몇 년 전만 해도 “개발자로 취업하면 안정적이다”라는 말이 통했다. 부트캠프 수료 후 포트폴리오 몇 개를 다듬으면 주니어 자리를 노려볼 수 있었다. 그런데 요즘 상황은 다르다. “초급 개발자 자리가 줄고 있다”는 이야기가 업계 곳곳에서 들린다. 실제로 채용 시장을 보면 인턴십, 신입 포지션, 주니어 공고가 눈에 띄게 줄었다는 현장 목소리가 많다. AI 코딩 보조 도구가 빠르게 보급되면서 단순 반복 구현 작업의 가치가 낮아졌기 때문이다. 그렇다면 이제 주니어 개발자는 어떻게 살아남아야 할까. 이 글은 그 질문에 대해 구체적으로 답한다.
왜 초급 포지션이 줄어들고 있는가
AI 보조 도구의 확산이 직접적인 원인 중 하나로 거론된다. GitHub Copilot, Cursor 같은 도구들이 보편화되면서 시니어 개발자 한 명이 처리할 수 있는 코드량이 크게 늘었다. 예전에는 팀에 주니어 두세 명을 두고 반복적인 CRUD 작업이나 UI 컴포넌트 구현을 맡겼다면, 지금은 시니어가 AI와 함께 그 일을 더 빠르게 처리한다. 주니어의 ‘가장 쉽게 맡겨지던 일’이 자동화 영역으로 넘어간 셈이다.
여기에 경기 침체와 채용 비용 최소화라는 경영 판단이 겹쳤다. 온보딩 비용, 멘토링 리소스, 생산성 도달 기간—주니어를 뽑는 것은 단기 비용이 생각보다 크다. 팀 규모를 줄이는 방향으로 조직을 재편할 때, 가장 먼저 조정되는 것이 신규 채용이고, 특히 초급 포지션이다. 이것은 개별 주니어 개발자의 문제가 아니라 구조적 변화다.
그렇다고 주니어 자리가 완전히 사라진다는 뜻은 아니다. 하지만 기준이 올라갔다. 예전에 시니어를 채용할 때 요구하던 수준의 ‘문제 인식력’과 ‘자기 방향성’을 이제 주니어에게도 기대하는 회사들이 늘었다. 시장이 바뀐 만큼, 접근 방식도 바꿔야 한다.
단순 구현 능력만으로는 부족한 이유
부트캠프나 독학 과정을 거치면 보통 특정 스택을 익히고 CRUD 앱 하나를 만드는 것을 목표로 한다. 이 과정 자체는 의미 있다. 하지만 문제는 이 수준에서 멈출 때다. AI 도구가 이미 기본적인 코드 생성, 오류 수정 제안, 반복 로직 작성을 충분히 해내는 시대에, ‘주어진 스펙대로 구현하는 능력’만으로는 차별화가 어렵다.
채용 담당자들이 실제로 자주 이야기하는 것은 “문제를 스스로 정의하고 접근 방식을 선택하는 능력”이다. 예를 들어 어떤 기능을 만들라는 지시를 받았을 때, 왜 그 기능이 필요한지, 어떤 사용자 문제를 해결하는지, 기술적으로 어떤 트레이드오프가 있는지를 생각할 수 있는 사람을 원한다. 이것은 연차가 아니라 사고 습관의 문제다.
또한 AI 도구를 얼마나 잘 활용하느냐도 이미 역량 평가 항목이 되고 있다. AI가 생성한 코드를 그대로 붙여넣는 사람과, AI가 제안한 코드의 한계를 파악하고 맥락에 맞게 수정하는 사람 사이에는 실력 차이가 있다. 후자가 되어야 한다.
살아남는 주니어가 실제로 하는 것들
채용 시장에서 눈에 띄는 주니어들을 보면 공통적으로 몇 가지 패턴이 있다. 기술 스택을 많이 쌓는 것보다, 특정 영역에서 깊이를 가지고 그것을 명확하게 설명하는 능력을 갖춘 사람들이 실제 인터뷰까지 가는 비율이 높다.
- 한 가지 프로젝트를 끝까지 밀어붙인 경험: 사이드 프로젝트를 여러 개 만들다 만 포트폴리오보다, 실제 사용자가 있거나 배포까지 완료한 프로젝트 하나가 더 설득력 있다. 완성 경험이 있는 사람은 실무에서도 완성을 낸다는 신호를 준다.
- 트러블슈팅 기록 남기기: 개발 중 막혔던 문제를 어떻게 해결했는지 블로그나 노션에 정리한 사람은 면접에서 그 사례를 구체적으로 이야기할 수 있다. “이런 문제가 있었고, 이렇게 접근했으며, 결국 이렇게 해결했다”는 구조로 말할 수 있어야 한다.
- 코드 리뷰 경험 만들기: 혼자 개발하면 코드 리뷰를 받을 기회가 없다. 오픈소스에 기여하거나, 스터디 그룹에서 서로의 코드를 리뷰하는 것이 실무 감각을 키우는 데 효과적이다.
- 도메인 이해 결합: 특정 산업(헬스케어, 커머스, 교육, 금융 등)에 대한 이해를 기술 역량에 결합한 사람은 그 분야 스타트업이나 기업에서 더 빠르게 성과를 낼 수 있다. “나는 이런 도메인의 문제에 관심이 있고, 이런 기술로 접근하고 싶다”는 방향성이 있으면 채용 측에서 더 쉽게 판단한다.
포트폴리오 전략: 많이보다 깊게
주니어 포트폴리오의 흔한 실수는 ‘증명하고 싶은 것이 너무 많다’는 것이다. React도 했고, Node도 했고, DB도 건드렸다는 것을 보여주려다 보니 각각이 얕다. 채용하는 쪽에서는 “이 사람이 실제로 깊이 파본 게 무엇인가”를 보고 싶어 한다.
포트폴리오를 정리할 때 권장하는 구조는 다음과 같다. 메인 프로젝트 하나에 집중하되, 거기서 어떤 기술적 결정을 내렸는지, 어떤 문제를 만났고 어떻게 해결했는지를 상세히 기록한다. 단순한 기능 목록 나열이 아니라, 결정의 이유와 과정을 보여주는 것이다. 예를 들어 “왜 이 라이브러리를 선택했는가”, “처음 설계와 최종 구현이 어떻게 달라졌는가”, “성능 문제가 있었다면 어떻게 측정하고 개선했는가” 같은 내용이다.
보조 프로젝트 한두 개는 다른 기술이나 접근 방식을 탐구한 흔적으로 두면 충분하다. 중요한 것은 각 프로젝트에서 “내가 무엇을 배웠는가”를 스스로 정확하게 말할 수 있어야 한다는 점이다. 면접에서 포트폴리오를 기반으로 질문이 들어오면, 그것을 막힘 없이 설명할 수 있어야 한다.
취업 준비 중 피해야 할 흔한 함정
취업 준비를 하다 보면 방향을 잃고 비효율적인 패턴에 빠지는 경우가 많다. 다음은 실제로 자주 관찰되는 함정들이다.
- 스택 쌓기 무한 루프: “이것도 배워야 취업이 되겠지”라는 생각으로 새로운 기술을 계속 추가하는 패턴. 어느 시점부터는 새 기술을 추가하기보다 기존 것을 더 깊게 파는 것이 효과적이다. 특히 기초—자료구조, 네트워크 기본 개념, 운영체제 기초—를 제대로 이해하지 않고 프레임워크만 쌓는 것은 인터뷰에서 금방 드러난다.
- 공고 무작위 대량 지원: 지원서를 백 개 보내는 것보다, 열 개를 제대로 맞춤 작성해서 보내는 것이 낫다. 자기소개서와 이력서를 해당 회사와 직무에 맞게 조정하는 과정에서 자신이 왜 그 회사에 지원하는지도 더 명확해진다.
- 혼자 준비하는 것: 취업 준비는 외롭고 기준을 잡기 어렵다. 혼자 공부하면 “내 수준이 어디쯤인가”를 객관적으로 파악하기 힘들다. 스터디, 커뮤니티, 멘토링을 통해 외부 피드백을 받는 것이 중요하다. 특히 같은 단계를 조금 먼저 지나간 사람에게 현실적인 조언을 듣는 것이 큰 도움이 된다.
- 면접 후 복기 안 하기: 면접을 보고 나서 어떤 질문이 나왔는지, 어디서 막혔는지, 어떻게 답하면 더 좋았을지를 기록하지 않으면 같은 실수를 반복하게 된다. 면접 경험은 기록해야 자산이 된다.
지금 당장 할 수 있는 것부터 시작하기
변화하는 채용 환경을 앞에 두고 막막하게 느껴진다면, 지금 당장 할 수 있는 작은 것부터 시작하는 것이 현실적이다. 완벽한 준비를 기다리다가 지원 자체를 미루는 것이 가장 흔한 실수다.
오늘 할 수 있는 것을 구체적으로 정리하면 다음과 같다. 첫째, 지금 만들고 있는 프로젝트가 있다면 배포 완료까지 일정을 잡는다. 둘째, 최근에 해결한 기술적 문제 하나를 골라 블로그 글 하나를 쓴다. 셋째, 관심 있는 회사 세 곳의 최근 채용 공고를 읽고 공통으로 요구하는 역량이 무엇인지 파악한다. 넷째, 같은 목표를 가진 사람들과 연결될 수 있는 커뮤니티나 스터디를 찾는다.
환경이 어렵다고 해서 기회가 없는 것은 아니다. 기준이 올라갔다는 것은, 그 기준을 맞추는 사람에게는 오히려 경쟁이 줄어드는 측면도 있다. 중요한 것은 막연한 불안 대신 명확한 방향을 갖는 것이다.
누스쿨 커뮤니티에는 비슷한 고민을 가진 개발자들과 현직 멘토들이 함께하고 있다. 취업 준비 방향을 잡고 싶거나, 포트폴리오에 대한 솔직한 피드백이 필요하다면 커뮤니티와 멘토링 프로그램을 활용해 보길 권한다. 혼자 고민하는 것보다 한 걸음 더 빠르게 나아갈 수 있다.
💬 댓글 0