가벼운 요구사항 정의하기

초간단 미니 요구사항 정의서

 현업에서 오래 일한 기획자들이 쓰는 요구사항 정의서는 보통 몇백 페이지에 달합니다. 템플릿도 있고, 섹션도 많고, 리뷰 프로세스도 복잡합니다. 큰 조직에서는 그럴 만한 이유가 있습니다. 이해관계자가 많고, 변경 이력도 남겨야 하고, 추후 유지보수까지 고려해야 하기 때문입니다.

 

 하지만 1인 창업자, 두세 명으로 움직이는 초경량 팀, 막 프로덕트 마켓 핏(Product-Market Fit)을 검증해 보려는 단계라면 이야기가 조금 다릅니다. 그런 팀에게 정석에 가까운 요구사항 정의서 포맷은, 솔직히 말씀드리면 과합니다.

 시간과 에너지의 상당 부분이 문서를 예쁘게 만드는 데 들어가고, 정작 중요한 “무엇을 만들지, 왜 만드는지”를 정리하는 데 쓰이는 시간은 줄어들기 쉽습니다. 이 글은 그런 상황에서 쓸 수 있는, 초간단 미니 요구샇아 정의서에 대한 이야기입니다. 교과서적인 정답보다는, 지금 당장 우리 팀에 조금 덜 헤매게 만드는 현실적인 방법에 대해 이야기해보려 합니다.

 

 

 

바닥 매트 깔기

 먼저 분명히 해야 할 점이 있습니다. 여기서 말씀드리는 미니 요구사항 정의서는, 대기업이나 대규모 조직에서 사용하는 정식 기획서를 대체하는 도구가 아닙니다. 큰 회사의 기획서는 수많은 제약을 고려합니다. 법적 이슈, 여러 시스템 간 연동, 과거 유사 서비스의 이력, 사내 정책, 언어나 지역별 지원 등.. 눈에 안 보이는 전제들이 많이 깔려 있습니다. 그래서 자연스럽게 양식도 복잡해지고, 검토 주체도 많아집니다.

 

 반대로, 1인 또는 소규모 팀이나 초기 단계 스타트업의 현실은 다릅니다. 회의는 빠르게 열리고, 결정은 슬랙이나 카톡 한 줄로 내려갑니다. 어제 말한 요구사항이 오늘 바뀌기도 합니다. 문서가 너무 없는것도 문제지만,
 그렇다고 해서 대규모 조직의 양식을 그대로 들여오는 것도 맞지 않습니다.

 

 여기서 말하는 미니 요구사항 정의서는 그 중간 지점, 조금 더 현실적인 타협에 가깝습니다. 슬랙, 카톡, 구두로 왔다 갔다 하던 기능 정의를 엑셀이나 노션의 테이블 한 장으로 임시 고정해 두고, 지금 이 버전에서 만들기로 합의한 것만 깔끔하게 모아두는 역할을 합니다.

 

 정식 설계 문서가 아니라, 그 설계로 가기 전에 깔아두는 바닥 매트 정도로 생각하시면 편합니다.

 

 

 

여기저기 흩어진 말을 한 장에 모으는 힘

 초기 팀에서 자주 보이는 장면이 있습니다. 제품 이야기는 다들 열심히 합니다. 메신저, 회의, 줌, 피그마 댓글, 노션 페이지로요. 하지만 막상 지금 버전에서 무엇을 어떻게 만들기로 한 건지를 질문드리면, 모두가 각자 다른 그림을 떠올립니다.

 

 어떤 사람은 기능 이름을 기준으로 기억하고, 어떤 사람은 화면 캡처를 기준으로 이해하고, 어떤 사람은 개발 관점에서 API를 떠올립니다. 이 상태로는 누가 맞고 틀리다보다, 서로 다른 언어로 떠들고 있다는 말이 더 정확한 것 같습니다.

 

 엑셀이나 노션으로 만드는 미니 요구사항 정의서는 이렇게 흩어진 내용을 기능 단위로 한 줄씩 묶는 역할을 합니다. 문서의 목표는 거창하지 않습니다.   

•      지금 만들기로 한 기능이 무엇인지
•      그 기능이 왜 필요한지
•      누가, 언제, 어떤 화면에서 쓰는지
•      입력과 출력이 대략 무엇인지
•      당장 떠오르는 예외사항이 무엇인지

 

 이 정도만 한 장에 모아도, 팀 내 대화의 질이 눈에 띄게 달라집니다. 기획을 전문으로 하지 않는 사람도 쉽게 접근할 수 있고, 개발자와 디자이너도 각자 필요한 정보를 이 한 장에서 출발할 수 있습니다. 완벽한 요구사항 정의서 대신, 지금 팀이 공통으로 볼 수 있는 최소한의 도면이라고 생각하면 됩니다.

 

 

컬럼 몇 개면 충분합니다

 형태는 단순합니다. 엑셀이나 노션에서 테이블을 하나 만들고, 위에 몇 개의 컬럼을 두면 됩니다.

예를 들어, 이런 열을 생각할 수 있습니다. 각 행(row)은 기능 하나 또는 사용자 행동 한 단위를 의미합니다.

•      기능명
•      이 기능이 필요한 이유
•      사용하는 사람과 상황
•      입력 / 출력
•      예외, 에러 처리 메모
•      우선순위(MVP / 다음 / 나중)
•      메모(아직 확정되지 않은 부분)

 

실제 예를 하나만 들어보겠습니다. 퇴근 후 10분 자기계발 서비스를 가정하고, “오늘의 콘텐츠 추천”이라는 기능을 적는다고 해 보겠습니다.

• 기능명에는 이렇게 적습니다. “오늘의 10분 콘텐츠 추천”
• 필요한 이유는 간단하게, “사용자가 들어오자마자 고민 없이 하나를 선택할 수 있도록 하기 위함”이라고 씁니다.
• 사용자와 상황에는 “퇴근 후 집에서, 자기계발을 하고 싶지만 뭘 해야 할지 모르겠을 때” 정도의 문장을 넣습니다.
• 입력/출력에는 “입력: 사용자 ID, 선호 카테고리, 최근 시청 기록 / 출력: 오늘 노출할 콘텐츠 1개” 정도로만 적습니다. 정확한 API 스펙이 아니라, 이 기능이 무엇을 받아서 무엇을 돌려주는지를 대략적으로 표현하는 것입니다.
• 예외에는 “추천할 콘텐츠가 1개도 없을 경우, 기본 추천 세트에서 하나를 로테이션으로 제공” 같은 식으로, 당장 떠오르는 최소한의 예외를 적습니다.
• 우선순위는 “MVP 필수” 또는 “후속” 정도로 표시해 둡니다.

 

 이렇게 한 줄을 써보고 나면, 이미 세 가지가 정리됩니다. 이 기능이 왜 필요한지, 누가 어떤 상황에서 쓰는지, 어떤 데이터를 기반으로 어떤 결과를 내야 하는지. 기획 문장과 구현 관점을 한 줄에 같이 묶어두는 효과가 생깁니다. 나머지 기능들도 이런 식으로 한 줄씩 천천히 채워나가면 됩니다.

 

 

 

처음부터 잘 쓰려고 하지 말고, 거칠게 여러 번 고치기

경험상 초반에 가장 자주 막히는 지점은 처음부터 깔끔하게 작성해야 한다는 압박입니다. 현실적으로는, 거칠게라도 한 번 테이블을 채우고 팀의 대화와 함께 여러 번 고치는 방식이 훨씬 잘 굴러갑니다.

 

처음에는 사용자 흐름을 정말 러프하게만 적어봅니다. 예를 들어,

앱 또는 웹을 연다 → 오늘의 콘텐츠를 고른다 → 본다 → 한 줄을 적거나 체크한다 → 오늘도 했다라는 피드백을 본다.

이 정도로 흐름을 적어두고 나면, 각 단계에서 구체적으로 어떤 기능이 필요할지가 자연스럽게 떠오릅니다. 콘텐츠 목록을 보여주는 기능, 콘텐츠 상세를 보여주는 기능, 한 줄 메모를 입력·저장하는 기능, 오늘 완료 상태를 표시하는 기능 등이 그렇게 나오는 기능들입니다.

 

이 기능들을 행으로 추가한 뒤, 각 기능에 대해 이유, 상황, 입출력, 예외상황을 조금씩 채워넣습니다. 처음에는 빈 칸이 많아도 괜찮습니다. 아직 미정이라고 써 두고 넘어가도 됩니다. 여기서 중요한 것은, 문서를 한 번에 완성하는 것이 아니라 생각하는 과정을 문서에 그대로 남기는 것입니다. 회의를 한 번 하고 나면 두세 줄이 바뀌고, 디자인 시안이 나오면 예외 항목이 하나 더 생기고, 개발자와 얘기하고 나면 입력/출력 컬럼에 구체적인 값이 하나 더 추가됩니다.

 

이렇게 자주 손을 타는 문서일수록 엑셀이나 노션 같은 가벼운 도구가 잘 맞습니다. 버전 관리도 부담이 덜하고, 필요할 때 열어서 바로 편집하기도 쉽습니다.

 

 

 

한계가 오는 시점

엑셀이나 노션으로 만드는 미니 요구사항 정의서는 언제까지나 만능으로 통하는 도구는 아닙니다. 사용자 수가 늘어나고, 서로 다른 유형의 고객이 생기고, 기능 간 의존성이 복잡해지기 시작하면 단일 테이블 한 장으로는 설명이 어려운 부분이 분명히 생깁니다.

 

예를 들면, 권한 체계가 여러 단계로 나뉜다든지, 외부 시스템과의 연동이 프로젝트의 핵심이 된다든지, 도메인 규칙이 수십~수백 개 수준으로 늘어나는 시점입니다. 이때는 자연스럽게 정식 요구사항 정의서에 가까운 형식이 필요해집니다. 기능 단위 정의를 넘어, 시퀀스 다이어그램, 상태 다이어그램, 데이터 모델링 문서 등

 별도의 산출물이 등장하게 됩니다.

 

그렇다고 해서 초기 단계에 미니 정의서를 쓰는 것이 의미 없다는 뜻은 아닙니다. 오히려 반대입니다. 처음에 아무 구조 없이 말과 채팅으로만 움직이던 팀이 간단한 문서로 기능/흐름/예외사항을 정리하기 시작하면, 나중에 정식 문서로 확장할 때도 훨씬 수월해집니다. 이미 1차로 정리된 언어와 결정들이 있기 때문에 그 위에 세밀한 설계를 쌓아 올리면 됩니다.

 

 

 

완벽한 문서보다, 대화가 되는 최소 단위가 먼저입니다

정리해 보면, 엑셀이나 노션으로 만드는 ‘미니 요구사항 정의서’는 완벽한 기획문서를 흉내 내는 도구가 아닙니다. 지금 단계의 팀이,   

•      현재 버전에서 무엇을 만들고 있는지,
•      왜 그 기능이 필요한지,
•      누가 언제 그 기능을 사용하는지,
•      어떤 입력과 출력, 어떤 예외를 상정하는지

 

이 네 가지를 기능 단위로 한 줄씩 붙잡아 두기 위한 장치에 가깝습니다. 정식 양식처럼 보일 필요도 없고,

 처음부터 빈칸 없이 채워 넣을 필요도 없습니다.

 오히려 거칠게 적고, 팀의 대화와 함께 조금씩 고쳐지는 문서일수록 더 유용합니다. 초경량 팀이나 초기 PMF 검증 단계에서는 문서의 “폼”보다, 팀이 동일한 그림을 보고 있는지가 훨씬 더 중요합니다. 그 최소한의 공통 그림을 만들어 주는 도구로, 미니 요구사항 정의서를 한 번 시도해 보시길 권해드립니다.