기획 노트현장 기록2026.08.17읽는 데 5분

AI는 계속 돌렸는데, 왜 결과물은 늘지 않았을까

AI 자동화와 코딩이 계속돼도 결과물이 늘지 않는 이유를 짚고, 실행·검증·결정·다음 행동으로 완료를 관리하는 1인 운영 원칙을 정리합니다.

AI는 계속 돌렸는데, 왜 결과물은 늘지 않았을까

IN SHORT

  • - 자동화 실행, 코드 생성, 글감 수집은 모두 중간 산출물일 수 있습니다.
  • - 완료는 `실행 → 검증 → 공개 또는 보류 결정 → 다음 행동`까지 상태가 바뀐 결과물로 판단해야 합니다.
  • - 도구를 더 늘리기보다, 주간 결과물 1~2개와 보류 사유를 명확히 남기는 운영이 필요합니다.

AI 도구를 여러 개 연결해 두고도 이번 주에 남은 결과물이 없다는 느낌을 받을 때가 있습니다. 자동화는 제시간에 실행되고, 코드도 만들어지고, 글감도 도착하는데 막상 "그래서 무엇이 끝났나"라는 질문에는 답을 하기 어렵습니다.

실행 기록을 완료로 착각

최근에 claude에 이어 gpt 구독까지 한 뒤 예약된 작업은 계속 돌고 있었고, 기록과 알림도 쌓였습니다. 하지만 눈에 보이는 결과물이 늘지 않았습니다. 곰곰히 생각해봤습니다. 문제는 도구의 성능이 아니라, 실행만 하고 Task를 완결하지 않은데 있는 것 같았습니다.

작업이 많다고 결과물도 많을까

자동화가 실행됐다는 것은 입력을 처리했다는 뜻입니다. 글감이 도착했다는 것은 후보를 받았다는 뜻이고, 코드가 생성됐다는 것은 구현 초안이 생겼다는 뜻입니다. 어느 것도 그 자체로 발행, 배포, 검증 완료를 의미하지는 않습니다.

말은 쉽지만 인지하고 대응하지 않으면 목록은 늘어나는데 프로젝트는 앞으로 가지 않습니다. "글감 받기", "초안 만들기", "테스트 통과" 같은 작업을 끝냈다는 표시만 남고, 독자에게 공개할 글 한 편이나 실제로 쓸 수 있는 기능 하나가 끝났는지는 확인하지 않게 됩니다. 아무리 훌륭한 Agent를 써서 칸반보드를 운영한다고 해도 해결될 수 없는 문제입니다.

그래서 저는 일을 네 단계로 나눠 보기로 했습니다. 실행, 검증, 공개 또는 보류 결정, 다음 행동입니다. 이 네 칸 중 어디까지 갔는지를 쓰지 않으면, 완료라고 부르지 않는 방식입니다.

실행은 AI가 가장 잘해요

AI는 실행력을 높이는데 도와줍니다. 코드를 초안으로 만들고, 자료를 모으고, 일정한 형식의 알림을 보내고, 빠진 항목을 찾아낼 수 있습니다. 블로그 운영에서도 이런 도움을 받고 있는데요. 콘텐츠를 관리하는 구조를 만들고, 검색 로봇이 읽을 수 있는 형태로 공개 페이지를 바꾸고, 발행 뒤 확인할 항목을 정리했습니다.

다만 실행이 빨라질수록 다음 단계는 더 의식적으로 관리해야 합니다. 한 번 세팅을 해놓으면 정해진 시간에 기록이 계속 쌓이기 때문입니다.

자동화 Task가 완료되어도 검색에 노출되는지, 독자가 이해할 수 있는지, 오늘 공개할 이유가 있는지 같은 질문은 자동 실행에 모두 맡겨둘 수 없습니다. 실행은 많아졌어도 검증이나 판단은 꼭 사람이 해야한다고 아직 생각합니다.

AI 기능보다 퀄리티에 집중

어떤 AI를 쓸지부터 정하면 도구 중심으로 일이 흘러갑니다. 저는 반대로 결과물부터 어떤 결과를 기대하는지 고민하는 편이 낫다고 봅니다. 예를 들어 "이번 주 블로그 글 한 편"이라고 쓰는 대신, 제목만 있는 글감은 실행 단계, 초안은 검증 대기, 공개 또는 보류가 결정되어야 완료라는 기준을 붙이는 겁니다.

그 다음에 역할을 나눕니다. Claude 같은 코딩 도구는 구현과 테스트에 집중시킵니다. Hermes 같은 운영 도구는 우선순위, 알림, 자료 정리, 중복 점검, 결과 확인을 맡깁니다. 마지막으로 사람은 공개 여부와 범위 변경, 다음 주에 계속할 일을 결정합니다.

중요한 것은 AI별로 역할를 분리하는 그 자체가 아닙니다. 어느 도구가 무엇을 했든 결과물 상태가 배포할 정도로 바뀌지 않았다면, 그 작업은 아직 다음 행동이 필요한 상태라는 점입니다. 역할을 나누는 이유는 전문성을 강화하고 다음 step이 무엇인지 명확히 알 수 있게 하기 위해서입니다.

보류도 결과물로 남기자

여기서 자주 빠지는 것이 보류 결정입니다. 기능을 더 만들지 않기로 했거나, 글의 근거가 부족해 발행하지 않기로 했다면 그것이 버릴 아이템이 아니라 판단의 결과입니다. 보류 이유와 다시 꺼내볼 조건을 남겨두면, 다음 주에 같은 고민을 처음부터 반복하지 않아도 됩니다.

반대로 보류 기록이 없으면, 자동화는 같은 글감을 다시 보내고 개발 목록은 같은 기능을 다시 끌어올립니다. 일을 멈춘 이유까지 기록해야 반복 작업을 줄일 수 있습니다. 완료 목록에는 공개한 것만이 아니라, 근거를 확인해 중단하거나 미룬 결정도 남겨야 합니다.

매주 1~2개만 끝내자

1인 운영자는 모든 자동화를 따라가려 하면 결국 관리 자체가 일이 됩니다. 편하려고 자동화를 했는데 그 자체로 일이 된 것이죠. 그래서 주간 결과물은 하나 또는 두 개면 충분합니다. "앱 기능 세 개 개선"보다 "사용자가 실제로 쓸 수 있는 기능 하나를 검증하고 다음 결정을 남긴다"가 더 낫습니다. "글감 다섯 개"보다 "근거와 체크리스트를 갖춘 글 한 편을 공개 또는 보류한다"가 낫습니다.

이 기준을 정하면 자동화도 줄일 수 있습니다. 결과물에 연결되지 않는 알림은 끄거나 묶고, 도움이 되는 자동화만 남길 수 있기 때문입니다. 자동화의 목표는 메시지를 많이 보내는 일이 아니라, 다음 판단을 덜 놓치게 하는 일이어야 합니다.

이번 주에 써볼 완료 기준

첫째, 이번 주 결과물은 한두 개만 적습니다.
둘째, 각 결과물에 실행·검증·결정·다음 행동을 한 줄씩 붙입니다.
셋째, 실행만 끝난 항목을 완료 목록에서 빼고 검증 대기로 옮깁니다.
넷째, 주말에는 무엇을 더 했는지보다 무엇을 공개했거나 보류로 결정했는지를 확인합니다.

AI를 잘 쓴다는 것은 더 많은 도구를 사용하는 일이 아닐 수 있습니다. 도구가 만든 중간 산출물을 끝까지 판단 가능한 결과물로 데려가는 운영 방식을 갖추는 일 아닐까요? 자동화가 많아도 결과물이 늘지 않는다면, 다른 도구를 찾기 전에 Task 완료의 정의부터 다시 적어볼 때입니다.


FAQ

Q. 자동화를 많이 쓰면 결과물이 빨리 늘어나지 않나요?
A. 실행 속도는 빨라집니다. 다만 검증·공개·보류 결정이 비어 있으면 중간 산출물만 더 빠르게 쌓일 수 있습니다.

Q. 코드 테스트를 통과하면 완료 아닌가요?
A. 기술적 검증은 통과한 것입니다. 사용자에게 쓸 가치가 있는지, 배포할지 보류할지까지 결정되어야 결과물의 상태가 바뀝니다.

Q. 보류한 일을 기록할 필요가 있나요?
A. 필요합니다. 보류 이유와 재검토 조건이 없으면 같은 아이디어와 작업이 반복해서 목록에 올라옵니다.

Q. Claude와 Hermes를 꼭 함께 써야 하나요?
A. 아닙니다. 핵심은 도구의 조합이 아니라 구현·운영·최종 판단이 어디에서 이뤄지는지 명확히 하는 것입니다.

Q. 주간 결과물은 몇 개가 적당한가요?
A. 1인 운영이라면 하나 또는 두 개가 현실적입니다. 더 많은 항목보다 공개·보류 판단까지 끝낸 결과물이 중요합니다.

공개 전 확인

  • 이번 주 완료 결과물이 1~2개로 좁혀졌는가?
  • 각 결과물에 실행 / 검증 / 결정 / 다음 행동 상태가 있는가?
  • 실행만 완료된 항목을 완료 목록에서 제외했는가?
  • 공개하지 않는다면 보류 이유와 재검토 조건을 남겼는가?
  • 자동화가 실제 다음 판단을 줄이는 데 연결되는가?