전송이 끊기는 건 정상이다 — 엣지 버퍼링과 재전송 설계의 실제 패턴 (현장 데이터 파이프라인 EP.2)

현장 데이터 파이프라인 EP.2 — 시리즈 이어서 읽기. 1편에서는 데이터가 '나오는 것'과 '쓸 수 있는 것' 사이의 4가지 막힘(수집·전송·저장·활용)을 정리했습니다. 오늘은 2편으로, 4가지 중 현장에서 제일 자주 깨지는 전송 구간을 깊게 팝니다. 끊김을 '장애'가 아니라 '전제'로 설계하는 법입니다.

 

현장 7년차로 말씀드리면, 이 문장으로 망가진 설계가 가장 많습니다. "MES로 MQTT 보내면 끝이죠?"

 

그렇게 만든 시스템은 시운전 때 잘 돌아갑니다. 그런데 주말 야간에 무선 AP가 한 번 재부팅되거나, 방화벽 정책이 바뀌거나, 라인 재배치로 VLAN이 분리되면, 그날의 데이터는 그대로 허공에 증발합니다. 월요일 아침에 대시보드를 열면 밤 11시부터 아침 6시까지가 통째로 비어 있는 겁니다. 현장에서 전송이 끊기는 건 예외가 아니라 일상입니다.

 

끊김을 가정한 설계의 세 가지 원칙

 

1) 엣지에서 먼저 쌓아라 — "보내고 지우는" 순서 금지

 

데이터를 클라우드·MES로 보낸 뒤 로컬에서 지우는 설계는 한 번의 전송 실패에 무조건 데이터가 깨집니다. 반대로 합니다. 엣지(게이트웨이 PC, 산업용 미니 PC)에 먼저 쓰고, 전송이 확인된 것만 나중에 정리하는 겁니다.

 

현장에서는 보통 SQLite 같은 로컬 파일 DB나, 용량이 작으면 순환 링 버퍼(circular buffer)를 씁니다. "보낼 때까지 지우지 않는다" — 이 한 줄이 전송 구간의 첫 번째 생명선입니다.

 

2) 재전송은 '언제' '얼마나'가 문제 — 단순 무한 재시도가 답이 아니다

 

연결이 끊겼다고 매번 즉시 재시도하면, 네트워크가 살아나는 순간 수천 건이 한꺼번에 몰려 다시 죽습니다. 현장에서 쓰는 실전 패턴은 이렇습니다.

 

백오프(지수적 대기): 첫 재시도는 5초, 다음은 10초, 20초… 이렇게 늘려가며 서버·네트워크에 숨 쉴 틈을 줍니다.

 

배치 전송: 건별 전송이 아니라 100~1,000건을 묶어서 보내면 오버헤드가 확 줄어듭니다.

 

우선순위 분리: 알람·이상 신호는 실시간 큐로, 주기 계측 데이터는 지연 허용 큐로. 끊김이 길어질 땐 중요한 것부터 살아돌아옵니다.

 

3) 끊김 자체를 '관측'하라 — 전송률 모니터링이 곧 품질 지표

 

재전송이 조용히 잘 돌아간다고 끝이 아닙니다. 전송 구간의 건강을 보는 세 지표를 둡니다: ① 전송 성공률 (보낸 대비 서버 도착), ② 재전송 건수, ③ 최대 지연 시간(끊김 후 복구까지 가장 오래 걸린 시간). 이 셋을 대시보드 한 줄에 얹어두면, "어제 밤 라인이 끊겼다"는 사실을 다음날 아침에, 숫자로, 정확히 알 수 있습니다. 관측 없는 복구는 운이고, 관측 있는 복구는 운영입니다.

 

2편의 결론 — 네트워크를 믿지 말고, 버퍼를 믿어라

 

정리하면 이렇습니다. 엣지에서 먼저 쌓고(원칙 1), 똑똑하게 재전송하고(원칙 2), 끊김을 관측으로 붙잡는 것(원칙 3). 현장 네트워크가 100% 안정적인 공장은 제가 본 적이 없습니다. 그러니 설계의 전제는 단 하나 — "어느 날 밤은 끊긴다."

 

그래서 뭘 하면 되나 — 자사 엣지 게이트웨이에서 전송 실패 시 데이터를 로컬에 보관하는지, 보관한다면 최대 며칠치인지, 오늘 바로 확인해 보세요. 보관 자체가 없으면, 그 라인의 데이터는 네트워크 상태에 완전히 맡겨져 있는 겁니다.

 

다음 편(3편)은 저장 구간의 심화 — 타임스탬프·설비 ID·단위 통일의 '스키마 계약' 만들기를 다룹니다.