자동 프로그래밍은 특정 유즈케이스에서, 제대로 다룰 줄 아는 사람의 손에 들어가면 소프트웨어 작성 속도를 극적으로 높여준다. 내 경험상 그 결과물은 최고 수준의 핸드코딩 소프트웨어가 갖는 구조적 품질이나 복잡도의 경제성에는 미치지 못한다. 하지만 모든 소프트웨어가 뛰어난 것은 아니며, 내 느낌으로는 자동 프로그래밍이 (잘 관리된다는 전제 하에) 대부분의 경우 그럭저럭 잘 만들어진 핸드코딩 코드의 품질은 능가한다.

그럼에도 AI로 새로운 소프트웨어를 작성할 때는 품질과 시간 사이의 트레이드오프가 존재한다. 내가 진행한 일부 프로젝트에서 이 트레이드오프는 극단적이어서, 수개월이 걸릴 만한 프로젝트를 단 몇 주 만에 끝내기도 했다. 하지만 LLM이 품질 타협 없이 프로세스를 자동화하는 훨씬 더 강력하고 새로운 방식을 열어주는 영역도 있다. 그중 하나가 바로 소프트웨어 QA와 테스팅이다.

전통적으로 소프트웨어는 로컬 범위의 테스트와 통합 테스트로 구성된 테스트 스위트로 테스트해 왔다(Redis를 생각해 보자. SET foo 10을 실행한 뒤 GET foo => 10이 되는지를 테스트하는 것과, 이 경우 리플리케이션이 제대로 동작하는지를 테스트하는 것은 전혀 다른 문제다). 그리고 보통 수동으로 수행되는 QA 과정을 거치는데, 이는 실행 가능한 테스트 스위트가 놓치는 구멍을 잡아낼 수 있다. 코드의 모든 라인을 커버한다고 해서 가능한 모든 상태를 커버하는 것은 아니라는 것은 잘 알려진 사실이다. 게다가 통합 테스팅은 구조적으로 어렵다. 타이밍 이슈, 환경 구성, 시각적으로만 확인할 수 있고 자동으로 검증할 수 없는 품질 지표 등 여러 요인 때문에 시간이나 물류적 제약으로 제대로 활용하지 못하는 테스트 기회가 많이 남는다.

LLM은 기존 테스팅 방법론에 더해 QA를 수행하는 새로운 방식을 제공한다. 아이디어는 AI 에이전트에게 QA 엔지니어로서 새 릴리스에 대해 여러 수동 테스팅을 수행하도록 요청하는 마크다운 파일을 만드는 것이다. 예를 들어 오픈 웨이트 LLM용 추론 엔진인 DwarfStar의 경우 나는 다음과 같은 방식을 사용한다. 마크다운 파일에서 에이전트는 이미 릴리스된 소프트웨어 프로젝트 버전을 기준으로 어떤 새로운 커밋이 추가되었는지 확인하도록 요청받는다. 그리고 모델에게는 수행해야 할 작업 목록이 전달되는데, 예를 들면 다음과 같다.

• MacBook A와 MacBook B에 걸쳐 분산 추론이 동작하는지 확인하고, 출력이 일관되는지, 두 머신에 있는 모든 GGUF 파일에서 추론이 정상적으로 동작하는지 등을 확인한다.
• 이번 릴리스에 속도 회귀가 없는지 확인한다.

등등이다. 특히 속도 회귀 부분에서는 이전에 기대되던 속도가 얼마였는지 에이전트에게 알려줄 필요가 없다는 점이 주목할 만하다. 이는 새로운 릴리스와 최적화에 따라 계속 바뀌는 움직이는 목표이기 때문이다. 마찬가지로 분산 추론을 위한 통합 테스트도 많은 지침을 필요로 하지 않는다. 파일 시작 부분에는 SSH 엔드포인트와 사용할 키, 경로 등이 적혀 있을 뿐이다.

에이전트는 길게 나열된 QA 활동들을 *특히* 추가된 커밋을 고려하여 점검하도록 요청받는다. 변경 사항을 살펴보고 어떤 부분에 영향을 줄 수 있는지 파악하는 것부터 시작함으로써, QA 과정이 특정 회귀를 찾는 데 특화되도록 하는 것이다.

Redis Arrays의 경우에도 비슷한 방법론을 사용해 에이전트에게 배열 기반의 대규모 Redis 애플리케이션을 구축하고, 리플리케이션과 영속성이 갖춰진 프로덕션 환경을 설정한 뒤, 여러 사용자가 며칠 동안 애플리케이션을 사용하는 상황을 시뮬레이션하며 뭔가 이상한 점이 없는지 확인하도록 했다.

이러한 접근을 활용한 테스팅은 소프트웨어 품질의 좀 더 심리적인 측면으로까지 확장될 수 있다. 에이전트에게 사용자의 관점에서 놀랍게 느껴지거나, 문서화가 충분하지 않거나, 전반적으로 허술해 보이는 모든 새로운 기능을 식별하도록 요청하는 식이다. 이전에는 모두 수동으로 수행해야 했고, 대부분의 경우 사실상 건너뛰었던 일들이다.

자동화된 QA의 도입이 새로운 소프트웨어 릴리스의 품질 기준을 높이고, 어쩌면 자동 프로그래밍을 이용해 고속으로 생산된 코드의 낮은 품질을 부분적으로 상쇄할 수 있을 것 같은 느낌이 든다.