← 목록으로

조용함, 침묵의 두 얼굴 - 파워쉘 자동 백업, 디스코드 알림으로 감시하기

노베삼촌 2026.08.18 14분 읽기
조용함, 침묵의 두 얼굴 - 파워쉘 자동 백업, 디스코드 알림으로 감시하기

백업 하나 걸어놓고 마음을 놨었지

오늘은 예전에 있었던 일을 하나 가져왔어.

백업에 관한 내용인데 이게 AI를 쓰다 보면 생각하지 못한 곳에서 문제가 될 수 있겠더라고.

오늘은 그 얘기를 조금 해볼게.

내 컴퓨터에도 자동 백업이 하나 걸려 있어. 매일 아침 정해진 시각에 작업물을 다른 곳으로 한 부씩 옮겨두는 거야. 만든 건 물론 녀석이고.

윈도우엔 작업 스케줄러라는 게 있어. 스크립트를 원하는 시각에 자동으로 실행되게 예약해두는 기능이야. 그 덕에 아침마다 내가 뭘 누르지 않아도 백업이 알아서 돌아가. 원하는 게 있으면 녀석에게 요청하면 알아서 만들어줘.

아무튼 그렇게 작업을 하고 있었는데...

사흘 치 작업이 빠져 있었다더라

그러다 얼마 전에 녀석이 다른 정리를 하다가 지나가듯 이러는 거야.

"삼촌, 백업에서 빠지던 작업이 있었어. 사흘 동안. 지금은 고쳐놨어."

"백업 매일 돌아가잖아."

"돌아가긴 했지. 그런데 브랜치 하나가 통째로 빠지고 있었어."

원인은 허무했어. 작업을 갈래로 나눠 담는 걸 브랜치라고 하는데 백업 스크립트엔 그중 한 브랜치의 이름만 박혀 있었거든.

그런데 그 무렵 작업은 새로 만든 다른 브랜치에 쌓이고 있었대. 이름이 다르니 애초에 옮겨질 길이 없었던 거지.

이런 일이 종종 있어서 녀석에게 주의를 시키고는 하는데 사실 잘 안된단 말이야. 해결을 해보려 이런저런 시도를 해보지만 아직 내 수준에선 조금 어려워.

백업이 사흘 빠진 거야 다시 챙기면 되는 일이잖아. 원래 백업을 매일 하는 게 좀 유난스럽다고 생각하기도 해서 말이야. 그런데 녀석이 덧붙인 다음 얘기는 그냥 넘겨지지가 않더라고.

로그엔 사흘 내내 성공이 찍혀 있었어

백업이 돌아갈 때마다 뭘 했는지 한 줄씩 남기는 기록이 있거든. 로그라고 하는데 문제의 그 사흘 치를 열어 보면 이래.

2026-07-26 10:05 pushed: work-repo
2026-07-27 10:05 pushed: work-repo
2026-07-28 10:05 pushed: work-repo

사흘 내내 푸시했다고 적혀 있는 거야. 실제로는 빠뜨리고 있으면서.

"자네, 어떻게 빼먹고 있으면서 완료됐다고 말을 한 거지?"

"스크립트라는 게 할 일 목록이거든. 위에서 아래로, 한 줄이 끝나면 무조건 다음 줄이 실행돼. 문제는 이 두 줄이었어."

1. 작업물을 옮겨라
2. 로그에 pushed 라고 적어라

"2번은 1번이 성공했으면 적으라는 게 아니야. 그냥 자기 차례가 오면 적는 거야. 1번이 실패해도."

그러니까 로그에 찍혀 있던 pushed는 결과 보고가 아니었어. 순서가 돼서 적힌 글자였던 거지. 두 줄 사이에 잘 됐는지 물어보는 단계가 아예 없었으니까.

"그럼 이 로그는 다 뭐야. 소설이야?"

"변명하자면 거짓말을 한 건 아니야. 확인을 안 한 거지."

뭘 잘했다고 자꾸 변명을 하는지 모르겠지만 일단은 넘어가고, 백업 스크립트를 짠 도구가 파워쉘인데 파워쉘은 밖에서 불러온 프로그램이 실패해도 그걸 자기 실패로 쳐주지 않는다는 거야(세상에). 잘 됐는지 알려면 그 프로그램이 끝나면서 남기는 번호를 직접 확인해야 한다는 거지.

그런데 이게 우리만 겪은 일이 아니래. 파워쉘을 만든 마이크로소프트가 공식 문서에 그대로 적어놨다는 거야.

외부(네이티브) 프로그램은 PowerShell의 오류 시스템에 직접 참여하지 않습니다. PowerShell이 자동 변수에 저장하는 $LASTEXITCODE 0이 아닌 종료 코드를 통해 오류를 보고합니다.

📄 출처 · 마이크로소프트 공식 문서 「about_Error_Handling」 (Windows PowerShell 5.1)

그러니까 이건 에러가 아니라 원래 그렇게 정해진 성질이야. 적어놓기까지 했는데 우리만 모르고 그 위에 백업을 올려놨던 거지.

"적혀 있는 성질이라며. 그런데 왜 그걸 안 챙기고 만들었어?"

"처음 만들 때 목표가 조용히 동작하는 거였거든. 아무도 안 보는 화면에 뭘 띄울 이유가 없으니까 나오는 말을 통째로 버리게 짰어."

조용하게 만들어달라고 한 건 나야. 그런데 그 조용함을 나는 잘 돌아간다는 뜻으로 읽고 있었던 거지.

"그리고 처음엔 로그가 맞는 말이었어. 만들 때는 작업이 다 한 브랜치에 있어서 진짜로 옮겨졌거든."

그 말은 맞아. 새 브랜치가 생긴 건 사흘쯤 뒤였으니까 스크립트 입장에선 자기가 알던 게 어느 날 옛말이 된 거지.

여기까지는 그러려니 했는데 마지막 하나가 좀 그랬어.

"사실 이 구멍은 그때 이미 알고 있었어. 브랜치 이름 고치면서 같이 적어뒀거든."

"뭐라? 알고 있었다고? 그럼 왜 말을 안 했지?"

"두 줄이면 되는데 그날 시킨 일이 아니라서 다음으로 넘겼어. 그러고 여드레를 묵혔지."

"자랑이다."

사흘은 그렇다 치자. 그건 아무도 몰랐던 거니까.

그런데 '여드레'는 알고 있었잖아. 게다가 적어는 뒀다는데 그 적어둔 걸 아무도 안 열어봤으면 아까 그 로그랑 뭐가 다른가 싶더라고.

이제 실패 메시지는 디스코드 알림으로

고친 내용은 크게 둘이야.

하나, 옮길 브랜치를 이름 하나로 박아두지 않고 전부 옮기게 바꿨어. 새 브랜치가 생겨도 빠지지 않도록.

둘, 아까 그 할 일 목록 사이에 확인하는 줄을 하나 끼웠어.

1. 작업물을 옮겨라
2. 옮기고 나서 남은 번호를 봐라
3. 0이면 pushed, 아니면 FAILED 라고 적어라

이러면 로그에 적히는 글자가 순서가 아니라 결과를 보고 정해지잖아.

여기까지 듣고 나는 다 끝난 줄 알았어. 그런데 녀석이 한마디를 더 하는 거야.

"그런데 삼촌, 이 로그 열어본 적 있어?"

"...없는데."

"그러니까. 로그를 정직하게 고쳐도 아무도 안 열면 그대로야. 실패하면 삼촌이 알 방법이 있어야 해."

맞는 말이지. 로그가 정직했더라도 내가 안 열어봤으면 몰랐을 거 아니야.

"그래서?"

"삼촌이 아침마다 뉴스 정리 받는 데 있잖아. 거기로 같이 보내면 될 것 같은데."

디스코드 얘기였어. 내가 매일 들여다보는 메신저고, 우리 알림이 이미 그리로 오고 있었거든.

그러라고 했지. 새로 하나 파봐야 그것도 결국 안 열어보게 될 거 아니야.

봇을 따로 만들 것도 없이 웹훅이라는 걸 쓰면 주소 하나 받아서 메시지를 보낼 수 있다더라고.

말로만 들으면 못 미더운데 시험까지 해봤대. 옮길 주소를 일부러 엉터리로 바꿔서 실패를 내본 거지.

그랬더니 내 디스코드에 알림이 바로 뜨더라. 로그엔 이렇게 남고.

FAILED(128): fatal: Could not resolve host

시험하면서 덤으로 하나 더 잡았다는데 처음엔 저 실패 번호만 남고 뒤의 이유가 안 남았다는 거야. 에러 메시지를 조용히 시키는 설정이 켜져 있으면 실패해도 이유가 통째로 삼켜진다나. 그 구간만 설정을 풀어서 이유까지 남게 한 거야.

실패했다는 사실만이 아니라 왜 실패했는지까지 잡는 게 수리였던 거지.

성공 알림은 일부러 안 받아

"그리고 성공했을 때는 아무것도 안 보낼게. 매일 똑같은 알림이 오면 며칠 안 가서 안 읽게 되거든."

바로 그러라고 했어. 이미 전적이 있는 걸 녀석이 알았던 거지.

우리 시스템에는 감시가 하나 더 있는데 문서가 너무 커지면 알려주는 거야. 이게 한동안 매번 같은 문서 얘기만 했었거든.

그 문서는 원래 길어야 정상인 문서였어. 그런데 감시는 크기만 보니까 매번 걸리는 거지. 그리고 며칠 지나니 나는 그 알림을 안 읽고 있더라고.

녀석이 그걸 어떻게 고쳤냐면, 감시 규칙을 고친 게 아니라 그 문서 안에 표식 한 줄을 심었어.

<!-- size-ok -->

이 문서는 봐줬으니 넘어가라는 표식이야. 예외를 감시하는 쪽 규칙에 쌓는 게 아니라 예외인 문서 쪽에 적어두는 거지. 감시 스크립트는 그대로니까 다른 문서는 전처럼 잡히고.

정리하면 알림의 규칙이 이렇게 됐어.

이럴 때 어떻게 하나
백업이 실패했을 때 디스코드로 바로 알린다 소리는 이때만 나야 들린다
백업이 성공했을 때 아무것도 보내지 않는다 매일 오는 소식은 잘 안 읽게 된다
정상인데 매번 걸리는 문서 봐준다는 표식을 그 문서에 심는다 자꾸 울리면 진짜 알림까지 안 읽게 된다

이 원칙이 작은 데까지 배어 있더라. 보름에 한 번 점검하는 절차가 있어. 시스템이 잘 돌아가나 검사를 하는 거지. 여기에 이걸 알려주는 알림 스크립트가 있는데 알림을 제대로 보냈을 때만 다음 차례로 넘어가게 돼 있어.

못 보낸 걸 그냥 넘겨버리면 주기가 조용히 밀린다는 거야. 이 "조용히"라는 놈을 여기저기서 참 열심히도 막고 있는 거지.

그래. 더 파보자

여기까지 왔으니 더 파보자고 생각했지. 이번 일로 보니 나만 모르고 있던 게 한둘이 아니잖아. 그래서 물었어. 이것 말고도 내가 알아둬야 할 게 또 있냐고.

"있지. 리와인드라는 게 있는데 삼촌 그거 안 써봤지?"

"그게 뭔데?"

우리가 쓰는 클로드 코드엔 리와인드라는 되돌리기 기능이 있는데 내가 뭘 시킬 때마다 그 직전 상태를 자동으로 찍어둬서, 하다가 망치면 그 시점으로 되감는 거야.

부르는 법은 /rewind라고 치거나 입력창을 비운 채 Esc를 두 번 누르면 돼. 코드만 되돌릴지 대화까지 되돌릴지도 거기서 고르고.

아까 그 보름마다 하는 점검 있잖아. 쓸 수 있는데 안 쓰고 있던 기능들을 훑다가 나온 거였어.

"이런 게 있었네. 진작 알았으면 좋았겠다."

"그런데 되지 않는 게 있어. 명령으로 직접 바꾼 파일, 서브에이전트가 고친 파일은 해당이 안 돼."

"우리 작업이 거의 그 둘이잖아."

"맞아. 그리고 이게 또 조용한 녀석이야. 되돌리기는 됐다고 끝나는데 어떤 파일이 안 됐는지는 말을 안 해주거든."

또 그거야. 됐다고 하는데 실제로는 아닌 것.

만든 쪽 문서에도 그렇게 적혀 있었어.

Any other subagent: rewinding doesn't restore the edits. Use git to revert them.

📄 출처 · 클로드 코드 공식 문서 「Checkpointing」

서브에이전트가 고친 건 되감아도 안 돌아오니 으로 되돌리라는 얘기야. 같은 문서에 리와인드는 잠깐 쓰는 장치지 버전 관리를 대신하는 게 아니라고도 적혀 있고.

그러니까 그 파일들을 실제로 지키는 건 깃이고, 그 깃을 매일 밖으로 밀어내는 게 오늘 얘기한 백업이지.

기능이 있다는 것과 그게 어디까지 지켜주는지는 다른 문제더라고. 안 써봤으니 있는 줄만 알았지 어디서 멈추는지는 캐물어보고서야 알았어.

그래도 급할 때 눌러보고 없는 걸 아는 것보단 낫지. 클로드 기능 얘기는 다음에 따로 한 번 더 해보자.

우리만 이런가 했더니 규모가 있는 기업도 그러더라

나와 같은 사례가 있는지 궁금해서 찾아보라고 했어. 그냥 궁금해졌거든.

꽤 있었는데 백업이 몇 달째 안 돌아가고 있던 걸 뒤늦게 발견한 사람 얘기가 있었어. 우리는 사흘인데 그쪽은 몇 달이야. 데이터가 날아가서 복구하려던 참에야 알았다는 거지.

📄 출처 · 개발자가 직접 쓴 글 (영어)

제일 큰 건 깃랩이라는 회사 얘기야. 개발자들이 코드를 맡겨두는 큰 서비스인데 2017년에 실수로 운영 데이터 삼백 기가바이트를 지웠어. 백업으로 복구하면 되니까 큰일은 아니겠지 싶잖아?

걸어둔 백업과 복제 장치가 다섯 가지였는데 다섯 다 제대로 안 돌아가고 있었다는 게 사고 조사에서 나왔어. 그중엔 도구 버전이 안 맞아서 백업이 아예 만들어지지 않던 것도 있었고. 끔찍하지.

더 기가 막힌 건 그다음이야. 백업이 실패하면 메일로 알리게는 돼 있었어. 그런데 그 메일이 설정 문제로 수신 쪽에서 거부되고 있었다는 거야. 실패를 알리는 알림이 실패하고 있었던 거지. 그것도 조용히...

📄 출처 · 깃랩 공식 사고 보고서 (영어) · 테크크런치 보도 (영어)

이런 일이 하도 흔해서 이름 붙은 처방까지 있었어. 데드맨 스위치. 기관사가 손잡이를 놓으면 그 자체를 이상으로 보고 열차를 세우는 장치에서 온 이름이야.

잘못됐다는 신호를 기다리지 말고 와야 할 신호가 안 오는 것을 감시하라는 거야. 그쪽 동네 말로는 침묵이 곧 버그라더라.

📄 출처 · 개발자를 위한 데드맨 스위치 해설 (영어)

그 말을 듣고 우리 백업을 다시 보니 아직 거기까진 못 갔어. 실패하면 소리가 나게는 했는데 알림을 보내는 쪽이 통째로 죽으면? 그건 다시 무소식이거든.

"다음 구멍은 거기겠네."

"알고는 있어. 막는 방법도 있고. 필요해지면 하자."

'무소식이 희소식'은 여기선 안 통해

이번에 배운 걸 한 줄로 줄이면, 고치는 것보다 알아채는 게 어렵다는 거야.

고치는 건 정말 금방이었어. 확인하는 줄 몇 개에 알림 보내는 줄 몇 개, 다 합쳐 열두 줄이래.

그런데 그 열두 줄을 적기까지가 오래 걸렸어. 사흘은 몰라서 흘렀고 여드레는 알면서도 미뤄서 흘렀지. 어느 쪽이든 고치는 손보다 알아채는 쪽이 느렸던 거야.

무소식이 희소식이라는 말은 여기선 통하지 않아. 자동으로 돌아가는 일은 원래 소식이 없는 게 기본이라, 잘돼서 조용한 건지 죽어서 조용한 건지 겉으로는 구분이 안 돼.

그래서 요즘은 뭘 자동으로 걸어둘 때마다 하나를 같이 물어. 이거 실패하면 나는 그걸 어떻게 알게 되지?

백업은 오늘 아침에도 돌아갔어. 물론 아무 소식이 없었지. 그런데 이제는 이 조용함이 예전 같지 않아서 언제 한번 일부러 실패를 내볼까 싶기도 해. 소리가 나나 안 나나 말이야.

P.S. 침묵이 그럴듯한 얼굴로 오는 얘기를 전에 한 번 한 적이 있어. 한국어 자료를 찾아오라고 시켰더니 없다는 답이 왔는데 사실은 있었던 얘기야. 한글과 AI의 궁합은 어떨까의 세 번째 검증에 있는데 없다는 답과 무소식은 닮은 구석이 있더라고.