무슨 일이 있었나요?
Claude Code, Codex CLI, Gemini CLI, Cursor의 에이전트 모드까지, 요즘 터미널에서 돌아가는 코딩 에이전트는 정말 많죠. 그런데 이 와중에 기능을 최대한 적게 넣는다는 반대 방향의 철학으로 만든 에이전트가 있어요. 바로 Pi인데요, 이번에 Earendil 블로그를 통해 1.0 버전이 공개됐어요.
Pi는 자바 게임 프레임워크 libGDX로 잘 알려진 Mario Zechner가 시작한 오픈소스 코딩 에이전트예요. Earendil은 파이썬 웹 프레임워크 Flask를 만든 Armin Ronacher가 세운 회사고요. 개인 AI 비서 프로젝트 OpenClaw가 내부 에이전트 엔진으로 Pi를 쓰면서 이름이 더 알려지기도 했어요. 0.x 시절부터 작지만 단단하다는 평을 들어왔는데, 1.0이라는 버전 번호는 '이제 이 위에 뭔가를 지어도 된다'는 안정화 선언으로 볼 수 있어요.
하네스가 뭐길래?
먼저 용어 하나만 짚고 갈게요. 코딩 에이전트는 크게 두 부분으로 나뉘어요. 하나는 생각을 맡는 LLM(Claude, GPT, Gemini 같은 모델)이고, 다른 하나는 모델에게 파일을 읽히고, 명령어를 실행시키고, 그 결과를 다시 넘겨주는 하네스(harness)예요. 말에 채우는 마구를 떠올리면 쉬운데요, 힘은 말(모델)이 내지만 어디로 어떻게 달릴지는 마구(하네스)가 정해주는 거죠.
같은 모델을 써도 하네스를 어떻게 설계했느냐에 따라 체감 성능이 꽤 달라지거든요. 시스템 프롬프트에 뭘 넣을지, 어떤 도구를 줄지, 대화 기록(컨텍스트)을 어떻게 관리할지가 전부 하네스가 할 일이에요.
Pi의 설계: 도구는 딱 4개
Pi의 가장 큰 특징은 극단적인 미니멀리즘이에요. 기본으로 주는 도구가 read(파일 읽기), write(파일 쓰기), edit(파일 일부 수정), bash(셸 명령 실행) 이렇게 네 개뿐이거든요. 시스템 프롬프트도 아주 짧게 유지하고요.
겨우 그걸로 되나 싶을 수 있는데, 생각해보면 bash만 있어도 grep으로 검색하고, git으로 이력을 보고, 테스트를 돌리고, curl로 API를 부를 수 있잖아요. 요즘 모델들은 셸 사용법을 이미 엄청나게 학습했기 때문에, 전용 도구를 수십 개 붙여주는 것보다 익숙한 셸을 쥐여주는 게 오히려 나을 수 있다는 게 Pi의 생각이에요. 도구 설명이 줄어드니 컨텍스트 창(모델이 한 번에 볼 수 있는 텍스트 양)도 아낄 수 있고요.
그래서 다른 에이전트들이 기본으로 넣어두는 MCP 서버 연동, 서브 에이전트, 플랜 모드, 할 일 목록 같은 기능이 Pi에는 기본으로 들어 있지 않아요. 필요하면 직접 붙여서 쓰라는 거죠.
확장: 에이전트가 자기 자신을 고친다
Pi에서 진짜 재미있는 부분은 여기부터예요. Pi는 TypeScript로 확장(extension)을 만들 수 있는 구조라서, 새 도구를 등록하거나 터미널 UI에 직접 만든 화면을 붙이거나 특정 이벤트에 훅을 거는 식으로 동작을 바꿀 수 있어요.
그리고 이 확장을 Pi에게 직접 작성하게 할 수 있어요. '이 프로젝트에선 커밋 전에 항상 린트를 돌리는 도구가 필요해'라고 말하면, 에이전트가 확장 코드를 써서 자기 자신에게 기능을 추가하는 거예요. 남이 만든 플러그인 마켓에서 고르는 게 아니라, 내 작업 방식에 맞는 도구를 그때그때 만들어 쓰는 셈이에요. 공구함을 사는 대신 작은 대장간을 하나 들여놓는 느낌이죠.
이 밖에도 눈여겨볼 설계가 몇 가지 있어요.
- 여러 모델 제공자 지원: Anthropic, OpenAI, Google 등 여러 회사 모델을 하나의 인터페이스로 다루고, 세션 중간에 모델을 바꿔도 맥락을 이어갈 수 있어요.
- 트리 구조 세션: 대화를 한 줄로 쌓지 않고 나뭇가지처럼 저장해서, 중간 지점으로 돌아가 다른 방향으로 다시 시도할 수 있어요. git 브랜치와 비슷한 개념이에요.
- 라이브러리로 나뉜 구조: LLM 호출 계층, 에이전트 루프, 터미널 UI가 각각 패키지로 나뉘어 있어서, 코딩 에이전트가 아닌 제품에 Pi의 엔진만 가져다 쓸 수 있어요. OpenClaw가 바로 그렇게 만들어졌고요.
업계 맥락: 더하기 vs 빼기
지금 코딩 에이전트 시장은 대체로 기능을 계속 더하는 경쟁을 하고 있어요. Claude Code는 서브 에이전트, 훅, 스킬, 플러그인을 계속 추가하고 있고, Cursor나 Codex도 기능 목록이 점점 길어지고 있죠. 이런 올인원 도구는 설치하자마자 바로 쓸 수 있다는 장점이 커요. 대신 내부 동작이 블랙박스처럼 느껴지고, 업데이트 때마다 시스템 프롬프트나 도구 정의가 바뀌면서 어제 잘 되던 워크플로가 오늘은 미묘하게 달라지기도 해요.
Pi는 그 반대편에 서 있어요. 코어가 작으면 컨텍스트에 뭐가 들어가는지 사용자가 전부 알 수 있어서 동작을 예측하기 쉽거든요. OpenCode나 Aider 같은 오픈소스 에이전트도 비슷한 결이지만, Pi는 그중에서도 '확장 가능한 최소 커널'이라는 위치를 가장 분명하게 잡은 편이에요. 리눅스 커널과 배포판처럼, Pi는 커널 역할만 하고 사용자가 그 위에 각자 자기 배포판을 만드는 방식이죠.
다만 트레이드오프도 분명해요. 기본 설정이 권한 확인 없이 바로 실행하는 쪽에 가까워서, 아무 데서나 그냥 돌리면 위험할 수 있어요. 컨테이너나 샌드박스 안에서 쓰는 습관을 들이는 게 좋아요.
한국 개발자에게 주는 시사점
첫째, 에이전트를 쓰는 것을 넘어 이해하고 싶다면 Pi는 아주 좋은 교재예요. 코드베이스가 작아서 에이전트 루프가 어떻게 돌아가는지, 도구 실행 결과가 어떻게 다시 모델로 들어가는지 하루 이틀이면 따라 읽을 수 있거든요.
둘째, 사내 전용 에이전트를 만들려는 팀에게 좋은 출발점이에요. 사내 배포 시스템이나 위키, 코드 컨벤션에 맞춘 도구를 확장으로 붙이면 되니까요. 특정 벤더에 묶이지 않고 여러 모델을 바꿔 쓸 수 있다는 점도 보안·비용 정책이 까다로운 국내 기업 환경에서는 장점이에요.
셋째, 1.0이 나왔다는 건 확장 API가 예전보다 덜 바뀔 거라는 뜻이기도 해서, 지금 확장을 만들어 두기에 괜찮은 시점이에요.
마무리
한줄 정리: Pi 1.0은 기능이 많은 에이전트가 좋다는 통념에 '작게 만들고, 쓰면서 직접 키워라'라고 답하는 프로젝트예요.
여러분은 어느 쪽이 더 손에 맞나요? 기능이 꽉 찬 올인원 에이전트가 편한가요, 아니면 작은 코어 위에 내 워크플로를 직접 쌓아 올리는 쪽이 더 끌리나요? 지금 쓰는 에이전트에서 빼버리고 싶은 기능이 있다면 댓글로 공유해주세요!
🔗 출처: Hacker News