저는 논문을 읽고, 무언가를 만들고, 실제로 제품을 출시하는 엔지니어들과 대화하며 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)에서 실제로 일어나고 있는 일

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

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

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

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

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

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

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

최근 계속해서 눈에 띄는 소식이 있습니다: Google이 25년 만에 처음으로 검색창을 재설계했습니다 — 이것이 여러분이 생각하는 것보다 왜 더 중요한지에 대하여. (VentureBeat AI). 4분의 1세기 동안, Google 검색창은 컴퓨팅에서 가장 인지도가 높은 인터페이스 중 하나였습니다: 얇은 흰색 직사각형, 깜빡이는 커서, 몇 개의 입력된 단어, 그리고 목록...

읽어볼 만한 가치가 있는 글: https://venturebeat.com/technology/google-just-redesigned-the-search-box-for-the-first-time-in-25-years-heres-why-it-matters-more-than-you-think

최근 계속해서 눈에 띄는 소식이 있습니다: Railway, AI 네이티브 클라우드 인프라 (AI-native cloud infrastructure)로 AWS에 도전하기 위해 1억 달러 확보 (VentureBeat AI). 마케팅에 단 1달러도 쓰지 않고 조용히 200만 명의 개발자를 모은 샌프란시스코 기반의 클라우드 플랫폼인 Railway는 목요일에 1억 달러를 조달했다고 발표했습니다...

읽어볼 만한 가치가 있는 글: https://venturebeat.com/infrastructure/railway-secures-usd100-million-to-challenge-aws-with-ai-native-cloud

최근 계속해서 눈에 띄는 소식이 있습니다: Claude Code는 한 달에 최대 200달러가 듭니다. Goose는 동일한 기능을 무료로 제공합니다. (VentureBeat AI). 인공지능 코딩 혁명에는 함정이 있습니다: 바로 비용이 많이 든다는 점입니다. 코드를 작성, 디버깅 및 배포할 수 있는 Anthropic의 터미널 기반 AI 에이전트인 Claude Code는...

읽어볼 만한 가치가 있는 글: https://venturebeat.com/infrastructure/claude-code-costs-up-to-usd200-a-month-goose-does-the-same-thing-for-free

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

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

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

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

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

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

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

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

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

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

청크(chunk) 경계가 잘못되었다는 점입니다.

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

🟢 더 나은 청킹(chunking) 전략이 도움이 됩니다. 오버랩 윈도우(Overlapping windows), 의미론적 청킹(semantic chunking), 부모 문서 검색(parent-document retrieval) 등이 있습니다.

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

✅ 만약 귀하의 RAG (Retrieval-Augmented Generation) 파이프라인이 기술적으로는 정확하지만 문맥적으로는 쓸모없는 결과를 반환하고 있다면, 그 문제는 임베딩 모델 (embedding model)이 아니라 거의 확실하게 청킹 (chunking)이나 메타데이터 (metadata)에 있습니다.

이 모든 것이 어디로 향하고 있다고 생각하는가

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

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

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

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

이는 모델 연구 (model research)보다는 시스템 설계 (systems design)에 더 가깝습니다.

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