흰색 Cloudflare 로고와 영문명이 표시된 주황색 배경 이미지
Product

바이브코딩으로 만든 웹사이트, 보안 신경 쓰인다면 Cloudflare

Cloudflare는 서비스 앞에서 주소를 안내하고 속도를 높이며 위험한 요청을 걸러주는 기반 시설에 가깝습니다. 무료로도 기본적인 방어선을 만들 수 있습니다.

바이브 코딩을 이용하면 이전보다 훨씬 빠르게 서비스를 만들 수 있습니다.

AI에게 필요한 기능을 설명하고 몇 차례 대화를 주고받다 보면 어느새 화면이 완성되고, 실제로 접속할 수 있는 서비스가 만들어집니다. 그런데 서비스를 인터넷에 공개하려는 순간 DNS, CDN, SSL, WAF, DDoS 방어처럼 낯선 이름들이 등장합니다.

그리고 자주 만나게 되는 서비스가 Cloudflare입니다.

Cloudflare에는 도메인을 연결하는 DNS, 서비스 속도를 높이는 CDN, 통신을 보호하는 SSL, 공격을 막는 WAF와 DDoS 방어가 있습니다. 웹사이트를 올리는 호스팅과 서버 기능도 제공하지만, 반드시 Cloudflare에서 모든 것을 사용해야 하는 것은 아닙니다.

서비스는 Vercel이나 AWS 같은 다른 곳에서 운영하고, 그 앞에 Cloudflare만 세울 수도 있습니다. 저도 Cloudflare를 직접 호스팅하기보다 기존 서비스 앞에서 요청을 확인하고 공격을 걸러주는 방어자로 사용하고 있습니다.

이번 글에서는 이 방어자의 역할을 중심으로 설명해 보겠습니다.

과일 가게를 연다고 가정해 보겠습니다

우리가 오프라인에서 과일 가게를 하나 운영한다고 생각해 보겠습니다.

손님이 가게를 찾아올 수 있도록 주소를 알려줘야 합니다. 먼 지역의 손님에게도 과일을 빠르게 전달해야 하고, 계산할 때 주고받는 정보도 보호해야 합니다. 수상한 손님이나 갑자기 몰려드는 군중도 관리해야 합니다.

Cloudflare가 하는 일도 이 과일 가게에 비유하면 조금 더 쉽게 이해할 수 있습니다.

DNS는 가게의 주소를 알려주는 안내소입니다

DNS는 ‘Domain Name System’의 줄임말입니다.

인터넷에 연결된 서버에는 숫자로 된 IP 주소가 있습니다. 하지만 사람은 복잡한 숫자 대신 jungwu.com 같은 도메인 이름을 사용합니다. DNS는 사람이 입력한 도메인 이름을 실제 서버의 IP 주소와 연결해 주는 인터넷의 주소록입니다.

과일 가게에 비유하면 손님이 가게 이름을 검색했을 때 정확한 주소를 알려주는 지도와 안내소입니다. 가게가 아무리 잘 꾸며져 있어도 안내소가 엉뚱한 주소를 알려주면 손님은 찾아올 수 없습니다. Cloudflare의 DNS 설명

CDN은 지역마다 마련한 대형마트의 분점입니다

CDN은 ‘Content Delivery Network’의 줄임말입니다. 이미지, 영상, HTML과 같은 콘텐츠의 복사본을 여러 지역의 서버에 보관하고 사용자와 가까운 곳에서 전달하는 시스템입니다.

서울에만 대형마트 본점이 하나 있다고 생각해 보겠습니다.

부산에 있는 손님이 사과 하나를 살 때마다 서울 본점까지 주문을 보내야 한다면 시간이 오래 걸립니다. 주문이 몰리면 서울 본점도 바빠집니다.

그래서 부산, 대전, 광주 같은 지역에 분점을 만들고 자주 팔리는 과일을 미리 가져다 둡니다. 부산 손님은 서울 본점까지 가지 않고 부산 분점에서 과일을 받을 수 있습니다.

Cloudflare의 CDN도 원본 서버에 있는 이미지와 파일의 복사본을 여러 지역에 보관합니다. 방문자는 가까운 지역 서버에서 파일을 받기 때문에 페이지가 더 빠르게 열리고, 원본 서버가 처리해야 하는 요청도 줄어듭니다. Cloudflare의 CDN 설명

SSL은 손님과 가게 사이의 대화를 암호화합니다

SSL은 ‘Secure Sockets Layer’의 줄임말입니다. 지금은 SSL을 개선한 TLS라는 기술이 실제로 사용되지만, 여전히 SSL 인증서라는 표현을 많이 사용합니다.

SSL/TLS는 손님과 서비스가 주고받는 내용을 암호화합니다. 접속한 사이트가 실제로 그 사이트가 맞는지 확인하고, 전달되는 내용이 중간에서 바뀌지 않았는지도 검사합니다.

과일 가게에서 손님이 주문서와 카드 정보를 직원에게 전달한다고 생각해 보겠습니다. 주문서를 누구나 열어볼 수 있는 투명한 봉투에 넣는다면 중간에 누군가 내용을 훔쳐볼 수 있습니다.

SSL은 주문서를 잠금장치가 있는 상자에 넣어 전달하는 것과 비슷합니다. 손님과 가게만 상자를 열 수 있기 때문에 중간에서 주문서를 가로채더라도 내용을 알아보기 어렵습니다. Cloudflare의 SSL/TLS 설명

DDoS는 가짜 손님으로 가게를 마비시키는 공격입니다

DDoS는 ‘Distributed Denial of Service’, 우리말로는 분산 서비스 거부 공격입니다.

공격자가 여러 컴퓨터와 기기를 이용해 한꺼번에 많은 요청을 보내면 서버는 그 요청을 처리하느라 정상적인 사용자에게 응답하지 못하게 됩니다. 서비스가 느려지거나 완전히 접속되지 않을 수도 있습니다.

과일을 살 생각이 없는 사람 수천 명이 동시에 대형마트로 들어와 입구와 계산대를 막는 상황과 비슷합니다. 실제 손님은 마트에 들어가지 못하고, 직원들은 가짜 손님을 상대하느라 정상적인 영업을 할 수 없습니다.

Cloudflare의 DDoS 방어는 이 군중이 가게 입구에 도착하기 전에 비정상적인 흐름을 확인하고 일부 요청을 차단하거나 분산합니다. 정상적인 손님이 계속 가게를 이용할 수 있도록 입구의 혼잡을 줄이는 역할입니다. Cloudflare의 DDoS 설명

WAF는 주문서까지 검사하는 경비원입니다

WAF는 ‘Web Application Firewall’, 즉 웹 애플리케이션 방화벽입니다.

DDoS 방어가 가게 앞에 갑자기 몰려든 군중을 관리한다면, WAF는 가게에 들어오려는 손님이 제출한 주문서와 행동을 자세히 확인합니다.

온라인에서는 다음과 같은 일이 발생할 수 있습니다.

  • 검색창이나 로그인 입력란에 데이터베이스를 조작하는 명령을 넣습니다.
  • 게시판이나 댓글에 다른 사용자의 브라우저에서 실행될 악성 스크립트를 넣습니다.
  • 외부에 공개되면 안 되는 설정 파일과 관리자 경로를 반복해서 찾습니다.
  • 서비스에서 아직 수정하지 못한 취약점을 이용하는 요청을 보냅니다.

WAF는 요청의 주소, 입력값, 헤더와 본문을 규칙에 따라 검사합니다. 위험한 공격 패턴과 일치하면 요청이 실제 서버에 도착하기 전에 차단하거나 추가 확인 절차를 보여줍니다.

과일 가게의 경비원이 손님의 인상만 보는 것이 아니라 위조된 주문서를 내고 있는지, 창고 열쇠를 요구하고 있는지, 출입 금지 구역으로 들어가려는지를 확인하는 셈입니다. Cloudflare의 WAF 설명

봇 방어와 요청 제한은 자동화된 반복 행동을 관리합니다

봇은 사람 대신 웹사이트에 자동으로 접속하는 프로그램입니다.

모든 봇이 나쁜 것은 아닙니다. Google 검색 봇처럼 웹페이지를 수집하는 봇도 있고, 서비스가 정상적으로 운영되는지 확인하는 모니터링 봇도 있습니다.

반대로 다른 사이트의 글과 가격을 계속 복사하거나, 유출된 비밀번호로 로그인을 시도하거나, 한정 상품을 선점하거나, 비용이 발생하는 API를 반복해서 호출하는 악성 봇도 있습니다.

과일 가게로 비유하면 로봇이 매초 가게에 들어와 시식 과일을 가져가거나 예약 주문을 수백 번 넣어 실제 손님이 주문하지 못하게 만드는 상황입니다.

봇 방어는 방문자가 사람인지 자동화 프로그램인지 확인합니다. 요청 제한은 같은 방문자가 일정 시간 동안 같은 행동을 몇 번이나 반복했는지 확인합니다.

예를 들어 “같은 방문자는 짧은 시간 동안 로그인 요청을 일정 횟수까지만 할 수 있다”는 규칙을 만들 수 있습니다. 횟수를 넘으면 잠시 차단하거나 사람인지 확인하는 절차를 보여줍니다.

봇 방어가 손님의 정체를 살펴보는 일이라면, 요청 제한은 한 손님이 얼마나 자주 행동했는지 세는 일에 가깝습니다. Cloudflare의 봇 방어 설명, 요청 제한 설명

무료 버전으로 사용 가능한 범위

Cloudflare Free 요금제에서도 기본적인 방어 기능을 사용할 수 있습니다.

기능무료로 가능한 역할과일 가게 비유
DNS도메인과 서버 연결가게 주소 안내
CDN이미지와 파일을 가까운 서버에서 전달지역 분점에 인기 과일 보관
Universal SSL방문자와 서비스 사이의 통신 암호화잠금장치가 있는 주문 상자
DDoS 방어비정상적으로 몰려드는 트래픽 완화입구를 점거하는 군중 통제
WAF 관리형 규칙널리 악용되는 주요 공격 패턴 방어기본 교육을 받은 경비원
WAF 직접 규칙서비스에 맞는 출입 규칙 설정가게 전용 출입 규칙
요청 제한반복되는 요청 제한한 손님의 반복 주문 제한
Bot Fight Mode알려진 봇에 추가 검사 적용로봇 손님인지 확인
Security Events일부 보안 기록 확인경비 일지 확인

무료 요금제는 아무런 방어가 없는 서비스에 주소 안내판과 출입문, 기본 경비원을 마련하기에 충분합니다. 다만 서비스의 구조에 맞춰 경비원의 행동을 세밀하게 조정하는 데에는 한계가 있습니다. Cloudflare 요금제, WAF 기능 안내, 무료 봇 방어

무료 요금제를 사용하다가 언제 유료를 검토해야 할까

Cloudflare를 사용한다고 처음부터 유료 요금제를 선택할 필요는 없습니다. 무료 요금제로 기본 방어를 적용한 뒤, 실제 서비스를 운영하면서 무료 설정으로 해결하기 어려운 문제가 생겼을 때 검토하면 됩니다.

첫 번째는 정상적인 봇이 계속 차단되는 경우입니다.

무료 봇 방어는 의심스러운 봇을 전체적으로 검사하기 때문에 검색 봇, 결제 서비스, 모니터링 도구처럼 필요한 자동화 요청까지 막을 수 있습니다. 이때 특정 봇이나 주소만 예외로 통과시켜야 한다면 더 세밀한 봇 설정이 필요합니다.

두 번째는 보호할 장소가 늘어난 경우입니다.

처음에는 로그인 하나만 요청 제한으로 보호해도 충분할 수 있지만, 회원가입과 결제, 관리자 페이지, 파일 업로드, AI API까지 운영하기 시작하면 모든 기능에 같은 규칙을 적용하기 어렵습니다. 로그인에는 반복 실패 방지를, 결제에는 비정상적인 주문 검사를, AI API에는 과도한 호출 제한을 적용하는 식으로 기능마다 다른 방어 규칙이 필요해질 수 있습니다.

세 번째는 기본 WAF보다 넓은 공격 방어가 필요한 경우입니다.

서비스에 실제 회원 정보와 결제 기능이 들어가기 시작하면 널리 알려진 일부 공격만 막는 것으로는 부족할 수 있습니다. 더 많은 관리형 보안 규칙을 적용하고, 서비스 구조에 맞춰 차단과 예외를 조정해야 한다면 유료 요금제를 살펴볼 이유가 생깁니다.

네 번째는 공격 기록을 운영에 활용해야 하는 경우입니다.

개인 프로젝트에서는 수상한 접근이 있었다는 사실만 확인해도 충분할 수 있지만, 고객이 사용하는 서비스라면 어떤 요청이 어떤 규칙으로 차단됐는지 확인하고 정상 사용자가 잘못 차단된 것은 아닌지 점검해야 합니다. 보안 이벤트를 자세히 분석하거나 중요한 공격이 감지됐을 때 알림을 받아야 한다면 무료 기능만으로는 부족할 수 있습니다.

마지막은 장애가 실제 손실로 이어지는 경우입니다.

서비스가 잠시 멈춰도 큰 문제가 없는 단계라면 무료 요금제로 시작해도 됩니다. 반면 서비스 중단이 매출과 예약, 고객 신뢰의 손실로 이어진다면 가동 시간 보장과 운영 지원을 포함한 상위 요금제를 검토할 수 있습니다.

Cloudflare만 사용하면 모든 공격을 막을 수 있을까

그렇지는 않습니다.

Cloudflare는 가게 정문을 지키는 경비원입니다. 하지만 뒷문이 열려 있거나, 직원들이 금고 비밀번호를 공유하고 있거나, 창고 열쇠를 계산대에 올려두었다면 정문에 경비원을 세운 것만으로는 가게를 지킬 수 없습니다.

Cloudflare도 Cloudflare를 거치도록 설정된 요청을 중심으로 검사합니다. 공격자가 Cloudflare를 거치지 않고 원본 서버에 직접 접근할 수 있다면 그 경로는 별도로 막아야 합니다.

Cloudflare는 다음과 같은 문제까지 자동으로 해결해 주지 않습니다.

  • AI가 작성한 코드에 보안 취약점이 있습니다.
  • API 키가 브라우저에 노출되어 있습니다.
  • 관리자 페이지에 인증이 없습니다.
  • 로그인한 사용자가 다른 사람의 정보까지 볼 수 있습니다.
  • 데이터베이스 권한이 누구에게나 열려 있습니다.
  • 파일 업로드의 용량과 형식을 검사하지 않습니다.
  • 장애와 데이터 손실에 대비한 백업이 없습니다.

WAF도 모든 공격을 완벽하게 알아내는 것은 아닙니다. 공격 요청을 놓칠 수 있고, 반대로 정상적인 요청을 공격으로 오해할 수도 있습니다.

바이브 코딩으로 서비스를 공개하기 전에는 최소한 다음 질문에 답할 수 있어야 합니다.

  • 사용자의 요청이 실제로 Cloudflare를 거치고 있는가?
  • Cloudflare를 통하지 않고 서버에 직접 접근할 수 있는 길은 없는가?
  • API 키와 비밀번호가 사용자 화면에 노출되어 있지 않은가?
  • 관리자 페이지와 중요한 API에 인증이 적용되어 있는가?
  • 로그인, 문의, 결제와 AI 기능에 요청 제한이 필요한가?
  • 정상적인 검색 봇과 결제 봇이 차단되고 있지는 않은가?

AI는 과일 가게를 빠르게 만들어 줄 수 있습니다. 하지만 가게의 주소가 어디를 가리키는지, 손님이 어떤 문으로 들어오는지, 경비원이 누구를 막고 누구를 통과시키는지는 운영자가 이해하고 있어야 합니다.

그럼 이제 Codex에게 ‘Cloudflare 설치해줘’를 외쳐봅시다!

이 글이 도움이 되었나요?