개념
가드레일(guardrail)은 AI 시스템이 허용된 범위 밖으로 나가지 않도록 붙이는 통제 장치다. 도로 가장자리의 가드레일이 차를 밀어붙여 달리게 하는 것이 아니라 이탈만 막듯이, 모델의 능력을 끌어올리기보다 넘지 말아야 할 선을 정해 두는 쪽에 가깝다.
거는 자리는 크게 세 곳이다. 첫째는 입력으로, 들어온 요청이 서비스 범위 안의 것인지, 프롬프트 인젝션 시도가 섞여 있지 않은지, 개인정보가 그대로 담겨 있지는 않은지를 본다. 둘째는 출력으로, 답변이 정해진 형식을 지켰는지, 금지된 내용이나 근거 없는 단정이 들어가지 않았는지를 검사한다. 셋째는 동작으로, 함수 호출이 실제로 실행되기 전에 권한과 인자를 확인하고 위험한 호출은 막거나 사람의 승인을 받게 한다.
구현 수단은 단순한 규칙 검사부터 별도의 분류 모델까지 다양하지만, 공통점은 모델 바깥에 있다는 것이다. 시스템 프롬프트에 하지 말라고 적어 두는 것은 강한 요청이지 보장이 아니다. 가드레일은 모델이 지시를 어겼을 때에도 여전히 작동해야 의미가 있으므로, 코드와 정책 층에 두는 것이 원칙이다.
가드레일이 모델의 판단을 대신하는 것은 아니다. 대부분의 요청은 그대로 통과시키고 명확히 선을 넘는 경우에만 개입하는 것이 목표다. 그래서 규칙은 넓고 모호하게 잡기보다 좁고 분명하게 잡는 편이 오래간다. 무엇을 막는 규칙인지 한 문장으로 설명되지 않는다면, 그 규칙은 나중에 오탐의 원인이 될 가능성이 높다.
쓰임새
고객 응대 봇에서는 답변 범위를 벗어난 질문을 상담원 연결로 넘기거나, 확정적 약속으로 읽힐 문구를 걸러 내는 데 쓴다. AI 에이전트에서는 삭제·송금·외부 발송처럼 되돌릴 수 없는 동작 앞에 확인 단계를 두는 형태가 대표적이다.
설계할 때는 막았을 때 무엇을 할지까지 정해 두어야 한다. 그냥 거절만 하면 사용자는 이유를 모른 채 막히고, 무엇이 걸렸는지 기록이 남지 않으면 잘못 걸러 낸 사례를 고칠 수도 없다. 차단·경고·사람에게 넘김처럼 단계를 나누고, 걸린 사례를 모아 기준을 조정해 나가는 편이 현실적이다.
가드레일도 시험해 보아야 한다. 반드시 막아야 하는 요청 모음과 반드시 통과해야 하는 정상 요청 모음을 각각 만들어 두고, 규칙을 고칠 때마다 양쪽을 함께 돌려 본다. 한쪽만 보고 조정하면 조이다가 정상 요청까지 막거나, 풀다가 위험한 요청을 흘려보내게 된다. 두 모음을 함께 두는 것만으로도 어느 쪽으로 기울었는지가 바로 보인다.
자주 하는 오해
시스템 프롬프트에 금지 사항을 적어 두면 가드레일이 있는 것 아닌가?
모델이 따라 줄 확률을 높인 것일 뿐이다. 반드시 막아야 하는 일이라면 모델의 판단과 무관하게 작동하는 검사가 있어야 한다.
가드레일을 붙이면 환각이 없어지나?
눈에 띄는 패턴을 걸러 낼 뿐, 그럴듯하게 꾸며 낸 내용은 그대로 통과한다. 근거를 함께 제시하게 하는 설계와 같이 가야 한다.
가드레일은 촘촘할수록 좋지 않나?
정상적인 요청까지 막는 오탐이 늘면 사용자는 서비스를 신뢰하지 않게 되고, 결국 우회 경로를 찾아 쓰게 된다. 모든 동작에 같은 강도를 적용하기보다 위험도에 따라 강도를 달리 두는 편이 낫다.