주니어 채용의 축소는 시작에 불과하다

글로벌 엔트리레벨 테크 채용이 73% 줄었습니다.

같은 시기 IBM은 신입 채용을 3배로 늘렸습니다.

한쪽에서는 "주니어는 끝났다"고 말하고 다른 한쪽에서는 주니어를 더 뽑겠다고 합니다. 모순처럼 보이지만 이 두 숫자가 가리키는 방향은 같습니다.

주니어가 사라진 게 아니라, '주니어'라는 단어의 뜻이 바뀌고 있습니다.

그리고 바뀌고 있는 건 주니어만이 아닙니다.

숫자가 말하는 것

주니어 채용의 감소는 명확한 사실입니다.

영국 HR 데이터 기업 Ravio가 2025년 12월 발표한 테크 채용 리포트에 따르면, 유럽과 미국 테크 기업의 엔트리레벨 채용은 전년 대비 73% 줄었습니다. 같은 기간 전체 직급 평균 감소폭은 7%였습니다. 주니어에게만 유독 가혹한 시장입니다.

미국만 따로 보면 더 극적입니다. Rezi.ai의 2024-2026 엔트리레벨 고용 위기 보고서는 미국 소프트웨어 개발, 데이터 분석 직군의 주니어 채용 공고가 2022년 대비 67% 감소했다고 분석했습니다. Google과 Meta는 2021년 대비 신규 졸업생 채용을 약 50% 줄였고, 같은 보고서에 따르면 미국 엔트리레벨 공고의 60% 이상이 경력 3년 이상을 요구합니다. '주니어'라는 라벨이 붙어 있지만, 내용은 주니어가 아닙니다.

한국도 예외가 아닙니다.

지난 시장은 더 이상 '만드는 사람'만을 원하지 않는다 아티클에서 말씀드렸듯, 주니어 채용이 절반 가까이 줄어들었습니다.

정성적으로도 이 변화를 체감합니다. 요즘 많이 요청 주시는 개발자의 모습은 '시니어인데 AI 도구 잘 쓰는 사람'입니다. 같은 인건비로 주니어 3명을 채용하던 팀이, 시니어 1명 + AI 도구 조합으로 재편하고 있습니다.

채용 방식도 바뀌었습니다. 2년 전까지 대부분의 테크 기업은 공채 → 코딩 테스트 → 기술 면접 → 문화 면접의 순서로 주니어를 뽑았습니다. 지금은 인턴 전환 채용이 사실상 표준이 되었습니다. 3~6개월간 실제 프로젝트에 투입하고 이 사람이 AI 도구를 활용해 혼자서도 결과물을 낼 수 있는가를 본 뒤에 정규직으로 전환합니다. 코딩 테스트 점수가 아니라, 실제 업무에서의 문제 해결 과정을 보는 겁니다.

기술 면접의 질문도 달라졌습니다. "이 알고리즘을 구현해보세요"에서 "이 문제를 AI 도구를 활용해 어떻게 접근하시겠어요?"로 바꾸었습니다.

여기까지만 보면 결론은 "주니어는 끝났다"하고 끝낼 수 있습니다.

그런데 이 숫자들만 보면 놓치는 게 있습니다.

IBM은 왜 역행했는가

2026년 2월 12일, Bloomberg는 IBM이 미국 내 엔트리레벨 채용을 3배로 확대하겠다고 보도했습니다. AI가 주니어의 일을 대체하고 있다는 바로 그 시점에 정반대의 결정을 내린 겁니다.

하지만 IBM이 늘린 건 예전의 '주니어'가 아닙니다.

같은 날 Fortune과의 인터뷰에서 CHRO Nickle LaMoreaux는 엔트리레벨 직무기술서 자체를 재설계했다고 밝혔습니다. 주니어 소프트웨어 개발자는 이제 루틴 코딩에 쓰는 시간이 줄었고, 대신 고객과 직접 일하는 시간이 늘었습니다. AI가 코드를 짜주니까 사람은 코드 너머의 문제를 다루게 된 겁니다.

흥미로운 건 배치 영역입니다. IBM은 HR이나 고객 지원처럼 AI가 충분히 대체할 수 있는 영역에도 의도적으로 주니어를 배치했습니다. AI가 처리하는 업무의 품질을 판단하고 AI가 놓치는 맥락을 채우는 역할입니다. AI를 단순히 쓰기보다 AI가 일하는 환경을 관리하는 것입니다.

IBM의 계산은 냉정합니다. 주니어를 줄이면 당장 인건비는 줄어들 수 있습니다. 하지만 3-5년 뒤 미드레벨 관리자가 비게 됩니다. 그때 외부에서 채용하면 비용은 더 들고, 조직 적응에 시간도 걸립니다. LaMoreaux는 이를 '단기 AI 이득을 넘어서는 판단' 이라고 표현했습니다.

IBM이 보여준 건 '주니어의 종말'이 아니라 '주니어의 재정의'입니다.

여기서 한 가지 더 봐야 할 게 있습니다. IBM이 바꾼 건 주니어 채용 공고만이 아닙니다. 주니어의 역할이 바뀌면 그 위의 역할도 함께 바뀔 수밖에 없습니다.

주니어 뿐만 아니라 시니어 또한 재정의되고 있다.

주니어가 더 이상 루틴 코딩을 하지 않는다면, 시니어의 역할은 무엇이 될까요.

스타트업에서 5년간 백엔드 리드를 맡은 분이 이직을 준비했습니다. 이력서에는 '마이크로서비스 아키텍처 설계', '팀 리드 경험', '고가용성'이 적혀 있었습니다. 기술 리드로서 빈틈없는 이력이었습니다.

면접에서 받은 질문:

"AI 코드 생성 도구를 팀에 도입한 경험이 있나요? 도입 후 개발 프로세스를 어떻게 재설계했나요?"

이 분에게 AI는 개인 생산성 도구였습니다. 팀 단위로 AI를 도입하고, 코드 리뷰 프로세스를 바꾸고, 주니어의 역할을 재설계하는 것은 해본 적이 없었습니다. 답변은 "개인적으로 Claude를 사용하고 있고 생산성이 좋아졌습니다" 정도였습니다.

돌아온 피드백:

"기술 리드 역량은 훌륭하지만, 저희가 지금 필요한 건 AI 시대의 개발 조직을 설계할 수 있는 분입니다."

반대 사례도 있습니다. 6년차의 PM이 스타트업에 지원했습니다. 이전 회사에서 PRD 작성, 스프린트 관리, 유저 리서치까지 해왔던 분이었습니다. 면접에서 이런 질문을 받았습니다.

"MVP를 AI로 하루 만에 만들 수 있는 상황에서, PM이 2주짜리 스프린트를 관리하는 게 의미가 있을까요?"

이 분은 이미 답을 준비하고 있었습니다.

"이전 팀에서 AI 프로토타이핑을 도입한 뒤, PM의 업무 비중이 바뀌었습니다. 빌드에 쓰던 시간 60%가 줄었고, 그 시간을 고객 검증에 재배치했습니다. 스프린트 2주 동안 이전에는 기능 1개를 만들었다면, 지금은 가설 3개를 검증합니다. 결국 '관리'가 아닌 '판단'이 메인이 되었습니다."

두 사례의 차이는 역량이 아닙니다. 바뀐 시장에서 자신의 좌표를 다시 찍었느냐, 예전 좌표에 그대로 서 있었느냐의 차이였습니다.

주니어에게 일어난 일은 시작일 뿐입니다. 가장 먼저, 가장 극적으로 보일 뿐이지, 같은 재정의는 모든 직급에서 진행되고 있습니다.

제목은 그대로인데, 안에 담긴 내용이 바뀌었다.

2년 전까지 커리어 경로는 비교적 명확했습니다. 입사하고, 사수 밑에서 일하며 배우고, 3년차쯤 되면 혼자서 할 수 있게 되고, 5년차쯤에 작은 팀을 리드하기 시작합니다. 각 단계에서 시장이 기대하는 것이 정해져 있었고, 그 기대에 맞추면 다음 단계로 올라갈 수 있었습니다.

지금 그 경로가 다시 그려지고 있습니다. 앞에서 본 것처럼 주니어는 단순 업무를 넘어 문제 정의를, 시니어는 업무 구조와 프로세스를 넘어 AI와 사람의 협업 구조를, PM은 단순 관리를 넘어 가설 판단을 기본적으로 기대받기 시작했습니다.

이 변화는 "과거의 경로를 충실히 밟아온 경험이, 지금 시장에서도 같은 가치를 인정받을 수 있는가"라는 다소 불편한 질문을 던집니다.

경험 자체가 무의미해진 게 아닙니다.

앞선 백엔드 리드와 같이 마이크로서비스를 설계해 본 사람이 AI 워크플로우를 설계하는 데 유리합니다. 스프린트를 운영해 본 PM이 가설 검증 사이클을 설계하는 데 유리합니다. 핵심은 경험을 버리는 것이 아니라, 그 경험이 지금 시장에서 어떤 문제를 풀 수 있는지를 다시 정의하는 것입니다.