왜 점점 더 많은 사람이 클로드 코드 대신 Pi를 쓰나

앞서 OMP에 관한 글을 두 편 썼는데, 한 편은 사용법을, 다른 한 편은 DeepSeek 연동을 다뤘다. OMP는 사실 Pi의 fork이며, OMP를 사용할 때 나는 계속 Pi도 함께 쓰고 있었다.

Pi의 harness는 Claude Code, Codex 같은 비교적 성숙한 AI Coding 도구에 비하면 상당히 작아 보이지만, 그 설계는 매우 정교하다. GitHub의 star 수에서도 그것이 얼마나 뛰어나게 만들어졌는지 알 수 있다. 오늘은 Pi 자체로 돌아가서, 과연 무엇이 좋은지 살펴보자.

Pi란 무엇인가

Pi 공식 홈페이지의 정의에 따르면, Pi의 포지셔닝은 minimal agent harness다. 이는 모델, 도구, 컨텍스트, 세션, 터미널 상호작용을 조직하여 agent가 프로젝트에서 작업할 기본 능력을 갖추게 하고, 사용자가 자신의 워크플로에 맞춰 이 harness를 조정하도록 한다.

공식 홈페이지는 이 설계를 두 문장으로 요약한다. Primitives, not features는 기초 구성 요소를 우선하고 기능을 최대한 적게 미리 넣는다는 점을 강조한다. Adapt Pi to your workflows, not the other way around는 워크플로가 Pi의 형태를 결정해야 한다는 뜻이다.

설치도 간단하다. 우선 공식 홈페이지 첫 페이지에서 자신의 환경에 맞는 설치 방식을 선택하고, 설치가 끝난 뒤 터미널에 pi를 입력해 실행하면 된다.

이어서 Pi의 설계 사상을 간단히 살펴보고, 왜 Pi가 이렇게 좋은 성과를 낼 수 있는지 알아보자.

Pi와 다른 coding agent의 가장 큰 차이

Claude Code, Codex도 각자의 harness가 있지만, 이들은 미리 넣어둔 제품 기능이 더 많아 사용자가 권한 제어, 계획 모드 등의 기능을 바로 쓸 수 있다. Pi는 안정적이고 범용적인 부분을 코어에 남기고 나머지 능력은 확장 계층에 둔다. 두 노선에 절대적인 우열은 없고, 차이는 주로 기본 제공 능력과 설정 비용에 있다.

최소 도구 집합

Pi가 얼마나 단순한가? coding agent 형태에서 Pi는 기본적으로 모델에게 read, write, edit, bash 네 가지 도구만 준다.

나도 처음에는 매우 놀랐다. 네 가지 도구로 충분할까?

Composio와 Databricks의 평가가 마침 이 질문에 답을 준다.

그림 1, Composio가 7월 31일 X에 게시한 Kimi K3 테스트 성공률, 그림 2, 3은 같은 출처.

그림 2, 작업당 평균 비용.

그림 3, 작업당 중위 소요 시간.

그림 4, Databricks benchmark의 비용과 성공률 분포. 가로축은 작업당 평균 비용, 세로축은 전체 통과율.

평가 결과만 보면, Pi는 상당히 눈에 띈다. 일부 작업에서의 성능은 Codex, Claude Code와 겨뤄볼 수 있거나 심지어 능가하기도 한다.

grep, find, ls도 내장 도구이며, 다만 기본적으로 켜져 있지 않을 뿐이다.

도구 역할 기본 제공 read 파일 읽기 예 bash 명령 실행 예 edit 파일 수정 예 write 파일 쓰기 예 grep 파일 내용 검색 아니오, 내장이지만 기본 아님 find 이름으로 파일 찾기 아니오, 내장이지만 기본 아님 ls 디렉터리 나열 아니오, 내장이지만 기본 아님

이 도구들을 쓰고 싶어도 다시 설정할 필요 없이, 아래 명령 한 줄만 실행하면 활성화된다.

pi --tools read ,grep,find, ls -p "Review the code"

--exclude-tools로 개별 도구를 비활성화할 수 있고, --no-builtin-tools로 모든 내장 도구를 끄면서 extension과 사용자 정의 도구는 유지할 수 있다.

grep, find, ls가 왜 기본으로 켜지지 않는지에 대한 공식 설명은 보지 못했다. 내 추측은 기본 bash가 이미 대부분의 shell 능력을 포괄하고 있고, 이 세 가지 전용 도구가 그것과 중복된다는 것이다.

이 선택은 내가 최근 읽은 책에서의 도구 설계에 관한 논의와 매우 가깝다. (책 제목은 AI Agents in Depth이니 관심 있으면 읽어보길 권한다)

read, write, edit, bash는 충분히 기초적이고 범용적이어서, 모델은 자신의 코드 메타 능력과 결합해 이들을 엮어 검색, 수정, 검증 등 여러 작업을 완수할 수 있다. 앞선 평가 결과에서도 Pi가 이 도구들만으로도 작업을 성공적으로 완수할 수 있음을 알 수 있다.

네 가지 도구는 Pi의 기본 출발점일 뿐이고, 진짜 차이는 능력을 어떻게 계속 확장하느냐에 있다.

확장 계층

네 가지 도구로도 많은 작업을 해결할 수 있지만, 안정적인 워크플로를 이루기에는 이것들만으로는 아직 턱없이 부족하다.

기능이 더 완전한 Claude Code, Codex 등 coding agent에서 넘어오면, 첫눈에 Pi가 많은 것을 빼놓은 것처럼 느껴진다. 우리가 평소 자주 쓰는 기능, 예컨대 고정 프롬프트, 전용 도구, 권한 제어에 대한 요구, 그리고 MCP, sub-agent, 권한 확인, plan mode, 내장 할 일 목록, 백그라운드 Bash 같은 것들은 Pi 코어에 직접 들어가지 않고 확장 계층에 놓였다. Pi는 이것들을 extension, skill, prompt template, package로 해결하도록 한다.

예컨대 MCP나 서브에이전트는 기성 package로 연동하거나 extension을 직접 작성할 수 있고, 계획과 할 일 목록은 파일이나 확장으로 담을 수 있다.

Pi 공식 홈페이지는 이 사고방식을 다음 문장으로 표현한다.

Pi isn't a sealed product. If you need a command, tool, provider, workflow, or UI tweak, just ask Pi to build it.

이 네 가지 방식이 처리하는 일은 서로 같지 않다.

유형 해결하는 문제 전형적 내용 extension Pi의 런타임 능력을 바꿈 도구, 명령, 이벤트, 단축키, UI, 권한 흐름 skill 필요할 때 로드하는 일련의 작업 방법, 참고 등을 저장 능력 설명과 실행 단계 prompt template 반복 입력 감소 /name으로 확장되는 Markdown 프롬프트 package 자원 배포 및 조합 extension, skill, prompt, theme

확장 계층의 가치는 필요에 따라 능력을 추가하는 것이고, 대가는 경계를 스스로 관리해야 한다는 점이다. 공식 문서는 extension이 사용자 정의 도구, 서브에이전트, 계획 모드, 권한 제어, 세션 압축, 샌드박스, MCP 등의 능력을 구현하도록 허용한다. package를 설치하기 전에는 먼저 소스와 유지보수 상태를 살펴서 보안 위험이 있는 패키지를 내려받지 않도록 해야 한다.

Pi와 DeepSeek Harness의 설계 이념은 무엇이 다른가?

DeepSeek Harness는 DeepSeek이 공식 오픈소스로 공개한 agent 프레임워크로, 핵심 이념은 Everything is a plugin(모든 것은 플러그인)이다. 이는 사실 Pi의 설계 이념과 매우 비슷하다. 둘 다 모든 능력을 코어에 고정하지 않지만, 관심을 두는 문제는 다르다.

Pi는 coding agent의 기본 코어가 어디까지 줄어들 수 있는지에 관심을 둔다. 먼저 바로 작동할 수 있는 최소 harness를 제공하고, 그다음 추가 도구와 워크플로 능력을 확장 계층에 둔다. 사용자는 안정적인 기본 진입점에서 시작해 자신의 요구에 따라 점차 능력을 늘려간다.

DSH는 agent runtime의 각 부분을 분리하고, 교체하고, 재조합할 수 있는지에 관심을 둔다. 예컨대 모델 연동, 세션 저장, 루프 스케줄링, 인터페이스는 모두 플러그인으로 교체되거나 재조합될 수 있다. 이는 runtime을 편성 가능한 시스템으로 보며, 중점은 고정된 최소 진입점을 제공하는 것이 아니라 사용자가 agent의 구성 방식을 조정할 수 있게 하는 데 있다.

따라서 Pi는 작지만 완전한 coding agent에서 출발해 점차 외부로 확장하는 쪽에 가깝고, DSH는 조합 가능한 runtime에서 출발해 agent의 각 부분을 재조직하는 쪽이다.

이 두 설계 이념에 절대적 우열은 없다. 이미 명확한 coding 워크플로가 있고 작은 코어에서부터 조정하고 싶다면 Pi가 더 직접적이고, agent runtime의 구성 방식을 연구하고 싶거나 더 많은 저수준 모듈을 교체하고 싶다면 DSH의 사고방식이 더 적합하다. 구체적 능력과 사용 방식은 각각의 공식 문서를 다시 확인하면 된다.

Pi를 쓸 때 가장 특별한 점

트리형 세션

상상해 보자. agent에게 어떤 기능을 위한 두 가지 구현 방안을 준비하게 했는데, 첫 번째 방안이 이미 절반쯤 진행된 상태다. 나는 원래 경로를 유지하고, 더 이른 사용자 메시지에서 다른 경로를 갈라져 나와 다른 시도를 하고 싶다면, 이때 Pi에서는 어떻게 할 수 있을까?

먼저 Pi가 세션을 어떻게 제어하게 해주는지 알아보자. Pi는 세션을 JSONL로 기록하는데, 각 레코드에는 id와 parentId가 붙는다. 이 필드들이 이력을 트리로 만든다. /tree는 같은 세션 파일 안에서 과거 노드로 뛰어 돌아가 계속할 수 있고, 원래의 이후 기록은 여전히 남는다. 독립적인 세션을 생성해야 할 때는 /fork를 쓰는데, 이는 사용자 메시지에서 새 세션 파일을 만든다. /clone은 현재 활성 브랜치를 복사하는데, 현재 상태를 통째로 다른 세션으로 가져가기에 적합하다. 이 명령들이 있으면 필요에 따라 유연하게 세션을 제어할 수 있다.

명령 결과 /tree 같은 세션 파일에서 역사 노드로 이동해 계속 /fork 사용자 메시지에서 새 세션 파일 생성 /clone 현재 활성 브랜치를 새 세션 파일로 복사 /export HTML 또는 JSONL로 내보내기 /share 비공개 GitHub Gist로 업로드하고 공유 링크 생성

Pi는 기본적으로 자동 compact를 켜며, 수동으로 /compact를 실행하는 것도 지원한다. 압축은 일부 컨텍스트를 잃지만, 전체 이력은 여전히 JSONL 파일에 보존된다. 압축된 세션은 현재 작업을 계속하기에 적합하며, 압축으로 사라진 세부 내용을 다시 확인하고 싶을 때는 /tree로 역사 노드로 돌아가 살펴볼 수 있다.

그림 5, /tree로 연 Session Tree.

예컨대 이번 예시 세션에서 나는 user:你在跑什么(너는 뭘 돌리고 있어)라는 역사 메시지를 선택한 뒤 엔터를 눌렀다. Pi는 먼저 Summarize branch?를 띄워, 사용자가 No summary, Summarize, Summarize with custom prompt 중에서 선택하게 한다. 되돌아가기 전에 확인 단계가 하나 더 있는데, 노드를 선택하면 원래 노드 뒤의 내용이 처리 대기 중인 브랜치가 되기 때문이다. 세션이 길 때는 요약 여부가 앞으로 볼 수 있는 컨텍스트에 영향을 미치므로, 습관적으로 건너뛰어서는 안 된다.

그림 6, 역사 노드를 선택한 뒤 나타나는 브랜치 요약 옵션.

이어서 입력하는 새 메시지는 여기서부터 이어지고, 원래 노드 뒤의 기록은 여전히 남는다.

그림 7, 역사 노드로 돌아간 뒤의 세션 인터페이스.

이렇게 하면 먼저 첫 번째 구현을 보존하고, 다시 "你在跑什么"라는 노드에서 두 번째 방안을 시도할 수 있다. 두 경로 모두 같은 세션 파일에 남고, 나중에도 /tree로 왔다 갔다 전환할 수 있다. 완전히 새 세션으로 분리하고 싶으면 /fork를, 현재 활성 브랜치를 복사해야 하면 /clone을 쓴다. 트리형 세션은 agent가 반복적으로 시행착오를 겪기에 적합하며, 되돌아가도 원래의 탐색 기록이 사라지지 않는다.

트리형 세션은 탐색 경로 문제를 해결하지만, 자유도가 높을수록 사용자가 떠안는 경계 관리도 많아진다.

권한 경계

능력을 런타임에 넣으면 문제도 따라 변한다. 무엇을 설치하고 무엇을 로드하는지가 Pi가 접할 수 있는 범위에 영향을 준다.

Pi의 공식 보안 문서는 권한 경계를 매우 직설적으로 서술한다.

Pi does not include a built-in sandbox. Built-in tools can read files, write files, edit files, and run shell commands with the permissions of the pi process.

Pi는 기본적으로 실행 사용자와 프로세스의 권한으로 실행되며, 내장 런타임 권한 팝업이 없다. 다만 Pi에는 Project Trust 메커니즘이 있어, 프로젝트 자원이 있는 디렉터리에 처음 들어갈 때 신뢰할지 묻는다. 이는 프로젝트 설정, 자원, package, 확장의 로딩만 제어하고, 이후의 도구 호출은 막지 않는다. read, write, edit, bash를 조합하면 이미 로컬 파일을 읽고 수정하고, 명령을 실행하고, 명령을 통해 외부 서비스에 접근할 수 있다. extension은 도구와 런타임 동작을 계속 바꿀 수도 있다.

Pi를 사용하려면 사용자에게 어느 정도의 위험 판단 능력과 예방 의식이 필요하다. 다음과 같은 위험을 마주할 수 있기 때문이다.

상황 위험 처리 방식 낯선 package 설치 extension이 임의 코드를 실행할 수 있음 설치 전 소스, 출처, 유지보수 상태 확인 낯선 저장소 진입 프로젝트 자원이 agent 능력을 바꿀 수 있음 먼저 자원을 확인한 뒤 해당 프로젝트에 진입할지 결정 고위험 명령 실행 실행 사용자 권한이 너무 클 수 있음 저권한 계정, 컨테이너 또는 Gondolin 등 격리 환경 사용 코드 검색만 필요 쓰기와 실행 능력을 노출할 필요가 없음 pi --tools read,grep,find,ls 사용

Pi 공식 저장소는 Gondolin extension을 격리 예시로 제공한다. 더 강한 경계가 필요할 때는 Pi를 자신이 관리하는 컨테이너, 가상 머신 또는 저권한 계정에서 실행할 수도 있다. 구체적 방안은 프로젝트 위험에 따라 결정해야 하며, 컨테이너 자체도 완전한 보안 보장과 같지는 않다.

코드 검색만 한다면 도구 범위를 좁힐 수 있다. 하지만 서드파티 package를 설치하거나 프로젝트 스크립트를 실행해야 한다면, 소스 코드 검토와 실행 환경을 함께 고려해야 한다. 권한 문제는 설정 파일만으로 해결되는 답이 없다.

권한은 비용의 한 계층일 뿐이고, 시작할 때 어떤 규칙과 도구를 로드하느냐도 유지보수 부담에 영향을 준다.

컨텍스트 로딩

Pi는 시작할 때 프로젝트 디렉터리 전체를 모델에 읽히지 않는다. 대신 먼저 고정된 자원 묶음을 준비하고, 작업이 진행되면서 세션 기록, 사용자 메시지, 도구 결과를 더한다. 이 부분의 내용은 몇 가지 유형으로 나눌 수 있다.

유형 | 로드 내용 | 역할 시스템 프롬프트 | 기본 system prompt, `.pi/SYSTEM.md`, `~/.pi/agent/SYSTEM.md`, `APPEND_SYSTEM.md` | `SYSTEM.md`는 기본 system prompt를 대체하고, `APPEND_SYSTEM.md`는 내용을 덧붙인다 프로젝트 규칙 | `~/.pi/agent/AGENTS.md`, 상위 디렉터리와 현재 디렉터리의 `AGENTS.md` 또는 `CLAUDE.md`, 같은 디렉터리의 `AGENTS.override.md` | 프로젝트 관례를 로드한다; `AGENTS.override.md`는 같은 디렉터리의 `AGENTS.md` 또는 `CLAUDE.md`를 대체한다 도구와 확장 | 기본 `read`, `write`, `edit`, `bash`, 그리고 extension 또는 package를 통해 추가된 도구 | 현재 모델이 호출할 수 있는 기능이 무엇인지 알려준다 세션 상태 | session JSONL, 현재 활성 브랜치, compact가 생성한 요약 | 기존 세션을 복원하고 현재 작업을 이어간다 현재 상호작용 | 사용자 메시지, assistant 응답, 도구 결과 | 현재 이번 라운드의 작업을 추진한다

프로젝트 규칙 파일은 현재 디렉터리만 인식하는 게 아니다. Pi는 먼저 전역 `~/.pi/agent/AGENTS.md`를 읽고, 그다음 현재 작업 디렉터리를 따라 상위 디렉터리를 거슬러 찾아 올라가며, 마지막으로 현재 디렉터리의 `AGENTS.md` 또는 `CLAUDE.md`를 처리한다. 어떤 디렉터리에 `AGENTS.override.md`가 존재하면 그것이 해당 디렉터리의 같은 이름 컨텍스트 파일을 대체하고, 다른 디렉터리의 파일은 계속 병합된다. 이 점은 Claude Code와 매우 비슷한데, 다만 Pi가 원래부터 지원하는 파일 수가 더 많다.

시스템 프롬프트 파일은 또 다른 입구다. 프로젝트 수준 `.pi/SYSTEM.md`와 전역 `~/.pi/agent/SYSTEM.md`는 기본 system prompt를 대체하는 데 쓰이고, `APPEND_SYSTEM.md`는 내용을 덧붙이는 데 쓴다. 기본 컨텍스트만 테스트하고 싶을 때는 `--no-context-files` 또는 `-nc`로 프로젝트 컨텍스트 파일 로딩을 막을 수 있다. Claude Code도 `--system-prompt`로 대체, `--append-system-prompt`로 덧붙이기를 지원하지만, 대체 내용을 매번 시작할 때 전달해야 한다; Pi는 `SYSTEM.md` 파일로 지속적인 대체를 할 수 있다.

Pi의 초기 컨텍스트 점유가 적은 가장 직관적인 이유는 기본 도구 범위가 매우 좁고 기본 시스템 프롬프트가 매우 작기 때문이다. Pi는 또한 MCP, sub-agent, 권한 확인, plan mode 같은 워크플로 기능을 전부 코어에 미리 설치하지 않았다. 이런 기능이 필요할 때 extension, skill 또는 package로 추가한다. 사용자가 직접 설정하고 유지보수해야 하는 대신, 시작할 때는 당장 쓰지 않을 도구 설명과 워크플로 규칙을 미리 로드하지 않아도 된다.

Claude Code는 더 "중후"하다. 즉 사용자가 아직 작업을 시작하지 않았더라도 기본 system prompt, 환경 정보, 내장 도구 설명, 권한 규칙, `CLAUDE.md`, `CLAUDE.local.md`, auto memory 같은 내용을 준비해야 한다. `.claude/rules`나 MCP를 설정하면 시작 컨텍스트는 계속 늘어난다.

따라서 Pi의 초기 컨텍스트 점유가 더 적은 것은 주로 기본 시스템 프롬프트가 작고, 기본 기능이 더 적고, 확장을 필요에 따라 추가하기 때문이다; Claude Code의 초기 컨텍스트 점유가 더 많은 것은 주로 내장 기능과 프로젝트 수준 보조 메커니즘이 더 완전하기 때문이다. 하지만 이는 시작 입력 구성의 차이일 뿐, Pi가 긴 세션에서 반드시 항상 더 적게 점유한다는 뜻은 아니다.

이런 설계 차이는 결국 사용 경험으로 돌아온다. 특히 처음 설정하고 워크플로를 조정할 때 그렇다.

작은 실전

아래에서 실제 설정과 사용 과정을 한 번 살펴보자.

시작할 때, 나는 먼저 Pi 공식 packages 설치 페이지에서 내 워크플로에 맞춰 MCP 어댑터, 네트워크 검색 등 기본 기능을 설치했다(주의: package 안의 extension은 본机 프로세스 권한으로 실행되므로, 설치 전에 출처, 유지보수 상태, 소스 코드를 확인해야 하고, "기능 완전"을 위해 한 번에 많이 설치할 필요는 없다). 내가 필요한 extension, skill, MCP를 설치했는데, 그중에는 Pi를 지속 실행시키는 pi-goal도 포함된다.

필요한 확장을 설치한 뒤, 나는 Pi가 DeepSeek V4 Flash와 함께 간단한 뽀모도로 타이머를 만들게 했다. 나는 먼저 Matt Pocock의 grill-me skill로 요구사항을 정리하고, 최종 goal prompt를 받은 뒤 Pi에 넘겨 바로 실행하게 했다.

실행 과정에서 왼쪽 아래에 표시되는 캐시 적중률이 매우 높은 것을 볼 수 있었고, 때로는 100%까지 가기도 했다.

전체 과정은 약 20분 걸렸다. 첫 goal에서 얻은 프런트엔드 결과는 그리 이상적이지 않았지만, 기능은 꽤 잘 완성되었다.

다음으로 나는 Pi가 taste skill로 프런트엔드를 최적화하게 했다.

전체 흐름은 그리 복잡할 필요가 없고, Claude Code와 Codex를 쓸 때와 사실 비슷하다. 진짜 차이는 설정 책임에 있다. Pi는 확장 기능을 스스로 골라 유지보수해야 한다.

이번 경험은 하나의 전제 조건도 보여준다. 사용자는 harness의 기본 구성을 이해하고, 이미 자신만의 AI coding 워크플로를 형성하고 있는 게 가장 좋다. 그렇지 않으면 아주 작은 기본 코어를 마주하고 무엇을 추가해야 하는지, 어떤 서드파티 package를 신뢰해야 하는지 판단하기 어렵다.

Pi는 누구에게 맞나?

바로 쓸 수 있기를 원하고 도구와 권한 설정을 유지보수하고 싶지 않다면, Claude Code, Codex가 보통 더 편하다. 이미 안정적인 워크플로가 있고, 최소한의 agent에서 시작해 점차 기능을 늘려가고 싶다면 Pi가 더 적합하며, 이전에 쌓아둔 MCP server도 extension 또는 package를 통해 연결할 수 있다.

Pi가 순위표에서 이렇게 강한 성적을 내고, 캐시 적중률이 높고 돈도 아낀다는 걸 보고, 당신도 유행을 따라 그것을 쓰고 싶어질 수 있다. 하지만 나는 AI coding을 막 접한 사람이 Pi를 첫 관문으로 바로 삼는 것은 권하지 않는다. 먼저 기능이 더 완전한 제품으로 실제 프로젝트를 돌려보고, 자신이 자주 쓰는 도구가 무엇인지, 어떤 작업에 승인이 필요한지 파악한 뒤에 Pi를 설정하면 판단이 훨씬 구체적이고 최종 경험도 더 좋아질 것이다.

앞서 말했듯이, 당신은 진짜 필요한 기능을 나열하는 데 도움이 될 AI coding 사용 경험이 필요하고, 이 기능을 extension, skill 또는 외부 환경 중 어디에 넣을지 결정하는 데 도움이 될 harness에 대한 이해도 필요하다. 남이 공유한 package를 설치할 때도 이런 경험이 권한 범위와 유지보수 비용을 판단하는 데 도움이 된다.

요약

Claude Code 또는 Codex가 이미 당신의 워크플로를 안정적으로 커버하고 있다면, 단순히 도구를 바꾸기 위해 마이그레이션할 필요는 없다. Pi는 더 많은 설정과 유지보수 시간을 필요로 하고, 이 비용은 실제로 존재한다.

많은 사람이 Pi를 좋아하는 이유는: 네 개의 기본 도구가 시작점을 충분히 작게 만들고, extension이 프로젝트에 맞춰 도구와 규칙을 조정하도록 허용하기 때문이다.

하지만 여기의 자유도는 권한 검토, package 유지보수, 장애 롤백 문제를 동반한다. 하나라도 빠지면 "커스터마이즈 가능"이 새로운 골칫거리로 바뀔 수 있다.

Pi는 agent harness를 학습하는 데도 적합하다. 그것은 모델 연결, 도구 루프, TUI, 세션 백엔드를 비교적 명확한 몇 개의 package로 나누고, 확장 시스템은 coding-agent package에 내장한다. 이 부분들이 어떻게 맞물리는지 연구하고 싶다면, 저장소 소스 코드와 공식 문서에서 바로 시작할 수 있다. 나는 또한 위에서 공유한 AI Agents in Depth 책을 읽어볼 것을 권한다. 그 책의 2, 4, 5장은 Pi의 설계 사상과도 비슷한 부분이 있다.

⭐️추천 읽을거리:

- 백엔드 개발 학습 + 면접 가이드: Java, 컴퓨터 기초, 데이터베이스, 프레임워크, 시스템 설계 등 백엔드 개발 핵심 지식과 면접 내용을 다룬다.

- AI 애플리케이션 개발 학습 + 면접 가이드: LLM, RAG, Agent, MCP, Prompt, 평가, 시스템 설계 등 AI 애플리케이션 개발 지식과 면접 내용을 다룬다.

- AI 프로그래밍 실전 가이드: Claude Code, Cursor, Codex, Trae 등 도구의 사용 팁과 면접 내용을 다룬다.

JavaGuide

DEV @위챗 공식계정&Github: JavaGuide

237

글

2.2m

조회

42k

팔로워