[책] 구글 엔지니어는 이렇게 일한다 - 4

책을 읽고 인상 깊었던 글귀 정리

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

---

지금까지는 프로그래밍과 소프트웨어 엔지니어링의 차이를 알아보았습니다. 프로그래밍은 당면한 문제에 집중하여 코드를 생산합니다. 그에 반해 소프트웨어 엔지니어링은 수십 년 혹은 평생에 걸친 유동적이고 모호한 문제에 대응하기 위해 코드, 도구, 정책, 프로세스 등을 응용하는 더 폭넓은 개념입니다. 이번 장에서는 다양한 계층의 사용자를 위한 제품을 설계할 때 엔지니어가 짊어져야 할 책임에 관해 이야기합니다.

(중략)

[4.5 단일한 접근 방식 거부하기]

오늘날의 개발은 많이 쓰이는 기능을 먼저 만들고 특수한 상황에 쓰이는 기능이나 개선은 나중으로 미루는 방식으로 주로 진행됩니다. 하지만 여기에는 결함이 있습니다. 기술을 접하기에 유리한 사람들에게 우선권을 줌으로써 불평등을 가중하는 방식인 것입니다. 모든 사용자층을 고려하는 일을 설계 막바지까지 미룸으로써 훌륭한 엔지니어의 기준을 낮추는 꼴입니다. 대신 시작부터 포용적으로 설계하여 개발이 지향해야 하는 기준점을 높여주세요. 그리하여 기술을 접하기 어려운 사람들도 쉽게 접할 수 있고 행복하게 활용할 수 있는 도구를 만들어주세요. 이런 식으로 우리는 모든 사용자의 경험을 개선할 수 있습니다.

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

더 공정한 제도를 만들기란 제품을 더 포용적으로 설계하는 것 이상으로 어려운 도전입니다. 공정한 제도 개발이란 때론 잘못된 결과를 낳는 기존 프로세스에 반하는 도전을 의미합니다. 

(중략)

표면적으로 보면 평가 프로세스의 속도를 높이고 구직자의 대기 시간을 줄여주는 건 훌륭한 목표입니다. 그렇다면 이 사례에서 불공정 문제는 어디에 숨어 있을까요? 구글에서는 다음과 같은 공정성 문제들이 제기되었습니다.

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

이 질문 중 하나라도 답이 '아니오'라면 성과 등급을 보여주는 건 불공정하다는 것을 의미합니다. 그래서 잘못된 결과로 이어질 수 있습니다.

실제로 한 뛰어난 엔지니어가 과거의 성과로 미래의 성과를 예측할 수 있는지 의문을 제기했고, 구글은 심층 분석해보기로 결정했습니다. 그 결과 낮은 평가를 받은 많은 직원이 팀 이동 후 평가가 좋아졌음을 알아냈죠. 심지어 낮은 평가를 한 번도 받지 않은 직원들만큼 만족스럽고 훌륭한 평가를 받았습니다. 요컨대 성과 등급은 해당 평가 시점에 그 사람이 맡고 있던 역할을 얼마나 잘 수행했느냐를 말해줄 뿐입니다. 등급은 특정 시기의 성과 평가에 중요한 수단인건 사실이지만 미래의 성과를 예견해주지는 못했던 것이죠. 그래서 앞으로 맡길 역할에 준비되어 있느냐를 평가하거나 팀 이동 시 자격을 논하는 데 이용되어서는 안 됩니다. (하지만 팀 이동 희망자가 현재 팀에 적합한지를 평가하는 데는 참고할 수 있습니다.) 따라서 그 직원을 더 잘 도와주려면 어떻게 해야 하는가를 고민해볼 기회로 활용할 수 있습니다.)

이 심층 분석에는 상당한 기간이 소요됐지만 사내 이동 프로세스의 공정성을 개선하는데 기여했습니다.

[4.10 핵심 정리]

• 우리는 편견에서 벗어날 수 없습니다.
• 다양한 사용자층을 포용하도록 설계하려면 조직 구성 측면에서도 반드시 다양성을 갖춰야 합니다.
• ..