15년간 한국·일본·베트남·싱가포르 개발사들과 협업하면서 수없이 넘어지고 배웠습니다. 언어도 시간대도 다른 팀과 제품을 만드는 건 생각보다 훨씬 복잡하고, 생각보다 훨씬 보람 있습니다. 이 글에서는 실제로 겪은 시행착오와 지금 쓰고 있는 노하우를 솔직하게 공유합니다.
1. 시간대 차이를 적으로 만들지 마라
베트남(UTC+7)과 한국(UTC+9)의 시간차는 2시간입니다. 처음엔 별거 아닌 것 같지만, 잘못 관리하면 하루에 의사결정을 한 번밖에 못 하는 상황이 생깁니다. 반대로 잘 설계하면 오히려 24시간 릴레이 개발이 가능해집니다.
# 협업 타임존 관리 예시 (Python)
from datetime import datetime
import pytz
KST = pytz.timezone('Asia/Seoul')
VN = pytz.timezone('Asia/Ho_Chi_Minh')
def schedule_standup():
# 겹치는 업무시간: KST 10:00 = VN 08:00
# 양쪽 모두 업무 시작 직후 → 최적 미팅 시간
standup_kst = datetime.now(KST).replace(hour=10, minute=0)
standup_vn = standup_kst.astimezone(VN)
return standup_kst, standup_vn
kst, vn = schedule_standup()
print(f"한국: {kst.strftime('%H:%M')} / 베트남: {vn.strftime('%H:%M')}")저는 오전 10시 KST를 데일리 스탠드업 고정 시간으로 씁니다. 양쪽 다 업무를 막 시작한 시점이라 에너지도 있고, 오전 중에 이슈를 해결할 시간도 남습니다. 회의는 15분을 넘기지 않습니다.
2. 커뮤니케이션 도구는 3개로 압축하라
초기에는 이메일, 카카오톡, Slack, Zoom, Notion을 동시에 썼습니다. 결과는 대혼란이었습니다. 지금은 Slack(실시간) + Notion(비동기 문서) + GitHub(코드/이슈)으로만 운영합니다.
- Slack — 즉각 반응이 필요한 질문, 일일 스탠드업, 빠른 결정
- Notion — 요구사항 문서, 회의록, 의사결정 기록. 영어로 작성해서 번역 오해 방지
- GitHub Issues/PR — 모든 기술적 논의는 코드와 붙어있어야 컨텍스트를 잃지 않음
중요한 결정은 반드시 텍스트로 기록합니다. 구두로만 전달된 요구사항은 나중에 “그런 말 안 했는데요”로 돌아옵니다. 특히 국경을 넘으면 더합니다.
3. 요구사항은 과할 정도로 구체적으로 써라
한국어로 “보기 좋게 만들어주세요”는 한국 개발자한테도 모호합니다. 영어로 번역하면 더 모호해집니다. 해외 팀에 줄 요구사항은 스크린샷 + 수치 + 예외 케이스가 있어야 합니다.
# 나쁜 예
- 로그인 버튼을 예쁘게 만들어주세요
# 좋은 예
- 로그인 버튼: background #0064FF, border-radius 8px, padding 12px 24px
- hover 시: background #0052D6, transition 0.2s ease
- disabled 시: background #CCCCCC, cursor not-allowed
- 모바일(< 768px): 버튼 너비 100%
- 참고 스크린샷: [Figma 링크]처음엔 이게 귀찮게 느껴집니다. 하지만 불명확한 요구사항 하나가 수정-재수정 사이클 3번을 만든다는 걸 경험하고 나면 생각이 바뀝니다. 명확한 스펙은 양쪽 모두에게 이득입니다.
4. 코드 리뷰는 문화가 아니라 프로세스로 만들어라
해외 팀과 코드 리뷰를 하면 처음에 어색함이 있습니다. 피드백을 개인적으로 받아들이는 문화권도 있고, 반대로 너무 예의 바르게 얘기해서 핵심을 못 전달하는 경우도 있습니다. 이걸 문화 차이로 두지 않고 프로세스로 표준화하는 게 답입니다.
# PR 체크리스트 (팀 공용)
## 작성자 확인사항
- [ ] 테스트 추가 or 기존 테스트 통과 확인
- [ ] 요구사항 문서와 대조 완료
- [ ] 브라우저 3종 (Chrome/Safari/Firefox) 확인
## 리뷰어 가이드라인
- Blocking issue: 반드시 수정 필요 → "BLOCKING:"으로 시작
- Suggestion: 개선 제안 → "SUGGESTION:"으로 시작
- Nitpick: 사소한 것 → "NITPICK:"으로 시작
- 칭찬도 적극적으로 → "NICE:"로 시작리뷰 코멘트의 톤과 형식을 통일하면 감정 소모가 줄고 기술적 토론에 집중할 수 있습니다. 특히 영어로 리뷰할 때는 이런 표준이 더욱 중요합니다.
5. 계약서에서 놓치기 쉬운 3가지
글로벌 협업에서 계약은 신뢰의 문제가 아니라 명확함의 문제입니다. 서로 선의가 있어도 기대치가 다르면 갈등이 생깁니다. 아래 3가지는 꼭 계약서에 명시하세요.
- 지적재산권(IP) 귀속 — 개발 결과물의 소유권이 누구에게 있는지. 기본적으로 "발주사가 완전한 IP를 보유"로 명시
- 소스코드 인도 시점과 방식 — 최종 납품 시점, GitHub 저장소 이전 or 아카이브 방식, 문서 포함 여부
- 유지보수 범위와 기간 — 납품 후 버그 수정 무료 기간(보통 30~90일), 이후 시간당/월정 요금 기준
6. 베트남 개발팀과 협업할 때 추가로 알아두면 좋은 것들
코드벤터는 현재 하노이와 다낭의 5개 협력사와 협업하고 있습니다. 베트남 팀과 일하면서 특히 도움이 됐던 팁들입니다.
- 베트남 국경일 미리 확인 — Tết(음력 설)은 1~2주 전후로 사실상 업무가 멈춥니다. 프로젝트 일정에 반드시 반영하세요
- 영어 실력에 편차가 큼 — 시니어는 영어를 잘 하지만 주니어는 어려울 수 있음. PM을 통해 소통하는 구조를 만드는 게 효율적
- 하노이 vs 다낭 vs 호치민 — 도시마다 팀 성격이 다릅니다. 하노이는 대형 기업 중심, 호치민은 스타트업 색이 강하고, 다낭은 소규모 고품질팀이 많습니다
- Lab-based 모델의 효율 — 단발 프로젝트보다 장기 계약(Lab-based)이 품질과 소통 모두 훨씬 좋아집니다. 팀이 컨텍스트를 쌓기 때문
마치며
글로벌 협업은 어렵습니다. 하지만 어렵다고 피해선 안 되는 시대가 됐습니다. 인건비 차이도 있고, AI 도구와 결합하면 소규모 팀으로 대형 프로젝트를 소화할 수 있습니다. 중요한 건 문화 차이를 존중하면서도, 프로세스만큼은 명확하게 표준화하는 것입니다.
코드벤터는 베트남 5개 협력사와의 글로벌 네트워크를 통해 스타트업부터 중견기업까지 다양한 규모의 개발 프로젝트를 수행하고 있습니다. 해외 개발팀 협업이나 아웃소싱 프로젝트에 대해 궁금한 점이 있으시면 언제든 문의해 주세요.
