에이전트는 조직이다

좋은 조직은 사람을 많이 모아놓은 곳이 아니다.

누가 무엇을 책임지는지 명확하고, 권한과 책임이 맞물려 있고, 결과가 피드백으로 돌아오고, 필요하면 역할이 바뀌는 곳이다. 일이 잘될 때는 각자가 알아서 움직이지만, 일이 실패했을 때는 어디서 왜 실패했는지 추적할 수 있어야 한다.

나는 에이전트 시스템도 결국 같은 문제를 만난다고 생각한다.

처음에는 프롬프트 하나로 충분해 보인다. 그다음에는 역할별 서브에이전트를 나눈다. 리서치 에이전트, 분석 에이전트, 리뷰 에이전트, 구현 에이전트. 여기까지 오면 시스템은 꽤 그럴듯해진다.

하지만 실제로 굴려보면 곧 다른 질문이 생긴다.

이 에이전트들은 누가 관리하는가.

누가 어떤 일을 맡아야 하는가. 결과가 틀렸을 때 책임은 어디에 있는가. 잘한 에이전트와 못한 에이전트는 어떻게 구분하는가. 어떤 에이전트의 권한을 넓히고, 어떤 에이전트의 권한을 줄여야 하는가. 조직도를 바꿔야 할 때는 언제인가.

내가 시장 분석 시스템을 만들면서 가장 먼저 배운 것도 이것이었다. 에이전트가 "완료했습니다"라고 말하는 것과, 일이 실제로 검증됐다는 것은 전혀 다른 문제였다. 기획을 잘했다고 말해도 숫자의 근거가 약할 수 있고, 구현을 끝냈다고 말해도 목표와 어긋난 변경일 수 있고, 리뷰를 통과했다고 말해도 중요한 리스크가 남아 있을 수 있다.

결국 필요했던 것은 더 긴 프롬프트가 아니라 운영 체계였다. 누가 기획하고, 누가 실행하고, 누가 검증하고, 어떤 기준으로 다음 단계로 넘길지. 그리고 그 모든 판단이 프로젝트의 골에 정렬되어 있는지 확인하는 구조.

이건 더 이상 프롬프트 엔지니어링만의 문제가 아니다.

AI 오퍼레이션 엔지니어링의 문제다.

함수에서 조직으로

1편에서 나는 에이전트를 함수에 비유했다.

하나의 에이전트가 너무 많은 일을 하면, 500줄짜리 handleEverything() 함수처럼 된다. 관심사가 뒤엉키고, 입력과 출력이 흐려지고, 결과 품질이 흔들린다. 그래서 에이전트도 함수처럼 쪼개야 한다고 했다.

리서치는 리서치 에이전트가 하고, 요약은 요약 에이전트가 하고, 검증은 검증 에이전트가 한다. 메인 에이전트는 이들을 조합한다.

하지만 시스템이 커지면 함수 비유만으로는 부족해진다.

함수는 호출된다. 조직은 운영된다.

함수는 코드를 읽으면 책임이 보인다. 조직은 실제 일이 흘러가는 방식을 봐야 책임이 보인다. 함수는 실패하면 스택 트레이스를 남긴다. 조직은 실패하면 회고와 개선 루프가 필요하다.

에이전트 시스템도 마찬가지다. 서브에이전트를 잘게 나누는 것만으로는 충분하지 않다. 그 에이전트들이 어떤 책임 체계 안에서 움직이는지, 어떤 기준으로 평가되는지, 실패가 어떻게 다음 실행에 반영되는지를 설계해야 한다.

하네스가 실행 구조의 문제였다면, 오퍼레이션은 지속 운영의 문제다.

실제로 에이전트를 나누는 순간부터 시스템은 코드라기보다 작은 회사처럼 보이기 시작한다. 기획만 하는 에이전트, PR을 관리하는 에이전트, 매일 시스템 상태를 브리핑하는 에이전트, 실제 코드를 고치는 에이전트가 생긴다. 문제는 이들을 "만드는 것"보다 "운영하는 것"이다.

각 에이전트가 자기 산출물을 내는 것만으로는 부족하다. 기획서는 구현으로 넘기기 전에 검증되어야 하고, 구현 결과는 리뷰를 통과해야 하고, 리뷰 결과는 실제 코드와 대조되어야 한다. 이 중 하나라도 빠지면 시스템은 빠르게 그럴듯한 자동화로 변한다. 겉으로는 바쁘게 돌아가지만, 실제로는 목표와 멀어질 수 있다.

서브에이전트는 직원이 아니다

여기서 조심해야 할 것이 있다.

에이전트를 조직에 비유한다고 해서, 서브에이전트를 진짜 직원처럼 보면 안 된다. 이전 글들에서 계속 이야기했듯이, 비유는 유용하지만 착각하면 위험하다.

직원은 경험을 축적한다. 맥락을 기억한다. 조직의 암묵지를 배운다. 자신의 실수에 대해 책임감을 느끼고, 다음번에 조심한다.

에이전트는 그렇지 않다.

에이전트는 매 호출마다 주어진 컨텍스트 안에서 추론한다. 메모리나 로그를 붙일 수는 있지만, 그것은 시스템이 제공하는 외부 장치다. 에이전트가 스스로 조직 문화를 내면화한다고 보면 안 된다.

그래서 "리서치 담당 에이전트"라는 말은 사람처럼 리서치 역량을 가진 직원을 의미하지 않는다. 더 정확히는, 리서치라는 책임 범위에 맞게 프롬프트, 도구, 권한, 입력 형식, 출력 형식이 묶인 실행 단위다.

이 차이가 중요하다.

서브에이전트는 직원이 아니라 역할 인터페이스다.

사람을 관리하듯 감정과 동기를 다루는 것이 아니라, 시스템 구성요소를 관리하듯 책임과 계약과 피드백을 다뤄야 한다.

역할보다 중요한 것은 책임 경계다

조직에서 직함은 종종 애매하다.

프로덕트 매니저, 데이터 애널리스트, 백엔드 엔지니어, 프론트엔드 엔지니어. 이름만 보면 대충 어떤 일을 하는지 알 수 있지만, 실제 책임은 조직마다 다르다.

에이전트도 마찬가지다.

research-agent라는 이름은 충분하지 않다. 무엇을 리서치하는가. 어디까지 판단하는가. 어떤 소스에 접근할 수 있는가. 결론을 내려도 되는가, 아니면 자료만 수집해야 하는가. 모호하면 안 된다.

역할 이름보다 중요한 것은 책임 경계다.

예를 들어 시장 분석 시스템에서 리서치 에이전트가 있다고 하자. 이 에이전트에게 "종목을 분석하라"고만 하면 책임이 너무 넓다. 자료 수집, 기업 요약, 섹터 비교, 투자 가설 생성, 리스크 판단, 포트폴리오 액션 제안이 모두 섞인다.

이 경우 책임을 나눠야 한다.

• 데이터 수집 에이전트: 지정된 소스에서 자료를 수집한다
• 엔티티 매핑 에이전트: 자료를 종목, 섹터, 테마에 연결한다
• thesis 에이전트: 수집된 근거를 바탕으로 가설을 만든다
• 검증 에이전트: 가설의 근거와 반대 근거를 점검한다
• 리포트 에이전트: 검증된 내용을 사람이 읽을 수 있는 형태로 정리한다

이렇게 나누면 각 에이전트의 실패도 더 잘 보인다. 자료가 부족했는지, 매핑이 틀렸는지, 가설이 과했는지, 검증이 약했는지, 리포트가 왜곡했는지 구분할 수 있다.

책임 경계는 디버깅 가능성을 만든다.

좋은 조직이 그렇듯, 좋은 에이전트 시스템은 "누가 잘못했는지"를 찾기 위해서가 아니라 "어디를 고쳐야 하는지"를 알기 위해 책임을 나눈다.

메인 에이전트는 팀장이 아니라 매니저다

에이전트 시스템에는 보통 메인 에이전트가 있다.

사용자의 요청을 받고, 어떤 서브에이전트를 호출할지 결정하고, 결과를 종합하고, 다음 단계를 판단한다. 1편에서는 이것을 오케스트레이터라고 불렀다.

조직 비유로 보면 메인 에이전트는 팀장처럼 보인다.

하지만 나는 팀장보다 매니저에 가깝다고 생각한다.

팀장은 때로 직접 실무를 한다. 급하면 코드를 치고, 문서를 쓰고, 고객 대응도 한다. 하지만 좋은 매니저의 핵심 역할은 직접 일을 많이 하는 것이 아니다. 목표를 정렬하고, 일을 나누고, 우선순위를 정하고, 결과를 검증하고, 다음 시스템 개선으로 연결하는 것이다.

메인 에이전트도 마찬가지다.

메인 에이전트가 직접 모든 것을 해결하려고 하면 다시 handleEverything()이 된다. 메인 에이전트의 역할은 직접 답을 내는 것이 아니라, 어떤 책임 단위에 어떤 입력을 넘길지 판단하고, 나온 결과가 전체 목표에 정렬되는지 확인하는 것이다.

내 시스템에서도 이 지점이 중요했다. 모든 일을 하나의 에이전트에게 맡기면 속도는 빨라 보인다. 하지만 기획, 구현, 리뷰, PR 관리가 한 덩어리로 섞이면 실패 원인을 찾기 어렵다. 기획이 틀렸는지, 구현이 틀렸는지, 리뷰가 약했는지, 애초에 이 일을 하면 안 됐는지 분리되지 않는다.

그래서 메인 에이전트의 일은 "직접 잘하기"보다 "넘기기 전에 멈춰서 판단하기"에 가까워졌다. 기획서가 오면 바로 구현으로 보내지 않고, 숫자와 제약과 기존 시스템과의 충돌을 본다. 실행 결과가 오면 "수정 완료"라는 문장만 보지 않고, 실제로 무엇이 바뀌었는지 확인한다. 매니저 에이전트의 핵심은 생산량이 아니라 판단 품질이다.

여기서 중요한 것은 라우팅이다.

잘못된 사람에게 일을 맡기면 조직의 결과가 망가지듯, 잘못된 에이전트에게 일을 맡기면 시스템의 결과가 망가진다. 리서치가 필요한 일을 요약 에이전트에게 넘기거나, 검증이 필요한 결론을 바로 리포트 에이전트에게 넘기면 결과는 그럴듯하지만 약해진다.

그래서 메인 에이전트의 품질은 곧 조직 운영의 품질이다.

서브에이전트가 아무리 좋아도, 매니저가 일을 잘못 배분하면 전체 시스템은 흔들린다.

성과 측정 없는 자율은 방임이다

자율적인 조직을 만들고 싶다는 말은 매력적이다.

에이전트 시스템에서도 마찬가지다. 사람이 매번 지시하지 않아도, 에이전트가 스스로 필요한 일을 찾고, 실행하고, 개선까지 해주면 좋다. 명령 기반 자동화를 넘어 스케줄러 기반 자율화, 나아가 이벤트 기반 자율화로 가고 싶은 마음은 자연스럽다.

하지만 성과 측정 없는 자율은 방임이다.

에이전트가 뭔가를 열심히 하고 있다는 사실은 중요하지 않다. 그 행동이 시스템의 목표에 가까워지고 있는지가 중요하다.

시장 분석 시스템이라면 더 그렇다. 리포트를 많이 만든다고 좋은 것이 아니다. 종목을 많이 발굴한다고 좋은 것도 아니다. 중요한 것은 그 발굴이 실제 알파로 이어졌는지, thesis가 성과를 설명했는지, 잘못된 판단을 얼마나 빨리 폐기했는지다.

이 지점에서 "바쁜 에이전트"는 오히려 위험하다. 매일 많은 이슈를 만들고, 많은 리포트를 쓰고, 많은 개선 제안을 내도, 그것이 알파 생성이라는 골과 연결되지 않으면 노이즈가 된다. 자동화된 시스템은 사람보다 더 빠르게 노이즈를 쌓을 수 있다.

그래서 운영 시스템에는 매일의 브리핑이 필요했다. 지금 병목이 무엇인지, 어떤 컴포넌트가 건강한지, 어떤 이슈가 골과 가장 가까운지. 에이전트가 스스로 움직이게 하려면, 먼저 시스템이 무엇을 중요하게 볼지 계속 갱신해야 한다.

에이전트별로 평가 기준이 있어야 한다.

• 리서치 에이전트: 중요한 자료를 빠뜨리지 않았는가
• 매핑 에이전트: 문서를 올바른 엔티티와 연결했는가
• thesis 에이전트: 검증 가능한 가설을 만들었는가
• 검증 에이전트: 반대 근거를 충분히 찾았는가
• 리포트 에이전트: 결론과 근거를 왜곡 없이 전달했는가
• 매니저 에이전트: 올바른 순서와 책임 단위로 일을 배분했는가

이 기준이 없으면 에이전트의 자율성은 성과가 아니라 활동량으로 측정된다.

활동량은 쉽게 늘릴 수 있다. 더 많이 검색하고, 더 긴 보고서를 쓰고, 더 많은 제안을 만들면 된다. 하지만 활동량이 늘어나는 것과 시스템이 좋아지는 것은 다르다.

좋은 조직은 바쁜 조직이 아니다.

목표에 정렬된 피드백 루프를 가진 조직이다.

실패한 에이전트를 어떻게 다룰 것인가

에이전트는 실패한다.

자료를 놓친다. 잘못된 도구를 호출한다. 근거보다 결론을 앞세운다. 너무 보수적으로 판단해서 기회를 놓치거나, 너무 공격적으로 판단해서 노이즈를 키운다. 평가 에이전트도 실패한다. 좋은 결과를 막거나, 나쁜 결과를 통과시킨다.

중요한 것은 실패 자체가 아니다.

실패가 시스템 안에서 어떻게 처리되는가다.

실패한 에이전트의 출력을 그냥 버리는 것은 가장 단순한 방법이다. 하지만 그것만으로는 시스템이 나아지지 않는다. 왜 실패했는지 기록해야 한다. 입력이 문제였는지, 프롬프트가 문제였는지, 권한이 부족했는지, 데이터가 낡았는지, 평가 기준이 부정확했는지 구분해야 한다.

사람 조직에서는 회고가 이 역할을 한다.

에이전트 시스템에서는 로그, 평가 결과, 반려 사유, 재시도 기록, 사람의 피드백이 이 역할을 한다. 실패를 데이터로 남기지 않으면 같은 실패가 반복된다.

여기서 중요한 것은 "에이전트가 반성하게 만들자"가 아니다.

시스템이 반성할 수 있게 만들자는 것이다.

에이전트 하나의 프롬프트를 고치는 것보다, 실패가 기록되고 다음 라우팅과 권한과 평가 기준에 반영되는 구조를 만드는 것이 더 중요하다.

예를 들어 어떤 기획서가 너무 많은 조건을 달고 왔다면, 단순히 "조건을 줄여라"라고 다시 시키는 것으로 끝나면 안 된다. 왜 그런 조건이 생겼는지 봐야 한다. 골이 모호했는지, 기존 시스템에 대한 정보가 부족했는지, 에이전트가 안전해 보이는 제약을 과하게 추가했는지. 그래야 다음 기획에서 같은 종류의 부채를 줄일 수 있다.

리뷰도 마찬가지다. "N건 수정 완료"라는 보고는 시작점일 뿐이다. 어떤 이슈가 실제로 수정됐는지, CRITICAL이나 HIGH로 분류된 문제가 정말 사라졌는지, 수정이 새로운 문제를 만들지는 않았는지 확인해야 한다. 에이전트의 보고는 결과가 아니라 검증할 대상이다.

에이전트의 승격과 해고

조직에는 승격과 해고가 있다.

에이전트 시스템에도 비슷한 개념이 필요하다. 물론 사람처럼 대우하자는 뜻이 아니다. 특정 에이전트에게 더 넓은 권한을 줄지, 더 좁은 책임으로 제한할지, 아예 제거할지를 판단해야 한다는 뜻이다.

예를 들어 어떤 검증 에이전트가 반복적으로 좋은 판단을 한다고 하자. 반대 근거를 잘 찾고, 나쁜 thesis를 잘 걸러내고, 통과시킨 결과의 사후 성과도 좋다. 그러면 이 에이전트의 권한을 넓힐 수 있다. 더 중요한 단계에 배치하거나, 더 많은 케이스에서 자동 통과를 허용할 수 있다.

반대로 어떤 에이전트가 반복적으로 실패한다면 선택지는 세 가지다.

첫 번째, 프롬프트를 고친다.

두 번째, 권한을 줄인다.

세 번째, 제거한다.

문제는 대부분의 에이전트 시스템이 첫 번째에만 머문다는 것이다. 결과가 안 좋으면 프롬프트를 더 길게 만든다. 규칙을 추가하고, 예외를 추가하고, "절대 하지 마라"를 붙인다. 그러다 보면 에이전트는 점점 무거워지고, 역할은 더 모호해진다.

조직 관점에서는 다른 선택도 가능하다.

이 역할이 정말 필요한가. 이 책임은 다른 에이전트와 합쳐야 하는가. 반대로 더 작게 쪼개야 하는가. 이 에이전트에게 판단 권한을 주는 것이 맞는가, 아니면 자료 수집까지만 맡겨야 하는가.

에이전트의 개선은 프롬프트 수정만이 아니다.

조직 재설계이기도 하다.

조직도는 코드보다 먼저 썩는다

조직도는 정적 문서처럼 보인다.

하지만 실제 조직은 계속 변한다. 사람이 들어오고 나가고, 제품 방향이 바뀌고, 병목이 이동하고, 기존 역할이 더 이상 맞지 않게 된다. 조직도를 갱신하지 않으면 문서는 현실을 설명하지 못한다.

에이전트 시스템도 그렇다.

처음에는 리서치, 분석, 요약, 리뷰 정도로 충분할 수 있다. 하지만 시스템이 커지면 새로운 역할이 생긴다. 데이터 신선도를 보는 에이전트, 출처 품질을 평가하는 에이전트, 과거 판단과 성과를 연결하는 에이전트, 비용을 감시하는 에이전트, 권한 위반을 막는 에이전트.

나도 처음부터 조직도를 그리고 시작한 것은 아니었다. 처음에는 그냥 일을 잘게 나누면 된다고 생각했다. 그런데 시간이 지나면서 역할이 생겼다. 미션 시작 전에 골 정렬을 보는 역할, PR을 만들기 전에 리뷰와 라이프사이클을 관리하는 역할, 매일 시스템의 병목을 요약하는 역할. 필요가 먼저 생기고, 그 다음에 조직도가 생겼다.

반대로 사라져야 하는 역할도 생긴다.

초기에는 필요했던 수동 검증 에이전트가, 스키마와 평가 기준이 안정되면 일부 단계에서 불필요해질 수 있다. 모델이 강해지면 촘촘했던 하네스를 줄이고 펜스 중심으로 옮길 수 있다. 데이터 레이어가 좋아지면 검색 에이전트의 역할도 바뀐다.

조직도는 코드보다 먼저 썩는다.

왜냐하면 시스템의 병목은 계속 이동하기 때문이다. 처음에는 모델의 성능이 병목이고, 그다음에는 데이터가 병목이고, 그다음에는 라우팅이 병목이고, 그다음에는 평가 기준이 병목일 수 있다. 병목이 바뀌면 조직도도 바뀌어야 한다.

에이전트 시스템을 운영한다는 것은 이 변화를 계속 감지하는 일이다.

결국 운영의 문제

프롬프트 엔지니어링은 에이전트에게 무엇을 시킬지의 문제다.

하네스 엔지니어링은 에이전트들을 어떻게 구조화할지의 문제다.

펜스 엔지니어링은 에이전트가 어디까지 움직일 수 있는지의 문제다.

그라운딩 엔지니어링은 에이전트가 무엇을 보고 판단할지의 문제다.

그리고 오퍼레이션 엔지니어링은, 이 모든 것이 시간이 지나도 목표에 정렬되어 움직이게 만드는 문제다.

좋은 에이전트 시스템은 좋은 프롬프트의 집합이 아니다.

책임과 권한과 피드백 루프가 정렬된 조직이다.

각 에이전트는 명확한 책임을 가져야 하고, 메인 에이전트는 일을 적절히 배분해야 하고, 실패는 기록되어야 하고, 성과는 측정되어야 하고, 역할은 계속 바뀔 수 있어야 한다.

이것은 AI만의 새로운 문제가 아니다.

좋은 소프트웨어 조직을 만드는 감각과 닮아 있다. 책임 경계를 나누고, 인터페이스를 설계하고, 로그를 남기고, 병목을 찾고, 권한을 조정하고, 회고를 통해 시스템을 바꾸는 것.

에이전트가 많아질수록 중요한 것은 더 똑똑한 에이전트 하나가 아니다.

더 나은 조직 운영이다.

AI 오퍼레이션 엔지니어링.

에이전트를 사람처럼 대하는 기술이 아니라, 에이전트들이 하나의 조직처럼 목표에 정렬되어 움직이도록 운영하는 기술. 나는 그렇게 이해하고 있다.