Page 29 -
P. 29

내가 구글의 검색 품질 팀에 있을 당시 구글 검색 결과 페이지의 새로운
                  UI 프로토타입을 작성하는 사람들은 대부분 C++를 사용했다. 프로덕션에

                  는 뛰어난 성능이 필요하므로 C++가 훌륭한 선택이겠으나 컴파일 주기가
                  길고 번거로워서 새로운 기능의 프로토타입을 만들고 새 UI 인터랙션을 테

                  스트하기에는 적절하지 않았다.

                    그래서 나는 주어진 시간의 20%를 활용해서 파이썬으로 새로운 검색 기
                  능 프로토타입을 만들 수 있는 프레임워크를 만들었다. 나와 팀원들이 기능

                  의 프로토타입을 잇달아 만들고 회의에서 시연하기 시작하자, 다른 동료들
                  도 기존 작업을 포팅해 와야 하는 불편을 감수하더라도 우리가 만든 프레임

                  워크를 기반으로 작업할 때 생산성이 훨씬 높아진다는 것을 금세 깨달았다.
                    여러분이 만든 시간 절약 도구가 기존 도구에 비해 객관적으로 뛰어나도

                  전환 비용이 있기 때문에 다른 개발자들이 작업 흐름을 바꾸거나 새로운 도

                  구를 도입하는 것을 망설일 수 있다. 이럴 때는 전환 비용을 낮춰서 기존
                  작업 흐름에 새로운 도구를 더 부드럽게 통합할 방법을 찾으려 노력해야 한

                  다. 아마 설정을 약간만 변경해도 다른 개발자가 새로운 행동 양식으로 전
                  환하도록 유도할 수 있을 것이다.

                    일례로 우얄라에서 온라인 비디오 플레이어를 만들던 당시, 우리 팀은 모
                  두 플래시 Flash 애플리케이션을 사용하는 언어인 액션스크립트 actionScript 코

                  드를 이클립스 Eclipse 플러그인으로 컴파일했다. 안타깝게도 이 플러그인은

                  안정성이 떨어져서 변경사항을 다시 컴파일하는 데 실패하곤 했다. 컴파일
                  중인 내용을 주의 깊게 보지 않으면 비디오 플레이어를 실행해보기 전까지

                  변경사항이 누락됐는지 알 수 없었기 때문에, 자주 혼란이 발생하고 개발
                  속도가 지연됐다. 그래서 나는 안정적으로 빌드를 생산하는 명령줄 기반의

                  빌드 시스템을 만들었다. 처음에는 내 시스템을 사용하는 팀원이 몇 명 없






                                                                 4장  반복 속도에 투자하라  101




     이펙티브엔지니어_07.indd   101                                                2022-06-14   오후 3:57:33
   24   25   26   27   28   29   30   31