AI 네이티브 엔지니어링 팀을 만드는 Tenex의 운영법

• 원제: AI in NYC: How Tenex Builds an AI-Native Engineering Team — Alex Lieberman & CJ Hess
• 원문 URL: https://www.youtube.com/watch?v=Vki6cklFqxo
• 게시일: 2026-10-21
• 처리일: 2026-10-21
• 채널: Latent Space (latentspacepod)
• 영상 ID: Vki6cklFqxo
• 길이: 43분 33초
• 출처: Latent Space 공식 에피소드 페이지의 자동 생성 전사와 타임스탬프를 바탕으로 정리했다. https://www.latent.space/p/tenex

📌 핵심 질문 / 이 대화가 다루는 핵심 논점

==AI가 코드를 싸고 빠르게 만들수록 엔지니어 보상, 기업의 업무 표준화, 소프트웨어 구매·구축의 기준을 어떻게 다시 세워야 하는가?== Tenex는 엔지니어의 투입 시간이 아니라 결과물에 보상하고, 고객의 지식과 설계 결정을 저장소에 축적해 에이전트가 장기 과업을 수행하도록 한다. 그러나 생산성이 두 배가 되어도 모든 가치를 스토리 포인트로 측정할 수는 없으며, 업무 과정이 제각각인 조직에는 자동화보다 프로세스 정립이 먼저다.

• Tenex 엔지니어의 산출물은 AI 도입 이후 대략 두 배로 늘었고, 회사는 결과물 중심 보상을 유지하면서 비코딩 기여를 보상하는 방식을 조정하고 있다.
• 기업의 범용 LLM 보급률은 높지만, 비엔지니어링 업무에서 실제 운영 중인 에이전트는 극히 적다. 데이터 권한과 프로세스 표준화가 주요 병목이다.
• AI 구축비가 낮아져도 기존 SaaS를 직접 대체하는 선택은 유지보수 부담, 사업상 위험, 사용자 경험 개선의 가치를 함께 따져야 한다.

AI는 스스로 경제에 확산되는 완제품이 아니라 조직의 맥락과 권한, 반복 가능한 업무 절차에 연결해야 하는 원재료다. Tenex의 접근은 엔지니어가 코드를 얼마나 많이 썼는지보다 고객 문제를 얼마나 잘 파악하고 검증된 결과를 냈는지에 초점을 둔다. 이 원칙은 보상 제도뿐 아니라 MetaHarness, 기업용 에이전트 배포, 수직형 AI 제품, 자체 소프트웨어 구축, 직무 재배치 논의까지 관통한다.

1. 결과물에 보상하는 엔지니어링 경제

1.1. 시간 판매에서 산출물 판매로

1. AI가 생산성을 올려도 시간당 과금은 엔지니어에게 불리하다

   1. 시간당 청구의 역설: 소프트웨어 엔지니어인 CJ Hess는 고객에게 시간을 기준으로 과금하던 컨설팅을 하면서 AI로 더 빠르고 나은 결과를 내는데도 청구 가능한 시간이 줄어드는 문제를 경험했다. 생산성 향상이 본인의 수입 감소로 이어졌다.
   2. Tenex의 유인 구조: Alex Lieberman이 제안한 모델은 일한 시간 대신 완료한 결과물에 보상하는 것이다. AI로 같은 시간에 더 많은 일을 처리하는 엔지니어가 수익도 더 많이 얻도록 보상 방향을 바꾼다.
   3. CJ의 초기 베팅: CJ는 Tenex의 첫 직원으로 합류했다. 창업을 여러 차례 시도하고 엔지니어링 컨설팅을 운영한 뒤, AI 컨설팅과 도구 활용을 늘렸다. Sonnet 3.5와 Gemini 2.5 Pro가 사용되던 초기에도 자신의 엔지니어링 역량과 AI 활용 능력을 결합하면 산출물과 소득 상한을 높일 수 있다고 판단했다.
   4. 성과 보상의 전제: 스토리 포인트(story points)를 일의 크기와 가치에 대한 합의 단위로 사용한다. 회사는 개발자가 AI를 활용해 작업을 병렬화할수록 시간 단위보다 결과 단위로 지불하는 방식이 경제적으로 자연스러워진다고 본다.

2. 성과급은 개인 생산성의 차이를 더 크게 드러낸다

   1. 역량에 대한 레버리지: Alex는 AI를 인간의 지성과 노동 윤리에 걸린 레버리지로 묘사한다. 같은 도구를 써도 기초적인 소프트웨어 역량, 새로운 모델을 익히려는 태도, 시간을 효율적으로 쓰면서 품질을 지키는 능력에 따라 결과 차이가 커진다.
   2. 선택적인 보상 모델: Tenex식 보상은 모든 엔지니어에게 맞는 제도가 아니다. 자기 역량에 투자하고 프런티어 기술을 빠르게 익혀 산출을 늘리고 싶은 사람에게는 높은 수익 잠재력을 제공하지만, 보상의 분산도 커진다.
   3. 스토리 포인트와 소득: 진행자는 과거 대화에서 일부 엔지니어가 연간 100만 달러 이상을 벌 수 있다고 언급했다. 이번 대화에서 Alex는 Tenex 내 최고·최저 보상 엔지니어 간 격차가 현재 약 4배라고 답했다. 10배 차이를 기대할 수 있느냐는 농담에는 아직 그 정도는 아니라고 선을 그었다.

1.2. 스토리 포인트의 한계와 보상 보정

1. 흔히 예상한 게임화 부작용은 핵심 문제가 되지 않았다

   1. 점수 부풀리기·일정 여유 잡기: 스토리 포인트가 주관적이라 개발자가 추정치를 부풀리거나 작업을 낮게 잡아 보상을 키울 수 있다는 우려가 있었다.
   2. 품질을 희생한 체크박스식 납품: 포인트만 얻기 위해 요구사항을 간신히 충족한 부실한 코드를 내놓을 수 있다는 우려도 제기됐다.
   3. 고객 관점의 견제: Alex는 이런 행동이 Tenex에서 가장 큰 문제가 되지는 않았다고 말한다. AI 전략가(AI strategist)는 고객 유지와 성장에 보상이 연동되어 있어 고객에게 가치가 없는 일을 밀어붙이는 엔지니어와 이해관계가 다르다. 이 역할이 결과물의 실제 효용을 확인하는 견제 장치가 된다.

2. 코딩 이외의 고가치 노동을 측정하기 어렵다

   1. 보상의 사각지대: 건축 설계(architecture), 고객 인터뷰, 문제 정의, 요구사항 정리처럼 코드를 직접 작성하지 않는 활동은 티켓 단위의 스토리 포인트에 넣기 어렵다. Tenex가 발견한 더 까다로운 문제는 점수 조작보다 이 활동들에 어떻게 보상할지 정하는 일이었다.
   2. 고객의 맥락을 모델에 전달하는 역할: 모델이 적절한 맥락을 받으면 해결책의 약 90%까지 도달할 수 있게 되면서 CJ의 직접 코딩 시간은 줄었다. 대신 고객이 머릿속에 가진 정보를 충분히 듣고 이를 모델이 활용할 수 있게 정리하는 일이 중요해졌다.
   3. 결과물 평가로 확장: Tenex는 스토리 포인트를 기준점(anchor)으로 유지하면서도 앞으로는 완성된 결과가 실제로 어떻게 작동하고 보이는지, 고객 문제를 해결했는지를 더 직접 평가할 가능성을 검토한다. 코딩 작업량만으로는 결과에 기여한 총가치를 설명하기 어렵다.
   4. 분기별 보정: 회사는 적어도 분기마다 스토리 포인트의 기준과 프로젝트 추정 방식을 다시 살핀다. 모델이 좋아져 작업 단위의 가치가 하락(포인트 인플레이션)하는지, 반대로 더 큰 가치를 내는지 평가하면서 산출물 보상과 실제 고객 가치의 균형을 맞춘다.

2. MetaHarness: 에이전트가 일할 수 있는 조직 기억

2.1. 코드 작성 전후의 작업을 표준화한다

1. 공유 기술과 저장소 중심 문서화

   1. 스킬에서 작업 환경으로: Tenex는 팀 공통 스킬을 표준화하려다 저장소 안의 구조화된 문서와 이를 조작하는 CLI(command-line interface)까지 확장했다. 모델은 이 도구로 계획을 만들고, 시각 자료를 생성하고, 고객에게 보여 줄 진행 보고서를 준비한다.
   2. 작업 과정 자체를 자동화: 목적은 코드 생성만 빠르게 하는 것이 아니다. 코드를 둘러싼 계획, 시각화, 고객 커뮤니케이션과 기록을 팀 전체에서 더 일관되고 자동으로 수행하는 것이다.
   3. 정형 구조를 점차 완화: 공통 계획 문서는 비슷한 형식을 유지하지만, 모델의 능력이 좋아지면서 초기보다 형식 강제를 줄였다. 에이전트의 역량이 증가하면 모든 작업을 세세한 고정 템플릿에 가두기보다 필요한 구조만 남긴다.

2. 계획·결정·진행 기록을 Git에 남긴다

   1. 에이전트의 작업 이력: 에이전트는 계획을 구현하면서 무엇을 결정했고 현재 무엇을 하고 있는지 기록한다. 계획과 결정, 진행 상황은 코드와 함께 Git에 커밋한다.
   2. 마크다운에서 HTML까지: 팀은 문서뿐 아니라 작업을 그림으로 설명하는 HTML 형태의 자료도 저장한다. CJ는 에이전트가 만드는 이런 시각적 작업물을 ‘그림책’처럼 확인한다고 설명한다.
   3. 코드만으로는 이유를 복원할 수 없다: 코드가 저장소의 기억 역할을 할 수 있다는 주장과 달리, 코드에는 왜 그 선택을 했는지, 어떤 고객 대화를 거쳤는지, 대안은 무엇이었는지 모두 담기지 않는다. 맥락과 의사결정 기록이 코드와 함께 있어야 나중에 변경의 이유를 다시 찾을 수 있다.
   4. 사람의 머릿속에서 팀의 기록으로: 결정 근거가 개인의 기억이나 대화창에만 있으면 담당자가 바뀌거나 시간이 지나면 에이전트가 맥락을 잃는다. 저장소에 남긴 기록은 팀원과 에이전트가 함께 활용할 수 있는 지속적 업무 기억이다.

2.2. 장기 과업, 도구 조합과 생산성 측정

1. 에이전트가 오래 수행할 수 있도록 업무 맥락을 준비한다

   1. ‘메타 하네스(MetaHarness)’: Tenex의 엔지니어링 워크플로와 도구를 묶어 부르는 말이다. 기술 스킬, 저장소 문서, CLI를 통해 모델이 단발성 코드 생성에서 벗어나 더 긴 과업의 계획·구현·설명까지 수행하게 한다.
   2. 팀의 기억을 한곳에 모으기: 코드와 업무 맥락이 여러 사람의 머리와 대화에 흩어져 있으면 새 작업마다 반복 설명이 필요하다. Tenex는 필요한 맥락을 한곳에 모으고 점차 더 많은 일을 에이전트가 직접 진행하게 하려 한다.
   3. 조직 규모에 따른 비용: 모든 프로젝트에 이 정도의 문서와 도구를 도입하는 것이 정답은 아니다. 단일 프로젝트를 맡은 작은 팀에는 구조화 비용이 작업 자체보다 클 수 있다. Tenex의 방식은 다수의 장기 프로젝트와 인수인계가 필요한 조직에서 더 가치가 크다.

2. 산출량은 약 두 배, 측정 기준은 계속 재검토한다

   1. 엔지니어별 월간 스토리 포인트: Tenex는 이런 프로세스가 효과가 있는지 살피는 지표로 엔지니어 한 명당 월간 평균 스토리 포인트의 추세를 본다.
   2. 올해의 약 2배 생산성: Alex와 CJ는 올해 엔지니어들이 같은 시간에 처리하는 산출량이 대략 두 배가 됐다고 평가한다. 모델이 장기 과업을 수행하기 시작한 Opus 4.5 시기를 전환점으로 들고, 현재의 Opus 5.5가 더 많은 작업을 처리한다고 말한다.
   3. 점수의 실질 가치가 변한다: 같은 스토리 포인트가 1년 전과 지금 같은 가치를 뜻하는지 확정하기 어렵다. 모델이 과업을 더 많이 처리한다면 점수 단위의 가치가 하락할 수도 있지만, 더 큰 범위와 품질을 내는 변화는 단순한 점수 인플레이션으로 환원되지 않는다.
   4. 지표는 보상 정책의 근사치: 스토리 포인트 추세는 생산성 변화를 살피는 기준이지 고객 가치의 완전한 척도가 아니다. 정기적 기준 재보정과 완성된 산출물 평가가 함께 필요한 이유다.

3. 모델 선택과 토큰 경제성

3.1. Opus 중심의 도구 조합

1. Opus 5.5가 여러 모델의 역할을 통합한다

   1. 성능·속도·비용의 균형: CJ는 현재 Opus 5.5를 빠르고 저렴하면서도 충분히 똑똑해 체크리스트를 고루 만족하는 모델로 꼽는다. 이전에는 저렴하고 빠른 모델, 고성능 모델, 특정 작업에 특화된 모델을 2~3개 병행했지만 Opus 하나가 많은 영역을 담당하게 됐다.
   2. 도구 선택의 자율성: 모든 직원이 같은 모델을 의무적으로 사용하기보다 각자 선호하는 도구를 고른다. 다만 팀의 주된 선택은 Opus 계열로 모이고 있다.
   3. Codex의 역할: 컴퓨터 사용(computer use)이나 작업 검토에는 Codex를 함께 쓰기도 한다. 한 모델이 작업하고 다른 모델이 검토하거나 같은 개발 환경에서 서로 결과를 주고받는 방식이 좋은 결과를 낸다고 CJ는 평가한다.

2. AMP의 원격 환경과 교차 모델 작업

   1. AMP 중심 작업: CJ는 AMP(대화 중 ‘AMP maxing’으로 표현)를 선호한다. 원격 실행 환경을 통해 개발 작업을 로컬 컴퓨터에서 분리할 수 있고, 모델 결과를 클라우드의 ‘orb’ 환경에서 다룬다.
   2. 구독 연결로 비용 절감: AMP가 Claude Code 구독을 연결하는 기능을 제공하면서 CJ는 비용이 약 80% 줄었다고 언급한다. 도구 구독과 모델 사용 방식이 실제 토큰 비용에 큰 차이를 만든 사례다.
   3. 교차 모델 검토: 한 orb에서 Opus가 작업한 뒤 다른 orb에서 결과를 검토하게 하는 식으로 여러 모델과 세션을 결합한다. CJ는 여러 모델과 원격 환경을 묶는 AMP의 유연성이 자신의 작업 방식에 잘 맞는다고 본다.
   4. 농담과 제품 취향: 원격 작업 공간을 쓰며 ‘orbing out’한다고 농담한다. 진행자와 CJ는 Anthropic의 클라우드 개발 환경이 AMP의 원격·협업 경험을 같은 방식으로 제공하지 못한다는 점도 짚는다. Cloud Code in the cloud나 CloudTag는 비기술 업무의 협업에는 가치가 있을 수 있지만, CJ에게는 교차 모델 작업이 가능한 AMP 쪽이 더 적합하다.

3.2. 비용 통제와 모델 품질의 한계효용

1. 토큰 비용은 인건비와 비슷한 규모까지 올라왔다

   1. 비교 기준: 진행자는 일반 기업 직원당 AI 지출을 월 10~200달러 정도로 설명하고, AI 중심 조직에서는 토큰 지출이 직원 인건비의 약 1배에서 최대 5~10배가 되기도 한다고 말한다.
   2. Tenex의 범위: Alex는 원시 토큰 지출이 직원 인건비와 대략 1:1에서 2:1 사이인 것으로 본다. 정확한 숫자를 바로 확인할 수는 없지만, AI를 핵심 작업에 쓰는 높은 지출 구간에 해당한다.
   3. 값비싼 모델에서의 전환: Tenex는 과거 Astra와 Fable 같은 모델이 좋은 결과를 냈지만 비용이 높았던 시기를 거쳤다. Opus 5.5가 성능과 가격을 함께 개선하면서 최근 비용 부담이 크게 낮아졌다.

2. ‘토큰 최대 사용’에서 작업당 ROI로 초점을 옮긴다

   1. 한때의 과소비 유인: 회사가 비용을 내는 상황에서 직원들이 토큰을 아끼지 않고 써 보는 문화가 생길 수 있다. 팀이 비효율과 한계를 직접 경험해야 절감할 수 있다는 점에서 초기의 과소비가 학습 과정이 될 수 있지만, 무제한 지출을 정당화하지는 않는다.
   2. 작업당 비용이 빠르게 낮아짐: Alex는 모델 비용 하락 때문에 6~8개월 전보다 지금은 토큰을 과도하게 사용해 회사 비용을 크게 악화시키기 어렵다고 본다. Tenex도 인원 증가에 따른 비용을 우려했지만, 단위 과업 비용 하락이 부담을 완화한다.
   3. 가격 경쟁의 압력: 진행자와 Alex는 기업용 데이터·학습 데이터 업체의 장기 시장을 토론한다. 현재 데이터 회사 매출이 AI 연구소에 크게 의존한다면, 향후 기업의 자체 미세조정(fine-tuning)이 성장 동력이 될 수 있다. 다만 프런티어 모델이 계속 좋아지는 상황에서 품질 우위를 보장하기 어렵고, 가격 역시 모델 토큰 단가가 내려가면 근거가 약해진다.
   4. 비싼 모델을 쓸 경제적 이유: 훨씬 똑똑한 모델이 항상 정당화되지는 않는다. 스프레드시트의 셀 몇 개를 옮기는 작업에 10배 비싼 모델을 쓰는 것이 합리적인지 따져야 한다. 더 값싸고 성능이 좋은 모델과 오픈소스의 경쟁이 작업당 비용을 계속 낮출 수 있다.

4. 기업 AI 확산의 간극: 배포보다 업무와 권한이 어렵다

4.1. 기업의 단계별 도입률

1. 범용 LLM 도입은 보편화 단계에 가깝다

   1. 조사 대상: 아래 수치는 Tenex가 현재 대화하는 약 100개 기업을 바탕으로 Alex가 제시한 대략적인 현장 추정치다. 모든 기업을 대표하는 통계 조사는 아니다.
   2. 도구 보급 약 90%: 대화 대상 기업의 약 90%가 직원들에게 Claude나 Codex 같은 범용 LLM을 배포했다.
   3. 교육·활용 훈련 약 60%: 실제로 기능과 사용 기술을 가르치는 기업은 약 60%다. 도구만 배포하고 직원들이 알아서 익힐 것이라 기대하는 회사가 적지 않다. Alex는 기술 배포 못지않게 교육과 활성화(enablement)가 중요하다고 본다.

2. 코딩 에이전트에서 비엔지니어링 에이전트로 갈 때 급락한다

   1. 엔지니어링 조직의 코딩 에이전트 약 50%: 엔지니어링·제품 조직에 코딩 에이전트를 도입한 기업은 약 절반으로, 청중이 예상하는 70~80%보다 낮다. 도입했다고 해도 실제 사용이 제한적이면 사실상 도입하지 않은 것과 다르지 않다.
   2. 비엔지니어링 프로덕션 에이전트 약 5%: 직원 1,000명 이상 기업에서 소프트웨어 개발 이외의 실제 업무를 운영 환경에서 처리하는 에이전트는 약 5%에 그친다고 추산한다. 지능형 모델의 잠재력과 기업의 반복 업무에 배치된 활용 사이에 가장 큰 격차가 있다.
   3. ‘에이전트의 해’와 현장의 차이: 시장은 반복적으로 에이전트의 해라고 말하지만, 기업은 뒤처질지 모른다는 불안(FOMO) 때문에 유행하는 프로젝트를 먼저 시도하기도 한다. 실제 반복 업무를 운영하려면 기술 데모를 넘어 데이터, 책임, 평가 체계를 풀어야 한다.

4.2. 권한과 프로세스 표준화가 선행 조건이다

1. 데이터 접근 권한을 제어할 통제면이 필요하다

   1. CIO·CISO의 RBAC 문제: 직원들이 Claude나 Codex를 쓰면서 사내 데이터를 읽게 되면 역할 기반 접근 제어(RBAC)와 데이터 권한 관리가 복잡해진다. 누가 무엇을 읽고 쓸 수 있는지 쉽게 제어할 수단이 없으면 보안 책임자가 위험을 감당하기 어렵다.
   2. 게이트웨이 제품화: Tenex는 처음에는 기업별 맞춤형으로 권한과 데이터 관리를 구현했다. 반복되는 수요를 확인한 뒤 자체 게이트웨이 솔루션으로 제품화하고 있다.

2. 존재하지 않는 절차는 자동화할 수 없다

   1. 40명이 40가지 방식으로 처리하는 업무: 같은 직무를 맡은 40명이 각자 조금씩 다른 절차로 일하면 에이전트가 무엇을 정답으로 삼아야 하는지 알 수 없다. 사람마다 다른 결과와 예외를 평가할 기준이 없다면 자동화는 불안정하다.
   2. 보조에서 백그라운드 자동화로: 먼저 직원들과 함께 도구를 사용하고 각자의 흐름을 이해해 공통 절차를 만든다. 그런 다음 에이전트가 작업을 미리 수행하고 사람이 검토·반려하는 운영 방식으로 옮긴다. 사람이 에이전트 관리자로 역할을 바꾸는 과정도 이 단계에서 시작된다.
   3. 평가 기준과 가치 입증: 표준 절차는 에이전트가 올바르게 일했는지 확인하는 평가(evals)를 만들 수 있게 한다. 프로세스가 정의되어야 자동화 품질과 고객 가치를 함께 입증할 수 있다.

5. 수직형 AI와 자체 소프트웨어: 기능보다 워크플로가 방어력이다

5.1. 수직형 제품의 사업성 논쟁

1. Tenex가 보는 수직형 AI의 구조적 위험

   1. 고객별 ‘하나뿐인’ 요구: 기업은 자신의 업무 방식에 맞춘 일대일(one-of-one) 솔루션을 기대한다. 수직형 제품이 고객별 맥락을 맞추려면 소프트웨어만 파는 대신 전방 배치 엔지니어(FDE)를 투입해야 해 서비스와 소프트웨어의 경계가 흐려지고, 소프트웨어 마진을 유지하기 어렵다.
   2. 조직의 관성과 통합 복잡성: 실제 기업 현장에는 데이터와 시스템, 승인자, 사용자 관행이 복잡하게 얽혀 있다. AI 제품이 기능 하나를 제공하는 것만으로 이 시스템을 교체하거나 전사적으로 확산하기 어렵다.
   3. 프런티어 모델의 기능 흡수: 특정 직무의 AI 에이전트가 수행하는 작업이 범용 모델의 기능으로 흡수될 수 있다. 자체 구축, 수평형 도구의 확장, 모델 성능 개선이 동시에 일어나면 단일 에이전트 기능은 독립 제품으로 남기 어렵다.

2. 데이터·인터페이스·업무 관행은 여전히 방어력이 될 수 있다

   1. Harvey·Legora·OpenEvidence: 진행자는 법률용 Harvey와 Legora, 의료용 OpenEvidence 같은 사례를 든다. 특화 데이터와 규제·컴플라이언스, 도메인 전용 인터페이스가 범용 모델과 차별화될 수 있다고 주장한다.
   2. 마지막 구간을 위한 UI: 특정 직무에 맞는 검토 표, 입력 방식, 결과 확인 기능 등은 같은 모델을 쓰더라도 사용자가 일을 완결하는 데 필요한 인터페이스다. 제품이 고객의 마지막 작업 단계(last mile)를 세심하게 해결하면 범용 채팅 인터페이스만으로 대체되기 어렵다.
   3. 습관과 통합의 누적 효과: 사람들은 이미 익숙한 도구를 쓰고 동료와 정보를 교환하며 다른 시스템에 연결된 업무 흐름을 쉽게 버리지 않는다. Bloomberg Terminal은 시장 데이터를 다른 곳에서 얻을 수 있어도 데이터, 뉴스, 거래 도구, 동료와의 메시지를 한곳에 통합해 사용 습관을 만든 사례로 언급된다. 연간 5만 달러 수준의 높은 비용에도 도구가 지속되는 이유를 데이터 독점만으로 설명할 수 없다.
   4. 일반 제품 안의 프리미엄 작업 환경: Gmail이 기본 메일 도구여도 이메일에 많은 시간을 쓰는 사람은 단축키와 속도에 특화된 Superhuman을 선택할 수 있다. 진행자는 월 30달러를 내고 이메일을 덜 신경 쓰게 되는 경험을 예로 든다. 모든 수직형 도구가 거대한 독점 기업이 될 필요는 없으며, 충분한 시장이 형성될 수 있다.

5.2. 에이전트 단품과 업무 플랫폼을 구분한다

1. 에이전트가 제품인지, 더 나은 업무 도구의 일부인지가 중요하다

   1. 위험이 큰 에이전트 단품: 특정 직무 작업을 대신 수행하는 에이전트만으로 구성된 제품은 모델이 좋아질수록 수평형 도구에 흡수될 수 있다. 전략적인 규제·데이터 장벽이 없다면 고객이 범용 에이전트에서 비슷한 기능을 직접 만들 가능성도 커진다.
   2. 더 지속적인 워크플로 제품: 고객이 실제로 일하는 앱과 절차를 개선하고, 그 위에 에이전트를 얹는 제품은 업무 방식 자체를 바꿀 수 있다. 제품의 방어력은 ‘우리 에이전트가 있다’보다 사용자가 일을 수행하는 기반이 될 수 있는지에 달려 있다.
   3. 에이전트와 데이터의 인터페이스 경쟁: 고객이 개별 업체의 에이전트를 계속 쓰기보다 자신이 선호하는 소수의 에이전트에 각 제품의 데이터를 연결할 가능성도 있다. Salesforce가 에이전트를 직접 소유하기보다 API와 MCP를 제공하는 방향으로 움직이는 사례가 논의된다. 장기적으로 일부 사업자는 주 인터페이스를 소유하고 다른 제품은 데이터·도구로 연결될 수 있다.

2. 시장 총량과 개별 점유율을 분리해 본다

   1. 도구 수요는 커진다: 여러 산업과 직무가 더 나은 소프트웨어를 원하므로 전체 시장이 확대될 수 있다. 수직형과 범용형 가운데 하나가 전부를 가져가는 구도보다 각각 어느 몫을 차지할지의 문제일 수 있다.
   2. 경쟁을 가르는 질문: 고객이 원하는 특화성이 데이터에 있는지, 규제 준수인지, 인터페이스인지, 협업·통합인지, 실제 업무 절차인지 나눠야 한다. 이 조건이 모호한 상태에서 AI 에이전트를 제품의 전부로 내세우면 모델 개선과 함께 가치가 약해질 위험이 있다.

6. Kill My SaaS: 비용 절감만으로 구축 결정을 내리지 않는다

6.1. 대회 결과가 보여 준 평가의 간극

1. 사람이 고른 우승작과 AI 순위는 달랐다
   1. 문제의 배경: 진행자는 컨퍼런스 연사 관리용 SaaS를 대체하는 ‘Kill My SaaS’ 프로젝트를 소개한다. 해당 도구는 연간 약 43,000달러의 견적을 받았고, 외부 제작자가 에이전트를 활용해 대체 제품을 만들도록 72개 제출물을 모았다.
   2. 평가 결과: 인간 심사위원이 선정한 우승팀은 AI 심사 순위에서 19위였다. 정해진 시나리오를 통과하는지 자동으로 확인하는 평가와 사람이 실제로 쓰고 싶어 하는 제품인지 판단하는 평가는 서로 다르다.
   3. 평가 설계의 시사점: 기능 체크리스트를 통과한 결과가 사용성·신뢰·현장 적합성까지 보장하지 않는다. 에이전트가 작성한 소프트웨어의 검증에는 정형 테스트뿐 아니라 인간의 맥락 판단이 필요하다.

6.2. 빌드 대 바이의 비용과 기회비용

1. 비용 절감은 하나의 근거지만 전체 사업성은 아니다

   1. 초기 제작비: 진행자는 약 1,000달러를 들여 기존 도구를 대체하는 제품을 만들었다고 말하며, 다음 컨퍼런스에 실제 투입할 계획을 설명한다. 단순 계산으로는 연 43,000달러 견적과 큰 차이가 있다.
   2. 유지보수라는 반대 비용: Alex는 특히 대기업일수록 이미 자리 잡은 시스템을 걷어내는 일이 비싸고 위험하다고 지적한다. 데이터나 업무가 잘못 이전되면 수억·수십억 달러가 걸릴 수 있어 Salesforce나 SAP를 쉽게 교체하지 않는다.
   3. 규모와 핵심성의 판단: 중간 규모 SaaS라면 연간 지출이 기업의 매출이나 비용에서 실제로 얼마나 큰지, 자체 구축이 엔지니어의 시간을 차지할 가치가 있는지 따져야 한다. 비용 절감 폭이 커도 핵심 사업과 무관한 도구를 계속 고치는 인지 부하(cognitive load)가 더 클 수 있다.
   4. 소프트웨어가 덜어 주는 일: 구매 소프트웨어의 가치는 기능뿐 아니라 직접 유지·개선하지 않아도 되는 부담을 없애는 데 있다. 회사가 자체 개발을 선택하면 새로운 기능을 얻는 대신 운영 책임을 떠안는다.

2. 제품 통제권과 개선 속도는 자체 구축의 공격적 가치다

   1. 나쁜 제품을 계속 쓰는 비용: 진행자의 팀은 기존 제품이 오랫동안 평범한 사용자 경험을 제공했으며, 연사와 운영자 모두 더 나은 흐름을 원했다고 말한다.
   2. 분 단위 반복 개선: 자체 도구를 보유하면 고객이자 운영자인 팀이 개선점을 발견한 뒤 외부 공급사의 수개월 일정에 기다리지 않고 몇 분 안에 수정할 수 있다. 가치는 비용 방어뿐 아니라 업무 경험을 크게 개선할 기회에 있다.
   3. 조직 민첩성의 차이: 스타트업이나 성장 중인 중견기업은 내부 요구에 맞춰 도구를 만드는 데 더 민첩할 수 있다. 반면 대기업은 조직 구조와 기존 시스템이 깊게 자리 잡아 작은 SaaS를 10배 나은 자체 제품으로 쉽게 재구축하기 어렵다.
   4. Tenex의 자체 도구 사례: Alex는 Tenex도 CRM과 내부 운영용 OS를 처음부터 구축했다고 언급한다. 모든 회사를 위한 범용 전략이라기보다 사업의 필요, 구축 역량, 유지 부담을 비교해 결정한 사례다.

7. 일자리 재편과 뉴욕의 AI 생태계

7.1. 자동화의 결과를 해고와 재배치로 나눠 본다

1. AI는 일을 보완하지만 특정 직무를 실제로 없앨 수도 있다

   1. 콜센터 사례: Alex는 콜센터가 줄고 AI가 더 많은 응대를 맡기 시작했다는 업계 신호를 언급한다. 한 사람이 오랫동안 쌓은 직무가 자동화되면 단순한 도구 개선이 아니라 생계와 정체성에 영향을 준다.
   2. 재배치의 논리: Tenex는 에이전트가 반복 업무를 맡으면 직원의 시간을 다음 문제로 옮긴다는 접근을 고객에게 설명한다. 특히 큰 기업에는 처리할 문제가 계속 생기므로 자동화가 곧 남은 일이 전혀 없다는 뜻은 아니라는 논리다.
   3. 전문성을 더 넓은 역할로 이동: 스프레드시트의 셀을 반복해서 다루던 재무 담당자는 자금 배분과 사업 전략을 고민하고, 팀을 가로질러 협업하는 역할로 이동할 수 있다. 업무 단위를 수행하는 전문 지식을 더 큰 조직 문제 해결에 활용한다는 구상이다.

2. 재교육은 고용주와 개인 모두의 책임이다

   1. 기업의 재배치·훈련 의무: 자동화로 얻은 시간을 성장에 쓰려면 기업이 다음 과제를 만들고 직원의 기술 전환을 지원해야 한다. ‘AI가 싫은 일을 없애 준다’는 낙관만으로 업무 전환이 저절로 해결되지는 않는다.
   2. 개인의 주체성: Alex는 직원도 자기 업무가 몇 년 안에 얼마나 안정적일지, 대체 가능성을 낮추려면 어떤 기술을 배워야 할지 스스로 살펴보고 행동할 여지가 있다고 말한다.
   3. 고통을 지우지 않는 담론: 사람들은 좋아하든 싫어하든 생계를 위해 일을 선택하는 경우가 많다. 자동화가 일자리를 대체하는 피해를 ‘사람을 반복 업무에서 해방한다’는 말만으로 가리면 당사자의 현실을 무시하게 된다.

7.2. 뉴욕은 상업과 AI 확산이 만나는 시장이다

1. 샌프란시스코보다 작지만 기업 현장과 가깝다

   1. AI 대화의 밀도 차이: CJ는 뉴욕에도 AI에 집중하는 인재와 회사가 있지만, AI에 관한 대화가 도시 전체를 둘러싼 듯한 샌프란시스코의 규모와는 다르다고 말한다. Tenex 내부와 연결된 고객·기술 커뮤니티는 샌프란시스코에 가까운 작은 생태계다.
   2. AI Engineer의 농축된 분위기: 컨퍼런스 현장은 기술을 받아들이는 사람의 밀도가 높아 샌프란시스코 분위기를 압축해 놓은 것처럼 느껴진다. 진행자는 그런 청중이 기술의 최전선에 산다는 느낌을 준다고 언급한다.
   3. AI 홍보의 일상화: 예전에는 AI 광고판이 일부러 반발을 부르는 장치처럼 보였지만, 이제는 뉴욕 거리에서 AI 광고가 자연스럽게 늘고 있다. AI가 도시 문화 안에 들어오는 과정을 보여 주는 징후다.

2. 뉴욕의 상업 기반은 AI 확산의 경제적 기회다

   1. 기업 고객과의 근접성: Alex는 뉴욕이 AI 생태계 규모에서는 샌프란시스코보다 작아도 상업 활동과 고객 기반은 그만큼 크거나 더 클 수 있다고 본다. 실제 사업 현장과 만나 기술이 GDP에 미치는 효과를 키우기 좋은 위치다.
   2. ‘미래’와 고객 현실을 연결한다: Tenex는 샌프란시스코 인재를 뉴욕 고객과 만나게 해 실제 문제를 확인하고 현실 감각을 얻도록 한다. 뉴욕의 강점은 AI 개발자만 모이는 데 있지 않고, 기술이 기업 업무에 실제로 확산될 수 있는 데 있다.
   3. 지역 허브를 키우려는 목표: Tenex는 뉴욕의 AI 커뮤니티를 키우고 더 많은 사람이 미래 기술을 일상과 업무에 적용하도록 만들고 싶어 한다. 회사가 뉴욕에서 AI를 하는 이유에는 고객과의 거리, 상업적 임팩트, 생태계 확장이라는 세 요소가 함께 있다.

7.3. Tenex의 채용과 내부 ‘특별 프로젝트’

1. 75명 규모의 적용 AI 회사

   1. 채용 직군: Tenex는 고객 현장에 배치되어 문제를 해결하는 포워드 디플로이드 엔지니어(forward deployed engineer)와 고객 프로젝트를 이끄는 AI 전략가를 계속 채용한다. AI 전략가는 기술 컨설턴트 역할을 맡는다.
   2. 기업의 AI 네이티브 전환: Tenex는 AI를 도입했지만 성과가 나지 않는 기업에 기술 구축과 조직 전환을 제공한다. 초창기 AI 기반 개발 대행에서 출발해 현재는 전사 AI 전환 서비스를 요청받는다.

2. CJ의 특별 프로젝트는 사내 도구와 배포 기반을 만든다

   1. MetaHarness의 프런티어 실험: CJ는 고객 납품 이외의 특별 프로젝트로 모델의 최첨단 기능을 시험하고, 에이전트가 더 잘 일하도록 필요한 도구를 제공한다.
   2. 백그라운드 에이전트 플랫폼: 내부 플랫폼을 만들어 반복 업무용 에이전트를 기업에 배포하고, 앞서 확인한 권한 관리와 IT 통합의 복잡한 문제를 해결하려 한다.
   3. 고객 기술 공유: 진행자는 Tenex가 해결책을 확보하면 Latent Space 블로그에 경험을 공유하는 게스트 글을 환영한다고 말하며 대화를 마친다.

주요 발언 모음

“존재하지 않는 프로세스는 자동화할 수 없다.”

“AI는 놀라운 기술이지만, 원재료인 지능(raw intelligence)이다. 경제 전반에 확산하는 마지막 구간이 가장 어려운 문제다.”

“내 산출물은 좋아지고 빨라졌는데, 시간당으로 고객에게 청구하니 결국 수입은 줄었다.”

“코드만으로는 왜 그런 결정을 했는지 알 수 없다. 맥락과 결정은 저장소에 남아야 한다.”

“같은 시간에 엔지니어가 처리하는 양은 대략 두 배가 됐다.”

“문제는 반복 작업을 없애는 것에서 끝나지 않는다. 그 사람들을 다음으로 가장 중요한 문제에 배치해야 한다.”

핵심 데이터 & 수치

• 약 18개월: Tenex 사업을 시작한 뒤 이번 대화 시점까지의 기간이라고 Alex가 설명했다.
• 75명: Tenex 전체 인원. 직원의 약 90%가 엔지니어 또는 기술 컨설턴트 성격의 AI 전략가다.
• 고객 구성 50:50: 약 절반은 Fortune 2000 기업, 나머지 절반은 매출 1억~5억 달러 규모의 중견기업이다.
• 약 4배: Tenex 내 최고 보상 엔지니어와 최저 보상 엔지니어 사이의 대략적인 격차다.
• 약 90%: 모델에 올바른 고객 맥락을 주면 해결책의 상당 부분에 도달할 수 있다는 CJ의 설명이다.
• 약 2배: 올해 같은 시간에 처리하는 엔지니어 산출량 증가 추정치다. Opus 4.5의 장기 과업 수행 능력 개선에서 Opus 5.5까지의 변화를 배경으로 한다.
• 분기별 최소 1회: 스토리 포인트 기준과 프로젝트 추정 방식을 재검토하는 주기다.
• 직원당 토큰 지출 1~2배: Tenex가 원시 토큰에 지출하는 비용과 직원 인건비를 비교한 대략적 비율이다.
• 기업 AI 도입 추정: 약 100개 기업 대화 상대 중 범용 LLM 보급 90%, 교육·활성화 60%, 엔지니어링 조직 코딩 에이전트 50%, 비엔지니어링 프로덕션 에이전트 5%다. 현장 추정치이며 전체 시장 통계가 아니다.
• 약 1,000명 이상: 비엔지니어링 업무의 프로덕션 에이전트 도입률 5%를 언급한 기업 규모 기준이다.
• 약 40명: 동일 직무라도 사람마다 프로세스가 달라질 수 있음을 설명하기 위해 든 예시 인원이다.
• 약 80% 절감: AMP에서 Claude Code 구독을 연결하는 방식으로 CJ가 언급한 비용 절감 폭이다.
• 6~8개월: 토큰 과소비가 지금보다 회사 비용에 큰 위협이 될 수 있었던 시기를 가리킨다.
• 연 43,000달러 / 약 1,000달러: 연사 관리 SaaS의 견적과 대체 제품을 만든 비용이다. 실제 장기 운영비와 유지보수 비용은 별도로 따져야 한다.
• 72개 제출물 / AI 심사 19위: Kill My SaaS 대회의 제출 수와 인간 심사 우승팀의 AI 평가 순위다.
• 수억~수십억 달러 위험: 대기업의 핵심 시스템 교체가 실패할 때 걸릴 수 있는 사업상 위험을 설명한 규모다.
• 월 30달러 / 연 5만 달러: Superhuman과 Bloomberg Terminal을 프리미엄 업무 도구의 사례로 들며 언급한 가격대다.

결론 및 시사점

1. 보상은 투입 시간이 아니라 검증된 고객 결과를 향하되, 비코딩 기여도 포함해야 한다. 스토리 포인트는 유용한 기준점이지만 문제 정의·설계·고객 조율을 포착하지 못하므로 완성된 결과의 작동과 품질을 함께 평가해야 한다.
2. 에이전트 생산성은 모델만으로 나오지 않는다. 계획, 결정 근거, 고객 대화에서 얻은 맥락, 진행 상황을 저장소에 남겨야 장기 과업과 인수인계가 가능해진다.
3. 기업의 AI 도입 순서는 배포 다음에 교육, 권한, 표준 업무, 평가 체계를 세우는 것이다. 비정형 프로세스를 그대로 자동화하면 에이전트는 무엇이 올바른지 판단할 수 없다.
4. 모델 선택은 최고 성능이 아니라 작업당 가치로 결정해야 한다. 저렴한 모델이 충분한 품질을 낸다면 더 비싼 추론 능력은 비용을 정당화하지 못할 수 있다.
5. 수직형 AI의 지속성은 에이전트 자체보다 데이터·컴플라이언스·인터페이스·통합·습관·워크플로에 달려 있다. 제품이 업무의 기본 장소가 되거나 범용 에이전트가 쉽게 복제할 수 없는 마지막 구간을 해결해야 한다.
6. 자체 소프트웨어는 절감액과 유지보수 비용을 같이 계산한다. 나쁜 사용자 경험을 개선하고 빠르게 반복할 가치가 큰 조직에는 구축이 유리할 수 있지만, 핵심성과 무관한 시스템은 구매가 인지 부담을 줄일 수 있다.
7. 자동화 이후에는 재배치와 재교육이 중요하다. 기업은 다음 문제를 만들고 인력을 지원해야 하며, 개인도 자신의 업무 안정성과 필요한 기술 변화를 주도적으로 살펴야 한다.
8. 뉴욕의 AI 기회는 기술 밀도보다 상업 현장과의 연결에 있다. 고객과 가까운 곳에서 모델의 가능성을 실제 업무·경제적 가치로 바꾸는 것이 AI 네이티브 전환의 마지막 구간이다.

핵심 요약 (20줄)

Tenex는 엔지니어 보상을 투입 시간이 아니라 고객에게 전달한 산출물에 연동한다.

시간당 과금으로 일하던 CJ Hess는 AI로 생산성이 높아져도 청구 시간이 줄어드는 역설을 겪었다.

Tenex의 성과 보상은 엔지니어별 생산성 차이를 드러내며 최고·최저 보상 격차는 약 4배다.

스토리 포인트 부풀리기보다 건축 설계와 고객 문제 파악 같은 비코딩 노동의 보상이 더 어려운 과제다.

AI 전략가는 고객 유지와 성장에 책임져 부실한 점수 획득보다 실제 고객 가치를 우선하도록 견제한다.

고객의 지식을 듣고 모델이 쓸 수 있는 맥락으로 바꾸는 일이 엔지니어 역할의 큰 부분이 되고 있다.

MetaHarness는 공통 스킬, 저장소 문서, CLI를 결합해 계획부터 구현과 고객 보고까지 표준화한다.

계획, 의사결정 근거, 진행 기록을 코드와 함께 Git에 남기면 에이전트와 팀이 조직의 맥락을 재사용한다.

Tenex는 엔지니어 한 명당 산출량이 올해 대략 두 배가 됐다고 평가하며 스토리 포인트를 분기마다 보정한다.

Opus 5.5는 속도와 가격, 성능의 균형을 제공하고 Codex와 AMP는 검토와 원격 작업을 보완한다.

Tenex의 원시 토큰 지출은 직원 인건비의 약 1~2배이며 더 저렴한 모델이 비용 부담을 낮추고 있다.

Tenex가 대화하는 기업 중 범용 LLM 보급은 90%지만 비엔지니어링 프로덕션 에이전트는 약 5%에 그친다.

에이전트 운영에는 직원별 데이터 권한을 통제하는 게이트웨이와 검증 가능한 업무 기준이 필요하다.

사람마다 다른 절차를 먼저 표준화해야 에이전트가 반복 업무를 안정적으로 수행하고 평가받을 수 있다.

수직형 AI는 데이터와 규제, 특화 인터페이스, 업무 통합을 갖출 때 범용 모델에 흡수되지 않을 수 있다.

에이전트 단품보다 사용자가 실제로 일하는 워크플로와 인터페이스를 개선하는 제품이 더 오래 지속될 가능성이 있다.

연 43,000달러 SaaS를 약 1,000달러로 대체한 사례도 유지보수 비용과 실패 위험을 함께 계산해야 한다.

대체 소프트웨어의 인간 심사 우승팀은 AI 평가에서 19위여서 기능 테스트와 사용성 판단의 차이를 보여 줬다.

자동화는 일자리를 대체할 수 있으며 기업의 재배치·재교육과 개인의 기술 전환이 함께 필요하다.

뉴욕은 샌프란시스코보다 AI 생태계는 작아도 기업 고객과 가까워 기술의 상업적 확산을 키울 수 있다.