처음 개발을 배울 때 막히는 지점
얼마 전 지인이 개발자 공부를 시작했다며 노트북 화면을 보여줬는데, 코드보다 검색창이 더 오래 열려 있더라고요. 사실 이 모습이 꽤 익숙합니다. 개발 공부는 문법을 외우는 일처럼 보이지만, 실제로는 모르는 문제를 어떻게 쪼개고 다시 연결하느냐에 가깝습니다.
초보 개발자가 가장 많이 하는 착각은 “언어 하나를 끝내야 다음으로 갈 수 있다”는 생각입니다. 그런데 현업 개발자는 매일 모르는 걸 만납니다. 자바스크립트를 잘해도 배포에서 막히고, 파이썬을 알아도 데이터 구조에서 헤매고, 프론트엔드를 하다가도 서버 응답 형식을 들여다보게 됩니다.
그래서 처음부터 완벽하게 이해하려고 붙잡기보다, 작은 기능을 직접 만들면서 필요한 개념을 하나씩 익히는 편이 훨씬 오래 갑니다. 예를 들어 계산기, 할 일 목록, 간단한 게시판처럼 눈에 보이는 결과가 있는 작업은 공부 시간을 실제 경험으로 바꿔줍니다.
개발자 공부는 작은 프로젝트로 시작하기
개발자가 되고 싶다면 강의만 100시간 듣는 것보다, 10시간짜리 작은 프로젝트를 여러 번 완성하는 게 더 효과적일 때가 많습니다. 처음에는 대단한 서비스를 만들 필요가 없습니다. 버튼을 누르면 숫자가 올라가고, 입력한 글이 목록에 추가되고, 새로고침해도 데이터가 남는 정도면 충분합니다.
작은 프로젝트가 좋은 이유는 배운 내용이 바로 드러나기 때문입니다. 변수, 조건문, 반복문, 함수 같은 기초 문법도 실제 화면 안에서 움직이면 느낌이 달라집니다. “아, 이래서 함수로 나누는구나” 같은 순간이 옵니다.
초보자에게 좋은 프로젝트 예시
- 오늘 할 일을 추가하고 삭제하는 목록 앱
- 월 지출을 입력하면 합계를 보여주는 가계부
- 날짜별 공부 시간을 기록하는 학습 로그
- 자주 쓰는 링크나 메모를 저장하는 개인 도구
여기서 중요한 건 기능을 계속 붙이는 욕심을 조금 내려놓는 겁니다. 로그인, 알림, 통계, 디자인까지 한 번에 넣으려 하면 금방 지칩니다. 처음에는 “입력된다”, “저장된다”, “다시 보인다”처럼 한 문장으로 설명되는 기능부터 완성하는 게 좋습니다.
검색을 잘하는 것도 개발 실력입니다
개발자는 모든 문법과 명령어를 머릿속에 넣고 일하지 않습니다. 오히려 필요한 정보를 빠르게 찾고, 현재 코드에 맞게 적용하는 능력이 중요합니다. 초보 때는 에러 메시지를 보면 겁부터 나지만, 그 문장 안에 답의 절반이 들어 있는 경우가 많습니다.
예를 들어 “undefined”라는 단어가 보이면 값이 아직 없거나 잘못 가져왔을 가능성이 큽니다. “permission”이 보이면 권한 문제일 수 있고, “not found”가 보이면 파일 경로나 설치 상태를 의심해볼 수 있습니다. 이렇게 에러 문장을 단어 단위로 읽으면 막연한 불안이 조금 줄어듭니다.
검색할 때는 한국어로만 찾기보다 에러 메시지의 일부를 그대로 넣어보는 방식이 좋습니다. 개발 관련 자료는 영어로 된 답변이 훨씬 많기 때문입니다. 처음에는 번역기를 같이 써도 괜찮습니다. 중요한 건 답을 베끼는 게 아니라, 내 코드에서 왜 같은 문제가 생겼는지 확인하는 과정입니다.
실력 차이는 기록에서 갈립니다
솔직히 개발 공부를 하다 보면 어제 해결한 문제를 오늘 또 까먹습니다. 이건 기억력이 나빠서라기보다, 처음 보는 개념이 한꺼번에 많이 들어오기 때문입니다. 그래서 기록이 생각보다 큰 차이를 만듭니다.
기록은 거창한 기술 블로그가 아니어도 됩니다. “문제 상황”, “시도한 방법”, “해결된 이유” 세 줄만 남겨도 나중에 엄청난 자산이 됩니다. 특히 같은 에러를 두 번째 만났을 때, 예전에 남긴 기록을 보면 공부 시간이 확 줄어듭니다.
기록할 때 넣으면 좋은 내용
- 어떤 작업을 하다가 문제가 생겼는지
- 화면이나 터미널에 나온 에러 문구
- 내가 바꾼 코드나 설정
- 다음에 같은 문제를 만나면 먼저 확인할 부분
처음부터 멋진 글을 쓰려고 하면 기록 자체가 부담이 됩니다. 개발자는 꾸준히 배우는 직업이라서, 완벽한 글보다 다시 볼 수 있는 메모가 더 실용적입니다. 나중에 이 메모들이 쌓이면 포트폴리오 설명에도 자연스럽게 연결됩니다.
취업을 생각한다면 보여줄 결과물이 필요합니다
개발자 채용에서는 “무엇을 배웠는지”보다 “무엇을 만들어봤는지”가 더 설득력 있게 보일 때가 많습니다. 물론 알고리즘, CS 지식, 언어 이해도도 중요합니다. 그런데 초보 단계에서는 결과물이 있어야 대화가 시작됩니다.
포트폴리오 프로젝트는 복잡한 기능보다 완성도가 더 중요합니다. 버튼이 어긋나 있거나, 저장이 불안정하거나, 실행 방법이 불분명하면 좋은 인상을 주기 어렵습니다. 반대로 기능은 단순해도 사용 흐름이 자연스럽고, 왜 만들었는지 설명이 분명하면 훨씬 믿음이 갑니다.
예를 들어 “개인 가계부 앱”을 만들었다면 단순히 수입과 지출을 더하는 데서 끝내지 않고, 월별 필터와 카테고리 합계를 넣어볼 수 있습니다. 실제 사용자가 어디서 편해질지 생각한 흔적이 보이면 개발자로서의 감각도 같이 드러납니다.
포트폴리오에 적기 좋은 포인트
- 프로젝트를 만든 이유와 대상 사용자
- 직접 구현한 주요 기능 3가지
- 가장 어려웠던 문제와 해결 방식
- 다음에 개선하고 싶은 부분
근데 여기서도 과장은 금물입니다. 혼자 만든 부분과 참고한 부분을 구분해서 말하는 편이 더 좋습니다. 면접에서는 결국 질문이 이어지기 때문에, 내가 이해한 만큼 솔직하게 설명하는 사람이 오래 기억됩니다.
꾸준히 가려면 공부 루틴을 작게 잡기
개발 공부는 초반 열정보다 반복 가능한 루틴이 더 중요합니다. 하루 5시간씩 일주일 불태우는 것보다, 하루 40분씩 두 달 이어가는 쪽이 실력으로 남는 경우가 많습니다. 특히 직장이나 학교와 병행한다면 공부량을 현실적으로 잡아야 합니다.
추천하고 싶은 방식은 “읽기 20분, 만들기 20분, 기록 10분”처럼 시간을 나누는 겁니다. 강의만 보면 손이 느려지고, 코드만 치면 개념이 비어 보일 수 있습니다. 짧게라도 세 가지를 섞으면 균형이 맞습니다.
개발자는 똑똑한 사람만 하는 직업이라는 이미지가 있지만, 실제로는 막힌 지점을 버티고 다시 시도하는 사람이 강해지는 분야에 가깝습니다. 처음부터 빠른 사람도 있지만, 천천히 가면서도 자기 방식으로 쌓아가는 사람이 분명히 있습니다. 지금 작은 기능 하나를 완성했다면, 그건 이미 개발자다운 하루를 보낸 겁니다.
