Agent_Sudo를 구축하며 배운 AI 에이전트 보안 (사용자를 찾기 전까지)

저는 실제 결과물을 출시했습니다. Agent_Sudo는 AI 에이전트를 위한 로컬 권한 게이트웨이(permission gateway)입니다. 에이전트의 도구 호출(tool calls) 앞에 위치하여 정책과 요청의 출처를 기반으로 _허용 / 거부 / 승인 필요(allow / deny / require-approval)_를 결정하며, 검증 가능한 변조 방지 해시 체인 감사 로그(tamper-evident, hash-chained audit log)를 작성합니다. Python으로 작성되었으며, 런타임 의존성(runtime dependencies)이 없고, 약 190개의 통과된 테스트, MCP 서버, LangGraph 및 PydanticAI용 작동 예제를 포함하며, PyPI에 v0.4.0 버전으로 게시되었습니다.

매우 견고합니다. 저는 이 엔지니어링 작업이 자랑스럽습니다. 그리고 지금까지 제가 배운 가장 유용한 것들은 코드와는 거의 관련이 없었습니다.

저는 현재 실제로 이 도구가 필요한 사람이 있는지 파악하는 과정에 있습니다. 진행 중인 과정에서 솔직하게 배우고 있는 점들은 다음과 같습니다.

엔지니어링 품질과 수요는 완전히 다른 변수입니다

몇 주 동안 저는 엔지니어들이 측정하는 것들, 즉 테스트 통과(tests green), 깨끗한 모듈, 의존성 없음, 신중한 추상화(abstractions)로 프로젝트를 측정했습니다. 이 모든 것은 실제적이고 만족스러운 것이지만, 단 한 명이라도 이 도구를 원하는지는 알려주지 않습니다.

저는 코드 품질을 진척도의 대리 지표(proxy)로 사용하고 있는 저 자신을 발견했습니다. 하지만 그렇지 않습니다. 아무도 필요로 하지 않는 아름답게 만들어진 물건은 여전히 아무도 필요로 하지 않는 물건일 뿐입니다. _'이것이 좋은 것인가(is it good)'_와 _'누군가 이것을 원하는가(does anyone want it)'_라는 두 개의 별개 축을 깨달은 것이 가장 명확한 인식의 전환이었으며, 저는 두 번째를 당연하게 가정하면서 첫 번째를 최적화하고 있었습니다.

나는 이것이 진통제(painkiller)라고 스스로 말하면서 비타민(vitamin)을 만들었을지도 모릅니다

제안 내용은 긴급하게 들립니다. 프롬프트 인젝션(prompt-injection)을 막고, 데이터 유출(exfiltration)을 방지하며, 모든 것을 감사(audit)하라는 것입니다. 하지만 한 걸음 물러나 봅시다. 대부분의 개발자는 이미 도구로부터 권한 프롬프트를 받습니다. 그리고 게이트웨이는 실제로 모든 호출을 그곳을 통해 라우팅(route)할 때만 도움이 됩니다. 개인 개발자에게 이것은 아직 겪어보지 못한 위험에 대한 '있으면 좋은 것(nice-to-have)' 정도로 읽힙니다.

더 심각한 구매자 팀은 여러 에이전트에 걸쳐 실제 권한 부여 정책 (authorization policy)과 검증 가능한 감사 추적 (verifiable audit trail)이 필요한 곳들입니다. 그것은 _그들에게_는 '진통제 (painkiller)'가 될 것입니다. 하지만 저는 아직 그 구매자를 검증하지 못했습니다. 그래서 제가 지금 품고 있는 솔직한 의문은 이것입니다: 나는 사람들이 실제로 느끼는 고통을 위해 만들고 있는가, 아니면 내가 흥미롭다고 생각하는 고통을 위해 만들고 있는가?

내 데모는 잘못된 것을 증명하고 있다 (그리고 내가 그것을 만들었다)

나는 깔끔한 60초짜리 데모를 만들었습니다: 에이전트가 오염된 웹 페이지를 읽고, 비밀 정보를 유출하려고 시도하면, 게이트웨이가 이를 차단하는 모습입니다. 보기에는 아주 좋습니다.

그 후 나는 내가 작성한 코드를 읽었습니다. 요청(requests)들은 수동으로 작성되었습니다. "공격"은 하드코딩되어 있었습니다. 집행(Enforcement)은 드라이 런 (dry-run) 모드로 실행되었습니다. 그것은 _의사 결정 로직 (decision logic)_은 충실히 보여주지만, 진정으로 어려운 부분은 연출하고 있습니다: 실제 에이전트를 가로채고 지시가 실제로 어디에서 왔는지 속성을 부여하는 것 (사용자 vs 모델 vs 가져온 콘텐츠) 말입니다. 그 속성 부여 (attribution)가 핵심적인 기술적 주장인데, 데모는 그것을 증명하는 대신 단정 짓고 있습니다.

증명하는 대신 설명만 늘어놓는 데모는, 차라리 데모가 없는 것보다 더 나쁩니다. 왜냐하면 회의적인 독자는 약 1분 만에 그 간극을 발견할 것이고, 이제 그들은 나머지 부분도 믿지 않게 될 것이기 때문입니다. 실제로 가로채고 속성을 부여하는 버전을 만드는 것이 진짜 작업이며, 그것은 여전히 내 앞에 놓여 있습니다.

배포는 구축하는 것보다 훨씬 더 어렵다는 것이 밝혀졌다

나는 구축(build)이 어려운 부분이라고 가정했습니다. 하지만 구축은 쉬운 부분이었습니다.

사람들에게 이것을 보여주려고 시도하며 얻은 몇 가지 구체적인 발견은 다음과 같습니다:

• 관련 서브레딧 (subreddit)에 게시했습니다. 관리자가 아니라 Reddit의 스팸 필터에 의해 즉시 삭제되었습니다. 내 계정의 _카르마 (karma)가 1_이었기 때문입니다. 계정은 5년이나 되었지만 상관없었습니다. 평판이 없으면 게시물도 없습니다.
• 공식 프로토콜 커뮤니티의 디스코드 (Discord)를 살펴보았습니다. 규칙은 다음과 같았습니다: 자기 홍보 금지; 권유는 차단 사유가 되는 위반 행위. 그곳은 기여자/사양 (contributor/spec)을 위한 공간이지, 제품을 보여주는 곳이 아니며, 이는 당연한 일입니다.

패턴이 명확해졌습니다. 이 관문들은 제 프로젝트를 심사하는 것이 아닙니다. 그들은 제가 커뮤니티 내에서 어떤 입지를 가지고 있는지를 심사하고 있으며, 저는 아직 입지가 없습니다. 콜드 스타트 (cold start) 상황을 단순히 홍보만으로 타개할 수는 없습니다. 개발자들에게 도달하는 채널들은 이제 막 시작한 빌더가 쌓을 시간이 없는 바로 그 평판에 의해 제한되어 있으며, 그 평판은 무언가를 제안하는 출시 당일이 아니라, 제안하기 전에 몇 주 동안 참여함으로써 구축되는 것입니다.

내가 아직 확보하지 못한 증거들

이 부분은 제가 진정으로 흥미롭다고 느끼는 지점입니다. 왜냐하면 이는 제가 직접 답을 찾아 나설 수 있는 목록이기 때문입니다:

• Pull (끌어당김): 단 한 명도 먼저 나서서 "이게 필요해요"라고 말하지 않았습니다. '0' 또한 데이터입니다.
• 검증된 구매자 (A validated buyer): 누가 비용을 지불하거나 채택할 것인지에 대한 가설은 있지만, 단 한 번의 실제 대화를 통해서도 이를 테스트하지 못했습니다.
• 핵심 주장에 대한 증거 (Proof of the core claim): Agent_Sudo가 실제 에이전트를 가로채고, 드라이 런 (dry-run)이나 수동으로 만든 요청 없이 스스로 출처 (provenance)를 도출해내는 작동하는 통합 사례.
• 배포 입지 (Distribution standing): 평판이 없는 차가운 계정이 아닌, 그 어떤 형태의 커뮤니티 존재감이라도 있는 상태.

이 중 그 어느 것도 코드에 관한 것이 아니라는 점에 주목하십시오. 이것들은 수요, 증거, 그리고 신뢰에 관한 것입니다. 즉, 제가 아키텍처 (architecture)에 과도하게 투자하는 동안 과소 투자했던 변수들입니다.

이에 대해 내가 하고 있는 일

교훈은 "좋은 코드는 중요하지 않다"가 아닙니다. "좋은 코드는 필수적이지만 결코 충분하지 않으며, 나는 순서를 거꾸로 잡고 있었다"는 것입니다. 그래서 저는 이를 뒤집으려 합니다. 엔진을 다듬는 대신, 누락된 증거들을 직접 찾아 나설 것입니다. 즉, 실제 통합 데모, 실제로 이 문제를 겪을 팀들과의 대화, 그리고 적절한 커뮤니티에 참여자로서 먼저 모습을 드러내는 것입니다.

만약 여러분이 기술적으로는 탄탄하지만 아무도 찾아와 주지 않는 무언가를 출시했거나, 에이전트(agents) 분야에서 일하며 출처 귀속 (provenance attribution)이 어디서 깨지는지에 대한 의견이 있다면, 댓글을 통해 진심으로 의견을 나누고 싶습니다. 코드를 살펴보고 싶다면 리포지토리(repo)는 여기에 있습니다: github.com/Kisyntra/Agent_Sudo.

저는 앞으로 30일 동안 다음과 같은 단순한 질문에 답하는 데 시간을 보낼 것입니다:

누군가 이것을 실제로 채택할 만큼 절실히 필요로 할까요?

그것은 제가 이것을 만들 수 있는지 여부보다 훨씬 더 어려운 질문이며, 지금 시점에서 정말 중요한 질문입니다.