'더 많은 기능'이 곧 '더 좋은 제품'이라는 등식은 AI 시대에 들어서면서 더 위험해졌다. 생성형 AI 덕분에 기능 하나를 추가하는 비용이 극적으로 낮아졌기 때문이다. 붙이는 데 드는 마찰이 줄어들수록, 걷어낼 이유를 먼저 묻는 힘은 더 의도적으로 설계해야 한다. 최근 잇따라 등장한 세 가지 사례는 서로 다른 맥락에서 출발하지만, 결국 같은 방향을 가리킨다.
8단계 폼을 걷어낸 이유
1인 개발자용 기획 도구 orot은 얼마 전 2.0 재설계를 공개했다. 아이디어를 요구·기능·화면으로 연결하는 도구였는데, 실제 사용 흐름을 들여다보니 문제가 선명하게 드러났다. 도구가 '기획을 도와주는' 것이 아니라 '폼을 8개 채우게 하는' 도구가 되어 있었다는 것이다. 가치 곡선이 거꾸로였다.
재설계의 핵심은 뺄셈이었다. 페르소나 분석, 핵심 가치 정의 같은 단계를 필수 플로우에서 제거하고, '아이디어 → 불편 → 요구 → 기능 → 화면'이라는 단일 사슬 하나로 압축했다. 제거된 단계들이 나쁜 것이어서가 아니다. MVP를 만드는 데 반드시 필요한 순간이 아니었기 때문이다. 오히려 끊긴 사슬—요구 없는 불편, 화면 없는 기능—이 '다음에 할 일'을 자연스럽게 드러내는 내비게이션이 됐다. AI는 여전히 선택지로 남아 있다. 아이디어 한 줄에서 사슬 전체의 첫 초안을 받거나, 항목별로 패킷을 복사해 ChatGPT·Claude·Gemini와 왕복하는 방식이다. AI가 흐름의 주인이 아니라 사용자 판단을 보조하는 도구로 위치가 재정의된 것이 이 재설계의 본질이다.
자동화 컨설턴트가 "하지 말라"고 말하는 이유
자동화 컨설턴트 Archit Mittal은 dev.to 기고에서 역설적인 고백을 했다. 자신의 비즈니스가 자동화에 달려 있음에도, 가장 기억에 남는 조언은 항상 "이건 자동화하지 마세요"였다는 것이다. 그가 소개한 사례는 구체적이다. 고객 전환율 40%를 자랑하던 고액 컨설팅 사업자가 팔로업을 자동화했더니, 한 달 만에 전환율이 정확히 40% 떨어졌다. 기술적으로는 완벽한 시스템이었다. 문제는 가정이었다. 고객이 사는 건 서비스가 아니라 그 사람 자체였고, 자동화된 메시지는 관계가 아니라 시스템의 흉내였다.
그가 제안하는 STAR 테스트는 단순하지만 날카롭다. 프로세스가 최소 6개월 이상 안정적으로 유지됐는가(Stable), 30분 안에 신입에게 설명할 수 있는가(Transferable), 절감 비용이 구축·유지 비용을 실제로 초과하는가(Arithmetic), 인간의 개입 자체가 가치의 이유인가(Replaceable). 이 네 가지 중 하나라도 통과하지 못하면, 자동화는 투자가 아니라 비용이 된다. AI를 붙이기 전에 이 필터를 먼저 돌리는 것이 진짜 자동화 역량이다.
비용의 85%는 아키텍처 설계 실패였다
같은 필자가 공개한 또 다른 사례는 AI API 비용 최적화다. 하루 4,000건 주문을 처리하는 인도 이커머스 업체의 월 AI API 청구서는 85,000루피였다. 3주 후 12,400루피로 줄었다. 기능을 삭제하거나 품질을 낮춘 것이 아니다. 고객 만족도는 오히려 3% 올랐다.
핵심 문제는 단순했다. '고객 불만이 배송 문제인가, 결제 문제인가'를 분류하는 단순 요청과 2,000자 상품 설명을 생성하는 복잡한 요청이 동일한 최고급 모델로 처리되고 있었다. 시니어 회계사에게 데이터 입력을 맡기는 것과 같은 구조다. 모델 라우팅—작업 복잡도에 따라 경량·중간·고급 모델을 분기하는 것—만으로 청구액이 38,000루피로 내려갔다. 반복되는 시스템 프롬프트를 캐싱하고, 실시간 처리가 필요 없는 내부 리포트를 배치로 묶고, 출력 토큰에 명시적 길이 제약을 걸었다. 각각의 변화는 단순하다. 그러나 이 모든 것은 아키텍처 결정이지, 프롬프트 튜닝이 아니다.
세 사례가 동시에 가리키는 것
세 사례는 도메인이 다르다. UX 설계, 자동화 전략, AI 비용 구조. 그런데 문제의 구조는 동일하다. 처음에 '일단 다 붙이는' 방향으로 설계했고, 실제 가치를 측정했을 때 제거가 해법이었다는 것이다.
프론트엔드와 프로덕트 설계 관점에서 이 흐름은 구체적인 질문으로 번역된다. 이 UI 단계가 사용자에게 실제로 필요한 순간은 언제인가? 이 자동화가 관계를 대체하는가, 아니면 관계를 위한 여백을 만드는가? 이 API 호출은 실제로 프리미엄 모델이 필요한 작업인가? 세 질문 모두 기능을 추가하기 전에 해야 하는 물음이다.
AI 시대의 설계 역량은 빼기 근육이다
AI가 기능 구현 속도를 높일수록, '붙일 수 있다'와 '붙여야 한다'의 간격은 벌어진다. orot 2.0이 8단계를 1개 사슬로 줄인 결정, 자동화 컨설턴트가 120만 루피짜리 시스템을 걷어낸 결정, AI API 구조를 모델별로 분기한 결정—세 가지 모두 기술 역량이 아니라 판단 역량의 문제였다.
빠르게 만드는 것과 오래 쓰이는 것 사이의 거리는 기능의 수가 아니라 걷어낼 것을 먼저 묻는 설계 태도에서 결정된다. AI 도구가 프로토타입 속도를 극적으로 높여주는 지금, 프로덕트와 UI/UX 설계자에게 가장 필요한 근육은 '빠르게 붙이는 능력'이 아니라 '무엇을 빼야 하는지를 먼저 설계하는 능력'이다. 이 근육은 AI가 대신해주지 않는다.