안녕하세요.

Cocone Engineering 에서 클라이언트 엔지니어 로 근무하고 있는 아라이입니다.

이번에는 AI 코딩 툴 ‘Claude Code’를 이용해 Unity Editor의 GUI(EditorWindow) 12개, 약 5,000줄을 거의 모두 구현하는 실험을 진행했습니다.

12일간의 개발을 통해 초기 코드 생성은 수동 대비 5~10배 빠른 속도로 완료되는 반면, 버그 수정에 전체 공수의 50%가 소요된다는 결과를 얻었기에, 그 상세 내용과 통찰을 전해 드리겠습니다.

서론

이전 다른 Unity 프로젝트에서 AI에 코드 생성을 맡기는 실험을 진행한 바 있으며, AI와 Unity 개발을 결합할 때의 장단점이 어느 정도 파악되었습니다.

그중에서 특히 알게 된 점은 다음과 같습니다.

• GUI나 프리팹(Prefab) 관련 부분은 Unity 특유의 구조가 강해 AI가 오류를 일으키기 쉽다
• 반면 에디터 확장은 코드 기반으로 완결되기 때문에 비교적 안정적이다
• 다만, 에디터 확장이라 하더라도 로직과 뷰(GUI)를 명확히 분리하는 편이 구현 정확도가 높다

이러한 결과를 바탕으로, GUI(EditorWindow)를 포함해 AI에 맡기면 어떻게 되는지 검증하는 2단계로서 이번 실험을 실시했습니다.

목표는 ScriptableObject 기반의 마스터 데이터 관리 패키지 개발 과정에서 Unity Editor GUI를 포함해 AI에 거의 모든 구현을 위임하고, 품질 · 버그 경향 · 사람의 개입량 · 개발 속도를 검증하는 것입니다.

실험 개요

실험 목적

이번 실험에서는 AI에 Unity Editor GUI 구현을 어느 정도까지 맡길 수 있는지 확인하는 것을 주된 목적으로 삼았습니다.

구체적으로는 ScriptableObject 기반의 마스터 데이터 관리 패키지 개발을 소재로 하여, 다음 4가지 사항을 동일 프로젝트의 일련의 작업 과정에서 검증합니다.

검증 항목	내용
품질	생성된 GUI는 그 자체로 실제 업무에 바로 적용할 수 있는 수준인가
버그 경향	어떤 종류의 버그가 발생하기 쉬운가
사람의 개입량	리뷰, 테스트, UX 조정 등 인간이 책임져야 할 작업은 무엇인가
개발 속도	초기 생성부터 버그 수정까지 포함하여, 실질적인 생산성이 향상되는가

Unity Editor GUI는 EditorWindow 나 SerializedObject、IMGUI의 렌더링 경로(Layout / Repaint) 등, Unity 특유의 API나 암묵적 지식이 많이 요구되는 영역입니다.

문서만으로는 파악하기 어려운 제약 조건도 많아, AI에게는 비교적 난이도가 높은 대상이라고 생각합니다.

따라서 이 영역에서 실용적인 품질에 도달할 수 있다면, 보다 직관적인 로직 구현이나 테스트 생성에서는 당연히 성립할 것이라는 하한선 벤치마크로서의 위치로 실험을 설계했습니다.

실험 조건

항목	내용
실험 기간	2026/01/29 〜 2026/02/09(12일간)
사용 툴	Claude Code (Claude Opus 4.6), Codex CLI
Unity Version	6000.0+
GUI기술	Unity IMGUI (EditorWindow, EditorGUILayout)

※ Codex CLI는 OpenAI가 제공하는 터미널에서 작동하는 AI 코딩 에이전트입니다.

본 실험에서는 코드 리뷰 용도로 사용했습니다.

대상 패키지의 기능

개발한 패키지는 ScriptableObject를 기반으로 한 마스터 데이터 관리 도구입니다. 주요 기능은 다음과 같습니다.

• 테이블 정의(YAML) 생성 및 편집
• CSV/데이터 가져오기·내보내기 및 차이점 미리보기
• 레코드 CRUD 조작
• SQL 스타일 쿼리 실행(JOIN, GROUP BY, 집계 함수 포함)
• 유효성 검사, 스키마 비교
• 성능 측정 및 모니터링
• 백업 관리
• 테스트 데이터 생성

구현 규모

카테고리	수량
EditorWindow	12개
Inspector / PropertyDrawer	4개
GUI 관련 코드 합계	약 5,000줄
Runtime 코드	약 10,000줄
테스트 코드	약 3,000줄
개발 페이즈	Phase 0 〜 Phase 10

생성된 EditorWindow 목록

Window	라인 수	개요	AI생성
DataEditorWindow	908줄	레코드 편집, CRUD조작	✅
DiffViewerWindow	548줄	불러오기 차분 미리보기	✅
SqlEditorWindow	481줄	SQL입력, 구문강조, 결과 표시	✅
BenchmarkWindow	472줄	성능 측정	✅
DatabaseBrowserWindow	447줄	테이블 목록, 레코드 관람	✅
ValidationWindow	378줄	유효성 결과 표시	✅
SchemaCompareWindow	328줄	스키마 차분 비교	✅
TestDataGeneratorWindow	306줄	테스트 데이터 생성	✅
TableEditorWindow	285줄	테이블 정의 YAML편집	✅（일부 수동）
PerformanceWindow	279줄	런타임 성능 감시	✅
BackupWindow	279줄	백업 관리	✅
StreamingImportWindow	150줄	대량 데이터 스트리밍 불러오기	✅

개발 타임라인

Day 1 (1/29): Phase 0~7 일괄 처리

시간	내용	비고
09:09	Initial commit	기존 코드 투입
11:53	CLAUDE.md・로드맵 작성	AI에게 프로젝트 방침을 전달
12:15	Phase 0: CSVParser수정	테스트 수정 포함
13:11	Phase 1: MVP완료	TableAsset, Database, TableEditorWindow
14:12	Phase 2: SecondaryKey완료	IndexBuilder, QueryResult
14:30	Phase 3: CSV Import/Export완료	DiffViewerWindow
15:09	Phase 4: SQL Editor완료	SqlEditorWindow, DatabaseBrowserWindow
16:33	Phase 6: Validation완료	ValidationWindow
16:46	Phase 7: Performance완료	BenchmarkWindow, PerformanceWindow

하루 만에 7개 단계, 7개의 EditorWindow가 생성되었습니다. 다만, 이 시점에서는 ‘작동은 하지만 결함이 있는’ 상태인 것이 다수 있었습니다.

Day 2 (1/30): Phase 8~10 + 테이블 에디터

내용	비고
Phase 8: 추가 툴	BackupWindow, DataGeneratorWindow, SchemaCompareWindow
Phase 9: 고도 SQL기능	JOIN, GROUP BY, 집계 관수
Phase 10: 테스트 확충	SQL실행 테스트
테이블 에디터(정의 YAML)	중간까지

Day 3-4 (1/31-2/1): 버그 수정

일자	수정 내용
1/31	테이블 에디터 완성, 타이밍 미스・문자 깨짐 수정
2/1	DatabaseBrowserWindow – 비공개 필드 가져오기 실패
2/1	SchemaCompareWindow – 버그 수정
2/1	SqlEditorWindow – 결과가 표시가 안되는 버그
2/1	DataEditorWindow – DateTime형 컬럼 편집 지원 추가
2/1	코드 클린업 – private+SerializeField전제에 수정

Day 5~6 (2/2~2/3): 대규모 리팩토링 + 버그 수정

내용	비고
SqlEditorWindow 버그 수정	COUNT결과가 (null), GROUP BY표시가 형태 명으로 보임
SqlEditorWindow 테스트 추가	버그가 많았으므로 중점적으로 대응
SqlExecutor의 분할 리팩토링	1개 파일 2,000 줄 넘김 → 5개 파일로 분할
복합 인덱스 기능 구현	PR리뷰 → 수정 의 사이클
도큐먼트・샘플 작성	—

발견된 주요 버그

카테고리별 버그 집계

카테고리	건수	심각도
데이터 가져오기 실패	4건	고
표시 버그	5건	중〜고
형태・이름의 불일치	3건	중
잘못된 로직	3건	고
그외	2건	저

대표적인 버그 상세 정보

【Bug 1】 SqlEditorWindow – COUNT결과가 (null)

증상: SELECT COUNT(*) FROM ItemTable 의 결과가 (null) 로 표시됨.

원인: GetFieldValue 함수가 ResultRow(집계 결과 전용 타입)를 예상하지 못했습니다. AI가 생성한 SqlExecutor 는 집계 결과를 독자적인 ResultRow 로 반환하지만, 표시 측의 SqlEditorWindow 는 일반적인 레코드 타입만 예상하고 있었습니다.

교훈: AI는 개별 컴포넌트를 올바르게 생성하지만, 컴포넌트 간의 인터페이스 일관성에는 취약한 경향이 있습니다.

【Bug 2】 DatabaseBrowserWindow – 비공개 필드 가져오기 실패

증상: 테이블의 레코드를 열람하면 모든 필드가 공백으로 표시됩니다.

원인: 리플렉션을 사용하여 GetProperties() 를 사용했으나, 레코드 클래스의 필드는 [SerializeField] private 이었고, 속성은 read-only getter만 있었습니다.

BindingFlags.NonPublic 을 지정해야 했습니다.

교훈: CLAUDE.md(AI 지시 파일)에 ‘private field + read-only accessor’ 패턴을 명시했음에도 불구하고, AI가 리플렉션 코드에서 이 제약을 고려하지 않았습니다.

코딩 규약을 기술하는 것만으로는 GUI 측의 리플렉션 코드에 적용되지 않는 경우가 있습니다.

【Bug 3】 GROUP BY결과의 컬럼명이 <BackingField>

증상: SELECT Category, COUNT(*) FROM ItemTable GROUP BY Category 의 결과 헤더가 <Category>k__BackingField 로 표시됨.

원인: C# 자동 속성의 백킹 필드 이름이 그대로 출력되었습니다.

교훈: AI는 C#의 내부 구현 세부 사항(백킹 필드 이름)을 이해하지 못하는 경우가 있습니다.

【Bug 4】 SchemaCompareWindow – 비교 결과가 부정확함

증상: 동일한 스키마를 비교해도 차이가 표시됩니다.

원인: 필드 비교 시 액세스 수정자를 포함시켜 버렸습니다.

【Bug 5】 SqlEditorWindow – JOIN 결과 헤더가 확장되지 않음

증상: SELECT * FROM ItemTable JOIN EventTable 의 결과 컬럼이 확장되지 않고, 테이블명에 와일드카드가 그대로 표시됩니다.

원인: SELECT * 의 와일드카드 확장이 JOIN 시 구현되어 있지 않았습니다.

AI의 장점과 단점

AI가 잘한 점

■ 대량의 보일러 플레이트 생성

12개의 EditorWindow 기본 구조(OnGUI, 메뉴 등록, 레이아웃)는 모두 올바르게 생성되었습니다.

EditorGUILayout API 사용도 대체로 적절했습니다.

■ 테스트 주도 수정

버그를 보고하고 테스트 결과를 붙여넣으면 높은 정확도로 수정 코드를 생성할 수 있었습니다.

테스트 추가도 적절했습니다.

■ 리팩토링

2,000줄이 넘는 SqlExecutor.cs 를 5개의 파일로 분할하는 리팩토링은 한 번의 지시만으로 정확하게 실행되었습니다.

■ 코드 생성(ClassGenerator)

YAML 정의로부터 C# 레코드 클래스를 생성하는 처리는 속성 조합([SerializeField, CsvColumn, PrimaryKey, SecondaryKey])을 올바르게 처리할 수 있었습니다.

AI가 취약했던 부분

■ 컴포넌트 간의 일관성

개별 클래스는 올바르게 생성되지만, 여러 클래스가 연동되는 부분에서 버그가 발생했습니다.

특히, 데이터 처리 계층과 표시 계층 간의 타입 전달이나, 런타임 코드(private field)와 에디터 코드(리플렉션을 통한 가져오기)의 일관성 문제가 발생했습니다.

■ Unity 고유의 엣지 케이스

SerializeField + private 필드의 리플렉션, IMGUI의 렌더링 타이밍(Layout/Repaint 이벤트의 구분), C# 백킹 필드 이름의 내부 표현 등, Unity 특유의 지식이 필요한 부분에서 문제가 발생했습니다.

■ 실제 화면을 보고 조정

AI는 화면을 볼 수 없기 때문에, 레이아웃의 미세 조정이나 UX 개선은 사람이 수행해야 했습니다.

생성된 GUI는 ‘기능적으로 작동’하지만 ‘사용하기 편하다’고 할 수는 없습니다.

■ 기존 코드의 암묵적 제약 조건 이해

CLAUDE.md에 기술된 코딩 규약은 ‘신규 코드 생성’에는 적용되었지만, ‘기존 코드와의 연동 시’에는 무시되는 경우가 있었습니다.

정량적 분석

개발 속도

지표	수치
전 EditorWindow 초안 완성	2일
버그 수정 완료	추가 4일
GUI 관련 코드 총량	약 5,000줄
버그 수정 커밋 수	15건
리팩토링 커밋 수	8건

버그 수정에 소요된 공수의 비율

초기 생성은 고속이었으나, 버그 수정에 초기 생성의 1.5배 이상의 시간이 소요되었습니다.

커밋 분석

종류	건수
기능 구현(Phase X 완료)	10건
버그 수정	15건
리팩토링	8건
도큐먼트・자료	5건
테스트 추가	4건
그외	5건

버그 수정 패턴과 권장 워크플로

버그 수정 패턴 분석

【패턴1】 ‘테스트 결과를 전달하여 수정’(성공률: 높음)

테스트 결과나 오류 로그를 직접 전달하는 패턴입니다.

AI가 가장 잘하는 패턴으로, 버그의 특정과 수정이 높은 정확도로 이루어졌습니다.

【패턴2】 ‘증상을 전달하여 수정’(성공률: 중간)

화면의 증상을 말로 전달하는 패턴입니다.

AI가 화면을 볼 수 없기 때문에 원인 추측 정확도가 떨어집니다(적중 확률은 60% 정도).

【패턴3】 ‘코드 리뷰를 통해 발견’(성공률: 높음)

Codex CLI로 코드 리뷰를 실행하고, 그 결과를 피드백하는 패턴입니다.

구조적인 문제 발견에 효과적이었습니다.

권장 워크플로

실험을 통해 드러난, AI에 GUI 구현을 맡길 때의 권장 워크플로입니다.

【Step 1】 설계 방침의 명문화

CLAUDE.md에 코딩 규약을 기술할 뿐만 아니라, 리플렉션 시의 필드 액세스 방법이나 데이터 전달 방법(형식, 포맷)도 명시합니다.

【Step 2】 인터페이스 퍼스트로 구현

먼저 데이터 계층의 인터페이스를 정의하고, GUI는 인터페이스에 의존하는 형태로 생성하게 합니다.

Mock이 필요 없는 테스트를 먼저 작성하게 하는 것도 효과적입니다.

【Step 3】 단계적인 생성 및 검증

한 번에 모든 Window를 생성하는 것이 아니라, 1개의 Window 생성 → 동작 확인 → 다음 Window 생성이라는 사이클로 진행합니다. 동작 확인은 테스트 코드로 자동화합니다.

【Step 4】 AI에 대한 피드백

버그 보고는 테스트 결과나 오류 로그로 전달합니다(말로 설명하기보다 정확도가 높기 때문).

스크린샷보다 테스트가 더 효과적입니다.

Unity Test Runner와의 연동 과제

현재의 과제

AI에 구현을 위임할 경우, 테스트 주도 개발에 가까운 반복 과정을 통해 진행하면 오류 발생률을 크게 낮출 수 있다는 결론에 도달했습니다.

하지만 Unity에서 TDD를 실천하려면 Test Runner의 실행 결과를 XML로 내보내거나, 실패한 테스트 결과를 수동으로 복사하는 등 사람의 개입이 필요합니다.

현재 AI 에이전트에게 자동화를 맡길 때의 현실적인 절차는 다음과 같습니다.

1. Unity를 한 번 종료한다
2. 배치 모드에서 Test Runner를 실행한다
3. 출력된 XML을 AI가 읽게 한다
4. 수정을 수행
5. Unity를 재시작하고 실제 기기에서 확인

특히 Unity의 시작 및 종료는 소규모 프로젝트라 하더라도 무시할 수 없는 시간적 비용이 발생하며, 반복 속도를 크게 떨어뜨리는 요인이 됩니다.

개선안: Unity × MCP 서버

이 문제를 해결하기 위한 방안으로, Unity 내에 MCP 서버를 구현하여 Test Runner를 직접 조작할 수 있게 하는 방법을 고려해 볼 수 있습니다. MCP(Model Context Protocol)는 AI 에이전트가 외부 도구와 연동하기 위한 프로토콜입니다.

이 구성이 실현된다면, 흐름은 다음과 같이 간소화됩니다.

1. MCP 서버를 통해 Test Runner 실행
2. 테스트 결과 즉시 확보
3. AI가 수정
4. 실제 기기 확인 수행

Unity를 재시작할 필요가 없어지므로, 반복 속도를 유지한 채 AI 주도형 개발 루프를 돌릴 수 있게 됩니다.

실제 검증 결과

위 개선안을 바탕으로 MCP 서버에 몇 가지 기능을 추가하여 검증을 진행했습니다.

구체적으로는 다음과 같은 기능입니다.

• Unity 화면 스크린샷 촬영 기능
• 계층 구조나 각 컴포넌트에 설정된 내용 · 데이터 구조 획득 기능
• 각종 오브젝트 생성 기능

참고로, 본 실험의 에디터 확장은 코드 기반으로 완결되는 IMGUI를 사용하고 있지만, 이 MCP 서버를 통한 검증은 GameObject 기반으로 구축되는 uGUI를 대상으로 하고 있습니다.

uGUI는 계층 구조 상에 오브젝트로 존재하기 때문에, MCP 서버를 통한 구조 획득이나 오브젝트 생성과의 궁합이 좋다고 생각됩니다.

그 결과, 토큰 소비량은 상당히 많아지지만, 제로베이스에서의 GUI(uGUI) 구축에 관해서는 70% 정도의 정확도로 자동 구현할 수 있음이 확인되었습니다.

다만, 버그가 완전히 사라지는 것은 아니며, 역시 최종적으로는 사람의 손으로 테스트나 리뷰를 수행하지 않으면 버그가 남게 된다는 과제는 해소되지 않았습니다. AI의 활용으로 개발 속도는 대폭 향상되지만, 품질 보증 공정을 생략할 수 있는 것은 아니라는 점은 본 실험 전체를 통해 일관된 결론입니다.

실험 전체 결과

12일간의 실험을 통해 12개의 EditorWindow와 약 5,000줄의 GUI 코드를 2일 만에 초안을 생성하고, 추가 4일간의 버그 수정 및 리팩토링을 거쳐 Asset Store에 출시할 수 있는 수준까지 품질을 끌어올릴 수 있었습니다.

정량적인 관점에서 보면, 초기 생성은 수동 구현보다 5~10배 빠른 속도로 진행된 반면, 버그 수정에도 전체 공수의 약 50%가 소요되었습니다.

버그의 경향으로는, 개별 클래스의 내부 구현은 대체로 올바르게 생성되지만,

• 여러 컴포넌트를 가로지르는 타입 · 데이터의 전달
• Unity 고유의 암묵적 지식([SerializeField] private 의 리플렉션 획득 등)
• 화면을 직접 보지 않으면 알아차리기 힘든 레이아웃이나 표시 오류

와 같은 부분에서 문제가 발생하는 패턴이 두드러졌습니다.

반면, 테스트 결과나 코드 리뷰 결과를 직접 전달하면 AI가 높은 정확도로 수정 결과를 반환해 준다는 점, 2,000줄이 넘는 클래스 분할과 같은 대규모 리팩토링이나 속성이 포함된 코드 생성 같은 보일러 플레이트 작업에서는 매우 높은 정확도를 발휘한다는 점도 확인할 수 있었습니다.

종합해 보면, 이번 실험을 통해 얻은 것은 “AI에 전적으로 맡길 수는 없지만, 인간이 리뷰 · 테스트 · UX 조정을 담당하고 AI가 코드를 작성하는 분업이 성립된다면, 지금까지 수익성이 맞지 않았던 사내 툴이나 패키지 개발에 대해서도 현실적인 투자 판단을 내릴 수 있는 수준에 도달했다”는 확신입니다.

정리

이번 실험을 통해 AI에게 Unity Editor GUI 구현을 맡기는 것은 ‘가능’하지만, ‘완성품’은 나오지 않는다는 점이 명확해졌습니다.

최종 평가는 다음과 같습니다.

항목	평가
개발 속도	⭐⭐⭐⭐⭐ (수동에 비해 5~8개 속도)
초기 품질	⭐⭐(움직이나 깨진 부분이 많음)
버그 수정 정확도	⭐⭐⭐⭐ (테스트 베이스면 정확도 가 높음)
UX품질	⭐⭐ (기능적이지만 정교함이 부족)
종합적인 생산성	⭐⭐⭐⭐ (버그 수정을 포함해도 수동보다 빠름)

이번 실험을 통해 제가 개인적으로 받은 인상을 솔직히 적자면, Editor GUI 영역에 한정해서 말하자면, Claude Code(Claude Opus 4.6)는 마치 ‘우수한 인턴 엔지니어’와 협업하고 있는 듯한 느낌이었습니다.

대량의 코드를 고속으로 작성해 주는 반면, 리뷰 · 테스트 · UX의 마무리 작업은 여전히 인간이 맡아야 하며, 이른바 ‘핵심적인 역할’을 그대로 맡길 수 있는 수준에는, 적어도 에디터 GUI에 관해서는 아직 도달하지 못했다는 것이 이번 실험을 통해 느낀 점입니다.

다만, 이는 어디까지나 이번 실험을 진행한 시점(Claude Opus 4.6 세대)에서의 소감이라는 점을 강조하고 싶습니다.

AI의 진화 속도를 고려하면, Editor GUI처럼 Unity 고유의 암묵적 지식이 얽힌 영역이라 하더라도, AI가 다룰 수 있는 범위는 앞으로 더욱 넓어질 것이며, 이미 다른 영역에서는 인턴 수준의 지원 단계를 넘어 AI에 개발을 맡기고 있는 프로젝트도 존재합니다.

그렇게 생각하면, 이번 실험에서 드러난 본질적인 변화는 인간의 역할이 ‘코드를 작성하는 사람’에서 ‘품질 게이트를 통과시키는 사람’으로 이동하고 있다는 점일지도 모릅니다.

AI에 전부 맡기는 경우에도, 인간의 ‘리뷰 설계 능력’이 성패를 좌우합니다.

특히 Unity 개발에 있어서는 Unity 구조상의 특수한 영역을 어디까지 AI에 맡길 것인지 의식적으로 설계해야 한다는 점을 깊이 느꼈습니다.

지금까지 읽어주셔서 감사합니다.

부록: 기술 스택

기술	용도
Unity IMGUI	Editor GUI
EditorWindow	각종 툴 윈도우
EditorGUILayout	레이아웃 관리
PropertyDrawer	커스텀 인스펙터
SerializedObject	Undo지원
Reflection	필드 값의 동적 불러오기
YamlDotNet	테이블 정의의 읽고 쓰기
NUnit	테스트