일을 시키는 스킬 그리고 일을 검사하는 스킬 — 규율에 QA 조항이 네 개 붙기까지

1. 처음 — 어느 날 도시가스 청구서 앞에서

나는 비개발자고, 코드는 못 쓴다. 업무 자동화는 클로드 코드로 만들고, 매일 반복되는 일은 n8n(자동화 흐름을 짜서 돌려주는 도구)이 서브 머신에서 24시간 돌린다. 짜여 있는 n8n 역시 클로드 코드가 만들어준 것이다.

그런데 그 파이프라인은 가끔 터진다. 그러면 오픈클로 에이전트가 텔레그램으로 "⚠️ 워크플로우 실패 알림"을 보내고, 나는 클로드 코드에게 "에러 떴어"라고 던진다. 문제는 그 다음이었다.

올해 4월, 도시가스 세금계산서 자동 수취가 실패했다. 클로드 코드는 에러 메시지 한 줄을 보더니 자신 있게 말했다: "청구서 사이트 로그인이 필요한 것 같습니다." 그럴듯했다. 고치게 했다. 또 실패했다. 다른 추측, 또 땜빵, 또 실패.

참다못해 내가 한 말이 그대로 기록에 남아 있다: "추론 그만, 실증해."

그제서야 클로드 코드가 실제 메일 본문을 열어보고, 실제 웹페이지 구조를 확인했다. 진짜 원인은 로그인이 아니었다 — 코드 안에 "// 실제 URL 확인 필요"라는 미완성 주석이 남아 있었고, 접속 주소 자체가 매번 메일 본문에서 새로 뽑아야 하는 구조였다. 추측으로는 영원히 못 찾을 원인이었다.

그날 깨달았다. 클로드 코드의 무서운 점은 틀리는 게 아니라, 확인 없이도 그럴듯한 답을 만들 수 있다는 것이다. 에러 문구가 로그인 얘기처럼 생겼으면 로그인을 고친다. 진짜 원인이 뭐든.

그래서 규율을 만들기 시작했다. 처음엔 조항이 두 개였고, 그 뒤로 사건이 터질 때마다 하나씩 붙었다. 아래는 그 규율이 석 달 동안 자란 기록이다.

2. 첫 번째 규칙 — 순서를 고정했다

그날 바로 만든 게 n8n-debug 스킬이다. 워크플로우 실패 얘기가 나오는 순간 에이전트에게 강제되는 규칙집인데, 핵심은 하나다. 순서를 고정하고, 건너뛰기를 막았다.

중요한 건 항목이 아니라 순서가 강제된다는 것이다. 첫 추측을 말하기 전에 실제 데이터와 코드 전문을 먼저 봐야 하니까, 적어도 "로그인일 것 같습니다" 같은 첫 추측이 그냥 통과되지는 않는다. 아는 척하지 말라고 부탁하는 게 아니라, 아는 척할 수 있는 경로를 없앤 것이다.

효과는 그 자리에서 나왔다. 며칠을 태우던 도시가스 건이 3단계에서 풀렸다. 실제 청구서 페이지를 열어보니 접속 주소가 메일마다 새로 발급되고 있었다. 코드에 주소를 박아두는 방식으로는 처음부터 될 수 없는 구조였다. 로그인 화면은 쳐다볼 필요도 없었다.

금지어 목록도 붙여뒀다. "아마 ~ 때문일 것" 같은 표현 사용 금지, 재실행을 나한테 시키기 금지(그것도 에이전트 몫) 같은 것들. 다만 굴려보니 그건 보조 장치였다. 말로 하는 금지는 새고, 순서로 막으면 안 샌다.

→ 규율 1조: 순서를 고정한다. 건너뛰기 없음.

3. 두 번째 규칙 — 잊지 못하게 했다

1조는 이번 사고를 푼다. 그런데 그걸로는 부족했다. 다음 달에 비슷한 게 터지면 에이전트는 오늘 세 시간 걸려 알아낸 걸 하나도 모르는 상태로 다시 시작한다. 대화가 끝나면 다 잊으니까. 절차는 완벽한데 경험이 0인 신입이 매일 새로 출근하는 셈이다.

그래서 5단계 중 4·5단계를 기록지에 걸었다. 워크플로우마다 문서 하나: 알려진 함정 / 과거 실패 이력 / 놓쳤던 단서 / 진짜 원인 / 예방책. 에이전트는 디버깅 전에 이걸 반드시 읽고, 끝나면 반드시 갱신한다.

처음엔 이걸 1조에 딸린 잔심부름으로 여겼다. "메모나 남겨두자" 정도. 따로 떼어 조항으로 올릴 부분이라는 건 석 달 굴리고 나서 알았다.

기록지는 세 순간에 일한다. 적을 때, 읽을 때, 그리고 너무 오래됐을 때.

① 적을 때 — 적으려니 확인하게 된다

도시가스는 그 뒤로도 한 번 더 터졌다. 이번엔 세금계산서 두 장 중 한 장만 처리된 것. 원인은 "들어온 항목 중 첫 번째만 처리하는 버그"였다. 두 장이 오면 한 장은 조용히 버려진다.

고친 다음이 중요했다. 기록지에 "놓쳤던 단서"를 적으려니 뭘 놓쳤는지 되짚어야 했고, 되짚다 보니 다른 업체 브랜치(업체별로 갈라지는 처리 갈래)까지 열어보게 됐다. 같은 버그가 세 곳에 전부 있었다.

그 세 곳은 그때까지 한 번도 실패한 적이 없었다. 아직 그 업체 계산서가 두 장 온 날이 없었을 뿐이다. 한 건이 터진 김에, 같은 결함 세 곳을 한 번에 고쳤다.

기록지를 읽어서 찾은 게 아니다. 쓰는 동작 자체가 점검을 시킨 것이다.

② 읽을 때 — 지난 실수가 이번 점검 목록이 된다

기록지엔 해결책만 적게 하지 않았다. "그때 뭘 못 봤는지"를 따로 적는 칸을 만들었다.

미완성 주석을 못 봄 / 추측으로 버튼 위치를 가정함 / 로그인 벽이라 단정하고 실제 응답을 확인 안 함

이게 쌓이자 기록지의 용도가 하나 늘었다. 점검 목록을 만드는 재료가 된 것이다. 맨 위의 "미완성 주석을 못 봄"은 그대로 규율 2단계의 검색 목록이 됐다 — 이제 코드를 읽을 때 // TODO, // 임시, // 나중에, // FIXME, 하드코딩을 반드시 훑는다. 정답을 기억하는 게 아니라 자기가 어디서 미끄러지는지를 기억하는 것. 나는 이 칸이 기록지에서 제일 값지다고 생각한다.

③ 오래됐을 때 — 낡은 정답에 유통기한을 붙인다

기록은 쌓이기만 하면 언젠가 독이 된다. 시스템 구조를 바꾸고 나면 과거의 정답이 새 구조에선 오답이 되기 때문이다.

그래서 이런 줄을 추가하게 했다 — "과거의 이 처방, 새 구조엔 적용하지 말 것." 해결책 옆에 유통기한을 써두는 셈이다. 이게 왜 필요한지는, 5장에서 아프게 확인하게 된다.

→ 규율 2조: 잊지 못하게 한다. 원인만이 아니라 놓쳤던 단서와 처방의 유효기간까지 남긴다.

4. 세 번째 규칙 — "성공"을 다시 정의했다

— 48일짜리 거짓말을 잡고 나서

매일 아침 업계 뉴스를 수집·요약해주는 파이프라인이 있었다. 몇 달째 실행 기록은 매일 "성공". 그런데 내 체감은 "이거 한 번도 제대로 된 적 없는데?"였다. 예전 같으면 에이전트는 실행 기록을 보고 "정상 작동 중입니다"라고 답했을 것이다. 실제로 성공이라고 찍혀 있으니까.

이번엔 규율대로 해부했다. 그러자 실체가 나왔다.

수집(n8n)은 매일 정상 저장되고 있었다(48일치가 쌓여 있었다). 그런데 요약을 맡은 에이전트가 이사 가기 전의 옛 폴더를 읽으라는 지시문을 갖고 있었다 — 매일 빈 폴더를 열고 "오늘은 뉴스 없음"이라 결론 내렸던 것. 심지어 그 에이전트의 "보고했습니다"도 거짓이 아니었는데, 보고가 흘러간 채널이 아무에게도 연결 안 된 로그 파일이었다. 성공 기록 48일 = 빈 폴더를 성공적으로 읽은 48일.

여기서 알았다. 문제는 파이프라인이 아니라 내가 쓰던 "성공"이라는 단어였다. 그래서 정의를 바꿔서 기록지 맨 위에 불변 조건으로 박았다:

"실행 성공 ≠ 일이 된 것." 검증은 체인으로: 실행됐나 → 파일이 실제로 도착했나 → 결과물이 생겼나 → 내용이 차 있나 → 나한테 도착했나.

그리고 정의만 바꾸면 또 잊을 게 뻔해서, 그 체인을 매일 대신 밟아주는 감시 파이프라인을 하나 더 만들었다. 매일 아침 8시 30분, 요약본이 실제로 만들어졌는지 확인하고 헤드라인과 기사 건수를 나한테 보낸다. 안 만들어졌거나 건수가 0이면 경고가 붙는다.

감시 장치를 하나 더 만든 게 요점이 아니다. 그럼 그 감시 장치는 또 누가 감시하나. 요점은 판정 지점을 시스템 안쪽에서 내 손끝으로 옮긴 것이다. 아침에 내 폰에 기사 몇 줄이 안 와 있으면 그날은 실패다. 그 판정에는 로그가 필요 없다.

뉴스 파이프라인 얘기로 들리겠지만, "매일 성공이라고 찍히는데 결과물은 비어 있다"는 자동화를 굴리는 사람이면 언젠가 반드시 만난다. 안 보는 곳에서 도는 게 늘어나는 순간부터.

→ 규율 3조: "성공"을 믿지 않는다. 끝까지 도착했는지 체인으로 확인한다.

5. 네 번째 규칙 — 알림부터 의심하게 했다

— 이 글을 다듬던 바로 그 주에

매달 두 번, 지출 증빙(인터넷·가스·관리비 청구서)을 자동 수집해 "도착/미비" 현황을 보내주는 파이프라인이 있다. 그날 아침 알림이 이랬다: "인터넷 미비. 도시가스 프로젝트 미분류." 문제는 내가 메일함에서 인터넷 청구서를 이미 봤다는 것. 몇 달째 반복되는 오탐이라 화가 난 상태로, 이번엔 힌트를 하나도 안 줬다. "내가 뭐가 문제인지 말 안 할게. 로그 보고 네가 찾아."

이번엔 시스템 로그가 아니라 메일함 실물부터 열었다. 그러자 원인이 한 겹이 아니라 세 겹으로 갈라졌다.

1. 메일은 전부 와 있었다. 인터넷 명세서 4회선이 다 도착해 있었는데, 하필 자동화 도구 자체가 엿새 동안 통째로 죽어 있던 주간(이 글에 다 담지 못한 또 다른 사건이다)과 겹쳐 처리가 누락됐고, 메일 감시 트리거(새 메일이 올 때만 깨어나는 감시 장치)는 지나간 메일을 소급하지 않는다. 죽어 있던 엿새치가 조용히 증발한 것.

2. 살아 있었어도 틀렸을 지뢰가 숨어 있었다. 명세서를 "휴대폰이냐 인터넷이냐"로 가르는 규칙이 휴대폰이라는 단어를 찾는 방식이었는데 — 알고 보니 모든 명세서 하단에 "※ 통신기기비: 전화기, 휴대폰 등 기기구입비"라는 안내 문구가 인쇄돼 있었다. 인터넷 청구서도 전부 휴대폰으로 오분류될 운명이었던 것.

3. "미분류" 알림의 정체는 좀비였다. 진짜 가스 청구서는 멀쩡히 분류돼 있었고, 알림에 뜬 건 한 달 전부터 방치된 가짜 파일(청구서가 아니라 "세금계산서 보기" 버튼만 있는 뷰어 안내 페이지)이 매 사이클 다시 걸려 나온 것이었다.

2번은 뼈아팠다. 그 규칙, 원래는 내가 시킨 수리였다. 그때는 맞는 처방이었다 — 실제로 휴대폰 명세서가 엉뚱한 폴더로 새고 있었으니까. 문제는 그 규칙이 그대로 살아남아, 몇 달 뒤 인터넷 청구서를 잡아먹기 시작했다는 것이다. 3장에서 말한 "유효기간 지난 처방"이 정확히 이거다. 어제의 해결책이 오늘의 버그가 되는 데는 아무 사건도 필요 없다. 그냥 시간만 지나면 된다.

세 겹이니 처방도 셋이었다.

• 증발한 4건 — 메일함에서 직접 찾아 소급 복구했다. 시스템이 못 하는 건 손으로 메웠다.

• 오분류 지뢰 — "휴대폰"이라는 단어로 가르던 조건을 걷어내고, 휴대폰 명세서에만 있는 표식으로 바꿨다. 인터넷 청구서가 잡아먹힐 일이 없어졌다.

• 좀비 파일 — 가짜 파일을 별도 보관함으로 치웠다. 매 사이클 되살아나던 유령 알림이 끊겼다.

오탐이 걷히자, 남은 게 진짜 미도착인지 구조 문제인지 구분할 수 있게 됐다. 이제야 "안 왔다"는 말을 믿을 수 있게 된 것이다.

그리고 여기서 규율이 네 번째로 자랐다. 이 디버깅에서 손으로 밟은 절차 — 알림을 의심하고 → 메일함 실물과 대조하고 → 누락이면 소급 복구하고 → 재실행으로 검증하는 — 를 그대로 새 스킬("증빙대사")로 굳혔다. 다음에 같은 알림이 오면 나는 "대사해봐" 한마디면 된다. 규율 스킬이 원인을 잡고, 잡힌 원인이 기능 스킬을 낳는 순환이 처음으로 한 바퀴 돌았다.

→ 규율 4조: 알림부터 의심한다. 시스템 말고 실물을 먼저 대조한다.

6. 지금 이 규율은 이렇게 생겼다

석 달, 네 번의 사건. 규율은 이만큼 자랐다.

1조 순서를 고정한다 — 데이터 → 코드 → 실물 → 이력 → 기록. 건너뛰기 없음.

2조 잊지 못하게 한다 — 원인만이 아니라 놓쳤던 단서와 처방의 유효기간까지.

3조 "성공"을 믿지 않는다 — 실행됐나 → 도착했나 → 생겼나 → 차 있나 → 나한테 왔나.

4조 알림부터 의심한다 — 시스템 말고 실물을 먼저 대조한다.

그리고 창고엔 이만큼 쌓였다. 워크플로우별 기록지 10개, 실패 이력 20건, 알려진 함정 30개. 코드는 한 줄도 내가 안 썼다. 그런데 내 시스템에서 제일 값진 자산은 코드가 아니라 저 30개다.

남는 생각 셋.

1. 에이전트의 최대 리스크는 오답이 아니라 '근거 없는 정답 톤'이다. 그리고 이건 모델 성능 문제가 아니라 절차 문제라서, 절차로 고칠 수 있다. 스킬로 만들어두면 매번 잔소리할 필요도 없다.

2. 비개발자일수록 규율이 먼저다. 나는 에이전트가 내놓는 원인 분석의 진위를 코드 실력으로 가릴 수 없다. 그래서 더더욱, 에이전트가 증거 없이는 말 못 하게 만드는 구조가 내 안전벨트였다.

3. 규율 스킬은 기능 스킬의 어머니다. 디버깅에서 손으로 반복한 절차가 곧 다음 스킬의 설계도였다. 스킬을 뭘 만들지 모르겠다면, 최근에 화났던 디버깅을 복기하면 된다.

스킬은 결국 나의 파이프라인을 고정시켜서 결과값을 안정적으로 나오게 하는 기능이라고 생각한다. 제일 잘 만든 스킬은 워크플로우만 잘 따르는 스킬이 아니라, QC가 가능한 스킬이라고 생각한다.