AI는 취약점을 감지할 수 있지만, 누가 위험을 관리하는가? (새 탭에서 열림)

AI의 발전으로 취약점 탐지 및 수정 제안의 자동화가 가속화되고 있으나, 실제 기업 보안의 핵심은 탐지 그 이상인 거버넌스와 위험 관리에 있습니다. 소프트웨어가 AI에 의해 조립되고 의존성이 복잡해지는 현대적 환경에서 단순한 코드 분석만으로는 보안 책임을 다할 수 없으며, 정책 집행과 가시성을 제공하는 통합 플랫폼의 역할이 더욱 중요해지고 있습니다. 결국 AI를 통한 생산성 향상의 성패는 기술 자체보다 이를 안전하게 통제하고 신뢰할 수 있는 거버넌스 체계를 구축하느냐에 달려 있습니다. **AI 신뢰를 뒷받침하는 거버넌스 체계** * AI 시스템(예: Claude Code Security)은 취약점을 식별하고 수정을 제안하는 데 뛰어나지만, 이는 분석일 뿐 책임(Accountability)의 영역은 아닙니다. * 기업의 보안 정책이나 허용 가능한 위험 수준을 정의하는 것은 인간의 영역이며, AI 에이전트가 작동할 경계와 가드레일을 직접 설정해야 합니다. * AI에게 더 많은 자율성을 부여할수록 직무 분리, 감사 추적, 일관된 통제와 같은 강력한 거버넌스가 AI 개발 환경의 신뢰를 지탱하는 기초가 됩니다. **코드 이상의 맥락(Context) 파악의 중요성** * 거대언어모델(LLM)은 개별 코드를 격리된 상태에서 평가하지만, 보안 플랫폼은 해당 코드가 비즈니스에 미치는 영향도와 인프라 간의 상호작용 등 전체 맥락을 이해합니다. * 취약점이 실제 운영 환경에서 실행 가능한 경로에 있는지(Reachable), 혹은 외부 API 및 환경 설정에 의해 실제로 악용될 수 있는지 판단하여 보안 소음을 줄입니다. * 누가 변경을 수행했는지와 애플리케이션의 중요도를 결합한 맥락 정보가 있어야만 개발 속도를 늦추지 않고 효과적인 위험 우선순위 선정이 가능합니다. **동적 위험에 대응하는 지속적 보증** * 소프트웨어 위험은 의존성 변화와 환경 진화에 따라 끊임없이 변하므로, 배포 시점의 일회성 스캔만으로는 안전을 보장할 수 없습니다. * 개발 워크플로에 보안 제어를 직접 삽입하여 빌드, 테스트, 배포 전 과정에서 실시간으로 위험을 평가하는 지속적인 보증(Continuous Assurance) 체계가 필요합니다. * AI 생성 코드와 오픈 소스 라이브러리가 혼재된 복잡한 공급망을 관리하기 위해서는 전체 소프트웨어 수명 주기를 통합적으로 관리하는 오케스트레이션이 필수적입니다. AI 보조 도구는 개발 속도를 획기적으로 높여주지만, 기업은 이를 안전하게 확장하기 위해 거버넌스 중심의 접근 방식을 택해야 합니다. 단순히 똑똑한 AI 어시스턴트를 도입하는 것에 그치지 않고, GitLab과 같은 통합 플랫폼을 통해 정책 집행과 보안 스캔, 감사 기능을 개발 워크플로에 내재화함으로써 AI 시대에 걸맞은 보안 신뢰를 구축할 것을 권장합니다.

Data Intensity의 Oracle Cloud Infrastructure (새 탭에서 열림)

GitLab은 Oracle Cloud Infrastructure(OCI) 및 관리 서비스 전문 기업인 Data Intensity와 협력하여 'DevSecOps-as-a-Service'를 출시했습니다. 이 서비스는 GitLab Self-Managed 버전이 제공하는 강력한 통제권과 보안성을 유지하면서도, 인프라 운영 및 유지보수에 따른 부담을 완전히 해소하는 것을 목표로 합니다. 기업은 OCI의 가성비 높은 클라우드 인프라와 전문가의 관리 서비스를 통해 복잡한 플랫폼 관리 대신 소프트웨어 개발 본연의 가치에 집중할 수 있습니다. ## GitLab Self-Managed의 가치와 운영상의 도전 과제 * **완전한 제어권:** 데이터 위치, 인스턴스 구성, 보안 및 규정 준수 요구 사항을 조직의 목적에 맞게 커스터마이징할 수 있습니다. * **운영의 복잡성:** 자체 관리형 환경을 운영하려면 서버 관리, 정기적인 업데이트 및 패치, 고가용성(HA) 확보, 재해 복구(DR) 시스템 구축을 위한 전문 인력과 자원이 필요합니다. * **리소스 분산:** 인프라 유지보수에 많은 에너지를 쏟게 되면 정작 중요한 애플리케이션 개발과 배포 속도가 늦어지는 부작용이 발생할 수 있습니다. ## Data Intensity가 제공하는 관리형 서비스의 핵심 * **전문가 관리형 인스턴스:** OCI 인프라 위에서 실행되는 독립적인 GitLab 인스턴스를 Data Intensity 전문가 팀이 직접 관리합니다. * **연중무휴 지원:** 24x7 모니터링, 알람 시스템, 기술 지원을 통해 서비스 안정성을 보장합니다. * **체계적인 유지보수:** 고객이 선택한 유지관리 시간에 맞춰 분기별 패치를 진행하며, 자동화된 백업 및 재해 복구 보호 기능을 제공합니다. * **유연한 확장성:** 조직의 사용자 규모와 복구 요구 사항에 맞춘 계층형 아키텍처를 제공하여 팀의 성장에 따라 유연하게 확장할 수 있습니다. ## Oracle Cloud Infrastructure(OCI) 도입의 이점 * **비용 효율성:** 타사 하이퍼스케일러 클라우드 대비 인프라 비용을 약 40-50% 절감할 수 있어 대규모 배포에 유리합니다. * **다양한 배포 모델:** 공공 클라우드뿐만 아니라 정부 전용 클라우드, EU 주권 클라우드, 방화벽 내부의 전용 인프라 등 엄격한 규제를 준수하는 다양한 환경을 지원합니다. * **일관된 성능:** 고성능 클라우드 환경에서 일관된 툴링과 운영 경험을 제공하며, 하이브리드 및 글로벌 환경 전반에서 GitLab 배포를 표준화할 수 있습니다. ## 도입 권장 대상 및 결론 * GitLab Self-Managed의 통제권은 필요하지만 내부 인프라 전문가가 부족하여 운영 오버헤드를 최소화하고 싶은 조직에 권장됩니다. * 특히 엄격한 데이터 거주 요건(Data Residency)이나 보안 컴플라이언스를 준수해야 하는 금융, 공공, 의료 분야 기업에 적합한 솔루션입니다. * 기존 코드 저장소와 커스터마이징 설정을 OCI로 이전하는 마이그레이션 서비스도 지원하므로, 복잡한 현대화 과정을 안정적으로 수행하고자 하는 기업에게 실질적인 대안이 될 것입니다.

PayTo 결제 수락하기 (새 탭에서 열림)

글로벌 시장에서 현지 구매자가 선호하는 실시간 결제 수단을 제공하는 것은 장바구니 이탈을 방지하고 전환율을 높이는 핵심적인 전략입니다. 신용카드 대비 낮은 수수료의 결제 방식을 도입함으로써 비용 절감이 가능하며, 단 한 번의 통합만으로 전 세계 100개 이상의 결제 수단에 접근할 수 있는 확장성을 확보할 수 있습니다. 특히 추가적인 엔지니어링 작업 없이도 새로운 결제 수단을 즉시 출시할 수 있다는 점이 기술적 강점입니다. **결제 수단 다양화의 비즈니스 가치** * **전환율 극대화:** 지역별 고객이 가장 선호하고 신뢰하는 결제 수단을 제공하여 결제 단계에서의 이탈을 최소화합니다. * **거래 비용 절감:** 신용카드 거래 시 발생하는 높은 수수료 부담을 줄여 비즈니스의 수익성을 개선할 수 있습니다. * **글로벌 시장 진입 장벽 완화:** 전 세계적으로 사용되는 100가지 이상의 결제 수단을 지원함으로써 새로운 국가로의 확장이 용이합니다. **효율적인 기술 통합 방식** * **단일 인터페이스 활용:** 'Payment Element' 또는 'Checkout' 기능을 사용하면 복잡한 연동 과정 없이 단 한 번의 통합으로 충분합니다. * **엔지니어링 리소스 최적화:** 새로운 결제 수단을 추가할 때마다 별도의 개발 작업을 수행할 필요가 없어 유지보수 효율이 매우 높습니다. **전 세계 결제 점유율 및 현황** * **결제 수단별 분포:** 신용카드가 48%로 가장 높은 비중을 차지하고 있으나, 디지털 지갑(29%)의 영향력이 매우 크며 뱅크 데빗(5%), BNPL(5%) 등이 그 뒤를 잇고 있습니다. * **주요 결제 서비스:** Visa, Mastercard와 같은 전통적 수단뿐만 아니라 PayPal, Apple Pay, Google Pay 등 지갑 서비스와 Klarna(BNPL), SEPA(유럽 계좌 이체) 등이 전 세계적으로 널리 사용됩니다. * **고객 인프라:** 타겟 고객의 94%가 은행 계좌를 보유하고 있는 높은 금융 접근성을 보이지만, 선호하는 결제 방식은 지역마다 상이하므로 이에 맞춘 전략적 배치가 필요합니다. 성공적인 글로벌 비즈니스를 위해서는 단순히 카드 결제를 지원하는 것에 그치지 않고, 통합 결제 솔루션을 활용해 현지화된 결제 경험을 엔지니어링 공수 없이 신속하게 구축하는 것이 권장됩니다.

단일 노드에서 멀티 GPU (새 탭에서 열림)

Discord는 수억 명의 사용자를 지원하기 위해 머신러닝 시스템을 고도화하는 과정에서 단일 머신으로는 감당할 수 없는 확장성 한계에 직면했습니다. 이를 해결하기 위해 오픈소스 분산 컴퓨팅 프레임워크인 Ray를 도입하고, 개발자 경험(DX)에 최적화된 맞춤형 오케스트레이션 플랫폼을 성공적으로 구축했습니다. 결과적으로 분산 학습의 복잡성을 낮춤으로써 광고 랭킹 모델의 비즈니스 지표를 200% 이상 향상시키는 등의 기술적 도약을 이뤄냈습니다. ### 머신러닝 확장의 한계와 분산 컴퓨팅의 필요성 * 모델이 정교해지고 데이터셋이 거대해짐에 따라 단일 GPU나 개별 장비로는 학습을 진행할 수 없는 병목 현상이 발생했습니다. * 인프라의 성장 속도보다 계산 리소스에 대한 요구치가 더 빠르게 증가하면서, 단순한 자원 추가를 넘어선 근본적인 분산 컴퓨팅 환경으로의 전환이 필수적이었습니다. ### Ray 기반의 맞춤형 ML 플랫폼 구축 * 분산 컴퓨팅 프레임워크인 Ray를 핵심 기반으로 삼아, 개발자가 복잡한 분산 환경을 의식하지 않고 작업할 수 있는 플랫폼을 개발했습니다. * 워크플로우 관리를 위해 Dagster와 KubeRay를 결합한 오케스트레이션 시스템을 구축하였으며, 자체 CLI 도구를 제공하여 개발 편의성을 극대화했습니다. * 시스템의 투명성을 높이기 위해 'X-Ray'라는 별도의 가시성(Observability) 레이어를 도입하여 모니터링 환경을 강화했습니다. ### 플랫폼 고도화가 가져온 비즈니스 성과 * 딥러닝 도입 초기 단계의 혼란을 극복하고, 실험 중심에서 체계적인 프로덕션 오케스트레이션 단계로 진화했습니다. * 구축된 플랫폼을 통해 광고 랭킹(Ads Ranking) 모델 등을 최적화한 결과, 비즈니스 지표에서 200% 이상의 성능 개선을 달성하며 분산 ML 플랫폼의 실효성을 입증했습니다. 성공적인 머신러닝 확장을 위해서는 분산 컴퓨팅의 기술적 도입만큼이나 개발자가 이를 쉽게 활용할 수 있도록 돕는 플랫폼 아키텍처와 도구(CLI, 오케스트레이션, 모니터링)의 통합이 필수적입니다. 단순히 강력한 인프라를 구축하는 것을 넘어, 분산 학습 환경을 표준화하고 자동화하여 개발자의 생산성을 높이는 데 집중해야 합니다.

GitLab Credits를 소개합니다 (새 탭에서 열림)

GitLab은 에이전트 기반 AI의 특성에 맞춰 기존의 사용자당 과금(Seat-based) 방식에서 벗어난 'GitLab Credits'라는 사용량 기반 과금 모델을 도입했습니다. 이는 AI 에이전트가 개별 사용자의 직접 호출뿐만 아니라 백그라운드 이벤트에 의해 자동 실행되는 환경에서 비용 효율성과 유연성을 극대화하기 위한 조치입니다. 이를 통해 기업 내 모든 구성원은 별도의 AI 시트를 구매하지 않고도 조직 내 공유된 크레딧을 사용하여 에이전틱 AI 기능을 자유롭게 활용할 수 있게 되었습니다. **사용자 중심에서 사용량 중심으로의 전환 배경** * 기존의 시트 기반 과금은 AI를 가끔 사용하는 팀원에게도 동일한 비용을 부과하여 팀 내 AI 도입의 격차를 유발하는 한계가 있었습니다. * GitLab Duo Agent Platform은 사용자가 직접 명령하는 채팅뿐만 아니라 소프트웨어 개발 생명주기(SDLC) 과정에서 발생하는 이벤트에 의해 자동 실행되는 '에이전틱 워크플로우'를 포함하므로 개별 시트 단위의 과금이 부적합합니다. * GitLab Credits는 조직 전체가 크레딧을 풀(Pool) 형태로 공유하고 실제 사용량에 따라 차감하는 방식을 채택하여 전사적 AI 활용도를 높이고 총소유비용(TCO)을 절감합니다. **GitLab Credits의 작동 방식 및 적용 범위** * 보안 분석가, 플래너, CI/CD 파이프라인 수정과 같은 기본 에이전트와 Anthropic Claude Code, OpenAI Codex 등의 외부 에이전트 사용 시 크레딧이 소모됩니다. * 사용자가 GitLab AI 카탈로그를 통해 직접 구축한 커스텀 에이전트 및 워크플로우 사용 시에도 동일한 크레딧 시스템이 적용됩니다. * 대규모 언어 모델(LLM)에 대한 요청 횟수를 기준으로 크레딧이 차감되며, 1크레딧의 온디맨드 가격은 1달러로 설정되어 투명한 비용 산정이 가능합니다. * 사용량은 매달 말에 정산되며, 연간 약정 고객에게는 사용량에 따른 볼륨 할인이 제공됩니다. **비용 거버넌스 및 관리 도구** * 대시보드를 통해 재무 담당자는 비용을 관리하고, 관리자는 운영 관점에서 사용량 통계 및 역사적 추이를 상세히 모니터링할 수 있습니다. * 특정 프로젝트나 팀별로 에이전트 접근 권한을 설정하거나 사용자 수준에서 크레딧 소모를 제어하는 기능을 통해 예기치 못한 비용 발생을 방지합니다. * 크레딧 사용량이 약정된 수량의 50%, 80%, 100%에 도달할 때마다 자동 이메일 알림을 발송하여 선제적인 비용 관리를 돕습니다. **기존 고객을 위한 혜택 및 전환 정책** * 한정 기간 프로모션으로 Premium 구독자는 인당 12달러, Ultimate 구독자는 인당 24달러 상당의 무료 크레딧을 매달 자동으로 제공받습니다. * 기존에 시트 기반의 Duo Pro 또는 Enterprise를 사용하던 고객은 남은 계약 금액을 GitLab Credits로 전환하여 전사적인 공유 모델로 업그레이드할 수 있습니다. * 모든 기능은 GitLab 18.8 버전부터 적용되며, 자체 관리형(Self-Managed) 및 전용(Dedicated) 고객도 해당 버전 업그레이드 후 사용 가능합니다. 에이전틱 AI를 전사적으로 도입하려는 기업은 기존의 경직된 라이선스 모델 대신 GitLab Credits를 통해 초기 비용 부담 없이 도입을 시작할 수 있습니다. 특히 Ultimate 구독자는 기본 제공되는 프로모션 크레딧을 활용해 보안 분석이나 파이프라인 자동화 에이전트의 효용성을 먼저 검증해 본 뒤, 실제 데이터에 기반하여 약정 규모를 결정하는 방식을 추천합니다.

GitLab 패키지 리포지토리 메타데이터 서명에 사용되는 GPG 키가 연장되었습니다. (새 탭에서 열림)

GitLab은 패키지 저장소 메타데이터의 무결성을 보장하기 위해 사용되는 GPG 키의 만료일을 기존 2026년 2월 27일에서 2028년 2월 6일로 연장했습니다. 이번 조치는 보안 정책을 준수하면서도 키 교체에 따른 사용자 혼란을 최소화하기 위해 키 자체를 새로 발급하는 대신 유효 기간만 늘리는 방식을 채택했습니다. 2026년 2월 17일 이전에 GitLab 저장소를 설정한 기존 사용자들은 패키지 설치 시 오류를 방지하기 위해 반드시 신규 키를 갱신해야 합니다. **GPG 키 연장 배경과 목적** * GitLab은 배포되는 공식 패키지(Omnibus, GitLab Runner)의 무결성을 검증하기 위해 apt 및 yum 저장소 메타데이터에 GPG 서명을 적용하고 있습니다. * 키가 탈취되었을 경우의 노출 범위를 제한하고 보안 정책을 준수하기 위해 만료 기간을 정기적으로 갱신합니다. * 키를 완전히 새로 교체(Rotation)할 경우 모든 사용자가 신뢰 키를 수동으로 교체해야 하는 번거로움이 발생하므로, 기존 키의 만료일을 연장하여 사용자 중단을 최소화했습니다. **대상 사용자 및 기술적 세부 사항** * 대상 키 지문(Fingerprint): `F640 3F65 44A3 8863 DAA0 B6E0 3F01 618A 5131 2F3F` * 2026년 2월 17일 이전에 로컬 장비에 GitLab 저장소를 구성한 기존 사용자는 새로운 만료일이 반영된 키를 다시 가져와 등록해야 합니다. * 해당 날짜 이후에 처음으로 설치를 진행하는 신규 사용자는 공식 가이드를 따르면 별도의 추가 작업 없이 연장된 키가 적용됩니다. **공개 키 갱신 방법** * GitLab 공식 패키지 서버(`https://packages.gitlab.com/gpg.key`)에서 최신 공개 키를 직접 다운로드하여 시스템에 추가할 수 있습니다. * GPG 키 서버에서 `packages@gitlab.com` 이메일이나 위의 키 지문을 검색하여 공개 키 사본을 갱신하는 것도 가능합니다. * 보다 구체적인 저장소 메타데이터 서명 검증 방법은 GitLab의 Omnibus 공식 문서 및 GitLab Runner 설치 문서를 통해 확인할 수 있습니다. 기존 사용자들은 패키지 업데이트가 중단되지 않도록 만료일 이전에 반드시 키를 갱신하시기 바랍니다. 관련하여 기술적인 문제나 도움이 필요한 경우 GitLab의 omnibus-gitlab 이슈 트래커를 통해 문의할 수 있습니다.

GitLab 메트릭스 및 레지스트리 기능이 CI/CD 병목 현상을 줄이는 데 도움을 줍니다. (새 탭에서 열림)

GitLab이 새롭게 선보이는 CI/CD 작업 성능 메트릭과 컨테이너 가상 레지스트리 기능은 개발 및 운영 팀이 직면한 인프라 복잡성과 파이프라인 병목 현상을 직접 해결하는 데 중점을 둡니다. 별도의 타사 도구 없이도 GitLab 내부에서 작업별 성능 데이터를 분석하고 여러 외부 소스의 컨테이너 이미지를 통합 관리 및 캐싱함으로써, 전체적인 개발 워크플로우의 속도와 안정성을 동시에 개선할 수 있습니다. ## CI/CD 작업 성능 메트릭을 통한 병목 지점 시각화 그동안 파이프라인의 성능 저하나 실패 원인을 파악하기 위해 별도의 대시보드를 구축하거나 로그를 수동으로 분석해야 했던 번거로움이 해결되었습니다. * **성능 지표 제공**: 각 작업(Job)별로 중앙값(P50) 및 최악의 케이스(P95) 실행 시간을 제공하여, 평상시 속도와 비정상적으로 느려진 시점을 명확히 구분할 수 있습니다. * **실패율 추적**: 특정 작업의 실패 빈도를 파악하여 불안정한(flaky) 작업을 식별하고 파이프라인의 신뢰도를 높일 수 있습니다. * **통합 분석 대시보드**: 프로젝트 수준의 CI/CD 분석 페이지에서 지난 30일간의 데이터를 기반으로 작업 이름, 단계(Stage)별 정렬 및 검색이 가능합니다. * **기술적 요구사항**: GitLab Premium 및 Ultimate 티어에서 사용 가능하며, 셀프 호스팅 환경의 경우 ClickHouse가 구성되어 있어야 합니다. 향후 빌드, 테스트, 배포 단계별 그룹화 기능이 추가될 예정입니다. ## 컨테이너 가상 레지스트리를 활용한 이미지 관리 최적화 Docker Hub, Harbor, Quay 등 여러 레지스트리에 흩어져 있는 이미지를 개별적으로 관리하며 발생하는 인증 및 대역폭 비용 문제를 단일 엔드포인트를 통해 해결합니다. * **단일 엔드포인트 통합**: 여러 업스트림 레지스트리를 하나의 GitLab 가상 레지스트리 주소로 통합하여, 파이프라인 설정에서 번거로운 개별 인증 과정을 줄일 수 있습니다. * **풀스루 캐싱(Pull-through Caching)**: 첫 번째 호출 이후 이미지를 GitLab 내부에 캐싱하여 외부 네트워크 대역폭 비용을 절감하고 이미지 풀 속도를 향상합니다. * **지원 범위**: 현재 Docker Hub, Harbor, Quay 등 장기 토큰 인증을 사용하는 레지스트리를 지원하며, 향후 AWS ECR이나 Google Artifact Registry 같은 클라우드 기반 레지스트리로 확장될 계획입니다. * **운영 방식**: GitLab 18.9 버전부터 API를 통해 설정 가능하며, SaaS 사용자는 기능 플래그 활성화를 통해 베타 버전에 참여할 수 있습니다. 성능 저하로 고민하는 플랫폼 팀이라면 이번 베타 기능을 통해 파이프라인의 병목 구간을 우선적으로 점검해 보길 권장합니다. 특히 여러 외부 레지스트리를 혼용하는 환경에서는 가상 레지스트리를 도입함으로써 관리 포인트를 일원화하고 대역폭 비용을 효과적으로 줄일 수 있습니다. 해당 기능들은 커뮤니티 피드백을 바탕으로 개선되고 있으므로, 실제 도입 후 개선 제안을 공유하는 것도 좋은 방법입니다.

깃랩, 옴니버스 패 (새 탭에서 열림)

GitLab은 Omnibus 패키지의 무결성을 보장하기 위해 사용하는 GPG 서명 키의 만료일을 기존 2026년 2월 14일에서 2028년 2월 16일로 연장했습니다. 이번 조치는 보안 정책을 준수함과 동시에 새로운 키로 교체할 때 발생하는 사용자의 작업 부담을 최소화하기 위한 결정입니다. 패키지 서명을 직접 검증하는 환경의 사용자들은 보안 신뢰를 유지하기 위해 시스템의 공개 키 정보를 갱신해야 합니다. **Omnibus 패키지 서명 키의 역할과 특징** * GitLab은 CI 파이프라인에서 생성된 모든 Omnibus 패키지가 변조되지 않았음을 증명하기 위해 GNU Privacy Guard(GPG) 키를 사용하여 서명합니다. * 이 키는 OS 패키지 매니저(apt, yum 등)에서 사용하는 저장소 메타데이터 서명 키나 GitLab Runner용 GPG 키와는 별개로 관리되는 독립적인 키입니다. * GitLab 보안 정책에 따라 키 탈취 시의 피해를 제한하기 위해 주기적으로 만료일을 관리하며, 이번에 유효 기간을 2028년까지로 늘렸습니다. **키 교체 대신 만료일을 연장한 이유** * 새로운 키를 생성하여 교체(Rotation)하는 방식은 모든 사용자가 기존에 신뢰하던 키를 삭제하고 새 키를 다시 등록해야 하는 번거로움을 유발합니다. * 사용자 환경의 혼란과 서비스 중단 가능성을 줄이기 위해, 기존 키의 정체성은 유지하면서 만료 기한만 연장하는 방식을 선택했습니다. **사용자 조치 사항 및 업데이트 방법** * GitLab Omnibus 패키지의 서명을 수동으로 검증하거나, 패키지 매니저가 서명을 강제로 검증하도록 설정한 경우에만 최신 키로 업데이트하면 됩니다. * 별도의 서명 검증 설정을 하지 않고 기본 패키지 매니저 설정을 사용하는 일반적인 경우에는 추가 조치 없이도 패키지 설치 및 업데이트가 가능합니다. * 키 갱신이 필요한 경우, GPG 키 서버에서 이메일(`[email protected]`) 또는 키 ID(`98BF DB87 FCF1 0076 416C 1E0B AD99 7ACC 82DD 593D`)를 검색하여 최신 공개 키를 가져올 수 있습니다. * 또한, GitLab 공식 패키지 저장소(packages.gitlab.com)에서 제공하는 직접 링크를 통해 GPG 공개 키 파일을 다운로드하여 적용할 수도 있습니다. 서명 검증 과정에서 문제가 발생하거나 상세한 기술적 도움이 필요한 경우 GitLab의 'omnibus-gitlab' 이슈 트래커를 통해 문의할 수 있습니다. 보안상의 안전을 위해 패키지 서명을 검증하는 환경이라면 만료일이 도래하기 전 미리 공개 키를 갱신하는 것을 권장합니다.

Go 1.18의 프로 (새 탭에서 열림)

Cilium configuration for Kubernetes operations at scale

깃랩 컨테이너 스 (새 탭에서 열림)

GitLab은 컨테이너 라이프사이클 전반에서 발생할 수 있는 보안 위협에 대응하기 위해 파이프라인 기반 스캐닝부터 레지스트리 모니터링까지 다섯 가지 핵심 스캐닝 방식을 제공합니다. 이를 통해 개발자는 취약점을 조기에 발견하는 '시프트 레프트(Shift-left)' 보안을 실현하고, 프로덕션 환경에 배포된 이미지의 안전성을 지속적으로 확보할 수 있습니다. 결과적으로 GitLab의 컨테이너 스캐닝은 단순한 도구를 넘어 소프트웨어 구성 분석(SCA)의 필수 요소로서 통합적인 보안 관리 워크플로우를 구축하도록 돕습니다. ### 파이프라인 기반 컨테이너 스캐닝 * **기능 및 목적**: CI/CD 파이프라인 실행 단계에서 컨테이너 이미지를 검사하여 취약점이 포함된 이미지가 배포되는 것을 사전에 차단합니다. * **기술적 특징**: 오픈 소스 보안 스캐너인 Trivy를 활용하며, Free부터 Ultimate 티어까지 폭넓게 사용할 수 있습니다. * **설정 방법**: 프로젝트의 보안 구성 메뉴에서 머지 요청(MR)을 통해 자동 설정하거나, `.gitlab-ci.yml` 파일에 `Jobs/Container-Scanning.gitlab-ci.yml` 템플릿을 직접 추가하여 활성화합니다. * **사용자 정의**: `CS_IMAGE` 변수를 통해 특정 이미지를 지정하거나, `CS_SEVERITY_THRESHOLD` 변수를 사용해 'High' 또는 'Critical' 등 특정 수준 이상의 취약점만 필터링하여 리포팅하도록 설정할 수 있습니다. ### 취약점 가시성 및 관리 통합 * **머지 요청(MR) 위젯**: 스캔 결과가 MR 페이지 내 보안 위젯에 즉시 노출되어, 개발자가 코드를 병합하기 전에 영향받는 패키지와 해결 가이드를 확인할 수 있습니다. * **중앙 집중식 취약점 보고서**: 보안 팀은 'Vulnerability Report'를 통해 프로젝트 전체의 취약점을 통합 관리하며, 상태 관리(탐지됨, 확인됨, 해결됨 등) 및 담당자 할당이 가능합니다. * **의존성 목록(SBOM)**: 컨테이너 내부의 모든 운영체제 패키지와 애플리케이션 라이브러리를 카탈로그화하여 제공합니다. 이를 통해 소프트웨어 자재 명세서(SBOM)를 관리하고 공급망 보안을 강화할 수 있습니다. ### 레지스트리용 컨테이너 스캐닝 * **자동 모니터링**: GitLab 컨테이너 레지스트리에 푸시된 `latest` 태그 이미지를 대상으로 보안 정책 봇이 자동 스캔을 트리거합니다. * **지속적 취약점 탐지**: Ultimate 티어에서 제공되는 이 기능은 수동 파이프라인 실행 없이도 최신 취약점 데이터베이스(Advisories)를 바탕으로 이미지를 지속적으로 감시합니다. * **활성화 조건**: 프로젝트에 최소 하나 이상의 커밋이 있어야 하며, 컨테이너 레지스트리 알림 기능이 구성된 상태에서 '보안 구성' 메뉴의 토글 스위치를 통해 활성화할 수 있습니다. ### 성공적인 컨테이너 보안을 위한 제언 효과적인 보안 운영을 위해 먼저 **파이프라인 기반 스캐닝**을 도입하여 개발 초기 단계에서 취약점을 걸러내는 환경을 조성하는 것이 중요합니다. 이후 서비스 규모가 커지면 **레지스트리용 스캐닝**을 병행하여 배포된 이후에 새롭게 발견되는 제로데이 취약점 등에 실시간으로 대응하는 다층 방어 전략을 권장합니다.

Datadog의 3세대 이벤트 (새 탭에서 열림)

Monitor Lustre with Datadog

GitLab, 서비스 크레딧으로 (새 탭에서 열림)

GitLab이 GitLab.com 및 GitLab Dedicated를 사용하는 Ultimate 요금제 고객을 대상으로 99.9% 가용성 보장 및 서비스 수준 계약(SLA) 미달 시 서비스 크레딧을 제공하는 정책을 발표했습니다. 이번 정책은 미션 크리티컬한 DevSecOps 워크플로우의 안정성을 보장하고 플랫폼 신뢰도에 대한 책임을 강화하기 위해 도입되었습니다. 가용성이 기준치 아래로 떨어질 경우, 고객은 향후 인보이스에서 차감 가능한 크레딧을 청구하여 비즈니스 연속성을 지원받을 수 있습니다. **신뢰 기반의 가용성 보장과 서비스 크레딧** * 현대적인 소프트웨어 개발 환경에서는 코드 푸시, 병합 요청(MR), 이슈 트래킹이 실시간으로 발생하므로 플랫폼의 가동 중단은 전체 워크플로우의 정지로 이어집니다. * GitLab은 99.9% 가용성 SLA를 통해 고객의 개발 속도가 인프라 문제로 저해되지 않도록 보장하며, 서비스 크레딧 제도를 통해 플랫폼 신뢰도에 대한 금전적 책임을 명시했습니다. * 이는 단순한 가용성 수치 달성을 넘어 고객의 비즈니스 성과와 GitLab의 성공을 일치시키려는 전략적 의도를 담고 있습니다. **SLA 적용 대상 및 핵심 서비스 범위** * DevSecOps 워크플로우의 핵심인 이슈 관리와 병합 요청(Merge Requests) 기능이 포함됩니다. * HTTPS 및 SSH를 통한 Git 작업(push, pull, clone)과 컨테이너 및 패키지 레지스트리 운영이 보호 대상입니다. * 위 항목들과 관련된 API 요청 또한 SLA 범위에 포함되며, 구체적인 제외 항목은 GitLab 핸드북을 통해 투명하게 공개됩니다. **가동 중단(Downtime)의 기술적 정의와 측정 방식** * 전 세계 여러 지리적 위치에서 자동화된 모니터링 도구를 사용하여 실제 고객이 체감하는 가용성을 정밀하게 측정합니다. * 특정 '분' 단위 시간 동안 유효한 고객 요청의 5% 이상이 서버 오류(HTTP 5xx status codes) 또는 30초 이상의 연결 시간 초과를 발생시킬 경우 이를 '가동 중단 분'으로 정의합니다. * 서버측 실패 외에도 기능 사용을 불가능하게 만드는 애플리케이션 버그나 성능 저하 이슈에 대해서는 자동 모니터링 결과와 별개로 고객의 청구를 종합적으로 검토하여 반영합니다. **서비스 크레딧 청구 및 처리 절차** * 가동 중단이 발생한 달이 종료된 후 30일 이내에 GitLab 지원 센터(support.gitlab.com)를 통해 크레딧 청구를 제출해야 합니다. * GitLab 기술 팀은 제출된 청구 내용을 검토하고 내부 모니터링 데이터를 바탕으로 가동 중단 시간을 검증합니다. * 승인된 서비스 크레딧은 고객의 다음번 발행 인보이스에 적용되어 비용을 절감해 줍니다. GitLab Ultimate 사용 기업은 이번 SLA 정책을 통해 더욱 안정적인 개발 환경을 구축할 수 있게 되었습니다. 플랫폼 장애 발생 시 비즈니스 피해를 최소화하기 위해, 장애 발생 시점의 로그를 기록해두고 월 종료 후 30일 이내에 잊지 말고 크레딧을 청구하여 비용 효율성을 극대화하시기 바랍니다.

익일 결제 (새 탭에서 열림)

Stripe의 '익일 정산(Next-day settlement)'은 국내 거래 대금을 영업일 기준 단 하루 만에 정산받을 수 있도록 지원하여 비즈니스의 자금 회전율을 극대화하는 서비스입니다. 미국 내 Stripe 사용자들을 대상으로 하며, 자동 또는 수동 출금 일정에 관계없이 표준 정산보다 훨씬 빠른 자금 접근성을 제공합니다. 이를 통해 기업은 매출 발생 직후 신속하게 운영 자금을 확보하고 유연하게 재무 계획을 세울 수 있습니다. **익일 정산의 작동 방식 및 일정** * ACH 직불 결제를 제외한 모든 국내 거래 대금은 발생 후 영업일 기준 1일 이내에 Stripe 잔고로 입금됩니다. * 자동 일일 출금을 설정한 경우, Stripe는 해당 자금을 익일에 은행 계좌로 전송합니다. 예를 들어 월요일에 발생한 거래는 일반적으로 화요일에 은행 계좌에 입금됩니다. * 단, 개별 은행의 처리 속도에 따라 실제 입금 시점에는 다소 차이가 있을 수 있습니다. **사용 가능 범위 및 제약 사항** * 현재 이 서비스는 미국 내 Stripe 대시보드 사용자에게만 제공되며, 플랫폼 사용자의 경우 별도의 문의가 필요합니다. * 미국 은행 시스템의 한계로 인해, 자동 출금 금액이 100만 달러(USD)를 초과할 경우 정산에 하루가 더 소요될 수 있습니다. * 신규 Stripe 사용자는 즉시 이용이 불가능할 수 있으므로, 대시보드의 출금 설정 메뉴에서 활성화 가능 여부를 확인해야 합니다. **비용 구조 및 설정 관리** * 익일 정산 이용 시 전월에 가속 정산된 거래 총액의 0.6%가 월간 수수료로 부과됩니다. * 해당 수수료는 매월 초 사용자의 사용 가능한 Stripe 잔고에서 자동으로 차감됩니다. * 사용자는 필요에 따라 대시보드 설정에서 익일 정산과 표준 정산 속도를 자유롭게 전환할 수 있습니다. **자금 접근성 향상을 위한 선택지** 가장 빠른 자금 확보를 원하는 경우 익일 정산과 '즉시 출금(Instant Payouts)' 기능을 필요에 따라 병행하여 사용할 수 있습니다. 비즈니스의 규모와 자금 수요에 맞춰 정산 속도를 최적화함으로써 보다 효율적인 현금 흐름 관리가 가능합니다.

에이전트를 활용한 (새 탭에서 열림)

Streamlining Security Investigations with Agents

Git 2.53.0 (새 탭에서 열림)

Git 2.53.0 버전은 대규모 저장소 관리 효율성을 높이고 데이터 무결성을 강화하는 데 초점을 맞춘 업데이트를 선보였습니다. 이번 릴리스의 핵심은 부분 클론(Partial Clone) 환경에서의 기하급수적 재패킹 지원과 히스토리 재작성 시 유효한 서명을 선별적으로 보존하는 기능의 도입입니다. 이를 통해 개발자와 운영자는 대규모 프로젝트를 관리할 때 성능 최적화와 보안 신뢰성을 동시에 확보할 수 있게 되었습니다. ## 부분 클론 환경의 기하급수적 재패킹(Geometric Repacking) 지원 * 전통적인 'all-into-one' 재패킹 방식은 모든 객체를 하나의 패크파일로 합쳐 조회 성능은 좋지만, 대규모 저장소에서는 작업 시간이 지나치게 길어지는 단점이 있습니다. * 이를 보완하는 '기하급수적 전략'은 패크파일들의 크기를 일정 비율(두 배 이상)로 유지하며 필요한 부분만 결합하지만, 그동안 부분 클론 환경의 '프로미서(promisor)' 패크파일을 제대로 처리하지 못하는 기술적 한계가 있었습니다. * Git 2.53에서는 기하급수적 재패킹 시 프로미서 패크파일을 별도로 구분하여 관리하도록 개선되었습니다. 이를 통해 부분 클론을 사용하는 저장소에서도 데이터 손상 위험 없이 효율적인 객체 관리가 가능해졌습니다. ## 유효한 커밋 서명만 보존하는 git-fast-import 개선 * 저장소 히스토리를 대량으로 재작성하는 `git-fast-import` 명령어에 `--signed-commits` 옵션의 새로운 모드인 `strip-if-invalid`가 추가되었습니다. * 기존에는 히스토리를 재작성할 때 서명을 일괄 삭제하거나 무효한 서명을 그대로 남겨둬야 했으나, 이제는 재작성으로 인해 내용이 바뀐 커밋의 서명만 골라 삭제할 수 있습니다. * 이 기능 덕분에 히스토리 재작성 과정에서 변경되지 않은 객체들의 유효한 서명은 안전하게 보존할 수 있어, 데이터의 무결성을 유지하는 데 큰 도움이 됩니다. ## 저장소 구조 분석 도구(git-repo-structure)의 데이터 수집 강화 * 저장소의 성능 특성을 파악하기 위해 도입된 `git repo structure` 명령어가 이제 도달 가능한 객체들의 상세 크기 정보를 제공합니다. * 커밋, 트리, 블롭, 태그 등 각 객체 유형별로 압축 해제 시 크기(Inflated size)와 실제 디스크 점유 크기(Disk size)를 모두 확인할 수 있습니다. * 이는 외부 도구 없이도 네이티브 명령어를 통해 대규모 저장소의 구조적 부하를 진단하고 하드웨어 자원 계획을 세우는 데 유용하게 활용됩니다. 대규모 저장소를 운영하거나 히스토리 정제 작업을 빈번하게 수행하는 팀이라면 이번 Git 2.53.0 업데이트를 적극 권장합니다. 특히 부분 클론을 활용한 CI/CD 환경에서 기하급수적 재패킹을 통해 성능을 최적화하고, 히스토리 수정 시에도 유효한 서명을 유지함으로써 보안 수준을 한 단계 높일 수 있습니다.