지금 우리 팀이 이해할 수 있는 수준으로 정리하기
현업에서 오래 일한 기획자들이 쓰는 요구사항 정의서는 보통 몇백 페이지에 달합니다. 템플릿도 있고, 섹션도 많고, 리뷰 프로세스도 복잡합니다. 큰 조직에서는 그럴 만한 이유가 있습니다. 이해관계자가 많고, 변경 이력도 남겨야 하고, 추후 유지보수까지 고려해야 하기 때문입니다.
하지만 1인 창업자, 두세 명으로 움직이는 초경량 팀, 막 프로덕트 마켓 핏(Product-Market Fit)을 검증해 보려는 단계라면 이야기가 조금 다릅니다. 그런 팀에게 정석에 가까운 요구사항 정의서 포맷은, 솔직히 말씀드리면 과합니다.
시간과 에너지의 상당 부분이 문서를 예쁘게 만드는 데 들어가고, 정작 중요한 “무엇을 만들지, 왜 만드는지”를 정리하는 데 쓰이는 시간은 줄어들기 쉽습니다. 이 글은 그런 상황에서 쓸 수 있는, 초간단 미니 요구샇아 정의서에 대한 이야기입니다. 교과서적인 정답보다는, 지금 당장 우리 팀에 조금 덜 헤매게 만드는 현실적인 방법에 대해 이야기해보려 합니다.
먼저 분명히 해야 할 점이 있습니다. 여기서 말씀드리는 미니 요구사항 정의서는, 대기업이나 대규모 조직에서 사용하는 정식 기획서를 대체하는 도구가 아닙니다. 큰 회사의 기획서는 수많은 제약을 고려합니다. 법적 이슈, 여러 시스템 간 연동, 과거 유사 서비스의 이력, 사내 정책, 언어나 지역별 지원 등.. 눈에 안 보이는 전제들이 많이 깔려 있습니다. 그래서 자연스럽게 양식도 복잡해지고, 검토 주체도 많아집니다.
반대로, 1인 또는 소규모 팀이나 초기 단계 스타트업의 현실은 다릅니다. 회의는 빠르게 열리고, 결정은 슬랙이나 카톡 한 줄로 내려갑니다. 어제 말한 요구사항이 오늘 바뀌기도 합니다. 문서가 너무 없는것도 문제지만,
그렇다고 해서 대규모 조직의 양식을 그대로 들여오는 것도 맞지 않습니다.
여기서 말하는 미니 요구사항 정의서는 그 중간 지점, 조금 더 현실적인 타협에 가깝습니다. 슬랙, 카톡, 구두로 왔다 갔다 하던 기능 정의를 엑셀이나 노션의 테이블 한 장으로 임시 고정해 두고, 지금 이 버전에서 만들기로 합의한 것만 깔끔하게 모아두는 역할을 합니다.
정식 설계 문서가 아니라, 그 설계로 가기 전에 깔아두는 바닥 매트 정도로 생각하시면 편합니다.
초기 팀에서 자주 보이는 장면이 있습니다. 제품 이야기는 다들 열심히 합니다. 메신저, 회의, 줌, 피그마 댓글, 노션 페이지로요. 하지만 막상 지금 버전에서 무엇을 어떻게 만들기로 한 건지를 질문드리면, 모두가 각자 다른 그림을 떠올립니다.
어떤 사람은 기능 이름을 기준으로 기억하고, 어떤 사람은 화면 캡처를 기준으로 이해하고, 어떤 사람은 개발 관점에서 API를 떠올립니다. 이 상태로는 누가 맞고 틀리다보다, 서로 다른 언어로 떠들고 있다는 말이 더 정확한 것 같습니다.
엑셀이나 노션으로 만드는 미니 요구사항 정의서는 이렇게 흩어진 내용을 기능 단위로 한 줄씩 묶는 역할을 합니다. 문서의 목표는 거창하지 않습니다.
지금 만들기로 한 기능이 무엇인지
그 기능이 왜 필요한지
누가, 언제, 어떤 화면에서 쓰는지
입력과 출력이 대략 무엇인지
당장 떠오르는 예외사항이 무엇인지
이 정도만 한 장에 모아도, 팀 내 대화의 질이 눈에 띄게 달라집니다. 기획을 전문으로 하지 않는 사람도 쉽게 접근할 수 있고, 개발자와 디자이너도 각자 필요한 정보를 이 한 장에서 출발할 수 있습니다. 완벽한 요구사항 정의서 대신, 지금 팀이 공통으로 볼 수 있는 최소한의 도면이라고 생각하면 됩니다.
형태는 단순합니다. 엑셀이나 노션에서 테이블을 하나 만들고, 위에 몇 개의 컬럼을 두면 됩니다.
예를 들어, 이런 열을 생각할 수 있습니다. 각 행(row)은 기능 하나 또는 사용자 행동 한 단위를 의미합니다.
기능명
이 기능이 필요한 이유
사용하는 사람과 상황
입력 / 출력
예외, 에러 처리 메모
우선순위(MVP / 다음 / 나중)
메모(아직 확정되지 않은 부분)
실제 예를 하나만 들어보겠습니다. 퇴근 후 10분 자기계발 서비스를 가정하고, “오늘의 콘텐츠 추천”이라는 기능을 적는다고 해 보겠습니다.
기능명에는 이렇게 적습니다. “오늘의 10분 콘텐츠 추천”
필요한 이유는 간단하게, “사용자가 들어오자마자 고민 없이 하나를 선택할 수 있도록 하기 위함”이라고 씁니다.
사용자와 상황에는 “퇴근 후 집에서, 자기계발을 하고 싶지만 뭘 해야 할지 모르겠을 때” 정도의 문장을 넣습니다.
입력/출력에는 “입력: 사용자 ID, 선호 카테고리, 최근 시청 기록 / 출력: 오늘 노출할 콘텐츠 1개” 정도로만 적습니다. 정확한 API 스펙이 아니라, 이 기능이 무엇을 받아서 무엇을 돌려주는지를 대략적으로 표현하는 것입니다.
예외에는 “추천할 콘텐츠가 1개도 없을 경우, 기본 추천 세트에서 하나를 로테이션으로 제공” 같은 식으로, 당장 떠오르는 최소한의 예외를 적습니다.
우선순위는 “MVP 필수” 또는 “후속” 정도로 표시해 둡니다.
이렇게 한 줄을 써보고 나면, 이미 세 가지가 정리됩니다. 이 기능이 왜 필요한지, 누가 어떤 상황에서 쓰는지, 어떤 데이터를 기반으로 어떤 결과를 내야 하는지. 기획 문장과 구현 관점을 한 줄에 같이 묶어두는 효과가 생깁니다. 나머지 기능들도 이런 식으로 한 줄씩 천천히 채워나가면 됩니다.
경험상 초반에 가장 자주 막히는 지점은 처음부터 깔끔하게 작성해야 한다는 압박입니다. 현실적으로는, 거칠게라도 한 번 테이블을 채우고 팀의 대화와 함께 여러 번 고치는 방식이 훨씬 잘 굴러갑니다.
처음에는 사용자 흐름을 정말 러프하게만 적어봅니다. 예를 들어,
앱 또는 웹을 연다 → 오늘의 콘텐츠를 고른다 → 본다 → 한 줄을 적거나 체크한다 → 오늘도 했다라는 피드백을 본다.
이 정도로 흐름을 적어두고 나면, 각 단계에서 구체적으로 어떤 기능이 필요할지가 자연스럽게 떠오릅니다. 콘텐츠 목록을 보여주는 기능, 콘텐츠 상세를 보여주는 기능, 한 줄 메모를 입력·저장하는 기능, 오늘 완료 상태를 표시하는 기능 등이 그렇게 나오는 기능들입니다.
이 기능들을 행으로 추가한 뒤, 각 기능에 대해 이유, 상황, 입출력, 예외상황을 조금씩 채워넣습니다. 처음에는 빈 칸이 많아도 괜찮습니다. 아직 미정이라고 써 두고 넘어가도 됩니다. 여기서 중요한 것은, 문서를 한 번에 완성하는 것이 아니라 생각하는 과정을 문서에 그대로 남기는 것입니다. 회의를 한 번 하고 나면 두세 줄이 바뀌고, 디자인 시안이 나오면 예외 항목이 하나 더 생기고, 개발자와 얘기하고 나면 입력/출력 컬럼에 구체적인 값이 하나 더 추가됩니다.
이렇게 자주 손을 타는 문서일수록 엑셀이나 노션 같은 가벼운 도구가 잘 맞습니다. 버전 관리도 부담이 덜하고, 필요할 때 열어서 바로 편집하기도 쉽습니다.
엑셀이나 노션으로 만드는 미니 요구사항 정의서는 언제까지나 만능으로 통하는 도구는 아닙니다. 사용자 수가 늘어나고, 서로 다른 유형의 고객이 생기고, 기능 간 의존성이 복잡해지기 시작하면 단일 테이블 한 장으로는 설명이 어려운 부분이 분명히 생깁니다.
예를 들면, 권한 체계가 여러 단계로 나뉜다든지, 외부 시스템과의 연동이 프로젝트의 핵심이 된다든지, 도메인 규칙이 수십~수백 개 수준으로 늘어나는 시점입니다. 이때는 자연스럽게 정식 요구사항 정의서에 가까운 형식이 필요해집니다. 기능 단위 정의를 넘어, 시퀀스 다이어그램, 상태 다이어그램, 데이터 모델링 문서 등
별도의 산출물이 등장하게 됩니다.
그렇다고 해서 초기 단계에 미니 정의서를 쓰는 것이 의미 없다는 뜻은 아닙니다. 오히려 반대입니다. 처음에 아무 구조 없이 말과 채팅으로만 움직이던 팀이 간단한 문서로 기능/흐름/예외사항을 정리하기 시작하면, 나중에 정식 문서로 확장할 때도 훨씬 수월해집니다. 이미 1차로 정리된 언어와 결정들이 있기 때문에 그 위에 세밀한 설계를 쌓아 올리면 됩니다.
정리해 보면, 엑셀이나 노션으로 만드는 ‘미니 요구사항 정의서’는 완벽한 기획문서를 흉내 내는 도구가 아닙니다. 지금 단계의 팀이,
현재 버전에서 무엇을 만들고 있는지,
왜 그 기능이 필요한지,
누가 언제 그 기능을 사용하는지,
어떤 입력과 출력, 어떤 예외를 상정하는지
이 네 가지를 기능 단위로 한 줄씩 붙잡아 두기 위한 장치에 가깝습니다. 정식 양식처럼 보일 필요도 없고,
처음부터 빈칸 없이 채워 넣을 필요도 없습니다.
오히려 거칠게 적고, 팀의 대화와 함께 조금씩 고쳐지는 문서일수록 더 유용합니다. 초경량 팀이나 초기 PMF 검증 단계에서는 문서의 “폼”보다, 팀이 동일한 그림을 보고 있는지가 훨씬 더 중요합니다. 그 최소한의 공통 그림을 만들어 주는 도구로, 미니 요구사항 정의서를 한 번 시도해 보시길 권해드립니다.