조직의 AI 도입 3단계: Stream, Shape, Scale과 단계별 평가법

#ai
#agent
#agentic-development
#harness-engineering
#organization
#token-economics

2026년 06월 15일 작성

TL;DR

토큰 가격과 토큰당 비즈니스 가치 사이의 괴리를 줄이는 것이 하네스 엔지니어링이고, 조직의 AI 도입은 Stream → Shape → Scale 세 단계를 거칠 수밖에 없으며 앞선 모든 투자는 마지막 단계에서 두고두고 회수된다.

시작하며

개인적으로는, 요즘 회사들이 AI를 도입하는 모습이나, AI 회사들이 도입을 가이드하는 모습이나, 둘 다 어딘가 향방 없이 흘러가는 경향이 있다고 생각한다.

OpenAI와 Anthropic은 이것에 대한 명확한 노하우가 있지만 의도적으로 풀지 않는 쪽에 가깝다고 생각한다. 에이전트와 하네스 관점에서는 복제가 너무 쉽기 때문에, 이건 이해가 되는 부분이다.

정작 의문인 쪽은 나머지 회사들이다. 왜 그런 식으로 일하고, 왜 적절히 가이드하지 못하는 걸까.

답을 풀기 위해 먼저 짚어야 할 전제가 하나 있다. 지금 에이전트는 토큰 가격과 토큰당 비즈니스 가치 사이의 괴리가 심하다. 그리고 이 간극을 줄여주는 것이 바로 하네스(컨텍스트를 포함한) 엔지니어링이다.¹

이 전제를 깔고 보면, 향방 없이 흘러가는 AI 도입의 정체가 비교적 또렷하게 보인다.

하네스를 대하는 관점의 차이라는 것이다.

1. “AI를 쓰세요, 그런데 토큰은 최소로”의 함정

하네스에 대한 이해없이 AI만 도입하고 “AI는 쓰되 토큰은 최소로 쓰라”고 던져두면 어떻게 될까?

여기엔 자기모순이 숨어 있다. 하네스를 구축하는 일 자체가 토큰을 많이 태우는 작업이기 때문이다. 하네스는 한 번에 완성되지 않고, 아래 사이클을 반복하며 깎여 나간다. 그리고 이 한 바퀴 한 바퀴가 모두 토큰을 태운다.

하네스 업데이트 사이클 — 코드 생성 → 디버깅 → 리팩터링 → 하네스 업데이트를 순환한다

그런데 토큰 압박이 걸리면 사람들은 정확히 그 반대로 움직인다. 토큰이 많이 드는 하네스 구축은 미뤄두고, 토큰을 적게 쓰면서 눈앞에 떨어진 단기 작업을 쳐내는 쪽을 택한다. 평가도 압박도 단기 사용량을 향해 있으니, 합리적인 선택이다.

문제는 그렇게 단기 작업만 쳐내는 동안 토큰당 비즈니스 가치는 조금도 개선되지 않는다는 점이다. 어제 누군가 한 번 겪은 시행착오를, 오늘 옆자리 동료가 똑같이 토큰을 태워가며 다시 겪는다. 하네스가 없으니 동일한 작업에 토큰이 과다 소모되는 경향이 구조적으로 그대로 남는다.

즉 토큰을 아끼라는 압박은, 정작 그 괴리를 줄여줄 유일한 투자(하네스 구축)를 가장 먼저 포기하게 만든다. 줄여야 할 건 개인의 단기 사용량이 아니라 조직이 반복하는 시행착오 그 자체인데, 압박은 정반대 방향을 가리키는 셈이다.

몇몇 소식이 빠른 사람은 하네스를 만들어서 쓰는 사람도 있지만 그걸 전파하거나 다른 사람의 업무에 같은 방식으로 하네스를 만드는 것은 또 다른 이야기 이므로 자신의 업무 정도만 하네스를 구축해둔다.

즉 현재 대부분의 조직이 흔히 빠지는 착각은, 코딩 에이전트를 도입하면 모든 문제가 자동으로 풀린다는 기대다. 하지만 하네스가 제대로 갖춰지지 않으면, 모델이 좋아져도 시행착오 자체가 줄기보다는 시행착오에서 사람이 확인을 한 번 덜 누르는 정도로 바뀔 뿐이다. 괴리의 본질은 그대로 남는다.

이런 상태에서 AI 도입의 성과를 평가하겠다고 하면, 직원들 입장에서는 기가 찰 노릇이다. 즉, 평가의 대상은 사람이나 에이전나 자체가 아니라 하네스여야 하는데, 정작 하네스가 없는 상태에서 사람과 성과만 평가하고 있는 셈이다.

뭘 평가해야하는지 어떻게 평가해야하는지 전혀 이해못하는 리더들이 자신들의 KPI 만을 위해서 공부없이 신기술을 대할 때 자주나오는 현상이며, 특히 디자인, 예술, GenAI 같이, 주관적인 기준의 평가가 대세인 분야에서 더 자주 나타나는 것 같다.

2. 도입을 설명하는 3단계 렌즈 — 3S

그럼 어떻게 도입하고 어떻게 평가하는게 현실적인가?

여기서 잠깐 켄트 벡(Kent Beck)의 3X 모델²을 빌려오자.

3X는 모든 제품과 비즈니스를 수익 곡선의 모양에 따라 세 단계로 나눈다. 가치 있는 아이디어를 싸고 빠른 실험으로 찾는 Explore(곡선이 거의 평평하다), 검증된 아이디어를 폭발적으로 키우는 Expand(곡선이 가파르게 치솟는다), 성숙한 제품에서 효율과 수익을 짜내는 Extract(곡선이 평탄해진다).

핵심은 단계마다 곡선이 다르니 엔지니어링 전략도 달라야 한다는 통찰이다. Explore에서 적절한 것이 Extract에서는 낭비고, 그 반대도 마찬가지다.

Kent Beck의 3X 곡선 — Explore는 평평, Expand는 급상승, Extract는 평탄화

나는 에이전틱 프로덕트를 도입하는 과정도 이런 식으로 세 단계로 나눠 본다.

다만 여기서 단계를 가르는 곡선은 수익이 아니라 토큰 가격과 토큰당 생산하는 비즈니스 가치의 괴리다.

3X의 결을 빌려, 나는 이걸 3S — Stream · Shape · Scale이라고 부른다. 이것이 현재 내가 조직 관점에서 AI를 보는 렌즈다.³ 당연히 아직 검증되지 않았고 생각만 정리해보고 있다.

flowchart LR
    A["1. Stream<br/>데이터를 흘려보낸다<br/>(외부 데이터 → 텍스트)"] --> B["2. Shape<br/>하네스로 형태를 잡는다<br/>(컨텍스트 · 피드백 루프)"] --> C["3. Scale<br/>가치를 확장한다<br/>(goal만 주면 완료)"]
    A -. "거의 평평, 완만한 우상향" .-> A
    B -. "나선형 · 계단식 exponential" .-> B
    C -. "누적 가치 · 괴리 최소화" .-> C
    classDef s1 fill:#f5f5f5,stroke:#bbb;
    classDef s2 fill:#fff3d6,stroke:#e8a;
    classDef s3 fill:#cfe8cf,stroke:#3a3;
    class A s1;
    class B s2;
    class C s3;

세 단어가 모두 S-로 시작하는 건 3X가 Ex-로 운율을 맞춘 것을 따라 한 의도적인 장치다. 입에 붙어야 렌즈로 오래 쓰인다.

3X의 곡선을 그대로 빌려, 세로축을 ‘토큰당 비즈니스 가치’로 바꿔 그리면 3S의 모양도 같은 S자 곡선이 된다.

공교롭게도 낮게 출발해 중간에 급격히 오르고 끝에서 완만해지는 기조는 똑같다. 둘 다 초반은 보상이 안 나오는 선행 투자 구간이고, 후반은 상한에 부딪혀 평탄해지기 때문에 모양이 같을 수밖에 없다.

다만 세 구간 중 두 곳에서 3S만의 차이가 드러난다.

Stream에서 3S는 거의 평평하게 출발한다. 비용만 잔뜩 들고 가치는 좀처럼 드러나지 않지만, 정렬해둔 데이터가 다른 곳에서 조금씩 재활용되기 때문에 아주 완만하게나마 우상향한다.

급상승 구간인 Shape가 가장 큰 차이다.

3X의 Expand가 수요에 올라타 매끄러운 지수 곡선으로 치솟는 것과 달리, 3S의 Shape는 계단을 밟듯 울퉁불퉁하게 올라온다. 하네스 구축이 나선형이기 때문이다.

컨텍스트와 피드백 루프를 한 바퀴 돌 때마다 한 칸 올라가고, 그 사이에는 다음 칸을 준비하는 정체 구간이 끼어든다. 계단 한 칸 = 나선 한 바퀴인 셈이다.

뒤에서 다룰 “모델이 좋아져도 하네스가 없으면 시행착오가 줄지 않는다”는 이야기도 결국 이 그림에서 나온다. 하네스가 없으면 계단의 수직 부분(한 칸 올라가는 순간) 없이 수평 부분(정체)만 반복하는 셈이기 때문이다.

마지막으로 Scale에서는 끝없이 치솟는 게 아니라 ‘괴리 0’이라는 이론상 상한에 수렴하며 평탄화된다. 토큰당 가치는 아무리 좋아져도 괴리가 0인 지점을 넘을 수 없기 때문이다(끝없이 불어나는 건 토큰당 효율이 아니라 그 위에 쌓이는 누적 가치 쪽이다).

3S 곡선 — Stream은 거의 평평한 완만한 우상향, Shape는 계단식 상승, Scale은 상한에 수렴하며 평탄화

이 곡선의 세로축은 사실 HITL 제거율의 다른 이름이다. 사람이 매번 끼어들어 확인하고 고쳐야 하면 그 개입 비용이 토큰당 가치를 깎고, 그 개입이 사라질수록 토큰 1단위가 온전히 가치로 전환되기 때문이다. 즉 괴리가 줄어든다는 건 곧 HITL이 제거된다는 뜻이다.

그래서 곡선의 세 구간은 HITL 렌즈로도 그대로 읽힌다. Stream에서 거의 평평한 건 데이터 차원이 부족해 HITL을 아직 제거할 수 없기 때문이고, Shape에서 계단을 한 칸 오르는 건 AHE가 하네스로 HITL을 한 겹씩 걷어내는 순간이다. 결국 AHE가 Shape에서 하는 일의 본질은 하네스를 통한 HITL 제거다. 그리고 Scale이 상한에 수렴하는 것도 같은 이유다 — HITL은 0 밑으로 내려갈 수 없으니, 괴리 0이란 결국 HITL 0이고 곡선은 그 지점에서 평탄해질 수밖에 없다.

1단계 — Stream (Data Streamlining)

에이전트는 모델이 외부 환경과 소통할 수 있게 해주는 애플리케이션이고, 외부 환경과 소통하는 수단은 도구다.

그런데 외부 환경이라는 건 결국 텍스트로 변환할 수 있는 데이터일 뿐이다.

결국 외부의 어떤 데이터든 텍스트로 변환해서 에이전트가 소비할 수 있도록 준비하는 과정이 없으면, 토큰 가격과 비즈니스 가치의 괴리를 줄일 방법 자체가 없다.

이 단계는 지리하고 지루하다. 시간, 돈, 사람, 조직에 들어가는 비용은 큰데 실제 비즈니스 가치는 거의 드러나지 않는다.

특히 엔터프라이즈에서는 조직 간의 경계를 조정하고 허무는 일이 주가 되기 때문에, 단기적으로는 비즈니스 생산성이 정체되거나 오히려 손해처럼 보일 수도 있다.

하지만 한번 구축해두면 다른 조직으로 쉽게 확산되기 때문에 확실한 보상이 따른다. 비용이 앞서 나가고 가치가 뒤늦게 따라오는, 전형적인 선행 투자 구간이다.⁴

어떤 데이터가 어떻게 필요한지를 조사하는 시간도 많이 들어가는데, 특히 사일로가 심화된 엔터프라이즈가 더 그렇다. 그렇다고 그 사일로를 넘지 못하고 일부만 데이터만 노출하는 것은 큰 효과를 보기 어려운데, 결국 그 부족한 몇개의 차원 때문에 HITL 을 완전히 제거할 수 없기 때문이다.

따라서 DDD 관점으로 조직의 워크플로우를 파악하고 도메인 경계에 해당하는 데이터들을 온전히 노출하는 과정이 필요하다(streamlining).

2단계 — Shape (Harness Engineering)

하네스에 필요한 데이터가 준비되면, 이를 기반으로 하네스를 구축하면서 컨텍스트와 피드백 루프를 쌓는다. 흩어진 데이터를 적시에 가져와서 워크플로우를 구축하며 형태를 잡아주는 단계다.

이 과정은 직선이 아니라 나선형으로 일어난다. 그래서 비즈니스 가치도 직선이 아니라 계단식으로 쌓이고, 장기적인 팀 생산성 관점에서 보면 선형이 아니라 exponential하게 향상된다. 한 칸 올라갈 때마다 다음 칸을 오르는 비용이 줄어들기 때문이다.

도메인 전문가와 AI 전문가(FDE) 가 같이 쌍을 이뤄서 작업하는 것이 효과적이며, 둘 중에서도 도메인 지식이 더 중요하다. 조금 더 욕심을 내자면, DDD 에서 말하는 비즈니스 처리 과정이 하네싱 된 AI 워크플로우와 1:1 매핑이 되도록 구축하는 것이 이상적이다.

3단계 — Scale (Value Extracting)

하네스가 충분히 구축된 상태에서는 요구사항 변경이나 기능 개선이 매우 안정적이다. 충분한 가이드가 있고, 참고할 베스트 프랙티스 코드와 하네스가 있기 때문에 에이전트가 웬만해서는 어긋나지 않는다.

이 상태가 되면 거의 goal만 주어지면 대부분의 작업이 매끄럽게 완료되고, 사람의 개입도 거의 필요하지 않다. 새로운 요구사항이 들어와도 기존 하네스와 코드를 참조해 맞춤 하네스를 만드는 일이 어렵지 않다. 토큰 가격 대비 비즈니스 가치의 괴리가 최소화되는 단계다.

앞 두 단계에서 비용으로 쏟아부은 모든 투자는, 이 단계에서 안정적으로 회수되고 그 위에 누적 가치가 장기적으로 쌓인다. 그리고 그 혜택은 하네스 위에 구축된 조직원 전체와 회사가 장기적으로 입는다.

괴리가 선형으로 줄어들지 않는 이유도 여기 있다. 하네스를 만들어가는 전 과정에서 도메인 전문가와 AI 전문가가 모두 필요하고, 기술 측면에서는 최신 모델로 많은 토큰을 문제 정의와 해결에 써야 하기 때문에, 중간 구간의 괴리는 오히려 벌어졌다가 마지막에 가서야 급격히 좁혀진다.

3. 그렇다면 조직은 어떻게 일해야 하는가

위 렌즈에 동의한 조직이 AI를 도입해야 한다면, 일하는 방식은 어느 정도 정해진다고 본다.

첫째, 도메인 전문가를 기반으로 Stream(데이터 정렬)을 구축하는 TFT를 만든다. 이 TF의 역할은 데이터를 안전하게 외부로 노출하는 것, 그리고 향후 다양한 형태의 데이터 노출에 대해 완전히 flexible한 하네스를 만드는 것이다. 가능하면 이 도메인 경계를 기준으로 조직을 재편하는 것이 좋다. 바운디드 컨텍스트가 아니라 도메인을 기준으로 삼는 이유는, 엔터프라이즈에서는 바운디드 컨텍스트와 도메인이 어긋날 가능성이 높기 때문이다.⁵

둘째, Agentic Harness Engineer(이하 AHE) 조직을 만든다. 이 조직에는 회사 비즈니스 도메인에 대한 기본적인 이해와, 하네스 엔지니어링의 동작 방식에 대한 깊은 이해가 모두 필요하다. 하네스는 에이전트의 자율성을 목표로 하는데, 최대한의 자율성은 최대한의 커스터마이제이션을 전제한다. 그래서 중앙에서 일괄로 찍어내는 하네스는 개별 조직의 HITL을 충분히 제거하지 못하고, 어정쩡한 부분 자동화에 머물게 만든다.⁶

다만 이런 엔지니어를 직접 뽑고 운영하는 비용은 대체로 크다. 그래서 현재 OpenAI나 Google은 AI Deployment Engineer(AI DE)나 Forward Deployed Engineer(FDE) 같은 롤을 직접 운영하고 있고, 조직 입장에서는 그 회사의 솔루션을 사는 대신 이 엔지니어들을 빌려 쓰는 선택지도 존재한다. 자체 AHE (Agent Harnessing Engineer) 조직을 키우는 비용과, 외부 엔지니어를 활용하는 비용을 저울질하게 되는 셈이다.

단, 반드시 사전에 고려할 점이 있는데, 하네스는 모델과 도구의 동작 방식에 종속적이라 락인이 굉장히 심하다. 는 것이다. 어떤 회사의 엔지니어와 솔루션 위에 하네스를 쌓느냐는 사실상 향후 몇 년의 기술 스택을 고정하는 결정에 가까우므로, 신중하게 선택해야 한다. (이 종속성이 왜 그렇게 강한지는 4번에서 내 경험으로 다시 다룬다.)

셋째, 각 조직에 도메인 챔피언과 AHE를 짝지어 할당하고, 해당 도메인 워크로드에 특화된 하네스를 구축한다. 여기서 핵심은 HITL을 정의하고, 그것을 얼마나 제거했는지다.

다만 이 짝은 영구적인 게 아니라 핵심 하네스를 까는 동안만 붙는 부트스트랩에 가깝다. 하네스는 크게 피드백 루프와 가드레일로 이뤄지는데, 피드백 루프는 도메인 지식이 핵심이라 AHE가 도메인 전문가의 구축을 보조하는 데 그치고, 엔지니어링 영역인 가드레일은 AHE가 전담해 특히 단단히 박아둔다.

flowchart TB
    H["하네스"]
    H --> FL["피드백 루프<br/>도메인 전문가 주도 · AHE 보조"]
    H --> GR["가드레일<br/>AHE 전담 (엔지니어링 영역)"]
    classDef d fill:#cfe8cf,stroke:#3a3;
    classDef a fill:#fff3d6,stroke:#e8a;
    class FL d;
    class GR a;

이 과정에서 도메인 전문가는 하네스의 동작 방식을 체득하게 된다. 그러면 AHE가 빠진 뒤에도 전문가가 같은 구조를 본떠 나머지 워크로드를 스스로 나선형으로 확장해 나갈 수 있다. 앞서 Shape에서 말한 “나선 한 바퀴 = 계단 한 칸”을 여기서 실제로 누가 돌리는지가 정해지는 셈이다. 가드레일이 미리 단단하면 전문가 혼자 나선을 돌아도 크게 어긋나지 않는다.

flowchart LR
    subgraph S1["1 · 핵심 하네스 공동 구축"]
        direction TB
        A1["AHE"] -. "피드백 루프 보조" .-> D1["도메인 전문가"]
        A1 ==> G1["가드레일 전담"]
    end
    subgraph S2["2 · 지식 이전"]
        direction TB
        D2["도메인 전문가<br/>하네스를 체득"]
    end
    subgraph S3["3 · 단독 나선 확장"]
        direction TB
        D3["도메인 전문가"] ==> R["나머지 워크플로우<br/>스스로 한 칸씩"]
    end
    S1 ==> S2 ==> S3
    A1 -. "이탈 후 다음 도메인으로" .-> S3
    classDef a fill:#fff3d6,stroke:#e8a;
    classDef d fill:#cfe8cf,stroke:#3a3;
    class A1,G1 a;
    class D1,D2,D3,R d;

AHE가 도메인마다 상주하지 않고 부트스트랩만 하고 빠지기 때문에, 바로 앞에서 말한 “직접 뽑고 운영하는 비용이 크다”는 부담도 한 명이 여러 도메인을 순회하는 식으로 완화된다.

하네스가 잘 구축되면 더 작은 모델로 전환해서(e.g. Opus → Sonnet) 토큰 효율화까지 달성할 수 있다. 참고로 이런 하네스 없이 에이전트 여러 개만 붙여 자동화하려는 시도는 결국 컨텍스트 엔지니어링 수준에 머문다.⁷

넷째, 도메인 TFT는 하네스를 기반으로 평가 시스템을 만든다. 도메인 내 토큰 사용량 대비 비즈니스 가치 생산을 측정하고, 하네스가 새는 곳을 찾아, 그 시그널을 챔피언들에게 전달해 계속 개선해 나가도록 만든다. 앞서 “기가 찰 노릇”이라고 했던 평가는, 바로 이 자리에서야 비로소 의미를 가진다.

4. 어떻게 도입하고, 단계별로 무엇을 평가할 것인가

위의 일하는 방식을 시간 순서로 풀면, 도입은 대략 이런 파이프라인을 따른다.

도메인을 분석한다. DDD 관점으로 조직의 워크플로우를 훑어 도메인 경계를 그린다.
도메인 전문가를 찾는다. 그 경계 안의 데이터와 의사결정을 실제로 아는 사람이다.
도메인 전문가와 AI Engineer(AHE/FDE)를 짝지어 데이터를 스트림라이닝한다. 경계에 걸린 데이터를 텍스트로 온전히 노출하는 작업이다.
도메인별 하네스를 만들어 자동화한다. 컨텍스트와 피드백 루프를 쌓아 HITL을 정의하고 하나씩 제거한다.
하네스가 일정 수준 완성된 뒤에야, 그 조직에 대한 평가가 비로소 시작된다.

5번이 핵심이다. 하네스가 없는 상태에서 사람과 성과부터 평가하는 게 왜 어긋난 접근인지는 1번에서 이미 말했다. 평가의 대상은 하네스이므로, 평가 가능한 하네스가 깔리기 전까지 생산성 평가는 시작할 수조차 없다.

그렇다면 평가 기준은 무엇인가. 여기서 또 흔한 실수가 나온다. 모든 단계를 토큰당 비용으로 재려는 것이다. 하지만 단계마다 곡선이 다르니 평가 기준도 달라야 한다. 새로운 워크로드나 작업이 들어와도, 그것이 3S 중 어느 단계에 있는지에 맞춰 다른 잣대를 대야 한다.

Stream — 기간과 활용처. 이 구간은 비용만 들고 가치가 거의 안 나오므로, 토큰당 가치로 재면 무조건 적자로 찍힌다. 대신 얼마나 빨리 데이터를 정렬해 노출했는가(기간), 그리고 그 정렬된 데이터가 몇 군데에서 재활용되는가(활용처)로 평가한다. 활용처가 늘수록 선행 투자가 회수되고 있다는 신호다.
Shape — 기간과 HITL 제거율. 하네스를 깎는 단계이므로 여전히 토큰당 가치는 안정적이지 않다. 하네스를 한 칸 올리는 데 걸린 기간과, 그 결과 얼마나 많은 HITL을 제거했는가(제거율)가 핵심 지표다. 계단을 몇 칸 올라왔는지를 HITL 제거율로 읽는 셈이다.
Scale — 토큰당 비용. 이 단계에서는 HITL이 거의 다 제거돼 goal만 주면 작업이 굴러가므로, 더 걷어낼 HITL이 남아 있지 않다. 그래서 평가의 잣대도 HITL 제거율에서 토큰당 비용으로 넘어간다. 괴리가 최소화된 구간이라 토큰 1단위가 만들어내는 비즈니스 가치가 비로소 안정적으로 측정되기 때문이다.

요컨대 토큰당 비용으로 생산성을 따지는 평가는 Scale에 도달한 워크로드에만 유효하다. 아직 Stream이나 Shape에 있는 작업에 그 잣대를 들이대면, 선행 투자를 손해로 오독하고 도입을 그 자리에서 멈추게 만든다.

5. 모델이 좋아진다고 괴리가 저절로 줄지는 않는다

최근 나온 Fable을 충분히 테스트해보진 않았지만, 핵심은 스스로 판단해서 컨텍스트를 메꾸는 능력이 향상된 것으로 보인다. (HITL 제거 렌즈³) 입력된 데이터를 넘어 모델 자체의 성능이나 리즈닝 방식이 급격하게 발전한 것 같지는 않다. 현재 일부 에이전트 벤치마크는 여전히 GPT 5.5가 이기기도 한다.

이 지점이 내가 줄곧 하고 싶은 이야기, 즉 괴리를 줄이는 건 모델이 아니라 그 위에 쌓인 컨텍스트와 하네스라는 이야기와 맞닿아 있다.

코딩 자체는 사실상 정복됐다고 본다. 나 역시 코딩이 Sonnet 3.7부터 정복되었다는 이야기에 크게 동의한다. 하지만 소프트웨어 엔지니어링에서 코딩은 일부분이었다. 기존에 많은 프로토타이핑을 하면서 같은 함정에 빠지는 고객들을 많이 봤다. 휴먼 트래킹 만 해결 되면 다 된다. 거나 물성예측만 해결되면 다 된다. 같은 식의 이야기를 많이 들었다. 하지만 해당 문제를 해결하고 나서 큰 그림을 보면 그 문제가 전체 비즈니스 변수들 중에서는 10% 내외였다는 것을 알 수 있었다.

에이전틱 엔지니어링에서도 마찬가지인데, 정복된 것은 코딩일 뿐이고, 에이전틱 엔지니어링에서 정복할 많은 변수들이 아직 남아있다.

아직 에이전트의 발전을 통해 바뀌고 있는 것은 크게 두 가지뿐이다. 내가 정확한 컨텍스트를 전달하는 과정이 토큰 효율화되었고, 사람의 개입이 줄었다. 바꿔 말하면, 괴리를 줄인 건 모델의 성능이 아니라 그 위에 쌓아온 컨텍스트와 하네스였다는 뜻이다.

그러니 모델이 좋아지길 기다리며 도입을 미루는 건 번지수가 틀렸다. 모델은 이미 충분히 좋다.

부족한 건 그 모델에 정확한 컨텍스트를 떠먹여 줄 하네스이고, 그건 기다린다고 생기지 않는다. 누군가 Stream을 깔고, Shape에서 하네스를 깎아야 생긴다.

6. “아무 코딩 에이전트나 골라 쓰세요”가 좋은 전략일까?

같은 맥락에서, 최근 여러 회사가 내놓는 “코딩 에이전트는 여러 개 붙여줄 테니 아무거나 골라 쓰라”는 정책에는 회의적이다. 심지어 한 작업을 두 에이전트로 반반 나눠 쓰라는 경우까지 있다.

앞서 줄곧 말했듯 현재의 하네스는 모델과 에이전트에 종속적이다. 모델마다 동작하는 방식이 다르고, 코딩 에이전트마다 내장된 하네스와 시스템 프롬프트를 통한 기본 행동 지침이 다르기 때문에, 같은 하네스라도 모델이나 에이전트가 바뀌면 효율이 나지 않는다.

그런데 아무 에이전트나 쓰라거나, 한 작업을 두 에이전트로 반반 쓰라는 건 곧 하네스가 모델과 에이전트에 종속적이라는 사실 자체를 거의 이해하지 못하고 있다는 반증이라고 본다. 에이전트를 자유롭게 갈아 끼울 수 있다는 발상은, 하네스가 없거나 있어도 제대로 동작하지 않는 상태에서만 성립한다. (미래에는 모르겠지만)

이건 개인 프로젝트에서 내가 직접 겪은 일이기도 하다.

나도 몇년전 한동안 Cursor에서 Claude Code로 넘어가지 못했는데, 이유는 단순했다. Cursor 기준으로 짜둔 하네스가 Claude Code로 옮기는 순간 전부 망가졌고, 그걸 전환하는 데 시간이 너무 오래 걸렸기 때문이다.

흥미로운 건, Cusor 하네스를 Claude Code 기준으로 스스로 재구성하라고 시켰을 때도 Sonnet 모델로는 제대로 동작하지 않았다. 나는 수십 개 이상의 파일로 구성된 하네스를 수동으로 옮기고 싶지 않았기 때문에 넘어가지 못했었다.

결국 Opus가 나오고 나서야 에이전트가 스스로 재구성한 하네스가 비로소 돌아갔고, 그제서야 넘어갈 수 있었다. 도구가 바뀌면 하네스를 다시 깎아야 하고, 그 하네스가 정상 작동하는지는 모델 수준에까지 걸려 있다. 락인이 심하다는 말은 이런 의미다.

그러니 코딩 에이전트 선택은 “여러 개 중 골라 쓰는” 편의의 문제가 아니라, 하네스를 어디에 정착시킬지를 결정하는 전략의 문제다.

미래에는 어떨지 몰라도, 현재 상황에서는 에이전트를 반반 나눠 쓰라는 정책은 둘 중 어느 쪽에도 제대로 된 하네스를 쌓지 말라는 말과 다르지 않다.

마치며

정리하면 이렇다. 토큰 가격과 비즈니스 가치 사이엔 괴리가 있고, 그 괴리를 줄이는 건 모델이 아니라 하네스다. 하네스는 데이터를 정렬하고, 그 위에서 깎아 나가야 비로소 생긴다. 그 전까지 드는 비용은 손해가 아니라 먼저 치르는 투자다.

향방 없이 흘러가는 AI 도입도 대개 순서가 거꾸로다. 먼저 치를 비용은 감내하지 못하고, 하네스를 만들 사람은 두지 않은 채, 성과부터 평가하려 한다. 토큰을 아끼라는 압박도, 아무 에이전트나 골라 쓰라는 정책도 마찬가지다.

하네스를 만드는 일은 지루하고, 단기 성과가 안 나오고, 조직의 경계를 건드려야 한다. 그래서 대부분은 초반에 멈춘다. 그 구간을 통과할 각오가 된 조직만이 그다음을 가져간다고 생각한다.

그리고 그 각오의 본질은, 결국 지금 사람이 하던 일을 하나씩 에이전트에게 넘기며 스스로를 대체해 나가는 일이다.

If you don’t cannibalize yourself, someone else will.

— Steve Jobs

내가 나를 잠식하지 않으면, 결국 누군가 나를 잠식한다. 우리가 속한 조직이 스스로 대체하고 진화하는 조직인지, 아니면 남에 의해 대체되고 소멸하는 조직인지, 한번 생각해볼 시기인 것 같다.

쉽게 설명한 하네스 엔지니어링 ↩
켄트 벡(Kent Beck)의 The Product Development Triathlon (2016) — 3X 모델(Explore, Expand, Extract). ↩
현상을 해석하는 렌즈, 그리고 에이전틱 엔지니어링 ↩ ↩²
하나의 잘 만든 GenAI 플라이휠이 비즈니스 전체를 견인한다 ↩
에이전틱 개발 시대, 비즈니스를 아는 개발자의 가치 ↩
에이전틱 엔지니어링과 과도기적 기술들 ↩
하네스 없는 멀티 에이전트는 그냥 컨텍스트 엔지니어링 ↩

Haandol