Pi 코딩 에이전트: 실제 워크플로우를 위한 유연한 AI 도구 구축

서론

코드는 결코 공짜가 아닙니다. 이는 Pi의 제작자인 Mario Zechner가 2026년 AI 보조 개발의 현주소를 논할 때 강조하는 핵심 주장입니다. 에이전트는 방대한 양의 코드를 빠르게 생성할 수 있지만, 그 코드가 초래하는 결과는 결국 개발자의 몫으로 돌아옵니다. Pi는 Zechner가 기존 코딩 에이전트들이 자신의 워크플로우에 맞지 않는다는 점을 깨닫고, 자신을 도구에 맞추는 대신 자신에게 맞게 적응하는 도구를 직접 만들면서 탄생했습니다.

이번 대담에서는 왜 기능의 속도보다 워크플로우의 안정성이 중요한지, 어떻게 하면 번아웃 없이 코딩 에이전트와 협업할 수 있는지, 그리고 왜 업계가 30년 전의 사양 중심 개발이라는 실수를 반복하고 있는지에 대해 다룹니다.

Pi가 존재하는 이유: 안정성보다 워크플로우의 유연성

Claude Code가 처음 출시되었을 때 Zechner는 만족했습니다. 하지만 시간이 지나면서 도구의 잦은 업데이트 주기가 문제가 되었습니다. Claude Code는 하루에 1~3회 업데이트되는데, 릴리스마다 도구 정의, 시스템 프롬프트, 기본 동작이 변경됩니다. 커스텀 프롬프트 템플릿, 슬래시 명령어, 워크플로우 설명을 직접 구축하는 사람에게 이러한 보이지 않는 변화는 치명적입니다.

모델 버전은 동일함에도 불구하고 모델 자체가 매일 다르게 동작하는 것처럼 보였습니다. Zechner는 이를 모델의 응답 방식을 결정하는 인프라와 시스템 프롬프트인 ‘하니스(harness)‘의 변화 때문이라고 봅니다. 하니스 변경이 출력 품질에 미치는 영향을 테스트하는 것은 결정론적인 측정 방법이 없기 때문에 매우 어렵습니다. 결과적으로 Zechner와 같은 개발자들은 도구가 일관되게 동작할 것이라고 신뢰할 수 없게 되며, 이는 도구를 중심으로 커스텀 워크플로우를 구축하는 목적을 무색하게 만듭니다.

Pi는 이러한 좌절감에서 탄생했습니다. Pi는 사용자가 도구의 제약에 적응하도록 강요하는 대신, 사용자의 워크플로우에 맞게 스스로를 수정할 수 있는 최소한의 확장 가능한 코딩 에이전트입니다. 기본 아키텍처는 LLM 제공자를 추상화하고, 터미널 사용자 인터페이스 라이브러리를 포함하며, 일반적인 에이전트 루프 추상화를 제공합니다. 하지만 가장 큰 차이점은 제어권에 있습니다. Zechner는 설계를 직접 결정하며, 공급업체의 릴리스 주기를 기다릴 필요 없이 언제든 변경할 수 있습니다.

Pi의 실제 작동 방식: 병렬 처리와 수동 검토

Zechner의 일상적인 Pi 워크플로우는 체계적이며 의도적으로 로우테크(low-tech) 방식을 따릅니다. 그는 에이전트 군단을 병렬로 실행하지 않습니다. 대신, 여러 세션을 대기열에 넣고 각 세션이 트래커의 서로 다른 이슈를 분석하게 한 뒤, 각각을 검토하고 반복하는 원시적인 방식을 사용합니다.

버그 수정 및 기능 구현 과정은 이슈 설명에서 시작됩니다. Zechner는 ‘관련 정보를 모두 가져오고, 이슈 내의 분석은 무시하며, 우리가 달성하고자 하는 목표에 기반하여 직접 분석하라’는 커스텀 프롬프트 템플릿과 함께 이슈를 에이전트에게 전달합니다. 이 분석 단계는 이슈당 약 5분이 소요됩니다. 그는 다음 이슈를 위해 두 번째 세션을, 또 다른 이슈를 위해 세 번째 세션을 열어 병렬 전처리 파이프라인을 구축합니다.

에이전트가 이슈 분석을 마치면 Zechner는 제안 사항을 검토하고, 직접 코드를 확인하며, 필요시 수동으로 문제를 재현합니다. 그는 구현 방식에 대해 스스로 확신이 들 때까지 에이전트를 러버 덕(생각의 파트너)으로 활용합니다. 에이전트에게 구현을 지시할 때쯤이면 컨텍스트에는 이미 충분한 가이드라인이 포함되어 있어, 에이전트는 어떤 인터페이스를 수정하고 어떤 모듈을 건드려야 하며 테스트가 어떻게 작동해야 하는지 정확히 파악하고 있습니다.

구현에는 10~30분이 추가로 소요됩니다. 에이전트가 완료 신호를 보내면 Zechner는 diff 뷰어를 띄워 개별 라인에 피드백을 남깁니다. 그가 완료 버튼을 누르면 피드백이 에이전트에게 자동으로 전달되고, 코드가 만족스러울 때까지 반복 작업이 계속됩니다. 핵심 메커니즘의 경우 그는 사람과 협업할 때처럼 모든 변경 사항을 검토합니다. 다른 부분은 깊은 검토 없이 승인하기도 합니다.

이 워크플로우가 가능한 이유는 Zechner가 코드베이스에서 10년 이상의 경험을 쌓았기 때문입니다. 그는 무엇이 효과적이고 무엇이 그렇지 않은지 잘 알고 있습니다. 경험이 부족한 신입 개발자들에게는 이 접근 방식이 다를 수 있으며, 더 위험할 수도 있습니다.

사양 중심 개발의 현실

업계는 30년 전의 실수를 반복하고 있습니다. 워터폴(Waterfall) 개발 방식은 수십 년 전에 이미 비효율적인 것으로 판명되었지만, AI 에이전트의 등장으로 우리는 다시 상세한 사양을 작성하고 에이전트가 이를 구현하게 하는 ‘하이퍼 워터폴’ 시대로 돌아갔습니다. 유일한 차이점은 이제 사양조차 직접 작성하지 않고, 에이전트에게 대략적인 프롬프트를 던져 상세 사양을 쓰게 한 뒤 다른 에이전트가 이를 구현하게 한다는 점입니다.

문제는 근본적입니다. 완벽한 사양은 사실상 프로그램 그 자체입니다. 자연어로 사양을 작성하면 반드시 공백이 생기기 마련입니다. 에이전트는 인터넷상의 20년 치 코드에서 학습한 패턴으로 그 공백을 채우는데, 그중 상당수는 쓰레기 코드입니다. 결과적으로 코드베이스는 ‘바이브 코딩(vibe-coded)‘된 소프트웨어처럼 보이게 됩니다. 실제로 그렇기 때문입니다.

반론도 있습니다. 이제 코드는 저렴해졌고 반복은 빠르다는 것입니다. 과거에는 워터폴 사양을 구현하는 데 몇 달이 걸렸지만, 이제는 하루면 충분합니다. 수동으로 테스트하며 진행할 수도 있습니다. 하지만 Zechner는 이것이 실제 프로덕션 소프트웨어에서 효과적이라는 증거를 아직 보지 못했습니다. 그는 결국 개발자들이 모든 것이 망가졌다는 사실을 깨닫고 밤잠을 설치게 될 것이라고 의심합니다.

그럼에도 에이전트 기반 개발이 합리적인 제약 조건은 존재합니다. Bun이 Zig에서 Rust로 재작성된 사례는 프로젝트에 광범위한 테스트 스위트가 있었기에 가능했습니다. 에이전트가 어느 정도 스스로 작업을 검증할 수 있었기 때문입니다. 그런 경우에는 이러한 도구가 진정으로 유용합니다. 하지만 대부분의 소프트웨어 개발에서 이 접근 방식은 위험합니다.

대규모 오픈 소스 관리: 클랭커(Clanker) 문제

에이전트 이전에는 성공적인 오픈 소스 프로젝트라도 일주일에 한두 개의 풀 리퀘스트를 받는 수준이었습니다. 하지만 Pi는 이제 하루에 50~60개의 풀 리퀘스트를 받는데, 모두 에이전트(Zechner는 이들을 ‘클랭커’라고 부릅니다)가 보낸 것입니다. 각 PR은 해리포터 책 한 권 분량의 설명과 10개에서 1,000개에 달하는 파일 변경 사항을 포함하고 있습니다.

기본 대응은 에이전트가 생성한 모든 PR을 쓰레기로 간주하고 자동 종료하는 것입니다. 하지만 Zechner는 해결책을 찾았습니다. 먼저 자신의 목소리로 화면 한 페이지를 넘지 않는 분량의 이슈를 작성하여 무엇을 왜 하고 싶은지 정확히 설명하도록 요구하는 것입니다. 이슈가 훌륭하면 그는 이를 승인하고, 작성자는 PR을 보낼 수 있습니다. 이는 그들이 사람이며, 문제를 이해하고 해결책을 파악하고 있음을 증명합니다.

승인된 후에는 의미 있는 PR들이 들어옵니다. 클랭커 PR은 더 이상 나타나지 않습니다. 이슈는 여전히 쏟아지지만, Zechner는 이를 수동으로 분류합니다. 그는 하루에 30~60개의 종료된 이슈를 읽으며 무엇이 합법적이고 무엇이 쓰레기인지 식별합니다. 최근 분류 작업에서는 50개의 이슈 중 2개만이 살아남았습니다. 대부분은 노이즈로 쉽게 식별할 수 있기 때문에 약 30분 정도 소요됩니다.

OpenClaw 규모의 프로젝트에서는 이러한 수동 접근 방식이 통하지 않습니다. Peter Steinberger의 토큰 소비량은 월 130만 달러에 달했는데, 이는 해당 규모에서 이슈와 PR 필터링을 자동화하려면 정교한 인프라가 필요하기 때문입니다. Zechner는 유사한 이슈를 클러스터링하는 시각화 도구를 작성했지만, 그것만으로는 부족했습니다. 이슈의 양이 차원이 다르게 많기 때문입니다.

로컬 추론과 더 작은 모델의 미래

Zechner는 소비자용 하드웨어에서 유능한 AI 모델을 로컬로 실행하는 것에 대해 낙관적입니다. 코딩 에이전트를 실행하는 스마트폰을 마이크로컨트롤러로 사용하는 장난감 로봇 프로젝트를 위해 그는 더 작은 Mixture-of-Experts 모델인 Gemma 4와 Qwen 3.6을 사용합니다. 이 모델들은 모터와 카메라 제어가 포함된 챗봇에 충분하며 속도도 빠릅니다.

설정 비용도 저렴합니다. Parakeet을 사용한 음성 인식(STT)에는 약 10GB의 통합 메모리가 필요합니다. Qwen TTS를 사용한 텍스트 음성 변환(TTS)에는 10GB가 추가로 필요합니다. Qwen 3.6은 4GB를 차지합니다. 총 14GB의 통합 메모리면 macOS나 Windows의 동급 NVIDIA 설정에서 충분히 구동 가능합니다. 이는 전 세계 모든 사람은 아니더라도 많은 사람에게 감당 가능한 수준입니다.

DeepMind의 Denise Asaves는 현재의 거대 모델들이 모든 파라미터를 필요로 하지 않으며, 출력 품질을 크게 잃지 않고도 훨씬 작은 모델로 증류(distillation)될 수 있다고 제안했습니다. Zechner는 미래가 특정 작업을 위해 전문 모델을 훈련하는 대신, 대형 모델을 대부분의 기능을 유지하는 소형 모델로 증류하는 방향으로 나아가길 바랍니다. Redis의 Antirez는 128GB 노트북에서 DeepSeek V4를 실행하는 ds4라는 커스텀 추론 엔진 작업을 시작했습니다. 이는 Zechner가 Pi로 처리하는 이슈의 60~70%를 감당할 수 있는 매우 유능한 모델입니다.

코드의 비용과 기술의 규율

Zechner는 사람들이 일주일 만에 에이전트를 통해 50만 줄의 코드를 생성하는 것을 보았습니다. 결과는 항상 똑같이 재앙이었습니다. 코드는 결코 공짜가 아니며, 그 결과는 결국 개발자에게 돌아오기 때문입니다. 지금 당장 많은 양의 코드를 생성하는 것이 좋다고 생각한다면, 단지 대가를 치르는 시점을 뒤로 미루고 있을 뿐입니다.

소프트웨어 개발의 진정한 병목 현상은 타이핑 속도나 코드 생성 속도가 아닙니다. 그것은 사고하고, 설계하고, 솔루션 공간을 탐색하는 과정입니다. 에이전트는 이 단계에서 진정으로 유용합니다. 여러 에이전트에게 서로 다른 접근 방식을 탐색하게 하고 결과를 더 빠르게 확인할 수 있기 때문입니다. 하지만 그러한 탐색의 결과물이 자동으로 재사용 가능한 것은 아닙니다. 여전히 그것을 이해하고, 리팩토링하고, 유지 관리해야 합니다.

Zechner에게 에이전트가 주는 가장 큰 생산성 향상은 작업의 비동기적 성격에서 옵니다. 그는 에이전트에게 작업을 맡기고 회의에 다녀온 뒤 결과를 확인할 수 있습니다. 하지만 그는 10개의 에이전트를 병렬로 실행한다고 해서 자신의 생산성이 10배가 될 것이라고는 믿지 않습니다. 컨텍스트 스위칭만으로도 지치기 때문입니다. 그는 한 달에 한두 번, 하루에 30개의 이슈를 처리해 본 적이 있는데, 그 후에는 뇌가 녹아내리는 기분이었습니다.

그가 가장 가치 있게 여기는 것은 협업 측면입니다. 질문하고, 옵션을 제안하고, 코드를 설명하는 페어 프로그래밍 파트너로서의 에이전트는 사고를 위한 자전거와 같습니다. 혼자 앉아 있는 것보다 문제를 더 잘 생각하게 도와줍니다. 하지만 여기에는 규율이 필요합니다. 모든 것을 기계에 위임하지 않는 것입니다. 위임할 때마다 결국 아무것도 제대로 작동하지 않고 모든 것이 무너져 내리는 상황에 직면하기 때문입니다.

Pi 리팩토링: 미래를 위한 구축

Pi에는 역사적인 부채가 쌓여 있습니다. 일부는 Zechner가 에이전트를 사용하기 전부터 존재했던 견고한 코드입니다. HTML 내보내기와 같은 다른 부분은 그가 한 번도 들여다본 적이 없으며, 렌더링만 잘 된다면 신경 쓰지 않는 부분입니다. 일부는 바이브 코딩된 코드입니다.

리팩토링 노력에는 몇 가지 목표가 있습니다. 첫째, 기존 확장을 깨뜨리지 않고 웹, 네이티브 등 다른 유형의 사용자 인터페이스로 더 쉽게 확장하는 것입니다. 둘째, 원격 기능을 활성화하여 한 기기에서 Pi 세션을 실행하고 다른 기기에서 적절한 내구성과 관측 가능성을 갖춘 상태로 연결하는 것입니다. 셋째, Pi의 SDK를 로컬 bash 환경뿐만 아니라 Cloudflare Workers, Vercel 및 기타 환경에 배포 가능하게 만드는 것입니다.

Zechner는 전통적인 의미의 안정성을 신경 쓰지 않기 때문에 메인 브랜치에서 리팩토링을 진행하고 있습니다. 그는 LLM 제공자와 통신하는 가장 낮은 수준의 패키지부터 시작하여 하나씩 작업을 수행 중입니다. 코딩 에이전트 자체는 여전히 동일하게 보이고 작동하겠지만, 모든 기본 인프라는 깨끗하고 재사용 가능해질 것입니다. 그는 1~2주 안에 이 단계를 마치고, 확장 기능이 서버 측 및 UI 측 구성 요소를 모두 가질 수 있도록 하는 새로운 확장 메커니즘에 몇 주를 더 투자할 계획입니다.

Pi가 기본적으로 YOLO 모드로 실행되는 이유

Pi는 코드를 실행하기 전에 허락을 구하지 않습니다. 이는 의도적인 것입니다. Zechner는 사람들에게 YOLO 모드가 위험하며 주의해야 한다고 말함으로써, 오히려 보안에 대해 생각하게 만듭니다. 그는 사용자들이 스스로 보안 의식을 갖고 자신의 환경에서 에이전트 작업을 어떻게 보호할지 결정하기를 바랍니다.

그 답은 보통 컨테이너화입니다. 에이전트가 컴퓨터를 망가뜨리는 것을 원치 않는다면, 에이전트나 에이전트가 사용하는 도구(파일 읽기/쓰기, bash 등)를 컨테이너화하면 됩니다. 그것이 문제를 해결합니다. 하지만 Zechner가 사용자를 대신해 결정할 수는 없습니다. 그는 Anthropic의 샌드박스나 bubble wrap을 번들로 제공할 수도 있지만, 이는 불완전한 해결책입니다. 특정 인프라 제약이 있는 엔터프라이즈 환경에서는 내장 샌드박스가 전혀 작동하지 않을 수도 있습니다.

Claude Code에 존재하는 것은 대부분 보안 쇼(security theater)에 불과합니다. Claude Code는 이제 자동 모드에서 bash 명령을 실행하기 전에 LLM에게 해당 명령이 안전한지 묻습니다. Zechner는 이것이 좋다고 생각하지 않습니다. LLM은 명령이 안전한지 안정적으로 판단할 수 없으며, 패턴에 기반하여 추측할 뿐입니다.

결론

Pi는 개발자가 소유하고 수정할 수 있는 도구를 구축해야 한다는, 개발자를 소유하는 도구가 아닌 다른 철학을 대변합니다. Pi의 성공은 기능이나 벤치마크로 측정되는 것이 아니라, Zechner가 작은 팀을 유지하며 코딩에서 로봇 공학, 로컬 추론에 이르기까지 에이전트 작업의 응용 분야를 계속 탐색할 수 있는지에 달려 있습니다.

더 넓은 교훈은 워크플로우가 과대광고보다 중요하다는 것입니다. 안정성, 예측 가능성, 도구를 커스터마이징할 수 있는 능력은 최신 기능보다 더 가치가 있습니다. 그리고 코드는 결코 공짜가 아니며, 당신의 행동이 초래한 결과는 결국 당신에게 돌아올 것입니다.