AI 코딩 프로그램 만들 때 AI가 멈춰도 프로그램은 안 멈추게 하는 3가지

오즈입니다.

AI로 만든 프로그램을 쓰다가, 인터넷이 잠깐 끊겼는데 아무것도 못 하게 된 적 있으신가요?

아니면 API 키를 안 넣으면 아예 켜지지도 않는 프로그램을 만들어 놓고 "이게 맞나" 싶으셨던 적은요?

그렇다면 이 글을 끝까지 보셔야 합니다.

AI 기능이 실패해도 프로그램은 계속 돌아가게 만드는 안전장치 세 가지를 정리했습니다. 실제 코드에 뭐라고 적어뒀는지까지 그대로 옮겼습니다.

이 시리즈 마지막 편입니다.

먼저 결론부터 말씀드릴게요.

AI는 부품이지 심장이 아닙니다.

그런데 바이브코딩으로 만들면 십중팔구 심장 자리에 놓입니다. 아무도 그러라고 안 했는데 그렇게 됩니다.

지난 편 복습과 오늘 자리

이 시리즈는 세 가지를 다룹니다.

1. 넘길 것 — 세션이 끊겨도 다음 AI에게 넘어가는 것 → 문서 세 장
2. 가를 것 — 어디까지 코드가 하고 어디부터 AI가 판단하나 → 질문 세 개
3. 막을 것 — AI가 실패했을 때 프로그램이 안 죽게 하는 장치 ← 오늘

지난 두 편의 그 사장님으로 마무리합니다. 직원 세 명짜리 인테리어 시공 업체 사장님. 코딩은 배운 적 없고, 현장이 동시에 네다섯 개, 자재 견적서가 주에 열 건, 손댈 시간은 저녁 한 시간.

현장 사진 정리 도구를 만들었고, 자재 견적 도구에서 "AI가 할 일"과 "코드가 할 일"을 갈랐습니다. 오늘은 그 도구를 들고 실제 현장에 나갑니다. 여기서 사고가 납니다.

지하 주차장에서 프로그램이 죽습니다

현장은 인터넷이 잘 안 됩니다. 이게 이 글 전체의 이유입니다.

신축 현장 지하 주차장, 골조만 올라간 층, 엘리베이터 안. 사장님이 자재를 확인하고 견적에 넣으려는 딱 그 순간에 신호가 없습니다.

그런데 지난 편에서 만든 도구는 카톡 목록에서 품명·수량을 뽑아내는 걸 AI한테 맡겼습니다. 그 부분이 안 되면 어떻게 되나요?

여기가 갈림길입니다.

• 심장으로 만든 경우 — 뽑아내기가 실패하니 저장 화면까지 안 뜹니다. 사장님은 결국 수첩에 적습니다. 그리고 다시는 그 프로그램을 안 켭니다.

• 부품으로 만든 경우 — 자동 채우기만 안 되고, 빈칸이 뜹니다. 사장님이 손으로 넣고 저장합니다. 조금 귀찮지만 일은 끝납니다.

같은 실패인데 결과가 완전히 다릅니다.

"AI가 실패했다"와 "프로그램을 못 쓴다" 사이를 끊어놓는 것. 그게 오늘 할 일입니다.

99%짜리도 한 달이면 세 번 죽습니다

숫자로 보면 왜 이게 선택이 아닌지 분명해집니다.

AI 호출이 잘 되는 비율을 아주 후하게 99%로 잡아보죠.

• 하루 15번 사용 × 20일 = 월 300번

• 실패 3번

3번이면 별거 아닌 것 같습니다.

그런데 여기에 네트워크가 안 되는 상황을 더해야 합니다. 현장 다니는 분이 하루 한 번은 신호 안 잡히는 데 들어간다고 치면 월 20번입니다.

사용료가 떨어지거나 결제가 밀리는 날도 있고요.

합치면 한 달에 스무 번 넘게 AI 쪽이 안 됩니다.

심장으로 만들었으면 그 스무 번이 전부 "프로그램을 못 쓴 날"입니다. 한 달 20일 중에 스무 번이면, 그냥 안 쓰게 됩니다.

그리고 이건 정확도를 올려서 해결되는 문제가 아닙니다.

모델을 더 좋은 걸로 바꿔도 지하 주차장에는 신호가 안 잡힙니다.

안전장치 1 — 키를 빼고 한번 켜보세요

제일 빠른 점검법입니다. AI 키를 지우고 프로그램을 켜보세요. 안 켜지면 심장에 놓은 겁니다.

제가 만든 가계 관리 도구가 하나 있습니다.

"이번 달 자재비로 80만 원 나갔어" 같은 말을 넣으면 항목·금액·날짜를 알아서 채워주는 기능이 붙어 있습니다.

그런데 그 도구 설명서 맨 앞에 이 문장이 있습니다.

키가 없어도 앱은 정상 작동합니다(수동 폼 입력).

이게 설계 전체를 요약합니다.

자연어 입력은 입력창을 대신 채워주는 기능이지, 저장 기능이 아닙니다. 채워주는 게 안 되면 사람이 채웁니다. 그게 끝입니다.

사장님 견적 도구에 대보면 이렇게 됩니다.

• 카톡 목록 붙여넣기 → AI가 표로 채움 → 안 되면 빈 표가 뜸

• 사람이 확인하고 고침 → 이 단계는 원래 있어야 함

• 저장 → 여기는 AI가 아예 안 지나감

두 번째 단계를 없애지 마세요.

AI가 채운 걸 사람이 안 보고 바로 저장하는 구조는 편해 보입니다. 하지만 지난 편에서 본 "거의 맞는 답"이 그대로 장부에 들어가는 길입니다.

안전장치 2 — 부가 기능의 실패가 본체를 물고 늘어지지 않게

AI 쪽에서 난 오류가 저장을 취소시키면 안 됩니다. 이건 순서 문제입니다.

제가 만든 업무 기록 도구에 부가 기능이 하나 붙어 있습니다. 오래 남길 만한 메모를 별도 서버로 보내 보관하는 기능입니다.

그 파일 맨 위에 규칙을 이렇게 적어놨습니다. 【직접 확인 · 2026-07-25】

절대 규칙:
- 이 모듈의 실패는 절대 항목 저장을 막거나 로컬 데이터를 잃게 해서는 안 됨(항상 예외를 삼키고 실패로 반환).
- 비밀번호는 절대 로그·예외 메시지·반환값 어디에도 노출하지 않음.

첫 줄이 오늘 얘기입니다. 보내기가 실패해도 내 손안의 기록은 이미 저장돼 있어야 합니다.

순서로 쓰면 이렇습니다.

1. 사용자가 저장을 누른다

2. 먼저 내 컴퓨터에 저장한다 ← 여기까지가 본체

3. 그다음 AI를 부르거나 외부로 보낸다 ← 여기가 부가

4. 3번이 실패하면 조용히 넘어간다. 저장은 이미 끝났으니까

바이브코딩으로 만들면 2번과 3번이 자주 뒤집힙니다. AI를 먼저 부르고, 그 결과로 저장하는 식으로요.

그러면 3번 실패가 2번을 통째로 날립니다.

AI한테 시킬 때 이렇게 말씀하시면 됩니다.

저장을 먼저 하고 AI 호출은 그다음에 해줘. AI 호출이 실패해도 저장은 이미 끝나 있어야 하고, 화면에는 "요약은 나중에" 정도만 뜨게 해줘.

두 번째 줄, 비밀값 얘기도 짚고 갈게요.

오류 메시지에 키가 딸려 나오는 사고가 진짜로 납니다. 로그를 캡처해서 어딘가에 붙여넣는 순간 키가 남한테 갑니다.

"오류 메시지에 API 키나 비밀번호가 절대 안 찍히게 해줘" 한 줄을 미리 넣어두세요.

안전장치 3 — AI 없이도 도는 가짜 부품 하나

세 번째는 조금 더 나갑니다. AI 자리에 끼워 넣을 "멍청한 대체품"을 하나 만들어 두는 겁니다.

같은 업무 기록 도구에 이런 게 실제로 들어 있습니다.

AI가 문장을 읽고 종류를 분류하는 자리에, 네트워크 없이 규칙만으로 돌아가는 가짜 분류기가 따로 있습니다. "해야", "할 일" 같은 말이 있으면 할 일로, 물음표로 끝나면 메모로 치는 식의 단순한 규칙입니다.

정확하진 않습니다. 그런데 항상 돕니다.

그리고 이게 두 가지를 해결합니다.

첫째, 인터넷이 끊겨도 프로그램이 멈추지 않습니다. 품질이 떨어질 뿐입니다.

둘째, 이게 있어야 점검을 할 수 있습니다. AI를 부르지 않고도 프로그램이 제대로 도는지 확인할 수 있거든요.

앤트로픽도 클로드 코드 문서에서 이 방향을 강조합니다. 【문서 근거 · 2026-07-25 확인】

"클로드에게 스스로 돌려볼 수 있는 검사를 줘라. 지켜봐야 하는 작업과 자리를 비워도 되는 작업의 차이가 여기서 갈린다."

검사가 매번 AI를 불러야만 돌아간다면, 그건 검사가 아니라 또 하나의 도박입니다.

사장님 견적 도구라면 이렇게 시키시면 됩니다.

AI를 못 쓸 때 쓸 간단한 대체 방식도 같이 만들어줘. 줄바꿈이랑 숫자만 보고 대충 나누는 정도면 돼. 그리고 프로그램이 자동으로 스스로 점검할 땐 이 대체 방식을 쓰게 해줘.

AI는 잘하는 걸 더 잘하게 만들 뿐입니다

이 세 가지가 결국 하나로 모입니다.

구글의 DORA 연구팀이 2025년 보고서에서 이렇게 정리했습니다. 【문서 근거 · 2026-07-25 확인】

"AI의 주된 역할은 증폭기다. 조직이 이미 가진 강점과 약점을 함께 키운다."
"AI 투자에서 가장 큰 수익은 도구 자체가 아니라 그 아래 시스템에 대한 전략적 집중에서 나온다."

혼자 프로그램 만드는 사람한테도 똑같이 적용됩니다.

AI는 우리가 만든 구조를 더 빠르게 굴릴 뿐입니다.

구조가 "AI가 죽으면 전부 죽는" 모양이면, AI를 더 잘 쓸수록 더 자주 전부 죽습니다.

지난 편에서 본 숫자가 여기서 다시 의미를 갖습니다. 개발자 열 명 중 여덟 명이 AI를 쓰는데, 정확성을 믿는 사람은 셋뿐이었죠.

믿음을 올리려 하지 마시고, 안 믿어도 굴러가는 구조를 만드시면 됩니다.

그게 훨씬 쉽고 확실합니다.

오즈가 직접 확인한 것

【직접 확인 · 2026-07-25】 제가 만든 도구 중 두 개에서 이 구조가 실제로 돌아가는 걸 확인했습니다.

하나는 AI 키가 없어도 수동 입력으로 완전히 작동합니다. 다른 하나는 부가 전송 실패가 본체 저장을 막지 않도록 코드 맨 위에 규칙을 못 박아 뒀고요. 네트워크 없이 도는 대체 분류기도 실제로 들어 있습니다.

【직접 확인 · 2026-07-25】 위의 "월 20번 넘게"는 제가 계산한 값입니다. 99%라는 성공률과 하루 15번이라는 사용량은 제 가정입니다.

다만 현장에서 신호가 안 잡히는 횟수가 AI 자체의 실패보다 훨씬 많다는 점은 가정을 어떻게 잡아도 뒤집히지 않습니다.

【아직 못 봄】 실제 사용 환경에서 AI 호출이 몇 % 실패하는지 세어본 적은 없습니다.

프로그램이 실패를 조용히 넘기도록 만들어놨더니, 정작 몇 번 실패했는지가 안 남더군요.

실패 횟수만 세는 기록을 붙이는 게 다음 할 일입니다. 숫자가 모이면 다시 올리겠습니다.

오늘 할 일 3가지

1. AI 키를 지우고 프로그램을 켜보기 — 3분

안 켜지면 심장에 놓은 겁니다. 이 한 번이 오늘 글 전체보다 확실합니다.

1. 저장 순서 확인하기 — 10분

저장이 먼저고 AI 호출이 나중인지 확인해줘. 반대면 바꿔줘. AI가 실패해도 저장은 남아야 해.

1. 오류 메시지에 키가 안 찍히게 한 줄 넣기 — 5분

오류 메시지나 로그에 API 키·비밀번호가 절대 안 나오게 해줘.

1번이 3분이고 나머지는 AI가 합니다. 오늘 세 개 다 하셔도 20분입니다.

자주 묻는 질문

Q. 그럼 AI를 아예 안 쓰는 게 낫다는 얘기인가요?
A. 아닙니다. AI를 어디에 놓느냐의 문제입니다. 뒤죽박죽인 걸 정리된 모양으로 바꾸는 자리에 AI를 놓으면 예전엔 사람이 몇 시간씩 하던 일이 몇 초로 줄어듭니다. 그 자리를 그대로 두되, 그게 안 될 때 사람이 손으로 할 길만 남겨두시면 됩니다.

Q. 대체품까지 만들면 만들 게 두 배 아닌가요?
A. 대체품은 아주 단순해도 됩니다. 정확할 필요가 없거든요. 실제로 제가 쓰는 것도 몇 가지 단어를 찾아보는 수준입니다. 만드는 데 걸리는 시간보다 점검을 매번 AI 불러가며 하는 비용이 훨씬 큽니다.

Q. 이미 AI가 심장에 들어간 프로그램은 어떻게 하나요?
A. 전부 뜯지 마시고 저장 순서 하나만 바꾸세요. AI 호출을 저장 뒤로 옮기는 것만으로 "실패해도 데이터는 남는다"가 확보됩니다. 대체품은 그다음에 붙여도 됩니다.

Q. 실패를 조용히 넘기면 문제가 있는 줄도 모르지 않나요?
A. 맞습니다. 그래서 조용히 넘기되 기록은 남겨야 합니다. 화면에 경고를 띄우지 않더라도 어딘가에 "몇 시 몇 분에 실패"는 적혀 있어야 합니다. 제가 지금 놓치고 있는 부분이기도 합니다.

Q. 세 편을 다 읽었는데 뭐부터 하면 좋을까요?
A. 3편의 1번 할 일부터 하세요. 키를 빼고 켜보는 3분. 여기서 프로그램이 안 켜지면 문서나 경계선보다 이게 급합니다. 잘 켜지면 1편의 문서 세 장으로 가시면 됩니다.

세 편을 한 줄로 줄이면 이렇습니다.

넘길 것은 문서로, 가를 것은 질문 세 개로, 막을 것은 순서로.

바이브코딩이 어려운 건 코드가 어려워서가 아닙니다. 어제 정한 걸 오늘 잃어버리고, 맡기면 안 될 걸 맡기고, 부품 하나가 죽으면 전부 죽기 때문입니다. 셋 다 코딩 실력과 상관없이 구조로 막을 수 있습니다.

• 1편 · 넘길 것 — 바이브코딩 하는법: AI가 매번 처음부터 다시 묻지 않게 만드는 문서 3장

• 2편 · 가를 것 — 클로드코드 사용법: AI한테 시키면 안 되는 일을 가르는 선 하나

같은 글머리에 이런 글도 있습니다.

• 바이브코딩 웹사이트 AI 티 빼는 법 — 기본값 다섯 자리만 바꾸면 됩니다

• 클로드코드 스킬 만들기 — 같은 말을 매번 다시 치지 않게 하는 3층

특히 마지막 글은 세 편에서 정한 규칙들을 프로젝트마다 다시 설명하지 않게 만드는 법입니다. 도구가 두 개를 넘어가면 그때부터 필요합니다.

만들고 계신 도구에서 "이건 어느 쪽이지" 싶은 게 있으면 댓글로 남겨주세요. 같이 대보겠습니다. 그리고 실패 횟수를 세는 기록을 붙여보고, 숫자가 모이면 이어서 올리겠습니다.

출처

• 앤트로픽, 「Best practices for Claude Code」 — 스스로 돌릴 수 있는 검사 제공, 검증 없이는 배포하지 말 것

https://code.claude.com/docs/en/best-practices

• DORA(구글), 「State of AI-assisted Software Development 2025」 — AI는 조직의 강점과 약점을 함께 키우는 증폭기이며, 수익은 도구가 아니라 그 아래 시스템에서 나온다

https://dora.dev/dora-report-2025/

• 스택오버플로 2025 개발자 설문 (응답자 33,662명) — AI 도구 사용·계획 84%, 정확성 신뢰 33% / 불신 46%

https://survey.stackoverflow.co/2025/ai/

최초 작성 2026-07-25 · 최종 수정 2026-07-25