MCP 서버를 부수지 않고 구부리는 법 — Nimrod Hauser, Baz
📺 원본 영상: Bending a Public MCP Server Without Breaking It — Nimrod Hauser, Baz 🎙️ 채널: AI Engineer 📅 정리 일자: 2026-04-08 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(코드 에디터, 터미널 출력, 슬라이드 등)는 포함되지 않을 수 있으며, 음성 설명을 토대로 재구성하였습니다.
개요
MCP(Model Context Protocol) 서버가 제공하는 써드파티 툴은 에이전틱 애플리케이션의 강력한 자산이지만, 박스에서 꺼내자마자 그대로 쓰면 오히려 성능 저하와 예측 불가능한 동작, 심하면 보안 사고로 이어질 수 있다. Baz의 파운딩 엔지니어 Nimrod Hauser는 자사 제품인 “스펙 리뷰어(Spec Reviewer)“를 예제 삼아 Playwright MCP 서버를 실제로 구동해보면서, 써드파티 툴을 자신의 유즈케이스에 맞게 “구부리는” 다섯 가지 실천 기법을 단계별로 시연한다. 이 리포트는 그 내용을 상세히 풀어낸다.
왜 써드파티 MCP 툴은 그냥 써선 안 되는가
에이전트에게 툴을 쥐어주는 행위는 비유하자면 신입사원에게 회사 내부 규정도 알려주지 않은 채 도구 창고의 열쇠를 통째로 넘기는 것과 같다. MCP 서버에서 오는 툴이든, 라이브러리에서 온 것이든, 어딘가에서 복사해 온 코드든 — 중요한 것은 그 툴이 ‘다른 팀이 작성한 코드’라는 사실이다. Hauser는 이러한 써드파티 툴의 본질을 “설명(description)이 붙은 호출 가능한 함수(callable function)“로 정의한다. 여기서 핵심은 함수 자체보다 설명에 있다. 에이전트는 이 설명을 보고 언제, 어떻게 해당 툴을 호출할지 결정하기 때문이다.
문제는 Playwright 팀처럼 MCP 서버를 만드는 사람들이 세상에 존재하는 수천 가지 유즈케이스를 모두 알 수 없다는 데 있다. 그들이 작성한 설명은 필연적으로 범용적이고 피상적일 수밖에 없다. press_key 툴의 설명이 “Press a key on the keyboard”이고, browser_resize의 설명이 “Resize the browser window”인 것은 Playwright 팀의 잘못이 아니다. 그들은 자신들의 임무를 충실히 수행한 것이다. 하지만 이 얕은 설명 위에서 작동하는 에이전트는 올바른 판단을 내리기 어렵고, 그 결과는 잘못된 결과물, 준최적 동작(suboptimal behavior), 혹은 보안 취약점으로 나타날 수 있다.
특히 멀티테넌트(multi-tenant) 아키텍처처럼 클라이언트 간 데이터 격리가 중요한 환경에서는 에이전트가 아키텍처를 충분히 인지하지 못한 상태에서 툴을 마구 호출할 경우, 한 클라이언트의 데이터가 다른 클라이언트에게 노출되는 사고가 일어날 수 있다. 에이전트는 본질적으로 비결정론적(non-deterministic)이며 예측하기 어렵다. 여기에 써드파티 툴을 더하면 “불확실성의 스케일업”이 발생한다.
유즈케이스 — Baz의 스펙 리뷰어
강연자는 추상적 논의를 피하고 실제 제품을 예제로 사용한다. Baz의 스펙 리뷰어는 요구사항과 실제 구현을 비교하는 에이전틱 QA 시스템이다. 동작 흐름은 크게 두 단계로 나뉜다.
첫 번째 단계에서 에이전트는 요구사항을 수집한다. Jira나 Linear 같은 티켓팅 시스템에 접근해 작업 지시서를 읽고, Figma 디자인을 멀티모달 방식으로 시각적으로 파악한다. 즉, 개발자가 어떤 화면을 구현해야 하는지를 이해하는 것이다.
두 번째 단계에서는 Playwright MCP 서버를 통해 실제 브라우저를 열고, 해당 브랜치를 체크아웃한 시스템에 접속하여 구현 결과를 직접 탐색한다. 에이전트는 요구사항 대비 구현의 충족 여부를 판단하고, 최종적으로 합격(pass) 또는 불합격(fail) 판정을 내리며, 스크린샷을 증거로 첨부한다. 이를 통해 주로 PM이 수행해온 단순 검증 작업의 상당 부분을 자동화할 수 있다.
이 예제의 구체적인 시나리오는 다음과 같다. 에이전트는 설정 드로어(configuration drawer)가 Baz 시스템의 에이전트(Agents) 탭 안에 존재하는지, 그리고 주어진 디자인과 일치하는지를 검사해야 한다. 티켓 스크린샷과 Figma 디자인 이미지가 인간 프롬프트에 멀티모달로 포함되어 있으며, 시스템 프롬프트에는 “먼저 티켓을 읽고, 시스템을 탐색하고, 최종적으로 스크린샷을 증거로 판정을 내리라”는 지침이 담겨 있다.
V0 베이스라인 — 그냥 쓰면 어떻게 되는가
강연자는 먼저 아무 최적화 없이 LangChain의 load_mcp_tools 메서드만 사용하는 베이스라인(V0)을 실행한다.
💡 [영상 참조] 이 시점에서 강연자는 코드 에디터를 통해 MCP 설정 및 에이전트 초기화 코드를 보여주며 설명합니다. 📺 원본 영상에서 확인하세요.
브레이크포인트를 걸고 실행하면 Playwright MCP 서버가 총 21개의 툴을 제공한다는 사실이 확인된다. browser_close, browser_resize, console_messages, handle_dialogue, file_upload, fill_form, press_key 등 브라우저 조작에 관한 모든 것이 포함되어 있으며, 각 툴의 설명은 앞서 언급한 대로 극도로 단순하다.
11:21 - Playwright MCP가 기본 제공하는 21개 툴 목록과 각 툴의 얕은 설명(browser_close, press_key 등)
에이전트는 실행된 후 로그인을 시도하고 시스템을 탐색하지만, 결과는 실패였다. 판정은 “불합격”이었고, 에이전트는 존재하지 않는 baz.co/spec-reviewer라는 URL을 스스로 만들어내 접근을 시도했다. 증거로 첨부한 스크린샷도 404 페이지였다. 이는 툴이 최적화되지 않은 상태에서 에이전트가 얼마나 쉽게 환각(hallucination)에 빠지는지를 보여주는 전형적인 사례다.
다섯 가지 실전 기법
베이스라인의 실패를 확인한 후, 강연자는 점진적으로 툴 처리 방식을 개선하는 다섯 가지 기법을 소개한다. 코드는 V1부터 V5까지 단계별로 구성되어 있으며, 각 버전은 이전 버전을 상속하여 get_tools 메서드를 점진적으로 고도화하는 구조다.
1. 툴 큐레이션(Tool Curation) — 맥락 창의 노이즈를 줄여라
첫 번째 기법은 가장 단순하면서도 즉각적인 효과를 낸다. 21개의 툴 중 스펙 리뷰어의 작업에 실제로 필요하지 않은 것들을 솎아내는 것이다. 예를 들어 브라우저 창 크기 조정, 드래그, 브라우저 내 코드 실행 등은 스펙 리뷰어가 수행하는 작업과 무관하다. V1은 이러한 툴 6개를 제외 목록에 넣어 에이전트에게 전달되는 툴을 16개로 줄인다.
💡 [영상 참조] 강연자는 Python 리스트 컴프리헨션으로 제외 목록을 처리하는 코드를 보여줍니다. 📺 원본 영상에서 확인하세요.
17:27 - V1 큐레이션 적용 후 브레이크포인트에서 툴 개수가 21개에서 16개로 줄어든 결과
이 접근법의 논리는 명확하다. 에이전트의 컨텍스트 창(context window)에 들어가는 툴이 적을수록 선택지가 단순해지고, 에이전트가 잘못된 툴을 선택할 확률도 줄어든다. 물론 모든 기법이 컨텍스트를 줄이는 방향으로 작동하지는 않는다. 이후 기법들은 오히려 컨텍스트를 늘리기도 한다. 중요한 것은 양이 아니라 적절성이며, 이것이 바로 이 강연 전체를 관통하는 트레이드오프(trade-off)다.
2. 툴 래핑(Tool Wrapping) — 설명을 유즈케이스에 맞게 재작성하라
두 번째 기법은 기존 툴의 기능은 그대로 두되, 설명(description)을 자신의 유즈케이스에 맞게 새로 작성하는 것이다. ToolWrapper 클래스는 원본 툴을 받아 강화된 설명이 붙은 새 툴을 반환하는데, 내부적으로는 원본 툴을 그대로 호출할 뿐이다. 핵심 변화는 에이전트가 읽는 설명에 있다.
예를 들어 Playwright의 접근성 스냅샷(accessibility snapshot) 툴은 이름만 보면 시각적 스크린샷처럼 보이지만, 실제로는 현재 페이지의 버튼·메뉴·링크 등을 텍스트 구조로 표현해준다. 에이전트가 페이지 구조를 이해하는 데 매우 유용하지만, 기본 설명만으로는 에이전트가 이를 적극적으로 선택하지 않는다. 강화된 설명에는 이렇게 명시할 수 있다. “클릭이나 호버(hover) 같은 인터랙션 툴을 호출하기 전에 반드시 이 툴을 먼저 호출하라. 실제 스크린샷보다 이 툴을 우선적으로 사용하라.” 이 한 줄이 에이전트의 행동 패턴 전체를 바꿀 수 있다.
💡 [영상 참조] 강연자는 툴 이름을 키로, 강화된 설명을 값으로 갖는 딕셔너리 구조와
wrap_playwright_tools함수 코드를 화면에 보여줍니다. 📺 원본 영상에서 확인하세요.
실행 결과, 브레이크포인트에서 툴 설명들이 눈에 띄게 길어져 있음을 확인할 수 있다. browser_snapshot의 설명에는 접근성 스냅샷의 용도와 우선 사용 지침이 담겨 있고, browser_click에는 “클릭 전에 반드시 스냅샷 툴을 먼저 호출하라”는 안내가 포함된다. 이제 에이전트는 Playwright 팀이 의도한 일반적인 행동 방식이 아닌, Baz의 스펙 리뷰어가 원하는 방식대로 움직일 준비가 된 것이다.
22:06 - V2 래핑 적용 후 browser_snapshot, browser_click 등의 툴에 강화된 설명이 부착된 상태
3. 결정론적 가드레일(Deterministic Guardrails) — 민감한 작업은 에이전트에게 맡기지 마라
세 번째 기법은 성격이 다소 다르다. 앞선 두 기법이 컨텍스트 엔지니어링(context engineering)의 영역이라면, 이것은 하드코딩된 제약이다. 에이전트는 비결정론적이며, ‘바늘 찾기(needle in a haystack)’ 현상이나 ‘중간에서 길을 잃는(lost in the middle)’ 현상처럼 긴 컨텍스트 속에서 중요한 지시사항을 놓치는 경우가 발생한다. 아무리 프롬프트와 툴 설명에 공을 들여도, 에이전트가 이를 무시할 가능성을 완전히 배제할 수 없다.
스펙 리뷰어에서 이 문제가 가장 두드러지게 나타나는 곳은 스크린샷 저장 경로다. 에이전트에게 지정된 폴더에만 이미지를 저장하라고 명시했어도, 에이전트는 전혀 다른 경로에 파일을 저장하려 할 수 있다. V3에서는 이를 결정론적으로 차단한다. path_validation 헬퍼 클래스는 스크린샷 툴이 실제로 호출되기 직전, 에이전트가 지정하려는 파일 경로를 가로채 올바른 스크린샷 폴더 내에 위치하는지를 검사한다. 경로가 유효하지 않으면 툴 호출 자체가 차단되며, 예외(exception)를 발생시킨다.
여기서 중요한 설계 포인트가 있다. 강연자는 예외를 전체 에이전틱 프로세스를 종료시키는 방식으로 처리하지 않는다. 대신 에이전트가 읽기 쉬운 오류 메시지를 반환한다. “접근이 거부되었습니다. 해당 경로에 저장할 수 없습니다. 올바른 폴더와 파일 이름을 사용해주세요”와 같은 메시지를 받은 에이전트는 대부분 올바른 경로로 재시도한다. 프로세스가 멈추는 것이 아니라 에이전트가 교정되는 것이다. 이는 특히 멀티테넌트 환경에서 데이터 격리를 강제하는 데 동일하게 적용할 수 있는 강력한 패턴이다.
25:45 - V3 가드레일 코드 — create_playwright_tool_wrapper 함수 내 경로 검증(path_validation) 로직과 에이전트 대상 오류 메시지 구성
4. 기존 툴의 조합으로 새 툴 만들기(Tool Composition) — 전문화된 도구를 직접 창조하라
네 번째 기법은 다소 고급 기술이지만 매우 유용하다. 기존 툴을 빌딩 블록 삼아 완전히 새로운 툴을 만드는 것이다. V4에서 강연자는 “증거 스크린샷 툴(Evidence Screenshot Tool)“을 새로 생성한다. 기능적으로는 일반 스크린샷 툴과 거의 동일하지만, 설명이 전혀 다르다. 이 툴의 설명에는 “이 툴은 오직 증거 수집 목적으로만 사용하라”고 명시되어 있으며, 추가 지침으로 “파일 이름에 관련 티켓 번호를 포함시켜라”는 내용이 담겨 있다.
💡 [영상 참조] 강연자는 V4에서 기존 툴과 새로운 증거 툴을 함께 주입하는 코드를 보여줍니다. 📺 원본 영상에서 확인하세요.
31:28 - V4 증거 툴(evidence tool) 생성 코드 — 새 툴의 설명(description)과 티켓 번호를 파일명에 포함하는 지침
이렇게 하면 에이전트는 상황에 따라 두 툴을 구분해서 사용할 수 있다. 일반적인 탐색 중에 페이지 상태를 확인할 때는 일반 스크린샷 툴을, 최종 판정 단계에서 증거를 남길 때는 증거 스크린샷 툴을 선택하게 된다. 각 툴마다 별도의 가드레일이나 결정론적 전처리 로직을 추가할 수도 있다. “원하는 것을 원하는 시점에 원하는 방식으로” 제어할 수 있는 유연성이 이 기법의 본질이다.
5. 툴을 결정론적 함수로 사용하기(Tool as Deterministic Function) — 에이전트 밖에서 직접 호출하라
다섯 번째이자 마지막 기법은 어떤 의미에서 가장 근본적인 것이다. 때로는 MCP 서버가 제공하는 코드를 에이전트에게 맡기지 말고, 개발자가 직접 호출하는 것이 최선이다. 에이전트는 이 코드의 존재조차 알 필요가 없다.
스펙 리뷰어에서 로그인이 바로 그런 경우다. 로그인은 항상 수행해야 하는 작업이고, 클라이언트마다 인증 방식이 다를 수 있으며, JWT 토큰 같은 민감한 시크릿을 다룬다. V5에서 login_to_baz 함수는 에이전틱 흐름이 시작되기 전에 결정론적으로 실행된다. MCP 툴에서 브라우저 관련 함수들을 직접 꺼내와서, 환경 변수로 숨겨둔 JWT 토큰을 브라우저의 로컬 스토리지에 주입하고 로그인 버튼을 클릭한다. 로그인이 완료되면 그때 비로소 에이전트에게 제어권을 넘긴다.
이 패턴의 핵심은 에이전트의 컨텍스트와 판단 능력을 아껴쓰는 것이다. 결과가 예측 가능하고 항상 수행되어야 하는 작업은 에이전트의 추론 과정에서 제외시키는 것이 더 효율적이고 안전하다.
최종 실행 — 모든 기법을 적용한 결과
다섯 가지 기법이 모두 적용된 상태에서 스펙 리뷰어를 재실행한 결과, 에이전트는 올바르게 작동했다. JWT 토큰이 자동으로 주입되어 로그인이 완료된 상태에서 에이전트가 시작되었고, 시스템 내 에이전트 탭을 성공적으로 탐색해 설정 드로어의 존재를 확인했다. 판정은 “합격”이었으며, 티켓 번호가 파일 이름에 포함된 스크린샷이 증거로 첨부되었다.
💡 [영상 참조] 강연자는 최종 실행 결과 화면과 에이전트가 캡처한 스크린샷을 보여줍니다. 📺 원본 영상에서 확인하세요.
37:57 - 모든 기법 적용 후 최종 실행 결과 — 합격(pass) 판정, 티켓 번호 포함 파일명으로 저장된 설정 드로어 스크린샷 증거
흥미로운 점은 에이전트가 어두운 모드(dark mode)의 디자인 이미지를 기준으로 밝은 모드(light mode) 화면을 탐색했음에도 정확히 요구사항을 파악했다는 것이다. 강연자는 이 토이 예제에서는 픽셀 단위의 정밀도까지는 검증하지 않는다고 솔직히 인정하면서, 실제 제품에서는 패딩·마진·스타일까지 검사하는 픽셀 퍼펙트 검증이 별도로 구현되어 있다고 밝혔다.
마무리 / 핵심 정리
이 강연은 MCP 서버 혹은 어떠한 출처에서 온 써드파티 에이전틱 툴이든, 그것을 그대로 사용하는 것은 출발점에 불과함을 명확히 보여준다. 진짜 엔지니어링은 그 위에서 시작된다. 툴을 걸러내고(큐레이션), 설명을 재작성하고(래핑), 민감한 작업에는 결정론적 제약을 걸고(가드레일), 기존 툴로 새 툴을 조립하고(컴포지션), 필요하다면 에이전트를 완전히 우회해 직접 호출하는(결정론적 함수) 이 다섯 가지 기법은 서로 배타적이지 않다. 유즈케이스에 따라 조합하고 적용 강도를 조절하는 것이 실전이다.
Hauser의 결론은 이렇다. 에이전트의 컨텍스트 창에 무엇이 들어가느냐가 에이전트의 행동을 결정한다. 툴의 설명은 에이전트에게 보내는 일종의 지시서다. 이 지시서를 써드파티 팀이 작성한 채로 방치하는 것은, 자신의 팀도 모르는 타팀의 가이드라인을 따라 일하게 내버려두는 것과 같다. 툴을 자신의 유즈케이스에 맞게 구부리는 것, 그것이 에이전틱 시스템을 실제로 작동시키는 핵심 역량이다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | Bending a Public MCP Server Without Breaking It — Nimrod Hauser, Baz |
| 채널 | AI Engineer |
| 발표자 | Nimrod Hauser (Baz, Founding Engineer) |
| 리포트 작성 | 2026-04-08 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.