"베트남에서 개발하면 비용이 3분의 1이래요."

개발 비용을 줄이고 싶은 마음은 당연합니다. 해외 외주(오프쇼어)는 매력적인 선택지처럼 보입니다. 실제로 잘 맞는 경우도 있습니다. 하지만 모든 프로젝트에 맞는 것은 아닙니다.

해외 외주의 장단점

장점: 비용

과거에는 인건비가 가장 큰 장점이었습니다. 하지만 최근 해외 개발자 인건비도 많이 올랐습니다. 베트남, 인도 등의 시니어급 개발자는 예전처럼 국내의 절반 수준이 아닙니다. 그래도 주니어~중급 인력의 경우 아직 가격 차이가 있어서, 예산이 제한된 상황에서 활용 여지는 있습니다.

단점: 보이지 않는 비용

인건비가 낮다고 총비용이 낮아지는 것도 아닙니다.

알아두셔야 할 현실

현재 어떤 메이저한 에이전시는 베트남 등에 자회사를 설립해서 현지 개발자를 직접 고용하는 곳이 있습니다. 여기서 중요한 건 그 구조입니다. 한국 개발자와 해외 개발자를 섞어서 팀을 구성하고, 클라이언트와의 소통 창구는 한국 개발자가 담당합니다. 클라이언트 입장에서는 해외 개발자가 투입된 게 보이지 않습니다. 그런데 단가는 한국 개발자 기준으로 받습니다.

이게 나쁘다는 것이 아닙니다. 소통 품질이 유지되고 결과물이 좋으면 괜찮습니다. 다만 내가 지불하는 단가가 실제 투입 인력의 단가와 다를 수 있다는 점은 알고 계셔야 합니다. 시니어급 단가를 받고 해외 주니어가 실제 코드를 작성하는 구조라면, 그건 클라이언트가 판단할 수 있는 정보가 투명하게 공개되어야 합니다.

소통 비용: 솔직히 한국 개발자랑도 소통이 어려운 이야기가 산더미입니다. 그런데 바다 건너 비행기 타고 가야 만날 수 있는 타국의 개발자랑 얼마나 소통이 잘 되겠습니까. 한국어를 잘하는 해외 개발자는 극소수이고, 영어로 소통해야 하며, 미묘한 뉘앙스가 전달되지 않습니다. "이 버튼을 눌렀을 때 자연스럽게 넘어가게 해주세요" — 이 "자연스럽게"를 설명하는 데 생각보다 오래 걸립니다.

중간에 PM을 두면 더 문제입니다. PM을 두는 명분은 "소통 채널을 일원화해서 누락되는 메시지를 없애고, 같은 말을 여러 번 하는 비효율을 줄이자"입니다. 맞는 말처럼 들리지만, 현실에서는 반대로 작용하는 경우가 많습니다. PM이 기술을 깊이 이해하지 못하면 클라이언트의 요구사항이 개발자에게 왜곡되어 전달되고, 개발자의 기술적 제약이 클라이언트에게 정확히 전달되지 않습니다. 전화기 게임처럼 중간에 한 명이 낄수록 메시지가 변형됩니다. 실제로 해외 외주를 경험한 클라이언트의 이야기를 들은 적이 있습니다. PM을 통해서만 소통이 가능한 구조였는데, PM을 거칠 때마다 요구사항이 왜곡됐습니다. 개발자와 직접 이야기하고 싶었지만, 프로젝트 1년 동안 단 한 번도 실제 개발자와 직접 소통하지 못했습니다. 매번 버그 덩어리의 결과물이 왔고, 버그 하나를 수정시키면 다른 버그가 나오고, 1년 동안 프로젝트를 진행했지만 결국 프로젝트는 폐기됐습니다. 1년치 비용과 시간이 증발한 겁니다.

시차: 베트남은 2시간, 인도는 3.5시간 차이입니다. 금요일 오후에 발견한 버그를 전달하면, 수정이 월요일 오전에 옵니다. 급한 이슈에 실시간 대응이 어렵습니다.

품질 관리: 코드 리뷰를 직접 할 수 없으면, 결과물의 품질을 기대만으로 통제해야 합니다. 문서화 수준도 팀마다 편차가 큽니다.

문화적 차이: "이해했습니다"가 진짜 이해한 건지, "알겠습니다"라고 대답한 건지 구분이 어렵습니다. 문제가 있어도 바로 말하지 않고, 나중에 결과물로 드러나는 경우가 있습니다.

국내 외주의 장단점

장점: 소통

같은 시간대, 같은 언어, 같은 비즈니스 문화. "이 기능은 한국 사용자에게 이런 맥락에서 필요합니다" — 이걸 설명하는 데 5분이면 됩니다.

대면 미팅이 가능하고, 카카오톡이나 슬랙으로 실시간 소통이 됩니다. 문제가 생기면 즉시 대응할 수 있습니다.

단점: 비용

국내 개발자 인건비는 해외 대비 높습니다. 같은 예산으로 투입할 수 있는 인력이 적습니다.

어떤 프로젝트에 어떤 선택이 맞는가

해외 외주가 맞는 경우

• 단순 반복 작업: 디자인 시안을 HTML/CSS로 변환, 기존 앱을 다른 플랫폼으로 포팅
• 명확한 스펙이 있는 작업: 화면 설계서, API 명세서가 완벽하게 준비된 상태
• 비즈니스 로직이 단순한 프로젝트: 정보 제공 웹사이트, 단순 CRUD 앱
• 내부에 기술 관리자가 있는 경우: 코드 리뷰와 품질 관리를 내부에서 할 수 있음

핵심은 "무엇을 만들어야 하는지"가 100% 명확한 상태에서, 실행만 맡기는 경우입니다.

국내 외주가 맞는 경우

• 비즈니스 이해가 필요한 프로젝트: 한국 시장 특유의 결제 구조, 배송 로직, 회원 등급 체계 등
• 기획이 확정되지 않은 프로젝트: 개발하면서 방향이 바뀔 수 있는 초기 단계
• 실시간 소통이 중요한 프로젝트: 빠른 피드백 반영, 긴급 대응이 필요한 서비스
• UX에 민감한 프로젝트: 한국 사용자의 기대에 맞는 인터랙션, 플로우 설계

"반반" 전략

실무에서는 하이브리드로 가는 경우도 있습니다.

• 기획, 설계, 핵심 로직: 국내 개발팀
• 단순 페이지 구현, 퍼블리싱: 해외 개발팀
• QA: 국내에서 최종 검수

이 방식은 전체 비용을 줄이면서, 핵심 부분의 품질은 유지하는 전략입니다. 다만 두 팀 간의 코드 통합과 소통을 관리하는 역할이 반드시 필요합니다.

정리

|---|---|---|

단순 반복 작업은 해외, 비즈니스 이해가 필요한 작업은 국내. 이것이 가장 현실적인 기준입니다. "싸니까 해외"가 아니라, "이 작업에 소통이 얼마나 필요한가"로 판단해야 합니다.

*프로젝트에 맞는 개발 방식이 궁금하시다면, 프로젝트 상담을 통해 문의해 주세요.*