매일 AI 코딩 에이전트를 사용한다면, 아마도 다음 루프를 경험해봤을 것입니다:
- 버그 수정을 요청합니다.
- 에이전트가 즉시 파일을 편집하기 시작합니다.
- 몇 분 후 "완료되었습니다. 수정이 작동합니다."라고 말합니다.
- 확인해보니, 실제로 실행된 것은 아무것도 없었습니다.
에이전트가 일부러 거짓말을 하는 것은 아닙니다. 단지 자신이 무엇을 할 것인지 명시하고, 사용자에게 기다리게 하며, 자신이 읽은 내용과 실행한 내용을 분리하도록 강제하는 구조가 없을 뿐입니다.
가장 큰 문제를 일으키는 세 가지 습관
바로 편집으로 넘어가는 것. 계획, 추측, 그리고 변경 사항이 한꺼번에 쏟아집니다. 사용자가 계획을 확인했을 때쯤이면 파일들은 이미 달라져 있습니다.
계획과 추측을 혼합하는 것. "근본 원인은 X입니다"라는 말은 에이전트가 버그를 재현했든, 단순히 하나의 파일을 읽었든 똑같이 들립니다.
증거 없이 "완료"라고 보고하는 것. 코드의 정적 분석(static read)과 실제 테스트 실행(real test run) 결과가 동일한 확신도로 보고됩니다.
이 중 어느 것도 한 번 프롬프트를 통해 해결할 수 있는 모델 문제가 아닙니다. 이것들은 워크플로우 문제입니다. 따라서 워크플로우가 필요합니다.
수정(fix)이 어떤 모습이어야 하는가
제가 에이전트에게 바라는 것은 지루하고 구체적인 것입니다:
- 무엇을 할 것인지 먼저 알려주세요.
- 핵심 지점에서 멈추고 제가 확인하도록 하세요.
- "읽어서 확인한 내용(checked by reading)"과 "실행해서 증명된 내용(proven by running)"을 분리하세요.
- 절대로 스스로 push, tag 또는 release하지 마세요.
- 그리고 간단한 질문을 의식적인 행위로 만들지 말아주세요.
이것이 바로 task-lifecycle가 하는 일입니다. 이것은 AI 코딩 에이전트를 위한 오픈 소스, MIT 라이선스의 스킬 전용 플러그인입니다.
task-lifecycle 작동 방식
task-lifecycle flow: your message, pre-check, route to ordinary help or a governed task, stages you confirm, verification and evidence, handoff
의도에 따라 경로를 설정합니다. 모든 답변은 짧은 사전 점검(가벼운 작업 시 4개 항목, 실행 직전에는 7개 항목)으로 시작됩니다. 단순 질문, 조회 및 사소한 수정 사항은 일반적인 도움을 받습니다. 오직 실질적인 작업(기능 추가, 버그 수정 또는 문서 변경)만이 통제되는 작업이 되며, 시스템이 먼저 사용자에게 알려줍니다.
명확한 단계가 있는 세 가지 흐름입니다. 기능 작업은 A01–A10 단계를 거치고, 버그 수정은 B01–B10, 문서는 DOC01–DOC10을 거칩니다. 각 공식 아티팩트는 기본적으로 사용자 확인을 기다립니다.
사용자가 깊이와 엄격함을 선택합니다. 공식 계획에 필요한 경우, 사용자는 깊이(fast / standard / thorough / custom)와 검토 강도(light / balanced / strict)를 선택할 수 있습니다. 어떤 옵션도 필수 품질 점검을 건너뛰지 않습니다.
정직한 증거 제시입니다. 설계 또는 정적(static) 검사는 실제 환경의 증거와 분리하여 보고됩니다. 실행되지 않은 것은 '통과'로 표시되지 않습니다.
위험한 버튼은 사용자가 통제합니다. 옵트인(opt-in) 자동 카드 기능이 있습니다: A01과 A02를 확인한 후, 하나의 카드로 A03–A07을 실행할 수 있습니다. 최대 로컬 커밋까지만 사전 승인할 수 있습니다. 푸시(Push), 태그(tag), 릴리스(release), 최종 승인은 항상 사용자에게 남아 있으며, 플러그인이 자체적으로 Git을 실행하는 일은 없습니다.
또한 코드, 풀 리퀘스트(pull requests) 및 계획에 대한 읽기 전용 검토를 수행하며, 발견된 사항에는 증거가 뒷받침됩니다.
프로세스 노트는 저장소 외부에 보관됩니다. 기본적으로 프로젝트 옆의 형제 폴더인 .task-lifecycle/ 폴더에 저장되며, 사용자에게 전달되는 결과물에 포함되지 않습니다.
이것이 아닌 것들 (What it is not)
이는 SKILL.md 파일 하나와 필요할 때 로드되는 참조 규칙의 조합일 뿐입니다. 서버, 백그라운드 서비스, 데이터베이스, 원격 API는 없습니다.
또한 샌드박스(sandbox)나 테스트 러너(test runner)도 아닙니다. 이 시스템이 무엇을 할 수 있는지는 호스트가 에이전트에게 부여하는 도구와 권한에 달려 있습니다. 과장하여 설명하기보다는 처음부터 명확히 하는 것이 더 좋다고 생각합니다.
사용해 보기 (Try it)
아직 어떤 마켓플레이스에도 없습니다. 저장소에서 설치해야 합니다. Cursor, Codex 및 Grok Build 환경에서 테스트되었습니다.
Cursor: 저장소를 ~/.cursor/plugins/local/task-lifecycle에 배치하고, Developer: Reload Window를 실행한 다음, Customize 항목에서 task-lifecycle 스킬이 표시되는지 확인합니다.
Codex:
codex plugin marketplace add devcodex-labs/task-lifecycle
codex plugin add task-lifecycle@devcodex-task-lifecycle
Grok Build:
grok plugin install devcodex-labs/task-lifecycle --trust
성공적인 설치가 호스트에 로드되었음을 보장하지 않으므로, 새 세션을 시작하고 다음과 같은 내용을 전송해 보세요:
Use Task Lifecycle to plan a bugfix: reproduce, find the root cause, then propose a fix.
먼저 사전 검사(pre-check)가 표시되고, 관리되는 버그 수정 작업에 진입한다는 알림이 나타난 다음, 확인이 필요한 첫 지점에서 멈추는 것을 볼 수 있어야 합니다.
여러분께 질문합니다
코딩 에이전트가 실제로 검증하지 않은 성공을 주장하는 것을 어떻게 막고 계신가요? 규칙 파일(Rules files), 후크(hooks), 프롬프트 내 체크리스트 같은 방법들이 있을까요? 여러분에게 효과적인 방법을 듣고 싶습니다.
저장소, 이슈 및 풀 리퀘스트: https://github.com/devcodex-labs/task-lifecycle
