AI 에이전트가 믿고 쓰는 도구가 거짓말을 하면 어떻게 알아채나. 한 개발자의 '거짓말 MCP 서버' 실험과 인디 빌더가 봐야 할 신호 3 가지

📅 2026.08.18 | ✍️ 경제 흐름을 읽어주는 형

오늘 아침 형이 챙긴 소식은 요란한 인수합병이나 조 단위 밸류 얘기가 아니야. 한 개발자가 개발자 커뮤니티 dev.to에 올린 실험 글인데, 형이 매일 하는 고민을 정확히 찌르는 내용이라 골랐어. 요즘 AI 에이전트는 MCP 서버라는 외부 도구를 붙여서 일을 시켜. 그 도구가 자기 설명서에 "나는 이렇게 동작한다"고 써두면 에이전트는 그 말을 그냥 믿고 써. 그런데 이 개발자가 던진 질문이 날카로워. 그 설명서가 거짓말이면 어쩔 건데?

형이 이걸 고른 이유가 있어. 형이 만드는 것들이 죄다 "AI가 하는 말을 그냥 믿지 말고 밖에서 검증하자"는 생각 위에 서 있거든. 이 개발자는 말로만 떠들지 않고, 아예 거짓말하는 도구를 손수 만들어서 그걸 잡아내는 방법까지 보여줬어. 형이 읽은 신호 셋을 풀어볼게.

【 핵심 체크포인트 】

1. 설명서는 뭐든 말할 수 있지만, 진실은 실제로 오는 응답에 있어.

이 글의 한 문장이 핵심을 다 담고 있어. "서버의 설명서는 무슨 말이든 쓸 수 있다. 그게 진짜인지는 도구 목록을 물었을 때 돌아오는 응답이 증명하거나 뒤집는다." MCP 서버는 자기가 상태를 안 남긴다거나, 목록을 캐시해도 된다거나, 도구 순서가 항상 일정하다고 문서에 적어둘 수 있어. 문제는 그 약속을 강제하는 장치가 프로토콜 안에 없다는 거야. 에이전트 입장에선 도구가 하는 말을 확인할 방법이 딱히 없으니 그냥 믿고 넘어가. 이 개발자는 바로 그 빈틈을 파고들었어. 문서가 아니라 실제로 전선을 타고 오는 응답만 보면 된다는 거지.

2. 진짜 검증은 일부러 고장 낸 버전을 만들어 내 검사기가 그걸 잡는지 확인하는 거야.

여기가 형이 무릎을 친 대목이야. 이 개발자는 규칙을 지키는 정상 서버 옆에, 일부러 규칙을 어기는 서버를 하나 더 만들었어. 캐시 정보를 빼먹고, 도구 순서를 거꾸로 뒤집는 식으로 계약을 대놓고 위반하게 짰지. 그다음 두 서버를 진짜 프로세스로 동시에 띄워서 각각의 응답을 나란히 읽는 검사를 돌렸어. 결과는 깔끔했어. 정상 서버는 순서가 맞고 캐시 값이 제대로 담겨 통과했고, 고장 낸 서버는 순서가 뒤집히고 캐시 값이 비어서 걸려 나왔어. 요점은 이거야. 잘 돌아가는 경우만 통과시키는 검사는 검사가 아니야. 일부러 틀린 버전을 만들어서 내 검사기가 그걸 실제로 잡아내는지를 봐야 그게 진짜 검증이야.

3. 에이전트 시대의 자산은 도구가 하는 말이 아니라 결과를 검증하는 습관이야.

AI 에이전트한테 외부 도구를 하나둘 붙이다 보면 어느 순간 내가 짠 게 아닌 부품이 절반을 넘어가. 그 부품 하나가 조용히 엉뚱한 값을 내놓으면 에이전트 전체가 틀린 판단으로 굴러가는데, 겉으로는 멀쩡해 보여서 알아채기가 어려워. 이 개발자가 남긴 교훈은 명확해. 도구가 약속하는 모든 것을 문서로 적어두고, 그 약속을 일부러 어기는 시험용 부품을 만들어서 내 검사기가 그걸 걸러내는지 증명하라는 거야. 인디 빌더한테 이건 남 얘기가 아니야. 남이 만든 도구를 믿고 쓰는 만큼, 그 도구가 실제로 약속을 지키는지 스스로 확인하는 장치를 곁에 둬야 사고가 안 나.

【 형 빌드에 어떻게 이어지나 】

형이 만들고 있는 것들에 이 실험이 어떻게 걸리는지 짚어볼게. 솔직히 이건 형이 몇 달째 붙잡고 있는 주제 그 자체야.

num_ctx 하네스 부터야. 형이 만든 이 검증 도구는 AI한테 넘긴 내용이 중간에 잘려서 엉뚱한 답이 나오는 걸 밖에서 잡아내는 물건이야. 이 개발자가 한 짓하고 결이 똑같아. 모델이나 도구가 "나 제대로 처리했어"라고 말해도 그 말을 안 믿고, 실제로 내놓은 결과를 밖에서 독립적으로 재보는 거지. 이 개발자가 도구의 설명서 대신 실제 응답을 본 것처럼, 형의 하네스는 모델의 자기 보고 대신 실제 출력을 본다는 점에서 정확히 같은 철학 위에 서 있어.

MINDCHANGE 하네스 하고도 곧장 이어져. 형이 짜는 이 자가검증 루프는 AI가 스스로 낸 답을 스스로 다시 검사하고 틀렸으면 고치게 만드는 장치야. 이 개발자가 강조한 "일부러 틀린 버전을 만들어 내 검사기가 잡는지 확인하라"는 말은, 자가검증 루프를 만들 때 반드시 새겨야 할 원칙이야. 잘 되는 경우만 통과시키는 루프는 있으나 마나거든. 형은 여기에 일부러 틀린 답을 흘려 넣고 루프가 그걸 걸러내는지 시험하는 단계를 넣을 수 있어. 그래야 그 루프가 진짜로 일한다고 말할 수 있어.

agent-starter-kit 하고도 결이 맞아. 형이 만든 이 텔레그램 에이전트 키트는 여러 외부 도구를 붙여서 일을 시키는 구조야. 이 글이 딱 그런 구조에 대고 던지는 경고지. 붙여 쓰는 도구가 늘어날수록, 그 도구 하나하나가 약속을 지키는지 확인하는 검사를 키트 안에 넣어둘수록 안전해져. 형은 키트에 새 도구를 붙일 때마다 그 도구의 응답을 한 번 걸러 보는 작은 검사를 기본으로 깔아둘 수 있어. 그러면 어느 도구가 조용히 이상한 값을 내놔도 에이전트가 통째로 흔들리기 전에 걸러낼 수 있어.

【 결론 】

정리하면 이래. AI 에이전트가 외부 도구에 점점 더 많이 기대는 시대에, 그 도구가 하는 말을 그냥 믿는 건 위험해. 한 개발자가 일부러 거짓말하는 도구를 만들어 보여준 건, 문서가 아니라 실제 응답만이 진실이고, 진짜 검증은 일부러 틀린 버전을 잡아내는지로 판가름 난다는 거야. 형이 오늘 남기고 싶은 한마디는, 지금 네 자동화에 붙어 있는 남의 도구 하나를 골라서 "이게 정말 약속대로 동작하나"를 한 번 실제로 재보라는 거야. 대단한 걸 만들라는 말이 아니야. 그 도구한테 똑같은 걸 두 번 물어보고 답이 흔들리는지 보는 것부터 시작하면 돼. 답이 흔들린다면 그 도구는 네가 믿던 만큼 믿을 물건이 아니었던 거야. 도구는 언제든 조용히 거짓말을 할 수 있어. 그 거짓말을 걸러내는 검사 하나를 곁에 두는 게, 이 시대 인디 빌더가 사고를 피하는 진짜 무기야.

출처: dev.to, I built a lying MCP server on purpose: here's how you catch it

이 글은 2026.08.18 뉴스 + 데이터 기반 AI 도구 활용 재작성.