AI 코딩·자동화 에이전트를 저장소에 연결하는 일은 단순히 실행 권한을 주는 문제가 아니다. 먼저 정할 것은 “무엇을 읽을 수 있는가, 무엇을 바꿀 수 있는가, 언제 멈추는가, 누가 승인하는가, 무엇으로 변경을 증명하는가”다. 안전한 도입의 목표는 에이전트의 선언을 신뢰하는 것이 아니라, 제한된 범위에서 재현 가능하게 일하도록 workflow를 만드는 데 있다.

자동화할 작업보다 먼저, 작업 경계를 문서화한다

모호한 “수정해 달라”는 요청 대신 작업 계약을 만든다. 계약에는 목표, 참조할 맥락, 허용·금지 범위, 완료 기준을 넣고, 복잡한 작업은 변경 전 계획을 먼저 제출하게 한다. 저장소별 명령, 금지 규칙, 검증 절차는 지속 지침으로 관리할 수 있다. 변경이 끝난 뒤에도 테스트, lint·type check, 실제 동작 및 diff 검토가 완료 기준에 포함돼야 한다. [1]

이때 요청 원문, 승인된 계획, 변경 대상, 결정 근거를 분리해 기록한다. 보안 요구사항과 위험·설계 결정, 릴리스 provenance 및 무결성 검증 자료를 보존하는 원칙은 이런 기록 설계의 기준이 된다. 다만 이는 AI 에이전트 전용 표준이 아니라 안전한 개발 운영의 일반 원칙이다. [2]

Sandbox와 human approval gate를 같은 말로 쓰지 않는다

읽기 전용 조사, 승인된 변경, 하드 스톱 경계를 샌드박스와 구분한 제어 도식
샌드박스는 실행 범위이고 human gate는 변경 권한을 부여하는 별도 통제다.

Sandbox는 에이전트가 기술적으로 할 수 있는 일을 제한한다. 반면 approval policy는 sandbox 경계를 넘는 행위를 누가, 어떤 조건에서 승인할지 정한다. 둘 중 하나가 다른 하나를 대체하지 않는다. [3]

예를 들어 제한된 workspace의 조사·편집은 routine 작업으로 둘 수 있지만, network 사용이나 외부 시스템 쓰기는 경계 밖 행동으로 분류해 approval flow로 넘길 수 있다. 실행 범위를 먼저 제한하면, 매 행동마다 사람의 판단을 요구하는 방식보다 승인 피로를 줄이면서도 책임 경계를 분명히 할 수 있다. [4] [3]

권장 순서: 읽기 전용 조사에서 승인까지

실무 흐름은 다음처럼 권한을 단계적으로 넓히는 편이 낫다.

  1. Read-only preflight: 코드, 문서, 기존 테스트와 현재 상태를 읽고 영향 범위와 불확실성을 보고한다.
  2. Bounded mutation: 승인된 파일·workspace·작업 범위 안에서만 변경한다.
  3. Independent verification: 에이전트의 완료 보고와 별개로 결정론적 검사와 diff 검토를 수행한다.
  4. Rollback checkpoint: 변경 전에 되돌릴 수 있는지 확인하고 복구 지점을 남긴다.
  5. Human approval: 외부 write, network, 유료 호출, 운영 영향, 파괴적 작업은 명시적 승인 뒤에만 진행한다.

권한이 없거나 정체성이 일치하지 않는 경우, 요청 범위를 벗어난 경우, 예상치 못한 외부 영향이 생긴 경우에는 계속 추론해 우회하기보다 중단하고 escalation해야 한다. [3]

검증은 에이전트의 보고가 아니라 독립된 증거로 한다

“완료했습니다”는 증거가 아니다. 변경 결과는 Git diff, 검토 가능한 PR 상태, 테스트 결과로 확인한다. CI는 저장소 변경마다 build, lint, security, functional test 같은 자동 검사를 실행하고 그 결과를 PR 검토 증거로 제공할 수 있다. [5]

그러나 녹색 CI만으로 충분하다고 결론 내리면 안 된다. 어떤 위험을 어떤 테스트가 덮는지는 사람이 설계한다. 따라서 검증 계획에는 정상 경로뿐 아니라 요구사항 불일치, 권한 오류, 경계 밖 영향처럼 해당 변경의 위험에 맞는 검토 범위를 포함해야 한다. CI는 중요한 증거이지만 모든 보안·운영 위험의 완전한 증명은 아니다. [5]

Source of truth와 감사 흔적을 변경물과 함께 남긴다

사후에 “왜 이 변경이 허용됐는가”를 답할 수 있어야 한다. source of truth를 정하고, 요청·계획·범위·승인·diff·검증 결과·릴리스 관련 무결성 자료를 연결해 보관한다. 이는 재현, 검토, 책임 추적을 위한 별도 통제다. [2]

기록을 남긴다고 해서 민감정보까지 남겨서는 안 된다. secret은 prompt, 로그, command argument에 넣지 않으며, redaction을 workflow에 포함한다. 감사 흔적은 충분해야 하지만 credential이나 고객 데이터를 복제하는 통로가 되어서는 안 된다.

복구 가능성과 stop condition이 자율성의 상한을 정한다

rollback은 실패 후에 떠올릴 기능이 아니라 변경 전에 확인할 조건이다. 되돌릴 수 없는 변경이라면 승인 기준을 더 엄격하게 두거나, 먼저 가역적인 단계로 쪼개야 한다. 외부 write, network 접근, 유료 서비스 호출, 운영 환경 영향, 파괴적 작업은 모두 명시적 승인 경계로 다룬다.

결국 AI Agent 도입의 핵심은 더 넓은 자율권이 아니다. 읽기, 제한된 변경, 독립 검증, 복구, 승인을 분리하고 각 단계의 권한·증거·중단 조건을 합의하는 일이다. 사람이 위험 기준과 테스트 범위를 설계하고, 에이전트는 그 경계 안에서만 일할 때 자동화는 통제 가능한 engineering system이 된다.

References

  1. OpenAI — Codex Best Practices — https://learn.chatgpt.com/guides/best-practices.md
  2. National Institute of Standards and Technology — NIST SP 800-218 Secure Software Development Framework 1.1 — https://csrc.nist.gov/pubs/sp/800/218/final
  3. OpenAI — Agent approvals & security — https://learn.chatgpt.com/docs/agent-approvals-security.md
  4. OpenAI — Codex Sandbox — https://learn.chatgpt.com/docs/sandboxing.md
  5. GitHub — Continuous integration with GitHub Actions — https://docs.github.com/en/actions/get-started/continuous-integration