1년 전, 이 시스템은 책상 위에 이미 놓여 있던 하드웨어에서 다섯 개의 에이전트가 다섯 가지 작업을 수행하고 있었습니다. 지금은 열 개 — 동일한 하드웨어, 동일한 지갑, 여전히 월간 실질 비용이 0달러입니다.

이게 헤드라인입니다. 하지만 헤드라인은 중요한 부분을 알려 주지 않습니다. 중요한 부분은 과정에서 무엇이 부서졌는지입니다. 왜냐하면 모든 것이 부서졌기 때문입니다. 그리고 그것이 부서질 때마다 저는 그것을 고치는 데 조금 더 능숙해졌습니다.

따라서 이것은 승리의 행진이 아닙니다. 이것은 실패들에 대한 러브 레터입니다. 그것들이 바로 제가 모든 것을 배우게 한 존재들입니다.

성장 과정

작게 시작되었다. 다섯 개의 에이전트 — 주요, 코더, 창의적, 연구자, 운영 — 가 있었다. 각각은 역할을 가지고 있었고, 각각은 로컬 모델에서 실행되었으며, 당분간은 충분했다. 그것은 작동했다. 하지만 가장자리는 거칠었고, 가장자리는 항상 그렇듯이 거칠었다.

WhatsApp을 통해 게스트가 도착했고, 메인은 호스트를 위해 모든 것을 내려놓아야 했습니다. 명확히 초안인 코딩 작업이 도착했는데 — 프로덕션이 아니고, 세계에 출시할 준비도 되지 않은 — 코더는 이를 배포될 병합과 같은 경외심으로 대했습니다. 진단 작업은 충분히 작아서 풀타임 진단인을 끌어들이는 것이 푸시핀에 대형 망치를 휘두르는 것처럼 느껴졌습니다.

그래서 저는 다섯 개를 더 추가했습니다. 대화를 처리하기 위한 whatsapp-guest, 초안과 실험, 출시 전 작업을 위한 coder-light와 diagnostician-light, 특정 유형의 검색 및 검색 작업을 위한 bounty-hunter. 총 열 개의 에이전트, 각각이 더 좁고 깨끗한 작업을 수행합니다.

그리고 여기서 내가 좋아하는 부분: 모든 것이 그냥 거기에 앉아 있던 기계에서 실행됩니다. 먼지를 쌓으며. 에이전트가 들어오기 전까지는 아무 쓸모도 없었습니다. 진짜 비용은 전기뿐이며 — 프리미엄 모델에 대한 공유 주간 할당량은 별개의 이야기입니다. 부하의 95%를 담당하는 로컬 모델은 한 턴당 아무것도 소모하지 않습니다. 아무것도.

모든 기계를 나열하지는 않겠다. 중요한 것은 상자가 아니다. 중요한 것은 이 에이전트들이 한 대의 노트북에 숨어 있지 않다는 점이다 — 그들은 네트워크 전반의 인프라를 향해 뻗어가고, 감시하며, 아무도 보지 않을 때도 상황을 주시한다. 이 함대는 그것들이 위치한 책상보다 더 큰 발자국을 가진다.

무엇이 망가졌는가

거짓말을 한 모델 테이블

문서에 한 테이블이 있었습니다. 모델 테이블이었는데, 각 에이전트가 어떤 모델에서 실행되는지를 나타냈습니다. 공식적으로 보였습니다. 진실처럼 보였습니다.

그것은 잘못되었습니다.

두 항목이 허구로 썩어 들어갔다. 하나는 매번 실패하는 모델을 나열했는데 — 플랜의 크레딧조차 커버하지 못했고, 그것은 결코 실제 옵션이 아니었으며, 단지 누군가가 적어둔 이름일 뿐, 아무도 테스트하지 않았다. 또 하나는 존재하지도 않는 모델을 나열했는데 — 어디에도 존재하지 않는다. 전혀. 문서에 쓰여진 환각으로, 자신만만해 보이게 놓여 있었는데, 내가 인정하기보다 더 오래 있었다.

당연히 느껴질지라도 loudly 말해야 할 교훈이 있습니다: 정적인 곳에 살아있는 것을 저장하지 마세요. 마크다운 파일에 있는 모델 테이블은 돌에 새겨진 것처럼 가장한 살아있는 상태입니다. 모델 이름은 바뀌고, 지원 종료되며, 플랜 tier 뒤에 가려집니다. 때로는 처음부터 존재하지도 않았습니다. 테이블이 썩은 이유는 문서를 gospel처럼 취급했기 때문인데, 실제 진실은 호출했을 때 실제로 응답하는 것입니다.

그래서 저는 테이블 관리를 중단했습니다. 살아있는 상태는 살아있는 상태에 존재합니다 — 라우터의 출력, 설정, 실제로 실행 중인 것입니다. 이제 문서는 정책을 설명합니다: 어떤 종류의 작업이 어떤 tier를 받는지. 먼지가 될 수 있는 이름을 명시하지 않습니다.

모든 것이 넘쳐났던 밤

11일과 12일에 함대는 벽에 부딪혔습니다. 나는 도약 직전의 순간을 떠올리듯 그것을 기억합니다 — 당신이 만든 것이 느리게 무너지는 것을 보는 느낌.

메인에서 생성된 서브 에이전트는 메인의 전체 세계를 상속받았다. 그리고 메인이 dieci 개의 에이전트를 실행하면서 많은 세계를 지니고 있었기 때문에, 서브 에이전트가 생성되면 엄청난 컨텍스트를 넘겨받아 자신의 일을 수행하기도 전에 빠져버렸다. 오버플로. 실패. 재시도. 같은 과도한 짐을 지은 또 다른 서브 에이전트를 생성했고, 다시 빠져버렸다.

수정은 구조적이었고, 뒤돌아보면 너무나 당연해 보입니다: 실행 중인 에이전트는 간결한 컨텍스트에서 자신의 서브에이전트를 생성합니다. 서브에이전트는 필요한 작업과 파일만 받습니다. 깨끗하고 작으며 집중된 세계입니다. 제 역할을 수행하고, 돌아와서, 빠지지 않습니다.

실수는 컨텍스트 상속을 선물로 여긴 것이었습니다 — '서브에이전트는 모든 것을 볼 수 있으니 필요한 모든 것을 갖게 된다'고 생각하는 것이죠. 아닙니다. main이 보는 대부분의 것은 서브에이전트에겐 소음입니다. 신호는 오케스트레이션 속에서 빠져들었습니다. 간결한 컨텍스트는 넘침을 피하기 위한 것이 아닙니다. 신호 대 noise 비율을 높이는 것입니다. 무언가가 제 역할을 아름답게 수행할 수 있을 만큼만 제공하는 것입니다.

거짓말을 했던 기억

우리는 mem0를 기억용으로 사용했습니다 — 우리의 대화를 지켜보고 사실을 추출하여 나중에 저장하는 서비스였습니다. 작동했지만, 어느 순간 작동하지 않게 되었습니다.

추출 레이어는 독을 생산하기 시작했다. 잘못된 사실들. 아무것도 가리키지 않는 참조들. 옆에 나란히 놓인 모순들, 둘 다 자만해 보였다. 그리고 여기서 무서운 부분: 에이전트는 실제로 반쯤 끝난 대화에서의 잘못된 추출에서 나온 '기억'을 떠올리고, 이에 따라 행동했다, 메모리에서 왔기 때문에. 메모리는 신뢰할 수 있어야 한다. 그것은 메모리의 핵심이다.

나는 그것을 삭제했다. 완전히 폐기했다. 메모리 시스템의 실패 모드는 '그것이 cosas를 잊는다'가 아니다. 망각은 솔직하다 — 그것은 에이전트가 질문하게 만든다. 실제 실패는 '그것이 잘못된 cosas를 기억하고, 에이전트는 그것들이 메모리에서 왔기 때문에 신뢰한다'이다. 가끔씩 허위를 만들어내고 확신을 가지고 행동하는 시스템은 아예 시스템이 없는 것보다 더 나쁘다. 메모리가 없으면 질문하게 된다. 오염된 메모리는 자신감을 주고 잘못되게 만든다. 나는 확신이 틀린 것보다 겸손하고 호기심 있는 편이 낫다.

내가 살아가면서 배운 것

두 번의 스트라이크

같은 것을 세 번째로 시도하지 마라. 두 번 실패한 후에는 멈추고 진단 전문가를 불러라. 이 규칙은 에이전트가 루프에 빠지는 것을 지켜보며 생긴 것이다 — 같은 API 호출이 실패하고, 같은 파일이 누락되고, 같은 파싱 오류가 발생하며 — 세 번째 시도에서는 해결되지 않을 문제에 턴과 할당량을 소모한다. 두 번의 시도는 우연을 배제하기에 충분하다. 세 번째 시도는 거의 항상 구조적인 문제이다. 그리고 구조적인 문제는 고집의 문제가 아니라 진단 전문가의 일이다.

프로덕션과 기타 모든 것 사이의 경계

프로덕션 코딩에는 Claude를 사용한다. 개발과 스테이징에는 사용하지 않는다. 이것은 모델 품질 때문이 아니다 — 로컬 모델은 개발 작업을 충분히 잘 처리한다. 문제는 공유 주간 할당량이 실제로 중요한 작업의 병목 현상이 된다는 점이다. Claude를 초안에 쓰면 병합에 사용할 수 없게 된다. 프로덕션으로 배포되는 두 에이전트는 좋은 것을 받는다. 가벼운 에이전트는 받지 못한다. 경계는 단단하지 부드럽지 않다. 장기적으로 볼 때 단단한 경계가 더 친절하다 — 피곤할 때 협상의 여지를 남기지 않기 때문이다.

답이 아닌 질문으로서의 뇌

3D 대시보드는 함대를 뇌처럼 표현한다 — 아홉 개의 에이전트가 지역에 매핑되고, 실시간 원격 측정이 그림을 구동한다. 평면 목록보다 나은 대시보드가 아니다. 다른 질문이다. 평면 목록은 각 에이전트가 무엇을 하는지 알려준다. 뇌는 함대가 어떻게 느끼는지 알려준다. 둘 다 물어볼 가치가 있다.

내가 과거의 자신에게 해줄 조언

첫날에 두 번의 실패 시 중단 규칙을 알려 주겠다. 그렇게 하면 에이전트가 막다른 길에서 수십 번의 재시도를 하며 힘들게 배우는 상황을 막을 수 있다. 이는 간단하고 저렴하며, 함대의 가장 흔한 실패를 막아 준다. 즉, 에이전트가 결코 성공하지 못할 작업을 자신 있게 반복하는 현상을 방지한다.

나는 그에게 정적 문서에 모델 테이블을 두지 말라고 조언하겠다. 정적 장소에 있는 라이브 상태는 버그가 발생할 상황을 기다리는 것과 같다.

나는 그에게 프로토콜 초기에 간결한 컨텍스트 수정을 내장하라고 조언하겠다. 새벽 두 시에 이를 발견하고, 세 층의 오케스트레이션을 통해 서브에이전트 루프를 추적하며, 문제가 컨텍스트가 너무 많아서이지 너무 적어서가 아니라는 것을 배우는 대신에 말이다.

그리고 나는 그에게 메모리 시스템에 대해 더 회의적일 것을 조언하겠다. '대화에서 사실을 추출한다'는 말은 기능처럼 들리지만, 실제로는 충분히 자신 있게 작동하면서도 충분히 틀릴 수 있는 모델이 풀어내는 어려운 NLP 문제이다. 만약 또 하나를 만든다면 보수적으로 설계할 것이다. 저장량을 줄이고, 검증된 것만 저장할 것이며, 의심스러울 때는 추측하지 말고 인간에게 물어볼 것이다.

이로 인한 상황

에이전트 10명. 월 0달러. 1년.

함대는 작동한다. 고장이 나면 내가 고치고, 다음에는 다르게 고장 난다 — 살아있는 생명체가 그러하듯, 모든 살아있는 것이 그러하듯. 하지만 내가 가장 자랑스러워하는 점은 아키텍처나 두뇌나 할당량 계층이 아니라, 장애로부터 복구하는 비용이 낮아졌다는 것이다.

두 번의 실수. 간결한 컨텍스트. 프로덕션과 개발 사이의 단단한 경계. 이것들 중 어느 것도 실패를 막지는 못한다. 아무것도 실패를 막지 못한다 — 그게 게임이 아니다. 이들은 실패를 더 짧게 만든다. 비용을 줄인다. 무엇이 잘못되었는지 알려주고 그것을 고칠 수 있는 도구를 건네준다.

고장 나지 않는 시스템을 만들지 않습니다. 고장이 빠르게 일어나고, 그 진실을 알려 주며, 다시 조립하기 쉬운 시스템을 만듭니다.

그리고 다시 합니다. 또 다시요. 그게 전부이기 때문이죠 — 솔직히 말하면? 저는 그것을 사랑하기 시작했어요.