AI 에이전트 안전은 작은 소프트웨어에서 시작해요

Matt Sephton은 2026년 4월 Fits on a Floppy를 발표하면서 일부러 터무니없어 보이는 제약을 내걸었어요. 유용한 소프트웨어라면 표준 3.5인치 플로피 디스크 용량인 1.44 MB 안에 들어가도록 노력해야 한다는 제약이었죠.¹

중요한 것은 용량 제한 자체보다 그 뒤에 있는 태도예요. Sephton은 빠른 다운로드, 즉시 실행, 낮은 메모리 사용량, 낮은 CPU 사용량, 네이티브 코드, 오래된 시스템 지원, 그리고 한 가지 일을 잘하는 도구를 주장해요.¹ 가장 쉬운 해석은 작은 소프트웨어가 사용자를 존중한다는 거예요. 에이전트 시대의 해석은 한 걸음 더 나아가요. 작은 소프트웨어는 AI 코딩 에이전트가 실수를 숨길 공간을 줄여요.

AI 에이전트 안전은 작은 소프트웨어에서 시작해요. 작고 살펴보기 쉬운 시스템은 에이전트가 오해하고, 바꾸고, 권한을 행사하고, 테스트하지 못한 채 실패할 수 있는 공간을 줄이기 때문이에요. 샌드박스와 권한 확인은 여전히 중요해요. 작은 소프트웨어는 안전 경계를 더 앞단으로, 즉 산출물의 형태 자체로 옮겨요.

요약

코딩 에이전트는 맥락이 흐려지기 전에 관련 파일을 읽고, 관련 검사를 실행하고, 관련 diff를 설명할 수 있을 때 가장 잘 작동해요. Anthropic의 Claude Code 가이드는 맥락이 빠르게 차며, 맥락이 찰수록 성능이 떨어진다고 설명해요. 같은 가이드는 검증을 가장 가치 있는 실천으로 꼽고, CLI 도구를 맥락 효율적인 인터페이스라고 설명해요.² OpenAI의 local-shell 문서는 shell 명령을 실행하는 에이전트에는 실행 전에 샌드박스나 엄격한 허용 및 차단 목록이 필요하다고 경고해요.³

작은 소프트웨어는 이런 통제를 대체하지 않아요. 대신 이런 통제를 적용하기 쉽게 만들어요. 작은 도구에는 권한을 부여해야 할 명령이 더 적고, 살펴볼 파일이 더 적고, 신뢰해야 할 의존성이 더 적고, 실행할 테스트가 더 적고, 잘못된 가정이 숨어들 분기가 더 적어요. 오래된 Unix의 교훈은 아직 낡지 않았어요. McIlroy는 “한 가지 일을 하라”는 원칙이 초기의 크기 제약에서 나왔다고 설명했고, 이어서 텍스트 스트림이 프로그램과 사람 모두에게 유용한 보편 인터페이스가 된 이유를 설명했어요.⁴ 에이전트 시스템도 같은 패턴을 다시 발견해요. 에이전트에는 살펴볼 수 있고 조합할 수 있는 표면이 필요하기 때문이에요.

핵심 요점

에이전트 빌더에게: - 넓은 API나 큰 도구 스키마를 추가하기 전에, 명시적인 입력과 출력, 평범한 파일 산출물을 가진 작은 도구를 우선하세요. - 파일 경로, diff, 로그, 테스트를 안전을 다루는 표면으로 보세요. 에이전트도 살펴볼 수 있고, 검토자도 살펴볼 수 있으며, 자동화도 그 기준으로 막을 수 있어요.

소프트웨어 팀에게: - 작은 소프트웨어는 검토 비용을 줄여요. 검토자는 400줄짜리 도구와 그 테스트를 한 번에 이해할 수 있어요. 반대로 거대한 프레임워크는 증거가 있어야 할 자리에 신뢰를 요구해요. - 권한 범위를 실제 동작 가까이에 두세요. 작은 명령은 읽기 전용으로 실행하거나, 한 디렉터리만 쓰거나, 네트워크 접근을 차단할 수 있어요. 범용 명령은 대개 작업에 필요한 것보다 더 큰 권한을 요구해요.

제품 리더에게: - 작은 소프트웨어는 향수가 아니에요. 기계가 너무 많은 코드를 너무 빠르게 만들어낼 수 있는 세계를 위한 거버넌스 패턴이에요. - 기준은 “에이전트가 만들 수 있는가?”에서 “팀이 검증하고, 소유하고, 되돌릴 수 있는가?”로 옮겨야 해요.

작은 소프트웨어가 다시 중요해진 이유

소프트웨어 비대화는 예전에는 사용자 경험 문제처럼 보였어요. 느린 다운로드, 무거운 메모리 사용량, 늦은 실행, 빨리 닳는 배터리, 뒤처지는 오래된 기기가 그 문제였죠. Fits on a Floppy는 의도적으로 물리적인 기준을 통해 이 비판을 눈에 보이게 만들어요. 1.44 MB 배지는 절제를 사용자가 이해할 수 있는 테스트로 바꿔요.¹

AI 코딩 에이전트는 절제가 중요한 이유를 바꿔요. 기계는 사람이 읽는 속도보다 더 빠르게 파일을 만들어낼 수 있어요. 주변 시스템이 양을 진척으로 받아들이면 그 속도는 품질을 약하게 만들어요. 새 의존성 4개가 붙은 2,000줄짜리 기능은 작업 기록에서는 인상적으로 보일 수 있지만, 실제로는 제품 가치를 늘리는 것보다 결함 표면을 더 크게 만들 수 있어요.

작은 소프트웨어는 에이전트에게 더 어려운 목표를 주고, 검토자에게는 더 나은 대상을 줘요. 프롬프트는 하나의 실행 파일, 하나의 데이터 형식, 하나의 테스트 파일, 하나의 롤백 경로를 요구할 수 있어요. 결과물에는 자유도가 더 적게 남아요. 모델은 여전히 실수할 수 있지만, 그 실수가 자신을 위장할 공간은 줄어들어요.

Niklaus Wirth는 코딩 에이전트가 작업 흐름에 들어오기 훨씬 전인 1995년에 A Plea for Lean Software라는 논문을 발표했어요.⁵ 그 제목이 지금도 유효한 이유는 근본적인 실패가 여전히 남아 있기 때문이에요. 팀은 어려운 설계 결정을 피하려고 하드웨어, 의존성, 추상화 계층을 소비해요. 에이전트는 코드를 추가하는 비용을 낮춰요. 그래서 코드를 추가하지 않겠다는 거절이 더 가치 있어져요.

맥락은 안전 예산이에요

에이전트 안전은 흔히 권한 문제로 다뤄져요. 에이전트가 어떤 명령을 실행할 수 있는지, 어떤 파일을 수정할 수 있는지, 어떤 비밀 값을 볼 수 있는지, 어떤 네트워크 호출을 할 수 있는지가 질문이 되죠. 이런 질문은 중요해요. 하지만 에이전트가 작업 중 가장 먼저 부딪히는 제약, 즉 맥락을 전부 설명하지는 못해요.

Anthropic의 Claude Code 모범 사례 가이드는 컨텍스트 창이 대화, 메시지, 읽은 파일, 명령 출력을 담으며, 하나의 디버깅 작업만으로도 수만 토큰을 소비할 수 있다고 설명해요.² 이 가이드는 또한 컨텍스트 창이 차면 Claude가 앞선 지시를 잊기 시작하거나 더 많은 실수를 할 수 있다고 경고해요.²

이 경고는 크기를 안전 속성으로 바꿔요. 작은 코드베이스에서는 에이전트가 관련 표면을 읽어도 관련 없는 파일이 작업 맥락을 압도하지 않아요. 작은 도구에서는 에이전트가 기능, 테스트, 권한 모델, 예외 상황을 동시에 시야에 둘 수 있어요. 작은 diff에서는 검토자가 생성된 움직임 더미를 훑는 대신 실제 변경을 찾을 수 있어요.

맥락 예산에는 실질적인 한계가 3가지 있어요.

큰 시스템도 안전할 수 있어요. 대신 더 강한 분해가 필요해요. 코드베이스 자체가 작을 수 없다면 에이전트가 마주하는 표면은 작아야 해요. 하나의 패키지, 하나의 경계가 있는 하위 시스템, 하나의 공개 명령, 하나의 테스트 대상, 하나의 소유 디렉터리처럼요.

숨은 상태보다 평범한 파일이 나아요

McIlroy의 구술 기록은 오래된 교훈에 날카로운 실용성을 더해요. 그는 “한 가지 일을 하라”는 원칙이 한 가지 이상을 할 공간이 없던 상황에서 태어났다고 설명했고, 원래의 제약이 사라진 뒤에도 팀들이 그 패턴을 유지했다고 말했어요.⁴ 또한 텍스트 스트림이 중요했던 이유도 설명했어요. 사람이 읽을 수 있는 데이터는 디버깅을 덜 고되게 만들었고, 변화하는 텍스트 필드는 고정된 바이너리 레이아웃을 바꾸는 것보다 손이 덜 갔어요.⁴

에이전트에도 같은 종류의 표면이 필요해요. 파일은 나열하고, 검색하고, diff를 보고, 범위 단위로 읽고, 커밋하고, 되돌리고, lint하고, 검토할 수 있어요. 숨겨진 IDE 상태, 불투명한 로컬 데이터베이스, 넓은 호스팅 도구도 유용할 수 있어요. 하지만 그런 것들은 에이전트와 검토자가 쉽게 살펴볼 수 없는 표면을 신뢰하도록 만들어요.

2026년 1월 arXiv 논문은 Unix의 파일 추상화를 에이전트형 AI 시스템과 연결해요. 이 논문은 파일 같은 추상화와 코드 기반 명세가 다양한 자원을 일관되고 조합 가능한 인터페이스로 접어 넣으며, 에이전트 시스템을 더 유지보수 가능하고 감사 가능하며 운영적으로 견고하게 만드는 데 도움을 줄 수 있다고 주장해요.⁶ Oracle의 에이전트 메모리 분석도 비슷한 구분을 해요. 파일시스템 인터페이스는 모델이 저장소, 폴더, Markdown, 로그, CLI 상호작용 같은 개발자 친화적 표면을 이미 이해하기 때문에 잘 작동하지만, 지속 저장소는 여전히 데이터베이스에 속할 수 있다고 설명해요.⁷

이 구분은 중요해요. “파일을 사용하라”는 말은 “모든 것을 느슨한 텍스트로 영원히 저장하라”는 뜻이 아니에요. 더 안전한 패턴은 에이전트 인터페이스와 저장 기반을 분리해요.

에이전트는 가장 작지만 유용한 인터페이스를 봐야 해요. 제품은 그 아래에 더 강한 저장 계층을 유지할 수 있어요.

도구가 적으면 권한도 적어요

MCP 권한 부여 글은 권한 부여의 교훈을 명확히 드러냈어요. bearer token을 검증했다고 해서 사용자가 서버 뒤의 모든 도구를 호출할 수 있다는 뜻은 아니에요.⁸ 작은 소프트웨어는 같은 생각을 설계의 더 이른 단계에 적용해요. 더 작은 도구는 더 좁은 권한을 요청해요.

OpenAI의 local-shell 문서는 위험을 분명하게 말해요. 임의의 shell 명령 실행은 위험할 수 있으며, 빌더는 명령을 system shell로 보내기 전에 실행을 샌드박스 처리하거나 엄격한 허용 및 차단 목록을 추가해야 해요.³ Anthropic의 Claude Code 가이드는 규모가 커질 때의 실용적인 예를 들어요. 파일 전반으로 작업을 나눠 실행할 때는 무인 실행이 작업에 필요한 것 이상을 하지 못하도록 허용 도구 제한을 사용하라고 해요.²

작은 명령은 제한하기 더 쉬워요.

넓은 도구는 넓은 권한을 쌓는 경향이 있어요. 범용 “publish” 명령은 콘텐츠, 번역, 데이터베이스 행, 캐시 제거, 배포 로그, 분석을 모두 건드릴 수 있어요. 때로는 릴리스 명령이 필요해요. 더 안전한 패턴은 릴리스를 각 단계 사이에 명시적인 기준이 있는 더 작은 명령들로 구성하고, 각 단계에 증거가 생긴 뒤에야 그 순서를 자동화하는 거예요.

목표는 일을 느리게 만드는 것이 아니에요. 권한을 보이게 만드는 거예요.

테스트는 도구에 맞아야 해요

Anthropic의 첫 번째 모범 사례 섹션은 사용자에게 Claude가 자기 작업을 검증할 방법을 주라고 말해요. 테스트, 스크린샷, 예상 출력, 명령 검사가 그 예예요.² 작은 소프트웨어는 이 조언을 구체적으로 만들어요. 작은 도구는 작은 검증 계약을 가질 수 있어요.

에이전트가 만든 소프트웨어의 계약은 한 화면에 들어가야 해요.

Inputs:
- one source path
- one output path
- one optional flag

Allowed effects:
- read source path
- write output path
- no network unless --verify-sources is present

Evidence:
- unit tests for parsing
- fixture test for output
- dry-run output for the exact file
- git diff limited to owned paths

이 계약이 중요한 이유는 에이전트가 모호한 요청을 너무 쉽게 충족할 수 있기 때문이에요. “파이프라인을 개선해 주세요”는 구조를 뒤흔드는 변경을 불러요. “이 하나의 명령에 dry-run flag를 추가하고 출력이 파일을 쓰지 않는다는 점을 증명하세요”는 증거 경로를 만들어요.

도구가 작게 유지되면 테스트도 빨라져요. 빠른 테스트는 에이전트의 행동을 바꿔요. 에이전트는 테스트를 더 자주 실행하고, 관련 코드가 아직 맥락 안에 있을 때 실패를 보며, 작업 기록이 흐려지기 전에 근본 원인을 고쳐요. 느린 테스트는 모델을 추측하거나 실행했을 법한 일을 설명하는 쪽으로 밀어내요.

작다는 것은 덜 만든다는 뜻이 아니에요

작은 소프트웨어는 예측 가능한 방식으로 실패할 수 있어요.

플로피 배지는 크기를 측정해요. 에이전트 안전에는 다른 측정이 필요해요. 검토자가 변경을 승인하기 전에 동작, 권한 범위, 증거 경로를 이해할 수 있는가?

이 질문은 도구가 1.44 MB를 넘는 것을 허용해요. 대신 중요한 부분, 즉 우발적인 범위 확장을 거부해요. 안전하고 지루한 20 MB 네이티브 앱이, 검토되지 않은 설치 프로그램을 shell로 실행하는 200 KB 스크립트보다 나을 수 있어요. 작은 소프트웨어는 절제가 실제 실행 경로까지 닿을 때만 안전에 기여해요.

에이전트 작업을 위한 작음 점수표

에이전트가 도구를 만들거나 수정하기 전에 5가지 차원에서 작업을 평가하세요. 목적은 큰 시스템을 벌주는 것이 아니에요. 에이전트가 쓰기 시작하기 전에 분해가 필요한 표면을 찾는 거예요.

빨간 칸이 있다고 해서 작업을 멈춰야 한다는 뜻은 아니에요. 빨간 칸은 에이전트에게 더 작은 작업 단위가 필요하다는 뜻이에요. 작업의 형태가 올바른 동작을 쉽게 증명하게 만들 때 안전은 개선돼요.

실용적인 패턴

제가 신뢰하는 가장 안전한 에이전트 제작 시스템들은 공통된 형태를 가지고 있어요.

1. 하나의 좁은 명령이 하나의 일을 해요.
2. 평범한 파일이 입력, 출력, 로그, 계획, 검토 패킷을 운반해요.
3. 권한은 명령의 실제 효과에 맞춰져요.
4. 테스트는 에이전트가 작업 중 사용할 수 있을 만큼 빠르게 실행돼요.
5. diff는 사람이 검토할 수 있을 만큼 작게 유지돼요.
6. 릴리스 경로는 하나의 버튼 안에 넓은 권한을 숨기지 않고 작은 명령을 조합해요.

No-Build 선언문은 웹 스택 쪽에서 같은 선호를 설명했어요. 더 적은 빌드 계층, 더 적은 생성 산출물, 소스와 실행 환경 사이의 더 짧은 거리가 핵심이었어요.⁹ 에이전트 안전 버전은 다른 독자를 염두에 두고 같은 말을 해요. 계층이 하나 늘어날 때마다 기계는 사람이 빠르게 검증할 수 없는 그럴듯한 작업을 만들어낼 공간을 하나 더 얻어요.

작은 소프트웨어는 절제를 인프라로 바꿔요. 더 좁은 모듈은 맥락 적합성을 높여요. 더 평범한 파일은 감사 가능성을 높여요. 더 빠른 테스트는 피드백을 개선해요. 더 작은 권한 집합은 피해 범위 통제를 개선해요. 더 작은 diff는 사람의 판단을 도와요.

FAQ: 작은 소프트웨어와 에이전트 안전

작은 소프트웨어는 AI 코딩 에이전트를 안전하게 만드나요?

아니요. 작은 소프트웨어는 에이전트가 오해하거나 손상시킬 수 있는 영역을 줄여요. 팀에는 여전히 샌드박스, 허용 및 차단 목록, 테스트, 코드 검토, 자격 증명 경계, 릴리스 기준이 필요해요. 작은 소프트웨어는 이런 통제를 적용하기 쉽게 만들고, 우연히 우회하기 어렵게 만들어요.

에이전트가 마주하는 도구는 얼마나 작아야 하나요?

유용한 한계는 바이트 수가 아니라 검토 가능성이에요. 좋은 에이전트용 도구에는 하나의 일, 작은 입출력 계약, 명확한 권한 프로필, 빠른 테스트, 그리고 검토자가 한 번에 이해할 수 있는 diff가 있어요.

에이전트 메모리에는 파일을 써야 하나요, 데이터베이스를 써야 하나요?

에이전트가 산출물을 살펴보고, 검색하고, diff를 보고, 써야 할 때는 인터페이스로 파일을 사용하세요. 제품에 동시성, 색인, 접근 제어, 내구성, 사용자 간 상태가 필요할 때는 데이터베이스를 사용하세요. 더 안전한 아키텍처는 에이전트가 마주하는 인터페이스와 저장 기반을 분리해요.⁷

MCP는 어디에 맞나요?

MCP는 에이전트가 외부 도구나 데이터로 향하는 typed bridge를 필요로 할 때 맞아요. MCP가 작은 명령, 범위가 제한된 권한, 동작 수준 권한 부여의 필요성을 없애지는 않아요. 서버는 여전히 특정 주체가 특정 동작을 실행할 수 있는지 결정해야 해요.⁸

마무리

AI는 코드를 싸게 만들어요. 싼 코드는 거절의 가치를 높여요.

작은 소프트웨어는 기계가 따를 수 있는 형태로 거절을 제공해요. 하나의 명령, 하나의 출력, 하나의 권한 경계, 하나의 테스트 경로, 하나의 diff예요. 이 형태가 품질을 보장하지는 않아요. 하지만 약한 작업을 더 잘 보이게 만들어요.

이제 제약은 플로피 디스크가 아니에요. 살펴볼 수 있는지가 제약이에요.

참고 문헌