총 75개의 글
가면사배 스터디 2주차! 1장에서 단일 서버부터 수백만 사용자까지의 시스템 진화 과정을 배웠다면, 이번 2장에서는 그런 시스템을 설계하기 전에 반드시 필요한 개략적인 규모 추정(Back-of-the-envelope Estimation)에 대해 다룹니다.처음에는 "봉투 뒷면 계산"이라는 번역이 좀 어색했는데, 실제로 읽어보니 정말 핵심적인 내용이더라고요. 시
최근에 토스 본사에서 열린 TypeScript Backend Meetup #7에 다녀왔습니다. 혹시 TSBM을 처음 들어보시는 분들을 위해 간단히 소개하면, TypeScript Backend Meetup의 줄임말로 TypeScript 기반 백엔드 개발자들의 커리어 성장과 네트워킹을 위한 정기 모임입니다. 매월 개최되며, 실무 경험을 바탕으로 한 기술 발표와
항해 플러스 동기들과 함께 "가상 면접 사례로 배우는 대규모 시스템 설계 기초(가면사배)" 독서 스터디를 시작했습니다!앞으로 각 장마다 학습한 내용을 정리해서 공유할 예정인데, 첫 번째로 1장 "사용자 수에 따른 규모 확장성"을 읽고 나니 정말 많은 걸 배웠더라고요.단일 서버에서 수백만 사용자를 지원하는 시스템까지의 진화 과정을 단계별로 설명해놓은 게 인상
> 참석일: 2025년 7월 25일 (금) > 장소: 코엑스 컨벤션센터 > 주요 세션: 10개 기술 세션 참석 --- 토스 메이커스 컨퍼런스 2025에 참석하며 가장 인상 깊었던 점은 "실패를 감추지 않고 드러내며 빠르게 공유하여 다음 선택의 근거로 삼는다"는 토스의 기술 철학이었습니다.20년 된 레거시 시스템의 현대화부터 최신 ML 플랫폼 구축까지, 각
> 토비님의 "AI 시대 개발자로 살아가는 법" 세미나에서 얻은 통찰과 실무 적용 방안 최근 개발자 커뮤니티는 그 어느 때보다 혼란스럽습니다. "AI가 개발자를 대체할 것이다"라는 위기론과 "AI는 개발자를 대체할 수 없다"는 낙관론이 동시에 쏟아지고 있죠.이런 상황에서 《토비의 스프링》 저자이자 31년차 개발자인 토비님이 제시한 "AI 시대 개발자 생존
> ? 매일 아침 의존성 업데이트 PR을 확인하는 것이 일상이 된 개발자를 위한 실전 가이드 안녕하세요! 오늘은 저희 팀에서 실제로 사용하고 있는 Dependabot 설정과 운영 노하우를 공유해드리려고 합니다.의존성 관리, 정말 귀찮지 않나요? 새로운 보안 패치가 나올 때마다 수동으로 업데이트하고, 어떤 패키지가 outdated인지 확인하고... 이런 반복
최근 프로젝트에서 BigQuery의 성능 개선을 위해 Storage Read API를 도입하는 과정에서 흥미로운 문제를 만났습니다. GoogleSQL의 DATE 타입과 Apache Avro의 DATE 타입 간의 불일치로 인해 예상치 못한 데이터 변환 이슈가 발생했는데요, 이를 해결하는 과정을 공유해보려 합니다. BigQuery에서 데이터를 읽는 방법은 크게
> "pronist/hello 스킨과 완벽하게 동기화되는 Mermaid 다이어그램 만들기" 기술 블로그를 운영하다 보면 다이어그램은 필수입니다. 복잡한 아키텍처를 설명하거나 플로우차트를 그릴 때 Mermaid만큼 편리한 도구도 없죠.하지만 다크모드가 대세가 된 지금, 한 가지 문제가 있었습니다: 특히 Tistory + pronist/hello 스킨을 사용하
> "하루 4번 서버가 죽는 이유를 찾아서" 마케팅 프로젝트는 전형적인 사내 어드민 시스템입니다. 평상시에는 문제없었습니다. 하지만 새로운 요구사항이 들어왔습니다: 그리고 매일 4번, 조용하던 서버에 지옥이 펼쳐지기 시작했습니다. 최악의 타이밍: 오전 9:30과 오후 3:30은 마케팅 팀이 가장 활발하게 사용하는 시간이었습니다. 문제점: - t4g.smal
사내 프로젝트에서 구글 빅쿼리 데이터를 조회하고 특정 시점의 스냅샷을 저장해야 하는 요구사항이 있었습니다. 처음엔 MySQL을 선택했지만 향후 S3 연동도 고려하고 있습니다. - MySQL의 JSON 타입 컬럼으로 데이터를 저장했습니다. - 다수의 부동소수점(float) 값이 포함된 JSON 데이터에서 부동소수점 오차로 인한 데이터 불일치가 발생했습니다.
기존 Layered Architecture의 문제점을 해결하기 위해 UseCase 패턴을 적용하여 Application Layer를 추가한 구조를 제안합니다.✅ 핵심 개선점: - 서비스 간 직접 호출을 제거하고, UseCase 단위로 비즈니스 로직을 모듈화 - Application Layer를 추가하여 비즈니스 로직을 분리하고, 서비스 간 결합도를 낮춤 -
마지막 글을 작성한 지 벌써 3개월이 지났네요. 정신없이 업무를 하다 보니 블로그를 잠시 쉬었는데, 최근 실무에서 아키텍처 개선을 고민하면서 공유하고 싶은 내용이 많아졌어요.사실 이 내용은 사내 기술 세미나에서 2주에 한 번씩 공유했던 내용인데, 내부 환경에 맞춰 다듬다 보니 블로그에 바로 올리지는 못했어요. 이번 기회에 정리해서 공유해보려고 합니다. --
항해 플러스 백엔드 코스를 수료하게 되었습니다. 10주라는 시간은 짧게 느껴질 수도 있지만, 실제로는 꽤 긴 여정이었습니다. 9월 중순부터 11월 말까지 휴식 없이 달려온 제 자신에게 칭찬을 보내고 싶습니다. (사실, 사전 스터디까지 포함하면 더 긴 여정이었습니다.) 대학교 3학년 때 교수님의 회사로 조기 취업하며 만 3년 2개월 동안 SI, B2C, B2
지원페이지에서 추천 코드에 `3ZTeU1`를 입력하시면 `20만원` 할인 혜택을 받을 수 있습니다. 항해 플러스 과정에 관심 있는 분들은 아래 링크를 통해 신청해보세요! 궁금한 점이나 커피챗을 원하시면 LinkedIn이나 `kboxstar@gmail.com`으로 연락주세요.항해 플러스 과정 페이지 개발자 커리어 개척 캠프 항해99, 첫 취업부터 현직자 역량
지원페이지에서 추천 코드에 `3ZTeU1`를 입력하시면 `20만원` 할인 혜택을 받을 수 있습니다. 항해 플러스 과정에 관심 있는 분들은 아래 링크를 통해 신청해보세요! 궁금한 점이나 커피챗을 원하시면 LinkedIn이나 `kboxstar@gmail.com`으로 연락주세요.항해 플러스 과정 페이지 --- 이번 주차에는 인덱싱을 사용한 쿼리의 성능 개선을 진