AI로 작업을 수행하다가 대화가 끊어졌을 때 일어날 대참사

Executive Summary

AI에 반복 업무를 맡기는 조직이 공통으로 겪는 운영 리스크가 하나 있습니다. 작업이 정상 종료된 상태와 중도 중단된 상태가 사용자 화면에서 구별되지 않는다는 점입니다. 이 구별이 안 되면 회사는 두 가지 비용을 치르게 됩니다. 하나는 완료된 작업을 불필요하게 다시 실행하는 비용이고, 다른 하나는 이미 수행된 단계를 중복 실행해 데이터 오염이나 토큰 비용등의 낭비가 심해지는 점이죠.

본 글의 핵심 요지는 세 가지 정도로 요약해볼 수 있습니다.

첫째, 이 문제는 기술적 한계에서 오지 않습니다. 앤트로픽, 오픈AI 시스템 내부에는 이미 종료 사유가 구분되어 있으며, 문제는 그 정보가 직접 AI를 사용하는 사람의 눈 밖에 있다는 데 있습니다.

둘째, 종료 신호가 보이지 않는 가시성 결여, 작업 주체와 기록 주체가 같은 구조적 종속, 성공과 실패 두 칸만 있는 상태 분류의 이분법입니다.

셋째, 이러한 이슈들은 5단계 AI 설계 절차로 해결할 수 있습니다. 작업 분해, 재실행 위험 의 등급화, 선행 확인 조건 프롬프트 삽입, 단계별 진행 기록, 의도적 중단 테스트로 이어지는 절차이며, 파일럿 기준 1개 업무당 30분 안팎이면 도입 가능합니다.

---

Part I. 문제 정의: 왜 '종료'와 '중단'은 AI 화면에서 똑같아 보이는가?

1. 가시성 결여 — 시스템 뒷단은 구분해내지만 AI를 쓰는 사용자는 보지 못합니다

사용자 화면에서 정상 종료와 중도 중단은 모두 "출력이 멈춘 상태"라는 동일한 외형을 보입니다. 담당자는 이 외형만으로 작업이 완결되었는지, 도중에 끊겼는지를 판별할 수 없습니다.

반면 시스템 차원에서는 이 구분이 이미 이루어져 있습니다. Anthropic API는 모든 응답에 stop_reason이라는 종료 사유 값을 함께 반환합니다(공식 문서 기준, 2026년 9월 6일 확인). 주요 값은 다음과 같습니다.

값 의미 업무 관점의 해석 end_turn 응답을 마쳐 정상 종료 작업 완결 max_tokens 출력 길이 상한에 도달해 절단 작업 미완 — 뒷부분 유실 pause_turn 서버 도구 반복 실행 중 한도 도달로 일시 정지 작업 미완 — 재개 필요

시사점: 정보는 존재합니다. 다만 대화형 인터페이스로 일하는 실무자에게 이 값이 노출되지 않습니다. 따라서 해법의 방향은 "새 정보를 만드는 것"이 아니라 "작업 상태를 담당자가 볼 수 있게 만드는 것 "으로 방향을 잡아야 합니다.

2. 구조적 종속 — 작업 주체와 기록 주체가 같습니다

두 번째 원인은 조직을 설계하는 문제와 구조가 같습니다. 컴퓨터에서 실행 중인 프로그램에는 각각 고유 식별 번호(PID)가 부여되고, 그 프로그램을 실행시킨 상위 프로그램의 번호(PPID)도 함께 기록됩니다. 즉 모든 프로세스에는 부모-자식 관계가 있습니다.

당사 운영 기록에 이를 잘 보여주는 사례가 있습니다. 한 정리 작업이 서버를 재기동하지 못한 건입니다. 원인은 단순했습니다. 해당 정리 작업 자체가 그 서버가 띄운 하위 프로세스였기 때문입니다. 서버를 종료하는 순간 정리 작업도 함께 종료되므로, 결과를 기록할 기회 자체가 사라집니다.

이 구조는 사람의 업무에도 그대로 적용됩니다. 진행 상황을 아는 사람이 해당 업무의 수행자 한 명뿐이라면, 그 사람이 이탈하는 순간 진행 정보도 함께 소실됩니다. 이른바 **단일 장애점(Single Point of Failure)**입니다.

AI가 업무를 수행하고 있는 상태 정보는 반드시 작업 주체의 외부에 별도로 저장되어야 합니다. 동일한 대화창 안에만 존재하는 진행 정보는 대화창이 닫히는 순간 함께 소멸합니다.

3. 상태 분류의 이분법 — '부분 성공'을 담을 칸이 없습니다

세 번째 원인은 분류 체계의 문제입니다. 프로그램은 종료 시 종료 코드라는 숫자 하나를 남깁니다. 0은 정상 종료를, 그 외 값은 비정상 종료 또는 사전에 정의한 특수 상태를 의미합니다.

운영 성숙도가 높은 조직은 이 체계에 '부분 성공'을 뜻하는 코드를 별도로 정의해 둡니다. 절반쯤 진행된 상태에 공식 명칭을 부여하는 것입니다. 명칭이 없으면 부분 성공은 실패로 분류되고, 실패는 통상 처음부터 재실행이라는 대응으로 이어집니다. 문제는 바로 이 전면 재실행에서 발생합니다.

4. 예시 시나리오: 시켰던 일을 전면 재실행이 사고로 이어지는 경우

한 기업의 인사팀이 지원자 자료 정리 업무를 6단계 AI 절차로 운영한다고 가정합니다. 이 절차가 4단계에서 중단되었습니다. 담당자는 종료 상태를 판별할 수 없으므로 전체를 재실행합니다. 그 결과 이미 완료된 1~3단계가 다시 실행됩니다. 이때 3단계가 "정리한 표를 공용 시트에 붙여넣기"였다면, 동일한 표가 두 벌 생성됩니다. 데이터 정합성이 훼손되고, 이를 사후에 식별·정리하는 추가 공수가 발생합니다.

이 사고의 빈도는 매우 흔합니다. 대용량 파일 이전 도구를 동일한 원본에 대해 중복 실행하면 폴더 경합이 발생하는 현상도 본질적으로 같은 원인에서 비롯됩니다.

5. 문제 정의 요약

1.가시성 결여 종료 사유가 사용자에게 보이지 않음

-상태 정보를 가시 영역으로 노출

2.구조적 종속 작업 주체가 소멸하면 기록도 소멸

-진행 정보를 작업 외부에 기록

3.이분법적 분류 부분 성공이 실패로 처리되어 전면 재실행

-중간 상태에 명칭 부여, 재실행 안전성 확보

상기 진단을 바탕으로, 다음 장에서는 이를 해소하는 5단계 설계 절차를 제시합니다.

---

Part II. 해결 방안: 재실행 안전성 확보 5단계 프레임워크

전체 구조

단계 핵심 과업 산출물 해소하는 원인

1. 업무를 단계로 분해 5~7행의 단계 목록 이분법적 분류

2. 재실행 위험 등급화(A·B·C) 등급이 매겨진 단계표 이분법적 분류

3. B·C 단계에 선행 확인 조건 삽입 중복 방지 지시문 이분법적 분류

4. 단계별 진행 기록 진행 표시 줄 가시성 결여, 구조적 종속

5. 의도적 중단 후 재개 테스트 검증 결과 전체 설계의 유효성

---

1단계 — 업무를 실행 단위로 분해합니다

대상 선정 기준: 최근 2주 이내에 AI에게 2회 이상 맡긴 업무 중 하나를 선정합니다. 신규 업무를 설계하지 말고 이미 운영해 본 업무를 대상으로 삼으십시오. 2회 이상 반복되었다는 사실 자체가 향후에도 반복될 업무라는 가장 신뢰할 만한 지표이며, 설계 투자 대비 효과가 가장 큰 영역입니다.

작성 방법: 5~7행으로 작성합니다. 한 행이 한 단계이며, 각 행은 반드시 **"무엇을 수행하여 어디에 남기는가"**의 형식으로 종결합니다.

• 부적절한 예: "자료를 정리한다"

• 적절한 예: "자료를 정리하여 작업 문서 3장에 붙여넣는다"

산출 위치를 명시하는 이유는 명확합니다. 산출 위치가 특정되어야 이후 단계에서 "이미 수행되었는가"를 확인할 수 있는 지점이 생기기 때문입니다.

성공 기준: 모든 행이 "무엇을 수행하여 어디에 남기는가"로 종결되면 1단계는 완료입니다. 산출 위치를 기술할 수 없는 행이 있다면, 그 행은 아직 실행 단위가 아니라 의도 수준의 서술에 머물러 있는 것이며 추가 분해가 필요합니다.

---

2단계 — 재실행 위험을 A·B·C 3등급으로 분류합니다

각 행에 대해 단 하나의 질문을 적용합니다.

"이 단계만 지금 한 번 더 실행하면 어떤 결과가 발생하는가?"

분류 기준:

등급 정의 판별 기준 예시

A (안전) 재실행해도 결과 불변 읽기 전용이거나, 동일 위치에 동일 값을 재기록 자료 조회, 동일 셀 재입력

B (주의) 재실행 시 산출물이 증식 새 행·새 파일·새 항목이 생성됨 시트에 행 추가, 새 문서 생성

C (위험) 재실행 시 되돌릴 수 없는 영향 외부 발신(발송·게시·제출) 또는 원본 덮어쓰기 이메일 발송, 게시판 등록, 원본 값 수정

판별 우선순위는 다음과 같습니다. 외부로 나가는 동작(발송·게시·제출)은 예외 없이 C, 원래 값을 덮어쓰는 동작도 C, 새 항목이 생성되면 B, 그 외 읽기 또는 동일 값 재기록은 A입니다.

판정 보류 규칙: 판단이 모호한 행은 억지로 등급을 부여하지 말고 '판정 보류'로 분류하십시오. 대신 판정에 필요한 정보가 무엇인지 한 줄을 병기합니다. 판정 보류가 3건을 초과한다면, 이는 1단계의 분해 수준이 거칠었다는 신호이므로 1단계로 돌아가 재분해하는 것이 효율적입니다.

성공 기준: 단계표에 B 또는 C 등급이 최소 1건 이상 식별되면 2단계는 완료입니다. 전부 A로 분류되었다면 발송·게시·제출·덮어쓰기 네 키워드로 재점검하십시오. 대부분의 경우 이 중 하나가 누락되어 있습니다.

핵심 관점: 이 등급표의 목적은 완벽한 분류가 아닙니다. B와 C의 위치를 식별하는 것, 즉 재실행 리스크가 집중된 지점을 찾아내는 것이 목적입니다. 80%의 정확도로 리스크 지점을 빠르게 특정하는 것이 100%의 정확도를 위해 설계를 지연시키는 것보다 가치가 큽니다.

---

3단계 — B·C 단계 앞에 선행 확인 조건을 삽입합니다

적용 범위: B와 C로 분류된 단계에만 조치합니다. A 등급 단계는 수정하지 않습니다. 모든 단계에 확인 절차를 넣으면 실행 비용만 증가하고 실익은 없습니다.

표준 지시문 형식:

"먼저 **[대상]**이 **[위치]**에 이미 존재하는지 확인하고, 존재하면 해당 단계를 건너뛴 뒤 건너뛰었다는 사실을 기록하라."

이 형식은 세 요소로 구성됩니다. 존재 여부 확인, 존재 시 생략, 생략 사실 기록입니다. 특히 마지막 요소가 중요합니다. 생략 사실이 기록되지 않으면 이후 검토 시 "실행되지 않은 것"과 "이미 완료되어 생략된 것"을 다시 구분할 수 없게 되어, Part I에서 지적한 가시성 문제가 재발합니다.

설계의 핵심 — 고유 식별 키 지정: 이 단계의 성패는 무엇을, 어떤 키로 찾게 하는가에 달려 있습니다.

• 효과가 낮은 지시: "같은 표가 있는지 확인하라"
  → 유사한 이름의 표가 여러 개 있으면 식별에 실패합니다.

• 효과가 높은 지시: "제목에 오늘 날짜와 지원자 번호가 함께 포함된 표가 있는지 확인하라"
  → 날짜와 지원자 번호의 조합은 중복될 수 없으므로 판별이 명확합니다.

즉 선행 확인은 중복 불가능한 식별 키를 전제로 할 때만 작동합니다. 1단계에서 산출 위치를 명시하도록 요구한 이유가 여기서 회수됩니다.

성공 기준: 삽입된 지시문 안에 확인 대상과 식별 키가 모두 명시되어 있으면 3단계는 완료입니다.

---

4단계 — 중단 시점의 진행 상태를 기록하게 합니다

설계 원칙: "중단하라"는 지시만으로는 충분하지 않습니다. 중단 이후 무엇을 남길지까지 정의해야 재개가 가능합니다. 중단 지시가 브레이크라면, 진행 기록은 재출발 지점을 알려주는 이정표입니다.

표준 형식: 한 줄이면 충분합니다.

진행: 3/6 완료 · 다음 4단계 · 멈춘 이유=자료없음 · 남긴 자리=작업문서 3장

이 한 줄은 재개에 필요한 네 가지 정보를 담습니다. 완료 범위, 재개 지점, 중단 사유, 산출물 위치입니다. 네 요소 중 하나라도 빠지면 재개 담당자는 추가 확인 작업을 해야 합니다.

핵심 설계 포인트 — 기록 시점: 진행 기록을 작업 종료 시점에 1회만 출력하도록 설계하면 치명적인 약점이 생깁니다. 출력이 절단될 때 가장 먼저 소실되는 것이 바로 마지막에 위치한 그 줄이기 때문입니다. Part I에서 살펴본 max_tokens 종료가 정확히 이 상황입니다. 가장 필요한 순간에 가장 먼저 사라지는 구조입니다.

따라서 진행 기록은 각 단계 완료 시마다 출력하도록 지시해야 합니다. 이렇게 하면 출력이 어느 지점에서 절단되더라도 직전 단계의 기록이 보존됩니다. 이는 데이터베이스의 체크포인트 방식과 동일한 원리이며, Part I에서 제시한 "진행 정보의 외부화"를 대화형 환경에서 구현하는 가장 간단한 방법입니다.

성공 기준: 중도에 절단된 출력에서도 마지막 줄에 단계 번호와 상태가 남아 있으면 4단계는 완료입니다.

---

5단계 — 의도적으로 중단시킨 뒤 재개를 검증합니다

필요성: 설계는 검증 전까지 가설에 불과합니다. 이 검증은 5분 내외면 충분하므로 반드시 수행할 것을 권고합니다.

테스트 절차:

1. 중단 조건 설정: 3단계 전후에서 중단되도록 조건을 하나 설정합니다(예: "4단계에 필요한 자료가 없으면 해당 지점에서 중단하라").

2. 1차 실행: 해당 조건하에 절차를 실행합니다.

3. 진행 기록 추출: 마지막으로 출력된 진행 표시 줄 한 줄만 복사합니다.

4. 2차 실행: 새 대화를 열고 복사한 진행 표시 줄을 붙여 넣은 뒤 재실행합니다.

통제 조건: 이전 대화 전체를 붙여 넣으면 테스트가 무효가 됩니다. 이 검증의 목적은 진행 표시 줄 하나만으로 작업이 이어지는가를 확인하는 것입니다. 전체 맥락을 제공하면 진행 기록 설계의 유효성을 분리해 평가할 수 없습니다. 이는 실제 운영에서 담당자 교체나 세션 만료처럼 맥락이 끊기는 상황을 재현하기 위한 조건이기도 합니다.

성공 기준: 다음 두 조건을 모두 충족하면 검증은 성공입니다.

• 2차 실행이 4단계부터 시작된다.

• 1~3단계의 산출물이 중복 생성되지 않는다.

첫 번째 조건은 4단계(진행 기록)의 유효성을, 두 번째 조건은 3단계(선행 확인)의 유효성을 각각 검증합니다. 두 조건 중 하나라도 실패하면 해당 단계로 돌아가 설계를 보완하십시오.

---

추가 위치는 Part II의 5단계가 끝난 직후, Part III 앞입니다. 지금 흐름은 문제 정의 → 5단계 해법 → 기대 효과로 곧장 넘어가서, 실제로 도입할 때 어디서 막히는지가 비어 있습니다. 이 자리에 새 장을 넣고, 기존 Part III는 Part IV로 번호만 밀면 됩니다.

---

Part III. 도입 시 흔히 빠지는 함정 3가지

5단계 프레임워크는 구조가 단순한 만큼, 형식은 갖추었는데 실제로는 작동하지 않는 경우가 생깁니다. 파일럿 과정에서 반복적으로 관찰되는 함정은 세 가지로 정리됩니다.

함정 1. 진행 기록을 다시 대화창 안에 가둡니다

4단계에서 진행 표시 줄을 만들어 두고도, 그 줄이 대화창 안에만 남아 있는 경우가 가장 흔합니다. 형식은 갖추었지만 Part I에서 지적한 구조적 종속은 그대로입니다. 대화창이 닫히거나 담당자가 바뀌면 진행 표시 줄도 함께 사라집니다.

대응 방안은 명확합니다. 진행 표시 줄을 대화 출력과 별도로 작업 바깥의 고정 위치에 한 번 더 남기도록 지시하십시오. 공용 문서의 지정된 칸, 업무 관리 도구의 해당 항목처럼 누구나 찾을 수 있는 자리여야 합니다. 판단 기준은 하나입니다. "지금 이 대화창이 사라져도 다음 담당자가 진행 상황을 알 수 있는가."

함정 2. 식별 키가 실행할 때마다 달라집니다

3단계의 선행 확인은 식별 키가 고정되어 있다는 전제에서만 작동합니다. 그런데 실무에서는 실행 시각(시·분)이나 "최종", "수정본" 같은 단어를 키로 쓰는 경우가 많습니다. 이 경우 두 번째 실행은 첫 번째 실행의 산출물을 다른 대상으로 인식합니다. 선행 확인은 "없음"으로 판정되고, 결국 중복이 발생합니다. 확인 장치가 있는데도 사고가 나는 전형적인 경로입니다.

대응 방안은 키를 실행 시점이 아니라 업무 대상 기준으로 잡는 것입니다. 실행 시각 대신 업무 기준일을, 파일 이름 대신 지원자 번호·거래처 코드 같은 대상 고유 번호를 쓰십시오. 점검 질문은 "내일 같은 작업을 다시 돌려도 이 키가 똑같이 만들어지는가"입니다.

함정 3. C 등급을 확인 한 줄로만 막으려 합니다

B 등급은 선행 확인만으로 충분히 통제됩니다. 중복이 생겨도 사후에 지우면 되기 때문입니다. 그러나 C 등급은 성격이 다릅니다. 이메일 발송, 게시, 제출, 원본 덮어쓰기는 한 번 실행되면 되돌릴 수 없습니다. 선행 확인이 한 번이라도 오판하면 그 비용은 조직 밖으로 나갑니다.

따라서 C 등급에는 이중 통제를 권고합니다. 선행 확인에 더해, 실행 직전에 멈추고 담당자의 승인을 받는 절차를 두는 것입니다. "발송할 대상과 내용을 먼저 보여주고, 승인하면 실행하라"는 한 줄이면 됩니다. 이는 자동화 수준을 낮추는 것이 아닙니다. 되돌릴 수 없는 지점에만 사람의 판단을 배치해, 나머지 구간의 자동화를 안심하고 확대할 수 있게 만드는 설계입니다.

요약

함정 증상 점검 질문 기록의 내부화 창이 닫히면 진행 상황 소실 이 창이 사라져도 이어받을 수 있는가 가변 식별 키 확인 장치가 있어도 중복 발생 내일 다시 돌려도 같은 키가 나오는가 C 등급 단일 통제 오판 시 대외 사고 되돌릴 수 없는 지점에 사람이 있는가

세 함정의 공통점은 5단계를 형식적으로만 이행했다는 데 있습니다. 5단계 테스트를 통과한 직후, 위 세 질문으로 한 번 더 점검하는 것을 표준 절차로 삼으시기를 권고합니다.

---

결론

정상 종료와 중도 중단이 같아 보이는 문제는 AI의 한계가 아니라 운영 설계의 공백에서 비롯됩니다. 시스템은 이미 두 상태를 구분하고 있으며, 조직에 필요한 것은 그 구분을 업무 담당자가 볼 수 있고 이어받을 수 있는 형태로 끌어내는 설계입니다.

5단계 프레임워크의 본질은 단순합니다. 업무를 쪼개고, 위험한 단계를 찾고, 그 앞에 확인 장치를 두고, 매 단계 흔적을 남기고, 실제로 끊어서 검증하는 것입니다. 이 과정을 거친 업무는 몇 번을 다시 돌려도 같은 결과를 내는 업무, 즉 재실행에 안전한 업무가 됩니다. 이것이 AI를 일회성 도구가 아닌 신뢰할 수 있는 운영 인프라로 전환하는 첫 번째 조건입니다.