AI-Native Step Tracing: 코드를 읽지 말고 동작을 관찰하여 AI 코드를 검증하라

저는 AI와 작업하는 방식을 바꾼 한 가지 사실을 깨달았습니다. AI가 생성한 코드의 코드 리뷰 (Code review) 비용은 직접 코드를 작성하는 비용만큼이나 많이 든다는 점입니다. 이는 속도 측면의 이점을 완전히 상쇄합니다. 결국 다시 원점으로 돌아가는 셈입니다. 문제는 모델이 아닙니다. 문제는 당신이 검증 노력을 어디에 쏟고 있느냐 하는 것입니다.

통찰 (The Insight)

AI의 환각 (Hallucinations)은 구문 (Syntax)이 아니라 동작 (Behavior)에서 나타납니다. 코드는 멀쩡해 보입니다. 리뷰도 통과합니다. 테스트도 통과합니다. 그러다 운영 환경 (Production)에서 무너집니다. 그러니 코드 검증을 멈추십시오. 동작을 검증하십시오.

방법론 (The Methodology)

AI는 항상 실수할 것이라고 가정하십시오
가끔이 아니라 항상 그렇습니다. "네트워크는 패킷을 드롭한다"는 공학적 논리와 같습니다. 실패를 고려하여 설계하십시오.
구현 전에 단계를 정의하십시오
어떤 구현이든 어쨌든 단계는 존재합니다. 당신이 미리 정의하든, AI가 구현 중에 스스로 만들어내든 말입니다. 사전에 정의하는 것은 비용이 거의 들지 않지만, 검증 가능한 동작 계약 (Behavioral contract)을 제공합니다.
단계의 세분화 (Granularity)를 선택하는 방법
이것이 가장 어려운 부분입니다. 관습적인 본능은 함수 (Functions), 모듈 (Modules), 서비스 (Services)와 같은 코드 경계를 따라 나누는 것입니다. 올바른 본능은 데이터 변경 시점 (Data change moments)을 따라 나누는 것입니다. 1,500줄짜리 함수라도 당신이 신경 쓰는 단 하나의 데이터 변경을 생성한다면 하나의 단계가 될 수 있습니다. 단 세 줄의 코드라도 그 세 줄이 검증이 필요한 데이터를 생성한다면 하나의 단계가 될 수 있습니다. 단계의 크기는 코드의 크기와 아무런 상관이 없습니다. 이는 또한 당신이 AI의 구현을 제약하지 않는다는 것을 의미합니다. 당신은 단지 "이 시점의 데이터가 필요하다"라고 말할 뿐입니다. AI가 그곳에 도달하는 방식은 전적으로 AI의 창의적 영역입니다.
각 단계를 트레이서 (Tracer)로 감싸십시오
입력 (Input), 출력 (Output), 지속 시간 (Duration), 성공/실패 여부를 기록하십시오. 사후에 별도의 계측 (Instrumentation)을 할 필요가 없습니다.
결과를 관찰하여 검증하십시오
단계가 실행되었는가? 데이터가 정확한가? 타이밍이 합리적인가? 인간은 몇 초 안에 이 질문에 답할 수 있습니다. 코드 리뷰가 필요 없습니다.

인간이 단계를 정의함 → AI가 구현함 → 트레이스 (Trace)가 검증함 → 인간이 관찰함

트레이싱이 없을 때 vs 트레이싱이 있을 때

트레이싱이 없을 때:
❌ 오류: 재고 부족 → 어떤 단계에서 실패했는가? 어디까지 진행되었는가? 알 수 없음.

트레이싱이 있을 때:
✅ Step 1: ① 재고 확인 (44ms) Input : {"productId":"prod_002","quantity":1} Error : 재고 부족: 가용량=0, 요청량=1 정확한 단계. 정확한 입력값. 정확한 오류. 즉각적인 위치 파악.

트레이싱을 통한 성공적인 주문:
✅ Step 1: ① 재고 확인 (31ms) ✅ Step 2: ② 재고 잠금 및 주문 생성 (32ms) ✅ Step 3: ③ 결제 큐로 푸시 (15ms) ✅ Step 4: ④ 결제 처리됨 (64ms) ✅ Step 5: ⑤ 배송 알림 (28ms)
트레이싱은 배송 증명서와 같습니다. 코드 리뷰가 필요 없습니다.

과도한 프롬프트 제약이 역효과를 내는 이유

과도한 프롬프트 제약 (Heavy prompt constraints)은 AI에게 무엇을 하지 말아야 할지를 지시합니다. AI는 문제를 해결하는 대신 규칙을 피하는 데 주의력 (Attention)을 소모합니다.

단계 정의 (Step definitions)는 AI에게 무엇을 달성해야 하는지를 알려줍니다.
구현 (Implementation)은 AI의 창의적 공간입니다.
제약을 줄수록 결과는 더 좋아지고 유연성은 더 높아집니다 — 줄어들지 않습니다.

당신이 볼 수 없는 버그들

데모 ( src/order.ts )에는 두 가지 구현 방식이 모두 포함되어 있습니다. 단순한 버전 (Naive version)에는 코드 리뷰로는 보이지 않는 세 가지 실제 버그가 있습니다:

레이스 컨디션 (Race condition) — 재고 확인과 차감이 별도로 이루어집니다. 동시 요청 시 초과 판매가 발생합니다.
트랜잭션 누락 (Missing transaction) — 주문 생성과 재고 차감이 원자적 (Atomic)이지 않습니다. 그 사이에서 충돌이 발생하면 데이터 불일치가 발생합니다.
멱등성 결여 (No idempotency) — 중복된 결제 메시지가 두 번 처리됩니다.

이 버그들은 코드 리뷰를 통과합니다. 단위 테스트 (Unit tests)도 통과합니다. 하지만 부하가 걸리는 운영 환경 (Production)에서 나타납니다.
단계를 정밀하게 정의하면 이러한 경계들이 가시화됩니다.

설계 원칙

모델 종속성 없음 (No model lock-in) — 어떤 모델과도 작동합니다. 사용 중인 가장 약한 모델에 최적화되어 있으며, 더 강력한 모델을 사용하면 결과가 향상될 뿐입니다.
언어 종속성 없음 (No language lock-in) — 이 패턴은 어떤 언어에서도 작동합니다. 이 데모는 TypeScript로 작성되었습니다.
최소 실행 가능 계약 (Minimum viable contract) — traceId와 단계 이름(step name)이라는 두 개의 필드만 가집니다. 그 외의 모든 것은 구현의 영역입니다.

실행해보기

bash git clone https://github.com/adun1982/step-trace npm install npx tsx src/index.ts

이 내용은 자유롭게 공유됩니다. 제품 판매나 업셀링 (Upsell)은 없습니다. 그저 1인 개발자가 20개의 레스토랑 체인, 400개의 지점을 관리하며 팀 규모의 결과물을 만들어내는 실제 운영 환경에서 도출된 패턴일 뿐입니다.

만약 이것이 AI 보조 개발 (AI-assisted development)에 대한 당신의 생각을 변화시킨다면, 그것만으로도 충분합니다. ---