이 단계에서 얻는 것
이 단계는 “스프링을 잘 쓰기” 이전에, 백엔드 개발자가 매일 마주치는 문제를 설명할 수 있는 언어를 만드는 구간입니다.
- 관찰/도구의 최소 필수: CLI, Git, 빌드/실행 흐름을 알고 “문제가 어디서 시작됐는지”를 빠르게 좁힐 수 있습니다.
- 동시성/성능의 기초 체력: 레이스 컨디션, 가시성, 락 경합, 스레드 풀 병목을 설명하고 디버깅할 수 있습니다.
- OS·네트워크의 최소 필수: “왜 느린지/왜 끊기는지/왜 타임아웃이 나는지”를 시스템 관점에서 추적할 수 있습니다.
- 문제 해결의 기본 도구: 자료구조·알고리즘을 “코딩테스트”가 아니라, 실무의 데이터 처리/성능 개선 관점으로 재사용합니다.
이 모듈을 보는 방법
이 페이지 아래에 연결된 글이 자동으로 정렬됩니다. 위에서 아래로(번호 순서대로) 읽으면서, 각 글의 “이 글에서 얻는 것/실무 기준/연습”을 따라 작은 실험을 꼭 해보세요.
왜 이런 순서인가
학습을 “이론 → 실전”으로 연결하려면, 먼저 실행/관찰 도구가 필요합니다. 그래서 이 모듈은 다음 흐름으로 구성합니다.
- 관찰/도구(리눅스/CLI, Git, 빌드)로 재현·디버깅 루틴을 만들고
- HTTP/TCP로 요청/응답이 오가는 길을 이해한 뒤
- 실행 모델(동기/비동기, 블로킹/논블로킹, 스레드풀)로 “왜 느린지”를 해석하고
- 코드 기본기(자료구조/테스트/예외/컬렉션)로 품질을 고정한 다음
- 동시성/OS/JVM/GC로 성능/장애의 근본 원인을 파고듭니다.
다음 단계로 넘어가기 전에 (권장 기준)
- “내 서비스가 느리다”를 들었을 때, CPU/IO/락/GC/네트워크 중 어디부터 확인할지 말로 설명할 수 있다.
- 스레드/풀/큐가 섞인 코드를 보고 병목이 생길 지점을 1~2개 이상 짚을 수 있다.
- HTTP 요청 하나가 실패할 때, 클라이언트·서버·네트워크 중 어디에서 끊겼는지 로그로 구분해볼 수 있다.