AI가 코드를 다 짜주는 시대, 주니어 개발자는 어떻게 성장해야 할까 (15년차 개발자의 생각)

얼마 전 팀 주니어 개발자가 짜온 코드를 리뷰하다가 잠깐 멍해진 적이 있다. 코드가 이상해서가 아니다. 너무 멀쩡해서였다. 예외 처리도 깔끔하고, 네이밍도 좋고, 테스트 코드까지 붙어 있었다. 3년차가 쓴 코드라고 보기엔 지나치게 정돈되어 있었다. 물어보니 역시나였다. "AI한테 시키고 제가 다듬었어요." 요즘은 이게 표준이다. 나도 쓴다. 부정할 생각은 없다. 다만 그날 이후로 계속 머릿속을 떠나지 않는 질문이 하나 있다. AI가 코드를 다 짜주는 시대에, 주니어 개발자는 도대체 어떻게 성장해야 하는가.

 

사진: Arnold Francisca / Unsplash

코드 리뷰 풍경이 달라졌다

15년 넘게 이 일을 하면서 코드 리뷰 풍경이 이렇게 빨리 바뀐 건 처음 본다. 몇 년 전만 해도 주니어 코드 리뷰의 절반은 문법과 컨벤션 얘기였다. 변수명이 왜 이러냐, 이 반복문은 왜 세 번 도냐, null 체크는 어디 갔냐. 지금은 그런 지적을 할 일이 거의 없다. AI가 그런 실수를 안 하기 때문이다.

대신 리뷰에서 나오는 질문이 달라졌다. "이 함수가 왜 여기 있어야 하죠?" "이 케이스에서 트랜잭션이 왜 필요한지 설명해줄 수 있어요?" 이런 질문을 던졌을 때 대답이 막히는 경우가 늘었다. 코드는 본인이 올렸는데, 그 코드가 왜 그렇게 생겼는지는 설명을 못 한다. 코드의 주인이 사람이 아니라 도구가 된 것 같은 순간이다.

오해는 말자. 주니어가 게을러서가 아니다. 회사는 빠른 결과물을 원하고, AI는 빠른 결과물을 준다. 눈앞에 완성된 코드가 있는데 그걸 안 쓰고 한나절 삽질하는 게 오히려 이상한 선택처럼 보이는 환경이 됐다. 구조가 그렇게 만들어졌는데 개인을 탓하는 건 공정하지 않다.

문제는 코드가 아니라 '겪음'의 실종이다

내가 걱정하는 건 코드 품질이 아니다. AI가 짜준 코드는 대체로 평균 이상이다. 문제는 그 코드에 도달하기까지의 과정이 통째로 사라진다는 데 있다.

예를 하나 들어보자. 몇 달 전 운영 중이던 서비스에서 간헐적으로만 재현되는 타임아웃 장애가 있었다. AI에게 물으니 그럴듯한 원인 후보를 여러 개 냈다. 커넥션 풀 고갈, DNS 캐싱, GC 멈춤. 전부 그럴싸했지만 정답은 그 목록에 없었다. 결국 문제를 찾은 건 "왜 특정 시간대에만 터지지?"라는 이상한 감각을 못 버린 팀원의 집요함이었다. 그 감각은 어디서 왔을까. 비슷한 장애를 맨몸으로 겪어본 기억에서 왔다고 나는 생각한다.

개발자의 실력이라는 게 뭘까 생각해보면, 결국 '겪은 문제의 총량'이라고 나는 믿는 편이다. 새벽에 장애 알림 받고 로그를 뒤지다가 커넥션 풀 설정 하나 때문이었다는 걸 알아냈을 때, 인덱스를 걸었는데도 쿼리가 느려서 실행계획을 처음 열어봤을 때, 그런 경험들이 쌓여서 어느 순간 코드를 보면 냄새를 맡는 감각이 생긴다. 이 감각은 책으로도, 강의로도 안 생긴다. 겪어야 생긴다.

그런데 AI는 바로 그 '겪는 구간'을 건너뛰게 해준다. 에러가 나면 에러 메시지를 복사해서 붙여넣으면 원인과 해결책이 같이 온다. 편하다. 나도 매일 그렇게 한다. 하지만 나는 그 에러를 예전에 맨몸으로 겪어봤기 때문에 AI의 답이 맞는지 틀렸는지 판단할 수 있다. 겪어본 적 없는 사람에게 AI의 답은 검증할 수 없는 정답지다. 채점 기준 없이 정답지만 쌓이는 공부가 실력이 될 리 없다.

 

사진: Mohammad Rahmani / Unsplash

"우리 때는 삽질로 배웠다"는 말의 함정

여기까지 쓰고 보니 딱 꼰대 소리 하기 좋은 흐름인데, 일부러 반대쪽 얘기도 해야겠다. "우리 때는 삽질하면서 배웠는데 요즘 애들은..."이라는 말에는 함정이 있다.

솔직해지자. 우리가 삽질로 배운 건 그때는 삽질 말고 방법이 없었기 때문이다. 스택오버플로우가 없던 시절에 개발하던 선배들은 매뉴얼 책 한 권 들고 밤을 새웠고, 그 선배들 눈에는 검색으로 답을 찾는 우리가 날로 먹는 것처럼 보였을 거다. 구글 검색이 개발자를 망친다는 얘기도 있었고, IDE 자동완성이 개발자를 바보로 만든다는 얘기도 있었다. 지금 들으면 웃기지 않나. 도구가 바뀔 때마다 같은 걱정이 반복됐고, 개발자들은 결국 그 도구 위에서 더 어려운 문제를 풀어왔다.

그러니까 "AI 때문에 주니어가 성장을 못 한다"는 명제는 절반만 맞다고 본다. 정확히는 이렇게 고쳐 써야 한다. 성장의 경로가 바뀌었는데, 새 경로가 아직 정리가 안 됐다. 예전 경로는 폐쇄됐는데 새 이정표는 없는 상태. 지금 주니어들이 서 있는 곳이 거기다.

그래서 주니어는 뭘 해야 하나

답을 아는 척할 생각은 없지만, 애 셋 키우면서 배운 게 하나 있다. 아이가 자전거를 배울 때 보조바퀴를 언제 떼느냐가 중요한 게 아니라, 넘어져도 되는 안전한 환경에서 넘어져보는 경험이 중요하더라. 개발도 비슷하다고 생각한다. 내가 주니어라면, 혹은 내 팀 주니어에게 해주고 싶은 얘기는 세 가지다.

첫째, AI의 답을 받기 전에 내 답을 먼저 만들어보는 습관. 설계든 디버깅이든, 10분이라도 좋으니 내 가설을 먼저 세우고 나서 AI에게 물어보는 거다. 내 가설과 AI의 답이 다르면 왜 다른지 따져보는 그 지점에서 진짜 공부가 시작된다. 가설 없이 받은 답은 흘러가고, 가설 위에서 받은 답은 쌓인다.

둘째, 설명할 수 없는 코드는 올리지 않는다는 원칙. AI가 짜줬든 어디서 가져왔든 상관없다. 리뷰에서 "이거 왜 이렇게 했어요?"라는 질문에 자기 언어로 답할 수 있으면 그건 자기 코드다. 답을 못 하면 아직 자기 코드가 아닌 거다. 이 기준 하나만 지켜도 AI를 쓰면서 성장하는 쪽에 설 수 있다고 본다.

셋째, 일부러 겪는 시간을 확보하는 것. 회사 일은 속도가 생명이니 AI를 풀로 쓰되, 사이드 프로젝트나 학습 시간에는 의도적으로 AI를 끄고 바닥부터 부딪혀보는 거다. 근력 운동이랑 똑같다. 평소에 기계 힘을 빌리더라도, 맨몸 운동으로 기본 근력을 만들어두지 않으면 기계가 없을 때 아무것도 못 든다. 일주일에 반나절이라도 좋다. 프레임워크 없이 HTTP 서버를 직접 띄워본다든가, ORM 없이 쿼리를 손으로 짜본다든가. 이런 시간이 당장의 생산성에는 아무 도움이 안 되지만, 5년 뒤의 판단력에는 복리로 쌓인다.

하나 더 보태자면, 장애와 트러블슈팅 경험은 기회가 올 때 자원해서 잡으라고 말하고 싶다. 남의 장애 회고 문서를 읽는 것과 새벽에 직접 로그를 뒤지는 건 완전히 다른 경험이다. AI가 대체하기 가장 어려운 경험이 바로 이런 '내 서비스가 무너지는 걸 직접 복구해본 기억'이다. 힘들지만, 이만한 성장 부스터가 없다.

 

사진: Franck V. / Unsplash

채용과 면접도 흔들리고 있다

이 얘기를 하려면 채용 얘기를 빼놓을 수 없다. 최근에 우리 팀 채용 면접에 들어갔다가 재미있는 경험을 했다. 과제 전형으로 제출된 코드들이 다 비슷하게 잘 짜여 있었다. 몇 년 전이라면 상위 10%에 들었을 코드가 이제는 평균이 됐다. 과제만 봐서는 지원자의 실력을 구분할 수 없는 시대가 된 거다.

그래서 면접 방식도 바뀌고 있다. 우리도 과제 코드에 대해 '왜'를 파고드는 질문의 비중을 크게 늘렸다. 이 구조를 선택한 이유, 다른 대안과의 트레이드오프, 이 코드가 트래픽이 10배 늘면 어디서 먼저 터질지. AI로 짠 코드라도 이 질문들에 자기 언어로 답하는 지원자는 합격이다. 반대로 완벽한 코드를 내고도 설명이 무너지는 지원자가 생각보다 많다. 결국 면접장에서도 갈리는 건 코드가 아니라 코드에 대한 이해다.

주니어 입장에서 이건 나쁜 소식이 아니라고 본다. 채용의 기준이 '코드를 짤 수 있는가'에서 '코드를 설명할 수 있는가'로 옮겨가고 있다는 건, 성장의 방향도 거기에 맞추면 된다는 뜻이니까. 어디에 힘을 써야 할지가 오히려 명확해졌다.

시니어와 회사도 숙제가 있다

주니어에게만 숙제를 떠넘기면 안 된다. 사실 더 큰 숙제는 시니어와 회사에 있다고 생각한다.

시니어의 역할은 이제 '코드 잘 짜는 법'을 가르치는 게 아니라 '판단하는 법'을 가르치는 쪽으로 옮겨가야 한다. 리뷰에서 문법 지적할 일이 없어졌으면, 그 시간에 왜 이 구조를 선택했는지, 이 코드가 6개월 뒤에 어떤 문제를 일으킬 수 있는지 같은 얘기를 해야 한다. 나부터도 리뷰 코멘트의 방향을 바꾸는 중이다. "이렇게 고치세요"가 아니라 "이 경우엔 어떻게 되나요?"라고 묻는 쪽으로.

회사 입장에서는 더 현실적인 문제가 있다. AI 때문에 주니어 채용을 줄이는 회사들이 실제로 늘고 있는데, 이건 미래의 시니어 공급을 끊는 일이다. 시니어는 하늘에서 떨어지지 않는다. 전부 주니어였던 사람들이다. 지금 주니어를 안 뽑고 안 키우면 5년 뒤에 시니어 구인난으로 돌아온다. 눈앞의 생산성만 보고 성장 사다리를 걷어차는 건 업계 전체로 보면 제 발등 찍기다.

우리 팀이 실험 중인 것들

말만 하면 꾼대니까, 우리 팀에서 올해 실제로 해보고 있는 것들을 공유한다. 성공했다기보다는 아직 실험 단계라는 걸 전제로 봐주면 좋겠다.

첫 번째는 '설명 리뷰'다. 주니어가 PR을 올리면 일주일에 한 번은 코드 리뷰 대신 15분짜리 구두 설명 시간을 잡는다. 화면 공유하고 본인이 짜온 코드의 흐름을 말로 설명하는 거다. 신기하게도 설명하다가 본인이 먼저 "어, 이거 이상한데요"하며 문제를 찾는 경우가 많다. 설명은 이해를 강제하는 장치다.

두 번째는 AI 사용 기록이다. 프롬프트를 어떻게 썼는지, AI 답을 그대로 썼는지 고쳤는지, 고쳤다면 왜 고쳤는지를 PR 설명에 한 줄씩 남기게 한다. 부끄러워할 일이 아니라 오히려 자랑이 되는 문화를 만들려고 한다. AI 답을 고친 이유를 설명할 수 있다는 건 그 사람의 판단력이 작동했다는 증거니까.

세 번째는 장애 회고에 주니어를 무조건 참여시키는 거다. 예전엔 시니어끼리 빨리 끝내는 게 효율적이라 생각했는데, 지금은 생각이 바뀌었다. 장애 회고야말로 AI가 대신 겪어줄 수 없는 경험을 간접체험으로라도 전달할 수 있는 거의 유일한 자리가 됐다.

반대편 의견도 있다

토론 카테고리에 쓰는 글이니 반론도 정리해둔다. 실제로 주변 개발자들과 얘기해보면 의견이 꽤 갈린다.

한쪽에서는 "겪음의 실종" 자체가 기우라고 본다. 어차피 앞으로의 개발은 AI와 협업하는 형태가 기본값이 될 텐데, 옛날 방식의 밑바닥 경험은 라틴어 같은 교양이지 필수가 아니라는 거다. 자동차 정비를 몰라도 운전을 잘할 수 있듯이, 저수준 디버깅 경험 없이도 AI를 지휘해서 좋은 소프트웨어를 만드는 새로운 유형의 개발자가 주류가 될 거라는 주장. 일리가 있다. 나도 어셈블리를 몰라도 15년을 먹고살았으니까.

다른 한쪽은 내 걱정보다 더 비관적이다. 판단력이라는 것도 결국 겪음에서 나오는데, 겪음의 기회 자체가 구조적으로 사라졌으니 세대 단절은 피할 수 없다는 쪽. 어느 쪽이 맞을지는 솔직히 모르겠다. 5년쯤 지나면 답이 나올 텐데, 그때 지금 주니어들이 어떤 시니어가 되어 있을지가 그 답일 거다.

정리하며

나는 AI 코딩 도구를 매일 쓰고, 앞으로 더 쓸 거다. 이건 거스를 수 있는 흐름이 아니다. 다만 도구가 대신해주는 것과 내가 가져가야 하는 것을 구분하는 일은 여전히 사람 몫이다. 코드는 AI가 짜줄 수 있어도, 그 코드에 책임지는 감각과 판단력은 외주를 줄 수 없다.

주니어 시절의 나에게 한 줄만 남긴다면 이렇게 쓰겠다. 도구는 최대한 활용하되, 설명할 수 없는 코드에 네 이름을 붙이지 마라. 그 원칙 하나면 도구가 뭐로 바뀌든 계속 성장할 수 있다.

여러분 생각은 어떤가. AI 시대의 주니어 성장, 기우일까 진짜 위기일까. 현업에 계신 분들의 의견이 궁금하다. 댓글로 나눠주시면 감사히 읽겠다.