해외 프로젝트로 들어간 계기

필자가 대학교 3학년 시절, 해외(일본)의 메타버스 관련 사이드 프로젝트를 한 적이 있었다.
이 포스트에서는 가입 1주년을 맞아 필자가 겪었던 것들을 정리하고, 나는 어떻게 나아갈지 정리하려 한다.

당시의 나는 누구였는가

대학생이자 직장인...이라고?

• 그 누구도 납득을 못하지만, 나는 당시도, 지금도 학생이자 직장인이다.
• 명함있는 대학생... 쉽지않을 것이다.
• 중소게임 회사에서 모바일 게임 프로젝트의 부활과 라이브 서비스중인 게임의 기능추가및 QA를 담당했었고, 스택은 PHP/NodeJS + PostgreSQL + VanillaJS + ... 역시 스타트업이라 아무거나 다했다.
• 그래서 그런지, 나는 내가 만든 것에 최대한 자신감을 가지기 위해서 다른 사람들과 만나는 것을 좋아하고, 새로운 것을 공유하는 것을 좋아했다.
• 그래서, 나는 외연확장을 통해서 다른 개발자도 만나보고 SNS도 하면서 각종 개발지식을 습득해나가는, 약간 욕심쟁이식 학습을 해왔다.
• 오늘 소개할 이 프로젝트도 그러한 성격의 발현이라 생각하며, 오늘의 포스트를 시작하려 한다.

  참고로, 이 팀을 지나온 이후, 나는 데이터 엔지니어로서의 생각이 깊어졌다. 가능하다면, 해보고싶다. 어떻게든.

Ps. 일본어는 어떻게 배웠는지?

• 사실 별로 공부는 안했고 심심해서 시험쳤더니 JLPT N2가 나왔다.
• 중학생때 한자 공부를 조금 했고, 철도에 관심이 많아 일본어를 배웠던게 이런 영역으로 나가게 된 것 같다.

어떤 상황이었는가?

• VRChat은 유저가 직접 C# 스크립트를 짜서 월드를 만들어 업로드하는 VR 메타버스 게임이다.
• 다만, 이 스크립트중 대부분은 허용되는 것들만 사용가능하다.
• 그래도 그것들만을 써서 여러 월드의 UI디자인을 할 수 있다는게 특징이었지만, 그 중 http 통신은 사실상 불가능했었다. *(아주 편법으론 됬었지만, 진짜 이건 편법이라서 꺼려했다...)
• 내가 지원했던 2023년 봄즈음에는 StringLoader라는 기능의 추가로 VRChat 월드 내에서 Http client를 사용한 API 서버를 만들 수 있지 않을까? 하는 생각이 딱 들었던 시기였다.
• 이 StringLoader는 HTTP client를 Unity단에서 지원해주는 기능으로서, 이제는 유저 내 메타버스 월드에서 HTTP 통신으로 외부의 자원을 가져올 수 있는 시대였기 때문이다!
• 그와중에 나는 트위터를 밀어보다가, 일본에서도 동일한 생각을 하던 프로젝트 팀이 있다는 사실을 알게 되었다.
• 나는 한번 해보자!라는 마음으로 한번 지원을 하게 되었다.
• 그것도 있고, 사실 나는 (Mobile Game 개발자임에도 불구하고!) Unity개발자라기 보단 PHP/Node.js + PostgreSQL개발자였기 때문에, 사실 Unity쪽을 잘 아는사람과의 협업이 좀 필요했었다고 생각했었다.

흥미를 위해서 지원했던 프로젝트

• 사실 나는, 이 프로젝트에 지원했을때, 흠... 하면서 지원을 해봤었다.
• 사실 내심 붙으면 좋겠다 생각하면서 github에 있던 개인서버의 readme에 일본어를 살짝 넣었었다.
• 그랬더니, 그냥 면담한번 가볍게하고 붙었는데, 아래 나올 부팀장이 여러 고민을 했던 것 같지만, 그래도 팀장이 좋게 봐줬는지 들여보내줬다.

어떤 조직이었는가.

미리 말해두자면, 일본에서의 메타버스는 VRChat/Cluster같은 게임쪽이 많다고 보인다.

• 일단 처음에 설명을 듣기로는, VRChat위에서 동작하는 Web기반 통신(http이다.)을 사용한 기믹을 제작하고 수익을 챙기는 팀. 이라고 했었다.
• 따라서 그러므로, 웹 기반 스타트업을 할 것 이니 오픈소스와는 다르다 라는 답을 얻긴 했는데... 사실 그냥 할거없기도 해서 받았었던 기억이 난다.
• 그리고 2024년 현재, IBM 일본에 있던 팀장이 퇴사하고 스타트업을 차렸다. 아마 생각보다 빡센 여정이 될지도 모르겠다.

팀의 배정과 문화 적응

개발팀? 데이터팀? 애매한 배정

• 처음에는 개발팀 매니저로부터 개발팀으로 배정받는다는 이야기를 들었는...데, 당일 디스코드를 했던 부조직장이 와서 데이터팀에 오지 않을 것인지?라고 물어봤다.
• 사실 별 생각없이 승인했던 기억이 난다. 내가 공부하는 것도 당시에는 데이터사이언스였고, 인공지능에 관심이 많아서 그랬다.
• 이후 나는 개발과 데이터팀을 동시에 배정받고, 개발 프로젝트를 진행했다.

VCAP에서의 첫 개발

• 나는 이후 첫 업무를 맡게 되었다.
• 일단은, 아래에 있는 내 태스크부터 맡았는데, 이건 생각보다 빨리 끝나서 vket 2023 summer를 위한 다른 기믹의 지원을 담당하게 되었다.
• chat GPT 관련 버그 찾아서 고치기, 즉 버그사냥(나는 이렇게 부르지만...)을 진행한 적이 있었다.
• 이때 나는 소스 코드상의 버그를 찾았는데, 당시 나의 적극성 부족으로 의견을 제시하지 못 한게 아쉬웠다.
• 결국에는 소스코드를 짜신 분이 찾아서 수정하셨지만, 내가 도와주었다면 더 빨리 끝났을지도 모르겠다는 생각을 하며 다음에는 의견개진에 있어서 더 용기를 내어보자라는 생각이 들었다.

첫 정모

• 아래의 vket 2023 summer가 끝나고 살짝 어수선할때, 일본여행을 가기로 했다. 아직은 대학생이기도 해서, 패기있게(라기보단 작년에도 2주갔었는데 가는김에 한번에라는 느낌으로) 2주간 일본에 가기로 했다.
• 오사카는 굉장히 가깝다. 특히 한국인 입장에서는 더 그렇고, 많이 가는 도시라서 아예 정감이 갈 지경이다.
• 뭐 어쨋든... 데이터팀 4명이 다 모여서 아라시야마 정모를 갔다가 왔다.
• 다들 처음만나서 그런지 재밌었다. 여행계획 이야기하니까 홋카이도 저 멀리 깊은곳 가는거 듣고 놀랐었던 모양이다.
• 그리고 회식을 했다. 일단 회 맛있었고, 미래에 관한 이야기를 들었다.
• 데이터 엔지니어에 관한 이야기는 사실 거기서 처음 들었던 기억이 났고, 내 방황하던 꿈을 어느정도 정리하던 자리가 되지않았나 싶다.

개발 -> 인프라팀으로의 이전

• 그렇게 일본에서 돌아오고 조금 있다가, 정식 출시에 앞서서 인프라팀을 모집한다길래 지원했다.
• DB관련해서 목소리를 낼 수 있을 것 같아서 일단 지원을 했고, 실제로 인프라(기반개발)팀이 되었다.

  여기서 인프라팀은 베이스가 되는 스크립트 개발을 하는 팀을 의미한다.

• 약간의 마찰...이 있기는 했었는데 그리 크지는 않았던 것 같다.
• 특히, 서로서로 어느정도의 양보를 통해서 해결을 했었더니 좋게 나간것 같다.

그리고, 지금.

• 나는 너무 바빴다. 하지만, 이제는 본격적인 출시를 앞두고 있어서, 슬슬 이쪽 일도 다시 진행해 나가려 한다.
• 다른 팀장 산하의 프로젝트로 배정을 받고, 투표 기반 프로젝트를 만드는 것으로 방향을 나아가고 있다.
• 언젠가 출시를 하면, 어딘가 올라가지 않을까 싶다.

어떤 프로젝트를 하였는가?

• 일본의 스타트업에서 기여했다고만 기술하겠다.
• 다만, 여러 사유로 공개할 수 없는 일이 있어서, 보여줄 수 있는 일만 공개한다.
• 사용스택은 대부분 Node.js/Hono, Prisma/Kesely, Unity이다.

Vket 2023 Summer booth

첫번째 개발, Vket 2023 Summer

미리 말해두자면, 나는 여름이랑 연이 깊을지도 모른다.
여름이 생일이고 여름에 첫 프로젝트를 했고...

• 나는 개발/데이터 팀에 배정받고 난 이후, 첫 개발로서 Hikky라는 회사에서 주관하는 Vket 2023 Summer 이벤트의 부스 기믹 개발자로 태스크를 맡았다.
• 일단 밝힐 수 있는 내용만 이야기하자면, 커뮤니티 부스에서 QvPen이라는 기믹의 외부 save-load 시스템 구축의 일부를 담당했었다.
• DB설계/통신 설계등이 그 대상이었다.
• 이 과정에서, 메타버스상에서 언급되는 여러 윤리적 문제들(음란성 게시글, 불쾌감을 주는 그림...)을 겪어보고, 이를 위한 대응책을 생각해 볼 수 있었다고 생각한다.

메타버스상의 설문조사

세상은 아직 불편한게 있을지도.

설문조사 기믹의 제작

• VRChat상에서 이벤트들을 하다보면, 이벤트를 하고 난 다음 웹으로 유인해서 고글을 벗기고 설문조사를 시켰다.
• 그게 불편해서, 우리는 고글을 벗지 않아도 설문조사가 되게 하자!라는 신념 아래, 한번에 빠른 속도로 데이터를 전송하는 방식의 설문조사를 만들게 되었다.

일본 내 협업 <CatsUdon>

• 사실 이 프로젝트가 나타나게 된 이유다. 이 스타트업은 VRC를 기반으로 TRPG를 즐겨보자! 라는 주제였다. 상당히 신선한 소재였어서, 꽤 재미있었다고 본다.
• 행사가 하나 있었는데, 만족도 조사를 위한

홍콩-일본 협업을 위한 background working

• avifair이라는 메타버스 기반의 스타트업이 있었는데, 이 스타트업은 메타버스를 주장하며 VR게임과 메타버스의 연결 플랫폼이라는 주제로 전시회를 하는 기업이었다.
• 이 기업체는 사실 내가 어쩌다 찾았는데, 넌 뭐하던 사람이냐길래 어떨결에 설문조사 이야기를 했고, 도입하고 싶다길래 연결을 해서 도입할 수 있게 했었다.
• 사실 연결과정에서, 여러 이벤트를 해보자! 라는 시도가 부팀장/홍보담당자와 했었...지만 결과적으로 설문조사만 하게 되었다.
• 이 과정에서의 의사소통은 모두 영어였다. 오랜만에 영어 스피킹연습해서 재밌던 기억도 난다.
• 언어는 인출을 자주하면 늘어난다고 한다. 앞으로도 더 충돌해보며 영어실력을 늘려야겠다.

분명히 존재하는 문화 차이와 극복

비슷한데 다른 문화

• 사실 솔직히, 한국/일본은 문화의 경우 큰 틀에서 유사성을 가지고 있다.
• 다만, 타인에 대한 관심수준이 살짝 다르다는걸 개인적으로 느끼곤 한다.
• 한국같은 경우는 타인에게 일어난 일에 대해서 관심을 많이 느끼고 표현한다고 생각하는 반면,
• 일본같은 경우는 느끼지만 (사적인 감정에서는) 표현은 과하게 하지 않는 듯하다는 느낌을 받고 있다.
• 다만 이건 한국도 추세에 따라서 바뀌고 있어서, 내가 봤을땐 (최소한 개발자에 한하여서는) 충분히 적응가능할 정도로 좁혀지고 있다고 생각한다.

정보가 아예 업데이트가 안되는 경우

• 이건 아주 간단한 문제였다. 나는 일본에 살지 않아서 일본에서 일어나는 일을 체감하지 못 한다.
• 나는 매일 뉴스를 보고 SNS같은걸 보면서 정보를 빠르게 접하지만, 문제는 이래봤자 지역내 정보는 지역사람이 더 빠르다는 점이다.
• 그러다보니 가끔 나타나는 밈이나(게임업계는 이게 좀 강하다.), 최신 동향에 약하기 떄문에, 나는 겸손하게 받아들이려 하는 자세로 정보를 받아서 이야기하는 타입으로 나서곤 한다.

언어부터가 달라서 말이 안 통하는 경우

• 한국과 일본은 대부분 공통되는 어휘가 많다.
• 그런데, 가끔씩 전혀 다른 의미로 사용되는 어휘가 있다. 예로 들어보겠다.

  愛人(애인, あいじん)
  함국어 : 사랑하는 사람
  일본어 : 불륜 대상자

• 이런, 같은 의미인줄 알고 썼더니 전혀 다른 의미인게 한 두 가지가 아니다.
• 예시는 일부러 극단적인걸 골랐지만, 사실은 S/W개발에서 이런류의 단어 선택 실패가 문제를 일으킨다는 점을 이해하면 좀 큰 문제인것을 알게 된다.
• 따라서 나는, 발화 이전에 이 발언이 어느정도의 문제가 될지 살짝 생각해보고, 동아리인 Freethinkers에서 대화했을때 듣던 그대로 쿠션발언을 통해서 상대방과 대화하는데 있어서 예의를 차림으로서 외국인임에도 불구하고 친절한 사람이 되려 했다.
• 그리고 팀장에게 들어본 나에 대한 평가는, "외국인임에도 불구하고 활발한 적극성을 기반으로 한 유쾌한 사람"이라는 답이었다. 아마 좋은 답이었을지도 모르겠다.

報連相라고 알려진것

報告(보고), 連絡(연락), 相談(상담) 의 첫글자들을 따온 일본의 비지니스 용어이다.

• 나는 일단 해외의 팀원으로서, 일본문화에 익숙하지 않다.
• 오히려 그렇기 때문에, 나는 문화를 받아들이는데 진중했다.
• 로마에 가면 로마법을 따르라는 말이 있듯이, 나는 팀원들과의 대화나 팀의 관찰등으로 그 문화에 동화하고 적응하는데 힘썼다.
• 報連相, 즉 보고/연락/상담은 최소로 하였지만, 그럼에도 불구하고 가능한 한 팀장들과의 대화를 자주하며 진행상황이나 최근의 문제등을 이야기하고 이해할 수 있게 하여, 나에 대한 정보의 불확실성을 제거하고자 노력했던 기억이 난다.

혼자하는 개발과의 차이

• 이건 좀 더 큰 문제이다. 국내 개발에서도 큰 문제를 겪곤 하는 문제이고, 나도 대학 졸업하면 생길 문제라고 받아들이려 한다.

PM, 매니저, 동료개발자... 그리고 의견충돌

• 이 조직은 놀랍게도 40명이나 되는 조직이다. 그래서, 여러 팀이 존재하고 심지어는 변호사, 행정사... 뭐 일본내에서 한가닥 하는것 같은 사람들이 있었다. 솔직히 일본여행하다가 문제생겨도 해결될 것 같다
• 아무튼, 이런 40명의 사람들과 협업하는 과정에서 상당히 많은 시련과 의견충돌, 그리고 해결과정이 있었다.
• 일단 나는 겪어보았던 일을 써보려 한다.

코딩에서의 스타일의 차이

• 요리를 만든다고 치자. 내가 만든 요리가 친구와 만든 요리와 같을 수 있다고 장담할 수 있는가?
• 레시피가 없다면 왠만해서는 못할 것이다. 레시피가 있다고 해도 그게 완전 같은 맛이기도 힘들다.
• 코드의 세계에서는 어것이 어떤 방식으로 문제가 될까.
• 자..좋다. 예시를 보면서 이야기하자. 어느 두 프로그래머가 있다. A와 B가 짠 코드는 각각 아래와 같다.

// A의 코드
const roadFinder = (roads:Road[])=>{
  const roadMap = [];
//...
}

//B의 코드
function road_finder (roads:Array<Road>){
  const road_map:Array<number> = []
  //...
}

• 이 둘의 차이를 알면 당신은 자바스크립트를 배운 것이다. (호이스팅부터 일급객체... 많이 알 것이라 믿는다.)
• 하지만, 이 두개가 맥락없이 혼용되어 있다는 사실에 주목하자.
• 새로들어온 개발자 C는 코드를 쓰려 한다. 그럴려 했더니, C는 혼란스러워하며 이렇게 말했다.

  어디 코드를 따라야 하나요?

• 둘을 보면, 스네이크 케이스, 카멜케이스냐, Array<> 혹은 []이냐... 등 어떻게 코드를 써야할 지 모를 것이다.
• 그래서 보통은, code conversation이라는 규정을 만들고, 이를 강제하기 위해 Lint라는 과정을 거친다.

  💡JS에서 많이 쓰는 Es-Lint는 Lint의 일종이지 그것이 Lint를 의미하지 않는다. C#도 Lint가 있다!

• 우리 회사에는 B를 따랐고, 나는 사실 처음 Nodejs단 코드를 쓸 떄 B 스타일로 썼다.
• 그런데 그렇게 짜니, 팀장이랑 불화가 생겼다.
• 알고보니, 이 팀은 AirBnB를 따르는 A 스타일 코드를 원했고, 나는 그것을 어기고 B 스타일로 짜서 문제가 있었던 것이다.
• 그 이후 나는, 각 팀에 들어와서 코드 작업을 하기전, 코드 규정을 한번 본다.
• 없다면, 다른 코드를 읽어보며 최소한의 코드 일관성을 위해서 가능한 한 코드의 규정을 추정해보고, 최대한 코드의 일관성을 유지하는 방향으로 코드를 짜는 습관을 들이게 되었다.
• 이런 것은, 문화와 같은 것이라, 나는 문화상대주의를 통해서 가능한 한 각 팀의 코드 스타일을 존중해주려고 한다.

Misunderstanding.

사람 살다보면 오해가 있을 수도 있지.
하지만 그걸 해결하는데에는 굉장한 용기가 필요할거야.

• 뭐 언제든, 어느때든 뭘 하다보면 사람 간에 오해가 생길 수 있다고 생각한다.
• 내 생각의 오해 라는 것은, 둘이 잘못된 정보를 가지고 있기에 발생하는 것이라고 생각한다.
• 나는 이것을 해결하기 위해서, 일단 물러나서 어떤 오해를 하는지부터 살피고,
• 둘이 어떤 정보가 문제인지 식별한 다음, 오해를 해소하기 위한 정보를 공유하여 오해를 해결하는 기법을 터득했었다.
• 다만, 정보를 공유하는 과정에서, 쿠션 화법이나, 필요하다면 내가 용기내서 정보 공유를 리드하여 나를 이해시키는 방식으로 더더욱 원만하게 해결하고자 하는 방법도 터득하게 되었다.

So,

• 나는 그러므로, 협응성을 위시할 필요가 있었고, 나는 이 프로젝트를 통해 해외의 40인 규모의 프로젝트를 경험해보았다고 생각한다.
• 하지만, 아직도 어딘가 모자란 감이 있다. 나는 성장을 멈추지 않을 것이고, seeking을 통해서 내 필요한 부분이 무엇인지 찾아보려 할 것이다.
• 다만... 하던일은 다 하려한다. 어차피 재밌는 일이기도 하고, 할만도 해서, 그만 둘 생각은 없다.