Agentic Search 시스템 구축기: 사내 검색 환경을 재정의하기 위해 우리가 선택한 것들

I’m happy to translate the article for you, but I need the full text of the post (the portion you’d like translated). Could you please paste the content you want translated here? Once I have it, I’ll keep the source line exactly as you specified and provide the Korean translation while preserving all formatting, markdown, and code blocks.

들어가며 : Agentic Search 시스템 구축기

회사 안에서 만들어지는 정보는 생각보다 훨씬 다양한 형태로 흩어져 있습니다. 어떤 데이터는 DB에 정리되어 있고, 어떤 데이터는 문서로 남아있으며, 또 어떤 데이터는 이미지나 첨부파일처럼 검색하기 까다로운 형태로 존재합니다.

문제는 데이터가 다양해진데 반해, 데이터를 찾는 방식은 여전히 예전 방식에 머물러 있다는 점입니다.

• DB는 컬럼 조건을 일일이 조합해 찾아야 합니다.
• 문서 검색은 키워드 기반이나 맥락이 결여된 임베딩 검색에 의존합니다.
• 사내 지식은 복수 모달로 구성되기 때문에 검색 난이도는 체감상 기하급수적으로 증가합니다.

LLM이 등장하면서 검색 환경 전반에 많은 변화를 만들었습니다. RAG 기반 접근이 빠르게 확산되었고, 사내 지식에 AI 기반 검색 요구도 자연스럽게 늘어났습니다.

저희 팀도 RAG, GraphRAG, Pipeline RAG 등 여러 방식을 시도해보았고 결국 한 가지 결론에 도달했습니다.

다양한 도메인과 다양한 모달, 여러 리소스를 하나의 흐름으로 안정적으로 엮어 검색·조합하려면 결국 Agentic Search 구조가 필요합니다.

본 글에서는 Agentic Search 시스템을 설계하고 구축하며 특히 중요했던 포인트를 공유하고자 합니다.

Agent Flow: Chat을 DAG로 바라보기

Agent는 흔히 ReAct 패턴처럼 LLM이 Tool을 호출하며 문제를 해결하는 구조로 설명됩니다. 이를 시스템으로 확장하면 관점이 달라집니다. 더 이상 단순한 순차적인 LLM 호출이 아니라 전체적인 실행 흐름을 DAG (Directed Acyclic Graph) 로 해석하는 것이 자연스러워지며, 하나의 DAG 안에서 Agent의 Context를 어떻게 관리하고 정제해 나갈지가 핵심 요소가 됩니다.

Agent Flow를 설계할 때는 다음과 같이 접근합니다.

1. 해결해야 할 Task를 Sub Task로 분해한다.
2. 각 Sub Task를 어떤 Node에서 처리할지 결정한다.
3. Node를 어떤 순서와 조건으로 연결할지 설계한다.

Node의 granularity는 전체적인 성능을 좌우합니다. 지나치게 세분화하면 Node 간 Hop과 LLM 호출이 증가해 비용과 Latency가 상승합니다. 반대로 Node가 과도한 책임을 가지면 내부 로직 제어와 디버깅, 품질 관리가 어려워집니다.

예를 들어 Figure 1처럼 사용자 질문 분석을 단계별 Node로 세분화하면 기능적으로 명확해지지만 정책 결정과 제어 흐름의 관리 지점이 여러 곳으로 분산되어 코드 복잡성이 증가하고, 각 단계의 LLM 호출로 인해 Latency와 Cost가 증가합니다.

따라서 이러한 부분을 CoT (Chain‑of‑Thought) 기반의 단일 Reasoning 흐름으로 통합할 수 있는지 검토했으며, 결론적으로 “쪼개기가 답이 아니라, 쪼갠 Sub Task 중 일부를 프롬프트로 묶어 효율화”하는 Figure 2와 같은 설계가 필요하다는 판단에 이르렀습니다.

Figure 1. High Granularity Node Design
(이미지 없음 – 설명용 자리표시)

Figure 2. CoT Based Low Granularity Node Design
(이미지 없음 – 설명용 자리표시)

Tool 설계 : Agentic 시스템의 핵심

Flow 설계에 이어 성능에 큰 영향을 미치는 요소가 Tool 설계입니다. 검색 시스템 관점에서 Tool은 보통 다음 세 가지로 구분됩니다.

• Context Handling Tool
• User Interaction Tool
• Resource Tool

Agent 시스템에서 Tool은 단순한 함수 호출이 아니라 검색 전략을 실행하는 단위이며, 사용자 경험까지 결정하는 요소입니다.

1. Context Handling Tool

Context를 잘 구성하는 것은 Agent가 검색 전략을 수립하고 문서를 이해하는 데 핵심입니다. 저희는 초기 Context에 사용자의 메타 정보, 검색 전략, 그리고 검색 대상 Space에 대한 정보를 넣었습니다.

Figure 3. 초기 Context 구성
(이미지 없음 – 설명용 자리표시)

Agent 실행 중에는 Tool의 결과를 구조화해서 넘겨주어야 하며, Context가 LLM의 Context Size를 초과하면 축약도 해야 합니다. 특히 문서 검색 Agent의 경우 불필요한 부분이 Context에 포함돼 LLM의 Context가 불필요하게 커질 수 있습니다. 이를 방지하기 위해 검색된 문서를 분석하는 Tool을 추가했으며, 문서 Chunking 최적화를 전처리 단계에서 수행해 기존 Context를 기반으로 SLM이 문서를 분석하도록 만들었습니다.

Figure 4. Context Handling
(이미지 없음 – 설명용 자리표시)

2. User Interaction Tool

기존 AI 시스템은 대부분 텍스트 기반 Q&A에 머물러 있습니다. 그러나 Agentic Search에서 Interaction Tool은 의미가 완전히 달라집니다. Agent가 UI 요소를 직접 호출해 사용자 행동을 유도하고 선택지를 제시하거나 강제하며 입력을 검증할 수 있습니다.

예를 들어 Agent가 Tool Calling을 통해 아래와 같은 Custom HTML을 프론트엔드(FE)로 보낸다고 가정합니다.

Figure 5. Custom HTML Tag
(이미지 없음 – 설명용 자리표시)

FE는 해당 Custom Tag를 사전에 정의된 Component로 치환해 UI에 표시할 수 있습니다. 이렇게 되면 Agent는 단순 텍스트 생성기가 아니라 사용자 상호작용까지 포함한 전체 의사결정 흐름을 제어하는 실행 주체가 됩니다.

3. Resource Tool

검색 시스템에서는 다양한 자원에 대한 접근이 필요합니다. 많은 시스템이 MCP 형태로 자원 접근을 지원합니다. 저희는 핵심 자원에 대한 검색 Tool을 내부적으로 구현하고, 인터페이스는 MCP 기반으로 구성했습니다. 이렇게 하면 다른 MCP 서버가 추가될 때도 Agent가 원활하게 Resource Tool을 호출할 수 있습니다.

Tool은 시스템의 Context 관리, UX 연계, 검색 Resource 접근 등 성능에 직접적인 영향을 미치는 요소이며, backbone LLM 모델이 바뀌어도 강건한 Agent System을 유지하는 데 핵심이었습니다.

Agent Runtime: LangGraph 기반으로 구현한 이유

Tool을 정의하고 Flow를 설계하면 이를 구현해 서버에서 동작하도록 해야 합니다. 실제 Agent 실행 방식은 Chat보다 DAG 형태에 가깝기 때문에 서버도 State Machine 형태의 프레임워크를 기반으로 구현되어야 합니다. Agent Runtime은 일반적으로 다음과 같은 특성을 가집니다.

• 여러 비동기 작업이 순차 또는 병렬로 실행됩니다.
• 각 Step의 상태가 누적되며 수렴합니다.
• Node 단위 실행이라는 점에서 Event‑Driven DAG 실행 모델과 유사합니다.

이러한 구조를 안정적으로 운영하기 위해 저희는 LangGraph를 선택했습니다.

LangGraph를 선택한 주요 이유

• Pregel 기반 Graph Runtime이라 recursive 작업이나 multi‑turn 확장이 용이합니다.
• Worker 기반 실행으로 scale‑out 가능한 배치 시스템 구축이 가능합니다.
• Node의 Callback 함수를 활용해 Node 단위 로깅 및 Traceability를 위한 Langfuse 연계가 쉽습니다.

결론적으로 LangGraph는 저희가 구축하고자 했던 Agent Runtime의 성격과 가장 잘 부합했으며, 운영에 필수적인 모니터링 연계가 용이했기에 선택하게 되었습니다.

마무리하며

저희가 사내 검색 시스템에 Agentic Search를 도입하기로 결정한 이유는 단순히 “LLM이 유행이라서”가 아닙니다.

삼성전자 내부 지식은 다양한 직군·사업부·복잡한 비즈니스 상황 속에서 만들어집니다. 따라서 사내 검색 엔진은 다양한 상황에 유연하게 대응하면서 동시에 임직원 업무에 특화되어야 합니다. 이 두 가지를 동시에 만족시키기 위해서는 RDB 기반 검색이나 단순 Naïve RAG만으로는 한계가 명확했습니다.

다양한 모달·리소스·복잡한 검색 시나리오를 처리하려면 Document Understanding과 Context Engineering을 기반으로 한 Agentic Search System이 필요합니다.

이번 구축 경험은 Agent 시스템 설계의 기본기를 다시 다지는 계기가 되었으며, 향후 더 다양한 사내 도메인에 대응할 수 있도록 검색 Agent를 지속적으로 고도화할 계획입니다.

사내 지식은 매우 복잡하고 유기적으로 얽혀 있습니다. 이 난제를 풀어 나가는 핵심은 비즈니스 도메인 기반 Context Engineering 그리고 이를 반영할 수 있는 Agentic Search System이라고 생각합니다.