(4/5) AWS 보안·거버넌스 면접 — IAM 부터 금융권 규제 대응까지

August 5, 2026 10 분 소요

🧭 AWS 전문가 면접 가이드 — 면접관을 위한 배경 지식과 질문 5부작 — “AWS 시니어를 뽑아야 하는데 정작 내가 AWS 를 잘 모른다.” 꽤 흔한 상황이에요. 서비스 이름을 200 개 외운다고 면접이 되는 것도 아니고요. 이 시리즈는 면접관 입장에서 필요한 것만 골라 담았습니다. 각 편은 ① 5분이면 따라오는 배경 설명 → ② 실제로 던질 질문 → ③ 답을 못 알아들어도 쓸 수 있는 채점 포인트 순서로 이어져요. 전체 그림과 면접 전략을 먼저 잡고(1편), 인프라·아키텍트(2편), DevOps·플랫폼(3편), 보안·거버넌스와 금융권 규제(4편), 데이터·AI 플랫폼과 60분 진행 시나리오(5편)까지 갑니다. 전체 5편.

Summary

보안 갈래는 면접 난이도가 가장 높아요. 이유가 좀 얄궂은데, 보안은 잘하면 아무 일도 안 일어나기 때문입니다. 성과가 “사고가 없었음” 이라서 실력이 눈에 안 보여요.

그래서 이 편의 질문들은 “무엇을 막았나” 대신 “무엇을 회수했나” 를 겨냥합니다. 권한을 준 이야기는 누구나 하지만, 권한을 도로 뺏은 이야기는 실제로 해본 사람만 할 수 있거든요. 그건 조직 저항이 있는 일이라 기억에 남습니다.

그리고 금융권이라면 여기에 하나가 더 붙어요. 기술적으로 안전한 것과 감독당국에 안전하다고 증명하는 것은 다른 일입니다. 이 둘을 다 해본 사람인지가 규제 산업 채용의 핵심이에요.

💡 이 글에서 다루는 것

IAM — 왜 어렵고, 뭐가 위험 신호인가

암호화와 비밀 관리 — 하드코딩이 왜 최대 사고 원인인가

흔적 남기기 — CloudTrail · Config · 탐지 서비스

가장 흔한 사고 유형 — S3 노출, 열린 보안 그룹, 남은 권한

금융권 특수 사정 — 망분리, 클라우드 이용 절차, 안전성 평가

질문 12개 + 채점 포인트

면접 직전 5분 요약

1. 배경 — IAM, 여기가 전부예요

AWS 보안의 8할은 IAM(Identity and Access Management) 이에요. “누가 무엇을 할 수 있는가” 를 정하는 곳입니다.

네 가지 단어만 알면 돼요

단어	뜻
사용자 (User)	사람 한 명 또는 프로그램 하나에 주는 계정
그룹 (Group)	사용자를 묶어서 권한을 한꺼번에 주는 것
정책 (Policy)	“이건 되고 저건 안 된다” 를 적어둔 규칙 문서
역할 (Role)	필요할 때 잠깐 빌려 쓰는 권한 꾸러미

여기서 가장 중요한 건 역할이에요. 요즘 AWS 보안의 기본 사고방식이 “고정 권한을 나눠주지 말고, 필요할 때 잠깐 빌려주자” 거든요.

왜냐면 고정 자격증명은 새어나가면 끝이기 때문이에요. 예전에는 프로그램이 AWS 를 쓰려면 액세스 키(아이디·비밀번호 같은 긴 문자열)를 발급받아 코드나 설정 파일에 넣었어요. 그런데 그게 실수로 깃허브에 올라가는 사고가 셀 수 없이 많았습니다. 역할을 쓰면 키 자체가 없어지고, 대신 몇 시간 뒤 자동으로 만료되는 임시 자격증명이 발급돼요.

🚨 면접에서 이건 꼭 물어보세요. — “장기 액세스 키를 몇 개나 쓰고 계시나요?” 시니어 보안 담당자라면 “거의 없앴고, 남은 건 어디 어디” 라고 답할 수 있어야 해요. “직원마다 하나씩 발급해서 씁니다” 면 오래된 방식에 머물러 있는 겁니다.

최소권한 — 말은 쉬운데

“딱 필요한 만큼만 권한을 준다” 는 원칙이에요. 모두가 동의하지만 실제로 하는 조직은 드물어요. 왜냐면 귀찮고, 권한이 부족하면 개발자가 항의하고, 넉넉하게 주면 아무도 불평 안 하거든요.

그래서 현실에서는 정책에 와일드카드(*) 가 남발됩니다. “모든 작업을 모든 자원에 허용” 같은 정책이요. 이건 사실상 권한 관리를 안 하는 것과 같아요.

이 영역에서 진짜 경험을 가려내는 질문은 이거예요.

“넓게 열려 있던 권한을 좁혀본 적 있으세요? 어떻게 진행하셨나요?”

경험자는 방법을 압니다. 실제 사용 기록을 뒤져서 쓰지 않는 권한부터 걷어내는 방식이요. AWS 에도 이걸 도와주는 기능(액세스 어드바이저, IAM Access Analyzer)이 있어서, 그 이름이 나오면 실제로 해본 사람이에요. 그리고 반드시 조직 저항 이야기가 딸려 나옵니다. “개발팀이 반발해서 단계적으로 했어요” 같은.

루트 계정

계정을 처음 만들 때 생기는 최고 권한 계정이에요. 규칙은 단순합니다. 평소에 절대 쓰지 않고, 다중 인증을 걸어 금고에 넣어두는 것. 후보자가 이걸 모르면 기초가 없는 거예요.

2. 배경 — 암호화와 비밀 관리

두 종류의 암호화

저장 중 암호화 — 디스크나 S3 에 저장된 상태에서 암호화. 요즘은 켜는 게 기본이고 성능 부담도 거의 없어요.
전송 중 암호화 — 네트워크를 지날 때 암호화. HTTPS 가 대표적이죠.

둘 다 “켰냐 안 켰냐” 보다 “안 켜진 게 있는지 어떻게 확인하냐” 가 더 좋은 질문이에요. 수백 개 자원 중 하나가 빠지는 건 흔한 일이라, 자동으로 점검하는 체계가 있는지를 봅니다.

키 관리 — KMS

암호화를 하려면 열쇠가 필요하고, 그 열쇠를 관리하는 서비스가 KMS 예요. 봐야 할 포인트는 두 가지입니다.

키 정책 — 이 열쇠를 누가 쓸 수 있는지. 데이터에 접근 권한이 없어도 열쇠 권한이 있으면 뚫릴 수 있어서, 권한과 키를 분리해서 이중 잠금을 거는 설계가 있어요. 이 얘기를 하는 후보자는 깊이가 있습니다.
키 회전 — 주기적으로 열쇠를 갈아끼우는 것. 규제 환경에서는 요구되는 경우가 많아요.

비밀 관리 — 여기가 실제 사고 지점

비밀번호, API 토큰, DB 접속 정보 같은 것들이요. 클라우드 사고의 상당수가 여기서 시작돼요. 코드에 박아두거나, 설정 파일에 넣어두거나, 채팅으로 주고받거나 해서요.

정답은 Secrets Manager 나 Parameter Store 같은 전용 저장소에 넣고, 애플리케이션이 실행 시점에 꺼내 쓰는 거예요.

💡 좋은 질문 — “DB 비밀번호가 지금 어디에 있나요? 그리고 마지막으로 바꾼 게 언제인가요?” 두 번째 질문이 핵심이에요. 저장소에 잘 넣어뒀어도 5년째 같은 비밀번호면 그건 관리가 아니거든요.

3. 배경 — 흔적을 남기고, 실제로 보기

사고는 결국 납니다. 그때 무슨 일이 있었는지 재구성할 수 있느냐가 보안 조직의 실력이에요.

서비스	하는 일	면접에서 보는 것
CloudTrail	누가 언제 어떤 API 를 호출했나	켜져 있는지, 삭제 못 하게 보호했는지
Config	설정이 규칙을 지키고 있나	규칙을 직접 만들어봤는지
GuardDuty	수상한 활동 자동 탐지	나온 알림을 실제로 처리하는지
Security Hub	위 결과를 모아 보기	모아만 두는지, 줄여나가는지

🚨 한 가지 함정이 있어요. CloudTrail 로그가 침해당한 계정 안에 그대로 있으면, 공격자가 로그를 지울 수 있습니다. 그래서 로그를 별도 계정에 쌓고, 지울 수 없게 잠그는 구성이 중요해요. 이 이야기를 꺼내는 후보자는 실제 사고 대응을 고민해본 사람입니다.

그리고 이게 이 편에서 가장 강력한 질문이에요.

“CloudTrail 로그를 실제로 뒤져서 뭔가를 조사해본 적 있나요?”

켜두는 건 클릭 한 번이라 다들 해요. 뒤져본 사람은 다릅니다. 뒤져본 사람은 로그가 얼마나 방대하고, 원하는 걸 찾기가 얼마나 번거로운지 압니다. 그래서 답변에 반드시 도구 이야기(Athena 로 쿼리했다는 등)나 고생담이 섞여요.

4. 배경 — 가장 흔한 사고 세 가지

면접에서 “이런 사고 겪어보셨나요?” 로 바로 쓸 수 있는 목록이에요.

① S3 버킷 공개 노출
클라우드 데이터 유출 사고의 고전이에요. 실수로 공개 설정이 되어 파일이 인터넷에 노출되는 거죠. 지금은 AWS 가 기본적으로 막아주지만, 누군가 그 차단을 풀 수 있다는 게 문제예요. 조직 차원에서 아예 못 풀게 막는 방법이 있고, 그걸 아는지가 포인트입니다.

📎 관련해서 S3 접근 통제를 실제로 설계한 기록이 블로그에 있어요. S3 쓰기 경로 접근 제한 — 누가 저장하나 편을 보시면 후보자가 이 주제로 무슨 말을 할지 감이 잡힙니다.

② 열려 있는 보안 그룹
관리 접속 포트가 전 세계에 열려 있는 경우예요. 개발할 때 잠깐 열고 안 닫은 게 대부분입니다. “임시로 열고 안 닫은 것들을 어떻게 찾아내나요?” 가 좋은 질문이에요.

③ 지워지지 않은 권한
퇴사자 계정, 끝난 프로젝트의 역할, 예전에 만든 액세스 키. 가장 조용하고 가장 흔한 위험이에요. 정기적으로 정리하는 절차가 있는지 물어보세요. 있다면 주기와 방법을 말할 수 있습니다.

5. 배경 — 금융권이라면 여기가 진짜 관문

금융회사에서 클라우드를 쓰는 건 기술 문제가 아니라 절차 문제예요. 기술적으로 안전하게 만드는 것과, 그게 안전하다는 걸 규정에 맞춰 증명하는 건 완전히 다른 일이고, 후자에 훨씬 많은 시간이 듭니다.

면접관이 알아야 할 큰 그림은 이 정도예요.

망분리

금융권 전산 환경은 업무망과 인터넷망을 분리하도록 요구받아 왔어요. 그래서 클라우드를 쓸 때도 “인터넷에 붙은 자원” 과 “내부 업무 자원” 사이의 경계를 어떻게 그을지가 설계의 출발점이 됩니다. 개발자 입장에서는 외부 라이브러리를 받는 것부터 불편해지죠.

최근 몇 년간 이 규제는 완화 논의와 개선 방안이 계속 나오는 영역이에요. 생성형 AI 활용처럼 예전 틀로는 감당이 안 되는 요구가 늘었거든요. 그래서 후보자가 “요즘 이쪽 흐름이 어떻게 바뀌고 있는지” 를 아는지도 볼 만합니다.

📎 배경이 더 필요하면 블로그의 금융권 망분리 — 내부망과 외부망 편과 내부망·외부망·DMZ 사용 요건 편을 먼저 보세요. 그다음 제로트러스트 설계와 멀티클라우드 금융보안 편까지 훑으면 후보자와 말이 통합니다.

클라우드를 도입하려면 거쳐야 하는 것들

금융회사가 클라우드에 업무를 올릴 때는 대체로 이런 단계를 밟아요.

단계	내용
중요도 평가	이 업무가 중요 업무인지 먼저 판정
안전성 확보 조치	암호화·접근통제·백업 등 기술적 요건 충족
제공자 평가	클라우드 사업자가 기준을 충족하는지 확인
계약 요건	감독당국의 접근·조사 가능성 등을 계약에 반영
보고·기록	이용 사실을 정해진 절차대로 보고·관리

⚠️ 여기서 중요한 주의 하나. 금융 클라우드 관련 규정과 가이드는 개정이 잦습니다. 이 글의 단계 구분은 큰 흐름을 잡기 위한 것이고, 실제 조문·기한·서식은 반드시 최신 전자금융감독규정과 금융보안원 가이드를 확인하세요. 면접에서도 후보자에게 조문을 외우는지 묻지 마시고, “그 절차를 실제로 통과해본 적 있는지” 를 물으시는 게 맞습니다. 조문은 찾으면 되지만 통과 경험은 못 삽니다.

이 영역에서 진짜와 가짜를 가르는 법

규제 대응은 말로만 아는 사람이 특히 많은 영역이에요. 가려내는 방법은 간단합니다. 고생담을 물어보세요.

심사·점검 준비를 하면서 가장 오래 걸린 일이 뭐였나요
규정 때문에 원래 하려던 설계를 바꾼 적이 있나요
감사에서 지적받은 것 중 기억나는 게 있나요

실제로 통과해본 사람은 여기서 이야기가 술술 나와요. 증빙 자료 만드느라 며칠 밤샜다든가, 로그 보관 기간 때문에 저장소를 다시 설계했다든가 하는 구체적인 고생이 있습니다. 책으로 아는 사람은 절차 이름은 대는데 고생담이 없어요.

6. 질문 12개 + 채점 포인트

Q1. 개발자에게 AWS 권한을 어떻게 주시나요

왜 묻나 — 권한 모델의 성숙도를 한 번에 봅니다.
👍 좋은 답 — 사람마다 고정 권한을 주지 않고, 역할을 빌리는 방식과 사내 인증 연동을 이야기해요. 환경별로 권한이 다르다는 얘기가 나오면 좋습니다.
⚠️ 걸리는 답 — “필요하다고 하면 관리자 권한을 줍니다.” 실제로 흔하고, 그래서 사고가 납니다.

Q2. 장기 액세스 키가 지금 몇 개나 살아 있나요

왜 묻나 — 앞서 말한 그 질문이에요. 자산 파악이 되어 있는지, 줄이려는 노력이 있었는지를 봅니다.
👍 좋은 답 — 대략의 숫자와 남은 이유를 말해요. “레거시 시스템 두 곳만 남았고 대체 계획이 있습니다” 같은.
⚠️ 걸리는 답 — 몇 개인지 모릅니다. 관리 대상이 아니라는 뜻이에요.

Q3. 넓게 열린 권한을 좁혀본 경험이 있나요

왜 묻나 — 최소권한을 실행해봤는지 봅니다. 원칙을 아는 것과 다릅니다.
👍 좋은 답 — 실제 사용 기록 기반으로 줄인 방법을 말하고, 조직 저항을 어떻게 다뤘는지가 나옵니다. 단계적으로 진행한 이야기면 더 좋아요.
⚠️ 걸리는 답 — “최소권한이 원칙입니다” 라는 교과서 답만 반복해요.

Q4. DB 비밀번호가 지금 어디에 있고, 마지막으로 언제 바꾸셨나요

왜 묻나 — 사고가 가장 자주 나는 지점이고, 두 번째 질문이 진짜 관리 여부를 가릅니다.
👍 좋은 답 — 전용 저장소를 쓰고, 자동 교체를 걸어뒀다고 답해요. 자동화가 안 됐으면 안 된 이유를 압니다.
⚠️ 걸리는 답 — 코드나 설정 파일에 있다고 하거나, 언제 바꿨는지 모릅니다.

Q5. 암호화 키는 어떻게 관리하시나요

왜 묻나 — 키와 데이터 권한을 분리해서 생각하는지 봅니다.
👍 좋은 답 — 키 정책을 별도로 관리하고, 회전 주기가 있어요. 데이터 접근 권한이 있어도 키 권한이 없으면 못 읽는 구조를 설명하면 아주 좋습니다.
⚠️ 걸리는 답 — “기본 키로 암호화했습니다” 만 말하고 그 이상 없어요. 작은 조직이면 괜찮지만 시니어 보안 담당으로는 얕습니다.

Q6. CloudTrail 로그를 뒤져서 뭔가를 조사해본 적 있나요

왜 묻나 — 켜두기와 실제 활용의 차이를 가릅니다. 이 편에서 가장 정직한 질문이에요.
👍 좋은 답 — 구체적인 조사 사례가 나와요. “누가 이 설정을 바꿨는지 찾느라 며칠 걸렸어요” 같은. 쿼리 도구 이야기가 섞이면 확실합니다.
⚠️ 걸리는 답 — “켜져 있습니다” 로 끝나요.

Q7. 로그 자체가 조작되는 상황은 어떻게 대비하셨나요

왜 묻나 — 사고 대응을 한 겹 더 깊이 생각해본 사람인지 봅니다. Q6 의 꼬리 질문으로 쓰기 좋아요.
👍 좋은 답 — 로그를 별도 계정에 쌓고 삭제를 막았다는 이야기가 나옵니다.
⚠️ 걸리는 답 — 생각해본 적 없다고 해요. 미들 레벨이면 괜찮지만 시니어면 아쉽습니다.

Q8. S3 버킷이 실수로 공개되는 걸 어떻게 막고 계신가요

왜 묻나 — 가장 흔한 클라우드 데이터 유출 유형에 대한 대비를 봅니다.
👍 좋은 답 — 개별 설정이 아니라 조직 차원에서 못 풀게 막는 방식(조직 정책, 자동 점검·교정)을 이야기해요.
⚠️ 걸리는 답 — “버킷마다 확인합니다.” 사람이 매번 확인하는 방식은 결국 뚫려요.

Q9. 계정을 어떻게 나눴고, 조직 차원의 금지 규칙을 걸어보셨나요

왜 묻나 — 거버넌스 경험을 봅니다. 계정 분리는 가장 강력한 격리 수단이에요.
👍 좋은 답 — 환경·조직별 분리 기준을 말하고, 계정 위에서 강제되는 금지 규칙(SCP)을 걸어본 경험이 있어요. 랜딩 존을 구축했다면 큰 조직 경험입니다.
⚠️ 걸리는 답 — 계정 하나에 다 넣었는데 규모는 크다고 합니다.

Q10. 퇴사자나 끝난 프로젝트의 권한은 어떻게 정리하시나요

왜 묻나 — 지루하지만 실제로 가장 자주 사고로 이어지는 영역이에요. 운영 규율을 봅니다.
👍 좋은 답 — 주기적 검토 절차가 있고, 인사 시스템과 연동했으면 아주 좋아요.
⚠️ 걸리는 답 — “요청이 오면 지웁니다.” 요청은 안 옵니다.

Q11. (금융권) 클라우드 도입 절차를 처음부터 끝까지 겪어보셨나요

왜 묻나 — 규제 산업에서 가장 중요한 단 하나의 질문이에요. 기술이 아니라 절차를 통과해봤는지를 봅니다.
👍 좋은 답 — 어떤 단계를 밟았는지 순서대로 말하고, 가장 오래 걸린 일을 구체적으로 꼽아요. 증빙 자료, 보관 기간, 계약 조항 같은 현실적인 고생담이 섞입니다. 규정 때문에 설계를 바꾼 이야기가 나오면 확실해요.
⚠️ 걸리는 답 — 절차 이름은 나열하는데 고생담이 하나도 없습니다. 또는 “보안팀이 다 했습니다” 로 넘어가요.

Q12. (금융권) 망분리 제약 안에서 개발 생산성을 어떻게 지키셨나요

왜 묻나 — 규제와 실무 사이에서 균형을 잡아본 사람인지 봅니다. 규제만 아는 사람과 개발만 아는 사람 둘 다 위험해요.
👍 좋은 답 — 구체적인 우회·개선 사례가 나와요. 내부 저장소를 두거나, 승인 절차를 자동화하거나, 안전하게 열어주는 통로를 설계한 이야기 같은. 그리고 보안팀과 개발팀 사이를 중재해본 경험이 있으면 최고입니다.
⚠️ 걸리는 답 — “규정이라 어쩔 수 없습니다” 로만 답해요. 또는 반대로 규제를 우회하는 편법만 자랑스럽게 말하면 그건 더 위험합니다.

7. 면접 직전 5분 요약

꼭 물을 것 3개 (+ 금융권이면 4개)

장기 액세스 키가 몇 개 살아 있나요 (Q2)
CloudTrail 로그를 뒤져서 조사해본 적 있나요 (Q6)
퇴사자·종료 프로젝트 권한은 어떻게 정리하나요 (Q10)
(금융권) 클라우드 도입 절차를 끝까지 겪어봤나요 — 고생담을 요구하세요 (Q11)

좋은 신호로 기억할 단어
역할을 빌려 쓰는 방식 · 임시 자격증명 · 실제 사용 기록으로 권한 좁히기 · 조직 저항을 단계적으로 · 로그를 별도 계정에 쌓고 삭제 금지 · 조직 차원에서 못 풀게 막기 · 키 권한과 데이터 권한 분리 · 규정 때문에 설계를 바꾼 경험

레드 플래그
필요하면 관리자 권한을 줌 · 액세스 키가 몇 개인지 모름 · 비밀번호를 코드에 보관 · 로그는 켜뒀지만 본 적 없음 · 퇴사자 권한은 요청 오면 처리 · 규제 이야기에 고생담이 전혀 없음 · 규제 우회 편법을 자랑

일단 오늘은 여기까지…..
다음 글이 마지막이에요. 데이터·AI 플랫폼 갈래를 정리하고, 마지막에 60분 면접 진행 시나리오와 레드 플래그 종합을 붙여서 시리즈를 닫을게요.

← 이전 글: (3/5) DevOps·플랫폼 엔지니어 면접 ｜ 다음 글 →: (5/5) 데이터·AI 플랫폼 면접 + 60분 진행 시나리오

X Facebook LinkedIn Bluesky