한 번 점검으로 충분한가?
CRM은 살아있는 시스템이다. 기능을 추가하고, 라이브러리를 업데이트하고, 설정을 변경할 때마다 새로운 취약점이 생길 수 있다. 특히 바이브코딩으로 빠르게 기능을 추가하면 보안 검토 없이 배포하기 쉽다.
보안 점검을 "한 번 받고 끝"으로 생각하는 순간, 그 점검 결과는 유통기한이 지난 우유가 된다. 지난달 A등급이었어도 이번 주에 추가한 고객 검색 API 하나 때문에 오늘 고객 DB 전체가 열려 있을 수 있다. SENTRIX가 레드팀으로 실제 진단을 나가 보면, 사고는 대부분 "새로 만든 기능"과 "방치된 옛 설정" 두 곳에서 터진다. 둘 다 정기 점검이 아니면 잡히지 않는다.
공격자 입장에서 CRM은 매력적인 표적이다. 이름·전화번호·이메일·주소가 한곳에 정리돼 있어 그대로 보이스피싱·스미싱 명단으로 쓰인다. 그래서 공격자는 특정 사이트를 노리는 게 아니라, 인터넷 전체를 스캔하며 "인증 없는 /api", "RLS 꺼진 Supabase", "만료된 SSL"을 자동으로 찾아다닌다. 당신이 어제 배포한 취약점은 평균 수십 분 안에 봇에게 발견된다. 점검 주기가 배포 주기를 따라가지 못하면, 그 격차가 곧 노출 시간이다.
왜 정기 진단이 필요한가
1. 코드 변경 = 새로운 위험
AI 코딩 도구에게 "고객 검색 기능 추가해줘"라고 하면 새 API 엔드포인트가 생긴다. 이 엔드포인트에 인증이 없을 수 있다. 기능 추가할 때마다 점검이 필요하다.
구체적으로 어떻게 뚫리는지 보자. AI 코딩 도구는 "작동하는 코드"를 만들지 "안전한 코드"를 만들지 않는다. 프론트엔드에서 데이터를 불러오는 fetch는 잘 만들지만, 서버 쪽 인증 미들웨어를 붙이는 것은 명시적으로 시키지 않으면 빠뜨린다. 결과적으로 다음과 같은 엔드포인트가 무방비로 열린다.
# 공격자가 인증 없이 그냥 호출한다
curl https://your-crm.com/api/customers
# 고객 DB가 그대로 응답으로 나온다
[{"name":"홍길동","phone":"010-1234-5678","email":"[email protected]"},
{"name":"김영희","phone":"010-9876-5432","email":"[email protected]"}, ...]
안전한 버전은 모든 데이터 접근 경로 앞에 인증·인가 검사를 둔다.
# 위험: 인증 검사 없음
@app.get("/api/customers")
def list_customers():
return db.query("SELECT * FROM customers")
# 안전: 토큰 검증 + 소유자 범위 제한
@app.get("/api/customers")
def list_customers(user=Depends(require_auth)):
return db.query(
"SELECT * FROM customers WHERE owner_id = %s",
[user.id]
)
직접 확인하는 법: 로그아웃 상태(또는 시크릿 창)에서 앱이 데이터를 불러올 때 브라우저 개발자도구 → Network 탭을 연다. /api/로 시작하는 요청 URL을 복사해 주소창에 그대로 붙여 넣거나 curl로 호출해 본다. 로그인하지 않았는데 고객 데이터가 나오면 인증이 빠진 것이다. 새 기능을 배포할 때마다 이 30초 테스트를 반복하라.
2. SSL 인증서 만료
Let's Encrypt 인증서는 90일마다 갱신이 필요하다. 자동 갱신이 실패하면 고객 데이터가 평문으로 전송된다. 정기 진단으로 SSL 상태를 확인해야 한다.
인증서 만료는 조용히 온다. 갱신 크론이 한 번 실패하거나, 서버를 옮기면서 certbot 타이머가 빠지거나, 방화벽이 갱신용 80포트를 막아버리면 아무 경고 없이 만료일을 넘긴다. 그 순간 방문자는 "이 연결은 비공개가 아닙니다" 경고를 보고, 최악의 경우 경고를 무시한 채 입력한 로그인·개인정보가 중간자(공용 와이파이의 공격자 등)에게 평문으로 노출된다. 신뢰가 생명인 CRM에서 브라우저 경고 하나로 고객 이탈이 발생한다.
직접 확인하는 법: 만료일과 자동 갱신 상태를 명령어로 직접 확인할 수 있다.
# 인증서 만료일 확인
echo | openssl s_client -connect your-crm.com:443 2>/dev/null \
| openssl x509 -noout -dates
# certbot 자동 갱신이 정상 동작하는지 시뮬레이션
sudo certbot renew --dry-run
그래서 뭘 해야 하나: 갱신을 자동화했다고 안심하지 말고, "자동화가 동작하는지"를 정기적으로 확인하는 이중 안전장치를 둔다. 만료 14일 전에 알림이 오도록 모니터링을 걸어 두면, 크론이 실패해도 사람이 손볼 시간이 생긴다.
3. 새로운 취약점 공개
사용 중인 프레임워크나 라이브러리에서 새 CVE가 공개될 수 있다. 어제까지 안전했던 코드가 오늘 위험해질 수 있다.
이건 당신이 코드를 한 줄도 바꾸지 않아도 발생하는 위험이다. 보안 연구자나 공격자가 당신이 쓰는 라이브러리의 취약점을 새로 발견해 공개하면, 그 순간부터 동일 버전을 쓰는 모든 서비스가 표적이 된다. 특히 공개 직후 며칠간은 패치를 적용하지 않은 서버를 노린 대량 스캔이 급증한다. Log4Shell처럼 널리 쓰이는 컴포넌트의 치명적 취약점은 공개 몇 시간 만에 전 세계에서 자동 악용이 시작됐다.
직접 확인하는 법: 의존성에 알려진 취약점이 있는지 배포 파이프라인에서 자동으로 검사한다.
# Node.js 프로젝트
npm audit --production
# Python 프로젝트
pip install pip-audit && pip-audit
GitHub를 쓴다면 저장소 설정에서 Dependabot alerts를 켜 두는 것만으로 취약한 패키지가 감지될 때 자동 알림과 수정 PR을 받을 수 있다. 정기 진단은 여기에 더해 "실제 서비스에 노출된 버전 정보"까지 외부 시점에서 확인해 준다.
4. 개인정보보호법 정기 점검 의무
개인정보보호법은 기술적 보호조치의 정기적 점검을 요구한다. 점검 기록이 없으면 사고 발생 시 과태료가 가중된다.
핵심은 "점검했다는 증거"다. 개인정보를 다루는 사업자는 접근 통제, 암호화, 접속 기록 보관 같은 안전조치를 갖추고 이를 주기적으로 점검할 의무가 있다. 사고가 터졌을 때 조사기관이 가장 먼저 확인하는 것은 "평소에 관리를 했는가"이다. 정기 점검 기록·로그·조치 이력이 남아 있으면 성실히 관리한 정황으로 참작되지만, 아무 기록도 없으면 방치로 판단돼 처분 수위가 올라간다. 개인정보 유출은 최대 매출액 기반의 과징금과 형사책임까지 이어질 수 있고, "AI가 만들어서 몰랐다"는 개인정보처리자(사업주)의 책임을 면해 주지 않는다.
그래서 뭘 해야 하나: 점검을 "일회성 이벤트"가 아니라 "날짜가 찍힌 반복 기록"으로 남겨라. 매월 자동 스캔 리포트를 PDF로 보관하면, 그 자체가 정기 점검을 이행했다는 타임스탬프 증거가 된다. CodeScan 구독 리포트가 이 기록 역할을 그대로 해 준다.
효과적인 CRM 보안 모니터링 방법
모든 항목을 매일 볼 필요는 없다. 위험의 성격에 따라 주기를 나누면 부담 없이 지속할 수 있다. 자주 바뀌는 것은 자주, 깊은 것은 가끔 본다.
매주: 기본 상태 확인
- SSL 인증서 유효 기간 확인 (만료 임박 시 즉시 대응)
- 서버 접근 로그에서 비정상 패턴 확인, 짧은 시간에 반복된 로그인 실패, 존재하지 않는 관리자 경로(
/admin,/wp-login.php등)로의 대량 요청 - 관리자 페이지 접근 시도 모니터링, 정체불명 IP의 관리자 URL 접근 여부
실전 팁: 접근 로그에서 이상 징후는 한 줄 명령어로 훑을 수 있다. 예를 들어 실패 응답이 많은 IP를 집계하면 자동화된 공격 스캔이 눈에 띈다.
# 접근 로그에서 401/403 응답이 많은 상위 IP 집계
awk '($9==401 || $9==403){print $1}' access.log \
| sort | uniq -c | sort -rn | head
매월: 종합 보안 진단
- 전체 보안 스캔 실행 (CodeScan 구독으로 자동화)
- 새로 추가된 API 엔드포인트 인증 확인, 지난달 이후 배포한 기능 목록과 대조
- 개인정보 처리 현황 점검, 수집 항목·보유 기간·파기 대상이 처리방침과 일치하는지
- 보안 헤더·CORS·쿠키 속성이 여전히 유효한지 재확인
월간 진단의 목적은 "지난 한 달의 변경이 만든 새 구멍"을 잡는 것이다. 배포 로그와 스캔 결과를 나란히 놓고 등급 변화를 추적하면, 어떤 변경이 점수를 떨어뜨렸는지 원인을 특정할 수 있다.
분기별: 심층 점검
- 침투 테스트 (레드팀 또는 자동화 도구), 자동 스캐너가 못 잡는 비즈니스 로직 취약점(권한 우회, IDOR, 결제 조작) 검증
- 개인정보 영향 평가, 데이터 흐름 전체를 다시 그려 보고 불필요한 수집·과다 보관을 제거
- 접근 권한 재검토, 퇴사자·외주 계정 정리, 역할별 최소 권한 원칙 재적용
자동 스캔이 "설정 레벨"을 본다면, 분기별 심층 점검은 "이 서비스만의 맥락"을 본다. 예컨대 다른 고객의 주문 번호로 URL을 바꿔치기하면 남의 정보가 보이는 IDOR 같은 취약점은 사람의 판단이 필요하다. 자동으로 기준선을 유지하고, 분기마다 전문가 관점으로 깊이를 더하는 이중 구조가 가장 비용 효율적이다.
CodeScan 구독으로 자동화하기
위 주기를 사람이 매번 챙기는 건 현실적으로 오래가지 못한다. 결국 잊혀지고, 잊혀진 시점에 사고가 난다. 그래서 최소한 "매주 자동 스캔"만큼은 사람 손을 떼고 시스템에 맡겨야 한다.
CodeScan Pro 구독을 이용하면 매주 자동으로 CRM 보안 진단이 실행된다. 새로운 취약점이 발견되면 즉시 이메일로 알림을 받을 수 있다.
- 매주 자동 스캔 + 등급 변화 알림, 지난주 대비 점수가 떨어지면 원인 항목과 함께 통보
- 개인정보 노출 감지 (PII 스캐너), 응답 본문·JS 번들에 이름·전화·이메일이 무방비로 실려 나가는지 탐지
- 인증 취약점 모니터링, 인증 없이 접근되는 API 엔드포인트 탐지
- 개인정보보호법 준수 체크리스트, 월간 리포트가 정기 점검 이행 기록으로 그대로 축적
보안 전문 기업 SENTRIX의 레드팀 진단 노하우를 21개 자동 스캐너로 구현했다. 사람이 매주 로그를 뒤지고 curl을 날리는 대신, 그 시간을 사업에 쓰고 이상 징후만 알림으로 받으면 된다.
먼저 무료 진단으로 현재 상태를 확인해보자. 지금 내 CRM이 몇 등급인지 아는 것이 모든 관리의 출발점이다.