백엔드 엔지니어 완벽 가이드

이지연·2026년 2월 24일

웹 CS (web CS)

목록 보기

2/19

백엔드는 "서버 코드를 짜는 일"이 아니라, 수많은 동시 요청을, 신뢰할 수 없는 네트워크와 장애가 일상인 분산 환경에서, 데이터의 정확성·일관성·보안을 지키며, 정해진 지연 시간 안에 처리하고, 그걸 관측 가능하게 운영하는 일이다. 이 문서는 그 일에 필요한 지식을 5개 파트·30개 영역으로 정리한 단일 레퍼런스다. 특정 언어에 종속되지 않은 원칙 위주이며, 예시는 일반적인 웹 서비스/마이크로서비스 환경을 가정한다.

읽는 법: 위에서 아래로 추상화가 높아진다. Part I(컴퓨팅·네트워크 기초)이 모든 것의 토대이고, Part V(운영)가 가장 바깥이다. 프로덕션 장애의 근본 원인은 거의 항상 자기가 보던 계층보다 한두 단계 아래에 있다.

Part V. 운영 & 품질
23. 관측성 (로그·메트릭·트레이스)
24. 배포 · 컨테이너 · 오케스트레이션
25. 클라우드 & 서버리스
26. 보안
27. 성능 · 부하 테스트 · 프로파일링
28. 테스트
29. 데이터베이스 운영
30. 비용 · 용량 계획 · 협업

부록. 학습 로드맵 & 관통 원칙

Part I. 기반 — 컴퓨팅 & 네트워크

언어와 프레임워크는 바뀌어도 이 계층은 안 바뀐다. 성능·장애·동시성 버그의 답이 거의 다 여기 있다.

1. 운영체제 · 프로세스 · 동시성

서버는 OS 위에서 돈다. 프로세스 vs 스레드(메모리 격리 vs 공유), 컨텍스트 스위칭 비용, 가상 메모리·페이지·스왑, 파일 디스크립터(소켓·파일도 fd — "too many open files" 에러의 정체), CPU 스케줄링을 이해해야 한다.

동시성 vs 병렬성. 동시성은 여러 작업을 번갈아 다루는 구조, 병렬성은 실제로 동시에 실행되는 것. 공유 자원 문제: 경쟁 조건(race condition), 임계 구역, 락(mutex/semaphore), 데드락(상호 배제·점유 대기·비선점·순환 대기 4조건), 락 경합과 그 회피(락 프리·불변 데이터·메시지 패싱). 원자성, 메모리 가시성도 핵심이다.

2. I/O 모델 & 런타임 동시성 모델

백엔드 성능의 절반은 "I/O를 어떻게 기다리느냐" 에서 갈린다. 대부분의 서버는 CPU가 아니라 I/O(DB·네트워크) 대기에 시간을 쓴다.

I/O 모델. 블로킹(스레드가 응답까지 멈춤) → 논블로킹 → I/O 멀티플렉싱(select/poll/epoll/kqueue로 한 스레드가 다수 소켓 감시) → 비동기 I/O. 이게 "스레드 풀 모델"과 "이벤트 루프 모델"의 갈림길이다.

런타임별 동시성 모델(중요).

Node.js: 싱글 스레드 이벤트 루프 + libuv 스레드풀. I/O는 논블로킹이지만 CPU 집약 작업이 루프를 막으면 전체가 멈춘다(워커 스레드/별도 프로세스로 분리).
Go: 경량 goroutine을 OS 스레드에 M:N 매핑하는 스케줄러. 채널로 통신.
JVM/기타: OS 스레드 1:1(스레드당 메모리·스위칭 비용) → 최근 가상 스레드(Loom)로 경량화.
Python: GIL 때문에 CPU 병렬은 멀티프로세스로, I/O는 async로.

GC(가비지 컬렉션) 동작과 stop-the-world, 메모리 누수 패턴도 런타임 공통 관심사다.

3. 네트워크 (TCP/IP · HTTP · TLS)

TCP/IP. 3-way 핸드셰이크, 신뢰성·순서 보장·흐름 제어·혼잡 제어, head-of-line blocking. UDP: 비연결·비신뢰지만 빠름(실시간·게임·DNS). 소켓 프로그래밍의 개념(bind/listen/accept), keep-alive, 커넥션 재사용.

HTTP. 메서드와 멱등성, 상태코드(2xx/3xx/4xx/5xx), 헤더. HTTP/1.1(연결당 직렬) → 2(멀티플렉싱·헤더 압축) → 3(QUIC/UDP). TLS: 핸드셰이크·인증서·암호화, mTLS(서비스 간 상호 인증). DNS: 조회 흐름·캐싱·TTL, 서비스 디스커버리의 기반.

로드 밸런싱 기초. L4(TCP) vs L7(HTTP) 분산, 알고리즘(라운드로빈·least-conn·해시), 헬스 체크, 스티키 세션. 리버스 프록시(Nginx/Envoy)의 역할.

4. 자료구조 · 알고리즘 · 복잡도

화려한 알고리즘 문제 풀이가 아니라 올바른 자료구조 선택이 핵심이다. 해시맵 vs 트리 vs 배열의 트레이드오프, Big-O로 병목 추정(특히 O(n²)가 데이터 증가 시 터지는 지점), 정렬·탐색, 그래프(의존성·라우팅).

실무에서 더 중요한 건 시스템 자료구조다: 큐·스택·우선순위 큐(작업 처리), 해시(분산·캐시 키), B-tree/LSM-tree(DB 인덱스 엔진의 내부 — 왜 어떤 DB는 읽기에, 어떤 건 쓰기에 강한지), 블룸 필터(존재 여부 빠른 판정), 일관성 해싱(샤딩·캐시 분산), 머클 트리(복제 검증).

Part II. API & 통신

백엔드가 외부와 만나는 표면. 계약(contract)을 잘 설계해야 클라이언트와 다른 서비스가 안정적으로 붙는다.

5. HTTP API 설계 (REST)

리소스 중심 모델링. 명사 기반 URL(/orders/123/items), 메서드로 행위 표현(GET 조회·POST 생성·PUT 전체교체·PATCH 부분수정·DELETE 삭제), 적절한 상태코드. 멱등성(같은 요청 여러 번 = 한 번과 동일): PUT/DELETE는 멱등, POST는 아님 → 결제 같은 건 멱등성 키로 중복 방지.

좋은 API의 조건. 일관된 네이밍·에러 포맷, 페이지네이션(offset/cursor), 필터·정렬·검색 규약, 버저닝(URL/헤더), 부분 응답·필드 선택, HATEOAS(선택), 명확한 에러 바디(코드·메시지·필드). API 문서화(OpenAPI/Swagger)와 계약 우선 설계.

6. RPC · GraphQL · gRPC

REST가 전부가 아니다. GraphQL: 단일 엔드포인트로 클라가 필요한 필드만 요청(over/under-fetching 해결), 스키마·리졸버, 그러나 N+1 쿼리·캐싱·복잡도 제어 같은 새 문제. gRPC: Protobuf 기반 바이너리·HTTP/2, 빠르고 타입 안전, 스트리밍 지원 → 서비스 간 내부 통신에 강점. tRPC: 같은 언어 스택에서 타입 공유. 선택은 클라이언트 종류·성능·진화 방식의 트레이드오프다.

7. 인증 & 인가

인증(authentication, 너 누구야) 과 인가(authorization, 너 이거 해도 돼) 는 다른 문제다.

인증: 세션-쿠키(서버 상태 보관) vs JWT(자가 수용 토큰, 무상태·확장 쉬움 but 폐기 어려움), access + refresh token 구조, OAuth2 / OIDC(위임 인증·소셜 로그인), SSO, API 키, mTLS(서비스 간). 비밀번호는 해시+솔트(bcrypt/argon2), 절대 평문 저장 금지.

인가: RBAC(역할 기반), ABAC(속성 기반), 정책 엔진(OPA), 멀티테넌시 격리, 최소 권한 원칙. 토큰 만료·갱신·폐기(블랙리스트/짧은 수명) 전략.

8. 입력 검증 · 직렬화 · Rate Limiting

모든 외부 입력은 적이다. 경계에서 스키마 검증(타입·범위·필수), 화이트리스트 방식, 인젝션 방어(파라미터 바인딩). 직렬화/역직렬화: JSON이 기본, 고성능엔 Protobuf/MessagePack, 안전하지 않은 역직렬화는 RCE 취약점.

Rate limiting & throttling. 토큰 버킷/리키 버킷/슬라이딩 윈도우 알고리즘, 사용자·IP·API 키 단위, 분산 환경에선 Redis 기반. 과부하·남용·DDoS 완화, 백프레셔(backpressure)로 시스템 보호.

9. 실시간 & 비동기 메시징

요청-응답만으론 부족하다. 실시간 푸시: 롱폴링 → SSE(서버→클라 단방향) → WebSocket(양방향). 다중 서버에서의 연결 관리·브로드캐스트는 pub/sub(Redis/메시지 브로커)로 푸는데, 이는 16장 메시지 큐와 이어진다. 웹훅(외부로 이벤트 통지)·콜백 패턴, 그리고 동기 호출을 비동기로 바꿔 결합도를 낮추는 설계 감각이 필요하다.

Part III. 데이터

백엔드의 본질은 데이터다. 여기가 가장 깊고, 가장 많은 장애와 성능 문제가 나오는 영역이다.

10. 관계형 DB & SQL

SQL을 "데이터 꺼내는 문법"이 아니라 선언적 질의 언어로 다뤄야 한다. 조인(inner/outer/cross)·서브쿼리·집계·윈도우 함수·CTE를 자유자재로.

인덱스가 성능의 핵심. B-tree 인덱스의 동작, 복합 인덱스의 컬럼 순서(왼쪽 접두사 법칙), 커버링 인덱스, 카디널리티, 인덱스가 안 타는 경우(함수 적용·형변환·선두 와일드카드). 실행 계획(EXPLAIN) 을 읽어 풀스캔·잘못된 조인 순서·N+1을 잡는다. 정규화(중복 제거)와 의도적 비정규화(읽기 성능)의 균형, 제약 조건(FK·UNIQUE·CHECK).

흔한 함정. N+1 쿼리(ORM의 대표 문제), 커넥션 풀 고갈, 락 경합, 통계 미갱신. ORM은 편하지만 생성되는 쿼리를 볼 줄 알아야 한다.

11. 트랜잭션 & 동시성 제어

ACID: 원자성·일관성·격리성·지속성. 동시에 여러 트랜잭션이 같은 데이터를 건드릴 때 생기는 이상 현상을 알아야 한다 — 더티 리드, 반복 불가능 리드, 팬텀 리드.

격리 수준: Read Uncommitted → Read Committed → Repeatable Read → Serializable(강할수록 안전하지만 느림·경합↑). MVCC(Postgres·InnoDB가 읽기-쓰기 비차단을 구현하는 방식), 비관적 락 vs 낙관적 락(버전 컬럼), 데드락 탐지·회피, SELECT ... FOR UPDATE. 분산 환경의 트랜잭션은 19·21장(2PC·Saga)으로 이어진다.

12. NoSQL & 저장소 선택

"관계형이 항상 정답"은 아니다. 유형별 특성과 용처를 알아야 한다.

Key-Value(Redis·DynamoDB): 초고속 단순 조회·캐시·세션.
Document(MongoDB): 유연한 스키마·중첩 문서, 집계.
Wide-Column(Cassandra·HBase): 대규모 쓰기·시계열, 높은 쓰기 처리량.
Graph(Neo4j): 관계 탐색(추천·소셜·경로).
시계열/검색/벡터 DB: 모니터링·로그·임베딩 검색 등 특화.

선택 기준: 접근 패턴(읽기/쓰기 비율·쿼리 형태), 일관성 요구, 확장 방식, 스키마 유연성. 폴리글랏 퍼시스턴스(용처마다 다른 저장소)도 흔하다. NoSQL은 보통 강한 일관성·조인·트랜잭션을 일부 포기하고 확장성·성능을 얻는다.

13. 데이터 모델링 & 마이그레이션

접근 패턴이 모델을 결정한다. 관계형은 정규화로 시작하되 쿼리 기준으로 조정, NoSQL은 "어떻게 읽을지"부터 역으로 설계(쿼리 주도 모델링). 엔티티 관계(1:N, N:M), 이력·감사 추적(audit), 소프트 삭제, 멀티테넌시 모델(공유 vs 분리).

스키마 마이그레이션(운영 핵심). 무중단 배포를 위한 하위 호환 변경, 확장-수축(expand-contract) 패턴(컬럼 추가 → 양쪽 쓰기 → 백필 → 읽기 전환 → 구컬럼 제거), 대용량 테이블 변경 시 락 회피, 롤백 전략, 마이그레이션 버전 관리. 잘못된 마이그레이션은 전체 장애로 직결된다.

14. 캐싱

"캐싱은 어렵다. 무효화와 네이밍이 컴퓨터 과학의 두 난제"라는 말이 있다.

계층: 클라/CDN/애플리케이션/DB. 패턴: cache-aside(가장 흔함 — 앱이 직접 채움), read-through, write-through(쓰기 시 동시 갱신), write-behind(나중에 비동기). 무효화: TTL, 이벤트 기반, 버전 키. 함정: 캐시 스탬피드/썬더링 허드(만료 순간 동시 요청 쇄도 → 락·조기 갱신·jitter로 완화), 캐시 일관성(stale data), hot key, 캐시 침투(없는 키 반복 조회 → 음수 캐싱). 무효화 전략 없는 캐싱은 버그 공장이다.

15. 검색 & 분석 (OLTP vs OLAP)

OLTP(트랜잭션 처리 — 빠른 단건 읽기/쓰기)와 OLAP(분석 — 대량 집계)는 요구가 정반대다. 분석 쿼리를 운영 DB에서 돌리면 둘 다 망가진다 → 읽기 복제본·데이터 웨어하우스(Snowflake/BigQuery)·컬럼형 저장소로 분리.

전문 검색: Elasticsearch/OpenSearch(역색인·랭킹·집계·자동완성), DB의 LIKE '%...%' 한계. 데이터 파이프라인: ETL/ELT, CDC(변경 데이터 캡처)로 운영 DB → 분석계 동기화. 최근엔 벡터 검색(임베딩 기반 의미 검색).

16. 메시지 큐 & 이벤트 스트리밍

서비스 간 결합을 끊고, 부하를 흡수하고, 비동기로 처리하는 핵심 인프라.

큐(RabbitMQ/SQS) vs 로그/스트림(Kafka). Kafka: 파티션(병렬·순서는 파티션 내에서만 보장), 컨슈머 그룹, 오프셋, 보존(replay 가능). 전달 보장: at-most-once / at-least-once(기본·중복 가능 → 컨슈머 멱등성 필수) / exactly-once(어렵고 비쌈). 순서 보장, 백프레셔, 데드레터 큐(처리 실패 격리), 컨슈머 재처리. 이벤트 기반 아키텍처(이벤트로 통신)·아웃박스 패턴(DB 트랜잭션과 메시지 발행의 원자성)도 여기서 다룬다.

Part IV. 아키텍처 & 분산 시스템

코드 한 대를 넘어 시스템을 설계하는 영역. 백엔드 시니어의 핵심.

17. 애플리케이션 아키텍처

한 서비스 내부를 어떻게 구조화하느냐. 계층형(Layered): 컨트롤러-서비스-리포지토리. 헥사고날/포트앤어댑터·클린 아키텍처: 비즈니스 로직을 중심에 두고 DB·웹·외부 연동을 바깥 어댑터로 — 의존성이 안(도메인)으로만 향하게 해서 인프라 교체에 강하게.

DDD(도메인 주도 설계): 도메인 모델·바운디드 컨텍스트·애그리거트로 복잡한 비즈니스를 다룸. CQRS(읽기/쓰기 모델 분리), 이벤트 소싱(상태 대신 이벤트 시퀀스를 저장). 모든 곳에 쓸 도구는 아니고, 복잡도가 정당화될 때 쓰는 판단이 중요하다.

18. 모놀리스 vs 마이크로서비스

모놀리스가 기본값이어야 한다. 단순·트랜잭션 쉬움·배포 단순. 마이크로서비스는 팀 자율성·독립 배포·기술 다양성·부분 확장을 주지만, 분산의 모든 고통(네트워크 실패·분산 트랜잭션·데이터 일관성·디버깅·운영 복잡도)을 떠안는다.

서비스 경계는 비즈니스 능력(바운디드 컨텍스트)으로 나눈다 — 잘못 나누면 분산 모놀리스가 된다. 서비스 간 통신(동기 REST/gRPC vs 비동기 이벤트), 서비스별 DB(공유 DB 금지), API 게이트웨이, 서비스 메시(Istio). "마이크로서비스가 필요한가"를 의심하는 것이 가장 중요한 역량이다.

19. 분산 시스템 기초 (CAP · 합의 · 복제)

여러 노드에 데이터·연산이 흩어지면 새로운 법칙이 적용된다.

CAP 정리: 네트워크 분할(P) 상황에서 일관성(C)과 가용성(A) 중 하나를 택해야 한다. 실무에선 PACELC(분할 없을 땐 지연 vs 일관성)이 더 현실적. 일관성 모델: 강한 일관성 vs 최종 일관성(eventual) vs 인과 일관성.

복제: 리더-팔로워(읽기 확장·복제 지연 문제), 다중 리더(충돌 해결), 리더리스(쿼럼 R+W>N). 파티셔닝/샤딩: 데이터를 키로 분산(해시·범위), 리밸런싱, 핫스팟. 합의: Raft/Paxos(분산 환경에서 하나의 값에 동의 — 리더 선출·설정 관리). 시간: 분산 환경엔 신뢰할 절대 시계가 없음(논리 시계·벡터 시계). 분산 락·분산 트랜잭션(2PC의 한계).

20. 확장성 & 부하 분산

수직 확장(서버 키우기) 은 한계가 있고, 수평 확장(서버 늘리기) 이 본질이다. 그러려면 무상태(stateless) 가 전제 — 세션·상태를 외부(Redis/DB)로 빼야 아무 서버나 요청을 받는다.

로드 밸런서, 오토스케일링, DB 확장(읽기 복제본 → 샤딩), 캐시 계층, CDN, 비동기 오프로딩. 병목은 보통 DB다 — 무작정 앱 서버만 늘려선 안 된다. 용량 추정(QPS·동시성·데이터 증가율)과 부하 지점 예측.

21. 신뢰성 & 복원력

분산 환경에선 장애가 정상이다. 한 부분의 실패가 전체로 번지지 않게 설계한다.

타임아웃(무한 대기 금지), 재시도 + 지수 백오프 + 지터(동시 재시도 폭주 방지), 서킷 브레이커(실패하는 의존성 호출을 잠시 차단), 벌크헤드(자원 격리로 장애 전파 차단), graceful degradation(일부 기능 저하로 핵심 유지), 멱등성(재시도 안전). 분산 트랜잭션은 2PC 대신 Saga 패턴(보상 트랜잭션)으로. 헬스 체크, 우아한 종료(graceful shutdown), 카오스 엔지니어링.

22. 비동기 작업 & 스케줄링

요청-응답 밖에서 도는 일들. 작업 큐(Celery/Sidekiq/Bull)로 무거운 작업(이메일·이미지 처리·리포트)을 백그라운드로. 재시도·실패 처리·우선순위·동시성 제어. 스케줄링: cron·지연 작업·분산 스케줄러(여러 인스턴스에서 중복 실행 방지 — 리더 선출/분산 락). 배치 처리: 대량 데이터 주기 처리, 체크포인트·재시작. 작업의 멱등성과 정확히 한 번 실행 보장의 어려움.

Part V. 운영 & 품질

코드를 짜는 것과 프로덕션에서 돌리는 것은 다른 일이다. 백엔드는 운영까지가 책임이다.

23. 관측성 (로그 · 메트릭 · 트레이스)

무슨 일이 일어나는지 모르면 못 고친다. 관측성의 3대 기둥:

로그: 구조화된 로그(JSON), 레벨, 상관관계 ID(요청 추적), 중앙 집계(ELK/Loki). 민감정보 마스킹.
메트릭: 시계열 수치(요청 수·지연·에러율·자원 사용 — RED/USE 방법론), Prometheus + Grafana.
트레이스: 분산 추적(OpenTelemetry/Jaeger)으로 한 요청이 여러 서비스를 지나는 경로·지연을 추적.

알림과 SLI/SLO/SLA(서비스 수준 지표·목표·계약), 에러 버짓, 온콜·인시던트 대응·포스트모템. "로그를 grep하는" 수준을 넘어 시스템 상태를 한눈에 보는 능력.

24. 배포 · 컨테이너 · 오케스트레이션

CI/CD: 커밋마다 빌드·테스트·정적분석·배포 자동화. 무중단 배포 전략 — 블루-그린, 카나리(점진 노출), 롤링, 피처 플래그. 롤백 자동화.

컨테이너(Docker): 환경 일관성·격리·이식성, 이미지 레이어·크기 최적화. 오케스트레이션(Kubernetes): 파드·디플로이먼트·서비스·인그레스, 오토스케일링·셀프힐링·롤아웃, 리소스 limit/request, 컨피그/시크릿. IaC(Terraform) 로 인프라를 코드로 관리. 12-Factor App 원칙(설정 환경변수화·무상태·로그 스트림 등).

25. 클라우드 & 서버리스

클라우드(AWS/GCP/Azure)의 핵심 빌딩블록: 컴퓨트(VM/컨테이너/함수), 매니지드 DB, 오브젝트 스토리지(S3), 큐·pub/sub, 로드밸런서, VPC·네트워킹, IAM(권한). 매니지드 서비스 활용(직접 운영 대신)이 생산성을 좌우한다.

서버리스(Lambda 등): 인프라 관리 없이 함수 단위 실행, 자동 확장·사용량 과금. 대가는 콜드 스타트, 실행 시간·상태 제약, 벤더 종속, 디버깅. 이벤트 기반·간헐적 워크로드에 적합. 멀티클라우드·하이브리드의 트레이드오프.

26. 보안

백엔드는 보안의 최후 방어선이다. OWASP Top 10을 알아야 한다: 인젝션(SQLi — 파라미터 바인딩으로 방어), 인증·세션 취약점, 접근 제어 실패(IDOR — 남의 리소스 접근), SSRF, 안전하지 않은 역직렬화, 취약한 의존성, 보안 설정 오류, 민감정보 노출.

핵심 실천: 최소 권한, 심층 방어, 모든 입력 검증, 출력 인코딩, 전송·저장 암호화(TLS·at-rest), 시크릿 관리(코드에 키 금지 — Vault/시크릿 매니저), 비밀번호 해싱(argon2/bcrypt), 감사 로그, 의존성 스캔(SCA)·정적분석(SAST). 개인정보·규제(GDPR 등) 준수. 보안은 기능이 아니라 전 과정에 스며들어야 한다.

27. 성능 · 부하 테스트 · 프로파일링

측정 없이 최적화 없다. 지연(latency)과 처리량(throughput)은 다른 축이고, 평균이 아니라 꼬리 지연(p95/p99) 을 봐야 한다(소수 느린 요청이 사용자 경험을 망친다).

프로파일링: CPU/메모리/할당 프로파일러로 병목 지점 특정, 플레임그래프. 부하 테스트(k6/Gatling/Locust): 정상·피크·스파이크·내구(soak) 테스트로 한계와 병목·메모리 누수를 사전 발견. 흔한 병목: DB 쿼리·N+1·락 경합·커넥션 풀·직렬화·외부 호출. 커넥션 풀링·배치·캐싱·비동기화로 개선.

28. 테스트

단위 테스트(순수 로직 — 빠르고 많이), 통합 테스트(DB·외부 연동 포함 — Testcontainers로 실제 DB), 계약 테스트(서비스 간 API 계약 검증 — Pact), E2E/부하 테스트. 테스트 피라미드, 테스트 더블(mock/stub/fake), 테스트 데이터 관리, 결정론적 테스트(시간·랜덤·외부 의존 격리). 멱등성·동시성·실패 경로 테스트가 백엔드에선 특히 중요하다.

29. 데이터베이스 운영

DB는 짜는 것보다 운영이 어렵다. 백업 & 복구(정기 백업·시점 복구 PITR·복구 리허설 — 복구 안 해본 백업은 백업이 아니다), 복제 & 페일오버(고가용성·자동 승격), 커넥션 풀링(앱-DB 연결 관리 — 풀 고갈이 흔한 장애), 모니터링(느린 쿼리·락·복제 지연), 용량·인덱스 유지보수(VACUUM 등), 무중단 스키마 변경(13장), 읽기 복제본 라우팅. 데이터 보존·아카이빙 정책.

30. 비용 · 용량 계획 · 협업

엔지니어링 결정은 곧 비용이다. 클라우드 비용(컴퓨트·스토리지·네트워크 egress·매니지드 서비스) 이해와 최적화(적정 사이징·예약·자동 스케일·캐싱으로 DB 부하↓). 용량 계획: 트래픽 성장 예측, 한계 지점 사전 파악.

협업: API 계약·설계 문서(RFC/ADR로 의사결정 기록), 코드 리뷰, 온콜·운영 문서(runbook), 프론트·인프라·데이터 팀과의 인터페이스 합의. 기술 선택의 트레이드오프를 비용·운영·팀 역량까지 포함해 설명하는 능력.

부록. 학습 로드맵 & 관통 원칙

대략적 성장 순서

언어 + HTTP API + 관계형 DB/SQL 기본: 동작하는 서비스를 만드는 단계.
OS·네트워크·동시성/IO 모델 기초: 왜 느린지·왜 깨지는지 설명하는 단계.
트랜잭션·인덱스·캐싱·인증/보안: 정확하고 안전하고 빠른 데이터 처리.
아키텍처(계층·DDD)·테스트·관측성: 유지보수·운영 가능한 시스템.
분산 시스템·확장성·복원력·메시징: 규모와 장애를 견디는 시스템.
클라우드·오케스트레이션·비용·시스템 설계 의사결정: 시스템 레벨 판단.

전 영역을 관통하는 원칙

장애는 정상이다 — 모든 외부 호출은 실패·지연한다고 가정하고 타임아웃·재시도·격리를 설계한다.
데이터 정확성이 최우선 — 트랜잭션·일관성·멱등성을 대충 다루면 돈과 신뢰를 잃는다.
모든 입력은 적이다 — 경계에서 검증하고, 최소 권한으로, 심층 방어한다.
무상태로 만들 것 — 확장의 전제. 상태는 외부 저장소로.
측정 없이 최적화 없다 — 꼬리 지연(p99)을 보고, 병목은 대개 DB다.
관측 가능하게 만들 것 — 로그·메트릭·트레이스 없는 운영은 눈 감고 운전하는 것.
단순함을 기본값으로 — 모놀리스·관계형 DB·동기 호출에서 시작하고, 복잡도(마이크로서비스·NoSQL·이벤트)는 정당화될 때만 도입한다.
트레이드오프로 사고할 것 — "정답"은 없고 맥락(규모·팀·비용·일관성 요구)에 따른 선택만 있다.

프론트엔드 가이드와 마찬가지로, 이 문서의 가치는 "모든 걸 안다"가 아니라 전체 지도를 갖고서, 문제가 생겼을 때 어느 계층을 파야 하는지 아는 것에 있다. 백엔드는 특히 데이터(Part III)와 분산 시스템(Part IV)에서 깊이가 갈린다.

이지연

Eazy하게

이전 포스트

프론트엔드 엔지니어 완벽 가이드

다음 포스트