멘토 Pick! 25년 12월 둘째 주 아티클 모음

여러분 안녕하세요~ 👋

이번 주 멘토's Pick 아티클이 도착했습니다!

멘토님께서는 어떤 아티클을 읽고 어떤 중요한 인사이트를 얻으셨을까요? 멘토님의 선택을 확인해 보세요!

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

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

💡Slack’s Migration to a Cellular Architecture

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

• 2021년 AZ 장애 시 단일 AZ 문제가 전체 서비스에 영향을 준 사례에서 시작해, Cellular Architecture로 마이그레이션한 과정을 소개합니다

💌 멘토님의 Comment
: AZ를 나눠놨으니 한 곳이 죽어도 괜찮을 거라고 생각하기 쉽습니다. 하지만 Slack은 2021년 장애에서 그게 아니라는 걸 배웠습니다. Gray Failure상태 (시스템의 특정 구성 요소가 비정상적으로 작동하지만, 기존의 모니터링 시스템이나 상태 확인(health check)에는 정상으로 보이는 상태)에 대해 방지하지 못했고 결고 장애 자동감지가 동작하지 않았습니다.

 

분산시스템에서 Gray Failure를 어떻게 방지해야할까요? 자동보다 수동으로 변경하는게 더 나을 때가 있으며, 운영 중인 시스템에서 특정 AZ를 5분 안에 뺄 수 있는지 한번 점검해보면 좋겠습니다

💡Stop Requiring CRLF Line Endings

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

• HTTP, SMTP, CSV 등 대부분의 인터넷 프로토콜이 줄바꿈으로 CR(\r)LF(\n)를 요구하는 이유와 그 역사적 배경을 설명합니다.
• SQLite 창시자가 작성한 "이제 CR은 그만 보내자"는 선언문입니다.

💌 멘토님의 Comment
: 왜 HTTP 헤더는 \n이 아니라 \r\n으로 끝나야 할까요? 최초의 문제는 1950년대 텔레타이프 기계에 있습니다. 당시 프린터는 줄바꿈할 때 프린트 헤드가 물리적으로 왼쪽 끝까지 이동해야 했는데, 그 시간이 꽤 걸렸어요. 그래서 CR(캐리지 리턴)으로 먼저 헤드를 움직이기 시작하고, 그 사이에 LF(라인 피드)로 종이를 올리는 식으로 시간을 벌었습니다.

 

문제는 이 70년 된 하드웨어 제약이 아직도 프로토콜 스펙에 남아있다는 겁니다. 사실 RFC 2616도, 최신 RFC 9112도 "bare LF를 받아들여도 된다"고 권장하고 있어요. 대부분의 서버와 클라이언트가 \n만으로도 잘 동작합니다. 그런데 스펙에는 여전히 CRLF가 "필수"로 적혀 있죠.

이런 역사적 잔재는 생각보다 많습니다. 

 

왜 이메일 첨부파일이 Base64로 33%나 커져야 하는지, 왜 URL에 공백 대신 %20을 써야 하는지. 지금 당연하게 쓰는 것들이 사실은 수십 년 전 제약의 흔적일 수 있습니다. 가끔은 "왜 이렇게 동작하지?"라고 질문해보면 재미있는 이야기가 나옵니다.

💡System Design Interview Concepts – Eventual Consistency

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

• 분산 시스템에서 Strong Consistency와 Eventual Consistency의 차이점, 그리고 각각이 적합한 상황을 설명합니다.

💌 멘토님의 Comment
: "데이터가 항상 최신 상태여야 한다"는 생각은 당연해 보이지만, 분산 시스템에서는 이 당연함이 엄청난 비용을 요구합니다. 모든 노드가 동기화될 때까지 읽기를 막아야 하니까요. 그래서 CAP 정리는 네트워크 파티션이 발생했을 때 일관성(Consistency)과 가용성(Availability) 중 하나를 선택하라고 말합니다.

 

Eventual Consistency는 지금 당장은 안 맞을 수 있지만, 결국엔 맞춰진다는 개념으로 즉시성이 중요하지 않은 데이터에 대해서는 이벤트로 인해 최종적으로 일관성이 적용되게 만든다면 분산시스템에서 안전하게 데이터를 저장할 수 있다는 개념입니다. 예를 들어, DNS가 전 세계에 전파되는 데 몇 시간 걸려도 인터넷은 잘 돌아갑니다. 물론 은행계좌같은 데이터가 Eventual Consistency를 적용하면 안되겠죠. 여러분의 시스템에서 정말 Strong Consistency가 필요한 데이터는 얼마나 될까요?

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

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

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