AI 에이전트 제품의 미래

우리는 종종 미래를 모델의 이름으로 상상한다. 더 큰 모델, 더 빠른 모델, 더 싸진 모델이 다음 시장을 결정할 것처럼 보이기 때문이다. 하지만 실제 제품 현장에서 더 중요한 질문은 조금 다르다. 그 모델이 어떤 환경에서 일하는가, 무엇을 보고 판단하는가, 어떤 도구와 권한을 갖는가, 어떻게 멈추고 검증하는가가 더 큰 차이를 만든다. 앞으로 AI 에이전트 제품의 미래는 단순히 더 똑똑한 모델의 미래가 아니라, 더 잘 설계된 실행 환경의 미래가 될 가능성이 크다.¹²

이 말은 모델이 중요하지 않다는 뜻이 아니다. 엔진은 여전히 중요하다. 다만 이제 엔진만으로는 차가 완성되지 않는다. 내비게이션, 브레이크, 계기판, 정비 시스템, 보험 장치까지 함께 갖춰져야 실제 도로를 달릴 수 있다. AI 에이전트 제품도 마찬가지다. 미래의 승부는 모델 성능의 미세한 우열보다, 하네스를 얼마나 자동으로 만들고, 얼마나 스스로 개선하며, 얼마나 표준화된 생태계 위에서 차별화된 경험을 쌓는가에서 벌어진다.

미래는 "더 좋은 모델"보다 "더 좋은 작업장"으로 간다

초기의 생성형 AI 제품은 모델 자체가 곧 제품처럼 보였다. 그러나 에이전트가 여러 단계를 거쳐 계획하고, 도구를 호출하고, 결과를 검증하는 시대로 들어오면서 무게중심이 달라졌다. 이제 사용자는 문장을 잘 쓰는 모델보다, 내 업무를 끝까지 수행하고 실패했을 때도 복구 가능한 시스템을 원한다.

이 변화는 소프트웨어의 층위 자체를 바꾸고 있다. 앞으로 많은 제품은 기록 시스템, 에이전트 운영 계층, 결과를 보여 주는 인터페이스의 세 층으로 재편될 가능성이 크다. 아래쪽에는 데이터와 정책이 있고, 가운데에는 계획·메모리·도구 호출을 담당하는 하네스가 있으며, 위쪽에는 사용자가 목표를 전달하고 상태를 확인하는 상호작용 층이 놓인다.¹ 예전 소프트웨어가 화면 중심이었다면, 앞으로의 소프트웨어는 실행 환경 중심이 된다.

이 구조에서 가장 흥미로운 점은 하네스가 점점 제품의 숨은 심장이 아니라, 제품의 본체가 되어 간다는 것이다. 사용자는 화면을 보지만, 진짜 차이는 화면 뒤에서 어떤 절차로 일이 처리되는지에서 생긴다. 같은 "고객 문의 자동 처리" 기능이라도 어떤 제품은 잘못된 계정에 답변을 보내고, 어떤 제품은 근거를 남기며 승인까지 거쳐 안전하게 끝낸다. 겉으로는 비슷해 보여도 속의 작업장이 전혀 다른 셈이다.

하네스도 자동으로 만들어지는 시대가 온다

지금까지 하네스 설계는 대부분 사람이 했다. 개발자가 프롬프트를 고치고, 도구 설명을 손보고, 루프를 바꾸고, 평가를 돌려 보며 조금씩 안정성을 높였다. 그런데 앞으로는 이 설계 과정의 일부도 에이전트가 맡게 될 가능성이 높다.

이미 이런 흐름의 초기 형태는 등장했다. 메타 에이전트가 다른 작업 에이전트의 프롬프트, 도구 구성, 오케스트레이션, 검증 방식을 바꾸어 가며 벤치마크 점수를 높이는 접근이 실험되고 있다.³ 쉽게 말해 "일하는 에이전트" 위에 "그 에이전트의 작업장을 개선하는 에이전트"가 붙는 구조다. 사람은 목표와 제약, 성공 기준을 정의하고, 메타 에이전트는 수많은 조합을 시험하며 더 나은 하네스를 찾아간다.

이 변화가 중요한 이유는 단순한 자동화 때문만이 아니다. 조직이 에이전트를 하나만 쓰는 시대는 오래가지 않을 가능성이 크다. 실제 현장에서는 코딩 에이전트, 리서치 에이전트, 문서 처리 에이전트, 고객 지원 에이전트처럼 수십 개의 작업장이 동시에 필요해진다. 이 모든 하네스를 사람이 손으로 하나하나 최적화하는 것은 너무 느리고 비싸다. 그래서 미래에는 "에이전트를 만드는 도구"보다 "에이전트 하네스를 자동 설계하고 튜닝하는 도구"의 가치가 커질 것이다.

다만 자동 하네스 생성이 만능 열쇠는 아니다. 점수만 잘 나오도록 벤치마크에 과적합될 위험도 있다. 시험 문제만 잘 푸는 학생이 실전에서는 약할 수 있는 것처럼, 평가 기준이 좁으면 하네스도 그 좁은 기준에 맞춰 비틀릴 수 있다.³ 그래서 미래의 자동 하네스 생성은 단순한 최적화가 아니라, 성능·안전·비용·설명 가능성을 함께 보는 다목적 설계가 되어야 한다.

자기 개선형 하네스는 제품의 기본 기능이 된다

더 멀리 보면, 하네스는 한 번 설계하고 끝나는 구조물이 아니라 매일 배우는 운영체계에 가까워진다. 오늘 실패한 작업이 내일의 가드레일이 되고, 오늘 성공한 궤적이 내일의 기본 전략이 되는 식이다.

이런 자기 개선 구조의 핵심은 복잡해 보이지만 원리는 단순하다. 먼저 실행을 기록한다. 그다음 결과를 평가한다. 실패한 이유를 진단한다. 마지막으로 그 교훈을 다음 실행에 반영한다. 이 루프가 지속되면 에이전트는 같은 실수를 반복하지 않을 가능성이 높아진다.⁴ 중요한 것은 "학습"이라는 말을 너무 거창하게 볼 필요가 없다는 점이다. 꼭 모델 가중치를 다시 학습시키지 않아도 된다. 프롬프트를 고치고, 툴 선택 규칙을 바꾸고, 실패 사례를 메모리로 축적하고, 검증 단계를 추가하는 것만으로도 하네스는 충분히 똑똑해질 수 있다.

앞으로 많은 제품은 이 자기 개선 구조를 기본 기능처럼 갖추게 될 것이다. 지금의 소프트웨어가 로그를 남기고 에러를 수집하는 것이 기본인 것처럼, 미래의 에이전트 제품은 실행 궤적을 요약하고, 실패 패턴을 분류하고, 개선 후보를 제안하는 기능을 당연하게 포함할 가능성이 높다. 특히 코딩 에이전트나 운영 자동화처럼 반복 실행이 많은 영역에서는 이 차이가 매우 크게 벌어진다. 관측 가능성이 없는 에이전트는 자신의 실수를 잊어버리는 신입사원과 비슷하지만, 관측 가능성과 피드백 루프가 있는 에이전트는 매일 업무일지를 쓰며 조금씩 요령을 익히는 팀원에 가깝다.⁴

여기서 한 단계 더 나아가면, 미래의 하네스는 실행 후에만 배우는 것이 아니라 실행 중에도 자신을 조정할 수 있다. 예를 들어 작업이 길어질수록 컨텍스트를 자동 압축하고, 실패가 반복되면 더 작은 하위 작업으로 쪼개고, 위험한 도구는 승인 모드로 전환하는 식이다. 이때 하네스는 단순한 통제 장치가 아니라, 상황에 따라 형태를 바꾸는 적응형 시스템이 된다.

표준화될 영역과 차별화될 영역은 다르다

미래를 이야기할 때 흔히 놓치는 점이 하나 있다. 모든 것이 표준화되지는 않는다. 오히려 어떤 층은 빠르게 표준화되고, 어떤 층은 더 강한 차별화의 전장이 된다.

표준화가 먼저 일어날 가능성이 큰 곳은 연결과 전달의 문법이다. 에이전트가 도구를 호출하는 방식, 다른 에이전트와 메시지를 주고받는 방식, 보안 토큰과 결과를 포장하는 방식은 점점 공통 규격을 향해 갈 것이다. 실제로 도구 연결과 에이전트 간 상호운용을 위한 프로토콜 논의가 이미 활발하며, 이런 문법이 정착할수록 여러 공급자의 에이전트를 함께 쓰기 쉬워진다.¹ 마치 웹에서 HTTP가 공통 기반이 되었듯, 에이전트 시대에도 기본 연결 규약은 점차 보편 인프라가 될 가능성이 높다.

하지만 표준화가 곧 평준화는 아니다. 진짜 차별화는 그 위의 의미 계층에서 벌어진다. 같은 도구 호출 규격을 써도, "승인"을 무엇으로 정의하는지, "고객 이탈 위험"을 어떤 신호로 판단하는지, "문제가 생기면 어디서 멈추는지"는 조직마다 다르다.¹ 다시 말해 배관은 표준화되지만, 그 배관 안을 흐르는 업무 문법은 표준화되지 않는다.

그래서 미래의 경쟁은 이상한 모양이 된다. 아래층은 공용 인프라가 된다. 모델 API, 에이전트 프로토콜, 기본 평가 도구, 로그 포맷, 권한 프레임워크는 점점 비슷해진다. 그러나 위층으로 갈수록 각 회사의 차이가 더 커진다. 누가 더 좋은 실행 정책을 가졌는지, 누가 더 잘 구조화된 내부 맥락을 가졌는지, 누가 더 설득력 있는 사용자 경험을 만드는지가 승부를 가른다.

에이전트 마켓플레이스와 제어 센터가 생긴다

에이전트가 늘어나면, 다음 문제는 "그래서 이들을 어디서 관리할 것인가"가 된다. 앱이 많아지면 운영체제가 필요해지듯, 에이전트가 많아지면 통합 제어면이 필요해진다.

앞으로 많은 조직은 단일한 채팅창 하나로 모든 에이전트를 쓰기보다, 여러 에이전트의 활동을 모니터링하고 승인하고 비용을 관리하는 제어 센터를 갖추게 될 가능성이 높다. 이 제어 센터는 사용량, 지출, 접근 권한, 상태, 성능, 보안, 컴플라이언스를 한곳에서 보여 주는 운영 화면이 된다.² 사용자는 "무슨 답을 했나"만 보는 것이 아니라, "무슨 근거로 어떤 시스템에 접근해 어떤 결과를 만들었나"를 함께 확인하게 된다.

이와 함께 에이전트 마켓플레이스도 중요해질 수 있다. 특정 기능을 수행하는 에이전트를 내부적으로 배포하거나 외부에서 가져와 연결하는 방식이 늘어나면, 기업은 더 이상 모든 기능을 처음부터 만들지 않아도 된다.² 그러나 여기서도 핵심은 에이전트 자체보다 하네스다. 같은 에이전트를 가져와도 어떤 조직은 안전하게 운영하고, 어떤 조직은 보안 사고를 낸다. 마켓플레이스는 에이전트를 사고파는 장소가 되겠지만, 실제 품질은 여전히 실행 환경에서 결정된다.

에이전트 네이티브 소프트웨어는 UI와 에이전트를 따로 보지 않는다

앞으로의 소프트웨어는 "화면이 있고, 그 옆에 AI 기능이 붙는" 식에서 벗어날 가능성이 크다. 더 자연스러운 방향은 UI와 에이전트가 같은 상태를 공유하고, 같은 작업을 서로 다른 방식으로 수행하는 구조다.⁶ 버튼으로 할 수 있는 일은 에이전트에게 말로 시킬 수 있고, 에이전트가 한 일은 즉시 화면 상태에 반영되는 방식이다.

이 변화는 생각보다 중요하다. 기존 소프트웨어에서 AI는 종종 손님처럼 취급됐다. 별도 채팅 패널에서 답을 하고 끝났다. 하지만 에이전트 네이티브 제품에서는 에이전트가 화면 바깥의 조언자가 아니라, 제품 내부의 행위자다. 사용자는 "이번 주 미수금 정리해 줘"라고 말할 수 있고, 시스템은 해당 작업의 체크리스트, 진행 상태, 승인 요청, 예외 항목을 같은 작업 공간 안에서 보여 준다. 즉, 대화와 조작이 경쟁하는 것이 아니라 합쳐진다.

이런 제품에서는 설계 원칙도 달라진다. 첫째, 에이전트가 이해할 수 있을 만큼 구조가 분명해야 한다. 둘째, 사람이 개입할 지점이 화면 안에서 분명해야 한다. 셋째, 에이전트의 판단 과정을 나중에 되짚어 볼 수 있어야 한다.⁷ 결국 미래의 좋은 UI는 예쁜 대시보드가 아니라, 인간과 에이전트가 같은 작업을 서로 다른 해상도로 바라볼 수 있게 해 주는 협업면이 될 가능성이 크다.

소프트웨어 개발 자체도 에이전트 네이티브로 바뀐다

에이전트 제품의 미래는 사용자용 제품에만 해당하지 않는다. 소프트웨어를 만드는 방식 자체도 바뀐다. 요구사항 정리, 작업 분해, 코드 작성, 테스트 생성, 배포, 관측, 장애 대응까지 개발 생애주기의 더 많은 부분이 에이전트로 연결될 가능성이 높다.⁸⁹

이때 중요한 것은 "코드를 대신 써 주는가"보다 "에이전트가 작업할 수 있도록 개발 환경이 얼마나 잘 구조화되어 있는가"다. 명확한 스펙, 버전 관리되는 설계 의도, 에이전트가 읽을 수 있는 문서, 실행 가능한 테스트, 관측 가능한 런타임이 있을수록 에이전트는 더 잘 일한다.⁸ 반대로 코드베이스가 사람의 암묵지에만 기대고 있으면, 에이전트는 빠르게 움직이지만 계속 같은 벽에 부딪힌다.

더 나아가 모델 자체도 점점 에이전트 네이티브 방향으로 진화하고 있다. 최근 연구는 단발성 코드 생성보다, 실제 저장소를 탐색하고 도구를 호출하고 테스트를 실행하는 에이전트형 작업 흐름에 맞춘 학습이 중요하다고 본다.⁵ 이는 단지 모델이 똑똑해지는 것이 아니라, 모델이 하네스 안에서 더 잘 일하도록 훈련된다는 뜻이다. 앞으로는 모델과 하네스의 경계도 지금보다 더 촘촘하게 맞물릴 가능성이 크다.

그러나 완전 자율은 천천히 온다

미래를 낙관적으로 보더라도, 모든 영역이 곧바로 완전 자율로 넘어가지는 않을 것이다. 특히 규제가 강하고, 실수 비용이 크고, 협업 구조가 복잡한 업무에서는 사람의 승인과 감독이 오래 남는다. 오히려 진짜 성숙한 제품일수록 사람을 완전히 제거하기보다, 어디까지 자동화하고 어디서 멈출지를 더 정교하게 설계한다.

이 점은 중요하다. 미래의 에이전트 제품이 성공하려면 "사람 없이 돌아가는가"보다 "사람과 함께 일할 때 얼마나 신뢰할 수 있는가"를 먼저 증명해야 한다. 따라서 향후 몇 년간 가장 강한 제품은 완전 자동화의 환상을 파는 제품이 아니라, 점진적으로 자동화 수준을 높이되 통제 가능성을 잃지 않는 제품일 가능성이 높다. 다시 말해 미래는 무인 공장이 아니라, 숙련된 감독 체계를 가진 반자동 공장에 더 가까울 수 있다.

결국 미래의 핵심 자산은 하네스의 진화 속도다

이 책의 처음으로 돌아가 보자. 좋은 모델이 좋은 제품은 아니었다. 그리고 마지막 장에 이르면 한 가지가 더 선명해진다. 미래의 좋은 제품은, 시간이 갈수록 더 나은 하네스로 진화하는 제품일 것이다.

모델은 계속 좋아질 것이다. 가격은 내려갈 것이고, 기능은 늘어날 것이다. 연결 규약도 점점 정리될 것이다. 그래서 많은 팀이 비슷한 수준의 모델과 비슷한 수준의 인프라를 사용할 수 있게 된다. 그때 차이를 만드는 것은 누가 더 빨리 배우는가다. 누가 실패를 더 잘 기록하는가, 누가 더 좋은 평가 하네스를 갖고 있는가, 누가 더 안전하게 자동 수정하는가, 누가 사용자와 조직의 맥락을 더 정교하게 실행 환경으로 바꾸는가가 경쟁력을 가른다.

결국 미래의 에이전트 제품은 이렇게 정의할 수 있다. 말을 잘하는 모델 위에, 스스로 점검하고, 점점 더 나아지고, 사람과 함께 일하며, 여러 시스템을 넘나들 수 있는 작업장을 얹은 소프트웨어. 다시 말해 AI 에이전트 제품의 미래는 모델의 미래이면서 동시에 하네스의 미래다.

그리고 아마 앞으로 시장은 이렇게 기억할 것이다. 가장 먼저 등장한 제품보다, 가장 똑똑해 보인 데모보다, 가장 잘 설계된 실행 환경을 가진 제품이 오래 살아남았다고.

참고

¹Will Agentic AI Disrupt SaaS? | Bain & Company

²SaaS meets AI agents: Transforming budgets, customer experience, and workforce dynamics

³GitHub - kevinrgu/autoagent: autonomous harness engineering · GitHub

⁴Closing the Loop: Coding Agents, Telemetry, and the Path to Self-Improving Software

⁵daVinci-Dev: Agent-native Mid-training for Software Engineering

⁶Agent-Native — Framework for Agent-Native Apps

⁷Agent-Native Architecture: Designing Software Systems That AI Can Understand, Operate, and Evolve

⁸An AI led SDLC: Building an End-to-End Agentic Software Development Lifecycle with Azure and GitHub.