모델이 바뀌어도 현장 AI는 살아남는다 — 프롬프트 위의 '규칙 레이어' 설계법

요즘 AI 모델은 몇 주 간격으로 바뀝니다. 성능이 좋아졌다는 소식에 현장에 붙인 AI 기능을 새 모델로 갈아탔더니, 어느 날부터 엉뚱한 판단을 내리기 시작했습니다. 프롬프트는 하나도 안 건드렸는데 말이죠. 모델 업데이트 한 번에 현장 로직이 흔들리는 경험, AI를 현장에 붙여본 엔지니어라면 한 번쯤 겪어봤을 겁니다.

 

## 프롬프트는 설계서가 아니라 '요청서'다

 

프롬프트의 가장 큰 착각은 "정확히 지시하면 정확히 동작한다"는 믿음입니다. 하지만 프롬프트는 PLC 프로그램이 아닙니다. 같은 입력에도 출력이 흔들리고, 모델 버전이 바뀌면 어제 잘 되던 지시가 오늘은 다르게 해석됩니다. 프롬프트를 제어 로직처럼 취급하면, 언젠가 반드시 사고가 납니다. 프롬프트는 요청서지, 설계서가 아닙니다.

 

## 규칙 레이어: AI 앞뒤에 '확정적인 벽'을 세운다

 

제가 현장에서 쓰는 방식은 단순합니다. **AI의 출력은 '초안'으로만 취급하고, 그 앞뒤를 결정적(deterministic) 규칙으로 감싸는 것**입니다.

 

예를 들어 설비 이상 감지 AI라면 이렇게 구성합니다. ① 임계값 룰이 먼저 데이터를 필터링하고, ② AI는 원인 후보를 제안만 하고, ③ 최종 판단은 룰과 작업자 확인이 내립니다. AI가 틀려도 규칙이 막아줍니다. 7년차 현장 엔지니어로서 보면 이건 PLC 인터록과 같은 철학입니다. 소프트웨어가 아무리 똑똑해져도, 안전은 하드와이어드 회로가 지키는 법이니까요.

 

## 모델 교체 테스트를 배포 파이프라인에 넣기

 

새 모델이 나오면 프롬프트를 그대로 새 모델에 돌려봅니다. 출력 포맷, JSON 스키마, 금지어 위반 여부를 자동으로 검증하는 겁니다. 여기서 깨지면 프롬프트를 먼저 고치지 말고 규칙 레이어를 의심하세요. 규칙이 제대로 서 있으면 모델이 바뀌어도 현장 기능은 살아남습니다.

 

AI는 코드를 대신하지만, 현장을 대신하지 않습니다. 모델은 계속 바뀔 겁니다. 바뀌지 않는 건 현장의 규칙뿐입니다.

 

**그래서 뭘 하면 되나** — 이번 주에 현장 AI 기능 하나를 골라 "AI가 틀렸을 때 막아주는 규칙이 있는가"를 점검해보세요. 그 답이 곧 여러분 현장 AI의 수명입니다.

 

> 관련 글: [AI 데모는 됐는데 현장에서 안 되는 이유 — '재현성' 없이 굴리는 모델의 대가](https://developer-arch

ive.tistory.com/125)