인도, 베트남 개발자가 한국 개발자를 대체할 수 있을까

※ 주의

이 글은 픽션입니다.

이글에 등장하는 인물 단체 지명 등은 실제와 관련이 없음을 알려드립니다.

지난 1년간 시장에서 핫하다는 인도, 베트남 개발자와 함께 프로젝트를 진행했다. 이 글은 1년 동안 프로젝트를 진행하며 느낀 점, 국내 개발자들과 해외 개발자들은 어떤 점이 다른가, 어떤 어려움이 있었지에 대한 회고 겸 넋두리이다.

영어 잘하는 기획자가 없어요! 이 프로젝트는 3개국 인원이 협업하는 다국적 프로젝트였다.

파트별 구성은 다음과 같다.

기획, 디자인, 퍼블리싱 = 한국

프론트엔드 = 베트남

백엔드 = 인도

3개 국가가 모인 다국적 프로젝트이다 보니 의사소통은 자연스럽게 영어로 진행하게 되었다. 개발자들이야 글로벌 프로젝트와 협업을 밥 먹듯이 하는 사람들이라 영어를 프리토킹 수준으로 구사할 수 있었지만, 한국 작업자들은 프리토킹은커녕 읽고 쓰기도 어려운 사람이 많았다.

자연스럽게 프로젝트의 인력을 배치할 때 최우선으로 고려하는 사항이 '기획을 얼마나 잘하냐' , '관련 도메인 경험을 가지고 있느냐' 가 아니라 '얼마나 영어를 잘하냐' 가 되어 버리고 말았다. 이게 문제의 시작이었다.

처음에는 통역만 전담으로 하는 전문 통역사를 고용했다. 그런데 개발에 대한 이해가 떨어지는 통역사를 통해 모든 의사소통을 진행다보니, 소통의 흐름이 뚝뚝 끊기고 회의 시간이 오래 걸렸다. 생각보다 업무 진척이 더디자, 보다 못한 윗선에서 영어를 프리토킹 수준으로 구사할 수 있는 기획자를 몇 명 데리고 왔다. 나는 오랜 경험으로 알고 있었다. 영어를 프리토킹 수준으로 구사하는 기획자는 ‘물경력’일 확률이 높다는 사실을.

기획자는 영어가 필수인 포지션도 아니고 업무에서 영어를 쓸 일도 거의 없다 보니 영어를 잘하는 사람이 많지 않다. (이는 개발자와 디자이너도 마찬가지) 영어가 필요한 포지션이나 회사도 있긴 하지만 우리 쪽과는 채용 시장이 분리되어 있다. 영어를 잘하는 기획자는 보통 영어를 필요로 하는 회사에서 일하고, 실무보다는 관리 업무를 주로 담당한다.

쉽게 말하면 이런 거다.

“영어 잘하고 실력 좋은 기획자가 왜 여기 있어, 갈 데가 얼마나 많은데.”

역시나 사장님이 데려온 기획자들은 영어를 프리토킹 수준으로 구사할 수 있었지만, 실무 경험이 부족한 물경력이었다. 물경력 프리토킹 기획자들은 프로젝트 내내 끊임없이 문제를 일으켰다. 내용을 잘못 이해해 이상한 방향으로 개발 지시를 한다거나 잘못된 통역으로 오해를 불러일으키는가 하면, 문서를 엉망진창으로 만들어 개발자들을 혼란에 빠트리기도 했다.

외국 개발자와 협업을 하면 가장 먼저 부딪히게 되는 것이 언어의 장벽 이다. 외국 개발자에게 개발을 맡기는 회사는 십중팔구 개발자를 채용하기 어려운 스타트업일 텐데, 개발자를 뽑기 어려운 회사가 그보다 열 배는 더 뽑기 어려운, 영어를 잘하는 PO나 PM을 뽑을 수 있을까? 현지 에이전시의 한국인 관리자가 소통을 담당한다고? 인력 사무소 사장은 인력을 보내주면 땡이다. 그 인력을 어떻게 활용할지는 순전히 당신의 몫이다.

업무 범위와 업무 롤(role)의 문제 앞서 설명했듯 이 프로젝트는 프론트엔드는 베트남, 백엔드는 인도에서 개발을 담당했다. 지금이야 우리나라도 프론트엔드, 백엔드 업무가 분리되어 있지만 몇 년 전만 해도 프론트엔드, 백엔드에 대한 개념 자체가 없었다. 개발자라면 당연히 프론트도 백엔드도도 할 줄 아는 게 업계의 상식이었다. 우리나라는 아직도 그런 기조가 좀 남아있다. 그런데 외국은 좀 다르다. 프론트엔드와 백엔드가 구분되어 있고 각자 업무 범위도 다르다.

개발을 진행하다 보면 프론트인지 백엔드인지 범위가 애매한 것들이 종종 있다. 예를 들면 백엔드에서 코드로 관리하는 콤보박스 옵션 같은 것들이 그렇다.

1:1 문의 작성 기능을 개발한다고 가정해 보자.

문의유형은 상품문의(A1), 고객문의(B1), 기타문의(C1) 3개 유형이 있고 관리자에서는 코드로 관리된다. 프론트에서 문의유형 콤보박스를 선택할 때 옵션값은 백엔드 API를 통해 가져온다. 이때 백엔드 API에서 상품문의, 고객문의, 기타문의라는 텍스트값을 주는 것이 아니라 A1, B1, C1이라는 코드값을 전달한다. 이렇게 코드값을 전달받으면 프론트에서는 A1이라는 코드를 상품문의라는 텍스트로 변경하는 작업이 필요하다.

백엔드에서는 ‘코드값을 줬으니 우리 업무는 다 했다’며 ‘프론트에서 코드에 맞춰 텍스트로 변환해서 표시하라’고 하고, 반대로 프론트에서는 ‘프론트는 API로 전달받은 값을 뿌리는 게 우리의 업무 영역’이며 ‘API로 값을 전달할 때 A1이라는 코드값이 아니라 상품문의라는 텍스트를 달라’고 요구했다. 정리하면 백엔드는 API로 코드값을 줄 테니 프론트에서 코드값을 텍스트로 변환해서 쓰라는 거였고 프론트는 API로 코드 말고 텍스트값 자체를 달라는 게 서로의 주장이었다.

원론적으로는 프론트 팀의 얘기가 맞다. 그런데 백엔드 팀은 그렇게밖에 줄 수 없는 사정이 있었다. 변경하려면 백엔드뿐만 아니라 연계되는 CRM 시스템까지 건드려야 하니 변경이 어렵고, 우리 시스템을 사용하는 곳들은 다 그런 식으로 사용하니 이번에만 프론트에서 작업해 주면 안 되겠냐고 요청한 것이다. 하지만 프론트 팀은 API로 전달받은 값을 그대로 뿌려주는 게 우리의 업무 롤이니 텍스트로 값을 달라고 요구했다. 한동안 논쟁이 오가다 감정이 격해지자 백엔드와 프론트는 과거의 일까지 끄집어내며 서로를 공격하기 시작했다. 감정 싸움은 2시간 동안 계속됐다.

한국인 개발자였으면 어떻게 해결할 수 있을까?

PM의 권위로 “이번만 프론트에서 해줍시다. 오케?” 라고 찍어 누르거나 개발자를 데리고 담배타임을 가진 다음 “한 번만 해줘 부탁이야” 라고 읍소하면 쉽게 해결할 수 있는 문제다. (학연 지연 흡연이 괜히 있는 얘기가 아니다) 애초에 한국인 개발자라면 저런 문제로 10분 이상 대화하지 않는다.

개발을 하다 보면 이런 이슈가 수시로 발생한다. 이럴 때 한국은 정석이 아닐지라도 가장 빠르고 쉬운 해결 방법을 선택하지만, 외국은 정석적인 해결방법을 우선시하는 경우가 많다. 문화적 차이라고 해야 할까? 순수 오리지널 토종 한국인으로 외국 업체와 소통하다 보면 답답할 때가 한두 번이 아니다.

워라밸 프로젝트가 한창이던 7월의 어느 날. 인도 개발자인 수바시시에게 메일이 한통 왔다.

“님들 저 7월 말부터 2주 동안 여름휴가 떠나요!”

수바시시는 백엔드 팀을 관리하는 총책임자였다. 프로젝트가 한창 진행되는 중요한 시기에 총책임자가 2주 동안 자리를 비우다니. 프로젝트 기간에는 여름휴가는커녕 월차도 제대로 못썼던 나로서는 상당한 컬처쇼크였다. (물론 그들이 정상이고 내가 비정상이다) 그 이후로도 릴레이처럼 개발자들의 여름휴가가 이어졌다. 개발자들은 “여름휴가는 프로젝트 훨씬 이전부터 계획된 것이다. 일정은 회사와 상의해” 라라는 입장이었고 개발사는 “애들 휴가는 안 보낼 수 없잖아. 니들이 이해 좀 해줘” 라는 입장이었다. 결국 개발자들이 여름휴가를 쓴 기간만큼 일정이 딜레이 될 수밖에 없었다.

오픈 대응을 위해 인도 총책임자와 베트남 총책임자가 한국 오피스에 와있을 때였다. 오픈을 이틀 앞둔 월요일 밤. 베트남 총책임자였던 꽁프엉이 돌연 귀국을 선언했다. 다급해 보이는 꽁프엉의 표정에서, 우리는 큰일이 일어났음을 직감했다. 부모님이 위독하신가? 무슨 사고가 났나? 조심스럽게 꽁프엉에게 이유를 물었다.

“내일 아들 유치원 학예회가 있어요. 급해요 빨리 가봐야 해요!”

그날은 PM이었던 부장님의 10번째 결혼기념일이었다.

외국의 워라밸은 우리나라와 개념이 좀 다르다. 우리나라의 워라밸이 칼퇴 라면 외국은 나의 생활과 가족이 회사보다 우선 이라는 게 기본 개념이다. 회사에 아무리 위급한 일이 있더라도 ‘그건 회사의 문제지 나의 문제는 아니고 내 생활이 먼저’라는 마인드가 기저에 깔려있다. 부장님은 ‘놀 거 다 놀고 챙길 거 다 챙기면 일은 언제 하냐’며 분노했지만, 꽁프엉은 아랑곳하지 않고 출국을 감행했다. 우리나라라면? 상상도 못 할 일이다.

우리나라에서 개발자란 5분 대기조에 가깝다. 문제가 생기면 휴일이라도 가장 먼저 달려가는 것이 개발자다. 한국 개발자와 외국 개발자는 마인드 자체가 다르다. 나는 우리나라 문화가 옳다고 생각하지 않는다. 우리나라의 개발 문화는 분명 잘못되었다. 하지만 일개 작업자가 아니라 프로젝트 매니저 입장에서 전화 한 통이면 언제든지 문제를 해결해 주는 한국 개발자와 일보다 개인의 생활이 우선인 외국 개발자를 선택하라고 하면 누구를 택해야 할까?

월계약과 타임슬럿 한국에서 외주 개발 의뢰 시 M/M(Man/Month, 한 사람이 한 달간 일해야 하는 범위)에 기반한 고정금액계약(Fixed-price contracts)방식을 주로 사용한다. 그런데 인도 업체는 시간자재계약(Time & materials contracts)을 요구했다. 인도에서는 시간자재계약이 일반적이라는 게 그 이유였다. (시간자재계약은 책에서만 봤지 실제로 해본 건 이번이 처음이었다)

※ 용어설명

● 고정금액계약

프로젝트에 투입한 인원만큼 월비용을 지급하는 방식, 3명을 투입하면 정해진 3명분의 월 인건비를 매달 지급 한다.

● 시간자재계약

프로젝트에 투입한 시간만큼 비용을 정산하는 방식. 시간당 비용 * 업무시간 을 계산해 비용 지급

우리나라에서 시간자재계약을 안 쓰는 이유가 두 가지 있다. 회사는 연단위로 프로젝트 예산을 계획하고 집행하기 때문에 정해진 예산 이외의 비용을 쓸 수 없어 고정금액계약을 선호하고,또 시간자재계약을 쓰려면 프로젝트에 투입한 시간을 산출해야 하는데 이를 산출하는 것도 어렵거니와 그 자체가 업무 부담이기 때문에 계약부서에서 고정금액계약을 선호하기도 한다.

어쨌든 인도 업체의 요청대로 시간자재계약으로 계약을 진행했는데, 그때부터 다른 프로젝트에서는 신경쓰지 않았던 것들이 하나둘씩 거슬리기 시작했다.

인도 개발자들은 항상 단체로 회의에 참석했다. 일반적인 개발자들은 회의를 그다지 좋아하지 않는다. 평소 같았으면 ‘프로젝트에 관심이 많나?’ 라고 생각하고 말겠지만 시간 단위로 돈이 나간다고 생각하니 갑자기 돈이 아까워지기 시작했다. ‘저것들이 개발은 안 하고 왜 단체로 회의에 들어오는 거야? 회의마다 다 들어오면 개발은 언제 하는 거야? 회의참석한다고 하고 농땡이 피우면서 돈 받아 가는 거 아냐? (화상회의였다)’라며 개발자들을 의심하기 시작했다. 개발 진척은 더딘데 회의에 우르르 몰려와서 농담 따먹기 하는 모습을 볼 때마다 짜증이 솟구쳤다. 안부 인사나 스몰토크도 달갑지 않았다. 한두 시간씩 업무 범위를 놓고 서로 말싸움 벌일 때마다 현타를 느꼈다. ‘아 오늘도 저 쓸데없는 감정싸움에 200달러를 소모했어. 외화가 마구 유출되고 있구나’ 같은...

문제는 또 있었다. 인도 개발자들은 인도 현지에서 개발을 진행하고 총괄 책임자인 수바시시만 한 달에 한 번 정도 한국을 왔다 갔다 하며 진척상황을 보고했다. 두 달 정도 지났을 때부터 의심이 스멀스멀 올라오기 시작했다. 투입되는 인원 대비 퍼포먼스가 너무 안 나왔기 때문이었다. ‘5명이나 투입했는데 개발을 이 정도밖에 못했다고? 이것들이 3명 투입해 놓고 5명이라고 사기 치는 거 아냐? 사무실에서 농땡이 치면서 돈만 받아 가는 거 아냐?’ 라고 개발자들을 의심하기 시작했다. 비상주라 일을 하는지 안 하는지 눈으로 확인할 방법이 없으니 검증을 위해 개발자와 함께 소스를 하나하나 까보기 시작했다. 이쯤 되면 서로에 대한 신뢰는 무너진 거나 다름없다.

사실 이건 인도뿐만 아니라 국내에서 비상주 외주 개발자를 써도 동일하게 일어날 수 있는 문제다. 하지만 국내 개발자들은 통제를 벗어났다고 생각될 때 대응 방법이 있다. 우리 회사의 관리자(감시자)가 그쪽 회사로 파견을 가서 업무를 점검하거나, 반대로 개발자를 우리 회사에 상주시키거나 하는 식으로 업무를 체크할 수 있다. 하지만 외국 개발자는 그게 어렵다. 인도나 베트남 업체에 개발을 맡겼는데 개발사가 일을 제대로 하지 않는 것 같다는 생각이 들 때, 당신이 관리자라면 어떻게 대응할 수 있을까?

니가 보는 문서와 내가 보는 문서가 달라? 요즘은 기획서를 PPT로 그리지 않고 피그마로 그리는 추세다. 당연히 우리도 피그마로 기획서 작업을 하고 있었는데 인도와 베트남 개발자들이 W/F(Wire Frame, 화면설계서)을 요구했다. (백엔드는 그렇다 쳐도 프론트는 왜???) 결국 열심히 피그마를 만들어놓고 개발자용 W/F을 또 만들어야 했다.

필드에서 피그마를 선호하는 이유는 실시간 업데이트와 버전 관리가 용이하기 때문이다. PPT로 W/F을 만들면 수정사항이 생길 때마다 문서를 배포하고 내가 보는 문서와 작업자들이 보는 문서가 동일한지 항상 체크해야 한다. 피그마는 실시간 업데이트가 되기 때문에 내가 보고 있는 디자인과 작업자가 보고 있는 디자인이 다를 수 없다. 별도의 버전 관리가 필요 없다는 것. 이건 기획자 입장에서 큰 장점이 된다.

기껏 피그마로 디자인과 기획을 해놓고 개발자용으로 W/F을 또 만들면 문서를 두벌 관리해야 한다. 작업물이 분산되어 있으면 작업물 간의 싱크를 맞추는 게 중요하다. 디자인은 A로 되어 있는데 W/F은 AB로 되어 있으면 작업자 입장에서 어느 쪽이 맞는지 알기 어렵다. 그래서 디자인과 W/F이 항상 일치하도록 싱크를 맞춰줘야 한다.

문제는 또 있다. 피그마는 실시간으로 업데이트가 되니까 내가 무언가를 수정했을 때 피그마에 “수정사항 업데이트 해놨습니다. 확인해 보세요” 하면 끝날 일이지만 PPT로 W/F을 만들면 문서를 업데이트한 후 작업자들에게 배포해야 한다. 이 과정에서 로스가 많이 발생한다. 작업자들이 메일을 제대로 확인하지 않는다거나 문서 버전 관리를 제대로 못한다거나 귀찮다거나 하는 이유로 내가 보낸 최종버전은 0.9 버전인데 개발자들은 0.8 버전을 보고 작업하는 경우가 종종 생기는 거다.

기획은 특히 애자일로 작업한다고 하면 작업 중에 빈번한 수정사항이 발생한다. 버전 관리가 안 되는 것, 문서 싱크가 안 맞는 것. 이건 같은 말을 쓰는 한국 개발자들과도 일하면서도 동일하게 생기는 문제 중 하나다. 문제는 외국 개발자는 물리적 거리가 떨어져 있으니 그게 더 심하다는 것. 거리와 소통의 문제 생각보다 중요하다. 괜히 ZOOM CEO가 재택 때려치우고 출근하라고 직원들에게 강요하는 게 아니다. 멀리 있으면 소통이 상당히 어렵다.

최신기술과 호환성 우여곡절 끝에 개발을 마치고 테스트가 시작되었다.

기능도 잘 돌아가고 이제 다 끝났구나 하고 안도의 한숨을 내쉬던 찰나, 멀리서 사장님의 목소리가 들려왔다.

“이거 테이블이 깨지는데?”

사장님이 깨진다는 부분을 확인해 보니 내 컴퓨터에서는 멀쩡했다. 이럴 땐 보통 둘 중 하나다. 남아있던 쿠키를 삭제하지 않아 CSS가 꼬였든지 CSS에 호환성 문제가 있든지. 퍼블리싱팀에 원인을 확인해 달라고 했더니 잠시 후 의외의 답이 돌아왔다.

퍼블리싱팀 : “프론트 개발자들이 CSS를 최신 버전으로 썼네요. 이게 구버전 브라우저에서 호환성 문제가 좀 있는데 사장님이 쓰시는 맥북의 구버전 사파리에서는 이 CSS가 안 먹어요.”

사파리 브라우저는 특정 CSS의 경우 14.1 버전부터 지원되는 경우가 종종 있다.

문제를 정리하면 이런 거다. 사장님의 꼬물 맥북은 업데이트가 종료되어 사파리 14.1 버전 업데이트가 안되는데, 이 CSS는 사파리 14.1 버전 이후로만 적용 가능해서 사장님이 보는 화면으로는 CSS가 깨진다.

경험이 많은 퍼블리싱 팀장님은 이 문제를 잘 알고 있었다. 그래서 퍼블리싱을 할 때 호환성이 좋게 살짝 낮은 버전으로 코딩을 해줬는데 개발자들이 지네 맘대로 소스를 최신 버전으로 바꾼 것이다. 개발자들에게 변경 요청을 했더니 이런 답이 돌아왔다.

“우리는 개발할 때 최신 기술을 쓰는 게 원칙이야. 지원이 종료된 구버전 브라우저까지 우리가 왜 신경 써야 됨?”

너무 맞는 얘기라 할 말을 잃었다. 해당 사파리 브라우저를 쓰는 사람은 전체 유저의 0.17% 였기 때문이다. 0.17%를 위해 최신버전을 포기하고 구버전을 쓴다는 건 납득하기 힘든 일일 수 있다. 그런데 기획자 입장은 좀 다르다.

프로젝트를 진행하다 보면 이런 호환성 이슈가 간혹 튀어나온다. 위 사례 같은 경우 문제를 제기한 사람이 QA팀이거나 직급이 낮다면 좋게 좋게 말로 해결할 수 있다. “0.17%니까 우리는 무시해. 지원 종료된 구형 맥북 쓰는 건 자기 문제잖아. 오케? 에러 아닌 걸로 처리합시다.” 이런 식으로 말이다. 그런데 높으신 분일 경우 이런 방법이 통하지 않는다. “0.17%라고 소수라고 무시하는 게 맞냐? 서비스를 만드는 사람의 자세가 그게 맞냐? 앞으로도 그렇게 소수 인원은 계속 버릴 거야?” 같은 논리를 들이밀면 할 말이 없어진다.

베트남 개발자들에게 ‘보스 이슈’를 얘기했더니 이해할 수 없다는 표정을 지으며 이렇게 말했다.

“그건 너네 보스 문제니까 너네 보스가 맥북을 바꾸면 되는 문제 아님? 왜 그것 때문에 소스를 바꿔야 됨?” 역시나 너무 맞는 말이라 할 말을 잃었다.

한국 개발자였다면 이건 이슈 거리도 안될 문제였다. 이런 이런 문제가 있으니 해결 좀 부탁한다고 하면 개발자들은 대부분 군말 없이 해결해 주는 편이다. 높으신 분 이슈에 대해서 개발자들이 가장 잘 알고 있기 때문이다. 몇 년 전까지 IE8을 지원했던 우리 입장에서 이런 건 당연한 문제지만 해외 개발자들은 이런 정서상의 문제를 이해하지 못한다. 한국 개발자였다면 한 시간도 안 걸려서 해결할 문제를 베트남 개발자와는 하루 종일 옥신각신하면서도 합의점을 찾지 못했다.

그래서 어떻게 했냐고? 극악 처방으로 사장님께 그대로 보고했다. “베트남 개발자들이 최신기술을 쓴다고 0.17%는 무시하라는데요? 수정 못해주겠답니다.” 사장님도 얼굴이 벌게졌지만 곧 수긍할 수밖에 없었다. 모두의 반대를 물리치고 비용이 저렴하다는 이유로 해외 개발자를 컨택한 것이 본인이었기 때문이다.

주방을 맡기시겠어요? 우리 프로젝트가 너무 극단적인 케이스일 수도 있고 너무 안 좋은 면만 부각한 걸 수도 있다.

십 년 넘게 이 업계에 있으면서 인도 개발자 3번, 베트남 개발자 2번, 파키스탄 개발자 1번, 총 6번의 협업을 경험했다. 해외 취업을 한다면 모를까. 앞으로 내 인생에 외국 개발자와 협업은 없을 것 같다.

물론 나와 함께 협업했던 친구들은 능력도 있고 성격도 좋은 친구들이었다. 프론트엔드 팀장이었던 꽁프엉은 베트남 최고 명문대라는 하노이 국립대학 출신이었고 백엔드 팀장인 수바시시 역시 인도 최고 명문이라는 인도공과대학(IIT) 출신이었다. 프로젝트에서 발생했던 문제들은 능력 부족보다는 거리가 떨어져 있어서 발생하는 소통의 문제와 문화적 차이에서 생기는 생각의 차이가 대부분이었다. (물론 이게 상당히 큰 이슈이긴 하다)

외국인 개발자와 협업을 꺼리는 이유는 기획자 입장에서 소통과 문화적 차이에서 오는 스트레스가 굉장히 크기 때문이다. 말 통하는 한국인 개발자와 작업할 때도 신경 써야 할 것도 챙겨야 할 것도 많은데 외국 개발자들은 오죽할까. 한국 개발자라면 말 한마디로 끝낼 수 있는 일을 소통이 원활하지 않아 문서를 만들고, 한국 개발자라면 한 시간 만에 끝낼 일을 하루 넘게 걸려 처리하는 일도 비일비재했다.

프로젝트에 투입되기 전, 본부장님은 나와 PM님에게 해외 개발자와 협업하면서 생기는 로스(loss)에 대해 기록해 달라는 특명을 내렸다. 프로젝트 종료 후 본부장님, 나, PM 셋이 모여서 한국인 개발자를 썼을 때 비용과 해외 개발자를 썼을 때 비용을 비교했다. 결론은 해외 개발자를 썼을 때 한국인 개발자보다 5~8% 정도 저렴하다는 계산이 나왔다. 통역 및 번역 비용, 소통으로 인한 시간 손해와 일정 딜레이, 그에 따른 신규 개발자 투입 비용 등 이래저래 고려하면 외국인 개발자를 쓴다고 해서 비용이 획기적으로 줄어드는 게 아니라는 얘기다.

지인들 중 나에게 이런 고민을 토로하는 사람이 가끔 있다.

“한국 개발자는 너무 비싼데 해외 개발자를 어때? 괜찮아?”

그럴 때 나는 이렇게 대답한다.

서점군 : 네가 식당을 창업했어. 음식은 주방장이 하고 너는 서빙을 해. 근데 주방장이 외국인이야. 어떨 것 같아?

지인 : 하 그건 좀 곤란한데... 말이 잘 통할까?

서점군 : 식당은 곤란하고 개발은 괜찮아? 개발을 외국인 개발자에게 맡긴다는 건 음식점이 주방을 통째로 외부 사람에게 맡긴다는 거랑 같은데?

“개발 인력 부족, 상위 10%의 베트남 개발자로 해결하세요!” “한국 개발자 연봉의 30% 수준. 숙련된 인도, 베트남 개발자가 당신의 사업을 함께합니다.”

아직도 이런 광고에 관심이 가는가? 나는 이런 광고를 절대 믿지 않는다.

10년 전쯤 중국 길림성과 요녕성쪽 개발자가 굉장히 핫했던 시절이 있었다. 10년이 지난 현재 콘텐츠 관리나 모니터링 같은 단순 작업은 중국에 외주를 주거나 현지 센터를 운영하는 경우가 있으나, 중국 개발자를 채용하거나 중국에 외주를 주는 경우는 거의 없다. 그때도 우스갯 소리로 “야 이제 우리도 중국인들한테 밀려서 새벽에 인력 시장 나가서 자바 2명이요 하면 허겁지겁 봉고 타야 되는 거 아냐?” 하는 말을 하는 개발자도 있었지만 아무도 그 말을 진지하게 듣지 않았다. 해외 개발자를 쓴다는 게 어떤 리스크가 있는지, 한국 개발자는 왜 대체되기 어려운지 본인들이 가장 잘 알고 있기 때문이다. 그리고 이건 현재 진행형이기도 하다. 우리는 최소한 Chat GPT 때문에 책상이 없어질 걱정은 해도 해외 개발자들에게 밥그릇 뺏길 걱정은 안 한다.

그래도 못 믿겠다고? 그렇다면 직접 찍먹해보시길...

※ 다시 한 번 말하지만 실화 아님. 소설임.