최근 개발 커뮤니티에서 가장 뜨거운 주제 중 하나는 이 질문이다.
“AI가 주니어 개발자를 쓸모없게 만들고 있는가?”
Be A Better Dev의 글은 이 불편한 문제를 정면으로 다룬다. 글의 핵심은 단순한 비관론이 아니다. 오히려 훨씬 현실적인 경고다.
AI는 생산성을 높여주지만, 동시에 ‘얕은 유능함(shallow competence)’을 대량 생산할 수 있다.
즉, 결과물은 빠르게 나오는데 “왜 이렇게 만들었는지”를 설명하지 못하는 개발자가 늘어날 수 있다는 이야기다.
1. 진짜 위기는 “코드 생산 능력”이 아니라 “판단 능력”이다
예전에는 버그를 고치기 위해 로그를 뒤지고, 스택 트레이스를 읽고, 시스템 동작을 몸으로 익혀야 했다. 지금은 AI가 그 과정을 통째로 압축해 준다.
문제는 여기서 시작된다.
- 코드는 돌아간다.
- 티켓은 닫힌다.
- 리뷰 전까지는 모두가 만족한다.
하지만 코드 리뷰에서 “왜 이 패턴을 선택했나요?”라는 질문이 나왔을 때 멈춘다면, 그건 실무 리스크다.
기업이 시니어에게 돈을 지불하는 이유는 타이핑 속도가 아니라, 실패 패턴을 식별하고, 트레이드오프를 판단하고, 나쁜 선택을 피하는 능력 때문이다.
주니어가 AI를 잘 활용하더라도, 이 판단 레이어를 건너뛰면 결국 성장 곡선이 무너진다.
2. “AI 금지”가 아니라 “학습 설계”가 필요하다
AI를 끄고 과거 방식으로 돌아가자는 건 현실적이지 않다. 핵심은 사용 금지가 아니라 사용 설계다.
전략 A) 답보다 이유를 요구하라
AI에게 바로 정답만 받지 말고, 최소한 아래를 함께 받는 습관이 필요하다.
- 대안 2~3개
- 각 대안의 장단점
- 실패 가능성이 높은 조건
- 현재 맥락에서 추천한 근거
이렇게 하면 AI를 “코드 생성기”가 아니라 “설계 튜터”로 쓸 수 있다.
전략 B) 의도적으로 ‘디버깅 근육’을 남겨둬라
에러가 나면 곧바로 붙여넣기 전에, 먼저 스스로 가설을 세우는 루틴이 중요하다.
- 스택 트레이스 읽기
- 재현 조건 정리
- 로그/메트릭 확인
- 원인 가설 1~2개 작성
- 그 다음 AI에게 검증 요청
이 순서만 지켜도 실력이 쌓이는 속도가 달라진다.
전략 C) “이해 못한 코드는 출고 금지” 원칙
AI가 제안했더라도 아래 질문에 답하지 못하면 병합하면 안 된다.
- 왜 이 라이브러리를 썼는가?
- 대안은 무엇이며 왜 버렸는가?
- 장애 시 어떤 문제가 생길 수 있는가?
이 기준이 없으면 팀은 단기 속도를 얻고, 장기 유지보수 비용을 폭발적으로 지불하게 된다.
3. 주니어에게 지금 필요한 건 더 많은 프롬프트가 아니다
커리어 초반에는 “빨리 많이 만들기”보다 “왜 그렇게 만드는지 설명할 수 있는 상태”가 더 중요하다.
AI 시대의 주니어 성장 전략은 이렇게 요약된다.
- 산출물 속도: AI로 확보
- 판단력 깊이: 의도적 학습으로 확보
둘 중 하나만 가져가면 오래 못 간다.
- 속도만 있고 판단이 없으면, 리뷰/장애/설계에서 무너진다.
- 판단만 있고 속도가 없으면, 실무 경쟁력을 잃는다.
결국 시장이 원하는 건 “AI를 잘 쓰는 사람”이 아니라, AI가 만든 결과를 검증하고 책임질 수 있는 엔지니어다.
마치며: ‘대체’의 시대가 아니라 ‘격차’의 시대
AI가 주니어를 즉시 대체한다기보다, 더 정확히는 격차를 확대한다.
- 생각 없이 붙여넣는 사람은 빠르게 한계에 부딪히고,
- AI를 학습 증폭기로 쓰는 사람은 더 빠르게 성장한다.
지금 필요한 건 공포가 아니라 전략이다.
앞으로의 경쟁력은 “코드를 누가 작성했는가”가 아니라, 그 코드를 누가 이해하고, 설명하고, 개선할 수 있는가에서 결정된다.