AI 때문에 잠깐 월 1억 부자였다 - 비개발자의 ERP 6주 삽질기

- 비개발자의 ERP 6주 삽질기

이 글이 누구에게 도움이 될까
- ERP 쓰다가 "이거 내가 만들면 되지 않나?" 생각해본 자영업자
- Claude Code·Cursor로 뭔가 만들다가 이상한 지점에서 막힌 비개발자
- AI가 그럴듯하게 돌아가는 것처럼 보이는데 실은 지뢰가 심어져 있을 때 어떻게 잡아내는지 궁금한 사람

지난 글에서 상품등록기 만들다가 OCR이 저장 안 되고 있던 대참사 이야기 했어요. 오늘은 그 다음 이야기.

상품등록기와 거의 동시에 만든 게 ERP였어요. 이카운트 구독료 44,000원이 아까워서 시작했는데, 결과적으로 Claude Code가 숨겨놓은 지뢰 덕분에 잠깐 월 1억 순이익 부자가 됐다가 현실 자각한 이야기입니다.

바로 가기

1. 형부가 내 코드 보고 한 말
2. 이카운트 44,000원이 아까워서
3. 판촉물 본사 발주 데이터 - 지옥의 시작
4. 어느 날 출고 캘린더에 찍힌 월 1억 순이익
5. 코드를 뜯었는데 값이 안 바뀌었던 이유
6. 비개발자의 함정 - 값이냐 계산식이냐
7. GitHub Actions를 포기한 순간
8. 지금의 ERP - 아직 불완전하다
9. 배운 것

형부가 내 코드 보고 한 말

2월 말, 제가 처음 만든 상품등록기 초안을 주변에 공유했어요. 크롤링해서 엑셀로 뽑는 수준의 원시적인 버전이었습니다.

친한 언니한테도 보여줬어요. 웹디자이너 시절부터 알던 언니인데, 그 형부가 개발자예요. 며칠 뒤 언니한테서 전달받은 말이 있었습니다.

형부: "어... 비밀번호를 박아놨던데, 저건 아니지."
그리고 이어서:
형부: "근데 걔 좀 무서운 사람이야. AI가 사람 대체하는 게 아니라, AI를 잘 쓰는 사람이 사람을 대체하는 건데, 걔가 딱 그런 사람이야."

앞부분은 기술 지적이었고, 뒷부분은 전혀 예상 못 한 말이었어요. 저는 그때 "그냥 엑셀 자동화한 거" 정도로 생각하고 있었거든요. 근데 개발자 시선에서는 다르게 보였나 봐요.

그 말을 듣고 본격적으로 마음을 먹었어요. "그럼 이카운트도 내가 만들어 보지 뭐."

이카운트 44,000원이 아까워서

이카운트 쓰고 계셨어요. 자영업자용 회계·ERP 서비스. 월 구독료 44,000원.

"그 정도면 싸잖아?"라고 하실 수 있는데, 저는 견적 기능만 쓰고 있었어요. 주문·재고·회계 기능 거의 안 썼거든요. 혼자 운영하고 위탁 공장이 생산 다 해주는 구조라 복잡한 ERP 기능이 필요 없었습니다.

견적서 하나 뽑자고 월 44,000원? 연 528,000원? 너무 아까웠어요.

그래서 결정했습니다. "이카운트 해지하고 내가 만들자."

처음엔 쉬워 보였어요. 이카운트에서 기존 견적 데이터 CSV로 뽑는 건 간단했고, 그걸 DB에 넣는 것도 금방 됐어요. Claude Code한테 "이런 화면 만들어 줘" 하니까 며칠 만에 기본 형태가 나왔습니다.

"어? 생각보다 쉽네?"

이게 함정이었어요.

판촉물 본사 발주 데이터 - 지옥의 시작

ERP의 진짜 코어는 "데이터가 제대로 흐르는가" 입니다.

제 경우에는:
1. 고객이 주문 → 저희 ERP에 저장
2. 저희가 판촉물 본사에 발주 → 발주 내역이 ERP에 반영
3. 상품가 + 발주가 → 마진 자동 계산
4. 출고일 기준으로 → 일별 순이익 집계

여기서 2번 "발주 내역이 ERP에 반영" 부분이 지옥이었어요.

판촉물 본사 시스템에 제가 접근할 수 있는 권한은 "단순 관리자" 수준이에요. DB에 직접 붙어서 쿼리 돌릴 수 있는 게 아니고, 본사 사이트 화면 통해서만 데이터를 볼 수 있습니다. 즉, 발주 정보를 받아오려면 크롤링하거나 수동으로 입력해야 하는 구조.

Claude Code한테 요청했어요:

"판촉물 본사에서 발주 데이터 받아와서, 상품가랑 비교해서 마진 계산하고, 출고 캘린더에 순이익으로 표시해줘."

Claude Code가 뭔가 만들었고, 돌아갔어요. 테스트해보니 숫자도 나오고, 캘린더도 보이고. "오 이거 되네?"

어느 날 출고 캘린더에 찍힌 월 1억 순이익

며칠 지나서 출고 캘린더를 열었어요. 일별로 순이익이 찍혀 있는 화면.

숫자가 이상했어요. 어떤 날은 적게, 어떤 날은 꽤 크게. 한 달 치를 합쳐보니 편차가 몇 배씩 벌어졌어요.

처음 든 생각: "어? 나 이렇게 많이 벌었나?"

잠깐 기뻤어요. 정말로요. "매출 반토막 났다고 징징댔는데 알고 보니 마진은 괜찮았구나" 생각했어요. 약 3초 정도요.

그 다음 생각: "근데... 통장엔 왜 없지?"

현실 자각이 왔어요. 월 1억 순이익이면 제가 지금 새 차 뽑고 있어야 하는데, 저는 여전히 재발주 고객 챙기느라 새벽까지 일하고 있었거든요.

뭔가 잘못된 거예요.

코드를 뜯었는데 값이 안 바뀌었던 이유

버그 추적 시작.

처음엔 계산식이 틀렸다고 생각했어요. 마진 계산 로직이 잘못돼서 이상한 값이 튀어나온다고.

Claude Code한테 물어봤어요:

"마진 계산식 보여줘. 어디서 이 숫자 나오는지."

Claude Code가 계산 코드를 보여줬어요. 보니까 수식은 멀쩡했습니다. (판매가 - 발주가) * 수량 같은 당연한 식. 이상한 구석이 없었어요.

근데 실제 화면에 표시되는 숫자는 전혀 다른 값이 나왔어요. 이게 며칠 갔어요. 코드 이리저리 뜯어보고, 수식 수정해보고, 조건 바꿔보고. 근데 결과는 똑같았어요. 월 1억 순이익 부자.

결국 제가 원인을 찾은 건 DB를 직접 열어봤을 때였습니다.

order_items 테이블을 조회해봤더니 - profit 컬럼에 값이 그냥 박혀 있었어요.

그러니까 뭐냐면, Claude Code가 제 요청을 구현할 때 계산식을 코드에 넣은 게 아니라, "계산된 결과값을 DB에 저장"하는 구조로 만들어놨던 거예요. 그래서:

• 제가 코드의 계산식을 아무리 고쳐도 → 반영 안 됨 (왜냐하면 이미 DB에 계산된 값이 박혀있으니까)
• 화면은 DB에 박힌 값을 그냥 표시 → 코드 안 거침
• 그 박힌 값이 초기 테스트 때 이상하게 계산된 상태로 저장됨 → 계속 그 잘못된 값이 나옴

이거 찾느라 삽질 엄청 했어요. 코드만 들여다보던 저는 "코드 어디가 잘못됐지?" 이 한 가지 생각에 갇혀 있었거든요.

비개발자의 함정 - 값이냐 계산식이냐

이 사건을 겪으면서 한 가지 확실히 배웠어요.

AI 코딩의 가장 무서운 함정은 "겉으론 돌아가는 것처럼 보이는데 구조가 어긋나 있는 경우"예요.

Claude Code는 "일단 결과가 나오게 해줘"라고 하면 제일 빠른 경로로 갑니다. 계산식을 제대로 코드에 넣고 실시간으로 돌리는 것보다 "일단 한 번 계산한 결과를 DB에 박아두는 것"이 훨씬 빠르거든요.

이게 당장은 돌아가요. 화면에도 숫자가 뜨고, 테스트도 잘 통과하는 것 같고요. 근데 변수 하나가 바뀌면(발주가가 수정되거나, 수량이 바뀌거나, 상품가가 조정되면) 그 값이 반영이 안 돼요. DB에 박힌 옛날 값이 계속 튀어나오니까.

비개발자인 제가 여기서 막힌 이유:
- 저는 소스를 읽지 못해요. Claude Code가 써준 걸 믿고 쓰는 구조
- 문제가 생기면 증상(화면에 이상한 값) 을 보고 코드 수정을 시도
- 근데 실제 문제는 데이터 구조 (DB에 값이 박혔는지, 계산식이 실시간으로 도는지)
- 이건 "DB랑 코드 중 어디가 진실의 원천(Source of Truth)인지" 를 알아야 하는 문제

이 감각을 얻는 데 며칠 날렸습니다. 지금은 ERP 고칠 때마다 Claude Code한테 매번 확인해요:

"이 값, DB에 저장하는 거야 아니면 매번 계산하는 거야?"
"만약 발주가가 바뀌면 이 숫자 자동으로 다시 계산돼?"
"실제로 DB 열어봤을 때 어떤 값이 들어가 있는지 SQL로 조회해서 보여줘."

"돌아가는지"가 아니라 "구조가 맞는지"를 물어야 한다는 감을 이때 잡았어요.

GitHub Actions를 포기한 순간

ERP 만들면서 배포도 큰 벽이었어요.

처음엔 "제대로 해보자" 싶어서 GitHub Actions로 자동 배포를 구축하려고 했습니다. 코드 push하면 서버에 자동으로 반영되는 그 흐름이요. 개발자들이 다 쓰는 표준 방식이니까.

안 되더라고요.

워크플로우 YAML 설정이 꼬이고, 권한 문제 터지고, 테스트 스크립트가 실패하고요. Claude Code가 여러 번 도와줬는데도 매번 새로운 오류가 튀어나왔어요. 며칠 붙잡고 있다가 결국 포기했습니다.

그냥 서버에 직접 배포하기로 했어요. 로컬에서 코드 짜고 → SSH로 서버 접속 → 파일 복사 → 서비스 재시작. 구시대적이지만 어쨌든 돌아갑니다.

솔직히 지금도 "이게 맞는 방식인가?" 싶긴 해요. 개발자 친구들한테 말하면 "야 GitHub Actions 써야지" 할 것 같고요. 근데 혼자 운영하는데 굳이 그럴 필요가 있나 싶기도 합니다.

찾아보니까 CI/CD 자동화의 원래 목적은 "여러 사람이 협업할 때 충돌 방지"더라고요. 혼자 운영하는 저한텐 과한 방법일 수도 있겠다는 결론이 났어요. 지금은 직배포로 잘 쓰고 있고, 팀이 생기는 날 GitHub Actions로 옮길 생각입니다.

지금의 ERP - 아직 불완전하다

솔직히 지금 ERP는 아직 불완전해요.

기존에 만들어놓은 "박힌 값들" 이 여기저기 남아있어서, 재발주 고객이 들어올 때마다 "이 상품 데이터 제대로 흐르나?" 확인하면서 돌아가며 수정하고 있어요. 완전히 청소한 적이 없어서, 버그가 언제 어디서 또 튀어나올지 모릅니다.

그런데 이카운트로 돌아갈 수는 없어요. 44,000원이 아까운 건 여전하고, 무엇보다 제가 만든 거니까 제가 원하는 대로 바꿀 수 있거든요. 이카운트는 견적 양식 하나 바꾸려고 해도 기능 제한에 걸렸는데, 지금은 제가 원하는 대로 다 가능합니다.

일단 견적·주문·시안·발주·출고·배송·거래처·품목·정산 모든 흐름이 기본적으로는 돌아가요. 재발주 고객이 들어오면 잘 처리되고, 출고 캘린더도 이제 현실적인 숫자를 보여줍니다 (월 1억 아니에요, 진짜로 ㅠ).

배운 것

6주 ERP 만들면서 얻은 것들:

1. AI 코딩의 진짜 함정은 "구조"에 있다

코드 문법 오류는 AI가 잘 잡아줘요. 근데 "이거 계산식으로 만들어야 하는지, 값으로 저장해야 하는지" 같은 구조적 판단은 AI가 자주 틀려요. 비개발자가 제일 속기 쉬운 지점입니다.

2. 물어봐야 할 질문

• "이 값, DB에 저장하는 거야 매번 계산하는 거야?"
• "변수가 바뀌면 자동 재계산돼?"
• "DB 열었을 때 실제 어떤 값이 들어있어?"

이 세 가지만 매번 물어봐도 지뢰 절반은 미리 찾을 수 있어요.

3. 증상이 아니라 원인을 봐야 한다

"숫자가 이상하다" → 계산식만 뜯어보지 말고 데이터가 어디서 오는지 먼저 확인. 코드가 맞아도 데이터가 틀리면 답은 틀려요.

4. 표준이 꼭 정답은 아니다

GitHub Actions가 "표준"이지만, 혼자 운영하는 1인 자영업자한테는 과해요. 자기 상황에 맞는 선택이 맞는 거예요. 표준 따라가려다 며칠 날리는 것보다 돌아가는 구조로 빨리 가는 게 낫습니다.

5. 44,000원을 아끼려다 6주를 썼다

솔직히 시간당 비용으로 따지면 이카운트 그냥 쓰는 게 훨씬 경제적이에요. 근데 저는 ERP 만드는 과정에서 배운 게 그 시간 이상의 가치가 있다고 봅니다. 이 경험 없이 다른 프로젝트 갔으면 똑같은 지뢰를 거기서 또 밟았을 거예요.

다음 편 예고

다음 글은 "AI가 중간에 거짓말하는 걸 잡아내는 46개 규칙" 이야기. 제가 Claude Code한테 여러 번 속고 만든 방어 체계예요. "다 했어요"라고 해놓고 실은 안 된 경우 잡아내는 법, 에러를 조용히 우회하는 거 감지하는 법.

그 다음엔 "5개 Claude Code 세션을 동시에 돌리는 병렬 작업 체계". 한 명이 어떻게 6주 동안 ERP + 상품등록기 + 멀티사이트 + 자동 포스팅 + 대시보드를 동시에 만들 수 있었는지.

저에 대해

주영. 판촉물 자영업자. AI로 바이브코딩 중.
- 21살부터 디자인 전 영역(웹·제품·영상·인쇄) + 마케팅·국가지원사업 경험, 판촉물 창업 3년 반차
- 2026년 2월부터 AI 자동화 전환 중
- 현재 운영 중 서비스: FreeToolbox.kr (무료 온라인 도구 포털), 판촉물가격비교, 마이비와이디홈(준비 중), 캐릭터 사주 서비스(한국어 준비 중)
- 이 블로그는 그 과정의 진짜 기록입니다

이 글은 2026년 4월 기준으로 작성되었습니다. ERP는 지금도 계속 고쳐가며 쓰고 있어요. 월 1억 부자 시기는 다행히 끝났습니다.