기술 블로그

한 줄 요약 — 클라우드플레어(Cloudflare)가 발표한 계정 남용 방지(Account Abuse Protection)는 봇 차단을 넘어 일회용 이메일 탐지와 해시된 사용자 ID를 통해 인간과 봇이 결합된 복합적인 사기 공격을 원천 차단합니다. 이 주제를 꺼낸 이유 웹 서비스 운영 시 가장 골치 아픈 지점은 단순한 봇(Bot)의 공격이 아닙니다. 봇처럼 보이지 않으려는 정교한 인간의 의도와 자동화 도구가 결합된 계정 남용(Account Abuse) 문제입니다. 실제로 서비스를 운영하다 보면 신규 가입자의 절반 이상이 프로모션 혜택만 챙기고 사라지는 가짜 계정이거나, 유출된 계정 정보를 이용해 초당 수천 번의 로그인을 시도하는 상황을 마주하게 됩니다. 기존의 IP 기반 차단은 공격자가 주거용 프록시(Residential Proxy)를 사용해 IP를 계속 바꾸면 대응하기 어렵다는 한계가 명확했습니다. ...

한 줄 요약 — Amazon S3는 20년 동안 API 하위 호환성을 유지하며 단순 저장소에서 AI와 데이터 분석을 위한 통합 플랫폼으로 진화했습니다. 이 주제를 꺼낸 이유 현대적인 클라우드 기반 애플리케이션을 개발하면서 Amazon S3(Simple Storage Service)를 거치지 않기란 불가능에 가깝습니다. 정적 웹 사이트 호스팅부터 대규모 데이터 레이크 구축, 그리고 최근의 생성형 AI를 위한 데이터셋 관리까지 S3는 언제나 그 중심에 있었습니다. 최근 S3 출시 20주년을 맞아 공개된 기술적 회고와 향후 비전은 단순한 기념사를 넘어섭니다. 20년 전 작성한 코드가 수정 없이 여전히 작동한다는 사실은 변동성이 심한 테크 업계에서 경이로운 수준의 신뢰를 보여줍니다. 특히 S3 Tables나 S3 Vectors 같은 신규 기능은 객체 스토리지가 앞으로 어떤 방향으로 확장될지 명확한 힌트를 줍니다. ...

한 줄 요약 — Amazon S3 일반 용도 버킷(General Purpose Buckets) 생성 시 계정 ID와 리전 정보가 포함된 고유 접미사를 붙여, 전역 네임스페이스 중복 문제 없이 버킷 이름을 자유롭게 선점할 수 있게 되었습니다. 이 주제를 꺼낸 이유 AWS를 사용하면서 가장 먼저 마주하는 난관 중 하나가 Amazon S3 버킷 이름을 정하는 일입니다. S3는 서비스 초기부터 전역 네임스페이스(Global Namespace)를 사용해 왔기에, 내가 원하는 이름이 이미 전 세계 누군가에 의해 사용 중이라면 해당 이름을 쓸 수 없었습니다. test-bucket이나 my-data 같은 평범한 이름은 고사하고, 회사 프로젝트 이름을 포함한 조합조차 중복 오류를 뱉어내기 일쑤였습니다. ...

한 줄 요약 — AI 에이전트가 데이터에 접근하고 상호작용하는 방식을 표준화하는 MCP, A2A, UCP 등 6가지 핵심 프로토콜의 작동 원리와 실무 적용 방안을 정리했습니다. 이 주제를 꺼낸 이유 최근 기술 블로그나 커뮤니티를 보면 MCP, A2A, UCP 같은 낯선 약어들이 쏟아지고 있습니다. 단순히 새로운 라이브러리가 나온 수준이 아니라, 에이전트가 외부 세계와 소통하는 규약 자체가 변하고 있다는 신호입니다. 지금까지는 에이전트를 만들 때마다 특정 서비스의 API 명세서를 읽고 전용 도구(Tool)를 일일이 개발해야 했습니다. 서비스가 10개면 10개의 커스텀 통합 코드를 짜고 유지보수해야 하는 셈인데, 이는 확장성 측면에서 큰 걸림돌이 됩니다. ...

에어비앤비(Airbnb)가 최근 발표한 기술 블로그를 읽으면서 깊은 공감을 느꼈습니다. 14년 넘게 자바와 코틀린 기반의 백엔드 시스템을 운영하며 가장 골머리를 앓았던 지점이 바로 옵저버빌리티(Observability)였기 때문입니다. 처음에는 간단히 외부 벤더사의 솔루션을 도입해 해결하려 하지만, 서비스 규모가 커지면 결국 비용과 데이터 파편화라는 거대한 벽에 부딪히게 됩니다. 에어비앤비는 이 문제를 해결하기 위해 뱅가드(Vanguard)라는 자체 플랫폼을 구축하며 주도권을 되찾아왔습니다. 왜 에어비앤비는 잘 쓰던 외부 솔루션을 버렸을까? 대부분의 스타트업이나 중견 기업은 데이터독(Datadog)이나 뉴렐릭(New Relic) 같은 서비스형 소프트웨어(SaaS) 솔루션으로 옵저버빌리티를 시작합니다. 저 역시 과거 여러 프로젝트에서 이런 도구들을 적극적으로 활용했습니다. 설치가 쉽고 UI가 미려하며 초기에는 관리 부담이 거의 없기 때문입니다. 하지만 에어비앤비가 지적했듯, 기업이 성숙해질수록 벤더사의 비즈니스 모델과 기업의 기술적 요구사항은 서로 다른 방향으로 흐르기 마련입니다. ...

에어비앤비(Airbnb)가 목적지를 정하지 못한 탐색형 사용자를 위해 머신러닝 기반의 여행지 추천 시스템을 어떻게 구축하고 최적화했는지 그 과정과 실무적 통찰을 공유합니다. 한 줄 요약 — 구체적인 계획 없이 여행을 탐색하는 사용자의 모호한 의도를 파악하여, 개인화된 여행지 후보를 제안하고 예약 전환율을 높이는 추천 모델링 전략입니다. 이 주제를 꺼낸 이유 대부분의 커머스나 예약 플랫폼은 사용자가 무엇을 원하는지 명확히 알고 있다는 가정하에 검색 결과를 보여줍니다. 파리에 가고 싶은 사람에게 파리의 숙소를 보여주는 것은 기술적으로 명확한 문제입니다. 하지만 현실에서 많은 사용자는 “어디로든 떠나고 싶다” 혹은 “유럽 어딘가로 가고 싶다"와 같은 막연한 상태로 탐색을 시작합니다. ...

한 줄 요약 — 슬랙은 알림 피로도를 줄이기 위해 복잡한 레거시 설정을 단순화하고, 알림의 대상(What)과 전달 방식(How)을 완전히 분리하는 아키텍처 재설계를 단행했습니다. 알림 시스템이 사용자 신뢰를 무너뜨리는 방식 알림은 서비스와 사용자를 잇는 가장 강력한 고리이지만, 제대로 관리되지 않으면 가장 먼저 차단당하는 요소가 됩니다. 슬랙(Slack) 정도의 규모에서 알림 시스템은 단순히 메시지를 보내는 기능을 넘어 사용자의 집중력을 관리하는 핵심 도구입니다. 하지만 오랜 시간 기능이 덧붙여지면서 슬랙의 알림 로직은 거대한 미로처럼 변해버렸습니다. 현업에서 복잡한 시스템을 다루다 보면 기능 추가보다 어려운 것이 기존 로직의 단순화라는 점을 체감합니다. 슬랙 엔지니어링 팀이 마주했던 문제는 단순히 알림이 많이 온다는 것이 아니었습니다. 사용자가 알림 설정을 변경해도 결과가 어떻게 나타날지 예측할 수 없다는 불확실성이 본질적인 문제였습니다. 데스크톱과 모바일의 설정 모델이 서로 달랐고, 특정 설정을 끄면 의도치 않게 다른 기능까지 마비되는 결합도가 높은 구조였습니다. ...

플랫폼 엔지니어링(Platform Engineering)은 단순히 최신 도구를 도입하는 기술적 여정이 아니라, 조직의 소통 구조와 아키텍처를 일치시켜 나가는 고도의 조직 설계 과정입니다. 한 줄 요약 — 성공적인 플랫폼 팀은 기술적 도구 구축에 매몰되지 않고, 콘웨이의 법칙을 활용해 조직의 복잡성을 관리하고 개발자의 인지 부하를 줄이는 데 집중합니다. 이 주제를 꺼낸 이유 많은 조직이 개발 속도를 높이기 위해 플랫폼 팀을 신설하지만, 정작 현장에서는 플랫폼이 오히려 무겁고 복잡하다는 불만이 터져 나오곤 합니다. 플랫폼이 조직의 효율을 높이는 지렛대가 아니라, 단순히 인프라 티켓을 처리하는 또 다른 병목 구간으로 전락하는 상황을 자주 목격합니다. ...

한 줄 요약 — 핀터레스트는 모델 컨텍스트 프로토콜(MCP)을 활용해 파편화된 AI 도구 생태계를 표준화하고, 단순 질의응답을 넘어 엔지니어링 업무를 자동화하는 에이전트 인프라를 구축했다. 이 주제를 꺼낸 이유 대규모 언어 모델(LLM)을 사내 데이터나 도구와 연결하려는 시도는 많지만, 매번 새로운 모델이 나올 때마다 혹은 새로운 내부 API를 붙일 때마다 개별적인 연동 코드를 짜는 것은 매우 비효율적입니다. 핀터레스트(Pinterest)가 선택한 모델 컨텍스트 프로토콜(Model Context Protocol, MCP)은 이러한 병목을 해결할 수 있는 강력한 대안으로 떠오르고 있습니다. ...

광고 랭킹 모델처럼 거대하고 복잡한 머신러닝(ML) 시스템을 운영하다 보면, 엔지니어의 시간 중 상당 부분이 실험 가설 수립, 학습 작업(Training Job) 모니터링, 로그 분석, 그리고 인프라 장애 대응에 소모된다는 것을 알 수 있습니다. 메타(Meta)가 공개한 랭킹 엔지니어 에이전트(Ranking Engineer Agent, 이하 REA)는 이러한 반복적인 ML 실험 사이클을 자율적으로 수행하여 엔지니어링 생산성을 5배 이상 끌어올린 사례를 보여줍니다. 단순히 코드를 짜주는 보조 도구를 넘어, 며칠에서 몇 주씩 걸리는 긴 호흡의 실험 과정을 스스로 관리하는 자율형 에이전트의 구조와 실무적 시사점을 정리했습니다. ...