Page 29 -
P. 29
내가 구글의 검색 품질 팀에 있을 당시 구글 검색 결과 페이지의 새로운
UI 프로토타입을 작성하는 사람들은 대부분 C++를 사용했다. 프로덕션에
는 뛰어난 성능이 필요하므로 C++가 훌륭한 선택이겠으나 컴파일 주기가
길고 번거로워서 새로운 기능의 프로토타입을 만들고 새 UI 인터랙션을 테
스트하기에는 적절하지 않았다.
그래서 나는 주어진 시간의 20%를 활용해서 파이썬으로 새로운 검색 기
능 프로토타입을 만들 수 있는 프레임워크를 만들었다. 나와 팀원들이 기능
의 프로토타입을 잇달아 만들고 회의에서 시연하기 시작하자, 다른 동료들
도 기존 작업을 포팅해 와야 하는 불편을 감수하더라도 우리가 만든 프레임
워크를 기반으로 작업할 때 생산성이 훨씬 높아진다는 것을 금세 깨달았다.
여러분이 만든 시간 절약 도구가 기존 도구에 비해 객관적으로 뛰어나도
전환 비용이 있기 때문에 다른 개발자들이 작업 흐름을 바꾸거나 새로운 도
구를 도입하는 것을 망설일 수 있다. 이럴 때는 전환 비용을 낮춰서 기존
작업 흐름에 새로운 도구를 더 부드럽게 통합할 방법을 찾으려 노력해야 한
다. 아마 설정을 약간만 변경해도 다른 개발자가 새로운 행동 양식으로 전
환하도록 유도할 수 있을 것이다.
일례로 우얄라에서 온라인 비디오 플레이어를 만들던 당시, 우리 팀은 모
두 플래시 Flash 애플리케이션을 사용하는 언어인 액션스크립트 actionScript 코
드를 이클립스 Eclipse 플러그인으로 컴파일했다. 안타깝게도 이 플러그인은
안정성이 떨어져서 변경사항을 다시 컴파일하는 데 실패하곤 했다. 컴파일
중인 내용을 주의 깊게 보지 않으면 비디오 플레이어를 실행해보기 전까지
변경사항이 누락됐는지 알 수 없었기 때문에, 자주 혼란이 발생하고 개발
속도가 지연됐다. 그래서 나는 안정적으로 빌드를 생산하는 명령줄 기반의
빌드 시스템을 만들었다. 처음에는 내 시스템을 사용하는 팀원이 몇 명 없
4장 반복 속도에 투자하라 101
이펙티브엔지니어_07.indd 101 2022-06-14 오후 3:57:33