2026-06-29 관찰성 모듈 셋팅 TradeOff 회의

[hyunbin1]

컴포넌트 flow 성능 최적화

1. 현재 CSV 데이터를 정제하고 ES에 데이터가 저장되는 부분은 HTTP 요청으로 진행된다.
2. 반면 대화 요청은 WebSocket 통신을 통해 AI Agent 까지 연결된다.

여기서 발생되는 문제는 3가지이다.

1. csv import thread와 대화 스레드가 다르면 끊긴다.
2. java에 thread context가 인메모리이다.
3. es 저장 완료와 대회 시작의 타이밍: es 데이터가 저장되기 이전에 대화가 진행되면 csv 데이터를 사용할 수 없다.

---

앞으로의 진행 방향성

시스템 전체의 횡단 관찰성은 이미 진행했으니, 이제부터는 AI Container를 기준으로 3단계 레이어 단계로 진행된다.

1. 인프라 Layer : 기억(상태)관리, Evaluation 관찰성 추적
2. 전문 Agent Layer:
3. 오케스트레이트 Layer
   순으로 진행될 예정이다.

*여기서 평가란 1) 사용자에게 얼마나 유효한 응답을 제공하는지 퀄리티 판단, 2) 얼마나 동시다발적인 요청을 처리할 수 있는지에 대한 성능&수용성 관리 이다.
우리는 1차적으로 관찰성 셋팅이 완료되면 2,3번의 구현 디테일로 나아갈 것이다.

[bbororo5]

현재 상황만 정리합니다.

GCP 비용 문제로 Cloud Run / Google Cloud Operations는 더 이상 사용하지 않기로 했습니다. 대신 로컬 Docker Compose로 frontend, backend, agent, elasticsearch, redis를 실행하는 구성은 완료된 상태입니다.

PR #21은 새로운 관찰성 도구를 붙이는 작업이 아니라, GCP를 제거한 뒤 logs/metrics/traces를 어떻게 볼지에 대한 최소 기준을 ADR로 남기는 작업입니다.

따라서 이 이슈의 본래 주제였던 인프라 Layer 작업은 PR #21 이후에 이어서 진행하는 게 맞습니다.

후속 작업에서는 다음을 다루면 됩니다.

• 상태/기억 관리가 제대로 동작하는지
• Java와 Python 흐름이 같은 요청으로 이어져 보이는지
• 어느 구간이 느리거나 실패하는지
• Phoenix evaluation 결과는 기존처럼 유지되는지

즉, 이번 PR은 기준 정리이고 실제 인프라 Layer 점검과 개선은 다음 PR에서 진행합니다.