네이버 검색의 대규모 메트릭 저장소, VictoriaMetrics 운영기 (새 탭에서 열림)

데이터베이스 설계 시 관습적으로 사용하는 '소프트 삭제(Soft Delete)' 방식이 유발하는 구조적 결함과 성능 저하 문제를 심층적으로 분석하고 이를 해결할 수 있는 아키텍처 대안을 제시합니다. 삭제 여부를 나타내는 플래그(Flag) 컬럼을 사용하는 방식은 구현이 간단해 보이지만, 장기적으로는 쿼리의 복잡도를 높이고 데이터 무결성을 위협하는 원인이 됩니다. 따라서 서비스의 규모와 요구사항에 따라 데이터 이관이나 상태 관리를 통한 물리적 삭제를 적절히 혼합하는 전략이 필요합니다. **소프트 삭제가 초래하는 기술적 부채** - **쿼리 복잡도 및 휴먼 에러**: 모든 조회 쿼리에 `WHERE deleted = false`와 같은 조건을 강제해야 하며, 조인(Join) 연산이 늘어날수록 조건을 누락할 위험이 커져 보안 및 비즈니스 로직 오류로 이어집니다. - **유니크 제약 조건(Unique Constraint) 충돌**: 사용자 ID나 이메일처럼 유일성이 보장되어야 하는 컬럼에서, 삭제된 레코드가 테이블에 남아 있으면 동일한 값의 새 데이터를 삽입할 때 인덱스 충돌이 발생합니다. - **인덱스 효율 저하**: 삭제 플래그는 카디널리티(Cardinality)가 매우 낮은 데이터이므로 인덱스를 생성해도 스캔 효율이 떨어지며, 불필요한 데이터가 테이블에 계속 축적되어 전체적인 I/O 성능을 저하시킵니다. **무결성 유지를 위한 아키텍처 대안** - **데이터 이관(History/Archive Table) 방식**: 삭제가 발생할 때 해당 로우를 원본 테이블에서 물리적으로 삭제하는 대신, 트리거나 애플리케이션 로직을 통해 '삭제 전용 테이블'로 옮겨 메인 테이블의 크기를 최적화합니다. - **데이터베이스 뷰(View) 활용**: 애플리케이션 계층에서는 삭제되지 않은 데이터만 필터링된 뷰를 참조하게 함으로써 개발자가 실수로 삭제된 데이터를 조회하는 상황을 원천적으로 차단합니다. - **복합 유니크 인덱스 설계**: 삭제 시점을 기록하는 `deleted_at` 컬럼을 활용하여 `(ID, deleted_at)` 형태의 복합 인덱스를 구성함으로써, 삭제된 데이터와 활성 데이터 간의 제약 조건 충돌을 우회합니다. **실무적인 선택 기준** 단순히 데이터 복구 가능성을 위해 소프트 삭제를 채택하기보다는, 해당 데이터가 비즈니스적으로 '상태가 변경된 것(예: 탈퇴 회원)'인지 아니면 '완전히 폐기된 것'인지를 먼저 구분해야 합니다. 법적 근거에 의한 보관이 목적이라면 별도의 이력 테이블로 분리하는 것이 성능과 유지보수 측면에서 유리하며, 단순한 실수 방지가 목적이라면 트랜잭션 로그나 백업 시스템을 활용하는 물리 삭제 방식을 우선적으로 고려하는 것이 권장됩니다.

Making Rust Workers reliable: panic and abort recovery in wasm‑bindgen (새 탭에서 열림)

Cloudflare Workers 환경에서 Rust로 작성된 WebAssembly(Wasm)는 예기치 못한 패닉(Panic)이나 중단(Abort)이 발생할 경우 런타임이 정의되지 않은 상태로 남아 동일한 인스턴스의 다른 요청까지 실패하게 만드는 '샌드박스 오염' 문제를 안고 있었습니다. 이를 해결하기 위해 Cloudflare는 `wasm-bindgen` 메인 프로젝트와 협력하여 Wasm 예외 처리 기능을 활용한 `panic=unwind` 지원과 중단 복구 메커니즘을 도입했습니다. 결과적으로 단일 요청의 실패가 전체 서비스 중단으로 이어지는 것을 방지하고, 상태 유지가 필요한 애플리케이션에서도 안정적인 오류 복구가 가능해졌습니다. ### 초기 대응 및 완화 전략 본격적인 기능 개선에 앞서, Cloudflare는 운영 환경에서의 피해를 최소화하기 위해 사용자 정의 패닉 핸들러와 JavaScript 프록시를 활용한 초기 완화책을 적용했습니다. * **패닉 핸들러 도입:** Rust 내부에 상태를 추적하는 패닉 핸들러를 설치하여 실패가 발생하면 전체 애플리케이션을 다시 초기화하도록 설정했습니다. * **Proxy 기반 간접 참조:** JavaScript 영역에서 Rust 호출 경계를 `Proxy`로 감싸 모든 진입점을 캡슐화하고, 실패 시 안전하게 Wasm 모듈을 재로드했습니다. * **한계점:** 이 방식은 서비스 가용성은 높였으나, 전체 애플리케이션을 재시작해야 하므로 메모리에 상태를 보관하는 Durable Objects 같은 서비스에서는 데이터 손실이 발생하는 단점이 있었습니다. ### Wasm 예외 처리를 통한 panic=unwind 구현 상태를 보존하면서 오류를 복구하기 위해 Wasm의 최신 표준인 예외 처리(Exception Handling) 제안을 활용하여 Rust의 패닉 언와인딩(Unwinding)을 구현했습니다. * **컴파일 옵션 변경:** `RUSTFLAGS='-Cpanic=unwind'`와 `-Zbuild-std`를 사용하여 표준 라이브러리가 언와인딩을 지원하도록 다시 빌드했습니다. * **wasm-bindgen 툴체인 업데이트:** Wasm 파서인 Walrus가 `try`, `catch`, `rethrow` 명령어를 인식하도록 수정하고, JavaScript와 Rust 경계에서 예외가 올바르게 전달되도록 개선했습니다. * **Boundary 처리:** Rust에서 발생한 패닉이 JavaScript의 `PanicError`로 변환되도록 했으며, `extern "C-unwind"`를 통해 함수 호출 경계를 넘나드는 언와인딩을 허용했습니다. * **클로저 안전성:** `MaybeUnwindSafe` 트레잇을 도입하여 언와인딩 시 안전하지 않은 참조를 캡처하는 클로저를 체크하고, 필요한 경우 패닉 시 즉시 중단되는 `Closure::new_aborting` 변형을 제공합니다. ### 중단(Abort) 복구 및 포이즌 필(Poison Pill) 메커니즘 메모리 부족(OOM)과 같이 언와인딩이 불가능한 '중단' 상황에서는 메모리 상태가 오염될 가능성이 높기 때문에, 해당 인스턴스의 재실행을 원천 봉쇄하는 전략을 사용합니다. * **포이즌 필 플래그:** `wasm-bindgen`은 이제 모든 Wasm 모듈에 내부 상태 플래그를 주입합니다. 만약 Rust 코드에서 중단이 발생하면 이 플래그가 즉시 설정됩니다. * **재실행 방지:** 이후 JavaScript에서 해당 Wasm 인스턴스의 어떤 함수라도 호출하려고 하면, Rust 코드를 실행하기 전에 플래그를 먼저 확인하여 즉시 JavaScript 에러를 발생시킵니다. * **안전성 보장:** 이를 통해 오염된 메모리 상태에서 코드가 다시 실행되어 발생할 수 있는 보안 취약점이나 예측 불가능한 동작을 완전히 차단합니다. Wasm 기반의 Rust 서비스를 운영한다면 최신 버전의 `wasm-bindgen`과 `workers` 라이브러리를 사용하고, 특히 Durable Objects와 같이 상태 보존이 중요한 경우 `panic=unwind` 설정을 활성화할 것을 권장합니다. 이는 단순한 안정성 향상을 넘어, Wasm이 네이티브 환경과 동등한 수준의 오류 복구 능력을 갖추게 되었음을 의미합니다.

신뢰성 향상을 위한 SLO/SLI 도입 3편 - 서비스 적용 사례 (새 탭에서 열림)

SLI(Service Level Indicator)와 SLO(Service Level Objective)의 도입은 단순히 지표를 설정하는 기술적 작업을 넘어, 사용자 중심의 관점으로 서비스를 재정의하고 조직의 협업 문화를 구축하는 과정입니다. 정량적인 지표와 오류 예산(Error Budget) 개념을 활용하면 서비스의 신뢰성과 비즈니스 혁신 사이에서 객관적인 판단 근거를 마련할 수 있습니다. 결과적으로 SLO는 사용자에게 안정적인 경험을 제공하는 동시에 엔지니어링 리소스를 효율적으로 배분하는 핵심 도구가 됩니다. **신뢰성 향상을 위한 마인드셋과 협업** * **사용자 여정 중심의 사고**: 서비스의 수많은 기능 중 사용자가 가장 많이 사용하거나 반드시 필요한 '핵심 사용자 여정(CUJ)'을 식별하는 것이 첫걸음입니다. * **다학제적 협업 체계**: 서비스 담당 부서(CUJ 정의), 인프라 조직(측정 환경 구축), SRE(도구 구현 및 모니터링) 등 이해관계자 모두가 목표를 공유하고 책임을 나누는 문화가 필수적입니다. **SLI/SLO 구현의 4단계 프로세스** * **CUJ 분석**: 가입, 메시지 송수신, 인증과 같이 비즈니스 목표와 사용자 경험에 직결되는 핵심 기능을 사용자 관점에서 선별합니다. * **SLI 정의**: 게이트웨이나 백엔드 등 적절한 측정 위치를 선정하고, 응답 시간(Latency)의 퍼센타일과 응답 성공률(Success Rate)에 대한 명확한 성공/실패 기준을 수립합니다. * **SLO 타깃 설정**: 28일 등 특정 기간 동안 달성할 현실적인 목표 수치를 정하며, 안정성 확보 비용과 사용자 경험 사이의 적절한 균형점을 찾습니다. * **시각화**: 전체 상태와 오류 예산 현황을 한눈에 파악할 수 있도록 대시보드를 구성하며, 색상(초록/주황/빨강)을 활용해 직관적인 인지성을 높입니다. **오류 예산을 활용한 의사 결정 및 운영** * **정량적 소통**: '서비스가 느리다'는 추상적 표현 대신 '응답 시간이 SLI 기준인 400ms를 초과했다'는 식의 정확한 데이터로 문제를 파악합니다. * **리소스 배분 가이드**: 오류 예산이 넉넉하면 신규 기능 출시나 공격적인 릴리스에 집중하고, 예산이 소진되어 가며 안정성 강화와 이슈 대응에 리소스를 우선 투입합니다. * **온콜(On-call) 및 예방**: 오류 예산의 상태 변화를 실시간 알림으로 받아 이슈에 신속히 대응하며, 정기적인 SLO 점검을 통해 서비스 품질을 지속적으로 관리합니다. 성공적인 SRE 문화를 정착시키기 위해서는 SLO를 단순한 규제가 아닌, 서비스의 안정성과 혁신 속도 사이에서 균형을 잡아주는 나침반으로 활용하는 것이 중요합니다. 측정 가능한 지표를 통해 막연한 불안감을 해소하고, 데이터에 기반한 의사결정을 내릴 때 비로소 지속 가능한 서비스 신뢰성을 확보할 수 있습니다.

Modernizing the Facebook Groups Search to Unlock the Power of Community Knowledge (새 탭에서 열림)

페이스북은 커뮤니티 내 방대한 정보를 사용자가 더 쉽고 정확하게 찾을 수 있도록 그룹 검색 시스템을 하이브리드 검색 아키텍처로 전면 개편했습니다. 기존의 단순 키워드 매칭 방식에서 벗어나 의미론적 이해를 더한 결과, 검색 정확도와 사용자 참여도가 크게 향상되었으며 오류율은 안정적으로 유지되었습니다. 특히 Llama 3를 활용한 자동화된 모델 기반 평가 시스템을 도입함으로써, 대규모 데이터 환경에서도 고도화된 품질 관리가 가능해졌습니다. ### 기존 커뮤니티 검색의 세 가지 마찰 지점 * **발견의 한계(Discovery):** 과거의 어휘 기반 검색은 정확한 키워드가 일치해야만 결과를 반환했습니다. 예를 들어 사용자가 '프로스팅을 얹은 작은 케이크'를 검색할 때, 게시물에 '컵케이크'라는 단어만 있다면 검색 결과에 노출되지 않는 언어적 간극이 존재했습니다. * **소비의 피로도(Consumption):** 사용자가 원하는 답을 얻기 위해 수많은 댓글을 일일이 읽고 합의된 의견을 찾아내야 하는 '노력의 세금(Effort Tax)' 문제가 발생했습니다. * **검증의 어려움(Validation):** 중고 거래나 전문적인 결정이 필요한 상황에서 커뮤니티의 집단 지성을 활용하고 싶어도, 흩어져 있는 전문 지식과 검증된 조언을 체계적으로 수집하기가 쉽지 않았습니다. ### 현대적인 하이브리드 검색 아키텍처 * **병렬 검색 전략:** 쿼리가 들어오면 토큰화 및 정규화를 거친 후, 어휘적 경로와 의미론적 경로라는 두 가지 파이프라인을 동시에 가동합니다. * **어휘적 경로 (Unicorn):** 페이스북의 역색인(Inverted Index) 시스템인 Unicorn을 사용해 고유 명사나 특정 문구가 포함된 게시물을 정확하게 찾아냅니다. * **의미론적 경로 (SSR):** 12레이어, 2억 개의 파라미터를 가진 검색 의미론적 리트리버(SSR) 모델이 쿼리를 벡터로 변환합니다. 이후 Faiss 벡터 인덱스에서 근사 최근접 이웃(ANN) 검색을 수행하여, 키워드가 겹치지 않더라도 개념적으로 유사한 콘텐츠를 추출합니다. ### MTML 아키텍처 기반의 L2 랭킹 * **특징 통합:** 검색 단계에서 수집된 후보군들을 대상으로 TF-IDF, BM25와 같은 어휘적 점수와 코사인 유사도 같은 의미론적 점수를 통합하여 분석합니다. * **다중 작업 다중 레이블(MTML) 모델:** 단일 목표가 아닌 클릭, 공유, 댓글 등 여러 사용자 참여 지표를 동시에 최적화하는 슈퍼모델 구조를 채택했습니다. 이를 통해 단순히 관련성만 높은 글이 아니라, 실제 커뮤니티에서 의미 있는 상호작용을 이끌어낼 수 있는 양질의 콘텐츠를 상위에 노출합니다. ### Llama 3 기반 자동화 평가 * **LLM 판독관 도입:** 고차원 벡터 공간에서의 검색 품질을 사람이 일일이 검증하기 어려운 한계를 극복하기 위해, Llama 3를 빌드 검증 테스트(BVT) 과정에 통합했습니다. * **정교한 품질 측정:** 검색 결과를 단순히 '좋음/나쁨'으로 나누지 않고, 주제나 도메인이 일치하는 '다소 관련 있음' 등의 세분화된 범주를 두어 검색 결과의 다양성과 미세한 관련성 개선 수치를 측정합니다. --- **실용적 제언** 방대한 커뮤니티 데이터를 다루는 서비스라면 단순 키워드 검색만으로는 사용자의 자연어 의도를 충족하기 어렵습니다. 페이스북의 사례처럼 정확도를 보장하는 **어휘적 검색**과 맥락을 파악하는 **의미론적 검색**을 병렬로 운영하고, 랭킹 단계에서 **사용자 반응 데이터(클릭, 공유 등)**를 다각도로 결합하는 하이브리드 전략이 검색 만족도를 높이는 핵심입니다. 또한, LLM을 평가 도구로 활용하면 수동 라벨링 비용을 줄이면서도 정교한 품질 관리가 가능해집니다.

카나나 스칼라 1회 세미나 현장 스케치 (새 탭에서 열림)

카나나 스칼라 1회 세미나 현장 스케치

봇 대 인간을 넘어서 (새 탭에서 열림)

웹 트래픽을 단순히 '인간'과 '봇'으로 이분법적으로 구분하던 시대는 지나갔으며, 이제는 사용자의 **의도(Intent)와 행동(Behavior)**을 파악하는 방향으로 웹 보호 전략이 진화해야 합니다. AI 에이전트의 등장과 자동화 도구의 일상화로 인해 인간과 봇의 경계가 모호해졌으며, 단순한 차단보다는 자원 보호와 데이터 관리라는 본질적인 목적에 집중해야 합니다. 따라서 미래의 웹 보안 시스템은 기술적 신호뿐만 아니라 맥락적인 비즈니스 로직을 결합하여 복합적인 위협에 대응할 수 있는 구조를 갖추어야 합니다. ### 웹 생태계의 암묵적 합의와 붕괴 * **브라우저의 중재 역할:** 과거의 웹 브라우저는 사용자의 이익(개인정보 보호, 가독성)과 웹사이트 소유자의 이익(콘텐츠 렌더링, 광고 노출) 사이에서 균형을 맞추는 '사용자 에이전트' 역할을 수행해 왔습니다. * **AI 에이전트의 파괴적 영향:** 최신 AI 에이전트들은 브라우저를 통한 표준 렌더링 과정을 생략하고 원시 데이터만 수집합니다. 이는 웹사이트 운영자가 콘텐츠의 가치를 실현(수익화)하거나 사용자의 의도를 파악하는 경로를 차단하여 기존의 웹 운영 모델을 위협합니다. * **투명성 상실:** AI가 데이터를 수집할 때 이것이 단일 사용자를 위한 요약용인지, 아니면 수백만 명을 위한 모델 학습용인지 구분할 수 없게 되면서 웹사이트 소유자의 통제권이 약화되고 있습니다. ### 기존 봇 관리 방식의 한계 * **단순 속도 제한(Rate Limiting):** 특정 IP의 요청 횟수를 제한하는 방식은 VPN이나 공용 프록시를 사용하는 다수의 선량한 사용자를 오인 차단할 위험이 큽니다. * **인간 증명(CAPTCHA)의 유효성 저하:** 캡차는 '인간성'을 확인하지만 '악의적인 인간'의 행동은 막지 못하며, AI 기술의 발달로 인해 자동화된 도구가 캡차를 통과하는 것이 점점 더 쉬워지고 있습니다. * **신호의 불확실성:** 장치 성능(CPU/GPU)이나 브라우저 지문(Fingerprinting)을 활용한 감지는 기기마다 사양이 다르고 개인정보 보호 강화로 인해 점차 정확도가 떨어지고 있습니다. ### 의도 중심의 새로운 보호 모델 * **행동 분석으로의 전환:** 접속자가 누구인지보다 "이 요청이 광고 사기에 연루되었는가?", "크롤러의 부하가 유입 트래픽에 비해 적정한가?"와 같은 실질적인 질문에 집중해야 합니다. * **봇 인증 및 신뢰 구축:** 익명성을 유지하면서도 신뢰를 증명하기 위해 HTTP 메시지 서명(Message Signatures)을 통한 크롤러 인증이나, 개인정보를 보호하는 증명 방식(Privacy Pass) 도입이 필요합니다. * **맥락적 제어:** 알려진 봇(검색 엔진 등)은 허용하되, 데이터 추출만 목적으로 하는 원하지 않는 자동화 도구는 의도와 행동 패턴에 따라 차별적으로 대응하는 유연한 정책이 요구됩니다. ### 향후 대응을 위한 제언 웹 보안을 설계할 때 더 이상 '봇 차단' 자체를 최종 목표로 삼아서는 안 됩니다. 대신 자신의 서비스에 유익한 자동화(예: 뉴스 요약 AI)와 해로운 자동화(예: 무단 데이터 크롤링)를 구분할 수 있는 세분화된 가시성을 확보해야 합니다. 이를 위해 클라이언트의 무결성을 증명할 수 있는 기술적 수단을 도입하고, 변화하는 웹 클라이언트의 특성에 맞춰 보안 정책을 지속적으로 업데이트하는 것이 중요합니다.

ODW #3: MCP 서버를 안전하게 활용해 개발 효율 높이기 (새 탭에서 열림)

LY Corporation은 Model Context Protocol(MCP)을 활용해 AI 어시스턴트와 사내외 도구를 표준화된 방식으로 연결함으로써 개발 프로세스의 효율성을 극대화하고 있습니다. 보안 리스크를 체계적으로 관리하는 동시에 워크숍을 통한 조직적 학습을 병행하여, 엔지니어들이 안전하게 AI 에이전트를 확장하고 업무 자동화를 실현할 수 있는 환경을 구축하고 있습니다. **MCP의 개념과 표준화의 이점** * MCP는 AI 어시스턴트와 외부 시스템 사이에서 '번역자' 역할을 수행하는 공통 통신 규격으로, 각 서비스마다 별도의 인터페이스를 구현해야 했던 번거로움을 해결합니다. * 도구 개발자가 MCP라는 단일 인터페이스만 구현하면, 이를 지원하는 다양한 AI 어시스턴트(Claude, Cline 등)에서 동일한 방식으로 기능을 호출할 수 있어 호환성과 확장성이 비약적으로 향상됩니다. **보안 리스크 관리와 사내 거버넌스 구축** * 외부 MCP 서버의 약 53%가 정적 API 키나 PAT에 의존하고 있다는 보안 취약점을 인지하고, OAuth 등 최신 인증 방식을 권장하며 철저한 보안 검증을 수행합니다. * 사내에서는 허용 목록(Allow-list) 제도를 운영하여 검증된 MCP 서버만 사용하도록 제한하며, 내부 업무 시스템 연동을 위해 사내 보안 요구사항을 충족하는 전용 MCP 서버를 직접 구축해 제공합니다. * 'Help LY MCP'와 같은 전용 지원 도구를 마련해 전 세계 그룹사 직원들이 복잡한 절차 없이 자사 조직에 AI를 적용할 수 있는지 검토할 수 있는 체계를 갖추었습니다. **AI 에이전트 기반의 실무 자동화 사례** * **Claude Code와 Jira 연동:** 워크숍 실습을 통해 Claude Code가 작업 내용을 요약하고 사내 그룹웨어 MCP를 통해 Jira 티켓을 자동으로 발행하는 과정을 구현하여 반복적인 관리 업무를 자동화했습니다. * **멀티 에이전트 코드 리뷰:** Claude 3.5 Sonnet이 코드의 문맥과 로직을 1차로 리뷰하면, Codex MCP를 통해 연결된 다른 모델(GPT-5 등)이 리뷰의 타당성을 검증하는 2단계 리뷰 프로세스를 구축하여 객관성을 높였습니다. **조직적 학습과 공유의 가치** * 기술 변화 속도가 매우 빠른 AI 분야에서는 개인의 학습에만 의존하지 않고, '워크숍'이라는 형식을 통해 조직 전체의 배경지식과 위험 인식을 동기화하는 것이 중요합니다. * '무엇이 가능한가', '어떤 함정이 있는가', '어떻게 활용해야 가치가 생기는가'라는 세 가지 관점을 팀 전체가 공유함으로써 실질적인 업무 개선으로 이어지는 추진력을 얻을 수 있습니다. AI 기술은 정답이 정해지지 않은 채 매우 빠르게 발전하고 있으므로, 완벽한 모범 사례를 기다리기보다 호기심을 바탕으로 작은 시도를 꾸준히 쌓아가는 자세가 중요합니다. MCP 서버와 같은 최신 프로토콜을 적극적으로 탐구하고 팀 내에 공유하는 문화를 조성하는 것이 다가오는 AI 시대의 핵심 경쟁력이 될 것입니다.

Steganography at scale: Embedding share URLs in Datadog widget screenshots (새 탭에서 열림)

Datadog은 사용자가 대시보드 위젯을 스크린샷으로 캡처할 때 유실되는 쿼리, 시간 범위 등의 컨텍스트를 보존하기 위해 픽셀 수준의 보이지 않는 워터마크 기술을 도입했습니다. 위젯의 테두리 픽셀에 미세한 색상 변화를 주어 메타데이터 키를 인코딩함으로써, 정적 이미지에서도 원본 데이터와 상호작용할 수 있는 기능을 구현했습니다. 이 시스템은 하루 10억 개 이상의 위젯 렌더링을 처리하면서도 사용자 경험에 영향을 주지 않는 성능과 투명성을 유지합니다. ### 스크린샷의 한계와 보이지 않는 워터마크의 필요성 - 대시보드 공유 링크는 실시간 데이터와 쿼리 정보를 포함하지만, 많은 사용자는 여전히 직관적이고 권한 문제에서 자유로운 스크린샷 공유를 선호합니다. - 일반적인 스크린샷은 이미지 픽셀 정보만 남기 때문에, 당시의 구체적인 타임프레임이나 기반 쿼리, 대시보드 상태와 같은 중요한 컨텍스트가 모두 사라집니다. - Datadog은 사용자 인터페이스를 해치지 않으면서도 스크린샷 내부에 보이지 않게 메타데이터를 심어, 이미지를 다시 Datadog이나 협업 도구(Slack 등)에 붙여넣었을 때 원본 위젯을 복구하고자 했습니다. ### 효율적인 데이터 관리를 위한 Redis 캐싱 전략 - 위젯 정의(Definition) 데이터는 평균 2kB로 이미지에 직접 모두 인코딩하기에는 너무 큽니다. - 이를 해결하기 위해 전체 위젯 정의는 Redis 캐시에 저장하고, 이를 식별할 수 있는 짧은 8바이트 고유 키(Snapshot ID)만 워터마크로 인코딩합니다. - 하루 10억 건 이상의 위젯 렌더링과 초당 35,000건의 피크 타임을 감안하여, 충돌 방지를 위해 조직 ID(Org ID)를 조합한 키 구조를 사용하며 데이터는 1시간 동안 유지됩니다. - 지연 시간을 최소화하기 위해 프론트엔드에서 낙관적(Optimistic)으로 ID를 생성하여 렌더링 즉시 워터마크를 적용합니다. ### 픽셀 단위의 RGB 인코딩 메커니즘 - 모든 위젯에 공통적으로 존재하는 1픽셀 두께의 테두리(Border)를 데이터 삽입 위치로 선정하여 시각적 일관성을 유지합니다. - 워터마크는 총 10개의 픽셀로 구성됩니다. 시작과 끝을 알리는 2개의 센티널(Sentinel) 픽셀과 그 사이의 8개 데이터 픽셀이 배치됩니다. - 각 데이터 픽셀은 1바이트(8비트)를 저장하며, RGB 채널에 비트를 분산(R: 3비트, G: 3비트, B: 2비트)하여 저장합니다. - 기본 색상에서 채널별로 아주 미세한 오프셋(최대 +7)만 조정하기 때문에 육안으로는 원본 테두리 색상과 구분이 불가능합니다. 이 기술은 대규모 트래픽 환경에서도 성능 저하 없이 정적 이미지에 생명력을 불어넣는 창의적인 엔지니어링 사례입니다. 협업 과정에서 스크린샷을 자주 활용하는 팀이라면, Datadog의 이러한 기능을 통해 이미지 너머의 원본 지표와 쿼리를 즉시 추적하여 문제 해결 속도를 높일 수 있습니다.

ReasoningBank: Enabling agents to learn from experience (새 탭에서 열림)

ReasoningBank는 에이전트가 배포된 이후에도 성공과 실패의 경험으로부터 일반화된 추론 전략을 추출하여 스스로 진화할 수 있게 돕는 새로운 메모리 프레임워크입니다. 기존 방식이 단순히 실행 기록을 저장하거나 성공 사례만 수집했던 것과 달리, ReasoningBank는 고차원의 전략적 통찰을 구조화하여 저장함으로써 에이전트의 성공률과 작업 효율성을 동시에 개선합니다. 이는 에이전트가 반복적인 실수를 방지하고 복잡한 환경에서 지속적으로 학습하는 '지속적 학습자(Continuous Learner)'로 거듭나게 하는 핵심 기술입니다. **전략적 통찰의 구조화와 추출** - ReasoningBank는 단순히 과거의 행동을 기록하는 것이 아니라, 제목(Title), 설명(Description), 내용(Content)으로 구성된 고차원의 구조화된 메모리 항목을 생성합니다. - '검색-추출-통합'의 연속적인 폐쇄 루프(Closed-loop)를 통해 작동하며, LLM-as-a-judge 기능을 활용해 에이전트의 궤적을 스스로 평가하고 통찰을 도출합니다. - 특히 실패한 경험에서 '반사실적 신호(Counterfactual signals)'를 분석하여, "무한 스크롤 함정에 빠지지 않기 위해 현재 페이지 식별자를 먼저 확인하라"와 같은 예방적 가드레일을 구축하는 데 탁월합니다. **메모리 기반 테스트 시간 확장(MaTTS)** - 추론 시점의 컴퓨팅 자원 확장(Test-time scaling)을 메모리와 결합하여 학습 신호를 극대화하는 MaTTS 기법을 도입했습니다. - **병렬 확장(Parallel scaling):** 동일한 쿼리에 대해 여러 경로를 생성하고 이를 상호 비교함으로써 더 견고한 전략을 합성하고 고품질의 메모리를 생성합니다. - **순차 확장(Sequential scaling):** 단일 작업 내에서 추론을 반복적으로 정제하며, 시행착오 과정에서 발생하는 중간 단계의 통찰을 메모리에 기록합니다. - 이 과정에서 고품질 메모리는 확산된 탐색을 유망한 전략으로 안내하고, 확장된 상호작용은 다시 메모리를 풍부하게 만드는 시너지 효과를 냅니다. **성능 향상 및 전략적 성숙도의 발현** - WebArena 및 SWE-Bench-Verified 벤치마크 평가 결과, 메모리가 없는 기본 모델 대비 성공률이 최대 8.3% 향상되었으며, 작업당 실행 단계는 평균 3단계 가량 단축되었습니다. - 에이전트가 축적된 지식을 바탕으로 점진적으로 발전하는 '전략적 성숙도'가 관찰되었습니다. 초기의 단순한 절차적 체크리스트가 시간이 흐름에 따라 복잡한 조건부 논리 구조를 가진 고급 메모리로 진화했습니다. - 실험 결과 ReasoningBank는 자기 평가 과정의 일부 노이즈에도 강건하게 작동하며, 확장(Scaling)과 결합했을 때 효율성이 더욱 극대화됨이 증명되었습니다. 단순히 성공한 워크플로우를 저장하는 것을 넘어, 실패로부터 배우고 추론 과정을 일반화하는 ReasoningBank의 접근법은 자율형 에이전트의 실용성을 높이는 강력한 도구입니다. 복잡한 소프트웨어 엔지니어링이나 동적인 웹 환경에서 작동하는 에이전트를 설계한다면, 실행 시간의 연산량을 메모리 업데이트로 전환하는 MaTTS 방식의 도입을 적극 고려해 볼 수 있습니다.

AI 리더들이 디자인 플레이북을 활용하는 방법 | Figma 블로그 (새 탭에서 열림)

해당 글은 디자인의 역할이 단순한 시각적 구현을 넘어 제품 전략과 비즈니스 전반으로 확장되면서 발생하는 변화와 그에 따른 실무자들의 어려움을 다루고 있습니다. 디자인의 위상이 높아진 만큼 디자이너에게 요구되는 역량이 다각화되었으며, 이러한 확장이 디자이너들에게는 오히려 압박과 피로감으로 다가오고 있다는 것이 핵심입니다. 결국 현재 디자인 업계가 겪는 혼란은 디자인이 제품의 핵심 경쟁력으로 자리 잡는 과정에서 발생하는 필연적인 성장통이라고 결론짓습니다. ### 디자인의 정의 변화와 전략적 위상 강화 * 디자인은 더 이상 제품 개발의 마지막 단계에서 '포장'하는 역할에 머물지 않고, 제품의 초기 기획과 전략 수립 단계부터 깊숙이 관여합니다. * 디자이너의 성과 지표가 단순히 '사용성'이나 '심미성'에 그치지 않고, 비즈니스 성과(KPI)와 수익 모델에 미치는 영향력으로 평가받기 시작했습니다. * 이러한 변화는 디자인이 기업 내에서 더 큰 의사결정권을 갖게 되었음을 의미하지만, 동시에 그 결과에 대한 책임도 막중해졌음을 뜻합니다. ### AI가 촉발한 제작 공정의 자동화와 판단의 중요성 * AI 기술의 발전으로 반복적인 UI 작업, 프로토타이핑, 레이아웃 생성 등 과거 디자이너의 많은 시간을 차지했던 '실행(Execution)' 영역이 자동화되고 있습니다. * 단순한 제작 능력을 넘어, 수많은 선택지 중 어떤 디자인이 사용자와 비즈니스에 최적인지를 결정하는 '안목'과 '판단력(Curation)'이 디자이너의 핵심 경쟁력이 되었습니다. * AI 도구를 능숙하게 다루면서도 기술이 대체할 수 없는 창의적 고유성을 유지해야 한다는 새로운 과제가 주어졌습니다. ### 다학제적 역량 요구에 따른 심리적 부담 * 현대의 디자이너는 디자인 툴뿐만 아니라 데이터 분석, 비즈니스 언어, 심지어는 엔지니어링 지식까지 갖춰야 하는 상황에 놓여 있습니다. * 개발자와의 원활한 소통을 위해 코드의 논리를 이해해야 하고, 기획자와 논의하기 위해 시장 논리를 파악해야 하는 등 업무의 경계가 모호해지면서 번아웃을 호소하는 사례가 늘고 있습니다. * 성장해야 할 영역이 너무 광범위해짐에 따라 발생하는 "과연 내가 잘하고 있는가"에 대한 실존적인 불안감이 디자이너들에게 큰 스트레스로 작용합니다. ### 협업의 복잡성 증가와 커뮤니케이션의 핵심화 * 디자인의 영향력이 커질수록 더 많은 유관 부서와의 협의가 필요하며, 이는 곧 회의 시간의 증가와 조율의 난이도 상승으로 이어집니다. * 자신의 디자인 결정을 논리적으로 설명하고 설득하는 '디자인 비평'과 '스토리텔링' 능력이 그 어느 때보다 중요해졌습니다. * 단순히 화면을 잘 그리는 사람보다 조직 내에서 디자인적 사고를 전파하고 타 직군과의 가교 역할을 하는 '퍼실리테이터'로서의 역할이 강조됩니다. --- **실용적인 결론** 디자이너들은 이제 도구(Tool) 숙련도에만 매몰되기보다 **비즈니스적 사고방식**을 기르고 **AI를 협업 파트너로 수용**하는 유연함을 갖춰야 합니다. 지금 느끼는 막막함은 디자인이 제품의 부수적인 요소가 아닌 **핵심 동력**으로 변모하고 있다는 증거입니다. 따라서 모든 역량을 완벽하게 갖추려 하기보다, 자신의 강점을 바탕으로 타 직군과 전략적으로 협력하는 법을 익히는 것이 지속 가능한 커리어 성장의 열쇠가 될 것입니다.

GitLab + Amazon: 신뢰할 수 있는 AI 기반의 플랫폼 오케스트레이션 (새 탭에서 열림)

GitLab Duo Agent Platform과 Amazon Bedrock의 결합은 기업이 보안과 규제 준수를 유지하면서 소프트웨어 개발 생애 전반에 에이전트 기반 AI를 도입할 수 있는 강력한 토대를 제공합니다. GitLab은 워크플로우 오케스트레이션 레이어 역할을 수행하고, Bedrock은 신뢰할 수 있는 모델 추론 인프라를 담당함으로써 파편화된 AI 도구 확산을 막고 클라우드 투자의 효율성을 극대화합니다. 이를 통해 개발팀은 데이터 주권을 유지하면서도 보안 스캐닝, 파이프라인 최적화 등 복잡한 개발 작업을 지능적으로 자동화할 수 있습니다. **기존 AI 도입의 구조적 문제점** * **운영 파편화:** 개별 팀이나 개발자가 승인되지 않은 AI 도구를 제각각 사용함에 따라 엔드 투 엔드 거버넌스 수립이 불가능해지는 현상이 발생합니다. * **보안 및 데이터 주권:** 프롬프트와 코드 데이터가 외부로 유출될 위험이 있으며, 로그 소유권 및 데이터 흐름에 대한 불확실성이 존재합니다. * **클라우드 지출 최적화:** 기존 AWS 사용 약정과는 별개로 개별 AI 도구에 비용이 지출되면서 기업의 클라우드 전략 및 비용 효율성이 저하됩니다. **GitLab Duo Agent Platform: 에이전트 기반 제어 평면** * **병렬적 자동화:** 전통적인 단계별 방식에서 벗어나, 여러 전문 에이전트가 이슈, 머지 리퀘스트(MR), 보안 취약점 등 프로젝트 컨텍스트를 공유하며 동시에 작업을 수행합니다. * **통합 오케스트레이션:** 단순한 채팅 보조 도구를 넘어, GitLab의 AI Gateway를 통해 Bedrock 모델을 호출하고 소프트웨어 수명 주기 전반의 워크플로우를 지휘합니다. * **맥락 중심 협업:** 이슈 데이터와 파이프라인 결과를 실시간으로 활용하여 AI 에이전트와 개발팀 간의 유기적인 협업 환경을 구축합니다. **Amazon Bedrock: 신뢰할 수 있는 AI 인프라** * **완벽한 데이터 격리:** 서버리스 기반의 완전 관리형 서비스로, 모든 데이터는 고객의 AWS 계정 내에 머물며 모델 학습에 절대 사용되지 않습니다. * **강력한 규제 준수:** GDPR, HIPAA, FedRAMP High 등 주요 보안 인증을 획득하여 규제가 엄격한 산업군에서도 즉시 도입이 가능합니다. * **안전 장치 제공:** 'Bedrock Guardrails' 기능을 통해 콘텐츠 필터링, 환각 현상(Hallucination) 감지, 민감 정보 보호 기능을 모델 전반에 적용할 수 있습니다. **환경에 따른 세 가지 배포 옵션** * **완전 제어형:** GitLab Self-Managed 사용자가 자신의 AWS 계정에서 직접 Bedrock 모델과 AI 게이트웨이를 호스팅하여 데이터 통제권을 극대화합니다. * **관리형 서비스 연동:** GitLab Self-Managed 사용자가 GitLab에서 호스팅하는 AI 게이트웨이와 Bedrock 인프라를 활용하여 운영 부담을 줄입니다. * **SaaS 통합형:** GitLab.com(SaaS) 사용자가 GitLab 관리형 AI 인프라를 통해 별도의 설정 없이 Bedrock 기반의 AI 기능을 활용합니다. 기존에 AWS 인프라를 활용하면서 보안과 거버넌스를 중시하는 기업이라면, GitLab Duo와 Amazon Bedrock의 통합은 섀도우 AI(Shadow AI)를 방지하고 기술 스택을 단일화할 수 있는 최적의 해결책입니다. 특히 보안 취약점 자동 수정이나 파이프라인 최적화와 같이 신뢰도가 중요한 영역에서 Bedrock의 보안 가드레일을 활용하여 안전하게 AI를 확장해 나갈 것을 추천합니다.

AWS Weekly Roundup: Claude Opus 4.7 in Amazon Bedrock, AWS Interconnect GA, and more (April 20, 2026) | Amazon Web Services (새 탭에서 열림)

AWS는 이번 발표를 통해 Anthropic의 가장 강력한 모델인 Claude Opus 4.7의 Amazon Bedrock 출시와 새로운 하이브리드 네트워킹 서비스인 AWS Interconnect의 정식 출시를 알렸습니다. AI 시대의 개발자는 도구에 대체되는 것이 아니라, 시스템 사고와 정교한 통신 역량을 바탕으로 더 높은 수준의 가치를 창출해야 한다는 비전을 제시합니다. 아울러 양자 내성 보안부터 고성능 컴퓨팅 인스턴스에 이르기까지 클라우드 전반의 성능과 보안을 강화하는 다채로운 업데이트가 포함되었습니다. **Claude Opus 4.7 및 Amazon Bedrock 고도화** * Anthropic의 최신 모델인 Claude Opus 4.7이 Bedrock에 출시되어 코딩, 장기 실행 에이전트, 전문 지식 업무에서 향상된 성능을 제공하며, 특히 SWE-bench Pro에서 64.3%의 높은 점수를 기록했습니다. * 요청의 복잡도에 따라 사고 토큰 예산을 동적으로 할당하는 '적응형 사고(Adaptive thinking)' 기능과 100만 토큰의 방대한 컨텍스트 윈도우를 지원합니다. * 고해상도 이미지 지원 기능이 추가되어 복잡한 차트, 밀집된 문서, 스크린 UI에 대한 분석 정확도가 크게 개선되었습니다. **멀티클라우드 및 라스트 마일 연결성 강화 (AWS Interconnect)** * 'AWS Interconnect - Multicloud'를 통해 AWS VPC와 타사 클라우드(Google Cloud 등) 간의 Layer 3 프라이빗 연결을 지원하며, 트래픽은 공용 인터넷을 거치지 않고 전용 백본망을 통해 전송됩니다. * 'AWS Interconnect - Last Mile'은 지사나 데이터 센터에서 AWS로의 고속 프라이빗 연결을 단순화하며, 최대 100Gbps 대역폭과 MACsec 암호화를 기본으로 제공합니다. * AWS는 관련 사양을 GitHub에 오픈 소스로 공개하여 다른 클라우드 제공업체들도 Interconnect 파트너가 될 수 있는 개방형 생태계를 구축했습니다. **개발 및 보안 운영의 자동화와 최적화** * **현대화 도구:** AI 에이전트 기반 마이그레이션 서비스인 'AWS Transform'이 VS Code 확장으로 제공되어, Java/Python 버전 업그레이드나 VB6 레거시 앱의 .NET Core 전환 작업을 IDE 내에서 직접 수행할 수 있습니다. * **보안 강화:** AWS Secrets Manager가 ML-KEM 기반의 하이브리드 양자 내성 TLS를 지원하기 시작하여 미래의 양자 컴퓨팅 위협으로부터 기밀 정보를 보호합니다. * **데이터 관리:** Amazon ECR의 풀스루 캐시가 OCI 참조(이미지 서명, SBOM 등) 동기화를 지원하여 컨테이너 보안 검증 워크플로우를 간소화했습니다. * **고성능 컴퓨팅:** 6세대 인텔 제온 프로세서 기반의 EC2 C8in/C8ib 인스턴스가 정식 출시되어, 이전 세대 대비 최대 43% 향상된 성능과 최대 600Gbps의 네트워크 대역폭을 제공합니다. **비용 관리 및 서버리스 고도화** * Amazon Bedrock에 IAM 주체별 세부 비용 속성 기능이 추가되어, 팀이나 프로젝트 단위로 AI 추론 비용을 정확하게 정산하고 관리할 수 있게 되었습니다. * Aurora DSQL은 PHP 전용 커넥터를 출시하여 IAM 토큰 생성, SSL 설정, 커넥션 풀링 등의 작업을 자동화함으로써 서버리스 데이터베이스 활용도를 높였습니다. 이번 업데이트는 AI 에이전트의 자율성을 극대화하고 멀티클라우드 환경의 네트워킹 장벽을 낮추는 데 중점을 두고 있습니다. 개발자들은 Claude Opus 4.7의 강화된 추론 능력과 AWS Transform 같은 자동화 도구를 적극 활용하여 레거시 시스템 현대화 속도를 높이고, 강화된 네트워킹 성능을 바탕으로 더 견고한 분산 시스템을 설계할 것을 권장합니다.

우리가 배포하는 플랫폼 위에 내부적으로 구축한 AI 엔지니어링 스택 (새 탭에서 열림)

Cloudflare는 자사 플랫폼의 기술력을 집약한 내부 AI 엔지니어링 스택을 구축하여 전체 R&D 인력의 93%가 AI 도구를 일상적으로 사용하는 환경을 조성했으며, 그 결과 주간 머지 리퀘스트(Merge Request) 수를 약 두 배 가까이 증가시키는 생산성 혁신을 이뤄냈습니다. 이들은 단순한 도구 도입을 넘어 MCP(Model Context Protocol), AI Gateway, Workers AI 등을 결합한 포괄적인 아키텍처를 통해 보안과 운영 효율성을 동시에 확보했습니다. 특히 이번 프로젝트는 실제 고객에게 제공되는 상용 제품들을 내부 워크플로우에 직접 적용하여 그 실효성을 검증했다는 점에서 중요한 기술적 이정표를 제시합니다. ### 통합 플랫폼 및 보안 계층 * **보안 및 인증 관리**: Cloudflare Access를 통한 제로 트러스트 인증으로 보안을 강화하고, 모든 LLM 요청을 AI Gateway로 라우팅하여 중앙 집중식 키 관리, 비용 추적 및 데이터 보존 정책을 적용합니다. * **Workers AI 활용**: 프론티어 모델(OpenAI, Anthropic 등)뿐만 아니라 Workers AI를 통해 Kimi K2.5와 같은 오픈 소스 모델을 병행 운용하며, 특히 보안 에이전트 등의 작업에서 상용 모델 대비 약 77%의 비용 절감 효과를 거두고 있습니다. * **프록시 워커 패턴**: 모든 클라이언트 요청을 단일 프록시 워커를 통해 처리함으로써 클라이언트 설정 변경 없이도 사용자별 권한 부여 및 모델 카탈로그 관리가 가능한 제어 평면(Control Plane)을 구축했습니다. ### 에이전트 기반 인프라와 MCP * **원스톱 온보딩**: `opencode auth login` 명령 하나로 MCP 서버, 에이전트, 명령 및 권한 설정을 자동으로 구성하여 엔지니어가 설정 파일에 손대지 않고도 즉시 AI 도구를 사용할 수 있게 했습니다. * **상태 유지 및 격리 실행**: Durable Objects 기반의 Agents SDK를 사용해 장기 실행되는 에이전트 세션을 관리하며, Sandbox SDK를 통해 에이전트가 생성한 코드를 안전한 격리 환경에서 빌드하고 테스트합니다. * **워크플로우 자동화**: 복잡한 다단계 엔지니어링 작업은 Workflows 기능을 통해 자동화하며, 이는 대규모 리포지토리 전반에 걸친 변경 사항 전파를 효율적으로 지원합니다. ### 지식 체계와 품질 관리 * **기술 지식 그래프**: 오픈소스인 Backstage를 활용해 16,000개 이상의 엔티티를 포함한 지식 그래프를 구축함으로써 에이전트가 조직 내 복잡한 시스템 구조를 정확히 이해할 수 있도록 지원합니다. * **AGENTS.md와 코드 리뷰**: 각 저장소의 컨텍스트를 담은 `AGENTS.md` 파일을 생성하여 에이전트의 정확도를 높이고, CI 파이프라인에 통합된 AI 코드 리뷰어를 통해 급증하는 코드 생산량 속에서도 품질을 유지합니다. Cloudflare의 사례는 AI 도입을 고민하는 기업들에게 '플랫폼 중심 접근법'의 중요성을 시사합니다. 단순한 챗봇 도입이 아니라, 중앙 집중식 게이트웨이를 통한 가시성 확보, 격리된 샌드박스 실행 환경 구축, 그리고 내부 지식 시스템(Backstage 등)과의 결합이 뒷받침될 때 비로소 실제적인 엔지니어링 생산성 향상을 기대할 수 있습니다.

대규모 AI 코드 리뷰 오케스트레이션 (새 탭에서 열림)

Cloudflare는 기존 AI 코드 리뷰 도구의 유연성 부족과 단순 요약 방식의 한계를 극복하기 위해 오픈소스 에이전트인 OpenCode 기반의 CI 네이티브 오케스트레이션 시스템을 구축했습니다. 이 시스템은 보안, 성능 등 각 분야에 특화된 다수의 전문 에이전트를 코디네이터가 관리하여 노이즈를 줄이고 정확도 높은 리뷰 결과를 제공합니다. 현재 수만 개의 머지 리퀘스트를 처리하며 실제 버그와 보안 취약점을 효과적으로 차단하는 등 엔지니어링 생산성을 획기적으로 개선하고 있습니다. **기존 접근 방식의 한계와 다중 에이전트 전략** * 단순히 Git Diff를 LLM에 입력하는 방식은 환각(Hallucination) 현상과 무의미한 수정 제안 등 노이즈가 많아 실질적인 코드 품질 향상에 한계가 있었음. * Cloudflare는 하나의 거대한 모델 대신 보안, 성능, 코드 품질, 문서화, 릴리스 관리, 내부 규정 준수 등 최대 7개의 전문 에이전트를 동시에 실행하는 구조를 선택함. * '코디네이터 에이전트'가 개별 에이전트의 발견 사항을 취합하여 중복을 제거하고, 문제의 실제 심각도를 판단한 뒤 하나의 구조화된 리뷰 코멘트로 통합함. **플러그인 기반의 유연한 아키텍처** * 다양한 버전 관리 시스템(VCS)과 AI 프로바이더를 지원하기 위해 `ReviewPlugin` 인터페이스 기반의 컴포저블 아키텍처를 채택함. * 리뷰 실행 주기는 세 단계로 나먐: 병렬로 실행되는 `Bootstrap`(비동기 준비), 순차적으로 실행되며 실패 시 중단되는 `Configure`(필수 설정), 그리고 원격 설정 로드 등을 처리하는 `postConfigure` 단계임. * `ConfigureContext` API를 통해 각 플러그인은 독립적으로 에이전트 등록, 프롬프트 주입, 환경 변수 설정을 수행하며, 최종적으로 `opencode.json` 설정 파일로 병합됨. * 이러한 격리 구조 덕분에 GitLab 플러그인이 AI Gateway 설정을 알 필요가 없는 등 컴포넌트 간 결합도를 최소화함. **OpenCode와 Bun을 활용한 기술적 구현** * OpenCode는 오픈소스이며 서버 중심 구조를 가지고 있어 프로그래밍 방식으로 세션을 생성하고 SDK를 통해 결과를 수집하기에 적합함. * 대규모 머지 리퀘스트 처리 시 발생하는 Linux 커널의 `ARG_MAX` 제한(E2BIG 에러)을 해결하기 위해, Bun의 `stdin` 스트림을 통해 대용량 프롬프트를 전달함. * 오케스트레이터는 OpenCode를 자식 프로세스(`Bun.spawn`)로 실행하며, 모든 출력은 JSONL 형식의 `stdout` 이벤트를 통해 실시간으로 모니터링 및 수집됨. Cloudflare의 사례는 단순한 AI 도입을 넘어, 대규모 조직의 복잡한 표준과 요구사항을 충족하기 위해 다중 에이전트와 플러그인 시스템이 왜 필요한지 잘 보여줍니다. 특히 CI/CD 파이프라인의 핵심 경로에 AI를 배치할 때 발생하는 인자 크기 제한이나 도구 간 결합도 문제를 해결한 아키텍처는 대규모 엔지니어링 팀에 실질적인 가이드라인이 될 것입니다.

Building the agentic cloud: everything we launched during Agents Week 2026 (새 탭에서 열림)

Cloudflare는 인공지능 에이전트가 주요 워크로드로 자리 잡는 미래를 위해 기존의 클라우드 구조를 재정의한 'Cloud 2.0(에이전트 클라우드)' 비전을 제시했습니다. 수천만 개의 에이전트 세션이 동시에 실행될 수 있도록 연산 인프라부터 보안, 도구 모음까지 스택 전반에 걸친 대대적인 신규 기능들을 공개했습니다. 이를 통해 개발자들은 단순한 프로토타입을 넘어 확장성과 보안을 갖춘 에이전트 기반 애플리케이션을 생산 환경에서 구현할 수 있게 되었습니다. **에이전트 전용 연산 환경 및 워크플로우** * **Git 호환 저장소 'Artifacts':** 에이전트가 생성한 코드와 데이터를 관리하기 위해 수천만 개의 레포지토리를 생성할 수 있고, 표준 Git 클라이언트와 연동되는 버전 관리 저장소를 제공합니다. * **격리된 실행 환경 'Sandboxes' (GA):** 에이전트에게 셸, 파일 시스템, 백그라운드 프로세스를 갖춘 독립된 컴퓨터 환경을 제공하며, 작업 중단 지점부터 즉시 재개할 수 있는 영속성을 보장합니다. * **상태 저장 및 확장성:** 'Durable Object Facets'를 통해 에이전트가 생성한 앱마다 독립된 SQLite 데이터베이스를 할당하며, 개선된 워크플로우 엔진으로 최대 50,000개의 동시 실행을 지원합니다. **에이전트를 위한 보안 및 ID 관리** * **Cloudflare Mesh:** 에이전트가 프라이빗 네트워크 내의 데이터베이스나 API에 안전하게 접근할 수 있도록 제로 트러스트 기반의 비공개 네트워크 연결을 지원합니다. * **Managed OAuth:** 에이전트가 보안상 취약한 서비스 계정 대신, 사용자를 대행해 내부 애플리케이션에 안전하게 인증하고 탐색할 수 있는 체계를 구축했습니다. * **비인간 식별자(Non-human Identity) 보호:** 에이전트용 API 토큰의 권한 범위를 세밀하게 제어하고 자동 취소 기능을 도입하여 자격 증명 유출에 따른 리스크를 최소화했습니다. **에이전트의 사고와 소통을 돕는 툴박스** * **다중 채널 소통 지원:** 실시간 음성 상호작용(STT/TTS) 기능을 약 30줄의 코드로 구현할 수 있게 되었으며, 이메일을 직접 송수신하고 처리할 수 있는 'Cloudflare Email Service' 베타를 출시했습니다. * **추론 성능 및 효율 최적화:** LLM의 품질 저하 없이 모델 크기를 22% 압축하는 'Unweight' 기술을 도입하여 더 빠르고 경제적인 추론 인프라를 구축했습니다. * **통합 추론 및 기억:** 14개 이상의 모델 공급자를 연결하는 통합 추론 레이어와 함께, 에이전트가 과거의 맥락을 기억하고 지속적으로 학습할 수 있는 'Agent Memory' 서비스를 제공합니다. 이번 발표는 에이전트가 단순히 텍스트를 생성하는 도구를 넘어, 독립적인 실행 환경과 보안 권한을 가지고 업무를 수행하는 '실행 주체'로 거듭나도록 돕는 데 초점이 맞춰져 있습니다. 대규모 에이전트 시스템을 구축하려는 팀이라면 Cloudflare가 제공하는 Sandboxes와 Mesh 기반의 보안 아키텍처를 활용하여 인프라 구축 비용과 보안 리스크를 획기적으로 낮출 수 있을 것입니다.