개발 외주 맡기기 전에 꼭 알아야 할 5가지! (feat. 계약서 꿀팁)

외주, 무작정 시작하면 큰일납니다! (실패 경험담 대방출)

개발 외주, 무작정 시작하면 큰일납니다! (실패 경험담 대방출)

앱 아이디어 하나 떠올랐는데, 개발자만 붙으면 대박 나겠는데? 혹시 이런 생각, 한 번이라도 해보셨나요? 저도 그랬습니다. 번뜩이는 아이템 하나 믿고 개발 외주 시장에 뛰어들었다가, 쓰디쓴 경험만 한 아름 안고 돌아왔죠. 오늘은 제가 겪었던 시행착오를 낱낱이 파헤쳐 보면서, 여러분은 부디 저와 같은 실수를 반복하지 않도록 외주 성공의 첫걸음을 떼는 방법에 대해 이야기해볼까 합니다.

묻지마 외주의 처참한 결말

당시 저는 작은 스타트업을 운영하고 있었습니다. 새로운 서비스에 대한 아이디어가 떠올랐고, 자체 개발팀이 없었던 저희는 당연하게 외주 개발을 고려했습니다. 문제는 그때부터 시작이었죠. 어떻게든 되겠지라는 안일한 생각으로, 견적 비교도 제대로 안 하고, 계약 조건도 꼼꼼히 따져보지 않은 채, 가장 저렴한 업체를 선택했습니다. 결과는 참담했습니다.

개발은 지지부진했고, 소통은 단절됐으며, 결과물은… 말 그대로 쓰레기였습니다. 제가 생각했던 기능은 구현되지 않았고, 디자인은 엉망이었으며, 버그는 셀 수조차 없었습니다. 결국 프로젝트는 중단되었고, 저희는 시간과 돈만 날린 채 빚더미에 앉게 되었습니다.

왜 꼼꼼한 준비가 필요할까?

돌이켜보면, 저희의 가장 큰 문제는 외주를 너무 쉽게 생각했다는 것입니다. 마치 짜장면 시키듯이, 이런 앱 만들어주세요라고 말하면 뚝딱 만들어지는 줄 알았던 거죠. 하지만 외주 개발은 복잡한 프로젝트입니다. 요구사항 정의부터 개발, 테스트, 유지보수까지, 수많은 단계를 거쳐야 하고, 각 단계마다 예상치 못한 문제들이 발생할 수 있습니다.

예를 들어, 저희는 초기 단계에서 요구사항을 명확하게 정의하지 않았습니다. 이런 기능이 있으면 좋겠다라는 식으로 두루뭉술하게 전달했죠. 그러니 개발업체는 저희가 진짜 원하는 게 뭔지 알 수 없었고, 결국 엉뚱한 결과물을 만들어낼 수밖에 없었습니다. 마치 레시피 없이 요리하는 것과 같은 이치였죠.

성공적인 외주, 첫걸음은 바로 준비

저의 실패 경험을 통해 얻은 교훈은 명확합니다. 개발 외주를 성공적으로 이끌기 위해서는 철저한 준비가 필수적이라는 것이죠. 지금부터 제가 겪었던 시행착오를 바탕으로, 여러분이 외주 성공의 첫걸음을 뗄 수 있도록, 개발 외주 맡기기 전에 꼭 알아야 할 5가지에 대해 자세히 이야기해 보겠습니다. 다음 섹션에서는 계약서 작성 꿀팁까지 아낌없이 공개할 예정이니, 기대해주세요!

숨겨진 함정 피하기: 외주 업체 선정, 이것만은 꼭 확인하세요!

숨겨진 함정 피하기: 외주 업체 선정, 이것만은 꼭 확인하세요! (2)

지난번 글에서는 개발 외주를 고려할 때, 무턱대고 시작했다가는 낭패를 볼 수 있다는 점을 강조했습니다. 오늘은 그 두 번째 시간으로, 외주 업체를 선정할 때 가격 말고 무엇을 봐야 하는지, 제가 직접 겪었던 경험을 바탕으로 꼼꼼하게 파헤쳐 보겠습니다.

포트폴리오, 그 이상의 의미를 읽어라

흔히들 외주 업체를 고를 때 포트폴리오를 보죠. 당연합니다. 하지만 단순히 와, 멋있다! 하고 넘어갈 게 아니라, 그 안에 숨겨진 의미를 읽어내야 합니다. 저는 이렇게 했어요. 먼저, 포트폴리오에 있는 프로젝트와 우리 프로젝트의 유사성을 따져봤습니다. 예를 들어, 쇼핑몰 앱 개발을 맡기려고 한다면, 비슷한 규모와 기능의 쇼핑몰 앱 개발 경험이 있는지 확인하는 거죠.

두 번째, 포트폴리오에 참여한 역할을 꼼꼼히 확인했습니다. 단순히 디자인만 담당했는지, 아니면 백엔드 개발까지 전체를 책임졌는지 알아야 합니다. 간혹 화려한 디자인만 보고 계약했다가, 실제 개발 능력은 미흡해서 곤란했던 경우도 봤거든요.

기술 스택, 우리 회사와 궁합이 맞아야 한다

기술 스택은 외주 업체의 무기와 같습니다. 아무리 뛰어난 업체라도, 우리 회사에서 사용하는 기술과 맞지 않으면 협업이 어려워질 수 있습니다. 저는 외주 업체와 미팅할 때 꼭 기술 스택에 대한 질문을 던졌습니다.

• 저희는 React Native를 사용하는데, 해당 기술 개발외주 스택에 대한 경험은 어느 정도 되시나요?
• 백엔드 API 개발 시, 어떤 아키텍처를 선호하시나요? RESTful API와 GraphQL 중 어떤 방식에 더 익숙하신가요?

이런 질문을 통해, 단순히 할 수 있다는 답변이 아닌, 실제 경험과 노하우를 확인할 수 있었습니다. 기술 스택이 맞지 않으면, 나중에 유지보수나 확장에 어려움을 겪을 수 있으니, 반드시 짚고 넘어가야 할 부분입니다.

소통 방식, 말이 통해야 일이 된다

개발 외주에서 가장 중요한 것 중 하나가 바로 소통입니다. 아무리 실력이 뛰어난 업체라도, 소통이 원활하지 않으면 프로젝트는 산으로 갈 수 있습니다. 저는 외주 업체와 계약하기 전에 반드시 소통 방식을 확인했습니다.

• 주로 어떤 방식으로 커뮤니케이션을 진행하시나요? (슬랙, 이메일, 전화 등)
• 프로젝트 진행 상황은 얼마나 자주 공유해주시나요? (주간 보고, 데일리 스크럼 등)
• 문제 발생 시, 어떤 방식으로 대응하시나요? (긴급 연락망, 티켓 시스템 등)

이런 질문을 통해, 소통 빈도, 채널, 문제 해결 방식 등을 미리 파악하고, 우리 회사와 가장 잘 맞는 업체를 선택했습니다. 특히, 개발 용어나 기술적인 내용을 쉽게 설명해주는 업체는 신뢰도가 높았습니다.

체크리스트와 질문 리스트, 나만의 무기를 만들어라

저는 위에서 언급한 내용들을 바탕으로, 저만의 외주 업체 선정 체크리스트와 질문 리스트를 만들었습니다. 이 리스트를 활용해서 여러 업체를 비교 분석하고, 최종적으로 최적의 파트너를 선택할 수 있었습니다. 여러분도 자신만의 체크리스트와 질문 리스트를 만들어, 외주 업체 선정에 활용해 보시길 바랍니다.

다음 글에서는, 외주 계약 시 반드시 확인해야 할 계약서 꿀팁에 대해 자세히 알아보겠습니다. 계약서는 단순한 종이 쪼가리가 아니라, 여러분의 권리를 보호하는 중요한 도구입니다. 다음 편도 기대해주세요!

계약서, 제대로 안 쓰면 독이 된다! (feat. 꿀팁 대방출)

계약서, 제대로 안 쓰면 독이 된다! (feat. 꿀팁 대방출) – 2. 검수와 유지보수, 악마는 디테일에 있다

지난 칼럼에서 외주 계약의 중요성과 핵심 조항에 대해 이야기했었죠. 오늘은 그중에서도 가장 뜨거운 감자인 검수와 유지보수 조항에 대해 심층적으로 파헤쳐 보겠습니다. 사실 이 두 가지는 프로젝트의 성공 여부를 가르는 핵심 요소라고 해도 과언이 아닙니다. 제가 직접 겪었던 뼈아픈 경험을 바탕으로, 어떻게 하면 이 부분에서 독이 아닌 약이 되는 계약서를 만들 수 있는지 알려드릴게요.

검수, 깐깐하게 따져야 내 돈이 아깝지 않다

검수 조항은 말 그대로 결과물이 계약 내용과 일치하는지 확인하는 절차를 규정하는 부분입니다. 많은 분들이 알아서 잘 해주겠지라는 안일한 생각으로 대충 넘어가는 경우가 있는데, 절대 안 됩니다! 저는 과거에 웹사이트 개발 외주를 맡겼다가 검수 과정에서 큰 낭패를 본 적이 있습니다. 디자인은 그럴듯했지만, 막상 실제 데이터를 넣어보니 엉망진창이었거든요. 기능 오류는 물론이고, 심지어 보안 취약점까지 발견됐습니다. 계약서에 검수 기준이 명확하게 명시되지 않았던 탓에, 외주 업체와 얼굴 붉히며 싸워야 했습니다.

이런 불상사를 막기 위해서는 검수 기준을 최대한 구체적으로 명시해야 합니다. 예를 들어, 단순히 정상 작동이라는 표현 대신, 특정 환경(OS, 브라우저)에서 특정 기능이 몇 초 이내에 작동해야 함과 같이 구체적인 수치를 포함하는 것이 좋습니다. 또한, 검수 기간, 검수 방법, 수정 요구 횟수, 수정 기간 등을 명확하게 정해두어야 합니다. 검수 과정에서 발견된 문제에 대한 책임 소재와 해결 방안도 미리 합의해두는 것이 중요합니다. 저는 변호사 자문을 받아 계약서에 검수 불합격 시 지체 보상금 조항을 추가했는데, 덕분에 외주 업체가 문제 해결에 적극적으로 나서도록 만들 수 있었습니다.

유지보수, 끝나지 않는 이야기

프로젝트가 완료되었다고 모든 것이 끝나는 것은 아닙니다. 오히려 그때부터가 진짜 시작일 수도 있습니다. 웹사이트나 앱은 시간이 지남에 따라 오류가 발생하거나, 새로운 기술에 맞춰 업데이트해야 할 필요성이 생깁니다. 이때 필요한 것이 바로 유지보수입니다. 유지보수 조항은 프로젝트 완료 후 발생하는 문제에 대한 책임 소재와 해결 방안을 규정하는 부분입니다.

유지보수 기간, 유지보수 범위, 유지보수 비용 등을 명확하게 명시해야 합니다. 유지보수 범위는 단순히 오류 수정뿐만 아니라, 기능 개선, 보안 업데이트, 성능 개선 등 다양한 요소를 포함할 수 있습니다. 유지보수 비용은 월정액, 건별, 시간당 등 다양한 방식으로 책정할 수 있습니다. 저는 과거에 유지보수 계약을 제대로 맺지 않아, 사소한 오류 수정에도 엄청난 비용을 지불해야 했던 경험이 있습니다.

유지보수 계약 시에는 SLA(Service Level Agreement)를 함께 고려하는 것이 좋습니다. SLA는 서비스 제공자와 사용자 간의 서비스 수준에 대한 합의를 의미합니다. 예를 들어, 오류 발생 시 24시간 이내에 답변하고, 48시간 이내에 해결해야 한다와 같이 구체적인 목표를 설정하는 것입니다. SLA를 통해 유지보수 서비스의 품질을 높이고, 문제 발생 시 신속하게 대응할 수 있습니다.

검수와 유지보수, 이 두 가지 조항만 꼼꼼하게 챙겨도 외주 계약에서 발생할 수 있는 대부분의 분쟁을 예방할 수 있습니다. 다음 칼럼에서는 계약 협상 시 유용한 꿀팁과, 혹시라도 분쟁이 발생했을 때 어떻게 대처해야 하는지에 대해 자세히 알아보겠습니다. 기대해주세요!

외주 후에도 안심은 금물! 성공적인 협업과 유지보수 전략

개발 외주 맡기기 전에 꼭 알아야 할 5가지! (feat. 계약서 꿀팁)

외주 후에도 안심은 금물! 성공적인 협업과 유지보수 전략

지난번 글에서 외주 계약 전 꼼꼼하게 따져봐야 할 사항들을 짚어봤는데요, 오늘은 그 연장선상에서 외주가 끝난 후에도 프로젝트를 성공적으로 관리하는 방법에 대해 이야기해볼까 합니다. 많은 분들이 외주만 주면 알아서 척척 결과물이 나올 거라고 기대하지만, 현실은 조금 다르죠. 외주 후에도 지속적인 관심과 노력이 필요합니다. 제가 직접 여러 프로젝트를 진행하면서 뼈저리게 느낀 점들을 바탕으로, 여러분의 성공적인 외주 프로젝트를 위한 몇 가지 팁을 공유하고자 합니다.

외주, 끝이 아닌 새로운 시작: 지속적인 소통과 피드백

외주 계약이 종료되고 결과물을 받았다고 해서 모든 게 끝난 것은 아닙니다. 오히려 그때부터가 진짜 시작이라고 할 수 있죠. 개발팀과의 지속적인 소통과 피드백은 결과물의 완성도를 높이는 데 결정적인 역할을 합니다. 저는 프로젝트 초반부터 정기적인 회의를 통해 진행 상황을 체크하고, 궁금한 점이나 개선해야 할 부분을 적극적으로 피드백했습니다. 예를 들어, UI 디자인이 초기 시안과 달라진 부분이 있다면 즉시 피드백하여 원하는 방향으로 수정하도록 요청했습니다. 이러한 과정을 통해 https://www.thefreedictionary.com/개발외주 최종 결과물이 기대에 훨씬 부합하는 수준으로 완성될 수 있었습니다.

유지보수 계약, 꼼꼼하게 따져보세요

외주 프로젝트의 특성상, 결과물에 예상치 못한 오류가 발생하거나 새로운 기능 추가가 필요할 수 있습니다. 따라서 유지보수 계약은 선택이 아닌 필수라고 할 수 있습니다. 유지보수 계약 시에는 다음 사항들을 꼼꼼하게 확인해야 합니다.

• 유지보수 기간: 일반적으로 6개월에서 1년 정도의 기간을 설정하는 것이 좋습니다.
• 유지보수 범위: 오류 수정, 기능 추가, 보안 업데이트 등 유지보수 범위에 대해 명확하게 정의해야 합니다.
• 대응 시간: 문제 발생 시 개발팀의 대응 시간은 얼마나 되는지 확인해야 합니다. 긴급한 문제 발생 시 신속하게 대응할 수 있는 팀을 선택하는 것이 중요합니다.
• 비용: 유지보수 비용은 기간, 범위, 대응 시간에 따라 달라질 수 있습니다. 여러 업체의 견적을 비교하여 합리적인 비용으로 계약하는 것이 좋습니다.

문제 발생 시, 당황하지 말고 침착하게

외주 프로젝트를 진행하다 보면 예상치 못한 문제가 발생할 수 있습니다. 예를 들어, 개발된 기능이 제대로 작동하지 않거나, 보안 취약점이 발견될 수도 있습니다. 이럴 때는 당황하지 말고 침착하게 문제 원인을 파악하고, 개발팀과 협력하여 해결해야 합니다. 저는 과거에 웹사이트에 심각한 보안 취약점이 발견되어 급하게 개발팀에 연락하여 긴급 패치를 진행한 경험이 있습니다. 당시 개발팀의 신속한 대응 덕분에 큰 피해를 막을 수 있었습니다. 문제 발생 시에는 계약서에 명시된 절차에 따라 대응하고, 필요한 경우 법적 자문을 구하는 것도 고려해야 합니다.

마무리하며: 성공적인 외주, 함께 만들어가는 여정

외주 프로젝트는 단순히 돈을 주고 결과물을 받는 거래가 아닙니다. 개발팀과 함께 목표를 향해 나아가는 협업 과정이라고 생각해야 합니다. 지속적인 소통과 피드백, 꼼꼼한 유지보수 계약, 문제 발생 시 침착한 대처는 성공적인 외주 프로젝트를 위한 필수 조건입니다. 이 글에서 공유한 팁들이 여러분의 외주 프로젝트를 성공적으로 이끄는 데 도움이 되기를 바랍니다.