“한 번에 다 해주는 AI”는 왜 실무에서 자꾸 무너질까? ― Wissly의 에이전트 구조 설계

“한 번에 다 해주는 AI”는 왜 실무에서 자꾸 무너질까?

문서 기반 업무에 AI를 붙일 때 가장 자연스럽게 떠오르는 설계는 이것입니다.

“검색도 하고, 이해도 하고, 글도 쓰는 ‘만능 에이전트’ 하나면 되지 않을까?”

실제로 데모 환경에서는 꽤 그럴듯하게 동작합니다.

하지만 운영 환경으로 들어가면, 동일한 구조가 예상보다 빠르게 흔들리기 시작합니다.

• 어떤 날은 답변이 정확한데, 어떤 날은 근거가 빈약해지고

• 어떤 날은 초안이 읽기 좋은데, 어떤 날은 구조가 무너지며

• 요청이 조금만 복합해져도 “업무가 끝까지 이어지지 않는” 상황이 발생합니다

Wissly 팀이 겪은 문제도 본질적으로 같았습니다.

“답변”은 생성할 수 있었지만, “업무”는 완주하기 어려웠습니다.

실무에서 실제로 벌어지는 요청의 형태

예를 들어, 다음과 같은 요청은 “검색”이나 “요약”만으로는 끝나지 않습니다.

“경쟁사 A가 이번 분기에 뭘 했는지 정리해서 임원 보고용 한 페이지 초안으로 써주세요.

내부에 있는 지난 분기 전략 문서도 참고하고, 숫자는 가능하면 출처가 보이게 해주세요.

톤은 너무 마케팅처럼 쓰지 말고, 리스크도 같이 적어주세요.”

이 요청에는 눈에 띄는 특성이 있습니다.

• 정보 소스가 복합적입니다. (내부 문서 + 외부 웹 + 상식)

• 산출물 형태가 명확합니다. (“임원 보고용 1페이지 초안”)

• 작성 규칙이 포함됩니다. (톤, 리스크 포함, 숫자 출처)

• 그리고 무엇보다 중간에 사용자 피드백이 들어올 가능성이 매우 큽니다.

  (“B 항목이 약해요”, “기간을 6개월로 늘려주세요”)

즉, 이건 단순 응답이 아니라 “작업 흐름”입니다.

운영 환경에서 반복되던 실패 패턴

1) 검색과 작성이 섞이면, 실패 원인을 분리할 수 없다

초기에는 “검색 → 답변”이 한 덩어리였습니다.

그런데 결과가 나쁠 때마다 동일한 질문이 남습니다.

• 검색이 잘못된 것인가?

• 검색은 맞았는데, 작성이 망가진 것인가?

• 컨텍스트가 과적재되어 모델이 중요한 부분을 놓친 것인가?

원인을 분리하지 못하면, 개선도 어렵습니다.

현상만 보고 프롬프트를 조금씩 만지다 보면 품질이 오히려 더 요동치게 됩니다.

2) 업무 요청은 보통 “한 문장”이 아니라 “작업 흐름”이다

실제 사용자의 요청은 대개 다음과 같은 형태로 발전합니다.

• “최근 3개월만 보고 정리해줘”

• “내부 문서 먼저 참고해줘”

• “경쟁사 A, B, C를 같은 포맷으로 비교해줘”

• “초안은 임원 보고용 톤으로 바꿔줘”

즉, 사용자는 답변을 원한다기보다 업무가 진행되는 과정을 원합니다.

이때 단일 에이전트 방식은 두 가지를 동시에 해야 합니다.

• 정보를 찾고(탐색)

• 결과물을 만들고(작성)

• 그 사이의 작업 흐름을 통제하고(계획·반복·수정 반영)

이 “세 가지 역할의 충돌”이 운영 품질을 흔드는 핵심 원인이었습니다.

3) 도구가 늘어날수록, 시스템의 중심이 흔들리기 시작한다

웹 검색, 내부 지식베이스, LLM의 일반 지식 등

실제 서비스 환경에서는 사용할 수밖에 없는 정보 소스가 점점 늘어납니다.

문제는 이 도구들이 아니라,

중앙 로직이 이 도구들의 세부 구현을 알기 시작할 때 발생합니다.

• 특정 검색 방식에 의존하게 되고

• 도구가 바뀌면 전체 흐름을 수정해야 하고

• 유지보수 비용이 급격히 증가합니다

운영 가능한 시스템이 되기 위해서는

중앙이 “무엇을 할 것인가”에만 집중하고,

“어떻게 할 것인가”는 각 역할에게 위임되어야 했습니다.

Wissly의 선택: “기능”이 아니라 “팀”으로 설계하기

Wissly는 문제를 기능 추가로 풀지 않고, 설계 관점을 완전히 새롭게 바꿨습니다.

AI 에이전트는 기능이 아니라 인력(채용) 관점에서 설계해야 한다

즉, 하나의 만능 에이전트가 아니라

역할과 책임이 분리된 “최소한의 팀”을 만들기로 했습니다.

• Chief Orchestrator: PM처럼 작업을 분해하고 위임하며, 흐름을 끝까지 끌고 간다

• Search Agent: 내부/외부를 오가며 근거를 수집하고, 필요하면 범위를 되묻는다

• Drafting Agent: 근거를 기반으로 사람이 검토 가능한 초안 내용을 작성한다

이 구조의 핵심은 “분산”이 아니라 “분리”에 있습니다.

검색, 작성, 흐름 제어를 나눔으로써

문제가 생겼을 때 원인을 빠르게 특정하고

해당 단계만 독립적으로 개선할 수 있도록 설계했습니다.

현재 Wissly가 운영 중인 구조

아래는 현재 제품에서 사용 중인 Orchestrator + Search + Drafting 흐름입니다.

위슬리에서 특히 신경 쓴 기술적 포인트

1) Orchestrator의 “Tool Blindness”: 중앙은 도구를 몰라야 한다

Orchestrator는 도구를 직접 호출하지 않습니다.

오케스트레이터가 아는 것은 다음뿐입니다.

• 어떤 에이전트가 어떤 책임을 갖는지

• 지금 단계에서 필요한 산출물이 무엇인지

• 다음 단계로 넘어가기 위해 무엇이 충족되어야 하는지

도구 호출 디테일을 Search Agent 내부로 숨기면, 구조가 단단해집니다.

• 웹 검색 방식이 바뀌어도 전체 플로우는 유지되고

• 내부 지식베이스 스키마가 바뀌어도 중앙 로직은 흔들리지 않으며

• 제품은 “기능 추가” 대신 “팀원의 역량 개선”처럼 진화할 수 있습니다

운영 환경에서 더 중요했던 것은 새로운 기능을 빠르게 추가하는 것보다,

변화가 생겨도 구조가 쉽게 흔들리지 않는 것이었습니다.

2) Context Distillation: “많이 주기”가 아니라 “필요한 만큼만 주기”

LLM 기반 시스템에서 흔한 착각은 다음입니다.

“검색 결과를 많이 주면 초안이 더 좋아질 것이다”

그러나 운영 환경에서는, 입력이 많아질수록

초안의 품질이 오히려 흔들리는 경우를 더 자주 마주합니다.

Wissly는 이 문제를 “검색 품질”이 아니라

검색 결과를 Drafting에 전달하는 방식에서 찾았습니다.

그래서 Search Agent의 최종 출력은 원문 덩어리가 아니라

초안 작성에 최적화된 형태로 증류된 브리프(Brief) 입니다.

• 이번 요청의 범위(기간, 대상, 관점)

• 핵심 근거 요약(중복 제거)

• 출처 메타(내부/외부, 문서/웹, 작성 시점)

• 상충 가능성이 있는 포인트(작성 시 주의)

이 방식은 Drafting Agent가 핵심 정보에만 집중하도록 돕고,

초안의 구조와 완성도를 보다 안정적으로 유지하게 합니다.

3) Search Agent의 핵심은 “검색”이 아니라 “정보 전략”이다

Search Agent는 단순히 문서를 찾아 나열하는 역할이 아닙니다.

실제 운영에서 중요한 것은 다음과 같은 판단입니다.

• 이 질문은 내부 정보가 우선인가, 외부 최신 정보가 우선인가?

• 최신성이 필요한가?

• 문서의 종류(정책/가이드/보고서/블로그)에 따라 신뢰도를 어떻게 볼 것인가?

• 범위가 모호하면 어떤 질문으로 좁힐 것인가?

특히 “되묻기”는 검색 성능만큼 중요합니다.

질문이 모호한 상태에서 검색을 시작하면 검색 결과는 많아져도 산출물은 오히려 흐려집니다.

그래서 Search Agent는 “검색을 시작하기 전” 업무 범위를 확정하기 위한 최소한의 질문을 수행하도록 설계했습니다.

적용 이후 달라진 점

이 구조를 적용한 이후, Wissly가 체감한 가장 큰 변화는

“데모가 더 그럴듯해졌다”가 아니라,

실제 업무 흐름이 안정되기 시작했다는 점이었습니다.

• 복합 요청에서도 작업이 단계적으로 진행되며

• 검색 결과가 초안 작성으로 자연스럽게 이어지고

• 초안의 품질이 “좋았다/나빴다”가 아니라 “일관되게” 유지되며

• 사용자 피드백 역시 “틀렸다”기보다는 “이 부분을 조금 더 보강해달라”는 방향으로 바뀌었습니다

‘한 번의 답변’이 아니라 업무가 지속적으로 진행될 수 있는 구조가 만들어졌습니다.

다음 단계: 에이전트가 더 합류합니다

지금까지는 “업무를 끝까지 굴리는 최소 팀”을 만드는 데 집중했습니다.

하지만 실제 조직이 그렇듯, 팀이 안정적으로 돌아가기 시작하면

다음은 자연스럽게 확장됩니다.

다음 업데이트에서는 Wissly의 “오피스 스쿼드”에

새로운 역할의 에이전트가 합류할 예정입니다.

• 지금보다 더 많은 업무 유형을 다루기 위해

• 초안 이후 단계까지 이어지는 흐름을 더 단단히 만들기 위해

• 그리고 “사람이 마지막으로 확인하면 되는” 수준으로 신뢰도를 끌어올리기 위해

현재의 에이전트 구조 위에,

몇 명의 팀원이 더 합류할 준비를 하고 있습니다.

(구체적인 역할과 방식은… 다음 글에서 공개하겠습니다.)

마치며

문서 기반 업무 자동화에서 핵심은

“한 번에 완벽한 답을 내는 것”이 아니라,

업무가 끝까지 이어질 수 있는 구조를 만드는 것입니다.

Wissly는 만능 에이전트 하나를 고도화하는 방식 대신, PM·리서처·라이터로 역할을 나누고 도구 변화에도 쉽게 흔들리지 않는 구조를 선택했습니다.

그리고 그 구조가 안정화된 지금, 다음 팀원들을 맞이할 준비를 하고 있습니다.