Transcript
00:00:00현재 터미널 점유율을 두고 경쟁하는 두 가지 강력한 오픈 소스 AI 코딩 에이전트가 있습니다.
00:00:04잘못된 선택을 하면 나중에 전체 워크플로우를 새로 구축해야 할 수도 있습니다.
00:00:10하나는 필요한 모든 기능을 즉시 제공하는 반면, 다른 하나는
00:00:14거의 아무것도 제공하지 않는 것이 핵심이라고 주장합니다. 오늘은
00:00:19Open Code와 Pi를 정면으로 비교해 보겠습니다.
00:00:21이 영상이 끝날 때쯤이면 여러분의 터미널에 어떤 도구가 적합할지 확실히 알게 될 것입니다.
00:00:27먼저 이 도구들의 정체부터 알아보죠.
00:00:30두 도구는 동일한 핵심 문제를 근본적으로 다른 방식으로 해결하기 때문입니다.
00:00:34Open Code와 Pi는 모두 터미널 기반의 AI 코딩 에이전트입니다. 터미널에서 실행하며,
00:00:40Claude나 GPT 같은 대규모 언어 모델에 연결하여 코드를 읽고,
00:00:45파일을 편집하고, 셸 명령을 실행하며, 코드베이스에 대해 심도 있는 대화를 나눌 수 있습니다.
00:00:50Claude Code의 오픈 소스 대안이라고 생각하시면 됩니다.
00:00:55둘 다 TypeScript로 작성되었고, MIT 라이선스이며, 20개 이상의
00:01:01LLM 제공업체를 지원하지만, 유사점은 거의 거기까지입니다. Open Code는
00:01:06Terminal.shop의 제작자와 NeoVim 애호가 커뮤니티에 의해 개발되었습니다.
00:01:11이 도구는 이른바 '배터리 포함(batteries included)' 방식을 취합니다.
00:01:15설치 즉시 다양한 작업을 위한 전문 에이전트가 포함된 멀티 에이전트 시스템,
00:01:20승인 대화 상자가 있는 내장 권한 시스템, 코드 지능을 위한 LSP(Language Server Protocol)
00:01:24통합, 외부 도구 연결을 위한 전체 MCP(Model Context Protocol) 지원,
00:01:29세션 유지를 위한 SQLite 데이터베이스, 그리고 심지어
00:01:34터미널 인터페이스와 병행할 수 있는 Tauri 기반 데스크톱 앱까지 제공합니다.
00:01:40Open Code의 철학은 코딩 에이전트가 합리적인 기본 설정과 깊은 통합을 통해
00:01:45즉시 잘 작동해야 한다는 것입니다. 반면 Mario Zechner가 만든 Pi는
00:01:51정반대의 접근 방식을 취합니다. 그 철학은 README에 명확히 명시되어 있습니다.
00:01:56“Pi는 매우 공격적으로 확장 가능하므로 워크플로우를 강요하지 않습니다.”
00:02:00Pi는 의도적으로 보조 에이전트, MCP 지원, 권한 시스템,
00:02:05플랜 모드, 내장 할 일 추적 기능 없이 출시되었습니다. 대신
00:02:11강력한 확장 API를 제공하여 정확히 필요한 것을 직접 구축하거나,
00:02:17자신의 방식대로 작동하는 커뮤니티 패키지를 설치하도록 합니다. 핵심은 최소한으로 유지하고 나머지는 선택 사항입니다.
00:02:22이 두 프로젝트는 개발자 도구 설계에 대한 진정한 철학적 갈림길을 보여줍니다.
00:02:27각각의 기술적 세부 사항을 살펴보고 직접 비교해 보겠습니다.
00:02:32먼저 Open Code의 아키텍처부터 시작하죠.
00:02:36Open Code는 약 21개의 패키지로 구성된 모노레포입니다.
00:02:42핵심 엔진은 단일 패키지에 있지만, 웹 콘솔, 데스크톱 앱,
00:02:46TypeScript SDK, 플러그인 시스템, 공유 UI 컴포넌트,
00:02:52그리고 문서화를 위한 별도의 패키지들이 존재합니다. 내부적으로는 Bun을 사용하는데,
00:02:57이는 시작 및 실행 속도 면에서 Node보다 훨씬 빠릅니다. LLM
00:03:02추상화 계층의 경우, Open Code는 다재다능한 Vercel AI SDK 버전 5를 사용합니다.
00:03:08이는 수십 개의 제공업체에 통합 인터페이스를 제공하는 잘 관리된 라이브러리입니다.
00:03:13이로써 Open Code는 Vercel SDK가 새로운 통합을 추가함에 따라
00:03:18제공업체 지원을 거의 공짜로 얻게 되는 실질적인 이점이 있습니다.
00:03:24Open Code의 돋보이는 기능 중 하나는 멀티 에이전트 시스템입니다.
00:03:30여러 전문 에이전트가 함께 제공되는데, 빌드 에이전트가 기본이며,
00:03:35무엇이든 읽고 쓰고 실행할 수 있는 전체 권한 개발 에이전트입니다. 플랜 에이전트는
00:03:40읽기 전용으로 설계되어 변경 없이 코드를 탐색하고 분석합니다.
00:03:45특정 플랜 디렉토리에만 쓸 수 있습니다. 익스플로러 에이전트는 코드베이스
00:03:50탐색을 위한 빠르고 가벼운 전문가로, 검색 및 읽기 작업으로 제한됩니다.
00:03:55또한 복잡한 다단계 작업을 위해 하위 에이전트로 작동하는 일반 에이전트가 있습니다.
00:04:00사용자는 탭 키로 에이전트를 전환하며, 각 에이전트는 고유한 권한 규칙 세트를 갖습니다.
00:04:05설정 파일에서 어떤 모델을 사용할지, 어떤 권한을 가질지,
00:04:09시스템 프롬프트가 무엇인지 지정하여 커스텀 에이전트를 정의할 수도 있습니다.
00:04:14데이터 유지를 위해 Open Code는 Drizzle ORM과 함께 SQLite를 사용합니다.
00:04:19세션, 메시지, 권한 및 MCP 자격 증명이 모두 단일 데이터베이스 파일에
00:04:25저장됩니다. 이는 의미 있는 아키텍처 선택입니다. SQLite는
00:04:30트랜잭션 무결성, 세션 간 효율적인 쿼리, 그리고 백업이 쉬운
00:04:35단일 파일을 제공합니다. Open Code는 더 나은 동시 읽기 성능을 위해 WAL 모드로 실행합니다.
00:04:41Open Code의 권한 시스템은 계층화되어 있고 세밀합니다.
00:04:46모든 도구 호출은 권한 확인을 거칩니다. 도구별, 파일 패턴별로 규칙을 설정할 수 있습니다.
00:04:52예를 들어, 모든 파일 읽기는 허용하되 .env 파일 편집은 승인을 요구하고,
00:04:57프로덕션 디렉토리를 건드리는 셸 명령은 완전히 거부할 수 있습니다.
00:05:03권한은 글로벌 사용자 설정부터 프로젝트별 오버라이드까지 여러 설정 수준을 통해 적용됩니다.
00:05:08에이전트가 승인이 필요할 때 터미널에 대화형 대화 상자를 표시하며,
00:05:13사용자는 해당 작업을 한 번만 허용하거나 항상 허용하도록 선택할 수 있습니다.
00:05:18MCP 통합은 모든 기능을 갖추고 있습니다. Open Code는 로컬 및 원격 MCP 서버에
00:05:24모두 연결할 수 있습니다. STDIO 및 HTTP 전송을 지원하고, 원격 서버를 위한
00:05:30OAuth 인증을 처리하며, 연결된 MCP 서버의 도구를 자동으로 등록합니다.
00:05:37이미 다른 도구에서 MCP 서버를 사용 중이라면 Open Code에서도 즉시
00:05:42작동할 것입니다. 또 다른 주목할 만한 기능은 내장된 LSP 지원입니다.
00:05:47Open Code는 TypeScript, Python, Go, Rust 등을 위한
00:05:53LSP 서버를 구동할 수 있습니다. 이를 통해 AI 모델은 단순히 텍스트 패턴
00:05:58매칭에 의존하는 대신 호버 정보, 정의 이동, 심볼 참조와 같은
00:06:04실제 코드 지능에 접근할 수 있습니다. 이는 코드 이해 정확도 측면에서
00:06:10작지만 의미 있는 우위입니다. Open Code는 또한 Claude Code의
00:06:15스킬 형식과 호환되는 스킬 시스템을 갖추고 있습니다. 스킬은 전문화된 동작을
00:06:20정의하는 프론트 매터가 포함된 마크다운 파일이며, NPM 패키지 기반의
00:06:25플러그인 시스템은 설정 로드부터 메시지 변환, 도구 실행에 이르기까지
00:06:30라이프사이클의 거의 모든 부분에 개입할 수 있습니다. 이제 Pi의 아키텍처를 살펴보죠.
00:06:35Pi 역시 모노레포이지만 구조가 다릅니다. 주요 패키지로는 코딩 에이전트 본체,
00:06:40LLM 추상화 계층인 Pi-I, 상태 기반 에이전트 런타임인 Pi-agent-core,
00:06:45그리고 터미널 렌더링 에이전트인 Pi-2e가 있습니다. 또한 Slack 봇 동료인
00:06:51PiMom과 GPU 배포를 위한 PiPods가 있습니다. Pi에서 가장 중요한 기술적 결정은
00:06:57Vercel AI SDK를 사용하는 대신 자체 LLM 추상화 계층을 처음부터 구축했다는 점입니다.
00:07:02Pi-I는 Vercel AI SDK가 다루지 않는 Minimax, Kimi를 포함하여
00:07:0830개 이상의 제공업체를 지원하는 통합 멀티 제공업체 LLM API입니다.
00:07:12자체 레이어를 구축함으로써 Pi 팀은 스트리밍 동작, 도구 호출 파싱,
00:07:20그리고 제공업체별 최적화를 완벽하게 제어할 수 있습니다. 유지 관리 부담이라는
00:07:24트레이드오프가 있지만, 도구 인자 스트리밍 중 부분 JSON 파싱과 같은
00:07:30기능을 원하는 방식대로 구현할 수 있음을 의미합니다.
00:07:35Pi의 세션 관리는 각 줄이 JSON 객체인 평면 파일인 JSONL 형식을 사용합니다.
00:07:40모든 항목에는 ID와 상위 ID가 있어 단일 파일 내에서 트리 구조를
00:07:44가능하게 합니다. 이는 영리한 방식입니다. 대화를 분기하고,
00:07:50전체 기록 트리를 탐색하며, 표준 Unix 도구로 쉽게 검사할 수 있는
00:07:56단일 파일 내에서 모든 지점 사이를 이동할 수 있습니다. tree 명령어로
00:08:00전체 대화 기록을 시각화하고 어떤 지점으로든 이동할 수 있습니다. fork 명령어는
00:08:06어떤 메시지에서든 새로운 분기를 생성합니다. 코딩 에이전트에서 본 것 중
00:08:12진정으로 뛰어난 대화 관리 인터페이스 중 하나입니다.
00:08:17Pi의 확장 시스템은 그 철학이 진정으로 살아나는 부분입니다. 확장은 JITI에 의해
00:08:23직접 로드되는 TypeScript 파일이므로 컴파일 단계가 없습니다.
00:08:28확장은 커스텀 도구, 명령어, 키보드 단축키를 등록할 수 있습니다.
00:08:33세션 시작, 에이전트 시작, 도구 호출, 모델 선택과 같은 라이프사이클 이벤트를
00:08:38구독할 수 있습니다. 확인 대화 상자, 선택 메뉴, 텍스트 입력 프롬프트를 통해
00:08:44사용자와 상호 작용할 수 있으며, 커스텀 TUI 컴포넌트를 렌더링할 수도 있습니다.
00:08:49확장 API는 세션 관리자, 모델 레지스트리, 인증 저장소 및 이벤트 버스에 대한
00:08:55접근 권한을 제공합니다. 즉, 확장은 핵심 기능이 할 수 있는 모든 것을
00:09:01본질적으로 수행할 수 있습니다. 여기서 Pi의 의도적인 생략이 이해되기 시작합니다.
00:09:06내장 권한 시스템이 없나요? 위험한 명령 전에 확인 대화 상자를 보여주는
00:09:11확장을 작성하면 됩니다. 하위 에이전트가 없나요? TMUX를 통해 Pi 인스턴스를
00:09:16생성하거나 여러 에이전트 루프를 조정하는 확장을 작성하면 됩니다. MCP가 없나요?
00:09:20CLI 도구와 README로 스킬을 구축하거나 MCP 지원을 추가하는 확장을
00:09:27작성하세요. 플랜 모드가 없나요? 마크다운 파일에 플랜을 쓰거나 원하는 방식으로
00:09:33플랜을 관리하는 확장을 구축하세요. Pi의 터미널 렌더링 또한 커스텀으로 구축되었습니다.
00:09:40pi2e 패키지는 화면 업데이트를 최소화하기 위해 세 가지 전략이 포함된 차분 렌더링을
00:09:45구현하며, 깜박임을 제거하는 원자적 업데이트를 위해 CSI 2026 프로토콜을 사용합니다.
00:09:51컨테이너, 에디터, 텍스트 렌더링, 마크다운 표시, 이미지 지원 및 선택 목록이
00:09:56포함된 자체 컴포넌트 시스템을 갖추고 있습니다. 코딩 에이전트의 TUI는 전적으로
00:10:02이 프레임워크 기반으로 구축되었습니다. 도구 처리의 경우, Pi는 READ, bash,
00:10:07edit, write, grep, find, ls라는 7개의 내장 도구만 제공합니다. 이는 의도적으로
00:10:13최소화된 구성입니다. bash 도구는 선택적 Docker 샌드박싱과 실시간 스트리밍
00:10:18출력을 지원합니다. edit 도구는 unified diff 형식을 사용합니다. 모든 도구는 실행 전
00:10:25AJV로 인자를 검증하며 기본적으로 병렬 실행을 지원합니다. 즉,
00:10:30LLM의 여러 도구 호출이 하나씩 차례로 실행되는 대신 동시에 실행됩니다.
00:10:36이제 가장 중요한 차원들에서 이 두 도구를 직접 비교해 보겠습니다.
00:10:42제공업체 지원: 둘 다 20개 이상의 제공업체를 지원하며 모든 OpenAI
00:10:48호환 API와 작동합니다. Open Code는 Vercel AI SDK를 사용하여
00:10:53에코시스템 성장에 따른 새로운 제공업체 지원을 그대로 물려받습니다. Pi는
00:10:59자체 Pi-I 라이브러리를 구축하여 제어력은 높지만 새 제공업체를 수동으로
00:11:06통합해야 합니다. 실제로는 둘 다 주요 제공업체를 모두 커버합니다.
00:11:12에이전트 모델: Open Code는 여러 전문 에이전트를 포함하고 키 하나로
00:11:18에이전트 전환이 가능합니다. Pi는 단일 에이전트만 제공하며 하위 에이전트가
00:11:22필요하다면 확장으로 구축하거나 별도 인스턴스를 띄우라고 합니다.
00:11:27즉시 제공되는 전문화된 모드를 원한다면 Open Code가 승자입니다.
00:11:33에이전트 토폴로지를 직접 구축하고 싶다면 Pi가 그 도구를 제공합니다.
00:11:37Open Code는 SQLite를, Pi는 JSONL 파일을 사용합니다.
00:11:42SQLite는 트랜잭션 무결성과 효율적인 쿼리를 제공하며, JSONL은 cat이나
00:11:47grep으로 검사할 수 있는 사람이 읽기 쉬운 파일을 제공합니다. Pi의 트리 구조는
00:11:53매우 우아합니다. 둘 다 세션 분기 및 포크를 지원하지만, Pi의 트리 탐색
00:11:58인터페이스는 대화 기록 탐색에 특히 잘 설계되어 있습니다. Open Code는
00:12:04승인 대화 상자, 파일별 규칙, 영구 권한 메모리가 포함된 포괄적인 내장
00:12:08시스템을 갖추고 있습니다. Pi는 핵심에 권한 시스템이 없으며 확장이 이를
00:12:13처리하도록 합니다. 즉각적인 안전 장치를 원한다면 Open Code가 더 안전한 선택입니다.
00:12:19컨테이너에서 실행하거나 보안 모델을 완벽히 제어하고 싶다면 Pi의 방식이
00:12:25더 많은 유연성을 제공합니다. MCP 지원: Open Code는 OAuth, 다중 전송,
00:12:30자동 도구 등록을 포함한 전체 MCP 지원을 제공합니다. Pi는 핵심에서
00:12:35README로 문서화된 CLI 도구인 스킬을 선호하며 MCP를 명시적으로 거부합니다.
00:12:41Mario Zechner는 블로그 글에서 MCP가 불필요한 복잡성을 더한다고 주장하며
00:12:48README가 있는 간단한 CLI 도구로 충분하다고 말합니다. 기존 워크플로우가
00:12:54이미 MCP 서버에 의존한다면 Open Code가 확실한 선택입니다. 작고 조합 가능한
00:13:00도구라는 Unix 철학을 선호한다면 Pi의 방식이 더 와닿을 수 있습니다.
00:13:04코드 지능: Open Code는 내장된 LSP 통합을 통해 AI 모델에게 타입 정보,
00:13:10정의 및 참조에 대한 접근을 제공합니다. Pi는 핵심에 LSP를 포함하지 않습니다.
00:13:16이는 타입 컨텍스트가 AI의 이해도를 높여주는 정적 타입 언어 작업에서
00:13:22Open Code에 상당한 우위를 제공합니다. 터미널 인터페이스: 둘 다 정교한
00:13:28커스텀 TUI 구현을 가지고 있지만 방식이 다릅니다. Open Code는 OpenID 프레임워크와
00:13:32Solid.js를 사용합니다. Pi는 차분 렌더링이 포함된 자체 Pi2E 프레임워크를 사용합니다.
00:13:37둘 다 보기 좋고 반응이 빠릅니다. Open Code는 추가로 Tauri 기반 데스크톱 앱과
00:13:42웹 콘솔을 제공합니다. Pi는 터미널 전용이지만 개발자가 애플리케이션에
00:13:48포함할 수 있는 웹 컴포넌트 라이브러리를 제공합니다. 둘 다 프로젝트 및
00:13:53글로벌 수준의 JSON 기반 설정을 사용합니다. Open Code는 주석이 가능한
00:13:58JSONC를 사용하며, Pi는 표준 JSON을 사용합니다. 둘 다 모델, 도구 및 동작의
00:14:03광범위한 커스터마이징을 지원합니다. Open Code는 설정할 수 있는 범위가 넓어
00:14:07설정이 더 복잡하고, Pi는 내장된 영역이 적어 더 간단합니다. 그렇다면
00:14:14어떤 것을 선택해야 할까요? 스스로에게 다음 질문들을 던져보세요.
00:14:19설치 즉시 완벽한 기능을 갖춘 도구를 원하시나요, 아니면 직접 워크플로우를
00:14:26조립하는 것을 선호하시나요? 코딩 에이전트를 설치하고 5분 안에
00:14:31권한, 멀티 에이전트, MCP, LSP 등 다듬어진 경험을 원한다면 Open Code가
00:14:35적합합니다. 반면 필요에 맞게 정확히 커스터마이징하는 최소한의 코어를 원하고
00:14:39TypeScript 확장을 직접 작성하는 데 거부감이 없다면 Pi가 정답입니다.
00:14:45워크플로우에서 MCP가 얼마나 중요한가요? MCP 서버를 이미 사용 중이거나
00:14:49계획이 있다면 Open Code는 이를 네이티브로 지원합니다. Pi는 의도적으로
00:14:56지원하지 않으며 더 간단한 CLI 기반 통합을 선호합니다. 주로 정적 타입
00:15:01언어로 작업하시나요? Open Code의 내장 LSP 지원은 AI 모델에게 더 풍부한
00:15:06코드 이해를 제공하며, 이는 TypeScript, Go, Rust 등에서 특히 중요합니다.
00:15:11주로 Python이나 동적 타입 언어를 사용한다면 이 이점은 상대적으로 적습니다.
00:15:16데스크톱 앱이나 웹 인터페이스가 필요한가요? Open Code는 터미널과 함께
00:15:22두 가지를 모두 제공하지만, Pi는 터미널 전용이며 이를 자랑스럽게 여깁니다.
00:15:28신뢰와 샌드박싱에 대해 어떻게 생각하시나요? 에이전트가 위험한 작업을 하기 전
00:15:34묻기를 원한다면 Open Code의 권한 시스템이 이를 즉시 해결해 줍니다.
00:15:39에이전트 전체를 Docker 컨테이너에서 실행하고 그 안에서 무엇이든 하도록
00:15:44두는 쪽이라면, Pi의 권한 없는 접근 방식이 컨테이너 기반 워크플로우와 잘 맞습니다.
00:15:51모든 것을 커스터마이징하고 싶은 파워 유저인가요? Pi의 확장 시스템은
00:15:55놀라울 정도로 강력합니다. 도구 실행부터 세션 관리, TUI 자체에 이르기까지
00:16:00에이전트 동작의 거의 모든 측면을 수정할 수 있습니다. Open Code에도
00:16:04플러그인 시스템이 있지만 전체적인 동작 재정의보다는 특정 훅에 집중되어 있습니다.
00:16:10솔직한 결론은 이렇습니다. Open Code는 현재 더 성숙하고 기능이 풍부한
00:16:15제품입니다. 더 많은 기본 기능을 제공하고, 외부 시스템과 더 많이 통합되며,
00:16:20진입 장벽이 낮습니다. 오픈 소스 AI 코딩 에이전트를 원하는 대부분의 개발자에게
00:16:25Open Code가 더 안전한 선택입니다. Pi는 설계가 더 흥미로운 도구입니다.
00:16:30공격적인 미니멀리즘과 확장 우선 철학으로 독특한 적응력을 보여줍니다.
00:16:34코드 한 줄 쓰기 전에 NeoVim 설정을 몇 주 동안 만지는 개발자이거나,
00:16:40자신이 생각하는 방식대로 정확히 작동하는 에이전트를 원한다면 Pi가
00:16:44그 투자에 보답할 것이며, 세션 트리 탐색은 진정으로 업계 최고 수준입니다.
00:16:49두 프로젝트 모두 MIT 라이선스이고 활발하게 유지 관리되고 있으며,
00:16:55동일한 광범위한 LLM 제공업체를 지원합니다. 오후 한나절이면 두 도구 모두
00:17:01테스트해 볼 수 있습니다. 코드는 GitHub에 있고 시작하는 데 구독이
00:17:05필요하지도 않습니다. 설치해서 동일한 코드베이스에서 실행해 보고,
00:17:09자신의 작업 방식에 어떤 것이 더 잘 맞는지 확인해 보세요.
00:17:14그것만이 실제로 의미 있는 유일한 비교입니다.
00:17:20어떤 에이전트가 여러분의 워크플로우를 바꿀지 기대되네요.
00:17:27코드는 GitHub에 있고 시작하는 데 구독이 필요하지도 않습니다.
00:17:31설치해서 같은 코드베이스에서 실행해 보고, 어느 것이 본인의
00:17:37작업 방식에 맞는지 확인해 보세요. 그것만이 유일하게 중요한 비교입니다.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video