LLM 멀티 에이전트 글쓰기, 품질을 떨어뜨린 건 요약 단계였다

AI 에이전트 여섯 개가 역할을 나눠 블로그 글을 쓰게 했는데, 결과물은 한 번의 호출로 쓰던 예전 글보다 확연히 나빴습니다. 테스트는 전부 통과했고 로컬에서 끝까지 한 번 돌려 본 기록도 있었습니다. 그런데 실제 화면에서 받아 본 초안은 사용자가 정성껏 적은 인터뷰 답변을 거의 살리지 못하고 있었습니다. 원인을 찾고 나서 놀랐습니다. 에이전트 개수도, 모델 성능도 아니고, 에이전트 사이에 끼워 둔 "요약" 한 단계였습니다. 이 글에서는 요약 단계가 어떻게 사용자 답변을 조용히 버렸는지, 그리고 모든 에이전트가 원문을 직접 읽도록 바꾸기까지의 과정을 정리합니다.

 

이 글에서 다루는 내용
· 테스트를 모두 통과한 파이프라인이 더 나쁜 글을 만든 상황
· 품질 저하의 진짜 원인이었던 요약 단계의 정보 손실
· 중간 요약을 걷어 내고 원문 직결형 4단계로 바꾼 최종 구조

 

에이전트를 나눴더니 글이 오히려 나빠졌습니다

제가 만들고 있는 알레오(ALLEO)는 홈페이지의 AI 검색 노출을 진단하고, 사장님의 경험을 블로그와 SNS 콘텐츠로 쌓아 주는 마케팅 자동화 서비스입니다. 이렇게 쌓은 글은 알레오 블로그에서 브랜드 블로그로 운영할 수 있습니다. 알레오에는 사용자가 인터뷰 질문에 답하면 AI가 블로그 초안을 써 주는 기능이 있습니다. 원래는 모델을 한 번 호출해 초안을 썼는데, 글의 완성도를 높이려고 역할을 나눈 여러 에이전트가 차례로 글을 다듬는 구조로 바꿨습니다. 순서와 재시도는 LLM이 아니라 애플리케이션 코드가 정하게 했습니다.

 

첫 구현은 일곱 단계였습니다. 사용자 답변을 정리해 글의 방향과 근거를 잡는 Brief, 공개 자료 리서치, 작가, 마케터, SEO 검수, 내용 검수, 그리고 필요할 때만 도는 부분 수정입니다.

 

그런데 실제 화면에서 받아 본 초안은 기존 단일 호출 방식보다 확연히 품질이 낮았습니다. 그때 작업 기록에 남긴 문장이 있습니다. 테스트·빌드 통과와 한 번의 로컬 완주는 초안 품질을 통과시킨 증거가 아니다.

 

범인은 에이전트 수가 아니라 요약 단계였습니다

기존 코드에 수정을 더 얹지 않고, 코드를 읽기만 하는 조사부터 했습니다. 사용자 답변이 각 단계에 어떤 모양으로 전달되는지 따라가 보니, 원인은 파이프라인의 맨 앞에 있었습니다.

 

Brief 단계는 사용자의 인터뷰 답변을 "근거가 연결된 사실 목록"으로 정리해 다음 단계에 넘겼습니다. 그런데 정리 규칙이 엄격했습니다. 한 사실에 붙은 근거 참조 중 하나라도 형식이 맞지 않으면, 그 사실을 통째로 버렸습니다. 사용자 고유의 말투나 고유명사도 같은 방식으로 걸러졌습니다.

 

더 큰 문제는 그다음입니다. 작가 에이전트는 Brief가 정리한 목록과 리서치 결과만 받았고, 사용자의 원래 질문과 답변은 받지 못했습니다. Brief에서 사라진 정보를 작가가 되살릴 방법이 없었던 것입니다. 그리고 이 손실은 오류가 아니라 정상 결과로 다음 단계에 넘어갔습니다. 아무 경고 없이, 조금 더 빈약한 글이 만들어졌을 뿐입니다.

 

단계	받는 입력	사라지는 것
Brief	사용자 답변 원문	근거 형식이 어긋난 사실, 말투, 고유명사
작가	Brief 결과 + 리서치 결과	원문에 접근할 수 없어 복구 불가
이후 단계	작가 초안	이미 빠진 정보는 아무도 모름

 

모든 에이전트가 원문을 직접 읽게 바꿨습니다

먼저 작가가 사용자 답변 원문을 직접 받도록 고쳤습니다. 하지만 Brief가 만든 사실 목록과 그 ID를 단계마다 주고받는 방식은 남아 있었고, 실제 화면에서 직접 써 보며 확인을 반복하자 비슷한 증상이 다시 나타났습니다. 글이 짧아졌고, 외부 자료 인용이 빠졌고, 글 끝의 안내 문구도 사라졌습니다.

 

원인을 다시 따라가 보니 같은 종류의 문제였습니다. 경력 정보는 Brief의 사실 목록이 되고, 목록의 ID가 작가에게, 작가가 쓴 ID가 검수자에게, 검수 결과가 편집자에게 넘어갔습니다. 변환을 한 번 거칠 때마다 원래 의미나 ID가 조금씩 어긋났고, 시스템은 글의 품질보다 내부 ID가 맞는지를 먼저 따지고 있었습니다.

 

그래서 중간 요약과 파생 ID를 모두 걷어 내고, 네 에이전트가 같은 원문을 직접 읽는 구조로 바꿨습니다.

 

인터뷰 질문·답변 원문 + 선택한 경력 원문
  → Writer      : 원문으로 1차 초안 작성, 외부 검증이 필요한 주장만 표시
  → Researcher  : 표시된 주장만 공개 자료로 검증 (지지 / 일부 지지 / 반박 / 근거 없음)
  → Marketer    : 제목·흐름·안내 문구 개선 (사실·출처는 건드리지 않음)
  → Final Editor: 내용·출처·SEO·구조를 검토하고 직접 고쳐 최종본 완성

눈여겨볼 변화는 두 가지입니다. 첫째, 리서치를 작가 뒤로 옮겼습니다. 먼저 넓게 조사하고 글을 쓰는 대신, 작가가 "이 주장은 외부 근거가 필요하다"고 표시한 것만 검증합니다. 조사 범위를 글에 실제로 쓰인 주장으로 좁혀 불필요한 선행 검색을 줄이려는 설계이고, 사용자의 개인 경험은 인터넷에서 다시 검증하거나 검색어로 노출하지 않도록 막았습니다. 둘째, 검수자와 편집자를 하나로 합쳤습니다. 검수 의견을 다른 에이전트에게 전달하는 대신, 최종 편집자가 원문과 모든 중간 결과를 함께 보고 직접 고칩니다. 근거가 없어 고칠 수 없는 것만 경고로 남깁니다.

 

구분	첫 구현	최종
단계	6역할 + 부분 수정	4역할
중간 요약	Brief의 사실 목록과 ID를 주고받음	없음
사용자 답변 원문을 받는 단계	Brief만	네 단계 모두
초안당 호출	정상 7~8회, 상한 14회	4회

 

모델도 역할에 맞게 나눴습니다. 글의 질을 좌우하는 작가와 최종 편집자만 상위 모델을 쓰고, 리서치와 마케터는 저렴한 모델로 바꿨습니다. 이 구조로 테스트용 계정에서 운영 품질을 직접 확인한 뒤 모든 사용자에게 열었습니다. 기존 실행과의 호환을 위해 이전 단계의 코드와 스키마는 지우지 않고 남겨 두었습니다.

 

마치며

멀티 에이전트 글쓰기의 품질을 떨어뜨린 것은 에이전트의 수가 아니라, 에이전트 사이에서 정보를 줄여 전달하는 단계였습니다. 요약과 파생 ID는 시스템을 정돈된 것처럼 보이게 했지만, 변환을 거칠 때마다 사용자가 준 원문의 구체성이 조용히 빠져나갔습니다. 결국 중간 요약을 없애고 모두가 원문을 직접 읽게 하자 호출 수도 줄고 구조도 단순해졌습니다.

 

• 단계 사이에 요약이나 정규화를 넣었다면, 그 단계가 무엇을 버리는지와 버린 것이 오류 없이 넘어가지 않는지부터 확인해 보세요.
• 결과물의 질을 좌우하는 단계에는 원문을 직접 넘기세요. 앞 단계의 요약만으로는 잃은 정보를 되살릴 수 없습니다.
• 자동 테스트와 별개로, 실제 화면에서 끝까지 써 보는 검증을 구현 초반에 넣으세요. 품질 문제는 대개 그때 처음 보입니다.

 

에이전트를 하나 더 붙이고 싶어진다면, 그 전에 지금 있는 에이전트들이 원문을 읽고 있는지부터 확인해 보시기 바랍니다.

 

이 글의 4단계 구조는 알레오의 블로그 초안 작성 기능에 적용되어 있습니다. 인터뷰 질문 몇 개에 답하면 내 경험이 담긴 초안이 어떻게 나오는지 직접 써 보실 수 있고, 그렇게 만든 글이 운영되는 모습은 알레오 블로그에서 보실 수 있습니다.

알레오 | SEO와 AI 검색에 강한 블로그 자산 자동화 서비스

알레오 블로그 | AI 검색 시대를 위한 브랜드 블로그 허브