클라우드에서 데이터 털리면 누구 책임? 비개발자가 파고든 '공유 책임'의 실체

안녕하세요, 코딩은 못 하지만 IT가 너무 궁금한 비개발자 루카(Luka)입니다.

thumbnail

최근 뉴스에서 기업들의 클라우드 데이터 유출 사고 소식을 자주 접했어요. 그때마다 "클라우드는 안전한 거 아니었어?"라는 의문과 함께, "이게 과연 누구 책임일까?" 하는 궁금증이 솟구치더라고요. 특히 '공유 책임 모델(Shared Responsibility Model)'이라는 알쏭달쏭한 개념을 접하고는, "공유? 그럼 서로 미루기 딱 좋겠네!" 하는 편견이 생기기도 했습니다. 그래서 제가 직접 이 공유 책임 모델이 대체 뭔지, 그리고 이게 개발자들의 실제 현실에서 어떻게 작동하는지 비개발자의 시선으로 파헤쳐 봤습니다.

클라우드 보안, 대체 왜 이렇게 복잡한가요?

제가 IT 기사를 읽으면서 느낀 건, 클라우드가 엄청나게 편리하고 유연하지만, 그만큼 보안이 만만치 않다는 거였어요. 온프레미스(물리 서버를 직접 관리하는 방식)에서는 서버실부터 네트워크, 소프트웨어까지 모든 걸 회사에서 책임졌다면, 클라우드는 이 모든 걸 '빌려 쓰는' 개념이잖아요? 그런데 빌려 쓰는 게 어떨 때는 건물만 빌리는 건지, 가구까지 포함해서 빌리는 건지 헷갈릴 때가 많습니다. 바로 이 지점에서 '누구 책임'이라는 문제가 복잡해지는 거였어요.

클라우드 제공자들(AWS, Azure, GCP 같은 곳들이죠)은 "우리 클라우드 서비스는 정말 안전합니다!"라고 광고하지만, 동시에 "보안은 고객과 저희의 '공유 책임'입니다"라고도 말합니다. 솔직히 처음에 이 문구를 보고는 "결국 사고 나면 고객 탓으로 돌리려는 건가?" 하는 의심부터 들었습니다. 제 친구 개발자에게 물어봤더니, 그 친구도 "에이, 책임 회피 문구 아니겠어?"라고 대수롭지 않게 말하더라고요. 하지만 직접 파고들어 보니, 이 모델이 나름의 합리적인 이유가 있었습니다.

'공유 책임 모델'의 진짜 의미: "클라우드 자체의 보안" vs. "클라우드 안에서의 보안"

이 모델의 핵심은 책임을 두 가지로 명확히 나눈다는 거였습니다. 바로 '클라우드 자체의 보안(Security of the Cloud)'과 '클라우드 안에서의 보안(Security in the Cloud)'이죠.

1. 클라우드 자체의 보안: 클라우드 제공자(AWS, Azure, GCP)의 책임

이 부분은 말 그대로 클라우드 서비스를 구성하는 '인프라' 자체의 보안을 의미합니다. 물리적인 데이터 센터의 보안, 서버와 네트워크 장비의 안정성, 가상화 기술의 무결성 등이 여기에 해당합니다. 예를 들어, 아마존 웹 서비스(AWS)의 경우, 공식 문서에 "AWS는 데이터 센터의 물리적 보안에 대해 ISO 27001, SOC 1/2/3 등 70개 이상의 규정 준수 인증을 획득했다"고 명시되어 있었습니다. 그들은 이런 기반 시설을 24시간 감시하고 관리하며, 해킹이나 물리적 침입으로부터 보호할 의무가 있는 거죠.

저는 이 부분이 "건물주가 건물의 뼈대와 공용 시설을 안전하게 관리하는 것"과 같다고 이해했어요. 건물에 불이 나지 않도록 소방 시설을 갖추고, 지진에도 견딜 수 있게 튼튼하게 짓는 책임은 건물주에게 있는 거죠.

2. 클라우드 안에서의 보안: 클라우드 사용자(기업, 개발팀)의 책임

여기가 바로 저희 같은 비개발자뿐만 아니라, 많은 개발자들도 혼란스러워하는 부분입니다. 제공자가 튼튼한 건물을 지어줬다면, 그 안에서 어떤 가구를 들이고, 문을 잠그고, 귀중품을 어떻게 보관할지는 '세입자(사용자)'의 책임이라는 거죠.

구체적으로는 다음과 같은 항목들이 포함됩니다:

데이터 보안: 저장된 데이터 암호화, 데이터 접근 권한 설정
네트워크 구성: 가상 네트워크 설정, 방화벽(Security Group) 규칙 설정
운영체제 및 애플리케이션 보안: OS 패치, 설치하는 소프트웨어의 취약점 관리
계정 및 접근 관리(IAM): 사용자 ID 및 비밀번호 관리, 다단계 인증(MFA) 적용, 최소 권한 원칙 적용

제가 찾아본 한 보안 보고서에 따르면, 클라우드 데이터 유출 사고의 80% 이상이 클라우드 제공자의 인프라 문제가 아니라, 사용자의 잘못된 구성(misconfiguration)이나 부적절한 접근 제어 때문이라고 합니다. 제가 들었던 "클라우드 보안 사고는 대부분 사용자 잘못"이라는 말이 정말 현실이었던 거죠.

이 부분이 바로 개발자들이 엄청난 스트레스를 받는 지점이기도 합니다. 단순히 코드를 짜는 것뿐만 아니라, 클라우드 환경의 복잡한 보안 설정을 이해하고 정확하게 적용해야 하니까요. "아니, 그냥 내 코드만 잘 짜면 안 되는 거야?"라는 불만을 친구 개발자에게서 여러 번 들었습니다.

비개발자 루카가 직접 해 본 클라우드 보안 맛보기 (feat. 명령어)

코딩은 못 하지만, 궁금한 건 못 참는 루카. 클라우드 보안 책임이 사용자에게 있다는 말에, 대체 뭘 어떻게 해야 하는지 궁금해서 개발자들이 주로 사용하는 클라우드 서비스(AWS)의 'S3 버킷' 보안 설정을 확인하는 명령어를 찾아봤습니다. S3 버킷은 데이터를 저장하는 창고 같은 거라고 보시면 됩니다. 이게 잘못 설정되면 전 세계 누구에게나 내 데이터가 노출될 수 있다는 기사를 보고 경악했거든요.

1. S3 버킷 공개 여부 확인 명령어

제가 찾아보니 터미널에서 aws s3api get-bucket-policy-status라는 명령어를 사용하면 S3 버킷의 '공개 설정 상태'를 확인할 수 있다고 합니다.

aws s3api get-bucket-policy-status --bucket your-bucket-name --query "PolicyStatus.IsPublic"

위 명령어를 치면 True나 False가 나온다고 합니다. 만약 True가 나온다면 "아, 이 버킷은 외부에 공개될 가능성이 있구나" 하고 바로 알아채야 한다고 해요. 저처럼 비개발자도 이 한 줄로 '우리 회사 중요 데이터가 혹시 노출된 건 아닐까?' 하는 일차적인 점검을 해볼 수 있다는 게 놀라웠습니다. 물론 your-bucket-name 자리에 실제 버킷 이름을 넣어야겠죠?

2. S3 버킷에 HTTPS 접속만 허용하는 IAM 정책 (예시)

개발자들이 가장 많이 다루는 보안 설정 중 하나가 바로 'IAM(Identity and Access Management)' 정책이라고 합니다. 누가 어떤 자원에 접근할 수 있게 할지 정하는 '권한 명세서' 같은 건데요. 저는 S3 버킷에 무조건 HTTPS(암호화된 통신)로만 접근하게 만드는 정책을 찾아봤습니다. HTTP(암호화되지 않은 통신)로 접근하면 중간에 데이터가 탈취될 위험이 크다고 하더라고요.

이 코드는 개발자들이 주로 사용하는 JSON 형식의 IAM 정책 예시입니다. 특정 S3 버킷에 대해 암호화되지 않은(HTTP) 접근을 완전히 차단하는 내용입니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::my-super-secret-bucket",
        "arn:aws:s3:::my-super-secret-bucket/*"
      ],
      "Condition": {
        "Bool": { "aws:SecureTransport": "false" }
      }
    }
  ]
}

제가 비록 이 코드를 직접 작성하거나 배포할 수는 없지만, Effect": "Deny", Condition": { "Bool": { "aws:SecureTransport": "false" } } 같은 부분을 보니 "아, 안전하지 않은 접근은 막아버리는구나!" 하는 걸 직관적으로 알 수 있었습니다. 개발자 친구 말로는 이런 정책 하나 잘못 설정해서 큰 사고가 터지는 경우가 허다하다고 해요.

서비스 모델별 책임 범위: IaaS, PaaS, SaaS, 헷갈리면 이걸 보세요!

클라우드 서비스를 찾아보면 IaaS, PaaS, SaaS 같은 어려운 용어가 자꾸 나옵니다. 솔직히 저도 처음에 이게 뭔 소린가 싶어서 한참 헤맸는데요. 이게 바로 '공유 책임'의 경계선이 어디까지인지 결정하는 중요한 요소였습니다!

간단히 말해, 클라우드 제공자가 '어디까지 관리해 주느냐'에 따라 사용자의 책임 범위가 달라집니다. 제가 비개발자의 눈높이에서 이해한 내용을 표로 정리해 봤습니다.

책임 항목	온프레미스 (On-Premise)	IaaS (예: EC2 서버)	PaaS (예: RDS 데이터베이스)	SaaS (예: G-Suite, Dropbox)
물리적 보안	사용자 (직접 관리)	클라우드 제공자 (데이터센터)	클라우드 제공자	클라우드 제공자
네트워크 인프라	사용자 (회선, 라우터)	클라우드 제공자 (가상 네트워크)	클라우드 제공자	클라우드 제공자
가상화	사용자 (하이퍼바이저)	클라우드 제공자	클라우드 제공자	클라우드 제공자
운영체제(OS)	사용자	사용자 (패치, 업데이트)	클라우드 제공자 (기본 OS)	클라우드 제공자
런타임 및 미들웨어	사용자	사용자	클라우드 제공자 (설정은 사용자)	클라우드 제공자
애플리케이션	사용자	사용자	사용자	클라우드 제공자
데이터 및 접근 제어	사용자 (데이터 관리, 권한 설정)	사용자 (데이터 암호화, IAM)	사용자 (데이터 암호화, IAM)	사용자 (데이터) / 제공자 (접근 제어 메커니즘)

표 해석:

IaaS (Infrastructure as a Service): 클라우드에서 가상 서버(예: AWS EC2)만 빌려 쓰는 개념입니다. 건물만 빌린 격이라, OS 설치부터 애플리케이션, 데이터까지 거의 모든 보안 책임이 사용자에게 있습니다. 개발자가 가장 많은 보안 부담을 지는 모델이죠.
PaaS (Platform as a Service): 미리 설정된 개발 환경(예: AWS RDS 데이터베이스)을 빌려 쓰는 개념입니다. OS와 런타임까지는 제공자가 관리해주지만, 그 위에서 돌아가는 애플리케이션이나 데이터 보안은 여전히 사용자의 몫입니다. "인테리어 된 집" 정도라고 생각하면 됩니다.
SaaS (Software as a Service): 완전한 소프트웨어 서비스(예: Gmail, Dropbox)를 사용하는 개념입니다. 사용자는 로그인해서 쓰기만 하면 되니, 물리적 보안부터 애플리케이션까지 대부분의 책임이 제공자에게 넘어갑니다. "풀옵션 원룸" 같은 거죠. 하지만 '데이터' 자체와 '데이터에 누가 접근할 수 있게 할지' 설정하는 것은 여전히 사용자 책임입니다. (예: 내 드롭박스 파일을 누구와 공유할지)

이 표를 보니, "아, 내가 어떤 클라우드 서비스를 쓰느냐에 따라 책임 범위가 확확 달라지는구나!" 하고 무릎을 탁 쳤습니다. 개발자들이 PaaS 환경에서는 OS 패치 같은 걱정은 덜 수 있지만, IaaS에서는 그걸 다 직접 해야 하는 이유를 알게 된 거죠.

비개발자가 헷갈리기 쉬운 부분 & 루카의 해결법

제가 이 공유 책임 모델을 파헤치면서 헷갈렸던 부분들을 정리하고, 어떻게 이해하면 좋을지 저만의 해결법을 공유합니다.

1. "공유 책임"이 곧 "서로 책임 미루기"는 아니다?

헷갈리는 이유: '공유'라는 단어 때문에 "이것도 네 책임, 저것도 네 책임" 하며 서로에게 책임을 전가할 수 있을 것 같았습니다. 사고가 나면 클라우드 제공자는 "고객의 설정 오류다!"라고 하고, 고객은 "제공자가 충분히 안전하게 만들지 않았다!"고 싸울 그림이 그려졌죠.
루카의 해결법: 이건 '레이어별 책임 분할'로 봐야 합니다. 마치 자동차 사고가 났을 때, 도로 공사는 '도로 자체'의 안전을, 자동차 제조사는 '차량 자체'의 안전을, 운전자는 '운전 행위'에 대한 책임을 지는 것과 같습니다. 클라우드 제공자는 '기반 인프라'라는 도로와 자동차 제조에 집중하고, 사용자는 '그 위에서 안전하게 운전하는 것'에 집중하는 거죠. 즉, 서로 다른 '영역'에 대한 독립적인 책임이 명확히 구분됩니다.

2. 클라우드 계정 관리(IAM), 왜 그렇게 중요하다고 난리일까?

헷갈리는 이유: 그냥 아이디랑 비밀번호 잘 설정하면 되는 거 아니야? 회사 규모가 커지면 IT 부서가 알아서 해주는 거 아니었어?
루카의 해결법: 클라우드 계정은 '회사 전체 자산에 접근할 수 있는 열쇠'와 같습니다. 온프레미스에서는 각 서버마다 다른 비밀번호를 설정했다면, 클라우드에서는 단 하나의 계정(Root 계정)으로 회사의 모든 클라우드 자원을 통제할 수 있습니다. 이걸 해킹당하면 진짜 큰일 나는 거죠. 제가 찾아보니 다단계 인증(MFA)을 적용하면 무단 접근 시도 중 99.9%를 막을 수 있다고 합니다. 이 정도면 개발자뿐만 아니라 회사 모든 구성원이 클라우드 계정 보안의 중요성을 인지하고, 강력한 비밀번호와 MFA 사용을 생활화해야 한다는 생각이 들었습니다. '최소 권한 원칙(Least Privilege)'이라는 것도 중요한데, 필요한 사람에게 필요한 권한만 주는 것이라고 해요. 저처럼 코딩은 못 해도, 회사 메일을 쓰거나 클라우드 서비스에 로그인할 때 2단계 인증을 꼭 설정하는 것부터 시작해야겠다는 생각을 했습니다.

3. 개발자가 쓰는 오픈 소스 라이브러리 보안은 누구 책임인가?

헷갈리는 이유: 개발자들이 프로그램을 만들 때, 다른 사람들이 만들어 놓은 오픈 소스 코드나 라이브러리 가져다 쓰는 경우가 많다고 들었어요. 그런데 그 라이브러리에 보안 취약점이 발견되면, 그걸 사용한 회사 책임인가, 아니면 라이브러리를 만든 사람 책임인가?
루카의 해결법: 이 부분은 전적으로 '사용자(개발자/회사)'의 책임입니다. 클라우드 제공자는 '안전한 환경'을 제공할 뿐, 그 안에서 어떤 '재료'를 가져다 쓰느냐는 사용자의 선택이자 책임입니다. 마치 식당 주인이 싱싱한 식자재(오픈 소스 라이브러리)를 직접 검증하고 사용하는 것과 같습니다. 보안 취약점이 있는 라이브러리를 사용해서 해킹당했다면, 이는 개발자가 그 라이브러리의 위험성을 제대로 파악하지 못했거나 업데이트를 소홀히 한 책임이 됩니다. 그래서 개발자 친구들은 주기적으로 사용 중인 라이브러리의 보안 취약점을 검사하는 도구들을 사용한다고 하더라고요.

개발자가 겪는 '공유 책임'의 진짜 현실

제가 직접 파고들어 보니, 이 '공유 책임 모델'은 굉장히 합리적인 분담처럼 보였습니다. 하지만 개발자 친구들의 이야기를 들어보니, 현실은 그리 녹록지 않다는 걸 알게 됐습니다.

방대한 책임 범위: 개발자는 코드 개발은 물론이고, 클라우드 인프라 구성, 네트워크 설정, 데이터베이스 관리, 계정 권한 설정, 로그 모니터링, OS 패치까지 이 모든 '클라우드 안에서의 보안'을 신경 써야 합니다.
클라우드 복잡성: 클라우드 서비스는 매년 수백 개의 새로운 기능과 서비스가 쏟아져 나옵니다. 이 모든 변화를 따라가면서 보안까지 완벽하게 챙기는 건 거의 불가능에 가깝다고 해요. 공식 문서만 해도 수십만 페이지가 넘는다고 하니, 그걸 다 읽고 이해하는 것만 해도 엄청난 업무겠죠.
보안 전문성 부족: 많은 개발자들이 보안 전문가가 아닙니다. 코딩 능력은 뛰어나지만, 네트워크 보안, 암호화, 접근 제어 같은 전문 보안 지식은 부족할 수밖에 없죠. 그런데 '공유 책임 모델'은 이들에게 보안 전문가 수준의 지식을 요구하는 것과 다름없습니다. "코딩도 바빠 죽겠는데, 보안 설정까지 내가 다 해야 돼?"라는 불만이 터져 나오는 이유입니다.
자동화의 필요성: 개발자들이 이 모든 보안 책임을 수동으로 감당하기는 불가능합니다. 그래서 'Infrastructure as Code(IaC)'나 'DevSecOps' 같은 개념이 중요해진다고 합니다. 미리 정해진 보안 규칙에 따라 자동으로 인프라를 배포하고, 코드에 보안 검사를 통합하는 방식이죠. 찾아보니 이런 자동화 도구를 잘 활용하면, 수동 설정 시 발생할 수 있는 휴먼 에러를 획기적으로 줄여준다고 합니다.

마치며: 비개발자도 클라우드 보안, 어렵지 않아요!

처음엔 어렵게만 느껴졌던 '클라우드 보안'과 '공유 책임 모델'. 직접 파고들어 보니, 클라우드 제공자와 사용자의 역할이 명확히 나뉘어 있다는 걸 알 수 있었습니다. 특히 "클라우드 안에서의 보안"은 우리 모두의 관심이 필요한 영역이라는 것을요.

제가 비록 코딩은 못 해도, 이렇게 하나하나 파헤쳐 보면서 클라우드라는 거대한 IT 세상을 조금 더 이해할 수 있게 되었습니다. 중요한 건, "IT는 어려워"라고 지레 겁먹지 않고, 저처럼 "이게 뭔데? 궁금하잖아!" 하는 마음으로 들여다보는 용기 아닐까요? 우리처럼 비개발자도 충분히 이해하고, 나아가 더 안전한 디지털 세상을 만드는 데 기여할 수 있다고 믿습니다.

다음에는 또 어떤 궁금증을 파헤쳐 볼지 기대해주세요! 비개발자 루카였습니다!

핵심 요약 3줄

클라우드 보안은 '클라우드 제공자'와 '클라우드 사용자'의 책임 영역이 명확히 나뉜 '공유 책임 모델'입니다.
제공자는 '클라우드 자체의 안전(인프라)', 사용자는 '클라우드 안에서의 안전(데이터, 애플리케이션, 설정)'을 책임집니다.
대부분의 클라우드 보안 사고는 사용자 책임 영역, 특히 잘못된 설정이나 부적절한 접근 제어에서 발생합니다.

자주 묻는 질문 (FAQ)

Q: 클라우드 제공자가 해킹당하면 제 데이터도 위험한가요? A: 클라우드 제공자 자체의 인프라가 해킹당할 확률은 매우 낮습니다. 이들은 막대한 자원을 들여 최고의 보안 시스템을 구축합니다. 하지만 만약 제공자의 기반 인프라가 뚫린다면, 이는 전 세계적인 재앙에 가까울 것이며, 당연히 고객 데이터도 위험해질 수 있습니다. 그러나 대부분의 사고는 사용자의 설정 오류(예: S3 버킷 공개)나 약한 접근 제어 때문에 발생합니다.

Q: 비개발자도 클라우드 보안에 대해 알아야 할까요? A: 네, 그럼요! 비개발자라도 클라우드 환경에서 업무를 처리하거나 데이터를 다룬다면 최소한의 보안 지식은 필수적입니다. 강력한 비밀번호 사용, 다단계 인증(MFA) 적용, 중요 파일 공유 시 주의, 피싱 메일 경계 등 기본적인 보안 수칙만으로도 회사의 전체적인 보안 수준을 높일 수 있습니다. '공유 책임 모델'은 모두의 관심이 필요하다는 것을 보여줍니다.

Q: 가장 먼저 시작해야 할 클라우드 보안 조치는 무엇인가요? A: 개인적으로는 클라우드 계정의 다단계 인증(MFA) 설정과 '최소 권한 원칙' 적용이 가장 중요하다고 생각합니다. 회사에서 클라우드를 사용한다면, 불필요한 사람에게 불필요한 접근 권한을 주지 않고, 반드시 필요한 경우에만 최소한의 권한을 부여하는 것이 핵심입니다. 그리고 주기적으로 보안 설정을 점검하고, 사용하지 않는 계정이나 리소스는 삭제하는 습관을 들이는 것이 좋습니다.