Tech 2025. 07. 21
의류 공장에 데이터는 넘치고, 시간은 없다
“베트남 공장의 생산현황 실시간 데이터를 한국 본사에서 바로 본다고요?”
이 이야기를 들으면 대부분은 반신반의해.
거리는 수천 km, 장비는 수천 대, 데이터는 매 분마다 쏟아지는데… 정말 가능할까?
우리는 베트남의 대형 봉제 공장에 설치된 수천 대의 IoT 디바이스(모노로그)가
생산 현황, 상태, 오류 정보 등을 무선으로 전송하고,
그 정보가 AWS 기반 웹사이트를 통해
한국 본사에서 거의 실시간으로 확인되도록 만들었지.
이건 단순히 장비 하나 붙이는 문제가 아니라,
현장 네트워크 설계부터 클라우드 인프라, API 응답, UX 최적화까지 전방위적인 설계의 결과야.
스마트 봉제를 위한 전체 시스템 지도
우리가 구축한 데이터 흐름은 다음과 같아
이 데이터 흐름은 다음과 같은 특징들을 가져.
- IoT Core나 MQTT 없이, SQS를 이용한 유연한 큐 기반 아키텍처
- ECS에서 직접 데이터를 소비하고, DocumentDB에 저장
- 클라이언트는 React 앱을 통해 실시간에 가깝게 정보를 요청
- 모든 IoT 디바이스는 무선(Wi-Fi) 기반
봉제 공장 IoT : IoT 디바이스와 봉제 라인의 연결법
공장마다 수천 대의 모노로그 디바이스가 Wi-Fi를 통해 네트워크에 연결되어 있어.
이 장비들은 1~2분 주기로 센서 데이터를 송신해.
이 데이터들의 특징은 다음과 같아.
- 작동 여부, 생산량, 온도, 오류 코드 등 다양한 데이터
- 용량은 작지만 빈도가 높고, 동시 송신 수가 많음
로컬 게이트웨이: 봉제 데이터를 지키는 중간 관리자
모든 데이터는 직접 클라우드로 가지 않고,
공장 내 설치된 로컬 게이트웨이 서버로 먼저 모여.
이 서버는 단순한 리피터가 아니라,
- 데이터를 사전 정제하고,
- 중복데이터를 제거하며,
- SQS에 배치 단위로 전송해.
각 공장에는 최소 2대 이상의 로컬 게이트웨이를 두어 HA 구성도 갖췄어.
SQS-ECS 구조로 봉제 데이터 폭주에도 흔들림 없이
로컬 게이트웨이가 보낸 데이터는 AWS SQS로 들어가.
여기서부터 클라우드에서의 처리가 시작돼.
왜 우리는 SQS를 택했는가
- 데이터량이 몰려도 큐잉으로 안전하게 흡수 가능
- 실패 메시지는 DLQ(Dead Letter Queue)로 전송
- 메시지 순서, 중복 처리도 유연하게 가능
그리고 이 큐를 처리하는 주체는 ECS 클러스터에서 실행 중인 NestJS 컨테이너 앱이야.
ECS 컨테이너: 의류 데이터를 클라우드로 옮기는 일꾼
- SQS에서 메시지 배치 단위로 수신
- JSON 파싱 및 데이터 정규화
- DocumentDB(MongoDB 호환)에 raw data 저장
- 원시 데이터는 S3에 장기 보관
ECS 컨테이너 수는 SQS 큐 길이에 따라 자동 확장되지.
데이터 폭주가 오더라도 ECS가 알아서 버텨준다는 말이야.
DocumentDB: 실시간 봉제 데이터 분석의 허브
우리는 처음엔 단순 관계형 DB 내지는 AWS의 DynamoDB를 고려했지만,
IoT 데이터 특성상 다양한 필드 구조와 복합 조건 검색이 필요해
MongoDB 호환인 AWS DocumentDB를 선택했어.
AWS Document DB가 가진 장점들을 통해서
“A공장의 3라인에서 최근 1시간 동안 3회 이상 오류가 발생한 장비 목록” 같은 쿼리를
Document DB에선 한 줄로 끝낼 수 있어.
이번 편에서는 기본적인 데이터의 흐름 위주로 살펴보았어.
다음 편에서는 실제로 웹에서 보이도록 구현하는 방법에 대해서 설명하도록 할게.
데이터를 시각화해서 보여주는 방법이 궁금하다면 ?
🔽 관련 글 보기
