과외 준비를 하다 보면 매일 반복하는 잡무가 꼭 생겨요. 저는 그런 걸 AI에게 예약 작업으로 맡겨두는 재미에 빠졌습니다. 정해진 시각에 알아서 데이터를 모으고 요약해서 저한테 보내주게요. 그런데 어느 날, 그 예약 작업이 데이터를 거의 다 모아놓고 마지막 조립 단계에서 멈췄어요. 그리고 저에게 도착한 결과물은… 아무것도 없었습니다. 절반이라도 남을 줄 알았는데 0이었어요. 이 오답노트는 “왜 부분 성공이 전체 실패가 됐는가”에 대한 기록입니다.
예약 작업은 이렇게 생겼다
먼저 그림을 그려볼게요. 제가 걸어둔 자동 루틴은 정해진 시각에 스스로 깨어나서, 여러 곳에서 실시간 데이터를 불러온 다음, 그걸 사람이 읽기 좋은 요약으로 조립해 메신저로 보내는 흐름이었어요. 데이터 호출이 여러 건이고, 마지막에 그것들을 하나의 브리핑으로 엮어서 전송하는 게 결승선이었죠.
그날 로그를 보니 데이터 호출은 다 나갔어요. 여러 건의 시세, 공시 조회, 뉴스까지 필요한 요청은 전부 보냈습니다. 문제는 그다음이었어요.
결승선을 코앞에 두고 끊겼다
수집 도중 호출 하나가 끊겼고, 루틴은 Retrying the calls that were interrupted(중단된 호출을 재시도합니다)라며 재시도에 들어갔어요. 그리고 그 재시도 직후 작업 기록이 그냥 끝나 있었습니다. 마지막 조립(요약 브리핑 만들기)과 전송(메신저로 보내기)까지 도달하지 못한 거예요.
여기서 이상한 점. 데이터는 거의 다 받아놨는데, 왜 받아둔 것마저 하나도 안 남았을까요? 절반이라도 건졌어야 정상 아닌가요? 이 질문이 이 글의 핵심입니다.
왜 통째로 사라졌나 — ‘무상태 단발’ 설계
먼저 이 설계를 변호부터 할게요. 그래야 반전이 살거든요.
제 예약 루틴은 매 실행이 이전 대화의 기억 없이, 그날 지침만으로 처음부터 끝까지 완결되도록 짜여 있었어요. 이걸 어려운 말로 무상태(stateless, 이전 상태를 기억하지 않음) 단발 실행이라고 해요. 이게 왜 합리적이냐면, 기억을 안 가지니까 매번 똑같이 재현되고(어제 실행이 오늘에 영향을 안 줌), 중간에 꼬인 상태가 다음 실행으로 새지 않아요. 자동화에서 이건 꽤 큰 장점입니다.
무상태(stateless): 매 실행이 과거를 기억하지 않고 백지에서 시작하는 방식이에요. 장점은 예측 가능성(늘 같은 입력이면 같은 동작)과 깔끔함(오염된 상태가 안 쌓임). 학생마다 새 시험지로 채점하는 것과 비슷하죠 — 앞 학생 답이 다음 채점에 안 섞이니까요.
그런데 이 장점의 정확히 뒷면이 이번 사고였어요. 기억을 안 가진다는 건, 실행이 중간에 끊기면 그때까지 받아둔 데이터도 어디에도 안 남는다는 뜻이거든요. 백지에서 시작해 한 번에 완결하는 구조라, 완결에 도달하지 못하면 손에 쥔 게 통째로 날아갑니다. 그러니 이건 코드가 틀려서 난 버그가 아니라, 무상태 단발이라는 선택이 치르는 대가예요. 편리함과 맞바꾼 트레이드오프인 거죠.
진짜 축 — “데이터 없음” 지침이 못 막은 이유
사실 제 지침에는 안전장치가 있었어요. 데이터가 실패하면 ‘데이터 없음’이라고 표기하고 계속 진행하라 — 이런 규칙이요. 그래서 저는 당연히 이번에도 “데이터 없음”이라도 찍힌 브리핑이 올 줄 알았죠.
그런데 안 왔어요. 왜일까요? 그 지침이 대비한 상황과 실제로 벌어진 상황이 달랐기 때문이에요. 이게 이 글에서 제일 중요한 대목입니다.
- 지침이 대비한 것: 도구가 응답은 했는데 그 내용이 비었을 때 → “데이터 없음”으로 표기하고 진행.
- 실제로 벌어진 것: 실행 자체가 중간에 끊겼을 때 → 표기고 진행이고 할 코드에 도달조차 못 함.
즉 “데이터 없음” 규칙은 빈 응답을 대비했지, 실행의 중단을 대비하지 못했어요. 안전장치가 지키는 자리와 사고가 난 자리가 어긋나 있었던 거죠. 안전장치가 있다고 다 막히는 게 아니라, 그 장치가 정확히 어떤 상황을 막도록 설계됐는지를 봐야 한다는 걸 이 사고로 배웠어요.
그래서 어떻게? — 아직 안 고쳤습니다
정직하게 말하면, 저는 이걸 아직 수리하지 않았어요. 이 글은 “이렇게 하면 된다”가 아니라 “이렇게 해야 한다는 걸 이 사고로 알았다”까지입니다. 방향은 잡았어요.
핵심은 중간에 받아둔 값을 버리지 않는 것이에요. 재시도로 넘어갈 때 이미 확보한 데이터를 어딘가에 남겨두면(체크포인트), 실행이 끊겨도 확보분만이라도 “부분 브리핑”으로 보낼 수 있어요. 그러면 “전부 아니면 전무”가 “적어도 일부는”으로 바뀌죠.
| 신호 | 무엇을 뜻하나 | 액션 |
|---|---|---|
| 예약 작업이 끝나기 직전 멈춤 | 무상태 단발이면 중간 산출물이 안 남음 | 🔴 지금: 부분 산출을 저장하는지 점검 |
| “실패 시 이렇게” 지침이 안 먹힘 | 그 지침이 대비한 상황과 실제가 다름 | 🔴 지금: 빈 응답 vs 실행 중단을 구분 |
| 재시도 후 결과 0 | 재시도가 확보분을 버리고 처음부터 | 🟡 백로그: 체크포인트/부분 발송 도입 |
| 매 실행을 백지에서 완결 | 재현성은 좋지만 중단에 약함 | 🟢 계속: 트레이드오프로 이해하고 설계 |
한마디로, 자동화가 “전부 아니면 전무”로 동작하고 있지 않은지 확인하라는 거예요. 무상태 단발은 깔끔하고 재현성이 좋지만, 그 대가로 중단에 약합니다. 안전장치를 하나 걸어뒀더라도 그게 어떤 실패를 막는 장치인지까지 따져봐야, 저처럼 “데이터 없음조차 안 오는” 날을 피할 수 있어요.