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

AWS Transform로 기술 부채를 선제적으로 자율적으로 줄이기 – 지속적인 현대화(프리뷰) | Amazon Web Services

AWS Transform – continuous modernization은 수천 개 저장소의 기술 부채를 지속적으로 분석하고, 우선순위를 정한 뒤 자동으로 수정 PR까지 생성하는 기능이다. 저장소 상태를 수작업 보고가 아닌 실제 코드 기반으로 파악하며, 의존성 만료·보안 취약점·폐기된 프레임워크 등을 조직 정책에 따라 관리할 수 있다. 이를 통해 개발자가 따라가기 어려운 기술 부채를 지속적이고 자율적으로 줄이는 것이 목표다. ## 지속적인 기술 부채 분석 - AWS Transform이 연결된 코드 저장소를 설정된 기준선(baseline)과 비교해 자동 분석한다. - 분석 결과는 수주가 아니라 수시간 내에 생성된다. - 기본 정책으로 다음과 같은 문제를 탐지한다. - 수명 종료(EOL)에 가까워진 의존성 - 폐기된 프레임워크 - 일반적인 기술 부채 패턴 - 조직별 정책도 추가할 수 있다. - 승인된 라이브러리 사용 여부 - 사내 코딩 표준 - 특정 로깅 패턴 - 더 이상 사용하지 않는 내부 라이브러리 - 저장소별로 기준선에서 얼마나 뒤처졌는지, 영향받는 파일 수, 심각도, 탐지된 패턴을 확인할 수 있다. - 팀의 자체 보고나 수동 점검 대신 코드에서 직접 현재 상태를 확인하므로, 플랫폼 팀이 조직 전체의 기술 부채를 항상 최신 상태로 파악할 수 있다. ## 우선순위 기반 기술 부채 관리 - 여러 저장소에서 발견된 문제를 하나의 목록으로 통합한다. - 심각도, 범주, 저장소 등의 기준으로 문제를 정렬하고 우선순위를 지정할 수 있다. - 개발 조직이 사용하는 여러 도구를 대체하거나 통합하는 것을 목표로 한다. - 의존성 검사 도구 - 보안 취약점 도구 - 코드 품질 도구 - AI 코딩 에이전트로 코드 변경 속도가 빨라질수록 기술 부채도 빠르게 쌓일 수 있다는 문제에 대응한다. ## 자동 수정 PR 생성 - 우선순위가 정해진 문제에 대해 자동 remediation을 실행할 수 있다. - 영향을 받는 각 저장소에 수정 PR을 자동으로 생성한다. - 기본 제공되는 변환 예시는 다음과 같다. - Java 버전 업그레이드 - SDK 마이그레이션 - 라이브러리 업데이트 - 조직 고유의 변환 규칙을 직접 만들어 사용할 수도 있다. - 담당 팀은 생성된 PR을 검토·병합하거나 자체 방식으로 문제를 수정할 수 있다. - 이후 지속 분석이 실제 수정 여부를 확인하므로, 팀의 수동 완료 보고가 필요하지 않다. ## 보안 취약점과 기술 부채의 통합 관리 - AWS Security Agent와 연동해 소스 코드 수준의 보안 취약점을 탐지하고 수정할 수 있다. - 보안 문제도 일반적인 기술 부채와 같은 우선순위 목록에 포함된다. - 탐지부터 수정 PR 생성, 병합 후 준수 상태 확인까지 동일한 워크플로로 처리된다. ## AWS Transform 사용 흐름 - AWS Transform 웹 애플리케이션에서 소스 제어 시스템을 연결한다. - 조직 정책과 기준선을 설정한 뒤 저장소 분석을 시작한다. - 대시보드에서 다음 정보를 확인한다. - 전체 저장소 현황 - 기준선 미준수 저장소 - 기술 부채의 심각도와 범주 - 영향받는 파일 수 - 높은 우선순위 항목을 선택해 remediation 캠페인을 실행한다. - 저장소별 PR 생성, 병합 여부, 기준선 준수 상태를 실시간으로 추적한다. - GitHub 및 로컬 환경의 저장소를 소스로 연결할 수 있다. ## 지속 모드와 캠페인 모드 - **지속 모드** - 일상적인 유지보수와 반복적인 현대화에 적합하다. - 라이브러리 업데이트, 보안 패치, 코딩 표준 적용 등을 지속적으로 수행한다. - 조직 기준선이 변경되면 저장소의 새로운 미준수 상태를 찾아낸다. - **캠페인 모드** - 대규모이면서 일회성에 가까운 현대화 작업에 적합하다. - 수백 개 애플리케이션의 런타임 업그레이드나 프레임워크 전환 등에 사용할 수 있다. - AWS Transform custom은 이러한 프로젝트형 작업을 위한 유연한 도구로 계속 제공된다. ## 제공 방식과 활용 시점 - 현재 프리뷰로 제공된다. - AWS Transform 웹 애플리케이션에서 사용할 수 있다. - AWS Transform Kiro Power, MCP, skills를 통해 기존 코딩 에이전트와 통합할 수 있다. - 플랫폼 팀이 다수 저장소의 반복적인 업그레이드와 정책 준수를 관리해야 한다면, 지속 분석과 자동 PR 생성을 활용하는 것이 효과적이다.

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

모델 컨텍스트 프로토콜Javaaws-lambdapull-requests+4

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

AWS Security Agent, 위협 모델링·Kiro 기능·Claude Code 플러그인 등을 추가 | Amazon Web Services

AWS Security Agent는 설계부터 개발, 배포까지 애플리케이션의 전체 생명주기를 보안하는 에이전트형 서비스다. 이번 업데이트에서는 PR·전체 저장소 코드 리뷰, STRIDE 기반 위협 모델링, 규정 준수 팩, GitLab·Bitbucket·Confluence 연동이 추가됐다. 또한 Kiro, Claude Code, MCP를 통해 IDE나 CLI에서 보안 점검과 취약점 수정까지 수행할 수 있다. ## PR 및 전체 저장소 코드 리뷰 강화 - GitHub뿐 아니라 GitLab과 Bitbucket을 지원하며, SaaS 및 자체 호스팅 환경 모두에서 사용할 수 있다. - Confluence 문서를 리뷰 컨텍스트로 연결해 기존 설계·보안 문서를 분석에 활용한다. - 단순 패턴 매칭이 아니라 애플리케이션의 맥락을 이해하는 추론 기반 분석을 수행한다. - PR 변경 사항과 전체 저장소를 대상으로 복잡한 취약점을 탐지한다. - 조직의 보안 요구사항과 일반적인 보안 위험을 함께 검사한다. - 탐지된 결과에 대해 다음 기능을 제공한다. - 수정 커밋 - 구체적인 remediation 가이드 - 시뮬레이션 환경에서의 검증 - 실제 악용 가능성을 보여주는 proof of exploitability - 보안팀은 모니터링할 저장소를 설정하고 중요 이슈에 개입할 수 있다. ## 보안 요구사항과 규정 준수 검토 - 설계 및 코드 리뷰 과정에서 보안 요구사항을 지속적으로 검증한다. - 관리형 컴플라이언스 팩을 제공한다. - AWS WAF - NIST CSF - PCI DSS - AWS 모범 사례 - 조직 내부 문서나 Confluence에서 자체 보안 요구사항을 가져올 수 있다. - 각 탐지 결과를 조직의 컴플라이언스 상태와 연결해 감사 대응과 추적성을 높인다. ## STRIDE 기반 위협 모델링 - 설계 문서나 소스 코드 저장소를 분석해 애플리케이션의 전체 보안 맥락을 구성한다. - 다음 요소를 모델링한다. - 시스템 구성 요소 - 데이터 흐름 - 아키텍처 - 신뢰 경계 - 잠재적 위협 행위자 - 공격 벡터 - STRIDE 프레임워크를 사용해 위협을 분류하고 취약한 지점을 식별한다. - 발견한 위협의 우선순위를 지정해 먼저 해결해야 할 위험을 판단하도록 돕는다. - 콘솔에서 위협 모델 기능과 소스 코드 저장소를 연결해 사용할 수 있다. ## Kiro·Claude Code·MCP 통합 - Kiro용 파워를 제공하며 Claude Code 플러그인도 출시 예정이다. - 공개 MCP 통합을 통해 Kiro, Claude Code, 기타 AI 기반 IDE에서 기능을 호출할 수 있다. - IDE나 CLI 화면 안에서 결과를 확인할 수 있어 별도 콘솔로 이동할 필요가 줄어든다. - Kiro에서 다음과 같은 자연어 명령을 사용할 수 있다. - `Set up AWS Security Agent` - `Run a full security scan on this repo` - `help me remediate my findings` - `Build a threat model for this application` ## 개발 환경에서의 취약점 수정 흐름 - 전체 저장소 보안 스캔으로 누적된 위험을 찾을 수 있다. - Kiro의 Agent Hook을 사용하면 에이전트 작업이 끝난 뒤 PR diff 스캔을 자동으로 시작할 수 있다. - 발견 결과를 로컬 워크스페이스로 가져와 심각도가 가장 높은 문제부터 처리할 수 있다. - 수정 과정에서 버그 수정 명세 세션을 시작하고 기존 IDE 도구, MCP 서버, 자동화 기능을 함께 사용할 수 있다. - 생성된 위협 모델은 `.security-agent/threat_model.md`에 저장된다. - 배포 전에는 CLI에서 침투 테스트를 실행해 일반적인 스캐너가 놓치는 위험까지 확인할 수 있다. ## 생명주기 전체를 아우르는 통합 보안 - 설계 단계: - 설계 리뷰 - 위협 모델링 - 개발 단계: - PR 및 전체 저장소 코드 리뷰 - 자동 수정 및 검증 - 배포 단계: - 온디맨드 침투 테스트 - 하나의 에이전트형 서비스에서 위협 식별, 악용 가능성 검증, 수정 코드 생성까지 연결한다. - 기능은 AWS Security Agent가 제공되는 AWS 상용 리전에서 사용할 수 있으며, 가격과 2개월 무료 체험 여부는 별도 가격 페이지에서 확인해야 한다. AWS Security Agent는 보안 검사를 별도 절차로 분리하기보다 개발 흐름에 직접 삽입하려는 서비스다. AWS 환경과 지원되는 저장소·IDE를 사용한다면 PR 자동 검사, 조직별 보안 요구사항 등록, 위협 모델 파일 생성부터 단계적으로 도입하는 것이 실용적이다.

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

모델 컨텍스트 프로토콜코드 리뷰claude-codethreat-modeling+3

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

Cloudflare One 스택 소개: 에이전트 기반 배포

Cloudflare는 Zero Trust 도입·마이그레이션·운영을 에이전트가 수행하도록 돕는 “Cloudflare One stack”을 공개했습니다. 이 스택은 Cloudflare One 제품 지식, 의사결정 트리, 마이그레이션 로직, API 도구를 제공해 기존 네트워크를 분석하고 안전한 배포 계획과 설정을 생성합니다. 특히 Zscaler·Palo Alto Networks 등 기존 SASE 솔루션에서 Cloudflare로 이전하는 작업을 자동화하고, 운영 중인 환경의 문제 해결까지 지원하는 것이 핵심입니다. ## 네트워크 보안에서의 에이전트 활용 격차 - 조직은 이미 에이전트를 코드 작성, 보안 알림 분류, 업무 자동화에 활용하고 있습니다. - 그러나 에이전트가 조직별 네트워크 토폴로지, 인증 정책, 트래픽 흐름, 기존 공급업체 설정을 자동으로 이해하기는 어렵습니다. - Cloudflare One stack은 이러한 부족한 맥락을 보완하기 위해 Cloudflare 제품에 대한 권위 있고 구체적인 지침을 제공합니다. - 이를 통해 에이전트가 일반적인 API 호출이 아니라 권장된 보안·배포 절차에 따라 작업하도록 합니다. ## Cloudflare One stack의 구성 - 어떤 에이전트와도 사용할 수 있는 스킬 모음으로 제공됩니다. - 두 개의 경량 스킬 파일로 구성됩니다. - `cloudflare-one`: Cloudflare One 구축, 관리, 운영, 문제 해결 - `cloudflare-one-migration`: 다른 SASE 제품에서 Cloudflare로의 마이그레이션 - Cloudflare One 고객 지원 과정에서 축적된 수만 시간의 실무 지식을 기반으로 제작되었습니다. - Cloudflare Code Mode MCP 서버와 함께 사용하면 Cloudflare API에 타입이 지정된 인터페이스로 접근할 수 있습니다. - 에이전트는 실시간 계정 정보를 조회하고, 현재 설정을 검사하며, 검증된 방식으로 변경을 수행할 수 있습니다. ## 지원하는 Cloudflare One 영역 - **Cloudflare Access** - 기존 VPN과 원격 접속 환경을 대체합니다. - 애플리케이션별 인증·인가 정책을 구성합니다. - **Cloudflare Gateway** - 사용자, 네트워크, 디바이스, 데이터를 보호합니다. - **Cloudflare Tunnel·Mesh·WAN** - 애플리케이션과 네트워크 간 연결 방식을 구성합니다. - **마이그레이션** - Zscaler, Palo Alto Networks 등 기존 SASE 공급업체의 개념과 설정을 Cloudflare 방식으로 변환합니다. - **네트워크 다이어그램** - 현재 또는 제안된 네트워크 구조를 시각화합니다. - **운영 및 문제 해결** - Digital Experience Monitoring(DEX)으로 사용자 경험과 지연 문제를 분석합니다. - 트래픽을 바탕으로 보안 규칙을 추천합니다. ## VPN 교체와 신규 배포 절차 에이전트는 기존 VPN 환경을 분석한 뒤 다음과 같은 순서로 Cloudflare 구성을 제안할 수 있습니다. - 기존 VPN 애플리케이션을 목록화하고 각 애플리케이션에 필요한 연결 모델을 식별합니다. - 애플리케이션을 적절한 Cloudflare 구성요소에 매핑합니다. - Self-hosted Access 애플리케이션 - Tunnel 연결 서비스 - Mesh 연결 네트워크 세그먼트 - 서비스 중단을 최소화하도록 단계별 전환 순서를 생성합니다. - 실제 변경 전에 팀이 검토할 수 있는 구성 요약을 제공합니다. ## 공급업체 간 마이그레이션 자동화 - Zscaler Private Access 애플리케이션 정의를 Cloudflare Access 애플리케이션 정의로 변환합니다. - 사용자 그룹과 보안 정책을 Cloudflare Access 정책으로 매핑합니다. - Cloudflare API를 사용해 변환된 리소스를 계정에 생성할 수 있습니다. - 마이그레이션된 항목과 수동 검토가 필요한 예외를 별도로 정리합니다. - 이 로직은 Cloudflare의 Descaler·Deskope 프로그램에 사용된 방식으로, 기업 고객의 이전 작업을 수개월에서 수시간으로 단축한 사례를 바탕으로 합니다. ## 운영 중인 환경의 보안·성능 개선 - 실시간 계정의 트래픽을 분석해 적절한 보안 규칙을 추천합니다. - 기존 Zscaler Private Access 애플리케이션을 Cloudflare의 self-hosted Access 애플리케이션으로 자동 이전할 수 있습니다. - Secure Web Gateway HTTP 로그에서 이상 현상을 조사하고 사용자 문제를 해결할 규칙을 만들 수 있습니다. - DEX 도구를 이용해 사용자 연결 안정성과 지연 시간을 분석하고 개선 조치를 제안합니다. ## 실용적인 결론 Cloudflare One stack은 Zero Trust 전문가의 경험을 에이전트가 활용할 수 있는 구조화된 지식과 도구로 패키징한 제품입니다. 다만 네트워크 정책 변경은 영향 범위가 크므로 에이전트가 생성한 계획과 구성 요약을 먼저 검토하고, 단계적 전환과 수동 승인을 병행하는 방식이 적절합니다.

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

모델 컨텍스트 프로토콜제로 트러스트sasecloudflare-access+4

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

ID-JAG The Hard Way: 실패로 배우는 AI 에이전트 보안 핸즈온

AI 에이전트의 API 접근에는 단순한 사용자 인증을 넘어, 에이전트가 특정 사용자를 대신해 정해진 범위의 작업만 수행하도록 통제하는 위임 인가가 필요하다. 글은 OAuth 기반 프로필인 ID-JAG를 활용해 Keycloak, Athenz, MCP 서버, 리소스 서버가 연계되는 전체 흐름을 로컬 핸즈온으로 재현한다. 특히 인증 정보와 실제 접근 권한을 분리하고, 기업 정책에 따라 실패 지점을 명확히 차단하는 중앙 집중형 인가 구조를 강조한다. ## ID-JAG가 해결하려는 문제 - ID-JAG는 다음 OAuth 표준을 결합해 위임된 크로스 도메인 API 접근을 지원한다. - OAuth 2.0 Token Exchange(RFC 8693) - JWT Profile for OAuth 2.0 Authorization Grants(RFC 7523) - 기존의 “사용자가 누구인가?”라는 인증 중심 질문을 다음과 같이 확장한다. - AI 에이전트가 현재 사용자를 대신해 특정 리소스에 접근할 권한이 있는가? - 요청된 권한 범위와 기업 정책을 충족하는가? - AI 에이전트에 영구적이고 포괄적인 권한을 주면 오작동이나 공격 시 피해 범위가 커지고, 사용자의 의도와 에이전트의 자율 행동을 구분하기 어렵다. - 모든 API 호출마다 사용자의 동의를 요구하면 자동화와 사용자 경험이 훼손된다. - ID-JAG는 임시 토큰 연결 대신, 정책에 기반한 명시적 위임과 중앙 집중형 신뢰 관계를 제공한다. ## 데모 아키텍처와 역할 분리 핸즈온에서는 인증과 인가 정책을 의도적으로 분리한다. - **Keycloak** - 사용자를 인증하는 업스트림 IdP다. - 로그인 결과로 원본 ID 어서션을 발급한다. - **Athenz** - KeycloakTokenExchangePlugin을 통해 연동된 IdP 인가 서버로 동작한다. - Keycloak 토큰의 발급자, 서명, 대상, 주체, 클라이언트 바인딩을 검증한다. - 기업 정책을 평가하고 최종 ID-JAG 어서션을 발급한다. - 중앙 리소스 인가 서버이자 정책 결정 지점(PDP) 역할을 한다. - **AI 에이전트** - 사용자를 대신해 ID-JAG와 액세스 토큰을 요청한다. - 장기 마스터 키가 아니라 정책으로 제한된 임시 권한을 사용한다. - **MCP 서버** - 에이전트가 호출하는 보호된 중간 리소스 서버다. - 전달받은 토큰을 인가 서버와 교환한 뒤 최종 리소스 서버에 접근한다. - **리소스 서버** - Athenz가 발급한 신뢰 가능한 토큰만 수용한다. - 업스트림 IdP의 토큰을 무조건 인가 그랜트로 인정하지 않는다. ## ID-JAG 실행 흐름 실습 환경에서는 다음 순서로 위임 접근이 진행된다. - 사용자가 Keycloak을 통해 로그인한다. - 사용자가 AI 에이전트에 작업을 지시한다. - 에이전트가 Athenz에 ID-JAG 토큰을 요청한다. - Athenz가 사용자, 클라이언트, 대상 리소스, 권한 범위 및 기업 정책을 검증한다. - 허용된 경우 에이전트가 Athenz에 액세스 토큰을 요청한다. - 에이전트가 액세스 토큰을 포함해 MCP 서버를 호출한다. - MCP 서버가 토큰 교환을 수행한다. - 교환된 토큰으로 최종 리소스 서버에 요청한다. 이 구조에서는 인증된 사용자라는 사실만으로 모든 리소스 접근이 허용되지 않으며, 각 단계에서 위임 범위와 정책을 다시 확인한다. ## 인증 토큰과 인가 그랜트의 분리 Keycloak의 ID 토큰을 곧바로 액세스 토큰으로 교환하는 방식도 기술적으로는 가능하지만, 보안 모델상 한계가 있다. - **ID 토큰** - 사용자가 클라이언트에 성공적으로 인증됐음을 나타낸다. - 특정 리소스에 접근할 권리를 직접 의미하지 않는다. - **인가 그랜트** - 특정 리소스와 권한 범위에 대한 액세스 토큰 발급을 요청하기 위해 인가 서버에 제출된다. - ID-JAG를 별도의 인가 그랜트로 사용하면 다음 실패 유형을 구분할 수 있다. - 사용자 인증 실패 - 그랜트 검증 실패 - 에이전트 위임 거부 - 기업 정책 거부 - 리소스 서버의 토큰 거부 - 이 경계는 장애 분석과 감사 추적을 명확하게 만들고, 로그인 성공이 곧 크로스 도메인 API 접근 권한으로 오해되는 것을 방지한다. ## 실패 경로를 통한 보안 검증 핸즈온은 정상 동작뿐 아니라 의도적인 설정 오류를 통해 정책 경계를 확인하도록 구성된다. - 토큰 없이 보호된 API를 호출하면 `401 Unauthorized`가 발생한다. - 엔터프라이즈 역할만 설정하고 멤버십을 누락하면 토큰 교환이 실패한다. - 에이전트에 필요한 위임 권한을 부여하지 않으면 위임 호출이 차단된다. - 각 오류는 인증, 역할, 멤버십, 위임 정책, 토큰 교환 중 어느 단계가 필요한지 보여준다. - Athenz UI에서 에이전트의 위임 권한을 제거한 뒤 다시 실행하면 차단이 발생하는 지점을 직접 추적할 수 있다. ## 중앙 정책 관리의 장점 - 기업의 위임 정책을 Athenz 한 곳에서 관리할 수 있다. - 여러 IdP, SaaS, 리소스 애플리케이션에 정책을 중복 배포할 필요가 줄어든다. - 벤더별 인가 로직에 대한 종속을 완화할 수 있다. - 시스템 간 정책 불일치와 운영상의 보안 위험을 줄인다. - Athenz가 ID-JAG 발급자이자 PDP로 기능하면서, 위임 API 접근에 대한 단일 진실 공급원이 된다. ## 실습 방법과 권장 사항 - `athenz-community/id-jag-the-hard-way` 저장소에서 튜토리얼을 실행한다. - 정상 흐름뿐 아니라 의도적으로 역할, 멤버십, 위임 권한을 제거해 실패 지점을 확인하는 것이 중요하다. - 실제 기업 환경에서는 인증 성공 여부와 별도로 리소스·권한·에이전트·정책을 명시적으로 검증해야 한다. - AI 에이전트 도입 시 장기 자격 증명 대신 제한된 범위의 단기 토큰과 중앙 정책 평가를 사용하는 방식을 권장한다.

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

모델 컨텍스트 프로토콜AI 에이전트jwtauthorization+4

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

Vibe Coding하는 비개발자는 개발자인가(3)

AI 에이전트는 비개발자에게 단순히 코드를 생성해주는 도구를 넘어, 업무를 실행 가능한 구조로 재정의하게 만드는 동반자다. 글쓴이는 로컬 HTML 도구를 공유 서비스로 확장하고, 스프레드시트·웹훅·환경변수·스킬·MCP 등을 활용하며 입력과 출력, 권한, 보안, 검증 조건을 자연스럽게 고민하게 되었다고 말한다. 결국 중요한 것은 코딩 능력 자체보다 자신의 업무를 AI가 수행할 수 있는 단위와 규칙으로 구조화하는 능력이다. ## 로컬 HTML에서 공유 데이터 도구로 - 초기 도구는 브라우저에서 실행하는 단일 HTML 파일이었다. - 서버와 데이터베이스가 필요 없고 혼자 사용하기에 충분했다. - 다른 사람과 공유하려면 배포 주소, 최신 버전 반영, 데이터 저장 문제가 생겼다. - 정적인 화면을 넘어 다음 요구사항이 발생했다. - 과거 입력값 조회 - 여러 사용자의 데이터 공유 - 상태 변경에 따른 화면 갱신 - 사용자별 조회·수정 권한 관리 - 잘못된 수정의 복구와 데이터 백업 - 정식 데이터베이스는 접근 권한 설계와 운영·보안 부담이 컸다. - 대신 구글 스프레드시트를 공유 데이터 저장소로 활용했다. - 기존 협업 UI와 권한 관리 기능을 이용할 수 있었다. - 수정 이력과 공유 기능도 이미 제공됐다. - Apps Script 코드를 직접 붙여넣는 방식에서 시작해, 이후 `clasp`를 이용한 Apps Script API 기반 배포·실행 방식으로 발전했다. - 핵심 변화는 코드를 많이 작성한 것이 아니라, 데이터 위치·공유 방식·권한·변경 이력을 설계하기 시작했다는 점이다. ## 웹훅 연동과 보안 습관 - AI 에이전트의 도움으로 업무 환경과 연결되는 웹훅 봇을 구현할 수 있게 되었다. - 웹훅 URL과 토큰을 다루면서 다음 보안 원칙을 익히게 됐다. - 비밀값을 코드나 프롬프트에 직접 입력하지 않기 - `.env` 파일에서 환경변수로 읽기 - `.gitignore`로 저장소에 비밀값이 올라가지 않도록 하기 - 로그에 토큰 등 민감정보를 출력하지 않기 - 실제 비밀값 대신 placeholder 사용하기 - 작은 자동화라도 외부 시스템과 연결되는 순간 실행 환경과 접근 권한, 비밀값 관리가 함께 고려되어야 한다. - 보안은 별도의 전문 작업이 아니라 AI에게 코드를 요청할 때마다 반복하는 작업 습관이 되었다. ## 손작업을 명세와 파이프라인으로 바꾸기 - 파일 복사·정리, 문서 변환, 영상 편집, 음성 추출, 요약 등 기존의 수작업도 AI 에이전트에게 맡기기 시작했다. - 사람이 직접 할 때는 감으로 처리하던 작업도 에이전트에게 맡기려면 구체적인 명세가 필요했다. - 대상 입력 파일 - 결과 파일명과 저장 위치 - 기존 파일 덮어쓰기 여부 - 실패 시 중단 조건 - 결과의 정상 여부를 판단하는 검증 기준 - 이 과정에서 반복 업무가 다음과 같은 업무 단위로 분해됐다. - 입력 - 처리 단계 - 출력 - 예외 상황 - 검증 조건 - 자동화의 핵심은 명령어를 아는 것이 아니라, 한 단계가 완료되었다고 판단할 기준과 입력·출력 형식을 정의하는 데 있다. ## 회의록 스킬과 반복 판단의 축적 - 매주 반복되는 회의록 작성 과정에서 일정한 수정 패턴이 발견됐다. - 글쓴이는 Codex와 Claude의 `skill`을 만들어 회의 유형별 규칙을 저장했다. - 회의록의 출력 형식 - 결정사항과 액션 아이템 추출 방식 - PMO 관점에서 확인할 신호 - AI가 독단적으로 결론 내리지 않고 사용자에게 질문해야 하는 경우 - 스킬은 단순한 프롬프트 모음이 아니라 반복되는 판단 기준과 업무 규칙을 저장하는 장치였다. - AI가 초안을 작성하면 최종본과 비교해 개선점을 찾고, 그 결과를 다시 스킬에 반영하는 순환 구조를 만들었다. - 내부 데이터를 정리하다가 대화 기록을 잃어버린 사례도 있었다. - 스킬 파일은 남았지만 대화에 포함된 맥락이 사라져 성능이 일시적으로 저하됐다. - 반복 업무에서는 규칙뿐 아니라 맥락과 사례를 보존하는 것도 중요하다는 점을 보여준다. ## MCP와 스킬을 이용한 GA 리포트 자동화 - 기존에는 구글 애널리틱스(GA) 데이터를 확인하고 여러 대시보드를 만들어 인사이트를 도출하는 과정이 번거로웠다. - GA MCP를 통해 API로 데이터를 가져오고, 스킬로 월간 리포트 형식을 유지했다. - 지난달과 이번 달의 차이를 비교해 변화가 의미 있는지 판단하는 방식으로 리포트가 개선됐다. - MCP는 데이터를 가져오는 통로이고, 스킬은 반복되는 리포트 구조를 유지하는 장치다. - 중요한 것은 단순히 숫자를 요약하는 것이 아니라 다음을 판단하는 것이다. - 어떤 변화가 발생했는가 - 그 변화가 설명할 가치가 있는가 - 추가 조사가 필요한 신호인가 - AI의 분석 결과에 사용자의 업무 맥락을 결합하면 이전에는 발견하기 어려웠던 변화를 준실시간으로 탐지할 수 있다. ## 개발의 경계가 넓어지는 방식 - 변화의 본질은 AI 도구의 개수가 늘어난 것이 아니라, 기존 업무를 다른 구조로 바라보게 된 데 있다. - AI가 만든 결과물 자체보다 AI가 수행할 수 있도록 업무를 설명하는 방식이 중요해졌다. - 앞으로 더 많은 사람이 다음 요소를 일상적으로 고민하게 될 것으로 전망한다. - 입력과 출력 - 권한과 보안 - 반복 작업과 파이프라인 - 완료 조건과 검증 방법 - 이는 모든 사람이 전통적인 개발자가 된다는 뜻은 아니다. - 다만 비개발자의 업무도 점차 쪼개지고, 자동화되고, 실행 가능한 형태로 재정의될 수 있다. AI 에이전트를 효과적으로 활용하려면 “무엇을 만들어 달라”보다 “입력은 무엇이고, 결과는 어떤 형식이어야 하며, 실패와 보안 문제를 어떻게 처리할지”를 구체적으로 정의하는 것이 좋다. 반복되는 수정과 판단을 스킬이나 문서로 축적하고, 민감정보와 작업 맥락을 안전하게 관리하는 습관을 함께 갖추는 것이 실용적인 출발점이다.

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

모델 컨텍스트 프로토콜AI 에이전트claude-codewebhooks+3

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

AWS 주간 요약: 프리뷰로 공개된 AWS FinOps 에이전트, Bedrock의 Gemma 4, Kiro Pro Max 등 (2026년 6월 15일) | Amazon Web Services

이번 주 AWS 소식은 AI 기반 개발 방식의 생산성 향상, 비용 최적화 자동화, 차세대 인프라와 모델 출시를 중심으로 전개됐다. AWS FinOps Agent는 비용 분석과 최적화 작업을 자동화하고, Graviton5 기반 EC2 M9g는 성능과 격리 보안을 강화했다. 또한 Gemma 4와 OpenSearch MCP Apps를 통해 생성형 AI와 에이전트 기반 운영 환경이 확대되고 있다. ## AI 네이티브 개발팀의 운영 방식 - Amazon의 수백 개 엔지니어링 팀 실험 결과, 구조화된 AI 개발 방식을 적용하면 생산성이 크게 향상됐다. - 6명의 엔지니어가 30명 투입 및 12~18개월이 예상되던 Amazon Bedrock 추론 엔진을 76일 만에 재구축했다. - Amazon Stores의 구조화된 파일럿에서는 배포 속도 중앙값이 4.5배 향상됐고, 일부 팀은 10배 이상 개선됐다. - Perfect Order Experience는 기능 출시 주기가 2주에서 반나절로 단축됐으며, WW Grocery는 설계 문서 작성 시간을 5일에서 몇 시간으로 줄였다. - 프런티어 팀을 위한 주요 실천법은 다음과 같다. - 코딩 규칙, 에이전트 지침, 구조화된 저장소 등 에이전트 컨텍스트를 먼저 구축한다. - 초기에는 생산성이 떨어질 수 있지만 새로운 워크플로가 정착될 때까지 지속한다. - 에이전트가 병렬로 처리할 수 있도록 범위가 명확한 작업 백로그를 유지한다. - 코드 생성 전에 명세와 의도를 구체적으로 정의한다. - 테스트를 개발 초기 단계로 앞당겨 에이전트가 스스로 오류를 수정하도록 한다. - 단순한 커밋 수만으로 생산성을 판단해서는 안 되며, 향후 릴리스 관리·운영·보안·EOL 업그레이드에 대한 후속 내용이 예고됐다. ## AWS FinOps Agent 기반 비용 최적화 - AWS FinOps Agent가 프리뷰로 공개됐다. - AWS 비용에 관한 질의에 답하고, 비용 보고서를 생성하며, 최적화 기회를 탐색한다. - Cost Optimization Hub와 Compute Optimizer를 활용해 다음 항목을 추천한다. - 리소스 라이트사이징 - 유휴 리소스 제거 - Savings Plans 도입 - 추천 결과를 바탕으로 Jira 티켓을 자동 생성할 수 있다. - 비용 이상 징후가 발견되면 원인을 자동 조사하고 결과를 Slack 채널에 게시할 수 있다. - 정기적인 FinOps 작업을 일정에 따라 실행할 수 있어 재무팀과 엔지니어링팀의 비용 관리 자동화에 적합하다. ## EC2 M9g·M9gd와 Graviton5 - EC2 M9g와 M9gd 인스턴스가 정식 출시됐다. - AWS Graviton5와 6세대 Nitro System을 기반으로 한다. - Graviton4 대비 최대 성능 향상: - 일반 컴퓨팅: 최대 25% - 웹 애플리케이션: 최대 35% - 머신러닝 추론: 최대 35% - 데이터베이스: 최대 30% - Graviton5는 AWS 프로세서 최초로 PCIe Gen6와 DDR5-8800 메모리를 지원한다. - 이전 세대보다 L3 캐시가 5배 커졌다. - M8g 대비 평균 네트워크 대역폭은 최대 15%, EBS 대역폭은 최대 20% 향상됐다. - Nitro Isolation Engine은 형식 검증을 활용해 가상 머신 간 격리를 수학적으로 증명한다. - M9gd는 최대 11.4TB의 NVMe SSD 로컬 스토리지와 M8gd 대비 30% 높은 IOPS를 제공한다. - Instance Bandwidth Configuration을 사용하면 EBS와 VPC 네트워크 간 대역폭 배분을 최대 25%까지 조정할 수 있다. ## Bedrock 모델 업데이트와 접근 제한 - Google DeepMind의 Gemma 4 제품군이 Amazon Bedrock에 추가됐다. - 제공 모델은 다음과 같다. - Gemma 4 31B: 256K 토큰 컨텍스트를 지원하며 추론·코딩에 적합 - Gemma 4 26B-A4B: MoE 구조로 비용과 지연 시간에 민감한 작업에 적합 - Gemma 4 E2B: 저지연 대화형 사용 사례를 위한 소형 모델 - 세 모델 모두 함수 호출, 구조화된 출력, 추론, 스트리밍 응답을 지원한다. - 텍스트·이미지·비디오·오디오 입력과 35개 이상의 언어를 지원한다. - Claude Fable 5는 비동기 장기 작업, 다이어그램·차트·PDF 비전 처리, 자체 검증 기능을 제공했다. - 다만 6월 12일 Anthropic이 미국 정부 수출통제 지침 준수를 위해 Claude Fable 5와 Claude Mythos 5의 접근 권한 철회를 AWS에 요청했다. - 해당 모델 사용에는 Data Retention API를 통한 데이터 공유 동의가 필요했으며, Mythos 계열은 입력·출력을 30일간 보관해야 했다. ## OpenSearch MCP Apps와 에이전트형 옵저버빌리티 - Amazon OpenSearch Service가 MCP Apps를 지원한다. - Claude Desktop, VS Code 등 호환되는 에이전트형 IDE에서 OpenSearch 기반 운영 데이터를 직접 조사할 수 있다. - 에이전트는 로그, 트레이스, 메트릭, 알림과 Amazon Managed Service for Prometheus 데이터를 활용해 장애를 분석한다. - 각 MCP 도구 호출은 두 가지 결과를 반환한다. - 에이전트 추론을 위한 텍스트 요약 - 대화 화면에 표시되는 인터랙티브 시각화 - 제공되는 분석 기능에는 로그·메트릭·트레이스 조사, 서비스 성능, 토폴로지, 동적 시각화, 에이전트 상태, 클러스터 상태, 계측 점수 등이 포함된다. ## AWS CLI와 자격 증명 관리 - AWS CLI v1이 유지보수 모드에 들어간다. - botocore와 s3transfer가 별도 패키지가 아니라 CLI v1 코드에 직접 포함된다. - 따라서 CLI v1 업그레이드가 독립적으로 설치된 해당 패키지 버전을 갱신하지 않는다. - CLI v1의 신규 릴리스는 치명적 버그와 보안 문제 수정에 한정된다. - AWS는 AWS CLI v2로의 마이그레이션을 권장한다. - AWS Workload Credentials Provider도 공개됐다. - AWS 외부 또는 온프레미스에서 실행되는 애플리케이션이 장기 액세스 키 없이 단기 자격 증명을 발급받을 수 있다. - 이를 통해 워크로드별 최소 권한 원칙과 자격 증명 보안을 강화할 수 있다. ## Kiro Pro Max - Kiro에 Pro Max 요금제가 추가됐다. - 더 높은 사용량 한도, 최신 프런티어 모델 접근 권한, 추가 에이전트 기능을 제공한다. - 지속적으로 AI 개발 기능을 사용하는 전문 개발팀을 주요 대상으로 한다. - 원문은 이 항목에서 일부가 잘려 있어 세부 기능과 가격 정보는 확인할 수 없다. 이번 발표들은 AWS가 단순한 클라우드 인프라 제공을 넘어, 비용 관리·소프트웨어 개발·운영 관측성까지 에이전트가 자동화하는 방향으로 확장하고 있음을 보여준다. 실무에서는 AWS CLI v2 마이그레이션을 우선 검토하고, FinOps Agent와 MCP Apps는 권한·데이터 보존·운영 자동화 범위를 점검한 뒤 제한된 환경에서 도입하는 것이 적절하다.

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

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

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

Dropbox가 MCP와 Dash를 활용해 디자인에서 코드로 이어지는 보안 격차를 해소하는 방법

Dropbox는 보안 위협 모델과 실제 코드 구현 사이의 단절을 MCP, 기초 언어 모델, Dash를 결합해 해결하고자 했다. 시스템은 코드 리뷰 시 관련 위협 모델을 자동으로 검색하고, 문서에 정의된 보안 요구사항이 코드에 반영됐는지 비교한다. 분석 결과 구현 PR의 12%만 원래 보안 검토와 연결되어 있었으며, 보안 지식을 코드 리뷰 시점에 자동으로 제공하는 것이 핵심 해결책으로 제시된다. ## 설계와 코드 사이의 보안 격차 - 보안 검토에서는 잠재적 위험, 공격 가능성, 필요한 보호 조치를 위협 모델에 기록한다. - 그러나 개발이 시작되면 위협 모델은 위키나 문서 시스템에 남고, 구현 코드는 별도의 PR에서 관리된다. - 명시적인 링크가 없으면 코드 리뷰어가 과거의 보안 요구사항을 확인하기 어렵다. - Dropbox의 분석 결과: - 구현 PR 중 원래 설계 검토 및 위협 모델을 연결한 비율은 **12%**에 불과했다. - 검증된 79개 쌍 중 **54%**는 보안 검토 후 한 달이 지나서야 PR이 생성됐다. - 보안 검토부터 PR 생성까지의 중앙값은 약 **5주**였다. - 일부 지연은 **11개월 이상**이었다. - 검토 후 2주 이내에 생성된 PR은 **29%**뿐이었다. ## 기존 보안 도구의 한계 - 정적 분석 도구는 코드에 특정 보안 제어가 존재하는지 확인할 수 있다. - 하지만 해당 제어가 설계 검토에서 합의한 요구사항과 일치하는지는 판단하기 어렵다. - 정적 분석은 코드의 패턴은 검사하지만, 설계 의도와 이전에 결정된 보안 맥락은 알지 못하기 때문이다. - 개발자에게 설계 문서와 PR을 직접 연결하도록 요구하거나 알림 봇을 사용하는 방식도 지속적인 준수에 의존한다. - 설계 검토의 약 **15%**는 코드가 먼저 작성된 뒤 사후적으로 진행됐다. - 따라서 자동화 시스템은 기존 검토와 코드를 연결하는 것뿐 아니라, 보안 검토가 필요할 가능성이 있는 작업을 개발 중 조기에 식별하는 역할도 할 수 있다. ## Dash와 MCP를 활용한 컨텍스트 연결 - Dash는 여러 연결된 애플리케이션의 문서를 색인하므로, 기존 위협 모델과 엔지니어링 문서를 통합적으로 검색할 수 있다. - Dropbox는 코드가 리뷰에 제출될 때 관련 위협 모델을 자동으로 검색하도록 시스템을 구축했다. - MCP(Model Context Protocol)는 AI 에이전트가 Dash가 색인한 문서에 접근하도록 하는 연결 계층이다. - 보안 검토 에이전트는 Dash의 MCP 서버를 통해 위협 모델과 관련 문서를 검색하고 읽는다. - 별도의 소스 시스템별 맞춤 통합 없이 여러 컨텍스트를 하나의 에이전트 세션에 결합할 수 있다. ## 요구사항과 구현 코드의 비교 - 코드 리뷰가 시작되면 에이전트는 관련 위협 모델과 보조 문서를 가져온다. - 기초 언어 모델은 문서에 기록된 보안 요구사항과 변경된 코드를 함께 분석한다. - 예를 들어 위협 모델이 특정 엔드포인트에 인증을 요구한다면, 실제 코드가 인증을 강제하는지 판단할 수 있다. - 기존 정적 분석과 달리 단순히 취약한 코드 패턴을 찾는 것이 아니라, **설계 단계의 보안 결정이 구현에 반영됐는지**를 검토한다. - 결과를 별도의 보안 절차가 아니라 개발자가 이미 사용하는 코드 리뷰 과정에 제공하는 것이 중요한 설계 원칙이다. ## 실용적인 결론 보안 검토 문서를 별도로 잘 작성하는 것만으로는 충분하지 않다. 해당 문서의 요구사항이 코드가 검토되는 시점에 자동으로 노출되고 구현과 비교되어야 하며, 이를 위해 조직의 기존 문서 검색 시스템과 MCP 기반 AI 에이전트를 코드 리뷰 흐름에 통합하는 접근이 효과적이다.

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

모델 컨텍스트 프로토콜대규모 언어 모델코드 리뷰static-analysis+2

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

에이전트 기반 테스트: E2E 테스트 스택에서 에이전트가 적합한 위치

에이전트 기반 E2E 테스트는 기존의 결정적 테스트를 대체하기보다, 사용자의 목표 달성 여부를 탐색적으로 검증하는 별도의 계층으로 활용해야 한다. 200회 이상 실험한 결과 Playwright MCP 기반 에이전트가 복잡한 흐름에서도 가장 안정적이었고, 생성된 Playwright 테스트는 단순한 흐름에서는 빠르지만 복잡도가 높아질수록 실패율이 크게 증가했다. 따라서 전통적 테스트는 핵심 회귀 검증에, 에이전트 테스트는 유연한 탐색과 목표 중심 검증에 배치하는 것이 적절하다. ## 여정 검증에서 목표 검증으로 - 전통적인 E2E 테스트는 `클릭 → 클릭 → 입력 → 검증`처럼 미리 정해진 UI 경로를 검증한다. - 에이전트 기반 테스트는 “스레드 메시지를 보내라”처럼 목표를 제시하고, 에이전트가 현재 UI 상태에 따라 경로를 선택하게 한다. - 동일한 결과에 도달하더라도 다음과 같은 차이가 발생했다. - 검색 제안 클릭 또는 Enter 키 사용 - 검색 화면을 다시 열거나 기존 상태 재사용 - 중간 클릭, 스냅샷 확인 등의 추가·생략 - 에이전트는 중간 단계도 검증할 수 있지만, 경로의 유연성 때문에 실행 시간·비용·신뢰성 관리가 필요하다. ## 실험 구성과 비교 대상 - 200회 이상의 자동 실행으로 신뢰성, 속도, 비용을 비교했다. - 비교한 실행 방식은 세 가지다. - **에이전트 + Playwright MCP**: 브라우저 액션과 DOM 상태·로그를 지속적인 컨텍스트로 사용 - **에이전트 + Playwright CLI**: 셸에서 명령을 한 단계씩 실행하고 매번 UI 상태를 바탕으로 다음 행동 결정 - **생성된 Playwright 테스트**: 자연어 설명으로 결정적 테스트 코드를 생성한 뒤 실행·수정 - Claude Sonnet 4.5와 Opus 4.6을 사용했으며, 비운영 데이터가 있는 테스트 워크스페이스에서 실행했다. - 입력 형식은 다음 두 가지였다. - 자연어 지시: 사람이 읽기 쉬운 단계별 설명 - 구조화된 YAML: 단계, 액션, 대상, 기대 결과를 명시 - 각 설정은 20회씩 실행했다. ## 테스트한 사용자 흐름 - **Thread Reply** - 약 15~20단계의 단순한 흐름 - 채널 생성, 메시지 전송, 스레드 답글 작성, 스레드 상태 확인 - **Search Discovery** - 약 25~30단계의 중간 복잡도 흐름 - 검색어 입력, 검색 결과 탐색, 채널·스레드·검색 화면 간 이동, 결과 검증 ## 측정 결과 | 방식 | Thread Reply 실패율 | Search Discovery 실패율 | 평균 실행 시간 | |---|---:|---:|---:| | 에이전트 + Playwright MCP | 0% | 약 12% | 약 5~8분 | | 에이전트 + Playwright CLI | 약 12% | 약 20% | 약 9~11분 | | 생성된 Playwright 테스트 | 약 8% | 약 48% | 약 3분 | - 에이전트 테스트는 실행당 15~30달러가 들고 10분 이상 걸릴 수 있어, 일반적인 빠른 회귀 테스트를 그대로 대체하기에는 부담이 있다. - 그러나 전통적 테스트와 목적이 다르므로 단순한 실패율만으로 비교해서는 안 된다. ## 복잡도가 높아질수록 벌어지는 신뢰성 차이 - Playwright MCP는 단순한 시나리오에서 거의 실패하지 않았고, 복잡한 흐름에서도 실패율이 0~12% 수준이었다. - Playwright CLI는 인증 처리, 탐색 타이밍, 세션 불안정 등 실행 환경 문제로 약 12~20%의 실패율을 보였다. - 생성된 Playwright 테스트는 단순한 흐름에서는 약 8% 실패했지만, 복잡한 검색 흐름에서는 약 48%까지 악화됐다. - 생성 테스트는 대체로 전체 흐름의 70~80%까지 진행한 뒤 마지막 상호작용이나 assertion에서 실패했다. - 주요 원인은 다음과 같다. - UI 상태의 변동성 - 자연어 명세와 실제 요소 선택 간의 추상화 불일치 - 기존 Page Object 추상화가 복잡한 상황에서 정확한 요소 지정을 방해 - MCP는 애플리케이션의 실시간 상태를 안정적으로 유지하는 반면, CLI는 단계마다 스냅샷을 다시 구성한다. - 긴 흐름에서는 상태 해석과 타이밍의 작은 차이가 누적되어 CLI 방식의 실패 가능성이 커질 수 있다. ## 테스트 스택에서의 적절한 역할 - 전통적인 결정적 Playwright 테스트는 빠르고 반복 가능하므로 핵심 회귀 테스트와 CI의 기본 검증에 적합하다. - 에이전트 기반 테스트는 특정 클릭 순서가 아니라 “사용자가 목표를 달성할 수 있는가”를 검증하는 데 적합하다. - 특히 다음 영역에서 활용 가치가 있다. - 다양한 UI 경로를 허용해야 하는 사용자 여정 - 사전에 모든 경로를 코드로 작성하기 어려운 탐색적 테스트 - 복잡한 화면 상태와 실제 사용자 행동에 가까운 검증 - 에이전트 방식 중에서는 실시간 브라우저 컨텍스트를 유지하는 Playwright MCP가 복잡한 시나리오에 더 적합한 것으로 나타났다. - 다만 높은 비용과 긴 실행 시간을 고려해 모든 커밋에서 실행하기보다는, 야간 테스트나 릴리스 전 검증 등 별도 계층에 배치하는 것이 현실적이다. 에이전트 기반 E2E 테스트는 결정적 테스트의 대체재가 아니라 보완재로 도입하는 것이 좋다. 빠르고 안정적인 핵심 회귀 검증은 기존 Playwright 테스트로 유지하고, MCP 기반 에이전트 테스트를 목표 중심·탐색적 검증에 제한적으로 추가하는 구성이 가장 실용적이다.

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

모델 컨텍스트 프로토콜대규모 언어 모델AI 에이전트claude+3

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

GitLab Orbit 소개

GitLab Orbit은 코드뿐 아니라 머지 리퀘스트, 파이프라인, 배포, 취약점, 소유권까지 연결한 실시간 그래프를 제공해 AI 에이전트가 시스템 전체 맥락을 한 번에 이해하도록 하는 서비스다. 이를 통해 에이전트는 파일을 반복 탐색하는 대신 관계형 질의를 수행하며, 최대 11배 빠르고 토큰 사용량은 4.5배 적어질 수 있다. GitLab은 Orbit이 코드 리뷰와 장애 대응, 보안, 마이그레이션처럼 여러 시스템을 함께 봐야 하는 작업의 정확성과 처리 속도를 높인다고 설명한다. ## 기존 AI 코딩 에이전트의 한계 - AI 에이전트는 코드 작성에는 강하지만 다음 정보를 찾는 데는 취약하다. - 관련 코드와 의존성 - 해당 코드를 실행하는 테스트와 파이프라인 - 실제 배포 환경 - 변경을 요청한 작업 항목 - 관련 팀과 담당자 - 대규모 모노레포에서는 에이전트가 파일을 탐색하는 데 토큰과 시간을 많이 사용한다. - 저장소가 여러 개로 나뉘면 컨텍스트가 부족해져 의존성을 놓치거나, 코드가 겉보기에는 맞지만 실제로는 되돌려지는 결과를 만들 수 있다. - 단순한 검색이나 RAG 방식만으로는 코드와 개발 lifecycle 데이터 사이의 관계를 충분히 복원하기 어렵다. ## 실제 머지 리퀘스트에서의 검증 - 영국 가격 비교 플랫폼 Compare the Market은 79개의 실제 머지 리퀘스트를 대상으로 AI 코드 리뷰의 컨텍스트 검색 방식을 비교했다. - Orbit을 사용한 리뷰어의 정확한 인라인 댓글 비율은 약 70%였다. - RAG 방식은 약 58%에 그쳤다. - 변경 사항 요약에서 핵심 변경을 포착한 비율도 Orbit이 68%, RAG가 66%였다. - RAG는 컨텍스트를 사용하지 않은 방식보다도 낮은 성능을 보였다. - 테스트 결과 Orbit은 단순히 현재 diff를 읽는 것이 아니라 코드베이스의 구조와 변경의 주변 영향을 이해하는 데 효과적이었다. ## 코딩 에이전트의 탐색 비용 감소 - Claude Code 같은 외부 에이전트를 MCP(Model Context Protocol)로 Orbit에 연결할 수 있다. - 에이전트는 다음 질문을 파일을 반복해서 읽으며 추론하지 않고 그래프에 직접 질의한다. - 특정 코드가 어디에 있는가? - 어떤 코드가 이를 의존하는가? - 어떤 테스트와 파이프라인이 이를 검증하는가? - 같은 모델과 같은 작업을 비교했을 때 다음과 같은 개선이 제시됐다. - 최대 11배 빠른 작업 수행 - 최대 4.5배 적은 토큰 사용 - 최대 45배 적은 환각 생성 - 결과적으로 에이전트가 실제 구현 작업을 시작하기 전에 소모하는 탐색 시간이 줄어든다. ## 파이프라인 장애의 전체 영향 추적 - 기존 에이전트는 실패한 파이프라인의 개별 job만 보고 원인을 고립된 문제로 판단하기 쉽다. - Orbit은 실패한 job에서 관련 파이프라인, 머지 리퀘스트, 프로젝트까지 연결해 추적한다. - 예시 질의는 실패한 CI job과 연결된 최근 머지 리퀘스트를 프로젝트별로 조회한다. ```cypher MATCH (job:CiJob {status: "failed", name: $job_name}) -[:RAN_IN]->(pipeline)-[:FOR]->(mr:MergeRequest) RETURN mr.title, mr.author, pipeline.started_at, mr.project_id ORDER BY pipeline.started_at DESC LIMIT 20 ``` - 이 방식으로 여러 프로젝트에서 동일한 장애를 만날 진행 중인 MR을 한 번에 찾을 수 있다. - 여러 팀이 같은 원인을 따로 해결하는 대신, 한 번의 대응으로 문제를 확산시키는 변경까지 파악할 수 있다. ## 취약점의 영향 범위와 담당자 파악 - 취약한 코드 자체를 찾는 것보다, 해당 코드가 시스템 어디까지 퍼졌는지를 확인하는 일이 더 어렵다. - Orbit은 다음 정보를 연결해 보여준다. - 취약한 컴포넌트를 포함한 서비스 - 해당 서비스를 빌드하는 파이프라인 - 실행되는 환경 - 각 구성 요소의 소유 팀 - 보안팀은 CVE가 공개된 직후 영향을 받는 구성 요소와 담당자를 포함한 remediation 계획을 만들 수 있다. - 수작업으로 여러 도구를 조사하는 데 걸리던 시간을 줄여 대응 속도를 높이는 것이 목표다. ## 조직 전반의 질의와 마이그레이션 계획 - Orbit은 고정된 대시보드에 없는 복합적인 질문에도 활용된다. - 예를 들어 팀별 cycle time을 파이프라인 실패율, 배포 빈도와 결합해 조회할 수 있다. - 공용 컴포넌트 마이그레이션에서는 다음 의존성을 한 번에 확인할 수 있다. - 종속 서비스 - 관련 job - 배포 환경 - 담당 소유자 - 숨은 downstream 의존성을 놓쳐 일정이 지연되는 위험을 줄이고, 마이그레이션 범위와 책임자를 구체화할 수 있다. ## Orbit의 기술 구조 - 소프트웨어 개발 lifecycle 데이터를 CDC(Change Data Capture) 방식으로 수집해 ClickHouse에 저장한다. - Rails 내부 API를 통해 12개 언어의 코드를 분석한다. - Ruby, Java, Kotlin, Python, TypeScript, JavaScript - Rust, Go, C#, C, C++, PHP - Cypher와 유사한 DSL, MCP, REST, GitLab CLI를 통해 그래프를 조회한다. - GitLab 자체 환경에서는 4만 개 이상의 프로젝트, 5억 개 노드, 20억 개 엣지를 45분 이내에 인덱싱한다고 설명한다. - 이벤트 기반 엔진이 변경 사항을 즉시 반영해 그래프를 최신 상태로 유지한다. - 인덱싱은 별도 서비스에서 수행되므로 쿼리 트래픽이 GitLab 인스턴스에 직접 부담을 주지 않는다. - GitLab 권한을 그대로 반영하므로 에이전트는 사용자가 UI에서 볼 수 있는 데이터만 조회한다. - 쿼리는 데이터베이스에 실행되기 전에 검증, 실행 계획 수립, 최적화, 보안 검사를 거친다. ## 다양한 사용 방식과 Data Explorer - GitLab Duo Agent Platform의 에이전트는 Orbit을 기본적으로 질의할 수 있다. - Claude Code, Codex, OpenCode 같은 외부 에이전트는 MCP와 GitLab CLI를 통해 연결한다. - 사내 도구나 맞춤형 에이전트는 REST API를 사용할 수 있다. - Data Explorer에서는 에이전트 없이 엔지니어가 같은 그래프를 직접 조회한다. - 장애 조사, 의존성 전파 추적, 반복적인 CI 실패 원인 분석처럼 정해진 프롬프트에 맞지 않는 작업에도 활용할 수 있다. Orbit은 코드 검색 도구라기보다 코드와 개발 lifecycle 전체를 연결하는 지식 그래프에 가깝다. 여러 저장소와 시스템에 걸친 의존성, 장애 영향, 보안 노출, 소유권을 자주 추적해야 하는 대규모 조직이라면 특히 효과가 크며, 도입 시에는 실제 MR 리뷰나 장애 대응 업무를 대상으로 기존 검색·RAG 방식과 정확도 및 비용을 비교해 검증하는 것이 좋다.

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

모델 컨텍스트 프로토콜AI 에이전트CI/CDgraph-database+3

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

에이전틱 AI 생태계의 주인공들, MCP Player 10 성료와 Next!

카카오의 MCP 기반 개방형 플랫폼 PlayMCP에서 열린 ‘MCP Player 10’ 공모전이 약 150개 팀의 참여 속에 마무리됐다. 수상작들은 보육 행정, 창업 지원사업, 육아, 법률, 문화생활, 게임, 보안 등 일상과 전문 영역의 문제를 AI 에이전트로 해결했다. 카카오는 PlayMCP를 개발자 중심 플랫폼으로 발전시키고, Kakao Tools 및 카카오톡과 연계해 MCP 서비스의 대중화를 추진할 계획이다. ## 60일간 진행된 MCP 공모전 - 공모전은 2025년 12월 19일부터 2026년 1월 18일까지 진행됐다. - 카카오의 MCP 기반 플랫폼 **PlayMCP**를 활용해 실용적인 MCP 서버를 개발하는 방식이었다. - 약 150개 팀이 참여했으며, 창의성·사용 편의성·기술적 안정성을 기준으로 최종 10팀을 선정했다. - 단순한 기술 시연보다 실제 생활 속 불편을 해결하고 서비스로 발전할 가능성이 중요한 평가 기준으로 소개됐다. ## 대상: 어린이집 행정을 돕는 ‘어린이ZIP’ - 현직 교사의 행정 업무 부담을 줄이는 AI 보육 조수다. - 활동 사진을 분석해 알림장과 보육일지 초안을 자동 생성한다. - 아이별 알레르기, 하원 방법 등 개별 특이사항을 기억해 맞춤형 답변을 제공한다. - 보육 현장에 적합한 따뜻한 문체와 전문가의 톤앤매너를 반영한다. - “사진으로 오늘 보육일지 작성”, “아이의 알레르기 정보 확인”과 같은 자연어 명령으로 사용할 수 있다. ## 최우수상: 창업 지원사업을 분석하는 ‘SeedUp’ - 정부 창업 지원사업 공고를 수집하고 분석하는 창업 지원 MCP다. - 여러 기관에 흩어진 공고와 첨부 파일을 한곳에서 검색·요약한다. - 지원 자격과 주요 조건을 확인하고, 지원사업별 합격 전략까지 안내한다. - 창업자가 “이번 주 주요 공고”, “AI 스타트업 관련 사업” 등을 자연어로 검색할 수 있다. ## 다양한 생활 문제를 해결한 수상작 - **공유 비밀의 방** - 익명성을 보장하는 디지털 소통 플랫폼이다. - AI와 나눈 고민이나 대화를 익명으로 공유하고 다른 사람의 이야기에 공감할 수 있다. - **바우만 16 안티에이징솔루션** - 바우만 피부 유형 16가지 분류법을 AI에 적용했다. - 화장품 성분과 피부 특성을 분석해 개인별 스킨케어 루틴과 제품을 추천한다. - **아라드도우미** - 던전앤파이터 이용자를 위한 게임 전문 AI 비서다. - RAG와 Vision AI를 활용해 패치 노트, 아이템 메타, 직업별 빌드를 분석한다. - **키즈허브** - 육아 정보와 공공데이터를 통합한 서비스다. - 응급실 현황, 성장 단계, 어린이집 대기 정보 등을 제공하고 가족 단톡방 공유도 지원한다. - **택배추적기** - 배송 조회뿐 아니라 택배 사칭 스미싱 URL도 탐지한다. - 배송 관련 문자 속 위험 링크를 분석해 개인정보와 금융 피해를 예방한다. - **ArtBridge** - 약 20만 건의 공연·전시 데이터를 활용하는 문화생활 추천 서비스다. - 위치, 예산, 취향을 바탕으로 연극·뮤지컬·클래식 등 9개 장르의 콘텐츠와 예매 정보를 추천한다. - **KidSafe** - 어린이와 청소년의 AI 대화를 보호하는 안전 MCP다. - 유해 표현과 정서적 위기 신호를 감지하고, 필요하면 보호자나 전문 상담 자원과 연결한다. - **LexiLink_ko** - 법령, 판례, 행정 해석례를 자연어로 검색하는 법률 리서치 도구다. - 복잡한 법적 쟁점을 통합 검색하고 이해하기 쉽게 정리한다. ## PlayMCP의 향후 발전 방향 - PlayMCP는 개발자가 MCP 서버를 만들고 공유하는 전문 공간으로 운영된다. - 일반 사용자가 MCP를 경험하는 공간은 카카오톡의 **Kakao Tools**가 담당하며, 두 서비스는 긴밀하게 연결될 예정이다. - 현재는 개발자가 MCP 서버의 엔드포인트와 운영을 직접 관리해야 한다. - 향후 카카오 클라우드 기반 서버 지원과 배포 자동화 등 매니지드 서비스 도입을 검토하고 있다. - 카카오톡 안에서 MCP가 JSON 기반 위젯 등 자체 UI를 렌더링하도록 지원하는 방안도 검토 중이다. ## 다음 공모전: Agentic Player 10 - 카카오는 2회 공모전인 **Agentic Player 10**을 예고했다. - 이번에는 Kakao Tools와 연계해 개발자가 만든 에이전트를 더 많은 사용자에게 직접 선보이고 검증할 기회를 제공한다. - 특히 스타트업과 예비 창업팀이 실제 사용자 접점을 확보하고 서비스 성장을 실험하는 장으로 활용할 수 있도록 설계될 예정이다. - MCP 서버가 카카오톡 안에서 대중적인 AI 에이전트로 발전하는 것이 주요 목표다. 수상작들은 MCP가 단순한 개발자용 연동 기술을 넘어, 특정 업무와 사용자 문제를 해결하는 실용적인 AI 서비스로 발전할 수 있음을 보여준다. MCP 서비스를 개발한다면 명확한 사용자 문제를 정하고, 신뢰할 수 있는 데이터와 안전장치, 자연어 기반 사용성을 함께 설계하는 것이 중요하다.

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

모델 컨텍스트 프로토콜AI 에이전트RAGjson+3

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

도메인 전문가를 코드화하기: Spotify 데이터 어시스턴트를 뒷받침하는 컨텍스트 레이어 | Spotify Engineering

Spotify의 데이터 어시스턴트가 신뢰할 만한 답변을 제공하는 핵심은 거대한 스키마를 LLM에 모두 넣는 것이 아니라, 도메인 전문가가 선별한 맥락 계층을 구축하는 데 있다. 이 맥락은 관련 데이터셋, 검증된 질문-SQL 예시, 업무 문서로 구성되며 각 도메인 팀이 소유하고 관리한다. 결국 AI는 전문가를 대체하기보다 전문가의 지식을 여러 사용자에게 확장하는 역할을 한다. ## 대규모 데이터 환경에서 스키마만으로 부족한 이유 - Spotify에는 7만 개 이상의 데이터셋과 페타바이트 규모의 데이터가 있다. - 모든 스키마를 LLM의 컨텍스트에 넣는 방식은 다음과 같은 한계가 있다. - 컨텍스트 윈도우가 전체 데이터 웨어하우스를 담기에 부족하다. - 컬럼 타입만으로는 실제 업무 의미를 알 수 없다. - 예를 들어 `INT64` 컬럼만 보고는 테스트 데이터와 실제 데이터의 구분, 또는 “활성 사용자”의 정의를 알 수 없다. - 테이블 수가 많을수록 모델은 비슷한 테이블 중 잘못된 대상을 선택하면서도 자신 있게 답할 수 있다. - 따라서 스키마와 LLM 사이에 도메인별 의미와 사용법을 담은 별도의 맥락 계층이 필요하다. ## Spotify 데이터 에이전트의 동작 방식 - 사용자가 자연어로 질문하면 에이전트가 다음 과정을 수행한다. - 적절한 데이터 맥락을 선택한다. - SQL을 생성한다. - 데이터 웨어하우스에서 쿼리를 실행한다. - 답변, 생성된 SQL, 사용한 출처를 함께 반환한다. - ReAct 루프를 사용해 도구 호출 결과에 따라 추론과 행동을 반복하고, 필요하면 쿼리를 수정한다. - 사용자는 결과뿐 아니라 답변이 어떻게 만들어졌는지도 확인할 수 있다. - Slack 봇, IDE와 AI 도구에서 사용할 수 있는 MCP 서버, 전용 웹 UI로 제공된다. - 관련 지식 기반이 없을 경우에도 이를 명시해 답변의 한계를 투명하게 드러낸다. - 2025년 8월 기준 2,100명 이상의 사용자가 13,000건 이상의 대화에서 활용했으며, 광고·팟캐스트·음악·오디오북·재무 등 177개 클러스터를 지원한다. ## 도메인별 클러스터 모델 Spotify는 데이터 도메인을 “클러스터”라고 부른다. 클러스터는 특정 조직, 프로젝트, 이니셔티브 또는 관심 주제를 중심으로 구성되며, 각 클러스터는 이름이 지정된 전문가 팀이 소유한다. - **데이터셋** - 관련 웨어하우스 테이블과 전체 스키마를 포함한다. - 컬럼 카디널리티, 자주 등장하는 값의 샘플, 파티션 구조 등을 프로파일링한다. - 예를 들어 `country` 컬럼에 `US`, `GB`, `SE` 등이 존재한다는 정보는 모델이 적절한 `WHERE` 조건을 작성하는 데 도움을 준다. - **질문-SQL 쌍** - 전문가가 작성하거나 검토한 질문과 SQL의 조합이다. - 단순한 예시가 아니라 해당 도메인에서 권장되는 쿼리 패턴과 데이터 의미를 가르치는 few-shot 자료로 사용된다. - **문서** - 업무 용어, 팀별로 달라지는 정의, 데이터 사용 시 주의점 등을 기록한다. - 어떤 컬럼을 사용해야 하고 어떤 컬럼을 피해야 하는지도 설명할 수 있다. - 클러스터의 범위, 포함할 테이블, 중요한 예시는 데이터 과학자와 애널리틱스 엔지니어 등 도메인 전문가가 결정한다. ## 자동 생성보다 전문가 검토가 중요한 이유 - Spotify는 데이터 웨어하우스의 과거 쿼리 기록에서 질문-SQL 쌍을 자동으로 생성하는 방법을 검토했다. - 실제 쿼리이므로 유용할 것처럼 보였지만, 큐레이터가 승인한 예시는 전체의 12.5%에 불과했다. - 나머지 87.5%에는 다음과 같은 쿼리가 포함되어 있었다. - 일회성 탐색이나 디버깅 쿼리 - 다시 사용하지 않을 임시 분석 - 잘못된 테이블을 사용한 쿼리 - 기술적으로는 맞지만 다른 사용자에게 잘못된 패턴을 가르치는 쿼리 - 쿼리 기록에는 정보가 많지만, 어떤 쿼리가 표준적인 지식인지는 자동으로 표시되지 않는다. - 따라서 AI가 데이터의 진실을 결정하도록 하지 않고, 전문가가 예시를 검토하고 정식 사례로 승인한다. - 목적은 전문가를 대체하는 것이 아니라 전문가의 판단을 재사용 가능한 형태로 확장하는 것이다. ## 클러스터의 지속적인 건강 관리 데이터 스키마와 업무 규칙은 계속 변하기 때문에, 한 번 만든 맥락이 영원히 정확한 것은 아니다. - 테이블이 교체되거나 폐기될 수 있다. - 컬럼명이 변경될 수 있다. - 비즈니스 정의와 분석 방식이 달라질 수 있다. - 기존 질문-SQL 쌍이 변경된 스키마와 호환되지 않을 수 있다. - Spotify는 여러 신호를 종합해 클러스터 건강 점수를 계산한다. - 기반 데이터의 상태 - 최근 스키마 변경 이후에도 curated pair가 유효한지 여부 - 실제 사용자가 묻는 질문을 충분히 다루는지 - 생성된 SQL을 재현할 수 있는지 - 기타 품질 및 활용 지표 - 문제가 발생하면 건강 점수가 낮아지고, 전문가에게 필요한 정비 작업이 제안된다. - 클러스터 소유자는 대시보드의 점수와 세부 신호를 보고 우선적으로 관리할 영역을 결정한다. ## 사용자 대화로 이어지는 피드백 루프 - 모든 대화와 쿼리는 기록되어 클러스터 소유자에게 전달된다. - 소유자는 질문, 답변, 생성된 SQL, 사용자 피드백을 확인할 수 있다. - 전문가가 질문-SQL 쌍을 승인하거나 문서를 보완할 때마다 이후 사용자에게 제공되는 맥락이 개선된다. - 즉, 실제 사용 과정이 새로운 품질 관리와 지식 축적의 자료가 된다. - 어시스턴트의 신뢰도는 모델 자체보다 그 모델이 참조하는 맥락의 품질과 최신성에 달려 있다. ## 실용적인 시사점 데이터 AI를 구축할 때는 모든 스키마를 한꺼번에 제공하기보다, 도메인별로 범위를 나누고 전문가가 검증한 예시와 업무 규칙을 함께 관리하는 것이 효과적이다. 또한 자동 생성된 지식은 그대로 신뢰하지 말고 사람의 검토를 거치며, 스키마 변경·사용 패턴·쿼리 재현성을 기반으로 지속적인 품질 관리를 해야 한다.

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

모델 컨텍스트 프로토콜AI대규모 언어 모델slack+4

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

ODW #8: Slack MCP로 사고 대응과 FAQ 생성 작업 속도를 높이는 실습형 사내 워크숍 후기

Slack에 축적된 문의와 사고 대응 정보는 중요하지만, 문서화가 늦어지거나 담당자별 품질 차이로 지식 자산화가 어려웠다. 이 글은 사내 인증 기반 Slack MCP와 Confluence·Jira MCP를 결합해 FAQ, 사고 상황 요약, 인시던트 리포트를 자동 생성하는 워크숍 사례를 소개한다. 핵심은 기술 설명보다 실제 업무를 직접 자동화해 보고, 검증된 프롬프트를 스킬로 만들어 조직 전체에서 재사용하는 데 있다. ## Slack 정보의 구조화 격차 - Slack에는 사고 대응, 문의, 프로젝트 논의 등 실시간 업무 정보가 축적된다. - 그러나 문서화가 본업에 밀리거나 담당자에 따라 기록 품질이 달라진다. - 그 결과 중요한 정보가 Slack 스레드에 묻혀 재검색과 재활용이 어려워진다. - FAQ, 사고 보고서, 진행 상황 보고서 형태로 Confluence나 Jira에 정리할 필요가 있다. ## Slack MCP 도입과 워크숍 목표 - 사내 Slack MCP는 사내 인증과 연동되어 개인 토큰이나 복잡한 OAuth 설정 없이 Slack 정보에 접근할 수 있다. - 새로운 도구의 도입을 막는 요인은 다음과 같다. - 업무 중 별도로 학습할 시간 부족 - 설정과 활용에 대한 심리적 부담 - 사내 정보 확산의 지연 - 워크숍은 Slack MCP가 공개된 직후 빠르게 열어 참가자의 관심을 실습으로 연결했다. - 목표는 깊은 기술 지식 전달보다 참가자가 당일부터 업무에 활용할 수 있게 만드는 것이었다. ## Slack MCP의 주요 기능과 확장성 - Slack MCP는 다음 기능을 제공한다. - 메시지와 스레드 조회 - 메시지 게시 및 액션 실행 - 채널과 멤버 조회 - 메시지 검색 - Confluence MCP와 결합하면 프로젝트 보고서나 FAQ를 자동 생성하고 게시할 수 있다. - Jira MCP와 결합하면 Slack 논의를 바탕으로 작업 티켓을 만들 수 있다. - 워크숍에서는 먼저 AI에게 Slack 채널에 “Hello”를 게시하게 하여 MCP의 동작을 직접 체험하게 했다. ## 문의 대응 내용을 FAQ로 변환 - Slack 문의 채널의 대화를 검색해 FAQ 형식의 마크다운으로 변환했다. - 기존 Confluence FAQ와 대조해 이미 문서화된 내용은 제외했다. - 생성된 내용을 Confluence 하위 페이지로 게시하고, 증상·해결책·원인 구조의 표로 정리했다. - 활용 흐름은 다음과 같다. - 문의 채널과 Confluence 페이지 지정 - ‘문의’를 포함한 최신 스레드 검색 - 기존 FAQ와 중복 여부 확인 - 신규 문의만 FAQ 파일로 생성 - Confluence에 게시 - 이를 통해 반복 문의를 지식 베이스로 축적하고 담당자별 답변 품질 차이를 줄일 수 있다. ## 사고 상황 요약과 인시던트 리포트 생성 ### 빠른 상황 파악 - “시스템 장애 내용 및 상황을 정리해줘”와 같은 자연어 지시로 Slack 스레드를 검색한다. - AI는 해결 상태, 고객 영향, 담당자별 조치, 장애 타임라인을 요약한다. - 예를 들어 장애 감지 시각, 원인 파악 시각, 대응 완료 시각을 한눈에 정리할 수 있다. - 매니저가 중간에 합류하거나 담당자에게 직접 묻기 전에 전체 상황을 파악할 수 있어 의사 결정이 빨라진다. ### 인시던트 리포트 자동 작성 - 사전에 정한 형식에 따라 발생 시각, 감지 시각, 장애 기간, 원인, 영향 범위, 대응 내용을 자동 구조화한다. - 데이터베이스 커넥션 풀 고갈이나 설정 변경 누락 같은 원인과 사용자 수, 영향 기능, 데이터 손실 여부 등을 보고서에 포함할 수 있다. - 사고 대응 중에는 현황 요약을, 대응 완료 후에는 공식 리포트를 생성하는 식으로 목적에 맞게 활용한다. ## 정확도와 리뷰를 높이는 방법 - Slack의 모든 정보를 그대로 사용하지 말고 분석 범위를 먼저 좁혀야 한다. - 기존 Confluence 문서와 중복 제거 - 특정 리액션이 달린 메시지만 선택 - 특정 채널이나 기간, 키워드로 검색 범위 제한 - AI가 생성한 결과를 그대로 공개해서는 안 된다. - 개인정보 포함 여부 확인 - 원본 스레드 출처 표시 - 원래 발언을 과도하게 해석하지 않았는지 검토 - 실제 실습에서도 원본 스레드의 의도와 FAQ 내용이 미묘하게 달라지는 사례가 있어 사람의 리뷰가 필요함을 확인했다. - “증상·해결책·원인 세 칼럼의 표로 작성”처럼 출력 형식을 구체적으로 지정하면 팀 문서 표준에 맞는 결과를 얻기 쉽다. ## 재사용 가능한 스킬 설계 - 반복 작업은 스킬로 저장해 프롬프트를 매번 다시 작성하지 않도록 했다. - 워크숍에서 사용한 스킬은 다음 네 가지다. - `slack-to-faq`: Slack 스레드에서 FAQ 생성 - `faq-to-confluence`: FAQ를 Confluence에 게시 - `slack-incident-status`: 사고 상황 요약 - `slack-incident-report`: 인시던트 리포트 생성 - 스킬 제작 과정은 다음과 같다. - 수동으로 여러 프롬프트를 실험 - 효과적인 지시와 출력 형식 기록 - 재사용 가능한 스킬로 정의 - 팀에 공유하고 피드백을 반영해 개선 - 이를 통해 워크숍 참가자가 같은 절차를 재현하고, 팀 전체가 일관된 품질의 결과를 얻을 수 있다. ## 워크숍 운영에서 얻은 교훈 - 신기술이 등장해 관심이 높은 시점에 빠르게 교육을 제공하면 학습 참여를 높일 수 있다. - “Hello” 게시처럼 단순한 성공 경험부터 시작한 뒤 FAQ 생성과 사고 대응으로 난도를 높이는 단계적 구성이 효과적이다. - 일반적인 기능 소개보다 문의 대응과 장애 대응처럼 실제로 시간이 많이 드는 업무를 주제로 삼아야 활용 가능성을 쉽게 체감할 수 있다. - 기술 자체보다 참가자가 직접 손을 움직여 자신의 업무에 적용해 보는 경험이 현장 정착에 중요하다. 실무에서는 Slack MCP를 전사적으로 한꺼번에 도입하기보다, 반복 문의나 인시던트 보고처럼 효과를 측정하기 쉬운 업무부터 시작하는 것이 좋다. 원본 출처와 사람의 검토 절차를 반드시 포함하고, 검증된 작업 흐름은 스킬로 표준화해 점진적으로 확산하는 방식이 적절하다.

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

모델 컨텍스트 프로토콜생성형 AIslackclaude-code+4

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

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

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

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

모델 컨텍스트 프로토콜Figma디자인 시스템프로토타이핑+4

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

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

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

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

모델 컨텍스트 프로토콜CI/CDgitlabDevSecOps+3

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

이슈 16호: 프로세스를 믿으세요 | Figma 블로그

AI와 에이전트 도구의 발전으로 디자인과 개발 workflow가 빠르게 결합되고 있다. 하지만 제작 속도보다 중요한 것은 올바른 방향을 선택하고, 실제로 가치 있는 결과물을 출시하는 판단력이다. 이 글은 Figma의 MCP, Weave, 디자인-코드 왕복 작업 등을 통해 속도·맥락·완성도를 함께 높이는 방법을 소개한다. ## 빠른 제작보다 중요한 출시 판단 - AI는 제품 아이디어와 결과물을 빠르게 만들어 주지만, 잘못된 방향으로 빠르게 나아갈 위험도 키운다. - “충분히 괜찮은 결과물”에 머무르지 않고, 경쟁 제품과 차별화되는 결과를 만들려면 무엇을 출시할지 판단하는 능력이 필요하다. - Figma의 Chief Product Officer Yuhki Yamashita는 AI 시대의 제품팀이 터널 비전을 피하고, 사용자와 제품에 실질적인 가치를 주는 방향을 검증해야 한다고 설명한다. ## MCP로 디자인 맥락을 코드에 연결 - Model Context Protocol(MCP)은 에이전트형 코딩 도구가 Figma 파일과 디자인 시스템의 정보를 활용하도록 해준다. - 코드 작성 도구가 컴포넌트, 스타일, 레이아웃 등 디자인 의도를 직접 참고할 수 있어 디자인과 구현 사이의 불일치를 줄인다. - Figma MCP 서버는 디자인 결정이 코드가 작성되는 환경으로 전달되도록 하며, 결과적으로 실제 구현물이 원래 디자인에 더 가까워진다. - 디자이너와 개발자는 MCP가 제공하는 맥락을 더 구조화하고 명확하게 관리할수록 에이전트의 결과 품질을 높일 수 있다. ## Figma Weave를 활용한 시각 자산 제작 - Figma Weave는 영상, 사진, 일러스트레이션, 3D 효과 등 다양한 시각 작업에서 AI 이미지 생성과 정밀한 편집을 지원한다. - 단순히 프롬프트 하나로 이미지를 생성하는 것이 아니라, 시각적 언어와 제작 규칙을 반복적으로 적용하는 workflow가 중요하다. - 두 개의 참고 이미지만으로도 전체 자산 라이브러리를 확장할 수 있으며, 20개 이상의 workflow 템플릿이 이를 지원한다. - 주요 작업 방식은 다음과 같다. - 이미지 생성 - 기존 이미지 편집 - 프롬프트의 구조와 의도 조정 - 여러 자산에 일관된 스타일 적용 - 반복 가능한 시각 제작 프로세스 구축 ## 디자인과 코드의 왕복 작업 - 오늘날 팀은 캔버스에서 코드를 만들고, 코드에서 다시 캔버스로 돌아오는 방식으로 작업한다. - 디자인과 개발이 분리된 순차 과정이 아니라 서로 영향을 주고받는 반복 루프로 변하고 있다. - 실제 제품 상태를 디자인 캔버스로 가져오면 디자이너가 정적인 목업이 아니라 실제로 출시될 화면과 상호작용을 다듬을 수 있다. - 이러한 왕복 작업은 다음 효과를 준다. - 디자인과 코드 사이의 간극 축소 - 구현 결과에 대한 빠른 피드백 - 제품 상태와 예외 상황을 디자인에 반영 - 개발 속도를 유지하면서도 완성도 향상 ## 실무 workflow와 생산성 팁 - Figma MCP를 활용해 비디오 export flow의 문제를 점검하고, 실제 제품 상태를 캔버스에 반영하는 사례가 소개된다. - 팀이 빠르게 제작할수록 디자인과 코드가 서로 다른 방향으로 움직일 가능성도 커지므로, 두 환경을 연결하는 장치가 중요하다. - Figma Make를 자주 사용하는 사용자를 위해 크레딧을 효율적으로 사용하고 작업 속도를 높이는 7가지 팁도 제공된다. - AI 도구의 활용도는 단순 사용 횟수보다 프롬프트 품질, 맥락 제공, 반복 가능한 프로세스 설계에 좌우된다. AI 도구를 도입할 때는 생성 속도만 평가하지 말고, 디자인 맥락이 코드까지 전달되는지, 결과를 반복적으로 개선할 수 있는지, 실제 출시 가치가 있는지를 함께 검토하는 것이 좋다. Figma MCP와 Weave 같은 도구를 활용하되, 최종 방향과 품질 기준은 사람이 명확히 관리해야 한다.

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

모델 컨텍스트 프로토콜FigmaAIdesign-to-code+2