로드맵
backend 병목에서 시작해 application, cloud, delivery와 AI-assisted engineering까지 이어집니다. 모든 코드를 외우는 순서가 아니라, 한 결정이 전체 system에 미치는 영향을 설명하는 순서입니다.
3 / 62 완성
이 서비스는 어떤 구조인가요?
Breaking Point 자체의 runtime 경계와 운영 loop입니다. lab에서 다루는 Queue, p99, overload 감각을 이 repository를 만드는 방식에도 같은 언어로 연결합니다. 자세한 설명은 프로세스와 Architecture를 봅니다.
Runtime layers
1
Static learning shell de facto practice
랩 본문, Wiki, 로드맵을 build time HTML로 제공합니다.
2
Interaction islands project contract
simulation, chart, challenge, Pet Coach처럼 상호작용만 React로 올립니다.
3
Deterministic model project contract
Scenario와 seed로 같은 결과를 내는 browser model입니다. production benchmark가 아닙니다.
4
Isolated AI gateway vendor boundary
API key와 provider 호출만 분리합니다. 학습 shell과 runtime을 섞지 않습니다.
Delivery loop
- Orient contract와 roadmap item을 읽고 범위를 닫습니다.
- feature/* 한 사용자 결과만 담은 브랜치에서 구현합니다.
- Verify pnpm quality와 UI evidence로 통과를 판정합니다.
- Review Standards와 Spec 축을 분리해 검토합니다.
- develop rebase로 통합합니다. Pages에는 아직 올리지 않습니다.
- release → main rebase로 공개하고 Actions·URL로 관측합니다.
랩 개념 → 운영 감각
이용률과 Queue CI·리뷰 대기열에 여유 없이 쌓이면 머지 지연이 수직으로 튑니다.
p50과 p99 평균 빌드 시간은 괜찮어도 느린 PR 꼬리가 배포 체감을 망칩니다.
커넥션 풀 / 공유 자원 에이전트·CI·리뷰어를 늘려도 공통 contract와 quality gate가 병목이면 소용없습니다.
Timeout과 overload PR과 release에 시간 예산을 두고, 빨간 CI에서는 merge circuit을 엽니다.
Evidence / tracing 대화가 아니라 test output, Scenario, Pages URL로 결과를 추적합니다.
0. CS 문제 해결의 기초
자료구조와 알고리즘을 암기 문제가 아니라 실제 system의 비용과 순서를 설명하는 도구로 익힌다.
예정
Complexity와 측정
입력이 10배가 될 때 어떤 구현은 왜 100배 느려질까?
🎛 입력 크기와 연산 수 곡선을 실제 browser 실행 시간과 나란히 비교
예정
탐색 알고리즘
순서가 있다는 사실 하나가 탐색 범위를 어떻게 절반씩 줄이나?
🎛 Linear Search와 Binary Search가 확인한 칸과 실제 연산 횟수를 나란히 표시
예정
Array와 Hash Table
빠른 lookup은 어떤 memory와 collision 비용을 치르는가?
🎛 중복 요청을 선형 탐색과 idempotency key map으로 판별하며 비용 비교
예정
Queue와 Stack
처리 순서 하나가 fairness와 memory 사용량을 어떻게 바꾸나?
🎛 FIFO worker queue와 LIFO 작업 복구를 workload별로 실행
예정
Tree와 Graph
한 service의 변경과 장애가 어디까지 퍼지는지 어떻게 찾나?
🎛 dependency graph를 순회해 blast radius, cycle과 배포 순서 찾기
예정
Graph 경로 탐색
가장 가까운 연결과 가장 저렴한 경로는 왜 같은 문제가 아닌가?
🎛 BFS, DFS와 Dijkstra의 frontier·방문 순서·누적 비용을 단계별 비교
예정
정렬, 탐색과 Priority Queue
모든 일을 순서대로 처리하는 것이 언제 불공정한가?
🎛 job scheduler의 정책을 바꾸며 throughput, starvation과 p99 비교
1. 기초 체력
부하가 걸리면 시스템이 왜, 어떤 순서로 무너지는지에 대한 감각을 만든다.
완성
완성
완성
예정
캐시 스탬피드
캐시를 넣었는데 왜 5분마다 DB가 죽을까?
🎛 TTL 동시 만료 순간 요청이 DB로 쏟아지는 장면 + 지터/뮤텍스 적용 비교
예정
리트라이 스톰
재시도는 왜 도움이 안 되고 불을 키우는가?
🎛 백오프 없음 / 고정 / 지수+지터 세 가지를 나란히 실행
2. 한계 다루기
내 시스템이 어디서 부러지는지 숫자로 말할 수 있게 된다.
예정
용량 산정
"초당 3000 요청을 버틸 수 있나요?"에 어떻게 답하나?
🎛 요청 하나의 자원 소모를 입력하면 필요한 서버/커넥션/대역폭을 역산
예정
부하 테스트 제대로 하기
k6로 한계점을 찾고 병목을 특정하는 방법
🎛 실제 실행 가능한 k6 스크립트 + 결과 해석 가이드
예정
스케일아웃의 경계
어디까지 늘려서 해결되고, 어디부터는 안 되는가?
🎛 계층별로 파드를 늘려보며 병목이 아래로 이동하는 걸 추적
예정
핫키와 편향
샤딩했는데 왜 한 대만 죽을까?
🎛 키 분포를 조절하며 샤드별 부하 불균형을 관찰
예정
N+1과 쿼리 비용
코드 한 줄이 어떻게 쿼리 500개가 되는가?
🎛 ORM 코드를 고르면 발생하는 쿼리 수와 총 지연을 계산
3. 무너짐 막기
한 곳의 장애가 전체로 번지지 않게 막는 장치들을 손에 익힌다.
예정
타임아웃 예산
서비스가 5단계로 이어져 있을 때 각 타임아웃을 얼마로 잡나?
🎛 체인의 타임아웃을 조절하며 어디서 예산이 터지는지 확인
예정
서킷 브레이커
고장난 하위 서비스를 언제 포기해야 하나?
🎛 차단기 임계값을 바꿔가며 회복 속도와 오작동을 비교
예정
백프레셔와 부하 제한
다 받아서 다 죽느니, 일부를 거절하는 게 나은 이유
🎛 무제한 수용 vs 큐 상한 vs 적응형 제한 3가지 비교
예정
벌크헤드
느린 API 하나가 왜 전체 서비스를 멈추게 하나?
🎛 스레드 풀 공유 / 분리 두 구조를 나란히 부하
예정
멱등성
결제가 두 번 되는 건 어떻게 막나?
🎛 중복 요청을 쏘면서 멱등키 유무에 따른 결과 비교
예정
동시성과 재고 초과 판매
재고 1개에 100명이 동시에 주문하면?
🎛 락 없음 / 비관적 / 낙관적 / 원자적 감소 4가지 결과 비교
예정
대기열(가상 대기실)
티켓팅은 왜 대기열을 쓰나?
🎛 대기열 유무에 따른 성공률과 사용자 경험 비교
4. 보고 고치기
터졌을 때 원인을 찾고, 안 터지게 배포하는 법.
예정
분산 트레이싱
서비스 10개 중 범인을 어떻게 찾나?
🎛 가짜 트레이스에서 병목 구간을 직접 찾아보는 연습
예정
무중단 스키마 변경
1억 행 테이블에 컬럼을 어떻게 추가하나?
🎛 단계별 마이그레이션 시뮬레이션 + 잘못된 순서의 결과
예정
graceful shutdown
배포할 때마다 왜 에러가 조금씩 나나?
🎛 종료 훅 유무에 따른 처리 중 요청의 운명
예정
장애 대응
새벽 3시에 알림이 왔다. 무엇부터 보나?
🎛 증상만 주고 원인을 좁혀가는 인터랙티브 시나리오
5. 애플리케이션 설계
React에서 PostgreSQL까지 한 요청의 lifecycle과 경계를 설명한다.
예정
React state와 Server state
무엇을 browser에 두고, 무엇을 server에서 다시 가져와야 하나?
🎛 local state / cache / server state가 어긋나는 시나리오를 비교
예정
Next.js rendering boundary
SSR, RSC, Client Component는 성능과 ownership을 어떻게 바꾸나?
🎛 같은 화면을 rendering 전략별 waterfall과 bundle 크기로 비교
예정
NestJS request lifecycle
middleware, guard, interceptor, pipe는 어디에서 책임을 나눠야 하나?
🎛 한 요청이 각 계층을 통과하며 실패·변환되는 경로 추적
예정
API contract와 backward compatibility
frontend와 backend를 따로 배포해도 깨지지 않게 하려면?
🎛 schema 변경 순서에 따라 구버전 client가 깨지는지 확인
예정
Authentication과 authorization
로그인했다는 사실과 이 작업을 해도 된다는 판단은 왜 다른가?
🎛 session/JWT와 resource-level permission을 공격 시나리오로 비교
예정
PostgreSQL transaction
transaction이 데이터는 지키는데 왜 서비스는 느려질까?
🎛 isolation level과 lock wait를 동시에 실행해 anomaly 관찰
6. 클라우드와 인프라
같은 system pattern이 Docker, Kubernetes, Serverless와 AWS에서 어디에 놓이는지 연결한다.
예정
Docker process model
container는 VM과 무엇이 다르고, 무엇을 격리하지 못하나?
🎛 process·filesystem·network namespace와 resource limit을 시각화
예정
Kubernetes workload model
Pod, Deployment, Service는 각각 어떤 실패를 처리하나?
🎛 Pod 종료·재시작·rolling update 동안 request 경로 관찰
예정
Autoscaling과 overload
HPA가 늘리는 동안 들어온 요청과 DB 병목은 누가 책임지나?
🎛 CPU HPA / queue metric / load shedding을 같은 spike에 비교
예정
Serverless concurrency
서버가 없어졌는데 downstream은 왜 더 빨리 무너질까?
🎛 AWS Lambda concurrency가 RDS connection을 압박하는 과정과 RDS Proxy 비교
예정
Event-driven architecture on AWS
SQS, SNS, EventBridge는 같은 메시징처럼 보여도 왜 선택이 다른가?
🎛 queue / pub-sub / event bus에서 fan-out, ordering, retry 경로 비교
예정
CDN과 Edge cache
사용자 가까이에 복사했는데 왜 Origin이 갑자기 과부하되고 오래된 화면이 보일까?
🎛 지역별 요청이 Edge와 Origin으로 흐르며 hit, miss, TTL 만료, purge와 stale 응답을 비교
예정
Terraform state와 plan
Infrastructure as Code가 있는데도 왜 실제 cloud와 코드가 어긋날까?
🎛 desired state, remote state, drift와 concurrent apply 충돌 관찰
예정
Cloud cost as architecture
같은 RPS인데 어떤 구조는 왜 10배 비쌀까?
🎛 compute, network egress, managed service 비용을 traffic pattern별 비교
예정
Local Lab CLI
실제 container와 부하 실험을 누구나 안전하고 재현 가능하게 실행하려면?
🎛 Scenario를 받아 Docker lab을 실행하고 evidence bundle을 Playground에서 시각화
7. AI와 함께 개발하기
AI에게 구현을 맡겨도 architecture, evidence와 결과에 대한 ownership을 잃지 않는다.
예정
Specification before prompt
좋은 prompt보다 먼저 정해야 할 constraint와 acceptance criteria는 무엇인가?
🎛 모호한 요청과 검증 가능한 spec이 만드는 구현 결과 비교
예정
Codebase map과 change surface
전체 코드를 외우지 않고도 변경의 영향을 어떻게 설명하나?
🎛 dependency graph에서 한 contract 변경의 downstream 영향 추적
예정
Reviewing AI-generated code
동작하는 코드와 merge해도 되는 코드를 어떻게 구분하나?
🎛 숨은 race, security, operability 문제를 review checklist로 발견
예정
Tests, evals, and CI
AI agent의 결과를 대화가 아니라 반복 가능한 evidence로 남기려면?
🎛 unit/integration/e2e/eval gate가 서로 다른 실패를 잡는 pipeline
예정
Agent orchestration
여러 agent에게 일을 나눌 때 속도보다 먼저 지켜야 할 것은?
🎛 공유 contract 없는 병렬 작업과 bounded task orchestration 비교
예정
Domain-grounded engineering coach
범용 model보다 적은 context로 더 근거 있는 engineering 답변을 만들려면?
🎛 전체 문서 prompt와 topic retrieval에서 token, citation coverage와 답변 정확도 비교
예정
Wiki에서 ADR까지
PM의 개념과 현재 architecture를 검증 가능한 의사결정 문서로 어떻게 연결하나?
🎛 질문 → 관련 topic·source 검색 → constraint 확인 → ADR 초안 → 누락 evidence 평가
예정
Decision log와 interview narrative
AI와 만든 일을 몇 달 뒤 내 경험으로 설명하려면 무엇을 기록해야 하나?
🎛 incident·PR·trade-off를 STAR와 architecture narrative로 재구성
8. 개발 방법과 설계
방법론을 이름으로 외우지 않고, 어떤 문제에서 어떤 feedback과 경계를 만드는지 실험합니다.
예정
TDD feedback loop
test를 먼저 쓰면 설계와 AI code review가 실제로 어떻게 달라질까?
🎛 같은 요구사항을 test-first와 implementation-first로 진행하며 regression과 change cost 비교
예정
DDD와 Bounded Context
하나의 단어가 서로 다른 뜻일 때 system boundary는 어디에 그어야 하나?
🎛 주문·결제·배송 model을 합치거나 분리하며 change propagation 비교
예정
OOP와 invariant
class는 언제 복잡성을 감추고, 언제 복잡성을 더 만들까?
🎛 anemic data model과 behavior-owning object에서 잘못된 상태가 생기는 경로 비교
예정
Code Smell과 Refactoring
냄새를 발견한 뒤 언제 고치고, 언제 그대로 두어야 하나?
🎛 변경 시나리오와 test를 유지하며 작은 refactoring의 비용과 효과 비교
예정
Functional Core, Imperative Shell
상태와 I/O를 어디까지 밀어내야 재현 가능한가?
🎛 같은 simulation을 숨은 상태와 pure core로 실행해 test 안정성 비교
9. 함께 일하는 언어
Engineering, Product와 Design이 같은 문제를 서로 다른 말로 설명할 때 의사결정의 접점을 만든다.
예정
Capacity Planning과 우선순위
팀이 감당할 수 있는 양과 system이 버틸 수 있는 양을 어떻게 함께 약속하나?
🎛 feature, 운영, interrupt의 비율을 바꾸며 WIP와 납기 예측 비교
예정
Carrying Capacity와 Product growth
유입은 계속되는데 활성 사용자 수는 왜 어느 지점에서 평평해질까?
🎛 비가 내리고 물이 빠지는 호수에서 Inflow, Churn과 Active users의 평형점을 조작
예정
Product metric과 기술 metric
p99 개선이 실제 사용자 경험과 business outcome을 바꿨는지 어떻게 아나?
🎛 latency와 error가 conversion, completion rate에 미치는 가상 funnel 비교
예정
Atomic Design과 UI 경계
재사용 component는 언제 일관성을 만들고 언제 domain을 숨기나?
🎛 부분과 page를 동시에 바꾸며 visual consistency와 change surface 비교
예정
접근성을 품질 조건으로
보이는 화면이 같아도 keyboard와 screen reader에서는 왜 다른가?
🎛 semantic element, focus order와 색 대비를 직접 바꾸며 사용 경로 확인
예정
Engineering Decision Record
결론만 남기지 않고 제약과 trade-off를 어떻게 팀의 기억으로 보존하나?
🎛 같은 architecture 결정을 context 유무에 따라 재검토하는 scenario
같이 만들고 싶다면
설명이 틀렸거나 simulation이 현실과 다르다면 Issue로 알려주세요. 새 랩은 구현 전에 현상, 실패해야 하는 순진한 해법, challenge constraint와 validation plan을 Proposal로 합의합니다.