Tec-Blog Technology & DevOps

AI Kim, DongKi

에이전트한테 시킨 일, 어떻게 검수할까 — grep·diff 기반 산출물 검증 습관

TL;DR

  • 에이전트가 “다 됐다”고 해도 믿지 않는다. 산출물을 스펙과 대조하는 1분 검수가 습관이 되어야 한다.
  • 검수는 거창한 게 아니다. grep 한 줄로 “약속한 함수·필드·경로가 실제로 있는가”, diff로 “바뀐 게 요구사항 범위인가”만 봐도 부채의 80%가 걸러진다.
  • 핵심은 수락 기준(acceptance criteria)을 먼저 적는 것이다. 검수할 기준이 없으면 검수도 없다.
  • N=1 경험이다. 완전 자동화가 아니라, 사람이 마지막 한 줄을 책임지는 구조를 권한다.

들어가며

지난번 글(AX 시대를 사는 개발자의 생각 정리)에서 이런 말을 했다. “grep 한 줄로 스펙과 코드가 어긋났는지 바로 확인하는 습관 — 이게 없으면 에이전트의 산출물은 검증 안 된 부채일 뿐이다.”

그 글을 쓰고 한 달 가까이 에이전트와 실제로 일해 보니, 그때보다 더 구체한 검수 루틴이 생겼다. 이번 글은 그 루틴을 정리한 메모다. “어떻게 시킬까”보다 “어떻게 받을까“에 무게를 둔다.

1. 먼저 수락 기준을 적는다 (그게 검수의 전부)

가장 큰 실수는 “이거 만들어 줘”만 던지고 나중에 “음… 잘 한 것 같지?” 하고 마는 것이다. 검수는 작업 이후가 아니라 이전에 정의된다.

카드 하나를 줄 때 나는 이 세 가지를 반드시 적는다.

  • 입력/출력 형태 — “함수 시그니처는 mapSku(List<String>)이고, 리턴은 List<Product>”
  • 완료 조건 — “SKU 범위 표기 A-100~A-103이 상품 4건으로 펼쳐지는 것까지”
  • 금지 사항 — “하드코딩 금지, 기존 API prefix 유지”

이게 있으면 검수는 “잘했나?”가 아니라 “조건 1·2·3이 충족됐나?“가 된다. 주관이 빠지니 속도도 붙는다.

2. grep — “약속한 게 진짜 있나” 확인

에이전트는 자신 있게 틀린 걸 준다. 특히 “리팩터했는데 동작은 똑같다”는 말을 들었을 땐, 변경한 심볼이 진짜 남아있는지 의심해야 한다.

# 약속한 함수가 실제로 정의되어 있는가
grep -rn "A-100" src/ || echo "MISSING"

# 금지한 하드코딩이 안 들어갔는가
grep -rn "A-100" src/ && echo "HARDCODE DETECTED"

# 바꿔야 할 prefix가 아직 남아있지 않은가
grep -rn "/v1/old/" src/ && echo "STALE PREFIX"

포인트는 찾아야 할 게 아니라 “없음”을 증명하는 데 있다. || echo MISSING 패턴으로 누락을 즉시 드러낸다. 이 한 줄이 수동 읽기보다 훨씬 엄격하다.

3. diff — “바뀐 게 요구 범위인가” 확인

에이전트가 넘긴 PR을 통째로 믿지 않는다. git diff로 “손댄 파일이 요청한 범위인가”만 본다.

# 이번 태스크와 무관한 파일이 함께 바뀌지 않았는가
git diff --name-only main...HEAD

# 의도한 파일 외에 config/스키마가 바뀌진 않았는가
git diff --stat

실제로 겪은 적 있다. 조건 추출 로직 하나만 고치게 했는데, 같이 온 diff에 공용 유틸리티 함수 시그니처가 바뀌어 있었다. “그냥 정리했어요”였는데, 다른 카드 3개가 그 시그니처에 의존하고 있었다. diff를 안 봤으면 다음 날 장애였다.

4. 정답지 대조 — “기대 출력이 맞는가”

도메인마다 기준이 되는 정답(ground truth)이 있으면, 에이전트 출력을 그걸로 채점한다. 코드를 읽는 게 아니라 출력값을 대조하는 게 더 빠르다.

# 입력값을 넣고 나온 상품 ID 목록을 정답지와 비교
python score.py --pred pred.json --gold gold.json
# expected: ORDER_PAID -> 3, SHIPPED -> 5

이 방식의 장점은 “코드가 그럴듯한가”가 아니라 “결과가 맞는가“로 평가한다는 점이다. LLM 파이프라인처럼 중간 로직을 사람이 다 읽기 힘든 경우일수록 출력 대조가 유리하다.

5. 검수는 병목이 아니라 안전장치

에이전트가 빨라지면 사람 검수가 병목이라는 말이 나온다. 맞다. 하지만 병목을 없애려고 검수를 빼면, 속도만큼 부채가 쌓인다.

내 기준은 이렇다. 마지막 한 줄은 내가 본다. 초안은 기계가 써도, “이 카드가 끝났다”고 선언하는 건 사람이다. grep·diff·정답지 대조라는 가벼운 삼단 검수로 그 선언의 신뢰를 확보한다.

마무리

  • 검수의 시작은 “수락 기준을 먼저 적는 것”이다. 기준이 없으면 검수도 없다.
  • grep로 존재 증명, diff로 범위 증명, 정답지로 출력 증명 — 이 세 줄이면 부채 대부분이 걸러진다.
  • 완전 자동화보단 “기계가 초안, 사람이 마지막 검수” 구조를 권한다. N=1이지만, 지금까지는 이게 가장 적게 깨졌다.

이 글도 방향은 내가 정하고 초안은 에이전트가 썼다. 그리고 이 검수 루틴대로, push 직전에 diff 한 번 더 봤다.

Comments