한 개발자가 4~5개월째 AI agent(목표를 받아 스스로 작업을 나누고 도구를 쓰는 AI)로 작은 게임 스튜디오를 운영하고 있습니다. 큰 작업 명세를 넘기면 agent들이 코드, 캐릭터 그림, 음악, 품질 테스트까지 수십 시간 분량의 일을 나눠 처리하고, 그 결과로 만든 Spades 카드 게임을 Apple App Store 심사에 제출하는 단계까지 왔습니다. 눈여겨볼 점은 이 구조가 처음부터 거대하게 설계된 것이 아니라는 데 있습니다. 출발점은 저장소에 적은 규칙 한 줄과, 일을 나눠 맡기는 조정 agent 하나였습니다.
agentic system은 모델, 규칙, 도구의 묶음
여기서 말하는 agentic system은 세 요소로 이뤄집니다. 판단을 맡는 모델, 해도 되는 일과 하면 안 되는 일을 정한 규칙, 실제로 일을 처리하는 도구입니다. 이 셋을 묶어 돌리는 실행 틀을 harness라고 부릅니다.
ChatGPT, Codex, Claude Code도 이미 agentic system입니다. 다만 대부분의 사용자는 서비스 회사가 정한 규칙 안에서 이 도구를 씁니다. 자기 규칙을 직접 쓰기 시작하면 쓰는 방식이 달라집니다.
- 결과를 보고 prompt를 고쳐 다시 묻는 반복은 지난해의 작업 방식으로 봅니다.
- 올여름 이후 나온 최신 모델에는 코드 한 줄씩 지시하기보다 목표 단위의 과제를 맡기는 편이 낫다고 판단합니다.
- 목표 단위로 맡기려면 허용하는 일, 금지하는 일, 팀의 작업 방식을 규칙으로 분명히 적어야 합니다.
첫 규칙은 아주 단순해도 됩니다. AGENTS.md나 CLAUDE.md 파일에 ‘운영 환경에 바로 올리지 않는다’ 한 줄만 적어도 시작입니다. 이후 필요할 때마다 규칙을 하나씩 늘립니다.
판매 중인 Mac 앱에 조정 agent 세우기
이 방식을 실제로 판매 중인 Mac 메뉴 막대 앱에 적용한 사례가 있습니다. Claude와 OpenAI 구독의 사용 허용량이 얼마나 남았는지, 지금 속도면 언제 바닥나는지를 보여 주는 앱입니다. 하나의 Git 저장소에 Mac 앱, 소개 페이지, 판매 페이지, 배포 과정이 모두 들어 있습니다.
Claude Code 데스크톱 앱에서 이 저장소에 연결된 대화를 열고, AI에게 코드를 직접 쓰는 역할이 아니라 orchestrator(작업을 나눠 맡기고 진행을 관리하는 조정 agent) 역할을 지시했습니다. 지시의 핵심은 다음과 같습니다.
- 요청을 해석해 sub-agent(하위 agent)나 별도 thread로 나눠 맡긴다
- 작업마다 알맞은 모델 등급과 reasoning effort(추론에 들이는 노력 수준)를 고른다
- 작업이 뒤에서 도는 동안에도 사람과 늘 대화할 수 있게 비워 둔다
- 어떤 sub-agent가 돌고 있는지, 진행 상태와 이정표를 먼저 알린다
Claude Code는 역할을 받아들이며 모델 배분 원칙을 정리했습니다.
| 모델 | 맡는 일 |
|---|---|
| Haiku | 조회, 이름 바꾸기, 기계적인 수정 |
| Sonnet | 일반 구현, 테스트 실행, 사이트와 내보내기 작업 |
| Opus(높은 effort) | 사용 속도 계산, 예측, 알림, 요금 등급, 라이선스, PR 검토처럼 중요한 작업 |
여러 agent가 같은 파일을 고칠 때는 서로 다른 git worktree(같은 저장소를 작업별로 따로 펼친 작업 공간)에서 일하게 해 병합 충돌을 막는다는 원칙도 포함됐습니다.
규칙은 도구 메모리가 아니라 AGENTS.md에
처음에 Claude Code는 이 운영 방식을 자기 로컬 메모리에 저장했습니다. 하지만 도구 안의 메모리는 그 도구에서만 쓸 수 있습니다. 그래서 같은 내용을 저장소의 AGENTS.md에 ‘How we work’ 항목으로 9줄 추가하게 하고 메모리 사본은 지웠습니다. 이렇게 하면 Codex 같은 다른 도구도 같은 규칙을 따릅니다. 새 세션을 열어 ’너는 작업자인가, 조정자인가’라고 묻자 모델은 저장소 규칙을 근거로 곧바로 조정자라고 답했습니다.
▲ 세 작업의 동시 실행
세 가지 일을 동시에 맡긴 결과
조정 agent에게 한 번에 세 가지를 요청했습니다. 판매 중인 빌드가 저장소의 릴리스와 같은지 확인하고, 자동 테스트를 돌리고, 새 기능 아이디어를 두세 개 내라는 요청입니다. 조정 agent는 이를 세 개의 백그라운드 작업으로 나누고, agent 이름, 모델, effort, 상태를 담은 진행 표를 보여 줬습니다.
| 작업 | 모델과 effort | 결과 |
|---|---|---|
| 버전 확인 | Sonnet, 낮음 | 공개 릴리스 2.3.0 (14) 확인 |
| 테스트 실행 | Sonnet, 중간 | 43개 묶음 356개 테스트 모두 통과, 빌드 포함 약 17초, 컴파일러 경고 없음, 공증과 서명 완료 |
| 기능 구상 | Opus, 중간 | 기능 후보 3개 제안 |
기능을 구상하는 agent는 프로젝트 이력, 사용 한도, 설정 파일을 따로 살폈고, 그동안 메인 대화창은 멈추지 않았습니다. 제안된 기능은 지난 8주 사용량을 보여 주는 막대 띠, 5시간 초기화 전에 세션이 바닥날 시점을 알리는 기능, 프로젝트별로 가장 많이 쓴 세션 분석이었습니다. 사람은 이 가운데 지난 몇 주 사용량 띠를 골랐고, 조정 agent에게 Opus로 명세를 먼저 쓴 뒤 분리된 worktree에서 Sonnet이 구현하게 지시했습니다.
탭을 여러 개 열어 agent를 따로 돌리는 방식과 비교하면 차이가 분명합니다. 전체 진행을 한곳에서 볼 수 없고, 모델과 effort를 매번 사람이 골라야 합니다. 기능 구상에는 Opus 중간 effort로도 충분했지만, 제품 로드맵처럼 구조를 정하는 일에는 더 높은 effort가 낫다는 판단도 덧붙었습니다. 조정 agent가 작업을 동시에 돌리지 않고 하나씩 처리한다면 AGENTS.md의 지시를 고쳐야 합니다.
게임 스튜디오로 커진 구조
같은 원리를 키우면 회사 단위가 됩니다. 이 게임 스튜디오는 폴더마다 부서가 하나씩 있는 구조입니다.
- 게임별 부서: Spades, Cribbage 같은 게임마다 하나
- 마케팅 부서와 producer 부서
- 공용 부품: UI, 세션 관리, 로비, 핵심 로직처럼 여러 게임이 함께 쓰는 기능
부서를 관리하는 화면도 따로 있습니다. 조직 구조를 원형 그림으로 보여 주는 화면, 캐릭터 그림과 목소리, 대사 수정을 다루는 캐릭터 관리 화면, 음악과 효과음을 정리하고 샘플레이트와 비트레이트를 맞추는 오디오 화면이 있습니다. 오디오 화면에서는 음악 205곡이 검색되고 효과음 949개가 정리돼 있었습니다. 출시 점검 화면은 App Store 심사 요건, 스크린숏, 법적 고지, 홍보 자료가 준비됐는지 추적합니다.
오래 걸리는 평가는 Lab 부서가 맡습니다. 로컬 장비에서 돌지만 외부 테스트 장비와 통신해 긴 자동 평가를 실행합니다. 이 구조에서 중요하게 보는 원칙은 분산입니다. 오래 걸리는 작업이 노트북 한 대를 하루 종일 켜 두는 데 기대지 않도록 호스팅 환경에서 따로 돌게 합니다.
Producer와 Architect
스튜디오 전체를 받치는 역할은 둘입니다.
Producer는 사람의 지시를 받는 주 창구입니다. 목표를 계획으로 나누고 작업자를 배정하며 결과를 지켜봅니다. 일은 네 단계로 관리합니다.
- 해석과 계획: 목표를 계획으로 나눈다
- 배치와 착수: 작업자를 정하고 일을 시작시킨다
- 관찰과 복구: 진행을 지켜보고 막힌 일을 되살린다
- 평가와 통합: 결과를 확인하고 합친다
요청 추적용 kanban 보드에서는 Producer가 Spades 관련 요청 14건을 포함해 디자인, 엔지니어링, 마케팅의 일을 동시에 다루고 후속 작업을 남깁니다.
Architect는 내부 조정자입니다. 부서들이 건강하게 돌아가는지 살피고, 같은 실패나 재작업을 되풀이하는 부서가 있으면 그 부서의 규칙에 교정 지침을 넣습니다. 새 게임을 시작하거나 홍보 영상, SNS 게시처럼 일이 늘면 경계를 정한 새 부서를 만들고, 쓰지 않는 부서는 접어 조직을 가볍게 유지합니다.
모든 부서가 따르는 공통 규칙 10개
모든 부서는 공통 규칙을 물려받습니다. 사람의 의도, 소유권, 리더와 작업자, 실제 착수, 품질, 복구, 오래가는 작업, 호스트와 전달, 학습, 전체 범위의 10개 항목입니다. 이 규칙 덕분에 부서마다 파일을 같은 방식으로 쓰고, 같은 약속으로 소통하고, 같은 품질 기준을 지킵니다.
이 구조도 처음에는 Spades 게임 하나를 만들려던 데서 시작했습니다. 디자인 폴더가 생겼고, 이어 Spades 코드 폴더와 캐릭터 모음이 따로 생겼습니다. Cribbage와 Parcheesi를 만들면서 여러 게임이 같은 부품과 캐릭터를 쓰게 되자 지금의 여러 부서 구조로 자랐습니다.
▲ 부서로 나뉜 AI 게임 스튜디오
사람이 놓지 않는 몫
이 시스템은 완전 자율도, 완벽하지도 않습니다. 사람은 크리에이티브 디렉터로서 게임에 자기 취향을 담고 결정을 내립니다. 어떤 기능을 만들지, 사용자 경험을 어떻게 할지는 사람이 정하고, agent는 그 결정을 실행합니다. 흔한 함정은 반대 방향에 있는 것으로 보입니다. AI에게 파일 하나 크기의 작은 코드만 맡길 수 있다고 여겨, 회사 운영의 많은 부분을 맡길 수 있다는 점을 놓치는 경우입니다.
따라 하려면 규칙 한 줄과 조정 agent 하나부터
여러 부서를 갖춘 스튜디오를 처음부터 설계할 필요는 없습니다. 복잡함은 실제 프로젝트에서 부딪힌 문제에서 자라나야 합니다. 시작은 다음 순서가 알맞습니다.
- 지금 쓰는 저장소에 AGENTS.md나 CLAUDE.md를 만들고 금지 규칙 하나를 적습니다.
- 첫 대화창에 직접 코드를 쓰지 말고 조정자로 일하라고 지시하고, 작업마다 모델 등급과 effort를 고르게 합니다. 단순한 확인과 테스트는 Haiku나 낮은 effort의 Sonnet, 구조 설계와 기능 구상은 높은 effort의 Opus가 기준입니다.
- 같은 파일을 고치는 sub-agent는 서로 다른 worktree에서 일하게 합니다.
- 진행 상태를 모델, effort, 완료 여부가 담긴 표로 보고하게 합니다.
- 운영 규칙은 도구 메모리가 아니라 저장소의 문서에 남깁니다.
- agent가 막히거나 같은 실수를 되풀이할 때마다 그 내용을 규칙 하나로 바꿉니다.
프로젝트가 늘어 공용 기능이 생기면 그때 별도 모듈로 떼어 내고, 지시 창구인 Producer와 시스템을 돌보는 Architect 같은 역할을 더하면 됩니다. 규칙 한 줄로 시작한 저장소가 어디까지 자랄 수 있는지는 이 스튜디오가 보여 준 셈입니다.