JeaniRFP 기반 시장 인텔리전스 에이전트

Service Thesis

Jeani는 RFP를 읽고 "무엇을 조사해야 하는가"부터 다시 계획하는 시장 조사 에이전트 파이프라인입니다.

단일 챗봇에 시장 조사를 맡기면 검색어 선정, 경쟁사 범위, 기술 트렌드, 출처 중복, 최종 보고서 저장 경로가 흐려집니다.
Jeani는 RFP 문서를 기준으로 조사 계획을 만들고, 시장 리서치, 경쟁사 분석, 기술 분석, 종합 보고, Knowledge Base 동기화를 분리된 Lambda agent와 S3 lifecycle로 다룹니다.

AWS EST 교육 기반 팀 프로젝트

Jeani는 AWS EST Gen AI 실무 역량 강화 과정 안에서 수행한 팀 프로젝트입니다.
이 과정은 전사 클라우드 및 생성형 AI 기술 내재화를 목표로 한 Enterprise Skills Transformation 프로그램으로, 2025년 9월 8일부터 2025년 12월 5일까지 총 13주 동안 진행됐습니다.

교육은 AWS 본사 정규 직원 강의, 오프라인 실습, 온라인 자율 학습, 팀 프로젝트 기반 개발로 구성됐습니다.
이 기간 동안 Generative AI Essentials on AWS, Developing Generative AI Applications on AWS, Agentic AI Foundations, Advanced RAG, MCP, SageMaker, MLOps 관련 과정을 이수했고, 학습 내용을 Jeani의 RFP 분석, agent workflow, S3/Bedrock Knowledge Base 연동 구조에 적용했습니다.

RFP가 검색 계획으로 바뀌는 방식

Jeani는 시장 조사를 고정 키워드 목록으로 시작하지 않습니다.
PlannerAgent가 S3의 00_input_data/ 문서를 먼저 읽고, 그 문서에서 프로젝트 요약, 고객사, 산업 도메인, 범위, 경쟁사, 검색 키워드, 기술 주제, 시장 주제, 실행 우선순위를 뽑습니다. .docx는 내부 XML에서 텍스트를 꺼내고, .pdf, .txt, .json도 같은 DocumentParser 경계로 정규화합니다.
RFP 본문은 최대 8,000자까지 prompt에 넣고, 기본 경쟁사/키워드/기술 컨텍스트는 fallback 정보로 붙습니다.

Planner의 결과는 단순 요약문이 아니라 다음 agent들이 바로 실행할 수 있는 plan schema입니다.
경쟁사는 name, priority, reason을 갖고, 검색 키워드는 keyword, category, purpose를 갖습니다.
기술/시장 주제에는 실제 검색에 사용할 search_query가 들어갑니다.
이 계획은 06_market_intelligence/plans/{project_id}/search_plan.json에 저장되어, 이후 workflow가 어떤 질문을 기준으로 움직였는지 되짚을 수 있게 합니다.

시스템을 다시 정의하면

Jeani의 핵심은 시장 조사 결과를 한 번 생성하는 것이 아닙니다.
RFP마다 조사 대상이 달라진다는 점을 시스템 경계로 끌어올린 것이 핵심입니다.
PlannerAgent가 만든 plan을 ResearcherAgent, CompetitorAgent, TechAnalystAgent가 공유하고, 각 agent는 같은 프로젝트를 서로 다른 관점에서 조사합니다.

마지막 SynthesizerAgent는 각 agent 결과를 종합해 executive summary, market trends, competitive insights, tech recommendations, strategic recommendations, action items, risks, next steps를 만듭니다.
Orchestrator는 이 결과를 06_market_intelligence/workflows/{project_id}/에 agent별 원본으로 저장하고, 최종 보고서는 06_market_intelligence/daily_updates/{document_name}/{timestamp}.json으로 저장합니다.
저장 시 기존 URL을 다시 수집하지 않도록 문서별 기존 source URL을 읽어 중복을 필터링하는 로직도 들어 있습니다.

Agent Runtime

runtime의 중심에는 workflow orchestrator가 있습니다.
입력으로 특정 RFP 문서가 오면 해당 문서를 파싱하고, 없으면 00_input_data/에서 최신 RFP 문서를 찾습니다. scheduled run에서는 00_input_data/의 모든 문서를 순회하며 문서별 workflow를 실행합니다.

실행 단계는 세 개입니다.
Phase 1은 planner입니다. planner는 RFP를 읽고 검색 계획을 만듭니다.
Phase 2는 researcher, competitor, tech analyst의 병렬 실행입니다.
Orchestrator는 ThreadPoolExecutor(max_workers=3)로 세 agent를 동시에 호출하고, 성공 또는 partial 결과만 context.agent_results에 넣어 synthesizer가 사용할 수 있게 합니다.
Phase 3은 synthesizer입니다. synthesizer는 이전 결과를 보고서 형식으로 통합합니다.
마지막으로 trigger option이 켜져 있으면 KB sync Lambda를 비동기로 호출합니다.

진행 상태도 별도 데이터로 남습니다. agent 실행 결과는 workflows/{project_id}/{agent_name}/result.json에 저장되고, DynamoDB에는 kb-{project_id} 파티션 아래 agent별 결과와 KB_WORKFLOW_STATUS가 기록됩니다.
UI나 운영 스크립트는 이 상태를 통해 현재 agent, progress, 완료/오류 상태를 확인할 수 있습니다.

검색 수집 계층

Jeani의 세 조사 agent는 모두 Brave Search를 사용하지만 같은 검색을 반복하지 않습니다.
ResearcherAgent는 plan의 search_keywords 최대 5개와 market_topics 최대 3개를 읽고, 각 쿼리마다 웹 검색 결과를 수집합니다.
수집된 result에는 검색어와 category를 다시 붙여서 후속 LLM 분석에서 어떤 키워드가 어떤 결과를 만들었는지 잃지 않게 합니다.

CompetitorAgent는 plan의 경쟁사 목록을 기준으로 회사별 검색을 수행합니다.
각 경쟁사에 대해 “AI 서비스”, “디지털 전환”, “신규 사업” 주제를 붙인 웹 검색과 최신 뉴스 검색을 분리해 가져오고, LLM 분석 단계에서 threat level, strengths, key activity, market leaders, opportunities로 압축합니다.
경쟁사 이름이 plan에 없으면 기본 산업 컨텍스트의 경쟁사 목록을 fallback으로 사용합니다.

TechAnalystAgent는 기술 주제별로 trend 검색과 use case 검색을 나눕니다.
예를 들어 특정 기술에 대해 트렌드 쿼리와 활용 사례 쿼리를 따로 만들고, 산업 도메인이 있으면 쿼리에 같이 넣습니다.
분석 결과는 maturity, recommendation, must-have tech, nice-to-have tech, trends, risks로 정리되어 제안서 전략에 바로 연결될 수 있는 기술 판단 자료가 됩니다.

검색 helper에는 무료 플랜 rate limit을 고려한 요청 간 지연이 들어 있고, API key는 환경변수 우선으로 읽습니다.
공개 문서에는 키 값을 쓰지 않고 Brave Search integration이라는 역할만 남기는 것이 맞습니다.

Self-Reflexion 구조

공통 agent runtime은 KB Intelligence agent들의 실행 계약입니다.
각 agent는 collect, analyze, evaluate 단계를 따릅니다. collect는 Brave Search나 RFP parser처럼 외부 데이터를 가져오는 단계이고, analyze는 Bedrock 모델을 호출해 agent별 JSON schema를 채우는 단계입니다. evaluate는 결과 품질을 점수화하고, 부족하면 개선 피드백을 만들어 다음 분석 prompt에 다시 넣습니다.

이 구조 덕분에 agent별 품질 기준을 다르게 둘 수 있습니다. planner는 경쟁사, 키워드, 기술 주제, 시장 주제, 실행 우선순위가 충분한지 봅니다. researcher는 findings, trends, recommendations를 봅니다. competitor는 analysis summary, competitors, insights, opportunities를 봅니다. tech analyst는 technologies, must-have/nice-to-have tech, trends, risks를 봅니다. synthesizer는 executive summary, strategic recommendations, action items, trend/tech recommendations를 봅니다.

중요한 점은 평가가 단순 boolean이 아니라 다음 시도에 들어가는 feedback이라는 점입니다.
각 agent는 품질 기준을 넘지 못하면 평가 feedback을 다음 prompt에 붙여 다시 분석합니다. planner, researcher, competitor, tech analyst는 최대 2회, synthesizer는 최대 3회까지 반복하도록 설정되어 있습니다.
그래서 이 시스템은 “검색 결과를 LLM에 한 번 넣고 끝”나는 구조가 아니라, 수집 결과를 agent별 schema와 품질 기준에 맞춰 다시 다듬는 구조입니다.

저장, 중복 제거, Knowledge Base 경계

S3 폴더 구조는 Jeani에서 중요한 설계입니다.
06_market_intelligence/plans는 검색 계획, 06_market_intelligence/workflows는 agent별 실행 결과와 workflow metadata, 06_market_intelligence/daily_updates는 최종 market intelligence report를 담습니다.
KB sync는 daily updates만 Jeani의 Market Intelligence Knowledge Base 대상으로 삼고, plans/workflows는 KB에서 제외합니다.
이렇게 해야 내부 실행 흔적과 최종 검색 대상이 섞이지 않습니다.

또 하나의 세부 설계는 중복 URL 필터링입니다.
Orchestrator는 문서별 daily_updates 폴더에서 기존 source URL을 모은 뒤, 새 researcher/competitor/tech analyst 결과의 source를 필터링합니다.
반복 실행될수록 같은 URL이 계속 보고서에 쌓이는 문제를 줄이기 위한 장치입니다.

최종 보고서에는 synthesizer 결과만 들어가지 않습니다.
Orchestrator는 source_data에 agent별 원본 결과를 붙이고, metadata에는 report id, generated time, project id, RFP document key, agents used, filtered URL count, new source count를 기록합니다.
이 metadata 덕분에 portfolio 관점에서도 Jeani의 시장 조사 루프가 단발성 생성물이 아니라 반복 실행과 누적 지식을 전제로 설계됐다는 점이 드러납니다.

API와 화면별 기능 매트릭스

문서관리 UI와 운영 루프

Jeani의 문서관리 화면은 market intelligence 산출물을 단순 파일 목록이 아니라 운영 상태로 보여줍니다. /api/documents?marketIntelligence=true는 06_market_intelligence/ 아래의 daily_updates, plans, workflows 폴더를 읽어 파일 수와 마지막 수정 시각을 반환합니다. /api/documents?marketIntelligence=projects는 daily update의 문서별 프로젝트와 workflow 목록을 함께 구성해, 사용자가 어떤 RFP에 대해 어떤 보고서와 agent 결과가 생겼는지 확인하게 합니다.

frontend는 이 데이터를 Market Intelligence tab의 통계, 프로젝트 카드, 업데이트 파일, workflow card, agent badge로 풀어냅니다. agent별 result.json은 download action으로 이어지고, Bedrock tab에서는 Knowledge Base와 data source, ingestion job status를 조회하거나 manual sync를 실행할 수 있습니다.
즉 Jeani의 시장 조사 루프는 backend batch 작업에서 끝나지 않고, 운영자가 산출물과 동기화 상태를 확인하는 화면까지 연결됩니다.

포트폴리오 관점의 구현 포인트는 시장 조사 업무를 하나의 prompt가 아니라 data lifecycle로 나눈 데 있습니다.
RFP에서 질문을 뽑고, 외부 검색을 agent별로 분리하고, 결과를 평가하며, 최종 보고서만 Knowledge Base에 넣습니다.
여기에 문서관리 UI가 plans, workflows, daily updates, KB sync를 한 화면 흐름으로 묶으면서 제안 업무에서 반복 가능한 시장 인텔리전스 운영 루프를 만듭니다.