2주간의 실험을 통해 공유 컨텍스트(shared context)와 실행 상태(execution state)를 관리하는 것이 거버넌스 프레임워크 자체보다 더 중요하다는 사실이 밝혀졌습니다.

저는 2주 동안 AI 보조 개발을 측정하였고, 엔지니어링 낭비의 가장 큰 원인은 모델이 아니라 세션 전반에 걸쳐 관리되지 않은 컨텍스트 드리프트(context drift)라는 것을 발견했습니다.

두 번의 별도 주간 동안, 저는 두 가지 반복된 AI 엔지니어링 워크플로우를 사용하여 동일한 로컬 프로젝트를 구축할 때 발생하는 기회비용을 추적했습니다.

두 주 모두 거버넌스 프레임워크를 따랐습니다.

두 주 모두 설계 문서(design documents), 구현 계획(implementation plans), 그리고 구조화된 실행(structured execution)을 사용했습니다.

결정적인 차이는 거버넌스의 존재 여부가 아니라, 워크플로우가 AI 세션 전반에 걸쳐 **공유 컨텍스트(shared context)와 실행 상태(execution state)**를 지속적으로 관리했는지 여부였습니다.

이 단 한 가지의 변화가 개발의 경제성을 근본적으로 바꾸어 놓았습니다.

지표 요약

워크플로우 전략	해결된 이슈 수	총 소요 시간	반응적 낭비 (Reactive Waste)	이슈당 추정 비용
1주 차: 공유 컨텍스트 없는 거버넌스	3	14.1h	56%	$1,175
2주 차: 공유 컨텍스트가 있는 거버넌스	7	5.2h	0%	$186

누락된 조각은 바로 공유 컨텍스트였습니다

저를 가장 놀라게 했던 것은 모델의 능력이 아니었습니다.

**컨텍스트 드리프트(context drift)**가 얼마나 빠르게 반응적 엔지니어링 작업(reactive engineering work)으로 축적되는가 하는 점이었습니다.

구현이 진행됨에 따라, 세션 간의 가정이 서서히 어긋나기 시작했습니다. 거버넌스 산출물(governance artifacts)이 갖춰져 있음에도 불구하고, AI의 작업 컨텍스트는 프로젝트의 의도된 상태로부터 점점 더 단절되었습니다. 그 결과 반복적인 디버깅, 불필요한 재작업, 그리고 애초에 존재하지 않았어야 할 문제를 수정하는 데 수 시간이 소요되었습니다.

가장 큰 개선은 모델이 아니라 워크플로우를 변경함으로써 이루어졌습니다.

거버넌스를 정적인 문서로 취급하는 대신, 저는 **공유 컨텍스트(shared context)와 실행 상태(execution state)를 매 세션마다 지속적으로 검증, 동기화 및 전파되어야 하는 일급 엔지니어링 산출물(first-class engineering artifacts)**로 취급했습니다.

그 비교적 작은 투자가 결과적으로 근본적인 변화를 가져왔습니다:

• 완료된 이슈(issue) 수 2배 이상 증가
• 총 개발 시간 약 63% 감소
• 사후 수습(reactive cleanup) 제로
• 완료된 이슈당 추정 엔지니어링 비용 84% 감소

여기서 얻은 교훈은 모델이 갑자기 더 똑똑해졌다는 것이 아니었습니다.

그것은 바로 관리된 컨텍스트 (managed context) 없는 거버넌스 (governance)는 불완전한 거버넌스에 불과하다는 점이었습니다.

저는 다른 이들도 결과를 직접 판단할 수 있도록 시간 로그, 비용 계산, 실패 분석, 그리고 불필요한 노력을 수 시간 동안 소모하게 만든 구체적인 이슈들을 포함하여 전체 실험 과정을 기록했습니다.

전체 분석 내용 읽기:

What 7 Issues in 5 Hours Taught Me About AI Workflow Economics

이곳에 표현된 견해는 저 개인의 의견이며, 제가 고용된 회사나 제가 소속된 조직의 견해를 반드시 반영하는 것은 아닙.