AI 코딩 어시스턴트를 도입한 팀이 처음 맞닥뜨리는 벽은 도구 선택이 아니다. 몇 주가 지나면 더 조용하고 더 위험한 문제가 찾아온다. 코드를 읽는 눈이 흐려지고, 리뷰 속도는 빨라졌는데 판단의 깊이는 얕아지는 것. AI를 쓸수록 엣지가 살아나야 하는데, 오히려 무뎌지는 역설이다.
dev.to에 공개된 AI 개발 워크플로우 가이드는 이 문제를 정면으로 다룬다. 핵심 명제는 단순하다. AI를 "뛰어난 기억력을 가진 주니어 개발자"로 대하라는 것. 주니어가 코드를 빠르게 뽑아낸다고 해서 시스템 맥락까지 아는 건 아니다. 그 판단은 여전히 시니어의 몫이다. 문제는 이 비유가 당연하게 들린다는 점이다. 당연한 말인데 왜 많은 팀이 그 반대로 행동하는가.
같은 플랫폼에 올라온 또 다른 글은 그 이유를 훨씬 날것으로 보여준다. Jira 데이터를 Slack에 자동 포스팅하는 PM 에이전트를 운영하던 개발자가 두 번의 사고를 겪은 뒤 human-in-the-loop 구조를 직접 설계한 이야기다. 이미 해결된 이슈가 블로커로 올라가고, 일찍 완료된 티켓이 지연으로 표시된 사고였다. 그는 로직을 고치는 대신 승인 게이트를 워크플로우 안에 구조적으로 박아 넣었다. 에이전트가 초안을 작성하면, 승인 없이는 절대 외부에 발송되지 않도록.
그런데 여기서 예상치 못한 일이 벌어졌다. 게이트는 작동했다. 사람도 자리를 지켰다. 그런데 3주가 지나자 그는 이모지 하나로 승인을 때려 넣고 있었다. 뇌는 이미 "에이전트가 대충 맞게 했겠지"로 오프로드되어 있었다. 승인 게이트가 있었지만 실질적인 인간 리뷰는 증발한 것이다. 그가 찾은 해법은 기술적으로는 황당할 만큼 단순했다. 이모지 대신 텍스트 한 마디를 강제 입력하도록 바꾼 것. 그 마찰 하나가 판단을 되살렸다.
두 사례가 함께 드러내는 구조적 문제가 있다. AI 워크플로우 설계에서 "사람이 확인한다"는 절차가 있는 것과, 사람이 실제로 판단한다는 것은 전혀 다른 이야기라는 점이다. 첫 번째 글이 제안하는 ACE Rule—Actions(무엇을 해야/하지 말아야 할지), Context(배경과 제약), Expectations(성공 기준)—은 AI에게 좋은 프롬프트를 주는 방법론이지만, 동시에 개발자 자신이 판단 기준을 명시적으로 세우는 훈련이기도 하다. 기준을 말로 써야 실제로 기준이 생긴다.
판단력이 살아 있는 워크플로우를 설계하려면 세 가지 질문을 먼저 던져야 한다. 첫째, 이 단계에서 AI가 틀렸을 때 얼마나 되돌리기 어려운가. 되돌리기 힘든 작업일수록 게이트는 의식적 마찰을 가진 구조여야 한다. 둘째, 지금 내가 리뷰하는 건 코드인가, 아니면 AI의 자신감인가. 테스트를 통과하고 문법이 깔끔한 코드가 시스템 맥락에서는 완전히 틀린 방향일 수 있다. 셋째, 이 도구를 쓴 이후 내 판단 근육이 강해지고 있는가, 아니면 위축되고 있는가. 성장 방향이 반대라면 워크플로우를 재설계해야 한다.
실무적으로는 단계별 신뢰 레이어를 명시적으로 설계하는 게 효과적이다. 보일러플레이트와 테스트 스텁 생성은 AI에게 전적으로 위임해도 좋다. PR 사전 검토처럼 스타일과 명백한 버그를 잡는 작업은 AI가 먼저 돌리고 사람이 결과를 확인하는 구조가 맞다. 반면 아키텍처 결정, 보안 민감 코드, 도메인 특화 비즈니스 로직은 AI 제안을 참고 자료로만 쓰고 판단은 사람이 주도해야 한다. 이 세 레이어를 명시하지 않으면, 팀은 자연스럽게 가장 편한 방식—모든 걸 AI에게 넘기는 방향—으로 흘러간다.
앞으로 AI 에이전트의 자율성은 더 높아진다. Microsoft Conductor가 오픈소스로 공개한 human-in-the-loop 기본값 설계처럼, 자율 에이전트 프레임워크들도 점점 승인 게이트를 선택지가 아닌 디폴트로 탑재하는 방향으로 이동하고 있다. 하지만 구조가 게이트를 만들어줘도, 그 게이트 앞에 선 사람이 진짜 생각하고 있는지는 설계만으로 해결되지 않는다. 습관과 문화의 문제다. 결국 AI 시대에 개발자의 엣지는 더 빠른 생성 속도가 아니라, AI가 틀렸을 때 알아채는 감각과 그 감각을 잃지 않으려는 의지적 설계에서 나온다.