Tiro의 Kiro를 활용한 보안 인프라 구축과 ISO/IEC 27001:2022 인증 취득 여정

AI Native 스타트업에게 보안 인증이 왜 어려운가

AI가 빠르게 발전하면서 한 명의 엔지니어가 하루에 50~100개의 커밋을 작성하는 일도 더 이상 낯설지 않게 되었습니다. 제품 개발, 테스트 코드 작성, 인프라 정의 변경, 운영 스크립트 작성까지 AI 에이전트와 함께 처리하는 조직이 늘고 있습니다. 개발 속도만 놓고 보면 분명 큰 변화입니다. 다만 AI가 만들어내는 속도가 언제나 더 안전한 제품으로 이어지지는 않습니다.

AI 에이전트에게 코드 작성이나 인프라 조작처럼 자율성이 큰 작업을 맡기면 초반에는 반복 작업이 크게 줄어드는 듯 보입니다. 그러나 제품이 고객 데이터를 다루고 실제 운영 환경에 연결되는 순간, 문제는 단순한 생산성을 넘어섭니다. 어떤 계정에 접근할 수 있는지, 어떤 리소스를 변경할 수 있는지, 변경 전후 상태가 증적으로 남는지, 어디서 사람이 승인해야 하는지가 분명하지 않으면 빠른 실행은 곧 빠른 위험이 됩니다. 즉, 빠르게 만들수록 무엇을 지켜야 하는지 잊기 쉽습니다. 신뢰와 거버넌스가 AI의 속도를 따라가지 못하면 개발 속도는 오히려 운영 리스크가 됩니다. 보안 인증을 준비한다는 것은 이 지점을 다시 정리하는 일입니다. 시스템적으로 넘어서는 안 되는 레드라인을 명시하고, 실제 운영 중인 제품과 고객 데이터에 영향을 주지 않겠다는 원칙을 조직의 운영 방식으로 만드는 과정입니다.

더플레이토(The Plato)는 AI 회의 노트 서비스 티로(Tiro)를 만듭니다. 조직의 민감한 대화가 매일 티로를 거쳐가기 때문에 티로는 제품 개발 초기부터 모든 고객 데이터를 암호화했습니다. 창업자 3명을 포함해 고객이 5명뿐이던 시절에도 모든 인프라 접근 기록을 남겼습니다. 보안은 회사가 커진 뒤에 덧붙이는 기능이 아니라 처음부터 제품의 일부여야 한다고 믿었기 때문입니다.

2026년 6월, 티로는 국제 보안 인증인 ISO/IEC 27001:2022(이하 ISO 27001)를 취득했습니다. 직접적인 계기는 일본 엔터프라이즈 시장 진출이었지만, 인증 준비는 감사 체크리스트를 채우는 작업에 그치지 않았습니다. AI 에이전트와 함께 일해도 안전하게 확장되는 운영 모델을 만드는 과정이었습니다.

이 글에서는 더플레이토 엔지니어 1명이 AWS의 AI 코딩 에이전트 Kiro와 함께 예상보다 4개월 빠르게 보안 인프라를 정비하고, ISO 27001 인증을 취득한 여정을 운영 모델 설정부터 Kiro 활용법까지 폭넓게 소개합니다.

Tiro가 목표로 한 보안 운영 모델

ISO 27001은 단일 제품의 보안 기능만 평가하지 않습니다. 조직이 운영하는 정보보안경영시스템(ISMS, Information Security Management System) 전체를 봅니다. 다시 말해 “이 서비스가 안전한가”만 묻지 않습니다. “이 조직이 보안을 일관되게 운영할 체계를 갖췄는가”를 확인합니다.

심사는 크게 두 단계로 구성됩니다.

• Stage 1(문서 심사): 정책과 절차가 표준 요구사항을 충족하도록 문서화되어 있는지 확인합니다.
• Stage 2(운영 심사): 그 정책이 실제 운영에서 지켜지고 있다는 증적(evidence)이 존재하는지 확인합니다.

핵심은 Stage 2입니다. 아무리 잘 작성된 정책 문서가 있어도 매일의 운영에서 작동한 흔적이 없으면 인증을 통과할 수 없습니다. 티로 팀은 인증 준비를 “문서를 잘 쓰는 일”로 보지 않았습니다. 운영을 증적이 남는 방식으로 다시 설계하는 일로 정의했습니다.

티로가 목표로 한 보안 운영 모델은 세 가지 원칙으로 요약됩니다.

• 첫째, 보안 통제는 정책 문서에만 머물러서는 안 됩니다. 코드 리뷰, 인프라 변경, 계정 접근, 로그 보관, 침해 탐지 같은 일상 운영 흐름 속에서 실제로 작동해야 합니다.
• 둘째, AI 에이전트는 통제 밖의 실행자가 아니라 통제 안의 작업 파트너여야 합니다. AI가 빠르게 진단하고 초안을 만들더라도, 운영 환경에 영향을 줄 변경은 명확한 승인 지점과 롤백 계획 안에서만 진행해야 합니다.
• 셋째, 주요 운영 활동은 증적으로 남아야 합니다. 변경 전 상태, 변경 계획, 사람의 승인, 변경 후 검증 결과가 연결되어야 감사 대응뿐 아니라 내부 운영 품질도 높아집니다.

이 관점에서 티로의 인증 준비는 ISO 27001 인증 취득만을 위한 프로젝트가 아니었습니다. AI Native 스타트업이 고객 신뢰를 확장하는 데 필요한 운영 체계를 AWS 위에 구체화하는 과정이었습니다.

정책과 증적을 어떻게 준비했는가

ISO 27001의 표준 통제 항목은 정해져 있지만, 그것을 조직의 실제 운영 방식으로 풀어내는 일은 별개의 문제입니다. 티로 팀은 이 작업을 두 축으로 나눴습니다. 하나는 정책 문서의 초안을 빠르게 만들고 조직의 맥락을 입히는 일, 다른 하나는 정책이 실제로 지켜지고 있음을 증적으로 수집하는 일이었습니다.

정책: AI로 초안을 만들고 사람이 맥락을 채운다

티로 팀은 사내 보안 의사결정이 오가던 팀 Slack 메시지의 논의 맥락을 AI 어시스턴트에 입력으로 제공하고, 통제 항목별 정책 초안을 만들었습니다. AI가 표준 요구사항의 뼈대를 잡으면 사람이 실제 책임자, 사용 도구, 점검 주기, 예외 처리 방식, 승인 절차를 채우는 방식입니다. 이때 하나의 통제 항목은 하나의 논의 스레드에 매핑했습니다. 정책 문서를 만드는 과정 자체가 추적 가능한 기록으로 남아야 했기 때문입니다. 누가 어떤 의사결정을 했고, 어떤 근거로 현재 정책이 만들어졌는지 확인할 수 있어야 운영 심사 단계에서도 설명이 가능합니다. 그 결과 티로 팀은 23개 정책 문서를 일관된 구조로 완성했습니다. 여기서 AI의 역할은 정책 책임을 대체하는 것이 아니었습니다. 반복적인 초안 작성과 구조화를 맡고, 사람은 조직의 실제 운영 맥락과 책임을 반영했습니다.

증적: 컴플라이언스 자동화로 운영 상태를 가시화한다

각 통제 항목은 Slack 안에서 하나의 스레드로 매핑해 관리했습니다.

정책이 실제로 지켜진다는 증적은 컴플라이언스 보안 파트너 사의 플랫폼을 통해 수집했습니다. 플랫폼에 정의된 ISO 27001 관련 204개 통제 항목의 범위를 선정하고, 각 항목을 티로의 AWS 인프라와 운영 방식에 연결했습니다. 계정 분리, 접근 제어, 감사 로그 보관, 암호화, 변경 관리 같은 항목은 AWS 환경의 실제 설정 상태와 연결되어야 합니다. 플랫폼이 AWS 환경의 설정 상태를 읽어 통제 항목과 연결하면 준비 상태가 실시간에 가깝게 보입니다. 팀은 이 준비도(readiness) 점수를 스코어보드처럼 활용했습니다. 이 방식의 장점은 인증 준비가 막연한 문서 작업으로 남지 않는다는 데 있습니다. 어떤 통제 항목이 준비되었고 어떤 항목은 추가 작업이 필요한지, 그 작업이 인프라 설정의 문제인지 운영 절차의 문제인지 구분됩니다. 덕분에 제한된 인력으로도 우선순위를 분명히 잡을 수 있었습니다.

서비스 ISO 증적자료 매핑표 예시

Kiro를 어디에, 어떻게 활용했는가

인증 준비에서 가장 손이 많이 가는 영역은 인프라 통제였습니다. 개발 환경 분리, 모니터링, 암호화, 네트워크 접근 제어, 감사 로그 중앙화와 관련된 통제만 30개가 넘었습니다. 이 구간에서 티로 팀이 가장 크게 의지한 도구가 AWS의 AI 코딩 에이전트 Kiro입니다.

티로 팀에게 Kiro가 의미 있었던 이유는 단순히 코드를 잘 생성했기 때문이 아닙니다. 보안 인증 준비에서 중요한 것은 “AI가 무엇을 만들 수 있는가”보다 “AI가 무엇에 접근할 수 있고, 그 접근을 어떻게 통제할 것인가”였습니다.

티로 팀이 Kiro에게 열어둔 작업 환경은 크게 다섯 가지였습니다.

• 워크스페이스: Kiro는 Terraform으로 관리되는 인프라 정의, 운영 스크립트, 정책 관련 파일을 읽고 수정할 수 있었습니다. 즉, 인프라의 현재 구조를 코드 레벨에서 이해하고 변경 초안을 만들 수 있었습니다.
• 통합 터미널 (Shell 명령): Kiro는 셸 명령을 통해 AWS CLI(aws 명령)로 현재 리소스 상태를 조회하고, terraform plan으로 변경 예정 사항을 확인하고, git과 gh로 변경 이력과 리뷰 흐름을 다룰 수 있었습니다.
• MCP (Model Context Protocol) 서버: AWS Documentation MCP 서버를 연결해 Kiro 에서 AWS 공식 문서를 검색하고, 인프라 변경의 근거를 최신 문서에 맞춰 확인할 수 있었습니다.
• Agent Hooks (이벤트 자동화): 파일 저장, spec task 실행 전후, 도구 호출 전후 같은 Kiro 이벤트에 에이전트 프롬프트나 셸 명령을 연결할 수 있었습니다. 반복되는 점검이나 검증 흐름을 자동화하는 기반이 되었습니다.
• Steering 파일 (영속 맥락): .kiro/steering/에 제품 맥락, 기술 스택, 인프라 운영 규칙, 금지 사항을 기록해 모든 작업에 일관되게 적용했습니다.

이처럼 Kiro는 코드, 터미널, 문서, 이벤트, 영속 맥락에 접근할 수 있었습니다. 그래서 더 강력했지만, 동시에 더 조심스럽게 다뤄야 했습니다. 프로덕션 인프라는 변경 한 번의 실수도 고객 데이터와 운영 안정성에 영향을 줄 수 있기 때문입니다.

티로 팀은 Kiro를 “자율 실행자”로 두지 않고, 명확한 경계 안에서 일하는 보조 엔지니어로 설계했습니다. 실행은 Supervised 모드로 제한하고, 반복되는 운영 규칙은 Steering 파일에 남겼으며, 인프라 변경은 Spec으로 요구사항, 설계, 작업 목록을 분리했습니다. 다음 섹션에서는 이 원칙을 실제 작업에서 어떤 가드레일로 적용했는지 살펴봅니다.

AI 에이전트를 안전하게 쓰기 위한 4가지 가드레일

프로덕션 인프라는 변경 한 번의 실수도 허용되지 않는 엄격한 제약 조건 위에서 동작합니다. 그래서 티로 팀은 Kiro 자체를 그대로 신뢰하기보다, Kiro가 안전하게 일할 수 있는 경계를 먼저 설계했습니다. 핵심 가드레일은 네 가지였습니다.

읽기 전용(Read-only) discovery로 시작한다

모든 인프라 작업은 읽기 전용 진단에서 시작했습니다. 현재 상태를 조회하고, 리소스 목록을 정리하고, 통제 요구사항과의 차이를 식별하되 어떤 리소스도 변경하지 않는 단계입니다. 예를 들어 비암호화 EBS 볼륨을 점검할 때는 다음과 같은 프롬프트를 사용했습니다.

ISO/IEC 27001 인증 준비를 위해 EBS 볼륨 암호화 상태를 점검하려고 합니다.
지정된 AWS 계정과 리전에서 EBS 볼륨을 읽기 전용으로 조회하고, 비암호화 볼륨이 어떤 Amazon EC2 인스턴스 또는 워크로드와 연결되어 있는지 정리해 주세요.

단, 어떤 리소스도 생성, 수정, 삭제하지 마세요.
`terraform apply`, `aws ec2 modify-*`, `aws ec2 create-*`, `aws ec2 delete-*` 계열 명령은 실행하지 마세요.

결과는 다음 컬럼을 포함한 표로 정리해 주세요:
Account ID, Region, Volume ID, Encrypted 여부, Attached Instance ID, Instance Name, 연결된 워크로드 추정, Environment 태그, Owner/Application 태그, 운영 영향도 메모, 사람 검토 필요 여부.

이 단계의 목적은 AI가 현황을 빠르게 파악하게 하되 운영 환경에는 아무 영향도 주지 않는 데 있습니다.

Spec으로 요구사항, 설계, 작업을 분리한다

티로 팀은 인프라 변경마다 Kiro의 Spec으로 작업을 구조화했습니다. Kiro Spec은 하나의 요청을 바로 코드 변경으로 넘기지 않고, 요구사항, 설계, 작업 목록으로 나눠 다룹니다. 덕분에 AI가 무엇을 만족해야 하는지, 어떤 방식으로 바꿀 것인지, 어떤 순서로 진행할 것인지가 파일로 남습니다.

보안 인증 준비에서는 이 구조가 특히 중요했습니다. 예를 들어 “모든 계정의 API 활동을 중앙에서 보관해야 한다”는 통제 요구사항이 있으면, 그것을 곧바로 Terraform 변경으로 처리하지 않았습니다. 먼저 requirements.md에 통제 요구사항과 수용 기준을 적고, design.md에 계정 구조와 로그 집약 방식, 롤백 방법을 정리했습니다. 그런 다음 tasks.md에 읽기 전용 진단, 변경안 검토, 사람 승인, 적용 후 증적 확인 같은 단계를 나눴습니다.

유사한 작업을 처음 시작하는 팀이라면 Kiro의 Quick Plan도 고려할 만합니다. 일반적인 Spec은 요구사항을 만들고, 검토하고, 설계를 만들고, 다시 검토한 뒤 작업 목록을 만드는 흐름입니다. 반면 Quick Plan은 필요한 질문을 앞에서 먼저 묻고, requirements.md, design.md, tasks.md 초안을 한 번에 생성합니다. 인증 준비처럼 통제 항목과 목표 상태가 비교적 명확한 작업에서는 초안 작성 시간을 줄이는 데 도움이 될 수 있습니다.

다만 Quick Plan은 실행을 빠르게 하기 위한 우회로가 아니라, 사람이 검토할 구조를 빨리 만드는 도구로 보는 편이 안전합니다. 예를 들어 “비암호화 EBS 볼륨을 식별하고, 영향도를 정리하고, 변경 전후 증적을 남긴다”는 작업은 목표가 명확합니다. 이런 경우 Quick Plan으로 Spec 초안을 만든 뒤, 사람이 요구사항과 설계의 빈틈을 검토하고 실제 변경은 Supervised 승인 흐름에서 다루는 방식이 적절합니다.

예시는 다음과 같습니다.

이 작업을 Kiro Quick Plan으로 만들어줘.

목표:
ISO/IEC 27001 인증 준비를 위해 EBS 볼륨 암호화 상태를 점검하고,
비암호화 볼륨의 워크로드 영향도와 변경 전후 증적 수집 계획을 정리한다.

제약:
- 어떤 리소스도 바로 변경하지 않는다.
- 기존 리소스를 수정하거나 삭제하지 않는다.
- apply는 사람이 승인하기 전까지 실행하지 않는다.

이 구조를 사용하면 AI가 바로 변경을 시도하지 않습니다. 먼저 “무엇을 만족해야 하는가”, “어떻게 바꿀 것인가”, “어떤 순서로 진행할 것인가”를 문서화합니다. Quick Plan을 쓰더라도 실제 변경은 다음 단계의 Supervised 승인 흐름에서 다루는 편이 안전합니다.

Supervised 모드로 승인 지점을 강제한다

Kiro는 Autopilot과 Supervised라는 두 가지 실행 방식을 제공합니다. Autopilot은 목표를 주면 여러 파일 변경을 한 번에 적용할 수 있어 위험이 낮고 잘 정의된 작업에 적합합니다. Supervised는 변경을 작은 조각으로 나눠 단계별 승인을 받습니다.

티로 팀은 인프라, 인증, 외부 계약처럼 영향이 큰 영역에서는 Supervised 모드를 사용했습니다. 특히 실제 적용(apply)은 사람이 검토하고 승인한 뒤에만 진행했습니다.

기존 리소스는 수정하거나 삭제하지 마.
변경은 신규 Terraform 파일로만 진행해.
apply는 내가 "승인"이라고 답하기 전에는 실행하지 마.

이 규칙은 매번 프롬프트로만 전달하지 않았습니다. .kiro/steering/ 파일에 영속적인 작업 규칙으로 기록해 Kiro가 모든 작업에서 같은 경계를 따르도록 했습니다.

변경 전후 증적을 남긴다

인증 준비에서 중요한 것은 변경 자체만이 아닙니다. 변경 전 상태, 변경 계획, 승인, 변경 후 검증 결과가 연결되어야 합니다. 티로 팀은 Kiro가 변경 전후 상태를 증적으로 남기도록 프롬프트와 작업 절차를 구성했습니다.

변경 전후 상태를 evidence/ 폴더에 before.json과 after.json으로 저장해.

이렇게 남긴 증적은 심사 대응뿐 아니라 내부 운영에도 유용했습니다. 어떤 리소스가 왜 변경되었는지, 변경 전에는 어떤 상태였고 변경 후에는 어떻게 바뀌었는지 추적할 수 있기 때문입니다.

{
  "documentType": "sanitized-evidence-example",
  "control": {"code": "DCF-54", "iso27001_2022": ["A.5.33", "A.8.24"]},
  "test": {
    "name": "AWS EBS Volume Encryption",
    "source": "AWS Organizations",
    "assertion": {"path": "EBSVolumeEncryption.EbsEncryptionByDefault",
                  "operator": "equal", "expected": true}
  },
  "scope": {"accountId": "[REDACTED]", "organizationalUnitId": "[REDACTED]"},
  "results": {
    "pass": [{"region": "ap-northeast-2", "EbsEncryptionByDefault": true}],
    "fail": [],
    "excluded": [{"region": "us-east-1",
                  "reason": "ElasticComputeCloudInstances.length == 0"}],
    "errored": []
  },
  "collectedAt": "[REDACTED_TIMESTAMP]"
}

EbsEncryptionByDefault=true 관련 필드 구조를 유지하고 식별자를 제거한 예시

티로 팀이 얻은 가장 중요한 교훈은 AI 에이전트를 안전하게 활용하는 방법이 “AI를 더 강하게 믿는 것”이 아니라는 점이었습니다. 필요한 것은 AI가 안전하게 일할 수 있는 경계를 명확히 하고, Spec으로 계획을 세우고, Supervised 모드로 승인받고, Steering으로 규칙을 지속적으로 주입하는 일이었습니다. 이 운영 방식이 있었기 때문에 티로 팀은 빠름과 안전함을 함께 추구할 수 있었습니다.

Kiro로 수행한 인프라 작업 사례: 세 가지 인프라 통제 개선

티로 팀은 Kiro로 여러 인프라 통제 항목을 점검하고 개선했습니다. 여기서 눈여겨볼 점은 Kiro가 운영 환경을 독자적으로 변경하지 않았다는 사실입니다. Kiro는 현황을 빠르게 수집하고, 변경 초안을 만들고, 증적을 정리했습니다. 사람은 영향도를 판단하고, 승인 지점을 통제하고, 최종 적용 여부를 결정했습니다.

사례 1. 비암호화 스토리지 볼륨 점검과 정비

첫 번째 사례는 비암호화 스토리지 볼륨 점검이었습니다. 보안 인증 준비 과정에서 저장 데이터 암호화는 반드시 확인해야 하는 항목입니다. 하지만 여러 계정과 워크로드에 흩어진 볼륨을 사람이 하나씩 확인하고, 각 볼륨이 어떤 서비스와 연결되어 있는지 파악하려면 시간이 많이 걸립니다.

티로 팀은 Kiro에게 전체 계정의 스토리지 볼륨을 읽기 전용으로 스캔하도록 요청했습니다. Kiro는 비암호화 볼륨의 인벤토리와 각 볼륨에 연결된 워크로드를 표로 정리했습니다. 어떤 리소스도 변경하지 않았고, 조회 결과만 증적으로 남겼습니다.

이후 사람은 Kiro가 정리한 표를 보고 “이 볼륨을 암호화하면 어떤 워크로드에 영향이 있는가”를 판단했습니다. 승인된 볼륨에 한해 스냅샷 기반으로 암호화를 적용했습니다. AI는 인벤토리 수집과 영향도 매핑처럼 반복적이고 노동집약적인 작업을 맡았고, 사람은 판단과 승인에 집중했습니다. 특히 보안 인증 준비처럼 확인해야 할 항목이 많고 증적이 중요한 작업에서는, AI가 현재 상태를 구조화해주는 것만으로도 팀의 속도와 정확도가 높아집니다.

사례 2. 조직 전체 감사 로그를 한 곳으로 집약

두 번째 사례는 감사 로그 중앙화였습니다. 통제 요구사항은 명확했습니다. 모든 계정의 API 활동을 변조 불가능하게 기록하고, 한 곳에서 보관하고 조회할 수 있어야 했습니다.

티로 팀은 이 요구사항을 Kiro Spec의 requirements.md에 그대로 넣었습니다. 그런 다음 Kiro가 각 계정의 현재 추적(trail) 설정을 읽기 전용으로 조사하게 했습니다. 어느 계정에 어떤 설정이 되어 있는지, 중앙화되지 않은 로그가 있는지, 추가로 확인해야 할 정책이 무엇인지 먼저 파악했습니다.

설계 단계에서는 조직 전체 감사 로그(Organization Trail)를 Security 계정의 단일 S3 버킷으로 집약하는 Terraform 초안을 만들었습니다. 이 초안에는 로그 보관 위치, 암호화, 로그 파일 무결성 검증(Integrity validation), 멤버 계정에서 Security 계정으로 로그를 전달하기 위한 교차 계정 정책이 포함되었습니다.

최종 설계는 CTO와 시니어 엔지니어가 검토했습니다. 사람의 승인 이후 변경을 적용했고, 적용 후에는 각 계정의 이벤트가 실제로 Security 계정에 도달하는지 Kiro로 읽기 전용 확인을 진행했습니다. 여기서도 Kiro는 단순히 코드를 생성하는 도구가 아니었습니다. 진단, 설계 초안 작성, 검증 결과 정리를 이어주는 작업 파트너로 동작했습니다.

사례 3. 코드 리뷰 통제 항목 자동 대응

세 번째 사례는 코드 리뷰 통제 항목이었습니다. 컴플라이언스 파트너 점검에서 main 브랜치 병합에 코드 오너 리뷰가 강제되어야 한다는 항목이 확인되었습니다. 여러 저장소에 걸쳐 현재 Branch Protection Rule과 CODEOWNERS 상태를 확인해야 했고, 저장소별 정책 적용 여부도 증적으로 남겨야 했습니다.

• 읽기 전용 수집: 티로 팀은 Kiro를 통해 대상 저장소의 현재 설정을 읽기 전용으로 수집했습니다. 변경 전 상태는 before 증적으로 저장했습니다.
• 설계·초안: 수집 이후 팀 기반 코드 오너 매핑과 “리뷰 1인 필수”, “오래된 리뷰 자동 해제” 같은 브랜치 보호 정책 초안을 만들었습니다.
• 승인: 리뷰어 풀이 너무 좁으면 자기 PR을 승인할 수 없는 교착이 생길 수 있고, 반대로 너무 넓으면 코드 오너 리뷰의 의미가 약해질 수 있습니다. Kiro가 정책 초안을 만들었지만, 실제 팀 구성과 승인 정책은 사람이 검토하고 확정했습니다.
• 적용·증적 보존: 적용 후에는 저장소별 변경 후 상태를 after 증적으로 남겼습니다. 이 증적은 심사 대응 자료로도 활용할 수 있었고, 이후 운영 과정에서 어떤 저장소에 어떤 보호 정책이 적용되어 있는지 확인하는 기준점이 되었습니다.

AI는 넓은 범위의 상태를 빠르게 수집하고, 사람이 검토할 수 있는 구조로 정리하고, 반복적인 증적 작업을 줄였습니다. 사람은 위험을 판단하고, 승인하고, 최종 책임을 졌습니다. 이 역할 분리가 AI 에이전트를 보안 인증 준비에 안전하게 활용하는 핵심이었습니다.

이렇게 티로 팀은 Kiro와 함께 보안 증적에 필수적인 여러 인프라 작업들을 마무리했으며, 이 과정에서 운영 사고 없이 마무리했습니다. 빠름과 안전함을 동시에 가능하게 한 것은 자율적인 AI가 아니라, Spec으로 계획하고 Supervised로 승인받고 스티어링으로 경계를 고정한 AI 에이전트 워크플로우였습니다.

AWS Multi-Account 아키텍처로 통제 경계를 분리하다

티로 팀은 이번 보안 인증을 준비하면서 기존의 단일 계정 아키텍처를 AWS Organizations 기반의 Multi-Account 아키텍처로 변경했습니다. 단일 계정에 모든 것이 섞여 있으면 운영 환경과 개발 환경을 명확히 분리하기 어렵고, 최소 권한과 중앙 감사 로그 같은 통제도 일관되게 적용하기 어렵습니다. AWS Well-Architected 보안 원칙 관점에서도 Multi-Account 구조는 보안 운영의 기본 출발점이 됩니다. 특히 Security Pillar의 자격 증명 및 액세스 관리, 탐지, 인프라 보호 영역과 직접적으로 연결됩니다. 또한 계정 경계, 중앙 로그, 보안 탐지 체계는 데이터 보호과 인시던트 대응를 운영하기 위한 기반이 됩니다.

티로 팀은 다음 2가지 명확한 원칙을 기준으로 계정을 분리했습니다.

• 환경·책임 단위로 계정을 분리한다
• 계정 위에 가드레일(Service Control Policy, SCP)을 적용한다.

먼저 티로 팀은 조직과 결제를 관리하는 Management 계정, 보안 로그와 위임 관리 기능을 담당하는 Security 계정, 공용 운영 기능을 담당하는 Ops 계정, 실제 서비스 운영을 위한 Production 계정, 개발과 실험을 위한 Development 계정을 분리했습니다.

이 구조에서 핵심은 개발 환경과 운영 환경의 경계를 분명히 하는 것이었습니다. AI 에이전트와 함께 빠르게 실험하고 개발하려면 안전한 공간이 필요합니다. 반대로 고객 데이터와 실제 운영 워크로드가 있는 환경에는 더 강한 접근 통제와 승인 절차가 필요합니다. Multi-Account 구조는 이 두 요구를 함께 만족시키는 기반이었습니다.

모든 멤버 계정의 API 활동 로그는 Security 계정으로 집약되도록 설계했습니다. 보안 이벤트 탐지와 설정 추적, 권한 분석과 관련된 관리 기능도 Security 계정을 중심으로 운영했습니다. 이렇게 각 계정에서 발생하는 활동을 중앙에서 확인하고, 통제 항목별 증적으로 연결할 수 있었습니다.

또한 Security 계정으로 감사 로그와 보안 탐지 기능을 모으면, 각 계정에서 발생하는 활동을 중앙에서 확인할 수 있습니다. CloudTrail, Amazon GuardDuty, AWS Config, AWS IAM Access Analyzer 같은 보안 신호를 한곳에 모으면 탐지와 감사 대응이 쉬워지고, 운영 증적도 일관되게 남길 수 있습니다.

결국 Multi-Account 아키텍처는 단순한 계정 분리가 아니라, 보안 책임과 운영 권한을 분리하고, 탐지와 증적을 중앙화하며, AI 에이전트가 안전한 범위 안에서 일하도록 경계를 만드는 구조였습니다.

인프라의 상당 부분은 Terraform 코드로 관리했습니다. 코드로 관리되는 인프라는 변경 이력이 남고, 리뷰를 거치며, 동일한 구성을 재현할 수 있습니다. 보안 인증 관점에서는 이 자체가 중요한 증적입니다. “누가, 언제, 무엇을, 어떤 승인 과정을 거쳐 변경했는가”를 코드와 리뷰 이력으로 설명할 수 있기 때문입니다.

티로 팀이 만든 구조는 단순히 인증을 통과하기 위한 계정 분리가 아니었습니다. AI 에이전트가 자유롭게 도움을 줄 수 있는 영역과 사람이 엄격하게 통제해야 하는 영역을 나누는 운영 경계였습니다. 이 경계 덕분에 팀은 개발 속도를 유지하면서도 고객 데이터와 운영 환경을 보호할 수 있었습니다.

인증 취득 결과와 운영 변화

티로 팀은 약 18주 동안 인증 준비를 진행했고, ISO 27001 인증을 취득했습니다. 착수 시점에 예상했던 최상의 시나리오보다 약 1개월, 최악의 시나리오보다 약 4개월 빠른 일정이었습니다.

Stage 2 본감사에서는 Major 부적합 0건을 기록했습니다. 첫 인증 심사라는 점을 고려하면 의미 있는 결과였습니다. 문서를 빠르게 준비해서가 아니라, 실제 운영 상태와 증적을 연결하는 구조를 먼저 만들었기에 가능했습니다.

티로 팀은 ISO 27001 외에도 SOC 2 Type 1을 취득했고, Type 2 취득을 위한 관찰 기간도 진행했습니다. 또한 CIS Controls v8.1, NIST AI RMF, NIST CSF에 대한 추가 컨트롤 매핑을 완료했습니다. 하나의 ISMS 위에 여러 보안 및 리스크 관리 프레임워크를 얹을 기반을 만든 셈입니다.

인증 준비는 외부 심사를 통과하는 데서 끝나지 않았습니다. 티로 팀은 외부 보안 전문 기업과 계약하여 정기 침투 테스트 체계를 마련했고, Trust Center를 통해 보안 통제 현황을 고객에게 공개하기 시작했습니다. 고객은 티로가 어떤 보안 원칙으로 운영되는지, 어떤 인증과 통제를 갖추고 있는지 더 투명하게 확인하게 되었습니다.

마무리: AI 시대의 보안은 신뢰를 스케일링하는 일

AI 시대에 보안은 더 어려운 주제가 되었습니다. 공격자와 방어자의 인센티브가 다르고, 비용의 비대칭도 존재합니다. 한 번의 방어 실패가 수많은 성공을 무의미하게 만들 수 있습니다.

그렇다고 AI를 개발과 운영에서 배제하는 것이 답은 아닙니다. 더 중요한 일은 AI가 안전하게 일할 수 있는 운영 경계를 만드는 것입니다. 어떤 작업은 읽기 전용으로만 수행하고, 어떤 작업은 Spec으로 설계하며, 어떤 변경은 반드시 사람의 승인을 거쳐야 하는지 명확히 해야 합니다. 변경 전후의 상태가 증적으로 남고, 그 증적이 정책과 통제 항목에 연결되어야 합니다.

티로 팀은 ISO 27001 인증 준비 과정에서 이 운영 방식을 실험하고 정착시켰습니다. Kiro는 빠르게 진단하고 초안을 만들고 증적을 정리했습니다. 사람은 맥락을 판단하고, 위험을 평가하고, 최종 승인을 담당했습니다. AWS 기반의 Multi-Account 구조와 Terraform 기반 변경 관리는 이 역할 분리를 가능하게 한 기술적 기반이었습니다.

인증은 끝이 아니라 운영의 시작입니다. 티로 팀 내부에서 동작하는 에이전트는 이번 인증 과정에서 정리한 통제 내역을 계속 참조합니다. 시스템 리뷰와 일상의 대화 속에서 사람이 놓치기 쉬운 가드레일을 규칙으로 상기시키고, 코드 리뷰와 인프라 변경의 현장에서 통제가 살아 있게 돕습니다.

AI 시대의 병목은 AI만큼 빠르게 스케일하지 못하는 신뢰에 있습니다. 보안과 거버넌스가 AI의 속도를 따라잡지 못하면 AI도 결국 그 속도만큼 안전하게 일할 수 없습니다. 티로 팀이 이번 여정에서 확인한 것은 명확합니다. AI Native 스타트업에게 보안은 속도를 늦추는 장치가 아니라, 더 오래 더 빠르게 달리기 위한 운영 기반입니다.

여러분의 조직에서도 AI 에이전트와 함께 일하고 있다면, 지금이 운영 경계를 정리할 좋은 시점입니다. 읽기 전용 진단부터 시작하고, Spec으로 변경을 구조화하고, 승인 지점을 명확히 하는 것만으로도 첫 걸음이 됩니다. AWS 전문가와 Kiro, 아래 참고자료와 함께 시작해보세요.

• Kiro 시작하기
• AWS 다중 계정 설정 가이드
• ISO 27001 준비 체크리스트