7.1 KiB
7.1 KiB
2026-07-15 업무 인계 메모
작성 시각: 2026-07-15 KST
오늘 최종 상태
- 실기기 직원검색 화면에서 실제 프로필 사진 노출을 확인했다.
- 현재 프로필 이미지 정책은 아래 순서로 정리된 상태다.
- 네이버웍스 프로필 사진
- Baron SSO
members[].id기준 UUID 파일명 이미지 - 앱 기본 아바타
tdc114plus-auth의GET /api/v1/profile-image는NAVER_WORKS -> BARON_UUID_R2 -> DEFAULT순서로 동작하도록 정리했다.- 앱은
GET /api/v1/profile-image를 우선 호출하고, 응답 실패 또는 미발견 시https://baroncs.co.kr/employee_img/{uuid}.jpg경로를 보조 fallback으로 사용하도록 보강했다. - 실기기 캡처 기준으로 직원목록의 여러 사용자가 기본 이니셜 원이 아니라 실제 사진으로 표시되는 것을 확인했다.
오늘 진행한 핵심 작업
1. 네이버웍스 1순위 경로 실검증
확인 내용:
- 서비스 계정 자격값을 최신값으로 다시 반영했다.
- 토큰 발급이 실제로 성공하는지 재검증했다.
GET /users/{userId}와GET /users/{userId}/photo를 실제 호출해302,404동작을 다시 확인했다.
확인 결과:
thlee3@samaneng.com- 프로필 조회
HTTP 200 - 사진 조회
HTTP 302
- 프로필 조회
khkang@samaneng.com- 프로필 조회
HTTP 200 - 사진 조회
HTTP 404
- 프로필 조회
의미:
- 네이버웍스 사진이 있는 사용자는 1순위 경로로 바로 쓸 수 있다.
- 네이버웍스 사진이 없는 사용자는 2순위 UUID 이미지로 내려가면 된다.
2. Baron UUID 기반 2순위 경로 재확정
확인 내용:
org-context실응답의members[].id가 실제 UUID 형식인지 다시 확인했다.- 기존 CSV와 가족사 전체 응답을 대조한 매핑 결과를 기준으로 UUID 파일명 정책을 유지하기로 정리했다.
- 외부 공개 경로는
https://baroncs.co.kr/employee_img/{uuid}.jpg규칙으로 본다.
현재 판단:
- 2순위 식별자는 이메일 local-part나 해시명이 아니라 Baron UUID로 보는 것이 가장 안정적이다.
- 프로필 이미지 전용 DB는 운영 기본안으로 채택하지 않고 보류 대안으로만 남긴다.
3. tdc114plus-auth 프로필 이미지 endpoint 보강
오늘 반영한 내용:
GET /api/v1/profile-image에 네이버웍스 1순위 조회를 연결했다.- 네이버웍스에서 사진이 없으면 Baron UUID 기준 공개 이미지 경로를 2순위로 판단하게 정리했다.
- 기존 PostgreSQL 매핑 경로는 최후 예비안 수준으로만 남겼다.
실검증 결과:
GET /api/v1/profile-image?email=thlee3@samaneng.comfound=truesource=NAVER_WORKS
GET /api/v1/profile-image?email=khkang@samaneng.comfound=truesource=BARON_UUID_R2
의미:
- 서버 레벨에서는 1순위/2순위 fallback이 실제 응답으로 이미 확인된 상태다.
4. 앱 프로필 이미지 resolver 보강
오늘 반영한 내용:
- 앱은 다시
tdc114plus-auth /api/v1/profile-image를 우선 호출하도록 정리했다. - 응답 실패, 미발견, 또는 세션 문제 상황에서는 UUID 형식
employee.id가 있으면 공개 UUID 이미지 경로를 직접 fallback 하도록 보강했다. - 관련 단위 테스트를 추가하고 통과시켰다.
테스트 결과:
app/test/directory/profile_image_api_client_test.dart- auth endpoint 경유 성공
- 이메일 없음 시 기본 null 처리
- auth 미발견 시 UUID 공개 경로 fallback
- 테스트 통과 확인
5. 실기기 반영 및 화면 확인
실행 내용:
- auth 서버 기동 상태 확인
- APK 빌드 및 실기기 설치
- 공기계에서 직원검색 화면 재진입
- 실기기 화면 캡처로 실제 사진 표시 여부 확인
최종 확인:
- 직원검색 목록에서 여러 사용자 사진이 실제로 표시됨
- 오늘 목표였던 “실기기에서 사진 뜨는지 확인”은 완료
오늘 발생한 보조 이슈
1. 실기기 재실행 중 bootstrap 일시 실패
현상:
- 일부 재실행 구간에서
127.0.0.1:5000bootstrap 연결 실패 메시지가 한 차례 있었다.
현재 판단:
- 이후 권한 포함 재실행에서는 정상 bootstrap 후 앱이 다시 올라왔다.
- 오늘 최종 결과는 실기기 사진 표시 성공으로 본다.
2. Docker/ADB 권한 및 대기 시간 이슈
현상:
- 일부 재실행 또는 조회 명령은 Docker 권한/ADB 응답 지연 때문에 중간 확인이 매끄럽지 않았다.
현재 판단:
- 기능 자체의 blocker는 아니었다.
- 최종적으로 실기기 캡처까지 확보했으므로 오늘 작업 결론에는 영향 없다.
오늘 변경 및 반영한 주요 파일
-
app/lib/src/features/directory/data/profile_image_api_client.dart- auth endpoint 우선 호출
- UUID 직접 fallback 추가
- debug 로그 보강
-
app/test/directory/profile_image_api_client_test.dart- UUID fallback 관련 테스트 추가
-
scripts/start-auth-server.sh- 네이버웍스 env를 함께 읽어 auth 서버 기동 시 반영되도록 정리
-
docs/00_guide_tdc114plus_profile_image_identifier_mapping_2026-07-14.md- 오늘 실검증 결과와 실기기 성공 결과 반영
-
docs/00_guide_tdc114plus_work_progress_timetable_2026-07-02.md- 오늘 진행 상태와 다음 검증 포인트 반영
내일 바로 이어서 볼 항목
- 현재 화면에 뜬 각 프로필 사진이
NAVER_WORKS인지BARON_UUID_R2인지 source별로 구분 검증한다. - 직원검색뿐 아니라 직원 상세/조직도 화면에서도 같은 규칙으로 사진이 표시되는지 확인한다.
DEFAULT케이스도 샘플로 잡아 기본 아바타 fallback이 자연스러운지 확인한다.- 필요 시 프로필 이미지 관련 debug 로그를 더 짧게 정리하거나 제거한다.
내일 업무 시작 순서
- auth 서버 상태 확인
curl -fsSL --max-time 5 http://127.0.0.1:5001/health
- 실기기 reverse 상태 확인
ADB_SERVER_SOCKET=tcp:172.21.128.1:5037 ./scripts/flutter-docker.sh adb -s R5CT42QTCNX reverse --list
- 필요 시 auth 서버 재기동
./scripts/start-auth-server.sh --restart --env-file=/home/ubuntu/workspace/tdc114plus/scripts/.env.android-device.local
- 필요 시 실기기 앱 재실행
ADB_SERVER_SOCKET=tcp:172.21.128.1:5037 TDC114_FLUTTER_DEVICE_ID=R5CT42QTCNX TDC114_SMOKE_ENV_FILE=scripts/.env.android-device.local ./scripts/manual-postlogin-run.sh
- 첫 확인 포인트
- 직원검색 목록 진입
- 사진이 계속 노출되는지 확인
- source별 구분 검증 대상으로 사용자 샘플 확보
오늘 결론
- 오늘 작업의 핵심 목표였던 “실기기에서 프로필 사진이 실제로 뜨는지 확인”은 완료했다.
- 현재 구조는
네이버웍스 -> Baron UUID 이미지 -> 기본 아바타정책과 실제 코드/실기기 화면이 서로 맞물리는 상태다. - 내일은 새로운 구현보다, 오늘 붙인 구조를 source별로 더 명확히 검증하고 화면 범위를 넓히는 단계로 이어가면 된다.