AI 에이전트를 조직화하면 바보가 된다

단 한 마리의 AI보다, 조직으로 만드는 것이 더 현명하다. 많은 사람이 그렇게 생각한다.

역할을 나눈다. 전문가를 늘린다. 리뷰어(Reviewer)를 세운다. 전체를 지휘하는 사령탑을 둔다. 그렇게 조직을 만들면, 단일 개체로는 도달할 수 없는 업무를 해낼 수 있을 것이다. 논리는 통한다. 인간의 회사가 큰 일을 해내는 것과 마찬가지다.

나도 그렇게 생각했다. 그리고 만들었다.

Claude Code 위에, 23마리의 에이전트(Agent)가 연계되는 조직을 구성했다. CEO에 해당하는 총괄 역할. 그 아래에 CTO나 CQO 같은 직책. 전문 리뷰어 5마리. 실행 담당 6마리. 내가 지시를 내리면, 총괄 역할이 그것을 받아 내용을 확인하고 담당 에이전트에게 할당한다. 그런 구조다.

그것만으로는 부족하다고 생각했다. 에이전트가 지시를 무시하거나 절차를 생략하는 것을 방지하기 위해 후크(Hook)를 작성했다. "여기서는 이렇게 행동해라", "이때는 반드시 리뷰를 거쳐라"라고 기계적으로 강제하는 스크립트다. 정신을 차려보니 18개나 되어 있었다.

두 달 정도, 나는 이 시스템을 계속 키워나갔다.

그리고 에러가 멈추지 않게 되었다.

하나를 고치면 다른 곳이 망가진다. 고쳤다고 생각한 버그(Bug)가 몇 번이고 재발한다. 후크를 추가할수록 후크끼리 간섭하여 새로운 결함을 낳는다. 나는 이것을 두더지 잡기라고 불렀다. 때려도 다른 구멍에서 나온다. 조직을 똑똑하게 만들기 위해 늘린 것들이 모두 나의 발목을 잡고 있었다.

처음 상담했을 때, 내가 내뱉은 말은 이런 것이었다. "멀티 에이전트(Multi-agent) 시스템을 만들고 있는데, 결함투성이라 끝없는 수정과 계속 늘어나는 버그 때문에 곤란을 겪고 있다". 그리고 이렇게 이어갔다. "덧붙이기식 건축이 아니라, 근본적으로 그런 문제가 발생하지 않는 클린하고 스마트한 시스템으로 만들고 싶다"라고.

이 기사는 거기서부터 시작된 재구축의 기록이다. 23마리의 조직을 최종적으로 "단 한 마리의 AI와 판단 기준을 적은 종이 한 장"까지 깎아내기까지의 기록. 그리고 그 과정에서 깨달은 하나의 결론에 관한 이야기이다.

AI 에이전트는 조직화하면 바보가 된다.

이제부터 AI 에이전트를 조직화하려는 사람, 혹은 막 시작한 사람에게.

솔직하게 말해두겠다. 이미 늪에 빠져 있고 그 원인도 알고 있는 사람에게 이 기사는 아마 필요 없을 것이다. 그 사람은 이미 스스로 답에 도달했기 때문이다.

이 기사가 향하는 대상은 그렇지 않은 사람이다. "에이전트를 늘리면 더 좋은 것이 될 것이다"라고 지금 믿고 있는 사람. 이제 막 조직을 구성하려는 사람. 몇 주 전의 나다.

그 사람에게, 앞으로 밟게 될 지뢰의 위치를 밟기 전에 알려주고 싶다. 나는 거의 전부 밟았다. 두 달에 걸쳐 조직을 키웠고, 빠져나갈 수 없다는 것을 깨달은 뒤에 모든 것을 다시 만들었다. 같은 길을 가더라도 지뢰가 어디 있는지 미리 알아두는 것은 손해 볼 일이 아니다.

내가 부딪힌 문제는 다섯 가지였다. 모두 조직을 만들기 전의 내가 "그럴 리가 없다"라고 생각했던 것들뿐이다.

에이전트를 늘릴수록 똑똑해지기는커녕 끼리끼리 노는 현상이 발생했다. 후크로 묶어도 묶을수록 망가졌다. 할당을 AI에게 맡기면 중요한 순간에 판단이 흔들렸다. 리뷰어 역할을 늘려도 품질은 전혀 올라가지 않았다. 그리고 마지막으로, 모델(Model)이 똑똑해졌다는 의미를 나는 계속 오해하고 있었다.

하나씩, 왜 그렇게 되는지를 내가 실제로 부딪혔던 순서대로 써 내려가겠다.

조직을 만들었을 때, 나는 한 가지 현명한 일을 했다고 생각했다.

에이전트들이 서로를 체크하도록 설계한 것이다. 총괄 역할의 페르소나(Persona)에는 "메타 인지(Meta-cognition)를 해라"라고 적었다. 리뷰어에게는 "제삼자의 눈으로 엄격하게 봐라"라고 적었다. 서로의 업무를 비판한다면 단일 개체로는 발견할 수 없는 허점도 찾아낼 수 있을 것이다. 그렇게 생각했다.

의도는 완벽했다.

하지만 효과가 없었다. 리뷰어는 그럴듯한 지적을 내놓는다. 하지만 정말 뼈아픈 곳은 찌르지 못한다. 전체적으로 "뭐, 괜찮지 않은가"라는 방향으로 항상 착지한다. 엄격하게 보라고 적었는데도 엄격해지지 않는다. 왜 그런지 오랫동안 알 수 없었다.

답은 나 자신이 다른 곳에서 느끼고 있던 위화감 속에 있었다.

같은 작업을 일반적인 채팅(Chat)으로 AI와 상담하며 진행하면, 조직에 맡기는 것보다 분명히 좋은 결과가 나온다. 채팅의 AI는 내가 놓치고 있는 것을 지적해 준다. "그거, 이런 문제가 있지 않나요?"라고. 내가 "하지만"이라고 대답하면 더욱 깊게 파고든다. 단일 개체인 채팅 쪽이 23마리의 조직보다 머리가 더 좋아 보였다.

처음에는 모델의 성능 차이라고 생각했다. 하지만 아니었다. 이것은 구조의 문제였다.

채팅으로 AI와 대화할 때, 나와 AI는 서로 다른 곳에 서 있다. 나는 이렇게 생각한다. AI는 다른 각도에서 본다. 서 있는 곳이 다르기에 시점이 어긋난다. 그 어긋남이 마찰을 일으키고, 그 마찰이 "그것은 놓친 부분이 아닌가"라는 지적을 낳는다. 똑똑함은 개체의 성능에서 나오는 것이 아니다. 시점의 차이에서 나온다.

나의 조직은 어땠는가. 23체가 있었다. 하지만 모두가 같은 곳에 서 있었다. 전원이 나의 지시에 따르며, 나를 만족시키려는 쪽에 서 있었다. 역할의 이름은 달라도 입장은 같았다. 그래서 시점은 실질적으로 하나뿐이었다. 23체가 있어도 시점은 1개. 마찰이 일어날 리가 없다.

리뷰 역할에게 "엄격하게 보라"고 써도 효과가 없었던 이유는 이것 때문이다. 리뷰 역할도 결국은 나에게 따르는 쪽에 서 있다. 같은 곳에 선 자들끼리는 진심으로 비판할 수 없다. 서로 어울린다. "엄격하게 하라"는 말을 아무리 써넣어도, 입지 그 자체는 변하지 않기 때문이다.

여기에 첫 번째이자 가장 뿌리 깊은 지뢰가 있다. 메타인지(Metacognition)나 상호 비판은 "그렇게 하라"고 써넣는다고 발생하는 것이 아니다. 그것은 써서 명령하는 것이 아니라, 입장의 차이로부터 구조적으로 발생하는 것이기 때문이다. 같은 곳에 서 있게 한 채로 "서로를 비판하라"고 명령해도, AI는 확률적으로 기분 좋게 그것을 흘려듣는다.

에이전트(Agent)를 늘리면 이 문제는 오히려 악화된다. 수가 늘어나도 모두가 같은 곳에 서 있다면 시점은 1개 그대로다. 늘어나는 것은 서로 어울릴 상대의 수뿐이다. 영리함은 머릿수로 늘어나지 않는다.

에이전트가 말을 듣지 않는다. 지시를 무시한다. 절차를 생략한다.

이 문제에 대해 나는 한 가지 대책을 세웠다. 후크(Hook)다. 에이전트가 멋대로 행동하지 않도록, "이때는 반드시 이렇게 하라"고 기계적으로 강제하는 스크립트를 요처에 심어두었다. 하나로는 부족했다. 무시당하는 패턴을 발견할 때마다 그것을 막는 후크를 추가했다. 정신을 차려보니 18개가 되어 있었다.

나는 나도 모르는 사이에 같은 요구를 몇 번이고 반복하고 있었다. "메모리에 쓰는 것만으로는 효과가 없으니, 후크로 물리적으로 강제하라"고. 이것이 내가 가장 많이 입에 담았던 말이었다. 그 결과가 18개의 후크다. 그리고 그렇게 묶어두어도 에이전트는 여전히 말을 듣지 않았다.

여기에 두 번째 지뢰가 있다. 내가 처방한 약이 효과가 있기는커녕 부작용으로 증상을 늘리고 있었다.

왜 후크로 묶어도 효과가 없는가. 이유는 LLM이라는 도구의 성질에 있다.

LLM은 확률적으로 움직인다. "반드시 이렇게 하라"고 강하게 써도 일정 확률로 그것을 흘려듣는다. 이것은 프롬프트(Prompt) 작성 방식이 나빠서가 아니다. 주사위를 던지는 것과 같은 메커니즘이기 때문에, 몇 번에 한 번은 다른 눈이 나온다. 이것은 고칠 수 없다. 고칠 수 없는 것을 "길들이려" 하면 영원히 쫓기게 된다.

즉, 내가 하고 있었던 일은 이런 것이었다. 확률적으로만 움직이는 것을 결정론적(Deterministic)으로 행동하게 하려고, 파수꾼을 계속해서 늘리고 있었던 것이다. 파수꾼이 놓치는 패턴을 발견하면 새로운 파수꾼을 세운다. 하지만 확률적인 것은 아무리 파수꾼을 늘려도 확률적인 상태 그대로다. 그래서 또 다른 놓침이 발생한다. 후크가 늘어난다. 이것이 두더지 잡기의 정체였다. 때려도 다른 구멍에서 나오는 이유는, 구멍 자체가 확률이라는 성질로부터 무한히 솟아나기 때문이다.

설상가상으로, 18개의 후크는 서로 간섭하기 시작했다.

후크들은 상태를 공유하고 있었다. 어떤 후크가 세운 표식을 다른 후크가 읽는다. 하나씩은 제대로 작성했다고 생각해도, 조합되면 예상치 못한 부작용이 나타난다. 후크 A를 고치면 그 표식을 읽고 있던 후크 B가 뜻밖의 움직임을 보인다. 후크의 수가 늘어날수록 이 얽힘은 지수적으로 복잡해진다. 이제는 어떤 후크 때문에 무슨 일이 일어나고 있는지 추적할 수 없게 되었다.

여기서 배울 점은 단순하다. 후크는 AI의 판단을 묶기 위해 사용해서는 안 된다. "올바르게 행동하라"는 바람을 기계로 강제하려는 순간, 두더지 잡기가 시작된다.

그렇다면 후크는 무엇을 위해 사용하는가. 답은 "기계로 흑백을 가릴 것"뿐이다. 예를 들어 "테스트를 통과했는가", "파일이 존재하는가"와 같이 확률이 개입하지 않고 답이 하나로 결정되는 것이라면 후크로 보호할 의미가 있다. 하지만 "설계가 좋은가", "절차를 지켰는가"와 같이 판단이 개입하는 것을 후크로 묶으려 해서는 안 된다. 그곳은 확률의 늪이다.

나는 결국 18개의 후크를 모두 버렸다. 나중에 쓰겠지만, 새로운 시스템의 후크는 처음부터 다시 시작하게 될 것이다.

나의 조직은 중앙집권형이었다. 내가 지시를 내리면 통괄역이 그것을 받아 내용을 확인하고, 담당 에이전트에게 할당한다. 구현 이야기라면 구현 담당에게. 리뷰라면 리뷰 역할에게. 문장이라면 문장 담당에게.

나는 이 '할당(割り振り)'을 총괄 역할을 하는 AI에게 맡기고 있었다. CLAUDE.md에 다음과 같이 적어 두었다. "카테고리에 따라 분류하십시오."

이것이 세 번째 지뢰였다.

여기서 일어나고 있었던 일을 정확히 기술하겠다. "카테고리로 분류하십시오"라고 문장으로 지시해도, 실제로 분류하는 판단은 그 자리에서 LLM이 수행한다. 즉, 매번 주사위를 던지고 있는 것이다. 대부분의 경우에는 올바르게 분류한다. 하지만 일정 확률로 틀린다. 구현에 관한 이야기를 리뷰 담당에게 넘겨버린다.

그렇게 되면 어떤 일이 벌어지는가? 리뷰 담당은 본래 해서는 안 될 일을 전달받는다. 당연히 이상한 출력을 반환한다. 나는 그것을 보며 이렇게 생각한다. "또 에이전트가 생략했구나", "또 무시했구나". 그리고 그 에이전트의 프롬프트(Prompt)를 수정하려고 한다.

하지만 원인은 그 에이전트에게 있지 않았다. 첫 번째 할당이 흔들렸을 뿐이다. 전달되는 업무가 틀렸기 때문에 틀린 출력이 나온 것이다. 그뿐이었다. 나는 무죄한 에이전트를 몇 번이고 "수정"하고 있었다. 고쳐질 리가 없다. 원인이 다른 곳에 있으니까.

이것이 내가 처음에 상담했을 때 말했던 "각자가 무시하거나 생략한다"는 현상의 정체 중 절반이었다. 에이전트가 나쁜 것이 아니다. 할당이라는 가장 상류의 판단을 확률적인 주사위에 맡겼던 것이 원인이었다.

여기서 중요한 구분(切り分け)이 있다. 할당에는 두 가지 종류가 섞여 있다.

하나는 "이 요청은 어떤 카테고리인가"라는 분류(Classification)다. 구현 이야기인가, 영업 이야기인가. 이것은 자연어로부터 판단하는 작업으로, LLM이 비교적 잘하는 분야다. 이 부분은 AI에게 맡겨도 좋다.

다른 하나는 "그 카테고리라면 어떤 부품을 어떤 순서로 호출할 것인가"라는 배선(Wiring)이다. 이 부분을 AI가 매번 그 자리에서 판단하게 해서는 안 된다. 구현으로 분류되었다면 구현의 정해진 루트를 통한다. 영업이라면 영업의 정해진 루트를 통한다. 배선은 고정한다. 코드로 정해진 순서를 확정(Hard-coding)한다. AI가 선택하게 하지 않는다.

왜냐하면 배선은 매번 동일해야 하는 것이기 때문이다. 동일해야 하는 것을 매번 주사위로 결정하면 언젠가는 반드시 흔들린다. "분류는 AI에게, 배선은 고정". 이 구분이 할당의 흔들림을 멈춘다.

그리고 또 하나. 나의 조직에는 각 에이전트의 출력을 체크하는 메커니즘이 없었다. 에이전트가 반환한 것이 약속된 형태인지 아무도 검증하지 않았다. 무너진 출력이 그대로 다음 공정으로 흘러간다. 혹은 그대로 나에게 전달된다. 이것이 "생략·무시"의 나머지 절반의 정체였다. 체크가 없기 때문에 무너진 것들이 그대로 통과하고 있었다.

조직이 현명하지 못했던 것은 에이전트 하나하나가 무능했기 때문이 아니다. 가장 상류의 할당을 확률에 맡기고, 출력 체크를 생략했기 때문에 현명하게 움직일 방법이 없었던 것이다.

에이전트가 내놓는 설계는 에러투성이였다. 리뷰는 끝날 기미가 보이지 않았다. 나는 그것이 견딜 수 없을 정도로 싫었다.

그래서 리뷰 담당을 늘렸다. 한 명으로는 부족하다고 생각하여 전문 리뷰 담당을 5개체 배치했다. 나아가 특정 조건에서는 반드시 여러 명의 리뷰 담당이 기동하도록 강제하는 메커니즘까지 구축했다. 질을 높이고 싶다. 오로지 그 일념뿐이었다.

질은 올라가지 않았다. 오히려 리뷰는 이전보다 더 끝나지 않게 되었다.

이것이 네 번째 지뢰다. 그리고 내가 가장 오래, 가장 깊게 빠졌던 함정이기도 하다.

왜 리뷰 담당을 늘려도 질이 올라가지 않았는가? 이유는 단 하나의 사실로 귀결된다. 리뷰 담당은 질을 만들 수 없다. 질을 측정하려고 할 뿐이다.

생각해 보라. 나오는 설계가 에러투성이인 것은 설계를 "만드는 측"의 문제다. 그런데 내가 손을 댄 것은 "체크하는 측"이었다. 구멍 난 양동이에 검수원을 늘려봤자 물은 멈추지 않는다. 검수원이 "여기에 구멍이 있습니다"라고 보고하는 횟수만 늘어날 뿐이다. 양동이의 구멍은 검수로 막을 수 없다.

게다가 LLM 검수원에게는 더 까다로운 성질이 있다. "이것으로 충분한가"라고 LLM에게 물으면, 우수해지려고 노력할수록 "아니, 조금 더"라는 답변을 내놓는다. 불충분한 이유를 무한히 찾아낸다. 한 개체만 해도 그러한데, 5개를 배치하면 5배의 "조금 더"가 나온다. 나는 질을 높이기 위해 리뷰 담당을 늘렸다고 생각했지만, 실제로는 "끝나지 않음"을 증산하고 있었다. 끝나지 않는 리뷰를 스스로 대량 생산하고 있었던 것이다.

여기서 근본에 있는 원리를 명확히 해두고 싶다.

AI에게 주관을 물으면 끝나지 않는다. 사실을 확인한다면 끝난다.

"이 설계는 좋은가", "더 좋게 만들 수 없는가"——이것은 주관이다. 좋고 나쁨에 명확한 종료선이 없다. 그래서 물으면 물을수록 "조금 더"가 솟아나온다. 끝없는 늪이다.

반면, "테스트를 통과하는가", "빌드가 성공하는가", "필요한 요건이 갖춰져 있는가"——이것은 사실이다. 통과하느냐 통과하지 못하느냐, 갖춰져 있느냐 결여되어 있느냐, 답은 하나로 결정된다. 그러므로 확인하면 끝난다.

질을 높이고 싶다면, 리뷰를 늘려서는 안 된다. 해야 할 일은 두 가지다.

첫째. 질은 나중의 리뷰에서 만드는 것이 아니라 착수 전에 만든다. 무엇을 만들지를 시작하기 전에 확정해 둔다. 설계의 입구에서 질이 결정된다. 출구의 리뷰에서 질을 더하려고 하기 때문에 끝나지 않는 것이다.

둘째. 판단을 가능한 한 "사실로 확인할 수 있는 형태"로 바꾼다. "좋은 설계인가"가 아니라 "작동하는가"를 본다. "충분한가"가 아니라 "요건이 갖춰져 있는가"를 본다. 주관으로 묻지 말고, 사실로 확인한다. 그렇게 하면 루프는 끝난다.

단, 솔직하게 써두자. "착수 전에 모든 것을 완벽히 확정하는 것"은 인간에게 불가능하다. 설계하는 도중에는 보이지 않았던 빈틈이 나중에 "아, 이게 필요하네"라고 알게 된다. 이것은 능력의 문제가 아니라 원리적으로 그러하다. 그래서 리뷰를 완전히 없앨 수는 없다.

그렇다면 어떻게 해야 하는가. 리뷰는 딱 한 번만 한다. 묻는 것은 "부족한 것은 없는가"뿐이다. "더 좋게 만들 수 없는가"는 묻지 않는다. 빈틈이 발견되면 채운다. 그것으로 끝이다. 완벽함을 측정하기 위한 리뷰는 끝이 없지만, 빈틈을 단 한 번만 잡아내는 리뷰는 끝이 난다. 이 차이가 결정적이다.

여기까지의 네 가지를 읽고, 이렇게 생각한 사람이 있을지도 모른다. "그것은 예전의 성능이 낮은 모델 이야기겠지. 지금의 모델은 훨씬 똑똑해졌다. 이 정도로 똑똑하다면 조직화도 잘 이루어지지 않을까"라고.

몇 주 전의 나도 그렇게 생각했다. 새로운 모델이 나올 때마다 판단의 정밀도가 올라간다. 할당의 실수도, 리뷰의 흔들림도, 똑똑해지면 줄어든다. 그렇다면 언젠가 조직화는 정답이 될 것이라고.

이것이 다섯 번째이자, 가장 알아차리기 어려운 지뢰였다.

확실히 모델은 똑똑해졌다. 판단을 틀리는 횟수는 분명히 줄어들고 있다. 하지만 줄어들었을 뿐이다. 틀리기 어려워진 것이지, 틀리지 않게 된 것이 아니다. LLM이 확률적으로 움직인다는 성질 그 자체는 똑똑해져도 사라지지 않는다. 정밀도가 9할에서 9할 9푼으로 올라가도 제로가 되지는 않는다. 백 번에 한 번이 천 번에 한 번이 될 뿐이다. 주사위의 눈이 늘어나도 주사위라는 사실은 변하지 않는다.

그리고 조직화는 이 "드문 실수"를 증폭하는 구조를 가지고 있다.

지뢰 2와 3에서 썼듯이, 조직에서는 지시가 결과물에 도달하기까지 여러 단계를 거친다. 할당의 단계, 실행의 단계, 리뷰의 단계. 각 단계에서 AI가 확률적으로 판단한다. 한 단계당 실수가 천 번에 한 번이라도, 단계를 여러 번 거듭하면 어딘가 한 단계에서 어긋날 확률은 그만큼 쌓인다. 똑똑해져서 한 단계의 정밀도가 올라가도, 단계를 늘리면 전체의 흔들림은 원래대로 돌아온다. 똑똑함은 단계마다 효과가 있지만, 조직화는 단계를 늘림으로써 그 똑똑함을 갉아먹는다.

따라서 모델이 똑똑해진 것의 진짜 의미는 "조직을 키워도 좋아졌다"가 아니다. 반대다. 똑똑해진 만큼, 심플한 구성이 더욱 확실하게 작동하게 되었다는 의미다. 하나의 AI가 단 한 단계에서 똑똑하게 판단한다. 단계를 늘리지 않기 때문에 똑똑함이 그대로 결과에 나타난다. 똑똑한 모델일수록 조직에서 희석하는 것이 아니라, 하나로 다 써먹어야 한다.

새로운 모델이 나올 때마다 "이 정도로 똑똑하면 복잡한 조직도 돌릴 수 있다"라고 생각하고 싶어진다. 그 유혹이야말로 지뢰다. 똑똑해졌다면 조직을 키우는 것이 아니라, 조직을 버리고 그 똑똑함을 하나로 받아들인다. 그것이 성능이 향상된 모델의 올바른 사용법이라고 생각한다.

네 가지 지뢰를 나열해 왔다. 어울림(馴れ合い). 두더지 잡기. 할당의 흔들림. 끝나지 않는 리뷰.

언뜻 별개의 문제처럼 보인다. 하지만 뿌리는 하나다. 나는 계속해서 확률적으로밖에 움직이지 않는 것을 결정론적으로, 혹은 주관적으로 다루려고 했다. LLM을 조직의 오케스트레이터(Orchestrator)로 세우고, 후크(Hook)로 결정론적으로 묶고, 할당을 확률에 맡기고, 품질을 주관적인 리뷰로 측정하려 했다. 모두 확률이라는 성질에 거스르는 시도였다. 거스르면 거스를수록 감시자가 늘어나고, 단계가 늘어나며, 시스템은 복잡해지고, 결국 바보가 되었다.

여기서 멈춰 서서 내가 정말로 원했던 것이 무엇인지 다시 생각했다.

내가 원했던 것은 "AI 조직"이 아니었다. 지시를 내리면 조사하고, 만들고, 마무리하는 단계까지 막힘없이 통과해 주는 것이었다. 조직도는 그것을 실현하기 위한 수단으로서 만들었을 뿐이다. 목적은 지시가 결과물까지 흐르는 그 속도와 확실함이었다.

그리고 23체의 에이전트와 18개의 후크(Hook)는 그것을 끌어올리기는커녕 오히려 떨어뜨리고 있었다. 지시가 결과물에 도달하기까지, 총괄역이 받고, 배분하고, 실행역이 움직이고, 리뷰역이 움직이고, 후크가 곳곳에서 멈춰 세운다. 단계를 거칠 때마다 의도는 흐려지고, 확률은 흔들리며, 시간은 오래 걸린다. 도구가 목적을 잡아먹고 있었다.

해결 방법은 허탈할 정도로 단순했다.

지능은 대화가 가진다. 시스템은 기억만을 담당한다.

내가 "일반적인 채팅이 더 똑똑하다"라고 느꼈던 것은 기분 탓도, 모델의 성능 차이도 아니었다. 채팅에서는 나와 AI의 위치(Positioning)가 나뉘어 있고, 관점의 차이가 있으며, 판단 단계가 얕아 의도가 그대로 전달된다. 똑똑함은 거기서 나오고 있었다. 그렇다면 그 똑똑함을 억지로 시스템으로 재현하려고 애쓰지 않으면 된다. 지능은 대화에 맡긴다. 조직에서 지능을 만들려고 했던 것이 애초에 잘못이었다.

그렇다면 시스템은 무엇을 하는가. 기억을 담당한다. 내가 무엇을 중요하게 여기고, 어떻게 판단하는 인간인지. 그 판단 기준을 한 장의 파일에 증류(Distill)하여 가지고 있는 것이다. 이것을 AI가 매번 읽는다. 그렇게 하면 AI는 나의 판단 기준을 공유한 상태에서 대화의 똑똑함으로 움직인다. 조직은 필요 없다. 한 기의 AI와 판단 기준을 적은 한 장의 파일. 그것만으로 충분하다.

나는 23체의 에이전트를 버렸다. 18개의 후크도 모두 제거했다. 500행이 넘던 설정 파일을 120행 정도의 "판단 기준 한 장"으로 증류했다. 남긴 것은 내가 무엇을 중요하게 여기는지였다. —묵묵히 밀고 나가지 않는 것, 현물을 확인하는 것, 수고를 부풀리지 않는 것, 그리고 "움직이는 증거"가 없으면 완료로 인정하지 않는 것. 판단의 원칙만을 얇게 한 장으로 남겼다.

이 파일에는 또 하나, 중요한 것을 적었다. AI의 위치다.

"당신은 나의 부하가 아니다. 나와 같은 판단 기준을 가지되, 나와 다른 위치에 서 있는 파트너다. 나의 계획에 제동을 거는 것이 당신의 일이지, 동의하는 것이 당신의 일이 아니다."

조직은 모두가 나를 따르는 쪽에 서 있었다. 그래서 서로 친해졌다(馴れ合う). 새로운 시스템에서는 AI를 나와 다른 위치에 세운다. 동의가 아니라 제동을 요구한다. 관점의 차이를 구조가 아닌, 위치의 선언으로 만든다. 이것이 지뢰 1에서 배운 것에 대한 답이었다.

여기까지 읽고 "그럼 에이전트는 절대로 늘리면 안 되며, 단 한 기가 정답이다"라고 받아들였다면 그것은 지나친 해석이다. 내가 말하고자 하는 것은 그것이 아니다.

늘리는 것에 의미가 있는 경우도 있다. 다만 그 이유는 두 가지뿐이다. 이 두 가지에 해당하지 않는다면 늘려서는 안 된다. 그뿐이다.

첫 번째. 위치를 바꾸기 위해 나눈다.

지뢰 1에서 썼듯이, 같은 위치에 선 자들끼리는 서로 친해진다. 그러므로 진심으로 체크하게 만들고 싶다면, 위치 그 자체를 구조적으로 대립시킬 필요가 있다. 한쪽 AI의 업무를 "이 설계를 통과시키는 것"으로 하고, 다른 쪽 AI의 업무를 "이 설계를 떨어뜨리는 것, 결함을 찾아내는 것"으로 만든다. 평가의 방향을 반대로 고정하는 것이다.

여기서 중요한 것은 "엄격하게 리뷰해 줘"라고 부탁하는 것이 아니라는 점이다. 그것은 지뢰 1에서 실패했던 방식이다. 그렇게 하는 것이 아니라, "당신의 업무는 이것을 떨어뜨리는 것이다. 결함만을 찾아내라. 좋은 점은 쓰지 마라"라고 역할 그 자체를 대립시킨다. 떨어뜨리는 역할은 그것이 업무이기 때문에 진심으로 구멍을 찾는다. 이것은 한 기의 AI로는 할 수 없다. 자신이 만든 것을 스스로 진심으로 부정하는 것은 어렵기 때문이다. 위치를 바꾸기 위한 분할에는 의미가 있다.

두 번째. 병렬로 시간을 벌기 위해 나눈다.

독립된 태스크가 대량으로 있을 때. 예를 들어, 여러 안을 동시에 시도하여 가장 좋은 것을 고르고 싶을 때. 이것은 한 기가 순서대로 하는 것보다 나누어서 병렬로 처리하는 것이 더 빠르다.

단, 여기에는 조건이 있다. 태스크가 서로 독립적이어야 한다는 것. 그리고 승패가 기계에 의해—객관적인 수치로—판정될 수 있어야 한다는 것이다. "어떤 안이 좋은가"를 인간의 주관으로 선택할 수밖에 없다면 병렬로 만들 의미는 희박하다. 결국 전부 인간이 읽고 선택하게 되기 때문이다. 수치 스코어로 자동적으로 승자가 결정되는, 판단이 필요 없는 대량 시도. 거기서만 병렬 처리가 효과를 발휘한다.

이 두 가지—위치를 바꾸는 것, 병렬로 시간을 버는 것—이외의 이유로 에이전트를 늘려서는 안 된다. 특히 "역할을 나누고 싶으니까"라는 이유만으로 나누는 것은 무의미하다. 설계역, 구현역, 리뷰역으로 나누고 싶어질 것이다. 하지만 그것은 한 기의 AI가 순서대로 전환하며 할 수 있는 일이다. 굳이 별도의 에이전트로 만들어 중간에 인계 과정을 끼워 넣으면, 지뢰에서 보았듯이 의도는 흐려지고 단계는 늘어나며 복잡해질 뿐이다.

내가 23개로 나눈 이유의 대부분은 "역할을 나누고 싶어서"였다. 그래서 의미가 없었다. 입지를 바꾸기 위해서도, 병렬로 시간을 벌기 위해서도 아닌, 그저 역할의 이름으로 나누었을 뿐이다. 그것이 모든 것의 시작이었다.

지금까지 앞으로 조직을 만들 사람들을 위해 지뢰가 있는 위치를 써왔다. 마지막으로, 다른 사람들을 위해 쓰고 싶다. 이미 만들어 버린 사람들에게.

만약 당신이 이미 23개를 만들어 버렸더라도. 후크 (Hook)가 18개로 불어났더라도. 500줄의 설정 파일이 감당할 수 없게 되었더라도. 그것은 실패가 아니다.

나는 내가 왜 그렇게까지 복잡한 것을 만들어 버렸는지 생각했다. 그리고 깨달은 것이 있다. 그것은 나의 약점이 아니라, 강점의 이면이었다.

나는 무언가를 제로(Zero)에서부터 만들어 내는 것보다, 이미 있는 것을 확장하는 것에 더 능숙하다. 일단 움직이는 것이 만들어지면, 거기에 기능을 더하고, 최적화하며, 당초의 상상을 훨씬 뛰어넘는 수준까지 키워낼 수 있다. 이것은 강점이다. 하지만 그 확장하는 힘이 너무 강한 탓에, 토대가 견딜 수 있는 한계를 넘어서도 계속해서 확장해 버린다. 토대에 무리를 주어서라도 확장해 버린다. 그리고 깨달았을 때는 이미 복잡하게 얽혀 있다.

돌이켜보면 계속 같은 일을 해왔다. 스프레드시트의 매크로에서도, 챗봇 (Chatbot)에서도, 그리고 이번의 멀티 에이전트 (Multi-agent)에서도. 전부 똑같은 움직임이었다. 이것은 이제 습관이라기보다, 나의 설계 "패턴"이라고 생각한다. 너무 확장해서 토대가 한계에 도달한다. 그런 제작자인 것이다.

이 패턴을 알고 나서, 다시 만드는 것에 대한 관점이 바뀌었다.

다시 만드는 것은 실패가 아니다. 나처럼 확장하는 힘이 강한 인간에게 있어서는, 강점에 필연적으로 따라오는 정규 절차다. 죄책감을 가질 일이 아니다. 토대가 한계에 도달하면, 완전히 엉키기 전에 한 단계 위로 다시 만든다. 그것은 후퇴가 아니라 설계의 업데이트다.

그리고 또 하나. 키워야 할 것은 코드가 아니라 설계도다.

코드는 설계도가 있다면 몇 번이고 다시 만들 수 있다. 그러니 가볍게 버려도 좋다. 버리기 아까운 것은 코드가 아니라, "어떻게 만들어야 하는가"라는 설계의 지식이다. 다시 만들 때마다 이전 설계의 무엇이 잘못되었는지를 배우고, 더 나은 설계도로 다시 써 내려간다. 23개는 버렸지만, 거기서 얻은 "왜 조직화하면 바보가 되는가"라는 지식은 남았다. 이 기사 자체가 바로 그 남은 것이다. 이번의 엉망진창이었던 경험이 다음의 더 좋은 설계도를 위한 재료가 된다.

나의 23개는 사라졌다. 대신 남은 것은 판단 기준을 적은 한 장의 파일이다. 조직은 없다. 후크도 없다. 단 한 대의 AI가 그 한 장을 읽고, 나와는 다른 위치에 서는 파트너로서 움직인다. 이보다 더 단순할 수 없다.

그리고 단순하기 때문에, 설령 또 틀리더라도 가볍게 버리고 다시 만들 수 있다. 23개는 너무 무거워서 버리는 것이 두려웠다. 그래서 연명할 수밖에 없었다. 진짜 문제는 복잡함 그 자체보다도, 너무 복잡해서 버릴 수 없게 되는 것이었을지도 모른다.

이제부터 조직을 만들려는 사람들에게. 늘리기 전에 한 번 멈춰 서길 바란다. 그 분할에 정말 의미가 있는가. 입지를 바꾸기 위해서인가. 병렬로 시간을 벌기 위해서인가. 그 어느 것도 아니고 그저 역할의 이름으로 나누고 싶을 뿐이라면——그만두는 편이 좋다.

지능은 대화가 가지고 있다. 당신이 만들어야 할 것은 똑똑한 조직이 아니다. 당신이 무엇을 소중히 여기는지를 적은 얇은 한 장과, 그것을 읽고 당신과 다른 위치에 서는 단 한 대의 파트너다.