그토록 믿음직하던 AI가 부실한 테스트 케이스를 만들어오는 이유에 대해 생각해 보았다

NewsPicks에서 QA 엔지니어를 하고 있는 니시조노(@yurizono)입니다. 본고에서는 제가取り組んでいる AI4QA에 관한 이야기를 하겠습니다.

저보다 훨씬 제대로 된 코드를 작성해 주는 LLM(Large Language Model) 군이지만, QA스러운 태스크가 되는 순간 미덥지 않게 보입니다. 이것은 제가 QA 엔지니어로서 제 직업에 자부심을 느끼고 있기 때문인지, 아니면 무언가 잘 풀리지 않는 이유가 있는 것인지. 제가 도달한 결론을 한마디로 표현하자면 "프로덕트에 특화된 컨텍스트(Context)의 정비가 부족했다"입니다.

저희 QA 팀은 테스트를 수행하기도 하지만, 툴 제공이나 기반 정비, 즉 개발자에 의한 개발 프로세스에 접근하여 품질 향상을 목표로 하는 것이 주요 활동입니다.

올해 초 SRE(Site Reliability Engineering)와 QA 팀의 합병이 있었고, 니시조노 개인으로서는 SRE 영역에도 손을 뻗어보자는 생각으로 NewsPicks Web 버전의 인프라 개선을 하고 있었습니다. 익숙하지 않은 CDK(Cloud Development Kit)를 작성하고, 익숙하지 않은 인프라 릴리스를 하며 몇 번인가 장애를 일으키기도 했습니다 (입장이 바뀌면……). 이 과정에서 저 자신도 개발 엔지니어로서 AI를 최대한 활용해 보았고, 덕분에 모두가 사용하고 있는 Claude Code가 어떤 것인지 감을 잡을 수 있었던 것 같습니다. 결론적으로, 이제 코더(Coder)로서 저의 존재 의의는 남아있지 않았습니다. 이건 이길 수 없습니다.

그런 느낌으로 견습 SRE로서 잠시 즐거운 시간을 보낸 뒤, 이제 이 믿음직한 AI를 본업에서 사용해 보자는 생각으로 이번 봄부터 새로운 활동을 시작했습니다. 그것이 바로 AI4QA(AI for QA)입니다. AI를 QA 프로세스에서 사용해 보자는 것이죠. 이미 개발 현장에서는 당연한 개념이라고 생각합니다만, 그에 대한 저 나름의 접근 방식에 대해 말씀드리겠습니다.

프로젝트의 의사록이나 사양서를 인풋(Input)으로 하여 AI에게 테스트 케이스 작성을 시켜본 적이 있었습니다. 결과적으로 나름대로 테스트 케이스다운 것은 생성해 주어서 '이거 편리하네'라고 생각했습니다만, 막상 그것을 리뷰해 보니 군데군데 관점 누락이 발견되었습니다. '아직 인간의 일은 없어지지 않는구나'라고 조금 아쉬워함과 동시에, '어떻게 하면 만족스러운 퀄리티의 결과물을 내놓게 할 수 있을까'라는 시행착오가 시작되었습니다.

서두에서도 언급했듯이 "프로덕트에 특화된 컨텍스트의 정비가 부족하다"는 점을 깨달았습니다.

방금 말씀드린 프로젝트의 예에서는 프로젝트 내용에 대한 컨텍스트는 어느 정도 갖춰져 있었지만, 그 외의 프로젝트 외부에 있는 컨텍스트가 부족했습니다. 즉, 앞으로 만들 기능이 어떤 것인지는 파악하고 있어서 그에 대한 테스트 케이스는 만들 수 있습니다. 하지만 그렇다면 기존 기능에 미치는 영향은 살펴보고 있는가, 사양서에서 언급되지 않은 사용자 유형에 대한 고려는 누락되지 않았는가라고 묻는다면 부족함투성이였다는 뜻입니다.

이 문맥에서 말하는 "컨텍스트"란, LLM에게 직접 던지는 지시문을 "프롬프트(Prompt)"라고 부르고, 그 외에 LLM이 읽어들이거나 파악하고 있는 모든 것을 "컨텍스트"라고 부릅니다 (어디까지나 제 이해입니다). 인간에 비유하자면 프롬프트가 업무 의뢰라면, 컨텍스트는 "베테랑 사원이 가진 지식을 신입에게 주입하기 위한 온보딩(Onboarding) 자료"와 같습니다. 즉, 다양한 업무의 전제가 되는 지식입니다.

요즘의 LLM은 우수한 엔지니어라고 생각하며, 코드베이스가 있고 사양을 잘 전달할 수 있다면 적어도 저 정도 수준의 개발자에게는 코딩 부분을 통째로 맡길 수 있는 수준입니다. 코더의 폐업은 이제 피할 수 없습니다. 반면, QA의 폐업이라는 이야기는 현재로서는 들리지 않습니다. 여기에 비대칭성이 존재합니다.

왜 코딩을 맡길 수 있는가 하면, "인간을 초월한 속도로 코드를 쓸 수 있기 때문"도 아니고 "코딩이 단순한 태스크이기 때문"도 아닙니다. 코딩을 맡길 경우, 코드를 LLM에게 전달하고 있으며, 또한 "코드를 읽으면 그 코드로 무엇을 하고 있는지 알 수 있기 때문"입니다. What(무엇을 하는가)에 한정한다면 정답이 그곳에 있습니다.

당연히 팀 구성에 따라 채택해야 할 설계는 달라질 것이고, 코드에 다 표현하지 못한 사상도 있을 것이기에 코드 외의 지식이 필요한 장면은 많을 것입니다1. 지금은 그러한 지식을 PR(Pull Request) 리뷰 등을 통해 인간이 보완하고 있는 상태라고 생각합니다만, 현시점에서 "LLM이 코더로서 쓸모가 있다"는 점은 의심할 여지가 없습니다.

그렇다면 QA(Quality Assurance) 활동, 예를 들어 테스트 케이스(Test Case) 작성은 어떨까요(여기서는 일반적인 QA 엔지니어가 만드는 수준의 테스트 케이스, 예를 들어 통합 테스트를 상정합니다). 사양서(Specification)를 LLM에 전달했을 때, "아, 그 관점은 놓치고 있었습니다"라고 개발자에게 깨달음을 줄 수 있는 수준의 테스트 케이스가 나올 수 있을까요? 과거의 수많은 장애를 몸소 경험하고, 평소에 앱을 사용하며 기능에 정통하며, 각 팀이 진행 중인 개발 안건을 횡적으로 파악하고 있는 그런 QA 엔지니어가 수행하는 테스트 설계(Test Design)를 AI가 대체할 수 있을까요? ……제 실감으로도, 아직은 어렵지 않을까 하는 생각이 들었습니다.

사양서에 적힌 내용에 국한된 테스트를 만드는, 이라는 태스크(Task)에 한정한다면 이미 대체가 가능합니다. 이 점은 코더(Coder)와 상황이 다르지 않습니다. 다만, 코딩에 대해서는 "리포지토리(Repository)를 통째로 전달한다", 더 나아가 "리포지토리를 체크아웃한 디렉토리에서 Claude Code를 실행한다"는 것만으로 방대한 컨텍스트(Context)를 LLM에 전달할 수 있는(실제로 읽을지 여부는 차치하고, 읽을 수 있는 상태는 된다) 반면, 테스트 케이스 작성이 되면 갑자기 "사양서 단 한 장"이 되어버리는 것이 현상황이라고 생각합니다. 즉, 우리가 특별히 의식하지 않고 전달할 수 있는 컨텍스트의 크기에 있어, 코딩과 테스트 케이스 작성 사이에는 큰 차이가 있는 것입니다.

위에서는 테스트 케이스 작성이라는 예를 들었지만, 사양서 리뷰, 설계에 대한 브레인스토밍(打ち合わせ), 버그 관리 등 모든 장면에서 이 컨텍스트가 효과를 발휘합니다. 무엇보다 프로덕트 특유의 컨텍스트가 없다면 시책 입안이든 데이터 분석이든, 전제가 되는 지식 없이 맞서게 되어 비효율적입니다. 기대하는 성능도 다 끌어낼 수 없습니다.

AI와 함께하려면, 코딩과 코딩 이외의 태스크 사이에 존재하는 이 차이를 메워야 합니다.

방대한 컨텍스트를 LLM에 전달하면 된다는 것을 알게 된 시점에서, 그렇다면 그것을 어떻게 전달할 것인가를 생각합니다. 컨텍스트라고 해도 기존 사양, 개수 내용, 과거 장애 정보 등 몇 가지 종류가 필요할 것 같습니다. 개수 내용을 전달하지 않고 테스트 케이스를 만들게 하는 사람은 없을 것입니다. 장애는 예전부터 티켓 관리 시스템을 사용하는 것이 당연했으므로, MCP로 연결하는 등의 방식을 취하면 해결될 것 같습니다. 그렇다면 기존 사양은 어떻게 할까요? 두 가지가 떠올랐습니다.

[방법 1: 사양서(Specification)를 활용하는 방법]
단 한 장의 종이에 비하면 낫습니다. 이번 프로젝트의 스코프(Scope) 외의 사양을 얻을 수 있습니다. 다만, 코드와 달리 작성일이 1년 전인 사양서는 아마 도움이 되지 않을 것입니다. 그 사양서를 인풋(Input)으로 작성된 코드는 이미 다시 작성되었을 가능성이 높고, 또한 사양서 자체도 아마 유지보수(Maintenance)되지 않았을 것입니다. 즉, 거짓 정보가 섞여 있으므로, 나온 테스트 케이스의 전제도 모두 의심하며 접근해야 하기에 인간의 리뷰 공수가 엄청나게 늘어날 것입니다.

[방법 2: 모든 사양서를 쌓아 올리는 방법]
모든 사양서를 쌓아 올리면 그것이 현재의 사양이 될 것이라고 저도 생각해 본 적이 있지만, 저희 회사의 경우 현실적으로 그렇게 되지 않습니다. 사양을 쓰지 않고 코드를 변경하는 일은 일상다반사이기 때문입니다. 또한, 버그와 달리 사양서는 통일된 작성 방식이나 보관 장소가 정해져 있지 않은 경우가 많으므로, 애초에 모든 것을 모으는 것 자체가 어렵기도 합니다.

[방법 3: 코드를 활용하는 방법]
이것 또한 나쁘지 않습니다. 사양서와 달리 역시 코드의 모든 것은 즉시 접근 가능한 장소에 있을 것이고, 무엇보다 코드는 거짓말을 하지 않습니다. 다만, 코드라는 것은 "현 시점에서 어떻게 동작하는가"만을 알려줍니다. 테스트라는 것은 "어떻게 동작하기를 원하는가", 즉 사양이나 요구사항을 바탕으로 만들어야 의미가 있습니다. 요구된 기능이 누락 없이 정확하게 코드에 반영되었는지 확인하기에는 코드만으로는 어떻게 해도 불충분합니다.

이번에 제가 취한 접근 방식은 이것입니다. 사양을 표현한 짧은 문구, 사내에서는 유저 저니(User Journey)라고 부르고 있습니다만, 이것을 많이 수집하여 검색 가능한 형태(Notion DB)로 저장했습니다.

"아까 '사양서는 유지보수되지 않는다'고 하지 않았어?"라는 지적이 나올 법도 하지만, 핵심은 바로 그 지점에 있습니다. 유지보수가 가능한 입도(Granularity)로만 만듭니다. 사양 변경이 있을 때에는 저희 QA 엔지니어가 직접 손으로 변경 사항을 반영합니다.

구체적인 예를 들면 '유료 결제한 사용자는 유료 기사에 댓글을 달 수 있다', '유료 결제를 하지 않은 사용자는 영상을 백그라운드 재생할 수 없다'와 같은 입도입니다. 세세한 화면 사양이나 복잡한 조건의 조합까지는 망라하지 않습니다.

사양 변경이 있으면, 그것을 릴리스 노트(Release Note)의 정기 체크나 의뢰받은 테스트를 수행하는 과정에서 포착하여, '유료 결제를 하지 않은 사용자도 영상을 백그라운드 재생할 수 있다'라는 사양으로 다시 쓰는 식입니다.

그리고 그 사양 DB (Specification DB)를 LLM에 전달하면, 상당히 훌륭한 수준으로 사양서 리뷰를 해주거나 테스트 케이스 (Test Case)를 작성해 주게 되었습니다. 예를 들어 사양서에 적혀 있지 않은 기존 기능에 대한 회귀 (Regression)를 지적하거나, 과거에 발생했던 장애와 관련된 테스트 케이스를 제안하기도 합니다.

처음에는 단순히 유저 저니 (User Journey)를 모아둔 것만으로는 제대로 작동하지 않을 것이라고 생각했습니다. 태그를 달고, 구조화하고, 전제 지식을 별도로 작성하는 등의 작업이 필요하며, 리뷰 등의 정밀도 향상에 효과가 나타나는 것은 그러한 요소들이 모두 갖춰진 후일 것이라고 말이죠.

하지만 서로 파편화된 유저 저니 모음 DB를 MCP (Model Context Protocol)로 연결한 것만으로도 어느 정도 잘 작동해 주었습니다. LLM 스스로 목적에 비추어 사양 DB를 자연어로 검색하고, 검색 결과를 요약하거나 비교하면서 태스크 (Task) 실행에 필요한 지식을 구축합니다. 얼마 전까지만 해도 이것만으로는 잘 되지 않아 저 역시 동일한 DB를 사용하여 RAG (Retrieval-Augmented Generation)를 구성하기도 했지만, 최근에는 이제 DB에 대한 액세스(Access)를 제공하는 것만으로도 알아서 잘 사용해 주는 것 같습니다. AI의 진화는 정말 무섭군요.

덧붙여 기술적인 이야기를 시작하면 길어지므로 여기서는 생략하겠습니다만, Notion MCP로 연결하여 레이트 리밋 (Rate Limit, 속도 제한)을 초과하지 않도록 조절하거나, 가능한 한 한 번의 검색으로 끝낼 수 있도록 하는 등의 고안을 적용하고 있습니다. 가끔 실패할 때도 있지만, 대체로 잘 작동하고 있는 것 같습니다. 다만 동작 속도에 만족하지 못해서 추가적인 고속화를 진행 중입니다 (그 이야기는 나중에 다시 하겠습니다).

NewsPicks에서는 이를 Claude의 Plugin으로 만들어 사내 Marketplace를 통해 배포하고 있습니다. 하지만 배포만 한다고 해서 사람들이 써주는 것은 아니기에, 제가 직접 사내를 돌며 영업을 하여 조금씩 사용자를 늘려가고 있는 중입니다.

이 사양 DB에 대해 '유지보수가 가능한 입도(Granularity)로만 만든다'라고 말씀드렸지만, 이는 어디까지나 AI 도입 전의 세계를 전제로 한 설계입니다. 애초에 이 사양 DB 자체는 AI에게 먹이기 위해 설계·구축한 것이 아니라, 인간이 사용하기 위해 2022년경부터 제가 만들기 시작한 것입니다 (테스트 커버리지 (Test Coverage)는 테스트의 가계부와 같다는 이야기죠). 지금이라면 AI를 잘 활용하여 유지보수를 돌릴 수 있을 것이기에, 최근에는 AI를 이용한 자율적인 사양 DB 유지보수에 힘쓰고 있습니다. 이에 대해서는 조금 더 성과가 나오면 다시 글로 써보도록 하겠습니다.

이상으로 말씀드린 내용은 소위 '컨텍스트 엔지니어링 (Context Engineering)'이라 불리는 내용이 주를 이루고 있다고 생각합니다. 이렇게 쓰면 유행을 따르기만 한 진부한 내용처럼 보일 수 있어, 일부러 본고에서는 바텀업 (Bottom-up) 방식으로 작성했습니다. 참고가 되길 바랍니다.

'테스트 설계나 사양 리뷰는 아직 AI에게 어렵겠지'라고 생각하며 안심하고 있는 QA 엔지니어가 혹시 계신다면, 조금 초조해하는 것이 좋을지도 모릅니다. 어쩌면 우리가 충분한 컨텍스트 (Context)를 설계하지 못하고 있을 뿐, 그것만 제대로 전달해 준다면 우리보다 뛰어난 결과물을 단 몇 달러에 얻을 수 있는 시대가 이미 와 있을지도 모르니까요.