계약 조건과 관리의 연결
T&M이면 투입 공수와 단가 산정 기준을, 고정가면 변경 요청 정산 방식을 관리 프로세스에 반영합니다. 검수 기준과 산출물 목록은 계약서와 관리 문서가 일치해야 합니다. 지식재산권 귀속과 NDA도 관리 대상에 포함됩니다. 비용과 계약 페이지에서 이 조항들을 더 자세히 확인하실 수 있습니다.
서울 강남 · 위시켓 디지털 외주 운영 가이드
외주 프로젝트 관리, 무엇을 기준으로 볼까
외주 프로젝트가 어긋나는 이유는 대부분 소통 부족과 일정 관리 실패입니다. 개발이 잘 되고 있는지 확인할 방법이 없으면 문제는 마감 직전에 드러납니다. 이 페이지에서는 PM/PL 체계, 일정과 산출물 관리, QA, SLA 기준으로 프로젝트를 어떻게 운영하는지 설명합니다.
먼저 정할 것
관리 부담은 착수 시점에 정해집니다
외주 개발에서 문제가 커지는 흐름은 대체로 비슷합니다. 요구사항이 말로만 오가고, 진행 상황을 확인할 창구가 없고, 검수 기준이 마지막에 정해집니다. 이 세 가지를 착수 시점에 문서로 남기면 개발 도중에 생기는 대부분의 이견을 줄일 수 있습니다.
이 페이지는 위시켓 디지털에서 IT 외주 프로젝트를 운영할 때 적용하는 기준을 역할, 일정, 산출물, QA, SLA 순서로 정리합니다. 각 항목은 프로젝트 규모와 계약 형태에 따라 조정되며, 조정한 내용도 같은 문서에 남기는 것을 원칙으로 합니다.
아직 프로젝트 등록 전이라면, 먼저 매칭 방식과 비용·계약 조건을 함께 확인하시면 판단이 빨라집니다.
PM과 PL은 무엇이 다른가
PM은 일정, 예산, 범위를 관리하고, PL은 기술 구현과 산출물 품질을 책임집니다. 규모가 작은 프로젝트는 한 사람이 겸할 수 있지만, 역할이 늘어나면 분리하는 편이 안전합니다.
PM · 범위 관리
일정, 예산, 범위를 관리합니다. 요구사항이 바뀔 때 무엇을 조정할지 결정하고, 기업 담당자와 소통 창구를 유지합니다.
PL · 구현 품질
기술 구현과 산출물 품질을 책임집니다. 아키텍처 판단, 코드 리뷰, 배포 결과물의 완성도를 관리합니다.
분리 시점 판단
기능 수와 이해관계자가 늘면 한 사람이 겸하기 어려워집니다. 이때 역할을 나누고 결정 범위를 문서로 정합니다.
담당자와 소통 창구를 명확히 정하면 달라지는 것
역할이 적혀 있지 않으면 같은 질문이 여러 사람에게 흩어지고, 답이 늦어지는 동안 개발은 멈춥니다. 이슈가 생겼을 때 어디에 남기고 누가 결정하는지 정해 두면 대응이 빨라집니다. 프로젝트 초기에 이 구조를 정하는지가 이후 관리 부담을 좌우합니다. 역할이 나뉘어 있어도 결정 기록이 남지 않으면 같은 논의를 되풀이하게 되므로, 회의가 아니라 기록으로 남기는 방식을 함께 정합니다.
일정 관리 기준
주 단위로 계획과 실적을 비교하고, 지연이 생기면 원인과 대응을 문서로 남깁니다. 마일스톤은 기능 단위가 아니라 검수 가능한 산출물 단위로 잡습니다. 이 기준이 있으면 진행률을 숫자가 아니라 산출물로 확인할 수 있습니다.
일정이 밀릴 때는 범위를 조정할지 기간을 늘릴지 미리 합의해 둡니다. 두 선택지 중 무엇을 쓸지는 프로젝트 단계마다 달라질 수 있으므로, 판단 기준을 계약 조건과 함께 정리해 두는 편이 안전합니다.
주 단위
계획과 실적 비교
이번 주에 무엇을 끝내기로 했고 실제로 무엇이 나왔는지 한 줄씩 남깁니다.
마일스톤
산출물 단위 설정
기능이 아니라 검수할 수 있는 결과물을 기준으로 잡아야 완료 여부가 분명해집니다.
지연 발생 시
범위와 기간 중 선택
지연 원인과 대응을 기록하고, 범위 조정인지 기간 연장인지 미리 합의한 기준으로 결정합니다.
산출물 관리
무엇을 받아야 끝난 것인지 미리 정합니다
소스 코드, 디자인 원본, 기획 문서, 배포 결과물은 프로젝트 종료 시 인수인계 대상입니다. 진행 중에도 정기적으로 공유해 기업이 상태를 파악할 수 있게 합니다. 버전 관리와 산출물 목록을 문서로 남기면 이후 유지보수가 수월해집니다. 종료 후 인수인계 기준을 계약서에 명시하는 경우도 많습니다.
코드
형상관리 저장소와 배포 이력
브랜치 전략, 커밋 기준, 배포된 빌드의 버전을 함께 넘겨야 이후 수정이 가능합니다.
디자인
원본 파일과 컴포넌트 정의
화면 캡처가 아니라 편집 가능한 원본과 상태별 정의가 있어야 유지보수가 이어집니다.
문서
기획서와 결정 기록
요구사항 변경과 그때의 판단을 남겨 두면 인수인계 후 재논의를 줄일 수 있습니다.
운영
배포 결과물과 계정 정보
서버, 도메인, 외부 연동 계정의 소유권과 접근 권한을 정리해 함께 인계합니다.
QA를 언제 돌려야 하나
QA는 개발 완료 후가 아니라 화면 단위로 나올 때마다 돌리는 편이 수정 비용을 낮춥니다. 기능 테스트, 예외 상황 테스트, 사용자 시나리오 테스트를 구분해 진행합니다. 발견된 이슈는 심각도와 우선순위를 표시해 관리합니다. 테스트 결과를 기록으로 남기면 최종 검수 기준이 됩니다.
마지막에 한 번 몰아서 확인하면 문제가 겹쳐 있어 원인을 찾기 어렵습니다. 화면과 기능이 하나씩 완성될 때마다 확인하고, 남은 이슈 목록을 계속 갱신해 두면 마감 시점에 예상하지 못한 항목이 줄어듭니다.
화면 단위 산출물이 나올 때마다 확인하고, 발견된 이슈는 심각도와 우선순위를 함께 기록합니다.
SLA와 운영 범위
SLA는 운영 단계까지 포함할 때 필요합니다. 장애 대응 시간, 복구 목표, 지원 시간대를 문서로 정합니다.
장애 대응 시간
신고를 받은 시점부터 확인, 복구까지의 목표 시간을 나누어 정합니다. 심각도에 따라 기준을 달리 두면 우선순위가 분명해집니다.
복구 목표와 지원 시간대
어느 시간대에 대응하고, 계획된 점검은 어떻게 공지할지 정합니다. 운영 범위에 모니터링, 백업, 보안 업데이트가 포함되는지도 함께 확인합니다.
ITSM 기준으로 보는 운영
ITSM 체계로 운영을 관리하는 경우에는 기획, 설계, 개발, 운영을 포괄하는 관리 기준을 함께 봅니다. 단계마다 담당과 기록 위치를 맞춰 둡니다.
운영 계약을 염두에 두고 있다면, 비용과 계약 페이지에서 검수 기준과 산출물 목록을 계약서에 어떻게 반영하는지 함께 확인하시면 판단에 도움이 됩니다.
리스크를 줄이는 소통 방식
주간 미팅, 이슈 트래커, 산출물 공유 주기를 정합니다. 결정이 필요한 사항은 회의가 아니라 기록으로 남깁니다. 담당자 한 명이 모든 결정을 독점하면 병목이 생기므로, 의사결정 범위를 정해 둡니다. 소통 주기가 명확하면 문제가 커지기 전에 발견할 수 있습니다.
정기 공유가 있으면 기업 담당자는 진행 상황을 확인하기 위해 별도로 요청할 필요가 줄어듭니다. 이슈를 어디에 남기고 누가 답하는지 정해 두면, 같은 문제를 여러 경로에서 다시 설명하는 일도 줄어듭니다.
주간
계획과 실적을 비교하는 정기 미팅
상시
이슈 트래커에 남기고 담당자를 지정
산출물
공유 주기와 버전을 문서로 기록
종료와 인수인계
프로젝트 종료 시 소스 코드, 문서, 계정 정보를 정리해 인계합니다. 유지보수 계약이 이어지면 담당자와 대응 절차를 다시 확인합니다. QA 결과와 이슈 이력을 함께 넘기면 이후 운영에서 참고 자료가 됩니다. 인수인계 목록은 착수 시점에 미리 정해 두는 편이 안전합니다.
질문
자주 받는 관리 관련 질문
프로젝트 등록 전에 자주 확인하시는 항목을 정리했습니다. 상황에 따라 조정되는 부분은 계약 조건과 함께 다시 확인하시는 편이 정확합니다.
평일 09:00 - 18:00 (주말 및 공휴일 휴무) · [email protected]
PM이 꼭 필요한가요?
규모가 작으면 PL이 겸할 수 있지만, 역할이 늘어나면 분리하는 편이 일정과 품질 관리에 유리합니다. 판단 기준이 애매하면 담당자 수와 이해관계자 수를 먼저 세어 보는 편이 좋습니다.
QA는 언제 시작해야 하나요?
개발 완료 후가 아니라 화면 단위 산출물이 나올 때마다 돌리는 편이 수정 비용을 낮춥니다. 기능, 예외 상황, 사용자 시나리오를 구분해 확인하고 결과를 기록해 두면 최종 검수 기준이 됩니다.
SLA는 어떤 경우에 필요한가요?
운영 단계까지 계약에 포함할 때 필요하며, 장애 대응 시간과 복구 목표를 문서로 정합니다. 지원 시간대와 계획된 점검 공지 방식도 함께 정해 두면 운영 중 혼선이 줄어듭니다.