CCTV 야간에만 화면 뿌옇다면 로컬 화면부터 확인

"낮엔 선명한데 밤만 되면 화면 전체가 안개 낀 것처럼 뿌옇게 나와요."

"불 끄고 나면 가운데가 하얗게 떠서 사람 얼굴이 안 보여요."

이 두 장면, 사장님 눈엔 그냥 "밤에 화질이 나쁘다"로 보이실 겁니다. 그런데 여기엔 원인을 좁혀주는 결정적 단서가 하나 숨어 있어요.

바로 "야간에만" 이라는 조건입니다.

IR LED는 어두워지면 자동으로 켜지도록 설정된 모델이 많습니다. 다만 자동 점등 여부와 임계값은 모델 설정에 따라 다르므로, 사장님 장비의 야간 모드와 IR 설정을 확인해야 합니다.

낮엔 멀쩡하고 밤에만 뿌옇다면, 적외선 반사·오염·주변 조명처럼 야간 모드에서 두드러지는 원인을 먼저 배제할 실익이 큽니다.

이 글은 그 "야간 뿌염"을 로컬/원격 분리 → 외부 오염 → 적외선 반사 → 주변 조명 → 모델별 IR 끄기 비교 → 업체 점검 순으로 확인하도록 정리한 편집 자료입니다. 확인일은 2026-08-13입니다.

낮엔 멀쩡한데 밤에만 뿌옇다면 왜 적외선을 보나

핵심부터 말씀드릴게요. 낮에는 선명하다가 야간 모드로 바뀐 뒤 뿌옇다면, 적외선 반사·오염·주변 조명을 우선 확인할 단서가 됩니다. 다만 IR 작동 방식은 모델과 설정에 따라 다릅니다.

즉 "밤에만"이라는 조건은 불편이 아니라 진단 범위를 줄이는 단서입니다.

카메라가 빛을 받아들이는 단계, 적외선이 켜지며 어둠을 비추는 단계, 그 빛이 렌즈로 돌아오는 단계 — 야간 화질은 이 흐름의 영향을 받아요.

이 중 어디서 빛이 반사되거나 산란하면 화면 전체가 안개처럼 뜰 수 있습니다.

다만 갈라둘 게 하나 있습니다. 로컬 모니터(녹화기에 직접 연결한 화면)에서도 뿌옇나요, 아니면 폰·원격에서만 뿌옇나요?

폰이나 밖에서 볼 때만 흐릿하고 매장 모니터에선 선명하다면, IR 반사보다 원격 앱의 Clear·Fluent 선택, 서브스트림, 해상도·비트레이트 설정을 먼저 비교하세요. 다만 이 관찰만으로 원인을 전송 화질 하나로 확정할 수는 없습니다.

이 경우는 CCTV 원격 영상이 자꾸 끊기면 어디부터 점검하나 쪽도 함께 보시는 게 맞습니다.

로컬 모니터에서도 밤에만 뿌옇다면, 이제 외부 오염부터 확인한 뒤 반사와 주변 조명을 차례로 배제합니다.

이 뿌연 화면을 만드는 세 자리 — 오염·반사·주변 조명

야간 뿌염을 만들 수 있는 자리를 세 군데로 나눠 보겠습니다. 셋 다 빛이 렌즈에 들어오는 과정에서 생기는 문제예요.

• ① 돔·렌즈 오염. 커버나 렌즈에 낀 먼지·지문·물자국·거미줄, 또는 돔 안쪽 결로가 IR을 산란시킬 수 있습니다.
• ② 적외선 반사. 카메라가 처마·벽·간판·유리에 너무 가까우면, IR이 튕겨 렌즈로 되돌아올 수 있습니다. 돔 카메라는 렌즈 둘레 폼링이 맞지 않아 돔 안에서 반사되기도 하죠.
• ③ 주변 강한 조명. 가까운 간판·가로등이나 옆 카메라의 IR이 화면으로 들어오면 하얗게 뜨거나 번질 수 있습니다.

서로 다른 원인이 비슷한 "뿌염"으로 보일 수 있습니다.

그러니 한 번에 한 축만 바꾸고, 밤에 실제로 화면이 개는지 확인하세요.

① 돔 커버나 렌즈에 먼지·거미줄·습기가 끼었나

첫 번째 축은 오염입니다. 돔 커버나 렌즈에 낀 먼지·지문·물자국·거미줄이 IR 빛을 산란시켜, 낮엔 덜 보이던 번짐이 밤에 두드러질 수 있어요.

낮에는 자연광 아래에서 오염의 영향이 작아 보일 수 있습니다. 정작 IR 비중이 커지는 밤엔 같은 얼룩이 확 도드라지기도 하죠.

돔 안쪽 결로·습기도 흐린 화면을 만들 수 있습니다. 김 서린 듯한 자국이 커버 안쪽에서 보인다면 외부 오염과 구분해야 해요.

판정 테스트는 간단합니다. 전원을 끄고 안전하게 접근할 수 있을 때만, 마른 극세사 천으로 돔·렌즈의 외부 표면을 닦은 뒤 그날 밤 다시 보세요.

• 닦았더니 개운해졌다면 → 표면 오염의 영향이 있었던 것으로 볼 수 있습니다. 거미줄이 자주 끼는 자리라면 주기적으로 닦아주세요.
• 외부를 닦아도 안쪽에서 뿌옇다면 → 돔 내부 결로 가능성을 확인해야 합니다. 밀봉을 임의로 뜯지 말고 방수 씰·방습 상태를 설치 업체에 확인하는 편이 안전합니다.

IR 조명을 갖춘 주야간 카메라는 벌레와 거미가 모이는 환경이 생길 수 있습니다. 다만 위치를 옮길 때는 화각과 고정 상태, 낙상 위험까지 함께 확인하셔야 해요.

② 적외선이 벽·처마에 튕겨 렌즈로 돌아오나

적외선 반사는 공식 문서에서 반복 확인되는 우선 점검 원인 중 하나입니다. 카메라가 벽·처마·간판·유리 같은 면에 가까우면, 켜진 IR이 그 면에 튕겨 렌즈로 되돌아와 화면을 뿌옇게 만들 수 있습니다.

Reolink 공식 안내도 렌즈가 매끈한 벽·거울·밝은 조명·반사되는 천장이나 바닥을 향하지 않게 위치를 조정하라고 안내합니다. 자세한 항목은 Reolink 공식 Night Vision Blurry 안내에서 확인하실 수 있어요.

돔 카메라라면 한 자리를 더 봐야 합니다.

렌즈 둘레의 차광 폼링(고무 링)이 돔 안쪽에 딱 밀착돼 있어야, IR이 돔 안에서 새어 렌즈로 반사되는 걸 막습니다. Hikvision 공식 안내도 이 폼링을 돔에 단단히 눌러 붙이라고 안내해요.

Hikvision IR 야간 번짐 방지 폼링 안내 — 출처: supportusa.hikvision.com (공식 문서, 2026-08-13 확인)

판정 테스트는 이렇게 하세요. 안전하게 조정할 수 있는 위치라면 카메라를 가까운 반사면에서 잠깐 떼거나 각도를 살짝 틀어, 밤에 뿌염이 줄어드는지 보세요.

• 각도를 틀거나 거리를 뒀더니 화면이 갠다면 → 그 반사면이 증상에 영향을 줬을 가능성이 큽니다. 위치·각도를 다시 잡고 같은 조건에서 재현하세요.
• 돔 카메라인데 폼링이 떠 있었다면 → 장비 구조와 방수 밀봉을 확인한 뒤 링이 돔에 고르게 밀착되는지 점검하세요. 분해가 필요하면 설치 업체에 맡기는 편이 안전합니다.

여기서 주의 하나. 각도를 잡을 때 렌즈 초점링(포커스)은 건드리지 마세요. 낮 영상이 선명하면 반사·오염·광원을 먼저 배제할 실익은 있지만, 이것만으로 야간 초점 문제가 배제되지는 않습니다.

초점 조정이 필요하다면 모델별 절차를 확인하거나 설치 업체에 맡기세요.

③ 가까운 간판·가로등 불빛이 화면을 태우나

세 번째 축은 주변 조명입니다. 화면 안이나 바로 옆에 강한 광원 — 간판, 가로등, 자동문 센서등, 다른 카메라의 IR — 이 있으면 일부가 하얗게 뜨고 번질 수 있습니다.

이 축은 뿌염이 광원 주변에 몰리는지 함께 보세요. 밝은 점 주변으로 빛이 퍼진다면 주변 광원의 영향을 비교할 실익이 있습니다.

판정 테스트는 이렇게 하세요. 안전하고 허용된 범위에서 의심되는 광원을 잠깐 가리거나 끄고, 같은 야간 화면을 비교하세요.

• 광원을 가렸더니 번짐이 줄었다면 → 그 광원이 증상에 영향을 줬을 가능성이 큽니다. 카메라 각도를 틀어 강광원을 화각 밖으로 빼는 방법을 검토하세요.
• 여러 대를 나란히 설치했는데 서로 마주 본다면 → 옆 카메라 IR의 영향을 확인하세요. 화각을 바꿀 때는 감시 사각이 생기지 않는지도 함께 보셔야 합니다.

밝은 광원을 완전히 없앨 수 없다면, WDR이나 야간 노출 설정을 비교할 수 있습니다. 다만 지원 여부와 효과 범위, 메뉴 명칭은 모델마다 다르니 사장님 장비의 공식 안내를 확인하셔야 합니다.

오염·반사·주변 조명을 확인해도 그대로라면, IR 제어를 지원하는 모델에 한해 한 번 더 비교할 수 있습니다.

주변 가시광을 먼저 확보하고 현재 설정을 기록한 뒤, IR을 `Auto`에서 `Stay Off`처럼 끄는 설정으로 잠시 바꿔 같은 화각을 보세요. Reolink의 지원 모델에서는 이런 IR 켜기·끄기 설정을 공식 IR Lights 안내에서 확인할 수 있습니다.

IR을 껐을 때 번짐이 사라졌다면 자체 IR이나 그 반사 경로의 영향을 의심할 근거는 됩니다. 하지만 그 결과만으로 특정 벽·폼링·오염을 원인으로 확정할 수는 없습니다. 앞선 단일변수 테스트와 함께 판단하세요.

화면이 너무 어두워 피사체를 비교할 수 없다면 이 테스트로는 판정할 수 없습니다. 시험이 끝나면 기록해 둔 원래 설정, 보통 사용하던 `Auto` 상태로 반드시 복원하세요.

같은 '야간 뿌염'을 세 축으로 나눈 판정표

증상·상황	우선 점검 축	판정 테스트	사장님이 직접?
폰·원격에서만 뿌옇다(모니터는 선명)	로컬/원격 분리	Clear·Fluent, 서브스트림, 해상도·비트레이트 비교 후 다른 원인도 확인	O
닦은 지 오래됐다·거미줄이 보인다	① 외부 오염	전원을 끄고 외부 표면을 마른 극세사로 닦은 뒤 재현	O
김 서린 듯 뿌옇고 안쪽에서 흐리다	① 돔 내부 결로	임의 분해하지 말고 방수·방습 상태 업체 확인	X
화면 전체가 안개처럼 뿌옇다	② 적외선 반사	오염 제거 후 반사면에서 떼거나 각도를 틀어 재현	O
가운데가 하얗게 떠서 얼굴이 안 보인다	② 반사·폼링	가까운 반사면과 돔 폼링 밀착 상태 확인	일부 O
돔 카메라인데 밤에만 흐리다	② 폼링·반사면	폼링과 벽·처마 위치를 확인하되 분해는 업체 의뢰	일부 O
밝은 점 주변으로 빛이 번진다	③ 주변 조명	의심 광원을 잠깐 가리거나 끄고 재현	O
여러 대가 서로 마주 본다	③ 타 카메라 IR	한 대씩 영향을 비교하고 사각 없이 각도 조정	일부 O
세 축을 확인해도 그대로다	IR 끄기 비교	지원 모델만 주변 가시광 확보 후 IR을 잠시 끄고 비교·원래 설정 복원	O
IR을 끄니 번짐이 줄었다	IR 또는 반사 경로	특정 원인으로 확정하지 말고 반사면·폼링·오염을 각각 재현	O
IR을 끄니 화면이 너무 어둡다	판정 불가	설정을 즉시 복원하고 다른 테스트나 업체 점검으로 전환	O
모두 확인해도 밤에만 흐리다	야간 초점·노출·IR-cut·센서·모듈	모델별 진단, 설치 업체 확인	X

이 표는 원인을 확정하는 표가 아닙니다. 어느 축부터 볼지 정하는 편집상 판정표예요.

두 축이 겹칠 수도 있습니다. 처마 반사도 있고 돔에 먼지도 꼈으면 둘 다 잡아야 화면이 완전히 갤 수 있습니다.

그러니 한 축씩 바꾸고, 같은 야간 조건에서 재현해 보세요.

야간 화면이 뿌옇다면 오늘 뭐부터 손대나

가장 먼저 하실 일은 딱 하나입니다. 로컬 모니터에서도 뿌옇나 확인하는 것.

폰에서만 흐리고 매장 모니터는 선명하다면, 원격 앱의 Clear·Fluent 선택과 서브스트림, 해상도·비트레이트 설정부터 비교하세요. 다만 그것만으로 원인을 확정하지는 마세요.

로컬에서도 밤에만 뿌옇다면 순서가 있습니다. 외부 오염을 닦고 → 반사면과 폼링을 확인하고 → 주변 강광원을 가리고 → 지원 모델만 IR을 꺼 비교하고 → 그대로면 업체 점검으로 넘기는 겁니다.

닦기가 쉽고 장비 설정을 바꾸지 않으니, 안전하게 접근할 수 있을 때 외부 표면부터 확인해 보세요.

반대로, 오늘 절대 먼저 하면 안 되는 게 있습니다. 밤에 흐리다고 렌즈 초점링부터 돌리지 마세요. 낮 영상이 선명해도 야간 초점·노출·IR-cut 계통 문제는 남을 수 있지만, 먼저 반사·오염·광원을 한 축씩 배제하는 편이 안전합니다.

화면이 아예 안 나오거나 밤 영상이 녹화에도 안 남는다면, 이건 화질이 아니라 녹화 계통 문제일 수 있습니다. 그때는 매장 CCTV 녹화 미저장 원인 4단계 점검법 쪽을 먼저 보시는 게 맞습니다.

끝으로 당부 하나. 카메라·녹화기의 IP·포트 같은 통신 설정은 원격 접속 자체를 끊을 수 있으니 손대지 마세요. 외부 오염·반사면·폼링·주변 광원과 IR 비교까지 마쳤는데도 그대로라면, 야간 초점·노출·IR-cut·센서·렌즈 모듈 가능성을 모델명·설치 위치·증상과 함께 설치 업체에 확인하시면 됩니다.

---

*이 글은 Hikvision 공식 IR 야간 번짐 방지 안내, Reolink 공식 Night Vision Blurry 안내, Reolink 공식 IR Lights 안내 등 공개 자료를 매장 사장님 관점에서 정리·대조한 편집 자료입니다(확인일 2026-08-13). 본문의 로컬/원격 분리 → 외부 오염 → 적외선 반사 → 주변 조명 → IR 끄기 비교 순서는 모든 장비의 공식 공통 절차가 아니라, 안전성과 실행 비용을 고려해 한 번에 바꾸는 범위를 줄이도록 구성한 우선 배제 모델입니다.

실제 메뉴 명칭·설정 위치·야간 보정 방식은 카메라·녹화기 제조사와 뷰어 앱, 펌웨어 버전에 따라 다를 수 있습니다. 높은 곳의 카메라 위치 변경, 돔 방수 밀봉 분해, 폼링 재조립, 렌즈 초점 조정은 낙상·방수 훼손 위험이 있으니 설치 업체에 맡기시기 바랍니다.

카메라·녹화기의 IP·포트·네트워크 통신 설정은 임의로 변경하지 마시기 바랍니다.*

CCTV 움직임 감지되는데 알림 안 오면 점검 순서

"화면엔 움직임 잡혔다고 표시가 뜨는데, 왜 폰은 조용하죠?"

"어제까진 알림 오던데, 오늘부터 갑자기 안 와요."

이 두 상황, 사장님 눈엔 똑같이 "알림이 안 온다"로 보입니다. 그런데 끊긴 자리는 서로 다릅니다.

먼저 딱 하나만 짚고 가겠습니다.

카메라가 움직임을 "감지"하는 것과, 그 사건을 폰으로 "푸시"로 보내는 것은 서로 다른 단계입니다. 감지 표시가 떴다는 건 앞 단계가 됐다는 뜻이지, 알림까지 발송됐다는 뜻이 아니에요.

그래서 감지 로그·녹화는 멀쩡한데 알림만 안 오는 일이 생깁니다.

이 글은 그 "알림 안 옴"을 세 축 — ① 폰·앱 알림 권한 → ② 감지·알림 일정 → ③ 기기의 알림 연동·푸시 설정 — 으로 갈라, 사장님이 직접 확인할 선까지 정리한 편집 자료입니다. 확인일은 2026-08-12입니다.

감지 표시는 뜨는데 폰만 조용한 이유 — 세 군데가 따로 논다

핵심부터 말씀드릴게요. 감지·녹화가 됐다는 사실은 알림이 발송됐다는 증거가 아닙니다.

카메라가 움직임을 잡는 단계, 그 사건을 알림으로 만들라고 기기가 지시하는 단계, 그 알림을 폰이 화면에 띄우는 단계 — 이 셋은 따로 놉니다.

그래서 셋 중 어디 하나만 막혀도 결과는 똑같이 "조용함"이에요.

사장님이 헷갈리는 지점이 바로 여기입니다. 감지 로그가 쌓이니까 "카메라는 멀쩡한데 왜 알림만?"이라고 생각하시죠.

감지 표시가 확인하는 것은 감지 단계까지입니다. 알림 생성·기기 연동과 휴대폰 표시 단계는 별도로 확인해야 합니다.

한 가지 먼저 갈라둘 게 있어요.

밖에서 앱이 카메라에 접속 자체가 안 되는 상황이라면, 그건 알림 문제가 아니라 원격 연결 문제입니다. 접속이 아예 안 된다면 매장 CCTV 원격접속 실패 — 포트포워딩·DDNS 5단계 점검을, LTE로 붙을 때만 안 된다면 매장 CCTV LTE 접속 불가 — 공인 IP·DDNS·P2P 점검을 먼저 보시는 게 맞습니다.

앱은 잘 붙어서 실시간 영상도 보이는데 알림만 안 온다면, 이제 아래 세 축입니다.

① 폰이나 앱이 알림을 조용히 버리고 있나

가장 먼저 볼 축은 폰과 앱의 알림 권한입니다. 기기가 푸시를 정상 발송해도, 받는 폰이 그걸 막고 있으면 화면엔 아무것도 안 뜹니다. OS 알림 허용, 앱 내 알림 토글, 방해금지·절전 설정을 순서대로 확인하세요.

여기가 막혀 있으면 설정을 아무리 깊게 파도 소용없어요. 알림이 폰 문턱에서 버려지니까요.

Reolink 공식 안내도 폰 설정과 Reolink 앱 양쪽 모두에서 푸시 알림을 켜야 한다고 안내합니다. 자세한 항목은 Reolink 공식 Enable Push Notifications 안내에서 확인하실 수 있어요.

체크할 자리는 이렇습니다.

• 폰 OS 설정 → 해당 앱 → 알림 허용이 켜져 있나. 여기가 꺼지면 앱은 아예 못 띄웁니다.
• 방해금지(집중 모드) 가 걸려 있진 않나. 장사 시간에만 조용하다면 시간대 자동 방해금지를 의심하세요.
• 배터리 절전·백그라운드 제한. 안드로이드에서 앱을 절전 대상에 넣으면 백그라운드 푸시가 지연되거나 막힐 수 있어요.
• 앱 안의 알림 스위치와 '조용 시간'·음소거. 앱 자체에 무음 설정이 따로 있다면 함께 확인해야 합니다.

판정 테스트는 이겁니다. 제조사가 지원하는 장비 공유·공유 사용자 기능으로 조건을 맞춘 다른 폰에서 같은 카메라 알림을 시험해 보세요.

계정 비밀번호를 가족 폰에 직접 입력하기보다 별도 공유 사용자 방식을 우선 사용하세요. 지원 여부가 불명확하면 해당 모델의 제조사 안내를 먼저 확인하셔야 합니다.

• 조건을 맞춘 다른 폰에서는 알림이 오는데 사장님 폰만 안 온다면 → 기존 폰의 권한·절전 설정을 우선 의심할 수 있습니다. 위 네 자리를 다시 보세요.
• 두 폰 모두 안 오더라도 → 폰 축이 완전히 배제되는 것은 아닙니다. 두 폰의 OS 권한과 앱 푸시 설정을 각각 확인한 뒤 ②번 일정, ③번 기기 연동으로 넘어가세요.

한 가지만 더요. 앱을 다시 열 때 밀린 알림이 나타난다면 백그라운드 제한이 가능한 원인 중 하나입니다.

절전 예외 적용 전후를 비교하되, 재현되지 않으면 앱·네트워크·푸시 서비스 상태를 제조사 절차로 확인하세요.

② 감지는 종일 하는데 알림 일정만 비어 있나

두 번째 축은 일정입니다. 여기서 감지 스케줄과 알림(푸시) 스케줄은 별개라는 점이 핵심이에요.

카메라가 24시간 감지하도록 돼 있어도, 푸시를 보내는 시간표가 지금 시간대를 비워두면 알림은 안 옵니다.

일정이 비어 있으면 같은 증상이 생깁니다. 감지는 늘 켜져 있으니 "일정 문제일 리 없다"고 넘기지 마세요.

Reolink에는 알림을 보낼 시간대를 따로 지정하는 푸시 스케줄이 있습니다. 특정 시간·요일에만 푸시를 켜도록 짜두면, 그 밖의 시간엔 감지해도 알림이 안 갑니다.

설정 항목은 Reolink 공식 Push Schedule 안내에서 볼 수 있어요.

Hik 계열은 이벤트마다 arming schedule(경계 일정) 이 걸려 있습니다. 이 일정이 지금 시각을 포함하지 않으면 그 시간엔 이벤트 연동 자체가 동작하지 않습니다.

판정 테스트는 이렇게 하세요. 푸시 스케줄 또는 arming schedule을 하루 전체·모든 요일로 잠깐 열어 두고, 카메라 앞에서 손을 흔들어 알림이 오는지 보세요.

• 일정을 다 열었더니 알림이 온다면 → 원인은 비어 있던 시간대입니다. 매장 운영 시간에 맞춰 다시 짜세요.
• 다 열어도 여전히 안 온다면 → 일정 외 원인을 확인해야 합니다. ③번 기기 연동으로 넘어갑니다.

채널별로도 확인하세요. 여러 대 중 특정 카메라만 알림이 안 온다면, 그 채널의 일정·알림 대상과 카메라별 푸시 스위치를 정상 카메라와 대조해 보세요.

한 카메라만 조용한지, 전체가 조용한지 — 이 구분만으로도 범위가 확 줄어요.

③ 기기에서 '알림 보내기' 스위치가 안 걸렸나

세 번째로 확인할 자리입니다. 녹화기·카메라에서 이벤트에 "알림을 내보내라"는 연결이 안 걸리면, 사건은 기록되지만 푸시는 가지 않을 수 있습니다. 녹화는 되는데 알림만 없다면 이 축을 우선 확인하되 확정하지는 마십시오.

Hik 계열에서 확인할 항목은 Notify Surveillance Center입니다. 해당 모델의 이벤트 설정에 이 항목이 있다면 Linkage Method(연동 방식)에서 활성화돼 있는지 확인하세요.

공식 문서 기준으로 이벤트 발생 시 원격 알림 호스트로 신호를 보내는 연동 항목입니다. 다만 실제 메뉴 명칭과 앱 푸시 연결 방식은 모델·펌웨어에 따라 다르므로 사장님 장비의 공식 안내를 함께 확인해야 합니다.

Reolink 계열은 해당 카메라의 Push Notifications 메뉴와 푸시 스위치, 유효한 푸시 스케줄을 확인하세요. 녹화 설정과 푸시 알림 설정은 별도이므로, 녹화된 사건이 있다고 해서 푸시 발송까지 보장되지는 않습니다.

판정 테스트는 간단합니다. 녹화 파일이나 이벤트 로그를 먼저 보세요.

• 녹화·이벤트 로그엔 사건이 남는데 푸시만 없다면 → ③번을 우선 확인하되 확정하지는 마십시오. Hik이면 해당 모델의 Notify Surveillance Center와 앱 알림 설정을, Reolink면 해당 카메라의 Push Notifications 메뉴·푸시 스위치·유효한 푸시 스케줄을 확인하세요.
• 로그에도 사건이 안 남는다면 → 애초에 이벤트가 안 잡히는 것이니, 이 글보다 매장 CCTV 녹화 미저장 원인 4단계 점검법 쪽을 먼저 보시는 게 맞습니다.

세 축이 모두 정상인데도 두 폰에서 알림이 안 오면, 여기서 폰이나 기기를 바로 초기화하지 마세요.

Reolink 장비라면 Reolink 공식 푸시 알림 미수신 문제 해결 안내에 따라 기기의 인터넷 연결 상태, 앱·펌웨어 업데이트 여부를 확인하세요. 제조사 푸시 서비스 상태도 공식 공지나 지원 창구에서 확인한 뒤, 해결되지 않으면 모델명·펌웨어 버전·발생 시각을 정리해 공식 지원에 문의하시면 됩니다.

다른 제조사도 해당 모델의 공식 푸시 알림 문제 해결 절차를 우선 따르세요. 앱 버전, 기기 펌웨어, 인터넷 연결, 제조사 서비스 상태를 확인한 뒤에도 재현되면 공식 지원이나 설치 업체 확인이 필요합니다.

한 가지 주의를 드릴게요. 이벤트 연동을 만질 때 카메라·녹화기의 IP·포트·네트워크 통신 설정은 건드리지 마세요.

여기서 바꾸는 건 어디까지나 알림 연동과 푸시 설정입니다. 통신 경로를 잘못 만지면 원격 접속 자체가 끊길 수 있어요.

메뉴 명칭과 위치는 제조사·펌웨어 버전마다 다릅니다. 사장님 장비에서 항목이 안 보이면 임의로 다른 값을 바꾸지 마시고, 해당 모델 제조사나 설치 업체 확인이 필요합니다.

같은 '알림 안 옴'을 세 축으로 나눈 판정표

증상·상황	우선 점검 축	판정 테스트	사장님이 직접?
조건을 맞춘 다른 폰엔 오는데 내 폰만 안 온다	① 폰·앱 권한	두 폰의 OS 알림 허용·앱 푸시 설정을 대조하고 기존 폰의 방해금지·절전 예외 확인	O
앱을 다시 열 때 밀린 알림이 나타난다	① 백그라운드 제한 가능성	절전 예외 적용 전후를 비교하고 재현되지 않으면 공식 문제 해결 절차 확인	O
장사 시간에만 조용하다	① 방해금지 / ② 일정	시간대 방해금지 해제, 푸시 일정 확인	O
특정 시간·요일에만 안 온다	② 알림 일정	일정을 하루 전체로 열고 대조	O
여러 대 중 한 대만 안 온다	② 일정·알림 대상 / ③ 카메라별 푸시	정상 카메라와 해당 채널의 일정·알림 대상·푸시 스위치 대조	O
녹화·로그엔 남는데 푸시만 없다	③ 기기 알림 연동 우선 확인	Hik 해당 모델의 'Notify Surveillance Center' / Reolink의 Push Notifications 메뉴·푸시 스위치·스케줄 확인	O
두 폰 모두 권한·일정·기기 푸시가 켜져 있는데 안 온다	공식 후속 절차	기기 인터넷 연결, 앱·펌웨어 업데이트 여부, 제조사 푸시 서비스 상태 확인 후 공식 지원 문의	일부 O
로그에도 사건이 안 남는다	이 글 범위 밖	감지·녹화 저장 계열부터 점검	일부 O
앱 접속 자체가 안 된다	원격 연결	접속·회선·P2P 계열부터 점검	O

편집자 노트. 이 글의 우선 배제 모델에서는 기기에서 알림을 내보내라는 연결이 빠졌는지, 폰이 그 알림을 조용히 버리는지를 감지 감도보다 먼저 확인합니다. 감지 표시가 이미 뜨고 있다면 감도는 이번 범위가 아닙니다.

이 표는 원인을 확정하는 표가 아닙니다. 어느 축부터 볼지 정하는 편집상 판정표예요.

두 축이 겹칠 수도 있습니다. 폰 절전도 걸려 있고 기기 연동도 빠져 있으면 두 자리를 다 고쳐야 알림이 옵니다.

그러니 한 번에 한 축만 바꾸고, 손 흔들어 재현해 보세요.

알림이 끊겼다면 오늘 뭘 먼저 하나

알림이 안 올 때 가장 피해야 할 건, 원인을 모른 채 앱부터 지우거나 녹화기를 초기화하는 일입니다. 그건 세 축과 공식 후속 절차를 확인한 뒤 마지막에 할 일이지, 처음 할 일이 아니에요.

첫 동작은 딱 하나입니다. 사장님 폰에서 OS 알림 권한과 앱 푸시 설정이 모두 켜져 있는지 확인하는 것.

다른 폰과 대조하려면 제조사가 지원하는 장비 공유·공유 사용자 기능을 우선 사용하세요. 지원 여부가 불명확하면 계정 비밀번호를 직접 입력하기 전에 제조사 안내를 확인하셔야 합니다.

여기서 갈립니다. 조건을 맞춘 다른 폰에서는 오면 기존 폰의 권한·절전 설정을 우선 의심할 수 있습니다.

두 폰 모두 안 오더라도 폰 축이 완전히 배제되는 것은 아니므로 두 폰의 OS 권한과 앱 푸시 설정을 각각 확인한 뒤 일정·기기 연동으로 넘어갑니다.

그다음은 순서가 있습니다. 폰·앱 권한을 열고 → 푸시 일정을 지금 시간대까지 켜고 → 그래도 안 오면 녹화 로그를 확인해 기기의 알림 연동을 보는 겁니다.

녹화엔 사건이 남는데 푸시만 없다면, ③번을 우선 확인하되 확정하지는 마십시오. Hik이면 해당 모델의 Notify Surveillance Center와 앱 알림 설정을, Reolink면 해당 카메라의 Push Notifications 메뉴·푸시 스위치·유효한 푸시 스케줄을 확인하세요.

두 폰의 권한, 알림 일정, 기기 푸시 설정까지 모두 정상이라면 기기 인터넷 연결 → 앱·펌웨어 업데이트 여부 → 제조사 푸시 서비스 상태 순으로 공식 절차를 확인하세요. 그래도 안 오면 모델명·펌웨어 버전·발생 시각을 적어 제조사 공식 지원이나 설치 업체에 문의하시면 됩니다.

끝으로 한 가지만 당부드릴게요. 알림·화질 값은 원래대로 되돌릴 수 있지만, IP·포트 같은 통신 설정은 원격 접속 자체를 끊을 수 있으니 손대지 마세요. 그 영역은 값을 바꾸기 전에 제조사·설치 업체 안내를 먼저 확인하시는 게 안전합니다.

---

이 글은 Hik-Connect 공식 Enable Push Notification 안내, Reolink 공식 Enable Push Notifications 안내, Reolink 공식 Push Schedule 안내, Reolink 공식 푸시 알림 미수신 문제 해결 안내 등 공개 자료를 매장 사장님 관점에서 정리·대조한 편집 자료입니다(확인일 2026-08-12).

본문의 3축(폰·앱 권한 · 감지/알림 일정 · 기기 알림 연동) 순서는 모든 장비의 공식 공통 절차가 아니라 한 번에 바꾸는 범위를 줄이기 위해 구성한 우선 배제 모델이며,

실제 메뉴 명칭·설정 위치·알림 연동 방식은 카메라·녹화기 제조사와 뷰어 앱, 펌웨어 버전에 따라 다를 수 있습니다.

감지·녹화가 된다는 사실이 알림 발송을 보장하지 않으며, 'Notify Surveillance Center' 같은 알림 연동 항목의 유무와 명칭은 모델마다 다릅니다. 확인할 수 없는 모델은 제조사 또는 설치 업체 안내가 필요하며, 카메라·녹화기의 IP·포트·네트워크 통신 설정은 임의로 변경하지 마시기 바랍니다.*

CCTV 원격 영상이 자꾸 끊기면 어디부터 점검하나

"매장 안에서 모니터로 볼 땐 멀쩡한데, 왜 밖에서 폰으로만 보면 자꾸 멈추죠?"

"화질을 낮췄더니 좀 낫던데, 이게 근본 해결은 아니잖아요."

이 두 상황은 원인이 서로 다른 자리에서 옵니다. 그런데 화면만 보면 똑같이 "끊긴다"로 보이죠.

먼저 딱 하나만 가르고 시작하겠습니다.

지금 영상을 보는 경로가 ① 녹화기 직결 모니터 ② 같은 LAN에서 IP/LAN 직접 연결로 확인된 앱 ③ UID·P2P·클라우드 등록 앱 ④ 외부 모바일망 앱 중 어디인가요?

①과 ②는 로컬 경로를 우선 점검할 수 있지만, ③은 휴대폰이 같은 와이파이에 있어도 UID·P2P·클라우드 경로를 쓸 수 있습니다. 앱이 LAN 직접 연결 중임을 확인한 경우에만 로컬 경로로 판정하세요.

연결 방식이 표시되지 않는다면 같은 와이파이라는 이유만으로 업로드·P2P 경로를 배제하면 안 됩니다.

녹화기 직결 화면과 LAN 직접 연결로 확인된 앱 영상은 멀쩡한데 UID·P2P·클라우드 등록 앱이나 외부 모바일망에서만 끊긴다면, 로컬 영상 경로의 우선순위는 내려갑니다. 다만 매장 회선의 업로드·NVR 원격 송출 부하·P2P 상태·펌웨어·외부 단말 문제는 여전히 남습니다.

이 글은 그 "끊김"을 세 축 — ① 업로드 대역폭 → ② 앱이 보는 스트림(메인/서브) → ③ 인코딩(비트레이트·CBR/VBR·코덱) — 으로 갈라, 사장님이 직접 확인할 선까지 정리한 편집 자료입니다. 확인일은 2026-08-11입니다.

원격만 끊기는데 회선이 문제일 수 있나 — 업로드부터 본다

원격 영상이 끊길 때 가장 먼저 볼 축은 매장 인터넷의 업로드(업스트림) 속도입니다. 밖에서 보는 영상은 매장 회선이 바깥으로 보내는 데이터라, 다운로드가 빨라도 업로드가 부족하면 끊길 수 있습니다.

여기서 사장님이 놓치기 쉬운 게 하나 있어요.

인터넷 상품에 따라 업로드가 다운로드보다 낮은 비대칭 회선일 수 있습니다. 다만 모든 가정용·소상공인용 회선이 비대칭인 것은 아니므로, 대칭 여부는 계약 상품명이나 통신사 조회를 통해 확인하셔야 합니다.

그래서 매장 안에서 로컬로 볼 땐 멀쩡하던 영상이, 밖으로 나가는 순간 막상 끊길 수 있는 겁니다.

판정 테스트는 이겁니다. 먼저 녹화기의 상태·네트워크 통계 화면에서 Remote Live View·Outgoing Bandwidth·송신 비트레이트처럼 실제 원격 송출량을 나타내는 항목이 있는지 보세요.

메뉴 명칭과 제공 여부는 모델마다 다릅니다. Hikvision NVR도 제품 사양에 최대 Outgoing Bandwidth가 표시되지만, 그 숫자는 장비의 최대 송출 사양이지 현재 회선으로 나가는 실측값은 아닙니다.

공식 제품 사양은 Hikvision DS-9632NI-I8 제품 페이지에서 확인할 수 있습니다.

현재값을 보여 주는 통계 화면이 없다면 제조사나 설치 업체에 해당 모델의 확인 경로를 물어보셔야 합니다.

그다음 매장의 같은 인터넷을 쓰는 다른 기기(POS·태블릿·폰)에서 속도 측정을 돌려 업로드 숫자를 보세요. 가능하면 CCTV가 자주 끊기는 시간대에 여러 번 재는 게 좋습니다.

비교식은 이렇게 잡습니다.

필요 업로드 = 현재 원격으로 보는 채널별 실제 송출 비트레이트의 합 + 전송 프로토콜 오버헤드 + 다른 업로드 트래픽 + 운용 여유

실제 송출량을 볼 수 없다면 각 원격 화면이 사용하는 스트림의 설정 비트레이트를 사용자별·채널별로 합산해 기준값을 만드세요. 다만 VBR 변동과 전송 오버헤드가 있으므로, 그 합계만 측정 업로드보다 작다고 곧바로 충분하다고 판정하면 안 됩니다.

예를 들어 한 사용자가 1Mbps로 설정된 네 채널을 동시에 본다면 설정값 합계는 4Mbps입니다. 같은 네 채널의 독립 원격 스트림이 두 사용자에게 각각 생성되는 구성이라면 기준 합계는 8Mbps까지 늘 수 있습니다.

이때 측정 업로드가 10Mbps라면 숫자상 차이는 2Mbps뿐입니다. 그 안에서 프로토콜 오버헤드·VBR 상승·POS나 클라우드 백업의 업로드까지 처리해야 하므로, 실제 송출 피크를 확인하지 않고 충분하다고 단정할 수 없습니다.

모든 제조사와 전송 방식에 공통으로 적용되는 고정 여유 비율은 없습니다. 장비가 요구하는 여유 기준을 공개하지 않았다면 임의로 20%나 30%를 붙이지 말고, 해당 모델 제조사 확인이 필요하다고 보는 게 안전합니다.

• 설정 비트레이트 합계가 측정 업로드와 같거나 더 크다면 → 회선 부족 가능성이 높으므로, 같은 조건에서 실제 원격 송출량과 끊김 재현 여부를 확인하세요. 특히 VBR의 설정값이 최대값인지 목표값인지 알 수 없다면 설정 합계만으로 부족을 확정하지 마세요.
• 실제 송출량과 다른 업로드 트래픽을 더한 값이 측정 업로드에 바짝 붙는다면 → 제조사 권장 여유와 송출 피크를 추가 확인해야 합니다.
• 낮 장사 시간에만 끊기고 새벽엔 괜찮다면 → 다른 트래픽(배달 태블릿·클라우드 백업·손님 와이파이)이 업로드를 나눠 쓰는 상황일 수 있어요.
• 업로드 여유가 충분한데도 끊긴다면 → 지연·패킷 손실·NVR 송출 부하·P2P 서비스·외부 단말 축도 남습니다.

동시에 몇 명이 보느냐도 확인해야 합니다. 같은 채널·같은 비트레이트의 독립 원격 스트림이 사용자별로 생성되는 구성이라면 사용자 수에 비례해 송출량이 늘 수 있습니다. P2P·클라우드 릴레이·NVR 트랜스코딩 방식은 장비별 확인이 필요합니다.

한 명만 남기고 나머지 접속을 끊었을 때 끊김이 사라지면, 회선 용량이나 NVR 원격 송출 부하 쪽으로 기웁니다. 다만 이것만으로 둘 중 하나가 확정되는 건 아닙니다.

참고로 밖에서 접속 자체가 아예 안 되는 것과 접속은 되는데 끊기는 건 다른 문제입니다. 접속이 안 되는 상황이라면 매장 CCTV 원격접속 실패 — 포트포워딩·DDNS 5단계 점검을, LTE로 붙을 때만 안 된다면 매장 CCTV LTE 접속 불가 — 공인 IP·DDNS·P2P 점검을 먼저 보시는 게 맞습니다.

화질을 낮추면 되던데, 그게 서브스트림인가

앱에서 화질을 낮췄더니 부드러워졌다면, 라이브 화면이 메인스트림에서 서브스트림으로 바뀌었을 가능성이 큽니다. 다만 앱이 해상도·프레임·비트레이트만 조정했을 수도 있어 실제 스트림은 장비에서 확인해야 합니다.

IP 카메라와 녹화기에는 메인스트림과 하나 이상의 서브스트림을 제공하는 모델이 많습니다. 고화질·고비트레이트의 메인스트림과, 해상도·프레임·비트레이트를 낮춰 대역폭 사용을 줄인 서브스트림입니다.

메인스트림은 녹화·확대 검색처럼 화질이 중요한 용도에, 서브스트림은 원격 라이브처럼 전송량을 줄여야 하는 용도에 쓸 수 있습니다. 다만 스트림 수와 용도는 제품별 공식 사양을 확인하셔야 합니다.

Reolink 공식 안내에서는 고화질 스트림을 Clear, 낮은 해상도·프레임·비트레이트의 스트림을 Fluent로 구분합니다. 자세한 설정 항목은 Reolink 공식 Stream Settings Guide에서 확인할 수 있습니다.

Hik-Connect 공식 도움말은 원활하지 않은 라이브 뷰에서 Fluent를 선택하거나 Custom 화면에서 Stream Type·Resolution·Frame Rate·Bitrate를 조정하도록 안내합니다.

문제는 앱이나 뷰어가 원격 라이브에서 높은 비트레이트의 스트림을 요청할 때입니다.

동시 화면과 단일 확대 화면에서 서로 다른 스트림을 쓰는지는 앱·NVR·카메라 구성에 따라 다릅니다. 큰 화면에서만 끊긴다면 자동전환이라고 단정하지 말고, 실제로 선택된 스트림과 송출 비트레이트가 달라지는지 확인하세요.

판정 테스트는 간단합니다. 앱에서 낮은 화질 스트림을 수동으로 선택해 보세요. Hik-Connect라면 Fluent 또는 Custom, Reolink라면 Fluent가 실제 메뉴 사례입니다.

SD·HD·유창 같은 명칭은 제조사와 앱마다 다릅니다.

• 낮은 화질 스트림에선 부드럽고 높은 화질 스트림에서만 끊긴다면 → 스트림 선택과 대역폭이 맞물린 문제입니다. 원격은 낮은 비트레이트 스트림으로 보고, 세밀한 확인이 필요할 때만 높은 화질을 잠깐 켜는 식으로 운용하세요.
• 낮은 화질 스트림으로 바꿔도 여전히 끊긴다면 → 그 스트림의 실제 송출량이 회선 여유를 넘거나, NVR·P2P·외부 단말 같은 다른 원인이 남은 겁니다. 세 번째 축으로 넘어갑니다.

앱에 메인·서브 선택 메뉴가 아예 없을 수도 있습니다.

그럴 땐 녹화기 또는 카메라 웹 설정의 영상·인코딩 메뉴에서 스트림별 해상도와 비트레이트를 확인하고, 원격 라이브·송신 대역폭 통계가 제공된다면 화면을 전환하면서 실제 송출량이 어떻게 바뀌는지 보세요. 제조사 공식 앱 도움말에 화질 명칭과 스트림 대응 관계가 나오는지도 확인하시면 됩니다.

그래도 현재 스트림을 확인할 수 없는 장비는 추측하지 마세요. 해당 모델이 자동으로 스트림을 고르는지, 화질 버튼이 스트림 자체를 바꾸는지는 제조사 확인이 필요합니다.

일부 장비는 회선 상태에 따라 스트림이나 화질을 조정하는 기능을 둡니다. 다만 자동전환 기능의 존재·명칭·동작 기준은 제조사와 모델별로 다르므로 공식 설명서에서 확인한 뒤 사용하세요.

서브스트림도 끊기면 비트레이트·코덱을 본다

낮은 화질 스트림으로 바꿨는데도 끊긴다면, 이제 인코딩 값 자체를 봐야 합니다. 여기가 세 번째 축이에요.

핵심은 하나입니다. 스트림 설정값이 아니라 실제 원격 송출량을 측정 업로드와 비교해야 합니다.

녹화기·카메라 영상 설정에는 보통 세 가지가 함께 있습니다.

• 해상도·프레임(fps) — 높을수록 필요한 전송량이 커질 수 있습니다. 원격 서브스트림은 굳이 최고로 둘 이유가 없어요.
• 비트레이트(Kbps) — 스트림당 대역폭을 가늠하는 기준값입니다. 다만 VBR 변동·전송 오버헤드·동시 원격 스트림을 포함한 실제 송출량은 더 크거나 달라질 수 있습니다.
• 비트레이트 타입 — CBR / VBR — 목표 비트레이트를 일정하게 제어할지, 장면에 따라 달라지게 할지 정하는 방식입니다.

CBR은 설정한 목표 비트레이트를 중심으로 전송량을 제어하고, VBR은 장면의 복잡도와 움직임에 따라 대역폭 사용량이 달라집니다. 설정 숫자와 네트워크에서 측정되는 실제 트래픽을 같은 고정값으로 보면 안 됩니다.

움직임이 많은 매장(주방·계산대 앞)에서는 VBR 사용량이 증가할 수 있습니다. 다만 사람이 붐빌 때 끊긴다는 사실만으로 VBR을 원인으로 확정할 수는 없고, 그 시간의 실제 송출량·패킷 손실·다른 업로드 트래픽을 함께 봐야 합니다.

판정 테스트는 이렇게 하세요. 먼저 현재 스트림 설정값을 기록하고, 가능하면 녹화기의 실제 원격 송출량도 기록합니다. 그다음 서브스트림의 비트레이트를 한 단계 낮춰 저장한 뒤, 같은 채널 수와 같은 접속자 조건에서 끊김이 사라지는지 봅니다.

낮췄더니 부드러워지면 인코딩 값과 현재 전송 경로가 맞물린 문제입니다. 이 경우 무리하게 화질을 다 낮추기보다, 실제 송출 피크와 다른 트래픽까지 측정 업로드 안에서 처리되는 선을 찾는 게 맞습니다.

코덱도 한 축입니다. H.265(HEVC)는 같은 수준의 화질에서 H.264보다 필요한 저장·전송량을 줄일 수 있지만, 브라우저·운영체제·하드웨어·앱의 재생 지원은 서로 다를 수 있습니다.

원격에서만 이상하고 특정 기기에서 유독 심하다면, 서브스트림 코덱을 H.264로 바꿔 대조해 보세요. H.264에서만 멀쩡하다면 해당 단말이나 앱의 H.265 호환 문제 쪽으로 기웁니다.

다만 카메라·녹화기의 IP·포트·네트워크 주소 같은 통신 설정은 임의로 건드리지 마세요. 여기서 바꾸는 건 어디까지나 영상 화질·스트림 값입니다. 통신 경로 설정을 잘못 만지면 원격 접속 자체가 끊길 수 있어요.

메인/서브 스트림, 전환은 어떤 흐름으로 도나

여기서 "지금 내가 보는 화면이 어느 스트림인지"를 그림으로 한번 정리해 두면, 다음에 화질을 낮출 때 헤매지 않습니다.

공유기를 새로 바꾼 뒤부터 스트림 전환이 이상하거나 원격 접속 자체가 흔들린다면, 스트림 값보다 네트워크 쪽 변수가 먼저일 수 있습니다. 이런 경우는 공유기 바꾼 뒤 CCTV 원격접속 안 되면 IP부터 확인 글에서 IP 쪽부터 짚어보시는 게 순서에 맞습니다.

같은 '원격 끊김'을 세 축으로 나눈 판정표

증상·상황	우선 점검 축	판정 테스트	사장님이 직접?
녹화기 직결 모니터도 끊긴다	이 글 범위 밖	카메라·녹화기·내부 배선·녹화기 부하부터 확인	일부 O
같은 LAN의 앱만 끊긴다	연결 경로·내부망	앱이 IP/LAN 직접 연결 중인지 확인하고, 표시되지 않으면 업로드·P2P 경로를 배제하지 않음	O
직결 모니터와 LAN 직접 앱은 멀쩡하고 UID·P2P·클라우드 앱만 끊긴다	① 업로드·원격 송출·P2P	실제 원격 송출량과 측정 업로드를 비교하고 P2P 상태 대조	O
외부 모바일망 앱에서만 끊긴다	① 업로드·원격 경로	실제 원격 송출량·매장 업로드·외부 단말망을 각각 대조	O
낮 장사 시간에만 끊긴다	① 대역폭(경합)	다른 업로드 트래픽·동시 접속자 줄여 대조	O
여러 명이 볼 때만 끊긴다	① 회선·NVR 동시성	한 명만 남기고 종료한 뒤 실제 송출량 대조	O
화질 낮추면 부드러워진다	② 스트림 선택	앱·녹화기에서 현재 스트림 확인 후 낮은 화질로 대조	O
4분할은 되는데 크게 키우면 끊긴다	② 스트림·송출량 변화	확대 전후 스트림과 실제 송출 비트레이트 대조	O
낮은 화질 스트림도 끊긴다	③ 비트레이트	설정 기록 후 비트레이트 한 단계 낮춰 대조	O
움직임 많을 때만 순간 끊긴다	③ CBR/VBR·송출 피크	실제 송출량과 다른 트래픽을 같은 시간에 대조	O
특정 기기·오래된 앱에서만 깨진다	③ 코덱	서브스트림 H.265→H.264로 바꿔 대조	O

이 표는 원인을 확정하는 표가 아닙니다. 어느 축부터 볼지 정하는 편집상 판정표예요.

두 축이 겹칠 수도 있습니다. 업로드가 빠듯한데 앱이 높은 비트레이트 스트림까지 물고 있으면 두 축이 동시에 작용하죠.

그러니 한 번에 한 축만 바꾸고 확인하세요.

우리 매장 기록표 — 업로드·채널·비트레이트·끊김을 적어보세요

말로만 대조하면 다음 날 기억이 흐려집니다. 아래 표에 매일 또는 끊김이 있을 때마다 값을 적어두면, 어느 축이 문제인지 스스로 좁혀갈 수 있습니다.

날짜/시간	업로드 속도(다른 기기 스피드테스트, Mbps)	동시 시청 채널 수	채널별 설정 비트레이트 합(녹화기 영상 설정에서 확인, Kbps)	실제 송출량(있다면 NVR 통계, Kbps)	끊김 여부(예/아니오)
예) 08-11 13시	예) 10	예) 4	예) 4,000	예) 확인 안 됨	예) 예

계산식은 앞서 나온 것과 같습니다. 필요 업로드 = 채널별 실제 송출 비트레이트의 합(또는 실측값이 없으면 설정 비트레이트 합) + 전송 프로토콜 오버헤드 + 다른 업로드 트래픽 + 운용 여유. 이 합계와 업로드 속도가 바짝 붙어 있는 날에 끊김이 몰려 있는지를 표로 비교해 보세요.

표를 채우다 보니 스트림·업로드는 다 정상인데 유독 "감지됐다는데 알림만 늦게 오거나 안 오는" 증상이 같이 있다면, 그건 이 글의 원격 영상 축과는 다른 문제입니다. 그런 경우는 CCTV 움직임 감지되는데 알림 안 오면 점검 순서를 따로 확인해 보세요.

원격이 끊기기 시작했다면 오늘 뭘 먼저 하나

원격 CCTV가 끊길 때 가장 피해야 할 건, 원인을 모른 채 녹화기를 초기화하거나 카메라부터 의심하는 일입니다. 녹화기 직결 화면과 LAN 직접 연결로 확인된 앱 영상이 멀쩡하다면 로컬 영상 경로의 우선순위는 내려가지만, NVR의 원격 송출 부하·P2P 상태·펌웨어 문제는 남습니다.

첫 동작은 딱 하나예요. 현재 영상 경로를 ① 녹화기 직결 모니터 ② 같은 LAN에서 IP/LAN 직접 연결로 확인된 앱 ③ UID·P2P·클라우드 등록 앱 ④ 외부 모바일망 앱으로 가르는 것.

같은 와이파이에서 앱이 잘 나온다는 사실만으로 로컬 경로라고 판정하면 안 됩니다. 앱이 LAN 직접 연결 중인지 표시되지 않는다면 업로드·P2P 경로도 그대로 점검 범위에 남겨 두세요.

직결 모니터와 LAN 직접 연결 영상은 멀쩡하고 UID·P2P·클라우드 등록 앱이나 외부 모바일망에서만 끊긴다면, 위 세 축과 원격 송출 경로로 범위를 좁혀 가시면 됩니다.

그다음은 순서가 있습니다. 실제 원격 송출량과 업로드 속도를 비교하고 → 앱이 보는 스트림을 확인해 낮은 화질로 대조하고 → 그래도 끊기면 서브스트림 비트레이트와 코덱을 하나씩 바꾸는 겁니다.

실제 송출량을 볼 수 없다면 현재 원격으로 보는 사용자별·채널별 스트림 비트레이트를 합산하세요. 그 합계에 프로토콜 오버헤드·다른 업로드 트래픽·운용 여유까지 필요하다는 점을 빼면 안 됩니다.

이 합산값은 실측값이 없을 때 쓰는 보수적 용량 점검 기준이며, 끊김 원인을 확정하는 값은 아닙니다.

화질을 무작정 다 낮추는 건 임시 완화일 뿐, 어느 축이 문제였는지는 이 순서로만 갈립니다.

끝으로 한 가지만 당부드릴게요. 화질·스트림 값은 원래 값을 기록해 두면 되돌릴 수 있지만, IP·포트 같은 통신 설정은 원격 접속 자체를 끊을 수 있으니 손대지 마세요. 그 영역은 값을 바꾸기 전에 설치 업체·제조사 안내를 먼저 확인하시는 게 안전합니다.

---

이 글은 Hik-Connect 공식 라이브 화질 설정 안내, Hikvision 공식 LAN 장비 추가 안내, Hikvision NVR 공식 제품 사양, Reolink 공식 Clear·Fluent Stream Settings Guide, Reolink 공식 UID 안내, Axis 공식 비트레이트 제어 문서 등 공개 자료를 매장 사장님 관점에서 정리·대조한 편집 자료입니다(확인일 2026-08-11).

본문의 3축(업로드 대역폭·스트림 선택·인코딩) 순서는 모든 장비의 공식 공통 절차가 아니라 한 번에 바꾸는 범위를 줄이기 위해 구성한 우선 배제 모델이며,

실제 메뉴 명칭·설정 위치·스트림 전환 방식은 카메라·녹화기 제조사와 뷰어 앱, 통신사 회선 구성에 따라 다를 수 있습니다.

같은 와이파이에 연결됐다는 사실만으로 앱이 LAN 직접 연결을 사용한다고 확정할 수 없으며, 연결 방식이 확인되지 않으면 UID·P2P·클라우드 경로와 매장 업로드를 배제하지 않아야 합니다. 설정 비트레이트와 실제 네트워크 송출량은 같지 않을 수 있으며, 공통으로 적용되는 고정 대역폭 여유 비율은 없습니다.

해상도·비트레이트·코덱의 구체 값과 필요한 여유는 장비 사양·전송 방식·회선 상태에 맞춰 확인해야 하며, 확인할 수 없는 모델은 제조사 또는 설치 업체 안내가 필요합니다. 카메라·녹화기의 IP·포트·네트워크 통신 설정은 임의로 변경하지 마시기 바랍니다.*

카드단말기 승인 오류·통신 실패 — 회선·VAN·단말기 5단계 진단

"방금 전 손님까지 결제됐는데 이 카드만 갑자기 안 긁혀요."

"단말기에 통신 오류라고 뜨는데, 카드 문제예요 인터넷 문제예요?"

이 두 질문은 진단의 출발점이 서로 다릅니다. 그런데 화면만 보면 똑같이 "결제가 안 된다"로 보이죠.

먼저 딱 하나만 가르고 시작하겠습니다.

지금 단말기 화면에 Mastercard·Visa 기준 DE39 승인·거절 응답코드(00·05·51·54·91 등)나 "한도 초과·거래 거절" 같은 문구가 떴나요, 아니면 "통신 오류·응답 없음·회선을 확인하세요"만 떴나요?

이게 갈리면 나머지 진단의 절반이 끝납니다. 앞쪽이면 해당 요청에 대한 승인·거절 응답이 단말기까지 도착한 겁니다.

뒤쪽이면 거래 상태가 불명확할 수 있으므로 재시도보다 직전 거래 조회가 먼저예요.

이 글은 그 "안 됨"을 ① 증상 분리 → ② 물리 회선 → ③ 네트워크 → ④ VAN → ⑤ 단말기 다섯 계층으로 갈라, 사장님이 직접 확인할 선과 VAN사를 불러야 할 선까지 정리한 편집 자료입니다. 확인일은 2026-08-10입니다.

아래 순서는 모든 VAN·단말기에 적용되는 공식 공통 절차가 아닙니다. 인용한 통신·거래상태 자료를 대조해 한 번에 바꾸는 범위를 줄이도록 구성한 우선 배제 순서예요.

실제 메뉴와 연결 시험, 재시작 시점은 사장님 단말기의 VAN사·제조사 안내가 우선합니다.

응답코드와 통신 오류는 어떻게 구분해야 하나?

가장 먼저 짚을 게 이겁니다.

카드 결제는 단말기 혼자 판단하지 않습니다. 단말기가 만든 거래 요청이 VAN을 거쳐 카드사(발급사)까지 갔다가, 승인·거절 결과를 받아 다시 돌아오는 구조예요.

이 왕복 메시지에 쓰이는 규격 가운데 하나가 ISO 8583입니다. ISO 공식 문서는 카드에서 시작된 금융거래 메시지를 매입사와 카드 발급사 사이에서 교환하기 위한 공통 인터페이스를 규정합니다.

• ISO 8583:2023 공식 규격 설명: iso.org

여기서 확인할 것은 Mastercard·Visa 네트워크 자료에 기재된 DE39 승인·거절 응답코드입니다. 결과가 돌아왔다면 그 안에 승인·거절 상태가 담겨 있어요.

아래 두 자리 값은 인용한 Mastercard·Visa 네트워크 자료 기준이며, 국내 VAN·카드사·단말기 표시 코드는 다를 수 있습니다.

• 00 — 승인
• 05 — 구체적 이유가 공개되지 않은 발급사 거절(Do not honor)
• 51 — 잔액 부족 또는 한도 초과
• 54 — 카드 유효기간 만료
• 91 — 발급사 또는 스위치·승인 시스템 이용 불가

• Mastercard 공식 거래 처리 규칙: mastercard.com
• Visa 공식 요청·응답 코드 자료: developer.visa.com

단말기가 표시하는 모든 숫자나 오류번호가 DE39 승인·거절 응답코드인 것은 아닙니다. 단말기 자체 오류번호나 VAN 내부 코드일 수도 있으므로, 코드 출처가 불명확하면 단말기에 표기된 VAN사에 의미를 확인하세요.

무슨 뜻이냐면, Mastercard·Visa 기준 DE39 승인·거절 응답코드(00·05·51·54·91 등)가 표시됐다면 해당 요청에 대한 승인·거절 응답이 단말기까지 도착했다는 겁니다. 따라서 그 거래에서 완전한 무응답형 통신 단절 가능성은 낮습니다.

다만 이것만으로 매장의 회선·VAN·단말기 기능이 전부 정상이라고 확정할 수는 없어요. 간헐적 회선 장애나 카드 리더 문제, 특정 경로의 장애까지 한꺼번에 배제되는 건 아닙니다.

이땐 코드의 범위 안에서 판단해야 합니다. 51은 잔액·한도 부족, 54는 유효기간 만료를 먼저 확인하세요.

05는 다릅니다.

05는 구체적인 거절 이유를 알려 주지 않는 코드라서 한도·정지·만료 중 하나로 확정하면 안 됩니다. 다른 카드가 정상 승인되더라도, 첫 카드 또는 해당 카드의 발급사 승인 판단 축을 우선 확인할 근거가 될 뿐이에요.

첫 카드의 정확한 거절 사유는 카드 소지자가 발급사에 확인해야 합니다.

다만 91번은 조금 다릅니다. 91은 발급사 또는 스위치·승인 시스템 이용 불가를 나타내는 DE39 응답코드가 도착한 상태입니다. VAN사 안내에 따라 재시도 시점을 확인하세요.

반면 실제 통신 타임아웃이나 응답 없음 뒤에는 화면에 결과가 안 왔어도 거래 처리가 계속됐을 수 있습니다. 같은 금액을 다시 승인하기 전에 단말기의 거래조회·직전 거래 메뉴 또는 VAN사 고객센터로 승인 여부를 먼저 확인하세요.

승인되지 않았다는 확인을 받은 뒤 VAN사 안내에 따라 재시도해야 중복승인을 피할 수 있습니다.

• 타임아웃 뒤 거래가 계속 처리될 수 있다는 안내: docs.adyen.com
• 응답을 받지 못한 거래의 상태 확인 절차: docs.adyen.com

문제는 화면에 아무 사유 없이 "통신 오류"만 뜰 때입니다. 여기서부터가 진짜 진단이에요.

통신 오류만 뜬다면 어디부터 확인해야 하나?

통신 오류만으로 단말기 고장이라고 바로 단정해서는 안 됩니다.

카드 결제 신호는 단말기 → 회선(케이블·전화선·인터넷) → 공유기·IP 또는 통신 경로 → VAN 호스트 → 카드사를 거칩니다. 이 중 한 구간이 끊기면 승인 요청이나 응답이 정상적으로 오가지 못할 수 있습니다.

이 판정표에서는 물리 회선부터 네트워크·VAN·단말기 순으로 확인합니다. 여러 자료를 대조해 변경 범위를 줄이도록 구성한 편집상 우선순위일 뿐, 모든 단말기의 공식 고정 순서는 아닙니다.

다만 통신 오류 직전 결제를 이미 시도했다면, 점검이나 재시도에 앞서 VAN 거래조회로 그 거래의 승인 여부부터 확인하세요.

한 번에 하나씩만 확인하세요. 여러 항목을 동시에 변경하면 어느 변경이 영향을 줬는지 구분하기 어려워집니다.

물리 회선 — 연결 방식부터 확인하면 빠르게 갈린다

두 번째 계층입니다. 이 단계에서 회선 전체 장애와 단말기별 장애를 1차로 분리할 수 있습니다.

카드단말기 회선에는 유선(LAN), 매장 Wi-Fi, 단말기 내장 LTE(무선) 외에 전화선을 이용하는 레거시 유선 방식도 있습니다. 사장님 단말기가 어느 쪽인지부터 확인하세요.

• LAN 단말기라면: 단말기 뒤 LAN 케이블이 빠졌는지, 공유기 포트 LED가 켜졌는지 봅니다.
• Wi-Fi 단말기라면: 매장 와이파이 신호가 잡히는지, 비밀번호가 바뀌진 않았는지 봅니다.
• LTE 단말기라면: 안테나 표시(신호 막대)가 떠 있는지, 특정 자리에서만 안 되는지 봅니다.
• 전화선 단말기라면: 전화선이 지정 포트에 제대로 연결됐는지와 회선 상태를 확인합니다. 연결에 이상이 없는데도 통신 오류가 계속되면 임의로 통신값을 바꾸지 말고 VAN사로 이관하세요.

LAN·Wi-Fi 단말기에서 가장 빠른 판정법은 이겁니다.

동일한 매장 네트워크를 쓰는 다른 기기(POS·주문 태블릿)로 인터넷이 되는지 확인하세요. 다른 기기도 다 안 되면 매장 전체 회선·인터넷 장애를 우선 확인할 근거가 됩니다.

다른 기기는 되는데 단말기만 안 된다면 매장 전체 인터넷 장애 가능성은 낮아집니다. 그래도 다른 VLAN·Wi-Fi·방화벽·DNS·특정 목적지 경로가 다를 수 있으므로, 단말기 경로까지 정상이라고 확정하진 마세요.

정전이 있었다면 회선 장비가 아직 다 안 올라왔을 수 있습니다. 이 경우는 정전 후 POS·프린터 복구 안 됨 — 15분 3단계 점검표의 전원 복구 순서를 먼저 밟은 뒤에 이 진단으로 돌아오시는 게 맞습니다.

네트워크 — 인터넷은 되는데 단말기만 안 될 때

세 번째 계층입니다. 다른 기기는 인터넷이 되는데 카드단말기만 안 될 때 여기를 봅니다.

이 구간은 케이블이 아니라 주소와 경로의 문제예요. 단말기가 IP를 할당받지 못했거나 주소가 충돌했거나, 게이트웨이·DNS가 잘못됐거나, 고정 IP 설정이 네트워크 구성과 맞지 않거나, 방화벽·포트가 VAN 호스트로 가는 길을 막은 경우입니다.

일반적인 TCP/IP 통신 점검도 물리 연결과 IP 설정, 상대 호스트까지의 도달 여부를 나눠 확인하도록 안내합니다.

• TCP/IP 통신 문제 해결 가이드(Microsoft): learn.microsoft.com

사장님이 직접 해볼 수 있는 건 여기까지입니다.

• 단말기의 유선 또는 Wi-Fi 네트워크 연결 상태를 확인하고 다시 연결합니다.
• 유선이면 케이블을 공유기의 다른 포트에 꽂아 봅니다.
• 공유기를 재부팅해야 한다면 다른 매장 장비에 미칠 영향을 먼저 확인하고, 해당 장비의 안내에 따라 진행합니다.

DHCP 환경에서는 IP 미할당·주소 충돌·잘못된 게이트웨이 또는 DNS·고정 IP 설정 불일치가 있는지 확인해야 합니다. 주소가 바뀌었다는 사실만으로 VAN 통신 장애가 확정되는 건 아닙니다.

같은 원리를 프린터에서 다룬 주방 프린터 IP 바뀜 — 고정 IP 설정 3단계 (DHCP 원인)는 IP 설정을 이해하는 참고 자료로만 보세요. 카드단말기의 실제 설정값은 VAN사 확인이 우선입니다.

다만 단말기의 IP·포트·VAN 호스트 주소 설정은 사장님이 임의로 건드리지 마세요. 이 값들은 설치 환경과 VAN사 구성에 따라 달라, 잘못 바꾸면 멀쩡하던 단말기까지 못 쓰게 됩니다.

여기까지 했는데도 통신 오류가 그대로면, 매장 내부 점검만으로 원인을 확정하지 말고 VAN 상태를 확인할 차례입니다.

VAN 호스트 장애일 때 — 사장님이 고칠 수 없는 선

네 번째 계층입니다. 그리고 여기가 이 판정표에서 사장님 점검을 VAN사 확인으로 넘기는 지점이에요.

VAN(부가통신망)은 단말기와 카드사 사이에서 승인 요청을 중계하는 사업자입니다. 앞의 매장 회선·네트워크 점검 뒤에도 통신 오류가 난다면, VAN사 호스트 장애나 특정 카드사 경로 문제, 가맹점·단말기 등록 상태 문제를 확인해야 합니다.

• VAN 서비스 개요(한국신용카드결제): koces.co.kr

이건 매장에서 확인할 방법이 제한적입니다. 대신 이렇게 좁혀 보세요.

• 우리 매장만 안 되나, 주변 가게도 같은 시간에 안 되나 — 같은 VAN을 쓰는 주변 가게에서도 같은 증상이 확인되면 VAN·카드사 쪽 상태를 우선 확인할 근거가 됩니다.
• Mastercard·Visa 기준 DE39 응답코드 91이 표시됐다면 발급사 또는 스위치·승인 시스템의 이용 불가 상태와 재시도 시점을 VAN사에 확인해야 합니다.
• 무응답·통신 타임아웃으로 직전 거래 결과가 불명확하다면 재시도하지 말고 VAN 거래조회나 고객센터로 승인 여부부터 확인합니다.

이 단계에서 사장님이 할 최선의 행동은 단말기 초기화가 아니라 VAN사 고객센터에 연락하는 겁니다. 단말기 하단·계약서·스티커에 VAN사 이름과 번호가 있어요.

전화할 때 이 세 가지를 미리 챙겨 두시면 통화가 훨씬 빨라집니다.

• 화면에 뜬 오류 문구 또는 코드 그대로
• 앞 단계에서 확인한 것(다른 기기 인터넷 여부, 네트워크 재연결 여부)
• 단말기 모델명과 가맹점 번호

코드가 DE39 승인·거절 응답인지 단말기 자체 오류번호인지 불명확하다면 그 점도 함께 확인하세요.

여기에 직전 거래 시각·금액·카드 끝자리와 승인번호 표시 여부까지 준비하시면 거래조회가 필요한 상황을 설명하기 좋습니다. 카드번호 전체나 비밀번호는 전달하지 마세요.

VAN사마다 거래조회 경로가 다릅니다. 단말기의 거래조회·직전 거래 메뉴를 쓰는 곳도 있고, 고객센터에서 가맹점 번호와 거래 정보를 확인하는 곳도 있어요.

VAN사 내부 설정·재등록 절차는 사업자·단말기마다 달라, 여기서 특정 메뉴 경로를 단정하지 않겠습니다. 그건 VAN사 안내를 그대로 따르시는 게 정확합니다.

단말기 자체 문제 — 이 판정표의 마지막 확인 계층

다섯 번째 계층입니다. 이 판정표에서는 앞의 회선·네트워크 상태를 기록하고 VAN사에 호스트·등록 상태를 확인한 뒤 단말기 자체 문제를 살펴봅니다.

단말기 고장에도 결이 있어요.

• 통신 모듈 문제 — 같은 회선의 다른 장비는 작동하고 VAN 상태에도 이상이 없는데 이 단말기만 계속 통신 오류. 다른 단말기가 있으면 VAN사 안내에 따라 같은 조건에서 대조합니다.
• 카드 리더(IC/MSR) 문제 — 통신 오류가 아니라 카드를 읽지 못하는 증상. IC 삽입은 되는데 긁기(MSR)만 안 되거나 그 반대인지 구분합니다.
• 소프트웨어 멈춤 가능성 — VAN사나 제조사 안내에 따라 전원을 완전히 차단한 뒤 다시 켜 확인합니다.

처리 결과가 불명확한 직전 거래를 먼저 조회한 뒤, 재시작 시점은 VAN사·제조사 안내를 따르세요. 이 판정표에서는 원인 구간을 보존하기 위해 회선·네트워크 상태를 기록한 다음 재시작하도록 배치했습니다.

재시작이 거래 상태 확인을 대신해 주지는 않습니다.

리더가 특정 카드만 못 읽는 거라면 통신 문제가 아닙니다. 여러 카드로 대조해서 "모든 카드가 안 되나, 이 카드만 안 되나"부터 가르세요.

같은 '결제 안 됨'을 5계층으로 나눈 판정표

화면·상황	우선 점검 계층	먼저 확인할 것	사장님이 직접?
Mastercard·Visa 기준 DE39 응답코드 05가 표시됨	카드·발급사 승인 판단 축	구체적 사유는 확정하지 말고 다른 결제수단 대조, 카드 소지자가 발급사 확인	일부 O
Mastercard·Visa 기준 DE39 응답코드 51·54가 표시됨	카드 축	51은 잔액·한도 부족, 54는 유효기간 만료 확인	O
Mastercard·Visa 기준 DE39 응답코드 91이 표시됨	발급사·스위치·승인 시스템 축	VAN사에 상태와 재시도 시점 확인	VAN사 확인
코드 출처가 불명확하거나 단말기 자체 오류번호로 보임	VAN·단말기 축	코드 의미를 단말기에 표기된 VAN사에 확인	VAN사 확인
"통신 오류"만 뜨고 다른 기기도 인터넷 안 됨	② 물리 회선	케이블·공유기 LED·인터넷 회선 자체	O
전화선 단말기에 "통신 오류"만 뜸	② 물리 회선	전화선 연결·회선 상태 확인 후 계속되면 VAN사 이관	일부 O
다른 기기는 되는데 단말기만 통신 오류	③ 네트워크	네트워크 재연결, 다른 포트, IP·게이트웨이·DNS 상태	일부 O
매장 회선·네트워크 점검 뒤에도 통신 오류	④ VAN	직전 거래 조회, VAN 호스트·가맹점 등록 상태 문의	VAN사
같은 VAN을 쓰는 주변 가게도 같은 시간대 안 됨	④ VAN·카드사 경로	VAN사 공지·고객센터 확인	VAN사
VAN 확인까지 마쳤는데 이 단말기만 통신 오류	⑤ 단말기	직전 거래 조회와 상태 기록 후 VAN사 안내에 따른 재시작·다른 단말기 대조	일부 O
통신 오류가 아니라 특정 카드만 안 읽힘	⑤ 리더(IC/MSR)	여러 카드로 대조, IC/긁기 구분	O

이 표는 원인을 확정하는 표가 아닙니다. 어느 계층부터 볼지 정하는 편집상 판정표예요.

두 계층이 겹칠 수도 있습니다. 그러니 한 번에 한 계층만 바꾸고 확인하세요.

실제 점검·재시작 순서는 VAN사·제조사 안내가 우선합니다. 무응답·통신 타임아웃으로 결제 결과가 불명확했다면 다시 승인하기 전에 VAN 거래조회나 고객센터로 직전 거래 상태부터 확인하시는 편이 안전합니다.

매장에서 바로 쓰는 기록표 — 안전 분기와 회선 비교

지금까지 다룬 5계층 진단을 실제로 쓰려면, 화면에 뜬 상태부터 갈라야 합니다. 아래 도식은 그 첫 갈림길만 따로 떼어 정리한 것입니다.

회선 방식에 따라 확인할 지점이 달라지므로, 매장 단말기가 어느 경로를 쓰는지도 미리 정리해 두면 좋습니다.

진단 도중에는 상태를 눈으로만 기억하지 말고 아래 표에 그때그때 적어 두세요. VAN사에 전화할 때 이 표 그대로 불러 주면 설명이 훨씬 빨라집니다.

항목	기입란	어디서 확인하나
화면에 뜬 오류 문구·코드		예시) "91" 또는 "통신 오류" — 단말기 화면 문구를 그대로 옮겨 적으세요
발생 시각		예시) 14:32 — 단말기 화면 또는 POS 로그의 시각 표시
시도한 금액		결제 화면에 입력했던 금액
직전 거래 상태		단말기 거래조회·직전 거래 메뉴 또는 VAN 고객센터 확인 결과(승인/미승인/확인 중)
회선 방식		LAN / Wi-Fi / LTE / 전화선 중 해당 단말기 방식
다른 기기 인터넷 여부		같은 매장 네트워크의 다른 기기로 확인

이 표는 원인을 대신 판정해 주지 않습니다. 다만 VAN사와 통화할 때 "언제, 얼마를, 어떤 문구로, 직전 거래는 어떻게 됐는지"를 한 번에 전달할 수 있게 정리해 두는 용도예요.

통신 오류가 났다면 이 판정표를 어떻게 적용해야 하나?

카드가 안 긁힐 때 가장 피해야 할 건, 원인을 모른 채 단말기를 초기화하거나 확인 없이 같은 결제를 다시 승인하는 일입니다.

첫 동작은 딱 하나예요. 화면에 뜬 게 Mastercard·Visa 기준 DE39 승인·거절 응답인지, 단말기 자체 오류번호인지, 무응답형 통신 오류인지 읽는 것. DE39 승인·거절 응답코드(00·05·51·54·91 등)가 표시됐다면 해당 요청의 응답이 단말기까지 도착한 것이므로, 그 거래에서 완전한 무응답형 통신 단절 가능성은 낮습니다.

단말기 자체 오류번호나 VAN 내부 코드는 같은 의미가 아닐 수 있습니다. 코드 출처가 불명확하면 단말기에 표기된 VAN사에 먼저 확인하세요.

05는 구체적 이유가 공개되지 않은 발급사 거절이고, 51은 잔액·한도 부족, 54는 만료입니다. 다른 카드의 승인만으로 첫 카드의 정확한 거절 원인을 확정하진 마세요.

91은 발급사 또는 스위치·승인 시스템 이용 불가를 나타내는 DE39 응답코드가 도착한 상태입니다. VAN사 안내에 따라 재시도 시점을 확인하세요.

실제 통신 타임아웃이나 응답 없음처럼 거래 결과가 불명확하다면 VAN 거래조회·직전 거래 확인이 재시도보다 먼저입니다. 이미 승인된 거래가 아닌지 확인한 뒤 VAN사 안내에 따라 다음 결제를 진행하세요.

통신 오류만 떴다면 이 판정표에서는 물리 회선부터 범위를 좁힙니다. 먼저 LAN·Wi-Fi·LTE·전화선 중 회선 방식을 확인하세요.

LAN·Wi-Fi라면 동일 네트워크의 다른 기기로 인터넷이 되나 → 단말기 네트워크 연결과 IP 경로는 맞나 → VAN 호스트·등록 상태는 정상인가 → 단말기 자체 문제도 확인할 것인가로 이어집니다. 전화선 단말기라면 전화선 연결과 회선 상태를 확인한 뒤 VAN사로 이관하세요.

다만 이 순서는 모든 VAN·단말기의 공식 고정 절차가 아닙니다. 실제 연결 시험과 재시작 시점은 사장님이 사용하는 VAN사·제조사 안내를 우선하고, 이 표는 한 번에 바꾸는 범위를 줄이는 용도로 쓰시면 됩니다.

한 계층씩 갈라 배제하면, 똑같은 "결제 안 됨"이라도 그 안에 섞인 서로 다른 원인을 하나씩 걷어낼 수 있습니다. 그리고 사장님이 직접 확인할 선과 VAN사를 불러야 할 선도 그때 분명해집니다.

---

*이 글은 ISO 공식 ISO 8583 규격 설명, Mastercard·Visa 공식 응답코드 자료, Microsoft TCP/IP 통신 문제 해결 가이드, VAN 서비스 공개 안내와 결제 타임아웃 거래상태 확인 자료를 사장님 관점에서 정리·대조한 편집 자료입니다(확인일 2026-08-10). 본문의 5계층 순서는 모든 VAN·단말기의 공식 공통 절차가 아니라 변경 범위를 줄이기 위해 구성한 우선 배제 모델이며, 실제 메뉴·연결 시험·재시작 시점은 VAN사와 제조사 안내가 우선합니다.

인용한 두 자리 응답코드 값은 Mastercard·Visa 네트워크 자료 기준이며, VAN사·카드사·단말기 제조사·통신사 구성에 따라 화면 문구, 응답코드 표시 방식, 거래조회 메뉴와 재등록 절차가 다를 수 있습니다. 단말기 자체 오류번호나 VAN 내부 코드는 DE39 승인·거절 응답코드와 같은 의미가 아닐 수 있으므로 출처가 불명확하면 단말기에 표기된 VAN사에 확인하시기 바랍니다.

실제 조치 전에 단말기에 표기된 VAN사 안내와 계약 정보를 함께 확인하시기 바랍니다. 무응답·통신 타임아웃으로 처리 결과가 불명확한 거래는 재시도 전에 VAN 거래조회나 고객센터로 승인 여부를 확인하고, 카드단말기의 IP·포트·VAN 호스트 설정은 임의로 변경하지 마시기 바랍니다.*

함께 보면 좋은 글

• 삼성월렛 인증 후 NFC·MST 단말기 무반응 점검법