같은 작업. 두 가지의 질문 방식. 매우 다른 두 가지 결과. 그 순간 깨달음이 왔고, 그 이후로 계속 제 머릿속을 떠나지 않고 있습니다.

저는 AI 코딩 에이전트(AI coding agent)에게 할 일을 주었습니다. 괜찮지만 아주 좋지는 않은 결과물을 받았고, 요청을 다시 표현(rephrase)했더니 제가 정확히 원했던 결과물을 받았습니다. 다른 것은 아무것도 변하지 않았습니다. 같은 모델(model), 같은 리포지토리(repo), 같은 오후였습니다. 유일한 변수는 저였고, 제가 그것을 어떻게 구성(frame)했느냐였습니다.

모델은 괜찮았습니다. 제가 변수였습니다.

이것을 인정하는 것은 불편한 일입니다. 왜냐하면 제 결과물의 품질이, 어떤 날에 제가 올바른 질문 방식을 기억하느냐에 달려 있다는 것을 의미하기 때문입니다. 컨디션이 좋은 날에는 에이전트에게 실패 로그(failure log)를 먼저 가리켜주고, 수정하기 전에 재현(reproduce)하라고 말하며, 우리가 이미 사용 중인 패턴을 상기시켰습니다. 주의력이 분산된 날에는 그중 절반을 잊어버렸고, 결과도 절반밖에 얻지 못했습니다.

일을 잘 수행하는 방법에 대한 지식은 존재했습니다. 다만 그것은 제 머릿속에만 있었고, 제가 주의를 기울일 때만 나타났습니다. 제가 재사용할 수 있는 곳도 없었고, 다른 누구도 사용할 수 없었습니다.

이제 팀 전체가 그렇게 하는 모습을 상상해 보세요

개인에게 이것은 그저 익숙해져야 할 마찰(friction)일 뿐입니다. 하지만 이를 팀 단위로 확장하면 더 나쁜 상황으로 변합니다. 모든 사람이 에이전트를 조금씩 다르게 구동합니다. 어떤 사람은 깔끔한 결과를 얻는 요령을 알고 있지만, 다른 사람은 모릅니다. 어떤 사람은 제너레이터(generator)가 존재한다는 것을 기억하지만, 다른 사람은 그것이 올바르게 구성(scaffold)했을 내용을 직접 손으로 작성합니다.

결과물은 도구의 기능이 아니라, 누가 키보드를 잡고 있느냐의 기능이 되어버립니다. 그것이 진짜 비용이며, 어떤 날에는 작업이 괜찮아 보이기 때문에 잘 숨겨집니다. 당신을 힘들게 하는 것은 평균이 아니라 변동성(variance)입니다.

그래서 저는 좋은 버전을 기록했습니다

저는 실제로 좋은 결과를 만들어내는 작업 방식들을, 에이전트(agent)가 스스로 습득할 수 있는 작고 재사용 가능한 기술(skills)로서 기록하기 시작했습니다. 아무도 열어보지 않는 위키(wiki) 페이지가 아닙니다. 읽다 보면 핵심을 지나쳐 버릴 정도로 거대한 하나의 지침(instructions) 파일도 아닙니다. 그저 각 작업의 종류가 어떻게 진행되어야 하는지를 설명하는, 집중된 플레이북(playbooks)들입니다. 어려운 버그를 어떻게 추적하는지, 어떻게 테스트 우선(test-first) 방식으로 무언가를 구축하는지, 코드 한 줄을 쓰기 전에 거친 아이디어를 어떻게 제대로 된 사양(spec)으로 바꾸는지와 같은 것들 말입니다.

가장 중요했던 부분은 그것들을 쉽게 접근할 수 있도록 만드는 것이었습니다. 저는 카탈로그를 암기할 필요가 없도록 단 하나의 입구인 라우터(router)를 추가했습니다. 당신이 무엇을 하려는지 설명하면, 라우터가 적절한 플레이북으로 안내합니다. 이 모든 것은 선택 사항(opt-in)이며 일반 텍스트(plain text)로 구성되어 있습니다. 사소한 디테일처럼 들릴 수 있지만 그렇지 않습니다. 플레이북이 틀렸을 때, 그것을 수정하는 것은 논쟁이 아니라 단 한 줄의 변경이면 충분합니다.

기술(skills)에 대한 생각, 그리고 자동화가 실제로 추가될 가치가 있는 지점에 대한 Matt Pocock(@mattpocockuk)의 생각은 제가 이 문제에 접근하는 방식에 큰 영향을 주었습니다. 머릿속에 남은 핵심 아이디어는 이것입니다. 기술은 에이전트가 적절한 순간에 그것을 찾아 사용할 때만 제 역할을 다한다는 것입니다. 기술을 작성하는 것은 쉬운 절반에 불과합니다. 그것이 실제로 사용되게 만드는 것이 진짜 작업입니다.

변한 것은 속도가 아니었습니다

이전에는 모든 세션이 차가운 상태(cold)에서 시작되었습니다. 방법론은 그날 키보드를 잡고 있는 사람이 누구냐에 따라 달라졌습니다. 이제는 누가 요청하든 방법론은 동일합니다. 제가 시작하든 팀원이 시작하든, 에이전트는 버그에 대해 동일하고 절제된 루프(loop)를 실행합니다.

그 과정에서 어느 정도의 속도 향상이 있지만, 속도가 핵심은 아닙니다. 예측 가능성(predictability)이 핵심입니다. 저는 어떻게 질문해야 하는지를 기억하는 데 주의력을 낭비하는 것을 멈췄고, 오늘의 좋은 결과가 다음 주에는 평범한 결과가 될까 봐 남몰래 걱정하는 것도 그만두었습니다.

두 가지가 저를 놀라게 했습니다. 아무도 찾지 않는 기술은 무거운 짐일 뿐이기에, 결국 라우터가 기술만큼이나 중요해졌다는 점입니다. 그리고 자리를 잡는 기술들은 제가 구축하려 했던 영리한 예외 사례(edge cases)들이 아니라, 거의 항상 지루하고 반복적인 작업들이라는 점입니다.

만약 당신이 팀을 위해 이를 결정하는 사람이라면

정책 문서를 발행한다고 해서 팀이 AI를 사용하는 방식을 표준화할 수는 없습니다. 아무도 그것을 읽지 않으며, 일주일만 지나도 구식이 되어버립니다. 당신은 올바른 경로를 기본 경로(default path)로 만듦으로써 표준화해야 합니다. 즉, 무언가를 수행하는 올바른 방법이 곧 쉬운 방법이 되도록 만들어야 합니다.

이 방식은 시도하는 비용이 저렴합니다. 리스크가 낮고, 변경하기 쉬우며, 유용함이 증명되지 않는 것은 무엇이든 쉽게 버릴 수 있습니다. 팀 업무 중 점점 더 큰 비중을 차지하게 될 작업의 품질을 조용히 결정짓는 요소에 대해서라면, 이는 충분히 가치 있는 거래입니다.