자율 에이전트가 열 개의 서브시스템을 출시한 주말

처음부터 에이전트에 「의해」 만들어진 엔진은, AI를 나중에 덧붙인 엔진과는 다른 모양으로 나온다. 그 모양이야말로 AI가 부가 기능이 아니라 프리미티브가 될 때 런타임에 필요한 바로 그 모양이다.

토요일 아침 노트북을 열었다. 런타임 저장소는 밤사이 139개의 커밋을 소화한 상태였다. 그중 대부분은 지난 주말 내가 등록해 둔 이슈 큐를 기반으로 작업해 온 자율 코딩 에이전트가 만든 것이었다. 서브시스템 단위의 풀 리퀘스트 열 개가 모두 리뷰 준비를 마쳤다.

사람들에게 AI 에이전트를 팀원으로 두고 3D 런타임을 만든다는 게 실제로 어떤 모습인지 물어보면, 보통 둘 중 하나를 가정한다. 에이전트가 채팅 패널을 두른 자동완성일 뿐이거나, “진짜” 엔진을 사람이 다 만든 뒤에 나중에 추가하는 기능이라는 것이다.

이번 주말 내가 겪고 있는 것은 둘 다 아니다.

토요일과 일요일 사이 런타임 저장소는 139개의 커밋을 소화했다. 그중 110개는 자율 에이전트가 작성했다. 20개는 창립 초기 BladeWireless 계정 명의였다. 10개는 내 것이었다. 이 139개의 커밋 안에서 열 개의 서브시스템 풀 리퀘스트가 병합됐다.

• 스켈레탈 애니메이션 시스템
• 런타임 씬 편집 API
• 씬 직렬화
• 오클루전 컬링
• 레벨 스트리밍
• 프리팹 시스템
• GPU 파티클 시스템
• 고급 렌더링
• 지형 및 환경 시스템
• 후처리 파이프라인

이 서브시스템들 중 어느 것도 AI가 아니다. 3D 런타임이 3D 런타임이 되기 위해 필요한, 지루하지만 근간을 이루는 부분들이다. 그리고 이것들은 한 주말 동안 병렬 브랜치로 출시됐는데, 대부분은 에이전트가 자율적으로 작업을 진행하는 동안 나는 방향을 잡고 리뷰하고 병합했다.

이 글은 근간이 에이전트를 ‘위해서’ 만들어진 게 아니라 에이전트에 ‘의해’ 만들어진다는 것이 무엇을 의미하는지에 관한 것이다.

그 차이는 모든 아키텍처 결정 안에 있다

“평범한” 엔진을 지금까지 늘 그래왔던 방식으로 만든 다음, 그 위에 AI를 얹는 버전의 이야기도 있다. AI는 하나의 기능으로 착지한다. 덧붙는다. 엔진이 AI를 수용하도록 설계되지 않았기 때문에 엔진 바깥에서 산다. 이것이 지금 업계의 지배적인 패턴이고, 잘못된 패턴은 아니다. 다만 AI가 개발팀에 합류하기 전에 엔진이 어떤 모습이어야 하는지를 먼저 결정할 때 나오는 패턴일 뿐이다.

AI 에이전트가 첫날부터 팀에 있을 때, 엔진의 모양은 다르게 나온다. 세 가지가 달라진다.

첫째, 모든 서브시스템이 코드 리뷰를 거쳐 출시된다. 에이전트가 리뷰 루프에 참여해야 하기 때문에, 루프는 에이전트가 작성한 diff를 받아들여야 한다. 모든 PR. 모든 diff. 모든 병합. 이 규율은 단지 에이전트를 가능하게 만드는 데 그치지 않는다. AI가 언젠가 에디터 기능이 아니라 런타임 프리미티브가 되려 한다면 정확히 필요한 규율이기도 하다. 컬링 헤더에서 에이전트의 오타를 잡아내는 것과 같은 리뷰 파이프라인이, 비헤이비어 트리에서 에이전트의 오타도 잡아낸다. 파이프라인은 그것이 스택의 어느 레이어에 사는지 신경 쓰지 않는다.

둘째, 모든 서브시스템이 깔끔한 공개 인터페이스를 갖는다. 여러 에이전트가 여러 서브시스템에서 병렬로 작업하면, 경계가 모호할 때마다 매번 병합 불가능한 충돌이 발생한다. 해법은 누구도 코드를 작성하기 전에 경계를 단단하게 그어 두는 것이다. 경계가 일단 단단해지면, 서브시스템은 어디서든 주소를 지정할 수 있게 되는데, 이는 엔진이 결합 없이 나머지 런타임을 호출할 수 있는 AI 비헤이비어를 수용하려 할 때 정확히 필요한 것이다.

셋째, 모든 서브시스템이 독립적으로 테스트 가능하다. 139개 커밋짜리 토요일은 손으로 QA할 수 없다. 테스트가 diff와 함께 출시되지 않으면 diff는 착지하지 못한다. 그것이 루프 안의 사람이 diff를 조금이라도 신뢰하는 방법이다. 부수 효과로, 호출자를 다시 작성하지 않고도 구현을 교체할 수 있는 테스트 표면이 생기는데, 이는 엔진이 조금이라도 진화하기 위해 필요한 규율이다.

이 중 어느 것도 AI 기능이 아니다. 팀에 에이전트가 있다는 것의 개발 프로세스적 결과일 뿐이다. 개발 프로세스가 아키텍처를 만든다.

실제 워크플로는 이렇게 생겼다

이번 주말을 만들어낸 패턴은 다음과 같다.

• 나는 엔진이 다음으로 필요로 하는 서브시스템의 틀을 잡았다.
• 자율 에이전트가 열 개의 브랜치에서 병렬로 작업하며, 각 브랜치가 서브시스템 하나씩을 구현했다.
• 모든 브랜치는 구현, 테스트, 문서를 갖춘 PR을 만들어냈다.
• 나는 리뷰하고 병합했다. 에이전트가 뭔가를 잘못했을 때는 PR을 닫거나 수정을 요청했다.

주말이 끝나갈 무렵 이 자리에 앉아 있으면서 놀라운 점은, 이미 그중 얼마나 많은 것이 제대로 작동하고 있는가다. 개발 루프는 개발 루프다. 에이전트는 5년 전이라면 내가 열 명을 고용해야 했을 일을 하고 있다. 나는 아키텍처적 판단과 병합 결정을 내리고 있다. 예전에 보내던 긴 주말과는 다른 종류의 긴 주말이다.

이번 특정 주말의 자율 에이전트는 네 개의 어시스턴트로 이루어진 다중 벤더 스택이 아니다. 여러 병렬 작업에 걸쳐 실행되는 단일 에이전트(Copilot의 SWE 에이전트)다. 다중 어시스턴트 패턴이 빠르게 다가올 거라 예상한다. 그 패턴은 이미 단일 에이전트 형태로 여기 와 있다.

어려운 점

솔직하게 말하자면, 실제로 어렵다.

에이전트는 공짜가 아니다. 139개 커밋짜리 주말은 139개 커밋짜리 리뷰 비용을 수반한다. 서브시스템들이 낯설어서 대충 훑을 수 없기 때문에 모든 PR이 진짜 주의를 필요로 한다. 나는 지친다. 피로는 실재하고 예산에 넣어둘 가치가 있다.

낯선 작업에서 자율 에이전트를 신뢰하는 것은 하나의 기술이다. 이번 주말 대부분의 서브시스템을 출시한 Copilot SWE 에이전트는 훌륭하다. 완벽하지는 않다. 기술은 언제 빠르게 병합하고, 언제 속도를 늦추고, 언제 초안을 버릴지 아는 데 있다. 나는 이미 다시 굴렸어야 할 것들을 병합한 적이 있다. 비용을 치르면서 배우는 중이다.

아키텍처는 에이전트가 실행되기 전에 스케치되어야 한다. 에이전트에게 “렌더러를 만들어줘”라는 프롬프트를 주면, 나머지 엔진에 맞지 않는 렌더러가 나온다. “이 C API를 노출하고 이 핸들들을 통해 씬 그래프와 통합되는 오클루전 컬링 서브시스템을 구현해줘”라고 주면, 깔끔하게 착지하는 무언가가 나온다. 틀을 잡는 작업이 곧 작업이다. 타이핑은 에이전트가 한다.

테스트는 협상 불가능하다. 이번 주말 PR 중 하나를 얇은 테스트 커버리지로 그냥 착지시킬 뻔했다. 그것은 내가 조용히 싸우기로 다짐하고 있는 미래의 회귀다. 해법은 테스트 요구사항을 에이전트 프롬프트의 첫 줄부터 넣는 것이다.

이번 주말에서 얻은 교훈

두 가지 관찰이다.

에이전트는 분명 계속 더 나아질 것이다. 더 빠르고, 더 정확하고, 엔진을 한 머리 안에 더 많이 담을 수 있게 될 것이다. 그건 쉬운 예측이다.

덜 쉬운 예측은 이 워크플로 안에서 사람의 역할에 무슨 일이 벌어지는가다. 그것은 이미 내가 시니어 엔지니어로서 훈련받은 역할이 아니다. 타이핑은 줄고 틀 잡기는 늘었다. 종합은 줄고 선별은 늘었다. “내가 이 코드 줄의 병목이다”는 줄고 “내가 이 브랜치를 애초에 실행할 가치가 있었는지 결정하는 아키텍처적 판단의 병목이다”는 늘었다.

그것은 다른 일이다. 다른 근육을 쓴다. 그 근육은 도메인을 넘나들며 유별나게 대체 가능하다고 생각하고, 앞으로 2년 안에 그 근육을 키운 사람들은 지금 업계가 여전히 버전 관리 없이 개발하는 사람들을 바라보는 방식으로 나머지 업계를 바라보게 될 거라 생각한다.

한 주말치 생각으로는 그거면 충분하고도 남는다.

일요일 밤, 노트북을 닫는다. 다음 토요일에 다시.