Tools: 코드만 있으면 충분해요 - Code Is All You Need

• MCP 방식의 도구 연결이 "미래"라고 주장되지만, 실제로는 조합성 부족과 과도한 컨텍스트 소비라는 한계로 인해, 직접 코드를 작성하는 방식이 여전히 더 효율적임
• LLM 시대에도 자동화·반복 작업에서는 코드를 생성/활용하는 것이 신뢰성과 검증 측면에서 우위에 있음
• LLM은 추론 기반 자동화보다 코드 생성 및 반복 실행에 강점, 코드 기반 프로세스는 문제점 파악과 검증, 확장성이 뛰어남
• Playwright 같은 일부 도구(MCP 방식)는 "추론 기반" 단계마다 불확실성과 디버깅 어려움이 커지고, 코드로 스크립트를 직접 생성/수정하면 반복성, 속도, 신뢰도 모두 향상
• LLM이 코드를 생성하고, 또 다른 LLM이 그 코드를 점검·설명하는 "코드-심사-반복" 루프가 실제로는 가장 강력한 자동화 흐름임

코드만 있으면 충분해요

• 만약 트위터에서 나를 팔로우하고 있다면, 최근 Model Context Protocol(MCP)에 대해 별로 긍정적이지 않음을 알 수 있음
• 이유는 아이디어 자체에 대한 거부감이 아니라, MCP가 광고한 대로 효과적이지 않기 때문
• MCP는 두 가지 주요 결함이 있음
  • 진정한 조합성(composable) 을 제공하지 못함
  • 과도한 문맥 제공 요구로 인해, 코드를 직접 작성해 실행하는 것보다 더 많은 문맥 소모가 발생함
• 간단한 실험을 통해 이를 확인할 수 있음
  • 예를 들어, GitHub MCP를 사용해 태스크를 수행한 다음, 동일한 작업을 gh CLI 툴로 해보면, 후자가 훨씬 효과적으로 문맥을 사용하고 더 빠르게 원하는 결과에 도달함

But MCP is the Future! : 하지만 MCP가 미래인데?

• 내가 이 입장(코드가 더 낫다는 주장)에 대해 받은 피드백에 대해 이야기하고 싶음
• 나는 MCP를 에이전트 기반 코딩(agentic coding) 문맥에서 깊이 실험했고, 한계가 가장 뚜렷하게 드러나는 부분에서 평가함
• 한 가지 피드백은, "MCP가 범용 코드 생성에는 굳이 필요하지 않다. 이미 모델이 코드 생성엔 충분히 뛰어나기 때문"이라는 점임. 반면 특정 도메인(예: 금융 기업의 자동화 업무) 같은 엔드유저 지향 애플리케이션에서는 MCP가 의미 있을 수 있다는 의견도 받음
• 또 다른 의견은, 미래에는 모델이 더 다양한 도구에 접근하고 더 복잡한 작업도 처리할 수 있을 테니, 그 가능성에 주목해야 한다는 것임

• 하지만 내 현재 판단은 이러함: 내가 실험한 데이터와 실제 경험에 따르면, 현재의 MCP는 항상 코드 직접 작성보다 사용이 어렵다
  • 가장 큰 이유는 MCP가 추론(inference)에 의존하기 때문임
  • 요즘 "더 많은 툴을 LLM에 연결하려는 모든 시도"를 보면, 결국 LLM이 모든 툴을 받아서 작업에 맞게 필터링하는 계층이 들어감
  • 지금까지 이보다 더 좋은 구조나 접근 방식이 제안된 적이 없음

• 그래서 나는 이렇게 결론내림: 비개발자용 특정 도메인 자동화 같은 특수한 경우에도, 결국 코드 생성이 조합성과 재사용성 면에서 항상 더 나은 선택

Replace Yourself With A Shellscript

• 이 문제를 바라보는 방법: AI가 없을 때, 개발자라면 문제를 해결하는 도구는 코드임
• 비개발자라면 코드가 어렵고, 많은 사람들이 수작업으로 하는 여러 작업도 사실 소프트웨어로 자동화 가능함
• 현실적인 문제는 누가 그 코드를 써주느냐임. 만약 특수한 환경에 있고 직접 프로그래밍을 못한다면, 코딩을 새로 배우기도 어렵고, 누군가가 맞춤형 코드를 써주기를 기대하기도 힘듦
• 물론 일부 작업은 추론(인간의 판단/유연성) 이 꼭 필요할 수 있지만, 사실상 반복적이고 명확한 작업은 대부분 코드로 자동화 가능함

• “나 자신을 셸 스크립트로 대체한다”는 오래된 개발자 관용구가 있는데, 실제로 이런 자동화는 예전부터 지속되어 왔음
• LLM과 프로그래밍의 시대에는, 셸 스크립트 대신 LLM으로 나 자신을 대체하려고 하지만, 여기서 세 가지 문제(비용, 속도, 신뢰성) 가 등장함
• 이 세 가지 문제를 해결하기 전에는, 도구(MCP 등) 사용을 고민할 단계조차 아님
• 즉, 자동화가 실제로 확장 가능한 방식으로 제대로 동작하는지를 먼저 보장하는 것이 핵심임

Automation at Scale : 대규모 자동화의 본질

• 자동화의 핵심은 반복적·재사용 가능한 작업을 코드로 처리하는 것임
• 한 번만 하고 다시는 안 할 작업은 자동화할 필요가 없음. 여러 번 반복할 작업, 기계가 진짜 생산성 이득을 주는 일부터 자동화가 시작됨
• 실제로 1~2번 수동으로 해보고, 동작 방식을 정리한 뒤, 기계가 수천 번 반복 수행하도록 만드는 것이 자동화의 본질임

• 이런 반복적 자동화에는 항상 "코드"를 쓰는 것이 최선임
  • LLM에게 "추론"으로 매번 시키면, 작은 일은 그럭저럭 되지만, 검증에 드는 시간/노력이 결국 자동화 효과를 반감시킴
  • 예: LLM에게 계산을 직접 시키는 것보다는, LLM이 파이썬 코드를 작성하게 하고, 그 코드로 계산하게 하면 신뢰도·확장성 모두 높아짐
    • 코드를 사용하면 공식/로직 자체를 검토 가능하고, 필요시 직접 수정하거나 LLM이 "이 방식이 맞는가"를 심사하도록 할 수도 있음
    • 파이썬이 계산을 잘못한다는 걱정은 할 필요가 없으니, 코드 생성 방식이 검증/신뢰 측면에서 더 낫다는 점이 분명해짐

• 이런 논리는 단순 계산을 넘어서서 실제 개발 실무에도 적용됨
  • 예: 최근 이 블로그의 전체 포맷을 reStructuredText에서 Markdown으로 변환하는 작업을 했음
  • 꽤 오래 미루고 있었는데, 귀찮기도 했지만, LLM에게 직접 변환을 맡기면 어딘가 미묘한 누락/실수나 맥락 왜곡이 생길까봐 신뢰하지 못함
  • 그래서 결국 LLM을 "직접 변환 실행"에 쓰지 않고, 변환용 코드를 생성하게 해서 코드로 처리함

LLM → 코드 → LLM: 반복 검증 자동화의 실제

• 첫 단계로, 나는 LLM에게 reStructuredText를 Markdown으로 변환하는 코어 변환 로직을 생성해 달라고 요청함
  • 단순 변환이 아니라, AST(추상 구문 트리)를 직접 활용해서
    • reStructuredText를 AST로 파싱 → Markdown AST로 변환 → HTML로 렌더링
    • 이렇게 하면 중간 변환 단계를 얻을 수 있고, 결과를 직접 비교·검증하기 쉬워짐

• 두 번째로, LLM에게 기존 HTML과 신규 HTML을 비교하는 스크립트도 작성해 달라고 함
  • 변환 후 HTML의 차이(diff)를 분석하면서, 비교에 앞서 사소한 차이(예: 공백, 푸터노트 처리 방식 등)를 자동으로 보정하도록 설계
  • 변환 과정에서 허용할 수 있는 에러 유형을 LLM이 자체적으로 고려하게끔 함
  • 예: Markdown/ reStructuredText 라이브러리의 HTML 표현이 달라 미세하게 다르더라도, 본질적 손실/오류만 걸러내도록 스크립트에서 반영

• 세 번째로, LLM에게 수백 개 파일의 결과를 일괄 분석하는 배치용 스크립트도 추가로 요청함
  • 이 스크립트로 전체 파일을 돌려가며, 차이가 줄어들 때까지 반복 개선(agentic 루프) 을 진행함

• 전체 과정은 다음과 같음:
  • 처음엔 10개 정도만 샘플로 돌려서 차이가 크게 줄어들 때까지 반복
  • 만족스러운 상태가 되면 전체 포스트에 적용, 30분 내외로 자동 처리
  • 핵심은, LLM이 실제로 변환을 '성공'했기 때문이 아니라, 내가 전체 과정을 "코드"로 검증·리뷰할 수 있었기 때문에 신뢰할 수 있었던 것임

• 여기에 추가로, 다른 LLM에게 생성된 코드와 변경 내용을 점검/해설하게 해 더 높은 신뢰를 얻음
  • 데이터 손실 없이, 기계적으로 올바르게 변환된다는 확신이 있었고, 언제든 샘플 체크·수정이 쉬웠음
  • 최악의 경우에도 마크다운 문법상 사소한 오류만 생길 뿐, 실제 본문 내용이 망가지는 일은 발생하지 않았음

• 또 한 가지 중요한 점은, 이 방식은 추론(inference) 비용이 일정해서 전체 파일 수(15개 vs 150개)에 따른 부담 차이가 크지 않음
  • 최종 분석 단계에서는 이미 사소한 차이는 자동으로 건너뛰기에, 대량 변환에서도 반복 검증 부담이 크지 않음

MCP Cannot Do That

• 이 긴 설명의 요지는 전체 변환·자동화 파이프라인이 "코드"로 돌아간다는 것임
  • 인간 입력 → 코드 생성 → LLM 심사 → 반복 개선, 이런 구조를 일반적인 과제에도 똑같이 적용 가능
• 예를 들어, MCP 방식의 대표 사례인 Playwright가 있음
  • 브라우저를 원격 제어하는 자동화 도구로, 페이지를 읽고 이해하고 버튼을 누르는 등 매 단계마다 추론(inference)이 반복됨
  • 이런 류의 과제는 실제로 "코드 접근"으로 완벽히 대체하기 어렵긴 함

• 하지만, 페이지 구조를 이미 알고 있다면(예: 내가 개발 중인 자체 앱 테스트 등)
  • LLM에게 Playwright 파이썬 스크립트를 생성하게 하고, 그걸 실행하는 방식이 훨씬 빠르고 신뢰성도 높음
  • 이 방식은 한 번 스크립트만 만들면 수십, 수백 번 반복 실행이 가능하고, 추가 추론이 필요 없음
  • 실시간으로 매번 화면을 해석하거나 버튼 위치를 찾지 않아도 되고, 전체 자동화 흐름을 한 번에 실행할 수 있음

• MCP 방식은 매 단계마다 추상화된 도구 호출과 추론이 필요해 LLM이 항상 올바르게 동작하도록 만드는 것이 매우 어렵고, 디버깅도 힘듦
  • 예를 들어 MCP 클라이언트를 셸 스크립트에 임베드해 효율적으로 원격 서비스 호출을 하고 싶어도, 실제로는 이 방식이 매우 비효율적이고 구현도 어렵다는 점을 절감함

• 결국, 나는 인간이지 MCP 클라이언트가 아님.
  • 코드는 실행·디버깅이 쉽지만, MCP 호출은 매번 불확실하고, 신뢰할 수 없음
  • 실제로는 LLM이 코드 생성 중 만들어주는 작은 툴들(예: Claude Code의 스니펫)을 오히려 내 개발 프로세스의 장기적 도구로 활용하고 있음

이 결론은 어디로 이어질까?

• 솔직히 나도 이 흐름이 어디로 이어질지는 모름. 하지만 지금이야말로 "의도적 에이전트 코딩(agentic coding)"을 위한 코드 생성 방식을 어떻게 더 개선할 수 있을지 고민하기 좋은 시점임
• 이상하게 들릴 수 있지만, MCP도 가끔은 정말 잘 동작하는 경우가 있음. 하지만 현재 구조는 너무 "추론"에 의존하고, 확장성 있는 대규모 자동화에는 적합하지 않은 막다른 골목처럼 느껴짐

• 그래서 아마도 MCP가 강점을 발휘할 수 있는 영역과, 코드 생성 방식의 역할을 더 명확하게 분리·추상화하는 방법을 찾아야 할 듯함
  • 이를 위해선 더 나은 샌드박스(안전 실행 환경) 를 만들고, 에이전트가 API를 자유롭게 "팬아웃/팬인(fan out/fan in)" 추론을 할 수 있게 API 설계를 바꾸는 시도도 필요함
  • "코드로 할 수 있는 건 최대한 코드로 처리"하고, 대량 실행 이후엔 LLM이 전체 결과를 판정·리뷰하는 구조가 바람직하다고 생각함

• 그리고 코드 생성 과정에서 충분한 맥락 정보를 추가해서, LLM이 생성된 스크립트가 무슨 일을 하는지 비개발자에게 자연어로 설명할 수 있게 한다면, 향후 이 자동화 흐름을 비개발자들도 손쉽게 활용할 수 있을 것임

• 결론적으로, 나는 MCP 대신 LLM의 코드 생성 능력을 더 과감하게 활용하고, 새로운 가능성을 실험하길 추천함
• LLM이 코드를 직접 쓰게 두면, 우리가 상상하는 것보다 훨씬 더 많은 것을 자동화할 수 있음

참고 자료

• 나의 Agentic Coding Talk (영상)
• Drew Breunig 의 How to fix your context (글)
• Manuel Odendahl 의 MCPs are Boring (영상)