Computer System 전체 지도

Computer System은 Java/Spring 코드가 OS, JVM, CPU, memory, I/O 위에서 실행되는 방식을 연결해 보는 학습 영역이다.
느린 API와 장애는 코드 한 줄이 아니라 thread 점유, GC, socket, file descriptor, disk I/O, scheduler 대기가 합쳐져 나타난다.
백엔드 개발자는 기능 구현뿐 아니라 실행 환경의 관찰 지표와 병목 원인을 연결할 수 있어야 한다.

하나의 요청은 client, kernel socket, web server, Tomcat thread, Spring handler, service, DB/client I/O, JVM heap, OS scheduler를 통과한다.
Application은 업무 규칙을 담고, JVM은 Java runtime과 memory를 관리하며, OS는 process, thread, file, socket, memory page, CPU scheduling을 관리한다.
CPU, memory, I/O, network는 서로 독립된 체크리스트가 아니라 같은 요청의 다른 비용 모델이다.
개인 프로젝트는 기본 관찰과 timeout, dump 확보가 핵심이고, 기업 운영은 SLO, alert, capacity, runbook, 변경 통제가 추가된다.
학습 순서는 전체 흐름, 실행 단위, blocking, memory, file/socket, Linux 관찰, 동시성, JVM, 병목 분석, 플레이북으로 잡는다.

Spring을 알면 실행 환경도 충분히 안다고 생각하기 쉽다.
- Spring은 요청 흐름을 추상화하지만 CPU, memory, socket, thread 비용을 없애지 않는다.
- 운영 장애에서는 추상화 아래 계층의 지표를 함께 봐야 한다.
CPU 사용률만 보면 성능 병목을 판단할 수 있다고 오해하기 쉽다.
- CPU가 낮아도 lock, I/O, pool 대기 때문에 응답은 느릴 수 있다.
- CPU가 높아도 실제 원인은 GC나 재시도 폭주일 수 있다.
개인 프로젝트에는 운영 관찰이 필요 없다고 느끼기 쉽다.
- 작은 서비스도 장애가 나면 원인 분석과 복구가 필요하다.
- 기본 로그, timeout, dump 방법은 규모와 무관하게 필요하다.

Computer System 문서를 백엔드 개발자가 배워야 하는 이유는 무엇인가?
- 서버 코드가 실제로 OS와 JVM 자원 위에서 실행되며 장애 원인도 그 자원에서 드러나기 때문이다.
Web-Back(Spring) 문서와의 경계는 무엇인가?
- Spring 설정법보다 thread, memory, JVM, OS, I/O의 실행 원리를 다룬다는 점이다.
느린 API를 볼 때 가장 먼저 나눌 축은 무엇인가?
- CPU 계산 문제인지, thread 대기 문제인지, memory/GC 문제인지, I/O 또는 network 문제인지 나누는 것이다.

동블