시니어 AI 엔지니어가 말하는 에이전트(Agent) 열풍에 대한 솔직한 생각 (복잡합니다)

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

그래서 제가 생각하는 현재 상황에 대해 솔직한 의견을 말씀드리겠습니다.

AI 에이전트에 대해 우리가 말하는 방식의 문제점

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

GPT-4 대신 최신 프론티어 모델로 교체하고 다른 것은 아무것도 바꾸지 않았는데도 다른 동작을 기대하며 나쁜 결과를 얻는 팀들이 있다.

최근에 계속 눈에 띄는 것들:
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 기기가 사용자의 필요를 기다리는 대신 백그라운드에서 작동하며 예측하는 미래를 설명했다....

읽어볼 만한 자료: [https://techcrunch.com/2026/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)

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

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

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

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

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

✅ 만약 여러분의 RAG 파이프라인이 기술적으로는 정확하지만 맥락적으로 쓸모없는 결과를 반환한다면, 문제는 임베딩 모델(embedding model)에 있는 것이 아니라 청킹이나 메타데이터(metadata)에 있을 가능성이 높습니다.

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

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

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

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

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

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

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