kevin/tdc114plus

Fork 0

Files

T

Codex 6610314548 docs: record cloudflare deployment meeting result

2026-07-21 13:38:24 +09:00

19 KiB

Raw Blame History

tdc114plus 신규앱 배포 회의 결과 정리

작성일: 2026-07-21 회의일: 2026-07-20 상태: 회의 결과 초안

0. 팀장 확인 완료 내용

아래 내용은 2026-07-21 팀장 확인 완료 기준으로 정리한다.

신규앱 tdc114plus와 중계서버 tdc114plus-auth 모두 Cloudflare 관리 체계 안에서 운영한다.
tdc114plus는 Gitea에 코드가 올라가면 Gitea Actions로 APK를 자동 빌드하고, 결과물을 Cloudflare에 배포하는 흐름으로 진행한다.
114.hmac.kr은 staging용 앱 다운로드 및 검증 경로, 114.brsw.kr은 production용 앱 다운로드 경로로 진행한다.
사용자는 별도 복잡한 절차 없이 도메인에 접속하여 APK를 다운로드하거나 설치 안내 페이지에 접근하는 방식으로 진행한다.
tdc114plus-auth도 Cloudflare Workers 쪽에서 운영하는 방향으로 검토한다.
다만 현재 tdc114plus-auth는 Go 기반 서버이므로 Cloudflare Workers에 그대로 올릴 수 있는지 기술 검토가 필요하다.
Go 기반 서버를 그대로 Workers에서 운영하기 어렵거나 안정성이 낮다면, TypeScript 등 Workers 지원 언어로 재구현하는 방안을 검토한다.
우선 현재 tdc114plus-auth의 인증, 조직도, 프로필사진 중계 기능이 Cloudflare Workers 환경에서 지원 가능한지 PoC 수준으로 확인한다.
검토 결과를 기준으로 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 배포 파이프라인

코드가 저장소에 올라간 뒤 사용자에게 전달 가능한 산출물이 나오기까지의 고정 절차를 의미한다.

회의 의도를 반영하면 기본 흐름은 아래와 같다.

개발자 코드 수정
-> 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가지다.

수동 APK 전달을 줄인다.
빌드와 배포 흐름을 Gitea Actions 중심으로 자동화한다.
사용자 접근 경로와 중계서버 운영 경로를 Cloudflare 도메인/Workers 중심으로 단순화한다.

5. 예상 배포 구조

현재 회의 결과 기준으로 예상되는 구조는 아래와 같다.

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에서 관리하자는 방향이 추가로 확인되었다.

이 말은 최소한 아래 가능성을 포함한다.

Cloudflare Workers로 tdc114plus-auth 기능을 직접 구현/배포한다.
기존 tdc114plus-auth 서버는 유지하되 Cloudflare Workers가 앞단 proxy 또는 routing 계층을 담당한다.
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 같은 외부 상태 저장소가 필요하다.

정리하면 현재 구조는 아래처럼 바뀌어야 한다.

현재 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 서버 실행

따라서 현재 추천은 아래다.

Go 그대로 Workers에 올리는 것은 1순위로 보지 않는다.
Workers 직접 운영이 목표라면 TypeScript Workers 재구현을 우선 검토한다.
Rust Workers는 성능과 타입 안정성 장점이 있지만 개발 난이도가 더 높다.
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 기반 배포를 실제로 진행하려면 아래 항목을 먼저 확인해야 한다.

Gitea Actions 사용 가능 여부
Gitea Runner 설치 여부
Flutter Android 빌드가 runner에서 가능한지
APK 서명 방식
staging/prod 빌드 환경변수 분리 방식
Cloudflare 배포 대상
Cloudflare Workers 사용 여부
APK 파일 저장 위치
사용자가 도메인 접속 시 바로 다운로드할지, 안내 페이지를 보여줄지
production APK 배포 승인 절차
tdc114plus-auth를 Workers로 직접 이식할지, 기존 서버 앞단 proxy로 둘지
Cloudflare에서 tdc114plus-auth secret을 어떻게 관리할지
Workers 환경에서 네이버웍스/Baron SSO 연동이 가능한지
tdc114plus-auth 배포 rollback 방식
현재 Go 구현을 유지할지, TypeScript Workers로 재구현할지
pending login 상태 저장소로 KV와 Durable Objects 중 무엇을 사용할지
Workers 기반 PoC 범위를 어디까지 잡을지

9. 다음 작업 제안

다음 작업은 아래 순서로 진행하는 것이 안전하다.

현재 문서에 Cloudflare 기반 앱 배포 방향을 반영한다.
Gitea Actions 기준 Android APK 빌드 파이프라인 초안을 작성한다.
staging/prod별 빌드 산출물 경로를 설계한다.
Cloudflare Workers 또는 정적 페이지 배포 방식을 비교한다.
tdc114plus-auth를 Cloudflare Workers로 이식할지, Workers proxy로 둘지 비교한다.
114.hmac.kr, 114.brsw.kr 도메인의 실제 연결 가능 여부를 확인한다.
APK 서명/버전/릴리스 태그 정책을 정리한다.
tdc114plus-auth의 Cloudflare secret, health check, rollback 정책을 정리한다.
TypeScript Workers 기반 최소 PoC 범위를 정한다.
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 안에서 함께 관리하더라도 서로 다른 산출물과 검증 절차를 가진다.

19 KiB Raw Blame History