AI 에이전트 시스템 설계: 멀티 에이전트 PR 리뷰어를 프로덕션급으로 만드는 설계 원칙

핵심 메시지

• 목표는 코드 리뷰 자동화가 아니라 시니어 리뷰어의 주의력을 되찾는 것이며, 그래서 설계의 첫 원칙은 '많이 말하기'가 아니라 '선별해서 말하기'다.
• 설계는 기술이 아니라 사람에서 출발한다. 시니어 리뷰어가 PR을 읽을 때 실제로 하는 미세한 행동을 전부 적어 내려간 뒤 그것을 부품으로 옮긴다.
• 보안·품질·테스트·문서라는 네 가지 관점은 임의로 정한 것이 아니라 사람 리뷰어의 서로 다른 사고방식에서 그대로 따온 것이고, 그래서 병렬 전문가 에이전트 구조가 된다.
• 모든 지적에는 근거와 확신도가 붙어야 하며, 확신도가 기준 아래면 자동으로 사람에게 넘긴다.
• 각 부품마다 '무엇이 잘못될 수 있는가'를 엔지니어링 측면과 모델 측면 양쪽에서 먼저 묻고, 그 답이 그 부품의 설계가 된다.

쉽게 이해하기

발표자는 강의를 시작하자마자 흔한 접근법을 스스로 부정한다. 코드 변경분을 떼어내 모델에 던지고 '이 코드의 문제를 알려줘'라고 시키는 방식, 거기에 저장소 일부를 검색해 붙이는 방식은 이미 수백 개의 튜토리얼이 하고 있고 그것을 프로덕션이라 부를 수는 없다는 것이다. 대신 그는 오늘 스무 개의 PR을 처리해야 하는 실제 시니어 리뷰어에서 출발하자고 제안한다. 첫 번째 PR의 리뷰 품질과 스무 번째 PR의 리뷰 품질이 같지 않다는 사실, 그 격차의 원인이 피로와 일관성 부족이라는 사실이 설계의 출발점이다.

여기서 문제의 정의가 한 번 바뀐다. 풀어야 할 것은 '리뷰를 자동으로 해주는 에이전트'가 아니라 '기계적인 부분을 걷어내 사람의 판단이 정말 필요한 곳에만 쓰이게 만드는 에이전트'다. 발표자는 이 차이를 계속 강조하며, 시스템이 최적화해야 할 값은 출력량이 아니라 선별성이라고 못박는다. 확신이 높은 고가치 지적만 자동으로 남기고 애매한 것은 사람에게 올린다는 이 한 문장이 이후 모든 구조를 끌고 간다.

사람 리뷰어의 행동을 분해하면 네 가지가 나온다. 저장소의 맥락을 끌어오고, 서로 다른 관심사로 나눠 판단하고, 회의적인 태도를 유지하고, 판단마다 근거를 댄다. 이것을 엔지니어링 언어로 옮기면 각각 검색 계층, 병렬 전문가 에이전트, 확신도, 근거 기록이 된다. 보안·품질·테스트·문서 에이전트를 병렬로 펼친 뒤 하나의 집계기가 결과를 합치고 중복을 제거해 전체 확신도를 계산하는 팬아웃·팬인 패턴이 이렇게 도출된다.

부품이 정해지면 각각에 대해 '무엇이 잘못될 수 있는가'를 두 방향에서 묻는다. 엔지니어링 방향으로는 같은 웹훅이 재전송되거나, 위조된 요청이 들어오거나, 응답 시한 안에 답하지 못하는 상황이 있다. 모델 방향으로는 환각, 잘못된 맥락 검색, 병렬 에이전트가 응답하지 않아 집계기가 영원히 기다리는 교착이 있다. 발표자는 각 실패에 대응하는 방어를 하나씩 붙인다. 웹훅 서명 검증과 중복 방지 키, 빠른 수신 확인 후 큐 적재, 모든 노드의 타임아웃, 재시도와 회로 차단기, 확신도 기반의 사람 검토 관문이 그것이다.

발표자는 관측 가능성이 왜 필요한지도 같은 방식으로 유도한다. 에이전트가 '이 엔드포인트에 SQL 주입 취약점이 있다, 확신도 60%'라고 올렸는데 개발자가 이를 반박한다고 하자. 어떤 맥락이 검색됐고 어떤 프롬프트 버전이 돌았고 모델이 무엇을 반환했는지 기록이 없다면 그 지적은 방어할 수도, 디버깅할 수도, 개선할 수도 없다. 그래서 모든 호출과 결정은 시간순 이벤트로 남고, 이 하나의 기록이 추적 뷰어와 감사 기록과 비용 대시보드를 동시에 떠받친다.

주요 인사이트

• '어떤 에이전트를 만들까'가 아니라 '이 시스템이 없으면 지금 무슨 일이 일어나는가'에서 시작하면 설계가 저절로 따라온다는 것이 강의를 관통하는 방법론이다. 문제를 제거해봐야 진짜 통증이 보인다.
• 자율성의 정도는 기본값이 아니라 선택이다. 발표자는 오류의 결과가 크거나 되돌리기 어려운 영역일수록 사람의 개입을 처음에는 넉넉히 두고, 시스템이 스스로를 증명해가며 줄여야 한다고 말한다.
• 자신이 겪은 실패담이 설득력을 더한다. 링크드인에서 잠재 고객과 대화하던 에이전트가 아홉 시간 만에 실제 저녁 약속을 잡아버렸고, 최소 이삼 일은 걸릴 것이라는 가정이 무너지면서 시스템 전체가 무너졌다. 시스템이 실패한 것이 아니라 가정이 실패한 것이라는 정리가 인상적이다.
• 프레임워크 선택은 큰 문제가 아니지만 프레임워크에 종속되는 설계는 문제다. 워크플로 엔진을 추상 인터페이스로 감싸두면 나중에 다른 오케스트레이터로 옮길 때 구현 클래스 하나만 추가하면 된다.
• 피드백 루프도 오염될 수 있다. 경험이 적은 리뷰어의 나쁜 피드백이 그대로 학습되는 것을 막기 위해, 피드백을 반영하기 전에 최소한의 증거 기준을 두고 오래된 피드백은 감쇠시킨다.

자주 묻는 질문

관련 AI 소식