처음에는 언어보다 생활 리듬이 더 중요합니다
얼마 전 지인이 개발자를 준비하고 싶다며 노트북부터 바꿔야 하냐고 묻더라고요. 솔직히 장비보다 먼저 잡아야 할 건 하루에 코드를 만지는 시간입니다. 처음 6개월은 재능을 확인하는 시기라기보다, 매일 1~2시간씩 낯선 문제를 버티는 습관을 만드는 시기에 가깝습니다.
개발자는 멋진 화면을 뚝딱 만드는 사람처럼 보이지만 실제 업무의 절반 이상은 문제를 쪼개고, 에러 메시지를 읽고, 왜 안 되는지 추적하는 일입니다. 그래서 처음부터 너무 거창한 목표를 세우면 금방 지칩니다. 예를 들어 “3개월 안에 취업”보다 “30일 동안 매일 작은 기능 하나 만들기”가 훨씬 현실적입니다.
시간 배분은 단순하게 잡는 게 좋습니다. 평일에는 문법 30분, 따라 만들기 40분, 복습 20분 정도면 충분합니다. 주말에는 2~3시간 정도를 잡고 평일에 만든 것을 하나로 묶어보면 실력이 눈에 보입니다. 개발 공부는 오래 앉아 있는 것보다 어제 이해 못 한 것을 오늘 조금 덜 낯설게 만드는 방식이 더 잘 맞습니다.
첫 언어는 목적에 맞춰 고르면 됩니다
개발자를 준비할 때 가장 많이 막히는 지점이 첫 프로그래밍 언어 선택입니다. 파이썬, 자바스크립트, 자바 중에서 고민하는 경우가 많죠. 그런데 정답을 찾으려고 오래 검색하기보다, 내가 만들고 싶은 것에 가까운 언어를 고르는 편이 낫습니다.
- 웹사이트 화면과 인터랙션을 만들고 싶다면 자바스크립트가 출발점으로 좋습니다.
- 데이터 분석, 자동화, 인공지능 쪽이 궁금하다면 파이썬이 접근하기 쉽습니다.
- 기업 시스템, 백엔드 취업, 안정적인 서버 개발에 관심이 크다면 자바도 괜찮습니다.
처음 2~3개월은 언어를 자주 갈아타지 않는 게 좋습니다. 문법이 조금 불편하다고 다른 언어로 옮기면 매번 입구만 반복하게 됩니다. 변수, 조건문, 반복문, 함수, 배열 같은 기본 개념은 언어가 달라도 계속 따라옵니다. 처음에는 “어떤 언어가 최고냐”보다 “이 언어로 작은 프로그램을 끝까지 만들 수 있느냐”가 더 중요합니다.
공부 순서는 작게 만들고 고치는 쪽이 빠릅니다
개발 공부를 책처럼 1장부터 끝까지 읽으려는 분들이 많습니다. 근데 실제로는 읽기만 하면 손이 안 움직입니다. 기본 문법을 어느 정도 본 뒤에는 아주 작은 결과물을 만들어야 합니다. 예를 들면 계산기, 할 일 목록, 날씨 메모장, 간단한 게시판 같은 것입니다.
처음 만든 결과물은 당연히 엉성합니다. 버튼 위치가 이상하고, 코드가 길고, 같은 내용이 반복될 수 있습니다. 그래도 괜찮습니다. 개발 실력은 처음부터 깔끔한 코드를 쓰는 능력보다, 엉성한 코드를 읽고 조금씩 고치는 과정에서 많이 늘어납니다.
추천하는 흐름은 이렇습니다. 먼저 강의나 문서로 기능 하나를 따라 만듭니다. 그다음 색상, 문구, 입력값, 저장 방식 중 하나만 바꿔봅니다. 에러가 났을 때 검색하기 전에 에러 문장을 천천히 읽습니다. 이 세 단계를 반복하면 단순 복사에서 벗어나는 속도가 빨라집니다.
포트폴리오는 큰 프로젝트 하나보다 작은 완성작 세 개가 낫습니다
초보 개발자에게 포트폴리오는 대단한 서비스를 만드는 과제가 아닙니다. 오히려 내가 어떤 문제를 어떻게 풀었는지 보여주는 기록에 가깝습니다. 예를 들어 할 일 관리 앱을 만들었다면 “추가, 수정, 삭제가 됩니다”에서 끝내지 말고, 왜 로컬 저장을 썼는지, 어떤 오류가 있었는지, 다음에는 무엇을 바꾸고 싶은지 적어두면 좋습니다.
작은 완성작 3개는 면접에서도 말하기 쉽습니다. 하나는 화면 중심, 하나는 데이터 처리 중심, 하나는 로그인이나 게시글처럼 흐름이 있는 기능으로 구성하면 균형이 생깁니다. 각 프로젝트는 2~4주 안에 끝낼 수 있는 크기가 적당합니다. 너무 큰 목표는 완성보다 방치될 가능성이 높습니다.
개발자 취업 준비는 코드만으로 끝나지 않습니다
개발자는 혼자 코딩만 하는 직업처럼 보이지만, 실제 회사에서는 협업이 꽤 큽니다. 기획자와 요구사항을 맞추고, 디자이너와 화면 상태를 조율하고, 다른 개발자의 코드를 읽어야 합니다. 그래서 깃 사용법, 이슈 작성, 간단한 문서화도 함께 익혀두면 차이가 납니다.
채용 공고를 보면 신입에게도 요구사항이 많아 보여 겁이 날 수 있습니다. 하지만 공고의 모든 항목을 100점으로 맞춰야 지원할 수 있는 건 아닙니다. 핵심 기술 2~3개를 실제 프로젝트에서 써봤고, 기본적인 문제 해결 과정을 설명할 수 있다면 지원해볼 만합니다. 특히 웹 개발 기준으로는 HTML, CSS, 자바스크립트 기본기와 하나의 프레임워크 경험, API를 주고받는 흐름 정도는 꼭 챙기는 편이 좋습니다.
이력서에는 “열심히 공부했습니다”보다 숫자와 기능을 넣는 게 낫습니다. 예를 들어 “게시글 검색 기능 구현”보다 “제목과 내용을 기준으로 게시글을 검색하고, 검색어가 없을 때 전체 목록을 보여주도록 구현”처럼 쓰면 읽는 사람이 바로 이해합니다. 프로젝트 기간, 사용 기술, 맡은 기능, 개선한 점을 짧게 적는 것도 중요합니다.
오래 가려면 비교보다 기록이 필요합니다
개발자 준비를 하다 보면 남들은 벌써 프레임워크를 쓰고, 알고리즘 문제를 풀고, 포트폴리오를 배포한 것처럼 보입니다. 사실 온라인에는 잘된 결과가 많이 올라옵니다. 중간에 막힌 시간, 에러 하나로 하루를 보낸 시간은 잘 보이지 않습니다.
그래서 저는 공부 기록을 추천합니다. 길게 쓸 필요는 없습니다. 오늘 배운 개념 1개, 막힌 오류 1개, 내일 다시 볼 코드 1개 정도면 충분합니다. 30일만 쌓아도 내가 어디서 자주 막히는지 보입니다. 이 기록은 나중에 면접에서 “문제를 어떻게 해결하나요?”라는 질문을 받았을 때도 꽤 쓸모가 있습니다.
개발자는 처음부터 모든 걸 아는 사람이 아니라, 모르는 것을 작게 나눠 끝까지 추적하는 사람에 가깝습니다. 시작이 늦었거나 전공이 다르다는 이유로 너무 움츠러들 필요는 없습니다. 다만 매일 손을 움직이고, 작은 결과물을 완성하고, 배운 것을 남기는 사람은 시간이 지날수록 확실히 달라집니다. 개발자라는 길은 화려한 지름길보다 꾸준히 쌓이는 흔적이 더 오래 힘을 발휘한다고 느낍니다.
