Ch7 계획과 전달

6/4/2025

 Timothy @ Daangn Frontend Core

Software Engineer, Frontend @Daangn Frontend Core Team

ex) Senior Lead Software Engineer @NHN Dooray (2021 ~ 2023)

ex) Lead Software Engineer @ProtoPie (2016 ~ 2021)

ex) Microsoft MVP

Timothy Lee

이 웅재

7.1 장기 프로젝트 계획

• 플랫폼 엔지니어링의 일정이 일반적인 애플리케이션 엔지니어링의 일정보다 훨씬 길다.

  • ​새로운 시스템을 구축하고, 테스트하고, 마이그레이션하는 데는
    회사의 규모에 따라 몇 달에서 몇 년까지 걸릴 수 있다.

  • 플랫폼 팀이 수개월간 사용자가 볼 수 있는 결과물을 전혀 제공하지 못하고,
    그저 프로젝트의 실현 가능성을 입증하는 정도의 성과만 내면서 작업을 이어가는 경우도 드물지 않다.

  • customer impact 가 발휘되길 기다리기 싫어한다면
    플랫폼 작업 내내 인내심을 시험 받을 수 있다.

• 플랫폼 리더로서 큰 규모의 장기 프로젝트를 감독하고
  팀이 프로젝트를 점진적인 마일스톤으로 나누는 작업을 돕는데 익숙해져야 한다.

  • 팀은 마일스톤과 논의 지점 파악을 도우면서 자신들의 노력을 올바른 방향으로 이끌어 주는 리더를 필요로 한다.

  • 리더십을 발휘하기에 가장 좋은 출발점은
    진행할 프로젝트가 구체적으로 무엇인지 명확히 하는 것

제안서 작성

• 달성하고자 하는 바를 모든 관계자에게 납득시킬 필요가 있다.

• 프로젝트 리더는 아이디어를 제안서나 요구사항 문서 형태로 문서화해서
  경영진이나 기타 엔지니어들이 평가하고 검토할 수 있게 해야 한다.

• 전통적인 엔지니어링 설계 문서와 다름

• 아마존 스타일의 6페이지 문서 같은 것이 있음

• 문서 형식이 어떻든, 제안서 작성에서 가장 중요한 것은 5가지 핵심 요소를 포함하는 것

제안서에 포함해야 하는 다섯 가지 핵심 요소

• 배경, 원칙, 가이드라인

• 문제의 세부사항

• 가능한 해결책 개요

• 제안하는 해결책과 근거

• 실행 계획

제안서에 포함해야 하는 다섯 가지 핵심 요소

• 배경, 원칙, 가이드라인

  • ​현재 상황을 설명하고 여기까지 오게 된 관련 정보를 제공한다.

  • 예시와 같은 핵심 원칙, 요구사항, 가이드라인을 명시한다.

    • ​"cross regional failover 를 지원해야 한다."

    • "향후 Y개월 이내에 X의 확장을 지원할 준비가 되어야 한다."

  • ​현재 상태를 문서화하여 기준선을 설정하면
    근본적인 의견 차이를 프로세스 초기에 해결할 수 있다.

• 문제의 세부사항

• 가능한 해결책 개요

• 제안하는 해결책과 근거

• 실행 계획

제안서에 포함해야 하는 다섯 가지 핵심 요소

• 배경, 원칙, 가이드라인

• 문제의 세부사항

  • ​해결해야 할 문제를 깊이 있게 다루는 섹션

  • 해결책을 설명하기 전에 문제를 서술하라 - 레슬리 램포트

  • 해결책을 제시하기 전에 문제를 개략적으로 설명하면
    제안된 것 이외의 가능한 해결책을 상상하기 쉽다

  • 프로젝트 리더가 문제를 잘 이해하지 못하는 부분을 드러내서
    리더가 더 많은 세부사항을 수집하고
    제안하는 내용을 완전히 이해하도록 만드는 데에도 도움이 된다.

• 가능한 해결책 개요

• 제안하는 해결책과 근거

• 실행 계획

제안서에 포함해야 하는 다섯 가지 핵심 요소

• 배경, 원칙, 가이드라인

• 문제의 세부사항​

• 가능한 해결책 개요

  • ​합리적인 해결 방안들을 모두 나열하고 각각의 주요 장단점을 공정하게 평가

  • 하나의 해결책을 정하기 전에 이 단계를 거치면, 이미 제외한 해결책을 누군가가 제시하는 일을 미리 방지할 수 있다.

  • 장단점들을 개인적으로 고찰하고 상반된 두 가지 의견을 모두 제시하기도 함

• 제안하는 해결책과 근거

• 실행 계획

제안서에 포함해야 하는 다섯 가지 핵심 요소

• 배경, 원칙, 가이드라인

• 문제의 세부사항​

• 가능한 해결책 개요​

• 제안하는 해결책과 근거

  • ​선택한 해결책을 제시하고, 시간적 제약 등의 제약 조건과 기타 관련 요소를 분석하여 결정의 근거를 설명한다.

  • 청중을 설득하는데 필요한 만큼 시간을 할애한다.

    • ​그렇다고 너무 긴 문서말고 상위 3 ~ 5개 요소를 추려서 이들을 다른 고려 사항보다 우선시 해야 하는 이유를 주장하는 것이 적당

• 실행 계획

제안서에 포함해야 하는 다섯 가지 핵심 요소

• 배경, 원칙, 가이드라인

• 문제의 세부사항​

• 가능한 해결책 개요​

• 제안하는 해결책과 근거​

• 실행 계획

  • ​제안서에서는 너무 상세한 것이 아니라 구현의 전체적인 상을 그리는 데 주력해야 한다.

  • 완료란 어떤 모습이며, 일정이 어느 정도인지를 서술

  • 초기에서 중기까지의 마일스톤과 성공 측정 지표 제시

  • 비기술적 문제도 포함 (시기, 인력 배치, 조직에 미치는 영향)

제안서 작성 후

• 경영진 및 선임 엔지니어들과 함께 한번 이상 회의를 열어 장단점을 논의하고 동의를 구한다.

• 어떤 방식이든 이러한 회의의 목표는 아래 내용에 대해 동의하게 만드는 것

  • ​프로젝트가 가치가 있다는 점

  • 구현 비용을 추정하고 작업 시작에 대한 최종 승인을 받기 위한 실행 계획을 수립해야 한다는 점

제안서에서 실행 계획으로

• 제안 승인 후 구현에 들어가기 전에 해야 할 문서 작업

  • 기술적 측면이 잘 고려되었는지 확인하기 위한 "상세한 설계서"
    - 선임 엔지니어들이 리뷰​

  • 제안서보다 훨씬 자세한 내용을 담은 "실행 계획" 문서

실행 계획 문서에서 중요하게 고려해야 하는 사항

• 테스트와 승인 기준

• 의존성 분석

• 인력 추정

• 도입 추진

• 이정표 (마일스톤)

실행 계획 문서에서 중요하게 고려해야 하는 사항

• 테스트와 승인 기준

  • ​테스트 계획서의 작성과 프로젝트 실행 과정에서 테스트 계획을 추적

  • 테스트에 승인 기준도 포함

• 의존성 분석

• 인력 추정

• 도입 추진

• 이정표 (마일스톤)

실행 계획 문서에서 중요하게 고려해야 하는 사항

• 테스트와 승인 기준

• 의존성 분석

  • ​어떤 다른 팀들이 이 프로젝트에서 작업해야 하는가?

  • 프로젝트가 다른 시스템과 통합되어야 하는가?

  • 해당 시스템을 소유한 팀의 동의와 가능한 참여를 얻었는가?

  • 프로젝트의 의존성이 많을수록 프로젝트 전달이 어려워진다.

  • 프로젝트의 전달을 완료하기 위해 고객의 마이그레이션이 필요하다면 마이그레이션은 프로젝트 제안서의 일부로 추정해야 할 중요한 의존성 분석 대상이다.

• 인력 추정

• 도입 추진

• 이정표 (마일스톤)

실행 계획 문서에서 중요하게 고려해야 하는 사항

• 테스트와 승인 기준

• 의존성 분석​

• 인력 추정

  • ​프로젝트의 핵심 엔지니어링에 필요한 엔지니어 수를 예상하고 추정

  • 테스트, 통합, 마이그레이션 등을 위한 일시적인 인력 증원이 필요한지도 고려

• 도입 추진

• 이정표 (마일스톤)

실행 계획 문서에서 중요하게 고려해야 하는 사항

• 테스트와 승인 기준

• 의존성 분석​

• 인력 추정​

• 도입 추진

  • ​내부 시스템 구성요소가 아니라 다른 엔지니어들이 직접 사용할 것을 만드는 경우, 도입을 추진할 계획이 있어야 한다.

  • 팀이 무엇을 만들고 있는지 홍보해서 고객이 제품의 목적을 이해하고 사용하고 싶어 하게 만들 계획을 세워야 한다.

  • 이름을 무엇이라고 할까? 얼리 어답터가 될 팀이 있는가? 문서가 필요한가? 사용법을 가르쳐야 할까? 발표나 블로그 등의 마케팅 활동이 필요할까? 출시를 어떻게 알릴까?

• 이정표 (마일스톤)

실행 계획 문서에서 중요하게 고려해야 하는 사항

• 테스트와 승인 기준

• 의존성 분석​

• 인력 추정​

• 도입 추진​

• 이정표 (마일스톤)

  • ​구현 작업을 일련의 이정표로 표현

  • 처음 12개월은 상세하게, 기본적으로 월별 이정표

  • 분기별 이정표는 후반부에 명확하지 않을때

  • 기술적 역량 전달뿐만 아니라 비즈니스 성과도 지원하는 이정표는 많을수록 좋다.

프로젝트 관리자를 너무 일찍 투입하지 말라

• 왜요?

  • 너무 일찍 투입하면 팀원들이 자신감을 가지는 것이 아니라, 팀에 일정 관리 관료주의가 생겨나서 엔지니어링 리드와 제품 관리자의 참여가 줄어든다.

  • 계획 수립에 그들이 의견이 반영되지 않으면 추정치가 지나치게 보수적이고 부정확해지는 경우가 많다.

  • 그래서 일정 관리의 세부사항이 프로젝트에 중대한 위험이 되는 경우에만 프로젝트 관리자를 투입하라고 조언한다.

• 다음과 같은 경우라면 프로젝트 관리자를 두어도 좋다

  • ​프로젝트에 확고한 마감일이 있는 경우

  • 프로젝트에 작업 의존성이 아주 많은 경우

  • 회사 문화가 협력하기 어려운 경우

    • ​"이번 OKR 에 포함되지 않아 다음 분기까지 기다려주세요"

장기 생고생 피하기

• 합리적인 플랫폼 프로젝트가 끝없는 생고생으로 변하는 이유 알아보기

  • ​과욕

  • 너무 크게 시작하기

  • 불명확한 문제 영역

  • 프로젝트 팀원 이직

7.2 상향식 로드맵 계획 수립

• 이 플랫폼은 안정성이 형편없어... 게다가 기능을 제때 출시하지도 못해!

• 기능 전달 일정에 대한 기대치를 관리할 계획이 없으면 플랫폼 팀은 운영 업무를 소홀히 하게 되고, 결국 운영 지옥에 빠지게 된다.

  • 시스템의 복잡도가 높아지고, 팀은 기술 부채를 만드는 땜질식 패치로 문제를 해결한다.

  • 새로운 기능의 약속된 마감일을 지키지 못하고, 반복되는 운영 문제를 겪으며, 고객을 실망시킨다.

  • 과도한 운영 업무와 스트레스로 엔지니어가 번아웃 된다.

• ​이러한 결과를 피하려면 기능 전달 계획에 플랫폼 운영과 운영 개선에 필요한 작업을 추가해야 한다. 추정이 필요한 세 가지 작업 영역

  • ​Keep the lights on 작업

  • 경영진 지시사항

  • 시스템 개선

가장 기본적인 KTLO 작업

• 그냥 "운영" 이라고 부르는 조직도 있음

• 향후 12개월 동안 비즈니스 운영에 절대적으로 필요한, 엔지니어링 팀의 진정한 필수 운영 작업을 뜻함

• 예시

  • ​온콜 사고 대응 인력 배치

  • 필수 사용자 지원 인력 배치 (온콜 또는 정규)

  • 운영 및 보안 사고 해결과 중요 사후 분석 조치 사항 처리

경영진 지시사항

• 하향식 명령으로, 경영진이 반드시 수행해야 한다고 말하는 것들​

• 엄격한 일정이 정해져 있을 때도 많다.

• 예시

  • ​다른 플랫폼 및 인프라 팀이 주도하는 마이그레이션

  • 새로운 클라우드 제공업체로의 이전, 인수 후 통합, 새로운 리전 구축 등의 인프라 계획

  • 회사의 규정준수, 보안 또는 운영 태세를 개선하기 위한 계획

    • ​오래된 오픈소스 의존성 제거 또는 HIPAA 규정 준수

  • ​지역(로컬) 우선순위를 무시하는 대규모의 "전략적" 비즈니스 계획

    • ​모든 제품에 AI 기능을 대폭 추가해야 한다.

• ​​경영진 지시사항은 계획 수립에 모순을 초래한다.

  • ​이랬다 저랬다. 최악

  • 정치적 감각으로 경영진과의 원할한 소통이 필요하다.

시스템 역량

• 시스템을 곧 개선하지 않으면 문제 발생 가능성이나 부정적 영향이 커져서 중기적으로 회사에 해를 끼칠 수 있는
• 세 가지 방향에서 작업이 발생한다.
  • ​규모 확장으로 시스템이 한계에 가까워지는 경우
  • 변화하는 환경에서 시스템이 자연스럽게 저하되는 경우
  • 플랫폼과 애플리케이션이 비즈니스에서 더욱 중요해지면서 표준이 높아지는 경우
• ​시스템 역량은 일반적으로 세 가지 범주로 나뉜다.
  • ​신뢰성과 운용성 - SRE
  • 효율성과 성능 - FinOps
  • 보안과 규정 준수

모든 것을 하나로

• 앞에서 준비를 잘 했다면 다음과 같은 산출물이 생겼을 것
  • ​꼭 필요한 KTLO 작업의 타협할 수 없는 추정치
  • 타협이 불가능할 가능성이 큰 필수 프로젝트들의 추정치
  • 고객과 이해관계자들이 플랫폼에 바라는 새로운 기능들을 나열한 제품 로드맵
  • 효율성, 신뢰성, 보안 개선 프로젝트들의 우선 순위별 목록 3개​

모든 것을 하나로

• ​위의 목록을 가지고 구체적인 계획으로 만들 때 중요한 요소
  • ​리듬감
    • ​플랫폼 팀의 경우 연 1회는 처음부터 철저하게 계획을 수립하고,
      나머지 3분기에는 좀 더 가볍게 갱신
  • 여러 목록의 병합
  • 플랫폼 팀들의 로드맵 병합

모든 것을 하나로

• ​위의 목록을 가지고 구체적인 계획으로 만들 때 중요한 요소
  • ​리듬감
  • 여러 목록의 병합
    • ​KTLO 는 팀 업무량의 40% 이하 - 번아웃 조심
    • 개별 시스템 개선 프로젝트의 작업량은 3개월을 넘기지 말 것
    • KTLO 가 아닌 작업에는 70/20/10 (구글)
      • ​70% 핵심 이니셔티브
      • 20% 핵심과 인접한 혁신
      • 10% 변혁적 혁신
  • 플랫폼 팀들의 로드맵 병합

모든 것을 하나로

• ​위의 목록을 가지고 구체적인 계획으로 만들 때 중요한 요소
  • ​리듬감
  • 여러 목록의 병합
  • 플랫폼 팀들의 로드맵 병합
    • ​가장 큰 가치는 한 수준 위에서 나온다.
    • 하지만 우리는 더 높은 수준에서 목록들을 병합해서 완벽한 전체 계획을 만드는 방식을 권장하지 않는다.

7.3 격주간 성과 및 난제 공유로 현황 알리기

• 계획이 완벽해도 문제는 생긴다.

• 예상치 못한 일이 발생하고 일정이 바뀐다.

• 아무것도 진행되지 않는다고 생각할 수 있다.

• 조직이 커지면서 확신하지 못한다.

• 이를 해결하기 위해 ' 성과 및 난제 (Wins and Challenges) '라는 활동을 사용한다.

기본 사항

• (언제) 2주마다 조직의 위계구조를 따라 올라가면서,

  • ​따라 올라간다 - 직속 관리자가 팀의 업데이트를 작성하고, 위계에서 그 위에 있는 각 수준은 그 업데이트 중 아래 수준에게 가장 중요하고 흥미롭거나 영향력 있는 내용을 선택해서 더 넓은 대상이 이해할 수 있도록 필요에 따라 다시 작성한다

• (무엇을) 지난 2주 동안의 성과(Wins)와 문제점 혹은 난제(Challenges)를

• (어떻게) 간결한 글머리 목록(bullet list) 형태로 작성한다.

(왜) 이런 활동에 시간을 들여야 하는 이유

• 이런 활동은 팀과 관리자들에게 다른 팀의 활동 상황을 적절한 수준에서 파악할 수 있는 가볍고도 정기적인 방법을 제공한다.

• 플랫폼 엔지니어링 팀은 장기적이고 이해하기 어려운 프로젝트를 수행하는 경우가 많다.

• 자신들의 업무 가치와 영향력을 설명하는 데 다른 팀들보다 더 많은 시간을 들여야 한다.

• 이해와 신뢰를 구축해야 한다.

• 이 활동이 최고다.

(무엇을) 성과 및 난제 업데이트의 구조화

• 성과들

  • ​요점 1

  • 요점 2

• ​난제들

  • ​난제 1

  • 난제 2

• ​먼저 굵은 글씨의 짧은 요약으로 시작한 다음, 상황, 조치, 결과를 각기 한두 문장으로 설명

  • ​상황 - 조치를 취하기 전의 상황은 어땠는가

  • 조치 - 그 상황을 해결하기 위해 무엇을 했는가

  • 결과 - 조치가 상황에 어떤 영향을 미쳤는가 가능하면 수치로

업데이트 문서에 포함할 만한 주제들의 예

• 주요 이니셔티브 관련 소식. 이정표 달성이나 지연 등.

• 인사 관련 소식. 팀원 이탈이나 합류, 팀 분할, 조직 개편 등.

• 운영 관련 소식. 사건 사고 보고, 좋은(사고 수나 페이지 호출 수 기준) 주간 성과 축하, 나쁜 성과 인정 등

• 제품이나 엔지니어링 지표의 변화. 성능 개선, 비용 절감, 도입 이정표, 고객 만족도 조사 변화, 주목할 만한 고객 피드백 등.

난제들을 포함해야 하는 이유

• 내부 건정성 모니터링

• 외부 신뢰 구축

• 협업 관련 난제들을 공유할 때는 신중

  • ​파트너 팀의 지도층과 상의 먼저

  • 대응할 기회도 주지 않고 깐거 같은

팀원들의 성과 및 난제 작성 돕기

• 반복적인 실천 중요

• 주기가 맞지 않는다는 것은 변명

• 팀의 실행 및 전달을 책임지는 사람이 팀원들의 업데이트 작성을 관리해야 한다.

• 가장 영향력 있는 업데이트를 더 널리 공유할 책임도 있다.

• 대부분 엔지니어링 관리자

• 다른 모든 이들이게 적극적으로 공유해야 한다.