비디오 검색을 위한 멀티모달 인텔리전스 구현 (새 탭에서 열림)

넷플릭스는 방대한 분량의 원본 영상 데이터에서 창작자가 원하는 특정 순간을 신속하게 찾아낼 수 있도록 여러 전문 AI 모델을 결합한 멀티모달(Multimodal) 검색 시스템을 구축했습니다. 이 시스템은 캐릭터, 환경, 대화 등 서로 다른 모델이 생성한 파편화된 신호들을 하나의 통합된 시간축으로 동기화하여 고차원의 문맥 이해와 실시간 검색을 동시에 실현합니다. 결과적으로 수십억 개의 데이터 포인트 속에서도 창작자의 의도에 부합하는 장면을 지연 시간 없이 정확하게 찾아내는 기술적 해결책을 제시합니다. **비디오 검색의 기술적 복잡성과 한계** * **타임라인 통합의 어려움:** 각 모델은 비디오를 서로 다른 간격으로 분석하여 텍스트 레이블이나 벡터 임베딩 등 상이한 형태의 메타데이터를 생성하므로, 이를 하나의 연대기적 지도로 정렬하는 데 막대한 계산 비용이 발생합니다. * **데이터 규모의 폭발:** 2,000시간 분량의 아카이브는 약 2억 1,600만 프레임에 달하며, 이를 여러 모델로 처리할 경우 수십억 개의 레이블과 벡터 데이터가 생성되어 전통적인 데이터베이스로는 처리가 불가능합니다. * **중복 제거와 하이브리드 스코어링:** 시각적으로 유사한 수천 개의 후보 중 최적의 클립을 제안하기 위해, 단순한 수학적 유사도를 넘어 상징적 텍스트 매칭과 의미론적 벡터 검색을 결합한 정교한 랭킹 엔진이 필요합니다. * **제로 프릭션(Zero-Friction) 검색:** 창작 흐름을 방해하지 않기 위해 수십억 개의 레코드를 탐색하면서도 초 단위 미만의 응답 속도를 유지해야 하는 물리적 제약이 존재합니다. **데이터 수집 및 융합 파이프라인 (Ingestion & Fusion)** * **트랜잭션 영속화 (Transactional Persistence):** 고가용성 파이프라인을 통해 수집된 모델의 원본 주석(Annotation)을 Apache Cassandra에 저장합니다. 이 단계에서는 데이터 무결성과 빠른 쓰기 처리량을 최우선으로 하여 모든 모델 출력을 안전하게 확보합니다. * **오프라인 데이터 융합 (Offline Data Fusion):** Apache Kafka를 통해 비동기적으로 실행되며, 파편화된 모델 데이터를 1초 단위의 '시간 버킷(Temporal Buckets)'으로 정규화합니다. 예를 들어 '조이'라는 캐릭터와 '주방'이라는 배경이 겹치는 구간을 하나의 통합 레코드로 병합하여 복합적인 쿼리가 가능하도록 만듭니다. * **실시간 검색 인덱싱:** 융합된 데이터를 Elasticsearch에 인덱싱합니다. 이때 자산 ID와 시간 버킷을 조합한 복합 키(Composite Key)를 사용하여 업서트(Upsert) 방식으로 데이터를 갱신함으로써 데이터 중복을 방지하고 단일 진실 공급원(Single Source of Truth)을 유지합니다. **효율적인 멀티모달 시스템을 위한 제언** 대규모 영상 자산을 관리하는 시스템에서는 원본 데이터를 실시간으로 검색하는 대신, 데이터를 수집-융합-인덱싱 단계로 분리(Decoupling)하여 처리하는 구조가 필수적입니다. 특히 서로 다른 AI 모델의 출력을 공통된 시간 단위(Time Bucketing)로 정규화하여 저장함으로써, 복잡한 다차원 검색 시 발생하는 계산 부하를 오프라인에서 미리 해결하고 사용자에게는 즉각적인 검색 경험을 제공할 수 있습니다.

Amazon Bedrock Guardrails supports cross-account safeguards with centralized control and management | Amazon Web Services (새 탭에서 열림)

Amazon Bedrock Guardrails에서 조직 전체의 여러 AWS 계정에 걸쳐 보안 제어 기능을 중앙 집중식으로 관리하고 강제할 수 있는 '교차 계정 보호(cross-account safeguards)' 기능이 정식 출시되었습니다. 이 기능을 통해 관리자는 단일 정책으로 모든 계정과 생성형 AI 애플리케이션에 일관된 안전 가이드라인을 적용하여 거버넌스를 강화하고 보안 팀의 운영 부담을 획기적으로 줄일 수 있습니다. 결과적으로 개별 계정의 설정을 일일이 확인하지 않고도 조직의 책임감 있는 AI(Responsible AI) 요건을 효과적으로 충족할 수 있게 되었습니다. **조직 및 계정 단위의 중앙 집중식 제어** * **조직 수준 강제:** AWS Organizations의 관리 계정에서 단일 가이드라인을 설정하여 조직 전체, 특정 조직 단위(OU), 또는 개별 계정에서 발생하는 모든 Amazon Bedrock 모델 호출에 보안 필터를 자동 적용합니다. * **계정 수준 강제:** 특정 AWS 계정 내에서 이루어지는 모든 추론 API 호출에 대해 보호 조치를 일괄 적용하도록 구성할 수 있습니다. * **유연한 계층 구조:** 조직 전체의 공통 가드레일을 적용하면서도, 필요에 따라 특정 사용 사례나 애플리케이션에 맞는 계정별 추가 제어 기능을 병행하여 운용할 수 있습니다. **정교한 가드레일 설정 및 적용 옵션** * **모델 선택적 적용:** 중앙에서 추론에 사용할 특정 모델을 포함(Include)하거나 제외(Exclude)하도록 설정하여 관리 효율성을 높였습니다. * **콘텐츠 가드링 모드(Content Guarding):** * **포괄적 모드(Comprehensive):** 호출자의 태그 지정 여부와 관계없이 모든 시스템 프롬프트와 사용자 입력에 가드레일을 강제 적용하는 안전한 기본 방식입니다. * **선택적 모드(Selective):** 호출자가 태그를 지정한 특정 부분에만 가드레일을 적용하여 불필요한 처리를 줄이고 효율성을 높이는 방식입니다. * **변경 불가성 보장:** 가드레일 설정 시 특정 버전을 지정하여 생성함으로써, 하위 멤버 계정에서 보호 조치 내용을 임의로 수정하거나 우회할 수 없도록 보장합니다. **구현 방법 및 기술적 디테일** * **통합 관리 인터페이스:** Amazon Bedrock 콘솔이나 AWS Organizations 정책 메뉴를 통해 관리할 수 있으며, 가드레일 ARN과 버전을 지정한 'Bedrock 정책'을 대상 계정에 연결하는 방식으로 작동합니다. * **지원 API:** `InvokeModel`, `InvokeModelWithResponseStream`, `Converse`, `ConverseStream` 등 Amazon Bedrock의 주요 추론 API 호출 시 가드레일이 자동으로 개입합니다. * **검증 및 모니터링:** 멤버 계정에서 현재 강제 적용 중인 조직 수준 가드레일을 직접 확인할 수 있으며, API 응답에 포함된 가드레일 평가 정보를 통해 정상 작동 여부를 테스트할 수 있습니다. **실무 적용 시 유의 사항** * **정확한 ARN 지정:** 정책 설정 시 가드레일 ARN을 잘못 입력하면 정책 위반으로 간주되어 해당 계정에서 Bedrock 모델 추론 자체가 불가능해질 수 있으므로 정확한 식별자 입력이 필수적입니다. * **기능 제한 사항:** 현재 교차 계정 보호 기능은 '자동화된 추론(Automated Reasoning)' 검사는 지원하지 않으므로 보안 설계 시 이를 고려해야 합니다. * **비용 및 지역:** 가드레일이 적용될 때마다 구성된 보호 조치에 따른 비용이 발생하며, Bedrock Guardrails가 사용 가능한 모든 AWS 리전(Commercial 및 GovCloud)에서 즉시 사용할 수 있습니다.

Diff 라인 성능 개선을 위한 험난한 여정 (새 탭에서 열림)

Senor Software Engineer

Hive에서 Iceberg로: 데이터 반영 속도 12배 향상의 비밀 (새 탭에서 열림)

LINE Plus는 수억 건에 달하는 상품 데이터를 처리하기 위해 기존에 사용하던 전체 데이터 복제(Full Dump) 방식의 ETL 구조를 탈피하고, Apache Iceberg와 Apache Flink를 결합한 증분(Incremental) 처리 구조를 도입했습니다. 이를 통해 데이터 규모가 커질수록 기하급수적으로 늘어나던 업데이트 비용과 시간을 대폭 절감하였으며, 결과적으로 데이터 반영 주기를 60분에서 5분으로 단축하여 약 12배의 성능 향상을 이루어냈습니다. 이 글은 대규모 데이터 환경에서 실시간성에 가까운 데이터 최신성을 확보하기 위한 기술적 여정과 엔진 선택의 근거를 상세히 다룹니다. **기존 전체 데이터 복제 방식의 한계** * **리소스 낭비와 지연:** 매번 수억 건의 전체 데이터를 다시 써야 하는 구조로 인해 데이터 규모가 커질수록 처리 비용이 증가하고, 사내 Hadoop 리소스 부족 시 업데이트 주기가 지연되는 문제가 발생했습니다. * **데이터 최신성 결여:** 스냅숏 기반의 추출 방식은 정합성은 보장하지만, 추출 작업에 걸리는 시간만큼 데이터가 과거 시점에 머물게 되어 라이브 서비스에서의 실시간 대응이 어려웠습니다. * **운영 DB 부하:** 대용량 데이터를 한꺼번에 추출할 때 발생하는 막대한 디스크 I/O와 Undo 세그먼트 팽창은 운영 환경의 성능 저하를 유발하는 고질적인 원인이 되었습니다. **Apache Iceberg를 통한 증분 처리 기반 마련** * **테이블 형식의 변화:** 기존 Hive의 디렉터리 기반 관리 방식에서 벗어나, 메타데이터를 이용해 스냅숏 단위로 파일을 추적하는 Iceberg 형식을 도입했습니다. * **행 단위 업데이트 지원:** 전체 데이터를 다시 쓸 필요 없이 변경된 행(row)만 선택적으로 업데이트(upsert)하거나 삭제(delete)할 수 있어, 데이터 규모와 상관없이 일정한 업데이트 비용을 유지할 수 있게 되었습니다. **Apache Flink 선택의 결정적 이유** * **스테이트풀(Stateful) 처리를 통한 최신성 보장:** Flink의 DataStream API를 활용해 `updatedate`를 상태값으로 관리함으로써, 컨슈머 랙 등으로 인해 뒤늦게 도착한 과거 데이터가 최신 데이터를 덮어쓰는 문제를 원천 차단했습니다. * **2단계 커밋(2PC) 기반의 정확히 한 번 처리:** Iceberg 테이블 쓰기와 Kafka 상태 메시지 발행을 하나의 트랜잭션으로 묶어, 데이터 누락이나 중복 없이 '전부 아니면 전무(All-or-Nothing)'의 정합성을 보장했습니다. * **강력한 장애 허용(Fault Tolerance):** 체크포인트 메커니즘을 통해 시스템 장애 발생 시에도 마지막 성공 지점부터 즉시 복구가 가능하며, 관리하던 상태값을 유실 없이 유지할 수 있습니다. **효율적인 운영을 위한 쿠버네티스 오퍼레이터 도입** * **운영 자동화:** 설정 작업을 수동으로 진행해야 하는 네이티브 쿠버네티스 방식 대신, Flink 쿠버네티스 오퍼레이터를 도입하여 라우팅, 웹 UI 구성 등 운영 요소를 커스텀 리소스로 추상화하고 관리를 자동화했습니다. * **격리 및 확장성:** 애플리케이션 모드를 통해 잡(job)별 클러스터 격리 수준을 높이고, 헬름(Helm) 차트를 이용해 손쉽게 배포 및 확장할 수 있는 환경을 구축했습니다. 대규모 데이터셋에서 실시간에 가까운 데이터 동기화와 엄격한 정합성이 모두 필요하다면, 단순한 배치 처리보다는 Flink와 Iceberg의 조합을 통한 증분 파이프라인 구축을 권장합니다. 특히 Flink의 2단계 커밋과 체크포인트 기능을 활용하면 분산 환경에서도 데이터 무결성을 보장하면서 시스템의 업데이트 주기를 획기적으로 단축할 수 있습니다.

LLM의 행동 성향 정렬 평가 (새 탭에서 열림)

구글 리서치는 대규모 언어 모델(LLM)의 행동 성향을 정밀하게 측정하기 위해 심리학적 방법론인 상황 판단 테스트(SJT)를 도입한 새로운 평가 프레임워크를 제시했습니다. 연구 결과, 최신 대형 모델들은 인간의 의견이 만장일치로 일치하는 상황에서는 높은 정렬 수준을 보였으나, 의견이 갈리는 복잡한 사회적 상황에서는 인간의 다양한 관점을 반영하지 못하고 특정 답변에 과하게 확신하는 경향을 보였습니다. 이는 LLM이 인간 사회의 미묘한 역학을 더욱 정교하게 탐색하기 위해 행동 정렬 방식의 개선이 필요함을 시사합니다. **심리학적 기반의 상황 판단 테스트(SJT) 설계** * 단순한 자기보고식 설문(예: "나는 의견을 빨리 표현한다")의 한계를 극복하기 위해, 실제 사용자-어시스턴트 상호작용 상황을 가정한 시나리오 기반의 SJT를 구축했습니다. * IRI(공감), ERQ(정서 조절) 등 검증된 심리학적 척도를 바탕으로 전문적 침착함, 갈등 해결, 일상적 의사결정 등 다양한 사회적 맥락을 반영하는 시나리오를 생성했습니다. * 모델의 자연어 응답을 'LLM-as-a-judge' 방식을 통해 두 가지 대조되는 행동 선택지 중 하나로 매핑하고, 이를 550명의 인간 주석자가 내놓은 반응 분포와 비교하여 정렬도를 측정했습니다. **모델 규모에 따른 행동 방향성 일치도** * 25개의 LLM을 분석한 결과, 25B(250억 개) 미만의 소형 모델은 인간의 다수 의견과 일치하는 선택을 하는 '방향성 일치도'가 현저히 낮았으며, 때로는 무작위 수준의 선택을 보였습니다. * 120B 이상의 대형 모델과 최신 프런티어 모델들은 인간의 합의가 만장일치(10/10)인 상황에서 거의 완벽한 일치도를 보였으나, 합의율이 80~90%로 낮아지면 모델의 성능도 80%대 초중반에서 정체되었습니다. * 구체적인 일탈 사례로, 모델은 인간이 '침착함'을 권장하는 전문적인 상황에서 '감정적 개방성'을 지나치게 독려하거나, 갈등 상황에서 자기 주장을 하기보다 과도하게 화합만을 우선시하는 경향을 보였습니다. **분포적 정렬의 한계와 과잉 확신 문제** * 인간 사회의 다양한 관점을 반영해야 한다는 '분포적 다원주의' 관점에서 볼 때, 인간의 의견이 갈리는 상황에서는 모델의 응답 확률 분포도 낮아져야(즉, 확신이 줄어들어야) 합니다. * 그러나 테스트된 25개 모델 모두 인간의 합의 수준과 상관없이 특정 선택지에 대해 체계적인 '과잉 확신(Overconfidence)'을 보이는 것으로 나타났습니다. * 인간들 사이에서 선호도가 팽팽하게 나뉘는 시나리오에서도 모델은 확률 분포를 고르게 분산시키지 못하고, 특정 행동이 정답인 것처럼 높은 확신을 가지고 응답하는 한계를 드러냈습니다. 이 연구는 LLM이 인간의 행동 양식을 단순히 흉내 내는 것을 넘어, 사회적 맥락에 따라 유연하게 대응하고 인간 의견의 다양성을 존중하도록 설계되어야 함을 강조합니다. 향후 모델 개발 시 단순한 선호도 최적화를 넘어, 인간의 미묘한 사회적 역동성과 다원적 가치를 반영할 수 있는 정렬 기술이 중요하게 작용할 것입니다.

토스가 디자인 직무를 2개로 줄인 이유 (새 탭에서 열림)

토스 디자인 챕터는 기술의 발전으로 도구 활용에 대한 장벽이 낮아짐에 따라, 기존의 세분화된 6개 직무를 'Product Designer'와 'Visual Designer' 2개로 전격 통합했습니다. 이번 개편은 "어떤 도구를 사용하는가" 혹은 "어떤 화면을 만드는가"라는 수단 중심의 경계를 허물고, "무엇이 좋은 경험인가"를 판단하는 디자이너 본연의 감각과 판단력에 집중하기 위한 결정입니다. 이를 통해 디자이너가 고민할 수 있는 영역을 넓히고, 매체나 기법에 갇히지 않는 본질적인 문제 해결을 지향합니다. **수단과 매체가 만든 직무 경계의 한계** * 기존의 직무 세분화(Platform, Interaction, Graphic, Brand 등)는 조직의 성장에 따라 전문성을 쌓는 데 기여했으나, 실무에서는 점차 경계가 모호해지는 문제가 발생했습니다. * 인터랙션 적용이나 디자인 시스템 구축 시 특정 직무의 영역인지 모호한 상황이 반복되었으며, 이는 협업의 효율을 저해하는 요소가 되었습니다. * 과거의 직무 구분은 "무엇을 판단하느냐"가 아니라 Lottie, 코드, PC/모바일 등 다루는 도구와 화면의 크기라는 '수단'에 매몰되어 있었다는 점이 한계로 지적되었습니다. **기술 발전과 하드스킬 장벽의 붕괴** * AI와 디자인 도구(Figma 등)의 비약적인 발전으로 영상 제작, 프로토타이핑, 코드 구현 등 과거 전문 영역이었던 기술적 난이도가 낮아졌습니다. * 이미 실무에서는 직무에 구애받지 않고 브랜드 디자이너가 제품을 디자인하거나, 그래픽 디자이너가 시스템을 구축하는 등 '경계를 넘는 디자이너'들이 등장하고 있었습니다. * 하드스킬 습득 시간이 단축됨에 따라 디자이너에게 가장 중요한 역량은 도구 숙련도가 아닌, 결과물의 질을 결정하는 '판단력'과 '감각'으로 이동했습니다. **통합된 두 가지 핵심 직무** * **Product Designer**: 기존의 제품 디자이너와 툴즈 제품 디자이너를 통합하여, 모바일과 PC라는 화면 구분을 없앴습니다. 사용자의 맥락과 문제를 발견하고 해결책을 설계하는 본질에 집중합니다. * **Visual Designer**: 플랫폼, 인터랙션, 그래픽, 브랜드 디자이너를 통합했습니다. 특정 매체에 국한되지 않고 "무엇이 아름답고 올바른 시각적 판단인가"를 고민하며, 필요에 따라 아이콘 제작부터 인터랙티브 웹까지 직접 수행하는 조형 전문가를 지향합니다. **산업 전반에서 나타나는 역할 수렴 현상** * 디즈니 애니메이션이 복잡한 물리적 공정을 소프트웨어로 대체하고 기획 중심의 구조로 바뀐 것처럼, 디자인 역시 도구 중심에서 판단 중심으로 진화하고 있습니다. * 음악 산업에서 DAW(디지털 오디오 워크스테이션)의 등장으로 작곡과 엔지니어링의 경계가 사라진 사례처럼, 도구가 하나로 모이면 역할도 자연스럽게 하나로 흐려집니다. * 영화와 TV 연출의 경계가 디지털 시네마 등장 이후 사라진 것과 마찬가지로, 디자인 매체의 통합은 거스를 수 없는 흐름입니다. **디자이너를 위한 실용적인 제언** 이제 디자이너는 특정 툴의 숙련도에 안주하기보다, 자신이 만드는 결과물이 사용자에게 어떤 가치를 전달하는지 '판단하는 힘'을 길러야 합니다. 직무의 이름에 스스로를 가두지 않고 문제 해결을 위해 필요한 모든 수단을 자유롭게 활용할 수 있는 역량을 갖추는 것이 중요합니다. 토스의 사례처럼 조직 차원에서도 디자이너가 더 넓은 범위에서 사고할 수 있도록 제도적 제약을 제거해 나가는 변화가 필요할 것입니다.

Smarter Live Streaming at Scale: Rolling Out VBR for All Netflix Live Events (새 탭에서 열림)

넷플릭스는 전 세계 라이브 스트리밍 서비스의 효율성과 품질을 최적화하기 위해 기존의 고정 비트레이트(CBR) 방식을 가변 비트레이트(VBR)로 전면 교체했습니다. VBR 도입을 통해 네트워크 트래픽을 평균 15% 절감하고 리버퍼링 현상을 5% 줄이는 성과를 거두었으나, 장면 복잡도에 따라 급변하는 비트레이트 특성상 서버 과부하를 예측하기 어려워지는 기술적 과제에 직면했습니다. 이를 해결하기 위해 넷플릭스는 실시간 트래픽 수치 대신 명목 비트레이트(Nominal Bitrate)를 기준으로 서버 용량을 예약 관리하는 전략을 도입하여 대규모 생중계 환경에서도 시스템 안정성을 확보했습니다. ## 라이브 스트리밍에 VBR을 도입한 이유 * **전송 효율 극대화**: CBR은 정적인 장면에서도 고정된 데이터를 소모하여 대역폭을 낭비하지만, VBR(QVBR)은 장면의 복잡도가 낮을 때 비트레이트를 대폭 낮추고 복잡한 장면에서만 비트를 집중 투입하여 효율을 높입니다. * **사용자 경험 개선**: 데이터 전송량이 평균적으로 감소함에 따라 시작 지연 시간(Start-up delay)이 단축되고, 시간당 리버퍼링 발생 횟수가 약 5% 감소하는 효과를 확인했습니다. * **네트워크 부하 경감**: 전체 이벤트 전송 바이트는 15%, 피크 타임 트래픽은 약 10% 감소하여 넷플릭스의 자체 CDN인 오픈 커넥트(Open Connect)의 운영 효율이 크게 향상되었습니다. ## 가변 비트레이트가 유발하는 시스템 불안정성 * **예측 불가능한 트래픽 패턴**: CBR 환경에서는 현재 트래픽을 통해 서버 수용량을 쉽게 예측할 수 있었으나, VBR은 화면 구성에 따라 비트레이트가 급락하거나 치솟기 때문에 단순 측정만으로는 서버의 실제 여유 자원을 판단하기 어렵습니다. * **서버 과점유(Over-admitting) 위험**: 잔잔한 장면이 이어져 비트레이트가 낮게 유지될 때, 트래픽 스티어링 시스템이 서버가 유휴 상태라고 판단하여 너무 많은 세션을 할당할 수 있습니다. * **동시 스파이크 발생**: 경기 중 꽃가루가 뿌려지거나 카메라가 빠르게 회전하는 등 화면이 복잡해지는 순간, 모든 세션의 비트레이트가 동시에 급증하면서 네트워크 인터페이스 카드(NIC)의 한계를 초과하고 패킷 손실 및 장애를 유발할 수 있습니다. ## 예약 기반 용량 관리를 통한 해결책 * **실제 트래픽 대신 명목 수치 사용**: 서버의 가용 용량을 결정할 때 현재 전송 중인 실제 비트레이트가 아닌, 스트림에 설정된 최대치인 '명목 비트레이트'를 기준으로 계산합니다. * **용량 예약(Capacity Reservation)**: 특정 스트림이 현재 낮은 대역폭을 사용하더라도, 언제든 복잡한 장면에서 높은 비트레이트로 튈 수 있음을 전제하고 미리 용량을 할당해 둡니다. * **안정적인 트래픽 제어**: 이러한 접근 방식을 통해 VBR의 효율성은 그대로 누리면서도, CBR 시절의 예측 가능성을 확보하여 급격한 장면 변화 시에도 서버가 안정적으로 트래픽을 처리할 수 있게 되었습니다. ## 실용적인 결론 대규모 라이브 시스템에서 VBR을 도입할 때는 단순히 인코딩 설정을 바꾸는 것에 그치지 않고, **모니터링 및 트래픽 스티어링 로직을 실제 부하가 아닌 논리적인 예약(Reservation) 기반으로 재설계**해야 합니다. 이는 자원 활용의 극단적인 효율성보다는 시스템의 가용성과 안정성을 우선시하는 전략으로, 대규모 트래픽 스파이크가 빈번한 라이브 환경에서 필수적인 접근입니다.

KernelEvolve: How Meta’s Ranking Engineer Agent Optimizes AI Infrastructure (새 탭에서 열림)

Meta는 하드웨어와 모델 아키텍처의 급격한 다양화로 인해 발생하는 커널 최적화 병목 현상을 해결하기 위해 에이전트 기반 시스템인 'KernelEvolve'를 도입했습니다. KernelEvolve는 숙련된 엔지니어가 수주간 작업해야 했던 커널 튜닝 및 최적화 과정을 단 몇 시간 만의 자동화된 탐색으로 단축하며, NVIDIA GPU부터 자체 칩인 MTIA에 이르기까지 다양한 이기종 하드웨어에서 성능을 극대화합니다. 이를 통해 Meta는 수조 건의 일일 추론 요청을 효율적으로 처리하고 복잡한 ML 모델 혁신 속도를 가속화하고 있습니다. **폭발적인 커널 요구량과 수동 최적화의 한계** * **복잡도의 증가:** 최적화가 필요한 커널의 수는 {하드웨어 종류 및 세대 × 모델 아키텍처 × 연산자 수}의 곱에 비례하여 기하급수적으로 증가하며, 수천 개의 고유 구성을 생성합니다. * **하드웨어 이질성:** NVIDIA 및 AMD GPU, Meta 자체 칩인 MTIA는 각기 다른 메모리 계층, 명령어 집합, 실행 모델을 가집니다. 특정 플랫폼에 최적화된 커널이 다른 플랫폼에서는 성능이 저하되거나 작동하지 않는 문제가 발생합니다. * **모델 아키텍처의 진화:** 초기 임베딩 중심 모델에서 시퀀스 학습 및 어텐션 기반 모델을 거쳐, 최신 생성형 광고 추천 모델(GEM)과 대규모 추론 모델에 이르기까지 연산자의 유형이 끊임없이 변화하고 있습니다. * **확장성 부족:** 전문가에 의존하는 수동 튜닝 방식은 하드웨어와 모델의 빠른 진화 속도를 따라잡지 못해 모델 배포를 늦추는 결정적인 병목 구간이 됩니다. **KernelEvolve: 에이전트 기반 커널 저작 시스템** * **탐색 중심의 최적화:** 단순한 일회성 코드 생성이 아니라, 커널 최적화를 '탐색 문제'로 정의하여 수백 개의 대안 구현을 시도하고 최적의 솔루션을 식별합니다. * **피드백 루프 아키텍처:** LLM이 생성한 커널 후보를 전용 작업 하네스(Job-harness)에서 평가하고, 실행 결과 및 진단 정보를 다시 LLM에 피드백하여 지속적으로 개선하는 구조를 갖췄습니다. * **광범위한 언어 및 하드웨어 지원:** Triton, Cute DSL, FlyDSL과 같은 고수준 DSL은 물론 CUDA, HIP, MTIA C++ 등 저수준 언어까지 생성할 수 있어 공개 및 독점 하드웨어를 모두 지원합니다. **성능 혁신 및 실질적 도입 성과** * **처리량(Throughput) 대폭 향상:** NVIDIA GPU 기반 Andromeda 광고 모델의 추론 처리량을 60% 이상 개선했으며, Meta 자체 MTIA 칩 환경에서도 광고 모델 학습 처리량을 25% 이상 높였습니다. * **개발 주기 단축:** 프로파일링, 최적화, 교차 하드웨어 디버깅 등 수주가 소요되던 전문가의 엔지니어링 작업을 단 몇 시간의 자동 탐색으로 대체했습니다. * **실제 서비스 적용:** KernelEvolve가 최적화한 코드는 현재 Meta의 프로덕션 환경에서 매일 수조 건의 추론 요청을 처리하는 데 사용되고 있습니다. KernelEvolve는 커널 개발을 수동 프로세스에서 자동화된 적응형 시스템으로 전환함으로써 소프트웨어와 하드웨어 간의 결합 방식을 근본적으로 바꾸고 있습니다. 하드웨어 포트폴리오가 다양해질수록 이러한 에이전트 기반 인프라 최적화는 새로운 칩을 통합하는 데 필요한 엔지니어링 노력을 획기적으로 줄여줄 것입니다.

불변 블롭 저장소 Magic Pocket의 저장 효율성 개선 (새 탭에서 열림)

Dropbox의 엑사바이트급 불변(Immutable) 블록 저장소인 'Magic Pocket'은 데이터 무결성과 효율적인 확장을 위해 설계된 핵심 인프라입니다. 최근 새로운 데이터 배치 서비스인 'Live Coder' 도입 과정에서 볼륨이 채 5%도 채워지지 않는 심각한 파편화 문제가 발생하여 스토리지 오버헤드가 급격히 증가하는 위기를 맞았습니다. 이를 해결하기 위해 Dropbox 엔지니어링 팀은 기존의 안정 상태 압축 방식을 넘어, 저밀도 볼륨을 집중적으로 재구성하는 다각적인 전략을 통해 스토리지 효율을 이전 수준보다 더욱 개선하는 데 성공했습니다. **불변 스토리지 구조와 공간 회수 메커니즘** * Magic Pocket은 데이터를 한 번 쓰면 수정하지 않는 불변 방식을 채택하고 있어, 사용자 데이터가 삭제되거나 수정되어도 기존 데이터는 즉시 지워지지 않고 볼륨 내에 그대로 남습니다. * 이러한 특성상 시간이 지남에 따라 실제 데이터보다 더 많은 디스크 공간을 점유하는 '파편화'가 발생하며, 이를 관리하지 않으면 스토리지 오버헤드가 기하급수적으로 늘어납니다. * 공간 회수는 가비지 컬렉션(참조되지 않는 데이터 식별)과 압축(Compaction)이라는 두 단계로 이루어지며, 압축은 유효한 데이터만 골라 새 볼륨에 옮겨 적고 기존 볼륨을 퇴거시키는 방식으로 수행됩니다. * 데이터 가용성을 위해 에러저 코딩(Erasure Coding)을 사용하여 복제 방식보다 적은 비용으로 결함 허용 능력을 유지합니다. **신규 서비스 도입으로 인한 저밀도 볼륨 문제** * 배경 쓰기 증폭을 줄이기 위해 도입된 'Live Coder' 서비스가 예상치 못하게 할당량의 5% 미만만 채워진 수많은 저밀도 볼륨을 생성하는 부작용을 일으켰습니다. * Magic Pocket의 볼륨은 고정된 크기를 가지기 때문에, 데이터가 적게 들어있어도 전체 용량을 점유하게 되어 실제 저장된 바이트 대비 물리적 디스크 소비량이 급등했습니다. * 기존의 압축 방식은 데이터 분포가 비교적 균일한 상태를 가정하고 설계되었기에, 엑사바이트 규모에서 발생한 대량의 저밀도 볼륨을 빠르게 정리하기에는 역부족이었습니다. **기존 L1 압축 전략의 동작과 한계** * 기존의 L1 전략은 거의 다 채워진 '호스트 볼륨'의 빈 공간에 파편화된 '공여 볼륨(Donor)'의 데이터를 채워 넣는 방식입니다. * 이 방식은 단순하고 메타데이터 업데이트 비용이 적지만, 한 번의 실행으로 회수되는 공간이 제한적이라는 단점이 있습니다. * 데이터 밀도가 극도로 낮은 볼륨이 대량으로 존재하는 상황에서는 L1 전략의 처리 속도가 파편화 속도를 따라잡지 못해 스토리지 비용을 실시간으로 절감하기 어려웠습니다. **실용적인 결론 및 권장 사항** 대규모 불변 스토리지 시스템을 운영할 때는 데이터의 배치 로직 변화가 스토리지 효율에 미치는 영향을 실시간으로 모니터링하는 것이 필수적입니다. 특히 데이터 밀도가 급격히 변하는 이례적인 상황에 대비하여, 단순히 빈 공간을 채우는 방식의 압축뿐만 아니라 저밀도 볼륨들을 한데 묶어 대량으로 정리할 수 있는 유연한 압축 전략을 병행 구축하는 것이 인프라 비용 최적화의 핵심입니다.

AI 시대를 위해 캐시를 재고하는 이유 (새 탭에서 열림)

AI 트래픽의 급격한 증가는 인간 사용자의 행동 패턴을 기반으로 설계된 기존 CDN 캐시 아키텍처에 큰 도전 과제를 던지고 있습니다. AI 크롤러와 에이전트는 일반적인 인간 사용자와 달리 웹사이트 전체를 순차적으로 스캔하거나 방대한 양의 '롱테일(비인기)' 콘텐츠를 집중적으로 요청하며, 이는 기존 캐시 적중률을 떨어뜨리고 원본 서버의 부하를 가중시키는 결과를 초래합니다. Cloudflare는 이러한 AI 시대의 독특한 데이터 접근 패턴에 대응하기 위해 CDN 캐시 설계의 근본적인 재검토가 필요하다고 주장합니다. ### AI 트래픽과 인간 트래픽의 차이점 * **높은 고유 URL 요청 비율:** AI 에이전트는 정보를 정제하고 정확도를 높이기 위해 반복적인 루핑(looping)을 수행하며, 이 과정에서 요청의 70~100%가 중복되지 않는 고유 URL로 구성됩니다. * **콘텐츠 접근의 광범위성:** 인기 페이지에 집중하는 인간과 달리, AI는 훈련 데이터 수집이나 검색 증강 생성(RAG)을 위해 기술 문서, 이미지, 블로그 등 웹사이트의 거의 모든 콘텐츠를 훑어갑니다. * **크롤링 비효율성:** AI 크롤러는 브라우저 측 캐싱이나 세션 관리를 제대로 활용하지 않으며, 독립적인 인스턴스를 여러 개 실행하여 동일한 콘텐츠를 중복 요청하거나 잘못된 URL 처리로 인해 많은 404 오류를 발생시키기도 합니다. ### 기존 캐시 알고리즘(LRU)의 한계와 영향 * **캐시 오염(Cache Churn):** 대규모 AI 스캔이 발생하면 인간 사용자가 자주 찾는 인기 콘텐츠가 캐시에서 밀려나고, 그 자리를 AI가 일회성으로 긁어가는 비인기 콘텐츠가 차지하게 됩니다. * **캐시 적중률(Hit Rate) 하락:** 가장 오래전에 사용된 데이터를 먼저 삭제하는 LRU(Least Recently Used) 알고리즘은 AI의 공격적인 스캔 패턴 아래에서 효율이 급격히 떨어지며, 이는 곧 캐시 미스 증가로 이어집니다. * **원본 서버 및 비용 부담:** 캐시 미스가 발생하면 모든 요청이 원본(Origin) 서버로 직접 전달되어 서버 부하가 커지고, 데이터 전송에 따른 이그레스(Egress) 비용이 상승하며 응답 속도는 느려집니다. ### AI 시대의 웹 운영을 위한 새로운 방향 * **운영자의 이분법적 선택:** 웹 운영자는 이제 자원 보호를 위해 AI 크롤러를 차단할 것인지, 아니면 AI 모델의 최신 정보를 유지하기 위해 이들을 수용할 것인지 선택해야 하는 상황에 놓여 있습니다. * **차세대 캐시 전략의 필요성:** 기존의 단순한 프리페칭(Prefetching)이나 캐시 만료 정책은 더 이상 유효하지 않으며, AI 에이전트의 반복적인 루핑과 롱테일 접근 패턴을 반영한 지능적인 캐시 설계가 필수적입니다. * **연구 및 협업:** Cloudflare는 ETH Zurich 연구진과 협력하여 AI 트래픽 패턴을 모델링하고, 이를 기반으로 CDN이 AI 시대에 어떻게 적응해야 할지에 대한 기술적 방향성을 제시하고 있습니다. 웹 운영자는 자신의 콘텐츠가 AI 검색 결과나 학습 데이터에 포함되기를 원한다면, AI 트래픽의 특성을 이해하고 이를 효율적으로 처리할 수 있는 도구를 도입해야 합니다. 단순히 트래픽을 차단하는 것을 넘어, 'Pay per crawl'과 같은 수익화 모델이나 AI 전용 캐시 계층을 고려하는 등 변화하는 환경에 맞춘 유연한 대응 전략이 권장됩니다.

Shoptalk 2026 인사이트: 에이전트가 리테일을 변화시키는 방식 (새 탭에서 열림)

Shoptalk 2026에서 확인된 에이전틱 커머스(Agentic Commerce)는 이제 미래의 비전이 아닌, 대화형 어시스턴트와 인앱 결제 등을 통해 실제 매출을 일으키는 현실로 자리 잡았습니다. 리테일 리더들은 단순 검색을 넘어 맥락 중심의 AI 발견 시스템으로 전환되는 시장 구조에 대응하기 위해 제품 데이터의 표준화와 체계적인 공급 전략을 고민하고 있습니다. 기술이 상거래의 전 과정을 자동화할수록 소비자의 선택을 받기 위한 브랜드의 신뢰도와 차별화된 고객 경험의 가치는 그 어느 때보다 중요해질 전망입니다. **에이전틱 커머스의 확산과 데이터 전략의 변화** - AI 에이전트가 새로운 '스토어프론트' 역할을 수행함에 따라, 에이전트에게 노출되지 않는 브랜드는 시장에서 소외될 위험이 커지고 있습니다. - 소비자 검색 패턴이 키워드 중심에서 맥락 중심(예: 여행 계획, 특정 상황에 맞는 가전 비교)으로 변화하고 있으며, OpenAI에 따르면 검색의 70%가 이러한 제약 조건을 포함합니다. - 웹 크롤링에만 의존하기보다 에이전트에게 직접 구조화된 데이터를 제공하는 '다이렉트 제품 피드'의 중요성이 강조되고 있습니다. - 세포라(Sephora)처럼 로열티 데이터를 AI와 결합해 맞춤형 샘플이나 혜택을 제안하는 실질적인 활용 사례가 늘고 있습니다. **채팅창을 넘어선 임베디드 커머스로의 확장** - 에이전틱 커머스는 단순한 채팅 기능을 넘어 광고 클릭부터 결제까지 앱을 이탈하지 않고 완료하는 '임베디드 커머스' 형태로 진화하고 있습니다. - 메타(Meta)는 에이전틱 커머스 프로토콜(ACP)을 활용해 광고 내에서 제품 상세 확인, AI 리뷰 요약, 결제까지 한 번에 이뤄지는 흐름을 구현했습니다. - 미래의 브랜드들은 자사 웹사이트보다 에이전틱 인프라 위에서 네이티브하게 구축되어 고객 획득 비용을 낮추는 전략을 취할 것으로 예측됩니다. - 패션, 뷰티 등 카테고리에 특화된 AI 앱들이 등장함에 따라 리테일러는 1방향 채널과 3자 에이전트 경험 사이의 투자 균형을 결정해야 합니다. **AI 환경에서 더욱 강조되는 브랜드 정체성과 신뢰** - AI가 제품 비교와 발견을 쉽고 빠르게 만들수록, 고객이 특정 브랜드를 선택하게 만드는 힘은 결국 브랜드에 대한 신뢰와 애착에서 나옵니다. - 뉴발란스(New Balance)의 매장 내 전문성 강화나 스티치 픽(Stitch Fix)의 AI 기반 개인화 시각화 도구처럼 고유한 고객 데이터를 활용한 차별화가 필수적입니다. - 에이전트가 주도하는 여정에서도 브랜드의 일관성을 유지하기 위해 고객 데이터와 정체성을 모든 채널에서 통합 관리하는 시스템이 요구됩니다. - '위안을 주는 경제(Soothing Economy)' 개념처럼 오프라인 매장에서의 정서적 경험과 온라인의 효율성을 결합하려는 시도가 이어지고 있습니다. **실무적인 결론 및 제언** 에이전틱 커머스 시대에는 고객이 결제 단계에 도달했을 때의 마찰을 최소화하는 것이 핵심입니다. Stripe의 '최적화된 결제 수트(Optimized Checkout Suite)'나 '에이전틱 커머스 수트(Agentic Commerce Suite)'와 같은 도구를 활용하면, 복잡한 개별 통합 과정 없이도 다양한 AI 에이전트와 플랫폼에 제품 카탈로그 정보를 신속하게 배포하고 전환율을 높일 수 있습니다. 기술적 인프라를 탄탄히 구축하는 동시에, AI가 대체할 수 없는 브랜드만의 고유한 가치를 정립하는 투트랙 전략이 필요합니다.

호평받은 AAAA 게임 ‘더 라스트 메도우’의 멀티플레이어 후속작 발표: 지금 플레이 가능 (새 탭에서 열림)

디스코드는 데스크톱 앱 내에서 즉시 플레이할 수 있는 세계 최초의 DBMMIRPG(Discord-Based Massively Multiplayer Incremental Role Playing Game)인 'Last Meadow Online'을 출시했습니다. 플레이어들은 주인공 Wumpus와 힘을 합쳐 초원을 위협하는 드래곤 'Grass Toucher'를 물리쳐야 하며, 이는 플랫폼 내에서 수많은 사용자가 동시에 협력하는 소셜 게임 경험을 제공합니다. 이번 이벤트는 4월 7일까지 한시적으로 운영되며, 참여자들에게는 특별한 보상이 주어집니다. **DBMMIRPG: 디스코드 기반의 대규모 멀티플레이어 증분형 게임** - 별도의 설치 없이 디스코드 데스크톱 환경에서 직접 실행되는 웹 기반 통합 게임 엔진을 활용합니다. - '증분형(Incremental)' 게임 방식을 채택하여 다수의 사용자가 실시간으로 협동하여 목표를 달성하는 구조를 가지고 있습니다. - 전 세계 디스코드 사용자들이 하나의 월드에 접속하여 공동의 적을 상대하는 대규모 소셜 인터랙션을 강조합니다. **클래스 시스템 및 협업 메커니즘** - 플레이어는 팔라딘(Paladin)의 빛, 레인저(Ranger)의 원거리 공격, 사제(Priest)의 치유 능력 중 하나를 선택하여 전투에 기여할 수 있습니다. - 단순 전투 외에도 수공예 기술(Handiwork skills) 등을 활용해 팀의 승리를 돕는 다양한 역할 수행이 가능합니다. - 전 세계 모험가들과 실시간으로 협력해야만 최종 보스인 'Grass Toucher'를 제압할 수 있는 구조로 설계되었습니다. **참여 기간 및 한정 보상 체계** - 이번 이벤트는 4월 7일까지만 한정적으로 진행되어 희소성을 높였습니다. - 보스 처치에 기여한 모든 플레이어에게는 자신의 디스코드 프로필에 전시할 수 있는 한정판 프로필 배지가 지급됩니다. - 친구들을 초대하여 함께 플레이하는 소셜 기능을 통해 커뮤니티의 참여를 독려하고 있습니다. 디스코드 데스크톱 사용자는 4월 7일 이내에 게임에 접속하여 짧은 시간 동안이라도 드래곤 토벌에 기여하는 것을 추천합니다. 이를 통해 디스코드 플랫폼이 추구하는 게임 통합 환경을 경험하고, 자신의 프로필을 꾸밀 수 있는 한정판 배지를 획득할 기회를 놓치지 마시기 바랍니다.

Build With More Context and More Control in Figma Make | Figma Blog (새 탭에서 열림)

Figma는 정적인 디자인을 넘어 실제 작동하는 경험을 즉각적으로 공유할 수 있도록 'Make Prototype' 기능을 생태계 전반에 통합했습니다. 이제 사용자는 AI를 활용해 디자인을 인터랙티브한 프로토타입으로 빠르게 변환하고, 이를 Figma Design뿐만 아니라 FigJam, Figma Slides 등 협업 환경 어디에나 임베딩하여 공유할 수 있습니다. 이러한 변화는 복잡한 설명 대신 실제 작동 방식을 시각적으로 보여줌으로써 팀원 간의 의사소통 효율을 극대화하는 것을 목표로 합니다. **AI 기반의 신속한 프로토타입 생성 (Make Prototype)** * Figma AI의 'Make Prototype' 기능을 사용하면 수동으로 인터랙션을 연결하는 번거로움 없이, 정적인 레이아웃에서 클릭 가능한 프로토타입을 즉시 생성할 수 있습니다. * AI가 디자인 컨텍스트를 이해하고 화면 간의 논리적인 흐름을 자동으로 구축하여 프로토타입 제작 시간을 획기적으로 단축합니다. * 디자인 초기 단계부터 고충실도(High-fidelity)의 인터랙션을 구현하여 아이디어를 더 명확하게 검증할 수 있습니다. **Figma 제품군 전반의 매끄러운 임베딩 워크플로우** * 생성된 프로토타입은 Figma Design에만 국한되지 않고, Figma Slides와 FigJam 등 모든 협업 공간에 직접 삽입하여 실행할 수 있습니다. * Figma Slides에서는 발표 도중 별도의 창 전환 없이 슬라이드 내부에서 프로토타입을 직접 시연하며 생생한 디자인 의도를 전달합니다. * FigJam에서는 브레인스토밍 단계에서 프로토타입을 함께 배치하여, 아이디어 구상과 동시에 사용자 흐름을 실제로 테스트하고 논의할 수 있습니다. **효율적인 의사소통을 위한 'Show don't tell' 전략** * 단순한 이미지나 텍스트 설명보다 실제 작동하는 프로토타입을 통해 이해관계자들이 제품의 맥락을 직관적으로 파악하도록 돕습니다. * 협업 과정에서 발생하는 오해를 줄이고, 개발자나 기획자가 실제 사용자 경험을 미리 체감하게 함으로써 고도화된 피드백을 유도합니다. * 디자인 결과물을 공유하는 방식이 '설명하는 것'에서 '보여주는 것'으로 전환되어 전체 제품 개발 생태계의 속도가 향상됩니다. 디자인의 가치는 공유되고 이해될 때 비로소 완성됩니다. 이제 Figma의 'Make' 기능을 적극 활용하여 정적인 화면 뒤에 숨겨진 동적인 경험을 모든 협업 채널에서 실시간으로 시연해 보세요. 특히 Figma Slides에 프로토타입을 임베딩하여 활용한다면, 발표의 몰입도를 높이고 더 빠른 의사결정을 끌어낼 수 있을 것입니다.

Amazon ECS 관리형 인스턴스를 위한 관리형 데몬 지원 발표 | Amazon Web Services (새 탭에서 열림)

Amazon ECS가 관리형 인스턴스(Managed Instances)에서 독립적인 에이전트 관리가 가능한 '관리형 데몬' 기능을 출시했습니다. 이제 플랫폼 엔지니어는 애플리케이션 팀의 배포 주기와 무관하게 모니터링, 로깅, 트레이싱 도구를 중앙에서 제어하고 업데이트할 수 있습니다. 이 기능은 데몬이 애플리케이션보다 먼저 시작되고 나중에 종료되도록 보장하여, 가시성의 공백 없는 안정적인 운영 환경을 제공합니다. ### 운영 효율성을 높이는 생명주기 분리 * 플랫폼 팀이 모니터링 및 로깅 에이전트를 애플리케이션 작업과 분리하여 독립적으로 배포, 업데이트 및 수정할 수 있습니다. * 에이전트 업데이트 시 애플리케이션 작업 정의(Task Definition)를 수정하거나 서비스를 재배포할 필요가 없어 운영팀 간의 조율 부담이 사라집니다. * '선 실행 후 종료(Start before stop)' 메커니즘을 통해 모든 인스턴스에서 애플리케이션이 실행되기 전 데몬이 먼저 활성화되도록 보장합니다. ### 유연한 자원 할당 및 배포 제어 * 특정 용량 공급자(Capacity Provider)를 대상으로 데몬을 배포할 수 있어 인프라 전반에 걸친 유연한 롤아웃이 가능합니다. * 데몬 전용 작업 정의를 통해 CPU 및 메모리 파라미터를 별도로 관리하며, 인스턴스당 단 하나의 데몬만 실행되어 시스템 자원 활용을 최적화합니다. * 배포 시 ECS가 인스턴스 교체 및 작업 마이그레이션을 자동으로 수행하며, 자동 롤백 기능을 통해 업데이트 중 발생할 수 있는 리스크를 최소화합니다. ### 심층적인 호스트 접근과 네트워킹 기술 * 새로운 `daemon_bridge` 네트워크 모드를 도입하여 애플리케이션 네트워크 구성과 격리된 상태에서 데몬과 작업 간의 통신을 지원합니다. * 권한 부여된 컨테이너(Privileged container), Linux 기능(Capabilities) 추가, 호스트 파일 시스템 경로 마운트 등 강력한 호스트 수준 접근 권한을 제공합니다. * 이러한 심층 접근 권한은 시스템 호출 모니터링이나 보안 검사 등 호스트 레벨의 세밀한 가시성이 필요한 도구 운영에 필수적입니다. 관리형 데몬 서비스는 추가 비용 없이 사용한 컴퓨팅 자원에 대해서만 요금이 부과됩니다. CloudWatch 에이전트나 타사 보안 솔루션을 운영하는 플랫폼 팀은 애플리케이션 가용성에 영향을 주지 않으면서 운영 도구를 최신 상태로 유지하기 위해 이 기능을 즉시 도입하는 것을 권장합니다.

GitHub 전반의 오픈 소스 공급망 보안 강화 (새 탭에서 열림)

Principal Software Engineer, GitHub