techlist.io
KREN

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

github4분 읽기큐레이션 요약

GitHub 에이전틱 워크플로로 리포지토리 간 문서화 자동화

Aspire 팀은 GitHub Agentic Workflows를 활용해 제품 코드 저장소와 문서 저장소가 분리된 환경에서도 기능 변경 직후 문서 PR을 자동 생성하는 시스템을 구축했다. 에이전트가 변경 사항과 이슈를 분석해 문서를 작성하지만, 실제 쓰기 작업은 제한된 별도 핸들러가 수행하도록 분리해 보안을 확보했다. 그 결과 Aspire 13.3·13.4에서 82개의 문서 PR이 제품 PR 병합 후 중앙값 44.8시간 내 생성됐고, 모두 해당 기능을 구현한 엔지니어의 검토를 받았다. ## 교차 저장소 문서화가 어려운 이유 - 제품 코드는 `microsoft/aspire`, 문서 사이트는 `microsoft/aspire.dev`에 있어 저장소와 배포 대상, 리뷰 절차가 분리되어 있다. - 기존 방식은 문서 작성자가 몇 주 뒤 닫힌 PR을 찾아 변경 내용을 역추적하는 구조였다. - 기능 작성자는 이미 다음 작업으로 넘어간 상태라 문서 작성에 필요한 맥락을 충분히 제공하기 어려웠다. - 저장소 전체에 쓰기 권한을 가진 광범위한 토큰은 보안상 부적절하므로, 단순한 크로스 리포지토리 자동화도 권한 설계가 병목이 된다. ## GitHub Agentic Workflows의 구조 - 워크플로를 YAML 대신 하나의 Markdown 파일로 작성한다. - YAML 형식의 frontmatter에 설정을 작성한다. - 아래에는 에이전트가 수행할 작업을 자연어 프롬프트로 작성한다. - 컴파일하면 일반 GitHub Actions 워크플로인 `.lock.yml` 파일이 생성된다. - 실행 시 에이전트는 제한된 도구와 프롬프트를 바탕으로 변경 사항을 분석한다. - 에이전트가 GitHub에 직접 쓰지 않는 점이 핵심이다. - 에이전트는 생성하려는 PR, 이슈, 댓글을 JSON 형태의 의도로 출력한다. - 별도의 `safe-outputs handler`가 허용된 작업만 실제로 실행한다. - 저장소와 작업 종류를 명시적으로 제한할 수 있어 보안 검토와 자동화의 균형을 맞춘다. ## 기능 PR에서 문서 PR로 이어지는 자동화 흐름 - `microsoft/aspire`의 `main` 또는 `release/*` 브랜치에 병합된 PR을 `pull_request: closed` 이벤트로 감지한다. - `merged == true` 조건을 적용해 실제 병합된 PR만 처리한다. - 에이전트가 실행되기 전에 Bash 기반의 결정론적 로직으로 문서 대상 브랜치를 결정한다. 1. 제품 PR의 마일스톤 제목을 확인한다. 예를 들어 `13.4`는 문서 저장소의 `release/13.4`로 매핑된다. 2. PR 본문에서 `Fixes`, `Closes`, `Resolves`로 연결된 이슈를 찾고, 해당 이슈의 첫 번째 비어 있지 않은 마일스톤을 확인한다. 3. PR의 base ref가 `release/X.Y` 또는 `release/X.Y.Z` 형식이면 이를 사용한다. 4. 어느 조건에도 해당하지 않으면 `main`을 사용한다. - 마일스톤과 문서 브랜치를 명확히 매핑해 에이전트가 대상 브랜치를 추측하지 않도록 한다. - 에이전트는 제품 diff와 연결된 이슈를 읽고 문서화가 필요한 변경인지 판단한다. - 문서가 필요하면 체크아웃된 `microsoft/aspire.dev` 작업 공간에 기존 문서 작성 규칙에 맞춰 초안을 작성한다. - 문서의 문체 - MDX 규칙 - Astro Starlight 컴포넌트 사용법 - 이후 `create_pull_request` safe output을 생성해 문서 PR 생성을 요청한다. ## 제한된 권한으로 PR 생성하기 - safe-outputs 핸들러는 실제 PR 생성 시 다음 제약을 적용한다. - PR 제목에 `[docs]` 접두사 사용 - `docs-from-code` 라벨 부착 - 자동 병합 없이 항상 draft PR로 생성 - base 브랜치는 `main` 또는 `release/*`로 제한 - 대상 저장소는 `microsoft/aspire.dev`로 고정 - 제품 PR의 리뷰 기록에서 해당 기능을 승인한 SME를 찾아 문서 PR 리뷰어로 요청한다. - 문서 리뷰가 기능 구현자의 맥락과 분리되지 않도록, 실제 기능을 승인한 사람이 문서도 검토하게 한다. - 별도 작업은 원본 제품 PR에 문서 PR 링크를 댓글로 남긴다. - 재실행 시 이전 `pr-docs-check` 댓글을 최소화해 중복 알림을 줄인다. - 기능을 병합한 엔지니어는 몇 분 안에 문서 초안을 확인할 수 있다. ## 보안 설계와 safe-outputs 계약 - GitHub 도구 세트를 `repos`, `issues`, `pull_requests` 등 필요한 범위로 제한한다. - `min-integrity: approved` 설정으로 무결성이 검증된 작업만 실행하도록 한다. - 허용 저장소를 `microsoft/*`처럼 제한할 수 있다. - 전용 GitHub App의 App ID와 private key를 사용해 일반적인 광범위 토큰 대신 작업별 권한을 부여한다. - App이 접근할 수 있는 저장소도 `aspire.dev`, `aspire`로 한정한다. - 에이전트의 분석 권한과 실제 변경 권한을 분리해, 에이전트가 임의로 저장소에 쓰거나 병합하지 못하게 한다. - 최종 문서 반영은 여전히 draft PR과 사람의 리뷰를 거친다. ## 측정된 결과 - Aspire 13.3과 13.4에서 문서 기능 PR 82개가 병합됐다. - 문서 PR은 제품 PR 병합 후 중앙값 44.8시간 뒤에 생성됐다. - 모든 문서 PR을 해당 기능을 구현한 엔지니어가 검토했다. - 별도의 인력 충원이나 새로운 프로세스 교육 없이 운영됐다. - 문서 작성 시점이 기능 출시 후 수 주가 아니라 기능 병합 직후로 앞당겨졌다. 기능 저장소와 문서 저장소가 분리되어 있다면, 에이전트에게 광범위한 쓰기 권한을 주기보다 **결정론적인 브랜치 선택 로직, 제한된 safe outputs, 초안 PR, 담당 엔지니어 리뷰**를 결합하는 방식이 실용적이다. AI가 문서를 작성하더라도 최종 병합은 사람이 담당하도록 설계하는 것이 안전성과 문서 품질을 함께 확보하는 방법이다.

원문 읽기(새 탭에서 열림)
AI 에이전트GitHub Actionsastrogithub-agentic-workflows+3
github3분 읽기큐레이션 요약

GitHub Copilot이 GitHub Pages에서 DNS 설정을 전혀 필요 없게 만드는 방법

GitHub Copilot CLI와 Namecheap API를 연동하면 DNS 레코드를 직접 수정하지 않고도 GitHub Pages 사이트를 사용자 도메인에 연결할 수 있다. 글에서는 저장소 생성부터 도메인 등록, DNS 설정, HTTPS 적용 및 배포 확인까지 약 14분 만에 완료하는 과정을 소개한다. 핵심은 Copilot CLI의 Namecheap 스킬이 API를 통해 DNS 작업을 자동화하되, 실제 변경 전에는 사용자 승인을 받는다는 점이다. ## GitHub Pages 사이트 만들기 - 공개 GitHub 저장소를 생성한다. - Copilot CLI에 원하는 결과를 설명해 `index.html`과 랜딩 페이지를 만들도록 한다. - GitHub Pages 활성화도 Copilot CLI를 통해 처리할 수 있다. - 우선 `github.io` 주소로 사이트가 배포되며, 이후 사용자 도메인을 연결한다. ## 저렴한 도메인 등록 - 비싼 `.com` 도메인이 아니어도 사이드 프로젝트를 시작할 수 있다. - 글에서는 `.click` 최상위 도메인을 사용했다. - `ghpagesblog.click` 도메인을 약 2달러에 등록했다. ## Namecheap API 활성화 - Namecheap의 **Profile → Tools → Business & Dev Tools → Namecheap API Access**로 이동한다. - API를 활성화한다. - API를 호출할 컴퓨터의 공인 IP를 **Whitelisted IPs**에 추가한다. - 발급된 API 키를 안전하게 보관한다. - API 키는 이후 Copilot CLI가 Namecheap 계정과 DNS를 관리할 때 사용한다. ## Copilot CLI에 Namecheap 스킬 설치 - 다음 명령으로 Namecheap 자동화 스킬을 설치한다. ```bash gh skill install github/awesome-copilot namecheap --scope user ``` - Copilot CLI에 Namecheap 도메인 목록 조회 등을 요청하면 사용자 이름과 API 키를 입력하도록 안내한다. - 인증 정보가 설정되면 계정의 도메인 목록을 반환해 API 연결이 정상인지 확인할 수 있다. - API 키는 로컬에 저장되므로 보관 위치와 접근 권한에 주의해야 한다. ## DNS 레코드 자동 설정 - Copilot CLI에 특정 Namecheap 도메인을 GitHub Pages 사이트에 연결하도록 요청한다. - 자동화 스킬은 DNS를 변경하기 전에 사용자에게 승인을 요청한다. - 기존 Namecheap 주차(parking) 또는 리디렉션 레코드를 제거하고 GitHub Pages에 필요한 설정으로 교체한다. - 루트 도메인에는 GitHub Pages의 A 레코드를 설정한다. - `www` 서브도메인에는 GitHub Pages를 가리키는 CNAME 레코드를 설정한다. - 저장소에도 `CNAME` 파일을 커밋해 GitHub Pages가 해당 사용자 도메인에 응답하도록 구성한다. ## 배포 및 도메인 확인 - Copilot CLI는 설정이 끝났다고 가정하지 않고 도메인 해석 상태를 직접 확인한다. - DNS가 올바르게 GitHub Pages를 가리키는지 검증한다. - GitHub Pages의 사용자 도메인 설정과 실제 사이트 연결 상태를 함께 확인하는 방식이다. - 글의 목표는 DNS 전파와 HTTPS 적용을 포함한 전체 배포 과정을 수동 설정 없이 완료하는 것이다. 실용적으로는 GitHub Pages와 Namecheap을 사용하는 개인 프로젝트에서 이 방식을 활용할 수 있다. 다만 DNS 레코드 삭제·교체와 API 키 사용이 포함되므로, 자동화 도중 표시되는 변경 내용을 반드시 검토하고 승인하는 것이 좋다.

원문 읽기(새 탭에서 열림)
github-copilotdnsgithub-pagesnamecheap-api+2
cloudflare4분 읽기큐레이션 요약

Meerkat 소개 - 글로벌 합의에 대한 실험

Cloudflare는 330곳이 넘는 글로벌 데이터센터에서 동일한 컨트롤 플레인 상태를 강한 일관성으로 읽고 수정할 수 있는 합의 서비스를 개발하고 있다. 기존 Raft는 리더 장애와 타임아웃 때문에 광역 네트워크에서 쓰기 가용성이 중단될 수 있어, Cloudflare는 모든 복제본이 쓰기에 참여하고 타임아웃으로 진행이 멈추지 않는 QuePaxa 기반의 Meerkat을 만들었다. Meerkat은 아직 실험 단계이며, 우선 데이터베이스 리더십이나 리소스 배치처럼 작은 규모의 내부 컨트롤 플레인 상태를 관리하는 데 사용될 예정이다. ## 글로벌 컨트롤 플레인 데이터의 필요성 - Cloudflare의 여러 서비스는 전 세계 데이터센터에 분산된 머신에서 동일한 제어 상태를 읽고 수정해야 한다. - 대표적인 컨트롤 플레인 데이터는 다음과 같다. - AI 모델 인스턴스 등 리소스의 배치 정보 - 데이터베이스에서 쓰기를 수행할 수 있는 머신을 나타내는 리더십 정보 - 네트워크 단절, 데이터센터 장애, 서버 중단, 큐 포화, 케이블 절단 등 인터넷 환경의 불확실성에도 시스템이 동작해야 한다. - 따라서 다음 두 조건을 동시에 만족하는 데이터 시스템이 필요하다. - 여러 클라이언트가 서로 모순되지 않는 상태를 읽는 강한 일관성 - 일부 머신이나 네트워크 링크가 실패해도 읽기와 쓰기가 가능한 장애 내성 ## 선형화 가능성으로 대표되는 강한 일관성 - 일관성 모델은 동시 읽기와 쓰기에서 시스템이 허용하는 동작 범위를 정의한다. - 약한 일관성에서는 여러 노드에 도착한 쓰기 순서가 재배열될 수 있다. - 더 강한 모델에서는 쓰기 순서는 유지되더라도 읽기가 서로 다른 시점의 값을 볼 수 있다. - 가장 강한 모델인 **선형화 가능성(linearizability)** 은 실제 시간 순서에 맞춰 연산이 실행된 것처럼 보이게 한다. - 어떤 쓰기가 완료된 뒤의 읽기는 반드시 그 쓰기 결과를 볼 수 있다. - 프로그래머는 분산 저장소를 단일 스레드 머신의 메모리처럼 추론할 수 있다. - Meerkat 위에 구축되는 키-값 저장소는 선형화 가능성뿐 아니라 직렬성(serializability)도 제공할 예정이며, 직렬성에 대한 자세한 내용은 후속 글에서 다룬다. ## 요구되는 장애 내성 - 시스템은 전체 머신 수가 `2f + 1`일 때 최대 `f`개의 장애를 감당하는 것을 목표로 한다. - 다음 조건이 유지되면 어느 데이터센터의 클라이언트에서도 읽기와 쓰기가 가능해야 한다. - 전체 머신의 과반수가 살아 있고 서로 통신할 수 있다. - 클라이언트가 과반수의 활성 머신과 연결된 머신 하나에 접속할 수 있다. - 이 조건은 단일 머신 장애나 하나의 네트워크 링크 성능 저하만으로 전체 시스템의 가용성이 떨어지지 않아야 함을 의미한다. - 시스템은 다음과 같은 장애에서도 올바른 상태를 유지해야 한다. - 머신 충돌 및 재시작 - 네트워크 장애와 지연 - 데이터센터 장애 - 네트워크 품질 저하 - 한편 공격자가 악의적으로 잘못된 메시지를 보내는 **비잔틴 장애**는 Raft와 마찬가지로 처리 대상에서 제외한다. - 안전성의 핵심은 최신 상태를 가진 두 머신이 서로 다른 세계를 인식하지 않도록 하는 것이다. 예를 들어 한 머신이 `key1=1`, 다른 머신이 `key1=2`라고 판단하는 상황을 허용하지 않는다. ## Raft가 광역 네트워크에서 겪는 한계 - Raft는 한 번에 하나의 리더만 쓰기를 수행할 수 있도록 한다. - 리더가 충돌하거나 네트워크 지연으로 사실상 접근 불가능해지면 다음 과정이 필요하다. - 다른 복제본이 리더의 실패를 타임아웃으로 감지 - 새로운 리더 선출 - 새 리더가 활동을 시작할 때까지 쓰기 중단 - 인터넷 전반에 걸친 Cloudflare 네트워크에서는 지연 시간이 일정하지 않기 때문에 타임아웃 값을 적절히 설정하기 어렵다. - 타임아웃이 너무 짧으면 정상적인 지연을 장애로 오인하고, 너무 길면 실제 장애 이후 복구가 늦어진다. - Cloudflare는 리더를 사용할 수 없어 합의 기반 시스템이 중단된 여러 장애를 경험했으며, 이것이 새로운 합의 서비스 개발의 배경이 되었다. ## QuePaxa 기반 Meerkat - Meerkat은 EPFL 연구진이 2023년에 발표한 합의 알고리즘 **QuePaxa**를 기반으로 한다. - Raft와 달리 QuePaxa에서는 모든 복제본이 항상 쓰기를 수행할 수 있다. - 특정 리더가 장애를 일으켰을 때 새 리더 선출을 기다리느라 전체 진행이 멈추지 않는다. - 타임아웃 때문에 합의 진행이 중단되지 않는 특성은 지연이 불규칙한 광역 네트워크에 적합하다. - Meerkat은 합의 로그를 제공하고, 그 위에 다음과 같은 애플리케이션을 구축한다. - 트랜잭션 키-값 저장소 - 분산 임대(lease) 및 잠금 시스템 - 데이터베이스 리더십 관리 - Cloudflare는 이를 글로벌 규모에서 산업적으로 배포하는 최초의 QuePaxa 사례가 될 것으로 보고 있다. ## 현재 개발 단계와 적용 범위 - Meerkat은 아직 개발 중인 실험적인 서비스다. - 초기에는 대규모 사용자 데이터가 아니라 작은 컨트롤 플레인 상태를 관리하는 데 집중한다. - 즉시 외부 공개 서비스로 제공하지 않고 Cloudflare 내부 전용으로 운영할 계획이다. - 이번 글은 Meerkat의 배경과 요구사항을 소개하고, 이후 합의 로그와 그 위에 구축되는 저장소 및 리스 시스템에 관한 후속 글의 기반을 마련한다. Meerkat의 핵심 설계 방향은 리더 장애와 고정된 타임아웃에 의존하지 않는 합의를 통해, 글로벌 네트워크에서도 선형화 가능한 데이터와 높은 쓰기 가용성을 함께 확보하는 것이다. 다만 실제 운영에서는 과반수 연결 조건과 비잔틴 장애를 처리하지 않는다는 한계를 함께 고려해야 한다.

원문 읽기(새 탭에서 열림)
분산 시스템fault-tolerancekey-value-storequepaxa+4
gitlab4분 읽기큐레이션 요약

GitLab 패치 릴리스: 19.1.2, 19.0.4, 18.11.7 | GitLab 문서

2026년 7월 8일 GitLab은 CE/EE용 패치 버전 19.1.2, 19.0.4, 18.11.7을 출시했다. 이번 릴리스는 XSS·HTML 인젝션·권한 우회·자격 증명 노출 등 여러 보안 취약점과 버그를 수정했으며, 자체 호스팅 사용자는 즉시 업그레이드하는 것이 권장된다. GitLab.com은 이미 패치가 적용됐고, GitLab Dedicated 고객은 별도 조치가 필요 없다. ## 패치 릴리스와 업그레이드 권고 - 패치 릴리스는 정기 릴리스와 고위험 취약점에 대응하는 비정기 긴급 패치로 나뉜다. - 정기 패치는 매월 둘째·넷째 수요일에 배포된다. - 영향을 받는 모든 자체 관리형 설치 환경은 Omnibus, 소스 코드, Helm Chart 등 배포 방식과 관계없이 최신 패치 버전으로 업그레이드해야 한다. - 보안 취약점 상세 이슈는 수정 버전 출시 후 90일이 지나면 공개된다. ## 취약점: XSS와 HTML 인젝션 - **CVE-2026-6896** - GitLab EE의 취약점 증거 테이블 렌더러에서 사용자 입력 sanitization이 충분하지 않았던 문제다. - Developer 권한의 인증 사용자가 다른 사용자의 브라우저 세션에서 임의 스크립트를 실행할 수 있었다. - CVSS 8.7로 이번 릴리스에서 가장 심각한 취약점 중 하나다. - EE 13.11 이후 버전 중 18.11.7, 19.0.4, 19.1.2 이전 버전에 영향을 준다. - **CVE-2026-13320** - CE/EE의 Wiki 마크업 렌더링 과정에서 HTML 인젝션이 가능했던 문제다. - 인증 사용자가 다른 사용자의 브라우저 세션에서 스크립트를 실행할 수 있었다. - CVSS 7.3이며, 높은 권한과 특정 조건이 필요하다. - CE/EE 15.7 이후 버전 중 각 패치 버전 이전 릴리스가 영향을 받는다. ## 자격 증명 및 저장소 보안 문제 - **CVE-2026-11827** - EE 저장소 미러링 기능의 권한 검사가 부족했다. - Maintainer 권한 사용자가 다른 사용자의 저장된 자격 증명을 획득할 수 있었다. - CVSS 4.9이며, EE 9.5 이후 버전에 영향을 준다. - **CVE-2025-12506** - Git 태그·브랜치 이름 해석이 모호하게 처리되는 문제다. - 공격자가 웹 인터페이스에 표시되는 저장소 내용과 다운로드 가능한 실제 내용이 다르게 보이는 저장소를 만들 수 있었다. - CE/EE 16.5 이후 버전에 영향을 주며 CVSS는 3.5다. ## 권한 검증 및 정보 노출 문제 - **CVE-2026-8472** - EE Work Items 기능에서 비공개 프로젝트의 메타데이터 접근 권한 검사가 누락됐다. - 최소 권한을 가진 인증 사용자가 비공개 프로젝트의 Work Item 정보를 읽을 수 있었다. - CVSS 4.3이다. - **CVE-2026-7492** - 커밋 토론 표시와 프로젝트 간 참조 페이지에서 권한 검사가 제대로 이뤄지지 않았다. - 비인증 사용자가 비공개 프로젝트의 존재 여부를 추론할 수 있었다. - CE/EE에 영향을 주며 CVSS는 4.3이다. - **CVE-2026-13151** - EE 그룹 수준 설정에 대한 권한 검사가 부정확했다. - 인증 사용자가 자신의 권한 범위를 넘어 그룹 설정을 수정할 수 있었다. - CVSS 2.7이며 GitLab 내부에서 발견됐다. - **CVE-2026-6352** - EE의 컴플라이언스 위반 관리 GraphQL 작업에서 권한 검사가 부족했다. - Auditor 수준 사용자가 컴플라이언스 위반 기록을 수정할 수 있었다. - CVSS 2.7이다. ## 버그 수정 및 기술 변경 ### 19.1.2 - OAuth 애플리케이션 등록 및 생성 시 `organization_id`를 설정하도록 수정했다. - 제약 조건 검증 전에 `oauth_applications`의 `NULL organization_id` 값을 보완하는 백필을 추가했다. - Go 버전을 1.25.11로 업데이트했다. - 멀티 아키텍처 태그를 레거시 레지스트리 경로에서 처리할 때 발생하던 HTTP 500 오류를 수정했다. - 외부 에이전트 흐름에서 커밋 작성자와 커미터의 신원을 사용하도록 개선했다. - ClickHouse 23.x에서 `ci_finished_builds` 엔진 교체가 동작하도록 수정했다. - Duo Workflow 이벤트 조회를 최신 체크포인트로 제한하고 커서 페이지네이션을 적용했다. - Developer가 작성한 Merge Request의 승인 규칙 재정의 회귀 문제를 수정했다. - 커밋 설명을 지나치게 미리 가져오면서 발생하던 커밋 페이지 메모리 누수를 해결했다. - 더 이상 필요하지 않은 `ActiveUserCountThresholdWorker` cron 스케줄을 제거했다. - 레지스트리 인증, OAuth 처리, 빌더 이미지 리비전 등 관련 구성도 백포트 및 조정했다. ### 19.0.4 및 18.11.7 - 19.0.4에도 OAuth 애플리케이션 등록 시 `organization_id`를 설정하는 수정이 백포트됐다. - CI_JOB_TOKEN을 이용한 레지스트리 인증 방식과 같은 일부 수정 사항이 19.0 안정화 브랜치에 반영됐다. - 18.11.7은 위 보안 취약점들이 수정된 18.11 계열의 권장 패치 버전이다. ## 실용적인 권장 사항 자체 호스팅 GitLab 운영자는 현재 지원 중인 계열에 맞춰 **19.1.2, 19.0.4, 18.11.7 중 하나로 즉시 업그레이드**하는 것이 좋다. 특히 EE에서 저장소 미러링, Work Items, 컴플라이언스 관리, 취약점 증거 렌더링을 사용하는 환경은 패치 적용 전까지 권한과 외부 입력 처리 기능을 우선 점검해야 한다.

원문 읽기(새 탭에서 열림)
gitlabGraphQLoauthcross-site-scripting+4
gitlab5분 읽기큐레이션 요약

AI 에이전트를 활용해 GitLab의 레이트 리미팅을 마이그레이션한 방법

GitLab은 3명의 엔지니어와 AI 에이전트를 활용해 레거시 애플리케이션·Rack 기반 레이트 리미팅을 `labkit-ruby` 단일 구현으로 통합했다. 에이전트는 코드 탐색, 사양 작성, 반복적인 구현과 테스트에는 효과적이었지만, 아키텍처 결정·점진적 롤아웃·관측성 설계·최종 판단은 여전히 사람의 책임이었다. 프로젝트의 성공을 결정한 것은 에이전트 자체보다 명확한 작업 루프, 작은 변경 단위, 점진적 배포, 그리고 실패를 되돌릴 수 있는 운영 체계였다. ## 레거시 레이트 리미팅 통합의 목표 - GitLab에는 다음 두 가지 레이트 리미팅 경로가 수년간 공존했다. - 애플리케이션 수준의 `Gitlab::ApplicationRateLimiter` - Rack 수준의 별도 레이트 리미터 - 목표는 두 시스템을 `labkit-ruby`의 단일 구현으로 통합하는 것이었다. - 새로운 구현은 다음 조건을 만족해야 했다. - 모든 요청에 적용될 만큼 안정적일 것 - 동작을 관측하고 테스트할 수 있을 것 - 장애 발생 시 되돌릴 수 있을 것 - 모놀리스와 다른 환경에서 동일하게 운영할 수 있을 것 - 기존 시스템에는 121개의 레이트 리미팅 키가 존재했다. ## 3명으로 구성된 포드와 AI 에이전트의 역할 - 포드는 세 명의 GitLab 엔지니어를 중심으로 구성됐다. - 모놀리스 측 구현과 롤아웃 담당 - `labkit-ruby`와 아키텍처 담당 - 범위 관리와 초기 gem 코드 작성 담당 - AI 에이전트는 다음 작업을 수행했다. - 코드와 기존 맥락 분석 - 기술 사양 초안 작성 - 범위가 제한된 변경 구현 - 테스트 작성 - 머지 리퀘스트 사전 검토 - GitLab Duo Code Review도 머지 리퀘스트의 품질 검토에 활용됐다. - 사람은 다음을 직접 맡았다. - 작업 범위 결정 - 아키텍처 설계 - 배포 및 롤아웃 판단 - 최종 리뷰와 승인 ## 사양-구현-검증 반복 루프 - 팀은 다음과 같은 엄격한 순서를 적용했다. 1. 에픽과 기존 코드 읽기 2. 사양 작성 3. 적대적 리뷰로 사양의 문제점 검토 4. 차단 이슈가 해결된 뒤 구현 5. 명시적인 증거를 바탕으로 검증 6. 머지 리퀘스트에 대한 적대적 리뷰 7. 필요 시 사람에게 에스컬레이션 8. 머지 - 적대적 리뷰는 최대 두 번의 해결 라운드까지만 허용하고, 이후에는 사람의 판단을 받도록 했다. - 프로젝트에서는 14개의 번호가 매겨진 사양과 30개가 넘는 `labkit-ruby` 머지 리퀘스트가 만들어졌다. - 레거시 코드처럼 맥락 파악과 반복 검증이 중요한 작업에서는 이처럼 제한된 루프가 에이전트 활용에 적합했다. ## 단계적 롤아웃과 에이전트가 잘한 작업 - 첫 번째 코호트에서는 트래픽이 많은 5개 키를 다뤘다. - `pipelines_create` - `notes_create` - `user_sign_in` - 그 외 주요 키 - 트래픽 비율을 `1% → 10% → 50% → 100%`로 단계적으로 높였고, 2026년 5월 5일 100% 배포를 완료했다. - 기존 `ApplicationRateLimiter`와 새 구현의 결과가 일치하는지 확인했지만, 단순히 불일치가 없다는 사실만으로 성공을 판단하지 않았다. - 실제로 제한에 걸릴 정도의 트래픽이 발생하지 않았을 가능성도 있기 때문이다. - 두 번째 코호트에서는 모놀리스 83개와 EE 12개를 포함한 95개 호출 지점을 두 개의 기능 플래그로 통합했다. - 이 작업을 수작업으로 했다면 약 95개의 플래그 변경과 190개의 YAML 수정이 필요했을 수 있지만, 에이전트는 이런 반복적인 코드베이스 전반의 변경에 특히 강했다. ## 관측성은 있었지만 실패 유형을 구분하지 못함 - 두 번째 코호트는 며칠간 섀도 모드에서 기존 구현과 비교되었고, 대체로 일치했다. - 그러나 강제 적용 모드로 전환한 뒤 인증되지 않은 일부 경로에서 식별자가 조용히 유실되는 문제가 발생했다. - 원인은 세 개의 `String` 값이 두 개의 원시 슬롯에 압축되면서 잘못된 값이 식별자를 덮어쓴 구조적 충돌이었다. - 일부 사용자는 짧은 시간 동안 일반적인 오류 메시지를 받았다. - 비교 시스템은 해당 키의 불일치를 이미 감지했지만, 대시보드가 다음을 구분하지 못했다. - 정상적인 동작 차이 - 데이터 구조 충돌 - 사용자에게 영향을 줄 수 있는 치명적 불일치 - 팀은 즉시 강제 적용 플래그를 끄고, 이틀 뒤 긴급 수정 사항을 배포했다. - 문제는 사양, 적대적 리뷰, 구현, 코드 리뷰, 점진적 롤아웃을 모두 통과했으므로, 단순히 “에이전트가 위험하다”기보다는 관측성이 충분히 세분화되지 않았던 것이 핵심 교훈이었다. ## 전체 키 인벤토리 관리의 실패 - 처음에는 다섯 개 코호트로 마이그레이션을 끝낼 계획이었다. - 마스터 브랜치 감사 과정에서 누락된 항목이 발견되어 여섯 번째 코호트를 추가했다. - Claude가 놓친 항목에는 다음이 포함됐다. - EE 전용 `notification_emails` - 일부 EE 레지스트리 항목 - 웹훅 관련 키 3개 - 1초 미만 주기의 `partner_*` 키 3개 - 고립된 어댑터 행 - 총 121개 키 중 17개가 초기 코호트에서 빠져 있었다. - 각 항목이 특정 코호트에 쉽게 들어가지 않는 이유는 있었지만, 목록에서 보이지 않아도 될 이유는 없었다. - 근본적인 실수는 에이전트와 사람이 전체 키 인벤토리 대비 진행 상황을 지속적으로 집계하도록 요구하지 않았다는 점이다. ## Redis 인프라 병목과 운영 판단 - `redis-cluster-ratelimiting`은 4개 샤드 클러스터로 운영됐다. - 마이그레이션으로 사용량이 증가하면서 기존에 알려져 있던 인프라 병목이 다시 나타났다. - 팀은 `maxclients`를 단계적으로 높였지만, 연결 수를 100,000까지 밀어붙이지 않고 75,000에서 중단했다. - 더 많은 연결을 허용하면 각 프라이머리의 CPU가 포화될 수 있었기 때문이다. - 각 샤드는 명령 실행에 하나의 코어를 사용했고, 수직 확장으로 해결할 여지도 제한적이었다. - 따라서 에이전트가 코드를 생성하더라도, 실제 배포 속도와 범위는 인프라 용량과 운영자의 판단에 의해 결정됐다. ## AI 에이전트가 바꾼 병목 - 에이전트 덕분에 코드 작성 자체는 더 이상 가장 느린 단계가 아니었다. - 대신 병목이 다음 영역으로 이동했다. - 사람의 리뷰 처리 용량 - 롤아웃 시점과 범위에 대한 판단 - 운영 중인 시스템을 주의 깊게 관찰하는 능력 - 에이전트는 요청하면 95개의 기능 플래그 같은 반복 작업도 만들어내지만, 그런 설계가 실제로 필요한지는 판단하지 못한다. - 예를 들어 코호트 1 이후 팀은 레이트 리미트마다 별도 기능 플래그를 두는 방식이 과도하다고 판단해 이후 마이그레이션에서는 적용하지 않기로 했다. - 에이전트와 협업하는 방법 자체도 학습이 필요했으며, 때로는 에이전트와 반복적으로 막혀 직접 처리하는 편이 빠르다고 느끼는 순간도 있었다. ## 최종 상태와 실용적인 교훈 - 2026년 6월 중순 기준으로 여섯 개 코호트가 모두 100% 롤아웃됐다. - `ApplicationRateLimiter`의 121개 키가 새 프레임워크를 통해 동작하게 되었고, 감사로 결과를 확인했다. - 이 사례에서 권장할 만한 방식은 다음과 같다. - 에이전트에는 반복적이고 범위가 명확한 변경을 맡긴다. - 아키텍처, 위험 허용 수준, 배포 중단 기준은 사람이 결정한다. - 전체 마이그레이션 대상을 인벤토리로 관리하고 누락 여부를 자동 검증한다. - 단순한 불일치 감지를 넘어 실패 원인과 심각도를 구분하는 관측성을 구축한다. - 기능 플래그와 점진적 롤아웃으로 즉시 되돌릴 수 있게 한다. - 코드 생성 속도가 빨라져도 리뷰와 운영 관찰에 필요한 사람의 시간을 충분히 확보한다.

원문 읽기(새 탭에서 열림)
AI 에이전트옵저버빌리티gitlab-duo-agent-platformredis+4
cloudflare5분 읽기큐레이션 요약

Cloudflare, 영국 정부의 사이버 복원력 서약에 자랑스럽게 동참

Cloudflare는 영국 정부의 자발적 사이버 복원력 서약(Cyber Resilience Pledge) 창립 서명기관으로 참여하며, 보안의 대중화·경영진 책임·투명성이라는 원칙을 지지한다고 밝혔다. 이 서약은 기업이 이사회 차원에서 사이버 보안을 관리하고, 공급망 전체의 보안 수준을 높이며, 기본적인 기술 통제를 갖추도록 요구한다. Cloudflare는 보안이 특정 상품이나 대기업만의 영역이 아니라 모든 조직에 기본값으로 제공되어야 하며, 집단 방어를 통해 인터넷 전체의 복원력을 높여야 한다고 주장한다. ## 영국 사이버 복원력 서약의 배경 - 영국 정부가 조직의 기본적인 사이버 보안 거버넌스와 이사회 책임을 강화하기 위해 자발적 프레임워크를 출범시켰다. - 주요 원칙은 다음과 같다. - 보안 기술과 보호 기능의 대중화 - 경영진 및 이사회의 책임 강화 - 사고와 대응 과정에 대한 투명성 확대 - 공급망 전반의 보안 기준 향상 - Cloudflare는 이 서약을 새로운 의무라기보다, 지난 10여 년간 추진해 온 보안 철학을 영국 정부가 공식적으로 확인한 것으로 평가한다. - Cloudflare는 영국 과학·혁신·기술부(DSIT), 국가사이버보안센터(NCSC) 등과 협력해 영국의 디지털 경제 보안을 강화해 왔다. ## 증가하는 사이버 위협과 AI의 영향 - Cloudflare는 2026년 1분기에 전 세계 네트워크에서 하루 평균 2,340억 건의 사이버 위협을 차단했다. - 최근에는 최대 31.4Tbps 규모의 초대형 DDoS 공격을 완화했다. - 2025년 말 기준 영국은 전 세계에서 DDoS 공격 표적이 많은 국가 6위로 올라섰다. - 금융 서비스, 항공, 지방정부 인프라 등에서 애플리케이션 계층 공격이 증가하고 있다. - 영국 사이버 보안 침해 조사에 따르면 지난 1년간 사이버 사고를 경험한 비율은 기업 43%, 자선단체 28%였다. - 프런티어 AI 모델은 공격자의 진입 장벽을 낮추고 다음과 같은 공격을 자동화·고도화하고 있다. - 취약점 자동 탐색 - 대규모 공격 시도 - 더욱 설득력 있는 피싱 캠페인 - 이에 따라 방어 체계도 머신러닝 기반 공격 평가, Zero Trust 접근 제어 등으로 위협 변화에 맞춰 빠르게 발전해야 한다. ## 사이버 복원력은 비즈니스의 기본 요건 - 고객은 공격이나 장애 상황에서도 서비스가 지속적으로 제공되고, 빠르게 응답하며, 신뢰할 수 있기를 기대한다. - 사이버 복원력은 단순히 사고 발생 후 복구하는 능력이 아니다. - 복원력 있는 시스템은 다음을 수행해야 한다. - 위협 신호를 사전에 탐지 - 공격과 장애를 서비스 전체로 확산시키지 않고 흡수 - 운영 과정에서 얻은 교훈을 바탕으로 지속적으로 개선 - 따라서 보안 통제는 복원력을 실현하는 핵심 기반이며, 보안과 복원력은 분리할 수 없는 개념이다. ## 보안을 상품 등급이 아닌 기본값으로 제공 - Cloudflare는 기본적인 보안 기능을 모든 조직이 사용할 수 있어야 한다고 주장한다. - 모든 사용자에게 트래픽 암호화에 필요한 SSL 인증서를 제공했고, 무료 요금제에도 다음 기능을 포함한다. - 공격 규모와 관계없는 무제한 DDoS 보호 - 글로벌 CDN - DNSSEC - 네트워크 전반에 양자내성 암호화를 도입하는 등 인터넷 암호화 기술도 발전시키고 있다. - Project Galileo와 Athenian Project를 통해 취약한 목소리와 공공기관을 보호한다. - 중소기업, 지방정부, 공공서비스, 스타트업도 보안 수준을 높일 수 있어야 서약의 목표인 “사이버 복원력의 최저선”을 높일 수 있다는 취지다. ## 네트워크 전체를 위협 탐지 센서로 활용 - Cloudflare는 전 세계 13,000개 이상의 네트워크와 직접 피어링하며 공격 패턴을 대규모로 관찰한다. - 한 지역에서 발견한 위협 정보와 공격 패턴을 수초 내 네트워크 전체의 방어 규칙에 반영할 수 있다. - 예를 들어 싱가포르 고객을 공격한 위협을 분석해 얻은 규칙이 곧바로 영국 셰필드의 고객 보호에도 활용될 수 있다. - 대규모 가시성은 공격 탐지, 위험 점수 산정, 대응 속도를 개선하고 고객 전체의 복원력을 높인다. ## 스스로 먼저 검증하는 ‘고객 제로’ 원칙 - Cloudflare는 고객에게 제공하는 보안 제품과 인프라를 자체 시스템 보호에도 사용한다. - 내부 애플리케이션 접근에는 다음 통제를 적용한다. - Cloudflare Access와 Gateway - 하드웨어 키 기반 다중 인증 - 기기 보안 상태 점검 - 암호학적으로 검증된 신원 토큰 - 모든 보안 계층을 내부 환경에서 먼저 시험하고, 운영 경험을 제품과 네트워크 개선에 반영한다. - 보안을 특정 팀이나 제품의 책임이 아니라 조직 전반의 운영 방식으로 통합한다. ## 투명한 공개와 사고 이후의 개선 - 사고나 제로데이 취약점이 발생하면 기술적 사후 분석(postmortem)을 공개한다. - 침해 지표(IoC)와 아키텍처 회고를 공유해 다른 조직과 보안 커뮤니티가 동일한 위협에 대비할 수 있도록 한다. - 투명한 공개만으로 끝내지 않고, 사고를 시스템 개선의 계기로 활용한다. - 대규모 장애 이후 진행한 “Code Orange” 작업에서는 다음을 추진했다. - 장애가 전체 시스템으로 번지지 않도록 “작게 실패하는(fail small)” 구조 설계 - 안전한 구성 변경을 강제하는 도구 개발 - 보안 모범 사례의 자동화 - 목표는 같은 유형의 장애가 반복되지 않도록 구조적 원인을 제거하는 것이다. ## 서약이 강조하는 조직 차원의 책임 - 서약은 이사회 책임과 거버넌스, 공급망 보안, 영국 Cyber Essentials 인증과 관련된 기술 요건을 기업이 수용하도록 요구한다. - 대부분의 침해 사고는 패치되지 않은 시스템, 취약한 접근 제어, 부실한 공급업체 관리처럼 이미 알려진 문제에서 발생한다. - 따라서 고도화된 기술만큼 다음과 같은 기본 통제의 광범위한 적용이 중요하다. - 정기적인 패치와 취약점 관리 - 강력한 인증 및 접근 권한 통제 - 공급업체 보안 검토 - 지속적인 모니터링 - 이사회 차원의 위험 관리와 책임 부여 영국의 서약은 사이버 보안을 IT 부서의 단독 과제가 아니라 경영진과 공급망 전체가 함께 책임져야 할 사업 과제로 끌어올린다는 점에서 의미가 있다. 조직은 우선 패치, 인증, 접근 제어, 공급업체 관리 같은 기본 통제를 강화하고, 사고를 숨기기보다 투명하게 공유하며, 보안을 모든 서비스의 기본값으로 설계하는 것이 바람직하다.

원문 읽기(새 탭에서 열림)
cloudflare제로 트러스트post-quantum-cryptographycybersecurity+3
google3분 읽기큐레이션 요약

협업의 힘: 교통 혼잡을 줄이는 방법

내비게이션 앱이 일부 차량의 경로만 분산해도 도시 전체의 교통 흐름과 배출량을 개선할 수 있다는 연구다. Google Research는 미국 10개 도시에서 혼잡 구간을 피해 비슷한 시간이 걸리는 대체 경로를 안내한 결과, 대상 도로의 속도와 연료 효율이 유의미하게 향상되는 것을 확인했다. 이는 개인별 최적 경로를 넘어, 네트워크 전체를 고려한 협력적 교통 관리가 가능함을 보여준다. ## 네트워크 단위 교통 최적화의 필요성 - 차량과 도로는 사람·물류 이동과 경제 활동을 뒷받침하지만, 교통 혼잡과 환경 비용도 크다. - 운전자는 평균적으로 평생 약 2.6년을 도로에서 보내며, 승용차와 밴은 전 세계 CO2 배출량의 약 10%를 차지한다. - 기존 내비게이션 서비스는 개별 운전자에게 가장 빠른 경로를 제공하는 데 집중했지만, 모든 차량의 경로를 고려한 시스템 전체 최적화는 충분히 구현되지 않았다. - 연결 차량, 스마트시티 인프라, 자율주행차의 확산으로 교통 흐름을 측정하고 조정할 수 있는 기반이 마련되고 있다. ## 혼잡 구간을 분산한 실험 설계 - 미국 주요 도시 10곳에서 6개월간 실험을 진행했다. - 각 도시에서 반복적으로 혼잡이 발생하거나 교통량이 높은 도로 구간 약 100개를 선정했다. - 실험일에는 Google Maps의 경로 알고리즘이 해당 구간의 비용을 높게 인식하도록 수정했다. - 대신 이동 시간이 비슷하고 도로 특성이 유사한 대체 경로를 우선 안내해 차량을 여러 도로로 분산했다. - 개별 차량을 무작위로 나누는 방식이 아니라, 도시 전체를 대상으로 다음 날에는 실험 경로, 그다음 날에는 기존 경로를 적용하는 스위치백(crossover) 설계를 사용했다. - 실제로 경로가 변경된 관측 차량은 전체의 2% 미만이었다. 즉, 소수의 차량만 조정해 전체 네트워크 효과를 측정했다. ## 교통 속도와 연료 효율 개선 - 분석에는 도시 단위와 시간대별 효과를 함께 추정하는 계층적 베이지안 모델을 사용했다. - 혼잡 대상으로 지정한 도로에서는: - 주행 속도가 중앙값 기준 약 2% 증가했다. - 연료 소비율은 약 0.5~1.0% 감소했다. - 경로 변경으로 영향을 받은 전체 도로 구간에서는: - 주행 속도가 중앙값 기준 약 0.35% 증가했다. - 출퇴근 등 교통량이 많은 시간대에는 약 0.5% 증가했다. - 이러한 개선은 통계적으로 유의미했으며, 도시 규모에 따라 도시당 연간 수천 톤의 CO2e 배출 저감으로 이어질 가능성이 있다. ## 차량 흐름 분산이 만든 네트워크 효과 - 차량을 단순히 한 도로에서 다른 도로로 옮긴 것이 아니라, 특정 병목 구간에 집중되던 교통량을 여러 주변 도로로 분산했다. - 대체 경로에 차량이 추가되었지만, 각 도로가 감당한 증가량은 상대적으로 작아 전체적인 평균 속도와 배출량이 개선됐다. - 애틀랜타 사례에서는 도심을 관통하는 중앙 고속도로의 차량이 주변부의 여러 도로로 분산됐다. - 효과는 해당 내비게이션 앱 사용자에게만 국한되지 않았다. 혼잡 구간이 완화되면서 앱을 사용하지 않는 운전자도 이동 시간 단축의 혜택을 받을 수 있었다. ## 향후 교통 관리로의 확장 - 이번 연구는 내비게이션 앱을 도시 교통을 능동적으로 조정하는 도구로 활용할 수 있음을 보여준다. - 향후에는 다음과 같은 시스템으로 확장할 수 있다. - 실시간 교통 신호 제어 - 도로 네트워크 전체의 동적 경로 최적화 - 차량·도로 인프라·스마트시티 센서 간 협력 - 자율주행차를 포함한 실시간 교통 수요 분산 - 다만 이번 결과는 비교적 단순한 우회 안내에 기반한 것이므로, 더 복잡한 도시 환경과 장기적인 운전자 경로 선택 변화에 대한 추가 검증이 필요하다. 실용적으로는 모든 운전자에게 무조건 가장 짧은 경로를 제시하기보다, 일부 차량에 비슷한 시간의 대체 경로를 분산 안내하는 방식이 효과적이다. 개인의 이동 시간을 크게 희생하지 않으면서도 도시 전체의 정체와 배출량을 줄일 수 있다는 점이 이 연구의 핵심적인 시사점이다.

원문 읽기(새 탭에서 열림)
network-aware-routingtraffic-optimizationnavigation-appssmart-cities+2
discord5분 읽기큐레이션 요약

Discord 패치 노트: 2026년 7월 7일

Discord의 2026년 7월 7일 패치 노트는 앱 성능·연결 속도 개선과 플랫폼별 버그 수정을 다룬다. iOS의 React Native Fabric 전환으로 앱 초기화 시간이 약 20% 단축됐고, 세션 연결 p95/p99 시간도 약 100ms 줄었다. 또한 메시지 전달 시 `@silent` 사용, 모든 서버에서 채널 고정 지원 등 사용성 기능이 확대됐다. ## 앱 성능과 안정성 개선 - iOS를 React Native의 New Architecture인 **Fabric**으로 이전했다. - 일반적인 앱 초기화 시간이 약 20% 개선됐다. - 향후 Android와 iOS의 성능·신뢰성 개선 프로젝트를 확장할 기반을 마련했다. - 세션 시작 로직의 설정값을 변경해 세션 연결 시간의 p95/p99를 약 100ms 단축했다. - Linux에서 NVIDIA GPU 사용 시 X11 연결이 점진적으로 누수되던 문제를 수정했다. - 장시간 실행 후 새 애플리케이션을 열 수 없게 되는 현상을 방지한다. - Windows에서 Discord가 시작 프로그램으로 자동 실행될 때 게임 창의 포커스를 빼앗던 문제를 수정했다. - 이제 백그라운드에서 조용히 실행된다. - 빠르게 두 번 새로 고친 뒤 데스크톱 클라이언트에서 마우스 클릭이 작동하지 않던 문제를 해결했다. ## 메시지 전달과 채널 사용성 - 메시지 전달 기능에서 `@silent`를 지원한다. - 새벽에 DM으로 메시지를 전달할 때 상대방에게 알림을 보내지 않을 수 있다. - 기존에는 Community 서버에서만 제공되던 **채널 고정(Channel Pinning)** 기능을 모든 서버로 확대했다. - 사용자가 자주 쓰는 채널을 개인적으로 채널 목록 상단에 배치할 수 있다. - Linux에서 GIF와 동영상이 반복 재생되지 않던 문제를 수정했다. - 반복 재생 처리가 운영체제별로 제대로 동작하도록 개선됐다. ## 데스크톱 인터페이스 및 프로필 수정 - 프로필 모달의 우측 상단 모서리와 배너 이미지가 어긋나던 문제를 해결했다. - 긴 검색어 입력 시 검색 드롭다운의 “결과 없음” 문구가 컨테이너 밖으로 넘치지 않도록 수정했다. - 작은 창에서 로그인 화면에 불필요한 스크롤바가 나타나고 로그인 박스가 중앙에서 벗어나던 문제를 고쳤다. - 프로필의 사용자 지정 상태 hover 표시가 사각형으로 보이거나 잘못 정렬되던 문제를 수정했다. - 최근 아바타 목록에서 일부 GIF 아바타가 깨져 다시 선택할 수 없던 문제를 해결했다. - 프로필 편집 중 “위젯 추가”를 눌러도 저장하지 않은 변경 사항이 사라지지 않도록 했다. - 사용자 지정 상태의 “24시간 후 삭제” 설정이 자정에 조기 만료되던 문제를 수정했다. - 일반 텍스트 입력창에서도 맞춤법이 틀린 단어를 우클릭하면 맞춤법 제안이 표시되도록 했다. - 검색 필터의 “이후(After)” 날짜가 필터 창을 다시 열 때마다 하루씩 앞당겨지거나 늦춰지던 문제를 해결했다. - 서버 프로필에서 기본 프로필로 전환할 때 tenure 배지 안내창이 잘못 표시되던 문제를 수정했다. - 다른 모달이 열린 상태에서 단축키로 Inbox를 열면 클라이언트가 잠기던 문제를 해결했다. - 배지 허브에서 Nitro나 Shop으로 이동할 때 기존 프로필 모달이 뒤에 남아 있던 문제를 수정했다. - 자신의 위시리스트에서 Nitro를 자신에게 선물할 수 있던 잘못된 흐름을 수정했다. - 이제 Nitro 구독 모달이 열린다. ## 모바일 앱 개선 - Android Nitro 탭에서 일부 기본 테마를 사용할 때 캐러셀 페이지 표시기가 보이지 않던 문제를 해결했다. - iOS 채널 목록을 스크롤할 때 화면이 흔들리거나 위치가 튀던 현상을 수정했다. - Android와 iOS에서 잘못된 `has:` 검색 필터 값이 유효한 필터로 처리되던 문제를 고쳤다. - iOS의 선물 수신자 선택 화면에 불필요한 색상 사각형이 표시되던 문제를 해결했다. - Android에서 닫을 수 없던 서버 애플리케이션 알림을 바깥 영역 터치나 뒤로 가기 버튼으로 닫을 수 있게 했다. - iOS에서 변경 중인 표시 이름 스타일이 전체 화면 프로필 미리보기에 반영되지 않던 문제를 수정했다. - iOS의 이벤트 카드와 Live 채널 알림에서 위치 텍스트가 카드 밖으로 넘치지 않도록 잘라서 표시한다. - 이미 가입한 서버의 초대 링크를 열 때 불필요한 Server Tag Adoption 절차로 이동하던 문제를 해결했다. - iPad 브라우저에서 서버 초대 링크를 열면 Discord는 실행되지만 초대 화면이 표시되지 않던 문제를 수정했다. - Android 프로필 사진 편집기에서 특정 테마를 사용할 때 “확대/축소”와 “회전” 텍스트 및 슬라이더가 보이지 않던 문제를 해결했다. - iOS 프로필 탭 전환 중 스크롤하면 콘텐츠가 잘리던 문제를 수정했다. - Android에서 친구 요청 수락 후 프로필의 통화·메시지 버튼 크기가 서로 다르게 표시되던 문제를 고쳤다. - iOS Shop 아이템 미리보기에서 프로필 미리보기 텍스트가 잠깐 나타났다가 사라지던 현상을 해결했다. - iOS에서 글자 크기를 키웠을 때 Nitro 혜택 설명이 잘리고 스크롤하기 어려웠던 문제를 수정했다. - iOS 알림 설정 화면이 푸시 알림을 이미 켠 뒤에도 계속 활성화를 요구하던 문제를 해결했다. ## 초대, 프로필, 이벤트 관련 수정 - iOS 채널 목록에 채널을 추가하라는 배너가 채팅 배경에 섞이지 않도록 구분선을 추가했다. - 프로필 카드와 상태 표시 요소의 모서리 및 정렬을 조정해 시각적 일관성을 높였다. - 예약 이벤트 카드와 Live 채널 안내 문구가 화면 가장자리를 넘지 않도록 처리했다. - 이미 가입한 서버 초대 링크가 잘못된 설정 흐름을 열지 않고 해당 서버로 바로 이동하도록 수정했다. ## 적용 방식 - 패치에 포함된 수정 사항은 모두 커밋되고 병합된 상태다. - 다만 플랫폼별 배포가 진행 중일 수 있어 모든 사용자에게 동시에 적용되지는 않을 수 있다. - 문제가 계속되면 Discord 커뮤니티의 격월 버그 메가스레드에 제보할 수 있다. 이번 업데이트는 대규모 신규 기능보다는 iOS 아키텍처 전환, 연결 속도 개선, 운영체제별 안정성 보강, 세부 UI 버그 수정에 초점이 맞춰져 있다. Discord를 사용하는 경우 앱을 최신 버전으로 업데이트하고, 특히 Linux·Windows·iOS에서 보고된 문제를 겪었다면 수정 여부를 확인하는 것이 좋다.

원문 읽기(새 탭에서 열림)
discordAndroidiOSLinux+3
aws4분 읽기큐레이션 요약

AWS 주간 요약: AWS에서 제공되는 Claude Sonnet 5, AI 에이전트를 위한 Amazon WorkSpaces, AWS 서비스 가용성 업데이트 등 (2026년 7월 6일) | Amazon Web Services

AWS는 이번 주 Claude Sonnet 5, AI 에이전트용 Amazon WorkSpaces, 로그 분석 최적화 OpenSearch 등 AI·인프라 관련 기능을 대거 공개했다. 특히 CloudFormation Express, EKS 버전 롤백, ACM의 ACME 지원처럼 개발·운영 속도와 안정성을 높이는 기능도 강화됐다. 동시에 여러 AWS 서비스와 기능이 유지보수 단계, 일몰 또는 지원 종료로 전환되므로 사용 중인 서비스의 마이그레이션 계획을 점검해야 한다. ## 주요 출시 및 업데이트 ### Graviton5 기반 Amazon EC2 C9g/C9gd - AWS Graviton5 프로세서를 탑재한 컴퓨팅 최적화 인스턴스다. - Graviton4 기반 인스턴스보다 최대 25% 향상된 컴퓨팅 성능을 제공한다. - 캐시 용량이 5배 커졌으며, 클라우드 프로세서 중 가장 빠른 메모리 성능을 제공한다. - C9gd는 로컬 NVMe 스토리지를 지원해 고성능 임시 데이터 처리에 적합하다. ### AWS CloudFormation Express 모드 - 인프라 배포 결과를 수초 내에 확인할 수 있도록 배포 흐름을 단축한다. - AI 에이전트와 개발자가 배포 결과를 빠르게 확인하고 반복 작업을 수행할 수 있다. - 모든 상용 AWS 리전에서 추가 비용 없이 제공된다. ### Amazon EKS Kubernetes 버전 롤백 - Kubernetes 클러스터 업그레이드 후 최대 7일 동안 이전 버전으로 되돌릴 수 있다. - 업그레이드 실패 시 클러스터를 새로 구축하지 않아도 된다. - Kubernetes 버전 업그레이드를 되돌릴 수 있는 저위험 작업으로 만들어 운영 안정성을 높인다. ### AWS Certificate Manager의 ACME 지원 - 표준 ACME 프로토콜을 사용해 퍼블릭 TLS 인증서 발급과 갱신을 자동화할 수 있다. - 기존 ACME 기반 도구 및 자동화 파이프라인과 연동하기 쉬워졌다. - 인증서 만료로 인한 서비스 중단 위험을 줄일 수 있다. ## AI 및 개발 생산성 기능 ### AWS에서 제공되는 Claude Sonnet 5 - Anthropic의 최신 Sonnet 모델로, 코딩·에이전트 작업·일반 업무를 대상으로 한다. - 대규모 코드베이스를 탐색하고 도구를 정확하게 호출할 수 있다. - 장시간 이어지는 에이전트 작업에서 상태를 유지하도록 설계됐다. - Sonnet 계열의 가격대에서 높은 수준의 추론 성능을 제공하는 것이 특징이다. ### AI 에이전트용 Amazon WorkSpaces - AI 에이전트가 관리형 WorkSpaces 환경에서 데스크톱 애플리케이션에 안전하게 접근하고 조작할 수 있다. - 기존 애플리케이션을 현대화하거나 별도의 맞춤형 통합을 구현하지 않아도 된다. - 레거시 GUI 애플리케이션을 AI 자동화 workflow에 포함할 수 있는 기반을 제공한다. - 정식 출시(GA) 단계로 제공된다. ### Amazon SageMaker AI 추론 확장 속도 개선 - 컨테이너 이미지 캐싱을 지원해 생성형 AI 모델의 scale-out 시간을 줄인다. - 추론 확장 이벤트에서 엔드투엔드 확장 속도가 최대 2배 빨라질 수 있다. - 트래픽 급증 시 새 추론 인스턴스를 준비하는 시간을 단축한다. ## 데이터 분석 및 모니터링 개선 ### 로그 분석에 최적화된 Amazon OpenSearch Service - 로그 분석 workload를 위해 별도로 설계된 새로운 엔진을 제공한다. - AWS 내부 벤치마크 기준 최대 4배 향상된 가격 대비 성능을 목표로 한다. - 로그 집계와 정밀한 전문 검색을 하나의 시스템에서 함께 수행할 수 있다. - 검색 기능과 분석 기능을 별도 시스템으로 분리해야 하는 부담을 줄인다. ### CloudWatch 로그 쿼리 기반 알람 - 로그 쿼리 결과에 직접 임계값을 설정해 알람을 만들 수 있다. - 기존처럼 먼저 메트릭 필터나 사용자 지정 메트릭을 생성할 필요가 없다. - 로그 분석과 장애 알림 설정을 하나의 workflow로 처리할 수 있다. ## AWS 서비스 가용성 변경 AWS는 서비스 또는 기능의 제공 상태가 바뀔 때 대체 서비스와 마이그레이션 지침을 제공한다. 2026년 6월 30일 기준으로 다음과 같은 변경이 발표됐다. ### 신규 고객 접근이 제한되는 유지보수 단계 2026년 7월 30일부터 신규 고객이 사용할 수 없게 되는 서비스 및 기능은 다음과 같다. - Amazon Bedrock Agents → Amazon Bedrock Agents Classic - Amazon Cognito Sync - Amazon Kendra - Amazon Q Business - AWS Directory Service – Simple AD - AWS IoT Device Defender – Detect - 2026년 8월 31일부터 신규 고객 접근 제한 - AWS Mainframe Modernization – Self-Managed Experience - AWS Management Console – myApplications - AWS Resource Groups – Group Lifecycle Events - AWS Service Catalog – Application Registry - AWS Systems Manager – Application Manager - SageMaker AI의 A2I, Clarify, Debugger, GeoSpatial, Ground Truth, Mechanical Turk, Model Monitor, Role Manager, Studio Lab ### 서비스 일몰(Sunset) 대상 - Amazon WorkSpaces – PCoIP - Amazon WorkSpaces – Pool - AWS Managed Services Advanced - AWS re:Post Private - Amazon SageMaker AI – Profiler ### 지원 종료 대상 2026년 6월 30일부로 다음 서비스의 지원이 종료됐다. - Amazon Chime SDK – Carrier Voice Focus - Amazon SageMaker AI – Ground Truth Plus ## 예정된 AWS 행사 - AWS Summits: - 2026년 하반기 각 지역에서 열리는 무료 클라우드·AI 행사다. - 최신 기술을 학습하고 커뮤니티와 교류할 수 있다. - AWS Community Days: - 커뮤니티가 직접 기획하고 운영하는 행사다. - 브라질에서는 AWS Community Day Belo Horizonte가 2026년 8월 22일 개최될 예정이다. - AWS Builder Center: - 개발자와 빌더가 솔루션을 공유하고 관련 콘텐츠 및 행사 정보를 확인할 수 있는 커뮤니티 공간이다. 사용 중인 AWS 서비스가 유지보수, 일몰 또는 지원 종료 대상인지 먼저 확인하고, 대체 서비스와 마이그레이션 일정을 미리 수립하는 것이 좋다. 신규 AI·인프라 프로젝트에서는 Claude Sonnet 5, CloudFormation Express, EKS 롤백, 로그 기반 CloudWatch 알람 등을 활용하면 개발 속도와 운영 안정성을 함께 높일 수 있다.

원문 읽기(새 탭에서 열림)
쿠버네티스AWSamazon-sagemakeramazon-eks+4
naver1분 읽기큐레이션 요약

[AI 해커톤 후기] 코드와 문서만 읽은 LLM은 어떻게 사람과 같은 팀을 1위로 골랐을까

이 글은 기술적 내용을 담은 본문이 아니라 NAVER D2 웹사이트의 메뉴와 저작권 정보로 구성되어 있습니다. `Hello world`, D2 News, About D2, NAVER Developers, DEVIEW, OpenSource, D2 STARTUP FACTORY 등의 항목이 나열되어 있으며, 별도의 주장이나 결론은 제시되지 않습니다. ### NAVER D2 관련 메뉴 - **Hello world**: 초기 또는 소개 성격의 메뉴로 보입니다. - **D2 News**: D2의 소식과 관련된 콘텐츠로 연결되는 항목입니다. - **About D2**: NAVER D2의 소개 정보를 제공하는 메뉴입니다. - **NAVER Developers**: NAVER 개발자 관련 자료와 서비스를 다루는 항목입니다. - **DEVIEW**: NAVER의 개발자 행사인 DEVIEW 관련 콘텐츠를 가리킵니다. - **OpenSource**: 오픈소스 프로젝트나 관련 자료를 제공하는 메뉴입니다. - **D2 STARTUP FACTORY**: 스타트업 지원 프로그램 또는 관련 조직을 소개하는 항목입니다. ### 저작권 정보 - 저작권자는 **NAVER Corp.**입니다. - 표기된 문구는 “Copyright © NAVER Corp. All Rights Reserved.”입니다. - 본문에는 각 메뉴에 대한 상세 설명, 기술적 주장, 사용 방법은 포함되어 있지 않습니다. 이 내용만으로는 기술 블로그 글의 주제나 결론을 파악하기 어렵고, 실제 요약을 위해서는 연결된 본문이나 원문 콘텐츠가 추가로 필요합니다.

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

이제 Worker 앞에 자체 캐시를 둘 수 있습니다

Cloudflare의 **Workers Cache**는 Worker 앞에 계층형 캐시를 배치해, 캐시 적중 시 Worker를 실행하지 않고 응답을 반환하는 기능이다. Wrangler 설정 한 줄과 기존 HTTP `Cache-Control` 헤더만으로 사용할 수 있으며, 캐시 적중 시 CPU 비용과 렌더링 지연을 줄인다. 서버 렌더링 애플리케이션은 정적 사전 생성과 매 요청 렌더링 사이에서, 필요할 때만 렌더링하고 결과를 캐시하는 세 번째 선택지를 얻게 된다. ## 서버 렌더링 앱에 필요한 캐시 - 기존 Workers 구조에서는 Worker가 캐시와 원본 앞에 위치했다. - 요청 변환, URL 재작성, A/B 테스트, 트래픽 필터링 등에 적합했다. - 하지만 Worker 자체가 애플리케이션 서버이자 원본이 되면, 캐시할 대상이 없어 모든 요청이 코드를 실행한다. - Astro, TanStack Start, Next.js, Remix, SvelteKit 같은 프레임워크는 Cloudflare용 어댑터를 통해 앱을 Worker로 배포할 수 있다. - 동일한 응답을 반복 생성하더라도 매번 렌더링해야 하므로: - 페이지 로드마다 렌더링 지연이 발생한다. - Worker CPU 실행 비용이 계속 발생한다. - Workers Cache는 캐시를 Worker 앞에 배치한다. - 캐시 적중: Worker를 실행하지 않고 응답 반환, CPU 비용 0. - 캐시 실패: Worker가 실행되어 응답을 생성하고 캐시에 저장. - 이후 전 세계 어디서든 캐시된 응답을 받을 수 있다. ## 정적 생성과 매 요청 렌더링 사이의 선택지 - 빌드 시점 사전 생성(SSG)은 빠르지만 콘텐츠 변경마다 전체 빌드와 재배포가 필요하다. - 대규모 문서나 전자상거래 사이트에서는 빌드 시간이 길어질 수 있다. - 매 요청 서버 렌더링은 최신 데이터를 반영하지만, 모든 방문자가 렌더링 비용과 지연을 부담한다. - Workers Cache는 요청 시 생성한 결과를 TTL 동안 저장한다. - 새 페이지의 첫 요청만 렌더링한다. - 이후 요청은 정적 페이지처럼 캐시에서 제공한다. - TTL 만료 후 필요할 때 다시 렌더링한다. - 프레임워크별 ISR 구현 없이 표준 HTTP 캐싱 방식으로 동작한다. ## Wrangler 설정과 HTTP 헤더 기반 제어 - Wrangler 설정에서 캐시를 활성화한다. ```json { "name": "my-worker", "main": "src/index.ts", "compatibility_date": "2026-05-01", "cache": { "enabled": true } } ``` - 응답의 `Cache-Control` 헤더로 캐시 정책을 지정한다. ```ts return new Response(body, { headers: { "Cache-Control": "public, max-age=300, stale-while-revalidate=3600", "Cache-Tag": "products,product:123" } }); ``` - 별도의 Zone 설정, 규칙 엔진, 캐시 프로비저닝 없이 Worker 코드와 HTTP 헤더만으로 구성한다. - 커스텀 도메인, `workers.dev`, 서비스 바인딩, 프리뷰, Workers for Platforms 테넌트 등 Worker가 실행되는 여러 진입점에서 동일한 방식으로 사용할 수 있다. ## `stale-while-revalidate`로 만료 시에도 지연 방지 - `max-age=300`은 응답을 5분 동안 신선한 상태로 유지한다. - `stale-while-revalidate=3600`은 만료 후 최대 1시간 동안 오래된 응답을 즉시 제공하면서 백그라운드에서 새 응답을 생성하도록 한다. - 이 설정이 없으면 TTL 만료 직후 첫 요청이 Worker 렌더링을 기다려야 한다. - 설정이 있으면: - 사용자는 오래된 페이지를 즉시 받는다. - 응답에는 `Cf-Cache-Status: UPDATING`이 표시될 수 있다. - Worker는 백그라운드에서 캐시를 갱신한다. - 갱신을 유발한 요청자도 캐시 수준의 응답 속도를 얻는다. ## 캐시 무효화와 고급 기능 - 콘텐츠가 변경되면 Worker에서 직접 캐시를 제거할 수 있다. ```ts await ctx.cache.purge({ tags: ["product:123"] }); ``` - `Cache-Tag`를 사용하면 특정 상품이나 콘텐츠 그룹 단위로 캐시를 무효화할 수 있다. - 글에서 언급한 추가 기능은 다음과 같다. - 네트워크 전반의 계층형 캐싱 - `Vary`를 이용한 콘텐츠 협상 - `ctx.props` 기반의 멀티테넌트 안전 캐시 키 - 태그 또는 경로 접두사 기반 프로그래밍 방식 purge - 공개 엔드포인트뿐 아니라 모든 Worker 진입점 앞에 캐시 배치 - 진입점별 캐시 활성화 여부 제어 ## 적용 범위와 의의 - Workers Cache는 모든 요금제의 Worker에서 사용할 수 있으며 Wrangler로 활성화한다. - 캐시는 애플리케이션 구조에 맞춰 여러 진입점 사이에 배치할 수 있다. - 결과적으로 서버 렌더링 앱은 정적 사이트에 가까운 응답 속도와 동적 서버 렌더링의 최신성, 두 가지를 함께 얻을 수 있다. - 실무에서는 페이지 특성에 따라 `max-age`와 `stale-while-revalidate` 값을 정하고, 데이터 변경 시 `Cache-Tag` 기반 purge를 함께 사용하는 방식이 적합하다.

원문 읽기(새 탭에서 열림)
Cloudflare Workerswranglerhttp-cachingstale-while-revalidate+2
gitlab4분 읽기큐레이션 요약

제한된 액세스로 GitLab 좌석을 관리하세요

GitLab의 **Restricted access**는 구매한 라이선스 좌석이 모두 사용된 뒤 새로운 과금 대상 사용자가 추가되는 것을 막아 좌석 초과와 예기치 않은 비용을 줄이는 기능입니다. SAML·SCIM·LDAP 기반 프로비저닝, OIDC/SSO 재로그인, 휴면 사용자 재활성화까지 처리 방식이 개선되어 자동화된 사용자 관리 환경에서도 더 안정적으로 사용할 수 있습니다. 다만 기존 초과 사용자를 자동으로 정리하지는 않으므로, 이미 발생한 초과분은 관리자가 별도로 해결해야 합니다. ## Restricted access의 역할 - GitLab.com과 Self-Managed에서 사용할 수 있는 좌석 제어 기능입니다. - 라이선스 좌석이 모두 소진되면 새로운 **과금 대상 사용자(billable user)** 추가를 차단합니다. - 좌석 초과를 사후에 되돌리는 기능이 아니라, 앞으로 발생할 추가 초과를 예방하는 기능입니다. - 프로젝트나 그룹 접근 없이 인증만 필요한 사용자는 **Minimal Access** 역할로 지정할 수 있습니다. - Minimal Access 사용자는 인증은 가능하지만 유료 좌석을 소비하지 않습니다. ## 기존 과금 사용자는 소급 적용되지 않음 - Restricted access를 이미 좌석 한도 초과 상태에서 활성화해도 기존 사용자는 영향을 받지 않습니다. - 기존 멤버가 자동으로 강등되거나 제거되거나 접근 차단되지 않습니다. - 관리자는 초과된 과금 사용자를 제거하거나 추가 좌석을 구매해 사용량을 한도 이내로 되돌려야 합니다. - 사용량이 한도 이내로 내려간 뒤부터 Restricted access가 추가적인 좌석 초과를 방지합니다. ## ID 프로바이더 기반 프로비저닝 개선 - 좌석이 없을 때 SAML, SCIM, LDAP로 프로비저닝된 사용자는 과금 역할로 바로 추가되지 않습니다. - 대신 자동으로 비과금 역할인 Minimal Access가 할당됩니다. - 중앙 집중식 계정 동기화를 유지하면서도 즉시 라이선스 초과가 발생하는 것을 막을 수 있습니다. - GitLab을 OIDC 프로바이더로 사용하는 경우, 인증만 필요한 사용자를 최상위 그룹에서 Minimal Access로 지정하는 방식이 유용합니다. - Minimal Access 사용자와 해당 역할만 가진 사용자는 좌석이 없어도 재활성화할 수 있습니다. ## 휴면 사용자 재활성화 문제 해결 - GitLab은 일정 기간 활동이 없는 사용자를 자동 비활성화해 좌석을 회수할 수 있습니다. - 이전에는 해당 사용자가 OIDC나 SSO로 다시 로그인하면 과금 사용자로 조용히 재활성화되어 좌석 초과가 발생할 수 있었습니다. - 이제 좌석이 부족하고 Restricted access가 활성화된 경우, 휴면 사용자는 **관리자 승인 대기 상태**로 전환됩니다. - 기존 그룹·프로젝트 멤버십은 유지됩니다. - 좌석이 확보되면 관리자가 사용자를 승인해 재활성화할 수 있습니다. ## 경고와 운영 가시성 강화 - LDAP 동기화, SAML 그룹 연결, SCIM 프로비저닝 설정 시 Restricted access의 동작을 안내하는 경고가 표시됩니다. - 좌석 한도에 접근 중인 상태와 한도에 도달한 상태가 제품 내에서 구분됩니다. - 좌석 부족으로 사용자가 Minimal Access로 배정되면 그룹 소유자나 인스턴스 관리자에게 이메일 알림이 전송됩니다. - Minimal Access로 전환된 이벤트는 감사 로그에서 확인할 수 있습니다. - 단순히 사용자 추가를 차단하는 것을 넘어, 왜 그런 처리가 발생했는지 추적하고 관리할 수 있게 개선되었습니다. ## Self-Managed의 설정 캐시 - GitLab Self-Managed는 성능을 위해 애플리케이션 설정을 기본적으로 60초간 캐시합니다. - Restricted access와 user cap 사이를 전환한 직후에는 UI나 좌석 제어 동작이 즉시 반영되지 않을 수 있습니다. - 캐시는 자동으로 갱신되며, 갱신 후에는 설정이 일관되게 적용됩니다. - 필요하다면 관리자가 캐시 간격을 조정할 수 있습니다. ## Restricted access와 user cap의 차이 - **User cap** - 좌석 여유 여부와 관계없이 새 사용자를 승인 대기 상태로 보냅니다. - 관리자나 그룹 소유자가 모든 신규 사용자 추가를 검토하는 승인 제어 기능입니다. - **Restricted access** - 라이선스 좌석이 모두 사용된 경우에만 신규 과금 사용자 추가를 제한합니다. - 구매한 좌석 수를 기준으로 동작하는 좌석 한도 제어 기능입니다. - 두 기능은 동시에 활성화할 수 없습니다. - Restricted access를 활성화하면 user cap은 자동으로 비활성화됩니다. - GitLab.com에서 user cap에서 Restricted access로 전환할 때 기존 대기 멤버의 상태가 영향을 받을 수 있으므로 전환 전에 관련 동작을 확인해야 합니다. ## 활성화 방법 - **GitLab.com** - `Settings > General > Permissions and group features > Seat control > Restricted access` - 그룹 Owner가 설정할 수 있습니다. - **Self-Managed** - `Admin > Settings > General > New user account restrictions > Seat control > Restricted access` - 관리자만 설정할 수 있습니다. - GitLab.com에서는 최상위 그룹이 외부 그룹과 공유된 경우 Restricted access를 사용할 수 없습니다. 자동 프로비저닝과 SSO를 사용하는 조직이라면 Restricted access를 활성화해 좌석 초과를 예방하는 것이 좋습니다. 다만 활성화 전 이미 발생한 초과 사용자는 별도로 정리하고, user cap과의 차이 및 기존 대기 사용자 처리 방식을 검토해야 합니다.

원문 읽기(새 탭에서 열림)
gitlabidentity-providersamlsingle-sign-on+4
figma3분 읽기큐레이션 요약

Config Leadership Collective에 앞서 우리가 품었던 7가지 질문 | Figma 블로그

AI 시대의 리더십은 완성된 해법을 제시하는 것보다 변화 속에서 직접 실험하고 조직의 적응력을 키우는 데 초점을 둬야 한다. AI가 실행 업무를 일부 대체하더라도 사용자 이해, 장인정신, 판단력과 같은 인간의 핵심 역량은 여전히 중요하다. 팀은 자율적인 소규모 단위로 구성하고, 교육과 작은 성공 경험을 통해 새로운 도구를 점진적으로 받아들이게 해야 한다. ## 변화 속에서 함께 실험하는 리더십 - AI와 새로운 제작 도구의 변화가 너무 빠르기 때문에 하나의 고정된 프로세스를 고수하기 어렵다. - 리더 역시 모든 답을 알고 있는 전문가가 아니라 팀과 함께 배우는 초보자의 자세를 가져야 한다. - 직접 프로토타입을 만들고 실패 사례까지 공유하면 팀원들이 실험을 더 자연스럽게 받아들일 수 있다. - 새로운 시도가 성공하지 않더라도 즐겁게 시도할 수 있도록 조직 차원의 심리적 허용과 자율성을 제공해야 한다. - 핵심 역량은 완성된 방법론보다 변화에 대응하는 적응력이다. ## AI 시대에도 유지해야 할 기본 원칙 - AI가 업무 방식을 바꾸더라도 다음과 같은 기본 원칙은 변하지 않는다. - 실제 사용자의 필요와 업무 흐름을 이해할 것 - 사용자를 위해 제품을 설계할 것 - 결과물의 완성도와 세부 품질을 중시할 것 - 도구 자체를 따라가는 데 몰두하면 “무엇을 만들 것인가”보다 “무슨 도구를 쓸 것인가”가 중심이 될 위험이 있다. - 디자인의 대상은 여전히 인간이므로, 기술보다 사용자와 문제에 대한 이해가 우선되어야 한다. ## 전문성의 중심이 실행에서 판단으로 이동 - 과거에는 특정 작업을 빠르고 정확하게 수행하는 능력이 전문성의 중요한 기준이었다. - AI가 일부 실행과 산출물 생성을 담당하면서 전문성의 가치는 다음 영역으로 이동한다. - 무엇이 좋은 결과인지 판단하는 감각 - 여러 대안 중 상황에 맞는 선택을 하는 분별력 - 결과물을 검토하고 개선하는 편집 능력 - 사용자와 비즈니스 맥락을 고려한 의사결정 - 전문가는 모든 정답을 알고 있는 사람이 아니라, 수많은 선택지 중 현재 상황에 가장 적합한 답을 고르는 사람이다. - 따라서 AI 활용 능력만큼 결과를 비판적으로 평가하는 ‘편집자의 시각’이 중요해진다. ## AI 시대의 팀 구조와 인재상 - AI는 디자인·제품·엔지니어링의 경계를 흐리므로 기존 직무 중심 조직을 재검토할 필요가 있다. - Airbnb는 제품, 디자인, 엔지니어링에 데이터 과학자나 비즈니스 담당자 등을 결합한 소규모 포드(pod) 구조를 활용한다. - 각 포드는 작은 스타트업처럼 독립적으로 움직이며 다양한 관점에서 문제를 해결한다. - AI가 생성한 결과물을 평가하고 다듬을 수 있도록 강한 편집력과 비판적 사고를 갖춘 인재가 필요하다. - 효과적인 팀은 다음과 같은 특성을 가진다. - 적극적으로 시도하는 태도 - 대담하고 다양한 아이디어 - 서로 반대 의견을 편하게 제시하는 문화 - 의견 충돌을 생산적인 논의로 전환하는 능력 - 모든 사람이 쉽게 동의하기만 하는 팀은 오히려 충분한 검토와 논쟁이 부족할 수 있다. ## 새로운 도구를 점진적으로 도입하는 방법 - 단순히 “AI를 사용하라”고 지시하는 것만으로는 조직의 도입이 이루어지지 않는다. - 구성원이 도구를 익힐 수 있도록 교육 과정과 학습 인프라를 제공해야 한다. - 사용법을 배울 수 있다는 안전감이 있어야 팀원들이 새로운 도구를 업무에 적용할 수 있다. - 대규모 업무 프로세스를 한 번에 자동화하기보다 가장 작은 작업부터 시작하는 방식이 효과적이다. - 예: Slack의 긴 대화 한 편을 AI 에이전트로 요약하기 - 작은 성공을 통해 실질적인 유용성을 체감하게 하기 - 이후 더 복잡한 업무로 활용 범위를 확대하기 - 점진적인 도입은 구성원의 거부감을 낮추고 AI 활용 숙련도와 신뢰를 단계적으로 높인다. ## 실용적인 적용 방향 리더는 먼저 팀과 함께 작은 AI 실험을 진행하고, 결과를 평가할 기준을 마련해야 한다. 도구 사용 교육과 실패를 허용하는 문화를 병행하되, 사용자 이해와 품질 기준은 절대 낮추지 않는 것이 중요하다. AI가 만든 결과물을 그대로 받아들이기보다 맥락에 맞는지 판단하고 개선하는 능력을 조직의 핵심 역량으로 키워야 한다.

원문 읽기(새 탭에서 열림)
AI사용자 경험프로토타이핑프로덕트 디자인+2
github1분 읽기큐레이션 요약

GitHub은 시크릿 스캐닝을 활용해 받은편지함을 0으로 만든 방법

Michael Recachinas는 GitHub의 스태프 보안 엔지니어로, 대규모 취약점 관리와 보안 개발 생명주기 도구를 이끌고 있다. 개발자가 보안상 올바른 선택을 쉽게 할 수 있도록, 대규모 환경에서 작동하는 보안 시스템과 자동화 기술을 구축해 온 전문가다. ### GitHub에서의 역할 - GitHub의 대규모 보안 프로그램을 주도한다. - 주요 업무는 다음과 같다. - 취약점 관리 - 보안 개발 생명주기(SDLC) 도구 - 개발자 중심의 보안 자동화 ### 전문성과 경력 - 대규모 시스템을 설계하고 운영한 경험을 보유하고 있다. - 보안 프로세스를 개발자의 업무 흐름에 자연스럽게 통합하는 데 집중한다. - 조직이 보안을 별도의 부담으로 느끼기보다, 안전한 선택을 쉽게 실행하도록 만드는 것을 목표로 한다. 제공된 내용은 기술 블로그 본문이 아니라 저자 소개에 해당하므로, 특정 기술이나 구현 방법에 대한 추가적인 요약은 어렵다.

원문 읽기(새 탭에서 열림)
githubvulnerability-managementapplication-securitysecurity-automation+1
line4분 읽기큐레이션 요약

AI로 웹 엔지니어 없이 LINE 앱 안에서 그룹 영상 통화 서비스 만들기

LINE OA와 LIFF, LINE Planet SDK를 결합하면 별도 앱 설치 없이 LINE 안에서 그룹 영상 통화 서비스를 구현할 수 있다. 글에서는 LINE Planet 팀의 PM과 Android 엔지니어가 웹 엔지니어 없이 만든 사례를 바탕으로, LIFF 웹 앱과 액세스 토큰 발급용 앱 서버만 직접 개발하면 된다는 구조를 설명한다. LINE의 인증·WebRTC·글로벌 네트워크 인프라를 활용하므로 핵심은 각 컴포넌트를 연결하고 통화 흐름을 구현하는 것이다. ## LINE OA와 LIFF의 역할 - **LINE OA** - 사용자와 소통하는 접점이자 서비스 진입 채널이다. - 상담, 교육, 라이브 방송, 게임 음성 채팅 등 다양한 서비스를 제공할 수 있다. - **LIFF** - LINE 앱 내부 웹뷰에서 실행되는 웹 애플리케이션이다. - LINE 로그인 정보인 `userId`, `displayName` 등을 전달하므로 별도 인증 서버 없이 사용자를 식별할 수 있다. - **LINE Planet** - WebRTC 기반의 음성·영상 통화와 미디어 처리를 담당한다. - 글로벌 네트워크 인프라를 제공해 개발자가 통화 인프라를 직접 구축하지 않아도 된다. ## 구현해야 하는 전체 구조 - 직접 개발할 부분은 크게 두 가지다. - LIFF에서 실행되는 그룹 영상 통화 웹 앱 - LINE Planet 액세스 토큰을 발급하는 앱 서버 - 앱 서버는 Firebase Cloud Functions로 구성하면 별도의 서버 인프라 설정을 줄일 수 있다. - LINE OA와 LIFF가 사용자 인증을, LINE Planet이 미디어 통신을 처리하므로 개발자는 서비스 화면과 연결 로직에 집중할 수 있다. - 실제 구현 대상은 웹 앱 레이어와 서버 레이어의 앱 서버이며, LINE OA·LIFF·LINE Planet의 기반 기능은 외부 플랫폼을 활용한다. ## 적용 가능한 서비스 사례 - **전문 상담** - 변호사, 재무 설계사, 심리 상담사와의 1:1 화상 상담 - 별도 앱 설치 없이 LINE 앱에서 상담방 입장 - **원격 교육** - 수업 예약과 화상 수업을 LINE OA에서 제공 - 여러 강사가 동시에 독립적인 통화방 운영 가능 - 화면 공유를 이용한 문서·문제 풀이 지원 - **실시간 소통 방송** - 기본 500명에서 최대 1만 명까지 동시 참여 가능 - 팬미팅, 라이브 이벤트, 진행자와 청중이 대화하는 양방향 방송 구현 - **게임 음성 채팅** - LINE 친구와 게임 중 별도 앱 전환 없이 실시간 음성 대화 ## 개발 전 준비 사항 - **개발 환경** - Node.js 20 LTS 이상 - npm 기반 프로젝트 - LIFF 특성상 HTTPS 배포 필요 - 로컬 개발에서는 ngrok 같은 HTTPS 터널링 도구 사용 가능 - **LINE Developers 설정** - Business ID로 개발자 계정 등록 - Provider 생성 - LINE OA 생성 후 Messaging API 활성화 - 같은 Provider에 LINE Login 채널 생성 - LINE Login 채널의 LIFF 탭에서 LIFF 앱 등록 - **주의할 설정** - 발급된 LIFF ID를 이후 모든 초기화 과정에서 사용하므로 별도 보관해야 한다. - 친구 초대 기능인 `shareTargetPicker`를 사용하려면 LINE Login 채널이 `Published` 상태여야 한다. - **LINE Planet 준비** - LINE Planet Console 계정과 서비스 ID가 필요하다. - 해당 정보는 LINE Planet 팀에 요청해 발급받는다. ## 통화방 ID 설계 - 사용자가 통화에 입장하기 전에 방 ID를 생성하거나 URL에서 복원한다. - 데모에서는 `crypto.randomUUID()`에서 하이픈을 제거한 뒤 앞 16자리를 사용해 랜덤 방 ID를 만든다. - 초대 링크에 `roomId`가 포함되어 있으면 query string에서 해당 값을 읽어 같은 방에 입장한다. - 서비스 목적에 따라 다음과 같이 확장할 수 있다. - 관심사별 고정 방 - 사용자 그룹별 자동 방 생성 - 예약된 수업이나 상담 일정에 연결된 방 - 방 ID 자체만으로 권한을 판단하지 말고, 실제 서비스에서는 서버에서 접근 권한과 만료 여부를 검증해야 한다. ## `MediaStreamManager`를 활용한 미리보기 - 일반적인 웹 구현의 `getUserMedia` 대신 PlanetKit의 `MediaStreamManager`를 사용한다. - 미리보기 화면에서 생성한 MSM 인스턴스를 통화방 입장 후에도 재사용할 수 있다. - 이 방식의 장점은 다음과 같다. - 페이지 전환 시 카메라와 마이크 권한을 다시 요청하지 않음 - 모바일 웹뷰에서 권한 프롬프트가 반복적으로 노출되는 문제 완화 - 기존 미디어 스트림을 통화 연결 과정까지 유지 - 구현 흐름은 다음과 같다. - 컴포넌트 마운트 시 `MediaStreamManager`를 한 번 생성 - 비디오가 켜져 있으면 `createMediaStream()`으로 미디어 스트림 생성 - 이미 스트림이 있으면 `changeVideoInputDevice()`로 비디오 입력 장치만 교체 - 스트림을 HTML `<video>` 요소의 `srcObject`에 연결 - 마이크 끄기/켜기는 권한을 다시 요청하지 않고 오디오 트랙의 `enabled` 속성만 변경한다. ## 모바일 카메라 전환 처리 - 모바일 기기에서는 전면·후면 카메라 전환 기능을 제공할 수 있다. - `useIsMobileDevice`로 모바일 환경을 판별하고, 모바일에서만 전환 버튼을 노출한다. - `resolveFacingModeDeviceId`를 통해 `front` 또는 `back` 방향에 해당하는 카메라 장치 ID를 찾는다. - 카메라가 꺼진 상태에서는 전환 버튼을 비활성화해 불필요한 장치 변경을 막는다. - 데스크톱에서는 기본 장치를 사용하고, 모바일에서는 방향 기반 장치 선택을 적용한다. ## 데모 코드의 범위와 주의점 - 글의 코드는 핵심 흐름을 보여주는 데모 코드다. - 통화 셋업, 미리보기, 통화 화면의 세부 UI와 전체 사용자 경험은 직접 구현해야 한다. - 프로덕션 적용 전 다음 항목을 추가 검토해야 한다. - 액세스 토큰 및 방 접근 권한 보안 - 네트워크 오류와 권한 거부 처리 - 통화 종료 및 리소스 정리 - 모바일 브라우저별 호환성 - 성능 최적화와 사용자 상태 동기화 - 앱 서버에서는 LINE Planet 액세스 토큰을 안전하게 발급하고 클라이언트에 비밀 키가 노출되지 않도록 해야 한다. ## 실용적인 결론 LINE OA를 이미 운영 중이라면 LIFF와 LINE Planet을 조합해 상담·교육·방송 같은 실시간 서비스를 빠르게 확장할 수 있다. 초기 구현은 랜덤 방 ID, `MediaStreamManager` 기반 미리보기, Firebase Cloud Functions 기반 토큰 서버로 단순화할 수 있지만, 실제 출시 단계에서는 방 권한 검증과 토큰 보안, 모바일 환경의 예외 처리를 반드시 보강해야 한다.

원문 읽기(새 탭에서 열림)
ReactTypeScriptnode.jswebrtc+4