AI VIDEO BRIEFING
AI 에이전트 함수 호출과 MCP 작동 원리 정리, 도구 오용과 보안 위험까지 짚어보기
AI 에이전트 속에 요정은 없다. NDC 코펜하겐 강연을 토대로 함수 호출의 실제 흐름과 RAG 토큰 절감 기법, 모델이 도구를 잘못 고르거나 결과를 맹신하는 문제, 그리고 MCP의 정확한 정의를 정리했다.

핵심 메시지
쉽게 이해하기
스웨덴 스톡홀름의 개발사에서 일하는 앨런 스미스는 NDC 코펜하겐 강연에서 에이전트를 '만드는 법'이 아니라 '안에서 무슨 일이 벌어지는지'를 설명했다. 그는 언어 모델이 마법이 아니라 통계에 기반한 토큰 예측기일 뿐이라는 점부터 짚는다. 사용자가 앱을 업데이트했더니 갑자기 AI 기능이 붙어 있고 그 안에 요정이 들어 있는 것처럼 느끼지만, 실제 구조는 훨씬 단순하다는 것이다.
동작 순서는 이렇다. 사용자가 '코펜하겐 날씨가 어때'라고 물으면 모델은 실시간 정보를 모르기 때문에 답하지 못한다. 여기에 날씨 도구의 정의를 함께 보내면, 모델은 도구를 실행하는 대신 '날씨 서비스를 코펜하겐이라는 인자로 부르라'는 응답을 돌려준다. 실제 호출은 에이전트 애플리케이션이 하고, 그 결과를 대화 이력과 함께 다시 모델에 넣어야 비로소 사람이 읽을 답이 나온다.
이 형식은 모델을 새로 학습시켜 만든 것이 아니라 미세조정으로 붙인 능력이다. 발표자는 오픈AI가 JSON 예시를 대량으로 학습시켜 함수 호출 개념을 이해시켰고, 다른 업체들도 각자 조금씩 다른 형식으로 같은 일을 했다고 설명한다. 그래서 제공사마다 요청 형식이 달라지고, 이를 감춰주는 프레임워크가 등장했다. 랭체인에서 시맨틱 커널을 거쳐 지금은 마이크로소프트 에이전트 프레임워크로 옮겨가는 흐름이라고 그는 정리했다.
검색 증강 생성(RAG)도 도구 호출로 흡수됐다. 예전에는 질문이 '누가'나 '언제'로 시작하면 검색을 쓰는 식의 조잡한 규칙을 사람이 짜야 했지만, 이제는 모델이 어느 저장소를 뒤질지 고르고 검색에 어울리는 질의로 바꿔 쓴다. 다만 무엇을 넣느냐가 비용을 좌우한다. 위키백과 문서를 통째로 넣었을 때 입력 토큰이 1만 8천 개 가까이 들었지만, 값싼 요약 모델로 주제에 맞게 줄여 넣자 1천 4백여 개로 떨어졌다.
강연의 절반은 실패담이다. 모델은 도구를 잘못 고르고, 도구가 돌려준 엉뚱한 값을 그대로 믿고, 같은 질문에도 매번 다르게 행동한다. 시스템 프롬프트에 신용카드 번호를 넣어두자 도구가 요구했다는 이유만으로 그대로 넘겨버리기도 했다. 발표자는 마지막에 이런 위험을 나열하면서도, 도구와 에이전트가 애플리케이션을 만드는 훌륭한 방법이라는 점은 부정하지 않았다.
주요 인사이트
- 에이전트의 신뢰성 문제는 대부분 '모델이 도구를 고르는 순간'에 생긴다. 도구 이름과 설명이 곧 인터페이스이므로, 파이썬식으로 읽기 쉬운 이름을 쓰라는 조언이 나온다.
- 같은 계산도 '16주는 며칠이냐'처럼 말로 물으면 도구를 쓰지 않고, '7 곱하기 16'처럼 수식으로 물으면 도구를 쓴다. 도구를 쓰라고 프롬프트에 적어도 마찬가지였다.
- 비개발자가 손쉽게 만드는 사내 코파일럿이 특히 위험하다. '내 보너스는 얼마인가'와 '상사의 보너스는 얼마인가', '테스트 서버를 재설치하라'와 '운영 서버를 재설치하라'는 모델 입장에서 거의 같은 요청이다.
- 멀티 에이전트는 성능 자랑이 아니라 컨텍스트 관리 기법에 가깝다. 프로젝트 매니저·개발자·디자이너 에이전트가 각자 대화 이력을 따로 들고 있어 창이 덜 붐빈다.
- 같은 코드가 내일 다르게 동작할 수 있다. 발표자가 카드 번호 유출을 재현하려 하자 다른 백엔드에서는 모델이 요청을 거절했고, 그는 이를 '서비스가 계속 바뀌기 때문'이라고 설명했다.
자주 묻는 질문
MCP는 결국 함수 호출을 대체하는 기술인가?
아니다. 발표자는 MCP가 에이전트와 MCP 서버 사이의 프로토콜일 뿐이며, 모델에 보내는 JSON 형식과는 무관하다고 못 박는다. 함수 호출로 충분한 애플리케이션에 MCP를 얹는 것은 함수 호출을 마이크로서비스로 쪼개는 것과 비슷한 아키텍처 결정이라고 설명한다.
MCP 서버는 무엇을 제공할 수 있나?
도구, 리소스, 프롬프트 템플릿, 그리고 알림 네 가지다. 이 가운데 실제로 널리 쓰이는 것은 도구이며, 알림이 필요하기 때문에 일반적인 요청·응답 방식 대신 스트리밍 HTTP를 써야 한다고 강연은 설명한다.
도구가 잘못된 값을 돌려주면 모델은 어떻게 반응하나?
그대로 믿는다. 두 수를 더하는 도구에 1을 더 더하는 버그를 심자 모델은 14 더하기 16이 31이라고 답했다. 사람이 '짝수 둘을 더하면 홀수가 나올 수 없다'고 지적한 뒤에야 답을 바로잡았고, 발표자는 이 성질이 악용될 수 있다고 경고한다.
원문과 출처
이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.
YouTube 원본 영상 보기 ↗