반복은 n8n에게, 판단은 스킬에게 — 지출결의서 업무를 손과 뇌로 나눴더니 (베스트 발표 ver)

자동화를 3층으로 쌓으면서 배운 것 — 적어두는 것과 강제되는 것은 다른 일이었습니다

(비개발자 · 코드는 한 줄도 못 씁니다)

1. 하려던 일

제 업무 중에 지출결의서가 있습니다. 나갈 돈을 증빙과 함께 정리해서 매달 정해진 날에 품의를 올리는 일입니다. 프로젝트를 다섯 개 이상 맡고 있어서 출금건이 한 달에 수십 건, 많으면 수백 건입니다.

이 일이 성가신 이유는 양이 아니라 증빙이 다 제각각으로 생겼다는 데 있습니다.

양식도 다르고 꺼내는 방법도 다르고, 제시간에 안 오는 것도 있습니다. 그걸 하나하나 열어서 저장하고, 분류하고, 엑셀에 금액 넣고, 대조하고, 압축해서 올립니다. 사람이 하면 짧게는 이틀, 길게는 사나흘씩 걸립니다.

2. 코드를 못 쓰니까, 대신 아주 길게 적었습니다

자동화 도구를 저는 짤 줄 모릅니다. 그래서 제가 아는 걸 전부 말로 적는 방식을 택했습니다. 워크플로우를 A부터 Z까지 자연어로 쓰고, 그걸 에이전트에게 정리시킨 다음, 클로드 코드에게 그대로 넘겨서 만들게 했습니다.

지출결의서 것만 워드 13페이지가 나왔습니다. 코드는 한 줄도 없습니다. 전부 제 업무의 워크플로우입니다.

시행착오와 해결법까지 꼼꼼하게 적었습니다.

그런데 검증기를 안 만들었습니다.

3. 그리고 제가 쓴 그 문장대로 당했습니다

두 층까지는 잘 굴러갔습니다.

• 1층 · 수집 — 메일 받고, 보안메일 풀고, 웹 청구서는 브라우저로 열어 PDF로 저장

• 2층 · 정리 — 항목별로 분류하고 프로젝트별로 묶어서 현황 보고

여기까지 만들고 저는 끝난 줄 알았습니다. 그런데 사고가 계속 났습니다.

• 증빙이 두 개 필요한 자리에 한 개만 넣어놓고 "완료"라고 보고

• 키워드가 잘못 걸려서 엉뚱한 폴더에 넣어놓고 "다 됐다"고 보고

• 메일이 분명히 왔는데 "안 왔다"고 보고

공통점이 있습니다. 전부 시스템은 "완료"라고 말하고 있었고, 제가 실물을 열어봤더니 아니었습니다.

제일 컸던 건 엿새짜리였습니다

어느 날 서버에서 자동 업데이트가 하나 돌았습니다. 제가 시킨 게 아닙니다. 그 여파로 자동화 도구가 통째로 못 돌게 됐습니다.

문제는 그다음입니다. 그걸 엿새 동안 몰랐습니다.

왜냐면 — 실패하면 알려주는 알림도 그 도구 안에 들어 있었거든요. 시스템이 죽으니까 알림도 같이 죽었습니다.

[⚠️ 아래 블록은 붙여넣으면 깨짐 — 이 부분은 캡처/PNG 이미지로 대체해서 업로드]

시스템 정지  →  알림 기능도 함께 정지  →  "아무 소식 없음"  →  나는 정상이라고 읽음

그 엿새 동안 도착한 증빙 메일들은 처리되지 못한 채 지나갔고, 그건 되돌릴 수가 없었습니다. 다음 달 지출결의서에서 증빙 다섯 건이 비어 있었습니다.

"자동 수취는 조용히 실패한다. 그래서 이걸 잡는 검증기를 따로 만들어야 한다."

4. 그런데 고치는 것도 안 됐습니다

그래서 이 문제들을 고치려고 했습니다. 그런데 이번엔 다른 벽이 나왔습니다.

고쳐달라고 하면 에이전트가 기록도 안 보고, 현장도 안 열어보고, 추측으로 답을 냈습니다.

가스 요금 청구서 수집이 실패했을 때가 그랬습니다. 에러 한 줄만 보고 "로그인이 필요한 것 같습니다" 하더군요. 저는 손으로 해봐서 로그인이 필요 없다는 걸 압니다. 고치게 했더니 또 실패. 또 다른 추측, 또 땜빵, 또 실패.

며칠을 태우고 나서야 제가 이렇게 말했습니다.

"너 혹시 추론하니? 맞다면 추론 그만하고, 가서 직접 보고 해결하고 와."

그러니까 고쳐졌습니다.

무서운 건 틀리는 게 아니라, 확인 없이도 그럴듯한 답을 만들 수 있다는 것이었습니다.

그래서 순서를 박았습니다

디버깅 규율 스킬을 따로 만들었습니다. 한 줄로 하면 "추론 그만, 실증해"입니다.

[⚠️ 아래 블록은 붙여넣으면 깨짐 — 이 부분은 캡처/PNG 이미지로 대체해서 업로드]

1  실패한 실제 데이터부터 본다
2  코드는 끝까지 읽는다 (미완성 주석까지)
3  실제 페이지·실제 메일을 직접 연다
4  전에 같은 병을 앓았는지 이력을 본다
5  기록을 남긴다

중요한 건 항목이 아니라 순서가 강제된다는 점입니다. 1단계 결과물을 붙이기 전에는 2단계로 못 갑니다. 그러면 건너뛸 경로 자체가 없어집니다.

아는 척하지 말라고 부탁하는 게 아니라, 아는 척할 수 있는 경로를 없앤 겁니다.

지금 규율은 네 조항입니다.

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

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

3. "성공"을 믿지 않는다 — 끝까지 도착했는지 직접 확인한다

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

5. 왜 메모리가 아니라 스킬이었나

여기서 한 가지 짚고 갑니다. 이 규율을 왜 스킬로 만들었나. 메모리에 넣어두면 되는 거 아닌가.

저는 그동안 "알려주면 된다"고 생각했습니다. 발주서에 적고, 메모리에 넣고, 안내 문서를 만들면 그다음부터는 지켜질 거라고요.

그런데 아니었습니다.

에이전트는 상황에 따라 접근 방식이 달라집니다. 메모리는 읽을 수도 있고, 안 읽을 수도 있습니다. 그런데 문제가 터지는 순간은 대개 제가 급하고 열받아 있는 때입니다. 하필 그때 안 읽습니다.

스킬은 다릅니다. 트리거가 걸리면 정해진 순서대로 발동합니다. 읽을지 말지를 에이전트가 고르지 않습니다.

적어두는 것과 강제되는 건 다른 일이었습니다. 그 증거가 2장의 13페이지입니다. 저는 "검증기를 따로 만들어야 한다"고 적어놓고도 안 만들었습니다. 적어두는 건 안 읽고 넘어갈 수 있으니까요.

6. 그제서야 검증이 돌기 시작했습니다

앞의 그 규율을 깔고 나서야 검증 스킬이 제대로 굴렀습니다. 지금 이 스킬이 하는 판단은 크게 둘입니다.

하나, 교차검증. 엑셀의 각 줄을 증빙 원본과 대조합니다. 자동으로 채워진 금액이 부가세 전인지 포함인지, 과세인지 비과세인지를 맥락을 보고 판단합니다. 이러면 역으로 계산서나 고지서 쪽 오류를 잡아내기도 합니다.

둘, 예외 분류. 증빙이 잘못 들어왔을 때 증상을 보고 원인을 판정해서 복구 경로를 고릅니다. 고정 금액인데 앞선 달과 다르면 알려주기도 합니다.

마지막엔 "뭐가, 왜 안 됐고, 뭘 해봤는지"를 자연어로 정리해 줍니다. 저는 그 보고만 보고 남은 것만 처리합니다.

여기서 층이 왜 나뉘는지가 분명해졌습니다. 도구로 나뉜 게 아니라 판단의 양으로 나뉩니다.

• 1~2층은 제 손을 대신합니다 → 매번 똑같아야 하니까 기계에 둡니다

• 3층은 제 판단을 대신합니다 → 매번 다르게 생긴 문제라서 미리 못 적어둡니다

7. 그런데 이 검증기는, 누가 검증하죠?

여기서 걸리는 게 하나 있었습니다.

3층이 하는 일은 결국 "시스템이 완료라고 해도 실물을 봐라"입니다. 그런데 그 실물을 보는 쪽도 AI입니다.

그럼 얘가 진짜 보고 판정하는지는 누가 봅니까.

지출결의서는 그나마 낫습니다. 금액은 숫자라서 틀리면 티가 납니다. 그런데 저는 다른 일에도 같은 구조를 얹어놨습니다. 제가 대본을 볼 때 쓰는 기준 여든 몇 개를 문항으로 만들어서, AI가 1차 검토를 하게 해둔 겁니다. 여기는 정답이 숫자가 아닙니다. 대충 채점해도 제가 알 방법이 없습니다.

그래서 채점기한테 시험을 보게 했습니다

멀쩡한 대본을 하나 가져다가 일부러 망가뜨렸습니다.

• 대사 주인을 통째로 뒤섞었습니다. A가 할 말을 B가 하게

• 길이는 원본과 똑같이 뒀습니다. "짧아서 점수가 낮다"는 핑계를 못 대게

그리고 원본과 망가뜨린 걸 섞어서 채점시켰습니다. 대사의 주인이 다 뒤바뀌었으니, 인물의 말투를 보는 항목은 당연히 점수가 떨어져야 합니다.

안 떨어졌습니다. 2점, 그대로 2점.

• 제일 좋은 모델로 바꿔봤습니다 → 똑같았습니다

• 프롬프트에 "제대로 좀 봐라"를 세게 써봤습니다 → 똑같았습니다

문항 정의는 멀쩡했습니다. "화자를 바꿔도 위화감이 없으면 약한 것"이라고 정확히 적혀 있었어요. 채점자가 그 테스트를 실제로 안 한 겁니다. 그러고도 점수는 그럴듯하게 내놨고요.

말로 안 되니까, 코드로 걸었습니다

왜 안 되는 건지는 지아코모 스터디장님 자료에 그대로 적혀 있었습니다.

"시험을 본 학생이 자기 답안을 채점해서 100점을 주면 아무도 안 믿습니다. 채점은 다른 사람이, 정답지를 손에 들고 합니다."

제 채점기는 자기 답안을 자기가 채점하고 있었던 겁니다. 그러니 아무리 세게 말해도 점수가 안 움직였던 거고요. 고칠 방향도 이 한 문장에 다 있었습니다 — 시험 보는 쪽과 채점하는 쪽을 가를 것. AI는 답안지만 내고, 채점은 정답지를 든 쪽이 할 것.

바꾼 건 하나입니다. AI한테 점수를 물어보는 걸 그만두고, 안 보면 못 푸는 문제를 풀게 했습니다.

대본에서 화자 이름표를 지웁니다.

그리고 묻습니다. "이 대사 100개, 각각 누가 한 거야?"

여기서 AI는 점수를 말할 기회가 없습니다. 답안지만 제출합니다. 정답지는 따로 만들 필요도 없습니다 — 원본 대본이 곧 정답지니까요. 맞았는지 틀렸는지는 코드가 대조해서 셉니다.

결과입니다.

그제서야 칼이 들었습니다. 프롬프트로 물었을 때는 둘 다 2점이라 구분 자체가 안 됐던 걸, 이 방식은 확실히 갈라냅니다.

67%가 낮아 보이지만 절대값은 의미가 없습니다. "네." "왜요?" 같은 대사는 사람도 못 맞힙니다. 원본과 망가뜨린 것 사이가 59%p 벌어졌다는 것이 "이 채점기는 말투를 실제로 읽고 있다"는 증거입니다.

부수 효과도 하나 있었습니다. 작품마다 이 정답률이 다르게 나옵니다. 프롬프트 채점은 뭘 넣어도 비슷한 점수를 주는데, 이건 차이를 만들어냅니다.

그런데 대사만 그런 게 아니었습니다

같은 시험을 사건 순서로도 해봤습니다. 씬을 통째로 뒤섞은 대본을 넣은 겁니다. 인과도 정보 공개 순서도 다 무너지니까 점수가 폭락해야 정상입니다.

0.0만큼도 안 움직였습니다. 제일 좋은 모델을 써도 똑같았고요.

여기는 원인이 달랐습니다. 화자 쪽은 채점자가 게을렀던 건데, 이쪽을 파보니 제가 답을 적을 칸을 안 만들어놨더군요.

제 기준에는 이렇게 적혀 있습니다 — "회차 마지막 씬이 정서적 봉합으로 끝나는가", "회차의 1/4 지점에서 톤이 전환되는가". 위치가 정확히 박혀 있습니다. 그런데 답을 받는 형식이 점수 하나뿐이었습니다.

아래처럼 받았으면 "12번인데 마지막이라고?"를 코드가 자동으로 되물을 수 있습니다. 위처럼 받으면 되물을 방법이 없고요.

위치를 적을 칸이 없으니 확인할 이유도 없었던 겁니다. 채점자는 대본 어딘가에서 봉합처럼 보이는 씬을 하나 찾으면 그만이고, 그러면 씬을 아무리 뒤섞어도 그런 씬은 여전히 어딘가에 있습니다.

그러니까 고칠 곳은 기준이 아니라 답변 형식이었습니다. 근거 씬 번호를 같이 내게 하면 코드가 대조할 수 있습니다. 지금 그 도구를 만들어뒀고, 실제 채점에 물릴지는 원본과 뒤섞은 걸 실제로 갈라내는지 측정한 다음 정하려고 합니다. 아직 안 끝났습니다.

8. 배운 점

하나. 아는 것과 지켜지는 것은 다릅니다.

저는 사고를 발주서에 미리 적어놓고도 그대로 당했습니다. 지식이 부족해서가 아니라 그 지식이 실행되도록 강제하는 장치가 없어서였습니다. 그게 제가 스킬을 만든 이유입니다.

둘. 알림을 시스템 안에 두지 마세요.

같이 죽습니다. 그리고 죽은 건 아무 말도 안 하기 때문에, 침묵이 정상인지 고장인지 구분이 안 됩니다. 지금은 알림을 밖으로 뺐고, "오늘 진짜 없었다"와 "오늘 못 가져왔다"를 다른 문구로 찍게 했습니다.

셋. 금지어 목록은 샙니다. 먹히는 건 순서 강제입니다.

"추측하지 마"라고 쓰는 것보다 "1단계 산출물 없이는 2단계로 못 간다"가 훨씬 잘 듣습니다. 부탁이 아니라 경로 차단이어야 합니다.

넷. 비개발자일수록 검증이 먼저입니다.

저는 에이전트가 내놓은 원인 분석이 맞는지를 코드 실력으로 가릴 수가 없습니다. 그래서 내용을 검증하는 대신 절차를 검증합니다. 판단은 못 해도 증거를 봤는지 안 봤는지는 볼 수 있으니까요.

다섯. 그리고 그 검증기도 시험을 봐야 합니다.

검증을 AI에 맡기는 순간, "이 검증이 진짜인가"라는 질문이 한 겹 더 생깁니다. 저는 그걸 일부러 망가뜨린 걸 넣어보는 방법으로 확인했습니다. 그리고 그 시험은 말이 아니라 코드로 걸어야 통과 여부가 갈립니다.

여섯. 답을 적을 칸이 없으면, 시켜도 안 합니다.

두 번의 실패가 결국 한 가지였습니다. "제대로 봐라"라고 시켜도, "근거가 없으면 낮은 점수를 줘라"라고 시켜도 안 지켜집니다. 확인할 수 있는 산출물을 요구하지 않으면, 시킨 게 지켜졌는지 알 방법 자체가 없기 때문입니다. 채점기한테 "누가 한 대사게?"를 풀게 한 것도, 근거 씬 번호를 적게 하려는 것도 결국 같은 처방이었습니다.

9. 그래서 스킬은 마지막에 만듭니다

여기까지 겪고 나서 정리된 게 하나 있습니다. 시켜놓은 걸 지키게 만드는 방법은 하나가 아니라 층이 있었습니다.

아래로 갈수록 확실해지지만, 만드는 값이 비쌉니다. 그래서 저는 위에서부터 시도하고, 새는 자리에서만 한 칸씩 내려갑니다. 전부 코드로 걸어버리면 좋을 것 같지만, 그러면 아무것도 못 만듭니다.

만드는 타이밍도 같습니다. 스킬을 먼저 만들려고 하면 결과물이 아쉬울 때가 많았거든요. 지금은 이렇게 합니다.

[⚠️ 아래 블록은 붙여넣으면 깨짐 — 이 부분은 캡처/PNG 이미지로 대체해서 업로드]

에이전트와 며칠 논의하며 결과물을 완성한다
        ↓
시행착오를 실제로 겪는다
        ↓
"지금까지 나눈 이야기를 최적의 루트로 스킬 만들어줘"

혹시 스킬로 뭘 만들지 모르겠다면 — 최근에 에이전트에게 가장 열받았던 순간을 복기해 보세요. 제 스킬은 전부 거기서 나왔습니다.

다음에 할 것

• 검증기 시험(일부러 망가뜨린 걸 넣어보기)을 상시로 붙이기. 지금은 제가 생각날 때 돌립니다

• 순서 쪽 처방(근거 씬 번호를 같이 받기)이 실제로 원본과 뒤섞은 걸 갈라내는지 측정. 안 갈라지면 이 처방도 무딘칼이라 접어야 합니다

• 채점 기준을 전수로 훑었더니 위치를 묻는 항목이 스무 개 넘게 있었습니다. 하나씩 볼 게 아니라 답변 형식을 통째로 바꿔야 할 것 같습니다

• 실제 실패가 났을 때 알림이 제대로 뜨는지 확인. 이건 실패를 기다려야 해서 아직 못 했습니다