6.5 KiB
6.5 KiB
2026-07-21 업무 인계 메모
작성 시각: 2026-07-21 KST
오늘 핵심 결론
- 전일 종료 후 금일 업무시작 기동을 수행했다.
- Android 실기기/ADB reverse는 오전 중 재설정하여 정상 상태를 확인했다.
- Baron/Ory runtime,
tdc114plus-auth5001, API smoke는 정상 확인했다. - 신규앱 실기기 로그상 로그인, 앱 세션 발급, 직원검색, 조직도, 프로필 이미지 호출 흐름이 정상 기록되었다.
- 배포 회의 결과에 따라
tdc114plus와tdc114plus-auth모두 Cloudflare 관리 체계로 가져가는 방향을 문서화했다.
1. 금일 업무시작 기동 결과
업무시작 시 아래 순서로 확인했다.
- 전일 인계 문서 확인
startup.sh문법 및 dry-run 확인- Windows ADB 서버 및 실기기 상태 확인
- 실기기
adb reverse tcp:5000,tcp:5001재설정 - Baron/Ory runtime 기동
tdc114plus-auth재기동check-baron-api-env.sh확인api-smoke.sh확인
정상 확인 결과:
tdc114plus,tdc114plus-auth작업트리 깨끗한 상태에서 시작- 실기기
R5CT42QTCNX연결 확인 adb reverse tcp:5000 tcp:5000설정adb reverse tcp:5001 tcp:5001설정- Baron/Ory 컨테이너 health 정상
tdc114plus-authhealth 정상
tdc114plus-auth health 응답:
{"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 재설정
결과:
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/initPOST /api/v1/auth/link/poll- Baron SSO 승인 완료
- 앱 세션 발급
- 사용자 메타데이터 보강
- org-context 조회
- profile-image 조회
로그상 확인된 사용자:
- 문형석
tenant_slug=is-3tenant_name=IS3
프로필 이미지 source 확인:
NAVER_WORKSBARON_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 없이 동작해야 한다.
정리:
개발 로컬 테스트: USB + adb reverse 필요
실제 배포 APK: USB 불필요
Cloudflare 도메인 기반 APK: USB 불필요
5. 신규앱 배포 회의 결과 정리
2026-07-20 팀장 회의 결과를 금일 문서로 정리했다.
문서:
docs/00_meeting_result_tdc114plus_release_2026-07-20.md
팀장 확인 완료 기준 이해 내용:
- 신규앱
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 기반 서버이므로 Workers에 그대로 올릴 수 있는지 기술 검토가 필요하다. - Go 기반 운영이 어렵거나 안정성이 낮다면 TypeScript 등 Workers 지원 언어로 재구현을 검토한다.
- 검토 결과를 기준으로
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. 다음 작업 시작 시 우선 순서
- 두 저장소
git status확인 - 오늘 작성한 회의결과 문서가 원격에 push되었는지 확인
- Cloudflare Workers 지원 범위 공식 문서 확인
tdc114plus-auth기능별 Workers 이식 가능성 표를 더 세분화- TypeScript Workers PoC 범위 확정
- Gitea Actions 기반 APK 빌드/Cloudflare 배포 파이프라인 초안 작성
114.hmac.kr,114.brsw.kr의 staging/production 경로 정책 정리
8. 퇴근 전 종료 기동 대상
종료 전 확인할 것:
tdc114plus변경분 커밋/pushtdc114plus-auth변경분 여부 확인scripts/shutdown.sh문법 확인scripts/shutdown.sh --dry-run확인- 실제 종료 기동
scripts/shutdown.sh --auto
주의:
- 종료 스크립트는
baron-sso-tdc114plus-apiDocker compose down을 포함한다. - 실기기 USB reverse는 명시적 Android connect address가 없으면 임의 disconnect하지 않는다.