요즘 저는 혼자 작은 생활 도구들을 만들면서, 그걸 알리는 마케팅까지 자동화로 돌리고 있어요. SNS에 글을 올리고, 콘텐츠를 만들고, 결과를 기록하는 흐름을 n8n이라는 자동화 도구로 묶어 둔 거예요.
자동화를 처음 붙일 때는 "만드는 것"에만 신경을 써요. 워크플로우가 돌아가고 초록색 "성공"이 뜨면 다 된 줄 알죠. 그런데 며칠 '운영'해 보면, 만드는 것보다 "정말 됐는지 확인하는 것"이 훨씬 어렵다는 걸 알게 돼요.
"성공"이라고 떴는데, 글이 안 올라가 있었어요
며칠 전, 자동화 대시보드를 봤는데 모든 실행이 "성공(success)"으로 표시돼 있었어요. 당연히 게시까지 다 된 줄 알았죠. 그런데 실제 계정을 열어보니, 정작 글이 안 올라가 있는 경우가 있었어요.
처음엔 "API 호출 한도에 걸렸나?" 하고 외부 서비스 탓을 했어요. 그런데 실제 결과 화면을 직접 하나하나 확인하고 나서야, 한도 문제라고 단정했던 제 판단이 틀렸다는 걸 알았어요. 지표는 분명히 초록불인데, 진짜 결과는 빨간불이었던 거예요.
status: success는 "코드가 끝까지 실행됐다"는 뜻이지, "내가 원한 결과가 실제로 일어났다"는 뜻이 아니에요.
자동화 시스템에서 "성공"은 대부분 "마지막 단계까지 에러 없이 도달했다"를 의미해요. 중간에 실제 게시가 비어 있어도, 그 단계가 에러로 처리되지 않으면 전체는 "성공"으로 기록돼요. 이걸 흔히 false green(가짜 초록불)이라고 불러요. 가장 무서운 건, false green이 사람을 안심시켜서 한참 동안 문제를 못 보게 만든다는 점이에요.
그래서 바꾼 원칙: 지표보다 '실제 결과'를 믿기
이 일을 겪고 제가 세운 원칙은 단순해요. 대시보드 숫자와 실제 결과가 어긋나면, 실제 결과를 믿어라.
그래서 지금은 자동화의 마지막에 "진짜 결과를 직접 확인하는 단계"를 하나 넣어요.
- 게시 자동화라면: 실행 성공으로 끝내지 않고, 실제로 그 글이 게시됐는지 한 번 더 확인해요.
- 데이터 저장이라면: 저장 후 다시 읽어와서 값이 들어갔는지 확인해요(저장 + 조회 왕복).
- 알림이라면: 알림이 실제로 도착했는지를 기준으로 삼아요.
코드가 "끝났다"가 아니라, 내가 원한 일이 "일어났다"를 완료 기준으로 바꾼 거예요. 자동화일수록 사람이 매번 안 보니까, 이 마지막 확인 한 줄이 false green을 잡아줘요.
같은 원칙을 블로그에도: 매일 자동발행 파이프라인
이 경험은 마침 제가 설계 중인 다른 자동화에도 그대로 적용됐어요. 바로 블로그 글을 매일 자동으로 발행하는 파이프라인이에요. 글은 게시 성공보다 더 까다로운 문제가 있어요. 글의 내용이 사실인지는 자동화가 "성공"으로 보장해 주지 않거든요.
그래서 제가 설계한 흐름은 이래요.
- 글 작성 — 주제를 받아 초안을 만들어요. (자동)
- 사실 검증 게이트(fact-gate) — 거짓 정보·추측·근거 없는 수치를 거르는 단계예요. (자동)
- 사람 검토 — 마지막엔 제가 직접 읽고 확인해요. (수동)
- 발행 — 검토를 통과한 글만 올라가요.
핵심은 2번과 3번이에요. '자동으로 쓰기'는 쉬워요. 어려운 건 '자동으로 믿을 수 있게' 만드는 거예요. 그래서 발행은 절대 완전 자동으로 두지 않아요 — 마지막 발행 버튼은 사람이 눌러요.
혼자지만, 둘이서: Claude와 Codex의 역할 분리
혼자 만들다 보면 가장 위험한 게 "혼자라서 아무도 안 봐주는" 상황이에요. 그래서 저는 두 AI 도구의 역할을 나눠서 써요.
- Claude — 만드는 쪽. 화면을 빠르게 만들고, 자동화를 붙이고, 글 초안을 잡아요.
- Codex — 검토하는 쪽. 만든 걸 깐깐하게 다시 보고 "이거 이렇게 하면 안 깨지나?" 하고 트집을 잡아요.
만든 사람이 검토까지 하면 자기 편을 들기 마련인데, 검토를 다른 도구에 맡기면 자기 작업을 좀 더 객관적으로 보게 돼요. 혼자 일하지만 둘이서 핑퐁하는 느낌이라, 혼자 다 할 때보다 덜 틀려요.
오늘 배운 것 한 줄
- "성공(success)"은 "완료"가 아니에요.
- 지표와 실제 결과가 충돌하면, 실제 결과를 믿어요.
- 자동화의 마지막엔 "진짜로 됐는지" 확인하는 한 단계를 남겨요.
- 자동 생성보다 자동 검증이 어렵고, 발행 버튼은 사람이 눌러요.
저는 이렇게 혼자 만든 자동화와 도구들로 생활을 조금씩 정리하는 라이프케어로그를 만들고 있어요. 농구 동호회 운영을 돕는 플랜비(plan-b), 흩어진 계산을 한곳에 모은 플랜씨(plan-c), 법령을 찾을 때 곁에서 도와주는 플랜엘(plan-l), 마음을 돌보는 기록 플랜티(plan-t) — 전부 제가 직접 쓰려고 만든 작은 도구들이에요. 궁금하시면 lifecarelog.co.kr에서 볼 수 있어요.
이 글은 1인 개발자의 운영 기록이에요. 특정 서비스의 정확한 한도·내부 수치는 다룰 수 없어, 겪은 경험과 원칙 중심으로만 정리했어요.
'개발일지(빌드로그)' 카테고리의 다른 글
| n8n과 Claude Code로 자동화를 처음 설정하는 방법 (0) | 2026.06.29 |
|---|
