솔직히 말씀드리면, 저는 처음에 공부법보다 공부량이 중요하다고 믿었습니다. 유명한 강의를 끝까지 들으면 어느 순간 실력이 따라올 거라고 생각했습니다. 그런데 강의를 수십 시간 들은 뒤 막상 빈 에디터 앞에 앉으니 손이 움직이지 않았습니다. 그때 처음으로 내가 공부를 잘 못하고 있는 건 아닐까 라는 의문이 들었습니다.
개발자 취업 공부 방법 - 나에게 맞는 학습 성향부터 확인해야 한다
강의를 많이 들을수록 실력이 는다고 생각하는 분들도 있는데, 제가 직접 겪어보니 강의 시청 시간과 구현 능력은 생각보다 별개였습니다. 강의에서는 이해가 됐는데, 막상 혼자서 로그인 기능 하나를 만들려고 하면 어디서부터 시작해야 할지 몰랐습니다.
개발 학습에서 먼저 파악해야 할 것은 자신의 학습 양식(Learning Style)입니다. 학습 양식이란 개인이 정보를 가장 효과적으로 받아들이고 처리하는 방식을 뜻합니다. 강의를 들으며 개념이 잡히는 사람이 있는가 하면, 직접 코드를 작성해 봐야 이해되는 사람도 있고, 블로그나 노트에 개념을 글로 풀어써야 비로소 머릿속에 정리되는 사람도 있습니다.
교육심리학에서는 이를 크게 청각형, 시각형, 읽기·쓰기형, 체험형으로 분류합니다(출처: 한국교육개발원). 개발 공부에 적용해 보면, 강의 위주로 배우는 방식이 잘 맞는 사람이 있고, 실습 중심으로 바로 만들어보는 방식이 더 효과적인 사람이 있습니다.
제 경험상 이건 좀 다릅니다. 처음에는 강의를 들으면 자연스럽게 따라가면 되지 않나라고 생각했지만, 실제로는 강의를 듣고 바로 작은 기능을 직접 만들어봐야 개념이 제대로 붙었습니다. 강의만 20시간 들은 것보다, 강의 2시간 듣고 기능 하나 직접 구현해 보는 게 저한테는 훨씬 남았습니다.
좋은 학습법이라고 알려진 방식을 정리하면 보통 세 가지 요소가 들어갑니다.
- 인풋(Input): 강의, 책, 문서 등으로 개념을 받아들이는 과정
- 아웃풋(Output): 직접 코드를 작성하고 기능을 구현하는 실습 과정
- 회고(Retrospective): 무엇을 배웠고 어디서 막혔는지 글이나 노트로 정리하는 과정
이 세 가지가 어느 정도 균형을 이룰 때 학습이 실제 역량으로 전환됩니다. 인풋만 반복하면 지식은 있는데 구현을 못하고, 아웃풋만 하면 왜 되는지 모르는 채로 진행되기 쉽습니다. 제가 직접 써봤는데, 회고 없이 계속 새로운 걸 배우기만 하면 나중에 면접에서 이걸 왜 이렇게 구현하셨나요?라는 질문에 제대로 답하기가 어렵습니다.
목표 직무 설계와 실습 검증이 공부 방향을 만든다
학습 성향을 파악했다면 다음은 목표 직무를 정하는 일입니다. 다양한 분야를 조금씩 공부하다 보면 방향이 잡힌다 라는 의견도 있지만, 실제로 써보니 직무를 정하지 않으면 공부가 매우 쉽게 흔들렸습니다. 저는 프런트엔드와 백엔드 사이에서 수개월을 오가다가 시간을 낭비한 경험이 있습니다.
직무별로 필요한 기술 스택(Tech Stack)이 다릅니다. 기술 스택이란 하나의 서비스나 기능을 만드는 데 사용되는 언어, 프레임워크, 도구의 조합을 뜻합니다. 프런트엔드라면 HTML, CSS, JavaScript, React 같은 기술 스택이 핵심이 되고, 백엔드라면 서버 언어, 데이터베이스, REST API, 인증 처리 같은 영역이 우선순위에 놓입니다.
고용노동부가 발표한 직종별 채용 공고 분석에 따르면, 신입 개발자 채용 시 포트폴리오와 실무 경험을 가장 중요한 평가 기준으로 삼는 기업이 전체의 70% 이상을 차지합니다(출처: 고용노동부). 이는 자격증이나 강의 수료 이력보다 실제로 만든 것이 더 중요하다는 의미입니다.
그래서 방향을 정한 다음에는 반드시 작은 결과물을 만들어보는 과정이 필요합니다. 솔직히 이건 예상 밖이었습니다. 처음에는 나중에 크고 완성도 높은 프로젝트를 만들어야지라고 생각했는데, 실제로는 작은 기능 하나를 처음부터 끝까지 직접 완성해 보는 것이 훨씬 더 많이 남았습니다.
예를 들어 프런트엔드를 준비한다면 자기소개 페이지, 할 일 목록, 영화 검색 페이지처럼 규모가 작은 프로젝트를 먼저 완성해 보는 게 유용합니다. 이 과정에서 DOM 조작(Document Object Model 조작, 쉽게 말해 웹 페이지의 요소를 JavaScript로 직접 제어하는 방식)이나 비동기 처리(Async Processing, 서버에 데이터를 요청하고 응답을 기다리는 동안 다른 작업을 병렬로 처리하는 방식) 같은 개념이 실제 코드 안에서 어떻게 작동하는지 몸으로 익히게 됩니다.
막히는 순간도 중요한 정보입니다. 강의를 듣고 바로 실습하면 빨리 이해된다면 인풋-아웃풋 루틴이 잘 맞는 것이고, 오류를 기록하고 복습해야 기억에 남는다면 회고 시간을 더 확보해야 합니다. 제 경험상 이건 직접 만들어보기 전까지는 절대 알 수 없었습니다. 머릿속으로 나는 어떤 스타일이지?라고 생각해 봐야 답이 나오지 않았습니다.
결국 자신에게 맞는 공부법은 완성형으로 존재하지 않습니다. 공부하면서 막히고, 원인을 분석하고, 방식을 조정하는 과정 자체가 학습법을 만들어가는 일입니다. 저는 지금도 새로운 기술을 배울 때마다 어떤 방식이 더 잘 맞는지 조금씩 달라진다는 걸 느끼고 있습니다. 남의 공부법을 그대로 따라가기보다, 내 속도와 목표 직무에 맞게 계속 조정하는 것이 결국 가장 현실적인 방법이라고 생각합니다.
피드백을 받아보면 나에게 부족한 부분이 더 잘 보인다
혼자 공부하다 보면 내가 잘하고 있는지 판단하기 어렵습니다. 코드가 일단 동작하면 괜찮다고 생각할 수 있지만, 실제로는 구조가 복잡하거나 설명이 부족하거나 포트폴리오 방향이 흐릴 수 있습니다. 이럴 때는 외부 피드백이 도움을 받는 것이 좋습니다. 스터디, 멘토링, 개발 커뮤니티, 코드 리뷰, 이력서 피드백 등을 활용하면 내가 놓친 부분을 더 빨리 알 수 있습니다.
예를 들어 프로젝트 README를 작성했는데, 다른 사람이 봤을 때 실행 방법이 이해되지 않을 수 있으며, 면접 답변을 준비했지만, 본인 역할과 문제 해결 과정이 잘 드러나지 않을 수도 있습니다. 코드는 동작하지만 같은 로직이 반복되어 유지보수가 어려울 수도 있습니다. 피드백을 받으면 학습법도 조정할 수 있으며, 개념 설명이 부족하다는 피드백을 받았다면 블로그 정리나 말로 설명하는 연습이 필요합니다.
구현 경험이 부족하다는 말을 들었다면 강의보다 프로젝트 시간을 늘려야 합니다. 좋은 학습법은 혼자만의 기준으로 완성되지 않습니다. 나에게 맞는 방식으로 공부하되, 외부 기준을 통해 부족한 부분을 점검하는 과정이 필요합니다.
정리하면 자신에게 맞는 학습법을 찾는 방법은 다음과 같습니다.
- 내가 어떤 방식으로 이해가 잘 되는지 확인합니다.
- 강의, 실습, 기록의 균형을 맞춥니다.
- 목표 직무에 맞는 학습 순서를 정합니다.
- 작은 결과물을 만들며 공부 방식을 점검합니다.
- 공부가 막힐 때 원인을 구분합니다.
- 피드백을 통해 부족한 부분을 확인합니다.
개발자 취업 준비는 남의 공부법을 그대로 따라 하는 과정이 아닙니다. 나에게 맞는 방식으로 배우고, 직접 만들어보고, 기록하고, 부족한 부분을 계속 조정하는 과정으로 결국 좋은 학습법은 처음부터 완성되어 있는 것이 아니라, 공부하면서 찾아가고 수정해 가는 것입니다.