성공적인 AI 제품에서 계속 나타나는 3가지 에이전트 패턴

저는 AI 분야에 많은 시간을 할애합니다. 논문을 읽고, 무언가를 만들고, 실제로 배포하는 엔지니어들과 대화합니다. 그리고 데모가 보여주는 것과 실제 프로덕션 시스템의 모습 사이에는 아무도 완전히 솔직하게 말하지 않는 간극이 존재합니다.

그래서 제가 생각하는 현실적인 견해를 말씀드리겠습니다.

AI 에이전트에 대해 이야기하는 방식의 문제점

요즘 모두가 모든 것을 '에이전트(agent)'라고 부릅니다. 도구를 호출하는 함수? 에이전트. 메모리가 있는 챗봇? 에이전트. 루프를 가진 스크립트? 에이전트.

이러한 희석화는 단순히 의미적인 문제가 아닙니다. 실제 엔지니어링 실수를 초래하고 있습니다.

무엇을 만들고 있는지에 대한 정확한 정의가 없으면, 간단한 파이프라인을 과도하게 설계(over-engineering)하고 실제로 복잡한 파이프라인은 충분히 설계하지 못하는(under-engineering) 결과를 낳습니다. 저는 팀들이 단일의 잘 구조화된 프롬프트로 충분했을 워크플로우에 '에이전트적' 오케스트레이션(agentic orchestration)을 추가하느라 몇 주를 허비하는 것을 보았습니다.

제가 계속 돌아가는 정의는 이렇습니다: 에이전트는 단순히 지침(instruction)만 받는 시스템이 아니라, 목표(objective)를 가진 시스템입니다. 다음에 무엇을 할지 스스로 결정합니다. 실패를 처리하고, 언제 끝났는지 알고 있습니다.

그 외의 모든 것은 그저 화려한 함수 호출에 불과합니다.

🟢 만약 시스템이 매 단계마다 인간에게 지시를 받아야 한다면, 그것은 에이전트가 아닙니다. 채팅 인터페이스입니다.

🔵 만약 시스템이 실패한 도구 호출에서 복구하여 다른 접근 방식을 시도할 수 있다면, 어느 정도 진전하고 있는 것입니다.

✅ 만약 시스템이 목표를 하위 작업으로 분해하고 위임할 수 있다면, 그것이 진짜입니다.

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

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

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

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

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

☑️ 실패 처리 (Failure handling) -- 도구가 아무런 유용한 결과를 반환하지 않을 때 무슨 일이 발생하는가

☑️ 관측 가능성 (Observability) -- 에이전트가 내린 결정의 이유를 정확하게 추적할 수 있는가

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

최근에 계속 눈에 띄는 것들:
Cal AI의 바이럴 성공과 관련하여, 소수의 인플루언서들에게 돈이 지불되었다 (TechCrunch AI). 이 회사는 2년 동안 3천만 달러 이상의 수익을 창출했으며, 지난 3월 MyFitnessPal에 미공개 금액으로 인수되었습니다....

더 읽어볼 만한 기사: [https://techcrunch.com/2026/10/15/when-it-came-to-cal-ais-viral-success-a-small-army-of-influencers-paid-off/]

최근에 계속 눈에 띄는 것들:
Meta가 Mac에서 실행되는 오픈 웨이트 AI 모델을 출시했다 (TechCrunch AI). Meta와 Apple이 협력하여 소셜 미디어 거대 기업의 최신 모델인 Muse Spark Open을 출시하는데, 이 모델은 Apple silicon에서 로컬로 실행될 예정입니다....

더 읽어볼 만한 기사: [https://techcrunch.com/2026/10/15/meta-launches-an-open-weight-model-that-runs-on-macs/]

최근에 계속 눈에 띄는 것들:
Amazon 디바이스 책임자 Panos Panay가 AI 기기가 앱을 사용하는 필요성을 대체하는 미래를 본다 (TechCrunch AI). TechCrunch Disrupt에서 연설한 Amazon 디바이스 책임자 Panos Panay는 주변 환경의 AI 기기(ambient AI devices)가 사용자의 필요를 기다리는 대신 배경에서 작동하며 예측하는 미래를 묘사했습니다....

더 읽어볼 만한 기사: [https://techcrunch.com/2026/10/15/amazon-devices-chief-panos-panay-sees-a-future-where-ai-devices-replace-the-need-to-use-apps/]

프레임워크 전쟁은 방해물이다

LangChain. LangGraph. CrewAI. AutoGen. Semantic Kernel. 매달 새로운 것이 나오고 누군가는 이전 것이 왜 죽었는지에 대한 글을 쓰고 있습니다.

제가 실제로 생각하는 것은 다음과 같습니다: 프레임워크보다 패턴이 더 중요합니다.

어떤 프레임워크를 사용하든 계속 작동하는 패턴들:

✔️ 계획-실행 (Plan-then-execute). 추론 단계가 하나의 계획을 생성하고, 별도의 실행 단계가 이를 따르는 방식입니다. 이 둘을 혼합하지 마십시오.

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

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

저는 이 동일한 아키텍처를 세 가지 다른 프레임워크에서 재구축했으며 결과는 매번 비슷했습니다. 프레임워크는 비계(scaffolding)일 뿐입니다. 아키텍처가 건물입니다.

아무도 해결하지 못한 검색 문제 (The Retrieval Problem Nobody Has Solved)

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

청크 경계가 잘못되었습니다.

문서를 청크로 분할하고 임베딩(embed)할 때, 여러분은 어떤 컨텍스트 조각들이 함께 속하는지에 대해 가정을 하고 있는 것입니다. 이러한 가정들은 종종 틀립니다. 이전 단락의 맥락이 있어야만 의미를 갖는 단락이 고립되어 검색되고 모델이 누락된 컨텍스트를 환각(hallucinates)합니다.

🟢 더 나은 청킹 전략이 도움이 됩니다. 오버래핑 윈도우(Overlapping windows), 시맨틱 청킹(semantic chunking), 부모 문서 검색(parent-document retrieval).

🔵 하지만 진짜 해결책은 무엇을 저장할지 재고하는 것입니다. 때로는 저장해야 할 올바른 것이 원시 텍스트가 아니라 정보의 구조화된 표현일 수 있습니다.

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

제가 생각하는 방향 (Where I Think This Is All Going)

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

이 모든 것 중 어느 것도 근본적인 엔지니어링 과제를 바꾸지는 못합니다. 즉, 우리가 지켜보고 있지 않을 때에도 올바르게 작동한다고 신뢰할 수 있는 시스템을 구축하는 것입니다.

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

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

이는 모델 연구보다는 시스템 설계에 가깝습니다.

만약 이 내용 중 어떤 것이 여러분이 만들고 있는 것과 공명하거나, 완전히 다른 관점을 가지고 있다면 듣고 싶습니다. 댓글에 경험을 남겨주세요. 이 분야에서 흥미로운 대화는 기조연설(keynotes)에서 나오는 것이 아니라, 사람들이 실제로 무엇이 효과적인지에 대해 솔직하게 이야기하는 스레드에서 나옵니다.