데일리 트렌드
· 약 4분 읽기
[데일리 트렌드] Databricks LTAP·AI 코딩 에이전트 추론예산·로봇 추론 런타임 — 오늘의 개발·AI 소식 3가지
오늘은 셋입니다 — 데이터베이스를 저장 포맷 층에서 다시 가르는 Databricks의 LTAP, 코딩 에이전트의 신뢰도를 도구가 아니라 추론에서 산다는 관측 연구, 그리고 로봇 AI를 하드웨어에서 떼어내는 이식형 추론 런타임. 성격은 달라 보여도 묶이는 한 가지가 있어요: 무엇을 떼어내면 무엇이 자유로워지는가. 각 항목은 ‘한 줄 판단’부터 던집니다.
오늘의 핵심
1. Databricks LTAP — Postgres 데이터를 Parquet로 저장해 트랜잭션과 분석을 한 벌로
- 한 줄 판단: 트랜잭션과 분석을 엔진이 아니라 저장 포맷 층에서 통합한다는 게 핵심입니다. OLTP/OLAP를 갈라 두 번 복사하던 오래된 구도를 “한 벌의 Parquet 복사본을 둘이 나눠 쓰는” 쪽으로 되감았어요.
- 사실: Databricks가 LTAP(Lake Transactional/Analytical Processing)를 공개했습니다(Reynold Xin). Postgres의 WAL을 SafeKeeper(Paxos 복제)로 외부화하고, 데이터는 PageServer가 객체 스토리지에 Parquet 컬럼 포맷으로 materialize합니다. Postgres는 데이터를 소유하지 않는 stateless compute가 되어 탄력 확장·유휴 시 scale-to-zero가 됩니다. 이 한 벌의 복사본을 트랜잭션(Postgres)과 분석(Lakehouse 엔진)이 함께 조회합니다. 쓰기 처리량 5배·읽기 지연 2배 개선을 주장하나 ⚠️ 벤더 자체 수치이고, 아직 “향후 수개월 롤아웃” 단계입니다.
- 이번 주 할 일: Aurora·Neon류 분리형 Postgres나 별도 OLAP 파이프라인을 운영 중이라면 SafeKeeper/PageServer 분해 모델을 한 번 읽어 두시길 권합니다. 단, 아직 롤아웃 전이라 도입 검토가 아니라 아키텍처 참고로 두는 편이 균형이 맞습니다 — 지금 옮기면 벤더 락인과 미성숙 리스크를 같이 지는 셈이라.
2. “도구보다 추론예산” — 코딩 에이전트 첫 시도 신뢰도의 관측 연구
- 한 줄 판단: 에이전트 신뢰도를 도구를 더 붙여 사려던 통념에 제동을 겁니다. 90회 관측에서 추론 예산을 High→xHigh로 올리자 첫 시도 완벽 통과가 28%에서 89%로 뛴 반면, 테스트 도구는 비용만 42~68% 늘리고 기능 점수는 그대로였어요.
- 사실: arXiv 관측 연구(Achint Mehta). 실시간 회고 보드 앱을 만드는 90개 독립 에이전트 런을 14개 기준 루브릭으로 평가했습니다. 추론 강도 상향은 교정 프롬프트를 약 5배 줄이면서 비용은 9
29%만 더했고, 디자인 중심 프롬프트는 시각 품질(3.0→4.5)만 올리고 기능은 바꾸지 못했습니다. 프런티어 모델은 천장 근처에 몰렸고 저가 로컬 모델은 42점 만점에 2437점. ⚠️ 단일 저자·단일 과제·N=90 관측연구라 인과가 아니며 일반화엔 한계가 있습니다. - 이번 주 할 일: 에이전트 파이프라인에 “도구를 더 붙일까”를 고민 중이라면, 그 전에 추론 예산(effort) 한 단계를 올려 같은 과제를 재보시길 권합니다. 단, 상위 예산은 토큰 비용·지연을 함께 키우니 첫 시도 성공률이 재작업 비용을 상쇄하는 과제(반복·야간 배치)에 먼저 대보는 편이 낫습니다.
3. Embodied.cpp — 로봇 AI를 하드웨어에서 떼어내는 이식형 추론 런타임
- 한 줄 판단: 로봇 AI를 모델별 파이썬 구현에서 떼어내 한 런타임으로 이식하려는 시도입니다. LLM 서빙이 request-response를 가정하는 것과 달리, 제어 루프 안의 다중 레이트·배치1·지연 우선을 정면으로 다룬다는 점이 다르죠.
- 사실: arXiv 원 논문이자 오픈소스입니다(Ling Xu 외, 7월 2일 제출). C++ 추론 런타임을 입력 어댑터·시퀀스 빌더·백본 실행·헤드 플러그인·배포 어댑터 5계층으로 모듈화해 이기종 하드웨어 배포를 통일합니다. VLA(비전-언어-행동) 모델에서 과제 성공률 100%·91%, 월드-액션 모델의 블록 메모리를 312.2→88.1 MiB로 줄였다고 보고합니다.
- 이번 주 할 일: ROS 2 노드에 모델을 태워 이기종 보드로 옮겨 본 적이 있다면, 5계층 분해가 지금 파이썬 배포 스택의 어디를 대체할 수 있는지 GitHub에서 살펴보시길 권합니다. 단, 아직 신생 프로젝트라 프로덕션 투입이 아니라 이식성 실험 범위로 재보는 편이 안전합니다 — 신생 런타임은 성능보다 엣지 케이스에서 발목을 잡히기 쉽거든요.
그래서, 무엇이 바뀌나
셋을 관통하는 흐름은 분리는 복잡도를 없애지 않고 옮긴다입니다. 스토리지에서 컴퓨트를 떼면(1) SafeKeeper·PageServer라는 새 조정 계층이 생기고, 신뢰도를 도구가 아니라 추론에서 사면(2) 비용·지연이라는 다른 축으로 관리가 옮겨가며, 모델을 하드웨어에서 떼면(3) 런타임 추상층을 누군가 떠안습니다. 그럼의 편집 기준(느슨한 결합 = 안정성)은 이 이동을 지지하지만 조건이 있어요 — 옮겨간 복잡도가 독립적으로 확장·교체·이식되는 자유도로 되갚아질 때만 남는 장사입니다. 새 ‘분리’를 볼 때마다 “무엇이 어디로 옮겨갔나”를 먼저 세어 보면, 과대광고와 진짜 구조 개선이 갈립니다. (어제의 ‘경계 설계’가 무엇을 못 건드리게 할지였다면, 오늘은 무엇을 떼어내 자유롭게 둘지입니다. 데일리 트렌드를 고르는 기준도 같은 렌즈에서 출발합니다.)