멘토 Pick! 25년 8월 넷째 주 아티클 모음

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

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

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

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

💡 Why the heck Single-Threaded Redis is Lightning fast? Beyond In-Memory Database Label

• Redis가 싱글 스레드 기반인데도 왜 그렇게 빠른지 설명합니다.

👉 아티클 전문 보러가기 

💌 멘토님의 Comment
: Redis의 성능은 구조적인 단순함에서 나옵니다. 메모리에 올려 두고 이벤트 루프로 요청을 처리하기 때문에 락 경합도 없고, 스레드 전환 비용도 없습니다. 그래서 캐시, 세션, 카운터처럼 짧게 끝나는 작업을 아주 빠르게수행합니다. 하지만 정렬, 집계, 대량 스캔처럼 CPU를 오래 쓰는 명령이 섞이면 전체 처리 흐름이 느려질 수밖에 없습니다.

 

지금 팀에서 Redis는 어떤 역할을 맡고 있나요? 단순 캐시와 세션 저장소 수준에서 머무는지, 아니면 다른 연산까지 얹고 있는지. Redis의 구조적 특성을 알고 쓰는 것과 모르고 쓰는 것은 운영 안정성에서 큰 차이를 만듭니다

💡 Everything I know about good system design

• 좋은 시스템 설계를 만들기위한 다양한 방법을 소개합니다.

👉 아티클 전문 보러가기

💌 멘토님의 Comment
: 시스템 디자인을 처음 접하면 분산 합의, CQRS, 이벤트 소싱 같은 화려한 패턴들에 눈이 가기 쉽습니다. 하지만 실제로 잘 동작하는 시스템은 대부분 단순하게 설계되어있으며, 필요할 때 하나씩 컴포넌트를 추가하며 복잡도가 올라가며 진화한 시스템들이 많습니다.

 

시스템설계를 할 때 많은 기술을 적용하면 어떤 부분이 좋을까요? 개발자는 멋진 기술스택으로 시스템을 만드는 사람이 아닌 비즈니스에 맞는, 요구사항에 맞는 시스템을 개발하는 사람이기 때문에 오버엔지니어링을 경계해야 합니다. 이런 관점에서 어떤 부분에서 주의하며 복잡도를 올리지 않을지, 경계할지 소개하는 글을 읽고 인사이트를 얻어가셨으면 좋겠습니다.

💡Optional은 정말로 필요한가? (feat. JSpecify)

• Java의 Optional이 원래 스트림 API의 메서드 체이닝을 위해 제한적으로 도입되었지만, 실제로는 Maybe 타입처럼 널 체크 용도로 남용되고 있다는 문제를 지적합니다.

👉 아티클 전문 보러가기

💌 멘토님의 Comment
:  Optional에 대한 논란은 Java 커뮤니티에서 오래된 주제입니다. Optional은 스트림 API에서 findFirst()나 findAny() 같은 메서드의 반환값을 표현하기 위한 제한적 용도로 만들어졌는데, 많은 개발자들이 이를 일반적인 null 처리 도구로 확대 사용하면서 문제가 생겼습니다. 특히 isPresent()로 체크하는 코드는 Optional의 취지를 완전히 무시하는 안티패턴입니다. 이럴 거면 그냥 null 체크하는 게 더 명확하죠. 필드나 메서드 파라미터에 Optional을 쓰는 것도 마찬가지입니다. Optional 자체가 null일 수 있다는 모순적인 상황을 만들어냅니다.

 

지금 팀에서 Optional을 어떤 용도로 사용하고 있나요? 메서드 체이닝을 위한 제한적 용도인지, 아니면 일반적인 null 처리 도구로 쓰고 있는지 점검해보고, JSpecify 도입을 검토해보는 것도 좋겠습니다.