OlmoEarth 임베딩 출시, Studio에서 고른 구역과 기간을 벡터로 꺼내는 이유

이번에 다룰 글은 AllenAI가 공개한 Introducing OlmoEarth embeddings: Custom embedding exports from OlmoEarth Studio for downstream analysis입니다. 이 글은 지구관측 데이터를 위한 OlmoEarth 파운데이션 모델이 만드는 전이 가능한 벡터 피처, 그리고 Studio에서 원하는 구역과 기간을 골라 임베딩으로 꺼내는 익스포트 기능을 소개합니다. 주장은 한 문장으로 정리되는데, 임베딩을 Studio 안에서만 보는 결과물이 아니라 바깥으로 꺼내 쓸 수 있는 형태로 만들면 분류와 클러스터링, 변화 탐지와 검색 같은 하류 분석이 GIS와 과학 파이썬 워크플로우 안에서 이어진다는 것입니다. 원문 링크는 제목 아래에 걸려 있습니다.

안녕하세요, 패트릭입니다. 저는 위성 데이터를 다루는 글을 읽을 때마다 비슷한 장면에서 멈칫합니다. 분석하고 싶은 지역은 매번 달라지는데 모델은 매번 처음부터 영상을 다시 읽어야 하니까요. 같은 해안선을 작년에 한 번 봤는데 올해 또 처음 보는 것처럼 처리한다면, 그건 어딘가 아쉽습니다. 그렇다면 한 번 읽은 내용을 벡터로 저장해두고 여러 분석에 다시 쓸 수는 없을까요? 오늘은 그 질문에서 출발한 OlmoEarth 임베딩 이야기를 처음부터 하나씩 풀어보겠습니다.

위성 사진을 매번 처음부터 읽어야 할까

위성 영상을 다뤄본 분들은 이 수고로움을 바로 아실 겁니다. 분석 지역이나 기간이 바뀌면 전처리부터 다시 시작해야 하는데, 구름을 가리고 좌표를 맞추고 밴드를 고르는 일이 매번 반복되기 때문이죠. 그래서 작년 홍수 때 만들었던 파이프라인이 있어도 올해 가뭄 분석에는 그대로 가져다 쓰기 어렵고, 옆 도시로 지역만 옮겨도 손이 꽤 많이 갑니다. 저는 이 반복을 단순한 귀찮음이 아니라 구조의 문제로 봅니다. 매 분석이 원시 픽셀에서 출발하다 보니, 이전 분석이 배운 지형의 질감이 다음 분석으로 이어지지 않기 때문입니다.

생각해보면 사람도 비슷하게 일하지 않습니다. 처음 가본 동네에서는 골목마다 헤매지만, 두 번째 방문부터는 지도가 머릿속에 남으니까요. 어떤 논밭이 물을 머금은 상태인지, 어떤 해안선이 계절마다 어떻게 바뀌는지 같은 감각이 쌓이면 다음 판단이 빨라집니다. 그렇다면 모델도 한 번 읽은 지구관측 데이터를 벡터라는 형태로 남겨두고 다음 분석에서 그 기록을 꺼내 쓸 수는 없을까요? 제가 이 글에서 가장 흥미롭게 본 부분은 바로 이 발상의 전환입니다. 영상을 그때그때 해석하는 소모품이 아니라 여러 번 다시 읽을 수 있는 중간 기록으로 바꾸겠다는 것이니까요.

물론 벡터로 남긴다고 모든 문제가 풀리지는 않습니다. 어떤 정보를 남기고 어떤 정보를 버릴지 정해야 하고, 남긴 벡터가 다른 지역과 다른 시기에도 통하는지 확인해야 하니까요. 그런데도 이 방향이 끌리는 이유는 분명합니다. 같은 지역을 여러 팀이 각자 처음부터 읽는 낭비를 줄일 수 있기 때문입니다. 저희가 새로운 AI 아키텍처를 볼 때도 모델 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 현장의 작업 흐름을 어떻게 바꾸는지를 함께 봅니다. 그런 눈으로 보면 OlmoEarth 임베딩은 점수 경쟁이 아니라 작업의 순서를 바꾸는 제안에 가깝습니다.

임베딩이라는 말이 이번 글에서는 무엇을 가리킬까

임베딩이라는 단어는 요즘 너무 자주 쓰이다 보니 읽는 사람마다 떠올리는 그림이 조금씩 다릅니다. 어떤 분은 언어 모델의 단어 벡터를 떠올리고, 다른 분은 검색용 벡터 데이터베이스를 떠올리죠. 그래서 이번 글의 정의를 먼저 분명히 해둘 필요가 있습니다. 여기서 임베딩은 OlmoEarth 파운데이션 모델이 지구관측 데이터에서 뽑아낸 전이 가능한 벡터 피처를 가리키는데, 영상 한 장을 통째로 저장하는 대신 그 장면의 성질을 담은 숫자 배열을 남긴다는 뜻입니다. 이 벡터는 원래 보던 장면보다 훨씬 작으면서도 다음 분석에 필요한 성질은 품고 있도록 만들어집니다.

여기서 전이 가능하다는 표현이 말하는 바를 짚고 넘어가야 합니다. 하나의 목적에만 묶인 벡터가 아니라 분류에도 쓰고 클러스터링에도 쓰고 변화 탐지나 검색에도 꺼내 쓸 수 있다는 뜻이기 때문입니다. 비유를 들어보면 요리할 때 미리 만들어두는 육수와 같죠. 육수 자체가 완성은 아니지만 국도 끓이고 찌개도 끓일 수 있듯이, 잘 만든 임베딩 하나가 여러 하류 분석의 출발점이 됩니다. 반면 특정 분류기에 종속된 피처는 일회용 양념에 가깝습니다. 그 요리에는 맞지만 다른 요리에는 쓰기 어렵습니다. 저는 이 차이가 이번 발표를 읽는 기준이라고 봅니다. 벡터의 크기보다 어떤 질문들에 다시 답할 수 있는지가 더 중요하니까요.

그렇다면 어떤 벡터가 좋은 육수가 될까요? 같은 논밭을 다른 계절에 봐도 논밭이라는 사실을 알아보고, 도시의 확장과 계절성 구름을 서로 다른 신호로 구분할 수 있어야 합니다. 다시 말하면 바뀌는 것과 바뀌지 않는 것을 벡터 공간 안에서 서로 다른 방향으로 갈라놓아야 합니다. 이게 말처럼 쉽지는 않습니다. 위성 영상은 센서도 다르고 해상도도 다르고 촬영 조건도 매번 달라지기 때문입니다. 그래서 임베딩의 품질은 모델이 얼마나 많은 변화를 겪어봤는지와 맞닿아 있습니다. 여러 지역과 시기를 본 파운데이션 모델일수록 처음 보는 지역의 낯섦을 덜 타게 되죠. 여기서부터는 자연스럽게 다음 질문이 이어집니다. 그렇게 만든 벡터를 사용자가 원하는 구역과 기간에 맞춰 꺼내는 과정은 어떻게 생겼을까요?

Studio에서 고른 구역과 기간이 파일로 나오는 순간

OlmoEarth Studio의 익스포트 기능은 말 그대로 사용자가 정한 구역과 기간에 대한 임베딩을 만들어주는 과정입니다. 지도 위에서 관심 지역을 고르고 분석하고 싶은 시기를 정하면, 그 조건에 맞는 피처가 파일 형태로 나옵니다. 이 설명은 겉으로 보면 단순하지만 실제로는 그렇지 않습니다. 구역 하나를 고른다는 말 안에는 좌표계의 선택과 해상도의 결정, 타일 나누기와 경계 처리가 따라오고, 기간 하나를 정한다는 말 안에는 어떤 촬영본을 쓰고 구름 낀 날은 어떻게 다룰지에 대한 판단이 들어 있기 때문입니다. 저는 그래서 이 익스포트를 단추 하나로 보지 않습니다. 여러 판단이 압축된 파이프라인의 출구로 보는 편이 더 정확하죠.

이 지점에서 실제 작업 장면을 하나 떠올려보겠습니다. 어느 연구팀이 6월부터 9월까지 특정 하천 유역의 변화를 보고 싶다고 합시다. 예전 방식이라면 그 기간의 영상을 일일이 모으고 전처리를 돌린 뒤에야 분석이 시작됐습니다. 하지만 임베딩 익스포트가 있다면 순서는 달라집니다. 먼저 원하는 구역과 기간을 정하고 벡터를 꺼낸 뒤, 그 벡터 위에서 분류나 변화 탐지를 바로 돌리기 때문입니다. 원시 영상을 매번 만지는 단계가 얇아지면서 분석자는 질문 자체에 시간을 더 쓸 수 있게 됩니다. 이 차이는 생각보다 중요하죠. 데이터 준비에 밀려 정작 궁금했던 질문을 못 던지는 일이 현장에서는 자주 일어나니까요.

다만 여기서 조심해서 읽을 필요가 있습니다. 구역과 기간을 고르는 자유가 곧바로 좋은 분석을 보장하지는 않기 때문입니다. 너무 좁게 자르면 맥락이 사라지고, 너무 넓게 잡으면 원치 않는 신호까지 들어옵니다. 기간을 잘못 잡으면 계절 변화와 실제 변화를 구분하기 어려워지기도 합니다. 그래서 익스포트는 편리한 도구인 동시에 사용자가 지리를 얼마나 이해하고 있는지를 묻는 도구가 됩니다. 어디를 언제 잘라낼지에 대한 판단은 여전히 사람의 몫으로 남습니다. 그렇다면 그렇게 꺼낸 벡터로는 바깥에서 실제로 어떤 일들을 할 수 있을까요?

꺼낸 벡터로 바깥에서 할 수 있는 네 가지 일

원문이 꼽는 하류 분석은 분류와 클러스터링, 변화 탐지와 검색입니다. 네 가지를 나열만 하면 평범해 보이지만 각각이 벡터를 쓰는 방식은 조금씩 다릅니다. 그래서 저는 이 대목을 벡터라는 공통 재료가 네 가지 다른 요리로 변하는 과정으로 읽었습니다. 분류는 벡터에 이름을 붙이는 일로, 이 픽셀이 논인지 밭인지, 이 지붕이 주거용인지 상업용인지 같은 라벨을 매기는 과정입니다. 임베딩이 잘 만들어졌다면 분류기는 원시 영상을 처음부터 배우지 않아도 됩니다. 이미 정리된 숫자 배열 위에서는 가벼운 모델로도 충분한 경우가 많기 때문입니다. 라벨이 부족한 현장에서는 이 가벼움이 특히 크게 다가옵니다.

클러스터링은 이름 붙이기 이전의 단계라고 할 수 있습니다. 정답 라벨 없이 비슷한 벡터끼리 모아보는 것인데, 지도 위에 뿌려진 수만 개의 벡터가 몇 개의 무리로 뭉치는지 보면 사람이 미처 나누지 않았던 토지 이용의 결이 드러나기도 합니다. 저는 이 용도가 생각보다 과소평가된다고 봅니다. 라벨이 없다는 이유로 분석을 미루는 대신, 벡터의 무리를 먼저 보고 어디에 라벨링 예산을 쓸지 정할 수 있죠. 한정된 현장 조사 예산을 어디에 투입할지 고르는 일에도 임베딩이 쓰이는 셈입니다.

변화 탐지는 시간 방향으로 벡터를 비교하는 일입니다. 같은 좌표의 작년 벡터와 올해 벡터가 얼마나 멀어졌는지를 재면 무엇이 바뀌었는지를 읽을 수 있습니다. 여기서 재미있는 질문이 생깁니다. 벡터 사이의 거리가 커졌다는 사실만으로 진짜 변화를 확신할 수 있을까요? 계절이 바뀌어도 벡터는 움직이고 센서가 바뀌어도 벡터는 흔들리기 때문입니다. 그래서 변화 탐지는 거리 하나만 보는 게 아니라 어떤 방향으로 얼마나 움직였는지를 함께 봐야 합니다. 계절성 움직임과 개발로 인한 움직임을 벡터 공간에서 서로 다른 결로 읽어내는 것입니다. 검색도 비슷한 맥락에 있습니다. 예시 패치를 하나 주면 비슷한 벡터를 가진 지역을 찾아주는데, 잘 되면 토지 이용 사례 찾기가 훨씬 빨라집니다. 그런데 비슷한 것의 기준을 누가 정하는지가 또 남습니다. 스펙트럼이 비슷하다는 건지, 질감이 비슷하다는 건지, 시간에 따른 변화 패턴이 비슷하다는 건지에 따라 결과가 달라지니까요. 이처럼 네 가지 작업은 같은 벡터를 쓰지만 묻는 질문이 다르고, 그래서 벡터의 어느 면을 믿을지도 달라집니다.

좌표가 빠지면 벡터는 그냥 숫자 더미가 된다

익스포트된 벡터를 바깥으로 가져나갈 때 가장 먼저 챙겨야 할 것은 지리참조와 메타데이터입니다. 벡터 자체는 좌표가 없는 숫자 배열이라 어느 위치의 어느 시기를 담은 것인지 알려면 별도의 정보가 반드시 따라붙어야 하기 때문입니다. 이 말이 당연하게 들릴 수도 있습니다. 하지만 현장에서는 바로 이 당연한 것이 자주 어긋납니다. 좌표계가 하나만 있는 게 아니고 타일을 나누는 방식도 도구마다 다르며, 시간 표기 역시 촬영 시각인지 합성 기간인지에 따라 갈리기 때문입니다. 그래서 익스포트에는 벡터와 함께 읽을 것을 읽고 모를 것은 모른다고 말해주는 표식이 필요합니다. 이 픽셀이 어느 좌표계의 어느 셀인지, 어떤 기간과 어떤 모델 버전에서 나왔는지를 파일이 스스로 설명해야 합니다.

GIS와 과학 파이썬 워크플로우와의 정렬이 여기서 중요해집니다. 벡터를 꺼낸 뒤에는 보통 지리정보 도구나 파이썬 데이터 스택에서 이어서 분석하는데, 이때 좌표가 어긋나면 분석 전체가 조용히 틀어지기 때문입니다. 눈에 띄게 오류가 나는 게 아니라 몇 픽셀씩 밀리면서 결과가 살짝 어긋나는 식이라 더 무섭습니다. 홍수 경계처럼 몇 미터가 중요한 주제에서는 작은 어긋남이 큰 오해가 되죠. 저는 그래서 메타데이터를 부속품이 아니라 벡터의 반쪽으로 봅니다. 벡터가 무엇을 봤는지를 담는다면, 메타데이터는 어디를 언제 어떤 조건에서 봤는지를 담고 있죠. 반쪽이 빠진 기록은 다음 사람이 다시 쓰기 어렵습니다.

여기서 실무적인 장면을 하나 더 그려보겠습니다. 아침에 익스포트한 벡터를 오후에 다른 팀원이 이어받는다고 합시다. 파일 이름만 보고는 그 벡터가 어느 구역의 어느 달을 담은 것인지 알기 어렵습니다. 그런데 좌표와 기간, 해상도와 모델 버전이 파일 안에 구조화된 형태로 들어 있다면 이야기가 달라집니다. 받는 쪽은 문서를 뒤지지 않고도 코드를 그대로 돌릴 수 있고, 몇 달 뒤에 같은 실험을 반복할 때도 조건을 복원할 수 있습니다. 밤사이 위성 촬영본이 추가되거나 타일 경계가 바뀌어도 분석 라인이 멈추지 않으려면 이런 자기 설명적인 파일이 필요하죠. 운영 측면에서 보면 이 차이는 상당히 큽니다. 결국 임베딩 익스포트의 품질은 벡터의 정교함만으로 정해지지 않습니다. 벡터와 함께 가는 정보가 얼마나 성실한지도 같은 비중으로 봐야 합니다. 그렇다면 시간이 흘러 모델 자체가 바뀌면, 예전에 꺼낸 벡터는 어떻게 되는 걸까요?

모델이 바뀌면 예전 벡터는 어떻게 믿어야 할까

파운데이션 모델은 업데이트됩니다. 더 많은 데이터를 보고 구조가 다듬어지고 학습 방식이 바뀌면서, 같은 영상을 넣어도 나오는 벡터가 달라집니다. 이 당연한 사실을 짚는 이유는 임베딩을 파일로 꺼내두는 순간부터는 시간이 벡터의 적이 되기 때문입니다. 작년에 꺼낸 벡터와 올해 꺼낸 벡터가 다른 모델 버전에서 나왔다면 두 벡터를 같은 공간에 놓고 비교할 수 없습니다. 숫자 배열의 모양은 같아 보여도 그 숫자들이 가리키는 방향의 의미가 달라졌기 때문입니다. 저는 이 지점을 임베딩 워크플로우에서 가장 과소평가되는 부분으로 봅니다. 벡터를 꺼내는 순간의 편리함 뒤에 버전이 바뀌었을 때의 비용이 숨어 있으니까요.

그래서 버전 관리와 재현성이 중요해집니다. 어떤 모델의 어떤 릴리스에서 벡터가 나왔는지를 기록하고, 필요하면 예전 버전으로 다시 꺼낼 수 있어야 합니다. 실험 노트에 모델 이름만 적어두는 수준으로는 부족합니다. 체크포인트의 식별자와 전처리 조건, 익스포트 설정까지 함께 묶여야 같은 벡터를 다시 만들 수 있습니다. 이 말을 들으면 번거롭게 느껴질 수도 있습니다. 하지만 반대로 생각해보면 이 기록이 없으면 예전 분석을 아무도 다시 확인할 수 없습니다. 논문의 그림 하나, 보고서의 숫자 하나가 어느 벡터에서 나왔는지 모른다면 그 결과는 다시 증명할 수 없는 이야기가 됩니다. 과학의 문법으로 보면 꽤 심각한 일입니다.

여기서는 조금 다른 각도의 질문도 던져볼 수 있습니다. 모델이 좋아졌다고 무조건 벡터를 다시 뽑아야 할까요? 새로 뽑으면 품질은 올라가겠지만 지금까지 쌓아둔 벡터 자산과 하류 모델을 전부 갈아엎어야 합니다. 반면 예전 벡터를 유지하면 당장의 파이프라인은 안정적이지만 새 모델의 개선을 누리지 못합니다. 이 선택에는 정답이 없습니다. 다만 선택의 비용을 미리 계산해둘 수는 있습니다. 벡터를 다시 뽑는 데 드는 계산 비용, 하류 모델을 다시 학습시키는 비용, 과거 결과와의 연속성이 깨질 때의 설명 비용 같은 것들입니다. 저는 그래서 버전 정책을 기술 문서의 부록이 아니라 설계의 일부로 봐야 한다고 봅니다. 어떤 주기로 모델을 올리고, 구버전 벡터를 얼마나 오래 지원하고, 버전이 바뀔 때 하류 모델을 어떻게 옮겨갈지를 처음부터 정해두어야 하죠. 이 약속이 있어야 임베딩을 오래 쓰는 팀도 안심하고 쌓아둘 수 있습니다. 그런데 쌓아둔다는 말, 그 자체가 다음 고민을 부릅니다. 촘촘한 벡터를 대량으로 쌓는 일은 얼마나 무거울까요?

촘촘한 벡터를 쌓아두는 일은 생각보다 무겁다

임베딩은 원시 영상보다 작다는 설명을 자주 듣습니다. 맞는 말이기도 합니다. 수백 개 밴드의 픽셀을 수백 차원의 벡터로 압축하면 용량이 줄어드는 경우가 많으니까요. 그런데 지역이 넓어지고 기간이 길어지면 이야기가 달라집니다. 좁은 구역에서는 가벼웠던 벡터가 대륙 규모로 쌓이면 저장소가 금방 차고, 매달 새로 뽑아야 하는 벡터가 밀리면 계산 비용도 만만치 않게 불어납니다. 저는 이 대목을 읽으면서 임베딩이 압축의 끝이 아니라 저장과 계산의 새로운 시작이라는 생각을 했습니다. 영상 읽기의 부담을 벡터 관리의 부담으로 옮겨온 셈이니까요.

정규화 문제도 여기서 함께 따라옵니다. 벡터를 꺼낸 뒤 분류기나 클러스터링에 넣으려면 값의 범위를 맞춰주는 과정이 필요한데, 이 기준을 어떻게 잡느냐에 따라 결과가 달라지기 때문입니다. 전체 지역의 통계로 맞출지, 작은 타일마다 따로 맞출지, 시기를 합쳐서 맞출지 나눠서 맞출지가 모두 다른 답을 만듭니다. 예를 들어 사막과 습지를 같은 기준으로 정규화하면 한쪽의 미묘한 차이가 묻힐 수 있고, 반대로 타일마다 따로 맞추면 타일 경계에서 인위적인 단절이 생길 수 있습니다. 어떤 선택이 맞는지는 묻는 질문에 따라 달라집니다. 넓은 지역의 경향을 보고 싶을 때와 작은 습지의 미묘한 변화를 보고 싶을 때의 답이 다를 수밖에 없기 때문입니다. 그래서 정규화는 전처리 잡일이 아니라 분석의 일부입니다. 기준을 어떻게 잡았는지를 기록하지 않으면 같은 벡터로 다른 그림을 그리고도 왜 다른지 설명할 수 없게 됩니다.

하류 모델의 계산 부담도 빼놓을 수 없습니다. 벡터 위에서 도는 가벼운 모델이라 해도 벡터의 양이 많아지면 학습과 추론의 비용이 따라 올라갑니다. 특히 검색처럼 벡터끼리 거리를 재는 작업은 데이터가 늘어날수록 계산량이 빠르게 불어납니다. 이때는 근사 검색 같은 기법으로 속도를 벌지만, 근사라는 말 그대로 정확도와 맞바꾸는 선택이 됩니다. 어디까지 근사해도 되는지는 서비스의 성격에 따라 달라집니다. 연구용 탐색과 실시간 모니터링의 허용 오차가 다를 수밖에 없기 때문입니다. 결국 규모가 커질수록 임베딩 파이프라인은 저장 형식과 압축 방식, 배치 크기와 캐싱 전략 같은 시스템 문제와 한 몸이 됩니다. 벡터의 수학적 성질만 보고 설계하면 운영에서 반드시 어딘가 막힙니다. 실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 이렇게 쌓은 벡터로 내린 분석을, 우리는 어떻게 믿을 수 있을까요?

정답이 없을 때 분석을 어떻게 믿을까

위성 분석의 어려운 점은 정답 라벨이 부족하다는 것입니다. 관심 있는 모든 지역에 현장 조사가 따라갈 수 없고, 변화가 일어나는 속도가 라벨을 만드는 속도보다 빠르기도 합니다. 그래서 임베딩 기반 분석의 검증은 늘 불완전한 조건에서 이뤄집니다. 분류 정확도를 재고 싶어도 믿을 만한 정답이 적고, 변화 탐지를 평가하고 싶어도 언제 무엇이 바뀌었는지를 적은 기록이 충분치 않습니다. 이 조건에서는 숫자를 하나 내놓는 것보다 그 숫자가 어떤 조건에서 나왔는지를 함께 말하는 게 더 정직합니다. 저는 그래서 검증이라는 말을 정확도 하나의 문제가 아니라 신뢰를 쌓는 과정으로 읽습니다.

그렇다면 라벨이 부족할 때 무엇을 할 수 있을까요? 먼저 할 수 있는 일은 작은 정답으로 크게 묻는 것입니다. 현장 조사가 가능한 몇 개 지점의 라벨로 모델을 점검하고, 그 결과를 비슷한 벡터 무리에 조심스럽게 확장하는 것입니다. 이때 클러스터링이 다시 유용해집니다. 벡터의 무리를 먼저 보고 각 무리에서 몇 개씩만 확인하면 적은 라벨로도 전체의 윤곽을 잡을 수 있기 때문입니다. 참고로 이 방식은 현장 예산이 한정된 팀일수록 잘 맞습니다. 전부 조사할 수 없을 때 어디를 골라 확인할지를 벡터가 알려주기 때문입니다. 다음으로 할 수 있는 일은 시간 방향의 일관성을 보는 것입니다. 말이 안 되는 깜빡임이 자주 나타난다면 모델이 진짜 변화를 본 게 아니라 노이즈에 흔들린 것일 수 있습니다. 계절의 리듬과 맞는 변화인지, 어느 날 갑자기 튀는 이상치인지를 구분하는 것만으로도 검증의 절반은 됩니다.

여기서는 조심해야 할 함정도 있습니다. 눈으로 보기에 그럴듯한 지도를 검증과 혼동하는 것입니다. 색이 예쁘게 나뉘고 경계가 매끈하면 맞는 것처럼 느껴지지만, 그럴듯함은 정확도가 아닙니다. 특히 클러스터링 결과는 어떻게 색을 입히느냐에 따라 인상이 크게 달라지는데, 이 인상에 취하면 라벨이 부족하다는 사실을 잊게 됩니다. 저는 이 대목에서 분석자의 태도가 중요하다고 봅니다. 벡터가 보여주는 그림을 일단 의심하고, 작은 정답과 시간의 일관성과 현장의 상식이라는 세 가지 끈으로 붙잡아두어야 합니다. 그렇다면 이런 검증의 어려움을 알면서도 임베딩을 쓰는 이유는 무엇일까요? 라벨이 적을수록 오히려 한 번 만든 벡터를 여러 각도에서 두드려보는 전략이 필요하기 때문입니다. 같은 벡터를 분류로도 보고 클러스터로도 보고 시간 차이로도 보면서, 서로 다른 각도의 답이 같은 곳을 가리키는지를 확인합니다. 하나의 숫자가 아니라 여러 질문의 일치가 신뢰를 만듭니다.

한 줄로 줄이면 놓치는 것들

임베딩 이야기를 한 줄로 줄이면 대개 이렇게 됩니다. 위성 영상을 벡터로 바꿔 여러 분석에 재사용한다는 것입니다. 틀린 말은 아닙니다. 그런데 이 요약에는 빠진 것이 너무 많습니다. 어떤 모델이 어떤 데이터를 보고 벡터를 만들었는지, 구역과 기간을 어떻게 잘라서 꺼냈는지, 좌표와 메타데이터가 어떻게 붙었는지, 버전이 바뀌면 어떻게 이어갈지, 규모가 커질 때 저장과 계산을 어떻게 감당할지가 모두 생략되기 때문입니다. 요약은 편리하지만 생략된 부분에 바로 실패의 자리가 있습니다. 저는 그래서 한 줄 요약을 의심합니다. 이해를 돕는 대신 이해했다고 착각하게 만들기 때문입니다.

비슷한 오해는 다른 방향에서도 생깁니다. 임베딩을 꺼냈다는 사실을 분석이 끝났다는 뜻으로 읽는 것입니다. 벡터는 재료이지 요리가 아닙니다. 재료를 꺼냈다고 저녁이 완성된 게 아니듯이, 벡터를 뽑았다고 변화 탐지가 끝난 게 아닙니다. 분류기의 선택과 정규화의 기준, 검증의 설계가 남아 있고 그 선택들이 결과를 좌우합니다. 또 하나 흔한 오해는 벡터가 원시 영상을 완전히 대체한다는 생각입니다. 어떤 질문에는 벡터만으로 충분하지만 어떤 질문에는 원시 영상으로 돌아가야 합니다. 미묘한 스펙트럼 차이가 문제될 때나 센서의 이상치를 의심할 때는 벡터의 압축 뒤에 숨은 정보를 다시 펼쳐봐야 합니다. 벡터가 편하다고 원본을 버리면 가장 확인이 필요한 순간에 돌아갈 곳이 없어집니다.

표면적으로 보면 임베딩 익스포트는 파일 내보내기 기능처럼 보입니다. 실제로는 그렇지 않습니다. 구역과 기간을 정하는 판단, 좌표와 메타데이터를 붙이는 성실함, 버전을 기록하는 습관, 규모에 맞는 시스템 설계, 라벨이 부족한 조건에서의 검증까지가 한 묶음으로 따라오기 때문입니다. 이 묶음을 통째로 이해할 때만 임베딩은 진짜로 쓸모가 있습니다. 그렇다면 이 흐름은 어디로 이어질까요? 그 이야기는 마지막에 다시 다루겠습니다.

제가 다음에 보고 싶은 장면은 이것이다

앞에서 미뤄뒀던 질문으로 돌아올 차례입니다. 임베딩을 꺼내 쓰는 흐름은 앞으로 어디로 이어질까요? 제가 먼저 보고 싶은 것은 현장의 반복 실험입니다. 서로 다른 지역의 팀들이 같은 방식으로 벡터를 꺼내 자기 문제에 붙였을 때, 어떤 작업에서는 잘 맞고 어떤 작업에서는 어긋나는지를 솔직하게 모으는 것입니다. 분류에서는 라벨이 얼마나 절약됐는지, 변화 탐지에서는 계절성과 실제 변화를 얼마나 갈라냈는지, 검색에서는 현장 조사 전에 후보를 얼마나 좁혀줬는지 같은 기록이 쌓이면 다음 팀의 선택이 훨씬 쉬워집니다. 숫자의 자랑이 아니라 실패의 기록까지 포함한 운영 노트가 모이는 장면을 보고 싶습니다.

다음으로 보고 싶은 것은 버전이 바뀌는 순간의 매너입니다. 새 모델이 나왔다고 기존 벡터를 하루아침에 무효로 만들지 않고, 구버전과 신버전을 이어주는 안내가 함께 나오는 것입니다. 어느 작업은 새 벡터로 옮기면 이득이 크고 어느 작업은 그대로 두어도 된다는 식의 구체적인 이사가이드 말입니다. 이 안내가 있어야 현장 팀도 안심하고 임베딩을 쌓아둘 수 있습니다. 쌓아둔 것이 내일 휴지가 된다면 아무도 쌓지 않으니까요. 그리고 마지막으로 보고 싶은 것은 라벨이 부족한 지역에서의 검증법을 나누는 흐름입니다. 작은 정답을 어떻게 골랐는지, 시간의 일관성을 어떻게 잣대로 썼는지, 현장의 상식과 어떻게 맞춰봤는지를 서로 공유하는 것입니다. 검증의 정답지가 없을 때일수록 검증의 과정을 나누는 것이 모두의 정확도를 올립니다.

이 글을 길게 따라오셨다면 마지막으로 한 가지만 남기겠습니다. 임베딩 익스포트는 위성 분석의 순서를 바꾸는 제안입니다. 원시 영상에서 매번 출발하는 대신 한 번 읽은 기록을 벡터로 남겨 여러 질문에 다시 꺼내 쓰는 순서입니다. 이 순서가 정착하면 분석자의 시간은 데이터 준비에서 질문 자체로 옮겨갑니다. 어디가 언제 어떻게 바뀌었는지, 그 변화를 어떻게 믿을 수 있는지 같은 질문 말입니다. 그렇다면 여러분의 다음 질문은 무엇일까요. 지도 위에서 오래 마음에 걸렸던 그 구역과 그 기간을, 벡터로 꺼내 처음 물어보고 싶은 것이 무엇인지 저는 궁금합니다.