최근 한 에이전트가 며칠 만에 MERIDIAN의 작동하는 프로토타입을 구축했습니다. 내가 어디에 있었고, 어디에 있으며, 다음에 어디로 갈지를 보여주는 라이브 페이지와 더불어, 사용자의 사진 라이브러리에 있는 EXIF 데이터를 활용해 기기 내부에서 수동 입력 없이 스스로 그리는 세계 지도까지 포함되었습니다. Expo, React Native, 검은색 SVG 지도를 사용했습니다. 1년 전이었다면 집중적인 프론트엔드 (Frontend) 작업으로 일주일은 걸렸을 일이, 당일에 바로 스크린샷 테스트 (Screenshot-test)를 할 수 있을 정도로 준비되었습니다.

이러한 속도가 가져온 변화는 다음과 같습니다. 위험을 제거한 것이 아니라, 위험의 성격을 옮겨 놓았습니다. 과거에는 코드가 비용이었기에 주요 질문은 "우리가 이것을 만들 수 있는가"였습니다. 이제 구축 비용은 거의 들지 않으며, 단 하나의 값비싼 질문만이 남았습니다. "내가 과연 올바른 것을 만들고 있는가"입니다. 위험이 "만드는 것 (make it)"에서 "무엇을 만들지 결정하는 것 (decide what to make)"으로 옮겨간 것입니다.

그래서 저는 제품을 운영하는 방식을 재구축했습니다. 누가 코드를 작성하느냐를 중심으로 하는 것이 아니라 — 이제 코드는 무제한입니다 — 어떤 코드를 작성할 가치가 있는지를 누가 결정하느냐를 중심으로 합니다. 저는 직접 코드를 거의 쓰지 않습니다. 에이전트에게 작업을 맡기고, 확인하고, 잘라냅니다. 아래는 제가 구축한 방식입니다. "내 시스템을 봐라"는 식의 자랑이 아니라, 여러분이 그대로 복사해서 사용할 수 있는 내용입니다.

에이전트가 하는 일, 그리고 내가 아무에게도 맡기지 않는 일

업무는 여러 조각으로 나뉩니다. 각 조각에는 방대한 양을 처리하는 에이전트가 있고, 제가 직접 유지하는 조각이 있습니다. 그 둘 사이의 경계가 바로 핵심적인 업무 (The whole job)입니다.

1. 발견 (Discovery). 에이전트들은 시장, 경쟁사, 사용자 대화, 그리고 저의 개인 노트 아카이브를 샅샅이 뒤져 제가 물리적으로 제시간에 다 읽을 수 없는 정보들을 뽑아냅니다. 저는 스스로에게 한 가지 질문을 던집니다. '이 패턴들 중 내가 믿을 만한 것은 무엇이고, 그저 듣기 좋게 들리는 것은 무엇인가?'
2. 가설 (Hypotheses). 에이전트는 제가 단 하나를 작성하는 속도보다 더 빠르게 기능에 대한 20가지 버전을 쏟아냅니다. 양(Volume)은 에이전트의 몫입니다. 취향(Taste)은 저의 몫입니다. 20개 중 단 두 개라도 만져볼 가치가 있는지를 결정하는 것입니다.
3. 의사결정 및 우선순위 (Decisions and priorities). 여기서 에이전트는 판사가 아니라 스파링 파트너입니다. 에이전트는 제가 실제로 알고 있는 사실에 비추어 가설을 분류하고, 논쟁하며, 허점을 찾아냅니다. 최종 결정 — 무엇을 로드맵(Roadmap)에 올리고 무엇을 휴지통에 버릴지 — 은 저의 몫입니다. 그것은 되돌릴 수 없는 것이기에, 위임할 수 없습니다.
4. 구축 (Build). Claude Code와 에이전트들이 코드, 디자인, 스키마(Schemas)를 작성합니다. 저는 시니어 개발자가 주니어의 PR(Pull Request)을 검토하듯 그들의 결과물을 읽습니다. '작동하는가'가 아니라, '예상치가 거짓인가, 한 달 뒤에 터질 만한 편법을 썼는가'를 봅니다. 저는 엔지니어링에서 프로덕트(Product) 분야로 넘어왔습니다. JavaScript와 React로 시작해 테크 리드(Tech lead)와 엔지니어링 매니지먼트(Eng management)를 거쳤고, 그것은 이제 하나의 도구가 되었습니다. 저는 코드를 직접 짜봤기 때문에 코드 속의 거짓말을 잡아냅니다.
5. 검토 (Review). 별도의 에이전트가 첫 번째 에이전트가 구축한 것을 공격합니다. 그것의 임무는 어디서 무너지는지를 찾아내는 것입니다. 이에 대해서는 아래에서 더 자세히 다루겠습니다. 이것이 전체 프로세스의 핵심입니다.
6. 오케스트레이션 (Orchestration). 나머지 다섯 단계를 유지하는 계층입니다. 어떤 에이전트가 어떤 작업에, 어떤 순서로, 어떤 컨텍스트(Context)와 함께 투입될지를 결정합니다. 그것이 바로 Yan OS입니다. Claude Code 위에 구축된 계층으로, 프로젝트, 에이전트, 스키마, 훅(Hooks), 예약된 실행, 그리고 몇 가지 MCP(Model Context Protocol)들을 포함합니다. 단 한 명의 지휘자, 바로 저입니다.

제가 에이전트에게 맡기지 않은 것들에 주목하십시오. 무엇을 믿을지 결정하는 것, 최종 로드맵을 확정하는 것, 그리고 타인의 작업물에서 거짓을 찾아내는 것입니다. 그 외의 모든 것은 양(Volume)의 문제이며, 이제 양은 저렴합니다.

어떻게 한 에이전트가 다른 에이전트의 거짓말을 잡아내는가

혼자 남겨진 에이전트는 자신 있게 거짓말을 합니다. 가설을 생성하고, 이를 정당화하며, 진실을 말할 때와 동일한 어조로 이를 사실처럼 제시합니다. 그래서 제 설정에서는 생성하는 에이전트와 검증하는 에이전트를 분리했습니다. 그리고 그 사이에는 단순한 분류(Sort) 과정이 자리 잡고 있습니다. 저의 것, 사용자의 것, 에이전트의 것을 포함한 모든 주장(Claim)은 다음 세 가지 버킷(Bucket) 중 하나로 분류됩니다:

• know (앎) - 실제 데이터, 행동, 유지되는 패턴.
• looks like (듯함) - 신호(Signal)일 뿐, 증거는 아님.
• want it true (사실이길 바람) - 소망이며, 현재로서는 확인되지 않음.

"want it true"에 속하는 모든 항목에는 확인하거나 폐기하는 테스트가 부착됩니다. 표시되지 않은 채 빌드(Build)로 넘어가는 것은 아무것도 없습니다. 그리고 제 자신의 직감은 가장 목소리가 크기 때문에 가장 혹독한 검증을 거칩니다.

이 방식이 실제로 저를 구해주는 지점은 여기입니다. 한 에이전트가 기능을 제안하며 "사용자들이 X를 원한다"라고 작성합니다. 그러면 두 번째 에이전트가 출처로 가서 그 "원한다"는 내용이 단 하나의 채팅 스레드에 있는 내용임을 찾아냅니다. 그것은 "know"로 제공된 "looks like"입니다. 두 번째 에이전트가 없었다면 그 "원한다"는 내용은 데이터로 포장되어 로드맵(Roadmap)에 올라갔을 것입니다. 하지만 두 번째 에이전트 덕분에, 그것은 테스트를 거치며 대기하게 됩니다. 비용은 불과 몇 푼 들지 않으면서, 가장 값비싼 종류의 오류, 즉 사실처럼 보이는 자신감 넘치는 거짓말을 잡아냅니다.

속도가 MERIDIAN에서 드러낸 것

다시 프로토타입(Prototype) 이야기로 돌아가겠습니다. 모든 핵심이 그 안에 있기 때문입니다.

MERIDIAN 이전에는 이전 가설이었던 Nomad Bridge(노마드를 위한 양면 마켓플레이스)를 폐기했습니다. 제가 직접 해체(Teardown)해 본 결과 살아남지 못했습니다. 양면 시장(Two-sided marketplace)은 첫날부터 양쪽 모두가 필요하며, 마켓플레이스를 망하게 하는 전형적인 콜드 스타트(Cold start) 문제가 있고, 제가 찾을 수 있었던 유일한 유료 수요는 증거가 아닌 유추에 의한 것이었습니다. 그 죽은 제품 안에는 제가 결코 진지하게 생각하지 않았던 작은 기능 하나가 있었습니다. 바로 당신이 방문했던 국가들의 지도가 포함된 프로필 페이지였습니다. 저는 그것을 다른 모든 것과 함께 버렸습니다.

그 후 한 달 동안 다음 아이템을 찾기 위해 시간을 보냈습니다. 약 350개의 아이디어, 에이전트를 이용한 9번의 실행 과정에서 거의 모든 실행마다 하나의 모티프(Motif)가 계속 떠올랐습니다. 바로 그 이동 지도(Movement map)였습니다. 이미 제 손안에 있었지만, 제가 미처 보지 못했던 그 기능 말입니다.

비결은 이렇습니다. 에이전트(Agent)는 며칠 만에 프로토타입(Prototype)을 만들어냈고, 그 속도 덕분에 어려운 부분은 결코 코드가 아니었다는 사실이 명확히 드러났습니다. 진짜 어려운 부분은 제가 스프레드시트(Spreadsheet)에서 350개의 아이디어에 점수를 매우느라 한 달을 보냈고, 그 과정에서 제 주머니 속에 이미 들어있던 것을 놓칠 뻔했다는 점이었습니다. 코드가 비쌌을 때는 느린 빌딩(Building) 속도가 제 머릿속의 오류를 가려주었습니다. 너무 오래 빌딩하다 보니 잘못된 것을 만들고 있다는 사실조차 알아차리지 못했던 것이죠. 빌딩이 빨라지자, 단 하나의 진짜 업무가 적나라하게 드러났습니다. 바로 무엇을 빌딩할 가치가 있는지 결정하는 것입니다.

한계점 (이 부분이 없다면 위 내용은 그저 광고에 불과합니다)

솔직히 말하자면, 그렇지 않다면 위의 모든 내용은 그저 보기 좋은 쇼윈도에 불과합니다.

이 시스템의 클라이언트는 바로 저입니다. 개발자이자, 동시에 그것이 필요한 사용자이기도 한 단 한 명의 사용자 말입니다. 이는 성과가 숫자로 증명되는 것이 아니라, 단지 저에게 더 잘 맞을 뿐이라는 것을 의미하며, 이는 가장 취약한 증거입니다. Yan OS는 완성되지 않았으며, 솔직히 그 본질상 결코 완성될 수도 없습니다.

다음으로, 에이전트는 자신의 아이디어를 사랑합니다. 동일한 모델에서 파생된 두 번째 에이전트는 첫 번째 에이전트의 아이디어를 과도하게 사랑하는 경향이 있습니다. 그래서 저는 두 번째 에이전트가 아닌, 최종적인 칼자루(Knife)를 직접 쥐고 있습니다. 이는 거짓말을 완전히 없애지는 못하더라도, 그 빈도를 낮춰줍니다.

컨텍스트(Context)는 비용과 주의력을 소모합니다. 에이전트가 올바른 판단을 내리게 하려면 적절한 컨텍스트를 제공해야 하는데, 그 컨텍스트를 수집하고 최신 상태로 유지하는 작업은 빌딩 속도에서 얻은 이득을 조용히 갉아먹기 전까지는 아무도 계산에 넣지 않는 작업입니다. 빌딩 시간을 몇 시간씩 아껴주는 시스템이라도, 컨텍스트를 다루는 과정에서 그 시간을 뒷문으로 쉽게 되돌려주게 됩니다.

그리고 가장 중요한 점은, 대조할 기준이 없는 곳에서는 제가 정확히 대체될 수 없다는 것입니다. 에이전트는 정답과 비교할 참조(Reference)가 있을 때 매우 영리합니다. 하지만 비교할 대상이 없을 때, 즉 질문이 "내가 올바른 것을 만들고 있는가"이고 시장이 아직 답을 주지 않았을 때는 취향(Taste), 위험을 감수하려는 욕구(Appetite for risk), 그리고 제품을 수년간 끌고 나가려는 의지가 결정을 내립니다. 이 부분은 아직 위임할 수 없습니다. 전체 시스템이 바로 이 지점에 서 있습니다. 이에 대한 자세한 내용은 여기에서 확인하세요: 빌딩이 저렴해질 때, 판단이 곧 업무가 된다.

팀이 사람을 채용할 때 실제로 구매하는 것

종합해 봅시다. 디자인과 코드가 거의 무료가 되었을 때, 제품 전문가(product person)를 채용하는 팀은 더 이상 명세서(spec)를 실행할 '손(hands)'을 구매하지 않습니다. 이제 무한한 손이 존재하며, 그들은 그 어떤 채용보다 저렴합니다.

팀이 실제로 구매하는 것은 제가 에이전트(agents)에게 맡기지 않은 바로 그 부분입니다: 무엇을 믿을지 결정하는 것, 자신의 가설을 폐기하는 규율, 그리고 사실처럼 들리는 거짓말을 알아채는 직관입니다. PRD(제품 요구사항 문서)를 더 빨리 쓰는 사람이 아닙니다. PRD를 쓰는 에이전트들을 운영하며, 어떤 것이 구축할 가치가 있는지를 아는 사람을 채용하는 것입니다.

저는 에이전트와 함께 혼자서 이것을 구축했습니다. 제가 광고비 지출 없이 3년 동안 Unicorn Embassy를 운영했던 것과 같은 방식입니다. 구축(building) 비용은 거의 제로로 떨어졌습니다. 판단(judgment)의 가격만이 유일하게 상승했습니다.

저는 Yan Nerovny이며, Unicorn Embassy의 제품 리드(product lead)이자 창립자입니다. 저는 nerovny.com/writing에서 제품, AI, 그리고 어디서든 무언가를 구축하는 것에 대해 글을 씁니다.

직접 에이전트로 제품을 운영하고 계신가요? 훔쳐갈 만한 가치가 있는 부분은 '알려진 것 / 알려진 것처럼 보이는 것 / 사실이었으면 하는 것(known / looks-like / wanted-to-be-true)'이라는 세 가지 분류 방식입니다. 여러분에게 이 방식이 어디서 막히는지 알려주세요: Telegram 또는 LinkedIn.