목표에서 시작하는 개발 학습 로드맵

로드맵은 지도이지 시간표가 아닙니다

학습 로드맵을 처음 펼치면 대부분 같은 실수를 합니다. 목록을 위에서부터 지워 나가야 할 과제로 읽는 것입니다. 그러면 3단계쯤에서 반드시 멈춥니다. 앞 단계를 "끝냈다"고 표시했지만 실제로는 손에 남은 게 없기 때문입니다. 아래 네 갈래의 로드맵은 순서를 알려주는 지도로 쓸 때 값이 있습니다. 어디쯤에서 무엇이 나오는지 미리 알면 지금 막힌 지점이 원래 어려운 곳인지, 아니면 순서를 건너뛰어서 어려워진 곳인지 구분할 수 있습니다. 실무에서 남을 가르쳐 보면, 초보자가 겪는 막힘의 상당수는 재능이나 노력의 문제가 아니라 순서의 문제였습니다.

그래서 이 페이지는 네 개의 링크를 나열하는 데서 끝내지 않으려 합니다. 어떤 트랙을 고를지, 고른 다음 무엇이 공통으로 필요한지, 잘못 골랐다는 신호는 어떻게 생겼는지, 그리고 한 주가 실제로 어떤 모양으로 굴러가야 지속되는지를 먼저 이야기합니다. 트랙별 세부 단계는 각 카드 안에 있습니다.

네 갈래는 결국 같은 기초 위에 서 있습니다

웹, AI, 모바일, 백엔드는 채용 공고에서는 다른 직군처럼 보이지만 실제로 하는 일은 크게 겹칩니다. 어느 트랙이든 결국 이런 것들을 합니다. 데이터를 어딘가에 저장하고 다시 꺼냅니다. 네트워크 너머로 요청을 보내고 응답을 해석합니다. 남이(주로 6개월 뒤의 자신이) 읽을 수 있는 형태로 코드를 남깁니다. 무언가 고장 났을 때 "어디부터 이상해졌는지"를 좁혀 들어갑니다. 트랙이 갈리는 지점은 무엇을 알아야 하는가가 아니라 어떤 문제를 더 자주 만나는가입니다.

이 말이 중요한 이유는, 지금 고른 트랙이 나중에 마음에 들지 않아도 배운 것의 대부분이 그대로 넘어가기 때문입니다. 트랙 선택을 인생의 분기점처럼 무겁게 다루지 않아도 됩니다. 네 트랙 모두에서 반복적으로 등장하는 공통 기반은 대략 이 정도입니다.

• 요청과 응답이 오가는 방식. 상태 코드와 헤더가 왜 그렇게 생겼는지 감이 오면 프런트든 서버든 앱이든 디버깅 속도가 달라집니다. HTTP 요청·응답 비교와 API 요청과 응답 이해하기가 이 지점을 다룹니다.
• 데이터를 표현하는 형식. 실무에서 주고받는 데이터의 대부분은 JSON이고, 이 구조를 언어별로 어떻게 다루는지는 JSON 처리 비교에 정리해 두었습니다.
• 데이터를 어디에 어떤 모양으로 저장할지. 이걸 나중으로 미룰수록 프로젝트가 커졌을 때 되돌리기 어려워집니다. 데이터베이스를 일찍 배워야 하는 이유를 참고하세요.
• 버전 관리. 첫 주부터 커밋을 남기기 시작하는 게 좋습니다. 첫 주의 Git에 최소 사용법이 있습니다.
• 내 컴퓨터 밖에서 코드를 돌려 보는 경험. 한 번 배포해 보면 코드 쓰는 법이 바뀝니다에서 왜 이걸 빨리 해봐야 하는지 설명합니다.

즉 아래에서 어떤 카드를 고르든, 위 다섯 가지는 어느 시점에서 반드시 만납니다. 트랙 선택은 "이 다섯 개를 어떤 문맥에서 배울 것인가"를 고르는 일에 가깝습니다.

고르기 전에 스스로에게 던질 세 가지 질문

"어느 분야가 전망이 좋은가"로 고르면 대체로 오래 못 갑니다. 전망은 본인이 확인할 수 없는 정보고, 확인할 수 없는 이유로 시작한 일은 힘들어졌을 때 붙잡을 근거가 없습니다. 대신 확인 가능한 세 가지로 고르는 편이 낫습니다.

1. 결과가 눈에 보여야 힘이 나는 편인가? 화면에 무언가 그려지고 버튼이 눌리는 걸 봐야 계속할 수 있는 사람이라면 웹 개발이나 모바일 앱이 유리합니다. 반대로 숫자가 맞아떨어지거나 로그가 깔끔하게 흐르는 걸 볼 때 만족스럽다면 백엔드나 AI 쪽이 덜 지겹습니다.
2. 이미 손에 쥔 데이터나 문제가 있는가? 정리하고 싶은 스프레드시트, 자동화하고 싶은 반복 작업, 매번 손으로 찾아보는 정보가 있다면 그게 가장 좋은 출발점입니다. AI 개발 트랙은 특히 "내 데이터"가 있을 때 진도가 빠릅니다. 소재가 없으면 남의 예제를 따라 치는 시간이 길어집니다.
3. 한 번에 확보할 수 있는 시간 덩어리가 얼마인가? 하루 30분씩 쪼개 쓸 수밖에 없는 상황이라면 환경 설정이 무거운 트랙은 불리합니다. 매번 다시 켜고 다시 기억해내는 데 그 30분이 다 갑니다. 주말에 서너 시간을 몰아 쓸 수 있다면 선택지가 넓어집니다.

세 질문에 답해도 언어가 안 정해진다면 언어 선택 도우미로 좁혀 보고, 판단 기준 자체가 궁금하다면 첫 언어 고르기를 읽어 보세요. 언어별 성격 비교는 언어 라이브러리와 언어 비교에 있습니다.

트랙을 잘못 골랐다는 신호, 그리고 아닌 신호

중간에 흔들릴 때 가장 필요한 건 "이건 원래 어려운 구간인가, 아니면 나한테 안 맞는 건가"를 구분하는 기준입니다. 둘은 느낌이 비슷하지만 대응이 정반대입니다.

잘못 골랐다는 신호에 가까운 것: 만들고 있는 결과물 자체에 아무 흥미가 없습니다. 완성해도 "그래서 뭐" 싶고, 남에게 보여주고 싶은 마음이 안 듭니다. 이 트랙에서 잘하는 사람이 자랑하는 것들을 봐도 부럽지 않습니다. 이런 상태가 몇 주 이어진다면 트랙을 바꾸는 게 맞습니다. 앞서 말했듯 배운 기초는 넘어갑니다.

잘못 고른 게 아닌 신호: 에러 메시지가 무슨 말인지 모르겠고, 튜토리얼대로 했는데 안 되고, 같은 개념을 세 번 읽었는데도 설명을 못 하겠습니다. 이건 전부 정상 구간입니다. 특히 3~4단계 언저리, 즉 프레임워크나 외부 시스템이 등장하기 시작하는 지점에서 거의 모든 사람이 여기를 통과합니다. 튜토리얼이 갑자기 도움이 안 되기 시작하는 시점에 대해서는 튜토리얼이 더 이상 도움이 되지 않을 때에 따로 정리해 두었습니다.

체크리스트로 변질되지 않게 쓰는 법

로드맵의 각 단계는 "읽어야 할 분량"이 아니라 "만들 수 있게 되어야 할 것"으로 번역해서 쓰는 게 좋습니다. 예를 들어 "REST API 설계"를 문서 한 편 읽는 일로 받아들이면 하루면 끝나지만 남는 게 없습니다. 대신 "내가 만든 목록 데이터를 조회·추가·삭제할 수 있는 엔드포인트 세 개를 직접 짜고, 각 엔드포인트가 왜 그 주소와 그 메서드인지 설명할 수 있다"로 바꾸면 며칠이 걸리지만 그 뒤로 사라지지 않습니다.

단계마다 이 형식으로 완료 기준을 하나씩 적어 두세요. 기준은 "남에게 소리 내어 설명할 수 있는가" 정도면 충분합니다. 설명하다가 막히는 지점이 곧 아직 안 배운 지점입니다. 이 방식으로 진행하면 진도는 느려 보여도 되돌아오는 횟수가 줄어듭니다.

또 하나, 단계마다 붙일 작은 프로젝트는 끝낼 수 있는 크기여야 합니다. 완성하지 못한 프로젝트가 세 개 쌓이면 학습보다 자책이 먼저 쌓입니다. 크기를 정하는 감각은 끝낼 수 있는 첫 프로젝트 고르기를 참고하세요. 그리고 남에게 보여줄 예정이라면 시작 단계에서 첫 프로젝트의 보안 기본기를 한 번 훑어 두는 편이 나중에 편합니다.

한 주가 실제로 굴러가는 모양

지속되는 학습 습관은 대체로 비슷한 모양입니다. 새로운 걸 읽는 시간, 읽은 걸로 뭔가 만드는 시간, 그리고 만든 걸 다시 들여다보는 시간이 섞여 있습니다. 셋 중 하나만 하면 오래 못 갑니다. 읽기만 하면 손이 안 따라오고, 만들기만 하면 늘 쓰던 방식만 쓰게 되고, 돌아보지 않으면 같은 실수를 반복합니다.

• 주중에는 짧게, 대신 매일 코드를 건드립니다. 20분이라도 파일을 열면 다음날 다시 붙는 비용이 확 줄어듭니다.
• 주말에 한 번은 두세 시간짜리 덩어리를 확보해서, 그 주에 배운 걸로 실제 동작하는 무언가를 붙입니다.
• 주말 끝에 10분만 써서 "이번 주에 새로 설명할 수 있게 된 것" 한 줄을 남깁니다. 이 기록이 쌓이면 정체된 것 같은 시기에 근거가 됩니다.

기간에 대해서는 솔직하게 말하는 편이 낫습니다. 아래 트랙들의 5단계를 한 바퀴 도는 데 걸리는 시간은 주당 투자 시간에 크게 좌우됩니다. 주 5시간이면 반년 이상, 주 10~15시간이면 서너 달, 하루를 통으로 쓸 수 있는 상황이면 두 달 안쪽도 가능합니다. 다만 어느 경우든 이건 "한 바퀴 돌았다"는 뜻이지 "다 안다"는 뜻이 아닙니다. 첫 100일을 어떻게 배치하는지는 첫 100일 로드맵에 더 자세히 적어 두었습니다.

한 바퀴를 돈 다음에는 로드맵 대신 실제 문제를 따라가게 됩니다. 그때부터는 심층 가이드에서 필요한 주제만 골라 읽고, 학습 라이브러리로 문법을 확인하고, 남들이 실무에서 부딪힌 기록은 필드 노트와 블로그에서 찾는 방식이 잘 맞습니다. 취업을 목표로 한다면 면접 준비 항목을 미리 훑어 두고, 로드맵을 도는 동안 만든 결과물이 그중 어떤 질문에 답이 되는지 표시해 두세요.