docs: record release meeting handoff
This commit is contained in:
Codex
@@ -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순위로 제안합니다.
|
||||||
|
```
|
||||||
Binary file not shown.
@@ -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 -> 내부 검증 -> 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>
|
||||||
@@ -303,3 +303,106 @@ Baron SSO 개발자에게 전달할 핵심은 아래였다.
|
|||||||
## 한 줄 요약
|
## 한 줄 요약
|
||||||
|
|
||||||
2026-07-20 기준 로그인 막힘의 핵심은 `앱이 요청을 못 보내는 문제`가 아니라 `요청은 정상인데 실제 문자 링크가 사용자에게 도착하지 않는 문제`다.
|
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` 기준으로 재기동한다.
|
||||||
|
|||||||
Reference in New Issue
Block a user