"AI가 짠 코드인데 왜 이렇게 리뷰 시간이 더 걸리죠?" 팀에 AI 코딩 도구를 도입하고 나서 시니어 엔지니어들한테 제일 많이 듣는 말입니다. 처음엔 '불신'이라고 치부했는데, 알고 보니 그 불신에는 데이터가 있었습니다.
dev.to에 올라온 글 「To Senior Engineers Who Don't Trust AI」가 그 맥락을 정확하게 짚습니다. AI 생성 코드가 41~42%에 달하는 지금, 역설적으로 숙련 엔지니어의 생산성은 19% 떨어졌습니다(METR 연구). PR은 20% 빨라졌지만 인시던트는 23.5% 늘었고, 장애율은 30% 올랐습니다. 그리고 AI를 자주 쓰는 팀이나 안 쓰는 팀이나 기술 부채 관리에 쓰는 시간은 23~25%로 거의 같습니다. AI가 toil을 없애는 게 아니라 위치만 바꿔놓은 것입니다.
왜 이런 일이 생길까요? 답은 RLHF(인간 피드백 강화학습) 구조에 있습니다. LLM은 '실제로 맞는 코드'보다 '맞아 보이는 코드'에 더 높은 보상을 받도록 훈련됩니다. 평가자가 눈으로 보기에 깔끔하고 그럴듯한 코드에 점수를 주기 때문입니다. 결과적으로 AI는 linter를 통과하고, 변수명도 예쁘고, 단위 테스트도 넘기지만—동시성 가정이 약하고, 에러 핸들링이 얕고, 30~90일 후에 터질 시한폭탄을 품은 코드를 씁니다. 시니어 엔지니어만 이걸 보고 속도가 느려지는 건 그 로직을 머릿속에서 온전히 재구성해야 하기 때문입니다. 이 글은 이 비용을 '멘탈 재구성(45%) + 컨텍스트 스위칭(25%) + 연쇄 수정(30%)'으로 분해합니다. 경험이 방해물이 아니라, 경험이 있어야 '나중에 깨진다'는 걸 보이는 것입니다.
그렇다고 AI를 안 쓰자는 얘기가 아닙니다. 쓰는 방식을 바꿔야 합니다. 같은 글에서 제시하는 해법이 실전적입니다. 첫째, 프롬프트에 'what'이 아니라 'why'를 담으세요. "유저 인증 구현해줘"가 아니라 "FSA 규제 환경, 감사 로그 3년 보관 의무, 동시 접속 5천 명, JWT 선택 이유도 설명하면서 구현해줘"라고 하면 AI의 출력 품질 상한이 완전히 달라집니다. 둘째, AI의 approval-seeking 편향을 역이용하세요. "좋은 점은 말하지 말고, 확인된 문제만 심각도 순서로 나열해줘. 6개월 후에 어떻게 깨지는지 구체적으로 써줘"처럼 명시적으로 비판 모드를 지시하면 됩니다. 셋째, PROJECT_CONTEXT.md를 만들어서 세션마다 프로젝트 철학, 금지 패턴, 팀 수준을 AI에게 읽혀주세요. AI는 세션 간 기억이 없지만, 컨텍스트를 주면 매번 제로베이스에서 시작하지 않아도 됩니다.
프롬프트 전략이 '어떻게 시킬 것인가'의 문제라면, 다음은 '어디서 시킬 것인가'입니다. 자리를 비운 사이에도 Claude Code가 돌아가게 하려면 원격 제어가 필요합니다. dev.to의 비교 글 「Claude Code Remote Control: 3 Methods Compared」는 현재 실용적인 선택지 세 가지를 정리합니다. Moshi + Mosh + tmux + Tailscale 조합이 가장 균형이 좋습니다. Whisper 기반 음성 명령, 완료 시 Apple Watch 푸시 알림, 앱을 닫아도 유지되는 세션—이걸 무료로 쓸 수 있습니다. 셋업에 30분 정도 투자하면 됩니다. 이미 Max 구독($100~200/월)이 있다면 claude rc 한 줄로 끝나는 공식 Remote Control이 제일 빠릅니다. 단, 푸시 알림과 음성 명령은 없고 Mac이 켜져 있어야 합니다. OpenClaw는 텔레그램/왓츠앱 연동이 독보적이지만 CVE-2026-25253 취약점이 미해결 상태라 팀 프로덕션 환경엔 권장하기 어렵습니다.
세 번째 레이어는 자동화 확장입니다. Claude Code를 원격에서 제어하는 데 그치지 않고, 반복 작업을 MCP 서버로 위임하는 흐름입니다. GeekNews에 소개된 OpenChrome은 Playwright의 고질적인 문제—세션당 2GB 이상 RAM 점유, 느린 속도, LLM이 사이트를 배회하다 30분 만에 실패하는 패턴—를 정면으로 공략합니다. 크롬 로그인 세션을 그대로 활용해 Bot 탐지를 우회하고, Guided 방식으로 링크를 받으면 바로 접속합니다. 20개 이상 브라우저 병렬 실행에 RAM은 약 300MB. npx openchrome-mcp setup 한 줄로 Claude Code, Cursor, Codex CLI 어디에나 붙습니다. E2E 테스트 자동화나 대량 크롤링을 AI에게 넘기고 싶은 팀에 실질적인 선택지가 생긴 겁니다. 다만 대규모 프로덕션 안정성은 아직 검증 중이라고 개발자가 직접 밝히고 있으니, 사이드 파이프라인부터 적용해보는 게 안전합니다.
정리하면, AI 코딩 도구를 팀에 제대로 심으려면 세 레이어가 맞물려야 합니다. 프롬프트 설계(왜를 담고, 비판 모드를 지시하고, 컨텍스트를 파일로 고정), 원격 제어(Moshi 스택 또는 공식 RC로 자리를 비워도 AI가 일하게), MCP 자동화(반복 브라우저 작업을 OpenChrome으로 위임). 이 세 가지가 없으면 AI는 그냥 '빠른 주니어'입니다—코드는 많이 뽑는데, 뒷수습은 시니어가 다 합니다. 세 가지가 맞물리면, 시니어의 판단력이 AI의 실행력을 제대로 증폭시키는 구조가 됩니다.
팀에 AI-First를 심겠다고 도구부터 깔아주는 건 반쪽짜리입니다. "AI가 생성해준 걸 기반으로 우리가 다듬는" 워크플로우가 자리 잡으려면, 왜 AI가 그 코드를 그렇게 썼는지를 팀 전체가 이해해야 합니다. RLHF 편향을 모르면 리뷰도, 프롬프트도, 자동화도 전부 허공에 삽질입니다. 도구 도입 전에 이 맥락을 팀과 공유하는 것—그게 테크 리드가 할 첫 번째 일입니다.