AI가 코드를 짜는데 리더는 뭘 하나 — 달라진 역할 3가지

---

코드 리뷰가 이상해졌다.

PR을 열면 코드가 있다. 근데 이걸 누가 왜 이렇게 짰는지 물어볼 수가 없다. AI가 짰으니까. 팀원이 방향을 잡고 AI가 구현했다. 코드가 틀린 건 아닌데 의도를 파악하기가 예전과 다르다.

개발 리더로서, 하네스 엔지니어링을 팀에 도입하고 설계를 다듬어온 지 몇 달이 됐다. AI가 코딩을 하고 사람이 검증하는 게 팀의 기본 흐름으로 자리잡았다. 그 과정에서 리더로서 내 역할이 달라졌다는 걸 느끼기 시작했다.

없어진 게 아니다. 위쪽으로 올라갔다.

---

1. 코드 리뷰가 "의도 검증"으로 바뀌었다

예전 코드 리뷰는 "이 코드가 올바른가"를 보는 거였다. 로직이 맞는지, 예외 처리가 빠진 건 없는지, 컨벤션을 따랐는지.

지금도 그건 본다. 근데 더 중요해진 게 생겼다. "이 AI가 왜 이렇게 판단했는지"다.

AI가 짠 코드는 대체로 문법상 맞다. 컨벤션도 맞다. 테스트도 통과한다. 근데 비즈니스 의도가 빠진 경우가 있다. 명세에 없는 걸 스스로 해결해버린 경우도 있다. 이때는 코드 자체가 문제가 아니라 AI가 받은 맥락이 문제다.

하네스의 두 축에서도 썼지만, 비즈니스 규칙을 도메인 맥락으로 AI에 주지 않으면 AI가 기술적으로 완벽한 코드를 짜도 비즈니스 관점에서 틀린 구현을 만든다.

"이 PR이 왜 이렇게 나왔는가"를 보는 게 리뷰의 핵심이 됐다. 리뷰어가 이걸 잡아내려면 코드가 아니라 맥락을 봐야 한다.

---

2. 요구사항 정밀도가 팀의 병목이 됐다

AI가 빠르게 구현한다. 그게 생각보다 빨리 팀의 진짜 병목이 어디인지를 드러냈다.

요구사항이 모호하면 AI가 임의로 해석한다. "검색 기능 만들어"라고 하면 AI는 만든다. 근데 정렬 기준이 없으면 AI가 임의로 정한다. 페이지네이션 방식이 없으면 AI가 알아서 한다. 결과물이 나왔는데 "이게 아닌데"가 나오면 다시 처음부터다.

사람 개발자라면 불명확한 부분을 물어보거나 적당히 판단해서 맞춰줬다. AI는 묻지 않고 그냥 한다.

결과적으로 리더와 기획자가 요구사항을 더 정밀하게 써야 한다는 부담이 생겼다. AI한테 "검색은 이름·태그 둘 다 되고, 결과는 최신 등록 순으로, 한 페이지 20개"처럼 줘야 한다. 그 정밀도로 정의하는 역량이 지금 팀의 속도를 결정한다.

개발 속도보다 기획·정의 속도가 병목이 되는 구간이 왔다.

---

3. 하네스 설계가 리더의 주 업무가 됐다

프롬프트 잘 쓰는 개발자 한 명이 있으면 팀 생산성이 오르는 구간은 지났다. 그 사람이 퇴사하면 노하우가 같이 사라지니까.

스킬을 어떻게 쪼갤지, 룰을 어디에 어떻게 걸지, 어떤 단계에서 사람 체크포인트를 둘지 — 지금 내가 가장 많이 시간을 쓰는 게 이 설계다. 이게 팀 AI 품질을 결정한다.

과거에 기술 스택 선정이나 아키텍처 결정이 리더의 주 업무였다면, 지금은 하네스 설계가 그 자리에 올라왔다.

팀원이 AI를 잘 쓰는 게 아니라 팀 하네스가 좋아야 한다.

---

주니어 딜레마 — 아직 답이 없다

솔직하게 쓰면, 이게 가장 불편한 부분이다.

AI가 구현을 빠르게 하니까 주니어가 예전처럼 손으로 짜는 경험이 줄었다. 에러를 직접 만나고 디버깅하는 과정이 줄었다. AI가 먼저 처리하니까. AI가 짠 코드를 주니어가 충분히 이해하지 못한다고 보는 시니어 개발자가 84%라는 조사가 있다(BairesDev, 2026). 체감상 맞다.

나는 지금 주니어에게 AI와 협업하는 방식 자체를 가르치는 방향으로 가고 있다. "이 코드가 왜 이렇게 됐는지 AI에게 설명하게 하고, 너는 그게 맞는지 검증해"처럼. 나쁜 해법은 아닌데, 이게 진짜 성장인지는 확신이 없다.

시니어는 어디서 나오나. 아직 모르겠다.

---

리더 역할이 없어지는 게 아니다

AI가 코딩을 한다고 리더가 필요 없어지는 건 아니다.

리더가 해야 할 일의 위치가 올라갔다. 코드를 보는 것에서 맥락을 보는 것으로. 구현을 지도하는 것에서 요구사항과 하네스를 설계하는 것으로. 팀 하네스 퀄리티가 기준이 됐다.

기술 실력이 없어도 된다는 게 아니다. 기술을 위에서 봐야 한다.

하네스 두 축 글에서 마지막에 썼던 말이 지금도 맞다. "모델은 이미 충분히 좋다. 병목은 조직이 맥락을 쌓고 프로세스를 설계하는 속도다."

그 설계를 누가 하는가. 리더다.

그 설계 대상, 그러니까 CLAUDE.md·룰 파일 자체가 공격받을 수 있다는 것도 최근에야 체감했다. AI 코딩 도구 보안 위협에서 다룬 얘기다.

---