WHERE절로 때려 넣기 전에 '이것'부터 고민했어야 했다

🧩 배경

최근 팀에서 새로운 AI 서비스 개발에 착수했다. 그중 프롬프트 엔지니어링을 제대로 하려면 기준이 될 '레퍼런스 데이터'가 필요했고, 전체 데이터 중 특정 조건에 맞는 샘플 10여 개를 뽑아보자는 의견이 나왔다.

사실 이때까지만 해도 금방 끝날 아주 가벼운 업무라고 생각했다.

 

💭 고민의 내용

문제는 단순했다.

특정 조건(seq=0, nm!='NONE')에 맞는 최근 한 달 데이터 cnt 상위 10개를 조회하는 쿼리였는데

조회 기간을 1주일로 설정하면 0.7초 만에 나오던 결과가 1개월로 늘리는 순간 50초가 넘어도 응답이 없었다.

 

"내 쿼리가 잘못됐나? 조건이 복잡한 것도 아닌데 왜?"

답답했다. 특히 COUNT(*)만 하면 무한 로딩에 빠지는 화면을 보며 내 실력의 밑바닥을 마주한 기분이었다.

 

일단 내가 조회 대상 자체를 잘못 설계하고 있다는 직감이 들었지만 정확히 뭘 고쳐야 할지 몰라 당황스러웠다.

 

🛠️ 해결을 위한 시도들

처음엔 인덱스가 문제인가 싶어 대리님께 여쭤봤다. 대리님도 nm 컬럼에 단일 인덱스가 필요할 것 같다며 함께 방법을 고민해 주셨다.

하지만 진짜 해결사는 부장님의 한 마디였다.

부장님은 내 쿼리를 보시더니 "그거 나한테 보내봐"라고 하셨고 그로부터 5분 뒤 부장님은 새로운 쿼리를 보내주셨다.

 

📈 변화

내가 쓰던 테이블이 아니라 뒤에 날짜가 붙은 생소한 이름의 테이블을 조회하고 계셨다.

여기서 큰 깨달음을 얻었다.

 

1. 조회 대상의 범위

WHERE 절은 거대한 창고에서 물건을 하나하나 검사하며 찾는 느낌이라면, 파티션 테이블을 지정하는 건 애초에 그 물건이 있을 법한 작은 방에만 들어가는 것이었다.

2. 데이터의 질

단순히 10개를 뽑는 게 중요한 게 아니라

'기준'이 되는 데이터를 효율적으로 뽑아낼 줄 알아야 그 다음 작업도 속도가 붙는다는 걸 알게 됐다.

3. 시야의 확장

쿼리는 단순히 문법 싸움이 아니라

우리 회사의 DB가 어떻게 쪼개져 저장되어 있는지(구조)를 이해하는 싸움이었다.

4. 소통의 힘

모르는 걸 숨기지 않고 물어봤을 때 선배들의 노하우(인덱스 설계, 파티션 활용)가 내 지식으로 흡수되는 속도는 혼자 구글링 할 때와 비교도 안 될 만큼 빨랐다.

 

📌 회고 & 다음 목표

이번에 배운 가장 큰 교훈은 "조회 조건보다 조회 대상이 먼저다"라는 것이다.

무작정 WHERE 절로 조건을 나열하기 전에 내가 지금 뒤지고 있는 이 테이블이 최선인지 더 작은 단위로 쪼개진 파티션은 없는지 먼저 살피는 습관이 필요하다는 걸 뼈저리게 느꼈다.

 

이번 삽질을 통해 깨달은 건 나에게게 필요한 건 멋진 알고리즘이 아니라 DB가 데이터를 어떻게 찾아가는지에 대한 이해라는 점이다.

50초 걸리던 쿼리를 3초 내로 줄이는 건 코드 몇 줄의 수정이 아니라 인덱스와 파티션이라는 '구조'의 힘이었다.

 

 

다음 목표:

1. 우리 팀 DB 구조 파악하기: 자주 사용되는 table을 기준으로 어떻게 쪼개져있고 왜 이렇게 쪼개져있고, 이렇게 쪼개져있다면 이 컬럼은 꼭 필요한지(백그라운드 듣기) 등 다양한 각도에서 보는 연습을 할 거다. 
2. 데이터 샘플링 스킬업: AI 서비스 개발을 위해 '좋은 데이터 10개'를 빨리 골라내는 나만의 쿼리 셋을 만들어두려 한다.
3. 기록하는 개발자: 오늘 느낀 이 당혹감을 잊지 않고 다음에 같은 문제를 만났을 땐 누군가에게 도움을 줄 수 있는 선배가 되고 싶다.

실무를 하다 보면 이론으로만 배웠던 것들이 얼마나 무력해지는지 자주 느낀다...ㅠㅠ

 

그래도..

어디서 봤는데

내가 멍청해보이면 그건 성장하고 있다는 좋은 신호랬다.

그렇담 나는 오늘도 좋은 경험을 한 것이다!