생각보다 많은 장비가 이메일 외에는 어떤 통신 방식도 지원하지 않습니다. 백업 어플라이언스, 네트워크 모니터링 장비, 건물 관리 시스템, 프린터, 산업용 제어기, 구형 계측기까지 모두 설계 당시 사용할 수 있던 연동 방식이 SMTP였기 때문에 이메일로 경고를 보냅니다. 장치마다 사서함을 하나씩 두면 이 골칫거리를 관리 가능한 체계로 바꿀 수 있습니다.
많은 사업장에서는 모든 장비가 하나의 공용 주소로 경고를 보내게 합니다. 장치 40대 중 어느 장치가 문제를 알리는지 찾아야 하기 전까지는 이 방식도 잘 작동합니다.
공용 주소 하나로는 부족한 이유
모든 장비의 수신 주소를 alerts@로 지정하는 것이 가장 먼저 떠오르는 방법이지만, 예상 가능한 방식으로 관리가 어려워집니다.
제조사마다 형식이 달라 이메일 제목과 보낸 사람 이름이 제각각입니다. 나중에 메시지를 분류하려면 각 장치가 내보내는 문구에 맞춰 규칙을 작성해야 합니다. 펌웨어 업데이트로 예고 없이 문구가 바뀌면 이 규칙은 작동하지 않습니다.
메시지 양이 많아지면 문제는 더 커집니다. 상태가 계속 오락가락하는 모니터링 장비나 실패한 작업을 반복해서 시도하는 어플라이언스처럼 메시지를 지나치게 많이 보내는 장치 하나가 수백 건의 이메일을 발생시켜 다른 경고를 묻어버릴 수 있습니다. 공용 주소를 사용하면 전체 메시지를 받는 규칙까지 끄지 않고 특정 발신 장치 하나만 음소거할 방법이 없습니다.
발신 장치를 구분하기도 어려워집니다. 장치마다 사서함을 두면 메시지를 한 글자도 읽기 전에 수신 주소만으로 발신 장치를 식별할 수 있습니다.
내용을 추측할 필요가 없는 라우팅
장치별 사서함의 가장 큰 장점은 내용을 해석해 분류하는 대신 구조 자체로 메시지를 라우팅할 수 있다는 점입니다.
내용 분석 없이 식별. ups-basement@로 도착한 메일은 지하실 UPS에서 온 것입니다. 규칙도, 제목 일치 조건도 필요 없으며 제조사가 템플릿을 바꿔도 혼동이 생기지 않습니다.
장치별로 독립적인 처리. 장치마다 목적지가 따로 있으므로 다른 장치에 영향을 주지 않고 한 장치만 음소거하거나 전송 속도를 제한하거나 무시할 수 있습니다.
깔끔한 장비 폐기 절차. 장비 한 대의 운영을 종료할 때 사서함 하나만 삭제하면 됩니다. 필터를 수정한 뒤 다른 장치가 그 필터에 의존하지 않았기를 바랄 필요가 없습니다.
발신 장치별 스크립트 처리. 특정 장치의 사서함을 읽는 스크립트는 어떤 형식의 메시지가 들어올지 정확히 알 수 있습니다. 여러 장치의 메시지가 섞인 환경에서는 얻기 어려운 안정적인 구문 분석이 가능합니다. 이 방식은 이메일 인제스트에서 설명합니다.
비용 문제
장치별 사서함은 사서함마다 사용자 요금을 부과하지 않을 때만 합리적입니다. 이 방식이 흔하지 않은 이유도 바로 비용입니다.
사용자당 7달러라면 장치 40대의 시스템 경고를 받는 데만 연간 3,360달러가 듭니다. 합리적인 담당자라면 승인하기 어려운 금액입니다. 사서함 수를 요금제 등급별로 제한하는 방식에서는 장치 사서함 40개를 만들어도 현재 요금제 외에 추가 비용이 들지 않습니다. Pro는 도메인당 300개, Agency는 1,000개를 지원합니다.
대신 장치 사서함은 공용 저장 공간을 사용합니다. 장비는 메시지를 계속 보내므로 이메일도 끊임없이 쌓입니다. 이 환경에서는 장치별 사서함 용량 제한과 보존 규칙이 선택 사항이 아니라 필수입니다. 그 이유는 사서함 저장 공간 할당량에서 자세히 설명합니다.
대부분은 사서함보다 별칭이 적합합니다
솔직히 말하면 많은 사업장에는 장치별 사서함보다 장치별 이메일 별칭이 더 적합합니다.
장치별 메시지를 따로 처리하는 시스템이 없고 발신 장치만 구분하면 된다면, 별칭을 이용해 관리할 개별 사서함이나 별도 저장 공간 없이도 식별용 주소를 만들 수 있습니다. 모든 메일은 한곳에 도착하지만 수신 주소를 보면 어느 장치가 보냈는지 알 수 있습니다.
시스템이 각 장치의 메일을 독립적으로 처리하거나, 장치 담당 팀이 달라 서로의 경고를 볼 수 없어야 하거나, 장치별 보존 기간이 다르다면 실제 사서함을 선택하세요. 한 사람이 모든 경고를 읽고 어떤 장치가 무엇을 보냈는지만 알면 된다면 별칭이 적합합니다.
사서함별 별칭 한도는 Starter 30개, Pro 50개, Agency 100개입니다. 대부분의 장비 환경은 별도 사서함을 대량으로 만들지 않고도 이 한도 안에서 운영할 수 있습니다.
장치 설정하기
장치별 사서함을 운영할 때 실무에서 걸림돌이 되는 부분은 장비 측 설정입니다. 도입을 결정하기 전에 이 점을 알아두는 것이 좋습니다.
최신 메일 제출 기능을 어느 정도까지 구현했는지는 제조사마다 크게 다르며, 장비의 연식에 따라 작업량도 달라집니다. 최근 5년 안에 구입한 장비를 사용하는 사업장이라면 거의 모든 장치가 별문제 없이 작동합니다. 20년 된 건물 관리 시스템이 있는 곳은 그렇지 않습니다. 이런 경우 아래에서 설명하는 릴레이를 사용하는 것이 일반적인 해결책이지 예외적인 방법이 아닙니다.
구형 장치는 RFC 6409에 정의된 인증 기반 메일 제출 방식 대신 25번 포트의 인증 없는 SMTP만 지원하거나, 오래전에 폐기된 인증 방식을 사용하는 경우가 많습니다. TLS를 전혀 지원하지 않는 장치도 있습니다. 이런 장비는 최신 메일 서비스로 직접 발송할 수 없습니다. 일반적인 해결책은 네트워크에 로컬 릴레이를 두어 장치가 보낸 인증 없는 메시지를 받은 뒤 적절히 인증해 전달하는 것입니다.
최신 메일 제출 방식을 지원하는 장치라면 로그인 정보를 공유하지 말고 장치마다 별도 계정을 부여하세요. 완전히 신뢰할 수 없는 네트워크 구간에 있는 장치가 공용 로그인 정보를 보관하는 위험을 장치별 계정으로 없앨 수 있습니다. 장비 한 대의 비밀번호를 변경해도 다른 장치에는 영향을 주지 않습니다.
장치에 내장된 테스트 버튼을 누르는 데 그치지 말고 실제 경고 조건을 발생시켜 테스트하세요. 제조사의 테스트 메시지는 실제 경고와 다른 코드 경로를 사용하는 경우가 많아서, 테스트는 성공해도 실제 경고는 전송되지 않을 수 있습니다.
전체 장비를 쉽게 파악할 수 있는 장치별 사서함 이름
이메일 주소가 유일한 표식이므로 목록을 찾아보지 않아도 위치와 장비 종류를 알 수 있게 이름을 지어야 합니다.
ups-basement@나 nas-office2@ 같은 주소는 2년 뒤에 봐도 의미를 이해할 수 있지만 device7@은 그렇지 않습니다. 이미 자산 관리 대장이 있다면 별도의 명명 체계를 새로 만드는 것보다 기존 식별자를 사용하는 편이 낫습니다. 병행 체계는 1년도 지나지 않아 기존 대장과 어긋날 수 있습니다.
도착한 경고에 대응하기
장치별 사서함은 들어온 메시지에 누군가 또는 어떤 시스템이 대응할 때만 유용합니다. 아무도 열지 않는 사서함만 늘어나는 것이 대표적인 실패 사례입니다.
장치별로 경고를 사람이 읽을지, 스크립트가 처리할지, 또는 문제가 생긴 날 과거 기록을 확인할 수 있도록 보관만 할지 정하세요. 세 가지 모두 타당한 선택입니다. 결정을 미뤄두는 것은 타당하지 않습니다. 읽지 않는 장치 메일은 제대로 모니터링하고 있다는 잘못된 안도감을 주기 때문입니다.
정말 긴급한 상황이라면 이메일은 적합한 채널이 아니며 애초부터 적합했던 적도 없습니다. 누군가를 깨워야 할 정도로 긴급한 장비는 비상 호출 시스템에 경고를 보내고, 사서함은 경보 전달 수단이 아니라 기록 보관용으로 사용해야 합니다.
