광고 돌리기 전에, AI 에이전트로 29시간 스트레스 테스트 체크

유료 광고 집행을 준비하다가, 그 전에 제 프로덕트에 문제가 없는지부터 확인하고 싶었습니다. 그래서 AI 에이전트에게 29시간 동안 프로덕트 테스트를 시켰습니다.

결과가 예상과 많이 달라서 정리해 보았습니다. AI로 개발하시거나 QA를 자동화해 보려는 분들께 참고가 될 것 같습니다.

Hermes로 복잡한 구성이 없이 Codex에서도 이정도는 할수 있다는 것을 알려 드리고 싶어서 적어봅니다.
(복잡한 설정을 구성하고 Hermes에서 더 정확치 측정할거라 생각합니다. 다만, 대부분은 Hermes도 못 접한 분들이 많다고 생각합니다.)

"QA는 계속 했는데" — 무슨 일이 벌어졌나

먼저 결론부터 말씀드리면, 크리티컬 오류는 나오지 않았습니다. 여기까지는 다행입니다.

문제는 그다음입니다. High 등급 오류가 여러 건 나왔습니다. 만드는 내내 중간중간 QA를 돌렸는데도 그러네요.

숫자로 보면 이렇습니다. 29시간 45분 동안 툴 호출 5,222회, 처리한 이슈 88건, 수정 커밋 111개. 그리고 이 작업이 끝난 뒤에도 제가 눈으로 두 가지를 더 찾아냈습니다.

"AI로 하면 다 되는 거 아니야?" 싶으실 텐데, 그렇지 않았습니다.
(물론 전 개발 직군이다 보니, 아직 AI를 100% 신뢰하면 안된다는 것을 알고 있습니다.)

왜 이런 걸 했을까?

광고를 돌리기 시작하면 깨진 화면 하나가 그대로 비용이 됩니다. 돈을 내고 처음 오신 분을 제 제품에서 가장 문제 있는 부분으로 안내하는 셈이니까요.

여기에 걱정이 하나 더 있었습니다. 제 제품은 여러 언어로 서비스되는데, 제가 그 언어들을 똑같이 잘 다루지는 못합니다. 특정 언어에서만 조용히 뭔가 깨져 있으면 몇 주가 지나도 모를 수 있습니다. 그동안 광고는 아무 문제 없이 잘 돌아가면서, 사람들을 계속 그 화면으로 보내겠죠.

그래서 반나절 정도 직접 클릭해 보고 "괜찮네" 하고 넘어가는 대신, 프로덕트 전체를 Codex(5.6 sol)로 스트레스 테스트 하기로 한겁니다.

그래서 어떻게 시켰을까요?

돌려보고 나서 가장 크게 느낀 건, 프롬프트가 결과의 대부분을 결정한다는 점이었습니다. 지시가 두루뭉술하면 테스트도 딱 그만큼만 두루뭉술해집니다.

실제로 사용한 지시를 정리하면 아래와 같습니다.

목표 곧 유료 광고를 시작한다. 돈을 써서 사람들을 이 제품으로 보내기 전에, 사용자들이 마주치게 될 문제를 찾아야 한다.

기본 규칙

테스트 강도 : 정상 경로만 확인하고 끝내지 말고, 같은 버튼을 반복해서 누르고, 더블 클릭하고, 동시에 요청을 날려보고, 작업 도중에 새로고침하거나 다른 페이지로 이동하거나 로그아웃했다가 돌아와야 한다. 세션 중간에 언어를 바꾸고 상태가 유지되는지 확인하고, 일부러 단계를 실패시키고 복구와 사용량 정산이 맞는지 봐야 한다. 모바일·태블릿·데스크톱, 키보드만으로의 조작, 포커스와 레이블, 명도 대비까지 확인하고, 권한 경계도 체크해야 한다.

이슈마다 남길 것 : 사용자가 겪게 될 현상 → 재현 절차 → 코드상의 원인 → 심각도(Critical / High / Medium / Low) → 수정 내용 → 회귀 테스트 → 배포 후 재검증 결과.

진행 방식 : docs/를 먼저 읽고 시작하고, 작고 추적 가능한 단위로 커밋하면서 고쳐 나가야 한다. main에 배포한 뒤 실제 환경에서 다시 확인하고, 프로덕션에서 확인되기 전까지는 수정이 끝난 게 아니다.

산출물 : 언어별 리포트를 각각 만들고, 마지막에 심각도순 통합 요약을 하나 더 만들어야 한다.

여기서 4번과 5번은 처음부터 있던 규칙이 아닙니다. 이번에 직접 당하고 나서 추가한 항목입니다. 뒤에서 다시 말씀드리겠습니다.

반복시킨 루프는 단순합니다.

관찰 → 재현 → 조사 → 수정 → 테스트 → 검증 → 반복

실제로 차이를 만든 규칙은 "한 번 통과한 걸 믿지 않는다"였습니다. 화면이 한 번 잘 떠서 숨겨진 문제가 있을수 있으니까요.

결과는 이렇습니다

타입 체크, 린트, 빌드, 최종 테스트까지 모두 통과한 뒤에 종료로 판단했습니다. 여기서 "종료"는 마지막 커밋을 찍은 시점이 아닙니다. 배포가 끝나고, 실제 환경에서 다시 확인하고, main에 동기화까지 마친 시점을 말합니다.

이슈 88건에 수정 커밋 111개인 것이 조금 이상해 보이실 수 있는데, 문제 하나를 제대로 해결하려면 보통 여러 군데를 건드려야 합니다. 불일치 하나가 저장된 데이터, 복원되는 UI 상태, 번역 출력, 실패 복구, 테스트 커버리지까지 전부 연결되는 경우가 많았습니다.

8억 7,200만 토큰 사용(캐시 포함)

총 처리 토큰이 8억 7,200만 개로 나왔습니다. 숫자가 크긴 한데, 같이 봐야 할 값이 있습니다.

8억 7,200만 중 97.63%는 캐시된 입력입니다.

장시간 세션은 원래 이렇게 동작합니다. 같은 코드베이스, 같은 리포트, 그동안 쌓인 대화 맥락이 매 턴마다 다시 처리되고, 누적 카운터는 그걸 전부 더합니다. 8억 7,200만 개의 새로운 토큰이 들어갔다는 뜻이 아닙니다.

실제로 새로 투입된 맥락과 생성된 결과물만 보면 약 2,235만 토큰입니다.

두 숫자를 모두 적는 이유는 단순합니다. AI 사용량 수치는 캐시 비율을 같이 봐야 의미가 있기 때문입니다. 비율 없이 총량만 보여드리면 그건 측정이 아니라 홍보에 가깝습니다.

제가 직접 손대야 했던 두 가지

이틀은 그냥 방치하기엔 긴 시간이라, 중간중간 들여다봤습니다. 모든 커밋을 리뷰한 건 아니고, 지나가는 화면을 보면서 "지금 저게 맞는 화면인가"를 확인하는 정도였습니다.

첫째, 특정 언어에서만 내역이 안 나오던 문제입니다.

다른 언어에서는 내역이 전부 정상적으로 출력되는데, 한 언어에서만 하나가 제대로 나오지 않았습니다. 그런데 에이전트는 그 화면을 보고 문제없다고 판단하고 그냥 넘어갔습니다.

제가 직접 지적했고, 짚어주자마자 원인 파악과 수정은 금방 끝났습니다. 고치는 게 어려운 일이 아니었습니다. 알아차리는 쪽이 어려웠던 것입니다.

에이전트의 한계가 정확히 여기 있다고 봅니다. "이게 에러를 던지는가"는 아주 잘 봅니다. 그런데 "이게 방금 열 번쯤 본 다른 화면들에 비해 이상해 보이는가"는 훨씬 약합니다. 앞의 프롬프트 4번은 이 일 때문에 생긴 규칙입니다.

둘째, 결제 완료 이벤트가 제대로 찍히지 않던 문제입니다.

이건 작업이 이미 완료로 정리된 뒤에 발견했습니다. 최종 결과를 다시 검토하다가 PostHog 값 중 하나가 제대로 동작하지 않는 것을 찾았는데, 하필 결제 완료를 체크하는 값이었습니다.

상황을 놓고 보면 좀 아찔합니다. 광고를 준비하려고 이 작업을 한 것인데, 정작 광고 성과를 판단할 때 쓸 숫자가 깨져 있었으니까요.

화면은 멀쩡했습니다. 테스트도 전부 통과했습니다. 에러도 없었습니다. 그냥 조용히 틀린 값이 계속 쌓였을 겁니다. 가장 중요한 지표에서요.

그래서 5번 규칙을 추가했습니다. 화면 너머까지 확인할 것. 이벤트가 작동하지 않는 성공 화면은 오류라고 봐야 합니다.

무엇이 바뀌었을까요?

수정된 내용을 정리하면 대략 이렇게 묶입니다.

• 화면으로 돌아왔을 때 상태 복원이 더 안정적으로 동작
• 반복 요청·동시 요청 처리의 일관성 개선
• 작업이 중간에 실패했을 때의 복구 로직 보완
• 파일·문서 경계 처리 강화
• 언어와 화면 크기에 따른 레이아웃 깨짐 감소
• 의도치 않은 내부 데이터 노출 방어 강화
• 테스트가 없던 경로에 회귀 테스트 추가

바뀐 코드의 양은 중요하지 않다고 생각합니다. 모든 수정이 관찰된 현상 → 재현 케이스 → 검증 단계로 되짚어진다는 점이 중요합니다. 그 연결고리가 없으면 큰 숫자는 그냥 큰 숫자일 뿐입니다.

정말로 새겨야 할 부분

앞에서 말씀드린 것처럼 크리티컬 오류는 없었지만, 하이 등급 오류는 여러 건 있었습니다.

저는 만들면서 중간중간 QA를 계속 해왔습니다. 대충 넘긴 적이 없다고 생각했고요. 그런데도 강도 높은 테스트 한 번에 하이 등급 문제가 여러 개 나왔습니다. 여기에 더해 그 테스트가 끝난 뒤에도 두 가지가 더 나왔습니다.

요즘 "AI로 하면 다 된다"는 이야기를 많이 합니다. 이번 결과는 에이전트가 얼마나 발전했는지 보여주는 근거이기도 하지만, 동시에 그 말이 아직 이르다는 근거이기도 합니다.

개발 중 QA가 놓쳤고, 29시간짜리 스트레스 테스트가 그 대부분을 잡았지만 그것도 두 개를 놓쳤습니다. 정리하면 이런 의미입니다.

아직 내재된 버그가 남아 있을 가능성이 큽니다.

물론 다시 확인할 예정입니다. 현재로서는 High 등급 문제가 남아 있지 않을 거라고 생각합니다. 확신한다가 아니라 생각한다입니다. 이 차이를 알고 계셔야 한다는 게 이 글에서 가장 드리고 싶은 말씀입니다.

같은 걸 해보신다면, 이것만은

① 에이전트를 오래 붙여두세요. 한 번짜리 프롬프트로도 눈에 보이는 버그는 고칩니다. 하지만 제품 옆에 계속 붙어 있는 에이전트만이 재시도, 다국어, 생성 파일, 세 단계 뒤에 돌아온 사용자가 겹쳤을 때 그 버그가 어떻게 변하는지를 발견합니다.

② 브라우저 접근과 코드 접근을 같이 주세요. 브라우저만 있으면 "실패했다"까지만 알 수 있고, 코드만 있으면 "실패할 수도 있다"까지만 알 수 있습니다. 둘이 합쳐져야 증상을 보고, 원인을 추적하고, 고치고, 같은 경로를 다시 걸어서 확인하는 흐름이 완성됩니다.

③ 회귀 테스트를 붙이게 하세요. 화면이 제대로 보이진다고 정상이라는 건 근거가 되지 못합니다. 고친 동작마다 테스트를 붙여두어야 나중 변경이 조용히 되돌려놓는 일을 막을 수 있습니다.

④ "아마 괜찮을 것 같다"를 금지어로 지정하세요. 에이전트가 작은 이상을 넘어가는 이유는 사람이 넘어가는 이유와 같습니다. 당장 터지지 않았으니까요. 그래서 규칙으로 명시해야 합니다. 언어 간 출력 차이는 느낌이 아니라 이슈입니다.

⑤ UI 너머, 특히 애널리틱스를 확인하게 하세요. 이벤트, 메일, 생성 파일, 저장된 상태. 조용한 실패는 대부분 여기에 있습니다. 테스트를 다 통과하고도 살아남는 버그가 정확히 이런 종류입니다.

⑥ 끝까지 직접 보셔야 합니다. 에이전트가 작업 범위를 엄청나게 넓혀준 건 분명합니다. 하지만 책임까지 가져가지는 않습니다. 중요한 게 빠져나간 두 번 모두, 그걸 잡은 건 화면을 보다가 "어, 이거 좀 이상한데" 하고 멈춘 저(사람)였습니다.

마치며

이번에 가장 의미 있었던 건 특정 버그를 고쳤다는 사실이 아니었습니다. 에이전트가 제품 안정화 과정 전체를 붙잡고, 제품을 돌아다니고 근거를 확인하고 코드를 고치고 테스트를 돌리고 배포를 기다렸다가 다시 검증하는 일을 30시간 내내 반복했다는 점이었습니다.

그러니까 우리가 코딩 에이전트에게 던지는 질문이 아직 좀 작았던 것 같습니다. "이 기능 만들어줄 수 있어?"에서 멈출 게 아니라, "이 제품을 계속 테스트하면서 깨지는 부분을 조사하고, 근본 원인을 고치고, 그 수정이 유효한지 증명해 줄 수 있어?"까지 물어볼 수 있습니다.

다만 조건이 하나 붙습니다. 누군가는 계속 지켜보고 있어야 한다는 것입니다.

혹시 비슷한 방식으로 테스트를 돌려보신 분이 계시다면, 어떤 유형의 버그가 나왔는지 궁금합니다. 댓글로 공유해 주시면 저도 많이 배울 것 같습니다.