ADR 3

Architecture Series를 마치며

이 글의 목적소프트웨어 아키텍처 본편 25편을 마쳤다. 이 글은 시리즈 전체를 압축·연결하고 다음에 어디로 갈지 짚는 에필로그다.25편 동안 본 개념을 한 장 지도로 다시 본다아키텍처에서 뻗어 나가는 주제와 블로그 내 다른 시리즈를 연결한다아키텍처 지식이 어떤 직업·역할과 맞닿는지 정리한다손으로 확인하는 방법과 읽을거리를 남긴다1. 25편이 만든 큰 그림아키텍처는 한 패턴 이름이 아니라 트레이드오프를 기록하고 운영하는 일이다.Part핵심 질문기억할 키워드0~1 기초무엇이 아키텍처이고 누가 무엇을 걱정하나concern, 품질 속성, 트레이드오프2 스타일구조를 어떻게 나누나레이어드, 헥사고날, MSA, EDA3 원칙모듈·도메인을 어떻게 묶나SOLID, 결합·응집, Bounded Context4 분산여러 노드..

ADR 실전

학습 목표ADR 작성법을 팀 워크플로(PR·리뷰·합의)에 연결할 수 있다.Supersede·Deprecated 절차와 양방향 링크를 운영할 수 있다.docs/adr/ 저장소·인덱스·도구를 설계할 수 있다.평가·구현 결과로 Proposed ADR을 Accepted로 승격하는 흐름을 설명할 수 있다.문제 상황ADR 템플릿만 있고 PR에 안 붙음 — 구현 후 잊음Accepted 40개인데 어느 게 현재 진실인지 모름 — Supersede 없음아키텍트 1명만 씀 — 팀은 " 문서 행정"으로 인식Confluence 복사본과 repo 불일치 — 어느 쪽이 맞는지 분쟁평가에서 ADR-0004 액션 나왔는데 티켓만 있고 ADR 파일 없음Rejected ADR 삭제 — 6개월 뒤 같은 논쟁 재개앞서 ADR 형식·평가 연..

ADR과 의사결정 기록

학습 목표ADR(Architecture Decision Record)가 무엇을·언제 남기는지 설명할 수 있다.Context·Decision·Consequences·Alternatives 섹션을 실무 템플릿으로 작성할 수 있다.Status(Proposed / Accepted / Superseded 등) 라이프사이클을 관리할 수 있다.C4·API 계약과 ADR이 역할을 나누는 방식을 설명할 수 있다.문제 상황2년 전 Kafka 도입 — "왜 RabbitMQ가 아닌가?" 슬랙 400줄 스크롤 후 포기Outbox 테이블 추가 PR — 리뷰어 "이거 왜?" — ADR 없음, 작성자 퇴사Confluence "아키텍처 원칙" 12페이지 — 현재 코드와 불일치, 누가 갱신할지 모름MSA 전환 롤백 논의 — "당시 제약..