[AX 사례] “이거 니가 알아서 못해?” — 베스트사례 수동 큐레이션 발행을 AI 비서 스킬로 옮겼습니다

[AX 사례] “이거 니가 알아서 못해?” — 베스트사례 수동 큐레이션 발행을 AI 비서 스킬로 옮겼습니다

📝 한줄 요약

입사 후 인수인계중 지피터스 공식 홈페이지의 베스트 사례 큐레이션 게시판이 23기 2주차 이후 업데이트가 되있지 않은 걸 발견한 후 담당 PM이 매주 손으로 하던 30분짜리 발행 작업을 명령어 한 줄로 5초 만에 끝나는 재사용 스킬로 옮겼습니다.

바쁘시면 이것만 읽어도 돼요

• 자동화가 고장 나서 게시판에 구멍이 난 게 아니었습니다. 자동화가 시작되기 전에 사람이 해줘야 하는 단계가 안 돌아서 구멍이 났습니다.

• 데이터의 진실 소스는 Airtable 테이블 전체가 아니라 「🔒 베스트URL」이라는 뷰 하나였습니다. 이 뷰에 안 들어온 사례는 자동화가 아무리 잘 돌아도 절대 게시되지 않습니다.

• 그 뷰는 현재 주차만 담고 지나가는 롤링 뷰였습니다. 3주차를 뒤늦게 채우려 하니 뷰 기준으로는 0건이 나왔고, 뷰를 우회하니 21건이 나왔습니다.

• 중복 발행은 "dry-run 먼저 돌리기"라는 운영 습관이 아니라 코드 안의 중복 검사 가드로 막았습니다.

• 결과: 23기 3주차·4주차 각 21건을 3개 카테고리로 나눠 게시글 6개를 스킬로 발행했습니다. 실행 시간은 각 5초입니다.

🎯 이런 분들께 도움돼요

• 예전에 만들어둔 자동화가 어느새 안 돌고 있는데, 왜 멈췄는지 아무도 설명하지 못하는 팀

• "이건 담당자만 할 수 있는 일"이 팀에 몇 개씩 쌓여 있는 운영 담당자

• AI에게 기존 워크플로 이관을 시켜보려는데, 코드만 옮겨서는 안 될 것 같은 분

😫 문제 상황 (Before)

제가 지피터스 공홈의 큐레이션 게시판을 열어봤을 때 눈에 걸린 건 빈 칸이었습니다. 23기가 막 종료된 시점인데 베스트 사례 큐레이션이 2주차까지만 올라와 있었습니다.

그래서 뽀짝이(팀 AI 운영 비서)에게 먼저 이유부터 물었습니다.

진저 (08:46): 짝아! 지피터스 공홈에 베스트 사례 큐레이션있잖아
              23기 클로징도 끝났는데 23기는 왜 아직도 2주차만 있어?

돌아온 답을 요약하면 이렇습니다. 이 작업에는 원래 n8n 워크플로가 있었습니다. 2025년 2월에 만들어졌고, 2026년 1월에 마지막으로 손을 댄 뒤 비활성 상태로 멈춰 있었습니다. 그래서 실제로는 담당 PM이 매주 베스트발표회가 끝날 때마다 선발된 사례를 카테고리별로 나누고, 요약을 정리해 게시글로 직접 올리고 있었습니다. 한 번에 30분이 넘게 걸리는 작업이었습니다.

여기서 제가 던진 질문이 이 일의 방향을 바꿨습니다.

진저 (11:16): 짝아 이거 니가 알아서 못해?
진저 (11:16): 무조건 수동인거야? 스킬로 자동화하자.

🛠️ 사용한 도구

• 뽀짝이 — Claude Code 기반 AI 운영 비서. 기존 워크플로 분석, 스킬 작성, 실행, 검증을 담당

• n8n — 새로 만들 대상이 아니라, 먼저 해독해야 할 분석 대상

• Airtable — 베스트 사례 데이터 소스

• Bettermode — 완성된 큐레이션 게시글의 발행 대상

🔧 작업 과정

1. 새로 만들기 전에, 멈춰 있는 워크플로부터 해독했습니다

가장 먼저 시킨 일은 코드 작성이 아니라 복원이었습니다. 비활성 n8n 워크플로의 내부 노드를 열어 데이터 흐름을 되짚게 했습니다.

뽀짝이가 추출해낸 건 이런 것들입니다.

• Airtable에서 데이터를 불러오는 조회 조건

• 사례를 카테고리별로 나누는 기준

• 요약 마크다운을 게시용 HTML로 바꾸는 방식

• 게시할 때 쓰는 게시판·작성자·게시글 타입 파라미터

• 최종 게시글의 제목 형식과 본문 구조

이 단계를 거치자 "예전에 자동화가 있었다더라"는 막연한 상태에서 어떤 입력이 어떤 변환을 거쳐 어디로 게시되는지 문장으로 설명할 수 있는 상태로 바뀌었습니다. 이게 없었으면 그다음 단계가 전부 추측이 됐을 겁니다.

2. 진짜 데이터 소스는 테이블이 아니라 ‘뷰’ 하나였습니다

코드보다 중요했던 건 실제 데이터가 어디서 오는가였습니다. 23기 데이터로 Airtable 조회 결과와 n8n의 조회 조건을 맞춰보니, 핵심이 하나 튀어나왔습니다.

큐레이션의 진실 소스는 설문 테이블 전체가 아니라 「🔒 베스트URL」 뷰입니다.

베스트발표회에서 사례가 아무리 잘 선발됐어도, 이 뷰에 데이터가 채워져 있지 않으면 자동화 결과에는 한 건도 포함되지 않습니다. 반대로 이 뷰에 들어온 사례만 큐레이션 대상이 됩니다.

이 사실 하나로 제가 처음 던졌던 질문 두 개가 동시에 풀렸습니다.

• 22기에 큐레이션 게시글이 왜 하나도 없었나 → 그 기수에는 뷰를 채우는 단계가 운영되지 않았습니다.

• 23기가 왜 2주차까지만 있었나 → 뷰가 채워진 주차만 게시됐고, 나머지 주차는 워크플로를 수동으로 실행하지 않았습니다.

자동화가 실패한 게 아니라, 자동화가 의존하는 선행 작업이 운영되지 않았던 것입니다.

3. n8n 로직을 재사용 가능한 스킬로 옮겼습니다

데이터 흐름을 확인한 뒤, n8n 코드 노드의 로직을 실행 스크립트로 옮겼습니다. 스킬은 이 순서로 동작합니다.

1. 요청받은 기수와 주차로 Airtable 설문 데이터를 조회합니다.

2. 「🔒 베스트URL」 뷰에 등록된 사례만 가져옵니다.

3. 각 설문 응답에 연결된 게시글에서 제목·닉네임·태그·URL·요약본·카테고리를 끌어옵니다.

4. 카테고리별로 묶고, 기존 큐레이션과 같은 형식의 HTML을 만듭니다.

5. 카테고리별 게시글을 Bettermode에 발행합니다.

운영자가 게시판 ID나 데이터 구조를 하나도 몰라도 되게, 입력은 기수와 주차 두 개로만 받게 했습니다. 슬랙에서 “뽀짝아 23기 4주차 베스트 사례 큐레이션 올려줘” 한 마디면 끝나는 형태입니다.

원본의 세부 동작도 일부러 그대로 살렸습니다. 예를 들어 각 사례 요약본에서 ### 시행착오 섹션부터는 큐레이션에 넣지 않는데, 이건 n8n 원본이 하던 방식이라 결과물이 기존 발행본과 달라지지 않도록 유지했습니다.

4. 실제 데이터로 기존 결과와 대조했습니다

자동화는 "코드가 돌아간다"만으로는 끝난 게 아닙니다. 기존 운영 결과와 같은 형태의 결과물을 만드는지까지 확인해야 했습니다.

그래서 게시하지 않고 HTML만 만들어보는 dry-run 모드를 먼저 넣고, 23기 4주차 실제 데이터로 돌렸습니다.

• 조회된 사례: 21건

• 카테고리: 3개 (개발&에이전트 / 업무&비즈니스 / 콘텐츠&지식), 각 7건씩

• 결과물: 카테고리별 HTML 게시글 3건

생성된 HTML을 기존 발행본과 나란히 놓고 제목 형식, 사례 배열 순서, 링크, 본문 구조가 같은지 확인했습니다.

5. 중복 발행을 '조심하기’가 아니라 '코드’로 막았습니다

이 시점에 제가 받은 초안에는 이런 문장이 있었습니다. “같은 기수와 주차를 두 번 실행하면 게시글도 두 세트가 만들어집니다. 그러니 dry-run을 먼저 돌리는 것을 운영 원칙으로 둡니다.”

그런데 이건 위험을 사람 주의력에 떠넘기는 방식입니다. 한 번 잘못 실행하면 운영자가 중복 게시글을 직접 찾아 지워야 합니다. 그래서 스킬에 중복 검사 가드를 추가했습니다.

• 발행 직전에 같은 게시판에서 동일한 제목의 게시글이 이미 있는지 검사합니다.

• 이미 있으면 그 카테고리는 발행하지 않고 건너뛰며, 실행이 끝날 때 "🚨 중복 감지"로 알려줍니다.

• 의도적으로 다시 올려야 할 때만 --force 옵션으로 통과시킵니다.

이건 n8n 원본에는 없던 안전장치입니다. 덕분에 같은 주차를 실수로 두 번 돌려도 중복 게시글이 자동으로 생기지 않습니다.

여기서 작은 삽질이 하나 있었습니다. 기존 게시글 목록을 가져오는 도구가 검색어를 서버에 넘기지 않고 게시판 전체를 통째로 반환했습니다. 수 MB짜리 응답이 버퍼를 넘겨서 조회가 실패했고, 받는 쪽 버퍼를 키운 뒤 제목을 로컬에서 대조하는 방식으로 우회했습니다. 별것 아닌 문제 같지만, "검색 옵션이 있으니 서버가 걸러주겠지"라고 믿었으면 조용히 중복 검사가 통과됐을 지점이었습니다.

6. 그리고 진짜 함정이 마지막에 나왔습니다 — 뷰는 롤링이었습니다

4주차는 잘 돌았습니다. 그런데 3주차를 돌리자 이렇게 나왔습니다.

⚠️ 23기 3주차에 해당하는 베스트 사례가 뷰(🔒 베스트URL)에 없어요.

「🔒 베스트URL」 뷰는 아카이브가 아니라 현재 주차만 담고 지나가는 롤링 뷰였습니다. 3주차 사례들은 데이터로는 멀쩡히 살아 있는데, 뷰에서는 이미 밀려나 있었던 겁니다. 즉 이 스킬은 당주차에는 완벽하게 동작하지만, 지난 주차 백필은 구조적으로 불가능한 상태였습니다.

그래서 뷰를 무시하고 테이블 전체에서 (주차 + 기수)로 직접 조회하는 --view none 옵션을 추가했습니다. 같은 3주차를 다시 조회한 결과는 이렇게 갈렸습니다.

같은 데이터, 같은 주차인데 조회 경로 하나 때문에 0과 21이 갈렸습니다. 이 옵션이 없었으면 저는 3주차를 결국 손으로 올렸을 겁니다.

✅ 결과 (After)

3·4주차를 손으로 먼저 올리고 스킬을 나중에 만드는 대신, 스킬을 먼저 만들고 그 스킬로 발행했습니다. 실제로 그날 발행된 게시글 6개는 전부 이 스킬이 만든 것입니다.

이번에 실제로 발행한 것: 23기 3주차 21건, 4주차 21건 → 카테고리별로 나눠 게시글 총 6개.

시간 절감보다 더 크게 바뀐 건 이겁니다. 큐레이션 게시판에 구멍이 생겼을 때, 이제는 "누가 안 했지?"가 아니라 "뷰가 안 채워졌구나"라고 원인을 지목할 수 있게 됐습니다.

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. 코드 이관을 시키기 전에 "이 자동화가 왜 멈췄는지"부터 물었습니다. 이 질문이 없었으면 잘 돌아가는 스킬을 만들어놓고도 뷰가 비어 있어서 여전히 결과가 0건인 상태가 됐을 겁니다.

2. 실제 데이터로 기존 결과물과 대조하게 했습니다. "실행됩니다"는 완료가 아닙니다. 기존 발행본과 같은 결과가 나오는지가 완료입니다.

3. 위험을 운영 규칙 대신 코드에 넣게 했습니다. "두 번 돌리지 않도록 조심하세요"는 언젠가 깨집니다. 중복 검사는 안 깨집니다.

4. 초안에 남은 틀린 문장을 나중에 수정했습니다. 이 글의 초안에는 "이 스킬은 멱등하지 않다"고 쓰여 있었습니다. 초안을 받은 시점에는 맞는 말이었지만, 그 뒤에 중복 가드를 넣으면서 사실이 아니게 됐습니다. 작업이 진행되면 문서도 같이 낡습니다.

이렇게 하면 안 돼요

1. "자동화가 있다"는 말을 그대로 믿지 마세요. 활성 상태인지, 마지막으로 언제 돌았는지 먼저 확인하세요. 이 워크플로는 1년 넘게 비활성이었는데도 "자동화되어 있는 작업"으로 인식되고 있었습니다.

2. 테이블을 데이터 소스라고 단정하지 마세요. 실제 기준이 뷰·필터·특정 컬럼일 수 있고, 그 뷰가 롤링이면 어제 되던 조회가 오늘 0건이 됩니다.

3. 급한 불부터 손으로 끄고 자동화는 나중에, 로 미루지 마세요. 이번엔 손으로 올리는 대신 스킬을 먼저 만들었고, 결과적으로 같은 날 6개를 발행하면서 도구까지 남았습니다.

🌍 다른 업무에 적용한다면?

이 패턴은 큐레이션 발행에만 해당하지 않습니다. “예전에 자동화했는데 지금은 안 돌아요”라고 말하는 모든 업무에 그대로 적용됩니다.

1. 그 자동화가 지금 활성 상태인지 확인합니다.

2. 그 자동화가 어떤 데이터를 최종 기준으로 삼는지 한 문장으로 적어봅니다. 못 적으면 그게 진짜 문제입니다.

3. 그 데이터를 사람이 채워야 하는지 확인하고, 채우는 단계를 운영 체크리스트에 넣습니다.

4. 그다음에 코드를 옮깁니다.

순서를 뒤집으면 잘 만든 자동화를 켜놓고도 결과가 비어 있는 상황이 반복됩니다.

🚀 앞으로의 계획

• 선행 단계까지 자동으로 챙기기 — 베스트발표회가 끝난 뒤 「🔒 베스트URL」 뷰가 비어 있으면 운영팀에 먼저 알리게 만들 예정입니다. 지금은 스킬을 실행해야만 비었다는 걸 알 수 있습니다.

• 중복 감지 시 선택지 넓히기 — 지금은 같은 제목이 있으면 건너뛰기만 합니다. 여기에 “기존 게시글을 업데이트” 선택지를 더하면, 사례가 뒤늦게 추가됐을 때도 대응할 수 있습니다.

• 주차 종료 후 자동 실행 — 뷰가 채워진 것이 확인되면 사람이 부르지 않아도 돌게 하는 게 최종 목표입니다.

📋 재사용 가능한 프롬프트

프롬프트 1: 멈춰 있는 자동화 해독하기

아래 [n8n 워크플로 / 스크립트 / 자동화 도구]를 새로 만들지 말고, 지금 어떻게 동작하도록 설계돼 있는지 먼저 복원해줘. 다음 4가지를 각각 분리해서 알려줘.

1. 데이터를 어디에서, 어떤 조건으로 가져오는가 (테이블 이름이 아니라 실제 필터·뷰까지)

2. 가져온 데이터가 어떤 변환을 거치는가

3. 최종 결과물이 어디로, 어떤 형식으로 나가는가

4. 사람이 미리 해둬야만 이게 동작하는 선행 작업이 있는가

[워크플로 링크 또는 경로]는 여기 있어.

프롬프트 2: 이관 전 진실 소스 검증하기

방금 파악한 데이터 흐름을 실제 데이터로 검증해줘. [기수/기간/조건]으로 조회했을 때:

• 몇 건이 나오는가

• 그 건수가 기존 결과물의 건수와 일치하는가

• 일치하지 않으면 어느 조건에서 갈라지는가

그리고 이 조회 조건이 시간이 지나도 같은 결과를 주는지 확인해줘. 뷰나 필터가 최근 데이터만 담는 구조라면 지난 기간 조회는 실패할 텐데, 그 경우 우회 방법도 같이 제안해줘.

프롬프트 3: 반복 실행 안전장치 넣기

이 스킬을 같은 조건으로 두 번 실행하면 어떤 일이 생기는지 확인하고, 문제가 생긴다면 운영 규칙이 아니라 코드로 막아줘.

• 이미 처리된 건인지 판별할 기준(제목·ID·날짜 등)을 정하고

• 중복이면 기본적으로 건너뛰되

• 의도적 재실행은 명시적 옵션으로만 통과시켜줘

"조심해서 실행하세요"라는 안내는 해결책으로 치지 않아.