제 첫 90일은 경청한 뒤, 지도를 그리고, 그다음 실행한다는 순서로 구성됩니다. 무언가를 바꾸기 전에 먼저 신뢰와 맥락을 얻고, 그다음 작지만 눈에 보이는 성과를 내며, 그제서야 구조적인 변화를 제안합니다. 목표는 영웅적 행동이 아니라 신뢰입니다.
0~30일: 경청하고 학습하기
- 모두와 1:1 미팅 — 모든 엔지니어, 제 매니저, PM, 핵심 stakeholder를 만납니다. 무엇이 잘 돌아가고, 무엇이 망가졌으며, 누군가 고쳐줬으면 하는 게 무엇인지 묻습니다.
- 코드만이 아니라 시스템을 읽기 — 앱을 로컬에서 실행하고, 핵심 요청 경로를 추적하며, 최근 3개월간의 incident와 postmortem을 읽습니다.
- 딜리버리 파이프라인 파악하기 — 코드가 노트북에서 프로덕션까지 어떻게 가는지, 어디서 막히는지, CI/CD와 on-call 상황은 어떤지.
- 아직 구조적인 것은 아무것도 쓰지 않기. 워크플로를 익히고 제가 직접 손을 움직인다는 걸 보여주기 위해 작은 PR(문서, flaky한 테스트, README)을 올립니다.
30~60일: 진단하고 성과 내기
- 발견한 것들을 짧은 서면 진단으로 정리합니다: 영향도 순으로 정렬한 강점 3가지, 리스크 3가지.
- 시그널이 강하고 리스크가 낮은 성과 하나를 고릅니다 — 예: CI 시간을 절반으로 줄이기, 가장 시끄러운 알림 고치기, 배포 과정 문서화하기. 눈에 보이는 가치는 더 큰 변화를 위한 정치적 자본을 쌓아줍니다.
- 방향을 확정하기 전에 제 판단을 팀과 매니저와 함께 검증합니다.
60~90일: 방향 설정하기
- 비즈니스 목표와 연결된 기술 roadmap을 제안하고, 순서와 담당자를 정합니다.
- **팀의 의례(ritual)**를 수립하거나 다듬습니다 — 코드 리뷰 규범, on-call 로테이션, 계획 수립 주기.
- 6개월 시점에 제 성공이 어떻게 측정되는지 매니저와 합의합니다.
피해야 할 함정
- 이해하기 전에 다시 작성하기 — "명백한" 엉망진창은 종종 힘들게 얻은 제약 조건을 담고 있습니다.
- 모든 것을 한 번에 고치려 하기 — 적게 골라서 끝까지 마무리하세요.
- 인간 관계도(social graph) 무시하기 — 실제로 누가 의사결정을 내리는지는 아키텍처만큼이나 중요합니다.
왜 중요한가
Tech Lead의 레버리지는 신뢰와 맥락에서 나오며, 이 둘은 복리로 쌓입니다. 첫 한 달을 경청에 쓰는 것은 느려 보이지만, 엉뚱한 문제를 요란하게 해결하는 값비싼 실수를 막아줍니다 — 그리고 신뢰할 만한 초기 성과는 나중에 어려운 구조적 작업을 다룰 권한을 사줍니다.