이견을 보존하는 아키텍처
몇몇 조직에서 각 분야 전문가들이 모인 자리를 지켜본 적이 있다. 기대와 달리 그 모임은 두 가지 방식 중 하나로 무너졌다. 하나는 충돌이 무서워 아무도 먼저 부딪히지 않는 경우였다. 다른 하나는 권한을 쥔 한 사람이 타인의 전문 영역까지 미시적으로 결정해버리는 경우였다. 두 경우 모두 겉으로는 평온해 보였다. 회의는 순조롭게 끝났고, 결정은 신속하게 내려졌다. 문제는 그 평온함이 실제로는 이견이 사라진 자리에서 나온 침묵이었다는 데 있었다.
전문가를 모으는 행위는 지식을 모으는 일처럼 보이지만, 실제로는 서로 다른 취향과 판단 기준과 문제를 보는 방식을 한자리에 모으는 일이다. 서로 다른 전문가들을 모으면 충돌은 필연적으로 발생한다. 그런데 그 충돌이 사라지는 순간 남는 것은 두 갈래뿐이다. 체면을 지키느라 봉합된 애매한 타협이거나, 권한이 센 사람의 판단이 다른 모든 판단을 대신 흡수해버리는 독단이다. 겉보기에는 정반대의 실패처럼 보이지만, 두 경우 모두 이견이 표출될 통로가 막혔다는 점에서는 같은 실패다.
리그 오브 레전드 프로 경기를 챙겨보던 시절, 인게임이든 아웃게임이든 사령관 없이는 팀이 굴러가지 않는다는 사실을 여러 번 확인했다. 하지만 사령관의 판단이 항상 옳았던 것도 아니었다. 흥미로운 지점은 전문성이 높은 팀일수록 최종 결정을 내리는 권한과 그 결정에 이의를 제기할 수 있는 권한을 별개의 것으로 다뤘다는 사실이다. 사령관의 판단은 결과가 나오기 전까지는 외부에서 이해하기 어려운 혼란처럼 보일 때가 많다. 관리자가 이 혼란을 서둘러 정리하려 개입하면 단기적으로는 안정되어 보이지만, 그 순간 팀이 가진 서로 다른 관점은 함께 사라진다. 결국 지휘권과 판단권을 동일시하지 않는 구조, 사령관이 존재하되 그 사령관도 틀릴 수 있다는 사실을 팀원들이 공개적으로 드러낼 수 있는 구조가 더 오래 버텼다.
이런 구조를 조직 안에 의도적으로 심어 둔 장치가 레드팀이다. 다만 레드팀을 신설한다고 자동으로 문제가 해결되지는 않는다. 평소에 반대 의견을 성가신 잡음으로 취급하고, 권한을 쥔 사람이 결론을 뒤집어버리는 관행이 남아 있다면 레드팀은 형식적인 절차로 전락한다. 핵심은 반대할 사람 한 명을 지정하는 데 있지 않다. 불일치를 시스템의 예외 상황이 아니라 정상적인 작동 과정으로 인정하는 데 있다.
에이전틱 코딩을 오래 하다 보면 이 관찰이 다른 자리에서도 반복된다는 사실을 알아채게 된다. 단일 모델로 코딩을 시킬 때 결과가 흔들리는 이유는 흔히 생각하듯 능력이 부족해서가 아니다. 진짜 문제는 하나의 판단 체계 안에서 생성과 비판과 우선순위 결정과 검증이 동시에 수행된다는 데 있다. 판단과 실행이 같은 루프 안에 물려 있으면, 실행에 유리한 방향으로 판단을 사후 합리화하기가 너무 쉬워진다. LLM은 특히 이 함정에 취약하다. 직전 출력을 전제로 다음 출력을 생성하는 구조 위에서는, 방금 세운 설계가 틀렸을 가능성을 독립적인 사건으로 취급하기가 어렵다.
그래서 여러 에이전트를 배치하는 일은 단순히 역할을 수평으로 쪼개는 작업이 아니라 서로 다른 판단 기준을 의도적으로 분리해 배치하는 작업에 가깝다. 설계자와 구현자와 검증자를 나누는 정도로는 부족하다. 중요한 것은 구현하지 않는 비판자에게 설계 자체를 뒤집을 수 있는 실질적인 권한을 쥐여 주는 일이다. 그래야 검증 단계가 형식적인 리뷰에 그치지 않고 시스템의 반대편 버스로 기능한다. 최종 결정권자는 여전히 존재해야 하지만, 반대 의견이 실제로 그 결정을 흔들 수 있는 통로가 함께 있어야 한다.
소프트웨어 아키텍처에서 느슨한 결합을 선호하는 이유도 다시 보면 단순히 유지보수 비용을 낮추기 위해서만은 아니다. 강하게 결합된 구조에서는 한 컴포넌트의 전제가 곧바로 다른 컴포넌트의 전제가 되어 버린다. 문제가 드러나도 시스템 전체가 그 잘못된 전제를 함께 끌어안고 합리화하기 쉬워진다. 반대로 느슨하게 결합된 구조에서는 각 부분이 서로 다른 가정과 판단 기준을 유지한 채 경계에서 부딪힐 수 있고, 그 마찰 지점에서 잘못된 가정이 드러난다. 결합도를 낮추는 설계가 지켜내는 것은 변경 가능성만이 아니다. 이견이 발생할 여지, 그리고 그 이견이 밖으로 드러날 통로 역시 함께 지켜낸다.
전문가 집단이든 게임 팀이든 에이전트 시스템이든 소프트웨어 아키텍처든, 실패는 대개 구성 요소의 능력 부족에서 오지 않는다. 서로 다른 판단이 부딪힐 자리를 남겨 두지 않았거나, 그 마찰이 감지되는 순간 서둘러 봉합해버린 데서 온다. 그렇다면 앞으로 설계해야 할 것은 얼마나 정교한 개별 판단자를 만들 것인가가 아니라, 그 판단자들 사이의 불일치가 조용히 증발하지 않도록 어떤 마찰의 자리를 남겨 둘 것인가일지도 모른다.