SI 개발 쉽게 이해하기: 턴키 계약 뜻부터 맨먼스 계산까지

1. 턴키 계약이란?

턴키(Turn-key)라는 단어는 원래 ‘열쇠만 돌리면 바로 사용할 수 있는 상태’를 의미합니다. 호텔 객실처럼 이미 모든 준비가 끝난 공간을 넘겨받아 즉시 사용할 수 있는 상황을 말하죠. 

이 사전적 의미가 SI 개발 계약으로 들어오면서 ‘턴키 계약(turn-key contract)’이라는 방식이 생겼습니다. 개발 업계에서는 처음에 정한 스펙과 범위 안에서 완성된 결과물을 납품받는 계약 구조를 뜻합니다. 

이 개념이 SI 개발 계약에서는 다음처럼 적용돼요.

• 어떤 기능을 만들지
• 어떤 화면과 구조로 개발할지
• 언제까지 납품할지
• 얼마에 개발할지

턴키 계약은 네 가지가 사전 정의된 상태에서, 개발사가 그 범위 안의 모든 결과물을 완성해 제공하는 방식이에요. 간단히 말해, 계약서에 적힌 그대로 완성된 웹이나 앱을 인수하는 구조라고 이해하시면 됩니다.

1.1 턴키 계약의 기본 흐름

턴키 방식은 보통 이러한 과정으로 진행됩니다.

• 요구사항 정의서 작성
• 기능 목록, 화면 정의, 설계 확정
• 전체 견적 및 일정 확정
• 마일스톤별 중간 점검
• 최종 납품 및 검수

이 구조에서 가장 중요한 요소는 프로젝트 범위입니다. 범위와 스펙이 명확해야 예산과 일정도 고정할 수 있기 때문이죠.

1.2 어떤 프로젝트에 턴키가 적합할까

다음과 같은 상황에서는 턴키 계약이 가장 효율적이에요.

• 기획과 설계가 충분히 준비된 신규 구축
• 화면 구조와 기능 정의가 명확한 경우
• 중간 요구사항 변경이 많지 않은 프로젝트
• 예산을 고정해야 하는 공공사업·대기업 프로젝트
• 서비스 오픈 일정이 확정되어 있어 지연이 어려운 상황

이런 프로젝트는 범위가 분명하기 때문에 턴키 방식으로 진행했을 때 예산과 일정 관리가 안정적으로 흘러갑니다.

1.3 턴키 계약에서 자주 발생하는 오해

턴키 계약이 실패하는 경우 대부분은 계약 방식 때문이라기보다, 스펙 정의가 충분하지 않은 상태에서 계약을 시작했기 때문이에요.

실제로 자주 겪는 문제는 다음과 같습니다.

• 화면 설계는 있지만 기능 정의가 부족해서 개발사가 임의로 해석하게 되는 경우
• 고객이 생각한 ‘간단한 수정’이 실제로는 기능 추가에 가까운 경우
• 변경 요청 처리 기준이 없어 일정이 계속 늘어나게 되는 상황
• 요구사항이 중간에 바뀌는데 처리 프로세스가 정의돼 있지 않은 경우

턴키 계약은 범위가 명확할수록 성공 확률이 높아지는 구조입니다. 결국 스펙 정의와 변경 관리 기준이 턴키의 핵심이에요.

2. 맨먼스 계약이란?

맨먼스(Man-Month)는 말 그대로 사람이 한 달 동안 일하는 단위를 뜻합니다. SI·외주 업계에서는 개발 인력을 얼마나, 얼마나 오래 투입하는지에 따라 견적을 산정할 때 사용하는 개념이에요.

즉, 턴키가 결과물 기준이라면 맨먼스는 인력과 기간을 기준으로 비용을 계산하는 방식이라고 이해하시면 됩니다.

2.1 맨먼스의 기본 의미

맨먼스는 보통 다음처럼 계산됩니다.

• 1명 × 1개월 = 1맨먼스
• 2명 × 3개월 = 6맨먼스
• 3명 × 4개월 = 12맨먼스

투입되는 인력의 역할(프론트엔드, 백엔드, PM 등), 숙련도, 기술 스택에 따라 단가가 다르기 때문에 프로젝트 전체 견적도 이 요소들의 투입 구조를 기준으로 달라져요. 무엇을 만들지보다 어떤 인력이 얼마 동안 투입되는지가 핵심이 되는 구조입니다.

👉 2025 IT 프리랜서 단가 알아보기

2.2 맨먼스 계약이 적합한 경우

맨먼스는 범위보다 인력 투입이 중요한 프로젝트에서 강점을 보입니다.

• 기획이 완전히 정리되지 않은 상태에서 개발을 병행해야 하는 경우
• 요구사항 변경이 반복될 가능성이 높은 프로젝트
• 장기 구축, 증설, 리팩토링, 운영 안정화 등 대규모 프로젝트
• 단기간에 내부 개발 리소스가 필요한 기업
• 유지보수나 상시 운영 인력이 필요한 상황

특히 스펙이 유동적이거나, 프로젝트가 길어지면서 역할이 계속 바뀌는 구조라면 맨먼스 쪽이 훨씬 현실적이에요.

2.3 맨먼스 계약에서 자주 발생하는 오해

턴키와 마찬가지로, 맨먼스 계약에서도 오해가 자주 생깁니다.

• 인력을 투입하고 있는데 결과물이 눈에 띄지 않는 상황
• 투입 공수와 개발 진척이 왜 비례하지 않는지 의문이 드는 경우
• 역할 정의가 명확하지 않아 커뮤니케이션 혼선이 생기는 경우
• 고객이 예상하는 일정과 실제 필요한 공수가 다르게 나오는 경우

이런 문제의 핵심 원인은 대부분 범위와 역할이 명확히 정리되지 않았기 때문입니다. 그래서 맨먼스 방식에서는 각 역할의 책임, 일정 산정 기준, 진척 보고 방식 등을 초기에 정리해두는 것이 중요해요.

* 턴키 vs 맨먼스 계약 비교

턴키와 맨먼스는 겉으로 보기엔 비슷해 보이지만, 실제로는 기준이 완전히 다른 계약 방식이에요. 어떤 프로젝트에 어떤 방식이 맞는지 판단하려면 두 구조의 차이를 명확하게 이해하는 것이 가장 중요합니다.

아래는 실무에서 가장 많이 비교되는 다섯 가지 기준입니다.

** 프로젝트 유형별 추천 턴키 vs 맨먼스 계약 방식

아래는 선택 기준을 빠르게 판단할 수 있도록 정리한 요약입니다.

3. 턴키 계약 시 주의해야 할 것들

턴키 계약은 결과물 중심이기 때문에, 초기 정의가 얼마나 정확하냐에 따라 프로젝트 품질이 크게 달라집니다. 

3.1 요구사항 명확화

가장 중요한 요소입니다. 기획서·화면설계·기능정의 등이 모호하면 개발사가 임의로 해석하게 되고, 그 결과가 예상과 달라질 확률이 높아요.요구사항을 정리할 때는 다음 항목을 최소한 포함하는 것이 좋습니다.

• 핵심 기능
• 예외 케이스
• 사용 흐름(Flow)
• 데이터 구조
• 관리자 기능 여부

3.2 산출물 정의

턴키는 “무엇을 납품받는지”가 기준이기 때문에, 산출물 목록이 명확해야 합니다.

예를 들어,

• 개발 파일(Front/Back)
• 관리자 페이지
• API 문서
• 데이터 모델링
• 테스트 계정
• 배포 환경 구성
• 운영 매뉴얼

이런 항목들을 계약서 또는 별도 문서로 정리해두면 인수 과정에서 불필요한 논쟁을 줄일 수 있어요.

3.3 중간 점검 기준 설정

마일스톤이 없으면 프로젝트 후반부에 한꺼번에 문제를 발견하게 되는 경우가 많습니다.중간 점검은 이렇게 나누는 것을 추천합니다.

• 1차: 화면 구현
• 2차: 기능 개발 70%
• 3차: 전체 기능 완료
• 4차: QA 및 버그 수정

각 단계에서 어떤 기준으로 승인하는지도 함께 정의해두면 훨씬 안정적입니다.

3.4 변경 요청(CR) 처리 기준

턴키에서 가장 많이 갈등이 생기는 지점입니다. 초기 스펙에 없던 기능이 추가되면 비용 또는 일정이 변경되어야 하는데, 이 기준이 없으면 고객과 개발사 모두 어려워져요.

실무에서는 보통 이렇게 정합니다.

• 기능 추가는 CR로 분류
• 일정 3일 이상 소요되는 수정도 CR
• CR 단가 산정 기준(시간·단가) 정의
• 적용 여부는 양측 합의 후 확정

미리 정의해두면 훨씬 깔끔하게 운영됩니다.

3.5 계약서에 반드시 넣어야 하는 항목

턴키 계약서에는 다음 내용을 꼭 넣는 것이 좋습니다.

• 요구사항 범위
• 산출물 목록
• 동일 기능 정의 기준
• 일정과 마일스톤
• CR 처리 절차
• 배포 기준
• 검수 기준 및 기간
• 지체상금 또는 일정 지연 처리 기준

턴키 계약은 계약서를 얼마나 잘 쓰느냐에 따라 성과가 결정된다고 해도 과언이 아닙니다.

4. 맨먼스 계약 시 주의해야 할 것들

맨먼스는 인력 기반 계약이라 턴키와 달리 프로젝트 운영 방식이 훨씬 중요합니다. 아래 항목들은 실제로 가장 문제가 많이 생기는 부분이에요.

4.1 투입 인력의 역할 정의

누가 무엇을 담당하는지를 명확하게 해야 합니다.

예시:

• PM: 일정·진척 관리, 의사결정 정리
• 프론트엔드 개발자: 화면·UI 개발
• 백엔드 개발자: API·DB·서버 로직
• 디자이너: UI/UX 개선
• QA: 테스트 및 검수

맡는 역할이 불분명하면 진척 관리도 어려워지고, 책임 소재도 흐려집니다.

4.2 작업 범위 불명확성 대비

맨먼스는 범위가 유동적이라는 장점이 있지만, 그만큼 작업이 과도하게 늘어나는 경우도 많아요.

그래서 실무에서는 이렇게 대비합니다.

• 우선순위 목록 정의
• 스프린트 또는 월 단위 목표 설정
• 긴급·일반 업무 구분
• 투입 공수 대비 산출물 확인

이렇게 하면 “왜 진척이 안 보이냐” 같은 문제도 크게 줄어듭니다.

4.3 일정·진척 보고 체계

인력 기반 계약에서는 보고 체계가 잡혀 있어야 안심하고 운영할 수 있어요.

일반적으로는 아래 형태로 정리합니다.

• 데일리 또는 위클리 리포트
• 완료·진행·대기 업무 구분
• 블로커(진행 방해 요소) 공유
• 차기 스프린트 계획

이 구조가 잡히면 인력 투입 대비 생산성을 명확하게 확인할 수 있습니다.

4.4 실제 투입 공수 미스매치 리스크

고객 입장에서는 “인력이 들어갔다고 했는데 왜 성과가 부족하지?”라는 상황이 생기고, 개발사 입장에서는 “요구사항이 계속 바뀌어서 공수가 늘어났다”고 느낄 수 있어요. 이 문제의 90%는 기대치와 작업량 공유가 부족해서 발생합니다. 

그래서 맨먼스에서는 프로젝트 초기부터 공수 관리 기준을 명확히 정하는 것이 꼭 필요합니다.

4.5 장기 계약 시 팀 변경 리스크

맨먼스는 장기 운영에 많이 쓰이기 때문에 인력 교체가 발생할 수 있습니다.

• 개발자 변경 시 인수인계 기간
• 코드 컨벤션
• 문서화 수준
• 설계 구조 이해

이런 항목들이 체계적으로 갖춰져 있어야 인력 교체가 있어도 리스크가 줄어듭니다.

계약 방식보다 중요한 건 ‘프로젝트의 성격’을 정확히 아는 것

턴키와 맨먼스는 서로 우열을 가릴 수 있는 방식이 아닙니다. 둘은 구조가 다르고, 장점도 다르고, 관리 방식도 완전히 달라요. 그래서 어떤 방식이 더 좋은지 고민하기보다 내 프로젝트가 어떤 특성을 가지고 있는지를 먼저 정의하는 것이 중요합니다. 프로젝트가 어떤 구조로 흘러가는지, 어떤 리스크가 있는지, 내부에서 어느 정도까지 관리할 수 있는지를 먼저 판단해보세요. 계약 방식은 그다음에 결정해도 늦지 않습니다.

우리 프로젝트는 어떤 방식으로 계약하는게 적합한지 궁금하다면? 간편하게 문의해보세요! ⬇️