figma2026년 7월 1일

검증할 수 있는 신뢰: Figma, 이제 ISO 42001 인증 획득 | Figma 블로그 (새 탭에서 열림)

Figma는 AI 거버넌스 관리 체계(AIMS)에 대해 국제 표준 ISO/IEC 42001:2023 인증을 획득했다고 발표했습니다. 이번 인증은 자체 설명이 아니라 ANAB 공인 인증기관인 Schellman의 독립적인 심사를 통해 정책, 위험 관리, 데이터 관행, 기술적 보호조치가 실제로 운영되고 있음을 검증받았다는 의미입니다. Figma는 이를 통해 규제 산업 고객이 AI 관련 공급업체 위험 평가와 규제 보고에 활용할 수 있는 객관적 근거를 제공한다고 강조합니다. ## ISO/IEC 42001과 AI 관리 시스템 - ISO/IEC 42001은 2023년 12월 제정된 AI 관리 시스템 국제 표준입니다. - 정보보호 관리체계 표준인 ISO 27001과 유사하게, 조직이 AI를 책임 있게 개발·배포·운영하기 위해 필요한 정책과 절차, 통제 항목을 정의합니다. - AI 관리 시스템(AIMS)은 다음 활동을 관리하는 운영 기반입니다. - AI 기능의 설계와 개발 - 제품 내 AI 배포 - 데이터 및 위험 관리 - 성능과 영향 모니터링 - 인간의 감독과 책임 체계 유지 ## 자체 문서보다 독립적 검증이 중요한 이유 - AI 공급업체는 백서, 보안 설문, 정책 문서 등을 통해 거버넌스 수준을 설명할 수 있지만, 문서만으로는 실제 통제가 작동하는지 판단하기 어렵습니다. - ISO 42001 인증은 공인된 제3자가 국제 표준에 따라 관리 체계를 직접 심사했다는 점에서 자체 평가와 구별됩니다. - Figma는 Schellman이 다음 항목을 검토했다고 설명합니다. - AI 거버넌스 정책 - 데이터 처리 관행 - AI 위험 관리 절차 - 기술적 보호조치 - 실제 운영 효과 - 따라서 고객은 Figma의 설문 답변만 검토하는 대신, 벤더 위험 평가·이사회 보고·규제 제출에 활용할 수 있는 외부 검증 결과를 참고할 수 있습니다. ## 인증 적용 범위 - 인증 대상은 Figma 플랫폼 전반의 AI 기능을 관리하는 AIMS입니다. - 적용 제품은 다음과 같습니다. - Figma Design - Figma Make - FigJam - Dev Mode - Figma Sites - Figma Slides - Figma Draw - Figma Buzz - Figma Weave ## 실제 심사 방식과 9개 통제 목표 - 심사는 두 단계로 진행되었습니다. - **1단계:** AIMS의 설계, 문서, 정책, 위험 평가 방법론 검토 - **2단계:** 직원 인터뷰, 업무 프로세스 관찰, 실제 운영 효과 평가 - 총 38개 통제를 다음 9개 Annex A 통제 목표에 따라 평가했습니다. - AI 영향 평가 - 거버넌스와 책임 - AI 특화 위험 관리 - AI 시스템 생명주기 관리 - 데이터 거버넌스 - 제3자 AI 위험 관리 - 모니터링과 성능 평가 - 인간의 감독 - AI 시스템의 책임 있는 사용 - Figma는 이번 인증이 관련 개념을 문서화했다는 사실보다, 실제 프로세스에 적용하고 운영하고 있음을 검증한 데 의미가 있다고 설명합니다. - 인증기관 자체도 ANAB의 공인을 받았기 때문에, 비공인 기관의 인증보다 신뢰성과 객관성이 높다고 강조합니다. ## 규제 산업 고객에게 의미하는 점 - Figma의 AI 기능은 금융, 의료, 보험, 공공 부문 등 보안·개인정보·규제 요구가 높은 환경에서 사용될 수 있습니다. - 이런 조직은 AI 공급업체를 평가할 때 다음을 입증해야 할 수 있습니다. - AI 위험을 식별하고 관리하는지 - 데이터가 적절히 통제되는지 - AI 시스템에 인간의 감독이 존재하는지 - 공급업체의 통제가 실제로 운영되는지 - EU AI 법(EU AI Act)과 새로운 AI 조달 기준은 단순한 선언보다 증빙을 요구하는 방향으로 발전하고 있습니다. - ISO 42001 인증은 기업의 벤더 위험 관리, 감사 대응, 이사회 보고, 규제 제출에 활용 가능한 공식 근거가 될 수 있습니다. ## 향후 지속적인 검증 - Figma는 AI 기능이 확대될수록 거버넌스 체계도 계속 제3자 검증에 맡기겠다고 밝혔습니다. - ISO 42001 인증서는 기존 ISO 27001 및 SOC 2 Type II 인증과 함께 제공됩니다. - 인증서와 보안·컴플라이언스 문서는 `compliance.figma.com`에서 확인할 수 있으며, Schellman 인증서 디렉터리를 통해 인증을 검증할 수 있습니다. - Figma는 AI 거버넌스가 변경되어 고객의 위험 평가에 영향을 줄 경우 이를 투명하게 알리고, 관련 정보를 지속적으로 최신 상태로 유지하겠다고 약속합니다. 실무적으로는 AI 서비스를 도입하거나 갱신할 때 공급업체의 자체 설명만 확인하기보다, ISO 42001처럼 공인기관이 검증한 인증 범위·유효기간·적용 제품을 함께 확인하는 것이 바람직합니다.

security-complianceaidata-governanceai-governance+3

gitlab2026년 6월 17일

GitLab, 2026 Gartner® DevSecOps 플랫폼 매직 쿼드런트™에서 리더로 선정 (새 탭에서 열림)

GitLab은 Gartner의 2026년 DevSecOps 플랫폼 매직 쿼드런트에서 4년 연속 리더로 선정됐다고 발표했습니다. 글은 AI 코딩 에이전트가 개발 속도는 높였지만 파이프라인, 보안, 배포, 비용 관리 등 후속 단계의 병목을 키웠다고 지적합니다. 이에 GitLab은 소스 코드부터 CI/CD, 보안, 배포, 거버넌스를 통합해 에이전트 시대에 ‘속도와 통제’를 동시에 제공하는 플랫폼을 지향한다고 설명합니다. ## AI 에이전트가 만든 새로운 병목 - 개발자들은 여러 AI 코딩 어시스턴트를 사용하며 코드 생산량이 빠르게 증가하고 있습니다. - 그러나 코드 작성 속도가 빨라져도 전체 소프트웨어 출시 속도가 반드시 개선되지는 않습니다. - 증가한 코드량은 다음 영역에 부담을 전가합니다. - CI/CD 파이프라인 구성 - 보안 취약점 및 보안 경고 처리 - 배포 순서 조정 - 인프라 및 도구 비용 관리 - 한 단계의 속도만 높이면 병목이 다음 단계로 이동하므로, 단순히 코딩 도구를 추가하는 방식으로는 충분하지 않습니다. - GitLab은 이를 “속도와 통제(speed with control)”의 문제로 정의합니다. ## 에이전트 시대의 통제 계층 - 기업은 에이전트가 다음과 같은 작업을 수행하는 방식을 통합적으로 관리해야 합니다. - 누가 에이전트를 실행하는가 - 어떤 데이터에 접근할 수 있는가 - 어떤 작업을 수행할 수 있는가 - 작업 내역을 감사할 수 있는가 - GitLab은 소스 코드 관리, CI/CD, 보안, 배포를 하나의 플랫폼에 통합합니다. - 개발자나 AI 에이전트가 변경 사항을 만들더라도 기존 코드, 파이프라인, 정책을 기준으로 검증한 뒤 배포하도록 지원합니다. - 따라서 GitLab은 에이전트가 생성한 결과를 프로덕션에 적용하기 전에 검증하고 통제하는 중앙 계층을 자처합니다. ## 대규모·규제 환경을 위한 플랫폼 - Ericsson은 GitLab을 통해 배포 시간을 절반으로 줄였다고 소개됩니다. - Southwest Airlines는 24시간 운영되는 항공 시스템에서 미션 크리티컬 소프트웨어를 관리합니다. - Barclays PLC와 같은 규제 산업 기업은 보안·컴플라이언스 요구사항을 유지하면서 소프트웨어를 출시해야 합니다. - GitLab은 다음 배포 형태에서 동일한 플랫폼 및 거버넌스 기능을 제공한다고 설명합니다. - 멀티테넌트 SaaS - 싱글테넌트 SaaS - 자체 관리형(Self-managed) 배포 - 에어갭 환경 및 자체 호스팅 모델 기반 에이전트 - SaaS와 온프레미스 환경 모두에서 AI 기능과 배포 통제력을 유지하는 점을 Gartner가 강점으로 평가했다고 주장합니다. - 외부 도구와 AI 서비스를 연동하면서도 하나의 거버넌스 경계 안에서 관리할 수 있습니다. ## 엔터프라이즈급 가용성과 책임 - 에이전트 작업을 전체 개발 생명주기에 걸쳐 조정하려면 플랫폼의 안정적인 가용성이 필수입니다. - GitLab은 Ultimate 고객을 대상으로 GitLab.com과 GitLab Dedicated에 월간 99.9% 가용성을 약정합니다. - 가용성이 기준 이하로 떨어지면 대상 고객은 향후 청구서에 사용할 서비스 크레딧을 받을 수 있습니다. - GitLab은 이러한 보상 체계가 실제 고객 경험에 대한 플랫폼의 책임을 명확히 한다고 설명합니다. ## 속도와 통제를 강화하는 5가지 혁신 - **차세대 소스 코드 관리** - 머신 규모의 작업을 목표로 설계되었습니다. - 테스트 결과 최대 50배 빠른 실행과 최대 1,000배 적은 네트워크 데이터 전송을 달성했다고 밝힙니다. - **GitLab Orbit** - 코드, 작업 항목, 파이프라인, 배포, 운영 신호를 연결하는 컨텍스트 그래프입니다. - Claude Code와 함께 사용할 경우 동일한 모델과 작업에서 최대 11배 빠른 실행을 제공한다고 설명합니다. - 토큰 사용량은 최대 4.5배, 환각은 최대 45배 줄일 수 있다고 주장합니다. - **보안·거버넌스 에이전트** - 에이전트가 늘어나면서 발생하는 보안 및 컴플라이언스 공백을 관리합니다. - **에이전트 트리거** - 개발자와 에이전트 간 작업 인계를 자동화합니다. - 사람이 각 단계의 진행을 직접 조정하지 않아도 작업 흐름을 연결할 수 있습니다. - **GitLab Flex 계약** - 계약을 변경하지 않고도 제품 및 기능별 GitLab 사용량과 비용 구성을 조정할 수 있도록 지원합니다. ## GitLab이 제시하는 전략적 방향 - GitLab은 기업이 다음 세 가지를 하나의 체계로 확보해야 한다고 강조합니다. - 하나의 통합 플랫폼 - 하나의 컨텍스트 그래프 - 하나의 거버넌스 경계 - 이를 통해 개발자와 AI 에이전트가 함께 소프트웨어를 만들면서도 보안, 정책, 비용, 배포 통제를 유지할 수 있다는 주장입니다. - GitLab은 175개월 이상 연속으로 매달 새로운 기능을 출시하며 혁신을 이어가고 있다고 덧붙입니다. - Gartner의 평가는 GitLab이 단순한 개발 도구가 아니라 전체 소프트웨어 생명주기를 조율하는 DevSecOps 플랫폼으로 자리 잡았다는 점을 반영한다고 설명합니다. 실무적으로는 AI 코딩 도구 도입 자체보다, 생성된 코드의 검증·보안·배포·감사·비용 관리를 하나의 통제 체계로 연결하는 것이 중요합니다. 여러 에이전트를 운영하는 조직이라면 GitLab과 같은 통합 플랫폼을 검토하되, Gartner의 평가와 공급업체의 성능 수치는 실제 환경에서 별도로 검증하는 것이 좋습니다.

security-complianceaigitlabci-cd+4

gitlab2026년 3월 4일

깃랩이 보안 통제 (새 탭에서 열림)

GitLab의 보안 컴플라이언스 팀은 기존의 범용 보안 제어 프레임워크가 자사의 클라우드 네이티브 환경과 다각화된 제품군에 최적화되어 있지 않다는 점을 발견하고, 이를 해결하기 위해 자체적인 'GitLab 제어 프레임워크(GCF)'를 구축했습니다. GCF는 복잡한 인증 요구사항을 통합 관리하면서도 개별 제품의 특성을 반영할 수 있도록 설계되어, 불필요한 보안 규제를 줄이고 실질적인 보안 운영 효율을 높이는 데 기여하고 있습니다. 결과적으로 이러한 맞춤형 프레임워크는 조직이 확장됨에 따라 늘어나는 다양한 외부 인증(SOC 2, ISO, FedRAMP 등)에 유연하고 빠르게 대응할 수 있는 기반이 되었습니다. ### 기존 프레임워크의 한계와 맞춤형 프레임워크의 필요성 * NIST SP 800-53과 같은 범용 프레임워크는 1,000개 이상의 방대한 제어 항목을 포함하지만, 모든 항목이 GitLab의 클라우드 환경에 필수적인 것은 아니었습니다. * 범용 항목은 세분성(Granularity)이 부족하여 실무 적용에 어려움이 있었습니다. 예를 들어 NIST의 '계정 관리(AC-2)'는 계정 생성, 수정, 삭제, 모니터링 등 성격이 다른 6개 이상의 활동을 하나로 묶어 관리하므로 책임 소재와 테스트 절차가 불명확해지는 문제가 발생합니다. * 불필요하거나 과도하게 제한적인 제어 항목은 실무자들이 보안 절차를 우회하도록 유도하여 오히려 전체적인 보안 수준을 저하시킬 위험이 있습니다. ### GitLab 제어 프레임워크(GCF) 구축 단계 * **요구사항 분석 및 벤치마킹**: SOC 2, ISO 시리즈, PCI DSS, FedRAMP 등 현재와 미래의 모든 인증 요구사항을 매핑하여 베이스라인을 설정하고, NIST CSF나 Adobe/Cisco의 CCF 같은 선진 사례를 참고하여 구조적 누락을 방지했습니다. * **도메인 및 계층 구조 설계**: GitLab의 실제 보안 운영 조직과 일치하도록 18개의 커스텀 도메인을 정의하고, '무엇을 구현해야 하는가(Level 1)'와 '제품별로 어떻게 구현했는가(Level 2)'를 분리하여 설계했습니다. * **상세 메타데이터 통합**: 단순한 제어 항목 설명을 넘어 소유자(Owner), 적용 환경, 대상 자산, 수행 빈도, 자동화 수준(Nature), 테스트 세부 정보 등의 구체적인 데이터를 각 항목에 결합했습니다. ### 멀티 제품 환경을 위한 계층적 제어 구조 * GitLab.com(멀티테넌트 SaaS), GitLab Dedicated(단일 테넌트), 정부용 Dedicated 등 각 제품군이 서로 다른 인프라(GCP, AWS)와 감사 요구사항을 가지므로, 이를 개별 프레임워크로 관리하는 대신 계층화된 구조를 도입했습니다. * 조직 전체에 공통으로 적용되는 '엔티티 제어(Entity Controls)'는 모든 제품이 상속받고, 제품별 고유한 구현 방식은 하위 계층(Level 2)에서 별도로 캡처하여 관리 중복을 최소화했습니다. * 이러한 구조 덕분에 특정 팀이 소유한 항목이나 자동화가 가능한 수동 프로세스를 즉각적으로 필터링하여 파악할 수 있는 '운영 가능한 인벤토리'를 구축하게 되었습니다. ### 지속 가능한 확장 및 성숙도 확보 * 새로운 국가적 인증(ISMAP, IRAP 등)을 추진할 때, GCF에 이미 구축된 데이터와 비교하여 격차(Gap)를 신속하게 식별하고 필요한 제어 항목만 추가하는 방식으로 대응 속도를 높였습니다. * 제어 항목의 성숙도를 정기적으로 평가하고 자동화 비중을 높임으로써, 컴플라이언스 업무가 단순히 감사를 준비하는 행위에 그치지 않고 지속적인 보안 강화 프로세스로 작동하도록 유도합니다. 성공적인 보안 컴플라이언스 프로그램을 운영하기 위해서는 표준 프레임워크를 맹목적으로 따르기보다 조직의 비즈니스 구조와 운영 방식에 맞게 재설계하는 과정이 필요합니다. GitLab처럼 제어 항목의 '요구사항'과 '구현 방식'을 분리하고 상세한 운영 컨텍스트를 메타데이터로 관리한다면, 복잡한 멀티 인증 환경에서도 일관성 있고 효율적인 보안 체계를 유지할 수 있습니다.

security-compliancedatabase-designgitlabcloud-native+4

figma2019년 8월 26일

Figma 데이터의 안전한 보호 및 (새 탭에서 열림)

Figma는 고객의 디자인 데이터와 지식재산을 보호하기 위해 보안을 제품 개발과 인프라 운영 전반의 핵심 원칙으로 삼고 있다. SOC 2 인증, 유럽 데이터 보호 체계, 플러그인 권한 제한, SAML 기반 SSO 등을 통해 규정 준수와 실제 서비스 보안을 함께 강화했다. 이후 업데이트에서는 SOC 2 Type 2와 SOC 3 보고서까지 취득해 내부 통제가 일정 기간 안정적으로 작동했음을 입증했다. ## SOC 2 인증으로 검증한 보안 통제 - SOC 2는 클라우드에 저장된 고객 데이터를 보호하기 위한 미국 소프트웨어 기업의 대표적인 보안 준수 기준이다. - 인증 과정에서 인프라, 소프트웨어, 인사 절차, 고객 데이터 처리 정책과 통제를 종합적으로 감사한다. - SOC 2 Type 1은 특정 시점에 통제가 마련되어 있는지를 확인하는 일종의 스냅샷이다. - SOC 2 Type 2는 통제가 일정 기간 실제로 작동했는지까지 검증하므로 더 높은 수준의 보증을 제공한다. - Figma는 글 작성 당시 Type 1 인증을 완료하고 Type 2를 추진 중이었으며, 2020년 업데이트에서 SOC 2 Type 2와 SOC 3 보고서 취득을 발표했다. ## 유럽 고객을 위한 데이터 보호와 준수 - 유럽 고객 증가에 맞춰 EU와 국제적인 데이터 보호 및 보안 요구사항을 충족하는 것을 목표로 했다. - EU-US Privacy Shield와 Swiss-US Privacy Shield 프레임워크 인증을 취득했다. - 이를 통해 유럽 및 스위스 고객이 Figma에 디자인 데이터를 저장할 때 필요한 개인정보 보호 체계를 마련했다고 설명한다. ## 기능 개발 단계부터 적용한 보안 원칙 - 보안은 별도의 사후 검토가 아니라 새로운 기능을 설계하고 개발하는 단계부터 고려하는 원칙으로 제시된다. - 특히 Figma Plugins처럼 외부 개발자가 플랫폼을 확장하는 기능은 보안·안정성·성능 사이의 균형이 중요했다. - 플러그인은 한 번에 하나의 디자인 파일에만 접근할 수 있다. - 플러그인이 사용자의 전체 계정이나 다른 플러그인의 데이터에 접근할 수 없도록 격리했다. - 플러그인이 Figma UI를 변경하지 못하게 해 사용자를 속이거나 피싱으로 유도할 가능성을 줄였다. - 일부 기능과 확장성을 제한하더라도 고객 데이터 보호를 우선한 설계 결정이었다. ## SAML SSO를 통한 기업 계정 관리 - 기업 고객을 위해 SAML 기반 싱글 사인온(SSO)을 지원했다. - SSO는 로그인 절차를 단순화하는 동시에 조직 전체에 Figma를 배포하고 사용자 접근 권한을 중앙에서 관리할 수 있게 한다. - 기존 Okta와 Microsoft Azure Active Directory에 더해 OneLogin도 통합 대상으로 추가했다. - 기업은 기존 인증·접근 관리 체계와 Figma를 연결해 퇴사자 계정 차단이나 사용자 권한 관리 등을 일관되게 운영할 수 있다. ## 실용적인 시사점 Figma의 사례는 SaaS 보안에서 인증서 취득만으로 끝나는 것이 아니라, 장기간 작동하는 내부 통제와 기능별 권한 격리, 기업용 접근 관리까지 함께 구축해야 한다는 점을 보여준다. 특히 플러그인이나 확장 기능을 도입할 때는 가능한 기능을 늘리는 것보다 데이터 접근 범위를 최소화하고 사용자 신뢰를 보호하는 설계가 우선되어야 한다.

security-compliancecloud-securitysamlsoc-2+2