개발 속도 늦추는 보안은 옛말, WAF-as-Code가 바꾸는 것들

들어가며

개발팀과 보안팀이 함께 있는 조직이라면 한 번쯤 겪어봤을 장면이 있습니다. 금요일 오후에 배포를 앞두고 있는데, 보안팀에서 WAF 규칙 검토가 아직 끝나지 않았다는 연락이 옵니다. 결국 배포는 다음 주로 밀리고, 개발팀은 보안팀을 병목이라고 부르기 시작합니다.

그런데 요즘 인프라를 코드로 관리하는 흐름이 자리 잡으면서, WAF 설정도 더 이상 콘솔에서 클릭으로 바꾸는 대상이 아니게 되었습니다. 코드로 작성하고, 파이프라인 안에서 자동으로 테스트하고 배포하는 이른바 WAF-as-Code라는 개념이 그 답입니다. 오늘은 이 개념이 실제로 어떻게 동작하는지, 그리고 보안이 왜 병목이 아니라 오히려 속도를 붙여주는 가속기가 될 수 있는지 살펴보겠습니다.

왜 콘솔에서 WAF 규칙을 바꾸면 안 될까

전통적으로 WAF 규칙은 보안 담당자가 클라우드 콘솔이나 관리 대시보드에 직접 로그인해서 수정하는 경우가 많았습니다. 이 방식은 당장은 편해 보이지만, 시간이 지날수록 몇 가지 문제를 만듭니다.

• 누가 언제 어떤 규칙을 바꿨는지 이력을 추적하기 어렵습니다
• 담당자의 실수로 규칙이 잘못 적용되어도 되돌릴 방법이 명확하지 않습니다
• 개발 환경과 운영 환경의 규칙이 시간이 지나며 서서히 어긋나기 시작합니다
• 규칙 변경이 코드 리뷰 없이 곧바로 운영 환경에 반영되는 경우가 많습니다

결국 WAF 규칙도 애플리케이션 코드와 똑같은 방식으로 다뤄야 한다는 문제의식에서 WAF-as-Code라는 접근이 등장했습니다. 규칙을 텍스트 파일로 작성해 깃 저장소에 올려두고, 그 변경 사항이 코드 리뷰와 테스트를 거쳐 배포되도록 만드는 것입니다.

WAF-as-Code, 실제로는 어떻게 동작할까

WAF-as-Code의 핵심은 WAF 규칙을 테라폼이나 클라우드포메이션 같은 인프라 코드 도구로 정의하고, 이를 CI, CD 파이프라인 안에 자연스럽게 포함시키는 것입니다. 개발자가 새로운 API 엔드포인트를 추가하면서 관련 보안 규칙도 함께 코드로 작성해 커밋하면, 그 이후 과정은 자동으로 진행됩니다.

아래 그림은 하나의 WAF 규칙 변경이 커밋부터 운영 배포까지 어떤 단계를 거치는지를 보여줍니다. 코드가 저장소에 올라오면 문법 검사를 거치고, 스테이징 환경에 자동으로 적용된 뒤, 알려진 공격 페이로드를 흘려보내 규칙이 실제로 의도대로 작동하는지 검증합니다. 이 모든 과정을 통과해야 동료의 승인을 받아 운영 환경까지 자동으로 반영됩니다.

이 흐름에서 중요한 것은 사람이 콘솔을 직접 건드릴 일이 사라진다는 점입니다. 모든 변경은 버전 관리되고, 문제가 생기면 이전 커밋으로 즉시 되돌릴 수 있습니다.

보안은 병목인가, 가속기인가

여기서 던져야 할 질문이 있습니다. 보안 검토가 배포를 늦추는 이유는 정말 보안 자체 때문일까요, 아니면 보안 검토가 수작업으로 남아 있기 때문일까요.

전통적인 방식에서는 개발과 QA가 끝난 뒤에야 보안 담당자가 수동으로 규칙을 검토합니다. 이 구조에서는 보안이 파이프라인의 맨 마지막에 위치하기 때문에, 어떤 이유로든 검토가 늦어지면 배포 전체가 밀릴 수밖에 없습니다. 반면 WAF-as-Code 방식에서는 보안 테스트가 코드 작성 시점부터 자동화된 파이프라인의 일부로 함께 돌아갑니다. 개발자는 보안팀의 승인을 기다리는 대신, 파이프라인이 자동으로 알려주는 테스트 결과를 보면서 곧바로 다음 단계로 넘어갈 수 있습니다.

두 구조의 차이는 생각보다 큽니다. 병목 구조에서는 보안이 마지막 관문 하나에 몰려 있어 그 지점이 막히면 전체가 멈춥니다. 가속기 구조에서는 보안 검증이 여러 단계에 나뉘어 병렬로 진행되기 때문에, 오히려 문제를 더 빨리 발견하고 더 빨리 고칠 수 있습니다. 조기에 발견된 문제일수록 수정 비용도 훨씬 적게 든다는 점까지 고려하면, 결과적으로 전체 개발 속도는 느려지는 것이 아니라 오히려 빨라지는 효과를 얻게 됩니다.

실제 적용 사례에서 나타나는 변화

WAF-as-Code를 도입한 조직들에서 공통적으로 나타나는 변화가 몇 가지 있습니다.

1. 보안 규칙 변경에 걸리는 시간이 며칠에서 수십 분 단위로 줄어듭니다
2. 규칙 변경 이력이 깃 커밋 로그에 고스란히 남아 감사 대응이 훨씬 수월해집니다
3. 개발자가 자신이 만든 API에 맞는 보안 규칙을 직접 작성하게 되면서 보안에 대한 이해도가 함께 높아집니다
4. 장애가 발생했을 때 문제가 된 규칙 커밋만 정확히 되돌리면 되므로 복구 시간이 짧아집니다

물론 처음부터 완벽하게 자동화되지는 않습니다. 초기에는 어떤 공격 시나리오를 테스트 단계에 포함시킬지, 오탐이 발생했을 때 파이프라인을 멈출지 경고만 할지 등을 조직 상황에 맞게 조정하는 과정이 필요합니다.

결론, 보안을 파이프라인 안으로 들여야 하는 이유

보안팀과 개발팀이 서로를 병목이라고 부르는 상황은 대개 보안이 프로세스 바깥에 별도로 존재할 때 벌어집니다. WAF 규칙을 코드로 관리하고 파이프라인 안에 통합하는 순간, 보안은 더 이상 마지막에 발목을 잡는 관문이 아니라 개발 과정 전체에 자연스럽게 녹아드는 하나의 단계가 됩니다.

지금 우리 조직의 WAF 규칙이 여전히 콘솔에서 수작업으로 관리되고 있다면, 그 규칙 하나를 코드로 옮기는 작은 실험부터 시작해보시길 권합니다.

참고

DevSecOps 및 Infrastructure as Code 관련 업계 자료를 참고하여 작성하였습니다.