#architecture
노트 117개
Frontend
Frontend Architecture폴더 구조, 의존성, SOLID, Feature-Sliced Design처럼 프론트엔드 코드를 어떻게 나누고 어디에 두는지에 관한 설계 원칙 모음.
Frontend › Architecture
결합도를 낮추는 전략결합도는 코드를 고쳤을 때 영향이 미치는 범위다. 모듈 결합도의 고전적 6단계 분류(자료~내용)와 높은 결합의 신호를 정리하고, 페이지 전체 쿼리 파라미터를 한 훅에 몰지 않고 책임별로 쪼개고, 앞으로 갈라질 수 있는 코드는 중복을 허용하고, Props Drilling은 조합(children) 패턴으로 먼저 풀고 마지막에 Context를 쓴다. 앱 규모에서는 기능 모듈이 서로를 부르지 않고 퍼사드(샌드박스)와 중재자(앱 코어)를 거치게 한다.
Frontend › Architecture
변경하기 쉬운 코드의 네 가지 기준좋은 프론트엔드 코드는 변경하기 쉬운 코드다. 가독성·예측 가능성·응집도·결합도 네 기준으로 판단하고, 네 기준은 서로 부딪히므로 상황에 따라 무엇을 우선할지 고른다. 기준별 개선 전략과 자주 논쟁되는 컨벤션, 코드 품질을 챙기는 이유·타이밍·감각 기르는 법을 함께 정리한다.
Frontend › Architecture
응집도를 높이는 전략응집도는 함께 수정돼야 할 코드가 항상 함께 수정되는지다. 모듈 응집도의 고전적 7단계 분류(기능적~우연적)와 낮은 응집의 신호를 정리하고, 함께 바뀌는 파일을 도메인 디렉토리에 모으고, 매직 넘버를 상수로 묶어 한쪽만 바뀌는 일을 막고, 폼은 변경 단위에 따라 필드 단위 검증과 스키마 기반 폼 전체 검증 중 하나를 고른다.
Frontend › Architecture
추상화 계층과 데이터 흐름요구사항을 데이터로 표현하면 구현이 되고, 구현에 알맞은 수준의 이름을 붙이면 추상화가 된다. 잘 변하지 않는 추상화가 쌓여 계층이 되고, 계층 사이를 사용자 중심으로 순환하는 데이터 흐름이 코드의 자리를 정한다. 요구사항을 이 계층과 흐름의 구간으로 쪼개 채우는 사고법(그라데이션 사고)을 정리한다.
Frontend › Architecture
컴포넌트를 분리하는 기준과 방법컴포넌트를 나누는 이유는 재사용, 복잡성, 렌더링 범위 세 가지다. 재사용할 컴포넌트는 주변 HTML 문맥에 기대지 않을 만큼 일반적이어야 하고, 쓰는 곳마다 조건문이 붙는다면 중복이 아니므로 고유한 부분은 props로 넘긴다. 복잡한 컴포넌트는 책임과 변경 빈도(UI vs 비즈니스 로직)를 기준으로 나누고, 서로 무관한 상태는 각자의 컴포넌트로 내린다.
Frontend › Architecture
프론트엔드 폴더 구조의 진화역할 기반 폴더(components·hooks·services)에서 출발해 순수 UI와 도메인 컴포넌트를 나누고, 페이지를 독립시키고, 다시 엔티티(데이터)·위젯(화면)·기능(행동) 중심으로 응집해 가는 과정을 따라가며, 좋은 폴더 구조는 팀의 멘탈 모델과 일치하는 구조라는 결론을 정리한다. FSD를 규칙이 아니라 렌즈로 쓰는 법.
Frontend › Architecture
프론트엔드 MV* 아키텍처의 흐름: MVC에서 MVI까지MVC·MVP·MVVM의 구조와 차이, 수동적 뷰·감독 컨트롤러·프레젠테이션 모델·Model 2 같은 변형, 웹 프론트엔드의 아키텍처가 MVC → MVVM → Container-Presenter → Flux → 가벼운 전역 스토어·서버 상태 관리로 바뀌어 온 흐름과, Flux가 reducer와 단일 스토어의 Redux로 줄어든 과정, 그 흐름을 정리한 MVI(Model-View-Intent) 아키텍처. 뷰와 비즈니스 로직을 분리하고, 뷰는 의도만 전하고, 데이터는 한 방향으로 돈다.
Frontend › Architecture
프론트엔드에서 관심사의 분리관심사의 분리는 한 단위가 하나의 선명한 기준으로 구분되게 해 인지 부하를 줄이는 일이다. 프론트엔드는 역할(HTML·CSS·JS) → 기능(컴포넌트) → 컴포넌트 안의 다시 계층으로 분리 축을 바꿔 왔고, 관심사는 모듈·레이어·데이터 흐름 여러 방향이 있어 프로젝트 시기마다 우선순위가 달라진다.
Frontend › Architecture
프론트엔드에서 의존성 관리하기의존성은 곧 변경에 노출되는 관계다. 변수는 스코프를 좁히고 값을 바꾸는 길을 하나로 만들고, 여러 곳이 쓰는 함수는 의존성 역전으로 계약에 기대게 하고, 타입은 API 응답이 아니라 잘 바뀌지 않는 도메인 타입에 기대게 한다.
Frontend › Architecture
Atomic Design과 컴포넌트 폴더 구조Brad Frost의 Atomic Design(원자 → 분자 → 유기체 → 템플릿 → 페이지)은 디자인 시스템을 이해하기 위한 멘탈 모델이지 폴더 구조 규칙이 아니다. 그대로 폴더로 쓰면 분자·유기체 경계가 흐려지고 계층 하나로는 분류가 안 된다. 기획·디자인이 부르는 이름으로 먼저 나누고, 이름이 더 없는 곳부터 계층 구조를 쓰는 절충안을 정리한다.
Frontend › Architecture
Feature-Sliced Design프론트엔드 코드를 레이어 → 슬라이스 → 세그먼트 3단계로 나누고, 위 레이어만 아래 레이어를 쓰게 하며, 슬라이스는 Public API로만 드나들게 하는 아키텍처 방법론. 구조, 규칙, 다른 구조와의 비교, Next.js와 함께 쓸 때의 충돌, 그리고 레이어 경계를 정하고 점진적으로 도입하는 법을 정리한다.
Frontend › Architecture
UI 변경 감지: 상태가 바뀌면 화면은 어떻게 따라 바뀌나UI 프레임워크의 핵심 문제는 상태를 화면으로 투영하고, 상태가 바뀌었을 때 최소한의 DOM만 고치는 것이다. 전부 새로 그리기, 수동 재렌더, 데이터 바인딩(관찰 가능한 모델·Proxy), 더티 체킹(AngularJS digest·zone.js), 가상 DOM 비교, 불변 데이터로 비교 건너뛰기, 시그널, 컴파일러까지 변경을 '언제·어떻게 아는가'로 나눠 비교하고, React Fiber가 렌더링을 쪼개 우선순위를 매기는 방식을 정리한다.
Frontend › CSS
객체 지향 CSS(OOCSS)구조와 겉모양을 분리하고, 컨테이너와 콘텐츠를 분리해 재사용 가능한 클래스 '객체'로 CSS를 짜는 방법론. 미디어 객체 같은 대표 패턴, 특정도 전쟁을 피하는 규칙, 시맨틱 클래스와의 긴장, 캐스케이드 기본값·타이포그래피 전략·객체 범위 같은 실무 전략과 흔한 오용, BEM·유틸리티 CSS로 이어진 흐름까지.
Frontend › CSS
유틸리티 우선 CSS속성 하나짜리 클래스를 조합해 화면을 만들고, 반복이 보일 때만 컴포넌트로 뽑는 CSS 작성 방식. '관심사의 분리'를 의존 방향의 선택으로 다시 보는 관점, 시맨틱 클래스에서 유틸리티까지 넘어가는 단계, 정해진 값만 고르게 해 생기는 일관성, 인라인 스타일과의 차이, 장단점과 Tailwind CSS v4 기준의 현재 사용법을 정리한다.
Frontend › CSS
CSS 설계 방법론: BEM과 ITCSS전역 범위와 명시도 문제를 규칙으로 다스리는 CSS 방법론. 이름으로 관계를 드러내는 BEM(.block__element--modifier), 파일을 일반→구체 순서의 일곱 층으로 쌓는 ITCSS와 BEMIT 접두사, OOCSS·SMACSS와의 차이를 비교하고, 지금은 @layer·@scope·CSS Modules가 같은 일을 어떻게 나눠 맡는지 정리한다.
Frontend › CSS
CSS-in-JS와 CSS Modules대규모 CSS의 일곱 가지 문제(전역 이름 공간, 의존성, 죽은 코드, 압축, 상수 공유, 비결정적 우선순위, 격리 깨짐)와 이를 빌드 도구로 푼 CSS Modules, JS로 푼 CSS-in-JS를 비교한다. 런타임 방식에서 빌드 타임(zero-runtime) 방식으로 옮겨 간 이유와 서버 컴포넌트 시대의 선택지까지 정리한다.
Frontend › CSS
Sass: 파일 구조, 믹스인과 @extendCSS 전처리기 Sass의 쓰임새와 설치, 파셜 파일을 폴더별로 나누는 아키텍처(7-1 패턴), 중첩·파일 크기 규칙, 믹스인과 @extend의 차이와 둘을 합친 DRY 믹스인, @extend로 프레임워크 클래스를 시맨틱한 이름 뒤에 숨기는 법.
Frontend › Mobile
모바일 앱 프레임워크 비교: 네이티브·하이브리드·크로스 플랫폼네이티브, 웹뷰 기반 하이브리드, 네이티브로 컴파일되는 크로스 플랫폼 앱의 원리와 장단점. PhoneGap·Cordova에서 Capacitor로 이어진 하이브리드 계보와 흔한 실수(deviceready, CDN 자산, 버전 고정, CSP, 웹사이트 감싸기)도 정리한다. 코딩 에이전트가 이중 구현 비용을 낮추며 네이티브로 돌아가는 판단 기준과 대규모 이전 원칙도 다룬다.
Frontend › Mobile
Flutter의 구조와 위젯 트리Flutter는 Dart 프레임워크·C++ 엔진·플랫폼 임베더의 세 층으로 이루어져, OS의 UI 컴포넌트를 빌리지 않고 화면을 직접 그린다. 프레임워크 라이브러리(Material, Cupertino, Widgets, Rendering 등)의 역할, Widget·Element·RenderObject 세 트리, StatefulWidget 순서를 바꿀 때 Key가 필요한 이유, 패키지·플러그인을 만들어 pub.dev에 배포하는 법을 정리한다.
Frontend › React
리액트 상태 관리의 흐름과 고르는 기준상태를 종류(로컬·서버·URL·폼·전역 클라이언트)로 먼저 나누고, 전역 상태 라이브러리는 읽기·쓰기·리렌더링 최적화·메모리 네 가지 문제를 어떻게 푸는지로 비교한다. Flux·Redux에서 Context, 서버 상태 라이브러리, atom·proxy 기반 라이브러리로 이어진 흐름까지.
Frontend › React
실시간 채팅 앱의 데이터 흐름: REST와 WebSocket 역할 나누기채팅 앱은 상태 조회·변경은 REST로, 새로 생기는 이벤트 전달은 WebSocket으로 나눈다. 리소스 계층이 드러나는 URL 설계, 소켓 연결의 수명 관리, optimistic UI와 중복 방지, 긴 메시지 목록의 렌더링 최적화 포인트를 정리한다.
Frontend › Testing
험블 객체 패턴: 테스트하기 쉬운 코드가 좋은 코드인 이유목은 비용에 따라 네트워크 목·전역 목·스파이·더미/스텁 네 단계로 나뉘고, 비싼 목이 많다는 것은 설계 문제의 신호다. 전역 객체·네트워크처럼 테스트하기 어려운 코드를 얇은 험블 객체로 떼어 내 인터페이스 뒤에 두면 나머지는 더미와 스텁만으로 테스트되고, 코드는 자연스럽게 SOLID에 가까워진다.
Frontend › Web
브라우저 안 빌드·프리뷰 환경: AI가 만든 화면을 바로 띄우기AI가 생성한 React 코드를 사용자 브라우저에서 바로 빌드해 보여 주는 프리뷰 런타임. 데이터 정책은 API 프록시 플랫폼이 맡고 화면만 AI가 만드는 분리, 서버 dev 서버·Sandpack·WebContainers·직접 구성의 비교, 가상 파일 시스템 + esbuild-wasm + 패키지 조합 해시로 미리 번들한 의존성 + import map 구조를 다룬다.
Frontend › Web
웹 개발에 대한 이상한 믿음들브라우저 엔지니어·표준 제정자·웹 개발자가 웹 개발을 잘 안다는 믿음, 브라우저는 SPA에 맞지 않는다, MPA가 SPA를 대체한다, 모든 사이트는 JS 없이 동작해야 한다, 빌드 단계는 필요 없다는 주장을 하나씩 따져 본다. 공통된 오류는 내가 겪는 웹이 웹 개발 전체를 대표한다고 여기는 것이다.
Frontend › Web
웹 아키텍처의 다음 전환: MPA에서 PESPA까지MPA → PEMPA → SPA를 거쳐 온 웹 앱 아키텍처가 '점진적으로 향상된 SPA(PESPA)'로 옮겨 가고 있다. 코드가 어디에 사는지, 각 단계가 무엇을 풀고 무엇을 남겼는지 비교한다.
Frontend
기술 스택 고르기기술 스택은 혼자가 아니라 함께 쓰는 것이라 커뮤니티가 키운다. 기술 수용 주기·캐즘·하이프 사이클로 유행이 만들어지는 과정을 보고, 범용성·학습 비용·커뮤니티·인력·지속 가능성 다섯 기준, 큰 팀이 유지 보수성과 안정성을 위해 보는 결정 축(도구 강제·경계·재현성), 언어부터 배포·모니터링까지 계층별 2026년 기본 선택과 고르는 이유, 레거시를 대하는 자세를 정리했다.
Frontend
React와 Vue 말고: Svelte, Angular, Preact, Alpine.js, HTMXReact·Vue 다음으로 많이 쓰이는 프레임워크들의 특징을 비교한다. 컴파일러, 풀스택 프레임워크, 경량 대체재, HTML 속성 기반 도구로 성격이 갈린다. Knockout부터 Svelte까지 프레임워크의 계보와 컴파일러 방식이 빠른 이유도 다룬다.
Frontend
UI 엔지니어링의 열두 가지 문제UI 엔지니어링의 실력은 라이브러리가 아니라 문제를 아는 데서 나온다. 일관성·반응성·지연·내비게이션·낡은 캐시·엔트로피·우선순위·접근성·국제화·전달·복원력·추상화라는 열두 문제는 툴팁부터 대형 SNS까지 어느 규모에서나 나타나며, 각 문제에 오늘날 쓰는 도구와 함께 정리한다.
Backend › Architecture
개발자 머피의 법칙: 백엔드 방어 체크리스트잘못될 수 있는 것은 결국 잘못된다. 클라이언트 값 불신, 서버 재계산, 인증과 권한 분리, 입력 범위 제한, 운영 권한 통제, 배치·로그·알림 분리, SPOF 제거처럼 감당할 수 없는 사고는 이미 일어난 것으로 보고 먼저 막는다.
Backend › Architecture
결제 시스템 설계: 흐름, 멱등성, 대사, 핫스팟 계정구매 버튼 뒤에서 결제 서비스·결제 실행기·PSP·지갑·원장이 어떻게 맞물리는지 정리했다. 이중 결제를 막는 재시도+멱등 키, 정보 흐름과 자금 흐름의 어긋남을 메우는 대사(reconciliation), 한 계좌에 쓰기가 몰리는 핫스팟 계정 대응, 결제 시스템을 장애에 강하게 만드는 운영 원칙까지 다룬다.
Backend › Architecture
고가용성 이중화 구조와 장애 감지가용성을 나인(nines)으로 재는 법과 직렬·병렬 구성의 가용성 계산, 주-백업·주-보조·주-주·핫-핫·핫-웜·단일 리더·리더 없는 클러스터 같은 이중화 구조, 결함 허용 설계의 여섯 원칙, 하트비트로 노드 장애를 감지하는 방식, 페일오버 절차와 비동기 복제의 유실, 스플릿 브레인을 막는 정족수·에포크·펜싱·리스를 정리했다.
Backend › Architecture
고전 분산 시스템 설계: GFS, MapReduce, Bigtable, Chubby, Dynamo구글의 GFS·MapReduce·Bigtable·Chubby와 아마존의 Dynamo 논문이 남긴 설계 아이디어를 정리했다. 단일 마스터와 큰 청크, 계산을 데이터 쪽으로 보내기, 정렬된 맵과 LSM 저장, 굵은 락과 시퀀서, 일관된 해싱·벡터 시계·느슨한 정족수 같은 기법이 HDFS·Spark·HBase·Cassandra·ZooKeeper 같은 오픈소스로 어떻게 이어졌는지까지 다룬다.
Backend › Architecture
권한 시스템 설계: ACL, RBAC, ABAC권한 시스템은 '누가 무엇에 어떤 행동을 할 수 있나'를 정하는 모델을 고르는 일이다. 자원마다 허용 목록을 다는 ACL, 소유자가 정하는 DAC, 등급 라벨로 강제하는 MAC, 역할로 묶는 RBAC, 속성 조건으로 판단하는 ABAC, 관계 그래프로 판단하는 ReBAC가 있다. 대부분 RBAC로 시작하고 예외가 늘면 속성이나 관계를 더한다.
Backend › Architecture
뉴스 피드 설계: 연결, 활동, 팬아웃뉴스 피드는 「누구와 연결됐나」와 「누가 무엇을 했나」 두 데이터를 합쳐 사용자마다 다른 목록을 만드는 문제다. 읽을 때 모으는 방식(스캐터·개더)과 쓸 때 받은편지함에 뿌리는 방식(팬아웃)의 차이, 활동 복제와 집계·중복 제거·점수 매기기, 비정규화와 캐시로 타임라인을 빠르게 만드는 법을 정리했다.
Backend › Architecture
대규모 서비스 기술 스택 해부Netflix·Uber·Reddit·Twitter 같은 대규모 서비스의 기술 스택을 계층별로 겹쳐 보고 반복되는 설계 선택을 정리했다. 데이터 성격별로 DB를 고르는 폴리글랏 저장, 캐시를 조회 가속 이상으로 쓰는 네 가지 방식, 비싼 작업을 큐로 미루고 CDC로 캐시를 맞추는 패턴, 표준화된 이벤트 플랫폼, 카나리 배포 중심의 CI/CD, 자동 버그 수정과 전용 하드웨어까지 다룬다.
Backend › Architecture
대규모 웹 크롤러 설계하루 10억 페이지 규모로 웹을 크롤링하는 시스템의 설계 원칙. 예의(robots.txt, 도메인당 지연)를 첫 제약으로 두고, 기능별 머신 풀 대신 도메인 샤드마다 모든 기능을 담은 독립 노드로 나누며, 프런티어·준비 큐·블룸 필터를 인메모리 저장소에 둔다. I/O에 묶인 페처는 비동기로, CPU에 묶인 파서는 프로세스로 늘리고, 요청당 과금되는 객체 스토리지보다 로컬 스토리지를 검토한다. 병목은 네트워크·DNS가 아니라 커진 페이지의 파싱과 TLS 핸드셰이크(CPU)이고, 메모리는 인기 도메인의 프런티어라는 꼬리에서 터진다.
Backend › Architecture
대규모 트래픽에서 서비스를 지키는 설계읽기 위주 서비스가 평소의 몇 배로 치솟는 트래픽을 버티는 방법. CDN과 웹 서버로 WAS 앞단에서 부하를 덜고, 미리 만들어 둔 정적 응답으로 빈 화면을 막고, 서킷 브레이커·서비스 디스커버리로 장애 전파를 끊고, 한계치 모니터링과 자동 방어 모드로 사람 없이도 대응하는 구조를 정리했다.
Backend › Architecture
대기열 시스템(가상 대기실) 설계순간적으로 몰리는 트래픽을 서버 증설 대신 줄 세우기로 흡수하는 가상 대기실의 구조를 정리했다. Redis Sorted Set에 도착 시각을 점수로 넣어 순번을 매기고, 주기 작업이 정해진 유입량만큼 대기→입장→종료 상태로 옮기는 방식이 핵심이다.
Backend › Architecture
데이터 관리 패턴: CDC, 이벤트 소싱, CQRS, 최종 일관성데이터가 여러 서비스·저장소에 흩어질 때 쓰는 패턴을 모았다. DB 변경을 로그에서 읽어 퍼뜨리는 CDC, 상태 대신 이벤트를 저장하는 이벤트 소싱, 읽기·쓰기 모델을 나누는 CQRS, 인덱스 테이블, 최종 일관성을 만드는 네 가지 방법(이벤트·백그라운드 동기화·사가·CQRS), 이벤트와 스키마의 호환성 규칙(Avro, 스키마 레지스트리)까지 다룬다.
Backend › Architecture
도메인 주도 설계(DDD)비즈니스 도메인을 모델로 표현하고 그 모델이 코드·DB·API 설계를 이끌게 하는 방법론이다. 유비쿼터스 언어와 바운디드 컨텍스트로 모델의 경계를 잡고, 엔티티·값 객체·애그리거트로 모델을 짜며, 리포지토리·팩토리·도메인 서비스·도메인 이벤트로 다룬다.
Backend › Architecture
동영상 스트리밍 서비스 설계: Netflix·YouTubeNetflix·YouTube 같은 주문형 동영상 서비스의 설계다. 요구 사항과 규모 추정(하루 500TB 업로드), 데이터 모델과 API, 업로드 뒤 큐로 도는 처리 파이프라인(장면 단위 청크, 콘텐츠 검사, 트랜스코딩, 화질 변환), CDN과 ISP 안에 서버를 두는 Open Connect, 적응형 비트레이트와 이어 보기, 검색·트렌드·공유, 지역 차단과 추천을 정리했다.
Backend › Architecture
라이브 스트리밍의 구조: 인코딩, 세그먼트, ABR, CDN라이브 스트리밍은 캡처한 영상을 압축·인코딩하고, 몇 초 단위 세그먼트로 잘라, 화질별로 여러 벌 만든 뒤(적응형 비트레이트) CDN 엣지로 퍼뜨려 시청자가 가까운 곳에서 받게 한다. 송출은 주로 RTMP·SRT, 시청은 HTTP 기반 HLS·DASH를 쓰고, 1초 미만 지연이 필요하면 WebRTC를 쓴다.
Backend › Architecture
로드 밸런서여러 서버 앞에서 트래픽을 나눠 주는 로드 밸런서. 하는 일(분산, 헬스 체크와 장애 우회, TLS 종료, 세션 고정, 수평 확장, 플랫폼·경로별 라우팅, 영역 간 분산), L4와 L7의 차이, 하드웨어·소프트웨어·클라우드·GSLB 같은 형태, 분산 알고리즘을 정리했다.
Backend › Architecture
마이크로서비스 아키텍처큰 시스템을 비즈니스 기능 단위의 작은 서비스로 나누고, 서비스마다 데이터와 배포를 따로 갖게 하는 구조다. 운영에는 API 게이트웨이, 서비스 레지스트리, 인증 서버, 비동기 메시징, 메트릭·로그 수집이 따라붙는다. 서비스 협업은 오케스트레이션과 코레오그래피 두 방식이 있고, 지연에 민감하거나 상태를 메모리에 둬야 하는 시스템에는 모놀리스가 낫다.
Backend › Architecture
멀티플레이 게임 서버 설계: 턴제 비동기와 실시간온라인 멀티플레이 게임을 두 갈래로 정리했다. 턴제 비동기 게임은 게임 상태를 DB에 저장하고 차례가 오면 푸시로 알리며, 상태를 격자 문자열이나 명령 로그로 표현한다. 실시간 게임은 서버가 상태의 권위를 갖고, 클라이언트는 입력 예측·서버 보정·보간으로 지연을 숨긴다.
Backend › Architecture
메시지 큐와 Kafka메시지 큐를 고르는 기준과 IBM MQ → RabbitMQ → Kafka → Pulsar로 이어진 구조 변화, Kafka의 토픽·파티션·컨슈머 그룹 구조와 빠른 이유(순차 I/O, 제로 카피), 전달 보장 수준(at-most/at-least/exactly once)과 메시지가 유실되는 지점별 대책, Kafka와 RabbitMQ의 차이, 처리 실패와 DLQ, Kafka Connect·Streams·스키마 레지스트리 생태계를 정리했다.
Backend › Architecture
백엔드 지연 시간 줄이기: 숫자 감각과 기법메모리·SSD·네트워크·DB 커밋·LLM 호출이 대략 몇 나노초~초인지 자릿수 감각(Jeff Dean의 원형 표, 해마다 줄지 않는 왕복 지연, 봉투 뒷면 계산)을 먼저 잡고, API 지연을 줄이는 기법(인덱스, 캐시, 페이지네이션, 비동기 로깅·처리, 압축, 커넥션 풀, 로드 밸런싱, CDN)을 무엇을 줄이는지 기준으로 정리한다. 극단적 저지연 시스템의 원칙은 「크리티컬 패스에서 일을 줄인다」 하나다.
Backend › Architecture
보안 시스템 설계: 원칙과 민감 데이터 관리보안 설계는 기밀성·무결성·가용성(CIA)을 지키는 일이고, 인증·인가·암호화·네트워크·컨테이너·API·서드파티·감사·사고 대응·재해 복구를 처음부터 기본값으로 넣는 것이다. 웹 앱의 대표 위험은 OWASP Top 10(2025)으로 점검한다. 민감 데이터는 분류하고, 전송·저장 중 암호화하고, 키를 분리 관리하고, 비식별화하고, 최소 권한과 수명 주기로 접근을 좁힌다.
Backend › Architecture
분산 시스템의 시간과 장애: 8가지 착각부터 논리 시계까지분산 시스템이 어려운 이유는 메시지가 늦게 오고(비동기) 부품이 일부만 고장 나기(부분 장애) 때문이다. 분산 컴퓨팅의 8가지 착각, 대규모 클러스터의 실제 장애 빈도, 전역 '지금'이 없다는 사실, Lamport의 happened-before와 논리 시계, 선형화 가능성부터 최종 일관성·세션 보장까지의 일관성 모델, 합의 문제와 비잔티움 장애·BFT, Raft의 리더 선출과 로그 복제, 합의·CRDT로 조율 비용을 다루는 법을 정리한다.
Backend › Architecture
분산 시스템의 통신·데이터 흐름 패턴서비스끼리 주고받는 방식(요청-응답, 비동기 요청-응답, 발행-구독, 경쟁 소비자, 우선순위 큐, 클레임 체크), 데이터가 흐르는 방식(ETL, 배치, 스트림 처리, 이벤트 소싱, CQRS), 여러 서비스를 조율하는 방식(오케스트레이션, 사가, 리더 선출, 분산 락, 앰배서더)을 한 지도로 묶고 각 패턴이 푸는 문제와 대가를 정리했다.
Backend › Architecture
분산 트랜잭션: 2PC와 사가여러 DB·서비스에 걸친 작업을 하나처럼 끝내는 방법을 정리했다. 2단계 커밋(2PC)의 동작과 블로킹·코디네이터 장애 문제, 그 대안인 사가 패턴의 보상 트랜잭션 설계, 보상이 실패할 때의 처리, 격리가 없어 생기는 중간 상태와 대응책(시맨틱 락 등), 코레오그래피·오케스트레이션 구현 비교를 다룬다.
Backend › Architecture
빠르고 유지보수하기 좋은 DB 조회 패턴서버 코드에서 DB 조회를 빠르게 하면서도 코드는 단순하게 두는 방법. 직렬 조회 → 수동 배치 → 병렬 처리 → 자동 배치 → 값별 독립 함수 → 요청 단위 캐시로 발전시키며, 핵심은 '지역적 추론(local reasoning)'이라는 점을 정리한다. DataLoader의 원리이기도 하다.
Backend › Architecture
사진 공유 서비스 설계: 메타데이터, 저장, 샤딩Instagram 같은 사진 공유 서비스의 설계다. 요구 사항과 규모 추정(하루 사진 200만 장, 10년 저장량), 미디어 파일과 메타데이터를 나눠 저장하는 구조, 테이블별 크기 계산, 느린 업로드가 읽기를 막지 않게 읽기·쓰기 서버를 나누는 이유, 복제로 파일을 잃지 않는 법, PhotoID 기반 샤딩과 홀짝 티켓 서버로 ID 만들기, CDN 배포를 다룬다.
Backend › Architecture
소프트웨어 아키텍처 패턴계층형, 클라이언트-서버, 이벤트 기반, 마이크로서비스, 플러그인(마이크로커널), 헥사고날(포트와 어댑터) 아키텍처를 구조·장점·약점으로 비교하고, 구성 요소·커넥터와 제어·데이터 흐름으로 스타일을 가르는 다섯 계열(데이터 흐름, 호출-반환, 독립 구성 요소, 데이터 중심, 가상 머신)과 문제 모양별 선택 경험칙을 정리한다. 패턴마다 얻는 것과 치르는 것이 다르므로 시스템의 변경 방향과 팀 규모를 보고 고른다.
Backend › Architecture
시스템 설계의 선택지와 흔한 문제의 해법수직·수평 확장, SQL·NoSQL, 배치·스트림, 정규화·비정규화, 강한·최종 일관성, REST·GraphQL, 상태 유지·무상태, 동기·비동기처럼 설계에서 반복되는 양자택일을 비교하고, 읽기 폭주·쓰기 폭주·단일 장애 지점·지연·대용량 파일·느린 쿼리 같은 흔한 문제를 해법과 짝지었다.
Backend › Architecture
시스템 설계의 품질 속성과 트레이드오프확장성·가용성·신뢰성·성능이라는 네 가지 품질 속성의 뜻과 달성 수단, 설계에서 늘 부딪치는 다섯 가지 트레이드오프, 시스템 설계를 이루는 빌딩 블록, 목표·범위·규모에서 상위 설계·병목까지의 설계 진행 순서와 지연 시간 숫자로 하는 어림셈, 요구 사항에서 이전 계획까지 설계 논의의 체크리스트, 그리고 CAP·BASE·KISS 같은 약어를 한 곳에 정리했다.
Backend › Architecture
실시간 공동 편집: OT와 CRDT구글 문서처럼 여럿이 동시에 고치는 편집기는 편집을 문서 전체가 아니라 연산(삽입·삭제) 단위로 WebSocket으로 주고받고, 동시에 일어난 연산을 충돌 없이 합치는 알고리즘이 핵심이다. 중앙 서버가 연산을 변환하는 OT, 연산 자체를 교환·결합 가능하게 만든 CRDT, 차이를 주고받는 차등 동기화가 있다.
Backend › Architecture
실시간 웹소켓 서버 설계수만 개의 연결을 붙잡고 메시지를 밀어 주는 웹소켓 서버를 설계·검증하는 방법이다. 연결 하나에 여러 메시지 타입을 싣는 법, 방(그룹) 단위 분할과 Pub/Sub로 서버 간 전파하기, 액터 모델로 상태 관리하기, 팬아웃 폭증을 묶음 전송으로 막기, 파일 디스크립터·포트·로드밸런서 한계, 연결 수명 주기를 검증하는 부하 테스트까지 정리했다.
Backend › Architecture
실시간 트렌딩과 Top-K 집계최근 시간 창에서 가장 많이 언급된 상위 K개를 구하는 문제를 정리했다. 슬롯 링 버퍼로 만드는 슬라이딩 창 카운터, 키별 카운트 → 부분 순위 → 전역 순위의 3단 집계, 창이 밀릴 때 다시 계산하지 않는 최소 후보 집합(MinTopk), 키가 너무 많을 때의 근사 Top-K, 과거 패턴과의 거리로 트렌드를 일찍 잡는 비모수 방법까지 다룬다.
Backend › Architecture
아키텍처와 API 계층의 진화: 모놀리스에서 페더레이션까지대규모 서비스가 모놀리스 → 서비스 분리(SOA·마이크로서비스) → 매크로서비스로 옮겨 가는 이유와, 그에 맞춰 API 계층이 직접 호출 → 게이트웨이 집계 → BFF → GraphQL 페더레이션으로 바뀌는 흐름을 정리했다. 반대로 모놀리스와 단순한 백엔드로 큰 트래픽을 감당하는 사례와 여러 SaaS API를 묶는 통합 플랫폼도 다룬다.
Backend › Architecture
알림 시스템 설계: 푸시·이메일·SMS와 실시간 메시지 전달여러 서비스가 보내는 알림을 게이트웨이 → 분배 서비스 → 메시지 큐 → 채널 서비스로 흘려 인앱·이메일·SMS·모바일 푸시로 전달하는 구조를 정리했다. 템플릿·채널 선호 저장소, 우선순위 큐, APNs·FCM 같은 플랫폼 푸시 서비스, 전달 추적, 그리고 채팅 메시지를 채널 서버와 지역 게이트웨이를 거쳐 웹소켓으로 밀어 주는 실시간 전달 경로까지 다룬다.
Backend › Architecture
웹 확장성의 구성 요소: 한 장으로 보는 웹 아키텍처확장 가능한 웹 애플리케이션을 이루는 구성 요소(DNS, 로드 밸런서, CDN, 프론트 웹 서버, 웹 서비스, 캐시, 메시지 큐와 워커, 데이터 저장소, 검색엔진)를 한 장의 지도로 정리했다. 3-Tier와 MSA의 데이터 흐름, 확장의 세 축(복제, 기능 분할, 데이터 분할), HTTP 캐시와 객체 캐시, 비동기 처리와 이벤트 기반 구조, 구간별 보안, 그리고 사람과 팀을 확장하는 법까지 다룬다.
Backend › Architecture
위치 기반 서비스 설계: 지오해시, 쿼드트리, 지도'내 주변 식당'은 모든 점과의 거리를 계산하면 느리므로 지도를 격자로 나눠 색인한다. 지오해시는 위경도를 접두사가 같으면 가까운 문자열로 바꿔 DB 색인으로 찾고, 쿼드트리는 밀도에 따라 칸을 쪼갠 메모리 트리로 찾는다. 지도 서비스는 위치 수집, 미리 잘라 둔 타일의 CDN 서빙, 지오코딩과 경로 계산으로 나뉜다.
Backend › Architecture
이미지·동영상 처리 서버 설계업로드된 이미지·동영상을 여러 크기와 화질로 바꿔 내보내는 서버를 설계하는 방법이다. 미리 만들어 두기와 요청 시 변환(온디맨드 리사이징)의 비교, 캐시·CDN·HTTP 검증자로 변환 비용을 줄이는 법, 엣지 함수 구성, 트랜스코딩 파이프라인을 단계로 나누고 비동기 완료 알림을 보내는 법, 점진적 다운로드와 적응형 스트리밍을 정리했다.
Backend › Architecture
이벤트 기반 아키텍처 설계이벤트 기반 아키텍처는 「무슨 일이 일어났다」는 사실을 발행하고, 관심 있는 쪽이 구독해 반응하게 해서 시스템 사이의 논리적 의존을 끊는다. 이벤트와 커맨드의 구분, 이벤트 계층(앱·내부·외부), 페이로드 설계, 발행 시점의 정합성, 큐와 토픽, 멱등 소비, 순서와 재처리, 조회 모델 분리까지 설계할 때 정해야 할 것을 정리했다.
Backend › Architecture
인증·인가 로직은 어디에 두나: 필터, 인터셉터, API 게이트웨이인증·인가를 컨트롤러마다 넣으면 중복과 누락이 생긴다. 단일 서버에서는 필터·인터셉터·메서드 보안으로, MSA에서는 API 게이트웨이에서 토큰을 검증하고 각 서비스가 자기 리소스의 인가를 맡는 식으로 층을 나눈다. 게이트웨이 우회 차단과 신원 전달 방식이 핵심 주의점이다.
Backend › Architecture
자금 이동: 청산과 결제온라인 결제 뒤에서 돈이 실제로 움직이는 구조를 정리했다. 정보 흐름과 자금 흐름이 분리되는 이유, 청산(clearing)과 결제(settlement)의 차이, 배치 이체망 ACH, 은행 간 메시지망 SWIFT, 외화 결제의 환전 경로, 실시간 이체망 UPI를 다루고, 은행 지갑과 블록체인 지갑·Web 3.0의 차이까지 비교한다.
Backend › Architecture
장애 확산을 막는 복원력 패턴작은 오류가 연쇄 장애로 번지지 않게 하는 여덟 가지 패턴(타임아웃, 재시도, 서킷 브레이커, 속도 제한, 부하 차단, 벌크헤드, 배압, 크래시 허용), 속도 제한 알고리즘의 개요, 벌크헤드 격리 방식과 배압 전략, 재시도를 안전하게 만드는 백오프·지터 전략, 4xx·5xx별 재시도 규칙, 재시도의 전제 조건인 멱등성을 적용해야 하는 곳을 정리했다.
Backend › Architecture
채팅 시스템 설계: 연결, 접속 상태, 메시지 전달채팅 서버는 클라이언트와 WebSocket을 유지하고, 메시지는 순서를 매겨 저장한 뒤 받는 사람이 붙어 있는 서버로 전달한다. 서버가 여러 대이면 Redis pub/sub·메시지 큐로 서버 간에 메시지를 넘기고, 접속 상태 서비스가 온라인이면 소켓으로, 오프라인이면 푸시 알림으로 보낸다.
Backend › Architecture
카드 결제망과 간편결제카드를 긁는 순간부터 가맹점이 돈을 받기까지의 승인·매입·정산 흐름과, 발급사·매입사·카드 네트워크·PG·프로세서가 각각 맡는 일, 수수료가 나뉘는 구조를 정리했다. 카드 번호 대신 토큰을 쓰는 Apple Pay·Google Pay, QR 결제의 네 가지 방식과 「스캔해서 결제」 흐름까지 다룬다.
Backend › Architecture
캐시 전략: 계층, 읽기·쓰기 패턴, 교체 정책, 장애 패턴캐시는 요청 경로의 거의 모든 층에 있다. 캐시와 원본을 맞추는 읽기·쓰기 패턴(cache-aside, read-through, write-through, write-around, write-back), 꽉 찼을 때 무엇을 버릴지 정하는 교체 정책(LRU·LFU·FIFO·SLRU·TTL 등), 그리고 캐시가 오히려 DB를 무너뜨리는 네 가지 장애(동시 만료, 관통, 핫 키 만료, 캐시 다운)와 대응을 정리한다.
Backend › Architecture
캐시 클러스터 운영과 장애 대응트래픽 대부분을 캐시가 받는 서빙 계층에서는 캐시의 가용성이 곧 서비스의 가용성이다. 일부 노드 장애를 연결 단위로 빨리 감지하고, 동기화 중인 복제본은 트래픽에서 빼고, 응답 속도 기반 라우팅이 만드는 쏠림을 무작위 선택으로 풀고, 핫 키는 짧은 TTL의 로컬 캐시로 흡수하는 방법을 정리했다.
Backend › Architecture
클라우드 설계 패턴클라우드 앱이 반복해서 만나는 문제(서버가 파일 전송을 떠안음, 순간 폭주, 설정 재배포, 여러 단계 작업의 실패, 인스턴스 상태 판단, 인증 위임)를 푸는 패턴을 모았다. 발레 키, 정적 콘텐츠 호스팅, 큐 기반 부하 평준화, 파이프와 필터, 계산 자원 통합, 외부 설정 저장소, 스케줄러·에이전트·감독자, 헬스 엔드포인트 모니터링, 연합 ID, 백그라운드 작업을 다루고, 다른 노트에 집이 있는 패턴은 지도로 잇는다.
Backend › Architecture
API 게이트웨이클라이언트와 백엔드 서비스 사이의 단일 입구인 API 게이트웨이. 라우팅·인증·레이트 리밋·요청 변환·응답 조합·캐시 같은 기능, 요청 하나가 게이트웨이를 지나는 순서, 생태계·마켓플레이스·다중 플랫폼 같은 쓰임, 그리고 리버스 프록시·로드 밸런서·서비스 메시·공통 라이브러리와의 차이와 함께 쓰는 배치를 정리했다.
Backend › Architecture
BFF (Backend For Frontend)프론트엔드 하나마다 그 화면에 맞춘 중간 서버를 두는 BFF 패턴. 여러 API를 묶고, 필요한 필드만 가공해 내려 주고, CORS·인증·MSA 엔드포인트 변경을 흡수한다. Next.js를 BFF로 쓰는 법과 GraphQL 정규화 캐시 함정을 정리한다.
Backend › Architecture
Kafka 운영: 복제, 컨슈머 그룹, 튜닝, 모니터링Kafka 클러스터를 운영할 때 알아야 할 내부 동작을 정리했다. 복제와 ISR·하이 워터마크, acks와 min.insync.replicas의 조합, KRaft 컨트롤러와 장애 조치, 프로듀서 배치·압축·전송 방식, 컨슈머 그룹 리밸런스와 오프셋 커밋, 컨슈머 랙, 보존과 로그 컴팩션, 보안(TLS·SASL·ACL), 브로커 증설·롤링 재시작, 모니터링 지표와 병목 진단을 다룬다.
Backend › Architecture
URL 단축기 설계긴 URL을 짧은 코드로 바꿔 주고 그 코드로 원래 주소에 리다이렉트하는 서비스(Bitly 같은)의 설계다. 요구 사항과 규모 추정, 301과 302 리다이렉트의 차이, 해시·고유 ID+Base62·무작위 코드 생성 방식 비교, 데이터 모델과 저장소, 캐시 중심의 읽기 경로, 사용자 지정 별칭·만료·클릭 분석·악용 방지를 다룬다.
Backend › Database
데이터베이스 샤딩한 DB에 담기 어려울 만큼 커진 데이터를 같은 스키마의 여러 DB로 행 단위로 나누는 샤딩을 정리했다. 샤드 키와 라우팅 방식(모듈러·범위·디렉터리·일관된 해싱·가상 버킷), 샤딩이 어렵게 만드는 것, ShardingSphere 같은 미들웨어, 기존 DB에서 옮겨 올 때의 동기화와 첫 요청 지연까지 다룬다.
Backend › Database
데이터베이스 확장과 성능 최적화DB가 느려지거나 한계에 닿을 때 싼 것부터 쓰는 수단을 순서대로 정리했다. 인덱스·쿼리 튜닝·커넥션 풀·캐시·구체화된 뷰(갱신 방식)·반정규화·수직 확장·읽기 복제본·파티셔닝(프루닝, 분할 방식, 로컬·글로벌 인덱스)·샤딩의 효과와 대가, 복제 구조(단일 리더·다중 리더·리더 없음)와 동기화 방식, 읽기 복제본 패턴의 복제 지연과 라우팅(애플리케이션 vs 미들웨어)을 다룬다.
Backend › Database
분산 환경의 고유 ID 생성여러 서버가 동시에 겹치지 않는 ID를 만드는 다섯 가지 방법(UUID, Snowflake, DB 자동 증가, DB 세그먼트, Redis)을 비교하고, 시간순 정렬·64비트·저지연 같은 요구 사항에 따라 어떤 방식을 고를지, 시간순 UUID(UUIDv7)가 인덱스 문제를 어떻게 푸는지 정리했다.
Backend › Database
용도별 데이터베이스와 고르는 법OLTP·OLAP·검색·키-값·문서·와이드 컬럼·그래프·시계열·벡터·공간 DB를 「어떤 질문에 답하는 저장소인가」로 나누고, 고르는 순서와 결정 트리, 확장 기능으로 여러 용도를 덮는 PostgreSQL, 컴퓨팅과 저장을 분리한 서버리스 DB, 클라우드 관리형 대응표를 정리했다.
Backend › Database
Elasticsearch와 ELK 스택Elasticsearch는 Lucene 위에 만든 분산 검색·분석 엔진이다. JSON 문서를 역인덱스로 색인해 전문 검색과 집계를 거의 실시간으로 처리한다. 클러스터·노드 역할·샤드·세그먼트 구조, 쓰기 경로와 복제·일관성 모델, 인덱스 템플릿·롤오버·ILM·데이터 티어, 스냅숏 백업, 확장과 튜닝, 모니터링과 장애 진단(429, 디스크 워터마크), 보안, ELK 로그 파이프라인을 정리한다.
Backend › Express
Express 프로젝트 구조: 3계층, 이벤트, DI, 로더구조를 강제하지 않는 Express 앱을 오래 고칠 수 있게 나누는 법. 라우트·서비스·데이터 접근 3계층, 서비스에서 HTTP를 떼어 내기, 부수 작업을 이벤트 구독자로 분리, 생성자 주입, 설정 모듈, DB 기반 작업 스케줄러, 시작 과정을 로더로 쪼개기를 정리했다.
Backend › NestJS
NestJS Module과 Provider: 의존성 주입과 캡슐화@Injectable 클래스를 모듈의 providers에 등록하면 Nest가 인스턴스를 만들어 생성자에 주입한다(DI). 모듈은 관련 컨트롤러·프로바이더를 묶고 export한 것만 밖에 공개하는 구성 단위다.
Backend › NestJS
Repository 패턴과 레이어 분리서비스와 데이터베이스 사이에 데이터 접근 전담 계층을 두어 비즈니스 로직과 DB 쿼리를 분리하는 패턴.
Backend › Web Basics
스프링 애플리케이션 설계: DI, 프록시 트랜잭션, 멀티모듈, WebFlux스프링으로 서버를 만들 때 반복해서 부딪히는 설계 문제를 정리한다. IoC·DI와 생성자 주입, Service/ServiceImpl 관행과 SOLID, Lombok 사용 기준, 프록시 기반 @Transactional의 자기 호출 함정, 멀티모듈의 계층과 의존 규칙, 사용하지 않는 API 찾기, Spring MVC와 WebFlux의 차이를 다룬다.
Backend › Web Basics
웹 서버, WAS, 그리고 Nginx정적 자원을 내주는 웹 서버(Apache·Nginx)와 동적 처리를 맡는 WAS(Tomcat 등)의 역할 분담, 리버스 프록시·로드밸런싱, Nginx의 마스터-워커 구조와 겸하는 역할(웹 서버·프록시·캐시·TLS 종료), 그리고 Nginx의 location·rewrite·proxy_pass로 404를 다른 서버로 넘기는 설정.
Backend › Web Basics
웹훅과 폴링다른 서비스의 변화를 알아내는 두 방법. 폴링은 내가 주기적으로 묻고, 웹훅은 상대가 이벤트가 생길 때 내 엔드포인트를 호출한다. 동작 흐름과 장단점, 고르는 기준, 웹훅을 받는 쪽이 갖춰야 할 서명 검증·빠른 응답·멱등 처리·재시도 대비를 정리했다.
Backend › Web Basics
API 아키텍처 스타일: SOAP·REST·GraphQL·gRPC·WebSocket·WebhookAPI는 시스템끼리 기능과 데이터를 주고받는 약속이다. 대표적인 여섯 가지 스타일(SOAP, REST, GraphQL, gRPC, WebSocket, Webhook)을 통신 방향·데이터 형식·잘 맞는 곳으로 비교하고, REST·GraphQL·gRPC를 계약·응답 모양·전송·스트리밍·오류 처리·캐시·브라우저 지원·버전 관리 등 축별로 나란히 놓았다. API와 SDK의 차이, 공개 범위에 따른 API 종류, API를 배울 때 거치는 주제 지도도 정리했다.
Backend › Web Basics
GraphQLGraphQL은 타입 스키마 위에서 클라이언트가 필요한 필드를 골라 질의하는 API 질의 언어이자 런타임이다. 쿼리·뮤테이션·구독, REST 대신 고를 때의 기준, N+1·캐시·악성 쿼리 같은 약점과 대책, 클라이언트 래핑·BFF·모놀리식·페더레이션 네 가지 도입 패턴, 등록된 쿼리로 운영하는 방식을 정리했다.
Computer Science › Programming Languages
같은 문제, 열다섯 가지 설계: 상태와 결합을 다루는 법터틀 그래픽(앞으로 가기, 돌기, 펜 올리기)이라는 단순한 문제를 객체 지향 클래스부터 순수 함수 모듈, 함수형 코어 API, 에이전트, 인터페이스·함수 의존성 주입, 상태 모나드, 커맨드 배치, 이벤트 소싱, 스트림 처리, 인터프리터, 추상 자료형, 능력 기반 API까지 열다섯 가지로 구현하며 상태를 누가 쥐는지와 구현과 어떻게 떼어 내는지를 비교한다. 행동(인터페이스)이 아니라 데이터(커맨드 타입)로 결합을 끊는 방식의 장점도 정리한다.
Computer Science › Programming Languages
객체 지향의 본질: 메시징객체 지향이라는 말을 만든 앨런 케이의 관점에서 OOP의 본질을 메시징·캡슐화·늦은 바인딩 세 가지로 정리한다. 클래스와 상속은 C++·Java가 대중화한 구현 방식일 뿐 필수 조건이 아니며, 핵심은 상태를 숨긴 독립 개체들이 메시지로 협력하는 구조다.
Computer Science › Programming Languages
책임 주도 설계: 협력·책임·메시지객체지향 설계는 좋은 객체가 아니라 좋은 협력을 설계하는 일이다. 메시지를 먼저 정하고 그 메시지를 처리할 책임을 가진 객체를 고른다. 객체가 받는 메시지의 집합이 인터페이스가 되고, 속성은 책임을 정한 뒤에 따라온다.
Computer Science › Programming Languages
DTO와 VO, DAO와 Repository이름이 비슷해 헷갈리는 네 가지 객체를 구분한다. DTO는 계층 사이로 데이터를 실어 나르는 로직 없는 상자, VO는 값으로만 같음을 따지는 불변 도메인 객체다. DAO는 테이블 중심으로 영속성을 추상화한 저수준 계층이고, Repository는 도메인 객체의 컬렉션처럼 보이게 만든 상위 수준 계층이다.
Computer Science › Programming Languages
Go 언어: 설계 원칙, 타입, 에러 처리, 빌드와 테스트, GCGo의 장단점과 The Zen of Go의 원칙, 암묵적으로 구현되는 인터페이스와 nil 인터페이스 함정, 값과 포인터 리시버, 배열과 슬라이스 헤더·append, Swiss Table 기반 맵, 구조체 임베딩, 제네릭과 타입 제약, error 값과 감싸기·errors.Is/As, defer·panic·recover, 정적 바이너리 빌드와 모듈·MVS·워크스페이스, 테이블 기반 테스트와 벤치마크, 세대 구분도 압축도 하지 않는 동시 GC와 GOGC·GOMEMLIMIT, 클린 아키텍처 계층으로 프로젝트를 나누는 방법을 정리한다.
Computer Science
소프트웨어 복잡성: 본질적 복잡성과 우발적 복잡성큰 소프트웨어를 만들기 어려운 근본 원인은 이해하기 어렵다는 것, 곧 복잡성이다. 문제 자체에 있는 본질적 복잡성과 도구·설계가 덧붙인 우발적 복잡성을 나누고, 복잡성의 주원인인 상태·제어 흐름·코드 양, 「단순함(simple)」과 「쉬움(easy)」의 차이와 얽힘(complect), 피하고(avoid) 분리하라(separate)는 처방을 정리한다.
Computer Science
소프트웨어 안전: 위험원 분석과 결함 허용 설계허용 가능한 위험만 남은 상태를 안전으로 정의하고, 소프트웨어 결함이 사고로 이어진 사례, 결함 예방·검출·제거·허용의 네 전략, 중복성과 다양성, IEC 61508을 뿌리로 한 분야별 안전 표준과 SIL, FMEA·FTA·HAZOP 안전 분석을 정리한다.
Algorithm
현실 시스템을 움직이는 알고리즘과 자료구조일상 소프트웨어에서 자료구조가 쓰이는 곳(피드의 리스트, 실행 취소의 스택, 캐시의 해시 테이블, DOM의 트리, 지도 검색의 R-트리), 대규모 시스템 설계에 자주 나오는 알고리즘(일관된 해싱, 지오해시·쿼드트리, 블룸 필터, HyperLogLog, 토큰 버킷, 머클 트리, 합의 알고리즘), 세상을 움직이는 아홉 가지 알고리즘을 정리한다. 블룸 필터는 중복 URL 크롤링 방지 예로 자세히 본다.
DevOps
12요소 앱클라우드에서 확장·배포·운영하기 쉬운 애플리케이션을 만드는 열두 가지 원칙(코드베이스, 의존성, 설정, 백엔드 서비스, 빌드·릴리스·실행, 프로세스, 포트 바인딩, 동시성, 폐기 가능성, 개발·운영 일치, 로그, 관리 프로세스)을 각 원칙이 막는 문제와 지금의 구현 방식으로 정리했다.
DevOps
고가용성과 재해 복구 설계데이터센터 하나가 통째로 사라져도 서비스를 이어 가기 위한 설계 원칙. RTO·RPO로 목표를 정하고, 백업·파일럿 라이트·웜 스탠바이·액티브-액티브 중 전략을 고르며, 데이터·플랫폼·운영 도구까지 모든 계층을 여러 데이터센터에 나누고, 전환을 정기 훈련으로 검증한다. 복구에 쓰는 운영 도구가 가장 자주 다중화에서 빠진다.
DevOps
관측 가능성: 로그, 트레이스, 메트릭관측 가능성의 세 기둥인 로그(개별 사건), 트레이스(요청 하나의 경로), 메트릭(집계 가능한 수치)의 차이와 수집 구조, OpenTelemetry로 한 표준에 모으는 방법, 메트릭 수집의 풀·푸시 모델과 서비스 디스커버리, 쓰기가 많고 읽기가 몰리는 메트릭에 범용 DB 대신 시계열 DB를 쓰는 이유를 정리한다.
DevOps
서버리스 아키텍처서버를 예약하지 않고 이벤트가 올 때만 코드를 실행해 실행한 만큼 내는 방식이다. IaaS·PaaS·컨테이너와의 차이, FaaS와 BaaS, 함수를 부르는 네 가지 경로, 함수를 나누는 네 가지 코드 구성(함수당 작업 하나·서비스·모놀리식·그래프), 콜드 스타트·실행 시간·연결 수·종속 같은 제약과 맞는 곳을 정리했다.
DevOps
서비스 운영 준비 체크리스트서버 애플리케이션을 프로덕션에 올리기 전에 확인할 최소 기준을 회복력, 수평 확장, 무중단 배포, 프로세스 감독, 로그, 알림과 헬스 체크, 지표, 고가용성, 부하·장애 테스트, 백업 복구, 보안, 법 열두 분야로 나누고 각 항목을 자세한 노트로 잇는다. 오래된 보안 헤더(X-XSS-Protection, HPKP)처럼 지금은 따르지 않는 항목도 정리한다.
DevOps
스타트업 인프라 선택 원칙작은 팀이 인프라를 고를 때의 판단 기준. 데이터 계층에는 관리형 서비스에 돈을 쓰고, 단순한 도구를 고르고, 관리형 편의 기능은 커스터마이즈 여지를 먼저 보고, 관측 표준(OpenTelemetry)·IdP·의존성 업데이트·비용 추적처럼 늦을수록 비싸지는 것은 처음부터 들인다. 가변 인프라·비대한 이미지·공유 DB 같은 클라우드 네이티브 안티패턴도 함께 정리한다.
AI & Data
데이터 파이프라인과 저장소 용어데이터 파이프라인은 수집 → 적재 → 저장 → 처리 → 활용의 다섯 단계로 데이터를 옮기고 다듬는다. 단계별 도구 지도(2026)와 도구를 고르는 원칙, 배치와 스트림·이벤트 시간과 늦게 오는 데이터·람다와 카파 아키텍처, ETL과 ELT, 웨어하우스·레이크·레이크하우스·테이블 포맷·데이터 메시 같은 저장소 용어, 데이터 계층과 테이블 이름 규칙, 분석 저장소가 커 가는 단계와 재작업에 강한 적재·운영 원칙을 정리한다.
AI & Data
머신러닝 모델 서빙학습한 모델을 서비스에서 호출할 수 있게 띄우는 방법. VM·컨테이너·서버리스·모델 서버 같은 배포 형태와 CPU·GPU 추론 선택, 모바일·엣지 배포, 동기 API와 큐 기반 비동기 워커 중 무엇을 고를지, 가중치·이미지 분리, 배치 처리, 헬스 체크, 배포 게이트 같은 설계 원칙과, BentoML처럼 모델을 API·컨테이너로 묶어 주는 프레임워크의 역할을 정리했다.
AI & Data
멀티 에이전트여러 AI 에이전트가 조사·작성·검토·실행 역할을 나눠 일하는 방식. 목표 설정 → 분업 → 병렬 수행 → 통합 → 검토로 돌아가며, 에이전트 수보다 역할 설계와 연결(공유 컨텍스트·가드레일)이 품질을 좌우한다.
AI & Data
분산 데이터 처리: MapReduce, Spark, SQL 엔진한 서버로 감당할 수 없는 데이터를 클러스터로 처리하는 기술의 계보(GFS·MapReduce·Hadoop → Spark → Trino)와 핵심 원리를 정리했다. MapReduce의 한계, Spark RDD의 계보(lineage)·지연 실행·좁은/넓은 의존성, 지금의 표준인 DataFrame·Spark SQL, 객체 저장소 위 클러스터 운영 팁, 대화형 SQL 엔진이 빠른 이유, 열 지향 포맷 Parquet의 컬럼 선택·조건 푸시다운을 다룬다.
AI & Data
웹 AI 플랫폼 고르기: 클라이언트, 서버, 하이브리드웹 AI는 모델이 어디서 도나(브라우저 / 서버)와 얼마나 고칠 수 있나(가중치 접근)로 네 가지 선택지가 생긴다. 내장 AI·커스텀 클라이언트 모델·관리형 API·자체 호스팅을 모델 성능·비용·프라이버시·호환성·유지 보수로 비교하고, 요구 사항에서 플랫폼을 고르는 법과 클라이언트 우선 하이브리드 라우팅을 정리한다.
AI & Data
이벤트 로그 설계와 수집지표와 의사 결정에 쓰는 이벤트 로그를 어떻게 설계하고 모으는지 정리했다. 보고 싶은 지표에서 거꾸로 로그를 정하기, 기록 시점의 기준 세우기, 매번 검증하기, 테이블 모양으로 남기기 같은 설계 원칙과 설계 순서, 품질 문제의 원인과 대응, who·what·how·when 구조, 스키마로 로그를 공유하는 법, 클라이언트·서버 로그의 차이, 에이전트 → 스트림 버퍼 → 원본 저장소·검색 인덱스로 이어지는 수집 파이프라인과 수집 자체를 감시하는 법을 다룬다.
AI & Data
AI 기능 기획: 시스템 블루프린트와 유스케이스 발굴웹 서비스에 AI 기능을 넣기 전에 기회(유스케이스·가치) → 솔루션(데이터·지능·UX) → 거버넌스의 세 관점으로 지도를 그린다. 가치 범주로 아이디어를 내고, 사용자 여정에 배치하고, 데이터 준비도·비용·실패 모드를 따져 우선순위를 정한 뒤 끝에서 끝까지 이어지는 프로토타입으로 검증한다.
AI & Data
LLM 서빙의 병목: KV 캐시, 배치, GPULLM을 수억 명에게 서비스할 때 병목은 연산보다 GPU 메모리인 경우가 많다. 어텐션 비용과 KV 캐시, 산술 강도와 배치 크기, GPU 사용률이 속이는 지표인 이유, 지역보다 GPU를 따라가는 배치, 오토스케일이 안 되는 상황을 정리했다. PagedAttention·연속 배치·프롬프트 캐싱 같은 지금의 서빙 기법과 H100·H200·B200의 연산 대비 메모리 대역폭도 다룬다.
Tools › Code Review
삭제하기 쉬운 코드코드는 쓰는 순간부터 유지 비용을 낳는다. 확장성과 재사용을 미리 설계하기보다, 바뀔 가능성을 기준으로 경계를 나눠 나중에 쉽게 버리고 바꿀 수 있게 쓴다. 쓰지 않기 → 복사 → 함수 추출 → 보일러플레이트 허용 → 래퍼 → 덩어리 → 변경 경계 분리의 단계로 정리한다.
Tools
다이어그램 코드: 코드로 그리는 아키텍처 그림다이어그램을 그림 도구 대신 텍스트·코드로 작성해 버전 관리·리뷰·재생성을 가능하게 하는 방식. 클라우드 아키텍처를 파이썬으로 그리는 Diagrams, 문서 안에서 렌더링되는 Mermaid·PlantUML, 마크다운을 마인드맵으로 바꾸는 Markmap, JSON을 그래프로 보여 주는 JSON Crack 등 도구별 쓰임과 고르는 기준을 정리한다.
Career › Job Search
기술 면접 준비: 유형별 대비와 시스템 디자인 7단계개발자 기술 면접은 코딩, 시스템 디자인, 객체 지향 설계(OOD), 행동(behavioral) 면접으로 나뉜다. 유형별로 무엇을 보는지와 준비 자료, 퀴즈·온라인 코딩 테스트·과제·화상 면접·온사이트 같은 진행 형식별 대비, 면접 언어 고르기, 남은 시간에 맞춘 준비 계획(주제 우선순위, Blind 75·Grind 75), 코딩 인터뷰를 자기소개 → 질문 명확화 → 접근 논의 → 말하며 코딩 → 테스트 → 역질문으로 진행하는 법을 정리하고, 시스템 디자인 면접의 유형과 요구 사항 확인 → 용량 추정 → 상위 설계 → DB 설계 → 인터페이스 설계 → 확장성 → 신뢰성의 7단계를 다룬다.
Career › Work
개발자 역량 지도: 주니어에서 시니어, 풀스택, 아키텍트까지주니어에서 시니어로 가며 넓혀야 할 열한 가지 역량(협업 도구, 언어, API, 서버·클라우드, 인증·테스트, DB, CI/CD, 자료구조·알고리즘, 시스템 설계, 디자인 패턴, AI 도구), 풀스택 개발자가 다루는 일곱 영역, 소프트웨어 아키텍트에게 필요한 지식 지도, 모든 개발자가 알아야 할 여덟 가지 표준을 한 장에 정리한다.