꽤 거친 말을 하겠다.

GUI는 대개 비본질적이다.

GUI는 인간이 소프트웨어를 사용하기 위한 조작반이다.

어디에 어떤 기능이 있는지를 메뉴로 보여주고, 버튼을 누르게 하고, 수치를 입력하게 하며, 결과를 화면에 표시한다.

코드를 작성할 수 없는 사람이라도 고도의 소프트웨어를 다룰 수 있도록 하기 위한 메커니즘이다. 이것은 틀림없이 훌륭한 발명이다.

하지만, AI까지 인간과 같은 조작반을 사용할 필요가 있을까.

최근 Unity MCP, Blender MCP, Figma MCP, Excel MCP, 브라우저 조작 MCP 등이 차례차례 등장하고 있다.

자연어로 지시하면, AI가 소프트웨어를 조작한다.

객체가 늘어난다. 표가 채워진다. 그래프가 만들어진다. 게임이 실행된다.

겉보기에는 미래적이다.

하지만 그 이면에서 AI가,

• 사용할 도구를 선택한다
• 하나씩 조작한다
• 결과를 다시 읽는다
• 다음 수를 생각한다
• 스크린샷을 찍는다
• 실패했으므로 다른 조작을 시도한다

라는 처리를 끝없이 반복하고 있다면, 그것은 정말로 현명한 자동화라고 할 수 있을까.

코드를 한 번 실행하면 끝날 작업에, 세상에서 가장 비싼 리모컨을 사용하고 있는 것은 아닌가.

이 기사는 MCP 불필요론이 아니다.

기존 프로젝트를 인간과 공동 편집한다. 전문 소프트웨어가 가진 고도의 기능을 사용한다. 기존의 소재나 플러그인을 활용한다.

그러한 용도에서는 MCP가 강력하다.

하지만 나는 다음의 발상에는 상당히 의구심을 느끼고 있다.

MCP가 있다.

그러니까 그 소프트웨어를 AI에게 조작하게 하자.

순서가 거꾸로 된 것이 아닌가.

가장 먼저 생각해야 할 것은,

그 소프트웨어를 경유할 필요가 정말로 있는가.

이다.

AI에게 CSV로부터 매출 그래프를 만들게 한다고 가정하자.

Excel을 사용한다면, 대개 다음과 같은 절차가 된다.

Excel을 연다
↓
데이터를 붙여넣는다
...

인간이 작업한다면 이것으로 충분하다.

Excel은 많은 사람이 사용에 익숙하다. 결과를 보면서 수정할 수 있고, 나중에 숫자나 서식도 바꿀 수 있다.

하지만 AI에게 시킨다면 어떨까.

나는 평범하게 Python을 작성하게 한다.

import pandas as pd
import matplotlib.pyplot as plt
df = pd.read_csv("sales.csv")
...

이렇게 하면,

무엇을 했는지 코드로 남는다같은 데이터로 몇 번이고 다시 만들 수 있다100종류의 그래프도 루프로 생성할 수 있다Git으로 변경점을 확인할 수 있다Excel의 윈도우 상태에 좌우되지 않는다****AI가 셀이나 메뉴를 하나씩 선택하지 않아도 된다

라는 이점이 있다.

덧붙여, Excel MCP는 실제로 존재한다.

열려 있는 Excel을 읽고 쓰는 것, Microsoft Excel을 설치하지 않고 .xlsx를 조작하는 것, 수식이나 서식을 유지한 채 기존 북(book)을 편집하는 것 등 여러 구현이 공개되어 있다.

그렇다면 Excel MCP는 무의미한가.

그렇지는 않다.

원하는 것이,

• 인간이 나중에 편집할 Excel 장부
• 기존 북의 수식이나 서식을 유지한 수정
• VBA나 피벗 테이블을 포함한 파일
• 납품 형식으로서의 .xlsx

라면 Excel을 사용할 이유가 있다.

하지만 원하는 것이 그래프 이미지 한 장이라면 어떨까.

Excel의 GUI는 중간에 끼어드는 불필요한 층이다.

성과물로서 Excel이 필요한가. 단순히 계산 결과가 필요한가.

이 구분을 하지 않고, "Excel MCP가 있으니까 사용한다"라고 시작하면 AI에게 불필요한 우회로를 걷게 하는 셈이 된다.

같은 일이 게임 엔진에서도 일어나고 있다.

MCP에는 명확한 이점이 있다.

동시에, 아무 생각 없이 사용하면 명확한 불이익도 있다.

요컨대, MCP가 강력한 경우는,

그 소프트웨어를 사용하는 명확한 이유가 있고, AI에게 묶음 처리를 시키는 경우

이다.

반대로 약한 경우는,

AI가 인간의 조작을 한 단계씩 생각하고, 그때마다 상태를 다시 읽어야 하는 경우

다.

MCP는 AI와 외부 소프트웨어를 공통된 형식으로 연결하기 위한 메커니즘이다.

MCP를 도입한다고 해서 다음 사항들이 자동으로 결정되지는 않는다.

• 무엇을 AI에게 맡길 것인가
• 무엇을 일반적인 코드로 맡길 것인가
• 어느 정도로 묶어서 실행할 것인가
• 언제 인간이 확인할 것인가
• 실패했을 때 어떻게 되돌릴 것인가
• 정말로 비용이 절감되었는가

MCP를 연결한 것만으로 자동화가 완성되었다고 생각하지 마라.

그것은 LAN 케이블을 꽂기만 하면 업무 개선이 완료되었다고 생각하는 것과 같다.

MCP의 사용법은 거칠게 두 가지로 나눌 수 있다.

GitHub에서 Issue를 직접 가져온다.

Figma에서 색상이나 여백을 직접 가져온다.

Blender에게 「이 스크립트를 실행해서 내보내라」고 부탁한다.

게임 엔진에게 「테스트를 실행하고, 실패한 것만 반환하라」고 부탁한다.

이러한 사용법은 좋다.

반면,

객체를 배치한다
↓
조금 움직인다
...

을 AI에게 끊임없이 판단하게 하는 것은 정말 필요한 일인가?

게임에는 화면이 있다.

캐릭터가 움직이고, 적이 공격하며, UI가 표시된다. 겉모습이나 조작감은 중요하다.

하지만,

게임이 GUI를 갖는 것

과,

게임을 만드는 AI가 GUI를 주요 조작 방법으로 삼는 것

은 별개의 문제다.

적을 10마리 내보내고 싶다면, AI가 게임 엔진 위에서 10번 복제하게 만들 필요는 없다.

foreach (var point in spawnPoints)
{
  SpawnEnemy(point);
  ...
}

라고 쓰게 하면 된다.

3D 씬에 기둥 100개가 필요하다면, 「기둥 추가」를 100번 실행하게 할 필요는 없다.

for spec in pillar_specs:
  create_pillar(spec)

이면 충분하다.

RPG용 적 데이터가 필요하다면, 이름, HP, 공격력을 GUI에 한 항목씩 입력하게 하는 것보다, 검증된 데이터를 한꺼번에 생성하는 것이 더 빠를지도 모른다.

GUI는 인간에게 편리한 입구다.

AI에게 최단 경로의 입구라고는 할 수 없다.

MCP에서는 AI가 사용할 도구(Tool)의 이름, 설명, 인자(Argument)를 모델에게 전달해야 한다.

도구가 늘어나면 그 설명만으로도 컨텍스트 (Context)를 소비한다.

Anthropic이 공개한 예시에서는 58개의 도구 정의 등으로 인해, 사용자의 요청을 읽기도 전부터 5만 토큰 이상을 사용하는 경우가 있다고 설명되어 있다. 현재는 필요한 도구만 나중에 불러오는 방식 등을 통해 이 문제를 줄이려 노력하고 있다.

문제는 비용뿐만이 아니다.

도구가 늘어날수록,

어떤 기능을 사용할지 망설이거나비슷한 기능을 잘못 선택하거나인자를 틀리거나오래된 기능과 새로운 기능을 혼동하거나본래의 코드를 읽을 여유가 줄어들

가능성도 높아진다.

Reddit에는 MCP 서버를 늘린 결과, 질문을 입력하기도 전부터 약 6만 7000 토큰을 소비했다는 보고도 있다. 물론 개인 환경에서의 측정이며, MCP 전체로 그대로 일반화할 수는 없다. 그럼에도 무제한으로 MCP를 추가하는 것이 공짜가 아닌 것은 확실하다.

사용 가능한 도구를 늘리는 것과 AI가 똑똑해지는 것은 같지 않다.

브라우저 조작용 Playwright MCP는 비교적 잘 만들어진 예시다.

화면을 단순한 이미지로 보는 것뿐만 아니라, 버튼, 입력창, 문장 등을 AI가 읽기 쉬운 형태로 취득할 수 있다.

그 공식 README에는 명확하게 이렇게 적혀 있다.

“CLI invocations are more token-efficient.”

방대한 도구 설명이나 긴 화면 정보를 매번 모델에게 전달하지 않아도 되기 때문에, 높은 처리량이 필요한 코딩 에이전트 (Coding Agent)에서는 CLI 방식이 더 적합할 수 있다고 한다.

브라우저 조작 MCP의 대표 격조차도,

업무에 따라서는 MCP보다 CLI가 더 좋다

라고 인정하고 있다.

당연한 일이다.

같은 조작을 수십 번 반복한다면, AI에게 한 수씩 생각하게 할 필요는 없다.

스크립트를 작성해서 한 번 실행하면 된다.

게임이나 3D 제작에서는 만드는 것보다 그 이후의 확인과 수정 비용이 더 높게 들 때가 있다.

완전 자동화로 수정하게 하려고 하면 다음과 같은 흐름이 된다.

게임이나 장면(Scene)을 실행
↓
스크린샷을 취득
...

이를 몇 번이고 반복한다.

게다가 GUI 소프트웨어에서는 문제의 원인이 한 곳에 있지 않다.

• 코드
• 오브젝트 설정
• 장면(Scene) 구조
• 소재
• 플러그인
• 빌드 설정
• 실행 중에만 존재하는 상태

중 어디에 있는지 알 수 없다.

예를 들어, 여러 층으로 된 3D 장면에서 일부 계단만 방향이 반대로 되어 있다고 가정하자.

AI가 스스로 특정하려면 각 층의 좌표, 회전, 상하층과의 연결, 화면상의 외관을 조사해야 한다.

하지만 인간이 이미지를 보면,

2층과 3층의 계단만 반대. 나머지는 맞음.

으로 끝낼 수 있다.

나아가,

난간은 고쳐져 있다. 그곳은 건드리지 마라. 벽과의 겹침만 수정해라.

라고 전달하면, 변경해서는 안 되는 장소까지 한 번에 지정할 수 있다.

인간을 중간에 개입시키는 것은 자동화의 패배가 아니다.

지금 AI의 약점을 인간의 직관으로 보완하는 것뿐이다.

AI에게 화면을 10번 보여주는 것보다 인간이 한 번 보는 것이 더 저렴한 경우는 흔히 있다.

짧은 브라우저 게임이나 Pong, Flappy Bird에 가까운 소작품이라면 AI는 꽤 잘 만들 수 있다.

하지만,

• 게임 전체를 설계하기
• 코드 작성하기
• 소재 통합하기
• UI 만들기
• 세이브 기능 만들기
• 버그 찾기
• 밸런스 조정하기
• 빌드하기
• 몇 시간 동안 즐길 수 있는 내용 준비하기
• 나중에 유지보수할 수 있는 상태로 만들기

단계까지 거의 무인으로 완성한 중규모 이상의 사례는 아직 일반화할 수 있을 정도로 확립되지 않았다.

2026년의 GameCraft-Bench는 Godot 상에서 AI 에이전트에게 게임을 처음부터 만들게 하는 140개의 과제를 평가했다. 가장 강력한 에이전트라도 종합 점수는 41.46%였으며, 많은 에이전트가 40% 미만이었다. 기본적인 메커니즘은 구현할 수 있어도, 충분한 내용, 이해하기 쉬운 반응, 통일된 외관을 가진 완성된 게임으로 묶어내는 데 고전했다.

GameDevBench에서는 게임 한 편을 만드는 것보다 범위가 좁은 '기존 게임에 기능 추가하기'에서도 최선의 성공률은 54.5%였다. 특히 2D 그래픽을 다루는 과제에서는 성공률이 31.6%까지 떨어졌다.

게다가 JamBench에서는 프로젝트 규모가 커짐에 따라 실행까지 도달하는 비율이 소규모일 때의 80.4%에서 대규모일 때는 5.7%까지 떨어졌다. 코드 에이전트 (Code Agent)를 사용하여 컴파일 (Compile) 비율이 개선되더라도 실제 동작의 질은 개선되지 않았으며, 연구자들은 전체 설계 (Overall Design)가 주요한 장벽이라고 분석하고 있다.

MCP로 조작할 수 있는 기능을 200개로 늘린다면 이 문제는 해결될까.

나는 그렇게 생각하지 않는다.

도구가 부족한 것이 아니다.

전체의 일관성을 장기간 유지하는 능력이 부족한 것이다.

Unity에는 명확한 강점이 있다.

• 다중 환경 빌드 (Build)
• 물리 (Physics)
• 애니메이션 (Animation)
• 에셋 관리 (Asset Management)
• 프로파일링 (Profiling)
• 방대한 기존 에셋 (Assets)
• 각종 SDK와의 연동

이러한 기능들을 사용한다면 Unity를 선택할 가치는 매우 크다.

기존의 Unity 프로젝트를 인간과 공동 편집한다면 Unity MCP도 의미가 있다.

하지만, 작은 단일 환경용 게임에서 이러한 기능들을 많이 사용하지 않는다면 어떨까.

Unity MCP를 연결하더라도,

• 폰트 설정
• 프리팹 (Prefab) 참조
• 씬 (Scene) 상의 설정
• 패키지 (Package) 호환성
• 통신 서비스
• 빌드 대상 고유 설정

은 여전히 남는다.

MCP는 Unity를 조작 가능하게 만든다.

Unity 고유의 번거로움까지 없애주는 것은 아니다.

작은 게임을 만들기 위해, 거대한 통합 환경을 AI에게 통째로 이해시킬 필요가 정말로 있는가.

그 점은 의심해 볼 만하다.

RPG 만들기 (RPG Maker)의 진정한 강점은 최첨단 실행 기술이 아니다.

• 맵 (Map)
• 대화 이벤트 (Event)
• 캐릭터 (Character)
• 직업 (Job)
• 스킬 (Skill)
• 아이템 (Item)
• 전투 (Battle)
• 상점 (Shop)
• 세이브 (Save)

가 처음부터 RPG의 형태로 갖춰져 있다는 것이다.

인간이 전형적인 RPG를 만들기 위한 번거로운 사전 준비를 처음부터 끝내 놓은 것이다.

이것은 매우 강력하다.

하지만, AI가 데이터나 JavaScript를 직접 생성하고, 인간이 나중에 에디터 (Editor)를 만지지 않으며, 표준 전투나 기존 에셋도 사용하지 않는다면 어떨까.

그 경우, RPG 만들기 고유의 입력 화면을 거치는 의미는 희박해진다.

RPG 만들기 MCP가 있으니까 RPG 만들기를 사용하는 것이 아니다.

RPG 만들기의 편리한 부분을 사용하고 싶기 때문에, 필요하다면 MCP를 사용하는 것이다.

순서를 틀려서는 안 된다.

Blender에는 명확한 기술적 가치가 있다.

• 모델링 (Modeling)
• UV
• 애니메이션 (Animation)
• 렌더링 (Rendering)
• 지오메트리 노드 (Geometry Nodes)
• 각종 형식으로 내보내기 (Export)

이것을 처음부터 다시 만드는 것은 어리석은 일이다.

그러니 Blender는 사용하면 된다.

하지만 Blender는 GUI로만 사용할 수 있는 소프트웨어가 아니다.

AI에게 Blender의 버튼을 몇 번이고 누르게 하는 대신, Blender Python을 작성하게 하면 된다.

blender --background scene.blend --python generate.py

100개의 기둥을 하나씩 추가하게 하는 것이 아니라, 100개를 만드는 루프 (Loop)를 작성하게 한다.

MCP는,

• 씬 (Scene) 상태 취득
• 생성 스크립트 실행
• 렌더링 (Rendering)
• 내보내기 (Export)
• 에러 (Error) 취득

을 위해 사용하면 된다.

MCP를 Python의 대체제로 쓰지 마라.

Python을 실행하는 입구로 사용하라.

인간용 소프트웨어에서는 기능이 많을수록 고성능처럼 보인다.

AI에게는 반드시 그렇지 않다.

기능이 늘어날수록,

• 선택해야 할 기능이 늘어난다
• 설정 항목이 늘어난다
• 버그 (Bug)의 원인 후보가 늘어난다
• 읽어야 할 설명이 늘어난다
• 버전 차이가 늘어난다

때문이다.

소규모 게임이라면, 굳이 단순한 환경을 사용하는 가치가 있다.

Pyxel은 Python용 레트로 게임 엔진으로, 16색, 4음 채널 등 의도적으로 강한 제약을 가지고 있다.

보통 생각하면 저기능이다.

하지만, AI에게는 이점이 된다.

선택지가 적다.

API가 작다.

프로젝트 전체를 읽기 쉽다.

제약은 AI의 약점을 보완한다.

무엇이든 할 수 있는 거대한 Editor에 AI를 던져넣기보다, Pyxel처럼 할 일이 압축된 환경이 AI가 정말로 게임 한 편을 완성할 가능성은 더 높을지도 모른다.

raylib은 공식 사이트에서 스스로 이렇게 설명하고 있다.

“no fancy interface, no visual helpers, no gui tools or editors”

화려한 화면도, 시각적인 보조도, GUI 툴도 Editor도 없다. 그저 코드를 작성한다.

작은 게임이라면, 그것으로 충분하다.

입력, 렌더링, 업데이트 처리가 전부 코드에 있다.

AI는 컴파일 에러를 읽고, 수정하고, 재실행할 수 있다.

Inspector에 숨겨진 설정을 찾을 필요가 없다.

Bevy는 Rust로 제작된 데이터 주도형 (Data-driven) 게임 엔진으로, 엔진과 게임 로직에 ECS를 사용한다.

예를 들어 체력을,

#[derive(Component)]
struct Health(i32);

라고 쓸 수 있다.

AI는 체력이 어디에 있는지 GUI에서 찾을 필요가 없다.

Rust 코드를 읽으면 된다.

타입 오류는 컴파일러가 알려준다.

물론, Unity만큼 완성된 Editor나 주변 기능은 없다.

인간에게 사용하기 편한 것과, AI에게 다루기 편한 것은 별개인 것이다.

Godot은 GUI 엔진이지만, 씬을 TSCN이라는 텍스트 형식으로 저장할 수 있으며, --headless를 통한 커맨드 라인 실행도 지원한다.

즉,

AI: 코드와 TSCN을 편집
자동 처리: headless로 테스트
인간: Editor로 외관과 조작감을 확인

이라는 역할 분담이 가능하다.

GUI를 버릴 필요는 없다.

AI에게 GUI만 사용하게 할 필요가 없는 것이다.

이 이야기는 게임에만 국한되지 않는다.

GitHub의 데이터가 필요하다면, Web 화면을 AI에게 조작하게 하지 말고 Issue나 PR을 직접 가져오면 된다.

데이터베이스를 업데이트하고 싶다면, 관리 화면이 아니라 SQL이나 API를 사용하면 된다.

CAD에서 100개의 구멍을 뚫고 싶다면, 면을 100번 선택하게 하는 것보다 파라미터를 부여하여 일괄 생성하는 편이 낫다.

GUI는 마지막에 인간이 확인하고 조정하는 장소로 남겨두면 된다.

AI의 주요 작업 장소로 만들 필요는 없다.

AI 자동화라고 하면, '인간을 전혀 개입시키지 않는 것'이 최고라고 생각하기 쉽다.

나는 그렇게 생각하지 않는다.

AI가 게임 화면을 10번 확인하고, 그때마다,

• 이미지를 읽는다
• 설정을 조사한다
• 원인을 생각한다
• 수정한다
• 재실행한다

정도의 과정을 거칠 바에는, 인간이 한 번 플레이하고 문제점을 피드백하는 편이 낫다.

・HP 표시가 오른쪽 끝에서 잘려 있음
・2층 계단만 반대 방향임
・적이 벽 안에서 출현함
...

이것으로 충분하다.

AI에게 화면을 보여주지 말라는 뜻이 아니다.

볼 필요가 없는 것까지, 몇 번이고 보여주지 마라.

좌표로 판단할 수 있는 문제는 좌표로 판단한다.

겹침은 충돌 검사 (Collision Detection)로 조사한다.

참조 누락은 자동으로 검사한다.

세이브 일치 여부는 테스트한다.

그럼에도 알 수 없는 외관이나 조작감만을 인간이 확인한다.

가장 중요한 질문은 이것이다.

MCP로 할 수 있느냐가 아니라, MCP를 사용함으로써 정말로 비용이 저렴해지는가.

GUI는 인간에게 편리하다.

하지만 인간에게 편리한 절차가 AI에게도 반드시 편리하다는 법은 없다.

AI에게 Excel을 조작시켜 그래프를 그리게 하는 것보다, Python과 Matplotlib을 작성하게 하는 것이 더 빠르다.

AI에게 Blender에서 기둥을 하나씩 배치하게 하는 것보다, Python으로 100개를 생성하게 하는 것이 더 빠르다.

AI에게 Unity의 Inspector를 몇 번이고 변경하게 하는 것보다, C#이나 생성 스크립트를 작성하게 하는 것이 더 빠르다.

AI에게 RPG Maker의 항목을 하나씩 채우게 하는 것보다, 데이터를 한꺼번에 생성하는 것이 더 빠를지도 모른다.

그럼에도 Excel, Blender, Unity, RPG Maker를 사용할 이유가 있다면 사용하면 된다.

기존 자산, 인간과의 공동 작업, 다중 환경으로의 출력, 고성능 렌더러, 전문적인 편집 기능.

그러한 이유가 있다면 MCP는 강력하다.

하지만,

"MCP가 있으니까 그 소프트웨어를 사용한다."

이는 주객전도다.

GUI를 AI가 만지게 하는 것이 목적이 되는 순간, 수단과 목적이 뒤바뀐다.

AI에게 인간용 GUI를 한 클릭씩 조작하게 하지 마라.

한 번에 쓸 수 있는 코드는 한 번에 쓰게 해라.

루프로 끝날 일을 100번의 툴 호출 (Tool Call)로 해결하지 마라.

수치로 확인할 수 있는 문제를 이미지로부터 추측하게 하지 마라.

인간이 한눈에 알 수 있는 것에 수만 토큰을 쓰지 마라.

그리고 무엇보다,

GUI가 정말로 필요한지를 처음에 의심하라.

MCP는 AI와 모든 소프트웨어를 연결하는 미래의 표준이 될지도 모른다.

하지만 그 미래가,

AI가 인간의 마우스 조작을 끝없이 높은 비용을 지불하며 흉내 내는 세상

이라면, 나는 그리 현명한 미래라고 생각하지 않는다.