Architecture Decision Records

Architecture Decision Records

현재 아키텍처의 주요 선택과 그 이유, 감수한 제약을 기록합니다.

ADR은 변경 비용이 크고 여러 기능에 영향을 주는 기술 결정을 기록합니다. 사용 방법을 설명하는 가이드와 달리, 당시의 맥락과 대안, 선택의 결과를 보존하는 것이 목적입니다.

상태

상태	의미
Proposed	검토 중이며 구현 기준으로 사용하지 않음
Accepted	현재 구현과 운영의 기준
Superseded	새 ADR로 대체됨
Deprecated	더 이상 권장하지 않지만 일부 경로에 남아 있음

결정 목록

ADR	상태	결정일	결정
ADR-0001	Accepted	2026-03-10	Lambda Version과 Alias를 배포 단위로 사용
ADR-0002	Accepted	2026-03-14	포털 작업을 Job·Outbox·SQS로 분리
ADR-0003	Accepted	2026-03-14	내부 콜백을 HMAC으로 서명
ADR-0004	Accepted	2026-04-10	스크래핑 결과 본문을 S3로 전달
ADR-0005	Accepted	2026-06-01	dev·prod 스키마를 외부 Flyway 작업으로 변경

ADR 작성 기준

다음 조건 중 하나 이상에 해당할 때 ADR을 추가합니다.

• 데이터 일관성, 인증, 배포 또는 장애 복구 방식이 바뀝니다.
• 여러 모듈이나 외부 시스템 사이의 책임 경계가 바뀝니다.
• 되돌리기 어렵거나 운영 비용이 큰 기술을 채택합니다.
• 비슷한 대안이 반복해서 논의되며 선택 이유를 보존할 필요가 있습니다.

단순 구현 세부사항, 한 PR 안에서 끝나는 리팩터링, 값만 바뀌는 설정은 ADR로 만들지 않습니다.

변경 규칙

• Accepted ADR의 과거 맥락과 결론을 현재 관점으로 다시 쓰지 않습니다.
• 결정이 바뀌면 기존 문서를 삭제하지 않고 새 ADR을 추가한 뒤 기존 상태를 Superseded로 변경합니다.
• 코드 변경으로 결과나 제약이 달라지면 같은 PR에서 관련 ADR을 갱신합니다.
• ADR과 코드가 다르면 현재 dev 코드와 테스트를 우선하고 문서 불일치를 수정합니다.