채용 공고를 열면 ‘경력 2년 이상’이라는 조건이 당연하다는 듯 붙어 있다. 실제로 많은 기업이 개발자 채용의 절반 이상을 경력직으로 채우고 있다는 이야기는 구직 커뮤니티에서 자주 회자된다. 신입 개발자 입장에서는 ‘경험을 쌓으려면 취업이 필요하고, 취업하려면 경험이 필요하다’는 이중 구속에 빠진 것 같은 느낌을 받기 쉽다. 그러나 이 장벽을 넘은 신입들은 분명히 존재한다. 그들이 어떤 방식으로 채용 시장의 논리를 이해하고, 어떤 준비로 경력직 우선 구조를 우회했는지를 살펴보면 구체적인 실마리가 보인다.
왜 기업은 신입보다 경력직을 선호하는가
채용 담당자 입장에서 경력직은 리스크를 줄이는 선택이다. 온보딩 기간이 짧고, 실제 서비스 환경에서 발생하는 문제를 혼자 해결한 이력이 있으며, 팀과 협업한 경험이 검증된 사람이다. 반면 신입은 그 모든 것을 ‘앞으로 보여줄 사람’이다. 회사가 신입을 뽑기 위해 투자해야 하는 교육 비용과 시간은 작지 않다.
특히 중소기업이나 스타트업에서는 팀 규모가 작아 한 명의 개발자가 빠르게 기여할 것을 기대한다. 멘토링 여력이 없는 조직일수록 신입보다 바로 실전에 투입할 수 있는 경력자를 더 원한다. 이 구조를 탓할 수는 없다. 하지만 이 구조를 이해하면, 신입으로서 어디에 에너지를 집중해야 하는지가 선명해진다.
결국 핵심은 ‘왜 신입을 뽑아야 하는가’에 대한 답을 채용 담당자에게 내 스스로 제시하는 것이다. 그 답은 학점이나 수료증이 아니라, 실제로 무언가를 만들고 운영하고 개선한 흔적이어야 한다.
포트폴리오는 ‘무엇을 만들었나’가 아니라 ‘어떻게 생각하는가’를 보여줘야 한다
많은 신입 개발자가 포트폴리오를 ‘결과물 나열’로 이해한다. 투두 앱, 쇼핑몰 클론, 날씨 앱. 기능이 동작하면 충분하다고 생각한다. 하지만 채용 담당자가 포트폴리오에서 보려는 것은 완성된 화면이 아니라 개발자의 사고방식이다.
좋은 포트폴리오는 ‘이 기능을 왜 이렇게 구현했는지’를 설명한다. 예를 들어 무한 스크롤을 구현할 때 Intersection Observer API를 선택한 이유, 기존에 시도했던 방식에서 발생한 문제, 그 문제를 어떻게 분석하고 해결했는지를 README나 개발 블로그에 정리해두면 단순한 기능 구현과 차별화된다. 선택의 맥락이 있는 코드는 없는 코드보다 훨씬 강력한 인상을 남긴다.
또한 포트폴리오 프로젝트에서 실제 사용자가 생겼거나, 배포 후 피드백을 반영해 개선한 이력이 있다면 그것을 명시하는 것이 좋다. ‘사용자 3명’이어도 괜찮다. 실제 운영의 경험은 토이 프로젝트와 질적으로 다르다.
신입이 진입하기 좋은 조직을 선별하는 법
모든 기업이 신입에게 닫혀 있는 것은 아니다. 신입을 정기적으로 채용하는 기업, 개발자 양성 프로그램을 운영하는 기업, 또는 빠르게 성장 중이어서 팀을 확충해야 하는 기업은 신입에게 상대적으로 열려 있다. 이런 기업을 식별하는 몇 가지 단서가 있다.
- 채용 공고에 ‘우대사항’과 ‘필수사항’이 명확히 구분되어 있는가. 경력이 ‘우대’에만 명시되어 있다면 신입도 지원 가능한 포지션이다.
- 기술 블로그나 오픈소스 기여가 활발한가. 조직 문화가 성장과 공유를 중시하는 기업은 신입에게도 학습 기회를 제공하는 경향이 있다.
- 인턴십이나 수습 과정이 명시되어 있는가. 채용 과정에 온보딩이 설계되어 있다는 것은 신입을 수용할 준비가 된 조직이라는 신호다.
- 팀 구성에 시니어 개발자가 있는가. 채용 공고나 LinkedIn에서 팀 멤버를 확인하면 멘토링 가능한 구조인지 짐작할 수 있다.
반대로, 신입이 지원하기 어려운 조직도 있다. 소수 정예 팀에서 즉시 성과를 내야 하는 조직, 채용 공고가 전부 ‘경력 3년 이상’으로 명시된 곳은 현재 단계에서 소모적인 지원이 될 가능성이 높다. 전략적으로 에너지를 집중하는 것이 중요하다.
기술 인터뷰에서 신입이 갖출 수 있는 강점
경력이 없다는 것이 인터뷰에서 약점이 되는 건 사실이다. 하지만 신입이 오히려 경쟁력을 가질 수 있는 영역도 분명히 있다. 최신 기술 트렌드에 대한 민감도, 최근 학습한 내용을 구조적으로 설명하는 능력, 그리고 무엇보다 ‘배우려는 태도’가 그것이다.
인터뷰 준비에서 신입이 가장 놓치기 쉬운 것은 자신이 ‘모르는 것’에 대한 대처 방식이다. 모른다고 침묵하거나 억지로 아는 척하면 신뢰를 잃는다. 오히려 “그 부분은 직접 사용해보지 않았지만, 공식 문서 기준으로 이렇게 동작하는 걸로 알고 있습니다. 실제 적용 시에는 이런 부분을 먼저 확인해보겠습니다”라고 말하는 것이 성실하고 신중한 개발자라는 인상을 줄 수 있다.
코딩 테스트 준비는 알고리즘 단기 암기가 아니라 문제 해결 과정을 설명하는 연습을 포함해야 한다. 라이브 코딩이나 화이트보드 인터뷰에서 ‘어떤 순서로 생각하는지’를 말로 표현할 수 있는 개발자는 아직도 드물다. 이 부분이 차별화 포인트가 될 수 있다.
실무 경험 없이 실무 경험을 만드는 방법
채용 시장이 경력을 요구한다면, 경력에 준하는 경험을 만드는 것이 현실적인 대안이다. 몇 가지 방법이 실제로 효과가 있다고 알려져 있다.
오픈소스 기여는 진입 장벽이 낮아지고 있다. 직접 핵심 기능을 개발하지 않아도 문서 개선, 버그 리포트, 작은 이슈 해결부터 시작할 수 있다. 기여 이력이 GitHub에 남고, 해당 프로젝트 메인테이너와 커뮤니케이션한 기록이 생긴다. 이는 ‘혼자서만 코딩했다’와는 다른 맥락의 경험이다.
프리랜서 소규모 프로젝트도 고려할 만하다. 지인의 쇼핑몰 랜딩 페이지, 소상공인 예약 시스템, 동아리 웹사이트 등 규모가 작더라도 실제 의뢰인이 있고 요구사항이 있는 프로젝트는 실무 감각을 키워준다. 완성 후 운영하며 발생하는 문제를 해결하는 경험은 포트폴리오에 구체적인 이야기를 더해준다.
사이드 프로젝트를 팀으로 진행하는 것도 협업 경험을 쌓는 실질적인 방법이다. Git 브랜치 전략, 코드 리뷰, 일정 조율, 배포 프로세스를 팀원과 함께 경험하면 실무와 유사한 맥락이 생긴다. 단, 결과를 내지 못하고 흐지부지 끝난 프로젝트는 이력으로 쓰기 어렵다. 작더라도 배포하고 운영한 프로젝트가 훨씬 가치 있다.
이력서와 지원 전략에서 놓치기 쉬운 것들
이력서는 채용 담당자가 보통 30초 안에 첫 판단을 내린다. 신입 이력서에서 자주 보이는 실수는 기술 스택을 나열만 하는 것이다. ‘React, TypeScript, Node.js 사용 가능’이라고 써있어도 어느 수준으로 사용할 수 있는지가 전달되지 않으면 의미가 없다. 이보다는 ‘해당 기술을 사용해 무엇을 만들었고, 어떤 문제를 해결했는지’를 한 줄이라도 구체적으로 적는 것이 낫다.
지원 전략에서 ‘묻지마 지원’은 피해야 한다. 채용 공고의 기술 요구사항 중 60~70% 정도를 충족한다면 지원해볼 만하다. 100%를 요구하는 조직은 실제로 많지 않고, 나머지 30~40%는 입사 후 배울 수 있다는 기대를 품고 있는 경우가 많다. 오히려 요구사항을 전혀 충족하지 못한 채 지원하는 것은 에너지를 낭비할 뿐 아니라 불합격 경험이 쌓여 자신감에도 영향을 줄 수 있다.
자기소개서는 짧고 명확하게 쓰는 것이 좋다. ‘저는 항상 성장을 추구합니다’와 같은 추상적인 문장 대신, ‘이 서비스를 3개월간 직접 운영하면서 성능 병목을 발견하고 API 응답 시간을 줄인 경험이 있습니다’처럼 구체적인 사실이 설득력을 만든다. 경험이 없을 때는 구체성으로 승부해야 한다.
커뮤니티와 네트워크, 단순한 인맥이 아닌 학습의 장
개발자 채용에서 레퍼런스나 커뮤니티 연결이 실질적인 영향을 미치는 경우가 있다. 특히 공개 채용 공고가 나오기 전에 내부적으로 먼저 적합한 사람을 추천받아 충원하는 경우도 드물지 않다. 이런 채널에 접근하려면 자신을 알릴 수 있는 커뮤니티 활동이 중요하다.
단순히 네트워킹 이벤트에 참석하는 것을 의미하지 않는다. 스터디 그룹에서 발표를 맡거나, 기술 블로그를 꾸준히 쓰거나, 온라인 커뮤니티에서 다른 사람의 질문에 답변을 달며 자신의 이해를 정리하는 활동이 쌓이면 ‘이 분야에서 활동하는 사람’으로 인식되기 시작한다. 채용 기회는 그런 인식에서 자연스럽게 연결되기도 한다.
누스쿨 커뮤니티는 커리어 전환이나 신입 취업을 준비하는 개발자들이 서로의 포트폴리오를 리뷰하고, 실제 채용 경험을 나누는 공간이다. 막연히 혼자 준비하다 지치기 전에, 같은 길을 걷는 사람들과 연결되는 것이 시행착오를 줄이는 빠른 방법이다. 멘토링 프로그램을 통해 현직 개발자의 시각으로 내 포트폴리오와 이력서를 점검받을 수 있다면, 그 피드백은 몇 달치 독학보다 더 밀도 있는 방향 교정이 될 수 있다.
💬 댓글 0