내가 Cadence를 만든 이유: GSD의 규율은 원하지만, 그 비용은 원치 않기에

저는 화려하지 않은 진실부터 시작하려 합니다. 그것이 정직한 것이며, 이 도구 전체가 정직함에 관한 것이기 때문입니다.

제가 Cadence를 만든 이유는 AI에게 한 번 데여서 복수를 다짐했기 때문이 아닙니다. 에이전트가 무언가 배포되었다고 말했는데 실제로는 그렇지 않았고, 고객이 이를 발견하게 되었다는 식의 극적인 기원 이야기는 없습니다. 저는 에이전트가 "완료(done)"를 과하게 보고하는 것을 본 적이 있습니다. 이런 방식으로 일하는 사람이라면 누구나 겪는 일입니다. 하지만 저에게 그런 전쟁 같은 경험은 없었습니다. 제가 겪은 것은 비용 문제였습니다.

저는 17년 차 시니어 스태프 소프트웨어 엔지니어(Senior Staff Software Engineer)이며, 지난 1년 동안 AI 엔지니어링 (AI Engineering) 분야를 깊게 파고들기 시작했습니다. 이것은 저의 새로운 집착이 되었습니다.

실제 이유

저는 AI 보조 작업을 GSD — Get Shit Done(일을 완수하기)를 통해 실행해 왔습니다. 그것은 좋습니다. 규율 있는 결과물을 만들어냅니다. 실제적인 계획, 실제적인 검증이 이루어지며, 에이전트가 딴 길로 새지 못하게 합니다. 문제는 그것을 얻기 위해 지불해야 하는 비용이었습니다. 주로 토큰 (Tokens) 비용이었고, 시간도 마찬가지였습니다. 모든 변경 사항은, 심지어 아주 작은 변경이라도 전체 메커니즘을 거쳐야 했습니다. 수많은 주고받기(back-and-forth)가 발생했습니다. 저에게 결정적인 계기가 된 것은 약 한 달 전, 여가 시간에 작업 중인 앱의 사소한 개선 작업을 수행할 때였습니다. 이는 구현하는 데 단 몇 분이면 충분했을 간단한 개선 사항들이었지만, GSD의 구조화된 워크플로우 (workflow)를 거치면서 원하는 것보다 훨씬 더 오래 걸렸고, 제 사용 한도의 상당 부분을 소모했습니다. 다음 날 아침, 저는 Cadence를 위한 브레인스토밍과 계획을 시작했습니다.

따라서 제가 시작한 질문은 "어떻게 하면 AI가 거짓말하는 것을 막을 수 있을까"가 아니었습니다. 질문은 이것이었습니다: "이 정도의 엄격함(rigor)을 유지하면서 비용은 아주 일부분만 지불할 수 있을까?"

답은 다음과 같았습니다: 모든 변경 사항에 대해 모든 게이트(gate)를 실행하지 마십시오. 어떤 종류의 작업에 어떤 체크(check)를 실행할지는 사람이 결정하게 하십시오. 오타 수정과 데이터베이스 마이그레이션 (database migration)이 같은 비용을 들여서는 안 됩니다. GSD의 규율은 유지하되, 특정 변경 사항이 실제로 필요로 하는 부분에 대해서만 비용을 지불하는 것입니다. 그것이 전체 아이디어입니다. 요령을 피우는 것이 아니라, 커스터마이징 (customization)을 통해 속도를 얻는 것입니다.

실제로 하는 일

Cadence는 하나의 루프(loop)입니다: DRAFT(초안 작성), BUILD(빌드), 그리고 SETTLE(확정)입니다. 여러분은 작업을 빌드하기 전에, 해당 작업이 수행해야 할 내용인 수락 기준 (acceptance criteria)을 작성합니다. 그다음 빌드합니다. 그리고 확정 (settle)을 시도합니다.

확정 (settle) 단계야말로 이 도구가 제값을 하는 부분입니다. 이 도구는 작업이 완료되었다는 에이전트 (agent)의 말을 그대로 믿지 않습니다. 대신 실제 작업 상태 (task state)로부터 각 수락 기준을 다시 도출하고, 테스트를 실행하며, 모든 기준이 실제로 테스트에 의해 참조되는지 확인합니다. 그리고 — 만약 기능을 켜두었다면 — 변경 사항 (diff)을 회의적인 태도를 갖도록 프롬프트된 별도의 검증기 (verifier)에게 전달합니다. 이 중 하나라도 실패하면, 확정을 거부합니다. 아주 요란하게 말이죠. 그리고 그 이유를 명시합니다.

제가 계속해서 되새기는 문장은 이것입니다: 에이전트가 믿음을 주는 것이 아니라, 상태 (state)가 믿음을 주는 것이다.

이 중 마법 같은 것은 없습니다. 이것은 마크다운 (markdown)과 JSON 폴더 위에 구축된 상태 머신 (state machine)일 뿐입니다. 모든 결정 사항은 디스크에 저장되고 모두 git에 기록되어 있기 때문에, 도구가 내린 모든 결정을 읽을 수 있습니다. 이는 의도된 설계였습니다. 저는 여러분이 신뢰해야만 하는 도구를 원하지 않았습니다. 여러분이 감사 (audit)할 수 있는 도구를 원했습니다.

실제로 제가 자랑스럽게 생각하는 부분

저는 Cadence를 Cadence를 사용하여 만들었습니다.

루프가 완성되었을 때 — settle이 처음으로 작동했던 37번째 커밋(commit) 즈음이었습니다 — 프로젝트의 나머지 부분을 이 루프를 통해 진행했습니다. 그 이후의 모든 단계는 일반 사용자가 하는 것과 동일한 방식으로 계획(plan), 빌드(build), 확정(settle)되었습니다. 마지막에는 총 44개의 명명된 단계 (named phases)가 생성되었고, 그 모든 단계는 확정 결과물 (settle artifact)을 레포지토리 (repo)에 포함하고 있습니다. 이는 전체 커밋의 약 93%에 달합니다.

저는 여러분이 이것을 맹목적으로 믿어달라고 요구하는 것이 아닙니다. 그것이 바로 핵심입니다. 프로젝트를 클론 (clone)하고, ls .cadence/phases/*/를 실행해 보세요. 그러면 모든 단계에서 SUMMARY 파일을 볼 수 있을 것입니다. 이 파일은 루프가 실제로 성공적으로 닫혔을 때만 존재합니다. 검증되지 않은 작업의 확정을 거부하는 이 도구 자체가, 바로 그런 방식으로 확정되었습니다.

미흡한 점

macOS 및 Windows CI 단계는 현재 보류된 상태입니다. 저는 Linux에서 개발하고 있으며, 현재로서는 그것만이 검증되었습니다.
두 번의 커밋으로 정착하는 관례(기능 커밋 후, 상태 파일(state files)을 위한 정착 커밋 수행)는 제가 수동으로 수행하는 작업입니다. 도구가 이를 강제하지는 않습니다.
구조적 게이트(structural gate)는 부여받은 작업 상태(task statuses)를 신뢰합니다. 작업에 대해 거짓을 말하고 가짜 통과 테스트(passing test)까지 작성한 결연한 에이전트라면 이를 통과할 수도 있습니다. 독립적인 검증기(independent verifier)가 존재하는 이유는 협력적인 체크(cooperative check)는 그 무엇도 위조 불가능하지 않기 때문이지만, 이것이 완벽한 보장이라고 거짓말하지는 않겠습니다.

이 글을 게시하는 이유

이것은 저의 첫 번째 공개 프로젝트입니다. 지난 몇 년간 여러 비공개 프로젝트를 진행해 왔지만, 저에게 매우 맞춤화되어 있어 더 넓은 대중을 위한 것이 아니라는 이유로 오픈 소스로 공개해야 한다는 압박을 느낀 적은 없었습니다. 하지만 몇 가지 이유로 다른 개발자들과 Cadence를 공유하고 싶습니다:

긍정적이든 부정적이든 피드백을 받아 계속해서 개선해 나가고 싶습니다.
제가 다른 곳에서는 찾지 못했던 균형, 즉 속도(speed)와 확신(confidence)을 제공한다고 믿습니다.

만약 Cadence를 사용하다가 문제가 발생한다면, 어디에서 발생했는지 알려주세요. 지금 저에게는 그것이 스타(star)보다 더 가치 있습니다.

— T. Powers / https://github.com/manehorizons/cadence