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

docs: record cloudflare deployment meeting result

Browse Source
This commit is contained in:
Codex
2026-07-21 13:38:24 +09:00
parent 3cea502619
commit 6610314548
2 changed files with 612 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/00_meeting_result_tdc114plus_release_2026-07-20.md
+431
View File
@@ -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 안에서 함께 관리하더라도 서로 다른 산출물과 검증 절차를 가진다.
docs/daily-issues/2026-07-21_work_handoff.md
+181
View File
@@ -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하지 않는다.