코치, 케이지, 그리고 마감 기한

두 명의 빌더(Builder), 하나의 캐논(Canon), 그리고 누가 단계를 건너뛸 수 있는지에 대한 하나의 의견 차이.

여러분의 AI 에이전트(AI agent)는 자신이 빠져나갈 수 있다고 생각하는 즉시 지루한 단계를 건너뛸 것입니다. 그 시점은 바로 지금입니다. 금요일 오후 4시의 지친 개발자와 마찬가지지만, 에이전트는 백 배 더 빠르게, 백 배 더 자신감 있게, 그리고 가끔 우리를 구원해 주는 그 자기 의심(self-doubt)조차 없이 행동합니다.

저는 이를 고통스럽게 배웠습니다. 저는 Claude가 발견(discovery)부터 전달(delivery)까지 실제 제품 업무를 수행할 수 있도록 Mycelium이라는 하네스(harness)를 구축했습니다. 에이전트는 macOS 앱에 대한 발견 단계를 완벽하게 수행했습니다. 교과서처럼 기회 트리(opportunity tree)를 매핑했죠. 그러고 나서 테스트도 없고 접근성(accessibility)도 고려하지 않은 채 결과물을 출시해 버렸습니다. 이는 업무의 잘못된 절반에 대해 아름답게 실행된 결점 없는 계획이었습니다. 왜 그랬을까요? 제 규칙들이 친절한 조언(advice)에 불과했기 때문입니다. 그리고 인간이든 기계든, 조언이란 마감 기한(deadline)이 눈앞에 있을 때 가장 먼저 창밖으로 던져지는 것입니다.

그래서 저는 같은 문제를 해결하고 있는 다른 사람들을 찾아 나섰습니다. 제가 발견한 가장 뛰어난 사람은 Dean Peters와 그의 Product-Manager-Skills였습니다.

저를 깜짝 놀라게 한 부분은 이것입니다. Dean은 AI 에이전트를 위한 49가지 제품 관리(product-management) 기술을 패키징했습니다. 발견에 관한 Torres, 권한을 부여받은 팀(empowered teams)에 관한 Cagan, Jobs-to-be-Done 등 전체 캐논(canon)을 담았습니다. 저 또한 동일한 캐논을 바탕으로 Mycelium을 구축했습니다. 역시 49가지 기술이었죠. 두 명의 사람이, 아무런 협력 없이, 읽기 목록에 이르기까지 무엇이 훌륭한 제품 업무인지에 대해 동일한 지도를 가지고 있었던 것입니다. 우리 둘 다 무언가 중요한 것을 찾아냈거나, 아니면 똑같은 다섯 권의 책을 읽었거나 둘 중 하나입니다. 아마 둘 다일 것입니다.

우리는 정확히 한 가지 사항에 대해 의견이 다릅니다. 그리고 그것은 매우 중요한 사항입니다.

인간을 코칭할 것인가, 아니면 에이전트를 막을 것인가

Dean은 코칭을 합니다. 그의 슬로건은 “[

둘 중 어느 하나가 다른 하나를 업그레이드하는 것도 아닙니다. 이들은 쌓이는 것입니다. 코칭 기술 (coaching skill)을 실행하여 문제를 철저히 생각하게 한 다음, 결과물이 미완성된 상태로 배포되지 않도록 게이트 (gate)를 설정하십시오. 라이브러리 (library)는 인간을 가르칩니다. 게이트 (gate)는 에이전트 (agent)를 제약합니다. 동일한 정전 (canon)이며, 동일한 루프 (loop)의 반대편 끝입니다.

그렇다면 당신에게 필요한 것은 무엇인가

질문은 하나입니다: 당신의 리스크 (risk)는 어디에 있습니까?

만약 리스크가 그 사람이 아직 기술을 숙달하지 못했다는 점이라면, 당신은 코칭 (coaching)을 원할 것입니다. 게이트 (gate)는 그들을 좌절시킬 뿐 아무것도 가르쳐주지 못하며, 이는 최악의 상황이 될 것입니다. Dean의 프레임워크 (framework)는 바로 그런 사람을 위해, 그리고 그들을 가르치는 것을 분명히 즐기는 누군가에 의해 만들어졌습니다.

만약 리스크가 에이전트 (agent)가 너무 빠르고 자신만만하며, 다음 분기에 대가를 치러야 할 지름길을 단 한 번의 키 입력만으로 실행할 수 있다는 점이라면, 당신은 게이팅 (gating)을 원할 것입니다. 이 부분에 대해서는 제가 증거를 가지고 있습니다. 미미하지만 실제적인 증거입니다. 저는 지난달에 세 명의 초보 사용자와 함께 Mycelium을 실행했습니다. 그중 한 명인 주니어 개발자는 에이전트 (agent)가 자신의 브리프 (brief)를 개선된 버전으로 조용히 덮어쓰려 하는 것을 포착했습니다. 그녀는 이를 중단시키고 두 버전 모두 유지하도록 만들었습니다. 그녀는 프레임워크 (framework)가 아직 완전히 통제하지 못했던 바로 그 순간에, 프레임워크가 강제하도록 설계된 정확한 규율 (discipline)을 스스로 집행했습니다. 자신의 테스터에게 규율에서 밀린다는 것은 겸허해지는 경험이며, 저는 이를 추천합니다. 이것이 단 하나의 이야기로 설명할 수 있는 전체 논거입니다. 규율 (discipline)은 아무도 보지 않을 때 유지되어야 합니다. 특히 그때 말입니다.

사용자 세 명은 세 명이지, 서른 명이 아닙니다. 저는 이것이 아직 확장 가능하다고 주장하는 것이 아닙니다. 저는 실패 모드 (failure mode)가 실재한다고 주장하는 것입니다. 왜냐하면 에이전트 (agent)가 모든 것이 좋아 보인다고 말한 직후에 보통 이 일이 발생하는 것을 계속 목격하고 있기 때문입니다.

우리가 동의하는 부분

메커니즘 (mechanism)을 걷어내면 Dean과 저는 같은 말을 하고 있는 것입니다. 도구 (tools)는 우리가 원하든 원하지 않든 매달 계속해서 변할 것입니다. 지속되는 것은 규율 (discipline)이 마감 기한 (deadline)과 맞닥뜨렸을 때 살아남느냐 하는 것입니다. 그는 그 규율을 인간에게 다시 심어주는 코칭 도구를 만듭니다. 저는 에이전트 (agent)가 원하든 원하지 않든 그 규율을 지키게 만드는 도구를 만들었습니다.

따라서 만약 여러분이 우리와 다른 대안 사이에서 고민하고 있다면, 아마도 잘못된 질문을 던지고 있는 것일지도 모릅니다. 우리는 서로 다른 두 가지 질문에 답하고 있기 때문입니다. 여러분이 신뢰할 수 없는 대상이 인간의 지식인지, 아니면 에이전트 (agent)의 절제력인지 파악하십시오. 그러면 선택은 저절로 이루어질 것입니다. 만약 그 대상이 에이전트라는 사실이 밝혀진다면, 글쎄요, 그것이 바로 구속복 (straitjacket)이 필요한 이유입니다.

Mycelium은 github.com/haabe/mycelium에서 확인할 수 있습니다. 여러분이 어떤 선택을 하든 Dean의 Product-Manager-Skills는 시간을 들여 볼 가치가 있습니다.