머릿속에 앱 아이디어가 있다. 어떤 문제를 해결하는지, 누구에게 필요한지, 대략 어떤 화면들이 있는지도 그려진다. 그런데 개발자를 처음 만나는 순간, 그 아이디어는 종종 "구체적으로 어떤 기능이 필요하세요?"라는 질문 앞에서 멈춰 선다. 추상적인 아이디어와 실제 개발 사이의 간극, 그걸 메우는 것이 기능 명세서다. 기획 단계에서 아이디어를 구체적인 기능 명세서로 정리해야 개발 과정이 명확해지고, 제품이 실제로 완성된다.
개발 단계에서 가장 많은 시간이 낭비되는 지점은 코드를 짜는 순간이 아니다. "이 부분은 어떻게 동작해야 하죠?"라고 묻고 답을 기다리는 순간이다. 기획이 모호하면 개발자는 매번 멈추고, 창업자는 매번 즉흥으로 답하고, 만들어진 결과물은 처음 생각과 달라진다.
기능 명세서란 앱의 각 기능이 어떤 조건에서 어떻게 동작해야 하는지를 문서화한 것이다. "회원가입 기능"이라고 쓰는 것이 아니라, "사용자가 이메일과 비밀번호를 입력하면 인증 메일이 발송되고, 링크를 클릭하면 가입이 완료된다"처럼 행동 단위로 쓰는 것이다.
이 문서가 있으면 개발자는 질문 없이 작업을 이어갈 수 있고, 창업자는 완성된 기능이 처음 의도와 맞는지 확인할 수 있다. 없으면 둘 다 각자의 머릿속 그림을 가지고 일하다가, 출시 직전에 그림이 달랐다는 사실을 깨닫는다.
포텐랩은 첫 미팅 후 Project Info Doc이라고 부르는 기획 문서를 작성한다. 이건 포텐랩이 내부적으로 사용하는 방식이고, 창업자에게 "기획서를 써 오세요"라고 요구하는 것과 다르다.
문서에는 네 가지가 담긴다.
창업자는 이 문서를 직접 채우지 않아도 된다. 미팅에서 나온 이야기를 바탕으로 포텐랩이 초안을 작성하고, 창업자가 검토하며 맞는지 확인하는 방식으로 진행된다. 완성된 문서는 이후 모든 개발의 기준점이 된다.
왜 이 방식이 필요한가. 비개발자 창업자 대부분은 자신이 무엇을 원하는지 알지만, 그것을 개발자가 이해할 수 있는 언어로 변환하는 데 익숙하지 않다. Project Info Doc은 그 번역 작업을 기획 단계에서 공식적으로 처리한다. 나중에 개발 중간에 하면 비용과 시간이 모두 늘어난다.
비개발자가 기능을 정리할 때 막히는 이유는 보통 "기능"이라는 단위로 생각하지 않아서다. "예약 기능"이라고 말하지만 그게 달력인지, 시간 선택인지, 결제까지 포함인지를 분리해서 생각하지 않는다.
기능을 정의하는 데 유용한 접근법 중 하나는 사용자 스토리(User Story) 형식이다. "나는 [어떤 사람]으로서, [무엇을] 하고 싶다, 왜냐하면 [이유]이기 때문이다"라는 구조로 쓰는 것이다. 이 형식이 중요한 이유는 기능의 존재 이유를 강제로 명시하기 때문이다. 기능이 아니라 목적에서 출발하게 된다.
예를 들어 가상의 예약 앱을 생각해보자. "예약 기능 추가"라고 쓰는 대신 "고객으로서, 원하는 날짜와 시간에 서비스를 예약하고 싶다. 이메일로 예약 확인을 받고 싶다"라고 쓴다. 이 문장 하나에서 달력, 시간 선택, 이메일 발송이라는 세 가지 개발 항목이 도출된다.
비개발자가 스스로 이 작업을 완벽하게 해낼 필요는 없다. 핵심은 개발자나 기획 파트너와 대화할 때 "사용자 입장에서 어떤 행동이 일어나야 하는가"를 기준으로 이야기하는 것이다. 그 대화가 문서로 정리되면 기능 명세서의 뼈대가 된다.
기능 명세서의 형식은 팀마다 다를 수 있지만, 실제 개발에 쓰이려면 아래 항목들이 빠지지 않아야 한다.
| 항목 | 설명 | 빠졌을 때 생기는 문제 |
|---|---|---|
| 기능 이름 | 기능을 식별하는 짧은 이름 | 소통 시 혼선 |
| 사용자 행동 | 사용자가 무엇을 하는가 | 개발 방향 불명확 |
| 시스템 반응 | 앱이 어떻게 응답하는가 | 기대치 불일치 |
| 예외 처리 | 오류나 실패 상황에서 어떻게 되는가 | 출시 후 버그 |
| 범위 구분 | 지금 만드는지, 나중에 만드는지 | 개발 범위 초과 |
특히 예외 처리는 비개발자가 가장 많이 빠뜨리는 항목이다. 로그인 기능을 정의할 때 "로그인이 성공하면"만 생각하고, "비밀번호가 틀리면", "계정이 없으면"은 빠뜨리기 쉽다. 그런데 개발자는 이 부분도 만들어야 한다. 명세서에 없으면 개발자가 임의로 결정하거나, 다시 물어봐야 한다.
범위 구분은 MVP(최소 기능 제품) 관점에서 더 중요하다. 지금 시장에 던져서 검증해야 할 기능과, 검증 후에 추가해도 되는 기능을 명세서 단계에서 구분해 두면 개발 중간에 "이것도 넣어야 하지 않을까?"라는 유혹을 구조적으로 막을 수 있다.
기획 단계에서 흔히 빠지는 함정이 있다. 아이디어를 설명하다 보면 "이것도 되면 좋겠고", "저것도 필요할 것 같고"가 계속 붙는다. 이걸 기능 명세서에 전부 담으면 개발 범위가 처음보다 두세 배 커진다. 그리고 그만큼 기간과 비용도 늘어난다.
범위를 확정하는 기준은 단 하나다. 이 기능이 없으면 핵심 사용자 시나리오가 동작하지 않는가. 동작한다면 그 기능은 지금 범위 밖이다.
가령 동네 소상공인을 위한 예약 관리 앱을 만든다고 가정해보자. 핵심 시나리오는 "고객이 예약하고, 사장님이 확인한다"이다. 이 시나리오를 완성하는 기능이 우선순위 1순위다. 통계 대시보드, 리뷰 기능, 카카오톡 연동은 시나리오를 막지 않는다. 나중에 추가할 수 있다.
이 판단을 기획 단계에서 명세서에 반영해 두면, 개발 중간에 "이것도 넣자"는 요청이 와도 "이건 2단계에 잡혀 있습니다"라고 명확하게 대답할 수 있다. 범위를 지키는 가장 현실적인 도구가 바로 기능 명세서다.
포텐랩은 기획 단계에서 이 범위 확정 작업을 창업자와 함께 진행한다. 단순히 요구사항을 받아서 개발하는 방식이 아니라, 무엇을 만들지 함께 정하는 과정을 기획 단계에 포함시킨다. 그래야 개발이 시작된 이후 방향이 흔들리지 않는다.
개발 착수 자체는 가능하지만, 기획이 불명확한 상태로 시작하면 중간에 방향이 바뀌는 경우가 많다. 포텐랩은 초기 상담에서 아이디어를 정리하는 과정을 함께 진행하므로, 완성된 문서 없이 대화만으로 시작해도 된다.
핵심 사용자 시나리오를 완성하는 데 반드시 필요한 기능이 MVP 범위다. 그 시나리오가 동작한 뒤 사용자 반응을 보고 추가할 수 있는 기능은 다음 단계로 분리한다. 기획 단계에서 이 구분을 명세서에 명시해 두면 개발 중 범위가 늘어나는 것을 막을 수 있다.
개발자가 별도로 묻지 않고 작업할 수 있을 정도면 충분하다. 사용자 행동, 시스템 반응, 예외 상황 세 가지가 적혀 있으면 대부분의 기능은 개발 가능한 수준이 된다. 처음부터 완벽할 필요는 없고, 검토 과정에서 보완하면 된다.
창업자가 직접 작성할 필요는 없다. 포텐랩은 초기 미팅에서 나온 대화를 바탕으로 기획 문서 초안을 만들고, 창업자가 검토하며 수정하는 방식으로 진행한다. 창업자의 역할은 "이게 내가 원하는 방향이 맞는가"를 판단하는 것이다.
기획 변경은 자연스러운 일이다. 다만 명세서가 있으면 무엇이 어떻게 바뀌는지, 그 변경이 개발 범위와 일정에 어떤 영향을 주는지를 정확하게 파악할 수 있다. 명세서 없이 구두로 변경 사항을 주고받으면 나중에 무엇이 결정된 건지 추적하기 어려워진다.
추상적인 아이디어는 누구나 갖고 있다. 그것이 실제 제품으로 이어지느냐의 차이는 기획 단계에서 얼마나 구체적으로 정리했느냐에 달려 있다. 포텐랩은 기획 단계에서 투명하게 소통하며, 비개발자 창업자의 아이디어를 실제 작동하는 제품으로 만든다. 초기 상담은 무료이며, potenlab.dev에서 시작할 수 있다.