에필로그. 에이전트 이후의 소프트웨어
소프트웨어의 역사는 화면을 바꾸는 역사이기도 했다. 처음에는 명령어를 외워서 입력해야 했다. 그다음에는 버튼과 메뉴가 생겼고, 웹이 등장하면서 브라우저가 운영체제 위의 또 다른 운영체제처럼 보이기 시작했다. 모바일 시대에는 작은 화면 안에 앱 아이콘이 질서 있게 늘어섰다. 그리고 이제 우리는 다시 한 번 인터페이스의 변화를 지나고 있다. 이번에는 화면이 아니라 행동의 단위 가 바뀐다. 사람은 기능을 찾기보다 의도를 말하고, 시스템은 화면을 보여주기보다 일을 끝내려 한다.
이 변화의 이름이 바로 에이전트다.
하지만 여기서 가장 먼저 버려야 할 오해가 있다. 에이전트가 등장한다고 해서 기존 소프트웨어가 갑자기 사라지는 것은 아니다. 회계 시스템, CRM, ERP, 디자인 툴, 개발 도구, 결제 인프라, 데이터베이스는 여전히 남는다. 아니, 오히려 더 중요해진다. 에이전트는 허공에서 일하지 못한다. 결국 할 수 있는 행동은 기존 시스템이 제공하는 데이터, 권한, 규칙, API 위에서만 가능하기 때문이다.
그래서 더 정확한 질문은 이것이다. 에이전트는 기존 소프트웨어를 대체하는가, 흡수하는가, 아니면 새로운 인터페이스 계층이 되는가?
답은 하나가 아니다. 셋 다 일어난다. 다만 서로 다른 층위에서 일어난다.

소프트웨어는 사라지지 않고 뒤로 물러난다
앞으로도 기업은 데이터 모델을 설계하고, 승인 규칙을 만들고, 예산 한도를 정하고, 로그를 남기고, 감사 가능한 기록을 보관해야 한다. 이 일은 여전히 전통적인 소프트웨어의 몫이다. 장부는 장부여야 하고, 재고는 재고여야 하며, 권한은 권한이어야 한다. 아무리 자연어 인터페이스가 편해져도 회계 처리의 정확성이나 주문 상태의 일관성까지 대충 넘어갈 수는 없다.
즉, 에이전트는 시스템의 바닥을 없애지 않는다. 대신 그 위에 올라가는 방식만 바꾼다.
예전에는 사용자가 직접 메뉴를 찾아 들어가고, 폼을 작성하고, 여러 화면을 오가며 작업을 완성했다. 앞으로는 그 과정의 많은 부분이 대화나 지시, 혹은 목표 중심의 요청으로 압축된다. 사용자는 "지난달 북미 매출이 떨어진 원인을 정리하고, 상위 세 개 가설을 표로 보여 줘"라고 말한다. 그러면 에이전트는 여러 시스템을 넘나들며 데이터를 읽고, 분석하고, 초안을 만들고, 필요한 경우 사람 승인을 기다린 뒤 다음 행동으로 이어진다.
화면은 없어지지 않는다. 다만 모든 사람이 늘 화면부터 보지는 않게 된다. 화면은 점점 기본 인터페이스 가 아니라 검토와 확인을 위한 인터페이스 로 이동한다. 평소의 실행은 에이전트가 맡고, 중요한 결정과 예외 상황은 사람이 화면에서 확인하는 식이다.
조금 과장해서 말하면, 많은 소프트웨어는 앞으로 "보는 도구"에서 "뒤에서 일하는 도구"로 성격이 바뀐다.
어떤 제품은 에이전트에게 흡수된다
모든 소프트웨어가 같은 속도로 변하지는 않는다. 특히 절차가 고정되어 있고, 사용자가 반복적으로 비슷한 작업을 수행하는 제품은 에이전트에게 기능 일부를 빠르게 내어줄 가능성이 크다.
예를 들어 출장 정산, 단순 고객 응대, 내부 문서 검색, 기본 보고서 작성, 일정 조율, 티켓 분류 같은 일은 원래도 사람이 규칙을 따라가며 처리하던 작업이다. 이런 영역에서는 복잡한 메뉴 구조보다 "해 줘"라는 요청 하나가 더 자연스럽다. 사용자는 기능명을 기억할 필요가 없고, 시스템은 필요한 단계들을 알아서 실행한다.
이런 상황에서는 기존 제품의 일부 표면이 얇아진다. 메뉴는 줄고, 설정 화면은 뒤로 숨고, 사용자는 앱을 배우기보다 에이전트에게 일을 맡기는 법을 배우게 된다. 제품 입장에서는 다소 아이러니한 일이다. 열심히 만든 UI가 사라지는 것처럼 보일 수 있기 때문이다.
하지만 실제로 사라지는 것은 가치가 아니라 조작 방식 이다. 사용자가 사랑했던 것은 버튼의 위치가 아니라 일을 빨리 끝내는 경험이었다. 에이전트가 그 경험을 더 짧은 경로로 제공한다면, 제품은 약해지는 것이 아니라 더 깊이 스며든다.
어떤 제품은 오히려 더 강해진다
반대로 에이전트 시대에 더 강해지는 제품도 있다. 특히 구조화된 데이터, 명확한 권한 체계, 잘 설계된 API, 안정적인 실행 환경을 가진 제품은 에이전트 생태계의 핵심 인프라가 된다.
에이전트는 똑똑해 보여도, 실제로는 믿을 수 있는 도구가 있어야 힘을 쓴다. 고객 정보를 읽고 싶다면 CRM이 필요하고, 결제를 처리하려면 결제 시스템이 필요하며, 문서를 찾으려면 검색 가능한 저장소가 필요하다. 다시 말해 에이전트가 전면에 설수록, 뒤에서 기능을 제공하는 플랫폼의 가치도 함께 올라간다.
예전에는 좋은 제품이 "사람이 쓰기 좋은 화면"을 갖추는 데 집중했다면, 앞으로의 좋은 제품은 "에이전트가 안전하게 호출하기 좋은 기능"도 함께 갖춰야 한다. 버튼만 잘 만드는 것으로는 부족하다. 함수처럼 호출 가능한 인터페이스, 명확한 실패 응답, 세밀한 권한 제어, 추적 가능한 로그가 중요해진다.
그래서 앞으로의 소프트웨어는 두 종류의 사용자를 동시에 상대하게 된다. 한쪽에는 사람 사용자가 있고, 다른 한쪽에는 에이전트라는 새로운 사용자층이 있다. 이 둘을 모두 만족시키는 제품이 점점 유리해진다.
에이전트는 새로운 앱이 아니라 새로운 층이다
에이전트를 하나의 독립된 앱으로만 보면 그림이 작아진다. 더 큰 변화는 에이전트가 여러 시스템 위에 놓이는 새로운 실행 계층 이 된다는 점이다.
이 계층은 사용자의 의도를 받아서 적절한 도구를 고르고, 상태를 관리하고, 중간 결과를 저장하고, 사람 승인과 정책 검사를 거쳐 실제 행동으로 연결한다. 과거에는 사용자가 직접 이 모든 단계를 이어 붙여야 했다. 이제는 에이전트가 그 조립을 맡는다.
이 말은 곧 소프트웨어 설계의 중심축도 바뀐다는 뜻이다. 예전에는 화면 흐름과 폼 설계가 중심이었다면, 앞으로는 다음 질문들이 더 중요해진다.
이 시스템은 어떤 행동을 도구로 노출할 것인가
어떤 상태를 기억하고 어떤 상태는 버릴 것인가
어디까지 자동 실행하고 어디서 사람 승인을 받을 것인가
실패했을 때 어떻게 멈추고 어떻게 복구할 것인가
누가 어떤 권한으로 무엇을 대신할 수 있는가
여기서 핵심은, 이제 소프트웨어가 단지 정보를 보여주는 물건이 아니라 의도를 실행 가능한 행동으로 바꾸는 기계 가 된다는 점이다. 에이전트는 바로 그 변환기의 역할을 맡는다.
인터페이스는 점점 '기능 중심'에서 '의도 중심'으로 간다
기존 소프트웨어는 대개 기능 중심으로 구성된다. 이 메뉴는 보고서, 저 메뉴는 설정, 다른 메뉴는 권한 관리다. 사용자는 자신이 원하는 결과를 얻기 위해 먼저 제품이 어떤 구조로 설계되었는지 배워야 했다. 즉, 사람의 생각이 소프트웨어의 구조에 맞춰져야 했다.
에이전트는 반대 방향으로 간다. 사용자의 말, 맥락, 목표에서 출발해 필요한 기능을 찾아간다. 사람은 "무엇을 하고 싶은지"를 말하고, 시스템은 "어떻게 해야 하는지"를 계산한다.
물론 이 변화가 완전히 매끄럽기만 한 것은 아니다. 의도는 늘 모호하다. "좋게 정리해 줘"는 사람끼리도 해석이 다르다. 그래서 에이전트 시대의 인터페이스는 단순히 채팅창 하나로 끝나지 않는다. 좋은 에이전트 인터페이스는 질문을 되묻고, 선택지를 좁혀 주고, 중간 계획을 보여 주고, 중요한 순간에는 확인을 요청한다.
즉, 미래의 인터페이스는 화면이 사라지는 방향이 아니라, 화면의 역할이 바뀌는 방향 으로 진화할 가능성이 크다. 입력은 더 자유로워지고, 검토는 더 구조화되며, 실행은 더 자동화된다.
개발자는 화면만 만드는 사람이 아니라 실행 환경을 설계하는 사람이 된다
에이전트 이후의 소프트웨어에서 개발자의 역할도 달라진다. 예전에는 사용자 흐름을 화면에 잘 담고, 데이터베이스와 API를 연결하고, 오류를 막는 것이 핵심이었다. 앞으로도 이것들은 중요하다. 다만 여기에 한 층이 추가된다. 개발자는 이제 에이전트가 일할 수 있는 작업 환경 자체를 설계해야 한다.
그 환경에는 도구 인터페이스, 상태 저장 방식, 권한 경계, 관측 가능성, 평가 체계, 승인 절차가 포함된다. 한마디로, 에이전트를 위해 작은 디지털 직장을 만드는 셈이다. 책상은 도구이고, 메모장은 상태이며, 사내 규정은 정책이고, 팀장은 사람 승인 단계다.
그래서 앞으로의 소프트웨어 엔지니어링은 프론트엔드, 백엔드, 데이터, 보안을 따로 보는 것만으로 충분하지 않을 수 있다. 그 위에 에이전트 시스템 엔지니어링 이라는 감각이 필요해진다. 어떤 모델을 쓰느냐보다, 어떤 구조 안에서 일하게 하느냐가 품질을 더 크게 좌우하기 때문이다.
재미있는 점은 여기서 고전적인 소프트웨어 원칙이 다시 살아난다는 것이다. 명확한 인터페이스, 작은 책임 단위, 예측 가능한 상태 전이, 감사 가능한 로그, 안전한 기본값 같은 원칙 말이다. 에이전트는 새롭지만, 그것을 제대로 굴리는 방법은 오히려 오래된 공학의 미덕을 더 강하게 요구한다.
회사는 앱을 도입하는 대신 '디지털 노동력'을 설계하게 된다
에이전트 시대의 기업은 더 이상 단순히 소프트웨어를 구매하지 않을 가능성이 크다. 대신 어떤 일을 사람에게 맡기고, 어떤 일을 자동화된 워크플로에 맡기고, 어떤 일을 에이전트에게 맡길지 설계하게 된다.
이때 중요한 것은 단순한 자동화 비율이 아니다. 더 중요한 것은 책임의 재배치 다. 사람은 예외를 처리하고, 판단을 내리고, 기준을 바꾸는 데 집중하게 된다. 에이전트는 탐색하고, 정리하고, 연결하고, 반복적인 조치를 수행한다. 워크플로는 정해진 절차를 안정적으로 실행한다. 세 가지가 서로 경쟁하는 것이 아니라 각자 잘하는 일을 나눠 갖는다.
이 구조가 자리 잡으면 조직의 소프트웨어 구매 기준도 달라진다. "UI가 예쁜가?"보다 "에이전트와 연결하기 쉬운가?"가 중요해질 수 있다. "사용자가 클릭 몇 번으로 할 수 있는가?"보다 "정책을 지키면서 자동 실행할 수 있는가?"가 더 중요한 질문이 된다.
결국 기업은 앱 목록을 관리하는 대신, 점점 능력의 목록 을 관리하게 될 것이다. 고객 조회 능력, 계약 검토 능력, 일정 조율 능력, 코드 수정 능력, 장애 분류 능력처럼 말이다. 그리고 그 능력들은 사람, 워크플로, 에이전트가 섞여 제공하게 된다.
소프트웨어는 '페이지의 집합'에서 '능력의 집합'으로 바뀐다
웹 시대의 사고방식으로 제품을 보면, 소프트웨어는 페이지들의 모음이다. 로그인 페이지, 대시보드 페이지, 설정 페이지, 목록 페이지, 상세 페이지가 있고 사용자는 그 사이를 이동한다. 하지만 에이전트 시대의 사고방식으로 보면, 소프트웨어는 페이지보다 능력의 조합에 가깝다.
사용자는 페이지에 들어가서 기능을 찾는 대신, 원하는 결과를 말하고 능력을 호출한다. 시스템은 그 능력을 실행한 뒤 필요할 때만 적절한 뷰를 제공한다. 보고서는 페이지가 아니라 결과물이 되고, 폼은 대화 중 수집되는 구조화 입력이 되며, 대시보드는 상시 탐색 도구가 아니라 예외와 현황을 점검하는 관제판에 가까워진다.
이 변화는 작아 보이지만 꽤 크다. 페이지 중심 설계에서는 사용자가 어디를 클릭할지 고민한다. 능력 중심 설계에서는 시스템이 어떤 계약으로 어떤 작업을 수행할지 고민한다. 전자는 화면 설계가 중심이고, 후자는 실행 설계가 중심이다.
에이전트가 소프트웨어 패러다임 변화로 보이는 이유가 바로 여기에 있다. 단순히 채팅 UI가 유행해서가 아니다. 소프트웨어를 조직하는 기본 단위가 화면에서 능력으로 이동하고 있기 때문 이다.
그래도 사람은 사라지지 않는다
에이전트의 미래를 말할 때 가장 흔한 실수는 사람을 너무 빨리 지우는 것이다. 그러나 실제 세계는 늘 애매하고, 책임은 여전히 사람의 이름으로 남는다. 계약서 최종 승인, 고객 환불 정책 변경, 대규모 지출, 의료적 판단, 인사 결정 같은 일은 앞으로도 사람의 검토를 필요로 할 가능성이 높다.
오히려 에이전트가 널리 퍼질수록 사람의 역할은 더 선명해질 수 있다. 사람이 해야 할 일은 직접 타이핑하고 복사 붙여넣기하는 것이 아니라, 기준을 정하고, 예외를 판단하고, 결과를 책임지는 일로 이동한다.
좋은 시스템은 사람을 빼는 시스템이 아니라, 사람을 더 중요한 위치에 놓는 시스템이다. 에이전트는 사람을 대체하는 환상이 아니라, 사람이 더 적은 마찰로 더 큰 일을 하게 만드는 도구일 때 오래 살아남는다.
앞으로 사라질 것들과 남을 것들
에이전트 이후의 소프트웨어에서 사라질 가능성이 큰 것은 '기능' 그 자체가 아니다. 더 많이 사라지는 것은 다음과 같은 것들이다.
사용자가 제품 구조를 먼저 배워야만 일을 처리할 수 있는 경험
같은 정보를 여러 화면에 반복 입력해야 하는 절차
검색, 요약, 분류, 초안 작성 같은 저밀도 반복 작업
사람에게 의미 없는 형식적 클릭과 이동
반대로 오래 남을 가능성이 큰 것도 분명하다.
신뢰할 수 있는 데이터 저장소
명확한 비즈니스 규칙과 정책 엔진
권한 관리와 감사 로그
사람 승인과 책임 소재
실패를 안전하게 다루는 운영 체계
즉, 화려한 겉모습보다 단단한 바닥이 더 중요해진다. 에이전트는 위를 유연하게 만들지만, 아래를 느슨하게 만들 수는 없다.
결국 남는 질문은 기술이 아니라 관점이다
이제 마지막으로 처음의 질문으로 돌아가 보자. 에이전트는 기존 소프트웨어를 대체하는가, 흡수하는가, 혹은 새로운 인터페이스 계층이 되는가.
가장 현실적인 대답은 이렇다. 에이전트는 소프트웨어를 없애지 않는다. 대신 소프트웨어를 사용하는 방식, 소프트웨어를 설계하는 방식, 소프트웨어를 조직 안에 배치하는 방식을 바꾼다. 어떤 제품은 표면 일부를 에이전트에게 내주고, 어떤 제품은 에이전트를 위한 기반 시설이 되며, 어떤 영역에서는 에이전트가 사람과 시스템 사이의 대표 인터페이스가 된다.
그리고 이 변화가 진짜 중요한 이유는, 그것이 새로운 기능 하나의 등장이 아니기 때문이다. 검색창이 추가된 것도 아니고, 자동완성이 조금 좋아진 것도 아니다. 우리는 지금 소프트웨어를 바라보는 단위를 바꾸고 있다. 앱, 페이지, 버튼, 메뉴 중심의 세계에서 목표, 능력, 실행, 감독 중심의 세계로 이동하고 있다.
앞으로의 좋은 제품은 단지 예쁜 화면을 가진 제품이 아닐 것이다. 사용자의 의도를 잘 이해하고, 적절한 도구를 안전하게 고르고, 필요한 상태를 기억하고, 실패를 품위 있게 다루고, 사람과 기계의 경계를 현명하게 나누는 제품일 것이다.
그런 의미에서 에이전트는 기능이 아니다. 하나의 모델도 아니다. 유행어는 더더욱 아니다.
에이전트는 소프트웨어가 다시 움직이기 시작했다는 신호다.
이제 소프트웨어는 더 이상 가만히 놓여 있는 화면이 아니다. 질문을 받고, 계획을 세우고, 도구를 고르고, 실행하고, 멈추고, 되묻고, 배운다. 우리는 프로그램을 사용하는 시대에서, 점점 일을 맡기는 시대 로 넘어가고 있다.
그리고 바로 그 점에서, 에이전트 이후의 소프트웨어는 이전보다 덜 기계 같고, 동시에 더 공학적이다. 겉으로는 더 자연스럽고, 속으로는 더 엄격하다. 사람 말은 더 잘 알아듣지만, 시스템 설계는 더 정교해야 한다.
미래의 소프트웨어는 아마 이렇게 보일 것이다. 눈앞에는 하나의 간단한 인터페이스가 있고, 그 뒤에는 수많은 도구와 정책과 상태와 검토 과정이 조용히 움직인다. 사용자는 그 복잡함을 모두 알 필요가 없지만, 만드는 사람은 그 복잡함을 정직하게 설계해야 한다.
결국 시대를 바꾸는 것은 더 똑똑한 답변이 아니다. 더 믿을 수 있는 실행 이다.
에이전트 이후의 소프트웨어는 바로 그 실행을 중심으로 다시 쓰이게 될 것이다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.