AI가 글을 써도, 망가진 작업을 먼저 발견하는 사람은 여전히 필요하다

AI에게 초안을 맡기면 작성 속도는 빨라진다. 하지만 초안이 빨리 생겼다는 이유만으로 일이 끝난 것은 아니다. 누가 그 결과를 받아야 하는지, 발행해도 되는지, 실패한 작업이 어디에서 멈췄는지는 여전히 누군가 확인해야 한다. AI를 쓰느냐 마느냐보다 더 중요한 것은, 결과를 계속 신경 쓰는 구조가 있느냐다.

나는 이 문제를 “AI가 care할 수 있는가”로 묻지 않기로 했다. 더 실용적인 질문은 이것이다. 내 시스템은 care하지 않아도 되는 상태를 허용하고 있는가? 작업이 유실되어도 모르고, 담당자가 없어도 모르고, 실패가 성공처럼 보이는데도 다음 단계로 넘어간다면 모델이 아무리 좋아져도 운영은 무너진다.

속도를 자동화하면 책임도 자동화됐다고 착각한다

AI 도입 초기에 가장 쉽게 측정하는 값은 생성 속도다. 몇 분 만에 코드가 생겼는지, 몇 개의 초안이 만들어졌는지, 도구를 몇 번 호출했는지를 센다. 그러나 실제 병목은 그 다음에 있다. 결과가 올바른 대상에게 전달됐는가? 사람이 판단해야 할 지점이 표시됐는가? 실패한 실행이 다시 시도할 수 있는 상태로 남았는가?

이 질문을 건너뛰면 시스템은 “생성”만 자동화한다. 생성된 파일은 늘어나지만 결정은 늘지 않는다. 더 나쁜 경우에는 AI가 만든 결과라는 이유로 사람이 검토를 덜 한다. 그 순간 AI는 생산성 도구가 아니라 책임을 흐리는 장치가 된다.

외부 정보(하베스터 수집): 희소해지는 것은 결과물이 아니라 신뢰다

외부 정보(하베스터 수집): Seth Godin의 The Icarus Deception을 정리한 하베스터 자료는 고품질 작업과 역량 자체가 더 이상 희소하지 않다고 설명한다. 대신 희소해지는 것은 신뢰, 연결, 놀라움이다. Linchpin 자료에서도 깊은 지식만으로는 충분하지 않고, 현명한 판단과 관대한 기여를 결합해야 대체하기 어려운 사람이 된다고 정리한다.

이 관점을 AI 파이프라인에 옮기면 결론은 단순하다. AI가 평균적인 결과물을 빠르게 만드는 동안 사람의 역할은 사라지는 것이 아니라 이동한다. 사람은 매번 문장을 직접 쓰는 대신, 무엇을 중요하게 볼지, 누구에게 넘길지, 어디서 멈출지를 책임져야 한다. 이것은 “AI를 믿지 말자”는 주장이 아니다. AI를 실제 시스템에 넣을수록 신뢰가 생기는 지점을 더 구체적으로 설계해야 한다는 주장이다.

상호작용(에이전트-드루 대화·작업): 내 시스템에서 CARE는 네 개의 연결이었다

상호작용(에이전트-드루 대화·작업): 이 원칙은 실제 콘텐츠 파이프라인을 고치면서 정리됐다. 한때 수동으로 넘긴 주제가 DB에는 남아 있는데 Content Manager에게 전달됐다는 증거가 없었다. 작업은 in_progress에 머물렀고, 담당자와 다음 소비자가 없었다. 화면이 있어도 “접수됐는가, 읽었는가, 지금 누가 처리하는가”에 답할 수 없었다.

이때 내가 붙잡은 기준이 CARE다. 기존 코드에 있던 공식 약어가 아니라, AI를 넣은 시스템에서 사람이 끝까지 신경 써야 할 연결을 기억하기 위한 작업용 모델이다.

  • C — Context. 작업의 목표와 출처가 보이는가? 왜 이 결과를 만드는지 입력에서 사라지지 않아야 한다.
  • A — Accountability. task ID, 담당자, 다음 소비자가 정해져 있는가? “누군가 보겠지”는 담당자가 아니다.
  • R — Reviewability. 승인·보류·거절 결정과 이유가 남는가? 결정이 기록되지 않으면 다음 사람은 같은 판단을 다시 한다.
  • E — Exceptions. stale, orphan, failed가 정상 상태와 구별되는가? 멈춘 작업을 숨기는 시스템은 자동화된 시스템이 아니라 자동화된 유실이다.
AI 콘텐츠 파이프라인에서 접수부터 검토, 발행, 예외 처리를 연결한 CARE 루프 아키텍처 다이어그램
AI는 실행 속도를 담당하고, 접수·책임·검토·예외 처리를 연결하는 것은 시스템 설계의 몫이다.

코드에서는 ‘잘 만든 AI’보다 ‘끊기지 않는 상태’가 먼저였다

현재 콘텐츠 오케스트레이터의 흐름은 세 모드로 나뉜다. schedule이 todo 작업에 발행 슬롯을 배정하고, write가 작성 작업을 실행해 publish_ready로 넘기며, publish가 준비된 결과를 WordPress로 보낸다. 작성기는 별도 세션에서 실행되고, 발행은 작성 에이전트가 아니라 오케스트레이터가 직접 처리한다. 생성과 외부 시스템 변경을 분리한 것이다.

schedule: todo → writing
write:    writing → publish_ready
publish:  publish_ready → completed

그 구조에서 care는 추상적인 태도가 아니라 숫자와 실패 경로로 들어간다. content_orchestrator.py에는 한 번에 처리할 작성 배치를 제한하는 WRITE_BATCH_CAP = 10, 작성 중·발행 대기 작업 수를 제한하는 WIP_LIMIT = 5, 작성기 타임아웃 WRITER_TIMEOUT = 900이 있다. 오래된 lock은 LOCK_EXPIRY = 3600 기준으로 정리한다. 많이 시키는 것이 능사가 아니라, 멈췄을 때 다음 실행이 회복할 여지를 남기는 쪽을 택했다.

작성 프로세스가 끝나지 않아도 초안 파일이 남아 있으면 최근 파일을 스캔해 slug를 복구하는 경로도 있다. 반대로 외부 발행은 작성 에이전트에게 맡기지 않는다. 에이전트가 “발행까지 했다”고 말하는 것과 WordPress에 실제 반영된 것은 다른 사건이기 때문이다. care는 좋은 의도를 믿는 일이 아니라, 사건을 분리하고 확인 가능한 상태로 만드는 일이다.

사람이 care한다는 말은 상태와 이유를 남긴다는 뜻이다

그래서 별도로 만든 로컬 Content Operations 서버는 화려한 대시보드보다 먼저 수신과 상태 전이를 고정한다. 서버는 127.0.0.1:8651에서만 실행된다. /api/content/intake에 주제를 보내면 task ID, received 상태, receipt ID, 다음 소비자인 Content Manager를 함께 반환한다. “전달했다”는 말이 아니라 전달 영수증을 남기는 방식이다.

상태 변경도 그냥 덮어쓰지 않는다. content_ops_events 테이블에 이전 상태, 새 상태, actor, reason을 기록한다. 보류나 거절에는 이유가 필수다. 오래된 수동 작업은 결과 문자열에 stale이 들어 있거나 24시간 넘게 완료되지 않았으면 화면에서 stale로 표면화한다. 실패와 고아 작업을 “기타”로 뭉개지 않는 것이 운영자의 관심이다.

python3 -m pytest -q tests/cron/test_content_ops_server.py

# 검증하는 것
# - 오래된 수동 작업 → stale
# - intake → task ID + receipt + event
# - reject / hold → reason 필수
# - overview → 활동 상태와 상태별 count

이 테스트는 AI의 문장 품질을 평가하지 않는다. 대신 작업이 유실되지 않는지, 사람이 결정했다는 사실과 이유가 남는지를 평가한다. AI를 더 좋은 모델로 교체하는 것보다 먼저 이런 불변조건을 테스트하는 편이 실제 장애를 줄인다.

당신의 프로젝트에 CARE를 넣는 가장 작은 순서

새 에이전트를 붙이기 전에 최근 실패한 작업 하나를 골라 다음 질문에 답해보라.

  1. 입력에 목표와 출처가 남아 있는가?
  2. task ID와 현재 담당자, 다음 소비자가 있는가?
  3. 승인·보류·거절의 이유를 나중에 읽을 수 있는가?
  4. stale·orphan·failed를 정상 완료와 구별할 수 있는가?
  5. 에이전트의 실행과 외부 시스템의 실제 반영을 따로 검증하는가?

다섯 질문 중 하나라도 “아직 모른다”라면 모델을 바꾸기 전에 그 연결부터 만든다. 입력에 source를 추가하고, 상태 전이에 owner를 붙이고, 결정 endpoint에 reason을 강제하고, 오래된 작업을 별도 상태로 표시하면 된다. 이것은 거대한 플랫폼 프로젝트가 아니다. 오히려 작은 상태 계약과 실패 테스트로 시작할 수 있는 운영 문제다.

AI를 쓰든 말든, 결과를 신경 쓰는 쪽이 시스템의 주인이다

AI를 사용하지 않는다고 자동으로 책임감이 생기지도 않는다. 반대로 AI를 쓴다고 책임을 포기해야 하는 것도 아니다. 차이는 도구가 아니라 태도를 시스템에 새겨 넣었는가에 있다. 목표를 보존하고, 담당자를 연결하고, 판단의 이유를 남기고, 예외를 숨기지 않는 것. 내가 말하는 CARE는 결국 이 네 가지다.

오늘은 프로젝트의 작업 하나를 task ID로 따라가 보라. intake에서 시작해 실제 반영까지, 중간에 “누가 다음에 보는가”가 끊기는 지점을 표시하라. 그 한 곳에 owner·reason·stale 검사를 추가하는 것이 새 AI 도구를 하나 더 구독하는 것보다 먼저 할 일이다. 발견한 끊김을 코드나 문서로 남겨두면, AI가 더 빨라져도 당신의 시스템은 더 무책임해지지 않는다.

근거 출처

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

Seth Godin, The Icarus Deception(2012)과 Linchpin(2010)의 핵심 개념은 로컬 하베스터 보고서 reports/seth-godin-cmo-20260816/report.md에 정리된 내용을 사용했다. “고품질과 역량은 더 이상 희소하지 않고 신뢰·연결·놀라움이 희소하다”, “깊은 지식은 판단과 기여가 결합될 때 의미가 있다”는 외부 자료의 주장을 본문의 AI 운영 관점으로 해석했다. 책의 주장을 내 작업 경험이나 성능 통계처럼 서술하지 않았다.

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

콘텐츠 파이프라인의 세 모드와 작성기 격리·타임아웃·배치/WIP 제한은 P4-cortex/scripts/content_orchestrator.py의 현재 코드에서 확인했다. 수동 전달 유실 문제, 상태 계약, receipt·owner·next consumer·stale·orphan 원칙은 P6-prefrontal/plans/agent-workspace-action-mvp-20260820.md의 작업 결정에서 가져왔다. 로컬 운영 서버의 상태·이벤트·결정 이유와 테스트 근거는 P4-cortex/scripts/content_ops_server.py와 tests/cron/test_content_ops_server.py를 기준으로 작성했다. CARE라는 네 글자 모델과 적용 순서는 이 상호작용을 재구성한 개인적인 통찰이며 외부 통계가 아니다.