Python / Java
🌐 웹 개발 학습 로드맵
순서대로 진행하되, 각 단계에서 작은 결과물을 만들고 다음 단계로 넘어가세요.
다섯 단계의 뼈대
- HTML & CSS 기초
- Python 또는 Java 선택
- Django/Spring Boot 프레임워크
- REST API 설계
- 배포 & 운영
순서에는 이유가 있습니다. 브라우저에 무언가 보이는 경험을 먼저 만들고(1단계), 그 화면을 채울 데이터를 다룰 언어를 익히고(2단계), 화면과 데이터를 이어 주는 틀을 배우고(3단계), 그 연결을 다른 프로그램도 쓸 수 있는 형태로 정리하고(4단계), 마지막으로 내 노트북 밖에서 돌립니다(5단계). 각 단계는 앞 단계에서 만든 결과물 위에 얹힙니다. 순서를 건너뛰면 배우는 내용 자체가 어려워지는 게 아니라 왜 그런 게 필요한지가 안 보여서 어려워집니다.
단계별로 실제 무엇을 하게 되는가
아래 기간은 주당 10시간 안팎을 쓴다고 가정한 범위입니다. 주 5시간이면 대략 두 배, 하루를 통으로 쓸 수 있으면 절반쯤으로 보면 됩니다. 사람마다 편차가 크니 숫자보다 "완료 기준" 쪽을 기준으로 삼으세요.
1단계 · HTML과 CSS — 화면이 왜 그 모양인지 알기
배울 것은 생각보다 좁습니다. 문서 구조를 만드는 태그 열댓 개, 폼과 입력 요소, 선택자와 박스 모델, 그리고 Flexbox와 Grid 정도면 첫 프로젝트를 굴리는 데 부족하지 않습니다. 여기서 시간을 잡아먹는 건 태그 개수가 아니라 "왜 이 요소가 저기로 밀려났는가"를 설명하지 못하는 상태입니다. 브라우저 개발자 도구를 열어 실제 적용된 스타일을 확인하는 습관을 1단계에서 들여 두면 이후 전 과정이 편해집니다.
기간: 2~3주. 완료 기준: 디자인 시안 없이도 헤더·목록·폼이 있는 페이지를 처음부터 만들 수 있고, 요소가 의도한 자리에 없을 때 개발자 도구로 원인을 30분 안에 찾을 수 있으면 충분합니다. 체크포인트 프로젝트: 자기소개 페이지 한 장. 단, 반응형으로 만들어서 휴대폰 화면에서도 깨지지 않게 하는 것까지 포함합니다.
가장 흔한 막힘: CSS를 완벽히 익히고 넘어가려는 것입니다. CSS는 끝이 없고, 애니메이션이나 세밀한 타이포그래피는 지금 배워도 다음 단계에서 쓰지 않아 잊힙니다. 배치가 되고 원인을 찾을 수 있으면 그대로 2단계로 가세요.
2단계 · Python 또는 Java — 데이터를 다룰 언어 하나 정하기
둘 중 하나만 고릅니다. 둘 다 조금씩 하면 둘 다 못 씁니다. 빨리 결과를 보고 싶고 문법 부담이 적은 쪽을 원하면 Python, 타입과 구조가 명시적인 편이 이해에 도움이 되고 대규모 코드베이스 쪽을 염두에 두었다면 Java가 무난합니다. 판단이 안 서면 언어 선택 도우미나 첫 언어 고르기를 보세요.
이 단계에서 실제로 필요한 범위는 변수와 조건문, 반복문, 함수, 리스트와 딕셔너리(또는 List와 Map), 파일 읽고 쓰기, 예외 처리, 그리고 클래스의 기본입니다. 클래스는 "상속 계층을 설계하는 법"까지 갈 필요 없이, 관련된 데이터와 동작을 한 덩어리로 묶는 도구라는 감각만 잡으면 됩니다. 언어별로 클래스 문법이 어떻게 다른지는 클래스 비교에 정리되어 있습니다.
기간: 4~6주. 완료 기준: 남이 쓴 200줄짜리 코드를 읽고 흐름을 설명할 수 있고, 에러 메시지의 스택 트레이스를 보고 어느 줄이 문제인지 짚을 수 있으면 됩니다. 체크포인트 프로젝트: 파일에 데이터를 저장하는 커맨드라인 프로그램. 가계부든 할 일 목록이든, 프로그램을 껐다 켜도 데이터가 남아야 합니다.
가장 흔한 막힘: 강의를 따라 치기만 하고 빈 파일에서 시작해 본 적이 없는 상태입니다. 강의 한 편이 끝날 때마다 화면을 끄고 같은 기능을 처음부터 다시 써 보세요. 이때 막히는 부분이 실제로 안 익힌 부분입니다.
3단계 · Django 또는 Spring Boot — 화면과 데이터를 잇기
2단계에서 고른 언어에 맞춰 프레임워크가 정해집니다. Python이면 Django, Java면 Spring Boot입니다. 여기서 배울 핵심은 프레임워크의 기능 목록이 아니라 요청 하나가 들어와서 응답이 나갈 때까지의 경로입니다. 주소를 어디서 받고, 어떤 함수가 실행되고, 데이터베이스를 언제 건드리고, 화면은 어디서 만들어지는지를 그림으로 그릴 수 있어야 합니다. 이 그림이 없으면 에러가 났을 때 어디를 봐야 할지 알 수 없습니다.
같이 배워야 하는 게 데이터베이스입니다. 테이블 설계, 기본 조회와 조인, 그리고 프레임워크가 제공하는 ORM이 SQL로 어떻게 번역되는지 정도입니다. 왜 이걸 미루면 안 되는지는 데이터베이스를 일찍 배워야 하는 이유에 적어 두었습니다.
기간: 5~8주. 로드맵에서 가장 긴 구간입니다. 완료 기준: 새 기능을 하나 추가할 때 어떤 파일들을 순서대로 건드려야 하는지 스스로 나열할 수 있으면 됩니다. 체크포인트 프로젝트: 로그인이 있고, 사용자마다 자기 데이터만 보이는 게시판이나 메모 앱. 인증은 프레임워크가 제공하는 기본 기능을 그대로 쓰세요.
가장 흔한 막힘: 튜토리얼 프로젝트를 그대로 따라 만든 뒤, 거기서 한 가지 기능을 바꾸려는 순간 아무것도 못 하는 상태입니다. 이건 3단계의 정상 통과 의례에 가깝습니다. 처방은 튜토리얼을 다시 보는 게 아니라, 튜토리얼 코드에서 일부러 무언가를 망가뜨린 뒤 에러 메시지를 읽고 고쳐 보는 것입니다. 튜토리얼이 더 이상 도움이 되지 않을 때가 이 구간을 다룹니다.
4단계 · REST API 설계 — 화면 없이도 쓸 수 있게 만들기
3단계까지는 서버가 HTML을 만들어 보냈습니다. 4단계에서는 데이터만 JSON으로 보내고, 화면은 다른 쪽이 만들도록 분리합니다. 배울 것은 자원을 주소로 표현하는 방식, 메서드 선택(조회는 GET, 생성은 POST 같은 관례), 상태 코드, 그리고 입력값 검증과 에러 응답 형식입니다. HTTP 비교와 API 요청과 응답 이해하기를 옆에 두고 진행하면 좋습니다.
설계의 감을 잡는 가장 빠른 방법은 표부터 그려 보는 것입니다. 코드를 쓰기 전에 이런 형태로 정리해 두면, 나중에 프런트엔드를 붙일 때 대화가 훨씬 짧아집니다.
ENDPOINT SKETCH — 메모 앱
GET /api/notes 목록 조회 200 / 401
POST /api/notes 새로 생성 201 / 400 / 401
GET /api/notes/{id} 단건 조회 200 / 404
PATCH /api/notes/{id} 일부 수정 200 / 400 / 404
DELETE /api/notes/{id} 삭제 204 / 404
# POST 요청 본문
{ "title": "장보기", "body": "우유, 빵" }
# 201 응답 본문
{ "id": 42, "title": "장보기", "body": "우유, 빵",
"createdAt": "2026-03-01T09:12:00Z" }
# 400 응답 본문 — 형식을 프로젝트 전체에서 하나로 통일
{ "error": "VALIDATION_FAILED",
"fields": { "title": "비어 있을 수 없습니다" } }표를 먼저 그리고 나면 애매한 결정들이 눈에 보입니다. 삭제 후에 무엇을 돌려줄지, 목록이 길어지면 어떻게 나눠 보낼지, 남의 데이터를 요청했을 때 404를 줄지 403을 줄지 같은 것들입니다. 정답이 하나는 아니지만, 프로젝트 안에서는 일관돼야 합니다. JSON을 언어별로 다루는 방법은 JSON 처리 비교를 참고하세요.
기간: 3~4주. 완료 기준: 자기 API를 브라우저 없이 curl이나 API 도구로 전부 호출해 볼 수 있고, 잘못된 입력을 넣었을 때 서버가 500이 아니라 의도한 400을 돌려주면 됩니다. 체크포인트 프로젝트: 3단계에서 만든 앱을 API 버전으로 다시 만들고, 아주 단순한 자바스크립트 페이지 하나로 그 API를 호출해 목록을 그려 봅니다. 여기서 비동기 호출이 처음 나오는데, 개념이 낯설면 비동기 처리 비교와 JavaScript 학습이 도움이 됩니다.
가장 흔한 막힘: 실패 경로를 안 만드는 것입니다. 잘 되는 경우만 짜 놓으면 화면을 붙이는 순간 무너집니다. 엔드포인트를 하나 만들 때마다 "없는 id를 넣으면?", "로그인 안 하고 부르면?", "필수 값이 비면?" 세 가지를 반드시 같이 처리하세요.
5단계 · 배포와 운영 — 내 노트북 밖에서 돌리기
배울 것은 환경 변수로 설정을 분리하는 법, 데이터베이스를 로컬이 아닌 곳에 두는 법, HTTPS를 붙이는 법, 로그를 남기고 찾아보는 법, 그리고 코드를 푸시하면 자동으로 반영되게 만드는 최소한의 파이프라인입니다. 대상 플랫폼은 무료 티어가 있는 곳 아무 데나 골라도 됩니다. 여기서 중요한 건 특정 서비스 사용법이 아니라 "내 컴퓨터에서만 되던 것"과 "아무 데서나 되는 것"의 차이를 몸으로 아는 일입니다. 한 번 배포해 보면 코드 쓰는 법이 바뀝니다가 그 차이를 설명합니다.
기간: 2~3주. 완료 기준: 코드를 고쳐 푸시하면 몇 분 안에 공개 주소에 반영되고, 무언가 잘못됐을 때 로그를 열어 원인을 찾을 수 있으면 됩니다. 체크포인트 프로젝트: 4단계 API를 실제 주소로 띄우고, 친구에게 링크를 보내 써 보게 하는 것까지입니다. 남이 쓰는 순간 예상 못 한 입력이 들어오고, 그게 가장 좋은 교재입니다.
가장 흔한 막힘: 비밀 키를 코드에 그대로 넣고 커밋해 버리는 것입니다. 배포 단계에 들어가기 전에 첫 프로젝트의 보안 기본기를 한 번 읽고, 커밋 습관은 첫 주의 Git을 참고해 정리해 두세요.
API 키, 데이터베이스 비밀번호, 관리자 계정 정보는 저장소에 절대 넣지 마세요. 한 번 커밋되면 나중에 지워도 기록에 남습니다. 실수했다면 파일을 고치는 게 아니라 해당 키를 즉시 폐기하고 새로 발급하는 게 정답입니다.
지금은 건너뛰거나 미뤄도 되는 것들
웹 개발은 배울 거리가 무한해 보이는 분야고, 그래서 "안 배우기로 결정하는 일"이 배우는 일만큼 중요합니다. 아래는 첫 바퀴에서 빼도 되는 것들과 그 이유입니다.
- 프런트엔드 프레임워크. 4단계에서 화면을 붙일 때는 순수 자바스크립트 30줄이면 충분합니다. 프레임워크는 화면 상태가 복잡해질 때 필요해지는 도구라서, 복잡함을 겪기 전에 배우면 왜 그렇게 생겼는지 알 수 없습니다.
- 컨테이너와 오케스트레이션. 서버 한 대짜리 프로젝트에서는 이득이 거의 없습니다. 배포를 손으로 몇 번 해보고 "환경이 매번 달라서 귀찮다"고 느낀 다음에 배우면 30분이면 이해되는 도구입니다.
- 디자인 패턴과 아키텍처 이론. 해결할 문제를 겪기 전에 읽으면 용어만 남습니다. 3단계 프로젝트가 지저분해져서 스스로 답답할 때 읽어야 붙습니다.
- 테스트 프레임워크의 고급 기능. 다만 테스트 자체를 미루라는 뜻은 아닙니다. 4단계쯤에서 엔드포인트마다 성공/실패 케이스를 확인하는 아주 단순한 테스트는 오히려 시간을 아껴 줍니다.
- 두 번째 언어. 첫 바퀴를 다 돌기 전에 언어를 늘리지 마세요. 로드맵 한 바퀴를 끝낸 뒤라면 언어 비교를 보며 두 번째 언어를 훨씬 빠르게 익힐 수 있습니다.
전체 기간을 현실적으로 잡으면
다섯 단계를 더하면 주당 10시간 기준으로 대략 4~6개월입니다. 주 5시간이면 8개월에서 1년, 하루를 통으로 쓸 수 있는 상황이면 2~3개월도 가능합니다. 이 범위가 넓은 건 대충 적어서가 아니라 실제로 개인차가 그만큼 크기 때문입니다. 특히 3단계에서 개인차가 벌어집니다. 앞의 두 단계를 얼마나 손으로 익혔는지가 여기서 드러나기 때문입니다.
진행 상황을 스스로 확인하는 방법은 단순합니다. 각 단계의 체크포인트 프로젝트를 남에게 보여주면서 "이 부분은 이렇게 동작합니다"를 막힘 없이 설명할 수 있는지 보면 됩니다. 예제를 한 번 실행해 보는 것과, 그 예제의 일부를 바꾸고 왜 그렇게 바꿨는지 설명하는 것 사이에는 큰 차이가 있습니다. 후자가 되면 다음 단계로 넘어가세요.
한 바퀴를 돈 뒤에 무엇을 할지는 목표에 달려 있습니다. 취업이 목표라면 면접 준비 항목을 보며 지금까지 만든 결과물이 어떤 질문에 답이 되는지 정리해 두는 게 효율적입니다. 더 깊이 파고 싶다면 심층 가이드에서 걸렸던 주제만 골라 읽고, 다른 트랙이 궁금해졌다면 로드맵 목록으로 돌아가 비교해 보세요. 전체 흐름을 기간 단위로 다시 보고 싶다면 첫 100일 로드맵이 참고가 됩니다.