교육 사업을 하다 보면 기업 인바운드 문의가 불쑥불쑥 들어와요. 그런데 바쁘면 그걸 깜빡하고 놓칠 때가 있습니다. "아, 그 문의 답을 안 했네…" 하는 순간이요. 이번에 로나(Rona) 실습으로 Claude Code와 함께 문의가 들어오면 놓치지 않고 슬랙으로 알려주는 자동 루프를 설계했는데, 단순 알림 자동화가 아니라 "제대로 작동하는지 검증까지 되는" 루프로 만든 게 핵심이었어요. 그 과정과, 로나로 실습한 솔직 후기까지 공유합니다.
1. "알림만 오면 좋겠다"에서 시작했어요
인바운드 문의는 저희 쪽 Airtable로 접수돼요. 문제는 제가 바쁠 때 그걸 못 보고 지나친다는 것. 그래서 처음 요청은 단순했어요.
인바운드 문의가 들어오면 슬랙으로 나한테 알려줘.
못 보고 놓치는 걸 막고 싶어.그런데 막상 "알림 자동화"를 제대로 만들려면, 먼저 답해야 할 게 있었어요. "무엇을 합격으로 칠 것인가?" 알림이 그냥 오기만 하면 되는 게 아니거든요.
2. "알맞게 오면 됨" 같은 애매한 기준은 버렸어요
처음엔 저도 "내용이 알맞게 오면 합격"이라고 생각했어요. 그런데 이 "알맞게"가 함정이더라고요. 오늘의 '알맞게'와 다음 주의 '알맞게'가 다르면, 루프가 좋아진 건지 그냥 그날 기분인지 구분이 안 돼요.
그래서 "됐다 / 안 됐다"로 딱 갈리는 질문으로 바꿨습니다.
- 알림이 실제로 왔는가?
- 접수 내용(회사·연락처·문의내용 등)이 빠짐없이 담겼는가?
- 항목별로 구분되게 왔는가?
애매한 점수제("이 정도면 괜찮은 듯") 대신, 누가 봐도 같은 답이 나오는 기준으로요.
3. 진짜 배움 — "잘 될 때" 말고 "실패하는 순간"을 봤어요
여기서 결정적인 전환이 있었어요. 처음 기준은 사실 일이 잘 풀리는 경우(1건 오면 1건 알림)만 본 거였어요. 그런데 현실은 그 경계에서 새더라고요.
새 문의 1건 → 알림이 0건 (= 놓침)
새 문의 1건 → 알림이 2건 넘게 (= 중복, 신뢰 붕괴)제가 애초에 이 루프를 원한 이유가 "놓쳐서"였잖아요. 그래서 합격 기준을 "새 문의 1건당 알림 정확히 1건 (놓침 0, 중복 0)"으로 조이고, 같은 문의가 두 번 들어와도 알림은 한 번만 가게 하는 로직을 넣었어요. 자동화에서 진짜 무서운 건 "품질"이 아니라 신뢰성이라는 걸 여기서 배웠습니다.
4. 만드는 쪽과 채점하는 쪽을 갈라놨어요
또 하나 배운 것. 만든 놈이 스스로 채점하면 안 된다는 거예요. 같은 쪽이 만들고 채점하면 무의식적으로 기준을 슬쩍 낮춰서, 개선인지 기준 완화인지 흐려지거든요. 그래서 "메시지를 만드는 부분"과 "합격 여부를 채점하는 부분"을 분리하고, 채점 기준은 만드는 쪽이 못 건드리게 잠갔어요.
5. 말로 안 하고, 실제로 한 바퀴 돌려봤어요
가장 중요한 건 이거예요. "이렇게 하면 되겠죠"로 끝내지 않고, 실제 문의 1건을 넣어 진짜로 돌려봤어요. 각본 없이 채점기가 직접 판정하게 두고요.
[1] 실제 문의 → 3개 기준 전부 통과 → 합격 (알림 생성)
[2] 같은 문의 재유입 → "이미 보냈음" 감지 → 중복 차단 ✅
[3] 연락처 빈 문의 → 완전성 미달 → 차단 ✅중복도, 누락도 제가 시키지 않았는데 채점기가 알아서 걸러냈어요. 이 순간이 "아, 이게 진짜 도는구나" 싶었습니다.
결과
Before After
─────────────────────────────────────────────────────
문의 대응 시작 가끔 놓침 / 수동 확인 → 놓침·중복 0 자동 알림
품질 확신 "괜찮겠지" (느낌) → 기준으로 검증됨 (증거)
확장 매번 사람이 챙김 → 루프가 알아서 돎단순히 시간을 아낀 게 아니라, "놓칠까 봐 신경 쓰던 부담" 자체가 사라진 게 제일 컸어요.
이 루프, '로나(Rona)'로 만들었어요 — 솔직 후기
이번 작업은 로나(Rona)라는 실습 도구로 진행했어요. AI를 실제 업무에 직접 써보도록 이끌어주는 도구인데, 만들면서 느낀 점을 인터뷰 형식으로 솔직하게 남겨둡니다.
사용자 인터뷰 — 첫 번째 타자: 이재혁 님
좋았던 점
- 방향·가이드를 잡아주는 점. 초보에겐 그런 가이드가 있다는 것만으로 심적 안정감이 들고, 학습에 몰입하게 되는 효과가 있었어요.
아쉬웠던 점 · 이랬으면 좋겠다
- 실습보다 설명이 많아 피로했어요. 저는 실행(메이킹) 위주가 더 맞더라고요. (지난주 로나는 메이킹에 포커스했는데, 이번 주는 설명이 많았어요.)
- 기준을 설명하는 예시가 중간에 나와 타이밍이 애매했어요. 흐름을 놓치게 되던데, 차라리 처음 설명 단계에서 바로 나왔으면 좋았을 것 같아요.
- "이해했으면 답해봐" 식의 역질문이 애매했어요. 놓친 부분은 예시·부연으로 바로 짚어주고, 그다음 사용자가 고치게 하는 편이 낫다고 느꼈어요.
- 난이도가 좀 쉽게 느껴졌어요. 스킬이 사용자 수준(초보/고수)을 파악해 난이도를 분리하면 좋겠어요. 고수라면 개념 설명을 하나씩 말고 두세 개씩 묶어서 진행해도 될 것 같고요.
제안 — 학습은 3단 구조가 좋아요
프롤로그(청사진) → 메인 디쉬(실습) → 에필로그(랩업)
"루프는 이런 거야, 직접 만들어보기 오늘 한 것 정리
이런 기준이 중요해"큰 그림(청사진)을 먼저 깔고, 본론은 실습으로, 마지막에 랩업. 이 흐름이 학 습에 제일 잘 붙더라고요. (누리 님과 로나를 함께 써보고 정리한 제안이에요.)
AI 활용 팁!
- 프롬프트를 길게 쓰기보다, "무엇이 합격인지"부터 정하세요. 그것도 '됐다/안 됐다' 이진으로요.
- 잘 되는 경우 말고, 실패하는 경계를 상상하세요. "0건이면? 2건이면?" — 거기에 진짜 리스크가 숨어 있어요.
- 만드는 역할과 채점하는 역할을 나누세요. 스스로 채점하면 기준이 슬그머니 느슨해집니다.
바로 쓸 수 있는 프롬프트
내가 매주 반복하는 [업무]를 자동으로 도는 루프로 만들고 싶어요. 아래 순서로 같이 설계해줘.
1) 이 일이 "합격"인지 판정하는 기준을, 애매한 점수 말고 '됐다/안 됐다'로 딱 갈리는 이진 질문으로 만들어줘.
2) 일이 잘 풀리는 경우 말고, 이 루프가 실패하는 경계(누락·중복·빈 값 등)를 찾아 기준에 추가해줘.
3) 만드는 역할과 채점하는 역할을 분리하고, 채점 기준은 못 바꾸게 잠가줘.
4) 마지막에 실제 예시 1건으로 한 바퀴 돌려서 잘 걸러내는지 검증해줘. (실제 발송 같은 되돌리기 어려운 건 내 승인 앞에서 멈추고)
※ [업무] 자리에 본인 반복 업무를 넣으세요.
