클라우드라는 집짓기 (4)

무너지지 않는 집의 조건, 규칙과 질서

by Yameh

안녕하세요.

이번 화에서는 예고한 바와 같이 클라우드에서 가장 중요한 요소인 거버넌스와 보안에 대해 좀 더 이야기해 보겠습니다.




2019년 7월, Capital One은 미국 금융 역사상 최악의 데이터 유출 사고를 겪었습니다.

해커 한 명이 AWS에 저장된 1억 명의 고객 정보를 탈취했죠. 원인은 단순했습니다. 잘못 설정된 방화벽 규칙 하나, 과도하게 부여된 서버 권한 하나. 이 두 가지 '실수'가 만든 결과는 1억 5천만 달러의 합의금과 무너진 기업 신뢰였습니다.


더 충격적인 사실은 이것이 기술의 문제가 아니었다는 점입니다.

AWS가 제공하는 보안 기능은 충분히 강력했습니다.

문제는 '누가 무엇을 할 수 있는가'에 대한 명확한 규칙이 없었고, 그 규칙을 지키게 만드는 시스템이 작동하지 않았다는 것이었습니다.


지난 화에서 우리는 클라우드라는 집을 관리하는 '운영 시스템'에 대해 알아보았습니다.

하지만 아무리 좋은 시스템도, 그 안에서 사는 사람들이 따라야 할 명확한 '규칙'이 없다면 집은 금세 무질서해지고, 문단속을 잊어 도둑을 맞게 될 겁니다.


클라우드의 가장 큰 장점인 '자율성'과 '속도'는 '규칙'이라는 가드레일이 없을 때 '혼돈'과 '위험'으로 돌변합니다.

이번 화에서는 클라우드 시스템의 마지막 퍼즐이자 가장 중요한 두 기둥인 거버넌스보안에 대해 이야기하겠습니다. 이것은 '있으면 좋은 것'이 아니라, '없으면 모든 것을 잃게 되는' 필수 조건입니다.


1. 거버넌스: 자유와 통제 사이의 균형점

많은 사람들이 거버넌스(Governance)를 '통제'나 '규제'와 같은 부정적인 단어로 오해합니다. "거버넌스를 강화한다"는 말을 들으면 개발자들은 "이제 뭘 하려면 또 승인받아야 하나?"라고 한숨을 쉽니다. 하지만 진정한 거버넌스는 혁신을 막는 장애물이 아니라, 모든 구성원이 안심하고 빠르게 달릴 수 있도록 돕는 '게임의 규칙'을 만드는 것입니다.


거버넌스란 무엇인가

클라우드 거버넌스는 "누가, 무엇을, 어떻게, 얼마의 예산 안에서 사용할 수 있는가?"에 대한 명확한 원칙과 프로세스를 정의하는 활동입니다. 여기에는 표준화, 규정 준수(Compliance), 위험 관리, 아키텍처 가이드라인, 변화 관리 등 매우 광범위한 영역이 포함됩니다.


이번 화에서는 그중에서도 실무에서 가장 먼저 부딪히고, 가장 큰 영향을 미치는 세 가지 핵심 영역에 집중하겠습니다.


첫째는 권한 관리입니다.

조직 내에서 누가 어떤 클라우드 자원에 접근할 수 있는지를 정의하는 것이죠. 이를 위해 IAM(Identity and Access Management)이라는 시스템을 사용합니다.

IAM은 각 사용자와 서비스에 대해 "당신은 이 데이터베이스를 읽을 수는 있지만 삭제할 수는 없다", "이 서버는 생성할 수 있지만 프로덕션 환경의 서버는 건드릴 수 없다" 같은 세밀한 권한을 설정할 수 있게 해 줍니다. 여기서 핵심 원칙은 최소 권한의 원칙(Principle of Least Privilege)입니다.

모든 사람에게 관리자 권한을 주는 것이 아니라, 각자의 업무에 꼭 필요한 최소한의 권한만 부여하는 것입니다.


둘째는 자원 관리입니다.

클라우드 환경에서는 수천 개의 서버와 데이터베이스가 생성되고 삭제됩니다.

이들을 체계적으로 관리하기 위해 모든 자원에 태그(Tag)를 붙입니다.

태그는 일종의 이름표로, "Owner: john@company.com", "Project: mobile-app", "Environment: production", "CostCenter: marketing", "TTL: 2025-12-31" 같은 정보를 담습니다.

이렇게 하면 "마케팅팀이 운영 중인 서버가 몇 대지?", "3개월 전에 만들어진 테스트 서버 중 아직도 돌아가는 게 있나?" 같은 질문에 즉시 답할 수 있습니다.


셋째는 비용 관리입니다.

각 팀은 할당된 예산 안에서만 자원을 생성할 수 있으며, 예산의 80%를 초과하면 자동으로 팀장에게 경고가 가도록 설정합니다. 더 나아가 특정 유형의 서버는 사전 승인 없이 생성할 수 없도록 제한할 수도 있습니다. 예를 들어 매우 비싼 GPU 인스턴스는 팀장의 승인을 받아야만 생성할 수 있게 하는 것이죠.


거버넌스 실패의 대가

거버넌스가 없으면 어떤 일이 벌어질까요? 전형적인 시나리오를 그려보겠습니다.

어떤 기업이 클라우드 도입 초기 "일단 빠르게 가자"는 방침 아래 거버넌스 없이 출발했다고 가정해 봅시다. 각 부서가 자유롭게 계정을 만들고 자원을 생성했죠. 2년 후 전사 감사를 했을 때 어떤 일이 벌어질까요?


수십 개의 클라우드 계정이 존재하는데, IT 부서가 관리하는 것은 일부뿐입니다. 나머지는 누가 만들었는지, 무엇을 하는지, 심지어 비용을 누가 내고 있는지도 모르는 '유령 계정'이 될 수 있습니다.

더 심각한 것은 이 중 일부 계정에서 보안 규칙이 완전히 무시되고 있을 수 있다는 점입니다. 고객 개인정보가 담긴 데이터베이스가 인터넷에 공개된 상태로 장기간 방치되는 경우도 있습니다.


다행히 실제 유출이 발생하기 전에 발견된다면 좋겠지만, 만약 발견되었다면 어떨까요?

유럽의 GDPR 규정에 따르면 최대 연 매출의 4% 또는 2천만 유로의 벌금이 부과될 수 있습니다.

이런 상황에 처한 기업은 모든 프로젝트를 중단하고 거버넌스 체계를 처음부터 다시 구축해야 할 수도 있습니다.


거버넌스는 어떻게 정착시키는가

하지만 이런 규칙을 문서로 만든다고 저절로 지켜지지는 않습니다. 성공적인 거버넌스 정착을 위해서는 기술보다 중요한 세 가지가 있습니다.


첫째, 최고 경영진의 의지와 지원입니다.

거버넌스는 IT 부서만의 일이 아닙니다.

"우리 회사는 클라우드를 이렇게 책임감 있게 사용한다"는 원칙이 CEO와 임원진으로부터 나와야 합니다.

CEO가 전사 미팅에서 "클라우드 거버넌스는 우리의 디지털 전환 성공을 위한 필수 조건"이라고 명확히 선언하는 것만으로도 조직의 분위기는 크게 달라집니다.

이는 모든 부서의 이기주의를 넘어 전사적인 협력을 이끌어내는 가장 강력한 동력이 됩니다.


둘째, 지속적인 변화 관리입니다.

거버넌스는 새로운 '일하는 방식'을 요구합니다.

왜 모든 서버에 태그를 붙여야 하는지, 왜 예산을 지켜야 하는지를 전사에 끊임없이 소통하고 교육해야 합니다. 이는 단순한 정책 공지가 아닌, 조직 문화를 바꾸는 변화 관리(Change Management)의 영역입니다.

효과적인 방법으로는 월 1회 '클라우드 타운홀'을 열어 거버넌스를 잘 지킨 팀의 사례를 공유하고, 어려움을 겪는 팀에게는 1:1 컨설팅을 제공하는 것 등이 있습니다.


셋째, 자발적 참여 유도입니다.

규칙을 강요하기만 하면 구성원들은 어떻게든 피할 방법을 찾습니다.

중요한 것은 자발적인 참여입니다. 이를 위해 많은 기업이 CCoE(Cloud Center of Excellence)라는 조직을 만듭니다. CCoE는 클라우드 전문가들로 구성된 팀으로, '경찰'이 아닌 '가이드' 역할을 합니다. 규칙을 지키기 어려운 팀을 돕고, 표준 템플릿을 제공하며, 거버넌스를 잘 따르는 팀에게는 더 많은 자율성을 부여하는 방식으로 긍정적인 선순환을 만듭니다.


효과적인 방법 중 하나는 "거버넌스 성숙도 레벨" 같은 제도를 도입하는 것입니다.

태그 준수율, 보안 점검 통과율, 비용 예산 준수율 등을 점수화하여 일정 수준 이상의 팀에게는 승인 프로세스를 간소화해 주는 혜택을 제공하는 방식입니다. 이렇게 하면 팀들이 규칙을 '억지로 지켜야 하는 것'이 아니라 '더 빠르게 일하기 위한 조건'으로 인식하게 됩니다.


2. 보안: 타협 불가능한 첫 번째이자 마지막 원칙

만약 클라우드 전환 프로젝트에서 단 하나의 원칙만 꼽으라면, 그것은 바로 보안입니다.

보안은 프로젝트의 여러 단계 중 하나가 아닙니다. 설계의 첫 단계에서 시작하여 운영의 마지막 순간까지, 그리고 그 이후에도 계속되는, 프로젝트 전체를 관통하는 '처음이자 마지막 원칙'입니다.


보안 사고는 일어난다

한 대형 병원이 랜섬웨어 공격을 받았다고 가정해 봅시다.

공격자들이 병원의 클라우드 백업 시스템에 침투하여 모든 환자 데이터를 암호화했습니다.

병원은 수 주 동안 전자차트를 사용할 수 없었고, 수술 일정이 연기되었으며, 응급실은 종이 차트로 돌아가야 했습니다. 피해액은 수십억 원에 달했고, 환자들의 신뢰는 땅에 떨어졌습니다.


이런 사고의 전형적인 원인은 기본적인 보안 원칙의 무시입니다.

백업 시스템의 관리자 계정 비밀번호가 단순하고, 이 계정이 인터넷에서 직접 접근 가능한 상태로 방치되는 경우가 많습니다. 최신 클라우드 인프라를 사용하더라도 가장 기본적인 보안 원칙이 지켜지지 않으면 무용지물입니다.


심층 방어: 한 겹이 아닌 여러 겹의 보호막

클라우드 보안은 비싼 방화벽 하나를 설치한다고 끝나는 문제가 아닙니다.

외부의 해커부터 내부의 실수까지, 모든 위협에 대비하는 심층 방어(Defense in Depth) 전략이 필요합니다. 마치 중세 성곽처럼 여러 겹의 방어선을 구축하는 것입니다.


첫 번째 방어선은 네트워크 보안입니다.

VPC라는 견고한 울타리를 치고, 꼭 필요한 대문만 최소한으로 열어둡니다.

여기서 보안 그룹(Security Group)NACL(Network Access Control List)이라는 두 가지 도구를 사용합니다. 보안 그룹은 각 서버마다 "어떤 IP에서, 어떤 포트로 접근할 수 있는가"를 정의하는 가상의 방화벽입니다.

예를 들어 웹 서버는 전 세계 누구에게나 80번 포트(HTTP)와 443번 포트(HTTPS)를 열어두지만, 데이터베이스는 오직 웹 서버에서만 3306번 포트(MySQL)로 접근할 수 있도록 제한합니다.


두 번째 방어선은 접근 제어입니다.

앞서 이야기한 IAM을 통해 '최소 권한의 원칙'을 철저히 적용합니다.

한 금융사의 실제 규칙을 보겠습니다. 일반 개발자는 개발 환경에서만 서버를 생성하고 삭제할 수 있습니다. 운영 환경의 서버를 건드리려면 시니어 개발자 권한이 필요하고, 데이터베이스의 데이터를 직접 수정하려면 DBA(데이터베이스 관리자)의 임시 권한 승인을 받아야 합니다. 이 승인은 2시간 후 자동으로 만료됩니다.


더 나아가 MFA(Multi-Factor Authentication, 다중 인증)를 필수로 적용합니다.

비밀번호만으로는 부족합니다. 로그인할 때 휴대폰 앱이나 하드웨어 토큰으로 두 번째 인증을 해야 합니다. Capital One 사고 이후, 대부분의 기업이 관리자 계정에는 MFA를 필수로 요구하고 있습니다.


세 번째 방어선은 데이터 보안입니다.

고객 정보나 금융 데이터처럼 중요한 정보는 반드시 암호화하여 '금고'에 보관해야 합니다.

암호화는 두 가지 상태에서 이루어집니다. 하나는 저장 시 암호화(Encryption at Rest)로, 데이터베이스나 스토리지에 저장될 때 암호화하는 것입니다.

다른 하나는 전송 시 암호화(Encryption in Transit)로, 데이터가 네트워크를 통해 이동할 때 암호화하는 것입니다. 이렇게 하면 설령 데이터가 유출되더라도 암호화되어 있어 실제로는 읽을 수 없습니다.


네 번째 방어선은 위협 탐지 및 대응입니다.

아무리 방어를 잘해도 완벽할 수는 없습니다. 중요한 것은 침입을 빠르게 발견하고 대응하는 것입니다.

AWS GuardDuty, Azure Sentinel, Google Cloud Security Command Center 같은 도구들은 24시간 우리 클라우드 환경을 감시합니다. 누군가 새벽 3시에 외국 IP에서 로그인을 시도하거나, 평소와 다르게 대량의 데이터를 다운로드하면 즉시 경보를 울립니다.

이런 자동 탐지 시스템이 없다면 어떻게 될까요?

토요일 새벽에 오래된 개발자 계정으로 로그인 시도가 있어도 아무도 모를 것입니다. 이미 퇴사한 직원의 계정이 다크웹에서 유출되어 공격자가 주말 내내 시스템에 접근할 수 있는 상황이 벌어질 수 있습니다.

자동화된 위협 탐지와 대응 시스템은 이런 위험을 실시간으로 차단합니다.


보안은 비용이 아니라 보험이다

보안에 대한 투자는 비용이 아니라 보험입니다.

한 조사에 따르면, 대규모 보안 사고 한 번의 평균 피해액은 약 50억 원입니다.

여기에는 직접적인 복구 비용뿐만 아니라 고객 이탈, 브랜드 가치 하락, 법적 비용, 규제 당국의 벌금까지 모두 포함됩니다. 반면 제대로 된 보안 시스템을 구축하는 데는 연간 2~3억 원이면 충분합니다.


더 중요한 것은 신뢰입니다. 고객들은 자신의 개인정보를 맡긴 회사가 보안에 얼마나 진지한지를 봅니다.

단 한 번의 보안 사고는 지난 10년간 쌓아 올린 기업의 명성과 가치를 한순간에 무너뜨릴 수 있습니다.

보안은 타협할 수 없는, 비즈니스 생존의 조건입니다.


마무리: 규칙이 혁신을 만든다

우리는 7가지 필수 도구를 시작으로 인프라를 설계하고, 실제 웹사이트를 조합했으며, 운영 시스템을 구축하고, 마침내 모두가 따라야 할 규칙과 질서까지 세웠습니다.


기억해야 할 마지막 교훈은 이것입니다. 거버넌스와 보안은 혁신의 발목을 잡는 '브레이크'가 아닙니다.

오히려 모든 구성원이 안심하고 더 빠르게 달릴 수 있도록 지켜주는 '안전벨트'이자 '가드레일'입니다.


규칙이 없는 자유는 혼돈을 낳고, 통제만 있는 조직은 정체됩니다.

잘 만들어진 규칙과 질서 위에서만이 진정한 자율성과 창의성, 그리고 지속 가능한 혁신이 피어날 수 있습니다.




클라우드는 도구입니다. 이 도구를 어떻게 사용하느냐는 결국 우리에게 달려 있습니다.

단단한 기초 위에 세워진 클라우드는 기업의 디지털 전환을 성공으로 이끌 것이고, 흔들리는 기초 위의 클라우드는 언젠가 무너질 것입니다.


여러분의 클라우드는 어떤 기초 위에 서 있나요?


이전 04화클라우드라는 집짓기(3)