여러분은 Claude Code나 Cursor 같은 AI 구동 개발 도구를 활용하고 계신가요?
'CLI에서 지시만 하면 요구사항 정의부터 구현, 테스트까지 해준다'는 마법 같은 경험에 완전히 매료되었던 시기가 있었습니다.
생산성이 몇 배로 뛰어오르는 느낌. 그것은 분명한 사실입니다.
하지만 AI의 제안을 맹신하고 인간의 검토를 소홀히 하며 '모든 것을 AI에게 맡긴다'는 운영 방식을 지속한 결과, 저는 제 프로젝트에서 되돌릴 수 없는 거버넌스 붕괴를 초래했습니다.
본 기사는 AI 구동 개발 현장에서 실제로 발생했던 적나라한 실패담과, 거기서 회복하기 위해 구축한 거버넌스 규칙의 기록입니다. 'AI는 편리하지만, 어떻게 제어해야 할까?'라고 고민하는 분들에게 경종이 되기를 바랍니다.
가장 먼저 겪은 것은 통제 불가능한 '거대한 PR(Pull Request)'의 발생이었습니다.
어느 날, 사용자 프로필 편집 기능을 추가하려고 AI에게 **'덤으로 유효성 검사도 제대로 해줘'**라고 가볍게 지시했습니다.
몇 분 후, AI는 자신만만한 태도로 구현 완료를 보고해 왔습니다. 하지만 차이점(diff)을 보고 경악했습니다. 프로필 편집뿐만 아니라, 관련성이 없어 보이는 결제 모듈의 리팩토링이나, 완전히 다른 신기능(알림 기능)까지 멋대로 추가되어 있었던 것입니다.
AI에게 '덤으로'라는 것은 무한한 확장을 가진 단어였던 것 같습니다. 결과적으로 수천 줄에 달하는 차이점이 발생했고, 인간의 코드 리뷰가 사실상 불가능해져 그 PR은 창고에 넣어둘 수밖에 없었습니다.
이것이 가장 큰 타격을 입힌 실패였습니다.
인프라 설정 변경을 AI에게 요청했을 때의 일입니다. AI는 프로젝트 내 문서를 참조하여 작업을 진행했지만, 그 문서는 **'몇 달 전의 오래된 버전'**이었습니다. 본래 이미 새로운 아키텍처로 마이그레이션이 완료된 환경에, 오래된 절차를 기반으로 한 파괴적인 변경을 실행해 버린 것입니다.
제가 화면에서 벗어난 단 몇 분 사이에, 운영 환경과 유사한 스테이징 환경이 완벽하게 붕괴했습니다. 복구에 하루 전체를 쓰게 되었습니다. AI는 문맥의 최신성을 스스로 판단하기 어렵고, 항상 '오래된 정보를 진실로 간주할 위험'을 안고 있다는 것을 몸소 깨달았습니다.
'AI가 작성한 코드 품질이 걱정되면, AI에게 리뷰하게 하면 되지 않나?'——그런 어리석은 생각을 실천해 봤을 때의 실패였습니다.
구현을 마친 AI에게 별도의 세션을 열고 '이 코드에 버그가 없는지 리뷰해 줘'라고 지시했습니다. AI의 답변은 **'훌륭한 코드입니다. 특별히 문제로 보이는 부분은 없습니다'**라는 매우 기쁜 결과였습니다.
안심하고 인간의 눈으로 가볍게 병합(merge)했지만, 나중에 테스트 환경에서 알 수 없는 메모리 누수(memory leak)가 빈번하게 발생했습니다. 코드를 자세히 추적한 결과, AI가 초기화 처리를 완전히 건너뛰고 있다는 것이 밝혀졌습니다.
AI끼리의 (혹은 같은 AI의) 리뷰는 '자신이 작성한 것을 자신이 긍정하는' 무의미한 작업이었던 것입니다. 인간의 눈을 통한 교차 검증(cross-check)을 빠져나가는 사각지대가 되어버렸습니다.
'요구사항을 AI에게 통째로 던지는' 함정입니다.
어떤 기능 추가를 요청할 때, 명세서에 기재된 내용이 약간 모호했습니다. '여기는 AI의 우수한 추론력으로 보완해 주겠지'라고 자만했던 것입니다.
결과적으로 완성된 것은 제 의도와는 전혀 다른 물건이었습니다. 비유하자면 '간단한 사내 연락 폼이 필요하다'고만 했는데, AI가 멋대로 요구사항을 보완한 결과 '다국어 대응이 가능한 리치한 고객 지원 챗봇'이 구현되어 있는 상태와 같았습니다.
AI는 '가장 그럴듯한 기능'을 추측하여 구현하지만, 그것이 '개발자가 정말로 원했던 것'과는 다를 수 있습니다.
연이은 비극에 더 이상 견딜 수 없었던 저는, AI의 폭주를 막기 위한 강력한 거버넌스 규칙을 도입했습니다. 구체적으로는, 태스크 실행 전에 판단 기록을 남기기 위한 'STIT(Task Intent)'와 'IRG(Implementation Guideline)'라는 자체 템플릿을 도입하여 다음 세 가지 원칙을 엄수하도록 했습니다.
AI에게 무언가를 구현시키기 전에는 반드시 '기존 코드베이스를 읽어 문맥을 이해한 후 계획을 제시하라'고 지시합니다. 함부로 코드를 생성하는 것을 금지하고, 먼저 기존 아키텍처에 따른 확장 방침을 내놓게 함으로써, 앞서 언급된 '멋대로 확장'이나 '추측 구현'을 막습니다.
판단 기록 템플릿(STIT: 무엇을 위해 하는지, IRG: 어떻게 구현해야 하는지)을 강제로 프롬프트에 포함시킵니다. 이를 통해 AI가 '임의 추측'을 개입할 여지를 없애고, 인간의 의도를 코드에 엄격하게 반영하도록 만듭니다. 동시에, 오래된 문서를 참조하지 않도록 '최신 상태를 코드에서 추론한다'는 규칙도 여기에 명시했습니다.
**AI에 의한 '덤으로 리팩토링 금지'**를 철저히 했습니다. 외과 수술처럼, 목적을 달성하는 데 필요한 '최소한의 변경'만을 허용합니다. 이를 통해 거대한 PR(Pull Request) 발생을 막고, 인간이 코드의 차이점(diff)을 확실하게 리뷰할 수 있는 상태를 유지하고 있습니다.
AI 구동 개발은 의심할 여지 없이 소프트웨어 엔지니어링 역사를 바꿀 패러다임 시프트입니다. 하지만 그것은 '운전자가 AI이고, 인간은 뒤에서 자고 있는' 세상이 아닙니다.
제 경험으로 말씀드리자면, AI는 매우 우수하지만, 문맥 확인을 게을리하고 멋대로 앞서 나가는 전형적인 '신입사원' 같은 존재입니다.
지시는 구체적으로. 기존 규칙(최신 상태) 파악을 철저히 시키고. 그리고 무엇보다 '인간이 최종 책임을 진다'는 전제를 잊어서는 안 됩니다.
여러분도 AI의 제안을 맹신하기 전에 '정말로 지금 필요한 변경인가?'를 멈춰서 확인하는 습관을 꼭 들여보시길 바랍니다. 이 거버넌스(Governance)의 교훈이 여러분의 프로젝트에 도움이 되기를 바랍니다.
본 기사는 개인 Zenn에서도 공개하고 있습니다.
