[AI와 같이 고친 에러들] “코드는 안 바꿨다”는 말, 테스트 범위까지는 아니었다
우리 매장 발주 화면이 점점 무거워지고 있었다. 한 파일에 기능이 계속 쌓이다 보니 코드 길이가 3천 줄 가까이 됐고, AI에게 “동작은 그대로 두고 위치만 옮기자”는 리팩토링 작업을 맡기게 됐다. 🙂 비개발자인 나로서는 “어차피 안 바뀐다는데 뭘 그렇게 조심스럽게 하나” 싶었다. 코드를 옮기기만 하는 건데, 뭐가 걱정이란 말인가.
이번에 손댈 부분은 거래처별 미출 엑셀(업체마다 형식이 다른 발주 엑셀) 업로드 로직이었다. 한 파일에 몰려 있던 업로드 함수들을 세 개로 나누고, 적정재고를 저장하는 부분도 따로 뺐다. 처음엔 이 정도면 “파일 분리 끝났고 빌드 통과했으니 끝”이라고 생각했다. 코드를 그대로 복사해서 옮긴 거니까 당연히 그대로 돌아가지 않겠나 싶었던 거다.
사실 이 부분은 전에 [[AI와 같이 고친 에러들] 상세페이지 HTML을 지우던 자동화, 태그를 살려야 했다](https://kimvibe.kr/ai%ec%99%80-%ea%b0%99%ec%9d%b4-%ea%b3%a0%ec%b9%9c-%ec%97%90%eb%9f%ac%eb%93%a4-%ec%83%81%ec%84%b8%ed%8e%98%ec%9d%b4%ec%a7%80-html%ec%9d%84-%ec%a7%80%ec%9a%b0%eb%8d%98-%ec%9e%90%eb%8f%99%ed%99%94/)에서도 비슷하게 헤맸던 지점이라, 그때 기록을 다시 들여다보면서 확인했다.
그런데 AI는 그 전에 한 단계를 더 거쳤다. 실제 화면을 켜지 않고, 가짜 데이터베이스와 가짜 알림창을 만들어서 각 업로드 케이스를 하나씩 돌려봤다. 기본 형식, 특정 거래처 전용 형식, 여러 파일을 한꺼번에 올리는 경우, 심지어 일부러 깨진 파일을 넣어보는 경우까지 표로 정리해서 보여줬다. 결과는 전부 기대한 대로 나왔다길래 “이 정도면 다 된 거 아닌가” 했는데, 여기서 또 한 번 헷갈렸다.
AI가 스스로 짚은 게 있었다. “이 테스트로 확인하지 못한 것”이라는 문구였다. 가짜 환경에서 함수 자체는 맞게 돌아간다는 걸 보여줬지만, 실제 화면에서 업로드 버튼을 눌렀을 때 그 버튼이 방금 나눈 함수로 제대로 연결되는지는 따로 확인한 게 아니라는 얘기였다. 비개발자 입장에서는 “함수가 맞으면 버튼도 맞는 거 아니냐”고 생각했는데, 그 둘은 서로 다른 층의 문제였다. 🎨 코드 안에서 계산이 맞는 것과, 화면에서 그 계산까지 실제로 연결되는 것은 따로 봐야 하는 확인이었다.
그래서 결국 화면에서 직접 거래처 엑셀 하나를 올려서 확인하기로 했다. 가짜 테스트를 거쳤다고 해서 실제 클릭 확인을 건너뛴 게 아니라, 가짜 테스트는 “계산 로직이 맞는지”를 미리 걸러내는 1차 관문이었고, 실제 클릭 확인이 진짜 마지막 관문이었던 셈이다.
재미있는 건 그다음에 또 있었다. 작업이 끝나고 원래 브랜치로 돌아가려는데, “main은 이미 다른 작업 폴더에서 쓰고 있다”는 오류가 떴다. 알고 보니 같은 코드 저장소를 여러 폴더(워크트리)로 나눠서 동시에 작업하고 있었는데, 그중 하나가 이미 main을 차지하고 있어서 생긴 문제였다. 처음엔 또 뭔가 잘못된 줄 알았는데, 이건 에러가 아니라 “지금 이 폴더에서는 새 가지를 따로 만들어서 작업하라”는 안내였다.
돌아보면 오늘 하루는 “확인했다”는 말을 들을 때마다 그 범위를 한 번씩 되물어야 한다는 걸 다시 배운 날이었다. 빌드가 통과했다는 건 문법이 맞다는 뜻이고, 가짜 데이터로 통과했다는 건 계산이 맞다는 뜻이다. 그런데 화면에서 버튼을 눌러야 비로소 “사용자가 실제로 쓸 수 있다”는 확인이 끝난다. 비개발자 입장에서는 이 세 가지를 뭉쳐서 “다 됐다”로 듣고 싶어지는데, AI가 매번 “이건 확인했고, 이건 아직 안 확인했다”고 선을 그어준 덕분에 마지막 클릭까지 놓치지 않을 수 있었다. 확신보다 중요한 건, 지금 내가 보고 있는 확인이 어디까지인지를 아는 일이었다.