AI로 제품을 만들었다면, 작동하는 것을 망가뜨리지 않고 개선하는 방법

모델을 활용하는 방법은 Ailoot 문서에서 더 알아보세요.

가장 많은 비용이 드는 일이 왜 출시 후에 시작될까?#

저녁 한 번 만에 앱을 만들고 링크를 공개해 친구들에게 보냈습니다. 작동합니다. 그러다 일주일 뒤, 실제 사용자가 처음 나타나 뭔가를 엉뚱하게 클릭하자 기능의 절반이 작동을 멈춥니다. Claude에게 고쳐 달라고 하면 한 가지를 고치고 다른 것을 망가뜨립니다. 익숙한 이야기인가요?

그리고 바로 여기서 핵심 질문이 생깁니다. 제품을 출시한 뒤, 처음 작동하는 프로토타입을 만들었을 때의 들뜬 기분이 가라앉고 나면 어떻게 해야 할까요? 이 과정을 어른을 위한 바이브 코딩이라고 부를 수도 있겠습니다. 만드는 일에는 재미와 속도가 있습니다. 유지 관리에는 냉정한 판단이 필요합니다. 무엇을 바꾸는지 이해하고 통제해야 합니다. 대부분의 사람은 아무도 이 두 번째 단계에 대비시켜 주지 않기 때문에 여기서 실패합니다.

한 업계 분석은 2,444개 팀의 코드 변경 100만 건 이상을 분석해 AI 개발에 쓴 돈이 실제로 어디에 쓰이는지 계산했습니다. 결과는 다음과 같습니다.

“바이브 코딩의 숨겨진 비용” 가이드에서 이 수치를 더 자세히 설명합니다. 그 가이드에서는 무엇에 비용을 내는지를 다뤘습니다. 여기서 질문은 다릅니다. 1달러 중 44센트가 버그 수정에 들어갑니다. 이 글은 그 비중이 커지지 않게 하는 방법을 다룹니다. 이를 관리하는 작업을 유지 관리라고 합니다.

어른답게 바이브 코딩하는 사람과 신경망을 돌보기만 하는 사람의 차이는 출시 후에 드러납니다. 전자의 코드베이스는 성장하고, 개선을 거듭해도 아무것도 고장 나지 않습니다. 한 달 뒤 후자의 제품은 여기저기 새는 장치처럼 변해 손대기조차 두려운 상태가 됩니다. 이제 어떻게 하면 첫 번째 그룹에 속할 수 있는지 설명하겠습니다.

실제로 고장 나는 것: 출시 후 벌어지는 재난 5가지#

실제로 AI로 만든 제품에서 벌어진 일을 수치, 날짜와 함께 공개한 사후 분석입니다. 지뢰밭 지도라고 생각하세요. 누군가 이미 지뢰를 밟았고, 이를 피하는 방법도 알려져 있습니다.

다섯 사례의 근본 원인은 같습니다. 기본적으로 AI는 지금 당장 작동하게 만들 뿐, 한 달 뒤 부하가 걸려도 안전하게 작동하도록 만들지는 않습니다. 컴퓨터에서 개발하는 동안에는 그 차이를 볼 수 없습니다. 악의를 품은 첫 낯선 사람이 나타나면 차이가 드러납니다.

문제는 코드를 직접 쓰지 않는 데 있지 않습니다. 많은 사람이 이런 방식으로 작업합니다. 문제는 “데이터베이스가 안전하게 보호되고 있나?”라고 묻지 않는 것입니다. 다음으로 이 질문을 대신해 줄 프롬프트를 보여드리겠습니다.

첫 번째 안전망은 git과 “어제 상태로” 되돌리는 기능입니다#

Claude가 무언가를 망가뜨렸을 때 “어제 상태로 되돌리기” 버튼이 필요합니다. 기술적으로 그 버튼은 git이라고 부르며, 생각보다 간단합니다.

개발자가 아닌 사람이 알아야 할 용어 세 가지입니다.

1. 저장소 — 프로젝트 폴더를 클라우드에 저장한 것입니다. 보통 GitHub를 사용합니다. 컴퓨터에만 있지 않은 전체 코드의 사본입니다.
2. 커밋 — 되돌아갈 지점입니다. 코드에 “이 상태로 저장해”라고 말하는 것과 같습니다. 각 커밋은 돌아갈 수 있는 표시입니다.
3. 배포 — 코드를 옮기는 일입니다. 코드는 로컬, 즉 컴퓨터에 있었고 당신에게만 작동했습니다. 배포하면 외부 서버로 보내 모두에게 작동하게 됩니다.

최근 커밋 지점이 있다면 한 문장으로 어떤 문제든 되돌릴 수 있습니다. 정말로요.

뭔가를 망가뜨렸어요. 어제는 전부 작동했는데 오늘은 작동하지 않아요. 모든 것이 정상적으로 작동하던 가장 최근 커밋을 찾아서, 그 이후 무엇이 바뀌었는지 보여주고 프로젝트를 그 상태로 되돌려 주세요.

다른 사람에게 제품을 보여주기 전에 바로 적용할 두 가지 규칙입니다.

• 저장소는 비공개여야 합니다. 공개 저장소가 아니어야 합니다. 그렇지 않으면 누구나 코드와 그 안의 모든 내용을 읽을 수 있습니다.
• 비밀 정보 파일을 제외 목록에 넣으세요. 키, 비밀번호, 데이터베이스 접근 자격 증명은 별도 파일에 둡니다. 보통 .env 파일을 사용하며, 이 파일은 저장소에 절대 들어가면 안 됩니다. .gitignore에 .env 행을 추가하면 비밀 정보가 밖으로 나가지 않습니다.

Claude Code에서 변경 사항을 안전하게 되돌리는 별도 가이드가 있습니다. Claude Code에서 변경 사항 되돌리기. 되돌아갈 지점이 없다면 안전망 없이 외줄을 걷는 것과 같고, 언젠가는 떨어지게 됩니다.

/rewind는 무엇을 되돌리고, 무엇은 되돌리지 않을까?#

Claude Code는 변경을 하기 전에 상태의 스냅샷을 만듭니다. /rewind 명령을 사용하거나 Esc를 두 번 누르면 파일과 대화를 선택한 지점까지 되돌릴 수 있습니다. 편리합니다. 5분 전에 기능을 망가뜨렸다면 5분 전으로 돌아갈 수 있습니다.

하지만 초보자가 데이터를 잃게 되는 함정이 있습니다. /rewind가 모든 것을 되돌리지는 않습니다.

Anthropic은 이를 명확하게 설명합니다. 스냅샷은 로컬 “실행 취소” 버튼이고, git은 영구 기록입니다. 스냅샷은 버전 관리 기능을 보완하지만 대체하지 않습니다.

개발자가 아닌 사람에게 실질적으로 중요한 점은 다음과 같습니다. /rewind는 “Claude가 기능을 방금 망가뜨렸어요” 같은 상황에서 도움이 됩니다. 하지만 데이터베이스 행을 삭제하거나 코드를 클라우드에 올려 버렸다면, 되돌릴 수 있는 것은 git과 데이터베이스 백업뿐입니다. 두 계층을 모두 유지하세요. 빠른 되돌리기에는 스냅샷을, 프로젝트의 영구 기록에는 커밋을 사용합니다.

이미 작동하는 것을 망가뜨리지 않고 어떻게 개선할까?#

두 명 중 한 명은 이 반복 과정에 빠집니다. AI에게 작은 버그를 고쳐 달라고 합니다. 그럴듯한 변경을 제안합니다. 그 변경이 다른 것을 망가뜨립니다. 새 문제를 고쳐 달라고 하면 문제가 두 개 더 생깁니다. 이런 일이 반복됩니다.

이런 반복이 생기는 이유는 바이브 코딩이 비결정적이기 때문입니다. 같은 프롬프트를 두 번 입력해도 서로 다른 코드가 나옵니다. 그래서 편집할 때마다 주변 로직이 조용히 바뀔 수 있습니다. 할인 기준이 10에서 12 percent로 바뀌거나 유효성 검사 규칙의 동작이 달라지지만, 직접 확인하지 않으면 경고조차 없습니다. 이것을 논리적 표류라고 하며, 가격, 접근 권한, 결제처럼 수익을 가져오는 요소를 조용히 손상시킵니다.

논리적 표류를 막는 규칙이 하나 있으며, 벽에 걸어 두기에도 충분히 간단합니다. 다른 사람에게 한마디씩 설명할 수 없는 코드는 커밋하지 마세요.

실제로는 작동 중인 코드를 변경하기 전에 사용하는 준비된 지침이 됩니다. AI가 작은 단계를 밟게 하고 정확히 무엇이 바뀌었는지 보여주도록 합니다.

코드를 변경하기 전에 다음을 수행하세요.

현재 작동 상태를 별도의 되돌리기 지점(커밋)으로 저장하세요.

무엇을 어떤 파일에서 변경할 계획인지 정확히 설명하세요.

가능한 한 가장 작은 변경만 하세요. 내 작업을 해결하는 데 필요한 것만 하고, 다른 것은 추가하지 마세요.

변경된 내용을 보여주고 각 변경을 설명하세요. 내가 다른 사람에게도 설명할 수 있어야 합니다.
내가 요청하지 않는 한 가격, 접근 권한 또는 결제 로직을 건드리지 마세요.

몇 주를 아껴 주는 또 다른 원칙은 작업 범위를 지키는 규율입니다. 문제 하나, 변경 하나, 빠른 구현이 원칙입니다. 한 번의 프롬프트로 프로젝트 절반을 다시 쓰라고 AI에게 요청하지 마세요. 전문 개발자도 버튼 하나만 필요할 때 Uber 전체를 만들기 시작해 몇 달씩 끌기도 합니다. 그럴 필요는 없습니다.

제가 설명하는 모든 내용은 한 가지, 즉 컨텍스트 관리에 기반합니다. AI가 주변 로직을 망가뜨리지 않도록 프로젝트의 규칙을 기억하게 해야 합니다.

공개하기 전에 변경 사항을 어떻게 확인할까?#

“내 컴퓨터에서는 작동해요”와 “모두에게 작동해요” 사이에는 초보자가 건너뛰는 중간 단계가 있습니다. 바로 테스트 사본입니다. 테스트 사본은 프로덕션 환경과 별도로 만든 스냅샷으로, 실제 사람이 보기 전에 변경 사항을 확인할 수 있습니다. 작업 주기는 다음과 같습니다.

1. 변경 사항을 만들고 직접 확인합니다(개발).
2. 실제 사용자가 없는 프로덕션 사본인 스테이징에 배포합니다.
3. 핵심 시나리오를 실행해 아무것도 달라지지 않았는지 확인합니다.
4. 이제 프로덕션에 배포합니다.

출시 후 이것이 중요한 이유는 릴리스마다 위험이 따르기 때문입니다. 작은 코드 변경 하나로 계정 로그인이 작동하지 않을 수 있습니다. 설정 하나가 빠져도 제품 전체가 중단될 수 있습니다. 스테이징에서는 이런 문제를 결과 없이 발견할 수 있지만, 프로덕션에서는 고객을 잃습니다.

매번 모든 것을 수동으로 확인하지 않으려면 AI에게 새 버전과 이전 버전의 동작을 핵심 영역에서 비교하도록 요청하세요.

변경 사항을 배포하려고 합니다. 제품의 핵심 시나리오를 순서대로 점검해 각 항목이 이전처럼 계속 작동하는지 확인하세요.

신규 사용자 가입과 로그인.

결제 및 결제 후 접근 권한 부여.

접근 권한: 일반 사용자는 다른 사람의 데이터나 관리자 영역을 볼 수 없어야 합니다.

핵심 비즈니스 로직 값(가격, 할인, 한도)이 바뀌지 않았는지 확인하세요.
이전 버전과 다르게 동작하는 부분이 있으면 중단하고 무엇이 바뀌었는지 정확히 보여주세요.

비밀 정보는 어디에 있나요? 초보자가 가장 많이 놓치는 보안 허점#

다른 어떤 문제보다 많은 제품을 무너뜨리는 가장 큰 지뢰를 자세히 설명하겠습니다. AI가 코드를 작성할 때 가장 손쉬운 방법은 키가 바로 작동할 곳, 즉 브라우저에서 열리는 페이지 코드에 키를 넣는 것입니다. 개발 중에는 차이를 알아차리지 못합니다. 하지만 누구나 개발자 도구를 열어 브라우저에 전달되는 내용을 전부 읽을 수 있습니다.

고객에게 $87,500의 요금이 청구된 창립자는 나중에 프롬프트 하나만 있었어도 막을 수 있었다고 말했습니다. 결국 요금은 취소됐지만 환불 불가 수수료와 잃어버린 마음의 평온은 남았습니다. 그때 사용했어야 할 프롬프트는 다음과 같습니다.

프로젝트 전체를 점검해 비밀 키가 브라우저에 들어가지 않도록 확인하세요.

데이터베이스, 결제 시스템, 외부 서비스에 사용되는 모든 키를 찾으세요.

각 키가 서버의 환경 변수에만 저장되어 있고 페이지 코드에는 없는지 확인하세요.

프로젝트 기록도 확인하세요. 과거에 키가 실수로 들어간 적이 있나요?
비밀 정보가 발견된 위치를 모두 목록으로 보여주고 각각 어떤 조치가 필요한지 알려주세요.

그 주변에 있는 또 다른 지뢰는 브라우저 쪽에서만 접근 권한을 확인하는 것입니다. 제품이 페이지 코드에서 “관리자 영역 표시 여부”를 결정한다면 누구든 그 결정을 우회할 수 있습니다. 접근 권한은 항상 서버에서 확인해야 합니다. 데이터베이스는 권한이 있는 사람에게만 데이터를 반환해야 합니다. 이를 위한 것이 행 수준 보안(RLS)이며, 모든 테이블에서 활성화해야 합니다.

접근 권한을 판매하거나 다른 사람의 접속을 허용하기 전에 제품의 전반적인 보안 감사를 실행하세요.

공격자의 입장에서 프로젝트를 살펴보고 보안 허점을 찾으세요.

브라우저로 전송되는 코드나 프로젝트 기록에 비밀 키가 저장되어 있나요?

모든 데이터베이스 테이블에서 행 수준 보안(RLS)이 활성화되어 있나요? 접근 권한을 브라우저에서만 확인하지 않고 서버에서 확인하나요?

자동 데이터베이스 백업이 설정되어 있나요? 백업에서 복원할 수 있는지 확인한 적이 있나요?

프로덕션 데이터베이스가 AI 에이전트 실행 환경과 격리되어 있나요?
각 항목에 문제가 없는지, 아니면 정확히 무엇을 고쳐야 하는지 알려주세요.

바이브 코딩 보안을 자세히 다루는 별도의 전체 가이드도 있습니다. 바이브 코딩 앱 보안 설정하기. 규칙은 간단합니다. 확인하기 전까지는 AI가 기본 설정으로 한 모든 일을 안전하지 않다고 간주하세요.

제품을 어디에 호스팅할까: 호스팅 단계별 안내#

처음부터 서버를 빌려 직접 설정할 필요는 없습니다. 초반에는 복잡한 작업이라 시간을 잡아먹습니다. 제품이 성장하면서 올라갈 수 있는 단계가 있습니다.

1. 무료 호스팅(예: Vercel): 개인용, 테스트, 소규모 프로젝트에 적합합니다. 플랫폼을 대상 사용자도 이용할 수 있고 사람들의 개인정보를 저장하지 않는 경우에 사용할 수 있습니다.
2. 한 번의 명령으로 배포할 수 있는 플랫폼(Railway): 백엔드와 데이터베이스가 있을 때 사용합니다. 한 번의 명령으로 배포할 수 있고 서버 설정이 필요 없습니다. 시작 장벽이 낮습니다.
3. 자체 전용 서버: 부하가 크고 완전한 제어가 필요할 때 사용합니다. 플랫폼의 한계에 도달한 뒤 옮기세요.

방금 제품을 출시한 비개발자에게 가장 쉬운 방법은 서버를 직접 설정하지 않아도 되는, 한 번의 명령으로 배포할 수 있는 플랫폼입니다. 나중에 자체 서버로 옮기세요. 구체적인 사례를 따라가고 싶다면 Coolify로 바이브 코딩 프로젝트를 자체 서버에 배포하기 가이드를 참조하세요.

앱, 데이터베이스, 백업은 언제 분리해야 할까?#

한 바구니에 담아 두지 말아야 할 것이 세 가지 있습니다. 앱, 데이터베이스, 백업입니다. 사용자가 적을 때는 모두 한곳에 있어도 괜찮습니다. 하지만 분리할 때를 알려주는 분명한 신호가 있습니다.

• 앱과 데이터베이스를 서로 다른 머신에 둡니다. 신호는 다음과 같습니다. 최대 부하에서 CPU와 메모리 사용량이 70–80 percent를 넘어 계속 유지되고, 요청이 느려지며, 앱과 데이터베이스가 같은 리소스를 놓고 경쟁합니다. 분리하면 앱을 건드리지 않고 데이터베이스를 강화할 수 있고, 그 반대도 가능합니다.
• 3-2-1 백업 규칙을 따릅니다. 데이터를 세 개 복사해 서로 다른 두 종류의 매체에 보관하고, 하나는 외부에 둡니다. 하드웨어 고장과 랜섬웨어로부터 보호할 수 있습니다. 핵심은 백업을 자동화하는 것입니다.

백업 빈도는 몇 시간 동안의 데이터 손실이 얼마나 큰 비용을 초래하는지에 따라 달라집니다. 결제 기록 한 시간 분량의 손실을 감당할 수 없는 온라인 구독 서비스라면 백업 간격을 한 시간보다 짧게 하거나 검증된 트랜잭션 로그와 시점 복구(PITR)를 사용해야 합니다. 감당 가능한 최대 데이터 손실에 따라 간격을 정하고 서비스 복구에 걸리는 시간도 따로 시험하세요. 블로그는 하루 한 번이면 충분합니다. 논리는 간단합니다. 감당할 수 있는 데이터 손실량을 정하고 그에 맞춰 백업을 설정하세요.

제품을 더 안정적인 인프라로 옮길 때가 됐는지 판단하도록 도와주세요. 각 항목을 확인하고 제게 질문하세요.

최대 부하에서 CPU와 메모리 사용량은 얼마나 되나요? 사용량이 70–80 percent를 넘어 계속 유지되나요?

데이터베이스와 앱은 같은 머신에 있나요, 서로 다른 머신에 있나요?

자동 데이터베이스 백업이 설정되어 있나요? 백업에서 복원하는 테스트를 했나요?

배포 전에 확인할 별도의 환경 사본(스테이징)이 있나요?
결과에 따라 명확하게 권고해 주세요. 무엇을 그대로 둘지, 무엇을 먼저 분리할지, 그 이유는 무엇인지 알려주세요.

관리형 데이터베이스와 자체 데이터베이스 중 무엇을 쓸지도 별도로 고려해야 합니다. 소규모 팀이라면 관리형 데이터베이스가 거의 항상 낫습니다. 직접 운영하면 하드웨어 비용은 저렴하지만 유지 관리에 몇 시간을 써야 합니다. 혼자 일하고 제품이 인프라 자체가 아니라면, 그 시간은 서버 가격 차이보다 비쌉니다.

유지 관리를 자동화하려면 어떻게 해야 할까?#

수동 유지 관리는 지칩니다. 모니터링과 순찰 에이전트, 두 가지 방식으로 직접 관리하는 수고를 줄일 수 있습니다.

모니터링 도구는 서로 다른 두 가지 작업을 담당합니다.

1. “사이트가 온라인인가?” — UptimeRobot과 같은 가동 시간 모니터입니다. 몇 분마다 제품에 신호를 보내고 다운되면 알림을 보냅니다. 무료 요금제가 있습니다.
2. “정확히 무엇이 고장 났나?” — Sentry와 같은 오류 추적 도구입니다. 앱 내부의 오류를 수집해 어디서 왜 문제가 생겼는지 보여줍니다.

첫 번째 도구는 제품이 중단된 사실을 잡아냅니다. 두 번째 도구는 어떤 기능이 왜 고장 났는지 보여줍니다. 두 도구를 함께 사용하면 “고객이 지원팀에 연락하기 전에 장애를 알 수 있을까?”라는 질문에 답할 수 있습니다.

자동화의 두 번째 단계는 순찰 에이전트입니다. 부동산 중개업소를 상상해 보세요. 오전 7시에 AI 에이전트가 웹사이트 문의를 읽다가 예약 양식이 고장 난 것을 발견하고, 코드에서 원인을 찾아 설명과 함께 바로 적용할 수 있는 수정안을 가져옵니다. 당신이 검토하고 “예”라고 하면 배포됩니다. 순서가 중요합니다. 먼저 사용자의 문제를 해결하고(접근 권한을 부여하고 사과한 뒤), 원인과 비용을 조사합니다.

AI가 운영 데이터베이스에 접근할 때 적용할 규칙이 하나 더 있습니다. 읽기 전용 사용자를 부여하고 개인정보를 중간 계층 뒤에 숨겨 에이전트에게 실제 사람 이름 대신 “이름”을 보여주세요. 그러면 실수를 하더라도 운영 데이터를 물리적으로 삭제하거나 손상시킬 수 없습니다. 에이전트가 운영 데이터베이스를 지워 버린 위 표의 사례는 바로 이런 제한이 없었던 문제를 보여줍니다. AI가 데이터베이스를 삭제했을 때 해야 할 일 가이드에서 이미 재난이 일어났을 때 어떻게 해야 하는지 설명합니다.

제품을 언제 종료해야 할까?#

유지 관리에서 가장 과소평가되는 부분은 언제 그만둘지 아는 것입니다. 많은 것을 만드는 사람은 누구나 프로젝트의 무덤을 갖고 있습니다. 하나를 만들고, 손보고, 결국 버린 프로젝트들입니다. 이는 정상이며 실패가 아닙니다. 실패는 들인 시간이 아까워 아무도 쓰지 않는 것을 몇 달 동안 끌고 가는 것입니다.

결정을 내릴 때 참고할 기준은 다음과 같습니다.

1. 2주 — 아이디어가 통하는지 알아보기에 충분한 기간입니다. 실제 첫 사용자들이 다시 찾아오면 계속하세요. 침묵도 답입니다.
2. 3개월 — 절대 넘지 말아야 할 한도입니다. 3개월 안에 반응이 없으면 종료하세요. 바이브 코딩 속도를 고려하면 하나의 아이디어를 6개월 동안 시험하는 건 너무 깁니다.

프로젝트를 닫는 일은 심리적으로 어렵기 때문에 감정이 아니라 결정으로 다루세요. 투자한 프로젝트를 놓아주는 일은 일을 제대로 하지 못하는 직원을 해고하는 것과 같습니다. 불쾌하지만 계속 고용하는 비용이 내보내는 비용보다 큽니다.

유지 관리는 제품을 살아 있게 하고 사람들에게 계속 쓸모 있게 만드는 작업입니다. git, 백업, 모니터링은 제품이 매일 당신을 위해 작동하기 시작하는 지점에 도달하도록 돕는 도구일 뿐입니다.

저녁 한 번 만에 AI로 제품을 만드는 일은 작업의 절반입니다. 제품이 성장하는 동안 살아 있고 안전하게 유지하는 것, 이것이 어른답게 바이브 코딩하는 방식입니다.

다음 단계는 Ailoot입니다.