바이브코딩 완성 ..But 그 이후..
돌아가는 것과
제대로 돌아가는 것은 다르다
비개발자가 직접 겪은 CRM 디버깅 이틀의 기록
4개월 전, 나는 처음으로 Claude와 함께 세무업무용 CRM을 만들었다. 코딩을 배운 적 없는 세무사가 AI와 대화만으로 프로그램을 만든다는 것 자체가 신기했고, 화면에 뭔가가 뜨고 버튼이 반응하고 메일이 나가는 순간 — 그것만으로도 충분히 감격스러웠다.
그런데 최근 이틀, 나는 전혀 다른 종류의 경험을 했다. 파일질라로 서버 폴더를 들여다보다 용량이 이상하게 크다는 걸 우연히 발견한 것이 시작이었다. 그 작은 위화감을 따라가다 보니 — 내가 모르는 사이에 서버에 쌓이고 있던 유령 파일들, 동명 파일을 다 업체에서 삭제하는 치명적인 버그, 이메일 삭제해도 첨부가 서버에 남는 구조적 문제까지 줄줄이 드러났다. 공통점은 하나였다. 파일이 들어오는 순간은 설계했지만, 나가는 순간은 설계하지 않았다.
이 글은 그 이틀의 기록이다. 비개발자로서 바이브코딩으로 프로그램을 만들고 싶은 사람이라면, 누구도 미리 말해주지 않는 그 다음 단계에 대해 — 이 경험이 조금이나마 길잡이가 되길 바란다.
🔍 발단 — 우연히 본 숫자 하나
서버 업로드 폴더에 파일이 285개나 쌓여 있었다. CRM을 통해 발송하고 수신한 문서들이 서버에 보관되는 건 알고 있었지만, 이 숫자는 너무 컸다. Claude Code에 점검을 의뢰했다.
AI의 첫 진단을 바로 믿지 말 것. “262개 문제”라는 말에 바로 수정 들어갔다면 정상 파일까지 건드렸을 것이다. DB와 디스크를 직접 대조하는 교차 검증이 먼저였다.
💥 복병 — 동명 파일 다업체 삭제 버그
재복사 루프를 막는 코드를 추가하고 더미 테스트까지 통과했다. 그런데 실제 데이터로 검증하는 과정에서 숫자가 맞지 않았다.
A 업체의 발송함 10개를 지웠는데 WorkDocs에 182개가 남아야 했지만 139개밖에 없었다. AI는 “comm 계산 오류, 정상입니다”라고 넘어가려 했다. 그러나 단순히 받아들이지 않고 파고들었다.
삭제 코드가 파일을 파일명(original_name)으로 매칭하고 있었다. 원천세 신고서, 종소세 납부서처럼 모든 업체가 같은 이름으로 가진 파일의 경우 — A업체 것을 지우면 다른 업체들의 동명 파일까지 줄줄이 삭제됐다.
182개에서 139개가 된 이유: 다른 업체들의 동명 파일 43개가 함께 날아간 것이었다.
이 버그가 커밋됐다면? 앞으로 발송함에서 파일 하나를 지울 때마다 다른 업체의 동명 파일이 조용히 사라지는 사고가 반복됐을 것이다. 원천세 신고서처럼 전 업체가 같은 이름을 쓰는 구조에서 특히 치명적이었다.
파일 삭제는 절대로 “이름”으로 하면 안 된다. 고유 식별자(company_id, filename의 타임스탬프-랜덤 조합)로 정확히 특정해야 한다. 그리고 더미 테스트는 “동명 파일이 여러 업체에 있는” 실제 사용 시나리오를 재현해야 의미가 있다.
🔧 추가 발견 — 이메일 첨부의 구조적 문제
파일 문제를 정리하는 과정에서 이메일 쪽의 문제도 드러났다. 공통점은 하나였다. 파일이 들어오는 순간은 설계했지만, 나가는 순간은 설계하지 않았다.
documents 테이블의 FK가 ON DELETE CASCADE로 설정돼 있어서, 업체를 CRM에서 삭제하면 그 업체로부터 받은 수신 첨부파일도 연쇄 삭제됐다. 모든 업체가 각자의 수신함을 가진 구조에서 이건 치명적인 데이터 손실이었다.
이메일을 삭제(soft delete)하면 메일 레코드만 is_deleted=1이 되고, 업로드 폴더의 첨부 파일은 그대로 남았다. 보낸 메일도 마찬가지 — attachments_json에 기록된 첨부 파일이 서버에 계속 누적됐다.
해결: CASCADE를 SET NULL로 바꾸는 스키마 마이그레이션(업체 삭제 시 파일은 남되 company_id만 NULL로), 그리고 이메일 삭제 라우트에 email_id로 연결된 첨부 파일까지 함께 정리하는 로직 추가.
DB 스키마의 CASCADE 설정 하나가 생각지도 못한 데이터 손실을 부른다. 처음 만들 때는 “삭제하면 연결된 것도 다 지워지면 편하겠다”고 생각했을 것이다. 하지만 실제 운영에서는 “어떤 삭제가 어디까지 영향을 미치는가”를 항상 명시적으로 설계해야 한다.
🛡️ 이틀이 가르쳐 준 것들
이틀 동안의 작업을 돌아보면, 단순한 버그 수정 이상의 것들을 배웠다.
처음 CRM이 완성됐을 때, 버튼이 눌리고 메일이 나가고 화면이 뜨는 것만으로 성공이라 생각했다. 그런데 그 이면에서 파일이 조용히 쌓이고, 삭제가 엉뚱한 데까지 미치고, 업체를 지우면 받은 서류도 함께 사라지는 일들이 벌어지고 있었다. 프로그램이 “돌아가는 것”과 “제대로 돌아가는 것”은 완전히 다른 단계다.
이번 이틀 동안 Claude Code는 “완벽합니다”, “정상입니다”, “완료됐습니다”를 수없이 말했다. 그때마다 숫자가 맞지 않으면 넘어가지 않고 파고들었다. 그 습관이 동명 파일 버그, CASCADE 문제, 표시 오류를 연달아 잡아냈다. AI를 도구로 쓰되, 결과는 본인이 검증해야 한다.
처음 더미 테스트는 단순히 “파일이 지워지나”만 확인했다. 동명 파일이 여러 업체에 있는 상황을 재현하지 않았기 때문에 버그를 통과시켰다. 테스트는 “잘 될 때”가 아니라 “실패할 수 있는 상황”을 만들어야 한다.
DB 스키마를 바꾸거나, 파일 삭제 로직을 수정하거나, 테이블을 재생성할 때마다 백업을 먼저 떴다. 한 번도 필요한 적이 없었다. 하지만 그 “한 번도 필요 없었음”이 백업 덕분이라는 걸 안다. 위험한 작업일수록 되돌아올 길을 먼저 만들어야 한다.
이번 이틀의 작업을 관통하는 가장 근본적인 교훈은 이것이다. 파일이 생성되거나 외부에서 들어오는 순간을 설계할 때, 반드시 그 파일이 언제, 어떤 조건으로, 어디서 사라지는지를 동시에 설계해야 한다.
발송하면 uploads에 복사본이 생긴다 → 그럼 발송함을 비울 때 그 복사본은 어떻게 되는가. 이메일을 받으면 첨부가 서버에 저장된다 → 그럼 그 이메일을 지울 때 첨부는 어떻게 되는가. 업체를 등록하면 수신 문서가 그 업체에 묶인다 → 그럼 업체를 삭제할 때 그 문서들은 어떻게 되는가.
단순히 서버에 파일을 쌓고 DB화해서 화면으로 보는 기쁨에만 안주하면, 어느 순간 서버는 아무도 모르게 불어나 있다. 어떤 기능이 작동하면 그 다음은 어떻게 되는가 — 사후 흐름 알고리즘을 개발 단계에서부터 반드시 설계에 포함해야 한다. 저장과 삭제는 한 쌍이다. 어느 한쪽만 있는 설계는 미완성이다.
이 모든 것의 출발점은 파일질라로 서버를 들여다보다 용량이 이상하게 크다는 느낌이었다. 거창한 점검이나 체계적인 감사가 아니었다. 그 작은 위화감을 그냥 넘기지 않은 것이 시한폭탄 몇 개를 미리 해체하게 했다. 내 시스템을 주기적으로 직접 들여다보는 습관이 중요하다.
“첫 시제품 완성은 결승선이 아니라 출발선이다.
그 이후가 진짜 개발이고, 진짜 배움이다.”
바이브코딩으로 자신만의 프로그램을 만들고 싶다면 — 만드는 것에 두려움 가질 필요 없다. AI가 상당 부분을 함께해 준다. 하지만 만들고 난 다음, 실제로 쓰면서 오류를 잡아나가는 과정이 더 길고 더 중요하다는 것을 미리 알았으면 한다.
그 과정이 두렵거나 막막하게 느껴질 수 있다. 그런데 실제로 해보면 — 그게 또 다른 배움이고, 내 시스템을 진짜로 이해하게 되는 시간이다. 그리고 그 이해가 쌓일수록, 다음번엔 조금 더 빨리 문제를 알아채게 된다.
돌아가는 것에서 제대로 돌아가는 것으로. 그 여정이 진짜 개발자의 길이다.