간트차트는 프로젝트에 필요한 작업을 세로로 늘어놓고, 각 작업이 언제 시작해서 언제 끝나는지를 가로 막대로 그린 일정표예요. 막대의 길이가 그 작업에 잡아둔 기간이고, 막대와 막대를 잇는 선은 "앞이 끝나야 뒤가 시작된다"는 선후 관계를 뜻해요. 이름은 미국의 기계공학자이자 경영 컨설턴트였던 헨리 간트에게서 왔고, 지금은 여러 IT 프로젝트 관리 도구가 간트 뷰를 지원해요.
그런데 외주 발주자에게 간트차트는 툴 사용법 문제가 아니에요. 이 글이 전제하는 상황은 개발사가 일정표를 그려서 보내오고 발주자는 그것을 받아 읽는 구조예요. 그래서 진짜 문제는 "어떻게 그리나"가 아니라 "이 일정표가 지켜질 물건인가", "지금 실제로 어디까지 왔는가"를 판단하는 일이에요.
이 글은 간트차트 그리는 법이나 특정 툴 사용법을 다루지 않아요. 받은 일정표에서 무엇을 확인하고, 주간 보고에서 무엇을 요구하고, 일정이 밀리기 시작할 때 어떤 순서로 따져 물을지를 정리했어요. 다음 미팅에서 그대로 쓸 수 있는 기준으로 썼어요.
간트차트가 실제로 해주는 일은 세 가지예요. 첫째, 작업의 순서와 의존 관계를 드러내요. 로그인이 안 끝나면 마이페이지를 못 만들고, 디자인 시안이 확정돼야 화면 개발이 시작된다는 사실이 막대와 선으로 눈에 보여요.
둘째, 누구의 지연이 누구를 막는지를 보여줘요. 외주 프로젝트에서 멈추는 이유는 개발사 안에만 있지 않아요. 발주자의 콘텐츠 전달, 제3자 서비스의 심사, 결제사의 계약 승인처럼 개발사가 통제할 수 없는 줄이 일정표에 함께 그려져 있어야 책임 소재가 흐려지지 않아요.
셋째, 하나가 밀렸을 때 그 여파가 어디까지 번지는지를 계산해줘요. 이번 주 사흘 밀린 작업이 오픈일을 사흘 미루는 건지, 뒤에 여유가 있어 흡수되는 건지는 의존 관계를 그려놔야 답할 수 있어요.
반대로 간트차트가 해주지 않는 일도 분명해요. 각 작업이 실제로 며칠 걸릴지는 알려주지 않아요. 막대 길이는 누군가의 추정치이고, 도표는 그 추정치를 보기 좋게 그린 그림일 뿐이에요. 일정표가 예쁘다는 것과 일정이 지켜진다는 것은 완전히 다른 이야기예요.
개발사가 일정표를 보내오면 막대 개수부터 세지 마세요. 먼저 볼 것은 우리 쪽 작업이 그 표 안에 들어 있는가예요. 발주자가 해야 하는 일이 한 줄도 없는 일정표는 "발주자는 아무것도 안 해도 된다"는 뜻이 아니라, 발주자의 지연이 계산에서 빠져 있다는 뜻이에요.
두 번째로 볼 것은 막대 사이에 선이 그어져 있는가예요. 선이 없으면 그건 간트차트가 아니라 색칠한 달력이에요. 의존 관계가 없는 일정표는 하나가 밀렸을 때 무엇이 함께 밀리는지 답을 못 하고, 결국 "일정 다시 뽑아드릴게요"라는 말로 매주 새 그림이 오게 돼요.
세 번째는 마지막 막대가 무엇인가예요. 마지막 줄이 "개발 완료"인 일정표와 "스토어 심사 통과"인 일정표는 전혀 다른 약속이에요. 심사, 데이터 이관, 실사용자 대상 테스트, 운영 인수인계가 표 밖에 있으면 그 기간은 아무도 예산에 잡지 않은 시간이 돼요.
네 번째는 여유가 어디에 들어 있는가예요. 모든 막대가 빈틈없이 붙어 있는 일정표는 한 번도 안 밀린다는 가정 위에 서 있어요. 여유를 마지막에 몰아서 한 덩어리로 두는 방식과 구간마다 조금씩 나눠 두는 방식 중 어느 쪽인지 물어보면, 개발사가 위험을 어디에 있다고 보는지가 드러나요.
WBS는 Work Breakdown Structure, 우리말로는 작업분해구조예요. 만들려는 결과물을 더 작은 산출물 단위로 계속 쪼개서 만든 목록이에요. "쇼핑몰"을 "회원", "상품", "주문", "결제", "관리자"로 쪼개고, "주문"을 다시 "장바구니", "주문서", "주문 내역", "취소·환불"로 쪼개는 식이에요.
간트차트는 그 목록에 담당자와 날짜를 붙인 결과물이에요. 순서가 정해져 있어요. WBS가 먼저고 간트차트가 나중이에요. WBS 없이 그린 간트차트는 이름만 붙은 막대의 나열이라, 막대 하나가 무엇을 뜻하는지 발주자와 개발사가 서로 다르게 이해한 채로 몇 주가 흘러가요.
발주자가 WBS 작성법을 직접 익힐 필요는 없어요. 다만 개발사가 만든 WBS를 읽고 "이 줄이 끝났다는 걸 나는 어떻게 확인하나"를 물을 수는 있어야 해요. 이 질문에 답이 안 나오는 줄이 여러 개면, 그 줄들은 검수 단계에서 이견이 나오는 자리가 돼요. 범위를 먼저 문장으로 굳히는 방법은 MVP 범위 확정 절차와 경계 기능 판단에 절차로 정리해 뒀어요.
쪼개는 깊이에는 정답이 없지만, 멈춰도 되는 지점을 판단하는 기준은 있어요. 크기, 다툼 여지, 담당자 세 가지예요. 한 줄이 한 사람이 며칠 안에 끝낼 수 있는 크기이고, 끝났는지 아닌지를 두고 말로 다툴 여지가 없고, 담당자를 한 명으로 적을 수 있으면 그 줄은 더 쪼개지 않아도 돼요. 셋 중 하나라도 안 되면 아직 덜 쪼갠 거예요.
쪼개기를 멈춘 다음에는 그 줄이 일정표에 올라갈 준비가 됐는지를 두 가지 더 봐요. 발주자가 완료를 확인할 방법이 그 줄에 적혀 있는가, 그리고 그 줄이 무엇 뒤에 오는지 선후 관계가 적혀 있는가예요. 앞의 세 가지는 "얼마나 쪼갰나"를 보고, 뒤의 두 가지는 "이 줄을 일정으로 쓸 수 있나"를 봐요. 다섯 가지를 합치면 받은 WBS를 줄 단위로 판정하는 기준이 돼요.
반대로 지나치게 잘게 쪼개면 관리 비용이 실제 작업보다 커져요. 줄이 수백 개가 되면 매주 상태를 갱신하는 일 자체가 부담이 되고, 그러면 갱신이 밀리고, 갱신이 밀리면 일정표는 실물과 무관한 장식이 돼요. 발주자가 매주 눈으로 훑을 수 있는 분량인지가 현실적인 상한선이에요.
아래 표는 그 다섯 가지를 질문으로 바꾼 거예요. 한 줄을 놓고 다섯 개 질문에 차례로 답해 보고, 하나라도 "아니오"가 나오면 그 줄은 개발사에 다시 물어야 하는 줄이에요.
| 판정 질문 | "예"가 나오는 줄 | "아니오"가 나오는 줄 |
|---|---|---|
| 며칠 단위로 끝나는 크기인가 | 결제 실패 케이스 예외 처리 | 결제 연동 |
| 완료 여부를 다툼 없이 확인할 수 있나 | 이메일 로그인 후 홈 화면 진입까지 동작 | 로그인 개발 |
| 담당자를 한 명으로 적을 수 있나 | 주문서 화면 퍼블리싱 | 주문 기능 전반 |
| 발주자가 확인할 방법이 적혀 있나 | 테스트 계정으로 결제 1건 성공 | 결제 테스트 |
| 다른 줄과의 선후 관계가 적혀 있나 | 디자인 확정 이후 시작 | 날짜만 있고 선행 없음 |
줄 이름을 명사로만 적으면 나중에 해석이 갈리는 일이 반복적으로 관찰돼요. "알림"이라고 적힌 줄을 개발사는 앱 푸시로 이해하고 발주자는 문자와 이메일까지로 이해하는 상황이 그렇게 생겨요. 이름은 기능의 분류가 아니라 완료된 상태를 적는 자리예요.
쓸 만한 문장 틀은 단순해요. "누가 무엇을 하면 무엇이 된다"로 적는 거예요. "회원가입"이 아니라 "사용자가 이메일로 가입하면 인증 메일이 발송되고, 링크를 누르면 로그인 상태가 된다"로 적으면 그 줄이 끝났는지를 눈으로 판정할 수 있어요.
다만 기능 하나하나의 상세한 완료 기준을 일정표에서 다 정하는 건 아니에요. 그건 기능 명세서가 맡는 자리고, 여기서 할 일은 그 문장을 일정표 줄 이름으로 그대로 옮겨 쓰는 거예요. 명세서의 항목 이름, 견적서의 항목 이름, 일정표의 줄 이름이 서로 다르게 적혀 있으면 무엇에 돈을 냈고 무엇이 끝났는지 대조가 안 돼요. 견적서 항목을 뜯어보는 기준은 앱 개발 견적서 뜯어보는 법에 정리돼 있어요.
마일스톤은 기간이 아니라 시점이에요. "설계 단계"는 마일스톤이 아니고 "설계 산출물을 받아서 확인을 마친 날"이 마일스톤이에요. 발주자 입장에서 마일스톤의 조건은 하나예요. 그날 눈으로 확인할 수 있는 물건이 있어야 해요.
이 조건을 넣으면 자주 쓰이는 마일스톤 이름 여러 개가 걸러져요. "기획 완료", "설계 완료", "개발 중반 도달" 같은 이름은 확인할 물건이 없어서 그날이 왔는지 아무도 판정할 수 없어요. 반대로 "테스트 계정으로 결제 1건 성공"이나 "스토어 심사 제출"은 됐는지 안 됐는지가 그 자리에서 갈려요.
간격은 프로젝트 길이에 맞춰 잡되, 너무 뜸하면 나쁜 소식을 늦게 알게 돼요. 두세 주에 하나씩 확인 지점을 두면 문제가 생겼을 때 되돌릴 여지가 남아요. 이 글이 소유하는 것은 "그날 눈으로 확인할 물건이 있는가"라는 판정 기준 하나예요. 지연 통지 의무나 확인 기한처럼 이 시점들을 계약 조항으로 굳히는 방법은 IT 외주 개발 일정·마일스톤 관리 가이드에 항목별로 있고, 마일스톤과 대금 지급을 묶는 방식은 IT 외주 개발 마일스톤 결제 구조 설계 가이드에서 단계별로 다뤘어요.
| 마일스톤 | 그날 발주자가 받는 것 | 확인 방법 |
|---|---|---|
| 화면 확정 | 전체 화면 시안과 화면 이동 흐름 | 주요 사용자 행동 하나를 시안만으로 끝까지 따라가 보기 |
| 첫 동작 빌드 | 설치 가능한 앱 또는 접속 가능한 주소 | 내 계정으로 가입해서 첫 화면까지 들어가 보기 |
| 핵심 거래 성공 | 테스트 환경에서 성공한 주문 또는 결제 건 | 취소와 환불까지 한 번씩 눌러 보기 |
| 운영 데이터 반영 | 실제 상품과 콘텐츠가 들어간 화면 | 가짜 데이터 대신 우리 데이터로 화면이 깨지지 않는지 |
| 출시 제출 | 스토어 제출 완료 또는 서버 배포 완료 | 제출 화면 캡처와 심사 상태 확인 |
| 인수인계 | 저장소 권한, 계정 목록, 운영 문서 | 개발사 도움 없이 한 번 배포해 보기 |
주간 보고에 "전체 진행률 90퍼센트"라고 적혀 있으면 발주자는 안심하게 되지만, 이 숫자는 판단 근거로 쓰기 어려워요. 이유가 여러 겹이에요.
첫째, 진행률은 측정값이 아니라 감각이에요. 남은 일이 정확히 무엇인지 아는 사람이 없는 상태에서는 남은 비율도 알 수 없어요. 코드를 얼마나 썼는지로는 잴 수 없고, 화면 개수로 재면 화면마다 난이도가 달라서 의미가 없어요.
둘째, 진행률은 되돌아가지 않아요. 지난주 90이었던 숫자를 이번 주에 85로 내리는 보고는 하기가 어려워요. 한 번 올라간 숫자가 내려오지 않으면 나쁜 소식이 그 숫자에 실릴 방법이 없어요. 숫자가 오르기만 하는 지표는 상태를 알려주는 게 아니라 상태를 가려요.
셋째, 여러 작업의 진행률을 평균 내면 뜻이 사라져요. 90퍼센트인 줄이 아홉 개고 0퍼센트인 줄이 하나면 평균은 81퍼센트가 되지만, 실제로는 시작도 안 한 작업이 남아 있는 상태예요. 이 산술은 예시이지 조사 결과가 아니지만, 평균이 무엇을 가리는지 보여주기에는 충분해요.
넷째, 마지막 구간에 성격이 다른 일이 몰려 있어요. 서로 다른 기능을 붙이는 통합, 예외 상황 처리, 기존 데이터 이관, 스토어 심사 대응, 실제 운영 데이터로 바꿔 넣기가 여기 있어요. 이 일들은 순서상 뒤에 오는 것이지 작은 일이라서 뒤에 있는 게 아니에요.
퍼센트를 없애고 상태값으로 바꾸면 보고에서 애매한 자리가 줄어요. 상태값은 중간이 없는 것이 핵심이에요. "거의 다 됨" 같은 칸을 만들면 줄이 그 칸으로 몰려서 원래 문제로 돌아가요.
여기에 매주 세 개의 숫자를 함께 요구하세요. 이번 주에 완료로 넘어간 줄 수, 아직 남은 줄 수, 그리고 이번 주에 새로 생긴 줄 수예요. 세 번째 숫자가 특히 중요해요. 새 줄이 계속 늘어나면 그건 개발이 느린 게 아니라 범위가 자라고 있는 거예요. 범위 증가는 일정 문제가 아니라 변경 요청서(CR) 작성으로 처리해야 하는 별개의 사안이에요.
| 상태값 | 뜻 | 발주자 쪽 대응 |
|---|---|---|
| 시작 전 | 착수하지 않음 | 선행 작업이 우리 쪽 결정 대기인지 확인 |
| 진행 중 | 착수했고 완료 문장에 아직 도달하지 않음 | 2주 이상 이 칸에 머문 줄이 있는지만 확인 |
| 확인 대기 | 개발사는 끝냈고 발주자 확인이 남음 | 기한 안에 직접 눌러 보고 결과 회신 |
| 완료 | 발주자가 완료 문장대로 동작함을 확인 | 더 손대지 않기로 하고 다음 줄로 이동 |
| 보류 | 외부 요인으로 멈춤 | 무엇이 풀려야 재개되는지와 담당자를 적기 |
이 표에서 발주자가 직접 손을 움직여야 하는 칸은 "확인 대기" 하나예요. 나머지 네 칸에서 하는 일은 눈으로 확인하는 것이지 작업이 아니에요. 그래서 확인 대기 칸에 줄이 쌓이기 시작하면 프로젝트를 멈추는 쪽은 개발사가 아니라 발주자예요. 확인 대기 줄이 몇 개 이상 쌓이면 다른 회의를 미루고 그것부터 본다는 규칙을 킥오프에서 정해두면 좋아요. 이 글이 다루는 것은 "확인 대기가 쌓이면 일정이 멈춘다"는 일정 축이고, 무엇을 어떤 절차로 확인하고 어떻게 사인할지는 IT 외주 개발 산출물 검수·사인오프 완전 가이드에 절차로 정리돼 있어요.
일정이 밀렸다는 보고를 받으면 "언제까지 될까요"를 먼저 묻고 싶어지지만, 그 질문은 새로운 추정치를 한 번 더 받는 것으로 끝나는 일이 자주 있어요. 먼저 확인할 것은 밀린 줄의 위치예요. 앞쪽 줄이 밀리면 그 줄에 이어지는 뒤 작업까지 함께 밀릴 수 있고, 뒤에 이어지는 줄이 없으면 그 줄만 밀려요.
다음은 그 줄이 다른 줄의 선행인가예요. 여러 줄이 그 줄을 기다리고 있으면 하루 지연이 하루로 끝나지 않아요. 반대로 아무도 기다리지 않는 줄이면 오픈일에 영향이 없을 수도 있어요. 이 판단은 의존 관계 선이 그려져 있어야 가능하고, 그래서 앞에서 선을 확인하라고 한 거예요.
그다음이 원인 분류예요. 원인마다 조치가 완전히 달라서, 분류를 건너뛰면 잘못된 처방이 나가요. 추정이 틀린 것과 우리 쪽 회신을 기다리다 멈춘 것은 같은 지연으로 보이지만 해결 방법이 정반대예요. 원인을 카테고리로 나누고 회복 마일스톤을 다시 그리는 절차는 IT 외주 개발 일정 지연 대응 가이드에 단계로 정리돼 있어요. 이 글이 맡는 구간은 밀리기 시작할 때의 조기 감지이고, 이미 크게 밀린 뒤의 회복은 그 글이 맡아요.
| 일정표에서 먼저 보이는 신호 | 확인할 질문 | 첫 조치 |
|---|---|---|
| 같은 줄이 여러 주째 진행 중 | 이 줄을 더 작은 줄로 쪼갤 수 있나 | 쪼개서 어디까지 됐는지 눈에 보이게 만들기 |
| 완료된 줄이 다시 열림 | 완료 문장이 애매했나, 요구가 바뀐 건가 | 완료 문장 재작성 또는 변경 요청 절차로 이관 |
| 새 줄이 계속 추가됨 | 계약 범위 안인가 밖인가 | 범위 밖이면 일정과 금액을 함께 재산정 |
| 보류 줄이 늘어남 | 무엇을 기다리는가, 누구 손에 있나 | 대기 항목의 담당자와 기한을 표에 올리기 |
| 담당 개발자가 바뀜 | 인수인계에 며칠을 잡았나 | 인계 기간을 일정표에 별도 줄로 반영 |
| 마감일만 그대로고 뒤 작업이 짧아짐 | 이 일정표의 이전 버전이 어디에 있나 | 처음 합의본 일정표를 꺼내 대조본으로 지정 |
신호는 하나만 떠도 물어볼 값이 있지만, 두세 개가 같은 주에 겹치면 그건 줄 하나의 문제가 아니라 계획 자체가 실물과 어긋났다는 뜻이에요. 그때는 줄 하나를 고치지 말고 일정표 전체를 다시 놓고 보세요.
지연 보고와 함께 새 일정표가 오는데 오픈일이 그대로인 경우가 있어요. 앞이 밀렸는데 끝이 안 밀렸다면 중간의 어떤 줄이 짧아졌다는 뜻이에요. 이때 발주자가 할 일은 새 일정표를 받는 게 아니라 원래 일정표와 나란히 놓고 어떤 줄의 길이가 줄었는지 찾는 거예요.
압축 대상으로 테스트 기간과 발주자 확인 기간이 자주 지목돼요. 이 두 구간은 산출물이 눈에 안 보여서 줄여도 티가 안 나거든요. 그런데 여기가 줄어들면 사라지는 것은 개발 시간이 아니라 문제를 발견할 기회예요. 출시 전에 잡았을 문제를 이미 사용자가 쓰고 있는 상태에서 고치게 돼요.
대조할 때 볼 것은 세 가지예요. 길이가 줄어든 줄, 아예 사라진 줄, 순서가 바뀐 줄이에요. 사라진 줄은 범위에서 빠졌다는 뜻이니 그게 합의된 것인지 물어야 하고, 순서가 바뀐 줄은 선후 관계를 무시하고 병렬로 돌리기로 했다는 뜻이라 그만큼 위험을 더 안고 간다는 말이에요. 새 일정표를 받을 때 "이전 버전 대비 무엇이 바뀌었는지 표시해서 달라"고 요청하면 이 대조를 개발사가 대신 해줘요.
외주 일정이 밀리는 이유가 개발사 쪽에만 있는 것은 아니에요. 시안 확정, 콘텐츠 전달, 계정 발급, 검수 회신처럼 발주자만 할 수 있는 일이 여러 개 있고, 이것들이 늦어지면 그 뒤에 이어지는 작업이 함께 멈춰요. 문제는 이 멈춤이 일정표에 안 그려져 있으면 보이지 않는다는 점이에요.
보이지 않는 대기는 두 가지 방식으로 돌아와요. 하나는 개발사가 그동안 다른 줄을 당겨서 작업하는 거예요. 당장은 놀지 않으니 좋아 보이지만, 순서가 어긋난 채로 만들어진 부분을 나중에 다시 손대게 되는 일이 반복적으로 관찰돼요. 다른 하나는 정산 단계에서 "지연 사유는 발주자 회신 지연"이라는 주장으로 돌아오는 거예요.
그래서 발주자 작업도 일정표에 줄로 올려야 해요. 담당자 이름과 기한을 개발 작업과 똑같은 형식으로 적고, 회신 기한을 며칠로 할지 킥오프에서 미리 합의하세요. 킥오프에서 정해둘 항목 전체는 IT 외주 개발 킥오프 미팅 완전 가이드에 체크리스트로 정리돼 있어요.
| 미룬 결정 | 그동안 멈추는 것 | 나중에 돌아오는 형태 |
|---|---|---|
| 디자인 시안 확정 | 화면 개발 전체 | 확정 후 남은 기간이 짧아져 테스트가 압축됨 |
| 결제사 계약과 심사 서류 | 결제 연동과 정산 테스트 | 심사 대기가 오픈일 직전에 겹침 |
| 스토어 계정과 사업자 정보 | 빌드 제출과 심사 | 개발은 끝났는데 출시를 못 하는 기간 발생 |
| 실제 콘텐츠와 상품 데이터 | 운영 데이터 반영과 화면 검증 | 가짜 데이터로만 검수해 출시 후 화면이 깨짐 |
| 검수 결과 회신 | 다음 마일스톤 착수 | 확인 대기 줄이 쌓여 전체가 뒤로 밀림 |
| 기능 변경 여부 판단 | 해당 기능과 연결된 줄 | 개발이 진행된 뒤 바꾸면서 비용이 커짐 |
발주자 줄을 만들 때는 개발 줄과 같은 규칙을 적용하세요. 완료 문장을 적고, 담당자를 한 명 지정하고, 기한을 날짜로 박아요. "콘텐츠 준비"가 아니라 "상품 30개의 이름, 설명, 이미지를 정해진 양식으로 전달"처럼 적어야 준비가 됐는지 판정이 돼요.
회신 기한도 규칙으로 정해두면 좋아요. 예를 들어 개발사 질문에는 세 영업일 안에 회신한다고 정하고, 그 기한을 넘기면 어떻게 할지도 함께 정해요. 기본안대로 진행하고 나중에 바꾸면 변경 요청으로 처리한다는 식으로요. 기한만 정하고 넘겼을 때의 처리를 안 정하면 결국 개발사가 멈춰서 기다리게 돼요.
의사결정권자를 한 명으로 좁히는 것도 일정 문제예요. 회신할 사람이 여럿이면 서로 다른 답이 오거나 아무도 답하지 않는 상태가 생겨요. 소통 구조를 어떻게 짜는지는 IT 외주 프로젝트 커뮤니케이션 완전 가이드에서 패턴별로 다뤘어요.
갱신 주기는 주 1회 정도가 무난해요. 더 자주 하면 관리 부담이 커지고, 더 뜸하면 문제를 알아차리는 시점이 늦어져요. 다만 여기서 말하는 갱신은 회의 운영이 아니라 문서 관리예요. 중요한 것은 주기 자체보다 갱신할 때 무엇을 남기느냐예요.
첫째, 변경 사유를 한 줄로 남겨요. 사유가 없는 갱신은 기록이 아니라 덮어쓰기예요. "결제 연동 3일 지연, 사유는 결제사 심사 대기"처럼 적으면 나중에 원인별로 얼마나 밀렸는지 셀 수 있어요. 이 기록이 쌓이면 다음 프로젝트에서 어디에 여유를 둘지 판단할 근거가 생겨요.
둘째, 처음 합의한 일정표를 대조본으로 따로 보관하고 그 위에 변경본을 쌓아요. 매주 새로 그린 그림으로 덮어쓰면 무엇이 언제 왜 밀렸는지 기록이 남지 않고, 나중에 책임을 따질 때도 근거가 없어요. 파일 이름에 날짜를 붙이고 원본은 수정 권한을 잠가두는 정도면 충분해요. 원본을 두고 변경본을 쌓아가면 그 자체가 프로젝트 기록이 돼요.
툴 이름은 이 문제의 핵심이 아니에요. 발주자가 확인할 것은 네 가지예요. 우리가 매주 볼 수 있는가, 변경 이력이 남는가, 줄마다 완료 문장을 적을 수 있는가, 계약이 끝날 때 우리 쪽으로 가져올 수 있는가.
이 조건을 만족하면 전용 프로젝트 관리 도구든 스프레드시트든 상관없어요. 반대로 아무리 좋은 도구를 써도 개발사 계정 안에만 있고 발주자가 못 보면 소용이 없어요. 계약 종료 후 접근이 끊기는 도구라면 일정 기록도 함께 사라지니, 일정표와 이슈 기록을 인수인계 목록에 넣어두세요. 넘겨받아야 할 자산 전체 목록은 IT 외주 개발 인수인계 완전 가이드에 정리돼 있어요.
도구를 고르기 전에 정할 것이 하나 더 있어요. 우리 쪽 계정을 언제 받느냐예요. 프로젝트 중반에 계정을 받으면 그전 몇 주의 기록은 개발사가 정리해서 보여주는 요약으로만 남아요. 킥오프 주에 계정을 받아 첫 일정표부터 우리 눈으로 보면, 프로젝트 초반 기록까지 우리 손에 남아요.
AI 기능은 같은 입력에도 결과가 달라져서 인수 기준을 따로 잡아야 해요. 그 기준을 어떤 문장으로 쓰는지는 MVP 뜻과 개발 방법의 AI MVP 절에 정리돼 있고, 여기서는 그것이 일정표를 어떻게 바꾸는지만 봐요.
달라지는 것은 일정표에 줄이 한 종류 더 붙는다는 점이에요. 실제 사용 사례를 모아 표본을 만들고, 사람이 채점하고, 결과를 보고 다시 조정하는 품질 확인 회차가 개발 뒤에 이어져요. 이 회차를 줄로 올리지 않으면 개발은 끝났는데 쓸 수 있는 상태가 아닌 구간이 생기고, 그 구간은 아무도 예산에 잡지 않은 시간이 돼요.
그리고 그 줄의 담당자는 개발사가 아니라 발주자로 잡히는 경우가 많아요. 무엇이 좋은 답인지는 그 업을 아는 쪽이 판단하니까요. 채점 회차를 발주자 줄로 올리고, 표본 몇 건을 며칠 안에 채점할지까지 적어두세요. 앞에서 본 발주자 줄 규칙이 여기에도 그대로 적용돼요.
맡길 팀을 고를 때 기준은 이렇게 갈려요. 앱이나 웹 서비스를 만들면서 그 안에 AI 기능이 하나 들어가는 경우라면 프로덕트 개발 경험이 있는 팀이 맞고, 포텐랩이 이 영역을 맡아요. 반대로 챗봇, RAG 검색, 에이전트처럼 AI 자체가 제품인 경우라면 트리숲(TreeSoop)이 맡는 영역이에요. 맞지 않는 쪽에 맡기면 일정 산정부터 어긋나서 서로 손해예요.
참고로 포텐랩은 약속한 범위를 기한 안에 완수한 비율인 수행완수율 97퍼센트를 자체 관리 지표로 삼고 있어요. 이건 포텐랩 내부 실적이고 업계 평균이나 공표 통계가 아니에요.
지금까지의 내용을 미팅에서 바로 쓸 수 있는 질문으로 줄이면 아래 표가 돼요. 순서대로 물어보면 일정표의 상태를 한 번에 파악할 수 있어요. 오른쪽 칸은 답이 흐릿하게 돌아왔을 때 그것이 무엇을 뜻하는지예요.
| 미팅에서 던질 질문 | 답이 흐릿하면 뜻하는 것 |
|---|---|
| 이 일정표에서 우리 쪽이 해야 할 줄은 어떤 것이고, 담당자와 기한은 무엇인가요 | 발주자 지연이 계산에서 빠져 있고, 정산 때 지연 사유로 돌아올 수 있다 |
| 막대 사이에 선이 없는 줄은 무엇이 끝나야 시작되나요 | 의존 관계가 없어서 하나가 밀렸을 때 여파를 계산할 수 없다 |
| 마지막 줄이 개발 완료인가요, 실제 출시인가요 | 심사와 이관, 인수인계 기간이 표 밖에 있고 예산에도 없다 |
| 여유 기간은 어디에 얼마나 잡혀 있나요 | 한 번도 안 밀린다는 가정 위에 서 있는 일정표다 |
| 완료 판정을 우리가 직접 확인할 수 있는 줄은 몇 개인가요 | 검수 기준이 아직 문장으로 굳지 않았다 |
| 이번 주에 새로 생긴 줄이 있나요, 계약 범위 안인가요 | 개발이 느린 게 아니라 범위가 자라고 있다 |
| 확인 대기로 우리 쪽에 넘어와 있는 줄은 무엇인가요 | 프로젝트를 멈추는 쪽이 발주자가 되고 있다 |
| 2주 넘게 진행 중인 줄이 있나요, 왜 그런가요 | 그 줄이 덜 쪼개졌거나 막힌 사실을 아직 말하지 않고 있다 |
| 지난주 대비 짧아진 줄이 있나요 | 마감일을 맞추려고 테스트나 확인 기간을 압축했다 |
| 일정표와 이슈 기록은 계약 종료 시 어떤 형태로 넘겨받나요 | 계약이 끝나면 프로젝트 기록이 함께 사라진다 |
이 질문들의 공통점은 답이 숫자 하나로 나오지 않는다는 거예요. 진행률 하나로 요약되던 대화를 줄 단위 상태로 바꾸는 것이 발주자가 일정에 개입하는 실질적인 방법이에요. 일정표는 개발사가 그리지만, 그 표에 무엇이 적혀 있어야 하는지는 발주자가 요구해야 해요.
간트차트는 프로젝트 작업을 세로로 늘어놓고 각 작업의 시작일과 종료일을 가로 막대로 그린 일정표예요. 외주에서 하는 일은 세 가지인데, 작업의 선후 관계를 드러내고, 누구의 지연이 누구를 막는지 보여주고, 하나가 밀렸을 때 여파가 어디까지 번지는지 계산해줘요. 다만 각 작업이 실제로 며칠 걸릴지는 알려주지 않아요. 막대 길이는 누군가의 추정치일 뿐이라 일정표가 정교하다는 것과 일정이 지켜진다는 것은 다른 이야기예요.
먼저 세 가지를 봐요. 한 줄이 한 사람이 며칠 안에 끝낼 수 있는 크기이고, 끝났는지 아닌지를 두고 다툴 여지가 없고, 담당자를 한 명으로 적을 수 있으면 더 쪼개지 않아도 돼요. 여기에 발주자가 완료를 확인할 방법이 적혀 있는지, 그 줄이 무엇 뒤에 오는지 선후 관계가 적혀 있는지 두 가지를 더 보면 다섯 가지 판정 기준이 되고, 하나라도 아니오가 나오면 개발사에 다시 물어야 하는 줄이에요. 반대로 줄이 수백 개가 되면 갱신 자체가 부담이 되니, 발주자가 매주 눈으로 훑을 수 있는 분량인지가 현실적인 상한선이에요.
진행률은 측정값이 아니라 감각이라 판단 근거로 쓰기 어려워요. 한 번 올라간 숫자는 내려오지 않아서 나쁜 소식이 실릴 자리가 없고, 여러 작업의 평균을 내면 시작도 안 한 작업이 가려져요. 퍼센트 대신 시작 전, 진행 중, 확인 대기, 완료, 보류 같은 상태값으로 보고를 바꾸고, 이번 주에 완료된 줄 수와 남은 줄 수, 새로 생긴 줄 수를 함께 요구하세요.
마일스톤은 기간이 아니라 시점이고, 조건은 하나예요. 그날 발주자가 눈으로 확인할 수 있는 물건이 있어야 해요. 이 기준을 적용하면 기획 완료나 설계 완료 같은 이름은 확인할 물건이 없어서 걸러지고, 테스트 계정으로 결제 1건 성공이나 스토어 심사 제출처럼 그 자리에서 판정되는 이름이 남아요. 간격은 두세 주에 하나씩 두면 문제가 생겼을 때 되돌릴 여지가 남아요.
시안 확정, 콘텐츠 전달, 계정 발급, 검수 회신은 발주자만 할 수 있는 일이라 늦어지면 그 뒤에 이어지는 작업이 함께 멈춰요. 이 대기가 일정표에 그려져 있지 않으면 보이지 않는데, 개발사가 다른 줄을 당겨서 작업하다 순서가 어긋나거나 정산 단계에서 발주자 회신 지연이 지연 사유로 돌아와요. 그래서 발주자 작업도 담당자와 기한을 붙여 일정표에 줄로 올리고, 회신 기한과 기한을 넘겼을 때의 처리 방법을 킥오프에서 합의해야 해요.
언제까지 되냐고 묻기 전에 밀린 줄의 위치를 보세요. 앞쪽 줄이 밀리면 그 줄에 이어지는 뒤 작업까지 함께 밀릴 수 있고, 뒤에 이어지는 줄이 없으면 그 줄만 밀려요. 그다음은 원인 분류인데, 추정 실패와 우리 쪽 회신 대기는 같은 지연처럼 보여도 해결 방법이 정반대예요. 마감일이 그대로인 새 일정표가 왔다면 원래 일정표와 나란히 놓고 길이가 줄어든 줄, 사라진 줄, 순서가 바뀐 줄을 확인하세요.