대부분의 개발자들은 프롬프트(prompt)를 감싸는 래퍼(wrapper)를 만드는 것으로 AI 여정을 시작합니다. 요청을 보내고, 응답을 받으며, 그것이 정확하기를 바랍니다. 이것은 선형적 워크플로우(linear workflow)입니다. 단순한 작업에는 효과적이지만, 고품질의 기술 문서나 SEO 중심의 콘텐츠를 제작하려고 할 때는 무너집니다.

제가 처음으로 우리 블로그의 기술 심층 분석(technical deep-dives)을 자동화하려고 했을 때, 저는 거대한 프롬프트를 사용했습니다. 저는 LLM에게 "전문 엔지니어가 되어 전문적인 어조를 사용하고 코드 예제를 포함하라"고 말했습니다. 결과는 일반적인 뻔한 내용(generic fluff)이었습니다. LLM이 단 한 번의 시도(one shot)로 정답을 추측하려고 했기 때문에 마치 마케팅 브로슈어처럼 보였습니다.

이를 해결하려면 프롬프트에서 에이전트 기반 워크플로우(agentic workflow)로 이동해야 합니다. 이는 단일 호출(single call)에서 계획(planning), 실행(executing), 비판(critiquing)의 루프(loop)로 이동하는 것을 의미합니다.

선형 프롬프트의 문제점

선형 프롬프트는 "환각 드리프트(hallucination drift)" 문제를 겪습니다. 만약 모델이 두 번째 문단에서 실수를 한다면, 내부적 일관성을 유지하기 위해 기사의 나머지 부분에서 그 실수를 정당화하는 데 시간을 허비할 것입니다. 모델은 앞으로만 나아가기 때문에 자신의 논리를 되돌아가서 수정할 수 없습니다.

전문적인 콘텐츠 운영에서 어떤 인간 작가도 이런 방식으로 일하지 않습니다. 당신은 2,000단어 분량의 기술 가이드를 한 번에 앉아서 쓰고 바로 발행하지 않습니다. 개요를 잡고, 조사하고, 초안을 작성하고, 검토하고, 편집합니다.

에이전트 루프(Agentic Loop) 설계하기

에이전트 기반 워크플로우는 작업을 전문화된 역할로 나눕니다. 하나의 프롬프트 대신, 서로 대화하는 작고 집중된 에이전트들의 파이프라인(pipeline)을 구축합니다.

1. 리서처 에이전트 (The Researcher Agent)

이 에이전트는 글을 쓰지 않습니다. 유일한 임무는 사실을 찾는 것입니다. 주제를 받아 요구 사항, API 참조, 실제 코드 스니펫(code snippets)의 구조화된 목록을 생성해야 합니다. 특정 라이브러리에 대해 작성하고 있다면, 이 에이전트는 LLM의 학습 데이터에 의존하는 대신 최신 문서를 가져와야 합니다.

2. 아키텍트 에이전트 (The Architect Agent)

이 에이전트는 조사된 내용을 바탕으로 뼈대를 구축합니다. H2 및 H3 태그를 정의하고, 코드 블록이 들어갈 위치를 결정합니다. 여기서의 목표는 구조적 무결성 (structural integrity)입니다. 개요가 부실하면 문장력이 아무리 좋아도 최종 기사는 부실할 수밖에 없습니다.

3. 라이터 에이전트 (The Writer Agent)

이제 라이터 에이전트가 개요의 섹션을 한 번에 하나씩 가져와 작업합니다. 범위를 하나의 헤딩 (heading)으로 제한함으로써, 모델이 집중력을 잃거나 토큰 (tokens)을 아끼기 위해 세부 사항을 건너뛰는 것을 방지할 수 있습니다.

4. 크리틱 에이전트 (The Critic Agent - 가장 중요한 부분)

여기가 바로 마법이 일어나는 지점입니다. 크리틱 에이전트는 매우 까다롭게(pedantic) 행동하도록 프롬프트가 작성됩니다. 이 에이전트는 다음 사항들을 찾아냅니다:

• 일반적인 형용사 (예: "강력한(powerful)", "매끄러운(seamless)")
• 구체적인 예시의 부족
• 코드의 논리적 공백

만약 크리틱 에이전트가 문제를 발견하면, 구체적인 피드백과 함께 해당 섹션을 다시 라이터 에이전트에게 보냅니다. 이 루프 (loop)는 크리틱 에이전트가 승인(thumbs up)을 할 때까지 계속됩니다.

워크플로우 구현하기 (Implementing the Workflow)

이를 시작하기 위해 복잡한 프레임워크 (frameworks)가 필요한 것은 아닙니다. 몇 가지 서로 다른 시스템 프롬프트 (system prompts)와 while 루프를 사용한 간단한 파이썬 (Python) 스크립트만으로도 이 로직을 처리할 수 있습니다.

기술적인 팁 하나를 드리자면, 에이전트 간의 통신에는 JSON과 같은 구조화된 출력 형식 (structured output format)을 사용하세요. 리서처 에이전트가 아키텍트 에이전트에게 데이터를 전달할 때, key_concepts나 source_urls와 같은 키를 가진 JSON 객체 형태여야 합니다. 이렇게 하면 아키텍트 에이전트가 리서처 에이전트의 대화형 미사여구 (conversational filler) 때문에 혼란을 겪는 것을 방지할 수 있습니다.

빌더들을 위한 시사점 (The Takeaway for Builders)

실제로 검색 순위가 높고 가치를 제공하는 콘텐츠를 자동화하고 싶다면, "완벽한 프롬프트"를 찾으려는 시도를 멈추세요. 그런 것은 존재하지 않습니다. 대신, 견제와 균형 (checks and balances)의 시스템을 구축하세요.

피드백 루프 (feedback loop)에 집중하십시오. 출력물의 품질은 사용하는 LLM에 의해 결정되는 것이 아니라, 크리틱 에이전트의 엄격함 (rigor)에 의해 결정됩니다.

이 과정의 리서치 측면을 관리하는 분들을 위해, 저는 소스들을 정리하고 검증 가능한 상태로 유지하기 위해 Citedy (https://www.citedy.com)를 사용하고 있으며, 이는 리서처 에이전트의 컨텍스트 윈도우 (context window)로 직접 연결됩니다.