MVP 필수 기능과 후속 기능, 어떻게 구분할까

MVP의 목적은 작은 제품을 만드는 것 자체가 아니라 실제 사용을 통해 불확실성을 줄이는 데 있습니다. 누구의 어떤 문제를 해결하려는지, 사용자가 어떤 행동을 마치면 가설을 확인할 수 있는지를 먼저 정해야 기능의 필요성을 비교할 기준이 생깁니다.

GOV.UK 서비스 매뉴얼은 사용자가 누구이고 무엇을 하려는지, 현재 어떤 문제를 겪는지부터 조사하고 사용자 요구를 구체적인 작업과 연결하라고 안내합니다. 기능마다 연결된 사용자 요구와 확인하려는 결과를 적을 수 없다면 첫 출시의 필수 기능으로 보기 어렵습니다.

회원가입, 검색, 결제처럼 기능 이름만 따로 적으면 사용자가 실제로 목표를 끝낼 수 있는지 알기 어렵습니다. 첫 진입, 필요한 정보 입력, 핵심 처리, 결과 확인과 문제가 생겼을 때의 안내까지 이어져야 하나의 검증 가능한 흐름이 됩니다.

화면이 많아도 결과가 끊기면 검증할 수 없고, 화면이 적어도 운영자가 뒤에서 처리할 규칙이 없으면 서비스가 멈춥니다. NXLAB은 사용자 화면과 운영 처리 단계를 같은 흐름에 놓고 한 번 끝까지 실행할 수 있는지를 확인합니다.

MVP라는 이유로 로그인 권한, 개인정보 보호, 입력 검증, 접근성, 오류 확인과 복구 기준을 모두 다음 단계로 미룰 수는 없습니다. 어떤 항목이 필요한지는 다루는 데이터, 사용자와 공개 범위에 따라 달라지지만, 실제 사용자에게 공개한다면 해당 위험을 먼저 확인해야 합니다.

OWASP ASVS는 웹 애플리케이션의 기술적 보안 통제를 시험하고 안전한 개발 요구사항을 정하는 기준을 제공합니다. W3C WCAG는 웹 콘텐츠 접근성을 확인할 수 있는 성공 기준을 제공합니다. NXLAB은 이 항목들을 차별화 기능이 아니라 출시 가능 여부를 결정하는 별도 기준으로 다룹니다.

우선순위 회의에서 모든 담당자가 자신의 요청을 중요하다고 말하면 필수 목록이 줄지 않습니다. 기능의 장점을 설명하는 대신 이번 출시에서 그 기능을 제거했을 때 무엇이 불가능해지는지를 확인하면 논의를 같은 기준으로 맞출 수 있습니다.

GOV.UK는 필수, 중요, 가능, 제외 항목을 나누는 방법을 소개하며 제품 단계와 근거에 따라 우선순위를 다시 정하라고 안내합니다. NXLAB은 여기에 검증, 완결 흐름, 안전과 운영이라는 네 가지 제거 질문을 적용합니다.

사용자 결과가 필수라고 해서 처음부터 모든 자동화와 외부 연동이 필수인 것은 아닙니다. 예를 들어 접수 결과를 확인하는 흐름은 남기되, 초기 처리량이 감당 가능한지 확인한 뒤 일부 운영 단계를 정해진 수동 절차로 시작할 수 있습니다.

다만 수동 대체는 작업을 숨기는 방법이 아닙니다. 처리 담당자, 예상 빈도, 개인정보 취급, 실패 확인과 자동화로 전환할 조건을 문서화해야 합니다. 이 조건을 감당할 수 없다면 기능을 미루거나 더 작은 검증 방식으로 바꾸는 편이 안전합니다.

후속 기능을 단순히 나중에 한다고 적으면 요청이 반복될 때마다 같은 논의를 하게 됩니다. 어떤 사용자 문제나 운영 부담이 확인되면 다시 검토할지, 판단에 필요한 자료를 어디에서 얻을지를 함께 정해야 합니다.

GOV.UK는 서비스를 일찍 실제 사용자에게 제공하고 사용 데이터를 관찰해 반복 개선하며, 서비스 성과를 처음부터 측정할 방법을 고려하라고 안내합니다. 후속 기능은 최초 계획의 약속이 아니라 실제 근거에 따라 우선순위를 다시 정할 후보입니다.

기능명과 우선순위만 있는 목록은 개발 중에 해석이 달라질 수 있습니다. 기능이 연결된 사용자 요구, 확인할 결과, 포함 이유, 완료 기준과 후속 검토 조건을 같은 행에 적어야 고객과 개발자가 같은 범위를 확인할 수 있습니다.

NXLAB은 항목을 핵심 흐름, 출시 기준, 후속 후보와 이번 범위 제외로 나눕니다. 핵심 흐름과 출시 기준만 첫 버전에 포함하고, 후속 후보는 근거가 생길 때 다시 정하며, 제외 항목은 왜 이번 목표와 맞지 않는지 기록합니다. 이 표는 견적·일정·검수 기준을 합의할 입력 자료로 사용합니다.