안녕하세요! 저는 쿠키런: 마녀의 성 서버를 담당하고 있는 5년 차 게임 서버 개발자 주윤아입니다.이직을 고민하고 계신가요? 새로운 팀에 합류하거나, 전혀 다른 코드베이스에서 일하게 된다는 건 많은 개발자에게 큰 도전으로 다가올 수 있습니다. 저 역시 같은 고민을 했습니다. 전 직장에서는 하나의 프로젝트에 4년 동안 몸 담으며 처음부터 끝까지 모든 과정을 경험했기 때문에, 새로운 환경에서 타인의 코드를 이해하고, 빠르게 적응해 성과를 낼 수 있을지 걱정이 컸습니다.하지만 그런 두려움에도 불구하고, 저는 데브시스터즈에서 1년 동안 두 개의 프로젝트에 참여해 각기 다른 코드베이스를 학습하고, 저의 것으로 만드는 과정을 거쳤습니다. 그 과정에서 크고 작은 기능 구 현과 업데이트를 성공적으로 완료 하며 팀에 완전히 녹아들 수 있었죠.본론에 들어가기 앞서, 첫 번째 팀이 아닌 두 번째 팀인 쿠키런: 마녀의 성 코드베이스 적응 과정에 집중하려고 합니다. 그 이유는, 두 번째 팀에서 경험한 것이 저에게 더욱 큰 도전이었기 때문입니다. 이전 팀에서는 익숙했던 C# 기반의 객체 지향 프로그래밍 언어를 사용했지만, 두 번째 팀에서는 함수형과 객체 지향 멀티 패러다임 언어인 Scala 를 처음 접하게 되었고, 더불어 새로운 아키텍처를 학습해야 했습니다. 또한 당시 혼자서 학습을 해야 했던 특수한 상황이었기에 그 과정은 더욱 까다로웠습니다.이번 글에서는 제가 새로운 코드베이스에 적응하고, 그것을 내 것으로 만드는 과정에서 느꼈던 고민들과 배운 점들을 공유하려 합니다. 이직 후 새로운 팀에 적응하는 것이 막연하게 느껴지는 주니어 개발자들에게 이 글이 작은 도움이 되길 바랍니다.새로운 팀에 합류하면서 낯선 코드 베이스와 프로그래밍 언어를 어떻게 효율적으로 익힐 수 있을지 고민이 컸습니다. 사람 마다 학습 방법이 다르겠지만, 저처럼 정석보다는 꼼수에 의존해온 사람에게는 특히나 공부의 순서를 정하는 것이 어려웠습니다. 제가 정한 학습 흐름은 크게 세 가지 단계로 나눌 수 있었습니다.• 문법 학습 : 새로운 언어의 기본 문법을 익히는 것이 가장 중요했습니다. 이 과정에서 사내에서 모든 스칼라 개발자가 완독했다는 빨간 책이라는 scala 관련 서적을 참고했습니다.• 스칼라로 배우는 함수형 프로그래밍 (제이펍, 2015)• 프레임워크 학습 : 서버 개발을 위해 사용되는 ZIO 프레임워크의 구조와 동작 방식을 파악했습니다.• 상업 코드 분석 : 실무에서 작성된 코드를 분석하고 작은 퀘스트들을 수행하며 경험치를 쌓았습니다.기존에 알고 있던 객체지향 언어들과 달리 새로운 패러다임을 익히는 과정은 고통스럽기도 했지만, 사내 상업 코드를 보며 월급을 받으며 새로운 언어를 학습할 수 있다니, 완전 럭키비키🍀 였습니다.새로운 팀의 코드 아키텍처현재 팀의 코드베이스는 제가 익숙했던 기본 아키텍처와는 달랐습니다. 헥사고날 아키텍처와 도메인 주도 설계(DDD)를 기반으로 한 방식은 개념으로만 알고 있었고, 실제로 적용해 본 적은 없었습니다.처음에는 낯선 함수형 언어와 새로운 아키텍처에 당

안녕하세요, 이번 글에서는 javascript의 Proxy API를 사용해 웹 기반 에서 gRPC 게임 서버와 효과적으로 통신하는 방법을 소개합니다.요즘 웹 서비스들은 통신 방식으로 대부분 REST API를 사용합니다. 하지만 실시간으로 많은 데이터를 주고받아야 하는 게임의 특성상, REST API를 사용하기에는 어려운 부분이 있습니다. 쿠키런: 킹덤을 포함한 데브시스터즈의 여러 게임은 효율적인 통신을 위해 API 프로토콜로 gRPC를 채택하고 있습니다. 아마 gRPC를 처음 들어보시는 분들도 있을 것 같은데요, gRPC의 특징 몇 가지 짚고 가겠습니다.• gRPC는 HTTP/2에 커스텀 헤더를 추가한 프로토콜로 통신합니다.• 메시지 데이터는 protocol buffers(이하 protobuf)를 사용해 바이너리 형태로 직렬화하여 전송합니다.• protobuf를 사용하여 데이터 구조를 정의할 수 있고, code-gen 라이브러리로 스키마에 대응하는 파일과 파일을 생성할 수 있습니다.위의 세 가지 특징으로 의 아키텍처를 아래와 같이 구성했습니다.gRPC에 필요한 커스텀 헤더를 브라우저가 지원하지 않아 로 직접 gRPC 호출을 할 수 없기 때문에 를 프록시 서버로 두어야 합니다.[1] code-gen으로 생성된 파일은 직렬화/역직렬화 로직으로 와 간의 gRPC 통신에 사용되고, 와 간의 통신은 직접 HTTP endpoint를 작성해야 합니다.그런데 이 구조에서는 한가지 문제점이 있습니다. 대부분의 protobuf code-gen 라이브러리가 Node.js 런타임을 대상으로 하기에 FE ↔ BE 통신의 구현체는 code-gen을 활용하지 못하고, gRPC method가 추가될 때마다 REST API의 endpoint를 직접 추가해야 하는 번거로움이 있습니다. 즉, protobuf를 쓰는 이유가 퇴색되고 있던 것입니다.오늘도 어김없이 개발자 김용쿠는 gRPC와 똑같은 REST API를 추가하다 문득 이런 생각이 들었습니다.저 타입처럼 동작하는 브라우저용 구현체를 자동으로 만들 수 없을까?[2]protobuf parser로 직접 FE용 code-gen을 만들어 이 문제를 해결할 수도 있습니다만, 이미 타입 정보가 존재하는데 각 endpoint와 1대1 대응하는 js 코드를 또 만들어야 할까요? 아래의 pseudo code를 상상하며 다음의 목표를 세웠습니다.• JavaScript 구현체와 code-gen으로 생성된 타입을 합쳐, 기존에 BE에서 사용하던 모습 그대로 마치 FE에도 api client 존재하듯 개발자를 속이자• 구현체는 타입 시그니처대로 동작해야 한다• 는 code-gen을 사용하지 않고 런타임에 동적으로 의 함수를 호출하도록 설계하자그런데 어떻게 code-gen 없이 구현체를 만들 수 있을까요? 답은 JavaScript Proxy에서 찾을 수 있습니다.JavaScript의 Proxy는 Reflection과 함께 JavaScript의 meta-programming 기법에 사용하는 API로, 객체의 여러가지 기본 동작을 재정의 할 수

저는 ABC Studio에서 MessagingHub라는 플랫폼 프로젝트를 담당하고 있습니다. MessagingHub는 다양한 비즈니스 요구에 맞춰 엔드 유저를 대상으로 메시징 기능을 제공하는 맞춤형 메시징 플랫폼입니다.아래 그림은 MessagingHub가 Demaecan 서비스의 각 도메인에서 몇 개의 컴포넌트와 연동돼 사용 중인지 나타내고 있습니다(올해 도입 예정인 컴포넌트도 일부 포함돼 있습니다).위 그림을 보며 알 수 있는 사실이 두 가지 있습니다. 하나는 MessagingHub가 플랫폼 프로젝트로서 확장해 나가고 있다는 것이고, 다른 하나는 그에 따라 이해관계자 또한 늘어간다는 것입니다.플랫폼 프로젝트는 성장 과정에서 필연적으로 여러 번 확장합니다. 이에 따라 단기적인 성과를 달성하는 것을 넘어 지속적으로 발전하며 확장하기 위한 도전 과제에 끊임없이 직면합니다. 주어진 현실에 안주하지 않고 지속적으로 성장의 의미를 찾아야 하는 이유입니다.MessagingHub도 그와 같은 과정을 거쳐오고 있습니다. 최초에 폴링(polling) 이슈를 해결하기 위해 시작해서 이후 앱 푸시와 이메일, 문자, 이제는 채팅에 이르기까지 그 기능을 지속적으로 확장해 왔습니다. 이에 따라 서비스나 컴포넌트와의 접점도 점차 넓어지고 있습니다.그런데 한 사람이 감당할 수 있는 업무량에는 분명한 한계가 있습니다. 해야 할 일은 많고 커뮤니케이션 비용은 높아지는데 인력이 부족하다면 업무 진행 과정에서 반드시 병목 지점이 발생합니다. 프로젝트의 지속 가능한 운영과 성장을 위한 중요한 기로에 서 있는 이 상황은 어렵고 힘들긴 하지만 한편으론 흥미로운 도전 과제이기도 합니다.이 상황을 짧게 정리하면 이렇습니다.• 플랫폼 프로젝트로서 초기 성장 단계를 성공적으로 넘어섰습니다.• 그러나 업무 범위가 확장된 것에 비해 실무 담당자의 수는 매우 부족합니다.• 따라서 지속 가능한 업무 환경을 만들기 위한 돌파구가 필요한 중요한 시점입니다.MessagingHub는 플랫폼 프로 젝트로서 범용적인 사용성을 제공합니다. 따라서 사용처가 다양해지는 것은 매우 반가운 일인데요. 한편으로는 그로 인해 운영 측면에서 쌓이는 피로감을 해소하는 것 또한 중요합니다.연동 포인트의 증가는 커뮤니케이션 비용 상승으로 이어집니다. 물론 업무 관련 커뮤니케이션은 담당자의 당연한 책무이지만, 반복되는 질의 응답에 갇히거나 질문자에게 실시간으로 원하는 답변을 해야 한다는 압박감이 담당자에게 쳇바퀴를 도는 듯한 피로감을 안겨줄 때도 있습니다. 저 역시 이런 상황이 계속 되다 보니 서서히 옥죄이는 기분이 들었고, 어느 날 커뮤니케이션에 들어가는 비용이 제가 지불할 수 있는 비용을 넘어서 부채로 쌓이고 있다는 것을 자각했습니다.아래 그림은 제 느낌을 시각화한 것입니다. 생산성과 복잡도가 시간의 경과에 따라 서로 어떤 어떠한 상호관계를 갖는지 보여줍니다. 우리는 때때로 여러 가지 요인으로 인해 생산성이 급격히 떨어지는 것을 체감합니다. 이를 체감하는 순간 우리는 언제나 그렇듯 생산성을 높이기 위해서 복잡도를 붕괴시키려는 노력을 하는데요. 그 시점을 제대로 인지하는 것이 중요합니다. 만약 그 시점을 너무 늦게 인지하거나 아예 인지하지 못하고 안주한다면 이는 생산성의 붕괴로 이어질 것입니다.이를 개발자들에게 익숙한 기술 부채와 비교해 보겠습니다. 기술 부채 역시 언젠가는 갚아야 할 마음의 빚이지만, 한편으로는 도전 욕구를 자극하는 과제로 다가오기도 합니다. 반면 커뮤니케이션 부채는 시 시때때로 갚으라고 독촉하는 사채 업자에게 진 빚처럼 느껴집니다. 독촉에 시달리다 보면 정작 진짜로 해야 하는 업무는 하기 힘들어지고 응대 모드로 전환할 수 밖에 없는 악순환에 빠져 피폐해지는 것이죠.MessagingHub에 인입되는 대부분의 질문은 시스템의 구조나 작동 방식, 연동 방법과 같은 것을 물어보는 세부적이고 실무적인 질문입니다. 따라서 연동 컴포넌트가 늘어날수록 질문의 양도 비례해서 늘어날 수밖에 없기에 정말 해야 할 일에 제대로 몰입하려면 이 부채를 반드시 해결해야 했습니다. 이를 위해 저는 아래 두 가지를 실행 목표로 정했습니다.• 질문의 양을 줄인다.• 질문을 내가 좋아하는 방식으로 바꾼다.각 실행 목표를 하나씩 살펴보겠습니다.질문의 양을 줄이기질문은 그 자체로 나쁜 것은 없습니다. 오죽하면 '세상에 바보 같은 질문은 없다'는 말까지 있으니까요. 반면 '세상에 바보 같은 답변은 없다'는 말은 없습니다. 실제로 조금만 찾아보면 바보 같은 답변은 쉽게 찾아볼 수 있습니다. 저는 이 사실을 곱씹다가 재밌는 사실을 하나 깨달았습니다. 질문하는 쪽보다 답변하는 쪽이 짊어져야 할 책임이 크다는 것입니다. 질문은 바보 같지 않은데 답변은 바보 같을 수 있으니까요. 그렇기 때문에 답하는 쪽에서는 질문을 최대한 시스템화하는 것이 중요하다는 결론에 도달했습니다. 그동안 받아왔던 질문의 유형과 관심사를 분류하며 결국 원하는 답은 무엇이었는가를 정리해 보면 질문에 대한 답을 체계화할 수 있습니다.제가 질문의 양을 줄이기 위해 사용자의 질문과 답변을 체계화하고 시스템화한 결과는 다음과 같습니다.통합 가이드 - 당신이 뭘 알고 싶은지 몰라서 다 준비했어요개발자에게 '배경이 어떻고, 구조가 어떻고, 철학이 어떻고'는 중요하지 않습니다. 개발자가 제일 궁금해 하는 것은 '그래서 내가 뭘하면 되는데?'입니다. 통합 가이드는 이런 개발자에게 연동 작업을 안내하기 위한 올인원 가이드입니다. 당연하지만 이 가이드를 처음부터 끝까지 샅샅이 읽으며 모든 것을 다 보고 이해할 필요는 없습니다. 본인이 원하는 기능에 대한 가이드는 최대한 해당 기능 페이지 안에 전부 설명돼 있습니다. 물론 참조 링크도 제공하고요.뉴비를 위한 흐름 차트: 이미지 게임하듯 순서대로 따라가다 보면 필요한 것을 찾을 수 있어요.앞서 MessagingHub와 연동할 때 참고할 수 있는 올인원 연동 가이드를 만들어 놓았더니 이제는 MessagingHub 자체에 대해 조금 더 자세히 알고 싶다고 합니다. 개발자뿐 아니라 기획자 혹은 의사 결정 권한을 가진 이해 관계자들을 이해시킬 자료가 더 필요하다는 건데요. 이를 위해 그동

안녕하세요, 뱅크샐러드 웹 프론트엔드 챕터의 민찬기입니다.gRPC는 마이크로서비스간 호출에 많이 사용되는 통신 프로토콜로, 개발자 생산성 향상 및 빠른 통신 속도를 지원하여 많은 어플리케이션에서 사용하고 있습니다. 뱅크샐러드도 마이크로서비스 아키텍쳐로 전환하여 서비스 간 통신에 gRPC를 적극적으로 사용하고 있습니다.뱅크샐러드는 프론트엔드 (web, android, ios) 플랫폼에서 서비스를 호출할 수 있도록 gRPC의 각 메시지를 HTTP 핸들러로 변환하여 외부에 노출할 수 있는 grpc-gateway를 쓰고 있으며, 프론트엔드 플랫폼에서는 HTTP 호출을 통해 간접적으로 gRPC 메시지를 소비하고 있습니다.gRPC-Gateway는 protobuf compiler (protoc) 위에서 동작하는 플러그인으로, 파일에 HTTP proxy에 대한 추가 내용을 작성하면 자동으로 reverse-proxy 역할을 하는 서버 코드를 생산해 줍니다. HTTP를 사용하는 곳에는 reverse proxy 서버에 HTTP 호출을 하면 json으로 포멧팅된 결과를 받을 수 있습니다.따라서 개발자가 IDL 레포지토리에 파일을 선언할 때, gRPC-Gateway가 활용 가능한 정보를 같이 추가하여 RESTful 호출을 지원하고 있습니다.이리하여 gRPC 서비스에 대한 HTTP API 호환이 가능했고, 웹 개발자는 axios 등 다양한 HTTP 클라이언트 라이브러리를 사용하여 마이크로서비스를 활용해 왔습니다. 하지만 점점 프론트엔드 어플리케이션이 많아지고 마이크로 서비스와 각 서비스의 메시지가 늘어나면서 아래와 같은 문제점들이 생겼습니다.HTTP 클라이언트 코드가 너무 많이 중복되고, 반복적인 작업이 되어감프론트엔드 개발자는 서비스를 호출하기 위해 아래와 같이 HTTP 클라이언트를 작성해야 했습니다.호출해야 하는 서비스가 많아지고, 프론트엔드 챕터에서도 마이크로 프론트엔드 아키텍쳐를 적용하게 되면서 중복되는 API 호출 코드가 레포지토리 여기저기에 흩어지게 되었습니다. 이 문제를 해결하기 위해 ts-proto를 활용하여 API 요청/응답 타입 생성을 자동화했습니다.추가로 api 호출부를 별도 npm 패키지로 분리하려 했지만 개발자가 신규 API를 사용하기 위해서 라이브러리를 수정하고, 코드 리뷰를 받고, 배포된 라이브러리를 서비스 개발 브랜치에 설치해서 작업해야 하는 비효율이 예상되어 실현하기 어려웠습니다.external domain인 을 사용하도록 클라이언트 코드를 작성하면 browser 및 Next.js 서버에 양 측에서 간편하게 사용할 수 있었기 때문에 모든 클라이언트 코드에서 을 호출하게 작성하는 경우가 많았습니다. 또한 토큰 관리의 어려움 및 빠른 개발을 위해 server side render를 활용하지 않고 사용자 브라우저에서 필요한 모든 API 호출을 하는 서비스가 많았습니다.뱅크샐러드는 사용자 여러분들의 데이터를 안전하게 지키기 위해 external 호출은 모두 IPS(침입 차단 시스템)을 거치도록 인프라 구성이 되어 있습니다. 따라서 웹 페이