지금 이 순간, 당신의 AI 워크플로우가 실행되고 있다.
하지만 당신은それが 3일 전에 멈춘 사실을 모르고 있다.
여전히 작동 중이다. API 크레딧을 태우고 있다. 아무도 읽지 않는 결과물을 계속 내보내고 있다. 주말을 바쳐 만든 에이전트가 쓰레기를 생성하고 있다. 개당 $0.40의 비용으로. 그리고 화요일에 고객이 스크린샷을 찍어 보내기 전까지는 알 방법이 없다.
이건 불운이 아니다. 이건 기본값이다.
저장해두라. 두 번 읽게 될 테니까.
30일의 무덤
매주 수백 명의 창업자가 AI 워크플로우를 만들어 트위터에 올린다.
데모는 깔끔하다. 스레드는 좋아요를 받는다. 댓글에는 "이게 미래다"라고 달린다.
30일 후, 그 워크플로우는 죽어 있다.
삭제된 게 아니다. 교체된 것도 아니다. 죽었으면서도 여전히 돌아가고 있다. 카드에서 비용이 빠져나간다. 아무 쓸모도 없는 결과물을 생산한다. 창업자는 이미 다른 일로 넘어갔다. 에이전트는 그 사실을 모른다.
오늘날 구축되는 AI 워크플로우의 90%는 첫 한 달을 버티지 못한다. 모델이 나빠서가 아니다. 아이디어가 틀려서도 아니다. 빌더가 반드시 실패하게 만드는 세 가지 실수를 저지르기 때문이다. 그리고 그 실수가 무엇인지 출시 전에 알려주는 사람은 아무도 없다.
이 글이 바로 그 글이다.
왜 죽는가
워크플로우가 죽는 과정을 해부해보면 항상 같은 순서다.
1일: 만든다. 데모에서는 완벽하게 작동한다. 무언가를 깨우친 기분이 든다.
3일: 여전히 작동한다. 예전처럼 꼼꼼히 확인하지 않게 된다.
9일: 무언가 변한다. API 응답 형식이 살짝 바뀐다. 참고하던 소스가 로그인 장벽 뒤로 사라진다. 모델이 첫날과 다르게 에지 케이스를 해석한다. 결과물이 조용히 나빠진다. 아무도 눈치채지 못한다.
14일: 워크플로우는 이제 기술적으로는 응답이지만 실질적으로는 쓸모없는 결과물을 생산한다. 여전히 실행 중이다. 당신은 여전히 비용을 지불하고 있다.
23일: 고객이나 동료가 뭔가 이상하다고 말한다. 확인해보니 12일치의 고장 난 결과물이 발견된다. 당신은 제대로 처리되고 있다고 믿고 있었다.
30일: 워크플로우를 죽인다. AI는 아직 준비되지 않았다고 스스로에게 말한다. 그리고 다음으로 넘어간다.
모델이 당신을 실망시킨 게 아니다. 빌드가 모델을 실패하게 만든 것이다.
상위 10%를 나머지와 가르는 3가지 규칙
워크플로우가 30일, 90일, 1년을 버티는 창업자들은 더 똑똑하지 않다. 더 나은 프롬프트를 가진 것도 아니다. 다른 사람들이 무시하는 세 가지 규칙을 가지고 구축할 뿐이다.
규칙 1 — 직무 기술서 없음, 에이전트 없음
대부분의 사람들은 '분위기'만 가지고 에이전트를 만든다.
"콘텐츠 작업을 도와줘." "경쟁사를 모니터링해줘." "고객 이메일을 처리해줘."
그건 직무 기술서가 아니다. 그건 소원이다. 그리고 소원은 주말을 버티지 못한다.
직무 기술서에는 다섯 가지 요소가 있다:
무엇을 감시하는가. 구체적인 트리거나 일정. "매주 월요일 오전 7시" 또는 "새로운 GitHub 이슈가 '버그' 레이블로 열릴 때마다" 또는 "연락처 목록에 없는 도메인에서 이메일이 도착할 때마다." "가끔"이나 "관련 있을 때"가 아니다.
무엇을 읽는가. 정확한 출처. "인터넷을 확인해줘"가 아니다. "이 세 개의 RSS 피드, 이 Airtable 베이스, 그리고 이 Slack 채널의 지난 7일치를 가져와." 구체적이다. 한정적이다. 모호함이 없다.
무엇을 생산하는가. 정확한 출력 형식. "요약"이 아니다. "세 가지 섹션으로 구성된 브리핑: 한 문장의 핵심 발견, 각각 하나의 출처가 있는 세 개의 근거 불릿, 하나의 권장 조치. 300단어 미만. 이 Google Docs에 작성."
무엇을 하지 않는가. 가드레일. "인간 승인 없이 외부 이메일을 절대 보내지 마." "프로덕션 데이터베이스를 절대 수정하지 마." "직접 게시하지 마. 항상 초안으로 저장해." 당신이 당연하다고 생각하는 것들이 당신을 불태울 것이다.
작동했는지 어떻게 아는가. 성공 조건. "브리핑이 비어 있으면, 관련 업데이트를 찾지 못했다는 Slack 메시지를 보내줘. 빈 브리핑은 보내지 마."
분위기는 주말을 버티지 못한다. 직무 기술서는 버틴다.
지금부터 구축하는 모든 워크플로우는 직무 기술서로 시작한다. 프롬프트가 아니다. 직무 기술서다.
규칙 2 — 침묵하는 실패만이 당신을 죽인다
시끄러운 실패는 괜찮다. 시끄러운 실패는 오류를 보낸다. 워크플로우를 중단시킨다. 당신을 깨운다. 고치면 된다.
침묵하는 실패가 비즈니스를 죽인다.
침묵하는 실패는 성공처럼 보인다. 워크플로우는 실행된다. 결과물이 도착한다. 형식은 정확하다. 내용이 틀렸다 — 조금씩, 그러다 더 많이, 그리고 완전히 — 그리고 제대로 보이기 때문에 아무도 확인하지 않는다.
침묵하는 실패가 실제로 일어나는 방식은 이렇다:
당신의 콘텐츠 에이전트가 30개의 포스트를 작성한다. 내부 평가 기준에서 80점 이상인 것은 자동 예약하도록 설정했다. 그 기준은 첫 20개의 포스트로 보정되었다. 15일째 되는 날, 모델이 당신의 기준을 다르게 해석하기 시작한다. 82점을 받은 포스트가 실제 당신의 기준으로는 평범하다. 그래도 발행된다. 참여율이 떨어진다. 알고리즘 탓으로 돌린다.
당신의 리서치 에이전트가 주간 브리핑을 보낸다. 11일째, 참조하던 소스 중 하나가 URL 구조를 바꾼다. 에이전트는 조용히 가져오기에 실패한다. 오래된 캐시 데이터로 그 빈자리를 채우고 그 사실을 알리지 않는다. 당신은 오래된 정보에 기반한 브리핑을 읽고 결정을 내린다.
당신의 받은편지함 트리아지 에이전트가 답장을 작성한다. 8일째, 특정 유형의 이메일을 저순위로 분류하기 시작한다. 발신자 이름이 훈련 데이터의 패턴과 일치하기 때문이다. 당신은 한 번도 읽지 않은 뉴스레터와 성이 같은 신규 고객의 중요한 이메일 세 통을 놓친다.
모든 경우에서: 워크플로우는 실행되었다. 오류는 발생하지 않았다. 당신은 손해를 봤다.
해결책은 필수 출력 검증이다. 모든 에이전트에는 세 가지가 필요하다:
카나리 출력. 모든 출력에서 확인하기 쉽고 조작하기 어려운 하나의 필드. 에이전트가 마지막으로 읽은 소스의 타임스탬프. 처리한 항목 수. 신뢰도 점수. 2초 안에 훑어보고 에이전트가 실제로 일을 했는지 알 수 있는 무언가.
침묵 실패 알림. 에이전트가 아무것도 생산하지 않거나 임계값 이하의 결과물을 생산하면, 빈 출력을 보내지 않는다. 대신 알림을 보낸다. "이번 주기에서는 결과를 찾지 못했습니다 — 확인한 내용과 아무것도 찾지 못했을 수 있는 이유는 다음과 같습니다." 빈 결과보다는 '없음'이 항상 더 유용하다.
주간 스팟 체크. 에이전트당每周 하나의 결과물을 골라 전체를 읽는다. 당신이 직접 작성했을 것과 비교한다. 4분이면 충분하다. 드리프트가 실패가 되기 전에 잡아낸다.
에이전트는 시끄럽게 실패하지 않는다. 조용한 고장에 대비하라.
규칙 3 — 당신의 노트북은 인프라가 아니다
여기서 90%의 빌더가 죽는다.
로컬에서 구축한다. 데모는 작동한다. 트위터 스레드를 올린다. 누군가 프로덕션에서 실행 중이냐고 묻는다. 그렇다고 대답한다. 실제 의미는: 맥북에서 실행 중이고, 맥북은 현재 열려 있고, 책상 위에 있고, 아파트에 있고, 집 WiFi에 연결되어 있으며, 목요일에 공항 가려고 뚜껑을 닫으면 작동이 중단된다는 뜻이다.
당신의 노트북은 인프라가 아니다. 지금 우연히 중요한 무언가를 실행하고 있는 개발 환경일 뿐이다.
노트북에서 호스팅되는 에이전트에 일어나는 일:
macOS가 오전 4시에 업데이트를 푸시한다. 기기가 재시작된다. 에이전트가 멈춘다. 월요일까지 아무도 모른다.
비행기에서 뚜껑을 닫는다. 6시간 동안의 워크플로우가 누락된다. 받은편지함 트리아지 에이전트는 분류하지 못했다. 버그 헌터는 사냥하지 못했다. 스탠드업 에이전트는 아무것도 보내지 않았다.
집 WiFi가 20분 동안 끊긴다. 에이전트가 재시도한다. 실패한다. 넘어간다. 로그를 남기지 않는다. 잡아야 했던 윈도우는 사라진다.
휴가를 간다. 노트북은 집에 남는다. 모든 것이 집에 남는다.
진짜 인프라는 당신이 지켜보지 않을 때도 실행된다. 당신이 자고 있을 때, 비행기에 있을 때, 저녁 식사 중일 때, 주말 동안 연락이 닿지 않을 때도 실행된다. 뚜껑을 열어둘 필요가 없다.
규칙은 간단하다: 워크플로우가 두 번 이상 실행되어야 하고, 한 주기를 놓쳐서는 안 된다면, 노트북에서 실행하지 마라.
실제로 작동하는 세 가지 인프라 옵션:
프로세스 매니저가 있는 VPS. PM2나 Supervisor가 실행되는 월 $12 서버. 에이전트가 관리형 프로세스로 실행된다. 충돌하면 PM2가 자동으로 재시작한다. 서버가 재부팅되면 PM2가 부팅 시 시작한다. 저렴하다. 안정적이다. 화려하지 않다. 작동한다.
관리형 에이전트 플랫폼. 이 목적에 맞게 구축되었다. 재시작, 모니터링, 알림을 처리한다. VPS보다 비싸다. 프로세스가 왜 죽었는지 디버깅하는 주말을 아껴준다. 에이전트가 진정한 가치를 창출하기 시작하면 그만한 가치가 있다.
스케줄러가 있는 서버리스. EventBridge나 Cloud Scheduler로 트리거되는 AWS Lambda나 Google Cloud Functions. 관리할 인프라가 없다. 실행당 비용을 지불한다. 실행되지 않을 때는 0으로 스케일링된다. 연속 실행보다는 고정 일정으로 실행되는 에이전트에 가장 적합하다.
이 중 어느 것도 복잡하지 않다. 모두 15분의 설정 시간이 필요하다. 이 모든 것이 오전 4시의 macOS 업데이트로 에이전트가 죽고 월요일 아침을 망치는 상황에서 당신을 구해줄 것이다.
노트북을 닫아라. 에이전트는 계속 실행되어야 한다.
살아남는 워크플로우
세 가지 규칙이 모두 적용된 90일짜리 워크플로우는 이렇게 생겼다.
직무 기술서: 매주 월요일 오전 7시에, 이 5개의 경쟁사 계정과 이 3개의 업계 뉴스레터에서 지난 7일간의 포스트를 읽는다. 제품 발표, 가격 변경, 또는 500개 이상의 참여를 기록한 콘텐츠를 추출한다. 지난주 브리핑과 비교한다. 새로운 것을 플래그한다. 세 가지 섹션으로 구성된 브리핑을 출력한다: 무엇이 바뀌었는지, 무엇이 주목받고 있는지, 그들이 어떤 격차를 남겼는지. 변경사항이 없으면 알림을 보낸다: "조용한 주입니다 — 확인한 내용은 다음과 같습니다." 이 Notion 페이지에 전달하고 Slack 알림을 보낸다.
카나리 출력: 모든 브리핑에는 다음이 포함된다: "확인한 출처: 8. 처리된 항목: [N]. 가장 최근 항목 타임스탬프: [타임스탬프]." N이 0이거나 타임스탬프가 8일보다 오래되었으면 브리핑 대신 알림을 보낸다.
인프라: 월 $12 VPS에서 실행. PM2가 프로세스를 관리한다. 충돌하면 30초 안에 재시작한다. 주간 로그 검토는 매주 금요일에 3분이면 끝난다.
스팟 체크: 매주 금요일, 하나의 브리핑을 전체 읽는다. 4분이면 충분하다. 6개월 동안 두 번의 드리프트를 잡아냈다.
이 워크플로우는 6개월째 실행 중이다. 두 번의 주기를 놓쳤다 — 두 번 모두 그 이유를 설명하는 알림을 보냈다. 침묵하는 실패는 단 한 번도 없었다.
그것이 살아남는 워크플로우와 9일째 죽는 워크플로우의 차이다.
불편한 진실
대부분의 사람들은 이 글을 읽고, 고개를 끄덕인 다음, 이전과 똑같은 방식으로 다음 에이전트를 만들 것이다.
프롬프트. 데모. 트위터 스레드. 30일간의 침묵. 아무도 공식적으로 죽이지 않은 죽은 워크플로우.
세 가지 규칙은 복잡하지 않다. 직무 기술서는 20분이면 작성할 수 있다. 출력 검증은 필드 하나와 조건문 하나면 된다. 인프라는 15분이면 설정할 수 있다.
격차는 지식이 아니다. 격차는 출시 전에 할 것인지, 워크플로우가 실패한 후에 할 것인지의 차이다.
직무 기술서 없이 구축한 모든 에이전트는 다시 구축하게 될 에이전트다. 출력 검증 없이 구축한 모든 에이전트는 조용히 실패할 에이전트다. 노트북 위에 있는 모든 에이전트는 다음에 뚜껑을 닫는 순간 죽을 에이전트다.
한 번만 제대로 구축하라. 그러면 영원히 실행된다.
더 많은 완전한 플레이북을 보려면 @sairahul1을 팔로우하세요. 현실 세계와의 접촉에서 살아남는 AI 워크플로우 구축에 관한 내용입니다.
요약
AI 워크플로우의 90%는 30일 안에 죽는다. 항상 같은 세 가지 이유다.
규칙 1 — 직무 기술서 없음, 에이전트 없음. 분위기는 주말을 버티지 못한다. 무엇을 감시하고, 읽고, 생산하고, 피해야 하는지, 그리고 작동했는지 어떻게 아는지를 정의하라. 단 한 줄의 프롬프트를 작성하기 전에.
규칙 2 — 침묵하는 실패만이 당신을 죽인다. 시끄러운 실패는 괜찮다. 침묵하는 실패는 고객이 발견하기 전까지는 성공처럼 보인다. 모든 에이전트에 카나리 출력, 침묵 실패 알림, 주간 스팟 체크를 구축하라.
규칙 3 — 당신의 노트북은 인프라가 아니다. 노트북은 뚜껑이 열려 있을 때만 실행된다. 진짜 에이전트는 당신이 자고, 비행기에 있고, 주말 동안 연락이 닿지 않을 때도 실행된다. VPS, 관리형 플랫폼, 서버리스 중 하나를 선택하라. 출시 전에 설정하라.
살아남는 에이전트는 더 똑똑하지 않다. 제대로 구축되었을 뿐이다.
