멘토 Pick! 25년 7월 셋째 주 아티클 모음

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

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

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

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

💡Most RESTful APIs aren't really RESTful

👉🏻 아티클 전문 보기

• 오늘날 RESTful API라고 표현하는 대부분의 API는 REST하지 않다는 점을 지적하며, RESTful API의 조건에 대해 설명합니다.
• HATEOAS가 없는 RESTful API의 문제가 무엇인지, 실무에서 HATEOAS를 적용하기 어려운 이유에 대해 공유합니다.

💌 멘토님의 Comment
: REST API라고 이름 붙인 수많은 API들이 사실은 "HTTP 기반 RPC"에 가깝다는 불편한 진실을 다룬 글입니다. 많은 개발자들이 HTTP 메서드(GET, POST, PUT, DELETE)를 사용하고 JSON을 주고받으면 RESTful API라고 생각합니다. 하지만 REST 아키텍처의 창시자인 Roy Fielding 본인도 2008년에 "HATEOAS 없이는 REST가 아니다"라고 명확하게 발언했습니다.

 

많은 개발자들이 이력서와 포트폴리오에 RESTful API 개발 경험을 작성하고 있지만, 단순히 CRUD와 HTTP 메서드를 1:1로 매칭하여 사용한다고 RESTful하다고 표현하기는 어렵습니다. 이것이 잘못되었다는 게 아닙니다. 같은 팀이 프론트엔드와 백엔드를 모두 관리한다면, REST의 장점인 클라이언트와 서버의 디커플링이 그렇게 필요하지는 않을 수 있습니다. 하드코딩된 엔드포인트를 호출하는 경우가 대부분이라면 굳이 REST 원칙을 따라가지 않아도 좋습니다.

 

다만, 현재 사용하고있는 API 아키텍처가 어떤 스타일에 가까운지, 해당 아키텍처가 지향하는 방향이 어떤 방향인지는 명확히 이해하고 사용하는건 어떨까요?

💡우리는 암호화하는데 왜 키를 사용할까?

👉🏻 아티클 전문 보기

• 카카오페이 손해보험이 암호화 모듈을 리팩토링하면서 얻은 인사이트를 통해 암호화의 역사부터 실무 구현까지 체계적으로 정리한 글입니다.

💌 멘토님의 Comment
: 정보 암호화는 왜 하는지를 이해하는게 중요합니다. 암호화 알고리즘을 왜 숨겨야하는지, 대칭키와 비대칭키를 왜 섞어쓰는지 모르고 암호화를 구현한다면 보안조치가 필요할 때 근본적인 원리를 이해하지 못해 위험도가 있는 암호화 방식을 사용할 수 있기 때문입니다.

 

암호화의 핵심은 키 관리입니다. 옛날 암호화방식은 알고리즘을 비밀로 만드는 방식이었고, 알고리즘이 노출되면 바로 복호화가 가능했습니다. 현대 암호화는 알고리즘을 모두 공개해두고 키를 숨깁니다. 키는 바꾸기 쉽지만 알고리즘은 바꾸기 어려우니까요.

 

이런 현대 암호화를 사용할 때 키를 변경하지 않고 그대로 사용한다면, 즉 키 로케이션을 사용하지 않는다면 여전히 암호화 취약점이 존재합니다. 따라서 현대 암호화가 어떤 방식을 지향하는지, 어떤 약점이 있는지 이해하고 사용하는게 중요합니다.

 

여러분 서비스는 민감 데이터 어떻게 보호하고 있나요?  암호화와 키 관리에 대해 이번 기회에 복습해보시는건 어떠실까요?

💡Pattern: Backends For Frontends

👉🏻 아티클 전문 보기

• BFF 패턴의 창시자 Sam Newman이 작성한 BFF 패턴의 원본 문서 내용으로 BFF패턴에 대한 전반적인 내용을 작성한 글입니다.

💌 멘토님의 Comment
: 하나의 API로 모바일, PC 등 여러 클라이언트에 대응하는 API를 개발할 수 있을까요? 여러가지 클라이언트에 대응하기 위해 나온 패턴인 BFF패턴은 어떤 패턴일까요?

 

BFF패턴은 각 클라이언트마다 전용 백엔드를 두는 방식인데 모바일 BFF, 웹 BFF와 같은 방식으로 백엔드를 분리합니다. 마이크로서비스가 많을 때 유용합니다. 예를 들어, 장바구니 화면 하나 만드는데 상품 서비스, 재고 서비스, 가격 서비스 다 호출해야 한다면 BFF패턴을 통해 복잡한 조합을 대신 처리해줄 수 있으며, 클라이언트는 BFF를 한번만 호출하면 됩니다.

 

이런 디자인패턴을 쓴다면 어떤 트레이드 오프가 있을까요? 비슷한 로직이 많아지지 않을까요? 

GraphQL과 같은 대안과는 어떤 장단점이 있을까요?

 

이런 패턴들을 알아두면 나중에 시스템 설계할 때 선택지가 넓어집니다. 모든 서비스에 적용할 수 있는 만능 아키텍처는 없습니다.

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

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

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