“프레임워크 만 잘 쓰면 되지, CS 기초 가 실무 에 쓰이나?”

내 답 은 — 평소 엔 안 보이다가, 장애 가 터지고 성능 을 짜낼 때 반드시 기초 로 돌아온다 다. 프레임워크 는 정상 경로 를 추상화 해 준다. 하지만 비정상 경로(장애·병목·경계) 에서 추상화 는 새고, 그 아래 의 DB·OS·네트워크·자료구조 가 드러난다. 이 글 은 백엔드 6 과목 이 실제 로 어디서 쓰였는지 를, 내가 운영 하는 시스템 의 구체 사례 로 정리한다.

1. 데이터베이스 — 돈 이 틀리는 곳 은 늘 여기

프레임워크(JPA) 가 SQL 을 가려 주지만, 정합성 이 걸리는 순간 격리수준·락·인덱스 를 모르면 손 도 못 댄다.

  • 동시성 제어: 정산 시스템 에서 금액 도메인 은 PESSIMISTIC_WRITE(비관적 락) 로 초과 환불 을 막고, 재고 도메인 은 @Version 낙관적 락 을 쓴다. 왜 다르게? — 충돌 빈도 와 트랜잭션 길이 라는 DB 특성 판단. 이건 격리수준·락 을 알아야 나오는 선택.
  • 멱등성: (payment_id, idempotency_key) UNIQUE 제약 으로 중복 결제 를 DB 레벨 에서 차단. 애플리케이션 체크 는 동시성 에서 뚫리지만, DB unique 는 안 뚫린다.
  • 인덱스: 느린 쿼리 는 결국 풀스캔 vs 인덱스 문제. B-tree 인덱스 의 동작 을 알아야 “왜 이 쿼리 는 인덱스 를 안 타나” 에 답 한다.

관련: 정산 시스템 을 KPI 로 — Triple Idempotency 의 L3 가 바로 DB 제약.

2. 운영체제 — 컨테이너 도 결국 프로세스 다

쿠버네티스·Docker 를 써도 그 아래 는 프로세스·스레드·메모리·cgroup 이다.

  • 메모리 관리: Velero 백업 컴포넌트 가 OOMKilled 로 44 회 죽었다. OOM = OS 가 메모리 한도 초과 프로세스 를 강제 종료 하는 것. 원인(과다 병렬 파일 읽기 → 메모리 폭증) 을 알아야 메모리 limit + 병렬도 튜닝 으로 고친다.
  • 컨테이너 = 격리된 프로세스: 컨테이너 는 마법 이 아니라 namespace(격리) + cgroup(자원 제한) 이다. 이걸 알면 “왜 컨테이너 메모리 가 host 와 다르게 보이나” 가 풀린다.
  • 스레드·동시성: 정산 재고 에 100 스레드 동시성 테스트 를 돌린다. 스레드·컨텍스트 스위칭·race condition 을 모르면 이 테스트 를 설계 조차 못 한다.

관련: 쿠버네티스 를 KPI 로 — velero OOM 44→0.

3. 네트워크 — 분산 시스템 은 네트워크 위 에 산다

MSA·쿠버네티스 는 전부 네트워크 로 연결 된다. 네트워크 를 모르면 분산 장애 를 못 잡는다.

  • 오버레이 네트워크: K3s 노드 를 재부팅 했더니 pod 간 통신 이 죽었다. 범인 은 방화벽(ufw) 이 VXLAN(오버레이 터널) 포트 를 막은 것. VXLAN·오버레이 개념 을 알아야 “노드 는 살아있는데 pod 는 왜 서로 못 부르나” 를 진단 한다.
  • HTTP·프록시·터널: Cloudflare Tunnel + frp 로 외부 포트 개방 없이 서비스 를 노출 한다. 리버스 프록시·NAT·TLS 종단 을 알아야 이 구조 를 짠다.
  • 타임아웃·재시도: 외부 API 장애 를 전제로 Retry/Circuit Breaker 를 건다. TCP 연결·타임아웃·백오프 를 모르면 장애 전파 를 못 막는다.

4. 자료구조 — 성능 은 “무엇 으로 저장 했나” 에서 갈린다

같은 데이터 도 어떤 구조 에 담느냐 로 속도 가 수십 배 갈린다.

  • 그래프 — 벡터 검색: AI 검색 에서 HNSW(계층적 근접이웃 그래프) 로 수만 개 벡터 중 근접 벡터 를 몇 홉 만에 찾는다. 그래프·계층 구조 를 알아야 왜 전수비교(brute force) 대신 이걸 쓰나 를 안다.
  • 트리 — DB 인덱스: B-tree/B+tree 가 인덱스 의 본체. 트리 를 알면 “인덱스 가 왜 범위 검색 에 강하고 앞 글자 없는 LIKE 엔 약한가” 가 보인다.
  • 해시 — 캐시·멱등: 해시맵/해시셋 이 O(1) 조회 의 근거. processed_events PK 중복 체크 도 결국 해시 기반.

관련: AI 검색·추천 을 KPI 로 — HNSW.

5. 알고리즘 — 복잡도 를 모르면 스케일 에서 터진다

작은 데이터 에선 뭘 써도 된다. 문제 는 데이터 가 커질 때 드러난다.

  • 복잡도(Big-O): 데이터 100 개 에선 O(n²) 도 멀쩡 하다. 100 만 개 면 서버 가 죽는다. “지금 은 되는데 커지면 터지는” 코드 를 미리 알아보는 눈 이 복잡도 감각.
  • 근사 알고리즘 트레이드오프: HNSW 는 정확도 를 약간 내주고 속도 를 크게 얻는 ANN(근사 최근접). “정확 vs 빠름” 을 의식적 으로 고르는 게 알고리즘 사고.
  • 도메인 알고리즘: 청각 재활(ASAT) 에선 2-down 1-up staircase(Levitt 1971) 상태머신 으로 개인별 역치 를 수렴 시킨다. 알고리즘 을 상태머신 으로 명시화 하는 훈련.

6. 컴퓨터구조 — 캐시 와 메모리 계층 이 성능 의 바닥

가장 안 보이지만, 가장 아래 에서 성능 을 결정 한다.

  • 메모리 계층: CPU 캐시 → RAM → 디스크 로 갈수록 수백~수만 배 느려진다. Caffeine 같은 인메모리 캐시 를 쓰는 이유 가 이 계층 차이. “DB 대신 캐시” 는 곧 “디스크 대신 메모리”.
  • 지역성(locality): 자주 쓰는 데이터 를 가까이 두면 빠르다. 캐시 무효화 전략(@CacheEvict) 도 결국 이 원리 위 에서 논다.
  • 자원 = 유한: CPU 코어·메모리 는 유한 하다. 노드 별 로 워크로드 를 배치 하고 CPU 과다 노드 를 cordon 하는 것 도, 결국 하드웨어 자원 을 의식 하는 감각.

결론 — 기초 는 평소 엔 안 보이는 안전망

CS 기초 는 튜토리얼 처럼 매일 쓰이지 않는다. 대신 결정적 인 순간 에 쓰인다:

  • 장애 가 터졌을 때 (OOM·VXLAN·데드락)
  • 성능 을 짜낼 때 (인덱스·캐시·복잡도)
  • 경계 를 설계 할 때 (트랜잭션·동시성·정합성)

프레임워크 는 정상 경로 를 대신 해 준다. 하지만 비정상 경로 에서 추상화 는 새고, 그 아래 기초 가 드러난다. 그리고 백엔드 의 진짜 실력 은 비정상 경로 에서 갈린다.

AI 가 코드 를 대신 써 주는 시대 라 기초 가 덜 중요 할 것 같지만, 오히려 반대 다 — AI 가 짠 코드 가 왜 틀렸는지, 어디서 터질지 를 판단 하려면 결국 DB·OS·네트워크·자료구조·알고리즘·구조 를 알아야 한다. 문제 를 정의 하는 능력 의 바닥 에도, 결국 CS 기초 가 깔려 있다.

기초 는 배신 하지 않는다. 다만 늦게 청구서 를 보낼 뿐이다.