내가 AI 에이전트(AI Agents)와 함께 실제로 사용하는 가드레일(Guardrails)

나는 ai liberty에서 모델의 능력이 향상될수록 모델의 확신(confidence)도 커지며, 그 확신 때문에 프라이머리 브랜치(primary branch)에 푸시하거나 아무도 요청하지 않은 데이터베이스 쿼리(database query)를 실행하는 등의 자의적인 행동을 하게 된다고 주장했습니다. 해당 포스트는 문제를 지적하고 가드레일(guardrails)을 약속했지만, 구체적인 방법론을 보여주는 데까지는 이르지 못했습니다. 이번 포스트는 실제 도구 세트(kit)를 소개하는 후속 글입니다.

내가 계속해서 되새기는 프레임워크는 '차선 준수(lane discipline)를 동반한 속도'입니다. 가드레일은 브레이크(brakes)가 아닙니다. 그것은 도로의 경계가 어디인지 정확히 알 수 있게 하여 내가 빠르게 달릴 수 있도록 해주는 차선 표시(lane markers)입니다. 목표는 안전한 95%의 작업에 대해 에이전트(agent)의 속도를 늦추는 것이 결코 아닙니다. 목표는 에이전트가 되돌릴 수 없는 행동을 할 수 있는 몇 안 되는 방식들을 제거하는 것입니다.

빠른 답변 (quick answer)

내가 의존하는 가드레일은 네 가지 계층, 즉 에이전트와 에디터(agent and editor), 저장소(repository), 데이터(data), 그리고 인간의 관문(human gate)에 위치합니다. 나는 에이전트의 기본 설정을 읽기 전용(read-only) 또는 요청 모드(ask mode)로 설정하고, 에이전트가 지속적으로 실행하는 안전한 명령은 허용 목록(allowlist)에 넣고 파괴적인 명령은 거부(deny)합니다. 데이터베이스 자격 증명(database credentials)은 읽기 전용으로 제공하며 절대 운영 환경(production)을 가리키지 않도록 하며, 메인 브랜치(main branch)를 보호하여 검토(review) 없이는 아무것도 반영되지 않도록 합니다. 그 외에도 진정으로 되돌릴 수 없는 작업 목록은 항상 나의 명시적인 승인을 요구합니다. 이 중 어떤 것도 일상적인 업무 속도를 늦추지 않는데, 왜냐하면 오직 되돌리기 어려운 드문 움직임만을 차단하기 때문입니다.

대상 (who this is for)

대상: 파일, 터미널(terminal), 또는 데이터베이스(database)를 다룰 수 있는 AI 에이전트(AI agents)를 운영하는 엔지니어 및 데이터 전문가
전제 조건: 이미 에이전트 기반 에디터(agentic editor)나 CLI를 사용 중이며, 의도치 않은 동작을 경험했거나 이를 방지하려고 시도 중인 경우
이 가이드를 사용해야 할 때: 복구 불가능한 피해를 입힐 수 있는 경로를 열어두지 않으면서도 자율성(autonomy)의 속도를 얻고 싶을 때

이것이 중요한 이유 (why this matters)

AI 자유(AI liberty)에서 설명했던 사건들은 단지 운이 좋았기에 무해했을 뿐입니다. 한 에이전트는 스스로 커밋(commit)을 수행하고 기본 브랜치(primary branch)에 푸시(push)했으며, 또 다른 에이전트는 로컬 스크립트를 하이재킹(hijack)하여 운영 데이터베이스(production database)에 쿼리(query)를 실행했습니다. 저는 AI 모델 미러와 함께 작업하기 (working with an ai model mirror)에서, 당신이 막지 않는 한 빠른 모델은 커맨드 라인(command line)에서 실제로 상당한 자유를 누릴 것이라고 썼습니다. 공통된 핵심은 타이밍(timing)입니다. 파괴적인 행동은 1초 만에 일어나지만, 복구에는 몇 시간이 걸리거나 아예 불가능할 수도 있습니다.

가드레일(guardrails)은 질문의 본질을 '모델이 무언가를 하지 않을 것이라고 내가 믿는가'에서 '모델이 그것을 할 수 있는가'로 바꿉니다. 신뢰(trust)는 희망이고, 가드레일(guardrail)은 제약(constraint)입니다. 전자는 조용히 실패하지만, 후자는 안전하게 실패(fail safe)합니다. 이는 제가 AI 에이전트를 신뢰하는 것의 위험성 (the danger of trusting the ai agent)에서 썼던 것과 동일한 차선 준수(lane discipline)이며, 의도(intention)가 아닌 설정(configuration)을 통해 구체화된 것입니다.

레이어 1: 에이전트와 에디터 (layer 1: the agent and the editor)

이곳은 제한을 설정하기에 가장 비용이 적게 들면서도 가장 많은 문제를 잡아내는 곳입니다.

읽기 전용(read-only) 또는 요청 모드(ask mode)를 기본값으로 설정: 새로운 채팅은 제가 권한을 부여할 때까지 명령을 실행하거나 파일을 작성할 수 없는 상태로 시작됩니다. 따라서 제가 문제를 설명하는 동안에는 아무것도 실행되지 않습니다.
안전한 동사(verb)는 허용 목록(allowlist)에 넣고, 파괴적인 것은 거부: 에이전트는 중단 없이 저의 상수적이고 되돌릴 수 있는(reversible) 명령들을 실행하며, 위험한 명령들은 확인을 위해 멈춥니다.
워크스페이스 범위(scope) 제한: 에이전트는 프로젝트 루트(project root) 내부에서만 작업하며, 저는 환경 파일(environment files)과 자격 증명 파일(credential files)을 에이전트의 손이 닿지 않는 곳에 둡니다.
채팅별 초기화: 권한은 세션 간에 유지되지 않으므로, 일회성 허용이 영구적인 허용이 되지 않습니다.

허용 목록(allowlist)은 매일 그 가치를 증명하는 부분입니다. 규칙의 형태는 도구마다 다른 정확한 구문(syntax)보다 더 중요합니다:

# 묻지 않고 실행하세요, 이것들은 안전하고 되돌릴 수 있습니다
allow:
  - git status
...

핵심은 특정 목록이 아닙니다. 안전한 경로는 마찰이 없고, 파괴적인 경로는 내 기억이 아니라 기본적으로 차단되어 있다는 점입니다.

레이어 2: 저장소(Repository)와 git

주의 깊은 에디터 설정(editor config)을 하더라도, 결국 명령어가 실수로 실행될 수 있다고 가정합니다. 저장소는 나의 두 번째 안전망입니다.

main 브랜치 보호: 직접적인 푸시(push)를 허용하지 않으므로, 에이전트가 풀 리퀘스트(Pull Request) 없이 main 브랜치에 무엇인가를 반영할 수 없습니다.
리뷰 및 체크 통과 요구: 머지(merge) 전에 사람의 리뷰와 통과된 지속적 통합(CI, Continuous Integration)이 필요합니다. 이는 에이전트와 공유 히스토리 사이에 사람과 테스트 스위트(test suite)를 배치하는 역할을 합니다.
에이전트는 커밋(commit)만 하고, 푸시(push)는 하지 않게 하기: 에이전트는 기능 브랜치(feature branch)에서 스테이징(stage) 및 커밋을 할 수 있으며, 차이점(diff)을 읽은 후 풀 리퀘스트를 여는 것은 나입니다.
프리 커밋(pre-commit) 단계에서 비밀 정보 스캐닝 유지: 자격 증명(credentials)을 차단하는 훅(hook)은 에이전트가 생성하거나 찾아낸 키를 커밋하려고 시도하는 순간을 대비한 저렴하고 효과적인 방어책입니다.

이 레이어가 중요한 이유는 에이전트의 행동에 의존하지 않기 때문입니다. 브랜치 보호(branch protection)는 모델의 판단력이 아니라 플랫폼에 의해 강제되므로, 에디터 설정이 잘못되었을 때도 유효합니다.

레이어 3: 데이터와 자격 증명(Credentials)

이것은 내가 가장 엄격하게 적용하는 레이어입니다. 데이터 손상은 항상 되돌릴 수 있는 종류가 아니기 때문입니다.

에이전트에게 읽기 전용(read-only) 역할 부여: 내 개발 루프의 자격 증명은 선택(select)만 할 수 있어야 하며, 그 외의 것은 할 수 없습니다.
운영 환경(production)의 쓰기 권한을 절대 닿을 수 없는 곳에 두기: 에이전트의 연결 지점은 개발(development) 또는 스테이징(staging) 데이터베이스를 향해야 하며, 운영 환경의 쓰기 자격 증명은 해당 환경에 아예 존재하지 않아야 합니다.
저장소와 프롬프트(prompt)에서 비밀 정보 제외: 자격 증명은 환경 변수(environment variables)나 비밀 관리자(secret manager)에 존재해야 하며, 로그와 히스토리에 남게 되는 채팅창에 절대 붙여넣지 마세요.
모든 곳에서 최소 권한 원칙(least privilege) 선호: 모든 것에 공유되는 하나의 강력한 역할보다, 용도별로 분리된 좁은 범위의 역할이 더 낫습니다.

읽기 전용 역할을 설정하는 데는 몇 분밖에 걸리지 않으며, 이를 통해 사고의 한 범주 전체를 제거할 수 있습니다:

create role ai_agent_readonly;
grant usage on warehouse dev_wh to role ai_agent_readonly;
grant usage on database analytics_dev to role ai_agent_readonly;
...

이러한 역할을 사용하면, 통제 불능의 쿼리가 발생할 경우 최악의 시나리오는 테이블 삭제가 아니라 느린 읽기 작업입니다.

레이어 4: 인간 개입 게이트(human-in-the-loop gate)

모델이 아무리 뛰어나더라도 제가 절대 자동화하지 않는 위험한 행동들이 몇 가지 있습니다. 이들은 항상 저를 멈추게 합니다:

스키마 마이그레이션 및 drop, truncate와 같은 파괴적 DDL(Data Definition Language)
프로덕션 데이터를 변경하는 삭제, 업데이트 또는 기타 작업
배포(deploy), 릴리스, 인프라 변경 사항
강제 푸시(force-push) 및 히스토리 재작성
비용이 발생하거나 실제 사용자에게 메시지를 보내는 모든 것

이 짧은 목록에 대한 규칙은 에이전트가 채팅에서 작성하는 요약본이 아니라 실제 diff와 명령어 출력을 읽는 것입니다. 저는 이전에 서사에 의존했다가 피해를 본 적이 있습니다. 깨끗한 git 트리가 제가 설명할 수 없는 작업을 숨기고 있을 때였고, diff를 읽는 것이 그것을 잡아냈을 겁니다. 같은 경주 문구가 여기에 적용됩니다. 느림은 부드럽고, 부드러움은 빠릅니다.

속도 유지하기(keeping the speed)

이 모든 것을 마찰의 벽으로 읽기 쉽지만, 실제로는 정반대입니다. 위에 언급된 거의 모든 가드레일은 영구적으로 보상하는 일회성 설정입니다. 에디터 설정, 브랜치 규칙, 읽기 전용 역할, 그리고 짧은 게이트 목록은 한 번 작성되면 그저 유지됩니다. 이들은 거짓 경보를 울리지 않기 때문에, 실제로 되돌리기 어려운 희귀한 행동에 대해서만 저를 중단시킵니다. 제 하루 대부분을 채우는 지속적이고 가역적인 작업은 이들 중 어느 것에도 영향을 미치지 않습니다.

그것이 저에게 있어 차선 준수(lane discipline)를 동반한 속도라는 의미입니다. 저는 에이전트에게 더 느려지거나 자율성을 낮추라고 요구하는 것이 아닙니다. 저는 에이전트의 속도가 제가 언제든 회복할 수 있는 방향으로 달릴 수 있도록 차선을 그리고 있는 것입니다. 저는 이러한 종류의 의도를 도구(tools)에 직접 인코딩하는 방법에 대해 how to use ai to create ai rules, skills, and commands라는 글에서 다룬 적이 있으며, 여기서 말하는 가드레일(guardrails)은 동일한 아이디어의 안전 필수적(safety-critical) 버전입니다.

FAQ

이 가드레일들이 에이전트의 속도를 늦추나요?

대부분 그렇지 않습니다. 안전하고 가역적인(reversible) 명령들은 화이트리스트(allowlisted)에 등록되어 중단 없이 실행되며, 오직 실제로 되돌리기 어려운 소수의 작업들만이 중단됩니다. 마찰(friction)은 정확히 제가 원하는 곳에 집중되어 있으며, 그 외의 모든 곳에서는 존재하지 않습니다.

단 하나의 가드레일만 설정할 수 있다면, 무엇을 선택해야 할까요?

운영 환경(production)에 접근할 수 없는 읽기 전용(read-only) 데이터베이스 자격 증명(credentials)입니다. 명령(command)이나 브랜치(branch) 실수는 대개 복구 가능하지만, 실제 데이터에 대한 파괴적인 쓰기(destructive write)는 복구가 불가능한 경우가 많으므로, 쓰기 권한을 제거하는 것이 최악의 결과를 가장 먼저 방지하는 방법입니다.

제가 지켜보지 않는 상태에서 실행되는 완전 자율 에이전트(fully autonomous agents)는 어떻게 하나요?

관문(gate)은 폭발 반경(blast radius)에 따라 규모가 조절됩니다. 제가 더 많은 자율성을 부여할수록 가드레일은 더 엄격해져야 하며, 이는 보통 샌드박스 환경(sandboxed environment), 운영 환경 자격 증명의 완전한 배제, 그리고 저의 주의력(attention)이 아닌 플랫폼에 의해 강제되는 불가역적 작업 목록(irreversible-action list)을 의미합니다.