Molayo

© 2026 Molayo

Qiita헤드라인2026. 06. 02. 12:59

코드를 작성할 수 없는 QA 엔지니어가 AI에게 앱의 QA를 시켜본 이야기

요약

코딩 지식이 없는 QA 엔지니어가 Gemini를 활용해 Flutter 앱을 개발하고 출시한 경험담입니다. AI를 활용한 코드 리뷰를 통해 결제 복원 오류와 광고 ID 설정을 발견했으며, QA적 사고방식을 AI 개발 프로세스에 적용하는 방법을 제시합니다.

핵심 포인트

  • AI를 활용한 코드 리뷰로 치명적인 결제 및 광고 버그 발견
  • QA의 '회귀 테스트' 사고방식을 AI 개발에 적용 가능
  • AI에게 정확한 로그와 재현 절차를 전달하는 것이 핵심
  • 구현 완료가 아닌 '기대 동작 확인'의 중요성

QA 엔지니어 8년 차입니다. 코드는 작성할 수 없습니다.

그럼에도 2025년 가을부터 개인 개발을 시작하여, AI를 사용해 JSTQB ALTM 대비 앱을 출시했습니다.

출시 후에 깨달은 점. AI는 코드만 작성하는 것이 아니라, QA (Quality Assurance)도 할 수 있다.

이 기사에서는 AI에게 코드 리뷰 (Code Review)를 의뢰하여 '스스로는 알아채지 못했던 버그'를 발견한 실체험과, QA 엔지니어로서 AI 개발에서 유용했던 관점을 소개합니다.

  • 앱: JSTQB ALTM 대비 앱 (iOS / Flutter 제작)
  • 개발: Gemini를 활용하여 개발 및 출시 완료
  • 상황: 다운로드(DL) 수 66 · 과금률 7.4% · 리뷰 0의 단계

출시 후에도 결함이 신경 쓰였다. 하지만 스스로는 코드를 다 읽을 수 없다. AI에게 리뷰를 부탁해 보았다.

현재 JSTQB 앱의 코드를 당신이 리뷰해 주었으면 하는데, 가능할까요?

그 후 Dart의 모든 소스 코드를 붙여넣었다.

중요도별로 문제를 지적받았다. 특히 충격적이었던 것은 이 두 가지.

🔴 구매 복원 버튼이 실제로는 복원되지 않고 메시지만 출력하는 버그

과금 사용자가 앱을 재설치했을 때, 복원할 수 없는 상태였다. 과금 기능의 버그를 출시 후까지 알아채지 못했다.

🔴 Android의 광고 ID가 테스트용인 상태라 수익이 발생하지 않는 상태

광고를 구현했다고 생각했지만, 테스트 광고 ID인 채로 본 버전에 출시했다. 즉, 광고 수익이 제로(0)가 되어 있었다.

둘 다 "지적받지 않았다면 알아채지 못한 채로 남았을" 버그입니다.

QA 엔지니어로서 8년 동안 버그를 봐왔는데도, 자신의 앱 버그를 놓치고 있었다. AI에게 지적받았습니다.

다운로드 수와 과금 수만 보고 있었다. 그 외에 봐야 할 지표가 있는지 알고 싶었다.

앱에 대해 분석을 하고 싶다.
3/1부터 5/23까지, 다운로드 수 66, 과금한 사용자 5.
이 외에 분석해야 할 항목이 있을까?

App Store Connect의 스크린샷을 공유하자, 구체적인 분석이 돌아왔다.

페이지 조회 → 다운로드 전환율 28%는 우수 (평균은 10~30%) 과금 전환율 7.4%는 교육 앱 평균을 상회 임프레션(Impression) 수가 최대의 병목 구간

즉 "찾아주기만 하면 통하는 앱"이라는 것을 알게 되었다. 과제가 품질이 아니라 인지였다.

이 분석을 바탕으로 Qiita 기사를 작성했더니, 2일 후에 다운로드 수가 역대 최고를 기록했다.

코드를 작성할 수 없는 내가 그럼에도 앱의 품질을 담보할 수 있었던 것은, QA로서의 사고방식이 곳곳에서 빛을 발했기 때문이라고 생각합니다. 구체적으로 3가지를 소개합니다.

  1. '구현 = 완료'가 아니다: AI가 생성한 코드가 통과된 것만으로 만족하지 않고, "기대대로 동작하는가"까지 확인했습니다. 예를 들어 리뷰 의뢰 기능은 시뮬레이터에서는 표시되지 않고 실기기에서만 확인할 수 있는 사양임을 사전에 파악할 수 있었습니다. 이는 "구현 = 완료가 아니다"라는 QA의 기본 자세입니다.

  2. 회귀 테스트 (Regression Test)의 사고: 텍스트 데이터를 업데이트했을 때, 즉시 "음성 데이터나 문제집에도 영향을 주지 않을까?"라고 생각했습니다. 이것은 회귀 테스트의 발상입니다. 결과적으로 용어의 불일치나 데이터의 어긋남을 발견할 수 있었습니다.

  3. 정확한 정보 전달: 빌드 에러(Build Error)나 린트(Lint) 경고는 요약하지 않고 로그를 그대로 붙여넣는 것이 가장 빠르게 해결되었습니다. QA가 결함 보고 시 "재현 절차와 로그를 정확하게 남기는 것"과 같습니다.

AI는 코드만 작성하는 것이 아니다. AI에게 QA를 시킬 수도 있다.

그리고 코드를 작성할 수 없기에 오히려 AI와의 대화에 집중할 수 있었다. "무엇을 확인하고 싶은가"를 언어화하는 능력, 수정의 영향 범위를 읽는 능력 —— QA 엔지니어로서 단련해 온 스킬이 그대로 개인 개발에서 빛을 발했습니다.

이 기사에서 소개한 것은 일부입니다. note에서는,

  • 남은 개발 플로우 (리뷰 기능 구현 · 디버깅 · 출시 절차)
  • QA 관점에서 되돌아보는 품질의 핵심 포인트 5가지
  • 실제로 사용한 모든 프롬프트 (Prompt) 목록

을 모두 공개할 예정입니다. "코드를 작성할 수 없는데 어떻게 품질을 담보했는가"에 관심이 있는 분은 꼭 확인해 주세요.

App Store에서 "JSTQB ALTM"으로 검색해 주세요. ALTM 수험을 생각하고 계신 분은 꼭 확인해 주세요.

X (@QAmah_desu)에서도 개인 개발의 일상을 발신하고 있습니다.

AI 자동 생성 콘텐츠

본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0