← AI Engineer
조직 · 에이전트

생성AI 에이전트, 데이터 과학자의 것인가 — 답은 다양한 팀에 있다

전통 기업에서 에이전트 일이 기존 ML·데이터 과학 팀으로 떨어지는 위임 사슬을 짚고, 그 자리가 왜 어긋나는지를 파이프라인 차이로 설명함. 모델이 이미 만들어져 있어 학습·검증 절차가 통째로 빠지고, 행동을 바꾸는 손이 재학습이 아니라 입력과 프롬프트라는 것이다. 정밀도·재현율·F1에 눈이 묶이는 습관이 에이전트 평가에는 좁다는 것이 발표자가 가장 크게 든 반론이고, 대신 가드레일·LLM 심사·파인튜닝 셋에서는 값을 더한다고 결론짓는다. 잰 값은 하나도 나오지 않는다.

Phil Hetzel Braintrust발표 2026-05-2618분 39초AI Engineer

한줄 코멘트. 조직 이야기처럼 들리지만 실은 평가를 누가 정의하느냐의 이야기다. 발표자가 가장 크게 든 반론이 데이터 과학자가 무엇을 재야 하는지 안 보인다는 것이고, 답으로 데려오라는 사람도 문제에 가장 가까운 비기술 전문가다. 그런데 이 발표는 자기 회사가 파는 것이 바로 그 평가 도구인 자리에서 나온 것이라, 결론이 「사람을 더 데려와라」로 끝나는 대목은 그만큼 깎아서 읽어야 한다. 값은 하나도 나오지 않는다.

1. 물음과 발표자

브레인트러스트에서 솔루션 엔지니어링 팀을 이끄는 필 헷젤이 나온다. 그 전에는 컨설팅과 시스템 구축을 12년 했고 마지막에는 한 컨설팅 회사에서 데이터브릭스 사업부를 글로벌로 맡았다. 브레인트러스트는 사용자로 먼저 쓰다가 제품이 마음에 들어 지원했고 1년쯤 됐다고 말한다.

컨설팅 시절에 본 것을 하나 든다. 고객들이 생성AI 개념검증은 아주 잘 만드는데 그것을 프로덕션으로 올리는 데는 그만큼 못했다는 것이다.

이날 물음은 하나다. 에이전트와 에이전트 개발이 데이터 과학이나 ML 엔지니어의 것이냐는 것인데, 자기 답이 듣기 좋지는 않을 테니 이유를 들어 달라고 미리 말한다.

자기 회사 제품은 오늘 다루지 않겠다고 하고 아래층 부스로 오라고 한다. 다만 그 회사가 무엇을 하는지는 밝힌다. 에이전트 품질을 다루는 곳이고 기둥이 둘인데, 내보내기 전에 확신을 얻는 *평가와 내보낸 뒤 실제 사용자를 마주하고도 확신을 지키는 *관측이다.

2. 조직이 두 갈래다

일이 그 팀에 떨어지는 길

CEO나 CIO가 읽는다에이전트를 만들어야 한다는 글
대리인에게 넘긴다이걸 맡으라고 시킨다
플랫폼 팀에 떨어진다이름에 AI가 들었으니 기존 ML·데이터 과학 팀으로
발표자가 전통 기업에서 봤다고 말한 사슬이다. 마지막 칸이 이름 때문에 정해진다.

전통 기업 쪽 사슬을 먼저 그린다. 결정권자가 잡지에서 에이전트를 만들어야 한다는 글을 읽고 아래로 넘기면, 그것이 다시 기존 ML이나 데이터 과학 플랫폼 팀으로 내려간다. 생성AI라는 이름에 AI가 들어 있으니 기존 AI 팀에 넘기는 것이 자연스러운 선택이 됐다는 것이다. 청중에게 물으니 원래 ML 플랫폼 엔지니어였다가 생성AI를 넘겨받은 사람들이 손을 들었다.

다른 쪽은 AI 네이티브다. 생성AI 이전에 있던 것이 거의 없어 기존 체계를 덜 따지고, 처음부터 에이전트를 중심으로 사업을 세웠다. AI·ML 플랫폼 팀 대신 시대에 맞춰 유연하게 크는 작은 엔지니어 팀을 두고, 제품 엔지니어링과 AI 엔지니어링을 오가는 사람을 쓴다. 회사가 작아 각자가 문제에 더 가까이 있고, 그래서 이 에이전트가 무엇을 풀어야 하는지를 더 잘 안다고 말한다.

3. 무엇이 달라졌나

전통 ML과 생성AI가 갈리는 두 자리

무엇전통 ML생성AI
모델데이터를 모아 파이프라인에 태우고 학습시키고, 과적합을 피하며 배포하는 일이 그 팀의 일이다앤트로픽·오픈AI·미스트랄이 그 과정을 이미 끝내 끝점으로 내놨다. 남은 일은 그 API를 제품에 붙인 뒤 평가하는 것이다
고치는 손데이터를 더 넣어 다시 학습시키거나 *피처 엔지니어링을 하고 A/B 시험으로 나아졌는지 본다파인튜닝은 드물어 입력과 프롬프트와 맥락을 바꾼다. 값을 더하는 손이 피처가 아니라 자연어라 다른 재주가 판에 들어온다

이 표의 오른쪽 칸이 뒤에 나오는 찬반의 바탕이다. 학습과 검증을 오가는 절차가 통째로 빠져 있다.

4. 찬반 여섯

발표자가 양쪽으로 세운 근거

어느 쪽근거
데이터 과학자 쪽조직에서 모델을 다스리는 것이 그들이라 신경망과 언어 모델이 어떻게 도는지 아는 것이 많고, 그래서 이 기술의 위험을 더 잘 안다
데이터 과학자 쪽모델과 그 자산을 프로덕션에 올리는 엄격한 절차를 이미 갖고 있어 회사를 지키는 시험 과정을 안다
데이터 과학자 쪽시험을 대하는 태도가 엄격하다
반대 쪽모델이 이미 만들어져 있어 학습도 시험도 필요 없다. *교차검증 같은 절차를 밟지 않는 다른 파이프라인이다
반대 쪽무엇을 재야 하는지가 다르다. 정밀도·재현율·F1 같은 익숙한 지표에 눈이 묶이는데, 에이전트는 훨씬 넓은 면을 봐야 하고 기술적으로 잘 도는지가 아니라 할 일을 하는지를 봐야 한다. 발표자가 가장 큰 논거라고 지목한 자리다
반대 쪽언어 모델은 그냥 API다. 제품 엔지니어는 다른 시스템에서 정보를 가져와 쓸모 있게 내놓는 일에 이미 익숙하다

여기에 둘을 더 붙인다. 하나는 시스템 쪽이다. 감독 에이전트가 다른 인프라에서 도는 하위 에이전트들을 부르고 그것들이 또 다른 시스템을 부르는 구조가 되면 복잡한 시스템 문제이지 통계나 수학을 하던 사람의 자리가 아니라는 것이다.

다른 하나가 비기술 쪽이다. 주제 전문가나 제품 매니저가 에이전트에 넣는 프롬프트를 직접 쥐는 것이 값이 크다고 말한다. 이 사람들이 그 에이전트가 풀려는 문제에 가장 가깝기 때문이다. 좋은 에이전트를 만드는 데는 사람이 자취를 하나씩 보고 이름표를 다는 큰 작업이 들어가는데, 도메인을 아는 비기술 인력이 자취를 열어 잘 돌았는지, 무엇보다 왜 그런지를 말할 수 있다는 것이다.

5. 답은 가운데다

기술을 통째로 새로 익히라고 말할 생각은 없다고 못 박고, 이런 판을 만들 때는 팀을 다양하게 꾸리는 것이 맞다고 정리한다. 데이터 과학자가 값을 더하는 자리를 셋 든다.

첫째가 울타리다. 언어 모델은 다음 토큰을 예측할 뿐이고 사실 아는 것이 없는 통계 문제라고 말해 줄 수 있는 사람, 방 안의 어른 노릇을 할 사람이라는 것이다.

둘째가 모델로 채점하는 자리다. 에이전트 평가에서 언어 모델을 심사자로 쓰는 몫이 큰데, 사람들이 그 심사를 그냥 믿고 싶어 한다. 데이터 과학자는 이름표를 단 데이터 묶음을 만들어 정밀도·재현율·F1 식으로 그 심사자를 재는 재주가 있다.

셋째가 파인튜닝이다. 오픈소스 모델을 그 쓰임에 맞춰 손봐야 한다면 가장 기술적이고 재미있는 자리이며 여기서 크게 값을 더한다고 말한다.

팀을 어떻게 세울지도 짚는다. 비기술 전문가는 사람 이름표 작업과 프롬프트·맥락 엔지니어링을 맡고, 제품과 시스템 엔지니어는 그 요구를 제품에 넣고 에이전트가 도는 시스템을 잘 만들고, 데이터 과학자는 평가와 관측 파이프라인을 실제로 만들어 프로덕션과 실험 사이에 되먹임 고리를 세운다.

평가를 낡지 않게 두는 고리

프로덕션에서 모은다실제로 오간 자취를 쌓는다
평가 묶음에 더한다오프라인으로 잴 데이터로 넣는다
사람 판단과 맞춰 본다평가가 사람 손과 붙는지 갈라지는지 본다
실험에서 다시 잰다
질의응답에서 나온 자리다. 평가 자체가 낡는다는 것을 셋째 칸이 다룬다. 발표는 이 고리를 얼마나 자주 도는지, 어긋났을 때 무엇을 고치는지는 대지 않는다.

질의응답이 둘 붙는다. 하나는 도구를 누가 갖느냐가 아니라 어떤 문제를 푸느냐로 봐야 하지 않느냐는 물음이었고, 발표자는 같은 생각이라며 전통 기업의 잘못은 이 일을 ML 엔지니어와 데이터 과학자에게만 가둬 두는 것이라고 답한다.

다른 하나는 고리를 닫는 도구에 대한 것이었다. 도메인 전문가가 시스템을 손보기 쉽게 만드는 도구가 빠진 자리라고 말하면서 자기네 판에 사람 이름표 기능과 프롬프트를 시험해 보는 자리가 있다고 답한다. 평가하는 쪽을 낡지 않게 지키는 방법을 묻자, 프로덕션에서 모은 것을 오프라인 평가 묶음에 계속 더하고 그 평가가 사람 판단과 붙는지 갈라지는지를 스스로 본다고 답한다.

결론은 답은 늘 가운데 있다는 것이고, 에이전트를 만들 때 방에 사람을 더 데려오라는 말로 끝난다.

6. 발표가 밝히지 않은 것

값이 하나도 없다. 조직을 두 갈래로 갈라 놓고도 어느 쪽이 무엇을 얼마나 더 잘 냈는지 잰 것이 없다. 개념검증은 잘 만드는데 프로덕션에 못 올린다는 관찰이 발표의 출발점인데, 몇 곳에서 몇 건이 그랬는지가 없다.

찬반 여섯도 근거의 성격이 같지 않다. 위험을 더 잘 안다거나 시험 태도가 엄격하다는 것은 겪은 인상이고, 학습 절차가 빠진다는 것은 사실이다. 발표는 이 둘을 나란히 세운다.

가장 큰 논거로 든 자리에도 대안이 없다. 정밀도·재현율·F1이 좁다고 했으면 그럼 무엇을 재야 하는지가 나와야 하는데, 훨씬 넓은 면이라는 데서 멈춘다. 뒤에서 데이터 과학자가 심사자를 잴 때 쓰라고 든 지표가 다시 정밀도·재현율·F1이라 앞뒤가 맞물리는 자리인데 그 대목도 짚지 않는다.

비기술 전문가가 프롬프트를 쥔다는 대목의 값도 없다. 이름표 작업이 얼마나 드는 일인지, 그 사람들의 판단이 서로 갈릴 때 무엇으로 맞추는지가 나오지 않는다.

발표자 자신이 평가 도구를 파는 회사 사람이라는 것은 앞에서 밝히고, 제품 이야기는 안 하겠다고 말한다. 다만 결론에 나오는 세 자리와 팀 구성이 그 도구가 필요한 자리와 겹친다는 것은 발표가 다루지 않는다.

용어

*평가
에이전트를 내보내기 전에 무엇을 얼마나 하는지 재 보는 일. 영어로 eval
*관측
내보낸 뒤 실제로 어떻게 도는지 자취로 지켜보는 일. 영어로 observability
*피처 엔지니어링
모델에 넣을 입력 항목을 사람이 골라 다듬는 일
*교차검증
데이터를 여러 벌로 갈라 번갈아 학습과 시험에 써 성적을 재는 방법