다음은 개발자와 AI 간의 오늘 하루 대화 로그야. 이 로그를 분석해서 내가 하루 동안 무엇에 집중하고 시간을 썼는지 한눈에 파악할 수 있도록 Obsidian 마크다운 형식으로 요약해줘.
1. 작업 분포
| 카테고리 | 비중 | |
|---|---|---|
| 백엔드 로직 및 AI 응답 개선 | 45% | ██████████ |
| 데이터 스키마 및 모델링 | 20% | ████░░░░░░ |
| 디버깅 및 인프라/환경설정 | 20% | ████░░░░░░ |
| 프론트엔드 연동 및 문서화 | 15% | ███░░░░░░░ |
2. 집중 영역 / 시간 소모 포인트
🟢 생산적 작업
- 검색 품질 고도화 (2-pass 검색): 컨텍스트 길이 제한으로 인해 정보가 누락되던 문제를 해결하기 위해, 팁 선정과 답변 생성을 분리하는 2-pass 방식으로
router.py검색 로직을 개선함. - 일정 생성 시스템 DB 연동: AI 내부 지식 의존에서 벗어나 Place DB(101개 장소)를 로드하여 일정 생성에 활용하도록
itinerary.py및router.py수정. - 구조화된 AI 응답 및 멀티 모델 지원: 단순 텍스트가 아닌 JSON 구조의
AIResponse를 정의하고, Gemini와 GPT-4o를 선택적으로 사용할 수 있도록_call_gpt함수 및 Provider 필드 추가. - 성능 최적화 (캐싱): 검색 속도 향상을 위해
search_cache.py모듈을 생성하여 정규화된 쿼리 기반 캐싱을 구현하고,gcloud token호출 병목을 완화하기 위해 토큰 캐싱 로직 중앙화. - 문화 로컬라이징 모듈화:
translator.py에 있던 문화 컨텍스트를culture.py로 독립시켜 검색 및 일정 생성 API에서 공유하도록 구조 개선. - 일정 API 스키마 대폭 개편: 프론트엔드 요청사항에 맞춰
ItineraryRequest/Response의 필드명(focus→travel_style,lang→language등)과 객체 구조를 전면 수정하고 신규 필드(유저 정보, 날짜 등)를 추가.
🔴 삽질/시간 소모 포인트
- 번역 시스템 데이터 모델 누락: 번역 모델(
TipTranslation)에solutions필드가 빠져 있어 발생한 이슈를 해결하기 위해 모델 정의와 파싱 로직을 수정하고 서버를 여러 번 재시작함. - 환경변수 및 호환성 이슈:
.env로드 시setdefault사용으로 인한 OpenAI API 401 에러, Python 3.9 환경에서의dict | None타입 힌트 오류 등을 해결하는 데 시간 소요. - AI 응답 파싱 예외 처리: GPT가 ID를 반환하거나, AI가 Enum에 없는 값(
item_type)을 반환하는 등 비정형 응답을 처리하기 위해 파서에 폴백 로직 및 타입 체크를 추가하는 작업 반복. - 스키마 불일치 디버깅: Google Apps Script의 헤더명과 Python 로더 매핑 불일치, 프론트엔드 페이로드와 백엔드 스키마 간의 불일치(422 Error)로 인한 디버깅 시간 소요.
3. 타임라인
| 시간 | 구분 | 주요 작업 내용 |
|---|---|---|
| 14:24 ~ 14:41 | 🦦 | 번역 시스템 플로우 리뷰 및 Tailscale 서버 설정 (router.py 실행, HTTPS 접속 확인). |
| 14:54 ~ 15:01 | 🦦 | 번역 로직 수정: solutions 필드 추가 및 last_resort Null 값 처리 로직 보완. |
| 15:13 ~ 15:26 | ⌨️ | 프론트엔드/백엔드 서버 기동 및 번역 배치 실행, solutions 타입 캐스팅 오류 수정. |
| 15:31 ~ 15:58 | 🦦 | Qdrant 재기동 및 구조화된 AI 응답(AIResponse) 모델 설계 및 적용 시작. |
| 16:05 ~ 16:29 | 🦦 | /search 로직 개선: 2-pass 검색(팁 선정→답변 생성) 도입, title 필드 추가, 토큰 한계 증설. |
| 16:39 ~ 16:54 | 🦦 | API 레퍼런스 문서화, /daily 엔드포인트 수정, Tailscale Funnel로 외부 공개 전환. |
| 17:04 ~ 17:12 | 🦦 | 검색 답변 품질 개선: 전체 팁 컨텍스트를 활용하여 필수 정보 포함되도록 2-pass 로직 구현. |
| 17:20 ~ 18:43 | 🦦 | 일정 플로우 및 데이터 갭 분석, DB 스키마 설계 및 Apps Script 수정 가이드 제공 (_formatPlace 함수 등). |
| 18:43 ~ 19:05 | 🦦 | RestaurantInfo 모델 필드 통합, Place DB 기반 일정 생성 로직 구현 (itinerary.py 수정). |
| 19:05 ~ 19:12 | 🦦 | Place 모델에 누락된 필드 추가, JSON 토큰 초과(maxOutputTokens 상향) 해결. |
| 19:21 ~ 19:35 | 🦦 | GPT-4o 멀티 모델 지원 구현, .env 로드 방식 수정(os.environ 직접 할당)으로 인증 에러 해결. |
| 19:38 ~ 19:52 | 🦦 | GPT 응답의 ID→텍스트 변환 로직 추가, Travel Tips 프롬프트 강화 및 Swagger 문서화. |
| 19:58 ~ 20:12 | 🦦 | culture.py 모듈 분리 및 생성, 일정 생성 프롬프트에 문화 컨텍스트 주입. |
| 20:16 ~ 20:24 | 🦦 | start_date 파라미터 추가, Python 3.9 호환성 이슈(from __future__ import annotations 추가) 해결. |
| 20:39 ~ 20:57 | 🦦 | 유저 정보 필드 추가, 검색 엔드포인트 디버깅(maxOutputTokens 증설, 마크다운 문구 제거). |
| 21:02 ~ 21:27 | 🦦 | 번역 퀄리티 개선, Gemini 2.5 Pro 테스트 및 thinkingBudget 이슈 해결(검색은 Flash로 유지). |
| 21:43 ~ 21:56 | 🦦 | 일정 API 스키마 대폭 개편(필드명 변경, 객체 구조 수정), 검색 캐싱 시스템(search_cache.py) 구현. |
| 22:25 ~ 22:47 | 🦦 | 피드(feed.py) 기능 설계 및 라우터 연동, gcloud token 병목 해결을 위한 토큰 캐싱 로직 중앙화. |
| 22:54 ~ 23:01 | 🐹 | 배포된 API 서버 상태 테스트, 검색 속도(캐시 히트 시 0.1초) 및 일정 생성 퀄리티 검토. |
| 23:01 ~ 23:20 | 🐹 | itinerary-preview.html 인풋/아웃풋 구조 변경, 422 에러 디버깅 및 페이로드 수정. |
| 23:23 | 🐹 | GitHub 저장소 분석 및 팀 프로젝트 구조 파악. |
4. 해결한 문제와 인사이트
핵심 문제 해결
- 번역 및 AI 응답 데이터 누락: 모델 정의에 필드(
solutions)가 누락되어 발생하던 문제를 모델 수정과 프롬프트 엔지니어링으로 해결하고, AI가 전체 컨텍스트를 참조하도록 2-pass 검색 방식을 도입하여 답변의 완성도를 높임. - 일정 생성의 환각(Hallucination) 해결: 기존 AI 내부 지식에 의존하던 것을
router.py에서 Place DB 데이터를 로드하여 프롬프트에 주입하는 방식으로 변경하여 실제 DB에 등록된 장소를 활용한 일정 생성을 구현함. - 환경변수 및 호환성 이슈: 서버 시작 시점에 이미 로드된 환경변수를 덮어쓰지 못하는
setdefault특성을os.environ직접 할당으로 변경하고, Python 3.9에서 발생하는 타입 힌트 에러를futureimport로 해결함. - API 스키마 불일치: 프론트엔드와 백엔드 간의 필드명(
focusvstravel_style) 및 구조 불일치로 인한 422 에러를 Pydantic 모델 전면 수정(ItineraryRequest등)을 통해 해결하고, 모델별 응답 차이(ID vs Text)를 처리하는 파싱 로직을 보강함. - 성능 병목 해결: 검색 속도 저하 원인을 분석하여 검색엔진은 Flash 모델을 사용하고 캐싱(
search_cache.py)을 적용하여 캐시 히트 시 0.1초 미만의 응답 속도를 달성함. 또한gcloud token호출 병목을 토큰 캐싱으로 완화함.
주요 인사이트
- 토큰 vs 품질 트레이드오프: 검색 정확도와 답변 품질을 높이기 위해 전체 데이터를 컨텍스트에 포함하는 것은 토큰 비용이 증가하지만, 신뢰도를 크게 높이는 데 기여함. 다만, 실시간 검색엔진은 속도를 위해 가벼운 모델(Flash)을 사용하는 전략이 유효함.
- 데이터 통합 관리의 효율성: 장소와 식당 정보를 단일 스키마에서 관리하면 AI 프롬프트 구성 시 컨텍스트가 풍부해지고 조인 로직이 단순해져 일정 생성 등 복합 작업에 유리함.
- 안전한 배포 및 스키마 관리: 스키마 변경 시 폴백(Fallback) 로직을 미리 반영하면 데이터 마이그레이션 중에도 서비스 안정성을 유지할 수 있으며, AI의 불확실한 응답(Enum 외의 값, 타입 불일치)에 대비한 파싱 로직이 필수적임.
Supported by ai-log-sync & GLM-4.7