엔진을 쓰기 전에 에이전트부터 그리다

공간 런타임을 만드는 팀은 런타임 그 자체만큼 신중하게 설계되어야 한다. RakuAI는 팀의 형태 - 한 명의 인간과 에이전트 함대 - 부터 시작했다. 왜냐하면 아키텍처는 그것을 만드는 사람에 종속되기 때문이다.

이번 토요일은 보는 사람이면 누구나 시기상조라고 생각할 만한 화이트보드 작업에 쓰였다. 제품은 출시까지 아직 갈 길이 멀다. 엔진은 아직 저장소조차 아니다. 코드는 없다. 데모도 없다. 있는 것은 하드웨어 로드맵, 10년을 거슬러 올라가는 특허 자산, 그리고 차세대 AR 글래스가 어떤 모습이어야 하는지에 대한 명확한 논지뿐이다. 그리고 나는 지금 부엌 식탁에 앉아 이 물건을 만들 에이전트들을 그리고 있다.

이건 의도적인 것이다.

왜 에이전트가 먼저인가

프로젝트의 이 단계에서 관습적인 움직임은 코드를 쓰기 시작하는 것이다. 저장소를 연다. 개념 증명(PoC)을 만든다. PoC가 도움을 요청하기 시작하면 엔지니어를 채용한다. MVP를 출시한다. 반복한다.

나는 관습적인 경로를 따라 세 개의 회사를 만들어 봤다. 이번에는 다르게 하기로 결정했다. 이 엔진을 만드는 팀은 한 명의 인간과, 정의된 역할 안에서 일하는 AI 에이전트 함대가 될 것이다. 엔진의 아키텍처, SDK의 형태, 코드 리뷰의 규율, 개발 루프의 리듬, 이 모든 것은 팀의 형태에 종속된다. 팀의 형태를 먼저 파악하지 않으면, 실제로 이 엔진을 만들어야 할 팀과는 다른 팀을 위해 만들어진 엔진을 갖게 될 것이다.

그래서 오늘은 팀 형태를 정하는 날이다.

명단

내가 정하고 있는 에이전트 명단과, 각각이 맡아야 할 역할.

Product Agent. 스펙을 소유한다. 하드웨어 업데이트, 벤더 로드맵, SDK 의존성, 공개 출시 캘린더를 추적한다. Product Agent는 엔진이 무엇을 해야 하는지에 대한 정본(正本) 소스다. 다른 에이전트들은 자신의 작업을 Product Agent가 읽은 스펙과 대조해서 확인한다.

SDK Agent. SDK 자체를 소유한다. 문서화, 온보딩 플로우, 호환성 테스트, 패키지 퍼블리싱. SDK Agent는 개발자들이 가장 자주 상호작용하게 될 에이전트다. 생성된 문서, 샘플 앱, 온보딩 에러 메시지의 형태로. 그 결과물은 진짜 개발자 관계(devrel) 조직처럼 느껴져야 한다.

Studio Agent. 게임 스튜디오와 인디 개발자를 향한 아웃리치를 소유한다. 데모 준비. 공동 마케팅 자료. 스튜디오를 특별히 겨냥한 온보딩 문서. Studio Agent의 지표는 전환이다: 우리와 이야기를 나눈 스튜디오가 실제로 이 엔진 위에서 무언가를 출시하는 것. 그 지표는 아직 먼 미래의 일이고, Studio Agent의 일상은 그것을 만들어낼 관계를 서서히 축적하는 일이다.

Marketing Agent. 대외 노출 표면을 소유한다. 프레스 킷. 필요하다면 킥스타터 자산. 인플루언서 트래킹. 하드웨어 이벤트 자료. 랜딩 페이지 A/B 테스트. 이 에이전트의 결과물은 세상이 가장 먼저 보게 될 것이다. 좋아야 한다.

Operations Agent. 리듬을 소유한다. 스탠드업(나와 함께). Notion / 간트 차트 관리. 병목 알림. 경영진용 요약. Operations Agent는 매주 토요일 시작할 때, 내가 다른 곳에 있는 동안 나머지 에이전트들이 그 주에 무엇을 했는지 확인하러 찾아가는 에이전트다.

AI and Data Strategy Agent. 데이터 플라이휠을 소유한다. SDK와 글래스로부터 텔레메트리를 수집한다. 결국 온디바이스에 탑재될 소형 언어 모델을 만든다. AI 해자(moat)를 다듬는다. 이 에이전트의 작업이 시간이 지날수록 가장 크게 복리로 쌓인다. 그것이 만들어내는 데이터와 모델이 누구도 복제할 수 없는 차별화 요소가 되기 때문이다.

Codex Dev Sub-Agent. 코드를 쓴다. 런타임 API를 통합한다. Unity와 Unreal 데모를 만든다. 기술적 온보딩에서 SDK Agent를 지원한다. 이것이 자율 코딩 에이전트다. 지시를 받아 일한다. 스스로 우선순위를 정하지 않는다.

이것이 캡스톤 명단이다: 정의된 역할을 맡은 일곱 개의 에이전트, 그리고 그들 사이의 명시적인 상호작용.

내가 추가하는 세 가지

캡스톤이 대부분을 완성한다. 필요하다고 생각하지만 원래 초안에는 없던 역할이 세 가지 있다. 이번 토요일에 추가한다.

Developer Relations Agent. GitHub 이슈. Discord. Reddit. 개발자가 질문을 했는데 SDK Agent가 아직 그에 대한 문서를 가지고 있지 않을 때 응답하는 에이전트. 이것은 컨시어지 업무다. 동시에 전도(evangelism) 업무이기도 하다. 이 역할을 맡은 적임자(혹은 적임 에이전트)는 어떤 마케팅 자료로도 대체할 수 없는 방식으로 스튜디오 및 인디 개발자와 신뢰를 쌓는다.

Strategic Partnerships Agent. B2B 아웃리치. 라이선싱 대화. 게이밍 카페, e스포츠 경기장 등 스튜디오가 아닌 누군가가 이 제품을 처음 경험할 수 있는 모든 곳과의 공동 마케팅 딜. 소비자 채널이 아닌 매출 채널을 뒤쫓는 에이전트다.

Agent Governance Agent. 다른 에이전트들을 모니터링하는 에이전트. 업그레이드를 제안한다. 버전 관리를 담당한다. 어떤 에이전트가 잘못된 판단을 내렸을 때 롤백을 처리한다. 이것이 이런 종류의 워크플로우에서 진짜 언락이라고 생각하는 재귀 구조다. 이것이 없으면 에이전트들은 표류한다. 이것이 있으면, 감시자를 감시하는 누군가가 있기 때문에 시간이 지날수록 더 나아진다.

상호작용 맵은 어떤 모습인가

화이트보드 버전을 단순화하면:

• 최고 감독(나)이 맨 위에 앉는다.
• Agent Governance Agent가 내 아래에 앉아 그 아래의 모든 것을 감시한다.
• Product, SDK, Codex Dev가 기술 작업의 한 삼각형을 이룬다.
• Studio와 Developer Relations가 개발자 대면 표면을 이룬다.
• Marketing과 Strategic Partnerships가 외부 대면 표면을 이룬다.
• Operations와 AI/Data가 그 아래에서 교차 관심사로 자리한다.

각 에이전트는 다른 에이전트들과 명시적인 상호작용을 갖는다. SDK는 Codex Dev와 이야기한다. Studio는 Marketing과 이야기한다. Operations는 모두와 이야기한다. Governance Agent는 전체를 감시하며 어떤 에이전트의 결과물이 자신의 역할에서 벗어나기 시작하면 개입한다.

이것은 전통적인 회사의 조직도가 아니다. 대부분의 박스가 AI 에이전트이고 그 사이의 대부분의 연결이 자동화된 인계인 워크플로우의 조직도다. 조직도 안의 유일한 인간은 맨 위에서 프레이밍과 판단 작업을 하고 있다. 나머지는 모두 에이전트다.

왜 지금이 이것을 할 적기인가

세 가지 이유가 있다.

엔진 아키텍처는 팀에 의해 형성될 것이다. 문서화, 테스트, 코드 리뷰 같은 교차 관심사는, 에이전트들이 거기에 참여하려면 첫날부터 코드베이스 안에 설계되어 있어야 한다. 코드베이스를 먼저 쓰고 나중에 에이전트를 거기에 끼워 맞추려 하면, 대부분의 작업을 두 번 해야 할 것이다.

특허 자산이 신중하게 계획할 여유를 준다. 이 제품을 뒷받침하는 특허들은 10년 묵은 선행 기술이다. 경쟁의 타이밍은 “석 달 안에 출시하지 않으면 남이 한다”가 아니다. “적절한 순간에 적절한 것을 출시한다”는 것이며, 그 순간은 지난 10년 어느 때보다 가깝지만 여전히 계획을 세울 한 분기의 여유는 허용한다. 나는 그 한 분기를 쓰고 있다.

에이전트 자체가 설계되어야 한다. 각 에이전트는 시스템 프롬프트, 도구 세트, 가드레일 세트가 필요하다. 엔진을 에이전트보다 먼저 쓰는 것은, 작업이 이미 시작된 후에 팀을 채용하는 것과 같다. 그것이 코드베이스가 지원하도록 설계되지 않은 역할에 에이전트를 억지로 끼워 맞추게 되는 엔진 프로젝트의 결말이다.

다음은 무엇인가

다음 토요일은 SDK 설계로 들어간다. 폴더 구조, 모듈 표면, 각 부분에서 개발자와의 상호작용이 어떤 모습일지. 그다음 토요일은 데모 스위트로 들어간다: 정본 샘플 앱이 무엇인지, 무엇을 증명하는지, 무엇을 가르치는지. 여름이 끝날 무렵에는 설계 단계가 끝나고 실제 저장소를 열 수 있어야 한다.

전통적인 벤처 속도 기준으로는 느린 빌드다. 완성되고 나면 느려 보이지 않을 것이다.