AI로 수정했더니 다른 기능에서 오류 — 회귀 테스트로 막는 법

AI 수정 후 다른 기능에서 오류가 난 적 있으십니까. 그건 잘못 시켜서가 아닙니다. 수정한 자리는 정상인데 관련 없어 보이던 화면이 작동하지 않는 일은 흔합니다. 문제는 고치는 능력이 아니라, 한 번 확인한 것이 다음 배포에서 다시 확인되지 않는다는 데 있습니다. 이렇게 이전에 되던 기능이 여전히 되는지 다시 확인하는 일을 회귀 테스트라고 부릅니다. 이 글은 왜 그런지, 그리고 그 회귀 테스트를 한 번만 적어 두고 배포마다 자동으로 돌리는 방법을 이야기합니다.

수정한 곳은 정상인데 다른 화면이 멈춘다

이런 경험이 있으실 겁니다.

"결제 화면 버튼이 안 눌려요."

AI에게 수정을 맡기면 금방 처리해 줍니다. 확인해 보니 결제도 정상입니다. 배포합니다.

며칠 뒤 다른 연락이 옵니다 — "회원가입이 안 돼요." 결제를 수정했는데 회원가입이 작동하지 않게 된 것입니다.

드문 일이 아닙니다. 화면 하나를 수정하면 그 화면만 바뀌는 것이 아니라, 같은 코드를 함께 쓰던 다른 화면도 함께 영향을 받습니다. 수정한 사람은 수정한 자리를 확인합니다. 문제가 생긴 곳은 확인하지 않은 자리입니다.

이렇게 정상이던 기능이 나중에 작동하지 않게 되는 일은 워낙 흔해서 따로 이름이 붙어 있고, 큰 회사들은 이것만 따로 확인하는 절차를 둡니다. 이름은 몰라도 됩니다. 중요한 것은 왜 매번 놓치는가입니다.

앞 글에서 다룬 것이 '누가 테스트하나'였다면, 이 글은 '언제 다시 확인하나'입니다. 바이브 코딩으로 만든 앱, 진짜 되는지 어떻게 확인하나요? 를 아직 안 보셨다면 그쪽을 먼저 보셔도 좋습니다.

이어서 읽기AI에게 테스트를 맡겼는데, 왜 오류가 났을까요?AI 테스트노코드 테스트6분

AI 수정 후 다른 기능 오류, 왜 반복될까요

앱이 커질수록 확인할 곳은 늘어납니다. 화면이 열 개면 열 곳, 서른 개면 서른 곳입니다. 그런데 배포는 오히려 더 잦아집니다. AI로 만들면 수정 속도가 빨라지기 때문입니다.

여기서 계산이 어긋납니다. 확인할 곳 × 배포 횟수만큼 눌러봐야 하는데, 그걸 할 시간은 늘어나지 않습니다.

배포가 문제로 이어지는 일은 드물지 않습니다. 구글의 DORA 연구 는 '배포가 장애·롤백·핫픽스를 유발한 비율'을 아예 핵심 지표로 두고 측정합니다. 배포할 때마다 무언가 잘못될 수 있다는 것을 전제로 삼은 셈입니다.

그래서 실제로 벌어지는 일은 이렇습니다.

• 처음에는 전부 눌러봅니다
• 다음에는 수정한 곳과 그 주변만 확인합니다
• 나중에는 수정한 곳만 확인합니다
• 결국 확인하지 않은 채 배포합니다

바꾼 게 많을수록 오히려 확인을 덜 하게 됩니다. 게으름이 아니라 시간 계산의 결과입니다.

수정한 자리는 하나인데 영향은 여러 화면으로 퍼진다

회귀 테스트를 배포마다 자동으로 돌리려면

문제를 뒤집어 보면 답이 보입니다. 매번 사람이 기억해서 확인하는 구조가 문제라면, 확인 항목을 사람 밖에 적어 두면 됩니다.

한 번 적어 두면 이런 것이 달라집니다.

첫째, 기억할 필요가 없습니다. "지난번에 뭘 확인했더라"를 떠올리지 않아도 됩니다. 적어 둔 것이 그대로 남아 있습니다.

둘째, 배포할 때마다 같은 항목을 확인합니다. 이번에 수정한 곳만이 아니라, 이전에 확인했던 흐름도 함께 다시 실행합니다. 사람은 지치지만 적어 둔 것은 지치지 않습니다.

셋째, 무엇을 봤는지 남습니다. 통과했는지 실패했는지, 어느 단계에서 멈췄는지가 기록으로 남아 나중에 볼 수 있습니다.

테스트 시나리오는 실제로 이렇게 씁니다

Specnote는 이 확인을 대신 적어 두고 반복하는 도구입니다. 코드를 읽지 않아도 됩니다.

1. 쓰던 AI 도구에 연결합니다. 클로드 코드라면 두 줄을 붙여넣고 한 번 허용하면 끝입니다. 토큰이나 설정 파일을 다룰 일이 없습니다.

2. 확인할 흐름을 말로 시킵니다. "회원가입이 되는지 확인하는 시나리오 만들어 줘"처럼 평소 하던 대로 말하면, 단계가 평범한 한국어로 만들어집니다. 기획 문서를 그대로 넘겨도 됩니다.

3. 통과 조건은 사람이 승인합니다. 무엇을 통과로 볼지는 AI가 정하지 않습니다. 만들어진 단계를 읽고 당신이 승인해야 정식으로 반영됩니다. 앞 글에서 다룬 문제 — 만든 쪽이 판정까지 맡으면 판정이 기울어진다 — 를 여기서 끊습니다.

4. 배포할 때마다 다시 실행됩니다. 승인된 시나리오는 그대로 남아, 다음 배포에서도 같은 흐름을 실제 크로미움 브라우저가 사람처럼 눌러봅니다. 통과·실패 두 값과 함께 화면 영상이 남습니다.

한 번 승인해 두면 배포할 때마다 같은 흐름을 다시 눌러본다

실패했을 때가 진짜 중요합니다

확인의 값어치는 실패했을 때 나옵니다. 통과만 알려주는 확인은 안심만 줍니다.

실패하면 어느 단계에서 멈췄는지, 화면에 무엇이 표시됐는지가 리포트로 남습니다. 그 리포트를 쓰던 AI 도구가 그대로 읽어갑니다. 리포트를 보고 코드를 수정한 다음, 다시 확인을 실행합니다.

정리하면 이런 고리가 됩니다.

Specnote가 코드를 수정하지는 않습니다. 수정은 계속 쓰시던 AI 도구가 합니다. Specnote는 어디에 문제가 있는지 정확히 짚어 주는 쪽만 맡습니다.

실패가 끝이 아니라 다음 행동으로 이어진다

오류가 자주 생기는 자리는 정해져 있습니다

수정 한 번이 어디까지 영향을 주는지는 미리 알기 어렵습니다. 다만 여러 화면이 함께 쓰는 코드일수록 영향 범위가 넓다는 것은 분명합니다.

대개 이런 자리입니다.

• 로그인 상태를 확인하는 코드 — 거의 모든 화면이 함께 씁니다. 여기가 틀어지면 로그인은 되는데 특정 화면만 들어가지지 않는 일이 생깁니다.
• 결제·정산과 이어진 코드 — 결제 화면 하나만 쓰는 것이 아니라 주문 내역, 영수증, 알림 메일이 같은 값을 참조합니다.
• 화면 이동 규칙 — 주소가 바뀌는 방식을 손대면 전혀 다른 화면에서 이동이 멈춥니다.
• 공통 화면 요소 — 버튼, 입력창, 알림창처럼 여기저기 재사용되는 부분입니다.

수정한 곳이 이 목록에 걸린다면, 그날은 수정한 화면만 확인하고 끝내지 않는 편이 안전합니다.

기록이 쌓이면 원인 찾기가 쉬워집니다

확인을 반복하면 부수적으로 따라오는 것이 있습니다. 언제부터 문제가 생겼는지 알 수 있게 됩니다.

회차마다 통과·실패가 남으므로, 문제가 보고됐을 때 "3회차까지는 정상이었고 4회차부터 실패"라는 것을 바로 볼 수 있습니다. 그 사이에 무엇을 수정했는지만 확인하면 원인 범위가 좁혀집니다.

이것이 없으면 순서가 뒤집힙니다. 사용자가 알려 준 시점부터 거슬러 올라가며 언제부터 문제였는지를 먼저 추측해야 합니다. 그 추측이 틀리면 엉뚱한 곳을 계속 보게 됩니다.

실패한 회차에는 화면 영상도 함께 남습니다. 사용자가 겪은 화면을 그대로 다시 볼 수 있으니, "저는 그렇게 안 되던데요" 같은 대화를 줄일 수 있습니다.

무엇부터 적어 둘까요

바이브 코딩으로 만든 앱이라면 배포 전 점검을 어디까지 할지부터 정해야 합니다. 이렇게 적어 두는 확인 항목 하나하나가 곧 테스트 케이스이고, 그것들이 이어진 흐름이 테스트 시나리오입니다. 전부 적을 필요는 없습니다. 이 기준으로 고르시면 됩니다.

• 멈추면 매출이 멈추는 흐름 — 결제, 구독 시작
• 멈추면 사용자가 들어오지 못하는 흐름 — 회원가입, 로그인
• 이미 한 번 문제가 있었던 흐름 — 같은 자리에서 다시 발생하는 일이 흔합니다

세 개면 충분합니다. 여기서 시작해 필요할 때 늘리면 됩니다.

지금 테스트해보기