얼마 전 AI 에이전트를 실제 업무에 붙여 쓰는 사람과 이야기를 나눴다. 처음에는 꽤 잘 움직였다고 했다. 문서를 읽고, 요청을 분류하고, 초안을 만드는 모습이 제법 그럴듯했다. 잘한다 싶으니 맡기고 싶은 일이 늘었다. 참고할 문서를 더 넣고, 이전 결정도 알려주고, 여러 팀의 사정까지 보태기 시작했다.
그런데 아는 것이 늘수록 에이전트는 오히려 둔해졌다. 간단한 요청에도 필요 없는 배경을 길게 꺼냈고, 서로 다른 시기에 세운 원칙을 한꺼번에 적용했다. 무엇이 중요한지 고르지 못한 채 모든 정보를 비슷한 무게로 다뤘다. 답은 길어졌지만 판단은 흐려졌다.
이 이야기를 듣다가 문득 이상한 점을 발견했다. 우리는 AI에게 회사의 모든 정보를 주면 더 나은 답을 낼 거라고 기대한다. 정작 회사에서 일하는 사람에게는 그런 기대를 하지 않는다. 누구도 회사의 모든 정보를 알지 못한다. 대표도, 오래 일한 구성원도, 여러 부서를 오가는 리더도 자기 자리에서 보이는 만큼만 안다. 그럼에도 조직은 굴러간다.
조직이 작동하는 까닭은 모두가 모든 것을 알아서가 아니다. 각자 무엇을 알아야 하는지, 모르는 일은 누구에게 물어야 하는지, 판단을 어디까지 맡을 수 있는지가 대체로 정해져 있기 때문이다.
모든 정보를 넣으면 더 잘할까
AI를 업무에 도입할 때 자주 빠지는 유혹이 있다. 답이 아쉬우면 문맥이 부족하다고 여긴다. 그래서 회의록을 붙이고, 정책 문서를 더하고, 과거 대화를 한데 모은다. 그래도 부족해 보이면 회사가 가진 자료를 가능한 한 많이 연결한다.
물론 문맥이 없으면 제대로 판단하기 어렵다. 고객의 요청만 보고 제품의 제약을 모르면 실현할 수 없는 답을 내놓는다. 최근에 바뀐 정책을 모르면 이미 폐기된 방식으로 일을 진행한다. 문제는 필요한 문맥과 많은 문맥을 같은 것으로 취급할 때 생긴다.
정보가 많아질수록 서로 충돌하는 내용도 늘어난다. 지난 분기의 우선순위와 지금의 우선순위가 나란히 놓이고, 특정 상황에서만 유효한 예외가 일반 원칙처럼 섞인다. 문서마다 같은 단어를 조금씩 다르게 쓰기도 한다. 사람은 회의에서 들은 말투나 당시의 분위기, 결정한 사람의 의도까지 떠올리며 어느 쪽에 무게를 둘지 정한다. 에이전트는 그 차이를 문서 안에서 찾아야 한다.
회사 자료를 전부 건네는 일은 문맥을 제공하는 것이 아니라 문맥을 고르는 책임까지 넘기는 일에 가깝다. 아직 업무의 경계도 모르는 대상에게 자료 더미를 주고 알아서 중요한 것을 찾으라고 요구하는 셈이다. 대답할 재료는 많아지지만, 무엇을 버려야 하는지는 더 알기 어려워진다.
사람도 회사 전체를 알지 못한다
사람이 제한된 정보로도 일하는 모습을 보면 다른 해법이 보인다. 재무를 맡은 사람은 모든 코드를 읽지 않는다. 개발자는 모든 고객과 나눈 대화를 기억하지 못한다. 디자이너가 계약의 세부 조항까지 매번 확인하는 것도 아니다. 대신 자기 판단에 필요한 정보가 어디에 있는지 알고, 경계를 넘어가는 순간에는 다른 사람을 찾는다.
여기에는 지식보다 역할이 먼저 놓여 있다. 역할은 해야 할 일만 정하지 않는다. 어디까지 혼자 판단해도 되는지, 어떤 변화가 생기면 알려야 하는지, 누구의 확인이 필요한지도 함께 정한다. 좋은 역할은 정보를 많이 품은 자리가 아니라 필요한 정보를 걸러내는 자리다.
문서도 같은 방식으로 작동한다. 회사의 모든 역사를 한 문서에 기록하지 않는다. 제품이 풀려는 문제는 PRD에, 고객이 겪은 일은 VOC에, 운영 원칙은 별도의 기준 문서에 남긴다. 각 문서는 서로 연결되지만 하나로 합쳐지지 않는다. 구분이 있기 때문에 필요한 순간에 필요한 문맥을 찾을 수 있다.
AI 에이전트에게도 이 구분이 필요하다. 에이전트 하나에 회사 전체를 재현하려 하기보다, 특정한 판단을 맡기고 그 판단에 필요한 문맥만 오래 관리하는 편이 낫다. 무엇이든 물어볼 수 있는 존재보다 어떤 문제를 책임지는지가 분명한 존재가 실제 업무에서는 더 믿을 만하다.
문맥도 나누어 맡아야 한다
우리가 에이전트를 운영하며 효과를 본 방식도 역할을 나누는 쪽이었다. 가운데에는 요청을 받아 성격을 파악하고 알맞은 곳으로 보내는 에이전트가 있었다. 이 에이전트가 모든 문제를 직접 해결하지는 않았다. 고객 문의인지, 제품 오류인지, 정책 변경인지 구분하고 해당 영역을 맡은 에이전트에게 일을 넘겼다.
각 영역의 에이전트는 훨씬 좁은 문맥을 가졌다. 제품을 맡은 에이전트는 해당 제품의 목표와 현재 상태, 최근 결정, 알려진 문제를 중심으로 판단했다. 고객의 목소리를 다루는 에이전트는 여러 경로에서 들어온 요청을 같은 기준으로 묶고 반복되는 신호를 찾았다. 문서를 관리하는 에이전트는 결정이 바뀌었을 때 어느 문서를 고쳐야 하는지 추적했다.
중요한 것은 에이전트의 수가 아니었다. 역할 사이의 인계가 분명한지가 더 중요했다. 요청을 넘길 때 어떤 정보를 함께 보내는지, 받은 쪽은 무엇을 결과로 돌려주는지, 판단하기 어려운 상황에서는 누구에게 멈춰 서는지를 정해야 했다. 이 약속이 없으면 에이전트를 나눠도 혼란만 여러 곳으로 흩어진다.
사람의 검토 지점도 달라졌다. 생성된 코드를 처음부터 끝까지 모두 읽는 데 힘을 쓰기보다, 에이전트가 어떤 문제를 풀도록 이해했는지 먼저 살폈다. PRD가 현재의 결정을 반영하는지, 고객의 요청이 과장되거나 누락되지 않았는지, 되돌리기 어려운 판단이 사람에게 올라오는지를 확인했다. 결과물을 일일이 다시 만드는 대신 결과가 나오는 경로를 검토한 셈이다.
작은 팀은 문맥을 적게 운반한다
작은 팀이 빠른 이유를 실행력에서만 찾기 쉽다. 손이 빠른 사람이 모였거나, 회의가 짧거나, 결정권자가 가까워서라고 생각한다. 모두 영향을 주지만 더 근본적인 차이는 문맥을 옮기는 양에 있다.
사람이 합류하면 그 사람의 작업만 늘어나는 것이 아니다. 기존 구성원이 알고 있던 배경을 설명해야 하고, 서로 다른 판단 기준을 맞춰야 하며, 이전에는 말하지 않아도 통하던 것을 문장으로 꺼내야 한다. 역할의 경계가 겹치면 같은 정보를 각자의 방식으로 해석한 뒤 다시 합의해야 한다. 새로운 손과 함께 새로운 연결이 생긴다.
AI가 실행 속도를 높일수록 이 문제는 더 선명해진다. 만드는 속도는 빨라졌는데 무엇을 왜 만드는지 맞추는 속도가 그대로라면, 팀은 더 많은 결과물을 앞에 두고 더 자주 멈춘다. 생산량이 늘어난 만큼 검토해야 할 판단도 늘어난다. 이때 병목은 코드나 디자인을 만드는 손이 아니라 문맥을 고르고 전달하는 구조로 옮겨간다.
그래서 작은 팀을 유지한다는 말은 단순히 사람을 덜 뽑는다는 뜻이 아니다. 모두가 같은 내용을 기억해야만 움직이는 구조를 피한다는 뜻에 가깝다. 책임을 작게 나누고, 필요한 정보가 제자리에서 갱신되게 하고, 경계를 넘을 때만 문맥을 운반한다. 사람과 에이전트가 늘더라도 이 원칙이 지켜지면 조직은 불필요한 설명에 덜 묶인다.
좋은 시스템은 모르는 방법을 안다
에이전트를 설계할 때는 무엇을 더 알려줄지 묻기 전에 무엇을 몰라도 되는지 정해야 한다. 이 에이전트가 책임질 판단은 무엇인지, 어느 문서를 기준으로 삼을지, 어떤 조건에서 다른 역할에 일을 넘길지, 어디부터 사람의 확인을 받을지 먼저 그려야 한다.
이 경계는 에이전트의 능력을 제한하는 장치처럼 보인다. 실제로는 능력을 쓸 수 있게 만드는 조건이다. 범위가 분명해야 관련 없는 정보를 버릴 수 있고, 기준이 분명해야 충돌하는 문서 사이에서 멈출 수 있다. 인계할 곳을 알아야 모르는 문제를 아는 척하지 않는다.
사람에게도 신뢰는 모든 것을 아는 데서 생기지 않는다. 자기 책임을 알고, 판단에 필요한 근거를 찾고, 혼자 결정해서는 안 되는 순간을 알아차리는 사람을 신뢰한다. 많이 아는 사람보다 모르는 것을 다루는 방법을 아는 사람이 함께 일하기 편하다.
회사의 모든 정보를 아는 사람은 없다. 그런 에이전트도 필요하지 않다. 좋은 시스템은 하나의 거대한 머리를 만드는 대신, 서로 다른 역할이 필요한 만큼 알고 정확히 건네도록 만든다. 조직의 지능은 각자가 품은 정보의 양보다 문맥이 제자리를 찾아가는 방식에 남는다.