10년 전 자격증 교재가 AI 테스트를 살렸다

‘Why’는 어디서 오는가

이전 글 ‘AI와 200만 줄의 코드를 작성하며 깨달은 것들’에서 저는 AI에 ‘Why’를 줘야 한다고 했습니다. 그런데 정작 그 Why를 어떻게 줘야 하는지는 쉽지 않습니다. Why를 그렇게 잘 줄 수 있다면, AI가 왜 필요한가 하는 생각도 듭니다. AI가 다 알아서 해줘야 하는 것 아닌가? 싶기도 하고요. 하지만 Why는 결국 ‘내가 원하는 것’입니다. 우리는 AI를 통해 무언가를 얻으려 하고, 그 원하는 것을 얻기 위해 Why를 주는 겁니다.

한 가지 덧붙이면, Why는 곧 우리의 생각이고, 이 생각은 AI를 통해 얼마든지 확장할 수 있습니다. 이를 확장된 사고(Extended Thinking)라고 부르기도 합니다. 우리가 원하는 것을 얻기 위해 자신의 생각을 최대한 넓혀 가는 것이죠.

내가 잘 아는 영역이라면 얼마든지 좋은 Why를 줄 수 있습니다. 문제는 내가 잘 모르는 영역입니다. 잘 모르는 영역에서 답을 구할 때는 환각 증상이 더 많이 나타날 수 있습니다. AI가 준 그 답을 내가 검증할 수 없기 때문입니다.

그래서 잘 모르는 영역에서 답을 구할 때는, AI와 브레인스토밍을 하며(저는 이 방법을 자주 씁니다) 원하는 답을 향해 차근차근 나아가는 방법도 있습니다. 이때는 AI가 길을 잘 찾아가도록, AI 내부가 아니라 밖에서 힌트를 구해 던져 주면 됩니다. 그러면 AI는 그 힌트를 붙잡고 길을 제법 잘 찾아갑니다.

오늘은 AI가 헤매지 않고 내가 원하는 목적지로 길을 잘 찾아가게 만드는 일에 대한 경험을 이야기해 보려 합니다.

미리 요점만 콕 집어보면?

• 1인 개발이라 테스트를 AI에 맡겼더니, 테스트는 늘 ‘통과’인데 정작 버그는 그대로였습니다. 기준을 주지 않았기 때문입니다.
• 그 기준은 새로 만드는 게 아니라, 10여 년 전 자격증 공부하며 읽었던 이미 쌓여 있는 문서 안에 있었습니다.
• AI가 강력해질수록 낡은 문서의 값은 오히려 오릅니다. 다만 그것을 판단에 쓰고 책임지는 일까지 AI에 넘겨선 안 됩니다.

AI가 늑대 소년이 되다

저는 1인 개발자라 모든 게 부족합니다. 무엇보다 기획과 테스트를 맡아 줄 사람이 없습니다. 그래서 AI로 QA 담당 에이전트를 만들었습니다. AI가 직접 브라우저로 화면을 열어 로그인하고, 값을 입력하며 자동으로 테스트하도록 만든 것이죠. 나온 버그는 슬랙으로 리포트를 받고, 제가 확인해 코드를 고치고 다시 돌렸습니다.

그리고 테스트는 늘 통과했습니다. 저는 아무 생각 없이 결과 리포트만 보고 ‘아, 잘됐구나’ 했습니다. 통과, 또 통과. 테스트 보고서에는 언제나 ‘모두 패스’라고 적혀 있었습니다. 그 깔끔한 성공 리포트 자체가 이상 신호였는데, 당시엔 오히려 안심하고 있었습니다.

서비스 오픈이 얼마 남지 않았을 무렵, 혹시나 하는 마음에 회사 내부 직원에게 같은 화면을 테스트해 보라고 했습니다. 오류가 쏟아졌습니다. 또 AI에 당한 겁니다. 저는 테스트가 정말 잘되고 있는 줄 착각하고 있었습니다. 실제로는 화면에 보이는 표면만 확인됐을 뿐, 정작 중요한 비즈니스 로직은 건너뛰거나 대충 넘어가고 있었습니다.

AI는 그저 테스트를 ‘통과하도록’ 만들어져 있었던 것이죠. 최종 결과를 사람이 확인하지 않고 “네가 확인해라” 하고 맡겼더니, AI는 테스트 항목 몇 개를 만들어 놓고 그냥 통과라고 말해 버린 것이었습니다.

기준을 감으로 만들 수는 없었다

처음 테스트 에이전트를 만들 때, 시간이 없다는 이유로 대충 만들었더니 이런 일이 벌어졌습니다.

왜 이 테스트를 해야 하는지, 무엇을 확인해야 하는지를 명확하게 주지 않아서 발생한 일이었습니다. 테스트 기준이 너무 헐거웠고, 검증 또한 너무 대충이었습니다. 방대한 코드베이스 전체의 테스트를 손수 작성하기에는 시간이 턱없이 부족했습니다.

이걸 어떻게 제대로 만들 수 있을까 고민하다가, 오래전에 따 두었던 테스터 자격증이 문득 떠올랐습니다. ‘아, AI에게 기준을 줘야겠구나.’ 물론 어떤 기준을 왜 줘야 하는지는 당연히 우리의 결정이고, 우리의 일입니다.

그런데, 이미 누군가 다 적어 놓았더군요

10여 년 전에 따 놓은 테스팅 자격증(ISTQB). 이력서 한 줄 외에는 거의 쓸 일이 없던 자격증이었습니다.

테스트는 AI의 환각을 막아 주는 최후의 보루라고 생각했기에, 저에게는 아주 중요한 업무였습니다. 환각을 완전히 제거하는 건 불가능하니, 발생할 환각을 ‘이건 환각이다’ 하고 발견해 막아 주는 게 최선이라 여겼습니다. 그래서 테스팅 전략과 시나리오를 처음부터 다시 정리하기로 했습니다.

그 자격증 사이트에 들어가 테스팅 교육 문서들을 다운로드하고, 제가 가지고 있던 몇몇 문서까지 함께 AI에 던져 정리 작업을 시켰습니다. 그런 다음 테스트 에이전트를 다시 작성했습니다. 그러자 AI는 이전에 만들어 둔 테스팅 전략을 수정하고 다시 세우기 시작했습니다. 이제 기준점이 생겼기 때문입니다. 이 기준을 바탕으로 테스팅 전략이 다시 만들어졌고, 전체 시나리오도 새로 작성됐습니다.

사실 저는 개발하면서 기존에 잘 정리된 문서들을 이미 많이 활용해 왔습니다. API 명세서, 국제 표준 스펙 문서 같은 것들이죠. 모두 오랜 시간에 걸쳐 잘 정리된 문서였기에, AI에 아주 좋은 품질의 데이터가 되어 주었습니다.

애자일과 테스팅의 선구자인 켄트 벡(Kent Beck)은 저서 『테스트 주도 개발(Test-Driven Development: By Example)』에서, 테스트를 작성하는 일이 프로그램을 작성하는 것과는 다른 종류의 사고를 요구한다고 봤습니다. 프로그램이 ‘어떻게 작동하게 만들 것인가’를 고민한다면, 테스트는 ‘이것이 어떻게 망가질 수 있는가’를 고민한다는 것이죠.

이 한 문장에 모든 게 담겨 있습니다. 테스트는 성공을 위한 것이 아니라, 실패를 위한 것입니다. 그리고 AI는 실패를 만들어 내는 데 서툽니다. 그래서 우리가 실패하도록 유도하고, 검증해야 합니다.

저는 늘 ‘AI가 모든 걸 자동으로, 그럴듯하게 해주니 편하구나, AI 정말 좋네’ 하며 그냥 넘어가고 있었습니다. 제 일을 AI에 통째로 일임했던 것이고, AI는 결국 이런 결과로 답한 것입니다. 그 뒤로 저는 AI와 협업할 때 항상 확인하고, 질문하고, 검증하는 버릇이 생겼습니다. 맞아 보여도 한 번 더 묻습니다. “너의 결과가 나의 의도(context)와 맞는지 확인하고, 어긋나면 나에게 피드백을 달라”고 말이죠.

문서에서 설계를, 설계에서 자동화를

테스팅 작업을 예로 들었지만, 제가 정작 강조하고 싶은 건 ‘문서’입니다. AI가 환각을 줄이고 더 나은 판단을 하도록 만드는 방법은 멀리 있지 않습니다. 우리가 그동안 한 땀 한 땀 적어 놓은 수많은 기록들이 있습니다. 오타도 있고 잘못 적힌 내용도 있지만, 우리가 일했던 그 흔적들이 AI에는 훌륭한 참고서가 됩니다.

결국 AI 시대에도 중요한 건 데이터였습니다. AI로 개발을 시작한 뒤로는, AI가 문서를 워낙 잘 만들어 주다 보니 제가 예전에 만든 문서들은 촌스럽고 낡은 것이 되어 어딘가에 백업본으로만 남아 있었습니다. 그 파일들 안에는 문서를 쓰며 고민했던 흔적과 시행착오 같은 경험이 고스란히 녹아 있었는데, AI의 멋진 출력물에 취해 저는 그걸 다 잊고 있었습니다.

그 문서를 다시 꺼내게 된 계기가 바로 이번 테스트 오류였습니다. AI에도 데이터를 주고, 가르치고, 쓰게 해야 한다는 당연한 사실을, 저는 AI의 근사함에 가려 잊고 있었던 겁니다.

그래서 PC 어느 구석에 숨어 있던 그 문서들을 AI에 정리시키고, 다시 참고서로 던져 주었습니다. 그러자 AI는 Why와 What, 그리고 Goal을 훨씬 잘 이해한 결과물을 내놓기 시작했습니다.

AI가 스스로 좋은 결과물을 내놓게 하려면, AI가 작업하는 환경 자체가 매우 중요하다는 걸 느꼈습니다. 문서를 주고, 의도를 주고, 형태를 주더라도 결국 모든 것은 저의 의사결정에 따라 움직여야 한다는 사실을 알게 됐습니다.

한 가지 팁을 덧붙이면, 참고 문서가 너무 많으면 프롬프트가 길어져 오히려 답변 품질이 떨어질 수 있습니다. 이럴 때는 AI에 먼저 문서 구조화 작업을 시켜 두면, 훨씬 효율적으로 활용할 수 있습니다.

마치며: 낡은 문서의 값이 오르는 시대

AI에 일을 맡기려는 순간, 우리는 그동안 굳이 명시적으로 답할 필요가 없던 질문들과 마주하게 됩니다. 무엇이 통과이고, 무엇이 실패인가. 확신이 서지 않을 때는 어떻게 할 것인가. 사람에게 맡길 때는 이런 것을 하나하나 정의하지 않습니다. 상대가 알아서 판단해 주니까요.

그리고 그 판단의 기준은 대개 이미 어딘가에 존재합니다. 제 경우엔 이력서 한 줄로만 남아 있던 자격증 교재였고, 다른 분야라면 회계 기준이나 임상 가이드라인, 하다못해 선배가 남긴 낡은 운영 매뉴얼일 수도 있겠죠. 우리는 그런 문서들을 낡았다고 여겨 왔습니다. 이론일 뿐이라고, 현장에선 안 쓴다고, 자격증 딸 때나 보는 거라고요.

하지만 AI 시대에 그 문서들의 값은 오히려 올라갑니다. AI는 그 문서를 읽고 실행할 수는 있어도, 만들어 낼 수는 없기 때문입니다.

AI는 최종 판단을 하지 않습니다. 언제나 그랬듯, 우리의 삶과 마찬가지로 중요한 결정은 결국 자기 자신이 내려야 합니다.

다만 한 가지 경계할 것이 있습니다. AI를 오래 쓰다 보면 ‘생각의 외주화’라는 함정에 빠지기 쉽습니다. AI의 출력이 그럴듯하니 점점 거기에 기대게 되고, 그러는 사이 사고력을 잃어 가는 것이죠. AI에 많이 의존할수록, 우리는 정작 Why를 던지는 일조차 서툴러집니다. 그래서 저는 늘 ‘기준은 내가 결정하고, 내가 책임진다’는 말을 되뇌며 작업합니다.

AI는 그 결과를 책임져 주지 않습니다. AI가 어떤 내용을 주든, 어떤 판단을 내리든, 최종 책임은 그것을 받아들인 우리 몫입니다. 늘 결과를 확인하고 검증해 최적의 답을 얻는 것, 그리고 결정하는 것. 그건 언제나 우리의 일입니다.

<참고>

1.   ISTQB® Certified Tester Foundation Level 실라버스 (공식)

2.   Kent Beck, 『Test-Driven Development: By Example』, Addison-Wesley, 2002.

ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.