POOOLING FOREST
CTO가 말하는 앱개발업체 선정, 그 뼈아픈 실패와 교훈 - CTO가 직접 겪은 앱개발업체 선정 실패 사례와 이를 통해 얻은 3가지 검증 기준을 공유합니다. 화려한 포트
Business Skills

CTO가 말하는 앱개발업체 선정, 그 뼈아픈 실패와 교훈

CTO가 직접 겪은 앱개발업체 선정 실패 사례와 이를 통해 얻은 3가지 검증 기준을 공유합니다. 화려한 포트폴리오보다 중요한 기술적 파트너십의 본질을 확인하세요.

송찬영

CTO

CTO로서 수많은 프로젝트를 지휘하다 보면, 내부 리소스만으로는 감당하기 어려운 순간이 반드시 찾아옵니다. 그때 우리는 외부 파트너, 즉 앱개발업체의 문을 두드리게 되죠. 솔직히 고백하자면, 저 역시 초기에는 뼈아픈 실패를 경험했습니다. "예산 내에서 스펙만 맞춰주면 된다"는 안일한 생각으로 업체를 선정했다가, 결과물은커녕 코드 한 줄 건지기 힘든 상황에 처한 적이 한두 번이 아닙니다. 오늘은 그 부끄러운 과거를 통해 배운, 진짜 실력 있는 파트너를 알아보는 기준에 대해 이야기해보려 합니다.

몇 년 전, 신규 서비스 런칭을 앞두고 급하게 외주 개발을 결정했을 때의 일입니다. 당시 저희 팀은 핵심 엔진 개발에 집중해야 했기에, 클라이언트 앱 개발은 외부 전문 업체에 맡기기로 했습니다. 여러 업체의 제안서를 검토했고, 화려한 포트폴리오와 저렴한 견적을 내세운 한 곳을 선택했습니다. 그들의 제안서는 완벽해 보였습니다. 최신 기술 스택을 사용한다고 했고, 일정도 넉넉하게 맞출 수 있다고 자신했으니까요.

하지만 프로젝트 시작 한 달 만에 문제가 터지기 시작했습니다. 주간 보고 때마다 "잘 진행되고 있다"는 말만 되풀이될 뿐, 실제로 돌아가는 데모 앱은 구경조차 할 수 없었습니다. 답답한 마음에 깃허브 저장소 접근 권한을 요청해 코드를 열어본 순간, 저는 경악을 금치 못했습니다.

변수명은 var1, temp 같은 의미 없는 이름으로 가득했고, 아키텍처라고 부를 만한 구조는 아예 존재하지 않았습니다. 더 심각한 건, 화면 UI만 그럴싸하게 만들어놓고 실제 데이터 연동 로직은 하드코딩으로 박혀 있었다는 점입니다. 결국 계약 해지를 통보하고, 내부 팀원들이 주말 밤을 새워가며 코드를 처음부터 다시 짜야 했습니다. 이 과정에서 발생한 시간과 비용, 그리고 팀원들의 번아웃은 온전히 리더인 저의 책임이었습니다.

그때 깨달았습니다. 화려한 제안서나 포트폴리오의 썸네일은 그 회사의 개발 역량을 증명하지 못한다는 것을요. 앱개발업체를 선정할 때 가장 중요한 것은 '무엇을 만들었는가'가 아니라 '어떻게 만들고, 어떻게 소통하는가'였습니다.

이후 저는 파트너사를 선정하는 기준을 완전히 바꿨습니다. 단순히 결과물만 납품받는 관계가 아니라, 기술적인 런닝메이트를 찾는다는 관점으로 접근했습니다. 제가 정립한 검증 기준은 다음과 같습니다.

첫째, 커뮤니케이션 도구와 방식이 구체적인지 확인해야 합니다. 단순히 "카카오톡이나 이메일로 소통해요"라고 말하는 곳은 거릅니다. 대신 Slack이나 JIRA, Figma 같은 협업 툴을 얼마나 능숙하게 다루는지, 이슈 트래킹은 어떻게 관리하는지 묻습니다. 개발은 코드를 짜는 시간보다 요구사항을 조율하고 버그를 추적하는 시간이 더 깁니다. 체계적인 커뮤니케이션 프로세스가 없는 곳은 프로젝트 후반부로 갈수록 늪에 빠질 확률이 매우 높습니다.

둘째, 코드 품질과 유지보수에 대한 철학을 물어보세요. "저희는 빨리 개발해 드립니다"보다 "저희는 확장성 있는 구조를 고민합니다"라고 말하는 업체를 신뢰해야 합니다. 가능하다면 과거 프로젝트의 코드 스니펫이나 아키텍처 다이어그램을 요청해 보는 것도 방법입니다. 클린 아키텍처나 MVVM 패턴 같은 구조적인 고민을 하는지, 테스트 코드는 작성하는지, CI/CD 파이프라인은 구축되어 있는지 확인해야 합니다. 결국 이 코드를 인계받아 운영해야 하는 것은 우리 내부 개발자들이니까요.

셋째, 개발자 실명제를 운영하거나 전담 인력이 명확한지 체크해야 합니다. 많은 앱개발업체가 계약은 시니어급 개발자의 이력으로 따내고, 실제 개발은 갓 입사한 주니어나 재하청 프리랜서에게 맡기는 경우가 비일비재합니다. 프로젝트 킥오프 미팅 때 실제로 코드를 작성할 개발자가 참석하는지, 그들과 직접 기술적인 대화를 나눌 수 있는지가 중요합니다.

최근 AI 기술을 도입하면서 협력했던 한 파트너사는 이 기준에 완벽하게 부합했습니다. 그들은 미팅 첫날부터 Cursor와 같은 AI 코딩 어시스턴트 활용 전략을 이야기하며, 생산성을 높여 남는 시간을 코드 리팩토링과 성능 최적화에 쓰겠다고 제안했습니다. 단순 구현을 넘어 기술적인 가치를 제안하는 그들의 태도에서 신뢰를 느꼈습니다. 결과적으로 그들과의 협업은 단순 외주를 넘어 저희 기술 팀의 문화를 한 단계 성장시키는 계기가 되었습니다.

앱개발업체를 찾는다는 것은 단순히 일손을 비는 것이 아닙니다. 우리 비즈니스의 중요한 부분을 맡길 수 있는 동료를 찾는 과정입니다. "싸고 빠르게"라는 유혹에 흔들리지 마세요. 그 뒤에는 반드시 기술 부채라는 이자가 붙습니다. 기술적인 깊이를 이해하고, 투명하게 소통하며, 함께 문제를 해결하려는 의지가 있는 파트너를 찾으시길 바랍니다. 그것이 리더가 프로젝트를 성공으로 이끄는 첫 단추입니다.

지금 읽으신 내용, 귀사에 적용해보고 싶으신가요?

상황과 목표를 알려주시면 가능한 옵션과 현실적인 도입 경로를 제안해드립니다.