techlist.io
KREN

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

github3분 읽기큐레이션 요약

초보자를 위한 GitHub Copilot 앱: 시작하기

GitHub Copilot 앱은 단순한 채팅 도구가 아니라, 프로젝트별 AI 에이전트 세션을 관리하고 코드 작성부터 리뷰·병합까지 지원하는 통합 개발 작업 공간이다. 여러 작업을 동시에 진행하고, 캔버스에서 UI를 직접 확인·수정하며, Agent Merge로 PR 리뷰와 CI 문제 대응까지 자동화할 수 있다. 글은 초보자가 프로젝트를 연결해 세션을 시작하고 실제 개발 workflow에 Copilot을 활용하는 방법을 소개한다. ## 프로젝트를 중심으로 시작하는 작업 - Copilot 앱의 각 에이전트 세션은 특정 프로젝트와 연결된다. - 기존에 작업한 GitHub 프로젝트를 선택하거나 GitHub 저장소·로컬 컴퓨터에서 새 프로젝트를 추가할 수 있다. - 프로젝트가 연결되면 에이전트가 코드베이스, 파일, 개발 도구에 접근한 상태로 작업을 시작한다. - 예를 들어 “기존 애플리케이션에 breadcrumb navigation을 추가해 달라”고 요청하면 에이전트가 다음 작업을 수행할 수 있다. - 관련 파일과 수정 위치 탐색 - 코드 변경 - 테스트 실행 - 변경 사항 검증 지원 - 세션 시작 전에 개발 환경과 파일을 수동으로 준비할 필요가 줄어든다. ## 여러 작업을 동시에 진행하는 세션 - 기존 세션을 중단하지 않고 다른 질문이나 작업을 위한 추가 세션을 만들 수 있다. - **Quick Chat**을 사용하면 Copilot 앱 홈 화면에서 별도의 대화를 시작할 수 있다. - 각 세션을 다음과 같이 독립적인 주제에 사용할 수 있다. - 새로운 기능 구현 - 코드베이스 구조 조사 - 가능한 구현 방식 비교 - Copilot 앱이나 worktree 사용법 질문 - 원래 작업 세션으로 돌아오면 이전 맥락과 변경 사항을 확인한 뒤 작업을 이어갈 수 있다. - 작업별로 대화를 분리하면 서로 다른 개발 흐름을 섞지 않고 진행 상황을 관리하기 쉽다. ## 캔버스를 이용한 UI 확인과 개선 - UI 작업에서는 코드 검토뿐 아니라 실제 화면을 직접 확인하는 것이 중요하다. - Copilot 앱의 **canvas**는 애플리케이션, 계획, 칸반 보드, 체크리스트 같은 작업 결과물을 대화 옆에서 시각적으로 보여주는 공유형 공간이다. - `/create-canvas Open this app in a browser canvas` 명령으로 별도 터미널이나 브라우저를 열지 않고 애플리케이션을 실행할 수 있다. - **Enable Canvas Dev Mode**를 켜면 캔버스에서 특정 UI 요소를 직접 선택할 수 있다. - **Pick & Polish** 기능을 사용하면 선택한 요소를 다음 요청의 컨텍스트로 전달해 다음과 같은 반복 개선이 가능하다. - 화면의 특정 요소 선택 - 수정 요청 작성 - 변경 결과 확인 - 추가 조정 반복 - 텍스트 기반 설명만으로 UI를 수정하는 것보다 시각적 결과를 기준으로 구체적인 피드백을 제공할 수 있다. ## Agent Merge를 활용한 PR 후속 작업 - 코드 변경이 끝난 뒤에는 pull request, CI, 코드 리뷰 과정이 이어진다. - Copilot 앱의 PR 옵션에서 **Agent Merge**를 활성화하면 에이전트가 PR 진행 상황을 모니터링한다. - 허용할 작업을 선택할 수 있으며, 주요 예시는 다음과 같다. - 리뷰 피드백 반영 - CI 실패 원인 해결 지원 - merge conflict 처리 - 리뷰 중 변경 요청이나 자동화된 검사 실패가 발생하면 Agent Merge가 대응 작업을 수행하고 PR을 병합 가능한 상태로 준비한다. - 필수 검사가 모두 통과한 뒤 사용자가 최종적으로 병합할 수 있다. ## AI 에이전트 기반 개발 workflow - Copilot 앱은 하나의 대화창보다 실제 소프트웨어 개발 과정에 맞춘 작업 공간을 제공한다. - 기본 workflow는 다음과 같이 구성된다. 1. 프로젝트 선택 2. 작업별 에이전트 세션 생성 3. 필요할 때 Quick Chat으로 조사·질문 4. 캔버스에서 실행 결과와 UI 확인 5. PR 생성 6. Agent Merge로 리뷰·CI·충돌 대응 7. 검사 통과 후 병합 - 사용자는 코드 작성뿐 아니라 탐색, 시각적 검증, 리뷰 대응까지 한 환경에서 이어서 진행할 수 있다. 새 기능이나 오래된 backlog 작업을 하나 선택해 프로젝트를 연결하고, 작업별 세션과 캔버스를 활용해 작은 범위부터 시작하는 것이 좋다. 다만 AI가 만든 변경 사항과 테스트 결과는 직접 검토한 뒤 PR을 병합해야 한다.

원문 읽기(새 탭에서 열림)
AI 에이전트CI/CDgithubgithub-copilot+3
kakao4분 읽기큐레이션 요약

더 작고 강해진 Kanana SLM 개발

Kanana-2는 온디바이스 환경에 맞춰 크기와 추론 비용을 줄이면서도 대형 모델에 가까운 성능을 확보한 카카오의 SLM 시리즈다. 3B 모델을 TPU에서 처음부터 사전 학습한 뒤 Instruct 모델을 Teacher로 활용한 Distillation과 Long Context 학습을 적용했으며, 이를 기반으로 1.3B와 0.9B 모델을 단계적으로 압축했다. 또한 한국어 토크나이저 개선과 Sliding Window Attention(SWA)을 도입해 언어 처리량과 메모리 효율을 높였다. ## Kanana-2 SLM 개발 배경 - 대상 모델은 **Kanana-2-3B, 1.3B, 0.9B** 세 가지다. - 3B와 1.3B는 Base 및 Instruct 모델로 공개됐다. - 스마트폰 등 온디바이스 환경은 메모리와 연산 자원이 제한적이므로, 작고 빠르면서도 다양한 업무를 처리할 수 있는 SLM이 필요하다. - Kanana-2 개발에는 Kanana-2-30B-A3B 개발 경험과 기존 Kanana Nano의 Pruning·Distillation 노하우가 활용됐다. - 새로운 핵심 기법으로 Teacher 기반의 **off-policy·on-policy 학습**, 개선된 Pruning·Distillation, Kanana-2 Tokenizer, SWA가 적용됐다. ## 3B 모델의 TPU 기반 사전 학습 - Kanana-2-3B-Base는 TPU v5e 클러스터와 MaxText 기반 자체 학습 프레임워크로 처음부터 사전 학습됐다. - TPU에서 사전 학습한 뒤 GPU 클러스터에서 Distillation을 이어서 수행할 수 있도록 TPU와 GPU 간 학습 호환성을 확보했다. - 사전 학습은 2단계로 진행됐다. - **Stage 1:** 7.5T 토큰 - **Stage 2:** 2T 토큰 - 전체 사전 학습 구간에 **Muon Optimizer**를 적용했다. ## Proxy Token Scale을 활용한 Learning Rate 탐색 - 수조 개 토큰 규모의 본 학습에서 Learning Rate를 직접 탐색하는 것은 비용이 지나치게 크다. - Stage 1의 데이터 분포를 유지한 채 **100B 토큰 규모의 Proxy 학습**으로 후보 Learning Rate를 먼저 비교했다. - 이후 최적 Learning Rate를 본 학습 규모에 맞게 Token Horizon Scaling 법칙으로 조정했다. - 사용한 식은 다음과 같다. `LR*(Dtarget) ≈ LR*(Dproxy) × (Dtarget / Dproxy)^(-β)` - `Dproxy=100B`, `Dtarget=7.5T`, `β=0.32`를 사용했다. - 토큰 규모가 커질수록 최적 Learning Rate가 작아지는 경향을 반영해, 적은 탐색 비용으로 안정적인 학습 설정을 얻었다. ## Instruct Teacher를 활용한 Distillation - GPU 기반 Megatron-LM 프레임워크에서 **Kanana-2-30B-A3B-Instruct-2601**을 Teacher로 사용했다. - Base, Instruct, Thinking 모델을 각각 Teacher로 설정해 성능을 비교했다. - 실험 결과, 학습 전반에서 **Instruct 모델을 Teacher로 사용했을 때 가장 높은 성능**을 보였다. - 특히 Post-trained 모델을 Teacher로 사용하면 수학과 코드 영역에서 효과가 크다는 기존 연구 결과와도 일치한다. ## 32K Long Context 학습 - 4K 컨텍스트에서 YaRN을 적용해 최대 **32K 컨텍스트**까지 확장했다. - Learning Rate decay 단계에서 Mid-training 데이터를 추가해 최종 Base 모델을 완성했다. - Kanana-2-3B-Base는 이전 Kanana 3B 모델보다 한국어·영어 지식, 수학, 코드 등에서 향상된 성능을 보였다. - 유사한 크기의 오픈소스 SOTA Base 모델과 비교해도 대부분의 평가 영역에서 우수한 결과를 기록했다. ## 1.3B·0.9B 모델의 단계적 압축 - 3B Base 모델을 기반으로 **1.3B Base와 0.9B Base**를 순차적으로 개발했다. - 주요 압축 방식은 모델 구조를 줄이는 **Structured Pruning**과 Teacher의 지식을 전달하는 **Knowledge Distillation**이다. - Pruning 대상에는 Layer, Hidden Dimension, MLP 중간 차원, Attention Head 등이 포함될 수 있다. - 기존 Kanana Nano보다 Hidden Dimension pruning 방법을 고도화했다. ## PCA 기반 Hidden Dimension Pruning - 기존 방식은 Calibration 데이터의 Activation으로 각 Hidden dimension의 중요도 점수를 계산하고, 점수가 높은 차원만 남겼다. - 이 방식은 차원을 개별적으로 평가하기 때문에 여러 차원이 함께 형성하는 Hidden representation을 충분히 반영하지 못한다. - Kanana-2에서는 Ministral 3의 **PCA 기반 pruning**을 적용했다. - 처리 과정은 다음과 같다. 1. Calibration 데이터로 Attention RMSNorm, MLP RMSNorm, Final RMSNorm 입력의 Activation 통계를 수집한다. 2. PCA를 수행해 Global Rotation Matrix를 계산한다. 3. Token Embedding, Attention, MLP Projection Weight의 입출력에 동일한 회전을 적용한다. 4. 회전된 표현을 기준으로 Hidden dimension을 축소한다. - 이를 통해 개별 차원의 중요도뿐 아니라 여러 차원에 분산된 표현 구조까지 고려하는 것을 목표로 한다. ## SWA와 토크나이저를 통한 추론 효율 개선 - **Sliding Window Attention(SWA)**를 적용해 각 토큰이 제한된 범위의 이전 토큰만 참조하도록 했다. - 전체 시퀀스에 대한 Attention을 줄여 Decoding 병목을 완화한다. - KV Cache 크기를 축소해 온디바이스 추론에서 메모리 사용량을 줄인다. - SWA 구조에 맞춘 Long Context 학습도 별도로 수행했다. - **Kanana-2 Tokenizer**는 주요 언어인 한국어 처리 효율을 기존 대비 30% 이상 개선했다. - 토큰 수가 줄어들면 같은 문장을 처리할 때 필요한 연산량과 메모리 사용량도 함께 감소한다. ## 실용적인 결론 Kanana-2의 접근법은 단순히 모델 파라미터를 줄이는 것이 아니라, 3B 모델의 충분한 사전 학습과 강력한 Teacher Distillation, PCA 기반 구조적 pruning, SWA, 한국어 특화 토크나이저를 함께 최적화한 사례다. 온디바이스 서비스에서는 모델 크기만 비교하기보다 **한국어 토큰 효율, KV Cache 메모리, 실제 Decoding 속도, 압축 후 성능 유지율**을 함께 평가하는 것이 중요하다.

원문 읽기(새 탭에서 열림)
knowledge-distillationkananatpusmall-language-model+4
aws4분 읽기큐레이션 요약

AWS 주간 요약: 아테네 로컬 영역, AWS의 Claude Opus 5, .NET용 Lambda 내구성 실행 및 기타 소식 (2026년 7월 27일) | Amazon Web Services

AWS는 인프라를 사용자와 데이터가 있는 지역에 더 가깝게 배치하고, AI·서버리스·관측성 기능을 강화하는 업데이트를 발표했다. 그리스 아테네 Local Zone, Amazon Bedrock의 Claude Opus 5, .NET용 Lambda durable execution 등이 대표적이다. 또한 에이전트 품질 평가, 멀티 리전 복원력, AI 코딩 도구의 효과 측정처럼 운영 단계의 실용성도 강조됐다. ## 아테네 AWS Local Zone 개설 - 그리스 아테네에 AWS Local Zone이 개설됐다. - EMEA 지역에서 Amazon S3와 Amazon EBS Local Snapshots를 지원하는 두 번째 Local Zone이다. - 지원 서비스: - Amazon EC2 C7i, M7i, R7i 인스턴스 - Amazon S3 One Zone-Infrequent Access - Amazon EBS - Amazon ECS - 데이터를 그리스 내에서 저장·처리할 수 있어 데이터 레지던시 요구사항 대응에 유리하다. - 대규모 사용자·산업 거점 가까이에서 한 자릿수 밀리초 지연 시간을 제공해 실시간 게임, 미디어 제작, 금융 서비스 등에 적합하다. - 지연 시간이 중요한 워크로드는 아테네에서 실행하고, 나머지 AWS 서비스는 인접 리전과 연결하는 하이브리드 아키텍처를 구성할 수 있다. ## Amazon Bedrock의 Claude Opus 5 - Anthropic의 최신 Opus급 모델인 Claude Opus 5를 AWS에서 사용할 수 있게 됐다. - Amazon Bedrock과 AWS 기반 Claude Platform을 통해 접근할 수 있다. - Amazon Bedrock에서는 zero data retention(ZDR)이 기본 활성화되어 데이터 거버넌스 요구사항을 충족하는 데 도움이 된다. - 고도의 지능이 필요한 애플리케이션에서 Opus급 가격으로 사용할 수 있다는 점이 강조됐다. ## .NET용 Lambda durable execution 정식 출시 - C# 개발자는 사용자 정의 진행 상태 추적이나 외부 오케스트레이션 서비스 없이 장기 실행 워크플로를 구축할 수 있다. - SDK가 실행 진행 상황을 자동으로 체크포인트에 저장한다. - 워크플로를 최대 1년까지 일시 중지할 수 있다. - 적합한 사용 사례: - 결제 처리 파이프라인 - AI 에이전트 오케스트레이션 - 사람의 승인이 필요한 human-in-the-loop 프로세스 - 기존에 개발자가 직접 구현해야 했던 재시도, 상태 저장, 재개 로직을 줄여준다. ## Bedrock AgentCore 관측성 통합 - 에이전트의 트레이스와 프롬프트가 에이전트 로그와 동일한 CloudWatch 로그 그룹에 저장된다. - 기존에는 트레이스와 프롬프트·입출력 데이터가 서로 다른 위치에 저장되어 단일 호출을 분석하기 어려웠다. - 이제 한 곳에서 에이전트 호출을 추적하고 디버깅할 수 있다. - 에이전트 단위로 세밀한 접근 제어와 고객 관리형 키(CMK) 암호화를 적용할 수 있다. ## Amazon Connect의 다국어 음성 에이전트 - 50개 이상의 언어에서 더 자연스럽고 인간적인 음성 기반 AI 경험을 제공한다. - 포르투갈어, 스페인어, 프랑스어, 이탈리아어, 일본어, 한국어, 태국어 등을 지원한다. - 100개 이상의 새로운 음성 옵션과 대화 품질 개선이 추가됐다. - AI 에이전트가 음성·디지털 채널에서 고객의 의도와 감정, 말투를 이해하고 필요한 작업을 수행할 수 있다. - 다국어 고객센터와 자연스러운 셀프서비스 구축에 활용할 수 있다. ## SageMaker Unified Studio와 OpenSearch 통합 - SageMaker Unified Studio에서 Amazon OpenSearch의 검색·로그 분석 데이터를 직접 조회하고 분석할 수 있다. - OpenSearch 데이터를 Amazon Redshift, Amazon S3, 관계형 데이터베이스의 데이터와 함께 다룰 수 있다. - 운영 데이터와 분석 데이터를 결합해 애플리케이션 로그와 트랜잭션 데이터를 연계 분석하는 데 유용하다. - 여러 데이터 소스를 하나의 거버넌스 환경에서 관리할 수 있다는 점이 핵심이다. ## CloudWatch 코딩 에이전트 인사이트 - 조직 내 AI 코딩 도구가 실제로 어떤 가치를 창출하는지 측정할 수 있다. - Claude apps gateway for AWS를 통해 Claude Code의 텔레메트리를 별도 계측 없이 수집한다. - Codex와 GitHub Copilot 같은 다른 코딩 에이전트도 지원한다. - OpenTelemetry 기반 지표로 AI 코딩 도구 도입 효과와 투자수익을 분석할 수 있다. ## 추가 AWS 소식과 행사 - Strands Agents와 Bedrock AgentCore를 활용해 AI 에이전트를 프로덕션 전후로 체계적으로 평가하는 가이드가 소개됐다. - CloudFormation custom resource를 멀티 리전 구조로 설계해 특정 리전 장애에도 배포 안정성을 유지하는 방법이 다뤄졌다. - Amazon SES에 이메일 발송량 증가에 대응할 수 있는 예측 가능한 가격제가 추가됐다. - AWS Summits와 AWS Community Days 등 2026년 하반기 개발자·클라우드 행사가 안내됐다. 실무적으로는 지역 데이터 보존이 필요하면 아테네 Local Zone을 검토하고, .NET 기반 장기 워크플로에는 Lambda durable execution을 활용할 만하다. AI 에이전트를 운영 중이라면 AgentCore의 통합 로그와 체계적인 평가 방법을 함께 도입하는 것이 효과적이다.

원문 읽기(새 탭에서 열림)
AWSamazon-bedrockaws-lambdaamazon-sagemaker+4
cloudflare3분 읽기큐레이션 요약

프라이버시 프록시 CLI를 오픈 소스로 공개합니다

Oblivious HTTP(OHTTP)는 여러 주체와 바이너리 인코딩을 거치기 때문에 장애 원인을 추적하기 어렵다. Cloudflare는 실제 운영 경험을 바탕으로 전체 OHTTP 요청 과정을 한 번에 실행하고 각 단계를 확인할 수 있는 오픈소스 CLI 도구 `pvcli(privacy-client)`를 만들었다. 이 도구는 복잡한 수작업과 일회성 스크립트를 줄여 개발·테스트·장애 대응을 단순화한다. ### OHTTP가 제공하는 프라이버시 구조 - OHTTP는 요청을 보낸 사람과 요청 내용을 한 주체가 동시에 알 수 없도록 설계된다. - 서로 충돌하지 않는 두 운영 주체가 필요하다. - **Relay**: 클라이언트의 신원을 gateway에 전달하지 않음 - **Gateway**: 요청을 복호화해 실제 대상 서버로 전달 - 일반적인 요청 흐름은 다음과 같다. - 클라이언트가 gateway의 공개 키를 가져온다. - 클라이언트가 HTTP 요청을 암호화해 relay로 보낸다. - relay가 클라이언트 식별 정보를 제거하고 gateway로 전달한다. - gateway가 요청을 복호화해 target 서버에 전송한다. - target의 응답을 gateway가 다시 암호화한다. - relay가 암호화된 응답을 클라이언트에 전달한다. - 클라이언트가 응답을 복호화한다. - 각 단계가 별도의 장애 지점이므로, 문제가 relay·gateway·target 중 어디에서 발생했는지 확인하기 어렵다. ### 기존 디버깅 방식의 문제 - 고객 환경에서 실제 end-to-end 테스트를 수행하려면 배포별 맞춤 클라이언트를 일회성으로 작성해야 했다. - 장애 발생 시 자체 시스템의 문제인지 고객 시스템의 문제인지 판별하는 데 시간이 많이 걸렸다. - OHTTP는 바이너리 HTTP를 사용하므로 원시 바이트를 직접 분석해야 했다. - 공개 키, 바이너리 HTTP 요청, 암호화된 OHTTP 메시지를 RFC에 따라 수작업으로 해석해야 했다. - 사람이 긴 hexadecimal 문자열을 직접 검증하는 과정은 번거롭고 실수하기 쉽다. ### 공개 키와 바이너리 HTTP의 수동 분석 - gateway에서 받은 공개 키 설정은 긴 hexadecimal 데이터로 반환된다. - RFC 9458에 따라 다음 필드를 직접 해석해야 한다. - `0029`: 공개 키 항목의 길이 - `55`: 공개 키 ID - `0020`: DHKEM(X25519, HKDF-SHA256) 비대칭 암호 방식 - 뒤따르는 32바이트: 실제 공개 키 - `0004`: 대칭 암호 방식 ID 영역의 길이 - `0001`, `0001`: HKDF-SHA256 및 AES-128-GCM 식별자 - 원래의 HTTP 요청도 RFC 9292의 바이너리 HTTP 형식으로 변환해야 한다. - 예를 들어 `POST`, `https`, 호스트명, 경로, 헤더와 본문이 각각 바이너리 필드로 인코딩된다. - 이후 공개 키를 이용해 바이너리 HTTP 요청을 OHTTP 형식으로 암호화하고, 키 ID와 암호 방식 ID를 포함한 헤더를 붙여 relay에 보낼 wrapper HTTP 요청을 만들어야 한다. ### `pvcli`의 역할 - Cloudflare는 이러한 프라이버시 프로토콜 관련 기능을 하나의 CLI에 통합했다. - 익숙한 HTTP 클라이언트 인터페이스를 제공하면서 OHTTP의 각 처리 단계를 순서대로 표시한다. - relay, gateway, origin으로 이어지는 전체 요청을 단일 명령으로 실행할 수 있다. - 예시 명령은 다음 작업을 수행한다. - `--first-hop`: relay 지정 - `--proxy`: gateway 지정 - `-X POST`: HTTP 메서드 지정 - `--header`: 요청 헤더 지정 - `--data`: JSON 요청 본문 지정 - 대상 URL: gateway가 요청을 전달할 origin - 따라서 사용자는 공개 키 조회, 바이너리 HTTP 변환, OHTTP 암호화, relay 전달, 응답 복호화 과정을 각각 수동으로 구현할 필요가 없다. ### 공개와 활용 - 도구 이름은 `privacy-client`, 실행 파일은 `pvcli`다. - Apache-2.0 라이선스로 공개되며 외부 기여를 허용한다. - 새로운 프라이버시 프로토콜이나 다양한 네트워크 아키텍처를 지원할 수 있도록 확장성을 고려했다. - 운영 환경과 유사한 end-to-end 테스트 및 장애 재현에 활용할 수 있다. 복잡한 OHTTP 시스템을 운영하거나 연동한다면, 원시 바이트와 RFC를 직접 해석하는 방식보다 `pvcli`로 전체 경로를 재현하는 것이 효율적이다. 특히 relay·gateway·origin 중 장애 위치를 빠르게 좁혀야 하는 개발 및 incident response 상황에서 유용하다.

원문 읽기(새 탭에서 열림)
cryptographyclioblivious-httpbinary-http+3
figma3분 읽기큐레이션 요약

디지털 도구, 인간의 표현: Config 2026의 시각적 아이덴티티 | Figma 블로그

Config 2026의 시각적 정체성은 AI 시대의 강력한 디지털 도구와 인간의 창의적·불완전한 표현을 함께 보여주는 데 초점을 맞췄다. Figma Brand Studio는 아이디어가 변형되고 확장되는 과정을 글리프, 생성형 텍스처, 동적인 구성으로 표현했다. 그 결과 디지털 화면부터 샌프란시스코 Moscone Center의 대형 조형물과 공간 연출까지 일관되면서도 인간적인 브랜드 경험을 만들었다. ## 인간과 AI의 협업을 표현한 세 가지 원칙 - **진화(Evolution)** - 아이디어를 그대로 완성하는 대신 remix, reinterpret, reinvent 과정을 거쳐 새로운 결과를 만든다는 개념이다. - 하나의 형태가 변형되고 증식하는 모습을 시각 시스템에 반영했다. - **유동성(Fluidity)** - 디자인, 코드, 프로토타입 사이를 오가며 다양한 지점에서 작업을 시작하는 현대적 제작 방식을 나타낸다. - 고정된 순서보다 반복과 순환을 강조한다. - **조화(Harmony)** - 생성형 도구로 빠르게 탐색하더라도 최종 판단에는 인간의 관점과 감각이 필요하다는 의미다. - AI의 정교함과 사람의 의도적인 불완전성을 함께 유지했다. ## 글리프로 아이디어의 변형과 확장을 시각화 - Config의 핵심 시각 요소는 스케치처럼 보이거나, 생성형 이미지처럼 유기적이거나, 선명한 기하학 형태를 가진 **글리프**였다. - 입자 형태의 글리프는 아이디어가 계속 생성되고 퍼지는 과정을 상징했다. - 반대로 깔끔한 직사각형은 충분히 정리되고 완성된 아이디어를 나타냈다. - 글리프는 약 14피트 높이의 폼 조형물로 제작되어 Moscone Center 외부와 행사 공간의 장면을 구성했다. - 결과물은 다소 엉뚱하고 개성 있어 보이면서도 프로그램으로 생성된 듯한 디지털 특성을 동시에 지녔다. ## AI로 만든 불완전한 텍스처 - 팀은 Figma Make로 원하는 로파이 효과를 도구화하고, 다음 세 가지 핵심 텍스처를 제작했다. - 낙서 같은 선화 - 흐릿한 그라디언트 - 타원형 입자 - 이미지를 도구에 입력해 예측하기 어렵고 손으로 그린 듯한 구성을 생성했다. - 완벽하고 자동화된 시각물 대신 작은 오류와 불규칙성을 남겨 인간적인 느낌을 강조했다. - 수백 명의 발표자 사진에는 디더링 도구를 적용했다. - 모든 사진에 일관된 스타일을 빠르게 적용했다. - 미세한 점묘 효과가 디지털 코드처럼 보이면서도 손으로 만든 질감을 더했다. - 흐릿한 형태와 거친 점 텍스처는 키노트 무대, 영상, 행사장 애니메이션 등 여러 접점에서 활용됐다. ## 정적인 디자인과 모션의 병행 제작 - 팀은 정적 그래픽을 먼저 완성한 뒤 애니메이션으로 넘기는 방식 대신, 정적 자산과 모션 자산을 동시에 개발했다. - 디자인과 모션이 서로 영향을 주는 반복적인 협업 구조를 취했다. - 초기 글리프가 실제로 움직이는 모습을 확인하면서 형태의 가능성을 새롭게 발견하는 등, 애니메이션 자체가 디자인 탐색의 도구로 기능했다. - 이를 통해 Config의 그래픽은 단순한 장식이 아니라 아이디어가 살아 움직이고 변형되는 과정을 보여주는 시스템이 됐다. ## 실용적인 시사점 AI를 활용한 브랜드 디자인에서도 결과물을 지나치게 매끈하게 만드는 것보다, 의도적인 불완전성과 인간의 판단을 남기는 것이 차별화에 도움이 된다. 또한 글리프·텍스처·모션처럼 재사용 가능한 시각 요소를 시스템화하면 디지털 콘텐츠와 오프라인 공간 전반에 일관된 경험을 효율적으로 확장할 수 있다.

원문 읽기(새 탭에서 열림)
FigmaAIfigma-makemotion-design+2
gitlab3분 읽기큐레이션 요약

GitLab의 Claude Opus 5: 어려운 작업을 위해 설계된 추론

Anthropic의 Claude Opus 5가 GitLab Duo Agent Platform에 출시되어 복잡하고 중요한 개발 작업에 더 깊은 추론 능력을 제공한다. GitLab 내부 평가에서 작업 해결률 93.3%를 기록해 Opus 4.8의 73.0%보다 크게 향상됐으며, 속도도 유지했다. 일상적인 작업에는 Sonnet 계열을, 대규모 리팩터링·장기 디버깅처럼 실패 비용이 큰 작업에는 Opus 5를 선택하는 전략이 권장된다. ## 복잡한 작업에서 강화된 추론과 정확성 - 여러 파일을 수정하는 기능 개발, 대규모 리팩터링, 장기간의 커밋 이력을 추적하는 디버깅에 적합하다. - 내부 평가에서: - Opus 5 작업 해결률: **93.3%** - Opus 4.8 작업 해결률: **73.0%** - 두 모델 모두 시도한 작업의 완료율은 **100%** - 단순히 작업을 끝내는 것을 넘어, 결과가 검증된 올바른 해결책인지에서 큰 차이를 보였다. - 부분적인 패치나 반복적인 재프롬프트가 줄어들어, 결과물을 바로 머지할 가능성이 높아진다. - 예시로 5개 파일을 수정하고 새로운 공개 타입과 설정 필드를 추가해야 하는 CLI SSO 인증 기능을 완전히 구현하고 커밋한 뒤 머지 리퀘스트까지 생성했다. ## 코드 리뷰와 멀티 에이전트 협업 - 실제 버그를 잘 포착하면서도 오탐이 적어, 개발자가 불필요한 경고를 검토하는 시간을 줄인다. - 여러 에이전트를 동시에 실행할 때 각 에이전트가 서로의 작업을 덮어쓰거나 충돌시키는 문제를 줄인다. - Writer-verifier 패턴을 활용할 수 있다. - 한 에이전트가 코드를 작성한다. - 다른 에이전트가 결과를 검증한다. - 검증을 통과한 결과만 최종 작업에 반영한다. - 장시간 자율 실행하거나 여러 에이전트를 병렬로 운영하는 환경에서 특히 효과가 크다. - GitLab Credits 사용량 상한을 설정해 병렬 에이전트 작업의 비용이 예산을 초과하지 않도록 제한할 수 있다. ## 깊은 추론을 유지하면서도 빠른 실행 - GitLab의 고난도 벤치마크에서 95번째 백분위 실행 시간은 다음과 같다. - Opus 5: **768초** - Opus 4.8: **784.98초** - Sonnet 4.6: **982.57초** - Opus 5는 Opus 4.8보다 **2.2% 빠르고**, Sonnet 4.6보다 **21.9% 빠르다**. - 복잡한 장기 작업에서도 실행 시간이 지나치게 늘어지는 상황을 줄여 보다 예측 가능한 결과를 제공한다. ## 작업별 모델 선택 - 모든 개발 작업에 가장 강력한 모델을 적용하기보다 작업의 복잡도에 따라 모델을 선택해야 한다. - **Sonnet 계열** - 일상적인 개발 작업 - 빠른 코드 생성과 수정 - 비용 효율성이 중요한 반복 작업 - **Opus 5** - 대규모 리팩터링 - 어려운 버그 추적 - 여러 파일과 시스템에 걸친 기능 구현 - 잘못된 판단을 다시 되돌리는 비용이 큰 작업 - 모델은 GitLab 인스턴스에서 직접 선택할 수 있다. - 모델이 달라도 GitLab Duo Agent Platform의 컨텍스트 계층, 정책 검사, 감사 추적 인프라는 동일하게 적용된다. ## GitLab Duo Agent Platform에서의 이용 - Claude Opus 5는 GitLab Duo Agent Platform에서 사용할 수 있으며 GitLab Credits로 과금된다. - 신규 사용자는 무료 체험을 시작할 수 있다. - GitLab Premium 또는 Ultimate 구독자는 포함된 GitLab Credits를 활용해 Duo Agent Platform을 활성화할 수 있다. 복잡하고 실패 비용이 큰 작업에는 Opus 5를 우선 적용하고, 반복적인 일상 개발에는 Sonnet 계열을 사용하는 혼합 전략이 가장 실용적이다. 다만 제시된 성능 수치는 GitLab의 내부 평가 결과이므로, 실제 도입 전에는 팀의 코드베이스와 작업 유형을 기준으로 별도 검증하는 것이 좋다.

원문 읽기(새 탭에서 열림)
AI 에이전트코드 리뷰refactoringgitlab-duo-agent-platform+4
cloudflare4분 읽기큐레이션 요약

BGP ORIGIN 속성 조작과 인터넷에 미치는 영향

BGP의 ORIGIN 속성은 경로가 어떻게 BGP에 주입됐는지를 나타내며, 원래 발신 AS가 설정한 뒤 다른 라우터가 변경하지 않는 것이 원칙입니다. 그러나 실제 인터넷에서는 관측된 경로의 약 70%가 최초 설정값과 다른 ORIGIN을 보였고, 이는 경로 선택과 트래픽 흐름에 큰 영향을 줍니다. 특히 일부 트랜짓 사업자는 더 많은 트래픽과 수익을 확보하기 위해 ORIGIN을 선호도가 높은 IGP로 바꾸고 있습니다. ## BGP ORIGIN 속성의 역할 - ORIGIN은 경로를 BGP에 주입한 방식을 나타내며, 경로를 발표한 AS 자체를 뜻하는 `origin AS`와는 다릅니다. - 가능한 값은 다음 세 가지입니다. - `IGP (0)`: 발신 AS 내부에서 생성된 경로 - `EGP (1)`: 현재는 폐기된 Exterior Gateway Protocol을 통해 학습한 경로 - `INCOMPLETE (2)`: 출처가 불명확하거나 외부 방식으로 학습한 경로 - RIPE RIS와 RouteViews의 공개 수집기에서 관측된 경로 분포는 다음과 같습니다. - IGP: 89.8% - EGP: 3.5% - INCOMPLETE: 6.7% - Local Preference와 AS_PATH 길이가 동일한 경로를 비교할 때, 라우터는 더 낮은 ORIGIN 값을 가진 경로를 선택합니다. 따라서 선호도는 일반적으로 `IGP > EGP > INCOMPLETE` 순서입니다. - RFC 4271은 ORIGIN을 최초 발신자가 생성하며, 다른 라우터는 변경하지 않아야 한다고 규정합니다. ## ORIGIN 변조가 트래픽에 미치는 영향 - 두 트랜짓 사업자가 동일한 목적지에 대해 비슷한 길이의 AS_PATH를 제공하면, ORIGIN 값이 경로 선택을 좌우할 수 있습니다. - 예를 들어 AS64501이 `INCOMPLETE`로 경로를 발표했을 때: - AS64502와 AS64503은 원래 해당 값을 유지한 채 경로를 전달해야 합니다. - 하지만 AS64503이 ORIGIN을 `IGP`로 바꾸면, 최종 고객 AS64504는 동일한 AS_PATH 길이에서 AS64503 경로를 선택하게 됩니다. - 결과적으로 AS64503은 더 많은 트래픽을 유치하고 트랜짓 수익을 늘릴 수 있습니다. - 이는 RFC 준수 여부보다 경쟁 사업자와의 트래픽 확보 경쟁이 우선되는 “수익 중심의 라우팅 경쟁”으로 이어집니다. ## 인터넷 운영 관행과 ORIGIN 폐기 논의 - 트랜짓 사업자가 ORIGIN을 IGP로 덮어써 경로 선호도를 높이는 관행은 오랫동안 운영자 커뮤니티에서 사실상 묵인되어 왔습니다. - RIPE 91 회의에서 James Bensley가 주요 네트워크의 광범위한 변조를 공개적으로 지적했고, 이후 LACNIC 45 회의에서는 라틴아메리카 지역의 영향을 조사했습니다. - 이 관행이 공개되면 중단될 가능성도 있지만, 경쟁 사업자들이 계속 변조할 경우 다른 사업자도 “경쟁 조건을 맞추기 위해” 같은 방식을 택할 유인이 있습니다. - ORIGIN 처리 방식이 인터넷 전체에서 일관되지 않게 되면서, ORIGIN 속성의 폐기를 권고하는 Internet-Draft도 작성되었으나 현재는 만료된 상태입니다. ## 변조 현황을 측정한 실험 방법 - 연구진은 IPv4 3개와 IPv6 3개의 테스트 프리픽스를 발표했습니다. - 각 프리픽스에는 각각 `IGP`, `EGP`, `INCOMPLETE` 중 서로 다른 ORIGIN 값을 설정했습니다. - BGP Anycast를 이용해 여러 피어링 지점에서 발표한 뒤, 전 세계로 전파되었는지 확인했습니다. - 이후 프리픽스를 철회해 BGP의 path hunting 과정에서 추가 경로가 드러나도록 했습니다. - 분석에는 다음 데이터가 사용되었습니다. - RIPE RIS 및 RouteViews의 MRT 덤프 - BGPKIT으로 처리한 BGP Update 메시지 - 연구진 경계 라우터에서 수집한 BMP 데이터 - RIB 스냅샷보다 Update 메시지를 사용한 이유는 발표와 철회 과정에서 나타나는 더 많은 경로를 확보하기 위해서입니다. - 다만 공개 BGP 모니터는 인터넷 전체 AS와 연결 구조를 볼 수 없습니다. - 하이퍼스케일러와 CDN이 기존 트랜짓 대신 직접·지역 피어링을 늘리고 있기 때문입니다. - 따라서 관측 결과는 전체 인터넷 토폴로지를 완전히 대표하지 못하며, AS의 의도나 특성에 대한 추론에는 불확실성이 남습니다. ## 두 홉 AS_PATH에서 확인된 변조 - 연구진은 먼저 `ASX AS13335`처럼 AS가 두 개뿐인 AS_PATH를 분석했습니다. - 연구진의 AS가 특정 ORIGIN으로 경로를 발표했으므로, 직접 피어 ASX에서 다른 ORIGIN이 관측되면 ASX가 값을 변경했다고 판단할 수 있습니다. - IPv4 직접 피어 352개를 조사한 결과 다음과 같은 행위가 발견되었습니다. - 3개 AS는 원래 값과 관계없이 ORIGIN을 EGP로 변경했습니다. - 4개 AS는 원래 값과 관계없이 INCOMPLETE로 변경했습니다. - 이는 고객 경로보다 덜 선호되도록 만들어 해당 경로의 선택 가능성을 낮추려는 의도일 수 있습니다. - 한 네트워크 운영자는 피어 또는 프로바이더로부터 받은 경로의 ORIGIN을 EGP로 바꾸어 고객 경로보다 낮은 우선순위를 부여한다고 확인했습니다. - 일부 AS는 비-IGP 경로에 대해 원래 ORIGIN과 IGP를 모두 전파했습니다. - 커뮤니티와 AGGREGATOR 같은 다른 속성을 함께 분석한 결과, 여러 피어링 지점에서 경로를 받고 특정 지점으로 트래픽을 유도하기 위해 IGP로 변경한 것으로 추정됩니다. - 글의 서두에서 제시한 전체 관측 결과에 따르면, 다양한 관측 지점에서 약 70%의 경로가 최초 발신 AS가 설정한 값과 다른 ORIGIN을 보였습니다. ## 실용적인 시사점 - ORIGIN은 단순한 메타데이터가 아니라 BGP 경로 선택과 트래픽 분배를 바꿀 수 있는 실질적인 정책 수단입니다. - 네트워크 운영자는 ORIGIN 변조 여부를 확인하기 위해 BGP Update와 여러 관측 지점의 경로를 비교하고, 커뮤니티·AGGREGATOR·AS_PATH를 함께 분석해야 합니다. - 경로 선택 정책을 ORIGIN에만 의존하면 사업자의 의도적인 조작에 취약하므로, Local Preference와 명시적인 커뮤니티 정책을 우선적으로 활용하는 것이 바람직합니다.

원문 읽기(새 탭에서 열림)
bgpipv6autonomous-systemsipv4+4
naver1분 읽기큐레이션 요약

[AI 해커톤 후기] AI 해커톤 1위 팀이 AI에게 맡기지 않은 것

이 글은 기술적 주제나 구체적인 내용을 다루지 않고, NAVER의 개발자·기술 관련 사이트인 **NAVER D2**의 메뉴 구조만 보여준다. D2 News, About D2, NAVER Developers, DEVIEW, OpenSource, D2 STARTUP FACTORY 등의 항목과 저작권 문구가 포함되어 있다. ### NAVER D2 주요 메뉴 - **D2 News**: D2 관련 소식과 공지로 보이는 메뉴 - **About D2**: NAVER D2의 소개 정보를 제공하는 메뉴 - **NAVER Developers**: NAVER 개발자 관련 자료나 서비스로 연결되는 항목 - **DEVIEW**: NAVER의 개발자 콘퍼런스 관련 항목 - **OpenSource**: 오픈소스 프로젝트 및 자료를 다루는 영역 - **D2 STARTUP FACTORY**: 스타트업 지원 프로그램 관련 메뉴 ### 문서 구성 - 본문에는 “Hello world”라는 짧은 문구만 포함되어 있어 기술 설명이나 사례는 제공되지 않는다. - 하단에는 NAVER의 저작권 문구인 “Copyright © NAVER Corp. All Rights Reserved.”가 표시되어 있다. 실질적인 기술 내용을 파악하려면 원문 본문이나 연결된 각 메뉴의 상세 페이지가 추가로 필요하다.

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

캐시 응답 규칙 소개

Cloudflare의 Cache Response Rules는 원본 서버 응답이 도착한 뒤, 캐시에 저장되기 전에 응답 헤더와 캐시 지시사항을 수정하는 기능이다. `Set-Cookie`, 잘못된 `Cache-Control`, 과도한 `ETag` 등으로 캐시되지 않던 콘텐츠를 원본 코드 변경 없이 캐시 가능하게 만들 수 있다. 다만 캐시 키처럼 요청 단계에서 이미 결정된 사항은 변경할 수 없으므로 기존 Cache Rules를 대체하지 않고 보완한다. ## 캐싱 판단이 이루어지는 시점 - CDN은 가능한 한 캐시에서 응답하고, 캐시에서 처리할 수 없을 때만 원본 서버에 요청한다. - 캐시 적중률이 낮으면 원본 서버의 대역폭과 인프라 비용이 증가하고 응답 속도도 느려진다. - 원본 서버의 응답 헤더는 다음과 같은 캐싱 정책을 결정한다. - 얼마나 오래 캐시할지 - 언제 재검증할지 - 애초에 캐시할 수 있는지 - 많은 캐싱 문제는 요청 시점이 아니라 원본 응답이 도착한 뒤에 드러난다. - 정적 파일에 실수로 `Set-Cookie`가 포함됨 - 캐시해도 안전한 리소스에 `Cache-Control: no-cache`가 설정됨 - 브라우저용 지시사항이 Cloudflare 캐싱에도 적용됨 - 지나치게 공격적인 `ETag`로 조건부 요청마다 재검증이 발생함 ## 기존 방식의 한계 - 요청 단계에서는 원본 서버가 반환할 응답 헤더를 알 수 없다. - 따라서 요청 시점에 동작하는 Cache Rules만으로는 `Set-Cookie`, `ETag`, `Last-Modified`, 원본의 `Cache-Control` 문제를 해결할 수 없다. - 기존 선택지는 다음과 같았다. - 원본 서버 코드나 설정 변경 - Worker로 응답을 다시 가져와 헤더 수정 - 낮은 캐시 적중률을 감수 - 특히 원본 서버 담당 팀과 CDN 담당 팀이 다르면 단순한 헤더 하나를 바꾸는 데도 긴 조율이 필요했다. ## Cache Response Rules의 동작 방식 - 실행 시점은 다음과 같다. 1. Cloudflare가 캐시 미스 후 원본 서버에 요청 2. 원본 응답 수신 3. Cache Response Rules 적용 4. 수정된 응답을 Cloudflare 캐시에 저장 - 다음과 같은 응답 변경이 가능하다. - `Set-Cookie` 제거 - `ETag` 및 `Last-Modified` 제거 - `Cache-Control` 지시사항 수정 - 캐시 태그 설정 및 관리 - 모든 변경은 Cloudflare에서 처리되므로 원본 애플리케이션이나 서버 설정을 수정할 필요가 없다. ## Cache Rules와 Cache Response Rules의 역할 차이 - **Cache Rules**는 요청 단계에서 동작한다. - 응답을 캐시할지 여부 - 어떤 캐시 키로 저장할지 - Edge TTL, 브라우저 TTL, stale 응답 제공 여부 - **Cache Response Rules**는 응답 단계에서 동작한다. - 원본 응답이 캐시에 적합한지 조정 - 캐시를 막는 헤더 제거 - 원본의 `Cache-Control` 수정 - 캐시 태그 설정 - 두 규칙이 충돌하면 Cache Response Rules가 우선한다. - 하지만 응답 단계에서는 캐시 키를 변경할 수 없다. 캐시 키는 원본 요청 전에 이미 결정되기 때문이다. ## 응답 단계에서 가능한 것과 불가능한 것 - 가능한 작업: - `Set-Cookie`를 제거해 캐시 가능하게 만들기 - 캐시 가능한 응답에 `no-store`를 설정해 저장하지 않기 - 원본의 캐시 TTL이나 캐시 지시사항 변경 - 캐시 무효화를 위한 태그 지정 - 불가능한 작업: - 이미 정해진 캐시 키 변경 - 요청 단계에서 캐시 대상에서 제외된 요청을 뒤늦게 캐시 대상으로 전환 - 따라서 Cache Response Rules는 Cache Rules의 대체재가 아니라, 원본 응답 헤더를 보정하는 보완 기능이다. ## 실용적인 결론 정적 리소스가 불필요한 `Set-Cookie`나 잘못된 `Cache-Control` 때문에 캐시되지 않는다면, 원본 서버를 수정하기 전에 Cache Response Rules를 활용하는 것이 효율적이다. 다만 캐시 여부의 기본 정책과 캐시 키는 Cache Rules에서 먼저 설계하고, 응답 단계에서는 헤더와 TTL 등 원본 응답의 캐시 관련 정보를 보정하는 방식으로 함께 사용하는 것이 적절하다.

원문 읽기(새 탭에서 열림)
cloudflarecachingcdncache-response-rules+2
github1분 읽기큐레이션 요약

쿨다운이 필요한 이유: Dependabot이 이제 버전 업데이트를 내놓기 전에 기다리는 이유

Carlin은 GitHub Advanced Security에서 Dependabot을 담당하는 제품 관리자입니다. 소프트웨어 엔지니어링과 데이터 과학 경험을 바탕으로 데이터 중심의 제품 관리 방식을 활용합니다. 워싱턴에서 파트너와 반려견 Cookie와 함께 살며, 여가 시간에는 사이클링과 경쟁적인 보드게임을 즐깁니다. ### GitHub에서의 역할 - GitHub Advanced Security 조직에서 제품 관리 업무를 담당합니다. - 주요 담당 분야는 Dependabot입니다. - 보안과 의존성 관리 기능을 발전시키는 데 집중하고 있습니다. ### 기술적 배경과 업무 방식 - 소프트웨어 엔지니어링 경험을 보유하고 있습니다. - 데이터 과학 배경을 바탕으로 의사결정과 제품 전략을 수립합니다. - 데이터에 근거한 제품 관리 접근 방식을 중요하게 여깁니다. ### 개인 생활과 관심사 - 워싱턴에서 파트너 및 반려견 Cookie와 함께 생활합니다. - 여가 시간에는 사이클링을 즐깁니다. - 경쟁적인 보드게임에도 참여합니다. 전반적으로 Carlin은 개발 및 데이터 전문성을 활용해 GitHub의 보안 제품을 이끄는 제품 관리자입니다.

원문 읽기(새 탭에서 열림)
product-management데이터 사이언스software-engineeringdependabot+1
figma4분 읽기큐레이션 요약

에이전트를 활용해 취약점에 앞서가는 Figma의 방법 | Figma 블로그

Figma는 하나의 보안 정책을 기반으로 AI 에이전트를 코드 작성, 풀 리퀘스트(PR) 리뷰, 과거 코드 감사에 활용한다. 핵심은 단순히 취약점을 많이 찾는 것이 아니라, 정밀도(실제 취약점 비율)와 재현율(실제 취약점 탐지 비율)을 함께 관리해 개발자의 신뢰를 확보하는 것이다. 특히 모든 PR에 적용되는 리뷰 시스템과 사람의 피드백·기존 취약점 재검증을 통해 정책을 지속적으로 개선한다. ## 에이전트 보안의 세 가지 적용 단계 - **코드 생성 단계**: 개발자가 코드를 작성하는 과정에서 취약점을 예방한다. - **PR 리뷰 단계**: 변경된 코드를 검토해 배포 전에 문제를 탐지하고 수정하도록 한다. - **과거 코드 감사 단계**: 오래된 모노레포 전체를 점검해 이미 배포된 취약점을 찾는다. - 세 단계 모두 다음 내용을 포함한 공통 정책을 사용한다. - 신뢰 경계 - 조직이 허용한 위험 - 과거 판단의 선례(precedent) ## 정밀도와 재현율을 함께 측정 - **정밀도(precision)**: - 에이전트가 보고한 결과 중 실제 취약점의 비율이다. - 높을수록 오탐(false positive)이 적다. - **재현율(recall)**: - 실제 존재하는 취약점 중 에이전트가 찾아낸 비율이다. - 높을수록 미탐(false negative)이 적다. - 취약점을 많이 보고하는 것만으로는 충분하지 않다. - 오탐이 많으면 개발자가 도구의 결과를 무시하게 된다. - 반대로 정밀도만 높이고 탐지 범위를 줄이면 중요한 취약점을 놓칠 수 있다. ## PR 리뷰를 먼저 구축한 이유 Figma는 코드 생성이나 전체 저장소 감사보다 개선 주기가 빠른 PR 리뷰부터 만들었다. - **보편성**: 모든 PR이 리뷰 대상이 된다. - **셀프서비스 구조**: 에이전트가 PR에 직접 댓글을 달고, 작성자가 해당 결과에 답변한다. - **양방향 측정**: - 정밀도는 작성자의 thumbs up/down 평가와 설명으로 측정한다. - 재현율은 이미 취약점이 있었던 커밋에 리뷰어를 다시 실행해 놓친 문제를 세는 방식으로 측정한다. - 이렇게 수집한 피드백은 에이전트가 따르는 보안 정책 개선에 반영된다. ## 여러 모델을 병렬로 사용 - Figma는 서로 다른 취약점을 놓치는 모델을 함께 사용한다. - Claude Code의 Opus 4.8, xhigh 노력 수준 - Codex의 GPT-5.6 Sol, high 노력 수준 - 어느 한 모델이라도 문제를 보고하면 결과를 상위 단계로 전달한다. - PR 하나의 리뷰 비용은 중앙값 약 0.50달러이며, 대부분의 PR에는 보고할 문제가 없어 비용이 크게 증가하지 않는다. - Figma는 이 비용이 버그 바운티 지급이나 사용자 피해를 예방하는 효과에 비해 충분히 낮다고 판단한다. ## 실제로 탐지한 취약점 사례 - 복잡한 취약점: - 주입된 샌드박스 객체가 호스트 영역의 `Function` 생성자에 접근할 수 있음을 추론했다. - 이를 통해 데스크톱 클라이언트에서 코드 실행으로 이어지는 경로를 찾아냈다. - 일반적인 접근 제어 취약점: - 송장 조회 API가 호출자가 전달한 송장 ID만 확인하고 소속 조직을 검증하지 않았다. - 인증된 사용자가 ID만 알면 다른 조직의 송장을 읽을 수 있는 IDOR(Insecure Direct Object Reference) 문제였다. - 해결책은 송장 조회 시 인증된 사용자의 조직에 속하는지 함께 확인하는 것이다. ## 초기 도입과 신뢰 확보 - Anthropic이 Claude Code Security Reviewer를 공개한 2025년 8월, Figma는 즉시 도입했다. - 처음에는 개발자 PR 댓글이 아닌 Slack과 Datadog로만 결과를 보내는 shadow mode로 운영했다. - 리뷰어는 두 단계로 동작했다. - 잠재적 취약점 탐색 - 적대적 검토를 통한 오탐 필터링 - 실제 보안 사고를 재현했을 때 근본 원인을 거의 그대로 찾아냈고, 애플리케이션 보안과 인프라 설정 오류 등 여러 영역에도 잘 일반화됐다. - 그러나 첫 주에는 27개 결과 중 4개만 유효해 정밀도가 약 15%에 불과했다. - Figma는 개발자에게 노출하기 위한 기준으로 70% 정밀도를 설정했다. - 10개 중 7개가 유효해야 개발자가 결과를 읽을 것이라는 실용적 기준이다. - 2주간의 관찰 기간 동안 정밀도가 70% 이상이고 심각한 오탐이 없을 때까지 PR 댓글을 보류했다. - 이를 위해 최근 8주간의 PR에 리뷰어를 다시 실행하고, 보안팀이 오탐을 직접 분류했다. - 과거 사례를 기반으로 에이전트가 따라야 할 정책을 작성했다. - 여기서 **선례(precedent)**는 특정 상황에서 어떤 보고가 유효하거나 유효하지 않은지 설명하는 구체적인 사례다. ## 실용적인 결론 AI 보안 에이전트를 도입할 때는 처음부터 모든 개발자에게 결과를 노출하기보다 shadow mode로 운영하며 정밀도를 먼저 확보하는 것이 좋다. 모든 PR에 적용하고, 사람의 결과 평가와 알려진 취약점 재검증을 분리해 수집하면 신뢰성과 탐지력을 함께 개선할 수 있다.

원문 읽기(새 탭에서 열림)
AI 에이전트코드 리뷰claude-codemonorepo+3
github4분 읽기큐레이션 요약

Copilot vs. 직접 API 접근: 실제로 무엇에 비용을 지불하고 있나요?

같은 AI 모델을 사용하더라도 GitHub Copilot과 원시 API는 서로 다른 계층의 문제를 해결한다. Copilot은 이슈부터 코드 수정, 테스트, 풀 리퀘스트와 조직 정책 적용까지 연결된 개발 워크플로를 제공하고, 원시 API는 프롬프트·검색·라우팅·보안·로그·과금 등을 직접 설계하는 시스템 구축용 기반이다. 따라서 비용과 선택 기준은 토큰 단가만이 아니라 팀이 직접 소유하고 운영해야 하는 작업의 범위에 따라 결정된다. ## GitHub Copilot은 모델을 둘러싼 개발 도구 - Copilot의 모델 호출은 개발 작업 전체 중 한 단계에 불과하다. - 일반적인 유지보수 작업에는 다음 요소가 함께 필요하다. - GitHub Issue 분석 - 저장소와 관련 파일 탐색 - 코드 수정 및 diff 생성 - 저장소 지침과 허용된 명령 반영 - 터미널에서 테스트 실행 - Pull Request 생성 및 리뷰 - 조직의 보안·사용 정책 적용 - Copilot은 에디터, 저장소, 이슈, PR, 터미널, 조직 관리 기능을 하나의 흐름으로 연결한다. - 유료 플랜에서는 코드 자동 완성과 Next Edit Suggestions가 계속 포함되며, 더 많은 리소스를 사용하는 채팅·에이전트 작업에는 AI Credits가 적용된다. - 실제 작업 비용은 모델의 토큰 단가 외에도 다음 요인에 영향을 받는다. - 선택된 컨텍스트의 양 - 도구 호출 횟수 - 실패에 따른 재시도 - 이슈에서 리뷰 완료 PR까지 이어지는 전체 작업 경로 - 조직 플랜은 AI Credits를 조직 단위로 공유하고, 관리자가 예산과 사용량을 대시보드에서 추적할 수 있다. ## 원시 API는 직접 소유하는 시스템을 위한 기반 - API 직접 호출은 다음과 같은 시스템을 만들 때 적합하다. - 제품 기능에 포함되는 AI 기능 - 사내 에이전트 플랫폼 - 모델 평가·벤치마크 도구 - 자동화 파이프라인 - 개발자가 직접 결정할 수 있는 항목이 많다. - 프롬프트 구성 - 문서 및 코드 검색 방식 - 모델 라우팅 - 실패한 도구 호출의 재시도 정책 - 로그와 추적 데이터 저장 - 인증 정보와 보안 경계 - 과금 및 사용량 관리 - 예를 들어 사내 에이전트가 특정 태그의 이슈를 읽고, 회사 문서를 검색하고, 별도 시스템에 변경 요청을 만들며, 감사 기록까지 남긴다면 자체 데이터 경계·이벤트 트리거·승인 절차가 필요하다. - API는 이런 요구사항을 구현할 수 있는 기본 요소를 제공하지만, 저장소 파일을 어떻게 검색하고 에이전트 권한을 어디까지 허용할지는 개발자가 설계해야 한다. ## 에이전트 SDK는 두 계층 사이의 선택지 - 에이전트 SDK는 모델 API와 완성된 개발 도구 사이에서 오케스트레이션을 담당한다. - 일반적으로 다음 기능을 제공한다. - 도구 사용 - 세션 관리 - 스트리밍 응답 - 에이전트 실행 흐름 제어 - SDK에 따라 특정 제공업체에 종속되거나 여러 모델 제공업체를 지원할 수 있다. - GitHub Copilot SDK는 Copilot CLI를 구동하는 에이전트 런타임을 노출해, 직접 처음부터 에이전트 하네스를 만들지 않고도 검증된 실행 환경을 임베드할 수 있게 한다. - 이 런타임은 Copilot 구독 또는 사용자의 자체 provider key로 실행할 수 있다. ## BYOK: Copilot 워크플로와 모델 비용을 분리 - Copilot의 BYOK(Bring Your Own Key)는 지원되는 외부 모델을 Copilot Chat, Copilot CLI, VS Code에서 사용할 수 있게 한다. - 지원 제공업체에는 다음이 포함된다. - Anthropic - AWS Bedrock - Google AI Studio - Microsoft Foundry - OpenAI 및 OpenAI 호환 제공업체 - xAI - 모델은 Copilot의 하네스와 GitHub가 유지하는 통합 기능을 사용하지만, 토큰 비용은 사용자가 연결한 제공업체에 청구된다. - 기존 클라우드 계약이나 약정된 사용량이 있는 팀은 해당 계약을 유지하면서도 개발자는 익숙한 Copilot 환경을 사용할 수 있다. - Copilot CLI에서는 Azure OpenAI, Anthropic, 로컬 Ollama 모델 등도 사용할 수 있다. - BYOK는 글 작성 시점에 공개 프리뷰이므로 구매나 아키텍처 결정을 내리기 전에 최신 GitHub 문서를 확인해야 한다. - 엔터프라이즈와 조직 관리자는 GitHub 호스팅 모델과 BYOK 모델을 포함해 팀에서 사용할 모델을 정책으로 제한할 수 있다. ## 상황에 따른 선택 기준 - **원시 API를 선택할 때** - 자체 제품이나 내부 시스템에 AI를 통합해야 할 때 - 사용자 정의 프롬프트·검색·라우팅이 필요할 때 - 보안, 감사, 승인, 로그, 과금 체계를 직접 통제해야 할 때 - **GitHub Copilot을 선택할 때** - 개발자가 GitHub와 IDE 안에서 코드를 작성하고 리뷰할 때 - 이슈부터 PR, 테스트, 보안 정책까지 연결된 흐름이 중요할 때 - 조직 차원의 사용량·예산·모델 정책 관리가 필요할 때 - **BYOK를 고려할 때** - Copilot의 개발 워크플로는 유지하면서 특정 외부 모델이나 기존 클라우드 계약을 사용해야 할 때 실용적으로는 팀의 개발 생산성 향상이 목적이면 Copilot을, 독자적인 AI 제품이나 자동화 시스템 구축이 목적이면 원시 API를 우선 검토하는 것이 적절하다. 두 요구가 모두 있다면 Copilot 또는 Copilot SDK에 BYOK를 결합하는 방식도 선택지가 된다.

원문 읽기(새 탭에서 열림)
대규모 언어 모델github-copilotAPIagentic-workflows+4
github3분 읽기큐레이션 요약

다음 장: GitHub 버그 바운티 프로그램 개편

GitHub은 버그 바운티 프로그램을 대량 제출보다 고품질·고영향 보안 연구 중심으로 재편한다. 이를 위해 우수 연구자 대상의 영구 VIP 프로그램을 도입하고, 공개 프로그램의 보상 체계와 제출 요건을 변경한다. 새 기준은 2026년 7월 27일 이후 제출된 보고서부터 적용된다. ## 프로그램 개편 배경 - 신규 연구자와 기존 연구자의 제출량 증가로 보고서 처리 대기열이 길어졌다. - 저품질 보고서와 AI로 생성된 보고서가 늘어나면서 중요한 취약점에 집중하기 어려워졌다. - GitHub은 “더 많이 제출할수록 더 많은 보상”이 아니라 “더 나은 취약점을 제출할수록 더 많은 보상”을 제공하는 방향을 택했다. ## 영구 VIP 프로그램 도입 - 지속적으로 고품질·고영향 취약점을 제보한 연구자를 위한 비공개 초대형 프로그램이다. - VIP 연구자에게는 다음 혜택이 제공된다. - 더 높은 보상금 - 더 빠른 응답 - GitHub 보안 엔지니어링 팀과의 긴밀한 협업 - VIP 보상 기준: - Low: **1,000달러** - Medium: **7,500달러** - High: **20,000달러** - Critical: **30,000달러 이상** - 다음 조건 중 하나 이상을 달성하면 VIP 자격을 얻을 수 있다. - Critical 취약점 1건 - High 취약점 2건 - Medium 취약점 4건 - Low 취약점 7건 - 구체적인 자격 기준은 GitHub의 공개 HackerOne 페이지에 게시될 예정이다. ## 공개 버그 바운티 보상 변경 - 공개 프로그램의 보상금은 다음과 같이 고정 금액으로 변경된다. - Low: **250달러** - Medium: **2,000달러** - High: **5,000달러** - Critical: **10,000달러** - 기존의 보상 범위 대신 심각도별 단일 금액을 사용한다. - 고정 금액은 연구자에게 예상 가능한 보상을 제공하고, GitHub의 내부 검토 부담과 불확실성을 줄이기 위한 조치다. - 기대 이상의 연구에는 별도의 재량 보너스가 지급될 수 있다. - 공개 프로그램은 신규 연구자가 탐색하고 실적을 쌓은 뒤 VIP 프로그램으로 진입하는 역할을 계속한다. ## 공개 제출에 신호 요건 적용 - 공개 프로그램에 HackerOne의 신호(signal) 요건이 도입된다. - 아직 충분한 실적이 없는 연구자는 제출 횟수가 제한된다. - HackerOne은 기준 미달 연구자에게 최대 **4회의 초기 제출 기회**를 제공한다. - 이는 신규 연구자를 배제하기 위한 장벽이 아니라, 실제 보안 연구 역량을 확인하고 저노력·AI 생성 보고서를 줄이기 위한 최소 기준이다. ## 유지되는 원칙과 적용 시점 - GitHub은 실제 보안 연구에 대한 신속한 보상과 명확한 커뮤니케이션을 계속 유지한다고 밝혔다. - 변경 시행 전에 제출된 보고서는 기존 보상 체계로 처리된다. - **2026년 7월 27일 이후 제출된 보고서**부터 새로운 보상 및 운영 구조가 적용된다. - 향후에는 응답 속도 개선, 심각도 판정 근거 명확화, 보안 커뮤니티와의 소통 확대도 추진한다. 이번 개편에 참여하려는 연구자는 단순히 보고서 수를 늘리기보다 재현 가능한 검증 절차, 명확한 영향 분석, 높은 심각도의 독창적인 취약점에 집중하는 것이 유리하다. 신규 연구자는 제한된 초기 제출 기회를 활용해 정확하고 완성도 높은 보고서를 제출하는 전략이 중요하다.

원문 읽기(새 탭에서 열림)
vulnerability-managementapplication-securitybug-bountyhackerone+2
datadog4분 읽기큐레이션 요약

JDK 25에서 JFR을 활용한 편향 없는 Java CPU 프로파일링

Java Flight Recorder(JFR)는 저부하·상시 운영에 적합한 강력한 진단 도구지만, CPU 사용량을 정확히 반영해야 하는 프로파일링에서는 한계가 있다. 특히 `ExecutionSample`은 실제 CPU 시간에 비례해 샘플링하지 않아 CPU 집약적이거나 리액티브한 애플리케이션의 핫스팟을 과소·과대평가할 수 있다. 따라서 현대 프로파일러는 JFR의 안정성과 `AsyncGetCallTrace`·JVMTI 기반 샘플링의 정확성을 결합해 사용하며, 장기적으로는 JVM이 공식 지원하는 CPU 프로파일링 이벤트가 필요하다는 것이 글의 결론이다. ## 연속 프로파일링의 기본 원리 - 프로파일러는 일정 시간 동안 스택 트레이스를 반복 수집하고 집계해 애플리케이션의 동작 패턴을 파악한다. - 샘플링 시점은 프로파일러마다 다르다. - CPU 시간 기반: 실제로 스레드가 CPU를 사용하는 동안만 시간이 증가한다. - 벽시계 시간 기반: 실행, 대기, I/O, 락 대기 등 모든 경과 시간을 포함한다. - CPU 시간 프로파일링은 연산 핫스팟을 찾는 데 적합하다. - 예: 무한 루프나 계산 집중 메서드 - 벽시계 시간 프로파일링은 지연 원인을 찾는 데 유용하다. - 예: 느린 데이터베이스 쿼리, 락 대기, I/O - 메모리 할당, 락 경합, 스레드 파킹, GC 등 특정 이벤트를 기준으로 스택을 수집하는 방식도 있다. - 어떤 이벤트를 사용하든 핵심은 “이벤트가 발생했을 때 어떤 코드가 실행 중이었는가”를 스택으로 기록하고 누적하는 것이다. ## JFR `ExecutionSample`의 장점과 한계 - JFR은 JVM에 내장되어 있으며 GC, 클래스 로딩, 스레드 스케줄링, 메모리 할당 등 다양한 런타임 이벤트를 구조화해 제공한다. - 낮은 오버헤드로 상시 실행할 수 있어 운영 환경에 적합하다. - CPU 프로파일링에는 `ExecutionSample` 이벤트가 사용된다. - 그러나 `ExecutionSample`은 운영체제 수준에서 실제 CPU 시간을 직접 기준으로 샘플링하지 않는다. - JVM이 관찰한 실행 가능 스레드 중 일부를 순환하며 샘플링한다. - CPU를 많이 사용하는 스레드가 더 자주 나타날 수는 있지만, 실제 CPU 사용량에 정확히 비례하지는 않는다. - CPU가 포화된 환경이나 리액티브 애플리케이션에서는 스레드 스케줄링 특성 때문에 특정 CPU 핫스팟이 충분히 나타나지 않을 수 있다. - 결과적으로 프로파일이 틀렸다기보다는 데이터가 불완전해져 원인 분석 시간이 길어질 수 있다. ## `AsyncGetCallTrace`를 이용한 CPU 샘플링 - JVMTI 에이전트와 운영체제 신호인 `SIGPROF`를 사용하면 CPU 시간에 기반해 샘플링할 수 있다. - 신호가 발생한 스레드 안에서 HotSpot의 `AsyncGetCallTrace`를 호출해 비동기적으로 Java 스택을 추적한다. - 이 방식은 세이프포인트 편향을 피하고 JFR에 정의된 이벤트가 아닌 임의의 CPU 이벤트에서도 스택을 수집할 수 있다. - `async-profiler` 같은 도구가 이 접근법을 널리 확산시켰다. - 실제 CPU 사용량에 가까운 결과를 제공하므로 CPU-bound 작업 분석에 특히 효과적이다. ## 내부 JVM API 의존성 문제 - `AsyncGetCallTrace`는 공식 공개 API가 아니라 HotSpot 내부 메커니즘이다. - OpenJ9, Zing 등 다른 JVM에서도 지원되지만 안정적인 표준 인터페이스로 설계된 것은 아니다. - 높은 부하나 특수한 상황에서는 오류를 일으킬 가능성이 있어 프로파일러가 JVM 장애를 방지하기 위한 방어 로직을 추가해야 한다. - Datadog 프로파일러는 다음 방식을 조합한다. - JFR: 안정적인 런타임 텔레메트리 수집 - `AsyncGetCallTrace`: 정확한 Java CPU 스택 샘플링 - `vmstructs` 워킹: JVM 내부 메타데이터를 직접 읽어 스택과 런타임 상태 복원 - `vmstructs`는 표준 API가 노출하지 않는 정보를 얻을 수 있지만, 역시 JVM 내부 구조에 의존한다. - 따라서 프로파일러 제작자는 다음과 같은 절충을 해야 한다. - JFR만 사용하면 안전하지만 CPU 샘플링 정확도가 떨어질 수 있다. - 내부 API를 사용하면 정확하지만 JVM 안정성과 유지보수 부담이 커진다. - 실제 상용 프로파일러들은 대체로 두 방식을 함께 사용한다. ## JVM 프로파일링 기반을 개선하려는 움직임 - Datadog, SAP, Amazon, OpenJDK 커뮤니티는 이 문제가 특정 회사만의 문제가 아니라는 데 공감했다. - JFR은 이미 운영 환경용 프로파일링 기반으로 적합하지만, 정확한 CPU 샘플링을 위한 공식 이벤트가 부족했다. - 기존 생태계가 비공개·비공식 HotSpot API에 의존하는 것은 장기적으로 바람직하지 않다. - 글에서는 이러한 한계를 해결하기 위해 JVM에 안전성과 정확성을 모두 갖춘 “일급 CPU 프로파일링 이벤트”를 추가하려는 협력 과정을 소개한다. - 제공된 원문은 OpenJDK 논의와 새 이벤트의 구체적인 설계 설명이 시작되는 부분에서 중단되어 있다. 운영 환경에서는 JFR만으로 CPU 병목을 단정하기보다, CPU 시간 기반 샘플링을 지원하는 프로파일러를 함께 사용하는 것이 좋다. 다만 JVM 내부 API 의존성은 안정성 위험을 동반하므로, 장기적으로는 공식 JFR CPU 프로파일링 이벤트가 제공되는 JVM과 프로파일러를 선택하는 것이 바람직하다.

원문 읽기(새 탭에서 열림)
Javajvmcpu-profilingjava-flight-recorder+3
gitlab4분 읽기큐레이션 요약

Cursor와 GitLab으로 Java 현대화하기

Java 8에서 21로의 현대화는 단순한 버전 업그레이드가 아니라 빌드·런타임·의존성·API·동시성·테스트·컨테이너·운영 동작을 함께 다루는 복합 작업이다. 따라서 Cursor로 모든 변경을 한 번에 수행하기보다, 작은 문제를 단계적으로 해결하고 GitLab의 이슈 계층, CI/CD, 보안 검사, 코드 리뷰, 영향 분석으로 안전성을 검증해야 한다. 글은 실패한 테스트 수정에서 시작해 품질 게이트를 마련하고, 특정 HTTP 연결 경계를 Java 21 방식으로 현대화하는 흐름을 제시한다. ## Cursor와 GitLab의 역할 분담 - Cursor는 코드베이스 안에서 다음과 같은 집중 작업에 적합하다. - 실패한 테스트의 원인 추적 - 구현 코드와 테스트 분석 - 제한된 범위의 수정안 작성 - 로컬 테스트 실행 - 브랜치와 머지 리퀘스트 생성 - GitLab은 AI가 만든 변경을 소프트웨어 개발 생명주기 안에서 검증하는 역할을 한다. - Epic과 하위 이슈로 현대화 계획을 지속적이고 검토 가능하게 관리 - GitLab MCP 서버로 이슈, 논의, 파이프라인, 의존성 등 프로젝트 문맥을 Cursor에 제공 - CI/CD, 보안 스캔, 코드 리뷰, 코드 소유자 승인, 영향 분석 수행 - Duo Agent Platform의 Code Review Flow와 Developer Flow로 프로젝트별 품질 기준 적용 - AI 에이전트의 속도 자체가 안전성을 보장하지 않으므로, 모든 에이전트 생성 머지 리퀘스트도 일반 변경과 동일한 검증 절차를 거쳐야 한다. ## 예제 시스템과 현대화 범위 - 대상은 Tanuki IoT Platform의 Java HTTP metrics collector다. - 이 컴포넌트는 다음 작업을 수행한다. - 상태 점검 및 유지보수 HTTP 엔드포인트에 `GET` 요청 - 응답 상태와 응답 시간 등의 메트릭 기록 - Rust 기반 metrics-store 백엔드에 `POST /api/metrics` 요청 - 백엔드의 HTTP 응답을 확인 - Java 애플리케이션과 Rust 백엔드 사이의 실제 HTTP 계약이 존재하므로, Java 런타임 현대화가 운영 경계에 미치는 영향을 테스트할 수 있다. - 환경에는 Java 8과 Java 21, Maven, Docker, Docker Compose, GitLab MCP 서버가 필요하다. - 저장소의 `AGENTS.md`에는 프로젝트 구조와 Maven 테스트 명령이 있어 Cursor가 로컬 개발 규칙을 따르는 데 활용된다. ## 실패한 엔드투엔드 테스트 수정 - 문제는 엔드포인트의 기대 HTTP 상태 코드 처리에서 발생한다. - 사용자는 특정 상태 코드를 기대하도록 설정할 수 있다. - 구현은 모든 `2xx` 응답만 성공으로 간주한다. - 따라서 `503`을 정상적인 기대값으로 설정해도 테스트가 실패한다. - 엔드투엔드 테스트는 이미 문제를 드러내고 있었지만 CI/CD 작업이 `allow_failure` 상태여서 실패가 지속적인 경고음으로만 남아 있었다. - Cursor에는 관찰 가능한 문제를 직접 설명하고 다음 순서로 작업하도록 요청한다. - 먼저 분석 작성 - 구현과 실패 테스트 추적 - 수정 적용 - 테스트 재실행 - Cursor는 엔드포인트 설정에서 `HttpCollector`와 실패한 엔드투엔드 테스트까지 경로를 추적해 불일치의 원인을 찾는다. - 집중 테스트와 전체 Maven 테스트가 통과한 뒤 브랜치와 머지 리퀘스트를 만든다. - 테스트가 결정적이고 안정적으로 통과하면, 기존에 실패를 허용하던 엔드투엔드 작업을 필수 검증 단계로 전환할 수 있다. ## 머지 리퀘스트 기반 검증 - 머지 리퀘스트 생성 후 자동으로 다음 검증이 실행된다. - 빌드 - 단위 및 통합 테스트 - 엔드투엔드 테스트 - 보안 스캔 - GitLab Duo Code Review는 프로젝트의 Java 전용 리뷰 지침에 따라 변경을 검토한다. - 리뷰에서 구체적인 문제가 발견되면 Developer Flow를 통해 수정한 뒤 병합한다. - 머지 리퀘스트는 단순한 결과물 제출 수단이 아니라 다음을 수행하는 협업·의사결정 공간이다. - 변경 의도 설명 - 테스트 및 파이프라인 결과 확인 - 리뷰 의견 처리 - 에이전트가 만든 코드의 품질 증거 축적 - 이 단계에서 실제 버그를 런타임 마이그레이션과 섞지 않고 먼저 수정함으로써, 이후 현대화 작업의 행동 기준선과 회귀 방지 테스트를 확보한다. ## Java 8에서 Java 21로 넘어가기 위한 품질 게이트 - Java 21 현대화는 앞선 테스트 버그 수정과 달리 훨씬 넓은 범위를 가진다. - 기존 Java modernization epic에는 다음과 같은 계획 문맥이 포함되어 있다. - 하위 작업 항목 - 팀 논의 - 조사 결과와 관련 머지 리퀘스트 - 과거 파이프라인 기록 - 의존성 정보 - 보안 취약점 및 관련 발견 사항 - 이러한 정보를 Cursor에 제공하면 단순히 소스 코드를 바꾸는 것이 아니라 프로젝트의 개발 이력과 운영 제약을 반영한 변경 계획을 세울 수 있다. - 글의 접근 방식은 전체 마이그레이션을 한 번에 수행하지 않고, 먼저 품질 게이트를 마련한 뒤 영향 범위가 명확한 경계부터 현대화하는 것이다. ## 실용적인 적용 순서 - 먼저 하나의 실패한 테스트나 제한된 버그를 선택한다. - Cursor로 원인 분석, 수정, 테스트 실행을 수행한다. - 변경을 작은 머지 리퀘스트로 제출하고 CI/CD와 자동 리뷰를 통과시킨다. - 그다음 Epic과 이슈, MCP를 통해 Java 21 마이그레이션의 전체 문맥을 연결한다. - 모든 테스트, 보안 검사, 코드 소유자 승인, 영향 분석 결과를 품질 게이트로 사용한다. - 마지막으로 HTTP 연결 처리처럼 하나의 경계를 골라 현대화하고, Java 애플리케이션과 Rust 백엔드 사이의 실제 계약이 유지되는지 검증하는 것이 안전하다.

원문 읽기(새 탭에서 열림)
CI/CDgitlab모델 컨텍스트 프로토콜Docker & 컨테이너+4