techlist.io
KREN

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

aws3분 읽기큐레이션 요약

에이전트형 AI 애플리케이션 구축을 위한 차세대 Amazon OpenSearch Serverless 소개 | Amazon Web Services

Amazon OpenSearch Serverless 차세대 버전은 AI 에이전트용 검색·벡터 백엔드로, 트래픽이 없을 때는 0까지 축소되고 필요할 때 초당 수천 건까지 확장됩니다. 기존 피크 용량 기준 클러스터 대비 최대 60% 비용을 절감할 수 있으며, 리소스 생성과 용량 확장이 이전 세대보다 크게 빨라졌습니다. Vercel, Kiro, Claude Code, Cursor 등과의 통합으로 인프라 관리 없이 몇 분 안에 프로덕션 수준의 검색 시스템을 구축할 수 있습니다. ## 서버리스 확장성과 비용 최적화 - 트래픽에 따라 용량을 0에서 수천 RPS 수준까지 자동 확장하고, 유휴 상태에서는 다시 0으로 축소합니다. - 기존 OpenSearch Service 클러스터를 피크 트래픽에 맞춰 프로비저닝하는 방식보다 최대 60% 비용을 절감할 수 있습니다. - 리소스 생성 시간은 수초이며, 이전 세대보다 용량 확장 속도가 최대 20배 빠릅니다. - 인덱싱, 검색, GPU 가속에 사용한 OpenSearch Compute Unit(OCU) 기준으로 컴퓨팅 비용이 부과됩니다. - 스토리지는 GB-month 기준으로 별도 과금됩니다. ## 차세대 컬렉션 생성 - AWS Management Console의 **Serverless → Create collection**에서 차세대 OpenSearch Serverless 컬렉션을 생성할 수 있습니다. - 출시 시 지원되는 컬렉션 유형은 다음 두 가지입니다. - `SEARCH`: 전문 검색 - `VECTORSEARCH`: 벡터 검색 - **Express create**를 사용하면 별도 설정 없이 기본값과 보안 정책이 자동 적용됩니다. - 일부 설정은 컬렉션 생성 후에도 변경할 수 있습니다. - 기존 OpenSearch Serverless 인프라를 사용하려면 **Switch to Classic**을 선택해야 합니다. ## 컬렉션 그룹과 용량 설정 - AWS CLI 또는 SDK를 이용해 컬렉션 그룹과 컬렉션을 생성할 수 있습니다. - 컬렉션 그룹에서 차세대 세대(`NEXTGEN`), 대기 복제본, 인덱싱·검색 용량 한도를 설정합니다. - 예시에서는 인덱싱과 검색 용량을 다음과 같이 설정합니다. - 최대 용량: 각각 96 OCU - 최소 용량: 각각 0 OCU - 컬렉션은 상위 컬렉션 그룹의 세대 설정을 상속합니다. - 컬렉션 그룹 생성 시 `standby-replicas ENABLED`를 지정해 대기 복제본을 활성화할 수 있습니다. - 제공된 CLI 예시는 글에서 같은 명령이 중복 제시되어 있으며, 2026년 5월 업데이트에서 최대 인덱싱·검색 용량 기본값이 96으로 수정되었습니다. ## AI 에이전트 개발 플랫폼 통합 - Vercel 콘솔에서 새 OpenSearch 컬렉션을 생성하거나 기존 OpenSearch Serverless 컬렉션을 연결할 수 있습니다. - 애플리케이션 성장에 맞춰 검색 기능을 단계적으로 추가할 수 있습니다. - Claude Code, Cursor, Kiro를 사용하면 아이디어에서 작동하는 프로토타입까지 빠르게 구현할 수 있습니다. - OpenSearch Agent Skills는 검색 도메인 지식, 모범 사례, 다단계 실행 로직을 에이전트에 제공합니다. - Kiro Powers의 OpenSearch Launchpad는 검색 애플리케이션의 아키텍처를 계획하고 구현하는 과정을 안내합니다. ## 제공 범위와 사용 시작 방법 - 차세대 OpenSearch Serverless는 정식 출시되었으며, 기존 OpenSearch Serverless가 제공되는 모든 AWS 상용 리전에서 사용할 수 있습니다. - 콘솔, AWS CLI, AWS SDK를 통해 컬렉션을 생성할 수 있습니다. - 자세한 관리 방법과 가격은 Amazon OpenSearch Service 공식 문서와 가격 페이지에서 확인할 수 있습니다. AI 에이전트의 검색·벡터 기능을 구축한다면, 트래픽 변동이 크거나 초기 인프라 운영 부담을 줄이고 싶은 경우 차세대 OpenSearch Serverless가 적합합니다. 특히 Vercel이나 Kiro를 사용하는 팀은 Express create와 기본 통합 기능을 활용해 빠르게 시작한 뒤, 필요에 따라 OCU 한도와 검색 기능을 확장하는 방식을 추천합니다.

원문 읽기(새 탭에서 열림)
AI 에이전트claude-codevector-dbaws-cli+4
dropbox4분 읽기큐레이션 요약

코드 생성을 넘어: AI 에이전트 시대의 엔지니어링 생산성을 다시 생각하다

Dropbox는 AI 코딩 도구가 코드 작성 속도는 높였지만, 리뷰·CI·테스트·배포·운영을 새로운 병목으로 만들었다고 설명합니다. 따라서 생산성의 핵심은 코드 생성량이 아니라 전체 개발 생명주기가 더 많은 변경을 안정적으로 흡수하고 고객 가치로 전환하는 능력입니다. Dropbox는 코딩 에이전트 플랫폼, 새로운 생산성 지표, 교육과 가드레일을 통해 AI 중심의 개발 운영 모델을 구축하고 있습니다. ## 코파일럿에서 자율형 에이전트로 - 초기 AI 코딩 도구는 코드 설명, 스니펫 생성, 질의응답 등으로 엔지니어 옆에서 작업을 보조하는 코파일럿 역할을 했습니다. - 에이전트는 범위가 정해진 작업을 받아 다음 과정을 수행할 수 있습니다. - 코드베이스 조사 - 파일 수정 - 테스트 실행 - 실패 원인 분석과 재시도 - 사람이 검토할 수 있는 결과물 생성 - 엔지니어는 여전히 요구사항, 아키텍처, 품질, 배포에 대한 최종 책임을 집니다. - 에이전트 도입으로 여러 작업을 병렬로 진행하고, 반복적인 구현 업무를 위임할 수 있게 됐습니다. - 반면 코드와 풀 리퀘스트가 빠르게 증가하면서 코드 리뷰, 테스트 인프라, 검증, 릴리스 조정, 운영 시스템에 부담이 커졌습니다. ## Nova: Dropbox의 에이전트 플랫폼 - Nova는 자연어로 작업을 설명하면 통제된 환경에서 AI 코딩 에이전트를 실행할 수 있는 Dropbox의 내부 플랫폼입니다. - Nova의 핵심 가치는 모델 자체보다 다음과 같은 주변 시스템에 있습니다. - 코드베이스와 내부 개발 관행에 대한 컨텍스트 - 안전한 실행 환경 - 기존 개발 워크플로와의 통합 - 검증 절차와 사람의 최종 리뷰 - Nova가 생성한 변경은 작업 정의, 에이전트 실행, 결과 검증, 사람의 승인이라는 구조화된 흐름을 거칩니다. - 현재 Dropbox 풀 리퀘스트의 약 12분의 1이 Nova를 통해 생성되고 있습니다. - 기능 개발뿐 아니라 다음과 같은 고수고 작업에도 활용됩니다. - 마이그레이션 - 불안정한 테스트 수정 - 버그 조사 - 의존성 업데이트 - 시스템 유지보수 작업 ## 코드량이 아닌 제품 전달 속도 측정 - AI로 PR 생성량이 늘어나면 단순한 PR 처리량은 생산성을 충분히 설명하지 못합니다. - 함께 측정해야 할 지표는 다음과 같습니다. - 코드 리뷰 대기 및 처리 시간 - CI 비용과 처리 지연 - 재작업 비율 - 결함 비율 - 테스트의 첫 실행 성공률 - 최종적으로 고객에게 전달되는 가치 - Dropbox는 생산성을 네 단계로 나눠 측정합니다. - **Fuel**: AI 도구가 실제로 사용되는 정도 - **Adoption**: 팀의 개발 워크플로가 얼마나 변화했는지 - **Output**: AI가 실제 프로덕션 작업에 기여한 정도 - **Impact**: 아이디어가 고객 가치로 전환되는 시간과 제품 전달 속도의 개선 - 생산성 향상은 속도만으로 판단할 수 없으며, 품질과 신뢰성을 유지하는지가 중요합니다. - 코드 생성이 빨라져도 결함과 재작업이 늘어난다면 실질적인 생산성 향상으로 볼 수 없습니다. ## 엔지니어링 업무 방식의 변화 - 에이전트가 구현을 더 많이 담당하면서 엔지니어의 역할은 다음 영역으로 이동합니다. - 문제와 의도 정의 - 요구사항과 코드베이스 맥락 정리 - 생성된 변경 검토 - 아키텍처 및 품질 판단 - 최종 결과에 대한 책임 - 도구만 배포한다고 에이전트 방식이 정착되지는 않습니다. - Dropbox는 실습 교육, 해커톤, 부트캠프, 워크플로 사례 공유, 동료 주도 학습 등을 활용해 팀의 적응을 지원합니다. - 팀마다 도입 속도와 필요한 안전장치가 다릅니다. - 고위험 시스템은 더 강한 검증과 명확한 가드레일이 필요합니다. - 격리되거나 위험도가 낮은 코드 영역은 더 빠르게 자동화할 수 있습니다. - 모든 작업을 에이전트로 처리하는 것이 목표가 아니라, 효과가 큰 영역에서 안전하고 반복 가능한 방식으로 사용하는 것이 목표입니다. ## AI가 옮겨 놓은 병목 - AI는 소프트웨어 개발의 병목을 제거하기보다 다른 단계로 이동시킵니다. - 코드 생성이 빨라질수록 다음 영역이 새로운 제약이 됩니다. - 리뷰 처리 용량 - 테스트와 검증 - 릴리스 조정 - 운영 및 장애 대응 - 따라서 조직은 모델이나 코드 생성 기능만 강화할 것이 아니라 다음 시스템에 투자해야 합니다. - 풍부한 코드베이스 컨텍스트 - 에이전트 오케스트레이션 - 품질 관리와 거버넌스 - 개발 워크플로 통합 - 결과와 고객 영향을 측정하는 체계 - 경쟁력은 누구나 접근할 수 있는 기반 모델보다, 그 모델을 실제 조직의 개발 과정에 연결하는 내부 시스템에서 나온다는 것이 글의 결론입니다. 실무적으로는 AI 도구 도입량보다 리뷰 지연, 테스트 성공률, 결함·재작업, 배포 리드타임, 고객 가치 전달 속도를 함께 추적하는 것이 중요합니다. 작은 범위의 반복 업무부터 에이전트를 적용하고, 사람의 승인과 명확한 안전장치를 포함한 워크플로로 확장하는 접근이 적절합니다.

원문 읽기(새 탭에서 열림)
AI 에이전트CI/CD자동화코드 리뷰+3
slack4분 읽기큐레이션 요약

Slack AI: 멀티 클라우드로 가는 길

Slack AI는 초기 SageMaker 기반 운영에서 출발해 Amazon Bedrock으로 이전하며, 수동적인 GPU·용량 관리에서 관리형·다중 클라우드 오케스트레이션으로 발전했다. 이 과정의 목표는 단순히 최신 LLM을 도입하는 것이 아니라, GPU 부족과 지역 장애에도 견디면서 엔터프라이즈 수준의 보안·성능·신뢰성을 유지하는 것이었다. 특히 부하 테스트, 품질 비교, 점진적 트래픽 전환을 통해 고객 영향 없이 마이그레이션을 완료한 점이 핵심이다. ## SageMaker 기반 초기 아키텍처 - 2023년 초 Slack은 AWS SageMaker를 LLM 서빙의 출발점으로 선택했다. - SageMaker는 다음 요구사항을 충족했다. - 보안성과 FedRAMP 준수 - 모델 가용성과 제어권 - Escrow VPC를 활용한 제로 지식 환경 - Slack의 데이터는 외부에 노출되지 않았고, 모델 제공업체의 비공개 가중치에도 Slack이 접근할 수 없었다. - 글로벌 가용성을 위해 여러 AWS 리전에 컨테이너를 배포했다. - 운영팀은 리전 간 IAM 역할, 모델 엔드포인트 라우팅, 용량 계획, 자동 확장을 직접 관리해야 했다. ## 자체 운영에서 발생한 비용 - **확장 지연** - 인스턴스 초기화 시간이 길어 즉각적인 확장이 어려웠다. - **GPU 부족** - A100, H100 같은 고성능 NVIDIA GPU를 필요한 시점에 확보하기 어려웠다. - **과잉 프로비저닝** - 피크 시간대 SLA를 맞추기 위해 유휴 리소스를 미리 확보해야 했다. - 2024년 초에는 On-Demand Capacity Reservations와 cron 기반 사전 확장으로 문제를 완화했지만, 엔지니어링 리소스가 인프라 조정 업무에 과도하게 투입됐다. - 결국 Slack은 수동 조정이 아니라 자동화된 용량 확보가 필요하다고 판단했다. ## SageMaker의 모델 출시 지연 - AWS가 관리형 LLM 서비스인 Bedrock을 우선적으로 발전시키면서, SageMaker 기반 커스텀 서빙 환경은 최신 모델 도입에서 뒤처지기 시작했다. - Escrow VPC에서 Anthropic 모델을 호스팅하는 방식은 Bedrock보다 모델 업데이트와 최적화 적용이 수주에서 수개월 늦었다. - AI 기능 품질이 경쟁력과 직결되는 Slack에는 이러한 지연이 큰 문제가 됐다. ## Amazon Bedrock으로의 전환 - 2024년 중반 Slack은 FedRAMP Moderate 인증과 필요한 보안 수준을 갖춘 Bedrock으로 이전했다. - 전환의 주요 이점은 다음과 같다. - 개별 GPU 인스턴스와 엔드포인트를 직접 확장하지 않아도 되는 운영 단순화 - 최신 모델을 공개 직후 빠르게 사용 가능 - 사용 패턴에 따른 비용·용량 최적화 - 예측 가능하고 지연 시간에 민감한 채널 요약에는 **Provisioned Throughput(PT)**를 사용했다. - 간헐적이고 예약 실행되는 Recap 작업에는 **On-Demand(OD)**를 사용해 유휴 용량 비용을 줄였다. ## Model Unit 기반 용량 관리 - Bedrock의 용량은 GPU 인스턴스가 아니라 **Model Unit(MU)**로 측정된다. - 각 MU는 분당 토큰 수로 표현되는 일정한 처리량을 제공한다. - Slack은 하드웨어 세부사항 대신 필요한 토큰 처리량에 집중할 수 있게 됐다. - 마이그레이션 위험을 줄이기 위해 먼저 Provisioned Throughput 환경을 이전하고, On-Demand 환경은 후속 단계로 진행했다. ## 무중단 마이그레이션 전략 - **규정 준수 검토** - Legal, Security, FedRAMP 승인을 받은 뒤 운영 트래픽을 전환했다. - **용량 검증** - 다양한 트래픽 패턴에서 SageMaker와 동일한 성능을 내는 MU 수를 부하 테스트로 산정했다. - **품질 비교** - A/B 테스트와 평가 프레임워크로 모델 출력 품질과 지연 시간을 나란히 비교했다. - **점진적 롤아웃** - 기능 플래그를 사용해 트래픽을 단계적으로 이동했다. - 문제가 발생하면 즉시 이전 환경으로 롤백할 수 있도록 구성했다. - 대규모 부하 테스트와 shadow request를 통해 기존 환경과의 성능 패리티를 확인했고, 고객에게 영향을 주는 장애 없이 전환을 완료했다. ## Bedrock 도입 이후의 운영 개선 - 엔지니어들은 GPU 수명주기, 엔드포인트 관리, 용량 예약 대신 모델 성능과 기능 품질에 집중할 수 있게 됐다. - 최신 모델을 더 빨리 적용하면서 AI Search에 고도화된 추론 모델을 신속히 도입했고, 더 정교하고 맥락에 맞는 답변을 제공할 수 있었다. - 인프라 운영은 다음과 같이 단순화됐다. - Slack이 필요한 quota를 요청 - AWS가 MU를 프로비저닝 - Slack이 해당 용량으로 트래픽을 처리 - 수요가 발생한 뒤 대응하는 방식에서, 몇 주 앞을 내다보고 용량을 예약하는 전략적 예측 방식으로 전환했다. - Slack이 강조한 운영 원칙은 **먼저 측정하고, 점진적으로 이전하며, 지속적으로 모니터링하는 것**이다. ## 남은 효율성 문제 - Provisioned Throughput은 안정적이고 예측 가능한 워크로드에는 효과적이었지만 모든 트래픽에 최적은 아니었다. - 미국 동부·서부 지역의 업무 시작 시간처럼 특정 시간대에 AI 요약과 검색 요청이 급증하는 패턴을 처리하려면 높은 MU 기본 용량을 유지해야 했다. - 그 결과 피크 시간대 성능을 보장하는 대신, 사용량이 낮은 시간에는 일부 용량이 유휴 상태로 남는 과잉 프로비저닝 문제가 여전히 존재했다. ## 실용적인 결론 LLM 인프라를 확장할 때는 직접 GPU를 운영하는 것보다 관리형 서비스가 모델 접근성과 운영 효율을 크게 높일 수 있다. 다만 서비스 이전은 단순한 엔드포인트 교체가 아니라, 부하·품질·규정 준수 검증과 점진적 롤백 체계를 포함한 통제된 마이그레이션으로 진행해야 한다.

원문 읽기(새 탭에서 열림)
대규모 언어 모델model-servinggpuaws-bedrock+3
cloudflare4분 읽기큐레이션 요약

Cloudflare의 데이터 플랫폼과 그 위에 구축한 AI 에이전트 이야기

Cloudflare는 여러 데이터베이스와 스트림에 흩어진 데이터를 하나의 SQL 인터페이스로 통합하기 위해 데이터 레이크하우스 플랫폼 **Town Lake**를 구축했다. Town Lake는 신선하고 정확한 원천 데이터와 빠른 분석용 샘플 데이터를 함께 제공하며, 권한 관리·PII 탐지·감사 기능을 기본으로 포함한다. 그 위에 자연어로 질문하면 감사 가능한 답을 제공하는 AI 데이터 에이전트 **Skipper**를 구축해 데이터 접근성을 높이려 했다. ## 데이터 파편화와 접근성 문제 - Cloudflare는 초당 10억 건이 넘는 이벤트를 처리하고 330개 이상의 도시, 120개 이상의 국가에서 네트워크를 운영한다. - 데이터가 다음과 같은 다양한 시스템에 분산되어 있었다. - Postgres: 계정 및 업무 메타데이터 - ClickHouse: 분석 이벤트 - BigQuery: 집계 데이터 - R2: 원시 로그 - Kafka: 실시간 이벤트 스트림 - 시스템마다 인증 방식, 쿼리 언어, 보존 기간이 달라 간단한 질문에도 여러 시스템을 알고 있어야 했다. - 올바른 테이블과 조인 방법이 조직 내 암묵지에 의존했다. - 예를 들어 ClickHouse의 사용량 테이블과 Postgres의 고객 차원 테이블을 연결하려면 별도의 고객 ID 변환 규칙을 알아야 했다. - 기존 분석 파이프라인은 초당 7억 건 이상의 이벤트를 처리하기 위해 데이터를 샘플링했다. - 대시보드에는 적합하지만 청구 금액 계산이나 보안 조사처럼 정확한 전체 데이터가 필요한 작업에는 부적합했다. - 일부 내부 리포팅 시스템은 외부 업체와 다른 클라우드에 의존하고 있어 비용과 운영상 종속성도 발생했다. ## 구축 목표 - 적절한 권한과 업무상 필요가 있는 모든 직원이 Cloudflare 데이터를 한곳에서 조회할 수 있도록 했다. - 사용 목적에 따라 서로 다른 데이터 품질을 제공하려 했다. - 청구·보안 조사: 신선하고 정확한 비샘플링 데이터 - 대시보드·탐색: 빠른 응답을 위한 다운샘플링 데이터 - PII를 자동으로 식별하고 민감한 테이블은 기본적으로 제한했다. - 모든 데이터 접근을 감사할 수 있도록 하고, 권한을 일정 기간 동안만 부여하도록 설계했다. - R2, Workers, Cloudflare Access, Workflows 등 Cloudflare 자체 제품 위에 플랫폼을 구축했다. - 최종적으로 SQL을 몰라도 자연어로 데이터를 조회할 수 있는 인터페이스를 제공하는 것이 목표였으며, 이것이 Skipper로 이어졌다. ## Town Lake의 데이터 레이크하우스 구조 Town Lake는 오브젝트 스토리지에 저장된 데이터를 쿼리 엔진으로 조회하고, 메타데이터 계층을 통해 데이터베이스처럼 사용하는 레이크하우스 구조다. - **Apache Trino** - 통합 쿼리 엔진으로 사용된다. - 하나의 SQL 쿼리에서 Postgres, ClickHouse, R2의 Iceberg 테이블을 함께 조인할 수 있다. - 필터를 ClickHouse로 푸시하고, Postgres의 계정 차원 데이터와 R2의 청구 집계 데이터를 결합하는 식으로 쿼리를 최적화한다. - **R2 Data Catalog와 Apache Iceberg** - 차갑거나 따뜻한 데이터를 R2에 저장한다. - Iceberg의 스키마 변경, 시점 조회(time travel), 파티션 변경, 데이터 컴팩션 기능을 활용한다. - 오래된 데이터는 분 단위에서 시간 단위, 다시 일 단위로 집계해 저장 비용을 줄인다. - Parquet 파일을 R2에 저장하면 동일한 데이터를 OLAP 데이터베이스에 보관하는 것보다 비용이 낮다. - **DataHub** - 테이블, 컬럼, 소유 팀, 데이터 계보(lineage), 용어집 정보를 관리한다. - 사용자가 특정 테이블의 의미를 물으면 컬럼 설명, 담당 팀, 상위 입력 테이블, 하위 소비 테이블까지 제공한다. ## 권한 관리와 데이터 거버넌스 - **Lifeguard**가 데이터 접근 제어를 담당한다. - 접근 규칙은 D1에 저장하고, 내부 접근 관리 시스템에서 사용자·그룹 정보를 동적으로 가져온다. - 이 정보를 결합해 JSON 정책을 생성하고 Trino가 HTTP를 통해 읽도록 한다. - Skipper와 Gateway에도 기본적인 권한 정보를 전달해 쿼리가 실행된 뒤가 아니라 진입 단계에서 접근을 차단할 수 있다. - 권한을 업무 목적과 기간에 맞춰 부여함으로써 민감 데이터에 대한 불필요한 상시 접근을 줄인다. - 데이터 접근 기록을 남겨 누가 어떤 데이터에 접근했는지 감사할 수 있도록 했다. ## PII 자동 탐지 - **Skimmer**는 테이블의 모든 컬럼을 지속적으로 검사하는 PII 탐지 스캐너다. - 각 컬럼에서 행을 샘플링하고 Workers AI를 이용해 PII 포함 여부를 분류한다. - 이를 통해 데이터 카탈로그에 민감도 정보를 자동으로 반영하고, 민감한 테이블이나 컬럼의 기본 접근 정책을 강화할 수 있다. ## 자연어 데이터 에이전트 Skipper - Skipper는 Town Lake 위에서 동작하는 AI 데이터 에이전트다. - 사용자가 영어로 질문하면 관련 데이터와 메타데이터를 찾아 SQL 기반 답변을 생성한다. - 데이터 위치, 테이블 구조, 조인 관계, 권한을 사용자가 직접 알 필요를 줄이는 것이 목적이다. - 자연어 질의의 예시는 다음과 같다. - 최근 분기의 매출 기준 상위 100개 고객 조회 - 특정 ASN에서 발생한 고위험 Bot Management 이벤트 검색 - 일정 금액 이상 지출한 고객의 청구 지원 티켓 분석 - 답변은 단순한 생성형 응답이 아니라 데이터에 근거하고 감사 가능한 형태여야 한다는 점이 중요하다. ## 실용적인 시사점 데이터 플랫폼을 구축할 때는 저장소 통합만으로는 충분하지 않다. 통합 쿼리 엔진, 메타데이터 카탈로그, 데이터 계보, 세분화된 권한 관리, PII 탐지, 감사 기능을 함께 설계해야 데이터가 실제 조직 전체에서 활용된다. 또한 정확성이 필요한 업무와 속도가 중요한 분석 업무에 동일한 데이터 처리 방식을 적용하지 않고, 목적에 따라 원천 데이터와 샘플 데이터를 구분하는 전략이 효과적이다.

원문 읽기(새 탭에서 열림)
AI 에이전트sqlapache-icebergdata-governance+4
stripe4분 읽기큐레이션 요약

1인 창업이 사상 최고 수준에 이르렀다: 최고의 성과를 내는 사람들에게는 이런 공통점이 있다

2026년 2분기 Stripe Atlas를 통해 설립된 C corporation 중 공동창업자 없는 1인 창업 기업이 63%로 역대 최고치를 기록했다. 그러나 1인 창업 기업의 성과 격차는 커지고 있으며, 상위 10%는 AI 기반 제품, 글로벌 판매, B2B 시장, 초기 고객 유지율에서 중간 수준의 창업자보다 뚜렷한 우위를 보였다. 특히 최상위 부트스트랩 기업은 공동창업자 기업과의 매출 격차를 거의 따라잡고 있다. ## 1인 창업 기업의 성과 격차 확대 - 2025년 1인 창업 기업의 설립 후 6개월간 중간 매출은 전년 대비 23% 감소했다. - 반면 상위 10% 기업의 매출은 19% 증가했다. - 4년 전 상위 10%와 중간 창업자의 초기 6개월 매출 차이는 약 34배였지만, 2025년에는 61배로 커졌다. - 연 매출 10만 달러 이상을 올리는 솔로프러너 수는 2022년 이후 3분의 1 증가했다. - 분석 대상은 2022~2023년에 설립되어 최소 2년간 매출 데이터가 있는 수천 개의 Stripe Atlas 기업이다. ## AI를 핵심 기능으로 삼는 제품 - 상위 10% 1인 창업자는 중간 수준 창업자보다 AI 네이티브 기업을 만들 가능성이 약 2배 높았다. - AI 네이티브 기업은 설립 2년 후 다른 1인 창업 기업보다 거의 2배 많은 매출을 기록했다. - 이 결과는 소수의 초대형 성공 사례 때문이 아니라, 50~95백분위 구간 전반에서 AI 기업이 더 높은 성과를 냈기 때문이다. - 99백분위 매출은 AI 기업과 비AI 기업이 거의 비슷해, AI의 효과가 극단적인 대박보다는 전반적인 성과 분포 개선에 있음을 보여준다. - 기술적 배경보다 문제 해결력, 빠른 출시, AI를 활용한 반복 개발, 소셜미디어 기반 유통 역량이 중요해지고 있다. ## 출시 초기부터 글로벌 시장 공략 - 첫 달부터 상위 10% 창업자는 평균 10개 국가에 판매했지만, 중간 창업자는 평균 3개 국가에 그쳤다. - 24개월 후에는 각각 미국 외 40개국과 6개국으로 격차가 확대됐다. - 상위 10% 기업은 매출의 51%를 해외에서 얻었고, 중간 기업은 해외 매출 비중이 2%에 불과했다. - 미국 외 지역에 기반을 둔 상위 창업자가 미국 시장을 조기에 공략한 점도 성과 차이에 영향을 줬다. - 소프트웨어 분야에서 규모가 크고 지출 수준이 높은 미국 시장을 일찍 확보하면 성장 속도를 높일 수 있다. ## B2B에 집중하는 사업 모델 - 상위 10% 1인 창업자는 중간 수준 창업자보다 B2B 기업을 만들 가능성이 약 30% 높았다. - 24개월 시점에서 중간 수준 B2B 기업의 매출은 중간 수준 B2C 기업보다 4배 이상 많았다. - 상위 10% 안에서도 B2B 기업이 B2C 기업보다 거의 2배 높은 매출을 기록했다. - 이러한 차이는 투자 유치 여부만으로 설명되지 않는다. 부트스트랩 기업에서도 B2B 창업자가 중간값과 상위 10% 모두에서 더 높은 매출을 올렸다. - 특정 고객군의 반복적인 문제를 해결하고, 여러 고객이 요청한 기능에 집중하는 방식이 효과적이었다. ## 초기 고객 유지율과 반복 결제 - 상위 10% 기업은 첫 달 고객의 약 30%를 다음 달에도 유지했지만, 중간 기업의 유지율은 8%였다. - 상위 기업은 이탈 고객을 약 3개월 더 일찍 되찾기 시작했다. - 2년 차 초반, 첫 달에 확보한 고객의 지출액은 상위 기업에서 초기보다 47% 증가했다. 이는 중간 기업의 증가폭보다 약 2배 크다. - B2B 기업에서는 상위 10% 창업자의 첫 달 고객 유지율이 중간 창업자보다 6배 높았다. - 정기 결제 모델도 영향을 미쳤다. 상위 B2B 창업자는 중간 그룹보다 26%포인트, B2C 창업자는 20%포인트 더 높은 비율로 반복 결제를 사용했다. - 완벽한 제품을 오래 준비하기보다 유료 고객에게 먼저 검증하고, 빠르게 출시한 뒤 반복 개선하는 접근이 강조된다. ## 공동창업자 기업과의 비교 - 초기에는 1인 창업 기업의 매출이 공동창업자 기업보다 높았지만, 24개월 시점에는 역전됐다. - 상위 10% 공동창업자 기업의 매출은 상위 10% 1인 창업자보다 53% 많았다. - 투자 유치 효과를 고려해도 공동창업자 기업의 우위는 유지됐다. - 다만 부트스트랩 기업 중 최상위 1%를 비교하면 차이는 5%에 불과했다. - 뛰어난 솔로 창업자는 개발과 출시뿐 아니라 채용, 조언자, 창업자 네트워크를 활용해 자신의 역량을 확장하는 특징을 보였다. ## 실용적인 결론 1인 창업을 고려한다면 AI를 단순 보조 도구가 아니라 제품의 핵심 기능으로 활용하고, 처음부터 해외 고객을 대상으로 설계하는 것이 유리하다. 또한 광고나 대규모 투자보다 유료 B2B 고객의 반복 문제를 해결하고, 정기 결제와 초기 고객 유지율을 빠르게 검증하는 전략이 중요하다.

원문 읽기(새 탭에서 열림)
AIsaasno-coderecurring-billing+3
line4분 읽기큐레이션 요약

도쿄에서 후쿠오카까지, 현장에서 답을 찾다 - CS InquiryChat 도입기

타사 채팅 솔루션의 종료를 계기로 데마에칸은 자체 메시징 플랫폼인 InquiryChat으로 전환했다. 이 프로젝트는 연간 라이선스 비용을 0원으로 줄였을 뿐 아니라, 상담 재활성화 비율을 약 20% 낮추고 보안·운영 유연성·사용자 경험을 개선했다. 성공적인 전환의 핵심은 단순한 기능 복제가 아니라, 현장 관찰과 사용자 테스트를 통해 실제 업무 맥락을 파악하고 이해관계자 간 합의를 이끌어낸 데 있었다. ## 자체 솔루션 전환의 배경과 목표 - 기존 타사 채팅 서비스의 종료가 예정되면서 후속 솔루션 도입과 자체 개발을 비교 검토했다. - InquiryChat을 선택한 이유는 다음과 같다. - 라이선스 비용을 제거할 수 있음 - 데마에칸의 운영 프로세스에 맞춘 유연한 커스터마이징 가능 - 내부 담당자를 통한 실시간 연동과 운영 지원 가능 - 고객 정보를 보안 문제 없이 활용 가능 - 실시간 분석·리포팅 제공 - 기존 서비스에는 다음과 같은 개선 과제가 있었다. - 상담원이 사용자가 전송하지 않은 메시지를 미리 볼 수 있는 보안 취약점 - 사용자가 이탈하면 세션이 유지되지 않아 상담을 처음부터 반복해야 하는 문제 - 다른 플랫폼과의 통합 및 사용자 정의가 제한적임 - 안정적으로 사용하던 도구를 교체하는 만큼, 상담원 교육과 업무 프로세스 변화, 서비스 중단 없는 전환이 필요했다. ## 문서 중심 요구 사항의 한계 - 초기 요구 사항은 기존 기능을 단순히 나열한 목록에 가까웠다. - 기능이 실제로 사용되는지, 현장 업무에 필요한지, InquiryChat에서 그대로 제공할 수 있는지 판단하기 어려웠다. - 요구 사항이 협업 부서를 거쳐 전달되면서 실제 상담원과 매니저의 업무 맥락이 희석됐다. - 기능을 다음 세 가지로 재분류해 우선순위를 정리했다. - 기본 제공 기능 - 커스터마이징 또는 추가 검토가 필요한 기능 - 신규 개발이 필요한 기능 ## 후쿠오카 콜센터 현장 조사 - 실제 사용자인 상담원과 매니저를 이해하기 위해 후쿠오카의 두 콜센터를 직접 방문했다. - 피크 시간대 업무를 모니터링한 뒤 여러 상담원과 매니저를 인터뷰해 공통 요구 사항을 도출했다. - 현장 조사로 불필요한 기능과 필수 기능을 구분할 수 있었다. - 매니저에게 지원을 요청하는 메시지 기능은 실제로 손짓이 더 빨라 거의 사용되지 않음 - 사무실에서 소리를 켤 수 없어 채팅 단절 음성 경고 기능은 실효성이 낮음 - 상담 내용을 CS 솔루션에 연동하는 기능은 상담 기록과 공유에 필수적이므로 우선순위를 높여 구현 - 직접 관찰한 근거를 바탕으로 협업 부서와 기능 우선순위를 설득할 수 있었다. ## 복잡한 협업 구조를 관리한 PM 전략 - 한국과 일본의 여러 부서, 외주 콜센터가 참여하는 구조에서 공통된 목표와 기준을 만드는 데 집중했다. - Jira 대시보드를 설계해 개발 진행 상황을 실시간으로 시각화하고 지표 기반 의사 결정을 가능하게 했다. - 파편화된 요구 사항을 하나의 마스터 사양서로 통합해 단일 기준을 마련했다. - 기획 의도가 실제 구현에 반영됐는지 확인하기 위해 기획·개발 단계의 내부 QA를 주도했다. - 출시 직후 현장에서 활용할 수 있도록 상세 운영 가이드도 제작했다. ## FGT를 통한 실제 사용자 경험 검증 - 화상 회의와 문서만으로는 세밀한 사용 경험을 검증하기 어렵다고 판단해 FGT를 진행했다. - 사용자와 상담원 역할을 나누고, 고객 문의 시작부터 문제 해결까지의 전체 시나리오를 직접 수행했다. - FGT 과정은 배경 설명, 수행 과제, 실습, 설문, Q&A 등으로 구성됐다. - 백엔드 연동에 집중하던 개발자도 실제 앱 사용 흐름을 경험하면서 문제를 QA 전에 발견하고 수정할 수 있었다. - 주요 피드백과 개선 사항은 다음과 같다. - 역할과 현재 상태를 더 직관적으로 표시할 필요 - 링크에 날짜뿐 아니라 시간도 표시 - Android 푸시 안정화 - 키패드와 채팅 입력창이 겹치는 문제 개선 - 푸시 알림 제목 변경 - 일부 대화 로그가 CS 솔루션에 누락되는 문제 해결 ## 보안과 상담 효율 사이의 균형 - 기존 상담원이 선호하던 ‘입력 중 메시지 미리보기’는 고객이 전송하지 않은 데이터까지 상담원이 볼 수 있다는 보안·정보 주권 문제를 안고 있었다. - 상담원에게는 고객 답변을 미리 파악해 평균 처리 시간(AHT)을 줄이는 유용한 기능이었다. - 단순히 기능을 삭제하면 상담 효율이 떨어질 수 있어, 대안으로 ‘입력 중 표시기’를 제안했다. - 상담원은 고객이 메시지를 작성 중인지 알 수 있지만, 실제 입력 내용은 볼 수 없도록 설계해 편의성과 개인정보 보호를 절충했다. - 이 과정은 기술 내재화가 기존 기능을 그대로 복제하는 것이 아니라, 운영 효율과 보안 원칙을 재검토하는 과정임을 보여준다. ## 실용적인 시사점 자체 솔루션 전환에서는 요구 사항 문서보다 실제 사용 현장 관찰이 우선되어야 한다. 또한 기능을 그대로 옮기기보다 보안, 업무 효율, 사용자 경험을 함께 평가하고, FGT 같은 실사용 검증을 통해 출시 전에 문제를 발견하는 것이 효과적이다.

원문 읽기(새 탭에서 열림)
Androiduser-researchjirainformation-security+3
discord3분 읽기큐레이션 요약

Steal a Brainrot, Grow a Garden, Brookhaven RP 등을 위한 공식 디스코드 연동

Discord가 Roblox 게임 개발자를 위한 공식 Social SDK 통합을 출시해 계정 연동, 커뮤니티 안전 관리, Rich Presence, 게임 초대 기능을 제공한다. 이를 통해 게임 서버는 실제 플레이어만 참여하도록 제한하고, 게임 내 제재를 Discord 서버 관리와 연계할 수 있다. 모든 기능은 사용자의 명시적 동의와 개인정보 설정을 기반으로 작동하며, 사용자는 언제든 연동을 해제할 수 있다. ## Roblox 게임과 Discord의 공식 연동 - **Steal a Brainrot**, **Grow a Garden**, **Brookhaven RP**, **Driving Empire**, **NFL Universe Football** 등이 Discord Social SDK 통합을 시작했다. - Roblox 게임 개발자는 기존의 서드파티 앱 대신 Discord의 네이티브 계정 연동 기능을 제공할 수 있다. - 공식 게임 서버 운영에 필요한 커뮤니티 관리, 소셜 기능, 초대 흐름을 하나의 통합 환경에서 구현할 수 있다. ## 계정 연동을 통한 커뮤니티 안전 강화 - 공식 Discord 서버에 입장할 때 Roblox 계정과 특정 게임을 연결하도록 요구할 수 있다. - 게임을 실제로 플레이하는 사용자만 서버에 참여하도록 제한해 커뮤니티의 신뢰성을 높인다. - 예를 들어 **Grow a Garden**은 인증된 Roblox 플레이어만 공식 서버에 참여하게 만들 수 있다. - 계정 연결 사용자끼리만 DM을 주고받도록 제한해 원치 않는 접촉과 개인정보 노출을 줄일 수 있다. - 게임 내 운영진의 제재 결과를 Discord 서버 차단과 연계할 수 있어 수동 관리 부담이 감소한다. ## 사용자 동의와 개인정보 제어 - 사용자는 계정 연결 및 데이터 공유 여부를 명확한 인증 절차에서 직접 결정한다. - Rich Presence와 게임 초대 기능은 Discord 계정 연결뿐 아니라 해당 게임에 대한 별도 승인까지 완료해야 활성화된다. - 사용자는 Discord 설정의 **Settings → Activity Privacy → Activity Sharing**에서 Rich Presence 공개 여부를 관리할 수 있다. - 연결은 언제든 해제하거나 권한을 취소할 수 있다. - Discord는 Roblox의 개인정보 보호 및 서드파티 통합 관련 원칙에 맞춰 사용자 안전과 신뢰를 강조한다. ## 게임 정보를 보여주는 Rich Presence - 기존 Roblox 이용자의 Discord 상태는 단순히 “Playing Roblox”로 표시됐다. - 통합 이후 개발자는 게임 이름, 플레이어의 현재 위치, 활동 내용 등 구체적인 정보를 Discord에 표시할 수 있다. - **Brookhaven RP**의 경우 연결된 사용자의 게임 활동을 Discord 친구들에게 자동으로 보여줄 수 있다. - 게임 활동이 노출되면 친구가 어떤 게임을 하는지 쉽게 발견하고 커뮤니티 참여로 이어질 가능성이 커진다. ## 한 번의 클릭으로 친구 초대 - Discord에서 친구가 어떤 게임을 플레이 중인지 확인하고 바로 세션에 참여할 수 있다. - **Grow a Garden**에서는 Discord 서버에서 친구를 초대해 함께 농작물을 공유하거나 거래하고 수확물을 구경할 수 있다. - 복잡한 링크 복사나 별도 앱 전환 없이 Discord와 Roblox 게임 사이의 참여 흐름이 간소화된다. - 개발자 입장에서는 팀 구성과 공동 플레이를 활성화하는 소셜 기능을 공식적으로 제공할 수 있다. ## Roblox 커뮤니티의 확장 가능성 - Roblox 게임의 Discord 서버는 아이템 드롭, 이벤트 공지, 피드백 수집, 업데이트 알림 등 다양한 커뮤니티 활동의 중심으로 활용된다. - **Grow a Garden**의 운영진 이벤트나 **Steal a Brainrot**의 공격·방어형 이벤트처럼 게임 고유의 문화와 커뮤니티 활동을 Discord에서 확장할 수 있다. - Discord는 기존 PC, Xbox, PlayStation 게임 개발자에게 제공하던 커뮤니티 관리 기능을 Roblox 생태계로 확대하려 한다. ## 실용적인 결론 Roblox 게임 개발자는 Social SDK를 활용해 인증된 플레이어 중심의 안전한 Discord 커뮤니티를 구축하고, Rich Presence와 원클릭 초대로 플레이어 참여를 높일 수 있다. 다만 기능 활성화가 사용자 동의와 개인정보 설정에 의존하므로, 명확한 권한 안내와 쉬운 연동 해제 절차를 함께 제공하는 것이 중요하다.

원문 읽기(새 탭에서 열림)
discordaccount-linkingrich-presenceroblox+3
figma3분 읽기큐레이션 요약

AI 도구로 아이디어를 제품으로 발전시키는 4가지 새로운 방법 | Figma 블로그

AI 도구는 제품 개발의 시작점을 아이디어나 정적 목업에서 실행 가능한 프로토타입으로 확장하고 있다. 팀은 코드를 통해 복잡한 제약과 실제 데이터를 먼저 검증한 뒤 Figma에서 함께 탐색·개선하고, 필요하면 디자인 맥락을 유지한 채 다시 코드로 돌아갈 수 있다. 글은 FloQast, Merkle, Affirm, Accor의 사례를 통해 속도와 의도적인 협업을 결합하는 네 가지 AI 기반 워크플로를 소개한다. ## AI 시대의 제품 개발 방식 변화 - 제품팀은 초기부터 프로토타입을 만들며 아이디어를 검증하는 방향으로 이동하고 있다. - AI 코딩 도구를 활용하면 디자이너나 기획자도 개발자의 큰 투입 없이 복잡한 상호작용을 시험할 수 있다. - 제품 탐색은 코드, Figma 캔버스, 다시 코드로 이어지는 순환형 과정이 된다. - AI는 탐색 범위를 넓힐 뿐 아니라, 기존에 핸드오프 과정에서 사라지던 디자인 시스템과 맥락을 개발 단계까지 전달하는 데 활용된다. ## 코드로 복잡한 제약 검증 - 정적 목업만으로 평가하기 어려운 다음과 같은 상황을 코드 기반 프로토타입으로 테스트할 수 있다. - 한 작업이 완료되어야 다음 작업이 활성화되는 다단계 흐름 - 실제 데이터에 따라 화면과 동작이 달라지는 인터페이스 - 사용자 권한, 조건부 상태, 외부 시스템 간 데이터 일치 여부 - 제품 담당자는 AI 코딩 도구로 실제 동작하는 프로토타입을 만들고, 이후 **Codex to Figma**를 통해 Figma 캔버스로 가져와 팀과 함께 검토할 수 있다. - 디자인에서 추가 조정이 필요하면 Figma에서 작업한 뒤 MCP를 통해 코드로 되돌릴 수 있으며, 디자인 맥락도 함께 유지된다. ## FloQast의 복잡한 회계 워크플로 테스트 ### 문제 상황 - FloQast의 회계 소프트웨어에서는 작업 간 의존성, 결제 처리업체와 은행 간 기록 대조, 검토 및 승인 절차 등이 중요하다. - 기존 워크플로에서는 사용자가 불일치를 확인하기 위해 여러 페이지를 오가야 했다. - 팀은 작업 목록, 차단된 작업, 문제 해결 기능을 하나의 화면에 통합하려 했다. - 초기 프로토타입은 가능성을 보였지만, 실제 데이터와 연결된 여러 단계의 상호작용을 정적 디자인만으로는 검증하기 어려웠다. ### AI 코딩 프로토타입의 활용 - UX 매니저 Benjamin Ellis는 AI 코딩 도구로 시뮬레이션 백엔드와 실제 고객 워크플로를 기반으로 한 현실적인 데이터를 구성했다. - 팀은 한 단계의 완료가 다음 단계의 상태를 바꾸는 실제 시나리오를 직접 실행했다. - 겉보기에는 자연스러워 보였지만 실제 데이터와 로직을 적용하면 무너지는 흐름을 조기에 발견했다. ### 결과와 적용 시점 - 디자인 방향을 확정하기 전에 실제 시나리오를 충분히 검증해 후속 개발 단계의 예상치 못한 문제를 줄였다. - 다음과 같은 경우에 이 방식을 적용할 수 있다. - 권한이나 조건에 따라 UI 동작이 달라지는 경우 - 한 동작이 다른 동작과 상태에 연쇄적으로 영향을 주는 경우 - 작은 수정은 디자인 툴을 거치는 것보다 코드에서 직접 처리하는 편이 빠른 경우 - 디자이너와 개발자가 복잡한 경험을 함께 정의해야 하는 경우 정적인 화면을 먼저 완성하려 하기보다, AI 도구로 실제 데이터와 로직을 포함한 작동 가능한 프로토타입을 빠르게 만든 뒤 디자인과 개발을 오가는 방식이 효과적이다. 특히 복잡한 제품일수록 초기 코드 검증을 통해 잘못된 상호작용을 일찍 발견하고, Figma를 협업과 refinement의 공간으로 활용하는 것이 유리하다.

원문 읽기(새 탭에서 열림)
Figma디자인 시스템프로토타이핑모델 컨텍스트 프로토콜+4
gitlab4분 읽기큐레이션 요약

GitLab 패치 릴리스: 19.0.1, 18.11.4, 18.10.7 | GitLab Docs

2026년 5월 27일 GitLab은 CE/EE용 패치 릴리스 19.0.1, 18.11.4, 18.10.7을 공개했습니다. 이번 릴리스에는 인증·인가 오류, 정보 노출, 서비스 거부 등 7건의 보안 취약점과 다양한 버그 수정이 포함되어 있어, 영향을 받는 모든 자체 관리형 설치 환경은 즉시 업그레이드하는 것이 권고됩니다. GitLab.com은 이미 패치가 적용됐으며 GitLab Dedicated 고객은 별도 조치가 필요하지 않습니다. ## 릴리스 대상과 업그레이드 권고 - 대상 버전: - GitLab 19.0.1 - GitLab 18.11.4 - GitLab 18.10.7 - CE와 EE 모두에 해당하는 수정이 있으며, 별도 배포 유형이 명시되지 않은 경우 Omnibus, 소스 설치, Helm Chart 등 모든 설치 방식에 영향을 줍니다. - GitLab 패치 릴리스는 일반적으로 매월 둘째·넷째 수요일에 제공되며, 심각한 취약점에는 긴급 패치가 별도로 배포될 수 있습니다. - 보안 취약점의 상세 이슈는 패치된 릴리스가 공개된 뒤 30일 후 이슈 트래커에 공개됩니다. ## Duo AI 워크플로 실행 주체 혼동 - **CVE-2026-4868** - GitLab EE에 영향을 주는 부적절한 접근 제어 취약점입니다. - 인증된 사용자가 특정 조건에서 다른 사용자의 신원으로 Duo AI 워크플로를 실행하도록 만들 수 있었습니다. - CVSS **8.2**로 이번 릴리스에서 가장 심각한 취약점입니다. - 수정 대상: - 18.8 이상 18.10.7 미만 - 18.11 이상 18.11.4 미만 - 19.0 이상 19.0.1 미만 ## Wiki 입력 검증 부족에 따른 서비스 거부 - **CVE-2026-1402** - GitLab CE/EE의 Wiki 기능에서 입력값 검증이 충분하지 않아, 인증된 사용자가 특정 조건에서 서비스 거부를 유발할 수 있었습니다. - CVSS **6.5**입니다. - 17.1부터 18.10.7 미만, 18.11.4 미만, 19.0.1 미만 버전이 영향을 받습니다. ## GraphQL WorkItem API의 비인가 프로젝트 열람 - **CVE-2026-6713** - GraphQL WorkItem API의 권한 검사가 잘못되어, 인증되지 않은 사용자가 비공개 프로젝트를 열거할 수 있었습니다. - 프로젝트 내용 전체가 노출된다는 의미는 아니지만, 비공개 프로젝트의 존재나 식별 정보가 노출될 수 있는 문제입니다. - CVSS **5.3**이며 GitLab CE/EE에 영향을 줍니다. - 수정 버전은 18.10.7, 18.11.4, 19.0.1입니다. ## Duo Workflows 및 Operations 권한 우회 - **CVE-2026-5296** - GitLab EE의 Duo Workflows API 취약점입니다. - 그룹 수준에서 foundational flow가 활성화된 경우, Developer 권한 사용자가 특정 조건에서 워크플로 제한을 우회할 수 있었습니다. - CVSS **4.3**입니다. - **CVE-2026-2601** - GitLab EE Operations 기능의 권한 검사 오류입니다. - Developer 권한 사용자가 다른 프로젝트의 민감한 배포 데이터를 볼 수 있었습니다. - CVSS **4.3**입니다. - 두 취약점 모두 18.10.7, 18.11.4, 19.0.1에서 수정되었습니다. ## CI/CD 및 토큰 인증 관련 취약점 - **CVE-2026-8716** - Pipelines에서 ref 유형 이름을 잘못 해석해, 인증된 사용자가 의도하지 않은 다른 ref의 CI 데이터를 볼 수 있었습니다. - GitLab CE/EE에 영향을 주며 CVSS는 **4.3**입니다. - **CVE-2026-2710** - 차단된 Project Access Token이 특정 인증 엔드포인트를 통해 계속 비공개 리소스에 접근할 수 있었습니다. - GitLab CE/EE에 영향을 주며 CVSS는 **4.3**입니다. - 두 취약점 모두 18.10.7, 18.11.4, 19.0.1에서 해결되었습니다. ## 19.0.1의 주요 버그 수정 - GitLab Credits 대시보드의 평가판 CTA 오류를 수정했습니다. - 작업 토큰의 세분화된 권한에 저장소 쓰기 권한 옵션을 추가했습니다. - Helm 기반 릴리스 환경 QA를 제거했습니다. - API 보안 수정 지침을 릴리스 노트에 반영했습니다. - 19.0 최종 릴리스 관련 변경 사항을 백포트했습니다. ## 18.11.4의 주요 버그 수정 - Ruby 스레드 스케줄러 우선순위 패치를 적용했습니다. - Elasticsearch 인덱서 버전을 5.14.7로 업데이트했습니다. - Zlib를 3.2.3으로 업데이트하고 GitLab Shell을 14.50.0으로 올렸습니다. - Wiki 페이지 이동 시 댓글이 사라지는 문제를 수정했습니다. - 성공한 빌드가 삭제되는 문제와 SyncPolicyWorker 타임아웃 문제를 해결했습니다. - CI/CD 프로젝트 생성 테스트, Epic 보드, swimlane 등 불안정한 기능과 테스트를 수정했습니다. - AI Workflows 범위와 subgroup 프로비저닝 서비스 계정 관련 기능을 보완했습니다. - 파이프라인 취소 및 trace 처리, 다이어그램 프록시의 허용 엔드포인트 전달을 개선했습니다. - 고급 검색 대량 인덱싱에서 기본 데이터베이스 연결을 사용하도록 수정했습니다. - 라이선스 승인 규칙 워크플로의 성능을 개선했습니다. - `num_context_lines=0`일 때 발생하던 off-by-one 오류를 수정했습니다. ## 실용적인 권장 사항 자체 관리형 GitLab 운영자는 현재 지원 중인 브랜치에 맞춰 즉시 19.0.1, 18.11.4 또는 18.10.7로 업그레이드하는 것이 좋습니다. 특히 Duo AI/Workflows, GraphQL WorkItem, Wiki, CI/CD, Project Access Token, Operations 기능을 사용하는 환경은 업그레이드 전까지 권한과 비공개 데이터 접근 로그를 점검해야 합니다.

원문 읽기(새 탭에서 열림)
CI/CDgitlabGraphQLelasticsearch+4
google4분 읽기큐레이션 요약

혁신의 새로운 시대: I/O 2026에서의 Google Research

Google I/O 2026에서 Google Research는 AI를 과학적 발견과 헬스케어 혁신을 가속하는 ‘에이전트 시대’의 핵심 기술로 제시했다. 연구용 AI 에이전트가 가설 생성부터 코드 작성·실험·검증까지 수행하고, 건강 분야에서는 개인화된 코칭과 진료 준비를 지원한다. Google은 이러한 기술이 인간의 연구 역량을 증폭할 수 있다고 강조하면서도, 실제 연구자·의료진과의 협업 및 책임 있는 공개를 병행하고 있다. ## 과학적 발견을 가속하는 AI - **Gemini for Science** - 과학 연구 전 과정을 지원하는 실험적 도구 모음이다. - 가설 생성, 계산 실험, 문헌 분석, 연구용 에이전트 활용 등을 하나의 생태계로 묶는다. - Google Cloud, Google DeepMind, Google Labs와 협력해 개발됐다. - **Empirical Research Assistance(ERA)** - 과학자가 전문가 수준의 경험적 연구 소프트웨어를 작성하도록 돕는 연구 코딩 시스템이다. - 문제와 평가 기준을 입력하면 새로운 개념을 제안하고, 코드를 작성한 뒤 결과를 평가한다. - 트리 탐색을 사용해 수천 개의 코드 변형을 반복적으로 생성·검증하며 성능을 최적화한다. - 신경과학과 우주론 연구에 활용됐으며, 호흡기 질환 입원 예측과 캘리포니아 강 유역의 계절별 유출량 예측에도 적용됐다. - **Co-Scientist** - Gemini를 기반으로 한 다중 에이전트 협업 시스템이다. - 전문화된 여러 에이전트가 가설을 생성하고, 서로 평가·토론·수정한다. - 항균제 내성, 식물 면역, 간 섬유화 등 연구 난제를 다루는 데 활용되고 있다. - **Computational Discovery** - ERA와 AlphaEvolve를 결합한 에이전트형 연구 엔진이다. - 수천 개의 코드 변형을 병렬로 생성하고 점수화해, 사람이 수개월 걸려 시험할 모델과 가설을 빠르게 비교한다. - **Hypothesis Generation과 Literature Insights** - Hypothesis Generation은 연구자와 함께 문제를 정의한 뒤, 다중 에이전트 ‘아이디어 토너먼트’를 통해 가설을 생성·논쟁·평가한다. - 생성된 주장은 클릭 가능한 인용을 제공해 과학적 검증 가능성을 높인다. - Literature Insights는 NotebookLM을 활용해 방대한 과학 문헌의 결과를 요약하고 구조화한다. - 매년 수백만 편의 논문이 발표되는 상황에서 문헌 종합을 자동화하는 것을 목표로 한다. ## 연구 자동화와 과학 검증 - Google Antigravity 같은 에이전트형 코딩 플랫폼에서 사용할 수 있는 **Science Skills**를 제공한다. - 구조 생물정보학과 유전체 분석처럼 복잡한 연구 작업을 수시간이 아닌 수분 단위로 수행할 수 있도록 지원한다. - 학술대회의 논문 심사와 검증에도 AI를 실험적으로 적용하고 있다. - **Paper Assistant Tool(PAT)**은 ICML, STOC, NeurIPS 등에서 1만 편 이상의 논문을 검토했다. - PAT의 피드백을 통해 저자가 이론적 허점을 발견하거나 새로운 실험을 수행할 수 있었다. - **Gemini Deep Think**는 수학·물리학·컴퓨터과학 연구자들과 협력해 네트워크 퍼즐의 미해결 문제, 최적화 추측, 머신러닝 최적화 현상, 경매 경제학, 우주끈의 물리적 특이점 등 전문가 수준의 난제를 다뤘다. ## AI를 활용한 헬스케어 발전 - Google은 증상 이해부터 진료 준비, 의료 기록 해석, 진료 이후 관리까지 이어지는 건강 관리 여정 전반을 AI로 지원하려 한다. - 이러한 연구를 바탕으로 **Google Health 앱**과 **Google Health Coach**를 개발했다. - Google Health 앱은 기존 Fitbit 사용자에게 순차적으로 제공되며, 개인별 상황에 맞춘 종합적이고 적응형인 건강 코칭을 제공한다. ## 증상 분석과 진료 준비 지원 - **Symptom AI** - 대화형 건강 데이터를 분석해 사용자의 증상과 관련된 감별 진단을 추론하는 연구용 도구다. - Fitbit 앱을 통한 무작위 연구에 13,917명이 참여했다. - 독립 임상의의 맹검 비교에서 Symptom AI의 감별 진단이 다른 임상의의 결과보다 약 두 배 자주 선호됐다. - 이는 AI가 다양한 표현 방식과 실제 질병 분포를 반영한 대화 데이터를 활용할 가능성을 보여준다. - **Plan for Care** - 사용자가 의사와의 진료를 준비하도록 돕는 파일럿 연구다. - 1,779명이 참여했으며, 기준 모델과 비교해 진료 준비가 더 잘 됐다고 느낀 사용자가 15% 증가했다. - 진료를 최대한 활용할 자신감이 있다고 답한 사용자도 13% 늘었다. - **개인 건강 기록(PHR) 연구** - 모델의 문맥에 개인 건강 기록을 포함했을 때 건강 관련 AI의 효과가 어떻게 달라지는지 평가했다. - 제공된 글은 PHR 연구의 구체적인 결과가 이어지기 전에 중단되어 있어, 해당 부분의 결론은 확인할 수 없다. ## 실용적인 의미 Google이 제시한 방향은 AI를 단순한 답변 도구가 아니라 가설을 세우고 실험하며 결과를 검증하는 연구 파트너로 발전시키는 것이다. 다만 과학적 정확성, 의료 안전성, 개인정보 보호가 중요한 영역인 만큼, 실제 활용에서는 AI의 결과를 연구자와 의료진이 검토하고 제한된 범위에서 단계적으로 도입하는 접근이 필요하다.

원문 읽기(새 탭에서 열림)
머신러닝생성형 AIgeminimulti-agent-systems+2
gitlab2분 읽기큐레이션 요약

GitLab의 Claude Opus 4.8: 복잡한 에이전트 작업, 중단은 줄이고

Claude Opus 4.8은 GitLab Duo Agent Platform에서 복잡한 다단계 에이전트 작업을 더 정확하고 안정적으로 수행하도록 설계된 최신 모델이다. 장시간 자율 실행 과정에서 지시를 더 충실히 따르며, 중간에 사용자가 개입하거나 결과를 수정해야 하는 상황을 줄이는 것이 핵심이다. 또한 코딩뿐 아니라 문서 작성, 데이터 분석, 구조화된 지식 작업과 세션 중 시스템 프롬프트 변경도 지원한다. ## 복잡한 장기 에이전트 작업의 안정성 향상 - 여러 도구를 사용하고, 사용자의 의도부터 실제 배포까지 이어지는 복잡한 작업에 초점을 맞춘 모델이다. - 장시간 자율적으로 실행되는 에이전트가 각 단계를 지시대로 처리하도록 해 최종 결과의 정확도를 높인다. - 이전 모델보다 지시 해석과 계획 수립 능력이 향상되어, 실행 중 에이전트를 다시 안내하거나 결과를 검토·수정하는 시간이 줄어든다. - GitLab Duo Agent Platform의 Agentic Chat과 인스턴스 내 다양한 에이전트 워크플로에서 모델을 선택해 사용할 수 있다. ## 코딩 외 업무 지원 확대 - Opus 4.8은 소프트웨어 개발뿐 아니라 다음과 같은 전문 업무도 안정적으로 처리한다. - 문서 초안 작성 - 데이터 분석 - 구조화된 지식 처리 - GitLab Duo 에이전트를 기획, 문서화, 코딩 전반에 활용하는 팀은 여러 업무 흐름에서 일관된 결과를 기대할 수 있다. ## 대화 중 시스템 프롬프트 변경 - 세션 중간에 시스템 지침을 업데이트하는 기능을 지원한다. - 시스템 프롬프트가 변경되어도 기존 프롬프트 캐시를 무효화하거나 세션을 다시 시작할 필요가 없다. - API를 사용하는 팀은 다음과 같은 비동기 상황에 대응할 수 있다. - 디스크의 파일이 변경된 경우 - 사용 가능한 토큰 예산이 달라진 경우 - 사용자 컨텍스트가 업데이트된 경우 - 이를 통해 긴 에이전트 세션의 상태와 캐시를 유지하면서 최신 정보를 반영할 수 있다. ## GitLab에서의 이용 방식 - Claude Opus 4.8은 GitLab Duo Agent Platform에서 즉시 사용할 수 있다. - 다른 모델과 마찬가지로 GitLab Credits를 사용하며, 모델별 크레딧 소비량은 GitLab 문서에서 확인할 수 있다. - 무료 체험 또는 GitLab Free 가입으로 시작할 수 있다. - 기존 GitLab Premium·Ultimate 구독자는 구독에 포함된 GitLab Credits를 활용할 수 있다. ## 실용적인 결론 복잡한 작업을 여러 단계로 나누어 장시간 실행하는 팀이라면 Opus 4.8을 GitLab Duo의 코딩·기획·문서화 워크플로에 적용해볼 만하다. 특히 에이전트의 잦은 방향 수정이 문제였던 환경에서는 향상된 지시 준수와 중간 프롬프트 갱신 기능이 운영 부담을 줄이는 데 도움이 될 수 있다.

원문 읽기(새 탭에서 열림)
AI 에이전트APIdata-analysisgitlab-duo+3
figma3분 읽기큐레이션 요약

Figma Make, 이제 로컬 코드에서 | Figma 블로그

Figma Make은 디자인, 프로토타이핑, 실제 코드 배포 사이의 경계를 허물고, Figma 안에서 로컬 코드베이스를 직접 수정·검토·공유할 수 있도록 확장된다. 사용자는 화면 요소를 시각적으로 편집하거나 자연어 주석으로 동작을 변경하고, Git 브랜치·커밋·PR 흐름을 통해 안전하게 배포할 수 있다. 궁극적으로 Figma는 디자인 캔버스와 코드베이스를 하나의 협업 환경으로 통합하려 한다. ## 로컬 코드베이스의 시각적 편집 - Figma Make를 회사의 코드베이스에 연결하면 Figma 안에서 실제 UI를 직접 수정할 수 있다. - 화면 요소를 선택해 다음 속성을 변경할 수 있다. - 레이아웃 - 색상 - 글꼴 - 크기 - 기타 시각적 속성 - Make의 에이전트가 사용자의 시각적 변경에 대응하는 코드를 찾아 수정한다. - 이미 원하는 결과가 명확한 속성 변경에는 직접 편집 기능을 사용한다. - 현재는 코드베이스 접근 권한이 있는 디자이너에게 적합하며, 비기술 사용자를 위한 설정 과정은 계속 개선 중이다. ## 주석과 프롬프트를 활용한 동작 변경 - 단순한 속성 변경을 넘어 상호작용이나 애니메이션을 수정할 때는 화면 요소에 주석을 달 수 있다. - 주석에는 원하는 동작을 자연어로 설명할 수 있다. - 여러 요소를 한 번에 참조할 수 있어 에이전트에 구체적인 맥락을 전달한다. - 직접 편집과 일반적인 채팅 프롬프트 사이의 유연한 작업 방식으로 활용된다. - 예를 들어 버튼의 클릭 동작, 화면 전환, 애니메이션 로직 등을 설명해 코드에 반영할 수 있다. ## 브랜치·커밋·PR 기반 배포 - 프로덕션 코드는 팀의 개발 프로세스를 거쳐 의도적으로 배포하도록 설계됐다. - PR을 열기 전 변경 사항은 로컬 커밋으로 저장된다. - Make 안에서 Git 작업을 수행할 수 있다. - 브랜치 생성 - 커밋 확인 - 커밋 되돌리기 - 변경 이력 검토 - PR 생성 - 엔지니어링 팀은 일반적인 코드 변경과 동일하게 Make의 변경 사항을 리뷰할 수 있다. ## 디자인과 코드의 협업 및 왕복 작업 - 로컬 코드베이스의 변경 사항을 파일과 브랜치 단위로 팀원에게 공유할 수 있다. - 팀원은 공유받은 브랜치를 체크아웃해 변경 내용을 확인하고 추가 작업을 진행한다. - 커밋 이력을 통해 변경 전후를 비교할 수 있다. - Make에서 만든 화면·페이지·컴포넌트를 Figma 캔버스의 레이어로 복사할 수 있다. - Figma 캔버스에서 팀원과 의견을 나누고, Figma 에이전트와 함께 디자인을 수정할 수 있다. - 디자인 변경 사항은 다시 Make로 가져와 코드에 적용할 수 있다. - 이를 통해 다음과 같은 왕복 흐름을 지향한다. - Make에서 코드 기반 화면 제작 - Figma Design에서 검토·편집·협업 - 결정된 디자인을 다시 코드에 반영 ## 베타 출시 범위 - 직접 편집, 주석, 채팅, PR 생성 기능은 2026년 5월 28일부터 제한적 베타로 제공된다. - 베타 기간에는 AI 크레딧을 차감하지 않는다. - 정식 AI 크레딧 요금은 추후 공개될 예정이다. - 초기 베타는 Mac용 Figma Beta 데스크톱 앱에서만 제공된다. - 대기자 등록이 베타 접근을 보장하지는 않으며, 선정된 사용자에게 별도 이메일이 발송된다. - 향후 다른 플랫폼으로 확대할 계획이다. Figma Make는 디자인 도구와 IDE를 대체로 구분하기보다, 작업 단계에 따라 두 환경을 연결하는 방향을 택했다. 현재는 Mac 베타와 코드 접근 권한 등 제약이 있지만, Git 기반 리뷰 프로세스와 Figma 캔버스 협업이 안정화된다면 디자이너와 개발자가 실제 제품 코드를 함께 발전시키는 실용적인 워크플로가 될 수 있다.

원문 읽기(새 탭에서 열림)
AI 에이전트collaborationfigma-makedesign-to-code+3
gitlab4분 읽기큐레이션 요약

에이전트 코딩은 컨텍스트만큼만 훌륭하다

코딩 에이전트의 성능과 신뢰성은 코드 작성 능력보다 프로젝트 생명주기 전반의 맥락을 얼마나 활용하느냐에 달려 있다. 저장소만 보는 에이전트는 컴파일되는 코드를 만들 수 있지만, 이슈 요구사항·CI 규칙·보안 정책·리뷰 기준까지 반영하기 어렵다. GitLab처럼 이슈, 파이프라인, 보안 스캔, 머지 리퀘스트를 연결하면 에이전트가 조직의 가드레일 안에서 작업하고, 리뷰 라운드와 머지까지 걸리는 시간을 줄일 수 있다. ## 저장소만 보는 에이전트의 한계 - 에이전트는 로컬 파일과 사용자가 입력한 프롬프트를 기반으로 코드를 수정하고 빌드를 실행한다. - 코드가 컴파일되더라도 다음 정보를 알지 못할 수 있다. - 이슈의 인수 조건과 구현 메모 - 비기능 요구사항 - CI 설정에 정의된 린터·테스트·품질 기준 - 조직의 코드 리뷰 규칙과 보안 정책 - 결과적으로 “동작하는 코드”와 “팀이 실제로 요구한 변경” 사이에 차이가 생긴다. - 이슈 링크 누락, 새로 추가된 린터 규칙 위반, 승인되지 않은 의존성 추가 같은 재작업이 발생할 수 있다. ## GitLab 이슈를 연결했을 때의 변화 - GitLab MCP 서버를 연결하면 에이전트가 코딩 전에 관련 이슈를 조회할 수 있다. - 이슈의 요구사항, 구현 메모, 라벨, 마일스톤을 확인해 계획에 맞는 수정이 가능해진다. - 예를 들어 Codex는 머지 리퀘스트 설명에 `Closes #32`를 추가해 코드 변경과 이슈의 관계를 명시한다. - Claude Code는 `get_issue`로 버그 리포트를 가져오고, `create_merge_request`로 적절한 참조가 포함된 MR을 생성한다. - 즉, 에이전트의 작업이 단순한 코드 수정에서 프로젝트 계획과 연결된 변경으로 확장된다. ## 머지 리퀘스트 안에서 수행하는 리뷰와 수정 - MR이 생성되면 GitLab의 Code Review Flow가 자동으로 리뷰 피드백을 게시한다. - 에이전트는 MR 내부의 외부 에이전트로 호출되어 다음과 같은 후속 작업을 수행할 수 있다. - 누락된 테스트 추가 - 문서 주석 보완 - 리뷰에서 발견된 검증 로직의 공백 수정 - 수정 사항은 MR 브랜치에 직접 커밋된다. - 새 커밋마다 CI/CD 파이프라인이 자동 실행되므로, 에이전트의 수정 결과를 즉시 검증할 수 있다. - 사람은 다른 도구로 전환하지 않고 MR에서 변경 내용과 파이프라인 결과를 검토한다. - 이 흐름은 리뷰 반복 횟수와 머지까지 걸리는 시간을 줄이는 데 기여한다. ## 플랫폼 전체 맥락과 조직의 가드레일 - 플랫폼 팀은 조직 내 AI 개발 방식에 대해 다음을 결정한다. - 허용할 에이전트 - 에이전트가 접근할 수 있는 도구와 데이터 - 결과물을 검증하는 방법 - 사람의 승인과 판단이 필요한 지점 - DevSecOps 플랫폼에는 에이전트가 필요로 하는 생명주기 정보가 모여 있다. - 이슈 트래커: 요구사항과 우선순위 - CI/CD 설정: 품질 기준과 자동 검증 - 코드 리뷰 지침: 스타일과 개발 표준 - 보안 스캐너: 취약점 정책 - MR: 자동화와 최종적인 사람의 승인 - IDE나 터미널 기반 에이전트가 아무리 뛰어나도 제공된 파일 중심으로만 판단한다. - 반면 플랫폼은 이슈부터 파이프라인, 보안 정책, 배포 대상, 승인 규칙까지 전체 흐름을 볼 수 있다. - 따라서 안전하게 배포되는 결과물은 에이전트 자체의 능력뿐 아니라 플랫폼이 제공하는 가시성과 통제에 좌우된다. ## AI가 코드를 더 많이 만들 때의 보안 영향 - 코드 생성 속도가 빨라지면 새 취약점, 보안 스캔 결과, 수정용 MR도 함께 증가한다. - 기존에는 보안팀이 취약점을 탐지·분류한 뒤 개발자에게 수정 요청을 보내고 기다리는 과정이 병목이었다. - 에이전트가 수정까지 빠르게 수행하면 병목은 “무엇을 고칠까”에서 “어떤 AI 생성 수정 MR을 먼저 사람이 승인할까”로 이동한다. - 우선순위를 정하려면 다음과 같은 전체 맥락이 필요하다. - 프로젝트 전체 코드 - 데이터 흐름 - 실제 배포 환경 - 조직에 적용되는 보안 정책 - 이런 맥락이 있으면 단순한 심각도 점수가 아니라 실제 환경에서의 노출 가능성을 기준으로 취약점을 우선순위화할 수 있다. - GitLab 보안 계층은 프로젝트 맥락을 활용해 오탐을 걸러내고 확인된 취약점을 식별한다. - 확인된 취약점에 대해서는 agentic SAST vulnerability resolution이 취약 코드와 주변 코드를 분석해 수정 MR을 자동 생성한다. - 이후 파이프라인이 수정 사항을 검증하고, 최종 머지 여부는 사람이 결정한다. - 즉, 에이전트가 수정 작업을 담당하더라도 승인과 거버넌스는 사람에게 남는다. ## `AGENTS.md`를 활용한 프로젝트별 지침 - 두 튜토리얼 모두 저장소에 `AGENTS.md` 파일을 두고 에이전트의 행동 지침으로 활용한다. - 이 파일에는 다음과 같은 내용이 포함될 수 있다. - 프로젝트 구조 - 실행해야 할 명령어 - 코드 품질 기준 - 수정해서는 안 되는 파일이나 영역 - Codex와 GitLab 튜토리얼에서는 Rust 에디션, 비동기 동시성 패턴, CI 이미지 고정 정책 등이 정의되어 있었다. - 이를 통해 에이전트가 매번 프롬프트로 설명받지 않아도 프로젝트의 기술적 규칙과 변경 범위를 일관되게 준수할 수 있다. 플랫폼 팀은 에이전트를 단독 코딩 도구로 도입하기보다 이슈·`AGENTS.md`·CI/CD·보안 스캔·MR 리뷰를 연결한 workflow 안에 배치하는 것이 좋다. 에이전트가 더 많은 작업을 자동화할수록 자동 검증은 강화하고, 최종 승인과 책임은 사람에게 남겨야 한다.

원문 읽기(새 탭에서 열림)
CI/CDgitlab모델 컨텍스트 프로토콜DevSecOps+3
cloudflare3분 읽기큐레이션 요약

이란의 인터넷이 부분적으로 복구됐음을 Cloudflare Radar 데이터가 보여준다

이란의 인터넷은 약 3개월간 이어진 전국적 차단 이후 2026년 5월 26일부터 부분적으로 복구되기 시작했다. Cloudflare Radar는 트래픽과 DNS 요청이 크게 증가했지만, 최대치가 차단 이전 활동량의 40%에 그쳐 완전한 복구는 아니라고 분석했다. 특히 테헤란과 주요 통신망에 회복이 집중됐고, IPv6 연결은 여전히 사실상 중단된 상태다. ## 첫 번째 전국 인터넷 차단 - 2026년 1월 8일경 첫 번째 전국적 인터넷 차단이 시작됐다. - 이란발 트래픽은 거의 0에 가까운 수준으로 떨어졌다. - 1월 21일과 25일에 일시적으로 트래픽이 회복됐지만 곧 다시 감소했다. - 이후 1월 27일부터 비교적 완전한 회복이 나타났다. ## 두 번째 장기 차단 - 미국과 이스라엘의 공격이 시작된 2월 28일, 두 번째 전국적 차단이 발생했다. - Cloudflare Radar는 현지 시간 오전 10시 30분경부터 트래픽이 급격히 감소한 것을 관측했다. - 트래픽은 기존 수준의 1% 미만으로 떨어졌으며, 소량의 웹·DNS 트래픽만 외부로 전달됐다. - 이 차단은 약 3개월 동안 지속됐다. ## 5월 26일부터 나타난 부분 복구 - 5월 26일 11:00 UTC경부터 웹 트래픽과 DNS 요청이 동시에 증가했다. - 11:45 UTC에 짧은 급증이 있었고, 12:00 UTC 이후에는 꾸준한 증가세가 나타났다. - 직전 일주일과 비교하면 Cloudflare 네트워크를 통과한 데이터량이 약 15배 증가했다. - 밤 시간대에는 트래픽이 감소하고, 5월 27일 현지 오전 6시 30분경부터 다시 증가하는 일중 변동 패턴도 관측됐다. - 이는 실제로 더 많은 사용자가 웹사이트와 온라인 서비스에 접속하기 시작했다는 신호다. ## 테헤란과 주요 통신사에 집중된 회복 - 새로 증가한 HTTP 요청의 91.6%가 수도 테헤란에서 발생했다. - 다른 지역에서도 소폭 증가했지만 테헤란만큼 뚜렷하지 않았다. - Iran TCI, IranCell, RighTel, MCCI 등 주요 인터넷 사업자에서도 트래픽 증가가 나타났다. - Cloudflare는 각 통신망을 ASN(자율 시스템 번호) 단위로 구분해 트래픽 변화를 측정했다. ## DNS 요청 증가가 보여주는 접속 회복 - Cloudflare 공개 DNS 리졸버인 `1.1.1.1`에 대한 요청도 크게 증가했다. - DNS 요청은 사용자가 웹사이트나 온라인 서비스를 찾을 때 발생하므로, 인터넷 이용자 활동의 회복을 보여주는 지표가 된다. - 트래픽 증가와 DNS 요청 증가는 단순한 네트워크 신호가 아니라 실제 사용자 접속이 늘고 있음을 뒷받침한다. ## 아직 제한적인 복구 수준 - 5월 26일 트래픽 최고치는 2026년 관측된 차단 이전 최대 활동량의 약 40%에 불과했다. - 따라서 이번 변화는 전국 인터넷의 완전한 정상화가 아니라 부분적인 복구로 해석된다. - 1월에도 잠시 회복된 뒤 다시 차단된 사례가 있었기 때문에, 현재의 증가세가 일시적일 가능성도 있다. - 향후 며칠간 트래픽이 계속 증가해 차단 이전 기준선에 접근하는지가 중요하다. ## IPv6는 여전히 사실상 중단 - 이란의 발표된 IPv6 주소 공간과 IPv6 트래픽은 여전히 거의 0에 가까운 상태다. - 반면 IPv4 주소 공간 발표는 두 차례의 차단 기간에도 비교적 안정적으로 유지됐다. - IPv4 주소가 글로벌 라우팅 테이블에서 제거되지 않았다는 점은, 이번 차단이 단순한 라우팅 철회 방식이 아니었음을 시사한다. - 애플리케이션 필터링이나 허용 목록(whitelisting) 같은 방식으로 특정 서비스와 연결을 제한했을 가능성이 있다. 이번 변화는 이란의 인터넷이 회복 국면에 들어섰다는 중요한 신호지만, 아직 정상화로 보기는 어렵다. 향후 트래픽 규모, 지역별 분포, IPv6 주소 공간의 복구 여부를 함께 관찰해야 하며, 사용자는 서비스 접근이 다시 제한될 가능성도 고려해야 한다.

원문 읽기(새 탭에서 열림)
dnsipv6cloudflare-radaripv4+3
aws3분 읽기큐레이션 요약

새로운 AWS 히어로를 만나보세요 – 2026년 5월 | Amazon Web Services

2026년 5월 AWS Heroes로 네 명의 커뮤니티 리더가 새롭게 선정되었습니다. 이들은 AI·서버리스·클라우드 아키텍처 지식을 공유하고, 사용자 그룹과 커뮤니티 행사를 운영하며, 교육과 멘토링으로 AWS 생태계의 성장을 돕고 있습니다. 특히 AWS re:Invent 도구 개발, 라틴아메리카 최대 규모 커뮤니티 운영, AI/ML 인증 기여 등 각자의 전문성을 바탕으로 활동해 왔습니다. ## AWS Heroes 선정의 의미 - AWS Heroes는 기술 전문성뿐 아니라 커뮤니티에 대한 기여와 지식 공유를 인정받은 리더들입니다. - 선정된 인물들은 블로그, 팟캐스트, 컨퍼런스, 사용자 그룹, 교육 행사 등을 통해 다른 개발자와 클라우드 실무자를 지원해 왔습니다. - 이번에는 이탈리아, 캐나다, 아르헨티나에서 AI, 서버리스, 클라우드 아키텍처 분야의 리더들이 선정되었습니다. ## Damiano Giorgi: AI 기반 re:Invent 세션 추천 도구 - 이탈리아 파비아 출신의 **Artificial Intelligence Hero**입니다. - 온프레미스 시스템 엔지니어에서 AWS 클라우드 솔루션 아키텍트로 전환했으며, 현재 AI의 발전과 활용에 집중하고 있습니다. - AWS User Group Pavia와 AWS User Group Milan의 운영을 돕고 있습니다. - 개인 블로그 **“Bass and Bytes”**를 통해 기술 콘텐츠를 공유합니다. - Amazon Bedrock과 Amazon Nova를 활용해 관심사에 맞는 AWS re:Invent 세션을 찾도록 돕는 **“Unofficial post:Invent Session Suggester”**를 개발했습니다. - AWS Summit Milan을 비롯해 이탈리아, 아드리아 지역, 그리스, 네덜란드 등 유럽의 다양한 컨퍼런스에서 발표하고 있습니다. ## Darryl Ruggles: 서버리스와 AI/ML 아키텍처 전파 - 캐나다 오타와 출신의 **Serverless Hero**입니다. - 소프트웨어 개발자로 오랜 기간 일한 뒤 AWS 애플리케이션 및 AI/ML 아키텍처 분야로 전문성을 확장했습니다. - 서버리스, 컨테이너, AI/ML, FinOps를 주제로 블로그, LinkedIn, 공개 프로젝트에서 지식을 공유합니다. - **“Believe In Serverless”**를 포함한 여러 온라인 AWS 커뮤니티에서 활발히 활동합니다. - 온라인과 오프라인 행사를 가리지 않고 다른 개발자들과 교류하며 서버리스 기술의 실제 활용을 돕고 있습니다. ## Ricardo Daniel Ceci: 라틴아메리카 클라우드 커뮤니티 확장 - 아르헨티나 부에노스아이레스 출신의 **Artificial Intelligence Hero**입니다. - 약 2,400명의 회원을 보유한 아르헨티나 최대 AWS 커뮤니티인 **AWS User Group Buenos Aires**를 이끌고 있습니다. - **AWS Community Day Argentina**의 수석 조직자로 활동했습니다. - 2025년 **LATAM AWS Community Leader of the Year**로 선정되었습니다. - 라틴아메리카의 클라우드 전문가, AWS Heroes, 개발자 애드보킷과 대화하는 팟캐스트를 운영합니다. - 15년 이상의 클라우드 및 웹 개발 경험을 바탕으로 스페인어권 개발자들이 클라우드와 AI에 쉽게 접근하도록 지원하고 있습니다. ## Matias Kreder: AWS 인증과 머신러닝 커뮤니티 기여 - 부에노스아이레스 출신의 **Artificial Intelligence Hero**입니다. - AWS 인증 시험의 Subject Matter Expert(SME)로 참여했으며, **AWS Certified AI Practitioner**를 포함한 여러 AI/ML 인증 개발에 기여했습니다. - AWS DeepRacer에서 세 차례 결승 진출자로 선정된 경험을 계기로 커뮤니티 활동을 시작했습니다. - 이후 지역 내 DeepRacer 대회와 머신러닝 발표·행사를 조직했습니다. - AWS User Group Buenos Aires의 리더로서 2025년 AWS Community Day Argentina를 조직했습니다. - 라틴아메리카 전역의 커뮤니티 행사에서 AI, 머신러닝, AWS 관련 주제로 발표하고 있습니다. ## 실용적인 시사점 - AWS 기술을 학습할 때 공식 문서뿐 아니라 사용자 그룹, 커뮤니티 행사, 팟캐스트, 공개 프로젝트를 함께 활용하면 실무 관점을 얻을 수 있습니다. - Amazon Bedrock·Nova 같은 생성형 AI 서비스를 실제 개발 도구에 적용한 사례는 AWS 서비스 학습과 프로토타이핑에 참고할 만합니다. - 관심 지역의 AWS Heroes나 사용자 그룹에 참여하면 발표, 멘토링, 자격증 준비, 네트워킹 기회를 얻을 수 있습니다.

원문 읽기(새 탭에서 열림)
AI머신러닝AWSamazon-bedrock+4