[Unity] AI를 사용한 프로토타이핑 파이프라인

개요

• 배경: 이 영상과 이 영상을 보고 영감을 얻어서, AI를 통해 프로토타입을 만드는 건 빠르게 할 수 있지 않을까 싶어서 시작해봤다.
• 목표: '총 쏘는 게임 만들어줘' 같은 지시를 내리면, AI가 이를 구체화할 수 있도록 사용자와의 대화를 주도한 뒤 계획을 작성, 하위 에이전트에게 지시 하달, 보고서 작성, 평가 및 검증, 배포까지 자동화한다.

구성

나(이하 사용자)는 이 Kit이 설치된 폴더에서 CLI를 실행하면 모델과 지침이 지정된 Root 에이전트와 소통하게 된다.

구조

에이전트 기본 설정

각 에이전트의 모델 선정 방식은 아직 확정은 아닌데, 이 파이프라인 밖에 있는 AI와 이야기하며 각 모델의 장단점을 고려한 배정을 했다. 이후 /usage를 통해 모델별 사용량을 확인하여 수정할 수 있다.

에이전트 별 허용 툴도 따로 설정했다. 예를들면 architect는 Unity MCP의 manage_prefabs 툴을 사용할 수 없다.

지시 해석 경로

오타 수정 등의 단순한 지시도 계획, 검수, 개발을 나눠 하므로 낭비라고 여겼다. 간단한 지시는 다른 경로를 타도록 했다.

시행착오

파이프라인

1. CoplayDev MCP for Unity의 mcp 서버 url은 127.0.0.1:8080/mcp 인데, agent에는localhost 라고 적어뒀었다. 그런데 Windows에서는 이게 ipv6로 먼저 해석돼서 ::1 이 되어버리는 문제가 있었다. 작업 중간에 해당 문제가 발생해서 mcp 연결이 불가해졌다. 지시를 종결로 처리(지시가 진행중일 땐 파이프라인 자체의 수정을 막아두었다) 하고, 127.0.0.1을 명시하여 해당 문제를 해결한 뒤, 다시 작업을 이어가라는 별도 지시를 하달해야했다.
2. Architect가 public API 스켈레톤을 먼저 작성하여야, Developer와 TestWriter가 그에 맞게 코드를 작성할 수 있다. 순서상 Architect가 먼저 작업해야하므로 본문을 throw new System.NotImplementedException()로 처리하도록 했다. Developer는 해당 스켈레톤의 변경이 필요하면 BLOCKED(DESIGN_CHANGE, TEST_DEFECT)로 보고한다.
3. AI 파이프라인 자체에 대한 변경을 이 파이프라인이 적용된 세션에서 할 수 없었다(사용자는 Root에게만 지시할 수 있는데 Root의 편집 권한이 Docs/의 일부 문서 파일 5종에 한정되므로). 그래서 별도의 Maintenance 세션을 만들고 거기에서 작업했다. 지침에 유지보수 절차를 포함하였고, 그 중 가장 중요한 것은 하나라도 지시의 상태가 closed가 아닌 것이 있으면 유지보수를 하지 않도록 한 것이다.
4. 중간에 작업이 escalated 되어서 멈추면, 나에게 디스코드로 훅이 오게끔 조치했다. 발헤임 하고 있었는데 멈춘 줄도 몰랐다.

그 외

1. AI의 소통 과정을 전부 md 문서로 저장했고, 이를 obsidian으로 열어서 보고 있다. 옵시디언 최신 버전은 md파일의 서식을 자기 멋대로 pretty하게 바꾸는데, 이러면 diff가 생기니 Ctrl + E 단축키로 readonly 모드로 바꿀 수 있었다.

느낀 점

1. 읽기 싫어졌다.

AI의 작업 내역을 일일이 저장해두면 나중에 읽기 편할 줄 알았는데, 그 대신 읽기 싫어지게 하는 역할을 해줬다.

위 이미지는 3매치 퍼즐에 발라트로의 인크리멘탈 장르를 결합한 게임 프로토타입을 지시한 것이다. 문서의 양에 조금 압도되었다.

2. 그래도 읽어야...

위의 문서들을 다 읽는 것은 AI의 역할인 것 같고, 나는 내 지시가 잘 전달되었는지 INSTRUCTION.md 를 읽고 파악하면 되고, Root가 내 지시를 계획으로 잘 옮겨놨는지 Root_Plan.md를 초기에 잘 읽어두면 된다. 이 두 파일로 결과물이 결정되므로 꼼꼼이 읽어야겠다는 생각이 들었다.

예를들면 AC(Acceptance Criteria)는 INSTRUCTION.md에 있고, T(Task)는 Root_Plan.md에 있다. 그리고 AC들이 각각 어떤 태스크에 할당되었는지도 같은 곳에 있다.

3. 프로토타입을 아이디어만 툭 던져서, "예측 가능하게" 뽑을 수 있다는 건 좋았다.

최초 지시는 3줄 정도였고, 그 지시가 Root의 구체화에 의해 맥락, 목표, 제한, 범위 밖(mvp밖), 산출물, 완료조건 등을 포함한 지시 파일이 되었다. 지시파일과 그로 인한 Root_Plan.md를 읽는 것으로 기대했던 것으로부터 크게 벗어나지 않는 결과물이 나왔다.

4. 오래 걸리고 토큰도 많이 먹는다.

중간 중간에 토큰 사용량 제한에 도달해서, 5시간을 기다리기를 3번 정도 반복해 총 4회 분량의 토큰 뭉탱이를 썼다. /usage 로 보면 오래 유지되는 세션에 컨텍스트가 쌓이는 것(아마 Root 세션), 그리고 하위 에이전트(특히 developer)의 모델 변경 정도를 고려해볼 수 있을 것 같다. 특히 Root의 컨텍스트 절약은 시도할 가치가 있어보인다.

오래 걸려서 시켜놓고 발헤임 하기에는 좋았다. ㅇㅅㅇ;;