모델 컨텍스트 프로토콜

97 개의 포스트

dropbox4분 읽기큐레이션 요약

범용 콘텐츠 처리 플랫폼 Riviera가 AI와 그 너머를 위해 어떻게 진화했는가

Dropbox의 콘텐츠 처리 플랫폼 Riviera는 파일 미리보기 서비스에서 출발해 Search, Replay, Sign, Dash 등 여러 제품이 공유하는 범용 변환 플랫폼으로 발전했다. 핵심 설계는 파일별·제품별 파이프라인을 따로 만드는 대신, PDF 변환·페이지 이미지 생성·텍스트 추출 같은 작은 변환 작업을 재사용 가능한 플러그인으로 조합하는 것이다. AI 제품의 확산으로 문서와 미디어를 일관된 형태로 준비하는 수요가 커지면서, Dropbox는 Riviera의 기능을 외부 개발자와 설계 파트너에게 API와 Model Context Protocol 도구로 공개했다. ## 미리보기 문제에서 시작된 플랫폼 - Dropbox는 300개가 넘는 파일 형식을 지원하며, 각 형식에서 썸네일, 전체 미리보기, 추출 텍스트, 스트리밍 매니페스트, 메타데이터 등 다양한 결과물을 생성해야 했다. - 파일 형식과 출력물마다 별도 서비스를 만들면 다음 문제가 발생한다. - 동일한 변환 로직이 여러 서비스에 중복됨 - 의존성, 패키지 버전, 설정이 서로 달라짐 - 유지보수와 운영 부담이 커짐 - Riviera는 모든 미리보기를 독립적인 기능으로 보지 않고, 재사용 가능한 작은 변환 단계의 조합으로 정의했다. - 예를 들어 PowerPoint 미리보기는 다음처럼 처리할 수 있다. - PowerPoint를 PDF로 변환 - PDF의 각 페이지를 이미지로 변환 - 생성된 이미지를 Dropbox 화면에서 표시 - PDF를 이미지로 바꾸는 단계는 PDF 자체의 미리보기나 다른 페이지 이미지 생성 작업에도 재사용할 수 있다. ## 조정과 실행을 분리한 아키텍처 - Riviera의 중앙 구성 요소는 변환 요청을 수집하고, 작업을 조합하며, 적절한 백엔드 워커에 분배한다. - 중앙 계층은 다음 기능을 담당한다. - 요청 유효성 검증 - 변환 작업 구성 - 결과 캐싱 - 중복되거나 잘못된 작업 차단 - 각 백엔드 워커는 특정 변환 유형을 담당한다. - 기능별로 독립적인 유지보수와 확장이 가능함 - 특정 변환의 처리량에 맞춰 개별적으로 확장할 수 있음 - 새로운 파일 형식이나 변환 유형을 추가할 때 핵심 인프라를 수정하는 대신 플러그인을 추가하면 된다. - 현재 Riviera는 100개가 넘는 변환 기능을 제공하며, 초당 수십만 건의 변환을 처리한다. - 이 구조 덕분에 핵심 플랫폼은 안정적으로 유지하면서 지원 파일 형식과 제품 기능을 계속 확장할 수 있었다. ## 여러 제품이 공유하는 변환 라이브러리 - Riviera는 처음에는 전담 Previews 팀이 운영하는 내부 서비스였지만, 다른 팀들도 동일한 콘텐츠 처리 문제를 겪고 있다는 사실이 드러났다. - 예를 들어 미리보기용으로 만든 160×160 썸네일은 머신러닝 팀의 이미지 정규화에도 활용할 수 있었다. - 같은 결과물을 여러 소비자가 사용하면 변환을 한 번만 수행하면 됨 - Search 팀은 문서를 검색 인덱싱에 적합한 형태로 준비하기 위해 Riviera를 도입했다. - Sign, DocSend, Replay 같은 제품도 기존 변환 기능을 재사용했다. - 이후 Dropbox는 플러그인 모델을 제품 팀에 개방했다. - Riviera 팀은 핵심 아키텍처를 관리 - 각 제품 팀은 필요한 변환 플러그인을 추가 - 추가된 플러그인은 다른 팀도 사용할 수 있는 공유 자산이 됨 ## Replay가 보여준 플러그인 모델의 효과 - 동영상 리뷰 제품인 Replay는 동영상 트랜스코딩과 조작이라는 복잡한 처리 작업이 필요했다. - Riviera의 미디어 변환 기능을 활용함으로써 Replay 팀은 동영상 처리 인프라를 처음부터 구축하지 않아도 됐다. - 제품 팀이 변환 기능을 요청하면 Riviera가 기존 기능을 노출하거나 새 플러그인을 추가하는 방식이 정착됐다. - 그 결과 기존에는 수개월이 걸릴 수 있었던 기능을 수주 안에 출시할 수 있었고, 새로운 플러그인이 추가될수록 다음 제품의 개발도 빨라졌다. ## Dash와 AI가 만든 새로운 요구 - AI 모델이 문서에 답변하거나 보고서를 요약하려면 먼저 문서가 모델이 처리할 수 있는 일관된 형태로 변환되어야 한다. - 필요한 전처리에는 다음 작업이 포함된다. - 텍스트 추출 - 스캔 문서의 페이지 인식 - 메타데이터 추출 - 다양한 파일 형식의 통일된 표현으로 변환 - 이러한 작업은 본질적으로 AI 모델 자체의 문제가 아니라 콘텐츠 변환 문제이며, Riviera가 기존부터 해결해 온 영역이다. - Dash 팀은 Riviera가 이미 지원하던 수백 가지 파일 형식과 변환 기능을 활용해 별도의 문서 처리 시스템을 새로 만들 필요를 줄였다. - Riviera는 미리보기와 미디어 처리뿐 아니라 검색, 문서 자동화, AI용 콘텐츠 준비에도 적용되는 기반 계층으로 확장됐다. ## 외부 개발자를 위한 공개 - Dropbox는 Riviera에서 축적한 콘텐츠 변환 기능을 API와 Model Context Protocol 도구 형태로 개발자 생태계와 설계 파트너에게 제공하기 시작했다. - 활용 사례로는 다음과 같은 작업이 제시된다. - 콘텐츠 관리 시스템 구축 - 문서 처리 워크플로 자동화 - 파일 검색용 인덱싱 - AI 애플리케이션용 문서 전처리 - 핵심 가치는 제품마다 변환 인프라를 새로 구축하지 않고, 검증된 공통 플랫폼을 이용할 수 있다는 점이다. Riviera의 사례는 대규모 콘텐츠 처리를 제품별 기능이 아니라 재사용 가능한 변환 조합과 플러그인 플랫폼으로 설계해야 한다는 점을 보여준다. 특히 AI 애플리케이션을 만들 때 모델 개발에만 집중하기보다, 다양한 파일을 안정적으로 추출·정규화·변환하는 기반을 먼저 확보하는 것이 실용적인 접근이다.

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

GitLab Transcend 해커톤: 개발자들이 GitLab Orbit에서 만든 것

GitLab Orbit 해커톤은 코드·머지 리퀘스트·파이프라인·배포·소유권을 연결한 실시간 코드 그래프가 AI 에이전트의 시스템 이해 문제를 해결할 수 있음을 보여줬다. 1,576명이 참가해 265개 프로젝트를 만들었고, 참가자들은 변경 영향 분석, 테스트 최적화, 마이그레이션 비용 산정, 보안 취약점 추적 같은 반복적인 실무 문제에 집중했다. 특히 에이전트의 실행 속도뿐 아니라 근거와 책임성을 확보하는 것이 중요하다는 점이 강조됐다. ## GitLab Orbit와 해커톤 규모 - GitLab Orbit는 다음 정보를 관계형 그래프로 연결하고 최신 상태로 유지한다. - 소스 코드와 의존성 - 머지 리퀘스트 - CI 파이프라인 - 배포 정보 - 팀과 코드 소유권 - AI 에이전트는 코드 작성에는 강하지만, 변경 사항이 시스템 전체에 미치는 영향 파악에는 취약하다. - Orbit를 사용하면 “무엇이 이 변경에 의존하는가”, “어떤 테스트가 영향을 받는가”, “문제 발생 시 담당 팀은 누구인가” 같은 질문을 단일 쿼리로 처리할 수 있다. - 해커톤에는 1,576명이 등록했고, 265개의 Showcase Track 프로젝트가 제출됐다. - 별도로 26명의 기여자가 Orbit 코드베이스에 61개의 개선 사항을 병합했다. ## 개발자들이 가장 많이 해결하려 한 문제 - 70개 팀이 변경 사항의 잠재적 영향 범위를 분석하는 도구를 만들었다. - 하위 호출자 - 영향받는 파이프라인 - 관련 팀과 소유자 - 30개 이상의 팀은 코드베이스 온보딩과 이해를 돕는 도구를 개발했다. - 그 밖에도 다음 문제가 주요 주제로 등장했다. - 장애의 근본 원인 분석 - 아키텍처 드리프트 탐지 - 불안정한 파이프라인 진단 - 여러 저장소에 걸친 CVE 추적 - 공통점은 기존에는 Git, CI, 배포 도구, 대시보드에 흩어진 정보를 사람이 직접 조합해야 했다는 점이다. - Orbit는 단순히 에이전트를 자동화하는 것이 아니라, 실행에 필요한 시스템 맥락과 통제 수단을 함께 제공한다. ## 시스템 통합과 자동화 ### Sankofa: 상황별 세 가지 에이전트 - 기술 구현 부문 우승작이다. - 사용자의 업무 상황에 따라 세 에이전트가 작동한다. - **Radar**: 머지 리퀘스트가 열리면 변경의 영향 범위와 관련 파이프라인, 담당 팀을 분석한다. - **Guide**: 이슈가 할당되면 작업 시작에 필요한 요약 보고서를 작성한다. - **Shield**: 보안 취약점이 발생하면 코드 그래프를 한 번 탐색해 취약점의 전파 경로를 추적한다. - 취약점의 영향을 여러 저장소와 의존성에 걸쳐 수동으로 추적하던 작업을 자동화했다. ### Stayed Shipped: AI 코드의 실제 운영 여부 추적 - AI 에이전트가 지난달 병합한 변경 중 실제 운영 환경에 남아 있는 비율을 확인한다. - 이후 시니어 개발자가 조용히 수정하거나 대체한 변경도 추적한다. - 기존 대시보드가 제공하지 못하는 “AI가 만든 코드가 실제로 살아남았는가”라는 지표를 제시한다. ## 마이그레이션 비용과 작업 계획 ### Carver: 레거시 마이그레이션 견적 - 디자인·사용성 부문 우승작이다. - 사용자가 원하는 마이그레이션을 입력하면 Orbit의 의존성 그래프를 분석해 다음을 산출한다. - 작업 단위 수 - 예상 기간 - 수행 순서 - 위험 요소 - 예시로 AngularJS에서 Angular로의 전환을 약 9주간의 인력 작업과 약 10달러의 생성 비용으로 추정한다. - 테스트되지 않은 핵심 서비스처럼 위험도가 높은 부분은 별도로 표시한다. - Orbit에서 실제 서비스를 찾지 못하면 임의의 수치를 만들지 않고 사용자에게 실제 코드 위치를 확인한다. ### Marshal: 조직 전체의 자율 마이그레이션 - 조직 단위 목표를 선언하면 영향받는 저장소를 찾고 작업 순서를 계획한다. - 작업을 여러 웨이브로 나누어 머지 리퀘스트를 생성하고, 대상 저장소가 누락되지 않았는지 확인한다. - Carver가 통제 가능한 견적과 설명에 집중한다면, Marshal은 최대한의 자율 실행을 지향한다. ## 영향 기반 테스트와 정밀한 리팩터링 ### CrossCut: 변경에 필요한 테스트만 실행 - 영향력 부문 우승작이다. - 머지 리퀘스트에서 변경된 심볼을 찾고, Orbit의 호출 그래프를 따라 실제로 영향을 받는 테스트를 계산한다. - 모델의 추측 없이 그래프 탐색만으로 테스트 파이프라인을 구성한다. - 대규모 또는 여러 저장소에 걸친 테스트 스위트에서 CI 실행량을 90% 이상 줄일 수 있다. ### OrbitWeaver: 의존성 순서를 반영한 리팩터링 - 벡터 유사도 검색이 아니라 정확한 영향 범위를 사용한다. - 영향을 받는 모든 파일을 매핑하고 의존성 순서에 따라 수정한다. - 단순한 의미적 유사성보다 실제 코드 그래프가 안전한 자동 리팩터링에 적합하다는 점을 보여준다. ## 시맨틱 웹과 에이전트 거버넌스 ### Transcend: Orbit 위에 새로운 추론 계층 구축 - 아이디어 품질 부문 우승작이다. - Orbit API를 단순히 호출하는 대신 OWL, SPARQL, RDF를 활용한 시맨틱 웹 기반 추론 엔진을 추가했다. - 기본 API만으로는 어려운 다음 작업을 수행한다. - 전이적 폐쇄 계산 - 코드베이스와 외부 지식 그래프의 조인 - 코드와 관련 논문, 저자, 발표 연도의 연결 - 예를 들어 코드베이스가 구현한 지식 그래프 임베딩 기법의 클래스명과 이를 뒷받침한 논문 정보를 함께 조회한다. ### Universal Agent OS: 에이전트의 책임성과 검증 - 에이전트 자체보다 에이전트를 통제하는 거버넌스 계층을 만든다. - 다음 절차를 강제한다. - 먼저 사용자 인터뷰 수행 - 코딩 전 계획 수립 - 의사결정 근거 보존 - 결과 검증 - AI가 작성하는 코드의 비중이 커질수록 빠른 실행보다 누가 어떤 근거로 결과를 승인했는지가 중요해진다는 문제의식을 담고 있다. ## Orbit 자체에 대한 커뮤니티 기여 - Contribute Track에서는 26명이 Orbit에 직접 61개의 머지 리퀘스트를 병합했다. - 주요 개선 내용은 다음과 같다. - C++20 concepts 지원 - Go 패키지 선언 지원 - Kotlin 코루틴 지원 - Ruby 람다 지원 - 온톨로지 수정 - CI에서 발생하던 SIGPIPE 버그 수정 - 첫 Orbit 쿼리 튜토리얼 작성 - `max_depth`와 `max_hops` 차이를 포함한 문서 정리 - 참가자들은 Orbit를 활용한 애플리케이션뿐 아니라 기반 플랫폼 자체도 개선했다. 실무에서는 AI 에이전트에 코드를 바로 작성하게 하기보다, 먼저 변경 영향 분석·관련 테스트 선택·소유 팀 확인·근거 기록을 Orbit로 연결하는 것이 효과적이다. 특히 대규모 저장소에서는 정확한 의존성 그래프가 CI 비용 절감과 안전한 리팩터링의 기반이 될 수 있다.

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

GitLab Duo로 작업 항목 할당 자동화

GitLab Duo Agent Platform의 새로운 **“Work item created” 트리거**는 작업 항목이 생성되는 즉시 플로우를 실행해 자동으로 분류하고 담당자를 배정한다. 이를 통해 사람이 일일이 팀원의 업무량과 가용성을 확인하던 과정을 없애고, 대규모 작업도 몇 초 안에 일관되게 라우팅할 수 있다. 예시에서는 GitLab Orbit과 두 개의 에이전트를 활용해 업무량이 가장 적은 팀원에게 새 이슈를 자동 배정했다. ## 수동 담당자 배정의 한계 - 새 이슈가 생성될 때마다 담당자가 팀원의 현재 업무량과 우선순위를 확인해야 한다. - 회의, 휴가, 휴식 시간 등으로 인해 배정이 지연될 수 있다. - 작업량이 증가하면 업무가 특정 팀원에게 몰리거나 초기 트리아지가 늦어진다. - 기존 GitLab Duo Flow는 멘션, 수동 할당, 리뷰어 지정 등 사람의 행동이 있어야 시작할 수 있었다. - 따라서 자동화된 배정 로직이 있어도 마지막 실행 단계는 수작업으로 남아 있었다. ## “Work item created” 트리거의 동작 - 프로젝트에서 새 작업 항목이 생성되는 순간 플로우를 자동 실행한다. - 별도의 멘션이나 UI 조작 없이 백그라운드에서 지속적으로 동작한다. - 조직이 정의한 조건에 따라 작업을 분류하고 적절한 담당자에게 라우팅한다. - 개발자는 반복적인 배정 업무보다 판단과 창의성이 필요한 작업에 집중할 수 있다. ## 자동화로 얻는 효과 - **즉각적인 트리아지:** 작업 생성 직후 배정이 시작된다. - **확장성:** 작업이 한 건이든 수백 건이든 담당자의 추가 개입 없이 처리한다. - **균형 잡힌 배정:** 팀원의 현재 미해결 작업 수와 가용성을 기준으로 배정할 수 있다. - **일관성:** 사람이 매번 판단하던 기준을 에이전트가 동일하게 적용한다. - **반복 업무 감소:** 팀 리드가 업무량을 확인하고 수동으로 라우팅하는 시간을 줄인다. ## 두 에이전트로 구성한 자동 배정 플로우 예시 프로젝트는 `Intra-account-transfers`이며, 플로우 이름은 `Work item assigner`다. - 프로젝트에서 “Work item created” 트리거를 활성화한다. - 첫 번째 에이전트는 GitLab Orbit을 사용해 조직 내 각 리소스의 미해결 작업 수를 조회한다. - 두 번째 에이전트는 업무량이 가장 적은 팀원을 식별하고 새 작업 항목의 담당자로 지정한다. - 배정 절차와 도구 사용 방법은 각 에이전트의 프롬프트에 정의된다. - 트리거가 플로우 전체를 실행하므로 별도의 수동 시작 작업이 필요하지 않다. ## 실행 과정과 결과 - 새 이슈를 생성하면 트리거가 즉시 `Work item assigner` 플로우를 실행한다. - 플로우 활동 로그에서 각 단계의 진행 상황을 확인할 수 있다. - 첫 번째 에이전트가 최상위 그룹 내 사용자의 미해결 작업 수를 집계한다. - 두 번째 에이전트가 가장 적은 업무량을 가진 팀원을 선택한다. - 예시에서는 William이 담당자로 선정되었고, 이슈에 자동으로 할당되었다. ## 확장 가능한 개선 방향 - **HR 또는 휴가 시스템 연동:** MCP를 통해 PTO 기간을 조회하고 휴가 중인 팀원을 배정 대상에서 제외할 수 있다. - **캘린더 연동:** 회의 일정과 실제 가용 시간을 확인해 더 정확한 담당자 배정이 가능하다. - 업무량뿐 아니라 전문 분야, 우선순위, 프로젝트 소속 등의 조건을 추가해 라우팅 기준을 고도화할 수 있다. ## 실용적인 결론 반복적인 이슈 배정이 병목이 되는 팀이라면 “Work item created” 트리거와 업무량 조회 에이전트를 결합하는 것이 효과적이다. 초기에는 미해결 작업 수처럼 단순하고 검증 가능한 기준으로 시작한 뒤, 휴가·캘린더·전문성 정보를 MCP로 추가하는 방식이 현실적이다.

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

GitLab 19.2 릴리스 노트 | GitLab Docs

GitLab 19.2는 GitLab Duo와 AI 에이전트 기능을 중심으로 개발·보안·운영 자동화를 강화한 릴리스입니다. Duo CLI와 커스텀 플로우가 정식 출시되었고, 정책 기반 예약 파이프라인과 Agentic Chat 연동이 추가되었습니다. 또한 의존성 취약점 자동 수정, 비기본 브랜치 취약점 추적, 하위 그룹 단위의 Duo 접근 제어가 베타 또는 정식 기능으로 제공됩니다. ## GitLab Duo CLI 정식 출시 - 터미널에서 GitLab Duo Agent Platform을 사용할 수 있습니다. - 코드베이스에 대한 복잡한 질문을 하거나 변경 작업을 자율적으로 수행하도록 요청할 수 있습니다. - 외부 AI 도구와 달리 GitLab 프로젝트, 파이프라인, 에이전트 설정을 문맥으로 활용합니다. - 주요 기능: - 대화형 모드와 CI/CD용 헤드리스 모드 - 모델 선택 및 세션 공유 - 도구 실행 승인 - MCP(Model Context Protocol) 연결 - 슬래시 명령어와 컨텍스트 사용량·압축 관리 - `AGENTS.md`와 스킬을 활용한 사용자 정의 - `glab`을 통해 설치하거나 독립 실행형 도구로 설치할 수 있습니다. - GitLab Self-Managed와 Dedicated에서는 관리자가 기능을 켜거나 끌 수 있습니다. ## GitLab Duo 커스텀 플로우 정식 출시 - 여러 단계로 구성된 AI 기반 작업 흐름을 YAML로 정의하고 재사용할 수 있습니다. - GitLab 이벤트에 따라 반복적인 개발·운영 작업을 자동 실행합니다. - 주요 기능: - 팀별 YAML 워크플로 - 복잡한 작업을 위한 멀티 에이전트 오케스트레이션 - 승인이나 피드백을 받는 HITL(Human-in-the-loop) 체크포인트 - 멘션, 담당자 지정, 파이프라인, 머지 리퀘스트 이벤트 트리거 - 프로젝트 또는 AI Catalog에서 플로우 생성·관리 - 공개·비공개 가시성 설정 - 서비스 계정과 복합 ID를 이용한 보안 실행 - 실행 전 YAML 검증 - GitLab CI/CD 안에서 실행되므로 별도 외부 자동화 플랫폼 없이 운영할 수 있습니다. ## 예약 파이프라인 실행 정책 정식 출시 - 보안 정책 프로젝트에서 일정을 한 번 정의하면 범위 내 여러 프로젝트에 강제 적용할 수 있습니다. - 각 프로젝트의 `.gitlab-ci.yml`을 직접 수정하지 않아도 됩니다. - 커밋 활동과 무관하게 일·주·월 단위로 다음 작업을 실행할 수 있습니다. - 컴플라이언스 검사 - 보안 스캔 - 의존성 취약점 점검 - 각 정책은 별도 파이프라인으로 실행됩니다. - 시간대, 실행 시간 분산 범위, 대상 브랜치를 설정할 수 있습니다. - 코드 변경이 드문 저장소에서도 새롭게 발견된 취약점을 주기적으로 탐지하는 데 유용합니다. ## Agentic Chat에서 기본 플로우 시작 - 기존에는 특정 UI 동작, 멘션, 담당자 지정 등을 통해 시작하던 기본 플로우를 Agentic Chat 대화 중에도 실행할 수 있습니다. - 요청 내용에 맞춰 전문 플로우로 넘길 수 있습니다. - Developer Flow: 코드 변경 또는 머지 리퀘스트 생성 - Code Review Flow: 머지 리퀘스트 검토 - Fix CI/CD Pipeline Flow: 실패한 파이프라인 진단 및 수정 - 사용자가 채팅에서 전환을 승인한 뒤, 대화창이나 **AI > Sessions**에서 진행 상황을 확인합니다. ## 의존성 스캔 자동 수정 베타 - 취약한 의존성을 자동으로 수정하는 두 가지 기능이 추가되었습니다. - 자동 의존성 버전 업데이트: - 취약한 의존성을 안전한 버전으로 올리는 머지 리퀘스트를 자동 생성합니다. - 기본적으로 패치 및 마이너 버전 업데이트를 대상으로 합니다. - Agentic Breaking Change Resolution: - 의존성 업데이트 후 파이프라인이 주요 변경 사항으로 실패하면 GitLab Duo가 원인을 분석합니다. - 파이프라인 오류, 의존성 변경 로그, 프로젝트의 실제 사용 방식을 함께 검토합니다. - 같은 머지 리퀘스트에 수정 사항을 커밋하고 파이프라인을 통과할 때까지 재실행합니다. - 활성화하면 메이저 버전 업데이트도 대상에 포함됩니다. - GitLab Credits를 사용합니다. - 결과적으로 GitLab이 수정 머지 리퀘스트를 생성하고, Duo가 복잡한 호환성 문제까지 해결하는 자동화된 보안 수정 흐름을 제공합니다. ## 비기본 브랜치 취약점 추적 베타 - 기본 브랜치 외에도 장기 유지되는 릴리스·배포 브랜치의 취약점을 추적할 수 있습니다. - 예시는 다음과 같습니다. - `project-qa` - `project-prod` - `project-iOS` - `project-android` - 보안 설정에서 추적 브랜치를 추가할 수 있으며, 네임스페이스 프로젝트 수의 최대 두 배까지 등록할 수 있습니다. - 취약점 보고서와 프로젝트 보안 대시보드에서 브랜치별 필터링을 지원합니다. - CVE를 포함한 모든 취약점 유형을 추적합니다. - 브랜치가 기본 브랜치에 병합될 때 취약점 상태 메타데이터를 일관되게 유지합니다. - 추적 브랜치의 취약점 상태도 갱신할 수 있습니다. - 사용 브랜치는 너무 많이 지정하기보다 환경별·플랫폼별 장기 브랜치로 제한하는 것이 권장됩니다. ## 하위 그룹별 GitLab Duo 접근 제어 - GitLab Dedicated 및 Dedicated for Government 관리자는 특정 하위 그룹에서 Duo와 Duo Agent Platform을 제한할 수 있습니다. - 기존에는 전체 인스턴스에서 비활성화하거나 모든 그룹에서 사용 가능하게 하는 방식만 제공되었습니다. - 이제 하위 그룹별 기본 거부(default-deny) 및 허용 목록(allowlist) 정책을 적용할 수 있습니다. - 특정 그룹을 **Always off**로 잠그면 하위 그룹과 프로젝트에서도 기능을 활성화할 수 없습니다. - 다른 그룹은 Owner 권한 사용자의 선택에 맡길 수 있습니다. - 잠금 설정과 해제는 관리자만 수행할 수 있으며, 영향을 받는 Owner에게는 상위 그룹 정책으로 기능이 잠겼다는 안내가 표시됩니다. - 조직의 규정 준수와 AI 기능 사용 범위에 대한 플랫폼 거버넌스를 세밀하게 관리할 수 있습니다. ## 실용적인 적용 방향 - 개발팀은 Duo CLI와 Agentic Chat을 코드 작성, 코드 리뷰, 실패한 파이프라인 수정에 활용할 수 있습니다. - 보안팀은 예약 파이프라인 정책과 의존성 자동 수정으로 지속적인 취약점 대응 체계를 구성할 수 있습니다. - 릴리스 브랜치를 운영하는 조직은 비기본 브랜치 추적을 제한적으로 적용하는 것이 좋습니다. - 규제 환경에서는 하위 그룹별 Duo 허용 정책을 사용해 AI 기능을 조직 단위로 통제하는 것이 적합합니다.

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

GitLab Duo Agent Platform을 터미널로 가져오세요

GitLab 19.2에서 GitLab Duo CLI가 정식 출시되어, 코드 작성뿐 아니라 파이프라인 실패·테스트·보안 취약점·CI/CD 작업까지 터미널에서 처리할 수 있게 됐다. GitLab 프로젝트와 파이프라인, 에이전트 설정 및 권한 정보를 이미 알고 있어 별도 도구보다 더 일관된 컨텍스트를 제공한다. 대화형 모드와 CI·스크립트용 헤드리스 모드를 모두 지원하며, 터미널·GitLab UI·에디터 간 세션도 공유된다. ## 터미널 중심 개발의 필요성 - 기존 에이전트형 AI는 파일 편집과 코드 생성에 집중되어 있었다. - 실제 소프트웨어 전달 과정에서는 다음과 같은 문제가 자주 발생한다. - 파이프라인 실패 - 테스트 오류 - 의존성 문제 - CI 설정 오류 - 보안 취약점 - 이러한 문제의 핵심 컨텍스트는 로컬 코드보다 GitLab 프로젝트와 파이프라인에 있기 때문에, 일반적인 코딩 전용 CLI 도구로는 충분히 대응하기 어렵다. - 외부 CLI 도구를 사용하면 조직 단위 관리자 제어, MCP 설정 진단, GitLab 전체 에이전트 생명주기와의 통합이 부족할 수 있다. ## GitLab Duo CLI의 주요 기능 - 터미널에서 코드 탐색, 리팩터링, CI/CD 정리, 파이프라인 장애 분석, 다단계 작업을 수행할 수 있다. - GitLab UI, Duo CLI, 에디터 확장 기능 사이에서 세션과 대화가 공유된다. - 브라우저에서 시작한 작업을 터미널에서 이어갈 수 있다. - 동일한 프로젝트 맥락과 대화 내용을 유지할 수 있다. - GitLab.com, GitLab Self-Managed, GitLab Dedicated에서 사용할 수 있다. - Self-Managed와 Dedicated 환경에서는 관리자가 인스턴스 단위로 접근을 활성화하거나 비활성화할 수 있다. - `/doctor` 명령으로 설치·환경 설정을 점검하고, `/mcp` 명령으로 MCP 구성을 확인할 수 있다. ## 계획 모드와 빌드 모드 - **Plan 모드** - 코드베이스와 관련 상황을 조사한다. - 파일을 변경하지 않고 해결 방법을 먼저 계획한다. - **Build 모드** - 사용자가 승인한 뒤 실제 코드나 설정을 변경한다. - 대화형 세션에서는 도구 실행 전에 승인을 요청하므로, 변경 사항을 검토하면서 작업할 수 있다. ## 헤드리스 모드와 자동화 - 헤드리스 모드는 사용자의 입력이나 승인 없이 실행되는 비대화형 방식이다. - CI 러너, 셸 스크립트, 자동화 작업에 적합하다. - 다음 명령으로 목표를 전달해 실행할 수 있다. ```bash glab duo cli run --goal duo run --goal ``` - 예를 들어 현재 셸에서 다음과 같이 특정 머지 리퀘스트의 파이프라인 실패 원인 분석과 수정안을 요청할 수 있다. ```bash glab duo cli > The pipelines in MR 23 are failing. Please help me fix them. ``` - Duo CLI는 관련 상황을 분석하고 수정안을 제안한 뒤, 적용 전에 검토할 수 있도록 한다. ## 설치와 실행 방식 - GitLab CLI를 사용하는 가장 간단한 방법은 다음 명령이다. ```bash glab duo cli ``` - `glab`이 인증을 처리하므로 별도의 인증 절차를 줄일 수 있다. - Duo CLI를 독립 도구로 설치하고 개인 액세스 토큰으로 실행하는 방식도 제공된다. ```bash duo ``` - 두 방식 모두 대화형 모드와 헤드리스 모드 등 동일한 기능을 지원한다. ## 프로젝트 지침과 확장성 - Duo CLI는 프로젝트 또는 조직의 사용자 지정 지침을 따를 수 있다. - 지원되는 지침 파일의 예시는 다음과 같다. - `chat-rules.md` - `AGENTS.md` - `SKILL.md` - 대화형 세션에는 사용자 정의 슬래시 명령을 추가할 수 있어 팀의 반복적인 작업 흐름을 확장할 수 있다. ## 실용적인 활용 방법 GitLab CLI를 이미 사용 중인 팀은 `glab duo cli`부터 도입하는 것이 좋다. 먼저 Plan 모드로 파이프라인이나 CI 설정 문제를 분석한 뒤 Build 모드에서 변경을 승인하고, 반복 작업은 `run --goal`을 이용해 CI나 스크립트에 연결하면 된다. 관리자는 Self-Managed·Dedicated 환경에서 접근 권한과 MCP 구성을 점검한 후 단계적으로 배포할 수 있다.

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

AWS 주간 정리: 1주년을 맞은 AWS Builder Center, Security Hub의 네트워크 스캐닝, AWS용 Loom 등 (2026년 7월 13일) | Amazon Web Services

AWS Builder Center가 출범 1주년을 맞아 샌드박스, 워크숍, 커뮤니티 기능을 갖춘 AWS 학습·개발 생태계로 확장됐다. 동시에 AWS Security Hub의 네트워크 스캐닝 및 Azure 지원, SageMaker와 Hugging Face 통합, GPU 관리 비용 인하, Aurora DSQL CDC 정식 출시 등 주요 서비스 업데이트가 발표됐다. AWS는 보안·AI 에이전트·멀티클라우드 관리 기능을 통합해 개발 편의성과 운영 자동화를 강화하는 방향을 보이고 있다. ## AWS Builder Center의 1년 성장 - 2025년 7월 9일 출시 이후 커뮤니티 허브에서 종합 개발자 생태계로 확장됐다. - 주요 기능: - AWS 리전별 서비스 현황 - 커뮤니티가 직접 만드는 Spaces - 카테고리·난이도별 워크숍 - 배지와 연속 활동 기록 - 아티클 시리즈, 조회 수, 저장 항목 - 학생 상태 및 서비스 출시 알림 - GitHub·Amazon 계정 로그인 - 무료 샌드박스 환경 - 5,548명의 작성자가 6,448개 아티클을 게시했으며, 누적 조회 수는 1,040만 회를 넘었다. - 2026년 3월 배지 시스템 출시 후 약 99,226개의 배지가 발급됐다. - 사용자 요청 565건 중 10건이 실제 출시됐고, 20건은 단기 로드맵에 포함됐다. - 인기 글: - MCP와 Strands Agents SDK 기반 AWS Study Buddy: 5만 회 이상 - Kiro를 활용한 EOL Linux 서버 AWS 이전: 4만 5천 회 이상 - 신경 질환 조기 검사를 위한 멀티모달 AI: 3만 8천 회 이상 ## 8시간짜리 무료 AWS 샌드박스 - 워크숍 실습을 위해 사전 구성된 무료 AWS 계정을 제공한다. - 개인 AWS 계정, 신용카드, 수동 리소스 정리가 필요 없다. - 환경은 최대 8시간 동안 활성화되며 이후 계정과 리소스가 자동으로 제거된다. - 한 번에 하나의 샌드박스만 사용할 수 있고, 주 1회 신청할 수 있다. - AWS 서비스를 안전하게 실습하거나 교육용 워크숍을 진행하는 데 적합하다. ## Security Hub의 네트워크 및 멀티클라우드 보안 - **Network Scanning**은 실제 인터넷에서 리소스에 접근 가능한지를 직접 확인한다. - AWS와 Azure 환경에서 다음 리소스를 탐색한다. - 공용 IP 주소 - 가상 머신 - 로드 밸런서 - 접근 가능한 포트와 해당 포트에서 실행 중인 서비스를 식별한다. - 접근 가능한 포트마다 발견 근거와 함께 Security Hub finding을 생성한다. - 기존 네트워크 도달 가능성 분석이 “도달 가능하게 만들 수 있는 구성”을 찾는다면, Network Scanning은 실제 인터넷 도달 여부를 검증한다. - Security Hub Exposures가 관련 설정 및 보안 결과를 결합해 전체적인 위험도를 계산한다. - 신규 고객에게는 기본 활성화되며, 기존 고객은 계정·리전별 또는 조직 정책으로 활성화할 수 있다. - Security Hub Essentials에 추가 비용 없이 포함된다. - Azure 리소스도 자동 검색해 다음 항목을 통합 관리한다. - VM, 컨테이너 이미지, Function Apps, ID - 설정 오류, 인터넷 노출, 소프트웨어 취약점 - AWS와 Azure의 보안 결과를 동일한 형식과 자동화 흐름으로 한 화면에서 관리할 수 있다. ## SageMaker Studio와 Hugging Face 통합 - Hugging Face에서 모델을 선택한 뒤 한 번의 클릭으로 SageMaker Studio에서 커스터마이즈하거나 배포할 수 있다. - 지원 모델에는 다음 작업 흐름이 제공된다. - SageMaker에서 모델 커스터마이즈 - SageMaker 또는 Bedrock 엔드포인트 배포 - 모델 평가 - 사용자 정의 보상 함수를 활용한 강화학습 파인튜닝 - 신규 고객은 사전 구성된 권한과 환경을 갖춘 Studio를 빠르게 생성할 수 있다. - 검증된 고객은 별도 쿼터 증액 요청 없이 G5, G6, G4dn GPU 인스턴스에 기본 접근할 수 있다. - Studio 내부에서 GPU 쿼터 사용량도 확인할 수 있다. ## GPU 관리 비용 인하 - 2026년 7월 1일부터 EKS Auto Mode와 ECS Managed Instances의 가속 인스턴스 관리 비용이 자동으로 인하된다. - 인하 폭: - G 계열: 35% - P 계열 및 AWS Trainium: 60% - 기존 클러스터에도 자동 적용되며 별도 작업이 필요 없다. - EKS Auto Mode: - GPU 인스턴스의 병렬 이미지 풀링 - 로컬 NVMe 기반 가속 워크로드 지원 - 가속기 상태를 인식한 노드 복구 - ECS Managed Instances: - CloudWatch Container Insights 기반 GPU 메트릭 - GPU 하드웨어 장애 자동 모니터링 ## Aurora DSQL의 변경 데이터 캡처 - Aurora DSQL CDC가 정식 출시됐다. - INSERT, UPDATE, DELETE 결과를 변경 이벤트로 만들어 Amazon Kinesis Data Streams에 전송한다. - 활용 사례: - 마이크로서비스 간 데이터 동기화 - Lambda 함수 트리거 - Firehose를 통한 S3, Redshift, OpenSearch Service 전달 - 데이터베이스 워크로드 성능에 영향을 주지 않도록 설계됐다. - CDC 인프라를 별도로 구축하거나 운영할 필요가 없다. ## AWS용 Loom과 안전한 AI 에이전트 운영 - Loom은 AWS Strands Agents와 Amazon Bedrock AgentCore Runtime 기반 에이전트를 구축·배포하는 오픈소스 엔터프라이즈 플랫폼이다. - 제공 기능: - 통합 관리 UI와 백엔드 API - ID 공급자 연동 - 범위 기반 권한 제어 - 멀티 페르소나 탐색 - 에이전트, 메모리, MCP 서버, 에이전트 간 연동의 전체 수명주기 관리 - 멀티테넌트 환경을 위해 RBAC와 ABAC를 지원한다. - 리소스 태깅을 자동화해 비용을 사용자·팀별로 추적할 수 있다. - 표준화된 배포 블루프린트, AWS Agent Registry 연동, 민감한 작업 전 사람의 검토 절차도 제공한다. - AWS Labs GitHub에서 프로젝트를 확인할 수 있다. ## Claude 애플리케이션 접근 제어 - Claude Code와 Claude Desktop에 대한 접근, 비용, 정책을 중앙에서 관리하는 자체 호스팅 게이트웨이가 소개됐다. - OIDC 호환 ID 공급자와 연동하며, 모든 요청에 관리형 설정을 적용한다. - Amazon Bedrock 또는 AWS 기반 Claude Platform으로 추론 요청을 라우팅할 수 있다. - 사용자·그룹별 지출 한도를 설정할 수 있다. - 프라이빗 네트워크의 무상태 컨테이너로 실행되며, PostgreSQL은 단기 로그인 상태만 저장한다. - 개발자 장비에 장기 보안 키를 저장하지 않는 방식으로 보안을 강화한다. ## AWS MCP Server의 OAuth 지원 - AWS Console이나 CLI와 동일한 자격 증명을 사용해 브라우저 기반 OAuth로 AWS MCP Server에 연결할 수 있다. - IAM Federation, AWS IAM Identity Center, 루트 사용자 및 IAM 사용자를 지원한다. - AWS Sign-In이 단기 액세스·리프레시 토큰을 발급하고 토큰 갱신을 자동 처리한다. - 개발자는 재시작 후에도 반복 로그인 없이 에이전트를 인증 상태로 유지할 수 있다. AWS를 학습하거나 실험하려는 경우 Builder Center의 샌드박스와 워크숍을 활용하면 비용과 정리 부담을 줄일 수 있다. 운영 환경에서는 Security Hub의 실제 인터넷 도달성 검사와 Azure 통합을 우선 검토하고, AI 에이전트 도입 시에는 Loom·OAuth·중앙 정책 관리 기능을 통해 권한, 비용, 감사 체계를 함께 설계하는 것이 바람직하다.

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

수익화 게이트웨이 출시: x402를 통해 Cloudflare 뒤의 모든 리소스에 요금 부과

Cloudflare는 웹 페이지·데이터셋·API·MCP 도구 등 Cloudflare 뒤의 모든 리소스에 사용량 기반 요금을 부과할 수 있는 Monetization Gateway를 발표했다. 이 게이트웨이는 결제 규칙, 결제 검증, 접근 제어를 엣지에서 처리하며, 출시 시 x402와 스테이블코인을 사용한다. 이를 통해 에이전트가 계정이나 구독 없이 요청 단위로 소액 결제하고, 서비스 제공자는 별도의 결제·정산 시스템 없이 리소스를 수익화할 수 있다. ## 에이전트 중심으로 바뀌는 웹의 수익 모델 - 기존 웹은 콘텐츠를 인간의 관심과 교환하고, 광고·구독·전자상거래로 수익을 창출했다. - AI 에이전트는 광고를 보거나 장기 구독을 유지하기보다, 필요한 페이지·데이터·도구를 한 번 사용하고 이동한다. - AI 크롤러는 방문자를 보내는 횟수보다 훨씬 많은 요청을 발생시킬 수 있어, 기존 광고 모델과 맞지 않는다. - 에이전트 경제에서는 다음과 같은 사용량 기반 과금이 적합하다. - 검색 1회당 수 센트 - 업로드 기본 요금 0.001달러와 MB당 0.01달러 - 성공적으로 해결된 지원 요청 1건당 0.99달러 - 소프트웨어의 자연스러운 과금 단위는 사용자 좌석이나 월 구독이 아니라 요청, 토큰, 작업 결과가 된다. ## 기존 사용량 과금의 한계 - 클라우드와 API는 호출량·사용 시간 기준으로 판매되어 왔지만, 일반적으로 사전에 등록한 고객과 API 키가 필요했다. - 콘텐츠 서비스는 주로 광고에 의존했기 때문에, 신원 확인이 되지 않은 구매자의 초소액 결제를 처리하기 어려웠다. - 결제 수수료와 정산 지연 때문에 결제 금액이 너무 작으면 결제 자체가 더 비싸지는 문제가 있었다. - 사업자는 사용량을 정확하고 감사 가능하게 기록하기 위해 자체 회계·청구 시스템을 구축해야 했다. - 이러한 복잡성 때문에 많은 기업이 구현하기 쉬운 좌석 기반 가격제를 선택했다. ## 스테이블코인과 에이전트 결제 - 에이전트는 한 사람이 처리할 수 없는 수준으로 지속적으로 작업하며, 수천 건의 소액 결제를 자동으로 수행할 수 있다. - 사람이 각 결제를 승인해야 하는 기존 방식은 에이전트 사용 패턴과 맞지 않는다. - Open USD, USDC 같은 스테이블코인은 매우 작은 금액을 낮은 수수료로 전송하고, 1초 이내에 정산할 수 있다. - 따라서 에이전트 환경에서는 소액·고빈도 결제와 사용량 기반 가격제가 적합하다. ## x402의 HTTP 기반 결제 흐름 - x402는 HTTP 상태 코드 `402 Payment Required`를 활용하는 개방형 결제 프로토콜이다. - 기본 흐름은 다음과 같다. - 클라이언트가 결제 보호 리소스를 요청한다. - 서버가 `402` 응답과 함께 가격, 허용 자산, 결제 주소를 전달한다. - 클라이언트가 결제한 뒤 결제 증명을 포함해 요청을 재전송한다. - 퍼실리테이터가 결제를 검증하면 서버가 리소스를 반환한다. - 결제는 별도의 결제 페이지나 API 호출 없이 일반적인 HTTP 요청·응답 안에서 처리된다. - 구매자의 결제 금액은 판매자의 지갑으로 직접 정산되는 P2P 구조다. - 판매자 계정이 없어도 결제 자체가 접근 자격 증명이 되므로, 구매자 온보딩이 필요 없다. - 프로토콜 오버헤드가 작아 1센트 미만의 결제도 가능하며, 스테이블코인과 결합하면 낮은 수수료와 빠른 정산을 기대할 수 있다. ## Monetization Gateway의 역할 - Cloudflare는 결제 정책과 접근 제어를 하나의 컨트롤 플레인에서 관리하도록 지원한다. - 서비스 제공자는 어떤 요청에 결제를 요구할지 Cloudflare 규칙 표현식으로 정의할 수 있다. - 토큰, API, MCP 호출, 데이터 등 기존 Cloudflare 경로를 통과하는 트래픽에 대해 선택적으로 과금할 수 있다. - 결제 검증과 집행은 원본 서버가 아니라 Cloudflare 엣지에서 처리된다. - Cloudflare의 330개 이상 도시에 분산된 네트워크에서 x402 핸드셰이크가 수행되므로 구매자와 가까운 위치에서 처리할 수 있고, 원본 서버의 부하와 지연도 줄일 수 있다. - 계획된 기능에는 다음이 포함된다. - 특정 REST 경로와 HTTP 메서드별 과금 - 예를 들어 `/api/premium/*`의 GET·POST 요청마다 0.01달러 부과 - 작업의 특성에 따른 변동 가격 설정 ## 서비스 제공자에게 주는 이점 - 제공자가 직접 구매자를 등록하거나 API 키·청구 시스템을 운영할 필요가 없다. - 사용량 측정, 결제 교환, 정산이 원본 서버에서 분리된다. - 제공자는 가격, 결제 조건, 접근 규칙, 수익에 집중할 수 있다. - Cloudflare는 기존에 자체 청구 및 고객 분석을 위해 구축한 사용량 회계 역량을 웹 리소스에 적용하려 한다. 실용적으로는 API·데이터·MCP 도구처럼 요청 단위 가치가 분명한 리소스부터 x402 기반 과금을 적용하는 방식이 적합하다. 다만 실제 도입 시에는 스테이블코인 지원 범위, 환불·분쟁 처리, 가격 변동성, 규제 및 회계 처리를 별도로 검토해야 한다.

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

프롬프팅에서 워크플로로, AI로 프런트엔드 개발 생산성 끌어올리기

코딩 속도보다 더 큰 병목은 Jira, Figma, Confluence, Slack, Git 등에 흩어진 정보를 모으고 조정하는 비용입니다. 글은 LLM을 단발성 프롬프트 도구가 아니라 반복 가능한 개발 워크플로의 실행 엔진으로 활용해야 한다고 주장합니다. 이를 통해 구현 전 요구 사항을 통합하고, 불확실성을 드러내며, 구현 후 검증까지 자동화하는 오케스트레이션 중심의 프런트엔드 개발이 가능해집니다. ## 프런트엔드 개발의 병목 변화 - 하나의 기능을 구현하려면 여러 시스템을 오가야 합니다. - 요구 사항: Jira - 디자인: Figma - 기술·정책 문서: Confluence - 의사결정과 논의: Slack - 구현과 검증: Git - 프런트엔드 개발자는 이 정보를 통합해 실제 사용 가능한 결과물로 조립하는 역할을 담당합니다. - 주요 부담은 코드를 작성하는 일보다 다음과 같은 컨텍스트 작업에 있습니다. - 티켓과 디자인 분석 - 에지 케이스 확인 - 제품·백엔드 팀과의 동기화 - 기존 코드와 재사용 가능한 구성 요소 탐색 ## 프롬프트에서 반복 가능한 워크플로로 - 단발성 프롬프트는 한 번의 작업에는 유용하지만, 반복성과 누적 효과가 부족합니다. - 워크플로는 입력부터 출력까지의 표준화된 경로입니다. - 여러 시스템에서 관련 컨텍스트 수집 - 요구 사항 요약 - 모호하거나 충돌하는 내용 식별 - 구현 계획과 파일 목록 제안 - 사람이 검토한 뒤 코드 수정 진행 - 이 구조에서 LLM은 단순히 코드를 생성하는 도구가 아니라 워크플로를 실행하는 엔진입니다. - 한 번 구축한 워크플로는 티켓의 내용이 달라져도 동일한 패턴으로 적용할 수 있어 확장성이 높습니다. ## 연결된 개발 컨텍스트와 Noah MCP - LY Corporation의 Noah MCP는 Jira, Confluence, Slack, GitHub 같은 내부 도구를 연결합니다. - AI 에이전트가 사람이 복사해 붙여넣은 정보가 아니라 실제 업무 시스템에 존재하는 컨텍스트를 직접 읽고 추론할 수 있게 합니다. - 이를 통해 개발자는 각 시스템을 수동으로 방문하고 정보를 노트에 조합하는 작업을 줄일 수 있습니다. - 핵심은 AI를 별도의 도구로 사용하는 것이 아니라 기존 업무 흐름 안에 배치하는 것입니다. ## 구현 전 요구 사항 통합 예시 기능은 검색·필터·정렬과 역할 기반 필터 표시가 있는 목록 페이지입니다. 기존 방식에서는 개발자가 Jira, Figma, Confluence, Slack, 코드베이스를 직접 확인한 뒤 계획을 작성합니다. 워크플로 기반 방식에서는 에이전트에게 다음을 요청합니다. - Jira 티켓 분석 - 관련 Confluence 문서 검색 - Slack의 최근 의사결정 확인 - 유사한 코드 구현 탐색 - 코드 수정 없이 다음 결과 반환 - 요구 사항 요약 - 프런트엔드 영향 범위 - 관련 파일 - 구현 체크리스트 - 테스트 체크리스트 - 미해결 질문 에이전트가 도출한 계획에는 다음과 같은 구체적인 정보가 포함됩니다. - `FeatureListPage.tsx`, `FeatureList.tsx` 등 신규 파일 - 기존 `useTableFilters`, `useUrlState` 훅의 재사용 - `GET /api/<feature>`의 기존 페이지네이션 API 활용 - 역할별 필터 표시 - viewer: 검색, 상태 필터, 날짜 범위 - editor: owner 필터 추가 - admin: 내부 전용 플래그 추가 - 필터·정렬·페이지 상태를 URL 파라미터와 동기화 - 로딩, 빈 결과, 검색 결과 없음 상태 구현 ## 숨겨진 요구 사항과 재작업 방지 - Slack 논의에서 필터 상태를 `localStorage`가 아니라 URL에 저장해야 한다는 결정이 발견됩니다. - URL 공유가 가능해지고 - 새로고침 후에도 상태가 유지되며 - 다른 사용자가 동일한 화면을 재현할 수 있습니다. - 코드베이스 검색을 통해 이미 존재하는 훅을 재사용할 수 있습니다. - 불필요한 중복 구현 방지 - 기존 동작과의 일관성 유지 - 개발 시간 단축 - 구현 전에 다음과 같은 미해결 사항도 드러납니다. - 필터·정렬 상태를 URL에 저장할지 여부 - 빈 상태에서 “필터 초기화” 버튼을 제공할지 여부 - 이런 문제를 PR 리뷰 단계가 아니라 구현 전에 발견하면 재작업 가능성을 줄일 수 있습니다. ## 코딩 이후의 폐쇄 루프 검증 워크플로는 코드 생성에서 끝나지 않고 검증 단계까지 포함해야 합니다. - 구현 후 원래 계획과 실제 변경 사항을 대조합니다. - 자동 검증 항목을 실행합니다. - 타입 검사 - 린트 - 관련 단위 테스트 - 스모크 테스트 또는 로컬 검증 흐름 - 에이전트는 다음 결과를 보고합니다. - 통과한 검사 - 실패 후 수정한 문제 - 자동화하지 못한 검증 - UI 상태별 스크린샷이나 확인 메모 - PR 전 남은 위험 요소 - 이 폐쇄 루프를 통해 계획, 구현, 검증이 하나의 연속된 개발 사이클이 됩니다. ## 실용적인 적용 방향 프런트엔드 팀은 먼저 Jira·문서·메신저·코드 검색을 묶은 “구현 전 분석 워크플로”부터 도입하는 것이 좋습니다. 이후 구현 계획 승인, 코드 수정, 자동 테스트, PR 전 검증을 단계적으로 연결하면 단순한 코드 생성보다 재작업 감소와 품질 향상이라는 더 큰 효과를 얻을 수 있습니다.

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

모델과 작업별 GitHub Copilot 에이전틱 하니스의 성능 및 효율성 평가

GitHub은 모델 자체의 지능뿐 아니라 도구·컨텍스트·작업 흐름을 조율하는 에이전틱 하니스(harness)가 실제 성능을 좌우한다고 주장합니다. 동일한 모델과 작업을 기준으로 비교한 결과, GitHub Copilot 하니스는 모델 제공업체의 하니스와 비슷한 작업 해결률을 유지하면서 대부분 더 적은 토큰을 사용하는 것으로 나타났습니다. 따라서 하나의 하니스를 개선하면 Copilot CLI, 앱, 코드 리뷰, IDE 등 여러 제품 경험이 함께 향상된다는 결론입니다. ## 에이전틱 하니스의 역할 - 모델은 기본적인 추론 능력을 제공하지만, 하니스가 그 능력을 실제 작업에 적용하는 방식을 결정합니다. - 하니스는 다음 요소를 조율합니다. - 사용할 도구 - 모델에 제공할 컨텍스트 - 작업 실행 순서와 워크플로 - 메모리 및 MCP 서버 활용 - GitHub Copilot의 하니스는 Copilot SDK의 공통 구성 요소입니다. - Copilot CLI, Copilot 앱, Copilot 코드 리뷰, VS Code·Xcode 등 다양한 GitHub 및 Microsoft 경험에서 공유됩니다. - GitHub은 좋은 하니스의 조건으로 빠른 속도, 낮은 토큰 사용량, 예측 가능성을 제시합니다. ## 벤치마크 비교 방법 - 공개 벤치마크와 GitHub·Microsoft 대규모 코드베이스에서 도출한 내부 벤치마크를 함께 사용합니다. - 통제된 실험 결과를 실제 사용 지표와 온라인 실험으로 보완합니다. - 비교 시 다음 조건을 동일하게 맞췄습니다. - 같은 모델 - 같은 벤치마크 작업 - 동일하게 정규화한 컨텍스트 윈도우 - 동일한 추론 수준 - 동일한 도구 선택 및 MCP 서버 - 비교 대상은 다음과 같습니다. - GitHub Copilot CLI - Claude 모델의 기본 하니스인 Claude Code - GPT 모델의 기본 하니스인 Codex CLI - 평가 모델은 Claude Sonnet 4.6, Claude Opus 4.7, GPT-5.4, GPT-5.5입니다. ## 사용한 벤치마크 - **SWE-bench Verified** - 오픈소스 Python 저장소의 사람이 검증한 버그 수정 500개 - 코딩 에이전트의 대표적인 산업 표준 벤치마크 - **SWE-bench Pro** - 여러 단계의 추론과 광범위한 코드 변경이 필요한 어려운 작업 - 실제 소프트웨어 엔지니어링에 가까운 복잡한 문제를 평가 - **SkillsBench** - 에이전트가 스킬을 얼마나 효과적으로 사용하고 호출하는지 평가 - **TerminalBench** - 개발자가 사용하는 명령줄·터미널 기반 작업 수행 능력 측정 - **Win-Hill** - Windows 컨테이너에서 실행되는 내부 벤치마크 - 운영체제와 실행 환경이 달라져도 성능이 유지되는지 검증 ## 토큰 효율 - 동일한 모델과 작업을 사용했을 때 Copilot 하니스는 대부분의 설정에서 더 적은 토큰을 소비했습니다. - 토큰 사용량이 줄었음에도 전반적인 작업 완료율은 다른 모델 제공업체 하니스와 비슷한 수준이었습니다. - Claude Sonnet 4.6과 Opus 4.7에서는 Copilot CLI가 비교된 모든 사례에서 더 나은 결과를 보였습니다. - GPT-5.4와 GPT-5.5에서도 대부분 Copilot CLI가 우세했지만, SWE-bench Verified에서는 각각 7%, 4% 낮은 성능을 기록했습니다. - 단순히 비용을 줄이는 것이 아니라, 작업 해결 능력을 유지하면서 토큰 소비를 낮추는 것이 핵심입니다. ## 작업 해결률 - 전체적으로 Copilot 하니스의 작업 해결률은 모델 제공업체 하니스와 대등했습니다. - SWE-bench Verified에서는: - Sonnet 4.6과 Opus 4.7에서 Copilot CLI가 더 높은 해결률을 보였습니다. - GPT-5.4와 GPT-5.5에서는 더 낮았습니다. - SWE-bench Pro에서는: - Sonnet 4.6에서만 Copilot CLI가 소폭 낮았습니다. - 나머지 모델에서는 더 나은 성능을 보였습니다. - SkillsBench에서는 Claude 모델에서 낮았지만 GPT 모델에서는 더 높았습니다. - Win-Hill에서는 모든 모델에서 같거나 더 나은 결과를 기록했습니다. - TerminalBench 2에서는: - Sonnet 4.6과 Opus 4.7에서 더 높았습니다. - GPT-5.5에서는 동률이었습니다. - GPT-5.4에서는 더 낮았습니다. - 저자들은 모델의 확률적 특성으로 인한 실행별 변동을 고려하면 이러한 차이는 실질적으로 “동등한 수준”이라고 해석합니다. ## 실행별 변동성과 비용 분석 - TerminalBench 2.0을 사용해 작업 해결률뿐 아니라 작업당 비용과 실행별 변동도 분석했습니다. - 벤치마크 결과는 한 번의 실행만으로 하니스 성능을 판단하기 어렵다는 점을 보여줍니다. - 같은 에이전트와 모델 조합도 실행마다 결과가 달라질 수 있습니다. - 평가에서는 더 많은 작업을 해결하면서 비용을 적게 쓰는 구성이 더 좋은 것으로 간주합니다. - Copilot CLI는 이러한 분석에서 모델 제공업체 하니스와 비교해 같거나 더 나은 해결률·토큰 효율을 보였습니다. ## 실용적인 의미 - 모델을 선택할 때 모델의 벤치마크 점수만 보지 말고 하니스의 도구 사용, 컨텍스트 관리, 토큰 효율도 함께 평가해야 합니다. - 여러 모델을 한 제품에서 사용해야 한다면, 특정 모델에 종속되지 않으면서 성능을 유지하는 공통 하니스가 유리합니다. - 실제 도입 전에는 SWE-bench 같은 표준 평가뿐 아니라 조직의 코드베이스와 터미널 작업을 반영한 내부 벤치마크를 반복 실행하는 것이 좋습니다. - 단일 실행 결과보다 해결률, 비용, 토큰 사용량, 실행 간 변동을 함께 비교해야 신뢰할 수 있는 판단을 내릴 수 있습니다.

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

Google Antigravity 에이전트, GitLab Orbit로 전체 컨텍스트 확보

Google Antigravity에 GitLab Orbit를 연결하면 코딩 에이전트가 단순히 파일과 터미널만 보는 것을 넘어 GitLab의 프로젝트, 의존성, 파이프라인, 머지 리퀘스트, 취약점, 코드 소유권까지 함께 이해할 수 있다. Orbit는 GitLab 데이터를 지식 그래프로 구성하고 MCP를 통해 에이전트에 제공하며, 이를 통해 변경 영향 분석과 코드베이스 탐색 같은 작업의 정확도와 속도를 높인다. 글에 따르면 초기 내부 테스트에서 응답 속도는 최대 11배 빨라지고, 토큰 사용량은 최대 4.5배, 환각은 최대 45배 줄었다. ## GitLab Orbit가 제공하는 컨텍스트 그래프 - GitLab 인스턴스의 다음 요소를 노드와 관계로 색인한다. - 그룹과 프로젝트 - 사용자와 코드 소유자 - 이슈 및 작업 항목 - 머지 리퀘스트 - 파이프라인 - 취약점 - 소스 코드와 프로젝트 간 의존성 - 지식 그래프는 코드 변경과 GitLab 활동을 연결해 에이전트가 시스템 전체의 맥락을 파악하도록 한다. - MCP 도구 두 가지를 제공한다. - `query_graph`: GitLab Orbit의 JSON DSL로 그래프를 질의 - `get_graph_schema`: 사용 가능한 노드 유형, 속성, 관계 확인 - 코드 변경 후 몇 분 내에 그래프를 다시 색인하므로 오래된 위키보다 최신 상태를 반영한다. ## Antigravity 에이전트의 활용 범위 확대 Orbit가 없으면 Antigravity 에이전트는 주로 현재 열려 있는 파일과 터미널에 의존한다. Orbit를 연결하면 다음과 같은 질문에 답할 수 있다. - 특정 모듈에 의존하는 프로젝트와 서비스는 무엇인가? - 해당 프로젝트에 해결되지 않은 취약점이 있는가? - 과거 리뷰 이력과 파일 소유권을 기준으로 적절한 리뷰어는 누구인가? - 특정 그룹에서 파이프라인 실패가 가장 많은 프로젝트는 무엇인가? 에이전트는 브라우저를 오가거나 사용자가 정보를 복사해 주지 않아도 구조화된 그래프 결과를 받아 답변을 생성한다. ## 변경 영향도와 충돌 분석 공유 인증 라이브러리처럼 여러 서비스가 사용하는 코드를 리팩터링할 때 Orbit가 특히 유용하다. - 해당 모듈을 import하는 모든 프로젝트를 조회한다. - 관련 파일을 수정 중인 열린 머지 리퀘스트를 확인한다. - 각 변경 사항의 담당자와 소유자를 찾아낸다. - 리팩터링이 기존 작업과 충돌할 가능성과 사전에 협의해야 할 사람을 한 번에 파악할 수 있다. 기존 에이전트가 파일 자체만 분석하는 것과 달리, 코드 의존성과 진행 중인 협업 작업까지 함께 고려한다는 점이 핵심이다. ## 온보딩과 코드베이스 탐색 익숙하지 않은 서비스에 복귀하거나 새로 합류한 개발자는 에이전트에게 다음 정보를 요청할 수 있다. - 서비스가 의존하는 프로젝트와 모듈 - 주요 진입점 파일 - 최근 일주일 동안 해당 서비스에 열린 머지 리퀘스트 에이전트는 조회 결과를 일회성 채팅 답변이 아니라 다시 볼 수 있는 **Walkthrough Artifact** 형태의 탐색 자료로 만들 수 있다. 그래프가 변경 후 빠르게 갱신되기 때문에 낡은 문서에 의존하지 않고 현재 코드베이스를 기준으로 학습할 수 있다. ## 실시간 의존성 다이어그램 생성 - 기술 리드는 그룹의 서비스 의존성 그래프를 조회한 뒤 Nano Banana Pro를 사용해 아키텍처 다이어그램으로 렌더링할 수 있다. - 특정 보안 취약점이 열려 있는 서비스만 필터링하는 등 범위를 좁혀 새 다이어그램을 만들 수 있다. - 다이어그램의 노드와 연결선은 최신 GitLab 그래프에서 생성된다. - 사용자의 GitLab 권한에 따라 결과가 필터링되므로 접근 권한이 없는 정보가 포함되지 않는다. - GitLab도 Software Architecture Map을 개발 중이지만, 글에서는 Antigravity 환경에서 이 기능을 즉시 사용할 수 있다고 설명한다. ## 설치와 사용 조건 - Antigravity 설정의 **Customization → MCP** 섹션에서 MCP Store를 연다. - **Add MCP**를 선택하고 GitLab Orbit를 추가한다. - 화면 안내에 따라 GitLab 인증을 완료하면 별도 설정 파일이나 터미널 작업 없이 에이전트가 Orbit 도구를 사용할 수 있다. - Orbit는 GitLab Duo Agent Platform과 동일한 컨텍스트 엔진을 사용한다. - 지원 언어는 Ruby, Java, Kotlin, Python, TypeScript, JavaScript, Rust, C#이며 기본 브랜치의 코드를 색인한다. - MCP 질의에는 GitLab Credits가 사용되지만 `get_graph_schema` 호출은 무료다. - GitLab.com의 Premium 및 Ultimate 요금제에서 사용할 수 있으며, 먼저 최상위 그룹에서 Orbit를 활성화해야 한다. ## 실용적인 결론 대규모 GitLab 환경에서 의존성 분석, 보안 점검, 리뷰어 선정, 온보딩을 자주 수행한다면 Orbit를 연결할 가치가 크다. 다만 성능 개선 수치는 초기 내부 테스트 결과이므로 실제 효과는 저장소 규모, 그래프 품질, 질의 설계에 따라 검증하고 GitLab Credits 사용량과 권한 설정도 함께 관리하는 것이 좋다.

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

Config 2026: 새로운 소재, 새로운 도구, 더욱 표현력 있는 캔버스 | Figma 블로그

Figma Config 2026의 핵심 방향은 캔버스를 단순한 디자인 작업 공간이 아니라 코드·모션·셰이더·생성형 플러그인 등을 함께 다루는 창작 환경으로 확장하는 것이다. Figma는 AI가 작업의 진입장벽은 낮췄지만 창작의 한계를 넓히는 것은 결국 디자이너와 크리에이터의 몫이라고 강조한다. 이를 위해 디자인과 코드의 경계를 없애고, 더 풍부한 표현과 협업을 캔버스 안에서 가능하게 하려 한다. ## 디자인 캔버스의 확장 - Figma는 이미지, 벡터, 디자인 레이어뿐 아니라 코드와 모션도 디자인 재료로 취급하려 한다. - 코드·모션·셰이더·생성형 플러그인·Weave 도구를 하나의 캔버스에서 조합하는 것이 이번 Config의 주요 방향이다. - 캔버스는 결과물이 저장되는 장소를 넘어, 아이디어를 연결하고 동료와 함께 반복적으로 발전시키는 협업 공간으로 정의된다. - AI가 창작의 진입장벽을 낮췄다면, 더 높은 수준의 창의성과 과감한 시도는 사용자가 만들어야 한다는 관점을 제시한다. ## 코드 레이어로 디자인과 개발 통합 - 기존의 “디자인 대 코드”라는 구분은 인위적인 논쟁이며, 코드는 이미지나 벡터와 같은 디자인 재료라는 것이 Figma의 주장이다. - Figma Design의 모든 디자인 레이어를 클릭 한 번 또는 프롬프트로 인터랙티브한 코드 레이어로 변환할 수 있다. - 코드 레이어를 복제해 여러 구현 방향을 나란히 비교하고 탐색할 수 있다. - 일반적인 Figma 캔버스처럼 팀원이 같은 파일에서 코드를 수정하고, 의견을 남기고, 반복 작업을 진행할 수 있다. - 코드로 만든 결과물을 다시 편집 가능한 디자인 레이어로 추출할 수 있다. - 디자인 레이어를 수정한 뒤에는 한 번의 클릭으로 변경 사항을 코드 레이어에 반영할 수 있어 디자인과 구현 사이를 양방향으로 오갈 수 있다. - 코드 레이어의 얼리 액세스는 7월부터 시작될 예정이며, 베타 대기자 등록을 통해 참여할 수 있다. ## Figma Motion으로 디자인에 움직임 추가 - Figma Design 안에 타임라인 기반의 모션 제작 기능이 추가된다. - 키프레임과 프리셋을 사용해 처음부터 애니메이션을 만들거나, 기존 디자인에 모션을 덧입힐 수 있다. - Figma agent를 이용해 애니메이션의 초기 시안을 생성할 수도 있다. - 모션 디자이너에게는 반복적인 작업을 줄이고, 창의적인 표현에 더 집중할 수 있는 환경을 제공한다. - 애니메이션을 컴포넌트에 한 번 정의하면 여러 화면과 협업자의 파일에서 디자인 시스템의 일부처럼 재사용할 수 있다. ## 모션과 개발 도구의 연결 - Dev Mode에서는 전체 타임라인을 확인하고 검사할 수 있다. - 각 키프레임, 타이밍 값, 이징 곡선을 별도의 해석 없이 읽을 수 있다. - 애니메이션 코드를 CSS, JSON 또는 React 프레임워크용 코드로 직접 복사할 수 있다. - MCP와 호환되므로 애니메이션이 적용된 프레임을 코딩 에이전트로 전달해 구현할 수 있다. - 결과물은 MP4, WebM, Animated SVG, GIF 등으로 내보낼 수 있으며, 향후 더 많은 포맷이 추가될 예정이다. Figma Config 2026은 디자인·개발·모션을 별도 도구로 분리하기보다 하나의 협업 캔버스에서 연결하려는 흐름을 보여준다. 특히 코드 레이어와 Figma Motion은 디자이너가 구현 가능성을 즉시 실험하고, 개발자는 디자인 의도와 애니메이션 세부 정보를 정확히 확인하도록 돕는 기능으로 볼 수 있다.

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

내부 데이터 분석 에이전트를 구축한 방법

GitHub는 사내 데이터 웨어하우스에 자연어로 질문하면 SQL을 작성하고 결과를 해석해 주는 GitHub Copilot 기반 분석 에이전트 ‘Qubot’을 구축했다. Qubot은 대시보드나 정기 리포트의 대체재가 아니라, 데이터 모델·필터·쿼리 작성법을 몰라도 탐색적 분석을 수행하도록 돕는 도구다. 핵심 성공 요인은 데이터에 대한 구조화된 컨텍스트와 자동화된 평가 체계이며, 이를 통해 분석 정확도뿐 아니라 응답 속도도 크게 향상됐다. ## Qubot의 목적과 활용 범위 - GitHub의 여러 제품·엔지니어링 팀이 데이터 분석가의 도움 없이 제품 텔레메트리를 활용하도록 지원한다. - 사용자는 다음과 같은 탐색적 질문을 자연어로 입력할 수 있다. - 특정 기능의 유지율이 가장 높은 사용자 코호트는 무엇인가? - 지난주 특정 지표의 변화에 가장 큰 영향을 준 제품은 무엇인가? - 정기 보고서나 대시보드를 대체하지 않고, 데이터셋을 빠르게 이해하고 가설을 검증하는 데 초점을 둔다. - 데이터 분석 지원 요청을 줄이고, 데이터 웨어하우스를 사용해 본 적이 적은 직원도 의사결정에 필요한 데이터를 직접 탐색할 수 있게 한다. ## 세 가지 핵심 구성 요소 Qubot은 사용자 인터페이스, 컨텍스트 계층, 쿼리 엔진으로 구성된다. - **사용자 인터페이스** - Slack, VS Code, Copilot CLI에서 사용할 수 있다. - Slack에서는 채널에 질문을 올리면 GitHub.com에서 Copilot Cloud Agent가 실행된다. - 답변은 Slack에 바로 게시되며, 스레드에서 질문을 추가로 구체화할 수 있다. - 분석 결과는 Markdown 보고서로 작성되어 Pull Request에 저장된다. - VS Code와 Copilot CLI에서는 플러그인 설치 후 다른 에이전트·스킬·도구와 함께 사용할 수 있다. - **컨텍스트 계층** - 데이터의 관리 수준에 따라 서로 다른 정보를 제공한다. - Bronze 데이터에는 제품 팀이 제공한 이벤트 스키마와 메타데이터가 포함된다. - Silver 데이터에는 예시 쿼리, 사용 지침, 필수 필터 등이 포함된다. - Gold 데이터에는 해당 데이터셋을 소유한 팀이 정의한 비즈니스 규칙과 지표 정의가 포함된다. - ETL 파이프라인이 추가 신호와 파생 메타데이터를 자동으로 보강한다. - 에이전트는 실행 시점에 GitHub MCP Server를 통해 필요한 컨텍스트를 가져온다. - **쿼리 엔진** - GitHub의 주요 분석 엔진인 Kusto와 Trino를 MCP 서버로 연결한다. - Kusto는 최근 이벤트 데이터를 빠르게 탐색하는 데 적합하다. - Trino는 복잡한 조인과 장기간의 이력 분석에 적합하다. - 사용자가 엔진을 직접 선택하지 않아도 Qubot이 기본적으로 Kusto를 사용하고, 복잡한 질문에는 Trino로 자동 전환한다. ## 컨텍스트 에이전트와 지식 관리 - 컨텍스트 정보는 여러 저장소에 Markdown 형태로 관리된다. - 팀은 표준 템플릿을 사용하거나 관련 컨텍스트가 있는 저장소를 참조해 지식을 기여할 수 있다. - 컨텍스트 에이전트가 정보를 수집한 뒤 정리·정규화해 Qubot이 활용하기 쉬운 구조로 변환한다. - 데이터 모델 자체보다 데이터의 의미, 올바른 필터, 지표 정의, 사용 사례를 함께 제공하는 것이 에이전트의 분석 품질을 높이는 핵심이다. ## 자동화된 평가 프레임워크 - 컨텍스트나 에이전트 설정이 변경될 때마다 배포 전에 오프라인 평가를 수행한다. - 평가 대상은 정확도뿐 아니라 적절한 답을 찾는 데 걸리는 시간과 기존 기능의 회귀 여부다. - 평가 프레임워크는 다음 세 부분으로 구성된다. - **테스트 케이스**: 정답, 기준 SQL, 도메인, 난이도를 포함한 표준 질문 집합 - **실행 오케스트레이션**: GitHub CLI의 `gh agent-task create`를 이용해 테스트를 병렬 실행하고 JSON 결과를 저장 - **통계 집계**: 테스트별 완료율, 정확도, 평균·최소·최대 소요 시간을 계산 - 전체 과정은 테스트 정의 → 여러 차례 실행 → 결과 수집 → 통계 집계 → 설정 비교 순서로 진행된다. - 이를 통해 컨텍스트 추가나 에이전트 변경이 실제 품질 향상으로 이어지는지 검증할 수 있다. ## 도입 효과와 핵심 교훈 - Qubot은 수백 명의 사용자가 수천 건의 쿼리를 실행할 정도로 확산됐다. - 데이터·분석 Slack 채널에 반복적으로 들어오던 질문이 크게 줄었다. - 사용자는 간단한 질문을 직접 해결하고, 분석 전문가는 더 복잡한 문제에 집중할 수 있게 됐다. - Slack, VS Code, Copilot CLI를 함께 제공해 기술 수준과 업무 방식에 따른 진입 장벽을 낮췄다. - 실험 결과, 잘 구조화되고 큐레이션된 컨텍스트는 Qubot의 정확도를 높였을 뿐 아니라 올바른 답을 반환하는 속도도 약 3배 향상시켰다. - 따라서 데이터 문서, 지표 정의, 사용 규칙 같은 컨텍스트 자산을 단순한 문서가 아니라 분석 시스템의 핵심 구성 요소로 관리해야 한다. 실무적으로는 처음부터 모든 데이터를 자동 분석하려 하기보다, 자주 묻는 도메인부터 표준화된 컨텍스트와 기준 테스트를 구축하는 접근이 적합하다. 또한 여러 쿼리 엔진을 사용한다면 사용자가 엔진을 선택하지 않아도 되도록 에이전트가 질문 특성에 따라 자동 라우팅하도록 설계하는 것이 좋다.

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

전문성 밖으로 나아가기

Technical Writer(TW)는 문서를 작성·관리하는 역할을 넘어, 지식이 축적되고 활용되는 제품과 시스템을 만드는 제품 오너로 확장되고 있다. 토스의 문서 플랫폼 ‘토독’은 누구나 쉽게 문서를 작성하고, 조직의 지식을 한곳에 모으며, AI가 활용할 수 있도록 하는 것을 목표로 한다. 궁극적으로는 문서화가 별도 업무가 아니라 실제 업무 과정에서 자동으로 발생하고, 지식의 최신성과 품질까지 시스템이 관리하는 구조를 지향한다. ## TW가 제품을 만드는 이유 - TW는 어떤 문서가 읽기 어려운지, 좋은 문서의 조건이 무엇인지, AI가 잘 활용할 수 있는 문서 구조가 무엇인지 깊이 고민해 온 직무다. - 이러한 전문성을 문서 작성에만 적용하지 않고, 문서와 지식 관리 제품의 설계 원칙으로 확장한다. - 제품 오너로서 사용자 인터뷰, 제품 방향 설정, 로드맵·우선순위 결정, 기능 기획과 구현까지 직접 수행한다. - 문서 요구사항을 개발팀에 전달하는 역할이 아니라, 제품의 문제를 정의하고 해결책을 만드는 메이커로 일한다. ## 기존 내부 문서의 문제점 - **높은 작성 장벽** - 정적 사이트 생성기 기반 문서는 저장소 클론, 마크다운 작성, PR 생성과 리뷰 과정을 거쳐야 했다. - 개발자에게는 익숙하지만 디자이너나 PM에게는 문서 작성 자체를 포기하게 만드는 장벽이 됐다. - **낡고 불필요한 지식의 누적** - 작성자와 작성 이유를 알 수 없는 메모, 변경된 정책을 설명하는 문서, 미완성 초안 등이 쌓였다. - 문서의 양이 많아질수록 실제로 신뢰할 수 있는 지식을 판별하기 어려워졌다. - **지식의 파편화** - 문서가 SSG, 문서 도구, 코드, 메신저 대화, 개인의 기억 등에 흩어져 있었다. - 지식이 한곳에 모이지 않으면 조직 차원의 축적과 재활용이 어려웠다. ## 토독의 핵심 가치 - **누구나 쉽게 문서 작성** - 별도의 개발 과정 없이 문서를 만들고 수정할 수 있다. - GitHub, 기존 문서 도구, 사내 메신저 등 다양한 출발점의 지식을 토독으로 연결할 수 있다. - **AI를 통한 지식 활용** - 토독의 문서를 팀별 봇과 연결할 수 있다. - API, CLI, MCP를 제공해 요청 봇, 제품 스펙 관리 등 다양한 방식으로 활용할 수 있다. - **단일 진실 공급원(SSoT)** - 여러 곳에 흩어진 정보를 모아 완결된 문서로 구성한다. - 어떤 지식이 최신이고 유효한지 한곳에서 확인할 수 있게 한다. - **확장 가능한 플랫폼** - 조직이나 팀마다 별도 도구를 선택하고 인프라를 구축할 필요가 없다. - 하나의 플랫폼 안에서 각 팀이 독립적인 문서 공간을 운영할 수 있으며, 계열사로도 확장할 수 있다. ## 문서 품질을 자동으로 관리하기 - 문서 작성 장벽을 낮추면 문서 수는 늘지만 품질이 떨어질 수 있다. - 기존에는 TW가 직접 문서를 리뷰하고 낡은 문서를 찾아 수정했다. - 토독은 TW가 정의한 ‘좋은 문서’의 기준을 다음 기능으로 전환하고 있다. - AI 교정 기능 - 문서 봇을 통한 초안 작성 - 자동 리뷰와 개선점 제안 - 다만 사용자가 직접 문서를 작성해야 한다는 전제만으로는 충분하지 않다고 판단했다. ## 업무 과정에서 자동으로 생성되는 문서 - 문서화를 별도의 업무로 요구하기보다, 일하는 과정에서 자연스럽게 문서가 생성되도록 한다. - 사내 메신저의 의사결정과 논의, 코드 변경 내역 등을 자동으로 문서화한다. - 코드 변경이나 의사결정 이후의 논의를 모니터링해 문서가 계속 갱신되도록 설계한다. - 단순히 정보를 수집하는 데 그치지 않고 다음을 판단하는 것이 목표다. - 정책과 실제 코드가 일치하는가 - 해당 지식이 실제 업무에서 사용되고 있는가 - 문서가 얼마나 최신 상태인가 - 현재도 유효한 지식인가 ## TW 전문성의 시스템화 - 좋은 문서를 직접 쓰는 능력에서, 좋은 문서가 반복해서 생산되도록 시스템을 설계하는 능력으로 중심이 이동한다. - 문서가 읽히지 않는 이유에 대한 경험은 누구나 쉽게 쓰고 AI도 잘 읽는 문서 기준으로 전환된다. - 좋은 문서에 대한 판단은 AI 교정과 자동 리뷰의 기준이 된다. - 낡은 문서를 식별하고 유효성을 판단하는 역량은 지식 신선도와 신뢰도를 관리하는 시스템으로 구현된다. - TW의 역할은 다음과 같이 정리된다. - 흩어진 지식이 모일 장소를 만든다. - 좋은 문서의 기준을 정의한다. - 사람의 판단을 시스템에 반영한다. - 업무 과정에서 문서가 자연스럽게 만들어지게 한다. - 축적된 지식이 스스로 갱신되도록 한다. ## 지향하는 업무 환경 - 시스템이 오래된 문서를 감지해 담당자에게 알리고 개선안을 제안한다. - 프로젝트 관리 도구를 별도로 갱신하지 않아도 업무 과정의 기록이 자동으로 정리된다. - 릴리즈 공지와 반복적인 문의 답변이 지식으로 남아 신규 구성원의 학습 비용을 줄인다. - 한 번의 업무가 조직 전체에서 재사용 가능한 흔적으로 남아 실행 시간을 단축한다. - TW는 반복적인 문서 관리보다 제품의 방향과 지식 거버넌스 설계에 집중한다. 결국 토독의 목표는 문서를 잘 쓰게 만드는 데서 끝나지 않는다. 조직의 업무 흐름 자체가 신뢰할 수 있는 지식을 만들고 갱신하도록 설계하는 것이 핵심이며, 이는 TW의 전문성을 조직 전체의 시스템으로 확장하는 방식이다.

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

각 토큰에서 더 많은 것을 얻기: Copilot이 컨텍스트 처리와 모델 라우팅을 개선하는 방법

GitHub Copilot은 에이전트형 작업이 길어질수록 단순히 토큰을 줄이는 것이 아니라, 반복되는 컨텍스트와 도구 정의를 효율적으로 재사용하고 작업에 맞는 모델을 선택해야 한다고 설명합니다. 이를 위해 VS Code에서는 프롬프트 캐싱과 지연된 도구 로딩을 개선하고, Auto 기능은 작업 난이도와 실시간 모델 상태를 바탕으로 적절한 모델로 라우팅합니다. 목표는 품질을 유지하면서 불필요한 비용과 지연을 줄이는 것입니다. ## 프롬프트 캐싱과 지연된 도구 로딩 - 긴 Copilot 세션에는 지침, 저장소 컨텍스트, 대화 기록, 도구 목록, 작업 상태 등 반복적으로 전달되는 정보가 많습니다. - **프롬프트 캐싱**은 반복되는 프롬프트 접두부의 모델 상태를 재사용해 매 요청마다 같은 내용을 다시 계산하지 않도록 합니다. - **도구 검색(tool search)**은 모든 도구의 전체 스키마를 처음부터 컨텍스트에 포함하지 않고, 모델이 필요할 때 관련 도구 정의만 불러옵니다. - MCP 도구, 터미널, 파일 조작, 워크스페이스 검색 등 도구가 많아질수록 이 방식의 효과가 커집니다. - 사용 가능한 도구의 범위는 넓게 유지하면서도, 현재 작업과 무관한 도구 정의가 매 턴마다 차지하는 토큰 비용을 줄일 수 있습니다. ## 작업별 모델 자동 선택 - Auto는 “현재 작업에 어떤 모델이 가장 적합한가?”를 자동으로 판단합니다. - 빠른 설명, 특정 파일의 간단한 수정, 여러 파일에 걸친 복잡한 변경은 요구되는 추론 수준이 서로 다르므로 동일한 모델을 사용할 필요가 없습니다. - 평가 결과 모든 작업에서 항상 최고 성능을 내는 단일 모델은 없었습니다. - 효율적인 모델이 더 적은 비용으로 같은 결과를 내는 경우가 많지만, 복잡한 추론이나 디버깅에서는 강력한 모델이 더 유리합니다. - Auto는 필요할 때만 더 강한 모델로 전환하고, 단순한 작업에는 효율적인 모델을 사용해 품질과 비용 사이의 균형을 맞춥니다. ## Auto의 라우팅 기준 Auto는 모델의 현재 상태와 작업의 특성이라는 두 가지 신호를 함께 사용합니다. - **실시간 모델 상태** - 모델의 가용성, 사용률, 응답 속도, 오류율, 비용을 동적으로 추적합니다. - 성능이 좋은 모델이라도 현재 과부하 상태이거나 응답 오류가 많다면 최적의 선택이 아닐 수 있습니다. - 따라서 작업을 처리할 능력뿐 아니라 현재 안정적으로 응답할 수 있는지도 고려합니다. - **HyDRA 기반 작업 인식 라우팅** - HyDRA는 추론 깊이, 코드 복잡도, 디버깅 난이도, 도구 오케스트레이션 필요성 등을 분석합니다. - 먼저 해당 작업의 품질 기준을 충족할 수 있는 모델들을 선별한 뒤, 그중 가장 적합한 모델을 선택합니다. - 게시글의 평가에서는 HyDRA가 품질과 비용 절감 수준을 조정할 수 있음을 보여줍니다. - 한 운영 지점에서는 Sonnet보다 높은 성능을 내면서 12.9% 비용을 절감했고, 다른 운영 지점에서는 품질을 균형 있게 유지하며 72.5%를 절감했습니다. - SWE-bench 평가에서 보수적 설정은 70.8% 해결률로 OpenRouter Auto와 동률을 기록하면서 3.3배 높은 절감 효과를 보였습니다. ## 캐시를 고려한 모델 전환 - 매 턴마다 모델을 바꾸면 유연성은 높아지지만, 기존 프롬프트 캐시가 깨져 오히려 비용이 증가할 수 있습니다. - 같은 모델을 계속 사용하면 대화의 프롬프트 접두부를 여러 턴에 걸쳐 재사용할 수 있습니다. - Auto는 다음과 같은 **자연스러운 캐시 경계**에서 주로 모델을 다시 선택합니다. - 첫 번째 요청: 아직 재사용할 캐시가 없는 시점 - 컨텍스트 압축(compaction) 이후: 이전 대화를 요약하면서 프롬프트 접두부가 초기화된 시점 - 그 사이에는 선택된 모델을 유지해 캐시가 축적되도록 합니다. - 즉, 모델 라우팅 자체의 이득뿐 아니라 모델 전환으로 발생하는 캐시 손실까지 함께 계산합니다. ## 여러 언어를 지원하는 라우팅 - Copilot은 영어뿐 아니라 다양한 언어로 사용되므로 라우팅 모델도 다국어 환경에서 작동해야 합니다. - 라우팅 모델은 CJK, 유럽 언어권 등을 포함한 16개 언어군의 대화 데이터로 학습되었습니다. - 19개 언어에서 추출한 VS Code Chat 텔레메트리 평가에서 언어군별 라우팅 정확도는 영어 기준선과 4포인트 이내의 차이를 보였습니다. - 언어군 사이에 통계적으로 유의미한 품질 격차도 나타나지 않았습니다. Copilot의 효율성을 높이려면 모든 정보를 매번 다시 보내거나 모든 작업에 가장 큰 모델을 사용하는 대신, 반복 컨텍스트는 캐시하고 도구는 필요할 때 불러오며 작업 난이도에 맞는 모델을 선택하는 것이 효과적입니다. 특히 긴 에이전트 세션에서는 모델 전환으로 캐시가 손실되지 않도록 하는 전략이 비용과 응답 속도 모두에 중요합니다.

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

Amazon Bedrock AgentCore 웹 검색 출시 발표: AI 에이전트를 최신의 정확한 웹 지식으로 기반 강화하기 | Amazon Web Services

Amazon Bedrock AgentCore의 Web Search가 정식 출시되어, AI 에이전트가 최신 웹 정보를 검색하고 출처와 함께 응답하도록 지원한다. 검색은 AWS 환경 내부에서 처리되므로 고객의 프롬프트와 검색 질의를 외부 검색 API 사업자에게 전송하지 않으며, 모델 학습 데이터 이후의 최신 정보도 안전하게 활용할 수 있다. Amazon 웹 인덱스와 지식 그래프를 결합해 일반 웹 검색보다 정확하고 신뢰도 높은 근거 제공을 목표로 한다. ## 최신 웹 정보와 출처를 활용한 응답 - 에이전트가 자연어 검색 질의를 보내면 관련성이 높은 다음 정보를 반환한다. - 검색 결과 요약문(snippet) - 원문 URL - 문서 제목 - 발행일 - 에이전트는 반환된 검색 결과를 추론해 최신 사실에 근거한 답변이나 후속 작업을 수행할 수 있다. - 모델의 학습 시점 이후 발생한 사건과 정보를 반영할 수 있어, 시의성이 중요한 업무에 적합하다. ## Amazon 검색 인프라와 지식 그래프 결합 - Web Search는 Amazon의 검색 인프라를 기반으로 구축됐다. - Amazon 웹 인덱스뿐 아니라 구조화된 지식 그래프 데이터도 함께 사용하는 다중 소스 기반 검색 방식을 적용한다. - Amazon Knowledge Graph의 검증된 사실을 활용해 단순 키워드 검색보다 관련성과 정확도가 높은 결과를 제공한다. - Alexa+, Amazon Quick, Kiro 등에서 축적한 에이전트 검색 경험이 기반이 됐다. ## MCP 기반 Bedrock AgentCore Gateway 연동 - Web Search는 Bedrock AgentCore Gateway의 기본 제공 커넥터 타깃으로 제공된다. - Model Context Protocol(MCP)을 사용하므로 MCP를 지원하는 에이전트와 개발 도구에서 호출할 수 있다. - 사용자는 Gateway 생성 시 다음과 같이 Web Search를 추가할 수 있다. - 대상 프로토콜: MCP target - 대상 유형: Connectors - 사전 구성된 타깃: Web Search - 기존 Gateway의 상세 페이지에서도 Web Search 타깃을 추가할 수 있다. ## 설정 및 테스트 방법 - Bedrock AgentCore 콘솔에서 Web Search 도구 타깃이 포함된 Gateway를 생성한다. - Gateway URL이 생성되면 다음 방식으로 검색 도구를 호출할 수 있다. - API 요청 - AWS CLI - Python 코드 - MCP Python SDK - Strands MCP Client - MCP Inspector - MCP Inspector에서는 Gateway 리소스 URL에 연결한 뒤 Web Search 도구를 선택하고 검색어를 입력해 결과를 즉시 확인할 수 있다. - 콘솔의 **View invocation code** 영역에서 호출 예제 코드를 확인할 수 있다. ## 보안과 기업 거버넌스 - 검색 질의와 사용자 프롬프트를 AWS 외부의 검색 API 제공업체로 보내지 않고, 고객의 보안된 AWS 환경 내에서 처리할 수 있다. - 별도의 검색 인프라를 직접 구축하거나 외부 API 연동을 관리하지 않아도 된다. - 기업 정책에 맞춰 데이터 보호와 접근 통제를 유지하면서 외부 공개 정보와 내부 데이터를 함께 활용할 수 있다. - Benchling은 기관 내부 과학 데이터와 최신 학술 문헌을 결합해 연구 질문에 답하고 가설을 생성하는 데 활용하고 있다. - Gen Digital은 Norton Revamp에서 현재 온라인 동향을 반영한 콘텐츠 아이디어를 생성하는 데 사용하고 있다. ## 제공 지역과 비용 - 현재 미국 동부(버지니아 북부) 리전에서 정식 제공된다. - Web Search 자체는 추가 비용 없이 시작할 수 있다. - Gateway 사용에 따른 데이터 전송 요금은 별도로 부과된다. - 신규 AWS 고객은 최대 200달러의 프리 티어 크레딧을 받을 수 있다. 실제로 도입할 때는 먼저 MCP Inspector로 검색 결과의 품질과 출처 형식을 검증한 뒤, 에이전트 프롬프트에 “검색 결과의 출처와 발행일을 반드시 반영하라”는 규칙을 추가하는 것이 좋다. 이후 내부 데이터와 웹 검색 결과를 함께 사용하는 경우에는 권한 관리와 출처 추적 정책을 별도로 설계해야 한다.

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