*이 글은 AB180 CEO 남성필 대표님이 Claude Code와 Codex를 사용하며 느낀 인사이트를 직접 정리한 수기입니다.
AI 에이전트는 소프트웨어를 없애기보다, 소프트웨어가 가치를 만드는 방식을 바꾸고 있다. 앞으로의 소프트웨어는 직접 결과를 만들거나, 에이전트가 결과를 만들 수 있도록 받쳐 주는 인프라가 되어야 한다.
핵심 포인트
10년 동안 엔터프라이즈 소프트웨어를 만들어 왔고, 지금도 SaaS를 만들고 있다. 이 자리에 앉아서 가장 자주 마주치는 질문은 단순하다. "우리가 만드는 이 소프트웨어는 5년 뒤에도 자리가 있는가." 요즘 머릿속에 정리되고 있는 답은 이렇다.
소프트웨어는 언제나 AI보다 더 넓은 범위를 커버한다. 그러나 두 영역은 서로를 대체하는 쪽이 아니라, 서로를 흡수하는 쪽으로 가고 있다는 생각이 든다. 한쪽에서는 AI 에이전트가 기존 소프트웨어의 영역을 빨아들이며 결과를 직접 만들어 내는 주체로 자리를 잡고, 다른 한쪽에서는 기존 소프트웨어가 그 에이전트의 일을 받아 주는 인프라로 흡수된다.
에이전트와 소프트웨어는 한쪽이 사라지는 관계가 아니라, 서로 안으로 들어가서 다시 조립되는 관계라고 본다. 그래서 살아남는 소프트웨어는 두 가지 형태로 정리된다. 에이전트가 되어 결과를 만들어 내거나, 에이전트에게 인프라를 제공하거나. 이 글은 그 두 형태가 어떻게 나뉘고, 그 사이에 낀 소프트웨어는 왜 약해질 수밖에 없는지에 대한 1차적 정리다.
먼저 용어부터 좁혀 둘 필요가 있다. 이 글에서 말하는 에이전트는, LLM을 의사결정 코어로 두고 환경과 상호작용하면서 인간이 원하는 일을 대신 수행하는 자율 실행 주체다. Google I/O 2025의 personal, proactive, powerful이라는 방향도 결국 여기에 닿아 있다. 맥락에 맞춰 다르게 반응하고, 먼저 움직이며, 더 큰 일을 끝까지 해내는 것이다.
이 진화의 본질은, 에이전트가 채팅창 안의 모델에서 벗어나 인간의 눈·귀·손에 해당하는 작업 접면을 하나씩 얻고 있다는 점이다. 코드를 읽는 눈, 브라우저를 조작하는 손, 화면과 음성을 이해하는 감각이 붙을수록 에이전트는 실행 주체에 가까워진다.
이 결과 인간이 GUI 앞에 앉아 마우스로 누르던 작업의 상당수가 줄어든다. GUI를 매끄럽게 만드는 데 가치의 무게를 두었던 SaaS가 가장 빠르게 흔들리는 이유다.
그러나 에이전트의 기본기가 아무리 좋아져도, 소프트웨어가 해야만 하는 영역은 남는다. 거기서 두 가지 형태가 살아남는다고 본다.
가장 확실히 살아남는 첫 번째 부류는, 결과 자체를 만들어 주는 소프트웨어다.
과거의 SaaS는 "성과를 내는 과정"을 매끄럽게 만드는 도구였다. 사람은 그 도구를 능숙하게 쓰는 법을 배워야 했고, 도구의 가치는 곧 "사람을 얼마나 잘 거들어 주는가"였다.
에이전트 시대에는 이 등식이 흔들린다. 어떤 식으로 일이 처리되든 결과만 잘 나오면 끝나는 쪽으로 무게가 옮겨간다. 한때 차별화의 핵심이었던 사용성, 워크플로우 디자인, 단축키, 사이드바 정렬은 부차적인 디테일로 밀려난다. 그 UI 앞에 앉는 사람의 시간이 빠르게 줄어들고 있기 때문이다.
그래서 결과를 직접 가져다주는 소프트웨어, 또는 그 일을 해내는 에이전트가 가장 강한 자리에 선다. 캠페인을 알아서 운영해 ROAS를 만들어 주는 도구. 채용 공고에서 합격 가능성 있는 후보 30명을 추려 인터뷰까지 잡아 주는 도구. 대시보드를 들여다보지 않아도 매주 "이번 주에 손봐야 할 세 가지"를 PR로 올려 주는 도구. 과정을 보여 주는 게 아니라 성과를 떠넘기는 형태의 소프트웨어다.
이 자리에 서는 소프트웨어는 사용자 인터페이스가 사라지는 게 아니다. 사용자가 도구를 다루는 시간이 줄어드는 만큼, 결과를 검토하고 권한을 위임하는 시간이 늘어난다. 가격 모델도 따라 움직인다. 월 사용료를 내고 도구를 잘 다루는 사람이 성과를 만든다는 등식에서, 결과를 만들어 준 만큼 비용을 낸다는 등식으로 무게가 옮겨간다. 한때 사용자를 학습시키는 데 들였던 비용은, 사람이 결과를 신뢰할 수 있는 근거를 제시하는 자리로 옮겨간다.
두 번째 부류는, 에이전트가 일을 더 잘하게 만들어 주는 인프라형 소프트웨어다.
에이전트라고 해서 모든 일을 직접 처리할 수 있는 건 아니다. 검색에는 안정적인 검색 API(Tavily, Exa 같은)가 필요하고, 메일에는 전달률(deliverability)을 책임질 발송 인프라(Postmark, Resend)가 필요하다. 분석에는 정제된 데이터와 쿼리 엔진(BigQuery, Snowflake)이 필요하다. 이렇게 에이전트의 손과 발이 되어 주는 소프트웨어는 앞으로도 살아남는다. 에이전트가 늘수록 인프라의 호출량과 의존도도 커지기 때문이다.
여기서 한 가지 정정해 둘 필요가 있다. 인프라는 클라우드, 데이터베이스, DNS, CDN 같은 전통적인 의미만이 아니다. 에이전트 시대의 인프라는 그것보다 훨씬 넓은 영역을 가리킨다.
그 세 가지는 다음과 같다.
라면을 예로 들어 보자. 우리는 집에서 수타면을 뽑아 끓일 수 있다. 그래도 인스턴트 라면을 사 먹는 이유는, 사 먹는 편이 훨씬 싸고 안정적이기 때문이다.
에이전트도 똑같다. 시간이 갈수록 에이전트가 직접 만들어 낼 수 있는 영역은 빠르게 넓어진다. 그러나 만든다는 행위에는 언제나 비용이 따라붙는다.
이 비용들은 누적된다. 더 싸고 안정적으로 같은 결과를 공급할 수 있는 서비스가 있다면, 에이전트는 직접 만들지 않고 그 서비스를 호출한다. 인프라화는 이 단순한 경제 계산이 만들어 내는 결과다.
다른 한 갈래도 있다. 만드는 비용이 문제가 아니라, 애초에 LLM이 소유할 수 없는 가치들이다. 인증된 파트너십, 게이팅된 API 액세스, 시간이 쌓일수록 자산화되는 데이터, 네트워크 효과 같은 것들은 에이전트가 아무리 똑똑해져도 그 자체를 만들어 낼 수 없는 영역이다. 이런 자산은 그 존재만으로 인프라가 된다.
예를 들어 MMP(Mobile Measurement Partner)의 가치는 분석 능력 그 자체보다 광고 네트워크와의 공식 연동, 검증된 측정 방식, 전환 데이터가 오가는 신뢰 구조, 오랜 시간 쌓인 어트리뷰션 데이터 모델에서 나온다. 에이전트가 아무리 똑똑해져도 이런 인증된 연결망을 혼자 만들 수는 없다. 그래서 좋은 MMP는 에이전트가 성과를 만들기 위해 호출하는 인프라가 된다.
두 갈래를 합치면, 에이전트가 직접 만드는 것보다 호출해서 쓰는 편이 합리적인 모든 종류의 서비스가 인프라가 된다.
이런 인프라는 이미 우리 주변에 많이 깔려 있다.
세 가지 모두 같은 패턴 위에 서 있다. 만들 수는 있지만, 만드는 것보다 호출해서 쓰는 편이 합리적인 영역. 그리고 이런 영역은 에이전트 시대에 더 강해진다. 에이전트가 직접 코드를 짜서 처리하기보다, 잘 검증된 인프라를 한 번 호출하는 편이 빠르고 안전하기 때문이다.
여기서 짚어 둘 변화 한 가지가 있다. 인프라를 매일 호출하는 사용자는 에이전트로 바뀌지만, 그 인프라에 비용을 지불하는 구매자는 여전히 사람이다. 에이전트 시대의 인프라는 두 명의 손님을 동시에 만족시켜야 한다.
과거의 SaaS는 PT 코치 모델에 가까웠다. 운동을 받는 사람과 결제하는 사람이 같았기 때문에 한 사람만 설득하면 됐다. 지금은 학원 원장 모델에 가깝다. 학생에게 실제로 도움이 되는 수업을 해야 하고, 동시에 부모가 그 효용을 이해하고 지갑을 열어야 한다.
에이전트 시대의 인프라도 정확히 그 자리에 선다. 에이전트에게는 안정적이고 예측 가능한 호출 환경, 좋은 스키마, 깨지지 않는 액션이 필요하다. 사람 구매자에게는 그 인프라가 자기 비즈니스에 어떤 효용을 만들어 주는지가 보여야 한다.
두 손님 중 한쪽만 만족시키는 인프라는 살아남기 어렵다고 본다. 사람만 보이고 에이전트가 못 쓰는 인프라는 호출량 자체가 늘지 않는다. 에이전트만 잘 쓰고 사람 구매자가 효용을 이해하지 못하는 인프라는, 호출량이 늘어도 청구서 앞에서 끊긴다.
그래서 좋은 인프라의 기준도 바뀐다.
이 기준에 부합하는 인프라가 살아남는다. 그러지 못하는 SaaS는, 자기 위에 사람이 앉아 있던 동안에는 가치를 만들었지만 그 사람이 사라지는 순간 가치도 같이 사라질 가능성이 높다.
자연스럽게 다음 질문이 따라온다. 그러면 무엇이 약해지는가.
두 갈래 사이에 낀 것들이다. 결과를 직접 만들어 주지도 못하면서, 에이전트가 호출해서 쓸 인프라도 되지 못하는 것들이다. 다시 말해 "사람이 마우스로 누르는 과정을 매끄럽게 해 주는 데에만 충실했던" 소프트웨어다.
한때 이 자리는 SaaS의 본진이었다. 워크플로우 도구, 디자인이 깔끔한 협업 툴, 클릭 몇 번을 줄여 주는 자동화 도우미. 모두 사람이 그 화면 앞에 앉아 있다는 전제 위에 세워진 가치였다.
에이전트가 그 자리에 대신 앉기 시작하면, 매끄러움 자체에 대한 수요가 줄어든다. 중간 지대로 떨어지는 소프트웨어에는 몇 가지 공통된 신호가 있다.
이 자리에 있는 소프트웨어가 가야 할 길은 둘 중 하나다. 결과를 책임지는 쪽으로 한 단계 위로 올라가거나, 자기 안의 한 부분을 에이전트가 호출할 수 있는 인프라로 떼어내거나. 둘 다 못 할 때, 약해진다는 표현이 사라진다는 표현으로 바뀌는 데는 그리 오래 걸리지 않는다.
마테크 서비스들은 이 갈림길 위에서 흥미로운 자리에 서 있다. 두 속성을 함께 갖기 때문이다.
첫째, 마테크 제품이 가진 온톨로지, 즉 데이터 모델과 분석·실행 환경 위에서 AI 에이전트를 돌려 결과를 만들어 내는 기능을 출시할 수 있다. 결과형 소프트웨어 쪽으로 가는 길이다.
둘째, 그 자체로 에이전트의 인프라가 되어 간다. 에이전트가 행동 로그를 직접 적재하고 퍼널을 다시 만드느니, 이미 정제된 마테크 솔루션을 호출해서 일하는 편이 압도적으로 빠르고 싸기 때문이다. 인프라형 소프트웨어 쪽으로 가는 길이다.
실제로 돌아가는 사례 하나를 짚어 보자.
요즘 나는 AI 에이전트로 Amplitude를 운영하고 있다.
흐름은 이렇다. 에이전트에게 Amplitude API 접근 권한을 주면, 매일 데이터를 가져와 임팩트가 큰 개선 대상을 판단한다. 그 페이지를 열어 UI/UX를 분석하고, A/B 테스트 가설을 도출하고, 코드로 구현한 PR을 올린다. 내가 승인하면 Experiment ID와 Variant 정보가 Event Property에 주입되고, 결과는 Amplitude Funnel Chart로 분석된다. 분석, 가설, 구현, 측정이 하나의 루프로 묶이는 것이다.
이건 단순한 아이디어가 아니라, 이미 내부에서 실험하고 있는 실제 워크플로우에 가깝다. 에이전트가 마테크 인프라 위에서 어떤 방식으로 일하게 되는지 보여 주는 좋은 단서다.
사용자 행동 로그를 데이터 웨어하우스에 직접 적재하고, 일일이 쿼리를 짜서 분석해야 했다면 이 자동화는 훨씬 오래 걸렸을 것이다. 또는 만들지 못했을 가능성이 높다. Amplitude가 가진 잘 정의된 데이터 모델과 API가 그 시간을 통째로 압축해 주었다고 본다.
이 워크플로우에서 진짜로 일어난 변화는 단순한 자동화가 아니다. Amplitude의 온톨로지가 에이전트의 작업 표면(work surface)이 되었다는 것이다. 에이전트는 그 위에서 가설을 세우고, 실험을 굴리고, 결과를 읽는다. Amplitude는 더 이상 PM이 들여다보는 대시보드가 아니라, 에이전트가 일하러 출근하는 작업장이 되어 가고 있다.
이 사례가 보여 주는 것은 단순하다. 마테크 솔루션이 이미 가진 인프라적 속성은 그대로 에이전트의 능력으로 환산된다.
에어브릿지는 이 논리에서 더 직접적으로 인프라에 가깝다. 모바일 마케팅 성과를 읽으려면 SDK, 광고 네트워크 연동, 딥링크와 포스트백, 전환 이벤트 정의, 플랫폼 변화에 맞춘 측정 규칙이 필요하다. 에이전트가 좋은 가설을 세워도 어떤 캠페인이 낭비되고 어떤 유저가 실제 가치로 이어졌는지 믿을 수 없다면 다음 액션을 정할 수 없다.
그래서 Airbridge의 방향은 더 보기 좋은 대시보드에 머물지 않는다. 우리가 쌓아 온 측정 데이터, SDK, API, 파트너 연동, 어트리뷰션 규칙을 에이전트가 호출할 수 있는 작업 표면으로 바꾸는 것이다. 에이전트가 예산, 딥링크, 장기 가치에 대한 질문을 던지고 Airbridge를 통해 답을 얻을 수 있어야 한다.
이미 이 변화는 고객 현장에서 시작되고 있다. 크몽의 에어브릿지 API 자동화 사례를 보면, Airbridge가 AI 에이전트의 인프라로 활용되는 방식이 잘 드러난다. 크몽은 Actuals Report API와 AI 코딩 어시스턴트로 리포트 수집, 매핑, 대시보드 업데이트를 자동화했고, 매일 30분 걸리던 작업을 5분으로 줄였다. 핵심은 Airbridge의 API와 측정 데이터가 AI의 실행 능력으로 바뀌었다는 점이다.
그렇게 되면 Airbridge는 에이전트가 성과를 만들기 위해 호출하는 인프라이자, 고객이 더 나은 의사결정과 실행 결과를 얻도록 돕는 결과형 소프트웨어가 된다.
우리가 만드는 모든 SaaS 제품 앞에 같은 질문이 놓여 있다. 우리는 결과를 주는 쪽인가, 에이전트가 쓰는 인프라인가, 아니면 그 사이에 낀 무언가인가. 답이 분명한 회사는 적지만, 답을 미룰 수는 없다. AB180은 이 두 부문에 모두 도전하기로 했다.
한쪽에서는 우리가 쌓아 온 데이터 파이프라인, SDK, API를 에이전트가 쓰기 쉬운 형식으로 인프라화한다. 다른 한쪽에서는 특수한 목적을 깊게 수행하는 에이전트를 직접 만든다. 이미 진행 중인 Amplitude 운영 자동화와 크몽의 Airbridge API 자동화가 그 방향의 초기 신호다.
한 가지 분명히 해 두고 싶다. 우리는 파운데이션 모델과 경쟁하지 않는다. 파운데이션 모델의 능력을 우리 인프라 위에서 더 강하게 만들거나, 파운데이션 모델이 직접 건드리지 않는 영역을 채우는 방식이다. 거대 모델과 충돌하는 길이 아니라, 그들과 맞물려 돌아가는 길이다. 구체적으로는, 에이전트가 우리 SDK·API를 호출해 측정 데이터를 가져가고, 그 데이터를 해석해 다음 마케팅 액션을 만든다. 우리가 깊게 가는 자리는 그 호출의 신뢰성과, 호출 결과가 비즈니스 결정으로 이어지는 자리다.
쉽지 않은 길이라는 걸 안다. 그래서 같이 만들어 갈 사람을 찾고 있다. 이 변화는 제품을 만드는 사람에게만 해당하지 않는다. 이런 소프트웨어를 고객에게 설명하고, 시장에 전달하고, 실제 매출로 연결할 세일즈와 마케팅 동료도 많이 필요하다.
10년의 엔터프라이즈 SaaS 경험은 이 변화 앞에서 한 줄로 요약된다. 사람을 거드는 기술에서, 사람의 결과를 책임지는 기술로. 그 한 줄을 진지하게 받아들이는 사람이라면, 우리가 함께 풀고 싶은 문제가 정말 많다.
사라지지 않는다. 다만 SaaS가 가치를 만드는 방식이 바뀐다. 살아남는 SaaS는 결과를 직접 만들어 주거나, 에이전트가 호출하는 인프라가 되는 두 부류다. 그 사이 "사람이 마우스로 누르는 과정을 매끄럽게 해 주던" 중간 지대만 약해진다.
에이전트가 직접 만드는 것보다 호출해서 쓰는 편이 합리적인 모든 종류의 서비스를 가리킨다. 클라우드·DNS 같은 전통적인 인프라뿐 아니라, 검색 API·발송 인프라·검증된 측정 데이터·게이팅된 파트너십 연동이 모두 여기에 포함된다.
두 속성을 함께 갖는다. 마테크가 가진 데이터 모델 위에서 AI 에이전트를 돌려 결과를 만들어 내는 결과형 기능을 출시할 수 있고, 동시에 정제된 측정 데이터와 API가 에이전트가 호출하는 인프라가 되기도 한다.
