감사 로그는 계속 쌓이지만 오래된 기록을 조회하는 빈도는 낮습니다. 그래서 audit_log와 audit_log_target을 occurred_at 기준의 월별 RANGE 파티션으로 나눴습니다. 데이터가 어느 파티션으로 들어갈지는 명확했지만, 다음 달 파티션을 누가 언제 만들지는 별도의 문제였습니다. PostgreSQL은 입력값을 받아 줄 파티션이 없으면 부모 테이블에 대신 보관하지 않습니다. DEFAULT 파티션을 두지 않은…
시간 순서로 계속 쌓이는 이벤트 데이터는 처음에는 단일 PostgreSQL 테이블로도 충분했습니다. 최근 며칠을 조회하는 API, 장비별 필터, 결함 통계 모두 적절한 복합 인덱스로 빠르게 처리됐습니다. 문제는 데이터와 인덱스가 함께 커진 뒤 나타났습니다. 조회 조건은 최근 범위였지만 조회에 사용되는 인덱스는 전체 이력을 포함했습니다. 대량 삭제로 발생한 WAL과…
시간 순서로 쌓이는 이벤트 데이터도 시간이 지나면 접근 빈도와 갱신 방식이 달라집니다. 수집 직후에는 새 데이터가 계속 들어오고 상태가 갱신되지만, 최근 며칠 또는 몇 주의 데이터는 화면 조회와 통계에서 반복해서 읽힙니다. 수개월이 지난 데이터는 거의 조회되지 않지만 감사, 장기 통계, 파일 내보내기를 위해 보관해야 합니다. 초기에는…
문서와 사용자 입력을 읽는 AI가 외부 도구까지 실행하면 Prompt Injection은 잘못된 답변을 넘어 실제 상태 변경으로 이어질 수 있습니다. 처음에는 system prompt에 외부 문서의 지시를 따르지 말라고 명시하면 도구 실행도 보호할 수 있다고 생각했습니다. 하지만 검색 결과와 사용자 입력이 같은 context에 들어오자 문서 속 명령이 실제…
MCP 도구가 API를 정확히 감싸더라도 모델이 언제 어떤 인자로 호출해야 하는지 이해하지 못하면 실제 사용성은 낮습니다. 처음에는 함수 이름과 JSON schema만 정확하면 모델이 알맞은 도구를 고를 것으로 기대했습니다. 하지만 기능이 비슷한 도구가 늘자 설명의 작은 차이가 선택과 인자 생성에 영향을 줬고, 단순 성공률만으로는 원인을 찾기 어려웠습니다.…
대화형 질문은 검색 query로 쓰기에 지나치게 짧거나 앞선 문맥에 의존할 때가 많습니다. 운영용 AI 챗봇에서도 처음에는 사용자 원문을 그대로 embedding하면 대화 맥락이 자연스럽게 반영될 것으로 기대했습니다. 그러나 RAG 검색 전에 독립된 질문으로 재작성하고 intent를 분류해야 검색 품질을 높이고 불필요한 비용을 줄일 수 있었습니다. 대명사와 생략이 포함된…
데모 챗봇은 모델 API 한 번으로 만들 수 있지만, 운영 환경에서는 지식 검색과 도구 실행, 권한, 비용, 대화 상태를 함께 관리해야 합니다. 처음에는 모델 호출 앞에 검색 결과를 붙이고 필요한 기능을 tool로 노출하면 충분해 보였습니다. 기능이 늘어나자 검색 실패와 도구 실패, 권한 거부를 구분하기 어려워졌고 한…
롤링 배포 중 MCP 서버 Pod 하나를 종료했을 때, 클라이언트의 재연결은 정상적으로 다른 Pod에 도착했습니다. 문제는 그다음이었습니다. 새 Pod는 이전 연결에서 어디까지 응답을 보냈는지, 실행 중이던 도구 요청이 취소됐는지 알지 못했습니다. 연결에는 성공했지만 대화를 이어갈 수는 없었습니다. 처음에는 같은 클라이언트의 요청을 계속 같은 Pod로 보내는 Sticky…