멘토 Pick! 25년 6월 첫째 주 아티클 모음

안녕하세요 여러분!
이번 주도 카카오 출신 멘토님께서 이번 주에 직접 선정한 아티클을 공유드립니다!

멘토's Pick에서 트렌디한 인사이트를 놓치지 마세요! 🚀

🤔 들어가기 전에 알아두면 좋습니다!

• 대부분 아티클은 영문으로 제공됩니다. 영문 글을 읽을 때 크롬 번역 플러그인을 쓰면 읽기가 불편하나, 크롬 플러그인 하나를 설치하면 한국어를 읽듯이 좀 더 쉽게 영어 아티클을 읽을 수 있습니다. Trancy Chrome 플러그인을 설치 후 더 쉽게 읽을 수 있습니다.
• 아티클을 읽고 어떤 점을 더 고민해 보고, 생각해 보면 좋을지 제시해 주시는 멘토님의 Comment도 잘 활용해 보시면 좋습니다!

💡 A Brief History of JavaScript

• JavaScript 탄생 30주년을 맞아 1995년 Brendan Eich가 10일 만에 만든 스크립트 언어가 어떻게 세계에서 가장 인기 있는 프로그래밍 언어가 되었는지 주요 사건들을 연대기로 정리합니다.

💌 멘토님의 Comment 

: 10일 만에 급조된 언어인 Javascript가 30주년을 맞았습니다. 

JavaScript는 꽤 운이 좋은 언어입니다. 처음엔 Java의 인기에 편승하려고 이름도 JavaScript로 지었고, 설계도 급하게 했는데 웹의 폭발적인 성장과 함께 덩달아 커버린 거죠. 하지만 급조된 언어인 만큼 여러가지 문제가 발생했습니다. 

2016년 left-pad 사건은 지금 생각해도 아찔합니다. 단 11줄짜리 문자열 패딩 함수 하나가 npm에서 삭제되자 React와 Babel을 포함한 수천 개 프로젝트가 빌드되지 않았던 이 사건 이후로 npm은 패키지 삭제 정책을 바꿨습니다. 

Array.prototype.flatten()을 추가하려다가 오래된 라이브러리인 MooTools와 충돌해서 메서드 이름을 smoosh()로 바꾸자는 농담이 진지하게 논의되며 진담이 될 뻔한 사건도 있었습니다. 결국 flat()으로 결정됐지만 하위 호환성을 지키기 위해 여러가지 사건 사고가 많았습니다. 

Javascript 붐이 온 것은 2009년 Node.js의 등장이 가장 큰 전환점이었다고 봅니다. 브라우저에만 갇혀있던 JavaScript가 서버로 나오면서 풀스택 개발이 가능해졌고, npm 생태계가 폭발적으로 성장했습니다. 지금의 JavaScript 생태계는 Node.js 없이는 상상하기 어렵습니다. 

30년이라는 긴 시간 동안 살아남고 계속 진화하는 JavaScript의 앞으로 30년 후는 또 어떤 모습일지 궁금합니다.

💡Synchronous vs Asynchronous Architecture

• 백엔드 시스템에서 동기와 비동기 아키텍처를 언제 선택해야 하는지, 각각의 트레이드오프와 실무에서 마주치는 함정들을 다룹니다.
• 단순하고 예측 가능한 동기 통신과 복잡하지만 회복력 있는 비동기 접근법(메시지 큐, 이벤트 기반) 사이의 균형점을 찾는 방법을 제시합니다.

💌 멘토님의 Comment 

: 동기방식과 비동기방식을 고려할 때 동기방식이 무조건 느리거나 안좋다고 생각하는 경우가 있습니다. 비동기로 처리하고, 이벤트 큐 사용하고, 보내고 잊는 방식(Fire and forget)을 사용하면 대규모 서비스에도 적합하며 정말 나이스한 개발방법을 쓴 것 같은 느낌이 들기도 하죠. 

하지만, 비동기 이벤트큐 방식은 다음 사례를 100% 방지하기 어렵습니다. 다음 상황이 발생한다면 어떻게 해결하시나요? 이걸 방지하기 위한 방법을 구현하는게 더 큰 리소스 소모인지 고민해보셔야 합니다. 

- Fire and forget이 얼마나 위험한지. "메시지 보냈으니 됐겠지" 하다가 나중에 고객이 "제 주문 어디 갔어요?" 물어보면 답이 없음 

- 이벤트 이름 하나 때문에 설계가 꼬이는 것. OrderPlaced vs PlaceOrder 

- 이벤트 발행했는데 누가 듣는지 모른다? 나중에 그 이벤트 없애려고 하면 어떤 팀이 쓰는지 다 물어봐야 함 

- 메시지 큐 모니터링 없으면 장애 났는지도 모름 

- UI에서 "처리 중입니다" 어떻게 보여줄지 미리 정하기 

- 메시지 순서 꼬이면 어떻게 할지 (유저가 구독 취소했는데 구독 신청이 나중에 처리되면?) 

 

위 글은 인터뷰를 그대로 적어둔 방식의 글입니다. 동기방식과 비동기방식에 관련된 토론을 보며 무조건 정답인 방식이 없다는 점을 인지하고 상황에 맞는 방식을 사용하시면 좋겠습니다.

💡 gRPC vs REST : Choosing the best API design approach

• REST의 단순함과 gRPC의 성능을 비교하며, HTTP/2 기반 gRPC가 제공하는 멀티플렉싱, 헤더 압축, 바이너리 직렬화의 장점을 설명합니다.

💌 멘토님의 Comment 

: gRPC와 전통적인 방식인 REST는 어떤 차이점이 있고, 선택의 기준은 어떤게 있을까요? 

REST는 HTTP/1.1 위에서 JSON을 주고받는 반면, gRPC는 HTTP/2 위에서 Protocol Buffers라는 바이너리 포맷을 사용하고, gRPC는 하나의 연결로 수백개의 요청을 처리할 수 있다고 하면 REST보다 gRPC가 더 좋은 방식일까요? 

아쉽게도 gRPC는 브라우저에서 직접 호출할 수 없습니다. 프록시를 쓰면 우회할 수 있긴 하나 REST API가 아직까지 대세인건 구현과 사용이 간편하다는 점 때문입니다. 

브라우저가 아닌 환경에서 웹 통신을 구현한다면 REST가 아닌 gRPC에 대한 선택 방향도 열어두는건 어떠실까요?

깊이 있는 인사이트와 현실적인 조언이 담긴 멘토님들의 인터뷰와 커리어 성장 콘텐츠가 데브클럽에서 정기적으로 업데이트되고 있습니다.

실력 있는 현직 개발자 멘토들과 직접 소통하고, 생생한 실무 노하우와 커리어 성장 전략을 배워보세요!

👉 멘토링 신청하고 데브클럽 참여하기