외주 개발 견적, 수정 요청과 추가 개발을 나누는 기준

안녕하세요. 사랑받는 IT 프로덕트의 첫걸음, 똑똑한개발자입니다.

오늘의 인사이트 요약
기능 이름보다 사용 조건과 완료 기준을 구체적으로 정합니다.
오류 수정과 요구사항 변경은 합의한 동작에 비춰 구분합니다.
변경 요청에는 비용뿐 아니라 일정과 검수 영향도 남깁니다.

외주 개발을 진행하다 보면 작아 보이는 수정 요청에도 추가 견적이 나와 당황할 수 있습니다. 발주자는 원래 포함된 기능이라고 생각하고 개발사는 새 요구라고 이해하면 같은 화면을 놓고도 이야기가 길어집니다. 요청한 화면이 몇 개인지만 세어서는 이런 차이를 설명하기 어렵습니다.

변경을 아예 막기보다 처음 합의한 동작과 이후 달라진 요청을 비교할 수 있어야 합니다. 오늘은 외주 개발 견적에서 수정 요청과 추가 개발을 나누고, 변경 비용을 검토하는 방법을 정리해보겠습니다.

기능 이름을 실제 동작으로 풀어야 합니다.

견적서에 회원 관리나 검색 기능이라고만 적혀 있으면 서로 다른 결과를 기대하기 쉽습니다. 누가 어떤 정보를 입력하고 어떤 결과를 보는지 한 흐름으로 풀어 봅니다. 관리자가 쓸 화면과 고객이 쓸 화면도 연결해 살펴야 한쪽에만 반영된 요구를 찾을 수 있습니다.

완료 여부를 확인할 조건을 함께 적습니다.

검색 기능이라면 대상 데이터와 검색할 항목, 결과를 보여줄 순서를 정합니다. 검색 결과가 없을 때 안내할 내용과 권한이 없는 자료를 제외하는 조건도 필요합니다. 화면 디자인만 확인하고 넘어가면 데이터가 들어온 뒤에야 예상과 다른 동작을 발견할 수 있습니다.

예를 들어 보겠습니다.
상품명을 입력하면 해당 상품을 보여주는 검색을 요청했다고 가정합니다. 오타를 자동으로 고치거나 비슷한 상품을 추천하는 기능까지 포함하는지는 상품명 검색이라는 이름만으로 정하기 어렵습니다.

이미 확정한 내용은 화면 설계서나 요구사항 목록의 해당 항목과 연결해 둡니다. 문서를 많이 만드는 것보다 현재 유효한 버전이 무엇인지 알 수 있는 것이 중요합니다. 검토 중인 제안과 반영하기로 결정한 내용은 구분해 둡니다. 그래야 회의에서 나온 모든 의견을 개발 범위로 오해하는 일을 줄일 수 있습니다.

똑똑한개발자팀은 기능 목록에 사용 조건과 완료 기준이 함께 있어야 견적을 비교할 수 있다고 봅니다. 항목 이름이 같아도 처리할 데이터와 예외 상황이 다르면 필요한 작업이 달라지기 때문입니다.

수정 요청은 합의한 동작과 비교해야 합니다.

오류인지 추가 요구인지는 요청 문장의 길이로 판단하기 어렵습니다. 합의한 조건에서 버튼이 작동하지 않는 문제와 새로운 사용자 유형에게 같은 버튼을 제공하는 요청은 다르게 검토해야 합니다. 수정 전후에 사용자가 할 수 있는 일이 어떻게 달라지는지 설명해 주세요.

애매한 요청은 근거를 확인한 뒤 분류합니다.

기존 문서에 동작이 빠져 있다면 어느 한쪽의 기억만으로 결론 내리지 않습니다. 당시 화면, 회의 기록, 승인한 설계 내용을 함께 보고 원래 기대했던 결과를 맞춥니다. 개발사가 기능을 구현하지 못했는지, 처음 설명이 부족했는지, 나중에 기능이 필요해졌는지부터 구분합니다.

가정해 보겠습니다.
관리자만 내려받는 목록을 일반 직원도 내려받게 해 달라는 요청이 들어왔습니다. 화면에 버튼 하나를 추가하더라도 직원에게 보여줄 데이터 범위와 다운로드 권한, 기록 방식까지 살펴야 할 수 있습니다.

분류가 끝나기 전에 비용이나 일정을 확정하면 빠진 작업이 뒤늦게 드러날 수 있습니다. 먼저 요청의 목적과 원하는 결과를 확인하고 개발사가 영향 범위를 검토하도록 합니다. 문구 변경처럼 작은 작업도 여러 화면에서 공통으로 쓰는 내용이라면 어디까지 반영할지 확인합니다.

요청별 완료 조건과 프로젝트 전체가 공통으로 지킬 품질 조건도 구분하면 좋습니다. 기능이 동작하는 것 외에 테스트와 문서 갱신까지 완료 범위에 넣는 방법은 Atlassian의 완료 정의 안내에서 더 자세히 보실 수 있습니다.

변경 견적에는 일정과 검수 범위를 남겨야 합니다.

추가 비용을 검토할 때는 무엇을 바꾸는지와 어떤 작업이 늘어나는지를 함께 봅니다. 화면 수정 뒤에 데이터 구조 변경이나 외부 서비스 연동, 기존 기능 재검수가 필요한지 확인합니다. 작업 시간이 왜 늘어나는지 알면 요청을 줄이거나 다음 배포로 미룰지 판단하기도 수월합니다.

이번 배포에 넣을 일과 나중에 할 일을 나눕니다.

변경 요청마다 요청 이유, 반영할 동작, 영향받는 화면, 비용과 일정, 결정한 담당자를 남깁니다. 별도 관리 도구가 없더라도 같은 목록에서 검토 중인지 승인됐는지 볼 수 있으면 됩니다. 보류한 요청은 삭제하지 말고 다음 검토 시점이나 보류 이유를 적어 둡니다.

똑똑한개발자팀은 변경을 승인할 때 이번 배포에서 무엇을 먼저 완성할지도 함께 결정해야 한다고 생각합니다. 기능을 추가한 뒤에도 기존 일정만 유지하면 검수할 시간이 부족해질 수 있기 때문입니다. 일정이 고정돼 있다면 덜 급한 요구를 다음 배포로 옮길 수 있는지 먼저 논의합니다.

변경된 기능을 확인할 때는 연결된 기존 흐름도 다시 살핍니다. 검색 조건을 추가했다면 결과 목록과 다운로드에서도 같은 조건이 적용되는지 확인하는 식입니다. 변경 승인 기록에 검수할 내용을 함께 남겨 두면 담당자가 바뀌어도 완료 여부를 같은 조건으로 판단할 수 있습니다.

견적 단계부터 변경을 논의할 방식을 맞춰야 합니다.

첫 견적을 받을 때 포함 범위와 제외 범위, 아직 정하지 못한 항목을 나눠 달라고 요청하세요. 미정 항목을 모두 포함된 것으로 생각하면 이후 협의가 어려워집니다. 어떤 자료를 확인한 뒤 범위를 정할 수 있는지도 함께 적으면 다음 회의의 목적이 분명해집니다.

개발 중 필요한 변경은 생길 수 있습니다. 중요한 것은 새 요청이 생겼을 때 누구에게 전달하고, 누가 영향 범위를 설명하며, 어떤 기록을 남기고 반영할지 합의하는 일입니다. 이렇게 협의하면 서로 다른 요청을 동시에 전달하거나 이전 합의를 뒤집는 일을 줄일 수 있습니다.

똑똑한개발자는 프로덕트의 기획·디자인·개발·운영을 연결해 지원합니다. 사용자 화면과 실제 운영 업무를 함께 살피며 개발 범위와 우선순위를 구체화합니다. 처음 정한 요구와 이후 운영에 필요한 개선을 이어서 검토할 수 있도록 서비스 전체 흐름을 다룹니다.

외주 개발 범위와 변경 요청의 우선순위를 구체화하고 싶다면 아래 똑똑한개발자 링크로 이야기 나눠주세요!

감사합니다. :)