SI 도급 개발, 계약 이후 어떻게 진행될까 | 모르면 손해보는 체크포인트

SI 도급 계약서에 도장을 찍은 순간, 많은 발주자들이 같은 고민을 하기 시작합니다. "그래서, 이제 뭘 해야 하지?" 요구사항 정의서는 어디까지 디테일하게 써야 하는지, 킥오프 미팅에서 뭘 합의해야 하는지, 단계마다 어떤 산출물을 받아야 하는지 상세하게 알려주는 곳은 많지 않습니다. 계약서 작성법을 다루는 자료는 많아도, 계약 이후의 실제 진행 흐름은 정작 공백으로 남아 있는 영역입니다.

도급 개발 프로세스는 계약 체결 이후 '요구사항 정의 → 설계 → 개발 → QA → 납품 → 유지보수' 6단계로 진행됩니다. 발주자가 각 단계마다 정해진 산출물 검수와 변경 관리 절차에 직접 참여해야 일정·비용 분쟁을 막을 수 있어요. 발주자가 손을 놓는 순간 프로젝트는 개발사의 페이스대로 흘러가고, 납품 직전에서야 "이게 아닌데"라는 말이 나오기 시작합니다.

1. 도급 개발은 계약 이후 어떤 순서로 진행될까?

도급 개발은 '요구사항 정의 → 분석·설계 → 개발 → QA(테스트) → 납품·검수 → 유지보수' 6단계로 흘러갑니다. 단계마다 정해진 산출물을 발주자가 검수·승인해야 다음 단계로 넘어가는 구조죠.

이 구조를 워터폴(Waterfall, 위에서 아래로 순차 진행되는 방식)이라고 부르는데요. 도급 계약은 "정해진 결과물을 정해진 값에 완성한다"는 약속이기 때문에, 범위를 먼저 확정한 뒤 단계적으로 내려가는 흐름이 자연스럽게 맞물립니다. 계약 방식(턴키·맨먼스)까지 정리됐다면, 이제 실제 프로젝트는 이 순서대로 진행된다고 보시면 됩니다.

1-1. 각 단계는 얼마나 걸리고, 어떤 산출물이 나올까?

전체 일정을 100%로 볼 때, 개발 단계가 가장 큰 비중을 차지하고 요구사항 정의·설계가 그 다음을 따라옵니다. 이 비중 감각을 미리 잡아두면 일정이 어디서 밀리는지 빠르게 알아챌 수 있어요.

이 비중은 일반적인 도급 개발 프로젝트에서 자주 관찰되는 분포인데요. 실무에서는 "개발이 절반쯤 차지하고, 그 앞뒤로 정의·설계·QA가 비슷한 무게"라는 감각으로 잡아두면 충분합니다.

1-2. 단계 간 '게이트(Gate)'는 왜 중요한가?

게이트(Gate)란 한 단계에서 다음 단계로 넘어가기 전에 발주자가 산출물을 검수하고 서면으로 승인하는 통과 지점을 말합니다. 도급 개발 프로세스에서는 이 게이트가 프로젝트의 안전장치 역할을 해요.

게이트 없이 다음 단계로 넘어가면 후반에 큰 비용을 치르게 됩니다. 예를 들어 요구사항 정의서가 모호한 채로 개발에 들어가면, QA 단계에서 "이건 우리가 생각한 기능이 아니다"라는 갈등이 터지는데요. 이때는 이미 코드의 절반 이상이 작성된 뒤라 수정 범위가 처음의 몇 배로 늘어납니다.

발주자 입장에서는 게이트마다 '검수확인서' 또는 '단계 완료 승인서' 형식으로 서명을 남기는 것이 안전해요. 단순히 회의에서 "좋아 보인다"고 말하는 수준이 아니라,

2. 킥오프 전, 발주자는 무엇을 준비해야 할까?

킥오프 전에 발주자가 챙겨야 할 건 요구사항 정의서, 의사결정 라인, 데이터·계정 접근 권한, 일정 마일스톤 초안 4가지입니다. 이 4가지가 빠진 채 킥오프를 열면, 첫 2~3주가 자료 요청과 회신 대기로 흘러갑니다.

도급 개발은 계약서에 도장을 찍는 순간부터가 아니라, 킥오프 미팅 어젠다가 채워지는 순간부터 실제로 움직이기 시작해요. 발주자가 어디까지 준비해두느냐에 따라 도급 개발 진행 방법의 초반 속도가 완전히 달라지죠.

2-1. 요구사항 정의서, 어디까지 써놓고 시작해야 하나?

요구사항 정의서는 화면 단위까지 세세하게 그릴 필요는 없습니다. 다만 핵심 기능 목록, 사용자 시나리오(누가 어떤 상황에서 무엇을 하려고 이 기능을 쓰는지), 비기능 요구사항(성능·보안·동시 접속자 수 같은 '기능 외 조건')은 킥오프 전에 정리돼 있어야 해요.

가장 중요한 건 우선순위 결정입니다. "A 기능은 반드시 있어야 한다" vs "B 기능은 없어도 된다"를 발주자가 미리 구분해두지 않으면, 개발 중반에 일정이 밀릴 때 무엇을 빼야 할지 협상이 길어집니다. MoSCoW 분류(Must have / Should have / Could have / Won't have)처럼 단순한 4단계 우선순위만 붙여둬도 의사결정 속도가 빨라져요. 또는 현재 예산 범위에 맞추어 우선순위가 높은 기능과 낮은 기능을 분류하여 요구사항을 정리하고 개발을 진행시킬 수 있는 능력을 가진 개발사와 함께해야합니다.

👉 요구사항 정의서 필수항목 7가지와 작성가이드 보기

2-2. 킥오프 미팅에서 반드시 합의해야 할 항목은?

킥오프는 친목 자리가 아니라 프로젝트의 운영 규칙을 확정하는 자리입니다. 아래 7가지는 킥오프 당일 합의하고 회의록에 남겨야 SI 도급 계약 후 프로세스가 흔들리지 않아요.

1. 프로젝트 목표 — 이 프로젝트로 무엇을 달성해야 성공인지 한 문장으로 합의
2. 범위(Scope) — 요구사항 정의서 기준으로 '이번에 만드는 것 / 만들지 않는 것' 경계 확정
3. 일정 마일스톤 — 분석·설계·개발·QA·납품 각 단계 종료 시점
4. 커뮤니케이션 채널 — 일상 소통(슬랙/메신저) vs 공식 의사결정(이메일/회의록) 채널 분리
5. 의사결정 라인 — 누가 최종 승인하는지, 부재 시 위임자가 누구인지
6. 산출물 검수 절차 — 단계별 산출물을 어떤 기준으로 확인하고 며칠 내 피드백할지
7. 변경 관리 룰 — 요구사항이 바뀔 때 비용·일정 재산정 절차

2-3. 킥오프 전 준비 체크리스트

준비 항목별로 누가 만들고, 킥오프 전 어디까지 완료돼야 하며, 빠졌을 때 어떤 일이 벌어지는지 한 번에 정리하면 다음과 같아요.

이 표에 있는 5가지가 킥오프 당일 회의록에 모두 정리돼 있어야, 다음 단계인 분석·설계 구간에서 발주자와 개발사가 같은 그림을 보고 일할 수 있어요. 계약서 단계에서 챙겨야 할 조항들은 외주 개발 계약서 체크리스트에 따로 정리해뒀으니, 계약서까지 마쳤다면 이 글의 킥오프 준비 단계로 자연스럽게 넘어오시면 됩니다.

3. 개발 진행 중, 단계별로 어떤 산출물을 받아야 할까?

발주자는 분석·설계 단계에서 화면 정의서·기능 명세서·ERD를, 개발 단계에서 주차별 진척 리포트와 데모를, QA 단계에서 테스트 케이스와 결함 리포트를 받아야 합니다. 산출물 없이 "진행 중"이라는 말만 듣고 있으면 안 됩니다.

도급 개발 프로세스에서 가장 위험한 신호는 "잘 되고 있어요"라는 구두 보고가 반복되는 상황이에요. 산출물이 없으면 진척률을 검증할 방법이 없고, 후반에 가서야 일정이 무너졌다는 사실을 알게 되죠.

3-1. 분석·설계 단계에서는 무엇을 확인해야 하나?

분석·설계 단계의 핵심 산출물은 네 가지입니다. 화면 정의서(스토리보드), 기능 명세서, DB 설계서(ERD, 데이터가 어떻게 저장되고 연결되는지 보여주는 설계도), 시스템 아키텍처 도식이에요.

발주자가 가장 꼼꼼히 봐야 할 건 화면 정의서입니다. 사용자가 앱이나 웹에서 실제로 보게 될 화면을 순서대로 그려둔 문서라, "내가 머릿속에 그렸던 사용자 흐름과 일치하는가"를 비개발자도 직관적으로 검수할 수 있어요. 이 단계에서 의도와 다른 부분을 잡지 못하면 개발이 끝난 뒤에 재작업 비용이 몇 배로 불어납니다.

ERD와 아키텍처 도식은 직접 검수가 어렵다면 도급사에 "왜 이렇게 설계했는지" 30분짜리 설명 미팅을 요청하세요. 도급사가 설명을 회피하거나 자료가 부실하면 그 자체가 위험 신호입니다.

3-2. 개발 단계에서 PM이 매주 챙겨야 할 것은?

개발 단계에서 발주자 측 PM이 매주 받아야 할 산출물은 진척 리포트와 정기 데모 두 가지입니다. 진척 리포트는 완료 기능, 진행 중 기능, 이슈 사항을 기능 단위로 정리한 문서예요.

여기서 가장 흔한 실수는 진척률을 "%"로만 보고받는 것입니다. "현재 60% 진행됐어요"라는 말은 검증이 불가능해요. 어떤 기능이 완료됐고 어떤 기능이 남았는지 기능 단위로 체크해야 후반에 무너지지 않습니다.

2~3주 단위 데모도 반드시 요청하세요. 실제로 동작하는 화면을 보면 명세서로는 잡히지 않는 어색한 사용자 흐름이 드러나거든요. 데모를 거부하거나 미루는 도급사는 일정 관리에 문제가 있을 가능성이 높습니다.

잔여 공수(남은 작업량을 사람·일 단위로 환산한 수치) 추적도 함께 봐야 해요. 초기 견적 공수 대비 실제 소진 공수가 어느 정도인지 매주 확인하면, 일정 지연을 2~3주 전에 미리 감지할 수 있습니다.

3-3. QA 단계에서 발주자가 직접 챙겨야 할 부분은?

QA(Quality Assurance, 품질 보증 테스트) 단계에서 발주자가 직접 챙겨야 할 건 세 가지예요. 테스트 시나리오 사전 합의, 결함 등급 기준 합의, UAT(User Acceptance Test, 사용자 인수 테스트) 일정 확보입니다.

테스트 시나리오는 QA가 시작되기 전에 미리 합의해야 합니다. "어떤 케이스까지 테스트할 것인가"를 정해두지 않으면, 도급사는 정상 케이스만 테스트하고 끝낼 수 있어요. 비정상 입력, 동시 접속, 결제 실패 같은 예외 케이스를 시나리오에 명시적으로 넣어야 합니다.

결함 등급 기준도 반드시 사전에 합의하세요. 일반적으로 Critical(서비스 중단), Major(주요 기능 오작동), Minor(경미한 UI 오류) 3단계로 나눕니다. 등급 기준이 없으면 "이건 사소한 버그라 납품 후 처리하면 된다"는 식의 분쟁이 생겨요.

UAT는 발주자가 실제 사용자 입장에서 직접 검수하는 마지막 단계입니다. 최소 5~10영업일을 확보하지 않으면 시간에 쫓겨 형식적인 검수가 되니, 일정 마일스톤에 미리 반영해 두세요.

3-4. 단계별 산출물·검수 포인트 한눈에 보기

4. 요구사항이 바뀌면 일정·비용은 어떻게 조정해야 할까?

요구사항 변경은 'CR(Change Request, 변경 요청서) 접수 → 영향 분석 → 일정·비용 재산정 → 변경 합의서 서명' 4단계로 처리합니다. 구두 합의로 넘어가면 거의 100% 분쟁으로 이어지므로 모든 변경은 문서로 남겨야 해요.

도급 개발 프로세스에서 기획이 한 번도 안 바뀌는 프로젝트는 거의 없습니다. 문제는 변경 자체가 아니라, 변경을 처리하는 절차가 없을 때 생기죠. "이 정도는 그냥 해주세요"가 누적되면 도급사는 일정을 못 맞추고, 발주자는 갑자기 추가 비용 청구서를 받게 됩니다.

4-1. 어디까지가 '범위 내'이고, 어디부터 '추가 비용'인가?

기준선(Baseline)은 킥오프에서 합의한 요구사항 정의서입니다. 이 문서에 적혀 있으면 범위 내, 적혀 있지 않으면 추가 공수 대상이라고 보면 돼요.

실무에서 자주 혼동되는 경계는 세 가지입니다. 명세에 없던 기능을 새로 넣는 경우, 화면 흐름을 처음 합의와 다르게 바꾸는 경우, 그리고 비기능 요구사항(응답 속도·동시 접속자 수 등 성능 기준)을 상향하는 경우는 모두 추가 공수 대상이에요. 반면 도급사가 만든 결과물이 명세대로 동작하지 않는 단순 버그 수정은 도급사 책임이고, 별도 비용을 청구할 근거가 없습니다.

4-2. 추가 공수와 비용은 어떻게 산정해야 합리적인가?

추가 공수는 맨먼스(M/M, 개발자 한 명이 한 달간 일하는 작업량 단위) × 표준 단가로 계산합니다. 이때 새로 추가되는 기능만 보는 게 아니라, 그 변경이 영향을 주는 기존 기능까지 함께 견적에 반영해야 합리적이에요.

예를 들어 회원가입에 본인인증을 추가하면, 회원가입 화면 자체뿐 아니라 로그인·비밀번호 재설정·관리자 페이지까지 줄줄이 수정이 필요합니다. 발주자가 "이 기능 하나만 추가하는 건데 왜 이렇게 비싸지"라고 느끼는 지점이 바로 여기예요. 일정 영향(Critical Path, 전체 프로젝트 종료일을 결정짓는 가장 긴 작업 경로)이 며칠 지연되는지도 견적과 함께 명시해야 분쟁이 줄어듭니다.

4-3. 변경 합의서에는 무엇이 들어가야 하나?

변경 합의서는 원 계약서의 부속 문서로 관리합니다. 변경 사유, 변경 전후 범위, 추가 공수와 비용, 일정 조정, 검수 기준, 양사 서명 6개 항목이 들어가야 효력이 있어요.

CR 이력과 공수 변동을 누가 어떻게 추적하느냐도 중요한데요. 변경이 누적될수록 "이게 몇 번째 CR인지, 누적 추가 비용이 얼마인지" 발주자가 한눈에 보지 못하면 예산 통제가 무너집니다. 그릿지는 커뮤니케이션 시트를 통해 CR 접수·승인·공수 변동 이력을 발주자가 실시간으로 확인할 수 있게 관리합니다.

5. 프로젝트 중간에 일정·품질 리스크는 어떻게 모니터링할까?

발주자는 잔여 공수, 결함 발생률, 일정 슬립(Slip, 계획 대비 일정이 밀린 정도) 3개 지표를 주 단위로 확인해야 합니다. "진행률 80%"라는 보고는 신뢰하기 어렵고, 기능 단위 완료율과 결함 등급 분포로 봐야 실제 상태가 보이죠.

도급 개발 프로세스에서 가장 위험한 순간은 "잘 되고 있어요"라는 말이 반복되다가, 막판 2주를 남기고 갑자기 일정이 무너지는 시점입니다. 이걸 막으려면 추상적인 진행률 숫자가 아니라, 객관적으로 검증 가능한 지표를 주 단위로 확인하는 체계가 필요해요.

5-1. 발주자가 매주 봐야 할 핵심 지표 3가지는?

첫 번째는 기능 단위 완료율입니다. 전체 기능 100개 중 코드만 짜인 게 아니라 QA(품질 검증)까지 통과해 검수 완료된 기능이 몇 개인지로 계산하죠. "80% 완료"가 아니라 "100개 중 62개 검수 완료"처럼 셀 수 있는 단위로 받아야 합니다.

두 번째는 결함 발생률과 등급별 분포입니다. 한 주에 새로 발견된 버그가 몇 건인지, 그중 치명적 등급(서비스가 멈추는 수준)이 몇 건인지 봐야 해요. 후반부로 갈수록 결함 수는 줄고 등급은 낮아지는 게 정상인데, 반대 흐름이면 품질 리스크 신호입니다.

세 번째는 잔여 공수 대비 잔여 일정입니다. 남은 작업량을 사람·일 단위로 환산했을 때 남은 기간 안에 가능한 양인지 확인하는 거죠. 잔여 공수 200인일에 잔여 일정이 30일인데 투입 인력이 5명이면 단순 계산으로도 빠듯합니다.

5-2. 리스크가 보일 때 발주자가 취해야 할 조치는?

지표가 경보 기준을 넘기 시작하면, 그 주 정례 보고에서 이슈 로그(주간 발생한 문제 목록)를 반드시 받아야 합니다. 어떤 기능에서, 어떤 원인으로, 며칠짜리 영향인지가 한 줄씩 정리돼 있어야 하죠. "이슈 있음" 정도의 보고는 의사결정에 쓸 수 없어요.

이슈 영향 범위가 확인되면, 발주자가 직접 일정·범위·리소스 세 가지 중 무엇을 조정할지 결정해야 합니다. 도급사에 일임하면 보통 "야근으로 메우겠다"는 답이 돌아오는데, 이건 결함률을 더 끌어올리는 선택지죠. 출시일을 늦출지, 기능 일부를 다음 단계로 미룰지, 인력을 추가 투입할지는 사업 측면 판단이라 발주자 몫입니다.

조기 경보가 작동하면 일정 슬립을 2주 이상 앞당겨 감지할 수 있어요. 막판에 터지는 것보다 중반에 범위를 조정하는 게 비용·품질 모두에서 훨씬 유리합니다. 투명한 프로젝트 가시성을 확보하는 것이 SI 도급 계약 후 프로세스에서 가장 중요한 발주자의 역할이에요.

6. 납품·검수·유지보수 단계는 어떻게 마무리해야 할까?

납품 단계에서는 최종 산출물 목록·소스코드·운영 매뉴얼·UAT 결과서를 받아 최종 검수서에 서명합니다. 이후 하자보수 기간(통상 3~12개월) 동안의 결함 대응 범위와 유지보수 계약 조건을 미리 정해두는 것이 중요해요.

도급 개발 프로세스의 마지막 단계는 단순히 "결과물을 받았다"로 끝나지 않습니다. 무엇을, 어떤 형태로, 누구에게 넘기는지가 명확하지 않으면 검수 이후에도 문제가 반복적으로 발생하죠. 특히 소스코드와 운영 매뉴얼이 누락된 채 검수서에 도장을 찍으면, 이후 다른 업체로 이관할 때 비용이 두 배 이상 늘어나는 경우가 많습니다.

6-1. 납품 시 반드시 받아야 할 최종 산출물 리스트는?

최종 납품 시 받아야 할 산출물은 코드·문서·테스트 결과 3개 카테고리로 나뉩니다. 하나라도 빠지면 운영 단계에서 같은 비용을 다시 지불해야 할 수 있어요.

발주자가 검수서에 서명하기 전, 아래 8가지 산출물이 모두 인수인계됐는지 확인해야 합니다.

특히 소스코드 이관은 단순히 zip 파일을 받는 것으로 끝내선 안 됩니다. GitHub·GitLab 저장소의 소유권 자체를 발주자 계정으로 이전받아야, 이후 다른 업체가 코드 히스토리를 그대로 활용할 수 있어요. zip 파일만 받으면 커밋 이력이 사라져 누가 어떤 의도로 어떤 코드를 짰는지 추적이 불가능해집니다.

6-2. 검수 완료 후, 하자보수와 유지보수는 어떻게 구분하나?

하자보수는 납품된 기능의 결함을 무상으로 수정하는 것이고, 유지보수는 신규 기능 추가나 운영 지원을 별도 비용으로 받는 계약입니다. 두 범위가 계약서에 명확히 분리되어 있지 않으면 분쟁이 반복적으로 발생해요.

도급 개발 계약서에 하자보수 기간(통상 3~12개월)을 명시하더라도, "어디까지가 하자인가"에 대한 기준이 없으면 실무에서 매번 다툼이 생깁니다. 아래 표 기준으로 계약서 단계에서 미리 합의해두는 것이 안전합니다.

7. 그릿지는 도급 개발 프로세스를 어떻게 관리할까?

그릿지는 올인원 개발로 요구사항부터 납품까지 단일 책임 구조로 운영하고, 커뮤니케이션 시트를 통해 단계별 산출물·공수·이슈를 실시간 추적합니다. 발주자는 대시보드에서 진척률·잔여 공수·CR(Change Request, 변경 요청) 이력을 직접 확인할 수 있어요.

일반적인 도급 개발에서 발주자가 답답함을 느끼는 지점은 비슷합니다. 주간 보고서만으로는 실제 진척이 어느 정도인지 알기 어렵고, 코드 품질은 납품 시점에야 확인할 수 있죠. 그릿지는 이 두 가지 공백을 메우는 방향으로 도급 개발 프로세스를 설계했습니다.

7-1. 올인원 개발은 일반 도급과 무엇이 다른가?

올인원 개발은 AI를 활용해 개발 속도를 끌어올리되, 테크리더가 코드 변경 제안서를 한 건씩 검수하는 구조입니다. 품질 게이트가 개발사 내부에 한 번 더 있다는 뜻이에요.

발주자 입장에서 가장 큰 차이는 인수 이후입니다. 일반 도급은 납품받고 나서 다른 개발팀에 유지보수를 맡길 때 코드 구조를 다시 뜯어봐야 하는 경우가 흔한데요. 올인원 개발은 테크리더가 사전에 코드 컨벤션과 구조를 잡아두기 때문에, 인수 직후에도 추가 개발과 버그 수정이 가능한 상태로 받습니다.

7-2. 범위가 자주 바뀌는 프로젝트라면 어떻게 풀어가나?

요구사항이 자주 흔들리는 프로젝트는 오로지 도급 개발만 진행하는 계약사보다 유연한 요금 조절이 가능한 개발사에서 진행하는 것이 좋습니다. 도급은 범위·일정·금액이 계약 시점에 고정되기 때문에, 변경이 잦으면 CR 절차와 비용 재산정이 반복돼 오히려 더 느려져요.

그릿지에서는 개발 프로젝트에 따라 다음 달에 우선순위가 달라지면 백로그(개발 대기 항목 목록)를 다시 정렬하고, 인력 구성도 프로젝트 진행 상황에 맞춰 조정해드리고 있어요. 초기 PoC(Proof of Concept, 기술 검증용 시제품) 단계나 신규 서비스 런칭 직후처럼 시장 반응에 따라 방향을 바꿔야 하는 시기에도 적합합니다.

일반 도급 개발사와 개발 방식 차이는 아래 표로 정리했습니다.

계약 이후가 진짜 시작입니다

도급 개발은 계약서에 도장을 찍는 순간이 끝이 아니라 출발선입니다. 요구사항 정의부터 분석·설계, 개발, QA, 납품, 유지보수까지 6단계를 발주자가 직접 따라가며 산출물과 변경 관리를 챙겨야 일정·비용 분쟁 없이 프로젝트를 마칠 수 있어요.

특히 단계별 가시성, 즉 지금 어디까지 진행됐고 무엇이 막혀 있는지 실시간으로 확인할 수 있는 구조가 핵심입니다. 잔여 공수와 결함 발생률, 일정 슬립 같은 지표를 주 단위로 확인하지 못하면 납기 직전에 문제를 발견하게 되죠.

그릿지는 300개 이상의 도급 개발 프로젝트를 운영하면서, 요구사항부터 납품까지 단일 책임 구조로 진행하고 커뮤니케이션 시트를 통해 진척·공수·이슈를 투명하게 공개해왔습니다. 이처럼 발주자와 개발사가 같은 화면에서 같은 데이터를 보는 것이 도급 개발 프로세스의 분쟁을 줄이는 가장 확실한 방법이에요.

개발사를 찾는 기준을 세우는데 어려움을 겪고계시다면, 그릿지의 무료 상담에서 요구사항 정의부터 납품 검수까지 개발 프로젝트를 어떻게 운영해야 할지부터 함께 점검해드립니다.

자주 묻는 질문

Q1. 도급 개발에서 요구사항 정의서는 발주자가 직접 작성해야 하나요, 도급사가 작성해주나요?

도급 개발에서 요구사항 정의서는 발주자가 초안을 작성하고 도급사가 기술 관점에서 보완하는 방식이 일반적입니다. 비즈니스 목적과 우선순위는 발주자만 정의할 수 있기 때문인데요. 도급사가 처음부터 단독 작성하면 의도 왜곡과 잦은 변경으로 일정·비용 리스크가 커집니다.

Q2. 킥오프 미팅은 보통 어느 정도 시간을 잡고, 어떤 직책이 참여해야 하나요?

킥오프 미팅은 보통 2시간 내외로 잡고, 발주사 측 의사결정권자·PM·실무 담당자, 도급사 측 PM·테크리더·디자이너가 함께 참여해야 합니다. 일정·범위·커뮤니케이션 규칙을 한 번에 합의해야 하기 때문이죠. 기술 리더가 빠지면 나중에 설계 단계에서 재합의가 필요해집니다.

Q3. 단계별 산출물을 검수할 때 며칠 안에 확정해야 일정에 지장이 없나요?

단계별 산출물은 일반적으로 영업일 기준 3~5일 안에 검수를 확정하는 것이 안전합니다. 검수가 지연되면 다음 단계 일정이 그대로 밀려 전체 납기에 영향을 주기 때문인데요. 계약 시점에 검수 SLA를 명문화하고, 지연 시 책임 소재를 사전에 합의해두는 것이 좋습니다.

Q4. 주간 보고에서 '진행률 80%'라는 말은 어디까지 신뢰해도 되나요?

주간 보고의 진행률 수치는 산정 기준이 명시되지 않으면 신뢰하기 어렵습니다. 완료 기능 수, 잔여 공수, 결함 발생률 같은 정량 지표가 함께 제시될 때만 의미가 있는데요. 가능하면 옵저버 도구로 커밋·이슈·잔여 작업을 실시간 확인하는 구조를 마련하는 것이 안전합니다.

Q5. 요구사항 변경 시 추가 비용은 보통 어떤 기준으로 산정되나요?

요구사항 변경 비용은 추가 공수(맨먼스)에 표준 단가를 곱해 산정하는 것이 일반적입니다. 변경된 화면 수, 신규 API, 영향받는 모듈을 기준으로 도급사가 견적을 내고 발주자가 승인하는 절차를 거치죠. 변경 합의서를 별도 문서로 남겨야 추후 분쟁을 막을 수 있습니다.

Q6. 도급 개발 완료 후 소스코드는 누구 소유가 되며, 어떻게 인수받아야 하나요?

도급 개발 소스코드의 저작권은 계약서에 명시한 대로 귀속됩니다. 별도 조항이 없으면 도급사에 귀속되므로, 발주자가 권리를 가지려면 양도 조항을 반드시 넣어야 하는데요. 인수 시에는 깃 저장소·빌드 스크립트·환경 변수·배포 매뉴얼까지 일괄 인계받아야 안전합니다.