글쓰기
프롬프트도 리팩터링 대상이다: AI 워크플로의 로그를 남겨 자동화할 것을 찾아내기
내 일에서 가장 신뢰하는 방식은 이것이다——경험이 "여기는 개선될 것 같다"고 짚는 것을 출발점으로 삼되, 직감대로 움직이는 대신 왜 그리고 어떻게 개선되는지를 실제 데이터로 증명하는 것. 직관은 어디를 봐야 할지 알려주고, 데이터는 내가 옳았는지, 그리고 무엇을 해야 할지 알려준다. 최근 달라진 점은, 그 "보는" 일을 LLM이——예전이라면 증명 자체가 수지에 안 맞을 만한 규모로——해낼 수 있게 됐다는 것이다.
Google에서 정확히 이걸 했다. Legal Content Policy and Standards 팀에서 Policy Lead로 일할 때, 어떤 종류의 법적 삭제 건이 백로그를 막히게 하고 어떤 것이 충분히 정형적이라 자동화할 수 있는지에 대한 직감이 있었다. 그것을 경험으로 주장하는 대신, LLM에 사건을 대규모로——수천 건을——분류·요약하게 해서 가설이 입증되거나 수정될 때까지 데이터를 돌렸다. Privacy Sandbox에서 TPM으로 일할 때도 형태는 같았다. 법무 리뷰로 넘어가는 문서 중 어떤 것이 정말 더 깊은 검토를 요하는가 하는 감각을, LLM이 한 건씩 리뷰하고 분류하는 파이프라인으로 바꿔, 값비싼 사람의 주의가 정작 필요한 곳에 떨어지게 했다. 두 경우 모두 직관은 출발점이었지 판결이 아니었다. LLM이 그 판결을 수지 맞는 것으로 만들어 줬다.
그래서 LayerX의 최근 엔지니어링 글(저자 마에다 요헤이(前田洋平)——LayerX '바쿠라쿠(バクラク)' 신청·경비정산 제품 모바일 앱의 EM, 필명 id:myohei11)이 눈에 들어왔다. 내가 겨눌 생각을 못 했던 대상——AI 워크플로 그 자체——에 바로 이 수를 쓰고 있어서다. 코딩 에이전트와 하루 종일 일하는 엔지니어는 같은 말을 계속 입력한다. "커밋하고, 푸시하고, PR 열어" "리뷰 코멘트에 대응해줘" "떨어진 CI 고쳐줘". 이건 반복하는 것 같다——하지만 "같다"는 느낌은 무엇을 자동화할지 정하는 근거로는 빈약하다. 그래서 에이전트에 보낸 프롬프트를 모두 로그로 남기고, 정기적으로 분석하며, 실제로 반복되는 패턴이 무엇을 만들어야 할지 말하게 한다. 마음에 남은 표현은 프롬프트도 리팩터링 대상이 된다는 한마디다. AI에 대한 지시도, 코드처럼, 관찰하고 측정하고 재사용 가능한 부품으로 다시 빚어낼 대상이다——같은 일을 열두 번 말하는 것은 중복이며, 코드에서 중복이 "냄새"인 이유는 바로 그것이 "추출할 가치가 있는 단위를 찾았다"는 신호이기 때문이다.
작동 방식
장치는 의도적으로 소박하다. UserPromptSubmit 훅이 각 프롬프트를 로컬의 prompts.jsonl에 덧붙인다——타임스탬프, 세션 ID, 본문을 한 줄 JSON으로 담고, 지나치게 짧은 입력은 걸러내며, 파일은 소유자만 읽을 수 있게 한다. 로그는 마스킹하고, 로컬에만 보관하며, 7일 후 삭제한다. (마지막 항목은 군더더기가 아니다. 프롬프트 로그는 "내가 무엇을 물었는가"의 기록 그 자체이므로, 프라이버시 가드레일은 생략 가능한 옵션이 아니라 구조를 떠받치는 핵심이다.)
이 로그 위에 두 개의 탐지 경로가 돈다. 하나는 라이브 세션 안에서 작동하며, 같은 작업이 다시 등장하는 것을 실시간으로 포착한다. 다른 하나는 매일 도는 스케줄 작업으로, 지난 한 주의 프롬프트를 읽어 의도별로 묶는다. 둘을 함께 돌리면 어느 한쪽만보다 놓치는 게 줄어든다——실시간 경로는 대화 안의 집중을, 배치 경로는 며칠에 걸쳐 흩어진 같은 요청을 잡아낸다. 패턴이 낮은 임계값——3회 이상——을 넘으면 Slack으로 알린다. 패턴 요약과 함께, 해당 Skill이나 명령을 만들기 위한 바로 쓸 수 있는 프롬프트까지 붙여서.
이것을 단순한 로그 기록 잔재주 이상으로 만드는 것은 두 가지 설계 결정이다. 첫째, 매일의 분석은 임베딩 클러스터링이 아니라 LLM을 통한 의미적 묶기를 쓴다——그래서 "PR 만들어", "커밋하고 푸시하고 PR 만들어", "수정 커밋하고 PR까지 올려줘"는 모두 하나의 패턴으로 접힌다. 표현이 달라도 의도가 같기 때문이다. 이것이야말로 언어 모델이 잘하고, 경직된 유사도 지표가 못하는, 모호하고 판단이 필요한 묶기다——앞서 그 법적 사건들을 분류할 때 정답이 키워드 필터가 아니라 LLM이었던 것과 같은 이유다. 둘째, 자동화는 제안에서 멈춘다. 스스로 Skill을 만들거나 지우는 일은 결코 없고, 사람이 하나하나 승인한다. 이로써 어설프게 쓸 만한 규칙이 모르는 새 무성하게 번지는 사태를 막는다——대다수 "자기개선형" 자동화를 부채로 만드는 바로 그 실패 양상이다.
흥미로운 반전: AI로 AI와 일하는 방식을 개선하다
이것을 말끔한 정리 요령 이상으로 만드는 것은 그 칼끝이 어디를 향하느냐다. 새 자동화를 드러내는 그 로그가 고장 난 자동화도 드러낸다. 사람들이 기존 Skill을 호출한 직후 매번 지시를 덧붙이고 있다면——"Notion 페이지도 갱신해줘", "Slack에도 올려줘", "아직 안 끝났어"——그 뒤따르는 대화는 그 Skill이 정의가 부족하다는 증거다. 완료 기준이 불명확하거나, 한 단계가 빠졌거나. 이렇게 시스템은 자기 자신에게 칼끝을 돌리고, 플라이휠이 나타난다. 더 나은 계측이 더 나은 자동화를 드러내고, 그것이 다음을 찾아내는 시스템 자체를 벼린다.
이 플라이휠이야말로, 수법보다 대상이 더 중요하다고 내가 보는 이유다. 에이전트형 코딩은 소프트웨어 엔지니어링의 기본 작업 모델이 되어 가고 있다——그러면 "사람과 에이전트가 실제로 어떻게 상호작용하는가"가 새롭고, 게다가 거의 계측되지 않은 개선의 표면이 된다. 대부분의 팀은 그 지점을 손으로 더듬으며 간다. 여기서 보고된 성과는 일부러 화려하지 않다——691회의 출현에 걸쳐 29개의 패턴, 그중 22개(76%)를 Skill이나 명령으로 전환해 652회분의 반복 프롬프트를 없앴고, 커밋→푸시→PR 사이클 하나만으로도 단일 /ship 명령이 되기 전까지 94회 등장했다——그리고 그게 핵심이다. 이것들은 세어보기 전까지 보이지 않는, 지루하고 빈도 높은 잡일이며, 이제 그것을 세는 일은 값싸졌다.
빈도는 신호이고, 판단 기준은 레버리지다
두 가지 단서로 스스로를 다잡는다. 첫째, 빈도는 중요도가 아니다. 자주 일어난다고 해서 추상화할 가치가 있는 것은 아니다——엔지니어를 몇 글자 입력에서 구해 주는 데에는 그 자체로는 별 가치가 없다. 가치는 한 프로세스 전체가 자동화되고, 반복 가능하고, 확장 가능해질 때 생긴다. 횟수는 그것을 찾을 곳을 알려줄 뿐, 찾았다는 증거가 아니다. 둘째는 비용이다. 프롬프트 로그는 이제 당신이 거버넌스해야 할 데이터이고, 프롬프트는 워크플로의 한 단면만 담으며, 한계효용에 불과한 Skill이 쌓이면 에이전트가 어느 것이 해당하는지 분간 못 할 만큼 환경을 막아 버린다. 어느 것도 치명적이지는 않지만, 엄연한 기술 부채이고, 그래서 사람의 승인 관문은 생략할 수 없다.
바꿔 말하면, 판단은 있어야 할 자리에 남는다——그리고 가장 큰 상은 어느 한 자동화된 워크플로가 아니다. 사람과 AI의 상호작용 그 자체의 효율을 끌어올리는 것이다. 왜냐하면 그것이 이제 거의 모든 개발의 임계 경로 위에 앉아 있기 때문이다. 그 구간을 빠르게 하면, 그 하류의 모든 것이 빨라진다. "이건 반복이다"라는 직감은 여전히 그저 직감일 뿐이다. 새로운 것은, 그것을 증명하고 손쓰는 일이 연구 프로젝트에서 매일의 습관으로 내려왔다는 점이다. 나도 내 몫을 로그로 남기기 시작하려 한다.