시즌 2-13편. 비전공자가 만든 첫 자동화 워크플로

 

지난 편에서는 skill.md 파일 하나를 실제로 만들어보는 튜토리얼을 정리했습니다. 그때 살짝 예고했듯, 오늘은 그 skill.md들이 여러 개 모여서 실제로 뭔가를 자동으로 해내는 첫 워크플로를 만들어본 이야기입니다.

시즌 2-11편, 12편이 각각 하나의 스킬을 만드는 튜토리얼이었다면, 오늘은 그것들을 조립해서 파이프라인으로 만드는 실험기에 가깝습니다. 저의 첫 자동화니만큼 결과가 늘 예쁘지는 않았습니다. 자동화된 부분보다 헤맨 부분이 더 많았고, 최종적으로도 손볼 곳이 남아 있습니다. 그런데 그 과정에서 배운 것이 오히려 이 편의 핵심입니다.

시작 전에 개념 하나를 정리하겠습니다. 자동화 워크플로는 여러 단계로 나뉜 작업을 사람의 개입 없이 순서대로 실행하는 흐름입니다. 시즌 2-3편에서 다뤘던 AI 에이전트의 실행자 감각이 여기서 자연스럽게 이어집니다.

한 문장으로 정리하면 이렇습니다.

자동화 워크플로는 여러 스킬과 도구를 순서대로 엮어, 한 번의 요청으로 여러 단계의 결과를 얻어내는 파이프라인입니다.

핵심은 여러 스킬을 엮는다는 부분입니다. 시즌 2-12편에서 만든 skill.md 하나만으로는 한 종류의 작업만 됩니다. 여러 개를 엮어야 실제 업무 하나가 완결됩니다.

🎬 오늘 만들 워크플로

목표를 먼저 정하겠습니다. 이번 실험의 대상은 이거였습니다.

블로그 원고 자동 발행 파이프라인 — 원고 폴더의 마크다운 초안 하나를 지정하면, 초안 리뷰 → 개선 반영 → 태그 자동 추출 → 노션 발행까지 한 번에 이어지는 흐름

이 파이프라인이 완성되면, 저는 "13번 원고 발행해줘" 한 마디로 리뷰-반영-발행이 자동으로 흘러가게 됩니다. 실제로 이 시즌의 원고들도 궁극적으로 이런 파이프라인 위에서 관리하고 싶었습니다.

🛠️ 조립에 쓴 재료

파이프라인의 재료는 세 가지 스킬과 하나의 외부 도구였습니다.

• blog-review 스킬 (시즌 2-12편에서 만든 것)
• tag-extractor 스킬 (새로 만듦: 원고에서 태그 후보를 뽑는 스킬)
• notion-publisher 스킬 (새로 만듦: 노션에 원고를 하위 페이지로 발행하는 스킬)
• Notion API 접근용 도구 (시즌 2-5편에서 이야기했던 MCP 규격의 노션 커넥터)

각 스킬은 짧게 이렇게 정의했습니다.

• blog-review는 원고를 8원칙으로 리뷰하고, 개선 제안을 남긴다
• tag-extractor는 원고의 핵심 개념을 뽑아 시즌 2 톤에 맞는 태그 8~10개를 만든다
• notion-publisher는 원고 파일과 태그를 받아 노션의 지정된 부모 페이지 아래에 하위 페이지로 발행하고, 결과 URL을 반환한다

🍳 조립하는 감각을 요리 비유로

시즌 2 초반부터 이어오는 요리 비유를 다시 써보겠습니다.

• 스킬 하나: 한 가지 요리 만드는 법 (파스타 만들기, 샐러드 만들기)
• 자동화 워크플로: 코스 요리 하나가 완결되는 흐름 (샐러드 → 파스타 → 디저트 순서 짜기)

각 요리 자체는 이미 스킬로 만들 수 있습니다. 하지만 순서, 인수인계, 이 요리의 결과가 다음 요리의 재료가 되는 흐름은 별도로 설계해야 합니다. 이게 워크플로의 진짜 어려움이었습니다.

🛠️ 실제 조립은 이렇게 진행했습니다

1단계: 순서 설계

먼저 종이에 이런 흐름을 그렸습니다.

• 사용자 요청 "13번 원고 발행해줘"
• → ~/blog/13-*.md 파일 찾기
• → blog-review 스킬 발동, 리뷰 결과 파일에 저장
• → 사용자에게 리뷰 확인 요청 (선택적: 개선 반영)
• → tag-extractor 스킬 발동, 태그 목록 확보
• → notion-publisher 스킬 발동, 노션에 발행
• → 결과 URL 반환

이 흐름을 하나의 마스터 스킬(blog-pipeline)로 정리해서, "이런 요청이 오면 위 순서를 밟아라"고 명시했습니다.

2단계: 마스터 스킬 작성

blog-pipeline/SKILL.md의 핵심은 이렇게 썼습니다.

여기서 중요한 것은 각 단계 사이의 사용자 확인을 명시한 부분입니다. 처음에는 이 확인 단계를 뺐다가 크게 후회했습니다. 그 이야기는 아래에서 이어집니다.

3단계: 각 스킬 사이의 데이터 흐름 정의

여기가 가장 헤맨 지점이었습니다. 스킬 A의 결과가 스킬 B의 입력이 되어야 하는데, 그 사이 데이터가 어떻게 넘어가는지가 처음에는 헷갈렸습니다.

해결책은 단순했습니다. 각 스킬의 출력물이 파일로 남게 명시하는 것이었습니다. blog-review는 리뷰 결과를 ~/blog/reviews/N-review.md로 저장하고, tag-extractor는 태그를 ~/blog/tags/N-tags.txt로 저장합니다. 그러면 다음 스킬은 그 파일을 읽어와서 작업합니다.

이 방식이 좋았던 이유는 중간 결과가 사람도 볼 수 있는 형태로 남는다는 것이었습니다. 어느 단계에서 문제가 생겼는지 파일만 열어보면 바로 파악할 수 있었죠.

4단계: 실전에서 굴려보기

파이프라인이 완성되고 처음 굴려봤습니다. 이때 벌어진 일들이 오히려 이 편의 핵심입니다.

첫 시도: "13번 원고 발행해줘"라고 요청. 결과는 예상대로 흘렀습니다. 리뷰가 나오고, 사용자 확인 후, 태그가 뽑히고, 노션에 발행이 되었습니다. URL이 반환됐고 열어보니 잘 올라가 있었습니다. 성공했다고 생각했습니다.

두 번째 시도: 다른 편(9번)으로 같은 요청. 이번에는 리뷰 단계에서 뭔가 이상했습니다. 리뷰 결과가 이전 13번의 리뷰 파일을 참고하고 있었습니다. 알고 보니 리뷰 파일 이름이 겹쳐서, 이전 결과 위에 덮어썼다가 다시 읽어오는 이상한 상황이 발생한 것이었습니다.

세 번째 시도: 파일명에 번호를 반드시 포함하도록 규칙을 수정한 뒤 재시도. 이번에는 잘 흘러갔습니다.

네 번째 시도: 초안이 훨씬 짧은 편(15번의 미완성 초고)을 던졌습니다. 이번에는 태그 추출 단계에서 태그가 3개만 나왔습니다. 원고가 짧아서 개념 추출이 부족했던 것이었습니다. 스킬에 "최소 태그 개수를 확보하지 못하면 사용자에게 알려주기"를 추가했습니다.

즉, 처음 만든 파이프라인은 이상적인 상황에서만 작동했습니다. 실제로 굴려보니 몇 가지 예외 상황이 계속 튀어나왔고, 하나씩 수정해가면서 서서히 안정됐습니다.

💭 헤맨 지점을 정직하게 남기면

첫 자동화를 하며 저는 이런 것들에 헤맸습니다.

첫째, 사용자 확인 단계를 처음엔 뺐다가 크게 후회했습니다. "한 번에 다 해달라"고 하니 처음에는 쭉 흘러가는 게 좋아 보였습니다. 그런데 리뷰가 잘못된 것을 그대로 반영하고, 태그가 이상해도 그대로 발행되는 일이 벌어졌습니다. 자동화는 완전 자동일 필요 없이, 몇 개의 확인 지점을 명시적으로 두는 게 더 안전합니다. 저는 "리뷰 후 확인", "발행 직전 확인" 두 지점을 넣었습니다.

둘째, 파일 이름과 폴더 구조를 미리 정하지 않아 낭패를 봤습니다. 각 스킬이 결과를 어디에 어떤 이름으로 저장할지 미리 안 정했더니, 서로가 서로의 결과를 못 찾거나 덮어쓰는 일이 잦았습니다. 파이프라인 시작 전에 파일과 폴더 규칙을 종이에 그려두는 것이 핵심이었습니다.

셋째, 각 스킬은 독립적으로 잘 작동해도, 조합에서는 예외가 나옵니다. blog-review 스킬은 잘 굴러가고, tag-extractor도 잘 굴러갔는데 두 개를 붙였을 때 tag-extractor가 blog-review의 결과 파일을 읽어야 하는데 그 파일이 아직 저장 중이면 실패하는 경우가 있었습니다. 조합에서만 나오는 문제는 실전에서 굴리기 전까지 예측하기 어렵습니다.

📊 시행착오를 표로

몇 주 굴리면서 겪은 시행착오와 그 대응을 표로 정리해봤습니다.

문제 원인 대응

리뷰가 다른 편 결과에 오염	파일명 겹침	파일명에 편 번호 필수 포함
태그 3개만 추출	원고가 너무 짧음	최소 개수 미달 시 알림
잘못된 리뷰가 자동 반영	사용자 확인 부재	리뷰 후 확인 지점 추가
두 스킬 사이 파일 못 찾음	저장 완료 전 읽기	완료 확인 로직 추가
노션 발행 실패 시 재시도 없음	예외 처리 부재	3회 재시도 + 실패 리포트

이 표는 지금도 계속 늘어가고 있습니다. 아직 완성된 파이프라인은 아니지만, 하나씩 안정화되어 가는 재미가 있습니다.

🔗 시즌 2 개념들과의 연결

이 편은 시즌 2에서 다룬 여러 개념이 실제로 한 자리에 모이는 지점입니다.

• 시즌 2-1편의 skill.md: 파이프라인의 재료로 여러 스킬이 실제로 조합됨
• 시즌 2-3편의 AI 에이전트: 스스로 여러 단계를 실행하는 실행자의 감각
• 시즌 2-4편의 컨텍스트 엔지니어링: 각 스킬이 자기 자리에서 컨텍스트를 물려받고 물려주는 흐름
• 시즌 2-5편의 MCP: 노션 커넥터가 실제 발행 단계에서 큰 역할을 함

즉, 시즌 2 초반부터 쌓아온 개념들이 이 편에서 손에 잡히는 결과물이 됩니다.

💭 첫 자동화에서 얻은 세 가지 감각

첫째, 자동화의 시작은 종이 스케치입니다. 코드부터 짜지 말고 흐름을 먼저 그려야 합니다. 저는 노트 하나에 순서와 파일 경로, 각 단계의 확인 지점을 다 그린 다음에야 실제 파일을 만들기 시작했습니다.

둘째, 완전 자동보다 안전한 반자동이 낫습니다. 몇 개의 사용자 확인 지점을 두면 실수를 크게 줄일 수 있습니다. 이 확인 지점은 자동화의 실패가 아니라 자동화의 신뢰를 만드는 장치였습니다.

셋째, 첫 파이프라인은 완벽할 수 없습니다. 실전에서 굴리면서 예외를 하나씩 잡아나가야 합니다. 이 과정 자체가 자동화의 진짜 학습이었습니다.

🎯 Technical Writer와 DevRel 관점에서

첫 자동화 파이프라인을 만들면서 저는 재미있는 사실을 발견했습니다. 파이프라인 설계는 결국 프로세스 설계와 같다는 것입니다.

Technical Writer는 팀의 프로세스를 문서로 정리하는 일을 자주 합니다. 회의록 작성 규칙, PR 리뷰 절차, 사고 대응 매뉴얼. 이런 것들이 결국 사람이 밟는 워크플로거든요. 그 감각을 그대로 AI 워크플로에 옮기면, 예상보다 잘 통합니다.

DevRel의 자리에서 보면, 팀의 반복 업무마다 잘 설계된 파이프라인이 하나씩 있는 시대가 오고 있습니다. 그 파이프라인을 잘 설계하고, 문서화하고, 팀에 전파할 수 있는 사람의 자리가 커집니다. 저의 관찰로는 이 자리가 앞으로 5년 안에 상당히 뚜렷하게 등장할 것 같습니다.

📌 정리

• 자동화 워크플로란: 여러 스킬과 도구를 순서대로 엮어 한 번의 요청으로 여러 단계를 실행하는 파이프라인
• 오늘 만든 것: 블로그 원고 자동 발행 파이프라인 (리뷰 → 반영 → 태그 → 발행)
• 재료: 세 개의 skill.md + 노션 커넥터
• 핵심 설계 원칙: 종이 스케치 먼저, 파일 규칙 미리 정하기, 확인 지점을 명시적으로 두기
• 실전에서 얻은 것: 완전 자동보다 안전한 반자동, 조합에서 나오는 예외에 대한 대비, 시행착오 표 축적
• 문서 관점: 파이프라인 설계는 프로세스 설계와 같다. Technical Writer 감각이 강하게 적용

다음 글에서는 이 자동화 감각을 조금 더 개인 실용성 쪽으로 옮겨보려 합니다. 요즘 이력서를 다듬을 때가 많은데, AI로 5분 만에 이력서를 다듬는 실용 워크플로를 정리해서 나눠보겠습니다.

읽어주셔서 감사합니다.

---

TAG: #자동화워크플로 #AI자동화 #skillmd #파이프라인 #워크플로설계 #DevRel준비 #DocsToDevRel #TechnicalWriter #비전공자 #AI실전