IT 컨설팅블로그 글
IT 컨설팅과 개발 외주의 차이
IT 컨설팅과 개발 외주의 역할, 산출물, 담당 범위와 선택 기준을 비교해 설명합니다.
IT 컨설팅은 무엇을 왜 바꿀지 판단하는 일에, 개발 외주는 합의한 기능과 시스템을 구현하는 일에 초점을 두고 비교할 수 있습니다. 다만 서비스 이름만으로 실제 제공 범위가 정해지는 것은 아닙니다. 한 프로젝트에서 두 역할이 함께 필요하거나 한 제공자가 여러 역할을 맡을 수도 있습니다.
이 글은 발주 전에 역할·산출물·책임·선택 기준을 구분하기 위한 설명입니다. 모든 업체의 계약 조건이 같다고 가정하거나 전산가이의 특정 상품·가격·성과를 제시하지 않습니다.
1. 먼저 남아 있는 질문을 구분합니다
업무의 문제가 무엇인지, 현재 자료와 시스템을 어떻게 연결할지, 어떤 대안을 선택할지가 불분명하다면 조사와 분석·의사결정 지원의 범위를 먼저 검토할 수 있습니다. 기능 목록이 있어도 문제의 원인이나 운영 책임이 정리되지 않았다면 구현 전에 확인할 항목이 남아 있는 셈입니다.
반대로 필요한 사용자 흐름과 데이터·권한·검수 기준이 정리돼 있다면 구현 범위와 인도할 결과를 구체화할 수 있습니다. 이때도 기존 자료의 누락이나 연동 제약을 확인하는 작업은 필요할 수 있습니다. ‘컨설팅 또는 개발’이라는 두 가지 이름만으로 프로젝트를 단순하게 나누지 마세요.
2. 활동과 산출물을 비교합니다
| 비교 항목 | 컨설팅 범위에서 확인할 일 | 개발 외주 범위에서 확인할 일 |
|---|---|---|
| 핵심 질문 | 어떤 문제와 대안을 검토할 것인가? | 어떤 동작과 결과를 구현할 것인가? |
| 주요 활동 예시 | 현황 조사, 요구 분석, 대안·우선순위 검토 | 설계, 구현, 테스트, 적용·인계 |
| 산출물 예시 | 현황·문제 정리, 요구·대안·실행 계획 | 동작하는 기능, 테스트·운영 자료 |
| 검수 관점 | 근거와 판단 기준이 명확한가? | 합의한 조건에서 기능이 동작하는가? |
표는 협의에 사용할 구분 예시입니다. 현황 조사나 운영 지원이 어느 범위에 포함되는지는 실제 제안에서 확인해야 합니다. 분석 문서가 있다고 해서 구현과 운영까지 완료된 것은 아니며, 시연 화면이 있다고 해서 업무 적합성 검증이 끝난 것도 아닙니다.
3. 두 역할 사이의 연결을 정합니다
분석 결과가 개발에 쓰이려면 요구사항의 의미, 데이터와 권한, 검수 기준이 전달돼야 합니다. 중요한 가정과 미정 항목을 숨기지 말고 확인할 담당자와 다음 판단 시점을 기록하세요. 문서 파일만 넘겼다고 인계가 끝났다고 보기는 어렵습니다.
개발 중 새로운 제약이 발견되면 누가 범위와 우선순위를 판단하는지도 정합니다. 분석 담당자와 구현 담당자가 다르다면 질의·변경·승인 경로를 연결하고, 같은 제공자라면 단계별 책임과 검수 결과를 구분해 남깁니다.
다양한 역할이 사용자 요구를 중심으로 함께 일한다는 관점은 GOV.UK의 서비스 팀 역할 안내에서 참고할 수 있습니다. 정부 서비스의 역할 구성을 모든 기업에 그대로 적용하거나 컨설팅·외주 계약의 기준으로 삼는다는 의미는 아닙니다.
4. 제안서를 업무 상태에 맞춰 검토합니다
| 현재 상황 | 확인할 질문 | 협의할 범위 |
|---|---|---|
| 목표가 추상적임 | 실제 문제와 사용자를 확인했는가? | 현황 조사와 목표·판단 기준 |
| 기능은 있으나 근거가 약함 | 업무·데이터·예외가 연결돼 있는가? | 요구 검증과 범위 구체화 |
| 구현 범위가 정리됨 | 동작·권한·연동·검수 조건이 명확한가? | 구현·테스트·적용·인계 |
| 운영까지 맡기려 함 | 누가 변경·계정·장애를 관리하는가? | 운영 지원과 내부 책임의 경계 |
제안서에는 제공 활동과 실제 산출물, 내부에서 제공할 자료와 승인 책임, 제외·별도 협의 항목을 구분해 요청하세요. 문서의 양이나 기술 이름만으로 결과를 판단하기보다 실제로 어떤 결정을 하거나 어떤 동작을 검증할 수 있는지 확인하는 편이 좋습니다.
웹 기반 시스템의 화면·링크 검수 예시는 홈페이지 오픈 전 QA 체크리스트를 참고할 수 있습니다. 업무와 데이터·권한에 필요한 검수는 해당 프로젝트에 맞춰 추가해야 합니다.
역할과 범위 확인 체크리스트
자주 묻는 질문(FAQ)
컨설팅을 받으면 개발도 포함되나요?
이름만으로 포함 여부를 판단할 수 없습니다. 조사·분석·실행 계획과 실제 구현·테스트·운영 지원 중 무엇을 제공하는지 제안서의 활동과 산출물로 확인하세요.
개발 외주 전에 컨설팅을 반드시 따로 받아야 하나요?
항상 별도 단계가 필요한 것은 아닙니다. 현재 업무와 요구사항이 얼마나 정리돼 있는지, 어떤 불확실성이 남았는지 확인하고 필요한 조사·검증을 개발 범위 안에서 수행할지 별도로 진행할지 협의할 수 있습니다.
한 업체가 두 역할을 맡으면 구분할 필요가 없나요?
같은 제공자여도 단계별 결과와 책임은 구분하는 편이 좋습니다. 무엇을 분석해 어떤 범위를 승인했는지, 구현·검수·운영에서 누가 판단하는지를 남겨야 변경이 생겼을 때 기준을 확인할 수 있습니다.
어느 쪽이 비용을 더 아낄 수 있나요?
작업 범위와 현재 준비 상태를 모른 채 단정할 수는 없습니다. 필요한 활동·산출물·내부 투입·미정 항목을 같은 기준으로 비교하고, 확인되지 않은 절감률이나 가격을 전제로 결정하지 마세요.
핵심 정리
IT 컨설팅과 개발 외주는 판단 지원과 구현이라는 관점으로 구분할 수 있지만 실제 범위는 활동·산출물·책임으로 확인해야 합니다. 두 역할의 연결과 내부 의사결정을 함께 정리하는 것이 중요합니다.
현재 남은 질문이 ‘무엇을 바꿀까’인지 ‘어떻게 구현하고 검수할까’인지 적어 보세요. 그 답을 바탕으로 필요한 범위를 더 구체적으로 협의할 수 있습니다.
현재 준비 상태와 필요한 역할을 정리해 보세요
업무 문제, 준비된 요구사항과 자료, 미정 항목을 비밀정보 없이 정리해 전산가이 문의하기로 전달해 주세요. 서비스 이름보다 실제 필요한 작업과 산출물을 중심으로 논의할 수 있습니다.