# 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 상태

정상 확인값:

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

응답:

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

의미:

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

### 2. 실기기 reverse 상태

사용자 확인 결과:

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

의미:

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

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

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

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

그리고 이어서:

```text
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`

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

```text
로그인 링크 요청 실패: 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`가 보인다.

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

정리:

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

## 오늘 외부 전달용 요약

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

```text
- 신규앱 -> 로컬 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`가 아니라 아래처럼 바뀐 것을 확인했다.

```json
{"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 기준 로그인 막힘의 핵심은 `앱이 요청을 못 보내는 문제`가 아니라 `요청은 정상인데 실제 문자 링크가 사용자에게 도착하지 않는 문제`다.

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

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

최종 확인된 내용:

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

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

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

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

## 다음 작업 시작 시 우선 순서

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

## 퇴근 전 종료 기동 점검 결과

종료 스크립트 점검 결과:

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