범위
무엇을 만드는지 먼저 고정합니다.
- 화면 목록과 화면별 목적
- 사용자 시나리오의 시작과 끝
- 관리자 기능과 권한 구분
가이드를 활용하는 순서
요구사항 명세를 먼저 정리하고, 그다음 제안서 검토 기준을 확인합니다. 각 단계는 앞 단계의 결과물을 기준으로 진행되므로 순서를 건너뛰면 비교 기준이 흔들립니다. 아래 네 단계만 지켜도 후보를 좁히는 시간이 크게 줄어듭니다.
먼저 준비할 것
요구사항 명세
화면 목록과 기능 범위, 경계 조건을 항목으로 적어 후보에게 같은 기준을 제시합니다.
그다음 확인
제안서 검토 기준
견적과 일정, 투입 인력을 같은 항목으로 놓고 비교표를 만듭니다.
후보를 좁힌 뒤
검증과 일정 산정
사업자 정보와 수행 이력을 확인하고, 검수 가능한 산출물 단위로 마일스톤을 잡습니다.
요구사항 명세 작성 가이드
화면 목록, 사용자 시나리오, 관리자 기능, 외부 연동, 기술 스택을 항목으로 나눠 적습니다. 처음 작성하는 경우 프로젝트 등록 단계에서 담당자가 보완을 요청합니다. 문서 한 장이 후보 다섯 곳의 견적 편차를 줄입니다.
우선순위
"필수"와 "있으면 좋음"을 구분합니다.
- 1차 오픈에 반드시 필요한 기능
- 2차로 미룰 수 있는 기능
- 예산 안에서 조정 가능한 항목
경계 조건
여기까지가 범위라고 선을 긋습니다.
- 외부 연동 대상과 방식
- 기술 스택과 호스팅 조건
- 제외 범위와 향후 확장 지점
쓰는 순서
서비스 목적 한 문단에서 시작해 화면 목록으로 넓히고, 마지막에 기술 조건을 붙입니다. 목적을 먼저 적으면 기능을 덜어낼 기준이 생깁니다.
분량 기준
길이보다 항목의 완결성이 중요합니다. 화면 하나에 목적·입력값·완료 조건을 한 줄씩 적으면, 문장을 다듬지 않아도 견적 기준으로 충분합니다.
보완 요청
처음 작성한 문서는 프로젝트 등록 단계에서 담당자가 빠진 항목을 짚어 드립니다. 빠진 항목을 확인한 뒤 후보에게 같은 문서를 배포하세요.
프로젝트 제안서 검토 기준
견적, 일정, 투입 인력, 기술 스택, 유지보수 조건을 같은 항목으로 비교합니다. 가격만 보지 않고 일정과 인력 구성을 같이 봐야 합니다. 담당자가 비교표를 만들어 강점과 주의할 점을 함께 표시합니다.
비용과 계약 기준 확인-
견적과 포함 범위
금액 · 범위
같은 기능을 기준으로 금액을 비교합니다. 총액보다 어떤 항목이 포함되고 무엇이 제외되는지가 이후 추가 비용을 좌우합니다.
-
일정과 마일스톤
기간 · 산출물
전체 기간보다 중간 산출물이 언제 나오는지를 확인합니다. 검수 시점이 명시된 제안서가 이후 일정 조정에 유리합니다.
-
투입 인력 구성
역할 · 기간
누가 어떤 역할로 며칠을 투입하는지 적혀 있는지 봅니다. 담당자 한 명이 전부를 맡는 구성은 협업 리스크가 큽니다.
-
기술 스택과 유지보수
스택 · 운영
우리 환경과 맞는지, 첫해 이후 누가 유지보수를 맡는지를 확인합니다. 변경 요청 정산 방식과 검수 기준이 포함되어 있는지도 봅니다.
-
비교표 만드는 법
항목 · 표시
항목을 행으로, 후보를 열로 놓고 빈칸이 남지 않게 채웁니다. 담당자가 비교표를 만들며 강점과 주의할 점을 함께 표시합니다.
후보를 좁히는 단계
개발사 검증 체크리스트
사업자 정보와 이력
사업자 정보, 수행 이력, 산출물 링크를 확인합니다. 비슷한 규모의 프로젝트 경험과 담당 역할, 투입 기간을 봅니다. 협업 방식과 산출물 공유 주기도 참고 자료입니다. 검증되지 않은 업체는 후보 목록에 올리지 않습니다.
확인해야 할 세 가지
- 수행 이력에 이번 프로젝트와 비슷한 규모가 있는가
- 담당자가 프로젝트에 얼마나 오래 투입되는가
- 산출물 공유 주기와 검수 방식이 문서로 남는가
일정 산정 방법
마일스톤은 검수 가능한 산출물 단위로 잡습니다. 주 단위로 계획과 실적을 비교하고 지연 원인을 기록합니다. 일정이 밀릴 때는 범위를 조정할지 기간을 늘릴지 미리 합의합니다.
일정
검수 단위로 쪼개기
주 단위로 계획과 실적을 나란히 놓고 비교합니다. 산출물이 나오지 않는 주가 이어지면 그 자체가 지연 신호입니다.
지연
지연 원인 기록
밀린 이유를 남겨 두면 같은 지점에서 다시 밀리지 않습니다. 원인을 기록하면 범위를 줄일지 기간을 늘릴지 판단이 쉬워집니다.
합의
범위 조정 사전 합의
일정이 흔들릴 때를 대비해 어떤 기능을 뒤로 미룰지 미리 이야기해 둡니다. 초기 정렬이 잘 되면 이후 이슈 대응이 수월해집니다.
프리랜서와 개발사 선택 기준
역할이 세 개를 넘어가면 개발사 쪽을, 특정 기능만 필요하면 프리랜서 쪽을 먼저 검토합니다. 기획과 디자인이 이미 준비되어 있는지도 판단에 영향을 줍니다.
매칭 방식 보기프로젝트 단위
프리랜서를 검토할 때
특정 기능만 필요하거나 기획과 디자인이 이미 준비되어 있을 때 맞습니다. 프로젝트의 시작과 끝이 분명한 작업에 어울립니다.
역할이 여러 개일 때
개발사를 검토할 때
역할이 세 개를 넘어가면 개발사 쪽을 먼저 봅니다. 기획·개발·운영을 한 팀이 이어서 맡을 수 있기 때문입니다.
운영이 계속될 때
상시 운영이 필요하면
프로젝트 종료 후에도 개선과 장애 대응이 이어지는 경우라면 운영형 서비스가 더 맞을 수 있습니다.
두 후보를 함께 볼 때
같은 기준으로 비교
프리랜서와 개발사를 함께 놓고 같은 항목으로 비교해도 됩니다. 비교 기준을 항목으로 고정하면 선택 근거를 설명하기 쉬워집니다.
계약과 NDA 준비
NDA, 지식재산권 귀속, 대금 지급 조건, 검수 기준, 변경 요청 정산 방식을 정리합니다. 운영까지 포함하면 SLA와 장애 대응 시간을 추가합니다.
문서에 담을 항목
- 비밀유지 범위와 유지 기간
- 산출물의 지식재산권 귀속
- 대금 지급 시점과 조건
- 검수 기준과 완료 판정 방식
- 변경 요청 정산 방식
- 운영 시 SLA와 장애 대응 시간
문서 정합성
계약서와 관리 문서의 산출물 목록을 일치시킵니다. 한쪽에만 있는 항목은 나중에 분쟁 지점이 됩니다.
법무 검토 일정
법무 검토가 필요한 경우 미리 일정에 반영합니다. 검토에 걸리는 기간을 착수일 앞에 두면 첫 마일스톤이 밀리지 않습니다.
처음 외주를 맡길 때 하는 실수
반복적으로 나오는 세 가지가 있습니다. 세 가지 모두 제안서를 받기 전에 고칠 수 있습니다.
예산
예산을 공개하지 않아 제안서 편차가 커지는 경우가 있습니다. 범위를 밝히면 비교가 훨씬 빨라집니다.
요구사항
요구사항을 "알아서 잘"로 넘기면 후보마다 다른 결과물을 상상합니다. 항목으로 적어 같은 문서를 나눠 주세요.
기준
선정 기준을 문서화하지 않으면 마지막에 감으로 고르게 됩니다. 기준을 세 개 이내로 정리하세요.
자주 나오는 질문
가이드를 적용할 때 자주 반복해서 나오는 질문을 정리했습니다. 답을 그대로 문서에 옮겨도 됩니다.
요구사항 명세는 어디까지 써야 하나요?
화면 목록, 사용자 시나리오, 관리자 기능, 외부 연동, 기술 스택과 경계 조건을 항목으로 적으면 충분합니다. 문장을 매끄럽게 다듬는 것보다 빠진 항목이 없는지 확인하는 편이 도움이 됩니다.
제안서에서 가장 먼저 봐야 할 항목은 무엇인가요?
포함 범위와 일정, 투입 인력 구성입니다. 가격은 그다음에 비교합니다. 범위와 일정이 다르면 같은 금액이라도 실제 조건이 달라집니다.
처음 외주를 맡길 때 가장 흔한 실수는 무엇인가요?
예산을 공개하지 않거나 요구사항을 모호하게 넘기는 경우입니다. 선정 기준을 미리 정해 두면 비교가 수월해집니다. 기준은 세 개 이내로 정리하면 회의에서도 설명이 짧아집니다.
개발사 검증은 어느 시점에 끝내야 하나요?
계약서를 쓰기 전에 마칩니다. 사업자 정보와 수행 이력, 산출물 링크를 확인하는 단계는 후보를 두세 곳으로 좁힌 뒤에 집중하는 편이 효율적입니다.
요구사항이 바뀌면 일정은 어떻게 조정하나요?
변경 항목을 문서로 남기고 기간과 금액에 어떤 영향이 있는지 같은 자리에서 합의합니다. 변경 요청 정산 방식을 계약서에 적어 두면 이후 조정이 훨씬 수월합니다.
준비한 문서 그대로 시작하세요
요구사항 명세를 정리했다면 프로젝트를 등록하고, 후보 제안서를 받아 같은 기준으로 비교하세요. 문서가 준비된 프로젝트일수록 담당자가 빠르게 매칭을 진행할 수 있습니다.
아직 정리가 덜 됐다면 문의를 남겨 주세요. 평일 09:00 - 18:00 사이에 확인하고 답변드립니다.