.svg)
.svg)
누구나 시작은 ‘처음’입니다. 그래서 걱정도 많고 실수도 많죠. 이때 먼저 경험한 사람들의 조언들이 큰 힘이 됩니다. 오늘의 이야기는 외주개발 프로젝트를 먼저 경험해 본 클라이언트들의 공통적인 조언으로, 외주개발에 들어가기 전 미리 알고 챙기면 반드시 도움되는 일종의 지침들입니다. 외주개발을 준비 중인 분들이라면 꼭 참고하세요.
✍️ 이 글의 순서
• 프로젝트는 작은 단위로 쪼개세요.
• 커뮤니케이션이 정말 중요해요.
• ‘유지 비용’ 꼭 염두에 두시길.
• 일정이 늦춰질 걸 대비하세요.
• 첫 요구사항은 바뀌기 마련입니다.
외주개발을 시작할 때, 많은 이들이 빠지는 함정이 바로 프로젝트 전체를 한 번에 맡기려는 관성(?)입니다. 얼핏 보면 효율적으로 보이는데요. 실상 그렇지 않습니다. 오히려 위험한 접근 방식입니다.
프로젝트 전체를 한 번에 맡기면 초기 요구사항과 최종 결과물 사이의 괴리가 커질 가능성이 높습니다. 개발이 진행되는 동안 시장 상황이 바뀌거나 새로운 아이디어가 떠오를 수 있지만 이를 반영하기가 어렵죠. 이런 위험을 피하는 방법은 프로젝트를 ‘작은 단위로 쪼개기’입니다. 프로젝트를 2~3주 단위로 완료할 수 있는 작은 목표들로 나누어 계약하고 진행하세요.
이렇게 하면 우선 각 단계마다 빠르게 결과물을 확인하고 피드백을 줄 수 있습니다. 방향이 잘못되었다면 초기에 바로잡을 수 있어 시간과 비용을 절약할 수 있죠. 또 변화하는 상황에 유연하게 대응할 수 있습니다. 각 단계 사이에 우선순위를 조정하거나 새로운 요구사항을 반영할 수 있는 여지가 생깁니다.
그리고 가장 중요한 건 실제 개발 결과물을 두 눈으로 직접, 그것도 자주 확인할 수 있다는 점입니다. 구두나 문서로만 진행 상황을 체크하는 것은 한계가 있습니다. 실제 작동하는 소프트웨어를 보면서 확인해야 정확한 진행 상황을 파악할 수 있고, 예상치 못한 문제점도 조기에 발견할 수 있습니다.
작은 단위로 프로젝트를 쪼개고 수시로 확인하는 전략은 시간과 노력이 더 들어갈 수 있습니다. 하지만 외주개발 경험자들은 성공적인 서비스 런칭을 위한 필수적인 투자라고 입 모아 이야기합니다. 프로젝트 쪼개기로 위험은 줄이고, 통제력은 높이며, 최종적으로 원하는 결과물을 얻을 확률을 크게 높일 수 있길 바랍니다.
외주개발 프로젝트를 진행하다 보면, 의사소통이 생각보다 복잡해지는 경우가 많습니다. 특히 대부분의 외주 개발사에서는 프로젝트 매니저(PM)가 클라이언트와의 핵심 교두보 역할을 합니다. 언뜻 효율적인 것처럼 보이지만, 실제로는 심각한 소통의 격차를 만들어낼 수 있습니다.
예를 들면 PM은 완전한 개발자가 아니기에 기술적 세부사항을 완벽히 이해하지 못할 수 있고, 실제 개발 현장의 상황을 정확히 파악하기 어려울 수 있습니다. 이로 인해 클라이언트의 요구사항이 개발자에게 왜곡되어 전달되거나, 반대로 개발 과정의 중요한 이슈가 클라이언트에게 제대로 전달되지 않을 가능성이 숨어 있죠.
이 문제를 해결하기 위해서는 프로젝트 매니저(PM)와 실무 개발자 사이의 ‘소통 격차’를 줄이는 일이 선행되어야 합니다. 아래 기본적인 5가지 룰을 공유해 드리니 실무에 잘 녹여 보세요.
클라이언트, PM, 그리고 핵심 개발자가 함께 참여하는 정기 미팅을 가집니다. 이를 통해 모든 당사자가 직접 소통할 수 있는 기회를 만듭니다.
세부적인 기술 관련 질문이 있다면, PM을 거치지 않고 개발자와 직접 소통할 수 있는 채널을 확보합니다.
활용 슬랙이나 지라, 트렐로와 같은 실시간 협업 도구를 사용하여 PM, 개발자, 클라이언트가 함께 대화할 수 있는 공간을 만듭니다. (참고 : 개발외주 실무에서 슬랙보다 좋은 협업툴 7가지)
기술적 배경이 있는 클라이언트라면, 주요 기능의 코드 리뷰 세션에 참여하여 개발 과정을 직접 확인하고 피드백을 줄 수 있습니다.
실무 개발자가 직접 작성한 주간 진행 보고서를 받아봅니다. 이를 통해 PM의 해석을 거치지 않은 원본 상태의 정보를 얻을 수 있습니다.
본격적인 외주 개발 프로젝트에 들어가기 전에, 모르고 들어가면 마주치게 되는 불투명한 항목이 있습니다. 바로 ‘유지 비용’ 또는 ‘운영 비용’이라는 이름으로 청구되는 비용들입니다. 이 항목은 얼핏 보면 당연히 필요한 것처럼 보이지만, 실제로는 불필요하게 과도한 비용이 책정되는 경우도 있어 주의가 필요합니다.
‘유지 비용’의 실체는 생각보다 복잡합니다. 여기에는 서버 유지 비용, 라이선스 비용, 보안 업데이트 비용 등 다양한 요소가 포함되죠. 문제는 이런 세부 항목들이 명확히 구분되지 않은 채 모두 합쳐진 채로 청구되는 케이스가 의외로 많다는 점입니다.
유지 비용을 꼼꼼히 따져보는 과정은 시간과 노력이 필요한 일입니다. 나름의 경험도 필요하죠. 그런데 너무 꼼꼼히 따지다 보면 때로는 외주사와의 관계가 불편해지기도 합니다. 그럼에도 이 과정은 ‘사람’이 아닌 성공적인 ‘서비스’와 ‘프로젝트’를 위한 일임을 잊지 않아야 합니다. 비즈니스의 중장기적 성공과 비용 효율성을 위해 반드시 거쳐야 하는 과정이라는 점 꼭 염두에 두세요.
유지 비용 외에도 숨은 비용은 또 곳곳에 숨겨져 있습니다. 자세한 내용은 견적서에 포함되지 않는 숨은 앱개발 비용 3가지 를 참고하세요. 앱개발 프로젝트 기준이지만, 다른 IT 프로젝트와 큰 차이가 없는 일반론입니다.
외주 개발을 시작하면서 가장 흔히 저지르는 실수 중 하나는 초기에 약속한 일정에 대한 절대적 믿음입니다. 현실은 그렇게 녹록지 않습니다. 프로젝트 일정 지연은 거의 모든 외주 개발에서 발생하는 불가피한 현상이라고 해도 과언이 아닙니다.
일정 지연의 원인은 다양합니다. 예상치 못한 기술적 문제, 요구사항의 변경, 외부 요인 등 수많은 변수가 프로젝트 진행을 늦추게 됩니다. 문제는 이게 단순히 시간만 늦추는 것이 아니라는 점입니다.
일정 지연은 비용 증가, 품질 저하, 심지어는 프로젝트 실패로 이어질 수 있다는 점입니다. 가만히 있다가 이런 일을 맞이하면 여러모로 손해를 입을 가능성이 큽니다. 그래서 이런 일을 미리 이해하고 현실로 받아들이는 것이 필요합니다. 만약, 이런 사실을 알고 일정 계획을 수립한다면 아래 3가지는 염두에 두고 일정 계획을 정리하시길 바랍니다.
가장 먼저 처음부터 여유 있는 일정을 수립하세요. 경험 많은 프로젝트 매니저들은 예상 기간에 최소 20-30%의 예비 기간을 추가해 두기를 권장합니다. 단순히 시간을 늘리는 게 아닙니다. 예상치 못한 상황에 대비하는 일종의 안전장치입니다.
유연한 일정 관리 방식을 도입하세요. 애자일(Agile) 방법론과 같은 유연한 프로젝트 관리 기법을 활용하면 변화에 빠르게 대응할 수 있습니다. 2~3주 단위의 스프린트로 일정을 나누고, 각 스프린트마다 우선순위를 조정하며 진행하는 것이 좋습니다.
의사결정 과정을 최대한 신속하게 만드는 것도 중요합니다. 많은 경우 일정 지연은 클라이언트 측의 느린 의사결정 때문에 발생합니다. 결정권자를 명확히 지정하고, 빠른 피드백 체계를 구축하세요. 정기적인 진행 상황 점검을 통해 지연의 징후를 조기에 발견하는 것도 필요합니다. 문제가 발견되면 즉시 대응 방안을 마련하고 필요하다면 일정을 조정하세요.
이미 벌어진 일정 지연 문제에 잘 대응하기 위한 ‘대응 계획’을 사전에 수립해 두는 건 선택이 아닌 필수입니다. 추가 인력 투입, 범위 조정, 단계적 출시 등 다양한 옵션을 미리 상기해 설정해 두면 실제 상황에서 빠르게 대처할 수 있습니다. 일정 지연에 대비하는 것은 단순히 시간 관리의 문제가 아닙니다. 일정 지연을 예상하고 대비함으로써 프로젝트의 성공 가능성을 크게 높일 수 있습니다.
외주 개발 프로젝트를 진행하다 보면 한 가지 불가피한 현실과 마주하게 됩니다. 바로 요구사항의 변경입니다. 현실적으로 프로젝트를 시작할 때 정의했던 요구사항이 끝까지 그대로 유지되는 경우는 거의 없습니다. 시장 상황의 변화, 새로운 아이디어의 등장, 기술적 제약 등 다양한 이유로 요구사항은 계속해서 변화하게 되죠.
사실상 변화를 막을 방도는 없습니다. 오히려 변화를 받아들이고 효과적으로 관리하는 자세가 필요합니다. 하지만 요구사항 변경을 제대로 관리하지 않으면 프로젝트의 범위가 무한정 확장되는 현상이 발생할 수 있습니다. 자연스럽게 비용 증가 문제로 이어질 수 있어, 주의가 반드시 사전 이해가 필요합니다.
요구사항 변경을 효과적으로 관리하기 위해서는 체계적인 관리 시스템이 필요합니다. 먼저, 변경 요청 프로세스를 명확히 정립해야 합니다. 누가, 어떤 방식으로 변경을 요청할 수 있는지, 그리고 그 요청을 어떻게 검토하고 승인할 것인지에 대한 절차를 만들어야 합니다.
변경 요청이 발생, 실행되었을 때의 영향 분석도 실시해야 합니다. 해당 변경이 일정, 비용, 품질에 어떤 영향을 미칠지 꼼꼼히 따져봐야 합니다. 이를 통해 변경의 필요성과 타당성을 객관적으로 평가할 수 있습니다.
변경되는 요구사항에 따라 계약 조정이 수반되기도 합니다. 추가 작업에 대한 비용과 일정 조정은 반드시 문서화하여 향후 분쟁의 소지를 없애야 합니다. 또 변경 이력을 체계적으로 관리하는 것 역시 중요한 과제인데요. 어떤 변경이 언제, 왜 이루어졌는지를 명확히 기록해두면 프로젝트의 진행 과정을 추적하기 쉽고, 향후 유사한 상황에서 유연하게 대응할 수 있습니다.
위의 외주 개발을 맡겨 본 경험자들의 공통적인 이야기는 결국 ‘외주 개발사 관리’라는 문제로 귀결됩니다. 이 외주 개발사 관리 이슈는 공부를 한다고 해서 완벽해질 수 없습니다. 어쩌면 반드시 ‘경험’이 필요한 영역이라고 볼 수 있죠.
이를 돕기 위해 위시켓에서는 1:1 매니저 제도를 운영합니다. 외주 개발사와 중간에서 의견을 조율하는 건 기본, 필요하다면 미팅에 참관해서 협의를 돕기도, 프로젝트 일정 자체를 관리해 드리기도, 행여 분쟁이 생겼을 때 클라이언트 편에 서서 중재 역할도 하는 중입니다. IT나 외주를 잘 알지 못하는 분들도 위시켓에서라면 문제없습니다. IT 외주 프로젝트를 앞두고 있다면 쉽게 위시켓으로 성공률을 높여 보시기 바랍니다.
🔖 함께 보면 도움되는 글
앱개발 비용 예상, 계산할 때 자주 빼먹는 비용 4가지
.svg)
