MCP

소프트웨어 에이전트의 tool call이 실패했을 때 우리가 실제로 하는 일은 재시도입니다. API가 500을 반환하면 다시 호출하고, 파일 쓰기가 깨지면 이전 커밋으로 되돌리고, 잘못된 레코드가 들어가면 트랜잭션을 롤백합니다. 이 습관은 대상이 비트라는 사실에 기대고 있습니다. 비트는 복제할 수 있고, 이전 상태를 보관할 수 있고, 같은 명령을 두 번 실행해도 대체로 같은 결과에 도달합니다. 로봇팔을 5cm 움직이는 명령은 이 전제 중 어느 것도 만족하지 않습니다. 명령이 절반만 실행된 상태에서 재시도하면 팔은 10cm를 움직입니다. 시약 40µL를 분주한 뒤에는 되돌릴 이전 상태가 없고, 시료 자체가 소모됩니다. 레이저 출력을 잘못 올리면 형광 분자가 표백되어 그날의 실험이 끝납니다. 소프트웨어 에이전트 설계에서 익숙해진 “일단 시도하고 실패하면 되돌린다"는 패턴이, 물리 장치에서는 그 자체로 사고의 경로가 됩니다. ...

사내 문서를 검색하고 요약해서 메일로 보내는 에이전트를 하나 상상해 보겠습니다. 이 에이전트에는 세 가지 도구가 붙어 있습니다. 문서 검색, 문서 본문 읽기, 메일 발송입니다. 세 도구는 각각 정당한 권한을 받았고, 호출 한 건씩 떼어 놓고 보면 어느 것도 규칙을 어기지 않습니다. 검색은 읽기 전용이고, 본문 읽기도 사용자가 접근 권한을 가진 문서만 반환하며, 메일 발송은 사용자가 명시적으로 요청한 기능입니다. 그런데 이 세 호출이 다음 순서로 일어나면 상황이 달라집니다. 에이전트가 인사 평가 문서를 검색하고, 그 본문을 읽어 컨텍스트에 담고, 곧바로 외부 도메인 주소로 요약 메일을 발송합니다. 호출 하나하나를 검사하는 게이트는 이 흐름을 통과시킵니다. 세 번째 호출을 심사하는 시점에 그 게이트가 보는 것은 “이 사용자가 메일을 보낼 권한이 있는가"뿐이고, 두 번째 호출에서 민감 문서가 컨텍스트로 들어왔다는 사실은 심사 대상에 들어 있지 않기 때문입니다. ...

에이전트에 기능을 붙이는 두 조각은 이미 표준이 있습니다. 모델에게 절차적 지식을 주는 Agent Skills와 외부 도구·데이터에 연결하는 MCP입니다. 두 규약 모두 여러 클라이언트가 이미 지원합니다. 그런데 이 조각들을 실제로 배포하려고 하면 예상치 못한 곳에서 마찰이 생깁니다. 컴포넌트 자체는 멀쩡한데 그것을 담는 상자가 클라이언트마다 다르기 때문입니다. 2026년 8월 6일에 발표된 Agent Plugins 1.0.0이 이 상자를 표준화합니다. 오픈이고 벤더에 중립적인 패키징 표준이며, 기술 운영 위원회의 코어 메인테이너는 Amazon, Cursor, Microsoft, OpenAI, Vercel입니다. 발표 이후 Google이 코어 메인테이너로 합류했고, DeepMind의 Kevin Hou가 대표를 맡았습니다. 이 글에서는 표준이 무엇을 정의하고 무엇을 일부러 정의하지 않았는지를 코드 예시와 함께 살펴봅니다. ...

MCP 서버를 로컬에서 하나 띄워 쓸 때는 아무 문제가 없습니다. Claude Desktop이 stdio로 프로세스를 하나 붙이고, 그 프로세스가 살아 있는 동안 세션이 유지됩니다. 프로토콜이 처음 설계될 때 상정한 그림이 정확히 이것이었습니다. 단일 앱, 단일 로컬 서버, 하나의 연결. 같은 서버를 사내 100명이 쓰도록 원격 배포하는 순간 이야기가 달라집니다. 로드밸런서 뒤에 인스턴스를 세 개 띄우면 클라이언트가 처음 handshake한 인스턴스에만 세션이 존재합니다. 두 번째 요청이 다른 인스턴스로 가면 그 인스턴스는 세션을 모릅니다. 그래서 sticky routing을 켜거나, 인스턴스들이 공유하는 세션 스토어를 앞에 두거나, 둘 다 하게 됩니다. ...

Enterprise 환경에서 LLM 기반 시스템을 프로덕션에 배포하려면, 단순히 API를 호출하는 것 이상의 설계가 필요합니다. PoC에서는 잘 동작하던 시스템이 실제 트래픽과 다양한 질의를 만나면 hallucination, 검색 품질 저하, 보안 취약점 같은 문제가 수면 위로 올라옵니다. 이 글에서는 Enterprise LLM 시스템을 설계할 때 반복적으로 등장하는 5가지 핵심 패턴을 정리합니다. 각 패턴은 독립적으로 적용할 수도 있고, 하나의 시스템 안에서 조합할 수도 있습니다. 1. Enterprise RAG: 검색 품질이 답변 품질을 결정합니다 RAG(Retrieval-Augmented Generation)는 LLM이 외부 지식을 참조해서 답변을 생성하는 기법입니다. 원리 자체는 단순하지만, 5만 건 이상의 내부 문서를 다루는 Enterprise 환경에서는 설계 난이도가 급격히 올라갑니다. ...

2026년, AI 에이전트가 도구를 쓰기 시작했다 AI가 질문에 답하는 걸 넘어 실제 업무 도구를 사용하기 시작했습니다. 이메일을 보내고, 문서를 편집하고, 캘린더를 관리합니다. Anthropic의 Claude Cowork는 Gmail, Google Drive, DocuSign 같은 서비스를 플러그인으로 연결해서 반복 작업을 자동화합니다. Spotify는 고객 지원 티켓을 AI 에이전트로 처리하고 있고, Novo Nordisk는 내부 문서 검색과 요약에 활용합니다. AWS가 2026년 3월 발표한 OpenClaw on Lightsail도 비슷한 방향입니다. 터미널 명령을 실행하고, Git 커밋을 만들고, 코드 리뷰를 진행하는 자율 AI 에이전트를 Lightsail 인스턴스 하나로 띄울 수 있습니다. 한 달에 몇 달러면 팀 전용 AI 개발자를 둘 수 있는 셈입니다. ...

1. 왜 모델 성능만으로는 코딩 에이전트를 설명할 수 없는가 AI 코딩 에이전트의 성능을 이야기할 때, 우리는 습관적으로 “어떤 모델을 쓰느냐"부터 묻게 됩니다. 하지만 SWE-bench 리더보드를 조금만 주의 깊게 살펴보면, 같은 기반 모델(base model)을 사용하면서도 에이전트 시스템에 따라 상당한 성능 격차가 발생하는 사례를 어렵지 않게 발견할 수 있습니다. 동일한 모델인데 결과가 크게 달라진다면, 그 차이는 어디에서 오는 걸까요? 핵심은 하니스(Harness), 즉 모델이 코드를 읽고, 수정하고, 실행 결과를 받아보는 도구 인터페이스(tool interface) 설계에 있습니다. 구체적으로 분해하면 다음 요소들이 실질적 병목으로 작용합니다. ...