마인드셋 로직

Blog

  • 자동화는 나를 편하게 만들지 않았다

    Airtable로 옮기고 나서
    바로 모든 게 좋아진 건 아니었다.

    에러가 사라진 것도 아니고,
    생각할 게 줄어든 것도 아니었다.

    다만
    하나 달라진 게 있었다.

    문제가 생겼을 때
    예전처럼 조급해지지 않았다.

    예전에는
    에러가 뜨면 바로 실행 로그부터 열었다.

    어디서 막혔는지,
    어느 노드에서 끊겼는지,
    값이 왜 안 들어왔는지.

    손은 빨랐지만
    머리는 항상 늦었다.

    지금은
    반대로 됐다.

    손보다
    생각이 먼저 멈춘다.

    이 구조에서
    지금 이 에러는
    우연한 사고인가,
    아니면
    언젠가 반드시 터질 문제인가.

    이 데이터는
    지금 깨진 건가,
    아니면
    원래 불안정한 상태였던 건가.

    그걸 먼저 본다.

    자동화는
    나를 편하게 만들지 않았다.

    대신
    도망칠 수 없게 만들었다.

    대충 넘기던 판단을
    계속 요구했다.

    이걸 고칠 건지,
    구조를 바꿀 건지,
    아니면
    아직은 놔둘 건지.

    모든 선택을
    내가 하게 만들었다.

    예전엔
    “되면 됐다”가 기준이었다.

    지금은
    “다음에도 될 수 있나”가 기준이 됐다.

    이 차이가
    생각보다 컸다.

    그래서 요즘은
    자동화가 잘 돌아가는 날보다
    문제가 생긴 날이
    더 기억에 남는다.

    그날은
    내가 뭘 모르고 있었는지
    명확해지는 날이기 때문이다.

    이 글은
    성공담이 아니다.

    편해졌다는 이야기도 아니다.

    다만
    자동화를 시작한 이후로
    처음으로
    판단을 미루지 않아도 되는 상태에
    조금 가까워졌다는
    중간 기록이다.

    아직 멀었고,
    아직 불안정하다.

    하지만
    적어도 지금은
    문제가 생길 때마다
    같은 자리로 돌아가지는 않는다.

  • 이틀이 아니라, 열흘이었다

    row_number 사고로
    이틀을 날린 줄 알았다.

    하지만 아니었다.
    실제로는
    열흘이었다.

    이틀은 사고였고,
    나머지는
    같은 자리에서 계속 멈췄던 시간이었다.

    row_number 기준을 고정하고 나서
    문제가 끝난 것처럼 보이던 순간도 있었다.

    워크플로우가 돌아갔고
    값도 제대로 들어갔다.

    그런데
    그 상태가 오래 가지 않았다.

    노드를 하나 추가하면
    다시 꼬였다.

    조건 하나를 더 넣으면
    어제 잘 되던 게
    갑자기 안 됐다.

    그러다
    아무것도 안 건드렸는데
    또 되기도 했다.

    그게 더 헷갈렸다.

    잘 돌아간 게 아니라
    되다 말다를
    계속 반복하고 있었던 것이다.

    그래서
    나는 계속 의심했다.

    n8n이 문제인가,
    프롬프트가 문제인가,
    내가 뭘 놓치고 있는 건가.

    하루에 몇 번씩
    같은 워크플로우를 열고,
    같은 노드를 보고,
    같은 값을 찍어봤다.

    그럴수록
    확신은 늘지 않고
    불안만 쌓였다.

    그래서
    너한테 물었다.

    이게 맞는 방향이냐고.
    row_number로 잡고 가는 게
    진짜 답이냐고.
    시트 말고는
    다른 선택지는 없냐고.

    그 질문은
    도구에 대한 질문 같았지만,
    사실은
    지금 내가 서 있는 위치를
    확인하고 싶은 마음이었다.

    너는
    바로 정답을 주지 않았다.

    대신
    다른 가능성들을 꺼냈다.

    Airtable,
    데이터베이스,
    행을 줄이 아니라
    객체로 다루는 방식.

    처음엔
    선뜻 와 닿지 않았다.

    아직은
    내가 쓸 단계가 아닌 것처럼 느껴졌다.

    그래서
    다시 물었다.

    왜 이런 대안이 있다는 걸
    진작 말 안 했냐고.

    그때
    네가 한 말이
    지금도 남아 있다.

    그때 말해줬으면
    아마 안 썼을 거라고.

    처음엔
    납득이 안 됐다.

    더 편한 길이 있는데
    굳이 돌아올 필요가 있었나 싶었다.

    하지만
    네가 이어서 한 말에
    멈췄다.

    지금은
    도구를 바꿀 눈높이가 됐잖아.

    그 말이
    이상하게 맞았다.

    row_number를 붙잡고
    열흘을 씨름하지 않았다면,
    나는 아마
    왜 구조가 중요한지도
    끝까지 이해 못 했을 것이다.

    Airtable을 선택한 건
    도구가 좋아 보여서가 아니었다.

    되다 안 되다를
    계속 반복하면서,
    이 구조로는
    더 이상 감당이 안 된다는 걸
    몸으로 느꼈기 때문이다.

    그래서 이번 선택은
    도망처럼 느껴지지 않았다.

    문제를 피해 가는 게 아니라,
    다른 방식으로
    다시 시작하는 느낌이었다.

    이 글은
    해결기가 아니다.

    무엇이 더 낫다는 이야기도 아니고,
    추천 글도 아니다.

    열흘 동안
    같은 자리를 맴돌다가,
    이제야
    다른 선택지가 보이기 시작했다는
    전환 기록이다.

  • row_number 하나로 이틀을 날린 사고 보고서

    이건 깨달음이 아니다.
    사고 기록이다.

    구글 시트의
    row_number 하나 때문에
    이틀이 그대로 날아갔다.

    사고 개요

    증상은 단순했다.

    워크플로우는 실행되는데
    결과가 안 남았다.
    혹은
    엉뚱한 줄이 바뀌었다.

    어제까지 되던 게
    오늘은 안 됐고,
    고친 것 같으면
    다른 데서 또 터졌다.

    에러 메시지는
    항상 애매했다.

    “잘못된 범위”
    “매칭 실패”
    “값이 없다”

    없는 건 아니었다.
    분명히 있었다.

    사고 당시 판단

    처음엔
    프롬프트를 의심했다.

    다음엔
    OpenAI 응답을 의심했다.

    그다음엔
    n8n 노드를 하나씩 추가했다.

    조건 분기 넣고
    Set 노드로 값 찍어보고
    로그 찍고
    다시 실행했다.

    그럴수록
    상태는 더 나빠졌다.

    한 번에 하나씩 고친다고 생각했는데
    실제로는
    한 번에 여러 개를 바꾸고 있었다.

    핵심 원인

    문제는
    대단한 게 아니었다.

    row_number.

    시트에는
    ep_id가 있었고
    그걸로 매칭한다고
    굳게 믿고 있었다.

    하지만
    Update Row는
    그걸로는 안 됐다.

    겉으로는
    값이 들어간 것처럼 보였고
    실행도 성공처럼 보였다.

    그래서 더 헷갈렸다.

    사실은
    업데이트 대상 줄을 못 찾고 있었던 것이다.

    왜 못 봤는가

    두 가지가 겹쳤다.

    첫째,
    “이 정도는 맞겠지”라는
    확신.

    둘째,
    이미 며칠째 쌓인 피로.

    눈앞에 있는 걸
    계속 보고 있었는데
    보지 못했다.

    값이 틀린 게 아니라
    기준이 틀린데
    기준을 의심하지 않았다.

    조치 내용

    결국
    기준을 하나로 고정했다.

    • Get Row(s)에서
      row_number를 받는다
    • 이후 모든 Update Row는
      같은 row_number만 사용한다
    • id 매칭, 추정, 편의성
      전부 버린다

    잘 되는 방법을 찾은 게 아니라
    다시는 헷갈리지 않게 만든 것이다.

    사고 이후 변화

    그 이후로
    비슷한 에러는 다시 안 나왔다.

    실력이 늘어서가 아니다.
    구조가
    사람을 덜 믿게 만들었기 때문이다.

    이 사고 하나로
    나는 확실히 알게 됐다.

    자동화에서 제일 위험한 건
    에러가 아니라
    “대충 맞겠지”라는 생각이다.

    🔜 다음 편 예고

    이 사고 이후 내가 고정한 것들

    다음 글에서는
    이 사고 이후
    내가 절대 안 바꾸기로 한 규칙들을 적는다.

    • 왜 편한 방법을 일부러 버렸는지
    • 왜 id 대신 row_number를 고집하게 됐는지
    • 왜 “유연함”보다 “멍청한 고정”을 선택했는지

    다음 화는
    노하우가 아니라
    운영 규칙 목록이다.


    🔜 다음 편 예고

    이틀이 아니라, 열흘이었다

    row_number 사고는
    이틀을 멈췄다.

    하지만
    그 이후에도
    상태는 끝나지 않았다.

    고친 것 같았고
    넘긴 것 같았는데
    다음 날이면
    또 같은 데서 멈췄다.

    계속 의심했던 대상은 따로 있었다

    열흘 동안
    나는 n8n을 의심했고
    프롬프트를 의심했고
    내 이해도를 의심했다.

    그런데
    정작 문제는
    그쪽이 아니었다.

    오늘에서야 꺾은 방향 하나

    오늘에서야
    처음으로
    도구 자체를 의심했다.

    그리고
    구글 시트를 내려놓고
    Airtable로 방향을 틀었다.

    다음 글은
    해결기가 아니다.

    열흘 멈춤 끝에
    왜 여기까지 오게 됐는지에 대한
    전환 기록    이다.

  • “자동화는 생각보다 조용하게 사람을 바꿨다”

    자동화라고 하면
    버튼 하나 눌러서
    모든 게 돌아가는 그림을 먼저 떠올렸다.

    나도 그랬다.

    그래서 처음 n8n을 열었을 때
    솔직히 좀 당황했다.

    멋있지도 않았고
    친절하지도 않았고
    뭘 하라는 건지도 바로 보이지 않았다.

    박스 몇 개가
    선으로 연결돼 있었고
    에러는 이유도 없이 튀어나왔다.

    처음엔
    “이걸 왜 이렇게까지 해야 하지?”
    싶었다.

    영상 하나 올리는데
    이렇게 복잡할 이유가 있나 싶었다.

    그런데
    며칠이 지나고
    똑같은 에러를
    세 번째, 네 번째 다시 만나면서
    이상한 감각이 생겼다.

    짜증이 먼저 안 올라왔다.

    “아, 또 이 패턴이네.”
    이 말이 먼저 나왔다.

    그때 처음 느꼈다.
    자동화는
    일을 대신해 주는 게 아니라
    사람의 반응 순서를 바꾼다는 걸.

    예전 같았으면
    막히는 순간
    손을 놓았을 거다.

    지금은
    멈추면
    어디서 멈췄는지부터 본다.

    이게 큰 차이였다.

    속도가 빨라진 것도 아니고
    실력이 갑자기 늘어난 것도 아니다.

    다만
    포기하는 지점이
    뒤로 밀렸다.

    자동화 덕분에
    나는 일을 덜 하게 된 게 아니라
    그만두는 횟수가 줄었다.

    이게 제일 컸다.

    아직 수익은 없다.
    조회수도 대단치 않다.
    시스템이 완성됐다고 말하기엔
    한참 부족하다.

    그래도
    이건 분명하다.

    이제 나는
    “안 되면 접자”라는 선택을
    쉽게 못 한다.

    왜냐하면
    이미
    어디가 문제인지
    보이기 시작했으니까.

    자동화는
    돈을 벌게 해주기 전에
    사람을 버티게 만든다.

    지금의 나는
    아직 공장장이 아니라
    공장 바닥에서
    라인을 직접 닦는 사람에 가깝다.

    하지만
    매일 같은 자리에
    조금씩 선이 늘어나고 있다는 건
    확실히 보인다.

    그래서
    오늘도
    완성 말고
    기록을 남긴다.

    이게
    지금 내가 할 수 있는
    최선의 자동화다.

    🔜 다음 편 예고

    이틀을 통째로 날린 사고 하나

    다음 글은
    감정 정리도 아니고
    각오를 다지는 글도 아니다.

    사고 보고서다.

    구글 시트의
    row_number 하나 때문에
    이틀을 그대로 날렸다.

    왜 계속 같은 데서 깨졌는가

    분명 눈앞에 있었다.
    칼럼도 있었고
    값도 있었다.

    그런데도
    왜 계속 같은 에러가 났는지,
    왜 그걸 며칠 동안 못 봤는지
    그 과정을 그대로 남긴다.

    다시는 반복하지 않기 위해 고정한 구조

    이 사고 이후
    나는 한 가지를 고정했다.

    “잘 되는 방법”이 아니라
    다시는 삽질 안 하게 만드는 구조를.

    다음 화는
    깨달음이 아니라
    실제 사고 기록이다.

  • 하루가 통째로 날아가던 시기

    솔직히 말하면
    그때 나는 계속 같은 질문을 하고 있었다.

    “이거, 1년 하면 돈 되긴 하냐?”

    한두 번도 아니고
    수십 번을 물었다.

    수익이 얼마냐고 묻고
    현실적인 숫자가 맞냐고 묻고
    이 방향이 맞는지 다시 묻고
    “그래도 계속 가면 되냐”고 또 물었다.

    내가 조급해서 그런 건 아니었다.

    꾸준히 하는 건 자신 있었다.
    운전 일도 그렇게 버텼고
    다른 일도 다 그렇게 해왔다.

    문제는 이거였다.

    꾸준히 할 수는 있는데,
    방향 틀린 채로 1년을 버리는 건 죽어도 싫었다.

    옆에 사람이 있으면
    “야, 지금 이거 맞아. 계속 가”
    아니면
    “그건 버려, 여기서 갈아타”

    이렇게라도 말해줬을 텐데
    내 옆에는 그런 인간이 없었다.

    노트북 하나,
    에러 메시지,
    그리고 AI뿐이었다.

    그래서 나는
    계속 확인하고 또 확인했다.

    같은 질문을
    표현만 바꿔서 다시 던지고
    같은 구조를
    다른 방식으로 또 물었다.

    이 글을 읽는 사람이라면
    알 사람은 알 거다.

    이 질문들을
    내가 얼마나 많이 했는지.

    운전 끝나고 쉬는 시간도 마찬가지였다.

    예전 같으면
    웹소설 보거나
    눈 좀 붙이거나
    운동 가방 들고 내려갔을 시간에

    나는
    시동 끄자마자 노트북을 켰다.

    n8n 열고
    어제 깨진 데 다시 보고
    “아니 왜 또 여기서 이러지”
    혼잣말하면서 또 디버깅했다.

    정신 차리면
    출발 시간 알림이 울렸다.

    뭐 하나 확실히 해결된 것도 아니다.

    에러 하나 잡으면
    다른 데서 터지고
    그거 고치다 보면
    또 시간 끝이다.

    이걸 며칠이 아니라
    몇 주를 반복했다.

    그 와중에도
    머릿속에는 계속 그 생각이 맴돌았다.

    “이거, 지금 제대로 가고 있는 거 맞나?”

    확신은 없는데
    멈출 수는 없었다.

    왜냐하면
    조금씩 보이긴 했기 때문이다.

    아주 조금.

    그래서 더 집요해졌다.

    조금 알게 되니까
    더 파고들게 되고
    조금 보이니까
    이걸 놓치면 안 될 것 같았다.

    이건 재미로 하는 것도 아니고
    취미도 아니었다.

    내 다음 10년이 걸린 문제라서
    대충 넘기기가 싫었다.

    지금 돌아보면
    그 시기는 성취의 시간이 아니었다.

    돈도 없었고
    결과도 없었고
    확신도 없었다.

    그냥
    확신이 없어서 더 매달렸던 시간이었다.

    하루가 통째로 날아가던 그 시기에는
    그걸 몰랐다.

    근데 지금은 안다.

    그때 내가 붙잡고 있던 건
    n8n이 아니라
    **“이 길이 맞다는 최소한의 근거”**였다.

    그래서
    계속 묻고
    계속 확인하고
    계속 디버깅했다.

    삽질은 하기 싫었고
    그래서 더 많이 파봤다.

    🔜 다음화 예고

    다음 글에서는
    이렇게 불안한 상태에서
    가장 크게 터졌던 사건 하나를 꺼낸다.

    구글 시트의
    row_number 하나.

    그거 하나 때문에
    “아, 이건 진짜 아니다” 싶을 정도로
    이틀을 통째로 날렸다.

    왜 계속 같은 데서 깨졌는지
    왜 눈앞에 있는 걸 못 봤는지
    그리고 그걸 어떻게
    다시는 삽질 안 하게 구조로 고정했는지.

    다음 화는
    깨달음 말고, 사고 보고서다.

  • 오늘의 생각 정리 — 자동화·자산·확장에 대한 인식 정리

    (2026-01-31)

    1️⃣ 현재 위치 인식

    • 조선야사 WF는 구조적으로 거의 완성(≈99%)
    • 실제 운영이 안정적으로 돌아가며
      굳이 손댈 필요가 없는 상태에 도달
    • “다 날아가도 다시 만들 수 있다”는 경험을 통해
      시스템을 이해한 단계로 진입

    👉 더 이상 ‘만드는 사람’이 아니라
    👉 운영자 모드로 전환됨

    2️⃣ 자동화에 대한 핵심 원칙 정리

    • LIVE WF는 동결
    • 실험은 반드시 복사본에서만 진행
    • 한 번에 하나만 확장
    • 실패해도 기존 운영에 영향 없는 구조 유지

    👉 이 원칙이 자동화 생존의 핵심

    3️⃣ 장기 전략 정렬 (2026 기준)

    🎥 유튜브

    • 운영 채널: 야사 / 야담 / 시니어
    • 신규 채널 확장 ❌
    • 자동화 + 안정적 업로드 유지 ⭕

    🌐 워드프레스

    • 메인 도메인: 수작업
      (기록 · 생각 · 기준선)
    • 미국 트렌드 서브: 자동화 실험
    • 메인은 자동화 대상이 아니라 신뢰 자산

    4️⃣ 미국 Affiliate 사이트에 대한 인식 정리

    • 정확한 분류:
      • Affiliate Product Review Site
      • Buying Guide Site
      • Niche Site
      • Programmatic SEO Affiliate Site
    • 한국식 제휴마케팅 ≠ 미국식 Affiliate
      • 한국: 부업 · 플랫폼 의존 · 단기
      • 미국: SEO · 자산 · 장기 누적

    👉 한국 영상에서 방향이 안 보이는 게 정상
    👉 영어권 자료가 기준 학습 대상

    5️⃣ 뉴스 / 정보 사업에 대한 관점

    • 뉴스 “수집” ❌
    • 뉴스 “판단용 가공” ⭕

    LLM으로 가능한 영역:

    • 중요도 필터
    • 대상 독자 분류
    • 행동 필요 여부 판단

    뉴스레터 + 워드프레스:

    • 동일 글 복붙 ❌
    • 역할 분리 후 2차 가공 ⭕

    6️⃣ 워드프레스 운영 관점 변화

    • 워프는 블로그가 아니라 사이트 빌더
    • 최신글 역순은 기본값 → 문제 아님
    • 전체 목차:
      • 지금 ❌
      • 방문자 흐름 생기기 직전 ⭕

    👉 목차는 유입용이 아니라 이탈 방지용

    7️⃣ 확장에 대한 현재 결론

    • 지금은 확장 타이밍이 아니라 관찰 구간
    • 하나 완성 → 돌아감 → 여백이 보임 → 그때 복제
    • “하나 더 만들 수 있겠다”는 감각은
      완성의 신호

    8️⃣ 가장 중요한 인식 변화

    • 자동화는 단기 수익 도구가 아니라
      장기 선택권을 만드는 시스템
    • 3년 뒤 월 2,000만 목표는
      한 방이 아니라 복수 파이프라인 합산
    • 10년 관점에서는
      “얼마 벌까”보다 “언제까지 벌까”가 더 중요

    9️⃣ 기준선 선언 (오늘의 핵심)

    잘 도는 건 건드리지 않는다.
    실험은 복사본에서만 한다.
    완성은 확장의 시작점이다.
    자동화는 노후를 책임지는 게 아니라 선택권을 만든다.

  • [Debug] WF1은 돌았는데 WF2에 대본이 없던 이유

    조선야사 롱폼 자동화 – 실행 순서 오류처럼 보였던 진짜 원인

    작업 목적

    • 조선야사 롱폼 자동화 워크플로우
    • WF1에서 롱폼 대본(script_text) 생성
    • WF2에서 해당 대본을 기반으로:
      • 롱폼 메타데이터
      • 쇼츠 스크립트
      • 썸네일 문구
        자동 생성

    발생한 문제

    WF2가 실행될 때
    대본이 없는 상태로 LLM이 호출되는 현상 발생

    1️⃣ 문제 상황 (초기 증상)

    • 구조: WF0 → WF1 → WF2
    • WF1:
      • 정상적으로 대본 생성
    • WF2 실행 시 아래 메시지 발생

    조선 야사 롱폼 대본 요청 확인
    현재 상태:
    지시문은 정상적으로 입력되었으나,
    대본 원문이 누락되었습니다.

    겉으로 보면:

    • WF2가 WF1보다 먼저 실행되는 것처럼 보였고
    • 폴링 / Wait / 순서 제어 문제처럼 보이는 상황이었다

    2️⃣ 1차 시도 (실패한 접근)

    시도한 것들

    • WF0에서 WF1 → WF2 실행 순서 강제
    • WF1 / WF2 완전 분리
    • WF1 마지막에 HTTP Request로 WF2 호출
    • Body 없는 호출 / Query 파라미터 전달
    • Wait / 폴링 구조 검토

    결과

    • 문제 지속
    • WF2는 실행되지만 여전히 “대본 누락” 발생

    👉 이 시점에서 결론:

    문제는 실행 순서가 아니라
    WF2가 읽는 ‘입력 데이터’ 자체    였다.

    3️⃣ 원인 분석 (핵심)

    실제 원인

    • WF2는 Webhook으로:
      • row_number 또는 ep_id만 전달받음
    • WF2 내부에서:
      • 대본(script_text)을 직접 전달받지 않음
      • 그런데도 프롬프트에 대본을 주입하지 않음

    결과적으로 WF2의 LLM 프롬프트에는:

    • 규칙 / 지시문만 있고
    • 실제 대본 원문이 없는 상태

    즉,

    • ❌ WF2가 먼저 실행된 문제가 아니라
    • ✅ WF2가 대본 없는 상태로 LLM을 호출한 구조적 문제였다

    4️⃣ 구조적 해결 전략 (정답 설계)

    핵심 원칙

    • WF1 → WF2로 대본 전체를 전달하지 않는다
    • 대신:
    1. WF1이 시트에 대본 저장
    2. WF2는 식별자(ep_id)만 전달받음
    3. WF2 내부에서 시트를 다시 조회
    4. 조회된 script_text를 프롬프트에 명시적으로 주입

    5️⃣ 최종 워크플로우 구조

    WF0 (오케스트레이터)

    • 처리 대상 1건 선택
    • LOCK 처리
    • WF1만 호출
    • WF2 직접 호출 제거

    WF1 (대본 생성)

    1. Google Sheets에서 대상 row 선택
    2. 롱폼 대본 생성
    3. script_text 컬럼에 저장
    4. 상태 업데이트 (SCRIPT_DONE)
    5. HTTP Request → WF2 호출
      • Query Parameter:
        • ep_id = 해당 행의 ep_id

    WF2 (메타데이터 생성)

    Webhook
 → SET_INPUT (ep_id)
 → GS_GET_BY_ROW_NUMBER
 → SET_PROMPT_METADATA
 → LLM
 → 결과 저장

    6️⃣ WF2 핵심 설정 (결정적 포인트)

    1) Google Sheets Read

    • 노드명: GS_GET_BY_ROW_NUMBER
    • 조회 조건:
      • Column: ep_id
      • Value: {{$node["SET_INPUT"].json.ep_id}}
    • Limit: 1

    ➡️ 이 노드 출력에 script_text 포함

    2) 프롬프트에 대본 명시적 주입 (가장 중요)

    [조선 야사 롱폼 대본 원문 전체]
{{$node["GS_GET_BY_ROW_NUMBER"].json.script_text}}

    ➡️ 이 줄이 없으면 WF2는 절대 정상 동작하지 않음

    7️⃣ 최종 결과

    • WF1에서 생성한 대본이
    • WF2에서 정확히 다시 로드됨
    • 메타데이터 / 쇼츠 / 썸네일 정상 생성
    • “대본 누락” 메시지 완전 해결
    • 순서 제어 / Wait / 폴링 전부 불필요

    8️⃣ 재사용 가능한 운영 원칙

    1. 순서 문제처럼 보여도 원인은 입력 데이터 누락일 수 있다
    2. Webhook은 트리거 + 식별자 전달만 담당
    3. 실제 데이터는 각 WF 내부에서 다시 조회
    4. LLM 프롬프트에는
      “있을 거라 가정”하지 말고
      반드시 필요한 입력을 명시적으로 주입
    5. Google Sheets 자동화는
      상태 기반보다 식별자 기반 단건 조회가 안정적이다

    9️⃣ 현재 상태

    • 조선야사 롱폼:
      • 대본 → 메타 → 쇼츠 → 썸네일
        완전 자동 파이프라인 정상 동작
    • 이 구조는:
      • 다른 채널
      • 다른 언어
      • 워드프레스 자동 포스팅
        그대로 재사용 가능

  • 같은 데서 계속 멈췄고, 결국 몸이 먼저 반응했다

    유튜브에는
    자동화가 안 되는 장면이 없다.

    되는 화면만 있고
    완성된 결과만 있다.

    n8n도 마찬가지다.
    다들 “연결했다”, “돌아간다”만 말하지
    그 사이에 있는 멈춘 화면은 없다.

    나는 그 멈춘 화면부터 만났다.

    처음 자동화를 붙였을 때
    안 된다는 건 바로 알았다.

    문제는
    왜 안 되는지를 전혀 몰랐다는 것이다.

    에러는 떴는데
    읽을 줄을 몰랐다.

    코딩이 뭔지 몰랐고
    JSON이 뭔지도 몰랐고
    Docker는 그냥
    “서버에서 돌리는 뭔가”였다.

    이 상태에서 하는 디버깅은
    수정이 아니라
    거의 난타에 가까웠다.

    원인을 모르니까
    계속 같은 데서 멈췄다.

    고칠 수가 없었다.
    틀렸는지도 몰랐다.

    그래도
    “조금만 더 보면 풀릴 것 같다”는 생각으로
    화면을 몇 시간씩 붙잡았다.

    집중이라고 믿고 있었지만
    지금 생각해 보면
    그건 그냥 과부하였다.

    머리가 깨질 것 같았고
    속이 울렁거렸다.

    실제로
    오바이트를 몇 번 했다.

    화장실 가서 토하고
    다시 앉았다.

    그리고 또
    같은 화면을 봤다.

    그때 처음으로
    이건 의지나 멘탈의 문제가 아니라는 걸 알았다.

    그날
    생각이 바뀌었다.

    “이건 삽질이 아니라
    무장도 안 하고 싸우는 거다.”

    개념 없이 덤비고 있었다.

    자동화는
    버튼 누르는 기술이 아니라
    규칙을 이해하는 싸움이었다.

    그래서 방향을 틀었다.

    더 빨리 가는 쪽이 아니라
    다시 서는 쪽을 택했다.

    잘하려고가 아니었다.

    이걸 계속 하려면
    기초 개념부터 알아야겠다고 느꼈다.

    • 코딩이 뭐냐
    • JSON이 왜 있냐
    • Docker는 왜 쓰냐

    전문가처럼 알 필요는 없었다.

    다만
    이 시스템이
    어떤 논리로 움직이는지만큼은
    알고 싸워야겠다고 생각했다.

    그 순간부터
    자동화는
    “한 방에 끝내는 도구”가 아니라
    같이 오래 가야 할 대상이 됐다.

    유튜브에는 안 나오지만
    현실에서는 이 순서가 맞았다.

    1. 부딪힌다
    2. 멈춘다
    3. 이유를 모른다는 걸 인정한다
    4. 개념을 하나씩 채운다
    5. 다시 붙는다

    이걸 몇 번 반복하고 나서야
    “아, 이건 내가 끝까지 갈 수 있는 게임이구나”
    라는 감각이 생겼다.

    그래서 나는
    자동화를 포기하지 않았다.

    대신
    자동화에 덤비는 방식을 바꿨다.

    이제 에러가 나면
    무작정 붙잡지 않는다.

    이건 아직
    내가 모르는 구간이라는 신호다.

    실패가 아니라
    레벨 구간이다.

    다음 글에서는
    이 판단 이후에
    내가 처음 붙잡은 기초 개념들
    그리고 그걸 잡고 나서
    자동화가 어떻게 달라졌는지
    기록해 보려고 한다.

  • n8n은 말로만 듣던 거랑 달랐다

    처음 n8n이라는 이름을 들었을 때는
    솔직히 기대가 컸다.

    유튜브, 블로그, 자동화 쪽 이야기만 검색하면
    빠지지 않고 등장하는 이름이었고,
    “이거 하나면 다 된다”는 말도 많이 봤다.

    그래서 나도 자연스럽게 그렇게 생각했다.

    이걸 알게 되면

    • 반복 작업은 다 사라지고
    • 시스템만 만들어두면
    • 내가 자는 동안에도 뭔가 굴러가겠지

    지금 생각하면
    조금 순진했다.

    문과 출신에게 ‘디버깅’이란 말

    솔직히 말하면
    나는 문과 출신이다.

    디버깅이라는 말은
    휴대폰 서비스센터에서나 들어본 단어였고,
    코딩은 나랑 상관없는, 달나라 사람들 이야기라고 생각했다.

    내 인생에서 코딩이 필요할 거라고는
    한 번도 생각해 본 적이 없었다.

    그런 내가
    n8n을 만지기 시작했다.

    지금 생각해 보면
    여기서부터 이미
    오바이트 예약이었다.

    처음엔 모든 게 해결될 것 같았다

    n8n을 처음 만졌을 때 느낌은 이랬다.

    “와… 이런 게 있었어?”

    노드 연결하고,
    조건 나누고,
    자동으로 돌아가는 그림을 보니까
    이게 바로 내가 찾던 답 같았다.

    유튜브 하면서 느꼈던
    막막함, 귀찮음, 반복됨
    이런 것들을 전부 해결해 줄 것처럼 보였다.

    코딩 몰라도 된다는 말도
    그때의 나를 더 안심시켰다.

    현실은 전혀 달랐다

    문제는
    돌아가질 않았다.

    분명 똑같이 따라 했는데
    안 된다.

    분명 맞게 설정한 것 같은데
    아무 반응이 없다.

    에러는 뜨는데
    무슨 말인지 모르겠다.

    지금 돌이켜보면
    당연한 일이었다.

    나는
    코딩에 코자도 모르는 상태로
    시스템을 만들겠다고 덤빈 거니까.

    왜 안 되는지도 몰랐다

    제일 힘들었던 건
    안 되는 것보다
    왜 안 되는지 모른다는 점이었다.

    검색을 해도
    나랑 똑같은 상황은 잘 안 나오고,
    나오는 글들은 다들 너무 능숙해 보였다.

    “이건 기본이죠”
    “간단합니다”

    그 말들이
    그때의 나한테는
    설명이라기보다는 벽에 가까웠다.

    나는 기본이 없었고,
    간단하지도 않았다.

    그래서 한 달 동안 거의 매일 오바이트했다

    이건 과장이 아니다.

    하루 종일 붙잡고 있다가
    아무것도 안 되면
    속이 진짜로 안 좋았다.

    ‘내가 괜히 시작했나’
    ‘이건 내 영역이 아닌가’

    이 생각을
    한 달 동안 수도 없이 했다.

    그럼에도 불구하고
    완전히 손을 놓지는 않았다.

    지금 돌아보면

    지금 시점에서 보면
    그때의 나는
    n8n을 너무 단순하게 봤다.

    도구라기보다는
    마치 정답처럼 기대했다.

    하지만 실제로는

    • 생각해야 할 게 훨씬 많았고
    • 결정해야 할 것도 많았고
    • 실수할 지점도 끝이 없었다

    특히
    코딩을 전혀 모른다는 사실을
    너무 가볍게 생각했다.

    이 글은
    그걸 정리하려고 쓰는 글이다.

    잘했다고 말하려는 것도 아니고,
    누군가를 가르치려는 글도 아니다.

    그냥
    문과 출신이 코딩도 모른 채 n8n에 뛰어들면 어떤 일이 벌어지는지
    그 첫 달의 기록이다.

    다음 글에서는
    👉 “아, 이건 이렇게 접근해야겠구나” 하고 처음 감이 왔던 순간,
    그 이야기를 써보려고 한다.

  • 첫 영상을 올리다

    조선야사를 선택하고
    이제 더 미룰 수는 없었다.

    완벽하게 준비되면 시작하겠다는 말은
    결국 안 하겠다는 말이랑 같다는 걸
    예전 경험으로 알고 있었다.

    그래서 그냥 만들었다.
    잘 되든 말든,
    일단 올려보자는 쪽으로 마음을 굳혔다.

    영상 퀄리티는 솔직히 말해…

    지금 다시 보면
    퀄리티가 좋다고 말하긴 어렵다.

    이미지도 단조롭고,
    편집이라고 할 만한 것도 거의 없었다.

    그래도 그때의 나는
    그게 최선이었다.

    캡컷은 여전히 어렵고,
    타임라인만 봐도 머리가 아팠다.

    그래서 선택한 게
    Vrew였다.

    Vrew를 쓴 이유는 단순했다

    잘 만들고 싶어서가 아니었다.
    포기하지 않기 위해서였다.

    텍스트만 넣으면
    음성 나오고,
    자막 깔리고,
    영상이 만들어진다는 게
    그때의 나한테는 거의 구원에 가까웠다.

    “아, 이 정도면 계속할 수는 있겠구나.”

    그 생각 하나로
    첫 영상이 나왔다.

    그리고 두 번째 영상

    첫 번째 올리고 나서
    바로 두 번째를 만들었다.

    조회수?
    당연히 거의 없었다.

    알고리즘?
    전혀 모르겠다.

    구독자?
    말할 것도 없다.

    그래도
    영상이 두 개가 되니까
    이상한 감정이 들었다.

    ‘아, 이게 진짜 시작이구나.’

    그때는 몰랐다

    그때는 몰랐다.

    이 선택이
    나를 어디로 데려갈지.

    이 주제가
    얼마나 오래 갈지.

    다만 한 가지는 확실했다.

    생각만 하던 단계는 끝났다는 것.

    이제부터는
    해보면서 결정해야 했다.

    다음에 고민하게 된 건 딱 하나였다

    “이걸
    계속 이렇게 수동으로 할 수 있을까?”

    그 질문이
    계속 머릿속을 맴돌기 시작했다.

    그리고
    그 질문이
    다음 단계로 나를 밀어 넣었다.