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

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

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

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

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

💡 The Curse of Knowing How, or; Fixing Everything

>>> 아티클 보러가기 >>>

• 개발 능력이 향상될수록 세상의 모든 소프트웨어와 시스템이 개선 가능한 대상으로 보이는 현상을 다룹니다.
• 기술적 능력이 일종의 도덕적 책임감으로 변모하면서 모든 것을 '고쳐야 한다'는 부담으로 이어지는 과정을 설명합니다.

💌 멘토님의 Comment
: 개발자로 성장할수록 이상한 현상이 생깁니다. 웹사이트를 방문할 때마다 "왜 이렇게 JavaScript를 많이 보내지?", CLI 도구를 사용할 때마다 "왜 이 출력은 파싱하기 어렵게 만들었지?" 같은 생각이 자동으로 떠오르죠. 점점 모든 소프트웨어가 '할 일 목록'으로 보이기 시작합니다. 그리고 더 위험한 것은 "이걸 고칠 수 있는데 왜 안 하지?"라는 생각이 들면서 일종의 도덕적 의무감까지 느끼게 된다는 점입니다.

하지만 진짜 중요한 기술은 무엇을 고칠지, 언제 그냥 놔둘지 아는 것입니다. 모든 깨진 것이 우리가 고쳐야 할 책임은 아니니까요. 때로는 그냥 충분히 좋은 상태로 두는 게 더 현명할 수 있습니다.
    
다음에 불완전한 시스템을 마주했을 때, 자문해보세요. "이걸 고치는 게 정말 가치 있는 일인가? 아니면 그저 내가 통제감을 느끼고 싶어서인가?"
    
이런 부분을 조정하지 못한다면 모든 시스템을 통제할 수 없는 개발자에게 번아웃이 찾아오기 쉽기 때문에 모든걸 고칠 수 없다는 점을 이해하고 필요한 부분에 집중하는 것이 좋겠습니다.

💡 How Discord Indexes Trillions of Messages

>>> 아티클 보러가기 >>>

• Discord가 수조 개의 메시지를 효율적으로 인덱싱하고 검색하기 위한 아키텍처 개선 과정을 설명합니다.
• 기존 시스템의 한계(메시지 유실, 노드 장애 시 복원력 부족, 대규모 클러스터의 성능 저하)와 이를 극복하기 위한 솔루션을 다룹니다. 
• Kubernetes 기반 Elasticsearch 배포, 멀티 클러스터 셀(cell) 아키텍처, PubSub을 활용한 메시지 큐 개선 등 핵심 기술적 결정을 상세히 설명합니다. 

💌 멘토님의 Comment 

: 서비스가 성장하면서 기존 아키텍처의 한계점이 드러나는 과정이 인상적입니다. Discord가 초기에 선택한 Elasticsearch 기반 구조는 처음에는 잘 작동했지만, 시스템이 수조 개의 메시지를 처리해야 하는 규모로 성장하자 여러 문제점이 나타났죠. 

 

특히 주목할 만한 점은 문제 해결 접근 방식입니다. 단순히 기존 시스템을 확장하는 대신, 근본적인 아키텍처 재설계를 선택했습니다. 대규모 클러스터 하나보다 여러 개의 작은 클러스터가 더 효율적이라는 결정, Redis에서 PubSub으로의 메시지 큐 전환, 그리고 '셀' 개념을 도입해 다양한 사용 사례(DM 검색, 대형 서버 등)를 지원하는 방식은 대규모 시스템 설계에 있어 좋은 사례입니다. 

 

시스템 설계에서 가장 중요한 것은 최신 기술을 쓰는 것이 아니라, 구체적인 문제와 제약 조건을 이해하고 그에 맞는 해결책을 찾는 것이 중요한데 이 글을 통해 이 부분에 대한 인사이트를 얻기 좋겠습니다.

💡 MySQL ALTER DDL 수행 방식에 대한 이해 

>>> 아티클 보러가기 >>>

• MySQL에서 테이블 구조를 변경하는 ALTER 명령의 세 가지 실행 알고리즘(Copy, In-Place, Instant)과 각각의 특성, 장단점을 설명합니다.
• 각 알고리즘이 어떤 방식으로 메타데이터 락(Metadata Lock)을 획득하고 해제하는지 상세히 다루며, 서비스 가용성에 미치는 영향을 분석합니다.
• 대규모 서비스 운영 환경에서 DDL을 안전하게 수행하기 위한 실질적인 가이드를 제공합니다.

💌 멘토님의 Comment 

: 테이블에 컬럼을 하나 추가하는 단순한 작업이 서비스를 멈추게 할 수 있다면 상상이 되시나요? 실제로 MySQL에서는 이런 일이 발생합니다. 

 

예를 들어보죠. 1천만 건의 데이터가 있는 사용자 테이블에 '주소' 컬럼을 추가한다고 가정해보세요. 예전 MySQL에서는 이 작업을 위해 테이블 전체를 복사하고, 그 동안 모든 사용자의 로그인이나 가입 같은 쓰기 작업이 블로킹됩니다. 대형 서비스라면 치명적이죠. 

 

이런 문제를 해결하기 위해 나온 것이 'Online DDL'입니다. MySQL 8.0의 경우, 단순히 컬럼을 추가하는 작업은 테이블 데이터를 전혀 건드리지 않고 메타데이터만 변경해 1초 내로 완료할 수 있습니다. 그 사이 서비스는 정상적으로 계속 운영됩니다. 

 

이 글에서는 이런 테이블 변경 작업이 내부적으로 어떻게 이루어지는지, 그리고 서비스 상황에서 어떤 방식을 선택해야 안전한지를 설명합니다.

💡 우리의 애플리케이션에서 PreparedStatement는 어떻게 동작하고 있는가

>>> 아티클 보러가기 >>>

• Java 애플리케이션에서 PreparedStatement의 동작 원리와 다양한 계층에서의 구현 방식을 상세히 설명합니다. 
• Hibernate, HikariCP, MySQL Connector/J와 같은 추상화 계층에서 PreparedStatement의 설정 방법과 내부 구현을 분석합니다.

💌 멘토님의 Comment 

: 대부분의 개발자들이 "PreparedStatement가 SQL Injection을 방지한다"는 기본적인 지식은 알고 있지만, 실제로 내부에서 어떻게 동작하는지 깊이 있게 이해하는 경우는 드뭅니다. 우리가 사용하는 ORM, Connection Pool, JDBC 드라이버 각 계층에서 PreparedStatement를 어떻게 처리하는지 이해하면, 더 효율적인 데이터베이스 접근 코드를 작성할 수 있습니다. 

 

특히 이 글에서 다룬 useServerPrepStmts와 cachePrepStmts 설정은 실무에서 자주 간과되는 부분입니다. 잘못된 설정으로 인해 매 쿼리마다 새로운 PreparedStatement를 생성해 성능 저하를 일으키는 경우가 많습니다. @DynamicUpdate와 같은 Hibernate 설정이 PreparedStatement 캐시 효율에 영향을 미친다는 점도 실무에서 잘 고려되지 않는 부분이죠. 

 

다음에 데이터베이스 설정을 검토하실 때, 단순히 모범 사례를 복사하는 것이 아니라 각 설정이 어떻게 동작하는지 이해하고 적용해보세요. 성능 향상 뿐 아니라, 문제 발생 시 더 빠르게 원인을 파악할 수 있는 기반 지식이 될 것입니다.