저는 코딩 작업을 여러 모델에 배분할 때 다음과 같은 간단한 질문을 던지곤 했습니다.

이 작업에 충분히 강력한 모델은 무엇인가?

그 질문은 여전히 유용하지만, 이제 제가 가장 먼저 던지는 질문은 아닙니다.

더 나은 첫 번째 질문은 다음과 같습니다.

출력을 얼마나 빨리 검증할 수 있는가?

이 질문은 제가 저비용 모델을 사용하는 방식을 바꾸어 놓았습니다. 저는 저비용 모델을 메인 코딩 모델을 대체하는 약한 모델로 취급하지 않습니다. 대신 검증 경로 (verification path)가 짧은 작업에 유용한 작업자(workers)로 취급합니다.

레벨 1: 출력을 직접 검사할 수 있는가?

어떤 작업들은 출력이 눈에 보이기 때문에 검토 비용이 저렴합니다.

예시:

• README 정리
• 사용 예시 (usage examples)
• 주석 (comments)
• 변경 사항 기록 (changelog notes)
• 작은 포맷팅 스크립트 (small formatting scripts)
• 이슈 템플릿 (issue templates)

만약 모델이 형편없는 README 단락을 작성한다면, 저는 그것을 바로 볼 수 있습니다. 모호한 문구를 추가한다면, 저는 그것을 삭제할 수 있습니다. 실패는 짜증스럽지만, 비용은 저렴합니다.

이것이 바로 저비용 모델이 유용한 지점입니다.

레벨 2: 테스트를 실행할 수 있는가?

다음으로 좋은 카테고리는 테스트 가능한 작업입니다.

만약 제가 기대되는 동작을 설명하고 테스트 스위트 (test suite)를 실행할 수 있다면, 저는 첫 번째 초안을 더 저렴한 모델로 배분하는 데 더 기꺼이 동의합니다.

하지만 프롬프트 (prompt)에는 경계가 필요합니다.

다음 대신에:

이 헬퍼 함수에 대한 테스트를 추가해줘.

저는 다음과 같이 작성할 것입니다:

빈 입력 (empty input), null 입력, 중복 값, 잘못된 설정 (invalid config), 기본 설정 (default config), 그리고 일반적인 입력에 대한 테스트를 추가해줘. 런타임 코드 (runtime code)는 변경하지 마.

차이는 작지만, 이는 모델이 검증 프레임 (verification frame) 안에서 작동하도록 강제합니다.

레벨 3: 수동으로 검증할 수 있는가?

어떤 작업들은 자동화된 테스트는 없지만, 여전히 명확한 수동 확인 절차가 있습니다.

예시:

• CLI 출력 포맷팅
• 설정 (config) 예시
• 마이그레이션 드라이 런 (migration dry-run) 노트
• 작은 데이터 변환 스크립트

이러한 작업의 경우, 저는 모델에게 다음 사항을 포함하도록 요청합니다:

1. 실행 방법
2. 어떤 입력을 사용할지
3. 어떤 출력을 기대할지
4. 어떤 에지 케이스 (edge cases)를 확인해야 할지

만약 모델이 자신의 출력을 어떻게 검증하는지 설명하지 못한다면, 저는 그 패치 (patch)를 신뢰하지 않습니다.

레벨 4: 숨겨진 동작을 변경할 수 있는가?

이 지점에서 저는 속도를 늦춥니다.

작은 리팩토링 (refactors)은 종종 보이는 것보다 더 위험할 수 있습니다.

차이점 (diff)은 짧을 수 있습니다. 코드는 더 깔끔해 보일 수도 있습니다. 하지만 폴백 경로 (fallback path), 기본값 (default value), 권한 확인 (permission check), 또는 호환성 분기 (compatibility branch)에서 동작이 변경될 수 있습니다.

저는 다음과 같은 작업을 건드릴 때 위험 수준을 높입니다:

• 폴백 (fallbacks)
• 기본값 (defaults)
• 라우팅 (routing)
• 권한 (permissions)
• 결제 (billing)
• 속도 제한 (rate limits)
• 마이그레이션 (migrations)
• 하위 호환성 (backwards compatibility)

이러한 실패는 코드 리뷰 (code review)에서 항상 명확하게 드러나지는 않습니다. 이를 알아차리려면 맥락 (context)이 필요합니다.

저의 현재 라우팅 규칙

저는 검증 비용 (verification cost)에 따라 라우팅합니다:

• 낮은 검증 비용: 저비용 모델 (low-cost model)이 초안을 작성할 수 있음.
• 중간 검증 비용: 저비용 모델이 초안을 작성하고, 사람이 수정함.
• 높은 검증 비용: 강력한 모델 (strong model)이 도움을 줄 수 있지만, 테스트와 사람의 리뷰가 필요함.

이 규칙은 "작은 작업 vs 큰 작업"이라는 기준보다 더 유용합니다.

작은 작업이라도 검증하기 어렵다면 비용이 많이 들 수 있습니다.

핵심 요점

저비용 AI 코딩 모델은 쓸모가 없는 것이 아닙니다.

작업을 검사하기 쉽거나, 테스트하기 쉽거나, 롤백 (roll back)하기 쉬울 때 매우 유용합니다.

AI 코딩에서 비용이 많이 드는 부분이 항상 생성 (generation)인 것은 아닙니다.

종종, 그것은 신뢰 (trust)입니다.