섬유 공장에 API를 붙이면: 제조를 클라우드처럼 쓰는 구상

서버가 필요할 때 더 이상 장비를 사서 랙에 꽂지 않는다. 필요한 사양을 API로 요청하고, 쓴 만큼 낸다. 그 뒤에서 어떤 하드웨어가 어느 데이터센터에서 돌아가는지는 몰라도 된다.

원단을 만드는 일도 이렇게 될 수 있을까. 이 글은 그 질문에서 시작한 창업 아이디어 Textile Manufacturing as a Service(이하 TMaaS)를 정리한 것이다. 대구의 섬유 제조 역량 위에 소프트웨어 레이어를 올려, 누구나 원단을 서비스처럼 주문할 수 있게 만드는 구상이다.

먼저 조건을 밝혀 둔다. 이 글은 구현 기록이 아니라 설계 단계의 구상이다. 쓰는 사람은 섬유 업계 경력이 없는 백엔드 개발자이고, 아직 제조기업 인터뷰나 MVP(최소 기능 제품)를 진행하기 전이다. 아래의 문제 정의는 앞으로 현장에서 검증해야 할 가설이다.

왜 대구 섬유인가

대구에는 원사, 제직, 염색, 가공까지 섬유 제조의 각 단계를 오래 해 온 기업과 전문기관이 모여 있다. 새 공장을 지을 필요가 없을 만큼 제조 역량은 이미 있다.

그런데 이 역량을 바깥에서 쓰기는 어렵다. 작은 패션 브랜드나 신규 창업자가 원단을 새로 만들려고 하면 다음 질문에 먼저 답해야 한다.

• 어떤 업체가 어떤 원단과 공정을 잘하는가
• 내가 원하는 감촉과 기능을 만들려면 어떤 소재, 조직, 가공이 필요한가
• 최소주문수량, 견적 방식, 납기, 품질 기준은 업체마다 어떻게 다른가

반대 방향의 장벽도 있다. 지역 제조기업은 기술과 경험이 있어도 새 고객을 찾고, 온라인으로 영업하고, 자기 생산 역량을 데이터로 보여 주는 데 익숙하지 않다.

양쪽을 놓고 보면 문제는 제조 능력이 아니다. 수요와 제조 능력을 잇는 디지털 인터페이스가 없다는 것이 핵심이다.

기존 도구가 풀지 못하는 부분

섬유 쪽에도 소프트웨어는 이미 있다. 다만 각자 다른 문제를 푼다.

도구	잘하는 것	원단을 새로 만들려는 고객에게 남는 일
섬유 B2B 플랫폼	원단과 제조업체 정보 제공, 구매자와 공급자 연결	소재와 공정 판단, 업체별 견적·샘플·납기 조율
ERP / MES (전사 자원 관리 / 제조 실행 시스템)	개별 제조기업 내부의 생산관리와 업무 효율화	기업 바깥의 고객 요청을 받는 창구가 없음

B2B 플랫폼은 “누가 무엇을 파는지”를 보여 준다. 하지만 그 정보를 보고 어떤 소재와 공정을 고를지 판단하고, 여러 업체와 따로 조율하는 일은 여전히 고객 몫이다. 섬유 제조 경험이 적은 소규모 브랜드나 디자이너에게는 이 과정 자체가 진입장벽이다.

결국 지금 구조에서는 섬유 제조를 잘 아는 사람만 원단을 만들 수 있다. TMaaS가 바꾸려는 것은 이 구조다.

무엇을 숨기고 무엇을 열 것인가

클라우드가 한 일을 다시 보면, 핵심은 추상화의 경계를 어디에 긋느냐였다. 사용자는 vCPU, 메모리, 리전처럼 원하는 결과의 언어로 요청하고, 서버 조달과 배치는 경계 뒤에 숨는다.

TMaaS도 같은 방식으로 경계를 긋는다.

• 인터페이스로 여는 것: 용도, 원하는 감촉과 기능, 수량, 목표 단가, 납기
• 경계 뒤에 숨기는 것: 소재·조직·중량·가공 사양 결정, 공정 구성, 제조기업 탐색과 매칭, 샘플 제작, 생산 일정, 품질관리

고객은 “가볍고 구김이 적은 여름용 셔츠 원단 3,000m가 필요하다”처럼 결과와 조건으로 말한다. 서비스는 이 요청을 받아 세 가지를 한다. 먼저 요청을 제조 사양으로 구체화한다. 다음으로 그 사양에 필요한 공정을 구성한다. 마지막으로 공정마다 맞는 제조기업을 연결하고, 견적부터 품질관리까지 하나의 흐름으로 진행한다.

flowchart LR
    A["고객 요청<br/>용도·기능·수량·단가·납기"] --> B["표준 제조요청서"]
    B --> C["원단 사양<br/>소재·조직·중량·가공"]
    C --> D["공정 구성<br/>원사 → 제직 → 염색 → 가공"]
    D --> E["공정별 제조기업 매칭"]
    E --> F["견적 · 샘플"]
    F --> G["생산 · 품질관리"]

단순 중개와 다른 점은 고객이 업체를 고르는 것이 아니라 결과를 요청한다는 데 있다. 제조기업을 소개하는 서비스가 아니라, 고객이 직접 수행해야 했던 제조 과정을 하나의 서비스로 감싸는 것이다.

Fabric Compiler: 요구사항을 제조 사양으로 바꾸는 엔진

장기적으로 위 흐름의 앞부분을 소프트웨어로 만들고 싶다. 이름을 Fabric Compiler로 붙였다. 컴파일러가 사람이 쓴 코드를 기계가 실행할 수 있는 형태로 바꾸듯, 고객의 요구사항을 제조 현장이 실행할 수 있는 원단 사양과 공정으로 바꾸는 역할이다.

컴파일러의 단계에 대응시켜 보면 이렇다.

컴파일러 단계	Fabric Compiler에서 하는 일
파싱	“가볍다”, “구김이 적다”, “여름용” 같은 자연어 요구를 구조화된 조건으로 해석
중간 표현	소재, 조직, 중량, 가공, 품질 조건으로 이루어진 표준 원단 사양
최적화	같은 조건을 만족하는 여러 제조 방식의 예상 원가, 납기, 최소주문수량, 품질 위험 비교
코드 생성	선택한 방식을 공정 순서와 공정별 제조기업 배정으로 변환

최적화 단계가 이 구상의 핵심이다. 실제 생산 데이터가 쌓이면 고객은 가장 싼 업체를 찾는 대신 자기 조건에 맞는 생산 방식을 고를 수 있다. 불필요한 공정, 반복 샘플링, 과도한 최소주문수량, 불량과 재작업 같은 비효율도 데이터로 드러난다.

이 부분은 지금 가장 불확실하다. 비교할 대안을 만들려면 소재, 공정, 원가, 납기 사이의 관계를 담은 데이터가 먼저 있어야 하는데, 그 데이터는 실제 거래에서만 나온다. 그래서 Fabric Compiler는 처음부터 만들지 않는다. 이 순서는 마지막 절에서 다룬다.

수익모델: 제조사의 마진을 깎지 않는 구조

중개 플랫폼은 흔히 공급자를 가격 경쟁에 세우면서 성장한다. 지역 제조기업과 오래 협력하려면 그 방식은 맞지 않다고 봤다. 그래서 수익모델을 세 단계로 잡았다.

1. Managed Manufacturing Service: 초기 핵심 매출이다. 고객의 주문을 받아 제조기업과 공정을 구성하고, 견적·샘플·생산 일정·품질관리까지 통합해 제공한다. 고객은 여러 업체와 따로 계약하지 않고 주문 하나로 생산을 진행한다.
2. Manufacturing Cost Optimization: 거래가 반복되면 어떤 원단을 어떤 소재·공정·제조사 조합으로 만들었고 원가·납기·품질이 어땠는지가 쌓인다. 이를 바탕으로 반복 생산하는 브랜드에 품목별 원가 분석과 절감 가능 영역을 제안하는 기업용 구독을 만든다.
3. API: Fabric Compiler와 제조 네트워크를 API로 연다. 그러면 패션 플랫폼이나 브랜드가 자기 시스템 안에서 제조 가능성, 예상 견적과 납기를 확인하고 생산을 요청할 수 있다. 과금은 기업 계약이나 사용량 기준으로 한다.

제조기업에게는 높은 가입비나 이용료를 먼저 받지 않는다. 대신 각 기업의 설비와 전문 공정에 맞는 주문을 연결해 영업 비용을 줄이고 가동률을 높이는 것을 핵심 가치로 둔다. 플랫폼의 매출이 지역 제조기업의 신규 주문과 함께 늘어나는 구조를 지향한다.

수수료율이나 구독 가격은 아직 정하지 않았다. 고객이 실제로 어떤 비용을 아끼는지를 확인한 뒤에 정할 문제다.

플랫폼을 먼저 만들지 않는 이유

개발자가 이런 구상을 하면 매칭 엔진, 제조사 데이터 모델, 견적 자동화부터 설계하고 싶어진다. 그렇게 하지 않기로 했다. 실제 주문이 없는 상태에서 만든 추상화는 현장의 예외를 하나도 모르는 추상화이기 때문이다.

순서는 이렇게 잡았다.

1. 현장 인터뷰로 첫 시장 정의: 대구의 원단·제직·염색·가공 기업을 만나 실제 주문이 어떻게 흘러가는지 듣는다. 견적 방식, 최소주문수량, 납기, 품질 기준, 공정별 애로사항이 대상이다. 동시에 소규모 패션 브랜드와 디자이너가 원단 소싱에서 가장 불편해하는 점을 확인한다. 처음부터 모든 섬유를 다루지는 않는다. 소재와 공정을 좁히고, 그 안에서 반복되는 문제부터 찾는다.
2. 사람이 운영하는 MVP: 고객이 용도, 기능, 수량, 목표 단가, 납기를 입력하면 표준 제조요청서가 만들어지고, 운영자가 직접 제조 파트너를 연결해 견적과 샘플을 진행한다. 실제 거래에서 반복되는 판단과 규칙부터 소프트웨어로 옮긴다.
3. 데이터 기반 Fabric Compiler: 쌓인 주문 데이터로 제조 가능성 검토, 공정 추천, 예상 견적을 점차 자동화한다. 제조기업별 설비, 강점 공정, 최소주문수량, 생산능력을 구조화해 Manufacturing Network를 만든다.
4. 고객 확대와 API: 국내 패션 브랜드와 제조 스타트업으로 넓히고, 이후 해외 브랜드와 플랫폼이 API로 직접 생산을 요청하게 한다.

이 순서에서 지키고 싶은 원칙이 하나 있다. 지역 기업의 데이터를 가져오기만 하는 플랫폼이 되지 않는 것이다. 데이터를 받는 만큼 신규 주문과 디지털 업무 도구를 기업에 돌려줘야 협력이 이어진다.

아직 답하지 못한 질문

구상을 정리하면서 오히려 모르는 것이 분명해졌다.

• 어떤 고객군과 어떤 소재·공정에서 소싱의 불편이 가장 크고, 돈을 낼 이유가 가장 강한가
• 제조기업이 이 플랫폼을 중개자가 아니라 파트너로 받아들이려면 수수료, 데이터 활용, 품질 책임, 클레임 처리를 어떻게 설계해야 하는가
• 여러 제조사를 묶어 하나의 주문으로 제공할 때 계약, 정산, 품질 보증, 납기 지연의 책임은 어디까지 지는가
• Fabric Compiler는 실제 거래가 몇 건쯤 쌓였을 때부터 제품화할 가치가 있는가

소프트웨어는 배포를 되돌릴 수 있다. 제조는 실제 원단과 공급망이 움직이므로 그렇게 되돌릴 수 없다. 그래서 이 질문들은 코드보다 현장에서 먼저 답을 찾아야 한다. 이 구상의 최종 목표는 Textile Manufacturing Cloud다. 새 공장을 만드는 대신 이미 있는 대구의 제조 역량 위에 소프트웨어 레이어를 올린다. 그래서 여러 제조기업이 각자의 전문성을 유지하면서 하나의 가상 공장처럼 연결되게 하는 것이다.

이 아이디어로 정부 창업 지원 프로그램에 지원한 과정은 다음 글에 정리했다.