시작하며가면사배 스터디 2주차! 1장에서 단일 서버부터 수백만 사용자까지의 시스템 진화 과정을 배웠다면, 이번 2장에서는 그런 시스템을 설계하기 전에 반드시 필요한 개략적인 규모 추정(Back-of-the-envelope Estimation)에 대해 다룹니다.처음에는 "봉투 뒷면 계산"이라는 번역이 좀 어색했는데, 실제로 읽어보니 정말 핵심적인 내용이더라고요. 시스템 설계 면접에서도 자주 나오고, 실무에서도 "이 정도 트래픽이면 서버가 몇 대나 필요할까?" 같은 질문에 답할 수 있어야 하거든요.스터디 동기들과 함께 실제 서비스들을 예시로 들어가며 계산해보니, 이론으로만 알던 것들이 구체적인 숫자로 와닿더라고요. "아, 유튜브가 이 정도 규모구나", "우리 회사 서비스와 비교하면 이 정도 차이가 나는구나"..

시작하며항해 플러스 동기들과 함께 "가상 면접 사례로 배우는 대규모 시스템 설계 기초(가면사배)" 독서 스터디를 시작했습니다!앞으로 각 장마다 학습한 내용을 정리해서 공유할 예정인데, 첫 번째로 1장 "사용자 수에 따른 규모 확장성"을 읽고 나니 정말 많은 걸 배웠더라고요.단일 서버에서 수백만 사용자를 지원하는 시스템까지의 진화 과정을 단계별로 설명해놓은 게 인상적이었습니다. 개발자로서 항상 "우리 서비스가 사용자가 많아지면 어떻게 대응해야 할까?"라는 고민이 있었는데, 이 책에서 체계적으로 정리해놓은 내용이 정말 도움이 됐어요.독서 스터디 동기들과 함께 토론하면서 더 깊이 이해할 수 있었고, 혼자만 알고 있기 아까워서 핵심 내용들을 정리해서 공유해보려고 합니다.책에서 제시하는 11단계 시스템 진화 과정..

시작하며최근에 토스 본사에서 열린 TypeScript Backend Meetup #7에 다녀왔습니다.TSBM이 뭔가요?혹시 TSBM을 처음 들어보시는 분들을 위해 간단히 소개하면, TypeScript Backend Meetup의 줄임말로 TypeScript 기반 백엔드 개발자들의 커리어 성장과 네트워킹을 위한 정기 모임입니다. 매월 개최되며, 실무 경험을 바탕으로 한 기술 발표와 자유로운 네트워킹이 특징이에요.공식 GitHub: https://github.com/ts-backend-meetup-ts/meetup공식 유튜브: Typescript Backend Meetup문의: TSBM 공지 오픈카톡방나의 TSBM 여정사실 TSBM은 이번이 처음이 아니에요. 5월에 열린 첫 번째 모임에도 참석했었는데, 그때..

토스 메이커스 컨퍼런스 2025 참석 후기: 대규모 서비스의 기술적 진화를 엿보다참석일: 2025년 7월 25일 (금)장소: 코엑스 컨벤션센터주요 세션: 10개 기술 세션 참석🚀 들어가며토스 메이커스 컨퍼런스 2025에 참석하며 가장 인상 깊었던 점은 "실패를 감추지 않고 드러내며 빠르게 공유하여 다음 선택의 근거로 삼는다"는 토스의 기술 철학이었습니다.20년 된 레거시 시스템의 현대화부터 최신 ML 플랫폼 구축까지, 각 세션에서 공유된 내용은 단순한 성공 사례가 아닌 시행착오와 해결 과정이 담긴 진솔한 경험담이었습니다.💎 핵심 인사이트1️⃣ 레거시는 짐이 아닌 자산이다"20년 레거시를 넘어 미래를 준비하는 시스템 만들기" 세션에서 가장 놀라웠던 점은 토스가 2020년 인수한 20년 된 결제 시스템을..

AI 시대, 개발자는 어떻게 살아남을 것인가?토비님의 "AI 시대 개발자로 살아가는 법" 세미나에서 얻은 통찰과 실무 적용 방안최근 개발자 커뮤니티는 그 어느 때보다 혼란스럽습니다. "AI가 개발자를 대체할 것이다"라는 위기론과 "AI는 개발자를 대체할 수 없다"는 낙관론이 동시에 쏟아지고 있죠.이런 상황에서 《토비의 스프링》 저자이자 31년차 개발자인 토비님이 제시한 "AI 시대 개발자 생존 전략"을 정리해보았습니다.🌪️ 지금은 "AI 대혼란의 시대"토비는 현재를 "AI 시대가 아닌 AI 대혼란의 시대"라고 정의합니다.상반된 메시지들🔴 위기론"신입 개발자 안 뽑습니다" (AI가 대체)저커버그: "1년 내 50% 대체"Claude CEO: "90% 코드를 AI가 생성"🟢 낙관론IBM CEO: "AI..

Dependabot으로 의존성 관리 자동화하기🚀 매일 아침 의존성 업데이트 PR을 확인하는 것이 일상이 된 개발자를 위한 실전 가이드안녕하세요! 오늘은 저희 팀에서 실제로 사용하고 있는 Dependabot 설정과 운영 노하우를 공유해드리려고 합니다.의존성 관리, 정말 귀찮지 않나요? 새로운 보안 패치가 나올 때마다 수동으로 업데이트하고, 어떤 패키지가 outdated인지 확인하고... 이런 반복 작업을 자동화할 수 있다면 얼마나 좋을까요?Dependabot이 바로 그 해답입니다! 🤖왜 Dependabot을 도입했을까?저희 팀도 처음에는 수동으로 의존성을 관리했어요. 하지만 프로젝트가 커지면서 문제가 생겼습니다:📅 업데이트를 깜빡하는 경우가 자주 발생🔒 보안 취약점 대응이 늦어짐⏰ 의존성 관리에 너..

BigQuery Storage Read API와 DATE 타입 불일치 해결하기들어가며최근 프로젝트에서 BigQuery의 성능 개선을 위해 Storage Read API를 도입하는 과정에서 흥미로운 문제를 만났습니다. GoogleSQL의 DATE 타입과 Apache Avro의 DATE 타입 간의 불일치로 인해 예상치 못한 데이터 변환 이슈가 발생했는데요, 이를 해결하는 과정을 공유해보려 합니다.왜 Storage Read API인가?BigQuery에서 데이터를 읽는 방법은 크게 두 가지가 있습니다:구분Legacy APIStorage Read API통신 방식REST 기반gRPC 기반데이터 형식JSONApache Avro/Arrow처리 방식순차적 페이지네이션병렬 스트림성능기준약 20-30% 개선메모리기준상당한 ..

Tistory에서 Mermaid 다이어그램 다크모드 자동 전환 구현하기"pronist/hello 스킨과 완벽하게 동기화되는 Mermaid 다이어그램 만들기"프롤로그: 다크모드 시대의 다이어그램 딜레마기술 블로그를 운영하다 보면 다이어그램은 필수입니다. 복잡한 아키텍처를 설명하거나 플로우차트를 그릴 때 Mermaid만큼 편리한 도구도 없죠.하지만 다크모드가 대세가 된 지금, 한 가지 문제가 있었습니다:😎 사용자가 다크모드로 전환📊 다이어그램은 여전히 라이트 테마👀 눈이 아픈 상황 발생...특히 Tistory + pronist/hello 스킨을 사용하는 환경에서는 더욱 복잡했습니다. 스킨의 다크모드 토글과 Mermaid 테마가 따로 놀았거든요.문제 상황 분석1. Tistory의 코드 블록 제약Tisto..

사내 어드민의 딜레마 - t4g.small의 한계"하루 4번 서버가 죽는 이유를 찾아서"프롤로그: 평범한 월요일 오전의 악몽flowchart LR %% ─── Google Cloud ─── subgraph Google Cloud BQ["BigQuery\n(360일 지표)"] DP["Dataflow\n배치 파이프라인"] MT["Metrics Table\n파티션 테이블"] end %% ─── Admin VPC ─── subgraph Admin VPC API["NestJS Admin API"] UI["어드민\nDashboard"] end Scheduler["Cloud Scheduler\n하루 4회 트리거"] ..

사내 프로젝트에서 구글 빅쿼리 데이터를 조회하고 특정 시점의 스냅샷을 저장해야 하는 요구사항이 있었습니다. 처음엔 MySQL을 선택했지만 향후 S3 연동도 고려하고 있습니다.배경 및 문제점기존 방식MySQL의 JSON 타입 컬럼으로 데이터를 저장했습니다.다수의 부동소수점(float) 값이 포함된 JSON 데이터에서 부동소수점 오차로 인한 데이터 불일치가 발생했습니다.이 문제는 TDD를 통해 조기에 발견되었습니다.해결 방안데이터 일관성을 위해 JSON 데이터를 문자열로 변환하고, MySQL 컬럼 타입을 longtext로 변경했습니다.새로운 문제점빅쿼리에서 조회한 테이블 중 하나가 약 66MB 크기로, MySQL의 max_allowed_packet(64MB) 한계를 초과하여 에러가 발생했습니다.단순한 설정 ..