AI로 만든 시스템, 6개월 뒤에도 안 터지려면 — "안전장치 먼저" 사고법

AI한테 "만들 수 있냐"를 묻는 순간 이미 반쯤 진 겁니다. 진짜 질문은 "6개월 뒤 새벽에도 조용히 안 터지냐"입니다.

이 글 3줄 요약

• AI로 시스템을 만들 때 완성의 기준은 '기능이 되느냐'가 아니라 '오래 도느냐'다 — 안전장치를 나중에 붙이지 말고 설계에 먼저 박아라.
• AI는 안 만든 걸 조용히 넘긴다. 그래서 안전장치 범주를 목록으로 두고 항목마다 '해당/비해당'을 판정하되, 비해당이라도 반드시 사유를 적게 해서 침묵을 없앤다.
• 앞서 다룬 '안 만드는 것도 이유를 쓰게 한다' 원칙을, 이번엔 시스템을 안 터지게 지키는 '안전장치'에 집중해 심화한다.

만들 수 있냐 vs 안 터지냐 — 기준이 다르다

AI로 뭔가 만들어보면 처음엔 다 신기합니다. 발주를 자동으로 넣고, 급여를 자동으로 계산하고, 재고를 자동으로 정리합니다. 화면에서 버튼 한 번 누르면 원하는 결과가 딱 나옵니다. 데모는 완벽하게 돕니다. 문제는 데모가 완벽한 것과 6개월 뒤에도 조용히 도는 건 완전히 다른 이야기라는 겁니다.

데모가 잘 도는 데는 이유가 있습니다. 그건 내가 만든 바로 그 순간에, 내가 직접 넣은 정상적인 값으로, 아무 방해 없는 조건에서 돌린 결과입니다. 개업 첫날 손님 없는 주방에서 동선을 리허설하는 것과 비슷합니다. 그날은 다 매끄럽습니다. 진짜는 6개월 뒤, 주문이 몰리고 재료가 애매하게 떨어진 금요일 저녁에 드러납니다.

시스템이 무너지는 것도 대개 만든 첫날이 아니라, 아무도 안 보고 있던 어느 평범한 날 새벽입니다. 바깥에서 받아오는 데이터의 형식이 소리 없이 바뀌거나, 로그인 세션이 만료되거나, 예상 못 한 입력값이 하나 들어오는 순간 조용히 멈춥니다. 이런 건 내가 잘못 만들어서라기보다, 세상이 바뀌기 때문에 생깁니다. 어제까지 멀쩡하던 게 오늘 갑자기 안 되는 거죠. 그리고 자동화는 원래 조용하기 때문에, 멈춘 것도 조용합니다.

그래서 빌더가 잡아야 할 진짜 기준은 이겁니다.

'만들 수 있냐'는 AI가 답하기 제일 쉬운 질문입니다. 그래서 그 질문만 하면 AI는 신나게 기능만 채워주고, 정작 오래 버티게 하는 부분은 통째로 비워둡니다. 비워뒀다고 말도 안 해줍니다. 데모가 도는 걸 보고 "완성됐다"고 판단하는 순간, 사실은 가장 위험한 절반을 안 보고 넘긴 겁니다.

한 가지만 기억하면 됩니다. 데모는 "된다"를 증명할 뿐, "오래 된다"를 증명하지 않습니다. 이 둘을 같은 걸로 착각하는 데서 6개월 뒤의 사고가 시작됩니다.

조용한 실패가 왜 무서운가

자동화의 성질을 하나 짚고 갑시다. 우리가 매장에 붙이는 자동화 상당수는 '정해진 시간에 알아서 도는' 방식입니다. 매일 새벽 몇 시에 재고를 확인하고, 정해진 요일에 정산을 돌리고, 마감 후에 매출을 정리합니다. 사람이 매번 버튼을 누르는 게 아니라, 시계처럼 스스로 돕니다. 이렇게 '예약된 시각에 자동 실행되는' 구조를 흔히 스케줄 실행이라고 부릅니다. 편하지만, 바로 그 편함이 함정입니다.

이런 자동화는 성공하면 아무 말이 없습니다. 발주가 잘 나갔어도 조용하고, 정산이 잘 됐어도 조용합니다. 문제는 죽었을 때도 똑같이 조용하다는 겁니다. 그러니 겉으로 보이는 '조용함'만으로는 지금 잘 돌고 있는 건지, 아니면 며칠 전에 죽어서 조용한 건지 구분이 안 됩니다. 사장님 눈엔 둘 다 똑같이 '아무 일 없음'으로 보입니다.

주방으로 치면 이렇습니다. 냉장고가 잘 돌 때도 조용하고, 밤새 꺼져서 안이 다 상했을 때도 아침에 문 열기 전까진 똑같이 조용합니다. 소리로는 구분이 안 되죠. 그래서 냉장고엔 온도 경보가 붙습니다. 조용함을 믿지 말고, '이상하면 알려주는 장치'를 따로 달아두는 겁니다. AI 시스템도 똑같습니다.

여기서 실무 팁 하나. 실패했을 때만 알리게 하면 부족할 때가 많습니다. 알림을 보내는 그 부분까지 같이 죽어버리면, 실패해도 알림조차 안 오기 때문입니다. 그래서 '정해진 시간에 돌긴 돌았다'는 신호도 같이 받는 게 좋습니다. 아침에 "오늘 새벽 발주 정상 처리됨" 한 줄만 와도, 그 한 줄이 안 온 날 곧바로 "어, 오늘 왜 조용하지?" 하고 눈치챌 수 있습니다. 있어야 할 신호가 없는 것도 신호로 쓰는 거죠.

물론 알림이 너무 많으면 그것도 문제입니다. 성공할 때마다 시끄럽게 울려대면, 사람은 며칠 만에 그 알림을 눈으로만 지나치기 시작합니다. 그러면 정작 실패 알림이 왔을 때도 그냥 흘려보냅니다. 그래서 성공 신호는 하루 한 줄처럼 조용하고 규칙적으로, 실패 신호는 눈에 확 띄게 — 이렇게 강약을 나누는 게 좋습니다. 알림의 목적은 '많이 알리는 것'이 아니라 '이상할 때 놓치지 않는 것'이니까요.

왜 안전장치를 '먼저' 생각해야 하나

안전장치는 나중에 붙이는 부품이 아니라 설계의 뼈대입니다. 되돌리기(롤백)를 예로 들면, 처음부터 '되돌릴 수 있게' 데이터를 다루도록 설계한 시스템과, 다 만들어놓고 나중에 되돌리기를 억지로 끼워 넣는 시스템은 구조 자체가 다릅니다. 후자는 대부분 반쪽짜리로 끝납니다. 이미 데이터를 덮어쓰는 방식으로 만들어버렸으면, 되돌릴 원본이 애초에 안 남아 있어서 나중에 아무리 코드를 붙여도 복구할 대상이 없습니다.

인테리어에 비유하면 명확합니다. 소화전과 배선, 환기구는 골조 세울 때 같이 넣습니다. 벽 다 바르고 타일까지 붙인 다음에 "여기 소화전 하나 넣자" 하면, 벽을 다시 뜯어야 합니다. 안전장치도 똑같아서, 나중에 넣으려면 이미 만든 걸 뜯어야 하고, 그래서 대충 겉에만 붙이고 끝냅니다. 처음에 물었으면 거의 공짜였을 게, 나중엔 공사판이 됩니다.

그래서 순서를 뒤집어야 합니다.

Before — 기능 먼저, 안전장치 나중에

1. "발주 자동화 만들어줘"
2. AI가 발주 넣는 기능을 만든다
3. 잘 돈다, 배포한다
4. 몇 달 뒤 새벽에 조용히 멈춘다
5. 다음 날 재고 사고가 나서야 안다

After — 안전장치 먼저, 기능은 그 위에

1. "발주 자동화를 만들 건데, 먼저 이게 실패하면 어떻게 알지?"
2. 실패 알림·되돌리기·사람 확인부터 어디에 둘지 정한다
3. 그 뼈대 위에 발주 기능을 얹는다
4. 몇 달 뒤 새벽에 멈춰도 아침에 알림이 와 있다
5. 재고 사고 전에 손을 쓴다

같은 기능인데 5번의 결말이 정반대입니다. 차이는 코드 실력이 아니라 '무엇을 먼저 물었냐'입니다. 그리고 이 질문은 개발을 몰라도 던질 수 있습니다. "이게 실패하면 나는 언제, 어떻게 알게 되지?" — 이 한 줄이 After와 Before를 가르는 전부입니다. 기술이 아니라 순서의 문제라는 게 이 글의 핵심 중 하나입니다.

오해하면 안 되는 게, 안전장치를 먼저 챙긴다고 기능이 늦어지는 게 아닙니다. 오히려 반대입니다. 실패하면 알림이 오고 잘못돼도 되돌릴 수 있다는 걸 알면, 사장님은 마음 놓고 배포 버튼을 누를 수 있습니다. 안전장치가 없으면 '이거 켜놨다가 새벽에 터지면 어쩌지' 하는 불안 때문에 오히려 시스템을 못 믿고 손으로 다시 확인하게 됩니다. 안전장치는 속도를 늦추는 브레이크가 아니라, 안심하고 밟을 수 있게 해주는 안전벨트입니다.

챙겨야 할 안전장치 범주

안전장치를 '먼저' 생각하려면, 매번 머리로 떠올릴 게 아니라 미리 목록으로 정해둬야 합니다. 사람 기억력은 바쁠 때 제일 먼저 무너지고, 안전장치는 하필 바쁠 때 빠집니다. 그래서 종이에 박아두는 게 낫습니다. 프로젝트가 달라도 챙길 범주는 대체로 겹칩니다. 개념 수준에서 이런 것들입니다.

여섯 개를 성격으로 묶으면 이해가 쉽습니다. 앞의 셋(실패 시 알림·백업·복구·되돌리기)은 "터진 다음에 살아남는" 장치입니다. 사고를 막는 게 아니라, 사고가 났을 때 피해를 되돌릴 수 있게 하는 안전망이죠. 뒤의 셋(권한 분리·입력 검증·사람 최종 확인)은 "터지기 전에 막는" 장치입니다. 애초에 이상한 게 들어오거나, 아무나 건드리거나, 잘못된 게 그대로 확정되는 걸 막습니다. 방어의 앞단과 뒷단을 둘 다 갖췄는지 보는 게 요령입니다.

이 목록이 완벽한 정답표는 아닙니다. 하는 일에 따라 항목은 더 늘 수도, 줄 수도 있습니다. 중요한 건 '내 목록'을 하나 갖고 있고, 프로젝트마다 그걸 꺼내 든다는 습관입니다. 목록이 손에 있으면, AI한테든 개발자한테든 "이 여섯 개 각각 어떻게 처리했는지 적어달라"고 요구할 수 있습니다. 목록이 없으면 그 요구 자체를 못 합니다.

목록을 거창하게 만들 필요도 없습니다. 위 여섯 줄을 메모장이나 휴대폰에 적어두고, 새 자동화를 시작할 때마다 그 여섯 줄을 위에서 아래로 한 번씩 훑으면 됩니다. 읽는 데 1분도 안 걸리지만, 그 1분이 '아, 이건 알림이 필요하겠네'를 만들기 전에 떠올리게 해줍니다. 만든 뒤에 떠올리면 뜯어고쳐야 하고, 만들기 전에 떠올리면 거의 공짜입니다.

다 넣는 게 정답은 아니다 — 반대편 함정

여기서 오해를 하나 풀고 가야 합니다. "안전장치가 중요하다"는 말을 "무조건 다 넣어라"로 알아들으면, 반대편 함정에 빠집니다. 메모 하나 남기는 간단한 자동화에까지 백업·권한 분리·되돌리기를 다 욱여넣으면, 정작 유지보수가 어려워지고 손댈 때마다 겁이 납니다. 이걸 과설계라고 합니다. 안전하자고 넣은 게 오히려 시스템을 무겁고 약하게 만드는 거죠.

주방으로 치면, 칼 한 자루 쓰는 자리에 방화문·비상벨·스프링클러를 다 다는 격입니다. 돈과 자리만 잡아먹고 실제로 쓸 일은 없습니다. 안전은 '많이'가 아니라 '맞게'입니다.

그래서 핵심은 '넣느냐 마느냐'가 아니라 **'각 항목을 의식적으로 판정했느냐'**입니다. 판정 결과가 "이건 안 넣는다"여도 괜찮습니다. 오히려 대부분의 작은 자동화는 여섯 개 중 여러 개가 '비해당'으로 빠지는 게 정상입니다. 반대로 돈·재고·급여·고객 데이터가 얽히는 순간, 관련 범주는 거의 필수로 봐야 합니다. 판정을 했느냐 안 했느냐가 갈림길이지, 많이 넣었느냐가 아닙니다.

반대 방향 예시도 하나. 손님 예약 정보나 매출 데이터를 다루는 자동화라면, '백업·복구'와 '입력 검증'은 웬만하면 비해당으로 뺄 수 없습니다. 한 번 꼬이거나 날아가면 손님과 돈이 곧바로 걸리기 때문입니다. 같은 여섯 줄짜리 목록인데, 메모 자동화에선 대부분 비해당이고 돈·고객이 걸린 자동화에선 대부분 해당으로 뒤집힙니다. 목록은 그대로고, 판정만 상황 따라 달라지는 겁니다 — 그래서 '많이 넣기'가 아니라 '판정'이 핵심입니다.

침묵을 '판정'으로 바꾼다 — 이 글의 핵심

여기서부터가 실제 사고법입니다. 목록만 있으면 소용없습니다. AI에게든 개발자에게든, 목록의 각 항목을 '해당/비해당'으로 판정하게 만들어야 합니다. 그리고 결정적으로 — 비해당이라도 반드시 사유를 적게 합니다.

왜 사유까지 적게 하냐면, AI는 안 한 걸 조용히 넘기기 때문입니다. "백업 안 만들었어요"라고 먼저 말해주는 AI는 없습니다. 그냥 없는 채로 넘어갑니다. 나쁜 의도가 있어서가 아니라, 요청받은 걸 만드는 데 집중하다 보니 요청 안 한 건 시야에 안 들어오는 겁니다. 그 침묵이 나중에 사고가 됩니다. 그래서 침묵을 강제로 '문장'으로 끄집어내야 합니다. 빈칸은 읽을 수 없지만, 문장은 읽고 반박할 수 있으니까요.

판정 예시 — 사장님이 검토할 수 있는 형태

핵심은 '비해당'도 빈칸이 아니라 문장이라는 점입니다. "결제가 없어서 정산 검증은 비해당" 같은 한 줄이 있으면, 나중에 사장님이 "어, 결제 붙였는데 정산 검증 다시 봐야겠네" 하고 스스로 잡아낼 수 있습니다. 빈칸이었으면 그 존재조차 몰랐을 겁니다. 사유 한 줄의 진짜 가치는 지금 당장이 아니라 상황이 바뀐 6개월 뒤에 나옵니다. 그때 이 문장이 "이 전제가 아직 맞나?"를 되묻는 방아쇠가 됩니다.

한 가지 더. 사유는 '기술적으로 왜'가 아니라 '현장 상황으로 왜'로 적혀 있어야 사장님이 검토할 수 있습니다. "동시 접근이 없어서 잠금 비해당"보다 "이 도구는 나 혼자 쓰니까 권한 나눌 필요 없음"이 사장님 언어입니다. 판정표를 받을 때 사유를 이렇게 요구하세요 — "개발 용어 말고, 우리 매장 상황으로 왜 그런지 적어줘." 그래야 판정을 사장님이 직접 검수할 수 있습니다.

이게 앞서 빌더용 글에서 다룬 '안 만드는 것도 이유를 쓰게 한다'는 원칙의 연장선입니다. 그때는 기능을 안 만드는 선택에 관한 이야기였다면, 이번엔 시스템을 지키는 안전장치를 안 넣는 선택에 같은 규율을 적용하는 겁니다. 판단을 지우지 말고, 기록으로 남기는 거죠.

외식 현장에 대보면 이렇게 갈린다

추상적으로 들릴 수 있으니 두 가지로 좁혀봅니다. 같은 '자동화'라도 생명줄이 어디에 있는지가 완전히 다릅니다.

발주 자동화 — 매일 새벽 재고를 보고 부족한 걸 자동 발주하는 시스템이 있다고 합시다. 이게 어느 날 새벽에 조용히 멈추면, 발주가 안 나갑니다. 그런데 자동화가 원래 조용하니 아무도 눈치를 못 챕니다. 다음 날 장사 준비하다가 재료가 없어서야 압니다. 여기선 '실패 시 알림'이 선택이 아니라 필수입니다. "오늘 발주 정상 처리됨" 또는 "발주 실패, 확인 요망"이 아침 영업 준비 전에 사장님 손에 닿아야 합니다. 재료가 없는 걸 손님 받기 전에 아느냐, 손님 주문받고 나서 아느냐 — 알림 한 줄이 이 차이를 만듭니다.

발주엔 하나가 더 붙습니다. 되돌리기입니다. 자동화가 수량을 잘못 읽어 필요한 양의 몇 배를 발주해버리면, 그건 '멈춘 것'보다 더 큰 사고입니다. 그래서 발주 같은 자동화는 잘못 나갔을 때 취소·정정하는 길이 같이 설계돼 있어야 합니다. 실패도 막고, 잘못된 성공도 막는 거죠.

급여 계산 자동화 — 시급·근무시간을 모아 급여를 계산하는 시스템은 성격이 다릅니다. 계산은 자동으로 하되, 마지막에 '사람 최종 확인 단계'를 반드시 둬야 합니다. 숫자 하나가 틀린 채로 자동 이체되면, 그건 단순 오류가 아니라 직원과의 신뢰가 걸린 문제가 되기 때문입니다. 돈 문제, 그중에서도 사람에게 나가는 돈은 되돌리기가 특히 어렵습니다. 그래서 자동화가 계산까지만 하고, '보내기' 버튼은 사람이 누르게 합니다. 자동화의 목적은 사람을 빼는 게 아니라, 사람이 확인만 하면 되게 판을 깔아주는 겁니다.

두 경우를 나란히 놓으면 확실합니다.

같은 '자동화'라도 어떤 건 알림이 생명줄이고 어떤 건 사람 확인이 생명줄입니다. 목록을 놓고 항목마다 판정했다면 이 차이가 저절로 드러납니다. 판정을 건너뛰면, 둘 다 그냥 '잘 도는 데모'로 배포됐다가 각자 다른 방식으로 터집니다.

그래서 뭘 만들든, AI한테 던지기 전에 이 세 줄만 먼저 물어보세요.

1. 이게 조용히 죽으면 나는 언제, 어떻게 알게 되지?
2. 이게 잘못 실행되면 되돌릴 수 있나?
3. 이게 확정하기 전에 사람이 한 번 보나?

이 세 질문에 답이 되게 만들어진 시스템은, 6개월 뒤 새벽에도 사장님을 배신하지 않습니다.

외식 SMB 인사이트

주방에 소화기를 두는 건 불이 날 걸 알아서가 아니라, 불이 나면 1분 안에 손이 닿아야 하기 때문이다. AI 시스템의 안전장치도 똑같다 — 안 터질 걸 믿어서가 아니라, 터졌을 때 조용하지 않게 하려고 미리 박아두는 것이다.

새벽에 혼자 문 여는 사장님에게 가장 무서운 건 '고장'이 아니라 '고장 났는데 몰랐던 것'입니다. 고장은 고치면 되지만, 몰랐던 고장은 이미 하루 장사를 망친 뒤에야 발견됩니다. 조용한 실패 하나가 그날 하루를 통째로 날립니다. AI로 뭘 만들든, 만들기 전에 "이게 조용히 죽으면 나는 언제 알게 되지?"를 먼저 묻는 습관이 6개월 뒤의 사고 하나를 미리 막습니다. 이 습관은 코드가 아니라 태도라서, 개발을 몰라도 오늘부터 쓸 수 있습니다.

내 시스템, 조용히 터질 구석은 없는지 같이 점검해 드립니다

이미 돌리고 있는 자동화가 있거나 만들 계획이 있다면, 위 안전장치 범주를 하나씩 대보며 '해당/비해당'을 같이 판정해 드립니다. 특히 어디서 조용히 실패할 수 있는지, 알림과 사람 확인 단계를 어디에 둬야 하는지를 현장 기준으로 짚어드립니다. 데모가 도는지가 아니라, 6개월 뒤에도 버티는지를 기준으로 봐드립니다.

무료 상담 신청하기 →