시리즈: software-design-docs-reading-path에 해당하는 글입니다.

개발 문서를 찾아보기 시작하면 약어가 끝없이 나온다. PRD, SRS, SDD 정도만 알아도 복잡한데 BRD, MRD, NFR, ADR, RFC, API Spec, ERD, Runbook, Postmortem까지 이어진다. 처음에는 이걸 전부 외워야 하나 싶다. 로그를 다시 펼쳤을 때 눈에 들어온 건 예쁜 성공 화면이 아니라, 개발 주변에서 반복되던 작은 끊김이었다. 문서를 종류별로 외우면 금방 막힌다. 회사마다 이름이 다르고, 같은 약어도 다르게 쓰인다. TDD만 해도 어떤 팀은 Technical Design Document라고…

제품 판단 문서는 구현 방법을 정하려고 쓰는 문서가 아니다. 왜 이 문제를 풀어야 하는지, 누구에게 가치가 있는지, 어떤 결과를 성공으로 볼지를 정한다. 여기에는 Product Brief, BRD, MRD, PRD, Roadmap이 들어간다. 로그를 다시 펼쳤을 때 눈에 들어온 건 예쁜 성공 화면이 아니라, 제품 주변에서 반복되던 작은 끊김이었다.

요구사항 문서는 “좋게 만들자”를 “무엇을 만족해야 통과인가”로 바꾸는 문서다. 이 층위에는 SRS, SyRS, FRD, NFR, Acceptance Criteria, Traceability Matrix가 들어간다. 같은 단어를 쓰더라도 제품 문맥이 다르면 답이 갈렸다. 그 갈림길을 숨기지 않는 쪽으로 썼다. ISO/IEC/IEEE 29148은 요구사항 공학과 요구사항 산출물의 기준을 다룬다. NASA의 요구사항 작성 가이드는 좋은 요구사항이 necessary, verifiable, attainable, clear,…

구조와 설계 문서는 “무엇을 만족해야 하는가”에서 “어떤 구조로 풀 것인가”로 내려간다. SDD, Technical Design Doc, Architecture Doc, HLD, LLD, C4, arc42, UML이 여기에 들어간다. ```md - Redis를 사용한다. - WebSocket으로 실시간 알림을 보낸다. - PostgreSQL에 저장한다. arc42도 비슷하다. Introduction & Goals, Constraints, Context & Scope, Solution Strategy, Building Block…

큰 설계문서는 자주 낡는다. 처음에는 열심히 쓰지만 코드가 바뀌고 일정이 밀리면 업데이트가 멈춘다. 시간이 지나면 남는 것은 최신 코드와 오래된 문서 사이의 불신이다. 같은 단어를 쓰더라도 제품 문맥이 다르면 답이 갈렸다. 그 갈림길을 숨기지 않는 쪽으로 썼다. 참고: [Michael Nygard, Documenting Architecture Decisions](https://www.cognitect. 좋은 RFC는 찬성표를 모으는 문서가 아니다. 논쟁을 좁히는 문서다. 예를 들면 이렇게 좁힐 수 있다. ADR은…

서비스가 커질수록 내부 구현보다 경계의 약속이 중요해진다. 이 층위에는 API Spec, OpenAPI, AsyncAPI, ERD, Data Dictionary, Schema, ICD가 들어간다. 그리고 배포 뒤에는 Threat Model, Release Plan, Migration Plan, Rollback Plan, Runbook, SLI/SLO/SLA, Postmortem이 필요해진다. 운영만 있으면 나머지는 따라올 거라고 믿었다. 이런 문서는 평소에는 지루하다. 하지만 장애가 나면 가장 빨리 읽히는 문서가 된다. 이…