프론티어 생태계는 열려 있어야 한다

생각 덩어리

모델이 상품화된 뒤 남는 해자 — 컨텍스트가 곧 우위, 프로덕션은 systems problem

Data is no longer something you keep track of and analyze ad hoc, it’s the necessary context agents need in order to act.

If frontier model performance becomes commoditized, the durable advantage then becomes the company-specific context around them : proprietary data, governed access, operational state, transaction logs, workflows, and feedback loops.

Fundamentally it appears that significantly better model performance in production is a systems problem , one that data guys like us are remarkably well prepared to solve!

Omnigent, 수렴한 두 갈래 — 코딩 에이전트와 커스텀 에이전트는 같은 문제

There were a couple of, like, converging lines, which I think is a good sign that you need something new.

Plus the agent is, like, completely useless if you can’t share sessions with someone and have history and have search and all this, like, layer on top of it for collaboration.

at first people thought it was weird. They’re like, “Why are you doing coding agents and custom agents in the same thing?” But I said it’s, it’s the same problems and, you just wanna build the stuff that lets you deliver the agent, maybe control it if you care about security, and, make it portable across things.

랩톱을 열어둔 채 살던 시절 — "Have you heard of cloud?"

from the moment I woke up to, like, the moment I went to bed, I was, like, looking at my Claude sessions, my Codex sessions. And one of the things that was particularly annoying was having to keep my laptop open.

Like honestly, I was driving and I was tethering my laptop to my phone.

Have you heard of cloud?

모든 하네스 위의 공용 API — 세션·메시지·스트림·툴콜·취소

the core of this is this common API on top of all the harnesses. So the API is like, you’ve got an agent session, and you can send in a message or, like, a file. That’s what you can send in, and then you get out, these streams as it’s streaming text or as it’s doing tool calls. And, or the other thing you can send in is you can, like, tell it to cancel a turn.

whenever cloud changes its API, you gotta, tweak your thing or it’s gonna lose some messages. So that’s the thing that’s valuable to maintain.

Vibe coding 시대에도 설계하고, 굳이 오픈하는 이유 — 프로토콜과 네트워크 효과

you might ask like today since we can vibe code anything so fast, why do we even need to design like protocols or APIs or software? Why can’t you just vibe code things on demand? But for this type of interoperability where multiple parties that are moving at different speeds are building stuff and you still want some layer on top to coordinate, you do wanna design it and build it.

One, so one of the reasons to open source something is if you think it’s a layer that will there’ll be some network effect, it’ll benefit from many, people collaborating, on it.

imagine, we our thing wasn’t open. We had some agent hosting thing, but it’s not open and then there is an open one. if you’re. Which one’s gonna win in the long run?

공개 이틀, 400 머지 — 절반은 외부 기여

400 merge already?

I would guess around half are not from our team.

We also have more agent harnesses already. Cursor, CLI, and Antigravity also.

스케일 — 하루 50~60M 가상머신, 아침 전에 엑사바이트

Maybe 50 or 60 million virtual machines a day across all three clouds, so we’re one of the biggest compute orchestrators out there.

I joked about depending on which time zone you are, typically before you have breakfast, Databricks would have processed exabytes of data already on that day.

보안의 긴장 — yes/no로는 못 지킨다, 상태 기반 contextual 정책

for security, there’s this tension between, like, usability and security.

the thing we decided we need is stateful or what we call contextual policies where you keep track of the state of that session. It’s not like is it allowed to push to the marketing site or not, but, like, hey, if it did a risky thing, like it installed, a old package from npm, or it read, like, 1,000 confidential docs, then no.

Should my agent be able to publish stuff to the company website? Well, if I’m using it to code on the website, yes. But should it be able to do both, so it can, like grab a confidential document and be prompt injected and leak it? Probably not.

Spend control과 편집증 — $500를 $5로 묶되, 안전하면서 성가시지 않게

I ask an agent to debug something, and it spent $500 because it decided to read a lot of log files and burn a lot of tokens. but I can literally say, “Okay, launch a agent to do this and cap it to spending $5.” Like, ask me for permission if it needs more.

so I’m especially paranoid. But also I have very little time, so I don’t want to sit there approving, like, do you want to run a 20-line, bash script, yes or no? so that’s why I spend a lot of time figuring out, like, how can I make it as safe as possible and not annoying?

스타트업 기회 — 코딩 에이전트의 management plane

you should add this skill, or you should write this thing, or your agents are really horrible at tasks involving this service, so I go spend time.

They started with, like, we will just do, code and human attribution, but they’re building the analytics layer on top of that.

CDC = continuous data corruption — 새벽 3시에 깨는 데이터 엔지니어

we joke that it’s, should be called continuous data corruption, because you might change your schema on your OLTP database, and then the CDC pipeline fails to handle...

I think many data engineers ends up being waken up at, like, 3:00 a.m, because there’s some pipeline thing.

It’s one of the most boring but one of the most fundamental operations, like, powering modern society.

HTAP의 성배와 LTAP — 쿼리 엔진이 아니라 스토리지만 통합

This is the holy grail of database engineering is why not build a single system that can do both of this? But it ends up just being a lot of compromises.

our whole idea of LTAP, it’s obviously a wordplay on the term HTAP, is that we think this is HTAP done right. HTAP wants to build a single engine for both. We think you can get 99% of what you need by unifying the storage, and just have a single storage layer.

once you have the single storage layer, if your Postgres databases are writing data in a column-oriented format, everything analytics can just go read that data directly without any delay, right? There’s no pipeline in between, so all the data will immediately be available for reasoning analytics.

Lakebase가 에이전트에 주는 것 — telemetry가 아니라 실시간 운영 데이터

But then there’s no way for those agents to even understand what’s going on in the actual databases themselves. All we see is just, like, product telemetry of the database and the services.

It would make those agents 10 times more powerful if understand, for example, who’s placing those orders, what is happening, what exactly are they doing. So now I’m sold on our own message.

"그냥 프로토타입 해봤는데 됩니다" — 설계 문서 없이 결판난 전략 결정

one day, one of our engineers who’s, like, super smart came in, he’s like, “Hey, I just prototyped it. It works.”

he just made the observation that, hey, our storage fleet has a lot of extra idle CPUs And we could use those CPUs to do the transcoding from row to column, where row is good for OLTP, but column is good for analytics.

I expect there to be, like, a kickoff thing, like a design doc. Nothing like that.

빠른 프로토타이핑 문화 — "고객이 누구냐", 몇 주 만에

instead of building, boil the ocean for everything, let’s figure out how do we do it incrementally, how do we do it very quickly.

usually my first question to whoever team is building is who’s the target customer? Who are you working with? Are you on a first-name basis with them? Are you texting with them?

한두 고객에 과적합하라 — overfit의 하방은 작다

I think the industry has a sense of, hey, maybe if you overfit to, like, one or two customers, it’s gonna be really bad for you. But I think the, downside of overfitting is much smaller than the upside itself. And if you try to be too ambitious and boil the ocean, it’s a much bigger problem.

‘Cause you might end up having no customer.

Dream engine — 10년이면 거대한 똥덩어리, second system syndrome

every single database engine out there, especially on the analytics side, are a decade old. pretty much everything that have reasonable traction are about a decade old. And they all started targeting some very specific narrow use cases, and then over time it’s become more and more successful.

after 10 years of organic evolution that way, it becomes a gigantic pile of shit.

It’s you built your first thing and it works out great, and the second one’s bound to fail because you become too ambitious.

Thank God it’s not their second system. Many of them have built more than two in the past.

엔진을 짓는 공장 — 수천조 트레이스로 알고리즘을 고른다

they went build a more of a factory for building the database. So they spent more time building this factory, and the factory takes the decade of traces we have. I think they count as like quadrillion data points in the trace table.

Machine learning model it can very quickly tell us how any algorithm and how any implementation would perform for any specific type of queries with very high fidelity. And based on that, they can, pick the most likely algorithm and data structure that will help with the different kinds of workloads.

Vector database는 애초에 별도 카테고리가 아니었어야

Vector database should have never been a separate category.

Agents are very eloquent in Postgres or Spark SQL. It’s never gonna get confused.

Snowflake와의 분기 — open과 AI, "start open, then optimize"

But the biggest difference, one is, open. Like Databricks had never had the proprietary format, right? We started with the open ecosystem started with Parquet and then evolved into Delta and Iceberg and all that.

start open and start large. Like, in some sense, we started upstream of them.

if your company’s existed for, like, thirty years, you’ve experienced, being locked into Oracle and, like, all kinds of, like, crazy things. And if you’re the CTO there and you’re setting up the architecture for the future for your company, you’re gonna wanna pick a foundation that’s open.

Mosaic 이후의 모델 전략 — 프론티어 대신 특화 모델, 문서 파싱 100X 저렴

instead of doing the general model where, like, a big part of the recipe is just throw in a lot of compute and just scale, we wanna focus on, like, the next step also of, let’s say you have the very smart model, how do you make it, useful?

our team, built this, document, vision model that takes a page and gives you back a nice JSON with all the components, and it’s very competitive. It’s like- Probably like 100X cheaper than those, frontier models and still better.

RL 파인튜닝의 대중화 — 스스로 환경을 만들어 학습하고 Opus를 이긴다

customizing models is gonna get way easier over time. That’s what we’re finding, ‘cause the base models are smarter, so they generate better traces in RL already, and then RL is about learning from your own past traces.

we have pipelines just using open source models, like the same model generates training environments and trains itself and beats like Opus and GPT 5.5 and stuff at a task.

데이터를 제자리에 두고 에이전트를 얹으면 — 소프트웨어의 재작성

What’s the theory of like, I guess tokens as IP, building up the context? He said everything but data is the new oil or context is the new oil.

I think many of the traditional software will be rewritten, with this new paradigm, which is just get the data to be there, and then just slap some agent on top.

Magic will come out.

but without the right data, you can’t really do that.