결과물로 값을 받는 회사가 본 기업 현장
10월 21일 공개된 Latent Space 에피소드에서 진행자 스윅스(swyx)는 AI Engineer 뉴욕 행사장에서 Tenex의 알렉스 리버먼(Alex Lieberman)과 CJ 헤스(CJ Hess)를 만났습니다. 리버먼은 Tenex의 공동창업자이고, CJ는 특수 프로젝트를 이끌고 있습니다. Tenex는 큰 기업의 AI 전환을 돕는 회사로, 엔지니어에게 일한 시간이 아니라 완료한 작업량을 기준으로 보수를 줍니다. 작업량은 개발 조직에서 흔히 쓰는 단위인 스토리 포인트로 셉니다.
이 대담을 고른 것은 Tenex가 서 있는 위치 때문입니다. 고객의 절반이 포춘 2000으로 불리는 대기업이고, 나머지 절반이 연 매출 1억~5억 달러 규모의 중견기업이라고 합니다.04:38 도입 방향을 조언하는 데서 그치지 않고 실제 구축까지 맡는 회사라, 도구를 보급한 뒤 어디서 일이 멈추는지를 가까이서 봅니다. 대담에서는 논지 세 가지만 골라 짧게 옮기고, 나머지 분량은 한국 조직에 옮길 때 무엇이 걸리는지 노바폴드가 해석하는 데 썼습니다.
Tenex가 짚은 세 가지: 결과 단위, 결정 기록, 업무 표준
첫째는 결과로 보상하려면 견제하는 역할이 같이 있어야 한다는 점입니다. 작업량에 보수를 걸면 흔히 두 가지 걱정이 나옵니다. 작업량 추정을 부풀리거나 품질 낮은 코드로 숫자만 채우리라는 걱정입니다. Tenex 쪽은 고객 유지와 성장에 보상받는 AI 전략가가 엔지니어와 반대 방향에서 일을 확인하기 때문에 이 걱정이 현실이 되지 않았다고 말합니다. 정작 어려웠던 것은 설계나 고객 미팅처럼 코딩이 아닌 시간을 어떻게 보상하느냐였습니다.
그 두 가지 걱정은 우리 AI 전략가들 덕분에 전혀 문제가 되지 않았습니다.
둘째는 결정의 이유를 코드 옆에 남긴다는 점입니다. CJ는 Tenex의 개발 작업 방식인 MetaHarness를 소개했습니다. 계획 문서와 에이전트의 결정 기록을 코드와 함께 저장소에 올려 나중에 에이전트가 무엇을 만들었는지뿐 아니라 왜 그렇게 만들었는지도 읽게 합니다. 코드만 있으면 문서는 필요 없다는 주장에는 동의하지 않는다고 했습니다.
왜 그렇게 결정했는지 알아야 하고, 그때 오간 대화의 맥락도 알아야 합니다.
셋째는 대담에서 가장 큰 숫자 차이와 함께 나왔습니다. Tenex가 대화 중인 대기업 약 100곳 가운데 90%가 범용 AI 도구를 직원에게 나눠 줬지만, 개발 밖의 업무에 에이전트를 실제로 운영하는 곳은 5% 정도라는 설명입니다.21:08 그 이유로 Tenex 쪽은 같은 일을 40명이 저마다 조금씩 다른 방식으로 하면 그 일을 맡을 에이전트를 만들기 어렵고 표준이 없으면 에이전트가 제대로 했는지 판단할 평가 기준도 세울 수 없다고 했습니다.
존재하지 않는 프로세스는 자동화할 수 없습니다.

한국 조직에서는 기준을 글로 남기는 단계에서 막힙니다
세 논지에는 대담에서 따로 말하지 않은 전제가 하나 깔려 있다고 봅니다. 일을 세는 단위와 기록을 쌓을 곳이 이미 있다는 전제입니다. 개발 조직에는 티켓과 스토리 포인트라는 단위가 있고, 코드 저장소라는 기록 장소가 원래 있습니다. MetaHarness도 그 위에 결정 기록을 한 겹 얹은 구조입니다. 개발 밖의 업무에는 둘 다 없는 경우가 많습니다.
그래서 노바폴드는 5%라는 숫자를 에이전트 기술의 한계보다 단위와 기록 장소를 새로 만드는 데 드는 비용으로 읽습니다. 기술의 한계라면 다음 모델을 기다리면 되지만 단위와 기록의 문제는 조직이 직접 풀지 않으면 시간이 지나도 그대로 남습니다.
한국 조직에서는 이 비용이 더 커지기 쉽습니다. 업무 매뉴얼이 있어도 실제 판단 기준은 담당자의 경험 속에 남아 있는 경우가 많고 순환 보직으로 담당자가 바뀌면 기준도 함께 떠납니다. 결재 문서에는 결론과 승인 이력이 남지만 왜 다른 안을 버렸는지는 잘 남지 않습니다. Tenex가 저장소에 남긴다고 한 바로 그 정보가 빠지는 셈입니다.
기록 장소도 문제입니다. 개발 밖의 업무 맥락은 메신저 대화, 메일 스레드, 개인 PC의 엑셀 파일에 흩어져 있는 경우가 많습니다. 사람은 이 조각들을 기억으로 이어 붙여 일하지만 에이전트는 그렇게 하지 못합니다.
개발 조직의 저장소에 해당하는 곳, 곧 업무 기준과 판단 이유가 한데 모이고 누가 언제 고쳤는지 남는 공간을 업무마다 정해야 합니다. 새 시스템을 들일 필요는 없고 공유 문서 한 벌로 시작해도 됩니다. 도구보다 중요한 것은 그 문서를 관리하는 사람이 정해져 있느냐입니다.
표준을 누가 쓰느냐도 걸립니다. 현업 부서는 표준 문서 작성을 본업 밖의 일로 여기기 쉽고 IT나 혁신 조직은 현업의 판단 기준을 정할 권한이 없습니다. 노바폴드는 에이전트 과제가 개념 검증(PoC) 단계에서 멈추는 경우 상당수가 이 공백에서 생긴다고 판단합니다.
보상 구조는 그대로 옮기기 어렵습니다. 국내 인사 제도에서 개인 작업량을 보수에 바로 연동하기는 쉽지 않습니다.
가져올 만한 것은 보수 체계가 아니라 그 뒤의 설계입니다. 결과를 세는 단위를 먼저 정하고 그 숫자를 부풀릴 유인이 생기면 반대편에서 확인하는 역할을 함께 두는 방식입니다. 가상의 고객 문의 대응팀이라면 처리 건수와 함께 재문의 비율을 보고 재문의 비율은 품질 관리 담당이 따로 확인하는 식으로 짝을 지을 수 있습니다. 한국 조직이 이 사례에서 현실적으로 가져갈 수 있는 것은 숫자 하나에 평가와 판단을 모두 걸지 않는다는 원칙입니다.
가상의 예를 하나 들어 보겠습니다. 한 제조사 구매팀에서 다섯 명이 협력사 견적을 비교한다고 하겠습니다. 누구는 단가부터 보고, 누구는 납기와 과거 불량 이력을 먼저 봅니다. 비교표 양식도 사람마다 다릅니다. 이 상태에서 견적 비교 에이전트를 만들면 에이전트가 낸 결과를 누구의 기준으로 검토할지부터 정할 수 없습니다.
순서를 바꾸면 달라집니다. 다섯 명이 실제로 보는 비교 항목과 예외 처리 기준을 한 장으로 합의하고 지난 분기 견적 몇 건을 그 기준으로 다시 비교해 정답지를 만듭니다. 그다음에야 에이전트가 비교표 초안을 쓰고 담당자는 예외 건만 검토하는 구조가 성립합니다. 이 예시에서 가장 오래 걸리는 단계는 에이전트 개발이 아니라 합의입니다.
합의가 오래 걸리는 데는 이유가 있습니다. 다섯 명의 방식이 다른 데는 대개 각자의 경험이 깔려 있습니다. 단가가 낮아도 납기를 자주 어긴 협력사를 겪어 본 사람은 납기부터 봅니다. 기준을 합의하는 일은 이런 경험을 규칙으로 꺼내는 과정이라 경험이 가장 많은 사람이 시간을 내지 않으면 진행되지 않습니다. 과제 일정에 이 시간을 미리 넣어 두지 않으면 개발을 마쳐도 현업이 쓰지 않는 결과물이 나옵니다.
반대로 한 번 합의한 기준은 에이전트가 없어도 쓸모가 있습니다. 새로 온 담당자의 인수인계 자료가 되고 협력사에 평가 기준을 설명하는 근거도 됩니다.
에이전트가 일을 올리고 사람이 검토하는 구조에는 한국 조직에서 질문이 하나 더 붙습니다. 에이전트가 쓴 초안을 담당자가 확인해 결재에 올렸다면 오류의 책임은 누구에게 있느냐는 질문입니다. 여기에 답이 없으면 검토자는 초안을 처음부터 다시 확인하게 되고 에이전트를 들인 효과도 그만큼 줄어듭니다.
그래서 기준 문서에는 처리 순서뿐 아니라 에이전트 초안에서 사람이 반드시 볼 항목과 보지 않아도 되는 항목을 함께 적어 두는 편이 좋습니다. 검토 범위가 글로 정해져 있어야 사람이 예외 판단에 시간을 쓸 수 있습니다.
Tenex가 두 번째 단계로 꼽은 교육과 활용 지원도 다시 볼 만합니다. 국내 기업의 AI 교육은 도구 기능을 익히는 데 집중되는 경우가 많습니다. 에이전트 단계로 가려면 교육에 자기 업무를 순서와 판단 기준으로 풀어 쓰는 연습이 들어가야 합니다. 프롬프트를 능숙하게 쓰는 사람보다 자기 일의 기준을 글로 설명할 수 있는 사람이 많은 조직이 다음 단계로 먼저 넘어갑니다.

에이전트 도입의 속도는 기준을 쓰는 속도를 넘지 못합니다
대담에서 Tenex는 모델이 빠르게 좋아지고 작업당 비용도 내려가고 있다고 말했습니다.17:59 도구 쪽 제약은 계속 풀리고 있다는 뜻입니다. 그렇다면 90%와 5% 사이를 좁히는 속도는 결국 조직이 자기 업무 기준을 글로 써 내는 속도에 달려 있습니다.
모델 성능 경쟁은 앞으로도 이어지겠지만 그 결과는 모든 조직에 거의 같은 시점에 도착합니다. 조직 사이의 차이는 그 모델에게 건넬 업무 기준을 얼마나 갖고 있느냐에서 벌어집니다. AX의 다음 단계가 기술보다 기록의 문제라면, 우리 조직의 업무 기준은 지금 어디에 적혀 있습니까?
참고
- AI for the Fortune 2000: How Tenex Builds an AI-Native SDLCLatent Space 에피소드 페이지 · 공개 대본 포함 · 2026.10.21
- AI in NYC: How Tenex Builds an AI-Native Engineering Team | Alex Lieberman & CJ HessLatent Space · YouTube · 2026.10.21
- Building an AI-Native SDLCTenex 블로그 · 2026.08.05