Poteto는 Cursor에서 일하는 엔지니어이고, pstack을 만들었으며, 「지난달 프로덕션에 2,500개의 PR을 배포한 방법」이라는 발표로 X에서 약 300만 회 조회를 얻었다. 그는 대담에서 Cursor를 지금은 SpaceX AI라고 부른다. Matt Pocock이 묻는 것은 PR 수를 늘리는 방법이 아니라, 에이전트 한 명을 세세하게 감독하던 사람이 어떻게 자는 동안 에이전트들이 코드를 병합하게 두는 상태까지 갔는가다. Poteto는 이 과정을 신뢰의 사다리라고 부른다.
그의 답은 모델이 아니라 환경에 있다. 에이전트에게 자기 작업을 검증할 손과 눈을 주고, 판단이 필요 없는 일은 CLI로 고정하고, 실수를 지침이 아니라 코드베이스의 제약으로 바꾸고, 외부 정보가 사람을 거치지 않고 작업으로 들어오게 연결한 뒤에야 전수 검토를 표본 검토로 바꿀 수 있었다. 그는 이것을 소프트웨어 공장보다 미쉐린 주방에 비유한다. 주방장은 모든 음식을 직접 만들지 않지만 전체 결과에 자기 이름을 건다.
이 노트에는 2026-10-06 deep-dive에서 확인한 내용이 함께 남아 있다. 결정론적 작업을 CLI로 고정한다는 말이 실제로 어떤 작업을 가리키는지, Poteto가 공개한 예제로 확인한 기록이다.
병목은 모델이 아니라 에이전트와 결과 사이에 서 있는 사람이다
Poteto의 실험은 Meta의 React 팀을 떠나 한 달을 쉬며 만든 사이드 프로젝트 nodle에서 시작됐다. AI로 코드를 썼지만 실제로는 에이전트 한 명을 세세하게 감독하는 데 시간을 쓰고 있었고, 그는 왜 자신이 계속 지켜보고 있어야 하는지를 물었다. Cursor에 합류해 에이전트 창의 성능 문제를 맡았을 때도 같은 일이 반복됐다. 플레임 그래프와 힙 스냅샷을 직접 읽으면서, 자신이 에이전트와 Chrome DevTools 사이에서 정보를 전달하는 대리인이 되어 있었다. 최상위 모델도 쉬운 방법과 지름길을 택하는 경향이 있었으므로, 그는 어떻게 해야 가장 쉬운 행동이 올바른 행동이 되는가라는 질문에 맞춰 많은 스킬을 설계했다.
반론. AI에 더 의존할수록 도메인 전문성의 가치는 낮아지지 않는가. Poteto의 판단은 반대다. 모델이 유능해질수록 병목은 에이전트가 해낼 수 있는 일의 범위에서 사람이 의도와 목표를 명확하게 표현하는 능력으로 옮겨 간다. 의사나 변호사처럼 소프트웨어 바깥에 깊은 전문성이 있는 사람이 에이전트 사용법을 조금만 배우면 큰 이점이 있다. 여기서 전문성은 AI가 대신하는 지식의 양이 아니라 무엇을 만들어야 하고 어떤 결과가 적절한지 판단하고 설명하는 능력이다.
그래서 두 사람은 언어에 주목한다. Matt는 에이전트가 어떤 단어를 이해한 뒤 자신의 추론에서 그 단어를 반복해 강화하는 순간에 관심이 있다. TDD라는 단어 하나가 에이전트가 테스트를 작성하는 방식과 우선순위를 바꾸고, 동어반복적인 테스트를 없애라는 뜻의 tautology라는 단어 하나가 상당한 양의 의도와 판단을 압축해 전달한다. Poteto는 Matt가 제시한 이 방식을 실제 작업에 적용했다. 에이전트와 함께 일하는 상황은 자연어와 프로그래밍 언어가 만나는 지점이며, 결국 의사소통의 문제라는 것이 두 사람의 공통 인식이다.
검증이 없으면 에이전트 루프는 없다
pstack이나 Matt의 스킬을 쓰지 않더라도 하나만 갖춰야 한다면 검증을 갖추라고 Poteto는 말한다. 검증은 에이전트가 작성한 코드를 실제로 실행하고, 평범한 사용자처럼 결과물과 상호작용하고, 디버깅하고 트레이스와 스냅샷을 얻는 일이다. 에이전트에게 손과 눈을 주는 것이다. Cursor에서 처음 만든 스킬도 검증 스킬이었고, 작업 방법을 다루는 how, why, unslop 같은 스킬이 아무리 좋아도 결과를 확인하는 사람이 남아 있으면 사다리를 오를 수 없었다.
이유는 단순하다. 에이전트가 자기 작업의 결과를 볼 수 없으면 다음 시도를 개선할 수 없다. 에이전트 루프라는 추상적인 표현을 실제로 작동하게 만드는 것은 계속 작업하라는 명령이 아니라 검증이다. 평가 기준이 있고 에이전트가 검증 루프를 돌 수 있으면, 사람에게 매번 판단을 요청하지 않고 개선을 이어 가는 hill climbing이 가능해진다. 그가 처음 hill climbing을 적용한 사례는 Cursor 에이전트 창의 성능 개선이며, 그는 Karpathy의 autoresearch에도 같은 아이디어가 있다고 본다. Cursor 내부에서는 각 앱에 검증 스킬이 있고 그 스킬도 자동으로 유지·관리된다.
판단이 필요 없는 일은 CLI로 고정한다
검증 스킬 안에 CLI를 넣게 된 첫 계기는 컨텍스트 절약이었다. 요약과 압축이 충분히 좋지 않던 시기에 컨텍스트를 아끼려 했다. 지금은 그 비중이 줄었지만 더 중요한 목적이 남아 있다. 작업은 여러 맥락을 모아 판단해야 하는 부분과 정해진 규칙대로 기계적으로 처리하면 되는 부분이 하나의 연속선 위에 있다. 코드를 한 패턴에서 다른 패턴으로 바꾸는 일이 단순하고 반복적이라면 에이전트가 매번 새로 생각해서 구현할 이유가 없다. 이런 부분은 스크립트와 CLI에 넣고, 실제 판단이 필요한 부분만 에이전트에게 남긴다. 그러면 스킬은 전용 도구의 사용법을 담은 가벼운 래퍼가 되고, CLI 자체는 Playwright와 Chrome DevTools Protocol을 엮은 연결 코드에 가깝다.
CLI가 없던 시기의 실제 문제는 컨텍스트 낭비만이 아니었다. 에이전트가 검증할 때마다 필요한 도구를 처음부터 다시 만들었고, 에이전트마다 구현이 달랐으며, 앞선 에이전트가 만든 잘 작동하는 도구가 버려졌다. 공통 CLI를 스킬에 넣으면 이후 모든 에이전트가 같은 구현을 재사용한다. 기술 마이그레이션도 같은 사례다. 추상 구문 트리를 순회해 코드를 변환하는 기계적인 작업은 코드모드가 하고, 에이전트가 그 변환을 매번 직접 만들지 않게 한다.
실수는 지침이 아니라 환경의 규칙으로 바꾼다
Matt의 코드 품질 정의는 변경하기 쉽고 변경 때문에 다른 부분이 망가지기 어려운 코드베이스라는 것이다. 이 정의에는 린트와 타입 검사 같은 자동 검사뿐 아니라 추상화를 설계하는 방식까지 포함되며, 목표는 사람과 에이전트가 하나의 좁고 올바른 경로를 따라가게 만드는 것이다. 에이전트가 늘 같은 실수를 한다면 그 실수를 환경 안에서 하기 어렵게 만들 수 있다.
Poteto가 TypeScript에서 가장 좋아하는 기능은 타입 좁히기다. 넓은 타입에서 출발해 타입 가드와 런타임 검사로 가능한 범위를 줄이듯, 코드베이스의 제약도 가능한 구현의 범위를 줄인다. 내부 프레임워크 Dune은 자신들의 Electron 앱을 위한 내부 Next.js 같은 것으로, 매우 엄격한 린트 규칙 아래 어떤 일을 하는 방식이 사실상 하나뿐이도록 설계되어 있다. 각 기능은 정해진 위치에 자기 디렉터리를 갖고, 레지스트리가 기능을 자동으로 찾아낸다. Dune을 만든 계기는 초기 Grockbot 코드였다. 각각 최소 1만 줄인 거대한 파일 여덟 개로 되어 있어서 작은 단위로 분리해야 했다. 그는 에이전트가 실패하는 모습을 관찰할 때마다 그 실패를 린트 규칙으로 바꿀 수 있는지, 코드베이스가 그 실수를 불가능하게 만들 수 있는지 묻는다. 실수를 환경의 규칙으로 바꾸면 에이전트에게 기억할 지침을 계속 추가하지 않아도 된다. 에이전트는 관련 작업을 하는 시점에 그 규칙을 확인하게 된다.
반론. 환경을 만드는 일과 기능을 만드는 일 중 무엇을 우선해야 하는가. Poteto는 작업 환경을 개선하는 일이 엔지니어의 새로운 일이 되고 있다고 답한다. 에이전트를 신뢰할 수 있게 만드는 스킬과 도구가 없으면 사다리 아래쪽에 머물고, 거기서 할 수 있는 일은 세세한 감독뿐이며, 감독에 시간을 쓰다 보면 더 큰 문제를 생각할 여유가 사라진다. 도구가 없는 엔지니어는 메모장만 알고 Git을 모르는 개발자나 무딘 칼로 요리하는 요리사와 같다. 마감이 다가오면 좋은 도구를 마련할 시간이 없는 상태에서 당장 결과를 내야 하는 압박이 계속된다. 그는 이것이 시간을 들여야 하는 투자이며, 도구가 부족한 상태에서 마감 압박까지 겹치면 시작하기 어렵다는 점도 인정한다.
외부 정보가 사람을 거치지 않고 작업으로 들어오게 연결한다
높은 PR 처리량의 전제는 앞서 만든 환경이다. 주방과 도구를 만들지 않았다면 이 규모를 운영할 수 없었다. 하나의 식당을 자신이 늘 있지 않아도 운영되게 만든 뒤에야 두 번째, 세 번째 식당을 열 수 있다. 그는 자신이 맡은 프로젝트와 큰 채팅 하나하나를 식당처럼 생각하고, 개입이 얼마나 필요한지에 따라 그 사이를 오가며 살핀다.
Poteto는 코드 작업을 하는 에이전트들이 그가 전달한 의도를 구현하는 과정을 내부 루프라고 부른다. 그 의도는 한 시점의 스냅샷이어서 새 정보가 나오면 낡는다. 버그 보고와 기능 요청과 인프라 제약은 Slack, Linear, X로 들어오는데, 오랫동안 그것을 모아 전달하는 사람이 자신이었다. 이 수집 과정이 외부 루프이고, Grockbot이 그것을 자동화한다. Slack 채널을 구독하게 하고 버그 보고가 들어올 때마다 분류하고 재현하는 일을 맡기면, 에이전트는 검증 스킬로 그 문제가 현재 main에도 있는지, 사용자 설정이나 의존성 문제는 아닌지 확인한다. 그가 이 일을 맡길 수 있는 것은 에이전트가 실제로 확인할 수 있다는 신뢰를 이미 쌓았기 때문이다. 그는 에이전트가 어떤 질문에 답하려면 왜 자신을 필요로 하는지 계속 묻는다. 회사의 두뇌나 컨텍스트 그래프 같은 표현은 불필요하게 추상적이고, 실질적인 문제는 사람이 전달하던 정보를 에이전트가 가져오게 가르치는 일이다.
Cursor Projects가 내부 루프이고 Grockbot이 외부 루프다. 프로젝트의 조정 에이전트는 클라우드에 있고 자기 컴퓨터를 가지며, 총괄 주방장이나 비서실장처럼 직접 일하는 대신 하위 에이전트에게 위임하고 작업을 조직한다. 이슈 30개가 한꺼번에 들어오면 조정 에이전트가 관련된 이슈끼리 묶어 하위 에이전트에게 나눠 맡긴다. 관련 작업을 묶는 이유는 상위 문제를 놓치지 않기 위해서다. 성능 이슈 여러 개에 에이전트를 하나씩 바로 배정하면 중복 작업이 생기거나 공통 원인을 놓치지만, 함께 보면 특정 위치의 버그로 보이던 것이 상위 구조의 문제였음을 알 수 있다. Netflix에서 들었던 통제보다 맥락이라는 원칙을 그는 에이전트에게도 적용한다.
PR 2,500개가 새 기능 2,500개는 아니다. 상당수는 코드베이스를 가꾸는 gardening이다. React에서 실수하기 쉬운 패턴을 찾는 루틴 에이전트에게 그는 발견 즉시 수정하라고 하지 않고 문서에 추가하게 한다. 며칠에 한 번 그 문서를 보면 여러 항목이 사실 같은 문제임을 알 수 있다. 문제를 쌓아 두는 버퍼가 사람과 에이전트 모두에게 패턴을 발견할 수단을 준다. 즉시 수정이 항상 틀렸다는 것은 아니고, 여러 문제를 함께 보는 것이 유리한 상황에서 수집과 실행 사이에 버퍼를 두는 편이 낫다는 뜻이다.
병합 전 전수 검토 대신 병합 후 표본 검토로 옮긴다
PR 2,500개를 전부 읽었느냐는 질문을 Matt는 만든 음식 2,500개를 전부 맛보았느냐로 바꿔 묻고, Poteto는 여러 식당을 운영하는 사람이 모든 음식을 맛볼 수는 없지만 전혀 맛보지 않는 상태도 원하지 않는다고 답한다. 공장의 품질 관리자처럼 표본을 보되 선택한 표본은 매우 엄격하게 검토한다. 찾는 것은 비효율과 나쁜 패턴이고, 수정 대상은 그 에이전트 한 명이 아니라 환경이다. 여러 에이전트가 같은 지름길을 택하거나 같은 임시방편을 퍼뜨리고 있다면 스킬과 제약과 린트와 타입 시스템을 바꾼다. 그는 이것이 pstack을 쓰기만 하면 되는 일이 아니라, 에이전트가 실패하는 지점을 살피고 기본 행동이 올바른 행동이 되도록 안전장치를 마련하는 데 상당한 시간이 드는 일이라고 강조한다.
환경을 마련한 뒤 그는 병합 전에 반드시 검토하던 방식에서 병합된 뒤 살펴보는 방식으로 옮겼다. pstack의 full autopilot은 PR마다 여러 검증 에이전트를 만들어 앱을 실제로 실행하고 사용자처럼 여기저기 클릭하는 퍼징을 수행하며, 회귀와 버그를 찾아 수정하고 다시 검증하기를 반복한다. 토큰을 많이 쓰므로 검증 에이전트를 한 명으로 줄이거나 작업한 에이전트에게 자기 검증을 맡길 수도 있다. 그는 아침에 커밋 기록을 보고 문제가 있으면 되돌리거나 린트 규칙을 추가한다. 처음 시작한 날에는 밤새 무언가를 망가뜨릴까 걱정했지만, 지금은 자신이 자는 동안 에이전트가 병합하고 그 덕분에 잠을 더 잘 잔다.
반론. 이것은 불을 끄고 돌리는 무인 공장이 아니라 사람이 여전히 관여하는 공장이 아닌가. Poteto는 에이전트가 자기 PR을 병합하고 24시간 일하므로 어떤 의미에서는 무인 공장이 맞다고 답한다. 서로 다른 영역을 맡는 비서실장 격 에이전트가 열 명 넘게 있다. Matt는 코드의 존재조차 잊는 바이브 코딩과 달리 이 방식에서는 코드와 환경이 결정적으로 중요하므로, 불을 완전히 끈 공장이라기보다 조광 장치로 조명을 일부만 낮춘 공장에 가깝다고 말한다. 이에 Poteto는 여러 식당을 운영해도 가끔 들러 음식을 맛보는 식당 비유가 더 맞는다고 응답한다. 두 사람은 자동 실행 여부와 사람이 품질에 계속 관심을 갖는지를 서로 다른 문제로 다룬다.
반론. 의료, 법률, 금융처럼 PR 대부분이 되돌릴 수 없는 일방향 문이라면 같은 방식을 권할 수 있는가. Poteto는 검증의 품질이 관건이라고 답한다. 충분히 검증할 수 있다면 되돌릴 수 없는 변경도 어떤 의미에서는 되돌릴 수 있는 변경에 가까워지지만, 프로그램으로 결과를 검증하기 어려운 영역에서는 같은 수준의 자율 운영에 도달하기 어렵다. 소프트웨어 작업은 많은 경우 검증할 수 있지만 전부는 아니다. 그가 기대하는 것은 프로그래밍과 증명을 결합하는 Bend 같은 언어다. 지금까지 Lean이나 TLA+ 같은 별도 언어에서 하던 형식 검증이 코드와 가까워지면, 컴파일되고 증명이 올바름을 보여 주는 코드를 병합하지 않을 이유가 없다. 되돌리기 어려운 모든 작업을 어떻게 다룰지에 대해서는 자신도 답이 없고 업계가 풀어야 할 문제라고 인정한다.
스킬은 과거 대화에서 추출한 절차다
Matt에게 스킬은 절차를 말로 표현한 것이고, Poteto에게도 결국 Markdown이다. 누구나 자기만의 도구 세트를 가져야 한다고 그는 말한다. 요리사가 식당을 옮겨도 자기 칼을 가져가듯 도구는 자신과 함께 이동하며, 신뢰해야 할 중요한 대상도 자신이 쓰는 도구다. Matt의 grill-me나 wayfinder를 pstack의 실행 스킬과 조합하는 사람도 있을 수 있고, wayfinder와 potato mode를 합쳐 자기 모드를 만들 수도 있다. 외부 스킬을 쓸 때는 작성자를 얼마나 신뢰하는지도 중요하다.
출발점은 추상적인 아이디어가 아니라 과거 대화다. 자신이 어떤 프롬프트를 썼고 어디서 수정했고 어떤 상황에서 계속 개입해야 했는지를 에이전트에게 찾게 하고, 그것을 새 스킬이나 린트 규칙으로 바꿀 수 있는지 제안하게 한다. 과거 대화는 머릿속의 추상적인 절차가 아니라 절차가 실제로 수행된 기록이므로 맥락이 풍부하다. pstack의 recall도 Cursor 앱의 가상화 작업에서 비슷한 버그를 다룰 때마다 이전 채팅의 맥락을 가져오던 반복 작업에 이름을 붙인 것이다. 모델이 좋아질수록 스킬은 스크립트 명령 같은 구현 세부를 덜고 절차와 단계에 집중하며 점점 작아질 것이라고 그는 예상한다. Matt는 스킬에 마법은 없으며, 가치가 있다면 선택한 단어와 추상적인 절차를 언어로 바꾸기 위해 수행한 사고에 있다고 맺는다.
정리된 것과 남은 것
두 사람이 합의한 것은 셋이다. 신뢰는 모델이 아니라 검증 가능한 환경에서 나온다. 반복되는 실수는 지침이 아니라 환경의 규칙으로 바꾼다. 규모가 커지면 전수 검토가 아니라 엄격한 표본 검토로 운영한다.
남은 것도 분명하다. 프로그램으로 검증하기 어려운 영역과 되돌릴 수 없는 변경을 어떻게 다룰지는 Poteto도 답이 없다고 말했고, 형식 검증과 결합된 언어는 기대일 뿐 아직 그의 운영 방식에 적용되지 않았다.
Deep Dive
2026-10-06
반복되는 실행 방법을 다음 에이전트에게 남긴다
이번에 풀어낸 질문은 "결정론적 작업을 CLI로 고정한다는 것이 실제로 어떤 작업인가?"였다. 앱을 조작하는 작은 명령들을 미리 구현하고, 스킬과 기능별 문서로 그 명령의 사용 절차와 검증 기준을 전달하는 방식이다. 앞선 에이전트가 알아낸 실행 방법이 다음 대화에서도 재사용 가능한 도구로 남는다.
이 도구를 만드는 과정도 중요하다. pstack의 Build the Lever 원칙은 첫 작업을 직접 수행해 방법을 익힌 뒤 작은 스크립트로 만들고, 같은 작업을 다시 실행해 처음 결과와 비교하도록 한다. 여러 작업에 쓰일 도구는 저장소에 커밋한다. 현재 공식 가이드 역시 에이전트가 앱 조작용 일회성 스크립트를 반복해서 작성하면 검증 스킬이 호출하는 작은 CLI로 바꾸라고 설명한다.
이 설명에서 얻은 적용 기준은 반복되는 작업 중 이미 실행 방법이 정해진 부분을 찾아 도구로 남기는 것이다. 도구에는 연결·입력·대기·측정·증거 수집 방법을 담고, 스킬에는 그 도구를 사용하는 절차를 담으며, 기능별 문서에는 무엇을 관찰해야 정상인지 적는다. 그러면 에이전트는 준비 작업을 재발명하는 대신 검증할 경로를 선택하고 결과를 판단하는 데 집중할 수 있다.
Key Insight
이미 알아낸 실행 방법은 재사용 가능한 CLI로 남기고, 스킬에는 사용 절차와 검증 기준을 담아 에이전트가 필요한 판단에 집중하도록 한다.
References
- pstack 공식 검증 가이드: 반복해서 만드는 앱 조작 스크립트를 작은 CLI로 전환하고 검증 스킬과 함께 유지하는 방법을 확인했다.
- Build the Lever 원칙: 첫 작업에서 방법을 익히고 도구로 구현한 뒤 재실행해 검증하는 제작 절차를 확인했다.
- Poteto의 검증 스킬 예제: 앱 조작 명령, 실행 환경 확인, 증거 수집, 비결정적인 스트리밍에 대한 대기 규칙을 확인했다.
- Atlas 입력창 기능 문서: 조작 도구와 별도로 기능의 접근 경로, 입력 방법, 주의사항을 문서화하는 모습을 확인했다.
- 예제 저장소 README: 가상 앱의 예제이며 CLI 구현 코드는 공개하지 않았다는 자료의 한계를 확인했다.