Quartz 4

2026-04-06 AI 대화 로그 요약

6 min read

📊 작업 분석 요약

1. 작업 분포

카테고리비중
기술 전략 논의 (RAG vs Rule-based)60%██████░░░░
아키텍처 및 코드 구조 분석40%████░░░░░░

2. 집중 영역 / 시간 소모 포인트

  • 생산적 작업
    • Locally 프로젝트 전체 구조 파악: 4개의 저장소(Locally, hamster_locally, locally-frontend, locally-sheets) 간의 연결 관계와 AI 모듈별 구현 현황(구현 완료 vs NOT_IMPLEMENTED)을 명확히 정리함.
    • 아키텍처 다이어그램화: 3단계 AI 레이어(베이스 번역, 정교화, 캐시) 구조와 3중 캐시 흐름(Redis → DB → AI)을 시각적으로 정리하여 시스템의 동작 방식을 체계화함.
  • 삽질/시간 소모 포인트 (논의 및 검토)
    • RAG 도입 여부에 대한 고민: 해커톤 특성상 데이터 규모가 작고 시간이 제한적임에도 불구하고, 기술적 난이도(RAG/벡터화)를 고려하여 과한 엔지니어링이 되지 않도록 ‘룰베이스 vs RAG’의 장단점을 심도 있게 검토하는 데 시간을 할애함. 결과적으로 현재 상황에서는 룰베이스 방식이 효율적이라는 결론을 도출하는 데 집중함.

3. 타임라인

  • 09:29 👤 User: 로컬리 관련 파일 구조를 분석하고 AI 모듈러 구성의 장단점 및 정보 아키텍처를 정리해 달라고 요청.
  • 09:31 🦦 AI: 전체 저장소 구조와 AI 모듈 현황, 3단계 레이어 아키텍처, 모듈러 구성의 장단점을 상세히 보고.
  • 09:34 👤 User: 청킹/벡터화/RAG 대신 룰베이스 AI 프롬프팅으로 충분하지 않은지에 대한 의견을 제시.
  • 09:34 🦦 AI: 데이터 규모, 갱신 주기, 할루시네이션 통제 관점에서 RAG가 필요한 순간과 룰베이스가 유효한 순간을 구분하여 설명.
  • 09:35 👤 User: 해커톤의 시간 제약과 대규모 처리 불필요성을 언급하며 룰베이스 채택 의견 피력.
  • 09:36 🦦 AI: 해커톤 맥락에서 RAG 구축의 비효율성을 인정하고, 현재 문제의 크기에 맞는 기술 선택(룰베이스)이 합리적임을 동의.
  • 09:41 👤 User: 청킹/클러스터링과 룰베이스 경험 모두 흥미로웠고, 지역별 데이터 묶임 현상 등이 신기했다고 회고.
  • 09:41 🦦 AI: 두 방식의 결과 차이가 만들어내는 의미(의미적 유사성 vs 구조적 데이터)를 분석하며, 직접 비교해본 경험의 가치를 강조.
  • 09:45 👤 User: 속도와 자료 측면에서 룰베이스의 우위를 재확인.
  • 09:45 🦦 AI: 기술 선택의 핵심은 ‘룰베이스로 버틸 수 있는지’에 대한 확신을 갖는 것이라며 경험의 중요성을 언급.
  • 10:00 👤 User: AI 환각이나 기존 자료 활용 케이스에서는 룰베이스가 독이 될 수 있다고 주장.
  • 10:00 🦦 AI: 사실 정확도가 중요한 긴급 정보나 동적 데이터 참조 케이스에서 룰베이스의 한계와 RAG/DB 조회의 필요성을 인정하며 모듈별 접근 방식을 제안.

4. 해결한 문제와 인사이트

  • 기술 전략 수립 (RAG vs 룰베이스)
    • 현재 프로젝트의 데이터 규모(팁 ~100개)와 해커톤의 시간 제약을 고려할 때, 복잡한 벡터 DB 및 RAG 파이프라인 구축보다는 룰베이스 프롬프팅이 훨씬 효율적이라는 결론을 도출함.
    • 단, 사실 기반의 정확도가 요구되는 긴급 연락처나 운영 시간 등의 정보에서는 룰베이스 방식의 환각(Hallucination) 위험이 있으므로, 이 부분은 DB 직접 조회 또는 RAG로 보완해야 함을 인지함.
  • 아키텍처 통합 방향성
    • hamster_locally(Python)와 Locally(Next.js) 간의 기능 중복(번역 모듈 등)과 연결 미정의 상태를 식별함.
    • 향후 hamster_locally를 마이크로서비스로 두거나 Next.js로 포팅하는 등의 통합 방향을 결정해야 함을 확인함.
  • 비용 및 성능 최적화
    • 3중 캐시 전략(Redis → DB → AI)과 3단계 레이어(배치 번역 → 요청 시 정교화 → 캐시)를 통해 AI 호출 비용을 통제하는 설계의 중요성을 재확인함.

Supported by ai-log-sync & GLM-4.7

그래프 뷰