▲

자율 에이전트에 대한 "과대광고"와 실제 프로덕션에서 작동하는 AI 에이전트의 차이점

 (utkarshkanwat.com)
3P by GN⁺ 4일전 | ★ favorite | 댓글 1개
  • AI 에이전트 붐이 2025년에 크게 다가올 것이라는 기대와 달리, 실제 프로덕션 환경에서는 현실적인 한계가 존재함
  • 에러 누적과 토큰 비용 문제로 인해, 다단계 워크플로우를 완전 자동화하는 것은 현재 불가능함
  • 대부분의 성공적인 에이전트 시스템은 엄격하게 제한된 도메인과 인간의 승인 또는 검증 과정을 필수로 함
  • 진짜 어려운 점은 AI 성능 자체가 아니라, 에이전트가 잘 사용할 수 있는 도구 및 피드백 시스템 설계임
  • 2025년에 완전 자율 에이전트를 전면에 내세운 스타트업/기업은 실제 도입과 확장 과정에서 큰 장애물을 맞이할 것으로 전망됨

내가 2025년에 AI 에이전트가 등장하지 않을 것이라고 베팅하는 이유 (AI 에이전트를 개발하고 있음에도 불구하고)

  • 2025년이 AI 에이전트의 해가 될 것이라는 과대광고가 만연함
  • 필자는 지난 1년간 실제 프로덕션 환경에서 동작하는 다양한 AI 에이전트 시스템을 직접 구축함
  • 직접적인 실무 경험에서 나온 이유로, 시장의 "에이전트 혁명"에 회의적 입장을 가짐

다양한 에이전트 시스템 구축 경험

  • 개발 에이전트: 자연어로부터 React 컴포넌트 생성, 레거시 코드 리팩터링, API 문서 자동관리, 명세 기반 함수 생성 등
  • 데이터 & 인프라 에이전트: 복잡 쿼리와 마이그레이션 처리, 멀티 클라우드 DevOps 자동화
  • 품질 & 프로세스 에이전트: 린트 자동수정, 테스트 코드 생성, 코드리뷰 및 상세 Pull Request 자동화
  • 이들 시스템은 실제 가치와 시간을 절감해주나, 이 경험이 과대광고에 대한 비판적 시각의 배경임

핵심 요약: AI 에이전트의 세 가지 냉정한 진실

  1. 에러율 누적: 단계가 늘수록 성공률이 기하급수적으로 하락함. 프로덕션 기준(99.9% 이상) 충족이 어려움
  2. 컨텍스트 윈도우와 비용: 대화가 길어질수록 토큰 비용이 자승적으로 증가함에 따라 경제성이 무너짐
  3. 도구 및 피드백 설계의 어려움: 기술적 한계가 아니라, 에이전트 활용 가능한 도구 및 피드백 시스템 설계가 가장 큰 도전임

에러 누적에 대한 수학적 현실

  • 다단계 자율 워크플로우는 에러 누적으로 인해 실제 운영규모에서 실현 불가
  • 예를 들어 각 단계에서 95% 신뢰도라 해도, 20단계면 최종 성공률 36% 에 불과(프로덕션의 요구: 99.9% 이상)
  • 높은 신뢰도를 설령 가정해도, 단계가 늘어날수록 실패확률 대폭 증가
  • 실무에서는 모든 프로세스를 완전 자동화하지 않고, 각 단계를 독립 검증 및 롤백 지점과 인간 확인을 두는 구조로 설계함
  • 성공적인 에이전트 시스템 패턴: 명확히 제한된 컨텍스트, 검증 가능한 작업, 중요한 지점에 인간 결정 관여

토큰 비용 구조와 경제적 한계

  • 컨텍스트 윈도우 및 대화를 유지하기 위한 토큰 비용이 시스템 확장 시 비경제적 현실로 부상
  • 대화식 에이전트는 매번 모든 대화 기록을 처리해야 하므로, 회차가 늘수록 비용이 제곱으로 급상승
  • 100회에 걸친 대화는 토큰 비용만 50~100달러 소요, 대량 사용자 적용 시 경제성 붕괴
  • 반면, Stateless(상태 비저장) 방식의 단일 슬롯, 맥락 불필요한 기능 생성 에이전트는 비용과 확장성 측면에서 유리함
  • 가장 성공적인 프로덕션 에이전트는 "대화식"보다 "명확한 목적의 스마트 도구"에 가까움

도구 설계와 피드백 시스템의 벽

  • 생산성 높은 에이전트 개발의 진짜 난관은, 기존 팀들이 과소평가하는 도구 설계 능력
  • 툴콜 자체의 정확도는 높아졌지만, 복잡 상태·결과를 효과적으로 요약해 에이전트에 피드백하는 설계가 관건
  • 예시:
    • 작업이 부분적으로 성공했을 때, 얼마만큼의 정보와 어떤 요약이 필요한지 판단 필요
    • 예를 들어 쿼리 결과가 10,000건이라면 "성공, 1만 건, 앞 5건만"처럼 상태 파악용 추상화 설계가 요구됨
    • 툴 실패 시 회복 정보양 조절 및 맥락 오염 방지 필요
  • 실제로 성공한 데이터베이스 에이전트의 핵심: 에이전트가 실질적으로 의사결정 가능한 구조화된 피드백 제공
  • 현실에서 AI가 하는 일은 약 30%, 나머지 70%는 도구 피드백·복구·컨텍스트 관리 등의 전통 엔지니어링 역량이 차지함

실제 시스템 통합의 한계

  • 신뢰도와 비용 문제가 해결되어도, 현실 세계와의 통합 문제가 또 다른 벽으로 작용
  • 현실 조직 시스템은 일관된 API가 아니며, 레거시 특성, 예외적 오류, 변화하는 인증, 가변적인 제한, 준법 규정 등 예측 불가한 복잡성 내재
  • 실제 데이터베이스 에이전트는 연결 풀 관리, 트랜잭션 롤백, 읽기 전용 복제본 존중, 쿼리 타임아웃, 로그 등 전통적 프로그래밍이 필수
  • "AI가 모든 스택을 완전 자율적으로 통합"한다는 약속은 실제 구축 시 현실 벽에 부딪힘

실제로 잘 작동하는 방식 패턴

  • 성공적인 에이전트 시스템의 공통 원리
    1. UI 생성 에이전트: 사용자 경험은 인간이 최종 검토 (AI는 자연어→React 변환 복잡성만 담당)
    2. 데이터베이스 에이전트: 파괴적 작업은 항상 인간이 확인 (AI는 SQL 변환만, 데이터 보존 통제는 인간)
    3. 함수 생성 에이전트: 명확한 명세 내 한정 동작 (상태·부작용·복잡한 통합 없음)
    4. DevOps 자동화: 인프라 코드 생성은 AI, 배포·버전관리·복구는 기존 파이프라인
    5. CI/CD 에이전트: 각 단계는 명확한 성공 기준과 롤백 메커니즘으로 설계
  • 패턴 요약: AI는 복잡성 처리, 인간이 통제권 유지, 신뢰성은 전통 엔지니어링이 확보

시장 전망 및 예측

  • 완전 자율 에이전트 앞세운 벤처 스타트업은 수익성 문제에 가장 먼저 부딪힐 것
  • 5단계 워크플로우에선 데모가 훌륭해도, 실제 기업은 20단계 이상 요구하며 수학적 한계에 직면
  • 기존 소프트웨어에 AI 에이전트만 단순 추가한 기업은 실제적 통합의 미비로 채택 정체 가능성 높음
  • 진짜 승리자: 명확히 제한된 도메인 내에서, AI를 어려운 작업에만 적용하고 중요 결정에는 인간·경계조건 부여하는 팀
  • 시장은 "데모는 잘 되는 AI"와 "진짜 신뢰성 있는 AI"의 차이를 값비싼 경험을 통해 배우게 될 전망

바람직한 에이전트 시스템 구축 원칙

  • 명확한 경계 설정: 에이전트의 역할과 인간/기존 시스템 핸드오프 구간 명확히 정의
  • 실패 대비 설계: AI 오류 발생 시 롤백·복구 구조 설계 필수
  • 경제성 검증: 인터랙션 단가 및 규모 확장 대비 구조 설계 (상태 저장보다 상태 비저장이 경제적)
  • 자율성보다 신뢰성 우선: 일관된 작동이 가끔 마법 부리는 시스템보다 신뢰성에서 사용자 신뢰 획득
  • 견고한 기반 위 구축: 어려운 부분(의도 해석, 생성 등)만 AI에 할당, 나머지(실행, 에러 처리 등)는 전통 SW에 맡김

실전 경험에서 얻은 진짜 교훈

  • "데모로 작동"과 "실제 대규모 운영" 간 괴리감은 매우 큼
  • 에이전트 신뢰성, 비용 최적화, 통합 복잡성 등은 아직도 산업 전반에서 풀리지 않은 주요 문제
  • 실제 구축 경험과 정직한 경험 공유가 업계 발전의 핵심
  • 더 많은 실전 경험자들이 합리적인 방법론과 현실적 실패 사례를 논의할수록 전체적인 성공 가능성 제고
▲
GN⁺ 4일전  [-]
Hacker News 의견

  • Amazon의 AI 프로덕션 엔지니어와 대화해 본 경험이 있음, 그분이 말하길 현재 어떤 회사도 고객과 직접 대화하는 곳에 생성형 AI만 사용하는 경우가 전혀 없다고 함, 모든 자동응답은 예전의 비생성형 "구식" 기술을 사용한다고 함, 생성형 AI의 신뢰성 문제가 기업의 명성에 걸 stake를 맡길 수 없을 만큼 큼

    • 예전에는 "구식 AI" 상징적 기법과 전통적인 머신러닝을 결합하는 에이전트에 관심이 많았음, 하지만 주로 프리-트랜스포머 신경망에서 일하게 됐음, 결국엔 항상 인간이 개입하는 시스템을 먼저 만들고 평가 및 훈련 데이터를 수집함, 그런 뒤 시스템이 업무 일부를 맡아서 나머지 품질까지 같이 향상시키는 흐름임, 특히 '주관적' 작업에서는 심볼릭 시스템도 반드시 평가해야 함, 만약 시스템을 훈련시켜야 한다면 평가를 못 피함

    • 실제로 많은 테크 기업이 이미 생성형 AI를 실시간 챗봇 고객지원에 도입 중임, Sonder와 Wealthsimple 같은 곳을 알고 있음, LLM이 쿼리에 답을 못 할 경우엔 대화를 바로 인간 상담사에게 넘김

  • 아직 논의되지 않은 점이 맥락 창(context window)에 대한 것임, 인간은 전문 분야에서 사실상 "거의 무한대"에 가까운 맥락을 다룰 수 있음, 모델은 더 크고 다양한 학습 데이터로 어느 정도 한계를 극복할 수 있지만 진정한 해결책은 아니라는 생각임, 현재는 사람들이 자신만의 맥락을 프롬프트에 담아 압축해야 하기에 영어처럼 유연한 언어에서는 공학보다는 마법주문 외우기나 추측 같은 느낌임, 결정론적 방식 대신 데이터의 많은 부분을 잃는다고 느끼는 중임

    • 인간은 "맥락"과 "가중치"가 나뉘어 고정적으로 구분되어 있지 않음, 시간에 따라 경험과 결과가 내 "가중치" 자체를 계속 바꾸는데 LLM은 아키텍처상 가중치가 읽기 전용이라 불가능함

    • 인간이 정말 그렇게 거대한 맥락 창을 가지고 있냐는 회의가 있음, 나는 내 복잡한 문제 해결 시 인간 고유의 "맥락 창" 한계에 자주 부딪힘, 실제로 그런 예시가 있는지 궁금함

  • 나는 AI툴 사용 경험이 대체로 긍정적이었음, 쉬어야 할 때 소규모 작업을 맡기거나, 업무를 정리 및 시동시키는 데 큰 도움이 됨, 하지만 비용 이슈가 금방 생김, 예를 들어 Claude Code를 큰 코드베이스에 쓰면 1~2시간에 $25 정도 소요됨, 자동화된 교정까지 붙이면 $50/hr까지 오름, 속도, 정확도, 비용 트레이드오프가 있음, 요즘 나온 Agent들도 그 삼각형의 지점이 아직 불명확해서 여러 실험이 흥미롭긴 해도 여전히 리스크가 있다고 생각함

    • 약간 냉소적으로 보자면, LLM이 끊임없이 자기 자신을 리프롬프트하면서 오류를 고치는 구조, 그리고 "RAG 필요 없음! 그냥 1m 토큰 맥락창에 모든 코드를 다 던져넣어라"라는 접근이 결국 '토큰당 과금' 비즈니스 모델에 딱 맞는 프레임임

    • 요즘 고민하는 아이디어는 여러 개의 커밋 초안을 처음부터 AI가 만들어내고, 이 결과를 사람이 직접 혹은 자동화된 방식으로 필터링 및 수동 다듬기 하는 구조임, 큰 작업일수록 초기의 작은 편차가 전체 결과를 망칠 확률이 높음, 그래서 현재 SOTA로도 에이전트들이 여러 안을 병렬로 시도하게 하면 수동 리팩터링하는 시간이 줄어듦, 관련 절차에 대해 GitHub에 글 남긴 적이 있음

    • 구독 서비스냐고 질문하고 싶음

  • 인간의 다단계 워크플로우에는 보통 검증 체크포인트가 있음, 인간도 99% 이상 정확하진 않기 때문임, 향후 에이전트도 출력에 검증 절차를 설계하고 다음 단계로 나아가기 전에 이 과정을 통과하도록 학습될 것임, 사전에 "여기만큼은 99% 이상 정확해야 한다" 같은 위험도 사전 평가도 할 수 있을 것임

    • Claude Code는 작업을 진행하기 전마다 계속 멈춰서 사용자에게 진행할지 물으며, 제안된 변경 사항도 미리 보여줌, 토큰 낭비와 비효율적인 작업을 막는 데 효과적임

    • 많은 애플리케이션도 이런 구조에 맞춰 재설계가 필요함, 내 생각에 마이크로서비스 아키텍처가 LLM과 궁합이 좋아서 다시 유행할 것 같음

  • "진짜 문제는 AI의 능력이 아니라, 에이전트가 실제로 효과적으로 쓸 수 있는 툴과 피드백 시스템을 설계하는 것"이라는 데 동의함, 시장이 어떻게 받아들일지 확신이 없어 눈팅만 하다가 에이전트 만들기에 특화된 아주 작은 스타트업에 합류함, 5개월 만에 회의적→동조→확신으로 바뀜, 주제 범위를 아주 좁게 잡고, 모델이 일하기 위한 툴링에 집중하면 높은 완수율을 경험했음, 비결정론적 특성을 꺼려하는 경향이 있지만, 뛰어난 툴링과 점점 더 좁은 스코프만 있으면 현실적으로 꽤 쓸 만함, 툴링 자체가 어렵게 느껴지지만 괜찮게 해결 가능하다고 봄, 미래를 낙관함

  • 다 해결 가능한 문제라고 생각함, 다만 빠른 ARR 확보 경쟁 때문에 많은 스타트업이 이런 문제에 집중하지 않음, 에이전트가 약속만큼 쓸모없다는 의견에도 일리는 있지만 실제로는 엔지니어링 문제임, 다른 시각으로 접근하면 작동할 거라 생각함(개인적으로 RL 쪽을 더 지지함), 예를 들면 좋은 검증자(verifier)가 필요함, 많은 작업은 직접 수행보다 검증이 더 쉬움, 80% 정확도의 병렬 생성물 5개만 있어도 99.96% 확률로 하나는 제대로 나오고 검증자가 그걸 고를 수 있음, 멀티스텝 상황에서도 수학적으로 유리해짐, 이제까지와는 다른 방식의 접근법, 글에서도 3~5단계 워크플로우 패러다임을 언급하는데 이게 실제로 잘 맞음, 앞으로 이런 모델이 더 많이 나와야 함

    • 많은 작업에서 실제로는 검증이 작업 자체보다 더 어렵지 않냐는 논거에 의견이 있음, 특히 소프트웨어 QA 현장은 이런 논리로 구조조정이 일어나곤 했고 그 결과 품질이 나빠졌다고 느낌, 검증자는 시스템, 외부세계의 가능 상태 조합수가 기하급수적으로 늘어나서 아주 어렵게 됨, LLM은 이런 복잡한 작업환경에서 의존성을 모킹하거나 데이터를 미리 채우는 등 반복적인 노가다를 대신하는 데 매력적이나, 검증 테스트가 유의미하려면 항상 100% 정확해야 한다는 요구가 붙고 결국엔 사전조건 마다 또 검증자가 필요해짐, 결국 모든 단계가 100%여야 하면 누적적으로 확률이 줄어듦, 인간은 대부분 특정 케이스 별로 신중하게 테스트하고 모든 경우를 완벽 검증하진 않음(화이트박스 테스트가 블랙박스보다 훨씬 일반적임), LLM이 코드를 많이 생산하면 결국 작업자가 코드 전체를 이해해야만 화이트박스 검증이 가능한데, 그러면 절약한 시간이 다시 줄어듦, 현재로선 LLM이 만들고 오류도 내가 직접 다 고쳐야 해서 자신감이 더 줄고 시간도 더 듬, 일부 상황에서는 인터페이스를 LLM의 예상에 맞추는 식으로 해결할 수 있지만 범용적이지 않음, 소프트웨어를 벗어나면 검증은 아예 불가능할 때가 많음(예: "가장 유망한 게임 스타트업 5개 선정" 같은 경우 객관적 검증 불가), 이런 영역까지 사람도 아닌 기계에 무작정 맡기면 수습 불가

    • 다섯 번 생성이 서로 독립적일 거라 가정해도 되는지 궁금함

    • 맞는 말임, 여러 에이전트가 시도하고, 여러 번 되풀이하며 다양한 솔루션을 적용하는 게 현실적으로 효과 있음, 실제로 한 방법에서 부정적 피드백 받고 다른 접근방법으로 성공한 사례를 경험함

  • 한 명의 개인(혹은 극소수 팀)이 개발, DevOps, 데이터오퍼레이션 등에서 실제 운영 중인 AI 에이전트를 12개 이상 만든 것은 의외임, 스타트업 실패율을 보면 "하나" 좋은 제품 만들기도 힘든데 12개나 만들었다는 것이 놀라움, 우리도 Definite 같은 데이터스택+AI 에이전트 툴을 2년 걸려 겨우 6개월 전부터 괜찮아졌음, Definite

    • 사실 12개의 독립적 제품이 아니라, 실제로는 필요에 따라 직장에서 쓰는 아주 구체적 목적의 툴 12개를 만들었다는 의미임, 전체 글의 주제처럼 아주 단순하고 명확한 목적에만 집중해야 쓸모있는 에이전트가 됨

    • 정규직 일을 3년이나 하면서 12개 이상 만들어냈다는 건 뭔가 어색함

  • 나도 에이전트/AI 자동화 개발이 직업임, 오픈엔드형 코딩 에이전트는 그냥 멍청한 생각임, 인간 검증 체크포인트, 작은 탐색공간, 아주 구체적 질문/프롬프트(예: 이 이메일에 인보이스 있나 YES/NO)가 현실적임, 완전 자동 에이전트를 원하는 마음은 이해해도 기술은 아직 거기 못 미침, 나는 컨텐츠(텍스트, 이미지, 코드) 생성에는 손대지 않음, 그런 건 결국 한 방 먹일 거니까

    • 나도 에이전트 프레임워크와 함께 chat coding(커뮤니케이션 기반 코딩)으로 작업량의 50% 정도를 줄임, GPT로 실제 효과 경험함, 하지만 10번 중 1번 꼴로 오류가 꼭 발생함, LLM 아키텍처를 근본적으로 바꾸지 않으면 이 에러율 안 고쳐질 거라 봄, 현 시점에서 hype 때문에 개발자 신뢰가 무너지지만 않는다면 향후엔 훨씬 더 견고한 시스템이 나올 것으로 확신함, 실제 팀원 채용도 예전보다 훨씬 적게 할 수 있을 정도로 생산성 향상이 눈에 띔, 각종 주제 러닝 커브도 google search 질 저하를 LLM이 보완해줘서 비약적으로 낮아짐, 자동화된 워크플로우에서 인간 업무 일부를 LLM이 맡도록 하는 Orchestration Framework가 가장 중요한 구조임, LLM이 본인 확신도 함께 보고하고, confidence %가 낮으면 바로 인간한테 넘어오도록, 테스트, 가드레일 등만 잘 되면 비핵심 업무부터 충분히 인간 대체 가능성큼, 사람을 대체하는 게 아니라 업무의 자동화로 팀 사이즈 절감이 목표임, 예시로 대형 이커머스의 상품설명, 이미지 검증·오타·이미지불일치 등 인간이 하던 작업을 LLM이 처리할 날을 확신함

    • 대체로 동의하지만 그렇게 접근하면 남는 게 "그냥 비싼 워크플로우 시스템"일 수도 있음, 예전 기술로도 할 수 있던 걸 굳이 LLM이 해야 할 필요성이 있나 고민됨

    • 나도 동의함, 현재는 "좁은 범위, 리스크 낮음, 반복성 높은 지루한 일"이 에이전트에 딱 맞는 포인트임, 예시로는 dev-log 마크다운 보조 작업에 에이전트 활용한 경험 여기에 남겼음

    • 인간 검증이 체크포인트를 만들기에 가장 신뢰성 높음은 사실이나, 유닛테스트, 시스템 전체의 임시 검증(ad-hoc validation) 등 여러 방식이 추가로 존재함

  • 나는 실제로 저자가 오히려 지금보다 자율 에이전트에 더욱 낙관적이어야 한다고 봄, 지금 하는 것 중 90%는 2024년 초엔 불가능했던 일임, 발전 곡선을 과소평가하지 않아야 함

  • 나도 같은 생각임, 관련된 블로그 글도 있음, 핵심 차이는 HITL(Human in the loop)로 오류를 줄이는 게 맞고 HOTL(Human out of the loop)은 오히려 문제를 만든다는 점임

답변달기