1단계: 백엔드 기초 다지기 (언어/알고리즘/CS)

이 단계에서 얻는 것

이 단계는 “스프링을 잘 쓰기” 이전에, 백엔드 개발자가 매일 마주치는 문제를 설명할 수 있는 언어를 만드는 구간입니다.

• 관찰/도구의 최소 필수: CLI, Git, 빌드/실행 흐름을 알고 “문제가 어디서 시작됐는지”를 빠르게 좁힐 수 있습니다.
• 동시성/성능의 기초 체력: 레이스 컨디션, 가시성, 락 경합, 스레드 풀 병목을 설명하고 디버깅할 수 있습니다.
• OS·네트워크의 최소 필수: “왜 느린지/왜 끊기는지/왜 타임아웃이 나는지”를 시스템 관점에서 추적할 수 있습니다.
• 문제 해결의 기본 도구: 자료구조·알고리즘을 “코딩테스트”가 아니라, 실무의 데이터 처리/성능 개선 관점으로 재사용합니다.

이 모듈을 보는 방법

이 페이지 아래에 연결된 글이 자동으로 정렬됩니다. 위에서 아래로(번호 순서대로) 읽으면서, 각 글의 “이 글에서 얻는 것/실무 기준/연습”을 따라 작은 실험을 꼭 해보세요.

왜 이런 순서인가

학습을 “이론 → 실전”으로 연결하려면, 먼저 실행/관찰 도구가 필요합니다. 그래서 이 모듈은 다음 흐름으로 구성합니다.

1. 관찰/도구(리눅스/CLI, Git, 빌드)로 재현·디버깅 루틴을 만들고
2. HTTP/TCP로 요청/응답이 오가는 길을 이해한 뒤
3. 실행 모델(동기/비동기, 블로킹/논블로킹, 스레드풀)로 “왜 느린지”를 해석하고
4. 코드 기본기(자료구조/테스트/예외/컬렉션)로 품질을 고정한 다음
5. 동시성/OS/JVM/GC로 성능/장애의 근본 원인을 파고듭니다.

다음 단계로 넘어가기 전에 (권장 기준)

• “내 서비스가 느리다”를 들었을 때, CPU/IO/락/GC/네트워크 중 어디부터 확인할지 말로 설명할 수 있다.
• 스레드/풀/큐가 섞인 코드를 보고 병목이 생길 지점을 1~2개 이상 짚을 수 있다.
• HTTP 요청 하나가 실패할 때, 클라이언트·서버·네트워크 중 어디에서 끊겼는지 로그로 구분해볼 수 있다.