오늘 고른 셋은 DB 벤치마크, 추천 시스템, 로봇 메모리로 분야가 다릅니다. 그런데 한 질문으로 꿰입니다: 다 담을 수 없을 때, 무엇을 남기고 무엇을 버리나. 그럼의 편집 기준이 ‘규모 = 난이도’를 말하는 자리가 여기입니다 — 숫자 한 줄도, 컨텍스트 전부도 함정입니다. 각 항목은 ‘한 줄 판단’부터 던지고 근거를 풉니다.

오늘의 핵심

1. PostgresBench — ClickHouse가 차린 ‘관리형 Postgres’ 벤치마크

• 한 줄 판단: 벤더가 자기 제품이 1등인 벤치마크를 내면, 숫자보다 방법론(워크로드·인스턴스·스토리지)부터 읽으세요.
• 사실: ClickHouse가 pgbench의 TPC-B류 워크로드(짧고 동시적인 쓰기 트랜잭션)로 관리형 Postgres 5종 — ClickHouse·AWS Aurora·RDS·Neon·Crunchy Bridge — 을 비교한 오픈 벤치마크입니다. 약 100GB에서 ClickHouse Postgres가 28,668 TPS·8.9ms, 약 500GB에서 26,328 TPS로 Aurora의 10,402 TPS를 앞섰다고 합니다. 우위 원인은 컴퓨트와 같은 자리에 둔 NVMe 대 네트워크 스토리지. 파라미터·코드는 공개 GitHub로 재현 가능하게 뒀습니다. (⚠️ ClickHouse 자사 블로그의 자사 제품 우위 벤치마크라는 점을 감안해 읽어야 합니다.)
• 태리의 해설: 그럼의 편집 기준은 ‘돈·물리가 걸리면 작은 실수도 용납 안 됨’을 무관용 항목으로 둡니다. 정산처럼 돈이 오가는 시스템에 DB를 고를 땐 남의 숫자를 그대로 믿지 않는 게 이 기준의 출발점이죠. 컴퓨트 옆 NVMe가 네트워크 스토리지를 이긴다는 결론 자체는 새롭지 않습니다 — 로컬 디스크와 원격 스토리지의 지연 격차는 공개된 시스템 벤치마크가 오래 반복해 보여준 패턴입니다. 진짜 봐야 할 건 워크로드입니다: TPC-B는 짧은 쓰기 트랜잭션에 편향돼 있어, 읽기 위주거나 분석성 쿼리가 섞인 시스템과는 닮지 않았을 수 있습니다. 재현 가능한 벤치마크를 공개한 건 칭찬할 일이지만, 칭찬과 채택은 다른 문제입니다.
• 이번 주 할 일: TPS 헤드라인 말고 방법론 표(인스턴스 등급·스토리지·동시성·데이터 규모)부터 확인하고, 가능하면 내 실제 쿼리 패턴으로 한 번 돌려보세요.

2. G2Rec — 생성형 추천을 그래프 + 시맨틱 토큰화로 산업 규모에 올린다

• 한 줄 판단: 생성형 추천은 “지켜볼” 단계에서 “운영 설계할” 단계로 넘어가는 중 — 단, 그래프와 토큰화의 서빙 비용부터 두들겨 보세요.
• 사실: G2Rec(arXiv, 2026-06)은 그래프 기반 사용자 공동참여(co-engagement) 모델링과 아이템 시맨틱 토큰화를 하나의 프레임워크로 묶어 산업 규모 생성형 추천에 적용한 연구입니다. 기존 방식이 확장성에 막히거나 국소 정보만 잡던 문제를, 전역 그래프 + 의미 토큰을 통합해 풀었다고 주장하며, 여러 제품 표면에 온라인 배포 + 공개 데이터셋 실험으로 우위를 보였다고 합니다. (⚠️ 초록에 구체 수치는 없습니다.)
• 태리의 해설: 그럼의 편집 기준으로 보면 비용은 평균이 아니라 동시성에서 터집니다 — 대용량 트래픽 분산이 어려운 이유가 늘 거기 있었습니다. 추천을 “검색”이 아니라 “생성”으로 푸는 흐름은 분명 방향성이 맞아 보이지만, 그래프 순회 + 토큰 생성은 요청당 연산을 올립니다. 최근 다룬 추론 비용 냅킨 계산을 추천 트래픽에 그대로 곱해 보면, 오프라인 지표가 좋아도 서빙 단가에서 막히는 지점이 보일 겁니다.
• 이번 주 할 일: 생성형 추천 PoC를 검토 중이라면 nDCG 같은 오프라인 지표보다 피크 동접 × 추천당 토큰·지연을 먼저 추산하세요.

3. MemoryWAM — 로봇의 ‘기억’을 전부냐 최근이냐 이분법에서 꺼낸다

• 한 줄 판단: 에이전트든 로봇이든 메모리는 “전부 넣기 vs 최근 것만”의 양자택일이 아닙니다 — 요약(gist) 계층이 정답에 가깝습니다.
• 사실: MemoryWAM(arXiv cs.RO)은 로봇 조작용 world action model의 메모리 트레이드오프를 정조준합니다. 최근 관측만 쓰면 비(非)마르코프 환경에서 실패하고, 긴 이력을 다 보존하면 연산·메모리가 폭발하죠. 해법은 하이브리드 — 최근 프레임 + 이벤트 경계 앵커 프레임 + 장기 이력을 압축한 gist 토큰 을 맞춤 어텐션으로 함께 검색합니다. 장기 의존 조작 태스크에서 VLA·WAM 베이스라인을 능가하면서 연산 효율도 양호했다고 합니다(시뮬레이션·실제 환경). (⚠️ 초록에 구체 수치는 없습니다.)
• 태리의 해설: 그럼의 편집 기준에서 ‘느슨한 결합 = 안정성’이 작동하는 자리입니다. 물리 세계는 상태가 끝없이 쌓이는데, 다 들고 다닐 수는 없습니다. 공개된 분산 시스템의 역사가 보여준 해법은 한결같았습니다 — 실시간 상태는 Pub/Sub로 흘려보내고, 이벤트는 메시지 큐로 떼어내 무엇을 이벤트 경계로 잡고 무엇을 요약으로 접을지를 먼저 정하는 것. MemoryWAM의 gist 토큰도 같은 데자뷰입니다. 멀티 AI를 제품에 넣을 때도 세션·산출물을 통째로 끌고 다니지 않고 요약·체크포인트로 관리하는 게 안정적이죠 — 무한 컨텍스트가 아니라 계층화된 기억이 답입니다.
• 이번 주 할 일: 에이전트나 로봇의 메모리를 다룬다면 “전부 vs 최근” 이분법을 버리고, 최근 창 + 이벤트 앵커 + 요약 세 계층으로 나눠보세요. 같은 ‘무엇을 남기고 무엇을 버리나’ 질문을 다른 소식으로 풀어 본 글은 다른 데일리 트렌드에서 이어집니다.

그래서, 무엇이 바뀌나

셋을 관통하는 한 가지 — 규모가 커질수록 엔지니어링은 ‘무엇을 남기고 무엇을 버리나’의 문제로 수렴합니다. 벤더 벤치마크는 어떤 워크로드를 대표로 남길지, 생성형 추천은 어떤 신호를 토큰으로 남길지, 로봇 메모리는 어떤 프레임을 기억으로 남길지를 고릅니다. 그럼의 편집 기준이 ‘규모 = 난이도’를 말하는 이유가 이것입니다 — 공개된 기술사가 반복해 보여준 패턴은 분명합니다: 다 담을 수 있을 땐 누구나 짭니다. 다 담을 수 없을 때 무엇을 버릴지 정하는 것 — 그게 늘 진짜 일이었고, 도구가 Postgres든 LLM이든 로봇이든 그 일만은 사라지지 않습니다.

참고 / 출처

• PostgresBench: A Reproducible Benchmark for Postgres Services — ClickHouse Blog (자사 벤치마크, 감안해 읽기)
• Structuring and Tokenizing Distributed User Interest Context for Generative Recommendation (G2Rec) — arXiv (2026-06)
• MemoryWAM: Efficient World Action Modeling with Persistent Memory — arXiv cs.RO (2026-06)