ClamAV 바이러스 스캔 완벽 가이드

리눅스 서버에서 ClamAV를 활용한 바이러스 스캔 시스템을 구축하는 방법을 다룹니다. 메일 서버와 연동하여 악성코드를 자동으로 탐지하고 처리하는 실무 노하우를 배워봅니다.

---

목차

1. ClamAV_아키텍처_이해
2. clamd_데몬_설정
3. 바이러스_DB_자동_업데이트
4. Amavis_연동_설정
5. 감염_메일_처리_정책
6. 리소스_최적화

---

1. ClamAV 아키텍처 이해

어느 날 김개발 씨가 회사 메일 서버를 관리하게 되었습니다. 선배가 "메일 서버에 바이러스 스캐너 붙여놔야 해"라고 말했는데, 대체 어디서부터 시작해야 할지 막막했습니다.

그때 ClamAV라는 이름을 처음 듣게 됩니다.

ClamAV는 오픈소스 안티바이러스 엔진으로, 리눅스 서버에서 가장 널리 사용되는 바이러스 스캐너입니다. 마치 공항의 보안 검색대처럼 파일을 검사하고 악성코드를 탐지합니다.

데몬 모드와 명령줄 모드를 모두 지원하여 다양한 환경에서 유연하게 활용할 수 있습니다.

다음 코드를 살펴봅시다.

# ClamAV 주요 구성요소 확인
# clamd: 바이러스 스캔 데몬 (항상 메모리에 상주)
sudo systemctl status clamav-daemon

# clamscan: 명령줄 스캐너 (일회성 검사용)
clamscan --version

# freshclam: 바이러스 DB 업데이트 도구
freshclam --version

# clamdscan: clamd 데몬에 스캔 요청하는 클라이언트
clamdscan --version

# 설치 확인 (Ubuntu/Debian 기준)
dpkg -l | grep clamav

김개발 씨는 입사 6개월 차 시스템 엔지니어입니다. 어느 날 팀장님이 다가와 말했습니다.

"우리 메일 서버, 바이러스 검사 기능 좀 넣어줘요. ClamAV 쓰면 된다던데." ClamAV라는 이름을 처음 들은 김개발 씨는 검색을 시작했습니다.

그런데 clamd, clamscan, freshclam, clamdscan... 비슷비슷한 이름의 프로그램들이 쏟아져 나왔습니다.

대체 이것들이 뭐가 다른 걸까요? 선배 개발자 박시니어 씨가 다가와 설명을 시작했습니다.

"ClamAV를 공항에 비유해볼게요. 공항 보안 시스템을 생각해보세요." clamd는 공항에 항상 상주하는 보안 검색 시스템과 같습니다.

전원을 켜두면 24시간 대기하면서 검사 요청이 들어올 때마다 즉시 처리합니다. 바이러스 시그니처 데이터베이스를 메모리에 올려놓기 때문에 검사 속도가 매우 빠릅니다.

반면 clamscan은 휴대용 금속탐지기와 같습니다. 필요할 때마다 꺼내서 사용하는 방식입니다.

실행할 때마다 바이러스 DB를 새로 로드하기 때문에 시작이 느리지만, 간단한 일회성 검사에 적합합니다. freshclam은 보안 정보를 업데이트하는 담당자입니다.

새로운 바이러스 정보가 나오면 인터넷에서 다운로드해서 로컬 데이터베이스에 반영합니다. 이 친구가 열심히 일해야 최신 악성코드도 탐지할 수 있습니다.

마지막으로 clamdscan은 보안 검색대에 짐을 맡기는 승객과 같습니다. clamd 데몬에게 "이 파일 좀 검사해주세요"라고 요청하는 클라이언트 도구입니다.

clamd가 이미 실행 중이어야 사용할 수 있습니다. 이 네 가지 구성요소가 어떻게 함께 동작하는지 살펴보겠습니다.

먼저 freshclam이 주기적으로 바이러스 DB를 최신 상태로 유지합니다. clamd 데몬은 이 DB를 메모리에 로드하고 대기합니다.

메일 서버나 다른 애플리케이션이 파일 검사를 요청하면 clamdscan이나 소켓 통신을 통해 clamd에게 전달합니다. 실제 서버 운영에서는 대부분 clamd 데몬 방식을 사용합니다.

메일이 수신될 때마다 clamscan을 실행하면 매번 수백 MB의 DB를 로드해야 하니 서버가 버티지 못합니다. clamd는 한 번 로드한 DB를 메모리에 유지하므로 수천 건의 메일도 빠르게 처리할 수 있습니다.

박시니어 씨가 덧붙였습니다. "그러니까 우리가 설정해야 할 건 clamd와 freshclam이야.

이 두 개만 제대로 설정하면 나머지는 자연스럽게 따라와." 김개발 씨는 고개를 끄덕였습니다. 복잡해 보였던 ClamAV가 이제 조금씩 이해되기 시작했습니다.

각 구성요소의 역할을 알고 나니 어디서부터 설정해야 할지 방향이 잡혔습니다.

실전 팁

💡 - 서버 환경에서는 반드시 clamd 데몬 모드를 사용하세요

• clamscan은 테스트나 일회성 검사에만 활용하세요
• freshclam 없이는 신종 바이러스를 탐지할 수 없습니다

---

2. clamd 데몬 설정

ClamAV의 구조를 이해한 김개발 씨는 이제 본격적인 설정에 들어갔습니다. 가장 먼저 해야 할 일은 clamd 데몬을 제대로 설정하는 것입니다.

하지만 설정 파일을 열어보니 옵션이 너무 많아서 어디서부터 손대야 할지 막막합니다.

clamd.conf는 ClamAV 데몬의 핵심 설정 파일입니다. 소켓 통신 방식, 스캔 옵션, 리소스 제한 등을 이 파일에서 제어합니다.

올바른 설정이 없으면 다른 프로그램과 연동이 불가능하므로 가장 먼저 점검해야 합니다.

다음 코드를 살펴봅시다.

# /etc/clamav/clamd.conf 핵심 설정
# 데몬 모드로 실행 (백그라운드)
Foreground false

# 로컬 소켓 설정 (같은 서버 내 통신용)
LocalSocket /var/run/clamav/clamd.ctl
LocalSocketMode 666

# TCP 소켓 설정 (원격 서버 연동 시)
TCPSocket 3310
TCPAddr 127.0.0.1

# 스캔 대상 최대 크기 (100MB)
MaxFileSize 100M
MaxScanSize 100M

# 압축 파일 검사 깊이
MaxRecursion 16
MaxFiles 10000

김개발 씨가 설정 파일을 열어보니 주석이 빼곡하게 달린 긴 파일이 나왔습니다. 박시니어 씨가 옆에서 말했습니다.

"전부 다 알 필요 없어요. 핵심 옵션만 제대로 잡으면 돼요." 가장 먼저 이해해야 할 것은 소켓 통신 방식입니다.

clamd는 다른 프로그램들과 어떻게 대화할까요? 두 가지 방법이 있습니다.

하나는 LocalSocket이고 다른 하나는 TCPSocket입니다. LocalSocket은 같은 건물 안에서 내선 전화를 거는 것과 같습니다.

파일 시스템에 생성되는 특수한 파일을 통해 통신합니다. 같은 서버 안에서만 사용 가능하지만 속도가 빠르고 보안에 유리합니다.

TCPSocket은 외부에서 전화를 거는 것과 같습니다. IP 주소와 포트 번호를 통해 통신합니다.

다른 서버에서도 접근할 수 있어 분산 환경에 적합하지만, 방화벽 설정에 주의해야 합니다. 대부분의 경우 LocalSocket만으로 충분합니다.

메일 서버와 ClamAV가 같은 서버에 있다면 굳이 TCP를 열 필요가 없습니다. 불필요하게 포트를 열면 보안 위험이 커지니까요.

LocalSocketMode 666은 소켓 파일의 권한을 설정합니다. 666은 모든 사용자가 읽고 쓸 수 있다는 의미입니다.

Amavis나 다른 프로그램이 clamav 사용자 그룹에 속하지 않더라도 접근할 수 있게 해줍니다. 보안이 걱정된다면 660으로 설정하고 관련 프로그램을 clamav 그룹에 추가하면 됩니다.

다음으로 중요한 것은 스캔 제한 설정입니다. MaxFileSize는 단일 파일의 최대 크기를 지정합니다.

이보다 큰 파일은 검사하지 않고 건너뜁니다. 너무 크게 설정하면 대용량 파일 검사 시 서버가 멈출 수 있고, 너무 작게 설정하면 중요한 파일을 놓칠 수 있습니다.

MaxScanSize는 압축 파일 등을 풀었을 때 검사할 총 용량의 한계입니다. 예를 들어 1MB짜리 zip 파일 안에 100GB 분량의 파일이 들어있다면 어떻게 될까요?

이런 압축 폭탄 공격을 방지하기 위해 MaxScanSize로 제한을 걸어둡니다. MaxRecursion은 압축 파일 안에 압축 파일, 그 안에 또 압축 파일...

이런 중첩 구조를 얼마나 깊이 따라갈지 결정합니다. 16단계면 대부분의 정상적인 파일을 처리할 수 있습니다.

MaxFiles는 하나의 검사 작업에서 처리할 최대 파일 수입니다. 압축 파일 안에 수만 개의 파일이 들어있는 경우를 대비한 설정입니다.

김개발 씨가 설정을 마치고 데몬을 재시작하려고 하자 박시니어 씨가 말했습니다. "설정 변경 후에는 꼭 문법 검사를 해봐요." clamconf 명령어로 현재 설정을 확인하고, clamd --config-file=/etc/clamav/clamd.conf --debug 명령으로 데몬이 제대로 시작되는지 테스트할 수 있습니다.

실전 팁

💡 - LocalSocket 사용 시 권한 문제가 가장 흔한 오류 원인입니다

• TCPSocket은 반드시 127.0.0.1로 바인딩하여 외부 접근을 차단하세요
• 설정 변경 후 systemctl restart clamav-daemon 잊지 마세요

---

3. 바이러스 DB 자동 업데이트

clamd 설정을 마친 김개발 씨에게 박시니어 씨가 물었습니다. "그런데 바이러스 DB는 언제 업데이트할 거야?" 김개발 씨는 순간 얼굴이 굳었습니다.

아무리 좋은 백신도 DB가 오래되면 무용지물이라는 걸 깜빡한 것입니다.

freshclam은 ClamAV의 바이러스 시그니처 데이터베이스를 최신 상태로 유지하는 도구입니다. 매일 수백 개의 새로운 악성코드가 발견되므로 자동 업데이트는 필수입니다.

설정이 잘못되면 업데이트에 실패하거나 서버가 차단될 수 있으니 주의가 필요합니다.

다음 코드를 살펴봅시다.

# /etc/clamav/freshclam.conf 핵심 설정
# DB 업데이트 서버 (미러 지정)
DatabaseMirror db.local.clamav.net
DatabaseMirror database.clamav.net

# 하루 업데이트 횟수 (권장: 12회)
Checks 12

# DB 저장 위치
DatabaseDirectory /var/lib/clamav

# 업데이트 후 clamd에 알림
NotifyClamd /etc/clamav/clamd.conf

# 로그 설정
UpdateLogFile /var/log/clamav/freshclam.log
LogRotate true

# 수동 업데이트 테스트
sudo freshclam --verbose

바이러스 DB 업데이트가 왜 중요할까요? 박시니어 씨가 비유를 들어 설명했습니다.

"경찰이 수배자 명단을 들고 다닌다고 생각해봐. 명단이 1년 전 거라면 어떻게 될까?" 새로운 악성코드는 하루에도 수십, 수백 개씩 등장합니다.

ClamAV 개발팀은 이를 분석해서 시그니처를 만들고 DB에 추가합니다. 우리 서버도 이 최신 정보를 받아와야 신종 바이러스를 탐지할 수 있습니다.

freshclam.conf 파일의 핵심 설정을 하나씩 살펴보겠습니다. DatabaseMirror는 DB를 다운로드할 서버를 지정합니다.

ClamAV는 전 세계에 미러 서버를 운영하고 있습니다. db.local.clamav.net을 먼저 지정하면 지리적으로 가까운 미러를 자동으로 선택합니다.

백업으로 database.clamav.net도 추가해두면 안전합니다. Checks 12는 하루에 12번 업데이트를 확인하라는 의미입니다.

즉 2시간마다 새로운 DB가 있는지 체크합니다. ClamAV 공식 권장 설정이 12회이니 이를 따르는 것이 좋습니다.

24보다 크게 설정하면 서버에서 차단당할 수 있으니 주의하세요. NotifyClamd가 매우 중요합니다.

이 옵션이 없으면 DB가 업데이트되어도 clamd 데몬이 알지 못합니다. clamd는 시작할 때 DB를 메모리에 로드하고 그대로 유지하거든요.

NotifyClamd를 설정해두면 freshclam이 업데이트를 마친 후 clamd에게 "새 DB 나왔으니 다시 로드해"라고 신호를 보냅니다. 김개발 씨가 수동으로 freshclam을 실행해보았습니다.

"ClamAV update process started... main.cvd is up to date...

daily.cvd is up to date..." 메시지가 쭉 나오다가 "Database updated successfully"라는 메시지가 출력되었습니다. 하지만 자동 업데이트는 어떻게 설정할까요?

Ubuntu나 Debian에서는 clamav-freshclam 패키지를 설치하면 systemd 서비스가 함께 설치됩니다. systemctl status clamav-freshclam으로 상태를 확인하고, 정상 작동하지 않으면 systemctl enable --now clamav-freshclam으로 활성화합니다.

가끔 업데이트가 실패하는 경우가 있습니다. 로그 파일(/var/log/clamav/freshclam.log)을 확인해보면 원인을 알 수 있습니다.

가장 흔한 문제는 네트워크 방화벽입니다. freshclam은 HTTP(80)나 HTTPS(443) 포트로 통신하므로 아웃바운드 연결이 차단되어 있으면 안 됩니다.

또 다른 문제는 IP 차단입니다. 너무 자주 접속하거나 비정상적인 패턴이 감지되면 ClamAV 미러에서 IP를 차단합니다.

이런 경우 잠시 기다렸다가 다시 시도하거나 다른 미러를 사용해야 합니다. 박시니어 씨가 마지막으로 조언했습니다.

"업데이트 로그는 꼭 모니터링해둬. 며칠째 업데이트 실패하면 알림이 오도록 설정하는 게 좋아."

실전 팁

💡 - Checks 값을 24 초과로 설정하면 서버에서 차단될 수 있습니다

• 업데이트 실패 시 /var/log/clamav/freshclam.log를 확인하세요
• 프록시 환경에서는 HTTPProxyServer 옵션을 설정해야 합니다

---

4. Amavis 연동 설정

ClamAV 설정을 마친 김개발 씨는 이제 메일 서버와 연동해야 합니다. 메일 서버 담당자가 "우리는 Amavis 쓰고 있어요"라고 말했습니다.

Amavis가 뭔지도 몰랐던 김개발 씨는 또다시 검색을 시작합니다.

Amavis는 메일 서버와 콘텐츠 필터 사이를 연결하는 다리 역할을 합니다. Postfix 같은 메일 서버는 바이러스 검사 기능이 없으므로 Amavis를 통해 ClamAV, SpamAssassin 등과 연동합니다.

올바른 연동 설정이 없으면 메일이 검사 없이 통과하거나 아예 전달되지 않을 수 있습니다.

다음 코드를 살펴봅시다.

# /etc/amavis/conf.d/15-content_filter_mode
# 바이러스 검사 활성화
@bypass_virus_checks_maps = (
   \%bypass_virus_checks, \@bypass_virus_checks_acl, \$bypass_virus_checks_re);

# /etc/amavis/conf.d/50-user 설정
# ClamAV 소켓 경로 지정
@av_scanners = (
  ['ClamAV-clamd',
    \&ask_daemon, ["CONTSCAN {}\n", "/var/run/clamav/clamd.ctl"],
    qr/\bOK$/m, qr/\bFOUND$/m,
    qr/^.*?: (?!Infected Archive)(.*) FOUND$/m ],
);

# 서비스 재시작
sudo systemctl restart amavis
sudo systemctl restart postfix

Amavis를 이해하기 위해 우편물 검사 과정을 떠올려 보겠습니다. 우체국(Postfix)은 편지를 배달하는 일에 집중합니다.

하지만 요즘은 우편물 검사가 필수입니다. 그래서 보안 검사팀(Amavis)을 따로 두는 것입니다.

우체국이 편지를 받으면 보안팀에게 넘깁니다. 보안팀은 X-ray 검사기(ClamAV)로 위험물을 확인하고, 스팸 탐지기(SpamAssassin)로 광고성 우편물을 걸러냅니다.

검사가 끝나면 다시 우체국에 돌려보내 배달을 완료합니다. 이런 구조 때문에 Amavis 설정에서 ClamAV 소켓 경로를 정확히 지정해야 합니다.

아까 clamd.conf에서 LocalSocket을 /var/run/clamav/clamd.ctl로 설정했다면, Amavis 설정에서도 동일한 경로를 넣어야 합니다. /etc/amavis/conf.d/15-content_filter_mode 파일을 열어보면 주석 처리된 설정들이 보입니다.

바이러스 검사를 활성화하려면 해당 줄의 주석을 해제해야 합니다. 기본적으로 비활성화되어 있는 경우가 많으니 꼭 확인하세요.

/etc/amavis/conf.d/50-user 파일은 사용자 정의 설정을 넣는 곳입니다. 여기에 @av_scanners 배열을 정의하여 ClamAV를 스캐너로 등록합니다.

배열의 각 요소를 살펴보겠습니다. 첫 번째 'ClamAV-clamd'는 스캐너 이름입니다.

로그에 이 이름이 표시됩니다. &ask_daemon은 데몬에게 요청을 보내는 함수입니다.

"CONTSCAN {}\n"은 clamd에게 보내는 명령어로, {}는 검사할 파일 경로로 치환됩니다. /var/run/clamav/clamd.ctl은 clamd 소켓 경로입니다.

이 경로가 틀리면 Amavis가 ClamAV와 통신할 수 없습니다. 권한 문제도 흔히 발생하는데, amavis 사용자가 이 소켓 파일에 접근할 수 있어야 합니다.

qr/\bOK$/m은 정상 파일일 때 clamd가 보내는 응답 패턴입니다. qr/\bFOUND$/m은 바이러스가 발견되었을 때의 패턴입니다.

마지막 정규표현식은 바이러스 이름을 추출하는 용도입니다. 설정을 마쳤다면 연동이 제대로 되는지 테스트해봐야 합니다.

EICAR 테스트 파일을 사용하면 됩니다. EICAR는 실제로는 무해하지만 모든 안티바이러스가 바이러스로 탐지하도록 만들어진 표준 테스트 문자열입니다.

테스트 메일을 보내고 로그를 확인합니다. /var/log/mail.log와 /var/log/clamav/clamav.log를 함께 보면 메일이 어떻게 처리되었는지 추적할 수 있습니다.

"Blocked INFECTED" 같은 메시지가 보이면 연동이 성공한 것입니다. 김개발 씨가 테스트 메일을 보내자 몇 초 후 로그에 메시지가 나타났습니다.

"ClamAV-clamd: Eicar-Test-Signature FOUND" 박시니어 씨가 웃으며 말했습니다. "축하해, 이제 우리 메일 서버도 바이러스를 잡을 수 있게 됐어!"

실전 팁

💡 - amavis 사용자가 clamav 그룹에 속해 있는지 확인하세요: usermod -a -G clamav amavis

• 연동 테스트에는 EICAR 테스트 파일을 사용하세요
• 문제 발생 시 /var/log/mail.log와 clamav.log를 함께 확인하세요

---

5. 감염 메일 처리 정책

바이러스를 탐지할 수 있게 된 김개발 씨에게 새로운 고민이 생겼습니다. "감염된 메일을 어떻게 처리하지?

그냥 삭제해도 되나? 보관은 해야 하나?" 생각보다 단순하지 않은 문제였습니다.

감염 메일 처리 정책은 보안과 사용자 편의 사이의 균형을 잡는 작업입니다. 무조건 삭제하면 오탐으로 인한 중요 메일 손실 위험이 있고, 그대로 전달하면 보안이 무너집니다.

격리, 삭제, 태깅 등 다양한 정책 중 조직에 맞는 방식을 선택해야 합니다.

다음 코드를 살펴봅시다.

# /etc/amavis/conf.d/50-user 감염 메일 처리 정책
# 바이러스 발견 시 동작 설정
$final_virus_destiny = D_DISCARD;  # 삭제 (알림 없음)
# $final_virus_destiny = D_BOUNCE;  # 발신자에게 반송
# $final_virus_destiny = D_REJECT;  # SMTP 단계에서 거부
# $final_virus_destiny = D_PASS;    # 그대로 전달 (위험!)

# 격리 설정
$virus_quarantine_to = 'virus-quarantine@example.com';
$virus_quarantine_method = 'local:virus-%i-%n';

# 관리자 알림 설정
$virus_admin = 'admin@example.com';
$mailfrom_notify_admin = 'amavis@example.com';

# 수신자 알림 (선택적)
$warnvirusrecip = 0;  # 수신자에게 알리지 않음
$warnvirussender = 0;  # 발신자에게 알리지 않음

감염 메일 처리 정책을 결정하는 것은 생각보다 복잡한 문제입니다. 박시니어 씨가 질문했습니다.

"바이러스 걸린 메일이 발견되면 어떻게 할 거야?" 김개발 씨가 대답했습니다. "당연히 삭제해야죠." 박시니어 씨가 고개를 저었습니다.

"만약 오탐이면? 중요한 계약서가 담긴 메일이었는데 바이러스로 잘못 판정된 거라면?" 이것이 바로 보안과 가용성 사이의 트레이드오프입니다.

몇 가지 선택지를 살펴보겠습니다. D_DISCARD는 메일을 조용히 삭제합니다.

발신자도 수신자도 모르게 사라집니다. 가장 안전한 방법처럼 보이지만, 오탐 시 메일이 영영 사라지는 문제가 있습니다.

D_BOUNCE는 발신자에게 "당신의 메일이 바이러스 때문에 거부되었습니다"라는 메시지를 보냅니다. 하지만 요즘은 발신자 주소를 위조한 스팸이 많아서, 엉뚱한 사람에게 바운스 메일이 갈 수 있습니다.

이를 백스캐터라고 하는데, 심하면 우리 서버가 스팸 서버로 등록될 수 있습니다. D_REJECT는 SMTP 세션 중에 거부합니다.

바운스와 달리 별도의 메일을 보내지 않고, 발신 서버에게 즉시 에러를 반환합니다. 백스캐터 문제는 없지만, 정상적인 메일 서버에서 보낸 경우에만 발신자가 알 수 있습니다.

D_PASS는 바이러스가 있어도 그대로 전달합니다. 위험해 보이지만, 헤더에 경고 태그를 추가하고 수신자가 판단하게 하는 방식으로 활용할 수 있습니다.

주로 테스트 환경에서 사용합니다. 대부분의 조직에서 권장하는 방식은 **격리(Quarantine)**입니다.

감염 메일을 특별한 저장소에 보관해두고, 관리자가 주기적으로 확인하는 것입니다. 오탐인 경우 복구할 수 있고, 진짜 악성코드라면 삭제하면 됩니다.

virus_quarantine_to 옵션으로 격리 메일을 받을 주소를 지정합니다. 실제 메일함일 수도 있고, 로컬 파일 시스템에 저장하는 가상 주소일 수도 있습니다.

virus_quarantine_method를 'local:virus-%i-%n'으로 설정하면 /var/lib/amavis/virusmails/ 디렉토리에 파일로 저장됩니다. 관리자 알림도 중요합니다.

$virus_admin에 관리자 이메일을 설정해두면 바이러스가 발견될 때마다 알림을 받을 수 있습니다. 단, 대량 스팸 공격 시 알림 폭탄을 맞을 수 있으니 알림 빈도를 조절하는 것도 고려해야 합니다.

수신자나 발신자에게 알릴지 여부는 조직 정책에 따라 다릅니다. 내부 직원이 실수로 감염 파일을 보냈다면 알려주는 게 좋겠지만, 외부 스패머에게 굳이 우리 보안 시스템의 존재를 알릴 필요는 없습니다.

김개발 씨가 물었습니다. "그럼 우리는 어떻게 하면 좋을까요?" 박시니어 씨가 대답했습니다.

"격리 + 관리자 알림이 무난해. 일주일 정도 모니터링하면서 오탐 비율을 확인하고, 안정화되면 자동 삭제로 바꿔도 돼."

실전 팁

💡 - D_BOUNCE는 백스캐터 문제로 권장하지 않습니다

• 격리 디렉토리의 용량을 주기적으로 확인하고 오래된 파일은 정리하세요
• 처음에는 격리 모드로 운영하면서 오탐 비율을 파악하세요

---

6. 리소스 최적화

ClamAV가 잘 동작하는 것을 확인한 김개발 씨에게 모니터링 담당자가 연락을 해왔습니다. "ClamAV가 메모리를 2GB나 먹고 있어요.

서버 리소스가 부족해지고 있습니다." 예상치 못한 문제였습니다.

ClamAV는 바이러스 시그니처 DB를 메모리에 로드하기 때문에 기본적으로 많은 메모리를 사용합니다. 서버 환경에 따라 적절한 최적화가 필요하며, 메모리 제한, 스캔 옵션 조정, 스케줄링 등을 통해 리소스 사용을 효율화할 수 있습니다.

다음 코드를 살펴봅시다.

# /etc/clamav/clamd.conf 리소스 최적화 설정
# 동시 스캔 스레드 수 제한
MaxThreads 12

# 대기열 길이 제한
MaxQueue 100

# 유휴 타임아웃 (초)
IdleTimeout 30

# 메모리 절약을 위한 스캔 제한
MaxEmbeddedPE 10M
MaxHTMLNormalize 10M
MaxHTMLNoTags 2M
MaxScriptNormalize 5M
MaxZipTypeRcg 1M

# systemd로 메모리 제한 (선택적)
# /etc/systemd/system/clamav-daemon.service.d/override.conf
# [Service]
# MemoryLimit=1G

# 리소스 모니터링
ps aux | grep clamd
cat /proc/$(pgrep clamd)/status | grep -i mem

ClamAV가 메모리를 많이 사용하는 이유는 간단합니다. 수백만 개의 바이러스 시그니처를 메모리에 올려놓고 있기 때문입니다.

이것은 clamd 데몬의 핵심 장점이자 단점입니다. 박시니어 씨가 설명했습니다.

"메모리에 DB를 올려놓으니까 검사가 빠른 거야. 디스크에서 매번 읽어오면 엄청 느려지거든.

그런데 DB가 점점 커지면서 메모리 사용량도 같이 늘어나는 게 문제지." 현재 ClamAV DB는 약 1GB 정도의 메모리를 기본으로 사용합니다. 여기에 검사 중인 파일 처리를 위한 버퍼가 추가됩니다.

1GB 메모리만 있는 저사양 서버에서는 운영이 어려울 수 있습니다. 가장 먼저 조정할 것은 MaxThreads입니다.

이 값은 동시에 처리할 수 있는 스캔 요청 수를 결정합니다. 기본값이 너무 높으면 트래픽 급증 시 서버가 과부하에 걸릴 수 있습니다.

CPU 코어 수의 2배 정도로 설정하는 것이 일반적입니다. MaxQueue는 대기열 크기입니다.

처리 중인 요청이 MaxThreads를 초과하면 대기열에 쌓입니다. 대기열마저 가득 차면 새 요청은 거부됩니다.

이 값이 너무 크면 응답 지연이 심해지고, 너무 작으면 피크 시간에 요청 실패가 발생합니다. IdleTimeout은 연결을 얼마나 유지할지 결정합니다.

Amavis 같은 클라이언트가 연결을 맺고 여러 파일을 연속으로 검사할 때, 매번 새 연결을 맺으면 오버헤드가 큽니다. 하지만 연결을 너무 오래 유지하면 리소스 낭비가 됩니다.

더 세밀한 조정을 위해 MaxEmbeddedPE, MaxHTMLNormalize 등의 옵션이 있습니다. PE는 실행 파일 형식이고, 이 옵션은 분석할 최대 크기를 제한합니다.

값을 낮추면 메모리는 절약되지만 대용량 악성 파일을 놓칠 수 있습니다. 메모리가 정말 부족하다면 온디맨드 스캔 방식도 고려할 수 있습니다.

clamd 대신 clamscan을 사용하는 것입니다. 하지만 이 방식은 매번 DB를 로드해야 해서 스캔 시간이 크게 늘어납니다.

메일 트래픽이 적은 소규모 환경에서만 권장합니다. systemd를 사용하는 시스템에서는 MemoryLimit으로 프로세스 메모리를 강제 제한할 수 있습니다.

하지만 이렇게 하면 ClamAV가 비정상 종료될 수 있으니 주의가 필요합니다. 김개발 씨가 모니터링 화면을 보면서 물었습니다.

"메모리 말고 CPU는 어떨까요?" 박시니어 씨가 대답했습니다. "스캔 자체는 CPU를 많이 쓰는 작업이야.

압축 해제하고, 패턴 매칭하고... 하지만 메일 서버에서는 I/O 대기 시간이 더 길어서 체감상 CPU 부하는 크지 않을 거야." 실제 운영에서는 모니터링이 핵심입니다.

top, htop으로 실시간 리소스 사용량을 확인하고, 문제가 있으면 설정을 조정하는 사이클을 반복합니다. 로그에서 "MaxThreads limit reached" 같은 경고가 보이면 해당 값을 늘려야 합니다.

김개발 씨는 MaxThreads를 8로, MaxQueue를 50으로 조정하고 clamd를 재시작했습니다. 메모리 사용량이 눈에 띄게 줄지는 않았지만, CPU 스파이크가 줄어든 것을 확인할 수 있었습니다.

실전 팁

💡 - 메모리 1GB 미만 서버에서는 ClamAV 운영이 어렵습니다

• clamdtop 도구로 실시간 스캔 상태를 모니터링할 수 있습니다
• 부하 테스트로 적정 MaxThreads 값을 찾아보세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!