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

gitlab·2026년 5월 7일·4분 읽기큐레이션 요약

GitLab Duo Agent Platform으로 배포 프로세스 자동화

GitLab Duo Agent Platform의 커스텀 에이전트를 활용하면 새로운 마이크로서비스를 기존 GitOps 배포 흐름에 자동으로 편입할 수 있다. 에이전트는 애플리케이션의 저장소 구조와 매니페스트, 파이프라인, Dockerfile을 분석해 필요한 설정을 생성하고 수정한다. 에이전트와 생성 결과가 GitLab 안에서 버전 관리·권한 통제되므로 자동화 속도와 엔터프라이즈 거버넌스를 함께 확보할 수 있다는 것이 글의 결론이다. ## TanukiBank의 마이크로서비스 온보딩 사례 - 가상의 은행 애플리케이션인 TanukiBank에 `intra-account-transfers` 마이크로서비스를 추가하는 상황을 예로 든다. - 기존 애플리케이션에는 계좌 간 송금 UI가 있지만 이를 처리할 백엔드 서비스가 없어 Transfer 버튼이 동작하지 않는다. - 새 서비스는 기존 GitOps 배포 규칙에 맞게 다음 요소를 모두 구성해야 한다. - Kubernetes 배포 매니페스트 - 컨테이너 이미지 빌드 및 전달 파이프라인 - 이미지 자동 업데이트 설정 - 네임스페이스, 포트, 호스트명 참조 ## TanukiBank의 GitOps 배포 구조 - GitLab 그룹에는 각 마이크로서비스를 담는 `services` 하위 그룹이 있다. - 배포 과정은 두 프로젝트와 Flux 컴포넌트가 연계되는 구조다. - **Tanuki Bank - Delivery**: 환경별 배포 매니페스트와 전달 파이프라인 관리 - **Flux Config**: Flux 관련 매니페스트 관리 - **Flux Image Automation Controller**: 서비스 레지스트리의 새 이미지를 감지하고 Delivery 프로젝트의 매니페스트 갱신 - **Flux CD Controller**: Delivery 프로젝트의 상태를 Kubernetes 클러스터의 실행 상태와 동기화 - 새 서비스가 추가되면 서비스 저장소, Delivery 프로젝트, Flux 설정을 모두 정확히 수정해야 한다. - 수동 작업에서는 특정 파일이나 참조를 빠뜨릴 경우 배포 실패가 발생할 수 있다. ## GitLab Duo를 이용한 시스템 프롬프트 생성 - GitLab Agentic Chat에 TanukiBank 그룹과 하위 그룹의 구조 및 파일을 분석하도록 요청한다. - Duo는 다음 자료를 조사해 커스텀 에이전트용 시스템 프롬프트를 작성한다. - Kubernetes 매니페스트 - 설정 파일 - Dockerfile - 프로젝트 간 의존성 - 기존 GitOps 규칙 - 생성된 프롬프트에는 다음과 같은 내용이 포함된다. - 에이전트가 따라야 할 작업 규칙 - 결과 보고 방식 - 사용할 도구 - 이 프롬프트는 현재 애플리케이션의 GitOps 구조를 반영한 것이므로, 향후 배포 방식이 바뀌면 다시 생성해야 한다. ## 커스텀 에이전트 생성 및 적용 - `application-agents`라는 별도 프로젝트를 만들어 에이전트를 관리한다. - GitLab의 **AI > Agents > Managed** 메뉴에서 `TanukiBank Microservice Onboarder` 에이전트를 생성한다. - 에이전트 생성 시 다음을 설정한다. - 이름과 설명 - 공개 여부 - Duo가 추천한 도구 - 앞서 생성한 시스템 프롬프트 - 이후 에이전트를 GitOps를 담당하는 다음 프로젝트에서 사용할 수 있도록 활성화한다. - `Tanuki Bank - Delivery` - `Flux Config` - 각 프로젝트의 Agentic Chat 에이전트 목록에 해당 에이전트가 표시되면 설정이 완료된 것이다. ## Developer 플로우로 새 서비스 구현 - `services` 그룹에 `intra-account-transfers` 프로젝트를 만든다. - 프로젝트 이슈에 마이크로서비스 요구사항을 작성하고 **Generate MR with Duo**를 실행한다. - Developer foundational flow가 다음 작업을 자동으로 수행한다. - 이슈의 사양 분석 - 서비스 코드 구현 - 브랜치 생성 - Merge Request 생성 - 이슈와 MR 연결 - 로컬에서 `curl` 명령으로 동작을 확인한 뒤 MR을 병합한다. - 파이프라인이 실행되어 새 서비스의 컨테이너 이미지를 서비스 프로젝트의 내장 레지스트리에 업로드한다. ## 커스텀 에이전트를 통한 GitOps 온보딩 - 서비스 자체는 생성됐지만 GitOps 설정에는 아직 등록되지 않은 상태다. - Delivery 프로젝트의 `manifests/dev`에 서비스 매니페스트가 없음 - 전달 파이프라인에 서비스 참조가 없음 - Flux Config의 `image-update-automation.yaml`에 이미지 자동화 항목이 없음 - 새 서비스 프로젝트에서도 `TanukiBank Microservice Onboarder`를 활성화한다. - Delivery 프로젝트의 Agentic Chat에서 커스텀 에이전트를 선택한다. - 서비스 이름과 호스트명을 전달해 온보딩을 요청한다. - 에이전트는 새 서비스의 Dockerfile을 읽어 포트를 확인하고, 이에 맞는 매니페스트와 파이프라인 설정을 생성·수정한다. - 제공된 글은 이 작업이 진행되는 지점에서 끝나므로, 이후 생성된 변경 사항과 실제 Kubernetes 배포 결과는 본문에 포함되어 있지 않다. 새 마이크로서비스 온보딩 절차가 반복적이고 규칙 기반이라면, 프로젝트 구조와 GitOps 규칙을 반영한 커스텀 에이전트를 만들어 자동화하는 것이 효과적이다. 다만 시스템 프롬프트가 현재 배포 구조에 강하게 의존하므로, GitOps workflow 변경 시 프롬프트와 에이전트 동작을 함께 재검토해야 한다.

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

쿠버네티스CI/CDDocker & 컨테이너마이크로서비스+3

gitlab·2026년 5월 7일·3분 읽기큐레이션 요약

유출된 개인 액세스 토큰 하나로 소유자가 접근할 수 있는 모든 프로젝트가 노출되어서는 안 됩니다. 세분화된 PAT는 각 토큰의 권한을 해당 작업에 맞게 제한합니다.

GitLab은 개인 액세스 토큰(PAT)을 작업별·리소스별로 제한하는 세분화된 PAT를 베타로 공개했습니다. 토큰이 특정 프로젝트의 특정 리소스에서 필요한 작업만 수행하도록 설정해, 유출 시 피해 범위를 전체 계정이 아닌 해당 작업과 프로젝트로 줄이는 것이 핵심입니다. 다만 현재 REST API의 약 75%만 지원하므로 정식 출시 전까지는 운영 환경 사용을 권장하지 않습니다. ## 광범위한 PAT의 보안 위험 - `api`나 `read_api`처럼 넓은 범위의 스코프는 사용자가 접근 가능한 여러 프로젝트와 그룹에 권한을 부여합니다. - 하나의 토큰으로 소스 코드 조회, 파이프라인 수정, 컨테이너 레지스트리 접근, CI/CD 변수 복호화 등을 모두 수행할 수 있습니다. - 토큰이 유출되면 공격자가 해당 사용자가 접근 가능한 전체 프로젝트를 악용할 수 있습니다. - 토큰의 권한이 특정 작업이 아니라 사용자 계정에 묶여 있어 피해 범위가 커집니다. ## 작업별 최소 권한 부여 - 세분화된 PAT는 자동화 작업마다 별도의 토큰을 발급하는 방식입니다. - 토큰이 접근할 수 있는 범위를 다음처럼 지정할 수 있습니다. - 개인 프로젝트만 - 사용자가 속한 모든 프로젝트와 그룹 - 선택한 특정 프로젝트와 그룹 - 접근 가능한 리소스별로 권한을 독립 설정할 수 있습니다. - Issues - Merge Requests - Pipelines - Repositories - Container Registry 등 - 각 리소스에 대해 `Create`, `Read`, `Update`, `Delete` 권한을 개별적으로 부여합니다. ## 컨테이너 레지스트리 활용 예시 - 컨테이너 이미지를 빌드하고 업로드하는 파이프라인에는 전체 `api` 토큰 대신 특정 프로젝트의 Container Registry용 토큰을 발급합니다. - 해당 토큰에는 필요한 `Create`와 `Read` 권한만 부여할 수 있습니다. - 토큰이 유출되어도 피해 범위는 전체 프로젝트나 계정이 아닌 해당 프로젝트의 컨테이너 레지스트리로 제한됩니다. ## 토큰 감사와 추가 보호 장치 - 토큰 목록 화면에서 기존 PAT와 세분화된 PAT의 전체 스코프 및 리소스별 권한을 확인할 수 있습니다. - 과도한 권한을 가진 토큰을 보안 검토 중 쉽게 식별할 수 있습니다. - 토큰 만료 기간 제한과 자동 폐기 기능을 함께 사용하면 도난된 토큰의 악용 시간을 줄일 수 있습니다. - 작업별 토큰을 사용하면 유출 이후 조사와 대응 범위도 해당 작업과 프로젝트로 좁힐 수 있습니다. ## 베타 단계의 지원 범위와 제한 - 세분화된 PAT는 현재 REST API 엔드포인트의 약 75%를 지원합니다. - 향후 나머지 REST API와 GraphQL 지원 범위를 확대할 예정입니다. - 정식 출시 전까지는 프로덕션 워크로드에 사용하지 않는 것이 권장됩니다. - 베타 기간에는 기존 PAT와 세분화된 PAT를 동시에 생성해 호환성과 권한 모델을 평가할 수 있습니다. ## 생성 방법 - **User Settings → Personal Access Tokens**로 이동합니다. - **Generate token** 메뉴에서 **Fine-grained token**을 선택합니다. - 접근 가능한 프로젝트·그룹과 리소스별 권한을 설정합니다. - 지원 리소스와 관리자 제어 항목은 GitLab의 세분화된 PAT 문서에서 확인할 수 있습니다. 실무에서는 자동화 작업마다 별도 토큰을 만들고, 특정 프로젝트와 필요한 리소스의 최소 권한만 부여하는 방식이 권장됩니다. 베타 기간에는 프로덕션 적용을 피하고, 먼저 테스트 환경에서 기존 PAT와의 호환성 및 API 지원 범위를 검증하는 것이 안전합니다.

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

gitlabGraphQLrest-apiapi-security+3

github·2026년 5월 6일·4분 읽기큐레이션 요약

“정답”이 결정적이지 않을 때 에이전트 행동 검증

자율 에이전트의 실행 과정은 환경, 타이밍, UI 상태에 따라 달라지므로 기존의 결정론적 테스트 방식만으로는 올바른 동작을 안정적으로 검증하기 어렵다. 에이전트가 실제 작업을 성공했는데도 실행 경로가 예상과 다르다는 이유로 테스트가 실패하는 ‘거짓 음성(false negative)’이 발생할 수 있다. 글은 고정된 스크립트 대신 필수 결과와 경로의 구조를 검증하는 독립적인 ‘Trust Layer’를 제안하며, 이를 통해 설명 가능하고 CI에 적합한 에이전트 검증을 구현할 수 있다고 주장한다. ## 에이전트 기반 검증에서 발생하는 문제 - Copilot Coding Agent가 UI, 브라우저, IDE 같은 실제 환경을 조작하면 실행 결과가 매번 동일하지 않다. - 네트워크 지연으로 로딩 화면이 오래 표시되거나, 반대로 즉시 화면이 나타날 수 있다. - 에이전트가 상황에 맞게 대기하고 작업을 완료했더라도, 테스트가 특정 시점이나 순서를 기대하면 실패한다. - 주요 문제는 다음과 같다. - **거짓 음성:** 작업은 성공했지만 테스트가 실패로 판정한다. - **취약한 인프라:** 렌더링, 타이밍, 네트워크 같은 환경 잡음이 결과에 영향을 준다. - **컴플라이언스 함정:** 올바른 결과를 냈어도 사전에 기록된 에이전트 행동과 다르면 회귀로 오인된다. - 에이전트의 정확성은 정해진 단계를 그대로 따르는 것이 아니라, 필수적인 결과를 안정적으로 달성하는지로 판단해야 한다. ## 기존 테스트 방식이 자율 에이전트에 맞지 않는 이유 - **Assertion 기반 테스트** - 모든 검증 조건을 사람이 직접 작성해야 한다. - 가능한 모든 대체 경로를 명세하기 어렵다. - **Record-and-replay** - 실행을 녹화된 순서와 비교하므로 사소한 타이밍·렌더링 변화에도 실패한다. - **시각적 회귀 테스트** - 스크린샷 차이는 감지하지만, 해당 변화가 작업의 의미나 최종 결과에 영향을 주는지는 이해하지 못한다. - **ML 오라클** - 많은 학습 사례가 필요하다. - 실패 판정의 근거를 설명하기 어려운 블랙박스가 되기 쉽다. - 이 방식들은 모두 “정확성은 특정한 관찰 상태와 순서를 재현하는 것”이라는 공통 가정을 갖는다. - 하지만 에이전트 시스템에서는 서로 다른 실행 경로가 동일한 올바른 결과로 이어질 수 있다. ## 필수 상태와 선택적 변형의 구분 에이전트 동작을 검증하려면 모든 상태를 동일하게 취급하지 말고, 성공에 반드시 필요한 요소와 환경에 따라 달라지는 요소를 분리해야 한다. - **필수 상태(Essential states)** - 성공을 위해 반드시 도달해야 하는 상태다. - 예를 들어 VS Code 검색 작업에서는 최종적으로 ‘검색 결과’ 화면에 도달해야 한다. - **선택적 변형(Optional variations)** - 로딩 스피너, 일시적인 로딩 화면, 장식적 UI 변화처럼 성공 여부와 직접 관련 없는 상태다. - **수렴 경로(Convergent paths)** - 단축키 사용, 메뉴 선택 등 서로 다른 절차가 동일한 최종 상태로 합쳐지는 경우다. - 로딩 화면이 나타났는지는 중요하지 않지만, 검색 결과가 표시되었는지는 작업의 성공을 결정한다. - 따라서 검증 대상은 실행 과정 전체가 아니라 성공을 보장하는 논리적 구조여야 한다. ## Dominator 분석을 활용한 필수 행동 추출 필수 상태와 부수적 상태를 자동으로 구분하기 위해 컴파일러 이론의 **Dominator 관계**를 활용할 수 있다. - 제어 흐름 그래프에서 노드 A가 노드 B를 지배(dominates)한다는 것은 시작점에서 B로 가는 모든 경로가 A를 거쳐야 한다는 뜻이다. - 에이전트의 실행 기록을 그래프로 표현하면 다음을 식별할 수 있다. - 모든 성공 경로에 공통으로 나타나는 필수 상태 - 일부 경로에만 등장하는 선택적 상태 - 서로 다른 실행 경로가 다시 합쳐지는 지점 - 이 분석을 통해 테스트가 확인해야 할 최소한의 성공 조건을 추출할 수 있다. - 또한 “왜 이 실행을 성공 또는 실패로 판단했는가”를 그래프 구조로 설명할 수 있어, 단순한 블랙박스 판정보다 신뢰성이 높다. ## 스크립트가 아닌 실행 그래프로 모델링 - 자율 에이전트의 행동은 고정된 1차원 스크립트보다 여러 분기와 수렴 지점을 가진 그래프로 보는 편이 적합하다. - 그래프 기반 모델은 특정 순서를 강제하지 않고, 서로 다른 행동 경로가 같은 필수 결과에 도달했는지를 평가할 수 있다. - 이 접근은 에이전트의 자유로운 문제 해결 능력을 유지하면서도, CI 파이프라인에서는 반드시 충족되어야 할 결과를 엄격하게 검증할 수 있는 기반이 된다. - 글에서 제안하는 Trust Layer는 이러한 실행 그래프를 바탕으로 우연한 환경 차이와 실제 기능 실패를 구분하는 역할을 한다. ## 실용적인 적용 방향 - 에이전트 테스트를 작성할 때 모든 중간 화면과 클릭 순서를 고정하지 않는다. - 대신 다음을 명확히 정의한다. - 반드시 도달해야 하는 최종 상태 - 작업 성공을 입증하는 핵심 데이터나 UI 상태 - 무시할 수 있는 로딩·렌더링 변화 - 허용 가능한 대체 실행 경로 - CI에서는 기록된 경로의 일치 여부보다 필수 상태의 도달 여부와 상태 간 논리적 관계를 검증하는 것이 적절하다. - 이를 적용하면 환경 변화로 인한 불필요한 실패를 줄이고, 에이전트가 실제로 작업에 실패한 경우에는 더 정확하게 감지할 수 있다.

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

AI 에이전트CI/CDgithub-copilotGitHub Actions+3

cloudflare·2026년 5월 6일·4분 읽기큐레이션 요약

DNSSEC가 잘못되었을 때: .de TLD 장애에 대응한 방법

2026년 5월 5일, .de TLD 운영자인 DENIC이 잘못된 DNSSEC 서명을 배포하면서 .de 하위 도메인에 대한 DNS 조회가 대규모로 실패했다. Cloudflare의 1.1.1.1은 DNSSEC 규격에 따라 검증에 실패한 응답을 `SERVFAIL`로 처리했지만, 캐시된 레코드를 TTL 이후에도 제공하는 “serve stale”과 DNSSEC 검증 우회 설정으로 영향을 완화했다. 이 대응은 가용성을 높이는 대신 사고 기간 동안 .de 도메인의 위조·변조 위험을 일부 감수하는 선택이었다. ## DNSSEC와 신뢰 체인 - DNSSEC은 DNS 응답의 암호화가 아니라 **무결성과 진위 검증**을 제공한다. - 각 DNS 레코드에는 `RRSIG` 전자서명이 붙으며, 리졸버는 이를 검증해 응답이 변조되지 않았는지 확인한다. - 검증은 루트 영역에서 시작하는 신뢰 체인을 따른다. - 루트 영역이 `.de`를 신뢰한다. - `.de`는 `DS` 레코드를 통해 `example.de` 같은 하위 영역을 신뢰한다. - 체인의 어느 한 지점이라도 깨지면 해당 영역 아래의 모든 도메인이 검증 실패와 `SERVFAIL`을 겪는다. - 일반적으로 다음 두 키를 사용한다. - **ZSK**: 영역 내 DNS 레코드 서명 - **KSK**: ZSK를 서명하며, 부모 영역의 `DS` 레코드가 KSK를 가리킴 - 키 교체 중 새 키가 완전히 배포되지 않았거나, 서명에 사용된 키를 `DNSKEY`에서 확인할 수 없으면 리졸버는 응답을 거부한다. ## .de TLD 장애와 영향 - 2026년 5월 5일 약 19:30 UTC부터 DENIC이 잘못된 DNSSEC 서명을 게시했다. - DNSSEC 검증을 수행하는 리졸버는 해당 서명을 거부하고 `SERVFAIL`을 반환해야 했다. - 1.1.1.1에서도 초기 `SERVFAIL`이 급증했고, 캐시된 레코드가 만료되면서 약 3시간 동안 실패율이 계속 상승했다. - 사용자가 실패한 DNS 조회를 반복하면서 전체 쿼리량도 크게 증가했다. - 실제 사용자 수보다 `SERVFAIL` 요청 수가 더 크게 보일 수 있는데, 동일한 사용자의 재시도가 여러 요청으로 집계되기 때문이다. - `.de`는 세계적으로 많이 조회되는 TLD이므로 장애가 수백만 개 도메인의 접근성에 영향을 줄 가능성이 있었다. ## 캐시된 응답을 계속 제공하는 “serve stale” - 리졸버는 권위 있는 네임서버의 응답을 레코드별 TTL 동안 캐시한다. - 장애가 발생하면 새로 가져온 레코드는 DNSSEC 검증 실패로 `SERVFAIL`이 되지만, 장애 전부터 캐시에 있던 레코드는 여전히 유효한 내용을 담고 있을 수 있다. - 1.1.1.1은 RFC 8767에 정의된 **serve stale** 동작을 사용해, 상위 네임서버 조회가 실패해도 만료된 캐시 레코드를 일정 기간 제공했다. - 이 기능 덕분에 일부 사용자는 장애 중에도 정상적인 `NOERROR` 응답을 받았다. - 캐시된 데이터가 사라질수록 stale 응답이 줄고, 정상 응답률도 점차 낮아졌다. - 즉, 캐시는 장애를 해결하지는 않지만 운영자가 복구할 시간을 벌어 주며 즉각적인 사용자 피해를 줄인다. ## DNSSEC 검증을 우회하는 Negative Trust Anchor - RFC 7646의 **Negative Trust Anchor(NTA)** 는 특정 영역을 일시적으로 DNSSEC 미서명 영역처럼 취급하는 예외 설정이다. - 신뢰 체인이 깨진 경우 해당 영역 아래 응답의 DNSSEC 검증을 생략해 `SERVFAIL`을 피할 수 있다. - TLD 운영자의 설정 오류처럼 하위 도메인 자체에는 문제가 없는 상황이 NTA의 대표적인 사용 사례다. - 이 경우 계속 `SERVFAIL`을 반환하는 것은 실질적인 보안 이득보다 가용성 손실이 더 클 수 있다. ## Cloudflare의 실제 완화 조치 - Cloudflare의 1.1.1.1과 관련 서비스는 `Big Pineapple`이라는 자체 리졸버를 사용한다. - 당시 Cloudflare는 RFC 방식의 네이티브 NTA 기능을 구현하지 않은 상태였다. - 대신 기존 오버라이드 규칙을 활용해 `.de`를 **insecure zone**으로 지정했다. - 결과적으로 `.de` 질의는 DNSSEC이 활성화되지 않은 영역처럼 처리되어 검증 실패에 따른 `SERVFAIL`을 피할 수 있었다. - 이는 형식상 NTA는 아니지만 기능적으로는 동일한 효과를 냈다. - 다만 DNSSEC을 우회하는 동안에는 실제 공격자가 DNS 응답을 변조하더라도 검증으로 차단할 수 없으므로, 가용성과 보안 사이의 의도적인 절충이었다. 장기적으로는 DNSSEC 장애 대응을 위해 serve stale을 활성화하고, 통제된 조건에서 사용할 수 있는 NTA 또는 동등한 예외 메커니즘을 마련하는 것이 권장된다. 단, 검증 우회는 장애 범위와 원인이 명확할 때만 일시적으로 적용하고, 복구 즉시 해제해야 한다.

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

dnsdnssecdomain-name-systemcloudflare-1.1.1.1+4

aws·2026년 5월 6일·4분 읽기큐레이션 요약

AWS MCP 서버가 정식 출시되었습니다 | Amazon Web Services

AWS MCP Server는 AI 에이전트가 기존 IAM 자격 증명을 사용해 AWS 서비스에 안전하게 접근하도록 해 주는 관리형 원격 MCP 서버다. 최신 AWS 문서 검색, 15,000개 이상의 API 호출, 샌드박스 스크립트 실행을 제공해 에이전트가 오래된 학습 데이터나 과도한 권한 정책에 의존하는 문제를 줄인다. 특히 IAM 기반 권한 통제, CloudWatch·CloudTrail 감사, AWS 서비스별 Skills를 통해 프로덕션 환경에 적합한 AWS 자동화를 지원한다. ## AI 에이전트가 AWS에서 겪는 문제 - 모델의 학습 데이터가 오래되면 최신 서비스와 기능을 알지 못한다. - 예를 들어 2025년에 출시된 Amazon S3 Vectors를 학습하지 못한 모델은 S3에 임베딩을 저장하는 일반적인 방법만 제시할 수 있다. - 인프라를 구성할 때 AWS CDK나 CloudFormation보다 AWS CLI 명령을 우선적으로 생성하는 경향이 있다. - 필요 이상으로 광범위한 IAM 정책을 만들어 보안 위험을 키울 수 있다. - 데모 수준에서는 동작하더라도 최신 정보, 최소 권한, 운영 표준을 반영하지 못해 프로덕션 배포에는 부적합할 수 있다. ## AWS MCP Server의 핵심 도구 - `call_aws` - 기존 IAM 자격 증명을 사용해 15,000개 이상의 AWS API 작업을 실행한다. - 새 AWS API가 출시되면 며칠 내에 지원될 예정이다. - `search_documentation` - 실행 시점에 최신 AWS 공식 문서와 모범 사례를 검색한다. - `read_documentation` - 검색된 문서의 구체적인 내용을 읽어 에이전트가 최신 정보를 바탕으로 답변하도록 한다. - 이 도구들은 개별 AWS 서비스를 수천 개의 도구로 노출하지 않고 소수의 고정된 인터페이스로 제공해 모델 컨텍스트 사용량과 환각을 줄인다. ## GA 버전의 보안·효율성 개선 - IAM 컨텍스트 키를 지원해 별도의 MCP 서버용 IAM 권한 없이 표준 IAM 정책으로 세밀한 접근 제어를 설정할 수 있다. - 문서 검색은 인증 없이 사용할 수 있다. - 상호작용당 필요한 토큰 수를 줄여 복잡한 다단계 작업의 비용과 컨텍스트 부담을 낮췄다. - 에이전트 권한은 IAM 정책이나 SCP(Service Control Policy)로 제한할 수 있다. - 예를 들어 사용자는 리소스를 변경할 수 있지만 MCP 서버는 읽기 전용 작업만 수행하도록 분리할 수 있다. - `AWS-MCP` 네임스페이스의 CloudWatch 지표로 에이전트 호출을 사람의 직접 호출과 구분해 관찰할 수 있다. - CloudTrail은 실제 AWS API 호출에 대한 전체 감사 기록을 제공한다. ## 샌드박스 기반 `run_script` - 에이전트가 짧은 Python 스크립트를 작성해 AWS 서버 측 샌드박스에서 실행할 수 있다. - 샌드박스는 IAM 권한을 상속하지만 네트워크 접근과 로컬 파일 시스템·셸 접근은 차단된다. - 여러 AWS API를 순차적으로 호출하고 결과를 필터링·계산하는 작업을 한 번의 왕복으로 처리할 수 있다. - 그 결과 API 호출 지연과 모델 컨텍스트 사용량을 줄일 수 있다. - 로컬 환경 전체에 대한 접근 권한을 주지 않고도 데이터 처리 능력을 제공한다. ## Agent SOP에서 Skills로의 전환 - Skills는 에이전트가 자주 실수하는 작업에 대해 AWS 서비스 팀이 관리하는 검증된 지침과 모범 사례를 제공한다. - 에이전트가 더 적은 토큰으로 빠르고 일관되게 작업하도록 돕는다. - AWS 서비스별 지침을 별도 도구로 무분별하게 늘리지 않고 큐레이션된 지식으로 제공한다. - 짧고 예측 가능한 도구 목록을 유지해 환각을 줄이고 에이전트의 작업 집중도를 높인다. ## 최신 문서 검색을 통한 실제 효과 - 모델만 사용하면 Amazon S3 Vectors가 학습 데이터 이후에 출시되었기 때문에 해당 기능을 제안하지 못한다. - AWS MCP Server를 연결하면 `search_documentation`이 최신 AWS 문서를 조회한다. - 동일한 질문에 대해 Amazon S3 Vectors가 임베딩 저장을 위한 전용 서비스라는 정확한 답변을 얻을 수 있다. - 즉, 모델 자체를 재학습하지 않고도 실행 시점의 AWS 지식으로 최신 서비스와 API를 활용할 수 있다. ## 인증과 클라이언트 연동 - AWS MCP Server는 IAM과 IAM SigV4 인증을 사용한다. - MCP 클라이언트가 OAuth 2.1만 지원하는 경우 오픈 소스 `mcp-proxy-for-aws` 프록시를 사용해 로컬 AWS 자격 증명과 MCP를 연결할 수 있다. - 예시 설정은 Claude Code에서 다음과 같이 등록한다. ```bash claude mcp add-json aws-mcp --scope user \ '{"command":"uvx","args":["mcp-proxy-for-aws@latest","https://aws-mcp.us-east-1.api.aws/mcp","--metadata","AWS_REGION=us-west-2"]}' ``` - `--scope user`는 노트북의 모든 프로젝트에서 서버를 사용할 수 있게 한다. - 엔드포인트는 미국 동부 또는 유럽 리전에 위치하지만, API 호출 자체는 모든 AWS 리전에 수행할 수 있다. - Claude Code, Kiro, Cursor, Codex 등 MCP 호환 클라이언트에서 사용할 수 있다. ## 요금과 제공 리전 - AWS MCP Server 자체에는 추가 요금이 없다. - 사용자가 부담하는 비용은 생성한 AWS 리소스 비용과 해당 데이터 전송 비용이다. - 서비스 엔드포인트는 현재 미국 동부(버지니아 북부)와 유럽(프랑크푸르트) 리전에서 제공된다. 에이전트에 AWS 접근 권한을 부여할 때는 관리자 권한 대신 읽기 전용 또는 작업별 최소 권한 IAM 정책부터 적용하는 것이 좋다. 최신 문서 검색과 `run_script`를 활용하면 에이전트의 정확성과 효율성을 높이면서도 로컬 시스템과 AWS 리소스에 대한 접근 범위를 분리할 수 있다.

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

모델 컨텍스트 프로토콜PythonAWSclaude-code+4

gitlab·2026년 5월 6일·3분 읽기큐레이션 요약

Claude Code와 GitLab: 실제 배포로 이어지는 세 가지 워크플로

Claude Code는 코드 작성과 디버깅을 빠르게 수행하지만, 실제 배포에는 CI/CD, 보안 검사, 코드 리뷰, 승인 등 추가 과정이 필요하다. 이 글은 Claude Code와 GitLab을 결합해 버그 수정부터 머지 리퀘스트, 검증, 리뷰, 배포까지 연결하는 세 가지 워크플로를 소개한다. GitLab MCP와 Duo Agent Platform을 활용하면 AI가 로컬 코드뿐 아니라 이슈와 과거 개발 맥락까지 반영할 수 있다. ## 코드 수정과 GitLab 검증 파이프라인 연결 - C++로 작성된 Arduino IoT Collector가 `/dev/ttyACM0` 장치가 없을 때 충돌하는 버그를 예제로 사용한다. - `cmake`로 프로젝트를 빌드하고 실행해 문제를 재현한다. - Claude Code에 버그 수정을 요청하면 코드베이스를 탐색해 `main.cpp`의 `std::runtime_error` 예외가 애플리케이션을 즉시 종료시키는 원인임을 찾는다. - 수정 방향은 예외로 프로세스를 중단하는 대신 사용자 친화적인 설정 오류를 기록하고 애플리케이션은 계속 실행하도록 바꾸는 것이다. - 수정 후 Claude Code 또는 직접 Git 명령으로 다음 작업을 수행한다. - 수정 브랜치 생성 - 변경 사항 커밋 - 원격 저장소에 푸시 - 머지 리퀘스트 생성 - MR이 생성되면 GitLab이 자동으로 다음을 수행한다. - 빌드 및 테스트를 위한 CI/CD 파이프라인 실행 - 새 취약점이 추가되지 않았는지 보안 스캔 - GitLab Duo Code Review를 통한 코드 정확성 및 스타일 검토 - 코드 리뷰에는 프로젝트의 C++ 개발 규칙과 사용자 정의 리뷰 지침도 적용할 수 있다. ## GitLab MCP로 이슈와 개발 이력 활용 - 로컬 저장소만 이용하면 Claude Code가 버그 리포트, 디버깅 논의, 과거 MR의 해결 방식 등을 알 수 없다는 한계가 있다. - GitLab MCP Server를 연결하면 Claude Code가 GitLab의 SDLC 맥락을 함께 조회할 수 있다. - 관련 이슈와 설명 - 이슈 댓글 및 논의 - 과거 머지 리퀘스트 - 유사한 버그의 수정 이력 - 프로젝트 내 개발 정보 - GitLab 인스턴스 또는 최상위 그룹에서 MCP Server를 활성화한 뒤, Claude Code에 HTTP 방식으로 추가한다. ```bash claude mcp add --transport http GitLab https://gitlab.example.com/api/v4/mcp ``` - 새 Claude Code 세션에서 `/mcp`를 실행하고 브라우저 OAuth 인증을 완료한다. - MCP 도구 목록과 서버 버전을 질의해 연결 상태를 확인할 수 있다. - MCP는 Claude에 추가적인 맥락을 제공할 뿐 권한을 상승시키지 않는다. - Claude Code는 인증한 사용자가 원래 접근할 수 있는 프로젝트와 이슈만 볼 수 있다. - GitLab의 프로젝트·그룹 멤버십과 가시성 설정을 우회하지 않는다. - 별도의 관리자 권한을 자동으로 부여하지 않는다. ## Claude Code와 GitLab Duo Agent Platform의 역할 분담 - Claude Code는 터미널이나 IDE에서 코드 탐색, 버그 수정, 기능 구현을 담당한다. - GitLab은 변경 사항을 실제로 출하하기 위한 중앙 플랫폼 역할을 한다. - CI/CD - 보안 검사 - 코드 리뷰 - 승인 절차 - 감사 가능한 변경 이력 - 세 번째 워크플로에서는 GitLab Duo Agent Platform의 외부 에이전트가 Claude를 활용해 MR의 코드 리뷰 피드백을 직접 반영한다. - 따라서 개발자가 리뷰 댓글을 수동으로 해석하고 수정하는 대신, 에이전트가 MR 맥락에서 코드를 변경하고 후속 검증까지 진행할 수 있다. ## 필요한 개발 환경 - 터미널에서 실행 가능한 Claude Code - 버그와 기능 제안 이슈가 등록된 GitLab 프로젝트 - 필요에 따라 GitLab MCP Server와 GitLab Duo Agent Platform 외부 에이전트 - C++ 예제 실행 시: - CMake - Make - gcc 또는 clang++ - Java 프로젝트를 다룰 경우 Maven - 예제 프로젝트를 클론한 뒤 `claude` 명령으로 Claude Code를 실행하고 프로젝트 목적을 먼저 질의할 수 있다. 실무에서는 Claude Code를 코드 작성과 문제 해결에 사용하고, GitLab을 CI/CD·보안·리뷰·승인의 통합 관문으로 두는 방식이 효과적이다. 특히 GitLab MCP를 연결하면 AI가 단순히 현재 파일만 보고 추측하지 않고, 실제 이슈와 과거 변경 이력을 근거로 더 일관된 수정을 제안할 수 있다.

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

gitlab코드 리뷰claude-codec-plus-plus+4

aws·2026년 5월 5일·3분 읽기큐레이션 요약

워크플로 현대화: Amazon WorkSpaces, 이제 AI 에이전트에 자체 데스크톱 제공(미리 보기) | Amazon Web Services

Amazon WorkSpaces는 레거시 애플리케이션을 API로 현대화하지 않아도 AI 에이전트가 데스크톱 환경에서 직접 조작할 수 있도록 지원한다. 에이전트는 직원과 동일한 관리형 가상 데스크톱에서 애플리케이션을 사용하며, IAM 인증과 CloudTrail·CloudWatch 감사 추적을 적용받는다. 이를 통해 기업은 대규모 마이그레이션 없이 기존 업무 시스템에 AI 자동화를 도입할 수 있다. ## 레거시 애플리케이션의 AI 접근성 문제 - 2024년 Gartner 보고서에 따르면 조직의 75%가 현대적인 API가 없는 레거시 애플리케이션을 운영한다. - Fortune 500 기업의 71%는 프로그래밍 방식 접근이 부족한 메인프레임에서 핵심 업무를 처리한다. - 기업은 AI 도입을 미루거나, 비용과 위험이 큰 애플리케이션 현대화 프로젝트를 진행해야 했다. - WorkSpaces는 애플리케이션을 재개발하거나 API를 새로 구축하지 않고도 이 문제를 해결한다. ## AI 에이전트를 위한 보안 데스크톱 - AI 에이전트는 관리형 WorkSpaces 환경 내부에서 데스크톱 애플리케이션을 실행한다. - AWS IAM을 통해 에이전트를 인증하고, 에이전트별 자격 증명과 권한을 적용한다. - AWS CloudTrail과 Amazon CloudWatch를 이용해 세션과 작업을 감사·모니터링할 수 있다. - 로컬 컴퓨터가 아닌 격리된 클라우드 데스크톱에서 동작하므로 기존 보안 정책과 컴플라이언스 통제를 유지할 수 있다. - 직원용으로 사용하던 WorkSpaces 인프라를 AI 에이전트용 실행 환경으로 확장할 수 있다. ## MCP 기반 에이전트 연동 - WorkSpaces는 업계 표준인 Model Context Protocol(MCP)을 지원한다. - MCP 엔드포인트를 통해 에이전트 프레임워크와 WorkSpaces를 연결할 수 있다. - LangChain, CrewAI, Strands Agents 등 다양한 프레임워크와 함께 사용할 수 있다. - 별도의 애플리케이션별 API 통합 없이 에이전트가 데스크톱의 사용자 인터페이스를 조작한다. ## 에이전트 접근 환경 설정 - WorkSpaces Applications 스택을 생성해 에이전트의 연결 방식과 권한을 정의한다. - 스택 설정에서 기본값인 `No AI agent access` 대신 `Add AI Agents`를 선택하면 에이전트 접속을 활성화할 수 있다. - 주요 에이전트 기능은 다음과 같다. - **Computer input**: 클릭, 입력, 스크롤 수행 - **Computer vision**: 화면을 캡처해 애플리케이션 상태 인식 - **Screenshot storage**: 감사 및 디버깅을 위한 세션 스크린샷 저장 - 화면 해상도와 이미지 형식도 지정할 수 있다. - 예시 설정: 1280×720 해상도, PNG 형식 - 복잡하고 조밀한 UI는 더 높은 해상도가 유리할 수 있다. - 터미널 중심 인터페이스는 720p 수준으로도 충분할 수 있다. ## API 없이 기존 업무 애플리케이션 자동화 - Strands Agent SDK와 Amazon Bedrock으로 구현한 에이전트가 샘플 약국 시스템에서 처방전 리필 업무를 수행했다. - 에이전트는 환자 기록 조회, 약품 검색, 주문, 처방전 갱신 확인을 모두 화면 조작으로 처리했다. - 해당 애플리케이션은 에이전트가 사용 중이라는 사실을 인식하지 못한다. - 애플리케이션 수정, 재빌드, API 통합 없이 현재 상태 그대로 사용할 수 있다는 점이 핵심이다. ## 제공 범위와 도입 방법 - 현재 퍼블릭 프리뷰로 제공되며 추가 비용은 없다. - 지원 리전에는 미국 동부·서부, 캐나다, 유럽 주요 리전, 도쿄·뭄바이·시드니·서울·싱가포르 등이 포함된다. - AWS Management Console에서 WorkSpaces Applications 스택을 생성하고 AI 에이전트 접근을 활성화한 뒤, MCP 엔드포인트와 IAM 인증 정보를 에이전트 프레임워크에 설정한다. - AWS GitHub 저장소와 WorkSpaces 공식 페이지를 통해 구현을 시작할 수 있다. 기존 데스크톱 애플리케이션을 빠르게 자동화하려는 기업에는 유용한 접근 방식이다. 다만 퍼블릭 프리뷰 단계이므로 실제 도입 전 권한 범위, 화면 캡처의 민감정보 처리, 감사 로그 보존 정책을 충분히 검토하는 것이 좋다.

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

AI 에이전트모델 컨텍스트 프로토콜amazon-bedrockamazon-cloudwatch+4

kakao·2026년 5월 5일·4분 읽기큐레이션 요약

음성 AI 모델을 프로덕션에 올리기까지: Kanana-O 서빙 최적화 여정

Kanana-O를 실시간 음성 대화 서비스로 제공하려면 모델 학습과는 별개의 서빙 최적화가 필요하다. 카카오는 Thinker·Talker·VoiceBox로 구성된 파이프라인에 특화된 Kanana-Omni Server를 구축해 임베딩 전달, 스트리밍 지연, 프로세스 안정성, 동시 요청 처리 문제를 해결했다. 그 결과 동시 사용자 64명 기준으로 vllm-omni 대비 상대 처리량 1.6배를 달성했다. ## Kanana-O의 멀티모달 음성 생성 구조 - **Thinker**는 텍스트·이미지·오디오 입력을 이해하고 텍스트를 생성하는 대형 언어 모델이다. - **Talker**는 Thinker의 텍스트 임베딩을 받아 음성 토큰을 순차적으로 생성한다. - **VoiceBox**는 음성 토큰을 실제 오디오 파형으로 변환한다. - 프로덕션 환경에서는 다음 조건을 동시에 만족해야 한다. - 수백 밀리초 안에 첫 음성을 제공해야 한다. - 여러 사용자의 요청을 동시에 처리해야 한다. - 텍스트와 오디오를 끊김 없이 스트리밍해야 한다. - 각 모델의 GPU 메모리 요구량 차이를 관리해야 한다. ## 범용 멀티모달 서빙 프레임워크의 한계 - Thinker가 Talker에 전달하는 값은 토큰 ID가 아니라 수천 차원의 **히든 스테이트 임베딩**이다. - 임베딩을 직렬화하거나 CPU로 복사하면 지연이 커지므로 GPU 메모리 주소를 직접 공유하는 zero-copy 방식이 필요했다. - Talker는 매 스텝 음성 토큰을 생성하지만 VoiceBox는 일정량의 토큰이 쌓인 뒤 청크 단위로 소비한다. - Talker의 입력에는 다음 값이 누적된다. - 화자 특성을 나타내는 스피커 임베딩 - Thinker의 출력 임베딩 - 이전 스텝에서 생성한 음성 임베딩 - 이처럼 생산자와 소비자의 속도가 다르고 입력 길이가 계속 증가하는 구조는 일반적인 LLM 서빙 패턴과 맞지 않았다. - 자체 서버를 구축한 결과 상대 처리량은 다음과 같았다. - naive 구현: 0.44 - vllm-omni: 1 - Kanana-Omni Server: 1.6 ## 공유 메모리와 CUDA IPC를 활용한 데이터 전달 - 프로세스 간 임베딩 전달을 매번 직렬화·역직렬화하면 토큰마다 큰 오버헤드가 발생한다. - 서버 시작 시 OS 레벨에서 공유 메모리 블록을 미리 할당해 런타임 할당·해제를 제거했다. - Thinker는 공유 메모리 풀의 블록에 데이터를 쓰고, Talker에는 실제 데이터 대신 블록 번호와 크기 같은 메타데이터만 전달한다. - 같은 노드의 GPU 간 텐서 전달에는 **CUDA IPC**를 사용했다. - GPU 텐서를 CPU로 내렸다가 다시 GPU로 올리는 `Device → Host → Device` 복사를 제거해 컴포넌트 간 통신 지연을 줄였다. ## Cascaded Streaming Pipeline - Thinker가 전체 텍스트를 생성한 뒤 Talker를 실행하는 순차 방식은 첫 음성 응답까지 수 초가 걸릴 수 있다. - 세 컴포넌트를 비동기 태스크와 큐로 연결해 파이프라인을 겹쳐 실행했다. - Thinker가 첫 청크를 생성하면 Talker는 즉시 음성 토큰 생성을 시작한다. - Talker가 앞선 토큰을 생성하는 동안 VoiceBox는 이전 토큰 청크를 오디오로 합성한다. - 각 단계가 동시에 진행되므로 전체 처리 시간보다 첫 음성까지의 체감 지연을 크게 줄일 수 있다. ## 프로세스 분리와 장애 격리 - Thinker와 Talker는 각각 독립적인 vLLM 엔진으로 실행된다. - 하나의 프로세스에서 두 엔진을 구동하면 CUDA 컨텍스트 충돌이나 GPU 메모리 관리 간섭이 발생할 수 있다. - 따라서 두 모델을 별도 프로세스로 분리하고 각자의 CUDA 컨텍스트에서 실행했다. - 프로세스 생성에는 `fork` 대신 `spawn`을 사용했다. - `fork`: 부모의 CUDA 상태와 메모리를 복제해 충돌 위험이 있다. - `spawn`: 깨끗한 Python 인터프리터에서 시작해 GPU 상태 오염을 줄인다. - Thinker가 OOM으로 종료되더라도 Talker와 API 서버까지 함께 영향을 받지 않아 독립적인 재시작과 장애 대응이 가능하다. ## vLLM continuous batching을 이용한 동시 처리 - 요청마다 이미지·오디오 입력 크기와 누적 임베딩 길이가 달라 직접 배치를 구성하기 어렵다. - 수동 배칭은 padding 낭비와 복잡한 동기화 문제를 유발한다. - Kanana-Omni Server는 배치 구성을 vLLM의 **continuous batching 스케줄러**에 위임했다. - 서버는 요청을 비동기로 빠르게 엔진에 제출하고, vLLM이 GPU 메모리와 요청 상태를 고려해 forward pass를 묶는다. - 각 요청은 `request_id`로 결과를 구분하므로 여러 요청이 하나의 배치에서 처리돼도 개별 응답을 독립적으로 스트리밍할 수 있다. - 내부 루프는 요청을 받자마자 `asyncio.create_task(generate(...))`로 실행해 다음 요청을 즉시 수락한다. ## FastAPI `workers=1`과 비동기 처리 - 일반적인 FastAPI 서버처럼 여러 워커를 실행하면 각 워커가 vLLM 모델을 별도로 로드한다. - 그 결과 GPU 메모리 사용량과 모델 로딩 시간이 워커 수만큼 증가해 멀티워커 구성이 현실적으로 어렵다. - 모델별 서버를 따로 두면 워커 확장은 가능하지만, Thinker와 Talker 사이의 임베딩이 네트워크를 거쳐 zero-copy 이점을 잃게 된다. - 따라서 API 서버는 `workers=1`로 운영하고, 단일 이벤트 루프가 블로킹되지 않도록 요청부터 오디오 생성까지 전체 경로를 `async/await`로 구성했다. - 단일 워커 환경에서는 동기 작업 하나가 모든 사용자의 처리를 막을 수 있으므로, 끝에서 끝까지 비동기 설계가 필수다. 실시간 멀티모달 모델을 서비스할 때는 모델 자체보다 모델 간 데이터 이동, 스트리밍 타이밍, GPU 메모리 관리, 장애 격리가 성능을 좌우한다. 특히 모델 간 임베딩 전달이 빈번하다면 공유 메모리와 CUDA IPC를 검토하고, 긴 생성 파이프라인은 비동기 스트리밍과 continuous batching으로 구성하는 것이 효과적이다.

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

멀티모달 AIvllmcontinuous-batchingfastapi+3

slack·2026년 5월 5일·4분 읽기큐레이션 요약

SSH에서 REST로: Slack EMR 데이터 파이프라인의 보안 주도 현대화

Slack은 700개가 넘는 EMR 데이터 파이프라인을 직접 SSH로 실행하던 구조에서 REST 기반 작업 제출 방식으로 전환했다. SSH는 보안 공격 표면, 키 관리, 장애 복구, 작업 관측성 측면에서 한계가 있었고 Spark on Kubernetes와 AWS 계정 분리 같은 현대화도 가로막았다. Slack은 YARN REST API와 YARN Distributed Shell을 활용해 8개 데이터 리전의 작업을 중단 없이 마이그레이션하고 SSH를 완전히 제거했다. ## SSH 기반 파이프라인의 확산 - 2017년경 Airflow가 EMR 마스터 노드에 SSH로 접속해 명령을 실행하는 방식으로 데이터 파이프라인을 구축했다. - 단순한 `SSHOperator` 패턴이 확산되면서 다음과 같은 작업까지 SSH로 실행됐다. - Spark 및 MapReduce 작업 - AWS CLI 명령 - 사용자 정의 Python 스크립트 - 2024년에는 700개 이상의 운영 작업이 SSH 기반으로 실행되고 있었다. - 검색 인덱싱, 분석, 비즈니스 인텔리전스 등 핵심 데이터 처리도 이 구조에 의존했다. ## SSH의 보안 및 운영상 문제 - **보안 위험** - 오케스트레이션 워커가 EMR 클러스터에 직접 SSH 접속해야 해 공격 표면이 커졌다. - SSH 키를 여러 워커에 배포하고 주기적으로 교체해야 했다. - 세밀한 감사 추적을 위해 여러 시스템의 로그를 상호 연관해야 했다. - 보안 그룹과 사용자 권한 설정이 복잡해졌다. - **운영 장애** - 작업이 EMR 마스터 노드에서 직접 실행되어 리소스 경쟁이 발생했다. - Kubernetes Pod가 재시작되면 SSH 연결이 끊겨 작업이 실패했다. - 연결이 끊긴 뒤에도 작업이 계속 실행되는 ‘좀비 작업’이 남을 수 있었다. - 연결 단절 후 작업의 성공·실패 상태를 안정적으로 확인하기 어려웠다. - **인프라 현대화 차단** - Spark on Kubernetes와 EMR on EKS 도입을 시작할 수 없었다. - 메인 AWS 계정의 EMR 클러스터를 자식 계정으로 이전하는 Whitecastle 프로젝트가 지연됐다. - 신뢰할 수 있는 작업 모니터링과 관측성을 구현하기 어려웠다. ## REST 기반 작업 제출의 장점 - SSH는 클라이언트와 서버 사이의 상태ful 연결을 유지해야 한다. - REST 방식에서는 작업의 생명주기를 서버가 관리한다. - `POST`: 작업을 제출하고 작업 ID를 받음 - `GET`: 작업 ID로 실행·완료·실패 상태를 조회 - `DELETE`: 필요할 때 작업을 취소 - Airflow나 Kubernetes Pod가 재시작되어도 작업 자체는 서버에서 계속 실행될 수 있다. - 클라이언트가 작업 상태를 다시 조회할 수 있어 연결 단절에 강하다. - 작업 취소, 리소스 관리, 로그 확인 등도 실행 엔진의 표준 기능으로 처리할 수 있다. ## YARN Distributed Shell을 활용한 해결책 - Spark는 Livy REST API, Hive는 HiveServer2를 사용할 수 있어 상대적으로 이전이 쉬웠다. - 반면 MapReduce와 `aws s3 sync`, `hadoop distcp` 같은 300개 이상의 임의 CLI 작업은 바로 사용할 REST API가 없었다. - 검토한 대안은 다음과 같았다. - 원격 명령 실행용 커스텀 래퍼 서비스 - Ansible이나 Salt 같은 원격 실행 프레임워크 - YARN에 새로운 작업 유형을 직접 개발 - 이러한 방법은 별도 보안 계층과 운영 인프라를 구축·유지해야 해 복잡도가 높았다. - YARN의 **Distributed Shell**은 임의의 셸 스크립트를 YARN 컨테이너에서 실행할 수 있도록 했다. - 기존 YARN REST API를 그대로 사용 - YARN의 인증·인가 체계 활용 - 별도 보안 서비스 불필요 - 오픈소스 표준 기반 - 컨테이너 리소스와 작업 생명주기 관리 지원 ## Distributed Shell의 실행 흐름 - 실행할 셸 스크립트를 S3에 업로드한다. - 예: `s3://bucket/command.sh` - 스크립트는 `aws s3 sync` 같은 임의 명령을 포함할 수 있다. - YARN REST 요청에 Distributed Shell의 `ApplicationMaster`와 스크립트 위치를 지정한다. - YARN이 컨테이너를 할당하고 S3에서 스크립트를 내려받아 실행한다. - 실행 과정에서 YARN이 다음을 담당한다. - 메모리와 vCore 등 리소스 제한 - 컨테이너 격리 - 재시도와 장애 복구 - 정상적인 작업 취소 - YARN UI를 통한 로그 및 상태 확인 ## 마이그레이션의 의미 - YARN Distributed Shell을 통해 REST API가 없던 CLI·MapReduce 작업까지 동일한 실행 모델로 통합할 수 있었다. - 작업 제출과 실행을 SSH 연결에서 분리해 클라이언트 재시작과 네트워크 단절에 대한 안정성을 높였다. - 700개 이상의 작업을 8개 데이터 리전에 걸쳐 중단 없이 이전하면서 SSH 의존성을 제거했다. - 결과적으로 보안 강화뿐 아니라 Kubernetes 기반 실행 환경, AWS 계정 분리, 표준화된 모니터링으로 나아갈 기반을 마련했다. 실용적으로는 원격 서버에 직접 접속해 명령을 실행하기보다, 작업 ID·상태 조회·취소를 제공하는 서버 측 실행 모델을 사용하는 것이 바람직하다. 특히 기존 작업이 단순 CLI 스크립트라면 복잡한 신규 실행 서비스를 만들기 전에 YARN Distributed Shell처럼 기존 플랫폼의 표준 기능을 우선 검토할 수 있다.

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

쿠버네티스rest-apiapache-sparkapache-airflow+3

gitlab·2026년 5월 5일·4분 읽기큐레이션 요약

팀 협업을 재편하는 8가지 에이전틱 AI 패턴

17개 에이전틱 AI 플랫폼을 분석한 결과, 팀 협업을 혁신하는 핵심은 개별 에이전트의 성능보다 팀 전체의 업무 흐름을 얼마나 일관되게 연결하느냐에 있다. 특히 에이전트는 진행 상황 공유, 업무 배정, 커뮤니케이션, 권한 관리, 개발·배포 거버넌스를 지원하며 팀의 속도와 판단력을 높이고 통제력을 유지하게 한다. 글은 이러한 기능을 8가지 패턴으로 정리하고, 소프트웨어 개발 생명주기 전체가 하나의 플랫폼에 통합된 GitLab이 에이전트 협업에 구조적 강점을 가진다고 주장한다. ## 1. 진행 상황 자동 공유 - 에이전트가 실시간 작업 데이터를 바탕으로 진행 상황과 상태 보고서를 자동 생성한다. - 일정 지연, 차단 요소, 위험 요소를 사전에 감지해 관련 담당자에게 전달한다. - 정기 상태 회의나 수동 확인 절차를 줄이고, 필요한 사람에게 필요한 정보만 제공한다. - 팀이 더 빠르게 움직이고, 업무 상황을 더 정확하게 파악할 수 있다. ## 2. 사람 간 업무 라우팅 - 대기열에 쌓인 업무를 담당자의 기술, 현재 업무량, 프로젝트 맥락에 따라 자동 배정한다. - 계획 수립 시점에만 업무를 조정하는 것이 아니라, 프로젝트 진행 중에도 지속적으로 부하를 균형 조정한다. - 에이전트가 왜 특정 담당자에게 업무를 배정했는지 근거를 공개한다. - 사람이 최종 배정 전에 개입하고 수정할 수 있어 자동화와 통제력을 함께 확보한다. ## 3. 팀 커뮤니케이션 지원 - 채널, 메시지 스레드, 회의 녹화 내용을 요약해 핵심 결정과 논점을 전달한다. - 새로 참여한 구성원도 전체 대화 기록을 직접 읽지 않고 업무 맥락을 파악할 수 있다. - 반복 질문과 역할 간 재설명을 줄이고, 동기식 회의 대신 비동기 요약을 활용한다. - 정보 공유 속도와 의사결정 효율을 높인다. ## 4. 채팅 안의 역할별 에이전트 - 팀이 이미 사용하는 Slack 등의 커뮤니케이션 도구 안에 전문 에이전트를 배치한다. - 온보딩 질문, IT 장애 처리, 영업 브리핑 등 역할별 업무를 대화 흐름에서 바로 수행한다. - 예를 들어 메시지에 이모지 반응을 추가하는 것만으로 추적 티켓을 생성할 수 있다. - 별도 포털이나 도구로 이동하지 않아도 대화가 곧 업무 실행의 출발점이 된다. ## 5. 공유되는 대화 맥락 - 에이전트가 여러 사람이 참여한 대화의 스레드와 파일을 지속적으로 인식한다. - 한 사람이 에이전트에게 제공한 정보와 지식이 팀 전체에 공유된다. - 새 구성원이나 다른 에이전트도 이전 작업이 끝난 지점에서 바로 이어서 작업할 수 있다. - 구성원마다 같은 문제를 반복해서 설명하거나 중복 프롬프트를 작성하는 일을 줄인다. ## 6. 역할 기반 접근 제어(RBAC) - 에이전트가 부여받은 역할에 허용된 데이터와 기능만 접근하도록 제한한다. - 권한은 단순한 시스템 단위가 아니라 필드 수준까지 세밀하게 적용될 수 있다. - 권한이 없는 데이터는 에이전트가 읽거나 추론하거나 조작할 수 없다. - 모든 에이전트의 작업을 기록해 규정 준수와 감사에 필요한 추적성을 제공한다. ## 7. 통제된 에이전트 실행 환경 - 에이전트를 코드와 마찬가지로 개발·테스트·운영 환경을 거쳐 배포한다. - 초기 개발 단계에서는 격리된 샌드박스를 사용해 에이전트 간 충돌을 방지한다. - 관리형 승격 파이프라인을 통해 검증되지 않은 에이전트가 운영 환경에 진입하지 않도록 한다. - 운영 중인 에이전트에 대한 무분별한 업데이트가 실제 업무를 중단시키는 위험도 줄인다. ## 8. 에이전트 공동 개발 - 여러 구성원이 에이전트를 공동 소유하고 수정·유지보수할 수 있다. - 역할별 권한을 부여하고, 공유 개발 공간에서 실시간으로 에이전트를 디버깅한다. - 표준화된 프로토콜을 사용해 서로 다른 사람이 만든 에이전트의 호환성을 유지한다. - 에이전트 개발을 개인 작업이 아니라 버전 관리와 협업이 필요한 팀 활동으로 만든다. ## 경쟁 환경에서 드러난 흐름 - 에이전트는 별도 애플리케이션보다 팀이 이미 일하는 채팅 도구 안으로 이동하고 있다. - 조직 규모가 커질수록 권한, 감사 로그, 배포 통제 같은 거버넌스가 필수 요소가 된다. - 에이전트 제작 역시 공동 소유, 협업 수정, 감사 가능한 버전 관리가 기본 기능이 되고 있다. - 상태 회의, 수동 확인, 역할 간 반복 설명 같은 ‘조정 비용’을 에이전트가 줄이기 시작했다. - 경쟁력은 가장 강력한 단일 에이전트보다 여러 에이전트와 사람을 일관된 팀 경험으로 연결하는 데서 나온다. ## 아직 부족한 통합형 거버넌스 - 분석된 플랫폼에서 가장 드문 기능은 다음 요소를 하나로 연결하는 통합 환경이다. - 실행 환경 그룹화 - 에이전트 카탈로그 공유 - 관리형 배포·승격 파이프라인 - 대부분의 플랫폼은 권한 관리나 배포 관리 등 거버넌스의 일부만 해결한다. - 개발부터 운영까지 에이전트를 안전하게 만들고 공유하고 배포하는 전체 흐름을 연결한 사례는 많지 않다. ## GitLab에 대한 시사점 - GitLab은 소프트웨어 개발과 배포 전 과정이 하나의 플랫폼에 있어 에이전트를 외부에서 덧붙일 필요가 적다. - GitLab Duo Agent Platform은 기존 워크플로를 규칙으로 활용하고, 조직의 맥락과 지식을 공유하며, 가드레일로 실행을 통제하는 방향을 취한다. - 따라서 코드 작성뿐 아니라 계획, 개발, 테스트, 보안, 배포 등 전체 DevSecOps 생명주기에서 에이전트를 조율할 수 있다는 것이 글의 결론이다. 팀에 에이전트를 도입할 때는 개별 자동화 기능보다 공유 맥락, 투명한 업무 배정, 세밀한 권한, 테스트·승격 파이프라인, 공동 유지보수 체계를 먼저 설계하는 것이 바람직하다. 그래야 속도 향상뿐 아니라 보안과 책임성까지 확보할 수 있다.

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

AI 에이전트gitlabDevSecOpsgovernance+3

aws·2026년 5월 4일·5분 읽기큐레이션 요약

AWS 주간 요약: AWS 2026의 향후 계획, Amazon Quick, OpenAI 파트너십 등 (2026년 5월 4일) | Amazon Web Services

AWS는 2026년 들어 생성형 AI와 에이전트 중심으로 서비스를 빠르게 확장하고 있다. Amazon Quick은 업무 자동화와 콘텐츠 생성을 강화했고, Amazon Connect는 공급망·채용·고객지원·의료를 아우르는 4개 에이전트 솔루션으로 확대됐다. 또한 AWS와 OpenAI는 Bedrock을 통해 OpenAI 모델과 Codex를 AWS 환경에서 사용할 수 있도록 협력을 강화했다. ## Amazon Quick의 업무 자동화 확대 - Amazon Quick은 앱과 연결해 사용자의 업무 맥락을 파악하고 대신 작업을 수행하는 AI 비서다. - 브라우저 없이 로컬 파일, 캘린더, 커뮤니케이션에 접근할 수 있는 데스크톱 앱을 프리뷰로 제공한다. - AWS 계정 없이 개인 이메일이나 Google, Apple, GitHub, Amazon 계정으로 가입할 수 있다. - 채팅 인터페이스에서 다음 콘텐츠를 직접 생성할 수 있다. - 문서 - 프레젠테이션 - 인포그래픽 - 이미지 - Google Workspace, Zoom, Airtable, Dropbox, Microsoft Teams와의 네이티브 통합이 추가됐다. - 자연어로 지시해 비즈니스 데이터와 연결된 앱, 대시보드, 웹 페이지를 만드는 기능도 프리뷰로 제공된다. ## Amazon Connect의 에이전트 AI 사업 확장 Amazon Connect는 고객센터 제품을 넘어 네 가지 업무 영역별 에이전트 AI 솔루션으로 확대됐다. - **Amazon Connect Decisions** - 공급망 계획 및 인텔리전스 솔루션이다. - Amazon의 30년 운영 노하우와 25개 이상의 공급망 도구를 결합한다. - 문제가 발생한 뒤 대응하는 방식에서 벗어나 선제적 계획 수립을 지원한다. - **Amazon Connect Talent** - 대규모 채용을 위한 에이전트형 AI 채용 솔루션이다. - AI 주도 인터뷰, 과학 기반 평가, 일관된 지원자 평가를 제공한다. - 현재 프리뷰로 제공된다. - **Amazon Connect Customer** - 기존 Amazon Connect를 확장한 고객경험 솔루션이다. - 음성, 채팅, 디지털 채널에서 개인화된 고객 응대를 지원한다. - 대화형 AI를 수개월이 아니라 수주 내 구성할 수 있도록 설정 기능을 강화했다. - **Amazon Connect Health** - 환자 확인, 예약 관리, 환자 인사이트, 주변 대화 기반 문서화, 의료 코딩을 자동화한다. - 환자는 더 빠르게 진료를 받고, 의료진은 문서 작업보다 진료에 집중할 수 있도록 설계됐다. ## AWS와 OpenAI의 Bedrock 협력 - AWS와 OpenAI는 최신 OpenAI 모델을 Amazon Bedrock에서 사용할 수 있도록 제한적 프리뷰를 시작했다. - GPT-5.5와 GPT-5.4 등을 기존 Bedrock API를 통해 사용할 수 있다. - 사용자는 별도 인프라나 새로운 보안 모델을 익히지 않고 Bedrock의 보안, 거버넌스, 비용 관리 체계를 그대로 활용할 수 있다. - **Codex on Amazon Bedrock** - OpenAI의 코딩 에이전트를 기존 AWS 환경에서 실행한다. - AWS 자격 증명으로 인증하고, 추론은 Bedrock을 통해 처리한다. - Codex 사용량을 AWS 클라우드 약정에 반영할 수 있다. - Codex CLI, 데스크톱 앱, Visual Studio Code 확장에서 사용할 수 있다. - **Amazon Bedrock Managed Agents** - OpenAI 모델과 AWS 인프라를 결합해 운영 환경용 에이전트를 구축한다. - OpenAI 하니스를 사용해 장시간 작업의 실행력, 추론, 제어 안정성을 높이는 것을 목표로 한다. ## 고성능 EC2 인스턴스 출시 - **M8in·M8ib** - 6세대 Intel Xeon Scalable 프로세서와 6세대 AWS Nitro 카드를 사용한다. - M6in·M6ib보다 최대 43% 높은 성능을 제공한다. - M8in은 최대 600Gbps 네트워크 대역폭, M8ib는 최대 300Gbps EBS 대역폭을 지원한다. - **R8in·R8ib** - 메모리 최적화 인스턴스다. - 대규모 상용 데이터베이스, 데이터 레이크, SAP HANA 같은 인메모리 데이터베이스에 적합하다. - 최대 600Gbps 네트워크와 300Gbps EBS 대역폭을 제공한다. - **C8ine·M8ine** - 네트워크 최적화 인스턴스다. - C6in·M6in 대비 vCPU당 패킷 처리 성능이 최대 2.5배, 인터넷 게이트웨이 경유 네트워크 처리량이 최대 2배 향상됐다. - 가상 방화벽, 로드 밸런서, 5G UPF 등 보안·네트워크 가상 어플라이언스에 적합하다. ## Bedrock AgentCore의 운영 최적화 - Bedrock AgentCore 프리뷰에 에이전트 개선 기능이 추가됐다. - 운영 환경의 추적 데이터와 평가 결과를 분석해 시스템 프롬프트와 도구 설명 개선안을 추천한다. - 추천 결과는 다음 방식으로 검증할 수 있다. - 사전 정의된 테스트 케이스를 활용한 일괄 평가 - 실제 트래픽을 대상으로 한 A/B 테스트 - 모든 추천 사항은 사용자가 승인해야 운영 환경에 반영된다. - 관찰, 평가, 개선의 반복 과정을 자동화해 운영 중인 에이전트의 품질을 높이는 구조다. ## AWS Lambda와 Ruby 4.0 지원 - AWS Lambda가 최신 LTS 버전인 Ruby 4.0을 관리형 런타임과 컨테이너 기본 이미지로 지원한다. - 고급 로깅 기능을 사용할 수 있다. - JSON 구조화 로그 - 로그 레벨 설정 - 대상 CloudWatch 로그 그룹 지정 - 중국 리전과 AWS GovCloud를 포함한 모든 AWS 리전에서 제공된다. ## Amazon Q Developer에서 Kiro로의 전환 - Amazon Q Developer IDE 플러그인과 유료 구독은 2027년 4월 30일 지원 종료 예정이다. - 신규 가입은 2026년 5월 15일부터 차단된다. - 기존 구독자는 계속 사용자를 추가할 수 있지만, 2026년 5월 29일부터 Q Developer Pro에서 Opus 4.6은 사용할 수 없다. - Opus 4.5 및 기존 모델은 유지되며, 최신 코딩 모델인 Opus 4.7 등은 Kiro에서만 제공된다. - AWS 관리 콘솔의 Amazon Q Developer와 문서, 모바일 앱, Slack, Microsoft Teams 등 AWS의 퍼스트파티 경험은 이번 종료 대상이 아니다. ## 실용적인 시사점 - 기업은 Bedrock을 중심으로 OpenAI 모델과 AWS의 보안·거버넌스·비용 관리 체계를 함께 활용할 수 있게 됐다. - 업무 자동화 도입을 검토한다면 Quick은 문서 생성과 사내 도구 연결에, Connect는 고객지원·채용·공급망·의료 프로세스에 적합하다. - 대규모 데이터베이스나 네트워크 집약적 워크로드는 새 M8·R8·C8 계열의 대역폭과 패킷 처리 성능을 기존 인스턴스와 비교해 검토할 만하다. - Amazon Q Developer 사용 조직은 지원 종료 일정과 Kiro 전환 계획을 미리 점검해야 한다.

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

AI 에이전트AWSamazon-bedrockamazon-ec2+3

netflix·2026년 5월 4일·4분 읽기큐레이션 요약

넷플릭스에서 머신러닝의 민주화: 모델 수명 주기 그래프 구축

Netflix는 ML 자산이 개인화, 스튜디오, 결제, 광고 등 여러 영역으로 확장되면서 모델과 데이터가 각기 다른 시스템에 고립되는 문제를 겪었다. 이를 해결하기 위해 다양한 ML 메타데이터를 통합하는 Metadata Service(MDS)와 Model Lifecycle Graph를 구축했다. MDS는 모델·피처·파이프라인·실험·데이터셋 등의 관계를 연결해 자산의 발견, 계보 추적, 영향 분석, 재사용을 가능하게 하는 기반이다. ## ML 생태계의 확장과 사일로 문제 - Netflix의 ML 활용 영역은 개인화 중심에서 다음과 같이 확대됐다. - 콘텐츠 추천과 사용자 참여 최적화 - 스튜디오의 제작 전후 작업 - 사기 탐지, 결제 라우팅, 정기 결제 최적화 - 광고 타기팅과 실시간 의사결정 - 각 도메인은 서로 다른 기술 스택, 비즈니스 지표, 조직 구조를 사용한다. - 그 결과 모델이 블랙박스처럼 고립되고, 다른 팀이 기존 모델과 데이터를 발견하거나 재사용하기 어려워졌다. - 예를 들어 스튜디오에서 만든 콘텐츠 임베딩은 장면 전환과 콘텐츠 구조를 분석하지만, 광고의 문맥 매칭이나 개인화 추천에도 활용될 수 있다. - 그러나 모델 레지스트리, 파이프라인 오케스트레이터, 실험 플랫폼이 분리되어 있어 다음 질문에 답하기 어렵다. - 어떤 피처와 데이터 소스가 존재하는가? - 특정 모델은 어떤 파이프라인과 데이터로 생성되는가? - 해당 모델을 사용하는 A/B 테스트는 무엇인가? - 피처를 변경하면 어떤 모델이 영향을 받는가? - 각 자산의 담당자는 누구인가? ## 통합 UI보다 어려운 메타데이터 연결 - 문제의 본질은 화면을 하나로 합치는 것이 아니라, ML 라이프사이클의 서로 다른 구성 요소를 연결하는 것이다. - Netflix에는 다음과 같은 시스템이 각각 메타데이터를 생성한다. - 파이프라인 오케스트레이션: 실행 정보, 단계 의존성, 데이터 변환 - 모델 레지스트리: 모델 버전, 아티팩트, 오래된 모델 여부, 배포 이력 - 실험 플랫폼: A/B 테스트와 설정 - 피처 스토어: 피처 정의와 사용처 - AI Dataset 플랫폼: 데이터셋 생성, 관리, 검색, 로딩 - Identity 플랫폼: 사용자, 팀, 조직 정보 - 시스템마다 데이터 형식, 식별자, 개념 모델이 다르기 때문에 이질적인 메타데이터를 하나의 엔터티 모델로 변환하고 관계 그래프로 만드는 작업이 핵심 기술 과제가 됐다. ## Metadata Service와 Model Lifecycle Graph - MDS는 Netflix 전반의 ML 관련 엔터티를 색인하고 서로 연결하는 서비스다. - 모델, 피처, 파이프라인, 실험, 데이터셋 등의 메타데이터를 실시간으로 수집한다. - 다음과 같은 교차 도메인 질의를 지원하는 것을 목표로 한다. - 특정 모델을 실행 중인 실험은 무엇인가? - 특정 피처를 공유하는 모델은 무엇인가? - 모델에 사용된 데이터와 생성 파이프라인은 무엇인가? - MDS의 역할은 다음과 같다. - 여러 시스템에서 이벤트 수집 - 메타데이터에 조직·소유자 등 추가 맥락 결합 - ML 자산 간 관계 추론 및 구체화 - 연결된 그래프 형태로 탐색 가능하게 제공 - 궁극적인 목표는 모든 ML 자산을 팀과 도메인에 관계없이 발견하고, 이해하고, 재사용할 수 있도록 만드는 것이다. ## URI 기반 핵심 추상화 MDS는 시스템 간 일관된 연결을 위해 AI Platform URI를 사용한다. - **Component** - 고유한 URI로 주소 지정할 수 있는 모든 객체다. - 형식은 다음과 같다. ```text aip://<componentType>/<platformId>/<resourceId> ``` - 예: ```text aip://model/registry/ranking-v5 aip://user/identity/alice aip://pipeline/orchestrator/weekly-training ``` - **Entity** - 이름, 설명, 생성일, 소유자 등 추가 속성을 가진 ML 생태계의 구성 요소다. - 모델, 피처, 파이프라인 등이 이에 해당한다. - **Entity Type** - 동일한 데이터 구조와 속성·관계 제약을 공유하는 엔터티 집합이다. - **Domain** - 관련 엔터티 타입을 묶고 해당 ML 자산 범주의 추상 인터페이스를 정의한다. - 예를 들어 Models 도메인은 Model과 Model Instance를, Pipelines 도메인은 Schedule·Request·Execution을 정의한다. - **Provider** - 도메인을 실제로 구현하는 특정 소스 시스템이다. - 하나의 도메인에 여러 Provider를 연결할 수 있어, 모델 레지스트리가 교체되더라도 도메인 인터페이스를 변경하지 않고 확장할 수 있다. - URI는 서비스 간 ML 자산 참조를 단일 문자열로 통일하고, MDS가 이를 풍부한 메타데이터와 연결된 관계로 해석할 수 있게 한다. ## 이벤트에서 엔터티와 그래프로 - MDS는 Kafka와 AWS SNS/SQS를 통해 소스 시스템의 이벤트를 실시간으로 수집한다. - 소스 시스템은 식별자와 이벤트 유형 중심의 얇은 이벤트를 발행한다. - 예시는 다음과 같다. ```json { "event_type": "model_instance_created", "instance_id": "ranking-model-v5-20XX0101" } ``` - 생산 시스템은 복잡한 그래프 로직을 알 필요 없이 간단한 이벤트만 발행하고, MDS가 이를 엔터티로 변환하고 다른 시스템의 정보와 결합한다. - 이후 모델, 파이프라인, 피처, A/B 테스트 등의 관계를 추론해 질의 가능한 Model Lifecycle Graph로 materialize한다. - 이를 통해 모델 생성 이벤트와 실험 설정을 연결하는 것처럼, 서로 다른 시스템에 존재하는 관계도 하나의 그래프에서 탐색할 수 있다. MDS와 Model Lifecycle Graph는 단순한 모델 카탈로그가 아니라, ML 자산의 생성부터 배포·실험·재사용까지를 연결하는 메타데이터 인프라다. 여러 팀이 공통 URI와 엔터티 모델을 사용하도록 만들면 모델의 검색성, 의존성 파악, 변경 영향 분석, 조직 간 재사용이 크게 향상된다.

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

머신러닝Apache Kafkafeature-storegraph-database+3

gitlab·2026년 5월 4일·4분 읽기큐레이션 요약

Atlassian이 여러분의 데이터를 학습에 사용합니다: GitLab으로 거부하세요

Atlassian은 2026년 8월 17일부터 Jira, Confluence 등 클라우드 제품의 메타데이터와 인앱 콘텐츠를 AI 서비스 학습에 기본적으로 활용할 예정이다. Free·Standard·Premium 고객은 메타데이터 수집을 끌 수 없고, Enterprise 고객만 옵트아웃할 수 있어 데이터 거버넌스와 규제 준수에 큰 부담이 생긴다. 글은 이러한 옵트아웃 기본 정책과 달리, GitLab은 요금제와 관계없이 고객 데이터를 수집하거나 AI 학습에 사용하지 않는 접근을 취한다고 설명한다. ## Atlassian의 데이터 수집 정책 변경 - 수집 대상은 크게 두 가지다. - **메타데이터**: 스토리 포인트, 스프린트 날짜, SLA 값, 작업 분류, Teamwork Graph 및 연결된 외부 앱의 운영 신호 - **인앱 콘텐츠**: Confluence 페이지, Jira 이슈 제목·설명·댓글 등 사용자가 작성한 내용 - Atlassian은 학습 전에 데이터를 비식별화하고 집계한다고 설명한다. - 수집 데이터는 최대 7년 보관될 수 있다. - 옵트아웃하면 인앱 데이터는 30일 이내 삭제되고, 관련 모델은 90일 이내 재학습된다고 안내한다. - 고객 관리 암호화 키, Government Cloud, Isolated Cloud, HIPAA 적용 고객은 수집 대상에서 제외된다. ## 요금제에 따른 옵트아웃 문제 - 모든 클라우드 고객에게 데이터 수집이 기본 활성화된다. - Free, Standard, Premium 고객은 메타데이터 수집을 비활성화할 수 없다. - Enterprise 고객만 옵트아웃할 수 있으며, 최소 801명의 사용자가 필요하고 별도 가격이 적용된다. - 결과적으로 데이터 보호가 기술 설정이 아니라 고비용 Enterprise 요금제로의 업그레이드 여부에 달려 있다. - Atlassian이 과거에 밝혔던 “고객 데이터를 AI 서비스 학습이나 개선에 사용하지 않는다”는 입장과도 달라졌다. ## 비식별 메타데이터도 민감할 수 있는 이유 - 스토리 포인트, 스프린트 속도, SLA 지표는 개별적으로는 민감하지 않아 보일 수 있다. - 그러나 장기간 축적하면 다음 정보를 추론할 수 있다. - 조직의 프로젝트 구조 - 팀별 생산성과 성과 패턴 - 릴리스 및 업무 처리 주기 - 운영 방식과 병목 구간 - 데이터가 비식별화되더라도 여러 신호를 결합하면 조직의 운영 특성을 재구성할 수 있으므로, 비식별화가 곧 비민감성을 의미하지는 않는다. ## Atlassian 생태계에서 커지는 데이터 범위 - Jira와 Confluence는 스프린트 계획, 버그 추적, 릴리스 관리, 보안 티켓, 사고 보고서, 내부 문서의 시스템 오브 레코드로 사용된다. - Bitbucket과 Bamboo까지 함께 사용하면 다음 정보도 데이터 흐름에 포함될 수 있다. - 소스 코드 관련 메타데이터 - CI/CD 구성 - 프로젝트 계획과 기술 문서 - Teamwork Graph 커넥터를 통해 Slack, Figma, Google Drive, Salesforce, ServiceNow 같은 외부 서비스의 관계·활동 신호도 연결될 수 있다. - 따라서 보안·컴플라이언스 팀은 Atlassian 제품 내부뿐 아니라 연결된 제3자 서비스까지 포함해 데이터 흐름을 검토해야 한다. - Data Center·Server에서 Atlassian Cloud로 이전하려는 조직은 클라우드 전환과 AI 학습 데이터 제공 문제를 함께 판단해야 한다. ## 옵트아웃 기본 정책의 거버넌스 공백 - 약관 변경만으로 데이터 처리 방식이 바뀌면 고객이 직접 변경 사항을 발견하고 위험을 평가해야 한다. - 다음 항목이 기존 계약 및 내부 정책과 일치하는지 확인해야 한다. - 데이터 처리 계약(DPA) - “메타데이터”의 정의 - 제3자 앱에서 유입되는 데이터 범위 - 보관 기간과 삭제 절차 - AI 모델 재학습 및 삭제 방식 - 조직의 법무·보안팀이 민감하다고 판단하는 정보가 Atlassian의 “비민감 메타데이터” 정의와 다를 수 있다. ## 규제 산업이 재평가해야 할 사항 - 금융 서비스 기업은 SR 11-7, DORA 등에 따라 외부 기술 제공업체의 데이터 처리와 통제를 문서화하고 감사 가능하게 관리해야 한다. - 공공 부문은 NIST 800-53과 FISMA에 따라 민감 데이터의 이동과 접근을 통제해야 한다. - 의료 분야에서는 HIPAA에 따른 제3자 데이터 처리 검토가 필요하다. - EU AI Act 적용 조직은 미국식 옵트아웃보다 유럽 규제 환경의 옵트인 동의 기대와 충돌할 가능성을 검토해야 한다. - 기존에 Atlassian의 데이터 처리 방식을 평가했다면, “고객 데이터를 학습에 사용하지 않는다”에서 “기본적으로 사용한다”로의 변경은 공급업체 위험평가와 관련 문서의 갱신 사유가 된다. ## GitLab의 대안적 접근 - GitLab은 고객 데이터에 대해 다음 원칙을 제시한다. - 고객 데이터 수집 없음 - 고객 데이터로 AI 모델 학습 없음 - 요금제와 관계없이 동일한 데이터 보호 원칙 적용 - 핵심 차이는 데이터 보호를 Enterprise 같은 특정 고가 요금제의 기능으로 제한하지 않는다는 점이다. - 글은 CTO와 CISO가 AI 도입을 규제기관, 이사회, 고객에게 설명할 수 있어야 하며, 이를 위해 명확하고 조건 없는 데이터 처리 약속이 필요하다고 주장한다. ## 실용적인 대응 - 2026년 8월 17일 이전에 Atlassian 데이터 흐름과 연결 앱 목록을 재검토한다. - Jira·Confluence의 콘텐츠뿐 아니라 Teamwork Graph가 가져오는 외부 서비스 메타데이터도 목록화한다. - DPA, 개인정보 처리방침, 보안 정책, 규제 준수 문서를 변경된 정책과 대조한다. - Enterprise 업그레이드, 예외 환경 사용, 플랫폼 이전 등 가능한 대응책의 비용과 위험을 비교한다. - AI 기능을 도입할 때는 옵트아웃 가능 여부보다 처음부터 고객 데이터를 학습에 사용하지 않는 공급업체 정책을 우선 검토하는 것이 권장된다.

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

gitlab클라우드 컴퓨팅jiradata-privacy+3

figma·2026년 5월 4일·3분 읽기큐레이션 요약

PGKeeper: Postgres에 꼭 필요했던 보안관 만들기 | Figma 블로그

Figma는 데이터베이스 트래픽과 제품 규모가 커지면서 기존 PgBouncer의 확장성·부하 제어·연결 관리 한계에 부딪혔고, 이를 대체할 자체 서비스 PGKeeper를 구축했다. PGKeeper는 DBProxy와 PostgreSQL 사이에서 연결 풀링과 트래픽 관리를 담당하며, 과부하로부터 데이터베이스와 연결을 보호하는 것을 목표로 한다. 글은 Figma의 데이터베이스 구조와 PgBouncer를 교체하게 된 이유, 그리고 PGKeeper를 직접 개발한 배경을 설명한다. ## Figma의 PostgreSQL 데이터베이스 구조 - PostgreSQL은 Figma의 OLTP 시스템 기반이다. - 데이터 증가에 대응하기 위해 데이터베이스를 수평·수직으로 확장하고 여러 PostgreSQL 인스턴스를 운영했다. - 애플리케이션이 샤딩 구조를 직접 알 필요 없도록 **DBProxy**라는 요청 라우팅 계층을 구축했다. - DBProxy는 쿼리를 분석해 적절한 PostgreSQL 인스턴스를 선택하고, 필요하면 여러 인스턴스를 대상으로 쿼리를 재작성한다. - DBProxy와 PostgreSQL 사이에는 연결 풀러가 위치한다. - 각 PostgreSQL 머신에는 전용 연결 풀러 복제본 그룹이 배치되어, 여러 풀러가 하나의 데이터베이스에 연결되는 n-to-1 구조를 이룬다. ## PgBouncer가 한계에 도달한 이유 - **확장성 부족** - PgBouncer는 단일 스레드 아키텍처라 수직 확장에 한계가 있었다. - 복제본을 늘려 수평 확장했지만 트래픽 분배가 치우치면서 성능 저하가 발생했다. - **정교한 부하 관리 부재** - 중요한 트래픽을 낮은 우선순위의 문제성 트래픽보다 먼저 처리할 수 없었다. - 백프레셔가 없어 급격한 트래픽 증가를 우아하게 제어하기 어려웠다. - 대기 시간에 기반해 작업을 버리는 CoDel(Controlled Delay) 같은 부하 완화 알고리즘도 지원하지 않았다. - **연결 폭증과 연결 churn 위험** - PostgreSQL 연결은 많은 자원을 사용한다. - 연결이 빠르게 생성되거나 과도하게 재생성되면 데이터베이스 안정성이 크게 떨어진다. - 장애 이후 무제한으로 연결을 다시 만들면 복구 과정 자체가 PostgreSQL을 압박할 수 있다. - 이로 인해 연결 churn과 연쇄적인 과부하가 장시간 지속될 수 있다. - **확장성과 운영 제어의 한계** - 트래픽 유형별 admission control, 공정한 자원 분배 등 세밀한 정책이 필요했다. - 심층적인 관측성, 기능 플래그 기반의 안전한 롤아웃도 요구됐다. - PgBouncer에 작은 수정 사항을 유지하는 것만으로도 부담이 컸기 때문에, 대규모 확장은 장기적인 유지보수 비용을 초래할 가능성이 컸다. ## DBProxy에 연결 풀링을 통합하지 않은 이유 - PostgreSQL 인스턴스 하나의 연결 풀은 대략 100개 규모로 운영됐다. - 반면 DBProxy는 수백 개의 상태 비저장 복제본으로 구성됐다. - 각 DBProxy가 독립적으로 연결 풀을 관리하면: - 전체 PostgreSQL 연결 제한을 초과할 수 있고, - 복제본 간 복잡한 조정이 필요하며, - 고정된 소규모 연결 풀을 수백 개 인스턴스에 분산하기 어렵다. - 따라서 연결 풀링은 DBProxy 내부가 아니라 별도의 중앙화된 계층에서 담당해야 했다. ## PGCat 대신 자체 서비스를 만든 배경 - Figma는 PgBouncer의 단일 스레드 한계를 해결하기 위해 멀티스레드 PostgreSQL 프록시인 PGCat도 검토했다. - 그러나 필요한 기능을 추가하려면 PGCat의 핵심 실행 경로를 크게 수정해야 했다. - 관측성, 기능 플래그, admission control을 upstream에 반영하기도 쉽지 않았다. - 결국 PGCat을 포크해 장기적으로 유지해야 할 가능성이 높았으므로, Figma는 요구사항에 맞는 Go 기반 자체 서비스 **PGKeeper**를 개발했다. ## PGKeeper의 역할 - PGKeeper는 DBProxy와 PostgreSQL 사이에 위치하는 Go 서비스다. - 주요 목적은 다음과 같다. - 데이터베이스를 과도하거나 잘못된 트래픽으로부터 보호 - PostgreSQL 연결의 급격한 생성과 churn 방지 - 트래픽 우선순위와 자원 사용을 세밀하게 제어 - 대규모 환경에 맞는 확장성과 운영 도구 제공 - 이름은 골키퍼처럼 위험한 트래픽이 시스템을 압도하지 못하도록 막고, 연결 자체도 보호한다는 의미에서 붙여졌다. Figma의 사례는 단순히 연결 풀러를 교체한 것이 아니라, 데이터베이스 앞단에서 트래픽을 선별하고 과부하를 제어하는 별도 인프라 계층이 필요해졌음을 보여준다. PostgreSQL 연결 수가 제한적이고 프록시 복제본이 많은 환경에서는 풀링을 애플리케이션 프록시에 분산하기보다, 독립적인 계층으로 관리하는 편이 적합하다.

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

PostgreSQLGodatabase-shardingload-balancing+3

discord·2026년 5월 4일·4분 읽기큐레이션 요약

Discord 패치 노트: 2026년 5월 4일

Discord의 2026년 5월 4일 패치 노트는 성능·안정성·사용성 개선과 다양한 버그 수정을 다룬다. 특히 서버 관리 및 권한 관련 문제를 집중적으로 해결했고, Android 동영상 시작 속도와 Soundboard 접근성을 개선했다. 데스크톱 설정 구조를 단순화하고 Linux 자동 업데이트도 지원해 전반적인 사용 편의성을 높였다. ## 서버 관리와 권한 문제 개선 - 서버 관리자용 기능에서 권한, 사용자 상태, 계정 안전 기능과 관련된 여러 오류를 수정했다. - Community 설정의 “Discord 관리자 서버 참여” 팝업을 닫아도 나중에 다시 참여할 수 있도록 버튼이 사라지지 않게 했다. - 서버 부스트 결제 화면에서 `ESC`를 눌렀을 때 결제 창이 아니라 뒤쪽의 부스트 페이지가 닫히던 문제를 해결했다. - 서버 프로필 편집 중 저장하지 않은 변경 사항이 있을 때, 모달 바깥을 클릭해도 경고 없이 닫히지 않도록 동작을 개선했다. - 서버별 프로필의 대명사를 지울 때 기본 프로필의 대명사가 자동 입력되던 문제를 수정하고, 기본 대명사는 placeholder로 표시한다. - 서버별 아바타의 링크를 복사할 때 기본 프로필 아바타 링크가 복사되던 문제를 해결했다. ## Android 동영상과 모바일 성능 - Android의 동영상 전송 네트워크 스택을 추가로 조정했다. - Android에서 동영상 피드가 시작되는 속도가 약 4.89% 빨라졌으며, 평균 시작 시간이 600ms 미만으로 줄었다. - 모바일에서 검색 결과를 불러오는 중 연결이 끊겼을 때 오류 메시지가 반복 표시되거나 요청을 무한 재시도하던 문제를 수정했다. - Media, Pins, Files, Links 탭에서 네트워크 오류가 발생해도 불필요한 재시도가 반복되지 않는다. - Android 검색 필터가 활성화되어도 파란색으로 표시되지 않던 시각적 문제를 해결했다. - iOS에서 프로필 또는 앱 소개의 링크를 눌렀을 때 발생하던 충돌을 수정했다. - iOS에서 기본 프로필의 사용자 이름을 복사한 뒤 서버별 프로필 화면으로 되돌아가던 문제도 해결했다. ## 데스크톱 설정 구조 개편 - 기존 Appearance, Accessibility, Chat, Streamer Mode, Advanced 설정을 다음 세 페이지로 통합했다. - Appearance - Accessibility - Developer - 일부 설정의 배치와 문구를 명확하게 변경했다. - “Sync Themes Across My Devices”를 다시 활성화했을 때 현재 테마가 이전에 동기화된 테마로 되돌아가던 문제를 수정했다. - 최근 아바타에 마우스를 올렸을 때 삭제 버튼이 보이지 않던 문제를 해결했다. - 프로필 편집 모달의 저장 변경사항 표시줄이 Legacy Username Badge 토글과 겹치던 문제를 수정했다. - “Connect Your Domain” 화면의 버튼 간격이 지나치게 좁거나 가장자리에 붙던 레이아웃 문제를 개선했다. - 프랑스어 환경에서 Poll 검색 필터인 `sondage`가 `Son`과 `dage`로 잘못 분리되던 문제를 해결했다. ## Soundboard와 음성 채널 로딩 - Soundboard 데이터를 처음 열 때가 아니라 음성 채널에 참가할 때 미리 가져오도록 변경했다. - 그 결과 음성 통화 중 Soundboard를 처음 사용할 때의 로딩 시간이 줄었다. - 작은 로딩 속도 개선만으로도 Soundboard 효과 사용량이 측정 가능하게 증가했다고 설명한다. ## Linux 업데이트와 패키지 지원 - Windows에서 사용하던 Rust 기반 자동 업데이트 시스템을 Linux에도 적용했다. - 이제 Linux 사용자는 새 버전을 직접 내려받아 설치하지 않고 앱 자체에서 업데이트할 수 있다. - 설치 패키지 형식으로 `.rpm`과 `.pkg.tar.zst`도 추가 지원한다. ## 기타 일반 버그 수정 - “Copy Username” 기능의 `GODLIKE!!`, `BEYOND GODLIKE!!` 메시지 배경이 투명하게 보이던 문제를 수정했다. 배경색은 기존 빨간색 대신 초록색으로 통일했다. - Quick Switcher에 초대 링크를 붙여 넣으면 해당 서버에 참가하고 바로 이동할 수 있게 됐다. - Active Now 창에서 사용자 이름에 마우스를 올릴 때 상태 표시기가 흰색으로 변하던 문제를 해결했다. - 모바일 검색 결과에서 긴 닉네임이 메시지 타임스탬프를 가리던 문제를 수정했다. - Server Boost 홍보 화면의 오디오가 결제 흐름으로 이동한 뒤에도 계속 재생되던 문제를 해결했다. - 알림을 빠르게 여러 개 삭제할 때 Inbox가 충돌하던 문제를 수정했다. - Nitro 탭에서 Nitro 가입 기간 보상 배지를 눌러도 사라지지 않던 문제를 해결했다. - 구독 설정에서 `GBP` 통화명이 비어 보이던 문제를 수정했다. - Inbox의 Unreads 미리보기에서 만료된 공개 이미지 링크가 표시되지 않던 문제를 해결했다. - 친구 요청 이메일에 오래된 `#0` discriminator가 표시되던 문제를 수정했다. - Nitro 체험 대상 친구를 선택하는 체크박스가 실제로 선택되지 않던 문제를 해결했다. - 사용자 프로필에서 Custom Status 편집 창을 열 때 전체 프로필을 대체하지 않고 위에 표시되도록 변경했다. - 프로필, 서버 부스트, 검색, 알림, 결제 등 여러 화면의 모달·버튼·레이아웃 관련 세부 오류를 정리했다. ## 적용 일정과 테스트 참여 - 모든 수정 사항은 코드에 반영되고 병합되었지만, 플랫폼별로 실제 배포되는 시점은 다를 수 있다. - 사용자는 커뮤니티의 격월 버그 메가스레드에 문제를 신고할 수 있다. - iOS 사용자는 TestFlight 버전에 참여해 정식 출시 전 기능과 수정 사항을 시험할 수 있다. 이번 업데이트는 대규모 신기능보다 서버 관리자 기능의 신뢰성, 모바일 성능, 설정 탐색성, 플랫폼별 업데이트 편의성을 높이는 데 초점을 맞췄다. Discord를 관리하거나 Android·Linux·데스크톱 앱을 주로 사용하는 사용자는 업데이트 후 관련 기능의 개선 여부를 확인해 보는 것이 좋다.

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

discordAndroidiOSRust+3