diff --git a/tdc114plus 배포 검토.md b/tdc114plus 배포 검토.md
new file mode 100644
index 0000000..a92de53
--- /dev/null
+++ b/tdc114plus 배포 검토.md	
@@ -0,0 +1,141 @@
+# tdc114plus 배포 검토
+
+작성일: 2026-07-20
+용도: 회의 현장에서 바로 보고 설명하기 위한 A4 1장 요약본
+
+## 0. 권장방안 및 결론
+
+| 항목 | 권장방안 | 판단 이유 |
+| --- | --- | --- |
+| 앱 배포 순서 | `staging -> 내부 검증 -> production` | 로그인, 세션, 조직도, 프로필 사진까지 함께 검증해야 하므로 production 직행은 위험 |
+| 최종 배포 대상 | `tdc114plus` 앱 + `tdc114plus-auth` 서버 | 이 두 축이 실제 운영 구성이고 `baron-sso-tdc114plus-api`는 로컬 개발/검증용 |
+| `baron-sso-tdc114plus-api` 취급 | 최종 배포 필수 구성에서 제외 | 개발 중 임시 worktree 성격이므로 운영 구조의 필수 요소로 보지 않음 |
+| `tdc114plus-auth` 운영 형태 | Baron SSO에 흡수하지 않는 `독립 서비스` 유지 | 앱 전용 인증/중계 책임이 있어 저장소, 배포, 장애 대응 경계를 분리하는 편이 안전 |
+| `tdc114plus-auth` 배치 위치 | 초기에는 기존 운영 인프라 안의 독립 실행 구조 | 처음부터 물리 서버를 새로 만들지 않아도 서비스/설정/배포를 분리해 시작 가능 |
+| 중계서버 외부 주소 | `114-auth.hmac.kr` 같은 전용 서브도메인 | 앱과 운영자 모두 역할을 이해하기 쉽고, 도메인/인증서/라우팅 관리가 명확 |
+| 서버 배포 전략 | `블루/그린` 1순위 | 로그인/세션 장애 시 직전 버전으로 빠르게 rollback하기 가장 쉬움 |
+| 회의용 최종 결론 | `staging 우선`, `auth 독립 서비스`, `블루/그린 채택` | 현재 구조와 운영 안정성을 같이 만족하는 가장 현실적인 1차안 |
+
+## 1. 이번 회의에서 결정할 핵심
+
+1. 신규앱 `tdc114plus`를 어떤 순서로 배포할 것인가
+2. `tdc114plus-auth` 중계서버를 어디에 둘 것인가
+3. `tdc114plus-auth` 서버 배포 방식은 무엇으로 할 것인가
+
+## 2. 현재 기준 결론
+
+- 신규앱은 `production 직행`보다 `staging -> 내부 검증 -> production` 순서가 적절하다.
+- 최종 배포 직접 대상은 `tdc114plus` 앱과 `tdc114plus-auth` 서버다.
+- `baron-sso-tdc114plus-api`는 로컬 개발/검증용이므로 최종 배포 필수 구성으로 보지 않는다.
+- `tdc114plus-auth`는 Baron SSO에 흡수하지 않고 `독립 서비스`로 유지하는 것이 맞다.
+- `tdc114plus-auth`의 운영 주소는 `114-auth.hmac.kr` 같은 전용 서브도메인 구성이 가장 현실적이다.
+- 서버 배포 방식은 현재 단계에서는 `블루/그린`이 1순위다.
+
+## 3. 왜 staging을 먼저 가야 하는가
+
+신규앱은 단순 화면 앱이 아니라 아래가 함께 묶여 있다.
+
+- 로그인 시작
+- 승인 확인
+- 앱 세션 발급
+- 직원검색/조직도 연동
+- 프로필 사진 프록시
+
+따라서 production에서 처음 검증하면 장애가 바로 운영 이슈가 된다.  
+그래서 Baron SSO 원본 `staging` 연동을 먼저 안정화한 뒤, 실기기 검증이 끝나면 production으로 승격하는 방식이 안전하다.
+
+## 4. `tdc114plus-auth`는 왜 중요하며 어떻게 봐야 하는가
+
+`tdc114plus-auth`는 앱 뒤에서 로그인과 중계를 처리하는 핵심 서버다.
+
+앱이 하는 일:
+
+- 사용자의 휴대폰에서 실행
+- `tdc114plus-auth` 호출
+
+`tdc114plus-auth`가 하는 일:
+
+- Baron SSO와 통신
+- 로그인 승인 결과 확인
+- 앱 세션 발급
+- 조직도/직원 데이터 중계
+- 프로필 사진 프록시 처리
+
+즉 이 서버가 깨지면 앱 로그인과 핵심 조회 기능이 함께 영향을 받는다.
+
+## 5. `같은 서버에 둔다`는 말의 정확한 의미
+
+아래 3가지는 서로 다르다.
+
+- 저장소 분리: Git 저장소를 따로 관리
+- 서비스 분리: 실행 프로그램을 따로 운영
+- 물리 서버 분리: 아예 다른 VM/장비에 배치
+
+현재 권장 방향은 아래다.
+
+- `tdc114plus`: 별도 저장소
+- `tdc114plus-auth`: 별도 저장소
+- Baron SSO: 기존 저장소 유지
+
+다만 `tdc114plus-auth`는 처음부터 별도 물리 서버를 만들지 않아도 된다.  
+기존 운영 인프라 또는 Baron SSO 인프라 안에서 `독립 프로세스/독립 컨테이너/독립 설정`으로 시작할 수 있다.
+
+즉 `같은 서버를 쓸 수 있다`는 뜻이지, `같은 저장소나 같은 서비스로 합친다`는 뜻은 아니다.
+
+## 6. 중계서버 배치 권장안
+
+가장 현실적인 1차안:
+
+- 주소: `114-auth.hmac.kr`
+- 운영 형태: `tdc114plus-auth` 독립 서비스
+- 배치 위치: 기존 운영 서버 또는 Baron SSO 인프라 안의 독립 실행 단위
+
+이 안의 장점:
+
+- 주소가 명확하다
+- Baron SSO 본체와 서비스 경계가 유지된다
+- 초기 인프라 부담이 작다
+- 나중에 별도 서버로 분리하기 쉽다
+
+## 7. `tdc114plus-auth` 배포 절차 요약
+
+1. Gitea에서 배포할 버전 또는 태그 확정
+2. staging 서버에 먼저 배포
+3. `/health`, 로그인, `link/init`, `link/poll`, 조직도, 프로필 사진 확인
+4. Android 실기기에서 실제 로그인과 조회 흐름 검증
+5. 문제 없으면 production 반영
+6. 배포 직후 로그와 장애 여부 집중 확인
+7. 문제 시 즉시 rollback
+
+## 8. 왜 블루/그린이 가장 적합한가
+
+블루/그린은 기존 운영 서버를 바로 덮어쓰지 않고, 새 버전을 옆에 준비한 뒤 전환하는 방식이다.
+
+장점:
+
+- rollback이 빠르다
+- 로그인/세션 장애가 생겨도 즉시 이전 버전으로 되돌리기 쉽다
+- 초보자도 구조를 이해하기 쉽다
+
+현재 `tdc114plus-auth`는 로그인과 세션을 담당하므로, `신구 버전이 섞일 수 있는 롤링`보다 `빠르게 되돌릴 수 있는 블루/그린`이 더 적합하다.
+
+## 9. 회의에서 꼭 확인할 질문
+
+1. `tdc114plus-auth`를 올릴 기존 운영 인프라가 있는가
+2. `114-auth.hmac.kr` 같은 전용 서브도메인을 사용할 수 있는가
+3. staging 도메인과 production 도메인을 나눌 수 있는가
+4. HTTPS 인증서와 secret 주입은 누가 담당하는가
+5. 블루/그린을 할 수 있을 정도의 서버 자원이 있는가
+6. 장애 시 rollback 책임자와 절차는 어떻게 되는가
+
+## 10. 회의용 최종 제안 문안
+
+```text
+신규앱은 production 직행보다 staging 연동 안정화 후 production으로 승격하는 구조가 안전합니다.
+
+최종 배포 대상은 tdc114plus 앱과 tdc114plus-auth 서버이며, baron-sso-tdc114plus-api는 로컬 개발용으로 보고 최종 배포 필수 구성에서는 제외하는 것이 맞습니다.
+
+tdc114plus-auth는 Baron SSO에 흡수하지 않고 독립 서비스로 유지하되, 초기에는 114-auth.hmac.kr 같은 전용 서브도메인과 기존 운영 인프라 안의 독립 실행 구조로 시작하는 것이 현실적입니다.
+
+서버 배포 방식은 현재 단계에서는 rollback이 빠른 블루/그린을 1순위로 제안합니다.
+```