만드는 것보다 믿는 게 어려웠다 — 가계부·지식관리·연구 자동화, 9편으로 돌아본 기록

📝 한줄 요약

7월엔 가계부와 링크 저장을 자동화했고, 8월엔 연구계획서 작성을 자동화했습니다. 영역은 셋 다 달랐는데 막힌 지점이 같았습니다. 만드는 건 됐는데, 만든 결과를 그대로 믿고 쓸 수가 없었습니다. 9편의 기록을 한 편으로 묶습니다.

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

• 돈·지식·연구 세 영역에서 자동화를 만들었는데, 매번 같은 벽에 부딪혔다

• 그 벽은 기능이 아니라 신뢰였다 — 결과가 맞는지 매번 사람이 다시 확인해야 했다

• 해법도 매번 같았다: AI가 하지 않을 일을 먼저 긋고, 확인할 수 있게 남기기

• "완료했습니다"를 믿지 않기로 하고 완료를 테스트 항목으로 바꿨다

• 복구된다는 말도 믿지 않고 일부러 파일을 부숴서 확인했다

• 다 돌았는데도 WARN으로 끝냈다 — 끝난 것과 쓸 준비가 된 것은 다르다

• 세 영역에서 같은 방법이 통했다면, 그건 요령이 아니라 일반적인 작업 방식이다

🎯 이런 분들께 도움돼요

• AI로 뭔가 자동화해 놨는데, 결과를 그대로 쓰기가 왠지 불안한 분

• "AI가 다 했다는데 이게 맞나?"를 매번 직접 확인하느라 오히려 시간이 더 드는 분

• 돈·개인정보처럼 틀리면 곤란한 데이터를 자동화에 맡겨야 하는 분

• AI에게 맡길 일과 사람이 쥐고 있어야 할 일의 경계를 잡고 싶은 분

😫 문제 상황 (Before)

세 번 다 같은 자리에서 멈췄습니다.

가계부는 카드 사용 메일을 읽어 거래를 정리하는 자동화였습니다. 돌아가긴 하는데, 중복인지 환불인지 카테고리가 맞는지를 매번 눈으로 다시 봐야 했습니다.

링크 저장은 읽은 글을 옵시디언에 모으는 자동화였습니다. 링크는 쌓이는데 왜 저장했는지가 남지 않아, 나중에 열어도 맥락이 없었습니다.

연구 자동화는 자료를 넣으면 프로필과 연구계획서 초안까지 나오는 도구였습니다. 결과물을 받아 놓고도 언제 검증한 것인지, 그 뒤에 안 바뀌었는지를 알 수 없어 그대로 쓸 수가 없었습니다.

공통점이 분명합니다. 자동화를 해 놓고도 검산에 드는 시간이 줄지 않았습니다. 만드는 건 끝났는데 믿는 게 안 되니, 도구가 아니라 숙제가 하나 더 생긴 셈이었습니다.

🛠️ 사용한 도구

• 도구명: Claude Code, Codex CLI(구현 위임), Hermes 워크플로우 스킬, Obsidian

• 분업 방식: 설계와 검증은 Claude, 구현은 Codex — 만든 쪽과 확인하는 쪽을 다른 프로세스로 분리

• 기간: 2026년 7월 ~ 8월 13일 (총 9편)

🔧 9편의 흐름

7월 — 다른 영역에서 먼저 나온 답

1편. 가계부: "매일 안전하게 돌게 하려면?"

돈을 다루는 자동화라 처음부터 조심스러웠습니다. 그래서 기능을 늘리는 대신 AI가 하지 않을 일을 먼저 정했습니다.

• 로그인과 비밀번호는 자동화하지 않는다. 사람이 직접 하고, 실패하면 거기서 멈춘다

• 메일은 증거일 뿐, 거래를 새로 만드는 기준이 아니다. 중복·환불·카테고리 판단은 사람이 한다

• 범위를 "최근 몇 건"이 아니라 날짜 범위로 정의한다 — 그래야 다시 돌려도 같은 결과가 나온다

• 자동화가 도는 경로와 사람이 보는 대시보드의 접근 경로를 나눈다

7월 1~25일로 첫 실행을 돌려 90건을 훑고 12건을 새 증거로, 14건을 기존 거래에 연결했습니다. 숫자보다 중요한 건 AI가 만든 것이 "거래"가 아니라 "증거"였다는 점입니다. 판단은 사람 몫으로 남겼습니다.

2편. 링크 저장: 저장에서 축적으로

읽은 글을 모으는 자동화인데, 링크만 쌓이니 나중에 쓸모가 없었습니다. 두 가지를 바꿨습니다.

인덱스와 상세 노트를 나눴습니다. 목록만 보면 뭐가 있는지는 알아도 왜 담았는지는 모릅니다.

그리고 이게 이 편의 진짜 수확입니다. 본문을 읽었는지, 메타데이터만 봤는지를 표시했습니다. 로그인이 필요한 플랫폼은 제목만 긁히는데, 그걸 구분 없이 저장하면 나중에 그 요약을 믿어도 되는지 알 수 없습니다. 모르면 모른다고 적어 두는 것이 정보의 신뢰도를 지켰습니다.

8월 — 같은 방법을 연구 자동화에서 끝까지

3편 (8/3). 작동하는 것을 "다시 쓸 수 있는 것"으로

도구는 도는데, 다음에 다시 돌릴 때도 같은 순서로 갈지가 문제였습니다. 한 번 잘 된 작업에는 그 순간의 판단이 잔뜩 묻어 있고, 그게 사람 머릿속에만 있으면 다음 실행은 처음부터 다시 흔들립니다.

자료 등록부터 감사까지를 10개 스킬과 파일로 남는 상태로 쪼갰습니다. 더 긴 지시를 주는 대신 언제 진행하고 언제 멈추며 무엇을 확인할지를 파일로 남겼습니다.

4편 (8/4). "생성된 것"과 "다시 확인할 수 있는 것"

여기서 중요한 구분이 나옵니다. 파일이 있다는 것과 검증했던 그 파일이 지금도 같은 것은 다릅니다. 검증한 뒤 누가 한 줄 고쳤다면 그 검증서는 더 이상 그 파일에 대한 것이 아닙니다.

승인도 "승인됨" 한 마디로는 부족했습니다. 무엇을·어디까지·어떤 입력을 보고 승인했는지가 남아야 다음 주의 내가 그 승인을 믿을 수 있습니다.

5편 (8/10). 완료 판정을 미루기로 하다

여기서 이야기가 뒤집힙니다. "다 만들어졌는데도 남는 불안"의 정체는 완료가 선언이었기 때문이었습니다. AI가 완료했다고 말하고 사람이 받아 적는 구조에서는 이력을 아무리 붙여도 불안이 사라지지 않습니다.

그래서 완료를 테스트 항목으로 바꿨습니다. "다 됐습니다"가 아니라 "이 명령을 돌렸을 때 이 결과가 나오면 완료"로 정의를 옮겼습니다.

같은 날 내린 결정 하나가 인상적입니다. 예전 기록을 새 기준에 맞춰 고치지 않기로 했습니다. 소급해서 다듬으면 기록이 깨끗해 보이지만, 그건 그때 실제로 무엇을 확인했는지를 지우는 일입니다.

6편 (8/10). 복구된다는 말을 믿지 않고 일부러 부쉈다

복구 경로를 만들어 둔 것과 실제로 작동하는 것은 다릅니다. 안전한 실험장을 먼저 만들고, 정상일 때의 상태를 숫자로 기록한 뒤, 일부러 파일을 바꿔서 고장이 감지되는지 봤습니다.

마지막 단계가 좋았습니다. 고장을 확인한 다음 전부 다시 만들지 않고 정상인 부분은 버리지 않고 문제가 생긴 곳만 수리했습니다. 복구가 "리셋"이 아니라 진짜 수리로 작동한다는 걸 눈으로 본 날입니다.

7편 (8/12). 고치기 전에 무엇이 반복되는지부터 적었다

PASS라는 글자가 떴는데, 그게 무엇을 통과한 건지 설명하지 못하면 다음번에 같은 판단을 재현할 수 없습니다.

이 날의 역할 분담이 명확했습니다. 사람은 문제를 골랐고, AI는 근거를 대조했습니다. 그리고 고친 것이 무엇이었는지가 핵심입니다. 연구 내용을 고친 게 아니라 확인 방식을 고쳤습니다.

8편 (8/12). 끝까지 돌렸는데 WARN으로 끝냈다

9편 중 가장 절제된 판단입니다. 하나의 실행을 처음부터 끝까지 연결하는 데 성공했고, 보통 여기서 "완료"를 찍습니다. 그런데 WARN으로 끝냈습니다.

끝까지 돌아간 것과 쓸 준비가 된 것을 구분했기 때문입니다. 같은 날, 한 번 받은 승인이 다음 문까지 열지는 않게 했고, 모호한 상황에서 더 세게 밀어붙이는 대신 다음 결정을 작게 만들었습니다.

9편 (8/13). 문서 116건, 요약기가 아니라 스킬을 고쳤다

작은 예제에서는 안 보이던 것들이 문서 116건에서 드러났습니다. 중간에 멈추면 처음부터 다시 해야 했고, 중복을 지우다 경력이 통째로 사라졌고, 문장은 그럴듯한데 출처를 다시 찾을 수 없었습니다.

여기서 가장 중요한 선택이 나옵니다. 결과가 나빴을 때 결과물을 손보지 않고 스킬을 고쳤습니다. 요약이 이상하면 요약을 다듬고 싶어지지만, 그러면 다음 116건에서 같은 일이 또 생깁니다.

✅ 결과 (After)

세 영역에서 같은 것이 바뀌었다

남은 것

8편이 WARN으로 끝났다는 건 아직 "쓸 준비가 됐다"에 도달하지 않은 지점이 남아 있다는 뜻입니다. 그걸 완료로 바꿔 적지 않은 게 이 연재에서 제일 마음에 드는 부분입니다.

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

효과적이었던 것

1. AI가 하지 않을 일을 먼저 긋기 — 가계부에서 로그인을 자동화 대상에서 뺀 것이 시작이었습니다. 무엇을 시킬지보다 어디서 멈출지를 먼저 정하면 나머지가 단순해집니다.

2. AI 산출물을 "결과"가 아니라 "증거"로 두기 — 메일에서 뽑은 건 거래가 아니라 거래의 근거입니다. 이 한 칸을 옮기면 판단이 사람에게 남습니다.

3. 완료를 말이 아니라 명령으로 정의하기 — "다 됐어?"라고 묻는 대신 "이걸 돌려서 이 결과가 나오면 완료야"라고 먼저 정해 두면 판정에 감이 끼어들 자리가 없습니다.

4. 된다고 하는 걸 일부러 부숴 보기 — 복구·백업·검증 장치는 만들어 놓기만 하면 작동한다고 착각하기 쉽습니다.

5. 모르면 모른다고 적게 하기 — 전문을 읽었는지 제목만 봤는지 표시하는 것만으로 나중에 그 요약을 믿어도 되는지가 갈립니다.

6. 결과가 나쁘면 결과 말고 절차를 고치기 — 산출물을 손보면 그 한 번은 좋아지지만 다음에 또 같은 일이 생깁니다.

이렇게 하면 안 돼요

1. "완료했습니다"를 그대로 받아 적기 — AI는 성실하게 완료를 보고합니다. 그 성실함이 정확함을 뜻하지는 않습니다.

2. 범위를 "최근 몇 건"으로 정하기 — 돌릴 때마다 대상이 달라져 같은 결과를 재현할 수 없습니다. 날짜처럼 고정된 기준을 쓰세요.

3. 과거 기록을 새 기준에 맞춰 고치기 — 기록은 깨끗해지지만 그때 무엇을 확인했는지가 지워집니다.

4. 한 번 받은 승인을 다음 단계까지 끌고 가기 — 승인에는 범위가 있어야 합니다.

5. 작은 예제만 보고 대량 처리로 넘어가기 — 116건에서야 보이는 문제가 따로 있습니다.

6. 다 돌았다고 완료로 적기 — 실행이 끝난 것과 쓸 준비가 된 것은 다릅니다.

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

9편이 돈·지식·연구 세 영역에서 같은 방법으로 풀렸다는 건, 이게 특정 분야의 요령이 아니라는 뜻입니다.

• 보고서·정산 자동화: "숫자가 맞다"를 눈으로 확인하는 대신 대조 명령 하나로 정의해 두기

• 자료 정리·아카이빙: 중복 제거를 돌리기 전에 "무엇이 사라지면 안 되는지"를 먼저 적어 두기 (9편의 경력 삭제 사고가 정확히 이 지점입니다)

• 외주·협업 산출물 검수: 승인에 범위를 붙여 남기면 나중에 "그때 이것까지 승인한 거였나"를 다투지 않아도 됩니다

• 개인정보·금융처럼 민감한 데이터: 자동화 범위에서 로그인과 최종 판단을 빼는 것부터 시작하기

🚀 앞으로의 계획

• 8편이 남긴 WARN 지점을 "쓸 준비 완료"로 옮기는 일이 다음 과제입니다

• 대량 처리에서 드러난 절차 문제를 다른 단계에도 같은 방식으로 적용해 볼 예정입니다

• 세 영역에서 통한 방식이니, 네 번째 영역에도 그대로 얹어 보려 합니다

📋 재사용 가능한 프롬프트

프롬프트 1: AI가 하지 않을 일부터 정하기

[작업]을 자동화하려고 해. 기능부터 만들지 말고, 자동화하면 안 되는 것을 먼저 정리해 줘.

• 사람이 직접 해야 하는 단계 (로그인·결제·최종 승인 등)

• AI가 만든 결과를 결정이 아니라 증거로만 취급해야 하는 지점

• 실패하면 계속 진행하지 말고 멈춰야 하는 지점
  그다음에 나머지를 자동화하자.

프롬프트 2: 완료를 테스트 항목으로 바꾸기

이 작업이 끝났는지 판단할 기준을 지금 정해 줘.
"다 됐습니다" 같은 말 말고, 내가 직접 실행해서 확인할 수 있는 명령과 기대 결과로 적어 줘.
각 항목은 [그대로 복사해 실행할 수 있는 명령] + [이 결과가 나오면 통과]의 쌍이어야 해.
"자연스러운지 확인" 같은 주관적 표현은 쓰지 마.

프롬프트 3: 안전장치를 실제로 시험하기

[백업/복구/검증 장치]가 진짜 작동하는지 확인하고 싶어.

1. 원본이 상하지 않는 실험용 사본을 먼저 만들고

2. 정상일 때의 상태를 숫자로 기록한 다음

3. 일부러 [고장 상황]을 만들어서 그게 실제로 감지되는지 보고

4. 감지되면 전부 다시 만들지 말고 문제가 생긴 부분만 고쳐 줘.
   각 단계마다 무엇을 관측했는지 알려 줘.

프롬프트 4: 모르는 것을 표시하게 하기

자료를 정리할 때, 각 항목에 내가 어디까지 확인했는지를 함께 남겨 줘.

• 전문을 읽고 정리한 것 / 제목·요약만 보고 정리한 것 / 접근이 막혀 추정한 것
  확실하지 않은 것을 확실한 것처럼 적지 말고, 모르면 모른다고 표시해 줘.

프롬프트 5: 결과 말고 절차를 고치게 하기

지금 나온 결과가 [문제점]이야.
결과물을 직접 손보지 말고, 이 결과를 만들어 낸 절차의 어느 지점이 원인인지 먼저 찾아 줘.
원인을 못 찾겠으면 찾지 못했다고 말해 줘 — 결과만 다듬는 건 다음번에 같은 문제를 다시 만든다.