버튼 하나 더 말고, 문제 하나 더 풀기

요즘 눈에 띄는 변화가 있다. 주변의 많은 제품이 MCP(Model Context Protocol)나 에이전트 연동에 집중하고 있다. 구글은 커머스 영역에서 UCP(Universal Commerce Protocol)를 내놓으며 같은 길을 걷고 있다. AI 검색에서 Gemini까지 결제가 통합되면 판매자는 프로토콜만 구현해도 AI 생태계에 자연스럽게 녹아든다. 처음에는 기술 트렌드의 하나로만 보였다. 단순한 변화는 아니다. 한때는 슬랙 연동, 노션 연동이 사용자 편의의 방향이었다. 이제 MCP와 에이전트가 그 자리를 잡아가고 있다. 프론트엔드와 UI의 자리를 Cursor나 Claude 같은 채팅 프로그램이 차지한다. 서비스 제공자는 MCP 같은 프로토콜로 필요한 기능만 열어주면 되는 구조가 만들어진다. 연동 방식이 바뀌는 것이 아니라, 제품이 가치를 전달하는 방식 자체가 바뀌고 있다. 여전히 많은 팀은 UI를 중심으로 제품을 만든다. 그렇게 만들다 보면 기능이 자연스럽게 늘어난다. 새 버튼, 설정 옵션, 필터와 예외 처리가 쌓여 간다. 사용성은 좋아진다. 대신 제품 가치가 뭔지는 흐려진다. "이걸로 뭘 할 수 있나요?"에는 대답할 수 있게 된다. "그래서 뭐가 해결되나요?"에는 말문이 막힌다. 기능은 많아졌는데 가치는 희석된다. MCP 같은 프로토콜을 염두에 두고 설계하면 질문 자체가 바뀐다. "이 기능을 UI 어디에 배치할까?"가 아니라 "에이전트가 이 도구를 호출했을 때 어떤 문제가 해결될까?"를 묻게 된다. 이 질문에 명확한 답이 없다면 굳이 만들지 않아도 된다. 기능 개수는 줄어들지만 가치 밀도는 높아진다. 기능은 줄어들어도 가치는 더 뾰족해진다. 그런 차이는 설계의 기본 단위에서도 드러난다. 기존에는 사용자 플로우를 중심으로 생각했다. 사용자가 어디서 막히는지, 어느 버튼에서 이탈하는지, 어떤 화면에서 혼란스러워하는지 분석했다. 그걸 개선했다. 전체 여정을 부드럽게 만드는 것을 목표로 했다. 에이전트 중심으로 생각하면 플로우보다 태스크가 중심이 된다. 입력이 뭐고, 중간에 어떤 판단을 해야 하고, 최종 결과물이 무엇인지. 이 세 가지가 설계의 축을 이룬다. 여정의 매끄러움보다 일의 완결성이 더 중요해진다. 시작보다는 끝이 중요하다. 시작이면서 끝이 될 수 있으니까. 로드맵을 짜는 방식도 달라졌다. 예전에는 "다음 분기에 어떤 기능을 추가할까?"라고 물었다. 이제는 "다음에 어떤 판단을 자동화할까?"를 묻게 된다. 진화 과정은 대체로 비슷하다. 처음에는 데이터 수집을 자동화한다. 그다음에는 분류와 요약을 자동화한다. 마지막에는 특정 의사결정의 일부를 제품이 대신하기 시작한다. 단순한 기능 확장이 아니다. 사용자의 사고 과정 일부를 제품이 점점 흡수해 가는 과정에 해당한다. 에이전트가 도구를 호출할 때 보는 것은 화면이 아니다. "이 도구가 어떤 결과를 주는가"만 본다. 그래서 외형이나 UX보다 제품과 서비스가 실제로 제공하는 가치가 더 중요해진다. 그 가치의 대부분은 자신이 쌓은 데이터와 그 안에 들어 있는 인사이트다. 예를 들어 CRM에서 "작년에 연락했다가 결론 없이 끝난 고객들 뽑아 주고, 올해 다시 연락해서 미팅 예약까지 잡아줘"라고 하면 에이전트가 처리할 수 있다. 예전 같으면 검색 필터를 여러 개 만들고, 리스트 화면, 예약 플로우, UI를 잔뜩 구현해야 했다. 이제는 API만 연결하고 응답 카드만 만들면 된다. 혹은 에이전트가 "예약 만들어 두었어요"라고만 하고 끝내도 된다. 앱스토어 리뷰를 모아두는 서비스도 마찬가지다. 리뷰 텍스트와 메타데이터가 정리되어 있으면 "불만 포인트만 뽑아줘"를 한 번에 해결해 준다. UI를 어떻게 꾸몄는지보다 어떤 데이터를 얼마나 잘 다루는지가 호출 이유가 된다. 변화는 설계에만 머물지 않는다. 유통 채널에서도 흥미로운 변화가 생기고 있다. 사용자가 더 이상 우리 웹사이트를 직접 방문하지 않는다. 이미 그 신호들은 여러 곳에서 드러난다. Cursor나 Claude 같은 채팅 프로그램이 클라이언트 역할을 한다. 서비스 제공자는 MCP 서버로 기능만 열어주면 되는 구조다. 커머스도 마찬가지다. 구글 UCP에서는 검색과 Gemini가 클라이언트가 된다. 판매자는 프로토콜만 구현하면 AI 화면에서 바로 구매가 이루어진다. 이때 제품은 더 이상 독립적인 웹서비스가 아니다. 에이전트 생태계에 붙는 하나의 구성 요소가 된다. MCP 제공은 "예쁜 홈페이지 만들어서 사용자 유치하겠습니다"가 아니라 "프로토콜 잘 만들어서 사용자가 원하는 곳에서 우리 기능을 쓸 수 있게 하겠습니다"라는 전략을 뜻한다. 이게 훨씬 사용자 친화적이다. 사용자 입장에서는 새로운 앱을 배울 필요가 없다. 계정을 만들고 로그인할 필요도 없다. 그냥 평소 쓰던 채팅에서 말하면 된다. OpenClaw 사용자들의 실제 반응이 그 실효성을 보여준다. "Gmail, Calendar, WordPress, Hetzner를 Telegram에서 한 번에 관리해요." 각각의 앱을 열고 로그인하고 메뉴를 찾아 헤맬 필요가 없다. 그냥 텔레그램에서 말하면 된다. "핸드폰으로 걸으면서 코드 스펙 파일을 만들었어요." 컴퓨터 켜고 에디터 열고 환경 세팅할 필요가 없다. 산책하면서 자연어로 말하면 끝이다. "WhatsApp으로 항공편 체크인했어요." 항공사 앱 찾고, 비밀번호 찾고, 메뉴 뒤져가며 체크인 버튼을 누를 필요가 없다. 그냥 채팅으로 해결된다. OpenClaw 사용자들이 공통적으로 하는 말이 있다. "새로운 걸 배울 필요가 없어요." 기존에 쓰던 채팅 앱에서 자연어로 말하면 모든 게 해결된다. 에이전트가 편하면 사용자도 편하다. 에이전트가 우리 서비스를 쉽게 호출할 수 있으면 사용자는 복잡한 UI를 배울 필요가 없다. 여러 서비스를 넘나들며 통합적으로 작업할 수 있고, 언제 어디서든 일관되게 접근할 수 있다. 매번 같은 정보를 반복 입력할 필요도 없다. 사용자와 서비스 사이의 마찰이 근본적으로 사라진다. 이런 흐름이 한데 모이면 한 가지가 분명해진다. 결국 MCP와 에이전트 중심 설계는 기술의 문제가 아니라 방향의 문제다. 아직 다들 이렇게 하고 있지는 않지만, 제품의 가치를 제대로 전달하려면 이런 방향으로 틀어야 한다. "우리가 뭘 만들 수 있을까?" 대신 "우리가 사용자 의도를 파악해서 어떤 걸 해줄 수 있을까?"를 묻게 만든다. 이 질문을 기준으로 제품을 재구성하면 기능은 줄어든다. 가치는 더 뾰족해진다. 구체적인 나아갈 방향은 명확하다. UI를 예쁘게 만들지 말고, 에이전트가 완벽하게 쓸 수 있는 도구를 만들어야 한다. 그게 진짜 사용자 중심 설계다. 사용자는 UI를 배우고 싶어 하지 않는다. 새로운 앱을 탐험하고 싶어 하지 않는다. 그냥 목적을 달성하고 싶을 뿐이다. 그 목적 달성을 가장 자연스럽게 도와주는 방식은 에이전트를 통한 대화다. 중간 과정의 복잡함은 에이전트가 처리한다. 사용자는 평소 쓰던 채팅에서 자연어로 말하기만 하면 된다. MCP와 에이전트 중심 설계가 만들어내는 새로운 제품 경험의 본질은 여기 있다. 버튼 하나를 더하기보다 문제 하나를 완전히 해결하는 편에 무게를 두는 편이 맞다.