저는 논문을 읽고, 무언가를 만들고, 실제로 제품을 출시하는 엔지니어들과 대화하며 AI 분야에서 많은 시간을 보냅니다. 그리고 데모가 보여주는 모습과 실제 프로덕션 시스템(production systems)의 모습 사이에는 아무도 솔직하게 말하지 않는 격차가 존재합니다.

그래서 현재 상황이 실제로 어떤지에 대한 저의 솔직한 견해를 말씀드리고자 합니다.

AI 에이전트(AI Agents)를 논하는 방식의 문제점

지금 모든 사람이 모든 것을 "에이전트(agent)"라고 부르고 있습니다. 도구(tool)를 호출하는 함수? 에이전트. 메모리(memory)가 있는 챗봇? 에이전트. 루프(loop)가 있는 스크립트? 에이전트.

이러한 의미의 희석은 단순한 언어적 문제를 넘어섭니다. 이는 실제 엔지니어링 실수를 유발합니다.

무엇을 만들고 있는지에 대한 정확한 정의가 없으면, 결국 단순한 파이프라인(pipelines)은 과잉 엔지니어링(over-engineering)하고, 진정으로 복잡한 파이프라인은 과소 엔지니어링(under-engineering)하게 됩니다. 저는 팀들이 단일한 잘 구조화된 프롬프트(prompt)만으로도 충분했을 워크플로우(workflows)에 "에이전트 방식(agentic)"의 오케스트레이션(orchestration)을 추가하느라 몇 주를 허비하는 것을 보았습니다.

제가 계속해서 되돌아오는 정의는 다음과 같습니다: 에이전트는 단순한 지시(instruction)가 아니라 목표(objective)를 가진 시스템입니다. 에이전트는 다음에 무엇을 할지 스스로 결정합니다. 실패를 처리합니다. 자신이 완료되었을 때를 압니다.

그 외의 모든 것은 그저 화려한 함수 호출(function call)일 뿐입니다.

🟢 만약 당신의 시스템이 매 단계마다 인간의 지시를 필요로 한다면, 그것은 에이전트가 아닙니다. 그것은 채팅 인터페이스(chat interface)입니다.

🔵 만약 당신의 시스템이 실패한 도구 호출(tool call)로부터 회복하여 다른 접근 방식을 시도할 수 있다면, 제대로 가고 있는 것입니다.

✅ 만약 당신의 시스템이 목표를 하위 작업(subtasks)으로 분해하고 이를 위임(delegate)할 수 있다면, 그것이 진짜 에이전트입니다.

현재 프로덕션(Production)에서 실제로 일어나고 있는 일

제가 팔로우하고 대화하는 팀들로부터 얻은 솔직한 모습은 다음과 같습니다:

대부분의 실제 에이전트 배포(deployments)는 좁은 범위(narrow)를 가집니다. 그들은 한 가지 일을 잘 수행합니다. 고객 지원 분류(triage), 문서 추출(document extraction), 특정 코드베이스에 대한 코드 리뷰(code review) 등입니다. 이들은 범용 추론 엔진(general-purpose reasoning engines)이 아닙니다. 결정 계층(decision layer)에 어느 정도의 지능을 갖춘 목적 기반 파이프라인(purpose-built pipelines)입니다.

좋은 결과를 얻고 있는 팀들은 최신 모델 출시를 쫓아다니지 않습니다. 그들은 다음 사항에 집착합니다:

☑️ 도구 설계(Tool design) -- 에이전트가 실제로 무엇을 호출할 수 있는지, 그리고 인터페이스(interface)가 얼마나 깔끔한지

☑️ 실패 처리 (Failure handling) -- 도구가 유용한 정보를 아무것도 반환하지 않을 때 어떤 일이 발생하는가

☑️ 관측 가능성 (Observability) -- 에이전트가 왜 그런 결정을 내렸는지 정확하게 추적할 수 있는가

나쁜 결과를 얻고 있는 팀들은 GPT-4를 최신 프론티어 모델 (frontier model)로 교체하기만 하고, 다른 어떤 것도 변경하지 않은 채 다른 동작을 기대하는 팀들입니다.

최근 계속해서 눈에 띄는 현상이 있습니다: AI 컴퓨팅 격차: 기업들이 비용을 측정하는 속도보다 더 빠르게 인프라를 구매하고 있다 (VentureBeat AI). 107개 기업을 대상으로 조사한 결과, AI 인프라 지출은 그 경제성을 파악하거나 조절할 수 있는 능력보다 훨씬 앞서 가속화되고 있습니다. 대부분의 조직은 익숙한 하이브리드 기반의 AI를 운영하고 있으며...

읽어볼 만한 가치가 있는 글: https://venturebeat.com/ai/the-ai-compute-gap-enterprises-are-buying-infrastructure-faster-than-they-can-measure-what-it-costs

최근 계속해서 눈에 띄는 현상이 있습니다: 에이전트 보안 격차: 기업의 54%가 이미 AI 에이전트 사고를 경험했으며, 대부분은 여전히 에이전트가 자격 증명 (credentials)을 공유하도록 방치하고 있다 (VentureBeat AI). 107개 기업을 대상으로 조사한 결과, AI 에이전트들은 시스템과 데이터에 대한 실제 접근 권한을 부여받고 있는 반면, 이들을 제어하기 위한 통제 장치는 뒤처져 있습니다. 절반 이상이 이미 확인된 사고를...

읽어볼 만한 가치가 있는 글: https://venturebeat.com/ai/the-agent-security-gap-54-of-enterprises-have-already-had-an-ai-agent-incident-and-most-still-let-agents-share-credentials

최근 계속해서 눈에 띄는 내용이 있습니다: AI 컨텍스트 격차: 기업용 AI 조직은 검색(Retrieval) 문제가 아니라 신뢰(Trust) 문제를 겪고 있으며, 대부분은 여전히 해결책을 구축 중이다 (VentureBeat AI). 101개 기업을 대상으로 조사한 결과, AI 에이전트에게 비즈니스 컨텍스트를 제공하는 인프라가 신뢰를 쌓는 속도보다 더 빠르게 구축되고 있습니다. 검색 증강 생성 (RAG)은 이미 d...

읽어볼 만한 가치가 있는 글: https://venturebeat.com/ai/the-ai-context-gap-enterprise-ai-organizations-have-a-trust-problem-not-a-retrieval-problem-and-most-are-still-building-the-fix

프레임워크 전쟁은 주의를 분산시킬 뿐입니다

LangChain, LangGraph, CrewAI, AutoGen, Semantic Kernel. 매달 새로운 프레임워크가 등장하고, 누군가는 기존 프레임워크가 왜 끝났는지에 대해 글을 씁니다.

제 실제 생각은 이렇습니다: 프레임워크는 패턴보다 덜 중요합니다.

어떤 프레임워크를 사용하든 상관없이 계속 작동하는 패턴들은 다음과 같습니다:

✔️ 계획 후 실행 (Plan-then-execute). 계획을 생성하는 하나의 추론(Reasoning) 단계와 이를 따르는 별도의 실행 단계를 두십시오. 이 둘을 섞지 마십시오.

✔️ 검색과 추론의 분리 (Separate retrieval from reasoning). 컨텍스트를 가져오는 것과 컨텍스트를 사용하는 것은 서로 다른 작업입니다. 이 둘을 혼동하는 시스템은 혼란에 빠집니다.

✔️ 명시적 핸드오프 (Explicit handoffs). 한 에이전트가 다른 에이전트에게 작업을 전달할 때, 핸드오프는 구조화되어야 하며 로그로 남아야 합니다. 프롬프트를 통해 전달되는 단순한 문자열이 되어서는 안 됩니다.

저는 세 가지 서로 다른 프레임워크에서 동일한 아키텍처를 재구축해 보았고, 결과는 매번 비슷했습니다. 프레임워크는 비계(Scaffolding)일 뿐입니다. 아키텍처가 바로 건물입니다.

아무도 해결하지 못한 검색 문제

이제 RAG는 표준입니다. 독점 데이터(Proprietary data)를 다루는 거의 모든 프로덕션 AI 시스템은 어떤 형태로든 RAG를 사용합니다. 하지만 튜토리얼에서 잘 다루지 않는 문제가 하나 있습니다.

청크(Chunk) 경계가 잘못되어 있다는 점입니다.

문서를 청크 (Chunk) 단위로 나누고 임베딩 (Embedding)할 때, 여러분은 어떤 맥락의 조각들이 서로 연결되어 있는지에 대한 가정을 하게 됩니다. 이러한 가정은 종종 틀립니다. 이전 문단이 있어야만 의미가 통하는 문단이 단독으로 검색되면, 모델은 누락된 맥락을 환각 (Hallucination)하게 됩니다.

🟢 더 나은 청킹 (Chunking) 전략이 도움이 됩니다. 오버랩 윈도우 (Overlapping windows), 시맨틱 청킹 (Semantic chunking), 부모 문서 검색 (Parent-document retrieval) 등이 있습니다.

🔵 하지만 진짜 해결책은 저장하고 있는 대상 자체를 재고하는 것입니다. 때로는 저장해야 할 올바른 대상이 가공되지 않은 텍스트 (Raw text)가 아니라 정보의 구조화된 표현 (Structured representation)일 수 있습니다.

✅ 만약 여러분의 RAG 파이프라인이 기술적으로는 맞지만 맥락적으로는 쓸모없는 결과를 반환하고 있다면, 그 문제는 임베딩 모델 (Embedding model)이 아니라 거의 확실하게 청킹 (Chunking)이나 메타데이터 (Metadata)에 있습니다.

이 모든 것이 향하는 방향에 대한 나의 생각

모델은 계속해서 좋아질 것입니다. 컨텍스트 윈도우 (Context windows)는 계속 확장될 것입니다. 토큰 (Token)당 비용은 계속 낮아질 것입니다.

그 어떤 것도 근본적인 엔지니어링 과제를 바꾸지는 못합니다. 바로 여러분이 지켜보고 있지 않을 때도 올바르게 동작한다고 신뢰할 수 있는 시스템을 구축하는 것입니다.

그것이 바로 해결할 가치가 있는 문제입니다. 벤치마크 (Benchmark)를 쫓는 것이 아니라 거버넌스 (Governance), 관측 가능성 (Observability), 그리고 신뢰할 수 있는 도구 사용 (Tool use)에 집중하는 것입니다.

2년 뒤에 중요해질 엔지니어는 다른 엔지니어들이 유지보수하고 신뢰할 수 있는 AI 시스템을 구축할 수 있는 사람들입니다. 이는 파인튜닝 (Fine-tuning)이나 프롬프트 엔지니어링 (Prompt engineering)과는 다른 기술 스택입니다.

이는 모델 연구 (Model research)보다는 시스템 디자인 (Systems design)에 더 가깝습니다.

이 내용 중 여러분이 구축하고 있는 것과 공명하는 부분이 있거나, 혹은 완전히 다른 의견이 있다면 듣고 싶습니다. 댓글로 여러분의 경험을 남겨주세요. 이 분야에서 흥미로운 대화는 키노트 (Keynote)에서 일어나는 것이 아니라, 무엇이 실제로 작동하는지에 대해 사람들이 솔직하게 이야기하는 스레드 (Thread)에서 일어납니다.