화면 자동 점검
손님이 실제로 지나는 길을 진짜 브라우저가 대신 밟아 보는 점검이에요. 주문에서 결제까지 이어지는 핵심 길이 배포마다 살아 있는지 자동으로 확인해요.
쉽게 말하면
마감하고 나서 사장님이 손님인 척 가게를 한 바퀴 돌아본 적 있으실 거예요. 문을 열고 들어와서, 진열대에서 물건을 집고, 계산대에서 카드를 긁고, 영수증이 나오는지까지 직접 해 보는 그 한 바퀴요. 화면 자동 점검은 그 한 바퀴를 적어 두고, 배포할 때마다 기계가 대신 돌게 하는 거예요. 문이 안 열리거나 카드가 안 긁히면 그 자리에서 손을 들어요.
여기서 말하는 길은 화면 한 장이 아니라 손님이 목적을 이루기까지 거치는 순서 전체예요. 상품 목록에서 장바구니를 지나 결제 완료 화면에 닿는 것까지가 길 하나예요.
조각은 다 맞는데 결제 버튼이 화면 밖으로 밀려 있으면 손님은 한 명도 결제를 못 해요. 조각 사이의 이음매는 아무도 안 보고 있어요.
이음매가 끊기면 그 단계에서 멈춰요. 어디까지 갔다가 어디서 막혔는지가 화면 사진과 함께 남아요.
어떤 길을 밟게 하나
고를 기준은 하나예요. 이 길이 막히면 오늘 매출이 0이 되는가. 그 답이 예인 길만 골라요. 화면 수가 아니라 돈과 신뢰가 지나는 길의 개수로 세는 거예요.
| 핵심 길 | 기계가 밟아 보는 순서 | 막혔을 때 생기는 일 |
|---|---|---|
| 사러 와서 결제까지 | 목록 열기, 상품 담기, 주문서 채우기, 결제, 완료 화면 확인 | 매출이 그날 0이 돼요. 손님은 고장이라고 말하지 않고 그냥 나가요 |
| 회원 가입과 로그인 | 가입, 로그아웃, 다시 로그인, 내 정보 화면 확인 | 기존 손님이 못 들어와요. 문의가 가장 많이 몰리는 자리예요. 세션과 쿠키 |
| 예약 잡기 | 날짜 고르기, 시간 고르기, 확정, 확인 메일이나 알림 도착 | 빈 시간에 손님이 못 들어오고, 겹치기 예약이 조용히 쌓여요. 예약 시스템 |
| 문의 남기기 | 문의 폼 채우기, 보내기, 관리자 화면에 그 문의가 뜨는지 확인 | 손님은 보냈다고 생각하고 사장님은 받은 적이 없어요. 최악의 종류의 고장이에요 |
| 관리자가 상품 올리기 | 관리자 로그인, 상품 등록, 손님 화면에 실제로 보이는지 확인 | 물건을 못 올려서 사장님 업무가 멈춰요. 손님 눈에는 안 보이는 사고예요 |
길은 셋에서 다섯이면 충분해요
화면 자동 점검은 만드는 값도 유지하는 값도 점검 중에 가장 비싸요. 그래서 많이 만드는 게 아니라 끊기면 안 되는 길만 골라요. 문구가 바뀌고 색이 바뀌어도 살아 있어야 하는 길, 그 몇 개가 목록의 전부예요.
부품 점검과 무엇이 다른가
두 점검은 이름이 비슷해서 견적서에서 자주 뒤섞여요. 무엇을 켜 놓고 보는지로 가르면 헷갈리지 않아요. 부품 점검은 계산기만 켜고 보고, 화면 자동 점검은 진짜 브라우저를 켜고 봐요.
| 갈리는 지점 | 부품 자동 점검 | 화면 자동 점검 |
|---|---|---|
| 무엇을 보나 | 계산 한 조각의 답이 맞는지. 부품 자동 점검 | 손님이 지나는 길이 끝까지 이어지는지 |
| 무엇을 켜나 | 계산기 하나만. 화면도 서버도 안 켜요 | 진짜 브라우저와 서버와 데이터베이스를 다 켜요 |
| 한 번 도는 데 걸리는 시간 | 수십 개를 돌려도 몇 초 안에 끝나요 | 길 하나에 수십 초씩 걸려요. 그래서 개수를 늘리기 어려워요 |
| 깨졌을 때 알려 주는 것 | 어느 규칙이 틀렸는지 이름으로 콕 집어 줘요 | 어느 단계에서 멈췄는지 알려 줘요. 원인은 따로 찾아야 해요 |
| 언제 도나 | 코드를 고칠 때마다 | 올리기 직전에 한 번. 매 수정마다 돌리기엔 너무 느려요. 자동 배포 흐름 |
| 잘 나는 문제 | 규칙이 바뀌었는데 점검을 안 고쳐서 빨간불 | 아무 문제 없는데 가끔 빨간불이 떠요. 뒤에서 따로 다뤄요 |
둘은 서로를 대신하지 못해요. 부품 점검이 백 개 초록불이어도 로그인 버튼이 안 눌리면 손님은 아무것도 못 하고, 화면 점검이 초록불이어도 할인 계산이 100원씩 틀릴 수 있어요.
순서는 부품 점검이 먼저예요
화면 자동 점검부터 만들면 느리고 잘 깜빡이는 점검을 잔뜩 안고 시작하게 돼요. 값이 잘 나오는 순서는 돈 계산에 부품 점검 몇 개 → 핵심 길 하나에 화면 점검 → 길을 서너 개로 늘리기예요.
점검 한 바퀴가 만들어지는 순서
- 1밟을 길을 손님 말로 한 줄씩 적어요. "목록을 연다, 상품을 담는다, 주문서를 채운다, 결제한다, 완료 화면에서 주문번호를 본다."
- 2각 단계에서 무엇을 누르는지를 정해요. 여기서 버튼을 위치나 색으로 찾으면 안 돼요. 디자인만 바꿔도 점검이 길을 잃어요.
- 3각 단계에서 무엇이 보여야 성공인지를 정해요. "결제 완료" 글자가 뜨는 것, 주문번호가 화면에 있는 것처럼 눈으로 확인 가능한 것이어야 해요.
- 4손님이 안 보는 연습용 주소에 붙여요. 결제는 결제사가 주는 시험용 열쇠로 해요. 실서비스에서 돌리면 진짜 주문과 진짜 청구가 쌓여요.
- 5일부러 한 단계를 망가뜨려 점검이 그 자리에서 멈추는지 확인해요. 안 멈추면 그 점검은 길을 밟는 척만 하고 있는 거예요.
- 6배포 흐름에 걸어요. 빨간불이면 올리기가 멈추게 할지, 경고만 띄울지를 여기서 정해요.
2번이 이 순서의 심장이에요. 버튼을 화면에서 세 번째 파란 버튼 같은 식으로 찾게 해 두면, 디자인을 손볼 때마다 점검이 통째로 무너져요. 개발자들은 이걸 막으려고 버튼마다 눈에 안 보이는 이름표를 붙여 둬요.
쌓이는 자료를 치울 계획까지가 한 세트예요
화면 자동 점검은 진짜로 주문을 만들고 진짜로 회원을 가입시켜요. 배포마다 돌면 가짜 주문이 매일 쌓여요. 점검용 자료에 표시를 남겨 두고 끝나면 지우는 절차까지 만들어야, 나중에 매출 집계에 섞이지 않아요.
가끔 빨간불이 뜨는 문제
이 점검의 가장 큰 골칫거리는 고장이 아니에요. 아무것도 안 고쳤는데 어떤 날은 빨간불, 다시 돌리면 초록불이 되는 거예요. 개발자들은 이런 점검을 깜빡인다고 말해요.
- 1기다리지 않고 눌러서. 화면이 다 그려지기 전에 기계가 버튼을 눌러요. 사람 눈에는 0.3초라 안 보여요. 시간을 정해 기다리게 하지 말고 그 버튼이 나타날 때까지 기다리게 고쳐요.
- 2바깥 서비스를 같이 밟아서. 결제사나 문자 발송처럼 남의 서버가 느린 날 점검이 같이 실패해요. 내 잘못이 아닌 실패예요. 시험용 열쇠와 시험용 응답으로 갈라 둬요.
- 3앞선 점검이 남긴 자료 때문에. 같은 이메일로 매번 가입하면 두 번째부터 중복으로 막혀요. 돌 때마다 다른 값을 쓰게 만들어요.
- 4여러 점검이 같은 자료를 동시에 만져서. 하나가 지운 상품을 다른 하나가 담으려다 실패해요. 길마다 자기 자료만 쓰게 갈라요.
장면 1 · 외주 개발자가 말했다
“그 테스트는 원래 가끔 실패해요. 다시 돌리면 통과하니까 신경 안 쓰셔도 됩니다.”
반은 사실이지만 그대로 두면 안 되는 말이에요. 깜빡이는 점검이 하나 생기면 사람은 빨간불을 일단 다시 돌려 보는 것으로 처리하기 시작해요. 그러다 진짜 고장이 났을 때도 똑같이 다시 돌리고 넘어가요. 되물을 말은 하나예요. "왜 깜빡이는지 원인을 찾을 수 있나요, 아니면 이 길은 점검에서 빼는 게 나을까요?" 고칠 수 없으면 빼는 편이 나아요.
견적서와 배포 설정에서 보는 말
| 문서에 적힌 문장 | 실제로 하는 말 | 이렇게 되물으세요 |
|---|---|---|
| E2E 테스트 시나리오 5건 구축 | 손님이 지나는 길 다섯 개를 기계가 밟게 만들었다는 뜻이에요 | 그 다섯 개가 각각 무슨 길인지 손님 말로 한 줄씩 적어 주세요 |
| Playwright 기반 자동화 | 브라우저를 대신 조종하는 도구 이름이에요. 도구 이름 자체는 값을 정하지 않아요 | 이 도구를 쓰면 제가 결과를 어디서 볼 수 있나요? |
| 헤드리스 브라우저로 실행 | 화면을 안 띄우고 브라우저를 돌린다는 뜻이에요. 사람 눈에는 아무것도 안 보이고 결과만 남아요 | 실패했을 때 그 순간 화면 사진이나 녹화가 남나요? |
| 배포 파이프라인에 통합 | 올릴 때마다 자동으로 돈다는 뜻이에요 | 빨간불이면 배포가 실제로 막히나요, 경고만 뜨고 그냥 올라가나요? |
| 결제 연동 구간은 목(mock) 처리 | 결제사를 실제로 부르지 않고 가짜 응답으로 대신했다는 뜻이에요 | 그러면 진짜 결제가 되는지는 무엇으로 확인하나요? 연습용 주소에서 시험 결제는 하나요? |
| 플래키 테스트는 스킵 처리 | 깜빡이던 점검을 꺼 뒀다는 뜻이에요. 그 길은 지금 아무도 안 보고 있어요 | 무슨 길을 왜 껐고, 다시 켜는 조건은 무엇인가요? |
장면 2 · 코드를 넘겨받은 업체가 말했다
“화면 테스트가 서른 개인데 절반이 깨진 채로 방치돼 있습니다. 이건 있으나 마나입니다.”
개수가 값이 아니라는 증거예요. 깨진 채 방치된 점검은 매번 빨간불을 띄우고, 사람은 그 빨간불을 보지 않는 법을 배워요. 확인하는 방법이 있어요. 마지막으로 전부 초록불이었던 날을 물어보세요. 대답이 안 나오면 그 점검들은 이미 꺼진 것과 같아요. 개발자에게 넘기기 때 먼저 볼 항목이에요.
AI에게 그대로 말할 문장
도구 이름을 외워서 말할 필요가 없어요. 손님이 밟는 순서를 그대로 적어 주는 것이 가장 잘 통해요. 오른쪽 칸은 복사해 붙여도 되는 말이에요.
| 내가 겪는 상황 | 그대로 말할 문장 |
|---|---|
| 결제가 끊긴 걸 손님 전화로 알았어요 | 목록에서 상품을 담고 주문서를 채우고 결제까지 가는 길을, 브라우저가 대신 눌러 보는 자동 점검으로 만들어 주세요. 결제는 시험용 설정으로 해 주세요 |
| 무슨 길이 점검되고 있는지 모르겠어요 | 지금 있는 화면 자동 점검이 각각 어떤 순서를 밟는지, 손님 입장의 문장으로 한 줄씩 설명해 주세요 |
| 점검이 어떤 날은 실패하고 어떤 날은 통과해요 | 이 점검이 왜 가끔 실패하는지 원인을 찾아 주세요. 정해진 시간을 기다리는 방식이 있으면, 요소가 나타날 때까지 기다리는 방식으로 바꿔 주세요 |
| 디자인만 바꿨는데 점검이 다 깨졌어요 | 버튼을 위치나 문구로 찾고 있으면, 바뀌지 않는 이름표로 찾도록 고쳐 주세요. 이름표는 화면에 안 보이게 해 주세요 |
| 점검 때문에 가짜 주문이 쌓여요 | 자동 점검이 만든 자료에 표시를 남기고, 점검이 끝나면 그 자료만 지우도록 만들어 주세요. 매출 집계에서도 빠지게 해 주세요 |
| 어디까지 갔다 막혔는지 모르겠어요 | 점검이 실패하면 그 순간의 화면 사진과 어느 단계에서 멈췄는지를 남겨 주세요 |
직접 해보기
내 서비스의 핵심 길을 먼저 세어 보세요
스튜디오 대화창에 이렇게 그대로 붙여 넣어 보세요. "이 서비스에서 손님이 목적을 이루기까지 거치는 길을 전부 목록으로 뽑고, 각각 막히면 무슨 일이 생기는지 한국어로 적어 주세요." 점검을 만들지 말지는 그다음 판단이에요. 먼저 끊기면 안 되는 길이 몇 개인지 보는 것이 시작이에요.
스튜디오 열기점검이 빨간불이면 배포를 멈출지 먼저 정해요
빨간불에 배포가 안 멈추면 점검은 그냥 지나가는 경고가 돼요. 반대로 깜빡이는 점검 하나가 배포를 매번 막으면 사람은 점검을 끄게 돼요. 그래서 믿을 수 있는 길만 배포를 막게 걸고, 나머지는 경고로 두는 식으로 갈라요.
자주 묻는 것
- Q. 손으로 확인하는 목록은 이제 없어도 되나요?
- 필요해요. 기계는 길이 이어지는지는 봐도 보기 좋은지는 못 봐요. 글자가 겹치거나 색이 안 어울리는 건 사람 눈이 봐야 해요. 손으로 확인할 목록은 그대로 두고, 매번 똑같이 반복되는 한 바퀴만 기계에 넘기는 거예요.
- Q. 실서비스에서 돌리면 안 되나요?
- 권하지 않아요. 진짜 주문과 진짜 회원이 쌓이고, 결제까지 밟으면 실제 청구가 일어나요. 손님이 안 보는 연습용 주소에서 돌리는 게 기본이에요. 다만 배포 직후에 결제 없이 열리는지만 한 바퀴 확인하는 짧은 점검은 실서비스에서 돌리기도 해요.
- Q. 점검이 느려서 배포가 오래 걸려요.
- 길 개수를 줄이는 게 첫 번째 답이에요. 그다음은 여러 길을 동시에 돌리는 것이고요. 그래도 오래 걸리면 핵심 길만 배포 때 돌리고 나머지는 밤에 한 번 도는 식으로 갈라요.
- Q. 저는 코드를 못 읽는데 이걸 알아야 하나요?
- 코드를 읽을 필요는 없어요. 사장님이 하실 일은 끊기면 안 되는 길을 손님 말로 적어 주는 것이에요. "목록에서 담고 결제까지" 한 줄이 점검 하나가 돼요. 나머지는 만드는 사람의 일이에요.
- Q. 점검은 초록불인데 손님이 결제가 안 된다고 해요.
- 점검은 자기가 밟는 길만 봐요. 손님이 쓰는 카드 종류나 폰 기종이 다르면 다른 길이에요. 그럴 때는 그 상황을 먼저 재현하고(재현 절차 쓰기), 그 길을 점검에 한 줄 더해요. 사고 하나가 점검 한 줄로 남는 게 가장 좋은 결말이에요.
- Q. 고쳤더니 딴 게 깨지는 문제도 이걸로 잡히나요?
- 핵심 길 위에서 일어난 일이면 잡혀요. 결제 화면을 손봤는데 로그인이 깨졌다면 로그인 길이 빨간불로 알려 줘요. 다만 점검이 안 밟는 길에서 깨진 건 못 잡아요. 고쳤더니 딴 게 깨짐에서 왜 점검 목록을 사고마다 늘려 가는지 다뤄요.
확인해 보세요
받은 보고서에 "플래키 테스트는 스킵 처리"라고 적혀 있어요. 무슨 뜻일까요?
하나 더
오픈 두 달째예요. 결제가 두 번 끊겼는데 둘 다 손님 전화로 알았어요. 지금 무엇부터 할까요?
더 깊이 (안 읽어도 괜찮아요)
비유가 어디까지 맞고 어디부터 다른가 · 손님인 척 한 바퀴 도는 비유는 "순서대로 밟아 보고 막히면 안다"까지 정확해요. 다른 점은 기계가 눈치가 없다는 거예요. 사람은 버튼이 조금 옮겨져 있어도 알아서 찾아 누르지만, 기계는 정해 준 이름표가 사라지면 그 자리에서 멈춰요. 그래서 디자인을 자주 바꾸는 화면일수록 점검이 자주 무너져요. 자주 바뀌는 곳에 이 점검을 달지 않는 이유이기도 해요.
왜 개수를 늘리면 오히려 나빠지나 · 점검이 서른 개면 한 바퀴에 십수 분이 걸리고, 그중 하나만 깜빡여도 전체가 빨간불이에요. 빨간불이 자주 뜨는 화면은 사람이 안 봐요. 점검의 값어치는 개수가 아니라 빨간불이 떴을 때 사람이 즉시 멈춰 서는지로 정해져요. 다섯 개가 늘 초록불인 편이 서른 개가 늘 빨간불인 것보다 훨씬 강해요.
실패했을 때 남는 것이 값을 결정해요 · 이 점검은 브라우저를 화면 없이 돌려요. 그래서 실패해도 사람이 그 순간을 못 봐요. 실패한 순간의 화면 사진, 그때까지의 녹화, 브라우저가 뱉은 오류 기록을 남기게 해 두면 원인 찾기가 몇 시간에서 몇 분으로 줄어요. 점검을 붙일 때 이 셋을 남기는지부터 확인하세요. 에러 읽는 법이 여기서 그대로 쓰여요.
일부에게만 먼저 여는 방식과 짝이에요 · 점검이 밟지 않은 길은 결국 손님이 처음 밟아요. 그래서 큰 변경은 점검을 통과했더라도 전체에 한 번에 열지 않아요. 일부 손님에게 먼저 열어 보고 문제가 없으면 넓히는 방식이 짝이 돼요. 일부에게 먼저 열기와 기능 스위치가 그 장치예요.
이것만 기억하세요
- ·화면 자동 점검은 손님이 지나는 길을 진짜 브라우저가 대신 밟아 보는 점검이에요
- ·고를 기준은 하나예요. 막히면 오늘 매출이 0이 되는 길만 골라요. 셋에서 다섯이면 충분해요
- ·부품 점검은 계산을 보고 이 점검은 이음매를 봐요. 서로를 대신하지 못해요
- ·버튼을 위치나 문구로 찾게 하면 디자인만 바꿔도 무너져요. 안 바뀌는 이름표로 찾게 해요
- ·가끔 뜨는 빨간불을 방치하면 사람이 빨간불을 안 보게 돼요. 고치거나 빼거나 둘 중 하나예요