AI Native 시대의 보안 인증 취득 여정
AI가 빠르게 발전하면서 한 명의 엔지니어가 하루 50~100개의 커밋을 작성하는 것은 더 이상 놀라운 일이 아니게 되었습니다. 엔지니어가 코드의 대부분을 AI 에이전트와 함께 작성하기 때문입니다. 하지만 이러한 방식이 언제나 제품을 잘 만드는데 기여하는 것은 아닙니다. AI에게 코드 작성이나 인프라 조작 같은 자율성 높은 작업을 맡기다 보면, 초반에는 시간을 크게 아껴주는 것 같다가도 어느 순간 병목이 생기는 경우가 많습니다. 엄격하게 지켜야 할 가드레일을 놓치게 되고, 하나의 실수가 다른 실수를 부르는 악순환에 빠지기 때문입니다.
빠르게 만들수록 무엇을 지켜야 하는지를 잊기 쉽습니다. 그리고 이것은 결국 AI의 스케일 속도를 신뢰가 따라가지 못하는 병목이 되고, 때로는 치명적인 보안 사고의 원인이 됩니다. 그래서 보안인증을 준비한다는 것은, 시스템적으로 넘어서는 안 되는 레드라인을 명시하는 일이자, 어떤 경우에도 실제 운영되는 제품과 고객의 데이터에 영향을 주지 않겠다고 약속하는 일입니다.
더플레이토(ThePlato)는 AI 회의 노트 '티로(Tiro)'를 만듭니다. 조직의 가장 민감한 대화가 매일매일 티로를 거쳐가기 때문에 티로는 제품 개발 첫 날부터 모든 고객 데이터를 암호화했고, 창업자 3명을 포함해 고객이 5명뿐이던 시절에도 모든 인프라 접근 기록을 남겼습니다. 보안은 회사가 커진 뒤에 덧붙이는 것이 아니라, 처음부터 제품의 일부여야 한다고 믿었기 때문입니다.
2026년 6월 4일, 티로는 국제 보안인증 ISO/IEC 27001:2022를 취득했습니다. 일본 엔터프라이즈 시장 진출이 직접적인 계기였지만, 결과적으로는 보안인증을 취득하는 과정에서 안정적으로 확장가능한 AI Native 인프라를 만드는 것에도 크게 기여했습니다. 이 글은 엔지니어 1명이서 AI 코딩 에이전트 Kiro와 함께 일관성 있고 안전한 인프라를 구축하고, 국제보안인증을 취득한 여정을 기록합니다.
ISO 27001은 무엇을 보는가
ISO/IEC 27001은 흔히 '보안 인증'으로 불리지만, 정확히는 정보보안경영시스템(ISMS, Information Security Management System)에 대한 인증입니다. 서비스 자체의 보안성뿐 아니라, 코드를 작성하고 운영하는 방식, 팀원이 시스템에 접근하는 기기와 정보를 관리하는 방식까지 포괄합니다. 그리고 이 모든 것을 일회성이 아니라 지속적으로 운영하고 있음을 증빙할 수 있을 때 비로소 발급됩니다.
2022년 개정판 기준으로 Annex A에는 93개의 통제 항목이 있고, 감사는 문서 검토 중심의 Stage 1과 실제 운영 증적을 확인하는 Stage 2로 나뉩니다. 핵심은 "통제를 갖추었는가"가 아니라 "통제가 계속 돌아가고 있는가"입니다. 즉, 한 번의 대청소가 아니라 매일의 습관을 평가하는 것이 ISO27001 인증입니다.
일관성 있는 정책 만들기: AI 초안과 맥락 입력
티로는 증적 자동화 및 정책의 일관성을 위하여 컴플라이언스 자동화 플랫폼인 Drata와 계약을 맺었습니다.
Drata에 올라온 ISO 27001 관련 204개 항목의 스코핑부터 시작했습니다. 일반적으로 Scoping의 경우 검토해야 하는 사항들이 많아서 처음 보안 인증을 진행하는 경우 일일이 클릭해서 읽으면 며칠이 걸릴 일이었습니다.
티로 팀에서는 이렇게 하는 대신 브라우저를 조작할 수 있는 AI 에이전트를 병렬로 작업시켜 다음과 같이 작업했습니다. (실제로는 아래 프롬프트보다는 훨씬 상세한 가이드라인과 가드레일들이 들어가야 합니다.)
직접 브라우저를 조작하되, 값을 바꾸는 일은 하지 마.
204개의 모든 옵션을 하나씩 클릭해서 디테일을 꼼꼼히 읽고, 우리 맥락과 인프라를 기준으로 판단하기 애매한 것은 Google Sheet에 정리해 두었다가 나중에 한번에 나에게 물어봐.
읽기 전용이라는 가드레일, 스스로 판단하기 애매한 사항들을 별도로 기록하고 검토를 받으라는 에스컬레이션 규칙과 함께 위 작업들을 Conucil 모델을 통해서 서로 다른 브라우저 에이전트들이 병렬적으로 진행하고, 판단 결과가 다른 경우, 토론하도록 해서 95% 정도 신뢰할 수 있는 1차 검수 결과를 가져오도록 만들었습니다.
에이전트가 전수 검토를 하는 동안 저는 Claude Project를 하나 만들어 거기에 사내 보안 인증 관련된 슬랙 채널을 연동하고, 인프라 설정들을 맥락으로 집어넣는 일들을 했고, 반나절 뒤 범위 제외 후보 18개가 사유와 함께 정리되어 돌아왔습니다. 물리적 보안 구역, 케이블링처럼 풀 클라우드 스타트업에 해당하지 않는 항목들이었습니다.
Scoping을 완료한 이후 Drata팀과의 1차 인터뷰를 통해 해당 Scoping의 적정 여부를 확인한 이후, 정책 문서 작성을 시작했습니다. Drata는 핵심 정책 문서에 대한 초안을 제공하며, 여기에 placeholder와 comment를 통해 조직에 맞는 내용들을 채워넣어야 할 부분들을 알려줍니다. 접근 통제, 암호화, 변경 관리, 사고 대응, 비즈니스 연속성까지의 23개의 정책 문서를 10시간 가량의 Working Hour를 투입하여 완료할 수 있었습니다.
이미 Drata에서 제공하는 1차 초안이 있고, 여기에 조직 내의 충분한 맥락을 가지고 있는 여러 프로젝트들과 Connector들을 통해 2차 정책 문서를 만들고, 이를 기반으로 모호한 질문을 AI가 저에게 인터뷰 하는 식으로 진행하다보니 완성도 높은 최종 Policy 문서를 꼼꼼히 확인하며 완료할 수 있었습니다.
작업 채널의 운영 방식도 통제의 일부가 됐습니다. 저희는 Slack에 컴플라이언스 전용 채널을 만들고, 통제 항목 1개당 스레드 1개라는 규칙으로 모든 작업을 기록했습니다. 누가, 언제, 왜 그 설정을 바꿨는지가 채널에 그대로 남으니, 채널 자체가 감사 증적이 되고, 이후에 AI가 해당 채널을 연동하는 것 만으로 모든 작업 내용을 쉽게 이해할 수 있습니다.
Drata: 증적 수집 자동화 셋업
도구의 역할 분담은 명확했습니다. Drata는 AWS, GitHub, ID등의 Provider들에 커넥터로 연결되어 증적을 자동 수집하고 통제 상태를 상시 모니터링합니다. 감사법인 Sensiba는 그 위에서 실제 심사를 수행하고 인증을 발급합니다.
감사인이 read-only 계정으로 Drata에 직접 들어와 갭분석을 수행했고, ISO 27001과 SOC 2의 통제가 70% 이상 겹치기 때문에 두 인증을 하나의 감사 흐름에서 증적을 공유하며 준비할 수 있었습니다.
Drata의 준비도(readiness) 점수는 팀의 스코어보드가 됐습니다. 2월 중순 10%였던 점수를 4주 만에 80%까지 끌어올렸습니다. 지루해지기 쉬운 컴플라이언스 작업에서, 매일 올라가는 숫자는 생각보다 강한 모멘텀을 만듭니다.
Kiro: AWS 기반 인프라 점검의 핵심 도구
인증 준비에서 가장 손이 많이 가는 영역은 인프라 통제였습니다. 개발 환경 분리, 모니터링, 암호화, 네트워크 접근 제어 관련 통제만 30개가 넘었습니다. 이 구간에서 저희가 가장 크게 의존한 도구가 AWS의 AI 코딩 에이전트 Kiro입니다.
다만 AI에게 프로덕션 인프라를 만지게 하는 일이라, 작업을 진행하기 전에 엄격한 가이드라인부터 정하는 것이 중요했습니다. 모든 인프라 작업은 네 단계를 거치며, 항상 프로덕션 트래픽이 가장 작은 새벽에만 수행했습니다.
Read-only 진단: 에이전트는 읽기 권한만으로 현재 상태를 조사하고 문제를 파악합니다. 이 단계에서는 어떤 변경도 일어나지 않습니다.
롤백 준비: 변경 계획과 함께 되돌리는 방법(스냅샷, 이전 설정값, 삭제 대신 비활성화)을 먼저 확보합니다. 롤백이 준비되지 않은 변경은 실행하지 않습니다.
승인 후 실행: 계획을 사람이 검토·승인한 뒤에야 쓰기 권한으로 실행합니다.
실행 로그 리뷰: 모든 명령과 결과를 로그 파일로 남기고, 사람이 로그를 리뷰해 문제 여부를 판단합니다. 이 로그는 그대로 변경 관리 증적이 됩니다.
몇 가지 예시가 있습니다. (실제 사용한 프롬프트는 이보다 복잡하며, 많은 가이드라인과 가드레일을 포함합니다.)
예시 1 — 모니터링 알람 일괄 구축. Drata는 데이터베이스 CPU·스토리지·IOPS 모니터링, 로드 밸런서 상태 알람 같은 항목을 요구합니다. 먼저 진단 단계의 프롬프트는 이렇습니다.
지금은 진단 단계다. 어떤 리소스도 변경하지 마라 (read-only).
1. 프로덕션 계정의 RDS 인스턴스 목록과 각 인스턴스에 설정된
CloudWatch 알람을 전수 조사해줘.
2. 아래 기준과 비교해 누락된 알람을 표로 정리해줘.
- CPUUtilization > 80% (5분 지속)
- FreeStorageSpace < 10GB
- ReadIOPS > 1,000
3. 알람 액션으로 연결할 SNS 토픽이 있는지 확인하고, 없으면 생성안을 제안해줘.
에이전트가 만든 누락 항목 표를 검토한 뒤, 실행 단계는 별도의 프롬프트로 넘깁니다.
방금 정리한 누락 알람을 생성해줘.
제약 (MUST NOT):
- 기존 알람과 토픽을 수정하거나 삭제하지 마라
- 실행 전에 생성할 리소스의 이름과 파라미터 계획을 보여주고 승인을 받아라
기록:
- 실행한 모든 AWS CLI 명령과 응답을 logs/2026-02-19-rds-alarms.log 에 남겨라
완료 후에는 생성된 리소스의 ARN 목록과 로그 파일 경로만 보고해줘.
이 형식으로 Amazon SNS 토픽 하나와 Amazon CloudWatch 알람 여섯 개가 생성됐고, 같은 패턴을 로드 밸런서·Lambda 에러율 알람으로 복제해 이틀 만에 모니터링 통제 약 30개를 정리했습니다. 보고 형식을 ARN 목록으로 고정해두면, 사람의 검증은 "보고된 ARN이 콘솔에 실제로 있는가, 로그에 계획 밖의 명령이 없는가"라는 명확한 체크리스트가 됩니다.
예시 2 — Amazon EBS 기본 암호화 마이그레이션. Drata 모니터링이 계정의 EBS 기본 암호화가 꺼져 있다는 사실을 잡아냈습니다. 계정 수준 기본 암호화를 켜는 것은 한 줄이지만, 이미 떠 있는 비암호화 볼륨들이 문제였습니다. 진단 단계에서 Kiro가 비암호화 볼륨의 전체 인벤토리와 각 볼륨에 붙은 워크로드를 정리했고, 볼륨마다 롤백 지점이 되는 스냅샷을 먼저 확보한 뒤에야 교체를 시작했습니다. Amazon ECS 시작 템플릿을 암호화 볼륨 기준으로 수정해 개발 환경에서 검증하고 프로덕션에 적용했으며, 고정 IP가 붙은 인스턴스는 스냅샷에서 암호화 볼륨을 복원해 교체했습니다.
아래에서 더 자세히 설명하겠지만, 티로는 보안 인증을 준비하는 과정에서 인프라를 코드로 관리하기 위해 Terraform으로 마이그레이션 하는 과정을 단행했습니다. Kiro를 사용해서 작업할 때, 진단 단계에서 각 리소스가 Terraform 상태 파일에 있는지, 그리고 코드가 있는 리소스는 Terraform 코드를 수정해서 적용하고, 코드 밖의 리소스만 직접 변경하되 변경 로그를 남기도록 작업했습니다. 감사 대응 작업 자체가 변경 관리 프로세스를 통과하게 한 것입니다.
다음과 같은 방식으로 Kiro와 함께 인프라 작업을 마무리했으며, 이 과정에서 단 한번의 인프라 변경작업에서의 실수도 발생하지 않았습니다.
목표는 선언적으로, 절차는 위임. "알람 여섯 개를 이 조건으로 만들어줘"까지만 정의하고, 어떤 API를 호출할지는 에이전트에 맡깁니다.
완료 보고 형식을 지정. "ARN 목록과 로그 파일 경로만 보고해줘." 보고 형식이 곧 검증 체크리스트가 됩니다.
금지 조항(MUST NOT)을 명시. "기존 리소스를 수정·삭제하지 마", "실행 전 계획을 보여주고 승인을 받아."
반복되는 규칙은 프롬프트가 아니라 steering 파일로. Kiro는
.kiro/steering/디렉토리의 마크다운을 영속 컨텍스트로 사용합니다. 암호화 기준, 태깅 규칙, 최소 권한 원칙, 위의 4단계 작업 패턴 같은 컴플라이언스 요구사항을 steering에 넣어두면, 매 프롬프트에서 반복하지 않아도 모든 작업에 같은 기준이 적용됩니다.
권한 설계도 같은 철학을 따랐습니다. 에이전트의 AWS 자격 증명은 read-only로 시작해서, 신뢰가 쌓인 작업 유형에만 점진적으로 쓰기 권한을 열었습니다. 변경 작업은 Kiro의 Supervised 모드처럼 사람의 승인을 거치게 하고, 에이전트가 남기는 실행 로그와 별개로 모든 변경은 AWS CloudTrail에 이중으로 기록되어 그 자체가 감사 증적이 됩니다. AI에게 인프라를 맡기는 일과 통제를 지키는 일은 상충하지 않습니다. 가드레일을 시스템에 넣으면, 오히려 AI가 가장 일관성 있는 운영자가 됩니다.
Terraform 마이그레이션 & Multi-Account 구조
인증 준비 기간에 단행한 가장 큰 구조 변화는 AWS Organizations 기반의 멀티 어카운트 전환이었습니다. 관리(Management), 보안(Security), 운영(Ops), 프로덕션(Prod), 개발(Dev): 책임과 환경별로 계정을 분리해, 권한의 경계와 공격 표면을 계정 단위로 격리했습니다. 개발 환경의 어떤 실수도 프로덕션의 고객 데이터에 닿을 수 없는 구조입니다.
로그는 조직 수준에서 정리합니다. AWS CloudTrail을 Organization Trail로 구성해 전 계정의 로그가 Security 계정의 중앙 Amazon S3 버킷에 자동 수집되게 했고, AWS KMS(AWS Key Management Service) 고객 관리형 키로 암호화한 뒤 수명 주기 정책으로 보관 비용을 통제했습니다.
이 전환을 마치고 나니 인프라의 약 80%가 Terraform 코드가 되어 있었습니다. 그러자 흥미로운 일이 생겼습니다. EBS 기본 암호화 같은 통제가 코드에 명시되어 있으니, 새로 만들어지는 인프라는 태어날 때부터 컴플라이언트합니다. 점검할 것은 코드 이전에 만들어진 과거뿐이고, 그 과거는 Kiro와 함께 청산하면 됩니다.
인증 취득 결과
2026년 6월 5일, ISO/IEC 27001:2022 인증 취득. 첫 삽부터 약 18주로, 착수 시점에 예상했던 최상의 시나리오보다 1개월, 최악의 시나리오보다 4개월 빨랐습니다.
Stage 2 본감사 Major 부적합 0건. 감사 과정에서 첫 인증 심사 기준으로 매우 적은 수치라는 평가를 받았습니다.
SOC 2 Type 1 취득(4월), Type 2 취득 임박. 6월 말까지 관찰 기간이 끝나면 7월 중 보고서가 발행됩니다.
CIS Controls v8.1, NIST AI RMF, NIST CSF 추가 컨트롤 매핑 완료. 하나의 ISMS 위에 여러 프레임워크를 얹는 구조를 만들었습니다.
티오리(Theori)와의 계약으로 정기 침투 테스트 체계 가동. 화이트박스 방식으로 소스 코드와 인프라 전체를 점검합니다.
인증과 동시에 Trust Center를 열어 보안 통제 현황을 고객에게 상시 공개하고 있습니다.
신뢰를 스케일링하기
AI 시대에 보안은 어려운 주제입니다. 공격자와 방어자의 인센티브가 다르고, 비용의 비대칭이 존재합니다. 한 번의 방어 실패가 수많은 성공을 무의미하게 만듭니다. 그럼에도 안티프래질(antifragile)의 관점에서 시스템의 취약점을 먼저 들여다보는 일은, 오히려 제품 개발의 상방을 높이는 길이라고 생각합니다. 보안이 중요한 소프트웨어에서는 하방을 막아두는 것이 상방을 여는 것보다 훨씬 더 지속가능하기 때문입니다.
인증은 끝이 아니라 운영의 시작입니다. 저희 팀 내부에서 동작하는 사내 에이전트는 이번 인증의 통제 내역을 온톨로지로 기억합니다. 시스템 리뷰와 일상의 대화 속에서, 사람이 놓치기 쉬운 가드레일을 에이전트가 규칙으로 잡아주고 매 순간 따르도록 넛지합니다. 정책 문서함에 잠든 통제가 아니라, 코드 리뷰와 인프라 변경의 현장에 살아 있는 통제입니다.
AI 시대의 병목은 AI만큼 빠르게 스케일하지 못하는 사람과 신뢰에 있습니다. 보안과 거버넌스가 AI의 속도를 따라잡지 못하면, AI도 결국 그 속도만큼 일할 수 없습니다. 그래서 저희는 신뢰를 스케일링하는 일에 가장 높은 우선순위를 둡니다.