개발 견적 전에 요구사항 정의서에서 확정해야 할 것

개발 견적 전에 요구사항 정의서에서 먼저 확정해야 하는 것은 화면 수나 버튼 수가 아닙니다. 누가 어떤 상황에서 무엇을 입력하고, 시스템이 어떤 결과를 내면 일이 끝나는지입니다. 이 흐름이 문장과 예외 조건으로 고정되어야 개발사는 같은 범위를 보고 견적을 낼 수 있고, 의뢰사는 견적서의 숫자가 무엇을 포함하는지 비교할 수 있습니다.

이 글의 결론은 간단합니다. 요구사항 정의서에는 목표 사용자와 업무 결과, 포함·제외 범위, 데이터와 권한, 정상·예외 흐름, 외부 연동, 비기능 요구사항, 검수 방법과 변경 규칙이 있어야 합니다. 아래 항목을 확정한 뒤에야 견적의 전제와 위험을 설명할 수 있습니다.

견적 전에 확정해야 하는 것은 기능이 아니라 업무의 끝입니다

“회원 관리 기능을 만듭니다”는 견적을 만들기에는 너무 넓습니다. 가입 대상이 누구인지, 이메일 인증이 필요한지, 탈퇴한 계정의 주문을 어떻게 보존하는지, 관리자가 어떤 정보를 볼 수 있는지에 따라 화면·API·데이터베이스·테스트 범위가 달라집니다. 요구사항은 명사 목록이 아니라 시작 조건과 종료 상태가 있는 업무 시나리오로 써야 합니다.

요구사항 문서의 목적은 개발자가 모든 디자인을 미리 상상하게 만드는 데 있지 않습니다. 의사결정이 필요한 부분과 아직 열어 둔 부분을 구분해, 견적에 포함할 작업과 별도 협의할 작업을 보이게 만드는 데 있습니다. 따라서 추정이 불가능한 항목은 감추지 말고 확인 질문, 가정, 위험으로 표시해야 합니다.

사용자 목표와 성공 결과를 한 문장으로 고정합니다

첫 페이지에는 프로젝트를 주문한 사람의 희망사항보다 실제 사용자의 목표를 적습니다. “관리자가 편하게 처리한다” 대신 “CS 담당자가 접수된 문의를 10분 안에 분류하고 담당자에게 배정해 고객에게 다음 행동을 안내한다”처럼 주체, 상황, 행동, 기대 결과를 넣습니다. 이 문장은 이후 기능 우선순위와 검수 항목의 기준이 됩니다.

GOV.UK 서비스 매뉴얼도 사용자 스토리에 사용자, 필요한 행동, 그 이유를 포함하고 목표를 중심으로 우선순위를 판단하도록 안내합니다.사용자 스토리 작성 지침은 인수 기준을 완료 여부를 확인하는 결과 목록으로 설명합니다. 이를 견적 전 단계에 적용하면 “기능을 만들었다”가 아니라 “사용자 목표가 달성되었음을 어떤 증거로 확인할지”까지 합의하게 됩니다.

• 사용자: 누가 이 흐름을 시작하고 결과를 소비하는가

• 문제: 지금 어떤 지연·오류·수작업을 줄이려는가

• 성공 결과: 업무가 끝났다고 판단할 수 있는 관찰 가능한 상태는 무엇인가

범위와 우선순위를 견적 가능한 단위로 나눕니다

범위 표에는 반드시 포함, 제외, 후속 검토를 나눠 적습니다. “결제 연동”을 포함한다고 썼다면 결제수단, 취소·부분 취소, 환불, 영수증, 실패 알림, 테스트 계정, 운영 키 교체까지 포함하는지 확인해야 합니다. 반대로 정산 자동화나 다국어 지원처럼 이번 목표에 필요하지 않은 항목은 제외한다고 명시해야 나중에 누락이 아니라 범위 밖이라는 사실을 설명할 수 있습니다.

우선순위는 “다 중요하다”로 끝내지 말고, 첫 출시에서 없으면 업무가 멈추는 항목과 있으면 편리한 항목을 분리합니다. 우선순위가 바뀌면 일정과 비용의 어떤 가정이 바뀌는지도 기록합니다. 작은 업무 흐름 하나를 끝까지 배포할 수 있는 수직 슬라이스로 잡으면, 목록만 많은 문서보다 견적과 검수 모두 구체적으로 만들 수 있습니다.

견적서에 선택 항목을 넣을 때는 기능 이름만 나열하지 않습니다. 선택 항목이 추가하는 화면·연동·데이터·테스트와 예상 영향, 선택하지 않았을 때의 수동 대안을 함께 적습니다. 그러면 의뢰인은 가장 싼 숫자와 가장 비싼 숫자 중 하나를 고르는 대신, 원하는 결과에 필요한 범위를 조정할 수 있습니다.

데이터·권한·외부 연동의 책임 경계를 표로 만듭니다

화면 정의만 있고 데이터 정의가 없으면 개발 중에 필드와 상태를 다시 설계하게 됩니다. 주요 데이터마다 식별자, 필수 여부, 형식과 단위, 생성자와 수정자, 보관 기간, 삭제·마스킹 규칙을 적습니다. “상태”도 대기·처리 중·완료·취소처럼 값만 쓰지 말고 언제 전이되고 누가 되돌릴 수 있는지 설명해야 합니다.

권한은 역할 이름보다 행동으로 검증합니다. 운영자는 문의를 조회하고 배정할 수 있지만 삭제할 수 없는지, 관리자는 환불을 승인할 수 있는지, 고객은 자신의 주문만 볼 수 있는지처럼 조회·생성·수정·삭제·승인 단위로 나눕니다. 개인정보가 포함된다면 누가 원문을 볼 수 있고 로그에는 어떤 형태로 남길지도 견적 전에 결정해야 합니다.

외부 연동에는 상대 시스템의 담당자와 문서 링크만 적지 말고 데이터 방향, 호출 시점, 인증 방식, 제한량, 타임아웃, 재시도, 중복 방지 키, 장애 시 수동 처리까지 적습니다. 연동 상대가 아직 정해지지 않았다면 특정 업체를 전제로 견적을 확정하지 말고, 연동 어댑터와 샘플 데이터 준비를 별도 가정으로 표시해야 합니다.

정상 흐름만큼 예외와 비기능 요구사항을 고정합니다

정상 흐름만 적은 정의서는 좋은 날의 데모만 설명합니다. 빈 필드, 잘못된 형식, 중복 제출, 권한 부족, 외부 응답 지연, 부분 성공, 사용자의 새로고침을 각각 어떻게 보여 주고 어디에 기록할지 적어야 실제 개발 범위를 계산할 수 있습니다. 실패한 요청을 다시 시도할지, 담당자 승인 뒤 재처리할지, 고객에게 어떤 안내를 보낼지도 결과 상태로 표현합니다.

비기능 요구사항은 “빠르게”, “안전하게”, “많이 처리하게” 같은 형용사를 숫자나 확인 방법으로 바꿉니다. 예를 들어 주요 목록의 목표 응답 시간, 동시 사용자의 가정, 허용 가능한 데이터 손실 시점, 백업과 복구 담당자, 지원 브라우저와 모바일 폭을 정합니다. 기준이 없는 성능·보안 요구사항은 견적에서 빠졌다가 출시 직전에 새 작업으로 나타나기 쉽습니다.

NASA 시스템공학 핸드북은 각 요구사항을 어떤 방법으로 검증할지 식별하는 검증 매트릭스와 고유 식별자를 제시합니다.요구사항 검증 매트릭스 안내처럼 “요구사항을 만족하는가”와 “사용자 기대에 맞는가”를 검증과 확인으로 나누면, 개발 완료 후에야 발견되는 해석 차이를 줄일 수 있습니다.

요구사항을 견적 입력값과 검수 산출물로 변환합니다

요구사항 문서가 끝나면 바로 금액을 적지 말고 추정 입력값을 추출합니다. 업무 흐름별 화면·API·데이터 변경·외부 연동·권한·테스트를 한 행에 놓고, 각 행에 확인된 사실과 가정을 나눠 적습니다. 요구사항 번호와 견적 항목 번호를 연결하면 어느 금액이 어느 기대 결과를 위한 것인지 추적할 수 있습니다.

1. 요구사항마다 고유 ID와 사용자 목표를 부여합니다.

2. 정상·예외 시나리오와 완료 증거를 적습니다.

3. 필요한 작업 단위와 불확실한 가정을 분리해 견적에 연결합니다.

4. 변경이 들어왔을 때 범위·일정·비용을 다시 계산할 기준을 합의합니다.

ISO/IEC/IEEE 29148은 요구사항 엔지니어링 과정에서 만들어야 할 정보 항목과 그 내용을 다루는 국제 표준입니다.ISO/IEC/IEEE 29148:2018 공식 설명을 그대로 복제할 필요는 없지만, 문서에 어떤 정보가 있어야 하는지 점검하는 기준으로 활용할 수 있습니다. 핵심은 문서의 분량이 아니라 각 요구사항이 설계·구현·검수로 이어지는 추적성입니다.

예시: 문의 접수 자동화의 견적 입력을 만드는 과정

다음은 특정 회사의 실제 프로젝트가 아닌 가상 사례입니다. 의뢰인은 홈페이지 문의를 담당자에게 자동 배정하고 싶어 합니다. 현재 입력은 이메일로 받고 있어 누락과 지연을 확인하기 어렵다는 것이 출발점입니다. 이 상태에서 “문의 관리 화면과 알림을 만들어 달라”고만 쓰면 견적자는 서로 다른 범위를 상상할 수 있습니다.

입력은 “방문자가 이름·이메일·문의 유형·내용을 제출한다”, 판단은 “문의 유형에 따라 담당 그룹을 찾고 스팸 의심이면 자동 배정하지 않는다”, 중간 산출물은 “REQ-04 시나리오 표와 상태 전이표, 담당 그룹 매핑표, 완료 기준 목록”으로 정합니다. 기대 결과는 “정상 문의가 한 건의 식별번호와 접수 시각을 갖고 담당자 큐에 표시되며, 방문자와 담당자에게 각각 확인 알림이 전달되는 상태”입니다.

이제 개발 작업을 분해할 수 있습니다. 방문자 폼과 유효성 검사, 문의·담당 그룹 데이터, 배정 규칙, 알림 발송, 관리자 목록과 상세, 스팸 보류 상태, 권한, 재처리 로그, 이메일 발송 실패 테스트가 각각 견적의 입력이 됩니다. “문자 알림도 필요한가”, “담당자가 바뀌면 기존 문의의 소유자가 바뀌는가”처럼 답하지 못한 질문은 미확정 항목으로 남기고, 답변 전에는 금액이 변할 수 있다는 가정을 견적서에 표시합니다.

실패한 정의서의 신호와 복구 경로를 따로 기록합니다

실패한 요구사항 정의서는 대개 화면 캡처와 기능 이름은 많지만, 누가 승인하는지와 어떤 상태가 완료인지가 없습니다. 견적 비교 때는 금액 차이만 보이고, 개발 중에는 “그 기능이면 이것도 되는 것 아닌가요?”라는 추가 요청이 계속 생깁니다. 정상 케이스만 있는 문서, 외부 연동 상대가 정해지지 않은 문서, 개인정보 처리 책임이 비어 있는 문서도 위험 신호입니다.

이때 문서를 처음부터 다시 쓰기보다 미확정 목록을 별도 표로 분리합니다. 각 질문에 담당자와 답변 기한을 붙이고, 답변 전에는 보수적인 가정으로 임시 견적을 계산합니다. 답변이 일정·데이터 모델·연동 범위를 바꾸면 변경 요청으로 기록하고, 단순 문구 수정이면 기존 범위 안에서 처리합니다. 범위를 합의하지 못한 채 개발을 시작해야 한다면 해당 항목을 옵션 또는 탐색 단계로 분리하고, 결과에 따라 본 개발 견적을 다시 산정하는 것이 복구 경로입니다.

반대로 이미 운영 중인 서비스의 작은 문구 수정처럼 데이터·권한·상태·연동에 영향을 주지 않는 작업에는 이 정도의 정의서가 과할 수 있습니다. 변경 범위가 한 화면의 표시와 테스트로 닫히고 담당자가 완료 증거를 즉시 확인할 수 있다면 간단한 티켓과 인수 기준으로 충분합니다. 문서의 크기는 프로젝트의 위험과 비례해야 합니다.

견적을 요청하기 전 마지막 점검표

아래 질문에 문서 안에서 바로 답할 수 있는지 확인합니다. 답이 없다는 사실 자체가 나쁜 것은 아니지만, 미확정 상태와 답변 주체가 보여야 견적의 불확실성을 관리할 수 있습니다.

• 사용자 목표와 첫 출시의 성공 결과가 한 문장으로 적혀 있는가

• 포함·제외·옵션 범위와 범위 변경 승인자가 정해져 있는가

• 주요 데이터의 상태 전이, 권한, 보관·삭제 책임을 확인했는가

• 외부 연동의 실패·재시도·수동 복구와 운영 담당자가 정해져 있는가

• 각 요구사항에 검수 방법과 완료 증거가 하나 이상 연결되어 있는가

완료 조건은 문서가 예쁘게 정리된 상태가 아닙니다. 견적에 참여한 사람이 같은 시나리오를 읽고 포함 범위, 가정, 제외 범위, 검수 증거를 같은 말로 설명할 수 있는 상태입니다.

완료 조건을 기록하고 견적의 전제를 보존합니다

요구사항 정의서의 버전, 승인자, 승인일, 미확정 질문, 견적 항목과의 연결표를 함께 보관합니다. 개발이 시작된 뒤 요구가 바뀌면 원래 문서를 조용히 고치지 말고 변경 전후의 범위와 영향, 재산정된 일정·비용을 남깁니다. 이렇게 해야 나중에 책임을 따지기보다 어떤 가정이 바뀌었는지 확인할 수 있습니다.

검증 완료는 사용자 목표, 범위, 정상·예외 흐름, 데이터·권한·연동, 비기능 기준, 검수 방법을 확인하고 기록한 뒤, 의뢰인과 개발사가 같은 샘플 시나리오의 입력·판단·결과를 재현할 때로 정합니다. 이 조건을 충족한 문서라면 견적 숫자 자체보다 그 숫자가 어떤 결과와 위험을 포함하는지 설명할 수 있습니다.