실제 코드베이스에서 10개의 AI 에이전트를 동시에 실행하면 어떤 일이 벌어질까

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

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

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

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

이러한 개념의 희석은 단순히 의미론적인 문제에 그치지 않습니다. 이는 실제 엔지니어링 실수를 유발합니다.

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

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

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

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

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

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

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

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

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

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

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

☑️ 실패 처리 (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 네이티브 클라우드 인프라로 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 제공). 인공지능 (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. 매달 새로운 프레임워크가 등장하고, 누군가는 기존의 것이 왜 죽었는지에 대해 글을 씁니다.

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

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

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

✔️ 검색 (Retrieval)과 추론 (Reasoning)을 분리하십시오. 컨텍스트 (Context)를 가져오는 것과 컨텍스트를 사용하는 것은 서로 다른 작업입니다. 이 둘을 혼동하는 시스템은 혼란에 빠지게 됩니다.

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

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

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

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

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

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

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

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

✅ 만약 여러분의 RAG 파이프라인 (pipeline)이 기술적으로는 정확하지만 컨텍스트 측면에서는 쓸모없는 결과를 반환하고 있다면, 문제는 임베딩 모델 (embedding model)이 아니라 거의 확실하게 청킹 (chunking)이나 메타데이터 (metadata)에 있습니다.

이 모든 것이 어디로 향하고 있는가에 대한 나의 생각

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

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

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

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

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

만약 이 내용 중 당신이 구축하고 있는 것과 공명하는 부분이 있거나, 혹은 완전히 다른 의견이 있다면, 저는 그것을 듣고 싶습니다. 댓글에 당신의 경험을 남겨주세요. 이 분야의 흥미로운 대화는 기조 연설 (Keynotes)에서 이루어지는 것이 아니라, 사람들이 무엇이 실제로 작동하는지에 대해 솔직하게 이야기하는 스레드 (Threads)에서 이루어집니다.