안녕하세요, AI 사범(AI師範)입니다.

지난번에는 「'이 일, 누가 맡을 거야?' ―― AI 세션을 병행시켰더니, 인간의 회사와 똑같은 문제가 발생했다」라는 이야기를 썼습니다 (「이 일, 누가 맡을 거야?」). 여러 개의 Claude Code를 병행 운용할 때 반드시 발생하는 누락과 중복 처리를, '대기 번호'라는 당번표 메커니즘을 통해 외부화했다는 이야기입니다.

그 기사는 제가 평소에 하고 있는 「Claude Code를 도구가 아니라 조직으로서 움직이는」 시도 중 하나였습니다. 이번에는 그 연장선상에서, 최근 관심 있게 지켜보던 비교에 관한 이야기를 하겠습니다. 테마는 이렇습니다 ―― 세상은 Claude Code를 「플러그인 (Plugin)」으로 강화한다. 나는 같은 과제를 「제도 (System/Institution)」로 해결하고 있었다. 양자를 대조했을 때 무엇이 남았는가.

세상은 도구를 더하고, 나는 규칙을 쓰고 있었다

최근 Claude Code를 강화하기 위해 플러그인을 조합하는 접근 방식이 화제가 되고 있습니다. 시각화를 위한 상태 표시, 응답을 압축하여 소비를 억제하는 것, 계획부터 구현·리뷰까지의 절차를 틀에 맞추는 것, 계획을 심층적으로 파고드는 인터뷰 역할 ―― 이러한 확장을 쌓아 올려 「변했다」라는 보고를 저도 흥미롭게 읽었습니다.

먼저 입장을 명확히 해두겠습니다. 이 기사는 그러한 강화 접근 방식에 대한 반론이 아닙니다. 플러그인으로 보완하는 길은 많은 사람에게 이치에 맞는 정공법입니다. 제가 쓰고 싶은 것은 부정(否定)이 아니라, 별개의 해법(別解) 제시입니다. 저는 우연히도 같은 과제군을 「확장 기능을 넣는 것」이 아니라 「조직의 규칙을 쓰는 것」이라는 다른 방향에서 해결해 왔습니다. 그 두 가지를 나란히 놓으면, 어느 쪽이 우월한가가 아니라, **「어디에 규율을 두는 것이 저렴한가」**라는 또 다른 질문이 보입니다. 그것이 이 기사의 본론입니다.

계기는 단순했습니다. 세상에서 평판이 좋은 플러그인 구성을 저의 운용 방식과 한 항목씩 대조해 보았습니다. 총 5개 항목. 결론부터 말씀드리면, 제가 새롭게 도입할 가치가 있다고 판단한 것은 그중 1개 항목뿐이었습니다. 나머지 4개 항목은 제 쪽에서는 이미 「제도」로 충분했기 때문입니다.

만약을 위해 덧붙입니다. 「우리 방식이 이겼다」라고 말하고 싶은 것이 아닙니다. 제 환경이 특수하기 때문입니다 ―― 한 명의 인간이 여러 AI 세션을 상시 병행시키며, 발주서와 검수와 대장으로 운영하고 있기 때문에, 애초에 전제가 다릅니다. 그렇기에 「당신의 전제에서는 어느 쪽이 더 저렴한가」를 생각하는 재료가 되기를 바랍니다.

도입한 것은 「시각화」 하나뿐이었다

5개 항목 중 제가 솔직하게 「이것은 도입하고 싶다」라고 생각한 것은, 세션 내의 상태를 항상 표시해 두는 시각화 메커니즘이었습니다. 지금 얼마나 문맥(Context)을 사용하고 있는지, 어떤 모드로 작동하고 있는지가 항상 눈앞에 보이는 것. 이것은 저의 운용에도 부족했던 조각이었기에 솔직하게 도입했습니다.

왜 이것만은 제도로 대체할 수 없었을까요? 시각화는 「실행 중인 세션의, 지금 이 순간의 상태」를 비추는 것이기 때문입니다. 저의 제도 측에는 소비를 나중에 집계하는 대장이나, 상한선에 가까워지면 멈추는 용량 가드(Capacity Guard)는 있었습니다. 하지만 그것들은 사후·사전 관리였지, **「달리고 있는 도중의 실시간 체온계」**는 아니었습니다. 이 부분은 도구로 메우는 것이 타당하다고 판단했습니다.

역으로 말하면, 나머지 4개 항목은 「그 자리에서 비추는 것」 이상의 일을 하려고 했고, 그 영역은 제도의 영역이었다 ―― 이것이 이번에 가장 전달하고 싶은 발견입니다. 차례대로 살펴보겠습니다.

왜 4개 항목은 「제도 측」에서 충분했는가

응답을 압축해도, 깎을 수 있는 것은 전체의 일부였다

4개 항목 중 이해하기 쉬운 것이, 응답을 압축하여 소비를 대폭 줄인다는 발상입니다. 출력을 줄이면 크게 줄어들 것이라는 생각은 직관적으로 맞게 들립니다.

하지만 실제로 측정해 보니 이야기는 반대였습니다. 어떤 집필 작업의 토큰(Token) 내역을 측정해 본 결과, 과거 문맥의 읽기가 약 23만 토큰인 것에 비해 실제 출력은 약 1만 토큰이었습니다. 소비의 대부분은 「읽기」 쪽에 있으며, 출력은 기껏해야 전체의 1~2%입니다. 즉, 출력을 아무리 줄여도 총 소비에 영향을 주는 것은 몇 퍼센트에 불과합니다. 「어디를 깎아야 효과가 있는가」는 소비 내역을 실제로 측정해 보지 않으면 알 수 없는 것입니다.

제 쪽에서는 이것을 압축 플러그인이 아니라 운용 규칙으로 다루고 있었습니다. 보고 양식을 가볍게 하기, 파일은 전문이 아니라 필요한 부분만 읽기, 감시 작업은 독립적으로 돌리지 않고 기존 처리에 편승시키기 ―― 이 모든 것이 「읽기 측의 총량」에 효과를 주는 궁리입니다. 효과가 있는 것은 응답 스타일의 압축이 아니라, 애초에 읽게 하는 양의 설계였습니다.

여기서 조금 보충하겠습니다. 「출력을 줄이는」 시책이 무의미하다는 뜻은 아닙니다. 출력이 지배적인 워크로드 (Workload) ―― 예를 들어 장문을 대량으로 계속 생성하는 것과 같은 사용 방식 ―― 이라면, 압축은 솔직히 효과가 있을 것입니다. 제가 말하고 싶은 것은, 자신의 소비 내역을 측정하지 않고 "아마 출력이 무겁겠지"라고 짐작하면, 효과가 없는 곳을 깎아내며 헛수고로 끝난다는 것입니다. 저 자신도 측정하기 전에는 "응답을 짧게 하면 효과가 있을 것"이라고 믿고 있었습니다. 실측하고 나서야 비로소 지배적인 항목이 읽기 측이라는 것을 알게 되었습니다. 그래서 제도 측의 첫걸음은 언제나 "먼저 측정하기"였습니다. 깎아내기 전에 어디가 무거운지를 숫자로 보는 것. 이것은 플러그인을 넣느냐 마느냐 이전의, 수수하지만 빼놓을 수 없는 토대입니다.

절차를 「실행 시의 대화」로 하면, 왕복이 배로 늘어난다

또 하나는, 요건 정의(Requirement Definition) → 계획 승인 → 테스트 주도(TDD) → 셀프 리뷰(Self-review)라는 규율 있는 절차를 하나의 틀(Template)로 갖추게 하는 발상입니다. 이것은 품질을 위한 정공법이며, 저 또한 규율 그 자체에는 찬성합니다. 문제는 "그 규율을 언제, 어디서 지불하느냐"였습니다.

이를 실행 시의 대화로 진행하면, AI는 "계획을 내놓는다 → 승인을 기다린다 → 리뷰한다"를 매번 그 자리에서 왕복합니다. 저의 실측 결과에 따르면, 이 다단계 대화를 런타임(Runtime)에서 수행하면 주고받는 횟수가 2~3배로 불어났습니다. 횟수가 늘어나면 그때마다 앞서 말한 "과거 문맥의 읽기"가 누적됩니다.

그래서 저는 규율을 발주서라는 한 장의 설계에 미리 앞당겨 담아두기로 했습니다. 요건, 인수 조건, 미결 사항, 금지 사항을 착수 전의 한 장에 다 써두는 것입니다. 실행하는 세션은 대화로 다듬는 것이 아니라, 그 한 장을 받아서 묵묵히 구현합니다. 그리고 품질은 구현한 세션 자신의 셀프 리뷰가 아니라, 이해관계에서 분리된 별도의 담당자가 독립적으로 검수합니다. 같은 규율이라도 놓는 위치를 바꾸는 것만으로 왕복 횟수가 줄었습니다.

중요한 점은, 지불하고 있는 규율의 총량은 거의 변하지 않았다는 점입니다. 요건을 다듬고, 계획을 세우고, 리뷰한다는 작업 자체는 어느 쪽 경로에서도 필요합니다. 차이점은 그것을 "실행 도중에, 매번, 대화로" 지불하느냐, "실행 전에, 한 번, 설계로" 지불하느냐뿐입니다. 전자는 착수가 빠른 대신 매번 비용이 재발합니다. 후자는 착수 전에 머리를 쓰는 대신, 같은 형태의 작업을 돌릴 때마다 재사용할 수 있습니다. 저의 환경은 동일한 형태의 작업을 여러 번 돌리기 때문에, 후자 쪽으로 기울수록 이득이 컸습니다. 반대로 말하면, 단 한 번뿐인 일이라면 굳이 발주서를 쓰는 것보다 대화로 진행하는 편이 더 빠를 것입니다.

심층 분석은 「자문」보다 「다른 모델의 반증」이 효과적이다

딱 하나 더. 계획을 심층 분석하기 위해 질문을 거듭하는 인터뷰어(Interviewer) 항목입니다. 계획의 허점을 없앤다는 목적은 중요하며, 저 또한 같은 목적의 메커니즘을 가지고 있습니다. 다만 저의 경우, 그것을 "자기 자신에 대한 심층 질문"이 아니라, 다른 모델에 의한 적대적 리뷰를 2회 수행하는 형태로 만들었습니다. 자문(Self-questioning)은 자신의 사고 습관 안에서 맴돌기 쉬워, 습관 밖에 있는 허점은 찾아내기 어렵습니다. 허점을 찾는 것은 같은 머리가 다시 생각하는 것보다, 다른 머리가 반증하러 오는 것이었습니다.

다른 모델에게 반증하게 하면, 저의 사고가 암묵적으로 전제하고 있던 것들을 가차 없이 찌릅니다. "이 계획은 입력이 이런 형태라면 깨지지 않습니까?", "이 인수 조건은 이렇게 해석하면 그냥 지나칠 수 있지 않습니까?". 스스로는 자명하다고 생각해서 쓰지 않았던 전제일수록, 타인의 머리에서 보면 허점으로 보입니다. 심층 분석의 가치는 질문의 개수가 아니라, 질문하는 시점이 자신의 외부에 있는가에 있었습니다. 그래서 저는 자문을 두텁게 하기보다, 시점이 다른 담당자를 한 단계 끼워 넣는 것에 투자했습니다.

남은 1개 항목(정해진 시간에 가동을 촉구하는 메커니즘)도 마찬가지로, 저의 환경에서는 큐(Queue)가 상시 돌아가고 있기 때문에 필요하지 않았습니다 ―― 다만 이것은 정해진 시간에 일하는 스타일에는 유효할 것이며, 단순히 전제가 맞지 않았을 뿐입니다. 여기서도 우열의 문제가 아니라 전제의 차이라는 점을 강조해 둡니다. 정해진 시간에 책상에 앉는 리듬으로 사용하는 사람에게는, 시각으로 등을 떠밀어 주는 메커니즘이 합리적입니다. 저처럼 "끝나면 다음 것을 집어 든다"를 끊임없이 돌리는 사용 방식에서는, 시각 신호는 오히려 노이즈가 됩니다. 같은 도구라도 전제에 따라 유효할 수도, 역효과를 낼 수도 있다 ―― 이 한 점은 5개 항목 모두에 관통하고 있었습니다.

규율은 「실행 시의 대화」가 아니라 「사안의 설계」에 두면 저렴하다

4개 항목을 되돌아보면, 관통하는 하나의 축이 있었습니다. 그것은 바로,

규율을 「실행 시의 대화」로 지불하면 비싸고, 「사안의 설계」에 담아두면 저렴하다.

라는 점입니다.

압축(Compression) 항목은 「응답이라는 런타임 (Runtime)의 동작」을 건드리는 것보다 「읽히는 양이라는 설계 (Design)」를 바꾸는 것이 더 효과적이었습니다. 절차(Procedure) 항목은 「실행 중의 왕복 (Round-trip)」으로 처리하는 것보다 「발주서라는 착수 전의 한 장」으로 접어두는 것이 더 저렴했습니다. 심층 탐구(Deep dive) 항목도 「그 자리에서의 자문 (Self-questioning)」보다 「별도 담당자에 의한 사후 검수 (Inspection)」가 더 구멍을 잘 찾아냈습니다.

플러그인(Plugin)의 대부분은 성질상 「실행 시 세션 (Session)의 동작」에 작용합니다. 그것은 매우 간편하며, 그렇기에 널리 사용됩니다. 반면 저의 제도는 「실행이 시작되기 전」과 「실행이 끝난 후」 ―― 즉 발주서와 검수와 대장이라는, **세션 외부의 구조 (Structure outside the session)**에 규율을 두고 있습니다. 같은 규율이라면 매 세션마다 비용을 다시 지불하는 것보다, 한 번 구조에 새겨 넣어 재사용하는 것이 횟수당 비용이 낮아집니다. 이것이 5개 항목을 비교했을 때 4개 항목이 제도 측에서 충족되었던 이유였습니다.

물론 구조에 새기기 위해서는 초기 비용 (Initial cost)이 발생합니다. 발주서의 양식을 정하고, 검수 담당을 나누고, 대장을 정비하는 ―― 이러한 초기 투자가 수지타산이 맞는 경우는 동일한 형태의 작업을 반복해서 수행할 때입니다. 단발성 작업이라면 그 자리에서의 대화로 끝내는 편이 더 저렴합니다. 따라서 「플러그인인가 제도인가」는 우열의 문제가 아니라, 당신이 같은 일을 몇 번 반복하는가에 따라 결정된다는 것이 솔직한 결론입니다.

한 가지 더 덧붙이자면, 이 두 가지는 배타적이지 않습니다. 저 자신도 시각화(Visualization)라는 도구는 순순히 추가했습니다. 도구로 메워야 할 빈틈에는 도구를 추가하고, 반복되는 규율은 구조에 새긴다 ―― 양쪽을 구분해서 사용하는 것이 실제 모습입니다. 「전부 플러그인으로」도 「전부 제도로」도 아닌, 각각의 규율에 대해 실행 시에 지불하는 것이 저렴한지, 설계 시에 지불하는 것이 저렴한지를 하나씩 가늠해 보는 것입니다. 그 가늠의 척도가 이번에 보여드린 「몇 번 반복하는가」와 「지배 항목은 어디인가 (먼저 측정한다)」 이 두 가지였습니다.

요약 ―― 그리고 다음 회차

이번에 전달하고 싶었던 것은 심플합니다.

• Claude Code의 강화는 플러그인으로 「도구를 추가하는」 길과, 규칙으로 「제도를 구축하는」 길이 있습니다. 양자는 대립 관계가 아닌 별개의 해법입니다.
• 제가 5개 항목을 비교하여 새로 도입한 것은 실시간 시각화 1개뿐이었습니다. 나머지 4개 항목은 제도 측에서 충족되었습니다.
• 그 차이를 만든 것은,
  규율을 「실행 시의 대화」에 둘 것인가 「사안의 설계」에 둘 것인가라는 한 가지 점입니다. 반복되는 작업일수록 후자가 더 저렴해집니다.

다시 말씀드리지만, 화제가 되는 플러그인 구성은 순수하고 강력한 정공법입니다. 저는 우연히 조직이라는 다른 입구로 들어왔을 뿐이며, 당신의 전제 조건에 따라 어느 쪽이 더 저렴할지는 달라집니다. 이 기사가 그 가늠을 위한 재료가 된다면 기쁘겠습니다.

다음 회차에서는 이 「설계에 접어넣는다」라는 사고방식을 조금 다른 각도에서 깊이 파고들어 보려 합니다. 무엇을 소재로 할지는 아직 정하지 않았지만, 또 하나 제 작은 회사에서 일어난 일을 이야기할 수 있으면 좋겠습니다.

그럼, 다음에 뵙겠습니다. AI 사범이었습니다.

Discussion