AI가 코드를 잘 쓰는 것보다, 누가 실행할지를 정하는 일이 먼저였다

AI가 코드를 잘 쓰는 것보다, 누가 실행할지를 정하는 일이 먼저였다

에이전트에게 “이 파일 고쳐줘”라고 말하면 금방 결과가 나온다. 그래서 작은 구현이나 상태 정리는 직접 시키는 편이 더 빠르게 느껴진다. 하지만 ~/.drewgent처럼 규칙, 메모리, 작업 원장, 자동화가 한곳에 모인 워크스페이스에서는 그 빠름이 위험해진다. 코드 한 줄보다 더 비싼 것은 잘못 바뀐 상태를 찾고 되돌리는 시간이다.

내가 이 작업 환경에서 세운 결론은 단순하다. 구현과 task-state cleanup은 authorized worker에게 맡기고, 나는 목표·범위·완료 증거를 결정한다. AI를 덜 믿자는 이야기가 아니다. AI가 실수해도 영향 범위를 좁히는 실행 구조를 먼저 만들자는 이야기다.

“작은 정리니까 직접 하지”가 가장 비싼 판단이 되는 순간

구현 작업은 파일을 바꾼다. task-state cleanup은 작업 원장의 상태, claim 정보, 재시도 기록처럼 다음 실행이 참고하는 값을 바꿀 수 있다. 둘 다 눈앞의 diff만 보면 작아 보이지만, 실제 영향은 다음 워커와 크론, 검증 단계까지 이어진다.

문제는 에이전트가 코드를 못 써서 생기지 않는다. 오히려 너무 자연스럽게 써서 생긴다. 현재 세션의 컨텍스트를 기준으로 “이 정도면 괜찮다”고 판단하고, 다른 작업이 기대하는 경계나 상태 전이를 놓칠 수 있다. 같은 폴더에서 여러 작업이 진행되면 누가 무엇을 바꿨는지도 흐려진다.

여기서 필요한 것은 더 긴 프롬프트가 아니다. 작업을 맡길 수 있는 주체와, 그 주체가 지켜야 할 계약이다.

상호작용에서 얻은 근거: 작업의 종류가 위임 방식을 결정했다

이 원칙은 이론으로 만든 것이 아니다. 에이전트-드루 작업을 반복하면서 생긴 운영 선호다. ~/.drewgent 안에서 구현하거나 task-state를 정리할 때는 직접 처리하지 않고, 권한이 확인된 워커에게 넘긴다. 반대로 글의 초안처럼 요청된 콘텐츠 산출물을 만드는 일은 별도의 작성 작업으로 수행한다. “파일을 쓴다”는 사실 하나만으로 모든 일을 같은 방식으로 처리하지 않고, 어떤 종류의 상태를 건드리는지부터 나눈다.

로컬 위임 구조를 읽어보면 이 구분이 더 선명해진다. 빠른 읽기·분석은 같은 세션의 작업으로 처리할 수 있지만, 구현·리팩터링처럼 변경 위험이 있는 작업은 격리된 워커 실행을 사용한다. 여러 독립 작업은 병렬 워커로 나누고, 각 작업은 자신의 공간에서 끝낸 뒤 결과를 돌려준다.

• 읽기·분석: 현재 상태를 파악하고 선택지를 좁힌다.
• 구현·리팩터링: 격리된 authorized worker가 파일을 변경한다.
• task-state cleanup: 작업 원장의 계약과 상태 전이를 아는 worker가 처리한다.
• 검증: 별도의 확인 단계에서 파일·테스트·완료 증거를 대조한다.

이 구조에서 내가 맡는 역할은 “직접 빨리 고치기”가 아니다. 무엇을 바꿔도 되는지, 무엇을 바꾸면 안 되는지, 완료를 어떤 증거로 판단할지를 먼저 정하는 것이다. 워커는 실행을 맡고, 나는 경계를 맡는다.

위임하면 실제 워크플로가 어떻게 달라지는가

1. 작업 공간이 분리되어 복구 비용이 줄어든다

워커가 격리된 공간에서 구현하면, 아직 검증하지 않은 변경이 현재 작업 트리에 바로 섞이지 않는다. 결과가 마음에 들지 않으면 원인을 확인하고 버리거나 다시 맡길 수 있다. 중요한 것은 워커가 항상 성공한다는 보장이 아니라, 실패가 원래 작업까지 오염시키지 않는다는 보장이다.

2. “끝났다”가 아니라 완료 조건으로 대화하게 된다

직접 처리할 때는 파일이 바뀌면 끝났다고 착각하기 쉽다. 위임할 때는 작업을 맡기기 전에 수용 기준을 적는다. 예를 들어 “상태가 정리됐다”가 아니라 “대상 상태만 바뀌고, 다른 보드의 작업은 건드리지 않으며, 변경 파일과 검증 결과를 보고한다”처럼 적는다. 그러면 워커의 출력이 감상이 아니라 확인 가능한 영수증이 된다.

3. 역할을 바꿔도 판단 기준은 남는다

특정 모델이나 특정 세션의 능력에만 기대면 실행 주체가 바뀔 때마다 품질이 흔들린다. 반면 목표, 비범위, 수용 기준, 검증 명령을 작업 계약으로 남기면 워커가 바뀌어도 같은 질문을 던질 수 있다. “누가 했는가”보다 “무엇을 근거로 완료했는가”가 중요해진다.

내가 쓰는 최소 위임 계약

위임을 거창한 오케스트레이션으로 만들 필요는 없다. 나는 다음 다섯 문장을 먼저 채운다. 이 정도만 있어도 “알아서 해줘”와 “이 경계 안에서 끝내줘”가 달라진다.

목표: 무엇을 바꿀 것인가
범위: 어떤 파일·상태만 건드릴 것인가
비범위: 무엇은 절대 바꾸지 않을 것인가
완료 조건: 무엇이 참이면 끝난 것으로 볼 것인가
증거: 변경 파일·검증 명령·결과를 어떻게 남길 것인가

이 계약은 워커를 통제하기 위한 문서라기보다, 내 판단을 고정하는 장치다. 작업 중에 “이것도 같이 고치면 좋겠는데?”라는 유혹이 생겨도 비범위에 없으면 다음 작업으로 미룬다. 작은 범위로 끝내고, 확인한 다음 확장한다.

완료 후에는 최소한 세 가지를 대조한다. 파일시스템에 실제 변경이 있는가, 검증 결과가 수용 기준을 만족하는가, 워커가 보고한 내용과 실제 상태가 같은가. 워커의 문장보다 디스크와 실행 결과를 우선한다.

모든 일을 워커에게 맡기면 안 되는 이유

위임은 책임 회피가 아니다. 그래서 모든 일을 무조건 워커에게 던지는 것도 답이 아니다. 읽기 전용 분석, 짧은 초안, 사용자가 명확히 요청한 문서 산출물은 현재 세션에서 빠르게 처리하는 편이 낫다. 반대로 코드·작업 원장·배포 상태처럼 다른 시스템이 이어서 읽는 값을 바꾸는 일은 격리된 실행이 기본값이어야 한다.

판단 기준은 “AI가 할 수 있나?”가 아니다. 실패했을 때 다른 작업의 상태까지 흔들리는가?다. 흔들릴 수 있다면 authorized worker로 보내고, 수용 기준과 검증 증거를 붙인다. 흔들리지 않는 읽기 작업이라면 직접 확인한다. 이 기준은 도구 이름보다 오래 간다.

AI 워크플로의 다음 단계는 더 똑똑한 프롬프트가 아니다

에이전트를 실제 운영에 넣으면 언젠가 같은 장면을 만난다. “이건 금방 끝나니까 내가 직접 하지.” 그 순간은 생산성이 아니라 경계가 무너지는 순간일 수 있다. 특히 설정, 메모리, 자동화, 작업 상태가 함께 있는 워크스페이스에서는 작은 변경도 다음 실행의 전제가 된다.

내가 얻은 해법은 작업을 더 세게 지시하는 것이 아니라, 실행 주체를 분리하는 것이었다. 구현과 상태 정리는 authorized worker에게 맡기고, 목표와 비범위와 완료 증거는 내가 정한다. 워커가 작업하는 동안 나는 결과를 기다리는 사람이 아니라, 결과를 판정할 계약을 준비한 사람이 된다.

AI 에이전트를 워크플로에 도입하고 있다면 오늘 작업 하나만 골라보자. 코드나 상태를 직접 바꾸기 전에 목표·범위·비범위·완료 조건·증거를 적고, 권한이 확인된 워커에게 넘겨라. 그다음 실제 변경 파일과 검증 결과를 대조해보자. 이 작은 분리가, 에이전트를 “빠른 조수”에서 “운영 가능한 팀원”으로 바꾸는 첫 단계다.

근거 출처

외부 정보(하베스터 수집)

이번 글에는 외부 기사·트렌드·통계 자료를 사용하지 않았다. 제공된 하베스터 참고자료가 없었으므로 최신 수치나 외부 인용을 덧붙이지 않았다.

상호작용(에이전트-드루 대화·작업)

• 에이전트-드루 작업에서 정리된 사용자 선호: ~/.drewgent 안의 구현과 task-state cleanup은 authorized worker에게 맡긴다.
• 로컬 위임 문서의 실행 구분: 읽기·분석은 빠른 같은 세션 작업으로, 구현·리팩터링은 격리된 worker 실행으로, 독립적인 여러 작업은 병렬 worker로 처리한다.
• 로컬 kanban worker 계약: 작업은 목표와 범위에 따라 수행하고, heartbeat·완료 결과·변경 파일·검증 증거를 남긴다.
• 이 글의 주장은 외부 통계가 아니라 에이전트-드루의 대화, 작업 규칙, 위임 구조를 읽고 정리한 경험이다.