최근 제 팀에서 Claude Code로 PR을 올린 주니어 개발자에게 물었습니다. "이 구조를 왜 이렇게 잡았어?" 돌아온 답은 "AI가 그렇게 해줬는데요"였습니다. 작동은 합니다. 테스트도 통과합니다. 그런데 결제 수단 하나 추가하려면 파일 여섯 개를 동시에 고쳐야 한다는 사실을, 그 코드를 승인한 누구도 몰랐습니다. evan-moon 님의 글 제목처럼, 물이 빠지면 누가 발가벗고 수영했는지 드러나는 순간이었습니다.
코드 작성자에서 '리뷰·승인권자'로
evan-moon 님은 ChatGPT 등장 3년 만에 개발자의 하루가 "코드 작성"에서 "AI 출력 검수"로 이동했다고 진단합니다. 저도 체감합니다. AI 코딩 에이전트가 수초 만에 수백 줄을 쏟아내는 지금, 진짜 병목은 코드 생산이 아니라 코드 판단입니다. 많은 팀이 AI 도입 후에도 생산성 향상을 못 느끼는 이유가 여기에 있습니다 — 생산 속도는 10배가 됐는데 리뷰 역량은 그대로니까요.
그리고 이 판단에는 반드시 책임이 따릅니다. "AI가 작성한 코드로 결제 버그가 터지면 누가 책임지는가?" 2024년 발효된 EU AI Act는 답을 명확히 합니다 — 인간입니다. 의료·금융·인프라 등 고위험 영역에서 AI 시스템에 대한 인간 감독을 의무화했고, 자율주행 사고 책임이 제조사·운전자에게, FDA 승인 의료 AI의 최종 판단이 의사에게 귀속되는 것과 같은 맥락입니다. 자동화가 고도화될수록 책임 구조는 희미해지는 게 아니라 오히려 더 선명하게 인간 쪽으로 귀속됩니다.
AI가 못 건드리는 '본질적 복잡성'
Fred Brooks가 1986년에 구분한 우발적 복잡성 vs 본질적 복잡성 프레임은 AI 시대에 오히려 더 날카로워집니다. AI가 해결하는 건 보일러플레이트, 반복 패턴, 문법 오류 같은 우발적 복잡성입니다. 비즈니스 요구사항의 모호함, 상충하는 설계 목표의 균형, 6개월 뒤 변경 비용 예측 — 이런 본질적 복잡성은 AI가 아무리 발전해도 사라지지 않습니다.
특히 추상화 판단에서 차이가 극명합니다. AI도 인터페이스 정의, 클래스 분리, 모듈 분리를 형식적으로는 잘 합니다. 파일이 적절히 나뉘고, 네이밍도 관례를 따르고, 패턴도 익숙합니다. 위험한 건 바로 이 '겉보기 좋음'입니다. AI의 추상화는 통계적 평균이고, 숙련된 개발자의 추상화는 한정된 자원과 불확실한 미래 속 트레이드오프 판단입니다. 문제는 항상 변경이 필요한 시점에 드러납니다.
도구 비용도 '거버넌스'다
판단력이 핵심이라는 건 알겠는데, 현실적으로 팀에 AI 도구를 굴리려면 비용 거버넌스도 필수입니다. Velog의 Claude Code 토큰 절약 가이드를 보면 핵심이 보입니다 — AI는 사람처럼 기억하지 않고, 매 메시지마다 대화 전체를 다시 읽습니다. 대화가 길어지고 참조 파일이 많아질수록 비용은 기하급수적으로 늘어납니다. 계획은 Opus로, 실행은 Sonnet으로 나누는 하이브리드 모드(/model opusplan), 작업 단위마다 컨텍스트를 초기화하는 /clear, CLAUDE.md를 500줄 이하로 유지하는 메모리 분리 — 이런 설정은 단순한 비용 절감이 아니라 AI에게 깨끗한 맥락을 제공하는 품질 관리 행위입니다. 토큰 낭비를 방치하면 AI가 멍해져서 환각(hallucination)을 내놓고, 이걸 고치려고 또 토큰을 쓰는 악순환에 빠집니다.
Human-in-the-Loop는 '승인 버튼'이 아니다
dev.to에 게재된 HITL(Human-in-the-Loop) 설계 아티클이 날카로운 지적을 합니다. 대부분의 AI 데모는 "자동으로 실행!"까지 보여주고 박수를 받는데, "추천이 틀리면?"이라는 질문이 나오면 "승인 단계를 추가하면 되죠?"에서 멈춥니다. 현실에서 그 '간단한 승인 단계'는 알림 시스템, 리뷰 UI, 컨텍스트 보존, 타임아웃 처리, 감사 추적까지 — 종종 AI 파이프라인 전체보다 더 큰 작업입니다.
Carnegie Mellon 연구에 따르면, 설명 없이 AI 추천만 받은 사용자는 89%를 수용했지만 그중 정확한 동의는 61%에 불과했습니다. 나머지는 나쁜 결정을 고무도장 찍은 셈입니다. 해법은 신뢰도 기반 라우팅입니다 — 95% 이상이면 자동 실행 후 감사 로그, 60~80%면 인간 승인 필수, 60% 미만이면 시니어 승인. 인간은 불확실성과 리스크에 비례해서 개입해야 합니다.
에이전트 보안: 새로운 결의 위협
요즘IT가 다룬 OpenClaw 사례는 AI 에이전트 보안의 새로운 국면을 보여줍니다. 네이버·카카오·당근이 일제히 사용을 금지한 이 도구의 핵심 위협은 "데이터가 나가는 게 아니라 AI가 들어온다"는 점입니다. 화면에 보이는 대외비 파일, 열어둔 메신저 창까지 AI의 시선(Vision)이 닿으며, OS 전체 제어 권한을 가진 에이전트가 백그라운드에서 작동하면 해킹과 정상 업무의 구분조차 어려워집니다. 기업들이 차단한 건 기술이 아니라 '준비 없는 도입'입니다.
AI-First 팀이 지금 해야 할 것
이 모든 이슈를 팀 리빌딩 관점에서 엮으면 결론은 명확합니다.
첫째, 설계와 리뷰는 AI에게 넘기지 마세요. 프롬프트 치기 전에 인터페이스와 책임의 경계를 먼저 정의하고, AI 출력과 자신의 설계를 비교하는 습관이 필요합니다. AI에게 PR 리뷰를 맡기고 별 문제 없으면 승인하는 건 "체육 시간에 벤치에만 앉아 있는 것"과 같습니다.
둘째, HITL을 '예외'가 아닌 '노드'로 설계하세요. 인간 승인 단계에 구조화된 컨텍스트, 신뢰도 기반 라우팅, 에스컬레이션 경로, 감사 로그가 기본 내장되어야 합니다.
셋째, 에이전트 보안 거버넌스를 선제적으로 세우세요. OpenClaw 금지령이 보여주듯, OS 레벨 에이전트는 기존 보안 교육으로 막을 수 없습니다. 격리 환경, 권한 최소화, 행동 로깅이 전제되어야 합니다.
결국 AI가 우발적 복잡성을 녹여낼수록, 본질적 복잡성을 다루는 인간의 판단력은 더 부각됩니다. 프롬프트 기술의 유효기간은 도구 교체 주기에 묶여 있지만, 장기 변경 비용을 예측하고, 암묵지를 언어화하고, 책임을 질 수 있는 역량의 유효기간은 소프트웨어가 존재하는 한 끝나지 않습니다. AI가 코드를 쓰는 시대에 팀이 해야 할 일은 더 많이 생산하는 것이 아니라, 더 정확하게 판단하는 것입니다.