AI 시대, 무엇을 근거로 소프트웨어 품질을 보장할 것인가

최근에는 Claude Code나 Codex 등을 사용하여 AI에게 코드를 작성하게 하는 것이 당연해졌습니다.

이런 상황에서 여러분은 무엇을 기준으로 '시스템의 품질이 보장되었다'고 생각하시나요?

좀 전의 시스템 개발에서는 다음과 같은 수치들을 많이 볼 수 있었다고 생각합니다.

• 단위 테스트 코드 커버리지 (Code Coverage)
• 소스코드 스텝 수 대비 테스트 항목 수
• 소스코드 스텝 수 대비 결함(불具合) 수
• 공정별 결함 수

이러한 값들을 IPA의 소프트웨어 개발 데이터 백서 등에 게재된 통계치와 비교하여,

'테스트 밀도나 결함 밀도가 일반적인 범위에서 크게 벗어나지 않으므로, 품질상 문제는 없다'고 판단했습니다.

즉,

'Java로 몇 k 스텝의 소스를 작성했으니, 몇 건 정도의 테스트 항목이 만들어져야 한다'

'게다가 그중 몇 건 정도 결함이 발생하면, 제대로 테스트되었다는 것이다'와 같은 사고방식이었습니다.

물론 당시부터 수치가 기준 내라고 해서 품질이 보장되는 단순한 이야기는 아니었지만,

적어도 이 값들을 사용하여 고객에게 '품질이 보장되고 있습니다'라고 설명하던 시대가 있었습니다.

(지금도 대규모 프로젝트나 예전부터 이어져 온 워터폴 개발의 시스템 등에서는 여전히 유효한 방법이라고 생각합니다)

코딩 AI를 사용하면, 약간 지시하는 것만으로 순식간에 수천 줄의 코드와 방대한 테스트 코드를 생성해 줍니다.

그러면 코드량 대비 충분한 수의 테스트를 했는지라는 양적 중심의 평가는,

품질의 근거로서 이전만큼 설득력을 갖기 어려워졌다고 할 수 있습니다.

코드 커버리지도 마찬가지입니다. 예전처럼 커버리지가 높으니 품질이 높다고 간단히 말할 수는 없습니다.

만약 처음에 AI에게 잘못된 사양(仕様)을 입력했다면, 그 오해에 맞춰 구현과 테스트가 세트로 대량으로 만들어질 가능성이 있습니다.

그 결과 '커버리지 100%, 모든 테스트 성공, 하지만 사양을 충족하지 못함'이라는 상황이 충분히 발생할 수 있습니다.

이렇게 예전 방식으로는 품질을 표현하기 어려워진 우리는, 무엇을 기준으로 품질이 보장되었다고 판단해야 할까요?

다시 생각해 보니, 새로운 품질 보증 기준이 필요한 것인지 고민하던 끝에,

결국 요구되는 것은 옛날부터 변하지 않은 것이 아닐까라는 깨달음을 얻었습니다.

필요한 것은 '요구를 충족하고 있음을 확인할 수 있는 것'입니다.

예전부터 사용되어 온 V자 모델이라는 사고방식에서도, 요구사항이나 설계와 그것을 검증하는 테스트 공정을 대응시켜 생각합니다. 즉, 완성된 코드에서 그것이 작동하는지 확인하는 것을 넘어, 요구/사양을 기점으로 하여 그것을 충족하고 있는지 확인한다는 생각입니다.

돌아보면, 백서와의 비교 역시 품질이 높다는 것을 증명하기보다는,

'이 기능만 결함이 제로인 것은 이상하다', '여기만 테스트가 극단적으로 적다'와 같은 이상함을 발견하기 위한 도구였던 것 같습니다. 즉, 수치 자체가 품질을 나타낸 것이 아니라, 품질의 근거는 원래 요구사항을 충족했는지 여부에 있었던 것입니다.

AI 시대에 완전히 새로운 품질 보증 사고방식이 필요했던 것은 아닐지도 모릅니다.

오히려 예전부터 언급되어 온

• 요구사항과 테스트의 추적성 (Traceability)
• 구현과 검증의 독립성
• 위험 기반 테스트 (Risk-based Test)
• 인간에 의한 리뷰 (Human Review)

같은 기본적인 사고방식이 그 어느 때보다 중요해지고 있는 것 같습니다.

이 중에서 AI 시대에 특히 의미가 달라졌다고 느끼는 것이 '구현과 검증의 독립성'입니다. 예전부터 만든 사람과 테스트하는 사람을 분리한다는 생각이 있었습니다. 자신이 만든 것을 스스로 테스트하면, 같은 착각으로 테스트하게 되기 때문입니다.

AI의 경우, 이것이 더욱 극단적으로 발생합니다. 동일한 AI에게 일련의 대화 흐름 속에서 구현과 테스트를 모두 작성하게 한다면, 동일한 오해가 포함되기 쉽습니다. 앞서 말한 '커버리지 100%, 하지만 사양을 충족하지 못함'은 바로 이런 케이스를 지적합니다.

따라서 AI를 사용할 때는 만들는 쪽과 확인하는 쪽을 의식적으로 분리하는 것이 중요하다고 생각합니다.

• 구현한 AI와는 다른 세션(다른 에이전트)에, 구현이 아닌 요구/사양으로부터 테스트 관점을 도출하게 한다.
• 인수 조건(무엇이 완료되었을 때 완성인가)은 인간이 정하고, 테스트로 실행할 수 있는 형태로 만들어 둔다.
• 인간은 테스트 코드를 한 줄씩 읽기보다는, 테스트 관점이 요구사항을 포괄하는지 여부를 리뷰한다.

또한, AI는 테스트가 실패했을 때, 구현이 아닌 테스트의 기대값(Expected Value)을 수정하여 통과시켜 버리는 경우가 있습니다.

애써 독립적으로 만든 테스트도, 구현 측의 AI가 수정해 버리면 의미가 없습니다.

인수 테스트는 AI에게 변경시키지 않도록 하고, 테스트 기대값의 변경은 반드시 인간이 리뷰하는 등, 검증하는 쪽을 보호하는 것도 필요합니다.

'어떻게 만들 것인가'는 AI에 맡겨도, '무엇이 옳은가'의 정의는 인간이 가지고 있습니다.

여기서 분리해 놓으면, AI가 대량으로 코드나 테스트를 만들어내더라도 그것을 요구사항에 비추어 검증할 수 있습니다.

다만, 독립성으로 방지할 수 있는 것은 AI의 오해까지입니다.

사양 자체가 잘못되었거나 모호하다면, 다른 AI도 같은 사양으로부터 동일한 오류를 포함한 테스트를 만들어냅니다.

그렇기 때문에 인수 조건은 인간이 고객과 합의한 후에 결정해야 합니다.

한편으로는, 사양의 모호하거나 상충되는 점을 AI에게 찾아내게 하는 것은 강점 분야이므로, 사양을 확정하는 단계에서도 AI를 활용할 수 있을 것이라고 생각합니다.

AI로 대량의 코드를 작성하게 된 지금도 'AI가 만든 코드는 신뢰할 수 없다', 'AI는 그럴듯한 모습으로 틀린다'와 같은 의견이 있습니다.

그렇다면, AI에 의한 개발 속도 향상은 품질을 희생하면서 이루어지고 있는 것일까요?

지금까지의 개발에서는,

'테스트를 더 많이 하는 것이 좋다'

'영향 범위를 더 조사하는 것이 좋다'

'리뷰를 더 철저히 해야 한다'와 같이 알고 있어도, 결국 인간의 공수가 필요했습니다.

그 때문에 현실적으로는, 해도 좋은데 그 정도까지 할 시간이 없는 경우가 적지 않았습니다.

단위 테스트는 생략하고 통합 테스트로 한 번에 확인하자 같은 것도 실제 현장에서는 흔한 일이었습니다.

하지만 AI는 코드뿐만 아니라,

• 테스트 관점의 도출
• 변경 영향 범위 조사
• 사양과 구현 비교

등에도 활용할 수 있습니다.

즉, AI를 통해 구현 비용뿐만 아니라, 품질을 확인하기 위한 비용도 낮출 수 있다는 것입니다.

AI 코딩이라고 하면, 이전에는 10일 걸리던 구현을 3일에 만들 수 있다 같은 생산성의 이야기로 흐르기 쉽지만, 그 절약된 7일을 모두 비용 절감으로 생각할 필요는 없습니다.

그 일부를, 지금까지 공수 문제로 할 수 없었던 품질 활동에 사용할 수도 있는 것입니다.

다만, 여기서 앞선 절에서 언급한 독립성이 중요합니다.

구현한 AI에게 그대로 테스트나 리뷰를 시키는 것이 아니라, 사양을 기점으로 다른 시점에서 확인하게 함으로써 비로소 AI에 의한 품질 활동에 의미가 생깁니다.

또한, AI가 생성하는 양에 대해 인간이 모든 것을 상세히 리뷰하는 것은 현실적이지 않습니다.

금액 계산, 권한, 개인정보, 외부 연동 등 리스크가 큰 부분에 인간의 리뷰를 집중시키는 것입니다.

이것은 예전부터 있는 리스크 기반 사고방식이지만, AI 시대에는 더욱 중요해질 것이라고 생각합니다.

여기까지의 이야기를 바탕으로 처음 질문으로 돌아갑니다.

백서와의 비교 대신, 고객에게 무엇을 보여줘야 우리가 '품질을 보장했다'고 말할 수 있을까요?

저는 얼마나 테스트했는지라는 양이 아니라,

'누가 정당성을 정의하고, 무엇을 사용해 독립적으로 확인했으며, 어디를 중점적으로 봤는가'를 보여주는 것이라고 생각합니다.

구체적으로는, 예를 들어 다음과 같은 것입니다.

테스트가 제대로 오류를 발견할 수 있는지 측정할 수 있기 때문에, AI가 대량 생산한 테스트의 품질을 확인할 지표로서 적합하다고 생각합니다.

또한, 커버리지나 테스트 건수가 필요 없어지는 것은 아닙니다.

너무 낮으면 명백히 부족하다는 최소 라인의 확인이나, 예전 백서 비교 같은 이상에 눈치채기 위한 도구로서는 지금도 사용할 수 있습니다.

다만, 그것 자체를 품질의 근거로 제시하기는 어려워졌다고 생각합니다.

참고로, 표와는 성격이 조금 다르지만, 릴리스 후 장애 발생률이나 복구 시간도 함께 보여줄 수 있으면 좋을 것 같습니다.

이것은 릴리스 시점의 품질이라기보다는, 문제가 생겨도 빨리 감지하고 고칠 수 있는 체제가 있다는 것을 보여주는 것입니다.

AI 시대가 되면서, 코드량이나 테스트량 같은 양적 지표만으로 품질을 설명하는 것은 이전보다 어려워지고 있습니다.

반면, 요구사항에서 테스트를 생각하는 것, 요구사항과 테스트를 연결하는 것, 구현과 검증을 분리하는 것, 리스크가 높은 곳을 중점적으로 보는 것 등, 예전부터의 원칙은 오히려 중요해지고 있습니다.

그리고 AI를 이전에는 비용적으로 어려웠던 품질 활동에도 사용할 수 있게 된다면, 더 높은 품질을 목표로 할 수 있을 것이라고 생각합니다.

'무엇으로 품질을 보장할 것인가'.

그 답 중 하나는 '양(量)이 아니라, 정확성(正しさ)의 정의와, 그것을 독립적으로 확인한 구조를 보여주는 것'이 아닐까 하고 생각합니다.

AI 시대이기 때문에야말로, 다시 한번 소프트웨어 품질의 기본으로 돌아갈 필요가 있을지도 모릅니다.

• IPA「소프트웨어 개발 데이터 백서 2018-2019」

IPA「소프트웨어 개발 분석 데이터 집 2022」

• 백서의 후속격인 본 데이터 집 역시 사업 종료에 따라 2022년판이 최종판입니다.