이 글은 Addy Osmani가 Google에서 14년간 경험으로부터 배운 교훈을 정리한 “21 Lessons From 14 Years at Google”이 가슴에 와닿아 정리해 본다.
1. 가치는 기술이 아니라 사용자의 곤란한 문제에서 나온다
새로운 기술을 배우면 사용하고 싶어진다. 그렇지만, 정말로 가치를 낳는 것은 이 기술 어디에서 사용하자?가 아니라 사용자는 무엇에 곤란한지? 이다. 사용자의 행동과 목소리에 귀 기울여야 한다. 문제를 정말로 이해하는 엔지니어가 되어야 한다.
2. 정론으로 논의를 이겨도 팀의 협력을 얻지 못하면 프로젝트는 진행되지 않는다.
“자신이 옳다”를 증명하는 것보다, 모두가 좋은 대답에 도달하는 것을 우선으로 하자.
3. 완벽한 설계보다 사용자에게 오픈해 사용자의 피드백에서 배우는게 빠르다.
완벽한 설계를 계속 생각한 나머지 아무것도 만 들지 않는 것보다, 최소 사양이라도 좋으니 우선 만든다. 피드백은 머리 속의 논의보다 100배 더 많이 배운다. 우선 만들고, 사용자 피드백에서 고치고, 개선을 반복한다.
4. 현명한 코드보다 알기 쉬운 코드여야 한다.
잘 쓰여진 코드는 유능함의 증명으로 보일 수 있지만, 운용에 있어서는 리스크가 될 수 있다. 심야에 트러블 대응중에 타인에게 코드는 읽어야 하는 메모이기 때문에 자신이 생각하는 코드의 아름다움보다 타인이 이해하기 쉬운 코드여야 한다.
5. 신기술의 도입은 빚과 동일하다.
최신 기술은 두근거리지만 도입할 때마다 ‘학습 비용’, ‘채용난’, ‘트러블시 정보 부족’ 등의 빚을 짊어진다. 정말 필요한 곳에만 도입하자.
6. 성과는 사람이 전한다.
“좋은 코드를 쓰면 평가된다”는 것은 환상이다. 당신이 없는 회의에서 누군가가 당신의 가치를 설명할 수 없다면 평가 대상이 되지 않는다. 자랑이 아니라 성과와 가치가 나와 어떻게 연결되어 있는지를 주위에 아는 형태로 알게 해야한다.
7. 최고의 코드는 쓰지 않은 코드다.
쓴 코드는 모두 미래의 버그·유지보수·설명의 대상이 된다. 만들기 전에 “정말 필요?”한지 묻는 습관을 가지자. 또, 기능을 추가하기 위해서 코드를 더하는 것보다 불필요한 코드를 지우는 것이 시스템을 좋게 하는 경우도 있다.
8. 사용자가 많으면 버그도 사양이 된다.
사용자가 많아지면 본래 생각하고 있던 기능이 아니어도 “사양”이 되어, 버그조차도 다른 요소와 의존 관계를 구성하는 경우가 있다. 이렇게 되면, 호환성 대응은 유지보수에 그치지 않고 가치가 되므로 기능의 불필요함의 논의는 때로는 사용자에게 노출해서 사용자에게 판단받아야 하는 경우도 있다.
9. 늦음의 원인은 인식 어긋남에 있다.
지연의 원인을 실행력이나 기술 탓으로 하기 쉽지만, 실제로는 다른 사람과의 방향성·역할 분담의 이음새·우선도의 불일치가 원인인 경우가 많다.
10. 바꿀 수 없는 것에 신경쓰지 않는다.
조직 개편·방침 전환·시장 변화 등 제어할 수 없는 일에 에너지를 소비하지 말고 자신이 통제할 수 있는 것에만 집중 하고 불확실성은 분해하고 지금 행할 수 있는 행동을 집중해야 한다.
11. 추상화도 때로는 복잡성이 제거되지 않고 겉으로 드러나 트러블로 이어질 수 있다.
추상화를 통해 아래 구조는 이해하지 않아도 된다고 인식하지만, 장애나 사이드 이펙트가 일어나면 추상화로 숨어 있던 복잡성이 나와 새벽에 혼자 원인을 찾아야 하는 상황이 오기 쉽다. 추상화 아래의 레이어도 문제가 될 수 있는 실패 패턴들이나 소스 분석을 해둘 필요가 있다.
12. 가르치면 자신의 이해가 깊어진다.
사람에게 설명하려고 하면, 자신이 애매하게 이해하고 있던 부분을 발견한다. 출력은 최고의 입력, 블로그, 문서, 뭐든지 좋으니까 설명해 보자.
13. 누군가를 돕는 일은 가시화한다.
문서화, 신입 교육, 팀간의 조정 등은 불가결한 일이지만, 아티팩트로 남기고 영향을 시각화 하지 않으면 캐리어에 안좋은 영향(번아웃, 평가에 제외)을 미친다.
14. 논의에서 계속 이기면 나중에는 저항이 축적된다.
많은 경우 설득되었다기보다는 상대가 포기했을지 모른다. 옳다는 단기적인 감각은 의욕적인 협력자와 제품을 만드는 장기적인 관점에서 훨씬 가치가 낮다.
15. 지표는 왜곡하기 쉽다. 목표로 하는 순간 의미를 잃는다.
코드 라인 수를 추적하면 더 많은 라인 수가 나오게 되고, 개발 속도를 추적하면 추정치가 부풀려지게 된다. 속도나 품질, 리스크의 지표를 세트로 해 수치의 기준을 절대시하지 않고 추이로 판단해야 한다.
16. “모르겠다”라고 말할 수 있는 것이, 팀을 안전하게 한다.
리더가 불확실성을 인정한다는 것은 다른 사람들도 같은 일을 해도 안전하다는 신호다. 경험이 많은 사람이 모르는 것을 모른다고 이야기하지 않는다면(안다고만 하면) 주니어들은 다른 모든 사람들이 이해하고 있다고 생각하며 침묵한다. 질문도 하지 않게 되고, 문제도 숨기게 되고, 도전도 어렵게 만든다.
17. 인맥은 어떤 직업보다 오래 지속된다.
일에 집중하고 네트워킹을 게을리하면 나중에 곤란해 질때가 있다. 관계를 쌓은 사람은 몇 년 후 기회를 옮겨준다. “이 사람이 나에게 도움이 될까?”를 계산하면서 관계를 맺기보다는, 그 사람 자체에 대한 호기심과 진정성·성실함을 가지고 관계를 맺자.
18. 가장 빠른 코드는 실행되지 않는 코드이다.
불필요한 작업을 제거하는 것은 필요한 작업을 더 빨리 만드는 것보다 더 속도를 올려준다. 최적화하기 전에 그 일이 원래 존재해야 하는지 물어보자.
19. 프로세스는 안심을 위해서가 아니라 불확실성을 줄이기 위해 존재한다.
“만약을 위해”에서 늘어난 규칙과 절차는 팀을 늦춘다. 목표를 설명할 수 없는 프로세스는 재 검토하자.
20. 언젠가 “시간＞돈”이 된다.
경력 초기는 시간을 돈으로 바꾼다. 하지만, 어느 시점에서 가치관이 역전된다. 승진이나 보상을 위해 시간과 에너지를 쏟기 전에 내가 무엇을 얻기 위해 하고 있는지를 이해하고 의도적으로 선택해야 한다.
21. 지름길은 없다. 그러나 복리의 마법은 있다.
전문성은 한 번에 역전을 노리는 것보다(지름길은 없다), 매일 조금씩 배우고 경험을 쌓아 올리는 과정에서 더 강해진다. 배운 것을 기록하고 재사용할 수 있는 구조를 만들며, 실패에서 교훈을 얻는 것. 단순해 보이지만 이런 작은 축적이 결국 복리처럼 쌓여 큰 차이를 만든다.