TL;DR

  • AI 에이전트가 작성한 코드를 읽지 않고 사용하더라도, 원하는 결과가 나왔는지 확인할 수 있는 검증 방법을 사람이 이해해야 함.
  • 코드를 보지 않고 소프트웨어를 만드는 일이 늘고 있지만, 출력과 동작을 살펴 의도에 부합하는지 확인하는 검증은 여전히 필요함.
  • AI가 자기 코드의 테스트를 작성할 수는 있지만, 테스트도 블랙박스로 취급하면 검증 문제를 해결하는 대신 다른 곳으로 옮길 뿐임.
  • 개발자나 에이전트의 오류 점검용 테스트와 이해관계자가 요구사항 충족 여부를 확인하는 테스트는 구분되며, 후자는 사람이 읽고 이해해야 함.
  • 수동 품질 보증(QA), 단위·통합 테스트, 정적 타입, 형식 검증, 적대적 AI 리뷰 등에서 문제에 맞는 방식을 선택하고 사람이 결과를 판단해야 함.

코드를 보지 않는 개발과 검증

  • 많은 사람이 더는 코드를 직접 읽지 않으며, 에이전트가 만든 소프트웨어를 블랙박스처럼 사용하고 원하는 기능이 빠졌을 때 추가로 요청하는 방식이 가능해짐.
  • 이런 방식이 적절한지는 상황에 따라 다르지만, 일회성 스크립트부터 핵심 인프라까지 다양한 코드 가운데 일부는 이제 코드를 보지 않고 작성할 수 있음.
  • 여기서 ‘보지 않는다’는 것은 동작까지 확인하지 않는다는 뜻이 아님. 코드 대신 스크립트의 출력이 그럴듯한지, 인터페이스가 올바르게 보이고 원하는 일을 하는지 살펴볼 수 있음.
  • 테스트, 타입 시스템, 형식 증명뿐 아니라 어떤 방식으로든 AI가 만든 결과물이 의도에 대체로 부합하는지 확인하는 과정이 검증임.

에이전트가 작성하는 테스트

  • AI가 자기 코드의 테스트를 작성하는 일은 흔하며, 테스트도 코드처럼 작성과 유지보수 부담이 있으므로 자동 작성 테스트에도 가치가 있음.
  • 다만 테스트를 읽거나 읽을 수 있는지에 따라 그 가치가 달라짐.
  • 코드와 마찬가지로 테스트가 의도한 일을 하는지 확인해야 하며, 테스트까지 블랙박스로 취급하면 검증 문제를 해결하지 못하고 위치만 옮기게 됨.

두 종류의 테스트

  • 테스트는 크게 두 종류로 볼 수 있음.
  • 개발자나 에이전트가 자기 작업의 오류를 확인하는 테스트임.
  • 이해관계자인 사람이 요구사항 충족 여부를 검증하는 테스트임.
  • 첫 번째 종류도 가치가 있지만, 두 번째 종류도 여전히 필요함.
  • 두 번째 종류의 테스트가 검증 역할을 하려면 이해관계자가 직접 테스트 내용을 확인할 수 있어야 함. 테스트를 직접 작성하지 않았더라도 테스트는 자신의 의도를 표현하므로 읽고 이해해야 의미가 있음.
  • 읽어 본 적 없는 단위 테스트 모음이 모두 통과하더라도 에이전트의 작업에 내부적으로 도움이 될 수는 있지만, 외부인에게 소프트웨어의 상태를 알려주지는 않음.

핵심은 테스트가 아님

  • 소프트웨어 검증에는 수동 품질 보증(QA), 단위 테스트와 통합 테스트, 정적 타입, 형식 검증, 명세나 요구사항 목록을 기준으로 한 적대적 AI 리뷰 등 여러 방법이 있음.
  • 각 방법은 유지보수 부담, 민첩성, 엄밀성, 수작업의 양, 문제 영역에 대한 적합성 측면에서 서로 다른 절충점을 가짐.
  • 중요한 것은 사람이 이해할 수 있는 결과상의 증거가 있다는 점임. 극단적으로는 ‘프로덕션에서 문제가 생겼는가?’도 검증이지만, 가능하면 그 전에 알아내는 편이 바람직함.
  • 읽지 않을 코드를 작성할 때는 그 코드가 원하는 일을 하는지 언제, 어떻게 알 수 있을지 고려해야 함.
  • 때때로 수동 테스트만으로 충분할 수 있음.
  • 눈으로 확인하거나 실행 결과가 괜찮은 테스트만으로 충분할 수 있음.
  • 위험 수준에 따라 사용자에게 바로 배포하고 로그를 확인할 수도 있음.
  • 형식 증명이 필요할 수도 있음.
  • 어떤 방식을 선택하든 AI가 검증을 대신해 줄 수는 없음. 검증 결과를 직접 파악하고 생각해야 하며, 그것이 마지막으로 사람이 해야 할 일일 수도 있음.