필독! 개발자 온보딩 가이드를 참고

구조

개요

해결하고자 하는 문제와 이유를 설명한다.

현재의 상태와 컨텍스트

수정하게 될 아키텍처를 기술하고 용어를 정의한다.

변경해야 하는 이유

해결할 때의 가치는 무엇이고, 왜 지금 해야하는지. 노력에 비해 얻는 점이 무엇인지 비즈니스의 요구사항과 연관지어야 한다.

요구사항

채택 여부를 위해 필요한 조건을 나열하자.

• 사용자 요구사항
• 기술 요구사항
• 보안 및 규제 요구사항(데이터 보관과 접근 정책)
• 마감일, 예산 등 중요한 고려사항

고려할 수 있는 해결책

트레이드오프에 대해 생각하자

채택하려는 해결책

해결책을 서술하자

설계와 아키텍처

활용할 핵심라이브러리와 프레임워크, 구현 패턴 등 구현과 관련된 주요 상세 내용을 설명한다.
블록 다이어그램, 데이터 흐름, UI 코드, API, 스키마 목업 등이 포함된다.

시스템 다이어그램

주요 컴포넌트와 그 컴포넌트의 상호작용을 보여주는 다이어그램을 첨부하자.

UI/UX 변경

인터페이스 변경에 대한 것이라면 목업을 만들어 첨부하자.

코드 변경

구현 계획을 설명한다. 기존 코드가 어떻게 변경되는지 집중적으로 설명하자.

API 변경

기존 API의 변경사항 및 새롭게 제안된 API에 대해 문서화하자. 하위/상위 호환성 및 버저닝에 대해서도 설명해야 한다.
에러 처리에 대한 내용도 설명해야 한다.

영속 계층 변경

새로 추가하거나 수정할 스토리지 기술에 대해 설명하자. 새로운 데이터베이스, 파일 및 파일 시스템 레이아웃, 검색 인덱스, 데이터 변형 파이프라인 등에 대해 기술하면 된다.

테스트 계획

모든 테스트를 미리 정의할 필요는 없다. 그보다는 변경사항을 어떻게 검증할 것인지를 설명하자.

롤아웃 계획

복잡한 배포 순서 요구사항에 얽매이지 않을 전략을 서술하자. 배포 패턴을 사용할 지, 변경 사항이 제대로 동작하지 않을 경우 어떻게 감지해낼지, 문제가 발견되었을 때 어떻게 롤백을 수행할 지 생각해보자.

미결 사항

해결하지 못한 질문의 목록을 명시적으로 기록하자.