이 글은 [조쉬의 뉴스레터]에서 발행되었습니다.

퀄리티 있는 프로덕트, 창업가, 비즈니스 이야기를 매주 구독해보세요. 
구독 시 100개의 1인 창업 케이스 스터디가 발송됩니다.

[구독하러 가기]

10월 19일 해커뉴스에 "이해하지 못한 AI 코드를 배포하는 문제를 어떻게 다루나"라는 질문이 올라와 이틀 만에 590점을 받았습니다. 질문이 인용한 메타 엔지니어의 말처럼, 코드를 한 줄씩 다 확인하다간 끝이 없으니까요. 에이전트가 만든 결과를 다 들여다볼 수 없다면, 무엇을 믿고 맡겨야 할까요?

메타 출신으로 지금은 SpaceX AI가 된 Cursor에서 Grok Bot을 만드는 로런 탠은 한 달에 PR(코드 변경 요청) 2,500개를 머지(본 코드에 합치기)했다고 말해 화제가 됐어요. 지금은 에이전트가 PR을 스스로 머지하게 두고 아침에 기록을 보며 리뷰하지만, 올해 초엔 그도 에이전트 하나를 붙잡고 몇 시간씩 감독했어요. 그의 답은 에이전트가 스스로 결과를 확인하게 하고, 실수를 볼 때마다 아예 못 하게 환경을 바꾸는 것입니다. 10월 3일 맷 포콕 채널에 공개된 라이브 대담을 포콕의 질문과 탠의 답으로 옮겨, 그가 에이전트를 믿게 되기까지 오른 사다리를 따라가 봅니다.

에이전트 하나를 붙잡고 있던 "사람 중계기"

Q. 에이전트 '신뢰 사다리'를 어떻게 올라오셨나요?

시작은 Cursor에 들어가기 전이에요. 메타 React 팀에서 일하다 나왔을 때 좀 번아웃이 와서 한 달을 쉬었어요. 번아웃이 오면 뭘 하겠어요, 새 사이드 프로젝트를 시작하죠.

AI로 코드를 쓰다 보니 에이전트 하나를 붙잡고 몇 시간씩 세세하게 감독하고 있더라고요. 2월 초, 어쩌면 1월이었는데 다들 오케스트레이션(여러 에이전트를 지휘하는 방식)에 빠져 있던 때였어요. 저도 '내 AI 코딩 환경을 어떻게 더 효율적으로 만들까'에 끌려 스킬(에이전트에게 주는 작업 설명서)을 만들기 시작했죠.

제가 하려던 건 결국 에이전트가 저처럼 코드를 쓰고 저처럼 일하게 가르치는 거였어요. 스킬이 그 입구였죠. 그때 만든 스킬은 지금도 제 GitHub의 noodle 저장소에 공개돼 있고, 그땐 몰랐지만 그 프로젝트가 지금 제가 공개한 스킬 묶음 pstack의 바탕이 됐어요.

Cursor에 들어가서는 버벅이던 에이전트 창의 성능 작업을 맡았어요. 처음엔 전부 손으로 했어요. 플레임 그래프(어디서 시간이 걸리는지 보여 주는 그림)와 메모리 스냅숏을 직접 들여다보면서요.

그러다 같은 걸 또 깨달았어요. 병목은 저였어요. 저는 에이전트와 크롬 개발자 도구 사이를 오가며 결과를 옮겨 주는 '사람 중계기'였죠. 그게 정말 짜증 났어요.

Q. 그게 올해 몇 월쯤이었나요?

3월에 Cursor에 들어갔으니 4월 초쯤이에요. 그땐 개인 스킬을 버려 둔 상태였어요. 더는 쓸모없을 줄 알았거든요. 그런데 에이전트 창과 지금의 Grok Bot을 만들면서, 그때 배운 게 아주 쓸모 있다는 걸 깨달았어요. 특히 검증, 엄격하게 일하는 습관에 관한 것들이요. 제 경험상 최신 모델도 지름길을 택하고 쉬운 일을 하려 해요. 그래서 제가 만든 스킬은 대부분 '어떻게 하면 쉬운 일이 옳은 일이 되게 할까'에 관한 거예요.

Q. AI에 기대면서 전문 지식이 덜 중요해진다는 사람이 많은데, 어떻게 보세요?

저는 오히려 전문 지식이 그 어느 때보다 중요하다고 봐요. 모델이 똑똑해질수록 병목은 더 이상 에이전트가 아니에요. 내 의도와 목표를 에이전트가 알아듣고 해낼 수 있게 분명히 말하는 능력이 병목이에요.

그래서 깊은 전문 지식을 가진 사람이 크게 유리하다고 생각해요. 기술에 호기심이 조금 있는 의사나 변호사처럼 다른 분야를 깊이 아는 사람이, 에이전트 쓰는 법만 익히면 정말 좋은 제품을 만들 수 있어요. 머릿속 그림이 분명하고 그걸 에이전트가 만들 수 있게 말로 옮길 수만 있다면요.

단어 하나도 그래요. 포콕 님이 공유한 팁 중에 '동어반복 테스트(아무것도 확인하지 않는 테스트)를 없애라'가 있는데, 그 단어 하나에 많은 의도와 뜻이 압축돼 있죠. 결국 에이전트와 일하는 것도 다 언어이고 소통이에요.

소프트웨어 공장 말고 미슐랭 주방

Q. '소프트웨어 공장' 대신 '미슐랭 주방'이라는 비유를 쓰시던데, 왜인가요?

저는 '소프트웨어 공장'이라는 말을 별로 좋아하지 않았어요. 틀린 말이라서가 아니라, 공장이라고 하면 품질이나 장인정신이 잘 떠오르지 않거든요. 제품을 만드는 사람에게는 사용자 경험과 만드는 물건에 대한 애정이 중요한데요. 그래서 자리 잡은 말이 '미슐랭 주방'이에요.

집에서 혼자 요리하면 채소 썰기부터 설거지까지 다 혼자 해요. 그런데 갑자기 온 가족이 부엌에 들어와 조리도구가 어디 있는지도 모른 채 북적인다고 생각해 보세요. 대부분은 스트레스를 받을 거예요.

혼자 요리하던 사람이 보조 셰프 몇 명과 일하게 되면, 어떻게 나눠야 전체가 각자의 합보다 나아질지 고민해야 해요. 셰프가 되면 더 이상 음식을 다 직접 만들지 않아요. 셰프는 주방의 CEO예요. 재료를 언제 주문하고, 어떻게 보관하고, 언제 손질해 둘지까지 주방 전체를 조직하죠.

요즘 엔지니어가 딱 그래요. 코드는 에이전트가 쓰지만 최종 결과의 책임은 여전히 사람에게 있어요. 내 이름과 평판이 그 일에 붙어 있으니까요. 그래서 주방을 어떻게 차리느냐, 곧 스킬과 환경과 코드베이스(제품을 이루는 코드 전체)를 어떻게 갖추느냐가 제품을 만드는 새 재료라고 생각해요.

첫 계단은 검증, 실수는 환경으로

Q. 발표를 보니 검증에 공을 많이 들이던데, 저는 그게 신뢰를 만드는 지렛대라고 봐요. 구체적으로 어떤 모습인가요?

pstack이나 포콕 님 스킬을 쓰지 않더라도, 도구 상자에 꼭 하나 있어야 할 스킬은 검증이에요. 검증은 에이전트에게 손과 눈을 주는 거예요. 에이전트가 코드를 직접 실행하고, 보통 사용자처럼 눌러 보고, 추적 기록과 스냅숏을 떠서 디버그하게 하는 거죠.

재밌게도 Cursor에 들어가서 처음 만든 스킬이 검증이었어요. 신뢰 사다리를 오르게 해 준 것도 그거였고요. how, why, unslop 같은 다른 스킬이 아무리 좋아도, 결과를 보고 옮기는 중계는 여전히 제 몫이었거든요. 에이전트가 자기 일의 결과를 볼 수 없으면 고쳐 나갈 방법도 없어요.

다들 '루프'를 말하는데, 제게 루프를 루프로 만드는 건 검증이에요. 에이전트가 스스로 확인할 수 있으면 제가 빠질 수 있죠. 처음엔 에이전트 창 성능 작업에서, 채점 기준을 두고 에이전트가 계속 고쳐 점수를 올리는 힐 클라이밍을 하려고 썼어요.

지금은 검증 스킬이 정말 많아요. Cursor, 그러니까 SpaceX AI의 모든 앱에 자동으로 관리되는 검증 스킬이 있고, 팀 모두가 쓰는 핵심 인프라가 됐어요.

Q. 검증용 CLI까지 직접 만들었던데, 그 CLI는 무슨 일을 하고 왜 만들었나요?

CLI(명령어로 쓰는 도구)는 스킬이 하는 일 중 결정적인 부분, 그러니까 매번 같은 결과가 나와야 하는 부분을 스크립트로 떼어 내 쓸데없이 판단을 쓰지 않게 하는 방법이에요. 일에는 여러 맥락을 엮어 생각해야 하는 판단의 영역이 있고, 코드를 한 패턴에서 다른 패턴으로 옮기는 것처럼 기계적인 영역이 있어요. CLI 자체는 Playwright(브라우저 자동 조작 도구)와 크롬 개발자 도구를 불러 쓰는 접착제일 뿐이에요.

CLI가 없을 땐 에이전트가 검증할 때마다 세상을 새로 지었어요. 에이전트마다 다른 방식으로 스크립트를 짜서 시험하고, 안 되고, 앞의 에이전트는 성공해 놓고 버렸죠. 그래서 CLI로 만들어 스킬 안에 넣었고, 이제 그 스킬을 쓰는 모든 에이전트가 같은 도구의 덕을 봐요.

내 스킬과 규칙 중 얼마나 많은 부분이 사실은 결정적일 수 있는지 따져 보세요. 에이전트는 비결정적인 부분에서 빛나게 하고, 기계적인 부분은 그냥 코드로 두는 거예요.

Q. 검사 규칙뿐 아니라 에이전트가 일할 프레임워크까지 만들었는데, 이런 환경 작업이 기능 개발보다 얼마나 중요한가요?

엔지니어의 새 일은 환경에 시간을 쓰는 거라고 생각해요. 에이전트를 믿을 수 있게 해 주는 스킬과 도구에 시간을 들이지 않으면 신뢰 사다리 아래쪽에 갇혀요. 결과를 못 믿으니 붙잡고 감독하느라 시간이 다 가고, 더 높은 차원의 일을 생각할 여유가 없어요.

메모장만 알고 Git은 들어 본 적도 없는 개발자를 생각해 보세요. 자기 칼을 갈 시간을 한 번도 내지 않은 거예요. 칼이 무디면 모든 게 오래 걸리는데, 마감에 쫓기니 그 수렁을 못 빠져나오죠.

코드베이스의 제약은 TypeScript의 타입 좁히기(뭐든 될 수 있는 값을 점점 좁혀 정하는 것)와 비슷해요. 가능한 경우의 수를 좁혀 방법이 하나만 남게 하는 거죠. 제가 만드는 비공개 사내 프레임워크 Dune이 그래요. 사람들에겐 '데스크톱 앱을 위한 사내판 Next.js(웹 앱을 만드는 유명 개발 틀)'라고 설명하는데, 아주 엄격한 규칙이 딸려 있어요. 기능마다 자기 폴더가 있고, 정해진 관례와 린트 규칙(금지된 코드 패턴을 자동으로 잡는 검사) 덕분에 나쁜 코드를 쓰기가 아주 어려운 환경이에요.

기능 폴더도 계기가 있었어요. Grok Bot의 초기 몇 버전은 적어도 1만 줄이 넘는 갓 파일(기능이 한데 몰린 거대한 파일) 8개로 돼 있었어요. 그걸 잘게 쪼개야 했죠.

결국 에이전트가 어떻게 실패하는지 관찰하는 게 중요해요. 실수를 볼 때마다 한발 물러서서 '이걸 린트 규칙으로 바꿀 수 있나, 코드베이스가 이걸 아예 불가능하게 만들 수 있나'를 생각해요.

탠은 대담 2주 뒤인 10월 17일 X에 글을 올려 이 생각을 직접 정리했어요. 에이전트를 더 믿는 방법을 네 단계로 나눴는데, 맨 위부터 코드베이스 개선, 린트·테스트 같은 자동 검사, 주석·규칙 문서·스킬 같은 글, 사람 리뷰 순이에요. 그는 이를 '역피라미드'라고 부르며 노력의 대부분을 위쪽에 쓰라고 적었어요.

탠의 한 달 PR 2,500개는 어디서 오나

Q. 채팅을 한 달에 2,500번 열 리는 없을 텐데, 그 PR들은 어디서 나오나요?

이렇게 많은 PR을 내는 전제조건은 방금 말한 환경이에요. 주방과 칼과 도구에 시간을 쓰지 않았다면 절대 못 했을 거예요. 식당 하나를 잘 차려 두면 제가 거기 없어도 돼요. 수석 셰프에게 비법을 다 가르쳐 뒀으니 두 번째, 세 번째 식당을 낼 수 있죠. 저는 큰 프로젝트 하나를 식당 하나처럼 보고, 여러 곳을 헬리콥터처럼 오가요.

그런데 프로젝트 바깥에는 프로젝트가 모르는 맥락이 있어요. 버그 제보는 Slack이나 Linear(업무 관리 도구), X로 들어오는데 코드를 짜는 쪽과는 연결돼 있지 않죠. 저는 에이전트가 코드를 짜는 순환을 안쪽 루프, 바깥 소식이 들어오는 순환을 바깥 루프라고 불러요. 오랫동안 그 사이를 중계한 건 저였어요.

두 루프를 이으면 아주 강력해져요. 예를 들어 에이전트에게 Slack 채널을 구독시키고, 버그 제보가 올라올 때마다 미리 만들어 둔 검증 스킬로 분류하고 재현하게 할 수 있어요. 사용자 환경 문제가 아니라 최신 코드에서도 정말 재현되는지까지 확인하게요.

제가 늘 생각하는 건 '이 과정에서 내가 어디서 병목인가, 에이전트는 왜 나한테 이걸 묻나'예요. 그리고 에이전트가 짐작하거나 지어내지 않고 실제 데이터로 스스로 답하게 가르쳐요.

2,000개든 몇 개든 그 숫자는 이 루프들 덕분이에요. 채팅을 2,500번 여는 게 아니에요. Cursor에 새로 나온 프로젝트(Projects)가 코디네이터 에이전트(직접 일하지 않고 하위 에이전트에게 나눠 주는 에이전트)인데, 저는 계속 맥락을 넣어 주거나 맥락을 스스로 얻는 법을 가르치고 일은 그쪽이 해요.

그리고 큰 전환점은 '에이전트가 자기 코드를 스스로 머지하려면 무엇이 필요한가'에서 거꾸로 생각한 거예요. 지난달 PR 2,500개를 냈다고 하면 다들 그걸 어떻게 다 리뷰했냐고 묻거든요.

Q. 에이전트를 관리할 때 화면은 실제로 어떻게 생겼나요?

솔직히 좀 헷갈리는 구성이라 하나로 합치는 작업을 하고 있어요. 바깥 루프는 이메일·캘린더·Slack 같은 서비스에 연결된 도구가 맡아요. 저는 제가 만드는 Grok Bot을 쓰지만 다른 도구도 괜찮아요. 이런 도구가 소식을 끌어와 일에 맥락을 넣어 주죠.

넷플릭스에서 일할 때 관리자들이 자주 하던 말이 '통제 말고 맥락(context, not control)'이었어요. 신기하게도 에이전트 세계에 그대로 통해요. 세세한 감독으로 원하는 결과까지 끌고 갈 수도 있지만, 맥락을 주고 스스로 해내는 법을 가르치면 감독할 필요가 없어요. 엔지니어에게든 에이전트에게든요.

안쪽 루프는 Cursor 프로젝트예요. 클라우드에 자기 컴퓨터를 가진 코디네이터 에이전트라, 수석 셰프나 비서실장처럼 하위 에이전트에게 일을 맡기고 맥락을 넘겨 줘요. 바깥 루프 도구가 버그를 찾아 이 프로젝트로 보내면, Cursor를 열지 않아도 일이 시작돼요.

Q. 이슈 30개가 한꺼번에 몰려와도 코디네이터가 알아서 나누나요?

맞아요. 한꺼번에 30개쯤 받으면 코디네이터가 하위 에이전트를 어떤 구조로 둘지 스스로 정해서, 가장 효율적으로 나눠요. 관련된 이슈는 한 프로젝트로 묶어 주는 게 좋아요. 예를 들어 '앱이 느리다'는 제보가 한꺼번에 몰려왔는데 서로 이어져 있고, 고칠 방법도 비슷할 수 있잖아요. 이슈마다 에이전트를 하나씩 붙이면 그 사이의 실마리를 잃고 일을 중복하거나 더 큰 문제를 못 봐요.

제보 하나만 보면 버그가 여기 있는 것 같은데, 조금씩 다른 제보 여러 개를 함께 보면 진짜 원인이 더 위에 있다는 걸 알게 되거든요.

2,500개가 전부 기능은 아니다

Q. 버그 제보 말고 PR이 나오는 다른 출처도 있나요?

재밌게도 코드를 읽는 데서도 나와요. 분명히 해 두면 PR 2,500개가 기능 2,500개는 아니에요. 상당 부분은 '정원 가꾸기', 그러니까 코드를 손질하는 일이에요. 제가 정말 좋아하는 말이에요.

정원 가꾸기는 사람 엔지니어가 많은 큰 팀일수록 더 중요해요. 좋은 환경은 저와 에이전트만이 아니라 팀 전체를 도와요. 팀의 관행을 모르는 신입도 환경이 좋으면 첫날부터 좋은 코드를 낼 수 있죠. 품질 낮은 PR을 잔뜩 열 필요 없이요.

Q. 코드를 살피는 에이전트는 언제 돌리나요? 한 시간마다처럼 정해 두나요?

저도 그런 정기 작업을 몇 개 돌려요. 간단한 예로, React에는 함정이 많잖아요. 그래서 나쁜 패턴을 계속 찾아다니는 에이전트를 하나 두고 있어요.

재밌는 건 바로 고치라고 하지 않고, 찾은 걸 문서에 덧붙이라고 한다는 거예요. 그리고 며칠에 한 번 그 문서를 보면 '이것들 사실 다 같은 문제네' 하게 돼요. 일종의 버퍼, 대기열이죠. 하위 에이전트를 잔뜩 띄워 하나하나 고치는 것보다 이게 더 효과적일 때가 있어요.

들어오는 주문을 처리하기 바쁜 실행 모드에서는 큰 그림을 놓치기 쉬워요. 쌓인 기록이 있으면 하나씩 풀 때는 놓쳤을 패턴이 보여요. 비서실장 에이전트를 두는 이유도 그거예요. 일을 하면서도 숲을 볼 수 있거든요.

PR은 표본만 맛보고, 아침에 몰아 본다

Q. 리뷰 얘기를 해 보죠. 주방에서 나간 2,500접시, 그러니까 PR 2,500개를 다 맛보셨나요?

직접 맛보는 일을 아예 그만두면 안 되겠죠. 그래도 규모가 커지면 주방에서 나가는 모든 요리를 맛볼 수는 없어요. 그래서 표본을 골라 보는 일, 그리고 과정을 생각하는 일이 돼요.

공장의 품질 관리자처럼 매일 들어가서 PR의 품질을 봐요. 에이전트가 쓴 코드를 아주 엄격하게 뜯어보고 비효율과 나쁜 패턴을 찾죠. 그리고 그 에이전트 하나가 아니라 환경을 바로잡을 방법을 생각해요.

한 번 있었던 일이면 괜찮아요. 하지만 여러 에이전트가 같은 지름길을 택하고 같은 문제를 여기저기 퍼뜨리고 있다면, 주방을 고치라는 신호예요. 스킬, 제약, 린트, 타입 시스템을 조정해서 그 문제가 다시 생기지 않게 하는 거죠.

그걸 충분히 반복하면 환경이 잘 짜여서 손을 떼도 되는 지점에 가요. 그게 꿈이죠. 다만 여기까지 오는 건 아주 어려워요. pstack만 쓰면 쉽게 되는 것처럼 팔고 싶지 않아요. 에이전트가 실패하는 지점을 아주 신중하게 고민하고, 기본으로 옳은 일을 하게 가드레일을 세우는 데 시간과 노력이 많이 들어요.

Q. 그래도 불 꺼진 공장은 아니죠? 불은 켜져 있는 거죠?

사실 어느 정도는 그래요. 에이전트가 자기 PR을 스스로 머지하니, 제가 자는 동안에도 24시간 일한다는 점에서는 불 꺼진 공장(사람 없이 밤새 돌아가는 공장)이 된 셈이죠. 저한테는 영역별로 일하는 비서실장 에이전트가 10개 넘게 있어요. 하나는 Grok Bot 데스크톱 앱의 성능을, 하나는 사용자가 제보한 버그를 맡고, 하나는 재미 삼아 네이티브 앱으로 다시 쓰면 어떨지 실험해요.

환경을 갖추는 데 시간을 들인 끝에 이제는 PR이 머지된 뒤에 리뷰해요. pstack의 '풀 오토파일럿'을 켜면 PR마다 검증 에이전트 여러 개가 앱을 실제 사람처럼 이리저리 눌러 보며(퍼징) 망가진 곳과 버그를 찾고, 스스로 고치고, 다시 확인해서 머지할 수 있는 상태까지 가져가요.

토큰은 꽤 많이 들지만 조정할 수 있어요. 검증 에이전트 10개 대신 하나만 쓰거나, 자기 작업만 검증하라고 해도 돼요. 핵심은 검증과 환경의 조합이에요. 그 둘이 있어서 '머지해 둬, 아침에 커밋 기록(코드에 들어간 변경 목록) 보고 리뷰할게'라고 할 수 있죠. 문제가 보이면 되돌리거나 고치고, 린트 규칙을 더해요.

처음 그걸 켠 날은 정말 무서웠어요. 밤새 장애를 내면 어쩌나, 뭘 망가뜨리면 어쩌나 싶었죠. 꽤 용기가 필요했어요. 그런데 지금은 잠을 훨씬 잘 자요.

Q. 의료·법·금융처럼 한번 들어가면 되돌릴 수 없는 '일방향 문' 같은 변경이 대부분인 분야라면, 이 방식은 권하지 않나요?

결국 에이전트에게서 얼마나 좋은 검증을 끌어낼 수 있느냐로 돌아온다고 봐요. 작업을 검증할 수 있는 분야일수록 쉽고, 일방향 문도 어떤 의미에선 되돌릴 수 있는 문이 돼요. 반대로 프로그래밍으로 검증하기 아주 어려운 일이라면 여기까지 오기는 정말 어려워요.

솔직히 제가 답을 갖고 있지 않은 문제예요. 업계가 풀어야 할 숙제죠. 제 바람은 에이전트를 위한 새 프로그래밍 언어가 더 나오는 거예요. 제가 본 것 중엔 프로그래밍과 증명(코드가 맞다는 수학적 확인)을 합친 Bend라는 언어가 가장 흥미로웠던 것 중 하나예요. 컴파일되고 증명이 맞다고 보여 주면 머지하지 않을 이유가 없죠.

남의 스킬을 내 칼로 만드는 법

Q. 사람들은 pstack과 제 스킬(mattpocock/skills)을 경쟁처럼 보는데, 둘을 어떻게 섞어 자기 프로세스로 만들면 될까요?

pstack과 포콕 님 스킬은 서로 보완해요. 스킬은 결국 과정을 글로 쓴 거예요. 그냥 마크다운(간단한 서식의 텍스트 파일)이죠. 내게 맞게 섞어 쓰면 돼요.

그래도 누구나 자기 칼 세트를 가져야 한다고 생각해요. 셰프는 다른 식당으로 옮길 때 자기 칼을 들고 가요. 제게 신뢰란 결국 내 도구에 대한 신뢰예요. 시간을 들여 칼을 갈고 속속들이 알면 대단한 일을 할 수 있어요.

그러니 자기 대화 기록을 보세요. 에이전트에게 내가 써 온 패턴과 끼어들어야 했던 순간을 다 찾아서 린트 규칙이나 새 스킬로 바꾸자고 제안하게 하세요. 지난 대화는 맥락의 보물창고예요. 머릿속의 추상적인 생각이 아니라 실제로 일어난 과정이니까요.

pstack의 recall 스킬이 바로 그거예요. Cursor 앱의 버그를 잡느라 새 대화를 열 때마다 지난 대화의 맥락을 가져오고 싶었는데, 매번 긴 설명을 쓰지 않으려고 그 과정을 스킬 하나로 압축했죠. 모델이 좋아질수록 스킬은 정확한 명령어 같은 구현 세부를 덜어 내고 일의 순서만 담게 돼요. 스킬은 점점 작아질 거예요.

1인 창업자를 위한 체크리스트

탠의 이야기를 바탕으로 편집자가 정리한 점검 목록이에요.

1. 결과물을 열어 보기 전에 에이전트가 먼저 확인하게 하세요. 탠이 꼽은 단 하나의 스킬은 검증이었어요. 에이전트가 직접 실행하고 눌러 볼 수단이 없으면 중계는 계속 내 몫이에요.

2. 매번 똑같이 하는 일은 스크립트나 템플릿으로 떼어 내세요. 탠은 에이전트가 검증 도구를 매번 새로 짜고 버리는 걸 보고 CLI를 만들었어요. 기계적인 부분을 떼어 내면 에이전트는 판단이 필요한 일에만 힘을 써요.

3. 같은 실수를 두 번 보면 잔소리 대신 구조로 막으세요. 프롬프트에 당부를 더하기보다 자동 검사나 정해진 틀로 그 실수를 아예 못 하게 만드세요. 탠의 역피라미드도 사람 확인을 맨 아래에 둬요.

4. 에이전트가 나에게 묻는 질문을 적어 보세요. 탠은 '내가 어디서 병목인가'를 늘 묻는다고 했어요. 내가 매번 복사해 붙여 주는 정보가 있다면 에이전트가 직접 가져오게 이을 자리예요.

5. 찾은 문제는 바로 고치지 말고 한곳에 쌓아 두세요. 탠은 점검 에이전트가 찾은 문제를 문서에 쌓아 며칠마다 묶어 봐요. 따로 보이던 문제가 하나의 원인일 때가 있어요.

6. 지난 대화에서 내가 끼어든 순간을 모으세요. 탠은 지난 대화 기록을 맥락의 보물창고라고 불렀어요. 에이전트를 바로잡은 순간을 찾아 규칙이나 스킬로 바꾸세요. 탠의 recall 스킬도 지난 대화의 맥락을 새 대화로 가져오는 과정을 스킬 하나로 줄인 거예요.

탠의 한 달 PR 2,500개에는 기능이 아닌 코드 손질이 상당 부분 섞여 있고, 그 뒤에는 밤새 도는 검증 에이전트와 아침의 커밋 기록 확인이 있어요. 탠 스스로도 pstack만 쓰면 되는 일이 아니라고 했죠. 그도 에이전트 하나를 붙잡고 있던 사람 중계기에서 출발했어요.

그가 오른 사다리의 답은 에이전트를 더 붙잡는 대신, 에이전트가 옳은 일을 하기 쉬운 주방을 차리는 것입니다. 오늘은 맡긴 일 하나를 골라, 내가 열어 보기 전에 에이전트가 먼저 확인할 방법을 붙여 보세요. 그게 사다리의 첫 계단이 될 거예요.

소중한 노력이 들어간 글을 널리 알려주세요. 

이 기사가 좋으셨다면, 보상을 해주세요. 

가장 좋은 보상은 ‘조쉬의  뉴스레터 구독’입니다. :) 

구독을 하시면 100개의 1인 창업가 데이터베이스를 발송해드립니다.

[구독하러 가기]