[비개발자 자동화 노트] 사이즈로 정렬해달라고 했는데, 왜 글자 전체로 줄을 세우고 있었을까

발주 페이지 하나를 손보다가 또 한 번 머리를 긁적인 날이다. 요청은 간단했다. 브랜드를 여러 개 동시에 골라서 보고 싶다, 그리고 품목을 “규격”으로 정렬할 때는 숫자(타이어 사이즈)만 보고 줄을 세워 달라. 말로 하면 한 줄인데, 두 번째 요청에서 한참 헤맸다. 🙂

처음엔 이게 단순히 정렬 버튼 하나를 추가하는 문제라고 생각했다. 상품명 컬럼에 “정렬” 버튼을 누르면 테이블 라이브러리가 알파벳/숫자 순서로 알아서 정렬해줄 거라 믿었다. 실제로 화면에는 버튼이 멀쩡히 생겼고 클릭하면 뭔가 순서가 바뀌긴 했다. 그런데 눈으로 보니 이상했다. 사이즈로 정렬했다고 했는데 전혀 사이즈 순서가 아니었다.

사실 이 부분은 전에 [[비개발자 자동화 노트] AI가 고친 파일이 화면에 안 보일 때, 진짜 화면 파일을 찾은 날](https://kimvibe.kr/%eb%b9%84%ea%b0%9c%eb%b0%9c%ec%9e%90-%ec%9e%90%eb%8f%99%ed%99%94-%eb%85%b8%ed%8a%b8-ai%ea%b0%80-%ea%b3%a0%ec%b9%9c-%ed%8c%8c%ec%9d%bc%ec%9d%b4-%ed%99%94%eb%a9%b4%ec%97%90-%ec%95%88-%eb%b3%b4/)에서도 비슷하게 헤맸던 지점이라, 그때 기록을 다시 들여다보면서 확인했다.

여기서부터가 비개발자 입장에서 좀 헷갈리는 지점이었다. 화면에 보이는 상품명은 “245/45R18 (한국) LH01 라우펜 (프리미엄)K” 같은 긴 문자열이다. 이 안에 사이즈(245/45R18), 브랜드, 패턴명, 플라이레이팅 같은 정보가 다 뒤섞여 한 줄로 들어가 있다. 나는 당연히 “정렬 기준이 사이즈”라고 입력했으니 시스템이 그 문자열 안에서 숫자 부분만 알아서 뽑아 비교해줄 거라 생각했다. 그런데 실제로는 그냥 상품명 전체 문자열을 통째로 비교하고 있었다. 숫자든 브랜드명이든 패턴명이든 구분 없이, 그냥 글자 순서대로 줄을 세운 것이다. 그러니 “165”로 시작하는 작은 사이즈와 “265”로 시작하는 큰 사이즈가 뒤섞여 보이는 게 당연했다.

AI와 같이 코드를 들여다보면서 확인한 게, 정렬 로직이 “product_name_sort”와 “product_size_sort”라는 두 가지 기준으로 나뉘어 있다는 점이었다. 이름만 보면 사이즈 전용 정렬 기준이 따로 있는 것 같았는데, 실제로 그 기준이 참조하는 값이 상품명 문자열 그대로였다. 즉 기준의 이름은 “사이즈”였지만 실제로 비교하는 데이터는 사이즈가 아니었다는 뜻이다. 이름과 실제 동작이 다른 경우였다. 비개발자 입장에서는 버튼 이름을 믿었는데, 버튼 뒤에서 실제로 무슨 값을 비교하고 있는지는 따로 확인해야 한다는 걸 다시 배웠다.

확인 과정에서 다른 실마리도 하나 나왔다. 코드 안에 이미 “245/45R18” 같은 문자열에서 숫자 패턴만 뽑아내는 함수가 따로 있었다. 배송비 계산할 때 쓰던 함수인데, 정규식으로 “숫자3자리/숫자2~3자리R숫자2자리” 모양만 찾아서 그 부분만 추출하는 역할이었다. 처음엔 이걸 못 보고 지나갔다. 전혀 다른 용도(배송비 조회용 키 생성)로 만들어둔 함수라서, 정렬 문제와 연결해서 생각하지 못한 것이다. 그런데 결국 필요한 건 똑같았다. “뒤섞인 문자열에서 사이즈 숫자만 뽑아내는 일”은 배송비 계산이든 정렬이든 똑같이 필요한 작업이었다.

그래서 정렬 기준을 상품명 문자열 전체 비교가 아니라, 그 문자열에서 사이즈 숫자만 뽑아낸 값으로 비교하도록 바꿨다. 폭(245), 편평비(45), 인치(18) 순서로 숫자만 떼어내서 비교하니, 그제야 작은 사이즈부터 큰 사이즈까지 제대로 순서가 맞았다. 다중 브랜드 선택 쪽은 오히려 수월했다. 기존에 브랜드 하나만 고를 수 있던 체크 구조를 다중 선택이 가능한 배열 구조로 바꾸기만 하면 됐고, 화면에서 바로 결과가 보여서 확인이 쉬웠다.

작업 중간에 작은 삽질도 하나 있었다. DB에서 실제 사이즈 데이터를 직접 조회해서 비교해보려다가 인증 토큰 형식이 안 맞아 몇 번 실패했다. 서버 쪽 비밀키를 새로 받아 바꾼 지 얼마 안 됐었는데, 그 영향으로 예전 방식의 조회가 막혀 있었던 거였다. 이것도 사실 오늘의 핵심 문제와는 상관없는 길이었는데, 한동안 거기서 시간을 썼다. 결국은 DB를 직접 들여다보지 않고 코드 안에 있는 샘플 데이터만으로도 충분히 확인할 수 있었다.

비개발자 김부장이 오늘 다시 느낀 건, 기능 이름과 실제 동작은 분리해서 생각해야 한다는 점이다. “사이즈 정렬”이라는 이름이 붙어 있어도, 그 뒤에서 실제로 무엇을 비교하고 있는지는 꼭 확인해봐야 한다. 그리고 전혀 다른 목적으로 이미 만들어둔 기능(이번엔 배송비 계산용 숫자 추출 함수)이 지금 문제를 푸는 데 그대로 쓰일 수도 있다는 것도 새삼 느꼈다. 급하게 새로 만들기 전에, 비슷한 걸 이미 어디선가 풀어놓지 않았는지 한 번 둘러보는 습관이 필요하다. 오늘도 AI가 답을 바로 찾아준 건 아니었다. 코드를 같이 뒤지고, 눈으로 결과를 보면서 “이건 아니네” 하고 되짚는 과정이 있었고, 그 과정 끝에 생각보다 단순한 답이 나왔다. ✨

[비개발자 자동화 노트] 사이즈로 정렬해달라고 했는데, 왜 글자 전체로 줄을 세우고 있었을까

관련 글 더 보기

댓글 남기기 응답 취소