adr-formatlisted

# ADR Format: 기술 선택 의사결정 기록 `$ARGUMENTS`로 비교할 선택지를 받는다. 예: "PostgreSQL vs MongoDB", "React Query vs SWR vs RTK Query". ## 언제 이 스킬을 쓰는가 - 2개 이상 기술/라이브러리/접근법 중 하나를 골라야 할 때 - 결정이 되돌리기 어렵거나(DB, 인증 방식, 메시징 큐) 팀 전체에 영향을 줄 때 - 비개발자 PM/디자이너/창업자에게 기술 선택 근거를 설명해야 할 때 - 사내에 의사결정 흔적(ADR)을 남겨두고 6개월 뒤에 "왜 그랬더라" 막아야 할 때 - 트래픽/데이터/사용자가 10배 늘었을 때 무너지는지 미리 점검하고 싶을 때 ## 핵심 원칙 (비개발자도 이해 가능하게) 1. **추천안을 가장 위에** — 결론부터 본다. 근거는 뒤에 따라온다. 2. **숨은 비용을 드러낸다** — 라이선스, 학습 곡선, 채용 난이도, 운영 인력, 마이그레이션 공수 등 "공식 문서엔 안 나오는" 비용. 3. **2년 뒤 관점** — 지금은 편해도 2년 뒤 기술 부채가 되는 선택을 경고. 4. **숫자보다 시나리오** — "10배 트래픽 시 어떤 일이 벌어지나" 같은 구체적 그림. 5. **어려운 용어는 풀어쓴다** — "샤딩"이라 쓰면 "데이터를 여러 서버에 쪼개 저장하는 방식(샤딩)"으로. ## 7-섹션 평가 프레임워크 매 선택지마다 다음 7개 축으로 평가한다. | # | 섹션 | 무엇을 보는가 | |---|------|--------------| | 1 | 컨텍스트와 제약사항 | 현재 팀 규모, 기술 스택, 예산, 마감, 기존 시스템 호환성 | | 2 | 각 접근의 trade-off | 장점과 단점을 짝으로 (장점만 나열 금지) | | 3 | 확장성 관점 | 사용자 100명 → 10만 명까지 동일 구조로 갈 수 있나 | | 4 | 10× 트래픽/데이터 증가 시 문제 | 구체적 시나리오: "DB 커넥션 풀 고갈", "캐시 미스 폭증" 등 | | 5 | 숨겨진 비용 | 라이선스, 학습 곡선, 채용 풀, 운영 인력, 마이그레이션 | | 6 | 추천안과 그 이유 | **굵게 강조**. 왜 다른 것 말고 이것인가 | | 7 | 2년 뒤 기술 부채 예상 | 이 결정이 가져올 미래 부채 포인트 | ## 출력 양식 (실제 엔지니어링 조직 ADR) ```markdown # ADR-{auto-increment}: {결정 제목 — 예: "주 DB로 PostgreSQL 채택"} ## 추천 결론 (TL;DR) > **{선택지 X}를 추천한다.** 이유는 {핵심 한 줄}. {반대 선택지}는 {결정적 단점} 때문에 보류. ## Status Proposed | Accepted | Deprecated | Superseded by ADR-{n} 작성일: {YYYY-MM-DD} 작성자: {이름 또는 팀} --- ## 1. Context (컨텍스트와 제약사항) **현재 상황**: {배경 — 왜 지금 이 결정이 필요한가} **제약사항**: - 팀 규모: {N명},