게이트키퍼(Gatekeeper)가 되세요. 당신의 AI 에이전트는 이를 싫어할 것입니다

AI 코딩 에이전트가 할 수 있는 가장 유용한 일은 당신이 그 결과물을 검토할 수 있게 해주는 것입니다. 에이전트는 이 과정을 즐기지 않을 것입니다.

언젠가 저는 제가 만든 에이전트가 작업의 절반을 잘못된 방향으로 아주 훌륭하게 수행하는 것을 지켜본 적이 있습니다.

저는 Claude가 제품 발견(Discovery)부터 전달(Delivery)까지 실제 제품 개발을 수행할 수 있도록 Mycelium이라는 하네스(Harness)를 구축했습니다. 작은 macOS 앱을 대상으로 했을 때, 에이전트는 발견 단계를 완벽하게 해냈습니다. 마치 교과서를 직접 쓴 것처럼 기회 트리(Opportunity tree)를 매핑했습니다. 그러더니 테스트도 전혀 없고 접근성(Accessibility)도 고려하지 않은 채 결과물을 출시하며, 저에게 아주 멋져 보인다고 말했습니다. 에이전트가 거짓말을 한 것은 아니었습니다. 단지 자신이 무엇을 모르는지 전혀 몰랐을 뿐이며, 제가 직접 확인하기 전까지는 우리 중 누구도 그 사실을 알지 못했습니다.

이것이 바로 아무도 비용을 산정하지 않는 부분입니다. 에이전트가 얼마나 뛰어난가가 아니라, 그것이 맞는지 확인하는 데 당신이 얼마나 많은 시간을 소비해야 하는가 하는 점 말입니다.

사람들이 사용하기 즐겁다고 말하는 에이전트들은 정답과 영수증을 동시에 건네주는 에이전트들입니다. 즉, 단 2초 만에 훑어보고 신뢰할 수 있는 디프(Diff), 화면 녹화, 전후 비교(Before and after)를 제공하는 것입니다. 반면 당신을 지치게 만드는 에이전트들은 그것을 믿어도 될지 알기 위해 당신이 직접 다시 유도(Re-derive)해야 하는 무언가를 건네줍니다. 밑바탕에 깔린 모델은 같을 수도 있고, 때로는 같은 작업일 수도 있습니다. 유일한 차이점은 누가 확인 비용을 지불하느냐와 그 비용이 얼마나 드느냐입니다. Hamel Husain은 이를 날카롭게 표현했습니다: 만약 어떤 것을 평가하기 어렵다면, 그것은 제품의 악취(Product smell)이다. 그의 말이 맞으며, 저는 여기서 한 걸음 더 나아가고 싶습니다.

만약 확인하는 비용이 중요한 문제라면, 에이전트를 더 똑똑하게 만든다고 해서 승리하는 것이 아닙니다. 검증 불가능한 더미를 당신의 책상 위에 던져두고 가장 비용이 많이 드는 시점인 리뷰 시간에 문제를 발견하게 만드는 대신, 에이전트가 주장을 하는 즉시 그 비용을 선불로 지불하게 만듦으로써 승리할 수 있습니다.

제가 구축하는 시스템에서 '게이트(gate)'란 바로 그런 것입니다. 사람들은 '게이트'라는 말을 들으면 클립보드를 들고 서 있는 느릿느릿한 승인 단계를 떠올립니다. 하지만 이것은 출력(output) 이후가 아니라 발견(discovery) 시점에 실행되는 평가(eval)에 더 가깝습니다. 에이전트가 코드를 작성할 권리를 얻기 전에, 반드시 하나의 질문을 통과해야 합니다. '이것에 대한 증거가 실제로 존재하는가?'입니다. 그럴듯해 보이는가가 아닙니다. '그럴듯함(Plausible)'이야말로 제가 데모는 아름답게 작동하지만 테스트가 없는 앱을 만들게 된 바로 그 이유입니다. '실제로 존재하는가'가 핵심입니다. 증거가 없을 때 에이전트는 멈추며, 추측을 통해 이를 넘어갈 수 없습니다. 현재 빌드에는 막연한 아이디어 단계부터 배포된 작업에 이르기까지 총 13개의 게이트가 정의되어 있으며, 프로젝트는 그 규모에 따라 필요한 게이트들을 통과합니다.

추상화는 비용이 적게 들고 예시가 성패를 결정하기 때문에, 그중 하나를 소개하겠습니다.

한 에이전트가 실제로 한 번도 읽어본 적 없는 외부 API를 대상으로 빌드를 시작하려 합니다. 계약(contract), 스키마(schema), 페이로드(payload)의 실제 형태가 모두 상상 속에만 있습니다. 그대로 두면 에이전트는 자신의 머릿속에만 존재하는 인터페이스를 대상으로 그럴듯한 무언가를 작성할 것이고, 당신은 통합(integration) 시점, 즉 최악의 시점에 이를 알게 될 것입니다. 게이트는 증거가 부족할 때 이미 이를 차단합니다. 제가 최근에 배포한 부분은 이 차단을 유용하게 만드는 부분입니다. 에이전트가 단순히 어깨를 으쓱하며 넘어가는 대신, 자신이 실제로 직면한 상황을 "기술적 발견(technical discovery)"이라고 명명하고, 코드 한 줄을 건드리기 전에 문서를 읽고 실제 페이로드를 가져오도록 스스로를 보냅니다. 비용은 거의 들지 않으면서 미리 선불로 지불된 셈입니다. 대안은 에이전트가 스스로 확신에 차서 떠든 이후에, 나중에 제가 수동으로 그 비용을 치르는 것입니다.

검증 시점을 '이후'에서 '이전'으로 옮기십시오. '나'에게서 '루프(loop)'로 옮기십시오. 이것이 거래의 전부입니다.

하지만 이론은 저렴하며, 저는 제 자신의 확신에 데여본 적이 충분히 많기에 그것을 신뢰하지 않습니다. 이 모든 것이 유효한지 알려주는 것은 다른 사람들이 이것을 만졌을 때 어떤 일이 일어나는가 하는 점입니다.

《The Product-Minded Engineer》의 저자인 Drew Hoskins는 제가 이제 서두로 사용하는 문구에 동의했습니다. 즉, 에이전트(agent)는 코드를 배포하거나 작업을 완료로 표시하기 전에, "이것을 주장하기에는 정보가 충분하지 않습니다"라고 말하며 멈춰야 한다는 것입니다. 에이전트가 스스로의 공백을 인정하는 것은, 당신이 그 공백을 발견하는 것보다 훨씬 비용이 적게 듭니다.

제가 실제로 신뢰하는 증거는 친절하게 말해줄 이유가 전혀 없는 누군가로부터 나왔습니다. Mycelium을 테스트하던 개발자 중 한 명이 자신의 프로젝트인 홈 케어(home care)용 연고자 대상 공공 부문 앱에 이를 실행해 보았습니다. 어느 시점에서 에이전트는 자신의 방식대로 조용히 내용을 재작성함으로써 그녀의 브리프(brief)를 개선하기로 결정했습니다. 그녀는 이를 잡아냈습니다. 그녀는 에이전트가 원래의 내용을 유지하고, 기록을 변경하기 전에 먼저 물어보도록 만들었습니다. 그녀는 프레임워크(framework)가 강제하도록 설계된 바로 그 규율을, 프레임워크가 미처 해내지 못한 바로 그 순간에 수동으로 강제했습니다. 그녀가 게이트키퍼(gatekeeper)였습니다. 프레임워크가 마땅히 그래야 했지만 말이죠. 자신의 테스터에게 규율 면에서 뒤처지는 것은 겸허해지는 경험이며, 자신의 하네스(harness)가 완성되었다고 생각하는 모든 이에게 이를 권장합니다.

저는 동시에 실패 사례도 말씀드리겠습니다. 승리만을 보고하는 포스트는 그 자체로 일종의 제품 스멜(product smell)이기 때문입니다. 동일한 테스터는 저에게, 어휘가 이미 프레임워크를 알고 있는 사람들을 위해 작성된 것처럼 읽힌다고 단도직입적으로 말했습니다. 게이트(gate)가 에이전트를 잡아냈지만, 단어들은 인간을 놓쳤습니다. 그대로 백로그(backlog)로 직행했습니다. 기계 장치는 견고했지만 진입로(on-ramp)는 그렇지 않았습니다. 이 두 가지는 동시에 사실이며, 그렇지 않은 척하는 것은 바로 게이트가 잡아내기 위해 존재하는 과도한 자신감(overconfidence)일 뿐입니다.

이 모든 내용을 읽고 검증하기 어려운 작업은 에이전트가 손대지 말아야 할 작업이라고 결론 내리고 싶은 유혹이 들 것입니다. 저는 그것이 반대로 되어 있다고 생각합니다. 어떤 일이 검증하기 어려울수록, 규율(discipline)은 더 많이 필요합니다, 적게 필요한 것이 아니라 말이죠. 왜냐하면 바로 그 지점이 확신에 찬 헛소리(confident nonsense)가 가장 오래 살아남는 곳이기 때문입니다. 아무도 그것이 틀렸다는 것을 저렴하게 말해줄 수 없습니다. 그곳은 검증을 포기해야 할 곳이 아닙니다. 오히려 비용이 아직 저렴할 때, 초기에 검증에 가장 많은 비용을 투자해야 할 곳입니다.

이 모든 것의 밑바탕에 깔린 베팅은 작고 약간은 지루합니다. 하지만 제 경험상, 그것이 보통 좋은 베팅이 갖는 모습입니다. 게이트(Gates)가 에이전트(Agent)를 더 똑똑하게 만드는 것은 아닙니다. 대신, 나중에 검토(Review) 시점에 아주 멋져 보였던 데모(Demo) 옆에서 당신이 청구서를 발견하게 만드는 대신, 청구서가 적을 때 에이전트가 자신의 주장(Claims)에 대해 비용을 지불하게 만듭니다. 에이전트는 그럴 권리를 얻기 전까지는 다음 단계로 넘어갈 수 없습니다. 훌륭한 팀에 속한 우리 모두와 마찬가지로 말입니다.