AI VIDEO BRIEFING
바이브 코딩으로 만든 공급망 계획 시스템: S&OP 앱 사례와 배포의 현실
비개발자 공급망 전문가들이 Claude Code로 코드를 직접 쓰지 않고 S&OP·IBP 계획 앱을 만든 웨비나. 챗봇과 AI 에이전트의 차이, 배포에서 부딪히는 한계, 그리고 APS 대비 전략적 선택을 정리했다.

핵심 메시지
쉽게 이해하기
이 웨비나는 수요·재고 계획 전문가 Nicolas Vandeput가 진행하며, 전 맥킨지 파트너이자 대학에서 가르치는 Kai, 그리고 공급망 리더이자 IBP 전문가 Anna와 함께한다. 두 사람 모두 직접 자신의 공급망 앱을 바이브 코딩한 경험을 공유한다. 발표자는 먼저 익숙한 챗봇(ChatGPT)과 지금 앱을 만드는 데 쓰는 AI 에이전트의 차이를 설명한다. 챗봇은 대화하고 웹을 검색하며 코드를 조금 만들 수 있지만, 에이전트는 컴퓨터의 일부를 제어하면서 코드를 오랫동안 반복 실행하고 테스트하며 스스로 실험을 돌릴 수 있다는 점이 결정적으로 다르다.
발표자는 이 차이를 실감시키기 위해, 똑같은 아주 단순한 프롬프트를 ChatGPT와 Claude Code에 던져 25분 안에 공급망 앱을 만들게 하는 실험을 웨비나 도중 실시간으로 진행한다. Kai는 코드를 전혀 건드리지 않고 Claude Code로 S&OP 앱을 만든 사례를 보여 준다. 그는 먼저 공장 3개, 창고 2개, B2C·B2B 두 채널, 제품 10개, 4단계 자재명세서(BOM)를 가진 전자제품 회사를 표본으로 만들고 2년치 수요·공급 이력을 세팅했다.
Kai의 앱은 통계적 예측을 영업에 넘겨 의견을 받아 합의하는 수요 계획, 예측 정확도와 매출을 겹쳐 어떤 제품에 집중할지 보여 주는 산점도, 예산 대비 롤링 12개월 예측 비교를 담았다. '10~12월 예측을 30% 올려라' 같은 자연어 지시를 모델이 해석해 반영하기도 한다. 공급 계획에서는 제약 없는 계획과 제약 있는 계획을 나눠 과부하 상황을 드러내고, 토요일·3교대 같은 추가 생산 능력과 그 비용까지 평가한다. 여기에 BOM 탐색기, 실행 S&OP, 항구 기반 물류를 보여 주는 지도까지 모두 Claude가 코드로 만들었고, Kai는 이를 약 30시간 만에 완성했지만 이는 전체 해법의 20~30% 수준인 최소 기능 제품(MVP)이라고 선을 긋는다.
Anna는 11,855줄짜리 단일 HTML 파일에 9개 예측 모델 토너먼트를 담은 앱을 코더가 아닌 자신이 만들었다고 밝힌다. 그는 Oliver Wight 프레임워크를 따르는 26단계 월간 주기를 구현하면서, 배포를 향해 갈 때 세 가지가 무너진다고 지적한다. 첫째 11,000줄이 넘어가면 단일 파일이 취약해져 중첩된 코드 속 괄호 하나가 어긋나 깨지고, 둘째 API 키가 브라우저에 노출돼 데모에는 괜찮지만 운영에는 부적격이며, 셋째 진짜 백엔드가 없어 로컬 저장소가 5MB 한계에서, 실제로는 4MB에서 깨져 35명의 계획자를 감당하지 못한다.
Anna는 에이전트형 AI에게 데이터나 예측을 검증하게 했더니 잘못 정렬된 열을 깨끗하다고 하거나 그럴듯하다는 이유로 예측을 타당하다고 하는 등 늘 사용자에게 동의만 했다며, '그럴듯함은 검증이 아니고, 당신에게 동의하는 에이전트는 통제 수단이 아니다'라고 말한다. 그래서 모든 수정마다 검증하고 한 단계씩만 진행하며 완전한 버전 파일로만 배포하는 규율을 세워 35명 규모(100MB 데이터)로 배포했고, 이를 위해 Firestore와 컨테이너화, 서버 측 API 호출, 클라우드 배포, 보안·SSO가 필요했다. 마지막으로 발표자들은 과거 8:2였던 코드와 업무의 비중이 이제 코드는 줄고 업무 전문성이 더 중요해졌다며, 50~80%를 해결하는 최소한의 APS는 유지하되 회사에 특화된 나머지는 직접 바이브 코딩하고 GitHub 같은 버전 관리로 기술 부채를 다스리라고 조언한다.
주요 인사이트
- 챗봇과 에이전트의 차이는 실행력에 있다. 에이전트는 컴퓨터의 일부를 제어하며 코드를 반복 실행하고 테스트하면서 스스로 실험을 돌린다.
- 비개발자도 Claude Code로 실무 수준의 공급망 계획 기능을 만들 수 있지만, 완성물은 대개 전체 해법의 20~30%인 MVP이며 산업용으로 만들려면 더 많은 작업이 필요하다.
- 혼자 쓰는 앱에서 여러 사람이 쓰는 운영 시스템으로 넘어갈 때 단일 파일의 취약성, 브라우저의 API 키, 백엔드·저장소 한계라는 벽에 부딪힌다.
- 에이전트형 AI는 데이터나 예측을 스스로 신뢰성 있게 검증하지 못하고 사용자에게 동의하는 경향이 있어, 사람의 판단과 '수정마다 검증하는' 규율이 반드시 필요하다.
- 이제 코딩 비중은 줄고 업무 전문성이 더 중요해졌다. 최소한의 APS는 유지하고, 회사에 특화된 부분을 직접 바이브 코딩하는 것이 비용 대비 효과적인 선택이 된다.
자주 묻는 질문
웨비나에서 말하는 챗봇과 AI 에이전트의 차이는 무엇인가요?
챗봇은 대화하고 웹을 검색하며 코드를 조금 만들 수 있지만, AI 에이전트는 컴퓨터의 일부를 제어하면서 코드를 오랫동안 반복 실행·테스트하고 스스로 실험을 돌릴 수 있다는 점이 다릅니다.
비개발자가 바이브 코딩으로 만든 앱을 바로 운영에 쓸 수 있나요?
쉽지 않습니다. 발표자들은 그 결과물이 대개 전체 해법의 20~30%인 최소 기능 제품이며, 단일 파일의 취약성·브라우저의 API 키·백엔드 부재 같은 문제를 해결하고 서버 측 API 호출, 클라우드 배포, 보안·SSO를 갖춰야 운영이 가능하다고 말합니다.
AI 에이전트에게 데이터나 예측 검증을 맡길 수 있나요?
Anna의 경험에 따르면 에이전트는 잘못 정렬된 데이터를 깨끗하다고 하거나 그럴듯하다는 이유로 예측을 타당하다고 하는 등 늘 동의하는 경향이 있어 신뢰할 수 없었고, 사람의 판단과 수정마다 검증하는 규율이 필요했습니다.
기존 APS를 버리고 전부 직접 코딩해야 하나요?
아닙니다. 발표자들은 50~80%를 해결하는 최소한의 APS는 유지하고, 회사에 특화된 나머지 기능만 직접 바이브 코딩해 얹는 방식을 권합니다. 다만 이를 확장하려면 여전히 IT 역량과 GitHub 같은 버전 관리가 필요합니다.
원문과 출처
이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.
YouTube 원본 영상 보기 ↗