AI 시대 소프트웨어 테스트 — 개발자의 일은 왜 여전히 유효한가

핵심 메시지

• DORA 연구에 따르면 가장 효과적인 엘리트 조직에서는 개발자가 테스트 자동화를 책임진다. 테스트를 남에게 떠넘기는 조직은 그 범주에 들지 못한다.
• 코드를 던지며 '테스트를 만들어 줘'라고만 하면, 그 코드가 옳다는 암묵적 가정 아래 버그까지 그대로 테스트로 굳어진다.
• 테스트가 초록불(통과)을 내는 것만 보고 안심하면 '이해의 외주화'에 빠진다. 통과 여부가 아니라 '내가 무엇을 만들고 있는지 이해하는가'가 진짜 피드백이다.
• AI는 TDD의 결을 거슬러 한 번에 한 테스트씩 하지 않고 너무 앞서 나간다. 최종 결과만 학습했을 뿐 코드가 만들어지는 과정을 배우지 않았기 때문이다.
• AI의 가장 좋은 쓰임새는 테스트 대행이 아니라 아이디어 생성과 증강이다. '이 코드의 세 가지 버전을 보여 줘', '내가 놓친 것은?'처럼 관점을 넓히는 보조로 쓸 때 가치가 크다.

쉽게 이해하기

모던 소프트웨어 엔지니어링 채널의 에밀리 B와 케빈 헤니는 'AI 시대에도 테스트가 개발자의 일인가'라는 큰 질문을 두고 대담한다. 두 사람은 우선 'AI 관련 질문들이 사실은 AI에 관한 것이 아니라, 우리가 지금까지 무엇을 해 왔는가에 관한 것'이라는 점을 짚는다. 금세기 들어 단위 테스트와 종단 간 테스트를 개발자의 업무로 받아들이는 흐름이 커졌지만, 여러 연구에 따르면 가장 흔한 형태의 개발자 테스트는 여전히 '테스트하지 않는 것'이라는 역설이 남아 있다.

문제는 이미 테스트를 하지 않던 조직들이 AI를 '테스트를 계속 안 해도 되는 핑계'로 삼는다는 데 있다. 그러나 DORA 연구는 시장에서 성과를 내는 엘리트 조직일수록 개발자가 테스트 자동화를 책임진다는 결론을 내놓는다. 의료·안전이 걸린 분야처럼 결함률이 중요한 영역에서 테스트는 선택이 아니며, 테스트 없는 CI/CD 파이프라인은 케빈의 표현을 빌리면 'CI/CD 파이프라인이 아니라 그냥 하수관'일 뿐이다. 역설적으로 엘리트 조직조차 'AI가 대신해 주니 우리 책임이 아니다'라고 착각하면 품질이 떨어질 수 있다.

테스트의 본래 목적은 개발자에게 빠르고 잦은 피드백을 줘 더 나은 코드를 쓰게 하는 것이다. 그런데 AI에게 '코드를 짰으니 테스트를 만들어 줘'라고만 하면 두 가지 함정에 빠진다. 첫째, 코드가 옳다는 암묵적 가정 아래 버그까지 테스트로 굳어진다. 회귀(regression)는 잡아 줄지언정 '내 해석이 맞는가'에 대한 검증·확인은 못 해 준다. 둘째, 운 좋게 맞는 테스트가 나와 모두 초록불이 되면 '다 했다'는 느낌만 남고 엣지 케이스와 해석의 사각지대는 그대로 남는다.

케빈은 이를 '초록불을 보며 몽유병처럼 걷는 것'이라 표현한다. 초록불이 주는 도파민에 취해 이해를 외주화하는 위험이다. 한 기계에게 이해를 맡기고 다른 기계에게 생성을 맡긴 뒤 '내 일은 끝났다'고 여기지만, 정작 그것이 옳은지·올바른 일을 하는지·보안은 어떤지 알지 못한다. TDD는 통과할 때의 작은 도파민과 더불어 '무엇을 원하는지 먼저 명세하는' 규율을 주는데, AI 도구는 한 번에 한 테스트씩 가지 않고 너무 앞서 나가 이 결을 거스른다. 최종 체크인된 코드만 학습했을 뿐 그 코드가 만들어진 과정을 배우지 않았기 때문이라는 진단이다.

결론적으로 두 사람은 테스트가 여전히 개발자의 일이라는 데 동의한다. 다만 AI는 일을 '대신'하는 도구가 아니라 '증강'하는 도구로 써야 한다. 새 도구나 관행을 도입하기 전 'AI라는 단어를 빼고, 우리가 풀려는 구체적 문제가 무엇인가'를 먼저 물어야 한다. AI가 정말 잘하는 것은 아이디어 생성과 창의적 보조다. 탐색적 테스트 단계에서 사람이 놓친 경우를 떠올리게 하고, 코드 한 벌이 아니라 '세 가지 버전을 보여 줘', '테스트를 쉽게 만들려면 어떤 모듈화가 좋을까', '내가 놓친 것은?'처럼 다른 관점을 받는 보조로 쓸 때 가장 큰 가치가 나온다. 데이브 팔리가 말한 공학의 두 축, 복잡성 관리와 학습 최적화를 AI가 거들게 하라는 것이다.

주요 인사이트

• AI에게 테스트를 통째로 맡기면 '버그를 테스트로 굳히는' 일이 벌어진다. 코드가 옳다는 검증 없이 회귀 방지만 남고 해석의 정확성은 확인되지 않는다.
• 초록불은 만족스럽지만 위험하다. '작동하는가'를 넘어 '내가 무엇을 만드는지 이해하는가'가 더 중요한 피드백이며, 이해를 외주화하면 보안·정확성을 알 수 없게 된다.
• AI는 최종 결과만 학습해 과정을 모른다. 그래서 한 번에 한 테스트씩 진행하는 TDD의 규율을 거슬러 너무 빨리 앞서 나가는 경향이 있다.
• AI는 '하지 말라'고 명시해도 그 일을 하는 등 열정적이면서도 비협조적인 페어 파트너에 가깝다. 그래서 통제보다 검토가 필요한 도구다.
• 레거시 코드에 AI로 단위 테스트를 무더기로 뽑으면, 리팩터링 한 번에 깨지는 부실하고 취약한 테스트가 나오기 쉽다. 설계가 나쁘면 AI도 더 나은 결과를 내지 못한다.

자주 묻는 질문

관련 AI 소식