Ch04 공정 사회를 위한 엔지니어링

한 줄 정의

우리가 만든 제품은 우리 조직의 편견을 그대로 닮기 때문에, 모두를 위한 소프트웨어를 만들려면 다양한 조직 구성과 의도적이고 측정 가능한 포용 실천 이 함께 있어야 합니다.

쉽게 말하면

프로그래밍이 당면한 문제를 풀려고 코드를 짜는 일이라면, 소프트웨어 엔지니어링은 수십 년에 걸친 유동적이고 모호한 문제에 대응하기 위해 코드·도구·정책·프로세스를 응용하는 더 넓은 활동입니다. 그 넓은 시야에 한 가지가 빠져 있으면 아무리 뛰어난 엔지니어라도 사용자에게 해를 끼칠 수 있습니다. 바로 누가 이 제품을 쓰는가, 그리고 누가 이 제품 때문에 소외되는가 라는 질문입니다.

핵심은 단순합니다. 제품은 그것을 만든 사람들의 모습을 닮습니다. 만드는 사람들이 한쪽으로 쏠려 있으면, 제품도 한쪽으로 쏠립니다. 그래서 “모두를 위한 제품(build for everyone)“이라는 구호는 코드 품질만으로는 절대 달성되지 않습니다. 조직 자체가 사용자를 대표하지 못하면, 가장 취약한 사용자에게 미치는 영향을 애초에 인지조차 못 하기 때문입니다.

왜 중요한가?

전 세계에 영향을 미치는 결정을 내리는 사람과 그 결정을 받아들일 수밖에 없는 사람 사이의 힘의 균형이 점점 무너지고 있습니다. 자신에게 해가 되는 기술이라도 약자는 받아들일 수밖에 없습니다. 누군가는 기술의 미래를 설계할 능력이 있고 다른 이들은 그렇지 못하다는 비대칭이 점점 커지는 상황에서, 엔지니어가 쥔 힘은 “문자 그대로 사회를 바꾸는 힘”입니다.

힘이 있으면 책임도 따릅니다. 백엔드/인프라 관점에서 이 장이 중요한 이유는, 공정성이 “있으면 좋은 가치”가 아니라 시스템 신뢰성과 같은 급의 품질 속성 으로 다뤄져야 한다고 말하기 때문입니다. 학습 데이터셋의 편향은 곧 잘못된 출력이고, 잘못된 출력은 곧 특정 집단에 대한 실패입니다. 우리가 가용성·지연시간을 SLO로 측정하듯, 공정성도 가정이 아니라 측정 의 대상이어야 합니다.

그리고 이 장의 출발점은 자기반성입니다. 구글조차 가장 취약한 고객을 보호하지 못한 실패 사례를 많이 가지고 있습니다. 더 공정한 제품으로 가는 길은 모든 답을 알기 때문이 아니라, 자신의 실패를 냉철하게 돌아보고 거기서 한 걸음 더 내딛는 데서 시작합니다.

핵심 내용

편견은 피할 수 없다

모든 사람은 편견을 지니고 있습니다. 사회 과학자들은 수십 년 연구 끝에, 사람 대부분이 무의식적인 편견(unconscious bias) 때문에 기존의 고정관념을 강화하고 퍼뜨린다는 사실을 밝혀냈습니다.

여기서 핵심은 무의식적 편견이 의도적인 배척보다 물리치기 어렵다 는 점입니다. 옳은 일을 하려고 애쓰면서도 내면의 편견을 인지하지 못할 수 있기 때문입니다. 개인이 그렇듯 조직도 마찬가지여서, 인력 운용·제품 개발에 잘못된 편견이 스며들지 않았는지 끊임없이 확인해야 합니다.

구글이 약자를 세심하게 배려하지 못한 이유는 엔지니어 구성비에서 찾을 수 있습니다. 구글의 엔지니어는 대부분 남성이고, 백인 혹은 아시아인입니다. 인력 구성이 사용자를 대표하지 못한다는 것은, 제품이 대표성이 부족하거나 취약 계층에 미치는 영향을 이해할 다양성이 부족하다는 뜻입니다.

사례 연구 — 구글 포토의 '고릴라' 분류

2015년 소프트웨어 엔지니어 재키 알시네(Jacky Alciné)는 구글 포토의 이미지 인식 알고리즘이 자신의 흑인 친구들을 ‘고릴라’로 분류한다고 지적했습니다. 구글은 신속히 대응하지도, 완벽히 해결하지도 못했고 2018년까지도 이 문제를 완전히 풀지 못했습니다.

이 치명적 실패의 원인은 세 가지로 정리됩니다.

• 데이터셋이 인구 구성을 대표하지 못했다. 이미지 인식은 학습 데이터에 의존하는데, 제공된 사진 데이터가 명백히 불완전했습니다.
• 조직 자체의 무의식적 편견이 제품에 새겨졌다. 구글(과 기술 산업 전반)이 흑인을 충분히 대변하지 못했고, 이 사실이 알고리즘 설계와 데이터 수집에 그대로 영향을 주었습니다.
• 타깃 시장에 대표성 낮은 그룹이 테스트에서도 빠졌다. 그래서 출시 전 내부 테스트에서 잡지 못하고, 출시 이후 사용자에 의해 발견되었습니다.

이 사례에서 기술 자체는 잘못이 없습니다. 자동 완성은 특정 사용자를 우대하거나 차별하도록 설계되지 않았습니다. 문제는 알고리즘이 혐오 발언 수준의 차별적 언어를 다 걸러낼 만큼 유연하지 못해 해로운 결과를 냈다는 데 있습니다. 자동 완성이 인종 차별적 표현을 추천하거나, 광고 시스템이 차별적 광고를 노출하거나, 유튜브가 혐오 발언을 완벽히 걸러내지 못하는 것이 같은 결의 실패입니다.

결과는 명백한 악영향이었습니다. 사용자 신뢰가 무너지고 참여도가 낮아졌으며, 흑인·라틴계·유대인 지원자들은 구글이 포용적 플랫폼이자 근무 환경을 제공한다는 믿음을 잃었습니다. ‘대표성이 높아지도록 채용한다’는 목표 자체가 타격을 입은 것입니다. 가장 좋은 해결책은 결국 엔지니어링 조직의 인적 구성을 제품이 목표하는 시장의 인적 구성과 닮아가도록 만드는 것 입니다.

대표성과 다문화 역량

뛰어난 엔지니어가 되려면 제품 설계와 구현에 다양한 관점을 포용해야 합니다. 이는 채용·인터뷰를 담당하는 직원도 전반적 인력 구성의 대표성까지 고려해야 한다는 뜻입니다. ‘모두를 위한 제품을 개발하려면 먼저 우리가 어떤 사람들을 대표하는지를 이해해야 한다’가 중요한 전제 조건입니다.

이 과정에서 깨야 할 통념이 있습니다. 컴퓨터 과학 학위나 업무 경험만으로 훌륭한 엔지니어가 된다는 믿음입니다. 학위가 필요한 출발점이 될 수는 있어도, 학위가 있다고 자동으로 좋은 엔지니어가 되는 것은 아닙니다. 학위 있는 사람만이 제품을 설계·구축할 수 있다는 믿음을 깨야, 더 다양한 배경의 사람을 받아들일 수 있습니다.

안목 — 만들지 않을 용기

다문화 역량(multicultural competency)의 핵심은 만들어야 할 때와 만들지 말아야 할 때를 구분하는 안목 입니다. 부정적 결과를 낳는 기능이나 제품을 알아채는 역량과, 그것을 거부할 수 있는 용기가 여기 포함됩니다.

이것이 어려운 이유는 역설적입니다. 높은 성과를 내는 엔지니어가 되는 데는 개인주의적 성향이 크게 작용하는데, 정작 공정성은 자기 커뮤니티를 벗어나 인터넷 활용도가 낮은 나라의 사용자나 우리 제품 때문에 소외될 사용자에게까지 시야를 넓혀야 얻어지기 때문입니다. 첫 단계는 사회적·교육적 요인으로 내게 심어진 편견의 현재 상태를 인식 하는 것입니다. 인식하고 나야 비로소 망각되던 쓰임새와 피해 입을 수 있는 사람들을 고려할 수 있게 됩니다.

편향된 데이터는 편향된 결과를 낳는다

AI 기반 얼굴 인식 소프트웨어는 아직 유색 인종이나 소수 민족을 구분하는 능력이 떨어집니다. 다양한 피부톤의 데이터가 부족하기 때문입니다. 훈련 데이터가 편중되어 특정 부류만 제대로 인식한다면 결과를 신뢰할 수 없습니다.

데이터 출처의 편향이 모델의 편향이 된다

2016년 연구에 따르면 미국 사법부 얼굴 인식 데이터베이스에는 1억 1,700만 명 이상의 미국 성인 데이터가 들어 있습니다. 그런데 미국 사회는 경찰력이 흑인 커뮤니티에 불리하게 집행되는 경향이 있어, 이 사법부 데이터를 얼굴 인식에 쓰면 인종적으로 편향된 오류를 낼 가능성이 큽니다. 대표성을 갖춘 데이터셋이라도 출처가 편향되어 있으면 잘못된 결과를 낳습니다.

소프트웨어는 빠르게 개발·배포되지만 독립적 테스트는 그 속도를 따라가지 못합니다. 이런 심각한 잘못을 바로잡으려면 속도를 늦추고 입력 데이터의 치우침을 최소화해야 합니다. 더 완전하고 정확한 데이터를 확보하기 위해 기꺼이 출시일을 미룰 줄도 알아야 합니다.

다양성을 실천 가능하게 만들기

우리가 종사하는 기술 분야에 성행하는 제도적 차별의 책임을 우리 모두가 진다고 인정해야 제도적 형평성과 공정성을 확보할 수 있습니다. 특정 개인에게 떠넘기거나, 회사·팀 내 역학 관계 탓으로 돌리는 태도는 무책임합니다.

가장 흔한 핑계는 이렇습니다. “성심껏 노력하고는 있지만, 우리 책임은 아니에요. 오래된 관습적 차별과 싸우는 게 쉬운 일은 아니잖아요?” 이야기가 이렇게 흘러가면 철학적·학문적 논의로 빠지기 쉽고, 정작 업무 환경이나 결과를 개선하는 데 집중하지 못하게 됩니다.

핵심 전환 — 학문적 토론에서 측정 가능한 실행으로

차별의 역사를 파고드는 건 학문적으로 의미 있는 싸움이지만, 더 중요한 건 형평성과 공정성을 심어주는 수량화할 수 있고(quantifiable) 실행 가능한(actionable) 일이 무엇인지 고민하는 것입니다. 예를 들어 리크루터라면 후보 그룹에 여성이나 소수자가 포함되어 있는지, 고용 후 성장 기회가 공평하게 돌아가는지, 테크 리드와 관리자가 팀 내 공정성을 강화할 수단을 가졌는지를 점검해야 합니다.

단일한 접근 방식 거부하기

기술 분야의 불평등은 복잡하며 여러 요인이 복합적으로 작용하므로, 단 하나의 철학이나 방법론으로는 해결할 수 없습니다.

대표적인 단일 접근의 함정이 “채용 과정만 바로잡으면 대표성 부족을 해소할 수 있다” 는 믿음입니다. 채용은 뿌리에 해당하는 단계지만 당장의 전부는 아닙니다. 채용 이후의 승진과 고용 유지(이탈 방지)에도 제도적 차별이 없는지 예의주시해야 합니다. 실제로 구글에서는 흑인 직원의 이직률이 다른 모든 그룹보다 높아, 대표성 개선이라는 목표 달성에 혼란을 줬습니다. 입구만 넓혀도 출구로 계속 빠져나가면 의미가 없습니다.

가장 어려운 사용자를 위해 설계하기

오늘날의 개발은 많이 쓰이는 기능을 먼저 만들고 특수한 상황의 기능을 나중으로 미루는 방식이 주를 이룹니다. 여기에는 결함이 있습니다. 기술을 접하기 유리한 사람에게 우선권을 줌으로써 불평등을 가중하는 방식이기 때문입니다. 포용을 설계 막바지로 미루면 훌륭한 엔지니어의 기준이 낮아집니다.

대신 시작부터 포용적으로 설계하여 개발이 지향할 기준점 자체를 높여야 합니다. 가장 소외받는 사람들을 위해 설계한다는 것은 현명함을 넘어선 모범 사례입니다. 다음 단계는 더 포괄적인 사용자 경험을 연구하는 것이며, 이 연구는 다양한 언어·문화·국가·사회 경제적 계층·장애 여부·연령대를 아우르는 사용자 그룹을 대상으로, 가장 어렵고 소외된 사용 사례를 최우선으로 살펴야 합니다.

확립된 프로세스에 도전하기

더 공정한 제도를 만드는 일은 제품을 포용적으로 설계하는 것보다 어렵습니다. 때론 잘못된 결과를 낳는 기존 프로세스에 정면으로 반하는 도전 을 의미하기 때문입니다.

구글의 한 엔지니어링팀이 외부 채용과 사내 이동을 모두 지원하는 글로벌 채용 요청 시스템을 구축한 사례가 이를 잘 보여줍니다. 개발팀은 핵심 사용자로 여긴 리크루터의 목소리를 듣고, 채용 관리자의 효율과 지원자 수를 늘리는 데 집중했습니다. 그 결과 누군가 사내 이동에 관심을 표하는 즉시 지원자의 성과 등급을(특히 낮으면 더욱) 부각해 보여주는 기능 을 요청받아 추가하려 했습니다.

표면적으로는 평가 속도를 높이고 대기 시간을 줄이는 훌륭한 목표였습니다. 그러나 공정성 문제가 숨어 있었습니다. 다음 질문 중 하나라도 답이 ‘아니오’라면, 성과 등급을 보여주는 건 불공정으로 이어집니다.

• 기존의 평가가 향후 성과를 예측하는 척도인가?
• 성과 평가가 다음 관리자에게 편견을 주지 않는가?
• 성과 평가 점수가 회사 전체적으로 표준화된 것인가?

실제로 심층 분석한 결과, 낮은 평가를 받은 직원 다수가 팀 이동 후 평가가 좋아졌습니다. 심지어 한 번도 낮은 평가를 받지 않은 직원들만큼 훌륭한 평가를 받았습니다. 요컨대 성과 등급은 그 시점에 맡은 역할을 얼마나 잘 수행했는지를 말해줄 뿐, 미래의 성과를 예견하지는 못합니다. 따라서 팀 이동 자격을 논하는 데 쓰여서는 안 됩니다. 이 분석은 오래 걸렸지만 사내 이동 프로세스의 공정성을 실제로 개선했습니다.

가치를 결과로 — 다섯 가지 방향

구글의 핵심 가치는 다양하고 포용적인 인적 구성이지만, 전 세계 사용자를 대표하게끔 채용하려는 목표에는 매년 미달합니다. 실패의 원인은 가치·의도·투자보다, 그것을 현실에 적용하는 과정 에 있습니다. 여성의 신체에 맞지 않는 웨어러블부터 피부색이 어두운 사람에게 효과 없는 화상 회의 소프트웨어까지, 이런 사례는 빈번합니다. 나아갈 방향은 다섯 가지입니다.

방향	핵심
자신을 솔직하게 성찰하자	대표성 있는 인력과 피드백 모델 없이는 ‘모두를 위한 제품’은 불가능함을 인정
모두를 위해 만들지 말고, 모두와 ‘함께’ 만들자	다양한 사용자를 설계의 중심으로 초대하고, 취약 커뮤니티 고려를 뒤로 미루지 않음
가장 어려운 이를 위해 설계하자	단기적 속도를 위해 공정성을 포기하지 않음
가정하지 말고 시스템 전반의 공정성을 측정하자	결정권자도 편향될 수 있으니, 전문가(혹은 팀)와 협력해 측정
변할 수 있다	과거 실패한 방식이나 현재 기술만으로는 감시·허위정보·사이버 폭력을 못 푼다

모두를 위해 만들지 말자, 모두와 '함께' 만들자

기술이 전체 인구를 대표하지 못하는 상황에서 ‘모두를 위한 제품’을 무에서부터 만드는 것은 불가능합니다. 그렇다고 포기할 수는 없습니다. 길은 하나입니다 — 사용자와 함께 만드는 것. 다양한 스펙트럼의 사용자를 참여시키고, 가장 취약한 커뮤니티를 의식적으로 제품 설계의 중심으로 초대해야 합니다.

비교 / 트레이드오프

출시 속도 vs 공정성

이 장 전체를 관통하는 긴장은 출시 속도와 공정성 사이에 있습니다. 많이 쓰이는 기능을 먼저 내고 특수 사례를 미루는 관행은 단기 속도를 높이지만, 기술 접근에 유리한 사람에게 우선권을 주어 불평등을 가중합니다.

관점	모두를 위해 만들기(build for everyone)	모두와 함께 만들기(build with everyone)
설계 주체	다수 사용자를 가정한 내부 팀	취약 커뮤니티를 포함한 사용자
포용 시점	설계 막바지(특수 사례로 후순위)	설계 시작점(기준선 자체를 높임)
공정성 다루는 법	가정·사후 보정	측정·사전 설계
출시 속도	빠름(일부 사용자에 해를 끼칠 위험)	느릴 수 있음(해를 끼치면 차라리 출시를 늦춤)

핵심은 속도를 모든 사용자에게 진정 유용한가 라는 관점에서 평가해야 한다는 것입니다. 일부 사용자에게 해를 끼칠 수 있는 제품이라면 차라리 출시를 늦추는 편이 낫습니다.

내 생각

• 편향된 데이터셋은 곧 SLO 위반입니다. “데이터가 인구를 대표하지 못한다”는 말은 운영 관점에선 특정 집단에 대한 정확도 SLO가 깨졌다는 뜻입니다. 가용성을 측정하듯 그룹별 성능 격차를 대시보드에 올려야 비로소 “측정 가능한 공정성”이 됩니다.

• 공정성도 출시 게이트입니다. 부하 테스트·보안 리뷰를 통과 못 하면 배포를 막듯, 취약 집단에 대한 검증 없이 나가는 ML 제품은 카나리아도 없이 프로덕션에 던지는 것과 같습니다. “기꺼이 출시일을 미룬다”는 결정은 SRE의 에러 버짓 사고와 같은 결의 절제입니다.

• 사내 이동 사례는 ‘데이터 기반 의사결정’의 함정을 보여줍니다. 성과 등급이라는 그럴듯한 지표가 사실은 미래를 예측하지 못했습니다. 지표가 존재한다는 이유만으로 노출하면 편향을 자동화·증폭합니다. 새 기능에 어떤 데이터를 노출할지는 항상 “이 신호가 무엇을 예측한다고 검증됐나”를 먼저 물어야 합니다.

• 단일 접근 거부 = 입구만 넓히지 말 것. 채용만 고치고 이직률을 방치하면 밑 빠진 독입니다. 온보딩·심리적 안전·승진 경로까지 시스템 전반을 봐야 한다는 점은 Ch03 지식 공유의 SPOF·심리적 안전 논의와 그대로 맞물립니다.