- 에이전트 AI
GenAI는 텍스트나 코드 같은 콘텐츠를 생성하는 데 정말 강력하지만, 실제 워크플로우에서는 사람이 여전히 다음 단계를 계획하고, 도구를 호출하고, 시스템을 업데이트하고, 결과를 확인해야 하죠.
Agentic AI는 해당 실행을 시스템으로 가져오는 거예요. 에이전트 시스템은 단계를 계획하고, 도구를 사용하고, 결과를 관찰하고, 시스템이 목표나 안전한 중지 지점에 도달할 때까지 계속 진행할 수 있어요.
정의는 간단해 보이지만, 실제 시스템에서는 생성적 출력과 목표 완료 사이의 격차가 분명해져요. 실제로 신뢰할 수 있는 다단계 에이전트를 구축할 때 가장 큰 병목 현상은 컨텍스트인데요. 각 단계마다 올바른 데이터, 도구 옵션, 제약 조건 및 메모리가 필요하며 약한 컨텍스트로 인해 드리프트 및 반복 작업이 발생하죠. Agentic AI는 구조화된 출력 및 도구 사용 측면에서 모델이 개선되고, 도구 생태계를 통해 통합이 더 쉬워지며, 팀은 워크플로를 엔드 투 엔드로 완료할 수 있는 자동화를 원하기 때문에 추진력을 얻고 있는 것 같아요.
이 가이드에서는 GenAI와 Agentic AI의 차이점, 어느 것을 사용해야 하는지, GenAI 사용에서 에이전트 시스템 개발로 전환하는 방법을 설명할 거예요.
이 가이드의 추가 내용:
-
- GenAI 작동 방식
-
- GenAI 스위트 스팟
-
- GenAI가 우위를 잃는 곳
-
-
- 시스템을 에이전트로 만드는 것은 무엇일까요?
-
- AI 에이전트와 Agentic AI
-
- AI 에이전트의 핵심 구성요소
-
-
- Agentic AI는 여전히 GenAI에 의존하고 있어요. 그 이유는 다음과 같아요.
-
-
- 다단계 추론의 실패 모드
-
- 복잡한 작업에서 환각 증가
-
- 상호작용 전반에 걸친 메모리 지속성 저하
-
- 벡터 전용 검색의 한계
-
- 실제 워크플로가 GenAI 답변을 넘어 팀을 추진하는 이유
-
-
- 1. 일반적인 문제를 처음부터 끝까지 해결하는 지원 Triage
-
- 2. Runbook을 따르고 복구를 입증하는 사고 대응
-
- 3. 영향을 추적하고 완화를 유발하는 공급망 예외 처리
-
- 4. 증거를 연결하고 사건을 진행시키는 사기 수사
-
- 이러한 사용 사례가 개발자에게 중요한 이유
-
-
- Knowledge Graph가 에이전트 작업에 잘 매핑되는 이유
-
- 에이전트를 위한 장기 기억으로서의 그래프
-
- 실용적인 검색 패턴: 연결된 컨텍스트를 위한 GraphRAG
-
- Agentic AI에 Neo4j를 사용하는 이유
-
-
- AI 애플리케이션의 일반적인 진화 경로
-
- 필요한 건축 사고방식의 변화
-
- 개발자를 위한 실용적인 전환 체크리스트
-
- 팀이 에이전트를 구축할 때 저지르는 실수
-
-
- 필수 GraphRAG
-
- Agentic AI와 Generative AI FAQ
생성 AI란 무엇인가?
Generative AI(GenAI)는 훈련 데이터에서 학습된 패턴을 기반으로 새로운 콘텐츠를 생성할 수 있는 모델을 말해요. 실제로 이 용어는 텍스트, 코드 및 구조화된 출력을 생성하는 LLM(Large Language Model)과 이미지, 오디오 또는 비디오를 생성하는 관련 모델을 가리키는 경우가 많죠.
GenAI 작동 방식
GenAI 애플리케이션은 훈련된 모델을 사용자 프롬프트 및 앱이 제공하는 추가 컨텍스트와 같은 런타임 입력과 결합해요. 아래에서는 개발자가 먼저 이해해야 할 사항, 즉 기본 모델이 무엇인지, 모델이 어떻게 학습되는지, 프로덕션에서 호출하면 어떤 일이 발생하는지 다뤄볼게요.
변압기 및 기초 모델
대부분의 최신 LLM은 Transformer 아키텍처를 기반으로 구축되었어요. Transformer는 모델이 긴 시퀀스에 걸쳐 일관된 출력을 생성할 수 있도록 주의 메커니즘을 사용하여 토큰 간의 관계를 평가합니다. 모델은 의미를 이해하는 대신 학습 데이터에서 학습된 통계 패턴과 런타임에 제공되는 컨텍스트를 사용하여 다음 토큰을 예측하는 거죠.
훈련과 추론
프롬프트 디자인, 검색, 도구 사용, 출력 설정 등 대부분의 생산 제어는 모델이 실행될 때 발생해요. 훈련은 모델의 기본 기능과 한계를 정의하죠. 차이점을 이해하는 것은 모델 동작이 확립되는 시기와 실제 애플리케이션에 적용되는 시기로 귀결돼요.
- 훈련:모델은 대규모 데이터 세트에서 패턴을 학습해요. 훈련 프로세스는 모델의 매개변수를 형성하여 모델이 여러 프롬프트에 걸쳐 일반화될 수 있도록 합니다.
- 추론:모델은 프롬프트와 사용자가 제공하는 추가 컨텍스트를 사용하여 토큰별로 출력 토큰을 생성합니다.
개발자는 일반적으로 프롬프트, 검색된 컨텍스트(RAG), 도구 호출 및 출력 제약 조건을 통해 추론 시 제어권을 갖습니다.
프롬프트-응답 상호작용 모델
일반적인 GenAI 상호작용은 반응적이에요.
- 사용자가 프롬프트를 제공합니다.
- 모델은 응답을 생성합니다.
- 사용자는 후속 조치를 요청하고 선택적으로 더 많은 컨텍스트를 추가합니다.
팀이 검색 기능을 추가하더라도 상호 작용 패턴은 질문, 검색, 답변 등 프롬프트 중심으로 유지되는 경우가 많아요.
GenAI 스위트 스팟
GenAI는 작업이 주로 정보 생성 또는 변환에 관한 것일 때 매우 효과적일 수 있어요.
- 자연어 이해:출력은 인간이나 시스템이 사용하기 전에 검토할 수 있는 텍스트이기 때문에 요약, 번역, 분류 및 추출이 매우 적합합니다.
- 텍스트 및 미디어 생성:문서 초안 작성, 이미지 생성, 1차 통과 템플릿 생성은 특히 생성과 테스트 및 검토를 결합할 때 전달 속도를 높일 수 있어요.
- 임베딩 및 의미 검색:임베딩은 텍스트를 벡터로 변환하므로 의미상 유사한 콘텐츠를 검색할 수 있어요. 이는 Retrieval-Augmented Generation(RAG) 파이프라인의 첫 번째 단계인 경우가 많죠.
GenAI가 우위를 잃는 곳
워크플로에 반복 가능하고 신뢰할 수 있는 실행이 필요할 때 제한 사항이 더욱 뚜렷해져요.
- 무상태 상호작용:언어 모델은 애플리케이션이 상태를 저장하고 다시 주입하지 않는 한 세션 전체에서 메모리를 유지하지 않아요.
- 본질적인 목표나 자율성이 없습니다.신속 대응 모델에는 목표가 없어요. 프롬프트 응답 모델은 다음 프롬프트를 기다립니다.
- :모델이 컨텍스트를 잃거나, 중간 결과를 잘못 처리하거나, 이전 오류가 복합될 수 있기 때문에 다단계 계획이 표류할 수 있어요.
- 접지 부족으로 인한 환각:모델이 신뢰할 수 있는 최신 정보에 대한 액세스가 부족하면 그럴듯하지만 잘못된 세부 정보가 생성될 수 있어요.
- 복잡한 워크플로의 취약성:단계가 증가함에 따라 프롬프트 전용 워크플로에는 불안정한 Prompt Engineering과 수동 예외 처리가 필요한 경우가 많아요.
Agentic AI란 무엇입니까?
Agentic AI를 목표를 추구할 수 있는 소프트웨어라고 생각해 보세요. 단계를 계획하고, 도구를 사용하고, 결과를 관찰하고, 시스템이 목표에 도달하거나 안전한 중지 지점에 도달할 때까지 반복하는 거죠. 메모리, 도구, 그리고 가드레일을 갖춘 더 넓은 실행 시스템 안에서 모델을 사용하는 아키텍처라고 할 수 있어요.
시스템을 Agentic하게 만드는 것은 무엇일까요?
대부분의 구현 시스템은 비슷한 특징을 공유하고 있어요.
- 목표 지향적 행동(Goal-oriented behavior): 시스템은 단순히 응답을 생성하는 대신 결과를 완료하도록 최적화되어 있어요.
- 자율성과 지속성(Autonomy and persistence): 시스템은 정의된 경계 내에서 여러 단계와 시간에 걸쳐 계속 작동할 수 있어요.
- 계획 및 실행(Planning and execution): 시스템은 작업을 여러 단계로 나누고, 도구를 선택하고, 작업을 실행하고, 진행 상황을 추적할 수 있어요.
- 피드백 루프 및 적응(Feedback loop and adaptation): 시스템은 도구 출력 및 변화하는 조건을 기반으로 계획을 업데이트해요.
- 환경과 상태에 대한 인식(Awareness of environment and state): 시스템은 정책, 자격, 인벤토리, 사고 상태 또는 대화 기록과 같은 외부 상태를 통합할 수 있어요.
AI Agent와 Agentic AI
AI Agent가 빌딩 블록이라면, Agentic AI는 하나 이상의 Agent, 도구 및 공유 상태를 조정해서 작업을 안정적으로 완료하는 시스템이라고 할 수 있어요. 실제로 시스템은 도구 권한, 상태 관리, 검색 품질, 중지 조건 등 대부분의 엔지니어링이 발생하는 곳이기도 해요.
AI Agent의 핵심 구성 요소
시스템에서 진단을 실행하고, 티켓을 업데이트하고, 복구를 확인하려면 좋은 프롬프트 이상의 것이 필요해요. 모델이 모든 단계에서 작동하고 일관성을 유지할 수 있도록 함께 작동하는 몇 가지 구체적인 요소들이 필요하죠.
핵심 구성 요소에는 일반적으로 아래 영역이 포함되며, 각 영역은 애플리케이션에서 함께 구현되고 연결돼요.
추론 엔진으로서의 LLM
Agent 시스템 내부의 GenAI 구성 요소인 Large Language Model(LLM)은 목표를 해석하고, 계획을 제안하고, 다음에 사용할 도구를 결정하고, 결과를 다음 작업 또는 최종 출력으로 종합하는 역할을 해요.
실행 도구(Tools for execution)
도구에는 검색 기능, 데이터베이스 쿼리, 티켓팅 작업, 배포 명령 또는 비즈니스 API 등이 포함될 수 있어요. 도구는 언어를 행동으로 바꿔주는 역할을 하죠.
메모리 레이어(Memory layers)
Agent 시스템은 일반적으로 메모리를 두 개 이상의 계층으로 분리해요.
- 단기 기억(작업 기억)(Short-term memory (working memory)): 세션 컨텍스트, 중간 단계, 도구 출력 및 현재 제약 조건
- 장기 기억(지속적 상태)(Long-term memory (persistent state)): 세션 전반에 걸쳐 지속되어야 하는 사용자, 시스템, 작업, 정책 및 결과에 대한 사실
관찰 및 개선(Observing and improving)
프로덕션 Agent에는 일반적으로 도구 호출 기록, 발생한 일 기록, 향후 동작을 개선할 수 있는 결과 캡처 등 관찰 및 피드백을 위한 메커니즘이 필요해요.

Agentic AI와 GenAI: 실제로 중요한 차이점
GenAI를 Agentic AI와 구분하는 가장 빠른 방법은 시스템이 완료하려는 워크플로에서 성공이 무엇을 의미하는지에 초점을 맞추는 거예요. GenAI의 경우 성공이란 좋은 반응을 얻는 것을 의미하는 경우가 많죠. 반면에 Agentic AI에서는 도구와 상태를 사용해서 안전하게 목표를 완료하는 것이 중요해요.
| Agentic AI | ||
| 기본 출력 | 콘텐츠(텍스트, 코드, 요약) | 목표 완료(행동 + 결과) |
| 상호작용 패턴 | 반응형 프롬프트 응답 | 계획 및 후속 조치가 포함된 목표 중심 루프 |
| 상태 | 앱이 메모리를 추가하지 않는 한 일반적으로 상태 비저장 | Stateful 설계(공유 상태와 메모리가 중심) |
| 추리 | 종종 단일 단계 또는 느슨하게 다단계 | 점검과 반복을 통한 명시적인 다단계 계획 |
| 도구 사용 | 선택사항이며 제한적인 경우가 많음 | 필수적인; 도구는 정상 작동의 일부입니다 |
사용할 접근 방식을 결정하는 방법: 마지막 단계가 콘텐츠인 경우 GenAI를 사용하세요. 마지막 단계가 시스템의 상태 변경인 경우 Agent AI를 사용합니다.
다음은 몇 가지 예시예요.
- GenAI: 지원 답변 초안 작성, 사후 분석 요약, SQL 쿼리 템플릿 생성
- Agent AI: 티켓을 열고 업데이트하고, 진단을 실행하고, 안전한 교정 단계를 적용하고, 시스템이 복구되었는지 확인하세요.
Agentic AI는 여전히 GenAI에 의존하고 있어요. 그 이유는 다음과 같아요.
대부분의 에이전트 시스템은 여전히 시스템 내부에서 GenAI를 사용하거든요.
- LLM은 사용자 의도와 중간 결과를 해석해요.
- LLM은 계획, 도구 호출 및 구조화된 출력을 생성하죠.
- LLM은 인간에 대한 결과를 요약해줘요.
Agentic AI는 GenAI를 기반으로 구축된 다음 목표 실행을 가능하게 하는 시스템 요소를 추가하는 방식이에요.
Agentic AI에는 단순한 프롬프트가 아닌 오케스트레이션이 필요해요.
프롬프트는 워크플로우를 설명할 수 있지만 여러 단계에서 상태 전환, 도구 순서 지정, 가드레일, 재시도 또는 중지 조건을 안정적으로 적용할 수는 없어요. 오케스트레이션은 책임을 분리해서 이러한 문제를 해결하죠.
- 오케스트레이션 계층은 단계를 라우팅하고 진행 상황을 추적하며 제약 조건을 적용해요.
- 메모리 계층은 내구성 있는 상태와 중간 결과를 저장하고요.
- 도구 계층은 작업을 실행하고 접지된 출력을 반환해요.

GenAI가 실제 워크플로우에서 벽에 부딪히는 곳
간단한 프롬프트 및 응답 데모가 설득력 있는 결과를 생성하고 가치를 입증하는 빠른 방법이기 때문에 많은 팀이 프롬프트 기반 부조종사로 시작해요. 하지만 생산 워크플로우에는 프롬프트 전용 시스템이 제대로 처리하지 못하는 조건이 생기게 되죠.
다단계 추론의 실패 모드
다단계 작업으로 인해 복합적인 위험이 발생해요.
- 각 단계는 이전 단계의 정확성에 따라 달라지죠.
- 각 단계에는 이전 제약 조건을 몰아낼 수 있는 새로운 컨텍스트가 도입돼요.
- 각 도구 출력은 오해되거나 잘못 적용될 수 있고요.
에이전트 루프는 시스템이 중간 출력을 확인하고, 불일치를 감지하고, 경로를 수정할 수 있기 때문에 도움이 된답니다.
복잡한 작업에서 환각 증가
워크플로우가 여러 작업에 걸쳐 있으면 환각을 포착하기가 더 어려워요. 워크플로우 초기에 잘못된 가정이 다운스트림 도구 호출 및 최종 출력에 영향을 미칠 수 있죠. 접지된 검색 및 내구성 있는 상태는 이러한 위험을 줄여준답니다.
상호작용 전반에 걸친 메모리 지속성 저하
대부분의 의미 있는 작업에는 연속성이 필요해요.
- 고객 문제는 세션 전반에 걸쳐 미해결 상태로 유지되죠.
- 사건 조사는 새로운 증거가 도착함에 따라 발전하고요.
- 조달 워크플로우에는 승인, 정책 및 공급업체 제약 사항이 포함돼요.
상태 비저장 채팅 기록은 내구성이 뛰어난 메모리 시스템이 아니에요. 내구성 있는 메모리에는 에이전트가 쿼리할 수 있는 저장 및 구조화된 검색이 필요하답니다.
벡터 전용 검색의 한계
벡터 검색은 의미상 유사한 텍스트를 찾는 데 유용해요. 벡터 전용 RAG는 분리된 텍스트 조각을 검색하는 경우가 많으며 해당 조각을 연결하는 컨텍스트를 놓칠 수 있어요. 이는 다중 홉 질문을 더 어렵게 만들고 벡터 검색이 특정 청크가 선택된 이유를 자연스럽게 표시하지 않기 때문에 설명 가능성을 줄일 수 있죠.

실제 워크플로가 GenAI 답변을 넘어 팀을 추진하는 이유
실제 시스템에서는 올바른 설명이 최종 목표가 아니에요. 시스템은 종종 다음 단계를 선택하고, 도구를 통해 이를 적용하고, 정책 및 권한 제약 조건에 따라 결과를 확인해야 하죠. 이것이 바로 팀이 생성 보조자에서 오케스트레이션, 도구 사용 및 내구성 상태를 갖춘 에이전트 워크플로로 전환하는 이유랍니다.
또한 워크플로는 서비스 소유권, 종속성, 자격, 변경 기록 등 여러 단계에서 일관성을 유지해야 하는 사실에 따라 달라져요. 해당 상태가 누락되거나 검색하기 어려운 경우 시스템이 표류하거나 작업을 반복하거나 잘못된 조치를 취하게 될 수 있어요.
다음을 추가하여 프롬프트 전용 동작을 뛰어넘어 보세요.
- 작업을 시스템이 확인할 수 있는 작업으로 나누는 계획 단계
- 안전 규칙에 따라 허가, 기록 및 제한되는 도구 호출
- 여러 단계에 걸쳐 작업, 결정, 결과를 위한 내구성 있는 상태 레이어
Agentic AI 시스템의 4가지 실제 사용 사례
에이전트 AI를 구체적으로 만드는 가장 쉬운 방법은 시스템이 작업을 설명하기만 하는 것이 아니라 실제로 작업을 수행해야 하는 워크플로를 살펴보는 거예요. 아래 각 예에서 시스템은 기록 시스템에서 입력을 가져오고, 상태를 변경할 수 있는 도구를 사용하고, 워크플로가 완료되었는지 또는 에스컬레이션이 필요한지 확인해요.
1. 일반적인 문제를 처음부터 끝까지 해결하는 지원 분류
시스템이 답변 초안만 작성하는 대신 사례를 진행할 수 있으면 지원 워크플로가 에이전트가 되죠. 실제적인 예로는 고객 상황을 파악하고, 자격을 확인하고, 알려진 수정 사항이나 정책을 적용하고, 다음 사람이 동일한 확인을 반복하지 않도록 티켓을 업데이트하는 것을 들 수 있어요.
일반적인 도구 및 데이터 소스:
- 고객 프로필 및 요금제 세부정보를 위한 CRM
- 정책 및 알려진 문제에 대한 기술 자료
- 상태, 소유자, 내역에 대한 티켓팅 시스템
- 환불 및 교체를 위한 청구 또는 주문 관리
완료 확인:
- 티켓 상태는 작업의 실제 상태를 반영합니다.
- 해결 요약이 케이스에 저장됩니다.
- 해당되는 경우 필수 다운스트림 작업이 시작됩니다.
2. Runbook을 따르고 복구를 입증하는 사고 대응
시스템이 신호를 연관시키고, 다음 안전한 단계를 결정하고, 조치를 취하고, 서비스가 안정될 때까지 계속 확인할 수 있을 때 사고 대응은 능동적이 돼요. 일반적인 패턴은 원격 분석을 수집하고, 경고를 소유 서비스 및 종속성에 매핑하고, 범위가 지정된 수정 단계를 실행하고, 신호를 다시 확인하여 복구를 확인하는 것이죠.
일반적인 도구 및 데이터 소스:
- 로그, 추적, 측정항목에 대한 관측 시스템
- 소유권 및 종속성을 위한 서비스 카탈로그 또는 구성 관리 데이터베이스(CMDB)
- 안전한 운영 작업을 위한 Runbook 자동화
- 배정 및 에스컬레이션을 위한 티켓 라우팅
완료 확인:
- 심각도와 소유권이 올바르게 설정되었습니다.
- 감사 및 사후 조사를 위해 증거와 조치가 기록됩니다.
- 복구 신호가 확인되거나 케이스가 에스컬레이션됩니다.
3. 영향을 추적하고 완화를 유발하는 공급망 예외 처리
시스템이 중단 신호를 감지하고 제품, 지역 및 약속 전반에 미치는 영향을 추적할 수 있을 때 공급망 워크플로우는 능동적이 되죠. 목표는 주문 경로 변경, 대체 공급업체 소싱, 승인 요청 생성 등 시스템에서 시작할 수 있는 완화 경로에요.
일반적인 도구 및 데이터 소스:
- 재고, 주문, 약정을 위한 ERP 및 재고
- 위험 신호 및 상태 변경에 대한 공급업체 피드
- 소싱 및 승인을 위한 조달 워크플로
- 라우팅 및 이행 옵션을 위한 물류 시스템
완료 확인:
- Impact Map이 생성되어 저장됩니다.
- 완화 옵션에는 장단점과 제약 조건이 포함됩니다.
- 작업이 시작되거나 승인 요청이 생성됩니다.
4. 증거를 연결하고 사건을 진행시키는 사기 수사
사기 워크플로는 시스템이 여러 개체에 걸쳐 증거를 수집하고, 의심스러운 관계를 연결하고, 사건을 명확한 다음 단계로 이끌 수 있을 때 능동적이 되죠. 다음 단계는 조사관에게 에스컬레이션하거나, 단계적 확인을 요청하거나, 정책 임계값이 충족되면 거래를 동결하는 것일 수 있어요.
일반적인 도구 및 데이터 소스:
- 행동 신호에 대한 거래 및 이벤트 데이터
- 사용자 및 장치 확인을 위한 신원 확인
- 증거 수집 및 워크플로우 상태에 대한 사례 관리
- 고객 연락 및 경고를 위한 알림 시스템
완료 확인:
- 증거 추적은 지원 컨텍스트와 함께 저장됩니다.
- 위험 평가는 정책 임계값에 맞춰 조정됩니다.
- 다음 조치는 감사 친화적인 근거와 함께 기록됩니다.
이러한 사용 사례가 개발자에게 중요한 이유
이러한 워크플로우는 에이전트 데모가 시스템이 호출할 수 있는 도구, 단계 간에 지속되어야 하는 상태, "완료"로 간주되는 사항, 시스템이 중지되어 사람에게 전달되어야 하는 시점 등의 설계 질문을 피하도록 만들어요.
답변이 프로덕션의 신뢰성과 안전성을 결정하기 때문에 명확한 답변을 얻는 것이 중요해요. 이는 시스템이 수행할 수 있는 작업, 시스템이 반복 작업이나 모순을 방지하는 방법, 시스템이 작은 실수를 연쇄 실패로 전환하는 것을 방지하는 방법을 정의하죠.
Knowledge Graph가 Agentic AI를 강화하는 방법
에이전트 워크플로우는 모델이 좋은 응답을 작성할 수 없기 때문에 실패하는 것이 아니에요. 작업이 도구와 시간에 걸쳐 전개될 때 시스템이 올바른 컨텍스트, 제약 조건 및 기록을 사용할 수 없기 때문에 실패하는 거죠. 컨텍스트는 에이전트의 신뢰성을 높이는 데 중요한 요소랍니다.
실제로 에이전트에는 시간에 따른 결정을 지원하는 컨텍스트가 필요해요.
- 안정적으로 유지되는 엔터티 (사용자, 서비스, 제품, 정책)
- 제약 조건 (소유권, 종속성, 액세스, 승인)을 유발하는 관계
- 결정 (취한 조치, 결과)을 설명하는 이력
- 세션 전반에 걸쳐 지속되는 상태 (미결 작업, 에스컬레이션, 기본 설정)
프롬프트 창은 연결된 상태를 저장하고 쿼리하도록 설계되지 않았어요. 시스템이 구조화되지 않은 텍스트에만 의존하는 경우 모델은 관계를 추론하고 누락된 세부 정보를 채워야 하죠.

Knowledge Graph가 에이전트 작업에 잘 매핑되는 이유
Knowledge Graph는 엔터티와 그 관계를 구조적으로 표현한 것이에요. 이는 시스템이 연결된 사실을 검색하고 이러한 사실이 어떻게 관련되어 있는지 보여줄 수 있기 때문에 에이전트 루프를 보다 안정적이고 감사하기 쉽게 만드는 엔터티, 관계 및 계보의 공유 맵 역할을 하죠.
Knowledge Graph는 다음과 같은 구체적인 방법으로 도움이 된답니다.
- 관계는 명시적이에요. 유사성 검색이 두 항목을 모두 검색하고 모델이 종속성을 추론하기를 바라는 대신 그래프는 "서비스 A가 서비스 B에 의존함"을 직접 나타낼 수 있어요.
- 다중 홉 검색이 자연스러워져요. 상담원은 "고객의 서비스 자격, 배포, 사고"와 같은 "링크를 따라가는" 컨텍스트가 필요한 경우가 많아요. 그래프 순회는 해당 패턴을 지원하죠.
- 시스템은 다음과 같이 작업 내용을 표시할 수 있어요. 그래프 검색은 관련 엔터티와 이를 연결하는 경로를 반환할 수 있으며 이는 디버깅 및 감사를 지원해요.
- 가드레일은 데이터 영역에 있을 수 있어요. 그래프 저장소가 역할 기반 액세스 제어를 지원하는 경우 에이전트는 해당 권한과 일치하는 데이터 및 작업으로 제한될 수 있어요.
관계가 답을 바꾸는 구체적인 예
간단해 보이지만 연결된 맥락이 필요한 질문을 생각해 보세요. "이 서비스 중단이 특정 사용자 그룹의 최근 로그인 시스템 변경과 관련이 있을 수 있습니까?"
신뢰할 수 있는 응답을 위해 시스템은 고객, 자격, 서비스, 배포 및 사고를 연결해야 해요. 그것은 관계 문제죠. Knowledge Graph는 계보 및 정책과 함께 이러한 연결을 저장할 수 있으므로 검색에서는 사실을 사용 가능하게 만드는 컨텍스트와 함께 사실을 반환한답니다.
에이전트를 위한 장기 기억으로서의 그래프
Knowledge Graph는 실시간으로 작업이 변경되고 데이터가 업데이트됨에 따라 진화하는 컨텍스트 레이어 역할을 할 수 있어요. 세상이 변하더라도 장기 기억은 여전히 의문의 여지가 없죠.
내구성이 뛰어나고 쿼리 가능한 에이전트 메모리의 예:
- 지속적인 사용자 기본 설정 및 권한
- 작업 상태 및 결과
- 시행해야 하는 정책 및 제약사항
- 결정이 내려진 이유를 설명하는 엔터티 기록
실용적인 검색 패턴: 연결된 컨텍스트를 위한 GraphRAG
유사한 텍스트뿐만 아니라 연결된 컨텍스트까지 반환하면 검색 성능이 훨씬 좋아져요. GraphRAG는 Knowledge Graph를 사용해서 초기 일치에서 관련 이웃과 관계로 확장하는 방식으로 이걸 가능하게 하죠.
에이전트에게는 서비스 소유자, 변경 사항이 발생한 배포, 영향을 받는 고객, 다음 작업을 제한하는 정책을 연결하는 컨텍스트가 필요한 경우가 많아요. GraphRAG는 관련 구절뿐만 아니라 해당 구절을 워크플로우에서 사용할 수 있게 만드는 관계까지 검색해서 도움을 준답니다.
실용적인 GraphRAG 루프는 보통 이런 순서로 진행돼요:
- Vector Embedding을 사용해서 시작점(문서 청크 또는 엔터티)을 찾아요.
- 관계를 탐색해서 연결된 사실, 제약 조건, 이웃을 수집해요.
- 구절과 관계 맥락을 포함하는 기반 컨텍스트를 반환해요.
- 검색된 증거를 참조하는 답변을 생성해요.
GraphRAG 파이프라인은 시스템이 각 출력을 지원하는 검색 경로를 표시할 수 있기 때문에 다단계 드리프트를 줄이고 디버깅을 더 쉽게 만들어 준답니다.

Agentic AI에 Neo4j를 사용하는 이유
개발자 입장에서 보면, 목표는 에이전트용 데이터베이스를 만드는 게 아니라 구조화된 컨텍스트와 메모리 백본 에이전트가 쿼리하고, 발전하고, 재사용할 수 있도록 하는 거예요. Neo4j의 AuraDB 엔터프라이즈 에디션은 거버넌스 및 감사 가능성을 지원할 수 있는 세분화된 액세스 제어 및 운영 로깅을 추가해줘요. 에이전트가 조치를 취할 수 있을 때 특히 중요하죠.
실제로 이건 이런 의미를 가져요:
- 의사결정에 중요한 엔터티 및 관계의 그래프 기반 모델링
- 연결된 컨텍스트 검색을 위한 빠른 multi-hop 탐색
- Vector Search와 관계 기반 확장을 결합한 GraphRAG 패턴
- 설명 가능성, 감사, 액세스 제어를 지원하는 데이터 계층
GenAI에서 Agentic AI로 전환하는 방법
프롬프트 기반 앱에서 에이전트 워크플로로의 이동은 보통 단계적으로 이루어져요. 아래 섹션에서는 시스템을 취약한 프롬프트 엉킴으로 만들지 않고도 검색, 도구, 메모리를 추가할 수 있는 실용적인 경로를 제시할게요.
AI 애플리케이션의 일반적인 진화 경로
많은 팀이 다음과 같은 패턴을 통해 발전하죠:
- 프롬프트 기반 LLM 애플리케이션
프롬프트, 응답, 약간의 Prompt Engineering으로 시작해요.
초안 작성, 요약, 내부 부조종사, 위험도가 낮은 텍스트 작업 흐름에 적합하죠. - Retrieval-Augmented Generation (RAG)
모델이 데이터를 기반으로 응답할 수 있도록 검색 기능을 추가해요.
기초 지식이 필요한 문서, Q&A, 정책 보조자, 지원 채팅에 적합해요. - GraphRAG (Knowledge Graph 기반 RAG)
시스템이 multi-hop 질문에 답하고 증거를 추적할 수 있도록 구조화된 검색과 연결된 컨텍스트를 추가해요.
종속성, 자격, 소유권, 계보, 근본 원인, 거버넌스 등 관계에 의존하는 워크플로에 적합하죠. - 도구를 사용하는 에이전트
도구 사용, 도구 선택, 조치를 취할 수 있는 루프를 추가해요.
API를 호출하고, 확인을 실행하고, 티켓을 업데이트하고, 작업을 수행하는 자동화에 적합해요. - 목표 중심 에이전트 시스템
공유 목표와 공유 상태를 중심으로 여러 도구, 때로는 여러 에이전트를 조정해요.
계획, 후속 조치, 반복성이 필요한 엔드투엔드 워크플로에 적합하답니다.

필요한 건축 사고방식의 변화
에이전트 워크플로로의 전환은 더 나은 프롬프트 작성보다는 시스템 설계에 관한 것이에요. 아래 하위 섹션에서는 시스템이 조치를 취하고 시간이 지남에 따라 일관성을 유지해야 할 때 변경해야 할 사항을 강조하고 있어요.
- 프롬프트에서 시스템까지: 프로덕션 에이전트 시스템에는 오케스트레이션, 도구, 메모리, 가드레일 및 평가를 포함한 명시적인 구성 요소가 필요해요.
- 출력에서 결과까지: 유용한 응답은 완료된 워크플로와는 다르죠. 결과 중심 설계에는 완료 시점 확인, 재시도 및 안전 중지와 같은 성공 기준이 필요해요.
- 상태 비저장 아키텍처에서 상태 저장 아키텍처까지: 상태 저장 디자인에는 내구성 있는 메모리와 구조화된 검색이 필요해요. 해당 상태는 에이전트가 읽고 쓰는 Knowledge Graph에 존재할 수 있어요.
개발자를 위한 실용적인 전환 체크리스트
에이전트 데모에서 에이전트 시스템으로 이동하려면 이 체크리스트를 사용해 보세요.
- 명확한 경계가 있는 워크플로를 하나 선택하세요. 시작 신호, 중지 조건 및 안전한 에스컬레이션 경로를 정의하는 거예요.
- 프롬프트를 작성하기 전에 도구 및 권한을 정의하십시오. 에이전트가 호출할 수 있는 API와 사람의 승인 단계가 필요한 작업을 결정해야 해요.
- 명시적으로 메모리를 설계합니다. 작업 메모리(세션)를 장기 메모리(내구성 상태)와 분리하세요. `쿼리`, 감사, 업데이트할 수 있는 형식으로 지속성 상태를 저장하는 거죠.
- 관계가 중요한 곳에 구조화된 검색을 추가합니다. 워크플로가 종속성, 계보, 소유권 또는 정책 제약 조건에 따라 달라지는 경우 Knowledge Graph 및 GraphRAG 패턴을 추가하세요.
- 모든 것을 계측하세요: 팀이 동작을 디버그하고 평가할 수 있도록 프롬프트, 도구 호출, 도구 출력 및 상태 변경을 기록하는 것이 중요해요.
- 작업 수준에서 동작을 평가합니다. 작업 완료, 오류 복구, 접지 품질 및 안전 준수를 측정해야겠죠?
팀이 에이전트를 구축할 때 저지르는 실수
에이전트 프로젝트는 일반적으로 동일한 함정에 직면하게 돼요. 특히 팀이 Prompt Engineering만으로 시스템 문제를 해결하려고 할 때 더욱 그렇답니다.
즉각적인 조정에 대한 과도한 의존
무슨 일이 일어나는지: 프롬프트가 깨지기 쉽고 유지 관리가 어려워질 때까지 프롬프트가 점점 커지는 거예요.
대신 수행할 작업: 제약 조건, 상태 및 정책을 구조화된 데이터 및 검색으로 이동하세요. 현재 단계에 초점을 맞춰 프롬프트를 유지하는 게 좋겠죠?
상담원을 챗봇처럼 대하기
무슨 일이 일어나는지: 시스템은 단계에 대해 말할 수 있지만 단계를 실행하지는 않아요.
대신 수행할 작업: 도구 계약, 성공 기준 및 도구를 사용하고 결과를 확인하고 안전하게 중지하는 루프를 정의해야 해요.
메모리 및 컨텍스트 디자인 무시
무슨 일이 일어나는가: 시스템은 이전 결정을 잊어버리고 작업을 반복하거나 스스로 모순되는 상황이 발생해요.
대신 수행할 작업: 엔터티, `관계` 및 결과에 대한 내구성 있는 저장소를 사용하여 메모리를 아키텍처의 최고 수준 부분으로 취급해야 해요.
Neo4j의 컨텍스트 엔지니어링 가이드는 각 단계에서 필요한 컨텍스트 에이전트를 설계, 저장 및 검색하는 실제 기술을 다루고 있어요.
답을 넘어 AI를 유용하게 만드세요
GenAI는 강력한 기반 레이어에요. 작성하고, 요약하고, 번역하고, 개발자가 더 빠르게 움직일 수 있도록 도와주죠. Agentic AI는 AI 시스템이 작업을 완료하고, 단계를 계획하고, 도구를 사용하고, 상태를 추적하고, 시스템이 목표에 도달할 때까지 반복하도록 하는 실행 계층이라고 할 수 있어요.
신뢰할 수 있는 에이전트 행동의 주요 차별화 요소는 에이전트가 올바른 사실, `관계`에 대한 이유를 검색하고 시스템이 조치를 취한 이유를 설명하는 데 도움이 되는 구조화된 컨텍스트에요. Knowledge Graph와 GraphRAG 패턴은 구조화된 컨텍스트와 내구성 있는 메모리를 제공하는 실용적인 방법이랍니다.
개발자에게 다음 단계는 더 큰 프롬프트가 아니라 데이터를 연결되고 사용 가능한 컨텍스트로 바꾸는 Knowledge Graph를 통해 오케스트레이션, 도구 및 메모리를 시스템의 최고 수준 부분으로 처리하는 아키텍처에요.
필수 GraphRAG
Knowledge Graph를 통해 RAG의 잠재력을 최대한 활용하세요. Manning의 최종 가이드를 무료로 받아보세요!
Agentic AI vs Generative AI FAQ
Generative AI는 프롬프트에 응답해서 콘텐츠를 생성하는 데 집중해요. 반면에 Agentic AI는 목표 달성에 집중하는데, 단계를 계획하고, 도구를 사용하고, 결과를 확인하면서 완료될 때까지 (혹은 안전하게 멈출 때까지) 계속 반복하는 루프를 거치죠.
쉽게 말해, 주요 업무가 정보를 생성하거나 변환하는 거라면 GenAI를 사용하고, 작업에 도구, 상태, 그리고 여러 단계 실행에 대한 후속 조치가 필요하다면 Agentic AI를 사용하면 돼요.
ChatGPT는 핵심 동작이 프롬프트에 응답해서 결과를 생성하는 것이기 때문에 기본적으로 GenAI 인터페이스라고 할 수 있어요.
하지만 팀에서 도구 액세스, 오케스트레이션, 그리고 지속적인 메모리 같은 기능을 추가해서 ChatGPT 클래스 모델을 에이전트 시스템에 통합할 수도 있어요. 중요한 건 모델 자체뿐만 아니라 주변 시스템 디자인도 중요하다는 점이죠.
일반적인 교육 프레임워크에서는 정교함에 따라 AI를 네 가지 유형으로 설명하는데요.
• Reactive Machines: 메모리 없이 입력에 즉각적으로 반응하는 시스템이에요.
• Limited Memory: 의사 결정을 개선하기 위해 과거 데이터나 최근 기록을 활용하는 시스템이죠.
• Theory of Mind: 신념과 의도를 모델링할 수 있는 미래형 시스템을 제안해요.
• Self-Aware AI: 자기 인식을 갖춘 가상의 미래 시스템이라고 할 수 있겠네요.
현재 대부분의 프로덕션 AI 시스템은 처음 두 가지 범주에 속한답니다.
Agent AI의 예시를 한번 살펴볼까요?
• 문제를 진단하고, 계정 작업을 실행하고, 티켓을 종료할 수 있는 고객 지원 시스템
• 로그를 연관시키고, 티켓을 생성하고, 안전한 문제 해결 단계를 실행하는 사고 대응 에이전트
• 수정 사항을 제안하고, 테스트를 실행하고, 검토를 위해 풀 요청을 열 수 있는 코딩 에이전트
Agentic AI 예제는 도구, 메모리, 정의된 결과를 향해 나아가는 실행 루프라는 동일한 패턴을 공유해요.
에이치시스템즈의 LogTree는 Neo4j 기반 GraphRAG 플랫폼으로, 데이터를 자동으로 지식그래프화하고 자연어 질의로 즉시 답을 제공합니다.
'Agent AI' 카테고리의 다른 글
| 실제 프로덕션에서 효과적인 AI 에이전트 활용 사례 연구 (0) | 2026.04.03 |
|---|---|
| Neo4j 에이전트 기반 멀티 유저 던전 만들기 (0) | 2026.04.03 |
| 외부 MCP 제공업체와 Neo4j를 활용한 에이전트 기반 그래프 분석 (0) | 2026.04.03 |
| 에이전트 기반 AI 아키텍처란 무엇일까요? 일반적인 패턴과 활용 시점 (1) | 2026.04.02 |
| Java와 Neo4j로 구현하는 에이전트 기반 AI (0) | 2026.04.02 |