하노이에서 한국 기업이 믿고 맡길 개발 파트너, 무엇을 봐야 하나

하노이 개발 파트너를 찾는 한국 기업이 가장 먼저 확인할 것은 무엇인가

가장 먼저 확인할 것은 견적이 아니라 실행 역량과 팀의 안정성이다. 믿을 만한 파트너는 실제로 운영 중인 결과물, 업무를 조직하는 방식, 그리고 내 프로젝트를 책임지는 사람이 누구인지를 보여준다. 단가가 싸도 담당자가 계속 바뀌는 팀은 결국 더 비싼 비용을 치르게 만든다.

한국 기업이 베트남 북부로 사업을 넓힐 때 웹, 모바일 앱, 사내 소프트웨어 개발을 맡기기에 하노이는 자연스러운 후보지다. 비용이 합리적이고 젊은 기술 인력 풀이 넓으며, 한국과 시차가 두 시간밖에 안 된다. 그런데 선택지가 많다 보니 정말 맡길 만한 파트너와 주문만 받는 가공 업체를 구분하기가 오히려 어려워진다.

가장 흔한 실수는 숫자부터 보는 것이다. 가장 낮은 견적은 거의 언제나 매력적이지만, 그 숫자는 실제로 누가 코드를 쓸지, 팀이 오래갈지, 프로젝트가 중간에 틀어졌을 때 어떻게 되는지를 알려주지 않는다. 대신 단순한 세 가지 질문에서 출발하는 게 낫다. 실제로 납품해서 운영 중인 결과물을 보여줄 수 있는가. 내 프로젝트 담당자는 누구이며 그 사람이 안정적으로 붙어 있는가. 납품 후 문제가 생겼을 때 처리 절차는 무엇인가.

성숙한 파트너는 이 세 질문에 구체적으로, 근거를 들어 답한다. 두루뭉술한 약속으로 피하지 않는다. 이 글에서는 한국 기업이 파트너를 평가할 때 써야 할 다섯 가지 기준 묶음을, 실제 우선순위 순서대로 짚어본다.

계약 구조와 대금·세금 처리: 한국 법인이 안전하게 거래하는 방법

한국 법인에 가장 안전한 방식은 적법한 세금계산서를 발행할 수 있고 범위, 대금 시점, 소스코드 소유권을 명확히 계약하는 상대와 일하는 것이다. 기술을 논하기 전에 누가 거래의 법적 주체이고 어떤 통화로 결제하는지부터 합의해야 한다. 이것이 나중의 회계와 세무 리스크를 좌우하기 때문이다.

국경을 넘는 거래에서 가장 자주 간과되는 것은 증빙이다. 한국 기업은 회계 감사나 세무 검토를 받을 때 버틸 수 있는 계산서와 계약서가 필요하다. 파트너가 단가를 깎아주는 대신 개인 계좌로 송금하라고만 제안한다면, 그 절감액에는 적법한 증빙이 없다는 리스크가 따라온다. 거래 방식은 여러 가지가 있고 각각 결과가 다르다. 한국 법인을 통해 부가세 계산서까지 갖춰 거래하면 회계상 투명하지만 비용은 올라간다. 베트남 현지 주체와 직접 거래하면 단가는 유연해지지만 본인의 증빙 의무를 정확히 이해하고 있어야 한다. 핵심은 싼 가격에 끌려가는 게 아니라 의도를 갖고 선택하는 것이다.

계약서에는 분쟁이 흔히 발생하는 몇 가지 지점을 분명히 해두어야 한다. 작업 범위는 양측이 같은 그림을 그릴 만큼 충분히 상세해야 하고, 범위를 벗어난 추가 요청을 처리하는 방법도 함께 적어야 한다. 대금 시점은 단순히 시간이 흐른 것이 아니라 검증 가능한 산출물 납품에 연동하는 편이 좋다. 소스코드와 디자인 자산의 지식재산권은 대금 완납 후 발주사에 귀속된다고 명시해야 한다. 그리고 하자보수, 버그 수정, 종료 시 인수인계에 대한 조항이 있어야 한다.

전문적인 파트너의 신호는 이런 조항들을 당신이 요구하기 전에 먼저 제시한다는 점이다. 양측을 모두 보호하는 표준 계약서를 파트너가 제안한다면, 그것은 이전에 기업 고객과 진지하게 일해본 적이 있다는 증거다.

커뮤니케이션과 시차·언어 리스크를 줄이는 운영 방식

국경 간 협업에서 가장 큰 리스크는 기술이 아니라 오해다. 리스크를 효과적으로 줄이려면 명확한 단일 연락 창구를 고정하고, 일정한 보고 주기를 합의하며, 모든 결정을 문서로 남겨야 한다. 하노이와 서울의 두 시간 시차는 장점이지만, 커뮤니케이션 절차가 제대로 설계되었을 때만 그렇다.

많은 프로젝트가 코드가 나빠서가 아니라 같은 요구사항을 두고 양측이 다르게 이해해서 실패한다. 모호한 설명이 여러 사람과 두 개의 언어를 거치면 쉽게 변형된다. 그래서 파트너를 평가할 때 그 변형을 어떻게 막는지를 물어야 한다. 좋은 답은 보통 세 가지 축으로 모인다. 매일 누구와 이야기하는가, 얼마나 자주 업데이트를 받는가, 결정은 어디에 기록되는가.

프로젝트마다 담당자 한 명을 고정하는 모델은 큰 도움이 된다. 같은 사람이 처음부터 끝까지 프로젝트를 따라가면 손을 옮길 때 맥락이 사라지지 않고, 누구에게 물어야 할지 늘 분명하다. 반대로 익명의 많은 인원을 거쳐 요청이 흘러가는 모델은 응답이 느려지고 책임이 희석되기 쉽다.

언어 면에서 모든 엔지니어가 한국어를 해야 하는 것은 아니다. 필요한 것은 한국 측이 추측 없이 읽고 이해할 수 있는 소통 채널이다. 일부 파트너는 자료와 보고서를 이중언어로 준비한다. 베트남어 본문을 원본으로 두고, 한국어 본은 한국 고객이 검토할 수 있게 함께 싣는 식이다. 이 방식은 요란하지 않지만, 파트너가 언어 격차를 방치할 것이 아니라 관리해야 할 리스크로 이해하고 있다는 것을 보여준다.

코드 품질과 검수 체계를 어떻게 검증하나

최종 결과물만 보지 말고 그것을 만드는 과정을 평가하라. 믿을 만한 파트너는 품질을 어느 지점에서 통제하는지 설명할 수 있다. 코드 리뷰를 하는가, 검수는 누가 하는가, 버그는 고객에게 닿기 전에 잡히는가 후에 잡히는가. 번지르르한 데모 하나보다 명확한 프로세스가 더 중요하다.

기술 비전공자가 코드를 직접 읽어 평가하기는 어렵다. 하지만 건강한 프로세스를 알아보는 데 코드를 읽을 필요는 없다. 진지한 팀만 막힘없이 답하는 몇 가지 질문을 던지면 된다. 고객에게 넘기기 전에 결과물은 어떤 점검 단계를 거치는가. 한 사람이 코드를 쓰면 두 번째 사람이 다시 보는가. 버그는 보통 어느 단계에서 발견되고 고치는 데 얼마나 걸리는가.

믿을 만한 구조에는 보통 이중 검수 층이 있다. 자동화 도구와 기계가 1차로 오류를 거르고, 그다음 경험 있는 사람이 기계가 못 잡은 것을 다시 살핀다. AI 보조 도구가 점점 보편화되는 시대에 코드를 빠르게 만들어내는 것은 더 이상 차별점이 아니다. 진짜 차별점은 검수 단계에 있다. 도구가 만든 코드가 실제로 맞고, 안전하고, 요구사항에 부합하는지 확인할 책임을 누가 지는가. 속도만 내세우고 통제 단계를 말하지 못하는 파트너는 조심해야 할 신호다.

문서화 방식을 보여달라고 요청해도 좋다. 명확하고 갱신되는 기술 문서는 팀의 규율을 보여주는 간접적이지만 믿을 만한 증거다. 돌아가긴 하는데 어떻게 만들어졌는지 아무도 모르는 결과물은 수정이 필요한 순간 곧바로 짐이 된다.

유지보수·하자보수·이전 가능성: 끝이 아니라 시작을 보는 기준

납품 시점은 끝이 아니라 진짜 관계의 시작이다. 파트너는 납품 이후 구간을 다루는 방식으로 골라야 한다. 하자보수 정책, 버그 수정 속도, 그리고 필요할 때 직접 운영하거나 다른 곳으로 옮기기 위해 소스코드와 문서 전부를 돌려받을 수 있는지가 기준이다. 결과물은 프로젝트보다 오래 산다.

값비싼 실수 하나는 출시 순간만 생각하고 그 이후 몇 달을 생각하지 않는 것이다. 소프트웨어는 갱신되고, 버그가 잡히고, 바뀌는 요구에 맞춰 조정되어야 한다. 그래서 계약 전에 몇 가지를 분명히 해야 한다. 납품 후 발견된 버그는 얼마 동안 무상으로 수정되는가. 하자보수 기간이 끝난 뒤 유지보수 비용은 어떻게 산정되는가. 언젠가 직접 운영하거나 파트너를 바꾸고 싶을 때, 그것을 할 수 있도록 소스코드와 데이터베이스, 문서를 충분히 받을 수 있는가.

마지막 질문이 특히 중요하다. 자신 있고 정직한 파트너는 소스코드나 문서를 감춰 당신을 인질로 잡지 않는다. 당신이 떠날 수 있는 능력이 곧 그들의 투명성을 재는 잣대다. 역설적이게도, 언제든 떠날 수 있다는 것을 알 때 오히려 남는 쪽을 택하게 된다. 관계가 속박이 아니라 신뢰 위에 세워지기 때문이다.

정리하면 이 다섯 가지 기준 묶음은 실제적인 필터를 이룬다. 팀의 역량과 안정성, 안전한 계약 구조와 증빙, 오해를 막는 커뮤니케이션 절차, 여러 층의 품질 통제 체계, 그리고 납품 이후 구간에 대한 약속이다. 이 다섯 묶음 모두에 구체적으로 답하는 파트너라면, 한국 기업이 하노이에서 일을 맡길 만한 상대다. 견적은 위 다섯 가지를 확신한 다음 마지막으로 따질 요소여야 한다.