tdc114plus/docs/daily-issues/2026-07-20_work_handoff.md

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 복원 시 에러 상태를 같이 끌고 오지 않는지
• 문자 미수신과는 별개로 화면 상태 표현이 꼬이지 않는지

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

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

1. tdc114plus-auth 응답 메타데이터 정합성 재확인

   • tenantSlug, tenantId, tenantName, department, grade, position, jobTitle
   • 앱이 실제로 어떤 필드를 저장하고 소비하는지 확인

2. 로그인 화면 상태 표현 정리

   • 실패 문구와 승인 대기 UI가 동시에 남지 않도록 정리
   • pending 복원 시 문구 초기화 조건 확인

3. /api/v1/profile-image route 복구 준비

   • 현재 앱 호출 형식 고정
   • auth 서버 route 부재 상태 문서화
   • 복구 시 필요한 응답 형태 확정

4. 프로필 사진 검증 대상 사용자 표 준비

   • NAVER WORKS 1순위 예상 사용자
   • UUID 이미지 2순위 예상 사용자
   • DEFAULT 3순위 예상 사용자

5. baron-sso-tdc114plus-api 제거 마이그레이션 표 세분화

   • 남은 기능이 진짜 필요한지
   • tdc114plus-auth에 흡수할지
   • 완전히 제거할지 분류

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

확인 결과:

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

확인한 키:

• tenantId
• tenantName
• tenantSlug
• department
• grade
• position
• jobTitle

정리:

1. 중계서버 출력

   • tdc114plus-auth/cmd/server/main.go
   • readUser(...)가 위 항목들을 읽는다.
   • issueAppSessionToken(...)가 같은 키명으로 JWT user 클레임에 넣는다.

2. 앱 수신/저장

   • 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에 저장한다.

3. 앱 소비 위치

   • 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순위 화면 검증으로 넘어가면 된다.

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

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

한 줄 요약

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