JetBrains 블로그에 Kerry Beetge가 기고한 글에 따르면, 출시 직전에 애플리케이션을 테스트하는 것만으로는 현대 소프트웨어의 품질을 보장하기에 더 이상 충분하지 않다. 핵심은 소프트웨어 개발 생명 주기 전반에 품질 검사를 분산해, 추가적인 변경과 복잡성이 누적된 후가 아니라 결함이 입력된 시점에 더 가깝게 발견되도록 하는 것이다.
이 글은 이러한 전환을 인공지능으로 생성된 코드에 대한 의존도 증가와 연결한다. 2025년 Stack Overflow 설문조사를 인용하며 개발자의 84%가 개발 과정에서 인공지능 도구를 사용하거나 사용할 계획이라고 지적한다. JetBrains는 이러한 도구로 생성되는 코드의 양이 늘어나면서 반복 가능하고 확장 가능한 검토가 더욱 중요해진다고 본다. 동시에 자동 생성된 결과물에 오류가 포함될 가능성이 있으므로 인간의 검증은 여전히 필수적이다.
출시 전 관문에서 지속적인 품질 보증으로
이 글은 소프트웨어 품질 보증(SQA)을 개발 주기 전체에 걸쳐 운영 요구 사항, 신뢰성, 보안 및 표준 준수 여부를 추적하는 활동으로, 전통적인 품질 관리(QC)를 주로 최종 제품에 집중하고 결함에 반응적으로 대응하는 활동으로 구분한다. 지속적인 접근 방식은 코드를 작성하거나 통합하는 동안 문제를 발견할 수 있게 하며, 이때는 수정 비용이 더 낮고 변경의 원래 맥락과도 더 밀접하게 연결된다.
이 글은 현대 개발 환경에서 릴리스 주기가 수개월에서 수일로 단축된 반면, CI/CD 파이프라인을 사용하면 제한적인 사람의 개입만으로 코드가 커밋에서 프로덕션으로 이동할 수 있다고 설명한다. 따라서 하나의 도구에 의존하는 것만으로는 충분하지 않다. 각 테스트 계층은 서로 다른 유형의 문제를 발견하기 때문이다.
도구는 실제로 무엇을 다루는가?
- 정적 분석: 코드를 실행하지 않고 검사해 결함, 취약점 및 코딩 표준 위반을 발견한다. 예로 Qodana가 있다.
- 단위 테스트: 함수와 구성 요소가 개별적으로 작동하는지 확인하며, JUnit, Jest, PyTest 및 NUnit 등이 그 예다.
- 통합 테스트: 서비스와 API의 상호 작용 및 데이터 흐름을 검사하며, Postman과 Soap UI 등이 사용된다.
- 기능 테스트 및 인터페이스 테스트: Playwright, Cypress 및 Selenium과 같은 도구를 사용해 브라우저를 통한 사용자 경로를 시뮬레이션한다.
- 성능 테스트: 부하 상황에서의 동작을 측정하고 병목, 메모리 누수 및 느린 쿼리를 발견하는 데 도움을 주며, JMeter, LoadRunner 및 k6와 같은 도구를 사용한다.
- 보안 테스트: SAST, SCA, 종속성 검사, DAST, 그리고 실수로 포함된 비밀 정보나 API 키 탐지를 결합한다.
도구를 어떻게 선택하고 업무에 통합할 것인가?
이 글은 CI/CD와의 통합 수준, 사용 중인 언어와 프레임워크 지원 여부, 반복 작업 자동화 능력, 코드와 팀의 성장에 따른 확장성, 실행 가능한 보고서 제공 여부, 그리고 도구 자체의 보안 관행을 기준으로 도구를 평가할 것을 제안한다.
실행 측면에서는 코드를 작성하는 시점으로 검사를 앞당기고, 반복 테스트를 자동화하며, 모든 커밋 또는 빌드와 함께 테스트를 실행하고, 코드 복잡도·중복·테스트 커버리지와 같은 지표를 통해 기술 부채를 모니터링할 것을 권고한다. 또한 보안 검사를 출시 직전의 별도 검토로 미루지 말고 일반적인 품질 보증 흐름에 포함해야 한다고 강조한다.
certi.news의 시각
이 글이 제시하는 실제 변화는 새로운 테스트를 추가하는 것이 아니라 개발 주기 내에서 품질에 대한 책임을 재분배하는 것이다. 이러한 접근 방식은 출시 간격이 짧거나 분산 아키텍처와 외부 종속성을 사용하는 팀에 유용하다. 그러나 수동 테스트나 엔지니어링 판단을 없애지는 않는다. 자동화, 특히 인공지능에 기반한 자동화는 문제 발견을 가속할 수 있지만, 그 자체만으로 커버리지의 완전성이나 결과의 정확성을 보장하지는 못하기 때문이다. 또한 이 출처는 일반적인 지침과 도구 사례를 제시하지만, 도구 간 비교를 위한 정량적 프레임워크를 제시하거나 성능에 대한 독립적인 비교 결과를 입증하지는 않는다.