엣지 컴퓨팅(Edge Computing): 클라우드의 한계를 넘어 분산 인프라의 새로운 패러다임

1. 클라우드만 믿고 시작했던 첫 프로젝트

저는 2025년 3월, 물류 창고에 설치된 카메라 48대의 영상을 클라우드로 보내 불량 상자를 판별하는 프로젝트를 맡았습니다. 처음에는 서버를 직접 관리하지 않아도 되고 확장도 편하다는 이유로 모든 영상을 서울 리전에 전송했습니다. 개발 초반에는 화면이 매끄럽게 보였지만, 카메라 수를 80대로 늘린 뒤부터 판정 결과가 평균 1.8초씩 늦어졌습니다. 작업자는 이미 상자를 다음 공정으로 넘긴 뒤에야 불량 알림을 받았고, 저는 그때 엣지가 단순한 유행어가 아니라 현장 지연을 줄이는 설계 방식이라는 점을 체감했습니다.
당시 창고와 클라우드 사이의 왕복 지연은 평소 70~90ms 정도였지만, 오전 9시처럼 작업량이 몰리는 시간에는 240ms까지 튀었습니다. 영상 한 대가 초당 약 4MB를 전송했고, 48대가 동시에 움직이면 내부망과 외부 회선 모두 부담을 받았습니다. 처음에는 클라우드 서버 사양을 키우는 데 180만 원가량을 추가로 썼지만 판정 지연은 거의 줄지 않았습니다. 연산량보다 영상이 오가는 길 자체가 병목이라는 사실을 놓친 셈이었습니다. 이 실패 뒤에 저는 카메라 옆에 소형 GPU 서버를 두고 1차 판정을 현장에서 처리하는 구조로 방향을 바꿨습니다.

2. 엣지 장비를 붙인 뒤 드러난 현실

2025년 5월, 저는 창고 네트워크실에 소비전력 120W급 엣지 서버 두 대를 설치했습니다. 카메라 영상 전체를 보내는 대신 서버가 0.5초 단위로 프레임을 읽고, 불량 가능성이 0.82 이상인 장면과 시간 정보만 클라우드에 올리도록 만들었습니다. 전송량은 하루 평균 410GB에서 36GB로 내려갔고, 현장 알림은 평균 1.8초에서 180ms 안팎으로 짧아졌습니다. 작업자들이 체감할 정도로 반응이 빨라졌지만, 장비를 현장에 둔다고 곧바로 운영이 편해지는 건 아니었습니다. 오히려 제가 직접 챙겨야 할 고장 지점이 늘어났습니다.
가장 먼저 겪은 문제는 저장장치였습니다. 설치 후 11일째 되던 5월 22일, 엣지 서버 한 대가 새벽에 재부팅을 반복했습니다. 로그를 확인하니 영상 임시 파일을 7일 동안 지우지 않아 디스크 사용량이 96%까지 올라간 상태였습니다. 저는 클라우드처럼 저장 공간이 자동으로 늘어날 거라 착각했고, 오래된 파일 삭제 정책과 디스크 경고를 넣지 않았습니다. 이후 24시간이 지나면 원본 프레임을 삭제하고, 저장 공간이 75%를 넘으면 관리자에게 문자 알림을 보내도록 바꿨습니다. 장비 가격보다 로그, 백업, 교체 절차를 먼저 설계해야 한다는 교훈을 얻은 사건이었습니다.

3. 인터넷이 끊겼을 때 비로소 보인 장점과 한계

같은 해 6월에는 창고 외부 회선이 공사 중 끊기는 일이 있었습니다. 장애는 오전 10시 14분에 시작해 27분 동안 이어졌고, 클라우드 대시보드와 원격 로그 수집은 멈췄습니다. 다행히 현장의 엣지 서버는 카메라 영상을 계속 판독했고, 컨베이어 정지 신호도 정상적으로 보냈습니다. 연결이 복구된 뒤 서버에 쌓인 이벤트 163건이 순서대로 클라우드에 올라왔습니다. 저는 이때 엣지의 장점이 인터넷이 빠를 때만 드러나는 게 아니라, 통신이 끊겨도 현장 기능을 유지하는 데 있다는 사실을 경험으로 배웠습니다.
다만 오프라인 동작에도 조건이 붙었습니다. 당시 서버의 시계가 4분 36초 늦어져 복구 뒤 올라온 이벤트 순서가 실제 작업 기록과 맞지 않았습니다. 원인은 시간이 동기화되지 않은 상태에서 내부 시계만 계속 사용했기 때문이었습니다. 저는 이후 네트워크가 살아 있을 때 시간을 맞추고, 연결이 끊기면 마지막 동기화 시각과 경과 시간을 함께 기록하도록 수정했습니다. 엣지 장비를 독립적으로 운영한다는 말은 단순히 인터넷 선을 뽑아도 돌아간다는 뜻이 아니었습니다. 전원, 시간, 저장 공간, 모델 파일까지 현장에서 관리하는 운영 체계가 함께 있어야 했습니다.

4. 엣지 AI 모델 교체에서 겪은 실수

7월에는 불량 판별 모델의 정확도를 높이려고 새 모델을 배포했습니다. 테스트 환경에서는 오탐률이 4.1%에서 2.7%로 낮아졌지만, 현장에 적용한 첫날 정상 상자를 불량으로 판단하는 비율이 오히려 9.4%까지 올라갔습니다. 창고 조명이 오후에 어두워지고, 카메라 렌즈에 미세한 먼지가 붙어 있었기 때문입니다. 저는 학습용 이미지가 깨끗한 상태에 치우쳤다는 점을 뒤늦게 발견했습니다. 새 모델을 모든 장비에 한꺼번에 적용한 탓에 작업 지연도 발생했고, 결국 이전 모델로 되돌린 뒤 시간대별 조명과 먼지가 포함된 이미지 2만 3천 장을 추가로 모았습니다.
그 뒤부터는 모델 파일을 교체할 때 한 대의 서버에서만 48시간 시험 운영을 거쳤습니다. 판정 정확도만 보지 않고 응답 시간, 메모리 사용량, 카메라별 오탐률을 함께 기록했습니다. 새 모델이 평균 92ms 안에 결과를 내더라도 특정 카메라에서 300ms 이상 걸리면 배포를 미뤘습니다. 클라우드에서는 중앙 서버 하나를 되돌리면 끝났지만, 엣지에서는 장비마다 모델 버전과 설정이 달라질 수 있었습니다. 저는 버전 번호를 화면에 표시하고, 실패하면 이전 모델로 자동 복귀하는 기능을 넣은 뒤에야 배포 불안을 조금 덜었습니다.

5. 제가 지금 엣지를 선택하는 기준

프로젝트를 몇 달 운영한 뒤 저는 모든 처리를 엣지로 옮기지는 않았습니다. 카메라 영상의 즉시 판정과 컨베이어 제어는 현장 서버에 두고, 여러 날의 통계와 모델 학습은 클라우드에 남겼습니다. 현장에서는 10분 동안 통신이 끊겨도 작업이 멈추지 않아야 하는 기능만 따로 분리했고, 원본 영상은 필요한 장면만 보관했습니다. 이렇게 나누자 월간 전송 비용은 약 63만 원에서 21만 원으로 줄었고, 장애가 발생했을 때 원인을 좁히는 시간도 평균 2시간에서 35분으로 감소했습니다. 클라우드와 엣지 중 하나를 고르는 문제가 아니라, 어느 위치에서 어떤 판단을 내려야 하는지 나누는 작업에 가까웠습니다.
제가 새 현장에 엣지 컴퓨팅을 적용할 때 먼저 적는 항목은 네 가지입니다. 허용 가능한 지연 시간, 네트워크가 끊겼을 때 유지해야 할 기능, 하루 원본 데이터의 양, 장비를 점검할 담당자입니다. 이 네 가지를 적지 않고 장비부터 구매하면 초기 비용만 늘고 운영자는 장애 때마다 현장으로 달려가야 합니다. 반대로 지연 요구가 낮고 원본 보관이 주된 목적이라면 굳이 엣지 서버를 둘 이유가 줄어듭니다. 제가 겪은 시행착오는 기술 선택보다 운영 범위를 먼저 정해야 한다는 쪽에 가까웠습니다.
엣지 컴퓨팅을 검토하는 분이라면 작은 구간부터 시험해 보시길 권합니다. 저는 처음부터 창고 전체를 바꾸지 않고 카메라 4대와 서버 1대로 2주간 측정했더라면 180만 원의 불필요한 서버 증설 비용과 모델 배포 사고를 피했을 것 같습니다. 지연 시간과 전송량만 기록하지 말고, 디스크 부족·전원 장애·시간 오차·원격 업데이트 실패까지 일부러 점검해 보세요. 제가 현장에서 얻은 가장 실용적인 교훈은 엣지를 설치하는 순간 문제가 사라지는 게 아니라, 현장 가까이에 새로운 운영 책임이 생긴다는 사실입니다. 그 책임까지 감당할 준비가 된 범위에서 작게 시작하는 편이 안전합니다.