범용 LLM 중심 LaunchPilot Agent Core 방향

[hyunbin1]

범용 LLM 중심 LaunchPilot Agent Core 방향

먼저 보는 결론

Google ADK는 LangChain으로 교체한다. 정확한 지표는 기존 Elasticsearch Tool로 조회한다. RAG는 큰 문서 검색에만 선택적으로 사용한다. LangGraph는 기존 실행 코드가 실제로 복잡할 때 도입한다.

기술	현재 판단
LangChain	ADK 대신 도입
RAG	큰 암묵지·트렌드 자료에 선택적으로 사용
LangGraph	바로 도입하지 않고 기존 Workflow와 비교 후 결정
Gemini	전환 중에는 유지
Elasticsearch·상태 저장	기존 구조 유지

1. LangChain·RAG·LangGraph의 역할과 Trade-off

세 기술은 서로 대체 관계가 아니다.

LangChain
= LLM과 Tool을 연결

RAG
= 많은 문서에서 관련 자료를 검색

LangGraph
= 여러 작업의 실행 순서와 상태를 관리

LangChain

LaunchPilot에서 맡길 역할:

• Gemini 호출
• 기존 Elasticsearch Tool 연결
• Tool 호출 결과를 다시 LLM에게 전달
• Pydantic 기반 구조화 출력
• 응답 streaming 연결

장점:

• Google ADK를 제거할 수 있다.
• 모델과 Tool 연결 방식을 한곳에 모을 수 있다.
• Gemini 외의 모델도 비교하기 쉬워진다.
• 기존 evidence Tool을 그대로 재사용할 수 있다.

단점:

• LangChain이라는 새로운 프레임워크 의존성이 생긴다.
• LangChain 전용 객체를 시스템 전체에서 사용하면 다시 교체하기 어려워진다.
• 고수준 Agent 기능을 과도하게 사용하면 실행 과정을 이해하기 어려울 수 있다.

따라서 LangChain은 모델·Tool 연결 경계 안에서만 사용한다.

우리 코드
→ LangChain
→ Gemini와 기존 Tool

RAG

LaunchPilot에서 맡길 역할:

• 큰 암묵지 문서 모음에서 관련 자료 검색
• 트렌드 자료에서 현재 질문과 관련된 근거 검색
• 검색한 자료와 출처를 LLM에게 제공

장점:

• 많은 문서를 매번 전부 LLM에게 보내지 않아도 된다.
• 관련 자료만 전달하므로 입력 크기와 비용을 줄일 수 있다.
• 최신 자료와 내부 자료를 모델 교체와 상관없이 사용할 수 있다.
• 답변에 출처를 연결하기 쉽다.

단점:

• 검색에 실패하면 필요한 자료가 있어도 LLM이 보지 못한다.
• 검색 결과 안에서만 답하게 만들면 범용성이 떨어질 수 있다.
• 문서 분할·색인·검색 품질을 별도로 관리해야 한다.
• 자료가 적을 때는 전체 첨부보다 오히려 복잡하다.

따라서 모든 질문에 RAG를 강제하지 않는다.

자료	제공 방법
정확한 마케팅 지표	Elasticsearch Tool 호출
작은 첨부 파일	전체 내용을 LLM에게 전달
과거 승인 계획	계획 ID로 직접 조회
큰 암묵지·트렌드 자료	RAG 검색
일반적인 아이디어	범용 LLM의 지식 활용

RAG의 기준:

자료가 너무 많아 전부 전달하기 어려울 때 관련 자료를 찾아주는 방법으로 사용한다.

LangGraph

LaunchPilot에서 맡길 수 있는 역할:

자료 조회
→ 답변 생성
→ 검증
→ 성공하면 전달
→ 실패하면 필요한 단계부터 재시도

장점:

• 현재 어떤 작업을 실행 중인지 확인하기 쉽다.
• 분기와 재시도 경로를 명시적으로 표현할 수 있다.
• 병렬 조회와 부분 실패를 관리하기 쉽다.
• checkpoint를 구성하면 실패 지점부터 이어서 실행할 수 있다.

단점:

• AI 답변 품질이 자동으로 좋아지지는 않는다.
• 응답 속도가 자동으로 빨라지지는 않는다.
• 기존 ConversationState 외에 실행 상태가 하나 더 생긴다.
• 현재 Python Workflow가 충분하다면 불필요한 복잡성이 된다.

도입 기준:

• 실행 순서를 이해하려면 여러 파일을 계속 따라가야 한다.
• 실패한 단계부터 다시 실행하기 어렵다.
• 병렬 조회와 부분 실패 코드가 복잡하다.
• 재시도와 사용자 승인 경로가 계속 늘어난다.

현재는 기존 Workflow를 유지한다. 위 문제가 실제로 확인되면 LangGraph와 비교한다.

2. 현재 구조와 목표 구조의 차이

현재

자체 Python Workflow
→ 역할별 Worker
→ Google ADK Agent
→ Gemini
↔ 기존 evidence Tool
→ Elasticsearch

현재 ADK의 역할:

• Gemini와 Tool 연결
• 역할별 Agent 실행
• 구조화 출력
• 실행 이벤트 전달

현재 ADK와 별개인 자산:

• Elasticsearch의 실제 조회와 계산
• ConversationState
• Redis와 Elasticsearch 상태 저장
• Pydantic 데이터 형식
• 상태 변경 reducer

첫 번째 변경

자체 Python Workflow
→ 역할별 Worker
→ LangChain
→ Gemini
↔ 기존 evidence Tool
→ Elasticsearch

이 단계에서 ADK만 LangChain으로 교체한다.

유지:

• Gemini
• 역할별 Worker
• 기존 Python Workflow
• Elasticsearch와 evidence Tool
• ConversationState
• Redis
• Pydantic 데이터 형식

장기 목표

사용자 질문
    ↓
교체 가능한 실행 관리
    ↓
범용 LLM
    ↕
LaunchPilot의 데이터와 Tool
    ↓
검증·사용자 승인·상태 저장

장기적으로 역할별 Agent와 Workflow 방식도 고정 자산으로 보지 않는다. 실제 품질과 성능에 따라 바꿀 수 있어야 한다.

3. 현재 구조에서 목표 구조로 가는 순서

1단계: ADK를 LangChain으로 교체

Google ADK
→ LangChain

다른 구성은 유지한다. 같은 질문·모델·데이터로 결과를 비교한 후 ADK를 완전히 제거한다.

2단계: 역할별 Agent 재평가

역할별 Agent 여러 개
vs
범용 LLM 하나 + 필요한 Tool

다음 조건을 비교한다.

• 근거와 수치 정확성
• 답변 품질
• LLM 호출 수
• 전체 응답 시간
• 프롬프트와 Agent 유지보수 비용

범용 LLM 하나로 품질이 유지되면 불필요한 역할을 줄인다.

3단계: RAG 확대 여부 결정

작은 자료는 전체를 전달한다. 자료가 커져 입력 비용·검색·출처 관리 문제가 생길 때 RAG를 확대한다.

4단계: LangGraph 도입 여부 결정

기존 Workflow의 분기·재시도·부분 실패 관리가 실제로 복잡해질 때 LangGraph와 비교한다.

4. 정확한 마케팅 지표는 어떻게 처리하는가

정확한 지표는 RAG가 아니라 기존 Elasticsearch Tool로 처리한다.

사용자
“지난주 TikTok 참여율이 어땠어?”

LLM
필요한 지표와 채널 판단

LangChain
기존 지표 Tool 호출

Elasticsearch Tool
지표 조회와 증가율 계산

LLM
계산 결과 설명

역할	담당
질문 이해	범용 LLM
Tool 연결	LangChain
지표 조회와 계산	기존 Elasticsearch Tool
사용자·캠페인 범위 제한	기존 시스템 코드
결과 설명	범용 LLM

LLM은 숫자를 직접 계산하지 않는다. 이미 계산된 결과를 해석하고 설명한다.

5. 기존 상태와 LangGraph 상태의 차이

현재 ConversationState는 여러 대화에 걸친 사용자 업무 상태를 기억한다.

현재 업무 단계
지난 분석 결과
승인된 계획
다음 확인 시점

이 정보는 Redis와 Elasticsearch에 저장된다.

LangGraph 상태는 질문 하나를 처리하는 동안의 실행 상태다.

지표 조회 완료
트렌드 조회 실패
답변 검증 중
재시도 1회

둘은 대체 관계가 아니다.

장기 사용자 업무 상태
→ ConversationState + Redis + Elasticsearch

단기 실행 상태
→ LangGraph 상태

LangGraph를 도입하더라도 기존 상태 저장은 유지한다.

6. 우리가 이 방향을 선택한 이유

LaunchPilot은 다음 루프를 돕는 서비스다.

현재 지표 확인
→ 원인 가설
→ 다음 행동 결정
→ 계획 저장
→ 실제 결과 확인

AI와 시스템의 책임을 다음처럼 나눈다.

역할	담당
자료를 찾고 해석하며 대안을 제안	범용 LLM
실제 행동을 선택하고 승인	사용자
수치 계산, 권한 확인, 상태 저장	시스템 코드

핵심 원칙:

열린 해석은 LLM이 하고, 정확해야 하는 사실·계산·권한·저장은 코드가 한다.

7. 변하지 않는 자산과 바꿀 수 있는 부분

계속 축적할 자산

• Elasticsearch의 마케팅 데이터
• 트렌드와 마케터 암묵지
• 기존 evidence Tool
• 사용자별 캠페인 맥락
• 승인된 계획과 실제 결과
• ConversationState
• Pydantic 데이터 형식
• 검증 규칙과 평가 사례

필요에 따라 바꿀 수 있는 부분

• 사용하는 LLM
• 프롬프트
• 역할별 Agent 구성
• RAG 검색 방식
• 자체 Workflow 또는 LangGraph
• 모델과 Tool을 연결하는 프레임워크

좋은 구조의 기준:

모델·Agent·Workflow를 바꿔도 데이터·상태·Tool·평가 기준은 다시 만들지 않아야 한다.

8. 성공 기준

1차 전환

• Google ADK 의존성과 import가 완전히 제거된다.
• 기존 Elasticsearch 지표 조회가 동일하게 동작한다.
• 사용자 상태와 승인 기록이 유지된다.
• 기존 Pydantic 출력 형식을 통과한다.
• 기존보다 근거와 수치 정확도가 낮아지지 않는다.

장기 방향

• 새로운 모델을 연결해도 데이터와 상태 코드를 바꾸지 않는다.
• 새로운 Tool을 추가해도 전체 Agent 구조를 다시 만들지 않는다.
• 동일한 평가 사례로 모델과 Agent 구조를 비교할 수 있다.
• LLM 호출 수와 응답 시간이 불필요하게 증가하지 않는다.
• 프롬프트와 Agent 개수가 필요 이상으로 늘어나지 않는다.

결론

LangChain
= ADK를 대신해 LLM과 Tool을 연결

RAG
= 큰 문서 집합에 선택적으로 사용

LangGraph
= 실행 Workflow가 복잡할 때 도입 검토

이 기술들은 LaunchPilot의 중심 자산이 아니다.

중심 자산
= 데이터
+ Tool
+ 사용자 기억
+ 계획과 결과
+ 검증 기준

Google ADK 제거와 LangChain 전환은 이 장기 구조로 가기 위한 첫 단계다.

[bbororo5]

초안 정리 감사합니다. 특히 아래 원칙에는 동의합니다.

열린 해석은 LLM이 하고, 정확해야 하는 사실·계산·권한·저장은 코드가 담당한다.

Elasticsearch의 데이터, 기존 Tool, 상태, 평가 기준을 장기 자산으로 두고 모델과 Agent 프레임워크는 교체 가능하게 만들자는 방향도 유지하면 좋겠습니다.

다만 이번 작업은 운영 중인 서비스를 무중단으로 마이그레이션하는 일보다는, 해커톤 프로젝트를 프로덕션 수준의 포트폴리오로 다시 설계하는 일에 가깝습니다. 따라서 ADK → LangChain → 필요하면 LangGraph처럼 기존 구조를 단계적으로 보존하기보다, 목표 구조를 이번에 명확하게 선택했으면 합니다.

제가 제안드리는 핵심 변경은 두 가지입니다.

1. ADK를 LangChain으로 단순 교체하지 않고 LangGraph를 Agent Core의 실행 프레임워크로 바로 채택합니다. LangChain은 모델·Tool 연동과 필요한 Agent 노드에서 선택적으로 사용합니다.
2. RAG를 큰 문서 검색으로 제한하지 않고, 우리 데이터의 정량성·의미성·관계성에 맞춰 구조화 검색, hybrid retrieval, graph expansion을 조합하는 Agentic Retrieval로 설계합니다.

1. LangGraph 중심으로 Agent Core 재설계

LangChain과 LangGraph는 둘 중 하나만 선택하는 관계는 아닙니다.

• langchain-core는 메시지·Tool·모델 호출 등에 사용하는 공통 기반입니다.
• LangGraph는 상태, 분기, 반복, 재시도, 사용자 승인을 관리하는 실행 계층입니다.
• LangChain의 고수준 Agent API도 LangGraph runtime 위에서 동작합니다.
• 반대로 LangGraph는 고수준 LangChain Agent를 사용하지 않고도 독립적으로 사용할 수 있습니다.

따라서 우리 선택은 다음과 같이 표현하는 것이 정확합니다.

LangGraph를 Agent 시스템의 주 실행 프레임워크로 채택하고, LangChain은 모델·Tool integration과 자율적인 Agent loop가 필요한 노드에서만 사용한다.

Agent 실행과 상태 전이
→ LangGraph

모델·메시지·Tool 연동
→ LangChain 구성 요소를 선택적으로 사용

정확한 계산·권한·저장
→ 기존 Python 코드와 Elasticsearch Tool

장기 사용자 업무 상태
→ ConversationState + Redis + Elasticsearch

자료를 탐색하며 Tool 호출 여부를 판단하는 Analyst 노드에는 Agent abstraction을 사용할 수 있습니다. 반면 지표 집계, 결과 검증, 승인 반영, 상태 저장은 명시적인 Python/LangGraph 노드가 담당하는 편이 적절합니다.

질문 분류
→ 근거 검색
→ Signal 분석
→ Hypothesis 생성
→ Experiment 제안
→ 검증
→ 사용자 승인
→ 상태 저장

이 흐름은 미래에 생길지 모르는 복잡성이 아니라 LaunchPilot이 이미 수행하려는 업무 흐름입니다. 따라서 LangGraph를 나중에 검토할 기술이라기보다, 현재의 상태와 전이를 코드에 명시하기 위한 기반으로 보는 것이 좋겠습니다.

참고: LangGraph Overview

2. 우리 데이터 특성에서 출발한 Retrieval 설계

LaunchPilot이 검색해야 하는 데이터는 한 종류가 아닙니다.

정확하게 계산해야 하는 정량 데이터

현재 프로젝트에는 다음과 같은 콘텐츠 성과 필드가 있습니다.

views, likes, comments, shares, saves
save_rate, engagement_rate
follower_count, watch_time_sec, retention_rate

실제 Meta Ads와 Google/YouTube Ads를 연동하면 다음과 같은 데이터도 다루게 됩니다.

campaign_id, adset/ad_group_id, ad_id, date
impressions, reach, clicks
spend 또는 cost_micros
actions 또는 conversions
video_views, video_view_rate
video_quartile_p25/p50/p75/p100_rate

이 데이터는 날짜, 채널, 캠페인, 광고 소재를 기준으로 필터링하고 합계·평균·증감률을 계산해야 합니다. 따라서 이런 질문은 vector search가 아니라 Elasticsearch의 filter와 aggregation으로 처리해야 합니다.

지난 4주간 캠페인별 광고비와 전환 수를 비교해 줘.

YouTube 영상 중 75% 시청률이 전주보다 상승한 소재를 찾아줘.

LLM이 숫자를 직접 계산하는 것이 아니라 Elasticsearch와 시스템 코드가 정확한 결과를 만들고, LLM은 그 결과를 해석해야 합니다. 또한 플랫폼별 spend와 cost_micros, actions와 conversions처럼 단위와 의미가 다른 필드는 원본을 보존하면서 공통 지표 모델로 정규화해야 합니다.

의미를 이해해야 하는 텍스트 데이터

우리에게는 광고 소재 제목과 설명, 캠페인 브리프, 팀 메모, 트렌드 문서, 고객 반응, 과거 분석 및 실험 회고도 있습니다.

예를 들어 “팬들이 멤버들의 자연스러운 모습을 좋아했던 콘텐츠”를 찾을 때 문서에 같은 문장이 없어도 behind the scenes, studio vlog, members interview처럼 의미가 비슷한 콘텐츠를 찾아야 합니다. 반대로 캠페인명, 제품명, 해시태그, 광고 ID처럼 정확한 단어가 중요한 경우도 있습니다.

관계를 따라가야 하는 업무 데이터

LaunchPilot의 핵심 데이터는 개별 문서로 끝나지 않습니다.

광고 성과 변화
→ Signal
→ Hypothesis
→ Experiment
→ Outcome

특정 광고의 성과가 변했다는 사실만 찾는 것이 아니라, 어떤 Signal에서 어떤 Hypothesis가 만들어졌고 어떤 Experiment를 실행했으며 결과가 어땠는지 연결해서 찾아야 합니다. 이 문제는 문장 유사도만 계산하는 일반적인 vector RAG보다 관계를 따라가는 검색이 더 잘 맞습니다.

3. 현재 주목받는 RAG 패턴이 우리와 맞는 이유

초기의 RAG는 주로 문서를 chunk로 나누고 질문과 의미가 비슷한 chunk를 vector search로 찾는 방식이었습니다. 하지만 실제 서비스 데이터에는 정확한 키워드, 의미, 수치, 시간, 객체 관계가 함께 존재하기 때문에 최근에는 여러 검색 방식을 조합하는 방향으로 발전하고 있습니다.

Vector RAG
→ Hybrid RAG
→ Multi-stage Retrieval
→ GraphRAG
→ Agentic RAG

우리에게 이 흐름이 중요한 이유는 최신 기술이기 때문이 아니라, 우리가 가진 데이터 구조와 맞기 때문입니다.

정확한 수치·기간 비교
→ Elasticsearch filter + aggregation

campaign_id, ad_id, experiment_id처럼 ID가 명확한 데이터
→ direct lookup

소재 설명·팀 메모·브리프·트렌드 문서
→ BM25 + dense vector + learned sparse retrieval

Signal → Hypothesis → Experiment → Outcome 관계
→ graph expansion

각 검색기가 찾은 후보
→ RRF로 결합
→ reranker로 최종 정렬

• BM25는 정확한 캠페인명·제품명·키워드를 찾는 데 강합니다.
• dense vector는 표현이 달라도 의미가 비슷한 자료를 찾습니다.
• learned sparse retrieval은 키워드 정확성과 의미 확장을 보완합니다.
• graph expansion은 문장 유사도를 넘어 업무 객체의 연결 관계를 따라갑니다.
• RRF와 reranker는 여러 검색 결과를 합치고 최종 근거의 관련성을 높입니다.

Elasticsearch도 lexical search와 vector search를 결합하고 RRF로 순위를 통합하는 hybrid search를 권장하고 있습니다.

참고: Elasticsearch Hybrid Search

GraphRAG 역시 vector search를 대체한다기보다 entity, relationship, claim과 원문 chunk를 함께 구성해 관계를 탐색하는 방식입니다.

참고: Microsoft GraphRAG Overview

별도의 graph database를 처음부터 도입해야 한다는 의미는 아닙니다. 우선 Signal·Hypothesis·Experiment·Outcome의 ID와 관계를 명시적으로 저장하고 Elasticsearch에서 관계 확장이 가능하도록 만든 뒤, 데이터 규모와 질의 복잡도가 별도 graph store를 정당화하는지 평가할 수 있습니다.

또한 모든 질문에 모든 검색기를 실행할 필요는 없습니다. 질문을 분석해 필요한 검색 전략만 선택하는 구조가 적합합니다.

“지난주 광고비와 전환 수를 비교해 줘”
→ filter + aggregation

“자연스러운 분위기의 소재를 찾아줘”
→ hybrid text search

“이 실험으로 이어진 가설이 무엇이었지?”
→ direct lookup + graph expansion

“성과가 오른 소재와 관련 메모, 과거 실험을 함께 분석해 줘”
→ aggregation + hybrid search + graph expansion

이 검색 과정을 LangGraph 노드로 표현하면 어떤 검색기가 호출되었고, 어떤 근거가 최종 답변에 사용됐는지도 추적할 수 있습니다.

4. 최종 제안

이번 이슈에서는 다음과 같이 방향을 결정했으면 합니다.

1. Google ADK를 제거한다.

2. 기존 Python Workflow를 유지한 채 LangChain만 교체하지 않고,
   LangGraph 중심으로 Agent Core를 재설계한다.

3. LangChain은 모델·Tool integration과
   필요한 Agent 노드에서 선택적으로 사용한다.

4. Elasticsearch를 정량 집계뿐 아니라
   lexical·dense·sparse hybrid retrieval의 중심으로 활용한다.

5. Signal·Hypothesis·Experiment·Outcome 관계를 명시적으로 저장하고
   graph expansion이 가능한 Retrieval 구조를 만든다.

6. 검색 결과는 RRF로 결합하고,
   필요하면 reranker로 최종 근거를 선정한다.

평가는 다음 항목을 중심으로 진행하면 좋겠습니다.

• 지표 조회와 파생 지표 계산이 원본 데이터와 일치하는가
• BM25, vector, hybrid, graph expansion 사이에 검색 품질 차이가 있는가
• 답변이 어떤 수치와 문서를 근거로 했는지 추적할 수 있는가
• 실패한 노드부터 재실행할 수 있는가
• 사용자 승인 전에는 상태 변경이 발생하지 않는가
• Agent 구조를 바꿔도 기존 Tool·상태·평가 데이터가 유지되는가

정리하면 초안이 세운 데이터·Tool·상태·평가 기준을 장기 자산으로 둔다는 원칙은 유지하되, 이번 포트폴리오 리빌딩에서는 점진적인 프레임워크 교체보다 LangGraph 중심 Agent 구조와 데이터 특성에 맞춘 Hybrid·Graph·Agentic Retrieval을 목표 구조로 바로 채택하는 방향을 제안합니다.

[hyunbin1]

각 개념을 하나씩 찾아보며 댓글에서 제안해 주신 방향을 이해할 수 있었습니다. 상세하게 정리해 주셔서 감사합니다.

특히 RAG를 단순히 유사한 문서 일부를 가져오는 방식으로 제한하지 않고, 데이터의 성격에 따라 정량 데이터는 구조화 조회와 집계로, 텍스트는 Hybrid Retrieval로, 업무 과정은 Graph Expansion으로 탐색한다는 방향이 좋다고 생각합니다. 이렇게 역할을 분리한다면 제가 기존 RAG를 사용하면서 느꼈던 검색 결과의 제한성과 편향 문제도 상당 부분 보완할 수 있을 것 같습니다.

제가 추가로 말씀드릴 수 있는 부분은, 이러한 구조의 성능이 결국 우리가 축적하는 데이터의 품질과 구조에 의해 결정된다는 점인 것 같습니다. 검색 기술은 존재하는 데이터를 더 잘 찾고 연결할 수는 있지만, 기록되지 않은 맥락이나 부정확한 관계를 스스로 복원해 주지는 못하기 때문입니다.

Hybrid Retrieval을 위해서는 저희만의 마케팅 암묵지인 메모와 회고를 단순한 결과 위주로 남기기보다 대상, 기간, 맥락, 관찰 내용과 판단 근거가 드러나도록 축적해야 실제 의미가 비슷한 사례를 찾을 수 있을 것 같습니다.

Graph Expansion을 위해서는 Signal·Hypothesis·Experiment·Outcome을 개별 데이터로만 저장하지 않고, 어떤 관찰이 어떤 가설과 실험으로 이어졌는지 관계와 식별자를 명확하게 연결해야 업무 과정을 따라갈 수 있을 것 같습니다.

또한 성공 사례만 축적하면 이후 검색과 제안도 성공 사례에 편향될 수 있으므로 실패 사례, 반대 근거, 적용되지 않았던 조건도 함께 기록할 필요가 있다고 생각합니다. 데이터의 출처, 시점, 작성 주체와 신뢰도 역시 검색된 근거를 사실과 해석으로 구분하고, 답변의 한계를 판단하는 데 중요할 것 같습니다.

따라서 Retrieval 구조와 함께 각 단계에서 어떤 데이터를 어떤 기준으로 생성·검증·축적할 것인지도 주요 설계 범위로 포함하면 좋을 것 같습니다.