채용 공고를 찾아보면 반복되는 문구가 있다. ‘경력직 우대’, ‘실무 경험 보유자’, ‘즉시 투입 가능한 분’. 개발 직군 채용에서 경력직 중심 구인이 늘고 있다는 이야기는 구직자들 사이에서 자주 회자된다. 이것이 얼마나 정확한 수치인지 단정하기는 어렵지만, 채용 공고를 직접 살펴보면 신입 TO가 경력직 포지션보다 눈에 띄게 적다는 것을 체감하는 데는 오랜 시간이 걸리지 않는다. 그렇다고 신입에게 문이 닫혀 있다는 의미는 아니다. 문제는 어떻게 들어가느냐다. 이 글에서는 공식적인 취업 이력이 없는 신입이 채용 담당자 앞에서 ‘준경력’을 설득력 있게 증명하는 방법을 구체적으로 다룬다.
채용 담당자가 경력직을 선호하는 진짜 이유
채용 담당자가 경력직을 선호하는 데는 명확한 이유가 있다. 온보딩 비용이 적고, 결과물 예측이 가능하며, 실무 투입까지 걸리는 시간이 짧다. 반면 신입에게는 반대의 우려가 따른다. 학습 곡선이 얼마나 될지, 팀 협업에 얼마나 빠르게 적응할지, 코드 품질과 일정 감각이 어느 수준인지를 이력서만으로는 가늠하기 어렵다.
중요한 것은 이 우려가 ‘신입이기 때문에 안 된다’는 판단이 아니라는 점이다. 채용 담당자가 묻는 것은 “이 사람이 실무에서 어떻게 행동할 것인가”다. 그 질문에 포트폴리오와 경험으로 답할 수 있다면, 연차 부족은 극복 가능한 조건이 된다.
‘준경력’은 무엇으로 만들어지는가
준경력은 공식 취업 이력이 없어도 실무에 가까운 경험과 결과물을 갖춘 상태를 말한다. 흔히 인턴 경험만을 준경력으로 오해하지만, 범위는 훨씬 넓다. 핵심은 세 가지다. 실제 문제를 풀었는가, 그 과정에서 협업이 있었는가, 결과물이 외부에 공개되거나 사용된 적 있는가.
토이 프로젝트와 준경력을 구분하는 기준도 여기서 나온다. “기술을 배우기 위해 만든 것”과 “실제 필요나 사용자를 전제로 만들고 운영한 것”은 채용 담당자에게 다르게 읽힌다. 같은 TODO 앱이라도 “튜토리얼 따라 만들었다”와 “팀원 4명이 실제로 쓰기 위해 만들고, 피드백을 받아 3번 수정했다”는 차원이 다른 이야기다.
준경력을 만드는 실천 경로 4가지
아래는 신입이 현실적으로 접근할 수 있는 준경력 축적 방법이다. 모든 것을 다 할 필요는 없다. 자신의 현재 상황에 맞는 것 하나를 먼저 선택하는 것이 출발점이다.
- 오픈소스 기여: GitHub에서 자신이 쓰는 라이브러리나 도구의 이슈 탭을 열어본다. ‘good first issue’ 태그가 붙은 항목부터 시작하면 된다. 문서 오류 수정이나 작은 버그 픽스라도, PR을 올리고 리뷰어와 소통한 뒤 머지된 기록은 실무 협업 감각을 증명하는 실질적인 근거가 된다.
- 실사용 목적의 팀 프로젝트: 부트캠프, 학교 동기, 온라인 스터디에서 2~4명이 함께 실제 배포까지 진행한 프로젝트. 기획부터 운영까지 역할을 나눠 진행하고 사용자 피드백이 있다면, 이것은 이미 준경력으로 서술 가능한 경험이다.
- 인턴십 및 단기 계약: 규모가 작은 스타트업, 에이전시, 프리랜서 의뢰 등 단기 참여도 충분히 경력 서술의 대상이 된다. 기간보다 맡은 역할과 기여 내용이 중요하다. 3개월이라도 실제 서비스에 코드를 올렸다면 그것은 경험이다.
- 사이드 프로젝트 공개 운영: 작은 SaaS 툴, 크롬 익스텐션, 개인 블로그 플랫폼 등 실제 사용자가 있는 서비스를 만들어 운영한다. DAU가 적어도 괜찮다. 실제 사용자의 피드백을 받아 개선한 이력이 있다면 그 자체가 제품 감각을 설명하는 근거가 된다.
포트폴리오와 이력서에서 준경력을 설득력 있게 서술하는 법
경험이 있어도 서술이 약하면 전달이 안 된다. 신입 포트폴리오에서 가장 흔한 실수는 기술 스택 나열에 그치는 것이다. “React, TypeScript, Spring Boot 사용”이라고 적는 것과 “상품 검색 응답 지연 문제를 API 캐싱 레이어 도입으로 개선하고, 이 과정에서 Redis를 직접 학습해 적용했다”고 적는 것은 읽히는 방식이 전혀 다르다.
포트폴리오 항목 하나를 쓸 때는 아래 세 가지를 반드시 포함한다.
- 문제 정의: 왜 이 프로젝트를 만들었는가. 어떤 불편함이나 필요가 있었는가.
- 내가 기여한 것: 팀 프로젝트라면 내가 구체적으로 맡은 부분. ‘프론트엔드 전반’보다 ‘검색 자동완성 컴포넌트 구현 및 API 연동’처럼 좁혀야 한다.
- 결과와 배운 점: 수치가 있으면 좋고 없으면 정성적 결과와 기술적으로 얻은 깨달음으로 대체한다. 중요한 것은 “그래서 어떻게 됐는가”가 빠지지 않는 것이다.
이력서에서는 ‘프로젝트 기간’보다 ‘성과와 역할’이 먼저 보여야 한다. 기간이 짧다고 주눅들 필요 없다. 채용 담당자는 기간보다 그 기간 안에 무엇을 했는지를 보고 판단한다.
추상적인 태도 서술도 정리해야 한다. “열심히 배우겠습니다”, “성실하게 임하겠습니다” 같은 표현은 정보 밀도가 없다. 모든 지원자가 비슷하게 쓰기 때문에 눈에 띄지 않으며, 오히려 경험 부재를 드러내는 신호로 읽힐 수 있다. 대신 “5인 팀 프로젝트에서 프론트엔드를 전담하며 API 연동 과정의 CORS 오류를 직접 디버깅해 해결했다”처럼 맥락과 행동, 결과가 보이는 문장으로 교체한다.
면접에서 준경력을 말하는 방식
포트폴리오를 잘 만들었어도 면접에서 제대로 전달하지 못하면 의미가 줄어든다. 신입이 면접에서 자주 하는 실수 두 가지가 있다. 하나는 기술을 열거하는 것이고, 다른 하나는 어려웠다고만 말하고 어떻게 해결했는지를 빠뜨리는 것이다.
면접관이 듣고 싶은 것은 “이 사람이 실제 문제 앞에서 어떻게 생각하고 행동하는가”다. 그래서 각 경험을 아래 구조로 정리해두면 면접 질문의 방향이 어디로 흐르더라도 유연하게 대응할 수 있다.
- 상황: 어떤 맥락에서 이 일을 했는가.
- 과제: 내가 해결해야 했던 문제나 목표는 무엇이었는가.
- 행동: 구체적으로 무엇을, 어떻게, 왜 그 방법으로 했는가.
- 결과: 어떤 결과가 나왔는가. 다음에 다르게 할 부분이 있다면 무엇인가.
기술 면접에서는 모르는 부분을 다루는 방식도 중요하다. “모르겠습니다”로 끝내는 것과 “그 부분은 깊이 다뤄보지 않았는데, 제가 이해하는 범위에서는 이렇게 작동하는 것으로 알고 있고, 실무에서라면 이렇게 접근할 것 같습니다”라고 말하는 것은 전혀 다른 인상을 남긴다. 완벽한 지식보다 생각의 흐름을 보여주는 것이 경쟁력이다.
자신이 작업한 코드에 대해서는 방어적으로 설명할 준비도 필요하다. “왜 이 구조를 선택했는가”, “다른 방법은 없었는가”, “지금 다시 만든다면 무엇을 바꾸겠는가”라는 질문에 자신의 언어로 답할 수 있을 때 준경력자의 인상이 만들어진다.
실전 감각을 빠르게 보완하는 방법
혼자 공부할 때 가장 놓치기 쉬운 것은 ‘실무 감각’이다. 어떤 코드가 현장에서 좋은 코드로 평가받는지, 어떤 이력서 표현이 실제로 채용 담당자의 시선을 끄는지, 어떤 질문이 면접에서 실제로 나오는지는 공부만으로는 파악하기 어렵다. 이 간극을 메우는 데 현직자와의 대화가 가장 효과적이다.
멘토를 찾기 어렵다면 커뮤니티를 활용하는 것이 현실적인 대안이다. 현직 개발자들이 활동하는 스터디 그룹, 코드 리뷰 커뮤니티, 커리어 관련 채널에 꾸준히 참여하다 보면 자연스럽게 실무 언어와 판단 기준을 흡수하게 된다. 단순히 정보를 얻는 것에 그치지 않고, 직접 코드 리뷰를 요청하거나 이력서 피드백을 구하는 적극적인 태도가 필요하다.