AI들과 함께 일하는 환경이 되기까지

AI를 개발에 활용하는 범위가 넓어지면서 여러 회사의 모델을 사용해보기 시작했다. 처음에는 각 모델이 어떤 결과를 만들어내는지 궁금했지만, 사용하다 보니 작업에 따라 느껴지는 장단점이 달랐다.

자연스럽게 작업에 맞는 모델을 선택하고, 각 모델의 장점을 함께 활용할 방법을 고민하게 됐다.

이 글에서는 여러 AI 모델의 장점을 활용해 하나의 작업 환경을 구성한 과정과, 실제 개발에 적용하며 겪은 시행착오를 정리해보려고 한다.

여러 회사의 모델을 사용하며 느낀 장단점

게임을 개발하면서 AI에게 맡기는 작업은 주로 다음과 같다.

• 기획 내용을 정리하고 요구사항을 구체화하는 작업
• 기존 코드를 읽고 시스템의 구조를 파악하는 작업
• 기능을 구현하거나 오류의 원인을 찾는 작업
• MCP를 통해 에디터의 데이터를 확인하고 설정하는 작업
• 아트 자산을 생성하는 작업

이처럼 작업의 성격이 다르다 보니, 모델을 사용하면서 살펴보는 부분도 늘어났다. 코드가 잘 작성되는지 뿐만 아니라,

• 내 의도를 얼마나 이해하는지
• 기존 프로젝트의 구조를 고려하는지
• 수정 요청에 어떻게 대응하는지

도 중요했다. 또 실제로 사용해보면서 다음과 같은 요소들도 고려되기 시작했다.

• 결과의 품질: 요구사항과 기존 작업의 의도를 얼마나 반영하는가.
• 작업 속도: 결과를 기다리고 다시 수정하는 데 얼마나 시간이 드는가.
• 사용량과 비용: 필요한 작업을 지속해서 맡길 수 있는가.

이 글은 2026년 10월 26일 기준의 개인적인 사용 경험을 바탕으로 작성했습니다.

AI 관리 환경의 필요성

모델마다 장단점이 다르다 보니, 작업에 맞춰 여러 모델을 함께 활용하고 싶어졌다. 하나의 작업을 진행하는 동안에도 다른 모델에 별도의 작업을 맡기면, 기다리는 시간을 활용할 수 있겠다는 생각도 들었다.

우선은 여러 에이전트의 세션과 진행 상황을 한곳에서 확인하고 싶었다. 더 나아가 작업에 필요한 문맥을 공유하고, 역할을 나누고, 결과를 이어받는 과정까지 연결하고 싶었다.

이런 필요에서 여러 세션을 관리하는 멀티플렉서를 찾아보기 시작했고, 이후에는 작업의 분배와 흐름을 조율하는 오케스트레이션 환경에도 관심을 갖게 됐다.

AI 멀티플렉서

멀티플렉서는 여러 터미널 세션을 한곳에서 실행하고 관리할 수 있게 해주는 도구다. AI 개발 환경에서는 여러 에이전트를 동시에 실행하고, 각 작업의 진행 상황을 확인하는 데 활용할 수 있다.

Herdr

처음 사용해본 멀티플렉서다. 터미널 기반으로 가볍게 사용할 수 있고, 여러 에이전트의 상태를 한눈에 확인할 수 있다는 점이 좋았다. 이를 사용하면서 여러 에이전트에 작업을 나누어 맡기는 방식에도 익숙해지기 시작했다.

다만 UI 시안이나 아트 자산 관련 작업에서는 불편한 부분도 있었다. 내 사용 환경에서는 이미지나 영상을 첨부하고, 결과물을 바로 확인하는 과정에 제약이 있었다.

Orca

이후에는 GUI 기반의 개발 환경인 Orca도 사용해보았다. Orca는 여러 에이전트의 실행과 함께 코드 편집, 변경 사항 검토, 브라우저 등의 기능을 제공한다.

주요 특징은 다음과 같다.

• 작업 공간 분리: Git Worktree를 활용해 작업별로 폴더와 브랜치를 구분한다.
• 변경 사항 검토: 에이전트가 수정한 코드를 Diff 화면에서 확인할 수 있다.
• 결과물 확인: 이미지와 영상, Markdown, PDF 등을 앱 안에서 열어볼 수 있다.

여기서 Worktree는 하나의 Git 저장소에 여러 작업 폴더를 두고, 각각 다른 브랜치에서 작업할 수 있게 해주는 기능이다. 여러 에이전트가 각자의 작업 폴더를 사용하므로 같은 파일을 직접 덮어쓰는 상황을 줄일 수 있었다.

AI Orchestration

여러 에이전트를 한곳에서 관리할 수 있게 되면서, 작업을 어떻게 나누고 연결할지도 고민하게 되었다. 각 모델의 장점을 활용하려면 역할을 정하고, 작업에 필요한 정보를 전달하고, 결과를 다음 작업으로 이어주는 과정이 필요했다.

이처럼 여러 에이전트의 역할과 작업 흐름을 조율하는 것을 AI Orchestration이라고 한다.

내가 구성하고자 하는 환경은 언리얼 엔진 개발을 기획·설계, 코드, 에디터 영역으로 나누고, 내가 각 작업의 방향과 결과를 확인하며 연결하는 방식이다.

역할을 나누는 기준

앞서 정리한 사용 경험을 바탕으로 다음과 같이 역할을 나누었다.

작업의 성격이나 결과에 따라 다른 모델에 의견을 구하거나 담당을 바꿀 수 있도록 생각하고 있다.

특히 코드와 에디터 영역은 서로 연결되는 부분이 많다. 새로운 기능에 필요한 코드를 준비한 뒤 에디터에서 데이터를 설정해야 할 수도 있고, 에디터 작업 중 발견한 문제를 다시 코드에 반영해야 할 수도 있다.

따라서 동시에 진행할 수 있는 작업과 앞선 결과를 기다려야 하는 작업을 구분하는 것도 중요했다.

공통 명세와 작업 전달

역할을 나눈 만큼 각 에이전트가 같은 기준으로 작업할 수 있어야 한다. 이를 위해 기존에 활용하던 Spec 문서를 공통 기준으로 삼으려고 했다.

문서에는 보통 다음과 같은 내용을 정리한다.

• 목표: 어떤 기능을 만들고, 어떻게 동작해야 하는가.
• 제약: 기존 구조에서 유지해야 할 부분과 변경하면 안 되는 것은 무엇인가.
• 작업 범위: 코드와 에디터에서 각각 무엇을 처리해야 하는가.
• 진행 상황: 완료한 내용과 다음 담당자가 이어받을 작업은 무엇인가.

기본적인 작업 흐름은 다음과 같다.

1. 내가 만들고 싶은 기능과 제약을 전달하고, Gemini와 요구사항을 구체화한다. 2. 정리한 명세를 검토한 뒤 GPT에 코드 구현을 맡긴다. 3. 구현 결과와 에디터에서 설정할 내용을 Claude에 전달한다. 4. Claude가 MCP로 에디터 작업을 수행하면, 내가 실제 동작과 표현을 확인한다.

요구사항과 명세가 확정되면, 코드 구현과 에디터 작업은 Orca에서 구성한 작업 흐름에 따라 자동으로 인계된다. 작업 난이도와 범위에 따라 적절한 모델이 배정되며, 설계 변경이나 결과 확인이 필요한 지점에서는 직접 개입한다.

내가 개입하는 지점

내가 집중하려는 부분은 방향 결정, 변경 판단, 결과 확인이다.

• 작업을 시작할 때: 기능의 목적과 우선순위, 완료 기준을 정한다.
• 설계를 구체화할 때: AI의 제안이 기존 시스템과 게임의 의도에 맞는지 검토한다.
• 작업 중 방향이 달라질 때: 수정 범위나 공통 구조를 바꿀 필요가 있는지 판단한다.
• 작업이 끝났을 때: 실제 플레이와 화면을 확인하고 추가로 수정할 부분을 정리한다.

각종 시행착오

같은 작업을 서로 다르게 이해하는 문제

여러 모델에 작업을 나누어 맡기면서 겪은 문제는 같은 요구사항을 전달해도 각 모델이 이해하는 내용이 조금씩 달라진다는 점이었다.

기획에서 정리한 의도가 코드 구현과 에디터 작업으로 이어지는 과정에서 조금씩 틀어지기도 했다. 각 작업만 보면 그럴듯하지만, 함께 연결해보면 처음 생각했던 동작이나 표현과 달라지는 것이다.

GPT가 일부 목표나 요구사항을 빠뜨리는 경우가 있었고, Claude는 요청한 구현 방향에서 벗어나거나, 우회적인 방법으로 작업을 처리하면서 의도하지 않은 동작을 만드는 경우도 있었다.

이런 경험을 통해 작업을 전달할 때 다음 내용을 명확하게 구분할 필요를 느꼈다.

• 유지할 내용: 이미 결정한 사항과 기존 시스템의 동작
• 수정할 내용: 이번 작업에서 변경해야 하는 범위
• 확인할 내용: 해석이 모호하거나 추가 결정이 필요한 부분

작업 완료 여부와 함께, 각 단계의 결과가 처음 정한 목표와 일치하는지도 지속적으로 확인해야 했다. 그러기 위해서 작업 단위를 세분화해서 한 번에 한 세션에서 여러 작업을 맡기도록 하는 것을 피해야했다.

레퍼런스 이미지의 불필요한 요소까지 반영하는 문제

Gemini나 GPT로 만든 예시 이미지를 레퍼런스로 전달할 때도 문제가 있었다.

생성형 AI가 만든 예시 이미지는 전체적인 분위기를 살펴보기에는 유용했다. 다만 이미지 안의 세부 요소까지 모두 확정된 설계로 전달하기는 어려웠다.

참고할 부분과 제외할 부분을 규칙이나 명세로 명시해봤지만, 원치 않는 요소가 반영되는 문제는 계속됐다. 결국 작업 지시에는 이미지나 영상보다 텍스트와 정량적인 수치를 사용하는 쪽으로 바꾸었다.