docs: record cloudflare deployment meeting result

docs: record release meeting handoff
docs: clarify auth deployment boundaries
2026-07-21 13:38:24 +09:00 · 2026-07-20 16:19:37 +09:00 · 2026-07-20 15:11:27 +09:00
7 changed files with 1259 additions and 0 deletions
@@ -370,6 +370,145 @@ production 직행의 장점은 아래 정도다.

 즉 "처음부터 무조건 완전 별도 물리 서버"가 아니라, "서비스 경계는 분리하고 인프라는 현실적으로 시작"하는 방향이다.

+## 5.6-A 위 문장을 더 쉽게 풀면
+
+여기서 가장 헷갈리기 쉬운 부분은 아래 3가지를 같은 뜻으로 오해하는 것이다.
+
+1. 저장소를 따로 둔다
+2. 서비스를 따로 운영한다
+3. 물리 서버를 따로 둔다
+
+이 3가지는 서로 다른 이야기다.
+
+### 저장소 분리
+
+이 뜻은 소스코드를 Git 저장소 단위로 따로 관리한다는 뜻이다.
+
+예:
+
+- `tdc114plus` 앱 저장소
+- `tdc114plus-auth` 저장소
+- Baron SSO 저장소
+
+### 서비스 분리
+
+이 뜻은 실제 실행되는 프로그램을 따로 운영한다는 뜻이다.
+
+예:
+
+- Baron SSO 본체 프로세스
+- `tdc114plus-auth` 프로세스
+
+둘이 같은 서버 안에 있어도 실행 주체가 따로면 서비스는 분리된 것이다.
+
+### 물리 서버 분리
+
+이 뜻은 아예 다른 VM, 다른 컨테이너 호스트, 다른 장비에 올린다는 뜻이다.
+
+즉 아래처럼 이해하면 된다.
+
+- 저장소는 따로일 수 있다
+- 서비스도 따로일 수 있다
+- 하지만 물리 서버는 처음엔 같은 것을 쓸 수도 있다
+
+그래서 "처음부터 인프라를 너무 크게 벌리지 않아도 된다"는 말은 `저장소만 다르게 둔다`는 뜻이 아니라 아래 뜻에 가깝다.
+
+- Git 저장소는 분리한다
+- 실행 서비스도 분리한다
+- 다만 처음에는 같은 운영 서버 자원을 활용할 수 있다
+
+## 5.6-B 실제로는 어떤 모습인가
+
+예를 들어 한 대의 서버 안에서 아래처럼 운영할 수 있다.
+
+- Baron SSO 본체 서비스는 기존 포트/기존 설정으로 실행
+- `tdc114plus-auth`는 별도 포트 또는 별도 컨테이너로 실행
+- 외부에서는 `114-auth.hmac.kr` 주소로 들어오고 reverse proxy가 `tdc114plus-auth`로 전달
+
+즉 겉으로 보기에는 전용 서버처럼 보이지만, 실제 초기 운영은 기존 인프라 안의 독립 서비스로 시작할 수 있다.
+
+이 구조의 핵심은 아래다.
+
+- 주소는 분리
+- 실행 프로세스도 분리
+- 설정값도 분리
+- 배포도 분리
+- 다만 물리 장비는 처음엔 공유 가능
+
+## 5.6-C `tdc114plus-auth`는 같이 둘 수 있는데, `tdc114plus` 앱은 왜 다르게 보나
+
+이 부분도 자주 헷갈릴 수 있다.
+
+### `tdc114plus-auth`
+
+`tdc114plus-auth`는 서버 프로그램이다.
+
+즉 실제로 서버 위에서 계속 실행되어야 하는 대상이므로, Baron SSO 인프라 안의 독립 서비스로 두는 개념이 성립한다.
+
+### `tdc114plus`
+
+반면 `tdc114plus`는 모바일 앱 소스코드와 빌드 산출물이다.
+
+즉 서버에서 계속 떠 있는 운영 프로세스가 아니라 아래 성격에 가깝다.
+
+- 개발 대상
+- 빌드 대상
+- 배포 대상
+- 휴대폰에 설치되는 결과물
+
+그래서 `tdc114plus-auth`를 같은 서버 인프라 안의 독립 서비스로 둔다는 개념을 그대로 앱 저장소에 적용하면 안 된다.
+
+## 5.6-D 그럼 `tdc114plus` 앱 소스코드를 Baron SSO 쪽에 같이 두는 것은 어떤가
+
+기술적으로 저장소를 한곳에 둘 수는 있다.
+
+하지만 현재 프로젝트 기준으로는 권장하지 않는다.
+
+이유는 아래와 같다.
+
+1. 책임이 다르다
+- `tdc114plus`는 모바일 앱이다
+- Baron SSO는 인증 본체다
+- `tdc114plus-auth`는 앱 전용 중계서버다
+
+2. 배포 시점이 다르다
+- 앱 배포
+- auth 서버 배포
+- Baron SSO 배포
+
+이 셋은 서로 다른 주기로 움직일 수 있어야 한다.
+
+3. 커밋과 리뷰 경계가 다르다
+- 앱 화면 수정
+- 인증 서버 수정
+- SSO 본체 수정
+
+이것이 한 저장소에 섞이면 추적과 검토가 어려워진다.
+
+4. 보안과 권한 경계가 다르다
+- 앱 개발자
+- auth 운영자
+- Baron SSO 운영자
+
+각자 접근 범위가 달라질 수 있다.
+
+그래서 현재 기준 추천 구조는 아래다.
+
+- `tdc114plus`: 별도 저장소
+- `tdc114plus-auth`: 별도 저장소
+- Baron SSO: 기존 저장소 유지
+
+단, `tdc114plus-auth` 실행 위치는 초기에는 Baron SSO 운영 인프라 안의 독립 서비스일 수 있다.
+
+## 5.6-E 한 줄로 정리하면
+
+아래처럼 기억하면 가장 쉽다.
+
+- `tdc114plus-auth`는 같은 서버 인프라 안에 둘 수 있다
+- 하지만 Baron SSO와 같은 서비스는 아니다
+- `tdc114plus` 앱은 같은 저장소나 같은 관리 경계에 섞지 않는 편이 낫다
+- 즉 서버 위치 공유는 가능하지만, 저장소와 서비스 경계까지 합치는 것은 권장하지 않는다
+
 ## 5.7 `tdc114plus-auth` 배포를 아주 쉽게 설명하면

 초보자 기준으로 가장 먼저 이해해야 할 점은 아래다.
@@ -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순위로 제안합니다.
+```
@@ -0,0 +1,264 @@
+<!DOCTYPE html>
+<html lang="ko">
+<head>
+  <meta charset="UTF-8">
+  <meta name="viewport" content="width=device-width, initial-scale=1.0">
+  <title>tdc114plus 배포 검토 회의 1페이지 요약</title>
+  <style>
+    @page {
+      size: A4;
+      margin: 10mm;
+    }
+
+    :root {
+      --text: #172033;
+      --muted: #4f5b73;
+      --line: #bfc8d8;
+      --head: #e9eef7;
+      --accent: #1f4ea3;
+      --soft: #f7f9fc;
+    }
+
+    * {
+      box-sizing: border-box;
+    }
+
+    body {
+      margin: 0;
+      font-family: "Noto Sans KR", "Malgun Gothic", sans-serif;
+      color: var(--text);
+      background: #fff;
+      line-height: 1.28;
+      font-size: 10.5px;
+    }
+
+    .page {
+      width: 190mm;
+      min-height: 277mm;
+      margin: 0 auto;
+      padding: 0;
+    }
+
+    h1 {
+      margin: 0 0 3mm;
+      font-size: 18px;
+      color: var(--accent);
+      letter-spacing: -0.02em;
+    }
+
+    .meta {
+      margin-bottom: 4mm;
+      color: var(--muted);
+      font-size: 10px;
+    }
+
+    h2 {
+      margin: 4mm 0 2mm;
+      font-size: 12px;
+      color: var(--accent);
+      border-left: 3px solid var(--accent);
+      padding-left: 6px;
+    }
+
+    p {
+      margin: 1.5mm 0;
+    }
+
+    ul, ol {
+      margin: 1.5mm 0 0 4mm;
+      padding: 0;
+    }
+
+    li {
+      margin: 0.7mm 0;
+    }
+
+    table {
+      width: 100%;
+      border-collapse: collapse;
+      table-layout: fixed;
+      margin: 1.5mm 0 2.5mm;
+    }
+
+    th, td {
+      border: 1px solid var(--line);
+      padding: 6px 7px;
+      vertical-align: top;
+      word-break: keep-all;
+    }
+
+    th {
+      background: var(--head);
+      text-align: left;
+      font-weight: 700;
+    }
+
+    .grid {
+      display: grid;
+      grid-template-columns: 1fr 1fr;
+      gap: 4mm;
+    }
+
+    .box {
+      border: 1px solid var(--line);
+      background: var(--soft);
+      padding: 3mm;
+    }
+
+    .strong {
+      font-weight: 700;
+      color: var(--accent);
+    }
+
+    .quote {
+      border: 1px solid var(--line);
+      background: #fff;
+      padding: 3mm;
+      font-weight: 700;
+    }
+  </style>
+</head>
+<body>
+  <div class="page">
+    <h1>tdc114plus 배포 검토 회의 1페이지 요약</h1>
+    <div class="meta">작성일: 2026-07-20 | 용도: 회의 현장에서 바로 보고 설명하기 위한 A4 1장 요약본</div>
+
+    <h2>권장방안 및 결론</h2>
+    <table>
+      <colgroup>
+        <col style="width: 18%">
+        <col style="width: 28%">
+        <col style="width: 54%">
+      </colgroup>
+      <thead>
+        <tr>
+          <th>항목</th>
+          <th>권장방안</th>
+          <th>판단 이유</th>
+        </tr>
+      </thead>
+      <tbody>
+        <tr>
+          <td>앱 배포 순서</td>
+          <td><span class="strong">staging -&gt; 내부 검증 -&gt; production</span></td>
+          <td>로그인, 세션, 조직도, 프로필 사진까지 함께 검증해야 하므로 production 직행은 위험</td>
+        </tr>
+        <tr>
+          <td>최종 배포 대상</td>
+          <td><span class="strong">tdc114plus 앱 + tdc114plus-auth 서버</span></td>
+          <td>실제 운영 구성의 핵심 두 축이며, <code>baron-sso-tdc114plus-api</code>는 로컬 개발/검증용</td>
+        </tr>
+        <tr>
+          <td>중계서버 형태</td>
+          <td><span class="strong">Baron SSO에 흡수하지 않는 독립 서비스</span></td>
+          <td>앱 전용 인증/중계 책임이 있어 저장소, 배포, 장애 대응 경계를 분리하는 편이 안전</td>
+        </tr>
+        <tr>
+          <td>배치 위치</td>
+          <td><span class="strong">기존 운영 인프라 안의 독립 실행 구조</span></td>
+          <td>처음부터 물리 서버를 새로 만들지 않아도 서비스/설정/배포를 분리해 시작 가능</td>
+        </tr>
+        <tr>
+          <td>중계서버 주소</td>
+          <td><span class="strong">114-auth.hmac.kr</span></td>
+          <td>앱과 운영자 모두 역할을 이해하기 쉽고, 도메인/인증서/라우팅 관리가 명확</td>
+        </tr>
+        <tr>
+          <td>배포 전략</td>
+          <td><span class="strong">블루/그린 1순위</span></td>
+          <td>로그인/세션 장애 시 직전 버전으로 빠르게 rollback하기 가장 쉬움</td>
+        </tr>
+      </tbody>
+    </table>
+
+    <div class="grid">
+      <div>
+        <h2>이번 회의 핵심</h2>
+        <ol>
+          <li>신규앱 <code>tdc114plus</code>를 어떤 순서로 배포할 것인가</li>
+          <li><code>tdc114plus-auth</code> 중계서버를 어디에 둘 것인가</li>
+          <li><code>tdc114plus-auth</code> 서버 배포 방식은 무엇으로 할 것인가</li>
+        </ol>
+
+        <h2>왜 staging이 먼저인가</h2>
+        <ul>
+          <li>신규앱은 단순 화면 앱이 아니라 로그인, 승인 확인, 앱 세션, 직원검색/조직도, 프로필 사진 프록시가 함께 묶여 있음</li>
+          <li>production에서 처음 검증하면 장애가 바로 운영 이슈가 됨</li>
+          <li>따라서 Baron SSO 원본 <code>staging</code> 연동을 먼저 안정화한 뒤 production으로 승격하는 구조가 안전</li>
+        </ul>
+
+        <h2>tdc114plus-auth가 중요한 이유</h2>
+        <ul>
+          <li>앱 뒤에서 로그인과 중계를 처리하는 핵심 서버</li>
+          <li>Baron SSO와 통신, 승인 결과 확인, 앱 세션 발급, 조직도/직원 데이터 중계, 프로필 사진 프록시 처리 담당</li>
+          <li>이 서버가 깨지면 앱 로그인과 핵심 조회 기능이 함께 영향을 받음</li>
+        </ul>
+      </div>
+
+      <div>
+        <h2>같은 서버에 둔다는 말의 의미</h2>
+        <ul>
+          <li><span class="strong">저장소 분리</span>: Git 저장소를 따로 관리</li>
+          <li><span class="strong">서비스 분리</span>: 실행 프로그램을 따로 운영</li>
+          <li><span class="strong">물리 서버 분리</span>: 아예 다른 VM/장비에 배치</li>
+        </ul>
+        <div class="box">
+          <p><span class="strong">현재 권장 방향</span></p>
+          <ul>
+            <li><code>tdc114plus</code>: 별도 저장소</li>
+            <li><code>tdc114plus-auth</code>: 별도 저장소</li>
+            <li>Baron SSO: 기존 저장소 유지</li>
+          </ul>
+          <p>다만 <code>tdc114plus-auth</code>는 처음부터 별도 물리 서버를 만들지 않아도 되고, 기존 운영 인프라 또는 Baron SSO 인프라 안에서 <span class="strong">독립 프로세스/독립 컨테이너/독립 설정</span>으로 시작할 수 있다.</p>
+        </div>
+
+        <h2>중계서버 배치 권장안</h2>
+        <ul>
+          <li>주소: <code>114-auth.hmac.kr</code></li>
+          <li>운영 형태: <code>tdc114plus-auth</code> 독립 서비스</li>
+          <li>배치 위치: 기존 운영 서버 또는 Baron SSO 인프라 안의 독립 실행 단위</li>
+          <li>장점: 주소 명확, 서비스 경계 유지, 초기 인프라 부담 작음, 나중에 별도 서버 분리 쉬움</li>
+        </ul>
+      </div>
+    </div>
+
+    <h2>tdc114plus-auth 배포 절차 요약</h2>
+    <ol>
+      <li>Gitea에서 배포할 버전 또는 태그 확정</li>
+      <li>staging 서버에 먼저 배포</li>
+      <li><code>/health</code>, 로그인, <code>link/init</code>, <code>link/poll</code>, 조직도, 프로필 사진 확인</li>
+      <li>Android 실기기에서 실제 로그인과 조회 흐름 검증</li>
+      <li>문제 없으면 production 반영</li>
+      <li>배포 직후 로그와 장애 여부 집중 확인, 문제 시 즉시 rollback</li>
+    </ol>
+
+    <div class="grid">
+      <div>
+        <h2>왜 블루/그린인가</h2>
+        <ul>
+          <li>기존 운영 서버를 바로 덮어쓰지 않고 새 버전을 옆에 준비한 뒤 전환</li>
+          <li>rollback이 빠름</li>
+          <li>로그인/세션 장애 시 즉시 이전 버전으로 되돌리기 쉬움</li>
+          <li>초보자도 구조를 이해하기 쉬움</li>
+        </ul>
+      </div>
+      <div>
+        <h2>회의에서 꼭 확인할 질문</h2>
+        <ol>
+          <li><code>tdc114plus-auth</code>를 올릴 기존 운영 인프라가 있는가</li>
+          <li><code>114-auth.hmac.kr</code> 같은 전용 서브도메인을 사용할 수 있는가</li>
+          <li>staging 도메인과 production 도메인을 나눌 수 있는가</li>
+          <li>HTTPS 인증서와 secret 주입은 누가 담당하는가</li>
+          <li>블루/그린을 할 수 있을 정도의 서버 자원이 있는가</li>
+          <li>장애 시 rollback 책임자와 절차는 어떻게 되는가</li>
+        </ol>
+      </div>
+    </div>
+
+    <h2>회의용 최종 제안 문안</h2>
+    <div class="quote">
+      신규앱은 production 직행보다 staging 연동 안정화 후 production으로 승격하는 구조가 안전하다. 최종 배포 대상은 tdc114plus 앱과 tdc114plus-auth 서버이며, baron-sso-tdc114plus-api는 로컬 개발용으로 보고 최종 배포 필수 구성에서는 제외하는 것이 맞다. tdc114plus-auth는 Baron SSO에 흡수하지 않고 독립 서비스로 유지하되, 초기에는 114-auth.hmac.kr 같은 전용 서브도메인과 기존 운영 인프라 안의 독립 실행 구조로 시작하는 것이 현실적이다. 서버 배포 방식은 현재 단계에서는 rollback이 빠른 블루/그린을 1순위로 제안한다.
+    </div>
+  </div>
+</body>
+</html>
@@ -0,0 +1,431 @@
+# tdc114plus 신규앱 배포 회의 결과 정리
+
+작성일: 2026-07-21
+회의일: 2026-07-20
+상태: 회의 결과 초안
+
+## 0. 팀장 확인 완료 내용
+
+아래 내용은 2026-07-21 팀장 확인 완료 기준으로 정리한다.
+
+1. 신규앱 `tdc114plus`와 중계서버 `tdc114plus-auth` 모두 Cloudflare 관리 체계 안에서 운영한다.
+
+2. `tdc114plus`는 Gitea에 코드가 올라가면 Gitea Actions로 APK를 자동 빌드하고, 결과물을 Cloudflare에 배포하는 흐름으로 진행한다.
+
+3. `114.hmac.kr`은 staging용 앱 다운로드 및 검증 경로, `114.brsw.kr`은 production용 앱 다운로드 경로로 진행한다.
+
+4. 사용자는 별도 복잡한 절차 없이 도메인에 접속하여 APK를 다운로드하거나 설치 안내 페이지에 접근하는 방식으로 진행한다.
+
+5. `tdc114plus-auth`도 Cloudflare Workers 쪽에서 운영하는 방향으로 검토한다.
+
+6. 다만 현재 `tdc114plus-auth`는 Go 기반 서버이므로 Cloudflare Workers에 그대로 올릴 수 있는지 기술 검토가 필요하다.
+
+7. Go 기반 서버를 그대로 Workers에서 운영하기 어렵거나 안정성이 낮다면, TypeScript 등 Workers 지원 언어로 재구현하는 방안을 검토한다.
+
+8. 우선 현재 `tdc114plus-auth`의 인증, 조직도, 프로필사진 중계 기능이 Cloudflare Workers 환경에서 지원 가능한지 PoC 수준으로 확인한다.
+
+9. 검토 결과를 기준으로 `Go 유지 + Cloudflare proxy/Tunnel 방식`과 `Workers 지원 언어로 재구현 방식` 중 안정적인 방향을 비교해 제안한다.
+
+## 1. 회의 배경
+
+2026-07-20 신규앱 배포 방식과 관련하여 배포 방향을 논의했다.
+
+회의 전 문서에서는 Android APK 배포, `tdc114plus-auth` 중계서버 배포, staging/production 분리, 블루/그린 배포 전략을 중심으로 검토했다.
+
+회의에서 추가로 확인된 큰 방향은 아래와 같다.
+
+- 앱 배포는 Cloudflare를 활용하는 방향으로 검토한다.
+- `tdc114plus-auth` 중계서버도 Cloudflare에서 관리하는 방향으로 검토한다.
+- Gitea와 Gitea Actions를 활용해 빌드/배포 자동화 흐름을 만든다.
+- 사용자는 도메인 접속만으로 APK 다운로드 또는 다운로드 안내 페이지에 접근할 수 있게 한다.
+- `114.hmac.kr`은 staging, `114.brsw.kr`은 production으로 본다.
+
+## 2. 회의 중 언급된 주요 단어
+
+회의 중 언급된 단어는 아래와 같다.
+
+- CI/CD
+- Gitea Actions
+- 결과물 다운로드 경로
+- 정적 페이지
+- 배포
+- 파이프라인
+- Gitea
+- 어떤 flow로 배포하겠다
+- WebAssembly 기반
+- Cloudflare
+- Cloudflare Workers 기반 변경
+- 앱 배포는 심플
+- 사용자가 도메인만 칠 때는 앱 APK가 다운로드되게
+- `114.hmac.kr`은 staging
+- `114.brsw.kr`은 production
+
+## 3. 단어별 해석
+
+### 3.1 CI/CD
+
+코드 변경 후 빌드, 산출물 생성, 배포까지 자동화하는 흐름을 의미하는 것으로 본다.
+
+즉 개발자가 매번 수동으로 APK를 빌드하고 전달하는 방식이 아니라, Git push 또는 tag 생성 후 자동으로 빌드/배포가 이어지는 구조를 의도한 것으로 해석된다.
+
+### 3.2 Gitea Actions
+
+Gitea 저장소에서 push, tag, release 같은 이벤트가 발생했을 때 자동 작업을 실행하는 기능이다.
+
+이번 회의 맥락에서는 아래 역할로 해석된다.
+
+- Flutter Android 앱 빌드
+- APK 또는 AAB 생성
+- 빌드 결과물 저장
+- Cloudflare 배포 또는 업로드 작업 실행
+
+### 3.3 결과물 다운로드 경로
+
+빌드된 APK를 사용자가 받을 수 있는 최종 URL을 의미한다.
+
+예상 예시는 아래와 같다.
+
+- staging: `https://114.hmac.kr`
+- production: `https://114.brsw.kr`
+- 직접 APK 경로: `https://114.hmac.kr/downloads/tdc114plus-staging.apk`
+- 직접 APK 경로: `https://114.brsw.kr/downloads/tdc114plus.apk`
+
+정확한 경로명은 Cloudflare 구성 방식과 파일 저장 위치가 정해진 뒤 확정한다.
+
+### 3.4 정적 페이지
+
+APK 다운로드 버튼, 버전 정보, 설치 안내, 변경 이력 등을 보여주는 단순 웹페이지를 의미하는 것으로 본다.
+
+사용자가 도메인에 접속했을 때 바로 APK 파일이 다운로드되게 할 수도 있지만, 운영상으로는 정적 안내 페이지를 먼저 보여주고 다운로드 버튼을 제공하는 방식도 가능하다.
+
+### 3.5 배포 파이프라인
+
+코드가 저장소에 올라간 뒤 사용자에게 전달 가능한 산출물이 나오기까지의 고정 절차를 의미한다.
+
+회의 의도를 반영하면 기본 흐름은 아래와 같다.
+
+```text
+개발자 코드 수정
+-> Gitea push 또는 release tag 생성
+-> Gitea Actions 실행
+-> Flutter Android APK 빌드
+-> 빌드 결과물 저장
+-> Cloudflare 업로드 또는 배포
+-> 사용자는 도메인 접속
+-> APK 다운로드 또는 설치 안내 확인
+```
+
+### 3.6 WebAssembly 기반
+
+이 표현은 Flutter Web 또는 향후 웹 실행 형태까지 염두에 둔 표현일 수 있다.
+
+다만 현재 신규앱의 1차 배포 대상은 Android APK이므로, WebAssembly 기반 배포는 아래처럼 분리해서 봐야 한다.
+
+- Android APK 배포: 현재 우선순위
+- Flutter Web/WebAssembly 기반 앱 제공: 후속 검토 가능성
+
+따라서 이 단어만으로 Android APK 대신 웹앱을 우선한다는 뜻으로 확정하면 안 된다.
+
+### 3.7 Cloudflare
+
+회의의 핵심 인프라 방향으로 보인다.
+
+현재 해석상 Cloudflare는 아래 역할을 담당할 수 있다.
+
+- 정적 다운로드 페이지 제공
+- APK 파일 다운로드 경로 제공
+- staging/production 도메인 라우팅
+- `tdc114plus-auth` API 또는 중계 기능 관리
+- Cloudflare Workers를 통한 요청 처리
+- 캐시, HTTPS, 접근 제어 등 운영 보조 기능 제공
+
+### 3.8 Cloudflare Workers 기반 변경
+
+단순 정적 파일 호스팅만이 아니라 Workers를 활용해 요청 흐름을 제어하려는 의도로 볼 수 있다.
+
+예상 가능한 역할은 아래와 같다.
+
+- `/` 접속 시 최신 APK 다운로드 페이지로 라우팅
+- `/download` 접속 시 최신 APK 파일로 redirect
+- staging/prod 도메인별 다른 APK 제공
+- 버전 정보 JSON 제공
+- User-Agent 기준 Android 사용자에게 설치 안내 제공
+- `tdc114plus-auth`가 담당하던 일부 중계 API를 Workers 기반으로 제공하거나, Workers가 별도 auth 서버 앞단 proxy 역할을 수행
+
+회의 후 추가 해석:
+
+- 팀장 의도는 `tdc114plus-auth`도 가능하면 Cloudflare Workers 쪽에서 직접 관리/실행하는 방향에 가까운 것으로 보인다.
+- 현재 Go 기반 `tdc114plus-auth`를 Cloudflare Workers에서 그대로 지원하는지 확인해야 한다.
+- 그대로 지원이 어렵다면 Workers에서 안정적으로 지원되는 언어로 중계서버를 변경하거나 재구현하는 방안도 검토 대상이다.
+
+## 4. 도출되는 팀장 의도
+
+회의에서 나온 단어를 종합하면, 의도는 아래처럼 정리된다.
+
+`Gitea에 코드가 올라가면 Gitea Actions가 자동으로 앱을 빌드하고, 결과 APK와 필요한 중계 기능을 Cloudflare 쪽에 배포하여 사용자가 도메인 접속만으로 다운로드하거나 앱 기능을 사용할 수 있게 한다.`
+
+즉 핵심은 아래 3가지다.
+
+1. 수동 APK 전달을 줄인다.
+2. 빌드와 배포 흐름을 Gitea Actions 중심으로 자동화한다.
+3. 사용자 접근 경로와 중계서버 운영 경로를 Cloudflare 도메인/Workers 중심으로 단순화한다.
+
+## 5. 예상 배포 구조
+
+현재 회의 결과 기준으로 예상되는 구조는 아래와 같다.
+
+```text
+tdc114plus Git 저장소
+  -> Gitea Actions
+    -> Flutter Android build
+    -> APK 산출물 생성
+    -> Cloudflare 업로드 또는 배포
+
+tdc114plus-auth Git 저장소
+  -> Gitea Actions
+    -> Cloudflare Workers 또는 Cloudflare 관리 런타임 배포
+    -> auth/profile/org-context 중계 기능 제공
+
+Cloudflare
+  -> 114.hmac.kr  : staging 앱 다운로드/안내
+  -> 114.brsw.kr  : production 앱 다운로드/안내
+  -> auth/API 경로 : tdc114plus-auth 중계 기능
+```
+
+## 6. staging / production 도메인 구분
+
+회의에서 언급된 기준은 아래와 같다.
+
+| 구분 | 도메인 | 용도 |
+| --- | --- | --- |
+| staging | `114.hmac.kr` | 내부 검증, 테스트 APK, 사전 배포 |
+| production | `114.brsw.kr` | 실제 운영 사용자 대상 APK |
+
+이 구분은 앱 다운로드 경로뿐 아니라 앱 내부 API base URL, auth 서버 base URL, org-context base URL과도 연결된다.
+
+따라서 APK 빌드 시점에 아래 값들이 환경별로 분리되어야 한다.
+
+- 앱 API base URL
+- auth broker base URL
+- org-context API base URL
+- 빌드 타입 또는 배포 채널명
+- 앱 버전/빌드번호
+
+## 7. 앱 배포와 서버 배포의 구분
+
+회의 내용 중 "앱 배포는 심플"이라는 표현은 Android APK 배포를 단순화하자는 뜻으로 해석된다.
+
+다만 `tdc114plus-auth` 서버/API 배포는 APK 배포와 역할이 다르므로 Cloudflare 안에서 함께 관리하더라도 구분해서 봐야 한다.
+
+구분하면 아래와 같다.
+
+| 대상 | 성격 | 배포 방식 |
+| --- | --- | --- |
+| `tdc114plus` APK | 사용자 휴대폰에 설치되는 앱 산출물 | Gitea Actions 빌드 후 Cloudflare 다운로드 제공 |
+| `tdc114plus-auth` | 로그인/조직도/프로필 이미지 중계 기능 | Cloudflare Workers 또는 Cloudflare 앞단 proxy/관리 런타임으로 배포 검토 |
+
+즉 Cloudflare 기반으로 두 대상을 모두 관리하더라도, 앱 APK 배포와 `tdc114plus-auth` API 배포는 서로 다른 파이프라인/검증 기준을 가져야 한다.
+
+## 7.1 `tdc114plus-auth`를 Cloudflare에서 관리한다는 의미
+
+회의 내용상 `tdc114plus-auth`도 Cloudflare에서 관리하자는 방향이 추가로 확인되었다.
+
+이 말은 최소한 아래 가능성을 포함한다.
+
+1. Cloudflare Workers로 `tdc114plus-auth` 기능을 직접 구현/배포한다.
+2. 기존 `tdc114plus-auth` 서버는 유지하되 Cloudflare Workers가 앞단 proxy 또는 routing 계층을 담당한다.
+3. Cloudflare Pages/Workers/R2 등을 조합해 앱 다운로드와 auth 중계를 같은 Cloudflare 운영 체계에서 관리한다.
+
+현재 바로 확정하면 안 되는 부분:
+
+- 현재 Go 기반 `tdc114plus-auth`를 Workers로 그대로 올릴 수 있는지
+- Workers가 네이버웍스 OAuth, Baron SSO 연동, RSA/JWT 처리, 외부 API 호출을 모두 안정적으로 감당할 수 있는지
+- Cloudflare에서 secret을 어떻게 관리할지
+- Workers가 아닌 별도 서버를 Cloudflare Tunnel 또는 proxy 뒤에 둘지
+
+따라서 현재 문서 기준으로는 아래처럼 정리한다.
+
+`tdc114plus-auth`도 Cloudflare 관리 대상에 포함한다. 다만 구현 방식은 Workers 직접 이식, Workers proxy, Cloudflare Tunnel/외부 서버 연동 중에서 별도 검토 후 확정한다.
+
+## 7.2 Cloudflare Workers가 현재 Go 기반 `tdc114plus-auth`를 그대로 지원하는지
+
+현재 판단은 아래와 같다.
+
+`Go 기반 tdc114plus-auth를 Cloudflare Workers에 그대로 올리는 것은 어렵거나 위험하다.`
+
+이유는 아래와 같다.
+
+- Cloudflare Workers의 기본 실행 모델은 일반적인 장기 실행 서버 프로세스가 아니다.
+- 현재 `tdc114plus-auth`는 Go의 `net/http` 서버로 `:5001` 포트를 열고 계속 떠 있는 구조다.
+- Workers는 `fetch(request, env, ctx)` 같은 요청 단위 실행 모델에 가깝다.
+- 현재 Go 서버는 `os.ReadFile()`로 RSA private/public key 파일을 읽는다.
+- Workers에서는 이런 파일 기반 secret 관리보다 Cloudflare Secrets/env 기반 관리가 필요하다.
+- 현재 Go 서버는 메모리 map으로 `pendingRef` 상태를 저장한다.
+- Workers에서는 인스턴스 메모리 지속성을 전제로 하면 안 되므로 KV, Durable Objects, D1 같은 외부 상태 저장소가 필요하다.
+
+정리하면 현재 구조는 아래처럼 바뀌어야 한다.
+
+```text
+현재 Go 서버 방식
+프로세스 실행
+-> :5001 listen
+-> 요청 처리
+-> 메모리 map 상태 저장
+-> 파일에서 RSA key 읽기
+
+Cloudflare Workers 방식
+fetch(request, env, ctx)
+-> 요청 처리
+-> Cloudflare Secrets에서 key/secret 읽기
+-> KV/Durable Object/D1 등에 pending 상태 저장
+```
+
+## 7.3 Cloudflare Workers 지원 언어 기준 검토
+
+Cloudflare Workers는 일반적으로 아래 언어/런타임이 주력 검토 대상이다.
+
+- JavaScript
+- TypeScript
+- Python
+- Rust
+- WebAssembly 기반 언어
+
+Go도 WebAssembly로 컴파일하면 일부 시나리오에서 가능성이 있을 수 있다.
+
+하지만 현재 `tdc114plus-auth`처럼 아래 기능을 가진 서버를 Go/Wasm으로 그대로 이식하는 것은 안정성 관점에서 신중해야 한다.
+
+- Baron SSO 외부 API 호출
+- NAVER WORKS OAuth/JWT/RSA 서명
+- 앱 세션 JWT 발급
+- org-context proxy
+- profile-image proxy
+- pending login 상태 저장
+- 파일 기반 RSA key 로딩
+- Go `net/http` 서버 실행
+
+따라서 현재 추천은 아래다.
+
+1. Go 그대로 Workers에 올리는 것은 1순위로 보지 않는다.
+2. Workers 직접 운영이 목표라면 TypeScript Workers 재구현을 우선 검토한다.
+3. Rust Workers는 성능과 타입 안정성 장점이 있지만 개발 난이도가 더 높다.
+4. Python Workers는 가능성을 검토할 수 있으나, 현재 Workers 생태계와 예제/운영 경험 면에서는 TypeScript가 더 무난하다.
+
+## 7.4 현재 `tdc114plus-auth` 기능별 Workers 이식 영향
+
+| 기능 | 현재 구현 | Workers 이식 시 검토 |
+| --- | --- | --- |
+| HTTP 서버 | Go `net/http`, `ListenAndServe(:5001)` | Workers `fetch()` 핸들러로 전환 필요 |
+| 로그인 시작 | Baron SSO headless/link API 호출 | `fetch()` 기반 외부 API 호출로 구현 가능 |
+| 로그인 poll | 메모리 map pending 상태 사용 | KV 또는 Durable Objects로 상태 저장 필요 |
+| 앱 세션 발급 | Go에서 JWT 생성/서명 | Web Crypto 또는 라이브러리로 재구현 필요 |
+| RSA key 관리 | 파일 경로에서 private/public key 읽기 | Cloudflare Secrets/env로 전환 필요 |
+| org-context proxy | Baron API Key로 외부 API 호출 | Workers에서 구현 가능하나 secret 관리 필요 |
+| NAVER WORKS 사진 | OAuth JWT bearer + photo redirect 처리 | Workers에서 구현 가능하나 RSA/JWT 처리 검증 필요 |
+| profile image fallback | R2/공개 이미지 URL 확인 | Workers에서 구현 가능 |
+| 로그 | Go log 출력 | Workers logs/observability 기준으로 전환 필요 |
+| health check | `/health` route | Workers route로 구현 가능 |
+
+## 7.5 가능한 전환 방식
+
+### 1안: Go 기반 `tdc114plus-auth`를 그대로 Workers에 올리기
+
+현재 기준 비추천이다.
+
+이유:
+
+- Workers 런타임과 Go 장기 실행 서버 모델이 다르다.
+- 파일 기반 key 로딩과 메모리 상태 저장 방식이 맞지 않는다.
+- Go/Wasm으로 가능하더라도 운영 안정성과 디버깅 난이도가 높을 수 있다.
+
+### 2안: TypeScript 기반 Cloudflare Workers로 재구현
+
+현재 가장 현실적인 검토안이다.
+
+장점:
+
+- Workers 기본 모델과 가장 잘 맞는다.
+- Cloudflare 문서와 예제가 많다.
+- Secrets, KV, Durable Objects, R2 연동이 자연스럽다.
+
+주의:
+
+- 기존 Go 서버의 인증/JWT/RSA 로직을 TypeScript로 재검증해야 한다.
+- 보안 로직이므로 단순 포팅이 아니라 테스트와 검증이 필요하다.
+
+### 3안: 기존 Go 서버 유지 + Cloudflare Workers/Tunnel/proxy 앞단 구성
+
+중간 단계로 검토 가능하다.
+
+장점:
+
+- 기존 Go 서버 코드를 크게 버리지 않아도 된다.
+- Cloudflare 도메인/보안/라우팅 체계는 사용할 수 있다.
+
+단점:
+
+- 팀장이 말한 "Workers에서 직접 관리" 의도와는 다를 수 있다.
+- 별도 서버 운영 부담이 남는다.
+
+## 7.6 현재 판단
+
+현재 회의 결과와 기술 제약을 함께 보면 아래처럼 정리한다.
+
+- `tdc114plus` 앱 배포는 Gitea Actions와 Cloudflare 조합으로 진행하는 방향이 타당하다.
+- `tdc114plus-auth`도 Cloudflare 관리 대상으로 보는 방향은 맞다.
+- 다만 현재 Go 기반 `tdc114plus-auth`를 Workers에 그대로 올리는 것은 1차 추천안이 아니다.
+- Workers 직접 운영을 목표로 한다면 TypeScript 기반 재구현 가능성을 우선 검토한다.
+- Go 서버를 유지하면서 Cloudflare를 앞단 proxy/Tunnel로 사용하는 방식은 단기 안전안으로 검토할 수 있다.
+- 최종 결정 전에는 Workers 지원 범위, secret 관리, 상태 저장소, JWT/RSA 구현 가능성을 작은 PoC로 확인해야 한다.
+
+## 8. 우선 검토해야 할 항목
+
+Cloudflare 기반 배포를 실제로 진행하려면 아래 항목을 먼저 확인해야 한다.
+
+1. Gitea Actions 사용 가능 여부
+2. Gitea Runner 설치 여부
+3. Flutter Android 빌드가 runner에서 가능한지
+4. APK 서명 방식
+5. staging/prod 빌드 환경변수 분리 방식
+6. Cloudflare 배포 대상
+7. Cloudflare Workers 사용 여부
+8. APK 파일 저장 위치
+9. 사용자가 도메인 접속 시 바로 다운로드할지, 안내 페이지를 보여줄지
+10. production APK 배포 승인 절차
+11. `tdc114plus-auth`를 Workers로 직접 이식할지, 기존 서버 앞단 proxy로 둘지
+12. Cloudflare에서 `tdc114plus-auth` secret을 어떻게 관리할지
+13. Workers 환경에서 네이버웍스/Baron SSO 연동이 가능한지
+14. `tdc114plus-auth` 배포 rollback 방식
+15. 현재 Go 구현을 유지할지, TypeScript Workers로 재구현할지
+16. pending login 상태 저장소로 KV와 Durable Objects 중 무엇을 사용할지
+17. Workers 기반 PoC 범위를 어디까지 잡을지
+
+## 9. 다음 작업 제안
+
+다음 작업은 아래 순서로 진행하는 것이 안전하다.
+
+1. 현재 문서에 Cloudflare 기반 앱 배포 방향을 반영한다.
+2. Gitea Actions 기준 Android APK 빌드 파이프라인 초안을 작성한다.
+3. staging/prod별 빌드 산출물 경로를 설계한다.
+4. Cloudflare Workers 또는 정적 페이지 배포 방식을 비교한다.
+5. `tdc114plus-auth`를 Cloudflare Workers로 이식할지, Workers proxy로 둘지 비교한다.
+6. `114.hmac.kr`, `114.brsw.kr` 도메인의 실제 연결 가능 여부를 확인한다.
+7. APK 서명/버전/릴리스 태그 정책을 정리한다.
+8. `tdc114plus-auth`의 Cloudflare secret, health check, rollback 정책을 정리한다.
+9. TypeScript Workers 기반 최소 PoC 범위를 정한다.
+10. PoC에서 `/health`, `/api/v1/auth/link/init`, `/api/v1/auth/link/poll`, `/api/v1/profile-image` 중 어떤 route를 먼저 검증할지 정한다.
+
+## 10. 현재 결론
+
+2026-07-20 회의 결과 기준으로, 신규앱 APK 배포는 아래 방향으로 정리한다.
+
+- 소스 기준점은 Gitea 저장소다.
+- 자동화 실행 주체는 Gitea Actions다.
+- 빌드 결과물은 APK를 1차 대상으로 본다.
+- 앱 다운로드 제공은 Cloudflare를 사용한다.
+- `tdc114plus-auth` 중계 기능도 Cloudflare 관리 대상으로 본다.
+- 현재 Go 기반 `tdc114plus-auth`를 Workers에 그대로 올리는 것은 위험하므로, TypeScript Workers 재구현 또는 Workers proxy/Tunnel 방식을 비교한다.
+- `114.hmac.kr`은 staging 다운로드 경로로 본다.
+- `114.brsw.kr`은 production 다운로드 경로로 본다.
+- 사용자는 도메인 접속만으로 APK 다운로드 또는 다운로드 안내 페이지에 접근할 수 있어야 한다.
+
+단, 앱 APK 배포와 `tdc114plus-auth` 중계 기능 배포는 Cloudflare 안에서 함께 관리하더라도 서로 다른 산출물과 검증 절차를 가진다.
@@ -303,3 +303,106 @@ Baron SSO 개발자에게 전달할 핵심은 아래였다.
 ## 한 줄 요약

 2026-07-20 기준 로그인 막힘의 핵심은 `앱이 요청을 못 보내는 문제`가 아니라 `요청은 정상인데 실제 문자 링크가 사용자에게 도착하지 않는 문제`다.
+
+## 2026-07-20 오후 최종 안정화 결과
+
+오전 인계 시점 이후 Baron SSO 문자 링크 흐름과 `tdc114plus-auth` 중계 흐름을 재점검했고, 최종적으로 실기기 기준 정상 진입을 확인했다.
+
+최종 확인된 내용:
+
+- 실기기에서 로그인 링크 발송 성공
+- 문자 링크 수신 및 승인 성공
+- 승인 후 앱 진입 성공
+- 직원검색 목록 표시 정상
+- 조직도 표시 정상
+- 즐겨찾기 표시 정상
+- 직원 상세 진입 정상
+- 화면 전환 후 목록/이미지 재표시 정상
+
+## 2026-07-20 프로필 사진 최종 검증 결과
+
+프로필 사진 우선순위는 아래 정책으로 확정하고 실기기에서 확인했다.
+
+1. `NAVER_WORKS`
+2. `BARON_UUID_R2`
+3. `DEFAULT`
+
+최종 확인된 대표 사용자:
+
+| 우선순위 | source | 사용자 | 확인 결과 |
+| --- | --- | --- | --- |
+| 1순위 | `NAVER_WORKS` | 한치영 / 이태훈 | 네이버웍스 프로필 사진 표시 정상 |
+| 2순위 | `BARON_UUID_R2` | 문형석 등 | UUID 파일명 기반 이미지 표시 정상 |
+| 3순위 | `DEFAULT` | 강버들 | 앱 기본 아바타 fallback 정상 |
+
+중요 정리:
+
+- 네이버웍스 사진이 있는 사용자는 1순위로 네이버웍스 사진을 사용한다.
+- 네이버웍스 사진이 없고 UUID 이미지가 있으면 `https://baroncs.co.kr/employee_img/{uuid}.jpg` 경로를 사용한다.
+- 둘 다 없으면 앱 기본 아바타로 자연스럽게 fallback 된다.
+
+## 2026-07-20 코드/문서 커밋 및 push 결과
+
+오늘 안정화된 변경은 두 저장소에 로컬 커밋 후 Gitea `origin/main`으로 push 완료했다.
+
+`tdc114plus`:
+
+- `5d3eee7 Stabilize auth flow and profile images`
+- `cb36612 Move external secrets behind auth broker`
+- `a0d393e docs: expand auth deployment guidance`
+- `a869231 docs: clarify auth deployment boundaries`
+
+`tdc114plus-auth`:
+
+- `4e97ef8 Stabilize auth broker and profile image proxy`
+- `0e448bd Document broker-managed external secrets`
+
+정리:
+
+- 앱 쪽 Baron API Key 직접 관리 제거 완료
+- 외부 secret은 `tdc114plus-auth` 중계서버에서 관리하는 방향으로 정리
+- PostgreSQL 프로필 이미지 매핑안은 폐기
+- `tdc114plus-auth`의 PostgreSQL 잔여 파일(`go.sum`, `db/profile_image_mapping.sql`, 빈 `db/`) 삭제 완료
+
+## 2026-07-20 배포 회의 문서 정리 결과
+
+배포 준비 회의용 문서를 정리했다.
+
+주요 문서:
+
+- `docs/00_guide_tdc114plus_android_release_meeting_2026-07-20.md`
+- `docs/00_meeting_onepage_tdc114plus_release_2026-07-20.md`
+- `docs/00_meeting_onepage_tdc114plus_release_2026-07-20.print.html`
+- `docs/00_meeting_onepage_tdc114plus_release_2026-07-20.pdf`
+
+문서 기준 현재 방향:
+
+- 신규앱은 `staging -> 내부 검증 -> production` 순서로 배포한다.
+- 최종 배포 직접 대상은 `tdc114plus` 앱과 `tdc114plus-auth` 서버다.
+- `tdc114plus-auth`는 Baron SSO 본체에 흡수하지 않고 독립 서비스로 유지한다.
+- 초기에는 Baron 계열 운영 인프라 안의 독립 서비스로 배치할 수 있다.
+- 서버 배포 전략은 rollback이 쉬운 블루/그린을 1순위로 본다.
+
+## 다음 작업 시작 시 우선 순서
+
+1. 업무시작 기동 전에 두 저장소 `git status` 확인
+2. `tdc114plus-auth` 5001 또는 staging auth endpoint health 확인
+3. 실기기 `adb reverse --list` 확인
+4. 로그인 링크 발송, 문자 수신, 승인 후 앱 진입 확인
+5. 직원검색/조직도/즐겨찾기/상세 화면 회귀 확인
+6. 프로필 사진 1순위/2순위/3순위 대표 사용자 재확인
+7. 배포 준비 단계로 이동하기 전, 회의 문서와 실제 서버 배포 체크리스트 정합성 확인
+
+## 퇴근 전 종료 기동 점검 결과
+
+종료 스크립트 점검 결과:
+
+- `bash -n scripts/shutdown.sh` 통과
+- `./scripts/shutdown.sh --dry-run` 통과
+- dry-run 기준 종료 대상은 helper 프로세스, 5001 listener, ADB disconnect 조건 확인, Baron SSO compose 로그 수집, compose down, 권한 복구 순서다.
+
+주의:
+
+- `scripts/shutdown.sh --auto`는 `/home/ubuntu/workspace/baron-sso-tdc114plus-api` Docker compose down을 포함한다.
+- 물리 실기기 USB reverse는 `TDC114_ADB_CONNECT_ADDRESS`가 없으면 임의 disconnect하지 않는다.
+- 다음날 업무시작 시 `docs/checklist_morning_startup_runtime_2026-07-03.md` 기준으로 재기동한다.
@@ -0,0 +1,181 @@
+# 2026-07-21 업무 인계 메모
+
+작성 시각: 2026-07-21 KST
+
+## 오늘 핵심 결론
+
+- 전일 종료 후 금일 업무시작 기동을 수행했다.
+- Android 실기기/ADB reverse는 오전 중 재설정하여 정상 상태를 확인했다.
+- Baron/Ory runtime, `tdc114plus-auth` 5001, API smoke는 정상 확인했다.
+- 신규앱 실기기 로그상 로그인, 앱 세션 발급, 직원검색, 조직도, 프로필 이미지 호출 흐름이 정상 기록되었다.
+- 배포 회의 결과에 따라 `tdc114plus`와 `tdc114plus-auth` 모두 Cloudflare 관리 체계로 가져가는 방향을 문서화했다.
+
+## 1. 금일 업무시작 기동 결과
+
+업무시작 시 아래 순서로 확인했다.
+
+1. 전일 인계 문서 확인
+2. `startup.sh` 문법 및 dry-run 확인
+3. Windows ADB 서버 및 실기기 상태 확인
+4. 실기기 `adb reverse tcp:5000`, `tcp:5001` 재설정
+5. Baron/Ory runtime 기동
+6. `tdc114plus-auth` 재기동
+7. `check-baron-api-env.sh` 확인
+8. `api-smoke.sh` 확인
+
+정상 확인 결과:
+
+- `tdc114plus`, `tdc114plus-auth` 작업트리 깨끗한 상태에서 시작
+- 실기기 `R5CT42QTCNX` 연결 확인
+- `adb reverse tcp:5000 tcp:5000` 설정
+- `adb reverse tcp:5001 tcp:5001` 설정
+- Baron/Ory 컨테이너 health 정상
+- `tdc114plus-auth` health 정상
+
+`tdc114plus-auth` health 응답:
+
+```json
+{"jwks":"ok","provider":"baron","status":"ok"}
+```
+
+## 2. 업무시작 중 발생한 이슈
+
+### 2.1 Android preflight 첫 실패
+
+처음 `startup.sh --dry-run` 실행 시 WSL에서 Windows ADB 서버 `172.21.128.1:5037` 접근이 막혀 실패했다.
+
+이후 승인 권한으로 다시 확인했으나 `Connection reset by peer`가 발생했다.
+
+처리:
+
+- Windows PowerShell에서 `adb.exe devices` 확인
+- 실기기 `R5CT42QTCNX device` 상태 확인
+- 오프라인 emulator가 여러 개 있었으나 실기기 기준으로 `-s R5CT42QTCNX`를 지정해 reverse 재설정
+
+결과:
+
+```text
+UsbFfs tcp:5000 tcp:5000
+UsbFfs tcp:5001 tcp:5001
+```
+
+### 2.2 `tdc114plus-auth` 첫 startup 실패
+
+`startup.sh --auto` 중 `tdc114plus-auth` health 대기에서 한 번 실패했다.
+
+로그상 `tdc114plus-auth listening on :5001`까지 찍힌 뒤 프로세스가 종료되었고, 이후 `start-auth-server.sh --restart`로 재기동했다.
+
+결과:
+
+- `tdc114plus-auth ready on :5001`
+- `/health` 정상
+
+판단:
+
+- 소스 오류보다는 첫 기동/컴파일/프로세스 타이밍 문제에 가까웠다.
+- 재기동 후 정상 동작했다.
+
+## 3. 실기기 앱 동작 확인 기록
+
+금일 로그 기준 신규앱은 실제로 아래 흐름을 정상 수행했다.
+
+- `POST /api/v1/auth/link/init`
+- `POST /api/v1/auth/link/poll`
+- Baron SSO 승인 완료
+- 앱 세션 발급
+- 사용자 메타데이터 보강
+- org-context 조회
+- profile-image 조회
+
+로그상 확인된 사용자:
+
+- 문형석
+- `tenant_slug=is-3`
+- `tenant_name=IS3`
+
+프로필 이미지 source 확인:
+
+- `NAVER_WORKS`
+- `BARON_UUID_R2`
+
+즉 서버 로그 기준으로는 로그인, 직원검색, 조직도, 프로필 이미지 흐름이 정상 동작했다.
+
+## 4. 실기기 USB 연결 관련 정리
+
+금일 확인한 중요한 정리:
+
+- 실제 운영/배포 APK가 동작하는 데 USB 연결은 필요 없다.
+- USB가 필요한 이유는 현재 개발용 APK가 `127.0.0.1:5000`, `127.0.0.1:5001`을 바라보기 때문이다.
+- 로컬 테스트에서는 실기기 앱 호출을 개발 PC 로컬 서버로 보내기 위해 `adb reverse`가 필요하다.
+- Cloudflare/staging/production 도메인을 바라보는 APK는 USB 없이 동작해야 한다.
+
+정리:
+
+```text
+개발 로컬 테스트: USB + adb reverse 필요
+실제 배포 APK: USB 불필요
+Cloudflare 도메인 기반 APK: USB 불필요
+```
+
+## 5. 신규앱 배포 회의 결과 정리
+
+2026-07-20 팀장 회의 결과를 금일 문서로 정리했다.
+
+문서:
+
+- `docs/00_meeting_result_tdc114plus_release_2026-07-20.md`
+
+팀장 확인 완료 기준 이해 내용:
+
+1. 신규앱 `tdc114plus`와 중계서버 `tdc114plus-auth` 모두 Cloudflare 관리 체계 안에서 운영한다.
+2. `tdc114plus`는 Gitea에 코드가 올라가면 Gitea Actions로 APK를 자동 빌드하고, 결과물을 Cloudflare에 배포한다.
+3. `114.hmac.kr`은 staging용 앱 다운로드 및 검증 경로로 사용한다.
+4. `114.brsw.kr`은 production용 앱 다운로드 경로로 사용한다.
+5. 사용자는 도메인 접속만으로 APK 다운로드 또는 설치 안내 페이지에 접근한다.
+6. `tdc114plus-auth`도 Cloudflare Workers 쪽에서 운영하는 방향으로 검토한다.
+7. 현재 `tdc114plus-auth`는 Go 기반 서버이므로 Workers에 그대로 올릴 수 있는지 기술 검토가 필요하다.
+8. Go 기반 운영이 어렵거나 안정성이 낮다면 TypeScript 등 Workers 지원 언어로 재구현을 검토한다.
+9. 검토 결과를 기준으로 `Go 유지 + Cloudflare proxy/Tunnel 방식`과 `Workers 지원 언어 재구현 방식` 중 안정적인 방향을 비교 제안한다.
+
+## 6. Cloudflare Workers 검토 기준
+
+현재 판단:
+
+- Go 기반 `tdc114plus-auth`를 Cloudflare Workers에 그대로 올리는 것은 어렵거나 위험할 수 있다.
+- Workers 직접 운영이 목표라면 TypeScript Workers 재구현을 우선 검토한다.
+- 단기 안전안으로 기존 Go 서버 유지 + Cloudflare Workers/Tunnel/proxy 앞단 구성도 비교한다.
+
+검토해야 할 항목:
+
+- Workers 지원 언어와 런타임 제약
+- Baron SSO 외부 API 호출 가능 여부
+- NAVER WORKS OAuth/JWT/RSA 처리 가능 여부
+- 앱 세션 JWT 발급 방식
+- pending login 상태 저장소 선택
+- Cloudflare Secrets 관리
+- health check와 rollback 방식
+
+## 7. 다음 작업 시작 시 우선 순서
+
+1. 두 저장소 `git status` 확인
+2. 오늘 작성한 회의결과 문서가 원격에 push되었는지 확인
+3. Cloudflare Workers 지원 범위 공식 문서 확인
+4. `tdc114plus-auth` 기능별 Workers 이식 가능성 표를 더 세분화
+5. TypeScript Workers PoC 범위 확정
+6. Gitea Actions 기반 APK 빌드/Cloudflare 배포 파이프라인 초안 작성
+7. `114.hmac.kr`, `114.brsw.kr`의 staging/production 경로 정책 정리
+
+## 8. 퇴근 전 종료 기동 대상
+
+종료 전 확인할 것:
+
+- `tdc114plus` 변경분 커밋/push
+- `tdc114plus-auth` 변경분 여부 확인
+- `scripts/shutdown.sh` 문법 확인
+- `scripts/shutdown.sh --dry-run` 확인
+- 실제 종료 기동 `scripts/shutdown.sh --auto`
+
+주의:
+
+- 종료 스크립트는 `baron-sso-tdc114plus-api` Docker compose down을 포함한다.
+- 실기기 USB reverse는 명시적 Android connect address가 없으면 임의 disconnect하지 않는다.
Author	SHA1	Message	Date
Codex	6610314548	docs: record cloudflare deployment meeting result	2026-07-21 13:38:24 +09:00
Codex	3cea502619	docs: record release meeting handoff	2026-07-20 16:19:37 +09:00
Codex	a8692319d5	docs: clarify auth deployment boundaries	2026-07-20 15:11:27 +09:00