코딩 에이전트(Coding agents)는 쓰기 권한(write credentials)을 가져서는 안 됩니다.

최근 코딩 에이전트(coding agents)에 대해 많은 생각을 해왔습니다.

그들이 좋은 코드를 작성할 수 있는지에 대한 것이 아닙니다. 왜냐하면 보통은 할 수 있고, 때로는 못하기 때문입니다. 그 부분은 명백합니다. 하지만 위험 요소가 '잘못된 답변'에서 '잘못된 결과(wrong outcomes)'로 이동하고 있습니다.

저에게 더 중요하게 느껴지는 부분은 이것입니다:
에이전트가 실제로 쓰기 권한(write authority)을 소유해야 하는가?

우리는 이미 역할(roles), 제한(limits), 검토(reviews), 그리고 책임(accountability)이 없는 인간을 신뢰하지 않습니다. 개발자는 PR(Pull Requests)을 사용하고, 조종사는 체크리스트를 사용하며, 은행원은 송금 한도를 가집니다. 유능한 에이전트에게도 동일한 구조가 필요하지만, 이는 기계가 읽을 수 있는(machine-readable) 형태여야 합니다.

현재 많은 설정은 대략 다음과 같은 모습입니다:

에이전트가 저장소(repo)를 읽음
에이전트가 무엇을 변경할지 결정함
에이전트가 GitHub 토큰을 보유함
에이전트가 커밋(commits), 브랜치(branches), 또는 PR을 생성함

저는 이것이 올바른 기본 설정(default)이라고 생각하지 않습니다.

에이전트는 추론(reason)할 수 있습니다.
에이전트는 파일을 검사(inspect)할 수 있습니다.
에이전트는 변경 사항을 제안(propose)할 수 있습니다.

하지만 에이전트가 직접적으로 외부 영향(external impact)을 생성할 수 있는 순간, 문제는 변화합니다.

이제 그것은 단지 다음과 같은 문제가 아닙니다:

에이전트가 무언가 잘못 말했는가?

그것은 다음과 같이 변합니다:

에이전트가 잘못된 결과(wrong outcome)를 만들어냈는가?

이것은 훨씬 더 비용이 많이 드는 실패 모드(failure mode)입니다.

의도(Intent)는 권한(authority)이 아닙니다

제가 더 선호하는 패턴은 간단합니다:

에이전트가 직접 읽음
에이전트가 의도(intent)를 제안함
경계(boundary)가 결정함
어댑터(adapter)가 승인된 작업만을 실체화(materializes)함

따라서 에이전트는 쓰기 권한(write credentials)을 받지 않습니다.
대신 다음과 같이 보일 수 있는 구조화된 의도(structured intent)를 제출합니다:

{
  "operation": "write",
  "target": {
...

이렇게 되면 이것은 더 이상 명령(command)이 아니라, 제안(suggestion) 또는 의도(intent)가 됩니다.
시스템은 여전히 이 제안된 결과가 존재해야 하는지 여부를 결정해야 합니다.

그 결정 계층(decision layer)은 다음과 같은 사항들을 확인할 수 있습니다:

이 행위자(actor)가 허용되었는가?
이 저장소(repo)가 허용되었는가?
이 경로(path)가 범위(scope) 내에 있는가?
소스 상태(source state)가 여전히 일치하는가?
이 작업(operation)이 허용되었는가?
동일한 효과가 이미 생성되었는가?
이것이 검토 가능한 PR이 되어야 하는가?

오직 그 이후에 결과가 나타나야 합니다.

예를 들어:

{
  "decision": "admitted",
  "checks": {
...

핵심 규칙은 다음과 같습니다:

승인(admission) 없이는 영향(impact)을 미치지 않는다.

흐름은 다음과 같습니다:

Diagram showing how an agent reads a repository, submits a structured intent, passes boundary checks, and creates a pull request through a GitHub adapter

이것은 샌드박스(sandbox)와 동일하지 않습니다

샌드박스(sandbox)는 유용합니다.
하지만 저는 그것이 다른 문제를 해결한다고 생각합니다.

샌드박스(sandbox)는 다음과 같은 질문을 던집니다:

에이전트(agent)가 어디에서 실행될 수 있는가?
네트워크(network)를 사용할 수 있는가?
명령(commands)을 실행할 수 있는가?
어떤 파일(files)에 접근할 수 있는가?
환경(environment)을 탈출할 수 있는가?

게이트웨이(gateway)는 다음과 같은 질문을 던집니다:

이 구체적으로 제안된 결과물이 존재해야 하는가?

이 차이는 중요합니다. 샌드박스(sandbox)는 탈출을 막을 수는 있지만, 제안된 결과물이 존재해야 하는지 여부를 결정하지는 않기 때문입니다.
만약 에이전트(agent)가 허용된 환경 내에서 유효한 GitHub 토큰(token)을 가지고 있다면, 허용된 도구(tools)를 사용하여 원치 않는 결과를 여전히 만들어낼 수 있습니다.
해당 동작은 기술적으로는 허용될 수 있지만, 여전히 잘못된 결과일 수 있습니다.

그렇기 때문에 저는 경계가 단순히 실행(execution) 주변에만 머무는 것이 아니라, 의도(intent)와 영향(impact) 사이에 위치해야 한다고 생각합니다.

샌드박스(sandbox)는 실행(execution)을 격리합니다.
게이트웨이(gateway)는 영향(impact)을 격리합니다.

GitHub가 좋은 첫 번째 타겟인 이유

GitHub에는 이미 훌륭한 인간의 패턴이 있습니다:

변경 제안(change proposal)이 곧 머지(merge)는 아니다.

풀 리퀘스트(Pull Requests)는 검토 가능하며 개발자들이 이미 일하는 방식에 부합하기 때문에 익숙합니다.

하지만 에이전트(agent)의 경우, PR(Pull Request) 이전에 중요하게 고려해야 할 단계가 하나 더 있습니다:

에이전트의 제안(proposal)이 자동으로 PR의 영향(impact)으로 이어져서는 안 됩니다.
PR은 그 자체로 이미 실제적인 부작용(side effect)입니다.

브랜치(branch)를 생성합니다.
커밋(commits)을 생성합니다.
검토 작업(review work)을 생성합니다.
저장소(repository)의 상태를 변경합니다.

따라서 에이전트(agent)가 자신의 쓰기 토큰(write token)을 사용하여 이를 직접 생성해서는 안 됩니다.

제가 원하는 흐름은 다음과 같습니다:

에이전트(agent)가 저장소(repository)를 읽습니다.
에이전트(agent)가 구조화된 의도(structured intent)를 제출합니다.
게이트웨이(gateway)가 상태(state), 범위(scope), 정책(policy), 그리고 멱등성(idempotency)을 확인합니다.
GitHub 어댑터(adapter)는 승인(admission) 후에만 검토 가능한 PR(Pull Request)을 생성합니다.
PR(Pull Request)은 해당 결정에 대한 증거(evidence)를 포함합니다.

어댑터(adapter)는 권한을 가진 주체가 아니며, 승인된 작업(admitted work)을 실체화(materialize)할 뿐입니다.
그리고 에이전트(agent)는 결코 GitHub 쓰기 권한(write credentials)을 받지 않습니다.

이것이 코드를 올바르게 만들지는 않습니다

이 점이 중요합니다:

이러한 경계(boundary)가 생성된 코드가 훌륭하다는 것을 증명하지는 않습니다.
이것은 CI(지속적 통합)를 대체하지 않습니다.
이것은 인간의 검토(human review)를 대체하지 않습니다.
이것은 의미론적 정확성(semantic correctness)을 증명하지 않습니다.
이것은 제안된 작업(proposed work)이 외부 영향(external impact)으로 전환되는 과정을 제어할 뿐입니다.

그 더 좁은 범위의 주장이 핵심입니다. 저는 많은 에이전트(agent) 시스템이 다음 세 가지를 혼동하고 있다고 생각합니다:

추론 (reasoning)
결정 (decision)
영향 (impact)

하지만 이들은 분리되어야 합니다:

에이전트(agent)는 추론(reasoning)을 담당합니다.
경계(boundary)는 결정(decision)을 담당합니다.
어댑터(adapter)는 제어된 실체화(controlled materialization)를 담당합니다.
대상 시스템(target system)은 승인된 영향(admitted impact)만을 받아야 합니다.

제가 이것에 관심을 갖는 이유

저는 모델이 더 똑똑해진다는 이유만으로 프로덕션 에이전트(production agent) 시스템이 신뢰받을 것이라고 생각하지 않습니다. 에이전트의 작업에서 외부의 변화로 이어지는 경로가 명시적(explicit)이 될 때 비로소 신뢰받을 것입니다.
모든 실제 결과에 대해, 저는 다음과 같은 질문을 던질 수 있기를 원합니다:

에이전트(agent)가 무엇을 제안했는가?
에이전트(agent)가 어떤 상태(state)를 읽었는가?
어떤 규칙(rules)들이 확인되었는가?
왜 승인되었거나 차단되었는가?
어떤 결과(outcome)가 생성되었는가?
인간이 이를 검토할 수 있는가?
나중에 이를 감사(audit)할 수 있는가?

그것이 제가 Impact Boundary Labs와 함께 작업해 온 계층(layer)입니다.
첫 번째 구현은 GitHub 우선(GitHub-first) 방식입니다:

에이전트(agents)는 저장소(repositories)를 직접 읽을 수 있지만, 쓰기 의도(write intents)는 증거를 포함하여 검토 가능한 Pull Request를 생성하는 결정론적 게이트웨이(deterministic gateway)를 거쳐야 합니다.

GitHub가 아이디어의 전부인 것은 아닙니다. 저장소는 명확한 상태(state), 브랜치(branches), 커밋(commits), PR(Pull Requests), 그리고 검토(review) 과정을 가지고 있기 때문에, 이 패턴을 증명하기 위한 첫 번째 구체적인 장소일 뿐입니다.

더 넓은 원칙은 다음과 같습니다:

에이전트가 추론(reason)하게 하십시오.
의도(intent) 단계에서 멈추게 하십시오.
결과(outcome)가 되는 것을 제어하십시오.

Project: Impact Boundary Labs