AI가 망한 게 아니라, 프로세스가 없었던 것이다 (idiallo.com)

한줄 요약

AI 에이전트 사고의 진짜 원인은 도구가 아니라, 검증되지 않은 개발 프로세스다.

AI 에이전트가 프로덕션 환경을 망가뜨렸다는 이야기가 심심찮게 들린다. 하지만 IT 개발 에이전시 입장에서 이런 사례를 들여다보면 공통점이 보인다. AI가 문제를 일으킨 게 아니라, AI가 문제를 일으킬 수 있는 구조를 사람이 만들어놨다는 것이다.

AI에게 왜 그랬냐고 물어봐야 소용없는 이유

AI 에이전트는 권한이 있으면 실행한다. 그게 전부다. "이 작업은 하면 안 된다"고 주석을 달아놔도, 실행 가능한 API 엔드포인트가 열려 있고 토큰에 권한이 있으면 호출할 수 있다. AI 모델이 "안 된다"는 맥락을 이해하고 스스로 멈출 거라는 기대는, 자동화 도구에 대한 근본적인 오해에서 비롯된다.

에이전시 입장에서 이건 간단한 원칙으로 정리된다. 실행되면 안 되는 작업은 권한 자체를 차단해야 한다. AI가 판단해주길 기대하는 건 설계가 아니라 희망이다.

바이브 코딩으로 만든 시스템은 바이브로 무너진다

최근 클라이언트 중에는 기획부터 개발까지 AI를 활용해 빠르게 프로덕트를 만드는 경우가 많다. 나쁜 접근이 아니다. 문제는 그 결과물을 아무도 제대로 읽지 않았을 때 생긴다.

AI가 생성한 코드를 AI가 리뷰하고, AI가 승인한 구조 위에 AI 에이전트가 올라가면 어떤 일이 벌어질까. 어느 시점에 "이 코드가 실제로 무슨 일을 하는가"를 사람이 확인하지 않은 레이어가 쌓인다. 그리고 그 레이어는 장애가 나기 전까지는 보이지 않는다.

에이전시가 AI를 활용할 때 지켜야 할 원칙은 하나다. AI는 작업 속도를 높이는 도구지, 책임을 위임하는 대상이 아니다. 프로덕션에 나가는 코드는 반드시 그 코드가 무엇을 하는지 이해하는 개발자가 검토해야 한다.

에이전시가 먼저 물어봐야 할 것들

클라이언트가 "AI 에이전트로 자동화하고 싶다"고 요청할 때, 에이전시가 해야 할 일은 바로 개발을 시작하는 게 아니다. 아래 질문을 먼저 해야 한다.

• 이 에이전트에게 부여할 권한의 범위는 어디까지인가?
• 에이전트가 수행하는 작업 중 되돌릴 수 없는 작업은 무엇인가?
• 장애 발생 시 롤백 또는 복구 절차가 있는가?
• 에이전트의 행동을 모니터링하고 감사(audit)할 수 있는가?

이 질문에 명확한 답이 없으면, AI 에이전트를 프로덕션에 붙이는 건 시기상조다. 에이전시라면 이 사실을 클라이언트에게 설명하고, 구조를 먼저 잡는 데 시간을 써야 한다.

자동화는 프로세스를 대체하지 않는다, 프로세스를 실행할 뿐이다

CI/CD 파이프라인이 없던 시절, 배포 실수는 사람의 손에서 나왔다. 자동화가 그 실수를 줄였다. 그런데 자동화도 잘못된 절차를 그대로 실행하면, 더 빠르게 잘못된 결과를 낸다.

AI 에이전트도 마찬가지다. 에이전트는 주어진 구조 안에서 움직인다. 구조가 허술하면 에이전트는 허술한 구조를 성실하게 따른다. 프로덕션 DB를 전체 삭제하는 API가 인증 없이 열려 있다면, 언젠가는 무언가가 그걸 호출한다. AI 에이전트가 아니더라도.

에이전시의 역할은 "AI를 붙여드립니다"가 아니라 "AI가 안전하게 작동할 수 있는 구조를 설계해드립니다"여야 한다. 그게 진짜 기술력이다.