kevin/tdc114plus
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: record release meeting handoff

Browse Source
This commit is contained in:
Codex
2026-07-20 16:19:37 +09:00
parent a8692319d5
commit 3cea502619
4 changed files with 508 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/00_meeting_onepage_tdc114plus_release_2026-07-20.print.html
+264
View File
@@ -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>