멘토 Pick! 25년 12월 첫째 주 아티클 모음
F-Lab : 상위 1% 개발자들의 멘토링
여러분 안녕하세요~ 👋
이번 주 멘토's Pick 아티클이 도착했습니다!
멘토님께서는 어떤 아티클을 읽고 어떤 중요한 인사이트를 얻으셨을까요? 멘토님의 선택을 확인해 보세요!
🤔 들어가기 전에 알아두면 좋습니다!
- 대부분 아티클은 영문으로 제공됩니다. 영문 글을 읽을 때 크롬 번역 플러그인을 쓰면 읽기가 불편하나, 크롬 플러그인 하나를 설치하면 한국어를 읽듯이 좀 더 쉽게 영어 아티클을 읽을 수 있습니다. Trancy Chrome 플러그인을 설치 후 더 쉽게 읽을 수 있습니다.
- 아티클을 읽고 어떤 점을 더 고민해 보고, 생각해 보면 좋을지 제시해 주시는
멘토님의 Comment도 잘 활용해 보시면 좋습니다!
💡How AI is transforming work at Anthropic
- Anthropic 엔지니어 132명 대상 설문과 53명 심층 인터뷰를 통해 AI가 개발 업무를 어떻게 변화시키고 있는지 분석한 내부 연구 결과를 공유합니다.
- 엔지니어들이 업무의 60%에서 Claude를 사용하며 50% 생산성 향상을 보고했고, Claude가 6개월 전보다 2배 더 복잡한 작업을 자율적으로 처리하게 되었다는 데이터를 제시합니다.
💌 멘토님의 Comment
: 엔지니어들이 그동안 우선순위에서 밀려 미뤄두던 작업을 27% 더 수행하게 되었습니다.
문서화, 리팩토링, 대시보드 제작 같은 있으면 좋지만 우선순위에서 밀리던 일들이죠. 또한 많은 개발자가 풀스택 개발자가 되어가고 있다고 합니다. 백엔드 개발자가 UI를 만들고, 연구원이 프론트엔드 시각화를 구현합니다.
하지만 동시에 코딩 근육이 약해진다는 우려도 나타납니다. 한 시니어 엔지니어는 디버깅하면서 얻는 부수적 학습이 사라진다고 지적했습니다. 문제를 직접 해결하면서 시스템 전체를 이해하게 되는데, AI가 바로 답을 주면 그런 기회가 사라진다는 거죠.
지금 여러분은 AI 도구를 어떻게 사용하고 있나요? 검증하기 쉬운 작업에만 쓰고 있나요, 아니면 핵심 설계까지 맡기고 있나요? 그리고 AI 없이도 문제를 해결할 수 있는 능력을 유지하기 위해 어떤 노력을 하고 있나요?
💡How Uber Serves Over 40 Million Reads Per Second from Online Storage Using an Integrated Cache
- Uber의 인하우스 분산 데이터베이스 Docstore에 통합 캐싱 솔루션 CacheFront를 구축하여 초당 4천만 건의 읽기 요청을 처리하는 방법을 설명합니다.
- Query Engine 레이어에 Redis 캐시를 통합하고, CDC 기반 캐시 무효화와 Cross-region 캐시 워밍을 통해 P75 레이턴시 75% 감소, 비용 95% 절감을 달성한 사례를 다룹니다.
💌 멘토님의 Comment
: 캐싱을 도입하면 성능이 좋아진다는 건 누구나 압니다.
문제는 각 팀이 개별적으로 Redis를 붙이기 시작하면서 생기는 부작용이죠. 중복된 캐싱 코드, 제각각인 무효화 로직, Region Failover 시 캐시가 비어있어서 DB에 트래픽이 몰리는 문제까지. 캐시가 해결책이 아니라 새로운 문제가 되는 상황입니다.
Uber는 이 문제를 Query Engine 레이어에 캐시를 통합하는 방식으로 해결했습니다.
비즈니스 팀은 캐싱 구현을 신경 쓸 필요 없이 Docstore만 사용하면 되고, 인프라 팀은 한 곳에서 일관되게 관리할 수 있게 된 거죠.캐시 무효화는 CDC로 MySQL binlog를 따라가면서 변경을 감지하고, TTL과 함께 사용해서 99.9% 일관성을 달성했습니다.
완벽한 Strong Consistency는 아니지만, 정말 그게 필요한 서비스는 캐시를 우회하는 옵션을 열어두었습니다. 모든 요구사항을 하나로 해결하려 하지 않고 현실적인 트레이드오프를 선택한 거죠.
지금 팀에서 캐싱은 어떻게 관리하고 있나요? 서비스마다 개별 Redis 클러스터를 운영하고 있다면, 그 중복 비용과 일관성 문제를 한번 계산해보신 적 있나요?
💡장시간 비동기 작업, Kafka 대신 RDB 기반 Task Queue로 해결하기
- 대용량 엑셀 생성 작업이 30분 이상 소요되면서 Kafka의 타임아웃(5분)을 초과해 리밸런싱이 발생하고, 동일 메시지가 중복 처리되어 엑셀이 여러 번 발송되는 문제를 다룹니다.
- Kafka를 걷어내고 RDB 기반 Task Queue + Heartbeat 아키텍처로 재설계하여, 작업 시간 제한 없이 안정적으로 처리하고 서버 장애 시에도 자동 복구되는 구조를 구현한 과정을 설명합니다.
💌 멘토님의 Comment
: Kafka는 좋은 도구지만, 모든 비동기 작업에 적합한 건 아닙니다. 우리가 발행하고 우리가 소비하는 구조에서 장시간 작업에 Kafka가 필요한가? 라는 질문이 필요합니다.
Kafka는 짧은 트랜잭션을 대량으로 빠르게 처리하는 데 최적화되어 있습니다. 실시간 알림, 로그 수집, 이벤트 스트리밍 같은 작업이죠. 반면 수십 분씩 걸리는 작업은 Kafka의 설계 의도와 맞지 않습니다. 타임아웃을 늘리면 당장은 해결되지만 실제 장애 감지가 그만큼 늦어지는 딜레마에 빠집니다.
RDB 기반 Task Queue의 장점은 상태 관리가 명확하다는 겁니다. 작업이 어떤 상태인지, 언제 마지막으로 Heartbeat가 갱신되었는지 단순 쿼리로 확인할 수 있습니다. 서버가 죽어도 2분 뒤면 다른 Worker가 작업을 이어받습니다. 폴링으로 인한 3초 지연과 DB 부하는 트레이드오프지만 엑셀 다운로드에서 3초는 허용 가능한 수준이죠.
지금 팀에서 Kafka로 처리하고 있는 작업 중에 이런 장시간 작업이 있나요? 혹시 타임아웃을 계속 늘려가며 버티고 있는 건 아닌지 점검해보면 좋겠습니다.
깊이 있는 인사이트와 현실적인 조언이 담긴 멘토님들의 인터뷰와 커리어 성장 콘텐츠가 데브클럽에서 정기적으로 업데이트되고 있습니다.
실력 있는 현직 개발자 멘토들과 직접 소통하고, 생생한 실무 노하우와 커리어 성장 전략을 배워보세요!
이 컨텐츠는 F-Lab의 고유 자산으로 상업적인 목적의 복사 및 배포를 금합니다.
