에이전트가 내 Unity 프로젝트에서 시간을 어디에 썼나 에이전트가 내 Unity 프로젝트에서 시간을 어디에 썼나

저는 전부터 AI 에이전트와 일한 세션 기록을 백업하고 주제별로 묶어 두고 있었습니다. 블로그 소재를 찾거나, 작업 방식을 다듬거나, 프로젝트의 큰 문제를 짚어 볼 때 씁니다.

그러다 Unity 작업을 하면서 궁금해졌습니다. 에이전트가 실제로 어떤 명령을 어떻게 써서 일하고 있는지, 거기서 줄일 수 있는 것은 무엇인지 알고 싶었습니다.

그래서 6주치 기록을 세어 봤습니다.

무엇을 셌나

Unity CLI는 터미널에서 에디터를 띄우고, 열려 있는 에디터에 명령을 보내는 공식 도구입니다. Pipeline 패키지는 에디터 쪽에서 그 명령을 받아 줍니다. 명령 중 eval은 C# 코드를 보내 에디터 안에서 실행합니다. 이 글에 자주 나옵니다.

에디터는 6000.7 알파, CLI는 베타, Pipeline 패키지는 experimental입니다. 최신을 쓰고 있다는 점을 감안해서 읽어 주시기 바랍니다.

수치는 두 종류입니다. 하나는 호출 수나 소요 시간처럼 로그를 파싱해서 직접 센 것입니다. 다른 하나는 로그를 약 9만 자 조각으로 잘라 LLM에게 읽히고 “이 구간에서 무슨 일이 있었나”를 뽑게 한 것입니다. 뒤쪽을 쓸 때는 그렇다고 적겠습니다.

기다림

에이전트가 sleep이나 until 루프를 넣어 명시적으로 기다린 시간입니다.

합쳐서 12.6시간입니다. 명령 자체가 오래 걸린 시간은 여기에 없습니다. 테스트 명령이 돌아간 시간만 따로 세면 약 8.7시간입니다.

시간보다 눈에 띈 건 횟수입니다. Unity를 부른 호출 여섯 번 중 한 번(16%)이 “지금 상태가 어떤가”를 묻는 호출이었습니다. 컴파일이 끝났는지, 테스트가 끝났는지, 에디터가 준비됐는지를 계속 묻습니다. 로그에는 이런 패턴이 반복됩니다.

unity command --project-path . editor_play
sleep 30
# ... eval 로 측정 코드 실행 ...
for i in $(seq 1 90); do [ -f result.txt ] && break; sleep 2; done
unity command --project-path . editor_stop

아케이드 게임에서 성능을 한 번 잴 때마다 이 흐름을 탔고, 한 세션에서 10번 넘게 반복했습니다.

에이전트는 Unity를 어떻게 불렀나

OFF는 호출의 75%가 제가 만든 래퍼 스크립트를 거칩니다. CLI 위에 씌운 셸 스크립트로, 컴파일 완료까지 폴링하고 응답의 성공 여부를 확인하는 일을 합니다. 아케이드 게임과 모바일 게임은 거의 전부 CLI 직접 호출이고, MatterKit은 래퍼와 CLI가 반반입니다. -batchmode는 CLI를 거치지 않고 에디터 실행 파일을 직접 띄운 경우입니다.

명령 중에서는 eval이 사실상 주 인터페이스였습니다. 6주간 5,208회 불렸습니다.

가장 많은 건 제가 프로젝트 안에 만들어 둔 코드를 부르는 호출로, 전체의 절반이 넘습니다. 씬과 계층 조회가 바로 뒤입니다. 씬을 조회하거나 캡처하는 코드는 대부분 그때그때 에이전트가 작성한 것이었습니다. 리플렉션은 대부분 제 프로젝트 코드의 private 필드를 테스트나 진단 목적으로 들여다본 것입니다.

두 가지가 더 나왔습니다.

• 씬은 주로 에디터를 통해 고쳤습니다. 고칠 때는 대부분 eval로 오브젝트를 만들고 컴포넌트를 붙였습니다(약 430회). 씬 YAML에 패치를 직접 넣은 건 30여 건입니다. 읽을 때는 eval로 계층을 물어보거나(약 2,540회) 셸에서 YAML을 grep과 파이썬으로 뒤졌습니다(약 1,030회).
• 문서보다 소스를 많이 열었습니다. 패키지 소스를 연 호출이 약 960회, Unity 문서나 포럼을 조회한 호출이 약 260회입니다. Editor.log를 직접 연 것도 약 1,270회입니다. 명령이 실패했을 때 응답만으로는 원인을 알기 어려워 로그를 찾아본 경우가 많았습니다.

사람은 언제 끼어들었나

여기는 LLM이 뽑은 결과 기준입니다. 작업 유형별로 제가 개입했거나 제 눈과 손이 필요했던 비율입니다.

위쪽 세 가지는 결과를 눈으로 보거나 직접 만져 봐야 판단되는 일입니다. “조작감이 이상하다”나 “찰흙 덩어리처럼 보인다”는 판단은 제가 했습니다. 테스트처럼 통과와 실패가 분명한 일은 에이전트가 거의 혼자 끝냅니다.

에이전트에게 일을 더 맡기려 할 때 걸리는 건 코드 작성보다 “결과를 어떻게 볼 수 있게 해 줄 것인가” 쪽입니다.

하나 더 있습니다. 실패한 것만큼이나 “막히진 않았지만 비싼 방식”이 많이 나왔습니다. 물리 값 하나를 조정할 때마다 테스트 전체와 플레이어 빌드와 캡처를 다시 도는 식입니다. 막힌 게 아니어서 세션 중에는 문제로 드러나지 않습니다. 이런 패턴은 성격이 전혀 다른 프로젝트들에서 비슷한 빈도로 나왔습니다.

Claude와 Codex

OFF에서는 두 에이전트를 모두 썼습니다. 전체 도구 호출은 Codex 쪽이 다섯 배 많고, 도구 호출 1,000회당 제가 보낸 메시지는 Codex 15개, Claude Code 39개입니다. 에디터 화면을 직접 보거나 조작하는 도구(computer use)를 부른 횟수도 Codex 415회, Claude Code 22회로 차이가 큽니다. 래퍼 사용 비율은 거의 같고 실패율도 비슷했습니다.

제 기준이 그대로 드러난 결과입니다. 오래 걸리는 작업과 모델링처럼 시각적 판단이 중요한 작업은 Codex에 맡깁니다. 그 밖에는 큰 차이를 못 느끼고, 사용량이 남은 쪽을 쓰는 경향도 있습니다.

래퍼를 걷어낸 뒤

9월 6일에 OFF의 래퍼를 605줄에서 179줄로 줄였습니다. 에디터 강제 재시작이나 화면 그대로 캡처처럼, 공개되지 않은(internal) API나 임시 파일에 기대던 기능을 걷어냈습니다.

당시 판단이 잘 기억나지 않아서 그날의 세션 기록을 찾아봤습니다. 시작은 “저장소가 에이전트가 읽기에 너무 커진 게 아닌가”라는 점검이었습니다. 에이전트용 Unity 작업 안내 문서가 1,410줄이라는 결과가 나왔고, 거기서 제가 한 말이 남아 있습니다.

비공식 방법은 최대한 덜어내고 싶긴 해. 유니티 버전업이나 패키지 버전업을 하더라도

전후를 비교하면 이렇습니다.

두 기간은 길이도 한 작업도 달라서 단순 비교는 조심해야 합니다. 그래도 실패율은 내려갔고, 대기는 호출당으로 환산해도 줄었습니다.

화면 캡처 호출이 사라진 기간에 화면을 직접 보는 도구 호출이 그만큼 생겼습니다. 다만 Codex가 그 도구를 쓰기 시작한 날이 마침 같은 날이라, 기능을 걷어낸 탓인지 도구가 생긴 탓인지는 이 데이터로 가릴 수 없습니다.

같은 날 하나 더 나왔습니다. 공개되지 않은 API에 기대던 연동 코드가 있었는데, 확인해 보니 공개 API가 이미 있었습니다. 처음 만들 때의 에디터 버전에는 없었고 그 뒤에 생긴 것입니다. 버전업 직후 테스트가 깨졌을 때 공개 API를 확인하지 않고 우회 코드를 수리했던 겁니다. 우회를 한번 만들면 그 우회를 계속 고치게 됩니다. 이날 이후 안내 문서에는 버전을 올릴 때 기존 우회가 아직 필요한지부터 확인한다는 규칙이 들어갔습니다.

LLM이 읽어 준 결과는 얼마나 맞았나

“에이전트가 뭘 하려다 막혔나”, “내가 왜 끼어들었나” 같은 건 누군가 로그를 읽어야 알 수 있습니다. 8GB를 파이썬으로 126MB까지 줄인 뒤 DeepSeek에게 읽혔습니다. 약 9달러 들었고, 앞 절의 “사람이 끼어든 비율”이 여기서 나온 수치입니다.

믿어도 되는지 보려고 198건을 뽑아 다른 모델에게 로그 원문과 대조하게 했습니다. 사실관계가 틀린 건 1건뿐이었습니다. 어긋난 건 해석 쪽입니다. 26건은 분류가 맞지 않거나 원인을 단정할 수 없었고, 사실은 맞아도 원인이 달랐던 경우도 있었습니다. “빌드가 18분간 멈췄다”는 사실이었지만 원인은 서드파티 플러그인 충돌이었고, “라이선스 인증 실패”는 동시에 띄운 에디터들의 메모리 경쟁일 가능성이 컸습니다. 표본은 눈에 띄는 것 위주로 뽑았으니 전체로 보면 이보다 나쁠 겁니다.

그래서 숫자는 직접 세고, LLM이 뽑은 결과는 어디를 들여다볼지 알려 주는 색인으로만 썼습니다.

그래서 바꾸는 것

집계에서 바로 나오는 할 일은 네 가지입니다.

1. 래퍼가 끝까지 기다려 주게 합니다. 상태 조회가 Unity 호출의 16%인 건 제 도구가 기다려 주지 않아서입니다.
2. 자주 쓰는 eval을 명령으로 올립니다. 씬 조회와 캡처처럼 에이전트가 매번 새로 짜던 코드가 첫 후보입니다.
3. 값 여러 개를 한 번에 돌려 비교하는 도구를 둡니다. 물리 값을 0.1, 0.3, 0.5로 바꿔 가며 같은 장면을 돌리고 결과를 표 하나로 받는 식입니다.
4. “볼 수 있게” 하는 데 투자합니다. 사람이 끼어드는 지점은 시각과 조작감이었습니다.

마치며

에이전트와 일한 기록은 그냥 두면 사라지기도 합니다. Claude Code는 기본 설정에서 30일이 지난 세션 기록을 지웁니다. Codex 앱은 업데이트하면서 기록 파일을 통째로 다시 쓴 적이 있습니다. 그래서 두 도구의 기록을 매일 백업해 두고 있습니다.

요즘은 AI로 개발을 잘하는 것에서 한 걸음 더 나가, 그 과정의 효율을 올리는 쪽에 관심이 갑니다. 프로파일러로 병목을 찾듯이, 에이전트와 하는 개발에서는 세션 기록이 그 역할을 합니다.