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

figma4분 읽기큐레이션 요약

Figma Make에서 더 많은 맥락과 제어력으로 빌드하기 | Figma Blog

Figma Make가 **Make kits**와 **Make attachments**를 통해 디자인 시스템과 실제 프로젝트 자료를 반영한 프로토타입을 생성하도록 개선됐다. Make kits는 코드 패키지나 Figma 라이브러리의 컴포넌트·스타일·토큰과 사용 지침을 제공하고, attachments는 데이터·법률 문구·스크린샷 등 프로젝트별 맥락을 전달한다. 이를 통해 범용적인 초안에서 출발해 반복적으로 수정하는 대신, 실제 제품 구조와 제약에 가까운 결과물을 더 빠르게 만들 수 있다. ## AI 초안이 실제 제품과 어긋나는 문제 - 기존 AI 생성 UI는 레이아웃과 인터랙션은 그럴듯하지만 다음과 같은 문제가 있었다. - 팀의 실제 디자인 시스템 컴포넌트를 사용하지 않음 - 카피가 placeholder로 남음 - 예외 상황과 중요한 edge case가 반영되지 않음 - 프로덕션 코드의 구조와 다른 방식으로 구현됨 - 그 결과 초기 생성 속도는 빨라도, 리뷰 전에 디자인 시스템에 맞게 다시 작성하고 조정하는 데 많은 시간이 필요했다. - Figma는 이 문제의 원인을 생성 품질 자체가 아니라 **팀이 실제 개발에 사용하는 맥락의 부족**으로 설명한다. ## Make kits: 디자인 시스템을 학습시키는 패키지 - Make kit은 디자인 시스템의 컴포넌트나 스타일과, 이를 어떻게 사용해야 하는지 설명하는 세부 가이드라인을 하나의 재사용 가능한 패키지로 결합한다. - 다음과 같은 소스를 사용할 수 있다. - 공개 npm 레지스트리의 JavaScript 패키지 - Figma의 보안 비공개 레지스트리에 저장된 코드 패키지 - Figma 라이브러리의 스타일과 디자인 토큰 - 가이드라인은 단순히 “어떤 컴포넌트가 존재하는가”뿐 아니라 다음까지 전달한다. - 컴포넌트를 어떤 상황에 사용해야 하는지 - 컴포넌트가 어떤 구조와 패턴을 따라야 하는지 - 디자인 시스템의 규칙을 프로토타입에 어떻게 적용해야 하는지 - 따라서 Make는 일반적인 UI 요소를 조합하는 대신, 팀의 코드베이스와 가까운 구조로 프로토타입을 시작할 수 있다. ## Make kits가 팀 협업에 주는 효과 - 폼, 대시보드, 설정 화면, 온보딩 플로우 등 여러 팀이 공유하는 화면에서 일관성이 높아진다. - 여러 팀이 동시에 프로토타입을 제작해도 디자인 시스템에서 벗어날 가능성이 줄어든다. - 리뷰 전에 spacing, 컴포넌트 선택, UI 패턴을 다시 맞추는 작업이 감소한다. - 엔지니어 입장에서는 익숙한 컴포넌트와 코드 패턴을 바로 확인할 수 있다. - “이 부분은 커스텀 구현인가?”와 같은 확인 질문이 줄어들어, 디자인을 코드로 번역하는 시간보다 제안 자체를 검토하고 개선하는 데 집중할 수 있다. - Figma는 향후 Figma 라이브러리의 컴포넌트 구조를 더욱 정확히 재현하는 방향으로 Make kits를 발전시킬 계획이다. ## Make attachments: 프로젝트의 실제 맥락 반영 - 디자인 시스템만으로는 각 프로젝트의 고유한 요구사항을 모두 설명할 수 없다. - 실제 프로젝트에는 다음과 같은 정보가 추가로 필요하다. - 실제 사용자 데이터 - 마이그레이션 제약 - 예외 처리와 edge case - 규정 및 컴플라이언스 요구사항 - 브랜드 콘텐츠와 법률 문구 - Make attachments는 이런 자료를 긴 프롬프트로 요약하지 않고 원본 파일 형태로 Make에 전달한다. - 지원되는 자료에는 다음이 포함된다. - PDF와 Markdown 문서 - CSV·JSON 데이터셋 - 스크린샷과 이미지 - 브랜드 가이드라인 - 법률 문구 - 미디어 파일과 SVG - 코드 및 관련 프로젝트 파일 ## 실제 데이터와 제약을 반영하는 프로토타이핑 - 예를 들어 디지털 제품의 전체 온보딩 플로우를 만들 때는 다음 정보가 동시에 필요할 수 있다. - 실제 사용자 데이터 - 법률상 반드시 표시해야 하는 문구 - 여러 입력 검증 상태 - 정상 흐름 외의 예외 상황 - 첨부 파일 없이 프롬프트만 사용하면 Make가 법률 문구를 임의로 줄이거나, 검증 상태를 단순화하거나, 이상적인 정상 흐름만 생성할 수 있다. - 원본 PDF, 데이터셋, 스크린샷 등을 첨부하면 Make가 프로젝트 자료를 직접 참조하므로, 보다 현실적인 콘텐츠와 제약을 포함한 프로토타입을 만들 수 있다. ## 디자인 시스템과 프로젝트 자료의 결합 - Make kits는 **제품 전반에 공통으로 적용되는 규칙**을 제공한다. - Make attachments는 **특정 프로젝트에만 존재하는 데이터와 제약**을 제공한다. - 두 기능을 함께 사용하면 다음과 같은 흐름이 가능하다. - Make kits로 실제 코드 또는 Figma 라이브러리 기반의 컴포넌트 사용 - attachments로 실제 데이터, 콘텐츠, 법률 요구사항, 시각 자료 반영 - 생성 결과를 프로덕션 구조에 가깝게 유지하면서 프로젝트의 세부 조건까지 검증 - 결과적으로 프로토타입 제작은 “일반적인 UI 초안 생성”에서 “실제 제품 조건을 반영한 탐색과 검증”으로 이동한다. 실무에서는 공통 컴포넌트와 토큰을 Make kit으로 정리하고, 기능별 요구사항·데이터·법률 문구·예외 상태는 attachments로 함께 제공하는 방식이 효과적이다. 이렇게 하면 생성 후 대규모 수정에 쓰는 시간을 줄이고, 초기 단계부터 개발·디자인 리뷰에 적합한 프로토타입을 만들 수 있다.

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

호평받은 AAAA 게임 ‘더 라스트 메도우’의 멀티플레이어 후속작 발표: 지금 플레이 가능

Discord의 자체 게임 스튜디오 Big Wump Games가 **「Last Meadow Online」**을 발표했다. 이 게임은 디스코드 안에서 여러 이용자가 협력해 ‘Grass Toucher’라는 용을 물리치는 온라인 RPG이며, 데스크톱 디스코드에서 바로 플레이할 수 있도록 구성됐다. 게임은 한정 기간 동안 제공되고, 참여자에게는 프로필 배지가 보상으로 지급된다. ## 후속작의 세계관과 위협 - 전작에서 Wumpus는 숲, 사막, 평원을 지나 마침내 ‘The Last Meadow’와 접촉하는 데 성공한다. - 마을로 돌아와 축하하려는 순간, 초목을 흡수하는 용 **Grass Toucher**가 등장한다. - 이번에는 Wumpus 혼자 해결할 수 없기 때문에 여러 플레이어의 협력이 필요하다는 설정이다. ## 디스코드 기반 멀티플레이 게임 - **Last Meadow Online**은 디스코드 데스크톱에서 직접 실행된다. - 전 세계 디스코드 이용자들과 함께 게임에 참여하고 목표를 공동으로 달성하는 방식이다. - 개발진은 이를 “Discord-Based Massively Multiplayer Incremental Role Playing Game(DBMMIRPG)”라고 표현한다. - 플레이어는 다음과 같은 역할을 선택할 수 있다. - 빛의 힘을 사용하는 **팔라딘** - 원거리 공격에 강한 **레인저** - 치유 능력을 가진 **프리스트** - 제작과 작업을 담당하는 장인형 역할 ## 기간 한정 플레이와 보상 - 글에서는 게임 전체를 발표 시점부터 즉시 플레이할 수 있다고 안내한다. - Grass Toucher를 물리치는 데 기여한 모든 플레이어에게 **디스코드 프로필용 한정 배지**를 지급한다. - 플레이 가능 기간은 **4월 7일까지**로 제한되어 있다. - 이용자들에게 친구를 초대해 함께 참여하도록 권장한다. ## 발표 성격과 날짜 관련 참고 - 글의 게시일은 **2026년 4월 1일**로 표시되어 있어 만우절 발표 형식의 콘텐츠로 보인다. - 하단 스튜디오 설명에는 전작 「The Last Meadow」가 2025년 4월 1일부터 4월 7일까지 공개됐다고 적혀 있다. - 따라서 실제 상시 서비스라기보다 디스코드 이용자를 대상으로 한 기간 한정 이벤트성 게임에 가깝다. 관심이 있다면 안내된 디스코드 링크에서 기간 내 게임에 참여하고, 협력 플레이와 한정 프로필 배지를 함께 노려볼 만하다.

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

Amazon ECS 관리형 인스턴스를 위한 관리형 데몬 지원 발표 | Amazon Web Services (새 탭에서 열림)

Amazon ECS가 관리형 인스턴스(Managed Instances)에서 독립적인 에이전트 관리가 가능한 '관리형 데몬' 기능을 출시했습니다. 이제 플랫폼 엔지니어는 애플리케이션 팀의 배포 주기와 무관하게 모니터링, 로깅, 트레이싱 도구를 중앙에서 제어하고 업데이트할 수 있습니다. 이 기능은 데몬이 애플리케이션보다 먼저 시작되고 나중에 종료되도록 보장하여, 가시성의 공백 없는 안정적인 운영 환경을 제공합니다. ### 운영 효율성을 높이는 생명주기 분리 * 플랫폼 팀이 모니터링 및 로깅 에이전트를 애플리케이션 작업과 분리하여 독립적으로 배포, 업데이트 및 수정할 수 있습니다. * 에이전트 업데이트 시 애플리케이션 작업 정의(Task Definition)를 수정하거나 서비스를 재배포할 필요가 없어 운영팀 간의 조율 부담이 사라집니다. * '선 실행 후 종료(Start before stop)' 메커니즘을 통해 모든 인스턴스에서 애플리케이션이 실행되기 전 데몬이 먼저 활성화되도록 보장합니다. ### 유연한 자원 할당 및 배포 제어 * 특정 용량 공급자(Capacity Provider)를 대상으로 데몬을 배포할 수 있어 인프라 전반에 걸친 유연한 롤아웃이 가능합니다. * 데몬 전용 작업 정의를 통해 CPU 및 메모리 파라미터를 별도로 관리하며, 인스턴스당 단 하나의 데몬만 실행되어 시스템 자원 활용을 최적화합니다. * 배포 시 ECS가 인스턴스 교체 및 작업 마이그레이션을 자동으로 수행하며, 자동 롤백 기능을 통해 업데이트 중 발생할 수 있는 리스크를 최소화합니다. ### 심층적인 호스트 접근과 네트워킹 기술 * 새로운 `daemon_bridge` 네트워크 모드를 도입하여 애플리케이션 네트워크 구성과 격리된 상태에서 데몬과 작업 간의 통신을 지원합니다. * 권한 부여된 컨테이너(Privileged container), Linux 기능(Capabilities) 추가, 호스트 파일 시스템 경로 마운트 등 강력한 호스트 수준 접근 권한을 제공합니다. * 이러한 심층 접근 권한은 시스템 호출 모니터링이나 보안 검사 등 호스트 레벨의 세밀한 가시성이 필요한 도구 운영에 필수적입니다. 관리형 데몬 서비스는 추가 비용 없이 사용한 컴퓨팅 자원에 대해서만 요금이 부과됩니다. CloudWatch 에이전트나 타사 보안 솔루션을 운영하는 플랫폼 팀은 애플리케이션 가용성에 영향을 주지 않으면서 운영 도구를 최신 상태로 유지하기 위해 이 기능을 즉시 도입하는 것을 권장합니다.

github4분 읽기큐레이션 요약

GitHub 전반의 오픈 소스 공급망 보안 강화

공격자들은 GitHub Actions 워크플로를 침해해 API 키 같은 비밀을 탈취한 뒤, 악성 패키지를 배포하고 더 많은 프로젝트로 공격을 확산시키고 있다. 이에 대응하려면 Actions 워크플로를 CodeQL로 점검하고, 서드파티 액션을 커밋 SHA로 고정하며, 장기 비밀 대신 OIDC 기반 인증과 trusted publishing을 사용해야 한다. GitHub는 npm 악성코드 탐지와 Actions·npm 보안 로드맵을 강화하고 있지만, 오픈소스 생태계 전반의 지속적인 협력이 필요하다고 강조한다. ## GitHub Actions 워크플로가 공격의 출발점 - 최근 오픈소스 공급망 공격은 GitHub Actions 워크플로의 취약점을 찾는 방식으로 시작되는 경우가 많다. - 공격자는 워크플로에서 API 키, 토큰, 배포 자격 증명 등의 비밀을 탈취한다. - 탈취한 자격 증명으로: - 공격자가 통제하는 환경에서 악성 패키지를 배포하고 - 해당 패키지를 이용해 다른 프로젝트와 계정으로 공격을 확산한다. ## 지금 적용할 수 있는 Actions 보안 조치 - 공개 저장소에서 무료로 사용할 수 있는 **CodeQL의 GitHub Actions 분석 기능**을 활성화한다. - 워크플로 구현상의 보안 취약점과 보안 모범 사례 위반을 점검할 수 있다. - `pull_request_target`을 사용하지 않는다. - 외부 기여자의 코드가 높은 권한의 워크플로 컨텍스트에서 실행될 위험이 있다. - 서드파티 GitHub Actions를 전체 길이의 커밋 SHA로 고정한다. - 태그나 브랜치는 이후 다른 코드로 변경될 수 있지만, SHA 고정은 특정 코드 버전을 보장한다. - 이 변경은 저장소 관리자나 Dependabot이 수행해야 하며, 외부 Pull Request가 액션 버전 고정을 바꾸려 하면 주의해야 한다. - 사용자 입력을 셸 명령이나 스크립트에 직접 삽입하지 않는다. - 이 방식은 스크립트 인젝션으로 이어질 수 있다. - 침해된 의존성은 GitHub Advisory Database에서 확인한다. - Dependabot을 사용해 악성 또는 취약한 의존성에 대한 알림을 받는다. ## 비밀 대신 OIDC와 trusted publishing 사용 - 워크플로에 장기 보관되는 비밀을 넣는 대신, **OpenID Connect(OIDC) 토큰**을 사용할 수 있다. - OIDC 토큰에는 실행 중인 워크로드의 신원이 포함되므로, 클라우드 제공업체·패키지 저장소·호스팅 서비스가 해당 워크플로를 검증하고 권한을 부여할 수 있다. - GitHub와 OpenSSF는 이를 패키지 저장소의 **trusted publishing**으로 확산하고 있다. - 현재 npm, PyPI, NuGet, RubyGems, Crates 등 여러 저장소에서 지원된다. - trusted publishing의 장점: - 빌드 파이프라인에서 장기 비밀을 제거한다. - 패키지가 어떤 신뢰된 워크플로에서 배포됐는지 확인할 수 있다. - 패키지가 갑자기 trusted publishing을 중단하면, 탈취된 자격 증명을 이용한 공격 가능성을 조사하는 신호가 된다. ## npm의 악성 패키지 탐지 - npm에서는 매일 3만 개가 넘는 패키지가 배포된다. - GitHub는 모든 npm 패키지 버전을 악성코드 관점에서 검사한다. - 탐지 규칙은 공격 방식의 변화에 맞춰 지속적으로 개선된다. - 매일 수백 개의 신규 배포 패키지에서 악성 코드가 발견될 수 있으며, 실제 조치 전에는 사람이 양성 여부를 검토한다. - 오탐률이 1%만 되어도 매일 수백 개의 정상 패키지 배포가 중단될 수 있으므로, 자동 탐지와 사람의 검증 사이 균형이 중요하다. ## Shai-Hulud 이후의 보안 로드맵 - 2025년 말 발생한 Shai-Hulud 공격은 npm 보안 로드맵을 재정비하는 계기가 됐다. - GitHub는 다음 작업을 가속했다. - npm trusted publishing 확대 - 악성코드 탐지 및 제거 기능 강화 - 오픈소스 유지관리자와의 보안 요구사항 논의 - 보안 변경은 기존 워크플로를 수정하게 만들거나 하위 호환성을 깨뜨릴 수 있으므로, GitHub는 생태계가 원활하게 전환할 수 있도록 지원할 계획이다. - 최근 공격을 계기로 GitHub Actions 보안 로드맵도 재검토하고, 이미 진행 중인 보안 기능의 출시를 앞당기고 있다. ## 오픈소스 생태계의 공동 대응 - 오픈소스는 전 세계가 공유하는 공공재인 만큼 공격이 앞으로도 계속될 가능성이 높다. - GitHub는 npm과 GitHub Actions를 비롯해 향후 등장할 새로운 공격 경로까지 방어 범위를 확대하겠다고 밝혔다. - 효과적인 보안 기능을 만들기 위해 유지관리자와 커뮤니티의 피드백이 중요하다. 실무적으로는 먼저 CodeQL로 Actions를 검사하고, `pull_request_target` 제거·커밋 SHA 고정·스크립트 인젝션 점검을 진행하는 것이 좋다. 이후 가능하면 OIDC와 trusted publishing으로 배포 인증을 전환해, 탈취 가능한 장기 비밀 자체를 줄여야 한다.

원문 읽기(새 탭에서 열림)
github4분 읽기큐레이션 요약

Copilot CLI에서 /fleet으로 여러 에이전트 동시에 실행하기

Copilot CLI의 `/fleet`는 하나의 작업을 여러 독립적인 하위 작업으로 나누고, 여러 에이전트를 병렬 실행하는 기능이다. 오케스트레이터가 작업의 의존성을 분석해 실행 순서를 정하고, 결과를 검증·통합하므로 여러 파일이나 모듈을 동시에 처리할 수 있다. 다만 에이전트들이 동일한 파일을 수정하면 잠금이나 자동 병합 없이 마지막 변경이 덮어쓰므로, 작업 범위와 파일 경계를 명확히 지정해야 한다. ## `/fleet`의 작동 방식 - 사용자가 `/fleet <작업 목표>` 형식으로 목표를 전달한다. - 오케스트레이터가 목표를 독립적인 작업 단위로 분해한다. - 작업 간 의존성을 분석해 병렬 실행 가능한 항목과 순차 실행해야 하는 항목을 구분한다. - 독립적인 작업은 백그라운드 하위 에이전트에 동시에 배정한다. - 작업 완료를 확인한 뒤 다음 의존 작업을 실행한다. - 각 결과를 검증하고 최종 산출물로 통합한다. - 하위 에이전트는 각자의 컨텍스트 창을 사용하지만 동일한 파일 시스템을 공유하며, 서로 직접 대화하지 않고 오케스트레이터를 통해 조정된다. ## 시작 방법 - 대화형 CLI에서는 다음과 같이 실행한다. ```text /fleet Refactor the auth module, update tests, and fix the related docs in the folder docs/auth/ ``` - 터미널에서 비대화형으로 실행할 수도 있다. ```bash copilot -p "/fleet <YOUR TASK>" --no-ask-user ``` - `--no-ask-user`는 사용자가 추가 질문에 응답할 수 없는 비대화형 환경에서 필요하다. ## 병렬화에 적합한 프롬프트 작성 - 작업마다 구체적인 산출물을 지정해야 한다. - 파일 - 테스트 스위트 - 문서 페이지 - 특정 모듈 - “문서를 작성하라”처럼 모호한 요청은 독립 작업을 식별하기 어려워 순차 실행될 가능성이 높다. - 예를 들어 인증, 엔드포인트, 오류 문서를 각각 별도 파일로 지정하면 세 작업은 병렬 처리할 수 있다. - 여러 문서를 연결하는 `docs/index.md`처럼 다른 결과물에 의존하는 작업은 후속 단계로 명시해야 한다. ## 파일 범위와 제약 조건 지정 프롬프트에는 각 에이전트가 담당할 범위를 명확히 적어야 한다. - 담당 디렉터리나 파일을 지정한다. - 수정해서는 안 되는 영역을 명시한다. - 테스트 변경 금지 - 의존성 업그레이드 금지 - 지정 디렉터리 외 수정 금지 - 완료 조건을 제시한다. - 린트 통과 - 타입 검사 통과 - 특정 테스트 통과 - API, UI, 설정처럼 서로 다른 영역을 별도 트랙으로 나누면 병렬 실행 효과가 커진다. ## 작업 의존성 선언 - 한 작업이 다른 작업의 결과를 필요로 하면 프롬프트에 `depends on` 관계를 명시한다. - 예를 들어 다음과 같이 데이터베이스 마이그레이션, ORM 모델, API 핸들러, 통합 테스트의 순서를 지정할 수 있다. - ORM 모델이 완성된 뒤 API 핸들러와 통합 테스트를 동시에 실행하도록 구성할 수 있다. - 의존성을 명시하지 않으면 에이전트가 충돌하거나 불완전한 결과를 바탕으로 작업할 수 있다. ## 사용자 지정 에이전트 활용 - `.github/agents/`에 전문 에이전트 설정 파일을 만들 수 있다. - 에이전트마다 다음을 지정할 수 있다. - 모델 - 사용 가능한 도구 - 역할과 작업 지침 - 문서 작성에는 `technical-writer` 같은 전문 에이전트를 사용하고, 코드 변경에는 기본 에이전트를 사용하는 식으로 역할을 나눌 수 있다. - 모델을 별도로 지정하지 않으면 현재 기본 모델이 사용된다. ## 병렬 실행 여부 확인 - 오케스트레이터가 작업을 여러 트랙으로 분해했는지 계획을 먼저 확인한다. - `/tasks` 명령으로 백그라운드 작업 목록과 진행 상태를 볼 수 있다. - 여러 트랙에서 동시에 진행 상황이 보고되는지 확인한다. - 병렬화되지 않는다면 다음처럼 먼저 분해하도록 요청할 수 있다. ```text Decompose this into independent tracks first, then execute tracks in parallel. Report each track separately with status and blockers. ``` ## 주요 주의점 - 하위 에이전트는 파일 잠금 기능 없이 동일한 파일 시스템을 공유한다. - 두 에이전트가 같은 파일을 수정하면 오류나 자동 병합 없이 마지막 완료 결과가 앞선 변경을 덮어쓸 수 있다. - 따라서 각 에이전트에 서로 다른 파일을 배정해야 한다. - 하나의 파일에 여러 에이전트가 기여해야 한다면: - 각자 임시 파일에 작성한 뒤 오케스트레이터가 병합하게 하거나 - 에이전트 실행 순서를 명시해야 한다. - 하위 에이전트는 오케스트레이터와의 이전 대화 기록을 볼 수 없으므로, 전달되는 프롬프트만으로 작업할 수 있도록 지침과 제약 조건을 self-contained하게 작성해야 한다. 실제로 `/fleet`를 사용할 때는 먼저 작업을 파일·모듈 단위로 분리하고, 의존성과 검증 조건을 프롬프트에 명시하는 것이 좋다. 특히 공유 파일을 여러 에이전트가 수정하지 않도록 범위를 엄격히 나누면 병렬 처리의 속도 이점과 결과 안정성을 함께 얻을 수 있다.

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

1.1.1.1 공개 DNS 리졸버를 위한 지속적인 개인정보 보호 약속 (새 탭에서 열림)

Cloudflare는 1.1.1.1 공용 DNS 리졸버 출시 8주년을 맞아 독립적인 외부 기관을 통해 실시한 개인정보 보호 실사 결과를 발표했습니다. 이번 검토를 통해 사용자 데이터를 제3자에게 판매하지 않고 소스 IP 주소를 25시간 내에 삭제한다는 핵심 원칙이 여전히 철저히 준수되고 있음을 재확인했습니다. 기술적 환경 변화 속에서도 투명성을 유지함으로써 사용자 신뢰를 강화하고 업계의 개인정보 보호 표준을 선도하겠다는 의지를 보여줍니다. **독립적 검토를 통한 신뢰성 확보** - 2020년 첫 실사 이후 기술 스택의 규모와 복잡성이 증가함에 따라, Big 4 회계법인을 통해 시스템 전반에 대한 두 번째 독립 검토를 완료했습니다. - 단순한 선언을 넘어 외부 전문가의 객관적인 검증을 통해 1.1.1.1의 개인정보 보호 제어 장치가 실제 운영 환경에서 약속대로 작동하고 있음을 입증했습니다. - DNS 쿼리 데이터를 다른 Cloudflare 데이터나 제3자 데이터와 결합하여 개별 사용자를 식별하지 않는다는 약속을 기술적으로 뒷받침하고 있습니다. **핵심 개인정보 보호 원칙의 재확인** - **데이터 판매 및 공유 금지**: 사용자의 개인정보를 제3자에게 판매하거나 공유하지 않으며, 광고 타겟팅 목적으로 데이터를 활용하지 않습니다. - **최소 정보 원칙**: 요청 내용(What)만 처리하며, 요청자가 누구인지(Who) 식별할 수 있는 정보는 보관하거나 사용하지 않습니다. - **신속한 데이터 삭제**: 사용자의 소스 IP 주소는 익명화 처리를 거친 후 25시간 이내에 시스템에서 영구적으로 삭제됩니다. **운영의 투명성과 기술적 예외 사항** - **네트워크 문제 해결**: 전체 트래픽의 최대 0.05%에 해당하는 무작위 샘플링 패킷은 네트워크 트러블슈팅 및 공격 방어 목적으로만 제한적으로 사용됩니다. - **익명화 데이터 활용**: Cloudflare Radar와 같은 연구 및 분석 서비스를 위해 익명화된 로그 데이터를 활용하지만, 이는 개인 식별이 불가능한 구조 내에서 이루어집니다. - **범위의 집중**: 이번 조사는 개인정보 보호 약속에 초점을 맞추어 진행되었으며, 기술적 변화 속에서도 개인의 프라이버시에 영향이 없음을 확인했습니다. 인터넷 사용자의 활동이 추적되지 않아야 한다는 철학 아래, Cloudflare는 기술적·제도적 장치를 통해 1.1.1.1 리졸버의 안전성을 지속적으로 증명하고 있습니다. 개인정보 보호와 속도를 동시에 확보하고자 하는 사용자라면, 독립적인 검증을 마친 1.1.1.1 DNS를 기본 리졸버로 설정하여 사용하는 것을 추천합니다.

cloudflare원문

EmDash를 소개합니다 — 플러그인 보안 문제를 해결한 워드프레스의 정신적 후속작 (새 탭에서 열림)

EmDash는 24년 된 워드프레스(WordPress)의 구조적 한계를 극복하고 현대적인 웹 환경에 최적화하기 위해 등장한 오픈소스 CMS입니다. 기존 워드프레스의 가장 큰 취약점인 플러그인 보안 문제를 '다이나믹 워커(Dynamic Worker)'를 통한 샌드박스 격리 방식으로 해결했으며, TypeScript와 Astro 프레임워크를 기반으로 설계되었습니다. 이를 통해 서버리스 환경에서 안전하고 빠른 성능을 보장하며, MIT 라이선스를 채택해 개발자들에게 더 높은 자유도를 제공하는 것을 목표로 합니다. ### 워드프레스의 유산과 현대적 재구성 * **전통의 계승과 한계:** 워드프레스는 인터넷의 40% 이상을 점유하며 출판의 민주화를 이루었으나, AWS EC2조차 없던 시절에 설계되어 현대의 서버리스 및 글로벌 분산 네트워크 환경을 충분히 활용하지 못하고 있습니다. * **현대적 기술 스택:** EmDash는 전체 코드가 TypeScript로 작성되었으며, 콘텐츠 기반 웹사이트에 최적화된 프레임워크인 Astro를 기반으로 구동됩니다. * **서버리스 최적화:** 가상 프라이빗 서버(VPS)에 의존하던 방식에서 벗어나, Cloudflare와 같은 서버리스 플랫폼이나 Node.js 환경 어디서든 유연하게 배포할 수 있습니다. * **완전한 오픈소스:** 워드프레스의 코드를 전혀 사용하지 않고 밑바닥부터 새로 작성하여, GPL보다 허용 범위가 넓은 MIT 라이선스를 적용해 생태계 참여를 독려합니다. ### 플러그인 보안 위기의 근본적 해결 * **직접 접근의 위험성 제거:** 워드프레스 취약점의 96%는 플러그인에서 발생하며, 이는 PHP 스크립트가 데이터베이스와 파일 시스템에 직접 접근할 수 있는 구조 때문입니다. * **다이나믹 워커(Dynamic Worker) 격리:** EmDash는 각 플러그인을 독립된 샌드박스(Isolate)에서 실행합니다. 플러그인은 핵심 시스템에 직접 접근할 수 없으며 선언된 범위 내에서만 작동합니다. * **역량 기반 권한 모델 (Capability-based Model):** 플러그인은 매니페스트 파일에 필요한 권한(예: `read:content`, `email:send`)을 명시적으로 선언해야 합니다. 관리자는 설치 전 플러그인이 어떤 권한을 요구하는지 OAuth 승인 과정처럼 명확히 확인할 수 있습니다. * **네트워크 제어:** 플러그인은 외부 네트워크 접근이 기본적으로 차단되며, 필요한 경우 특정 호스트네임에 대해서만 접근 권한을 정적으로 부여받아 실행됩니다. ### 시장 종속성 탈피와 개발자 생태계 혁신 * **신뢰 구조의 변화:** 기존 워드프레스는 보안 위험 때문에 마켓플레이스의 수동 검토와 평판에 의존해야 했으나, EmDash는 기술적 격리를 통해 코드 수준에서 신뢰를 보장합니다. * **비즈니스 유연성:** 보안 이슈로 인해 강제되었던 마켓플레이스 종속성과 라이선스 제약에서 벗어나, 개발자들이 자신의 코드를 더 자유롭게 배포하고 상용화할 수 있는 환경을 제공합니다. * **정적 선언을 통한 자동화:** 플러그인의 권한 요구 사항이 정적으로 정의되어 있어, 관리자는 특정 권한을 요구하는 플러그인의 설치를 그룹별로 제한하는 등 정책 기반의 관리가 가능해집니다. 현재 EmDash는 v0.1.0 프리뷰 버전을 공개하고 초기 개발자 베타를 진행 중입니다. 클라우드플레어 계정이나 Node.js 서버에 직접 배포하여 테스트할 수 있으며, 기존 워드프레스의 운영 편의성은 유지하면서도 최신 보안 표준과 성능이 필요한 프로젝트에 강력한 대안이 될 것으로 보입니다.

line원문

도메인에 의존하지 않는 채팅 플랫폼은 어떻게 만들었을까? (새 탭에서 열림)

MessagingHub는 서비스마다 개별적으로 구축해야 했던 채팅 기능을 통합하여 플랫폼화함으로써 개발 비용을 절감하고 시스템 복잡도를 낮춘 메시징 플랫폼입니다. 특정 도메인에 의존하지 않는 독립성과 범용성을 바탕으로 챗봇, 상담 채팅, 1:1 대화 등 다양한 요구사항을 레고처럼 조합할 수 있는 구조로 설계되었습니다. 결과적으로 연동 서비스는 비즈니스 로직에만 집중하고, 채팅의 핵심 기능과 연결 관리는 플랫폼이 전담하여 효율적인 서비스 운영이 가능해졌습니다. ### 도메인 독립적인 인증 및 사용자 식별 * **연동 측 책임 중심의 인증:** MessagingHub는 직접 사용자를 관리하지 않고, 연동 시스템이 인증을 마친 후 요청한 연결 토큰(connection token)을 검증하여 웹소켓 연결을 허용합니다. * **유연한 사용자 식별:** 도메인 정보와 연동 측 식별자를 조합한 ‘client ID’를 사용해 여러 서비스의 사용자를 구분하며, 닉네임이나 프로필 같은 부가 정보는 연동 측에서 실시간으로 갱신하도록 설계되었습니다. * **서비스 컨텍스트 기반 제어:** '누가 누구와 대화하는지(Driver2CS 등)'를 정의하는 서비스 컨텍스트와 채팅방 유형(1:1, 그룹, 챗봇 등)의 조합을 통해 세밀한 접근 권한과 메시지 허용 정책을 관리합니다. ### 관심사 분리를 통한 모듈형 아키텍처 * **컴포넌트 기반 구조:** 연결 관리(connection-manager), 비즈니스 로직(chat-app), 메시지 중계(message-router), 알림(notification-app) 등 각 기능을 독립적인 컴포넌트로 분리하여 R&R을 명확히 했습니다. * **커맨드(Command) 패턴 활용:** 채팅의 모든 동작을 커맨드 단위로 정의하여 챗봇이나 상담 채팅 등 서비스 성격에 맞게 기능을 유연하게 조합하고 확장할 수 있습니다. * **이벤트 기반 연동:** 각 컴포넌트는 이벤트 기반으로 느슨하게 결합되어 있어, 특정 기능의 변경이 전체 시스템에 미치는 영향을 최소화했습니다. ### 효율적인 데이터 관리와 메시지 순서 보장 * **메시지 체이닝 및 상태 관리:** `prev_chat_log_id`를 사용하여 메시지 간 순서를 보장하며, 읽음 위치(`last_seen_chat_log_id`)와 전체 메시지 범위를 비교하여 정확한 안 읽은 메시지 수를 산출합니다. * **JSON 컬럼을 통한 확장성:** 연동 측에서 필요로 하는 도메인 특화 데이터(검색용 데이터, 사용자 상세 정보 등)를 MessagingHub가 해석하지 않고 JSON 형태로 그대로 보관 및 전달함으로써 범용성을 확보했습니다. * **보안 및 자동 삭제:** 모든 메시지는 암호화하여 저장되며, 참여자 이탈에 따른 즉시 삭제나 설정된 보관 기간에 따른 자동 삭제 정책을 지원합니다. ### 챗봇 시나리오의 안정적인 배포와 SOFT STOP 정책 * **계층적 시나리오 구조:** 관리자 도구를 통해 시나리오를 편집하고 배포할 수 있으며, 답변과 선택지 및 외부 연동을 위한 웹훅 기능을 지원합니다. * **SOFT STOP 상태 도입:** 새로운 시나리오 배포 시, 기존 대화 중인 사용자는 이전 버전을 유지하고 신규 사용자에게만 새 버전을 노출하는 'SOFT STOP' 단계를 두어 사용자 경험의 단절을 방지합니다. * **지능형 스케줄링:** 스케줄러가 이전 버전 시나리오의 잔여 연결 정보를 주기적으로 체크하여, 더 이상 사용하는 사용자가 없을 때 자동으로 해당 버전을 종료 처리합니다. ### 상담 효율을 높이는 문의형 채팅 최적화 * **상담 컨텍스트 제공:** 상담원이 사용자 정보를 별도로 조회할 필요가 없도록, 채팅방 생성 시 연동 측으로부터 전달받은 검색 데이터, 추적 데이터 등 풍부한 메타데이터를 상담 화면에 함께 제공합니다. * **생명 주기 관리:** 상담 대기(PENDING)부터 종료(DISABLE) 및 재진입 방지(BLOCK)까지 이어지는 상담 전용 상태 관리를 통해 상담 프로세스의 일관성을 유지합니다. MessagingHub와 같은 채팅 플랫폼 도입은 서비스 확장 속도가 빠르고 다양한 소통 창구가 필요한 환경에서 특히 유용합니다. 채팅 기능을 직접 구현하기보다는, 인증과 데이터 처리는 전문 플랫폼에 맡기고 도메인 특화 데이터(Metadata)를 적극 활용하는 방향으로 설계한다면 시스템의 유연성과 운영 효율을 동시에 확보할 수 있을 것입니다.

figma3분 읽기큐레이션 요약

소프트웨어와 상호작용하는 방식을 재구상하는 6가지 디자인 | Figma 블로그

이번 Figma Make-a-thon 수상작들은 소프트웨어가 단순히 효율을 높이는 도구를 넘어, 사람들의 연결·놀이·창작 방식을 새롭게 설계할 수 있음을 보여준다. 공통적으로 기존의 익숙한 상호작용을 비틀고, 제약과 감각적 경험을 활용해 더 인간적인 디지털 경험을 만든다. 특히 Figma Make는 전문 개발 지식이 부족한 사람도 아이디어를 빠르게 프로토타입으로 구현하도록 돕는 도구로 소개된다. ## 소프트웨어 상호작용을 다시 상상한 Make-a-thon - Figma Make-a-thon은 핀치 줌, 좋아요 탭, 오른쪽 스와이프처럼 일상화된 상호작용의 다음 가능성을 탐구했다. - 수상작에는 총 10만 달러의 상금이 수여됐다. - 작품들은 새로운 기능보다 사람 사이의 연결, 놀이, 창의성, 장인정신에 초점을 맞춘다. - 얼굴 움직임으로 인터페이스를 조작하거나, 16비트 세계를 구현하는 등 익숙한 소프트웨어 사용 방식을 확장한다. ## 낯선 사람과 함께 만드는 자수 캔버스 **수상 부문: Best Overall — Common Thread** - 전통적인 자수 견본천(sampler)에서 영감을 얻은 멀티플레이어 디지털 캔버스다. - 사용자는 실의 색상과 스티치 유형을 선택해 공동 캔버스에 자신의 흔적을 남긴다. - 한 사람의 작업물이 아니라 여러 방문자가 이어서 완성하는 구조이며, 캔버스의 제한된 공간 자체가 중요한 경험이 된다. - 10만 개가 넘는 스티치가 쌓였으며, 작품은 완성되지 않은 채 계속 확장된다. - 제작자는 기능 목록보다 먼저 “어떤 느낌의 경험을 만들 것인가”를 설명하고, Figma Make로 구조를 만든 뒤 시각 디자인을 덧입히는 방식을 추천한다. - 실시간 협업과 인터랙티브 캔버스 기능을 개발 지식 없이 하루 만에 구현했다는 점도 강조된다. - 핵심 메시지는 속도와 규모를 중시하는 디지털 환경에서, 제한과 느린 공동 작업이 오히려 의미 있는 상호작용을 만든다는 것이다. ## 클릭 대신 입술 움직임으로 조작하기 **수상 부문: New Interaction — Pucker** - 손을 사용할 수 없거나 음성 명령을 원하지 않는 상황을 위해 얼굴 움직임을 입력 방식으로 활용한다. - 고개를 기울여 커서를 움직이고, 일정 시간 멈춰 항목을 선택하며, 입술을 오므리는 동작으로 선택을 확정한다. - 뜨개질, 요리, 베이킹, 디자인처럼 손이 바쁜 상황에서도 화면을 조작할 수 있다. - 전면 카메라로 실시간 추적하지만, 데이터는 저장하거나 전송하지 않는 방식으로 설계됐다. - 제작자는 기본적인 코드 구조를 이해하면 프로토타입을 수정하고 문제를 해결하는 데 큰 도움이 된다고 조언한다. - Pucker는 특정 제품이라기보다 여러 앱과 플랫폼에 적용할 수 있는 “유연한 인터랙션 레이어”로 제시된다. - 새로운 상호작용이 충분히 자연스러워지면 사용자가 의식하지 않고도 사용할 수 있으며, 이것이 접근성 높은 디자인으로 이어질 수 있다는 관점을 담고 있다. ## 시간과 공간의 제약을 없앤 사진 부스 **수상 부문: Reimagining Iconic Interactions — Duet Booth** - 1920년대부터 크게 변하지 않은 사진 부스의 개념을 원격 환경으로 확장한다. - 서로 다른 장소에 있는 두 사람이 비동기적으로 사진을 촬영할 수 있다. - 각자의 사진을 하나의 사진 스트립으로 결합해, 마치 두 사람이 같은 장소에 함께 있었던 것처럼 보여준다. - 사진 부스가 사진을 더 쉽고 즉각적이며 공유 가능한 경험으로 만들었다는 점을 디지털 공간에서 재해석한다. - 제작자는 시각적 세부 사항보다 핵심 상호작용을 먼저 완성하라고 조언한다. 기본 경험이 제대로 작동하면 이후의 디자인 요소가 이를 중심으로 정리되기 때문이다. 이 사례들이 보여주는 실용적인 방향은 기능을 많이 추가하는 것보다 사용자가 어떤 감정과 행동을 경험할지 먼저 정의하는 것이다. 그 후 핵심 상호작용을 빠르게 프로토타이핑하고, 시각 디자인과 세부 기능을 단계적으로 보완하면 제한된 시간과 개발 지식으로도 독창적인 소프트웨어 경험을 만들 수 있다.

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

97% 더 작고 2배 더 빠르게: es-toolkit이 주간 다운로드 1,000만 건을 달성한 방법 (새 탭에서 열림)

es-toolkit은 lodash를 대체하기 위해 토스(Toss)에서 처음부터 다시 설계한 현대적인 JavaScript 유틸리티 라이브러리입니다. 최신 웹 표준인 ES Modules와 TypeScript를 기반으로 제작되어 lodash 대비 번들 크기는 최대 97% 줄이고 실행 속도는 2배 이상 높였습니다. 현재 마이크로소프트, IBM 등 글로벌 기업들이 도입하며 주간 1,000만 회 이상의 다운로드를 기록하는 등 차세대 표준 유틸리티로 자리 잡고 있습니다. ### lodash의 한계와 탄생 배경 * **구식 아키텍처:** lodash는 10년 전 JavaScript 환경에 맞춰 설계되어, 최신 웹의 표준인 ES Modules 기반의 트리 셰이킹(Tree-shaking)을 완벽히 활용하지 못합니다. * **불필요한 의존성:** lodash는 단일 함수를 임포트하더라도 내부적인 헬퍼 함수들이 함께 포함되어 번들 크기가 커지는 구조적 한계를 가집니다. * **현대적 엔진 최적화 미비:** V8이나 SpiderMonkey와 같은 현대적 엔진은 과거에 느렸던 패턴들을 최적화했지만, lodash는 하위 호환성 문제로 이러한 최신 성능 이점을 충분히 누리지 못합니다. ### 독보적인 번들 사이즈와 실행 성능 * **완전한 독립성:** 모든 함수가 처음부터 독립적으로 설계되어 숨겨진 내부 의존성이 없습니다. 예를 들어 주요 함수 5개를 사용할 때 lodash는 약 30KB를 차지하지만, es-toolkit은 1KB에 불과합니다. * **런타임 최적화:** 현대 JavaScript 엔진에 최적화된 패턴을 적용하여 대부분의 함수가 2배 이상 빠르며, 특정 함수(`omit`)의 경우 11배 이상의 성능 향상을 보여줍니다. * **실질적 절감 효과:** `sample` 함수의 경우 lodash 대비 번들 크기를 96%까지 줄이는 등, 실제 프로젝트의 Core Web Vitals 지표 개선에 직접적인 도움을 줍니다. ### TypeScript 우선 설계 및 호환성 * **정밀한 타입 추론:** 별도의 `@types` 패키지 없이 소스 코드와 타입 정의가 함께 제공되어 타입 정확도가 매우 높고, 복잡한 타입도 정확히 추론합니다. * **드롭인 교체 지원:** `es-toolkit/compat` 레이어를 통해 lodash와 100% 호환성을 보장합니다. 이는 Storybook, Recharts 등 대규모 오픈소스 프로젝트의 성공적인 마이그레이션으로 검증되었습니다. * **활발한 생태계:** 토스 프런트엔드 챕터의 오픈소스 위원회가 주도하며, `overlay-kit`, `use-funnel` 등과 함께 지속적으로 관리되고 업데이트됩니다. ### 손쉬운 마이그레이션 방법 * **단축 경로:** `package.json`의 의존성 설정에서 `lodash`를 `npm:es-toolkit`으로 별칭(alias) 지정하는 것만으로 코드 수정 없이 즉시 성능 이점을 얻을 수 있습니다. * **점진적 전환:** 단순한 임포트 경로 변경만으로도 도입이 가능하며, 대규모 코드베이스를 위해 공식 codemod 도구(`@es-toolkit/codemod`)를 제공하여 전환 비용을 최소화합니다. 번들 크기 최적화와 런타임 성능이 중요한 현대 프런트엔드 환경에서 lodash를 유지할 이유는 점차 사라지고 있습니다. 단 5분의 투자로 `package.json` 설정을 변경하여 즉각적인 성능 향상을 경험해 보길 권장하며, 특히 TypeScript를 활발히 사용하는 프로젝트라면 타입 안전성 측면에서도 es-toolkit은 최선의 선택이 될 것입니다.

aws원문

AWS Sustainability 콘솔 발표: 프로그래밍 방식 액세스, 구성 가능한 CSV 보고서, Scope 1~3 보고를 한 곳에서 | Amazon Web Services (새 탭에서 열림)

AWS는 고객이 자사 워크로드의 환경적 영향을 정밀하게 측정하고 관리할 수 있도록 독립된 서비스인 'AWS 지속 가능성 콘솔(AWS Sustainability console)'을 출시했습니다. 기존에 빌링(Billing) 콘솔의 하위 기능으로 제공되던 탄소 발자국 도구를 별도 서비스로 분리하여 접근성을 높였으며, API 지원과 맞춤형 리포트 기능을 통해 기업의 ESG 공시 및 데이터 통합 과정을 대폭 간소화했습니다. 이를 통해 지속 가능성 전문가들은 재무 데이터에 대한 권한 없이도 탄소 배출량 데이터에 직접 접근하여 분석할 수 있게 되었습니다. **빌링 권한으로부터 독립된 데이터 접근 체계** * 기존에는 탄소 발자국 데이터를 확인하기 위해 비용 및 결제 정보에 접근할 수 있는 빌링 권한이 반드시 필요했으나, 이제는 지속 가능성 콘솔만의 독립적인 IAM 권한 모델을 사용합니다. * 이를 통해 민감한 재무 정보에 노출될 필요가 없는 지속 가능성 담당자나 리포팅 팀에게 필요한 데이터만 안전하게 제공할 수 있습니다. **Scope 1~3 탄소 배출량의 심층 분석** * AWS 사용으로 발생하는 Scope 1(직접 배출), Scope 2(에너지 구매를 통한 간접 배출), Scope 3(공급망 및 제조 등 기타 간접 배출) 데이터를 모두 제공합니다. * 탄소 배출량을 리전(Region)별, 서비스(Amazon EC2, S3, CloudFront 등)별로 세분화하여 확인할 수 있어 배출량이 집중된 지점을 정확히 파악할 수 있습니다. * Scope 2 배출량의 경우, 에너지 속성 인증서를 반영한 시장 기반 방식(MBM)과 지역 그리드 평균 배출량을 반영한 위치 기반 방식(LBM)을 모두 지원하여 공시 표준에 맞는 데이터를 활용할 수 있습니다. **유연한 리포트 생성 및 회계 연도 맞춤화** * 사전 정의된 월간 및 연간 탄소 배출 리포트를 다운로드할 수 있으며, 사용자가 필요한 필드와 시간 단위, 필터를 선택하여 맞춤형 CSV 리포트를 생성할 수 있습니다. * 기업의 회계 연도가 달력상의 연도와 일치하지 않는 경우, 콘솔 내에서 회계 연도 시작 월을 설정하여 모든 데이터 뷰와 내보내기 파일을 조직의 보고 주기에 맞출 수 있습니다. **API 및 SDK를 통한 프로그래밍 방식의 데이터 통합** * 새롭게 출시된 API와 AWS SDK, CLI를 사용하여 탄소 배출 데이터를 기업 내부의 대시보드나 컴플라이언스 워크플로에 자동으로 통합할 수 있습니다. * 대규모 계정을 운영하는 조직은 별도의 데이터 내보내기 설정 없이도 특정 기간의 데이터를 프로그래밍 방식으로 추출하여 맞춤형 계정 그룹별 배출량을 산출할 수 있습니다. 이 서비스는 추가 비용 없이 즉시 사용할 수 있으며, 2022년 1월부터의 과거 데이터를 제공하므로 조직의 탄소 배출 트렌드를 즉각적으로 분석할 수 있습니다. 지속 가능성 담당자는 새롭게 제공되는 API를 활용해 수동 작업을 줄이고, 기업의 ESG 보고 파이프라인을 자동화하여 공시 대응 효율을 높이는 것을 추천합니다.

slack3분 읽기큐레이션 요약

커스텀에서 오픈으로: Prometheus를 활용한 확장 가능한 네트워크 프로빙 및 HTTP/3 준비성

Slack은 HTTP/3 도입 과정에서 기존 모니터링 도구가 QUIC/UDP 기반 엔드포인트를 측정하지 못하는 관측성 공백을 발견했다. 이를 해결하기 위해 Prometheus Blackbox Exporter에 `quic-go` 기반 HTTP/3 프로빙 기능을 추가하고 오픈소스로 공개했다. 그 결과 HTTP/1.1, HTTP/2, HTTP/3를 Grafana에서 통합 관찰하고 더 정확한 알림과 장애 분석이 가능해졌다. ### 기존 모니터링 도구의 한계 - Slack은 AWS Availability Zone 간 내부 트래픽과 인터넷에서 인프라로 유입되는 외부 트래픽을 상용 SaaS 및 자체 도구로 측정해 왔다. - HTTP/3는 TCP 대신 UDP 기반의 QUIC 프로토콜을 사용한다. - 기존 SaaS 관측성 도구 대부분은 HTTP/3 프로빙을 기본 지원하지 않았다. - 핵심 모니터링 도구인 Prometheus Blackbox Exporter(BBE)에도 QUIC 네이티브 지원이 없었다. - 수십만 개의 HTTP/3 엔드포인트를 측정할 수 없어 HTTP/2로의 회귀, 실제 왕복 시간(RTT), 클라이언트 관점의 성능 변화를 파악하기 어려웠다. ### `quic-go` 기반 HTTP/3 프로브 구현 - 인턴 Sebastian Feliciano가 BBE에 QUIC 지원을 구현하고 오픈소스로 기여했다. - Go용 QUIC 라이브러리로 널리 사용되는 `quic-go`를 선택했다. - HTTP/3 전송 계층을 다음과 같이 구성해 기존 HTTP 클라이언트에 연결했다. ```go http3Transport := &http3.Transport{ TLSClientConfig: tlsConfig, QUICConfig: &quic.Config{}, } client = &http.Client{ Transport: http3Transport, } ``` - BBE의 기존 설정 방식과 아키텍처를 유지해 새로운 프로브도 기존 기능과 조합할 수 있도록 설계했다. - 이를 통해 HTTP/3 엔드포인트에 대해 설정 가능한 Prometheus 프로브가 제공됐다. ### 오픈소스 기여와 사내 통합 - 새로운 기능을 Prometheus BBE에 upstream 기여해 다른 조직도 사용할 수 있게 했다. - 오픈소스 PR의 병합을 기다리는 동안, Slack은 새 기능을 활용하는 사내 프로빙 시스템도 별도로 설계했다. - 결과적으로 외부 공개 기능과 Slack 인프라에 맞춘 운영 시스템을 함께 확보했다. ### 통합 관측성과 운영 개선 - Grafana에서 HTTP/1.1, HTTP/2, HTTP/3 지표를 하나의 화면에서 확인할 수 있게 됐다. - 프로토콜별 성능을 비교하고 다른 텔레메트리와 상관관계를 분석하기 쉬워졌다. - HTTP/3 엔드포인트의 상태와 성능을 기반으로 더 정확하고 신뢰성 높은 알림을 만들 수 있게 됐다. - 장애 발생 시 관련 지표를 한곳에서 확인해 원인 분석과 디버깅 속도를 높였다. ### 향후 확장 방향 - **SNI 라우팅 테스트** - 공유 IP를 사용하는 CDN이나 멀티테넌트 로드밸런서에서 요청한 호스트명이 올바른 백엔드로 라우팅되는지 검증한다. - 올바른 TLS 인증서가 반환되는지도 확인해 잘못된 라우팅을 방지할 수 있다. - **종단 간 네트워크 경로 시각화** - 단순한 성공/실패 확인을 넘어 모니터링 에이전트부터 서비스까지의 네트워크 홉을 시각화한다. - 지연 증가나 패킷 손실이 어느 구간에서 발생했는지 파악할 수 있다. ### 실무적인 시사점 - 새로운 프로토콜이나 인프라로 마이그레이션하기 전에 먼저 관측성을 확보해야 한다. - 기존 도구에 기능이 없을 때 직접 구현하고 오픈소스로 공유하면 조직과 커뮤니티 모두의 비용을 줄일 수 있다. - HTTP/3 도입을 검토하는 팀이라면 Prometheus Blackbox Exporter의 QUIC 프로브를 활용해 마이그레이션 전후 성능과 장애를 지속적으로 비교하는 것이 좋다.

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

Meta 적응형 랭킹 모델: 추론 확장 곡선을 휘어 광고에 LLM급 모델 제공하기 (새 탭에서 열림)

메타는 광고 추천 시스템의 성능을 비약적으로 높이기 위해 LLM 수준의 복잡도를 갖춘 '적응형 랭킹 모델(Adaptive Ranking Model)'을 도입하여 추론의 복잡성, 지연 시간, 비용 효율성 사이의 상충 관계를 해결했습니다. 이 모델은 모든 요청에 동일한 연산을 적용하는 대신 지능형 요청 라우팅과 하드웨어 인지형 설계를 통해 1초 미만의 응답 시간을 유지하면서도 광고 전환율을 3% 이상 향상시키는 성과를 거두었습니다. 결과적으로 메타는 인프라 비용의 급증 없이도 수십억 명의 사용자에게 고도로 개인화된 광고 경험을 제공할 수 있는 기술적 토대를 마련했습니다. ### 추론 효율성을 극대화하는 모델 확장 기술 * **요청 중심의 계산 공유:** 기존의 개별 광고 단위 처리 방식에서 벗어나, 한 번의 요청 내에서 공통된 사용자 신호를 한 번만 계산하고 이를 여러 광고 후보군이 공유하는 '요청 지향 최적화(Request-Oriented Optimization)'를 도입했습니다. * **서브 리니어(Sub-linear) 비용 구조:** GPU 커널 내에서 요청 수준의 임베딩을 직접 브로드캐스트함으로써 연산량 증가에 따른 비용 상승 곡선을 완만하게 만들고 메모리 대역폭 압박을 줄였습니다. * **장기 사용자 시퀀스 활용:** 연산 오버헤드 때문에 제한적이었던 긴 사용자 행동 데이터를 중앙 집중식 키-값(KV) 저장소와 실시간 결합 방식을 통해 효율적으로 처리하여 사용자 의도 파악의 깊이를 더했습니다. ### 모델과 시스템의 통합 설계: Wukong Turbo * **구조적 처리량 최적화:** 메타의 내부 아키텍처인 Wukong을 발전시킨 'Wukong Turbo'는 수치적 불안정성을 제거하는 'No-Bias' 접근법을 통해 파라미터 수 증가 없이도 처리량을 극대화했습니다. * **하드웨어 친화적 파라미터 배치:** 전체 샤딩 데이터 병렬 처리(FSDP)와 분산 데이터 병렬 처리(DDP) 사이에서 파라미터 역할을 적절히 분배하여 네트워크 오버헤드를 줄이고, 모델 플롭스 이용률(MFU)을 다양한 하드웨어 환경에서 35%까지 끌어올렸습니다. * **지연 시간 중립화:** GPU가 데이터를 기다리며 공회전하는 '데이터 기아' 현상을 방지하기 위해, 기존 CPU 중심이었던 피처 전처리를 GPU로 이관하여 엔드투엔드 실행 경로를 단순화했습니다. ### 1조 파라미터 시대를 여는 서빙 인프라 * **멀티 카드 GPU 아키텍처:** 단일 장치의 메모리 한계를 극복하기 위해 다중 GPU 카드 구성을 활용하여, 추천 시스템에서도 1조(1T) 단위의 파라미터 확장이 가능하도록 인프라를 재설계했습니다. * **지능형 요청 라우팅:** 사용자의 문맥과 의도에 따라 모델의 복잡도를 동적으로 조절함으로써, 시스템 자원을 가장 효과적인 요청에 우선적으로 배정하여 전체적인 ROI를 높였습니다. 이번 적응형 랭킹 모델의 성공은 대규모 언어 모델(LLM) 수준의 복잡도를 실시간 서비스에 적용하기 위해서는 단순한 하드웨어 확장이 아닌, 모델 아키텍처와 서빙 인프라의 심층적인 협업 설계가 필수적임을 보여줍니다. 실시간 추천 성능을 개선하고자 하는 기업들은 연산 단위를 개별 아이템에서 요청 단위로 전환하고, GPU 활용도를 극대화할 수 있는 하드웨어 인지형 소프트웨어 스택 구축에 집중할 필요가 있습니다.

github3분 읽기큐레이션 요약

Copilot Applied Science의 에이전트 주도 개발

GitHub Copilot Applied Science 팀의 Tyler McGoffin은 코딩 에이전트를 활용해 벤치마크 결과 분석에 필요한 지적 반복 작업을 자동화한 프로젝트 `eval-agents`를 만들었다. 핵심은 에이전트를 단순한 코드 생성기가 아니라 계획·구현·검증에 참여하는 협업자로 활용하고, 에이전트가 기여하기 쉬운 저장소 구조를 만드는 것이다. 그 결과 3일도 안 되어 5명이 11개 에이전트와 4개 스킬을 추가하고, 345개 파일에 걸쳐 약 2만 8천 줄의 변경을 만들어냈다. ## 반복적인 벤치마크 분석에서 `eval-agents` 탄생 - 연구자는 TerminalBench2, SWEBench-Pro 같은 코딩 에이전트 평가 벤치마크를 분석한다. - 각 평가 작업은 에이전트의 사고 과정과 행동을 담은 trajectory로 기록되며, 대개 수백 줄의 `.json` 파일로 저장된다. - 수십 개 작업과 여러 번의 벤치마크 실행을 합치면 분석 대상이 수십만 줄에 달한다. - 기존에는 Copilot으로 trajectory에서 패턴을 먼저 찾은 뒤 사람이 직접 조사해 읽어야 할 분량을 수백 줄로 줄였다. - 이 반복 과정을 에이전트가 자동 수행하도록 만든 도구가 `eval-agents`다. ## 프로젝트 설계 목표 - 에이전트를 쉽게 공유하고 사용할 수 있도록 구성한다. - 새로운 에이전트를 쉽게 작성할 수 있도록 한다. - 사람보다 코딩 에이전트가 프로젝트 기여의 주요 수단이 되도록 설계한다. - 특히 세 번째 목표를 적용하자 프로젝트 자체의 사용성과 협업성도 함께 좋아졌다. - 과학자와 엔지니어가 각자의 필요에 맞는 에이전트와 기능을 직접 추가할 수 있는 기반이 마련됐다. ## 코딩 에이전트를 중심으로 한 개발 환경 - 코딩 에이전트: Copilot CLI - 사용 모델: Claude Opus 4.6 - IDE: VS Code - Copilot SDK를 사용해 Copilot CLI의 도구, MCP 서버, 사용자 정의 도구와 스킬 등록 기능을 재활용했다. - 에이전트 실행 기반을 직접 처음부터 만들지 않아도 되어 에이전트 생성 속도를 높일 수 있었다. ## 효과적인 프롬프트 전략 - 에이전트는 범위가 명확한 작업에는 강하지만, 복잡하고 고차원적인 문제에는 충분한 안내가 필요하다. - 짧은 요구사항보다 문제를 고민하는 과정, 전제, 우려 사항을 자세히 설명하는 대화형 프롬프트가 효과적이다. - 바로 구현을 지시하기보다 계획 모드에서 조사와 설계를 먼저 진행하게 하는 것이 좋다. - 예를 들어 테스트가 에이전트의 변경에 맞춰 부적절하게 수정되는 문제를 해결하기 위해, 계획 모드에서 에이전트가 건드릴 수 없는 보호된 테스트 영역을 설계하도록 했다. - 그 대화의 결과로 사람이 승인해야만 수정할 수 있는 계약 테스트와 유사한 회귀 방지 장치가 만들어졌다. - 결론적으로 효과적인 인간 엔지니어에게 필요한 설명, 사고 유도, 검토 과정이 에이전트에도 동일하게 중요하다. ## 에이전트 우선 저장소를 위한 아키텍처 전략 - 에이전트 중심 프로젝트에서는 새 기능보다 코드 구조 개선, 리팩터링, 문서화, 테스트 작성이 더 중요한 기반 작업이 된다. - 명확한 이름과 파일 구조는 에이전트가 코드를 탐색하고 변경하기 쉽게 만든다. - 기능과 패턴을 문서화하면 에이전트가 프로젝트의 규칙과 설계 의도를 더 잘 따를 수 있다. - 발견된 문제를 테스트 케이스로 남기면 이후 에이전트의 변경으로 인한 회귀를 방지할 수 있다. - 에이전트가 기능을 빠르게 추가할수록 사람이 죽은 코드와 불필요한 복잡성을 정리하는 작업도 병행해야 한다. - 잘 관리된 저장소에서는 Copilot을 통한 기능 전달이 쉬워지므로, 과거에 미뤄두었던 유지보수 작업이 개발 생산성의 핵심 요소가 된다. ## 짧은 기간에 이루어진 협업 성과 - 처음 참여한 팀원 5명이 3일 이내에 프로젝트에 기여했다. - 새로 추가된 항목: - 에이전트 11개 - 스킬 4개 - 과학자의 추론 흐름을 표현하는 `eval-agent workflows` - 전체 변경 규모는 345개 파일에서 `+28,858/-2,884`줄이었다. - 이는 에이전트에게 적절한 개발 환경과 구조를 제공하면 새로운 기능과 협업을 매우 빠르게 확장할 수 있음을 보여준다. 에이전트를 효과적으로 활용하려면 좋은 프롬프트만으로는 부족하다. 계획 모드와 상세한 대화를 적극 활용하고, 문서·테스트·리팩터링을 지속해 에이전트가 이해하기 쉬운 저장소를 유지하는 것이 실용적인 출발점이다.

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

Programmable Flow Protection 소개: Magic Transit 고객을 위한 맞춤형 DDoS 완화 로직 (새 탭에서 열림)

클라우드플레어는 매직 트랜짓(Magic Transit) 고객이 자신의 네트워크 환경에 맞춘 DDoS 방어 로직을 직접 설계하고 배포할 수 있는 '프로그래밍 가능한 플로우 보호(Programmable Flow Protection)' 기능을 출시했습니다. 이 기능은 표준화되지 않은 독자적인 UDP 프로토콜을 사용하는 기업들이 eBPF 프로그램을 통해 트래픽의 정당성을 직접 판단하게 함으로써, 기존의 일률적인 차단 방식이 가졌던 오탐 문제를 해결합니다. 고객은 클라우드플레어의 글로벌 네트워크 인프라 위에서 직접 작성한 코드를 실행해 대규모 공격을 정교하고 유연하게 방어할 수 있습니다. ### 커스텀 UDP 프로토콜 방어의 한계 극복 * 기존 DDoS 방어 시스템은 TCP, DNS, NTP 등 잘 알려진 프로토콜의 특성을 활용해 공격을 식별하지만, 기업 고유의 커스텀 UDP 프로토콜은 내부 구조를 알 수 없어 정교한 대응이 어려웠습니다. * 알려지지 않은 UDP 트래픽에 공격이 발생할 경우, 기존에는 특정 IP나 포트 전체를 차단하거나 속도 제한(Rate Limit)을 거는 투박한 방식을 사용해야 했습니다. * 이러한 방식은 공격 트래픽뿐만 아니라 정상적인 사용자의 패킷까지 차단하여 서비스 지연이나 연결 끊김을 유발하는 부작용이 있었습니다. ### eBPF 기반의 맞춤형 방어 메커니즘 * 고객은 eBPF(Extended Berkeley Packet Filter) 프로그램을 작성하여 어떤 패킷이 '정상'이고 '비정상'인지 직접 정의할 수 있습니다. * 작성된 프로그램은 클라우드플레어의 전 세계 엣지 네트워크에 배포되어 모든 유입 패킷에 대해 즉각적인 판단(통과, 차단, 챌린지 등)을 수행합니다. * 커널 공간이 아닌 사용자 공간(Userspace)에서 프로그램을 실행함으로써 보안성을 확보하면서도, 클라우드플레어의 기존 DDoS 방어 계층 이후에 실행되어 다층적인 보호를 제공합니다. ### 상태 저장 및 고급 기능 지원 * 단순한 패킷 필터링을 넘어, 클라이언트의 상태를 저장하고 관리할 수 있는 '상태 저장(Stateful)' 기능을 지원합니다. * 클라우드플레어는 프로그램 실행 간 상태 유지, 암호화 검증, 챌린지 패킷 발송 등을 돕는 전용 API 및 헬퍼 함수(Helper Functions)를 제공합니다. * 이를 통해 게임 엔진의 고유 헤더 검증이나 토큰 기반의 인증 등 복잡한 애플리케이션 계층의 방어 로직을 네트워크 하단에서 구현할 수 있습니다. ### 실무 적용 예시: 독자적인 게임 프로토콜 보호 * 독자적인 헤더 구조를 가진 UDP 포트 기반 온라인 게임 서버의 경우, 공격자가 무작위 페이로드를 보내면 일반적인 장비로는 구분할 수 없습니다. * '프로그래밍 가능한 플로우 보호'를 활용하면 패킷 헤더 내의 특정 바이트나 고유 토큰을 검사하는 코드를 배포하여, 유효하지 않은 모든 트래픽을 클라우드플레어 엣지에서 즉시 제거합니다. * 결과적으로 원본 서버(Origin)에 도달하기 전에 공격이 차단되어 서버 자원을 보호하고 실제 이용자에게는 쾌적한 환경을 제공하게 됩니다. 현재 이 기능은 매직 트랜짓 엔터프라이즈 고객을 대상으로 베타 서비스 중입니다. 표준 프로토콜을 벗어난 고유의 통신 방식을 보유하고 있으며, 기존의 단순 차단 방식만으로는 서비스 품질 유지가 어려운 기업에게 이 기능을 통한 정밀한 트래픽 제어를 권장합니다.