techlist.io
KREN

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

aws4분 읽기큐레이션 요약

Amazon SQS 20주년: 대규모 환경에서 20년간 이어온 안정적인 메시징 | Amazon Web Services

Amazon SQS는 서비스 간 결합도를 낮추고 장애 전파를 막기 위해 메시지를 비동기적으로 전달하는 AWS의 관리형 메시지 큐 서비스다. 출시 20년 동안 FIFO 고처리량, 암호화 기본 적용, DLQ 복구, 대규모 메시지 처리 등 기능이 크게 발전했지만, 서비스 간 분리·트래픽 버퍼링·장애 격리라는 핵심 역할은 변하지 않았다. 최근에는 멀티테넌트 시스템과 AI 에이전트·추론 워크로드에도 활용 범위가 확대되고 있다. ## 비동기 메시징을 통한 서비스 결합도 완화 - 서비스가 서로 직접 호출하면 호출 대상의 지연이나 장애가 연쇄적으로 전체 시스템에 영향을 줄 수 있다. - SQS를 사용하면 생산자는 메시지를 큐에 저장한 뒤 작업을 계속하고, 소비자는 처리 가능한 시점에 메시지를 가져갈 수 있다. - 이를 통해 다음과 같은 효과를 얻는다. - 서비스 간 의존성 및 결합도 감소 - 트래픽 급증 시 메시지 큐를 버퍼로 활용 - 특정 서비스 장애가 전체 시스템으로 확산되는 것을 방지 - 소비자의 처리 속도에 맞춘 안정적인 작업 처리 ## FIFO 큐의 처리량과 동시성 향상 - 2021년 FIFO 큐 고처리량 모드가 출시되며 API 작업당 초당 3,000건(TPS)을 지원했다. - 이후 처리량이 단계적으로 증가했다. - 2022년: 6,000 TPS - 2023년 8월: 9,000 TPS - 2023년 10월: 18,000 TPS - 2023년 11월: 일부 리전에서 최대 70,000 TPS - 2024년에는 FIFO 큐의 인플라이트 메시지 한도가 20,000개에서 120,000개로 증가했다. - 소비자가 동시에 처리할 수 있는 메시지가 늘어나 대규모 순서 보장 처리에 유리해졌다. ## 암호화와 세분화된 접근 제어 - 2021년 SQS 관리형 키를 사용하는 서버 측 암호화 방식인 SSE-SQS가 도입됐다. - 2022년 10월부터 새로 생성되는 큐에는 SSE-SQS가 기본 적용됐다. - 고객이 직접 암호화 키를 생성하고 관리하지 않아도 메시지를 보호할 수 있다. - 2022년에는 ABAC(Attribute-Based Access Control)가 추가됐다. - 큐의 고정된 리소스 정책 대신 태그를 기준으로 권한을 부여할 수 있다. - 큐와 환경이 늘어나는 대규모 시스템에서 권한 정책 관리 부담을 줄인다. ## DLQ 메시지 복구 기능 강화 - 처리에 실패한 메시지를 보관하는 Dead-Letter Queue(DLQ)에서 원래 큐로 메시지를 되돌리는 기능이 단계적으로 확대됐다. - 2021년에는 SQS 콘솔에서 DLQ 메시지를 소스 큐로 직접 재전송할 수 있게 됐다. - 2023년에는 SDK와 CLI에서도 다음 API를 사용할 수 있게 됐다. - `StartMessageMoveTask`: 메시지 이동 작업 시작 - `CancelMessageMoveTask`: 이동 작업 취소 - `ListMessageMoveTasks`: 이동 작업 목록 조회 - 같은 해 FIFO 큐에도 redrive 기능이 지원됐다. - 운영 중 실패한 메시지를 수동으로 재처리하거나 별도 개발 없이 복구할 수 있다. ## 메시지 처리 성능과 연동성 개선 - 2023년 AWS SDK에 JSON 프로토콜 지원이 추가됐다. - 5KB 페이로드 기준 종단 간 처리 지연을 최대 23% 줄이고, 클라이언트의 CPU·메모리 사용량도 낮췄다. - SQS 콘솔에서 EventBridge Pipes와 큐를 직접 연결할 수 있게 됐다. - 별도의 통합 코드를 작성하지 않고도 큐 메시지를 다양한 AWS 서비스 대상으로 라우팅할 수 있다. ## 대용량 메시지와 페이로드 확장 - 2024년 Python용 Extended Client Library가 제공됐다. - 최대 2GB 크기의 메시지를 Amazon S3에 저장하고, SQS에는 해당 데이터의 참조 정보만 전달할 수 있다. - 2025년에는 표준 큐와 FIFO 큐의 최대 메시지 크기가 256KiB에서 1MiB로 증가했다. - AWS Lambda의 SQS 이벤트 소스 매핑도 이 새로운 페이로드 크기를 지원하도록 업데이트됐다. ## 멀티테넌트 환경을 위한 공정한 처리 - 2025년 표준 큐에 fair queues가 도입됐다. - 메시지를 보낼 때 메시지 그룹 ID를 포함하면 특정 테넌트가 큐를 독점하는 ‘시끄러운 이웃(noisy neighbor)’ 문제를 완화할 수 있다. - 소비자 측 코드를 변경하지 않고도 한 테넌트의 대량 메시지가 다른 테넌트의 처리 지연을 유발하는 상황을 줄일 수 있다. ## AI 시스템으로 확장되는 SQS의 활용 - SQS의 기본 패턴은 AI 워크로드에도 적용된다. - 활용 사례는 다음과 같다. - 대규모 언어 모델 요청을 큐에 저장해 추론 요청량 조절 - 추론 처리량을 소비자 수와 처리 속도에 맞춰 관리 - 독립적으로 동작하는 AI 에이전트 간 작업과 통신 조정 - AI 서비스가 일시적으로 느려지거나 중단돼도 요청을 큐에 보관해 전체 시스템의 안정성을 유지할 수 있다. 실무에서는 서비스 간 직접 호출이 장애 전파나 트래픽 급증 문제를 일으키는 경우 SQS를 우선 검토할 수 있다. 순서 보장과 중복 처리 방지가 필요하면 FIFO 큐를, 실패 메시지 복구가 중요하면 DLQ와 redrive 기능을 함께 설계하는 것이 좋다.

원문 읽기(새 탭에서 열림)
AWS분산 시스템amazon-s3amazon-sqs+4
aws5분 읽기큐레이션 요약

AWS 주간 정리: 1주년을 맞은 AWS Builder Center, Security Hub의 네트워크 스캐닝, AWS용 Loom 등 (2026년 7월 13일) | Amazon Web Services

AWS Builder Center가 출범 1주년을 맞아 샌드박스, 워크숍, 커뮤니티 기능을 갖춘 AWS 학습·개발 생태계로 확장됐다. 동시에 AWS Security Hub의 네트워크 스캐닝 및 Azure 지원, SageMaker와 Hugging Face 통합, GPU 관리 비용 인하, Aurora DSQL CDC 정식 출시 등 주요 서비스 업데이트가 발표됐다. AWS는 보안·AI 에이전트·멀티클라우드 관리 기능을 통합해 개발 편의성과 운영 자동화를 강화하는 방향을 보이고 있다. ## AWS Builder Center의 1년 성장 - 2025년 7월 9일 출시 이후 커뮤니티 허브에서 종합 개발자 생태계로 확장됐다. - 주요 기능: - AWS 리전별 서비스 현황 - 커뮤니티가 직접 만드는 Spaces - 카테고리·난이도별 워크숍 - 배지와 연속 활동 기록 - 아티클 시리즈, 조회 수, 저장 항목 - 학생 상태 및 서비스 출시 알림 - GitHub·Amazon 계정 로그인 - 무료 샌드박스 환경 - 5,548명의 작성자가 6,448개 아티클을 게시했으며, 누적 조회 수는 1,040만 회를 넘었다. - 2026년 3월 배지 시스템 출시 후 약 99,226개의 배지가 발급됐다. - 사용자 요청 565건 중 10건이 실제 출시됐고, 20건은 단기 로드맵에 포함됐다. - 인기 글: - MCP와 Strands Agents SDK 기반 AWS Study Buddy: 5만 회 이상 - Kiro를 활용한 EOL Linux 서버 AWS 이전: 4만 5천 회 이상 - 신경 질환 조기 검사를 위한 멀티모달 AI: 3만 8천 회 이상 ## 8시간짜리 무료 AWS 샌드박스 - 워크숍 실습을 위해 사전 구성된 무료 AWS 계정을 제공한다. - 개인 AWS 계정, 신용카드, 수동 리소스 정리가 필요 없다. - 환경은 최대 8시간 동안 활성화되며 이후 계정과 리소스가 자동으로 제거된다. - 한 번에 하나의 샌드박스만 사용할 수 있고, 주 1회 신청할 수 있다. - AWS 서비스를 안전하게 실습하거나 교육용 워크숍을 진행하는 데 적합하다. ## Security Hub의 네트워크 및 멀티클라우드 보안 - **Network Scanning**은 실제 인터넷에서 리소스에 접근 가능한지를 직접 확인한다. - AWS와 Azure 환경에서 다음 리소스를 탐색한다. - 공용 IP 주소 - 가상 머신 - 로드 밸런서 - 접근 가능한 포트와 해당 포트에서 실행 중인 서비스를 식별한다. - 접근 가능한 포트마다 발견 근거와 함께 Security Hub finding을 생성한다. - 기존 네트워크 도달 가능성 분석이 “도달 가능하게 만들 수 있는 구성”을 찾는다면, Network Scanning은 실제 인터넷 도달 여부를 검증한다. - Security Hub Exposures가 관련 설정 및 보안 결과를 결합해 전체적인 위험도를 계산한다. - 신규 고객에게는 기본 활성화되며, 기존 고객은 계정·리전별 또는 조직 정책으로 활성화할 수 있다. - Security Hub Essentials에 추가 비용 없이 포함된다. - Azure 리소스도 자동 검색해 다음 항목을 통합 관리한다. - VM, 컨테이너 이미지, Function Apps, ID - 설정 오류, 인터넷 노출, 소프트웨어 취약점 - AWS와 Azure의 보안 결과를 동일한 형식과 자동화 흐름으로 한 화면에서 관리할 수 있다. ## SageMaker Studio와 Hugging Face 통합 - Hugging Face에서 모델을 선택한 뒤 한 번의 클릭으로 SageMaker Studio에서 커스터마이즈하거나 배포할 수 있다. - 지원 모델에는 다음 작업 흐름이 제공된다. - SageMaker에서 모델 커스터마이즈 - SageMaker 또는 Bedrock 엔드포인트 배포 - 모델 평가 - 사용자 정의 보상 함수를 활용한 강화학습 파인튜닝 - 신규 고객은 사전 구성된 권한과 환경을 갖춘 Studio를 빠르게 생성할 수 있다. - 검증된 고객은 별도 쿼터 증액 요청 없이 G5, G6, G4dn GPU 인스턴스에 기본 접근할 수 있다. - Studio 내부에서 GPU 쿼터 사용량도 확인할 수 있다. ## GPU 관리 비용 인하 - 2026년 7월 1일부터 EKS Auto Mode와 ECS Managed Instances의 가속 인스턴스 관리 비용이 자동으로 인하된다. - 인하 폭: - G 계열: 35% - P 계열 및 AWS Trainium: 60% - 기존 클러스터에도 자동 적용되며 별도 작업이 필요 없다. - EKS Auto Mode: - GPU 인스턴스의 병렬 이미지 풀링 - 로컬 NVMe 기반 가속 워크로드 지원 - 가속기 상태를 인식한 노드 복구 - ECS Managed Instances: - CloudWatch Container Insights 기반 GPU 메트릭 - GPU 하드웨어 장애 자동 모니터링 ## Aurora DSQL의 변경 데이터 캡처 - Aurora DSQL CDC가 정식 출시됐다. - INSERT, UPDATE, DELETE 결과를 변경 이벤트로 만들어 Amazon Kinesis Data Streams에 전송한다. - 활용 사례: - 마이크로서비스 간 데이터 동기화 - Lambda 함수 트리거 - Firehose를 통한 S3, Redshift, OpenSearch Service 전달 - 데이터베이스 워크로드 성능에 영향을 주지 않도록 설계됐다. - CDC 인프라를 별도로 구축하거나 운영할 필요가 없다. ## AWS용 Loom과 안전한 AI 에이전트 운영 - Loom은 AWS Strands Agents와 Amazon Bedrock AgentCore Runtime 기반 에이전트를 구축·배포하는 오픈소스 엔터프라이즈 플랫폼이다. - 제공 기능: - 통합 관리 UI와 백엔드 API - ID 공급자 연동 - 범위 기반 권한 제어 - 멀티 페르소나 탐색 - 에이전트, 메모리, MCP 서버, 에이전트 간 연동의 전체 수명주기 관리 - 멀티테넌트 환경을 위해 RBAC와 ABAC를 지원한다. - 리소스 태깅을 자동화해 비용을 사용자·팀별로 추적할 수 있다. - 표준화된 배포 블루프린트, AWS Agent Registry 연동, 민감한 작업 전 사람의 검토 절차도 제공한다. - AWS Labs GitHub에서 프로젝트를 확인할 수 있다. ## Claude 애플리케이션 접근 제어 - Claude Code와 Claude Desktop에 대한 접근, 비용, 정책을 중앙에서 관리하는 자체 호스팅 게이트웨이가 소개됐다. - OIDC 호환 ID 공급자와 연동하며, 모든 요청에 관리형 설정을 적용한다. - Amazon Bedrock 또는 AWS 기반 Claude Platform으로 추론 요청을 라우팅할 수 있다. - 사용자·그룹별 지출 한도를 설정할 수 있다. - 프라이빗 네트워크의 무상태 컨테이너로 실행되며, PostgreSQL은 단기 로그인 상태만 저장한다. - 개발자 장비에 장기 보안 키를 저장하지 않는 방식으로 보안을 강화한다. ## AWS MCP Server의 OAuth 지원 - AWS Console이나 CLI와 동일한 자격 증명을 사용해 브라우저 기반 OAuth로 AWS MCP Server에 연결할 수 있다. - IAM Federation, AWS IAM Identity Center, 루트 사용자 및 IAM 사용자를 지원한다. - AWS Sign-In이 단기 액세스·리프레시 토큰을 발급하고 토큰 갱신을 자동 처리한다. - 개발자는 재시작 후에도 반복 로그인 없이 에이전트를 인증 상태로 유지할 수 있다. AWS를 학습하거나 실험하려는 경우 Builder Center의 샌드박스와 워크숍을 활용하면 비용과 정리 부담을 줄일 수 있다. 운영 환경에서는 Security Hub의 실제 인터넷 도달성 검사와 Azure 통합을 우선 검토하고, AI 에이전트 도입 시에는 Loom·OAuth·중앙 정책 관리 기능을 통해 권한, 비용, 감사 체계를 함께 설계하는 것이 바람직하다.

원문 읽기(새 탭에서 열림)
쿠버네티스모델 컨텍스트 프로토콜PostgreSQLAWS+4
meta4분 읽기큐레이션 요약

오픈 소스 커널 스케줄러를 활용한 Meta 광고 서비스 현대화

Meta는 광고 서버의 워크로드 특성을 반영한 `sched_ext` 기반 커스텀 스케줄러를 도입해 광고 검색 경로의 p99 지연을 28% 줄이고, 전력 3.28MW를 절감했으며, 순위 매긴 광고 수를 1.1% 늘렸다. 일반 목적 스케줄러 대신 요청의 중요도와 실행 경로를 이해하는 스케줄링 정책을 적용한 결과다. 이후 사용자 공간 BPF 정책만 수정해 p99 지연을 추가로 60% 줄이고 타임아웃 오류도 18% 감소시켰다. ## 광고 서비스에서 지연 시간이 중요한 이유 - Meta의 광고 플랫폼은 초당 평균 500만 건 이상의 요청을 처리하며, 하루 기준 4,000억 건이 넘는다. - p99 지연 시간이 몇 밀리초만 늘어나도 광고의 관련성과 광고주 ROI가 악화될 수 있다. - 기존 Linux 스케줄러인 CFS와 EEVDF는 범용 목적이라 각 스레드의 업무 중요도나 광고 요청 처리 경로를 알지 못한다. - 광고 서비스에서는 어떤 스레드가 사용자 요청의 핵심 경로에 있는지 알고 있으므로, 이를 스케줄러에 직접 반영할 여지가 있었다. ## EEVDF 전환으로 발생한 문제 - Linux 6.6부터 도입된 EEVDF가 최신 커널 6.9에서 광고 서버의 지연 시간을 악화시켰다. - 그 결과 응답에서 검색·순위 지정되는 광고 수가 줄어들었다. - 일부 광고 서버는 성능 회귀를 피하기 위해 Linux 6.4와 CFS에 계속 남아야 했고, 커널 버전이 혼재하는 운영 부담과 기술 부채가 발생했다. - 이미 Meta 내 여러 서비스에서 성능 개선 효과를 보인 `sched_ext`가 이 문제의 해결책으로 선택됐다. ## BPF 기반 `sched_ext`의 구조 - `sched_ext`는 BPF 프로그램으로 스케줄링 정책을 구현할 수 있는 Linux의 확장 가능한 프레임워크다. - Linux 6.12에 공식적으로 포함됐으며, Google의 ghOSt 설계 경험을 바탕으로 업스트림 통합을 고려해 개발됐다. - 커널은 다음과 같은 이벤트가 발생할 때 BPF 스케줄러를 호출한다. - 스레드가 실행 가능 상태가 될 때 CPU 선택 - 실행 큐에 스레드를 넣을 때 - CPU가 유휴 상태가 되어 다음 스레드를 선택할 때 - CPU가 유휴 상태에 진입하거나 빠져나올 때 - 광고 워크로드가 실행되는 호스트에만 광고 최적화 정책을 적용할 수 있다. ## 광고 요청에 맞춘 CPU 분할과 지역성 개선 - CPU를 두 개의 논리적 풀로 나눈다. - 지연 시간에 민감한 광고 요청 처리 스레드용 - 상대적으로 덜 중요한 백그라운드·비핵심 작업용 - 어떤 스레드를 어느 풀에 배치할지는 광고 도메인 지식에 따라 결정한다. - 부하 기반 휴리스틱으로 각 CPU 풀의 크기를 동적으로 조절한다. - 관련 작업을 장기간 같은 CPU에 배치해 L3 캐시 지역성을 높이고 DRAM 접근 비용을 줄인다. - 정책은 사용자 공간 바이너리가 BPF 프로그램을 로드하는 형태로 배포된다. - 정책을 변경할 때 커널을 다시 빌드하거나 설치할 필요 없이 스케줄러 프로세스를 재시작하면 되므로 실험과 배포가 빠르다. ## 성능과 운영 효과 Linux 6.4의 CFS에서 Linux 6.9와 `sched_ext`로 전환한 초기 도입 결과는 다음과 같다. - 광고 검색 경로의 서비스 p99 지연 28% 감소 - 전체 서버 플릿에서 전력 3.28MW 절감 - 가중 광고 순위 지표 1.1% 증가 - 사용자 공간 정책을 두 차례 추가 개선한 뒤: - 서비스 p99 지연이 추가로 60% 감소 - 핵심 경로의 타임아웃 오류 18% 감소 커널 변경이 필요하지 않았기 때문에 후속 개선은 수개월이 아닌 며칠 단위로 배포할 수 있었다. ## 장기적인 전략 자산으로의 확장 - 업스트림 Linux 스케줄러의 변화와 별개로, Meta가 자체 워크로드에 맞는 정책을 병렬적으로 개선할 수 있다. - 커널 패치와 장기간의 검증이 필요했던 기능도 사용자 공간 BPF 업데이트로 빠르게 실험할 수 있다. - 예시로 로컬 캐시 인식 배치, ROI 기반 실행기 라우팅, NUMA 인식 CPU 선택 등을 적용할 수 있다. - `sched_ext`가 Linux에 업스트림되면서 클라우드 사업자, 대규모 서비스 운영자, 임베디드 시스템 등도 커널을 포크하지 않고 특화된 스케줄링 정책을 구현할 수 있게 됐다. ## 향후 방향 - 광고 서비스가 요청의 상대적 중요도 같은 애플리케이션 수준의 정보를 스케줄러에 전달할 수 있다. - 스케줄러는 중요 요청을 처리하는 스레드에 더 긴 실행 시간을 주거나, 실행 큐의 최상단에 유지하는 방식으로 대응할 수 있다. - 이를 통해 단순한 CPU 부하 균형을 넘어, 비즈니스 가치와 요청 우선순위를 반영한 스케줄링이 가능해진다. 워크로드별 우선순위와 실행 특성을 명확히 알고 있는 대규모 서비스라면, 범용 스케줄러만 고집하기보다 `sched_ext` 같은 확장 프레임워크로 지연 시간·전력·처리량을 함께 최적화하는 방안을 검토할 만하다.

원문 읽기(새 탭에서 열림)
Linuxebpflinux-kernelnuma+4
cloudflare4분 읽기큐레이션 요약

Precursor 소개: 지속적인 클라이언트 측 신호를 통한 에이전트형 행동 탐지

Cloudflare의 Precursor는 개별 요청이나 챌린지 결과가 아니라 웹사이트 전체 세션에서 나타나는 행동 패턴을 지속적으로 분석해 인간과 봇·에이전트 트래픽을 구분하는 클라이언트 측 검증 시스템이다. Turnstile이 로그인·가입·결제 같은 특정 시점의 검증을 담당한다면, Precursor는 사용자 여정 전반의 신호를 수집해 탐지 정확도를 높이고 불필요한 챌린지를 줄인다. 봇이 실제 브라우저와 JavaScript를 사용하더라도 장시간 일관된 인간 행동을 모방하기는 어렵다는 점이 핵심이다. ### 기존 봇 탐지의 가시성 한계 - Cloudflare는 하루 1조 건이 넘는 요청과 인터넷의 20% 이상에서 얻은 네트워크 신호를 활용한다. - Turnstile은 CAPTCHA 대체 수단에서 위험 기반 관리형 챌린지로 발전했으며, 하루 약 30억 회 실행된다. - 하지만 로그인, 가입, 결제처럼 중요한 순간에만 검증하면 애플리케이션 전체 여정에서 사용자가 어떻게 행동했는지는 충분히 파악하기 어렵다. - Precursor는 이 공백을 메우기 위해 세션 전체의 상호작용을 지속적으로 관찰한다. ### Precursor의 역할 - 동적으로 삽입되는 JavaScript가 방문자의 행동 신호를 수집한다. - 수집된 신호는 실시간으로 Cloudflare의 봇 방어 시스템에 반영된다. - Turnstile을 대체하는 기능이 아니라, Enterprise Bot Management에서 선택적으로 함께 사용하는 보완 기능이다. - 짧은 시간 동안 정상적으로 보이는 자동화도 세션 전체의 일관된 행동 패턴에서는 이상 징후를 드러낼 수 있다. - 공격자는 전체 세션을 인간처럼 시뮬레이션해야 하므로 자동화 개발·유지·대규모 운영 비용이 증가한다. - 정상 사용자는 공격적인 챌린지를 덜 받으면서도 보호 수준을 유지할 수 있다. ### 인간 행동과 봇 행동의 차이 - 인간의 마우스 움직임은 단순한 무작위 노이즈가 아니라 물리적·인지적 제약을 따른다. - 손목과 팔의 회전 범위 때문에 움직임이 일정한 곡선이나 호 형태를 보인다. - 화면의 요소를 인지한 뒤 클릭하기까지 인지 처리 시간이 발생한다. - 손 떨림으로 인해 미세한 생리학적 진동이 나타난다. - 봇은 다음과 같은 패턴을 보이기 쉽다. - 두 지점 사이를 직선으로 이동한다. - 수학적으로 이상적인 베지어 곡선을 따른다. - 지나치게 정확하게 클릭한다. - 동일한 속도와 리듬으로 반복한다. - 마우스를 항상 원점으로 되돌리는 등 기계적인 동작을 보인다. - 개별 동작 하나만 보면 정상처럼 보일 수 있지만, 세션 전체에서 이동 경로·속도·대기 시간·수정 동작의 반복을 관찰하면 인간과 자동화의 차이가 커진다. - 마우스 이동 외에도 키보드 활동, 포커스 변화, 페이지 가시성 등이 함께 분석된다. ### 데이터 수집 및 전송 - Precursor가 활성화되면 Cloudflare가 네트워크를 통과하는 HTML 응답에 경량 스크립트를 자동 삽입한다. - 별도의 네트워크 설정이나 외부 임베드가 필요 없다. - 스크립트는 응답마다 동적으로 조립되고 난독화되며, 기존 애플리케이션 로직에 영향을 주지 않도록 설계된다. - 다음과 같은 이벤트를 수집한다. - 포인터 이동 - 키보드 활동 - 입력 요소의 포커스 변화 - 페이지 가시성 변화 - 이벤트는 압축된 형식으로 직렬화되어 메모리에 임시 저장된다. - 일정 간격으로 버퍼의 데이터가 평가 계층으로 전송된다. ### 엣지 기반 행동 평가 - Cloudflare 엣지 서버는 수신한 Precursor 데이터를 역직렬화해 행동 입력으로 변환한다. - 여러 평가기(evaluator)가 각자 필요한 데이터 스트림을 분석하고 탐지 레지스트리에 신호를 추가한다. - 평가기는 단일 이벤트보다 서로 다른 신호 간의 상관관계를 확인한다. - 포인터 활동이 실제 페이지 가시 시간과 일치하는지 검사한다. - 키보드 입력이 텍스트 필드 포커스 상태에서 발생했는지 확인한다. - 개별 평가 결과는 통합된 탐지 신호로 변환되어 세션의 봇 점수와 판정에 반영된다. ### 세션 단위 분석 - Precursor 데이터는 요청 단위가 아니라 세션 범위에서 누적된다. - 페이지를 새로고침하거나 새로운 챌린지를 시작해도 기존 행동 서명을 쉽게 초기화할 수 없다. - 세션 메타데이터는 다음과 같은 후속 분석에도 사용된다. - 섀도 모드 휴리스틱 - 세션 분석 - 예측된 완료 상태와 실제 완료 상태의 비교 - 세션 비정상 종료(delinqency) 관련 휴리스틱 - 엣지에서 관찰된 정보는 탐지 개선과 세션 봇 점수 조정에 활용된다. - Cloudflare는 요청별 분석에서 방문자 전체 여정을 보는 방식으로 확장하기 위해 Security Analytics에 세션 기반 뷰를 도입한다. ### 개인정보 보호 설계 - 자동화와 악성 행위를 식별하는 데 필요한 최소한의 신호만 수집한다. - 키보드 활동은 실제 입력한 키가 아니라 입력 시점의 타이밍과 리듬으로 기록된다. - 개별 행동 자체보다 여러 행동의 집계된 패턴을 평가한다. - 수집된 행동 신호는 Cloudflare 내부 봇 탐지 시스템에서 사용된다. - 고객 대시보드에 노출되지 않으며, 사용자 계정·로그인 신원·영구 프로필과 연결되지 않는다. ### 실용적인 결론 Precursor는 CAPTCHA를 더 복잡하게 만드는 접근보다, 사용자 세션 전체에서 축적되는 행동 일관성을 탐지 신호로 활용하는 방식이다. 봇 방어가 필요한 서비스는 Turnstile로 중요한 순간을 보호하면서 Precursor로 전체 여정을 분석하면, 정상 사용자에 대한 마찰을 줄이고 장기적으로 정교한 자동화 공격의 비용과 불안정성을 높일 수 있다.

원문 읽기(새 탭에서 열림)
JavaScriptbot-managementbot-detectionbehavioral-analysis+3
naver1분 읽기큐레이션 요약

[AI 해커톤 후기] AI 시대의 해커톤과 인간의 역할: AI의 계획과 사람의 전략

제공된 글은 기술적 주제나 구체적인 본문 없이 NAVER D2 사이트의 메뉴와 저작권 정보만 나열하고 있습니다. 따라서 특정 기술에 대한 주장, 설명, 결론은 확인할 수 없습니다. ### NAVER D2 관련 메뉴 - `Hello world` - `D2 News` - `About D2` - `NAVER Developers` - `DEVIEW` - `OpenSource` - `D2 STARTUP FACTORY` ### 저작권 정보 - 저작권자는 NAVER Corp.입니다. - 표기된 문구는 “Copyright © NAVER Corp. All Rights Reserved.”입니다. 별도의 기술 내용이 포함된 원문을 제공하면 섹션별로 구체적으로 요약할 수 있습니다.

원문 읽기(새 탭에서 열림)
오픈 소스software-developmentdeveloper-community
github4분 읽기큐레이션 요약

더 나은 도구가 Copilot 코드 리뷰를 악화시켰습니다. 실제로 개선한 방법은 다음과 같습니다.

더 나은 코드 탐색 도구를 도입했지만, GitHub Copilot 코드 리뷰의 비용은 오히려 증가하고 발견하는 문제는 줄어들었다. 원인은 `grep`, `glob`, `view` 자체가 아니라, 코딩 에이전트용으로 작성된 도구 지침을 리뷰 작업에 그대로 적용한 데 있었다. 리뷰어처럼 PR diff에서 출발해 필요한 최소한의 코드만 확인하도록 지침을 바꾸자, 리뷰 품질을 유지하면서 평균 비용을 약 20% 낮출 수 있었다. ## 도구 교체가 예상과 다른 결과를 낳은 이유 - 기존 Copilot 코드 리뷰는 자체 코드 탐색 도구를 사용했다. - `list_dir`: 디렉터리 탐색 - `search_file`, `search_dir`: 파일 및 디렉터리 검색 - `read_code`: 코드 읽기 - 이 도구들은 검색 결과나 지정한 코드 범위뿐 아니라 주변 코드도 함께 반환했다. - 토큰 비용은 증가하지만, 도구 호출 횟수가 적고 자동으로 맥락을 확보하기 어려운 초기 모델에는 유용했다. - Copilot CLI는 여러 제품이 공유하는 Unix 스타일 도구를 제공했다. - `glob`: 후보 파일과 디렉터리 탐색 - `grep`: 텍스트, 심벌, 호출 지점 검색 - `view`: 특정 파일이나 코드 범위 읽기 - 인프라를 통합하면 도구 구현 중복을 줄이고, CLI와 클라우드 에이전트의 개선 사항을 코드 리뷰에도 공유할 수 있다는 장점이 있었다. - 그러나 단순히 기존 도구를 새 도구로 치환하는 방식으로는 충분하지 않았다. ## 벤치마크에서 드러난 성능 저하 - 공유 도구를 적용한 오프라인 벤치마크에서 다음 문제가 나타났다. - 평균 리뷰 비용 증가 - 유용한 리뷰 댓글 감소 - 전체적으로 효율성과 효과성 모두 저하 - 내부 추적 데이터는 최종 점수뿐 아니라 에이전트의 탐색 과정도 보여줬다. - 어떤 도구를 호출했는지 - 각 호출이 얼마나 많은 결과를 반환했는지 - 오류가 발생했는지 - 탐색이 문제의 증거로 좁혀졌는지, 아니면 범위를 넓혔는지 - 이를 통해 도구가 오작동한 것이 아니라, 에이전트가 도구를 사용하는 방식이 문제였음이 드러났다. ## 코드 리뷰가 저장소 탐색으로 변한 문제 - 에이전트는 PR의 변경 사항을 분석하기보다 저장소 전체를 이해하려는 것처럼 행동했다. - 전형적인 흐름은 다음과 같았다. - 넓게 검색 - 경로를 추측 - 많은 파일을 읽음 - 새로 발견한 내용을 바탕으로 다시 검색 - 불필요한 맥락을 계속 누적 - 이런 방식은 “저장소를 이해하거나 기능을 구현하라”는 작업에는 적합할 수 있다. - 하지만 코드 리뷰의 목적은 저장소 전체를 파악하는 것이 아니라, 변경 사항이 실제 문제를 만들었는지 판단하는 것이다. - 도구 결과는 일회성 출력이 아니다. - 반환된 파일 내용은 에이전트의 컨텍스트에 남는다. - 불필요한 코드는 이후 추론 비용을 높인다. - 관련 없는 정보가 많아지면 리뷰의 초점도 흐려질 수 있다. ## 코딩 에이전트와 코드 리뷰어의 탐색 방식 차이 - 일반적인 코딩 에이전트는 변경 전에 넓은 영역을 파악할 수 있다. - 다른 코드에 미칠 영향을 확인하기 위해 저장소 구조를 폭넓게 탐색한다. - 계획 수립, 파일 수정, 여러 차례의 대화형 작업을 전제로 한다. - 코드 리뷰어는 보통 훨씬 좁은 질문에서 시작한다. - 이 함수는 어디에서 호출되는가? - 이 설정 키가 다른 곳에서도 사용되는가? - 같은 패턴의 테스트나 헬퍼가 존재하는가? - 이 동작을 설명하는 데 필요한 가장 작은 코드 범위는 무엇인가? - 따라서 리뷰 에이전트는 다음 순서를 따라야 한다. - PR diff에서 출발 - 변경된 코드가 일으킬 수 있는 구체적인 의문을 제기 - 해당 의문을 검증할 최소한의 주변 코드만 탐색 - 문제의 증거가 부족하면 탐색을 확장하지 않고 결론 ## 도구보다 중요한 지침과 워크플로 - Copilot CLI와 클라우드 에이전트의 도구 지침은 대화형 코딩 작업에 맞춰져 있었다. - 동일한 `grep`, `glob`, `view`라도 지침이 다르면 에이전트의 행동이 달라진다. - 기존 지침은 넓은 저장소 탐색을 유도했지만, 코드 리뷰에는 다음 원칙이 필요했다. - 변경된 diff를 탐색의 중심으로 삼기 - 파일 경로를 추측하기보다 diff에서 확인된 심벌과 호출 관계를 활용하기 - 전체 파일보다 필요한 코드 범위만 읽기 - 새 정보를 얻을 때마다 탐색을 무작정 넓히지 않기 - 실제 문제를 판단하는 데 필요한 증거만 컨텍스트에 추가하기 - 지침을 리뷰 작업의 특성에 맞게 다시 작성한 결과, 도구는 그대로 유지하면서도 리뷰 비용을 약 20% 절감했다. - 글에서는 이 개선이 리뷰 품질을 유지한 상태에서 이루어졌다고 설명한다. ## 실용적인 결론 에이전트 도구를 교체할 때는 도구의 기능만 비교해서는 안 된다. 도구 사용 지침과 에이전트가 따라야 할 탐색 워크플로까지 작업 목적에 맞게 설계해야 하며, 특히 코드 리뷰에서는 “더 많이 읽기”보다 “변경 사항을 검증하는 데 필요한 최소한만 읽기”가 비용과 품질 모두에 유리하다.

원문 읽기(새 탭에서 열림)
AI 에이전트github-copilot코드 리뷰pull-requests+2
cloudflare4분 읽기큐레이션 요약

퍼블릭 클라우드 리전을 위한 스마트 계층형 캐시 개선

Smart Tiered Cache는 원본(origin)으로 향하는 캐시 미스를 가장 가까운 단일 Cloudflare 상위 티어(upper tier)로 모아 캐시 적중률을 높이는 기능이다. 그러나 AWS·GCP·Azure·Oracle Cloud처럼 anycast 또는 regional unicast를 사용하는 퍼블릭 클라우드 원본은 IP만으로 실제 위치를 판단하기 어려워, 여러 상위 티어를 사용하는 보수적 방식으로 동작했다. 이번 개선에서는 사용자가 클라우드 리전을 지정하면 Cloudflare가 해당 리전에 맞는 주·보조 상위 티어를 선택해 불필요한 대륙 간 우회(hairpin)와 원본 요청을 줄인다. ## Smart Tiered Cache의 목적과 발전 - 모든 요금제에서 무료로 제공되는 Cloudflare의 대표적인 tiered cache 토폴로지다. - 원본 IP의 실시간 지연 시간을 측정해 가장 빠른 Cloudflare 데이터센터 하나를 상위 티어로 선택한다. - 캐시 미스를 한 곳에 집중해 다음 효과를 얻는다. - 캐시 적중률 향상 - 원본으로 연결되는 요청 및 연결 수 감소 - 원본 데이터를 가져오는 지연 시간 감소 - 기존 확장 사례: - **R2 지원(2024년 11월):** R2 버킷의 실제 위치에 가까운 상위 티어를 자동 선택 - **Load Balancing 지원(2025년 1월):** 풀 전체에 동일한 상위 티어를 사용해 공유 캐시와 적중률 개선 ## 퍼블릭 클라우드 anycast 원본의 문제 - 고정된 unicast IP는 특정 물리적 위치에 대응하므로 지연 시간 측정만으로 최적 상위 티어를 고르기 쉽다. - 반면 클라우드 로드 밸런서나 regional ingress의 IP는 여러 클라우드 엣지에서 동시에 응답할 수 있다. - 같은 IP라도 Cloudflare 데이터센터마다 서로 다른 클라우드 엣지로 연결되므로, IP가 실제 백엔드 위치를 나타내지 않는다. - 그 결과 한 곳을 최적 상위 티어로 잘못 선택할 수 있다. - 예를 들어 싱가포르 원본에 대해 시카고 데이터센터가 가장 낮은 측정 지연을 보이면: - 아시아 사용자의 요청이 가까운 Cloudflare PoP에 도착 - 시카고 상위 티어로 대륙을 건너 이동 - 시카고에서 다시 싱가포르 원본으로 이동 - 이런 hairpin 트래픽은 대륙 간 왕복을 추가해 수백 밀리초의 지연을 만들 수 있다. ## anycast 감지와 기존 대응 - Cloudflare는 여러 전 세계 체크포인트에서 원본까지의 probe 지연을 측정한다. - 두 체크포인트 간 물리적으로 빛이 이동할 수 있는 시간보다 전체 경로가 빠르게 나타나면, 하나의 위치가 아니라 여러 위치에서 응답한다고 판단한다. - 이는 해당 원본이 anycast일 가능성이 높다는 의미다. - anycast로 감지되면 Cloudflare는 단일 상위 티어에 고정하지 않고 여러 상위 티어를 사용하는 방식으로 전환한다. - 이 방식은 안정적이지만 트래픽이 여러 티어로 분산되어: - 캐시가 한 곳에 모이지 않음 - 원본으로 전달되는 요청 증가 - 단일 최적 상위 티어를 사용할 때보다 캐시 효율 저하 ## 리전 힌트를 이용한 개선 - 사용자가 원본이 위치한 클라우드 리전을 직접 지정한다. - 예시: - `aws:us-east-1` - `gcp:europe-west1` - Cloudflare는 리전 정보를 바탕으로 IP 자체의 모호한 지연 측정 대신 해당 리전에 적합한 상위 티어를 선택한다. - 각 리전에 대해: - **Primary upper tier:** 가장 강한 신호를 가진 최적 상위 티어 - **Fallback upper tier:** 주 상위 티어와 다른 PoP에 위치한 보조 상위 티어 - 주·보조 티어를 서로 다른 PoP로 구성해 한 PoP 장애가 두 경로를 동시에 제거하지 않도록 한다. - AWS, GCP, Azure, Oracle Cloud에서 출시되며 향후 지원 제공자가 추가될 예정이다. ## 설정 방법과 운영 방식 - Cloudflare 대시보드에서 다음 경로로 설정한다. - `Caching > Tiered Cache > Origin Configuration` - 원본 IP 옆의 **Set Region Hint** 선택 - 클라우드 리전 입력 - 대시보드에서는 Cloudflare가 anycast로 감지한 원본 IP에만 리전 힌트를 설정할 수 있다. - IP별 개별 설정뿐 아니라 여러 원본 IP에 대한 일괄 편집도 가능하다. - API와 Terraform도 지원하므로 Infrastructure as Code 환경에 통합할 수 있다. ## 리전 매핑과 상위 티어 선택 방식 - Cloudflare는 지원 클라우드 제공자의 최신 IP 범위 파일을 몇 시간마다 가져온다. - 이 파일을 통해 각 클라우드 리전과 현재 IP prefix를 매핑한다. - 클라우드 제공자가 서브넷을 추가·삭제·재할당해도 최신 정보를 반영한다. - Cloudflare의 상위 티어 데이터베이스는 15분마다 갱신되는 지속적인 지연 시간 측정 결과로 구성된다. - 리전에 속한 각 서브넷은 현재 상위 티어 할당 결과에 따라 가중 투표를 제공한다. - 가장 강한 신호를 얻은 상위 티어가 해당 리전의 primary가 된다. ## 실용적인 권장 사항 퍼블릭 클라우드의 anycast 원본에서 캐시 효율이 낮거나 대륙 간 hairpin 지연이 발생한다면, 원본 IP에 정확한 클라우드 리전 힌트를 설정하는 것이 좋다. 여러 원본을 운영한다면 API나 Terraform으로 리전 정보를 관리하고, primary와 fallback이 서로 다른 PoP로 구성되는지 확인하면 장애 대응과 성능을 함께 개선할 수 있다.

원문 읽기(새 탭에서 열림)
cloudflareTerraformtiered-cachinganycast+3
line5분 읽기큐레이션 요약

초당 100만 건, LINE 앱에 Apache Kafka 종단 간 암호화 적용기

LINE의 대규모 Kafka 환경에서는 TLS·인증·인가만으로는 브로커에 저장된 평문 데이터를 충분히 보호하기 어렵기 때문에, 프로듀서부터 컨슈머까지 메시지 페이로드를 암호화하는 종단 간 암호화를 도입했다. 레코드 단위 암호화와 DEK-KEK 구조를 결합해 Kafka 표준 확장성을 유지하면서 성능 오버헤드를 줄였고, 공유 KEK·평문 폴백·점진적 배포로 초당 최대 100만 건 규모의 토픽에 무중단 적용했다. ## Kafka 기본 보안 모델의 한계 - TLS/SSL은 프로듀서·컨슈머와 브로커 사이의 전송 구간만 보호한다. - SASL 인증은 클라이언트의 신원을 확인하고, ACL 인가는 토픽 접근 권한을 통제한다. - 그러나 브로커에 저장된 메시지 페이로드 자체는 평문일 수 있다. - 따라서 접근 권한이 우회되거나 브로커 내부 데이터가 노출되면 민감 정보가 보호되지 않는다. - 데이터 생성 시점부터 컨슈머의 복호화 시점까지 암호화 상태를 유지하는 심층 방어 전략이 필요하다. ## 레코드 단위 암호화 - 배치 단위 암호화는 압축 효율과 처리 성능이 좋지만, Kafka 클라이언트 내부 동작을 수정해야 한다. - Kafka의 인터셉터와 같은 공식 확장 포인트는 레코드 단위로 동작한다. - 레코드 단위 암호화는 압축 효율이 낮고 메시지 크기가 다소 증가하지만 다음 장점이 있다. - 표준 Kafka API를 활용할 수 있다. - Kafka 버전 업그레이드 시 호환성과 안정성이 높다. - 기존 프로듀서·컨슈머 클라이언트 코드를 직접 수정하지 않아도 된다. - 이러한 이유로 레코드 단위 암호화를 선택했다. ## DEK-KEK 이중 키 구조 - **DEK(Data Encryption Key)** - 메시지 페이로드 암호화에 사용하는 AES 대칭 키다. - AES-GCM을 사용해 빠른 암·복호화와 무결성 검증을 제공한다. - **KEK(Key Encryption Key)** - DEK를 암호화하는 ECC 기반 비대칭 키 쌍이다. - KMS가 키를 관리하며, 프로듀서는 공개 키를 사용하고 컨슈머는 인가된 비공개 키를 사용한다. - DEK 암호화에는 ECIES와 `secp521r1` 곡선을 사용한다. - 대용량 데이터는 빠른 대칭 키로 처리하고, 짧은 DEK에만 비대칭 암호화를 적용해 성능 부담을 줄인다. - 프로듀서는 페이로드를 한 번만 암호화하므로 컨슈머 수가 늘어도 메시지 크기를 크게 늘리지 않는다. - 공개 키를 이용한 암호화 권한과 비공개 키를 이용한 복호화 권한을 분리해 최소 권한 원칙을 적용한다. ## 암호화 메시지 구조 - **키** - Kafka 파티션을 결정하는 기존 메시지 키를 그대로 유지한다. - **헤더** - 컨슈머가 사용할 KEK ID와 KEK로 암호화된 DEK를 저장한다. - **바디** - DEK로 암호화된 실제 페이로드를 담는다. - 외부 DB나 캐시 없이 메시지 자체에 복호화 메타데이터를 포함해 시스템 의존성을 줄였다. - 컨슈머는 헤더의 KEK ID를 확인한 뒤 DEK를 복호화하고, 복호화한 DEK로 바디의 페이로드를 복호화한다. ## 프로듀서 암호화 처리 - Kafka 인터셉터가 전송 직전 DEK를 생성하고 KEK 공개 키로 암호화한다. - 암호화된 DEK는 메시지 헤더에 삽입한다. - 기존 시리얼라이저를 감싼 래퍼가 직렬화된 페이로드를 DEK로 암호화한다. - 인터셉터와 시리얼라이저가 같은 실행 스레드를 공유한다는 점을 활용해 DEK를 `ThreadLocal`로 전달한다. - 매 메시지마다 DEK를 새로 만들지 않고 일정 시간 캐싱해, 반복적인 비대칭 키 연산을 줄였다. ## 컨슈머 복호화 처리 - 컨슈머는 KMS에서 인가된 KEK 비공개 키를 조회한다. - 디시리얼라이저가 헤더에서 암호화된 DEK를 추출하고 비공개 키로 복호화한다. - 복호화된 DEK로 페이로드를 복호화한 후 기존 역직렬화를 수행한다. - 여러 프로듀서가 생성한 암호화 DEK와 복호화된 DEK의 쌍을 캐싱한다. - 동일한 암호화 DEK가 반복되면 비공개 키 연산을 생략해 컨슈머 성능을 높인다. ## KMS 기반 키 관리 - 토픽 오너가 KEK 키 쌍을 생성하고 KMS에 등록한다. - 프로듀서는 공개 키를, 승인된 컨슈머는 비공개 키를 KMS에서 조회한다. - 신규 컨슈머는 비공개 키 접근 권한을 요청하고 토픽 오너의 승인을 받아야 한다. - KEK의 생성·배포·접근 제어·교체를 KMS를 통해 일관되게 관리한다. ## 공유 KEK로 메시지 크기 제어 - 컨슈머마다 별도의 KEK를 사용하면 컨슈머 수에 비례해 헤더 메타데이터가 증가한다. - 메시지 크기 증가는 배치당 레코드 수 감소, 네트워크 대역폭 증가, CPU·메모리 사용량 증가로 이어진다. - 특히 초당 최대 100만 건의 토픽에서는 컨슈머 추가에 따른 헤더 증가가 큰 성능 문제가 된다. - 여러 컨슈머가 하나의 KEK를 공유하면 헤더에는 하나의 메타데이터만 포함되어 메시지 크기를 일정하게 유지할 수 있다. - 대신 키 격리 수준은 낮아지므로 다음 보완책을 함께 적용한다. - KMS 기반 비공개 키 접근 인가 - 주기적인 KEK 교체 - 토픽 오너 중심의 키 관리 ## 평문 폴백을 이용한 무중단 마이그레이션 - 암호화 도입 과정에서는 기존 평문 메시지와 새로운 암호화 메시지가 함께 존재할 수 있다. - 디시리얼라이저가 헤더의 암호화 메타데이터 유무를 확인해 처리 방식을 결정한다. - 헤더가 있으면 복호화 후 역직렬화한다. - 헤더가 없으면 기존 평문 역직렬화만 수행한다. - 안전한 전환 순서는 다음과 같다. - 평문과 암호화 메시지를 모두 처리할 수 있는 컨슈머를 먼저 배포한다. - 모든 컨슈머가 준비된 뒤 프로듀서 암호화를 활성화한다. - 모니터링을 통해 평문 메시지 비중이 0%가 되었는지 확인한다. - 프로듀서 암호화 비율도 한 번에 100%로 변경하지 않고 점진적으로 높여 성능 저하나 암·복호화 오류에 대응한다. ## 실용적인 결론 Kafka의 TLS·인증·인가를 대체하기보다, DEK-KEK 기반 페이로드 암호화를 추가 보안 계층으로 적용하는 것이 적절하다. 대규모 환경에서는 레코드 단위 암호화, DEK 캐싱, 컨슈머 측 DEK 캐싱, 공유 KEK, 평문 폴백과 점진적 배포를 함께 설계해야 보안성과 성능, 무중단 운영을 동시에 확보할 수 있다.

원문 읽기(새 탭에서 열림)
Apache Kafkaend-to-end-encryptionzero-downtime-migrationkey-management-service+3
figma3분 읽기큐레이션 요약

Decagon이 AI를 활용해 디자인 시스템을 포화시키는 방법 | Figma 블로그

Decagon은 빠르게 성장하는 AI 고객지원 플랫폼의 품질과 개발 속도를 함께 확보하기 위해 Deco라는 디자인 시스템을 구축했다. Figma 라이브러리, Storybook, 코딩 에이전트, Figma MCP를 연결해 디자인과 코드가 지속적으로 일치하도록 만들었고, 그 결과 반복적인 해석과 수정 작업을 줄였다. 핵심은 디자인 시스템을 단순한 컴포넌트 모음이 아니라 사람과 AI 에이전트가 함께 사용하는 공통 언어로 만든 데 있다. ## 빠른 성장에 대응하는 디자인 시스템 구축 - Decagon은 초기에는 디자인 시스템 없이 빠르게 제품을 개발했지만, 플랫폼과 팀이 커지면서 화면 간 불일치와 완성도 저하가 나타났다. - 기업 고객을 대상으로 제품을 제공하기 위해서는 일관된 UI와 높은 품질이 필요했으며, 디자인과 개발 사이의 반복적인 수정 작업도 줄여야 했다. - 디자이너와 엔지니어가 처음부터 함께 Deco를 설계해 다음과 같은 세부 사항을 미리 정의했다. - 포커스 상태 - 비활성화, 읽기 전용, 오류, 경고 상태 - 플레이스홀더 사용 여부 - 기존 코드에 이미 존재하는 컴포넌트와의 관계 - 현재 Deco는 수백 개의 컴포넌트·스타일·변수를 포함하며, 여러 팀과 제품 영역의 대부분의 사용 사례를 다룬다. - Figma 라이브러리에서 30일 동안 수만 건의 컴포넌트 삽입이 발생해 조직 전반에서 실제로 활용되고 있음을 확인했다. ## 디자인 시스템이 만든 공통 언어 - 디자이너는 기존 컴포넌트로 화면을 조합할 수 있어 매번 UI를 처음부터 만들 필요가 없어졌다. - 개발자는 어떤 버튼이나 테이블을 사용해야 하는지 명확히 알 수 있어 구현상의 판단과 논쟁이 줄었다. - 디자인과 코드가 동일한 프리미티브를 기준으로 소통하면서 제품 흐름과 요구사항을 설명하기 쉬워졌다. - Deco는 조직 전체에 공개된 단일 진실 공급원(single source of truth)으로 작동해 빠른 출시와 일관된 디자인을 동시에 지원한다. ## 디자인과 코드 사이의 반복 작업 줄이기 - 기존 방식에서는 디자이너가 명세를 전달하면 개발자가 해석하고, 리뷰 단계에서 불일치를 발견한 뒤 다시 수정하는 과정이 반복됐다. - 코딩 에이전트는 개발자처럼 암묵적인 의도를 추론하지 않고 제공된 정보만 바탕으로 작업하므로, 디자인 파일과 명세가 불명확하거나 일관되지 않으면 결과물도 부정확해진다. - Decagon은 디자인 시스템 컴포넌트를 Storybook으로 옮겨 코드에서도 동일한 컴포넌트를 확인할 수 있게 했다. - 코딩 에이전트가 구현할 때 정확한 Deco 컴포넌트를 사용하도록 별도의 skill을 만들었다. - 디자이너가 새로운 컴포넌트를 추가할 때 사용하는 skill도 구축해 Figma와 코드의 동기화를 유지했다. ## Figma MCP를 통한 에이전트 활용 - Figma MCP를 사용하면 코딩 에이전트가 Figma의 디자인 문맥과 명세를 직접 읽을 수 있다. - 디자이너는 Figma 링크를 코딩 에이전트에 전달하는 것만으로 다음 작업을 수행할 수 있다. - 디자인의 구조와 세부 명세 파악 - Deco의 적합한 컴포넌트와 매핑 - 디자인에 가까운 고충실도 구현 생성 - 디자인 캔버스, 코드, 컴포넌트 명세가 하나의 작업 흐름으로 연결되어 파일을 내보내고 다시 해석하는 수동 왕복이 줄었다. - 에이전트가 기존 디자인 시스템을 활용하므로 빠른 프로토타이핑과 반복 수정이 가능하면서도 브랜드와 UI 일관성을 유지할 수 있다. ## 실용적인 결론 AI 코딩 도구를 도입할 때는 에이전트의 성능만 높이기보다, 먼저 재사용 가능한 디자인 시스템과 명확한 컴포넌트 문맥을 마련해야 한다. Figma와 Storybook을 연결하고, MCP와 에이전트 skill을 통해 동일한 컴포넌트를 사용하게 하면 디자인-개발 간 불일치를 줄이면서 빠른 개발 속도와 품질을 함께 확보할 수 있다.

원문 읽기(새 탭에서 열림)
Figma디자인 시스템AI 에이전트design-to-code+2
github1분 읽기큐레이션 요약

GitHub가 모든 저장소에 지속적인 소유자를 부여한 방법

Michael Recachinas는 GitHub의 스태프 보안 엔지니어로, 대규모 보안 프로그램을 이끌고 있습니다. 주요 업무는 취약점 관리, 보안 개발 수명주기(SDL) 도구, 개발자 중심의 보안 자동화이며, 조직이 안전한 선택을 쉽게 할 수 있는 시스템을 구축하는 데 집중합니다. ### 대규모 보안 프로그램 운영 - GitHub에서 대규모 보안 프로그램을 주도합니다. - 다양한 팀과 시스템에 적용할 수 있는 확장성 높은 보안 체계를 구축합니다. ### 주요 전문 분야 - **취약점 관리:** 보안 취약점을 식별하고 추적·개선하는 프로세스 - **보안 개발 수명주기 도구:** 개발 과정 전반에 보안을 통합하는 도구와 체계 - **보안 자동화:** 개발자의 업무 흐름 속에서 보안 조치를 자동화하는 기술 ### 개발자 중심의 보안 철학 - 보안을 별도의 부담으로 만들기보다 개발자가 자연스럽게 따를 수 있도록 설계합니다. - “안전한 선택이 가장 쉬운 선택”이 되도록 시스템과 자동화 기능을 구축합니다. - 대규모 환경에서도 일관되게 작동하는 실용적인 보안 솔루션을 지향합니다.

원문 읽기(새 탭에서 열림)
githubvulnerability-managementsecurity-automationsecure-development-lifecycle+1
cloudflare4분 읽기큐레이션 요약

왜 우리는 더 나은 양자내성 서명 알고리즘을 기다릴 수 없는가

RSA와 ECC는 충분히 강력한 양자컴퓨터가 등장하면 깨질 수 있으므로, 양자내성을 갖춘 암호 알고리즘으로의 전환이 필요하다. ML-KEM은 이미 널리 사용되기 시작했지만, 인증을 보호하는 양자내성 서명은 아직 선택지가 제한적이며 당장은 ML-DSA를 사용해야 한다. 더 나은 알고리즘이 개발 중이지만 전환 시점에 맞춰 준비되기 어렵기 때문에, “원하는 알고리즘이 아니라 현재 가진 알고리즘으로 대응해야 한다”는 것이 글의 결론이다. ## 양자내성 암호 전환이 시급한 이유 - RSA와 ECC는 현재 인터넷 보안의 핵심이지만, 충분히 발전한 양자컴퓨터에서는 취약해진다. - 공격자가 지금 암호화된 데이터를 수집해 두었다가 미래에 복호화하는 **harvest-now-decrypt-later** 공격이 가능하다. - NIST는 8년에 걸친 국제 경쟁 끝에 2024년 다음 알고리즘을 표준화했다. - **ML-KEM**: 양자내성 키 캡슐화·암호화 알고리즘 - **ML-DSA**: 양자내성 디지털 서명 알고리즘 - Cloudflare는 이미 대부분의 트래픽에 ML-KEM을 적용하고 있으며, 2029년까지 전체 시스템을 양자내성 상태로 전환하는 것을 목표로 한다. - 암호화만으로는 충분하지 않다. 인증서와 인증 시스템의 서명까지 양자내성으로 바꿔야 무단 접근을 막을 수 있다. ## 당장은 ML-DSA를 사용해야 하는 이유 - ML-DSA는 현재 표준화된 양자내성 서명 중 가장 범용적인 선택지다. - 다만 기존 RSA·ECC에 비해 다음과 같은 단점이 있다. - 공개키와 서명 크기가 훨씬 크다. - 네트워크 전송량이 증가한다. - RSA와 ECC에서 활용하던 일부 최적화 기법을 적용하기 어렵다. - 더 나은 후보가 개발되고 있지만, 표준화와 구현·배포까지는 오랜 시간이 걸린다. - NIST는 새로운 서명 알고리즘 9개를 “signatures on-ramp” 3라운드로 진출시켰다. - 기존 경쟁에서 선정된 Falcon의 후속 표준인 **FN-DSA**도 표준 초안이 곧 나올 예정이다. - 그러나 이 알고리즘들은 현재 진행 중인 양자내성 전환에 맞춰 준비되기 어렵다. - 따라서 완벽한 알고리즘을 기다리기보다, 현재 사용 가능한 ML-DSA로 우선 전환해야 한다. ## 양자내성 서명 알고리즘의 평가 기준 - 글에서는 TLS에 적합한 128비트 보안 수준의 변형을 중심으로 후보들을 비교한다. - 주요 평가 지표는 다음과 같다. - 공개키 크기 - 서명 크기 - 서명 생성 시간 - 서명 검증 시간 - 후보 알고리즘은 보안 수준별로 여러 변형을 제공하며, 3라운드 과정에서 성능과 크기가 바뀔 수 있다. - 일부 알고리즘은 구현상의 위험도 존재한다. - **FN-DSA·SQIsign**: 빠르고 타이밍 부채널 공격에 안전한 구현이 어렵다. - **LMS**: 서명마다 상태를 보존해야 하며, 안전한 서명을 위해 상당한 캐시가 필요하다. - **SLH-DSA의 특정 변형**: 생성 가능한 서명 수가 제한적이다. ## ‘만능 알고리즘’이 없는 상황 - 양자 공격에 취약하다는 점을 제외하면 Ed25519는 여전히 거의 모든 지표에서 가장 뛰어난 서명 알고리즘이다. - 공개키와 서명이 작다. - 서명 생성이 빠르다. - 검증 속도도 대부분의 애플리케이션에 충분하다. - 반면 양자내성 알고리즘에는 Ed25519와 같은 만능 선택지가 없다. - 크게 두 종류로 나뉜다. - **전문가형(specialist)**: 특정 지표에서는 ECC에 근접하지만 다른 부분에 큰 단점이 있다. - **범용형(generalist)**: 모든 지표에서 균형 잡힌 대신, ECC만큼 뛰어난 항목은 적다. - ML-DSA는 대표적인 범용형 알고리즘으로, 크기·성능·구현 난이도에서 극단적인 약점은 없지만 전반적으로 부담이 크다. ## SQIsign: 작은 서명과 느린 서명 생성 - SQIsign은 전송 크기만 보면 ECC의 대체재에 가까운 특성을 보인다. - 서명 크기: 148바이트 - 공개키 크기: 65바이트 - RSA-2048보다도 작다. - 그러나 다음과 같은 약점이 있다. - 후보 중 가장 복잡한 알고리즘이다. - 서명 생성과 검증이 느리다. - 타이밍 부채널 공격에 안전한 서명 생성 구현이 어렵다. - 부채널 방어를 적용하면 성능 저하가 더 커진다. - 2024년과 비교하면 구현이 크게 개선되었다. - 당시에는 타이밍 부채널 안전 구현이 없었다. - 검증 속도도 현재보다 약 20배 느렸다. - 최근에는 알고리즘 단순화와 성능 개선이 진행됐다. - 그래도 안전한 서명 생성은 가까운 미래에 TLS 핸드셰이크처럼 온라인으로 반복되는 작업에 쓰기 어려울 가능성이 높다. - 대신 서명 생성보다 검증이 중요한 오프라인 용도에는 적합할 수 있다. - 인증기관(CA)의 서명 - DNSSEC - SQIsign은 아이소제니(isogeny) 수학에 기반한다. - 같은 계열의 SIKE는 NIST 경쟁 후반에 치명적으로 공격받았다. - 다만 SIKE는 이미 보안 우려가 있었고, 그 때문에 표준화에서 제외된 뒤 추가 검토 대상으로 남아 있었다. - SQIsign은 SIKE의 취약점과 관련된 torsion point를 사용하지 않으므로 동일한 문제가 직접 적용되지는 않는다. - 현재 SQIsign에 대해 알려진 최선의 공격은 잘 선택된 타원곡선처럼 일반적인 전수공격에 가깝다. - 그러나 아이소제니 수학은 매우 풍부하고 공격 표면도 넓어, 충분한 검토 없이 서둘러 표준화해서는 안 된다. ## 실용적인 결론 현재 시스템은 더 나은 서명 알고리즘이 나올 때까지 기다리기보다 ML-DSA를 중심으로 양자내성 전환을 시작해야 한다. 이후 FN-DSA, SQIsign 등 후속 알고리즘이 표준화되고 구현 안정성이 검증되면, TLS·CA·DNSSEC처럼 용도별 특성에 맞춰 ML-DSA와 함께 선택적으로 도입하는 전략이 현실적이다.

원문 읽기(새 탭에서 열림)
post-quantum-cryptographyquantum-computingelliptic-curve-cryptographyml-kem+4
figma3분 읽기큐레이션 요약

GPT-5.6이 이제 Figma Make에서 사용 가능합니다 | Figma 블로그

GPT-5.6이 Figma Make에 추가되어 프롬프트에서 프로토타입과 코드로 전환하는 속도와 첫 결과물의 품질을 높인다. 복잡한 앱도 한 번의 프롬프트로 만들고, 오류가 발생하면 모델이 원인을 찾아 스스로 수정할 수 있다. 또한 기존 Figma 디자인을 높은 충실도로 인터랙티브 프로토타입으로 변환하며, 반응형 레이아웃과 실제 동작하는 상호작용까지 구현한다. ## 빠른 프로토타이핑과 작업 흐름 유지 - GPT-5.6은 아이디어를 working build로 빠르게 전환해 한 번의 작업 세션에서 여러 방향을 탐색할 수 있도록 한다. - 복잡한 디자인에서도 첫 결과물을 빠르게 생성하며, 토큰 효율성도 높다고 소개된다. - 예시로 금융·고딕 스타일의 주식 추적 앱을 한 번의 프롬프트로 제작했다. - 어두운 배경과 앰버·네온 오렌지 텍스트 - 샘플 주가와 수익률 정보 - 스파크라인, 티커, 모듈형 그리드 - 키보드 단축키와 검색 기능 - 빌드 중 오류가 발생해도 작업을 중단하지 않고 원인을 조사해 자체적으로 수정한다. - 실제 테스트에서는 빈 화면이 나타난 원인을 GPT-5.6이 찾아 해결했다. ## 기존 디자인을 충실하게 구현 - Figma Design 파일이나 디자인 명세를 기반으로 기존 시각적 구조를 유지하면서 인터랙티브 프로토타입을 만들 수 있다. - 자연의 소리를 재생하는 오디오 플레이어 사례에서 다음 요소들이 원본 디자인과 유사하게 구현됐다. - 다중 트랙 타임라인 - 재생·일시정지·이전·다음 컨트롤 - 사운드 라이브러리와 아트워크 - 레이아웃, 시각적 계층, 간격, 비율, 스타일 - 정적인 디자인을 실제 동작하는 프로토타입으로 바꾸는 디자인-투-코드 작업을 보다 안정적으로 수행한다. - 오디오 파일 재생뿐 아니라 음악에 반응하는 셰이더 기반 이미지 왜곡 효과도 요청할 수 있다. ## 높은 완성도의 첫 결과물 - 최소한의 프롬프트만으로도 스타일이 정돈된 프로토타입을 생성하는 것이 목표다. - 책장 제품을 판매하는 콘텐츠 중심의 이커머스 페이지 사례에서는 다음 기능이 첫 결과물에 포함됐다. - 제품 설명, 치수, 관리 가이드 - 제품 정보가 채워진 드롭다운 - 책장 사진을 탐색하는 인터랙티브 이미지 갤러리 - 클릭 가능한 메뉴 - 별도의 추가 지시 없이도 화면 크기에 따라 레이아웃이 안정적으로 조정됐다. - 따라서 초기 결과물을 단순한 시안이 아니라 팀이 검토·수정·확장할 수 있는 출발점으로 활용할 수 있다. ## Figma Make에서의 사용 방법 - GPT-5.6은 Figma Make에서 제공된다. - Make의 모델 선택기에서 GPT-5.6을 선택해 사용할 수 있다. - 사용자는 거친 아이디어, 기존 Figma 디자인, 짧은 기능 설명 등을 입력해 프로토타입이나 생산 코드에 가까운 결과물을 생성할 수 있다. 실무에서는 먼저 기존 디자인이나 원하는 사용자 경험을 구체적으로 제공하고, 생성된 첫 결과물을 기반으로 세부 기능과 스타일을 반복 수정하는 방식이 효과적이다. 특히 반응형 동작, 실제 인터랙션, 오류 자동 수정 기능을 활용하면 초기 프로토타입 제작과 팀 리뷰까지의 시간을 줄일 수 있다.

원문 읽기(새 탭에서 열림)
프로토타이핑figma-makedesign-to-code반응형 디자인+3
google4분 읽기큐레이션 요약

SensorFM: 웨어러블 헬스 데이터를 위한 범용 지능과 인터페이스를 향하여

SensorFM은 500만 명의 웨어러블 사용자에게서 수집한 1조 분 이상의 센서 데이터를 학습한 대규모 웨어러블 건강 파운데이션 모델이다. 라벨이 거의 없는 현실 데이터를 자기지도학습으로 처리해 심혈관·대사·수면·정신건강 등 35개 과제에 전이 가능한 생리학 표현을 학습한다. 데이터와 모델 규모를 함께 키울수록 성능이 계속 향상됐으며, 적은 라벨만으로도 새로운 건강 예측 과제에 적용할 수 있음을 보였다. ## 웨어러블 건강 데이터가 가진 가능성과 한계 - 심박수, 움직임, 피부 온도, 혈중산소, 수면 등 웨어러블 데이터는 예방적·개인화 건강관리의 중요한 기반이다. - 사람마다 기본 생리 상태와 생활습관이 달라 같은 신호도 개인별 의미가 다를 수 있다. - 확진 진단, 검사 결과, 검증된 설문 같은 학습 라벨은 수집 비용이 높고 과거 데이터에 retrospectively 적용하기 어렵다. - 기존 모델은 특정 질환이나 결과 하나씩을 대상으로 설계돼 다른 건강 영역으로 일반화하기 어려웠다. ## 1조 분 분량의 다중 센서 사전학습 - 데이터는 2024년 9월부터 2025년 9월 사이 수집된 비식별화 데이터다. - 연구 활용에 동의한 500만 명의 참여자가 포함됐으며, 100개 이상 국가와 미국 50개 주, Fitbit·Pixel Watch 20개 이상 모델을 포괄한다. - 각 참여자에게서 수 주간의 데이터를 추출해 총 20억 시간, 1조 분 이상의 분 단위 신호를 구성했다. - 5개 센서 모달리티에서 도출한 34개 1분 집계 특성을 사용한다. - PPG: 심박수, 심박변이도, 혈중산소포화도 - 가속도계: 움직임과 걸음 수 - 피부전기활동(EDA): 피부 전도도 - 피부 온도 - 고도계: 활동 및 환경 변화 정보 - 데이터는 하루 24시간의 생리·행동 흐름을 표현한다. ## 결측 데이터를 활용하는 자기지도학습 - SensorFM은 정답 라벨 대신 마스킹된 센서 신호를 복원하는 방식으로 학습한다. - 웨어러블 데이터에는 센서 전원 주기, 기기 탈착, 절전 모드, 센서 비활성화 등으로 인한 결측과 단절이 일상적으로 발생한다. - 일반적인 자기지도학습은 이런 구간을 인위적으로 보간하거나 불완전한 구간을 버리지만, 두 방식 모두 편향을 만들거나 데이터를 낭비할 수 있다. - SensorFM의 AIM(Adaptive and Inherited Masking) 방식은 실제 결측 구간과 학습을 위해 인위적으로 가린 구간을 동일하게 취급한다. - 따라서 모델은 결측을 단순한 오류가 아니라 센서 데이터의 자연스러운 특성으로 학습하며, 불완전한 기록에서도 유용한 표현을 생성한다. ## 모델과 데이터 규모를 함께 확장한 효과 - 사전학습 데이터는 약 200만 시간부터 20억 시간까지, 모델은 10만 개부터 1억 개 파라미터까지 네 자릿수 범위로 실험했다. - 데이터와 모델 용량이 증가할수록 복원 손실과 실제 건강 과제 성능이 예측 가능하게 개선됐다. - 전체 데이터로 학습한 최대 모델 SensorFM-B는 가장 작은 모델보다: - 복원 손실 31% 감소 - 분류 과제 평균 AUC 9% 향상 - 회귀 과제 평균 피어슨 상관계수 21% 향상 - 데이터만 또는 모델 크기만 키우는 것보다 두 요소를 함께 확장할 때 가장 큰 효과가 나타났다. - 최대 모델은 35개 과제 중 33개에서 가장 높은 성능을 기록했으며, 성능 포화 징후도 나타나지 않았다. ## 하나의 표현으로 여러 건강 영역에 전이 - 3개 독립적이고 기관생명윤리위원회(IRB) 승인을 받은 전향적 연구에서 총 13,985명의 데이터를 활용했다. - 평가 과제는 다음 6개 영역의 35개 분류·예측 문제로 구성됐다. - 심혈관 건강 - 대사 위험 - 정신건강 - 수면 - 인구통계 - 생활습관 - SensorFM 인코더를 고정하고 그 위에 간단한 선형 헤드만 학습하는 방식으로 성능을 측정했다. - 센서에서 직접 설계한 특징을 이용한 지도학습 기준선보다 35개 중 34개 과제에서 우수했다. - 나이·성별 같은 인구통계 정보를 추가하면 성능이 소폭 상승했지만, 모델이 커질수록 추가 효과는 감소했다. - 이는 대형 모델이 사전학습만으로도 생리학적으로 의미 있는 개인 특성을 어느 정도 학습한다는 점을 시사한다. - 우울증과 불안처럼 센서 신호가 약하고 개인차가 큰 상태에서도 규모 확장의 효과가 특히 컸다. - 라벨 데이터가 일부만 있어도 인구통계 기반이나 수작업 특징 기반 모델을 빠르게 넘어섰다. ## 예측 헤드 구축을 자동화하는 에이전트 구조 - 범용 임베딩을 실제 예측 시스템에 적용하려면 과제별 특징 설계, 모델 구조 선택, 하이퍼파라미터 조정이 필요하다. - 연구진은 이 과정을 자동화하기 위해 여러 LLM 에이전트가 협력하고 경쟁하는 ‘교실(classroom)’ 구조를 만들었다. - 이 구조는 새로운 건강 예측 엔드포인트마다 수작업으로 예측 헤드를 설계해야 하는 부담을 줄이는 것을 목표로 한다. - 제공된 글은 해당 에이전트 시스템의 소개 도중 끝나므로, 구체적인 구성과 성능 수치는 본문만으로 확인할 수 없다. SensorFM의 실용적 의미는 웨어러블 데이터를 질환별 개별 모델이 아니라 재사용 가능한 공통 생리학 표현으로 다룬다는 데 있다. 다만 실제 의료 적용에는 데이터 편향, 개인정보 보호, 임상적 검증, 예측 결과의 해석 가능성에 대한 추가 평가가 필요하므로, 연구 성능을 곧바로 진단 도구로 간주해서는 안 된다.

원문 읽기(새 탭에서 열림)
healthcare-aiself-supervised-learningfoundation-modelwearable-health+2
figma2분 읽기큐레이션 요약

AI 시대에 디자인 팀을 이끄는 방법 | Figma 블로그

AI 시대의 디자인 리더에게 필요한 것은 무조건적인 속도가 아니라, 팀이 침착하게 판단하고 실험하도록 돕는 안정감이다. Jen Dunnam은 도구와 유행을 좇기보다 인간을 위한 디자인이라는 원칙을 유지하고, 비판적 사고와 다양한 경험을 가진 인재를 채용해야 한다고 강조한다. 결론적으로 리더는 긴박감을 더하기보다 팀이 올바른 문제를 정의하고 현명하게 실행하도록 방향을 잡아야 한다. ## 변화 속에서도 침착하게 이끌기 - AI의 발전으로 업계에 불안과 긴박감이 커졌지만, 뛰어난 디자이너들은 이미 충분한 추진력을 갖고 있다. - 리더의 역할은 위기감을 더하는 것이 아니라 팀을 안정시키는 데 있다. - 문제를 작은 단위로 나누고, 전략을 세우며, 적절한 도구를 실험하고, 디자인 원칙을 다듬어야 한다. - AI 도구의 기능이나 유행을 무작정 따라가기보다 디자이너이자 인간으로서 본질에 집중해야 한다. - 기술은 바뀌어도 디자인의 대상은 여전히 인간이므로, 사용자에 대한 이해와 인간 중심 원칙은 변하지 않는다. - 가장 현실적인 접근은 꾸준히 실험하되, 결과를 학습하고 원칙에 따라 판단하는 것이다. ## 비판적 사고를 기준으로 채용하기 - 빠른 제품 출시가 강조되면서 신입 디자이너와 졸업생이 기회를 얻기 어려워졌으므로, 이들의 성장 가능성에 투자할 필요가 있다. - 신입 인재를 제품 출시 경험이 풍부한 시니어와 짝지으면 새로운 관점과 실행력을 결합할 수 있다. - 사용자 연구자 중에서도 인사이트를 수집하는 데 그치지 않고, 디자인과 제품 방향에 대해 결단력 있게 의견을 낼 수 있는 사람을 찾는 것이 유효하다. - 현재 채용에서 특히 가치가 높아진 역량은 비판적 사고다. - 면접에서는 단순히 결과물을 확인하기보다 다음과 같은 경험을 깊이 물어야 한다. - 언제 자신의 의견에 반대했는가? - 이해관계자에게 어떻게 이의를 제기했는가? - 제품에 반영되지 않아 지금도 아쉬운 점은 무엇인가? - AI가 만들어낸 결과물은 시각적으로 매력적이고 그럴듯해 보일 수 있다. 따라서 ‘반짝이는 결과’나 그럴듯한 답을 그대로 받아들이지 않고, 문제와 결과를 검증하는 태도가 중요하다. ## 실용적인 결론 디자인 팀은 AI 도구를 빠르게 익히되, 도구 자체를 목표로 삼아서는 안 된다. 리더는 팀이 인간 중심 원칙을 잃지 않으면서 실험하고, 근거를 바탕으로 반대 의견을 내며, 빠른 실행과 깊이 있는 판단을 함께 발전시키도록 지원해야 한다.

원문 읽기(새 탭에서 열림)
FigmaAI프로덕트 디자인human-centered-design+2
gitlab4분 읽기큐레이션 요약

그린 DevOps: 탄소 측정이 CI/CD 파이프라인에 포함되어야 하는 이유

CI/CD 파이프라인은 매일 상당한 컴퓨팅 에너지와 탄소를 소비하지만, 일반적인 파이프라인 지표에는 그 영향이 드러나지 않는다. 글은 GitLab에 Eco CI와 Carmen을 연동해 파이프라인·인프라·애플리케이션 수준의 탄소 배출량을 측정해야 한다고 주장한다. 측정만으로도 불필요한 테스트 실행, 의존성 재설치, 유휴 서비스 같은 낭비를 찾아 비용과 탄소 배출을 함께 줄일 수 있다. ## CI/CD 파이프라인에 탄소 측정이 필요한 이유 - 현대적인 개발 파이프라인은 하루에도 수백 개의 작업을 실행한다. - AI 기반 테스트, 코드 리뷰, 자동화 작업이 늘면서 과거보다 실행 작업과 에너지 소비가 증가했다. - 파이프라인 로그나 아키텍처 다이어그램에는 컴퓨팅에 따른 탄소 배출량이 표시되지 않는 경우가 많다. - 배출량을 줄이려면 먼저 파이프라인 실행별, 서비스별, 팟(pod)별 배출량을 측정해야 한다. - Green DevOps는 탄소 데이터를 엔지니어링 의사결정에 활용하는 실천 방식이다. ## 파이프라인 수준의 측정: Eco CI - Eco CI는 CI/CD 작업별 에너지 소비량과 탄소 배출량을 측정한다. - 별도 서버나 데이터베이스 없이 가벼운 Bash 스크립트로 실행할 수 있다. - 각 작업의 배출량을 확인하고, 자원 사용량이 큰 작업과 시간에 따른 추세를 파악할 수 있다. - README에 탄소 배출량을 보여주는 배지를 추가할 수도 있다. - 기존 GitLab 파이프라인에 몇 줄을 추가하는 방식이므로 도입 난도가 낮다. - 파이프라인 자체가 이미 관측 대상이므로, 초기 Green DevOps 도구로 적합하다. ## 인프라와 애플리케이션 수준의 측정: Carmen - Carmen(Carbon Measurement Engine)은 Green Software Foundation의 Impact Framework를 기반으로 한다. - Kubernetes에서 실행되는 가상 머신, 팟, 개별 애플리케이션 워크로드까지 측정한다. - 컴포넌트별 CSV 보고서를 생성하며 다음 탄소를 구분한다. - 운영 탄소: 전력 사용으로 발생하는 배출량 - 내재 탄소: 하드웨어 제조와 폐기 과정에서 발생하는 배출량 - 주요 출력 필드는 다음과 같다. - `EnergykWh`: 에너지 소비량 - `TotalCarbonGramsCO2eq`: CO₂ 환산 총 배출량 - 생성된 데이터는 Grafana, FinOps 대시보드, 사내 분석 도구에 직접 연결할 수 있다. - “어떤 서비스가 가장 많은 CO₂를 배출하는가?”, “API 게이트웨이와 데이터 처리 계층 중 어디가 더 큰가?” 같은 질문에 답할 수 있다. ## GitLab 파이프라인에 연동하는 방법 - Eco CI와 Carmen 모두 `.gitlab-ci.yml`에 직접 추가할 수 있다. - Carmen 예시는 다음 작업을 수행한다. - `python:3.12` 이미지 사용 - Node.js, npm, Git, `lsb-release` 설치 - Carmen 저장소를 Git으로 복제 - Impact Framework 관련 npm 패키지 설치 - Carmen을 Python 패키지로 설치 - `carbon-daemon` 실행 - 생성된 결과를 GitLab artifact로 보관 - 결과 artifact는 예를 들어 1주일 동안 보관한 뒤 다운로드해 첫 탄소 보고서로 활용할 수 있다. - Carmen 작업을 별도의 비차단(non-blocking) 작업으로 구성하면 기존 배포 경로를 지연시키지 않는다. ## 측정으로 발견할 수 있는 낭비 - 한 팀은 Eco CI 도입 후 통합 테스트가 전체 파이프라인 배출량에서 예상보다 큰 비중을 차지한다는 사실을 발견했다. - 원인은 테스트 코드가 아니라 매 실행마다 모든 의존성을 처음부터 다시 설치하는 설정이었다. - 의존성 캐시를 추가하면 다음 효과를 동시에 얻을 수 있다. - 테스트 실행 시간 단축 - CI 탄소 배출량 감소 - 개발자 대기 시간 감소 - CI 비용 절감 - Carmen을 스테이징 클러스터에 적용한 결과, 폐기된 기능의 데이터 처리 서비스가 유휴 상태로 계속 실행되고 있었다. - 해당 서비스를 제거함으로써 불필요한 운영 탄소와 내재 탄소 소비를 줄일 수 있었다. - 두 사례 모두 대규모 지속가능성 프로젝트가 아니라, 데이터 가시성에서 출발한 개선이었다. ## 낮은 도입 비용과 실질적인 효과 - Eco CI는 몇 줄의 설정과 Bash 스크립트만으로 추가할 수 있다. - 별도 인프라를 구축하지 않으며 파이프라인에 의미 있는 지연을 추가하지 않는다. - Carmen 역시 독립적인 작업으로 실행할 수 있어 기존 핵심 경로에 영향을 주지 않는다. - 측정 데이터는 향후 탄소 보고와 규제 대응을 위한 조직의 기준선(baseline)이 된다. - 탄소 배출이 적은 코드는 대체로 더 빠르고 저렴하다. - 의존성 캐시, 러너 규모 조정(right-sizing), 불필요한 서비스 제거는 환경 개선이면서 동시에 FinOps 최적화이기도 하다. ## 규제와 기업 요구사항 변화 - 탄소 인식형 엔지니어링은 선택적 활동에서 전문적인 개발 관행으로 자리 잡고 있다. - EU의 기업 지속가능성 보고 지침(CSRD)은 대기업에 클라우드 사용량을 포함한 가치사슬 전반의 배출량 공개를 요구한다. - 기업 고객도 공급업체 선정 과정에서 지속가능성 정책과 배출량 관리 여부를 확인하는 경우가 늘고 있다. - 법적 의무가 생긴 뒤 시작하기보다, 지금부터 작은 범위에서 측정 기준과 내부 운영 습관을 마련하는 편이 유리하다. Eco CI를 단일 GitLab 파이프라인에 먼저 적용해 작업별 탄소 배출량을 확인하고, 이후 Carmen으로 Kubernetes와 서비스 수준까지 범위를 확장하는 접근이 현실적이다. 특히 의존성 캐시, 유휴 리소스 제거, 러너 크기 조정처럼 비용과 성능도 함께 개선하는 항목부터 실행하는 것이 효과적이다.

원문 읽기(새 탭에서 열림)
쿠버네티스CI/CDgitlabDevOps+4