조직에서 가장 침투하기 어려운 인프라 파이프라인을 구축하는 실용 가이드

서론: 왜 코드로서의 보안인가, 그리고 지금인가

2025년 12월 re:Invent에서 AWS는 소프트웨어 배포 및 운영에 초점을 맞춘 일련의 자율 AI 서비스를 발표했습니다. 바로 명세(specification)를 작동하는 코드로 변환하는 에이전트 Kiro; 설계 및 코드 검토를 수행하고 필요할 때 침투 테스트를 실행하는 AWS Security Agent; 그리고 사고를 조사하고 완화 계획을 초안 작성하는 AWS DevOps Agent입니다. 나아가는 방향은 분명합니다: 코드는 점점 더 _기계에 의해 작성되고, 검토되며, 운영될 것_이며 — 기계 속도로 말이죠.

이는 속도 면에서는 고무적이지만 보안 측면에서는 무시무시합니다. 에이전트가 새벽 3시에 새로운 VPC를 프로비저닝하는 풀 리퀘스트(pull request)를 열 수 있다면,

그리고 플릿(fleet)은 계속 성장합니다. AgentCore 결제 기능이 2026년 8월에 일반 사용 가능(general availability) 상태에 도달하면서, 에이전트들은 Coinbase와 Stripe로 구축된 지갑을 통해 개방형 x402 프로토콜과 Machine Payments Protocol (MPP)을 거쳐 API, MCP 서버, 콘텐츠 비용을 결제할 수 있게 되었으며, 이는 설정 가능한 지출 한도를 포함합니다. 몇 주 후인 2026년 10월에 AWS는 AWS Well-Architected Agent의 미리 보기(preview) 버전을 발표했습니다. 이 에이전트는 환경과 심지어 Terraform 코드까지 지속적으로 분석하여 Well-Architected Framework와 비교하고, 적용할 준비가 된 수정 사항을 제공합니다. 이제 에이전트들은 코드를 작성하고, 코드를 검토하며, 시스템을 운영하고, 돈을 지출하며, 아키텍처를 감사할 수 있습니다.

본 기사에서는 전체 운영 모델을 안내합니다: 계층형 아키텍처, Terraform 파이프라인, 정책-코드(policy-as-code) 도구링, AWS 네이티브 감지, 드리프트 관리(drift management), 이 확장되는 AWS 에이전트 플릿이 Security-as-Code 세계에 어떻게 통합되는지, 그리고 — 무엇보다 중요한 — 에이전트들이 여전히 부족한 부분은 어디인지를 다룹니다.

1. Security as Code가 실제로 의미하는 것과 그것이 서비스하는 대상

Security as Code는 IaC(Infrastructure as Code)가 인프라에 적용했던 것과 동일한 엔지니어링 엄격함을 보안에 적용합니다:

1.1 고객의 관점: 모든 정책은 약속이다

고객들은 Rego 정책을 직접 읽어보지 않지만, 그 정책 하나하나를 경험합니다. 성숙한 팀과 분리되는 규율은 리포지토리(repo)에 있는 각 정책에 대해 그것이 지키는 고객 약속을 명명할 수 있는 능력입니다:

• **저장 시 암호화 및 공개 접근 정책 (Encryption-at-rest and public-access policies)**은 "내 데이터가 안전한가요?"라는 질문과 여러분과 모든 엔터프라이즈 거래 사이에 놓인 조달 보안 설문지에 대한 해답입니다. 이러한 통제들이 코드로 구현되면, 그 설문지를 작성한다는 것은 회의를 잡는 것이 아니라 아티팩트(artifacts)를 내보내는 것을 의미합니다.
• **드리프트 감지 (Drift detection), 런타임 가드레일 (runtime guardrails), 그리고 DevOps 에이전트 (DevOps Agent)**는 고객 입장에서 단순히 '가동 시간(uptime)'입니다. 고객들은 보안 실패를 서비스 중단, 데이터 유출, 신뢰 상실로 경험하며, 어떤 계층에서 문제가 발생했는지에 신경 쓰지 않고, 단지 어느 한 곳의 실패만으로는 충분하지 않다는 사실에만 관심을 가집니다.
• **AgentCore 결제 제한 (payments limits)**은 가격 페이지에 인쇄할 수 있는 신뢰 기능입니다: "에이전트는 승인된 예산을 벗어나 돈을 쓰지 않을 것입니다." 에이전트 기반 제품에서 지출 정책 자체가 고객 계약서가 됩니다.
• 코드로서의 규정 준수 (Compliance as code)(NIST 및 CIS 벤치마크에 매핑된 Config conformance packs)는 감사 주기를 압축합니다. 이는 보안을 코드로 만드는 것(Security as Code)이 비용 센터가 아니라 **매출 가속기(revenue accelerator)**라는 의미입니다. 영업팀은 이 점을 보안팀보다 먼저 느낍니다.

테스트는 간단합니다: 정책을 고객 약속과 연결할 수 없다면, 그 정책이 왜 존재하는지 의문을 제기하십시오.

1.2 개발자의 관점: 채택률이 진정한 핵심 성과 지표(KPI)이다

개발자들이 우회하는 보안 게이트는 아예 없는 것보다 나쁩니다. 왜냐하면 커버리지 없이 통제라는 환상을 주기 때문입니다. Security as Code는 개발자가 그것을 선택할 때만 성공하며, 이는 개발자 경험 자체를 보안 속성으로 만듭니다:

• 이미 작동하는 곳에 대한 피드백 제공. 위반 사항은 몇 주가 걸리는 보안 검토 티켓이 아니라, 몇 초 안에 PR(Pull Request) 댓글로 표시되어야 합니다. 섹션 4의 파이프라인은 계획(plan), 위반 사항, 그리고 — 가장 중요한 것은 — 각 항목을 어떻게 수정해야 하는지를 풀 리퀘스트에 직접 게시합니다.
• 단순히 거부만 하는 것이 아니라 가르치는 오류 메시지. 비교해 보세요:
  • 나쁜 예: Policy SG-001: DENIED.
  • 좋은 예: aws_security_group_rule.web: ingress 0.0.0.0/0 포트 22는 금지되어 있습니다. 수정 방법: cidr_blocks 범위를 VPN 범위(예: 10.0.0.0/16)로 제한하거나 secure-bastion 모듈을 통해 SSM 세션 관리자를 사용하세요. 이유: 인터넷에 노출된 SSH는 흔한 침해 경로입니다. 정책: policies/network.rego — 질문 있으신가요? #security-help
• 게이트키핑보다 골든 패스(Golden paths) 제공. 강화된 내부 모듈(섹션 3.3)은 규정을 준수하는 방식을 가장 빠르게 만드는 역할을 해야 합니다. 복사-붙여넣기 예제, 합리적이고 안전한 기본값 설정, 그리고 셀프 서비스 모듈 카탈로그를 통해 가능합니다. 보안 모듈을 사용하여 5분 만에 배포할 수 있는 개발자는 불안전한 코드를 직접 작성하는 데 두 시간을 쓰지 않을 것입니다.
• 수치심 없는 탈출구(Escape hatches). 소프트 의무 정책과 시간 제한이 걸린 예외 처리 워크플로우는 그림자 IT(shadow IT)를 부추기는 하드웨어 장벽보다 효과적입니다. 예외 사항은 데이터이며, 그 발생률과 연령은 측정 지표가 됩니다(섹션 10). 그리고 모든 반복되는 예외 사항은 정책이나 골든 패스에 개선이 필요하다는 신호입니다.
• 속도 예산(Speed budget). 정적 분석 단계가 2분 이상 걸린다면, 개발자들은 배치 처리하거나, 우회하거나, 강제 푸시를 통해 건너뛸 것입니다. 캐시 제공자, 스캔 병렬화, 중요 항목에서 빠르게 실패하도록 설계해야 합니다.
• 정책의 공동 저자로 참여하는 개발자. 정책에 대해 PR을 열어 더 나은 규칙을 제안하거나, 메시지를 다듬거나, 테스트를 추가할 수 있는 개발자는 통제권을 갖습니다. 사람들과 함께 작성된 정책은 따르게 되고, 하달되는 정책은 우회됩니다.

문화적 시험: 보안 도구가 개발자를 측정 가능하게 더 빠르게 만든다면 — 검토 왕복 횟수 감소, 롤백으로 인한 재작성 감소, 새벽 2시의 긴급 패치(hotfixes) 감소 — 채택 문제는 더 이상 관리 문제가 아닙니다.

2. 계층형 방어 모델

성숙한 AWS 환경의 Terraform 보안 태세는 네 개의 파이프라인 계층과 하나의 조직적 안전장치로 구성됩니다. 이 중 어느 하나에만 의존하는 것이 바로 보안 침해(breach)가 발생하는 방식입니다.

┌─────────────────────────────────────────────────────────────┐
│ Layer 4: 감지 및 대응 (DETECT & RESPOND) (런타임, 지속적)
│   AWS Config · Security Hub CSPM · GuardDuty · CloudTrail · │
...

각 계층은 이전 계층이 놓친 부분을 포착하며, 각 계층 자체도 애플리케이션 코드처럼 검토되고 버전 관리되는 코드입니다.

Layer 0의 중요성: Layer 1부터 Layer 4까지는 모두 자격 증명(credentials)에 의해 우회될 수 있기 때문입니다. 유효한 콘솔 또는 CLI 접근 권한을 가진 사람은 파이프라인에 손대지 않고도 인프라를 변경할 수 있습니다. 서비스 제어 정책(Service Control Policies, SCPs), 리소스 제어 정책(Resource Control Policies, RCPs), 그리고 권한 경계(permission boundaries)는 심지어 유출된 관리자 자격 증명으로도 CloudTrail을 비활성화하거나, 보안 그룹을 전 세계에 열거나, 승인된 지역을 벗어나게 하는 것을 막아주는 안전장치입니다. 이들을 전용 거버넌스 계정(governance account)에서 Terraform으로 배포하고, 변경 사항에 대해서는 프로덕션 환경의 변경 사항과 동일한 검토 엄격함을 적용해야 합니다.

Layer 1은 설계상 자문적(advisory)입니다. git commit --no-verify를 사용하면 사전 커밋 훅(pre-commit hooks)이 완전히 건너뛰어지며, 개발자는 언제든지 이를 설치하지 않기로 선택할 수 있습니다. 사전 커밋 훅은 강제하기 위함이 아니라 피드백 루프를 단축시키기 위해 존재합니다. 동일한 검사는 CI(Layer 2)에서도 다시 실행되어야 하며, 이곳에서는 건너뛸 수 없습니다.

3. Terraform 운영: 기반 시설 보호

어떤 정책 도구도 중요하기 전에, Terraform 운영 모델 자체를 강화해야 합니다. 실제 환경에서 발생하는 대부분의 Terraform 사고는 이국적인 것이 아닙니다. 유출된 상태 파일(state files), 과도한 권한을 가진 CI 역할, 그리고 수동으로 편집된 콘솔이 주원인입니다.

3.1 상태 파일 보안

상태 파일은 전체 인프라의 지도와 같으며 민감한 값을 포함할 수 있습니다. 절대 포기할 수 없는 사항은 다음과 같습니다:

terraform {
  backend

-   **SSE-KMS를 사용하여 저장 시 암호화(Encrypt at rest with SSE-KMS)**하고, 사용을 CI/CD 실행 역할로 제한하는 키 정책을 적용합니다. (`encrypt = true`만으로는 SSE-S3만 제공됩니다.)
-   **버킷 버전 관리 활성화(Enable bucket versioning)**하여 손상되거나 악의적으로 덮어쓰인 상태 파일(state file)을 복구할 수 있도록 합니다.
-   **상태 잠금(Lock the state)**: 현재 Terraform 버전에서 제공하는 네이티브 S3 잠금 기능을 사용합니다 (DynamoDB 잠금은 더 이상 지원되지 않습니다). 실행 역할에는 상태 키에 대한 `s3:PutObject`/`s3:GetObject`/`s3:DeleteObject` 권한과 `*.tflock` 객체에 대한 `s3:PutObject`/`s3:GetObject`/`s3:DeleteObject` 권한이 필요합니다.
-   **최소 권한 원칙(Least-privilege access)**: 상태를 쓸 수 있는 역할은 CI/CD 실행 역할만 가능하며, 사람은 감사된 비상 접근 경로(audited break-glass paths)를 통해서만 읽기 접근을 허용받습니다.
-   **상태 파일을 절대 git에 커밋하지 마십시오.** `.gitignore`와 CI의 시크릿 스캐너로 이를 강제합니다.
-   **`.terraform.lock.hcl`은 커밋**하여 프로바이더 버전이 고정되고 검증되도록 하며, 비밀번호나 토큰처럼 상태에 절대 지속되어선 안 되는 비밀 정보에는 **쓰기 전용 속성 및 임시 리소스(write-only attributes and ephemeral resources) (Terraform 1.11 이상)**를 사용합니다. 이렇게 하면 해당 비밀 정보가 `terraform show`, plan 출력 또는 상태 파일에 나타나는 것을 방지할 수 있습니다.

### 3.2 CI/CD 역할: 최소 권한이 아니면 아무것도 아니다
파이프라인의 AWS 자격 증명(credentials)은 가장 중요한 보물입니다:
-   장기 액세스 키 대신 **OIDC 페더레이션(OIDC federation)** (예: GitHub Actions → AWS IAM 역할)을 사용합니다.
-   **신뢰 정책을 정확한 주체에 고정(Pin the trust policy to the exact subject)**해야 합니다. 역할의 신뢰 조건은 단순히 조직만 아니라 `sub` 클레임 — 리포지토리, 그리고 이상적으로는 브랜치나 환경 — 에 고정되어야 합니다. 그렇지 않으면 귀하의 GitHub org 내 어떤 리포지토리의 워크플로우라도 해당 역할을 가정(assume)할 수 있습니다:

"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
...

-   역할의 범위를 각 워크스페이스가 관리하는 정확한 서비스로 제한하고, 환경별로 역할을 분리합니다 — 개발(dev) 적용 역할은 물리적으로 운영(prod)에 접근할 수 없어야 합니다. 역할 자체에 대한 권한 경계(Permission boundaries)는 파이프라인 버그조차 초과할 수 없는 두 번째 상한선을 추가합니다.

### 3.3 모듈 거버넌스

자유 형식으로 작성된 리포지토리별 Terraform 코드는 일관성을 잃기 쉽습니다. 대신 다음을 수행하세요:

-   **보안 강화된 내부 모듈(hardened internal modules)**을 게시합니다 (공개 액세스 차단 및 KMS가 적용된 S3, 기본적으로 `0.0.0.0/0` 인그레스가 없는 보안 그룹, 모든 곳에 로깅 활성화). 
-   모듈 버전을 브랜치 대신 태그로 고정합니다.
-   모듈 내부에 안전한 기본값(secure defaults)을 강제하여, 안전한 경로가 가장 쉬운 경로가 되도록 합니다. 이것이 '코드로서의 보안(Security as Code)'을 문화적으로 정착시키는 핵심입니다.
-   모듈 카탈로그를 개발자를 고객으로 하는 제품처럼 운영합니다: 모든 README에 복사-붙여넣기 예시 제공, 검색 가능한 카탈로그, 버전별 변경 로그, 그리고 SLA가 있는 Slack 채널을 마련합니다. 편리성 측면에서 '골든 패스(golden path)'가 승리하지 못하면 아무것도 승리할 수 없습니다.

## 4. 파이프라인: 코드로서의 보안이 존재하는 곳

여기에 Layer 2(스캔)를 Layer 3(강제 적용)으로 연결하는 참조 GitHub Actions 설계가 있습니다. 이 설계는 두 개의 워크플로우를 사용합니다: 풀 리퀘스트(pull requests)에 대한 하나(스캔 + 계획 + 정책), 그리고 main 브랜치로 병합(merges)될 때의 하나(재계획, 재정책 확인, 적용). `apply` 워크플로우는 PR 아티팩트를 재사용하기보다 재계획을 수행합니다. 왜냐하면 PR 시점의 계획은 병합 시점까지 오래되었을 수 있고, 계획 파일에는 민감한 값이 포함되어 있어 이를 아티팩트를 통해 러너(runner) 간에 전달하려면 저장 시 암호화와 신중한 범위 설정이 필요하기 때문입니다. 보호된 브랜치에서 재계획하는 것이 더 간단하고 안전합니다. 왜냐하면 해당 브랜치 자체가 보호되기 때문입니다.

.github/workflows/terraform-pr.yml

name: terraform-pr
on:
...

.github/workflows/terraform-main.yml

name: terraform-main
on:
...

이 설계의 주요 속성들: