AI로 유니티 시스템을 짤 때 — 코드보다 설계 합의가 먼저다

AI에게 유니티 시스템을 맡길 때 결과를 가르는 것은 코드 생성 능력보다 코드를 짜기 전에 무엇을 합의했는가입니다. 이 자료는 AI 코딩 도구로 시나리오 재생 시스템을 만든 실제 대화 기록을 분석해, 어떤 요청 방식이 좋은 구조로 이어졌는지를 정리합니다.

이 문서는 NotebookLM(노트북 LM)으로 자료를 조사해 만든 문서입니다.

• 상용 에셋 대신 경량 자체 모듈과 엑셀 데이터 파이프라인을 택했습니다. 기존 시스템과의 충돌을 피하기 위해서입니다
• 기획자는 엑셀만 다루고, 런타임은 엑셀을 모르는 분리 구조가 핵심입니다
• AI에게는 만들 것보다 만들지 않을 것을 먼저 알려 주는 편이 설계가 정확해집니다
• 바로 코드를 요구하지 말고 마크다운 설계 문서를 먼저 합의합니다
• 정답을 지시하기보다 검토를 요청하고, 구현은 모듈 단위로 나눠 맡깁니다

요구사항과 구조 결정

상용 비주얼 노벨 에셋은 기능이 많지만 사운드·저장·리소스 관리를 자기 방식으로 가져옵니다. 이미 사운드 매니저와 Addressables가 돌아가는 프로젝트라면 그 자체가 기술 부채가 됩니다. 엑셀은 에디터에서만 읽고 런타임에는 변환된 에셋만 싣는 구조는 유니티 프로젝트에서 데이터 테이블을 다룰 때도 그대로 쓸 수 있는 방식입니다.

마지막 사용 시점을 임포트 단계에서 미리 계산해 두는 해제 방식도 눈여겨볼 만합니다. 런타임에서 참조 횟수를 세는 대신 변환 시점에 필요한 정보를 만들어 두면 실행 중 판단이 단순해집니다.

사람과 AI의 역할 나누기

네 가지 요청 방식 비교

네 비교 가운데 실무에서 가장 효과가 큰 것은 첫 번째입니다. AI는 요청을 받으면 빈 곳을 스스로 채우려 하고, 그 과정에서 이미 있는 시스템을 새로 만듭니다. "저장은 쓰지 않는다", "사운드는 기존 매니저를 호출한다" 같은 한 줄이 불필요한 코드를 크게 줄입니다.

설계 문서를 먼저 받는 방식은 대화가 길어질 때 효과가 드러납니다. 문서가 기준점으로 남아 있으면 이름과 구조가 흔들릴 때 되돌아갈 곳이 생깁니다. 30%와 95% 같은 정확도 수치는 자료 기준이며, 저희가 측정한 값은 아닙니다.

정리 — 설계는 사람이, 구현은 AI가

"10배 생산성" 같은 표현은 슬라이드의 요약이고, 실제 효과는 팀과 프로젝트에 따라 다릅니다. 다만 프롬프트의 대부분을 환경과 규칙 설정에 쓴다는 관찰은 AI 코딩을 도입하는 팀이 바로 적용해 볼 수 있는 기준입니다.

자주 묻는 질문

AI에게 처음 무엇부터 알려 줘야 하나요? 사용 중인 엔진 기능과 기존 매니저, 그리고 만들지 않을 기능입니다. 저장·사운드·리소스 로딩처럼 이미 있는 시스템을 먼저 밝히면 중복 구현이 크게 줄어듭니다.

설계 문서는 어느 정도까지 받아야 하나요? 폴더 구조, 클래스 이름, 데이터 흐름이면 충분합니다. 이 문서를 작업 공간에 두고 이후 요청마다 기준으로 삼으면 긴 대화에서도 구조가 흔들리지 않습니다.

모듈을 얼마나 잘게 나눠야 하나요? 한 번의 응답에서 한 모듈을 끝낼 수 있는 크기가 기준입니다. 설계 문서에 단계 번호를 매겨 두고 번호 단위로 지시하면 출력이 잘리거나 로직이 엉키는 일을 줄일 수 있습니다.

저희가 이 이야기를 하는 이유

에버스톤은 2013년부터 유니티로 모바일 게임과 앱을 만들어 왔고, 최근에는 AI 코딩 도구를 개발 과정에 들이고 있습니다. 엑셀로 기획 데이터를 관리하고 기존 매니저 구조를 유지하는 방식은 저희 프로젝트에서도 늘 부딪히는 조건이라, 이 자료의 요청 방식 비교를 도입 기준을 세우는 참고로 삼고 있습니다.

인용한 수치와 사례는 원 자료 기준이며, 저희가 검증한 내용이 아닙니다.