cloudflare·2026년 8월 7일·3분 읽기큐레이션 요약

Workers AI와 AI Gateway를 하나의 AI 제어 플레인으로 통합하기

AI Gateway와 Workers AI는 각각 모델 호출 프록시와 Cloudflare 관리형 추론 서비스로 출발했지만, 이제 하나의 통합 AI 제어 평면으로 수렴하고 있다. 사용자는 단일 바인딩과 REST API를 통해 Workers AI를 포함한 여러 모델 제공자를 호출하면서 관측성, 로깅, 보안, 비용 관리, 결제를 한곳에서 처리할 수 있다. 향후에는 제공자가 아니라 원하는 모델을 기준으로 자동 라우팅·장애 조치·부하 분산까지 수행하는 모델 우선 라우팅을 제공할 계획이다. ## 통합된 바인딩과 REST API - Workers AI와 AI Gateway는 별도의 호출 경로가 아니라 동일한 `env.AI.run()` 바인딩으로 통합된다. - `gateway: { id: "default" }`를 지정하면 기본 AI Gateway를 통해 Workers AI 모델을 호출할 수 있다. - REST API도 통합되어 다음과 같은 `/ai/` 엔드포인트를 사용한다. - `https://api.cloudflare.com/client/v4/accounts/{account_id}/ai/run/{model}` - `cf-aig-gateway-id: default` 헤더로 기본 게이트웨이를 지정 - 사용자는 처음부터 Workers AI와 AI Gateway 중 어느 제품을 선택할 필요 없이 관측성과 제어 기능이 포함된 경로를 사용할 수 있다. - 여러 애플리케이션을 분리하거나 애플리케이션별 정책을 적용해야 하는 경우에는 별도의 이름 있는 게이트웨이를 지정할 수 있다. ## 자동 관측성과 제어 - AI Gateway를 사전에 생성하지 않아도 `default` 게이트웨이를 처음 인증 요청에 사용하면 자동으로 생성된다. - 별도 대시보드 설정 없이 다음 정보가 기록된다. - 요청 및 응답 전문 - 모델별 토큰 사용량 - 요청 비용 및 비용 귀속 - 지연 시간 분석 - 오류율 - 기존 Workers AI 직접 호출에 게이트웨이 옵션만 추가하면 전체 관측성을 활성화할 수 있다. - 이후 캐싱 규칙을 사용자 지정하거나 애플리케이션별로 트래픽을 분리하려면 이름 있는 게이트웨이로 변경하면 된다. - 프롬프트와 응답까지 확인할 수 있어 모델 동작 디버깅과 AI 출력 감사에 유용하다. ## AI Gateway 크레딧과 Workers AI 통합 결제 - 기존에는 AI Gateway 크레딧을 OpenAI, Anthropic 등 외부 제공자에만 사용할 수 있었다. - 이제 동일한 크레딧 지갑으로 다음 서비스의 사용량을 결제할 수 있다. - OpenAI - Anthropic - Workers AI - 기타 지원 모델 제공자 - Workers AI에도 선불 결제가 적용된다. - AI Gateway 통합 결제를 사용하는 Workers AI 이용자에게는 더 높은 요청 한도가 제공될 수 있다. - 실제 한도와 상향 요청 방법은 최신 개발자 문서를 확인해야 한다. ## 모델 우선 라우팅 - 현재는 사용자가 특정 제공자를 직접 선택해야 하므로, 해당 제공자의 장애나 속도 제한이 애플리케이션 장애로 이어질 수 있다. - 향후에는 “어느 제공자를 호출할지”가 아니라 “어떤 모델이 필요한지”를 지정하는 방식으로 전환한다. - 추론 능력이 높은 모델 - 빠른 요약 모델 - 저렴한 임베딩 모델 - AI Gateway가 모델을 호스팅하는 제공자를 선택하고 다음 작업을 자동으로 처리한다. - 제공자 선택 - 장애 조치 - 부하 분산 - 용량 부족 시 다른 제공자로의 투명한 전환 - 예를 들어 `kimi-k2.7-code`를 요청하면 Workers AI, Moonshot API 또는 동일 가중치를 제공하는 다른 검증된 제공자 중 적절한 경로가 선택될 수 있다. - 원하면 특정 제공자에 고정할 수도 있다. - 검증된 제공자를 사용하고 Zero Data Retention(ZDR) 같은 데이터 처리 요구사항도 반영할 예정이다. ## 실용적인 적용 방향 새 프로젝트라면 `default` 게이트웨이를 사용해 별도 설정 없이 로그, 토큰 사용량, 비용, 오류율을 확보하는 것이 권장된다. 애플리케이션이 커지면 이름 있는 게이트웨이로 분리하고 캐싱·보안·라우팅 정책을 세분화하면 된다. 장기적으로는 특정 제공자에 강하게 결합하기보다 모델 중심으로 호출 구조를 설계하는 편이 장애 대응과 비용 최적화에 유리하다.

원문 읽기(새 탭에서 열림)

rest-api옵저버빌리티ai-gatewayload-balancing+3

cloudflare·2026년 7월 17일·3분 읽기큐레이션 요약

Cloudflare WAF, 두 가지 고위험 취약점으로부터 WordPress 애플리케이션 보호

Cloudflare는 WordPress의 REST API 관련 SQL 인젝션과 인증 없는 원격 코드 실행(RCE) 취약점을 차단하는 WAF 규칙을 모든 고객에게 배포했습니다. 다만 WAF는 임시 방어 수단일 뿐이며, WordPress를 보안 수정 버전으로 업데이트하는 것이 근본적인 해결책입니다. 영향을 받는 사이트는 자동 업데이트 여부와 Cloudflare 규칙의 차단 상태를 반드시 확인해야 합니다. ### 취약점의 범위와 심각도 - **CVE-2026-60137 — SQL 인젝션** - WordPress 6.8 이상에 존재합니다. - 공격자가 조작된 입력값으로 데이터베이스 쿼리를 변경할 수 있습니다. - 심각도는 **High**입니다. - **CVE-2026-63030 — 인증 없는 원격 코드 실행** - WordPress 6.9 이상에서 발생합니다. - 영구 객체 캐시를 사용하지 않는 경우 REST API의 배치 엔드포인트를 통해 인증 없이 코드 실행이 가능합니다. - 로그인이나 사용자 상호작용이 필요하지 않으며, 심각도는 **Critical**입니다. - SQL 인젝션 취약점과 연관된 공격 경로를 사용합니다. - WordPress 6.8 미만 버전은 영향을 받지 않습니다. ### WordPress 보안 업데이트 - 수정 버전: - **7.0.2**: 두 취약점 모두 해결 - **6.9.5**: 두 취약점 모두 해결 - **6.8.6**: SQL 인젝션만 해결 - **7.1 Beta 2**: 두 취약점 모두 해결 - WordPress 보안팀은 이를 최고 심각도·최우선순위 문제로 분류하고 영향을 받는 사이트에 자동 업데이트를 강제하고 있습니다. - 자동 업데이트가 실행되었더라도 실제 설치 버전이 수정 버전인지 확인해야 합니다. ### Cloudflare WAF 차단 규칙 - Cloudflare는 2026년 7월 17일 17:03 UTC에 두 규칙을 배포했습니다. - 두 규칙 모두 기본 동작은 **Block**입니다. - SQL 인젝션 규칙: - CVE: `CVE-2026-60137` - Managed Ruleset ID: `1c060d3a371549219ee290d7ed933fcc` - Free Ruleset ID: `db003b39b7774859a8d588ce33697a1a` - 원격 코드 실행 규칙: - CVE: `CVE-2026-63030` - Managed Ruleset ID: `7dfb2bd4708d4b88b9911dc0550664b6` - Free Ruleset ID: `ebd3f2df15c74ddcbf6220c9b5ec246a` - Pro, Business, Enterprise 고객은 Cloudflare Managed Rules가 활성화되어 있는지 확인해야 합니다. - Free 요금제는 Free Ruleset을 통해 자동으로 보호됩니다. - 규칙 전체를 `Log`로 변경하는 규칙셋 수준 오버라이드가 있다면 제거하거나, 해당 규칙을 권장 동작인 `Block`으로 설정해야 합니다. ### 두 단계의 방어와 모니터링 - SQL 인젝션 규칙은 악성 파라미터가 WordPress에 도달하기 전에 탐지합니다. - RCE 규칙은 원격 코드 실행 경로에 접근하려는 요청을 차단합니다. - Cloudflare **Security Events**에서 두 규칙과 일치하는 요청을 확인해야 합니다. - 즉시 업데이트할 수 없는 경우에도 규칙이 활성화되어 있고 `Block` 상태인지 확인한 뒤, 관련 REST API 엔드포인트에 대한 의심스러운 요청을 조사해야 합니다. - WAF는 취약한 WordPress 코드를 수정하지 않으므로 패치를 대체할 수 없습니다. ### 향후 대응 - Cloudflare는 탐지된 트래픽을 지속적으로 분석하고 새로운 공격 변형에 맞춰 규칙을 업데이트할 예정입니다. - WordPress 운영자는 수정 버전으로 업데이트하고, WAF 차단 규칙과 보안 이벤트 로그를 함께 점검하는 방식으로 방어 계층을 구성하는 것이 권장됩니다.

원문 읽기(새 탭에서 열림)

rest-apicloudflarevulnerability-managementweb-application-firewall+3

netflix·2026년 6월 19일·4분 읽기큐레이션 요약

데이터 카나리아: 넷플릭스는 카탈로그 메타데이터를 어떻게 검증하는가

넷플릭스는 코드 변경이 없어도 카탈로그 데이터 자체가 손상되면 수백만 명의 재생 경험이 즉시 영향을 받을 수 있다는 점을 확인했다. 이에 실제 운영 트래픽으로 새 데이터 버전을 검증하는 데이터 카나리 시스템을 구축했고, 10분 이내에 문제를 감지해 배포를 차단한다. 핵심은 최종 변환 결과를 별도 카나리 클러스터에서 검증하고, 실제 재생 시도량을 기준으로 이상 여부를 빠르게 판단하는 것이다. ## 카탈로그 메타데이터 손상으로 발생한 장애 - 넷플릭스의 카탈로그 메타데이터는 타이틀, artwork, 제공 지역, 재생 가능 여부 등을 정의한다. - 과거 장애 대응 과정에서 실행된 수동 완화 조치가 데이터 피드를 비워 버렸고, 일부 타이틀의 메타데이터가 손상됐다. - 코드나 설정 변경이 없었기 때문에 기존 코드 카나리 배포는 문제를 감지하지 못했다. - 손상된 메타데이터로 manifest 생성이 실패하면서 카탈로그 서비스와 재생 기능에 장애가 발생했다. - 각 upstream 데이터 소스에는 검증 로직이 있었지만, 여러 입력을 변환한 최종 출력 상태의 오류까지는 잡지 못했다. ## 데이터 배포에 필요한 새로운 검증 방식 - 카탈로그 데이터는 여러 입력 피드를 지속적으로 변환하고 짧은 주기로 배포하는 고속 데이터 파이프라인이다. - 기존 카나리 분석 도구는 통계적 신뢰도를 확보하는 데 30~60분이 필요해 데이터 배포 주기와 맞지 않았다. - 입력 데이터가 정상이어도 변환 이후의 최종 상태에서 문제가 발생할 수 있으므로, 실제 클라이언트가 소비하는 출력물을 검증해야 했다. - shadow traffic은 카탈로그 서비스 요청만 재현할 뿐, 여러 서비스가 연동되는 전체 재생 과정을 검증할 수 없었다. - 운영 트래픽을 사용하되, 문제가 발생하면 고객 영향 범위를 즉시 제한할 수 있어야 했다. ## 전용 데이터 카나리 오케스트레이터 - 별도의 카나리 전용 클러스터와 오케스트레이터를 구축해 데이터 검증과 일반 서비스 운영을 분리했다. - **Baseline 클러스터** - 현재 운영 중인 최신 카탈로그 버전을 지속적으로 제공한다. - **Canary 클러스터** - 새 카탈로그 버전을 받아 검증한다. - **오케스트레이터** - baseline과 canary 클러스터의 상태 및 버전 동기화를 확인한다. - 조건이 충족되면 카오스 실험을 시작한다. - 실험 결과를 REST endpoint로 transformer 서비스에 전달한다. - 이 REST 기반의 일반화된 연동 지점 덕분에 다른 데이터 소스도 transformer 코드를 수정하지 않고 유사한 검증 패턴을 적용할 수 있다. ## 카오스 플랫폼을 활용한 실시간 검증 - 10분 이내 검증을 위해 기존 카오스 플랫폼을 확장하고, 실험 임계값을 데이터 카나리 목적에 맞게 조정했다. - 클라이언트 유형별로 트래픽 패턴과 downstream 의존성이 다르므로 주요 tenant마다 별도 실험을 수행했다. - 특히 playback 요청을 처리하는 tenant의 트래픽이 오류를 가장 빠르게 발견했다. - **Sticky canary** - 세션 affinity를 사용해 한 사용자의 트래픽이 실험 중 baseline 또는 canary 중 한쪽에만 계속 연결되도록 한다. - 두 데이터 버전의 결과가 섞이는 것을 막아 공정한 비교가 가능하다. - 기술 지표보다 실제 사용자 행동에 가까운 **Starts Per Second(SPS)** 를 핵심 지표로 사용했다. - 메타데이터 오류는 카탈로그 서비스의 latency나 error rate를 높이지 않고도 재생 시도 자체를 감소시킬 수 있기 때문이다. - 통계 수집이 끝날 때까지 기다리지 않고, 실시간으로 지표를 스트리밍하며 회귀가 감지되는 즉시 실험을 중단한다. - 이는 통계적 확실성을 일부 줄이는 대신, 짧은 배포 주기 안에 문제를 차단하는 속도를 우선한 설계다. ## 운영 환경을 고려한 예외 처리 - 오케스트레이터가 재배포 중 재시작되더라도 진행 중인 카오스 실험을 찾아 계속 polling하도록 했다. - 여러 오케스트레이터 인스턴스가 동시에 실행될 수 있으므로 leader election과 중복 실행 방지 장치를 적용했다. - 한 버전 공지에 대해 실험이 한 번만 실행되도록 보장했다. - 클라이언트별 데이터 소비 주기가 다르기 때문에 baseline과 canary의 버전 상태를 추적하고, 두 클러스터가 올바르게 정렬된 경우에만 실험을 시작한다. ## 의도적인 장애 주입으로 검증 - 시스템의 효과를 확인하기 위해 실제로 카탈로그 데이터를 의도적으로 손상시키는 통제된 실험을 수행했다. - 고관심 타이틀을 denylist에 넣는 등 실제 장애와 유사한 데이터 손상 상황을 재현했다. - 이러한 실패 주입 실험을 통해 실제 재생 트래픽과 SPS 지표가 회귀를 감지하고, 잘못된 데이터 버전이 회원에게 확산되기 전에 중단되는지 검증했다. 데이터 파이프라인도 코드 배포와 마찬가지로 최종 산출물 기준의 카나리 검증이 필요하다. 특히 사용자 영향이 직접 반영되는 지표를 선택하고, 운영 트래픽을 격리된 환경에서 비교하며, 이상 징후가 나타나는 즉시 중단하는 구조가 고속 데이터 배포에 효과적이다.

원문 읽기(새 탭에서 열림)

rest-apidata-pipelineschaos-engineeringdata-canary+3

github·2026년 5월 7일·4분 읽기큐레이션 요약

GitHub 에이전틱 워크플로의 토큰 효율성 향상

GitHub Agentic Workflows는 반복 실행되는 CI 자동화인 만큼 토큰 비용이 누적되기 쉬우며, YAML과 실행 로그를 분석하면 이를 체계적으로 줄일 수 있다. GitHub는 토큰 사용량을 표준화해 수집하고, 감사·최적화 워크플로를 통해 불필요한 MCP 도구를 제거하거나 GitHub CLI로 대체했다. 그 결과 동작을 바꾸지 않고도 요청당 수천 토큰을 절약할 수 있었다. ## 토큰 사용량을 표준화해 기록 - Claude CLI, Copilot CLI, Codex CLI 등 에이전트 프레임워크마다 로그 형식이 달라 사용량 비교가 어려웠다. - 인증 정보를 에이전트에 직접 노출하지 않도록 사용하는 API 프록시를 활용해 모든 실행의 토큰 사용량을 한 형식으로 수집했다. - 각 워크플로는 `token-usage.jsonl` 아티팩트를 생성한다. - API 호출별 입력 토큰 - 출력 토큰 - 캐시 읽기·쓰기 토큰 - 모델과 제공업체 - 호출 시각 - 실행 로그와 이 데이터를 결합해 워크플로별 일반적인 토큰 소비 패턴과 이상 실행을 파악했다. ## 감사·최적화 워크플로로 자동 개선 - **Daily Token Usage Auditor** - 최근 실행의 토큰 사용량을 워크플로별로 집계한다. - 사용량이 급증한 워크플로, 비용이 큰 워크플로, 비정상적인 실행을 탐지한다. - 예를 들어 평소 4번의 LLM 턴으로 끝나던 작업이 18턴까지 늘어난 경우를 표시한다. - **Daily Token Optimizer** - 감사 결과가 나온 워크플로의 YAML과 최근 로그를 분석한다. - 불필요한 동작과 구체적인 최적화 방안을 GitHub Issue로 제안한다. - 감사·최적화 도구 자체도 에이전트 워크플로이므로 사용량을 함께 측정할 수 있고, 이를 통해 개선 작업이 반복되는 순환 구조를 만든다. ## 사용하지 않는 MCP 도구 제거 - LLM API는 상태를 유지하지 않기 때문에 MCP 도구의 함수명과 JSON 스키마가 매 요청에 포함되는 경우가 많다. - GitHub MCP 서버의 도구가 40개라면 매 턴마다 10~15KB의 스키마가 추가될 수 있다. - 실제로 두 도구만 사용하는 에이전트라면 나머지 38개 도구의 스키마는 매번 순수한 오버헤드가 된다. - 도구 설정과 실제 호출 기록을 대조하면 장기간 사용되지 않은 도구를 식별할 수 있다. - 스모크 테스트에서는 사용하지 않는 MCP 도구를 제거해 요청당 컨텍스트를 8~12KB 줄였고, 동작 변경 없이 실행당 수천 토큰을 절약했다. ## 데이터 조회를 GitHub CLI로 대체 MCP 호출은 단순한 데이터 조회에도 LLM의 판단 과정을 요구한다. - 에이전트가 도구를 선택하고 인자를 구성한 뒤 결과를 받는 과정 전체가 추가 LLM 호출이 된다. - 이 과정에서 도구 스키마, 인자 JSON, 응답 데이터가 모두 토큰을 소비한다. - 반면 `gh pr diff` 같은 GitHub CLI 명령은 결정적인 API 요청이므로 LLM 추론 단계가 필요 없다. GitHub는 두 가지 방식으로 MCP 데이터 조회를 CLI로 옮겼다. - **에이전트 실행 전 데이터 다운로드** - 항상 필요한 PR diff, 변경 파일 목록 등을 에이전트 시작 전에 `gh` 명령으로 가져온다. - 결과를 작업 공간 파일에 저장하고 에이전트가 파일을 읽도록 한다. - MCP 호출과 별도 추론 라운드트립을 제거하며, 에이전트가 Bash 도구를 활용해 데이터를 효율적으로 처리할 수 있다. - **에이전트 내부 CLI 프록시** - 실행 중 어떤 데이터를 가져올지 에이전트가 결정해야 하는 경우 사용한다. - 인증 토큰을 노출하지 않는 투명 HTTP 프록시가 CLI 요청을 GitHub API로 전달한다. - 에이전트는 `gh pr view --json` 같은 명령을 실행하고 구조화된 결과를 받는다. - 보안상 “에이전트에 비밀정보를 직접 제공하지 않는다”는 원칙을 유지하면서 토큰 사용량을 줄인다. ## 효율성 측정에서 고려할 요소 단순히 토큰 개수만 비교하면 최적화 효과를 정확히 판단하기 어렵다. - 모델별 토큰 가격이 다르다. - Claude Haiku와 Sonnet은 비슷한 토큰 수를 사용할 수 있지만 Haiku가 토큰당 약 4배 저렴하다. - 이를 반영하기 위해 모델과 토큰 종류에 가중치를 적용한 **Effective Tokens(ET)** 지표를 사용한다. ```text ET = m × (1.0 × I + 0.1 × C + 4.0 × O) ``` - `m`: 모델 비용 배수 - Haiku = 0.25 - Sonnet = 1.0 - Opus = 5.0 - `I`: 새로 처리한 입력 토큰 - `C`: 캐시에서 읽은 토큰 - `O`: 출력 토큰 - 출력 토큰은 입력 토큰보다 비용 영향이 크므로 4배 가중치를 적용한다. - 따라서 최적화가 토큰 수를 줄였는지뿐 아니라, 더 저렴한 모델을 사용했는지와 작업 품질을 유지했는지도 함께 평가해야 한다. 반복 실행되는 에이전트 워크플로는 먼저 사용량을 관측하고, 실제 사용 도구만 남기며, 결정적인 데이터 조회를 CLI나 사전 다운로드로 이동하는 방식이 효과적이다. 특히 MCP를 편리하다는 이유로 전체 등록하기보다 워크플로별 최소 도구만 구성하고, ET 같은 비용 반영 지표로 품질 저하 없이 최적화되는지 검증하는 것이 권장된다.

원문 읽기(새 탭에서 열림)

rest-api대규모 언어 모델모델 컨텍스트 프로토콜GitHub Actions+3

gitlab·2026년 5월 7일·3분 읽기큐레이션 요약

유출된 개인 액세스 토큰 하나로 소유자가 접근할 수 있는 모든 프로젝트가 노출되어서는 안 됩니다. 세분화된 PAT는 각 토큰의 권한을 해당 작업에 맞게 제한합니다.

GitLab은 개인 액세스 토큰(PAT)을 작업별·리소스별로 제한하는 세분화된 PAT를 베타로 공개했습니다. 토큰이 특정 프로젝트의 특정 리소스에서 필요한 작업만 수행하도록 설정해, 유출 시 피해 범위를 전체 계정이 아닌 해당 작업과 프로젝트로 줄이는 것이 핵심입니다. 다만 현재 REST API의 약 75%만 지원하므로 정식 출시 전까지는 운영 환경 사용을 권장하지 않습니다. ## 광범위한 PAT의 보안 위험 - `api`나 `read_api`처럼 넓은 범위의 스코프는 사용자가 접근 가능한 여러 프로젝트와 그룹에 권한을 부여합니다. - 하나의 토큰으로 소스 코드 조회, 파이프라인 수정, 컨테이너 레지스트리 접근, CI/CD 변수 복호화 등을 모두 수행할 수 있습니다. - 토큰이 유출되면 공격자가 해당 사용자가 접근 가능한 전체 프로젝트를 악용할 수 있습니다. - 토큰의 권한이 특정 작업이 아니라 사용자 계정에 묶여 있어 피해 범위가 커집니다. ## 작업별 최소 권한 부여 - 세분화된 PAT는 자동화 작업마다 별도의 토큰을 발급하는 방식입니다. - 토큰이 접근할 수 있는 범위를 다음처럼 지정할 수 있습니다. - 개인 프로젝트만 - 사용자가 속한 모든 프로젝트와 그룹 - 선택한 특정 프로젝트와 그룹 - 접근 가능한 리소스별로 권한을 독립 설정할 수 있습니다. - Issues - Merge Requests - Pipelines - Repositories - Container Registry 등 - 각 리소스에 대해 `Create`, `Read`, `Update`, `Delete` 권한을 개별적으로 부여합니다. ## 컨테이너 레지스트리 활용 예시 - 컨테이너 이미지를 빌드하고 업로드하는 파이프라인에는 전체 `api` 토큰 대신 특정 프로젝트의 Container Registry용 토큰을 발급합니다. - 해당 토큰에는 필요한 `Create`와 `Read` 권한만 부여할 수 있습니다. - 토큰이 유출되어도 피해 범위는 전체 프로젝트나 계정이 아닌 해당 프로젝트의 컨테이너 레지스트리로 제한됩니다. ## 토큰 감사와 추가 보호 장치 - 토큰 목록 화면에서 기존 PAT와 세분화된 PAT의 전체 스코프 및 리소스별 권한을 확인할 수 있습니다. - 과도한 권한을 가진 토큰을 보안 검토 중 쉽게 식별할 수 있습니다. - 토큰 만료 기간 제한과 자동 폐기 기능을 함께 사용하면 도난된 토큰의 악용 시간을 줄일 수 있습니다. - 작업별 토큰을 사용하면 유출 이후 조사와 대응 범위도 해당 작업과 프로젝트로 좁힐 수 있습니다. ## 베타 단계의 지원 범위와 제한 - 세분화된 PAT는 현재 REST API 엔드포인트의 약 75%를 지원합니다. - 향후 나머지 REST API와 GraphQL 지원 범위를 확대할 예정입니다. - 정식 출시 전까지는 프로덕션 워크로드에 사용하지 않는 것이 권장됩니다. - 베타 기간에는 기존 PAT와 세분화된 PAT를 동시에 생성해 호환성과 권한 모델을 평가할 수 있습니다. ## 생성 방법 - **User Settings → Personal Access Tokens**로 이동합니다. - **Generate token** 메뉴에서 **Fine-grained token**을 선택합니다. - 접근 가능한 프로젝트·그룹과 리소스별 권한을 설정합니다. - 지원 리소스와 관리자 제어 항목은 GitLab의 세분화된 PAT 문서에서 확인할 수 있습니다. 실무에서는 자동화 작업마다 별도 토큰을 만들고, 특정 프로젝트와 필요한 리소스의 최소 권한만 부여하는 방식이 권장됩니다. 베타 기간에는 프로덕션 적용을 피하고, 먼저 테스트 환경에서 기존 PAT와의 호환성 및 API 지원 범위를 검증하는 것이 안전합니다.

원문 읽기(새 탭에서 열림)

rest-apigitlabGraphQLapi-security+3

slack·2026년 5월 5일·4분 읽기큐레이션 요약

SSH에서 REST로: Slack EMR 데이터 파이프라인의 보안 주도 현대화

Slack은 700개가 넘는 EMR 데이터 파이프라인을 직접 SSH로 실행하던 구조에서 REST 기반 작업 제출 방식으로 전환했다. SSH는 보안 공격 표면, 키 관리, 장애 복구, 작업 관측성 측면에서 한계가 있었고 Spark on Kubernetes와 AWS 계정 분리 같은 현대화도 가로막았다. Slack은 YARN REST API와 YARN Distributed Shell을 활용해 8개 데이터 리전의 작업을 중단 없이 마이그레이션하고 SSH를 완전히 제거했다. ## SSH 기반 파이프라인의 확산 - 2017년경 Airflow가 EMR 마스터 노드에 SSH로 접속해 명령을 실행하는 방식으로 데이터 파이프라인을 구축했다. - 단순한 `SSHOperator` 패턴이 확산되면서 다음과 같은 작업까지 SSH로 실행됐다. - Spark 및 MapReduce 작업 - AWS CLI 명령 - 사용자 정의 Python 스크립트 - 2024년에는 700개 이상의 운영 작업이 SSH 기반으로 실행되고 있었다. - 검색 인덱싱, 분석, 비즈니스 인텔리전스 등 핵심 데이터 처리도 이 구조에 의존했다. ## SSH의 보안 및 운영상 문제 - **보안 위험** - 오케스트레이션 워커가 EMR 클러스터에 직접 SSH 접속해야 해 공격 표면이 커졌다. - SSH 키를 여러 워커에 배포하고 주기적으로 교체해야 했다. - 세밀한 감사 추적을 위해 여러 시스템의 로그를 상호 연관해야 했다. - 보안 그룹과 사용자 권한 설정이 복잡해졌다. - **운영 장애** - 작업이 EMR 마스터 노드에서 직접 실행되어 리소스 경쟁이 발생했다. - Kubernetes Pod가 재시작되면 SSH 연결이 끊겨 작업이 실패했다. - 연결이 끊긴 뒤에도 작업이 계속 실행되는 ‘좀비 작업’이 남을 수 있었다. - 연결 단절 후 작업의 성공·실패 상태를 안정적으로 확인하기 어려웠다. - **인프라 현대화 차단** - Spark on Kubernetes와 EMR on EKS 도입을 시작할 수 없었다. - 메인 AWS 계정의 EMR 클러스터를 자식 계정으로 이전하는 Whitecastle 프로젝트가 지연됐다. - 신뢰할 수 있는 작업 모니터링과 관측성을 구현하기 어려웠다. ## REST 기반 작업 제출의 장점 - SSH는 클라이언트와 서버 사이의 상태ful 연결을 유지해야 한다. - REST 방식에서는 작업의 생명주기를 서버가 관리한다. - `POST`: 작업을 제출하고 작업 ID를 받음 - `GET`: 작업 ID로 실행·완료·실패 상태를 조회 - `DELETE`: 필요할 때 작업을 취소 - Airflow나 Kubernetes Pod가 재시작되어도 작업 자체는 서버에서 계속 실행될 수 있다. - 클라이언트가 작업 상태를 다시 조회할 수 있어 연결 단절에 강하다. - 작업 취소, 리소스 관리, 로그 확인 등도 실행 엔진의 표준 기능으로 처리할 수 있다. ## YARN Distributed Shell을 활용한 해결책 - Spark는 Livy REST API, Hive는 HiveServer2를 사용할 수 있어 상대적으로 이전이 쉬웠다. - 반면 MapReduce와 `aws s3 sync`, `hadoop distcp` 같은 300개 이상의 임의 CLI 작업은 바로 사용할 REST API가 없었다. - 검토한 대안은 다음과 같았다. - 원격 명령 실행용 커스텀 래퍼 서비스 - Ansible이나 Salt 같은 원격 실행 프레임워크 - YARN에 새로운 작업 유형을 직접 개발 - 이러한 방법은 별도 보안 계층과 운영 인프라를 구축·유지해야 해 복잡도가 높았다. - YARN의 **Distributed Shell**은 임의의 셸 스크립트를 YARN 컨테이너에서 실행할 수 있도록 했다. - 기존 YARN REST API를 그대로 사용 - YARN의 인증·인가 체계 활용 - 별도 보안 서비스 불필요 - 오픈소스 표준 기반 - 컨테이너 리소스와 작업 생명주기 관리 지원 ## Distributed Shell의 실행 흐름 - 실행할 셸 스크립트를 S3에 업로드한다. - 예: `s3://bucket/command.sh` - 스크립트는 `aws s3 sync` 같은 임의 명령을 포함할 수 있다. - YARN REST 요청에 Distributed Shell의 `ApplicationMaster`와 스크립트 위치를 지정한다. - YARN이 컨테이너를 할당하고 S3에서 스크립트를 내려받아 실행한다. - 실행 과정에서 YARN이 다음을 담당한다. - 메모리와 vCore 등 리소스 제한 - 컨테이너 격리 - 재시도와 장애 복구 - 정상적인 작업 취소 - YARN UI를 통한 로그 및 상태 확인 ## 마이그레이션의 의미 - YARN Distributed Shell을 통해 REST API가 없던 CLI·MapReduce 작업까지 동일한 실행 모델로 통합할 수 있었다. - 작업 제출과 실행을 SSH 연결에서 분리해 클라이언트 재시작과 네트워크 단절에 대한 안정성을 높였다. - 700개 이상의 작업을 8개 데이터 리전에 걸쳐 중단 없이 이전하면서 SSH 의존성을 제거했다. - 결과적으로 보안 강화뿐 아니라 Kubernetes 기반 실행 환경, AWS 계정 분리, 표준화된 모니터링으로 나아갈 기반을 마련했다. 실용적으로는 원격 서버에 직접 접속해 명령을 실행하기보다, 작업 ID·상태 조회·취소를 제공하는 서버 측 실행 모델을 사용하는 것이 바람직하다. 특히 기존 작업이 단순 CLI 스크립트라면 복잡한 신규 실행 서비스를 만들기 전에 YARN Distributed Shell처럼 기존 플랫폼의 표준 기능을 우선 검토할 수 있다.

원문 읽기(새 탭에서 열림)

rest-api쿠버네티스apache-sparkapache-airflow+3

cloudflare·2026년 4월 30일원문

이제 에이전트가 Cloudflare 계정을 만들고 도메인을 구매하고 배포할 수 있습니다 (새 탭에서 열림)

이제 AI 에이전트는 사람이 직접 대시보드에 접속하거나 신용카드 정보를 입력할 필요 없이, 스스로 클라우드플레어 계정을 생성하고 도메인을 구매하여 서비스를 배포할 수 있게 되었습니다. 클라우드플레어는 스트라이프(Stripe)와의 협업을 통해 '스트라이프 프로젝트(Stripe Projects)' 내에서 작동하는 새로운 프로토콜을 도입했으며, 이를 통해 에이전트가 소프트웨어 개발을 넘어 프로덕션 환경 구축까지 원스톱으로 처리할 수 있는 환경을 마련했습니다. 사용자는 최초의 권한 승인과 이용 약관 동의 외에는 복잡한 설정 과정에 개입할 필요가 없어 서비스 배포의 마찰력이 획기적으로 줄어들었습니다. **에이전트의 완전 자동화된 배포 흐름** * 사용자가 스트라이프 CLI를 통해 프로젝트를 초기화하면, AI 에이전트는 사용자의 스트라이프 계정 정보를 바탕으로 클라우드플레어 계정을 자동 생성하거나 기존 계정을 연결합니다. * 에이전트는 API 토큰을 발급받고, 도메인을 등록하며, 코드를 즉시 프로덕션 환경에 배포하는 모든 과정을 스스로 수행합니다. * 이 모든 과정은 사람이 대시보드에 들어가 API 토큰을 복사하거나 결제 수단을 수동으로 등록하는 단계 없이 하나의 흐름으로 진행됩니다. **상호운용성을 위한 세 가지 핵심 구성 요소** * **발견(Discovery):** 에이전트는 REST API 형태의 카탈로그를 조회하여 클라우드플레어의 도메인 등록과 같은 사용 가능한 서비스를 스스로 파악하고 선택할 수 있습니다. * **인증(Authorization):** 스트라이프가 신원 제공자(Identity Provider) 역할을 수행하여 사용자를 증명하면, 클라우드플레어는 즉시 계정을 프로비저닝하고 보안이 유지되는 자격 증명을 에이전트에게 반환합니다. * **결제(Payment):** 에이전트에게 실제 카드 번호를 공유하지 않고 스트라이프의 결제 토큰을 사용하며, 기본적으로 월 100달러의 지출 한도를 설정하여 예기치 못한 비용 발생을 방지합니다. **플랫폼 확정성 및 스타트업 지원** * 이 프로토콜은 스트라이프뿐만 아니라 로그인된 사용자를 보유한 어떤 플랫폼이든 '오케스트레이터' 역할을 맡아 클라우드플레어와 통합할 수 있도록 설계되었습니다. * 클라우드플레어는 이번 협업을 기념하여 스트라이프 아틀라스(Stripe Atlas)를 통해 법인을 설립하는 신규 스타트업에게 10만 달러 상당의 클라우드플레어 크레딧을 제공합니다. * 이를 통해 개발자들은 인프라 설정이라는 번거로운 작업에서 벗어나 AI 에이전트와 함께 아이디어를 프로덕션 수준의 서비스로 더욱 빠르게 전환할 수 있습니다. 에이전트 중심의 개발 환경을 구축하려는 개발자나 플랫폼 운영자라면 클라우드플레어의 'Code Mode MCP 서버'와 'Agent Skills'를 활용해 보시기 바랍니다. 인프라 구축의 모든 단계가 API화되어 있으므로, 사용자의 개입을 최소화하면서도 안전하고 확장 가능한 배포 자동화 시스템을 구현할 수 있습니다.

rest-api데이터베이스 설계cloudflarestripe+4

cloudflare·2026년 4월 16일원문

아티팩트: Git 방식으로 작동하는 버전 관리 저장소 (새 탭에서 열림)

AI 에이전트가 생성하는 코드와 데이터의 양이 기하급수적으로 증가함에 따라, 기존의 소스 제어 플랫폼은 인간의 작업 속도를 상회하는 대규모 수요를 감당하기 어려워지고 있습니다. Cloudflare는 이러한 문제를 해결하기 위해 AI 에이전트 중심의 분산 버전 관리 파일 시스템인 'Artifacts'를 출시했습니다. Artifacts는 익숙한 Git 프로토콜을 기반으로 하면서도 API를 통해 수백만 개의 리포지토리를 프로그래밍 방식으로 즉시 생성하고 제어할 수 있는 새로운 저장소 프리미티브를 제공합니다. ### AI 에이전트에 최적화된 Git 인터페이스 * AI 모델들이 이미 학습 데이터로 익숙하게 습득한 Git 프로토콜을 그대로 사용하여, 별도의 CLI나 기술 전파 없이도 에이전트가 즉시 소스 제어를 수행할 수 있습니다. * 에이전트 세션마다 독립적인 리포지토리를 할당하거나, 특정 시점에서 수만 개의 포크(Fork)를 생성하여 병렬적으로 작업을 수행하는 것이 가능합니다. * 서버리스 환경과 같이 표준 Git 클라이언트를 사용하기 어려운 곳을 위해 REST API와 네이티브 Workers API를 별도로 제공하여 커밋과 자격 증명 관리를 단순화합니다. ### 단순 소스 제어를 넘어선 상태 관리 도구 * Git의 데이터 모델을 코드 저장뿐만 아니라 세션 프롬프트 히스토리, 샌드박스 상태, 사용자별 설정(Config) 등 시간 흐름에 따른 상태 추적이 필요한 모든 곳에 활용합니다. * Cloudflare 내부적으로는 에이전트 세션마다 Artifacts 리포지토리를 할당하여, 블록 스토리지 없이도 파일 시스템 상태를 영구 저장하고 특정 시점으로의 타임트래블(복구) 기능을 구현하고 있습니다. * 세션 자체를 포크(Fork)하여 동료와 공유하거나, 특정 실험 단계에서부터 다시 작업을 시작하는 등의 협업 워크플로우를 데이터 계층에서 지원합니다. ### Durable Objects와 Zig 기반의 고성능 아키텍처 * Cloudflare의 Durable Objects를 기반으로 설계되어 수천만 개의 독립적인 상태 저장 인스턴스를 확장성 있게 관리할 수 있습니다. * 런타임 효율성을 극대화하기 위해 Git 구현체를 Zig 언어로 작성한 뒤 WebAssembly(Wasm)로 컴파일하여 Cloudflare Workers 환경에서 가볍고 빠르게 동작하도록 구축했습니다. * 기존 외부 Git 저장소(예: GitHub)에서 데이터를 가져오는 `.import()` 기능과 읽기 전용 포크 생성 기능을 통해 복잡한 코드 베이스 위에서도 에이전트가 안전하게 독립적인 작업을 수행할 수 있도록 돕습니다. AI 에이전트가 주도하는 소프트웨어 개발 환경을 구축하고 있다면, Artifacts는 대규모 상태 관리와 버전 제어를 위한 가장 강력한 인프라가 될 것입니다. 현재 유료 Workers 플랜 사용자를 대상으로 프라이빗 베타를 진행 중이며, 5월 초 공개 베타 전환이 예정되어 있으므로 에이전트 세션 관리나 동적 환경 구축이 필요한 팀은 도입을 적극 검토해 보시기 바랍니다.

rest-api데이터베이스 설계TypeScriptCloudflare Workers+4

cloudflare·2026년 4월 16일원문

Cloudflare 이메일 서비스: 이제 퍼블릭 베타로 제공됩니다. 에이전트를 위한 준비 완료 (새 탭에서 열림)

Cloudflare Email Service가 퍼블릭 베타로 전환되며, AI 에이전트가 이메일을 주요 인터페이스로 활용할 수 있는 포괄적인 인프라를 제공합니다. 개발자는 이 서비스를 통해 별도의 API 키 관리나 복잡한 인증 설정 없이 Workers 내에서 직접 이메일을 수신, 처리 및 전송할 수 있는 환경을 구축할 수 있습니다. 결과적으로 이메일은 단순한 알림 수단을 넘어, 에이전트가 비동기적으로 복잡한 작업을 수행하고 사용자와 소통하는 독립적인 실행 채널로 진화하게 되었습니다. ### 이메일 전송 기능의 퍼블릭 베타 전환과 편의성 * **네이티브 Workers 바인딩:** Workers 내에서 `env.EMAIL.send`와 같은 간단한 코드로 이메일을 즉시 발송할 수 있으며, 복잡한 API 키나 시크릿 관리가 필요 없습니다. * **다양한 환경 지원:** Workers뿐만 아니라 REST API를 비롯해 TypeScript, Python, Go 언어용 SDK를 통해 어떤 플랫폼에서든 이메일 발송 기능을 연동할 수 있습니다. * **자동화된 도메인 인증:** 이메일 도달률의 핵심인 SPF, DKIM, DMARC 레코드를 Cloudflare가 자동으로 구성하여, 보낸 메일이 스팸으로 분류되지 않도록 관리합니다. * **글로벌 네트워크 활용:** Cloudflare의 전 세계적인 네트워크를 통해 지연 시간을 최소화하며 안정적인 전송 성능을 보장합니다. ### 이메일 기반 에이전트(Agentic Email)로의 진화 * **비동기적 작업 수행:** 실시간으로 즉시 응답해야 하는 챗봇과 달리, 에이전트는 이메일을 수신한 후 데이터를 처리하고 외부 시스템을 조회하는 등 장시간의 작업을 독립적으로 수행한 뒤 결과를 회신할 수 있습니다. * **Agents SDK 연동:** Agents SDK의 `onEmail` 훅을 사용하면 수신된 이메일을 기반으로 에이전트의 상태를 업데이트하거나 비동기 워크플로우를 트리거하는 것이 용이합니다. * **주소 기반 라우팅:** 특정 이메일 주소(예: support@example.com)를 특정 에이전트 인스턴스에 연결하는 주소 기반 리졸버를 통해 복잡한 로직 없이도 개별 에이전트에게 작업을 배분할 수 있습니다. ### 에이전트 구축을 위한 통합 툴킷 제공 * **새로운 도구 지원:** 효율적인 개발을 위해 Wrangler CLI용 이메일 명령어와 에이전트용 Email MCP(Model Context Protocol) 서버를 새롭게 도입했습니다. * **레퍼런스 앱 활용:** 오픈 소스로 공개된 'Agentic Inbox' 레퍼런스 앱을 통해 에이전트 전용 편지함과 워크플로우를 어떻게 구성하는지 구체적인 가이드를 얻을 수 있습니다. * **양방향 이메일 자동화:** 기존의 Email Routing(수신)과 신규 Email Sending(발신)을 결합하여, Cloudflare 플랫폼 내에서 이메일의 수신-처리-응답으로 이어지는 완전한 자동화 파이프라인을 완성했습니다. 기존의 복잡한 서드파티 이메일 API 연동이나 SMTP 설정에서 벗어나고 싶은 개발자에게 이번 퍼블릭 베타는 훌륭한 대안이 될 것입니다. 특히 고객 지원 시스템이나 인보이스 처리와 같이 비동기적인 워크플로우가 필수적인 AI 에이전트를 개발 중이라면, Cloudflare의 통합 개발 플랫폼을 활용해 인프라 관리 부담을 획기적으로 줄여보시길 추천합니다.

rest-apiTypeScriptPythonGo+4

airbnb·2026년 2월 11일원문

나의 에어비앤비 입 (새 탭에서 열림)

안나 술키나(Anna Sulkina)는 20년 이상의 경력을 가진 엔지니어링 리더로, 하드웨어 진단에서 시작해 프론트엔드와 백엔드를 거쳐 현재 에어비앤비의 인프라 및 클라우드 부문을 이끌고 있습니다. 그녀는 트위터 재직 당시 대규모 분산 시스템의 기술적 한계를 극복하고 조직적 합의를 통해 GraphQL 도입을 성공시킨 경험을 바탕으로, 기술적 역량과 리더십의 조화를 강조합니다. 현재 그녀는 에어비앤비에서 개발자 플랫폼의 전략적 방향성을 설정하고 고성과 팀을 구축하여 비즈니스 가치를 극대화하는 데 전념하고 있습니다. ### 기술적 호기심의 시작과 초기 경력의 도전 * 소련 붕괴 시기 우크라이나에서 성장하며, 컴퓨터 하드웨어를 조립하던 오빠의 영향으로 기술에 대한 호기심을 키웠습니다. * 미국 이주 초기에는 프로그래밍 언어보다 영어 소통에 더 큰 어려움을 겪었으나, 버클리 익스텐션 등을 통해 C++과 Java 지식을 확장하며 전문성을 쌓았습니다. * 첫 직장인 하드웨어 진단 분야를 시작으로 기술 스택의 아래 단계로 점진적으로 내려가며 하드웨어, 프론트엔드, 백엔드를 아우르는 폭넓은 시각을 갖게 되었습니다. ### 리더십으로의 전환과 팀 구축의 즐거움 * 개인 기여자(IC)로서의 역량뿐만 아니라 리더십 잠재력을 인정받아 텔레콤 스타트업과 컴캐스트(Comcast)를 거치며 엔지니어링 매니저로 성장했습니다. * 좋은 리더가 있는 팀과 그렇지 않은 팀의 차이를 직접 목격하며 사람을 코칭하고 고성과 팀을 만드는 과정에서 큰 흥미를 느꼈습니다. * 기술 스택의 깊이가 깊어질수록 리더십의 책임 또한 커지는 궤적을 그리며 인프라 부문의 리더로 자리매김했습니다. ### 트위터에서의 분산 시스템 설계와 기술 혁신 * 약 9년 동안 트위터에 재직하며 'Fail Whale' 시기와 엘런 디제너러스의 셀카 사건 등 대규모 트래픽 장애를 해결하는 핵심적인 역할을 수행했습니다. * **실패를 위한 설계:** 모놀리스 구조에서 마이크로서비스 아키텍처로 전환하며, 복잡한 분산 시스템에서는 실패를 피하는 것이 아니라 '실패를 대비한 설계'가 필수적임을 배웠습니다. * **합의를 통한 혁신:** 해커톤에서 시작된 GraphQL 도입을 위해 전사적인 기술적 합의를 이끌어냈으며, 이는 기존 REST 서비스를 대체하고 제품 개발 속도를 획기적으로 높이는 결과로 이어졌습니다. ### 에어비앤비에서의 전략적 정렬과 플랫폼 고도화 * 평소 여행을 좋아하고 에어비앤비 서비스의 팬이었던 점이 이직의 결정적 계기가 되었으며, 개인적 관심사와 기술적 전문성을 일치시켰습니다. * **개발자 플랫폼 개선:** 파편화되어 있던 개발자 플랫폼 조직의 전략을 명확히 하고, 내부 이해관계자들과의 신뢰를 구축하는 데 집중했습니다. * **조직적 정렬:** "우리는 왜 여기에 모였는가?"와 같은 근본적인 질문에 답하며 리더십 코칭과 팀 간 정렬을 통해 비즈니스 가치를 창출하는 고성과 조직을 재정비했습니다. 안나 술키나의 여정은 복잡한 시스템일수록 기술적 완벽주의보다는 실패를 수용하는 유연한 설계가 중요하다는 점을 시사합니다. 또한, 기술적 혁신은 단순히 뛰어난 코드로 완성되는 것이 아니라, 조직 내의 합의를 이끌어내고 구성원들의 목표를 하나로 정렬하는 리더십을 통해 비로소 실현될 수 있음을 보여줍니다.

rest-api분산 시스템마이크로서비스Java+3

toss·2025년 11월 27일원문

토스페이먼츠의 Open API 생태계 (새 탭에서 열림)

토스페이먼츠는 Open API를 단순한 통신 수단을 넘어 수십 년간 안정적으로 운영되어야 할 핵심 인프라로 정의합니다. 20만 개 이상의 가맹점이 사용하는 환경에서 개발자의 인지 부하를 줄이고 연동 신뢰성을 높이기 위해, 리소스 중심의 인터페이스 설계와 자동화된 생태계 구축을 최우선 과제로 삼고 있습니다. 이러한 철학은 기술적 완성도를 넘어 가맹점 개발자가 겪는 전반적인 경험(DX)의 질을 결정짓는 근간이 됩니다. ### 리소스 중심의 일관된 인터페이스 설계 * **직관적인 경로 규칙**: 가맹점이 URL 구조만 보고도 기능을 예측할 수 있도록 `버전/도메인/리소스 고유 ID` 순서의 일관된 경로 체계를 사용합니다. 특정 리소스 지정 외의 조건은 쿼리 파라미터나 JSON 필드로 분리하여 명확성을 높였습니다. * **중첩 객체를 활용한 모듈화**: 카드 정보나 현금영수증 내역처럼 여러 API에서 반복되는 데이터는 JSON의 계층 구조를 활용해 객체 형태로 모듈화합니다. 이는 데이터 중복을 줄이고 응답의 의미를 명확하게 전달하며, null 체크 등 가맹점의 코드 로직을 간소화합니다. * **도메인별 객체 재사용**: 승인, 조회, 취소 등 연관된 도메인의 API들이 동일한 응답 객체를 공유하도록 설계하여, 개발자가 새로운 API를 연동할 때 추가적인 학습 없이 결과를 예측할 수 있게 합니다. * **자연어 기반 데이터 표현**: 시스템 효율을 위한 코드 값(예: SC0010) 대신 "현대", "국민"과 같은 직관적인 한글 데이터를 제공합니다. 또한 `Accept-Language` 헤더에 따라 영문 등으로 응답을 자동 전환하는 로컬라이제이션(Localization)을 지원합니다. * **표준화된 오류 처리**: HTTP 상태 코드로 큰 틀의 성공/실패를 구분하고, 상세한 에러 코드와 메시지를 담은 표준 객체를 응답 바디에 포함하여 가맹점이 상황에 맞춰 유연하게 대응할 수 있도록 돕습니다. ### 비동기 처리를 위한 안정적인 웹훅 체계 * **이벤트 기반 처리**: 즉각적인 응답이 어려운 비동기 결제 상황에서 서버가 클라이언트에 처리 완료를 알리는 웹훅 인터페이스를 API와 함께 제공합니다. * **데이터 구조의 일관성**: 웹훅을 통해 전달되는 데이터 페이로드를 일반 API 응답과 동일한 리소스 객체 구조로 설계하여 가맹점의 파싱 로직 중복을 방지합니다. * **지수 백오프(Exponential Backoff) 재전송**: 네트워크 이슈나 가맹점 서버 장애로 인한 웹훅 전송 실패 시, 수신 서비스의 회복 시간을 고려하여 점진적으로 재시도 간격을 늘리는 전략을 사용합니다. * **자가 조치 도구 제공**: 개발자가 직접 웹훅 전송 내역을 조회하고 필요 시 수동으로 재전송할 수 있는 기능을 개발자 센터를 통해 지원하여 운영 편의성을 높였습니다. ### 개발자 경험(DX) 강화를 위한 문서 자동화 * **OAS 기반 실시간 동기화**: 수동 문서 작성의 한계를 극복하기 위해 OpenAPI Specification(OAS)과 Springdoc 라이브러리를 활용하여 서버 코드와 문서가 실시간으로 동기화되는 시스템을 구축했습니다. * **문서의 신뢰성 확보**: API 스펙이 변경될 때마다 연동 문서가 즉시 업데이트되므로, 가맹점 개발자는 항상 실제 동작하는 서버와 일치하는 최신 명세를 바탕으로 안심하고 개발할 수 있습니다. 토스페이먼츠의 사례처럼 좋은 Open API는 단순히 기능의 유무를 넘어, 개발자가 '설명 없이도 이해할 수 있는' 직관적인 구조와 자동화된 지원 환경을 갖추어야 합니다. 특히 리소스 중심 설계와 API-웹훅 간 데이터 일관성은 가맹점의 연동 비용을 획기적으로 낮추는 실용적인 전략이 될 수 있습니다.

rest-apiAPI 설계jsondeveloper-experience+4

figma·2024년 11월 20일·4분 읽기큐레이션 요약

피그마 패턴 라이브

UI3 개편은 Figma 내부 디자인 시스템이 오랜 성장 과정에서 파편화되었다는 문제를 드러냈고, 이를 해결하기 위해 Figma Pattern Library(FPL)를 처음부터 다시 구축하게 만들었습니다. 디자이너와 엔지니어가 페어 프로그래밍에 가까운 방식으로 협업해 디자인 의도와 코드 구현을 연결하고, 변수·REST API·테마 모드를 기반으로 일관되고 접근성 높은 제품 개발의 기반을 마련했습니다. FPL은 단순한 컴포넌트 모음이 아니라 조직 전체의 공통 언어이자 UI3를 확장하기 위한 단일 진실 공급원으로 설계되었습니다. ## UI3가 드러낸 내부 디자인 시스템의 문제 - Figma는 다른 팀의 디자인 시스템 구축을 돕는 제품을 만들고 있었지만, 내부 시스템은 오랜 기간의 급속한 성장과 제품 확장으로 분리되어 있었습니다. - 동일해야 할 컴포넌트가 서로 조금씩 달랐고, 연결이 끊긴 컴포넌트 인스턴스가 누적되었습니다. - UI3를 모든 Figma 제품에 적용하려면 새로운 화면 디자인만으로는 부족했습니다. - 여러 팀이 일관되고 효율적으로 작업할 수 있는 견고한 기반 시스템이 필요했습니다. ## 디자이너와 엔지니어의 페어 협업 - Wayne Sun과 Tom Williams는 디자이너와 엔지니어로 구성된 5명의 소규모 팀을 만들었습니다. - 개발에서 한 사람이 코드를 작성하고 다른 사람이 실시간 검토하는 페어 프로그래밍처럼, 디자이너와 엔지니어가 긴밀하게 짝을 이루어 작업했습니다. - 디자이너는 시각적·사용자 경험 의도를 전달하고, 엔지니어는 이를 실제 컴포넌트와 토큰 시스템으로 구현했습니다. - 이 방식은 디자인 파일과 제품 코드 사이의 간극을 줄이고, 양쪽이 공유할 수 있는 시스템 언어를 만드는 데 목적이 있었습니다. - 그 결과 새로운 내부 디자인 시스템인 Figma Pattern Library(FPL)가 탄생했습니다. ## 스타일과 스프레드시트에서 변수 중심 구조로 전환 - 기존 시스템은 Figma의 변수 기능이 등장하기 전에 만들어졌습니다. - 디자이너는 Figma 스타일을 사용했지만, 엔지니어는 별도의 Google Sheets에서 색상 토큰을 관리했습니다. - 스프레드시트가 제품 변경 사항을 즉시 반영하지 못하면서 디자인 파일과 실제 코드의 색상이 달라지는 문제가 발생했습니다. - 팀은 Figma 변수와 REST API를 활용해 디자인과 코드가 자동으로 동기화될 수 있는 구조를 만들었습니다. - 타이포그래피 변수를 새로 만들고, 기존 타이포그래피 스타일이 이 변수들을 별칭으로 참조하도록 구성했습니다. - 색상 스타일은 중앙 관리가 가능한 색상 변수로 마이그레이션했습니다. - 색상 변수에 CSS 정의도 추가해 Dev Mode의 검사 패널에서 개발자가 올바른 변수명과 코드 표현을 확인할 수 있게 했습니다. ## Primitive와 Semantic 변수로 색상 체계 정리 - 색상은 밝기와 어두움이 체계적으로 이어지는 **color ramp**를 기반으로 구성했습니다. - 기본 색상 단위인 **Primitive 변수**는 색상 계열별로 정리하고, 100부터 1000까지 단계적으로 구분했습니다. - 실제 UI 용도를 나타내는 **Semantic 변수**는 Primitive 변수를 별칭으로 참조합니다. - 예를 들어 특정 색상값을 직접 사용하는 대신 배경, 텍스트, 테두리 같은 의미 기반 변수로 연결할 수 있습니다. - Semantic 변수는 다음과 같은 테마와 제품별 모드를 지원하도록 설계되었습니다. - 라이트 모드와 다크 모드 - Figma Design - FigJam - Slides - Dev Mode - 이 구조 덕분에 하나의 공통 컴포넌트가 제품이나 테마에 따라 색상만 자연스럽게 바꿀 수 있습니다. - Primitive 변수의 값을 수정하면 이를 참조하는 Semantic 변수와 컴포넌트에 변경 사항을 일괄 적용할 수 있습니다. ## FPL의 역할 - FPL은 UI3의 시각적 스타일을 정의하는 동시에, 이를 실제 제품에 일관되게 구현하기 위한 기술적 기반입니다. - 디자인과 엔지니어링을 분리된 단계로 처리하지 않고, 초기 설계부터 함께 검증하는 협업 모델을 채택했습니다. - 변수와 모드 기반의 구조는 여러 제품과 테마를 지원하면서도 공통된 사용자 경험을 유지하도록 돕습니다. - 중앙화된 토큰과 컴포넌트는 중복 구현과 미세한 시각적 차이를 줄이고, 향후 변경 사항을 더 빠르게 확산시킬 수 있습니다. FPL 사례는 디자인 시스템을 단순한 UI 컴포넌트 저장소가 아니라 디자인 토큰, 테마, 코드 연동, 협업 방식까지 포함하는 조직의 공통 인프라로 다뤄야 한다는 점을 보여줍니다. 특히 디자인 파일과 코드가 서로 다른 토큰을 관리하지 않도록 변수와 자동 동기화를 도입하는 것이 규모가 큰 제품 조직에 실용적인 출발점입니다.

원문 읽기(새 탭에서 열림)

rest-apiFigma디자인 시스템접근성+4

figma·2024년 4월 15일·3분 읽기큐레이션 요약

카바나가 일관성과 확장성을

Carvana는 Figma의 디자인 시스템과 변수를 활용해 빠른 성장 속에서도 제품 경험의 일관성과 확장성을 유지했다. 분산된 디자인 도구를 Figma로 통합해 단일 기준을 만들고, 변수와 테마 기능으로 디자인·개발 협업과 브랜드 확장을 효율화했다. 그 결과 반복 작업과 수정이 줄고, 새로운 사업 영역에도 기존 디자인 언어를 빠르게 적용할 수 있었다. ## 성장에 대응하는 단일 기준 마련 - Carvana는 2019년 성장세가 가속화되면서 확장 가능한 디자인 플랫폼이 필요해졌다. - 기존 디자인 시스템은 PDF 기반 UI 키트, Principle, Sketch 등 여러 도구에 흩어져 있었다. - 컴포넌트를 복사해 사용하는 방식 때문에 동일한 요소가 조금씩 변형됐고, 디자인과 개발팀이 참조할 중앙 기준이 없었다. - Figma로 디자인 시스템을 이전하면서 디자인·개발팀이 함께 참조할 수 있는 연결된 단일 소스 오브 트루스를 구축했다. - 코로나19 시기 차량 판매가 급증했을 때도 통합된 시스템 덕분에 기존 도구에서 발생하던 협업 마찰을 줄이고 수요에 대응할 수 있었다. - 약 40명의 디자인 시스템 팀이 1만 명 규모의 회사 전반에 디자인 품질을 확산시키는 역할을 담당했다. ## 변수로 디자인 일관성과 효율성 강화 - 제품 생태계가 커지면서 색상, 간격, 타이포그래피, 모서리 반경이 화면과 컴포넌트마다 달라지는 문제가 발생했다. - Figma 변수는 색상이나 수치처럼 재사용 가능한 값을 정의하고 여러 디자인 속성에 적용할 수 있게 했다. - 특히 숫자 변수를 활용해 spacing과 corner radius를 일관된 값으로 관리했다. - 변수의 값을 중앙에서 정의하면 디자이너가 픽셀 수준의 정확성을 유지하면서도 반복적인 수정 작업을 줄일 수 있다. - 초기에는 변수 설정과 학습에 비용이 들었지만, 결과적으로 디자인 완성도가 높아지고 리뷰 과정에서 되돌아오는 수정 사항이 감소했다. - 변수 기반 시스템은 장기적으로 디자이너의 반복 작업과 리비전을 줄여 효율을 높인다. ## 테마 기능으로 인수 사업 통합 - Carvana가 자동차 경매 기업 ADESA를 인수한 뒤에도 변수는 새로운 브랜드 테마를 빠르게 도입하는 데 활용됐다. - 컴포넌트의 구조와 기능은 유지하면서 변수 값만 바꾸어 ADESA 전용 색상과 스타일을 적용할 수 있었다. - 기존 방식이라면 새 스타일에 맞춰 컴포넌트 라이브러리를 다시 구축하는 데 최소 한 달이 걸렸을 작업을, 변수 기반 테마로 1주일 이내에 처리했다. - ADESA용 디자인 시안을 평소보다 약 3배 빠르게 제작할 수 있었다. - 브랜드 변경을 개별 컴포넌트의 재작업이 아니라 테마 전환으로 처리함으로써 여러 화면 너비와 제품 영역에 일관되게 적용할 수 있었다. ## 디자인과 개발 간 연결 강화 - Figma 기반 디자인 시스템은 디자이너와 개발자가 동일한 컴포넌트와 변수 기준을 참조하도록 돕는다. - 중앙화된 라이브러리와 변수는 디자인 변경 사항을 일관되게 관리하고 핸드오프 과정의 마찰을 줄이는 기반이 된다. - 글에서는 변수와 Figma REST API를 활용한 개발 연계 및 변수 마이그레이션 사례도 소개한다. Carvana 사례는 성장하는 조직일수록 디자인 시스템을 여러 파일이나 도구에 분산시키기보다 단일 기준으로 통합해야 한다는 점을 보여준다. 특히 색상·간격·브랜드 스타일을 변수와 테마로 관리하면 제품 확장이나 인수 이후의 리브랜딩도 빠르고 안정적으로 수행할 수 있다.

원문 읽기(새 탭에서 열림)

rest-apiFigma디자인 시스템사용자 경험+4

figma·2023년 6월 20일원문

Config 2023 다시 보기 (새 탭에서 열림)

Figma는 Config 2023을 통해 단순한 디자인 도구를 넘어 디자인과 개발의 경계를 허물고 전체 제품 개발 팀이 함께 협업할 수 있는 통합 플랫폼으로의 진화를 선언했습니다. 이를 위해 개발자 전용 워크스페이스인 '개발 모드(Dev Mode)'와 코드의 논리를 디자인에 이식하는 '변수(Variables)', 그리고 실질적인 제품 작동 방식을 구현하는 '고급 프로토타이핑' 기능을 새롭게 도입했습니다. 이번 업데이트는 디자인 결과물이 실제 제품 코드로 전환되는 과정을 가속화하고, 팀 간의 소통 방식을 근본적으로 재정의하는 데 목적이 있습니다. ### 개발자 경험을 최적화하는 개발 모드(Dev Mode) * **개발자 전용 워크스페이스:** 무한한 캔버스 내에서 개발자가 작업에 필요한 구조와 기능을 직관적으로 파악할 수 있는 별도의 모드를 제공합니다. * **코드 번역 및 검사:** 디자인 요소를 코드로 더 빠르게 변환할 수 있으며, Jira, GitHub, Storybook과 같은 주요 개발 도구 및 코드베이스와 플러그인을 통해 직접 연결됩니다. * **VS Code 통합:** 'Figma in VS Code'를 통해 개발 환경을 벗어나지 않고도 에디터 바로 옆에서 디자인 파일을 검사하고 협업할 수 있습니다. * **배포 추적:** 어떤 디자인 요소가 프로덕션에 반영되어야 하는지 상태를 추적하여 디자인과 개발 간의 누락을 방지합니다. ### 디자인 시스템의 유연성을 극대화하는 변수(Variables) * **디자인 토큰의 코드화:** 색상, 숫자, 텍스트, 불리언(Boolean) 값을 변수로 저장하여 디자인 시스템을 코드의 언어와 일치시킵니다. * **모드(Modes) 지원:** 라이트 모드와 다크 모드, 혹은 다양한 테마 간의 전환을 변수 값을 통해 손쉽게 토글하며 테스트할 수 있습니다. * **확장성 있는 관리:** 에일리어싱(Aliasing) 및 스코핑(Scoping)을 지원하며, REST API와 플러그인을 통해 변수 생성 및 관리 프로세스를 자동화할 수 있습니다. ### 논리적 흐름을 구현하는 고급 프로토타이핑 * **조건부 로직 및 표현식:** "특정 변수가 X일 때 프레임 2로 이동"과 같은 조건문이나 수학적 표현식을 활용하여 실제 앱과 유사한 복잡한 상호작용을 구현할 수 있습니다. * **효율적인 프로토타입 제작:** 수많은 화면을 직접 연결할 필요 없이 변수를 활용해 동적인 변화를 줄 수 있어 프로토타입 제작 시간이 단축됩니다. * **인라인 프리뷰:** 디자인 편집 화면과 프로토타입 미리보기 화면을 동시에 띄워두고 수정한 내용을 즉각적으로 확인할 수 있어 반복 작업의 효율이 높아졌습니다. ### 워크플로우 개선을 위한 편의 기능(Quality of Life) * **오토 레이아웃 고도화:** 요소가 넘치면 다음 줄로 넘겨주는 '줄 바꿈(Wrap)' 기능과 최소/최대 너비 및 높이 설정 기능이 추가되었습니다. * **글꼴 선택기 업그레이드:** 글꼴 이름을 해당 서체로 미리 볼 수 있는 기능과 검색 및 필터링 기능이 강화되어 원하는 폰트를 더 빠르게 찾을 수 있습니다. * **파일 브라우저 업데이트:** 외부 팀과 공유된 프로젝트나 파일을 더 쉽게 찾을 수 있도록 인터페이스가 개선되었습니다. ### AI 기술을 통한 디자인의 미래 확장 * **Diagram 인수:** AI 기반 디자인 도구를 개발해온 Diagram을 인수하여 Figma 플랫폼 전반에 AI 기능을 통합할 계획입니다. * **창작 보조 및 가속:** AI가 시각적 표현을 돕고 워크플로우를 가속화하며, 누구나 수준 높은 초안을 만들 수 있도록 지원함으로써 디자인의 진입장벽을 낮추고자 합니다. Figma의 이번 업데이트는 디자이너와 개발자가 서로 다른 언어를 사용하는 문제를 해결하는 데 집중하고 있습니다. 개발 모드를 통해 개발자는 디자인 의도를 명확히 파악하고, 디자이너는 변수와 로직을 활용해 실제 제품에 가까운 설계를 할 수 있게 되었습니다. 팀의 생산성을 높이기 위해 현재 베타 버전으로 제공되는 개발 모드를 프로젝트에 적극적으로 도입하고, 기존 디자인 시스템을 변수(Variables) 기반으로 전환하여 다국어나 테마 대응 효율을 높여보시길 권장합니다.

rest-apiFigma디자인 시스템프로토타이핑+4

figma·2023년 2월 2일·3분 읽기큐레이션 요약

핀터레스트 디자인

Pinterest의 Gestalt 디자인 시스템은 코드 사용량만으로는 전체 채택 현황을 파악하기 어렵다고 보고, Figma 안에서 디자이너들이 컴포넌트를 얼마나 사용하는지 측정하는 ‘디자인 채택률’을 도입했다. 코드 지표는 웹 플랫폼에 한정되고 실제 디자인 단계보다 늦게 나타나는 반면, Figma 지표는 웹·iOS·Android를 아우르며 초기 사용 신호를 제공한다. 이를 위해 Figma REST API 기반의 대시보드 FigStats를 만들어 컴포넌트 사용량을 전체 디자인 요소 대비 상대적으로 분석했다. ## 코드 채택률만으로는 부족한 이유 - Gestalt은 웹뿐 아니라 iOS와 Android용 디자인 컴포넌트도 제공하지만, 기존 코드 채택률은 웹 컴포넌트만 측정했다. - 새 컴포넌트가 실제 제품 코드에 도입되기까지 시간이 걸리므로, 코드 지표에는 채택 지연이 발생한다. - 디자이너가 컴포넌트를 사용하지 않으면 개발자도 해당 컴포넌트의 존재나 필요성을 알기 어렵다. - 따라서 디자인 시스템 채택은 제품 코드 단계가 아니라 디자인 단계부터 시작된다는 관점이 필요하다. ## Figma에서 디자인 채택을 측정하는 이유 - Pinterest 디자이너들의 작업은 Figma에서 이루어지므로, 디자인 시스템 사용 현황을 가장 이른 단계에서 확인할 수 있다. - Figma에서 Gestalt 컴포넌트가 사용되면 웹·iOS·Android 전반에서 향후 코드 컴포넌트를 구축할 근거로 활용할 수 있다. - 디자이너가 실제로 컴포넌트를 사용하는지 확인하면 디자인 시스템 투자 효과와 플랫폼별 개발 우선순위를 설명하기 쉬워진다. ## 단순한 인스턴스·삽입 횟수의 한계 - Figma 기본 라이브러리 분석은 팀별 컴포넌트 인스턴스 수와 삽입 횟수를 제공한다. - 예를 들어 버튼이 수십만 번 사용됐다는 사실은 알 수 있지만, 그 수치가 건강한 채택 수준인지는 판단하기 어렵다. - 대형 파일에 노드가 1,000개 있고 Gestalt 컴포넌트가 10개뿐이라면, 사용량은 존재하지만 전체 디자인의 1%에 불과하다. - 따라서 절대적인 사용 횟수보다 전체 디자인 요소 중 디자인 시스템 컴포넌트가 차지하는 비율이 더 유용한 지표가 된다. ## FigStats와 상대적 채택률 - Gestalt 팀은 Figma REST API를 사용해 FigStats라는 내부 대시보드를 구축했다. - 대시보드는 Figma 파일을 분석해 어떤 Gestalt 컴포넌트가 어느 팀과 파일에서 사용되는지 시각화한다. - 핵심은 컴포넌트 인스턴스 수 자체가 아니라, 전체 노드 또는 디자인 요소 중 Gestalt 컴포넌트가 차지하는 비중을 계산하는 것이다. - 이를 통해 파일 규모가 서로 달라도 디자인 시스템이 실제 작업에 얼마나 깊이 적용됐는지 비교할 수 있다. - 컴포넌트별 사용 현황을 보면 널리 사용되는 컴포넌트와 거의 사용되지 않는 컴포넌트를 구분할 수 있으며, 개선이나 교육이 필요한 영역도 찾을 수 있다. ## 채택 데이터의 활용 - 채택률은 디자인 시스템 팀이 제공하는 가치와 투자 대비 효과를 리더십에 설명하는 공통 언어가 된다. - 사용률이 낮은 컴포넌트는 문서화 부족, 발견성 문제, API나 시각적 설계의 불편함 때문일 수 있다. - 디자인 단계에서 사용이 확인된 컴포넌트는 향후 코드 컴포넌트로 구현할 때 우선순위를 정하는 근거가 된다. - 코드 채택률과 디자인 채택률을 함께 보면 디자인에서 제품 출시까지의 채택 흐름과 지연 구간을 파악할 수 있다. ## Figma 분석 기능의 확장 - 글 작성 당시 Figma 기본 분석은 주로 컴포넌트 인스턴스와 삽입 데이터를 제공했다. - 이후 Figma Library Analytics는 스타일과 변수 데이터까지 포함하도록 확장되었고, Enterprise 고객은 Library Analytics API를 활용할 수 있게 됐다. - 따라서 현재는 컴포넌트뿐 아니라 스타일·변수까지 포함해 조직 전체의 디자인 시스템 채택을 분석할 수 있다. 디자인 시스템의 성공을 평가할 때 단순한 사용 횟수만 보지 말고, 전체 디자인 대비 사용 비율과 플랫폼별 채택 흐름을 함께 측정하는 것이 좋다. 특히 Figma의 디자인 채택률과 코드 채택률을 연결하면 어떤 컴포넌트가 실제 제품으로 이어지는지 더 정확하게 판단할 수 있다.

원문 읽기(새 탭에서 열림)

rest-apiFigma디자인 시스템data-analytics+2