코딩 에이전트에게 필요한 것은 더 나은 매너가 아니라 파일 경계(File Boundaries)입니다

다음 단계의 진지한 코딩 에이전트(coding-agent) 기능은 더 따뜻한 말투나 더 똑똑한 자동 완성(autocomplete)이 아닙니다.

그것은 바로 감사 가능한 차단 목록(auditable denylist)입니다.

지루하게 들릴 수도 있지만, 바로 그렇기 때문에 중요합니다. 일단 에이전트가 당신의 리포지토리(repo)를 조사하고, 로컬 파일을 열고, 컨텍스트(context)를 요약하고, 명령어를 실행하거나, 패치(patch)를 준비할 수 있게 되면, 신뢰의 문제는 "모델이 신중해 보이는가?"라는 질문에서 멈추게 됩니다. 대신 훨씬 더 기계적인 질문이 중요해집니다:

무엇을 읽을 수 있는가?

무엇을 모델로 보낼 수 있는가?

무엇을 변경할 수 있는가?

그리고 작업이 검증되었다고 말할 때, 사람이 알아챌 수 있을 만큼 충분히 크게 실패한 것은 실제로 무엇인가?

개발자들은 계속해서 더 부드러운 언어로 에이전트의 신뢰 문제를 해결하려고 시도합니다. "비밀 정보(secrets)를 주의하세요." "자격 증명(credentials)을 건드리지 마세요." "민감한 파일을 사용하기 전에 물어보세요." 이는 가이드라인으로서는 괜찮습니다. 하지만 경계(boundary)는 아닙니다.

경계란 에이전트가 말로써 우회할 수 없는 무언가입니다.

민감한 파일은 일반적인 컨텍스트가 아닙니다

현재 Codex에는 에이전트의 접근으로부터 민감한 파일과 디렉토리를 제외하는 방법을 요청하는 오픈 이슈가 있습니다. 예시는 정확히 예상할 수 있는 것들입니다: .env, 개인 키(private keys), 클라우드 자격 증명(cloud credentials), 로컬 설정(local config), .aws/, .ssh/, 그리고 실제 권한과 밀접하게 연관된 기타 파일들입니다.

이 이슈는 일반적인 에이전트의 과장된 홍보(hype)를 뚫고 지나가기 때문에 유용합니다. 이것은 추상적인 "AI 안전(AI safety)" 논쟁이 아닙니다. 이것은 어떤 팀이라도 이해할 수 있는 리포지토리 위생(repo hygiene) 문제입니다.

소스 코드는 컨텍스트입니다. 문서(Docs)는 컨텍스트입니다. 테스트 파일은 컨텍스트입니다. 빌드 스크립트(Build scripts)는 컨텍스트입니다.

비밀 정보(Secrets)는 다릅니다.

로컬 자격 증명(Local credentials)은 다릅니다.

작업 디렉토리에 놓인 고객 수출 데이터(Customer exports)는 다릅니다.

실수는 모든 인접한 파일을 유능한 모델을 위한 동일하게 유효한 입력값으로 취급하는 것입니다. 그렇지 않습니다. 어떤 파일들은 운영상의 경계(operational boundaries)입니다. 어떤 파일들은 개발자의 머신에서 지저분한 실제 작업이 일어나기 때문에 존재합니다. 어떤 파일들은 단 한 번의 read_file 호출만으로 접근 가능하더라도, 결코 모델의 컨텍스트가 되도록 의도되지 않았습니다.

에이전트에게 "민감한 파일을 피하라"고 프롬프팅(Prompting)하는 것은, 에이전트가 경로를 확인하기도 전에 런타임(runtime)에서 강제하는 규칙보다 훨씬 약합니다.

그 차이는 중요합니다.

프롬프트 정책은 액세스 제어(Access Control)가 아닙니다

프롬프트가 쓸모없다고 가정하고 싶지는 않습니다. 저장소 지침(Repo instructions), 에이전트 가이드라인, 그리고 프로젝트 정책은 이제 워크플로(workflow)의 실제 구성 요소입니다. 이것들은 에이전트에게 프로젝트가 어떻게 작동하는지 알려줍니다. 편집의 일관성을 유지하도록 돕습니다. 또한 많은 어리석은 실수들을 방지할 수 있습니다.

하지만 그것들은 여전히 산문(prose)입니다.

산문은 검토가 가능합니다. 산문은 유용합니다. 하지만 에이전트가 긴 작업을 수행하며 여러 일을 동시에 처리할 때, 산문은 잘못 읽거나, 무시하거나, 충돌하거나, 잊어버리기 쉽습니다.

액세스 제어(Access control)가 에이전트가 당신의 선호도를 기억하는 것에 의존해서는 안 됩니다. 특정 경로가 금지되어 있다면, 시스템이 그 경로를 금지된 상태로 만들어야 합니다.

이는 팀들에게 지루한 제어 장치들이 필요함을 의미합니다:

에이전트가 절대 읽어서는 안 되는 파일에 대한 저장소 수준(repo-level)의 거부 규칙(deny rules)
머신 수준의 자격 증명(credential) 경로에 대한 글로벌 거부 규칙
코드 리뷰어가 검사할 수 있는 가시적인 설정(config)
읽기 가능한 컨텍스트(context)와 금지된 컨텍스트 사이의 명확한 구분
내용을 유출하지 않으면서 거부된 액세스 시도를 보여주는 로그

이것은 기업용 보여주기식 행위(enterprise theater)가 아닙니다. 개인 개발자들에게도 이것이 필요합니다. 가장 최소한의 버전이라도 여전히 유용합니다. 즉, 체크인된 에이전트 설정(agent config)과 비밀 정보 및 머신별 상태를 위한 로컬 글로벌 무시 목록(ignore list)을 갖추는 것입니다.

요점은 간단합니다. 에이전트가 파일을 읽어서는 안 된다면, 그것을 성격 테스트(personality test)로 만들지 마세요.

생성된 작업은 부담을 리뷰로 옮깁니다

AI 코딩 에이전트에 관한 연구들은 한 가지 사실을 명확히 하기 시작했습니다. 에이전트가 리뷰의 필요성을 없애는 것이 아니라, 리뷰로 향하는 압박을 더 많이 옮긴다는 점입니다.

최근의 한 논문은 AI 코딩 에이전트 도입 이후 수천 개의 저장소를 연구하였으며, 그 효과가 단순히 코드 양에만 나타나는 것이 아니라 인간 기여자 생태계(human contributor ecosystem)에 나타난다고 주장합니다. 이것이 바로 팀들이 주목해야 할 부분입니다. 더 많은 생성된 작업은 더 깊은 리뷰, 더 많은 거버넌스(governance) 작업, 그리고 사후에 문제를 잡아내야 하는 유지 관리자(maintainer)들에 대한 더 큰 압박을 의미할 수 있습니다.

이는 이러한 워크플로가 실제로 느껴지는 방식과 일치합니다.

에이전트는 패치(patch)를 빠르게 생성할 수 있습니다. 좋습니다.

이제 누군가는 이 패치가 올바른 파일을 건드렸는지, 올바른 가정을 사용했는지, 잘못된 컨텍스트를 노출했는지, 잘못된 테스트를 건너뛰었는지, 아니면 깔끔한 요약 뒤에 위험한 변경 사항을 숨겼는지를 결정해야 합니다.

취약한 경계(boundaries)는 그러한 리뷰를 더욱 어렵게 만듭니다. 만약 에이전트가 광범위한 파일 접근 권한을 가지고 있다면, 리뷰어는 에이전트가 무엇을 보았을지 의구심을 가져야 합니다. 만약 에이전트가 로컬 비밀 정보(secrets)를 읽을 수 있다면, 리뷰어는 그러한 상태가 출력에 영향을 미치지는 않았을지 의심해야 합니다. 만약 에이전트가 생성된 에셋(assets), 디자인 내보내기(exports), 로컬 데이터, 그리고 설정 블롭(config blobs)을 훑을 수 있다면, 디프(diff)는 전체 이야기의 일부일 뿐입니다.

이 지점에서 파일 경계(file boundaries)는 생산성 기능(productivity feature)이 됩니다.

작은 운영 표면(operating surface)은 리뷰하기가 더 쉽습니다. 가시적인 차단 목록(denylist)은 설명하기가 더 쉽습니다. 저장소(repo) 내의 설정 파일(config file)은 에이전트가 "아마도 그러지 않았을 것입니다"라고 막연하게 확언하는 것보다 논의하기가 더 쉽습니다.

좋은 경계는 팀의 속도를 늦추지 않습니다. 오히려 에이전트가 이미 행동을 취한 후 수행해야 하는 탐정 업무(detective work)의 양을 줄여줍니다.

오라클(oracle)이 약하다면 테스트는 증거가 될 수 없다

에이전트가 작성한 테스트에도 유사한 함정이 있습니다.

최근의 또 다른 논문은 에이전트가 작성한 테스트 코드 내의 오라클 신호(oracle signals)를 살펴봅니다. 여기서 유용한 교훈은 "에이전트의 테스트는 나쁘다"가 아닙니다. 유용한 교훈은 테스트 형태를 갖춘 출력물이라 할지라도 여전히 중요한 사항을 확인하는 데 실패할 수 있다는 점입니다.

테스트 파일이 존재할 수 있습니다.

테스트 스위트(suite)가 실행될 수 있습니다.

요약 결과가 초록색(pass)으로 보일 수 있습니다.

하지만 실제 동작에 대한 주장(behavioral claim)은 여전히 테스트가 부족하거나, 과도하게 모킹(over-mocked)되었거나, 버그를 절대 잡아낼 수 없는 방식으로 단언(asserted)될 수 있습니다.

이것이 중요한 이유는 팀들이 종종 "테스트를 실행한다"는 것만으로 에이전트의 안전성(safety) 루프가 완성되는 것처럼 이야기하기 때문입니다. 그렇지 않습니다. 테스트를 실행하는 것은 하나의 단계일 뿐입니다. 의미 있는 검증(verification)이 바로 그 루프입니다.

동일한 원칙이 파일 접근에도 적용됩니다. "에이전트가 어떤 비밀 정보도 언급하지 않았다"는 것이 에이전트가 민감한 컨텍스트에 전혀 손을 대지 않았다는 증거는 아닙니다. "에이전트가 변경 사항을 검증했다고 말한다"는 것이 그 검증에 유용한 오라클(oracle)이 있었다는 증거는 아닙니다.

에이전트 워크플로에는 가시적인 실패 모드(failure modes)가 필요합니다:

차단된 파일 읽기(blocked file reads)는 명시적이어야 합니다.
건너뛴 테스트(skipped tests)는 명시적이어야 합니다.
불안정한 검증기 출력(flaky verifier output)은 명시적이어야 합니다.
생성된 테스트는 어떤 동작을 단언(assert)하는지 명시해야 합니다.
요약(summaries)은 "이것을 변경했습니다"와 "이것을 증명했습니다"를 구분해야 합니다.

위험한 상태는 실패가 아닙니다. 실패는 괜찮습니다. 실패는 정보입니다.

위험한 상태는 가짜 초록색 체크(fake green check)입니다.

프론트엔드 예시도 동일한 패턴입니다

이는 백엔드 저장소(repos)나 비밀 파일에만 국한되지 않습니다.

프론트엔드 및 AI UI 작업도 산출물(artifacts)만 다를 뿐 동일한 경계(boundary) 문제를 가지고 있습니다. 저장소에는 디자인 스크린샷, 생성된 이미지, 소셜 프리뷰 에셋(social preview assets), 고객 목업(customer mockups), 내보낸 UI 상태, 그리고 에이전트 컨텍스트(agent context)로 자동 포함되어서는 안 되는 미완성 실험들이 포함될 수 있습니다.

만약 작업이 "소셜 프리뷰 이미지를 준비하라"는 것이라면, 에이전트에게 관련 없는 원본 에셋이 가득 찬 폴더가 필요하지는 않을 것입니다. 가능할 때마다 해당 작업을 에이전트 컨텍스트 외부로 유지하세요. Resize Image For와 같은 브라우저 로컬 유틸리티를 사용하는 것이, 단지 근처에 있다는 이유로 에이전트에게 추가 이미지 파일을 넘겨주는 것보다 플랫폼 에셋의 크기를 조정하는 데 더 적합합니다.

생성된 인터페이스 패턴을 평가할 때도 마찬가지입니다. 필드가 어떻게 생겼는지 배우기 위해 에이전트가 저장소의 모든 오래된 실험 내용을 흡수할 필요는 없습니다. Awesome Generative UI와 같이 큐레이션된 참조 표면(reference surface)만으로도, 로컬 프로젝트에 대한 에이전트의 접근 권한을 넓히지 않고 패턴, 논문, 예시 및 도구를 비교하기 위한 충분한 컨텍스트를 제공할 수 있습니다.

이것이 더 넓은 의미의 규칙입니다: 에이전트에게 당신이 우연히 가지고 있는 모든 산출물을 주는 것이 아니라, 에이전트에게 필요한 컨텍스트를 제공하십시오.

이번 주에 에이전트를 도입하는 팀을 위한 실무 체크리스트

만약 당신의 팀이 실제 업무에 코딩 에이전트를 추가하려 한다면, 모델 선택에 대해 논쟁하기 전에 이 체크리스트부터 시작해 보시길 권합니다.

첫째, 금지된 경로(forbidden paths)를 정의하십시오. 비밀 정보(secrets), 자격 증명(credentials), 개인 키(private keys), 로컬 환경 파일(local environment files), 클라우드 설정(cloud config), 고객 데이터(customer data), 그리고 기기 특정 디렉토리(machine-specific directories)를 포함해야 합니다. 이 목록을 명시적으로 만드십시오.

둘째, 저장소 규칙(repo rules)과 기기 규칙(machine rules)을 분리하십시오. 저장소는 프로젝트 경계(project boundaries)를 정의할 수 있습니다. 개발자의 기기에는 어디에서도 에이전트가 읽어서는 안 되는 항목들을 위한 전역 차단 목록(global denylist)이 여전히 필요합니다.

셋째, 빌드 설정(build config)과 같은 에이전트 설정(agent config)을 검토하십시오. 만약 어떤 변경 사항이 에이전트에게 더 많은 컨텍스트(context), 더 많은 쓰기 권한(write access), 또는 더 많은 권한(authority)을 부여한다면, 그것은 실질적인 검토를 거쳐야 합니다.

넷째, 작업에 필요한 경우가 아니라면 생성된 자산(generated assets)을 컨텍스트(context)에서 제외하십시오. 이미지(images), 미리보기(previews), 내보내기(exports), 로그(logs), 스냅샷(snapshots), 그리고 로컬 데이터(local data)는 에이전트에게 필요한 것보다 더 많은 정보를 담고 있을 수 있습니다.

다섯째, 거부된 읽기(denied reads)를 관찰 가능하게(observable) 만드십시오. 조용한 차단(silent block)이 정보 유출(leak)보다는 낫지만, 눈에 보이는 차단(visible block)이 미스터리보다는 낫습니다. 검토자는 경계(boundary)가 제 역할을 다했을 때 그 사실을 알아야 합니다.

여섯째, 패치 성공(patch success)과 검증 성공(verification success)을 분리하십시오. "디프(diff)가 생성되었다"는 것이 "동작이 검증되었다"는 뜻은 아닙니다. 에이전트가 어떤 체크(checks)를 실행했는지, 어떤 체크가 실패했는지, 그리고 어떤 주장(claims)이 여전히 증명되지 않았는지 말하게 하십시오.

일곱째, 에이전트가 작성한 테스트에서 실제 오라클(real oracles)을 검사하십시오. 모의 객체(mock)가 모의 값(mock value)을 반환했다는 것만을 증명하는 테스트는 당신에게 별로 도움이 되지 않습니다.

여덟째, 위험한 변경 사항에 대해서는 소스 노트(source notes)를 남기십시오. 만약 에이전트가 인증(auth), 파일 처리(file handling), 설정 로딩(config loading), 도구 접근(tool access), 데이터 내보내기(data export), 또는 테스트 정책(test policy)을 변경했다면, 검토 과정에서 어떤 소스나 규칙이 해당 변경을 정당화했는지 알 수 있어야 합니다.

이 중 그 어느 것도 거대한 플랫폼 팀을 필요로 하지 않습니다. 이것은 에이전트의 접근 권한(agent access)을 사후 고려 사항이 아니라 시스템 설계(system design)의 일부로 결정하는 것을 필요로 합니다.

지루한 경계가 곧 제품이다

더 나은 모델이 도움이 될 것입니다. 더 나은 IDE 통합(IDE integrations)이 도움이 될 것입니다. 더 나은 요약(summaries)이 도움이 될 것입니다.

하지만 그것들이 엄격한 경계(hard boundaries)의 필요성을 제거해주지는 않을 것입니다.

코딩 에이전트(coding agent)는 매우 뛰어날 수 있지만, 여전히 과도한 권한을 가질 수 있습니다. 신중하게 행동할 수도 있지만, 결코 봐서는 안 될 파일을 볼 수도 있습니다. 테스트를 작성할 수도 있지만, 동작을 증명하는 데 실패할 수도 있습니다. 아름다운 요약(summary)을 만들어낼 수도 있지만, 리뷰어가 어떤 컨텍스트(context)가 패치(patch)를 형성했는지 추측하게 만들 수도 있습니다.

에이전트 도입의 진지한 버전은 "모델을 더 신뢰하는 것"이 아닙니다.

그것은 "모델이 더 작고 검사 가능한 공간(inspectable space) 안에서 작동하도록 만드는 것"입니다.

이것이 바로 차단 목록(denylist)이 중요한 이유입니다. 이것은 설정 패널의 사소한 기능이 아닙니다. 이것은 신뢰 경계(trust boundary)의 형태입니다.

코딩 에이전트의 액세스 규칙(access rules)이 팀 전체가 감사(audit)할 수 있을 정도로 충분히 지루할 때, 에이전트를 더 신뢰하기 쉬워집니다.

그것이 제가 에이전트를 매일 실제 저장소(real repos) 근처에서 작업하도록 허용하기 전에 원하는 기준입니다.

출처 노트 (Source notes)