초보 웹 개발자의 공부 방향과 차별화

왜 방향이 필요한가

신입 개발자 채용은 여전히 어렵다. 회사는 교육 없이 바로 일할 사람을 원하고, 기술이 복잡해진 만큼 신입에게 바라는 수준도 올라갔다. 대신 클라우드, 무료 강의, 커뮤니티 덕분에 혼자 공부할 환경은 훨씬 좋아졌다. 결국 무엇을 얼마나 깊게 공부하고, 그 결과를 어떻게 보여 주느냐가 갈린다.

무엇을 공부할까

분야: 하나는 깊게, 나머지는 기본만

웹 개발은 크게 프론트엔드, 백엔드, 인프라(DevOps)로 나뉜다. 모든 영역을 다 하는 풀스택은 드물다. 한 분야를 깊게 파고, 협업에 필요한 만큼 다른 분야의 기본을 익힌다. 대기업은 스페셜리스트를, 스타트업은 여러 역할을 하는 제너럴리스트를 선호하는 경향이 있다.

로드맵의 중요도 표시를 따른다

roadmap.sh의 분야별 로드맵은 항목마다 중요도를 표시한다.

표시	공부 깊이
추천	깊게 공부한다
대체 가능한 옵션	무엇인지 기본만 안다
선택·비추천	있다는 것만 안다

다 알 수는 없다. React를 쓰는 회사에서는 React·Vue·Angular를 얕게 아는 사람보다 Vue 하나를 깊게 아는 사람이 더 좋은 평가를 받을 수 있다. 깊이는 옮겨 가기 때문이다.

대부분 회사가 지원자를 거르려고 알고리즘 테스트를 본다. 그래프 탐색(DFS·BFS)과 주요 자료구조는 따로 준비한다. 정답을 보고 이해한 뒤 직접 구현할 수 있는 수준이면 충분하다. 알고리즘 대신 과제형 테스트를 보는 회사를 골라 지원하는 방법도 있다. 연습 사이트는 백준, 프로그래머스, LeetCode가 대표적이다. 풀이 요령은 코딩 테스트 접근법에 있다.

기본기: 호기심으로 쌓는다

프레임워크 덕분에 포트폴리오는 화려한데 CS 기초가 약한 지원자가 많다. 스택과 큐의 차이, DNS, HTTP와 HTTPS, 논블로킹 호출, 비밀번호 저장 방식 같은 질문에 답할 수 있어야 한다. 지름길은 없다. rand()는 어떻게 무작위 수를 만들까, 해시맵은 메모리에 어떻게 저장될까, React를 처음부터 만들면 어떨까처럼 평소에 궁금해하고 찾아보는 습관이 기본기를 만든다.

어떻게 공부할까

방법	장점	주의할 점
클론코딩	재미있고 포트폴리오가 된다	강의 코드를 그대로 따라 친 결과물은 면접 질문에서 바로 드러난다
토이·사이드 프로젝트	기획부터 운영까지 겪으며 내가 좋아하는 분야를 알게 된다	팀보다 혼자 작게 시작해야 흐지부지되지 않는다
스터디	어려운 내용을 빨리 익히고 자극을 받는다	주제·책을 정하고, 공동 정리와 발표 순서를 정해야 굴러간다
온라인 강의	빠른 입문	핵심 위주라 깊이가 부족하다. 감을 잡은 뒤 공식 문서와 책으로 넘어간다
컨퍼런스	실무 고민과 최신 흐름	지금 고민과 관련된 세션만 고른다. 다시보기는 잘 안 보게 되니 가능하면 라이브로
책	깊이와 태도	추천 목록은 개발 분야별 추천 도서 참고
유튜브·팟캐스트·트위터	이동 중에, 빠르게	흐름을 아는 용도. 깊은 공부를 대신하지 않는다

클론코딩을 내 것으로 만들기

모방으로 끝나면 의미가 없다. 강의 코드를 따라 치든 AI 도구가 생성하든, 설명하지 못하는 코드는 내 실력으로 인정받지 못한다. 두 가지를 더한다.

만들면서 배운 점, 막힌 점, 해결한 방법을 정리한다.
원본에 없는 기능을 하나 이상 붙인다. 이미지 리사이즈, 영상을 GIF로 변환, OpenGraph 이미지 생성처럼 작아도 된다.

사이드 프로젝트를 시작하고 이어 가는 요령은 사이드 프로젝트 10가지 팁에 따로 정리했다.

한 일을 드러낸다

면접관은 속사정을 모른다. 보이는 것으로 평가한다. 학력과 경력은 바꾸기 어렵지만 프로젝트, 블로그, 오픈소스는 노력으로 차별화할 수 있다.

항목	평범한 이력서	눈에 띄는 이력서
프로젝트	TODO 앱, React+Redux	같은 TODO 앱을 직접 배포하고 개인 도메인을 연결, 마감 임박 시 웹 푸시 알림
블로그	개념 정리 몇 편	왜, 어떻게를 담은 과정 중심 글을 꾸준히
오픈소스	없음	쓰던 라이브러리의 이슈를 고친 경험

첫 번째 지원자도 배포와 도메인 연결은 할 줄 알았다. 드러내지 않았을 뿐이다.

포트폴리오: 면접관이 코드로 확인하는 것

기술 면접은 포트폴리오 저장소의 코드를 열어 놓고 묻는 경우가 많다. 권장 방식에서 벗어난 코드, 설명 없는 복잡한 코드, 비효율적인 코드가 그대로 질문이 된다. 신입이면 이런 프로젝트 3편 안팎이 보통이고, 팀 프로젝트일수록 자세히 쓴다.

평가 축	높게 보는 것	준비
직무 관련성	지원 직무의 몫. 프론트엔드 지원자의 백엔드 코드, 백엔드 지원자의 화면은 가산점일 뿐 본 평가가 아니다. PM 지원이면 문서화·시각화와 계획대로 진행됐는지를 본다	내가 맡은 부분이 어디인지 README에 분명히 쓴다
실무 관련성	커머스·소셜·대시보드처럼 실제 업무와 닮은 도메인. 실사용자 피드백을 반영했거나 트래픽이 있는 프로젝트	사용자 수, 받은 피드백과 고친 내용을 남긴다
기술적 도전	성능 최적화, 보안, 접근성처럼 기본 구현 너머의 문제를 푼 흔적	문제·원인·해결을 README의 이슈 항목에 기록한다
기술 선택의 이유	장단점을 알고 골랐는가. 작은 프로젝트에 Redux를 쓰면 「Context나 Zustand는 검토했나」가 단골 질문이다	후보와 비교 기준, 고른 이유를 한두 줄씩 적는다(리액트 상태 관리)
코드 품질	이름·스타일의 일관성, 모듈 분리, 메모이제이션·지연 로딩·이미지 최적화, 테스트	포매터·린터를 저장 시 자동 실행하고 테스트를 CI에 붙인다
화면 완성도	일관된 레이아웃과 피드백, 절제된 애니메이션. 반응형은 모든 서비스의 필수가 아니다. 페르소나가 쓰는 기기를 기준으로 대응 범위를 정한다	반응형을 하지 않았다면 그 이유도 쓴다

README에는 개요, 설치·실행 방법, 주요 기능, 기술 스택과 선택 이유, 디렉터리 구조와 주요 파일의 역할, 이슈와 해결 기록을 넣는다. README 일반의 구성은 소프트웨어 문서화에 있다.

기록의 깊이

블로그는 성장 과정을 보여 주는 도구다. 글의 가치는 깊이에 따라 다르다.

링크만 모아 둠          ─ 가치 없음
공부한 내용 정리         ─ 조금
한 주제를 깊게 파고 장단점·사용기까지 ─ 높음
여러 기술을 조합해 만든 결과 정리     ─ 가장 높음

글이 몇 편 없는 블로그는 이력서에 적지 않는 편이 낫다. 블로그는 꾸준히 쌓인 기록일 때 성장 과정을 보여 준다.

그 밖에 좋은 질문을 하는 법을 익히고, 주간·월간 목표를 적당히 잡아 기록하고 회고하며, 지치면 환경을 바꿔 본다.

피해야 할 회사

개발 문화가 없는 회사(버전 관리·테스트·코드 리뷰가 없고 실수를 개인 탓으로 돌리는 곳)는 성장을 막는다. 면접에서 가려내는 신호는 면접 잘 보는 법에 있다.

정리

분야는 하나를 깊게, 나머지는 협업할 만큼만.
로드맵의 중요도 표시대로 깊이를 나눈다. 넓고 얕은 것보다 좁고 깊은 것이 낫다.
클론코딩은 기록과 기능 추가로 내 것으로 만든다. 사이드 프로젝트는 혼자 작게.
배포, 도메인, 블로그, 오픈소스처럼 한 일을 보이게 만든다.
지금 실력보다 계속 성장하고 있다는 사실이 중요하다.

버그 제보