When "Do Not" Is Not Deny: Security Rules in CLAUDE.md vs Built-In Controls

현대 소프트웨어 제작 세계에서 새로운 종류의 조력자가 등장했습니다: 바로 코딩 에이전트입니다. 이들은 인간 개발자처럼 코드를 작성하고, 버그를 수정하며, 파일을 관리할 수 있는 인공지능 프로그램입니다. 이러한 디지털 비서들을 안전하게 유지하고 올바른 궤도에 머물게 하기 위해, 개발자들은 지침 파일을 작성합니다. 이 파일들을 마치 레시피나 행동 강령과 같은 일련의 서술된 규칙이라고 생각하십시오. 여기에는 인간이 에이전트에게 무엇을 할 수 있고 무엇을 절대 해서는 안 되는지를 알려줍니다. 개발자는 "평문으로 비밀번호를 저장하지 마시오"라거나 "중요한 데이터를 삭제하기 전에 물어보시오"와 같은 내용을 작성할 수 있습니다. 수년 동안 이러한 방식으로 지침을 전달하는 것은 이 지능적인 도구들을 안내하는 표준적인 방법이었습니다. 만약 규칙을 명확하게 작성한다면, 에이전트가 이를 이해하고 따를 것이며, 구축 중인 소프트웨어를 위한 안전한 환경을 만들 것이라는 가정이 전제되어 왔습니다.

하지만 연구자 팅 얀(Ting Yan)의 최근 연구는 이 시스템에 존재하는 조용하지만 중요한 격차를 밝혀냈습니다. 이 연구는 인기 있는 코딩 에이전트인 클로드 코드(Claude Code)와 함께 사용되는 특정 유형의 지침 파일에 초점을 맞추고 있습니다. 연구는 매우 간단하면서도 결정적인 질문을 던집니다: 개발자가 평이한 영어로 보안 규칙을 작성했을 때, 소프트웨어에 실제로 그 규칙을 강제할 수 있는 내장된 메커니즘이 있는가, 아니면 그 규칙은 단지 인공지능이 어떻게 따라야 할지 추측해야 하는 하나의 제안에 불과한가? 연구 결과는 이러한 대다수의 서술된 규칙에 대해 답은 후자임을 시사합니다. 이 파일은 개발자는 말하지만 시스템은 규칙이 준수되고 있는지 확인하지 않는 일방통행로 역할을 합니다. 이는 개발자는 위험한 동작이 차단되었다고 믿지만, 실제로는 시스템이 명령을 기억하고 준수하도록 인공지능에만 의존하고 있을 뿐 아무런 강력한 정지 장치(hard stop)가 없는 상태, 즉 잘못된 보안 의식을 만들어냅니다.

이 문제의 규모를 파악하기 위해, 연구진은 전 세계 개발자들로부터 약 500개의 공개 지침 파일을 수집했습니다. 그들은 이 파일들을 마치 손으로 쓴 메모 모음처럼 취급하여, 문장을 한 줄씩 스캔하며 보안 규칙처럼 들리는 문장을 찾아냈습니다. 그들은 제한을 나타내는 신호인 "must not", "never", 또는 "do not"과 같은 구절을 찾았습니다. 이 파일들로부터 수천 개의 후보 규칙을 추출했습니다. 다음 단계는 인간의 언어인 규칙과 소프트웨어의 기술적 언어 사이의 번역가 역할을 하는 것이었습니다. 연구진은 특정 코딩 에이전트인 클로드 코드가 해당 동작을 자동으로 차단할 수 있는 내장된 스위치나 설정값을 이미 가지고 있는지 물었습니다. 예를 들어, 규칙이 "이 특정 명령을 실행하지 마시오"라고 한다면, 연구진은 소프트웨어에 해당 명령을 발생하기 전에 단순히 거부할 수 있는 권한 설정이 있는지 확인했습니다. 만약 소프트웨어에 그러한 스위치가 없다면, 규칙은 인공지능이 해석하도록 남겨지며, 이는 에이전트가 스스로 지침을 따를지 여부를 결정해야 함을 의미합니다.

이 비교의 결과는 극명했습니다. 연구진이 엄격한 기준(내장된 제어가 작성된 규칙의 정확한 동작, 정확한 대상, 정확한 조건을 모두 충족해야 한다는 기준)을 적용했을 때, 매칭되는 안전 메커니즘을 가진 규칙은 아주 적었습니다. 구체적으로, 개발자가 작성한 보안 규칙 중 추가 작업 없이 이를 강제할 수 있는 내장된 제어 장치를 갖춘 규칙은 약 4~6%에 불과하다는 것을 발견했습니다. 부분적인 매칭을 허용하는 완화된 기준을 사용했을 때조차, 그 숫자는 약 16%로 늘어나는 데 그쳤습니다. 이는 이 파일들에 작성된 보안 규칙의 약 95%에 대해 자동화된 안전망이 없음을 의미합니다. 규칙은 오직 텍ек스트로 존재할 뿐이며, 인공지능이 매번 이를 올바르게 해석하기만을 전적으로 신뢰하고 있었습니다.

연구는 왜 그렇게 많은 규칙이 매칭되지 않았는지도 조사했습니다. 연구진은 규칙들이 소프트웨어의 내장 도구들이 단순히 볼 수 없거나 할 수 없는 것들을 요구하는 경우가 많다는 것을 발견했습니다. 규칙은 "코드에 비밀 정보를 커밋하지 마시오"라고 할 수 있지만, 소프트웨어의 권한 설정은 파일 경로 나 명령은 차단할 수 있어도 파일 내부의 실제 내용은 차단할 수 없습니다. 비밀 정보에 대한 규칙을 집행하려면 소프트웨어가 파일을 읽고 그 안에 무엇이 있는지 이해해야 하는데, 이는 표준 설정으로는 수행할 수 없는 작업입니다. 마찬가지로, 규칙은 시스템의 상태를 확인하거나 특정 사람의 승인을 받아야 할 수도 있는데, 내장된 제어 기능은 이러한 세부 사항에 접근할 수 없습니다. 이 경우, 규칙은 소프트웨어가 실행할 수 있는 명령이 아니라, 인공지능이 판단력을 발휘하도록 요청하는 것이었습니다. 연구진은 이러한 구분이 개발자에게는 보이지 않는다는 점에 주목했습니다. 지침 파일은 규칙이 하드웨어 시스템 잠금에 의해 강제되는지, 아니면 인공지능의 연약한 기억력에 의존하는지에 관계없이 똑같이 보이기 때문입니다.

이러한 피드백의 부재는 연구진이 "쓰기 전용(write-only)" 채널이라고 부르는 현상을 만듭니다. 대부분의 소프트웨어 개발에서 개발자가 규칙을 작성하면 즉각적인 피드백을 받습니다. 만약 규칙을 위반하는 코드를 작성하면 컴퓨터가 실행을 거부하거나 테스트가 실패하여 즉시 문제가 있음을 알려줍니다. 하지만 이 지침 파일의 경우, 그러한 신호가 없습니다. 개발자는 규칙을 작성하고 넘어가며, 에이전트가 실제로 그 규칙을 따르고 있는지 결코 알 수 없습니다. 연구는 이것이 특히 보안에 익숙하지 않은 개발자들에게 위험하다고 강조합니다. 그들은 시스템을 보호했다고 생각하며 규칙을 작성할 수 있지만, 시스템이 해당 제한 사항을 실제로 강제할 방법이 없다는 사실을 깨닫지 못할 수 있습니다. 인공지능은 대부분의 경우 규칙을 따르겠지만, 실수하거나 혼란을 겪거나 다른 입력값에 의해 속을 수도 있으며, 이는 시스템을 취약하게 만듭니다.

연구진은 소프트웨어가 고장 났거나 개발자들이 무언가 잘못하고 있다고 본 것이 아닙니다. 대신, 그들은 이러한 도구들이 사용자들과 소통하는 방식의 설계 결함을 식별했습니다. 도구들은 직관적이고 쉬운 자연어로 규칙을 작성할 수 있게 해주지만, 작성된 규칙 중 어떤 것이 시스템에 의해 실제로 강제되고 있고 어떤 것이 단순한 제안에 불과한지는 알려주지 않습니다. 연구는 이러한 도구들이 진정으로 안전해지려면 이 루프를 닫아야 한다고 제안합니다. 도구들은 개발자에게 어떤 규칙이 하드 제어에 의해 뒷받선되어 있고 어떤 것이 그렇지 않은지 보여줄 수 있는 방법을 제공해야 합니다. 이상적으로는, 소프트웨어가 개발자가 시스템이 강제할 수 없는 규칙을 작성했을 때 경고를 보내거나, 그 규칙을 시스템이 실제로 사용할 수 있는 설정으로 전환하도록 도와야 합니다. 이 피드백 루프가 닫히기 전까지, 이 시스템들의 보안은 인공지능이 모든 지침을 완벽하게 기억하고 준수할 것이라는 희망에 크게 의존하게 될 것이며, 데이터는 그 희망이 종종 잘못되었음을 보여줍니다.

연구는 결론적으로 이것이 해결 가능한 문제이지만, 이러한 도구들이 구축되는 방식의 변화가 필요하다고 강조합니다. 개발자가 작성하는 것과 시스템이 강제하는 것 사이의 격차는 미스터리가 아니라 측정 가능한 사실입니다. 이를 측정함으로써, 연구진은 현재의 에이전트 보안 방식이 불완전하다는 것을 보여주었습니다. 해결책은 보이지 않는 것을 보이게 만드는 데 있습니다. 즉, 개발자가 규칙을 작성할 때 그것이 정확히 어떤 종류의 보호를 제공하는지 알 수 있도록 하는 것입니다. 이렇게 함으로써 지침 파일을 일방적인 메모에서 양방향 대화로 바꿀 수 있으며, 시스템이 규칙을 단순히 기록하는 것에 그치지 않고 실제로 작동하고 있음을 확인해 주는 구조를 만들 수 있습니다.