409 lines
15 KiB
Markdown
409 lines
15 KiB
Markdown
# 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` 기준으로 재기동한다.
|