AI에게 코드를 작성하게 하는 이야기는 이제 꽤 흔해졌다.

하지만 AI에게 명령(Command)을 실행하게 하는 이야기가 되면 풍경이 달라진다. git diff를 읽는 정도라면 아직 괜찮다. rm도 실행할 수 있다. 환경 변수도 읽을 수 있다. 네트워크에도 접속할 수 있다. CI를 실행하고, 의존성을 설치하며, 파일을 수정하고, 때로는 개발자 본인보다 빠르게 작업 트리(Working Tree)를 바꿔버린다.

이 단계에서 프롬프트(Prompt)에 "중요한 파일은 삭제하지 마세요"라고 적는 것은 상당히 불안하다.

물론 모델(Model)에 대한 지시는 필요하다. 하지만 그것은 안전장치가 아니다. 오히려 작업 방침에 대한 메모에 가깝다. 실제로 사고를 막는 것은 프롬프트가 아니라, 실행 환경의 경계(Boundary)이다.

똑똑한 AI일수록, 멈추는 방법을 먼저 설계한다

코딩 에이전트(Coding Agent)의 가치는 단순히 "보완을 잘한다"는 것에 있지 않다. 스스로 조사하고, 스스로 파일을 편집하며, 스스로 테스트를 실행하는 데 있다.

즉, 편리함의 원천은 곧 리스크의 원천이기도 하다.

인간이 매번 명령어를 선택하던 시대에는 위험한 조작 직전에 인간의 개입이 있었다. 에이전트의 경우, 그 전 단계의 판단을 모델이 상당 부분 대신한다. 따라서 안전성을 "모델이 제대로 판단해 줄 것이다"에 의존하면 설계로서 취약하다.

필요한 것은 AI를 믿는 것이 아니라, AI가 실수하더라도 망가지지 않는 실행 면을 만드는 것이다.

예를 들어 다음과 같은 경계가 있다.

• 쓰기 권한이 있는 디렉토리를 한정한다
• 네트워크 액세스를 원칙적으로 차단한다
• 파괴적인 명령어에는 승인 절차를 넣는다
• 실행 전후의 훅(Hook)으로 명령어와 차분(Diff)을 검사한다
• 감사 로그(Audit Log)를 남겨 나중에 추적할 수 있게 한다

모두 화려한 기술은 아니다. 하지만 이러한 경계가 없는 상태에서 에이전트를 개발 흐름(Workflow)에 도입하는 것은, SSH 키를 넘겨준 외부 위탁자에게 "운영 환경(Production)만은 건드리지 말아줘"라고 구두로 부탁하는 것과 같다.

프롬프트는 논리적인 제어일 뿐이다

프롬프트를 통한 제어는 기본적으로 "부탁"이다.

"이 디렉토리는 건드리지 마"
"네트워크에는 나가지 마"
"사용자의 승인 없이 삭제하지 마"

이것들은 방침으로서는 옳다. 하지만 방침과 강제는 다르다.

모델은 문맥(Context)을 잘못 읽는다. 도구 호출(Tool Call)의 추상도에 따라 위험한 부작용(Side Effect)이 잘 보이지 않을 수도 있다. 생성된 셸 명령어(Shell Command)가 언뜻 무해해 보여도, 현재 디렉토리나 glob 전개 방식에 따라 피해 범위가 달라진다.

그러므로 프롬프트에 금지 사항을 적지 말라는 뜻이 아니다. 거기에 안전성을 맡기지 말라는 뜻이다.

정말로 금지하고 싶다면 OS, 컨테이너(Container), 샌드박스(Sandbox), 권한, 네트워크 정책, 훅(Hook)으로 막아야 한다. 모델이 "하지 않기"를 기대하기보다, 실행 환경이 "할 수 없게" 만드는 것. 여기에 결정적인 차이가 있다.

훅(Hook)은 AI 시대의 pre-commit이 아니라 실행 게이트(Execution Gate)다

Claude Code의 Hooks나 권한(Permission) 설계가 흥미로운 점은, AI의 행동을 대화만으로 제어하려고 하지 않는다는 점에 있다.

특정 타이밍에 훅을 실행한다. 실행 전에 명령어를 검사한다. 허가되지 않은 조작을 차단한다. 필요하다면 인간의 승인 단계로 되돌린다.

이는 기존의 pre-commit이나 CI와 비슷하지만, 대상이 조금 다르다. pre-commit은 인간이 만든 변경 사항을 커밋 전에 검사한다. 에이전트의 실행 게이트는 AI가 환경을 바꾸기 전에 막는다.

순서가 앞당겨지는 것이다.

이 부분을 놓치면 리뷰는 그저 사후 처리(Cleanup)가 되어버린다. AI가 빠르게 움직일수록 사후 처리도 빠르게 쌓인다. 생성된 코드의 품질만 보고 있으면 이 병목 현상(Bottleneck)을 간과하게 된다.

실무에서 중요해지는 것은 아마 다음과 같은 설계일 것이다.

• 읽기 전용 작업과 쓰기를 동반하는 작업을 분리한다
• 테스트 실행은 허용하되, 외부 네트워크는 차단한다
• package install이나 migration과 같은 환경 변경은 승인제로 운영한다
• 비밀 정보를 포함한 파일은 처음부터 읽을 수 없는 곳에 둔다
• 에이전트마다 작업 트리나 브랜치(Branch)를 분리한다

이것은 프롬프트 엔지니어링(Prompt Engineering)이라기보다, 거의 인프라 설계에 가깝다.

모든 것을 에이전트에게 맡길 필요는 없다

또 하나, 사소하지만 중요한 논점이 있다. 에이전트에게 시켜야 할 일과 일반적인 도구로 끝내야 할 일을 나누는 것이 좋다.

예를 들어 이미지 생성 관련 후처리라면, 매번 에이전트에게 파일을 읽게 하고, 스크립트를 작성하게 하고, 출력을 확인하게 할 필요가 없는 경우가 있다. Gemini로 만든 이미지의 워터마크 제거처럼 용도가 한정되어 있다면, Gemini Watermark Remover와 같이 브라우저 측에서 완결되는 전용 도구로 한정하는 것이 권한 측면에서 다루기 쉽다.

이것은 홍보를 하는 것이 아니라, 경계(Boundary)에 대한 이야기다.

범용 에이전트(General-purpose agent)는 강력하다. 하지만 강력하다는 것은 불필요한 일도 할 수 있다는 뜻이다. 단일 기능 도구로 해결될 일이라면 단일 기능 도구에 가두어야 한다. CLI로 해결될 일이라면 CLI에 가두어야 한다. 에이전트가 필요할 때만 최소 권한(Least privilege)으로 동작하게 해야 한다.

AI 시대의 워크플로(Workflow) 설계는 "무엇을 AI에게 맡길 것인가"만으로는 부족하다. "어느 범위까지 맡기지 않을 것인가"를 결정하는 설계이기도 하다.

조직에서 사용한다면, 이것은 더 이상 개인용 CLI가 아니다

개인이 로컬(Local)에서 테스트하는 정도라면 다소 거칠어도 돌아간다. 실패하더라도 자신의 작업 트리(Working tree)가 망가지는 정도로 끝나는 경우가 많다.

하지만 조직의 코드베이스(Codebase)에 들어오면 이야기가 달라진다.

강력한 권한을 가진 토큰(Token), 사내 네트워크, 고객 데이터에 근접한 설정 파일, CI 실행 권한, 배포 플로(Deployment flow). 에이전트는 이들 근처에서 동작한다. 게다가 인간보다 빠르고, 지치지 않으며, 거리낌 없이 명령어를 시도한다.

여기서 필요한 것은 "AI 이용 가이드라인"만이 아니다. 물론 가이드라인도 필요하다. 하지만 그보다 앞서 실행 경계(Execution boundary)가 존재해야 한다.

구체적으로는 다음과 같은 질문에 답할 수 있어야 한다.

• 해당 에이전트는 어떤 파일을 읽을 수 있는가
• 어디에 쓸 수 있는가
• 어떤 명령어를 실행할 수 있는가
• 네트워크로 나갈 수 있는가
• 비밀 정보에 접근했을 가능성을 어떻게 탐지할 것인가
• 누가 어떤 조작을 승인한 것이 되는가
• 실패했을 때 어디까지 되돌릴 수 있는가

이것은 SRE나 보안 담당자만이 고민해야 할 문제가 아니다. 에이전트를 일상적으로 사용하는 개발자 스스로가 갖추어야 할 최소한의 설계 감각이 되어가고 있다.

"AI를 어떻게 사용할 것인가"에서 "AI를 어디서 멈출 것인가"로

한동안 AI 코딩에 관한 논의는 "어떤 모델이 똑똑한가", "어떤 도구가 빠른가"에 너무 치우쳐 있었다고 생각한다.

물론 성능은 중요하다. 느리고 정답을 맞히지 못하는 에이전트는 사용하기 어렵다.

다만, 에이전트가 정말로 실무에 도입되면 마지막에 결정적인 역할을 하는 것은 속도만이 아니다. 오히려 빠른 것을 안전하게 멈추는 메커니즘이 더 중요해진다.

자동차의 속도가 빨라졌다고 해서 브레이크가 필요 없어지는 것은 아니다. AI 에이전트도 마찬가지다. 능력이 향상될수록 브레이크, 가드레일(Guardrail), 그리고 달려도 되는 길에 대한 설계가 필요하다.

프롬프트(Prompt)가 핸들을 잡는 법을 가르치는 것이라면, 샌드박스(Sandbox)와 권한 설계는 도로 그 자체를 설계하는 것이다.

앞으로의 개발자에게 필요한 것은 AI에게 말을 잘 거는 기술만이 아니다. AI가 실수하더라도, 혹은 빠르더라도, 멋대로 선을 넘지 못하도록 경계를 만드는 기술이다.

AI 에이전트는 편리한 파트너에서 관리해야 할 실행 주체가 되었다. 그렇다면 물어야 할 것은 하나다.

"이 AI는 무엇을 할 수 있는가"가 아니라, "이 AI는 무엇을 절대로 할 수 없도록 만들어 두었는가".

그 질문에 답할 수 있을 때, 비로소 실무에서 사용할 수 있는 도구가 된다.

Source notes

Discussion