techlist.io
KREN

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

aws4분 읽기큐레이션 요약

AWS 주간 요약: AWS Transform 출시 1주년, AWS의 Claude 플랫폼, EC2 M3 Ultra Mac 인스턴스 등 (2026년 5월 18일) | Amazon Web Services

AWS는 기업 애플리케이션 현대화를 위한 AWS Transform을 출시 1년 만에 대규모 코드·서버 마이그레이션 서비스로 확장했으며, Kiro·Claude·Cursor·Codex에서도 Transform 에이전트를 사용할 수 있게 했다. 이번 주에는 Claude Platform의 AWS 정식 출시, 고성능 EC2 M3 Ultra Mac 인스턴스, Graviton 기반 Redshift RG 인스턴스 등 AI·개발·데이터 분석 관련 기능이 다수 공개됐다. 또한 보안 코드 분석, 멀티클라우드 연결, AI 연구 지원과 스타트업 크레딧 등 개발자와 기업을 위한 생태계 지원도 강화됐다. ## AWS Transform 출시 1년과 에이전트 확장 - AWS Transform은 .NET, 메인프레임, VMware 워크로드의 대규모 현대화를 지원하는 에이전트 기반 서비스다. - AWS Transform custom을 통해 다음 작업을 AWS 관리형 또는 사용자 정의 변환으로 수행할 수 있다. - 프로그래밍 언어 버전 업그레이드 - 프레임워크 마이그레이션 - 성능 최적화 - 코드베이스 분석 - Windows 전체 스택 현대화, 메인프레임 Reimagine 기능, 자동화된 테스트 기능도 추가됐다. - 1년 동안 수천 개 고객이 수십만 대의 서버를 마이그레이션했으며, 160만 시간 이상을 절감하고 45억 줄 이상의 코드를 처리했다. - AWS Transform 에이전트는 Kiro, Claude, Cursor, Codex에서 사용할 수 있고, Kiro의 에이전트 빌더 툴킷으로 맞춤형 변환 에이전트를 만들 수 있다. ## Claude Platform on AWS 정식 출시 - Anthropic의 네이티브 Claude Platform을 기존 AWS 계정에서 직접 이용할 수 있다. - 별도의 계정, 결제 체계, 사용량 추적을 관리할 필요가 없다. - Claude API와 콘솔, 얼리 액세스 베타 기능을 제공한다. - 서비스 운영 주체는 Anthropic이며, 고객 데이터는 AWS 보안 경계 외부에서 처리된다는 점에 유의해야 한다. ## EC2 M3 Ultra Mac 인스턴스 - Apple M3 Ultra Mac Studio 기반의 EC2 인스턴스로, Apple 애플리케이션 개발과 온디바이스 머신러닝 작업을 대상으로 한다. - 주요 사양: - 28코어 CPU - 60코어 GPU - 32코어 Neural Engine - 256GB 통합 메모리 - 이전 세대 M4 Max Mac 인스턴스와 비교하면 통합 메모리는 2배, CPU 코어는 1.75배, GPU 코어는 1.5배, Neural Engine 코어는 2배다. - 더 많은 Xcode 시뮬레이터를 병렬 실행하고 ML 워크로드를 가속해 제품 출시 시간을 단축할 수 있다. ## Graviton 기반 Amazon Redshift RG 인스턴스 - AWS Graviton 프로세서를 사용하는 Redshift RG 인스턴스가 출시됐다. - 기존 RA3 인스턴스보다 데이터 웨어하우스와 데이터 레이크 워크로드를 최대 2.4배 빠르게 처리한다. - vCPU당 가격은 이전 세대보다 30% 낮다. - 클러스터 노드에서 Apache Iceberg 및 Parquet 데이터를 처리하는 자체 벡터화 데이터 레이크 쿼리 엔진을 포함한다. ## Bedrock 프롬프트 최적화 - Amazon Bedrock의 모든 모델에 대해 프롬프트를 최적화할 수 있다. - 원래 프롬프트와 최적화된 프롬프트의 결과를 최대 5개 모델에서 동시에 비교할 수 있다. - 모델을 교체하거나 현재 모델의 응답 품질과 성능을 개선하려는 경우 유용하다. ## AWS Security Agent의 전체 저장소 분석 - AWS Security Agent가 저장소 전체를 대상으로 문맥을 고려한 심층 보안 분석을 수행한다. - 취약점을 발견하면 정확한 파일과 코드 줄에 연결된 구체적인 수정 코드를 생성한다. - 기존 AWS Security Agent 고객은 프리뷰 기간 동안 추가 비용 없이 사용할 수 있다. ## OCI와의 멀티클라우드 연결 - AWS Interconnect를 사용해 Oracle Cloud Infrastructure와 탄력적이고 확장 가능한 프라이빗 연결을 빠르게 구성할 수 있다. - 동일한 개방형 사양을 기반으로 OCI와 Google Cloud를 지원한다. - Google Cloud 연결은 정식 제공 중이며, Microsoft Azure 연결은 2026년 후반 제공될 예정이다. ## AI 연구 및 개발자 생태계 지원 - AWS는 대학 연구자들이 Trainium 칩을 사용할 수 있도록 1억 1,000만 달러를 투자했다. - UC Berkeley, MIT, Carnegie Mellon 등에서 Trainium 기반 AI 연구가 진행되고 있다. - 연구 결과는 오픈 소스로 공개되어 관련 개선 사항이 개발자 커뮤니티에 공유된다. - AWS Community Days 2026이 전 세계 여러 도시에서 개최된다. - Kiro Startups Credit 프로그램이 재개되어, 선정된 스타트업은 AWS 계정에서 최대 1년간 Kiro Pro+ 크레딧을 받을 수 있다. 실무적으로는 AWS Transform을 기존 레거시 현대화 계획과 검토하고, Claude Platform 사용 시 데이터 처리 경계를 확인하는 것이 좋다. Apple 개발팀은 M3 Ultra Mac의 병렬 시뮬레이터 성능을, 데이터팀은 Redshift RG의 성능 대비 비용을 각각 워크로드 기준으로 평가할 만하다.

원문 읽기(새 탭에서 열림)
amazon-bedrockamazon-ec2claudeapache-iceberg+3
grammarly4분 읽기큐레이션 요약

영업 통화 후 후속 이메일 작성 방법과 템플릿

영업 후속 이메일은 통화 내용을 재확인하고 추가 가치를 제공해 거래를 다음 단계로 진전시키는 메시지다. 효과적인 이메일은 구체적인 제목, 대화 맥락을 담은 도입부, 핵심 내용 요약과 추가 가치, 명확한 다음 행동 요청으로 구성된다. 첫 이메일은 통화 후 2시간 이내에 보내고, 이후에는 새로운 정보나 관점을 더해 일정 간격으로 후속 연락해야 한다. ## 영업 후속 이메일의 목적 - 단순히 “잘 지내시나요?”라고 확인하는 메일이 아니라, 실제 거래와 직접 연결된 커뮤니케이션이다. - 통화에서 논의한 문제와 목표를 다시 강조한다. - 미해결 질문에 답하고, 사례·자료·인사이트 등 추가 가치를 제공한다. - 합의된 다음 단계를 명확히 제시해 거래의 추진력을 유지한다. - 통화 이후 후속 조치가 약하면 좋은 통화도 거래 중단으로 이어질 수 있다. ## 효과적인 이메일 작성 구조 ### 통화 내용을 검토하고 목표 정하기 - 이메일을 쓰기 전에 통화 기록을 다시 확인한다. - 한 이메일에는 하나의 명확한 목표만 둔다. - 목표의 예: - 데모 일정 확정 - 가격 논의 진행 - 의사결정권자와의 미팅 예약 - 제안서나 자료 검토 요청 - 요청이 하나로 제한되면 상대방이 무엇을 해야 하는지 쉽게 이해하고 빠르게 답할 수 있다. ### 구체적인 제목 작성 - 제목은 짧고 모바일에서도 쉽게 읽히며, 통화 내용과 직접 관련되어야 한다. - 활용할 수 있는 방식: - 통화 언급: “[이름]님, 오늘 통화 후 다음 단계” - 가치 강조: “간단한 요약과 말씀드린 사례 연구” - 특정 주제 언급: “[특정 주제]에 대한 후속 안내” - 무응답 후 재접촉: “[주요 문제]에 대한 후속 연락” - “그냥 확인차 연락드립니다”처럼 내용과 목적이 불분명한 표현은 피한다. - 창의적인 표현보다 명확성과 관련성이 중요하다. ### 맥락을 담은 도입부 - 첫 한두 문장에서 통화 주제와 연락 목적을 상기시킨다. - 예: “오늘 팀의 온보딩 문제에 대해 이야기 나눌 수 있어 좋았습니다. 논의한 핵심 내용을 간단히 정리해 보내드립니다.” - “말씀드린 대로”, “그냥 후속 연락드립니다” 같은 상투적인 문구만 사용하는 것은 피한다. - 상대방이 언제, 왜 이 메일을 받았는지 즉시 알 수 있어야 한다. ### 핵심 내용 요약과 추가 가치 제공 - 상대방의 주요 문제, 목표, 약속한 사항 중 거래에 중요한 내용만 두세 문장으로 요약한다. - 통화 내용을 그대로 반복하기보다 상대방이 중요하게 여긴 구체적인 발언을 반영한다. - 이름만 바꾸는 일반 템플릿보다 다음과 같은 개인화가 효과적이다. - 상대방이 언급한 운영상의 문제 - 달성하려는 목표 - 현재 사용 중인 프로세스의 한계 - 요약 뒤에는 새로운 가치를 하나 추가한다. - 관련 사례 연구 - 통화 중 답하지 못한 질문에 대한 답변 - 참고 자료나 제안서 - 문제 해결을 위한 구체적인 인사이트 - 예를 들어 온보딩 지연을 언급했다면, 유사한 기업이 온보딩 시간을 30% 줄인 사례를 함께 제공할 수 있다. ### 명확한 다음 단계 제시 - 이메일 마지막에는 하나의 구체적인 행동 요청만 둔다. - “어떻게 생각하시는지 알려주세요”처럼 모호한 요청은 피한다. - 대신 다음과 같이 답하기 쉬운 요청을 사용한다. - “화요일 오후 2시에 데모를 진행해도 될까요?” - “이번 주 목요일과 금요일 중 어느 시간이 편하신가요?” - “의사결정권자와 함께 30분간 논의할 수 있을까요?” - 가능하면 통화 중 합의한 내용과 연결해 자연스러운 다음 단계로 만든다. - 선택지를 좁히거나 예·아니오로 답할 수 있게 하면 응답 부담이 줄어든다. ### 발송 전 검토 - 맞춤법, 문법, 문장 명확성을 확인한다. - 이메일이 전문적이고 자신감 있으며 도움을 주는 어조인지 점검한다. - 한 번은 정확성을, 두 번째는 수신자 입장에서 자연스럽게 읽히는지를 확인한다. - 작은 오류도 신뢰도와 전문성에 영향을 줄 수 있다. ## 발송 시점과 후속 연락 간격 - 첫 후속 이메일은 통화 후 2시간 이내, 늦어도 같은 영업일 안에 보낸다. - 통화 내용이 아직 상대방의 기억에 남아 있을 때 보내야 추진력을 유지할 수 있다. - 일반적인 후속 일정은 다음과 같다. - 당일: 통화 후 2시간 이내 첫 이메일 발송 - 3~5일 후: 답장이 없으면 새로운 인사이트나 자료와 함께 재연락 - 약 1주일 후: 짧고 부담이 적은 최종 연락 - 통화 중 일정이 정해졌다면 일반적인 cadence보다 그 일정을 우선한다. - 상대방의 근무 일정에 따라 발송 요일과 시간을 테스트하면 응답률을 개선할 수 있다. - 대부분의 거래에는 한 번 이상의 후속 연락이 필요하므로, 타이밍뿐 아니라 꾸준함도 중요하다. ## 상황별 템플릿 활용 ### 다음 단계가 명확했던 경우 - 제목: “[이름]님, 오늘 통화 후 다음 단계” - 구성: - 상대방이 설명한 문제나 목표에 대한 감사 - 약속한 자료나 제안서 첨부 - 상대방의 구체적인 상황에 기반한 추천 사항 - 특정 날짜와 시간으로 다음 단계 제안 - 이 구조는 대화를 재확인하고 약속한 자료를 전달하면서 일정 확정까지 쉽게 만든다. - 템플릿은 출발점으로만 사용하고, 통화에서 나온 구체적인 세부사항에 맞게 수정해야 한다. ## 실무적으로 적용할 때의 원칙 - 이메일 하나에 목표와 CTA를 하나씩만 넣는다. - 상대방이 실제로 말한 문제를 인용해 개인화한다. - 단순한 통화 요약에 그치지 말고 반드시 새로운 가치를 추가한다. - 첫 연락은 신속하게, 이후 연락은 새로운 정보와 함께 적절한 간격으로 보낸다. - 모호한 요청 대신 날짜, 시간, 답변 형식이 분명한 요청을 사용한다.

원문 읽기(새 탭에서 열림)
grammarlyemail-marketingcrmsales-follow-up+1
cloudflare4분 읽기큐레이션 요약

프로젝트 글래스윙: Mythos가 우리에게 보여준 것

Mythos Preview는 단순히 취약점을 찾아내는 수준을 넘어, 여러 취약점을 연결해 실제 공격 경로를 구성하고 실행 가능한 증명 코드까지 생성하는 새로운 단계의 보안 도구로 평가된다. 그러나 모델의 자발적 거부는 일관되지 않으며, 탐색적 모델의 높은 오탐률 때문에 대규모 운영에는 별도의 안전장치와 검증·분류 체계가 필요하다. Project Glasswing의 핵심 교훈은 강력한 모델 자체뿐 아니라 이를 통제하고 결과를 검증하는 아키텍처가 함께 발전해야 한다는 점이다. ## Mythos Preview가 달라진 점 - Cloudflare는 Project Glasswing의 일환으로 Mythos Preview를 50개가 넘는 자체 저장소에 적용했다. - 이전 범용 프런티어 모델과의 단순한 성능 비교보다, Mythos가 실제로 수행하는 작업의 성격을 이해하는 것이 중요하다고 설명한다. - 기존 모델도 개별 버그를 발견하거나 영향도를 분석할 수 있었지만, 여러 조각을 하나의 공격으로 연결하는 단계에서 자주 멈췄다. ## 여러 취약점을 연결하는 공격 체인 - 실제 공격은 하나의 버그가 아니라 여러 취약점과 공격 원시 기능을 조합해 완성되는 경우가 많다. - 예를 들어: - use-after-free를 임의 메모리 읽기·쓰기 기능으로 전환 - 제어 흐름 탈취 - ROP(Return-Oriented Programming) 체인 구성 - 최종적으로 시스템 제어권 획득 - Mythos Preview는 낮은 심각도로 분류될 만한 개별 버그들을 결합해 더 심각한 실제 공격 경로를 추론할 수 있었다. - 이러한 추론 과정이 자동화된 스캐너보다는 숙련된 보안 연구자의 작업에 가깝게 나타났다는 점이 두드러졌다. ## 반복 실행을 통한 익스플로잇 증명 - Mythos Preview는 의심되는 취약점을 설명하는 데 그치지 않고, 이를 재현하는 코드를 직접 작성한다. - 생성한 코드를 격리된 scratch 환경에서 컴파일하고 실행해 예상한 동작이 발생하는지 확인한다. - 실패하면 오류 결과를 분석하고 가설을 수정한 뒤 다시 시도한다. - 이 반복 루프를 통해 단순한 “취약할 가능성”과 실제 악용 가능한 취약점을 구분한다. - 따라서 취약점 탐지와 익스플로잇 가능성 입증 사이의 간극을 모델 스스로 줄일 수 있다. ## 정당한 보안 연구에서의 모델 거부 - Project Glasswing에서 제공된 Mythos Preview에는 일반 공개 모델에 적용되는 추가 안전장치가 없었지만, 모델 자체적으로 일부 요청을 거부하는 경향이 나타났다. - 그러나 거부 기준은 일관되지 않았다. - 동일한 코드라도 실행 환경의 사소한 변화에 따라 연구를 허용하거나 거부했다. - 심각한 메모리 버그를 확인한 뒤에도 시연용 익스플로잇 작성은 거부할 수 있었다. - 요청 표현을 바꾸거나 실행 시점을 달리하면 반대 결과가 나오기도 했다. - 이러한 자발적 안전장치는 실제로 존재하지만, 확률적이고 상황 의존적이므로 단독 안전 경계로 사용할 수 없다. - 향후 공개되는 강력한 사이버 보안 모델에는 통제된 연구 환경 밖에서도 사용할 수 있도록 별도의 안전장치가 필요하다. ## 신호 대 잡음 문제와 오탐 - 보안 취약점 분석에서 가장 어려운 일 중 하나는 발견된 문제가 실제인지, 악용 가능한지, 즉시 수정해야 하는지를 판별하는 것이다. - AI 스캐너와 AI가 생성한 코드의 확산은 이 문제를 더욱 악화시켰으며, Cloudflare는 여러 후속 검증 단계를 구축해 대응하고 있다. ### 프로그래밍 언어의 영향 - C와 C++는 메모리를 직접 제어할 수 있어 다음과 같은 취약점이 발생하기 쉽다. - 버퍼 오버플로 - 경계 밖 읽기·쓰기 - 메모리 수명 관리 오류 - Rust와 같은 메모리 안전 언어는 이러한 버그 유형의 상당수를 컴파일 시점에 제거한다. - 실험에서는 메모리 비안전 언어로 작성된 프로젝트에서 오탐이 일관되게 더 많이 발생했다. ### 모델의 탐색 편향 - 숙련된 사람은 발견 내용과 함께 확신 수준을 명확히 제시하지만, 모델은 코드에 문제가 없어도 문제를 찾으려는 경향이 있다. - 결과에는 “가능성이 있다”, “잠재적으로”, “이론상 가능하다”와 같은 추측성 표현이 많이 포함된다. - 탐색 단계에서는 이런 보수적·과잉 탐지 성향이 유용할 수 있다. - 하지만 실제 트리아지 큐에서는 각각의 추측성 결과를 사람이 검증하고 기각해야 하므로, 수천 건으로 확장될 경우 인력과 모델 토큰 비용이 크게 누적된다. ## 실용적인 결론 Mythos Preview 같은 모델은 취약점 후보 발굴을 넘어 공격 체인 구성과 재현 증명까지 수행할 수 있어 보안 연구의 생산성을 크게 높일 수 있다. 다만 결과를 그대로 신뢰해서는 안 되며, 격리된 실행 환경, 다단계 검증, 신뢰도 기반 우선순위화, 일관된 안전 정책을 함께 구축해야 대규모 운영에 적합하다.

원문 읽기(새 탭에서 열림)
Rustc++memory-safetyllm-security+4
gitlab3분 읽기큐레이션 요약

BYOK를 넘어: AI 에이전트에 거버넌스가 중요한 이유

BYOK와 로컬 모델 실행은 AI 모델 선택권을 넓히지만, 기업 환경에서 필요한 거버넌스까지 해결하지는 못한다. AI 에이전트가 CI/CD 파이프라인에서 빌드를 실행하고 설정을 변경하며 배포까지 수행하려면 접근 권한, 승인 절차, 감사 기록, 보안 통제가 플랫폼 차원에서 보장되어야 한다. 글은 GitLab Duo CLI와 Duo Agent Platform이 이러한 통제를 대화형 환경뿐 아니라 비대화형 CI/CD 실행에도 적용한다고 설명한다. ## BYOK와 로컬 모델의 한계 - GitHub Copilot CLI의 BYOK 기능은 개발자가 원하는 모델 제공자를 사용하거나 모델을 로컬에서 오프라인으로 실행할 수 있게 한다. - 이는 데이터 주권과 모델 선택 측면에서 유용하지만, 조직 전체에 어떤 모델을 강제할지 결정하거나 에이전트의 행동을 감사하는 기능과는 별개다. - 개인 개발자의 터미널 사용을 넘어, 여러 프로젝트와 릴리스 주기에서 AI가 자동화 작업을 수행하려면 추가적인 통제가 필요하다. ## 대화형 AI와 자동화된 에이전트의 차이 - 대화형 코딩 도구는 개발자가 매 단계에서 결과를 검토하고 승인하는 것을 전제로 한다. - 반면 자동화된 AI 에이전트는 사람의 확인 없이 테스트 실행, 설정 변경, 보안 검증, 배포 같은 여러 단계를 수행할 수 있다. - 따라서 중요한 질문은 다음과 같이 바뀐다. - 에이전트가 어떤 데이터와 시스템에 접근할 수 있는가? - 어떤 작업을 수행하도록 허가되었는가? - 실제로 어떤 행동을 했고, 그 이유를 입증할 수 있는가? - 특히 CI/CD 안에서는 개발자가 프롬프트 인젝션이나 비정상적인 모델 행동을 실시간으로 감지할 수 없으므로, 보안 통제가 플랫폼에 내장되어야 한다. ## GitLab Duo CLI의 거버넌스 방식 - GitLab Duo CLI는 개발자 터미널뿐 아니라 보안, 검증, 컴플라이언스, 배포 자동화까지 지원하도록 설계되었다. - 헤드리스 모드를 제공해 대화형 승인 없이 스크립트와 CI/CD 파이프라인에서 실행할 수 있다. - 대화형 모드에서는 사람이 승인하기 전까지 작업을 실행하지 않는 human-in-the-loop 방식을 적용한다. - GitLab Duo Agent Platform에 프롬프트 인젝션 탐지가 포함되어 악의적인 입력이 에이전트의 동작을 바꾸는 위험을 줄인다. - 복합 ID(composite identity)로 에이전트의 접근 범위를 명시적으로 허가된 리소스로 제한하고, AI가 수행한 작업을 감사 가능하게 만든다. - `AGENTS.md`와 `SKILL.md` 같은 사용자 정의 지침 파일을 통해 에이전트가 수행할 수 있는 작업과 금지된 행동을 팀 차원에서 정의할 수 있다. ## CI/CD 파이프라인 자동화의 핵심 과제 - 활용 사례로는 스프린트 종료 시 고장 난 파이프라인을 분석하거나, 여러 단계로 구성된 개발 작업을 자동 처리하는 것이 제시된다. - 그러나 파이프라인 내부에는 매번 결과를 검토할 개발자가 없기 때문에 개인별 설정만으로는 충분하지 않다. - 모든 프로젝트와 환경에서 동일하게 적용되는 권한 제어, 실행 기록, 프롬프트 인젝션 방어가 필요하다. - 모델이 예상과 다르게 행동했을 때 원인을 추적하고 책임을 확인할 수 있는 감사 로그도 중요하다. ## 모델 유연성과 데이터 주권 - 기업은 모델 선택권과 오프라인 실행 기능을 통해 민감한 데이터를 직접 관리하는 인프라에 둘 수 있다. - GitLab Duo CLI는 자체 호스팅 모델과 GitLab 호스팅 모델을 함께 사용할 수 있도록 지원한다. - 민감도가 높은 작업은 자체 인프라에서 처리하고, 일반 작업은 호스팅 모델을 사용하는 방식으로 유연성과 통제력을 조정할 수 있다. - 다만 글은 모델 선택보다 그 위에 있는 거버넌스 구조가 실제 프로덕션 도입 가능성을 결정한다고 강조한다. ## 실용적인 판단 기준 AI 에이전트를 CI/CD에 도입할 때는 지원 모델이나 BYOK 여부만 확인하지 말고, 비대화형 실행에서도 권한 제한, 승인 정책, 프롬프트 인젝션 방어, 감사 추적이 일관되게 작동하는지 검증해야 한다. 특히 사람이 지켜보지 않는 환경에서도 동일한 보안 모델이 유지되는지가 핵심 평가 기준이다.

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

LLM은 A/B 테스트에서 언제 인간을 대체할 수 있을까? | Spotify Engineering

LLM 예측은 인간 사용자를 대신한 A/B 테스트에 활용될 수 있지만, 무작위 실험처럼 설계만으로 타당성이 보장되지는 않습니다. Upworthy 헤드라인 데이터에서는 원시 LLM 예측이 인간의 실제 효과를 39%만 포착했지만, 적절한 보정과 반복 예측을 적용하면 인간 실험 결과를 회복할 수 있었습니다. 다만 그 보정이 새로운 유형의 제품·기능에도 유지된다는 보장은 없으며, 혁신적인 개입일수록 인간 대상 실험이 여전히 필요합니다. ## LLM 원시 예측은 단순한 잡음이 아니라 편향을 가진다 - 연구진은 수천 건의 헤드라인 A/B 테스트가 포함된 Upworthy Research Archive를 사용했습니다. - `gpt-4o-mini`에 각 대조군·처리군 헤드라인의 일반적인 사용자 클릭률을 예측하도록 했습니다. - 원시 예측값으로 인간 실험과 같은 분석을 수행하자 실제 인간 치료 효과의 **39%만 회복**했습니다. - 이는 무작위 잡음만의 문제가 아니라, LLM이 처리 효과를 전반적으로 0에 가깝게 축소하는 방향성 편향입니다. - 이런 편향이 누적되면 조직은 기능이나 제품 변경의 사용자 가치를 과소평가하고, 출시 여부를 잘못 결정할 수 있습니다. ## LLM을 인간 결과의 대리변수로 쓰기 위한 두 조건 ### 대리성(Surrogacy) - LLM 예측이 처리군과 대조군의 차이 중 인간 행동에 영향을 주는 모든 요소를 포착해야 합니다. - LLM 예측과 처리 전 특성 등을 고려한 뒤에는, 사용자가 어느 조건에 배정됐는지가 인간의 결과를 추가로 설명하지 않아야 합니다. - 즉, LLM 예측이 “해당 처리가 인간 반응에 미치는 경로”를 완전히 매개해야 합니다. - 이 조건이 성립하지 않으면 LLM은 인간의 효과가 아니라 LLM 자체의 반응을 측정하게 됩니다. ### 비교가능성(Comparability) - 과거 인간 실험에서 추정한 “LLM 예측과 실제 인간 행동의 관계”가 새로운 실험에서도 동일해야 합니다. - 새로운 처리 방식이 등장했을 때 LLM 점수와 실제 사용자 행동의 매핑이 달라지면 기존 보정 함수는 무너집니다. - 더 강한 형태로는 처리 전 사용자 특성과 LLM 예측의 전체 분포가 실험 간 안정적이어야 합니다. - 두 조건이 모두 충족될 때에만 과거 사용자 데이터로 LLM 결과를 보정해 인간 평균 처리 효과를 추정할 수 있습니다. - 데이터나 LLM 샘플을 무한히 늘려도 조건이 깨지면 편향은 사라지지 않습니다. 이는 표본 부족이 아니라 식별 대상 자체가 달라지는 문제이기 때문입니다. ## 보정 방법에 따라 결과가 달라진다 - 단순 선형 보정과 OLS(최소제곱법)는 인간 결과와 LLM 결과 사이의 비선형 관계를 충분히 표현하지 못했습니다. - 검증용으로 남겨둔 실험에서 OLS 보정 효과는 인간 기준값과 **3.8 표준오차**만큼 차이를 보여 신뢰하기 어려웠습니다. - 랜덤 포레스트와 그래디언트 부스팅 트리 같은 머신러닝 모델은 더 유연하게 비선형 관계를 학습했습니다. - 이 방법으로 보정한 효과는 인간 효과의 표본오차 범위 안에 들어갔고, 통계적으로 유의한 차이가 나타나지 않았습니다. - 따라서 LLM 예측을 사용할 경우 단순 선형 보정보다는 과거 인간 데이터에서 검증된 유연한 보정 모델이 필요합니다. ## LLM 생성의 무작위성도 별도로 처리해야 한다 - 같은 입력이라도 샘플링 온도에 따라 LLM은 서로 다른 예측을 낼 수 있습니다. - 이 측정오차를 무시하면 효과가 다시 0으로 축소되고 추정 분산도 커질 수 있습니다. - 각 실험 단위에 대해 LLM 예측을 여러 번 생성한 뒤 평균을 내면 우연한 생성 잡음이 줄어듭니다. - 평균 예측은 개별 출력의 불안정성을 완화하고, 인간 행동과 관련된 신호에 더 가까워지는 효과가 있습니다. ## 가장 큰 한계는 새로운 개입에 있다 - 대리성과 비교가능성은 과거 데이터에서 일부 점검할 수 있지만, 한 번도 실험하지 않은 처리에 대해 성립한다고 증명할 수는 없습니다. - 새로운 UI 패러다임, 가격 정책, 완전히 새로운 기능처럼 기존 실험과 거리가 먼 개입일수록 과거 보정의 근거가 약해집니다. - Upworthy 데이터는 텍스트 기반이고 헤드라인 변형들이 서로 유사하며, LLM이 매력적인 문구에 관한 많은 텍스트를 학습했다는 점에서 대리변수 검증에 유리한 사례입니다. - 반면 레이아웃, 추천 알고리즘, 가격, 사용자 경험 구조처럼 텍스트만으로 표현하기 어려운 처리는 필요한 조건이 더 쉽게 깨질 수 있습니다. - 역설적으로 LLM A/B 테스트가 가장 큰 이익을 주는 “완전히 새로운 시도”에서 인간 결과를 대체할 근거가 가장 약합니다. 새로운 기능이나 제품 혁신을 평가할 때는 인간 대상 A/B 테스트를 기준으로 삼는 것이 안전합니다. LLM 기반 테스트는 과거와 유사한 처리를 빠르게 선별하거나, 충분한 인간 실험 데이터로 보정·검증된 제한적인 영역에서 보조 수단으로 사용하는 것이 적절합니다.

원문 읽기(새 탭에서 열림)
대규모 언어 모델머신러닝ab-testingcausal-inference+4
gitlab4분 읽기큐레이션 요약

GitLab Dedicated for Government, 이제 GovRAMP 인증 획득

GitLab Dedicated for Government가 GovRAMP Authorization을 획득해 주·지방 정부기관이 보안과 규정을 충족하는 DevSecOps SaaS를 더 빠르게 도입할 수 있게 됐습니다. 미국 내 데이터 거주성, 단일 테넌트 격리, 프라이빗 네트워킹, GitLab의 완전 관리형 운영을 제공하면서도 인프라 수준의 통제력을 유지하는 것이 핵심입니다. 또한 GitLab Duo 기반 AI 기능을 제공하며, GovRAMP 인증 경계 내 에이전틱 AI 기능도 추후 추가될 예정입니다. ## GovRAMP 인증의 의미 - GovRAMP는 주·지방 정부기관이 클라우드 서비스의 보안성과 규정 준수 여부를 평가할 수 있도록 표준화된 위험 승인 체계를 제공합니다. - 32개 주가 GovRAMP를 채택했으며, 여러 주에서 의무화가 진행 중입니다. - 이번 인증으로 정부기관은 별도의 긴 인증·조달 장벽을 줄이고, 현대적인 소프트웨어 공급망을 더 신속하게 도입할 수 있습니다. - GitLab Dedicated for Government는 정부 데이터와 서비스가 요구하는 높은 수준의 보안, 데이터 주권, 격리 요건을 목표로 설계됐습니다. ## 정부기관의 현대화와 보안 요구 - 주·지방 정부는 하이브리드 및 멀티클라우드 전략을 추진하며 IT 현대화에 대규모 예산을 투입하고 있습니다. - NASCIO의 2025년 조사에서 현대화는 주 CIO들의 주요 우선순위 4위로 상승했습니다. - 기관들은 노후 시스템의 보안 취약점, 제3자 소프트웨어 공급망 위험, 랜섬웨어와 국가 지원 공격에 대응해야 합니다. - GitLab은 인프라를 직접 구축·운영하지 않고도 현대적인 애플리케이션 개발과 엔터프라이즈급 보안·규정 준수를 달성할 수 있도록 이 서비스를 설계했습니다. ## 도구 체인 통합 - GitLab의 2025년 공공 부문 DevSecOps 조사에 따르면: - 60%의 팀이 소프트웨어 개발 도구를 5개 이상 사용합니다. - 53%의 팀이 보안 도구를 5개 이상 사용합니다. - 비효율적인 프로세스와 협업 장벽으로 주당 약 6시간을 잃습니다. - 여러 도구를 사용하는 방식은 비용을 증가시키고, 팀 간 협업과 보안 정책 적용을 복잡하게 하며, 공격 표면을 넓힐 수 있습니다. - GitLab Dedicated for Government는 개발·보안·운영 팀을 하나의 플랫폼과 통합 워크플로로 연결합니다. - 중앙화된 접근 제어와 인증 정책을 통해 제로 트러스트 아키텍처 구현도 지원합니다. - 개방형 API와 통합 기능을 제공하므로 기관은 기존 도구를 한 번에 교체하지 않고 단계적으로 통합할 수 있습니다. ## 데이터 거주성과 보호 - GovRAMP 인증 인프라를 기반으로 하며, 미국 시민으로 접근을 제한하는 요건을 지원합니다. - 고객의 VPC와 GitLab 사이에 프라이빗 연결을 구성해 인터넷에 직접 노출하지 않고 사용자·데이터·서비스를 격리된 인스턴스에 연결할 수 있습니다. - 저장 데이터와 전송 데이터 모두 최신 암호화 표준으로 보호됩니다. - 저장 데이터 암호화에는 고객이 직접 관리하는 AWS KMS 키를 사용할 수 있습니다. - CVE 패치를 지속적으로 적용해 고객이 인프라와 규정 준수 관리 부담을 줄일 수 있습니다. ## GitLab의 완전 관리형 단일 테넌트 운영 - 고객별 물리적 격리를 제공하는 단일 테넌트 구조입니다. - 미국 내에서 호스팅되며 프라이빗 네트워크로 연결됩니다. - 인프라는 GitLab이 완전히 관리하고 운영하므로 정부기관은 자체 인력으로 플랫폼을 구축·유지할 필요가 없습니다. - 기관 직원은 인프라 관리보다 핵심 업무와 미션에 집중할 수 있습니다. - 자체 호스팅보다 총소유비용과 도입 시간을 줄이면서도 GitLab의 개발 생산성, 보안, 규정 준수 기능을 활용할 수 있습니다. ## 네이티브 보안 및 규정 준수 기능 - 소프트웨어 개발 생명주기 전반에 보안과 규정 준수 기능이 통합돼 있습니다. - 기본 제공 보안 스캐너에는 다음이 포함됩니다. - 정적 애플리케이션 보안 테스트(SAST) - 비밀정보 탐지 - 컨테이너 스캔 - 동적 애플리케이션 보안 테스트(DAST) - 의존성 스캔은 직접 의존성과 전이 의존성을 깊이 제한 없이 분석합니다. - 프로젝트 단위뿐 아니라 여러 프로젝트 그룹 전체에서 의존성 목록과 위험 요소를 확인할 수 있어 공급망 위험을 추적하기 쉽습니다. - 보안 결과는 머지 리퀘스트 위젯과 파이프라인 보안 탭에 표시됩니다. - 개발 작업의 맥락에서 한 번의 클릭으로 결과를 분류하고 대응할 수 있습니다. - 사용자 지정 규칙 집합과 보안 정책 자동화를 통해 오탐을 줄이고 일관된 보안 통제를 적용할 수 있습니다. ## 실용적인 결론 보안·데이터 주권 요건 때문에 일반적인 퍼블릭 SaaS 도입이 어려운 주·지방 정부기관이라면 GitLab Dedicated for Government가 적합한 선택지가 될 수 있습니다. 특히 여러 개발·보안 도구를 통합하면서도 미국 내 데이터 저장, 단일 테넌트 격리, 프라이빗 연결, GovRAMP 승인을 동시에 요구하는 조직에 유용합니다.

원문 읽기(새 탭에서 열림)
gitlabDevSecOps클라우드 보안software-supply-chain-security+4
spotify4분 읽기큐레이션 요약

코딩은 더 이상 제약이 아니다: Spotify에서 팀과 에이전트를 위한 개발자 경험 확장 | Spotify Engineering

Spotify는 AI 코딩 에이전트 도입으로 개발 속도가 크게 향상되면서, 이제 코딩 자체보다 의사결정과 개발 경험의 확장성이 새로운 병목이 되었다고 설명합니다. 수년간 구축한 자동화 시스템, 내부 개발자 포털, 표준화된 기술 스택이 AI 에이전트의 성능과 신뢰성을 높이는 기반이 되었습니다. 그 결과 99% 이상의 엔지니어가 매주 AI 코딩 도구를 사용하고, 풀 리퀘스트 생성 빈도도 76% 증가했습니다. ## AI 코딩 도구의 폭발적인 확산 - Spotify 엔지니어의 99% 이상이 매주 AI 코딩 도구를 사용합니다. - 94%는 AI가 생산성을 높였다고 응답했습니다. - 풀 리퀘스트 생성 빈도는 76% 증가했습니다. - 대부분의 PR은 개발자와 AI 에이전트가 협업해 작성합니다. - 특히 Claude Opus 4.5 출시 이후 Claude Code 사용량이 급격히 증가했습니다. - Spotify는 과거에도 내부 생산성 도구를 꾸준히 배포했지만, AI 도구만큼 빠른 채택률은 경험하지 못했습니다. ## 에이전트 이전부터 시작된 자동화 - Spotify의 운영 코드베이스는 엔지니어 수보다 7배 빠르게 증가했습니다. - 개발자들은 기능 개발보다 다음과 같은 유지보수 작업에 더 많은 시간을 쓰게 되었습니다. - 의존성 업그레이드 - API 마이그레이션 - 보안 취약점 패치 - 특히 마이그레이션이 개발자 불만의 가장 큰 원인이었습니다. - 이를 해결하기 위해 여러 팀이 각자 수작업으로 처리하는 대신, 수백~수천 개 컴포넌트를 한꺼번에 변경하는 Fleet Management를 구축했습니다. - Fleetshift는 대상 식별, 작업 예약, 진행 상황 추적 등 전체 변경 작업을 조율합니다. - 지금까지 250만 건 이상의 자동화 유지보수 PR을 병합했으며, 대부분은 사람의 개입 없이 자동 병합되었습니다. ## Honk: 백그라운드 코딩 에이전트 - 단순한 변경에는 결정론적 스크립트가 효과적이었지만, API 교체나 대규모 리팩터링처럼 예외가 많은 작업에서는 한계가 있었습니다. - Spotify는 복잡한 스크립트를 계속 추가하는 대신 LLM이 코드 수정 작업을 수행하도록 했고, 그 결과 Honk를 만들었습니다. - Honk의 구성은 다음과 같습니다. - Claude와 Agent SDK 기반 - Spotify 자체 실행 하네스와 결합 - Kubernetes 파드에서 실행 - 여러 에이전트 세션을 클라우드에서 동시에 스케줄링 - 여러 운영체제에서 CI 빌드를 실행해 변경 사항 검증 - Fleetshift가 전체 작업을 관리하고 Honk가 실제 코드 수정을 담당합니다. - 최근 백엔드 서비스의 Java 마이그레이션은 한 명의 엔지니어가 3일 만에 완료했습니다. - 과거 수백 팀이 수주 또는 수개월에 걸쳐 수행하던 작업을 단일 엔지니어가 며칠 안에 처리할 수 있게 되었습니다. - Honk는 Slack에서도 호출할 수 있어, 대화 중 언급하면 맥락을 바탕으로 작업하고 PR을 생성합니다. - Honk v2에서는 다음 기능을 도입할 예정입니다. - 공유 에이전트 세션 - 팀 프로젝트 - Chirp를 통한 에이전트 오케스트레이션 - 여러 개발자와 에이전트의 협업 ## 에이전트에게도 필요한 개발자 경험 - Spotify는 “세계 최고 수준의 기술 영역을 적게 만들수록 더 빠르게 움직일 수 있다”는 원칙을 오래 유지해 왔습니다. - 제한된 기술 스택과 일관된 설계 패턴을 사용하면 다음 효과가 있습니다. - 팀 간 협업이 쉬워짐 - 기술 선택에 따른 불필요한 의사결정 감소 - 코드베이스에 대한 공통 전문성 향상 - 개발자와 에이전트가 참고할 수 있는 일관된 코드 증가 - Claude는 참고할 코드가 많고 그 구조가 일관될수록 더 나은 결과를 냅니다. - 반대로 코드베이스가 파편화되어 있으면 에이전트 성능도 측정 가능하게 저하됩니다. ## Backstage를 통한 통합과 표준화 - Spotify는 오픈소스 내부 개발자 포털인 Backstage를 개발 경험의 중심으로 사용합니다. - Backstage 이전에는 배포, CI, A/B 테스트 등 기능별로 약 100개의 내부 도구가 분리되어 있었습니다. - Backstage는 이를 하나의 화면으로 통합하고, 소프트웨어 컴포넌트 카탈로그를 중심으로 관리합니다. - 개발자와 에이전트 모두 Backstage에서 다음 정보를 확인할 수 있습니다. - 컴포넌트 소유 팀 - 관련 문서 - 기술 구성 - 담당자와의 커뮤니케이션 경로 - Spotify는 Backstage 기능을 MCP와 CLI 도구로 노출해 Claude도 동일한 정보를 활용하도록 했습니다. - 에이전트는 필요한 컴포넌트의 담당자를 조회하거나 문서를 읽고, Slack으로 책임 팀에 문의할 수 있습니다. ## Golden State와 자동 피드백 - Golden state는 컴포넌트 유형별 권장 기술과 개발 관행을 정의합니다. - Soundcheck는 각 팀이 자신의 컴포넌트가 표준을 얼마나 준수하는지 점검하는 UI를 제공합니다. - 정적 분석과 린팅을 결합하면 표준이 단순한 문서가 아니라 실제 가드레일로 작동합니다. - Claude가 권장되지 않는 기술이나 설계 패턴을 사용하면 린터가 즉시 피드백을 제공합니다. - 에이전트는 이 피드백을 바탕으로 스스로 코드를 수정할 수 있습니다. - 같은 피드백 루프가 개발자와 에이전트 모두에게 적용되므로, 조직 전체의 일관성을 유지하는 효과적인 수단이 됩니다. ## 실용적인 결론 AI 에이전트를 도입하려면 모델 자체보다 먼저 일관된 기술 스택, 중앙화된 컴포넌트 정보, 자동화된 검증 체계를 마련해야 합니다. 표준화된 코드베이스와 즉각적인 린트·CI 피드백이 갖춰질 때 에이전트는 대규모 마이그레이션과 유지보수 작업을 안정적으로 수행할 수 있습니다.

원문 읽기(새 탭에서 열림)
AI 에이전트쿠버네티스CI/CDslack+4
discord3분 읽기큐레이션 요약

디스코드의 모든 음성 및 영상 통화가 이제 종단 간 암호화됩니다

Discord는 2026년 3월부터 Stage 채널을 제외한 모든 음성·영상 통화에 종단간 암호화(E2EE)를 기본 적용했다. 이를 위해 DAVE 프로토콜을 데스크톱·모바일·웹·콘솔·봇·Social SDK 등 모든 플랫폼에 적용했으며, 사용자가 별도로 설정하지 않아도 암호화가 작동한다. Discord는 통화 품질과 지연 시간을 유지하면서도 공개 프로토콜, 오픈소스 구현, 외부 감사를 통해 검증 가능한 개인정보 보호를 제공하는 것을 목표로 했다. ## DAVE 프로토콜 도입과 전면 적용 - Discord는 2023년 음성·영상 통화 E2EE 실험을 시작했다. - 2024년 DAVE 프로토콜을 공개했다. - 오디오·비디오 통화를 위한 공개 E2EE 프로토콜 - 외부 보안 기업 Trail of Bits의 설계·구현 감사 진행 - 오픈소스 구현체 공개 - 버그 바운티 프로그램에 프로토콜 포함 - 2025년 웹 브라우저, PlayStation·Xbox 같은 게임 콘솔, Discord 봇·앱, Social SDK까지 지원 범위를 확대했다. - 2026년 3월 초 마이그레이션을 완료해 다음 통화가 기본적으로 암호화된다. - 개인 메시지 통화 - 그룹 DM 통화 - 음성 채널 - Go Live 스트림 ## 다양한 플랫폼을 동시에 지원한 설계 - Discord 통화에는 노트북, 스마트폰, 웹 브라우저, PlayStation, Xbox 사용자가 함께 참여할 수 있다. - 각 플랫폼의 암호화 구현이 서로 호환되면서도 낮은 지연 시간과 높은 통화 품질을 유지해야 했다. - Discord는 플랫폼 다양성 때문에 DAVE를 인터넷에서 가장 폭넓은 플랫폼을 지원하는 음성·영상 E2EE 구현 중 하나로 설명한다. - 모든 클라이언트가 DAVE를 지원해야 통화에 참여할 수 있도록 변경했다. - 현재는 암호화되지 않은 연결로 되돌아가는 폴백 코드를 제거하는 중이며, 제거가 끝나면 비암호화 연결은 불가능해진다. ## 공개 검증과 외부 협업 - DAVE의 설계와 구현을 공개해 커뮤니티가 직접 검토할 수 있도록 했다. - 외부 감사를 통해 보안성을 검증하고, 버그 바운티로 추가적인 취약점 제보를 유도했다. - 웹 지원 과정에서는 Firefox의 문제로 DAVE가 실제 통화에서 정상 작동하지 않는 사례가 발견됐다. - Discord는 우회책을 적용하는 대신 Mozilla와 Firefox 코드베이스를 함께 조사해 근본 원인을 수정하고 패치를 반영했다. - 이는 자체 코드뿐 아니라 관련 플랫폼과 생태계까지 개선하는 방식으로 프로젝트를 진행했음을 보여준다. ## 사용자 경험과 Stage 채널 예외 - E2EE 적용 이후에도 통화 품질과 성능은 기존 수준을 유지하도록 설계했다. - 사용자가 별도로 opt-in할 필요 없이 암호화가 투명하게 적용된다. - 유일한 예외는 대규모 방송을 위한 Stage 채널이다. - 라이브 이벤트, AMA, 커뮤니티 타운홀 등에 사용되는 방송형 구조 - 개인적인 대화 보호를 목적으로 하는 일반 통화와 설계 목적이 다름 - 따라서 현재는 E2EE 대상에서 제외된다. ## 텍스트 메시지 암호화 계획 - Discord는 현재 텍스트 메시지까지 E2EE를 확장할 계획이 없다고 밝혔다. - Discord의 다양한 텍스트 기능이 비암호화 환경을 전제로 구축되어 있기 때문이다. - E2EE를 도입하려면 검색, 관리, 신고, moderation 등 기존 기능을 대규모로 재설계해야 한다. - Discord는 음성·영상 암호화를 완료했지만 개인정보 보호 강화는 계속 진행되는 작업이라고 강조한다. 이번 변화로 Discord 사용자는 별도 설정 없이 개인 음성·영상 대화에 구조적이고 검증 가능한 보호를 받을 수 있게 됐다. 다만 Stage 채널과 텍스트 메시지는 적용 범위에서 제외되므로, 민감한 대화에는 일반 음성 채널이나 DM 통화를 사용하는 것이 적절하다.

원문 읽기(새 탭에서 열림)
오픈 소스end-to-end-encryptionbug-bountycross-platform+3
gitlab4분 읽기큐레이션 요약

Codex와 GitLab으로 버그 수정

Codex는 터미널에서 코드를 분석하고 수정·테스트하는 데 강력하지만, 실제 배포에는 이슈 관리, 머지 리퀘스트, CI/CD, 코드 리뷰와 승인 과정이 필요하다. 글은 GitLab과 Codex를 연계해 Rust WebSocket 버그를 수정하고, GitLab MCP로 이슈와 개발 맥락을 반영하며, GitLab Duo Agent Platform의 외부 에이전트로 리뷰 피드백까지 처리하는 흐름을 소개한다. 핵심 결론은 코딩 에이전트의 빠른 구현 능력과 GitLab의 소프트웨어 생명주기 관리 기능을 결합해야 코드 작성부터 운영 배포까지 연결할 수 있다는 것이다. ## Codex와 GitLab을 결합하는 전체 워크플로 - Codex는 저장소 안에서 코드를 읽고, 수정안을 만들고, 명령을 실행하고, 테스트까지 수행한다. - 그러나 코드 작성만으로는 소프트웨어가 배포되지 않는다. - GitLab 이슈 - 머지 리퀘스트 - CI/CD 파이프라인 - 보안 스캔 - 코드 리뷰 - 최종 사람의 승인 등이 필요하다. - 글에서는 Tanuki IoT Platform 프로젝트의 Rust metrics backend를 대상으로 세 가지 활용 사례를 제시한다. - 로컬 Codex로 Rust WebSocket 버그 수정 - GitLab MCP로 이슈 요구사항과 개발 맥락을 Codex에 제공 - GitLab Duo Agent Platform에서 Codex를 외부 에이전트로 사용해 MR 리뷰 피드백 처리 ## 실습 환경과 프로젝트 구조 - 필요한 환경: - 터미널에서 실행 가능한 Codex - 이슈가 포함된 GitLab 프로젝트 - 선택적으로 GitLab MCP 서버와 GitLab Duo Agent Platform - Rust 컴파일러와 Cargo - 프로젝트를 GitLab에 가져온 뒤 로컬에 clone하고 저장소 루트에서 `codex`를 실행한다. - 주요 대상은 `backend/` 아래의 Rust metrics store다. - 센서는 REST API로 측정값을 전송한다. - 대시보드는 WebSocket 스트림으로 실시간 데이터를 받는다. - `AGENTS.md`를 통해 Codex에 Rust 도구 체인, 빌드 명령, 테스트 방법, 코드 품질 기준을 알려줄 수 있다. ## WebSocket 메트릭 필터 버그 재현 - 백엔드는 REST API에서는 메트릭 필터링을 지원하지만, WebSocket 스트림에서는 필터가 제대로 적용되지 않는 문제가 있었다. - 서버 실행: ```bash PORT=9090 cargo run --manifest-path backend/rust-metrics-store/Cargo.toml ``` - 특정 센서와 메트릭을 구독: ```bash websocat 'ws://localhost:9090/ws?sensor=arduino-iot-collector&metric=temperature_celsius' ``` - 같은 센서에 서로 다른 메트릭을 전송한다. ```bash curl -s -X POST http://localhost:9090/api/metrics \ -H 'Content-Type: application/json' \ -d '{"sensor":"arduino-iot-collector","metric":"temperature_celsius","value":23.5}' curl -s -X POST http://localhost:9090/api/metrics \ -H 'Content-Type: application/json' \ -d '{"sensor":"arduino-iot-collector","metric":"humidity_percent","value":61.2}' ``` - 기대 결과는 `temperature_celsius`만 수신하는 것이다. - 실제로는 `humidity_percent`도 스트림에 나타나므로, `/ws`가 `metric` 쿼리 파라미터를 무시하고 있음을 확인할 수 있다. ## 로컬 Codex를 이용한 버그 수정 - Codex에 다음과 같이 작업을 요청한다. ```text I need help with a backend change to add metric filtering to /ws so live streams can be narrowed to one metric. ``` - Codex는 저장소와 `AGENTS.md`를 분석해 다음 작업을 수행한다. - `/ws` 핸들러의 기존 sensor 필터 로직 조사 - 선택적 `metric` 쿼리 파라미터 지원 추가 - 센서와 메트릭 조합에 따른 필터링 구현 - 관련 테스트 추가 - `README.md`와 `AGENTS.md` 등 문서 갱신 - 변경 후 포맷팅, 테스트, 빌드를 실행하고 최종 diff를 검토한다. - 이후 Codex에 브랜치 생성, 커밋, 원격 저장소 push를 맡길 수 있다. ## GitLab 머지 리퀘스트와 CI/CD 검증 - 코드가 MR에 올라가면 GitLab이 이후 생명주기를 담당한다. - 파이프라인에서 다음 검증이 수행된다. - 빌드와 테스트 - 보안 스캔 - Rust 코드 스타일 및 품질 검사 - GitLab Duo Code Review - 배포 후에는 동일한 로컬 테스트를 다시 실행해 sensor와 metric을 모두 지정했을 때 요청한 메트릭만 전달되는지 확인한다. - 검증 결과와 로컬 테스트 내용을 MR에 댓글로 남겨 리뷰 맥락을 공유한다. ## GitLab MCP로 이슈와 요구사항 연결 - 로컬 저장소만 보는 Codex는 GitLab에 있는 다음 정보를 알 수 없다. - 버그 이슈의 상세 내용 - 합의된 기능·비기능 요구사항 - 구현 메모 - 관련 MR 상태 - 파이프라인 상태 - GitLab MCP 서버를 연결하면 Codex가 이슈를 직접 조회할 수 있다. - 이슈에는 다음과 같은 내용이 포함될 수 있다. - 문제 재현 방법 - 기능 요구사항 - 비기능 요구사항 - 필요한 테스트 - `README.md`, `AGENTS.md` 갱신 요구 - 구현 방향에 대한 메모 - 따라서 사용자가 긴 요구사항을 프롬프트에 복사하지 않아도, Codex가 GitLab 이슈를 단일 기준 정보로 활용해 구현할 수 있다. - 이는 단순히 코드를 고치는 것보다 프로젝트의 합의된 요구사항과 개발 프로세스에 맞춘 변경을 가능하게 한다. ## 실용적인 적용 권장 사항 - Codex에는 작업 범위와 기대 동작을 명확히 요청하고, `AGENTS.md`에 빌드·테스트·스타일 규칙을 기록하는 것이 좋다. - 코드 수정 전에는 실제 API와 WebSocket 동작을 명령줄에서 재현해 버그를 객관적으로 확인한다. - GitLab MCP를 사용해 이슈를 직접 참조하게 하면 요구사항 누락을 줄일 수 있다. - Codex가 작성한 코드는 GitLab MR, CI/CD, 보안 스캔, 사람의 리뷰를 거친 뒤 배포해야 한다.

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

범용 접근성 에이전트 구축과 그 과정에서 얻은 교훈

GitHub는 개발자가 접근성 질문에 즉시 답을 얻고, 배포 전 단순하고 객관적인 접근성 문제를 자동 수정하도록 실험적인 범용 접근성 에이전트를 운영하고 있습니다. 이 에이전트는 3,535개의 풀 리퀘스트를 검토해 68%의 해결률을 기록했지만, 접근성을 자동으로 “해결”하는 만능 도구가 아니라 기존 엔지니어링 노력을 보완하는 역할로 설계되었습니다. 특히 조직이 축적한 구조화된 접근성 이슈와 수정 사례가 에이전트의 정확도와 실용성을 높이는 핵심 자산이 되었습니다. ## 접근성 에이전트의 목표와 성과 - GitHub Copilot CLI와 VS Code 통합 환경에서 접근성 관련 질문에 신뢰할 수 있는 답변을 제공합니다. - 프런트엔드 코드가 변경된 풀 리퀘스트를 자동으로 검사합니다. - 단순하고 판단 기준이 명확한 접근성 문제는 코드 제안 형태로 자동 수정할 수 있습니다. - 현재까지 3,535개의 풀 리퀘스트를 검토했으며, 68%의 해결률을 기록했습니다. - 가장 많이 발견된 문제는 다음과 같습니다. - 구조와 관계를 보조공학 기술이 명확히 이해하도록 표현하지 못한 문제 - 대화형 컨트롤의 이름이 불명확한 문제 - 중요한 상태 변화나 공지를 사용자에게 전달하지 못한 문제 - 이미지 등 비텍스트 콘텐츠에 텍스트 대안이 없는 문제 - 키보드 포커스 이동 순서가 논리적이지 않은 문제 예를 들어 시각적 배치와 DOM·스크린 리더 읽기 순서가 서로 다른 경우, 에이전트는 `row-reverse` 대신 DOM 요소 순서를 바꾸고 일반적인 `flex-direction: row`를 사용하라고 제안할 수 있습니다. ## 접근성을 바라보는 관점 - 사회적 장애 모델에 따르면 장애와 사용 장벽은 개인뿐 아니라 환경의 설계 방식에서도 발생합니다. - 디지털 서비스에서도 잘못 구성된 UI가 보조공학 사용자에게 장벽을 만들 수 있습니다. - 따라서 에이전트의 목표는 접근성을 독립적으로 완성하는 것이 아니라, 동료 개발자가 장벽을 더 빠르게 발견하고 제거하도록 돕는 것입니다. - 모든 상황을 자동으로 처리할 수 있는 “실버 불릿”으로 에이전트를 홍보하지 않았습니다. - 에이전트의 책임 범위를 현실적으로 정의한 덕분에 실험을 빠르게 시작하고 조직 내 동의를 얻을 수 있었습니다. ## 규제와 사전 투자 - 유럽 접근성법(EAA)이 시행되었고, 미국 장애인법(ADA) Title II도 2027년 4월부터 WCAG 2.1 AA 준수를 법적 완료 기준으로 삼을 예정입니다. - LLM 기반 에이전트는 접근성 트리를 읽고 이를 바탕으로 UI를 분석하거나 조작할 수 있습니다. - 조직이 아직 수동으로 접근성 문제를 식별하고 수정하는 체계를 마련하지 않았다면, 향후 에이전트를 구축할 때도 불리해집니다. - 자동화는 기존의 접근성 품질 관리 체계를 대체하는 것이 아니라, 이미 검증된 문제와 해결 방식을 활용해 확장하는 방식으로 효과를 냅니다. ## 구조화된 이슈 데이터의 가치 GitHub는 에이전트 도입 이전부터 접근성 문제를 일관되게 기록하고 검증하는 시스템을 운영했습니다. - 문제 신고용 구조화된 템플릿 - 재현 절차 - 심각도, 담당 서비스 영역, 적용 가능한 WCAG 성공 기준 등의 메타데이터 - 문제를 해결한 풀 리퀘스트와의 연결 - 수정 완료를 판단하는 명확한 수용 기준 - 모든 접근성 이슈를 하나의 저장소에 중앙화 이처럼 일관된 형식으로 축적된 이슈와 코드 변경 내역은 에이전트가 참고할 수 있는 고품질 학습·검색 자료가 되었습니다. LLM의 비결정적이고 유연한 매칭 능력도 비슷한 코드와 문구를 찾아내는 데에는 장점으로 작용했습니다. ## 일반적인 지침만으로는 부족한 이유 - 전문 영역에서 “접근성 모범 사례를 따르라”는 식의 짧고 추상적인 지침만으로는 충분하지 않습니다. - 주요 LLM은 접근성이 부족한 코드가 포함된 수십 년간의 자료로 학습되었기 때문에, 접근성 안티패턴을 생성하는 편향을 보일 수 있습니다. - 따라서 에이전트가 실제 조직의 코드 스타일과 문제 해결 관례를 반영한 구체적인 사례를 참고해야 합니다. - 수동으로 접근성 문제를 분류하고 수정한 기록은 다음 요소를 함께 포함합니다. - 실제 제품 맥락 - 조직의 코딩·문서화 규칙 - 적용된 WCAG 기준 - 문제를 해결한 코드 - 수정 여부를 검증하는 조건 - 이런 사례 기반 자료는 단순한 체크리스트보다 에이전트의 판단과 코드 제안에 훨씬 강력한 기반이 됩니다. ## 실용적인 결론 접근성 에이전트를 도입하려면 먼저 사람이 접근성 문제를 일관되게 기록하고, 재현 절차와 WCAG 기준, 실제 수정 사례를 축적하는 것이 좋습니다. 에이전트는 전문가의 판단을 대체하기보다 반복적이고 객관적인 문제를 빠르게 발견·수정하는 보조 수단으로 운영해야 하며, 그 한계를 명확히 정의할수록 조직 내 신뢰와 도입 효과가 커집니다.

원문 읽기(새 탭에서 열림)
대규모 언어 모델접근성github-copilotGitHub Actions+3
github4분 읽기큐레이션 요약

기준을 높이다: 품질, 공동의 책임, 그리고 GitHub 버그 바운티 프로그램의 미래

GitHub는 버그 바운티 프로그램을 유지하되, 제출량 증가와 검증되지 않은 보고서 확산에 대응해 심사 기준을 강화하겠다고 밝혔다. AI·스캐너 사용 자체는 환영하지만, 연구자가 실제 영향을 재현하고 검증할 책임이 있다는 점을 강조한다. 또한 사용자가 악성 콘텐츠를 직접 선택·실행하는 경우에는 GitHub의 보안 경계를 우회한 취약점이 아니라 공유 책임 영역으로 보는 원칙을 설명한다. ## 제출량 증가와 품질 문제 - AI와 새로운 보안 도구로 보안 연구 진입 장벽이 낮아지면서 업계 전반의 버그 바운티 제출량이 크게 증가했다. - 정당한 취약점이 늘어난 긍정적 효과도 있지만, 다음과 같은 저품질 보고서도 급증했다. - 실제 동작하는 개념 증명(PoC)이 없음 - 검증되지 않은 이론적 공격 시나리오 - GitHub가 이미 공개한 부적격 항목에 해당 - 보안 영향이 구체적으로 입증되지 않음 - GitHub는 프로그램을 중단하는 대신 제출 품질을 높이는 방향으로 대응한다. ## 강력한 취약점 보고서의 조건 - **작동하는 PoC와 실제 보안 영향** - 단순히 “이론적으로 가능하다”고 설명하는 데 그치지 않아야 한다. - 공격자가 실제로 무엇을 할 수 있는지 재현해야 한다. - 보안 경계를 넘을 수 있다는 사실과 구체적인 결과를 보여줘야 한다. - **범위와 부적격 항목 확인** - 제출 전에 GitHub의 버그 바운티 범위와 부적격 목록을 검토해야 한다. - DMARC/SPF/DKIM 설정 문제, 사용자 열거, 공격 경로가 입증되지 않은 보안 헤더 누락 등은 부적격 사례다. - 이런 보고서는 “해당 없음(Not Applicable)”으로 종료될 수 있으며 HackerOne Signal과 평판에 영향을 줄 수 있다. - **제출 전 직접 검증** - 스캐너, 정적 분석 도구, AI가 발견한 결과라도 사람이 재현하고 확인해야 한다. - 검증되지 않은 오탐은 트리아지 리소스를 낭비하는 잡음에 불과하다. ## AI 활용은 허용되지만 책임은 연구자에게 있음 - GitHub는 AI를 보안 연구에 사용하는 것을 금지하지 않는다. - AI는 공격 표면을 탐색하고 후보 취약점을 찾는 생산성 도구로 활용될 수 있다. - 다만 AI가 생성한 결과도 다음 조건을 충족해야 한다. - 실제 환경에서 검증 - 재현 가능성 확인 - 작동하는 PoC 제공 - 구체적인 보안 영향 설명 - AI뿐 아니라 스캐너와 정적 분석 도구의 결과에도 동일한 기준이 적용된다. - 도구가 아니라 결과물의 정확성과 품질이 평가 대상이며, 보고서의 정확성에 대한 최종 책임은 연구자에게 있다. ## 간결하고 구조화된 보고서 작성 강한 보고서는 다음 세 요소를 포함해야 한다. - **짧은 문제 요약** - **명확한 재현 절차와 증거** - 스크린샷 - HTTP 요청 - 터미널 출력 등 - **영향 설명** - 공격자가 실제로 달성할 수 있는 결과를 구체적으로 기술 반대로 긴 이론적 서술, 이미 알려진 배경의 반복, AI가 생성한 불필요한 문장은 핵심 취약점을 묻히게 해 처리 속도를 늦춘다. ## GitHub의 공유 책임 보안 모델 GitHub는 악성 콘텐츠를 탐지하고 처리하기 위해 자동 스캐닝과 수동 검토 등 다양한 방어 체계를 운영한다. 그러나 모든 콘텐츠를 사전에 신뢰할 수 있는 것은 아니므로, 사용자와 GitHub가 보안을 함께 책임지는 공유 책임 모델을 적용한다. 사용자에게 기대되는 책임은 다음과 같다. - 신뢰할 저장소, 이슈, 코드를 신중하게 선택 - 코드·스크립트·워크플로 등 실행 가능한 콘텐츠를 실행하기 전 검토 - 저장소를 클론하는 행위가 해당 코드에 대한 신뢰를 선택하는 것임을 이해 - 토큰, 자격 증명, 로컬 보안 설정을 안전하게 관리 사용자가 악성 저장소를 직접 클론하거나, 악성 파일을 열거나, 신뢰하지 않는 코드를 AI 도구에 분석하도록 제공해야만 문제가 발생한다면, 이는 대체로 GitHub의 보안 통제를 우회한 사례로 간주되지 않는다. ## 공유 책임 영역의 대표 사례 - 사용자가 직접 AI 도구에 제공한 콘텐츠를 이용한 프롬프트 인젝션 - 사용자가 체크아웃한 저장소에서 Git 훅이나 필터가 코드 실행 - 사용자가 클론한 저장소에 포함된 악성 콘텐츠 - 사용자가 제공한 신뢰할 수 없는 입력을 처리하는 LLM의 예기치 않은 출력 이러한 연구도 가치가 있지만, 실제 보안 통제를 우회해 사용자가 악성 콘텐츠를 적극적으로 신뢰하지 않아도 피해가 발생하는지 입증해야 의미 있는 취약점 보고서가 된다. 실무적으로는 AI나 자동화 도구를 적극 활용하되, 제출 전 반드시 수동 재현과 영향 검증을 수행하는 것이 좋다. 보고서는 “요약-재현 절차-실제 영향” 중심으로 간결하게 작성하고, GitHub의 범위·부적격 목록과 사용자 신뢰가 전제된 보안 모델을 먼저 확인해야 한다.

원문 읽기(새 탭에서 열림)
githubGitai-securitystatic-analysis+4
line3분 읽기큐레이션 요약

ODW #6: Git 자동화 관점에서 본 MCP와 에이전트 스킬의 장단점

AI 에이전트 개발에서는 MCP 서버보다 에이전트 스킬이 구현과 아키텍처 측면에서 간단해지는 추세다. 글은 `skill-creator`를 활용해 Git 릴리스 자동화 스킬을 만들고, 요구사항을 구체화하는 과정을 실무 예제로 설명한다. 핵심은 명확한 프롬프트와 로컬 Python 스크립트를 결합해 반복 작업을 자동화하는 것이다. ## MCP에서 에이전트 스킬로의 전환 - MCP 서버 구축보다 에이전트 스킬이 구현하기 쉽고 구조가 단순하다. - 기본 개념이나 대규모 GitHub 예제는 많지만, 일상 업무에 적용하는 실용적인 안내는 부족하다. - 이 글은 스킬 자체의 개념을 깊게 설명하기보다 실제 예제를 만들며 활용 방법을 보여주는 데 초점을 둔다. ## Git 스마트 릴리스 자동화 스킬 - 현재 디렉터리의 Git 프로젝트를 자동으로 릴리스하는 스킬을 예제로 선택했다. - `skill-creator`를 사용해 스킬 정의와 실행 스크립트를 자동 생성한다. - 핵심 작업 흐름은 다음과 같다. - 가장 최근 태그 이후의 `git log` 분석 - 변경 사항을 요약해 `CHANGELOG.md` 최상단에 추가 - `pyproject.toml`의 버전 변경 - 변경 파일 커밋 - 새 버전 태그 생성 - 스킬은 현재 터미널 경로인 `pwd`를 기준으로 동작하는 로컬 Python 스크립트 형태로 구성한다. ## 명확한 요구사항의 중요성 - 에이전트가 엉뚱한 디렉터리를 수정하거나 과도하게 복잡한 계획을 세우지 않도록 목표와 제약 조건을 프롬프트에 구체적으로 작성해야 한다. - 초기 요구사항에는 다음 내용이 포함된다. - `v0.1.0` 등 최근 태그 이후의 커밋 조회 - `CHANGELOG.md`가 없으면 새로 생성 - 버전을 patch 단위로 증가 - `chore: release v[새 버전]` 형식으로 커밋 - 새 버전의 Git 태그 생성 - 현재 작업 경로에서만 실행 ## 대화형 요구사항 구체화 에이전트는 모호한 부분을 질문하고, 사용자는 답변을 통해 스킬 동작을 확정한다. - 버전 증가 방식 - patch, minor, major 모두 지원 - 사용자가 원하는 릴리스 유형을 선택 - 최초 릴리스 - 기존 태그가 없으면 `v0.1.0`부터 시작 - 변경 로그 - Keep a Changelog 형식을 따름 - 버전, 날짜, `feat`, `fix`, `docs` 등의 변경 분류를 포함 - 원격 저장소 - 로컬 커밋과 태그 생성 후 원격 저장소에도 push - 작업 디렉터리 안전성 - 커밋되지 않은 변경 사항이 있으면 작업을 중단 - 중단 이유를 사용자에게 설명 ## 생성된 스킬의 구조 - `git-smart-release/SKILL.md` - 스킬의 메타데이터와 에이전트가 따라야 할 실행 절차를 담는다. - `git-smart-release/scripts/smart_release.py` - Git 명령 실행, 파일 수정, 버전 변경 등 실제 작업을 수행한다. - `git-smart-release/evals/evals.json` - 스킬 동작을 검증하기 위한 테스트 케이스를 담는다. ## SKILL.md와 실행 스크립트의 역할 - 프런트매터 - YAML 형식의 메타데이터다. - 에이전트가 스킬을 언제 사용할지 판단할 수 있도록 짧은 설명과 검색 정보를 제공한다. - 마크다운 본문 - 스킬 사용이 결정된 뒤 읽히는 실행 매뉴얼이다. - 구체적인 절차와 워크플로를 정의한다. - `smart_release.py` - Git 상태 확인, 로그 분석, 파일 변경, 커밋과 태그 생성 등을 직접 처리한다. - LLM이 모든 파일 내용을 직접 읽고 수정하는 대신 결정된 작업을 코드로 실행해 토큰 사용과 오류를 줄인다. ## 실무 적용 방식 - 사용자는 “릴리스해 줘”처럼 자연어로 요청할 수 있다. - 에이전트는 요청에 맞는 버전 유형을 선택하고 스킬 지침을 따른다. - 스크립트는 먼저 작업 디렉터리가 깨끗한지 확인한다. - 변경 사항이 있으면 안전을 위해 중단하고, 문제가 없을 때만 변경 로그 작성부터 커밋·태그·원격 push까지 진행한다. - 글은 이후 Python 계산기 프로젝트를 대상으로 제작한 스킬을 테스트하는 시나리오로 이어진다. 반복적인 Git 릴리스 업무를 자동화하려면 요구사항, 예외 처리, 실행 범위를 프롬프트에 명확히 적고, 실제 파일·Git 조작은 검증 가능한 스크립트로 분리하는 것이 좋다. 특히 자동 push 기능은 되돌리기 어려우므로 dirty check와 실행 전 확인 절차를 함께 두는 것을 권장한다.

원문 읽기(새 탭에서 열림)
모델 컨텍스트 프로토콜Pythonclaude-codeGit+3
aws3분 읽기큐레이션 요약

Amazon Bedrock, 새로운 고급 프롬프트 최적화 및 마이그레이션 도구 출시 | Amazon Web Services

Amazon Bedrock의 **Advanced Prompt Optimization**은 여러 모델에서 프롬프트를 자동으로 개선하고, 기존 프롬프트와 최적화된 프롬프트의 성능을 비교하는 도구입니다. 사용자는 예시 입력, 정답 데이터, 평가 기준을 제공하면 되며, 모델 마이그레이션이나 현재 모델의 성능 개선에 활용할 수 있습니다. 최적화 결과로 프롬프트, 평가 점수, 비용 추정치, 지연 시간이 함께 제공됩니다. ## 여러 모델을 동시에 비교하는 프롬프트 최적화 - 최대 5개의 Amazon Bedrock 추론 모델을 선택할 수 있습니다. - 새 모델로 마이그레이션하는 경우: - 현재 모델을 기준선으로 선택 - 최대 4개의 후보 모델과 성능 비교 - 모델을 변경하지 않는 경우에도 현재 모델의 최적화 전후 결과를 비교할 수 있습니다. - 알려진 사용 사례에서 성능 저하가 없는지 확인하거나, 성능이 낮은 작업을 개선하는 데 사용할 수 있습니다. ## 입력 데이터와 JSONL 템플릿 - 프롬프트 템플릿은 JSONL 형식으로 준비해야 합니다. - 각 JSON 객체는 한 줄에 작성해야 합니다. - 주요 필드는 다음과 같습니다. - `version`: 고정값 `bedrock-2026-05-14` - `templateId`: 프롬프트 템플릿 식별자 - `promptTemplate`: 최적화할 프롬프트 - `evaluationSamples`: 입력 변수와 선택적 기준 응답 - `steeringCriteria`: 자연어 기반 최적화 기준 - `customLLMJConfig`: 사용자 정의 LLM 평가 설정 - `evaluationMetricLambdaArn`: Lambda 기반 평가 함수 - 파일은 직접 업로드하거나 Amazon S3에서 가져올 수 있습니다. - 최적화 결과와 평가 데이터가 저장될 S3 출력 위치도 지정할 수 있습니다. ## 멀티모달 프롬프트 지원 - 텍스트 입력뿐 아니라 이미지와 문서가 포함된 프롬프트도 최적화할 수 있습니다. - 지원 파일 형식: - PNG - JPG - PDF - `inputVariablesMultimodal` 필드에 파일 유형과 S3 URI를 지정합니다. - 문서 분석, 이미지 분석과 같은 멀티모달 작업의 프롬프트 개선에 적합합니다. ## 평가 방식 세 가지 ### Lambda 기반 사용자 정의 평가 - 정확도, F1 점수, 실행 정확도, 구조화된 JSON 일치 여부처럼 명확한 수치 평가에 적합합니다. - Python으로 작성한 Lambda 함수에서 모델 응답과 기준 응답을 비교합니다. - `evaluationMetricLambdaArn`을 통해 평가 Lambda를 연결합니다. - 핵심 로직은 모델 출력과 정답을 비교해 점수를 계산하는 `compute_score` 구현입니다. ### LLM-as-a-Judge 평가 - 요약, 생성, 추론 설명처럼 정답이 하나로 정해지지 않은 작업에 적합합니다. - 사용자 정의 평가 프롬프트와 평가 기준, 점수 척도를 설정할 수 있습니다. - Bedrock의 평가 모델이 각 프롬프트와 응답을 평가하고 점수와 판단 근거를 반환합니다. - 기본 평가 모델은 Claude Sonnet 4.6이며, 지원되는 다른 평가 모델을 선택할 수도 있습니다. - 설정은 `customLLMJConfig`에 지정합니다. ### 자연어 기반 Steering Criteria - 브랜드 문체, 출력 형식, 안전 제약 등 원하는 품질을 자연어로 설명할 때 사용합니다. - 직접 복잡한 평가 프롬프트나 점수 체계를 작성하지 않아도 됩니다. - `steeringCriteria` 배열에 원하는 기준을 입력합니다. - 기본 LLM 평가 프롬프트가 해당 기준을 반영해 응답을 종합적으로 평가합니다. - 이 방식에서도 Claude Sonnet 4.6이 평가 모델로 사용됩니다. ## 피드백 루프와 결과 확인 - Bedrock은 프롬프트와 예시 데이터를 선택한 모델에 전달합니다. - 모델 응답을 지정한 평가 방식으로 채점합니다. - 평가 결과를 바탕으로 프롬프트를 다시 작성합니다. - 이 과정을 반복해 평가 지표에 맞는 프롬프트를 탐색합니다. - 최종적으로 다음 정보를 확인할 수 있습니다. - 원본 및 최적화된 프롬프트 템플릿 - 모델별 평가 점수 - 예상 비용 - 응답 지연 시간 - 평가 데이터와 결과 ## 사용 방법과 제공 지역 - Amazon Bedrock 콘솔의 **Advanced Prompt Optimization** 페이지에서 `Create prompt optimization`을 선택합니다. - API를 사용하려면 `CreateAdvancedPromptOptimizationJob`을 호출합니다. - 미국, 아시아 태평양, 캐나다, 유럽, 남미의 여러 리전에서 제공됩니다. - 최적화 과정에서 사용된 Bedrock 모델 추론 토큰에 대해 일반 추론과 동일한 토큰 요금이 부과됩니다. 실무에서는 먼저 정확도나 JSON 일치처럼 측정 가능한 작업은 Lambda 평가로 시작하고, 요약·문체·안전성처럼 정성적인 작업은 LLM-as-a-Judge 또는 Steering Criteria를 사용하는 것이 적합합니다. 모델을 교체할 때는 기존 모델을 기준선으로 포함해 품질뿐 아니라 비용과 지연 시간까지 함께 비교하는 것이 좋습니다.

원문 읽기(새 탭에서 열림)
대규모 언어 모델amazon-bedrock멀티모달 AIamazon-s3+3
github1분 읽기큐레이션 요약

지연에서 즉시로: GitHub Issues 탐색 성능 현대화

Alexander는 GitHub Issues 팀의 시니어 소프트웨어 엔지니어로, 개발자 업무 흐름을 더 빠르고 즉각적으로 만드는 방법을 찾는 일을 즐긴다. 컴퓨터 그래픽스, 머신러닝, 지리공간 소프트웨어 등 다양한 분야의 경험을 바탕으로 현재 역할을 수행하고 있다. ### 경력과 전문 분야 - GitHub Issues 팀에서 시니어 소프트웨어 엔지니어로 근무한다. - 컴퓨터 그래픽스, 머신러닝, 지리공간 소프트웨어 등 여러 기술 분야를 경험했다. - 한 분야에 국한되지 않은 폭넓은 배경이 현재의 문제 해결 방식에 영향을 준다. ### 개발자 경험 개선 - 일상적인 개발자 업무를 “즉각적으로” 느껴지게 만드는 창의적인 방법을 찾는 것을 중요하게 여긴다. - 기술 자체뿐 아니라 개발자가 도구를 사용하는 과정의 속도와 편의성에 관심이 있다. - GitHub Issues와 같은 개발 협업 도구의 사용자 경험을 개선하는 데 전문성을 발휘한다.

원문 읽기(새 탭에서 열림)
머신러닝software-engineeringgithub-issuescomputer-graphics+1
cloudflare4분 읽기큐레이션 요약

청구 파이프라인이 갑자기 느려졌다. 원인은 ClickHouse의 숨겨진 병목이었다

Cloudflare는 ClickHouse의 파티션 키를 `(day)`에서 `(namespace, day)`로 변경해 테넌트별 보존 기간을 지원하려 했지만, 수 주 뒤 청구용 쿼리가 급격히 느려졌다. 디스크 I/O, 메모리, 스캔 행 수, 읽은 파트 수는 정상처럼 보였지만, 실제 원인은 쿼리 실행 전 계획 수립 단계에서 발생한 `MergeTreeData` 뮤텍스 경합이었다. 파티션 수 증가가 개별 쿼리의 읽기량을 늘리지는 않았지만, 모든 쿼리 스레드가 전체 파트 목록을 보호하는 하나의 잠금을 기다리면서 지연이 누적됐다. ## 페타바이트 규모의 Ready-Analytics 플랫폼 - Cloudflare는 수십 개 클러스터에서 100PB 이상의 ClickHouse 데이터를 운영한다. - 내부 팀의 온보딩을 단순화하기 위해 `Ready-Analytics`라는 대규모 공용 테이블을 구축했다. - 데이터는 `namespace`로 구분하고, 표준 스키마에 따라 저장했다. - 기본 키는 `(namespace, indexID, timestamp)`로 구성했다. - `namespace`: 데이터 소유 팀 또는 애플리케이션 구분 - `indexID`: 네임스페이스별 쿼리 패턴에 맞춘 정렬 기준 - `timestamp`: 시간 범위 조회 지원 - 2024년 12월 기준 2PiB 이상, 초당 수백만 행의 데이터가 유입되고 있었다. ## 단일 보존 정책의 한계 - 기존 시스템은 ClickHouse의 네이티브 TTL이 보편화되기 전부터 운영되어 자체 파티션 기반 보존 시스템을 사용했다. - 테이블은 날짜별로 파티셔닝되었고, 31일보다 오래된 파티션을 삭제했다. - 모든 네임스페이스에 동일한 31일 보존 기간이 적용됐다. - 법적·계약상 수년간 데이터를 보관해야 하는 팀과 며칠만 보관하면 되는 팀을 동시에 지원할 수 없었다. - 그 결과 일부 사용 사례는 Ready-Analytics 대신 별도의 테이블과 복잡한 온보딩 절차를 이용해야 했다. ## `(namespace, day)` 파티션으로의 변경 - 검토한 선택지는 두 가지였다. - 네임스페이스마다 별도 테이블을 생성하는 방식 - 기존 파티션 키를 `(day)`에서 `(namespace, day)`로 변경하는 방식 - 별도 테이블 방식은 수천 개의 테이블을 자동으로 생성·관리해야 하므로 운영 복잡도가 컸다. - 최종적으로 `(namespace, day)` 파티션을 선택했다. - 기존 보존 시스템을 재사용할 수 있었다. - 특정 네임스페이스의 오래된 데이터만 선택적으로 삭제할 수 있었다. - 설계 당시에는 전체 데이터 파트 수가 늘어날 것을 알고 있었지만, 모든 쿼리가 특정 `namespace`로 필터링되므로 개별 쿼리가 읽는 파트 수는 변하지 않을 것이라고 판단했다. - 따라서 쿼리 성능도 크게 변하지 않을 것으로 예상했다. - 이 구조는 디스크 사용량을 네임스페이스별로 관리하는 기반도 제공했다. - max-min fairness 알고리즘으로 여유 디스크를 네임스페이스 간에 공유 - 목표 디스크 사용률을 90% 수준으로 유지 - 2025년 1월부터 마이그레이션을 시작했고, ClickHouse의 `Merge` 테이블 기능을 활용해 구 테이블과 신 테이블을 함께 운영하며 데이터를 이전했다. ## 청구 작업에서 드러난 성능 저하 - 2025년 3월 말, 마이그레이션 약 두 달 뒤 청구 팀이 일일 집계 작업의 지연을 보고했다. - 청구 작업은 정해진 시간 내 완료되지 않으면 청구서 발행이 지연되므로 강한 마감 시간이 있었다. - 성능 저하는 점진적으로 심해졌지만 일반적인 원인은 발견되지 않았다. - I/O 문제 없음 - 메모리 부족 없음 - 쿼리별 스캔 행 수 변화 없음 - 읽은 데이터 파트 수 증가 없음 - 전체 클러스터의 파트 수와 평균 `SELECT` 쿼리 시간을 비교한 결과, 두 지표 사이에 뚜렷한 상관관계가 나타났다. - 즉, 쿼리가 직접 읽지 않는 파트라도 테이블에 존재하는 것만으로 성능에 영향을 주고 있었다. ## Flame Graph로 찾은 쿼리 계획 병목 - ClickHouse의 `trace_log`를 이용해 쿼리 실행 중 어떤 코드가 시간을 사용하는지 분석했다. - `trace_log`는 실행 코드뿐 아니라 사용자, 쿼리 ID 등의 메타데이터도 제공해 특정 리프 `SELECT` 쿼리를 대상으로 분석할 수 있었다. - CPU 샘플 기반 Flame Graph에서는 쿼리 계획 단계에 상당한 시간이 소요되는 것이 확인됐다. - 특히 `filterPartsByPartition` 함수가 샘플 CPU 시간의 약 45%를 차지했다. - 파트 제거 휴리스틱의 실행 순서를 바꾸는 패치를 적용했지만 성능 향상은 약 5%에 그쳤다. - 이후 실행 중인 스레드만 측정하는 CPU trace 대신, 대기 중인 스레드까지 포함하는 Real trace를 사용했다. - 그 결과 실제 병목은 CPU 연산이 아니라 잠금 대기임이 밝혀졌다. ## `MergeTreeData` 뮤텍스 경합 - 쿼리 실행 시간의 절반 이상이 `MergeTreeData` 뮤텍스를 획득하기 위해 대기하는 데 사용됐다. - 이 뮤텍스는 테이블의 활성 데이터 파트 목록을 보호한다. - 쿼리 계획을 수립할 때 각 스레드는 읽을 파트를 결정하기 위해 이 파트 목록에 접근해야 한다. - `(namespace, day)` 파티션 도입으로 전체 파트 수가 계속 증가하면서, 파트 목록을 대상으로 하는 계획 수립 작업과 잠금 경쟁도 함께 커졌다. - 따라서 개별 쿼리가 실제로 읽는 파트 수가 동일해도, 전체 테이블의 파트 수 증가만으로 쿼리 지연이 누적될 수 있었다. ## 실용적인 결론 ClickHouse에서 파티션 수는 저장 공간이나 데이터 스캔량뿐 아니라 쿼리 계획 단계의 내부 자료구조와 잠금 경합에도 영향을 준다. 파티션 키를 세분화할 때는 “쿼리당 읽는 파트 수”만 보지 말고 전체 파트 수 증가, 계획 수립 시간, 대기 시간까지 함께 추적해야 하며, CPU trace와 대기 스레드를 포함한 Real trace를 모두 활용하는 것이 중요하다.

원문 읽기(새 탭에서 열림)
clickhouselock-contentiondatabase-partitioningquery-planning+2