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

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

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

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

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

💡Must-Know Event-Driven Architectural Patterns

👉🏻 아티클 전문 링크

• 이벤트 기반 아키텍처에서 자주 활용되는 패턴들을 실제 시스템 사례와 함께 설명합니다.
• Event Sourcing, CQRS, Outbox Pattern, Idempotent Consumer 등의 여러 패턴이 어떤 문제를 해결하고 왜 중요한지 다룹니다.

💌 멘토님의 Comment
: MSA로 전환하면서 이벤트 처리는 피할 수 없는 과제입니다. 동기식으로 처리하던 로직을 비동기 이벤트로 바꾸면 시스템은 유연해지지만, 복잡도는 기하급수적으로 증가합니다.

 

시스템 아키턱처를 구성할 때에는 단순히 동작하는 방식으로 구현하면 안됩니다. 검증된 패턴과 안티패턴 등을 미리 확인하여 각 방식의 장단점을 비교하고 리스크를 관리해야 적절한 시스템 아키텍처 구성이 가능합니다.

 

이를 모르고 Transactional Outbox Pattern 등을 사용한다면 DB는 업데이트됐는데 이벤트가 발행되지 않는 등 이슈가 발생하고, 원인을 찾거나 디버깅을 하기도 꽤나 어려워지니 시스템 아키텍처를 설계할 때에는 어떤 특징이 있는지 꼭 먼저 찾아보시면 좋겠습니다. 각 패턴이 해결하는 문제와 트레이드오프를 이해하고, 상황에 맞게 적용하는 것이 중요합니다.

 

여러분의 시스템은 이벤트 유실이나 중복 처리에 대한 대비가 되어있나요?

💡Milvus: LINE VOOM의 실시간 추천 시스템을 위한 대규모 벡터 DB 구축기

👉🏻 아티클 전문 링크 

• 추천 시스템에서 벡터 검색이 어떤 기술적 도전 과제들을 가지고 있는지 설명합니다.
• 벡터 DB의 스케일링, 데이터 싱크 및 갱신 문제, 그리고 실시간 검색 성능 확보를 위해 LINE이 직접 설계하고 적용한 시스템 아키텍처와 최적화 전략을 소개합니다.

💌 멘토님의 Comment
: 최근 들어 벡터 데이터베이스는 AI 추천 시스템이나 검색 엔진 등 다양한 서비스에서 빠질 수 없는 인프라가 되었습니다. 하지만 규모가 커지고 데이터 갱신이 빈번해지면 벡터 DB는 RDBMS와 다르게 까다로운 여러 관리 방식이 필요합니다.

 

대규모 벡터 색인을 안정적으로 유지하면서도 지연 시간을 최소화하기 위해 어떻게 아키텍처를 구성해야 할까요? 벡터 검색은 임베딩 생성부터 유사도 검색까지 생각보다 많은 리소스와 시간이 듭니다. 단순히 쿼리를 하는 RDBMS와는 다르게 벡터 DB는 데이터 생성부터 임베딩을 해야하며 조회를 할 때에도 코사인 연산 등의 여러 부하가 큰 작업이 이루어집니다. 특히 검색방식을 실시간으로 바꾸려면 수십억 개의 벡터에서 밀리초 단위로 유사 벡터를 찾아야 합니다.

 

이런 문제점을 라인에서 어떻게 해결하는지, 벡터 DB를 선택할 때 기준이 어땠는지를 살펴보고 추후 기술 선택시의 근거를 삼을 때 참고자료로 삼으면 좋겠습니다.

💡Virtual Thread의 기본 개념 이해하기

👉🏻 아티클 전문 링크

• JDK 21에 정식 도입된 Virtual Thread가 기존 플랫폼 스레드와 어떻게 다른지, 내부 동작 원리는 무엇인지 분석합니다.

💌 멘토님의 Comment
: Java에서 Thread와 Vitrual Thread는 어떤 차이가 있을까요? Java의 Thread는 OS의 Thread와 1:1로 연결되어 동작합니다. 즉 OS에서 스레드를 할당해주지 않으면 Java Thread도 동작하기 어렵습니다. 하지만 Virtual Thread는 N:1로 매핑됩니다. 수천 개의 Virtual Thread가 몇 개의 플랫폼 스레드를 공유하면서 실행되는 거죠.

 

그러면 Virtual Thread가 무조건 좋을까요? 내부 구조는 꽤나 복잡합니다. 스레드의 상태 자체가 늘어났고, 마운트, 언마운트를 수행하며 Thread.sleep 호출시 블로킹되지 않고 리스케줄링을 호출하는 등 꽤나 흥미로운 동작 방식을 가집니다. 그래서 Virtual Thread를 기존 Thread를 대체하는 방식으로 쓰면 꽤나 여러 문제가 발생합니다. I/O작업은 높은 성능을 가지는 반면 MySQL 드라이버를 사용할 때 낮은 성능을 보여주기도  합니다.

 

Virtual Thread는 Reactive 프로그래밍의 복잡함 없이도 높은 동시성을 달성할 수 있는 대안입니다. 다만 아직은 충분한 검증이 이루어지지 않았으므로 최신기술이니 무조건 좋을거라고 기대하기 보다는 충분히 검토하여 장단점을 따져보고 도입하느걸 권장드리겠습니다.

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

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

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