IT 개발이나 SI 프로젝트를 발주하는 실무 책임자는 여러 업체로부터 견적을 받아보지만, 총액 외에 중요한 항목들이 모호하게 기술되어 있어 업체를 선택하기 어렵습니다. '앱 개발', '플랫폼 구축'이라는 동일한 이름의 서비스라도 실제 개발 범위, 테스트 포함 여부, 완료 후 지원 범위가 천차만별이기 때문입니다.

이러한 불확실성은 프로젝트 지연, 예산 초과, 결과물 품질 저하 등 심각한 문제로 이어질 수 있습니다. 따라서 단순히 가격을 비교하는 것을 넘어, 프로젝트의 성공을 좌우하는 핵심 요소들을 체계적으로 확인하고 비교할 수 있는 명확한 기준이 필요합니다.

적용 순서

성공적인 IT 프로젝트를 위해 개발사나 SI 업체에 다음 4가지 항목에 대한 구체적인 설명과 자료를 요청하고, 계약서에 명시해야 합니다.

1. 개발 범위(Scope) 명확화

단순 기능 목록을 넘어, 프로젝트의 경계를 명확히 정의해야 합니다. '스코프 크립(Scope Creep)'이라 불리는 범위 확장을 막는 가장 중요한 단계입니다.

* 상세 요구사항: 단순 기능 목록(e.g., '로그인 기능') 대신, 사용자 유형별 권한, 데이터 처리 규칙, 예외 상황 처리 방안 등 상세한 시나리오를 포함한 요구사항 명세서를 확인합니다. * 책임 주체: 요구사항 정의와 상세 기획(화면 설계 등)을 누가 주도하는지 명확히 합니다. (고객사 vs. 개발사) * 변경 관리: 프로젝트 진행 중 요구사항 변경이 발생했을 때, 이를 요청하고 승인하며, 추가 비용과 일정을 산정하는 공식적인 절차(Change Request)가 있는지 확인합니다.

2. 검수 기준(Acceptance Criteria) 구체화

프로젝트의 '완료'를 객관적으로 판단할 수 있는 기준을 사전에 합의해야 합니다.

* 인수 기준 정의: '오픈', '완료' 같은 모호한 표현 대신, '어떤 기능이 어떤 조건 하에 정상 동작해야 하는가'를 정의한 구체적인 인수 기준(Acceptance Criteria)을 마련합니다. * 테스트 계획: 제안요청서(RFP)의 요구사항을 기반으로 작성된 '테스트 시나리오'나 '검수 체크리스트'에 따라 체계적인 검수가 진행되는지 확인합니다. * 무상 유지보수: 검수 완료 후 발견되는 결함(버그)에 대한 무상 수정 기간과 범위를 명확히 규정합니다.

3. 보안 요구사항(Security) 확인

서비스의 안정성과 신뢰도를 위해 보안은 프로젝트 초기부터 고려되어야 합니다.

* 보안 대책: 개인정보보호법 등 관련 법규 준수, 데이터 암호화, 사용자 인증 및 접근 제어 방안을 확인합니다. * 취약점 점검: 개발 과정에서 시큐어 코딩을 적용하는지, 서비스 오픈 전 외부 기관이나 도구를 통해 모의 해킹 또는 취약점 점검을 수행하는지 계획을 확인합니다. * 책임 소재: 보안 사고 발생 시의 대응 절차와 책임 소재를 명확히 합니다.

4. 인수인계(Handover) 및 소유권 정의

프로젝트 종료 후 고객사가 시스템을 안정적으로 운영하고 고도화할 수 있도록 보장하는 절차입니다.

* 산출물 목록: 소스코드 원본, 데이터베이스 설계서, API 명세서, 시스템 아키텍처 구성도, 서버 계정 정보 등 인수인계 받을 전체 산출물 목록을 사전에 합의합니다. * 소스코드 소유권: 개발된 소프트웨어의 소스코드 저작재산권(소유권)이 누구에게 귀속되는지 계약서에 반드시 명시합니다. 이는 향후 유지보수나 추가 개발의 자율성을 결정하는 핵심 조항입니다. * 팀 구조 및 인력: 프로젝트에 투입되는 핵심 인력의 역할과 투입률, 인력 교체 시 업무 인수인계 방안을 확인합니다. 특히 하도급 업체가 참여하는 경우, 관리 및 소통 방식을 명확히 해야 합니다.

이렇게까지 상세하게 정의하는 것은 너무 과하고 시간낭비 아닌가요?

아닙니다. 특히 예산과 인력이 한정된 작은 프로젝트일수록, 초기에 범위를 명확히 하지 않으면 사소한 변경 요청 하나가 프로젝트 전체를 위협하는 큰 리스크가 될 수 있습니다. 초기의 상세한 정의는 불필요한 재작업과 분쟁을 막아 오히려 시간과 비용을 절약하는 가장 확실한 방법입니다.

전문가인 개발사가 알아서 잘 해주는 것 아닌가요?

개발사는 '계약된 내용'을 기준으로 '잘' 수행합니다. 발주처가 마음속으로 기대하는 '잘'과 개발사가 계약서상으로 이해하는 '잘'은 다를 수 있습니다. 문서화된 합의는 서로의 기대를 일치시키고, 공통의 목표를 향해 나아가게 하는 유일한 방법입니다.

기술적인 내용을 잘 몰라서 요구사항을 구체적으로 만들기 어렵습니다.

모든 기술적 세부사항을 알 필요는 없습니다. 발주처는 '무엇을 원하는지(To-be)', '현재 어떤 문제를 해결하고 싶은지(As-is)' 등 비즈니스 관점의 목표를 명확히 전달하는 데 집중해야 합니다. 이를 기술 언어로 번역하고 구체적인 해결책을 제안하는 것이 바로 전문가인 개발사의 역할입니다.

계약서에 다 있는데 굳이 이런 걸 또 챙겨야 하나요?

계약서는 법적 분쟁 시를 대비한 최후의 보루입니다. 성공적인 프로젝트 완수를 위해서는 계약서의 추상적인 조항들을 실제 실행 계획과 산출물로 구체화하는 과정이 반드시 필요합니다. 이 과정은 계약 내용이 실제로 어떻게 이행될 것인지 사전에 확인하고 조율하는 중요한 소통의 기회입니다.

체크리스트

* 이 글의 체크리스트를 활용하여 개발사에게 보낼 표준 질문지를 만들어 보세요. * 관심 있는 개발사에 제안요청서(RFP)와 함께 프로젝트 범위 기술서(Scope of Work) 샘플을 요청하여 문서화 수준을 비교해 보세요.