Everything is a File: Unix에서 AI Agent로의 설계 철학

원작 Ethan 业成

반세기를 넘나드는 울림

1970년대 초 벨 연구소(Bell Labs)에서 Unix의 아버지 켄 톰슨(Ken Thompson)과 데니스 리치(Dennis Ritchie)는 대담하다 못해 거의 편집증적인 설계 원칙을 처음으로 제시했습니다. Everything is a file - 만물은 파일이다.

50여 년이 지난 오늘날, AI Agent 프레임워크가 봇물처럼 쏟아지고 있습니다. Manus, Claude Code, OpenClaw... 이들은 서로 다른 팀, 서로 다른 기술 스택, 서로 다른 비즈니스 목표를 가지고 있지만, 모두 같은 선택을 했습니다. 파일 시스템을 Agent의 인지 골격으로 삼는 것입니다.

Manus는 Agent에게 가상 머신을 제공하고, 작업 결과물을 파일로 저장합니다. Claude Code는 사용자 로컬 파일 시스템에서 직접 읽고 쓰며, CLAUDE.md 파일 하나에 모든 명령어와 컨텍스트를 담습니다. OpenClaw 등 오픈 소스 프레임워크 역시 디렉터리 구조로 작업 분해와 중간 상태를 구성합니다.

반세기의 간격을 둔 엔지니어들이 완전히 다른 기술 문제에 직면했지만, 독립적으로 동일한 해법으로 수렴했습니다. 이는 우연이 아니라 설계 철학의 공명입니다.

Unix의 그 결정

이 일의 무게를 이해하려면 먼저 Unix가 무엇을 했는지부터 알아야 합니다.

Unix 파일 시스템의 설계는 컴퓨터 과학 역사상 가장 우아한 설계 중 하나로 인정받고 있습니다. 이는 매우 복잡한 문제를 해결했습니다. 즉, 천차만별의 하드웨어 자원과 데이터 자원을 통일되고 간단한 인터페이스로 관리하는 방법입니다.

1970년대 이전에는 운영 체제가 다음과 같이 작동했습니다. 디스크를 읽으려면 디스크 인터페이스를 호출하고, 자기 테이프를 읽으려면 자기 테이프 인터페이스를 호출하고, 터미널에 액세스하려면 터미널 인터페이스를 호출합니다. 각 장치에는 자체 API가 있고, 각 API에는 자체 의미가 있습니다. N개의 장치와 M개의 작업이 있다면 시스템 복잡도는 N × M입니다.

Thompson과 Ritchie는 어리석을 정도로 단순해 보이는 일을 했습니다.

모든 것을 파일로 만듭니다. open, read, write, close 네 개의 동사로 모든 것을 조작합니다.

핵심 의미는 운영 체제의 모든 자원(문서, 디렉터리, 하드 드라이브, 모뎀, 키보드, 프린터, 심지어 네트워크 연결 및 프로세스 정보)을 파일 스트림(Stream of Bytes)으로 추상화할 수 있다는 것입니다.

즉, open(), read(), write(), close()라는 하나의 API 세트만 배우면 컴퓨터의 모든 자원을 조작할 수 있습니다.

이로써 복잡도는 N × M에서 4 × 1로 붕괴됩니다. 네 개의 동사, 하나의 추상화 계층.

이 일의 천재성은 "파일"이라는 명사에 있는 것이 아니라 더 심오한 통찰력에 있습니다.

파일 설명자 뒤에 무엇이 있는지 알 필요가 없습니다. 인터페이스는 계약입니다.

fd(파일 설명자)는 불투명한 핸들입니다. read()를 하면 바이트 스트림이 나옵니다. 이 바이트가 하드 드라이브 섹터, 네트워크 카드 버퍼 또는 다른 프로세스의 표준 출력에서 ​​나왔는지 여부는 중요하지 않으며, 중요해서도 안 됩니다.

이것이 통일된 인터페이스의 힘입니다. 무지가 강점이 되도록 합니다.

Agent가 직면한 동일한 문제

이제 AI Agent의 상황을 되돌아봅시다.

Agent가 복잡한 작업을 완료하려면 1970년대 운영 체제와 놀라울 정도로 유사한 곤경에 직면합니다.

• 영속적인 기억: LLM의 컨텍스트 창은 휘발성이며, 사고 사슬은 세션과 함께 사라집니다. 마치 프로세스가 종료된 후 메모리가 회수되는 것처럼, 중간 상태를 영속적으로 저장할 장소가 필요합니다. 그렇지 않으면 매번 대화가 처음부터 시작됩니다.
• 점진적인 컨텍스트: 복잡한 작업은 한 번에 완료할 수 없습니다. 에이전트는 여러 번의 추론을 통해 점진적으로 컨텍스트를 축적해야 합니다. 마치 Unix 프로세스가 파일을 읽고 쓰는 방식으로 여러 번의 실행 간에 상태를 전달하는 것과 같습니다. 파일 시스템은 자연스럽게 이러한 "조금 쓰고, 조금 읽고, 다시 조금 쓰는" 점진적인 작업 방식을 제공합니다.
• 도구 및 기술의 통합 스케줄링: 에이전트는 검색, 코드 실행, 이미지 생성 등 이기종 도구(Tools/Skills)를 호출해야 합니다. 마치 Unix가 디스크, 네트워크, 프린터 등 이기종 장치를 관리해야 하는 것과 같습니다. 통합된 추상화 계층이 필요하며, 그렇지 않으면 새로운 도구를 연결할 때마다 새로운 통합 로직을 작성해야 합니다.
• Computer Use의 권한 경계: 에이전트가 컴퓨터를 조작할 수 있는 능력을 가질 때, "무엇을 만질 수 있고, 무엇을 만질 수 없는지"가 생사를 가르는 문제가 됩니다. Unix의 파일 권한 시스템(rwx)은 기존의 샌드박스 모델을 제공합니다. 디렉터리는 경계이고, 권한은 계약입니다.

이 네 가지 요구 사항. 익숙하게 들리시나요?

이는 1970년대 운영체제가 직면했던 문제와 정확히 같습니다.

영속적인 기억 - 파일 시스템은 자연스럽게 해결하며, 쓰기는 영속성을 의미합니다. 점진적인 컨텍스트 - 디렉터리 구조 자체가 증분적으로 구축됩니다. mkdir, touch, append를 통해 컨텍스트가 파일과 함께 성장합니다. 도구 통합 스케줄링 - Unix 파이프라인의 본질: 한 프로세스의 stdout은 다른 프로세스의 stdin이며, 중간 매개체는 바이트 스트림입니다. 에이전트의 도구 체인도 마찬가지입니다. 이전 단계의 출력 파일은 다음 단계의 입력입니다. 권한 경계 - 파일 시스템의 rwx 권한, chroot 샌드박스는 자연스럽게 에이전트의 "능력 범위"를 정의합니다.

따라서 에이전트 프레임워크 설계자가 "에이전트의 작업 상태를 어디에 둘 것인가"라는 문제에 직면했을 때, 답은 거의 정해져 있습니다. 파일 시스템에 넣는 것입니다. 왜냐하면 이 네 가지 제약 조건을 동시에 만족하는 더 간단한 방법이 없기 때문입니다.

시스템이 "대량의 이기종 리소스 상호 작용을 관리"해야 할 때, 두 가지 길이 있습니다.

경로 A: 각 리소스에 대한 전용 인터페이스를 설계합니다. N개의 리소스 × M개의 작업 = NM개의 인터페이스. 정확하지만 폭발적입니다.

경로 B: 모든 리소스가 동일한 옷을 입도록 충분히 얇은 추상화 계층을 찾습니다. 4개의 작업 × 1개의 추상화 계층. 조잡하지만 조합 가능합니다.

Unix는 B를 선택했습니다. 50여 년 후, 에이전트 프레임워크는 다시 B를 선택했습니다.

더 깊은 층: 파일은 사고의 외재화

그러나 "기술 솔루션의 수렴"에만 머무른다면, 더 본질적인 것을 놓치게 됩니다.

인간 자신이 복잡한 작업을 어떻게 처리하는지 회상해 봅시다.

큰 프로젝트를 맡으면, 가장 먼저 하는 일은 일을 시작하는 것이 아니라: 폴더를 만드는 것입니다. 프로젝트 루트 디렉터리, 하위 작업 디렉터리, 참고 자료 디렉터리, 출력 디렉터리. 디렉터리 구조를 사용하여 혼란스러운 작업을 관리 가능한 단위로 분해합니다. 파일 이름을 사용하여 각 단위에 이름을 지정합니다. 파일 내용을 사용하여 사고 과정과 중간 결과물을 기록합니다.

파일 시스템은 단순한 저장 솔루션이 아닙니다. 그것은 인간이 사고를 외재화하는 원시적인 도구입니다.

이 통찰력은 에이전트 프레임워크가 파일 시스템으로 수렴하는 이유를 설명합니다. LLM의 "사고"는 외재화되어야 합니다. 컨텍스트 창이 제한되어 있으므로, 장기 추론은 외부 기억에 의존해야 합니다. 그리고 파일 시스템은 인간이 발명한 가장 보편적인 "외부 기억" 형식입니다.

이 관점에서 보면, Claude Code의 CLAUDE.md는 구성 파일이 아닙니다. 그것은 외재화된 인지 계약입니다. 인간은 의도를 파일에 쓰고, 에이전트는 파일을 읽어 의도를 파악합니다. 파일은 인간의 마음과 인공 지능 사이의 인터페이스 계층이 됩니다.

이는 Unix 파이프라인의 철학과 놀랍도록 일치합니다.

Write programs to handle text streams, because that is a universal interface.## 기본 원리로 돌아가기

위대한 추상화는 낡지 않습니다. 단지 새로운 영역에서 새로운 사례를 찾을 뿐입니다.

"통합 인터페이스는 복잡성을 해소한다"는 것은 Unix의 발명이 아니라 시스템 설계의 영원한 법칙입니다. Unix는 우연히 "파일"이라는 이름으로 이를 구현했습니다. AI Agent는 우연히 "작업 디렉토리"라는 형태로 다시 구현했습니다.

다음 세대 시스템도 다시 같은 선택에 직면하게 될 것입니다. 모든 것에 대해 전용 인터페이스를 설계할 것인가, 아니면 얇고, 범용적이며, 조합 가능한 추상화를 찾을 것인가?

역사가 교훈을 준다면, 답은 이미 /dev/null 옆에 쓰여 있습니다.

Keep it simple. Make it compose. Everything is a file. (간단하게 유지하고, 조합 가능하게 만드세요. 모든 것은 파일입니다.)