하루 종일 여러 AI와 자동화를 돌렸는데도 일이 끝나지 않는 날이 있다. 대화와 초안은 늘었지만 무엇이 실제로 작동하는지는 모른다. 나도 개인 자동화 프로젝트를 운영하면서 “실행 성공” 표시를 보고 안심했다가, 사용자가 받아야 할 메시지가 오지 않는 문제를 뒤늦게 발견했다.
그날 배운 것은 단순했다. 일을 많이 실행한 것과 결과가 검증된 것은 다르다. 바쁨을 줄이려면 도구를 하나 더 붙이는 것보다 업무를 수집, 판단, 생산, 검증으로 나누고 각 단계의 증거를 남겨야 한다.
개인용 Telegram 자동화가 성공으로 기록됐지만 정기 메시지는 도착하지 않았다. 로그와 실행 경로를 분리해 조사한 결과, 대화형 기능과 예약 발송은 서로 다른 실행 경로였고 예약 발송은 필수 설정이 없어도 성공 코드로 끝나고 있었다. 비밀값은 공개하지 않고 문제를 찾고 닫은 과정만 정리한다.
처음에는 “봇이 죽었다”고 생각했다
표면적인 증상은 간단했다. Telegram에서 명령을 보내도 답이 없었다. 로컬 프로세스 상태를 보니 대화형 봇이 멈춰 있었고, 파일 접근 권한과 실행 경로에도 문제가 있었다. 프로젝트를 접근 가능한 위치로 옮기고 실행 경로를 고친 뒤 명령에 다시 답하는 것을 확인했다.
여기서 일을 끝냈다고 표시하기 쉬웠다. 실제로 대화형 기능은 살아났다. 하지만 같은 봇의 정기 발송은 GitHub Actions라는 별도 경로에서 실행되고 있었다. 화면에는 최근 실행이 성공으로 보였지만, 새 토큰으로 바꾼 뒤 정기 메시지는 오지 않았다.
“봇 하나”라는 이름 아래에 서로 다른 두 시스템이 있었던 것이다.
| 기능 | 실행 위치 | 처음 보인 상태 | 완료 증거 |
|---|---|---|---|
| 대화형 응답 | 로컬 Mac | 프로세스 정지 | 실제 명령에 답변 도착 |
| 정기 발송 | GitHub Actions | 실행 성공 표시 | 수동 실행 후 메시지 수신 |
성공 표시가 실제 성공이 아니었던 이유
예약 실행의 로그를 다시 읽자 필수 수신 대상 설정이 없다는 문구가 보였다. 더 큰 문제는 스크립트가 이 상황에서 오류 코드로 끝나지 않았다는 점이다. 발송하지 못했는데도 실행 환경에는 성공으로 전달됐다. 대시보드는 거짓말을 한 것이 아니라, 프로그램이 전달한 종료 상태를 그대로 표시했을 뿐이었다.
이 문제를 고칠 때 한 일은 세 가지였다.
- 대화형 응답과 예약 발송을 별개의 완료 항목으로 분리했다.
- 필수 설정이 없거나 발송이 실패하면 스크립트가 실패 상태로 종료되게 했다.
- 예약 작업을 수동으로 실행하고 실제 메시지가 도착한 뒤에만 완료로 기록했다.
핵심은 코드를 많이 바꾼 것이 아니다. 완료의 기준을 “작업이 실행됐다”에서 “의도한 결과가 사용자에게 도착했다”로 바꾼 것이다.
업무를 네 단계로 나누면 어디서 착각했는지 보인다
| 단계 | 이번 사례에서 한 일 | 남겨야 할 증거 | 흔한 실패 |
|---|---|---|---|
| 수집 | 프로세스, 로그, 실행 이력, 수신 여부 확인 | 관찰 사실과 시각 | 성공 배지만 보고 멈춤 |
| 판단 | 로컬 응답과 클라우드 발송을 분리 | 원인 후보와 반증 | 모든 증상을 한 원인으로 묶음 |
| 생산 | 경로·설정·오류 종료 처리 수정 | 변경 내역과 되돌리기 방법 | 여러 설정을 한꺼번에 변경 |
| 검증 | 양쪽 경로를 각각 실제 실행 | 응답·수신·실패 테스트 | 프로세스가 떠 있으면 완료 |
AI를 병렬로 쓰더라도 완료 기준은 하나여야 한다
이 사례를 정리하는 동안 여러 AI가 각각 블로그, 자동화, 저장소를 맡았다. 독립적으로 조사하면 속도와 관점은 늘어난다. 반면 상태 표현이 제각각이면 “고쳤다”, “살아 있다”, “배포됐다”가 서로 다른 뜻으로 사용된다.
그래서 도구나 담당자보다 먼저 공통 상태를 정했다.
- 대기: 아직 시작 조건이 충족되지 않았다.
- 진행 중: 변경 또는 조사가 진행되고 있다.
- 검증 필요: 변경은 끝났지만 실제 결과를 확인하지 않았다.
- 완료: 정해 둔 증거로 결과를 확인했다.
특히 “검증 필요”가 중요했다. 배포와 완료 사이에 한 칸을 만들어야 성공 표시만 보고 넘어가는 일을 줄일 수 있다.
내가 사용하는 완료 조건 문장
“[대상]을 [환경]에서 실행하고, [사용자가 받는 결과]와 [실패 시 나타날 신호]를 각각 확인한다. 확인 전 상태는 완료가 아니라 검증 필요로 둔다.”
예를 들어 “예약 발송을 고친다” 대신 “클라우드 예약 작업을 수동 실행해 실제 메시지 수신을 확인하고, 필수 설정을 제거한 시험에서는 작업이 실패로 표시되는지 확인한다”라고 적는다. 긍정 테스트와 실패 테스트가 함께 있어야 대시보드의 성공 표시를 믿을 근거가 생긴다.
문서와 법령 검토에도 같은 구조를 적용할 수 있다
자동화가 아니어도 원리는 같다. 법령 검토라면 AI가 조문 후보를 제시한 것이 생산 단계이고, 현재 시행 중인 원문과 기준일을 직접 대조해야 검증 단계가 끝난다. 보고서라면 초안 생성은 생산이고, 의사결정자가 필요한 선택지·근거·담당·기한이 있는지 확인해야 완료다.
AI는 수집과 초안을 빠르게 하지만, 자연스러운 답변이 원문과 일치한다는 보장은 없다. 그래서 사실, AI의 해석, 사람의 판단을 한 문단에 섞지 않고 구분한다. 민감한 회사 자료나 개인정보는 도구에 넣기 전에 별도의 보안 기준도 확인한다.
오늘 바로 적용하는 20분 점검
- 5분: 진행 중인 일 중 하나를 고르고 사용자가 받는 최종 결과를 한 문장으로 쓴다.
- 5분: 수집·판단·생산·검증 중 현재 위치를 표시한다.
- 5분: 화면의 성공 표시 외에 필요한 실제 증거를 정한다.
- 5분: 정상 동작과 실패 상황을 하나씩 시험하고 결과를 기록한다.
이 네 단계 뒤에도 결과를 설명할 수 없다면 일이 부족한 것이 아니라 완료 조건이 흐린 것이다.
검증을 마치고 다음 일로 넘어가는 기준
이 사례의 완료 조건은 대화형 응답과 클라우드 발송 각각의 실제 수신, 필수 설정 누락 시 실패 표시였습니다. 이 조건을 확인했다면 해당 수정은 닫고 다음 작업으로 넘어갑니다. 새 변경이나 실패가 없는데 같은 검사를 계속 반복할 필요는 없습니다.
예약 작업을 수동 실행해 수신을 확인한 결과와, 다음 예약 시각에 자동 실행된 결과는 구분해서 기록합니다. 예약 시각의 관측이 남았다면 그 항목만 대기로 두고, 결과에 의존하지 않는 다른 구현은 계속할 수 있습니다.
아직 어떤 일을 자동화할지 정하지 않았다면 업무 자동화 후보 비교와 전체 시간 측정표부터 작성하세요.
함께 읽기
참고한 공식 자료
작성·검토 기준일: 2026년 8월 29일. 실제 개인 자동화 장애를 바탕으로 작성했으며 토큰, 계정, 저장소의 비공개 정보는 포함하지 않았습니다.