Skip to main content

기술 제안서 템플릿 - Amazon Working Backwards 방식

고객/사용자 경험을 먼저 정의하고, 그 경험을 만들기 위해 필요한 기술을 거꾸로 설계하는 제안서 템플릿입니다.
본문은 6페이지 이내를 목표로 하고, 상세 근거는 부록으로 분리합니다.

0. 문서 정보​

항목내용
제안명{{제안명}}
상태Draft / Review / Approved / Rejected
작성 조직{{팀/부서}}
제안 책임자{{DRI}}
검토자 / 의사결정자{{이름, 역할}}
작성일 / 목표일{{YYYY-MM-DD}} / {{YYYY-MM-DD}}

1. 한 문장 결정 요청​

{{오늘 승인/반려/보류해야 하는 결정을 한 문장으로 쓴다.}}

예:

2026년 4분기까지 고객사별 실시간 사용량 분석 기능을 제공하기 위해 이벤트 수집 파이프라인을 Kafka 기반으로 재설계하는 안을 승인한다.

2. 작성 원칙​

  • 고객, 사용자, 운영자 중 누가 가장 큰 문제를 겪는지 먼저 정의한다.
  • 현재 만들 수 있는 것보다 고객이 실제로 필요로 하는 결과를 먼저 쓴다.
  • 장점뿐 아니라 비용, 리스크, 운영 부담, 롤백 계획을 함께 쓴다.
  • 회의에서는 발표 전에 참석자가 문서를 먼저 읽고 질문한다.

Part A. Working Backwards PR/FAQ

3. 미래 보도자료​

아직 출시되지 않은 제안을 이미 성공적으로 출시했다고 가정하고 작성한다.
독자는 내부 임원이 아니라 실제 고객, 사용자, 운영자다.

3.1 제목​

{{고객이 바로 이해할 수 있는 제품/기능/변경의 이름과 핵심 가치}}

3.2 부제​

{{어떤 고객이 어떤 문제를 더 빠르게, 쉽게, 저렴하게, 안전하게 해결하는지 한 문장으로 설명}}

3.3 출시 요약​

{{회사명}}은 {{YYYY-MM-DD}}에 {{대상 고객/사용자}}를 위한 {{제안명}}을 출시했다.
{{제안명}}은 {{핵심 문제}}를 해결하여 {{정량적/정성적 고객 가치}}를 제공한다.

3.4 고객 문제​

{{현재 고객/사용자가 겪는 문제를 고객 관점에서 설명한다.}}

  • 현재 고객은 {{현재 방식}} 때문에 {{불편/비용/위험}}을 겪고 있다.
  • 이 문제는 {{빈도, 규모, 금액, 시간, 품질 영향}}만큼 반복된다.
  • 기존 대안은 {{기존 대안}}이지만, {{부족한 점}} 때문에 충분하지 않다.

3.5 제안 솔루션​

{{제안이 고객 문제를 어떻게 직접 해결하는지 설명한다. 기술 구현 세부보다 고객 경험의 변화를 먼저 쓴다.}}

  • 고객은 앞으로 {{새로운 행동/업무 흐름}}을 할 수 있다.
  • 시스템은 {{자동화/정확도/성능/보안/확장성 개선}}을 제공한다.
  • 운영자는 {{운영 변화}}를 통해 {{장애 감소/대응 시간 단축/비용 절감}}을 얻는다.

4. 핵심 FAQ​

Q1. 누가 이 제안의 주 고객인가?​

{{고객 세그먼트, 사용자 역할, 사용 빈도, 현재 대안}}

Q2. 고객은 이 제안을 사용하면 무엇을 더 잘하게 되는가?​

{{시간 단축, 비용 절감, 품질 향상, 위험 감소, 매출 증가 등}}

Q3. 성공하면 어떤 지표가 바뀌어야 하는가?​

지표현재값목표값측정 방법
{{Metric 1}}{{현재}}{{목표}}{{측정 방법}}
{{Metric 2}}{{현재}}{{목표}}{{측정 방법}}

Q4. 왜 지금 해야 하는가?​

{{시장/고객 요구, 기술 제약, 계약 일정, 운영 한계, 경쟁 상황, 규제 등}}

Q5. 이번 제안에서 하지 않는 것은 무엇인가?​

  • 포함하지 않음: {{명시적 제외 범위}}
  • 다음 단계 후보: {{후속 범위}}

Part B. 6페이지 내러티브 기술 제안

5. 요약​

{{3-5문장으로 쓴다. 무엇을 제안하는지, 누구의 어떤 문제를 해결하는지, 왜 지금 필요한지, 어떤 결정을 요청하는지 포함한다.}}

6. 현재 상태와 한계​

6.1 현재 고객/사용자 흐름​

  1. {{현재 단계 1}}
  2. {{현재 단계 2}}
  3. {{현재 단계 3}}

6.2 현재 시스템​

6.3 현재 방식의 한계​

한계고객/사업 영향기술 원인근거
{{한계 1}}{{영향}}{{원인}}{{데이터/사례}}
{{한계 2}}{{영향}}{{원인}}{{데이터/사례}}

7. 목표와 성공 기준​

목표​

  • {{고객 가치 목표}}
  • {{사업/조직 목표}}
  • {{기술 품질 목표}}
  • {{운영 목표}}

비목표​

  • {{이번 제안에서 의도적으로 하지 않는 것}}
  • {{나중에 별도 검토할 것}}

성공 기준​

기준목표측정 방식
고객 경험{{예: 처리 시간 50% 감소}}{{분석 로그/설문/운영 지표}}
안정성{{예: p95 latency < 300ms}}{{APM/SLO}}
비용{{예: 월 인프라 비용 +10% 이하}}{{Cloud cost report}}
운영{{예: 수동 작업 월 20시간 감소}}{{운영 티켓/런북 기록}}

8. 제안 솔루션​

8.1 핵심 아이디어​

{{제안 솔루션을 1-2문단으로 설명한다. 고객 문제와 직접 연결해서 쓴다.}}

8.2 목표 아키텍처​

8.3 주요 변경점​

영역현재변경 후기대 효과
{{API/서비스/데이터/운영}}{{현재}}{{변경}}{{효과}}
{{API/서비스/데이터/운영}}{{현재}}{{변경}}{{효과}}

8.4 운영 모델​

영역제안 내용
배포{{순차 배포, 기능 플래그, 릴리즈 방식}}
모니터링/알림{{핵심 메트릭, 대시보드, 알림 조건}}
장애 대응{{런북, 온콜, 에스컬레이션}}
비용 관리{{예산, 비용 알림, 최적화 계획}}

9. 대안 검토​

대안장점단점결정
Option A: {{제안안}}{{장점}}{{단점}}선택 / 보류 / 기각
Option B: {{대안}}{{장점}}{{단점}}선택 / 보류 / 기각
Option C: Do nothing구현 비용 없음{{문제 지속}}선택 / 보류 / 기각

선택한 이유: {{선택한 안이 고객 가치, 기술 리스크, 비용, 일정, 운영 부담 측면에서 가장 적절한 이유를 설명한다.}}

10. 리스크와 검증 계획​

항목내용대응
핵심 가정{{가정}}{{실험/PoC/측정}}
기술 리스크{{리스크}}{{완화책, 소유자}}
보안/개인정보{{데이터 분류, 접근권한, 암호화, 보존 기간}}{{보안/법무 검토}}
운영 리스크{{온콜, 장애, 비용, 마이그레이션 이슈}}{{런북, 알림, 롤백}}

11. 실행과 출시 계획​

11.1 마일스톤​

단계산출물담당종료일승인 기준
검증{{PoC/스파이크 결과}}{{팀}}{{YYYY-MM-DD}}{{기준}}
설계{{상세 설계/ADR}}{{팀}}{{YYYY-MM-DD}}{{기준}}
구현{{서비스/기능}}{{팀}}{{YYYY-MM-DD}}{{기준}}
출시{{배포/전환}}{{팀}}{{YYYY-MM-DD}}{{기준}}

11.2 의존성과 롤백​

구분내용소유자기한/조건
의존성{{Dependency}}{{이름/팀}}{{YYYY-MM-DD}}
롤백 조건{{롤백 조건}}{{이름}}{{조건/시간}}
롤백 조치{{조치}}{{이름}}{{예상 소요}}

12. 미해결 질문과 의사결정 기록​

구분내용소유자기한/날짜
미해결 질문{{질문과 왜 중요한지}}{{이름}}{{YYYY-MM-DD}}
결정 기록{{결정 내용과 근거}}{{결정자}}{{YYYY-MM-DD}}

Part C. 리뷰 운영

13. 리뷰 미팅 방식​

  1. 20-30분 동안 모두가 조용히 문서를 읽고 코멘트를 단다.
  2. 작성자는 발표하지 않고 질문을 받는다.
  3. 참석자 전원이 총평을 말한다.
  4. 가장 senior한 참석자는 마지막에 말한다.
  5. 마지막 10분에 결정, 보류 사유, 다음 액션을 확정한다.

14. 품질 체크리스트​

  • 고객/사용자가 명확하다.
  • 고객 문제가 고객 관점으로 쓰였다.
  • 성공 기준이 측정 가능한 지표로 정의됐다.
  • 대안과 trade-off가 명확하다.
  • 보안, 개인정보, 운영, 비용 영향이 포함됐다.
  • 마이그레이션과 롤백 계획이 있다.
  • 핵심 가정과 검증 방법이 있다.
  • 미해결 질문과 의사결정 기한이 명확하다.

Part D. 부록

A. 근거 데이터​

{{사용자 인터뷰, VOC, 로그 분석, 매출/비용 데이터, 장애 리포트, 벤치마크 결과 링크}}

B. 상세 아키텍처 / API / 데이터 모델​

{{상세 다이어그램, API 명세, 데이터 모델, 인프라 구성, 권한 구조}}

C. 참고한 Amazon 방식​

  • Working Backwards: 고객 경험을 먼저 정의하고 거기서부터 거꾸로 무엇을 만들지 명확히 한다.
  • PR/FAQ: 고객 가치, 범위, 사업 결과, 구현 난이도를 한 문서에서 검토한다.
  • 6-page narrative: 슬라이드 대신 내러티브 메모를 먼저 읽고 토론한다.