주니어를 AI 팀장으로 세우자는 말, 방향은 맞고 순서가 틀렸다

AI 에이전트가 작은 구현을 순식간에 해치우니, 주니어 개발자는 이제 그 에이전트들을 지휘하는 'AI 팀장'이 돼야 한다. mytory.net에 올라온 글의 요지입니다. 작은 조각을 받아 코드를 치던 역할은 AI가 가져갔으니, 주니어도 처음부터 문제를 정의하고 해결책을 설계하고 완료 기준을 정하고 결과를 검수하라는 거죠. 시니어의 코드 리뷰가 AI 시대의 일상적인 병목이 된 만큼, 주니어는 자기 코드에 팀장과 같은 무게의 책임을 져야 한다고도 말합니다.

근거도 구체적입니다. 30분 교육받은 비개발자가 두어 시간 만에 웹앱을 만들고, 글을 쓴 시니어 개발자가 따옴표 처리 기능을 AI에 맡겼더니 밥 먹고 오는 사이 보고서까지 끝나 있었고요. 이 시니어의 하루는 보고서를 읽고, 새 일을 지시하고, 다시 보고서를 읽는 일의 연속이 됐고요. 《바이브 코딩 — 프로덕션의 원칙》의 비유를 빌리면 이제 모든 개발자가 자기만의 작은 주방을 가진 셰프가 된 셈입니다.

여기까지는 저도 동의합니다. 갈라지는 지점은 그 셰프가 어디서 만들어지느냐예요.

판단력은 조리원 시절에 생긴다

이 글이 주니어에게 요구하는 능력 목록을 보면 이렇습니다. 컴퓨터와 네트워크가 어떻게 돌아가는지, UI와 UX, 선택할 수 있는 해결책들, 전체 구조와 이번 해결책의 조화. 글은 코딩 언어 능력의 가치는 줄었어도 이 개발 지식은 여전히 필요하다고 분명히 적었습니다. 저도 같은 생각이에요. 문제는 이 지식 대부분이 그동안 '작은 일을 직접 하면서' 쌓였다는 겁니다.

주니어가 따옴표 처리나 정렬 같은 작은 기능을 직접 짜면서 겪던 시행착오가 바로 판단력의 재료였습니다. 왜 이 함수가 느린지, 왜 이 상태가 꼬이는지를 몸으로 겪어본 사람이 나중에 AI의 보고서를 읽고 "그건 너무 복잡하게 구현했는데? 그냥 오른쪽 정렬만 하면 되지 않아?"라고 말할 수 있어요. 이 시니어가 AI에게 던지는 지시들은 전부 그런 경험에서 나온 문장입니다. 작은 일을 AI에게 넘기는 건 효율로는 맞지만, 그 일이 키우던 판단력의 공급도 같이 끊깁니다. 사다리를 치워놓고 꼭대기에 서라고 하는 셈이죠.

본문에 나온 반례가 오히려 이 우려를 키웁니다. 한 비개발자가 Python으로 프로그램을 짠 뒤 PHP 프로젝트에 기계적으로 얹었고, 기존 프로젝트 안에서 해결할 수 있는지 확인하지 않은 채 AI의 제안을 받아들였다는 사례예요. 글은 이걸 개발 지식이 필요한 이유로 들었지만, 저는 이 장면에서 경험이 얕은 주니어의 모습이 먼저 보였습니다. 판단의 재료가 없는 사람에게 팀장 역할을 주면 이런 결정이 '팀장의 결정'이라는 이름으로 나옵니다. 그리고 이름이 붙은 결정은 이름 없는 실수보다 되돌리기 어렵습니다.

책임을 내려도 병목은 사라지지 않는다

두 번째로 동의하기 어려운 건 책임의 이동입니다. 시니어 리뷰가 병목이니 주니어가 더 무거운 책임을 지고, AI 검수를 2중 3중으로 돌리고, 시니어는 위험도에 따라 보고서만 보거나 코드를 직접 보라는 처방이에요. 저는 이게 병목을 푸는 게 아니라 위험을 옮기는 일이라고 봅니다. 지식과 권한이 덜 쌓인 쪽으로 책임만 내려가면, 사고가 났을 때 그 책임을 실제로 감당할 수 있는 사람은 여전히 시니어고, 시니어는 이제 무엇을 놓쳤는지조차 모르는 상태가 됩니다.

검수 전용 AI를 여러 겹 두자는 제안도 조건이 붙어야 합니다. 직접 코드를 짜지 않은 모델, 다른 개발사의 모델, 알리바바의 Open Code Review 같은 도구를 쓰라는 건 좋은 방향이지만, 같은 완료 보고서와 같은 테스트를 보고 판단하는 검수자는 같은 맹점을 공유하기 쉽습니다. 완료 기준 자체가 틀렸다면 검수를 몇 겹 돌려도 틀린 기준을 통과할 뿐이고요. 이 글에서 제가 가장 높이 치는 처방은 오히려 완료 보고서에 작동 영상과 테스트 결과, 실행 기록을 붙이게 해 가짜 보고를 막자는 부분입니다. 검수를 늘리는 것보다 입증의 형식을 정하는 쪽이 싸고 정확해요. 영상이나 실행 기록은 모델이 그럴듯하게 꾸며내기 어려운 증거니까요.

그럼 무엇을 바꿔야 하나

제 대안은 책임을 내리기 전에 시니어의 검토 위치를 옮기는 겁니다. 지금 병목이 생기는 건 시니어가 AI가 만든 코드를 '사후에' 읽기 때문이에요. 주니어가 맡은 과제의 문제 정의와 해결 방향, 완료 기준을 구현 전에 시니어가 먼저 보면, 코드 리뷰는 그 기준을 지켰는지 확인하는 가벼운 일이 됩니다. 글에 나온 TTS 기능처럼 기획이 중요한 과제일수록 효과가 커요. 시니어는 덜 읽고, 주니어는 가장 비싼 실수를 구현 전에 교정받습니다.

또 하나는 주니어에게 '설명 의무'를 두는 것입니다. 이 글도 개발자가 AI에게 변경 내용을 설명하라고 요구하고 이해되지 않는 부분을 질문하라고 권했는데, 저는 방향을 반대로 돌려야 한다고 봐요. AI가 주니어에게 설명하는 게 아니라, 주니어가 AI의 변경분을 자기 말로 시니어에게 설명할 수 있어야 merge되는 겁니다. 설명하지 못하는 코드를 내보내지 않는다는 규칙 하나가, 작은 일을 직접 하던 시절이 해주던 학습을 일부 대신해줄 수 있습니다.

그렇다고 이 제안이 틀린 건 아닙니다. 방향 자체는 지금 많은 팀이 이미 가고 있는 길이기도 하고요. 테스트와 프리뷰 환경이 잘 갖춰져 있고, 주니어가 이미 손으로 몇 년 짜본 경험이 있다면 '처음부터 팀장'은 꽤 잘 맞는 그림이에요. 과제를 더 큰 단위로 배분하고 완료 기준을 명시하자는 작업 방식 제안은 어느 팀에서든 바로 쓸 만하고요. 제가 반대하는 건 신입에게 그 그림을 그대로 들이미는 경우입니다. 판단력을 기를 경로를 함께 설계하지 않은 채 책임만 먼저 내리면, 1년 뒤 그 팀에는 AI는 잘 부리는데 왜 그렇게 결정했는지는 설명하지 못하는 팀장들이 남을 겁니다.