저는 Codex에게 동일한 작업을 부여하여 세 가지 Godot MCP를 테스트했습니다:

Godot 3.6 프로젝트에 연결하고 이를 Godot 4.6으로 마이그레이션하십시오.

간단한 테스트입니다.

동일한 프로젝트. 동일한 프롬프트 (Prompt). 서로 다른 MCP들.

그중 하나는 제가 직접 만든 MCP인 Fennara였습니다. 나머지 두 개는 Godot AI와 Godot MCP Native였습니다.

프로젝트의 시작 상태는 다음과 같았습니다:

• 208개의 에러 (errors)
• 73개의 경고 (warnings)

따라서 이것은 깔끔하고 작은 데모가 아니었습니다. 실제의 엉망진창인 마이그레이션 테스트였습니다.

테스트 1: Fennara

Fennara는 Codex가 올바른 Godot 프로젝트에 연결되었는지 확인하는 것으로 시작했습니다.

그 다음 Codex는 프로젝트 전체에 대해 진단 (diagnostics)을 실행했습니다.

이 지점에서 Fennara가 큰 도움이 되었습니다.

Fennara는 단순히 에디터 출력 패널을 읽는 것에 그치지 않고 다음과 같은 사항들을 표면화했습니다:

• 스크립트 에러 (script errors)
• 씬 에러 (scene errors)
• 셰이더 에러 (shader errors)
• 이전 버전의 Godot API 에러 (old Godot API errors)
• 에디터에 명확하게 표시되지 않은 에러들

Codex는 또한 Fennara의 get_class_info 도구를 여러 번 사용했습니다.

이는 Godot 3에서 Godot 4로의 마이그레이션에는 많은 API 변경 사항이 있기 때문에 매우 중요합니다.

만약 AI가 새로운 API를 추측한다면, 잘못된 코드를 쉽게 작성할 수 있습니다.

하지만 AI가 Godot에 직접 물어볼 수 있다면, 수정 작업이 훨씬 더 안전해집니다.

Codex가 Fennara를 통해 파일을 수정했을 때, 쓰기 결과로 해당 스크립트에 대한 새로운 에러와 경고가 즉시 반환되었습니다.

따라서 Codex는 단순히 코드를 작성하고 작동하기를 바라는 것이 아니었습니다.

수정 후에 Godot로부터 피드백을 받고 있었습니다.

그것이 핵심입니다.

AI 에이전트는 맹목적으로 구축해서는 안 됩니다.

네, Fennara의 쓰기 도구들은 더 느립니다.

하지만 더 느린 이유는 더 신중하기 때문입니다.

모든 동작이 에디터에 즉각적으로 반영되었습니다. 다른 MCP들에서 나타났던 에디터 캐싱 (caching) 문제를 겪지 않았습니다.

또 다른 진단 실행 후, 에러가 대폭 감소했습니다.

Fennara는 런타임 에러 (runtime errors)를 잡아내는 데도 도움을 주었습니다. 한 가지 예로, AnimationPlayer에서 add_animation을 호출하는 오래된 코드가 있었습니다.

결과적으로 Codex는 스스로 훨씬 더 나은 상태에 도달했습니다. 저는 수정 과정을 수동으로 안내하지 않았습니다.

테스트 2: Godot AI

다음으로 Godot AI를 테스트했습니다.

Codex에게 다시 동일한 마이그레이션 프롬프트를 주었습니다.

그것은 프로젝트를 실행하는 것으로 시작했습니다.

문제는 해당 도구가 프로젝트가 실행 중이라고만 말한다는 것이었습니다. 씬(scene)이 깨져 있었음에도 불구하고 런타임 에러 (runtime error)를 명확하게 반환하지 않았습니다.

그러자 Codex는 게임 및 에디터 로그 (logs)를 읽기 시작했습니다.

그리고 여기서부터 상황이 엉망이 되었습니다.

에디터 로그 안에는 오래된 에러들이 포함되어 있었습니다.

어떤 에러들은 파일이 변경되기 전의 것이었습니다. 어떤 것들은 더 이상 유효하지 않았습니다.

Codex도 이 점을 알아차렸습니다.

그것은 기본적으로 로그에 현재 디스크에 존재하지도 않는 라인에 대한 에러가 여전히 남아 있다고 말했습니다.

이것은 큰 문제입니다.

AI가 오래된 로그를 신뢰하게 되면, 더 이상 존재하지 않는 에러를 수정하기 시작하기 때문입니다.

나중에 Codex는 터미널 출력이 더 깔끔하기 때문에 터미널에서 Godot 실행 파일 (executable)을 직접 사용하는 방식을 택했습니다.

그것이 도움이 되긴 했지만, MCP가 진정으로 깔끔한 피드백 루프 (feedback loop)를 제공하지는 못했습니다.

어느 시점에서 Codex는 마이그레이션이 완료되었다고 생각했습니다.

하지만 프로젝트를 다시 불러온 후에도 여전히 약 30개의 에러가 남아 있었습니다.

그래서 저는 그것이 계속 진행할 수 있도록 씬을 실행하고 몇 번의 스크린샷을 제공해야 했습니다.

테스트 3: Godot MCP Native

그다음 Godot MCP Native를 테스트했습니다.

이것 역시 유사한 문제들이 있었습니다.

처음에 Codex는 모든 도구 (tools)를 제대로 찾지 못해서, 제가 리포지토리 (repo)의 README를 제공했습니다.

그 이후에 그것은 도구들을 더 잘 이해했습니다.

하지만 이것은 또한 도구가 너무 많을 때의 단점 하나를 보여주었습니다.

에이전트 (agent)가 무엇을 사용해야 할지 모를 수 있다는 점입니다.

마이그레이션 과정 동안, Codex는 여전히 MCP를 사용하는 대신 터미널에서 Godot을 직접 실행하는 것에 많이 의존했습니다.

그리고 네, Codex는 그런 방식으로도 여전히 문제를 해결할 수 있습니다.

하지만 이번 테스트는 단순히 Codex가 결국 프로젝트를 고칠 수 있는지에 대한 것이 아니었습니다.

테스트의 목적은 다음과 같았습니다:

MCP가 Codex가 Godot 프로젝트 상태를 이해하는 데 얼마나 도움이 되는가?

Codex가 완료되었다고 생각한 후, 저는 프로젝트를 다시 불러왔습니다.

여전히 에러들이 남아 있었습니다.

주요 차이점

가장 큰 차이점은 피드백이었습니다.

Godot 마이그레이션 작업을 위해서는 AI에게 파일 접근 권한 이상의 것이 필요합니다.

Godot으로부터의 신뢰할 수 있는 피드백이 필요합니다.

제가 발견한 가장 큰 문제들은 다음과 같습니다:

• 오래된 에디터 출력 (stale editor output)
• 명확하게 반환되지 않는 런타임 에러 (runtime errors)
• 파일 쓰기 후의 에디터 캐시 문제 (editor cache issues)
• 이미 사라진 에러를 수정하려는 에이전트 (agents)
• 너무 많은 도구들로 인해 발견이 더 어려워짐
• 충분하지 않은 직접적인 Godot API 컨텍스트 (context)

이것이 제가 더 적은 도구를 사용하되, 더 깊은 피드백을 제공하도록 Fennara를 구축한 이유입니다.

Fennara는 단순히 거대한 명령 목록이 되는 대신, 에이전트에게 유용한 Godot 컨텍스트 (context)를 제공하려고 시도합니다:

• 프로젝트 진단 (project diagnostics)
• 편집 후의 스크립트 진단 (script diagnostics)
• 씬(scene) 및 노드(node) 검사
• 변경된 속성 (properties)
• 내보낸(exported) 스크립트 변수
• 부착된 스크립트 정보
• 유효성 검사 경고 (validation warnings)
• 런타임 에러 (runtime errors)
• Godot으로부터의 클래스(class) 및 메서드(method) 정보

그러한 피드백 루프 (feedback loop)가 Codex가 추측하는 것을 방지하는 데 도움이 되었습니다.

마치며

네, 이 영상은 부분적으로 제 자신의 MCP를 찬양하는 내용이 맞습니다.

저도 알고 있습니다.

하지만 테스트에서 보여드린 모든 것은 가감 없는 실제 상황이었습니다.

제가 믿는 핵심은 이것입니다:

MCP가 에이전트에게 제공하는 피드백이 더 신뢰할 수 있을수록, 에이전트가 환각 (hallucinate)을 일으킬 확률은 줄어듭니다.

Godot 프로젝트, 특히 마이그레이션(migration)에서는 이것이 매우 중요합니다.

다양한 MCP를 시도해 보고 여러분의 워크플로 (workflow)에 무엇이 맞는지 확인해 보세요.

어떤 도구는 다른 도구보다 여러분의 스타일에 더 잘 맞을 수도 있습니다.

하지만 저에게 있어 최고의 MCP는 가장 방대한 명령 목록을 가진 것이 아닙니다.

AI가 Godot이 실제로 무엇을 말하고 있는지 이해하도록 돕는 MCP가 최고의 MCP입니다.