kevin/tdc114plus

Fork 0

Files

T

Codex 3cea502619 docs: record release meeting handoff

2026-07-20 16:19:37 +09:00

15 KiB

Raw Permalink Blame History

2026-07-20 업무 인계 메모

작성 시각: 2026-07-20 KST

오늘 핵심 결론

tdc114plus 앱과 로컬 tdc114plus-auth:5001 연결은 정상 확인했다.
실기기 adb reverse tcp:5001 tcp:5001도 정상 확인했다.
앱에서 link/init 호출 후 pendingRef 생성, 이후 link/poll 반복까지 서버 로그로 확인했다.
즉 오늘 로그인 막힘의 핵심은 앱 <-> 로컬 중계서버 구간이 아니라 Baron SSO 문자 링크 실제 발송/SMS 연계 구간으로 판단했다.

오늘 확인한 최종 상태

1. 로컬 auth broker 상태

정상 확인값:

curl -i --max-time 5 http://127.0.0.1:5001/health

응답:

{"jwks":"ok","provider":"baron","status":"ok"}

의미:

로컬 tdc114plus-auth 5001은 떠 있었다.
최소한 health 기준으로는 죽어 있지 않았다.

2. 실기기 reverse 상태

사용자 확인 결과:

adb reverse --list
UsbFfs tcp:5001 tcp:5001

의미:

실기기에서 127.0.0.1:5001로 가는 호출은 PC 로컬 5001로 붙는 상태였다.
따라서 실기기에서 auth broker 접속이 안 되는 상태는 아니었다.

3. 앱이 실제로 5001에 요청을 보내는지 확인

서버 로그에서 아래를 직접 확인했다.

linkInit body={"phoneNumber":"01091365338","device":{"platform":"android","appVersion":"0.1.0","deviceName":"android"}}

그리고 이어서:

POST /api/v1/auth/link/init
POST /api/v1/auth/link/poll

반복 확인했다.

의미:

앱에서 로그인 버튼을 눌렀을 때 요청이 실제로 로컬 auth broker까지 도달했다.
pendingRef 생성도 정상 진행됐다.

4. 앱 내부 pending 상태 저장 확인

실기기 SharedPreferences에서 아래 항목을 직접 확인했다.

flutter.tdc114plus.auth.pending.ref
flutter.tdc114plus.auth.pending.expiresAt

의미:

앱이 로그인 요청 직후 pending 상태를 저장하지 못하는 문제는 아니었다.
앱 내부 상태 저장까지는 정상으로 봐도 된다.

오늘 발생한 실제 장애

현상:

앱에서는 승인 대기 중 화면으로 넘어간다.
하지만 사용자 휴대폰에는 실제 문자 링크가 도착하지 않는다.
재전송 시도 후에도 동일하다.

중요 판단:

앱 요청 실패 아님
로컬 auth broker 연결 실패 아님
adb reverse 누락 문제 아님
현재 가장 의심되는 구간은 Baron SSO 쪽 문자 링크 실제 발송 처리 또는 그 뒤 SMS 연계 구간이다.

오늘 중간에 있었던 혼선 정리

1. `auth_provider_unavailable`

한 시점에는 앱에 아래 문구가 보였다.

로그인 링크 요청 실패: auth_provider_unavailable

이때 직접 확인한 사실:

같은 시각 sso.hmac.kr /oidc/oauth2/auth가 502 Bad Gateway를 반환하던 구간이 있었다.
이후 재확인 시 다시 302 Location: /login?login_challenge=...로 정상 응답했다.

의미:

Baron SSO upstream authorization 시작점이 한때 불안정했다.
하지만 이후 복구된 뒤에도 최종적으로는 문자 미수신 문제가 남았다.

2. callback URL 혼선

아래 주소는 현재 직접 열면 404 page not found가 보인다.

https://114-auth.hmac.kr/api/v1/auth/oidc/callback

정리:

이 URL은 브라우저에서 직접 여는 진입 URL이 아니라 OIDC 최종 code 수신용 callback 경로다.
현재 문자 미수신 문제의 직접 원인으로 확정한 상태는 아니다.
다만 라우트 정합성은 후속 점검 대상으로 계속 유지한다.

오늘 외부 전달용 요약

Baron SSO 개발자에게 전달할 핵심은 아래였다.

- 신규앱 -> 로컬 tdc114plus-auth(5001) 요청 정상
- adb reverse 정상
- auth 서버 로그상 link/init, pendingRef 생성, link/poll 반복 정상
- 그런데 실제 문자 링크가 사용자 휴대폰에 도착하지 않음
- 따라서 Baron SSO 쪽 문자 링크 실제 발송 처리 또는 SMS 연계 구간 확인 필요

오늘 기준 남아 있는 작업

1. 문자 미수신 이슈 답변 대기

Baron SSO 개발자 확인 결과를 받아야 한다.
그 전까지는 앱/로컬 중계서버 쪽에서 더 고쳐도 문자 미수신 문제를 끝낼 수 없다.

2. 프로필 사진 route 상태 정리

현재 확인 상태:

앱은 /api/v1/profile-image를 먼저 시도한다.
하지만 현재 5001 서버는 해당 route에 404를 반환한다.

의미:

사진 1순위/2순위/3순위 실기기 검증은 아직 시작 조건이 완전히 갖춰지지 않았다.

3. 로그인 화면 상태 문구 정리

관찰된 화면:

실패 문구
승인 대기 박스
재전송 카운트

이 조합이 시점별로 다르게 보였다.

후속 과제:

요청 시작 시 이전 에러 문구를 항상 지우는지
pending 복원 시 에러 상태를 같이 끌고 오지 않는지
문자 미수신과는 별개로 화면 상태 표현이 꼬이지 않는지

외부 답변 대기 중 내부 진행 순서

문자 발송 구간 답변이 오기 전에도 아래 순서로는 내부 작업을 진행할 수 있다.

tdc114plus-auth 응답 메타데이터 정합성 재확인
- tenantSlug, tenantId, tenantName, department, grade, position, jobTitle
- 앱이 실제로 어떤 필드를 저장하고 소비하는지 확인
로그인 화면 상태 표현 정리
- 실패 문구와 승인 대기 UI가 동시에 남지 않도록 정리
- pending 복원 시 문구 초기화 조건 확인
/api/v1/profile-image route 복구 준비
- 현재 앱 호출 형식 고정
- auth 서버 route 부재 상태 문서화
- 복구 시 필요한 응답 형태 확정
프로필 사진 검증 대상 사용자 표 준비
- NAVER WORKS 1순위 예상 사용자
- UUID 이미지 2순위 예상 사용자
- DEFAULT 3순위 예상 사용자
baron-sso-tdc114plus-api 제거 마이그레이션 표 세분화
- 남은 기능이 진짜 필요한지
- tdc114plus-auth에 흡수할지
- 완전히 제거할지 분류

2026-07-20 메타데이터 정합성 재확인 결과

확인 결과:

tdc114plus-auth가 내보내는 사용자 메타데이터 JSON 키와
tdc114plus 앱이 저장/사용하는 JSON 키는 현재 서로 맞는다.

확인한 키:

tenantId
tenantName
tenantSlug
department
grade
position
jobTitle

정리:

중계서버 출력
- tdc114plus-auth/cmd/server/main.go
- readUser(...)가 위 항목들을 읽는다.
- issueAppSessionToken(...)가 같은 키명으로 JWT user 클레임에 넣는다.
앱 수신/저장
- app/lib/src/features/auth/domain/auth_models.dart
- LoginUser.fromJson(...)가 같은 키명으로 파싱한다.
- app/lib/src/features/auth/data/auth_session_store.dart
- 세션 저장 시 response.user.toJson() 그대로 SharedPreferences에 저장한다.
앱 소비 위치
- app/lib/src/features/directory/presentation/directory_screen.dart
- tenantSlug가 있으면 초기 회사 선택에 바로 사용한다.
- tenantSlug가 비어 있으면 조직도 조회 fallback으로 현재 사용자 소속을 다시 찾는다.
- department가 있으면 초기 부서 고정에도 바로 사용한다.
- profile_image_api_client.dart에서도 tenantSlug/tenantName를 회사코드 추정에 사용한다.

현재 판단:

구조적 키 mismatch 문제는 아니다.
진짜 남은 위험은 Baron upstream 응답에서 값이 비어 들어오는 경우다.
특히 tenantSlug가 비면 앱은 fallback으로 버티지만, 초기 선택과 사진 1차 lookup 정확도는 떨어질 수 있다.

2026-07-20 프로필 사진 검증 대상 표

현재 문서와 과거 실검증 이력을 기준으로, source별 우선 확인 대상은 아래처럼 정리한다.

우선순위	예상 source	사용자	근거	현재 상태
1순위	`NAVER_WORKS`	`thlee3@samaneng.com`	2026-07-15 네이버웍스 사진 조회 `HTTP 302` 확인 이력	route 복구 후 실기기 재검증 필요
2순위	`BARON_UUID_R2`	`khkang@samaneng.com`	2026-07-15 네이버웍스 사진 조회 `HTTP 404`, UUID 공개 이미지 fallback 이력	route 복구 후 실기기 재검증 필요
3순위	`DEFAULT`	미확정	실제 운영 사용자 중 `네이버웍스 없음 + UUID 이미지 없음` 샘플을 아직 확정하지 못함	샘플 대상 추가 선정 필요

현재 판단:

1순위와 2순위는 과거 실검증 이력이 있는 샘플이 이미 있다.
3순위는 억지로 추정하지 말고, route 복구 후 실제 미보유 샘플을 한 명 확정하는 것이 안전하다.

2026-07-20 `/api/v1/profile-image` 복구 진행 결과

이번 복구에서 반영한 범위:

tdc114plus-auth에 GET /api/v1/profile-image route를 다시 등록했다.
현재 복구 로직은 아래 순서로 동작한다.
1. NAVER_WORKS
2. BARON_UUID_R2
3. DEFAULT

구체 복구 내용:

네이버웍스 서비스 계정 env가 있으면 GET /users/{email}/photo의 302/404 규칙을 사용한다.
네이버웍스에서 사진이 없으면 org-context에서 email 기준 Baron UUID를 찾는다.
UUID가 있으면 https://baroncs.co.kr/employee_img/{uuid}.jpg 공개 경로 존재 여부를 확인한다.
둘 다 없으면 found=false, source=DEFAULT를 반환한다.

검증 결과:

go test ./cmd/server 통과
로컬 5001 재기동 완료
무인증 호출 기준 이전 404 page not found가 아니라 아래처럼 바뀐 것을 확인했다.

{"error":"unauthorized","message":"앱 세션을 확인하세요."}

현재 판단:

route 자체는 현재 기동 서버에 복구됐다.
즉 이전처럼 endpoint 자체가 없는 상태는 아니다.
다음 실제 확인은 로그인된 앱 세션 상태에서 1순위/2순위/3순위 화면 검증으로 넘어가면 된다.

내일 또는 다음 작업 시작 시 우선 순서

5001 health 먼저 확인
adb reverse --list 먼저 확인
앱에서 link/init 로그가 실제로 찍히는지 확인
문자 수신 여부를 먼저 확인
문자 미수신이면 앱 수정으로 우회하지 말고 Baron SSO 답변 상태부터 확인
문자 문제가 외부에서 정리되면 그 다음에 프로필 사진 검증으로 넘어간다

한 줄 요약

2026-07-20 기준 로그인 막힘의 핵심은 앱이 요청을 못 보내는 문제가 아니라 요청은 정상인데 실제 문자 링크가 사용자에게 도착하지 않는 문제다.

2026-07-20 오후 최종 안정화 결과

오전 인계 시점 이후 Baron SSO 문자 링크 흐름과 tdc114plus-auth 중계 흐름을 재점검했고, 최종적으로 실기기 기준 정상 진입을 확인했다.

최종 확인된 내용:

실기기에서 로그인 링크 발송 성공
문자 링크 수신 및 승인 성공
승인 후 앱 진입 성공
직원검색 목록 표시 정상
조직도 표시 정상
즐겨찾기 표시 정상
직원 상세 진입 정상
화면 전환 후 목록/이미지 재표시 정상

2026-07-20 프로필 사진 최종 검증 결과

프로필 사진 우선순위는 아래 정책으로 확정하고 실기기에서 확인했다.

NAVER_WORKS
BARON_UUID_R2
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순위로 본다.

다음 작업 시작 시 우선 순서

업무시작 기동 전에 두 저장소 git status 확인
tdc114plus-auth 5001 또는 staging auth endpoint health 확인
실기기 adb reverse --list 확인
로그인 링크 발송, 문자 수신, 승인 후 앱 진입 확인
직원검색/조직도/즐겨찾기/상세 화면 회귀 확인
프로필 사진 1순위/2순위/3순위 대표 사용자 재확인
배포 준비 단계로 이동하기 전, 회의 문서와 실제 서버 배포 체크리스트 정합성 확인

퇴근 전 종료 기동 점검 결과

종료 스크립트 점검 결과:

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 기준으로 재기동한다.

15 KiB Raw Permalink Blame History

2026-07-20 업무 인계 메모

오늘 핵심 결론

오늘 확인한 최종 상태

1. 로컬 auth broker 상태

2. 실기기 reverse 상태

3. 앱이 실제로 5001에 요청을 보내는지 확인

4. 앱 내부 pending 상태 저장 확인

오늘 발생한 실제 장애

오늘 중간에 있었던 혼선 정리

1. auth_provider_unavailable

2. callback URL 혼선

오늘 외부 전달용 요약

오늘 기준 남아 있는 작업

1. 문자 미수신 이슈 답변 대기

2. 프로필 사진 route 상태 정리

3. 로그인 화면 상태 문구 정리

외부 답변 대기 중 내부 진행 순서

2026-07-20 메타데이터 정합성 재확인 결과

2026-07-20 프로필 사진 검증 대상 표

2026-07-20 /api/v1/profile-image 복구 진행 결과

내일 또는 다음 작업 시작 시 우선 순서

한 줄 요약

2026-07-20 오후 최종 안정화 결과

2026-07-20 프로필 사진 최종 검증 결과

2026-07-20 코드/문서 커밋 및 push 결과

2026-07-20 배포 회의 문서 정리 결과

다음 작업 시작 시 우선 순서

퇴근 전 종료 기동 점검 결과

15 KiB

Raw Permalink Blame History

1. `auth_provider_unavailable`

2026-07-20 `/api/v1/profile-image` 복구 진행 결과