생산·납품·세금계산서까지? 얽히고 섥힌 데이터들 사이, MES 서비스 프론트엔드 개발기
안녕하세요, 컨시언스파트너스 프론트엔드 개발자 June입니다.😊
제가 참여했던 FactoryX 프로젝트를 소개하고, 진행하며 마주했던 고민들을 나눠보려고 해요.
FactoryX 소개
FactoryX는 제조 현장의 생산, 납품, 재고, 설비 등을 통합 관리하는 프로젝트 중심의 MES(Manufacturing Execution System)예요.
1. 프로젝트 중심의 통합 관리
견적서부터 생산, 납품, 세무/회계까지 전체 제조 프로세스를 프로젝트 단위로 체계적으로 관리해요. 라인별 생산을 넘어서 프로젝트 기반으로 생산 계획을 수립하고 실행을 관리할 수 있어요.
2. 자동화된 데이터 처리
수동 입력을 줄여 생산성을 높여요.
• OCR로 견적서·주문서 등 문서의 데이터를 자동 입력
• 거래처 및 설비 정보의 체계적 자동 관리
• 반복 입력 작업의 최소화
3. 이력 추적 시스템
자재 입고부터 제품 출고까지 전 과정을 투명하게 추적해요. 프로젝트별 작업 로그로 이슈를 관리할 수 있어요.
개발 관점에서 본 FactoryX의 특징
상태 관리의 중요성
제조 현장 데이터는 서로 얽혀 수시로 변해요. 복잡하고 방대한 상태를 효율적으로 관리하고, 역할별로 명확히 분리하는 전략이 필요했어요.
연쇄적인 데이터 흐름
예를 들어 견적서의 주문 품목은 생산 계획과 납품, 세금계산서까지 이어지고, 생산 계획은 설비·원자재 재고에 영향을 줘요. 한 지점의 수정이 여러 화면과 로직에 파급되기 때문에 흐름과 영향 범위를 깊이 이해하고 예측해야 했어요.
정보 밀도가 높은 화면 구성
한 화면에 의사결정에 필요한 정보를 밀도 있게 보여줘야 했어요. 공통 컴포넌트를 여러 화면에서 재사용하므로, 정교한 컴포넌트 설계와 데이터 재사용 방안이 선행돼야 일관된 UX를 제공할 수 있었어요.
실시간 데이터 동기화
현장의 변화를 지연 없이 반영하려고 WebSocket 기반 실시간 업데이트를 적용했어요. 단순 API 폴링만으로는 충족하기 어려운 요구를 즉시 UI에 반영하는 것이 핵심이었어요.
시행착오
1. 낯선 도메인
초기엔 제조 도메인 자체가 낯설었어요. 용어만 모르는 수준이 아니라, 각 용어가 갖는 비즈니스 로직과 현업 맥락을 이해하기가 쉽지 않았어요.
예를 들어 세금계산서는 단순 회계 장표가 아니라 견적·주문·납품과 연결되는 자금 흐름의 매개였고, 생산 지시서는 프로젝트별 오늘의 생산 계획을 한눈에 보고 배분하는 핵심 도구였어요.
처음엔 맥락 이해 없이 개발을 시작해 구현 단계에서 의문이 계속 생기며 속도가 느려졌어요. 이후 기획 문서와 유사 서비스 사례를 탐색하고, 기획자와 긴밀히 소통하면서 핵심 프로세스를 잡아갔고, 도메인 이해가 프로젝트 전체 이해로 확장되며 많은 물음에 답을 찾을 수 있었어요.
2. 백엔드와 데이터 스펙 조율
복잡한 로직 때문에 프론트엔드·백엔드 협업이 필수였어요. 단순 API 연동을 넘어 시스템 동작 방식 자체를 함께 논의해야 했죠.
현장 특성상 ‘분할 생산’ 같은 예외가 발생했어요. 특정 품목의 생산 계획을 나누고, 수정된 계획을 동적으로 추가해야 했죠.
그래서
생산 계획 추가를 어디서 처리할지(프론트/백엔드 경계),
변경·추가된 계획을 어떻게 전달하고 결과를 UI에 어떻게 반영할지,
분할된 계획의 버퍼율을 어떻게 적용·저장할지 등을 합의하고 스펙을 다듬었어요.
3. 다양한 예외 케이스에 따른 복잡도
데이터·기능 간 연결이 촘촘해 예외 케이스에 따라 UI와 처리 구조를 자주 바꿔야 했어요.
세금계산서 발행·연동
초기엔 견적서 기반 발행만 고려했지만, 실제 환경에선 견적 품목과 무관하게 발행하거나 프로젝트 시작 전 선발행이 필요했어요. 그래서 프로젝트와 무관하게도 발행 가능하지만, 이후 프로젝트에 연결할 수 있는 유연한 방식으로 바꿨어요. 불러온 품목은 사용자가 수정할 수 있어야 했고, 선발행 건을 표시하고 추후 연결하는 흐름도 추가했어요.
반품 처리
초기에 반품이 들어오면 반품 수량만큼 생산 수량이 자동 생성되도록 했는데, 재고가 존재하면 재고로 반품 처리해야 했어요. 사용자에게 해당 품목 재고를 보여주고, 반품 수량·일자 등 정보를 직접 입력·수정하도록 변경했어요.
다양한 예외를 예측·정의해 UI/UX와 데이터 흐름에 반영하는 과정에서 시야가 넓어졌고, 복잡도를 다루는 역량을 키울 수 있었어요.
마무리
FactoryX를 진행하며 많은 시행착오를 겪었지만 그만큼 크게 배웠어요.
개발자는 도메인 지식을 갖추고, 기획 단계부터 업무 프로세스를 온전히 이해하려는 태도가 필요하다고 절감했어요.
예외 케이스와 스펙 조율을 거치며 데이터 처리 방식 전반에 대한 실질적 이해를 쌓을 수 있었어요.
혼자가 아니라 함께 고민하는 협업의 가치를 확인했어요. 의견을 나누고 최선의 방안을 찾는 과정이 문제 해결 효율을 높이고 팀워크를 단단하게 해줬어요.
앞으로도 마주할 도전 속에서 사용자에게 실질적 가치를 주는 개발자로 꾸준히 성장해 나가려고 해요. 🌱