EDR, 기업용 백신과 다른 엔드포인트 보안의 시작

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

직원이 받은 견적서 파일 하나가 악성코드인지 아닌지 판단해야 하는 순간, 담당자는 흔히 기업용 백신 화면부터 확인합니다. 그런데 검사 결과가 ‘정상’이라면 정말 안심해도 될까요? 공격자는 이미 알려진 악성 파일 대신 정상 프로그램을 악용하거나, 파일을 거의 남기지 않는 방식으로 움직일 수 있습니다.

이때 필요한 도구가 EDR(Endpoint Detection and Response)입니다. 이름은 어렵지만 핵심은 단순합니다. PC와 서버에서 벌어지는 행동을 지속적으로 기록하고, 의심스러운 흐름을 찾아 조사와 대응을 돕는 엔드포인트 보안 솔루션입니다. 정보기술의 넓은 개념이 낯설다면 지식백과의 IT 용어 설명을 먼저 읽어도 좋습니다.

EDR이라는 이름부터 쉽게 풀어보기

Endpoint, Detection, Response가 뜻하는 것

Endpoint는 업무 데이터가 실제로 열리고 처리되는 끝단 장치를 말합니다. 직원의 노트북과 데스크톱은 물론이고 업무용 서버, 가상 데스크톱, 경우에 따라 클라우드 워크로드도 포함됩니다. 이메일과 협업 도구가 클라우드로 이동했어도 로그인 정보와 첨부 파일을 다루는 PC는 여전히 공격자가 노리는 주요 통로입니다.

Detection은 단순히 특정 바이러스 파일을 찾는 작업보다 범위가 넓습니다. 예를 들어 문서 프로그램이 명령어 실행 도구를 호출하고, 그 도구가 외부 서버에 접속한 뒤 시작 프로그램을 변경했다면 각각의 동작은 정상 기능처럼 보일 수 있습니다. EDR은 이 동작들이 이어진 순서와 관계를 살펴 의심스러운 사건으로 판단합니다.

Response는 발견 이후의 조치입니다. 감염이 의심되는 PC를 네트워크에서 격리하거나, 악성 프로세스를 종료하고, 특정 파일을 격리하며, 같은 흔적이 다른 장치에도 있는지 검색할 수 있습니다. 제품에 따라 자동 대응 범위와 관리자가 직접 승인해야 하는 범위가 다르므로 도입 전에 확인해야 합니다.

• 수집: 프로세스 실행, 파일 생성, 네트워크 연결, 계정 활동 등의 보안 이벤트를 기록합니다.
• 탐지: 규칙, 행위 분석, 위협 정보 등을 이용해 수상한 패턴을 찾습니다.
• 조사: 어떤 사용자와 장치에서 사건이 시작됐는지 시간순으로 보여줍니다.
• 대응: 장치 격리, 프로세스 종료, 파일 차단 등 확산을 줄이는 기능을 제공합니다.

초보 담당자를 위한 기준: EDR을 ‘더 강한 백신’으로만 이해하기보다, 엔드포인트에 설치하는 보안 카메라와 원격 대응 도구가 합쳐진 형태로 생각하면 기능을 구분하기 쉽습니다.

기업용 백신과 EDR은 어디서 갈리는가

예방 중심과 조사·대응 중심의 차이

기업용 백신은 알려진 악성코드와 위험 파일을 빠르게 차단하는 데 강점이 있습니다. 중앙 관리, 예약 검사, 정책 배포, 매체 제어 같은 기능도 제공해 기본 보안 수단으로 가치가 큽니다. 따라서 EDR을 도입한다고 백신의 역할이 사라지는 것은 아닙니다. 최근에는 한 에이전트 안에 백신 기능과 EDR 기능이 함께 들어간 제품도 많지만, 두 기능의 목적과 계약 범위는 구분해서 봐야 합니다.

차이는 사고가 발생한 뒤 질문을 던질 때 선명해집니다. 백신 알림에는 ‘어떤 파일을 차단했다’는 결과가 중심이지만, EDR에서는 그 파일을 누가 내려받았는지, 어떤 프로세스가 실행했는지, 이후 어떤 주소로 접속했는지, 다른 PC에도 같은 명령이 나타났는지를 추적할 수 있습니다. 즉 단일 탐지 결과보다 사건의 전후 맥락을 제공하는 것이 EDR의 핵심 가치입니다.

예를 들어 직원이 정상 원격관리 프로그램을 설치했다고 가정해 보겠습니다. 프로그램 자체는 악성코드가 아니어서 백신이 허용할 수 있습니다. 하지만 새벽에 실행되고, 평소 사용하지 않던 국가의 주소로 연결되며, 관리자 권한 획득을 반복한다면 이야기가 달라집니다. EDR은 이런 행동 조합을 조사할 단서를 남깁니다.

같이 사용해야 하는 이유

백신과 EDR 중 하나만 고르는 문제로 접근하면 도입 목적이 흐려집니다. 기본적인 악성코드 차단은 백신 또는 차세대 안티바이러스 기능이 맡고, 이를 통과한 의심 행동의 가시성과 대응은 EDR이 보완하는 구조가 현실적입니다. 제품 설명서에서 ‘EDR 포함’이라는 문구를 보았다면 단순 탐지 화면만 제공하는지, 원격 격리와 과거 데이터 검색까지 가능한지 확인해야 합니다.

• 백신 라이선스에 EDR 기능이 실제로 포함되는지 확인합니다.
• 윈도우뿐 아니라 macOS와 리눅스 서버 지원 범위를 살펴봅니다.
• 이벤트 데이터가 몇 일 동안 보관되는지 질문합니다.
• PC가 사내망 밖에 있어도 정책과 대응 명령이 전달되는지 시험합니다.
• 기존 보안 에이전트와 충돌하거나 성능을 떨어뜨리지 않는지 검증합니다.

처음 도입할 때 기능보다 먼저 볼 항목

우리 조직이 직접 운영할 수 있는가

EDR 화면에 경보가 뜬다고 해서 모든 문제가 자동으로 해결되지는 않습니다. 담당자는 경보가 실제 공격인지, 정상 업무 프로그램의 예외 행동인지 판단해야 합니다. 직원 30명의 회사라도 경보를 매일 확인할 사람이 없다면 기능이 풍부한 제품보다 관리형 탐지·대응 서비스가 결합된 상품이 더 실용적일 수 있습니다.

반대로 사내 보안 인력이 있고 서버와 네트워크 로그를 함께 분석할 수 있다면 상세 검색과 연동 기능이 중요해집니다. 조직마다 적합한 형태가 다른 이유입니다. 재택근무와 외부 접속이 일상화된 배경을 이해하려면 포스트 코로나 관련 설명도 참고할 수 있습니다. 근무 장소가 분산될수록 사무실 방화벽만으로 모든 단말을 관찰하기 어려워집니다.

가격은 일반적으로 장치 수, 서버 포함 여부, 데이터 보관 기간, 관리형 서비스, 기술 지원 등급에 따라 달라집니다. 공개된 1대당 가격만 곱하면 실제 예산과 차이가 날 수 있습니다. 초기 구축비, 최소 계약 수량, 부가세, 교육비, 로그 연동비를 포함한 연간 총비용으로 견적을 비교해야 합니다.

1. 대상 수량 계산: 직원 수가 아니라 실제 PC, 노트북, 서버, 가상 장치 수를 셉니다.
2. 운영 주체 지정: 경보를 매일 볼 사람과 부재 시 대체 담당자를 정합니다.
3. 필수 기능 선정: 장치 격리, 원격 조사, 서버 지원처럼 반드시 필요한 기능을 세 가지 정도로 좁힙니다.
4. 개념검증 진행: 실제 업무용 장치 일부에 설치해 성능과 탐지 품질을 확인합니다.
5. 사고 절차 연결: 심각도별 보고 대상과 대응 승인자를 문서로 남깁니다.

도입 검증에서 직접 던질 질문

제품 시연에서는 화려한 대시보드보다 실제 상황을 요청하는 편이 좋습니다. 테스트 PC에서 의심 행위를 발생시킨 뒤 경보가 언제 표시되는지, 담당자가 어떤 근거로 판단할 수 있는지, 격리 후 정상 상태로 되돌리는 과정이 쉬운지 확인해 보세요. 잘못된 탐지는 완전히 없앨 수 없으므로 예외 정책을 얼마나 세밀하고 안전하게 설정할 수 있는지도 중요합니다.

• 경보 화면에서 최초 실행 파일과 부모 프로세스를 바로 찾을 수 있나요?
• 인터넷에 연결된 외근자 PC도 원격 격리할 수 있나요?
• 격리된 PC가 관리 서버 및 필수 업데이트 서버에는 연결되나요?
• 관리자 실수로 격리했을 때 해제 절차와 감사 기록이 남나요?
• 탐지 데이터의 저장 위치와 보관 기간은 어떻게 되나요?
• 에이전트 업데이트 실패나 비활성 장치를 별도로 알려주나요?

기능표에서 체크 표시가 가장 많은 제품보다 담당자가 10분 안에 경보의 원인과 영향 범위를 이해할 수 있는 제품이 실제 운영에서는 더 나을 수 있습니다.

작은 조직도 실패하지 않는 단계별 운영법

전사 설치 전에 소규모로 관찰하기

처음부터 모든 장치에 강한 차단 정책을 적용하면 업무 프로그램이 멈추거나 정상 스크립트가 차단될 수 있습니다. 우선 IT 담당자와 협조적인 사용자, 일반 사무직, 개발 또는 디자인 직군을 섞어 5~10대 정도의 시험 그룹을 구성하는 방법이 안전합니다. 업무 형태가 다른 장치를 포함해야 예상하지 못한 충돌을 빨리 발견할 수 있습니다.

첫 1~2주는 가능하면 관찰 중심으로 운영하며 평소 어떤 프로세스와 통신이 발생하는지 기준선을 만듭니다. 이후 명백히 위험한 행위부터 차단하고, 정상으로 확인한 경보에는 근거와 유효기간을 붙여 예외를 설정합니다. 무기한 예외가 쌓이면 탐지 범위가 조용히 줄어들 수 있으므로 월 1회 이상 검토하는 편이 좋습니다.

사용자 공지도 빼놓기 쉽습니다. EDR이 설치되면 어떤 보안 이벤트가 수집되는지, 개인용 장치에는 설치되는지, 오탐으로 업무가 중단될 때 어디로 연락해야 하는지 알려야 합니다. 기술적 통제뿐 아니라 사용자 안내와 내부 정책이 함께 움직여야 불필요한 불신을 줄일 수 있습니다. IT가 조직의 업무 방식과 결합되는 배경은 IT 개념 자료에서도 폭넓게 살펴볼 수 있습니다.

1. 1단계, 자산 파악: 운영체제와 중요도에 따라 장치를 분류하고 설치 제외 사유를 기록합니다.
2. 2단계, 시험 배포: 대표 사용자 그룹에서 CPU, 메모리, 부팅 시간, 업무 앱 충돌을 측정합니다.
3. 3단계, 탐지 관찰: 경보 유형과 반복 횟수를 기록해 정상 업무 패턴을 구분합니다.
4. 4단계, 대응 연습: 테스트 장치를 격리하고 해제하면서 연락과 승인 절차를 점검합니다.
5. 5단계, 순차 확대: 부서 단위로 설치하고 각 단계에서 장애 여부를 확인합니다.
6. 6단계, 월간 개선: 미설치 장치, 비활성 에이전트, 오래된 예외, 반복 경보를 검토합니다.

경보가 왔을 때 초보 담당자의 순서

긴급 경보를 받으면 바로 파일부터 삭제하고 싶어지지만, 먼저 증거와 영향 범위를 확인해야 합니다. 사용자 이름, 장치 이름, 발생 시각, 탐지된 프로세스, 외부 연결 주소를 기록하세요. 실제 침해 가능성이 높고 확산 위험이 있다면 네트워크 격리를 우선하되, 생산 설비나 핵심 서버처럼 중단 영향이 큰 장치는 내부 승인 절차를 따라야 합니다.

그다음 같은 파일 해시, 도메인, 프로세스 명령줄이 다른 장치에서도 발견되는지 검색합니다. 한 대만 치료하고 끝냈다가 동일 계정이나 첨부 파일을 통해 다시 발생할 수 있기 때문입니다. 사건 처리 후에는 사용한 계정의 비밀번호 변경, 취약점 보완, 이메일 차단, 예외 정책 수정 등 재발 방지 조치를 연결해야 합니다.

• 확인: 경보의 심각도와 탐지 근거를 읽습니다.
• 보존: 화면, 시간, 사용자, 명령줄 등 조사에 필요한 정보를 기록합니다.
• 제한: 확산 가능성이 높다면 장치를 격리하고 관련 계정을 보호합니다.
• 탐색: 동일한 흔적이 다른 PC와 서버에 있는지 전사 검색합니다.
• 복구: 원인을 제거한 뒤 필요한 점검을 거쳐 격리를 해제합니다.
• 개선: 탐지 규칙, 사용자 교육, 패치 정책에 사건의 교훈을 반영합니다.

백신이 있는데도 EDR을 꼭 추가해야 할까

직원 수보다 사고 대응 능력으로 판단하기

이 질문에 대한 답은 모든 기업에 무조건 ‘예’가 아닙니다. 중요한 것은 직원 수보다 보호할 데이터의 가치, 외부 접속 방식, 서버 운영 여부, 사고 발생 시 업무 중단 비용입니다. 고객 개인정보나 설계 자료를 다루고, 외근자가 많으며, 사내에서 원격접속과 관리자 권한을 자주 사용한다면 EDR의 조사·대응 기능이 주는 이점이 커집니다.

반면 장치가 매우 적고 중앙 관리형 백신, 다중 인증, 신속한 보안 업데이트, 제한된 관리자 권한, 검증된 백업 체계가 잘 운영된다면 먼저 기본 통제를 다지는 편이 효율적일 수 있습니다. EDR은 취약한 비밀번호나 미적용 업데이트를 대신 해결하지 못합니다. 경보를 볼 담당자조차 없다면 라이선스를 추가하는 것보다 관리형 서비스를 검토하거나 기존 보안 운영을 정돈하는 일이 우선입니다.

예산이 한정되어 있다면 ‘EDR을 살까 말까’라는 이분법 대신 위험도가 높은 장치부터 적용해 보세요. 외부에서 자주 사용하는 노트북, 관리자 PC, 중요 서버, 개발 장비를 우선 대상으로 선정하고 운영 결과를 측정할 수 있습니다. 다만 일부 장치만 보호하면 공격 흐름이 보이지 않는 구간이 생기므로 적용 범위와 한계를 문서에 명확히 표시해야 합니다.

• 도입 우선도가 높은 경우: 민감정보 취급, 외부 접속 증가, 중요 서버 운영, 반복되는 보안 사고, 감사 대응 필요가 있습니다.
• 기본 보완이 먼저인 경우: 자산 목록이 없고, 업데이트가 방치되며, 관리자 계정을 함께 쓰거나 백업 복구 시험을 하지 않습니다.
• 관리형 서비스가 맞는 경우: 전담 보안 인력이 없고 야간·휴일 경보를 내부에서 확인하기 어렵습니다.
• 시험 도입이 맞는 경우: 필요성은 있지만 성능 저하, 오탐, 기존 프로그램 충돌이 걱정됩니다.

한 달 시험 운영에서 무엇을 측정해야 하나

시험 운영의 목적은 탐지 건수를 많이 만드는 것이 아닙니다. 실제 담당자가 경보를 이해하고 필요한 조치를 수행할 수 있는지 확인하는 데 있습니다. 전체 경보 수, 실제 확인이 필요했던 경보 비율, 경보 한 건을 판별하는 데 걸린 시간, 반복 오탐, 에이전트 장애, 사용자 문의를 함께 기록하면 제품의 운영 부담을 비교할 수 있습니다.

테스트 마지막에는 의심 파일 실행, 비정상 명령어 사용, 장치 격리와 복구 같은 사전에 승인된 모의 시나리오를 진행해 보세요. 단, 실제 악성코드를 임의로 내려받거나 운영 서버에서 공격 도구를 실행해서는 안 됩니다. 공급사가 제공하는 안전한 시뮬레이션이나 격리된 시험 환경을 사용하고, 내부 승인과 영향 범위를 먼저 확인해야 합니다.

한 달 뒤에도 “탐지는 잘 되는 것 같다” 정도밖에 말할 수 없다면 평가 기준이 부족했던 것입니다. 평균 확인 시간, 중대한 경보의 알림 지연, 격리 성공 여부, 정상 업무에 미친 영향, 기술지원 응답 품질을 점수화하면 구매 여부를 설명하기 쉬워집니다. 이 수치들이 현재 인력과 절차에 맞는다면 EDR은 단순한 보안 프로그램이 아니라 사고 상황에서 판단 시간을 줄여 주는 실질적인 기업 IT 솔루션이 됩니다.

1. 경보가 담당자에게 도착하기까지 걸린 시간을 측정합니다.
2. 경보 화면만 보고 최초 원인과 영향을 파악할 수 있는지 확인합니다.
3. 장치 격리와 해제가 원격에서도 안정적으로 작동하는지 시험합니다.
4. 정상 업무 프로그램의 오탐 횟수와 예외 처리 시간을 기록합니다.
5. 에이전트가 CPU, 메모리, 배터리와 부팅 시간에 미친 영향을 비교합니다.
6. 문의 시 공급사의 최초 응답 시간과 답변의 구체성을 평가합니다.
7. 시험 결과를 토대로 전사 적용, 범위 제한, 관리형 서비스 전환 중 하나를 선택합니다.