AI 에이전트에게 필요한 것은 자율성 연극이 아니라 승인 경계입니다

대부분의 팀은 코딩 에이전트에 대해 잘못된 질문을 던지고 있습니다.

흥미로운 질문은 "이것이 얼마나 자율적일 수 있는가?"가 아닙니다. "누가 이것에게 권한을 부여했는가, 이것이 무엇을 건드릴 수 있는가, 그리고 이것이 틀렸을 때 어떤 일이 발생하는가?"입니다.

이것은 덜 흥미롭게 들릴 수 있습니다. 좋습니다. 흥미로운 것이란 사양(spec)을 작성하고, 리포지토리(repo)를 편집하고, 도구(tool)를 호출하고, 브라우저를 열고, 디프(diff)를 푸시한 다음, 모호하게 "작업을 완료했습니다"라고 주장하는 봇을 만드는 방식입니다. 그것은 엔지니어링 워크플로우(engineering workflow)가 아닙니다. 그것은 셸 액세스(shell access) 권한을 가진 상태에서 벌이는 신뢰 게임(trust fall)입니다.

생성된 작업은 이제 저렴합니다. 승인(Approval)은 여전히 비쌉니다. 두 번째 부분을 파악하는 기업이 끊임없이 더 똑똑한 모델을 찾아 쇼핑하는 기업보다 에이전트로부터 더 많은 가치를 얻게 될 것입니다.

어려운 부분은 생성이 아니라 권한입니다

AIEOS에 관한 최근 DEV.to의 글은 명확한 지점을 짚어줍니다: AI는 사양(spec)을 작성할 수 있지만, 그것을 승인할 수는 없습니다. 이 구분은 고개를 끄덕이며 동의하기는 쉽지만, 실제로는 놀라울 정도로 위반하기 쉽습니다.

여러분은 어디에서나 이러한 위반을 볼 수 있습니다:

• 모델이 계획을 작성하고 그 계획이 좋은지 스스로 판단함
• 에이전트가 코드를 변경하고 왜 그 변경이 안전한지 요약함
• 동일한 실행(run) 내에서 아티팩트(artifact)를 생성하고 다음 단계로 넘어갈 준비가 되었는지 결정함
• 도구가 먼저 조치를 취하고 인간이 나중에 무슨 일이 일어났는지 재구성하도록 남겨둠

이것은 사소한 프로세스 악취(process smell)가 아닙니다. 이것은 핵심적인 실패 모드(failure mode)입니다.

만약 에이전트가 사양(spec)을 작성한다면, 생성기(generator) 외부의 무언가가 그 사양이 수용 가능한지 결정해야 합니다. 만약 에이전트가 코드를 변경한다면, 해당 실행(run) 외부의 무언가가 그 디프(diff)가 배포 가능한지 결정해야 합니다. 만약 에이전트가 프로덕션 인접 시스템, 자격 증명(credentials), 의존성(dependencies), 워크플로우(workflows) 또는 고객 대면 자산에 접근하기를 원한다면, 조치가 일어나기 전에 승인 경로가 명시적이어야 합니다.

그렇지 않으면 "에이전트 기반 개발(agentic development)"은 단지 리뷰를 건너뛰는 더 비싼 방법이 될 뿐입니다.

프롬프트 신뢰보다 역량 인벤토리가 낫습니다

프롬프트(Prompts)는 유용합니다. 하지만 프롬프트는 권한 시스템(permission systems)이 아닙니다.

실질적인 조치는 에이전트가 실제로 무엇을 할 수 있는지 인벤토리(Inventory)를 작성하는 것입니다. 전체 리포지토리(Repo)를 읽을 수 있나요? 어디든 쓸 수 있나요? 셸 명령(Shell commands)을 실행할 수 있나요? 브라우저 세션(Browser session)을 사용할 수 있나요? 내부 API를 호출할 수 있나요? 패키지를 설치할 수 있나요? 브랜치를 푸시(Push)할 수 있나요? 메시지를 보낼 수 있나요? 콘텐츠를 게시할 수 있나요? 이미지 에셋(Image assets)을 건드릴 수 있나요? 고객 데이터를 열람할 수 있나요?

일단 목록이 존재하면, 제어 시스템(Control system)의 형태는 훨씬 덜 신비로워집니다:

• 저위험 작업(Low-risk actions)은 자동으로 실행될 수 있습니다.
• 중위험 작업(Medium-risk actions)은 가시적인 체크포인트(Checkpoint)가 필요할 수 있습니다.
• 고위험 작업(High-risk action)은 별도의 승인자(Approver)가 필요합니다.
• 모든 중대한 작업(Consequential action)은 감사 추적(Audit trail)을 남겨야 합니다.

이것이 MakerChecker와 같은 프로젝트들이 비록 초기 단계일지라도 흥미로운 이유입니다. 유용한 아이디어는 "이 리포지토리 하나가 에이전트 거버넌스(Agent governance)를 해결했다"가 아닙니다. 그것은 바로 패턴입니다: 기본 거부(Deny-by-default) 역할, 관리되는 도구(Governed tools), 인간의 승인(Human approvals), 직무 분리(Segregation of duties), 그리고 서명된 감사 추적(Signed audit trails)입니다.

그것이 올바른 방향입니다. 모든 사이드 프로젝트에 엔터프라이즈 거버넌스(Enterprise governance)가 필요하기 때문이 아닙니다. 팀들에게는 "프롬프트가 조심하라고 말했어"라는 말보다 더 구체적인 무언가가 필요하기 때문입니다.

이제 '에이전트'라는 라벨은 거의 무용지물입니다

Product Hunt에서는 모든 제품이 갑자기 "AI 에이전트"가 되고 있는 것인지에 대한 토론이 있었습니다. 대답은 기본적으로 "예"입니다. 적어도 마케팅 용어 측면에서는 그렇습니다.

하지만 이제 "에이전트"라는 말은 당신에게 많은 것을 알려주지 않습니다.

어시스턴트(Assistant)는 제안합니다. 자동화(Automation)는 미리 정의된 경로를 실행합니다. 에이전트(Agent)는 컨텍스트(Context)를 파악하고, 행동을 선택하며, 도구를 사용하고, 작업 결과물을 가져옵니다. 마지막 카테고리에서 리스크의 성격이 변하는데, 이는 시스템이 텍스트 생성(Text generation)에서 워크플로 실행(Workflow execution)으로 이동했기 때문입니다.

유용한 제품 관련 질문은 어떤 것이 에이전트라는 라벨을 달 자격이 있느냐가 아닙니다. 유용한 질문은 자율성(Autonomy)이 어디에서 멈추느냐입니다.

사용자가 제안된 행동이 일어나기 전에 볼 수 있나요? 시스템이 이를 되돌릴 수 있나요? 다른 역할이 이를 승인할 수 있나요? 팀이 어떤 도구 호출(Tool calls)이 왜 발생했는지 알 수 있나요? 검토자(Reviewer)가 방대한 양의 생성된 작업 대신 작은 디프(Diff)를 검사할 수 있나요?

만약 대답이 "아니오"라면, 당신은 에이전트 워크플로를 가진 것이 아닙니다. 당신은 폭발 반경(Blast radius)을 가진 데모를 가지고 있는 것입니다.

개발자 머신은 이미 너무 강력합니다

여기서는 보안적 배경이 중요합니다.

개발자 워크스테이션(Workstation)은 패키지 매니저(Package managers), 확장 프로그램 생태계(Extension ecosystems), API 키, 로컬 자격 증명(Local credentials), Git 원격 저장소(Git remotes), 셸 히스토리(Shell history), 브라우저 세션, 프라이빗 저장소(Private repos), 내부 문서 등 조용한 권한들로 가득 차 있습니다. 공급망 사고(Supply-chain incidents)는 개발자 머신이 결코 해롭지 않은 로컬 놀이터가 아니라는 사실을 계속해서 상기시켜 줍니다.

에이전트(Agents)는 그 공격 표면(Surface)을 더 빠르게 만듭니다.

에이전트가 의존성 위험(Dependency risk)을 만들어내는 것은 아닙니다. 그것을 가속화할 뿐입니다. 에이전트가 나쁜 확장 프로그램 동작을 만들어내는 것도 아닙니다. 그것은 IDE를 상속받는 것입니다. 에이전트가 부실한 검토(Review)를 만들어내는 것도 아닙니다. 검토 과정에서 놓치게 될 더 많은 작업량을 생성할 뿐입니다.

이것이 바로 지루한 마찰(Friction)이 하나의 기능(Feature)이 되고 있는 이유입니다. 2시간의 확장 프로그램 업데이트 지연은 지루하게 들릴 수 있지만, 즉각적인 전파(Propagation)가 공격자에게는 선물과 같기 때문에 지루한 통제 장치가 존재하는 경우가 많다는 점을 기억한다면 이야기가 달라집니다. 동일한 논리가 에이전트에도 적용됩니다. 좋은 승인 게이트(Approval gate)는 기본적으로 관료주의가 아닙니다. 때로는 그것은 단지 회로 차단기(Circuit breaker)일 뿐입니다.

출력을 단순히 인상적이게 만드는 것이 아니라, 검토 가능하게 만드세요

제가 본 가장 유용한 에이전트 시스템이자, 가장 빠르게 신뢰하게 된 시스템들은 작은 산출물(Artifacts)을 만들어냅니다.

작은 계획(Plans). 작은 차이(Diffs). 작은 명령 로그(Command logs). 작은 생성 자산(Generated assets). 작은 검토 패킷(Review packets).

거대한 자율 실행(Autonomous runs)은 디버깅을 해야 하기 전까지는 환상적으로 느껴집니다. 하지만 디버깅을 시작하면 "에이전트가 작업을 완료했습니다"라는 말이 매우 무의미하다는 것을 깨닫게 됩니다. 어떤 단계를 완료했나요? 어떤 가정(Assumptions)을 바탕으로 했나요? 어떤 파일을 읽은 후인가요? 어떤 도구 호출(Tool calls)을 사용했나요? 경고를 건너뛰었나요? 실패한 체크를 조용히 우회했나요? 스크린샷을 생성하고, 크기를 조정하여 게시 가능한 곳에 배치했나요, 아니면 그냥 했다고 말만 했나요?

시각적 또는 게시 워크플로 (workflows)의 경우, 그 마지막 단계(last mile)가 중요합니다. 만약 팀이 에이전트에게 릴리스 노트 (release note)를 위한 검토 가능한 스크린샷이나 소셜 에셋 (social assets)을 준비하라고 요청한다면, Resize Image For와 같은 브라우저 로컬 유틸리티는 패킷 내의 지루한 한 단계가 될 수 있습니다. 즉, 결과물 (artifact)의 크기를 조정하고, 소스 이미지를 로컬에 보존하며, 출력물을 검사하기 쉽게 만드는 것입니다. 이것은 워크플로의 중심이 아닙니다. 검토 과정을 정상적으로 유지해 주는 결과물 경계 (artifact boundary)의 구체적인 예시일 뿐입니다.

생성된 인터페이스 (interfaces)에도 동일한 원칙이 적용됩니다. 만약 에이전트 UI (agentic UI), 컴포넌트 카탈로그 (component catalogs), 또는 생성형 인터페이스 패턴 (generative interface patterns)을 탐색하고 있다면, 근거가 되는 참조 세트 (reference set)를 가까이 두십시오. Awesome Generative UI와 같이 큐레이션된 인덱스는 유용합니다. 왜냐하면 팀이 모든 에이전트 렌더링 UI 아이디어가 새롭다고 가정하지 않고도 논문, 사례, 비디오, 그리고 오픈 소스 리소스를 비교할 수 있게 해주기 때문입니다.

에이전트의 출력물이 검토하기에 충분히 지루할 때, 에이전트를 더 신뢰하기 쉬워집니다.

제어 패턴 (control pattern)의 모습

코딩 에이전트가 진지한 작업을 수행하도록 허용하기 전에, 저는 다음 여섯 가지 질문부터 시작할 것입니다:

1. 어떤 역량 (capabilities)을 가지고 있는가?
2. 기본적으로 거부되는 동작은 무엇인가?
3. 실행 전 승인이 필요한 동작은 무엇인가?
4. 후속 작업이 의존하기 전에 동결 (frozen)되어야 하는 결과물 (artifacts)은 무엇인가?
5. 생성기 (generator) 외부에서 출력을 판단하는 검증기 (validator)는 무엇인가?
6. 실행 후 무슨 일이 일어났는지 증명하는 로그 (log)는 무엇인가?

이것은 무거운 프로세스가 아닙니다. 기본적인 엔지니어링 위생 (engineering hygiene)입니다.

생성된 명세 (spec)는 구현이 시작되기 전에 동결되어야 합니다. 차이점 (diff)은 사람이 검토할 수 있을 만큼 충분히 작아야 합니다. 외부 상태를 변경하는 도구 호출 (tool call)은 게이트 (gated)가 설치되어야 합니다. 고위험 동작은 그것을 요청한 것과 동일한 ID에 의해 승인되어서는 안 됩니다. 검증 실패 (failed validation)는 모델이 합리화하기 위한 또 다른 프롬프트 (prompt)가 되는 대신 흐름을 중단시켜야 합니다.

핵심적인 움직임은 분리 (separation)입니다. 생성기는 이쪽에, 검증기는 저쪽에 둡니다. 경계 (boundary)에서 인간의 승인을 거칩니다. 그 아래에는 감사 추적 (audit trail)을 둡니다.

장난감 같은 작업(toy tasks)을 위해 이를 과하게 구축하지 마세요

반대 방향에도 함정이 있습니다.

모든 에이전트 작업에 거버넌스 플랫폼 (governance platform)이 필요한 것은 아닙니다. 에이전트가 일회성 브랜치 (throwaway branch)에서 로컬 변수 이름을 변경하고 있다면, 그냥 실행하고, 차이점 (diff)을 검토한 뒤 다음으로 넘어가면 됩니다. 마크다운 (Markdown) 형식을 맞추고 있다면, 그것을 준수 절차 (compliance ceremony)로 만들지 마세요.

승인 경계 (Approval boundaries)는 위험도에 맞춰 설정되어야 합니다.

실수는 일부 작업이 무해하다는 이유로 모든 에이전트 작업을 무해한 것으로 취급하는 것입니다. 또 다른 실수는 일부 작업이 위험하다는 이유로 모든 에이전트 작업을 위험한 것으로 취급하는 것입니다. 더 합리적인 버전은 훨씬 더 지루합니다. 역량 (capabilities)을 분류하고, 기본값 (defaults)을 설정하며, 중대한 작업 (consequential actions)에 게이트 (gate)를 설치하고, 작업 내용을 검토 가능한 상태로 유지하는 것입니다.

대부분의 팀이 시작하기에는 이 정도면 충분합니다.

실질적인 테스트

제가 계속해서 되새기는 테스트는 다음과 같습니다:

에이전트가 틀렸을 때, 여러분의 팀이 이를 발견하고, 중단시키고, 되돌리고, 그로부터 배울 수 있습니까?

만약 그렇다면, 여러분은 아마도 워크플로 (workflow)를 갖추고 있는 것입니다.

만약 아니라면, 더 많은 자율성 (autonomy)도 여러분을 구원하지 못할 것입니다. 그것은 단지 실패가 더 빨리 도달하게 만들 뿐입니다.

출처 노트

• Inside AIEOS: AI Can Write the Spec. It Can't Approve It.
• MakerChecker
• Is every product suddenly becoming an "AI agent"?
• Inside the Miasma Software Supply Chain Attack Toolkit
• VS Code Adds 2-Hour Extension Auto-Update Delay to Limit Supply Chain Attacks