AI가 주니어를 밀어내고 있다
솔직히 말하면, 저도 처음엔 이 흐름을 긍정적으로만 봤습니다. AI 코딩 어시스턴트를 쓰면 생산성이 올라가고, 더 적은 인원으로 더 많은 걸 할 수 있으니까요. 그런데 MS 애저 CTO 마크 러시노비치와 코어AI 부사장 스콧 한셀만이 ACM 학술지에 공동 기고한 글을 읽고 나서 생각이 달라졌습니다. 그들의 핵심 경고는 이겁니다. "시니어는 채용하고, 주니어는 자동화하라"는 인식이 업계에 퍼지고 있다. GPT-4 출시 이후 22~25세 청년층 고용이 약 13% 감소했다는 데이터까지 붙어 있었고요.
이건 단순한 고용 통계 문제가 아닙니다. 주니어가 시니어로 성장하는 사다리가 끊어지면, 5년 후 10년 후에 복잡한 시스템을 설계하고 위기 상황에서 책임 있는 결정을 내릴 기술 리더가 사라진다는 얘기입니다.
AI는 시니어에게 가속기, 주니어에게는 독이 될 수 있다
AI 코딩 도구가 왜 주니어에게 불리하게 작용하는지 생각해보면 명확합니다. 바이브 코딩(Vibe Coding)—자연어로 의도를 설명하면 LLM이 코드를 생성해주는 방식—은 아키텍처를 이해하고, AI가 내놓은 결과물을 비판적으로 검증할 수 있는 사람에게만 제대로 작동합니다. Andrej Karpathy가 제시한 바이브 코딩의 핵심 역할은 "디자인 퍼스트 프롬프팅"과 "아키텍처 거버넌스"인데, 이건 사실 경험 많은 개발자의 일입니다.
Claude Code나 GitHub Copilot이 생성한 코드를 보면 꽤 그럴듯해 보입니다. 그런데 러시노비치 CTO가 지적했듯, 최신 AI 코딩 에이전트조차 복잡한 동기화 버그를 못 잡고 sleep 함수를 덧붙이거나 잘못된 논리를 정답처럼 내놓는 경우가 있습니다. 시스템 전체를 이해하는 시니어라면 바로 잡아낼 수 있지만, 주니어는 그 코드가 잘못됐는지조차 모를 수 있죠. AI가 성장을 도와주는 게 아니라, 학습 기회 자체를 빼앗는 상황이 될 수 있습니다.
Claude Code와 CI/CD 자동화가 보여주는 현실
Claude Code가 최근 cowork와 security 기능을 추가하며 개인 개발자 보조를 넘어 팀 단위 업무 인프라로 진화하고 있습니다. 실제로 Claude Code가 경쟁 도구 대비 높은 평가를 받는 이유는 모델 자체가 아니라, 코드 생성을 전제로 설계된 시스템 프롬프트와 워크플로우 덕분입니다. 명시되지 않은 예외 처리나 보안 요소를 알아서 보완하는 경향이 있거든요.
CI/CD 자동화 측면에서도 변화가 가파릅니다. PipelineIQ 같은 도구는 파이프라인 실패 로그를 Claude AI에 던져 수 초 안에 근본 원인과 수정 방법을 Slack으로 알려줍니다. 기존에 엔지니어가 300줄 로그를 뒤지며 45분 쓰던 일을 자동화한 거죠. 이건 분명히 팀 생산성에 좋습니다. 하지만 그 45분이 사실 주니어가 시스템을 몸으로 배우던 시간이기도 했다는 걸 잊으면 안 됩니다.
그래서 AI-First 팀은 어떻게 주니어를 키워야 하나
저도 팀 리빌딩을 하면서 이 문제를 계속 고민하고 있습니다. MS 임원들이 제시한 '프리셉터십(preceptorship)' 모델이 현실적인 출발점이라고 생각합니다. 시니어 1명이 3~5명의 주니어를 전담해서, 프롬프팅부터 디버깅까지 의사결정 과정을 함께 경험하게 하는 구조입니다. 정답을 주는 게 아니라 과정을 같이 밟는 거죠.
제가 팀에서 실제로 해보고 있는 방식을 몇 가지 공유하면:
① AI 결과물을 그대로 쓰지 말고, '왜 이렇게 나왔는지' 설명하게 한다. Claude Code가 생성한 코드를 주니어에게 그냥 머지하게 하지 않습니다. "이 코드가 왜 이런 구조인지, 어떤 예외 케이스를 처리하고 있는지" 설명하는 시간을 반드시 끼웁니다. AI 생성 + 인간 검증 협업 모델을 주니어 교육의 틀로 활용하는 거예요.
② 바이브 코딩은 '설계 언어 훈련'으로 접근한다. 바이브 코딩에서 중요한 건 자연어로 의도를 정밀하게 표현하는 능력입니다. 이건 개발 역량의 핵심이기도 합니다. 주니어에게 먼저 요구사항을 자연어로 정리하게 하고, 그 프롬프트가 AI에게 제대로 전달되는지를 시니어와 함께 검토합니다. 코드를 짜기 전에 생각하는 훈련이 됩니다.
③ CI/CD 자동화 도구는 '문제 해결 과정'을 함께 본다. PipelineIQ 같은 도구가 진단 결과를 슬랙으로 쏴줄 때, 주니어가 혼자 받아보고 fix만 적용하게 하면 안 됩니다. AI 진단 결과를 보면서 "왜 이 에러가 났는지, AI 진단이 맞는지" 같이 리뷰하는 세션을 만들어야 합니다. 자동화가 학습을 대체하지 않도록 의도적으로 설계해야 합니다.
AI 도구 설계 자체도 바뀌어야 한다
한셀만 부사장이 흥미로운 제안을 했습니다. AI 도구가 정답을 즉시 주는 게 아니라, 학습자에게 질문을 던지고 스스로 해결책을 찾도록 유도하는 소크라테스식 코칭 AI로 발전해야 한다는 겁니다. 저도 완전히 동의합니다. 지금 Claude나 Copilot은 "이렇게 하세요"를 바로 줍니다. 주니어 교육 모드라면 "이 에러가 왜 났다고 생각해요? 먼저 어디를 봐야 할까요?"를 물어봐야 맞습니다.
실제로 Claude를 팀원 교육에 쓸 때, 저는 시스템 프롬프트에 "정답을 바로 주지 말고, 힌트와 질문으로 유도해달라"고 지정합니다. 같은 모델도 어떻게 쓰느냐에 따라 교육 도구가 되기도 하고 생각을 빼앗는 도구가 되기도 합니다.
전망: AI-First 팀의 성장 사다리를 다시 설계해야 한다
솔직히, AI-First 팀 리빌딩을 하면서 가장 어려운 질문이 이겁니다. "AI 도구를 잘 쓰는 팀이 주니어 친화적일 수 있는가?" 지금까지의 흐름은 그렇지 않은 방향으로 가고 있습니다. 하지만 이건 필연이 아니라 설계의 문제입니다.
AI 도구 도입이 주니어를 대체하는 게 아니라, 주니어가 더 빨리 더 깊이 성장하는 발판이 되도록 의도적으로 팀 구조와 워크플로우를 만들어야 합니다. 단기 생산성 지표만 보면 주니어 채용은 손해처럼 보입니다. 하지만 5년 후 팀을 이끌 기술 리더가 없다면, 그 손해는 훨씬 커집니다.
러시노비치 CTO의 말이 계속 머릿속에 남습니다. "소프트웨어 엔지니어링의 미래는 AI가 얼마나 많은 코드를 생성하느냐가 아니라, 이 직군의 장인정신을 어떻게 보존하느냐에 달려 있다." AI-First 팀이라면 이 질문을 피하지 말고 정면으로 마주해야 합니다.