제품 코드는 이미 거의 끝난 상태였다. 마지막으로 테스트만 통과시키면 되는 줄 알았는데, tests/shoppingList.test.ts 끝부분의 괄호 하나 때문에 validation이 실패했다.
사람이 보면 “괄호 하나 고치면 끝”인 작업이었다. 그래서 자동화에 맡겼다. 그런데 이 작은 작업이 오히려 AI 자동화에서 무엇을 믿고 무엇을 검증해야 하는지 가장 잘 보여주는 사례가 됐다.
첫 번째 모델은 작업 자체를 끝내지 못했다
자동화는 첫 번째 무료 모델인 Nemotron Super에 작업을 넘겼다. 기대한 건 단순했다.
- 지정한 테스트 파일을 읽고
- 문법 오류가 난 괄호를 바로잡고
- 테스트를 다시 실행하는 것
하지만 첫 worker는 작업을 완료하지 못했다. 그래서 fallback 규칙에 따라 다음 모델로 넘어갔다.
이때까지만 해도 “무료 모델이 한 번 실패했네” 정도였다. 문제는 두 번째 모델부터였다.
두 번째 모델은 시키지 않은 일을 하기 시작했다
North Mini Code가 다음 worker로 들어왔다. 그런데 Windows Runner에서 작업 중인데 Linux 명령을 사용했고, 요청하지도 않은 tests/simple.test.ts 파일까지 새로 만들었다.
여기서 중요한 건 결과가 얼핏 좋아 보일 수도 있다는 점이다. 새 테스트 파일을 만들고 다른 방식으로 문제를 우회하면 최종 테스트가 통과할 가능성은 있다. 하지만 그것은 내가 요청한 수정이 아니다.
“테스트를 통과시켜라”만 목표로 두면 agent는 생각보다 넓은 범위에서 방법을 찾을 수 있다. 반대로 “이 파일의 이 오류만 고쳐라”가 진짜 요구사항이라면, 변경 범위를 시스템에서 제한해야 한다.
write-path guard가 작업을 막았다
자동화에는 허용된 파일 경로 밖의 변경을 감지하는 guard를 넣어둔 상태였다.
이번 작업에서 허용한 것은 기존 테스트 파일 수정이었다. 새 테스트 파일 생성은 허용하지 않았다. 그래서 agent가 tests/simple.test.ts를 만든 순간 guard가 범위를 벗어난 변경으로 판단했고, 자동으로 원복했다.
이 장치가 없었다면 결과만 보고 “테스트 통과했으니 성공”이라고 착각할 수도 있었다.
자동화에서 성공 여부를 판단할 때는 테스트 결과뿐 아니라 무엇이 바뀌었는지도 같이 봐야 한다.
세 번째 모델에서 원래 문제를 해결했다
다시 fallback이 실행됐고 세 번째 모델인 Poolside Laguna가 작업을 맡았다. 이번에는 원래 문제였던 잘못된 괄호를 수정했고, 불필요한 파일을 만들지 않고 작업이 끝났다.
결과만 보면 정말 사소하다.
테스트 파일의 괄호 하나 수정.
하지만 그 한 줄에 도달하기까지 세 개의 모델, fallback, 변경 경로 검증, 자동 원복이 모두 동작했다.
작은 작업이 자동화 품질을 더 잘 드러내기도 한다
복잡한 기능 개발에서는 agent가 여러 파일을 수정하는 것이 자연스럽다. 그래서 예상하지 못한 변경이 끼어 있어도 발견하기 어렵다.
반대로 괄호 하나 고치는 작업에서는 기대 범위가 너무 명확하다. 이때 agent가 새 파일을 만들거나 다른 환경용 명령을 쓰면 시스템의 문제점이 바로 보인다.
이 경험 이후 자동화에서 더 중요하게 본 것은 모델의 “코딩 실력”만이 아니었다.
- 요청 범위를 얼마나 정확히 지키는지
- 실행 환경을 제대로 이해하는지
- 실패했을 때 다음 모델로 안전하게 넘길 수 있는지
- 허용하지 않은 변경을 자동으로 막을 수 있는지
- 마지막 결과가 원래 요구사항과 같은지
AI를 여러 개 연결한다고 자동으로 안정적인 시스템이 되는 것은 아니다. 모델이 틀릴 수 있다는 전제에서 실패를 작게 만들고 되돌리는 구조가 있어야 한다.