AI 도입 성과는 언제 비즈니스 지표로 봐야 할까 — AHEAD·LEVER 다시 보기 2/2

TL;DR

• 한 팀에서 학습할 때는 하네스와 리뷰 부담의 변화를 본다.
• 다른 업무로 확산할 때는 전체 전달 비용과 비즈니스 성과를 본다.
• AHEAD와 LEVER는 종합점수가 아닌 질문 목록이다.

시작하며

1/2 글에서는 AI 도입을 업무 환경을 연결하고, 한 팀에서 실패를 줄이고, 검증한 방식을 다른 업무로 넓히는 과정으로 정리했다.

그런데 한 팀에서 배우는 동안에도, 다른 업무로 넓힌 뒤에도 비용 절감을 물으니 두 단계의 차이가 흐려졌다. 코드 생성에서 줄어든 비용이 리뷰, CI와 운영으로 이동하는 문제도 충분히 드러나지 않았다.

리뷰 인지부하 글을 쓰면서 초기에 먼저 확인해야 할 것은 사람이 결과를 이해하고 승인하는 부담이 실제로 줄고 있는가라는 생각이 분명해졌다.¹

소프트웨어 전달 비용 글을 정리하면서, 확산 이후에는 고객에게 도달하기까지의 전체 비용을 봐야 한다고 생각하게 됐다.²

이번 글에서는 그에 맞춰 단계별로 확인할 질문을 고쳐보려 한다.

1. 처음부터 평가하되 같은 것을 묻지 않는다

도입 전에는 현재 워크플로우의 시간, 품질, 비용과 사람 개입을 기록해야 한다.

앞선 글에서는 업무 환경을 연결하는 단계를 Streamlining, 한 팀에서 하네스를 개선하는 단계를 Shape, 검증한 방식을 확산하는 단계를 Scale이라고 불렀다. 하네스는 Agent가 사용하는 컨텍스트, 도구, 권한과 검증 체계를 뜻한다.

Shape의 질문 목록은 AHEAD, Scale의 질문 목록은 LEVER로 이름 붙였다. 둘 다 내가 제안하는 기준이며 검증된 표준이나 종합점수는 아니다. CTS-SW는 고객에게 전달한 소프트웨어 한 단위에 든 전체 비용을 보는 지표다.²

Streamlining과 Shape에 Scale의 투자수익 기준을 바로 적용하면 선행 투자를 실패로 보기 쉽다.

Kiro의 매니저용 가이드도 성과가 높았던 팀들이 초기에는 느려졌다고 보고하며, 일하는 방식을 바꾸지 않고 즉각적인 성과를 기대한 팀들과 구분한다.³ 초기에는 학습을, 확산 이후에는 성과를 묻자는 내 구분을 뒷받침하는 관찰이다. 다만 Kiro가 AHEAD와 LEVER를 제안하거나 검증한 것은 아니다.

반대로 Scale에 들어간 워크로드를 계속 학습 단계라고만 부르면 비용과 성과를 설명하지 않아도 된다. 단계 구분은 투자를 정당화하기 위한 이름이 아니라 다음 판단을 바꾸기 위한 기준이어야 한다.

2. AHEAD — 하네스와 리뷰 부담의 변화를 본다

Shape에서는 Agent가 만든 산출물의 수보다 같은 실패와 판단이 어떻게 줄어드는지 확인한다.

기존 AHEAD의 E를 비용 효율을 뜻하는 Efficiency에서 검증 근거의 질을 뜻하는 Evidence Quality로 바꿨다. 업데이트한 AHEAD는 다음 다섯 질문으로 구성한다.

Autonomy Boundary는 자동화율을 높이라는 뜻이 아니다.

위험이 낮고 계약이 분명한 정상 경로는 Agent가 구현과 검증을 끝낼 수 있어야 한다. 반대로 계약 변경, 기존 결정과의 모순, 보안과 데이터 위험은 빠짐없이 사람에게 올라와야 한다.

사람의 개입이 적다는 사실만으로는 좋은 자율성인지 알 수 없다. 사람이 판단해야 할 위험까지 보고하지 않는다면 Dependability가 낮아진 것이다.

Harness Learning에서는 리뷰에서 반복된 판단이 다음 Agent가 사용할 계약, 테스트, 규칙이나 도구로 바뀌었는지 본다. 같은 문제를 사람이 계속 찾아낸다면 하네스가 학습했다고 보기 어렵다.

Kiro의 지속 개선 원칙에서도 Agent가 잘못된 방향으로 가거나 사람을 불필요하게 부를 때마다, 다음에는 같은 일이 생기지 않도록 규칙·도구·컨텍스트를 고치라고 권한다.⁴ 이 원칙을 평가 질문으로 옮기면, 사용량보다 반복 개입의 원인이 다음 실행에서 줄었는지를 보게 된다.

이번에 새로 넣은 Evidence Quality는 리뷰 인지부하를 직접 다룬다.

Agent가 테스트를 통과했다는 한 줄만 남기면 사람은 코드를 처음부터 읽게 된다. 계약별로 무엇을 만족했고 어떤 증거가 있으며, 확인하지 못한 위험과 구현 중 새로 정한 내용이 무엇인지 보여줘야 검토 범위를 줄일 수 있다.

보고서의 길이보다 사람이 새로 이해해야 할 범위가 계약 변경과 예외로 좁아졌는지를 본다. 보안, 결제와 데이터 마이그레이션처럼 코드까지 봐야 하는 영역은 남겨두되, 모든 변경에 같은 수준의 리뷰를 요구하지 않는다.

매니저용 가이드에는 자동 검사와 테스트를 앞당긴 뒤 리뷰의 초점이 코드 스타일과 이름에서 인터페이스 정의와 아키텍처 결정으로 옮겨간 팀의 사례가 나온다.³ 리뷰에서 사람이 무엇을 판단하게 됐는지 확인해야 한다는 근거다. 계약별 증거의 질로 이를 살펴보자는 것은 이 글의 제안이다.

Adoption은 도구 접속자 수보다 운영 소유권을 본다.

도메인팀이 결과를 신뢰하고, 실패를 분류하고, 평가 기준을 직접 고칠 수 있어야 한다. 하네스 엔지니어가 떠난 뒤 워크플로우가 멈춘다면 아직 조직 역량으로 넘어가지 않은 것이다.

AHEAD 다섯 항목은 하나의 점수로 합치지 않는다.

자동 완료 비율만 높이려 하면 위험을 놓칠 수 있다. 반대로 안정성을 높이겠다며 모든 변경에 수동 검토를 붙이면, 검증 근거를 개선할 이유가 줄고 현업의 사용 부담은 커질 수 있다. 한 항목을 개선하려고 택한 방법이 다른 항목에 어떤 영향을 주는지 함께 보는 편이 낫다고 생각한다. 생산성을 단일 활동량으로 환원하지 말자는 SPACE의 제안과도 같은 이유다.⁵

3. Shape에서 Scale로 넘어가는 기준

대표 평가 사례를 몇 번 통과했다고 바로 Scale로 넘어가지는 않는다.

다음 조건이 함께 보여야 한다.

• 반복 실패가 계약·테스트·규칙과 도구에 반영된다.
• 정상 경로는 사람의 반복 승인 없이 완료된다.
• 사람은 계약 변경과 중요한 예외를 정확히 전달받는다.
• 도메인팀이 하네스와 운영 지표를 직접 관리한다.
• 모니터링, rollback과 책임 경계가 준비되어 있다.

리뷰 대기열이 계속 늘거나 사람이 모든 코드를 다시 이해해야 한다면 Shape가 끝난 것이 아니다.

코드 생성 속도만 높인 상태에서 Scale을 선언하면 변경량만 늘고 병목은 리뷰, CI와 운영으로 이동한다. DORA가 AI를 조직의 기존 강점과 약점을 증폭하는 요소로 설명하는 것도 이 흐름과 맞닿아 있다.⁶

Scale 전환은 하네스가 완벽하다는 선언이 아니다.

정의된 범위에서는 반복 가능한 품질과 위험 기준을 유지하며 운영할 수 있고, 새로운 계약과 예외가 생기면 다시 Shape로 돌아갈 수 있다는 뜻이다.

4. LEVER — 전체 전달 비용과 가치 회수를 본다

Scale에서는 같은 하네스를 다음 요구사항에 재사용했을 때 무엇이 달라졌는지 본다.

업데이트한 LEVER는 다음과 같다.

기존 Extraction Efficiency를 End-to-end Efficiency로 바꾼 이유는 비용이 이동하기 때문이다.

코드 생성 시간과 토큰이 줄어도 리뷰 대기, CI 재시도와 장애 대응이 늘면 효율이 좋아진 것이 아니다. 모델, 도구, 사람과 운영을 포함한 전체 비용을 고객에게 도달한 소프트웨어와 연결해야 한다.

CTS-SW는 이 항목을 보는 출발점으로 사용할 수 있다.²

다만 CTS-SW 자체가 비즈니스 가치는 아니다. 배포 한 단위의 비용이 낮아져도 고객이 원하지 않는 기능을 더 싸게 만든 것일 수 있다.

그래서 Value Realization을 따로 둔다.

무엇을 가치로 볼지는 워크로드마다 다르다. 고객 요청 처리 시간이 줄었는지, 같은 인원으로 더 많은 업무를 처리하는지, 사고 위험을 낮췄는지 시작할 때 정해야 한다.

Extension & Reuse는 기능 개수보다 추가 준비 작업을 본다.

새 워크로드마다 프롬프트, 도구, 평가와 권한 체계를 처음부터 만든다면 앞선 투자를 재사용한 것이 아니다. 반대로 기존 계약과 평가 사례를 조금 확장해 새 요구사항을 처리했다면 Scale의 효과가 나타난 것이다.

Kiro도 확산 단계에서 조직 공통 규칙을 적용하고, 지속 운영 단계에서는 먼저 도입한 팀의 경험과 컨텍스트를 조직에 공유하도록 제안한다.³ 도구를 쓰는 팀 수와 함께 실제로 무엇을 재사용했는지 봐야 한다는 Extension & Reuse의 방향과 맞닿아 있다.

Reliability는 비용 절감이 다른 곳으로 전가되지 않았는지 확인한다.

CTS-SW가 낮아졌는데 변경 실패와 당직 대응이 늘었다면 개선으로 보기 어렵다. 같은 팀의 시간에 따른 추세를 품질 지표와 함께 봐야 한다.

매니저용 가이드 역시 확산할 때 속도뿐 아니라 결과의 정확성을 측정하라고 명시한다.³ 전달 비용이 줄었어도 품질이 나빠졌다면 개선으로 보지 않는다는 LEVER의 판단과 같은 방향이다.

5. 코드 생성이 빨라졌는데 리뷰가 밀리는 경우

여러 Agent를 도입한 뒤 PR은 빨리 생기지만 리뷰 대기열이 길어졌다고 해보자.

코드 생성량만 보면 도입이 성공한 것처럼 보인다.

AHEAD로 보면 다른 문제가 드러난다.

• Autonomy Boundary: 정상 변경도 모두 사람의 승인을 기다린다.
• Harness Learning: 같은 리뷰 지적이 테스트와 규칙으로 옮겨지지 않는다.
• Evidence Quality: 계약별 증거가 없어 사람이 전체 diff를 읽는다.
• Adoption: 도메인팀은 결과를 사용하지만 하네스를 고치지 못한다.
• Dependability: 리뷰를 줄이면 어떤 위험이 생기는지 기준이 없다.

이 상태에서 Agent를 더 늘리면 읽지 않은 변경만 빨리 쌓인다.

먼저 반복되는 리뷰 판단을 계약과 테스트로 옮기고, Agent가 요구사항별 검증 근거와 남은 위험을 남기게 해야 한다. 사람이 구현 전체보다 예외를 검토할 수 있게 된 뒤에야 생성 속도가 전달 속도로 이어진다.

flowchart LR
    G["코드 생성 증가"] --> Q["리뷰 대기 증가"]
    Q --> A["AHEAD로 원인 확인"]
    A --> H["계약 · 테스트 · 증거 개선"]
    H --> D["사람은 예외만 판단"]
    D --> L["LEVER로 전달 비용과 가치 확인"]

LEVER는 그 다음 질문이다.

리뷰 대기가 줄어 고객에게 도달하는 시간이 짧아졌는지, CTS-SW가 품질 저하 없이 낮아졌는지, 그 변화가 실제 비즈니스 결과로 이어졌는지 본다.

6. 지표는 목표보다 대화의 순서로 쓴다

AHEAD와 LEVER의 각 항목을 KPI로 만들면 다시 숫자 최적화가 시작될 수 있다.

자동 완료 비율을 목표로 두면 필요한 사람 검토까지 피할 수 있다. CTS-SW만 낮추려 하면 유지보수와 장애 비용을 계산에서 빼거나 소프트웨어 단위를 잘게 나눌 수 있다.

그래서 한 팀의 한 워크로드에서 기준선을 만들고, 아래 순서로 대화하는 편이 낫다고 생각한다.

1. 현재 가장 큰 병목과 위험은 어디인가
2. 이번 변경이 AHEAD의 어떤 항목을 바꿀 것으로 예상하는가
3. 실제 리뷰 부담과 품질이 어떻게 달라졌는가
4. Scale 이후 CTS-SW와 LEVER에 어떤 변화가 나타났는가
5. 비용이 다른 단계나 사람에게 이동하지 않았는가

모든 항목이 매주 좋아질 필요는 없다.

새로운 보안 요구사항이 생기면 사람 검토와 Lead Time이 일시적으로 늘어날 수 있다. 그 판단이 계약과 가드레일로 남아 다음 작업의 반복 검토를 줄인다면 Shape의 학습으로 볼 수 있다.

지표는 성공을 선언하는 점수보다, 다음에 어디를 고칠지 찾는 기록에 가깝다.

마치며

지금은 AHEAD와 LEVER를 조직 평가 점수보다 도입 단계에 맞는 질문을 빠뜨리지 않기 위한 체크리스트로 쓰는 편이 적절하다고 생각한다.

이 기준을 실제 워크로드에 적용하면 항목의 이름이나 관찰 방법은 더 바뀔 수 있다. 다만 Shape에서 학습과 리뷰 부담을 먼저 보고, Scale에서 전체 비용과 가치를 묻는 순서는 유지할 생각이다.

• #ai
• #agent
• #agentic-development
• #harness-engineering
• #organization
• #developer-experience
• #cts-sw