<PonsLink/>
작업
글
주제
시리즈
카테고리
연락
⌘K 검색
About
코드와 제품으로

코드와 제품으로

연결되는 세계

연결되는 세계

PonsLink는 만남 뒤 요청을 세션으로 잇고, PonsWarp는 서버 보관 없이 파일을 직접 전송합니다. 이 블로그는 기능 소개보다 설계 판단과 운영 증거를 남깁니다.

연락처

[email protected]github.com/DeclanJeon

운영

콘텐츠는 WordPress headless CMS, 공개 UI는 Next.js입니다.

초안 미리보기
© 2026 PonsLink Blog|Next.js · WordPress REST · Framer Motion
Local-first · Backup-before-deploy

Writing

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

주제
프로젝트
글 유형
6개의 글
개발 설계문서 지도: 문서 이름보다 질문을 먼저 본다
2026년 7월 7일·설계문서 공부 노트 읽는 순서·8 min

개발 설계문서 지도: 문서 이름보다 질문을 먼저 본다

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

software designdesign docsPRDSRSSDDADRRunbook공부 노트설계문서
제품 판단 문서: PRD는 구현 지시서가 아니다
2026년 7월 7일·설계문서 공부 노트 읽는 순서·7 min

제품 판단 문서: PRD는 구현 지시서가 아니다

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

PRDBRDMRDProduct BriefRoadmapproduct requirements공부 노트설계문서
요구사항 문서: “빠르게”를 검증 가능한 문장으로 바꾸기
2026년 7월 7일·설계문서 공부 노트 읽는 순서·7 min

요구사항 문서: “빠르게”를 검증 가능한 문장으로 바꾸기

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

SRSFRDNFRAcceptance CriteriaTraceability MatrixNASAIEEE 29148공부 노트설계문서
구조 설계 문서: SDD와 Architecture Doc은 박스 그림이 아니다
2026년 7월 7일·설계문서 공부 노트 읽는 순서·6 min

구조 설계 문서: SDD와 Architecture Doc은 박스 그림이 아니다

구조와 설계 문서는 “무엇을 만족해야 하는가”에서 “어떤 구조로 풀 것인가”로 내려간다. 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…

SDDTechnical Design DocArchitecture DocC4arc42SEIGoogle Design Docs공부 노트설계문서
결정 기록 문서: ADR과 RFC는 왜 나중의 개발자를 살리는가
2026년 7월 7일·설계문서 공부 노트 읽는 순서·6 min

결정 기록 문서: ADR과 RFC는 왜 나중의 개발자를 살리는가

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

ADRRFCDecision Logarchitecture decisionsMichael Nygard공부 노트설계문서
계약과 운영 문서: API Spec부터 Runbook, SLO, Postmortem까지
2026년 7월 7일·설계문서 공부 노트 읽는 순서·5 min

계약과 운영 문서: API Spec부터 Runbook, SLO, Postmortem까지

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

API SpecOpenAPIERDThreat ModelRunbookSLOPostmortemOWASPSRE공부 노트설계문서