The End of Feature Discovery: AI가 기능을 골라 주면 성장팀의 일은 신뢰와 첫 성공으로 바뀐다
Lovable에서 성장을 맡은 Elena Verna는 사용자가 목표를 말하면 AI가 쓸 기능을 고르는 제품에서는 온보딩·내비게이션·인앱 넛지로 기능을 알리던 일이 대부분 사라진다고 봅니다. 대신 AI의 선택을 믿게 만드는 일과 빈 입력창에서 무엇을 맡길 수 있는지 알려 주는 일이 성장팀의 새 과제가 됩니다.
사용자가 목표만 말하면 AI가 알아서 기능을 고르는 제품에서는 기능을 찾게 하고 가르치던 성장 업무가 대부분 필요 없어집니다. 남는 일은 두 가지입니다. 소프트웨어가 자기 기능을 언제 쓸지 알게 만드는 일, 그리고 사용자가 AI의 선택을 믿고 더 큰 일을 맡기게 만드는 일입니다.
요약
Elena Verna는 AI 앱 빌더 Lovable에서 성장을 맡고 있고, 그 전에는 오랫동안 기능 채택(feature adoption)을 끌어올리는 일을 해 왔습니다. 그가 2026년 11월 뉴스레터 Elena’s Growth Scoop에 쓴 이 글은 자기 직업의 큰 몫이 사라지고 있다는 고백에 가깝습니다. 기존 소프트웨어에서 성장팀은 문제를 찾고, 기능을 만들고, 화면을 설계한 뒤, 사용자가 그 기능을 찾고 이해하고 익히도록 여정을 짰습니다. 단계마다 누군가가 책임지는 전환율 문제가 생겼습니다. 그렇게 애써도 새 기능을 쓰는 사람은 사용자 기반의 아주 작은 일부에 그친다고 그는 봅니다. 원문 표현으로는 “maybe 0.1% of your user base”입니다.
AI 네이티브 제품에서는 이 전제가 흔들립니다. 사용자가 목표를 말하면 소프트웨어가 그 목표에 필요한 기능을 골라 씁니다. 사용자는 존재조차 모르는 기능에서도 가치를 얻습니다. API, MCP(Model Context Protocol, AI가 외부 도구를 부르는 표준), 각종 연동을 거치면 제품 화면을 아예 열지 않을 수도 있습니다. Verna는 Lovable에서 온보딩이나 넛지를 거의 고민하지 않는다고 말합니다. 대신 새 문제가 생깁니다. AI가 사용자 대신 많은 선택을 하다 보니, 결과가 틀렸을 때 사용자는 무엇이 잘못됐는지 모른 채 떠납니다. 기능 발견은 사라져도 “이 제품에 무엇을 맡길 수 있나”를 알아내는 사용 사례 발견(use-case discovery)은 남습니다. 그래서 성장팀의 목표는 첫 성공 경험, 더 할 수 있는 일 보여 주기, 계속 맡기게 만드는 신뢰로 바뀝니다. 아래 절들은 이 전환을 메커니즘으로 풀고, 실제 제품과 사내 업무 도구에서 돌리는 방법을 덧붙입니다.
핵심 메커니즘
Feature Adoption Funnel: 기능 하나마다 생기는 전환 깔때기
기존 성장 업무의 기본 단위입니다. 기능 하나가 출시되면 사용자는 그 기능을 찾고, 무엇인지 이해하고, 쓰는 법을 익혀야 합니다. 세 단계가 각각 떨어져 나가는 지점이고, 성장팀은 온보딩 흐름, 내비게이션 개편, 라이프사이클 캠페인, 맥락형 넛지로 단계마다 전환율을 올립니다. 기능을 발견한 사용자가 더 오래 남았기 때문에 이 일은 정당했습니다.
문제는 긴장 관계입니다. 기능을 늘리면 제품이 할 수 있는 일은 넓어지지만 복잡해집니다. 복잡함은 성장팀이 끌어오고 싶은, 동기가 약한 사용자를 먼저 밀어냅니다. 저자는 이를 소프트웨어 비대화(software bloat)와 기능 정리 목록(kill list)으로 설명합니다. 개인화로 풀려고 해도 규모를 키우기 어렵고, 메뉴 위치를 정하는 회의가 끝없이 열립니다. 저자가 든 예는 후속 회의 하나에 24명이 초대된 2시간짜리 회의입니다.
언제 여전히 쓰나: 사람이 직접 화면을 조작하는 핵심 기능, 규제상 사용자가 절차를 알아야 하는 기능은 이 깔때기를 계속 관리해야 합니다.
Goal-to-Capability Routing: 사용자는 목표를, AI는 기능을 고른다
사용자가 “이번 주 고객 문의를 유형별로 묶어 보고서로 만들어 줘”처럼 결과를 말하면, AI가 그 결과에 필요한 기능 조합을 골라 실행하는 구조입니다. 입력은 자연어 목표, 처리는 AI가 기능 목록에서 쓸 것을 고르는 일, 출력은 완성된 결과입니다. 사용자는 중간에 어떤 기능이 쓰였는지 몰라도 됩니다.
저자는 이것이 소프트웨어를 조작하는 주체를 바꾼다고 봅니다. 화면을 돌아다니는 일을 점점 AI가 맡고, API·MCP·연동을 거치면 사용자는 제품에 로그인하지 않고도 결과를 받습니다. 그러면 “사용자가 기능을 발견해야 한다”는 전제 자체가 무너집니다.
언제 쓰나: 목표가 결과물로 표현되고, 중간 절차는 사용자가 신경 쓰지 않는 일에 맞습니다. 사용자가 절차 하나하나를 통제하고 싶어 하는 일에는 아래 신뢰 메커니즘이 먼저 갖춰져야 합니다.
Agent-side Discovery: 이제 기능을 알아야 하는 쪽은 소프트웨어다
기능 발견이 사라진 것이 아니라, 발견해야 하는 주체가 사람에서 AI로 옮겨 갔다는 뜻입니다. 저자는 질문을 “사람이 이 기능을 쓰게 하려면?”에서 “소프트웨어가 자기 기능을 언제 써야 하는지 알고 있나?”로 바꿉니다. 누가 기능 사용을 결정하는지가 바뀐 것입니다.
저자의 경험이 그대로 예입니다. Lovable에서 그가 자주 부딪히는 불만은 에이전트가 어떤 기능의 존재를 모를 때뿐이고, 그럴 때는 사내 Slack 채널에서 고쳐 달라고 요청합니다. 기능을 사람에게 알리던 일이, 기능을 에이전트에게 알리는 일로 바뀐 셈입니다.
작은 예시(가상): 사내 구매 시스템에 “분할 발주” 기능이 새로 생겼는데 에이전트의 도구 설명에 빠져 있으면, 직원이 “납기 다른 품목은 나눠서 발주해 줘”라고 해도 에이전트는 수작업 안내만 합니다. 기능은 있는데 아무도 쓰지 않는 상태가 사람이 아니라 AI 쪽에서 재현됩니다.
Trust and Delegation: AI의 선택을 믿게 만들고, 맡기는 범위를 넓힌다
AI가 사용자 대신 결정할수록, 무언가 틀렸을 때 사용자는 원인을 모릅니다. 원인을 모르는 사용자는 떠납니다. 저자는 설계 질문 세 가지를 던집니다. 사용자가 모든 단계를 이해하지 않아도 과정과 결과를 믿게 하려면 어떻게 하나. AI가 무엇을 왜 결정했는지, 사람이 언제 끼어들어야 하는지 어떻게 보여 주나. 사소한 것까지 검토하게 하지 않으면서 행동을 되돌릴 수 있게 하려면 어떻게 하나.
이 관점에서는 성장 지표도 바뀝니다. 지금까지 제품팀은 기능 수, 참여, 상호작용, 로그인을 늘리는 쪽으로 최적화했습니다. 그런데 가장 좋은 경험은 직접 조작이 거의 없는 경험일 수 있습니다. 참여 지표는 떨어지는데 고객이 얻는 가치는 오를 수 있다는 뜻입니다. 저자가 보는 새 성장 동력은 사용자가 중요한 일을 맡기는 데 익숙해지는 것입니다. 작은 작업에서 쌓인 신뢰가 워크플로 전체로 번지고, 그래서 신뢰성·투명성·통제권이 곧 성장 레버가 됩니다.
Use-case Discovery: 빈 입력창은 무엇을 맡길 수 있는지 말해 주지 않는다
AI가 없애는 것은 기능 발견이지 사용 사례 발견이 아닙니다. 버튼과 메뉴로 가득한 기존 화면은 복잡하지만, 그 자체로 “이 제품은 이런 일을 한다”는 신호였습니다. “무엇을 하고 싶으세요?”라는 입력창 하나만 남기면 복잡함은 사라지지만 그 신호도 함께 사라집니다. 사용자는 무엇을 부탁해도 되는지 몰라 첫 문장을 쓰지 못합니다.
그래서 저자는 성장팀의 할 일을 세 가지로 다시 정의합니다. 사용자를 첫 의미 있는 결과까지 데려가기, 그다음 할 수 있는 일을 보여 주기, 계속 더 맡길 만큼 자신감을 쌓기입니다. 결과를 원하는 사용자에게는 특정 기능을 눌러 보라고 설득할 필요가 없다는 것이 그의 결론입니다.
AI Is the Product: AI를 기능 하나로 붙이면 옛 문제가 돌아온다
저자는 AI를 아이콘 하나 달린 기능으로 붙이고 “AI 기반”이라고 발표하는 방식을 경계합니다. 그렇게 하면 AI도 결국 성장팀이 홍보해야 할 기능 목록의 한 줄이 되고, 앞서 본 기능 발견 문제가 그대로 되살아납니다. AI가 기능을 고르는 구조의 이점은 AI가 제품의 입구일 때 생깁니다. 그는 “AI로 피벗합니다” 발표를 꼬집은 Felix Lee의 게시물을 함께 소개합니다.
통념과 다른 주장
흔히 이렇게 봅니다새 기능을 만들면 온보딩, 툴팁, 출시 메일로 사용자에게 알려야 쓰인다.
Verna는 이렇게 봅니다AI가 목표를 받아 기능을 고르는 제품에서는 사용자에게 기능을 알릴 필요가 대부분 사라지고, 에이전트가 그 기능을 알고 있는지가 중요해집니다.
근거기존 방식으로는 새 기능을 쓰는 사용자가 아마 0.1% 정도에 그쳤고, 그 자신이 Lovable에서는 기능 채택 업무를 거의 하지 않으며 에이전트가 기능을 모를 때만 수정을 요청합니다.
흔히 이렇게 봅니다참여, 상호작용, 로그인이 늘어야 제품이 잘되고 있는 것이다.
Verna는 이렇게 봅니다가장 좋은 경험은 직접 조작이 거의 없는 경험일 수 있고, 참여 지표가 떨어져도 고객 가치는 오를 수 있습니다. 새 성장 지표는 사용자가 얼마나 중요한 일을 맡기느냐입니다.
근거AI가 화면 탐색을 대신하고 API·MCP로 제품을 열지 않고도 결과를 받는 흐름이 늘고 있어서, 사람의 주의를 끄는 것을 전제로 짠 성장 공식이 맞지 않게 됩니다.
저자가 든 사례
Verna 본인: Lovable에서 사라진 기능 채택 업무
| 구분 | 내용 |
|---|---|
| 상황 | 경력의 상당 부분을 온보딩 흐름, 내비게이션 변경, 라이프사이클 캠페인, 맥락형 넛지로 기능 채택을 올리는 데 썼습니다. |
| 한 일 | AI 앱 빌더 Lovable에서 성장을 맡으며, 사용자가 목표를 말하고 에이전트가 기능을 쓰는 구조에서 일합니다. 에이전트가 기능을 모를 때는 Slack 채널에서 수정을 요청합니다. |
| 결과 | 기능 채택 업무를 거의 고민하지 않게 됐다고 말합니다. 수치는 원문에서 밝히지 않음. |
| 연결 | Agent-side Discovery, Goal-to-Capability Routing |
기존 성장팀: 메뉴 위치를 정하는 회의
| 구분 | 내용 |
|---|---|
| 상황 | 기능이 늘수록 제품이 복잡해져 동기가 약한 사용자가 떠나고, 팀은 기능을 어디에 둘지로 계속 씨름합니다. |
| 한 일 | 내비게이션 개편, 메뉴 배치 회의, 개인화를 시도합니다. 저자가 든 예는 후속 회의에 24명이 초대된 2시간 회의입니다. |
| 결과 | 개인화는 규모를 키우기 어렵고, 새 기능 사용은 아마 0.1% 수준에 머문다고 봅니다. |
| 연결 | Feature Adoption Funnel |
기술 디테일: 에이전트가 기능을 알고, 사용자가 믿게 하려면
아래는 원문의 메커니즘을 실제 제품이나 사내 업무 도구에서 돌릴 때 필요한 설정입니다. 필드명과 숫자는 모두 가상 예시입니다.
Agent-side Discovery를 운영하려면 기능 목록을 에이전트용 도구 정의(capability manifest)로 관리합니다. 기능마다 언제 쓰고 언제 쓰지 않는지, 부작용이 있는지, 되돌릴 수 있는지를 적어 에이전트의 도구 설명과 MCP 서버 정의에 그대로 씁니다. 새 기능 PR에 이 항목이 없으면 CI가 막도록 하면, “기능은 있는데 에이전트가 모르는” 상태가 출시 단계에서 걸러집니다.
{
"capability": "split_purchase_order",
"when_to_use": "품목별 납기나 공급사가 달라 한 발주를 나눠야 할 때",
"when_not_to_use": "단일 공급사, 단일 납기 발주",
"example_goals": ["납기 다른 품목은 나눠서 발주해 줘", "공급사별로 발주서 따로 만들어"],
"inputs": ["po_id", "split_rule"],
"side_effects": "draft_only",
"reversible": true,
"risk_tier": 1
}Goal-to-Capability Routing은 목표 문장 평가 세트로 잽니다. 실제 사용자 목표 문장 200개에 “기대 기능”을 붙인 세트를 만들고, 배포마다 돌려 기능 선택 정확도를 봅니다. 같은 목표를 3회씩 호출해 선택이 흔들리는지도 봅니다. 라우팅 단계는 temperature 0~0.2로 낮게 둡니다. 정확도가 떨어진 기능은 모델을 바꾸기 전에 when_to_use 문구와 example_goals부터 고칩니다. 운영 중에는 사용자가 결과를 받은 뒤 바로 다시 요청하거나 직접 수정한 세션을 하루 50건 표본으로 뽑아, 에이전트가 기능을 몰라서 생긴 실패인지 분류합니다.
Trust and Delegation의 세 질문은 결정 기록과 위험 등급으로 풉니다. 에이전트가 행동할 때마다 무엇을 했고 왜 했는지, 되돌리는 손잡이가 무엇인지 한 줄로 남기고 화면에는 요약만 보여 줍니다. 사용자가 원할 때만 펼쳐 봅니다. 사람의 확인이 필요한 경우는 위험 등급으로 미리 정해 두면, 사소한 검토를 강요하지 않으면서 개입 시점을 분명히 할 수 있습니다.
{
"step": 3,
"action": "split_purchase_order",
"why": "품목 A·B 납기가 2주 차이",
"alternatives_considered": ["single_order"],
"risk_tier": 1,
"needs_human": false,
"undo": "restore_snapshot:po-8812@step2"
}| 위험 등급 | 예 | 처리 |
|---|---|---|
| 0 | 조회, 요약, 초안 작성 | 자동 실행, 결과만 표시 |
| 1 | 되돌릴 수 있는 내부 변경 | 자동 실행 + 결정 요약 + 되돌리기 버튼 |
| 2 | 외부 발송, 삭제, 결제, 승인 | 실행 전 사람 확인 필수 |
Use-case Discovery는 빈 입력창 대신 역할별 시작 예시로 풉니다. 첫 화면에 사용자의 역할과 연결된 데이터에 맞춘 예시 목표 3~5개를 띄웁니다. 예시는 성공한 세션의 목표 문장을 매주 모아 군집으로 묶고 상위 군집에서 고릅니다. 결과 화면 끝에는 “이어서 맡길 수 있는 일” 1~2개를 붙여, 저자가 말한 “더 할 수 있는 일 보여 주기”를 자연스럽게 잇습니다.
지표는 참여에서 위임으로 바꿉니다. 참여 지표가 떨어져도 가치가 오를 수 있다는 저자의 지적을 대시보드에 반영하려면 아래 지표를 따로 둡니다.
| 지표 | 정의(가상 예시) | 연결 |
|---|---|---|
| Time to First Outcome | 가입부터 첫 결과물 채택까지 걸린 시간 | 첫 성공 경험 |
| 첫 성공률 | 첫 세션에서 결과를 채택한 사용자 비율 | 첫 성공 경험 |
| Delegation Depth | 세션당 사람 개입 없이 끝난 단계 수 | 위임 확대 |
| 되돌리기율 | 실행한 행동 중 사용자가 되돌린 비율 | 신뢰 |
| 재위임률 | 실패 경험 뒤 7일 안에 다시 맡긴 사용자 비율 | 신뢰 회복 |
현업 실행 디테일: 누가, 언제, 무엇을
역할. 아래는 AI 네이티브 제품이나 사내 업무 에이전트 하나를 기준으로 한 예시입니다.
| 역할 | 맡는 일 |
|---|---|
| 성장·프로덕트 리드 | 위임 지표 정의, 첫 성공의 기준 결정, 주간 리뷰 진행 |
| 에이전트 엔지니어 | capability manifest 관리, 목표 평가 세트 운영, 실패 세션 분류 |
| 프로덕트 디자이너 | 결정 요약·되돌리기·시작 예시 화면 설계 |
| CS·운영 담당 | “에이전트가 기능을 몰랐다” 사례를 모으는 채널 운영 |
| 현업 스폰서(사내 도구일 때) | 위험 등급 2 행동 목록 승인, 첫 성공 과제 선정 |
시작 전 준비물. 전체 기능 목록과 담당자, 최근 3개월 사용자 요청 문장(사내 도구라면 헬프데스크 티켓), 되돌릴 수 없는 행동 목록, 현재 참여 지표 대시보드입니다.
| 기간 | 할 일 | 산출물 |
|---|---|---|
| 1주차 | 기능 목록을 manifest로 옮기고 위험 등급 표시 | manifest 초안, 등급 2 행동 목록 |
| 2주차 | 요청 문장 200개로 평가 세트 구성, 첫 측정 | 기능 선택 정확도 기준값 |
| 3주차 | 결정 요약·되돌리기·시작 예시 화면 적용 | 화면 시안, 결정 기록 로그 |
| 4주차 | 위임 지표 대시보드 개설, 첫 주간 리뷰 | 지표 기준값, 다음 달 개선 목록 |
주간 리뷰에서 물을 질문.
- 이번 주 에이전트가 몰라서 쓰지 못한 기능은 무엇이었나, 누가 언제 manifest를 고쳤나
- 첫 세션에서 결과를 채택하지 않은 사용자는 어느 단계에서 멈췄나
- 되돌리기가 많은 행동은 무엇이고, 등급을 올려야 하나
- 시작 예시 중 아무도 누르지 않은 것은 무엇인가
진행 판정 기준(예시). 기능 선택 정확도 90% 이상, 3회 호출 일치율 95% 이상이면 해당 기능을 자동 실행 대상으로 둡니다. 첫 성공률이 4주 동안 오르지 않으면 시작 예시와 첫 과제를 다시 고릅니다. 되돌리기율이 10%를 넘는 행동은 위험 등급을 한 단계 올립니다.
AX 프로젝트에 쓸 때. 사내 업무 도구에 에이전트를 붙이는 프로젝트는 흔히 사용 교육, 사내 공지, 기능 안내 메일에 예산을 씁니다. 이 글의 관점에서는 그 예산 일부를 capability manifest와 평가 세트, 결정 요약 화면으로 옮기는 편이 낫습니다. 도입 첫 달의 성공 기준도 로그인 수나 사용 시간이 아니라 “부서마다 첫 성공 과제 하나를 사람 개입 없이 끝냈나”로 잡습니다. 구매 요청 초안, 주간 보고 취합처럼 되돌릴 수 있고 결과가 분명한 일부터 맡기고, 되돌리기율과 재위임률을 보며 발송·승인 같은 등급 2 업무로 넓힙니다. 현업 스폰서는 이 순서를 정하고 등급 2 목록을 승인하는 사람으로 둡니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 저자·매체 | Elena Verna, Elena’s Growth Scoop(Substack) |
| 저자 소속 | Lovable 성장 책임 |
| 발행 | 2026년 11월 5일 |
| 핵심 주장 | AI가 목표를 받아 기능을 고르면 기능 발견 업무는 대부분 사라지고, 신뢰와 사용 사례 발견이 새 과제가 된다 |
| 수치 | 새 기능 사용자는 아마 0.1%, 후속 회의 초대 24명·2시간 |
| 새 과제 | AI 결정 공개, 사람 개입 시점, 되돌리기, 빈 입력창의 사용 사례 발견 |
| 성장팀의 새 목표 | 첫 의미 있는 결과, 다음에 할 수 있는 일 보여 주기, 계속 맡길 만큼의 신뢰 |
| 그 밖의 언급 | API·MCP·연동, AI를 기능으로 붙이는 방식 경계, Felix Lee 게시물 |
핵심 개념
- Feature adoption
- 출시한 기능을 사용자가 실제로 쓰기 시작하는 비율과 그 과정입니다. 기존 성장팀의 주요 관리 대상이었습니다.
- Software bloat
- 기능이 계속 쌓여 제품이 무겁고 복잡해지는 현상입니다.
- Contextual nudge
- 사용자가 특정 화면이나 상황에 있을 때 띄우는 짧은 안내입니다. 툴팁, 배너, 팝업이 대표적입니다.
- Lifecycle campaign
- 가입, 첫 사용, 이탈 위험 같은 사용자 단계에 맞춰 보내는 메일·알림 묶음입니다.
- MCP
- Model Context Protocol. AI 에이전트가 외부 도구와 데이터를 같은 방식으로 부르게 해 주는 표준입니다.
- AI-native product
- AI가 덧붙인 기능이 아니라 제품의 입구이자 작동 방식인 제품입니다.
내 메모
TODO: 내 생각 추가
원문은 Elena Verna의 「The end of feature discovery as we know it.」(Elena’s Growth Scoop, 2026.11.5)입니다. 요약, 핵심 메커니즘의 원문 설명, 통념과 다른 주장, 저자가 든 사례, 원문 사례 표는 원문 내용을 AX Review가 다시 정리했습니다. 메커니즘 이름(Goal-to-Capability Routing 등)은 설명을 위해 붙인 것이고, 가상 예시, capability manifest와 결정 기록 JSON, 위험 등급표, 평가 세트 설정, 위임 지표, 역할·일정·판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했으며 그 안의 필드명과 숫자는 가상 예시입니다. 전체 글은 원문에서 읽을 수 있습니다.