[슈퍼브 인사이트] 모든 지표가 정상인데, 비용은 계속 새고 있었다니!⛲️(신뢰 엔지니어의 등장)

🌟 SUPERB Spotlight

데이터 담당자의 일이 '전달하는 것'에서 '보증하는 것'으로 바뀌고 있습니다

본 글은 Medium의 'Data Engineers Are No Longer Just Moving Data. They Are Becoming Trust Engineers.'를 편집한 것으로, 전체 내용은 원글을 참고해 주세요.

예전의 일: "제때 옮겼고, 정확한가"

한때 데이터 엔지니어링의 역할 정의는 꽤 명확했습니다. 데이터를 유실 또는 손상시키지 않고, 필요한 곳으로 제때 전달하는 것이었죠. 파이프라인을 만들고, 데이터 웨어하우스(분석용 데이터를 모아두는 중앙 저장소)를 설계하고, 최신성·완전성 같은 데이터 품질 기준(SLA)을 지키면 됐습니다. 성공의 기준도 단순했는데요. '데이터가 도착했는가, 그리고 정확한가'만 보면 됐습니다.

실패 역시 곧바로 티가 났습니다. 작업이 멈추거나, 테이블 갱신이 늦거나, 행 개수가 이상한 이슈들이 생기면 파이프라인을 고치면 그만이었죠. 무엇보다 최종 판단을 내리는 사람이 중간에서 데이터를 보고 몇 시간~며칠 뒤에 판단을 내렸습니다. 그래서 데이터에 사소한 오류가 있어도, "어, 좀 이상한데?" 하고 걸러낼 수 있었죠. 데이터가 완벽하지 않아도 '이 정도면 충분하다'가 통했던 건, 그 값이 실제로 쓰이기 전에 확인해 줄 '사람'이 있었기 때문인데요.

AI가 바꿔놓은 것

그런데 AI가 데이터를 쓰는 방식을 바꿔 놓았습니다. 데이터가 사람이 나중에 꺼내 보는 '고정된 자료(정적 입력)'였다면, 이제는 'AI가 돌아가는 내내 실시간으로 받아 쓰는 재료(런타임 의존성)'로 바꿔놓았습니다. 이제 데이터의 소비자는 대시보드를 읽는 사람이 아니라, 방금 전달받은 데이터로 기계의 속도로 결정을 내리는 시스템입니다. 게다가 그 판단에는 사람이 끼어들 틈이 거의 없는데요. 자동 발주로 이어지는 수요 예측 모델을 떠올려 볼까요. 매일 아침 데이터는 제때 도착하고, 스키마도 멀쩡하고, 빈 값도 없습니다. 하지만 몇 주 전 가격 정책이 바뀌며 구매층이 서서히 달라졌고(입력 분포가 이동했고), 모델은 그 사이 조용히 과다 발주를 이어옵니다. 아무 알림도 울리지 않죠. 예전 방식이 이상을 잡아내던 지점 어디에서도 실제로 문제가 터지지 않았으니까요.

같은 문제가 에이전트에서도 나타납니다

이 문제는 요즘 부쩍 늘어난 엔터프라이즈 에이전트에서도 똑같이 드러나는데요. 에이전트가 기술적으로는 최신이지만 맥락상으로는 틀린 데이터를 가져다 쓰는 경우가 있습니다. 고객에게 답하거나, 워크플로를 승인하거나, 리스크를 요약해 보고할 때와 같은 상황에서 말이죠. 이렇게 되면 데이터 파이프라인도 정상적으로 돌았고, 검색도 제대로 작동했지만, 정작 그 답을 신뢰할 수 없는 상황이 생깁니다. 애초에 데이터 계약(contract, 데이터가 지켜야 할 형식·조건에 대한 약속)이 '에이전트가 무엇을 가정해도 되는지'를 규정해 두지 않았기 때문이죠. 즉 데이터가 도착하고 형식이 맞는 것만으로는, AI가 그걸 올바르게 쓰리라는 보장이 되지 않는 셈입니다.

지금의 일: 전달을 넘어 '보증'까지

그래서 이제 기준 자체가 달라졌습니다. 데이터가 제때 도착하고 정해진 규칙을 통과하는 것만으로는 더 이상 충분하지 않은데요. 이제는 '이 데이터가 AI가 하려는 일에 정말 적합한가, 그리고 적합하지 않게 되는 순간을 우리가 알아챌 수 있는가'를 물어야 합니다. 이 변화에는 이름도 붙기 시작했습니다. 바로 '신뢰 엔지니어(trust engineer)'인데요. 데이터가 잘 전달됐는지가 아니라, 그 데이터를 바탕으로 작동하는 AI를 신뢰할 수 있는지를 책임지는 사람을 가리킵니다. 그만큼 역할의 범위도 예전보다 한층 넓어졌는데요.

• 작업이 아니라 데이터를 지켜보기 → 파이프라인이 멈추지 않고 잘 끝났는지만이 아니라, 거기서 나온 데이터가 지금도 쓸 만한지까지 지켜봅니다.
• 형식이 아니라 데이터의 '결'을 살피기 → 스키마나 행 개수가 맞는지를 넘어, 데이터의 분포가 달라지진 않았는지(드리프트, 데이터가 조용히 변하는 현상)를 함께 봅니다.
• 계보(lineage)를 살아 있는 도구로 쓰기 → 데이터가 어디서 와서 어디로 흘러가는지의 기록을, 문서로만 남기지 않고 '어떤 변화가 어느 AI에 영향을 주는지' 추적하는 데 활용합니다.
• 에이전트를 위한 거버넌스와 접근 제어 → AI 에이전트가 어떤 데이터까지 건드릴 수 있는지 정하고, 실제로 무엇을 건드렸는지 확인할 수 있게 관리합니다.

이 모든 게 기존 기술을 대체하는 건 아닙니다. 파이프라인·오케스트레이션·모델링은 여전히 토대이지만, 더 이상 결승선이 아니라 기본 전제가 된 것이죠.

밑바탕에 깔린 '태도의 전환'

앞서 말한 관측·계보·거버넌스 같은 도구를 갖추는 일은, 이 전환에서 오히려 쉬운 부분입니다. 진짜 어려운 건 '어디까지 해야 일이 끝난 것인가'라는 기준 자체를 바꾸는 것인데요. 예전에는 완료의 기준이 '전달'이었습니다. 테이블이 최신 상태이고, 스키마가 유지되고, 작업이 정상으로 끝나면 내보내는 식이었죠. 이제는 완료의 기준이 '적합성'으로 바뀝니다. 데이터가 그저 존재하고 정확한 수준을 넘어, 곧 그 데이터를 사용할 시스템에 정말 적절한지, 그리고 그 적절함이 깨지는 순간을 알려주는 신호가 있는지까지 봐야 하는 것입니다. 실무에서는, 예전엔 재지 않던 것들에까지 기준을 세운다는 뜻인데요. 최신성·완전성뿐 아니라 데이터의 분포가 안정적인지, 데이터가 흘러온 경로(계보)가 온전한지, 그리고 우리가 넣어준 데이터에 모델이 실제로 어떻게 반응하는지까지 살핀다는 것이죠.

위협이 아니라 '확장'인 이유

이 흐름을 'ML 엔지니어나 플랫폼 팀에게 역할을 빼앗기는 신호'로 읽기 쉽지만, 오히려 반대입니다. 모델이 프로덕션에서 무너질 때, 근본 원인은 모델 안이 아니라, 더 상위(upstream)에 있을 때가 훨씬 많은데요. 데이터를 가져오는 원천(소스)이 바뀌거나, 데이터의 분포가 달라지거나, 데이터를 연결하는 조인이 어긋나거나, 공급되는 데이터가 옛날 것에 멈춰 있는 경우처럼 말이죠. 데이터가 흘러오는 위쪽 상황을 책임지고 꿰고 있는 사람이, 그 변화가 아래쪽 모델의 행동으로 어떻게 번지는지까지 연결할 수 있는 데이터 담당자입니다. 이 자리를 내어주는 건 역할을 안전하게 지키는 게 아니라 오히려 변방으로 밀어내는 일인데요. 데이터와 'AI가 그걸 어떻게 소비하는지'를 함께 이해하는 사람이야말로 시스템 전체를 신뢰할 수 있는지 가릴 수 있는 핵심축이 되고, 가치는 '변환을 작성하는 일'에서 '결과를 보증하는 일'로 옮겨갑니다.

그래서, 어디에 힘을 실어야 할까요

그렇다면 지금 이 역할에 있는 사람은 무엇부터 시작하면 좋을까요. 모니터링·거버넌스·관측을 '문제가 터졌을 때만 떠맡는 남의 일'로 두지 않고, 핵심 역량으로 끌어안는 것이 출발점입니다. 다음 습관들이 그 토대가 되는데요.

• 행 개수가 아니라 데이터의 분포를 지켜보기 → 파이프라인이 안정적으로 돌아도, 모델에는 예전과 전혀 다른 데이터가 들어가고 있을 수 있습니다.
• 데이터가 흘러가는 경로를 눈에 보이게 만들기 → 데이터를 공급하는 쪽에서 생긴 변화가 어떤 모델·리포트·에이전트에 영향을 주는지 한눈에 드러나도록 합니다.
• 실제 쓰임새에 맞춰 데이터 계약을 정하기 → 컬럼명·타입뿐 아니라, 최신성·전제 조건·접근 범위·허용 가능한 변화 폭까지 약속에 담습니다.
• ML·플랫폼 팀과 'AI의 반응'을 함께 보기 → 데이터의 변화를 모델 성능, 검색 품질, 에이전트의 행동과 연결해 살핍니다.
• 거버넌스를 '개발 인프라'로 다루기 → 누가 어떤 데이터에 접근했는지 기록하고, 민감 정보를 가리고(마스킹), 정책을 강제하는 일을 서비스 안정성의 일부로 삼습니다.

핵심은 하나입니다. 일을 '데이터를 나르는 파이프라인'이 아니라, '그 위에서 돌아가는 AI를 떠받치는 토대'로 정의하는 것이죠.

결국, 명함 속 직함이 아니라 미션이 바뀝니다

명함에 적힌 직함은 여전히 '데이터 엔지니어'일지 모릅니다. 하지만 그 밑에 깔린 미션은 '전달'에 대한 질문에서 '신뢰'에 대한 질문으로 바뀌고 있는데요. 예전엔 '데이터가 도착했고, 정확한가'였다면, 이제는 '이 데이터 위에 세운 AI를 신뢰할 수 있는가, 그리고 신뢰할 수 없게 되는 순간을 내가 알아챌 수 있는가'입니다. 훨씬 어려운 질문이지만, 이 질문에 잘 답하는 일이야말로 앞으로 데이터를 다루는 사람이 할 수 있는 가장 값어치 있는 일이 될 것입니다.

📌 주목해야 할 핵심 인사이트

1. '완료'의 정의가 바뀌면 일의 가치도 바뀝니다

예전에는 '제때, 정확하게 전달했는가'가 완료의 기준이었지만, 이제는 '그 결과물이 다음 단계에 정말 적합한가'가 기준이 됩니다. 이는 데이터에만 국한된 이야기가 아닌데요. 어떤 일이든 '넘겼다'가 아니라 '받는 쪽이 믿고 쓸 수 있는가'로 완료의 기준을 옮기는 순간, 그 일의 무게중심과 가치도 함께 올라갑니다.

2. 가장 위험한 문제는 '아무 알림도 울리지 않을 때' 생깁니다

요란하게 고장 나는 문제는 차라리 다루기 쉽습니다. 정작 무서운 건 모든 지표가 초록불인데 결과가 서서히 어긋나는 경우인데요. 눈에 보이는 오류만 감시하는 체계로는 이런 '조용한 저하'를 잡을 수 없습니다. 무엇을 지켜보고 있는지뿐 아니라, 무엇을 지켜보지 못하고 있는지를 점검하는 습관이 중요해집니다.

3. 문제의 뿌리는 대개 '내가 선 자리보다 위쪽'에 있습니다

결과가 어긋나면 가장 눈에 띄는 대상(모델·최종 단계)부터 의심하기 쉽지만, 원인은 그 위쪽의 조용한 변화일 때가 많습니다. 그 상류를 이해하고 하류까지 연결해 볼 수 있는 사람이 결국 전체를 신뢰할 수 있는지 판단하는 핵심이 되는데요. 어떤 분야든 '내 담당 구간'만 보지 않고 흐름 전체를 읽는 시야가 더 큰 가치를 만듭니다.

✏️ SUPERB Curation

슈퍼브 차문수 CTO의 추천:

Jev, 생성 대신 의사결정에 집중한 새로운 AI 모델

최근 공개된 Jev는 긴 답변을 생성하는 대신, 주어진 선택지에 대한 확률을 계산해 빠르게 의사결정을 내리는 데 특화된 AI 모델입니다. 일반적인 LLM처럼 토큰을 하나씩 생성하지 않고 필요한 판단 결과를 구조화된 형태로 바로 반환해, 분류나 라우팅, 스코어링처럼 빠른 결정이 필요한 작업에 활용할 수 있는데요.

Jev 공개 이후 이러한 방식을 오픈소스 모델에서도 활용하려는 움직임이 빠르게 나타나고 있습니다. Bespoke Labs는 Qwen 기반으로 Jev 방식의 의사결정을 구현한 Nimble을 공개했으며, Gemma와 Qwen 등 다양한 모델로 이를 확장하려는 시도도 이어지고 있습니다. vLLM에서도 관련 기능을 지원하기 위한 논의가 진행되고 있다고 합니다.

LLM이 모든 답변을 직접 생성하는 방식에서 벗어나, 필요한 작업에 따라 더 빠르고 효율적으로 '판단'하는 모델을 활용하려는 흐름이 확산되고 있다는 점에서 주목해볼 만합니다.

👉 Jev 자세히 살펴보기

슈퍼브 정현지 Product Advocate의 추천:

탐지에서 끝내지 않은 Vision AI 해커톤 1등 프로젝트

지난 8월, Superb AI × B.D.A.I Vision AI 해커톤이 최종 발표를 끝으로 마무리됐습니다.

이번 해커톤에서는 참가자들이 아이디어를 제안하는 데서 끝나는 것이 아니라, 직접 데이터를 모으고 정리하는 것부터 라벨링, 모델 학습과 검증, 실제 서비스 구현까지 4주 동안 비전 AI 프로젝트의 전 과정을 경험했는데요.

물류센터에서 발견한 안전 문제는 어떻게 하나의 비전 AI 서비스가 되었을까요? 1등 수상자는 세 종류의 공개 데이터셋을 통합해 2만 장 이상의 이미지와 약 19만 개의 박스 어노테이션을 정리하고, 프로젝트에 필요한 모델을 직접 학습했습니다. 안전 장비 미착용 여부를 탐지하는 데서 그치지 않고, 여러 위험 상황의 우선순위를 판단해 관리자의 대응까지 돕는 서비스로 완성했는데요. 데이터 준비부터 모델 학습과 서비스 구현, 그리고 1등 수상까지 이어진 개발 과정을 소개합니다.

👉 해커톤 수상자 인터뷰 살펴보기