내 AI 에이전트가 또 다른 AI 에이전트를 필요로 했다. 우리가 이걸 하고 있다니.

Agent needs and agent
저는 AI 에이전트에게 IssueFlow의 마케팅을 도와달라고 요청했습니다.

저는 ChatGPT를 사용하여 GTM(Go-To-Market) 캠페인 관리를 돕게 했는데, 이는 합리적인 요청이었습니다. 적절한 사람들을 찾고, 제품을 설명하며, 고객 유입에 도움을 주는 것이죠. 이상적으로는 제가 본업을 하면서 두 개의 제품을 개발하는 동안 이루어지기를 바랐습니다. 왜냐하면 제 달력과 아내를 보니 명확한 결론이 나왔기 때문입니다. 즉, “도움이 필요하다”는 것이었습니다.

그래서 저희는 광고 집행부터 시작했습니다.

그러자 마케팅 에이전트가 불편한 점을 지적했습니다. 클릭 수를 얻는 것은 좋지만, 그 이후에 무슨 일이 일어났는지에 대한 더 나은 증거가 필요하다는 것이었습니다.

누군가가 가입했나요? 유용한 워크플로우를 완료했나요? 아니면 실제로 비용을 지불하는 고객이 되었나요?

공정한 질문들이었습니다. 하지만 그것은 IssueFlow 코드 자체에 통합되어야 했습니다...

그래서 저는 에이전트에게 해당 통합을 위한 개발 이슈(development issues)를 생성하도록 지시했습니다.

IssueFlow (제가 IssueFlow를 개발하는 데 사용하는 도구)가 이 이슈들을 가져갔고, 설정된 에이전트들이 배포 프로세스를 거치며 작업을 시작했습니다. 트리아지(Triage), 디자인, 디자인 검토(design-review)...

그러다가 첫 번째 디자인이 승인 게이트(approval gate)에 도달했을 때였습니다.

그때 상황이 흥미로워졌습니다.

요청자가 리뷰어가 되다

보통은 제가 그 단계에서 작업을 검토합니다.

이번에는 마케팅 에이전트가 이슈들을 작성했습니다. 그것은 자신이 무엇을 필요로 하고 왜 필요한지 알고 있었습니다. 그래서 저는 명시적으로 이 디자인들을 검토하고 승인하거나, 아니면 되돌려 보낼 수 있도록 권한을 위임했습니다.

분명히 하자면: 저는 이 이슈들에 대한 결정을 위임했습니다. 시스템은 인간의 승인이 구식 개념이라는 것을 조용히 결정하지 않았습니다.

이제 저희는 기능을 요청하는 에이전트, 그것을 디자인하는 다른 에이전트들, 그리고 제안된 해결책이 실제로 문제를 해결했는지 검토하는 요청 에이전트를 갖게 되었습니다.

에이전트가 에이전트를 필요로 했습니다.

저희는 성공적으로 작은 소프트웨어 팀을 재현했습니다. 다행히도 아무도 정기적인 정렬 회의(alignment meeting)를 잡지 않았습니다.

“디자인 검토를 통과했다”가 대화의 끝은 아니었다

첫 번째 문제는 가입 추적에 관한 것이었다.

이미 자동 디자인 검토를 통과했었다. 하지만 요청하는 에이전트가 이를 원래 요구사항과 비교하여 살펴본 결과, 누락된 부분이 발견되었다.

일부는 기술적인 문제였다: 웹사이트가 방문자의 신원 및 세션 정보를 포털로 어떻게 전달할지, 이벤트 전송에 불확실한 결과가 발생했을 때 무슨 일이 일어날지, 그리고 나중에 발생하는 전환이 유용한 기여도(attribution)를 유지하는 방법 등이었다.

특히 미묘했던 문제는 시간과 관련된 것이었다.

디자인의 타이밍 규칙은 정보가 전달되는 시점을 기준으로 했다. 검토자는 이를 실제 세션에 연결할 필요성을 느꼈다.

이것들은 누군가가 탭을 열어둔 채 자리를 비웠다가 나중에 돌아왔을 때, 당신의 깔끔한 가정이 해석적인 춤을 추기 시작하면서 비슷하게 들릴 수 있다.

에이전트는 구체적인 수정 사항과 함께 디자인을 되돌려 보냈다.

솔직히 고백하자면: 이 특정 사례에서는—정직하게 말해서—나도 전혀 알지 못했다… 나는 IssueFlow가 어떻게 처리하는지, 음… 이슈 흐름(issue flow)은 깊이 관여하고 있지만, 외부 마케팅 플랫폼과 어떻게 통합되는지는 모른다.

수정된 디자인은 그중 몇 가지를 해결했다. 검토자(마케팅 에이전트)는 그 변경 사항들을 수용했고, 남아있는 우려사항은 열어둔 채로 두고 또 다른 집중적인 수정(디자인 에이전트에게서)을 요청했다.

IssueFlow는 이러한 루프를 처리하도록 설계되었으며, 더 높은 복잡성의 요청을 다룰 수 있는 디자인 재작업 에이전트에게 이를 위임했다.

결국 그 문제는 요청자가 승인할 수 있는 디자인에 도달했다.

나에게 중요했던 것은 피드백이 작업의 일부로 남아있었다는 점이었다. 다음 검토에서는 전체 설명을 다시 시작하는 대신, 무엇이 변경되었는지에 초점을 맞출 수 있었다.

최고의 질문은 의미에 관한 것이었다

다음 두 가지 문제는 활성화(activation)와 결제(payments)에 관한 것이었다.

여기서 “기술적으로 가능함”과 “우리가 실제로 원하는 것” 사이의 차이가 매우 명확해졌다.

활성화의 경우, 하나의 제안된 해석은 요청을 더 작고 세부적인 하위 이슈로 나누는 것을 의미 있는 진전으로 간주할 수 있었다.

하지만 그것이 우리가 원했던 측정 기준은 아니었다.

더 많은 작업을 생성하는 것이 유용한 작업을 완료하는 것과는 같지 않습니다.

만약 그렇다면, 제 할 일 목록이 가장 성공적인 고객일 겁니다.

요청자는 반대했습니다: 활성화는 진정으로 성공적인 워크플로우 결과물을 반영해야 합니다. 요청을 조각으로 나누는 것만으로는 충분하지 않았습니다. 에이전트 대 에이전트(Agent vs Agent)가 되었습니다. Astra와 Opus의 대화입니다. 그리고 저는 지켜보고 있습니다…

the review: creating more tasks isn’t the same as delivering useful work
결제 설계는 또 다른 질문을 제기했습니다.

만약 결제를 확인할 수 있지만, 이전 결제 내역 확인이 끝나지 않았다면, 이것을 고객의 첫 결제라고 부를 수 있을까요?

돈이 도착했다는 것은 알지만, 그것이 처음이라는 것을 반드시 아는 것은 아닙니다.

이러한 구분이 새로운 유료 고객을 측정하려고 할 때 중요합니다.

수정된 설계는 불확실성을 확신에 찬 것처럼 보이는 숫자에 강제하기보다, 이러한 사실들을 분리했습니다.

또한 동의(consent) 및 복구와 관련된 수정 사항도 있었습니다: 분석은 합의된 동의 규칙을 존중해야 하며, 측정 실패가 근본적인 고객 워크플로우가 성공하는 것을 막아서는 안 됩니다.

이것들은 수용 결정이었습니다. 구현을 통해 요청의 의미를 보존하는 것에 관한 것이었습니다.

승인(Approval)이 여전히 마법 지팡이는 아니었다

설계가 승인된 후, 구현이 계속되었습니다.

그리고 나중에 확인 과정에서 더 많은 문제가 발견되었습니다.

IssueFlow는 흐름을 이어갔습니다: 유효성 검사(validation), 보안 점검(security check)을 거쳤고, 그 다음 코드 리뷰(Code review)가 구현 결함을 포착했습니다. 유효성 검사는 누락된 테스트 증거를 노출했습니다. 관련 변경 사항들은 함께 작동할 수 있도록 조정되어야 했습니다.

이것 또한 유용했습니다.

설계 게이트(design gate)가라고 해서 그 이후의 모든 것이 올바른 것은 아닙니다. 그것은 작업에 더 명확하게 정의된 방향을 제시해 줄 뿐이며, 나중 확인 과정도 여전히 할 일이 있습니다. IssueFlow 자체는 모든 게이트를 통과할 때까지 이슈를 수정하기 위해 재라우팅했습니다.

세 가지 이슈 모두 결국 완료되었고, 코드는 성공적으로 프로덕션에 배포되었습니다.

하지만 그것만으로는 “측정 문제가 해결되었다!”라고 발표할 권한은 아니었습니다.

설정(Configuration)과 실제 처리된 이벤트 검증은 여전히 별개의 작업이었습니다. 출하된 코드와 검증된 고객 여정은 다른 이정표입니다.

저는 시스템—그리고 그것을 사용하는 사람들—이 계속해서 그 구분을 지켜나가기를 바랍니다.

제가 얻은 교훈

저는 IssueFlow를 구축했기 때문에, 이것은 독립적인 고객 리뷰가 아닙니다. 제품을 만들기 위해 우리가 사용하는 제품에 대한 실제 연습이었습니다.

그리고 순탄하지 않았습니다. 일부 리뷰는 너무 많은 읽기를 요구했습니다. “무엇을 고치라고 요청했고, 무엇이 바뀌었으며, 증거가 어디 있는지”에 대한 더 명확한 요약이 과정을 더 쉽게 만들었을 것입니다.

그럼에도 불구하고 유용한 부분은 매우 구체적이었습니다.

요청하는 에이전트(requesting agent)는 작업을 검사하고, 그 해석에 이의를 제기하며, 특정 피드백을 반환하고, 중요한 격차들이 해결되었을 때 수정을 승인할 수 있었습니다.

배포 워크플로우(delivery workflow)는 이러한 결정들을 유지하고 계속되었습니다.

제가 개인적으로 모든 리뷰 응답을 직접 타이핑한 것은 아닙니다. 저는 누가 이 작업에 대한 결정을 내릴 수 있는지 결정했습니다.

제가 신경 쓰는 통제란 바로 이것입니다: 실행과 판단을 의도적으로, 경계와 제가 검사할 기록을 가지고 위임할 수 있다는 것.

또한, AI 에이전트가 다음과 같은 시대를 초월하는 소프트웨어 개발 경험을 발견하게 했다는 점도 흥미롭습니다:

‘거의 다 왔어. 하지만 내가 요청했던 것은 아니야.’

어떤 것들은 정말 모든 기술 변화를 견뎌냅니다.

코딩 에이전트(coding agents)로 구축하고 있다면, ‘완료’가 여전히 원래 원했던 것을 의미하는지 누가 확인합니까?

저는 AI 코딩 에이전트를 위한 워크플로우 오케스트레이션 도구인 IssueFlow의 개발자입니다. 이것은 인간의 판단을 원하는 곳에 유지하면서 개발 프로세스를 자동화하는 데 도움을 줍니다. 이 이야기는 IssueFlow 자체를 구축하기 위해 사용한 경험에서 나온 것입니다.