[독서] CTO 테크리더 플레이북 - 최재필

[CTO 테크리더 플레이북] - 최재필(링크드인: https://www.linkedin.com/in/jaepil)

후기

CTO와 테크리더 직무를 하고 있다면 강력히 추천한다. 아니, 꼭 읽어야할 책이라고 생각한다. 이 책은 CTO의 역할을 분명하게 정의해주고, 실무에서 쓰고있는 명확한 가이드를 제시해준다. 이 책을 통해 내가 부족한 부분들을 많이 깨달을 수 있었고, CTO로서 생각과 행동을 어떻게 해야할지 분명하게 알 수 있었다.

3줄 요약

1. CTO는 무엇이 달라졌는지 설명할 수 있는 좋은 목표를 선정하고, 유지보수가 쉬운 아키텍처를 설계해야한다. 중요한건 쉽게 흔들리지 않는 기준을 세우는 것이다.
2. 스크럼을 통해 업무를 작게 나누고, 자주 점검하며, 품질을 놓치지 않는다. 시각화 도구(지라)를 통해 현재 팀의 상황을 한눈에 볼 수 있게 설정하고, 자연스럽게 평가로 이어지는 통합된 흐름을 만들어야한다.
3. 모든 것은 결국 한가지 질문으로 수렴한다. 어떤 기준으로 판단할 것인가? CTO는 조직이 스스로 판단하고 움직일 수 있도록 기준을 만드는 사람이다.

책을 읽게 된 배경

팀이 커지고 복잡해지면서 기존의 운영 방식이 점점 삐걱거리는 것을 느꼈다. 결정이 느려졌고 합의가 자주 불발됐으며 사람들을 모으고 미팅을 여는 것 만으로도 스트레스 받고 힘든 일이 되었다. 변화가 필요함을 느꼈고 제대로된 방법을 학습해야겠다는 생각이 들었다. 이때 재필님의 링크드인 글이 우연히 노출됐다. 이런 좋은 기회가 있을까 싶어서 플레이북 공유를 요청드렸고 재필님께서 선뜻 공유해주셨다.

서문: CTO의 일은 기술을 선택하는 것이 아니라 조직이 올바른 선택을 할 수 있도록 환경을 만드는 것

Part 1. CTO가 처음으로 버려야 할 착각들

Chapter 1. 일정은 목표가 아니다.

• 일정은 성과 판단의 기준이 아니다. 초기에 수립된 일정은 현실을 정확히 반영하지 못한다. 많은 조직은 일정을 지키는 것을 성과처럼 착각한다. 기술 부채를 쌓고, 품질을 희생하고, 테스트를 줄이고, 설계를 미루면 숫자상 일정은 지켜진다. 그 일정 끝에 무엇이 달라졌는지가 중요하다.
• 좋은 목표는 무엇이 달라졌는지를 설명할 수 있어야 한다. 사용자에게 어떤 가치가 전달되었고, 제품이 어떤 상태로 변화했는지를 말할 수 있어야 목표는 힘을 갖는다. 목표는 의사결정의 기준이다. 목표는 쉽게 흔들리거나 바뀌지 않는다.

Chapter 2. 성과 관리는 왜 실패하는가

• 대부분 구조의 문제이다. 목표를 세우고 실행으로 이어지고 점검과 평가로 자연스럽게 연결될때 비로소 의미를 갖는다. 하나의 흐름으로 이어질때 실제 성과를 판단할 수 있다.

Part 2. 설계와 아키텍처 - 원칙은 왜 필요한가

많은 조직은 설계를 미루거나, 과도하게 적용한다. 시간이 지날수록 변경 비용은 커지고, 기술적 의사결정은 점점 어려워진다.

Chapter 3. SOLID - 변경에 강한 설계를 위한 최소 원칙

• SRP 단일 책임 원칙: 단 하나의 일만 해야한다는 의미가 아니다. 단일 모듈의 변경 이유는 하나의 사용자(부서)여야한다. 즉 한 사용자(부서)의 요구사항에만 대응할 수 있도록 경계를 나누어야 한다는 뜻이다. 모듈의 변경을 최소화하기 위한 원칙이다. 너무 잘게 쪼개질 경우는 Facade를 두어 기능을 일관되게 관리할 수 있다.
• OCP 개방 폐쇄 원칙: 추가에는 열려있고 변경에는 닫혀있어야한다. 의존성 역전을 사용하여 고수준 컴포넌트(서비스)를 저수준 컴포넌트(DB, API, UI 등)가 의존하게 한다. 고수준 컴포넌트에 인터페이스(포트)를 만들고 저수준이 이를 의존하여 구현하게 한다.
• LSP 리스코프 치환 원칙: 하위 타입은 상위 타입을 완전히 대체해도 프로그램의 동작이 깨지지 않아야 한다. 상속, 인터페이스, 구현체의 설계원칙이다.
• ISP 인터페이스 분리 원칙: 각 사용자에게 필요한 수준으로 인터페이스를 분리한다.
• DIP: 의존성 역전 원칙: 클린 아키텍처의 핵심. 고수준 모듈을 저수준 모듈이 의존하도록 의존성을 역전시킨다.

Chapter 4. 아키텍처 - 유지보수가 쉬운가

• 아키텍처의 주된 목적은 시스템을 쉽게 이해하고, 쉽게 개발하며, 쉽게 유지보수하고, 쉽게 배포하는 것이다. 즉 시스템 관리 비용은 최소화하고, 개발자의 생산성을 최대화 해야한다.
• 독립성: 결합 분리: 생산성을 가장 떨어뜨리는 요인은 결합이다. 아키텍처의 목표는 결합을 최적으로 분리하는 것이다. 레벨에 따라 수평으로 계층을 분리해야하고 수직으로 유스케이스를 배치한다. 좋은 아키텍처는 모놀리틱 구조 > 독립적 배포 > 독립적 마이크로 서비스로 성장해 나가야한다.
• 경계: 선 긋기: 레벨 경계에 인터페이스를 두고 쉽게 교체할 수 있는 플러그인을 연결한다.
• 프로젝트 패러독스: 아이러니하게도 프로젝트 초반 잘 모르는 상태에서 아키텍처를 결정해야한다. 뛰어난 아키텍트라면 이런 점을 감안하여 외부 모듈의 의존을 최대한 줄여야한다.

Chapter 5. API - 일관성이 시스템을 지탱하는 방식

• REST 설계의 출발점은 언제나 리소스다. URI 는 리소스를 표현해야하며 메서드는 팀 전체가 같은 기준을 두고 선택한다. 리소스는 크게 3가지로 구분한다. document(단수), collection(복수), controller(동사). 소문자 kebab-case를 사용한다. 파라미터는 snake_case 를 사용한다. 기타 명확한 룰을 정해 팀이 하나의 기준으로 움직이게 한다.
• 원칙이 왜 필요한지 충분히 이해해야한다. SOLID, 클린 아키텍처, API 설계는 변경할 수 있는 상태를 유지하는 것이 목적이다.

Part 3. 실행과 완결 - 기준은 어떻게 현실이 되는가

Chapter 6. 프로젝트 관리 - 작게 나누고 끝까지 완결하라

• 과제의 크기는 3개월을 넘기지 않는다
• 일을 나눌 때는 '완결성'을 보장한다: 명확한 결과물이 존재한다. 결과물을 테스트할 수 있다. 사용자 또는 비즈니스 관점에서 의미가 있다.
• 일정 관리의 핵심: 라운드 단위 진행: 라운드 초반 테스트 케이스를 미리 작성한다. 이 테스트를 모두 통과해야 라운드 완료이다.
• 계층적 작업 구조 설계: 에픽, 태스크, 서브태스크
• 테스트와 품질 확보 전략: 테스트와 품질 확보를 뒤로 미루지 않는다. 매 라운드마다 테스트를 통과하여 품질을 확보한다. 품질 이슈를 누적시키지 않는다.

Chapter 7. 스크럼 - 작은 주기로 만드는 협업의 리듬

• 요구사항을 가치와 필요성 기준으로 정렬한다. 작은 주기 안에서 구현과 점검을 반복한다. 현재 상태와 문제점을 투명하게 드러낸다. 작업 방식을 지속적으로 개선한다. 스크럼을 통해 불확실성과 변화 속에서도 가치를 계속 만들어낼 수 있다.
• 스크럼의 본질은 빠른 피드백에 있다.

Chapter 8. 지라 - 실행 상태를 가시화하는 방법

• 가시성을 높이는 이슈 티켓 작성: Epic: 목표, Task: 실행, SubTask: 세부 작업
• 티켓 크기와 완결 기준: Epic: 1~3개월, Task: 1~5일, SubTask: 0.5~2일
• 상태는 단순하게 유지하라: To do, In Progress, Done. 즉시 상태를 바꾼다. 현재 팀 상태를 보여준다.
• 담당자는 반드시 한 명으로: 하나의 이슈에는 한 명의 담당자가 있어야 한다. 커뮤니케이션 비용을 줄인다.
• 대시보드는 팀을 위한 것이다. 관리자만 보는게 아니라 팀원 스스로 우리가 어디에 있는지 확인하기 위한 도구이다. 지라는 회의를 줄이기 위한 도구다. 지라의 목적은 보고가 아니라 공유다. 지라만 보고도 팀은 같은 상황을 인식할 수 있다. 그때 비로소 팀의 효율을 높이는 도구가 된다.
• 지라 설정의 기준: 이 설정이 일을 더 빨리 끝내는가? 입력 부담은 줄어드는가? 지금 상태가 한눈에 이해되는가? 아니오 라면 그 설정은 과감히 버린다.

Chapter 9. 정기 배포 - 지속적인 통합과 배포

• 정기적인 배포 주기를 통해 팀은 리듬을 갖는다.
• 정기 배포 주기: 1~2주 또는 1개월 단위
• 단계별 배포 프로세스: 서버 먼저 배포 -> 최소 24시간 이상 모니터링 -> 클라이언트 배포 -> 백오피스 처리. 모든 배포는 QA 검증과 내부 승인 절차를 거쳐야한다.
• 비정기 배포: 꼭 필요한 경우 필요할 수 있지만 일관된 리듬을 깨고 리스크와 비용을 크게 늘린다.
• 핫픽스 배포: 치명적인 오류에 사용한다. 해당 이슈만 빠르게 수정하여 최소한의 검증을 거친 뒤 배포한다. 이때 가장 중요한 선택은 안정 버전으로의 롤백을 고려하는 것이다.
• 버전 관리: product-YYMMDD, -nonregular, -hotfix

Chapter 10. 회고 - 제대로 작동하게 만드는 방법

• 회고가 점점 형식적으로 변한다. 인원이 많아지면 시간이 길어지고 목소리가 큰 몇몇에 회고가 지배된다. 이를 막기 위해 회고를 구조적으로 설계해야한다.
• 준비물: 포스트잇, 네임펜, 점스티커, 화이트보드 또는 벽면
• 절차 (총 90분):
  1) 포스트잇에 간결하게 하나의 내용 작성, 별도 설명 시간 없음, 미리 생각해오기 (15분)
  2) 보드에 포스트잇을 붙이기(대주제: LIKED, EARNED, LACKED, LONG FOR), 다른 구성원의 포스트잇을 같은 소주제로 그룹핑 (15분)
  3) 점스티커로 공감하는 포스트잇에 투표 (10분), 대화 없음, 그룹내 가장 공감하는 포스트잇에 한표만 행사
  4) 진행자가 공감이 많은 내용 선정(10분)
  5) 공감이 많은 주제 토론 (40분)
• 장점: 의견을 잘 말하지 않던 구성원이 글로는 의견을 낸다. 그룹핑, 투표를 하며 모두 의견을 알게된다. 미션하듯이 진행되어 집중력이 높다. 투표를 통해 다수의 구성원이 공감하는 주제를 알게된다.
  추가로) 개선점을 백로그로 만들어 다음 스크럼에서 해결하기

Part 4. 모든 것을 지속시키는 조직과 사람의 문제

Chapter 11. 성과 관리의 핵심 - 데이터 기반 연결

• 많은 IT 조직이 기대만큼 성과를 만들지 못하는 이유는 데이터가 흩어져 있고 목표, 실행, 평가가 하나의 흐름으로 연결되지 않기 때문이다.
• 체크인 시 공유되는 진척률의 정확도가 낮다. 투입된 리소스를 추적하기 어렵다. 팀원들의 기여도는 여전히 주관적인 평가에 의존하고 있다.
• 통합된 관점이 성과 관리의 핵심: 핵심은 통합이다. 목표 -> 실행 -> 체크인(점검) -> 평가가 하나의 사이클로 자동 연동되어야한다. 실제 투입된 데이터를 기반으로 정확한 진척률과 객관적인 참여자 기여도 지표가 제공된다.
• 성과 관리가 명확해지면: 목표가 단순한 선언이 아니라 실행의 기준이 된다. 객관적 데이터로 진척률과 기여도가 증명된다. 조직 전체가 같은 방향으로 움직인다. 이러한 구조가 갖춰지면 팀의 속도, 품질, 협업의 선명도를 높이는 장치로 기능한다.

Chapter 12. 목표 관리 - 다이어트와 닮았다.

• 개발팀은 뚜렷한 정량 지표를 잡기가 어려워서 일정이 잘못된 목표가 되곤한다.
• 개발 품질, 사용성 등이 떨어질 수 있다. 측정 가능한 기준을 통해 개선과 성장을 이어가야한다.
• 정확하고 정직한 수치를 알려주는 도구가 필요하다. 품질, 사용성, 성능 개선, 고객 피드백 같은 정확한 지표와 기준을 마련해야한다.

Chapter 13. 채용 인터뷰 - 아마존이 인재를 찾는 방법

• 아마존의 두가지 기준: 적어도 한 가지 면에서 기존 직원들보다 뛰어날 것, 조직의 미션을 믿으며 리더십 원칙을 내재화하는 사람. 단순한 스펙 평가가 아니라, 조직 문화와 기준에 부합하는지를 보는 기준이다.
• 행동사건 인터뷰: STAR 질문기법: Situation. 어떤 상황이었는가? Task. 어떤 과제를 맡았는가? Action. 어떤 행동을 취했는가? Result. 결과는 어땠는가?
• 인터뷰 피드백 문서: 매우 채용하고 싶다. 채용하고 싶다. 채용하고 싶다. 매우 채용하고 싶지않다. 피드백 문서는 구체적이고 상세한 사례들로 채워져야 한다. 편향을 없애기 위해 다른 면접관과 토론하지 않는다.
• 모든 인터뷰가 끝나면 참석한 모든 사람은 문서를 모두 읽는다. 그 후 각자가 다시 판단한다. 필요하다면 결정을 바꿀 수 있으며, 참석자 대다수가 같은 결론에 도달할 때까지 토론한다.

끝맺음

모든 것은 결국 같은 질문으로 수렴한다. 어떤 기준으로 판단할 것인가? CTO는 조직이 스스로 판단하고 움직일 수 있도록 기준을 만드는 것이다. 이 기준이 없으면 조직은 매번 같은 문제를 반복한다. 사람은 통제의 대상이 아니라, 기준 안에서 스스로 판단할 수 있을 때 가장 잘 움직인다. 기술은 계속 바뀐다. 하지만 기준은 자주 바뀌지 않는다. 시간이 지나도, 사람이 바뀌어도 작동한다. 이 책이 바라는 점은 CTO 와 테크리더가 자신의 역할을 다시 정의하는 계기가 되는 것이다. 코드를 잘 아는 사람이 아니라, 조직이 잘 움직이도록 설계하는 사람으로서 말이다. 조직은 사람 위에 세워진다.