공부를 열심히 하고 있는데 왜 실력이 쌓이는 느낌이 없을까요? 저도 같은 질문을 한참 동안 스스로에게 던졌습니다. 알고 보니 문제는 의지가 아니라 방향이었습니다. IT 취업 준비에서 방향성을 잃는 건 누구에게나 생기는 일이고, 중요한 건 다시 잡는 기준을 갖는 것입니다.
IT 취업 준비 중 방향성을 잃었을 때 - 목표 직무 없이 공부하면 어디서도 깊어지지 않습니다
저는 처음에 "개발자가 되겠다"는 말 하나만 들고 공부를 시작했습니다. 그 결과가 어땠냐면, 자바도 조금, 파이썬도 조금, React 강의도 조금씩 손댔지만 어느 것 하나 제대로 쌓이지 않았습니다. 솔직히 이건 예상 밖이었습니다. 많이 배울수록 더 잘 알게 될 거라고 생각했거든요.
IT 직무는 실제로 하는 일이 완전히 다릅니다. 프런트엔드 개발자는 사용자 인터페이스(UI), 즉 사용자가 눈으로 보고 직접 조작하는 화면 영역을 담당합니다. 반면 백엔드 개발자는 REST API 설계와 데이터베이스 연동, 인증 로직 같은 서버 내부 구조를 만드는 역할을 합니다. 여기서 REST API란 프런트엔드와 백엔드가 데이터를 주고받는 통신 규칙을 의미하는데, 쉽게 말해 두 시스템이 대화하는 방식을 정해놓은 약속입니다.
데이터 분석가는 또 다릅니다. SQL로 데이터를 추출하고, 전처리 과정을 거쳐 지표를 설정한 뒤 시각화 결과를 리포트로 만드는 흐름이 핵심입니다. 클라우드 엔지니어라면 AWS 같은 클라우드 플랫폼에서 서버를 배포하고 네트워크를 설정하는 인프라 운영 경험이 더 중요해집니다.
직무가 이렇게 다르기 때문에, 목표 직무가 없는 상태에서는 공부할수록 오히려 어디로 가야 할지 더 혼란스러워집니다. 저도 그 상태가 꽤 길었습니다. 방향성을 잃었다면 가장 먼저 "나는 어떤 문제를 해결하는 역할을 하고 싶은가"를 다시 물어봐야 합니다.
채용공고는 공부 방향을 잡는 가장 정직한 나침반입니다
목표 직무를 잡은 뒤에도 흔들릴 때가 있습니다. 주변에서 "요즘 TypeScript가 대세다", "클라우드 자격증이 있어야 한다"는 말을 들을 때마다 계획이 바뀌기 시작했습니다. 제가 직접 겪어보니, 이럴 때 가장 현실적인 기준은 채용공고였습니다.
채용공고에는 기업이 실제로 원하는 기술 스택이 적혀 있습니다. 기술 스택이란 서비스를 만들기 위해 사용하는 기술들의 조합을 말합니다. 예를 들어 "Java, Spring Boot, MySQL, Git" 같은 식으로 묶인 것들이 기술 스택입니다. 비슷한 직무 공고 10개만 모아봐도 어떤 기술이 반복적으로 등장하는지 금방 보입니다.
실제로 국내 채용 시장에서 신입 백엔드 직무는 Java와 Spring 프레임워크 조합을 가장 많이 요구하고, 프런트엔드 직무에서는 JavaScript와 React가 꾸준히 반복됩니다(출처: 사람인 채용트렌드 리포트). 이런 반복 키워드를 정리해 두면, 내가 지금 배우는 기술이 공고와 맞는지 바로 비교할 수 있습니다.
채용공고를 볼 때 확인해야 할 핵심 항목은 다음과 같습니다.
- 우대 기술보다 필수 기술 항목을 먼저 본다
- 비슷한 직무 공고 10개 이상을 모아서 반복 키워드를 찾는다
- 요구 경험 항목에서 프로젝트 구현 범위를 확인한다
- 협업 도구(Git, Jira, Notion 등) 언급 여부도 체크한다
방향이 흔들릴 때마다 더 많은 강의를 찾기보다 공고를 먼저 보는 습관이 생기고 나서, 공부에 쓸데없는 힘을 많이 빼지 않게 됐습니다.
포트폴리오는 크기보다 직무와의 연결이 더 중요합니다
IT 취업 준비에서 프로젝트는 중요합니다. 하지만 프로젝트를 했다는 사실보다 중요한 것은 그 프로젝트가 목표 직무와 연결되어 있는지입니다.
"프로젝트를 했다"는 사실 자체가 포트폴리오가 되지는 않습니다. 제가 처음 만든 프로젝트는 투두리스트 웹앱이었는데, 나중에 돌아보니 그게 백엔드 직무를 준비하는 저한테 어떤 역량을 보여주는지 설명하기가 어려웠습니다. 기능은 돌아갔지만, 서버 구조도 없고 데이터베이스 연동도 없었거든요.
포트폴리오에서 중요한 건 ERD(Entity-Relationship Diagram)입니다. ERD란 데이터베이스의 테이블 구조와 테이블 간 관계를 시각적으로 표현한 설계도입니다. 백엔드 직무를 준비한다면 포트폴리오 안에 ERD와 API 명세서가 있어야 면접관 입장에서 데이터 설계 능력을 확인할 수 있습니다.
데이터 분석 직무라면 프로젝트 안에 문제 정의, 데이터 전처리, 지표 설정, 시각화, 인사이트 도출 과정이 순서대로 정리되어 있어야 합니다. 클라우드나 인프라 직무라면 서버 배포 과정과 장애 대응 기록이 더 설득력 있는 자료가 됩니다.
규모가 작아도 괜찮습니다. 제 경험상 이건 좀 다릅니다. 작은 프로젝트라도 내가 어떤 역할을 맡았는지, 어떤 문제를 만났고 어떻게 해결했는지 설명할 수 있다면, 그게 면접에서 훨씬 더 강한 인상을 남깁니다. 반대로 팀 프로젝트 규모가 크더라도 내 역할이 불분명하고 직무와 연결고리가 없다면 설득력이 약해집니다.
기본기와 기록이 없으면 공부 시간이 증발합니다
마지막으로 제가 가장 늦게 깨달은 부분입니다. 강의를 수십 시간 들어도 기록이 없으면 나중에 면접 준비를 할 때 거의 기억이 없습니다. 어떤 오류를 해결했는지, 어떤 개념을 어떻게 이해했는지 사라져 버립니다.
기본 개념을 내 말로 설명할 수 있는지가 실력의 척도입니다. 예를 들어 "HTTP(HyperText Transfer Protocol)"를 썼다면, HTTP란 클라이언트와 서버가 데이터를 주고받는 통신 규약으로 요청(Request)과 응답(Response) 구조로 작동한다는 것을 설명할 수 있어야 합니다. "Git을 사용했습니다"에서 멈추는 것이 아니라, 브랜치 전략이나 코드 충돌(Conflict)을 어떻게 해결했는지까지 말할 수 있어야 합니다.
고용노동부 직업훈련 포털 통계에 따르면, IT 관련 훈련 이수자 중 취업으로 이어지는 비율은 수료 후 6개월 이내에 자기소개서와 포트폴리오를 정비한 경우에서 유의미하게 높게 나타났습니다(출처: 고용노동부 HRD-Net). 공부하면서 동시에 기록을 쌓아야 한다는 것이 숫자로도 확인됩니다.
GitHub README에 프로젝트 목적과 기술 스택을 정리하고, 블로그에 오류 해결 과정을 남기는 것은 단순한 메모가 아닙니다. 그것이 이력서와 면접 답변의 재료가 됩니다. 제가 직접 써봤는데, 블로그 글 한 편이 면접에서 실제로 이야기로 이어진 적이 여러 번 있었습니다.
방향성이 흔들릴 때 새로운 강의를 찾는 건 문제를 해결하지 않습니다. 목표 직무를 다시 확인하고, 채용공고와 비교하고, 프로젝트가 그 직무와 연결되는지 점검하고, 기본 개념을 설명할 수 있는지 확인하는 순서로 돌아오는 것이 더 빠릅니다. 저도 여러 번 이 기준으로 방향을 다시 잡았고, 그때마다 공부가 조금씩 더 선명해졌습니다. 흔들리는 건 자연스러운 일이고, 돌아오는 기준이 있으면 충분합니다.