techlist.io
KREN

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

cloudflare4분 읽기큐레이션 요약

포스트양자 시대의 EO는 중요한 이정표다. 이제 실행에 옮길 때다

미국의 행정명령 14409호는 연방기관이 2030년까지 고위험 시스템의 암호화를, 2031년까지 디지털 서명과 인증을 양자내성암호(PQC)로 전환하도록 요구한다. 이는 양자컴퓨터가 현재의 RSA와 타원곡선 암호를 무력화할 가능성에 대비한 중요한 이정표이며, 특히 이미 진행 중인 암호화 전환과 달리 인증 전환은 지금부터 서둘러야 한다. 글은 각 기관이 자산을 조사하고 단계적인 전환 계획을 세우되, 민간과 중요 인프라도 같은 준비를 시작해야 한다고 주장한다. ## 행정명령 14409호의 주요 요구사항 - 2026년 6월 22일 트럼프 대통령이 「첨단 암호 공격으로부터 국가 보호」 행정명령에 서명했다. - 대상은 주로 다음 두 종류의 연방 시스템이다. - **고가치 자산(HVA)**: 국가안보, 외교, 국민 신뢰에 중대한 영향을 주는 핵심 시스템 - **고영향 시스템**: FIPS 199 기준으로 기밀성·무결성·가용성의 영향도가 ‘높음’인 시스템 - 주요 일정은 다음과 같다. - **2026년 7월**: 각 기관이 PQC 전환 책임자를 지정 - **2026년 9월**: OMB가 자산 목록 검토, 전환 계획 수립 및 제출을 요구 - **2030년 12월**: HVA와 고영향 시스템의 키 설정을 PQC로 전환 - **2031년 12월**: 디지털 서명과 인증서를 PQC로 전환 - 국가안보시스템(NSS)은 행정명령의 일정에서 제외되며, NSA가 관리하는 별도 기밀 전환 일정이 적용된다. - 행정명령의 직접적인 법적 적용 대상은 연방기관이며, 주·지방정부, 중요 인프라, 학계, 시민사회에는 직접 의무를 부과하지 않는다. ## 양자컴퓨터가 만드는 시급성 - 양자컴퓨터가 충분히 발전하면 현재 인터넷에서 널리 쓰이는 **RSA와 타원곡선암호(ECC)**를 깨뜨릴 수 있다. - NIST는 2024년 기존 공개키 암호를 2030년까지 단계적으로 폐기하고 2035년까지 사용을 금지하는 방향을 제시했다. - 최근 연구 발전으로 ‘Q-Day’, 즉 암호학적으로 유의미한 양자컴퓨터가 등장하는 시점이 앞당겨질 가능성이 커졌다. - 미국 정부가 양자컴퓨팅 개발을 촉진하는 동시에 2031년까지 PQC 인증을 요구한 것은, 그 무렵 실용적인 양자컴퓨터가 등장할 가능성을 무시할 수 없다고 판단했음을 시사한다. ## 암호화와 인증은 서로 다른 전환이다 ### 포스트양자 암호화 - 양자컴퓨터에 안전한 키 설정과 암호화를 사용해 통신 내용을 보호한다. - 현재 가장 중요한 위협은 **‘지금 수집하고 나중에 복호화’** 공격이다. - 공격자가 오늘 암호화된 데이터를 저장해 두었다가, 미래에 양자컴퓨터로 복호화할 수 있다. - 다음과 같이 장기간 가치가 유지되는 데이터를 보유한 조직은 즉시 전환을 시작해야 한다. - 정부기관 - 은행 및 금융기관 - 의료기관 - 방위산업체 - 통신사업자 - 인터넷 전반에서 이미 전환이 진행 중이며, Cloudflare는 브라우저 트래픽의 3분의 2 이상에 PQC 암호화를 적용하고 있다고 설명한다. ### 포스트양자 인증 - 양자컴퓨터를 이용한 다음과 같은 위조 공격을 막는다. - 서버 인증서 위조 및 서버 사칭 - 악성 코드 서명 생성 - 시스템에 대한 무단 접근 - 암호화와 달리, 인증 공격은 실제로 강력한 양자컴퓨터가 등장해야 본격적으로 가능하다. - 그러나 인증 전환은 더 복잡하고 시간이 오래 걸리므로 Q-Day 이후가 아니라 지금부터 준비해야 한다. - ML-DSA 같은 PQC 디지털 서명은 기존 서명보다 크기가 커서 짧은 TLS 연결의 성능과 네트워크 비용에 영향을 줄 수 있다. - 인증 전환에는 다음 구성요소의 동시 업그레이드가 필요하다. - 클라이언트와 서버 - 인증기관(CA) - 인증서 투명성 로그 - 루트 저장소 - 웹 브라우저 - Cloudflare는 Google Chrome과 함께 Merkle Tree Certificates를 연구해 대형 PQC 서명이 TLS 성능에 미치는 영향을 줄이려 하고 있다. ## 표준화된 PQC와 QKD의 차이 - 행정명령이 NIST가 표준화한 PQC 알고리즘에 초점을 맞춘 점은 타당하다고 평가한다. - 양자키분배(QKD)는 다음 이유로 인터넷 전체에 적용하기 어렵다. - 특수 하드웨어가 필요하다. - 송신자와 수신자 사이에 전용 물리 링크가 필요하다. - 기존 인터넷 규모로 확장하기 어렵다. - 따라서 범용 인터넷과 연방 시스템의 현실적인 경로는 표준화된 PQC 알고리즘을 기존 암호 체계에 통합하는 것이다. ## Cloudflare가 제시하는 전환 현황 - Cloudflare는 2029년까지 암호화와 인증을 포함한 완전한 포스트양자 보안을 달성하는 것을 목표로 한다. - 대부분의 제품이 PQC 키 합의를 지원하며, Cloudflare One은 다음 연결 경로에 PQC 암호화를 제공한다. - TLS - MASQUE - IPsec - 암호화 전환은 이미 상당히 진행됐지만, 포스트양자 인증 배포는 아직 초기 단계다. - 글은 이번 행정명령이 이전 행정부와 민간 부문이 진행해 온 작업을 확대하는 기반이라고 평가한다. ## 실용적인 권고 - 조직은 먼저 공개키 암호가 사용되는 자산과 데이터를 목록화해야 한다. - 장기 보존 가치가 있는 데이터는 ‘수집 후 복호화’ 공격을 고려해 PQC 암호화를 우선 적용해야 한다. - 인증 전환은 인증서, 브라우저, 서버, CA 등 의존성을 함께 점검하고 장기 마이그레이션 계획을 세워야 한다. - 연방기관뿐 아니라 금융·의료·통신·방위 분야 조직도 2030~2031년 일정을 외부 기준으로 삼아 지금부터 테스트와 단계적 도입을 시작하는 것이 바람직하다.

원문 읽기(새 탭에서 열림)
post-quantum-cryptographyquantum-computingcryptographyelliptic-curve-cryptography+3
meta3분 읽기큐레이션 요약

메타는 AI 안경용 초슬림 배터리를 어떻게 설계했나

스마트 안경은 카메라, 스피커, AI, 디스플레이를 구동해야 하지만 배터리는 성인 새끼손가락보다 좁은 관자놀이 부분에 들어가야 한다. Meta는 기존 파우치형 배터리 대신 7mm 폭까지 줄인 초박형 스틸 캔 셀을 개발해 공간 활용도와 순간 출력 성능을 높였다. 세대별 배터리 용량 증가뿐 아니라 전력 관리, 펌웨어, 하드웨어 구조 개선을 함께 적용해 사용 시간을 크게 늘렸다는 것이 글의 결론이다. ## 스마트 안경에서 기존 배터리가 부족한 이유 - 스마트폰·노트북에 널리 쓰이는 파우치 셀은 형태를 자유롭게 줄이거나 변형하기 어렵다. - 내부 접힘 구조와 제조 공차가 좁은 공간을 차지해, 안경 다리처럼 폭이 제한된 부품에는 불리하다. - 셀 크기가 작아지면 카메라 촬영과 AI 작업을 동시에 수행할 때 필요한 순간적인 고출력을 안정적으로 제공하기 어렵다. - 따라서 배터리가 제품 형태에 맞춰 정확하고 견고하게 제작되어야 하며, 빈틈 없이 공간을 활용해야 한다. ## 7mm 폭의 스틸 캔 셀 개발 - 스틸 캔 배터리는 전동 공구나 시계 등에 사용되던 방식이지만, Meta는 기존에 없던 7mm 수준의 폭으로 축소했다. - 이를 위해 배터리 내부 부품의 구조와 제조 방식 대부분을 다시 설계했다. - 금속 캔은 형태를 일정하게 유지하므로 좁은 공간에서도 파우치 셀보다 정밀하게 배치할 수 있다. - 약 10mm 폭의 셀에서 형상 오차를 약 100마이크로미터 수준으로 관리하면, 회수한 공간이 추가 에너지 용량과 사용 시간으로 이어진다. ## 적층 전극으로 낮춘 임피던스 - 기존 스틸 캔 셀은 전극을 말아 만든 ‘젤리 롤’ 구조를 사용한다. - Meta는 전극을 정밀하게 절단해 여러 층으로 쌓는 구조를 적용했다. - 이는 작은 저항들을 병렬로 연결하는 것과 비슷한 효과를 내며, 배터리 임피던스를 크게 낮춘다. - 임피던스가 낮으면 카메라 녹화와 AI 처리처럼 전력 수요가 동시에 커질 때 전압이 급격히 떨어지는 브라운아웃을 줄일 수 있다. ## 세대별 용량 증가와 시스템 효율 - 1세대 Meta Ray-Ban의 배터리 용량은 160mAh였지만 2세대에서는 210mAh로 약 30% 증가했다. - 그러나 제품이 주장한 사용 시간은 약 2배로 늘었고, 이는 배터리 화학 조성의 변화만으로 설명되지 않는다. - 주요 개선 요소는 다음과 같다. - 전력 관리 최적화 - 펌웨어 제어 정밀화 - 더 큰 셀을 넣을 수 있는 제품 구조 - 하드웨어와 소프트웨어 전반의 에너지 효율 개선 ## 양쪽 관자놀이에 배터리를 넣은 Oakley Meta Vanguards - Oakley Meta Vanguards는 양쪽 관자놀이에 각각 배터리를 배치했다. - 두 셀은 대칭적으로 설계됐지만 실제 전자 부하가 좌우에 균등하게 분배되지는 않는다. - 이 때문에 한쪽 배터리가 다른 쪽으로 과도하게 충전되는 교차 충전 위험이 발생할 수 있다. - 부팅과 종료 과정에서도 두 배터리의 충전·방전 순서를 조정해야 하므로 전기, 펌웨어, 기계 설계가 함께 해결해야 하는 문제가 됐다. ## 디스플레이 탑재에 따른 새로운 전력 요구 - Meta Ray-Ban Display 안경은 화면이 추가되면서 가장 demanding한 전력 프로파일을 요구했다. - 카메라나 AI 작업처럼 순간적으로 전력을 많이 쓰는 기능과 달리, 디스플레이는 지속적으로 전력을 소비한다. - 이에 따라 Meta 제품군 중 가장 큰 248mAh 스틸 캔 셀이 설계됐다. - 이는 배터리 용량뿐 아니라 지속 출력 능력과 열·공간 제약까지 함께 고려해야 했음을 의미한다. ## 다른 웨어러블로의 확장 - 초박형 스틸 캔 기술은 스마트 안경 외에도 다양한 Meta 하드웨어 폼팩터에 적용될 가능성이 있다. - Meta는 여러 제조업체가 이 기술을 사용할 수 있도록 생산 규모를 키우고 공급망을 확대하려 한다. - 배터리 개발은 셀 자체의 화학 기술만으로 끝나지 않으며, 제품 설계·전력 관리 소프트웨어·제조 정밀도·규제 준수까지 통합적으로 다뤄야 한다. 작은 웨어러블의 배터리 성능을 높이려면 단순히 더 큰 배터리를 넣는 방식보다, 셀 구조를 제품에 맞게 재설계하고 전력 관리 소프트웨어까지 함께 최적화하는 접근이 효과적이다.

원문 읽기(새 탭에서 열림)
wearablessmart-glassesbattery-technologysteel-can-cells+3
github2분 읽기큐레이션 요약

내 일을 자동화했더니 (더 나은 리더가 되었다)

Ashley Willis는 GitHub의 개발자 관계 부문을 이끄는 수석 디렉터로, 오픈소스와 개발자 커뮤니티를 중심으로 활동하고 있습니다. 기술을 더 인간적으로 만들고, 기여자를 지원하며, 소외된 목소리를 대변하는 리더십을 강조합니다. 또한 접근성과 회복력 있는 팀 구축을 통해 실제 사용자에게 도움이 되는 도구와 환경을 만드는 데 집중합니다. ### 개발자 관계와 오픈소스 리더십 - GitHub에서 개발자 관계(Developer Relations) 조직을 이끕니다. - 오픈소스 생태계와 커뮤니티에 대한 깊은 관심을 바탕으로 활동합니다. - 개발자의 참여와 기여를 촉진하는 환경을 만드는 데 주력합니다. ### 커뮤니티와 기여자 지원 - 기술을 사용하는 사람들의 경험을 중심에 둔 활동을 펼칩니다. - 오픈소스 기여자를 지원하고, 다양한 개발자들의 목소리를 확대합니다. - 기술 커뮤니티가 더 포용적이고 지속 가능하게 성장하도록 돕습니다. ### 포용성, 접근성, 팀의 회복력 - 소외되거나 충분히 대표되지 못한 집단의 목소리를 강조합니다. - 누구나 사용할 수 있는 접근성 높은 도구와 공간을 만드는 데 관심을 둡니다. - 변화와 어려움에 대응할 수 있는 회복력 있는 팀 문화를 구축합니다. ### 기술을 더 인간적으로 만들기 - 리더십과 기술 옹호 활동을 사람 중심의 관점에서 결합합니다. - 단순히 기능적인 도구를 넘어, 실제 사용자의 필요를 충족하는 기술을 지향합니다. - 개발자와 커뮤니티를 배려하는 태도를 기술 조직 운영의 핵심 가치로 삼습니다. 결국 이 글은 Ashley Willis를 기술 전문성뿐 아니라 사람, 커뮤니티, 포용성을 중시하는 개발자 관계 리더로 소개합니다. 기술 조직은 제품 개발과 함께 기여자 지원, 접근성, 다양한 목소리의 반영도 함께 고려해야 한다는 점을 시사합니다.

원문 읽기(새 탭에서 열림)
오픈 소스접근성githubdeveloper-relations
naver1분 읽기큐레이션 요약

SNOW의 Automatic Sharding 도입기

글에는 기술적 내용이나 주장이 포함되어 있지 않으며, NAVER D2 관련 메뉴와 안내 항목만 나열되어 있습니다. 따라서 특정 기술, 사례, 결론을 요약할 수 있는 본문은 확인되지 않습니다. ### NAVER D2 사이트 구성 - `Hello world` - `D2 News` - `About D2` - `NAVER Developers` - `DEVIEW` - `OpenSource` - `D2 STARTUP FACTORY` ### 저작권 안내 - NAVER Corp.가 저작권을 보유하고 있습니다. - 저작권 표기는 “Copyright © NAVER Corp. All Rights Reserved.”로 되어 있습니다. 실질적인 기술 블로그 글을 요약하려면 본문 내용이 추가로 필요합니다.

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

개발을 넘어 AI로 사회문제를 해결하다

이번 글은 카카오와 삼성전자가 공동 개최한 AI 해커톤을 통해, 개발 역량을 사회문제 해결과 연결한 사례를 소개합니다. 참가자들은 AI 민생 10대 프로젝트를 주제로 실제 서비스 프로토타입을 개발하며 문제 정의, 협업, 전문가 피드백의 중요성을 경험했습니다. 글은 이러한 실전형 협력이 AI 시대의 개발자 양성과 사회적 가치 창출을 동시에 이루는 출발점이라고 결론짓습니다. ## 카카오·삼성 공동 AI 해커톤의 배경 - 2026년 6월 13~14일 경기도 용인 카카오 AI캠퍼스에서 개최됐습니다. - 카카오테크 부트캠프와 삼성 청년 SW·AI 아카데미(SSAFY)가 처음으로 공동 주최했습니다. - 두 기관 모두 고용노동부 K-디지털 트레이닝 사업을 기반으로 디지털 인재를 양성하고 있습니다. - 예선을 통과한 12개 팀, 약 90명의 교육생이 참여했습니다. - 단순한 개발 경연을 넘어 서로 다른 교육 배경의 참가자들이 협업하고 성장하는 것을 목표로 했습니다. ## AI 민생 10대 프로젝트와 사회문제 해결 - 참가자들은 정부가 선정한 ‘AI 민생 10대 프로젝트’ 중 하나를 주제로 선택했습니다. - 주요 문제 영역은 다음과 같습니다. - 소상공인 지원 - 보이스피싱 대응 - 아동·청소년 보호 - 해양 안전 - 제한된 시간 안에 문제를 정의하고 사용자 관점에서 해결책을 설계했습니다. - AI 기술을 적용한 서비스 모델을 실제 프로토타입으로 구현했습니다. - 기술 자체의 활용보다 AI가 어떤 사회적 가치를 만들어낼 수 있는지에 초점을 맞췄습니다. ## 정부·현업 전문가의 실전형 멘토링 - 경찰청, 법무부, 여성가족부 등 정부 부처 담당자들이 멘토로 참여했습니다. - 참가자들은 정책과 현장의 요구사항을 직접 확인하고 질의응답을 진행했습니다. - 카카오 현업 개발자들은 특강과 기술 멘토링을 제공했습니다. - 전문가 피드백을 통해 아이디어의 현실성, 서비스 완성도, 문제 해결 방향을 개선했습니다. - 교육 과정에서 배운 기술을 실제 공공 문제에 적용하는 경험을 제공했습니다. ## 서로 다른 배경의 개발자 간 협업 - 카카오테크 부트캠프와 SSAFY는 서로 다른 교육 방식과 경험을 가진 참가자들을 배출해왔습니다. - 참가자들은 처음 만난 동료들과 역할을 나누고 아이디어를 발전시켰습니다. - AI를 결과물 제작에 어떻게 활용할지 논의하며 새로운 개발 방식을 실험했습니다. - 다양한 경험과 관점을 공유하면서 기존에 생각하지 못했던 해결책을 발견했습니다. - 기술 역량뿐 아니라 소통, 협업, 공동 문제 해결 능력의 중요성을 체감했습니다. ## 수상작과 개발자 생태계 확장 - 최종 심사를 통해 총 5개 팀이 수상했습니다. - 고용노동부 장관상은 통신 두절 상황에서도 AI로 해상 구조를 지원하는 서비스 ‘DRIFT’를 개발한 ‘골든타임’ 팀이 받았습니다. - 카카오 대표이사상은 AI 기반 민원 접수·처리 서비스 ‘민담’을 개발한 ‘SSAIKA’ 팀이 수상했습니다. - 전체 상금은 1,500만 원 규모였습니다. - 카카오는 2022년부터 660명 이상의 디지털 인재를 양성해왔으며, 이번 행사를 통해 SSAFY와 교육 경험을 연결했습니다. - 기업 간 경쟁보다 인재 양성과 사회적 가치 창출을 위한 협력 모델을 제시했다는 데 의미가 있습니다. ## 미래 개발자에게 필요한 역량 - AI 시대에는 단순한 코딩 능력만으로는 충분하지 않습니다. - 중요한 역량은 다음과 같습니다. - 사회문제를 발견하고 정의하는 능력 - 사용자 관점에서 해결책을 설계하는 능력 - AI 기술을 실제 서비스에 적용하는 능력 - 다양한 배경의 사람들과 협업하는 능력 - 기술의 사회적 영향과 가치를 고려하는 태도 - 실전 프로젝트와 전문가 멘토링은 이러한 역량을 짧은 시간 안에 종합적으로 경험하게 합니다. 개발자 교육과 해커톤은 최신 기술 구현에만 머물지 않고, 실제 사회문제를 해결하는 방향으로 설계될 필요가 있습니다. 교육기관과 기업이 협력해 현장 전문가, 사용자, 개발자가 함께 참여하는 프로젝트를 확대한다면 기술 인재 양성과 사회적 가치 창출을 동시에 달성할 수 있습니다.

원문 읽기(새 탭에서 열림)
AIsoftware-developmentcollaborationai-hackathon+2
stripe4분 읽기큐레이션 요약

HITEC 2026에서 본 여행 및 호스피탈리티 트렌드 네 가지

호텔 업계의 AI 투자는 빠르게 확대되고 있지만, 실제로 핵심 운영에 AI를 통합하고 투자수익률을 입증한 기업은 10% 미만이다. 성공의 걸림돌은 모델 성능보다 데이터 단절, 낡은 결제 인프라, 실제 업무 흐름과 연결되지 않은 기술에 있다. 앞으로는 검색 최적화보다 AI 답변에 노출되는 구조화된 데이터, 원활한 결제, 눈에 띄지 않게 작동하는 개인화 기술이 경쟁력을 좌우할 전망이다. ## AI 시대의 직접 예약 경쟁 - 기존 호텔 업계는 SEO와 검색 순위 개선을 통해 Expedia, Booking.com 같은 OTA를 거치지 않고 직접 예약을 유도했다. - 그러나 AI Overview가 포함된 Google 검색의 65%는 사용자가 웹사이트를 클릭하지 않고 종료되며, 모바일에서는 이 비율이 78%까지 높아진다. - 업계의 전통적인 검색 트래픽은 약 25% 감소하고 있어, 키워드와 백링크 중심의 SEO만으로는 충분하지 않다. - AI 모델에 노출되려면 다음 정보가 정확하고 기계가 읽기 쉬운 형태로 제공되어야 한다. - 객실 유형과 세부 조건 - 편의시설 - 취소 및 환불 정책 - 주변 지역 정보 - 실시간 재고와 요금 - 숙박업체 사이트의 90% 이상이 아직 AI 모델에 제대로 탐지되지 않는다. - 여행자의 56%가 최근 1년 동안 여행 계획, 예약 또는 현지 지원에 AI를 사용했다. - 따라서 대규모 AI 투자보다 먼저, 주요 AI 서비스가 자사 호텔을 정확히 설명하고 있는지 데이터 감사를 수행해야 한다. - AI 검색 노출만으로는 부족하며, 현지 결제수단·통화, 원클릭 결제, 사기 방지 기능을 갖춘 결제 과정까지 연결해야 예약 전환이 가능하다. ## 호텔 AI의 병목은 모델보다 데이터 연결성 - 많은 호텔이 AI 기능을 도입하고 있지만, 전략과 데이터 기반, 운영 아키텍처가 부족해 안정적으로 확장하지 못하고 있다. - 주요 시스템이 분리되어 있어 동일 고객에 대한 정보가 여러 곳에 흩어진다. - PMS(호텔 운영 시스템) - CRM - 멤버십·로열티 시스템 - 식음료 시스템 - 결제 시스템 - 이로 인해 AI 개인화가 부정확해지고, 재무팀의 대사 업무가 늘며, 고객 프로필이 불완전해지고, 고객 경험에도 마찰이 발생한다. - 중요한 것은 AI를 만드는 것보다 실제 운영 환경에서 안정적으로 실행하는 ‘AI 운영화’다. - 효과적인 기업은 정제되고 연결된 데이터를 업무 흐름 안에 제공해 직원이 적시에 행동하도록 만든다. - 예를 들어: - Delta Air Lines는 고객 프로필과 운영 데이터를 활용한 AI 컨시어지를 모바일 앱의 고객 지원 과정에 통합했다. - Wynn Las Vegas는 목표 대비 실적이 하락할 때 수익 관리자에게 예측 알림과 구체적인 대응 방안을 함께 제공한다. - 즉, 대부분의 여행 기업에서 우선 해결해야 할 문제는 더 좋은 AI 모델이 아니라 데이터의 통합과 업무 시스템 연결이다. ## 결제 인프라가 예약과 고객 경험을 좌우한다 - 호텔 업계는 결제를 단순한 비용과 운영 기능으로 취급해왔지만, 이제 결제 방식 자체가 성장과 경쟁력의 요소가 되고 있다. - 호텔 경영진 설문에서: - 90%는 결제가 성장에 중요하다고 답했다. - 37%는 결제수단 부족이 고객 경험을 가장 크게 해치는 요인이라고 답했다. - 58%는 사기 방지 시스템이 정상 거래까지 차단한다고 답했다. - 74%는 결제 시스템 분절로 대사 업무에 과도한 시간이 든다고 답했다. - 특정 국가에서 널리 쓰이는 결제수단을 지원하지 않으면 고객은 결제가 가능한 OTA나 다른 플랫폼으로 이동한다. - 대형 OTA는 결제 전문 인력을 대규모로 운영할 수 있지만, 독립 호텔이나 소규모 사업자는 같은 방식으로 투자하기 어렵다. - 대신 적절한 결제 인프라를 사용하면 적은 인력으로도 여러 국가의 결제수단, 통화, 사기 방지 기능을 운영할 수 있다. - 결제 범위의 작은 차이가 직접 예약을 잃고 OTA에 고객을 빼앗기는 결과로 이어질 수 있다. ## 성공적인 기술은 고객에게 보이지 않는다 - 고객은 작동하지 않는 기술에 큰 불만을 느끼며, 반드시 항의하지 않더라도 재방문하지 않을 수 있다. - 기술의 성공 기준은 고객이 기술의 존재를 인식하지 못할 정도로 자연스럽게 작동하는 것이다. - 이상적인 개인화 경험의 예시는 다음과 같다. - 고객이 도착하기 전에 객실 온도가 선호 수준으로 설정됨 - TV에 선호 채널이 표시됨 - 선호하는 베개가 준비됨 - 고객이 매번 자신의 취향을 직접 입력하지 않아도, 과거 투숙·멤버십·운영 데이터를 바탕으로 필요한 서비스를 예측해야 한다. - 다만 개인화는 “AI가 무엇을 했는지”를 과시하는 방식보다, 자연스럽고 방해 없이 서비스에 녹아드는 방식이 효과적이다. ## 실무적인 시사점 호텔과 여행 기업은 유행하는 AI 기능을 무작정 추가하기보다, 먼저 고객·객실·재고·결제 데이터를 통합해야 한다. 이후 AI 검색에서 자사 정보가 정확히 노출되는지 점검하고, 선호 결제수단을 지원하며, 예측 결과가 실제 직원 업무와 자동화된 조치로 이어지는지 확인하는 것이 우선이다. საბოლო적으로 경쟁력 있는 기술은 가장 화려한 기술이 아니라 예약을 늘리고 운영을 단순화하면서 고객이 불편을 느끼지 않게 하는 기술이다.

원문 읽기(새 탭에서 열림)
AI대규모 언어 모델AI 에이전트seo+4
netflix5분 읽기큐레이션 요약

더욱 정교하게 제어할 수 있는 AI 영상 편집을 향해: 넷플릭스의 초기 연구 탐색

넷플릭스는 AI가 영상 전체를 무분별하게 재생성하지 않고, 창작자가 지정한 부분만 정밀하게 수정해야 전문적인 영상 편집에 활용될 수 있다고 주장합니다. 이를 위해 편집 영역만 별도 레이어로 생성하는 Vera와, 객체를 제거한 뒤 물리적으로 자연스러운 장면을 복원하는 VOID를 제안했습니다. 두 연구의 목표는 원본 영상의 정체성·연기·배경을 보존하면서도 복잡한 편집 작업을 자동화해 창작자의 통제력을 높이는 것입니다. ## 전문 영상 편집에서 AI가 겪는 문제 - 기존 생성형 비디오 편집 모델은 수정 대상뿐 아니라 영상 전체의 픽셀을 다시 생성하는 경우가 많습니다. - 그 결과 다음과 같은 의도하지 않은 변화가 발생할 수 있습니다. - 인물의 얼굴이나 정체성 변화 - 배우의 연기와 동작 변형 - 배경, 소품, 장면의 세부 정보 훼손 - 객체 제거 모델은 대상 객체를 지우는 데 집중한 나머지, 객체가 장면의 물리적 상호작용에 미친 영향을 복원하지 못할 수 있습니다. - 그림자, 반사, 가려진 배경, 움직임의 연속성이 깨지면 객체를 제거한 결과가 부자연스럽게 보입니다. ## Vera: 편집 영역만 생성하는 레이어드 비디오 확산 모델 - Vera는 원본 영상 전체를 재생성하지 않고 다음 두 가지를 별도로 생성합니다. - **편집 레이어**: 새로 추가하거나 변경할 시각적 요소 - **알파 매트**: 편집 레이어가 적용될 영역을 나타내는 grayscale 마스크 - 생성된 레이어를 원본 영상과 합성하므로, 편집 영역 바깥의 원본 픽셀은 그대로 유지됩니다. - 텍스트 지시를 기반으로 다음과 같은 작업을 지원합니다. - 객체 추가 - 배경 변경 - 복잡한 장면의 시각적 요소 수정 - 이 방식은 원본 인물의 정체성, 연기, 카메라에 포착된 세부 사항을 보존하는 데 유리합니다. ## Vera의 학습 데이터 구축 - 기존 공개 데이터셋에는 깨끗한 입력 영상, 알파 매트, 편집 레이어, 합성 결과를 함께 제공하는 고품질 레이어드 데이터가 부족했습니다. - 넷플릭스는 오픈소스 영상, 자동 처리, 사람의 품질 검수를 결합해 총 **48만 6천 프레임**, 해상도 **832×480** 규모의 데이터셋을 구축했습니다. - 데이터는 세 단계로 구성됩니다. - **합성 영상** - 고품질 전경 알파 매트를 다양한 자동 생성 배경에 합성 - 객체 추가와 배경 변경을 위한 알파 매트 학습에 활용 - **현실적인 단일 객체 영상** - 분할, 매팅, 배경 인페인팅 또는 생성 과정을 적용 - 사람의 품질 검수를 거쳐 다양한 장면과 카메라 움직임을 확보 - **효과가 포함된 다중 객체 영상** - 개별 객체와 함께 그림자·반사 같은 시각 효과도 분리 - 복잡하고 동적인 장면에서의 합성 성능을 개선 ## Vera의 MoT 모델 구조 - Vera가 생성해야 하는 출력은 서로 다른 특성을 가집니다. - 편집 레이어 - 알파 매트 레이어 - 자연스러운 합성 영상 레이어 - 하나의 공유 아키텍처만 사용하면 데이터 효율이 떨어질 수 있어, Vera는 **Mixture-of-Transformers(MoT)** 구조를 사용합니다. - 하나의 DiT 대신 출력별로 세 개의 DiT를 둡니다. - 각 분기는 독립적인 QKV projection과 FFN 가중치를 유지합니다. - 세 분기의 토큰을 결합한 뒤 joint self-attention을 적용해 서로 간의 상호작용을 가능하게 합니다. - 각 분기는 전문성을 유지하면서 다른 레이어의 정보도 활용합니다. - 세 DiT는 동일한 사전 학습 T2V 모델에서 초기화됩니다. - 추가 입력 처리 방식은 다음과 같습니다. - 원본 영상 토큰은 합성 레이어 토큰에 더해집니다. - 선택적 마스크 영상 토큰은 노이즈가 포함된 알파 토큰에 더해집니다. - 모든 레이어는 동일한 RoPE를 공유하며, 알파·합성 토큰에는 레이어를 구분하도록 0으로 초기화된 학습 임베딩을 추가합니다. ## Vera의 평가와 결과 - 평가용 벤치마크는 다음으로 구성되었습니다. - 객체 추가 72개 - 배경 변경 69개 - 느리고 빠른 움직임, 다양한 카메라 움직임, 단일·다중 객체, 단순·복잡한 장면을 포함합니다. - 성능은 세 기준으로 평가했습니다. - **콘텐츠 보존**: 편집 대상 바깥 영역이 변하지 않았는지 픽셀 및 지각적 유사도로 측정 - **지시문 준수**: 텍스트 프롬프트를 얼마나 정확히 실행했는지 평가 - **영상 품질**: 시간적 일관성과 프레임별 공간 품질 측정 - Vera-1.3B와 Vera-14B는 기존 기준 모델보다 콘텐츠 보존 성능에서 크게 우수했습니다. - 동시에 가장 강력한 기존 모델들과 비슷한 수준의 영상 품질과 지시문 준수 성능을 유지했습니다. ## VOID: 물리적으로 자연스러운 객체 제거 - VOID는 영상에서 객체와 객체가 장면에 미친 상호작용을 함께 제거하는 비디오 인페인팅 모델입니다. - 단순히 객체 영역을 지우는 것이 아니라 다음 요소까지 장면에 맞게 복원하는 것을 목표로 합니다. - 객체 뒤에 가려져 있던 배경 - 객체가 만든 그림자와 반사 - 주변 물체와의 물리적 상호작용 - 시간에 따른 움직임과 장면 연속성 - 따라서 결과 영상은 객체가 처음부터 존재하지 않았던 것처럼 보이도록 설계됩니다. ## 창작자 통제력을 중심에 둔 연구 방향 - 넷플릭스는 AI가 창작자의 의도를 대체하기보다 창작 선택을 확장해야 한다는 원칙을 강조합니다. - 영상 편집 도구는 무엇을 바꿀지뿐 아니라 무엇을 절대 바꾸지 않을지도 통제할 수 있어야 합니다. - Vera는 변경 범위를 레이어 단위로 제한하고, VOID는 제거 후 장면의 물리적 일관성까지 고려함으로써 전문 편집 환경에 필요한 예측 가능성과 보존성을 높이려는 접근입니다. - 연구진은 두 모델의 알고리즘과 실험 결과를 논문으로 공개해 후속 연구와 발전을 촉진하려 합니다. 실무적으로는 영상 전체를 재생성하는 방식보다, 편집 영역·보존 영역·합성 결과를 분리하는 구조가 원본 훼손을 줄이고 편집 결과를 더 쉽게 검수할 수 있습니다. 특히 객체 제거 작업에서는 시각적 삭제뿐 아니라 그림자, 반사, 가려진 배경, 시간적 움직임까지 함께 처리해야 자연스러운 결과를 얻을 수 있습니다.

원문 읽기(새 탭에서 열림)
생성형 AItransformercomputer-visiondiffusion-models+4
line4분 읽기큐레이션 요약

프롬프트 튜닝을 수작업에서 AI 튜닝으로: 유전 알고리즘 기반 자동 최적화와 고속화

프롬프트 튜닝은 반복적인 수작업과 개인 의존성 때문에 수일에서 수주가 걸리지만, 유전 알고리즘 기반의 GEPA를 적용하면 이를 약 한 시간으로 단축할 수 있다. GEPA는 후보 프롬프트를 여러 세대에 걸쳐 평가·변이하고, 점수뿐 아니라 자연어 피드백까지 활용해 개선 방향을 찾는다. LY Corporation은 이를 Yahoo! JAPAN Search의 건강·의료 쿼리에 적용해 정책 준수와 답변 가독성을 함께 최적화했다. ## 프롬프트 튜닝이 어려운 이유 - 프롬프트를 조금만 수정해도 출력을 다시 생성하고 사람이 품질을 판단해야 한다. - 수십~수백 개의 프롬프트 패턴을 시험하는 경우가 있어 반복 작업량이 크다. - “특정 표현이나 지시 순서가 효과적이다” 같은 노하우가 담당자 개인에게 남기 쉽다. - 개선 이유와 시행착오 과정이 기록되기 어려워 재현성과 설명 가능성이 떨어진다. - 모델 버전이 바뀌면 출력 품질도 변하므로 지속적인 재튜닝이 필요하다. - 사람이 직접 해야 할 정책 검증, 평가 기준 정리, 품질 판단에 충분한 시간을 쓰기 어렵다. ## 프롬프트 자동 최적화 방법 - 대표적인 접근법은 다음과 같다. - **강화 학습 기반**: 출력에 대한 스칼라 보상을 이용해 프롬프트 생성 정책을 학습한다. - **베이지안 최적화 기반**: 지시문과 퓨샷 예시를 탐색 공간으로 보고 효율적으로 후보를 선택한다. - **유전 알고리즘 기반**: 여러 프롬프트 후보를 집단으로 관리하며 세대별로 개선한다. - 자연어로 구성된 프롬프트는 이산적인 구조이므로 유전 알고리즘과 잘 맞는다. - 실행 결과와 평가 내용을 자연어로 분석하는 **리플렉션(reflection)**을 통해 단순 점수 이상의 개선 정보를 활용할 수 있다. ## GEPA의 진화적 최적화 루프 - 여러 후보 프롬프트를 생성하고 각 후보를 평가한다. - 점수가 높거나 여러 평가 축에서 균형이 좋은 후보를 선택한다. - 후보의 출력과 피드백을 자연어로 분석해 문제점을 찾는다. - **Reflective Prompt Mutation**을 사용해 기존 프롬프트를 개선한 변이 후보를 생성한다. - 이 과정을 수~수십 세대 반복하면서 평가 기준에 맞는 프롬프트로 수렴시킨다. - 여러 평가 관점을 동시에 고려하기 위해 **Pareto frontier 기반 선택**을 사용한다. - 스칼라 보상 하나에만 의존하는 방식과 달리, “왜 감점됐는가”라는 설명을 개선 과정에 반영할 수 있다. ## DSPy와 GEPA를 이용한 구현 - DSPy에서는 입력과 출력을 정의한 `Signature`, 실행 로직을 담은 `Module`, 예측을 수행하는 `Predict`를 구성한다. - 시그니처의 독스트링은 LLM에 전달되는 인스트럭션으로 사용된다. - GEPA는 이 인스트럭션을 자동으로 재작성해 최적화한다. - 최적화 과정에서 다음 모델을 분리해 설정할 수 있다. - **추론 모델**: 실제 답변을 생성하는 모델 - **평가 모델**: 생성 결과를 채점하는 모델 - **리플렉션 모델**: 평가 결과를 바탕으로 개선 프롬프트를 만드는 모델 - `num_candidates`, `num_generations` 등의 설정으로 후보 수와 세대 수를 조정한다. - 최적화는 학습 예제 집합을 대상으로 `optimizer.compile()`을 실행해 수행한다. ## 평가 함수와 자연어 피드백 - GEPA의 평가 함수는 기본적으로 `score`라는 단일 스칼라 값을 반환해야 한다. - 평가 기준이 여러 개라면 각 점수를 0~10 범위로 계산한 뒤 평균 등을 사용해 하나의 값으로 정규화한다. - 예를 들어 구체성, 정책 준수, 가독성의 점수를 합산해 전체 점수를 만들 수 있다. - 동시에 `feedback` 필드에 감점 이유와 개선 방향을 자연어로 전달할 수 있다. - 점수만 전달하면 “0.6점”이라는 결과만 알 수 있지만, 피드백을 주면 “의료 판단을 단정적으로 표현해 감점됐다”처럼 구체적인 원인을 알 수 있다. - 정답 데이터가 있다면 `gold`를 사용해 기대 출력이나 레이블과 비교할 수 있다. - 정답이 없는 경우에도 LLM-as-a-Judge나 규칙 기반 평가를 사용할 수 있다. - LLM-as-a-Judge를 사용할 때는 평가 기준을 명확히 작성하고, 출력 점수의 범위를 제한하는 등 평가 결과를 정규화해야 한다. ## Yahoo! JAPAN Search 건강·의료 쿼리 적용 - 건강·의료 답변은 일반 쿼리보다 정책 요구가 많다. - 주요 정책에는 다음이 포함된다. - 질병명이나 중증도를 단정하지 않기 - 근거 수준에 맞는 표현 사용하기 - 일반적인 설명 범위를 유지하기 - 필요할 때 의료기관 진료를 권유하기 - 허위 정보나 확증되지 않은 정보를 제공하지 않기 - 동시에 제목, 목록, 강조 등 마크다운 형식을 적용해 가독성도 높여야 했다. - 정책 준수와 가독성은 한쪽을 강화하면 다른 쪽이 약화될 수 있어 사람이 동시에 최적화하기 어렵다. ## 실제 최적화 방식과 기대 효과 - 초기 프롬프트에는 기존 범용 프롬프트와 건강·의료 정책 문구가 단순히 이어 붙어 있었다. - GEPA는 시그니처의 인스트럭션 부분을 재작성하며 두 목표를 동시에 최적화했다. - 평가 함수는 여러 품질 관점의 점수를 집계하고, LLM이 작성한 평가 이유를 리플렉션 피드백으로 제공했다. - 결과적으로 수일~수주가 걸리던 프롬프트 조정 작업을 약 한 시간으로 줄이는 것을 목표로 했다. - 모델 업데이트나 정책 변경 때도 동일한 평가·최적화 파이프라인을 다시 실행할 수 있어 유지보수 자동화에 유리하다. 프롬프트 최적화를 도입할 때는 먼저 정책과 품질 기준을 세분화하고, 점수뿐 아니라 구체적인 자연어 피드백을 평가 함수에 포함하는 것이 중요하다. 다만 LLM 평가자의 편향과 변동성이 결과에 영향을 줄 수 있으므로, 가능하면 규칙 기반 검사와 정답 데이터 기반 평가를 함께 사용해 최적화된 프롬프트를 별도로 검증하는 것이 권장된다.

원문 읽기(새 탭에서 열림)
대규모 언어 모델llm-as-a-judgeprompt-optimizationdspy+3
line5분 읽기큐레이션 요약

총 용량 1EB 초과! 서로 역사가 다른 두 HDFS를 어떻게 연결할까? 데이터 플랫폼 연계 중 직면한 과제와 설계 결정

LY Corporation은 구 LINE과 구 Yahoo Japan의 HDFS 클러스터를 통합해 1EB를 넘는 데이터 플랫폼을 운영하고 있습니다. 두 플랫폼은 같은 HDFS를 사용했지만 Namespace 구성, 권한 관리, 사용자 접근 방식이 달라 운영·연계 설계에서 서로 다른 과제가 발생했습니다. 대규모 환경에서는 단순한 용량 증설보다 NameNode 메타데이터, 소규모 파일, Balancer 트래픽, 클라이언트 접근 경로를 함께 관리해야 한다는 것이 글의 결론입니다. ## 구 LINE과 구 Yahoo Japan의 운영 모델 차이 - **구 LINE** - 여러 분석 환경을 통합한 Hadoop 3.x 기반 플랫폼을 구축했습니다. - 사용자가 HDFS 권한이나 Apache Ranger를 직접 다루지 않도록 웹 포털을 제공했습니다. - DB·테이블 중심의 데이터 카탈로그와 역할 기반 권한 신청·승인 구조를 사용했습니다. - BI, 리포팅, ETL 등 다양한 사용 방식을 지원했지만, 기존 클러스터를 Namespace 단위로 통합하면서 관리 복잡성이 증가했습니다. - **구 Yahoo Japan** - Hadoop 0.2.x 시절부터 제한된 목적의 대규모 분석 플랫폼을 운영했습니다. - 접근 인터페이스를 최소화하고 사용 방식에 일정한 제약을 둬 안정적인 운영과 사용자 지원을 우선했습니다. - 단일 Namespace가 커지면서 NameNode 확장에 한계가 생기자 RBF(Router-Based Federation)를 도입했습니다. - 권한 관리는 여전히 HDFS Permission(POSIX 유사 모델)을 사용해 현대적인 세밀한 권한 관리에는 제약이 있습니다. - 같은 HDFS라도 데이터 위치, 사용자 접근 경로, 권한 변경의 영향 범위, 운영팀의 개입 방식이 크게 달랐습니다. ## Namespace 구성과 접근 방식의 차이 - 두 플랫폼 모두 NameNode 병목을 피하기 위해 여러 Namespace로 HDFS를 분할했습니다. - 각 Namespace는 2~4대의 NameNode로 이중화했지만, Namespace와 DataNode를 묶는 방식은 달랐습니다. ### 구 LINE: ViewFS와 DataNode 공유 - ViewFS를 사용해 클라이언트의 마운트 테이블에서 실제 Namespace와 NameNode를 결정했습니다. - 유연하고 단순하지만 모든 사용자와 서비스에 올바른 마운트 설정을 배포·유지해야 합니다. - 여러 Namespace가 DataNode를 공유해 자원 효율은 높지만 클러스터 구성과 운영이 복잡해졌습니다. - 통합 과정에서 NameNode와 DataNode 버전이 혼재한 점도 운영 부담을 키웠습니다. ### 구 Yahoo Japan: RBF 기반 서버 측 라우팅 - 사용자는 Router에 접속하고, Router가 적절한 Namespace와 NameNode로 요청을 분배합니다. - 클라이언트 설정을 단순화하고 여러 HDFS를 투명하게 연결하기 쉽습니다. - 대신 Router 계층의 가용성, 확장성, 네트워크 도달성, 진입점 제어가 중요합니다. - Observer NameNode를 활용해 읽기 부하도 분산했습니다. - 이 차이는 플랫폼 간 데이터 복사에서도 중요합니다. - ViewFS 환경은 클라이언트 마운트 테이블과 설정 배포가 핵심입니다. - RBF 환경은 Router를 통한 접근 경로와 Router 계층의 안정성이 핵심입니다. ## 구 LINE에서 발생한 용량과 네트워크 문제 - 전사적 활용이 확대되면서 예상보다 빠르게 HDFS 용량이 부족해졌습니다. - 신규 서버 납품 전까지 기존의 오래된 서버를 임시 재사용하고, 이후 서버를 교체하는 작업이 반복됐습니다. - DataNode를 대규모로 추가하거나 제거하면 HDFS Balancer와 블록 재배치가 대량의 네트워크 트래픽을 발생시켰습니다. - 따라서 서버 변경 작업은 HDFS뿐 아니라 네트워크 구성과 혼잡 가능성까지 고려해 네트워크팀과 협력해야 했습니다. ## 블록 증가와 NameNode 부하 - NameNode는 파일·디렉터리·블록 메타데이터를 메모리에 보관하므로 파일과 블록 수가 증가할수록 힙 사용량과 처리 부하가 커집니다. - 힙이 지나치게 커지면 GC 시간이 길어지고 NameNode 응답 지연과 불안정성이 발생합니다. - 특히 소규모 파일이 많은 Hive 테이블이 주요 원인이었습니다. - 해결을 위해: - FSImage를 정기적으로 덤프해 Hive 테이블로 저장했습니다. - 사용자별 경로, 파일 수, 블록 수, 데이터량을 분석했습니다. - 삭제나 스키마 변경이 필요 없는 테이블을 우선 선정했습니다. - 파일 병합으로 파일 수와 블록 수를 줄였습니다. - 파일 병합은 메타데이터 규모뿐 아니라 HDFS 요청 횟수도 줄여 잡 실행 속도와 NameNode 응답성을 개선했습니다. ## Namespace별 부하 특성과 Balancer 조정 - 부하는 Namespace마다 다르게 나타났습니다. - 임시 파일이 많은 Namespace에서는 평상시 부하는 낮지만 DataNode 추가 시 Balancer가 급격한 부하를 유발했습니다. - Apache Spark의 스테이징 파일은 짧은 시간에 생성·삭제되며 NameNode의 write lock을 빈번하게 발생시켰습니다. - Balancer의 블록 이동은 블록 정보 조회를 늘리고 read lock을 오래 유지해 파일 생성·삭제를 지연시킬 수 있었습니다. - 초기에는 Balancer 병렬도를 높였지만, DataNode 디스크 여유와 서비스 영향을 고려해 병렬도를 낮추고 처리 시간과 안정성 사이의 균형을 맞췄습니다. ## 조직 통합과 플랫폼 연계 - 조직 통합 후에는 서로 다른 설계 철학의 데이터 플랫폼을 연결해야 했습니다. - 주요 설계 과제는 다음과 같습니다. - 어느 플랫폼과 Namespace를 연결할 것인가 - 권한 관리 단위를 어떻게 맞출 것인가 - 어떤 접속 경로와 진입점을 사용할 것인가 - DistCP 등으로 데이터를 어떤 경로로 전송할 것인가 - 네트워크 도달성과 운영 책임을 어떻게 나눌 것인가 - 글의 후반부에서는 플랫폼 간 권한 모델 통합과 DistCP 기반 데이터 연계 방식을 다룰 예정이지만, 제공된 본문은 해당 설명이 시작되기 전에 끝나 있습니다. 대규모 HDFS를 운영할 때는 용량 증설만으로 문제를 해결하기 어렵습니다. 파일·블록 수를 지속적으로 관찰하고 소규모 파일을 줄이며, DataNode 변경과 Balancer의 네트워크 영향을 사전에 통제해야 합니다. 또한 플랫폼 통합 시에는 ViewFS와 RBF의 접근 모델 차이, 권한 체계, Router 및 클라이언트 설정까지 포함한 운영 경계를 함께 설계하는 것이 권장됩니다.

원문 읽기(새 탭에서 열림)
apache-sparkdata-platformhdfsapache-hadoop+3
toss3분 읽기큐레이션 요약

5. Technical Writer, 사라질 결심

AI 시대에 문서는 조직의 맥락을 AI에 전달하는 핵심 수단이므로, AI가 문서를 잘 만들고 관리하도록 문서화 원칙과 사례를 학습시켜야 한다. 토스는 소수의 Technical Writer(TW)만으로 수천 명의 문서를 관리할 수 없다는 문제를 해결하기 위해, TW의 역할을 AI Skill로 자동화하려 했다. 하지만 Skill을 만들어 공개하는 것만으로는 사용률이 높아지지 않았고, 사용자가 직접 설치·호출하고 자료를 준비해야 하는 불편함이 주요 장애물로 드러났다. ## AI에게 TW의 암묵지 전달하기 - 기존 TW의 리뷰 코멘트를 분석해 문서를 바라보는 관점과 테크니컬 라이팅 원칙을 추출했다. - 기존 가이드를 AI가 기계적으로 적용하지 않도록 각 원칙에 다음을 함께 제공했다. - 잘못된 예시 - 올바른 예시 - 왜 그렇게 작성해야 하는지에 대한 설명 - 자주 작성하는 문서 유형별 템플릿을 만들었다. - ADR 템플릿에는 다음과 같은 필수 섹션을 명시했다. - 개요 - 맥락 - 고려한 선택지와 장단점 - 최종 결정 - 결정 근거 - 반드시 들어가야 하는 섹션에는 `(required)`를 붙여 AI가 핵심 정보를 누락하지 않게 했다. - 문서 유형과 템플릿을 함께 제공해 AI가 구조와 작성 목적을 이해하도록 했다. ## 문서 작성 Skill 구축 TW가 문서 작성을 지원하는 과정을 네 단계로 분해해 AI Skill에 반영했다. - **목적과 배경 확인** - 서비스·프로젝트명 - 문서 목적 - 대상 독자 - 필요한 상세 수준 - 참고 자료 - 예상 문서 구조를 질문한다. - **문서 구조 결정** - 템플릿이 없으면 개요, 핵심 내용, 부가 정보 순서로 기본 구조를 만든다. - 적합한 템플릿이 있으면 온보딩 가이드, 회의록, PRD 등 문서 유형별 템플릿을 참고한다. - **본문 작성** - 테크니컬 라이팅 원칙과 MDX 규칙에 따라 내용을 채운다. - 템플릿은 문서의 목적과 유형에 맞을 때 보조적으로 사용한다. - **점검** - 어색한 표현이나 누락된 정보를 확인한다. - 필수 정보가 부족하면 추측하지 않고 질문이나 주석으로 남긴다. - 선택 항목은 근거 자료가 없을 경우 빈 섹션으로 만들지 않는다. 사용자는 AI가 묻는 질문에 답하기만 하면 되므로, TW와 대화하듯 문서 초안을 완성할 수 있도록 설계했다. ## 문서 리뷰 Skill의 시행착오 처음에는 기존 리뷰 코멘트를 체크리스트로 바꿔 AI가 모든 항목을 점검하게 했다. 그러나 AI가 중요한 문제는 놓치고, 실제로 필요하지 않은 코멘트를 억지로 생성하는 문제가 발생했다. - 잘 작성된 문서의 기준은 어느 정도 정형화할 수 있다. - 반면 잘못된 문서의 문제는 문서마다 다르게 나타난다. - 목적은 명확하지만 논리 흐름이 어색한 경우 - 논리는 자연스럽지만 독자에게 전달할 가치가 빠진 경우 - 따라서 고정된 체크리스트만으로는 다양한 문서 문제를 효과적으로 찾기 어려웠다. 이를 해결하기 위해 AI가 원칙을 참고해 자율적으로 판단하는 리뷰 워크플로를 만들었다. - 테크니컬 라이팅 원칙 파일을 먼저 읽는다. - 문서를 원칙에 비추어 스스로 검토한다. - 문제라고 판단한 이유와 수정 초안을 코멘트로 작성한다. - 마지막에 체크리스트로 누락을 한 번 더 확인한다. 기존 리뷰 코멘트는 단순 점검 목록이 아니라, 원칙이 실제 문서에 어떻게 적용되는지 보여주는 예시로 활용했다. 예를 들어 `date: string`처럼 이름과 타입만 적는 대신, 의미·허용 형식·사용 예시까지 함께 작성하도록 가르쳤다. ## Skill만 공개해서는 충분하지 않았다 두 가지 Skill을 만들어 사내에 공개했지만, 기대만큼 사용되지 않았다. - 사용자가 직접 Skill을 다운로드하고 설치해야 했다. - 비개발자에게 CLI 기반 설치 과정이 낯설고 어려웠다. - Skill을 설치한 뒤에도 문서를 작성할 때마다 사용자가 AI Skill을 떠올리고 직접 호출해야 했다. - 문서 작성에 필요한 코드, 기획서, 기존 문서, Slack 링크 등의 자료도 사용자가 직접 찾아 AI에게 전달해야 했다. - 결국 자동화된 기능이 있어도 실제 업무 흐름과 분리되어 있으면 사용자가 추가로 수행해야 하는 일이 많았다. 따라서 문서 자동화의 핵심은 좋은 프롬프트나 Skill을 만드는 데서 끝나지 않는다. 사용자가 별도로 설치하거나 기억하거나 자료를 수집하지 않아도, 실제 업무 과정에서 자연스럽게 AI가 문서 작성과 리뷰를 지원하도록 연결해야 한다.

원문 읽기(새 탭에서 열림)
AI프롬프트 엔지니어링technical-writingcli+3
toss4분 읽기큐레이션 요약

6. 도구를 넘어, 기준과 책임으로

커머스 조직의 지식 관리는 문서를 많이 쓰거나 자동화 도구를 도입하는 것만으로 완성되지 않는다. 무엇을 지식으로 남길지, 누가 책임질지, 어떤 문서를 신뢰할지에 대한 기준과 거버넌스가 함께 있어야 한다. 궁극적으로는 개인의 기억과 흩어진 기록을 조직의 업무 흐름 속에서 생성·검증·갱신되는 시스템으로 바꿔야 한다. ## 혼자 문서를 작성하는 방식의 한계 - 커머스 위키에 용어사전, 온보딩 문서, 정책 문서를 정리하자 팀마다 다르게 쓰던 용어를 통일하고 다른 팀의 기능을 이해하는 출발점을 만들 수 있었다. - 하지만 제품과 정책의 변화 속도가 문서 작성 속도보다 빨랐다. - 담당자가 바뀐 정책, 일시적인 실험, 메신저에서 논의된 결정까지 한 사람이 모두 추적하기는 불가능했다. - 지식이 현장에서 먼저 생기고 TW가 뒤늦게 정리하는 구조로는 최신성을 유지하기 어려웠다. ## 참여를 유도하는 문화만으로 부족했던 이유 - 주간 뉴스레터, 정책 질문봇, 문서화 워크숍, 길드 등을 통해 구성원의 참여를 높였다. - 문서 요청과 위키 인용은 늘었지만, 첫 기여가 지속적인 기여로 이어지지는 않았다. - 문서 작성은 업무 우선순위에서 밀렸고, 작성된 문서도 시간이 지나며 갱신되지 않았다. - 문서의 적절한 깊이와 대상 독자가 정해져 있지 않아 작성자가 매번 혼자 판단해야 했다. - 실무자는 상세한 구현 정보가 필요하지만, 다른 팀에는 불필요한 노이즈가 될 수 있다. - 개발자에게 유용한 변수명과 기술 세부사항은 비개발자의 이해를 방해할 수 있다. - 문제는 구성원이 문서화에 무관심해서가 아니라, 무엇을 어디에 어느 수준으로 남기고 누가 검토할지 정해져 있지 않았다는 데 있었다. - 문서화가 업무 흐름에 포함되고 팀의 책임으로 인정되어야 지속될 수 있다. ## AI 자동화가 보여준 구조적 문제 - 매일 밤 AI가 두 가지 신호를 바탕으로 문서 초안을 작성한다. - 배포·정책 변경 공지에서 문서 갱신이 필요한 내용을 추출한다. - 정책 질문봇이 답하지 못한 질문을 찾아 관련 자료를 바탕으로 새 문서 초안을 만든다. - 사람은 빈 화면에서 처음부터 작성하는 대신, AI 초안의 근거를 확인하고 승인하는 역할을 맡는다. - 자동화로 작성 부담은 줄었지만 새로운 문제가 드러났다. - 비슷한 문서가 중복 생성됐다. - 최신 문서가 무엇인지 판단하기 어려웠다. - 종료된 실험이나 오래된 정책을 AI가 현행 정책처럼 답하는 경우가 생겼다. - 자동화는 지식 수집과 초안 작성은 돕지만, 문서의 신뢰성·최신성·책임자를 결정하지는 못한다. ## 지식 거버넌스와 책임의 필요성 - 질문의 초점이 “문서를 어떻게 만들까?”에서 “어떻게 믿을 수 있는 지식을 만들까?”로 바뀌었다. - 정책 담당자 변경, 오래된 결정의 폐기, 중복 문서 간 우선순위 같은 문제는 도구가 아니라 운영 기준이 해결해야 한다. - 토스는 문서와 지식을 누가, 언제, 어떤 기준으로 만들고 관리하고 폐기할지 이해관계자가 함께 정하는 ‘커머스 문서·지식 거버넌스’를 제안했다. - 거버넌스는 한 번 정하고 끝나는 규칙이 아니라, 실제 적용 결과를 확인하고 지속적으로 보완하는 체계다. ## 토스 팀의 지식 관리 기준 - **아는 것은 조직에 남긴다** - 반복해서 묻는 질문 - 중요한 의사결정 - 새로 온 구성원이 알아야 하는 내용 - **남긴 지식은 찾을 수 있게 정리한다** - 사람이 검색하거나 AI가 참조할 수 있도록 분류·구조화한다. - 조직 특성에 따라 다음 기준을 선택할 수 있다. - 기술 레이어: 데이터나 시스템의 처리 단계 - 서비스 도메인: 담당 서비스 영역 - 기능 단위: 시스템 또는 기능별 구분 - **필요한 순간에 사용할 수 있게 연결한다** - 위키에 저장하는 데 그치지 않고 질문봇, GitHub 등 실제 업무 도구와 연결한다. - **정확한 정보를 최신 상태로 유지한다** - 문서 책임자와 검토 주기를 정한다. - 실험 정책과 확정 정책을 구분하고, 종료된 정책은 폐기하거나 기록용으로 분류한다. - 조직의 지식은 단순히 글로 남은 모든 정보가 아니라, 구성원이 상황을 이해하고 더 나은 결정을 내리는 데 도움이 되며 검증된 정보다. ## Knowledge Committee의 역할 - Knowledge Committee는 전사 문서 운영 기준을 정의하고 유지하며, 조직 간 기준 충돌을 조정하는 협의체다. - 자발적 모임인 길드와 달리 공식적인 의사결정 권한과 실행력을 가진다. - 운영은 두 층으로 나뉜다. - **TW 챕터**: 문서의 정의, 상태, 출처, 책임자 등 전사 공통 기준을 관리한다. - **각 도메인·챕터**: 현장 특성에 맞춰 문서의 책임자, 갱신·폐기 시점, 운영 방식을 정한다. - 중앙에서 모든 것을 통제하면 현장 변화에 느리고, 전사 기준이 없으면 조직마다 지식 관리 방식이 달라진다. - 예를 들어 커머스 조직에서 실험 배포와 확정 배포를 구분하지 않으면 종료된 실험 정책이 현행 정책처럼 남을 수 있다. - 이런 예외와 시행착오를 커미티가 기준에 반영하고 전사에 공유하면, 개별 조직의 경험이 전체 조직의 운영 노하우가 된다. ## 개인의 기억을 조직의 자산으로 전환하기 - 목표는 지식이 특정 개인이나 메신저 기록에 머무르지 않고 조직 안에서 계속 축적되고 재사용되는 구조를 만드는 것이다. - 지식을 남기고 검증하고 다시 사용하는 과정이 업무의 기본 흐름에 포함되어야 한다. - TW의 역할도 문서 작성에 머무르지 않고 지식 시스템, 제품, 거버넌스를 설계하는 방향으로 확장된다. - 궁극적으로는 문서화가 별도의 숙제가 아니라 자연스러운 업무 방식이 되어, TW의 개입 없이도 조직 지식이 순환하는 상태를 지향한다. 실무적으로는 도구를 도입하기 전에 먼저 “무엇을 남길 것인가”, “누가 검토하고 책임질 것인가”, “언제 최신성을 확인하고 폐기할 것인가”를 정하는 것이 우선이다. 이후 자동화와 AI를 초안 작성·검색·질의응답에 연결해야 지식 관리 시스템이 지속적으로 작동할 수 있다.

원문 읽기(새 탭에서 열림)
AI자동화knowledge-managementtechnical-writing+3
datadog4분 읽기큐레이션 요약

AI 지원 리팩토링을 활용해 실시간 라우팅 시스템을 마이그레이션한 방법

Datadog은 Stream Router의 기존 FoundationDB 기반 KV 모델이 트랜잭션 크기와 데이터 증가에 따른 한계에 도달하자, 운영 중단 없이 PostgreSQL·DuckDB 기반의 관계형 구조로 전환했습니다. 이 과정에서 Claude와 Cursor를 활용했지만, AI가 자율적으로 코드를 작성한 것이 아니라 사람이 새 스키마와 기존 구현, 실패 테스트를 제공하고 테스트 결과로 검증하는 방식으로 사용했습니다. 핵심 결론은 AI가 대규모 마이그레이션을 크게 가속할 수 있지만, 데이터 모델 설계와 안전성 판단은 여전히 사람의 전문성이 필요하다는 것입니다. ## Stream Router의 역할과 기존 아키텍처 - Datadog은 하루 100조 개가 넘는 이벤트를 처리하며, 각 메트릭 데이터를 올바른 Kafka 클러스터·토픽·파티션으로 라우팅해야 합니다. - Stream Router는 Kafka 메시지를 직접 생산하거나 소비하지 않고, 다른 서비스가 사용할 라우팅 결정을 관리하는 제어 평면 서비스입니다. - 라우팅 정보는 다음과 같은 용도로 사용됩니다. - Producer가 데이터를 기록할 위치 결정 - Querier가 데이터를 읽을 위치 결정 - 시간에 따른 데이터 위치 이력 관리 - 기존 구조는 쓰기와 읽기를 분리한 Eventually Consistent 아키텍처였습니다. - 쓰기 경로: FoundationDB의 키-값 모델 사용 - 읽기 경로: 주기적으로 생성된 스냅샷을 RocksDB와 메모리 데이터베이스에 적재 - Producer와 Querier는 쓰기 경로에 직접 접근하지 않음 ## 설정 파일에서 중앙 제어 평면으로의 발전 - 2016년에는 몇 줄짜리 설정 파일을 모든 서비스에 배포해 라우팅을 관리했습니다. - 인프라와 고객 규모가 커지면서 설정 파일이 수천 줄로 증가했고, 수동 편집과 배포가 운영 부담이 되었습니다. - Stream Router 도입 후에는 다음과 같이 개선되었습니다. - 설정 파일 대신 gRPC API로 라우팅 변경 - 자동화된 오케스트레이션 - 점진적이고 자동화된 롤아웃 - 고가용성과 장애 내성을 고려한 읽기·쓰기 분리 ## KV 모델의 확장 한계 - 라우팅 데이터는 단순한 키-값 목록이 아니라 서로 연결된 관계형 데이터였습니다. - Route는 특정 Kafka Stream을 참조 - Route는 Sharding Strategy를 참조 - Rule은 Route를 참조하고 활성화 시점과 적용 방식을 결정 - 기존 KV 구조에서는 데이터베이스가 제공해야 할 관계 검증을 애플리케이션이 직접 수행해야 했습니다. - 수만 개의 레코드를 Pod 프로세스로 가져옴 - 애플리케이션 내부에서 관계형 데이터베이스처럼 조인과 일관성 검사를 수행 - 데이터와 변경 규모가 커지면서 FoundationDB 트랜잭션 크기 제한에 걸리는 작업이 발생했습니다. - FoundationDB를 PostgreSQL로 단순 교체하는 방안도 해결책이 되지 못했습니다. - 기존 KV 접근 패턴을 그대로 유지하면 수천 번의 순차적인 데이터베이스 왕복이 필요 - 일부 작업은 약 45분이 걸릴 것으로 예상 - 따라서 병목의 원인은 특정 데이터베이스가 아니라, KV에 맞춰진 데이터 모델과 애플리케이션 로직 자체였습니다. ## 관계형 스키마로 재설계 - 팀은 AI를 사용하기 전에 도메인 관계를 직접 분석하고 새 스키마를 설계했습니다. - 관계형 구조에서는 다음 관계를 외래 키로 명시합니다. - Streams와 Sharding Strategies → Routes - Routes → Rules - 기존 애플리케이션 코드가 수동으로 복원하던 관계를 데이터베이스가 직접 표현하고 검증할 수 있게 되었습니다. - 쓰기 경로에는 PostgreSQL을 선택했습니다. - 관계형 의미론 지원 - 트랜잭션 처리 - Datadog의 자체 관리형 PostgreSQL 플랫폼 활용 가능 - 읽기 경로에는 DuckDB를 선택했습니다. - 스냅샷 기반 읽기 계층에 적합한 임베디드 데이터베이스 - 배열 컬럼을 기본 지원 - PostgreSQL과 유사한 SQL 문법 - PostgreSQL과 DuckDB 사이에서 쿼리 로직을 공유할 수 있음 - SQLite도 검토했지만 배열 컬럼을 기본 지원하지 않아 적합하지 않았습니다. ## AI를 활용한 테스트 중심 리팩터링 - Claude와 Cursor는 코드를 독립적으로 생성하도록 맡기지 않았습니다. - 각 메서드마다 사람이 다음 정보를 제공했습니다. - 기존 구현 - 새 데이터베이스 스키마 - 현재 실패하는 테스트 - AI는 이를 바탕으로 첫 번째 구현을 만들었고, 테스트가 코드의 정확성을 검증했습니다. - 이 방식의 장점은 다음과 같습니다. - 전체 마이그레이션을 한 번에 생성하지 않고 메서드 단위로 분할 - 실패 테스트가 요구사항과 오류를 구체적으로 제시 - 생성 코드가 실제 동작과 데이터 관계를 만족하는지 즉시 확인 - 사람이 설계와 판단을 담당하고 AI는 반복적인 변환 작업을 가속 ## 안전한 마이그레이션을 가능하게 한 조건 - 마이그레이션이 성공할 수 있었던 기반은 AI보다 기존 시스템의 구조와 개발 프로세스였습니다. - 특히 저장소 계층이 `Controller`라는 내부 인터페이스 뒤에 모듈화되어 있었습니다. - 이러한 추상화 덕분에 저장 엔진과 구현을 교체하더라도 상위 계층의 변경 범위를 줄일 수 있었습니다. - 글의 제공된 부분은 안전성을 뒷받침한 요소를 설명하는 도중 끝나므로, 이후 테스트 전략이나 실제 전환 절차의 상세 내용은 포함되어 있지 않습니다. 결국 AI는 관계형 스키마를 설계하거나 운영 위험을 판단하는 도구라기보다, 명확한 설계와 테스트가 준비된 상태에서 반복적인 코드 변환을 빠르게 수행하는 도구로 활용하는 것이 적절합니다. 대규모 운영 시스템에서는 먼저 데이터 모델과 인터페이스를 사람이 설계하고, 작은 단위의 실패 테스트를 기준으로 AI 생성 코드를 검증하는 방식을 추천할 수 있습니다.

원문 읽기(새 탭에서 열림)
데이터베이스 설계PostgreSQLApache Kafkagrpc+4
aws4분 읽기큐레이션 요약

전체 수명 주기 제어로 격리된 샌드박스 실행하기: AWS Lambda, MicroVM 도입 | Amazon Web Services

AWS Lambda MicroVMs는 사용자나 AI가 생성한 신뢰할 수 없는 코드를 사용자별로 격리된 실행 환경에서 실행하도록 설계된 서버리스 컴퓨팅 기능이다. Firecracker 기반의 VM 수준 격리, 스냅샷을 활용한 빠른 시작·재개, 메모리와 디스크 상태를 유지하는 실행 세션을 제공하면서도 인프라를 직접 운영할 필요가 없다. 특히 AI 코딩 도구, 온라인 개발 환경, 데이터 분석, 취약점 스캐너처럼 사용자별 장기 실행 환경이 필요한 서비스의 기존 격리·성능 trade-off를 줄이는 것이 핵심이다. ## 사용자별 격리 실행 환경이 필요한 이유 - AI 코딩 어시스턴트, 대화형 코드 실행 환경, 데이터 분석 플랫폼, 취약점 스캐너, 사용자 스크립트를 실행하는 게임 서버 등이 주요 대상이다. - 기존 방식에는 각각 한계가 있다. - **가상 머신**: 강력한 격리를 제공하지만 시작에 수분이 걸릴 수 있다. - **컨테이너**: 빠르게 시작되지만 공유 커널 때문에 신뢰할 수 없는 코드를 안전하게 격리하려면 추가적인 보안 강화가 필요하다. - **서버리스 함수**: 이벤트 기반 요청-응답 처리에 적합하지만, 사용자 상호작용 사이에 상태를 유지하는 장기 세션에는 적합하지 않다. - 직접 가상화 인프라를 구축하면 낮은 지연 시간과 강한 격리를 모두 확보할 수 있지만, 상당한 운영·보안 전문성이 필요하다. ## Firecracker 기반 VM 수준 격리 - 각 사용자 또는 세션은 독립된 MicroVM을 할당받는다. - MicroVM 간 커널과 리소스를 공유하지 않으므로 한 사용자가 실행한 신뢰할 수 없는 코드가 다른 사용자 환경이나 호스트 시스템에 접근하는 것을 막는다. - AWS Lambda에서 대규모로 사용되어 온 Firecracker 기술을 기반으로 하므로, 자체 가상화 시스템을 구축하는 대신 AWS의 운영 성숙도를 활용할 수 있다. ## MicroVM Image 생성 과정 - 애플리케이션 코드와 Dockerfile을 ZIP 파일로 패키징해 Amazon S3에 업로드한다. - `public.ecr.aws/lambda/microvms:al2023-minimal` 기반 이미지에서 Python, pip 등을 설치하고 애플리케이션을 구성할 수 있다. - 예시 애플리케이션은 Gunicorn으로 실행되는 Flask API이며, `0.0.0.0:5000` 포트에서 요청을 처리한다. - 다음과 같은 CLI 명령으로 이미지를 생성한다. ```bash aws lambda-microvms create-microvm-image \ --code-artifact uri=<path/to/s3/artifact.zip> \ --name <VM_image_name> \ --base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \ --build-role-arn <IAM role ARN> ``` - Lambda는 ZIP 파일을 가져와 Dockerfile을 빌드하고 애플리케이션을 초기화한다. - 초기화가 끝난 실행 중인 디스크와 메모리 상태를 Firecracker 스냅샷으로 저장한다. - 빌드 로그는 다음 CloudWatch Logs 경로에서 확인할 수 있다. ```text /aws/lambda/microvms/<image-name> ``` ## 스냅샷 기반 빠른 시작과 재개 - MicroVM은 일반적인 콜드 부팅 대신 사전에 초기화된 스냅샷에서 시작한다. - 애플리케이션 프로세스, 설치된 패키지, 메모리 상태 등이 준비된 상태이므로 실행 직후부터 요청을 처리할 수 있다. - 이후 생성되는 MicroVM도 동일한 이미지 스냅샷에서 복원되므로 초기화 시간을 줄일 수 있다. - 대규모 대화형 세션도 사용자 입장에서 즉시 반응하는 수준의 시작·재개 성능을 목표로 한다. ## 상태를 유지하는 세션과 유휴 정책 - 실행 중인 MicroVM은 다음 상태를 세션 동안 유지한다. - 메모리 상태 - 디스크 상태 - 실행 중인 프로세스 - 일정 시간 요청이 없으면 MicroVM을 일시 중지할 수 있다. - 중지 시 메모리와 디스크 상태를 보존하고, 요청이 다시 들어오면 해당 상태에서 자동으로 재개한다. - 예시 설정은 15분 유휴 후 중지하고, 5분 동안 중지 상태를 유지한 뒤 요청이 오면 자동 재개하도록 구성한다. ```bash aws lambda-microvms run-microvm \ --image-identifier arn:aws:lambda:<region>:<acct>:microvm-image:my-image \ --execution-role-arn arn:aws:iam::<acct>:role/MicroVMExecutionRole \ --idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":300,"autoResumeEnabled":true}' ``` ## 엔드포인트와 요청 인증 - MicroVM을 실행하면 Lambda가 고유 ID와 전용 엔드포인트 URL을 제공한다. - 별도의 네트워킹 구성을 하지 않아도 애플리케이션에 접근할 수 있다. - CLI로 단기 인증 토큰을 생성한 뒤 HTTPS 요청의 `X-aws-proxy-auth` 헤더에 포함해 요청을 보낸다. - MicroVM이 중지된 뒤 다시 요청해도 애플리케이션 상태가 유지된 채 복원되므로 클라이언트는 중지·재개 과정을 직접 처리할 필요가 없다. ## 실용적인 활용과 추천 Lambda MicroVMs는 단순한 단발성 함수보다 사용자별로 지속되는 안전한 실행 환경이 필요한 서비스에 적합하다. 사용자 코드 실행, AI 에이전트의 도구 호출, 온라인 IDE, 샌드박스형 분석 환경을 구축한다면 컨테이너 직접 격리나 VM 운영을 대체할 수 있는 후보로 검토할 만하다. 다만 실제 도입 전에는 IAM 실행 역할, 인증 토큰 관리, 유휴·재개 정책, 상태 보존 범위와 비용을 서비스의 세션 패턴에 맞게 검증하는 것이 좋다.

원문 읽기(새 탭에서 열림)
PythonDocker & 컨테이너amazon-s3flask+3
netflix4분 읽기큐레이션 요약

넷플릭스는 Kueue로 배치 컴퓨팅을 어떻게 간소화했는가

Netflix는 기존 자체 배치 시스템인 CMB의 큐잉·스케줄링 기능을 Kubernetes 기반 오픈소스인 Kueue로 대체해 배치 컴퓨팅을 단순화했다. Kueue는 Titus의 기존 스케줄러를 유지하면서 멀티테넌트 용량 관리, 우선순위 큐, 선점, 공정 공유 등을 제공해 기능 확장과 Kubernetes 네이티브 전환을 지원했다. Netflix는 사용자 API와 경험을 그대로 유지한 채 수백만 개의 배치 작업을 이전했으며, 현재 Kueue를 프로덕션에서 완전히 운영하고 있다. ## CMB와 Titus의 기존 구조 - CMB(Compute Managed Batch)는 완료까지 실행되는 배치 작업을 제출·관리하는 Netflix의 관리형 서비스였다. - 작업은 테넌트 계층 구조에 따라 관리되며, 우선순위와 큐 순서에 따라 실행됐다. - Titus는 실제 작업 실행 플랫폼으로, 여러 Kubernetes 클러스터 또는 셀에 걸친 작업 배치와 용량 예약을 담당했다. - CMB는 단일 Titus 엔드포인트를 통해 클러스터 토폴로지를 직접 알지 않고도 작업과 용량 예약을 관리할 수 있었다. ## 테넌트 계층과 용량 관리 - **Internal Tenant** - 조직이나 애플리케이션 구조를 표현하기 위한 중간 노드다. - 직접 작업을 수용하지 않으며, 하위에 internal tenant나 leaf tenant를 둘 수 있다. - **Leaf Tenant** - 실제 작업을 제출할 수 있는 최종 테넌트다. - 큐를 가지며 하위 테넌트를 둘 수 없다. - **Reserved Capacity** - 내부 테넌트에서는 하위 트리 전체가 용량을 공정하게 공유한다. - 리프 테넌트에서는 특정 용량을 독점적으로 예약해 다른 테넌트가 해당 자원을 예약하지 못하도록 한다. - **Shared Capacity** - 모든 테넌트가 사용할 수 있는 전역 버스트 용량이다. - 기존 CMB에서는 작업이 승인된 뒤에는 선점되지 않았으므로, 이후 수요가 바뀌어도 작업이 끝까지 실행됐다. ## Kueue를 선택한 이유 - Kueue는 kube-scheduler를 대체하지 않으므로 Titus의 기존 스케줄링 프로파일과 통합할 수 있다. - YuniKorn이나 Volcano처럼 스케줄러 자체를 교체하면 작업 배치가 분산되어 효율이 저하될 수 있었다. - Kubernetes 생태계에서 빠르게 발전하고 있으며 채택 흐름도 강했다. - 서로 다른 하드웨어를 사용하는 환경에서 멀티테넌트 쿼터를 관리할 수 있다. - `v1.Pod`, `batch/v1.Job`뿐 아니라 RayJob, RayCluster 같은 고수준 리소스도 지원한다. - CMB에서 구현하기 어려웠던 기능을 기본 제공한다. - 선점(preemption) - 전체 작업 단위의 원자적 스케줄링(all-or-nothing scheduling) - 토폴로지 인지 스케줄링(topology-aware scheduling) ## Netflix Batch로의 마이그레이션 - 마이그레이션 프로젝트의 목표는 다음과 같았다. - CMB 사용자가 별도 작업을 하지 않아도 되는 투명한 이전 - 컨테이너 실행률과 전체 최대 처리량 유지 - CMB의 큐잉·스케줄링 로직을 Kueue로 대체 - 새로운 구조에서는 Kueue가 활성화된 Titus 셀에서 Kueue가 큐잉과 스케줄링을 담당한다. - Titus federation은 Netflix가 만든 Kueue router를 통해 작업을 적절한 Kueue 셀로 전달한다. - 운영자는 UI에서 테넌트의 마이그레이션 버튼을 누르는 것만으로 전환할 수 있으며, 문제가 발생하면 쉽게 롤백할 수 있었다. ## CMB 개념을 Kueue 리소스로 변환 - 기존 internal tenant는 Kueue의 **Cohort**로 변환됐다. - 기존 leaf tenant는 **ClusterQueue와 LocalQueue** 조합으로 변환됐다. - 테넌트의 용량 설정은 Kueue의 다음 개념으로 매핑됐다. - Resource Flavor - Nominal Quota - 이 구조를 통해 기존의 테넌트 계층과 용량 정책을 유지하면서 실제 큐 관리는 Kueue에 위임했다. ## 마이그레이션 과정에서 얻은 교훈 - 기존 API를 유지하고 내부 구현부터 교체하면 고객 경험을 바꾸지 않고 위험을 단계적으로 줄일 수 있다. - 가장 복잡한 사용 사례를 마지막으로 미루지 않는 것이 중요했다. - Netflix는 가장 크고 복잡한 고객을 초기에 이전했다. - 이를 통해 다른 고객의 이전 가능성을 검증했고, 실제 프로덕션 마이그레이션은 4주 만에 완료됐다. - 기본 설정만으로는 Netflix의 처리량을 감당할 수 없었다. - Kueue의 QPS, burst, `groupKindConcurrency` 값을 기본값보다 크게 조정해야 했다. - Titus와 유사한 개발 환경에서 부하 테스트를 일찍 수행해 성능 위험을 사전에 확인했다. ## 현재 운영 상태와 향후 방향 - Kueue는 Netflix 프로덕션에 완전히 배포되어 수백만 개의 배치 작업을 관리하고 있다. - Netflix는 더 많은 Titus 배치 작업을 Kueue 기반의 관리형 환경으로 편입할 계획이다. - 예약 용량 활용률을 높이기 위해 공정 공유와 선점 기능도 프로덕션 수준으로 확장했다. - 이러한 경험은 Kubernetes 네이티브 학습·트레이닝 인프라를 구축하는 다른 내부 팀의 작업 큐와 스케줄링 설정에도 활용되고 있다. Netflix의 사례는 기존 사용자 인터페이스와 실행 플랫폼을 유지하면서 큐잉 계층만 검증된 Kubernetes 구성 요소로 교체한 점이 핵심이다. 대규모 시스템에서는 한 번에 모든 것을 재작성하기보다 API 호환성, 단계적 전환, 조기 부하 테스트, 손쉬운 롤백을 함께 설계하는 접근이 실용적이다.

원문 읽기(새 탭에서 열림)
쿠버네티스container-orchestrationmulti-tenancykueue+4
cloudflare3분 읽기큐레이션 요약

hyper HTTP 라이브러리에서 버그를 발견한 방법

Cloudflare의 Images binding을 로컬 Unix 소켓 기반 구조로 개편한 뒤, 대용량 이미지 응답이 간헐적으로 잘리는 버그가 발생했다. 응답은 HTTP 200과 정상적인 `Content-Length`를 반환했지만 실제 본문은 수백 KB만 전달되어 이미지가 부분적으로 렌더링되거나 디코딩에 실패했다. 원인은 특정 조건에서 발생하는 hyper 라이브러리의 레이스 컨디션이었으며, 최종적으로 네 줄의 코드 수정으로 해결됐다. ### Images binding과 hyper의 데이터 흐름 - Workers는 바인딩을 통해 Images 서비스에 이미지 데이터를 직접 전달하고, 변환 결과를 스트림으로 받을 수 있다. - 이미지 변환 과정은 다음과 같이 진행된다. - Workers 런타임이 소켓을 통해 Images 서비스에 요청을 보낸다. - Images 서비스가 이미지를 합성·리사이즈·트랜스코딩한다. - 변환된 전체 이미지를 메모리 블록으로 hyper에 전달한다. - hyper가 데이터를 내부 버퍼에 저장한 뒤 소켓의 송신 버퍼로 기록한다. - 소켓의 양 끝에는 커널이 관리하는 버퍼가 있다. - 수신자가 충분히 빠르면 hyper가 한 번에 모든 데이터를 보내고 소켓을 종료할 수 있다. - 수신자가 조금이라도 느리면 송신 버퍼가 가득 차고, hyper는 공간이 생길 때까지 추가 쓰기를 기다려야 한다. ### 네트워크 중계에서 로컬 Unix 소켓으로 전환 - 초기 Images binding은 Workers 런타임과 Images 사이에서 FL이라는 내부 중계 서비스를 거쳤다. - FL은 DNS 조회와 라우팅 등 전체 네트워크 처리 파이프라인을 수행했기 때문에 오버헤드가 있었다. - 2025년 12월, Cloudflare는 FL을 같은 머신에서 실행되는 내부 Worker binding으로 교체했다. - 새 구조는 네트워크 소켓 대신 Unix 소켓으로 서비스를 직접 연결했다. - 이 변경으로 다음 효과를 기대했다. - 네트워크 스택과 FL 처리 과정 제거 - Images 요청 경로 단축 - Images 팀이 독립적으로 binding을 배포하고 변경 가능 - 그러나 출시 며칠 뒤부터 대용량 이미지 응답 실패 제보가 접수됐다. ### HTTP 200이지만 잘린 응답 - 고객 사례는 두 단계의 이미지 처리 파이프라인을 중첩한 비표준 구성이었다. - 내부 파이프라인: R2의 JPEG와 PNG를 합성해 JPEG 생성 - 외부 파이프라인: 결과 이미지를 다시 압축·변환·리사이즈 - 실제 문제는 내부 transformation binding의 반환 경로에서 발생했다. - 외부 파이프라인은 내부 응답에서 다음과 같은 모순을 받았다. - 상태 코드는 `200 OK` - `Content-Length`는 수 MB로 설정 - 실제 수신 본문은 일부 데이터에 불과함 - 한 사례에서는 예상 크기 3.3MB 중 약 200KB만 전달됐다. - 상위 계층에서는 다음 오류가 발생했지만, 실제 원인이 어느 서비스에 있는지는 즉시 알기 어려웠다. ```text error reading a body from connection: end of file before message length reached ``` - 브라우저에서는 이미지 형식에 따라 일부만 표시되거나, 하단이 회색으로 남거나, 아예 깨진 이미지로 표시됐다. ### 재현과 원인 범위 좁히기 - 개발팀은 고객의 중첩 파이프라인을 재현하는 Worker를 만들었다. - 이후 외부 파이프라인과 여러 계층을 하나씩 제거해 binding 단독으로도 문제를 재현할 수 있음을 확인했다. - 배치 요청을 보내는 간단한 스크립트로 재현을 자동화했다. - 초기 실행에서는 25건 중 19건이 실패했다. - 매번 도착한 데이터가 약 200KB였는데, 이는 운영 환경의 소켓 버퍼 크기와 매우 유사했다. - 이를 통해 문제는 고객 설정이 아니라 소켓 버퍼가 가득 찬 뒤 hyper가 응답 전송과 연결 종료를 처리하는 방식과 관련 있음을 추정할 수 있었다. - 최종 원인은 특정 타이밍에서 발생하는 hyper 내부의 레이스 컨디션으로 밝혀졌고, 수정에는 네 줄의 코드만 필요했다. ### 실용적인 결론 소켓 기반 스트리밍에서는 `200 OK`나 올바른 `Content-Length`만으로 전송 성공을 판단할 수 없다. 특히 송신 버퍼가 가득 차는 상황, 느린 수신자, 데이터 기록과 연결 종료가 동시에 일어나는 경로를 반드시 테스트해야 하며, 대용량·중첩 파이프라인을 포함한 재현 테스트가 간헐적인 네트워크 버그를 찾는 데 결정적이다.

원문 읽기(새 탭에서 열림)
Cloudflare WorkersRusthttprace-condition+2