techlist.io
KREN

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

cloudflare4분 읽기큐레이션 요약

대규모 도그푸딩: cdnjs를 Cloudflare의 개발자 플랫폼으로 마이그레이션하기

cdnjs는 2026년 6월 23일부터 Cloudflare Developer Platform만으로 운영되며, 이를 통해 하루 90억 건의 요청을 처리하는 대규모 오픈소스 CDN의 배포 파이프라인까지 단일 플랫폼으로 통합했다. 기존 시스템은 안정적이고 높은 캐시 적중률을 유지했지만, GCP·VM·GitHub·Cloudflare로 분산된 구조 때문에 관측성과 유지보수가 어려웠다. 이번 마이그레이션은 성능 개선보다 배포·처리 과정의 단순화, 추적 가능성, 보안성 향상에 초점을 둔 것이다. ### cdnjs가 여전히 대규모 트래픽을 처리하는 이유 - cdnjs는 JavaScript와 CSS 오픈소스 라이브러리를 무료로 제공하는 커뮤니티 기반 CDN이다. - 사용자는 API 키나 회원가입 없이 `<script>` 태그만으로 jQuery, Bootstrap, Lodash 등을 불러올 수 있다. - 전체 웹사이트의 약 12%, JavaScript CDN 시장의 48.3%가 cdnjs를 사용한다. - 하루 약 90억 건, 초당 평균 10만 8천 건의 요청을 처리하며 330개 이상의 Cloudflare 데이터센터에서 서비스한다. - 캐시 적중률은 98.6%에 달한다. - URL 규칙이 일관되고 버전이 불변이어서 ChatGPT, Claude, Cursor 같은 LLM이 예제 코드에 안정적으로 활용하기 쉽다. - 각 파일에 SRI 해시가 제공되고 미러가 감사 가능해 공급망 공격 대응에도 유리하다. - 무료·무제한 서비스라는 점 역시 cdnjs가 계속 사용되는 중요한 이유다. ### 기존 아키텍처의 배경 - 2020년 파일 제공 영역은 Cloudflare Workers와 KV로 이전됐다. - KV 장애 시에는 베어메탈 오리진을 사용하는 구조로 복원력을 높였다. - Brotli와 gzip으로 모든 자산을 사전 압축해 응답 크기도 줄였다. - 그러나 새 버전 감지, 패키지 다운로드, 압축, 처리 결과 저장을 담당하는 퍼블리싱 파이프라인은 GCP에 남아 있었다. - 당시 Workers에는 장시간 실행 작업, 대용량 아카이브 처리, 다단계 오케스트레이션을 지원할 기능이 충분하지 않았다. - 이에 따라 GCP Functions, VM 기반 `git-sync`, GCS, Pub/Sub, GitHub 저장소가 서로 연결된 형태로 운영됐다. ### 관측성과 데이터 일관성의 문제 - 하나의 패키지 업데이트가 Cloud Functions, GCS 이벤트, Pub/Sub, `git-sync` VM, Workers KV를 거쳤지만 공통 correlation ID가 없었다. - GCP Logging과 Cloudflare Logpush의 로그를 연결할 기준이 없어 장애 원인을 수작업으로 추적해야 했다. - 처리 결과가 KV에는 기록됐지만 GitHub 저장소 반영에 실패하는 부분 성공(partial success)이 발생할 수 있었다. - 두 저장소가 불일치해도 전체 파이프라인 상태를 아는 시스템이나 자동 알림이 없었다. - 파일은 엣지의 KV와 GitHub 저장소에 동시에 존재했지만 어느 쪽도 명확한 단일 원본이 아니었다. ### 이벤트 기반 파이프라인의 한계 - 여러 Cloud Functions가 공유 스토리지에 파일을 기록하고, 스토리지의 새 파일 이벤트가 다음 함수를 호출하는 방식이었다. - 스토리지가 메시지 큐 역할까지 맡으면서 구조가 복잡해졌다. - 명시적인 dead-letter queue가 없어 실패한 작업을 확인하기 어려웠다. - 대기 중인 작업의 backlog를 파악하기 어렵고, 특정 단계부터 깔끔하게 재실행하기도 힘들었다. - npm 업데이트 확인만 해도 알파벳별로 나눈 26개의 Cloud Functions가 필요했다. - 각 함수마다 별도의 배포와 로그가 있어 전체 시스템의 정상 여부를 확인하려면 26개를 모두 점검해야 했다. ### GitHub 저장소의 규모 문제 - `git-sync` VM은 처리된 모든 파일을 GitHub 저장소에 미러링했다. - 저장소의 packed storage가 1.1TB를 넘으면서 GitHub의 tarball·zip 아카이브 생성이 불가능해졌다. - 클론 속도가 느려지고 포크도 사실상 어려워졌다. - 비정상적이거나 처리하기 곤란한 릴리스를 차단하기 위한 `.gitignore` 항목이 274개까지 늘어났다. - GitHub 저장소는 원본 저장소이면서 동시에 배포 미러 역할까지 맡아 장기적인 확장에 부적합해졌다. ### 보안과 운영 부담 - GCP Functions, `git-sync` VM, 컨테이너 이미지, GCS 버킷, 서비스 계정 키 등 관리해야 할 보안 대상이 많았다. - 각 구성 요소마다 패치, 접근 권한 관리, 감사가 필요했다. - 기존 파이프라인을 폐기하면서 최근 발견된 cdnjs 관련 취약점도 함께 줄일 수 있었다. - 시스템 구성 요소가 줄어들어 장애 대응과 보안 관리가 단순해졌다. ### Cloudflare Developer Platform으로의 재구축 - 새 아키텍처는 Workers, Workflows, D1, Queues, Workers Cache, R2, KV, Containers를 사용해 Cloudflare 안에서 전체 파이프라인을 운영한다. - R2가 파일 콘텐츠의 단일 원본(single source of truth)이 됐다. - 실질적인 크기 제한이 없어 기존 KV에 저장하기 어려웠던 소스 맵, 대형 번들, 폰트 패키지도 함께 저장할 수 있다. - R2의 S3 호환 API를 통해 cdnjs 전체 카탈로그를 일반적인 S3 클라이언트로 접근하고 미러링할 수 있다. - 저장소와 처리 시스템을 하나의 플랫폼으로 통합함으로써 배포 상태 추적, 재처리, 장애 분석을 개선할 기반을 마련했다. ### 실용적인 시사점 대규모 서비스에서는 높은 성능이나 캐시 적중률만으로 충분하지 않다. 여러 클라우드와 저장소에 걸친 파이프라인은 부분 성공, 데이터 불일치, 로그 단절 문제를 만들 수 있으므로, 명확한 단일 원본과 공통 추적 ID, 재처리 가능한 작업 큐를 설계하는 것이 중요하다. 또한 플랫폼이 장시간 작업과 대용량 데이터를 지원할 만큼 성숙해졌다면, 분산된 운영 스택을 통합하는 것이 기능 추가와 보안 관리에 큰 이점이 된다.

원문 읽기(새 탭에서 열림)
Cloudflare Workers서버리스content-delivery-networkcloudflare-r2+3
line5분 읽기큐레이션 요약

AI 에이전트를 위한 Android CLI: 대규모 모바일 개발 환경에 적용하기

LINE Android처럼 수백 개의 Gradle 모듈과 대규모 코드를 가진 저장소에서는 단순한 `grep`·`glob` 검색만으로 AI 에이전트가 의미론적 질문에 답하기 어렵고, 불필요한 결과와 재시도로 토큰 비용이 급증합니다. LINE 개발팀은 Android CLI를 문서 검색과 Android Studio 연동의 기반으로 활용하되, 고정된 바이너리·래퍼·스킬·프롬프트를 조합해 보안, 환경 일관성, 오류 처리, 토큰 효율성을 보완하고 있습니다. 핵심은 CLI를 에이전트에 그대로 노출하지 않고, 저장소 규모와 조직 환경에 맞게 통제된 인터페이스로 제공하는 것입니다. ## 대규모 Android 저장소에서 AI 에이전트가 겪는 문제 - 수백 개의 Gradle 모듈과 방대한 코드 때문에 검색 한 번에도 지나치게 많은 결과가 반환됩니다. - 검색 결과가 에이전트 컨텍스트에 포함되면서 토큰과 비용이 빠르게 증가합니다. - 텍스트 검색만으로는 다음과 같은 의미론적 질문에 정확히 답하기 어렵습니다. - 특정 심볼의 선언 위치 - 심볼의 실제 참조 위치 - IDE가 판단하는 사용되지 않는 코드나 경고 - 의존성 내부 심볼의 위치 - 관련 없는 결과를 바탕으로 에이전트가 반복 검색과 재시도를 수행하면서 비효율이 커집니다. - 따라서 Android CLI를 그대로 적용하기보다는 래퍼, 스킬, 프롬프트를 통한 보완이 필요합니다. ## 문서 검색을 Android CLI로 전환 - Android CLI는 빌드·배포, SDK 관리, 환경 진단, 공식 문서 검색, Android Studio 연동 등을 제공합니다. - 첫 적용 대상은 Android, Jetpack Compose, AndroidX, Firebase 등의 공식 문서 검색이었습니다. - 모델의 사전 학습 지식은 최신 API 변경을 반영하지 못할 수 있어 잘못된 시그니처를 생성하는 환각이 발생할 수 있습니다. - 최신 Android Knowledge Base를 직접 참조하면 문서의 권위와 최신성을 확보할 수 있습니다. - 기존에는 Google Cloud Knowledge MCP 서버를 사용했지만 다음 운영 부담이 있었습니다. - 개발자별 Google Cloud API 인증 설정 - 인증 프록시 운영 - API 할당량 제한 대응 로직 유지 - Android CLI의 `docs` 명령은 다음 두 단계로 사용됩니다. - `docs search`: 키워드로 공식 문서 검색 - `docs fetch`: 검색 결과의 KB URL로 문서 본문 조회 - 이 기능은 `get-android-dev-knowledge` 스킬로 에이전트에 제공됩니다. - 기존 MCP 방식과 비교해 인증, 프록시, 할당량 처리 인프라를 제거하고 더 적은 토큰으로 최신 문서를 참조할 수 있습니다. ## CLI 바이너리를 저장소에 번들링한 이유 LINE 팀은 전역 설치된 `android` 명령 대신 `.agents/tools/android-cli/android`처럼 저장소 내부의 고정 경로에 바이너리를 포함했습니다. ### 환경 파편화 방지 - 개발자마다 CLI 버전, 설치 위치, 운영체제가 달라지는 문제를 줄입니다. - 저장소를 클론하면 동일한 버전을 사용할 수 있습니다. - 개발자 장비뿐 아니라 CI와 AI 에이전트 실행 호스트에서도 동일한 환경을 보장합니다. ### 보안 정책과 래퍼 적용 - Android CLI는 호출 과정에서 일부 데이터를 수집할 수 있습니다. - 이를 막으려면 호출마다 `--no-metrics` 인자를 지정해야 합니다. - 에이전트가 해당 인자를 누락할 수 있으므로 모든 호출을 통과시키는 래퍼에서 강제하는 방식이 안전합니다. - 래퍼가 실제 바이너리를 안정적으로 찾으려면 바이너리 위치가 고정되어 있어야 하므로 저장소 번들링이 유리합니다. - 대규모 저장소에 이미 `git-lfs`가 적용되어 있어 바이너리 포함 비용도 감당할 수 있었습니다. ## `--no-metrics` 관련 버그와 오류 출력 개선 - Android CLI 1.0 도입 과정에서 정보 수집 기능이 `--no-metrics` 처리 전에 초기화되는 버그가 발견되었습니다. - 이 때문에 메트릭 수집을 비활성화해도 `~/.android/cli`에 쓰기를 시도할 수 있습니다. - 샌드박스나 파일 시스템 권한으로 쓰기가 차단되면 여러 페이지의 Java 스택 트레이스가 출력됩니다. - 장황한 스택 트레이스는 에이전트 컨텍스트를 불필요하게 차지하고 문제 해결도 어렵게 만듭니다. - 래퍼는 CLI 실행 전에 다음을 수행합니다. - `~/.android/cli` 디렉터리 생성 시도 - 임시 파일을 만들어 쓰기 권한 확인 - 쓰기가 막히면 한 줄짜리 파싱 가능한 오류 출력 - 에이전트는 이제 긴 예외 대신 “쓰기 권한을 부여한 뒤 재시도하라”는 원인과 조치를 직접 전달받습니다. - 반복적으로 발생하는 오류를 에이전트가 처리하기 쉬운 구조화된 메시지로 변환하는 방식은 이후 Android Studio 연동에도 적용됩니다. ## Android Studio 연동의 의미론적 기능 Android CLI 1.0에서는 실행 중인 Android Studio와 연결해 IDE 수준의 분석을 명령줄에서 수행할 수 있게 되었습니다. - `studio check` - Android Studio 실행 여부를 확인합니다. - 대상 프로젝트가 열려 있는지 확인합니다. - 프로젝트 인덱싱이 완료되었는지 확인합니다. - 다른 Studio 기능을 사용하기 위한 전제 조건입니다. - `studio analyze-file` - 빌드하지 않고 단일 파일에 IDE 인스펙션을 적용합니다. - 에러와 경고를 반환합니다. - `is never used`처럼 단순한 `grep`으로 파악하기 어려운 의미론적 문제도 찾을 수 있습니다. - `studio find-declaration` - 심볼의 선언 위치를 찾습니다. - 프로젝트 코드뿐 아니라 `.aar`, `.jar` 의존성 내부도 검색합니다. - `studio find-usages` - 특정 심볼이 사용된 위치를 찾습니다. - `studio render-compose-preview` - `@Preview`가 적용된 Jetpack Compose 화면을 PNG 이미지로 렌더링합니다. ## CLI를 래퍼와 스킬로 감싼 설계 - Android Studio 기능도 CLI를 에이전트에 직접 노출하지 않고 얇은 래퍼와 스킬을 통해 제공합니다. - 가장 먼저 `studio-check` 스킬을 만들었습니다. - 에이전트가 CLI의 복잡한 입출력과 환경 전제 조건을 직접 처리하지 않도록 하는 것이 목적입니다. - 래퍼는 권한 확인, 실행 환경 검증, 오류 메시지 정규화 같은 공통 처리를 담당합니다. - 스킬은 에이전트가 언제 어떤 기능을 사용해야 하는지 안내하는 고수준 인터페이스 역할을 합니다. 실무적으로는 대규모 저장소에서 Android CLI를 전역 도구로 배포하기보다, 버전을 고정한 바이너리를 저장소에 포함하고 모든 호출을 래퍼로 통제하는 방식을 추천할 수 있습니다. 특히 검색 결과를 무작정 늘리는 대신 문서 검색, 심볼 탐색, IDE 분석처럼 목적에 맞는 의미론적 명령을 스킬로 제공하면 토큰 낭비와 에이전트의 반복 작업을 크게 줄일 수 있습니다.

원문 읽기(새 탭에서 열림)
모델 컨텍스트 프로토콜Androidgradleai-coding-agents+3
google4분 읽기큐레이션 요약

Science One 프레임워크: 증거 사슬을 통한 검증 가능한 자율 연구 프레임워크

Science One Framework는 AI가 생성한 연구 결과의 모든 주장에 실제 근거를 연결하는 Chain-of-Evidence(CoE) 방식으로 환각과 재현성 문제를 줄이는 자율 연구 프레임워크다. 문헌 검색, 실험 탐색, 논문 작성 전 과정에서 증거 사슬을 구축하고, CoE Audit로 인용·점수·코드·방법의 일치 여부를 독립 검증한다. 실험 결과, 기존 시스템의 참고문헌 환각률이 최대 21%에 달한 반면 Science One Framework는 유령 참고문헌 없이 높은 재현성과 성능을 달성했다. ## 자율 연구 시스템에서 검증 가능성이 중요한 이유 - LLM 기반 연구 에이전트는 문헌 조사, 가설 수립, 실험 실행, 논문 작성까지 자동화하고 있다. - 그러나 생성 과정에서 발생한 오류가 다음 단계로 누적·증폭될 수 있다. - 대표적인 문제는 다음과 같다. - 존재하지 않는 논문을 참고문헌으로 생성 - 논문에 설명한 방법과 실제 실행 코드가 불일치 - 논문에 보고된 실험 점수가 코드를 다시 실행했을 때 재현되지 않음 - 따라서 논문의 문장 품질만이 아니라, 각 주장과 근거 사이의 연결을 검증해야 한다. ## Chain-of-Evidence(CoE)의 원칙 - CoE는 데이터베이스 트랜잭션의 ACID처럼 신뢰할 수 있는 연구 산출물이 갖춰야 할 속성을 정의하는 개념적 프레임워크다. - 핵심은 두 가지다. - **완전성**: 연구 산출물의 모든 주장에 기록된 증거 사슬이 있어야 한다. - **정확성**: 연결된 증거가 실제로 해당 주장을 뒷받침해야 한다. - 검증 대상이 되는 주장은 다음과 같다. - 참고문헌의 존재 여부 - 논문에 보고된 실험 수치 - 연구 방법 설명 - 최종 결론 - 증거는 학술 논문, 실험 로그, 실제 실행된 코드, 결과 테이블 등으로 연결된다. - 존재하지 않는 참고문헌, 재현되지 않는 점수, 코드와 다른 방법 설명은 모두 증거 사슬이 끊어진 사례다. ## 문헌을 근거로 고정하는 Problem Investigator - Semantic Scholar API를 사용해 주제별 인용 그래프를 구축한다. - 최대 100개의 전문 PDF를 읽어 구조화된 연구 브리프를 만든다. - 최종 논문의 참고문헌은 모델의 기억에서 생성하지 않고, API를 통해 실제로 검색·확인된 자료에서 가져온다. - 이 방식으로 존재하지 않는 참고문헌이 논문에 포함되는 문제를 방지한다. ## 병렬 탐색을 수행하는 Discovery Engine - 여러 탐색 브랜치를 병렬로 운영해 새로운 아이디어를 탐색하고 성능이 좋은 아이디어를 개선한다. - 각 독립 사이클에서 다음 작업이 수행된다. - Solver 에이전트가 해결책을 구현 - 문제별 evaluator가 결과를 평가 - 성능이 높은 브랜치를 반복적으로 개선 - 모든 evaluator의 원시 출력은 엄격한 읽기 전용 기록으로 저장된다. - 따라서 논문에 기재된 점수를 실제 평가 결과와 대조할 수 있다. ## 주장과 근거를 연결하는 Paper Writer와 Claim Verifier - 논문을 렌더링하기 전에 모든 사실 주장을 구조화하고, 각 주장에 인라인 증거 태그를 붙인다. - 증거 태그는 해당 주장을 뒷받침하는 특정 작업 공간 산출물에 연결된다. - Claim Verifier는 각 주장을 선언된 출처와 대조한다. - 주장이 근거보다 과장된 경우 삭제하기보다 근거가 뒷받침하는 수준으로 보수적으로 다시 작성한다. - 이를 통해 논문 내용이 실제 수행된 연구와 일치하도록 유지한다. ## CoE Audit의 네 가지 검증 CoE Audit는 생성된 논문, 코드, 해결책, 참고문헌을 대상으로 수행하는 사후 자동 감사 프로토콜이다. - **점수 검증** - 논문에서 보고된 점수를 추출한다. - 제출된 코드를 완전히 독립적으로 다시 실행해 결과를 비교한다. - **명세 위반 검사** - 코드가 실제 문제를 해결하는지 확인한다. - 평가 지표를 악용하거나 정답 파일을 직접 읽는 등의 부정한 구현을 검사한다. - **참고문헌 검증** - 모든 참고문헌을 학술 API와 대조한다. - 존재하지 않는 유령 참고문헌을 식별한다. - **방법-코드 정렬 검사** - LLM 심사자가 논문의 방법론 설명과 코드를 나란히 비교한다. - 논문이 실제 구현보다 복잡하거나 다른 알고리즘을 설명하는지 확인한다. ## 실험 결과 - ADRS 벤치마크의 5개 시스템 최적화 과제(Prism, Cloudcast, EPLB, LLM-SQL, transaction scheduling)에서 5개 시스템이 생성한 총 75편의 논문을 평가했다. - Science One Framework는 네 가지 무결성 검사 모두에서 기존 기준 시스템보다 우수했다. - 참고문헌 환각률은 0%였다. - 반면 기존 시스템에서는 최대 21%의 참고문헌이 존재하지 않았다. - 제출 코드의 독립 재실행을 통한 점수 검증에서 완벽한 결과를 보였다. - 방법 설명과 실제 코드의 일치도 역시 가장 높았다. - 일부 기준 시스템은 실제 코드가 단순한 결정론적 휴리스틱임에도 “하이브리드 뉴로-심볼릭 솔버”처럼 과장된 방법을 기술했다. - 검증 절차를 강화했음에도 연구 성능이 저하되지 않았다. - 5개 ADRS 과제에서 인간 전문가 수준 이상을 기록했다. - Cloudcast와 EPLB에서는 전체 시스템 중 최고 성능을 달성했다. - 외부 일반화 평가에서도 MLE-Bench의 의료 영상, 세밀한 이미지 인식, 3D 인식 관련 대회에 적용되었으며, 일부 과제에서 Gold Medal 성과를 기록했다. ## 실용적인 시사점 자율 연구 시스템은 논문을 완성한 뒤 사실을 확인하는 방식보다, 문헌·코드·실험 로그·결과를 생성 시점부터 연결하는 구조가 바람직하다. 특히 자동화된 연구 결과를 실제 의사결정이나 후속 연구에 사용하려면, 논문 자체뿐 아니라 독립적인 코드 재실행, 참고문헌 확인, 방법-코드 비교를 포함한 CoE Audit 같은 검증 절차를 함께 운영해야 한다.

원문 읽기(새 탭에서 열림)
대규모 언어 모델머신러닝autonomous-agentssemantic-scholar-api+3
figma3분 읽기큐레이션 요약

속성 패널과 주석 기능, 이제 Figma Make에서 사용 가능 | Figma 블로그

Figma Make에 속성 패널과 주석 기능이 추가되어, 사용자는 코드를 직접 작성하지 않고도 시각적으로 인터페이스를 수정할 수 있게 되었다. 속성 패널은 간격·타이포그래피·레이아웃 같은 시각적 변경을 정밀하게 처리하고, 주석은 애니메이션이나 상호작용처럼 설명이 필요한 변경을 특정 요소에 연결해 전달한다. 두 기능은 디자인과 코드 사이의 간극을 줄이고, 프롬프트 기반 편집보다 정확하고 효율적인 작업 흐름을 제공한다. ## Figma Make의 속성 패널과 주석 기능 - Figma Make 편집기에서 요소를 선택한 뒤 시각적 컨트롤이나 자연어 주석으로 코드를 수정할 수 있다. - 디자인을 수정하는 과정과 코드가 업데이트되는 과정을 하나의 연속적인 작업 흐름으로 통합한다. - 새 기능은 처음부터 작업하는 경우뿐 아니라 기존 코드 기반 프로젝트를 편집할 때도 사용할 수 있다. ## 속성 패널을 활용한 시각적 편집 - 상단 툴바에서 **Edit**를 선택하면 요소의 속성을 조정할 수 있다. - 조정 가능한 항목에는 다음이 포함된다. - 패딩, 요소 간 간격, 코너 반경 - 글꼴 굵기, 줄 높이, 자간 - 투명도, `z-index`, 테두리 스타일 - 위치와 레이아웃 속성 - 코드의 전체 DOM 트리를 레이어 패널처럼 확인하면서 원하는 요소를 선택할 수 있다. - 동일한 요소의 모든 인스턴스를 한 번에 선택해 일괄 수정할 수 있다. - 현재는 코드베이스에 정의된 색상 및 타이포그래피 토큰을 사용해 디자인 일관성을 유지한다. - 향후 Code Connect가 적용되면 Figma Design 컴포넌트와 코드 컴포넌트 간 연결도 강화될 예정이다. ## 변경 사항 검토와 코드 반영 - 속성 패널에서 변경한 내용은 즉시 코드에 확정되지 않고 프롬프트 입력창에 먼저 단계적으로 쌓인다. - 사용자는 각 변경 사항을 검토한 뒤 적용하거나 마음에 들지 않는 변경을 폐기할 수 있다. - 적용을 완료하면 Figma Make가 실제 코드를 수정하고 새로운 파일 버전을 생성한다. - 따라서 캔버스에서 시각적으로 확인한 결과와 실제 배포되는 코드 사이의 불일치를 줄일 수 있다. ## 주석을 통한 정밀한 프롬프트 작성 - 속성 패널만으로 표현하기 어려운 상호작용, 애니메이션, 동작 변경에는 주석 기능을 사용할 수 있다. - **Annotate for agent**를 선택한 뒤 캔버스에서 변경 대상 영역을 직접 표시하고 자연어로 요구사항을 작성한다. - 예시는 다음과 같다. - 썸네일에 마우스를 올리면 약간 확대 - 버튼을 300ms 지연 후 페이드 인 - 버튼을 탭할 때 눌리는 효과 추가 - 메뉴 버튼 클릭 시 전체 화면 내비게이션 오버레이 표시 - 번호가 매겨진 주석으로 여러 요소를 동시에 지정할 수 있다. - 에이전트는 표시된 정확한 위치와 설명을 함께 활용해 관련 코드 전체에 변경 사항을 적용한다. ## 프롬프트 비용과 작업 효율 - 직접 요소를 선택하면 에이전트가 수정 대상을 탐색하거나 추측할 필요가 줄어든다. - 일반적인 텍스트 프롬프트로 같은 변경을 설명하는 것보다 토큰을 적게 사용하고 더 빠르게 완료할 수 있다. - 변경 사항은 적용 전까지 크레딧을 소비하지 않고 대기한다. - 최종적으로 변경 사항을 적용할 때 크레딧이 차감되고 파일이 새 버전으로 업데이트된다. ## 디자인과 코드의 통합 - 속성 패널은 시각적 조정에, 주석은 동작과 맥락이 필요한 변경에 적합하다. - 두 기능을 통해 사용자는 코드를 직접 다루면서도 Figma와 유사한 시각적 편집 경험을 유지할 수 있다. - 같은 편집 경험은 향후 Figma Design의 코드 레이어에도 제공될 예정이다. - 장기적으로는 Figma 캔버스에서 코드 기반 결과물을 여러 방향으로 탐색하고 팀과 함께 비교하는 작업이 가능해진다. 실무에서는 간격·타이포그래피·레이아웃처럼 명확한 시각 속성은 속성 패널로 수정하고, 인터랙션이나 애니메이션처럼 의도가 중요한 변경은 주석으로 요청하는 방식이 가장 효율적이다. 적용 전 검토 단계가 제공되므로 여러 변경을 시도한 뒤 실제 코드 반영 여부를 결정하는 것도 권장된다.

원문 읽기(새 탭에서 열림)
Figmafigma-makedesign-to-codecode-connect+2
toss5분 읽기큐레이션 요약

LLM은 똑똑한데, 왜 우리 회사 일은 모를까

LLM이 사내 질문에 정확히 답하려면 단순히 관련 문서를 검색하는 것만으로는 부족하다. 문서·코드·메신저의 최신성, 상충 여부, 실제 구현과의 일치 여부까지 관리하는 신뢰 가능한 컨텍스트 계층이 필요하며, Topic은 이를 구축하기 위한 시스템이다. Topic은 원본을 의미 단위로 정규화하고, 개념과 관계를 연결한 뒤, 변경된 부분만 선택적으로 검증한다. ## 검색만으로는 신뢰를 보장할 수 없는 이유 - 검색은 질문과 관련된 텍스트를 찾아줄 뿐, 해당 정보가 최종 결정인지 판단하지 못한다. - 문서, 미팅, 코드가 서로 다른 정책을 설명할 수 있다. - 메신저 논의가 실제 결론인지, 문서가 오래된 것인지, 코드 변경이 의도된 것인지 추가 판단이 필요하다. - 에이전트가 각자 원문을 검색하면 자료 선택과 충돌 해석이 달라져 답변 일관성이 떨어진다. - Topic은 출처, 관계, 최신성, 충돌 상태를 공통 계층에서 관리해 사람과 LLM이 같은 근거를 사용하도록 한다. ## 신뢰를 구성하는 여섯 가지 축 - **Granularity**: 독립적으로 관리할 수 있는 적절한 크기와 의미의 컨텍스트인지 판단한다. - **Faithfulness**: 컨텍스트의 주장이나 설명이 원문 근거로 뒷받침되는지 확인한다. - **Staleness**: 정보가 현재도 유효한지 검사한다. - **Canonicality**: 서로 다른 이름이나 표현이 같은 대상을 가리키는지 판단한다. - **Consistency**: 여러 출처의 내용이 서로 양립하는지 확인한다. - **Coverage**: 중요한 근거와 관점이 누락되지 않았는지 살핀다. - 모든 문제를 하나의 신뢰도 점수로 합치지 않고, 규칙·LLM·사람 검토를 각각 적합한 판단에 사용한다. ## Ingest: 출처별 의미 단위를 보존한 정규화 Topic은 문서·코드·메신저의 원본을 공통 `ContentUnit`으로 변환한다. - 주요 필드: - `source_type`: document, code, messenger - `unit_type`: 문서 섹션, 메신저 스레드 등 - `source_uri`: 원문으로 돌아가는 주소 - `content_hash`: 변경 감지용 해시 - `created_at_src`, `updated_at_src` - 출처별 식별자와 구조를 담은 `metadata` - 공통 형식은 후속 추출·검증을 일관되게 만든다. - 출처별 구조는 의미 경계와 증거의 원천을 보존하기 위해 유지한다. ### 문서는 제목 계층 단위로 분할 - Markdown 문서를 고정 길이가 아니라 제목 구조에 따라 나눈다. - 상위 제목 경로를 함께 저장해 문장이 어떤 정책이나 기능에 속하는지 보존한다. - 섹션이 지나치게 긴 경우에만 추가 분할한다. - 문서 경로, 원문 URL, 작성·수정 시각도 검증 정보로 남긴다. ### 메신저는 개별 메시지보다 스레드 단위로 처리 - 메시지 하나만 보면 질문인지 결론인지 알기 어렵기 때문에 스레드 전체를 하나의 의미 단위로 삼는다. - 요약 시: - 함수명, 에러 클래스, 파일 경로 등 기술 식별자를 원문 그대로 보존한다. - 질문, 검토한 선택지, 최종 결과를 구분한다. - 확정된 내용과 미결정 내용을 나눈다. - 대화에 없는 합의를 만들어내지 않는다. - 잡담만 있는 스레드는 컨텍스트로 만들지 않는다. ### 코드는 심볼과 비즈니스 동작을 함께 표현 - 파서로 함수·클래스 등 코드 심볼을 추출한다. - 파일 경로, 심볼 종류, 시작·종료 줄, import 관계는 규칙 기반으로 수집한다. - 여러 심볼을 가로지르는 업무 동작은 `CodeSemanticCard`로 묶는다. - semantic card에는 다음 정보가 포함된다. - 업무 대상과 실제 동작 - 도메인 용어와 코드 식별자 - 저장소·파일·줄·심볼 단위의 근거 span - 기준이 된 `commit_sha` - LLM이 만든 카드는 파일·줄이 실제 존재하는지, 설명을 뒷받침하는 span이 있는지 규칙 기반으로 재검사한다. - 최종 검증에서는 카드의 설명만 믿지 않고 현재 코드의 실제 span을 다시 읽는다. ## Extract: 개념과 관계를 원문 근거와 연결 - 각 `ContentUnit`에서 개념 후보와 이를 뒷받침하는 문장을 추출한다. - 함께 등장한 후보를 중심으로 관계를 제안하고, 표현·의미가 유사한 후보의 중복 가능성을 계산한다. - 충분한 근거가 있을 때만 대표 개념으로 통합한다. - 문서·메신저·코드처럼 출처가 다른 unit 사이에도 연결 후보를 만든다. - 개념과 관계에는 원문 위치, 인용, 판단 상태를 함께 저장한다. ### 사내 용어는 사람 검토를 포함 - 띄어쓰기·대소문자 차이는 정규화와 임베딩으로 자동 탐지할 수 있다. - 사내 약어와 별칭은 잘못 합치면 검색·검증 전체를 오염시킬 수 있다. - 애매한 동의어는 즉시 병합하지 않고 `Synonym Proposal`로 등록한다. - 사람이 승인한 별칭만 관리되는 관계로 반영하며, 거절된 후보는 반복 제안하지 않는다. ### 문서와 코드 관계를 유형별로 구분 - `supported_by`: 코드가 문서의 설명을 뒷받침한다. - `contradicted_by`: 코드와 문서의 동작이 충돌한다. - `mentions`: 같은 기능을 언급하지만 일치·충돌 여부를 판단할 근거가 부족하다. - 임베딩으로 후보를 제한한 뒤, 의미 판단이 필요한 후보만 배치 검증한다. - 관계에는 유형뿐 아니라 신뢰도, 판단 이유, 원문 인용, 검증 상태를 기록한다. - 검증 실패나 낮은 신뢰도는 관계를 저장하지 않는다. 관계가 없다는 것은 무관하다는 뜻이 아니라 아직 확인되지 않았다는 의미다. ## Verify: 변경된 부분만 선택적으로 재검증 - 각 unit의 안정적인 식별자와 `content_hash`를 이용해 변경 범위를 추적한다. - 변경되지 않은 unit의 추출·관계 결과는 재사용한다. - 새로 생성되거나 변경된 unit만 다시 처리한다. - 원본이 삭제되면 해당 원본을 참조하던 관계도 정리한다. - 코드 anchor에는 검증 당시의 commit과 span hash를 저장한다. - 현재 코드에서 anchor가 사라졌으면 orphaned 상태로 표시한다. - anchor의 span hash가 같으면 의미 검증을 생략한다. - span hash가 달라졌으면 변경된 코드에 대해 faithfulness를 다시 검증한다. - 해시와 참조 무결성은 규칙 기반으로 검사하고, 실제 의미가 달라진 경우에만 LLM을 호출한다. - 이 방식은 비용을 줄이면서도 변경 원인과 컨텍스트 상태 변화를 추적하게 해준다. ## 실용적인 결론 사내 LLM의 품질을 높이려면 검색 성능만 개선하기보다, 의미 단위·원문 근거·출처 간 관계·최신성·충돌 상태를 함께 관리해야 한다. 특히 자동화는 명확한 변경 감지와 관계 추출에 사용하고, 사내 용어 통합이나 중요한 정책 판단처럼 맥락 의존적인 문제는 근거를 제시한 뒤 사람의 승인을 받는 방식이 안전하다.

원문 읽기(새 탭에서 열림)
대규모 언어 모델human-in-the-loopsemantic-searchknowledge-graph+4
toss6분 읽기큐레이션 요약

토스의 디바이스 팜 만들기

네뷸라는 팀별로 흩어져 운영하던 실기기 테스트 환경을 중앙 플랫폼으로 통합해, 누구나 API 호출 한 번으로 실제 스마트폰을 제어할 수 있도록 만든 사내 디바이스 팜입니다. Appium 대신 자체 드라이버를 개발해 속도와 확장성을 높였고, 실시간 미러링·보안·24시간 운영 안정성까지 직접 구축했습니다. 그 결과 15대에서 시작한 팜은 100대를 넘어 수백 대 규모로 확장되며 전사 공용 테스트 인프라로 자리 잡았습니다. ## 팀별 디바이스 팜의 한계 - 각 팀이 맥북이나 맥미니에 5~10대의 기기를 직접 연결하고 관리했습니다. - Appium 설정, 기기 인식, OS 버전 대응, 연결 장애 복구를 팀마다 반복해야 했습니다. - 기기 관리와 테스트, 보안·컴플라이언스까지 개발자가 함께 맡아야 했습니다. - 팀별 자원이 격리되어 회사 전체의 기기를 효율적으로 공유하기 어려웠습니다. - 네뷸라는 이러한 운영 부담을 중앙화하고 전문 플랫폼으로 이전하기 위해 시작됐습니다. - 맥미니 5대와 기기 15대, 개발자 1명으로 시작해 1년간 100대 이상으로 성장했습니다. ## API 한 번으로 실기기 제어 - 사용자는 기기가 어느 호스트에 연결됐는지, ADB나 Xcode를 어떻게 설정했는지 알 필요가 없습니다. - `occupy` API로 조건에 맞는 기기를 점유한 뒤 액션 API를 호출하면 됩니다. - 예를 들어 다음과 같은 흐름으로 기기를 사용할 수 있습니다. - Android 기기 점유 - 좌표 `(540, 1200)` 클릭 - 테스트 종료 후 기기 반환 - 예약, 케이블 연결, 로컬 환경 설정을 숨기고 단순한 인터페이스를 제공하는 것이 네뷸라의 핵심 가치입니다. ## 네뷸라의 4계층 아키텍처 - **클라이언트** - 웹 프런트엔드, SDK·CLI, 직접 API 호출 등 다양한 접근 방식을 제공합니다. - **서버** - 기기 발견·점유·할당·테스트 실행을 관리하는 오케스트레이션 계층입니다. - 테스트 요청은 Kafka로 전달되고 여러 Runner가 분산 처리합니다. - `occupy · assign · release` 기반 분산 락으로 한 기기를 여러 테스트가 동시에 사용하는 문제를 방지합니다. - **에이전트** - iOS용 Mac mini와 Android용 Linux 호스트에서 실행됩니다. - ADB·Xcode로 연결된 기기를 자동 발견하고 서버 요청을 로컬 기기로 전달합니다. - **기기 계층** - 기기마다 controller server와 controller runner가 동작합니다. - 실제 화면 클릭, 텍스트 입력 등의 동작은 이 계층에서 수행됩니다. ## Appium 대신 개발한 Nebula Driver ### 빠른 명령 처리 - Appium과 Android 기기에서 명령 지연을 비교한 결과, 클릭·입력 작업에서 네뷸라가 10배 이상 빠른 경우가 있었습니다. - Appium은 동작 전 화면이 안정될 때까지 기다리는 `waitForIdle`을 사용해 견고성을 높입니다. - 네뷸라는 화면이 진행 중이어도 노드에 바로 명령을 전달하고 즉시 반환하는 속도 우선 방식을 택했습니다. - `waitForIdle`을 끄면 성능 격차가 2~3배 수준으로 줄어들지만, 실시간 조작이 중요한 네뷸라에는 속도 중심 설계가 적합했습니다. ### Stateless 구조 - Appium은 세션 기반이라 세션 생성에 약 15~40초가 걸릴 수 있습니다. - 기기 수가 늘수록 세션 생성 실패와 세션 관리 비용도 증가합니다. - 네뷸라는 기기 컨트롤러를 미리 실행해 두고, 상태 없는 HTTP 호출을 받는 구조를 사용합니다. - 세션 시작 비용과 세션 장애를 줄이고, 대규모 기기 운영에 유리한 구조를 만들었습니다. ### 사내 환경에 맞춘 확장 - 자체 인터페이스를 소유하므로 필요한 기능을 직접 추가할 수 있습니다. - 한글·이모지 입력을 지원하는 자체 IME를 구현했습니다. - 토스 앱 전용 신호 트리거를 추가할 수 있습니다. - 사내 앱센터와 연동해 pre-release 빌드를 기기에 바로 설치할 수 있습니다. - 보안 정책도 드라이버 규격 안에서 강제할 수 있습니다. - Android는 ADB·UiAutomation, iOS는 Swift·XCTest를 기반으로 구현하고, OpenAPI 스펙으로 Go·TypeScript 코드를 자동 생성했습니다. ## 실시간 화면 미러링 - 네뷸라는 정해진 테스트 스텝만 실행하는 도구가 아니라, 사용자가 화면을 보면서 동시에 조작할 수 있어야 했습니다. - 따라서 실시간 조작과 실시간 영상 스트리밍을 Android·iOS 모두에서 해결해야 했습니다. ### Android 미러링 - scrcpy는 Android 화면을 데스크톱 앱에 보여주는 데 적합하지만, 서버를 거쳐 여러 브라우저에 배포하는 구조에는 맞지 않았습니다. - 네뷸라는 scrcpy의 인코딩 방식을 참고하되 자체 미러링 경로를 구현했습니다. - `SurfaceControl`로 가상 디스플레이를 만들고 `MediaCodec`으로 H.264 영상을 인코딩합니다. - 인코딩된 영상은 브로드캐스터를 통해 여러 브라우저 시청자에게 전달됩니다. ### iOS 미러링 - iOS는 Android처럼 화면을 자유롭게 추출하기 어렵고 USB 사용 방식에도 제약이 있습니다. - 기존 QVH·Appium MJPEG 방식은 화면을 보면서 동시에 조작하는 요구를 충족하지 못했습니다. - QuickTime Player의 iOS 화면 캡처 방식과 유사한 경로를 USB 독점 없이 내재화했습니다. - 그 결과 조작과 미러링을 동시에 수행할 수 있게 됐습니다. - Android와 iOS 모두 실시간 H.264·브로드캐스팅 경로로 통일해 브라우저에서 여러 기기를 한 번에 볼 수 있습니다. ## 중앙화로 강화한 보안과 컴플라이언스 - 팀별 운영에서는 개발자가 테스트와 기기 관리, 보안 준수를 모두 책임져야 했습니다. - 네뷸라 팀은 사내 보안팀과 협력해 모바일 기기 팜 운영 기준을 정의했습니다. - 중앙 플랫폼에 보안 정책을 적용해 모든 기기에 동일한 기준을 일괄 반영할 수 있게 했습니다. - 사용자는 보안 요건이 적용된 환경에서 테스트에만 집중할 수 있습니다. ## 24시간 운영을 위한 안정성 ### 하드웨어 운영 - USB 연결 안정성, 케이블·허브 선택, 전원 공급, 서버실 설계를 직접 검증했습니다. - 물리적 장애를 완전히 제거할 수 없기 때문에 사람의 대응 체계와 이중화를 함께 준비하고 있습니다. ### 소프트웨어 운영 - 호스트별 컨트롤러와 미러링 프로세스를 오케스트레이션합니다. - 프로세스가 종료되더라도 자동으로 복구되도록 설계했습니다. - 서버·에이전트·컨트롤러·미러링 구성요소에 무중단 배포를 적용했습니다. - 기기 상태, 프로세스 상태, 서버 성능을 함께 관측하는 모니터링 체계를 구축하고 있습니다. - 여러 팀이 상시 사용하는 공용 인프라이므로 안정성을 핵심 기능으로 취급합니다. ## API 위에 만들어진 테스트 생태계 - 기기 15대에서 100대 이상, 수백 대 규모로 확장 중이며 24시간 운영됩니다. - 웹페이지에서는 미러링 화면을 보며 클릭으로 테스트 스텝을 만들 수 있습니다. - SDK로 E2E 테스트 코드를 작성하고, CLI로 터미널·CI/CD·AI 에이전트에서 기기를 제어할 수 있습니다. - 제품 로그가 기대대로 기록되는지 검수하는 시스템에도 활용됩니다. - AI 에이전트가 API를 호출해 테스트 스텝을 직접 판단하고 실행할 수도 있습니다. - 하나의 공개 API를 기반으로 여러 도구와 활용 사례가 자연스럽게 확장됐습니다. - 사용자 사례에 따르면 Appium 기반 테스트를 이전한 뒤 실행 속도가 크게 향상됐고, 수동 검수 시간이 30~40분에서 10분 이내로 줄었습니다. 네뷸라의 사례는 기기 수를 늘리는 것보다, 복잡한 하드웨어와 운영 문제를 단순한 API 뒤로 숨기는 것이 중요하다는 점을 보여줍니다. 비슷한 플랫폼을 구축한다면 초기부터 기기 점유 모델, 실시간 미러링, 보안 정책, 자동 복구와 무중단 배포를 함께 설계하고, 내부 사용자가 쉽게 확장할 수 있는 단일 API를 중심에 두는 것이 좋습니다.

원문 읽기(새 탭에서 열림)
AndroidiOSApache Kafkaopenapi+4
github3분 읽기큐레이션 요약

Dependabot 길들이기: 업데이트를 그룹화하고, 주기를 늦추되, 보안 업데이트는 신속하게

활성 저장소에서는 Dependabot이 의존성마다 개별 PR을 생성해 알림, 리뷰, CI 실행을 과도하게 늘릴 수 있다. 글은 Microsoft GCToolkit 사례를 통해 의존성 업데이트를 생태계별로 그룹화하고 주기를 월간으로 늦추면 유지보수 소음을 크게 줄일 수 있다고 설명한다. 다만 일반 버전 업데이트와 달리 보안 업데이트는 신속하게 처리되므로, 업데이트 빈도를 낮춰도 보안 대응 속도는 유지할 수 있다. ## Dependabot이 만드는 유지보수 소음 - GCToolkit의 578개 커밋 중 92개가 Dependabot 버전 업데이트였으며, 최근 12개월에만 61개가 발생했다. - 기존 설정은 다음과 같았다. - GitHub Actions만 감시 - 매일 업데이트 확인 - 최대 10개의 PR 허용 - 의존성 10개가 업데이트되면 PR 10개, CI 실행 10회, 리뷰 알림 10건이 발생한다. - `open-pull-requests-limit: 10`은 PR 수를 제한할 뿐, 업데이트가 쏟아지는 원인을 해결하지 못한다. ## 여러 업데이트를 하나의 PR로 그룹화 - `groups`와 `patterns: ["*"]`를 사용하면 모든 의존성 업데이트를 하나의 PR로 묶을 수 있다. - 예를 들어 10개의 업데이트가 발생해도 다음처럼 처리된다. - 브랜치 1개 - PR 1개 - CI 실행 1회 - 리뷰 및 병합 1회 - 그룹 이름은 자유롭게 정할 수 있으며 PR 제목과 브랜치 이름에 표시된다. - 규모가 큰 프로젝트에서는 테스트 라이브러리, 운영 의존성 등 목적별로 여러 그룹을 만들 수 있다. - 모노레포에서는 `directories`와 `group-by: dependency-name`을 사용해 여러 디렉터리에 같은 의존성이 있을 때 하나의 PR로 통합할 수 있다. ```yaml - package-ecosystem: "npm" directories: - "/apps/*" schedule: interval: "monthly" groups: monthly-batch: group-by: dependency-name patterns: - "*" ``` ## 업데이트 주기를 일간에서 월간으로 변경 - `interval: daily`는 평일마다 업데이트를 확인하므로 지속적인 PR 생성으로 이어질 수 있다. - `interval: monthly`로 바꾸면 계획 가능한 월간 배치 방식으로 전환된다. - 그룹화와 결합하면 생태계별로 한 달에 하나의 일괄 PR을 받게 된다. - 프로젝트 특성에 따라 `weekly`를 선택할 수도 있고, `schedule.day`와 `schedule.time`으로 실행 시점을 지정할 수 있다. - 의존성이 안정적인 성숙한 라이브러리에는 월간 주기가 적합하다. ## 실제 사용하는 생태계를 모두 설정 - 기존 설정은 GitHub Actions만 대상으로 했지만, GCToolkit은 Maven 기반 Java 프로젝트이므로 Maven 의존성도 별도로 등록해야 했다. - 생태계마다 `updates` 항목을 추가해야 한다. ```yaml - package-ecosystem: "github-actions" directory: "/" schedule: interval: "monthly" groups: monthly-batch: patterns: - "*" - package-ecosystem: "maven" directory: "/" schedule: interval: "monthly" groups: monthly-batch: patterns: - "*" ``` - GitHub Actions와 Maven 업데이트는 각각 독립된 그룹과 일정으로 관리된다. - 소음을 줄이는 것뿐 아니라, 실제 애플리케이션 의존성까지 Dependabot이 감시하도록 만드는 것이 중요하다. ## 보안 업데이트는 빠르게 유지 - 월간 일정과 그룹 설정은 일반적인 버전 업데이트의 처리 방식을 조정하는 설정이다. - Dependabot 보안 업데이트는 별도의 메커니즘으로 동작하므로, 일반 업데이트 주기를 늦춰도 보안 취약점 대응까지 월간으로 미뤄지지 않는다. - 따라서 평상시에는 일괄 업데이트로 리뷰 부담을 줄이고, 보안 수정은 기존처럼 신속하게 처리하는 균형을 유지할 수 있다. ## 실용적인 적용 방법 - 안정적인 저장소라면 생태계별로 `monthly` 일정과 전체 의존성 그룹화를 적용한다. - 업데이트가 자주 필요하거나 변경 영향이 큰 프로젝트는 `weekly` 또는 목적별 다중 그룹을 사용한다. - GitHub Actions뿐 아니라 Maven, npm 등 실제 사용하는 모든 패키지 생태계를 `dependabot.yml`에 등록한다. - 보안 업데이트 설정은 별도로 확인해 취약점 수정이 지연되지 않는지 점검한다.

원문 읽기(새 탭에서 열림)
CI/CDGitHub Actionsdependency-managementmaven+2
cloudflare4분 읽기큐레이션 요약

오리진에 대한 양자 이후 인증이 이제 지원됩니다

Cloudflare는 Cloudflare와 고객의 원본 서버 사이 연결에 ML-DSA 기반의 포스트퀀텀(PQ) 인증을 지원하기 시작했다. 이제 Custom Origin Trust Store와 Authenticated Origin Pulls를 조합하면 원본 서버 연결을 암호화할 뿐 아니라 양쪽을 포스트퀀텀 방식으로 인증하는 mTLS 구성이 가능하다. 이는 Cloudflare가 2029년까지 완전한 포스트퀀텀 보안을 달성하기 위해 세운 로드맵의 첫 번째 주요 milestone이다. ## 포스트퀀텀 인증이 필요한 이유 - 기존에는 양자컴퓨터가 현재의 암호화를 미래에 해독하는 ‘수집 후 해독(harvest-now/decrypt-later)’ 공격에 대비해 포스트퀀텀 암호화를 우선 배포했다. - 최근 양자컴퓨팅과 암호해석 기술의 발전으로, 공격자가 고전적 인증서를 위조해 서버나 클라이언트를 사칭하는 위험에도 대비해야 하게 됐다. - Cloudflare는 다음 연결에 대해 이미 포스트퀀텀 암호화를 지원하고 있다. - 방문자와 Cloudflare 간 연결: 2022년 지원 - Cloudflare와 원본 서버 간 연결: 2023년 지원 - 이번 변경은 여기에 포스트퀀텀 인증을 추가한 것이다. ## Cloudflare-원본 서버 연결의 특성 - 웹사이트 요청에는 일반적으로 두 개의 TLS 연결이 사용된다. - 방문자 → Cloudflare - Cloudflare → 고객 원본 서버 - Cloudflare-원본 서버 연결에서는 Cloudflare가 TLS 클라이언트 역할을 하므로 인증 방식을 직접 통제할 수 있다. - Cloudflare는 여러 요청을 적은 수의 연결로 묶는 connection pooling을 사용해 PQ 서명에 따른 연결 설정 비용을 분산할 수 있다. - 고객과 이미 Cloudflare 계정 기반의 신뢰 관계가 있으므로, 공개 웹 PKI의 제약 없이 용도에 맞는 사설 PKI를 사용할 수 있다. - 중간 인증서 체인과 Certificate Transparency가 필요하지 않을 수 있다. - 공개 웹의 인증서 생태계보다 빠르게 ML-DSA 인증을 배포할 수 있다. - 방문자-Cloudflare 연결에서는 향후 Merkle Tree Certificates(MTC)를 활용할 계획이며, 초기 배포 목표는 2027년이다. ## 지원되는 ML-DSA 구성 - Cloudflare는 FIPS 204의 세 가지 ML-DSA 파라미터 세트를 지원한다. - ML-DSA-44 - ML-DSA-65 - ML-DSA-87 - 대부분의 애플리케이션에는 성능이 가장 우수하고 NIST 보안 강도 카테고리 2를 제공하는 ML-DSA-44가 권장된다. ## Custom Origin Trust Store를 이용한 원본 인증 - Full (strict) SSL 모드에서 Cloudflare는 원본 서버의 인증서를 신뢰 저장소와 대조한다. - 기본적으로 일반적으로 신뢰되는 CA와 Cloudflare Origin CA가 사용된다. - Custom Origin Trust Store(COTS)를 사용하면 고객이 관리하는 CA 목록으로 기본 신뢰 저장소를 대체할 수 있다. - 이제 ML-DSA CA를 업로드할 수 있으며, Cloudflare는 해당 CA로부터 발급된 원본 서버 인증서만 신뢰하도록 구성할 수 있다. - COTS 사용에는 Advanced Certificate Manager가 필요하다. ## Authenticated Origin Pulls를 이용한 상호 인증 - Authenticated Origin Pulls(AOP)는 원본 서버가 Cloudflare에서 온 요청만 처리하도록 제한하는 기능이다. - Cloudflare가 클라이언트 인증서를 제시하므로 원본 서버는 요청 주체가 Cloudflare인지 검증할 수 있다. - 이를 통해 Cloudflare와 원본 서버 간 상호 TLS(mTLS)를 구성할 수 있다. - AOP는 모든 Cloudflare 요금제에서 무료로 제공된다. - 영역(zone)별 및 호스트명별 설정에서 다음을 업로드할 수 있다. - ML-DSA 인증서 - ML-DSA 개인 키 - 개인 키는 현재 FIPS 204 seed 형식으로만 업로드할 수 있다. - 전역(global) 설정의 ML-DSA 지원은 아직 제공되지 않으며 추후 작업으로 예정되어 있다. ## 다운그레이드 공격 방지 - 양쪽이 PQ 인증을 지원하는 것만으로는 완전한 포스트퀀텀 보안이 보장되지 않는다. - 원본 서버가 기존의 양자 취약 인증 방식도 계속 신뢰하면, 공격자가 고전적 인증서를 위조해 연결을 다운그레이드할 수 있다. - 따라서 인증서를 검증하는 원본 서버는 양자 취약한 인증 메커니즘에 대한 신뢰를 제거해야 한다. - 복잡한 PKI에서는 인증 체계 전환 단계와 신뢰 설정을 별도로 설계해야 한다. ## 구성에 필요한 도구와 절차 - 인증서 생성에는 OpenSSL 3.5.0 이상이 필요하다. - Cloudflare가 현재 허용하는 개인 키 형식은 FIPS 204의 seed-only 인코딩이다. - 일반적인 구성 절차는 다음과 같다. - ML-DSA-44 등의 알고리즘으로 원본 서버용 CA와 인증서 체인을 생성한다. - 생성한 CA를 COTS에 업로드한다. - ML-DSA 클라이언트 인증서와 개인 키를 AOP의 영역별 또는 호스트명별 설정에 업로드한다. - Cloudflare API 또는 대시보드를 통해 원본 서버의 mTLS 및 인증서 검증을 활성화한다. - 원본 서버에서 양자 취약 인증서와 인증 기관을 신뢰하지 않도록 설정한다. ## 실용적인 권장 사항 대부분의 사용자는 ML-DSA-44를 사용해 COTS와 AOP를 함께 구성하는 것이 적절하다. 단순히 ML-DSA 인증서를 추가하는 데 그치지 말고, 원본 서버의 신뢰 저장소에서 기존 양자 취약 인증 방식을 제거해야 다운그레이드 공격까지 방어할 수 있다.

원문 읽기(새 탭에서 열림)
cloudflarepost-quantum-cryptographyml-dsaopenssl+4
discord2분 읽기큐레이션 요약

프로필 프레임 소개: Discord 프로필을 박물관에 전시할 만큼 멋지게 꾸며 주는 장식 테두리

디스코드가 프로필을 꾸밀 수 있는 새로운 장식 요소인 **Profile Frames**를 출시했습니다. Profile Frames는 프로필 주변에 장식 테두리를 추가해 아바타, 이름표, 프로필 효과 등과 함께 개성을 표현할 수 있게 합니다. 프레임은 Shop에서 구매할 수 있으며, Nitro 이용자는 할인과 서버별 프레임 설정 혜택을 받을 수 있습니다. ## 프로필 프레임이란? - 디스코드 프로필 가장자리에 장식 테두리를 추가하는 기능입니다. - 프로필을 더욱 개성 있고 완성도 있게 꾸밀 수 있습니다. - 기존의 Avatar Decorations, Nameplates, Profile Effects, Display Name Styles 등과 함께 사용할 수 있습니다. ## Shop에서 구매 및 관리 - Profile Frames는 디스코드 Shop에서 구매할 수 있습니다. - 데스크톱에서는 앱 왼쪽 상단의 디스코드 로고를 클릭해 Shop에 들어갑니다. - 모바일에서는 “You” 버튼을 누른 뒤 오른쪽 상단의 Shop 아이콘을 선택합니다. - 구매한 프레임은 원하는 때에 프로필에 적용하거나 해제할 수 있습니다. - 마음에 드는 프레임은 Wishlist에 추가해 다른 사람에게 선물 아이디어로 보여줄 수 있습니다. ## Nitro 회원 혜택 - Nitro 회원은 다른 프로필 장식 상품과 마찬가지로 Profile Frames를 할인된 가격에 구매할 수 있습니다. - 여러 개의 프레임을 보유한 경우, Nitro를 통해 서버마다 서로 다른 프레임을 설정할 수 있습니다. ## 지속적으로 추가되는 프레임 - 디스코드는 앞으로 새로운 Profile Frames를 정기적으로 출시할 예정입니다. - 현재 마음에 드는 디자인이 없더라도 향후 추가될 프레임 중에서 원하는 스타일을 찾을 수 있습니다. - 다양한 장식 요소를 조합해 자신의 취향과 관심사를 한눈에 보여주는 프로필을 만들 수 있습니다. 프로필을 적극적으로 꾸미는 사용자라면 Profile Frames를 아바타 장식이나 이름표와 조합해 활용할 수 있습니다. 여러 서버에서 서로 다른 분위기를 연출하고 싶다면 Nitro의 서버별 프레임 설정 기능도 유용합니다.

원문 읽기(새 탭에서 열림)
discordnitroprofile-customizationavatar-decorations+2
gitlab4분 읽기큐레이션 요약

GitLab 패치 릴리스: 19.2.1, 19.1.3, 19.0.5 | GitLab 문서

2026년 7월 29일 GitLab은 CE/EE용 패치 버전 19.2.1, 19.1.3, 19.0.5를 출시했다. 이번 릴리스에는 다수의 보안 취약점과 버그 수정이 포함되어 있어, 영향을 받는 모든 자체 관리형 GitLab 설치 환경은 즉시 업그레이드하는 것이 권장된다. GitLab.com은 이미 패치가 적용됐으며, GitLab Dedicated 고객은 별도 조치가 필요 없다. ## 패치 릴리스와 업그레이드 권고 - 이번 패치 버전: - GitLab 19.2.1 - GitLab 19.1.3 - GitLab 19.0.5 - 대상: - GitLab Community Edition(CE) - GitLab Enterprise Edition(EE) - Omnibus, 소스 설치, Helm Chart 등 모든 배포 방식 - GitLab은 지원 중인 버전에서 최신 패치 릴리스를 유지할 것을 권장한다. - 일반 패치 릴리스는 매월 둘째·넷째 수요일에 제공되며, 심각도가 높은 취약점에는 별도 긴급 패치가 배포될 수 있다. - 보안 취약점의 상세 이슈는 패치된 릴리스 이후 90일이 지나면 공개된다. ## Workhorse 내부 요청 처리의 정보 노출 - **CVE-2026-6267** - 인증된 Developer 권한 사용자가 내부 요청 처리 과정의 접근 제어 미흡을 악용해 권한 없는 정보에 접근할 수 있었다. - CVSS 점수는 **8.5**로, 이번 릴리스에서 가장 심각한 취약점 중 하나다. - GitLab CE/EE의 10.1.0 이후 버전이 영향을 받으며, 19.0.5·19.1.3·19.2.1에서 수정됐다. ## Pipeline Schedule API의 대량 할당 취약점 - **CVE-2026-12436** - 파이프라인 스케줄 입력값 검증이 충분하지 않아, 인증된 사용자가 다른 사용자의 CI/CD 설정을 변경할 수 있었다. - CVSS 점수는 **8.4**다. - GitLab 18.0 이상 버전과 19.x의 이전 패치 버전이 영향을 받는다. ## Merge Request Discussions 기반 서비스 거부 - **CVE-2026-15975** - Merge Request 토론 처리 시 리소스 제한이 부족해, 인증되지 않은 공격자가 서비스 거부(DoS)를 일으킬 수 있었다. - CVSS 점수는 **7.5**다. - 11.8 이후 버전부터 수정 버전 이전의 19.0, 19.1, 19.2 계열이 영향을 받는다. ## Merge Request 승인 규칙 우회 - **CVE-2026-13113** - GitLab EE에서 승인 규칙 처리 중 발생하는 경쟁 조건(race condition)을 통해, 필요한 승인 없이 보호 브랜치에 코드를 병합할 수 있었다. - CVSS 점수는 **6.5**다. - 인증된 사용자가 공격을 수행할 수 있으며, 보호 브랜치와 승인 정책을 사용하는 조직에 특히 중요하다. ## Virtual Registries의 자격 증명 보호 미흡 - **CVE-2026-16553** - Virtual Registry가 업스트림 요청을 처리하는 과정에서 민감한 정보가 의도하지 않은 호스트로 전달될 수 있었다. - GitLab EE 18.8 이상 및 19.x의 이전 패치 버전이 영향을 받는다. - CVSS 점수는 **5.4**다. ## 프로젝트 가져오기 기능의 권한 검증 문제 - **CVE-2026-6336** - 프로젝트 가져오기 상태에서 인증되지 않은 사용자가 프로젝트 소스 정보를 확인할 수 있었다. - CVSS 점수는 **5.3**이다. - **CVE-2026-14341** - Maintainer 권한 사용자가 프로젝트 API의 권한 검증 미흡을 악용해 보호 브랜치 설정을 변경할 수 있었다. - CVSS 점수는 **4.9**다. ## 페이지네이션 화면의 XSS - **CVE-2026-3093** - 사용자 입력값이 충분히 정제되지 않아, 조작된 URL을 통해 다른 사용자의 브라우저에서 임의 JavaScript를 실행할 수 있었다. - CVSS 점수는 **4.7**이다. - 사용자가 악성 링크를 열어야 하는 조건이 포함되지만, 웹 인터페이스를 사용하는 환경에서는 패치가 필요하다. ## GitLab Duo 기능의 권한 우회 - **CVE-2026-15077** - Duo Code Review가 신뢰할 수 없는 콘텐츠를 처리하는 과정에서 프롬프트 인젝션이 발생할 수 있었다. - 공격자가 권한 없는 프로젝트의 정보에 접근할 가능성이 있었다. - GitLab EE 19.1 및 19.2의 초기 버전에 영향을 주며, CVSS 점수는 **4.3**이다. - **CVE-2026-15831** - Duo Workflows의 보안 토큰 생성 과정에서 권한 적용이 잘못되어, 관리자가 설정한 도구 거버넌스 정책을 우회할 수 있었다. - CVSS 점수는 **4.3**이다. ## 권장 대응 - 자체 관리형 GitLab은 사용 중인 메이저 버전에 맞춰 **19.0.5, 19.1.3 또는 19.2.1 이상**으로 즉시 업그레이드한다. - GitLab EE에서 보호 브랜치, Merge Request 승인 규칙, Virtual Registries, Duo 기능을 사용하는 경우 우선적으로 점검한다. - 업그레이드 전 백업과 운영 환경 검증을 수행하되, 보안 패치 적용을 불필요하게 지연하지 않는 것이 좋다.

원문 읽기(새 탭에서 열림)
CI/CDgitlabapi-securityprompt-injection+3
gitlab2분 읽기큐레이션 요약

GitLab은 왜 ‘Open Weights and American AI Leadership’ 서한에 서명했나

GitLab은 고객 선택권, 데이터 프라이버시, AI 모델 중립성을 강화하기 위해 ‘Open Weights and American AI Leadership’ 서한에 서명했다. 오픈 웨이트 모델은 비용·배포 환경·데이터 주권에 대한 통제력을 높이고, AI 안전성과 혁신을 촉진한다고 본다. GitLab은 개방형 모델과 독점 모델을 함께 지원하는 멀티모델·클라우드 중립적 DevSecOps 환경을 지향한다. ## 오픈 웨이트 모델을 지지하는 이유 - 오픈 웨이트 모델은 개발팀이 모델을 직접 선택하고 운영할 수 있게 한다. - 특정 클라우드나 AI 제공업체에 종속되지 않아 고객의 선택권과 협상력을 높인다. - 모델을 직접 배포할 수 있어 비용, 보안, 데이터 저장 위치를 조직의 요구에 맞게 관리할 수 있다. - 필요한 경우 외부 네트워크와 분리된 에어갭 환경에서도 모델을 운영할 수 있다. - 다양한 모델 제공업체가 경쟁하면 혁신과 보안 수준이 향상될 수 있다. ## 파운데이션 모델과 오픈 웨이트 모델의 조합 - 파운데이션 모델은 범용적인 성능과 폭넓은 활용 사례에서 강점을 보인다. - 오픈 웨이트 모델은 다음과 같은 통제력을 제공한다. - 모델 실행 위치 선택 - 비용 최적화 - 데이터 레지던시 관리 - 소스 코드와 전략적 지식재산 보호 - GitLab은 두 유형의 모델 중 하나만 선택하기보다, 업무와 보안 요구에 따라 함께 사용할 수 있어야 한다고 설명한다. ## GitLab의 모델·클라우드 중립 전략 - GitLab은 소프트웨어 개발 생명주기를 조율하는 DevSecOps 플랫폼으로서 팀의 업무 흐름에 여러 AI 모델을 연결한다. - 특정 클라우드나 단일 AI 모델 제공업체에 조직이 묶이지 않도록 하는 것이 핵심이다. - 모델 선택권이 실질적으로 유지되려면 AI 모델 시장 자체가 개방적으로 운영되어야 한다. - 이는 기업이 보안·개인정보·경쟁상의 위협으로부터 코드와 전략적 IP를 보호하는 데 중요하다. ## 개방성과 AI 안전성에 대한 입장 - GitLab은 안전하고 보안이 강화된 AI 생태계 구축에 개방성이 중요한 역할을 한다고 본다. - 오픈 웨이트 모델의 개발·배포·사용을 보장하는 정책을 지지한다. - 다만 모든 모델에 무제한 자유를 부여하기보다 다음과 같은 접근을 제안한다. - 위험 수준에 따른 비례적 안전장치 - 실제 악용 사례를 겨냥한 도구와 규제 - 혁신과 고객 선택권을 과도하게 제한하지 않는 정책 - 개방형 모델과 독점 모델이 성능과 가치로 경쟁하는 환경이 바람직하다고 주장한다. ## 실용적인 시사점 기업은 단일 AI 모델이나 클라우드에 의존하기보다, 업무별로 적합한 모델을 선택하고 보안·비용·데이터 위치를 함께 통제할 수 있는 멀티모델 전략을 검토하는 것이 좋다. GitLab의 서명은 이러한 모델 중립성과 오픈 웨이트 생태계에 대한 지지를 정책적·제품 전략적으로 확인한 것이다.

원문 읽기(새 탭에서 열림)
AIDevSecOpsfoundation-modelsdata-privacy+3
figma4분 읽기큐레이션 요약

에이전트를 활용해 Figma의 내부 시스템을 보호하는 방법 | Figma 블로그

Figma는 SIEM 경보 대응에 AI 에이전트를 도입해 과거 조사 기록 검색, 포렌식 분석, 보안 데이터 질의, 코드 수정과 PR 생성까지 자동화했다. 그 결과 경보의 해결까지 걸리는 시간을 71% 줄였으며, 온콜 엔지니어의 업무를 단순한 정보 수집에서 판단과 검토 중심으로 바꾸었다. 핵심은 기존 업무 흐름을 유지하면서 경보와 조사 지식을 지속적으로 축적·검색하는 시스템을 구축한 것이다. ## 보안 경보 대응의 병목 - Figma의 SIEM인 Panther는 클라우드 인프라, 엔드포인트, SaaS, ID 시스템을 점검한다. - 문제가 감지되면 Slack에 경보를 게시하고 Asana 티켓을 생성한다. - 기존 온콜 엔지니어는 다음 정보를 수동으로 모아야 했다. - 같은 경보가 과거에 발생했는지 - 이전 조사에서 어떤 결론을 내렸는지 - 관련된 Slack 대화가 있는지 - 문제를 해결할 예정인 PR이 존재하는지 - 클라우드 환경과 개발 도구가 빠르게 변하면서 경보의 유형과 대응 방법도 계속 바뀌었다. - 따라서 단순히 경보를 분류하거나 중복 제거하는 것만으로는 업무 부담을 충분히 줄일 수 없었다. ## 검색 시스템에서 에이전트 시스템으로의 확장 - 초기 목표는 새 경보가 발생했을 때 과거 온콜 엔지니어의 판단과 대응 기록을 찾아주는 retrieval layer를 만드는 것이었다. - 이후 시스템은 다음 기능을 수행하는 에이전트 구조로 확장됐다. - 경보 조사 - 보안 데이터 레이크와 감사 로그 질의 - 관련 코드 변경 작성 - PR 생성 - 과거 조사 결과를 기억하고 다음 대응에 활용 - Figma는 코드베이스에서도 에이전트를 활용해 Okta와 AWS 같은 민감한 도구의 설정 변경을 점검하고 있었다. - 그러나 SIEM이 발견하는 광범위한 운영·인프라 문제까지 다루기 위해서는 코드 분석을 넘어선 별도의 시스템이 필요했다. ## RAG 계층: 경보에 기억을 부여하기 - Figma는 AWS Bedrock Knowledge Bases와 Amazon Kendra를 이용해 검색 증강 생성(RAG) 기반의 경보 분류 시스템을 구축했다. - Panther 경보가 발생하면 Lambda 핸들러가 원본 payload를 표준화된 문서로 변환해 Kendra에 색인한다. - 다음과 같은 구조화된 정보를 추출해 검색 속성으로 저장한다. - `p_any_ip_addresses`에서 추출한 IP 주소 - `p_any_usernames` 및 공급자별 사용자 필드의 행위자 정보 - ARN에서 추출한 AWS 계정 ID - 경보 제목, 심각도, 태그, 생성 시각 - 경보 유형, 상태, 조사 맥락의 존재 여부 - 예시 속성에는 `alert_id`, `alert_type`, `severity`, `status`, `created_at`, `has_investigation_context`가 포함된다. ## 의미 검색과 최신성 반영 - 새로운 유사 경보가 발생하면 경보 제목을 주요 검색 벡터로 사용해 Bedrock에 의미 검색을 요청한다. - 검색 질의에는 조사 맥락이 있는 기록만 우선하도록 다음 조건을 추가한다. ```text {경보 제목} has_investigation_context=1 ``` - 경보 제목은 일반적으로 탐지 규칙 이름과 행위자 사용자 이름으로 구성된다. - 단순히 가장 유사한 기록을 찾는 것보다 최근 기록을 우선하도록 검색 결과를 편향시켰다. - 대응 절차와 환경이 계속 변하기 때문에, 6개월 전의 정확히 같은 경보보다 이틀 전에 발생한 유사 경보가 실무적으로 더 유용할 수 있다. - 이를 통해 검색 결과가 현재의 운영 방식과 최신 조사 관행을 더 잘 반영하게 된다. ## Slack 조사 기록의 자동 축적 - `investigation_context`는 온콜 엔지니어가 Slack 경보 스레드에 남긴 조사 결과와 판단을 의미한다. - 조사 내용이 없는 종료 경보는 단순히 “닫혔다”는 사실만 제공하므로 재사용 가치가 낮다. - Figma는 엔지니어가 기존처럼 Slack이나 Asana에 댓글을 남기기만 해도 해당 내용을 자동으로 원래 경보 문서에 추가한다. - 기존 문서의 조사 맥락 배열에 새 댓글을 추가하고, `has_investigation_context` 값을 1로 변경한 뒤 문서를 재색인한다. - 결과적으로 유용한 댓글 하나가 이후 발생하는 모든 유사 경보의 조사 비용을 낮춘다. - 별도의 annotation 도구나 새로운 수동 입력 절차를 요구하지 않고 기존 업무 흐름에서 지식이 축적된다는 점이 중요하다. ## 실용적인 적용 방향 - 처음부터 완전한 자율 에이전트를 만들기보다, 과거 대응 기록을 검색하는 좁은 문제부터 시작하는 것이 현실적이다. - 경보 데이터는 검색 가능한 구조화 필드와 사람이 작성한 조사 맥락을 함께 저장해야 한다. - 최신 대응 기록과 조사 내용이 있는 기록을 우선하는 검색 전략이 필요하다. - 별도의 문서화 작업을 추가하기보다 Slack·티켓 시스템의 기존 댓글을 자동으로 지식화하는 방식이 도입 장벽을 낮춘다. - AI가 분석과 코드 변경을 수행하더라도 PR 검토와 최종 판단은 보안 엔지니어가 맡는 구조가 효과적이다.

원문 읽기(새 탭에서 열림)
AI 에이전트TypeScriptRAGaws-lambda+4
github3분 읽기큐레이션 요약

npm 및 GitHub Actions의 공급망 공격 교란

npm과 GitHub Actions를 겨냥한 공급망 공격은 계정 탈취, CI/CD 취약점 악용, 자격 증명 탈취, 악성 패키지 확산을 연쇄적으로 결합한다. GitHub는 단일 방어 기능보다 공격 단계별로 핵심 연결고리를 끊는 다층 방어가 필요하다고 보고, npm과 GitHub Actions에 계정 보호·워크플로 권한 제한·캐시 보호·무자격 증명 배포 등의 기능을 도입했다. 목표는 공격을 완전히 제거하기보다 초기 침해와 권한 상승, 자격 증명 유출, 대규모 확산을 차단하고 탐지·대응 시간을 확보하는 것이다. ## 공급망 공격의 구조 - 공격은 대개 다음 단계로 진행된다. - 유지보수자 계정이나 프로젝트의 GitHub Actions 워크플로를 침해한다. - CI/CD 환경에서 더 높은 권한과 자격 증명을 찾는다. - 토큰과 계정 정보를 외부로 유출한다. - 탈취한 자격 증명으로 다른 패키지와 프로젝트를 연쇄적으로 감염시킨다. - 공격 방식은 다양하지만, 초기 침해·권한 상승·확산이라는 공통된 흐름을 가진다. - 따라서 하나의 보안 기능보다 공격 사슬의 영향력이 큰 지점을 여러 단계에서 차단하는 접근이 필요하다. ## 초기 침해 차단 - **고영향 npm 계정 보호** - 이메일 주소를 변경하거나 2FA 복구 코드를 사용한 고영향 npm 계정은 72시간 동안 읽기 전용 상태가 된다. - 피싱으로 계정을 탈취당하더라도 공격자가 즉시 악성 버전을 배포하지 못하게 한다. - 해당 기간 동안 유지보수자가 계정을 복구하거나 이상 행위를 확인할 수 있다. - **`pull_request_target`의 안전한 checkout 기본값** - 포크에서 제출된 풀 리퀘스트의 신뢰할 수 없는 코드를 워크플로가 실행하는 “pwn request” 취약점을 완화한다. - `actions/checkout`은 일반적으로 악용되는 트리거에서 포크의 비신뢰 코드를 checkout하지 않도록 변경됐다. - 관리자가 위험을 검토한 뒤 명시적으로 예외를 선택해야 하며, 기존 버전에도 변경 사항이 백포트됐다. - **워크플로 실행 주체와 트리거 제한** - 엔터프라이즈·조직·저장소 수준에서 누가 워크플로를 실행할 수 있는지 설정할 수 있다. - 허용할 워크플로 트리거 유형도 제한할 수 있다. - 이를 통해 Actions 인프라에 최소 권한 원칙을 적용하고 공격 표면을 줄인다. - **비신뢰 트리거의 Actions 캐시 읽기 전용화** - 공격자가 워크플로 실행 권한을 얻은 뒤 공유 캐시를 오염시켜 더 높은 권한의 워크플로를 공격하는 경로를 차단한다. - 신뢰도가 낮은 워크플로는 다른 워크플로와 공유되는 캐시를 수정할 수 없게 된다. - 결과적으로 릴리스·패키지 배포 워크플로의 고권한 자격 증명 탈취로 이어지는 권한 상승을 어렵게 만든다. ## 자격 증명 탈취와 유출 방지 - **장기 자격 증명 제거** - CI/CD 파이프라인에 저장된 장기 토큰은 공격자가 가장 먼저 노리는 대상이다. - npm Trusted Publishing은 장기 자격 증명 없이 패키지를 배포하도록 해 탈취 가능한 비밀 정보를 줄인다. - CircleCI도 Trusted Publishing 공급자로 추가되어, CircleCI 기반 배포에서도 장기 자격 증명 제거가 가능해졌다. - **Actions 네트워크 방화벽** - 기술 프리뷰 단계의 기능으로, Actions 실행 중 발생하는 모든 외부 네트워크 트래픽을 기록한다. - 악성 코드 다운로드나 새 도메인으로의 자격 증명 유출처럼 비정상적인 통신을 탐지하는 데 활용할 수 있다. - 향후에는 네트워크 외부 연결 제한과 정책 기반 차단을 지원해 유출이 발생하기 전에 공격을 막는 방향으로 확장될 예정이다. ## 악성 패키지 확산 억제 - **npm 단계적 게시(Staged Publishing)** - 패키지 배포 자격 증명만 가지고는 새 버전을 즉시 공개할 수 없도록 한다. - 배포된 패키지는 추가 승인과 npm CLI 또는 npmjs.com에서의 2FA 인증이 완료될 때까지 보류된다. - 선택적으로 활성화할 수 있으며, 자동화·CI/CD 자격 증명과 실제 배포 승인 절차를 분리한다. - 탈취된 배포 자격 증명으로 악성 버전을 대규모 배포하는 공격을 줄인다. ## 실용적인 권장 사항 npm 유지보수자는 고영향 계정 보호, Trusted Publishing, 단계적 게시를 검토하고, GitHub Actions 사용자는 포크 PR 처리 방식과 캐시 공유 구조를 점검하는 것이 좋다. 또한 워크플로 실행 주체를 최소화하고, Actions 네트워크 트래픽을 모니터링하면 자격 증명 유출과 연쇄 확산을 조기에 발견할 가능성을 높일 수 있다.

원문 읽기(새 탭에서 열림)
CI/CDGitHub Actionsnpmsupply-chain-security+3
cloudflare4분 읽기큐레이션 요약

자연재해와 정부 개입: 2026년 2분기 주요 인터넷 장애 사건 분석

인터넷 장애는 자연재해·정전 같은 물리적 사건부터 정부의 의도적 차단, 클라우드 인프라 손상, DNSSEC 설정 오류까지 다양한 원인으로 발생하며, 서로 다른 원인도 사용자에게는 비슷한 “연결 불가”로 나타난다. Cloudflare Radar의 Q2 2026 분석은 이란의 88일 인터넷 차단 종료, 괌 태풍, 수단·이라크의 시험 기간 차단, 독일 `.de` 도메인 장애 등을 통해 인터넷의 취약성과 동시에 높은 복원력을 보여준다. 다만 이 글은 모든 이상 현상이 아니라 확인된 주요 장애 사례를 다룬다. ### 자연재해와 정전이 네트워크에 미친 영향 - **괌의 슈퍼태풍 신라쿠** - 4월 중순 태풍이 괌 북쪽을 지나가며 열대폭풍급 강풍과 광범위한 정전을 일으켰다. - 전력과 수도 시스템이 영향을 받으면서 4월 13~14일 인터넷 트래픽이 예상치보다 최대 80% 감소했다. - 섬이 태풍의 직접적인 타격을 피했음에도 디지털 연결성이 크게 흔들렸다. - **베네수엘라 지진** - 6월 24일 북부 베네수엘라에서 규모 7.5 지진과 추가 지진이 연이어 발생했다. - 지진 발생 시점에 HTTP 전송 바이트가 급격히 감소했으며, Fibex Telecom, CANTV, VNET 등 주요 ISP에서 동일한 현상이 관측됐다. - 특히 약 160만 명의 사용자를 보유한 것으로 추정되는 Fibex Telecom에서 감소가 뚜렷했다. - **탄자니아 정전** - 6월 27일 발생한 정전으로 인터넷 트래픽이 최소 5시간 동안 급락했다. - 원인은 정부의 의도적 차단이 아니라 전력 인프라 장애였지만, 사용자에게 나타난 결과는 통신과 뉴스 접근이 불가능해지는 등 과거의 국가적 차단과 유사했다. - 서로 다른 사건도 데이터상으로는 “트래픽의 급격한 소실”이라는 비슷한 패턴을 남긴다. - 이러한 사례는 전력 공급, 라우팅 경로, 물리적 회선의 중복성을 확보해야 인터넷이 외부 충격을 견딜 수 있음을 보여준다. ### 정부 정책과 지정학적 갈등에 따른 접속 제한 - **이란의 인터넷 복구** - 2월 28일부터 이어진 약 88일간의 전국적 인터넷 차단이 5월 26일부터 점진적으로 해제되기 시작했다. - 5월 27일 트래픽은 차단 전의 약 40%까지 회복됐고, 이후 최대 90%까지 상승한 뒤 약 59% 수준으로 안정됐다. - 완전한 정상화라기보다 최근 차단 이전 수준에 가까운 부분적 복구로 평가된다. - 2026년 월드컵 분석에서도 이란의 트래픽은 경기 일정이 아니라 차단과 복구의 극적인 대비에 의해 좌우됐다. - **중동 분쟁과 AWS 인프라 손상** - UAE의 AWS `me-central-1` 리전 트래픽은 계속 낮은 수준을 유지했다. - 드론 공격으로 UAE와 바레인의 데이터센터 시설이 물리적 피해를 입었고, AWS는 UAE 리전이 고객 애플리케이션을 안정적으로 지원하지 못한다고 밝혔다. - 이는 네트워크 자체의 장애가 아니라 데이터센터 손상이 해당 리전에 호스팅된 웹사이트와 애플리케이션에 영향을 준 사례다. - **시험 기간의 국가 인터넷 차단** - 이라크에서는 6월 2일, 11일, 28일 세 차례 차단이 발생했으며 각각 약 90분간 지속됐다. - 수단에서는 4월 13~23일 사이 열 차례 차단이 시행됐고, 매번 약 3.5시간 동안 이어졌다. - 두 국가 모두 국가시험 부정행위를 막기 위해 시험 시간에 맞춰 접속을 차단했다. - 정부는 국가 인터넷을 완전히 끄거나, 속도를 낮추거나, 일부 사용자에게만 재개하는 등 정책적으로 연결성을 통제할 수 있다. ### DNSSEC 오류로 발생한 독일 `.de` 도메인 장애 - 5월 5일 독일 국가 코드 도메인 `.de`를 관리하는 DENIC의 DNSSEC 키 교체 과정에서 잘못된 서명이 생성됐다. - DNSSEC 검증 리졸버는 서명이 현재 공개된 키와 일치하지 않으면 DNS 응답을 위조나 변조로 간주한다. - 그 결과 전 세계 검증 리졸버가 `.de` 도메인 요청을 거부하고 `SERVFAIL` 오류를 반환했다. - 장애는 5월 6일 23:15 UTC에 정상화됐다. - 장애 중 `.de` 질의량이 오히려 증가했는데, 실패한 응답은 캐시에 저장되지 않아 사용자의 재시도와 반복 조회가 늘어났기 때문이다. - 사용자는 암호화 서명 문제를 직접 인식하기보다 독일 도메인의 웹사이트와 서비스가 갑자기 열리지 않는 현상으로 경험했다. ### 해저 케이블과 지역 인프라의 취약성 - 세인트루시아에서는 해저 케이블 절단이 지역 인터넷 연결을 약화시켰다. - 이 사건은 특정 국가나 지역의 국제 연결이 제한된 수의 물리적 케이블에 의존할 경우, 단일 절단만으로도 사용자 접속이 크게 영향을 받을 수 있음을 보여준다. - DNSSEC 장애와 케이블 절단은 원인은 다르지만, 인터넷 서비스가 정상적으로 보이기 위해서는 암호화 검증 체계와 물리적 전송 경로가 모두 안정적으로 운영되어야 한다는 점을 공통적으로 드러낸다. 인터넷 회복력을 높이려면 전력·라우팅·해저 케이블·데이터센터의 중복성을 확보하고, DNSSEC 키 교체 같은 정기 유지보수에는 철저한 검증 절차를 적용해야 한다. 또한 정부와 사업자가 연결성을 정책적으로 차단할 수 있는 만큼, 장애 원인이 기술적 고장인지 의도적 차단인지 구분해 모니터링하는 것도 중요하다.

원문 읽기(새 탭에서 열림)
AWScloudflare-radardnssecinternet-infrastructure+3
github3분 읽기큐레이션 요약

하네스만 있으면 된다 (대부분)

AI 생산성의 핵심은 새로운 모델·MCP·프롬프트를 끊임없이 추가하는 데 있지 않고, 에이전트 하네스(harness)를 제대로 이해하고 활용하는 데 있다. 글은 GitHub Copilot의 여러 도구에서 공통으로 사용되는 하네스 중심의 단순한 워크플로를 제안하며, 자율 실행 환경에서 먼저 프로토타입을 만들고 요구사항의 복잡성을 조기에 발견하라고 권한다. 다만 자율성을 높일수록 샌드박스 등 안전한 실행 환경을 함께 마련해야 한다. ## 도구보다 하네스 이해하기 - GitHub Copilot CLI, Copilot 앱, VS Code, Visual Studio, JetBrains 등 다양한 도구가 있지만 핵심 상호작용 방식은 점점 비슷해지고 있다. - 하나의 하네스를 익히면 여러 Copilot 환경에서 같은 방식으로 작업할 수 있다. - 처음 시작한다면 UI 요소가 적고 프롬프트와 에이전트 동작에 집중할 수 있는 Copilot CLI가 적합하다. - 중요한 것은 어떤 도구를 선택했는지가 아니라, 에이전트가 작업을 수행하고 파일·명령·결과를 다루는 방식을 이해하는 것이다. ## 자율 실행과 안전한 환경 - `/allow-all` 또는 “Allow All” 설정을 사용하면 에이전트가 매번 사용자의 승인을 기다리지 않고 명령을 실행할 수 있다. - 모든 작업을 일일이 승인하면 생산성 향상이 줄어들고, 사용자가 승인 요청을 무심코 넘기게 될 위험도 있다. - 에이전트의 자율성은 생산성에 중요하지만, 잘못된 명령 실행이나 데이터 손실 같은 위험이 있다. - 특히 회사의 private 데이터가 있는 로컬 환경에서 YOLO 모드를 사용하는 것은 위험하다. - GitHub Codespaces나 개발 컨테이너처럼 격리된 샌드박스 환경에서 실행하는 것이 안전하다. ## 구현 전에 여러 프로토타입 만들기 - AI를 이용하면 과거에는 별도 프로젝트 단계였던 프로토타이핑을 짧은 프롬프트만으로 수행할 수 있다. - 예를 들어 날짜 선택기라면 다음과 같이 여러 시안을 한 번에 생성할 수 있다. ```text Give me 20 mocks for a date picker web component. Put them all in an HTML file so I can compare. ``` - 여러 레이아웃을 비교하면 연·월·일을 단계적으로 확대하는 방식처럼 처음에는 생각하지 못했던 상호작용을 발견할 수 있다. - 이미지, 도형, 레이아웃 같은 시각적 결과물은 복잡한 요구사항을 긴 텍스트보다 빠르게 이해하게 해준다. - 시각적 프로토타이핑은 UI뿐 아니라 API 설계에도 적용할 수 있다. - 예를 들어 분석 데이터 다운로드 API에 대해 여러 구현 방식을 Mermaid 다이어그램으로 비교하면 요구사항과 제약을 조기에 파악할 수 있다. - 프로토타입은 에이전트 작업의 숨은 복잡성을 드러내며, 구현 후 재작업에 드는 시간과 토큰을 줄여준다. ## 모델과 대화 흐름 유지 - 대부분의 작업에는 중간 크기의 모델과 중간 수준의 reasoning을 사용하는 것이 적절하다고 제안한다. - 하나의 기능·버그·개선 작업을 진행하는 동안 모델과 reasoning 수준을 가급적 바꾸지 않는 것이 좋다. - 같은 모델과 설정을 유지하면 이전 대화가 캐시되어 후속 요청의 토큰 비용을 줄일 수 있다. - 모델을 자주 바꾸기보다 일관된 컨텍스트를 유지하는 것이 작업 효율에 유리하다. ## 실용적인 적용 순서 - Copilot CLI 등 하네스에 가까운 도구로 에이전트의 기본 동작을 익힌다. - 실제 로컬 시스템 대신 Codespaces나 개발 컨테이너에서 자율 실행을 활성화한다. - 구현 전에 HTML 목업, 다이어그램 등 여러 프로토타입을 생성한다. - 선택한 모델과 reasoning 설정을 작업 끝까지 유지한다. - 프로토타입으로 요구사항을 구체화한 뒤 계획과 구현 단계로 넘어간다. 어진 글의 본문은 “계획 수립” 섹션 초입에서 끝나므로, 이후 계획·구현 단계의 구체적인 내용은 제공된 자료만으로 확인할 수 없다.

원문 읽기(새 탭에서 열림)
AI 에이전트github-copilotgithub-codespacesdevelopment-containers+2