AI는 어려운 수학 문제를 풀고, 수백 줄짜리 코드를 쓰고, 긴 문서를 몇 초 만에 요약합니다. 그런데 고객 문의를 분류하거나 환불 여부를 판단하는 것처럼 겉보기에는 더 단순한 업무에는 여전히 사람이 붙어 있죠. 모델은 이렇게 똑똑해졌는데, 왜 일은 통째로 맡기기 어려울까요?
2026년 7월 AI Engineer World's Fair 무대에 오른 Diogo Almeida는 이 모순을 모델의 지능보다 목표의 차이로 설명합니다. InstructGPT와 GPT-4 연구에 참여한 그는, 사람의 요청을 잘 따르는 보조 AI와 사람 없이 돌아가는 자동화 시스템은 처음부터 성공 조건이 다르다고 말해요. 이번 글에서는 그의 강연과 TypeSafe의 첫 제품 Jev를 통해, AI에게 일을 통째로 맡기려면 무엇을 바꿔야 하는지 살펴봅니다.
AI가 잘하는 일과, 우리가 맡기고 싶은 일 사이의 틈
강연 초반 Almeida는 AI를 둘러싼 상반된 두 풍경을 한 화면에 놓습니다. 한쪽에서는 모델이 자연어 처리와 수학 벤치마크를 빠르게 넘고, 코딩 에이전트가 점점 긴 작업을 수행합니다. 다른 한쪽에서는 고객지원이나 회계 같은 반복 업무에 사람이 계속 남아 있어요.
그는 여기서 단순하지만 불편한 질문을 던집니다. 풀리지 않던 수학 문제에 도전하는 모델이 왜 고객 문의 하나를 끝까지 처리하지는 못할까요? 강연자가 보기에 이는 어려운 문제와 쉬운 문제의 차이만으로 설명되지 않습니다.
결정적인 차이는 결과를 확인하는 사람이 작업 안에 있느냐입니다. 코딩 도구의 결과는 사용자가 읽고, 실행하고, 오류를 고치고, 다음 지시를 내립니다. 모델이 애매하게 답해도 사람과의 대화가 다음 단계에서 빈틈을 메워줘요.
이런 제품에서 자연스러운 말투와 의도 파악은 중요한 성능입니다. 사용자가 원하는 방향을 빨리 알아듣고 수정 요청에 잘 반응하면, 결과가 첫 시도에 완벽하지 않아도 충분한 가치를 만들 수 있거든요.
자동화 시스템은 조건이 다릅니다. 새벽에도 백그라운드에서 돌아가고, 결과를 다른 소프트웨어에 넘기고, 때로는 고객이나 돈에 영향을 주는 결정을 곧바로 실행합니다. 사람이 모든 결과를 읽지 않는 것이 목표라면, 사람의 판단력으로 메우던 빈자리를 시스템이 맡아야 하죠.
Almeida는 이 차이를 assistance와 automation으로 부릅니다. 보조의 목표는 사람과 함께 더 나은 결과를 만드는 것이고, 자동화의 목표는 매번 사람을 호출하지 않아도 정해진 일을 안정적으로 끝내는 것입니다.
같은 모델을 사용하더라도 제품의 책임 구조는 완전히 달라집니다. 이메일 초안을 만드는 기능은 사용자가 발송 전에 읽을 수 있어요. 이메일을 자동 발송하는 기능은 수신자, 내용, 시점이 잘못됐을 때 이미 외부 행동이 일어난 뒤일 수 있습니다.
환불 업무도 마찬가지입니다. 상담원이 모델의 추천을 참고하는 경우라면 잘못된 추천을 거절할 수 있습니다. 모델이 직접 환불을 승인한다면 금액 한도, 중복 요청, 계정 위험 신호, 예외 규정까지 실행 전에 검사해야 하죠.
그래서 “AI를 도입했는데 왜 일이 줄지 않지?”라는 질문에는 두 가지 답이 가능합니다. 직원이 더 빨리 초안을 만들게 됐다면 보조 능력은 커졌습니다. 그러나 그 초안을 사람이 계속 읽고 고쳐야 한다면 업무 흐름에서 검토 단계가 사라진 것은 아니에요.
AI 기능을 붙인 것과 자동화를 완성한 것은 같은 말이 아닙니다. 자동화는 모델의 평균 성능만 높이는 일이 아니라, 사람이 하던 확인을 규칙과 인터페이스와 기록으로 옮기는 일에 가깝습니다.
사람의 선호를 배운 AI는 왜 사람을 다시 필요로 할까
이 구분을 이해하려면 대화형 AI가 어떤 목표를 배웠는지 봐야 합니다. 오늘날 챗봇이 사용자의 지시를 잘 따르게 된 배경에는 RLHF, 즉 인간 피드백을 통한 강화학습이 있어요.
InstructGPT 연구에서는 먼저 사람이 좋은 답변의 예시를 만들었습니다. 그다음 여러 모델 답변을 비교해 순위를 매기고, 그 순위를 예측하는 보상 모델을 학습했습니다. 마지막으로 언어 모델이 높은 보상을 받는 답을 만들도록 조정했죠.
여기서 ‘선호’는 가벼운 인기투표만 뜻하지 않습니다. 지시를 제대로 따르는지, 도움이 되는지, 위험한 내용을 피하는지처럼 사용자가 실제로 원하는 여러 특성을 사람의 비교 판단으로 모으는 방식이에요.
이 접근은 분명 성과를 냈습니다. InstructGPT 연구는 조사한 조건에서 기존 GPT-3보다 사람의 지시를 더 잘 따랐고, 진실성과 독성 관련 평가도 개선됐다고 보고했습니다. 그러니 “인간 피드백 때문에 AI가 거짓말하게 됐다”라고 단순화하면 원래 결과와 맞지 않습니다.
문제는 평가자가 좋아하는 답과 사실에 맞는 답이 항상 일치하지는 않는다는 데 있습니다. 모르는 것을 모른다고 짧게 인정하는 답보다, 자신감 있고 친절하게 설명하는 답이 더 그럴듯하게 느껴질 수 있어요.
강연에는 이 어긋남을 보여주는 장난스러운 사례가 나옵니다. 누군가 음악이라며 엉뚱한 소리 파일을 보냈는데, 모델이 분위기와 작품성을 진지하게 칭찬했다는 내용입니다. 모델이 실제로 무엇을 들었는지보다 사용자가 기대할 반응을 내놓은 셈이죠.
이 일화를 모든 모델에 대한 증거로 볼 수는 없습니다. 하지만 Almeida가 강조하는 위험은 선명합니다. 사람이 화면을 보고 있다면 과한 칭찬을 웃고 넘기거나 바로잡을 수 있지만, 보이지 않는 자동화 단계에서는 그럴듯한 오판이 그대로 다음 프로그램에 전달될 수 있습니다.
2023년 Anthropic 연구도 비슷한 긴장을 제한적으로 확인했습니다. 연구진은 다섯 AI assistant와 인간 선호 데이터를 조사했고, 사용자의 관점에 동의하는 답이 더 선호되는 경향과 선호 모델 최적화가 일부 과업에서 진실성보다 아첨을 강화한 사례를 보고했어요.
두 연구는 서로 반대되는 결론이라기보다 적용 범위를 보여줍니다. 인간 피드백은 모델을 훨씬 유용하게 만들 수 있습니다. 동시에 평가자의 선호가 정답과 어긋나는 과업에서는 별도의 검증 신호가 필요해요.
자동화에서 필요한 출력은 자신감 있는 긴 문장만이 아닙니다. 모델이 선택한 행동, 그 판단의 불확실성, 입력이 기준을 벗어났는지 여부를 다음 시스템이 읽을 수 있어야 합니다. 모른다는 신호를 숨기지 않는 것이 친절한 설명보다 더 중요할 때가 있습니다.
여기서 환각과 잘못된 결정을 구분할 필요도 있습니다. 존재하지 않는 사실을 자유 문장으로 만들어내는 문제를 줄여도, 정해진 선택지 가운데 틀린 선택을 고를 수는 있어요. 출력 형식을 제한하는 것만으로 판단이 항상 맞아지는 것은 아닙니다.
결국 자동화 제품은 “답이 그럴듯한가?”와 다른 질문을 해야 합니다. 이 결과를 기계가 검사할 수 있는가, 틀렸을 때 멈출 수 있는가, 확신이 낮을 때 사람에게 보낼 수 있는가가 제품 설계의 중심으로 올라옵니다.
코드를 더 빨리 쓰는 것과 더 똑똑한 소프트웨어
강연 중반 Almeida는 Claude Code를 예로 들며 코딩 에이전트도 아직 보조의 시대에 속한다고 주장합니다. 이는 제품의 객관적 성능 평가라기보다, 그가 assistance와 automation을 나누는 기준에서 나온 분류예요.
코딩 에이전트의 가치는 분명합니다. 요구사항을 코드로 바꾸고, 오류를 찾고, 여러 파일을 수정하는 속도가 빨라졌습니다. 소프트웨어를 만드는 비용과 시간이 낮아지면 이전에는 만들지 못했던 작은 도구도 손쉽게 만들 수 있죠.
하지만 소프트웨어를 더 싸게 만드는 것과 소프트웨어 자체가 더 신뢰할 만한 결정을 내리는 것은 다른 변화입니다. 개발 속도가 두 배 빨라져도, 완성된 제품이 모든 결과를 사람에게 확인받아야 한다면 실행 구조는 예전과 크게 달라지지 않을 수 있어요.
Almeida는 많은 SaaS가 기존 화면 옆에 챗봇을 붙이는 형태에 머물렀다고 봅니다. 사용자가 질문하고, 모델이 문장으로 답하고, 사용자가 답을 읽어 다음 행동을 선택하는 구조죠. ‘2019년 이후 SaaS가 변하지 않았다’는 강한 표현은 그의 견해이며 산업 전체를 입증한 통계는 아닙니다.
그가 원하는 것은 채팅창이 하나 더 생긴 제품보다 판단을 맡길 수 있는 새로운 소프트웨어 구성 요소입니다. 일정한 입력을 받아 정해진 결정을 내리고, 그 결정을 기존 코드가 바로 사용할 수 있는 형태로 돌려주는 구성 요소예요.
고객 문의를 예로 들면 차이가 더 선명합니다. 보조형 제품은 상담원에게 답변 초안을 씁니다. 자동화형 제품은 먼저 환불 승인 / 보류 / 사람 검토처럼 허용된 행동을 정의하고, 모델은 그 범위에서 하나를 선택합니다.
그다음 주변 소프트웨어가 금액과 확률, 고객 등급, 규정 예외를 검사합니다. 소액이면서 확신이 높은 건 자동 처리하고, 큰 금액이나 처음 보는 유형은 사람에게 올릴 수 있어요. 모든 실행은 기록하고 필요할 때 되돌릴 수 있어야 합니다.
이 예시는 영상의 직접 제품 설명이 아니라 assistance와 automation 구분에서 도출한 적용입니다. 중요한 점은 모델 하나가 전 과정을 알아서 한다는 상상이 아니라, 모델의 판단과 기존 소프트웨어의 규칙을 어떻게 나눌지입니다.
자유로운 언어는 탐색과 설명에 강합니다. 반면 기존 소프트웨어는 명확한 값과 조건문을 다루는 데 강해요. 자동화는 둘 중 하나를 버리는 일이 아니라, 언어 모델이 필요한 판단과 코드로 확정할 규칙의 경계를 다시 긋는 일에 가깝습니다.
모델이 얼마나 똑똑한지보다, 모델이 틀렸을 때 시스템이 무엇을 하는지가 자동화의 수준을 결정합니다. 평균 정확도가 높아도 드문 한 번의 오류가 큰 손실을 만들면, 그 실패를 발견하는 구조가 제품의 핵심이 됩니다.
강연 두 달 뒤 공개된 Jev는 무엇을 바꿨을까
강연 당시 TypeSafe는 신뢰성과 자동화를 위해 AI 스택을 다시 설계하고 있으며 곧 공개할 예정이라고만 밝혔습니다. 그리고 2026년 9월 15일, 회사는 첫 제품 Jev를 얼리 액세스로 공개했어요.
TypeSafe의 설명에 따르면 Jev는 자유로운 문장을 쓰는 대신 미리 정의된 타입의 결정과 각 선택의 확률을 반환합니다. 회사는 이 학습 방식을 RLCD(Reinforcement Learning for Calibrated Decisions)라고 부릅니다.
가령 프로그램이 정상 / 의심 / 사람 검토 세 값만 받도록 정의했다면, 모델은 그 밖의 장황한 답을 새로 만들지 않습니다. 각 선택의 확률을 함께 받으면 주변 코드는 확신이 낮은 결과만 따로 분기할 수 있어요.
이 변화는 단순히 답변 길이를 줄이는 문제가 아닙니다. API의 모양 자체가 다음 행동을 전제로 설계됩니다. 모델의 문장을 다시 해석하는 중간 단계를 줄이고, 허용되지 않은 형식은 애초에 다음 시스템으로 넘어가지 않게 만드는 접근이죠.
강연 후반 Almeida는 학습 방법마다 최적화하는 목표가 다르면 API의 모양도 달라진다고 말합니다. 사람의 선호를 따르는 모델, 검증 가능한 정답을 맞히는 모델, 보정된 결정을 내리는 모델이 같은 인터페이스를 가져야 할 이유는 없다는 관점입니다.
여기서 보정(calibration)은 높은 확률을 말한 판단이 실제로도 그 정도 비율로 맞는 성질을 뜻합니다. 확률이 현실의 성공률과 잘 맞는다면 제품은 임계값을 정해 자동 실행과 사람 검토를 나누기 쉬워져요.
다만 확률 숫자가 붙었다고 곧바로 잘 보정된 것은 아닙니다. 실제 운영 데이터에서 예측 확률과 결과를 비교해야 하고, 고객군이나 입력 유형이 달라질 때 다시 확인해야 합니다. 이 검증 없이는 0.9라는 숫자도 또 하나의 그럴듯한 출력일 뿐이에요.
TypeSafe는 Jev가 특정 System One 과업에서 기존 LLM과 비슷한 지능 수준을 유지하면서 훨씬 빠르고 저렴하다고 주장합니다. 홈페이지와 출시 글에는 큰 배수의 속도·비용 수치도 제시돼 있습니다.
그러나 현재 확인한 것은 회사 자체 워크플로 평가와 회사 자료를 인용한 보도입니다. 비교 과업, 모델, 하드웨어, 평가 설정에 따라 결과가 달라질 수 있고 독립된 재현 결과는 확인하지 못했어요. 따라서 이 수치를 제품의 확정된 우위로 받아들이기는 이릅니다.
회사가 내세우는 “환각 0”도 같은 주의가 필요합니다. 자유 텍스트를 생성하지 않아 정의된 형식을 벗어나지 않는다는 뜻에 가깝지, 모든 분류와 결정이 옳다는 뜻은 아닙니다. 형식이 맞는 오답은 여전히 가능합니다.
그래서 Jev를 자동화의 정답으로 소개하기보다, 자동화용 AI의 인터페이스는 대화형 AI와 달라야 한다는 가설을 제품으로 만든 사례로 보는 편이 정확합니다. 무엇을 출력할지 제한하고 확률을 함께 내보내는 방향은 분명하지만, 실제 신뢰성은 운영 환경에서 따로 검증해야 합니다.
이 구조가 잘 맞는 일도 비교적 분명합니다. 티켓 분류, 위험도 판정, 승인 여부, 작업 라우팅처럼 선택지가 미리 정해져 있고 결과를 코드가 곧바로 사용해야 하는 일입니다.
반대로 기획안을 쓰고, 낯선 시장을 탐색하고, 고객의 모호한 요구를 대화로 풀어내는 일에는 자유로운 언어 모델이 더 적합할 수 있습니다. 하나의 모델이 모든 일을 대신하기보다, 업무의 모양에 따라 다른 모델과 검증 방식을 조합하게 될 가능성이 큽니다.
자동화의 시작은 모델 선택이 아니라 실패 설계다
모델을 고르기 전에 먼저 적어야 할 것은 정상 흐름보다 실패 흐름입니다. 어떤 입력을 받지 말아야 하는지, 어떤 판단은 사람이 해야 하는지, 이미 실행된 행동을 어떻게 취소할지를 정해야 해요.
첫째, 초안과 결정을 구분합니다. 문서 요약, 답변 초안, 코드 제안처럼 사람이 다음 행동을 선택하는 출력인지, 결제 승인, 계정 정지, 메시지 발송처럼 결과가 곧바로 실행되는 출력인지 표시합니다.
같은 정확도라도 두 업무의 위험은 다릅니다. 초안에서 틀린 문장은 검토자가 고칠 수 있지만, 자동 발송된 메시지는 고객이 이미 읽었을 수 있어요. 실행이 포함되는 순간 필요한 검증 수준이 올라갑니다.
둘째, 허용된 출력의 범위를 줄입니다. 자유문이 꼭 필요하지 않다면 선택지, 숫자 범위, 데이터 스키마로 결과를 받습니다. 다음 프로그램이 값의 형식과 범위를 자동으로 검사할 수 있기 때문이에요.
출력을 제한한다고 판단 오류가 사라지는 것은 아닙니다. 다만 예상하지 못한 형식의 오류를 줄이고, 어떤 종류의 실수가 남아 있는지 측정하기 쉬워집니다. 정확성을 높이는 장치이면서 관찰 가능성을 높이는 장치인 셈이죠.
셋째, 한 번 틀렸을 때의 비용을 적습니다. 평균 성공률만 보면 99%는 좋아 보입니다. 하지만 하루 만 건을 처리한다면 1%는 백 건이고, 그중 하나가 큰 금액이나 규정 위반과 연결되면 평균값의 의미가 달라집니다.
비용에는 돈만 들어가지 않습니다. 고객 신뢰, 복구에 필요한 시간, 잘못된 데이터를 다시 학습에 넣을 위험, 담당자가 오류를 찾느라 쓰는 시간도 포함됩니다. 자동화 효과를 계산할 때 검토 비용과 복구 비용을 함께 봐야 해요.
넷째, 사람에게 넘길 조건을 먼저 만듭니다. 입력이 빠졌을 때, 처음 보는 유형일 때, 확신이 낮을 때, 큰 금액이 걸렸을 때처럼 명시적인 에스컬레이션 규칙을 정합니다.
여기서 사람 검토는 실패의 증거가 아닙니다. 자동화가 처리할 수 있는 범위를 선명하게 만드는 제품 기능이에요. 모든 건을 검토한다면 자동화가 아니지만, 위험한 소수만 정확하게 골라 올린다면 사람의 시간을 더 중요한 판단에 쓸 수 있습니다.
다섯째, 나중에라도 실패를 발견할 수 있어야 합니다. 입력, 모델 버전, 출력, 실행 결과, 사람이 뒤집은 결정을 함께 기록합니다. 그래야 어떤 유형에서 확신은 높았지만 자주 틀렸는지 찾을 수 있어요.
로그가 없다면 오류가 없었던 것과 오류를 발견하지 못한 것을 구분하기 어렵습니다. 자동화가 조용히 돌아간다는 사실만으로 신뢰할 수 있는 시스템이 되지는 않습니다.
여섯째, 되돌릴 수 없는 행동은 더 작은 단계로 나눕니다. 바로 삭제하는 대신 보관함으로 옮기고, 바로 송금하는 대신 승인 대기 상태를 만들 수 있어요. 실행을 여러 단계로 나누면 모델의 한 번의 판단이 곧바로 최종 손실이 되는 것을 막을 수 있습니다.
이 여섯 항목은 강연에 나온 체크리스트를 옮긴 것이 아니라 assistance와 automation의 구분에서 도출한 실무 적용입니다. 특정 모델을 도입하면 자동으로 해결되는 기능이 아니라, 각 팀이 업무 흐름 안에 직접 설계해야 할 조건이에요.
‘무엇을 보상할 것인가’가 제품의 모양을 바꾼다
강연 마지막 질의응답에서 Almeida는 사전학습 자체보다 그 지식을 어떤 목표로 꺼내 쓰는지가 문제라고 봅니다. 인터넷의 지식을 압축한 사전학습 모델의 능력을 높게 평가하면서, 후처리의 목표에 따라 나타나는 행동이 달라진다고 설명해요.
그는 RLHF는 인간 선호를, RLVR은 검증 가능한 정답을, TypeSafe의 접근은 보정된 의사결정을 최적화한다고 구분합니다. 이 구도는 Almeida의 설명이며, 모든 최신 모델의 실제 학습 조합을 완전히 보여주는 분류는 아닙니다.
강연자는 이 대목에서 Richard Sutton의 ‘The Bitter Lesson’을 자신의 관점으로 확장합니다. Sutton의 원문은 장기적으로 인간 지식을 직접 넣는 방식보다 계산과 함께 확장되는 일반적 탐색·학습 방법이 더 큰 진전을 만들었다는 역사적 관찰입니다.
Almeida가 말한 ‘올바른 과업이 데이터보다 중요하다’는 위계는 Sutton의 직접 문장이 아닙니다. 두 사람의 주장을 합치면 안 돼요. 다만 어떤 목표를 정하느냐가 학습 결과뿐 아니라 제품 인터페이스에도 영향을 준다는 강연의 결론은 앞선 assistance와 automation 구분으로 이어집니다.
사람에게 설명하는 모델이라면 대화의 맥락과 표현의 유연성이 중요합니다. 검증 가능한 수학 문제를 푸는 모델이라면 정답을 확인할 채점기가 중요해요. 반복 업무를 자동 실행하는 모델이라면 결정의 범위, 불확실성, 실행 비용이 학습과 평가에 들어가야 합니다.
이 관점은 “어떤 모델이 가장 좋은가?”라는 질문도 바꿉니다. 가장 큰 모델 하나를 모든 업무에 넣는 대신, 우리가 원하는 결과가 대화인지 탐색인지 결정인지 먼저 정의해야 해요. 그다음에야 필요한 출력 형식과 평가 기준을 고를 수 있습니다.
AI가 계속 좋아지면 사람의 검토가 줄어드는 업무는 분명 늘어날 겁니다. 그러나 그 변화는 모델이 어느 날 완벽해져서 찾아오기보다, 어떤 실수는 자동으로 막고 어떤 상황은 사람에게 돌려보내는 시스템이 촘촘해지면서 나타날 가능성이 큽니다.
모델 성능표는 출발점입니다. 실제 자동화를 결정하는 것은 출력의 범위, 오류의 비용, 검토로 넘기는 기준, 실행 기록, 복구 경로예요. 이 구조가 없다면 뛰어난 모델도 결국 사람이 계속 지켜봐야 하는 보조 도구로 남습니다.
AI에게 일을 맡기고 싶다면, 먼저 사람이 하던 검증을 제품 안에 넣어야 합니다. 모델의 답을 믿는 것과, 모델이 틀려도 버틸 수 있는 시스템을 만드는 것은 서로 다른 일이니까요.
조쉬가 직접 운영하는 AI 솔로프리너 클럽에 초대합니다.
이미 300명이 넘는 분들이 ASC와 함께 성장하고 있습니다.
구글 엔지니어, 토스 PM, 산부인과 전문의, 스타트업 대표까지
— 각자의 자리에서 정상에 선 사람들이 지금 AI로 새로운 도전을 시작했습니다.
그리고 ASC 13기는 단 30명만 함께합니다.
아직 늦지 않았습니다.
지금 시작하는 당신이, 1년 뒤 가장 앞서 있을 솔로프리너입니다.
의견을 남겨주세요