최근 OpenAI와 Anthropic의 사이버보안 평가 사건은 “AI가 통제를 벗어났다”는 이야기로 쉽게 소비됩니다. 하지만 더 유용한 질문은 좁습니다. 평가 환경이 모델에게 어떤 권한을 줬고, 어떤 경계가 작동하지 않았을까요?
두 시스템은 모델에게 목표를 주고, 목표를 달성하는 데 사용할 수 있는 인터넷·계정·도구를 연결했습니다. 공개 보고서는 해당 평가에서 일어난 일을 설명하지만, 모든 에이전트가 실제 운영 환경에서 같은 방식으로 행동한다고 증명하지는 않습니다. 대신 프롬프트가 권한 시스템이 될 수 없는 이유는 보여줍니다.
“인터넷에 접근하지 마라”라고 프롬프트에 적는 것과 실제로 네트워크 접근을 차단하는 것은 전혀 다릅니다. 에이전트의 안전성은 모델뿐 아니라 네트워크 정책·주체의 신원·도구 권한·로그·승인 관문·중단 장치가 포함된 실행 환경에서 결정됩니다.
사건의 공통점은 권한 문제입니다
에이전트가 행동하려면 적어도 목표·능력·경계가 필요합니다. 목표는 무엇을 이루려는지 말하고, 능력은 어떤 시스템과 도구에 닿을 수 있는지 정합니다. 경계는 무엇을 하면 안 되는지, 언제 물어야 하는지, 실행이 어떻게 끝나는지를 정합니다.
| 층위 | 답해야 할 질문 | 흔한 실패 |
|---|---|---|
| 목표 | 에이전트가 책임질 결과는 무엇인가? | 넓은 목표가 임의 행동의 허가로 바뀝니다. |
| 능력 | 필요한 계정·파일·네트워크·도구는 무엇인가? | 작업보다 많은 시스템에 접근할 수 있습니다. |
| 경계 | 승인·시간 제한·강제 중단이 필요한 지점은 어디인가? | 프롬프트의 경고가 실제 행동을 막아줄 것으로 기대합니다. |
| 증거 | 무슨 일이 있었는지 어떤 기록이 보여주는가? | 최종 답변 뒤에 도구 호출과 상태 변경이 숨습니다. |
공개된 평가 보고서는 실행 환경도 안전성 논의의 일부로 만듭니다. 출처: Anthropic
보고서에서 얻을 실무 교훈은 모델을 무조건 더 똑똑하게 만드는 것이 정답은 아니라는 점입니다. 더 좁은 네트워크 범위, 별도 신원, 읽기 전용 도구, 승인 단계, 불완전한 산출물을 거부하는 검증기가 더 직접적인 해법일 수 있습니다.
복잡한 하네스가 항상 좋은 것은 아닙니다
저는 하네스와 루프 엔지니어링 방식을 적용해보면서 비슷한 문제를 느꼈습니다. 계획을 세우고, 일을 나누고, 여러 에이전트에게 위임하고, 결과를 검토하고, 실패하면 재시도하고, 중간 결과를 요약하는 과정은 각각 그럴듯했습니다. 하지만 기능을 하나씩 붙이자 실제 작업보다 프로세스가 더 커졌습니다.
시간과 토큰을 계속 빨아먹는 하마처럼 느껴질 때도 있었습니다.
AP 보도는 사건의 맥락을 보여주지만, 1차 평가 기록을 대신하지는 않습니다. 출처: AP News
그래서 지금은 대부분의 과정을 걷어내고 제 작업에 맞는 간단한 하네스를 실험하고 있습니다. 이것은 통제된 생산성 실험의 결과가 아니라 설계 판단입니다. 단순한 하네스도 넓은 자격증명을 노출하거나 중단 조건이 없으면 더 쉽게 운영되는 만큼 더 쉽게 오용될 수 있습니다.
작은 하네스도 반드시 분명히 해야 할 것
플래너나 리뷰어를 하나 더 붙이기 전에 먼저 권한 경계를 확인해야 합니다.
- 각 도구가 이번 작업에 필요한 파일·서비스·네트워크만 볼 수 있는가?
- 권한을 철회할 수 있는 별도 신원을 사용하는가?
- 외부 변경과 되돌리기 어려운 동작을 사람 승인 뒤에 두었는가?
- 시간·재시도·토큰 예산이 숨지 않고 보이는가?
- 요청·도구 호출·결과·변경 산출물을 검토자가 확인할 수 있는가?
- 실패할 때 접근 권한을 넓히지 않고 제한된 오류를 반환하는가?
그래서 에이전트 설계는 조직 설계보다 권한 설계에 가깝다고 생각합니다. 인간 조직은 큰 사회적 시스템 안에서 협업하기 때문에 역할이 필요합니다. 작은 에이전트 작업에는 실제 통제나 증거 경계를 만드는 역할만 있으면 됩니다. 인간 조직에 존재하는 역할을 그대로 붙인다고 안전해지는 것은 아닙니다.
권한을 작게 설계하는 순서
권한 경계를 실제 작업에 적용할 때는 에이전트에게 한 번에 “작업 전체”를 맡기지 않는 편이 설명하기 쉽습니다. 예를 들어 저장소의 버그를 고치는 작업이라면 다음처럼 단계를 나눌 수 있습니다.
| 단계 | 허용하는 권한 | 남겨야 할 증거 |
|---|---|---|
| 조사 | 관련 파일 읽기와 테스트 실행 | 읽은 범위, 실행한 명령, 테스트 결과 |
| 제안 | 변경 계획과 패치 초안 작성 | 바뀔 파일, 변경 이유, 예상 영향 |
| 승인 | 사람의 확인을 받은 변경만 적용 | 승인자, 승인 시각, 승인된 범위 |
| 검증 | 제한된 환경에서 테스트·검사 실행 | 로그, 생성된 산출물, 실패 원인 |
| 종료 | 자격증명 회수와 임시 파일 정리 | 권한 회수 여부, 최종 상태 |
이 흐름에서 에이전트는 먼저 읽을 수 있지만 바로 외부 시스템에 쓰지는 못합니다. 네트워크가 필요하지 않은 단계에서는 네트워크를 차단하고, 배포나 데이터 변경처럼 되돌리기 어려운 행동에는 별도의 승인 토큰을 요구할 수 있습니다. 승인 토큰도 작업·시간·대상에 묶어야 하며, “이번 세션 동안 모든 작업 허용”처럼 넓게 발급하면 처음 세운 경계가 다시 사라집니다.
실패 처리도 권한 설계의 일부입니다. 테스트가 실패했을 때 에이전트가 자동으로 더 많은 파일이나 서비스를 열어 달라고 요청하는 대신, 현재 범위에서 실패 이유와 사람이 확인할 질문을 반환하도록 해야 합니다. 그러면 재시도 횟수는 늘어도 권한 범위가 조용히 커지지는 않습니다. 이 예시는 보편적인 구현 정답이나 생산성 측정 결과가 아니라, 권한을 프로세스보다 먼저 검토하기 위한 설계 단위입니다.
이 글이 증명하지 않는 것
인용한 사건은 각자의 목표·도구·조건을 가진 평가 환경에서 일어났습니다. 그 수치를 개발자나 모델이 일상 업무에서 같은 비율로 실패한다는 주장으로 옮겨서는 안 됩니다. 제가 단순화한 하네스가 오케스트레이션이 나쁘다는 증거도 아닙니다. 확인 가능한 결론은 더 실용적입니다. 프로세스를 최적화하기 전에 권한을 먼저 정해야 합니다.
작은 목표, 제한된 권한, 짧은 피드백 루프, 명확한 중단 지점이 아무도 안전 이유를 설명할 수 없는 복잡한 워크플로보다 좋은 출발점입니다. 에이전트가 강해질수록 물어야 할 것은 무엇을 할 수 있는지만이 아닙니다. 어떤 행동을 허가받았고, 멈춘 뒤 어떤 증거가 남는지도 물어야 합니다.
