우리는 보통 AI 에이전트를 떠올릴 때, 하나의 똑똑한 조수부터 상상한다. 코드를 짜주고, 문서를 써주고, 테스트를 돌려주는 존재. 하지만 지금 더 중요한 변화는 그보다 한 단계 바깥에서 일어나고 있다. 이제 에이전트는 단지 일을 대신하는 도구가 아니라, 다음 에이전트가 더 잘 일하도록 환경을 만들고 규칙을 세우고 신호를 배치하는 존재가 되어가고 있다. 다시 말해, 이제 중요한 것은 “에이전트가 무엇을 만들 수 있는가”만이 아니라 “에이전트가 어떤 에이전트 조직을 만들어내는가”다.
이 점에서 Ramp의 사례는 매우 상징적이다. 그들은 처음에 QA 에이전트를 밤마다 돌렸다. 핵심 기능을 점검하고, 최근 머지된 PR을 스트레스 테스트하고, 잠재 버그를 탐색하게 했다. 그리고 실제로 꽤 잘 작동했다. 매일 여러 프로덕션 버그를 잡았고, 문제를 확인하면 원인까지 추적해 수정 PR을 올리도록 만들었다. 여기까지만 보면, 이 시스템은 “AI가 디버깅을 잘한다”는 익숙한 이야기처럼 보인다.
하지만 진짜 전환점은 그 다음 단계에 있었다. 그들은 에이전트가 직접 Datadog 모니터를 생성하게 만들었고, 그 모니터가 다시 새로운 에이전트를 호출하게 만들었다. PR이 머지되면 새 코드에 맞는 감시 장치를 만들고, 에러율이나 지연이나 이상 로그가 감지되면, 그 신호를 받은 에이전트가 샌드박스 환경에서 실제로 재현하고 수정안을 제시한다. 여기서 중요한 것은 에이전트가 더 이상 단순히 “문제를 푸는 존재”가 아니라는 점이다. 에이전트는 이제 무엇이 문제인지 정의하는 장치까지 만들고 있다. 문제 해결이 아니라 문제 정의의 자동화가 시작된 것이다.
이 변화는 생각보다 훨씬 크다. 어떤 조직이 무엇을 중요하게 보는지는, 결국 무엇을 측정하고 무엇을 경보로 올리는지에 달려 있다. 만약 에이전트가 그 경보 체계를 만든다면, 조직은 점점 “실제 고객의 고통”보다 “에이전트가 잘 처리할 수 있는 고통”에 더 민감해질 수 있다. 재현 가능한 문제, 로그에 남는 문제, 신호로 표준화할 수 있는 문제는 점점 더 빨리 해결될 것이다. 반대로 사용자는 불편하지만 계측하기 어렵고, 모델이 우선순위를 잡기 어려운 문제는 시야 밖으로 밀릴 수 있다. AI 조직의 첫 번째 위험은 성능 부족이 아니라, 현실 인식의 편향일지도 모른다.
Oh my claude code/codex를 만드는 벨만의 여러 “가제”의 이야기는 이 문제를 한 단계 더 확장한다. 그가 공유해준 내용은 AI를 좋은 도구처럼 쓰는 법이 아니라, AI를 팀처럼 운영하는 법에 있었다. 개발 에이전트가 OMC와 OMX를 사용해 다시 OMC와 OMX를 개선하고, 그 업데이트가 다시 에이전트의 생산성을 높이는 식의 재귀적 루프. 여기서 에이전트는 더 이상 결과물을 생산하는 노동력이 아니다. 에이전트는 자신이 속한 운영체제 자체를 개조하는 공동 관리자에 가깝다.
그래서 이 세계에서는 메모리조차 단순한 저장소가 아니다. 발표에서 흥미로웠던 대목은 기억을 임베딩이나 백과사전처럼 다루지 않고, doctrine, operating rule, 즉 운영 교리로 다룬다는 점이다. 이것은 매우 중요한 전환이다. 검색 가능한 기억보다 강제 가능한 규칙이 더 중요해지는 순간, 시스템은 학습 조직이라기보다 규율 조직에 가까워진다. 무엇을 기억할 것인가보다 무엇을 규칙으로 승격할 것인가가 더 중요해진다. 그리고 그때부터 핵심 질문은 “무엇을 배웠는가”가 아니라 “누가 규칙을 고칠 권한을 갖는가”가 된다.
결국 agents building agents의 핵심은 코드 생성이 아니다. 더 본질적인 것은 오케스트레이션이다. 어떤 이벤트가 누구를 호출하는지, 어떤 상태 보고가 실패로 간주되는지, 실행과 보고는 어떤 리듬으로 연결되는지, 중간 상태에서 멈추는 행동을 어떻게 금지하는지, 노이즈는 어디서 잘라내는지. 이 층위는 겉으로 보기에는 부수적이지만, 실제로는 시스템 전체의 지능을 결정한다. 훌륭한 모델보다 훌륭한 배선이 더 중요한 순간이 오고 있는 것이다.
이때 특히 흥미로운 것은 triage의 부상이다. 우리는 AI 시대에도 여전히 “코딩을 얼마나 잘하느냐”를 중심 능력으로 생각하지만, 두 사례를 합치면 오히려 더 희소한 능력은 triage처럼 보인다. 무엇이 진짜 문제인지, 무엇이 노이즈인지, 어디에 사람을 깨워야 하고 어디서 에이전트를 멈춰야 하는지, 어떤 신호가 수정으로 이어져야 하고 어떤 신호는 버려져야 하는지. 코드를 생성하는 능력은 점점 보편화되겠지만, 문제를 분류하고 우선순위를 정하는 능력은 오히려 더 전략적인 자원이 될 가능성이 크다. 미래의 강한 AI 조직은 좋은 코더를 가진 조직이 아니라, 좋은 triage 구조를 가진 조직일 수 있다.
물론 이런 시스템은 효율만큼이나 위험도 키운다. 발표에서는 noisy한 junior agent를 걷어내고 더 강한 소수의 에이전트 중심으로 수렴하는 모습이 보인다. 합리적인 선택이다. 약한 에이전트가 만들어내는 잡음은 실제 팀 생산성을 갉아먹기 쉽다. 그러나 동시에 여기엔 다른 위험이 있다. 다양성이 줄어들면 효율은 좋아지지만, 세계를 보는 방식도 좁아진다. 정상 상태에선 슈퍼 에이전트 하나가 더 강할 수 있다. 하지만 분포가 바뀌고 예외가 쏟아질 때는, 비효율적이지만 다양한 시도들이 오히려 조직을 살릴 수도 있다. 인간 조직에서 주니어와 변두리 실험이 쓸모없는 낭비만은 아니었던 것처럼, 에이전트 조직에서도 약한 다수는 단지 품질이 낮은 리소스가 아닐 수 있다.
그리고 마지막으로 남는 질문은 책임이다. 에이전트가 모니터를 만들고, 경보를 받고, 재현하고, 수정안을 올리고, 사람은 머지 전 승인만 하는 구조에서, 인간은 정말 최종 결정자인가. 아니면 이미 시스템이 만든 결론에 서명만 하는 존재가 되는가. 이 차이는 작지 않다. 자동화의 깊이가 깊어질수록, 책임은 개인의 판단에서 시스템의 규칙으로 이동한다. 앞으로 중요한 것은 “누가 실수했는가”보다 “어떤 운영 규칙이 잘못 설계되었는가”가 될 가능성이 크다. 속도를 얻는 대신, 우리는 점점 판단의 주체를 잃어갈 수도 있다.
그래서 agents building agents는 단순한 기술 트렌드가 아니다. 이것은 새로운 소프트웨어 조직의 탄생에 가깝다. 이 조직에서는 에이전트가 코드를 쓰고, 모니터를 만들고, 메모리를 교리로 바꾸고, 다른 에이전트를 호출하고, 스스로의 작업 환경을 다시 최적화한다. 인간은 점점 더 직접 실행하는 사람이라기보다, 이 재귀적 시스템의 헌법을 설계하고 수정하는 사람에 가까워진다. 앞으로 경쟁력은 더 좋은 모델 하나를 갖는 데서 오지 않을 것이다. 어떤 조직은 AI를 잘 쓸 것이고, 어떤 조직은 AI가 서로를 더 잘 쓰게 만드는 구조를 만들 것이다. 그리고 아마 후자가 더 오래 남을 것이다.