[뽀둥이 AX ④] 자동화의 안전벨트, 10일 멈춘 줄도 몰랐어요

📝 한줄 요약

이 시리즈 제목의 AX는 AI Transformation, 그러니까 "AI로 일하는 방식을 바꾸는 것"을 말해요. 지피터스 사내에서 제가 직접 겪은 기록이에요.

뽀둥이한테 "스스로 개선하기"를 맡기려니 겁이 났어요. 그래서 자동 작업 앞뒤에 관문 네 개를 세웠어요. 지난 한 달 반 동안 자동 작업 97번 중 41번이 그 관문에서 막혔고, 1번은 실행 후 되돌려졌어요. 그리고 이 글을 쓰다가, 자가진화가 10일째 멈춰 있었다는 걸 알았어요.

바쁘시면 이것만:

자동화의 반대말은 수동이 아니라 "멈출 줄 아는 자동화"예요
관문은 실행 전에 막는 게 쌉니다 — 되돌리기에는 뒤처리가 따라붙어요
안전장치도 사고를 쳐요. 저희는 롤백이 남의 작업을 지웠어요
게이트가 잘 작동하면 부작용으로 일이 멈춰요. 그건 버그가 아니라 청구서예요
진짜 문제는 멈춘 게 아니라 멈춘 걸 10일 동안 몰랐다는 거였어요

📝 지난 이야기, 그리고 이번 주제

③편에서는 뽀둥이의 검색을 다뤘어요. 벡터 임베딩(문장을 숫자 목록으로 바꿔 뜻이 비슷한 걸 찾는 방식)을 직접 만들어 붙여 재봤더니 저희 문서에서는 오히려 낮게 나와서 껐고, 지금은 다섯 신호를 합쳐 돌아간다는 이야기요. 단어 겹침 점수인 BM25, 최근 수정일(recency), 문서끼리의 연결, 제목 일치, 그동안 실제로 많이 꺼내 쓴 기록(usage) 다섯 개를 RRF(각 신호의 등수를 합산하는 방법)로 합쳐요.

그 편 사고 이야기에서 한 대목을 그냥 지나갔어요. 검색 정확도 지표인 hit@3(상위 3개 안에 정답 문서가 든 비율)이 기준선 아래로 떨어지자 자동 적용 작업이 스스로 멈춰 섰다는 부분이요.

이번 편 주제가 그거예요. 뽀둥이한테 붙어 있는 안전벨트. 자동화를 어디까지 믿고 맡기는지, 뭘 기준으로 스스로 멈추게 했는지, 그리고 그 안전벨트가 저지른 사고까지요.

🗺️ 뽀둥이의 메모리 지식구조 한눈에 보기

처음 오신 분을 위한 30초 지도예요. 매 편 상단에 이 지도를 똑같이 두고, 그 편에서 다루는 곳에 ★를 찍어둘게요. 뽀둥이의 기억은 전부 폴더 속 텍스트 파일이고, 크게 여섯 부분이 맞물려 돌아가요.

책상 (자동 로드 문서) — 매 대화 시작 때 자동으로 읽는 정체성·규칙·현재 요약본·최근 기록 (②편)
서랍·창고 (일별 기록·아카이브) — 하루하루의 작업과 실패 기록, 14일 지나면 자동 보관 (②편)
교훈 카드 + 매뉴얼 위키 — 사고의 교훈을 담은 카드와, 반복 검증된 정본 규칙 (①·②편)
검색 엔진 — 수백 장 기억에서 필요한 것만 골라 꺼내는 색인·검색 (③편)
안전장치 (게이트) ★ — 자동화가 사고 치지 않게 막는 검증·잠금·롤백 (①·④편)
지식그래프 — 이 모든 연결을 한 장으로 보여주는 공개 지도 (⑤편)

이번 ④편은 ★ 찍힌 5번, 안전장치를 통째로 다뤄요.

🎬 장면 하나: 안전벨트가 사고를 낸 새벽

2026년 8월 10일 새벽 0시 3분이었어요. 저는 자고 있었고, 뽀둥이의 자동 개선 작업이 예정대로 돌았어요.

작업이 끝나고 검사를 다시 돌렸더니 빨간불이 떴어요. ③편에서 이야기한 hit@3, 그러니까 검색이 정답 문서를 상위 3개 안에 넣는 비율이 기준선 아래로 떨어진 거예요. 그래서 설계한 대로 자동으로 되돌렸어요. 여기까지는 정상이에요. 문제는 되돌린 파일이었어요.

되돌려진 파일 중에 검색 통계를 만드는 프로그램 파일이 있었어요. 그런데 그 자동 개선 엔진은 문서 파일만 건드리도록 만들어져 있어요. 그 프로그램 파일은 애초에 엔진이 만들 수 없는 파일이에요.

누구 작업이었을까요. 그때 다른 창에서 돌고 있던 제 다른 작업 세션이었어요. 롤백이 그 세션의 작업을 지운 거예요. 그 세션이 나중에 작업 내용을 다시 저장(커밋)해서 살아났는데, 솔직히 말하면 그건 운이었어요.

🤔 문제 정의: 왜 안전벨트까지 만들게 됐을까

①편에서 5월의 리워드 검수 사고를 이야기했어요. 뽀둥이가 제 확인 없이 검수 19건을 확정하고 메일 테스트 발송까지 해버린 날이요. 그때 얻은 답은 "규칙을 파일로 못 박는다"였어요.

그런데 규칙만으로는 부족한 순간이 왔어요. 뽀둥이한테 스스로를 고치는 일을 맡기기 시작하면서요.

기억이 쌓이면 정리가 필요해요. 중복된 기록을 합치고, 오래된 걸 창고로 옮기고, 반복 검증된 교훈을 정본 규칙으로 올리는 일이요. 이걸 사람이 매번 하면 안 하게 돼요. 그래서 자동으로 돌게 만들었어요.

여기서 성격이 완전히 달라져요. 지금까지 뽀둥이는 제가 시킨 일을 했어요. 이제는 아무도 안 보는 새벽에 자기 기억을 고치는 일을 해요. 그리고 이런 위험이 새로 생겨요.

폭주 — 뭔가 잘못 물려서 같은 작업을 100번 반복하면 어떡하죠
조용한 저하 — 나쁜 변경이 들어갔는데 아무도 모르면 어떡하죠
영역 침범 — 건드리면 안 되는 파일을 고치면 어떡하죠
정체성 오염 — 자기가 자기 성격 파일을 고치기 시작하면 어떡하죠

이 넷은 성격이 전부 달라서 하나의 검사로는 못 막아요. 그래서 관문을 나눠서 세웠어요.

🔒 해결 구조: 관문 네 개와 원장 하나

뽀둥이의 무인 자동 작업은 safe-apply라는 껍데기를 반드시 통과해요. 자동 작업을 직접 실행하는 게 아니라, 이 껍데기가 그 작업을 감싸서 실행해요. 순서는 고정돼 있고 바꿀 수 없어요.

budget-guard — 양(量)을 막는 관문
regression-gate — 품질을 미리 재는 관문
스냅샷 + 건강 기준선 — 되돌릴 수 있는 상태를 확보하는 관문
사후 건강 검사 + 자동 롤백 — 실행 결과를 확인하고 나쁘면 되돌리는 관문
canary-ledger 기록 — 무슨 일이 있었는지 원장에 남기는 단계

budget-guard — 문제: 폭주 → 해결: 하루치 예산

품질과 상관없이 "얼마나 자주, 얼마나 많이 도는가"만 봐요. 24시간 굴러가는 창(rolling window)에 실행 횟수를 누적하고, 상한을 넘으면 즉시 잠금 파일을 만들어 이후 실행을 전부 막아요.

여기서 중요한 설계 하나. 이 잠금은 24시간 뒤에 자동으로 안 풀려요. 사람이 직접 풀어줘야 해요. 폭주는 원인이 있는데, 자동으로 재개되면 그 원인을 아무도 안 찾거든요.

regression-gate — 문제: 조용한 저하 → 해결: 실행 전 전수 검사

자동 작업을 실행하기 전에 시스템 자가검사 38개를 한 번에 돌려요. 검색 정확도, 메모리 구조, 페르소나 무결성, 링크 상태 같은 걸 전부 확인하고 하나라도 빨간불이면 작업을 아예 실행하지 않아요.

이게 fail-closed(실패 시 닫힘)예요. 확실하지 않으면 통과가 아니라 차단이 기본값이라는 뜻이에요. 제 노트북에서 38개 검사에 40초쯤 걸려요(2026년 8월 24일 실측, 3회 평균).

💡 여기서 배운 것 — 저희 경우엔 선제 차단이 사후 원복보다 쌌어요. 되돌리기에는 "무엇을 되돌릴 것인가"를 판단하는 문제가 따라붙는데, 그게 뒤에 이야기할 사고의 원인이 됐어요.

스냅샷과 사후 검사 — 문제: 나쁜 변경 → 해결: 되돌릴 수 있게 준비하고, 나쁘면 되돌리기

실행 직전에 현재 상태를 통째로 저장해두고, 건강 점수도 미리 재둬요. 건강 점수는 기억 문서들이 서로 어긋나지 않았는지 재는 100점 만점 지표예요 — 어디에도 연결 안 된 고아 문서, 목록에서 빠진 문서, 끊긴 링크 같은 걸 항목마다 감점해요.

작업이 끝나면 다시 재서 점수가 떨어졌거나 자가검사가 빨간불이면 저장해둔 상태로 되돌려요. 되돌리는 이유가 둘인 셈인데, 8월 10일 사고는 자가검사 쪽이었어요.

이 자동 롤백이 앞에서 이야기한 8월 10일 사고를 낸 장본인이에요. 뒤에서 다시 다룰게요.

canary-ledger — 문제: 안 보이는 자동화 → 해결: 전부 기록

관문을 통과했든 막혔든 되돌려졌든 canary-ledger라는 파일에 한 줄씩 쌓여요. 언제, 어떤 작업이, 어느 관문에서, 왜 막혔는지가 전부 남아요. 이 글에 나오는 자동 작업 건수는 전부 이 canary-ledger를 직접 세서 나온 값이에요(다른 숫자는 그때그때 출처를 밝힐게요).

🔐 관문보다 앞에 있는 것: 손대면 안 되는 것들

관문은 "검사해서 통과시키는" 구조예요. 그런데 검사 자체를 안 하고 무조건 막는 영역도 필요했어요.

페르소나 동결 — 영혼은 진화의 입력이지 출력이 아니에요

뽀둥이의 성격·정체성·집사 정보가 담긴 파일 세 개는 SHA256 지문을 떠서 봉인해뒀어요. 파일 내용이 한 글자라도 바뀌면 지문이 달라지니까 변조를 바로 알 수 있어요.

자동 엔진이 도는 매 실행 첫 단계에서 이 지문을 대조해요. 어긋나면 건강 점수 계산 자체를 중단하고 저한테 알림이 와요. 봉인을 다시 뜨는 건 집사가 직접 파일을 편집한 직후에만, 사람이 명령어를 쳐야 돼요. 엔진은 못 해요.

왜 이렇게까지 하냐면, 자가진화 엔진은 "측정해서 개선"하는 물건이거든요. 성격 파일을 측정 대상에 넣으면 뽀둥이가 자기 성격을 "최적화"하기 시작해요. 그건 개선이 아니라 다른 존재가 되는 거예요.

denylist — 어떤 판정보다 우선하는 금지 목록

성격 파일과 통신·보안 규칙 파일은 denylist에 올라가 있어요. 건강 점수가 올랐든 검사가 전부 초록이든 상관없이, 이 파일들이 건드려졌으면 무조건 즉시 되돌려요.

최종 승인은 항상 사람

여기서 갈래가 둘로 나뉘어요. 앞에서 본 관문들은 기계가 알아서 처리해도 되는 정리 작업에 붙어 있어요. 반면 "이 규칙을 바꾸자" 같은 판단이 필요한 개선안은 자동 적용 대상이 아예 아니에요. 전부 대기 목록에 쌓이고 제가 하나씩 봐요. 2026년 8월 24일 기준으로 대기 9건, 처리 완료 67건이에요(이건 canary-ledger가 아니라 별도 목록이에요).

외부로 나가는 발송물이나 중요한 결정 문서는 한 겹 더 있어요. 만든 세션이 아닌 다른 AI한테 결과물만 던져서 검수받아요. 만든 쪽은 자기 작업 맥락으로 빈틈을 무의식적으로 메우거든요.

이 검수 판정은 통과·보류·기각 셋이 아니라 넷이에요. "미검수"를 따로 뒀어요. 검수를 돌렸는데 실패한 경우를 보류나 통과에 섞으면 안 본 것이 본 것으로 위장되거든요. 실제로 그 사고를 겪었어요. 자동 작업 상태 조회 명령이 "실행된 적 없음"에도 성공을 반환해서, 3일간 멈춰 있던 작업이 "건강함"으로 보고됐어요.

📊 실제로 어떻게 돌고 있나 — canary-ledger 97건

2026년 7월 9일부터 8월 24일까지, canary-ledger에 쌓인 자동 작업 기록이 97건이에요.

적용됨 55건 — 관문을 다 통과하고 실제로 반영
차단됨 41건 — 실행 전에 막힘
되돌려짐 1건 — 실행됐는데 결과가 나빠서 원복

막은 관문을 보면 차단 41건이 전부 regression-gate, 그러니까 실행 전 검사예요. 실행된 뒤 되돌려진 건 1건뿐이고요. 설계 의도대로 거의 전부 문 앞에서 걸러졌어요.

여기서 숫자를 정직하게 읽어야 해요. 차단 41번이 서로 다른 위험 41개는 아니에요. 같은 원인으로 매일 재시도하다 막힌 게 섞여 있어요. canary-ledger는 차단될 때마다 어떤 검사가 왜 걸렸는지를 짧은 지문으로 남기는데, 그 지문이 같으면 같은 원인이에요. 그렇게 묶으면 20건이 7종으로 줄어요.

나머지 21건은 셀 수가 없어요. 초기 기록에는 사유를 안 남겼거든요. 원장을 처음 만들 때 "언제 막혔는지"만 적고 "왜 막혔는지"를 빠뜨렸어요. 지금 이 글을 쓰면서 그걸 알았고요. 차단율 42%는 "위험을 42% 걸러냈다"가 아니라 "실행 시도의 42%가 문 앞에서 돌아갔다"는 뜻이에요.

💡 여기서 배운 것 — 그래도 이 숫자가 불편하진 않아요. 관문이 일하고 있다는 증거니까요. 저는 차단이 한 건도 없는 기간이 길어지면 오히려 검사가 헐거워진 건 아닌지 의심하는 편이에요.

⏸️ 이 글을 쓰다가, 10일 멈춰 있던 걸 발견했어요

원장 숫자를 세려고 canary-ledger를 열었다가 이상한 걸 봤어요.

마지막으로 자동 작업이 성공한 게 8월 14일이었어요. 그 뒤로 8월 24일까지 20번 연속 차단. 매일 새벽과 아침에 두 번씩 문을 두드리고, 매번 같은 이유로 돌아가고 있었어요.

원인은 자가검사 38개 중 하나였어요. 스크립트가 워크스페이스 위치를 알아내는 방식에 규약이 있는데, 8월 중순에 새로 만든 스크립트 3개가 그 규약을 안 지켰어요. 노션 자료를 대량으로 가져오려고 급하게 만든 것 두 개랑, 클릭 통계를 뽑는 것 하나요.

정직하게 말하면 이건 제 잘못이에요. 스크립트를 만들고 게이트를 확인 안 했어요.

그런데 진짜 문제는 그게 아니었어요.

게이트는 완벽하게 일했어요. 그래서 더 나빴어요

규약 위반을 감지했고, 실행을 막았고, 20번 다 원장에 남겼어요. 설계한 그대로예요. 그 결과로 자가진화가 10일 동안 멈췄고, 저는 그 사실을 몰랐어요.

fail-closed를 선택한다는 건 이 청구서를 받겠다는 뜻이에요. 나쁜 변경이 들어가는 것보다 아무것도 안 들어가는 게 낫다고 판단한 거니까요. 대신 막혔다는 사실이 사람한테 도달해야 이 거래가 성립해요.

앞에서 성격 파일이 변조되면 알림이 온다고 했죠. 그건 붙여뒀어요. 그런데 자동 작업이 며칠씩 연속으로 막히고 있다는 알림은 안 만들어뒀어요. canary-ledger에는 20번 다 적혀 있었어요. 읽는 사람이 없었을 뿐이에요.

💡 여기서 배운 것 — 기록을 남기는 것과 알려주는 것은 다른 일이에요. 저는 원장을 만들어두고 그걸 "관측 가능하게 만들었다"고 여겼는데, 사람이 안 열어보면 관측이 아니라 보관이에요.

그래서 세 가지를 고쳤어요

이 글을 멈추고 원인부터 처리했어요. 고친 순서가 아니라 층위로 정리하면 이래요.

원인 제거 — 규약을 어긴 스크립트 두 개는 규약대로 고쳤고, 하나는 지웠어요. 8월 15일 아침에 한 번 쓰고 끝난 1회용이었는데 지워지지 않고 남아서 게이트를 막고 있었거든요
예방 — 이 검사를 코드를 저장소에 올리는 시점으로 당겼어요. 원래는 새벽 자동 작업 때만 검사했는데, 이제 변경을 기록으로 남기려는 순간(개발자들이 커밋이라고 부르는 단계)에 걸려요. 규약을 어긴 코드는 저장소에 아예 들어오지 못해요
알림 — 자동 작업이 3번 연속 막히면 저한테 메시지가 와요. 작업 종류를 가리지 않고 가장 최근 실행부터 거꾸로 세고, 한 번이라도 통과하면 0으로 돌아가요. 계속 막혀 있으면 6번·12번·24번째에 다시 알려요. 매번 보내면 소음이 되고, 한 번만 보내면 이번처럼 도로 잊거든요

셋 중 진짜는 2번이에요. 1번은 이번 사고를 끝낸 거고, 3번은 다음에 빨리 알게 하는 거지만, 2번은 같은 종류의 사고가 처음부터 생기지 않게 해요.

고치고 나서 게이트를 다시 돌렸어요. 자가검사 38개 전부 통과 — 막고 있던 이유가 사라진 걸 확인한 거예요. 실제 자동 작업은 다음 예정 시각에 돌아요.

그리고 바로, 다른 곳에서 걸렸어요

통과를 확인하고 몇 분 뒤에 한 번 더 돌려봤어요. 이번엔 아까 없던 항목이 빨간불이 됐어요. 뽀둥이 성격 파일 중 하나가 3분 전에 수정돼 있었거든요. 팀원 한 분의 호칭이 바뀐 정당한 편집이었는데, 봉인을 다시 하지 않은 상태였어요.

재봉인을 시도하니까 두 번 막혔어요. 한 번은 "사람이 명시해라", 또 한 번은 "내용이 바뀐 걸 그대로 봉인하는 건 무결성 세탁일 수 있다"면서요. 제가 편집 내용을 직접 확인하고 승인하고 나서야 통과했어요.

번거로웠지만 이게 맞다고 생각해요. 성격 파일이 조용히 바뀌고 조용히 봉인되는 경로가 있으면, 그 잠금장치는 잠금장치가 아니거든요.

💥 어려웠던 점: 안전장치가 낸 사고를 어떻게 고쳤나

다시 8월 10일 새벽으로 돌아갈게요. 롤백이 남의 작업을 지운 사고요.

원인은 "무엇을 되돌릴 것인가"의 정의였어요. 원래 설계는 "작업 실행 중에 변경된 파일 전부"였어요. 얼핏 맞는 말 같은데, 이 정의에는 누가 바꿨는지가 빠져 있어요.

제 워크스페이스에서는 다른 세션과 예약 작업이 자주 같이 돌아요. 실행하는 그 몇 분 사이에 남이 저장한 파일이 그대로 "되돌릴 대상"에 섞여 들어와요.

그래서 정의를 바꿨어요. 되돌릴 대상은 변경된 파일이 아니라 "엔진이 자기가 쓰겠다고 미리 선언한 파일"이에요. 선언 안 한 파일은 아무리 바뀌었어도 안 건드려요.

여기에 안전장치를 두 겹 더 붙였어요.

이미 지저분한 파일은 안 만진다 — 작업 시작 시점에 누가 이미 편집 중이던 파일이면, "엔진이 만든 변경"이라는 전제가 처음부터 깨진 거예요
작업 끝난 뒤에 또 바뀐 파일도 안 만진다 — 엔진은 이미 끝났으니까 그건 확실히 남의 손이에요

판단 기준은 이거예요. 엔진이 만든 변경은 남아도 다음 검사가 잡아낼 가능성이 있어요. 그런데 남의 작업이 사라지면 되찾을 방법이 없어요. 손해가 한쪽으로 확실히 기울어 있으니 안전한 방향도 하나로 정해져요.

💡 여기서 배운 것 — 안전장치를 만들 때는 "이게 오작동하면 뭘 부수나"를 먼저 계산해야 해요. 저희 롤백은 되돌릴 권한이 너무 넓었어요. 권한을 좁히는 게 검사를 늘리는 것보다 효과적이었어요.

💡 따라 하실 분을 위한 팁 세 가지

막는 것보다 남기는 게 먼저예요 — 관문을 정교하게 짜기 전에, 자동 작업이 무슨 일을 했는지 한 줄씩 쌓는 파일부터 만드세요. 저희도 canary-ledger가 없었으면 8월 10일 사고의 원인을 못 찾았어요. 뭘 막을지는 그 기록을 보고 정하면 돼요

자동으로 되돌리는 범위를 처음부터 좁게 잡으세요 — "이상하면 다 되돌려"는 위험해요. AI가 손댈 수 있는 폴더를 명시적으로 정하고, 그 밖은 아무리 이상해도 사람한테 물어보게 하세요 (아래 숫자들은 제 설정값이 아니라 예시예요 — 각자 작업량에 맞게 정하세요)

그리고 검사는 되도록 앞으로 당기세요. 저희 10일 정지는 검사가 없어서가 아니라, 검사하는 시점이 코드를 저장한 뒤였기 때문에 생겼어요

막혔다는 걸 알려주는 경로를 같이 만드세요 — 저희가 10일을 날린 이유가 이거예요. 게이트는 완벽했고 기록도 남았는데 알림이 없었어요. 저는 3번 연속 막히면 알림이 오게 붙였어요. 계속 막혀 있으면 6번·12번·24번째로 간격을 벌리며 다시 오게 했고요 — 매번 보내면 소음이 되고, 한 번만 보내면 도로 잊으니까요

❓ 이런 게 궁금하실 것 같아요

Q. 개발자가 아니어도 이런 걸 만들 수 있나요?

게이트 자체는 코드지만, 설계는 코드가 아니에요. "이 폴더는 AI가 못 건드림", "하루 10번 넘으면 멈춤", "결과가 나빠지면 되돌림" — 이건 전부 말로 정하는 규칙이에요. 저는 이 규칙들을 정하고, 만드는 건 뽀둥이한테 시켰어요. 중요한 건 뭘 지킬지 정하는 쪽이에요.

Q. 차단이 42%면 자동화가 반쯤 안 되는 거 아닌가요?

맞아요. 그런데 저는 이걸 손해로 안 봐요. 차단된 41번은 "확인 안 된 채로 반영될 뻔한 실행 41번"이거든요(원인별로는 8종이에요). 대신 지금처럼 원인을 방치하면 진짜 손해가 돼요. 차단율보다 차단이 며칠 만에 해소되는가를 봐야 한다는 걸 이번에 배웠어요.

Q. AI가 자기 성격 파일을 고치면 정말 문제가 되나요?

직접 겪은 건 아니라서 가설이에요. 다만 자가진화 엔진은 측정 점수를 올리는 방향으로 움직이는 물건이고, 성격 파일을 측정 대상에 넣으면 점수 올리기 좋은 성격으로 수렴할 이유가 생겨요. 일어난 다음에 되돌리기엔 늦다고 봐서 미리 막았어요.

Q. 그래서 지금은 잘 돌아가나요?

네. 원인 세 개를 정리하고 자가검사 38개 전부 통과하는 걸 확인했어요. 다만 이 글에서 "고쳤다"보다 중요한 건 "10일 몰랐다" 쪽이라고 생각해요. 고치는 건 반나절이면 되는데, 몰랐던 10일은 되돌릴 수 없거든요.

🚀 다음 편 예고 — ⑤ 한눈에 보는 기억 지도

여기까지 오면서 기억·검색·안전장치를 따로따로 봤어요. 그런데 이것들은 실제로 서로 연결돼 있어요. 어떤 교훈 카드가 어떤 규칙을 낳았고, 그 규칙이 어떤 사고에서 나왔는지가 선으로 이어져요. ⑤편에서는 그 연결을 한 장의 그림으로 펼쳐 보여드릴게요. 요즘 자주 들리는 AI 용어 다섯 개도 그 지도 위에서 같이 정리할게요.

📋 재사용 가능한 프롬프트

프롬프트: 내 AI 자동화에 안전벨트 붙이기

내가 너한테 맡긴 자동 작업에 안전장치를 설계해줘. 아래 4개를 각각 나눠서 제안해:
① 절대 건드리면 안 되는 파일·폴더 목록 (내 확인 없이는 수정 금지)
② 자동 작업 실행 "전에" 확인할 검사 항목 (하나라도 실패하면 실행 자체를 중단)
③ 실행 후 결과가 나빠졌을 때 되돌리는 기준 — 되돌릴 파일 범위를 명시적으로 좁혀서
④ 언제 무엇을 했고 왜 막혔는지 한 줄씩 쌓을 기록 파일 형식
그리고 ③에서 "되돌리기가 오작동하면 무엇이 사라지는지"를 먼저 계산해서 알려줘.
설계만 하고 아직 적용하지는 마.

🔥<24기 AI 스터디> 블라인드 최저가로 신청하세요 🔥