해외 개발자 협업 가이드 101(2): 협업 실전편
지난 글이 원론적인 부분들을 다뤘다면, 이번 글은 채용 이후 실제 협업에 대해 다룹니다.
May 21, 2024
지난 글을 못보신 분이라면 먼저 1편부터 읽어주세요.
드디어 무사히 외국인 개발자를 채용했습니다. 무엇부터 시작해야 할까요? 실제로 협업하면서 맞닥뜨리는 상황들에 우리는 어떻게 대처해야 할까요?
무사히 온보딩 마치기
해외 개발자 채용 후 당연히 가장 먼저 해야할 일은 온보딩입니다. 온보딩 과정에서 중요한 것은 R&R에 대한 합의를 하고, 기본적인 협업 구조를 세팅하는 것입니다.
킥오프 미팅 갖기
- 회사가 하는 일 소개
- 회사의 사업과 목표를 개발자에게 인지시킵니다. 소통에 빈 틈이 생겼을 때, 큰 틀에서의 맥락 이해에 도움을 줄 수 있습니다.
- 팀원 소개 및 협업 구조 설명
- 전반적인 팀 구성 설명과 직접적으로 협업하게 될 팀원들을 소개합니다. 하루 일과를 설명하고 공유나 보고 체계를 설명합니다.
- R&R 설명
- 개발자가 담당해야할 역할과 책임에 대해 설명합니다.
- 커뮤니케이션 방법 설명
- 주로 소통은 어떤 채널을 통해서 하는지 설명합니다. 회사가 사용하는 협업 툴을 소개합니다.( e.g. 슬랙, 노션, JIRA 등)
자료 공유
개발시 사용하게 될 툴, 언어, 코드 컨벤션, 소스 코드, 개발 가이드 문서, 기획서, 디자인 문서 등을 공유합니다. 첫 1~2주 정도는 충분히 기존 자료들을 팔로업할 수 있는 시간을 주는 것이 좋습니다.
또한 모든 자료가 번역되어있을 필요는 없습니다. 처음부터 100% 이해를 하는 것이 목적이 아니기 때문에, DeepL 등 번역 툴을 써서 자체적으로 번역을 해서 보라고 해도 괜찮습니다. 번역 퀄리티가 꽤 높기 때문에, 90% 이상의 내용은 이해 가능합니다.
주기적인 콜 및 공유 체계 구축하기
앞선 글에서 설명을 드렸듯이, 원격 협업일수록 빈번하게 소통을 하고 이슈 공유를 해서 신뢰 관계를 구축하고 같은 목표를 향해 달려나가게 하는 것이 중요합니다.
- 데일리 스크럼/데일리 콜: 정기적으로 콜을 잡는 것은 소속감과 긴장감을 유지하는 차원에서도 중요합니다. 매일 각자 어떤 일을 하고 있는지(In progress), 어떤 일을 할 것인지(To-do), 어떤 일을 했는지(Done) 공유합니다. 각자 당면한 이슈도 공유해서, 개인의 리소스를 활용해서 해결할 수 없다면 함께 이슈를 해결해줍니다.
- 사소한 것도 질문할 수 있도록 하기: 간과될 수 있지만 정말 중요한 부분입니다. 성격에 따라 사소한 것을 질문하는 것을 많이 망설일 수 있습니다. 이런 부분들이 쌓이면 실무자가 매니저가 기대하는 것과 다른 결과물을 생산해내게 됩니다. 사소한 것도 질문하게 하려면 매니저의 역할이 정말 중요한데요. 계속해서 쉽게 질문할 수 있게끔 이런 것들도 퍼포먼스를 판단하지 않는다는 믿음을 주고, 지속적으로 유도해야 합니다. 만약 이미 제공한 자료에서 확인할 수 있는 사항이라 하더라도, 모든 자료를 100% 검토할 수 없다는 것을 인지하고 인내심을 가져야 합니다.
첫 태스크 맡기기
초기 온보딩이 끝났다면, 이제 드디어 실무를 시작할 차례입니다.
작고, 쉽고, 독립적인 것부터
외국인 개발자가 함께 일을 한지 조금 시간이 지났다고는 하지만 아직 완벽히 모든 사항들에 파악한 것은 아닙니다. 이럴 때 큰 업무를 맡기게 되면 코드가 꼬이는 등 예상치 못한 Side effect가 발생할 확률이 높습니다.
따라서 다른 기능과 크게 연동되어 있지 않은, 쉽게 해결할 수 있는 단순한 업무부터 맡겨야 합니다. 이러한 업무에 익숙해고 나서 천천히 다른 팀원과 협업이 필요한, 복잡한 개발로 나아가면 됩니다.
*만약 기존에 개발된 내역이 없는 새로운 프로젝트에 해외 개발자를 투입하는 상황이라면 이런 부분을 많이 고려할 필요는 없습니다.
피드백 주기
외국인 개발자가 실무를 마쳤다면, 이에 대해서 피드백을 반드시 줘야 합니다. 매니저가 실무를 하다 보면 바빠서 태스크 수행 내역을 리뷰하지 못하는 경우들이 생길 수 있습니다. 이런 경우 나중에 확인을 해보면, 생각한 것과 전혀 다른 방향으로 가있을 가능성이 있습니다. 이 경우 1차적 원인이 실무자가 아닌 매니저에게 있습니다.
피드백을 줄 때 단순히 이 부분이 잘못되었다고 얘기하는 것이 아니라, 잘못 수행한 부분에 대해서는 기존 레거시 코드를 미처 파악하지 못해서 생긴 이슈인지, 태스크가 분명하게 전달되지 않아 생긴 이슈인지 등 철저히 원인 파악을 해야합니다.
충분한 시간과 기회주기
개발자가 제대로된 퍼포먼스를 내기까지 1~2달은 필요합니다. 흔한 실수 중 하나는 너무 즉각적인 퍼포먼스를 원한다는 것입니다. 정말 개발자의 실력 자체가 낮다면 당연히 문제가 되겠지만, 특히 초반일수록 퍼포먼스는 그외의 요인들로 인해 영향을 받는 경우가 많습니다.
흔하게 발생할 수 있는 오해의 케이스들을 몇가지 나열해보겠습니다.
- 쉬운 일인데 왜 아직도 해결 못했지?
일의 난이도를 잘못 생각했을 가능성이 있습니다. 이미 프로세스에 익숙하고 레거시를 다 파악하고 있는 입장에서는 쉬운 일이겠지만, 새로 투입된 개발자의 입장에서는 어려운 일일 수 있습니다.
- 사이드 이펙트가 발생했는데, 실력에 문제 있는 것 아닌가?
레거시 코드를 100% 다 파악하기 어렵기 때문에 초반에 충분히 일어날 수 있는 일입니다. 작은 태스크부터 주기, 개발용 서버를 구축하기, 코드 병합 권한을 매니저가 가져가기 등의 방안을 통해 방지할 수 있습니다.
- 왜 메시지를 보냈는데 답장이 없지?
생각보다 많은 개발자들은 문제 해결에 집중하고 있을 때 메시지를 잘 보지 않는 경향이 있습니다. 집중을 해치지 않는 선에서 메시지를 확인하길 권유하고, 실제 결과물을 통해 퍼포먼스를 측정해야 합니다.
- 코드를 왜 이렇게 짰지?
개발자 각자의 코딩 스타일이 있고, 상황에 따라 최적화된 코드 구조는 다를 수 있습니다. 코드 리뷰 과정에서 이야기를 나누고, 팀의 코드 컨벤션을 함께 만들어 나가는 것이 중요합니다.
한국인 팀원들의 마음 열기
개발의 특성상 다른 개발 팀원, PM, 디자이너 등과 소통해야 할 일이 많을 수 있습니다. 만약 나머지 팀원들이 외국인 개발자와 소통하는 것을 불필요하거나 불편하게 느낀다면 외국인 개발자의 퍼포먼스는 제한될 수밖에 없습니다.
마음을 여는데 몇가지 도움이 될 수 있는 방안들은 다음과 같습니다.
One of us
외국인 개발자가 외부 프리랜서가 아니라 한 명의 팀원으로 인식되게 하기
더 큰 목표의 일환
우리 회사가 외국인 개발자 채용을 한 것이 단순히 비용 절감이 목표가 아니라, 글로벌 조직 문화 및 리모트 협업 문화를 구축함에 있다는 것을 강조
나에게도 도움이 되는 일
점차 모든 조직은 외국인들과 협업을 해야할 가능성이 높기 때문에, 이러한 부분들을 미리 경험하고 전문성을 습득하는 것이 나머지 팀원에게도 좋은 경험과 능력치가 될 수 있다는 것을 어필
그래도 안 맞다면?
충분한 시간을 주었음에도 불구하고 이슈들이 해결이 안되고 반복된다면 다른 해외 개발자를 채용하는 것을 고려해볼 수 있습니다. 해외 개발자 채용의 장점 중 하나가 바로 고용 유연성이 확보된다는 것입니다. 또한 풀이 넓기 때문에, HR에 충분한 시간을 쏟을 수만 있다면 좋은 개발자를 확보할 수 있습니다.
해외 개발자 협업, 하이퍼하이어와 함께하기
해외 개발자 채용부터 실제 협업까지, 모든 과정을 아직 경험이 부족한 내부 인력의 리소스만 활용하는 것보다 외부 전문가 집단을 활용하는 것이 효과적일 수 있습니다. 하이퍼하이어는 단순히 해외 개발자 채용을 도와줄 뿐 아니라, 한국인 PM을 지원하여 실제 협업을 매끄럽게 도와줄 수 있습니다. 또한 각종 법률 및 인사 리스크, 고용 유연성 확보도 제공합니다.
Share article
뉴스레터 구독하고 IT & 글로벌 최신 트랜드 정보를 받아보세요!
