바이브코딩으로 ERP를 만들었다면, 어디까지를 만들었다는 뜻일까요?

바이브코딩으로 ERP를 만들었다는 문장은 최근 실제로 논쟁이 됐습니다.[1] 특정 결과물을 평가하려는 것이 아니라, 이 문장이 왜 사람마다 다르게 읽히는지를 보려 합니다.

누군가는 거래처·주문·재고를 입력하는 사내 화면을 떠올리고, 누군가는 회계·재고·급여와 회사의 공식 거래 기록을 책임지는 핵심 시스템을 떠올립니다. 같은 ERP라는 단어로 서로 다른 범위를 말하면 한쪽에는 혁신이고 다른 쪽에는 과장이 됩니다.

바이브코딩으로 ERP를 만들 수 있느냐는 질문보다, 어디까지 만들었고 무엇을 책임지는지 묻는 편이 정확합니다.

화면이 동작한다는 뜻의 ERP가 있습니다

AI 코딩 도구를 사용하면 거래처를 등록하고, 주문을 입력하고, 재고를 조회하고, 매출 현황을 보여주는 화면을 빠르게 만들 수 있습니다. 업무 담당자가 직접 요구를 설명하고 결과를 바로 수정하면 전달과 해석에 걸리는 시간도 줄어듭니다.

사용자가 적고 범위가 좁으며, 오류가 나도 원본 자료와 기존 시스템으로 돌아갈 수 있는 내부 도구라면 바이브코딩이 잘 맞습니다.

• ERP 데이터를 읽어 담당자별 보고서를 만듦
• 이메일 주문서를 검토 대기 상태로 정리함
• 현장 사진과 작업 내용을 표준 양식으로 모음
• 승인 전에 누락된 값을 확인함
• 기존 화면의 반복 입력을 줄임

이 범위를 우리 팀용 ERP라고 부르는 조직도 있습니다. 실제 업무를 줄인다면 이름 때문에 가치를 낮출 이유는 없습니다. 다만 이 도구가 회사의 공식 원장을 소유하는지는 따로 말해야 합니다.

회사가 책임져야 한다는 뜻의 ERP도 있습니다

핵심 ERP에서 주문 한 건이 들어오면 재고가 줄고, 매출과 채권이 생기며, 구매와 생산 일정이 바뀝니다. 취소·반품이 발생하면 이미 처리된 데이터를 규칙에 맞게 되돌려야 합니다.

이 시스템에서는 버튼이 눌리는지보다 다음 질문이 중요합니다.

• 같은 요청이 두 번 들어와도 거래가 한 번만 처리되는가
• 여러 사람이 동시에 수정해도 재고와 금액이 맞는가
• 가격·세금·원가를 신뢰할 원본에서 다시 계산하는가
• 누가 어떤 값을 왜 바꿨는지 확인할 수 있는가
• 담당자가 자신의 거래를 스스로 승인하지 못하게 분리했는가
• 은행·세금계산서·물류 연결이 끊기면 어디서 재개하는가
• 기존 데이터를 옮긴 뒤 전후 잔액과 재고가 일치하는가

가격·권한·소유권과 상태에 영향을 주는 값은 화면에서 받은 값을 그대로 믿지 않고, 신뢰할 수 있는 데이터와 업무 규칙으로 다시 계산해야 합니다. 여러 단계의 승인과 거래는 서버에 명시적인 상태로 두고 순서·반복·동시 실행을 통제해야 합니다.[2]

AI는 이런 요구를 코드로 옮기는 속도를 높일 수 있습니다. 하지만 어떤 회계·재고 규칙이 맞는지, 오류가 났을 때 누가 책임지고 복구할지까지 정해 주지는 않습니다.

도메인 지식과 시스템 지식이 함께 필요합니다

업무를 잘 아는 사람이 직접 만들면 잘못된 요구 전달을 줄일 수 있습니다. 그러나 업무를 안다고 운영 시스템이 저절로 안전해지는 것은 아닙니다. 반대로 개발을 잘한다고 회사의 회계와 재고 규칙을 알 수 있는 것도 아닙니다.

ERP에는 두 종류의 지식이 함께 필요합니다.

바이브코딩은 두 지식을 코드로 연결하는 구현 도구입니다. 어느 한쪽의 지식을 대신하는 면허는 아닙니다.

그래서 개발자가 코드를 검토하는 것만으로도 충분하지 않습니다. 업무 책임자는 규칙과 결과를 승인하고, 개발·운영 담당자는 데이터 무결성·권한·복구를 확인해야 합니다. 상충하는 업무를 한 사람이 모두 실행하지 않도록 역할과 접근 권한도 나눠야 합니다.[3]

완성은 첫 사용 뒤부터 증명됩니다

바이브코딩 데모에서는 화면이 열리고 주요 기능이 동작하면 완성처럼 보입니다. 회사 시스템은 첫 사용 뒤에 새로운 요구가 드러납니다.

• 월말 마감 중 숫자가 맞지 않음
• 퇴사한 직원의 권한이 남아 있음
• 제품 코드가 바뀌어 과거 주문을 찾지 못함
• 거래처 엑셀 양식이 달라짐
• 외부 API 응답이 늦거나 중복으로 도착함
• 이미 승인된 거래의 수정 요청이 들어옴

이때 필요한 것은 프롬프트 한 번이 아닙니다. 테스트 데이터, 변경 기록, 백업, 복구 절차와 운영 담당자가 필요합니다. 코드를 만든 사람이 회사를 떠난 뒤에도 시스템을 고칠 수 있어야 합니다.

일주일 만에 만든 화면과 몇 년 동안 운영할 원장을 같은 완성으로 부르면 논쟁은 반복됩니다. 기간이 짧아서 문제가 아니라, 아직 시험하지 않은 책임 범위를 말하지 않은 것이 문제입니다.

세 단계로 부르면 이야기가 쉬워집니다

바이브코딩 결과물을 무조건 ERP라고 부르거나 장난감이라고 깎아내릴 필요는 없습니다. 무엇을 책임지는지에 따라 세 단계로 나눌 수 있습니다.

1. 업무 보조 도구

기존 ERP 데이터를 읽어 보고서를 만들거나, 주문서 초안을 정리하고, 반복 입력을 줄입니다. 오류가 나도 담당자가 원본과 비교해 고칠 수 있습니다.

바이브코딩으로 가장 먼저 시도하기 좋은 영역입니다. 읽기 전용 또는 초안 상태로 시작하면 실패 범위도 좁습니다.

2. ERP 주변 모듈

특정 부서의 견적, 승인, 현장 기록을 처리한 뒤 검증된 결과만 기존 ERP로 넘깁니다. 독립적인 사용자와 데이터를 가지지만 회계 원장이나 핵심 재고를 직접 소유하지는 않습니다.

이 단계부터 권한, 변경 기록, 중복 방지, 백업과 운영 책임자가 필요합니다. 연결 실패 시 어디서 재개할지도 정해야 합니다.

3. 핵심 ERP

회계, 인사·급여, 재고·원가와 회사의 공식 거래 기록을 직접 관리합니다. 여러 부서와 외부 시스템이 연결되고, 잘못된 값이 청구·납품·신고에 영향을 줍니다.

AI 코딩 도구를 써도 설계·검토·테스트, 데이터 이관과 장기 유지보수 조직이 필요합니다. 혼자 만들었다보다 누가 계속 책임질 것인가가 더 큰 질문입니다.

저는 ERP의 바깥쪽부터 시작합니다

처음부터 회계 원장이나 전체 재고를 교체하지 않습니다. 기존 ERP가 불편한 지점 가운데 실패를 발견하고 수기로 복구할 수 있는 업무부터 개선합니다.

예를 들어 이메일 주문서를 검토 대기 상태로 만들거나, 현장 기록을 표준 양식으로 모으거나, ERP 데이터를 읽어 담당자별 할 일을 보여주는 도구입니다. AI가 초안을 만들고 사람이 승인한 결과만 핵심 시스템에 넣으면 실패 범위를 줄일 수 있습니다.

다음 단계로 옮기기 전에는 아래 내용을 확인합니다.

• 책임질 부서와 데이터 범위가 한 문장으로 정해졌는가
• 중복·동시 수정·권한 오류를 시험했는가
• 변경 전후 숫자를 대조할 기준이 있는가
• 장애 시 마지막 정상 상태로 복구해 봤는가
• 만든 사람이 없어도 운영 담당자가 이어받을 수 있는가

이 기준을 통과한 범위만 ERP 안쪽으로 옮깁니다. 구현 속도가 빨라졌다는 이유로 실패의 영향까지 한 번에 넓힐 필요는 없습니다.

논쟁보다 범위를 설명하는 편이 낫습니다

바이브코딩으로 ERP를 만들었다는 문장 안에서는 분석, 업무 규칙, 권한, 데이터 이관, 검증과 유지보수 같은 보이지 않는 일이 생략됩니다. 그래서 듣는 사람마다 다른 완성도를 상상합니다.

바이브코딩으로 ERP를 만들 수 있습니다. 대신 어느 부서가 쓰고, 어떤 데이터를 책임지며, 오류가 나면 어디까지 영향을 주고, 누가 복구할지 함께 말해야 합니다.

그 답이 없다면 만든 것은 ERP처럼 보이는 첫 화면일 수 있습니다. 반대로 그 답을 정하고 검증한 사람이 AI로 구현 시간을 줄였다면, 그것은 충분히 의미 있는 변화입니다. 중요한 것은 도구의 이름이 아니라 책임 범위가 코드와 운영에 남아 있는가입니다.

출처

• [1] https://kr.linkedin.com/posts/jaykeelj_%EC%98%A4%EB%8A%98-%EC%8A%A4%EB%A0%88%EB%93%9C%EC%97%90%EC%84%9C-%EB%B0%94%EC%9D%B4%EB%B8%8C%EC%BD%94%EB%94%A9%EC%9C%BC%EB%A1%9C-erp-%EB%A7%8C%EB%93%A4%EC%97%88%EC%8A%B5%EB%8B%88%EB%8B%A4%EA%B0%80-%EC%9D%B4%EC%8A%88-%EC%9E%BC%EC%9E%88%EB%84%A4%EC%9A%94-activity-7483023314991407104-KDNB — LinkedIn, 이재상 님 공개 글(2026년 8월 16일 확인)
• [2] https://cheatsheetseries.owasp.org/cheatsheets/Business_Logic_Security_Cheat_Sheet.html — OWASP, Business Logic Security Cheat Sheet(2026년 8월 16일 확인)
• [3] https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final — NIST, SP 800-53 Rev. 5.1, AC-5 Separation of Duties(2026년 8월 16일 확인)