30분 걸리던 리드 리서치를 자동화한 4개 에이전트 파이프라인
잠재 고객을 찾기 위해 레딧이나 해커뉴스를 하루 종일 뒤져본 경험이 있을 것이다. 누군가 특정 도구에 대해 불만을 터뜨리거나 새로운 제품을 출시했다는 신호를 포착해도, 이를 실제 영업 기회로 연결하려면 다른 커뮤니티와 깃허브까지 일일이 확인해야 한다. Thrad.ai 영업팀은 리드 한 명을 발굴하기 위해 6개 소스를 리서치하며 인당 30분에서 45분을 소모했다. 이들은 단일 모델로는 처리하기 힘든 광범위한 소스 분석과 서로 다른 API 대응 문제를 해결하기 위해 4개의 전문 에이전트가 협업하는 파이프라인을 구축했다.
먼저 데이터 수집 단계에서는 두 명의 에이전트가 병렬로 움직이며 정보를 긁어모은다. 트렌드 리서치 에이전트(Trend Research Agent)는 해커뉴스, 유튜브, dev.to, 프로덕트헌트, 레딧, 스택 오버플로우 등 6개 소스를 쿼리하여 제품 출시 소식이나 구매 의도가 담긴 신호를 찾는다. 동시에 서치 스페셜리스트 에이전트(Search Specialist Agent)가 위키피디아, 깃허브, 롭스터스, 스택 오버플로우를 통해 해당 리드의 배경 정보를 보강한다. 소스마다 데이터 구조와 접근 방식이 다르기 때문에 각 에이전트에게 전담 소스와 도구를 할당하여 분석의 정밀도를 높였다.
수집된 정보는 분석 에이전트(Analysis Agent)로 전달되어 가치 판단 과정을 거친다. 이 에이전트는 아마존 베드락(Amazon Bedrock)의 클로드 소네트 4.6(Claude Sonnet 4.6) 모델을 기반으로 잠재 고객과 트렌드의 쌍을 0점에서 100점 사이로 점수화한다. 이때 글로벌 추론 프로필인 `global.anthropic.claude-sonnet-4-6`를 사용하여 리전별 ARN 설정 없이 최적의 리전으로 요청을 라우팅하며 멀티 리전 배포 환경의 복잡도를 낮췄다. 분석 결과 점수가 높은 리드만이 메일 생성 에이전트(Email Generation Agent)로 넘어가며, 여기서는 브랜드 가이드라인을 준수하는 개인화된 메일 초안을 작성하고 검증한다.
이 파이프라인의 핵심은 단일 모델에게 모든 리서치와 작성을 맡기지 않고 역할을 완전히 쪼갠 것에 있다. 리드 발굴부터 개인화 메일 발송까지의 전 과정을 자동화함으로써 실무자가 수동으로 리서치하던 30분 이상의 시간을 제거했다. 각 에이전트가 하나의 책임과 전용 도구 세트를 가지는 구조는 복잡한 외부 소스 분석에서 발생하는 환각이나 누락을 줄이는 실무적 대안이 된다.
Pydantic 검증과 가중치 기반의 신호 교차 분석(Triangulation)
데이터를 많이 모을수록 정교한 타겟팅이 가능하다고 믿지만, 실제로는 검증되지 않은 정보가 많을수록 노이즈만 늘어난다. Thrad.ai는 이를 해결하기 위해 Pydantic(파이썬 데이터 검증 라이브러리)을 도입해 에이전트 간 출력 계약(Output Contract)을 강제했다. 에이전트가 내뱉는 데이터의 타입과 형식을 런타임에서 엄격하게 검사하여 타입 안전성을 확보하는 방식이다. 특정 에이전트가 정의된 스키마와 다른 형태의 데이터를 반환하면 시스템이 이를 즉시 포착해 다음 단계로 전달하지 않고 차단함으로써 분석 단계의 런타임 오류를 방지한다.
단일 소스의 정보는 단순한 홍보성 게시물일 가능성이 커서 최소 2개 이상의 독립 소스에서 상관관계가 확인된 증거가 있을 때만 리드로 인정하는 신호 교차 분석(Triangulation)을 적용했다. 예를 들어 개발자 커뮤니티에 제품 출시 글이 올라왔더라도 추천 요청 스레드나 Stack Overflow의 활동, GitHub 스타 수 등의 추가 증거가 없다면 이를 단순한 프로모션 활동으로 간주해 필터링한다. 이러한 교차 검증은 분석 에이전트가 고비용의 추론 토큰을 소모하기 전에 부적합한 리드를 미리 걸러내는 게이트 역할을 한다.
분석 에이전트는 주제 적합성 25%, 타이밍 관련성 20%, 참여 잠재력 20%, 의도 신호 20%, 데이터 품질 15%라는 다섯 가지 가중치 기준을 적용해 리드의 가치를 점수화한다. 여기에 시간적 감쇠(Temporal Decay) 로직을 더해 발생한 지 24시간 미만인 신호에는 1.5배 가중치를 부여하고, 7일을 초과한 신호는 0.5배로 낮춰 우선순위에서 제외한다. 최신 트렌드에 민감한 B2B 영업 환경에서 정보의 시의성을 수치화해 리소스 투입 순서를 결정하는 기준이 된다.
이상적 고객 프로필(ICP) 매칭 단계에서는 오픈소스 프로젝트를 운영하며 B2B 개발 도구에 집중하는 특성을 가진 경우 최대 10점의 가산점을 부여해 타겟팅의 정밀도를 높였다.
Swarm vs Graph: 동적 제어와 고정 워크플로의 벤치마크
리서치 자동화 도구 구축 시 에이전트 간 제어권 전달 오류로 인한 무한 루프와 토큰 낭비 문제가 발생할 수 있다. Thrad.ai는 이를 해결하기 위해 Swarm 방식을 도입했다. Swarm은 `handoff_to_agent` 도구를 통해 에이전트가 동적으로 제어권을 전달하며 공유 메모리를 사용한다. 트렌드 리서치 에이전트가 리드를 발굴해 서치 스페셜리스트에게 넘기면, 다시 분석 에이전트가 점수를 매기는 구조다. 만약 분석 단계에서 정보가 부족하다고 판단하면 다시 리서치 단계로 제어권을 되돌려 추가 맥락을 요청할 수 있다. 무한 루프를 방지하기 위해 윈도우 8, 최소 고유 에이전트 3명이라는 안전 장치를 설정해 강제로 전진하게 만들었다.
python
Swarm 설정 및 handoff 파라미터 예시
swarm_config = {
"handoff_window": 8,
"min_unique_agents": 3,
"shared_memory": True
}
반면 Graph 방식은 고정된 방향성 그래프(DAG)를 따라 실행된다. 트렌드 리서치와 서치 스페셜리스트가 병렬 진입점으로 설정되어 동시에 작동하며 데이터 수집 시간을 단축한다. 두 에이전트의 작업이 모두 완료되어야 분석 에이전트가 실행되는 게이팅 구조를 가지며, 특히 분석 점수가 60점 이상인 경우에만 이메일 생성 단계로 진입하도록 조건부 엣지를 설정해 낮은 품질의 리드가 발송 단계까지 넘어가는 비용 낭비를 막는다.
python
Graph 정의 및 병렬 진입점, 조건부 엣지 설정
workflow = Graph()
workflow.add_edge("TrendResearch", "Analysis")
workflow.add_edge("SearchSpecialist", "Analysis")
workflow.add_conditional_edge("Analysis", "EmailGen", lambda x: x.score >= 60)
두 방식을 50명의 리드 워크로드로 벤치마크한 결과, Swarm은 리드의 복잡도가 높고 에이전트가 이전 단계의 정보를 다시 요청해야 하는 유연한 상황에 유리하지만, 실행 경로를 예측하기 어렵고 핸드오프 추론 과정에서 토큰 소모가 더 많았다. Graph는 모든 실행이 동일한 경로를 따르므로 실패한 케이스를 동일한 입력값으로 재현해 수정하는 감사 가능성이 높으나, 동적 루프가 불가능해 추가 맥락이 필요할 경우 DAG 정의에 명시적인 피드백 엣지를 직접 추가해야 하는 제약이 있다.
실무 적용을 위한 오케스트레이션 선택 기준과 확장 가능성
이러한 멀티에이전트 협업 체계는 잠재 고객 발굴 외에도 경쟁사 인텔리전스 수집, 인재 소싱, 심층 시장 조사 등 유사한 리서치 워크플로에 적용 가능하다. 실무자가 아키텍처를 결정할 때 가장 먼저 고려할 점은 작업 순서의 반복성 여부다.
워크플로가 명확하게 정해져 있고 시스템 오류나 결과물 불만족 시 실패한 지점을 정확히 찾아내어 다시 실행하는 재현(Replay) 능력이 중요하다면 Graph 패턴을 선택해야 한다. Graph 방식은 에이전트들이 고정된 단방향 경로를 따라 움직이므로 실행 경로가 투명하고 감사 추적이 쉽다. 특히 데이터 수집과 분석 단계가 병렬로 진행된 후 최종 검증 단계로 모이는 구조를 짤 때 유리하며, 정해진 순서대로 데이터를 처리하고 결과물을 검증하는 엄격한 파이프라인이 필요한 기업 환경에 적합하다.
반면 데이터의 상태에 따라 유연하게 움직이며 최적의 답을 찾아야 한다면 Swarm 패턴이 대안이 된다. 분석 에이전트가 수집된 정보가 빈약하다고 판단하면 다시 발굴 에이전트에게 돌아가 추가 컨텍스트를 요청하는 양방향 소통이 가능하다. 다만 동적 제어권 전달 과정에서 추가 추론이 필요해 토큰 소비량이 Graph 방식보다 높아질 수 있다. 탐색 범위가 넓고 예측 불가능한 변수가 많아 에이전트 간의 자율적인 협업이 성과를 결정짓는 리서치 작업에 더 유리한 선택지다.
이 시스템을 실제 환경에 구축하려면 Python 언어 활용 능력과 AWS CDK(AWS Cloud Development Kit) 기초 지식, LLM 프롬프트 제어 개념이 필요하다. 구체적인 전체 설정 가이드와 구현 코드가 담긴 리포지토리는 [README.md](README.md)에서 확인할 수 있다. 결국 비즈니스 요구사항이 오류 없는 반복 실행인지, 아니면 유연한 탐색을 통한 정보 보강인지에 따라 Graph와 Swarm 중 하나를 선택하는 것이 실무적인 아키텍처 결정의 기준이 된다.
커뮤니티를 일일이 뒤지며 잠재 고객의 구매 신호를 찾던 수동 리서치의 번거로움은 이제 에이전트 설계의 문제로 옮겨갔다. 정교하게 짜인 고정 경로의 안정성과 유연한 동적 탐색의 효율성 사이에서 무엇을 우선할 것인가에 대한 답이 곧 자동화의 품질을 결정한다.
결국 자동화의 성패는 워크플로의 예측 가능성과 비용 사이의 최적점을 찾는 설계자의 판단 기준에 달려 있다. 본문의 오케스트레이션 선택 기준을 현재 공정에 대입해 가장 적합한 패턴으로 파이프라인을 구축하는 것이 내일 당장 실행할 수 있는 최선의 방법이다.
