AI 코딩 에이전트는 왜 실행 증거를 먼저 남겨야 하는가

Lead: AI 코딩 에이전트의 기준은 더 이상 “코드를 잘 쓰는가”만이 아니다. 무엇을 실행했고, 어디서 멈췄고, 어떤 증거를 남겼는가가 더 중요하다. 실행 증거가 없는 에이전트는 똑똑해 보여도 운영으로 들어가면 금방 무너진다.

TL;DR

에이전트 제품의 핵심은 모델 이름이 아니라 실행 증거다.
log, blame, show, replay 같은 개념이 있어야 에이전트 작업을 신뢰할 수 있다.
local-first, no-upload, self-verification은 멋진 옵션이 아니라 첫 번째 신뢰 조건이다.

왜 지금 중요한가

이번 inbox에서 반복해서 보인 건 같은 한 줄이다. AI는 답을 내는 순간보다, 그 답이 어떻게 만들어졌는지를 남기는 순간 더 강해진다.

re_gent는 AI 코딩 에이전트의 작업을 git처럼 추적한다.
leerob의 메모는 source of truth, 검증, 간결한 AGENTS.md를 강조한다.
루프 엔지니어링은 반복 자동화보다 종료 조건과 검증을 먼저 보게 만든다.
브라우저에서만 끝나는 SQL→ERD 도구는 “아무것도 업로드하지 않는다”는 문장으로 신뢰를 만든다.

이 네 개는 주제가 달라 보여도 같은 구조를 말한다.

에이전트는 결과물보다 경로를 먼저 증명해야 한다.

AI 제품이 점점 더 실무로 들어올수록, 사용자는 “정답”보다 “재현 가능한 과정”을 본다. 특히 코드, 스키마, 운영 설정, 고객 데이터처럼 되돌리기 어려운 영역에서는 더 그렇다.

핵심 흐름

flowchart LR
    A[Input] --> B[Plan / Parse]
    B --> C[Edit / Act]
    C --> D[Verify]
    D --> E[Record Evidence]
    E --> F[Replay / Next Step]

이 그림에서 중요한 건 박스 개수가 아니다. 어느 단계에서 무엇이 남는지가 보인다는 점이다.

1) 버전 관리는 코드만이 아니라 세션을 추적해야 한다

re_gent가 흥미로운 이유는 단순히 git 비슷하게 생겼기 때문이 아니다. 핵심은 에이전트가 한 작업을 세션 단위로 쪼개서 추적한다는 점이다.

log는 무슨 일이 있었는지 보여준다.
blame은 누가, 어떤 맥락에서 그 줄을 만들었는지 보여준다.
show는 한 단계의 전체 맥락을 복원한다.

이건 사람 개발자에게도 유용하지만, 에이전트 제품에는 더 중요하다.

왜냐하면 에이전트는 늘 같은 방식으로 일하지 않기 때문이다. 같은 입력이라도 도구 선택이 달라질 수 있고, 같은 도구라도 중간 판단이 달라질 수 있다. 그래서 진짜 버전 관리 대상은 결과 파일 하나가 아니라 결정의 흐름이다.

2) source of truth는 코드베이스 바깥에 두면 약해진다

leerob의 메모는 아주 단순하지만 강하다.

소스 코드는 진실의 원천이거나, 진실로 가는 경로를 가져야 한다.
에이전트는 스스로 검증할 수 있어야 한다.
AGENTS.md는 간결해야 한다.

이 세 가지는 AI 제품에도 그대로 들어맞는다.

문서와 실제 동작이 따로 놀면 에이전트는 쉽게 헷갈린다.
데이터와 UI가 따로 놀면 사용자는 신뢰를 잃는다.
규칙이 길고 모호하면 에이전트는 핵심을 놓친다.

즉, source of truth는 “어딘가에 있는 문서”가 아니라 실행 가능한 경로다. 읽을 수 있고, 검증할 수 있고, 필요하면 다시 돌려볼 수 있어야 한다.

3) local-first는 가장 먼저 보여줘야 하는 신뢰 장치다

SQL→ERD 도구가 강한 이유는 기능이 많아서가 아니다. 오히려 반대다. 브라우저 안에서 실행되고, 아무것도 업로드하지 않는다는 문장이 먼저 보이기 때문이다.

이건 보안 고지 이상이다. 제품 심리학에 가깝다.

민감한 입력을 바로 서버에 보내지 않는다.
가입 전에 가치를 보여준다.
사용자는 “일단 믿어도 되는가”를 바로 판단한다.

AI 코딩 에이전트도 똑같다. 코드베이스, 내부 문서, 운영 로그, 고객 데이터를 다룬다면 첫 번째 질문은 “얼마나 강력한가”가 아니다. **“어디까지 로컬이고, 어디서부터 외부인가”**다.

4) 루프는 반복이 아니라 종료 설계다

루프 엔지니어링이 유용한 이유는 AI에게 일을 반복시키는 데 있지 않다. 언제 멈추고, 무엇으로 멈췄다고 판단할지를 정하는 데 있다.

좋은 루프에는 최소한 아래가 들어간다.

run_id
step log
검증 기준
사람 개입 지점
실패 후 복구 경로

이게 없으면 루프는 그냥 비용이다. 하지만 이 다섯 개가 있으면, 루프는 에이전트의 학습 엔진이 된다.

실제 사례 / 원문에서 본 신호

`re_gent`가 보여준 것

AI 코딩 에이전트는 파일을 바꾸는 것보다 왜 그 줄을 바꿨는지가 더 중요할 때가 있다. re_gent는 바로 그 점을 건드린다. 결과 중심이 아니라 과정 중심으로 세션을 기록한다.

`leerob` 메모가 보여준 것

좋은 에이전트는 자기 일을 스스로 검증할 수 있어야 한다. 테스트, 린터, typed language, concise instructions는 전부 같은 메시지를 향한다. 검증 없는 자동화는 신뢰를 만들지 못한다.

SQL→ERD 도구가 보여준 것

“아무것도 업로드하지 않는다”는 문장은 단순한 기능 설명이 아니다. 사용자의 불안을 줄이는 첫 문장이다. AI 제품도 이 정도의 명확함이 필요하다.

루프 엔지니어링이 보여준 것

반복은 강력하지만, 멈출 수 있어야 한다. 멈출 수 없으면 실험이고, 멈출 수 있으면 제품이다.

실전 활용 팁: [독자 행동]

AI 유틸이나 코딩 에이전트를 만드는 팀이라면 아래를 먼저 붙여라.

run_id를 만든다.
입력, 도구, 출력, 검증 결과를 한 묶음으로 저장한다.
읽기 전용 단계와 쓰기 단계는 분리한다.
실패한 step만 다시 돌려볼 수 있게 한다.
사용자 화면 옆에 아주 짧은 log view를 붙인다.
“무엇이 완료인가”를 한 줄로 적는다.

이렇게 하면 제품의 설명력이 올라간다. 무엇보다, 사용자가 에이전트를 “마법 상자”가 아니라 작업 시스템으로 보게 된다.

바로 해볼 실험

오늘 만들고 있는 AI 기능 하나만 골라서 아래 실험을 해보면 된다.

실행마다 run_id를 찍는다.
입력과 출력 사이에 도구 호출 로그를 남긴다.
검증 결과를 반드시 기록한다.
실패한 step을 1번만 replay해 본다.
그 기록을 사용자에게 보이는 형태로 한 줄 정리한다.

중요한 건 더 많은 기능이 아니다. 나중에 다시 볼 수 있는가다.

리스크 / 반론

물론 모든 제품이 무거운 감사 로그를 가져야 하는 건 아니다.

로그가 너무 많으면 noise가 된다.
민감 데이터는 더 적게 보여야 한다.
공개 가능한 증거와 내부 운영 기록은 분리돼야 한다.

그래서 정답은 전부 공개가 아니라, 필요한 증거를 최소한으로, 하지만 되돌릴 수 있게 남기는 것이다.

결론

AI 코딩 에이전트의 해자는 모델 이름이 아니다. 실행 증거, source of truth, self-verification, replay 가능성이다.

똑똑한 에이전트는 많아질 것이다. 하지만 운영에서 살아남는 에이전트는 적다. 그 차이는 결국 질문 하나로 갈린다.

이 에이전트는 결과를 보여주는가, 아니면 결과가 만들어진 경로까지 증명하는가?