네트워크가 끊긴 동안, 현장 단말은 무엇을 하고 있었나?

현장 단말을 고를 때 대부분 화면 구성과 스캔 속도를 봅니다. 시연도 통신이 정상인 상태에서 진행됩니다. 그런데 실제로 나중에 문제가 되는 것은 통신이 정상일 때의 동작이 아니라 끊겼을 때의 동작이고, 이 부분은 제안서에도 잘 적히지 않습니다.

앞서 공장에서 와이파이가 자꾸 끊기는 진짜 이유의 마지막에서, 끊길 것을 전제로 설계하라는 이야기를 한 줄로 짚고 넘어갔습니다. 이 글은 그 한 줄을 펼칩니다. 네트워크가 끊긴 몇 분 혹은 몇 시간 동안 단말이 무엇을 하는지, 그리고 도입 전에 무엇을 확인해두면 나중에 곤란해지지 않는지를 정리합니다.  단말 자체를 고르는 기준은 현장 입력 단말, 무엇으로 고를까?에서 다뤘습니다.

무엇이 죽는지부터 나눈다

"통신이 끊기면 어떻게 되나요"라고 한 번에 물으면 "저장됩니다"라는 한 문장이 돌아옵니다. 이 답으로는 아무것도 확인되지 않습니다. 단말이 하는 일을 넷으로 쪼개서 물어야 답이 달라집니다.

• 입력 받기: 작업자가 화면에 값을 넣는 동작. 대개 끊겨도 살아 있습니다.
• 전송: 서버로 올려보내는 동작. 가장 먼저 죽습니다.
• 보관: 보낼 때까지 데이터를 쥐고 있는 동작. 여기가 갈립니다.
• 검증: 품번이 맞는지, 이 공정에 투입 가능한지 확인하는 동작. 서버 조회에 의존하면 같이 죽습니다.

끊김은 이 넷을 한꺼번에 죽이지 않습니다. 어떤 조합으로 죽느냐에 따라 증상이 완전히 달라지고, 대응 방법도 달라집니다.

넷을 나눠서 물어야 공급사의 답이 달라진다

저장됐다는 표시를 믿을 수 없다

증상. 작업자는 저장 버튼을 눌렀고 화면에 완료 표시도 떴는데, 사무실에서 조회하면 그 실적이 없습니다. 작업자에게 물으면 분명히 입력했다고 하고, 실제로 입력한 것이 맞습니다.

왜 구조적인가. 많은 단말이 "단말에 저장됨"과 "서버에 도착함"을 같은 문구로 표시합니다. 개발 과정에서 두 상태를 하나로 묶는 편이 화면이 단순해지기 때문입니다. 평소에는 두 상태가 거의 동시에 일어나므로 구분할 이유가 없어 보입니다. 문제는 끊겼을 때만 드러납니다.

무엇을 확인하면 막는가. 두 상태를 화면에서 구분해 보여주는지, 아직 전송되지 않은 건수가 작업자 화면에 상시 보이는지, 작업자가 자기 미전송 목록을 직접 열어볼 수 있는지를 봅니다. 화면 설계 문제처럼 보이지만, 실제로는 현장이 데이터를 믿을 수 있느냐의 출발점입니다.

중복은 양쪽에서 생긴다

증상. 같은 실적이 두 번 집계돼 생산수량이 실제보다 많게 나옵니다. 월말에 재고와 맞춰보다가 발견되는 경우가 많습니다.

왜 구조적인가. 중복이 생기는 경로가 둘인데, 둘 다 정상 동작의 결과입니다. 하나는 사람 경로입니다. 전송이 안 된 줄 안 작업자가 같은 실적을 다시 입력합니다. 이건 실수가 아니라 오히려 성실한 대응입니다. 다른 하나는 시스템 경로입니다. 통신이 복구되자 단말이 남아 있던 실적을 다시 보내는데, 사실 첫 전송은 서버에 도착해 있었습니다.

원인은 하나로 모입니다. 같은 실적인지 알아볼 식별자가 없다는 것입니다. 단말이 실적을 만들 때 고유 ID를 붙여 보내면 서버가 두 번째로 들어온 같은 ID를 걸러낼 수 있습니다. 반대로 서버가 저장하는 시점에 번호를 매기는 구조라면, 서버 입장에서 두 건은 그냥 서로 다른 두 건입니다. 판별할 근거 자체가 없습니다.

두 경로 모두 정상 동작의 결과다

무엇을 확인하면 막는가. 실적 식별자를 단말이 만드는지 서버가 만드는지, 같은 식별자가 두 번 들어오면 서버가 어떻게 처리하는지(거부·덮어쓰기·추가 중 무엇인지), 그리고 작업자가 화면에서 중복 여부를 알 수 있는지를 확인합니다.

데이터가 아니라 작업이 멈춘다

증상. 바코드는 읽히는데 다음 화면으로 넘어가지 않습니다. 데이터가 사라지는 것이 아니라 작업 자체가 진행되지 않습니다.

왜 구조적인가. 검증을 매번 서버 조회로 처리하는 설계입니다. 이 품번이 맞는지, 이 공정에 투입해도 되는지를 서버에 물어보는데, 오프라인에서는 물어볼 곳이 없으니 판단을 못 하고 진행을 막습니다.

다만 이걸 잘못된 설계라고 단정하기는 어렵습니다. 틀린 자재가 투입되느니 라인이 멈추는 편이 나은 공정이 분명히 있습니다. 회사마다, 같은 회사 안에서도 공정마다 답이 다릅니다. 중요한 것은 이 선택이 의도된 것인지, 아니면 아무도 정하지 않아 그렇게 된 것인지입니다.

무엇을 확인하면 막는가. 검증에 쓰는 마스터 데이터를 단말에 내려받아 두는지, 내려받는다면 갱신 주기가 어떻게 되는지, 그리고 오프라인 상태에서 통과시킬 항목과 막을 항목을 우리가 정할 수 있는지를 봅니다.

끊긴 걸 아무도 모른다

증상. 두 가지 형태로 나타납니다. 하나는 시간대 문제입니다. 야간이나 주말에 끊기면 월요일 아침에야 발견됩니다. 다른 하나는 범위 문제입니다. 설비 자동수집은 살아 있는데 사람이 입력하는 실적만 죽어서, 나중에 두 숫자가 맞지 않습니다.

왜 구조적인가. 감시 대상이 "서버가 살아 있는가"에 맞춰져 있기 때문입니다. 서버는 멀쩡하고 대시보드에도 숫자가 올라오고 있으니 정상으로 보입니다. 전체가 멈추면 바로 알아채는데, 일부만 끊기면 오히려 발견이 늦습니다.

덧붙이면, 실적이 들어오지 않은 시간은 비가동으로도 잡히지 않습니다. 아예 없던 시간이 되기 때문에 가동률이나 OEE가 실제보다 좋게 나옵니다. 숫자가 나빠지는 게 아니라 좋아지는 방향이라 더 오래 방치됩니다.

무엇을 확인하면 막는가. 단말별 최종 데이터 수신 시각을 볼 수 있는 화면이 있는지, 일정 시간 데이터가 없으면 알림이 나가는지, 그 알림을 받을 사람이 실제로 지정돼 있는지를 확인합니다. 셋 중 마지막이 가장 자주 빠집니다.

도입 전에 물어볼 것

위 내용을 공급사에 던질 수 있는 질문으로 바꾸면 아홉 개입니다. 답을 문서로 받아두면 나중에 책임 소재를 따질 때도 근거가 됩니다.

영역	질문	주의해서 들을 답
보관	미전송 데이터를 어디에 보관합니까?	메모리에만 둔다면 재부팅에 취약합니다
	보관 가능한 최대 건수나 기간은 얼마입니까?	"제한 없습니다"는 대개 확인해보지 않은 답입니다
	한도를 넘으면 어떻게 됩니까?	오래된 것부터 지우는데 알림이 없다면 위험합니다
	단말을 재부팅해도 남아 있습니까?	말로 듣지 말고 시연에서 직접 확인합니다
전송	실적 식별자는 단말과 서버 중 어디서 만듭니까?	서버 채번이면 중복 판별이 어렵습니다
	같은 식별자가 두 번 오면 서버가 어떻게 처리합니까?	거부·덮어쓰기·추가 중 무엇인지 명확해야 합니다
표시	미전송 건수가 작업자 화면에 보입니까?	관리자 화면에만 있으면 현장은 모릅니다
검증	마스터를 단말에 보관합니까, 갱신 주기는 어떻게 됩니까?	갱신 주기가 길면 구버전으로 판정합니다
감시	단말별 최종 수신 시각을 볼 수 있습니까?	화면이 있어도 알림 담당자가 없으면 무의미합니다

가장 확실한 방법은 따로 있습니다. 시연 자리에서 랜선을 뽑아보거나 공유기를 꺼보는 것입니다. 실적 몇 건을 입력하고, 단말을 재부팅하고, 다시 연결한 뒤 서버에 몇 건이 들어왔는지 세어보면 위 아홉 개 질문의 답이 대부분 한 번에 나옵니다. 이 요청을 부담스러워하는 공급사라면 그 반응 자체가 정보입니다.

사람이 입력하는 실적이 아니라 설비에서 직접 데이터를 가져오는 경우에도 같은 질문이 필요합니다. 설비 연결의 네 가지 경로와 각각의 조건은 설비를 연결한다는 것에 정리했습니다. 장애가 끝난 뒤 수기 기록을 시스템에 다시 넣는 과정은 장애가 끝난 뒤, 종이에 남은 숫자는 어디서 어긋나는가?에서 이어집니다.