techlist.io
KREN

Techlist.io - 한국 테크 블로그 큐레이터

cloudflare4분 읽기큐레이션 요약

Cloudflare CASB를 통한 Claude Compliance API 지원 발표

Cloudflare가 Claude Compliance API를 CASB에 통합해, 보안·컴플라이언스 팀이 엔드포인트 에이전트 없이 Claude 사용 현황과 민감정보 노출을 Cloudflare 대시보드에서 모니터링할 수 있게 했다. 이를 통해 Claude의 프로젝트, 파일, 대화, 생성 문서에서 발생하는 보안 문제를 탐지하고, 기존 SaaS 보안 워크플로와 Cloudflare Gateway 정책을 이용해 차단·제한까지 연결할 수 있다. 핵심은 AI 애플리케이션의 사용 데이터를 단순히 차단하는 데서 나아가, 데이터 생성·처리·저장 전 과정을 관리하는 것이다. ## AI 도입에 따른 새로운 보안 과제 - 기존 SaaS와 달리 AI 서비스에서는 사용자가: - 고객 개인정보나 기밀자료를 프롬프트에 입력할 수 있다. - API 키를 실수로 공유하고 장기간 교체하지 않을 수 있다. - 민감정보가 포함된 응답이나 문서를 생성할 수 있다. - 네트워크 계층에서 승인되지 않은 AI 서비스 사용을 차단하는 것만으로는 승인된 서비스 내부의 활동을 파악할 수 없다. - AI 애플리케이션은 데이터를 읽는 것뿐 아니라 생성하고, 여러 시스템과 연결하며, 에이전트나 API를 통해 업무를 수행한다. - 따라서 보안은 API 호출, 데이터 처리, 저장 데이터까지 전체 라이프사이클을 다뤄야 한다. ## Cloudflare의 AI 보안 구성 - **Cloudflare AI Gateway** - 애플리케이션과 Anthropic 같은 AI 제공업체 사이에 위치한다. - 요청, 토큰 사용량, 모델 성능을 관찰한다. - 속도 제한, 응답 캐싱, 세밀한 모델 라우팅을 지원한다. - **Cloudflare Gateway 및 DLP** - AI 트래픽을 검사한다. - 고객 개인정보나 기밀자료가 포함된 프롬프트가 모델에 전달되기 전에 차단할 수 있다. - **Cloudflare Access 및 MCP 서버 포털** - 에이전트가 기업 도구에 연결하는 경로를 보호된 단일 엔드포인트로 통합한다. - 사용자·에이전트별 접근 권한을 제어하고 모든 요청을 감사 로그로 남긴다. - **Cloudflare CASB** - Claude 내부에 저장된 데이터를 검사한다. - 잘못된 공유 설정과 민감정보를 탐지하며 엔드포인트 에이전트를 요구하지 않는다. - 각 기능은 Cloudflare 플랫폼 안에서 연동되므로 여러 보안 서비스나 클라우드 사이를 트래픽이 우회하는 ‘헤어핀’ 구조를 피할 수 있다. ## Claude Compliance API와 CASB 통합 - Claude Compliance API는 Claude 조직, 워크스페이스, 사용량에 관한 보안 관련 데이터를 프로그래밍 방식으로 제공한다. - Cloudflare CASB는 이 API를 사용해 인라인 트래픽 검사나 단말 에이전트 없이 Claude의 보안 문제를 탐지한다. - 탐지 결과는 다른 SaaS 애플리케이션의 보안 결과와 함께 Cloudflare 대시보드에 표시된다. - 결과는 카테고리별로 묶이고 심각도순으로 정렬된다. - 보안팀은 Microsoft 365, Google Workspace, Salesforce와 동일한 방식으로 이슈를 분류하고 담당자를 지정하며 해결할 수 있다. ## 탐지 가능한 Claude 자산과 위험 - **프로젝트** - 조직 전체 또는 특정 사용자·그룹에 공유된 프로젝트를 탐지한다. - **프로젝트 첨부파일** - DLP 정책을 위반하는 파일과 문서를 식별한다. - **채팅 파일** - 사용자가 업로드한 파일과 Claude가 생성한 파일을 검사한다. - **채팅 메시지** - 사용자의 프롬프트와 제공자의 응답에 포함된 민감정보를 탐지한다. - **Artifacts** - Claude가 생성한 문서와 파일의 DLP 정책 위반 여부를 확인한다. ## Claude Enterprise와 Claude Platform 지원 범위 - Claude Enterprise에서는 다음 정보를 확인할 수 있다. - 조직 - 프로젝트 - 채팅 - 역할 - 대화 메시지 - 업로드된 파일 - 대화와 파일은 전용 읽기 전용 엔드포인트를 통해 조회해 데이터 손실 위험을 줄인다. - Claude Platform에서는 다음 이벤트를 계속 제공한다. - 멤버 및 워크스페이스 변경 - API 키 생성 - 파일 생성 및 다운로드 - Activity Feed 지원도 향후 추가될 예정이다. ## 탐지에서 정책 시행까지 - CASB가 민감정보가 포함된 파일 업로드 같은 문제를 발견하면, 해당 결과를 Cloudflare Gateway 정책으로 연결할 수 있다. - 보안팀은 다음과 같은 조치를 취할 수 있다. - 특정 사용자의 Claude 파일 업로드 차단 - Claude 애플리케이션 전체 접근 제한 - 문제가 해결될 때까지 특정 기능만 제한 - 이를 통해 CASB의 사후 가시성을 Gateway의 실시간 인라인 정책 집행으로 확장한다. ## 시작을 위한 조건 - Claude Enterprise 계정이 필요하다. - 조직에 대해 Claude의 Compliance API 접근 권한을 요청해야 한다. - 이후 Cloudflare CASB에서 해당 API 통합을 구성해 Claude 관련 보안 결과를 대시보드에서 확인하는 방식이다. 실무적으로는 Claude 사용을 일괄 차단하기보다, CASB로 민감정보와 과도한 공유를 먼저 식별한 뒤 사용자·그룹·기능별 Gateway 정책으로 단계적으로 제한하는 접근이 적합하다.

원문 읽기(새 탭에서 열림)
모델 컨텍스트 프로토콜data-loss-preventionanthropiccloudflare-ai-gateway+4
dropbox4분 읽기큐레이션 요약

Nova: 코딩 에이전트를 위한 사내 플랫폼을 소개합니다

코딩 에이전트는 코드 작성뿐 아니라 CI 장애 대응, 마이그레이션, 테스트 개선 등 소프트웨어 개발 전반의 반복 업무를 지원할 수 있다. Dropbox는 대규모 모노레포와 Bazel, 사내 인프라에 맞는 실행·검증 환경을 제공하기 위해 개별 도구 대신 클라우드 기반 플랫폼인 Nova를 구축했다. Nova는 대화형 세션과 비동기 자동화 작업을 하나의 인터페이스로 통합하고, 실제 빌드·테스트 결과를 바탕으로 에이전트가 반복적으로 수정하도록 설계됐다. ## 분산된 개발 업무를 통합하는 플랫폼 - 개발 과정에는 디버깅, 의존성 업데이트, 테스트 커버리지 개선, flaky test 수정처럼 반복적이지만 중요한 작업이 많다. - 작업에 따라 상호작용 방식이 다르다. - 개발자가 직접 대화하며 진행하는 대화형 세션 - 에이전트가 백그라운드에서 실행되고 의미 있는 결과만 전달하는 비동기 작업 - Dropbox의 대규모 모노레포는 Bazel의 캐시와 원격 실행, 온프레미스 인프라에 의존한다. - 일반적인 외부 코딩 에이전트는 로컬 개발에는 적합하지만 Dropbox의 저장소 구조와 빌드·검증 경로를 자연스럽게 지원하지 못한다. - 따라서 워크플로마다 별도 AI 도구를 만드는 대신, 실행·검증·컨텍스트 처리를 공통화한 플랫폼을 선택했다. ## Nova의 실행 및 검증 방식 - 각 Nova 세션은 특정 커밋 시점의 Dropbox 코드베이스 스냅샷을 기반으로 격리된 환경에서 실행된다. - 호출자는 다음 정보를 전달할 수 있다. - 기준 커밋 - 수행할 작업 - 작업 후 실행할 검증 명령 - 검증 실패 시 계속 진행할지 여부 - 최대 반복 횟수 - 결과를 게시할 브랜치 - 기본 흐름은 다음과 같다. - 에이전트가 변경 사항 제안 - Bazel 빌드·테스트 등 실제 검증 수행 - 실패 결과를 에이전트에 전달 - 에이전트가 원인을 분석하고 수정 - 정해진 반복 횟수까지 재검증 - 단순히 그럴듯한 패치를 생성하는 데 그치지 않고, 실제 Dropbox 개발 환경에서 변경 사항이 유효한지 확인한다. - 세션은 하나의 브랜치만 사용하고 코드 게시 작업은 에이전트 외부에서 처리한다. - 활성 브랜치와 게시 상태를 예측하기 쉽다. - 테스트 실행, 리베이스 등 후속 자동화를 단순하게 유지할 수 있다. - 여러 브랜치를 에이전트가 직접 관리할 때 발생하는 기준 브랜치 선택 문제를 피할 수 있다. ## 다양한 개발 인터페이스와 확장 기능 - Nova는 여러 코딩 에이전트를 동일한 인터페이스 뒤에서 사용할 수 있도록 확장됐다. - 제공 방식은 다음과 같다. - 웹 UI 기반 대화형 세션 - CLI - API - 로컬 에이전트, 스크립트, 사내 서비스에서 병렬 작업 실행 - 장기 실행 워크플로에 AI 단계를 추가할 수 있는 헬퍼를 제공한다. - 프롬프트 평가, 관측성, 피드백 수집 기능으로 에이전트 성능을 측정하고 개선할 수 있다. - 파일 수정 외에도 로그 수집, 장애 조사, 여러 단계에 걸친 컨텍스트 유지가 필요하므로 다음 확장 기능을 포함한다. - Skills - Plugins - MCP 통합 - 관측성 시스템 접근 ## CI 장애 대응에서 시작한 적용 - Nova는 CI 실패에 대한 수정 제안을 자동화하는 문제에서 출발했다. - 예시 요청은 특정 커밋에서 CI 실패를 조사하고, 관련 Bazel 테스트를 실행하며, 실패 시 최대 5회까지 수정·재검증하는 형태다. - 검증 명령을 호출자가 명시하므로 에이전트가 변경한 코드에 필요한 컴파일·테스트 범위를 구체적으로 지정할 수 있다. - 이 방식은 “변경 제안 → 실제 검증 → 실패 원인 반영”이라는 안정적인 자동화 패턴을 만든다. ## 개발자 주도 세션 - 엔지니어는 Nova 웹 UI에서 로컬 개발을 중단하지 않고 빠른 수정이나 프로토타입을 진행할 수 있다. - Bazel 선택성 도구와 검증 명령을 결합해 변경된 코드와 관련된 컴파일·테스트 대상만 검증할 수 있다. - Slack 대화에서 바로 Nova 세션을 시작하고 해당 스레드의 논의 내용을 컨텍스트로 전달할 수 있다. - 이를 통해 문제 설명이나 팀 내 논의를 에이전트 프롬프트에 수동으로 다시 작성하는 비용을 줄인다. ## Flaky test 자동 수정 - Nova의 대표적인 운영 자동화 사례는 flaky test remediation이다. - Dropbox의 flaky 테스트 탐지 시스템인 Athena와 내부 도구 Deflaker를 결합했다. - Deflaker의 흐름은 다음과 같다. - 테스트가 성공한 사례와 실패한 사례를 수집 - 관련 로그를 Nova에 컨텍스트로 전달 - 에이전트가 가능한 근본 원인을 분석 - 수정안을 제안 - 이는 단순 코드 생성보다 로그 분석, 증거 비교, 원인 추론이 중요한 장기 실행형 워크플로에 해당한다. ## 실용적인 시사점 코딩 에이전트를 도입할 때는 에디터 플러그인 하나를 추가하는 것보다 저장소, 빌드 시스템, 테스트 인프라, 로그와 컨텍스트를 연결하는 플랫폼 설계가 중요하다. 특히 에이전트의 결과를 실제 검증 명령으로 확인하고, 실패 결과를 다시 에이전트에 제공하는 반복 루프와 예측 가능한 브랜치·게시 정책을 갖추는 것이 안정적인 자동화의 핵심이다.

원문 읽기(새 탭에서 열림)
옵저버빌리티CI/CD모델 컨텍스트 프로토콜slack+4
kakao4분 읽기큐레이션 요약

메시징 서버의 스트레스 테스트 노하우와 AI 가 덜어 준 부분

메시징 서버의 안정적 운영을 위해서는 실서비스와 동일한 환경에서 상시 스트레스 테스트를 수행하고, 실제 트래픽 패턴과 최악의 시나리오를 재현해야 한다. 테스트는 단순히 서버가 장애 없이 버티는지를 보는 것이 아니라 RPS, 지연 시간, 오류율, 시스템 자원 등을 계층적으로 분석해 병목 원인을 찾아내는 과정이다. 관측성 도구, 프레임워크, OS·보안 시스템, 신규 기능 변경 전후에도 스트레스 테스트를 적용해야 운영 장애를 예방할 수 있다. ## 상시 스트레스 테스트 환경 구성 - 테스트 대상 서버는 실운영 서버와 동일한 JVM heap, CPU·메모리 한도, 네트워크 사양으로 구성한다. - 운영 서버 대수가 다르면 측정값을 그대로 비교하기 어렵기 때문에 필요한 경우 수치 보정을 적용한다. - 부하 생성에는 Locust를 사용하며, 클러스터 리소스에 따라 수백 개의 워커 파드까지 확장한다. - 부하 생성 클라이언트의 자원 부족이 서버 성능 측정에 영향을 주지 않도록 클라이언트 리소스를 충분히 확보한다. - 경우에 따라 `org.openjdk.jmh:jmh-core`를 이용해 프레임워크나 프로토콜 자체를 벤치마크한다. ## 실제 트래픽을 반영한 시나리오 설계 - 여러 사용자 동작을 실제 환경의 비율에 맞춰 조합한다. - 평시 정오에는 메시지 전송, 채팅방 입장, 채팅방 목록 조회, 메시지 조회가 비교적 고르게 분포한다. - 신년 자정에는 메시지 전송 비중이 52%에서 61%로 증가하고, 채팅방 목록 조회는 18%에서 8%로 감소한다. - 같은 RPS라도 READ·WRITE 프로토콜 비율에 따라 병목 지점과 최대 처리량이 달라질 수 있다. - 새로운 시나리오마다 부하 코드를 새로 작성하지 않고, 사용자 수·요청 비율·동시성 등 설정값을 조합해 다양한 트래픽을 재현한다. ## 변경 유형별 스트레스 테스트 ### 관측성과 로깅 인프라 추가 - Logstash, Fluent Bit, OpenTelemetry, Vector DB 등 관측성 컴포넌트가 애플리케이션 처리량과 응답 시간에 미치는 영향을 확인한다. - 메트릭 수집 때문에 애플리케이션 부하가 증가하거나 CPU·메모리·네트워크 사용량이 변하지 않는지 측정한다. - 높은 트래픽에서 내부 메트릭과 알림 시스템 자체가 지연되는지도 검증한다. ### 프로토콜·프레임워크 벤치마크와 포팅 - 비즈니스 로직을 제외하고 동일한 I/O 부하를 주어 프로토콜이나 프레임워크별 성능을 비교한다. - WebFlux, virtual thread 등 기술 선택을 추상적인 장점이 아니라 실제 RPS, latency, CPU 사용량으로 판단한다. - CPU 부하와 I/O 대기 시간을 단계적으로 늘려 현재 서비스가 CPU-bound인지 IO-bound인지 확인한다. - C++에서 Kotlin으로 메인 서버를 포팅할 때도 전후 시스템 지표를 비교하고, GC 튜닝 등을 통해 성능 차이를 줄였다. ### OS 변경과 보안 시스템 도입 - 온프레미스 호스트 OS 변경, 백신, 보안·모니터링 에이전트 추가가 고부하 상황에서 미치는 영향을 검증한다. - 평상시에는 드러나지 않던 slab 메모리 누수나 백신 동작 시 리소스 급증이 대규모 트래픽에서 문제가 될 수 있다. - 적용 전후 응답 시간과 처리량이 악화되지 않는지 확인한 뒤 인프라 변경을 진행한다. ### 메시징 도메인 특화 임계 상황 - 한 채팅방에서 여러 사용자가 동시에 메시지를 전송하는 상황을 재현한다. - 자정 메시지 burst, 수백 명 규모의 단체 채팅방 입장 등 최악의 시나리오를 별도로 검증한다. - 신규 기능도 부하 상황에서 예상되는 병목을 먼저 파악한 후 출시한다. ## 지표를 계층적으로 분석하는 방법 ### 엔드포인트 지표 - **RPS**: 워커 수를 점진적으로 늘려 포화 지점을 찾거나, 동일한 부하에서 RPS가 안정적으로 유지되는지 확인한다. - 예상보다 낮은 RPS에서 포화되거나 처리량이 급격히 흔들리면 내부 원인 분석으로 넘어간다. - **Latency**: - P50은 대부분 사용자의 일반적인 경험을 나타낸다. - P95·P99는 최악의 응답 시간과 내부 병목을 파악하는 데 유용하다. - P95·P99가 급증하면 처리량 한계나 대기열 문제를 의심한다. - P50 자체가 목표치나 실제 환경보다 높아도 비정상으로 판단한다. - **Error rate**: - 5xx는 서버 처리 한계에 도달했을 가능성이 있다. - timeout은 클라이언트 자원 부족이나 타임아웃 설정을 확인해야 한다. - 400 오류는 테스트 데이터나 비즈니스 시나리오가 잘못되었을 가능성이 있다. ### 시스템 자원 지표 - 본문은 시스템 자원 레이어 설명 중간에서 끝나지만, 엔드포인트 지표에서 이상이 발견되면 CPU·메모리·네트워크 등 하위 시스템 지표를 세부적으로 확인하는 방식으로 이어진다. - 스트레스 테스트 결과는 단순한 성공·실패가 아니라, 어느 계층에서 병목이 발생했는지 추적하는 디버깅 과정으로 해석해야 한다. 실무에서는 운영과 유사한 테스트 환경을 상시 유지하고, 평시 트래픽뿐 아니라 도메인 특유의 폭증 시나리오까지 자동화하는 것이 중요하다. 또한 변경 사항을 도입할 때 RPS, P50/P95/P99 latency, 오류율, 시스템 자원을 동일한 기준으로 비교해 정량적으로 판단하는 것이 권장된다.

원문 읽기(새 탭에서 열림)
옵저버빌리티Kotlinopen-telemetryperformance-testing+4
grammarly3분 읽기큐레이션 요약

예시와 함께 전문적으로 이메일을 확인했다고 회신하는 방법

이 글은 답변을 즉시 완성하기 어려울 때 먼저 보내는 짧은 수신 확인 메일이 침묵으로 인한 불안과 재촉을 줄이고 신뢰를 높인다고 설명합니다. 좋은 확인 메일은 받은 내용, 다음 단계, 답변 예정 시점을 구체적으로 밝히며, 상대방과 상황에 맞게 격식을 조절해야 합니다. 다만 바로 완전한 답변이 가능하거나 응답이 필요 없는 메시지라면 별도의 확인 메일은 생략해도 됩니다. ## 수신 확인 메일의 역할 - 메시지나 문서를 받았다는 사실을 짧게 알리는 메일입니다. - 전체 요청에 답하는 대신, 우선 수신 여부와 향후 진행을 전달하는 데 초점을 둡니다. - 답변이 며칠씩 지연되어 “답변이 늦어 죄송합니다”로 시작하는 상황을 예방합니다. - 상대방이 “잘 받았는지”, “언제 답을 받을 수 있는지” 추측하지 않도록 해 후속 확인 연락을 줄입니다. ## 효과적인 확인 메일의 구성 - **명확한 제목** - 기존 메일에 답장할 때는 원래 제목과 `Re:`를 유지합니다. - 새 메일이라면 `Receipt confirmation: Q3 budget proposal`처럼 용도를 분명히 적습니다. - **수신 사실 확인** - “확인했습니다”처럼 모호하게 쓰기보다 받은 문서, 요청, 주제를 구체적으로 언급합니다. - 예: “서명된 공급업체 계약서를 받았으며 오늘 오후에 검토하겠습니다.” - **다음 단계와 기한 제시** - 검토, 담당 부서 전달, 추가 질문 여부 등 다음 행동을 알립니다. - “금요일까지 피드백을 드리겠습니다”처럼 구체적인 시점을 제시하면 좋습니다. - **상황에 맞는 맺음말** - 공식적인 메일에는 “Best regards”, “Thank you”를 사용할 수 있습니다. - 내부의 짧은 답장에는 “Best”, “Thanks”처럼 간결한 표현이 적절합니다. ## 확인 메일을 보내야 하는 경우 - 문서, 제안서, 계약서, 청구서 또는 공식 요청을 받은 경우 - 마감이 임박했거나 시간에 민감한 요청을 받은 경우 - 신규 고객이나 외부 연락처와 처음 소통하는 경우 - 상대방이 내 답변을 받아야 다음 업무를 진행할 수 있는 경우 - 아직 완전한 답변은 어렵지만 메시지를 확인했다는 신호가 필요한 경우 ## 생략해도 되는 경우 - 즉시 전체 답변을 보낼 수 있는 경우 - 단순한 정보 공유나 중요도가 낮은 내부 메일인 경우 - 참조(CC)로만 포함되어 인지 여부를 알릴 필요가 없는 경우 - 모든 메시지에 자동으로 확인 메일을 보내면 불필요한 메일이 늘어날 수 있으므로, 응답 필요성을 기준으로 판단해야 합니다. ## 상황별 작성 방식 - **간단한 내부 확인** - “확인했습니다. 검토 후 [요일]까지 다시 말씀드리겠습니다. 감사합니다.” - **일반적인 업무 연락** - 받은 문서나 주제를 언급하고, 당일 검토 여부와 후속 연락 계획을 밝힙니다. - **공식 문서나 요청** - 문서명과 수신 날짜를 명시하고, 질문이나 검토 결과를 전달할 시점을 적습니다. - **입사 지원서 접수** - 지원 직무와 지원서 접수 사실을 확인한 뒤, 다음 절차를 안내할 기간을 제시합니다. - **고객 또는 고위험 사안** - 수신 사실뿐 아니라 관련 팀에 전달했는지, 언제까지 다음 단계나 질문을 안내할지를 분명히 해야 합니다. ## 피해야 할 실수 - “Got it, thanks”처럼 내용이 지나치게 모호한 표현만 사용하는 것 - 실제로 지키기 어려운 답변 기한을 약속하는 것 - 수신 확인 메일에서 아직 결정되지 않은 결과를 암시하는 것 - 고객이나 임원에게 지나치게 가벼운 어조를 사용하는 것 - 이미 전체 답변을 보냈는데 별도의 확인 메일을 추가해 메일을 불필요하게 늘리는 것 실무에서는 메시지를 받은 즉시 “무엇을 받았는지, 어떻게 처리할지, 언제 답할지”를 한두 문장으로 보내는 습관이 가장 유용합니다. 짧더라도 구체적인 확인 메일은 답변 지연에 대한 불확실성을 줄이고 업무 흐름을 안정적으로 유지해 줍니다.

원문 읽기(새 탭에서 열림)
grammarlyemail-communicationprofessional-writingbusiness-communication
discord2분 읽기큐레이션 요약

리그 & VAL에서 친구들과 연결하기가 그 어느 때보다 쉬워집니다!

Discord와 Riot Games의 계정 연동으로 League of Legends와 VALORANT에서 Discord 친구를 더 쉽게 찾고 초대할 수 있게 된다. 게임 내에서 Discord 친구의 플레이 여부와 상태를 확인하고, 파티 초대나 참가 링크를 바로 공유할 수 있어 친구 목록을 오가며 시간을 낭비할 필요가 줄어든다. 이 기능은 Riot과 Discord가 모두 지원되는 지역에서 제공된다. ## Discord와 Riot 계정 연동의 배경 - League of Legends와 VALORANT는 Discord에서 가장 많이 플레이되는 게임 중 하나다. - 기존에는 게임 클라이언트와 Discord 친구 목록을 번갈아 확인하며 빈자리를 채워야 했다. - 이번 통합은 게임 중단이나 별도 검색 없이 Discord 친구를 게임 파티로 연결하는 것을 목표로 한다. ## 게임 내 Discord 친구 확인 및 초대 Riot 계정과 Discord 계정을 연결하면 다음 기능을 사용할 수 있다. - 게임 내 친구 목록에서 어떤 Discord 친구가 League 또는 VALORANT를 플레이하는지 확인 - 게임 클라이언트에서 Discord 친구를 파티에 직접 초대 - 파티 참가 링크를 Discord 서버, DM 등 원하는 곳에 공유 - Discord에서 친구의 게임 상태 확인 - 현재 매치 진행 시간 - 파티 인원 - 게임 플레이 여부 - League of Legends에서는 친구 목록의 “Invite by Discord” 기능을 통해 Discord 친구를 초대할 수 있다. ## Riot 계정 연결 방법 Discord에서 다음 순서로 연결할 수 있다. - **사용자 설정(User Settings)** 열기 - **연결(Connections)** 메뉴 선택 - Riot Games 아이콘을 선택 - 목록에 보이지 않으면 “더 보기(View More)”를 선택 - 권한 안내를 확인하고 인증 절차 진행 또한 League of Legends와 VALORANT의 게임 클라이언트에 있는 계정 관리 페이지에서도 Riot 계정과 Discord 계정을 연결할 수 있다. ## 공유되는 정보와 권한 - 기능 작동에 필요한 정보만 공유된다. - Riot ID - Discord 표시 이름 및 계정 ID - 게임 상태 - 연결 전에 권한 승인 화면에서 공유 정보와 허용 권한을 확인할 수 있다. - 권한에는 프로필 정보, 친구 목록, 게임 활동 상태, 게임 초대 송수신 등이 포함될 수 있다. - 연결된 계정은 Discord 사용자 설정에서 언제든지 해제할 수 있다. - 기능은 Riot과 Discord가 모두 지원되는 지역에서만 제공된다. ## 실용적인 활용 Riot 계정을 Discord에 연결해 두면 게임 내 친구 목록에서 바로 빈자리를 확인하고 초대할 수 있으므로, 5인 파티를 구성하거나 매치 중인 친구에게 합류할 때 편리하다. 다만 계정 연결 전 권한 내용을 확인하고, 필요하지 않다면 언제든 연결을 해제하는 것이 좋다.

원문 읽기(새 탭에서 열림)
discordaccount-linkingleague-of-legendsvalorant+2
gitlab4분 읽기큐레이션 요약

MR을 수동 작업에서 자동화된 워크플로로 전환하기

GitLab 19.0은 AI를 코드 작성 단계에만 사용하는 것을 넘어, 머지 리퀘스트(MR) 생성부터 리뷰 대응·충돌 해결·리베이스·병합까지 전체 lifecycle을 자동화합니다. Developer Flow가 단일 AI 에이전트로 확장되어 반복 작업을 대신 수행하고, 개발자는 방향 설정과 검토에 집중할 수 있습니다. 이를 통해 MR 처리 과정의 수작업과 개발자의 대기 시간을 줄이는 것이 핵심입니다. ## MR 전체를 담당하는 Developer Flow - 기존 Developer Flow는 이슈를 기반으로 MR을 생성하는 데 초점을 맞췄습니다. - GitLab 19.0에서는 생성 이후의 작업까지 같은 MR 안에서 이어서 처리합니다. - 다음과 같은 방식으로 실행할 수 있습니다. - 이슈의 **Generate MR** 버튼 사용 - 이슈나 MR에 **Duo Developer 서비스 계정** 할당 - 이슈 또는 MR의 댓글에서 새로운 `@mention` 트리거 호출 - 에이전트는 별도의 새 MR을 만드는 대신 기존 MR을 계속 수정하며 작업합니다. - 다음 작업을 자동으로 수행할 수 있습니다. - 여러 차례에 걸친 리뷰 피드백 반영 - 장기간 유지된 브랜치의 병합 충돌 해결 - 익숙하지 않은 코드베이스 조사 - 구현 방식 평가 및 결과 보고 - 지나치게 커진 MR 분할 - 새로운 기능의 처음부터 끝까지 구현 ## 단일 에이전트와 개발 환경 구성 - Developer Flow는 `read`, `grep`, `edit`, 명령 실행 등 전체 개발 도구를 사용할 수 있는 단일 에이전트 루프로 재구축되었습니다. - 에이전트가 작업 단계마다 어떤 도구를 사용할지 직접 판단하므로, 특정 순간의 코드 생성이 아니라 MR 전체에 참여할 수 있습니다. - `AGENTS.md`를 읽어 다음과 같은 프로젝트별 정보를 반영합니다. - 잘 알려지지 않은 Bash 명령 - 코딩 규칙과 프로젝트 관례 - 환경별 주의사항 - 아키텍처 결정 사항 - `agent-config.yml`은 에이전트가 실제로 작업을 완료할 수 있도록 개발 환경을 준비합니다. - 필요한 의존성 설치 - 도구 및 설정 구성 - 테스트 실행 - pre-commit hook 실행 - 이를 통해 에이전트가 프로젝트 표준에 맞지 않는 코드를 작성해 후속 재작업을 만드는 문제를 줄입니다. ## AI를 활용한 병합 충돌 해결 - MR의 충돌 화면과 merge checks 위젯에 베타 기능인 **Resolve with Duo** 버튼이 추가되었습니다. - 에이전트는 다음 과정을 수행합니다. - MR의 의도 파악 - 양쪽 브랜치의 변경 내용 분석 - 적절한 해결 전략 선택 - 충돌 파일 수정 - 수정 사항 커밋 및 푸시 - 작업 후에는 발견한 충돌과 해결 방식을 MR 댓글로 요약합니다. - 해결이 안전하지 않다고 판단하면 임의로 수정하지 않고, 처리가 어렵다는 사실을 알립니다. - 특히 여러 릴리스 브랜치에 백포트하거나 연쇄적으로 MR을 관리하는 팀에서 반복적인 충돌 해결 비용을 줄일 수 있습니다. ## 한 번의 클릭으로 리베이스와 병합 - GitLab 19.0에는 베타 기능인 **One-click rebase and merge**가 추가되었습니다. - semi-linear history나 fast-forward 방식에서는 기존에 리베이스 후 결과를 기다렸다가 다시 병합해야 했습니다. - 이제 리베이스와 병합을 한 번의 작업으로 처리할 수 있습니다. - 이 기능은 Free, Premium, Ultimate 모든 요금제에서 제공됩니다. ## 개발자 역할의 변화 - AI 에이전트는 코드 작성, 리뷰 피드백 반영, 충돌 해결처럼 판단이 필요한 작업을 수행합니다. - 리베이스와 같은 반복적인 절차는 자동화 기능이 처리합니다. - 개발자는 작업 실행 과정에 직접 매달리기보다 방향을 제시하고 결과를 검토하며 최종 결정을 내리는 역할에 집중할 수 있습니다. - GitLab은 이를 개발자가 “루프 위에 머무는” 방식이라고 설명합니다. ## 사용 조건과 적용 방법 - 새로운 Developer Flow 기능은 GitLab Duo Agent Platform의 Premium 및 Ultimate에서 사용할 수 있습니다. - 기존 고객은 Duo Agent Platform 무료 평가판으로 체험할 수 있습니다. - GitLab 19.0 이전 버전에서는 `@mention` 워크플로를 사용하기 위해 트리거를 수동 설정해야 할 수 있습니다. - Free 사용자는 별도 절차를 통해 GitLab Duo Agent Platform을 신청할 수 있습니다. 실무에서는 `AGENTS.md`에 프로젝트 규칙과 테스트 방법을 명확히 기록하고, `agent-config.yml`로 재현 가능한 개발 환경을 제공하는 것이 중요합니다. 자동화 결과를 그대로 병합하기보다는 에이전트가 남긴 변경 내용과 충돌 해결 근거를 리뷰하는 방식으로 도입하는 것이 안전합니다.

원문 읽기(새 탭에서 열림)
AI 에이전트CI/CDgitlabDevSecOps+4
gitlab3분 읽기큐레이션 요약

GitLab Duo Agent Platform Self-Hosted를 위한 더 많은 AI 모델

GitLab 19.0은 GitLab Duo Agent Platform Self-Hosted에서 사용할 수 있는 오픈소스 AI 모델을 확대해, 에어갭·규제 환경에서도 더 강력한 에이전트 기능을 제공한다. 기업은 데이터와 소스 코드를 외부 API로 전송하지 않고도 작업 유형과 인프라에 맞는 모델을 선택할 수 있으며, 필요하면 GitLab 관리형 모델과 자체 호스팅 모델을 혼합할 수도 있다. ## 규제·에어갭 환경의 AI 제약 - 데이터 레지던시, 네트워크 격리, 규제 준수 때문에 소스 코드를 외부 클라우드 API로 보낼 수 없는 조직이 대상이다. - 완전한 에어갭 환경에서는 인터넷과 외부 API를 사용할 수 없으므로, 자체 인프라에서 실행하는 오픈소스 모델이 사실상 유일한 선택지다. - 기존에는 이런 환경이 최신 AI 기능 도입에서 뒤처지거나, 모든 작업에 하나의 모델만 사용해야 하는 문제가 있었다. ## GitLab 19.0의 오픈소스 모델 확대 GitLab은 Duo Agent Platform의 실제 에이전트 작업에 필요한 다음 기준을 바탕으로 모델을 평가했다. - 여러 단계의 도구 호출 및 작업 수행 - 지시사항 준수 - 코드 생성 품질 - 대규모 diff와 여러 파일로 구성된 코드베이스에 대한 추론 새롭게 지원되는 모델은 다음과 같다. - Mistral Devstral 2 123B - GLM-5.1 - Kimi-K2.6 - MiniMax-M2.7 이를 통해 단순 작업에는 효율적인 모델을, 복잡한 에이전트 작업에는 더 강력한 모델을 선택하는 방식의 운영이 가능해진다. ## 온프레미스 및 가상 인프라 배포 - 권장 방식은 자체 하드웨어에서 vLLM을 사용해 모델을 제공하는 것이다. - 모든 추론이 조직 내부에서 실행되므로 소스 코드와 데이터가 외부로 나가지 않는다. - 전용 GPU를 직접 구매하기 어려운 팀은 GPU가 연결된 프라이빗 클라우드의 가상 머신에서 모델을 실행할 수 있다. - 이 방식은 필요할 때만 GPU 용량을 확보하면서도 데이터 격리 정책을 유지할 수 있다. ## 배포 환경별 모델 선택 - **완전한 에어갭 환경** - 자체 추론 하드웨어에 오픈소스 모델을 배포해야 한다. - 모델별 GPU·하드웨어 요구사항을 사전에 확인해야 한다. - **하이브리드 환경** - 기능별로 자체 호스팅 모델과 GitLab 관리형 모델을 혼합할 수 있다. - AI Gateway 설정을 통해 어떤 기능이 어떤 모델을 사용할지 구성한다. - **온라인 라이선스 환경** - 사용량 기반 모델을 이용할 수 있다. - 자체 호스팅 모델과 GitLab 관리형 모델을 함께 사용하는 구성이 가능하다. ## 이용 조건 - 오프라인 라이선스 고객은 GitLab Duo Agent Platform Self-Hosted 애드온이 필요하다. - 온라인 라이선스 고객은 사용량 기반 모델을 사용할 수 있으며, 자체 호스팅·GitLab 관리형 모델의 하이브리드 구성이 가능하다. ## 실용적인 권장 사항 완전한 네트워크 격리와 데이터 보안이 중요하다면 vLLM 기반의 자체 GPU 인프라에 지원 모델을 배포하는 것이 적합하다. 반면 작업별 성능과 운영 비용을 균형 있게 관리하려면, 민감한 코드는 자체 호스팅 모델로 처리하고 일반 작업이나 고난도 작업은 GitLab 관리형 모델로 분리하는 하이브리드 구성을 검토할 수 있다.

원문 읽기(새 탭에서 열림)
gitlab-duo-agent-platformvllmgpu-inferenceself-hosted-ai+3
gitlab3분 읽기큐레이션 요약

GitLab Secrets Manager로 CI/CD 자격 증명 관리

GitLab Secrets Manager는 CI/CD 자격 증명을 GitLab 내부에서 안전하게 관리하도록 지원하는 기능으로, GitLab 19.0에서 공개 베타로 제공됩니다. 비밀 값을 프로젝트·그룹 구조와 파이프라인의 브랜치·환경 조건에 따라 최소 범위로 제공해 유출 시 피해를 줄이고, 생성·변경·사용 이력을 감사 로그로 추적할 수 있다는 것이 핵심입니다. 기존 외부 보안 저장소와 달리 별도의 권한 체계와 운영 시스템을 추가로 관리하지 않아도 됩니다. ## CI/CD 변수와 외부 보안 저장소의 한계 - 개발자는 자격 증명을 `.env`, 설정 파일 또는 CI/CD 변수에 임시로 저장하기 쉽습니다. - 프로젝트나 그룹 수준의 CI/CD 변수는 값을 마스킹할 수 있지만, 기본적으로 여러 작업에 주입되어 최소 권한 원칙을 위반할 수 있습니다. - 파이프라인 접근 권한이 있는 사용자가 변수 값을 읽을 가능성도 있습니다. - 별도 Vault를 사용하면 비밀을 CI/CD 설정에서 분리할 수 있지만 다음과 같은 운영 부담이 생깁니다. - 별도 인증 방식 관리 - GitLab과 다른 권한 모델 유지 - 여러 시스템의 감사 로그 상관관계 분석 - 조직·역할 변경 시 권한 동기화 ## GitLab Secrets Manager의 사용 방식 - Secrets Manager는 OpenBao를 기반으로 GitLab에 통합된 네이티브 기능입니다. - `.gitlab-ci.yml`의 `secrets:` 키워드로 작업에 필요한 비밀을 선언합니다. ```yaml deploy: secrets: DATABASE_PASSWORD: gitlab_secrets_manager: name: db-password script: - deploy --password $DATABASE_PASSWORD ``` - 기본적으로 비밀 값은 임시 파일에 기록되고, 해당 파일 경로가 작업 범위의 환경 변수로 전달됩니다. - 값 자체보다 파일 경로를 전달하면 하위 프로세스, 크래시 덤프, 텔레메트리 등에 비밀이 노출될 가능성을 줄일 수 있습니다. ## 기존 GitLab 권한 모델 활용 - 그룹과 프로젝트 구조가 비밀의 격리 경계로 사용됩니다. - 사용자·그룹·역할별로 읽기, 생성, 수정, 삭제 권한을 설정할 수 있습니다. - 그룹 수준에서 만든 비밀은 하위 프로젝트들이 상속받아 공통 자격 증명을 한 번만 정의할 수 있습니다. - 사용자가 프로젝트에서 제거되면 해당 프로젝트의 비밀 접근 권한도 즉시 사라집니다. - 별도 보안 시스템에서 GitLab의 조직 구조와 권한을 다시 구성하고 동기화할 필요가 없습니다. ## 브랜치와 환경별 최소 권한 범위 - 각 비밀은 해당 비밀이 필요한 작업에만 제공됩니다. - 접근 여부는 다음 작업 속성으로 결정됩니다. - 대상 환경 - 실행 브랜치 - 브랜치 보호 여부 - 환경과 브랜치에는 와일드카드를 사용할 수 있습니다. 예를 들어 `production/*`과 같은 규칙을 지정할 수 있습니다. - 보호된 브랜치에서 `production/*` 환경으로 실행되는 작업에만 비밀을 제공하도록 조건을 조합할 수 있습니다. - 작업 실행 시 백엔드가 작업의 신원, 브랜치, 환경을 검증한 뒤 비밀을 반환합니다. - 작업 종료 후 비밀은 러너에 남지 않으며, 로그에서는 값이 마스킹됩니다. - 자격 증명이 유출되어도 접근 가능한 시스템 범위가 좁아져 회전, 조사, 복구에 필요한 작업이 줄어듭니다. ## 파이프라인과 연결된 감사 추적 - 프로젝트·그룹 비밀의 생성, 수정, 삭제 이벤트가 GitLab의 기존 감사 로그에 기록됩니다. - CI/CD 파이프라인에서 비밀을 읽은 이벤트에는 원본 파이프라인 ID와 작업 ID가 포함됩니다. - 따라서 별도 CI 시스템, 보안 저장소, ID 제공자의 로그를 수동으로 조합하지 않고도 비밀 사용 경로를 추적할 수 있습니다. - 감사 로깅은 현재 self-managed 배포에서 제공되며, GitLab.com 지원은 공개 베타 기간 중 추가될 예정입니다. ## 공개 베타와 기존 도구와의 연계 - GitLab.com 및 self-managed 환경의 Premium·Ultimate 사용자가 공개 베타에 참여할 수 있습니다. - GitLab Dedicated 지원은 추후 제공될 예정입니다. - 베타 기간에는 무료이며, 정식 출시 후에는 GitLab Credits를 통해 유료 제공됩니다. - HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Cloud Secret Manager 통합도 계속 사용할 수 있어 기존 시스템에서 단계적으로 전환할 수 있습니다. 실무적으로는 광범위한 CI/CD 변수를 먼저 점검하고, 배포 환경·브랜치별로 필요한 비밀을 Secrets Manager로 이전하는 것이 좋습니다. 특히 운영 자격 증명은 보호된 브랜치와 특정 `production/*` 환경에만 연결해 유출 시 피해 범위를 제한하는 방식을 권장합니다.

원문 읽기(새 탭에서 열림)
CI/CDaccess-controlsecrets-managementaudit-logging+3
gitlab4분 읽기큐레이션 요약

GitLab 19.0 | GitLab 문서

GitLab 19.0은 그룹 단위 AI 코드 리뷰 지침, 사용자 정의 작업 항목, Secrets Manager 오픈 베타 등 협업·보안 기능을 확장한 릴리스입니다. 또한 GitLab Duo를 에이전트 중심으로 강화하고, SBOM 기반 의존성 스캔을 정식 제공하며, 사용량 기반 과금과 새로운 모델·트리거를 도입했습니다. 이번 릴리스는 여러 프로젝트를 아우르는 표준화와 에이전트 기반 개발 자동화에 초점을 둡니다. ## 그룹 단위 GitLab Duo 코드 리뷰 지침 - 기존에는 프로젝트별로만 `.gitlab/duo/mr-review-instructions.yaml`을 설정할 수 있었습니다. - 이제 그룹과 하위 그룹 전체에 공통 리뷰 지침을 적용할 수 있습니다. - 그룹 내 특정 프로젝트를 템플릿으로 지정하면, GitLab Duo가 그룹 지침과 개별 프로젝트 지침을 결합해 코드 리뷰를 수행합니다. - Code Review Flow와 GitLab Duo Code Review 모두 지원합니다. - Premium·Ultimate 등급에서 GitLab.com, Self-Managed, Dedicated 환경에 제공됩니다. ## 사용자 정의 작업 항목 유형 - 프로젝트에서 `Issue`, `Task` 외에 `User Story`, `Bug`, `Maintenance` 같은 작업 항목 유형을 직접 생성하거나 이름을 변경할 수 있습니다. - 각 유형은 고유한 이름과 아이콘을 가지며, 사용자 정의 필드와 상태 라이프사이클을 지원합니다. - 저장된 보기와 이슈 보드에서도 유형을 기준으로 작업을 관리할 수 있습니다. - 최상위 그룹 또는 조직에서 설정한 유형 구성이 하위 프로젝트로 전파됩니다. - 프로젝트별로 특정 유형을 활성화하거나 비활성화할 수 있으며, 유형을 비활성화해도 기존 작업 항목에는 영향을 주지 않습니다. ## GitLab Secrets Manager 오픈 베타 - 기존 폐쇄형 베타에서 Premium·Ultimate 고객 대상 오픈 베타로 확대되었습니다. - GitLab.com과 GitLab Self-Managed에서 사용할 수 있습니다. - 프로젝트 및 그룹 Owner가 CI/CD 시크릿을 GitLab에 저장·조회·참조할 수 있습니다. - 시크릿은 프로젝트 또는 그룹 범위로 제한되며, 명시적으로 요청한 파이프라인 작업만 접근할 수 있습니다. - 아직 베타 지원 정책이 적용되므로 운영 환경에 사용하기 전 안정성과 제한 사항을 검토해야 합니다. ## GitLab Duo Developer의 MR 자동화 - 이슈 할당, `Generate MR` 선택, 이슈·MR 토론에서의 `@mention` 등 여러 방식으로 Developer를 실행할 수 있습니다. - 피드백, To-do, 디자인 관련 질문을 코드 변경, 후속 MR, 조사 요약으로 전환할 수 있습니다. - `AGENTS.md`와 `agent-config.yml`을 설정하면 커밋 전에 테스트와 검사를 실행하도록 구성할 수 있습니다. - 최상위 그룹 또는 인스턴스 관리자가 Developer Flow를 활성화하면 대상 프로젝트에 멘션 및 할당 트리거가 자동으로 추가됩니다. ## SBOM 기반 의존성 스캔 정식 제공 - Maven, Gradle, Python 프로젝트에서 직접 선언한 의존성뿐 아니라 전이 의존성까지 분석합니다. - lockfile이나 해석된 의존성 그래프가 없으면 Maven·Gradle·Python 도구를 자동 실행해 전체 그래프를 생성합니다. - v2 Dependency Scanning 템플릿을 포함하는 것 외에 별도 설정이 거의 필요하지 않습니다. - 의존성 해석이 불가능한 경우 `pom.xml`, `requirements.txt`, `build.gradle`, `build.gradle.kts`를 분석하는 매니페스트 스캔으로 대체됩니다. - 매니페스트 스캔은 직접 의존성만 제공하므로, 전이 의존성까지 확인하려면 lockfile·그래프 파일 또는 의존성 해석 기능이 필요합니다. - Ultimate 등급 기능입니다. ## GitLab Duo Core의 사용량 기반 과금 - GitLab Duo Core가 19.0부터 사용량 기반 과금으로 변경됩니다. - Web IDE와 데스크톱 IDE의 Code Suggestions 사용량이 GitLab Credits를 소비합니다. - Duo Chat은 GitLab Duo Agent Platform 기반의 에이전트 방식으로 변경됩니다. - GitLab UI나 데스크톱 IDE에서 Chat을 사용하려면 인스턴스 또는 최상위 그룹에서 Agent Platform을 활성화해야 합니다. ## 코드 검색과 MR 자동화 트리거 - 정확한 코드 검색 결과를 `repo:` 구문으로 특정 저장소에 한정할 수 있습니다. - 예를 들어 `def authenticate repo:my-group/my-project`처럼 검색하면 지정한 저장소의 결과만 확인할 수 있습니다. - 부분 경로나 패턴을 사용해 여러 저장소를 한 번에 검색할 수도 있습니다. - Draft MR이 리뷰 준비 상태로 전환될 때 Flow나 외부 에이전트를 실행하는 `Merge request ready` 이벤트 트리거가 추가되었습니다. - 프로젝트의 `AI > Triggers`에서 설정하며, `merge_request_ready_flow_trigger` 기능 플래그 뒤에 있고 기본값은 비활성화입니다. ## GitLab Duo Agent Platform의 모델 확장 - Claude Opus 4.7을 Agent Platform에서 사용할 수 있습니다. - 복잡한 다단계 작업, 지시 준수, 결과 검증이 필요한 CI/CD, 코드 리뷰, 취약점 수정 플로우에 적합하도록 개선되었습니다. - GitLab Self-Managed용 Duo Agent Platform은 자체 호스팅 Gemini 모델도 지원하기 시작했습니다. - 제공된 글 내용은 Gemini 지원이 여러 플로우를 지원한다는 설명 중간에서 끝나므로, 세부 지원 범위는 공식 문서를 확인해야 합니다. ## 릴리스의 방향 - 여러 프로젝트에 공통 AI 리뷰 정책과 작업 유형을 적용해 그룹 단위 표준화를 강화했습니다. - 에이전트가 이슈와 MR에서 직접 코드를 수정하고 검증하는 개발 흐름을 확대했습니다. - SBOM 및 전이 의존성 분석으로 공급망 보안 가시성을 높였습니다. - Duo 사용량 기반 과금과 Secrets Manager 베타 도입에 따라 비용 및 운영 정책 검토가 중요해졌습니다. 도입 시에는 그룹 공통 리뷰 지침과 작업 유형을 먼저 표준화하고, SBOM 스캔에서 전이 의존성 해석이 실제로 활성화되었는지 확인하는 것이 좋습니다. Secrets Manager와 새로운 Agent Platform 기능은 베타·기능 플래그 상태와 과금 영향을 검증한 뒤 점진적으로 적용하는 것을 권장합니다.

원문 읽기(새 탭에서 열림)
CI/CDgitlabPythongitlab-duo+4
gitlab3분 읽기큐레이션 요약

조직 전체의 CI 컴포넌트 사용 현황 추적

GitLab 19.0은 CI/CD Catalog에 등록된 공유 컴포넌트의 조직 내 사용 현황을 추적하는 Components Analytics를 제공한다. 모든 요금제에서 컴포넌트별 채택 규모를 확인할 수 있고, Ultimate에서는 어떤 프로젝트가 어떤 버전을 사용하는지까지 조회할 수 있다. 이를 통해 보안 취약점 대응, 구버전 정리, 표준 파이프라인 채택 여부를 수작업 감사 없이 파악할 수 있다. ## 공유 CI의 가시성 문제 - CI/CD Catalog는 재사용 가능한 파이프라인 컴포넌트를 버전별로 배포해 프로젝트가 `include` 한 줄로 사용할 수 있게 한다. - 중앙 배포와 표준화는 가능하지만, 배포 후 다음 정보를 파악하기 어렵다는 문제가 있었다. - 실제로 어떤 프로젝트가 컴포넌트를 사용하는지 - 각 프로젝트가 어느 버전을 사용하는지 - 보안 수정이 적용되지 않은 구버전이 얼마나 남아 있는지 - 공유 컴포넌트의 보안 수정은 기존 사용 프로젝트에 자동 전파되지 않으므로, 취약점 발생 시 조직의 노출 범위를 수작업으로 조사해야 했다. ## Components Analytics의 채택 현황 보기 - `Explore > CI/CD Catalog > Analytics`에서 관리 중인 카탈로그 리소스의 사용 현황을 확인할 수 있다. - 모든 요금제에서 제공되는 고수준 분석 기능은 다음 정보를 보여준다. - 최신 릴리스 버전 - 최근 30일 동안 컴포넌트를 가져간 고유 프로젝트 수 - 해당 버전에서 제공되는 컴포넌트 목록 - 이를 통해 널리 사용되는 컴포넌트와 사실상 사용되지 않는 컴포넌트를 구분할 수 있다. - 유지보수 우선순위 설정, 폐기 계획 수립, 플랫폼 투자 효과 측정에 활용할 수 있다. - 이 고수준 분석 기능은 GitLab 18.9에서 출시되었으며 Free를 포함한 모든 티어에서 제공된다. ## Ultimate의 컴포넌트 사용 상세 조회 - GitLab Ultimate에서는 특정 카탈로그 리소스를 열어 최근 30일간 사용한 프로젝트를 확인할 수 있다. - 프로젝트별로 다음 정보를 제공한다. - 사용 중인 컴포넌트 버전 - 최신 버전 여부 - 구버전 사용 여부 - 예를 들어 v2.1에서 보안 수정이 배포된 경우, 여전히 v1.x에 고정된 프로젝트를 바로 식별할 수 있다. - 관리자는 해당 프로젝트에 머지 리퀘스트를 제안하거나 담당자에게 알림을 보내고, 필요한 경우 문제를 에스컬레이션할 수 있다. - 대규모 리팩터링의 영향 범위, 구버전 폐기 가능 여부, 보안 패치의 실제 적용 여부를 판단하는 데도 유용하다. ## 다른 CI 플랫폼과의 차이 - GitHub Actions는 조직 전체에서 재사용 워크플로와 버전 사용 현황을 보여주는 기본 카탈로그 분석 기능이 없어 별도 도구가 필요하다. - CircleCI Insights는 파이프라인 성능을 분석하지만, 어떤 팀이 어떤 Orb를 어느 버전으로 사용하는지는 제공하지 않는다. - Jenkins Shared Libraries도 사용 현황 추적을 위해 맞춤형 도구를 구축해야 한다. - GitLab은 재사용 가능한 컴포넌트 카탈로그와 사용 현황 분석을 기본 기능으로 결합했다. ## AI 생성 파이프라인에 대한 거버넌스 - AI가 생성하는 파이프라인이 늘어날수록 조직 표준이 실제 운영 환경에 적용되고 있는지 확인하는 기능이 중요해진다. - CI/CD Catalog는 표준 컴포넌트를 배포하고, Components Analytics는 그 표준이 실제로 사용되는지 감사할 수 있게 한다. - Self-Managed 및 Dedicated 고객은 GitLab.com의 컴포넌트를 미러링하거나 자체 컴포넌트를 추가해 규제·에어갭 환경에서도 승인된 표준 집합을 운영할 수 있다. 조직에서 공유 CI 컴포넌트를 운영한다면 Analytics로 채택률과 방치된 컴포넌트를 먼저 파악하고, Ultimate 환경에서는 구버전 사용 프로젝트를 대상으로 보안 패치와 업그레이드를 직접 추진하는 것이 좋다.

원문 읽기(새 탭에서 열림)
CI/CDgitlabDevSecOpsyaml+3
github2분 읽기큐레이션 요약

GitHub 소유 저장소에 대한 무단 접근 조사

Alexis Wales는 GitHub의 최고정보보호책임자(CISO)로서 플랫폼과 제품, 오픈소스 커뮤니티의 보안을 담당한다. 20년간 국방부와 CISA 등에서 국가 및 민간 부문의 핵심 네트워크를 방어해 왔으며, 공공·민간 협력을 통해 기술 보안 문제를 해결하는 데 주력하고 있다. 그녀의 목표는 전 세계 1억 5천만 명 이상의 개발자가 GitHub에서 안전하게 소프트웨어를 개발하고 배포하도록 지원하는 것이다. ### GitHub의 보안 리더십 - GitHub의 보안 전문가 팀을 이끈다. - GitHub 플랫폼과 제품의 보안을 강화한다. - 오픈소스 생태계와 커뮤니티를 보호한다. - 개발자들이 안전하게 소프트웨어를 만들고 배포할 수 있도록 지원한다. ### 국가 핵심 네트워크 방어 경험 - 약 20년 동안 국가 및 민간 부문의 중요 네트워크를 보호해 왔다. - 미국 국방부에서 보안 업무를 수행했다. - 국토안보부 산하 CISA에서도 근무하며 사이버 보안과 핵심 인프라 보호 경험을 쌓았다. ### 공공·민간 협력에 대한 관점 - 국가 기관과 민간 기업이 협력해야 가장 어려운 보안 위협에 효과적으로 대응할 수 있다고 본다. - 이러한 협력에 대한 관심은 국가 및 민간 네트워크를 방어한 경험에서 비롯되었다. - 일상적으로 사용하는 기술을 위협하는 보안 문제를 공동으로 해결하는 것을 중시한다. 실용적으로는 GitHub와 같은 개발 플랫폼의 보안을 강화하려면 기술적 방어뿐 아니라 공공기관, 기업, 오픈소스 커뮤니티 간의 지속적인 정보 공유와 협력이 필요하다는 점을 시사한다.

원문 읽기(새 탭에서 열림)
오픈 소스클라우드 보안githubcybersecurity+1
figma3분 읽기큐레이션 요약

피그마 디자인 에이전트가 출시되었습니다 | 피그마 블로그

Figma는 캔버스 안에서 직접 작동하며 디자인 시스템과 팀의 작업 맥락을 이해하는 전용 디자인 에이전트를 공개했다. 이 에이전트는 AI 생성과 직접 조작 중 하나를 선택하게 하지 않고, 아이디어 탐색부터 반복 수정·대량 편집까지 디자이너의 작업을 보조한다. Figma는 이를 통해 속도와 정밀성, 자동화와 디자이너의 통제력을 함께 확보하려 한다. ## 캔버스에 통합된 Figma 디자인 에이전트 - 에이전트는 Figma 캔버스와 왼쪽 레일에서 바로 사용할 수 있다. - 특정 디자인 레이어에서 프롬프트를 시작할 수 있다. - 여러 프롬프트를 병렬로 실행해 다양한 아이디어를 동시에 비교할 수 있다. - 사용자가 직접 편집하는 동안 에이전트도 계속 반복 작업을 수행할 수 있다. - 별도의 도구 설정이나 컨텍스트 전환 없이 팀과 같은 파일 안에서 협업자처럼 작동한다. - 컴포넌트, 디자인 토큰, 변수, 표준, 모범 사례 등 Figma 내부의 디자인 시스템 맥락을 이해하도록 설계됐다. ## Figma 에이전트와 MCP 서버의 역할 분담 - **Figma 에이전트** - 캔버스 안에서 디자인을 생성하고 수정하는 데 적합하다. - 현재 파일과 디자인 시스템에 대한 추가 맥락을 활용한다. - Figma 파일을 직접 편집하며 결과물을 바로 조작할 수 있다. - **MCP 서버와 `use_figma`** - 코드를 캔버스로 가져오거나 디자인을 다시 코드로 보내는 작업에 사용한다. - 코드와 Figma 사이를 오가며 디자인 충실도를 유지할 수 있다. - 두 방식은 경쟁 관계가 아니라, 캔버스 작업과 코드-디자인 간 연결을 각각 담당한다. ## 다양한 디자인 방향 탐색 - 첫 번째 아이디어나 프롬프트에 머무르지 않고 여러 방향을 빠르게 실험할 수 있다. - 같은 문제에 대해 서로 다른 스타일의 시안을 여러 개 생성할 수 있다. - 예: 유기적 스타일, 현대적 스타일, 복고풍 스타일 - 서로 다른 비즈니스 목표에 맞춘 결제 흐름이나 정보 구조를 비교할 수 있다. - Figma Design에서 흐름, 상태, 문구, 구조를 구체화한 뒤 Figma Make로 보내 동작을 위한 코드 레이어를 생성할 수 있다. - 반대로 Figma Make에서 만든 프레임을 Figma Design으로 가져와 에이전트로 다듬은 뒤 다시 Make로 보낼 수도 있다. ## 디자인 시스템을 활용한 생성과 반복 - 에이전트는 자주 사용되거나 최근 사용된 컴포넌트를 우선 활용한다. - 특정 라이브러리를 선택하거나 토큰·변수·컴포넌트를 `@` 멘션해 결과를 세밀하게 통제할 수 있다. - 디자인 시스템에 맞는 화면을 생성하고 기존 디자인을 새로운 스타일로 리믹스할 수 있다. - 예시 작업: - 모바일 앱용 가로 스크롤 이미지 캐러셀 생성 - 이미지 위·아래에 제목을 배치한 여러 버전 비교 - 특정 디자인을 여러 시각적 스타일로 변환 - AI가 평균적인 결과물을 빠르게 만드는 데 그치지 않도록, 여러 대안을 비교한 뒤 최종 방향은 디자이너가 직접 선택하고 조작하도록 한다. ## 반복적인 대량 작업 자동화 - 에이전트는 맥락과 정밀성이 필요한 단순 반복 작업을 자동화한다. - 대표적인 활용 사례: - 파일 전체의 타이포그래피 업데이트 - 여러 화면의 동일 컴포넌트 일괄 교체 - 전체 플로우의 패딩 값 변경 - 변수 이름 일괄 변경 - 그리드 전체의 Lorem ipsum과 이미지를 실제에 가까운 콘텐츠로 교체 - 칩 컴포넌트를 모두 활성 상태로 변경 - 화면을 다크 모드로 변환 - 디자인 시스템 관리자는 라이브러리의 설명, 태그, 사용 사례, 컴포넌트 문서와 명명 규칙을 대량으로 정리할 수 있다. ## 코드와 디자인 사이의 연속적인 흐름 - 코드에서 시작한 결과물을 Figma의 코드-투-캔버스 기능으로 가져와 디자인 시스템을 적용하고 시각적으로 반복 수정할 수 있다. - 수정된 디자인은 MCP 서버를 통해 다시 코드로 전달할 수 있다. - 이 과정에서 Figma 에이전트가 캔버스 작업을 지원해 코드와 디자인 간 이동 중에도 작업 흐름과 맥락을 유지한다. - AI 지원과 직접 조작을 필요에 따라 오갈 수 있어, 모든 작업을 프롬프트로 해결하지 않아도 된다. 디자인 방향을 넓게 탐색할 때는 에이전트를 활용하고, 최종 선택과 세밀한 조정은 캔버스에서 직접 수행하는 방식이 가장 실용적이다. 특히 디자인 시스템을 사용하는 팀은 컴포넌트·토큰 기반의 대량 수정과 코드-디자인 동기화에 에이전트를 효과적으로 활용할 수 있다.

원문 읽기(새 탭에서 열림)
AI디자인 시스템생성형 AI모델 컨텍스트 프로토콜+2
cloudflare4분 읽기큐레이션 요약

Cloudflare에서 Claude Managed Agents 발표

Cloudflare와 Anthropic은 Claude Managed Agents의 에이전트 루프는 Anthropic에서 실행하고, 코드 실행·샌드박스·네트워크 연결은 Cloudflare에서 처리하는 통합 환경을 공개했습니다. 이를 통해 보안 프록시, 프라이빗 서비스 연결, 샌드박스 관측성, 브라우저 제어, 이메일, 사용자 정의 도구를 기본 제공하면서도 인프라를 직접 통제할 수 있습니다. 특히 작업 특성에 따라 전체 Linux microVM과 가벼운 V8 isolate를 선택해 비용과 확장성을 조절할 수 있다는 점이 핵심입니다. ## Claude Managed Agents의 구조 - Claude Managed Agents는 Anthropic 플랫폼에서 에이전트를 정의하고 실행하는 관리형 환경입니다. - 에이전트는 파일 읽기, 명령 실행, 웹 브라우징, 코드 실행 등을 수행할 수 있습니다. - 프롬프트 캐싱, 대화 압축(compaction), 에이전트 실행 최적화 기능이 내장되어 있습니다. - 기존에는 에이전트 루프와 실행 인프라를 모두 Anthropic 환경에서 운영했지만, 이제 실행 환경을 Cloudflare 등 외부 인프라로 분리할 수 있습니다. - Anthropic이 이를 “두뇌와 손의 분리”라고 설명하듯이: - **두뇌**: Claude의 에이전트 루프 - **손**: 코드 실행, 파일 시스템, 명령 도구, 네트워크 연결을 담당하는 Cloudflare 환경 ## Cloudflare 기반 실행 환경 - Claude Agent가 세션을 시작하면 Cloudflare Workers 기반 컨트롤 플레인에 메시지를 보냅니다. - 컨트롤 플레인은 각 세션에 샌드박스를 할당해 다음 작업을 지원합니다. - 코드 실행 - 애플리케이션 개발 - CLI 도구 실행 - 파일 생성 및 수정 - 세션이 일시 중지되어도 상태가 자동으로 보존됩니다. - VM 기반 샌드박스는 다음과 같이 설정할 수 있습니다. - 인스턴스 크기 조정 - 실행 컨테이너 이미지 사용자 정의 - Cloudflare 대시보드에서 샌드박스 상태를 확인하고 로그를 조회할 수 있습니다. - 로그는 Datadog이나 Splunk 같은 외부 관측성 플랫폼으로 전송할 수 있습니다. - 기본 UI를 통해 실행 중인 샌드박스에 SSH로 접속하고 대화형 셸 세션을 사용할 수 있습니다. ## 기본 제공되는 통합 기능 - **보안 프록시** - 에이전트의 모든 외부 트래픽을 사용자 정의 프록시로 통과시킬 수 있습니다. - 샌드박스 외부에서 인증 정보를 주입해 에이전트가 비밀값을 직접 보지 못하게 할 수 있습니다. - 데이터 유출을 차단하고 외부 서비스와의 상호작용을 관찰할 수 있습니다. - **샌드박스 제어와 관측성** - 상세한 메트릭과 로그를 제공합니다. - 실행 중인 머신에 SSH로 접근할 수 있습니다. - 샌드박스 이미지를 직접 구성할 수 있습니다. - **프라이빗 서비스 연결** - 인터넷에 서비스를 공개하지 않고 내부 API나 데이터베이스에 연결할 수 있습니다. - **브라우저 제어** - 에이전트의 브라우저 세션을 기록하고 감사 추적을 남길 수 있습니다. - 세션 녹화와 human-in-the-loop 승인 흐름을 지원합니다. - **이메일** - 에이전트별 이메일 주소를 부여하고 이메일을 발송할 수 있습니다. - **사용자 정의 도구** - 별도의 인프라 없이 함수를 작성하고 배포해 에이전트 기능을 확장할 수 있습니다. ## microVM과 isolate를 통한 확장성 - 모든 에이전트에 전용 microVM을 할당하면 대규모 동시 실행에서 비용과 자원 낭비가 커질 수 있습니다. - Cloudflare는 두 가지 샌드박스 방식을 제공합니다. - **microVM 기반 샌드박스** - 완전한 Linux 환경을 제공합니다. - 애플리케이션 개발, Linux 기반 도구, 복잡한 코드 실행에 적합합니다. - Cloudflare Containers를 사용할 수 있습니다. - **V8 isolate 기반 샌드박스** - Dynamic Workers와 Codemode를 이용해 임의의 코드를 실행합니다. - 파일 시스템을 제공하면서도 전체 VM보다 가볍습니다. - 수 밀리초 단위로 부팅할 수 있어 비용과 시작 시간이 줄어듭니다. - 에이전트 설정에서 백엔드 유형으로 `isolate`를 선택하면 V8 isolate를 사용할 수 있습니다. - 수만 개 이상의 동시 에이전트가 필요한 경우 isolate 방식이 VM 기반보다 훨씬 높은 확장성을 제공할 수 있습니다. - 반대로 완전한 Linux 환경이나 강한 격리가 필요하면 microVM을 선택하는 것이 적합합니다. ## 보안과 네트워크 제어 - 에이전트가 조직 내부의 데이터와 서비스에 접근할수록 유용성은 높아지지만 보안 위험도 커집니다. - Cloudflare 샌드박스는 아웃바운드 프록시를 통해 외부 서비스와의 통신을 제어할 수 있습니다. - 프록시에서 동적으로 인증하고 비밀값을 요청에 삽입하면, 샌드박스와 에이전트가 실제 자격 증명을 직접 보유하지 않아도 됩니다. - 이를 통해 샌드박스와 외부 서비스 사이에 동적이고 사용자 정의 가능한 zero-trust 인증 구조를 구성할 수 있습니다. - 제공된 글은 이 보안 섹션이 “데이터 유출 방지” 설명 도중 중단되어 있어, 세부 구현이나 설정 방법까지는 확인할 수 없습니다. ## 실용적인 선택 기준 - 단순한 코드 실행과 대규모 동시성이 중요하면 **V8 isolate**를 우선 고려하는 것이 좋습니다. - Linux 도구, 애플리케이션 빌드, 장시간 실행되는 개발 작업이 필요하면 **microVM 또는 Containers**가 적합합니다. - 내부 시스템에 연결할 때는 프록시 기반 인증과 프라이빗 연결을 사용해 비밀값과 서비스를 샌드박스에 직접 노출하지 않는 구성이 권장됩니다. - 운영 환경에서는 Cloudflare 대시보드, 로그 외부 전송, 브라우저 세션 기록을 함께 활용해 에이전트 행동을 지속적으로 감사하는 것이 중요합니다.

원문 읽기(새 탭에서 열림)
Cloudflare Workerszero-trust-securitycloudflare-sandboxesagent-sdk+3
google4분 읽기큐레이션 요약

경험적 연구 지원(ERA): Nature 게재에서 계산적 발견 촉진까지

ERA는 Gemini를 활용해 과학 문헌을 탐색하고, 실험 코드를 작성·개선하며, 수천 가지 해결책을 비교하는 과학 연구 지원 도구다. Nature 논문에서 유전체학, 공중보건, 위성영상, 신경과학, 시계열 예측, 수학 등 다양한 벤치마크에서 전문가 수준의 성능을 보였다. Google은 ERA를 활용한 여러 과학 연구 결과를 공개하고, AlphaEvolve와 결합한 Computational Discovery를 Google Labs의 신뢰할 수 있는 테스터 프로그램으로 제공하기 시작했다. ## 과학 코드를 자동으로 탐색하고 최적화하는 ERA - 사용자가 과학적 문제와 성공 기준을 제시하면 ERA가 다음 작업을 수행한다. - 관련 과학 문헌 검색 - 분석 및 예측 코드 작성 - 여러 알고리즘과 기법 조합 - 실행 결과 평가 - 성능이 낮은 접근법 수정 및 반복 실험 - 트리 탐색(tree search) 방식으로 수천 가지 후보를 검토하고, 주어진 목표에 맞춰 코드를 최적화한다. - 단순한 코드 생성이 아니라, 가설과 구현 방법을 실험적으로 비교해 가장 성능이 좋은 계산 모델을 찾는 데 초점을 둔다. ## 다양한 과학 분야에서의 전문가 수준 성능 - Nature 논문에서는 다음 분야의 문제를 대상으로 ERA를 평가했다. - 유전체학 - 공중보건 - 위성영상 분석 - 신경과학 예측 - 일반 시계열 예측 - 수학 - 여러 벤치마크에서 전문가 수준의 결과를 달성했다. - 이 결과는 고급 계산 모델링 기술에 대한 접근성을 넓히고, 기존 전문가의 연구 역량도 확장할 가능성을 보여준다. ## 감염병 입원 환자 예측 - 미국 각 주의 독감, 코로나19, RSV 병원 입원 건수를 최대 4주 앞서 예측했다. - ERA 기반 예측은 세 감염병 모두에서 미국 질병통제예방센터(CDC) 예측 리더보드의 최상위권 또는 1위를 기록했다. - 다른 국가나 질병에도 비교적 쉽게 적용할 수 있는 기법을 사용했다는 점이 강조됐다. ## 캘리포니아 물 공급과 적설 유출량 예측 - 눈으로 물이 공급되는 캘리포니아 강 유역의 계절성 유출량을 예측하는 모델을 개발했다. - ERA 모델은 봄철 유출량을 조기에 예측하는 데 기존 공식 전망인 Bulletin 120(B120)보다 높은 정확도를 보였다. - 예측 정확도가 향상되면 농업과 주민 생활에 중요한 수자원 관리와 배분을 개선할 수 있다. ## 위성 데이터를 활용한 대기 CO₂ 지도 작성 - 정지궤도 기상위성 데이터와 추가 정보를 결합해 대기 중 CO₂ 농도를 추정했다. - 기존 위성인 Orbiting Carbon Observatory-2가 약 16일마다 특정 지점을 측정하는 것과 달리, ERA 모델은 넓은 지역의 CO₂ 농도를 약 10분 간격으로 추정할 수 있다. - 로스앤젤레스 분지의 도시 배출 증가를 식별하고, 식물이 낮 동안 CO₂를 흡수하면서 농도가 감소하는 현상도 포착했다. - 이러한 고해상도 추정치는 온실가스의 공간적·시간적 변화를 모니터링하고 모델링하는 데 활용될 수 있다. ## 태양에너지 장치 설계 최적화 - ERA와 Google Antigravity를 함께 사용해 3차원 태양에너지 포집 구조를 탐색했다. - ERA는 500개의 삼각형으로 구성된 입체 팬(volumetric fan) 형태가 산란된 태양광을 가두면서 후방 음영을 만들지 않아 에너지 포집을 극대화할 수 있다고 제안했다. - 이는 AI 시스템들이 서로 다른 설계·최적화 작업을 결합할 수 있음을 보여주는 사례다. ## 소매 판매 예측 - 미국 경제지표, Google Trends, 과거 판매 패턴, 소비자 심리 등을 입력으로 사용했다. - ERA가 설계한 모델은 상용 컨센서스 전망과 Chicago Fed의 CARTS 월간 소매 판매 예측을 충족하거나 넘어섰다. - 정확한 소매 예측은 재고 부족과 폐기물을 줄이고, 기업 운영과 경제 정책 수립을 지원할 수 있다. ## Computational Discovery로의 확장 - Google은 ERA와 AlphaEvolve를 결합한 Computational Discovery를 공개하기 시작했다. - Computational Discovery는 과학 문제를 계산적으로 탐구하는 보다 넓은 실험 도구로 소개됐다. - Gemini for Science의 다른 도구들과 역할이 구분된다. - Computational Discovery: 계산 실험과 모델 탐색 - Hypothesis Generation: AI Co-Scientist 기반의 가설 생성 - Literature Insights: 과학 문헌 분석 - 이 도구들은 과학적 방법의 서로 다른 단계를 지원하도록 설계됐다. ERA는 과학자의 반복적인 코드 작성과 실험 최적화 작업을 자동화해, 복잡한 계산 연구를 더 빠르고 폭넓게 수행하도록 돕는 도구다. 특히 감염병 예측, 수자원 관리, 기후 모니터링처럼 실제 정책과 공공복지에 직접 연결되는 문제에서 활용 가능성이 크며, 연구자는 ERA를 최종 판단을 대신하는 시스템이라기보다 다양한 계산적 가설을 빠르게 검증하는 연구 파트너로 활용하는 것이 적절하다.

원문 읽기(새 탭에서 열림)
AI머신러닝geminitime-series-forecasting+4
figma3분 읽기큐레이션 요약

Friends of Figma의 브랜드 리뉴얼이 글로벌 커뮤니티의 이야기를 전하다 | Figma 블로그

Friends of Figma는 전 세계 지역 커뮤니티의 다양성과 연결성을 표현하기 위해 브랜드를 새롭게 개편했다. 새 디자인은 Figma와의 연관성은 유지하면서도 각 지역 챕터가 도시와 문화를 반영해 자유롭게 활용할 수 있도록 설계됐다. 핵심은 통일된 결과물을 강요하기보다, 공통된 정신과 최소한의 규칙 안에서 챕터들이 직접 브랜드를 소유하고 발전시키도록 하는 것이다. ## 전 세계로 확장된 Friends of Figma - Friends of Figma는 Figma 사용자를 연결하고 서로 배우며 영감을 나누는 공식 사용자 그룹 프로그램이다. - 2026년 기준 전 세계 **82개국, 250개 이상의 챕터**가 운영되고 있다. - 지난해에는 워크숍, 웨비나, 디자인 토크, 시청 파티, 친목 모임 등 **900개 이상의 행사**가 열렸다. - 2018년부터 커뮤니티 주도의 모임이 형성됐고, Figma는 2020년 Friends of Figma 프로그램을 출범해 챕터 리더 선정, 행사 지원, 신기능 사전 공개 등을 제공했다. - AI로 산업이 빠르게 변화하는 상황에서, 지역 기반의 실제 만남과 사람 간 연결이 더욱 중요해졌다는 점이 브랜드 개편의 배경이다. ## Figma와 연결되면서도 지역적인 브랜드 - 새 디자인 시스템은 두 가지 목표를 동시에 추구한다. - Figma와 구별되지만 Figma의 정체성은 유지할 것 - 각 챕터가 도시와 지역의 특성을 반영해 자신만의 방식으로 표현할 수 있을 것 - Figma 브랜드와 연결된 시각적 정체성은 지역 커뮤니티가 신규 참가자와 후원자를 유치하는 데 도움을 준다. - 특히 디자인 커뮤니티가 충분히 형성되지 않은 지역에서는 Figma와의 공식적인 연계가 신뢰와 참여를 높이는 역할을 한다. - 이 시스템은 모든 챕터가 똑같은 결과물을 만드는 방식이 아니라, 공통된 정신을 공유하는 **민주적 디자인 시스템**을 지향한다. ## Figma 로고의 기본 형태를 활용한 심벌 - 새 Friends of Figma 로고는 기존 Figma 로고를 구성하는 기본 도형을 분리해 새로운 조합의 building block으로 활용한다. - 각각의 도형은 서로 다른 지역 챕터를 상징하고, 이들이 모여 하나의 글로벌 커뮤니티를 구성한다는 의미를 담는다. - 따라서 로고는 단순한 브랜드 변형이 아니라, 독립적인 챕터들이 공동체로 연결되는 과정을 시각화한다. ## 제약을 줄이고 창의성을 여는 디자인 규칙 - 브랜드 가이드라인은 색상, 챕터 배지, 스티커 등 기본적인 공통 요소를 제공한다. - 모든 챕터는 핵심 색상 체계를 공유하지만, 제공된 팔레트에서 **추가 색상 6개를 직접 선택**할 수 있다. - 스티커 템플릿은 최소한의 형태만 제공하며, 그 안에 어떤 그래픽과 메시지를 담을지는 각 챕터가 결정한다. - 즉, 브랜드가 모든 표현을 통제하기보다 “창의성을 발휘할 수 있을 만큼만 제한”하는 접근이다. - 최종 결과물보다 각 지역의 사람, 장소, 행사처럼 실제 커뮤니티를 구성하는 요소가 중심이 된다. ## 지역의 현실을 담는 사진과 콘텐츠 - 새 사진 가이드는 전문적인 연출보다 지역의 일상과 거리에서 포착되는 모습을 중시한다. - 해당 지역 주민이 알아볼 수 있는 장소와 분위기, 실제 행사 참여자의 모습을 통해 챕터의 정체성을 표현한다. - 이를 통해 Friends of Figma가 전 세계적으로 통일된 브랜드이면서도, 서울·상파울루·바쿠·나이로비 등 각 지역에서 서로 다른 모습으로 존재하도록 한다. ## 실용적인 시사점 - 글로벌 커뮤니티 브랜드는 모든 지역에 동일한 디자인을 적용하기보다, **공통 요소와 지역 자율성의 균형**을 설계하는 것이 효과적이다. - 브랜드 가이드라인을 세밀하게 통제하기보다 핵심 원칙, 기본 자산, 선택 가능한 범위를 제공하면 참여자들의 소유감과 창의성을 높일 수 있다. - 특히 사용자 그룹이나 지역 지부를 운영하는 조직이라면 로고보다 실제 사람과 장소, 활동이 드러나는 콘텐츠를 브랜드의 중심에 두는 것이 바람직하다.

원문 읽기(새 탭에서 열림)
Figma디자인 시스템brandingvisual-identity+1