OpenClaw의 내부에서 구동되는 작은 코딩 에이전트 Pi, 그 설계 철학, 확장 방식, 그리고 왜 소프트웨어가 소프트웨어를 만드는 미래를 보여주는지에 대한 글.
written on 2026년 1월 31일
바위 밑에서 살고 있지 않았다면, 이번 주에 내 친구 Peter의 프로젝트 하나가 인터넷에서 폭발적으로 화제가 된 것을 눈치챘을 것이다. 이것은 여러 이름으로 불렸다. 가장 최근 이름은 OpenClaw지만, 뉴스를 통해 접했다면 읽은 시점에 따라 ClawdBot 또는 MoltBot으로 보았을 수도 있다. 이것은 여러분이 선택한 커뮤니케이션 채널에 연결된 에이전트로, 그저 코드를 실행한다.
아마 덜 알려진 사실은 OpenClaw의 내부에서 돌아가는 것이 Pi라는 작은 코딩 에이전트라는 점이다. 그리고 현시점에서 Pi는 내가 거의 전적으로 사용하는 코딩 에이전트이기도 하다. 지난 몇 주 동안 나는 이 작은 에이전트의 전도사가 되어 갔다. 최근에 이 주제로 발표를 한 뒤, 이 블로그에 Pi에 대해 아직 실제로 쓴 적이 없다는 걸 깨달았고, 그래서 내가 왜 여기에 집착하는지, 그리고 이것이 OpenClaw와 어떻게 연결되는지에 대한 맥락을 좀 설명하고 싶어졌다.
Pi는 Mario Zechner가 만들었고, “약간의 광기를 곁들인 공상과학”을 지향하는 Peter와는 달리 1, Mario는 매우 현실적이다. 접근 방식에는 차이가 있지만, OpenClaw와 Pi는 둘 다 같은 아이디어를 따른다. LLM은 코드를 쓰고 실행하는 데 정말 뛰어나니, 이 사실을 받아들이자는 것이다. 어떤 면에서는 이것이 우연이 아니라고 생각하는데, Peter가 작년에 나와 Mario를 이 아이디어와 에이전트에 빠지게 만들었기 때문이다.
그래서 Pi는 코딩 에이전트다. 그리고 코딩 에이전트는 많다. 정말로, 이제는 아무거나 하나 골라도 에이전트식 프로그래밍이 어떤 것인지 충분히 경험할 수 있다고 생각한다. 이 블로그의 리뷰들에서 나는 AMP에 대해 긍정적으로 이야기한 적이 있는데, 내가 AMP에 그렇게 공감했던 이유 중 하나는 그것이 단지 화려한 UI를 둘러싼 제품이 아니라, 에이전트식 프로그래밍에 깊이 빠져 보았고 무엇이 작동하고 무엇이 작동하지 않는지 여러 가지를 실제로 시도해 본 사람들이 만든 제품처럼 느껴졌기 때문이다.
Pi가 내게 흥미로운 이유는 크게 두 가지다:
그리고 작은 보너스 하나: Pi 자체가 아주 훌륭한 소프트웨어처럼 작성되어 있다. 화면이 깜빡이지 않고, 메모리를 많이 먹지 않으며, 무작위로 망가지지 않고, 매우 신뢰할 수 있으며, 소프트웨어에 무엇을 넣을지 세심하게 신경 쓰는 사람이 만들었다.
Pi는 또한 그 위에 자신만의 에이전트를 만들 수 있는 작은 컴포넌트들의 모음이기도 하다. OpenClaw가 그렇게 만들어졌고, 내가 직접 만든 작은 Telegram 봇도 그렇고, Mario가 만든 mom도 그렇다. 무언가에 연결된 자신만의 에이전트를 만들고 싶다면, Pi를 자기 자신과 mom을 향하도록 두기만 해도 하나를 만들어 낼 것이다.
그리고 Pi 안에 무엇이 있는지 이해하려면, Pi에 무엇이 없는지, 왜 없는지, 그리고 더 중요하게는 왜 앞으로도 없을지를 이해하는 것이 훨씬 중요하다. 가장 눈에 띄는 생략은 MCP 지원이다. 여기에 MCP 지원은 없다. 물론 확장으로 만들 수는 있겠지만, MCP를 지원하기 위해 OpenClaw가 하는 방식, 즉 mcporter를 사용하는 방법도 있다. mcporter는 MCP 호출을 CLI 인터페이스나 TypeScript 바인딩을 통해 노출하며, 여러분의 에이전트가 그걸로 뭔가 할 수도 있다. 아니면 안 할 수도 있고, 글쎄 :)
그리고 이것은 게으른 생략이 아니다. 이것은 Pi가 작동하는 방식의 철학에서 나온다. Pi의 전체 아이디어는 에이전트가 아직 하지 못하는 일을 하게 만들고 싶을 때, 확장이나 스킬 같은 것을 다운로드하러 가는 것이 아니라는 점이다. 에이전트에게 스스로를 확장하라고 요청한다. Pi는 코드를 쓰고 실행하는 아이디어 자체를 찬양한다.
그렇다고 해서 확장을 다운로드할 수 없다는 뜻은 아니다. 분명히 지원된다. 하지만 반드시 다른 사람이 만든 확장을 다운로드하도록 권장하는 대신, 이미 존재하는 확장을 가리키며 이렇게 말할 수도 있다. 저기 보이는 저것처럼 만들어 보되, 내가 좋아하는 이런 변경 사항들을 반영해 달라고.
Pi와 더 나아가 OpenClaw가 하는 일을 보면, 점토처럼 형태를 바꿀 수 있는 소프트웨어의 한 예를 볼 수 있다. 그리고 이것은 그 기반 아키텍처에 특정 요구 사항을 부여하는데, 실제로는 시스템에 특정 제약을 만들며, 이것들은 반드시 핵심 설계에 들어가야 한다.
예를 들어 Pi의 기반 AI SDK는 하나의 세션이 실제로 여러 모델 제공자의 다양한 메시지를 담을 수 있도록 작성되어 있다. 세션의 이식성은 모델 제공자들 사이에서 어느 정도 제한된다는 점을 인식하고, 그래서 다른 제공자로 옮길 수 없는 어떤 모델 제공자 전용 기능 집합에 지나치게 기대지 않는다.
둘째, 모델 메시지 외에도 세션 파일 안에 커스텀 메시지를 유지하는데, 이것은 확장이 상태를 저장하는 데 사용되거나, 시스템 자체가 AI에 전혀 보내지지 않거나 일부만 보내지는 정보를 유지하는 데 사용될 수 있다.
이 시스템이 존재하고 확장 상태도 디스크에 영속화할 수 있기 때문에, Pi는 내장된 핫 리로딩을 갖고 있다. 그래서 에이전트가 코드를 쓰고, 다시 불러오고, 테스트하고, 확장이 실제로 동작할 때까지 반복 루프를 돌 수 있다. 또한 에이전트가 스스로를 확장할 때 사용할 수 있는 문서와 예제도 함께 제공된다. 더 좋은 점은 Pi의 세션이 트리 구조라는 것이다. 세션 안에서 분기하고 이동할 수 있어서, 예를 들어 메인 세션의 컨텍스트를 낭비하지 않고도 망가진 에이전트 도구를 고치기 위한 사이드 퀘스트 워크플로를 가능하게 하는 등 온갖 흥미로운 기회를 연다. 도구를 고친 뒤에는 세션을 이전 지점으로 되감고, Pi가 다른 브랜치에서 무슨 일이 있었는지 요약해 준다.
이 모든 것은 중요하다. 예를 들어 MCP가 어떻게 작동하는지 생각해 보면, 대부분의 모델 제공자에서는 MCP용 도구가, LLM용 다른 모든 도구와 마찬가지로, 세션 시작 시 시스템 컨텍스트 또는 그 안의 도구 섹션에 로드되어야 한다. 그러면 도구가 할 수 있는 일을 완전히 다시 불러오는 것이 매우 어렵거나 사실상 불가능해진다. 전체 캐시를 망가뜨리거나, 이전 호출이 왜 다르게 작동하는지 AI를 혼란스럽게 만들지 않고서는 말이다.
Pi의 확장은 LLM이 호출할 수 있도록 도구를 등록할 수 있고, 나는 가끔 이것이 유용하다고 느낀다. 예를 들어 Beads가 구현된 방식은 비판하지만, 에이전트에게 할 일 목록에 접근권을 주는 것은 매우 유용하다고 생각한다. 그리고 나는 로컬에서 동작하는, 에이전트 전용 이슈 트래커를 사용하고 있는데 이것도 내 에이전트가 스스로 만들었다. 에이전트가 할 일도 관리하게 하고 싶었기 때문에, 이 경우에는 CLI 대신 도구를 주기로 했다. 문제의 범위에 적절하다고 느껴졌고, 현재 내 컨텍스트에 추가로 로드하는 유일한 도구이기도 하다.
하지만 대부분의 경우 내가 에이전트에 추가하는 것은 스킬이거나, 내가 에이전트와 더 즐겁게 일할 수 있도록 해 주는 TUI 확장이다. 슬래시 명령을 넘어서, Pi 확장은 터미널 안에서 직접 커스텀 TUI 컴포넌트를 렌더링할 수 있다. 스피너, 진행 막대, 상호작용 파일 선택기, 데이터 테이블, 미리보기 패널 같은 것들이다. TUI는 충분히 유연해서 Mario는 그 안에서 Doom을 실행할 수 있다는 것을 증명했다. 실용적이지는 않지만, Doom을 실행할 수 있다면 분명 유용한 대시보드나 디버깅 인터페이스도 만들 수 있다.
무엇이 가능한지 감을 잡을 수 있도록 내가 만든 확장 몇 가지를 강조하고 싶다. 수정 없이 그대로 사용할 수도 있지만, 전체 아이디어는 사실 여러분이 에이전트에게 이것들 중 하나를 가리키고 마음껏 리믹스하게 하는 데 있다.
/answer나는 plan mode를 사용하지 않는다. 나는 에이전트가 질문하도록 장려하고, 생산적인 주고받기가 일어난다. 하지만 에이전트에게 질문 도구를 주었을 때 생기는 구조화된 질문 대화는 좋아하지 않는다. 설명과 다이어그램이 섞인 에이전트의 자연스러운 산문을 선호한다.
문제는 이렇다. 질문에 인라인으로 답하다 보면 금방 복잡해진다. 그래서 /answer는 에이전트의 마지막 응답을 읽고, 모든 질문을 추출한 뒤, 보기 좋은 입력 상자로 다시 포맷한다.
/todos내가 Beads의 구현을 비판하긴 하지만, 에이전트에게 할 일 목록을 주는 것은 진짜로 유용하다. /todos 명령은 .pi/todos에 markdown 파일로 저장된 모든 항목을 불러온다. 에이전트와 나는 둘 다 이것들을 조작할 수 있고, 세션은 작업을 점유해서 진행 중으로 표시할 수 있다.
/review점점 더 많은 코드가 에이전트에 의해 작성되는 상황에서, 에이전트가 먼저 검토해 보기도 전에 미완성 작업을 인간에게 던지는 것은 별 의미가 없다. Pi 세션은 트리 구조이기 때문에, 나는 새로운 리뷰 컨텍스트로 분기해 결과를 얻고, 그 수정 사항을 다시 메인 세션으로 가져올 수 있다.
UI는 Codex를 모델로 삼아 커밋, diff, 커밋되지 않은 변경 사항, 원격 PR 등을 쉽게 검토할 수 있게 해 준다. 프롬프트는 내가 중요하게 생각하는 것들에 주의를 기울이기 때문에 내가 원하는 지적을 받게 된다. 예를 들어 새로 추가된 의존성을 지적하라고 요청한다.
/control실험은 하지만 적극적으로 사용하지는 않는 확장이다. 한 Pi 에이전트가 다른 에이전트에게 프롬프트를 보낼 수 있게 해 준다. 복잡한 오케스트레이션 없이 동작하는 단순한 멀티 에이전트 시스템으로, 실험에 유용하다.
/files세션에서 변경되었거나 참조된 모든 파일을 나열한다. Finder에서 표시하거나, VS Code에서 diff를 보거나, quick-look 하거나, 프롬프트에서 참조할 수 있다. shift+ctrl+r은 가장 최근에 언급된 파일을 quick-look 해 주는데, 에이전트가 PDF를 생성했을 때 특히 편리하다.
다른 사람들도 확장을 만들었다. Nico의 subagent 확장과 interactive-shell이 있는데, 이것은 Pi가 관찰 가능한 TUI 오버레이 안에서 상호작용형 CLI를 자율적으로 실행할 수 있게 해 준다.
이 모든 것은 여러분이 자신의 에이전트로 할 수 있는 일에 대한 아이디어일 뿐이다. 핵심은 대부분 이것들 중 어느 것도 내가 직접 작성한 것이 아니라는 점이다. 이것들은 내 명세에 맞춰 에이전트가 만들어 냈다. 나는 Pi에게 확장을 만들라고 말했고, Pi는 그렇게 했다. MCP도 없고, 커뮤니티 스킬도 없고, 아무것도 없다. 오해는 말자, 나는 엄청나게 많은 스킬을 사용한다. 하지만 그것들은 어디선가 다운로드한 것이 아니라 내 clanker가 손수 만든 것이다. 예를 들어 나는 브라우저 자동화를 위한 모든 CLI나 MCP를 완전히 대체해서, 그저 CDP를 사용하는 스킬 하나로 바꾸었다. 다른 대안이 작동하지 않아서도 아니고, 나빠서도 아니다. 그냥 이것이 쉽고 자연스럽기 때문이다. 에이전트가 자기 기능을 스스로 유지보수한다.
내 에이전트에는 꽤 많은 스킬이 있고, 중요한 점은 필요 없으면 스킬을 버린다는 것이다. 예를 들어 다른 엔지니어들이 공유한 Pi 세션을 읽는 스킬을 주었는데, 이것은 코드 리뷰에 도움이 된다. 또는 에이전트가 내가 원하는 커밋 메시지와 커밋 방식을 만들고 changelog를 업데이트하는 방법을 돕는 스킬도 있다. 이것들은 원래 슬래시 명령이었지만, 지금은 이것도 똑같이 잘 작동하는지 보려고 스킬로 옮기는 중이다. 또한 Pi가 pip 대신 uv를 사용하도록 돕는 스킬도 있지만, pip와 python 호출을 가로채 uv로 리디렉션하는 커스텀 확장도 추가했다.
Pi 같은 최소주의 에이전트와 작업하면서 내가 느낀 매력의 일부는, 더 많은 소프트웨어를 만드는 소프트웨어를 사용한다는 아이디어를 실제로 살게 만든다는 점이다. 이것을 극단까지 밀고 가면 UI와 출력을 제거하고 채팅에 연결하게 된다. 그것이 OpenClaw가 하는 일이며, 그 엄청난 성장세를 보면, 이것이 어떤 형태로든 점점 더 우리의 미래가 될 것이라는 생각이 강하게 든다.
이 글에는 ai 태그가 달려 있다.