'멀쩡해 보이는' 버그: AI로 만든 앱의 조용한 실패를 잡아내는 법

AI 앱 빌더가 문의 양식을 만들어 줬습니다. 이름을 입력하고, 제출을 눌렀고, 친절한 성공 메시지를 봤고, 다음 일로 넘어갔습니다. 일주일 뒤 친구에게 그 페이지 이야기를 하니, 누가 작성한 적은 있냐고 묻습니다. 확인하러 갑니다. 제출 세 건이 어떤 대기 상태로 멈춰 있습니다. 그중 어느 것도 받은편지함에 도착한 적이 없습니다.

이것이 AI로 만든 앱에서 가장 흔한 실패 양상이고, 대부분의 사람이 걱정하는 그 버그가 아닙니다. 빨간 오류 메시지를 띄우는 버그는 찾기 쉽습니다 — AI 빌더가 2분 안에 고칩니다. 위험한 버그는 화면은 멀쩡해 보이고, 사용자는 다 됐다고 생각하고, 당신은 한 달 동안 알아채지 못하는 버그입니다.

이 글은 그런 버그를 잡는 체크리스트입니다. “QA 엔지니어처럼 테스트하는 법”이 아니라 — 그저 멀쩡해 보이는 AI 앱에 진짜 사용자가 데이는 다섯 군데입니다.

1. 무언가를 제출하고, 정말 어딘가에 도착했는지 확인하라

AI 빌더가 양식을 만들면, 질문 하나를 던지세요. 데이터는 어디로 가나? 추상적으로 말고 — 말 그대로, 제출한 뒤 그걸 어디 가서 볼 수 있나요?

이런 양식 중 놀랄 만큼 많은 수가, 이메일을 보내지도 데이터베이스에 저장하지도 누구에게 알리지도 않으면서 “감사합니다!”만 돌려주는 핸들러로 데이터를 보냅니다. 양식은 정중한 겉치레일 뿐입니다. 그러니까:

• “ZZZ TEST”처럼 가짜지만 눈에 띄는 이름으로 테스트 항목을 제출하세요.
• 대시보드, 데이터베이스, 받은편지함, 스프레드시트 — 제출이 떨어지기로 되어 있는 곳을 여세요.
• 거기서 올바른 타임스탬프와 함께 “ZZZ TEST” 항목을 찾으세요.

1분 안에 찾지 못한다면, 제출했다고 축하해 줬더라도 당신의 양식은 망가진 겁니다. 유료 랜딩 페이지의 “문의하기” 양식이 3주 동안 리드를 0건 모은 걸 본 적이 있습니다 — 이메일 단계가 끝내 연결되지 않았기 때문이죠. 페이지는 완벽해 보였습니다.

2. 절대 가지 않을 경로를 가 보라

당신은 앱이 만들어지는 걸 지켜봤으니 무엇을 하는지 압니다. 매번 같은 순서로 버튼을 누릅니다. 진짜 사용자는 그러지 않습니다.

가장 이상하게 느껴지는 경로를 고르세요.

• 제출을 빠르게 연달아 두 번 누르세요.
• 무언가를 하던 중간에 페이지를 새로고침하세요.
• 로그인 없이 시크릿 창에서 열어 보세요.
• 아포스트로피가 든 이름을 입력하세요(O’Brien은 고전적인 파괴자입니다).
• 숫자를 요구하는 칸에 숫자를 넣되, 음수나 0으로 해 보세요.

무언가 눈에 보이게 망가지면 그건 진짜 버그지만 — 적어도 시끄러운 버그죠. “멀쩡해 보이는” 버전은 두 번째 클릭이 중복 레코드를 만들었는데 화면에서는 알 길이 없는 경우입니다. 데이터베이스에 가서 타임스탬프가 2초 차이 나는 “ZZZ TEST” 행 두 개를 찾아보세요. 찾았다면, 그 양식에는 중복 방지 장치가 필요합니다.

3. 하루 기다렸다가 다시 와 보라

많은 AI 생성 코드는 앱이 재배포되거나 재부팅되면 초기화되는 임시 메모리를 씁니다. 앱이 당신의 데이터를 개발자가 “인메모리 상태”라고 부르는 곳에 담아 두는 것이죠 — 데모용으로는 괜찮지만, 진짜 무언가에는 끔찍합니다.

테스트는 가혹하고 쉽습니다. 데이터를 좀 입력하고, 탭을 닫고, 24시간 기다린 뒤, 다시 오세요. 데이터가 사라졌거나 엉켜 있다면, 저장이 진짜가 아닌 겁니다. AI 빌더에게 평범한 말로 이렇게 일러 줘야 할 겁니다. “이 데이터는 서버 재시작에도 살아남아야 해.” 대부분의 빌더는 요청하면 데이터베이스로 바꿔 주지만, 일부는 묻지 않으면 그러지 않습니다.

빌더에게 채팅으로 “이 양식의 데이터는 어디에 저장되며, 재배포에도 살아남나요?”라고 물으면 이 테스트의 더 빠른 버전을 돌릴 수 있습니다. 답에 “메모리에”, “세션”, “이번 실행 동안”이 언급되면, 어떤 사용자도 닿기 전에 버그를 찾아낸 겁니다.

4. 당신이 아닌 한 사람에게 보여 줘라

당신은 자기 앱이 무엇을 뜻하는지 압니다. 당신이 설계했으니까요. 버튼 이름도 당신이 붙였습니다. 라벨이 당신에게는 뻔합니다 — 당신이 썼으니까요.

아무 설명 없이 친구에게 보여 주세요. “X를 해 봐”라고만 말하세요. 지켜보세요. 돕지 마세요. 세 가지 일이 벌어집니다.

• 당신이 예상하지 못한 곳을 누를 것이고, 앱은 뜻밖의 동작을 할 겁니다.
• 당신이 쓸 때는 뻔해 보였던 라벨에서 막힐 겁니다.
• 당신이 원하던 일을 하긴 하는데, 당신이 상상한 절반의 단계로 하고, 화면 하나를 통째로 건너뛸 겁니다 — 때로는 앱이 그들에게 채워 주길 기대하던 화면을요.

이 각각이 진짜 버그입니다. 어느 것도 오류를 띄우지 않습니다. 친구는 “오, 귀엽다”라고 말하며 노트북을 돌려줄 겁니다. 그리고 당신은 그 표정에서, 당신이 이음매가 없다고 여겼던 곳에서 그들이 30초 동안 길을 잃었다는 걸 알게 될 겁니다.

5. 앱이 보내는 이메일을, 휴대폰에서 읽어라

앱이 이메일을 보낸다면 — 확인 메일, 비밀번호 재설정, 청구서 — 하나를 휴대폰에서 열고, 하나는 평소 쓰는 것과 다른 이메일 클라이언트에서 열어 보세요. AI로 만든 앱은 데스크톱 Gmail에서는 근사해 보이지만 안드로이드 Outlook에서는 잡음처럼 보이는 이메일을 생성하는 경향이 있습니다.

같은 논리가 PDF 영수증, 내려받을 수 있는 내보내기 파일, “이 링크 공유하기” 버튼에도 적용됩니다. 앱 바깥으로, 진짜 세상으로 나가는 것이야말로 AI 빌드에서 가장 덜 테스트된 부분입니다. 동시에 사용자가 가장 많이 보는 부분이기도 합니다. 제가 아는 한 창업자는 아름다운 결제 흐름을 출시했는데, 그 영수증 PDF가 아이폰에서는 새까만 사각형 하나였습니다. 아무도 항의하지 않았습니다 — 그냥 구매를 멈췄을 뿐이죠.

”작동한다”에 관한 불편한 진실

AI 앱 빌더로 만들 때 “작동한다”는 말은 “내 기계에서, 내 브라우저에서, 내가 정확히 클릭한 대로, 내가 만든 그날에 돌아갔다”는 뜻입니다. 들리는 것보다 훨씬 작은 주장이죠.

진짜 앱은 이럴 때 작동합니다.

• 다른 사람이 쓸 때.
• 데이터가 데모보다 오래 남아 있을 때.
• 앱을 지나는 경로가 당신이 예상하지 못한 것일 때.
• 출력물이 당신이 테스트하지 않은 기기에서 읽힐 때.

좋은 무언가를 출시하려고 소프트웨어 테스터가 될 필요는 없습니다. 그저 이 다섯 가지 점검을, 누군가에게 앱의 존재를 알리기 전날 한 번만 하면 됩니다. 20분쯤 걸립니다. 그러면 유료 사용자에게까지 닿았을 조용한 버그 열에 아홉을 잡아낼 겁니다.

딱 하나만 할 시간이 있다면, 첫 번째를 하세요. 무언가를 제출하세요. 반대편에서 그걸 찾으세요. 대부분의 AI로 만든 앱은 멀쩡해 보입니다. 비결은 그게 정말로 멀쩡한지 확인하는 것입니다.

이 글이 와닿았다면, 다음으로 해 볼 만한 일은 종이 한 장을 앞에 두고 당신의 앱이 절대로 조용히 실패해서는 안 되는 세 가지를 적는 것입니다 — 양식이든, 이메일이든, 결제든, 당신의 경우 무엇이든 — 그리고 위의 점검으로 각각을 짚어 가는 것입니다. 지금의 20분이 나중의 수많은 밤의 숙면을 사 줍니다.