온프레미스에서 AI 에이전트 DevOps가 어려운 진짜 이유

"AI 코드 리뷰" 와 "AI DevOps 에이전트" 는 다른 문제다.

전자는 코드를 읽고 의견을 낸다. 후자는 실제로 빌드를 돌리고, 배포를 트리거하고, 인시던트를 다룬다. 클라우드에서 GPU 한 통 빌리면 끝나는 일이 아니다. 특히 온프레미스 환경에서는 세 가지 제약이 기술 선택을 다 결정해 버린다.

1. 데이터 경계

대부분의 LLM 서비스는 외부 API 호출을 전제로 한다. 그러나 폐쇄망 / 분리망 환경의 코드, 인시던트 로그, 배포 메타데이터는 외부로 한 바이트도 나갈 수 없다.

해결책은 두 갈래다.

• 자체 호스팅 모델 (Llama, Qwen 계열) — GPU 자원, 모델 운영 책임을 떠안음
• 게이트웨이를 통한 마스킹 / 토큰 치환 — 의도 누락이 잦고 운영이 무겁다

CollabOps 는 모델 자체보다 모델이 다루는 데이터 평면을 먼저 정의한다. 어떤 정보가 어느 경계 안에서만 살아 있어야 하는지 — 이게 정해지지 않으면 어떤 모델 선택도 답이 안 된다.

2. 실행 권한

AI 에이전트가 "PR 머지", "배포 롤백", "스테이징 재기동" 같은 행동을 하려면, 사람과 동등한 수준의 권한 모델을 가져야 한다.

• 누가 이 에이전트에게 배포 권한을 줬는가
• 어떤 조건에서 그 권한이 효력을 갖는가 (시간대, 환경, 변경 범위)
• 에이전트의 실행이 사람의 실행과 같은 감사 추적에 들어가는가

대부분의 AI 코드 어시스트 제품은 이 셋 중 어느 것도 답하지 않는다. 그건 IDE 안의 일이기 때문이다. 운영 평면으로 넘어가는 순간 이 셋이 전부 필요하다.

3. 감사 의무

공공·금융처럼 규제가 있는 산업에서는, "AI 가 했어요" 가 면책 사유가 되지 않는다. 오히려 그 반대다 — AI 가 한 일을 사람이 똑같이 증명해야 한다.

who?     — 어떤 에이전트가, 어떤 자격으로
what?    — 어떤 입력으로, 어떤 출력을 만들었고
when?    — 정확히 언제
which?   — 어떤 모델·버전·프롬프트를 썼고
why?     — 어떤 트리거가 이 실행을 일으켰는가

이 다섯 개가 한 트레이스로 연결되지 않으면, 사고가 났을 때 재현 도 해명 도 불가능하다.

정리

AI 에이전트 DevOps 는 "더 똑똑한 모델" 의 문제가 아니다. 데이터 경계·실행 권한·감사 의무가 동시에 풀려야 비로소 운영 평면에 들어올 수 있다. 이 셋을 못 풀면 결국 "코드를 읽는 봇" 으로 머문다.