2026년 7월, 한국 Threads에서 “바이브코딩으로 ERP를 만들었습니다”라는 글을 둘러싸고 논쟁이 벌어졌습니다. Threads 안에서 끝나지 않았습니다. 같은 날 LinkedIn에 이슈를 언급한 글이 올라왔고, 클리앙에는 ERP 구축 경험자가 별도 토론을 열었습니다. 다음 날에는 다른 개발자 커뮤니티에도 “실무 수준으로 가능한가”라는 질문이 이어졌습니다.
공개 검색으로는 Threads 원문의 전체 내용과 반응 수를 확인하지 못했습니다. 그래서 원글 작성자의 의도나 실제 시스템의 완성도를 평가할 수는 없습니다. 확인할 수 있는 것은 논쟁의 문장과 바깥으로 번진 반응입니다.
왜 이 말이 이렇게 크게 불탔을까요. 바이브코딩을 믿는 사람과 개발자가 싸운 것처럼 보이지만, 실제로는 양쪽이 서로 다른 것을 ERP라고 부르고 있었습니다.
화면이 돌아간다는 뜻의 ERP
회사 안에서 필요한 기능을 직접 만들 수 있습니다. 거래처를 등록하고, 주문을 입력하고, 재고를 조회하고, 매출 현황을 보여주는 화면도 AI 코딩 도구로 빠르게 구현할 수 있습니다.
업무를 잘 아는 사람이 직접 만들면 속도는 더 빨라집니다. 기존 개발에서는 요구사항을 전달하고 해석하는 데 시간이 들지만, 업무 담당자가 도구와 대화하며 바로 수정하면 중간 과정이 줄어듭니다.
사용자가 적고 범위가 좁으며, 문제가 생겼을 때 수기로 되돌아갈 수 있는 내부 도구라면 바이브코딩은 꽤 잘 맞습니다. 여기까지를 ERP라고 부른다면 “바이브코딩으로 ERP를 만들었다”는 말이 틀렸다고 단정하기 어렵습니다.
회사가 책임져야 한다는 뜻의 ERP
개발자들이 반발한 ERP는 다른 물건입니다.
주문 한 건이 들어오면 재고가 줄고, 매출과 채권이 생기며, 구매와 생산 일정이 바뀝니다. 취소나 반품이 발생하면 이미 처리된 데이터를 규칙에 맞게 되돌려야 합니다. 사용자마다 볼 수 있는 정보와 승인할 수 있는 금액도 다릅니다.
이런 시스템에서는 버튼이 눌리는지보다 다음 질문이 중요합니다.
- 같은 요청이 두 번 들어와도 거래가 한 번만 처리되는가
- 여러 사람이 동시에 수정해도 재고와 금액이 맞는가
- 누가 어떤 값을 바꿨는지 나중에 확인할 수 있는가
- 담당자가 자신의 거래를 스스로 승인하지 못하게 분리했는가
- 은행, 세금계산서, 물류·생산 시스템과 연결이 끊기면 어떻게 복구하는가
- 회계·세무·회사 규칙이 바뀌었을 때 누가 수정하고 검증하는가
- 기존 데이터를 옮긴 뒤 전후 잔액과 재고가 일치하는가
AI는 이 요구를 코드로 옮기는 속도를 높일 수 있습니다. 하지만 어떤 규칙이 맞는지, 오류가 났을 때 누구에게 책임이 있는지까지 정해주지는 않습니다.
도메인 지식만 있다고 끝나는 일도 아닙니다
클리앙 토론에서는 HR·회계·제조 BOM·물류 같은 도메인 지식이 필요하다는 반응이 많았습니다. ERP를 직접 구축하고 유지보수한 경험자가 “초반 30%는 빠르게 올라갔지만 연동 범위와 복잡성이 커지면서 시간이 오래 걸렸다”고 적은 댓글도 있었습니다.
도메인 지식은 출발점입니다. 업무를 안다고 해서 운영 시스템이 저절로 안전해지지는 않습니다. 반대로 개발을 잘한다고 회사의 회계와 재고 규칙을 알 수 있는 것도 아닙니다.
ERP에는 두 종류의 지식이 함께 필요합니다.
하나는 회사가 실제로 일하는 방식입니다. 다른 하나는 그 규칙이 누락·중복·동시 수정·권한 오류 속에서도 깨지지 않도록 만드는 시스템 지식입니다. 바이브코딩은 둘을 연결하는 구현 도구이지, 어느 한쪽을 대신하는 면허가 아닙니다.
‘완성’이라는 말이 너무 빨리 등장합니다
바이브코딩 데모에서는 화면이 열리고 주요 기능이 동작하면 완성처럼 보입니다. 회사 시스템은 첫 사용 후에 요구사항이 드러납니다.
월말 마감 중 숫자가 맞지 않거나, 퇴사한 직원의 권한이 남아 있거나, 제품 코드가 바뀌어 과거 주문을 찾지 못하는 문제가 생깁니다. 거래처가 보낸 엑셀 형식이 달라지고 외부 API가 변경되기도 합니다.
이때 필요한 것은 프롬프트 한 번이 아닙니다. 테스트 데이터, 변경 기록, 백업, 복구 절차와 운영 담당자가 필요합니다. 코드를 만든 사람과 회사를 떠난 뒤에도 시스템이 굴러가야 합니다.
일주일 만에 만든 화면과 몇 년 동안 운영할 ERP를 같은 단어로 부르면 논쟁은 피하기 어렵습니다.
세 단계로 부르면 이야기가 쉬워집니다
바이브코딩으로 만든 결과물을 무조건 ERP라고 부르거나, 반대로 장난감이라고 깎아내릴 필요는 없습니다. 범위를 세 단계로 나누면 판단하기 쉽습니다.
1. 업무 보조 도구
기존 ERP 데이터를 읽어 보고서를 만들거나, 주문서 초안을 정리하고, 반복 입력을 줄이는 도구입니다. 오류가 나도 담당자가 원본과 비교해 고칠 수 있습니다.
바이브코딩이 가장 잘 맞는 영역입니다.
2. ERP 주변 모듈
특정 부서의 견적, 승인, 현장 기록을 처리한 뒤 검증된 결과만 기존 ERP로 넘깁니다. 독립적인 사용자와 데이터가 있지만 회계 원장이나 핵심 재고를 직접 소유하지는 않습니다.
이 단계부터 권한, 로그, 중복 방지, 백업과 운영 책임자가 필요합니다.
3. 핵심 ERP
회계, 인사·급여, 재고·원가와 회사의 공식 거래 기록을 직접 관리합니다. 여러 부서와 외부 시스템이 연결되고, 잘못된 값이 청구·납품·신고에 영향을 줍니다.
AI 코딩 도구를 써도 설계·검토·테스트와 장기 유지보수 조직이 필요합니다. “혼자 만들었다”보다 “누가 계속 책임질 것인가”가 더 큰 질문입니다.
바이브코딩은 ERP의 바깥쪽부터 쓰는 편이 좋습니다
처음부터 회계 원장이나 전체 재고를 교체하지 않아도 됩니다. 기존 ERP가 불편한 지점을 찾아 주변 업무부터 개선할 수 있습니다.
예를 들면 이메일 주문서를 검토 대기 상태로 만들거나, 현장 기록을 표준 양식으로 모으거나, ERP 데이터를 읽어 담당자별 할 일을 보여주는 도구입니다. AI가 초안을 만들고 사람이 승인한 결과만 핵심 시스템에 넣으면 실패 범위를 줄일 수 있습니다.
이 방식은 화려하지 않습니다. 대신 기존 업무를 멈추지 않고 효과와 오류를 함께 확인할 수 있습니다.
개발자가 사라지는 이야기가 아니었습니다
이번 밈이 불탄 이유는 AI가 코드를 잘 짜서가 아닙니다. “만들었다”는 짧은 문장 안에서 분석, 설계, 검증, 데이터 이관과 유지보수 같은 보이지 않는 일이 사라졌기 때문입니다.
바이브코딩으로 ERP를 만들 수 있습니다. 다만 먼저 ERP의 범위를 한 문장으로 고정해야 합니다. 어느 부서가 쓰고, 어떤 데이터를 책임지며, 오류가 나면 어디까지 영향을 주고, 누가 복구할 것인지 답할 수 있어야 합니다.
그 답이 없다면 만든 것은 ERP라기보다 ERP처럼 보이는 첫 화면에 가깝습니다. 반대로 그 답을 갖춘 사람이 AI로 구현 시간을 줄였다면, 그것은 충분히 의미 있는 변화입니다.
프로젝트 문의
사내 ERP 전체를 새로 만들지 않아도 반복 입력, 승인 대기, 현장 기록과 보고서부터 개선할 수 있습니다. MOSH는 기존 시스템을 유지하면서 분리 가능한 업무를 찾고, 바이브코딩·AI 자동화가 맞는 범위와 사람이 책임져야 할 경계를 함께 검토합니다.
확인한 공개 자료
#바이브코딩 #ERP #AI코딩 #Threads #사내시스템