Prompt Injection으로부터 도구 실행을 보호하기
문서와 사용자 입력을 읽는 AI가 외부 도구까지 실행하면 Prompt Injection은 잘못된 답변을 넘어 실제 상태 변경으로 이어질 수 있습니다. 처음에는 system prompt에 외부 문서의 지시를 따르지 말라고 명시하면 도구 실행도 보호할 수 있다고 생각했습니다. 하지만 검색 결과와 사용자 입력이 같은 context에 들어오자 문서 속 명령이 실제…
최근 글
-
-
MCP 도구 설명이 AI의 호출 정확도를 바꾸는 이유
MCP 도구가 API를 정확히 감싸더라도 모델이 언제 어떤 인자로 호출해야 하는지 이해하지 못하면 실제 사용성은 낮습니다. 처음에는 함수 이름과 JSON schema만 정확하면 모델이 알맞은 도구를 고를 것으로 기대했습니다. 하지만 기능이 비슷한 도구가 늘자 설명의 작은 차이가 선택과 인자 생성에 영향을 줬고, 단순 성공률만으로는 원인을 찾기 어려웠습니다.…
-
RAG 전에 질문을 재작성하고 의도를 분류해야 하는 이유
대화형 질문은 검색 query로 쓰기에 지나치게 짧거나 앞선 문맥에 의존할 때가 많습니다. 운영용 AI 챗봇에서도 처음에는 사용자 원문을 그대로 embedding하면 대화 맥락이 자연스럽게 반영될 것으로 기대했습니다. 그러나 RAG 검색 전에 독립된 질문으로 재작성하고 intent를 분류해야 검색 품질을 높이고 불필요한 비용을 줄일 수 있었습니다. 대명사와 생략이 포함된…
-
RAG부터 MCP 도구 실행까지: 운영용 AI 챗봇 아키텍처
데모 챗봇은 모델 API 한 번으로 만들 수 있지만, 운영 환경에서는 지식 검색과 도구 실행, 권한, 비용, 대화 상태를 함께 관리해야 합니다. 처음에는 모델 호출 앞에 검색 결과를 붙이고 필요한 기능을 tool로 노출하면 충분해 보였습니다. 기능이 늘어나자 검색 실패와 도구 실패, 권한 거부를 구분하기 어려워졌고 한…
-
Sticky Session을 제거하며 MCP 재연결 상태를 Redis로 옮긴 방법
롤링 배포 중 MCP 서버 Pod 하나를 종료했을 때, 클라이언트의 재연결은 정상적으로 다른 Pod에 도착했습니다. 문제는 그다음이었습니다. 새 Pod는 이전 연결에서 어디까지 응답을 보냈는지, 실행 중이던 도구 요청이 취소됐는지 알지 못했습니다. 연결에는 성공했지만 대화를 이어갈 수는 없었습니다. 처음에는 같은 클라이언트의 요청을 계속 같은 Pod로 보내는 Sticky…
-
운영 가능한 MCP 서버에 OAuth 2.1을 붙이는 과정
로컬에서 동작하던 MCP 서버를 여러 사용자와 클라이언트가 쓰는 서비스로 바꾸자 도구 구현보다 인증 흐름이 더 큰 과제가 됐습니다. 클라이언트마다 discovery와 redirect 처리 방식이 달랐고, token의 issuer와 audience, scope를 구분하지 않으면 다른 서비스용 권한까지 받아들일 수 있었습니다. 이 문제를 해결하기 위해 OAuth 2.1 authorization code와 PKCE를 적용했습니다.…
-
Redis Streams의 Pending 메시지를 안전하게 회수하는 방법
처음에는 XREADGROUP으로 메시지를 읽었습니다. 처리가 끝나면 XACK하면 된다고 생각했습니다. 정상 흐름만 보면 맞는 설명입니다. 운영에서는 다른 질문이 더 중요했습니다. Worker가 ACK 전에 종료되면 누가 메시지를 다시 처리해야 할까요? 전달된 메시지는 ACK 전까지 목록에 남습니다. 이 글은 MongoDB·Redis Streams·PostgreSQL 파이프라인 가운데 Pending 복구 경로를 좁혀 설명합니다. 이…
-
HMAC 기반 Presigned URL을 직접 설계하며 배운 것
사용자가 스토리지 서버를 거치지 않고 파일을 업로드하거나 다운로드하려면 짧은 시간만 유효한 파일 접근 권한을 URL에 담아야 합니다. 처음에는 경로와 만료 시각을 HMAC으로 서명하면 충분하다고 생각했지만, 실제로는 서명 대상과 검증 순서까지 하나의 계약으로 맞춰야 했습니다. HTTP method와 인코딩 순서가 달라지자 같은 요청의 서명이 어긋났고, 경로만 서명한 URL은…