AI 시대 소프트웨어 개발의 진짜 병목 — '무엇을 만들지' 정하는 기술과 유저 스토리 매핑

핵심 메시지

• AI로 코드 작성 비용이 급감하면서, 개발의 진짜 병목은 '무엇을 만들지'를 정하는 일로 옮겨갔다.
• 회의실의 의사결정자와 이해관계자에게서 올바른 요구사항을 끌어내는 '사람을 다루는 기술'은 AI로 대체되지 않는다.
• 유저 스토리 매핑은 고객의 업무 흐름을 한눈에 보고 무엇부터 만들지(MVP)를 정하는 강력한 도구다.
• '페르소나·무엇을·왜'의 유저 스토리 구조는 AI가 학습한 익숙한 형식이라, 그대로 쓰면 더 좋은 결과를 얻는다.
• 출시한 기능 수가 아니라 '실제로 두 번 이상 쓰인 기능'을 KPI로 삼아야 옳은 것을 만든다.

쉽게 이해하기

발라즈 호르바스는 VisualLabs 창업자로, 13년간 비즈니스와 IT·개발자 사이의 다리 역할을 해왔다. 그는 AI가 코드 작성을 값싸게 만든 지금, 소프트웨어 개발의 병목이 '코드를 짜는 일'에서 '무엇을 만들지 정하는 일'로 옮겨갔다고 본다. AI에게 프롬프트는 줄 수 있어도 회의실에는 프롬프트를 줄 수 없다는 것이 그의 핵심 메시지다.

그는 연초 사내 해커톤에서 21개의 에이전트 아이디어 중 17개가 실제 비즈니스 가치를 내지 못해 폐기됐고, 살아남은 4개만이 업무 방식을 크게 바꿨다고 소개한다. 이는 '만들 가치가 있는 것'을 가려내는 일이 얼마나 중요한지 보여 준다. 헨리 포드의 '고객에게 물었다면 더 빠른 말을 원했을 것'이라는 일화처럼, AI는 본래 가장 흔한 답을 내놓기 때문에 그대로 쓰면 이미 존재하는 것을 복제하기 쉽다.

그가 가장 가치 있다고 꼽은 기술은 유저 스토리 매핑이다. 고객의 업무를 '접수→분류→해결→종료'처럼 큰 흐름(백본)으로 펼치고 그 아래 유저 스토리를 배치하면, 무엇을 먼저 만들지(MVP)와 무엇을 백로그로 미룰지가 또렷해진다. 각 스토리는 '페르소나·필요·이유' 구조로 쓰는데, 이는 AI가 익숙하게 학습한 형식이라 더 좋은 결과로 이어진다.

그는 무엇을 만들지 정할 때 네 가지 질문을 던지라고 권한다. 누구의 문제인가, 그들에게 성공은 무엇인가, 무엇이 그들을 못 쓰게 만드는가, 그것이 어떤 의사결정을 바꾸는가. 이 답을 마크다운 파일로 저장소에 남겨 두면 AI가 더 풍부한 맥락을 활용한다. 그는 이런 사고 흐름을 가치(Value)·구조(Architecture)·설계(Design)의 머리글자를 딴 VAD라고 부른다.

잘못된 것을 만들고 있다는 신호는 기능은 쏟아내는데 실제 사용이 따라오지 않거나, 데모가 곧 결과물이 되어 실제 운영으로 이어지지 않는 경우다. 그는 '지난 분기 출시 기능 수' 대신 '두 번 이상 실제로 쓰인 기능 수'를 측정하고, 가장 경험 많은 전문가를 고객 가까이로 옮겨 무엇을 만들지 결정에 참여시키라고 조언한다.

주요 인사이트

• 빌딩(구현)은 싸졌지만, '무엇을 만들지 결정하는 일'은 여전히 비싸고 사람에게 달려 있다.
• AI는 평균적인 답을 주도록 학습됐기 때문에, 평균을 넘어 더 나은 결과로 끌어가는 것은 사용자의 몫이다.
• 유저 스토리는 AI가 잘 아는 패턴이므로, 익숙한 구조로 요구사항을 포장해 주면 AI의 출력 품질이 올라간다.
• 데모는 빠르고 보기 좋지만, 실제 사용자 테스트와 운영 반영이 없으면 살아남지 못한다.
• 옛 제품관리·분석 기술(스토리 매핑, 비즈니스 모델 캔버스)이 'AI 시대의 새로운 경쟁력'으로 재부상한다.

자주 묻는 질문

관련 AI 소식