검색 조회 상한이 기본값 그대로여서 한 번에 100건을 가져오는데 화면에는 20건만 보여 주고 있었다. 나머지 80건은 매번 가져와서 그대로 버리고 있는 셈이었다.
Table of contents
Open Table of contents
버리는 만큼의 비용
과금이 조회 건수 기준이라 하루 조회 수에 100을 곱한 만큼 비용이 나가고 있었다. 상한을 화면에서 실제로 쓰는 수에 맞추니 조회 건수가 5분의 1로 줄었다.
건수만 줄이면 되는 줄 알았는데 손대야 할 기본값이 하나 더 있었다. 점수 하한이 0으로 돼 있어서 관련 없는 결과까지 함께 나오고 있었다.
품질까지 나빴던 이유
점수 하한이 없으면 상한 건수를 채우려고 점수가 낮은 것까지 끌어오게 된다. 그래서 검색어와 관련 없는 항목이 목록 뒤쪽에 계속 붙어 있었다.
건수를 줄이고 점수 하한을 두니 억지로 채우던 것이 없어지면서 품질도 같이 좋아졌다. 가져와서 버리는 구조가 비용과 품질을 동시에 나쁘게 만들고 있었다.
하한을 정한 방법
하한 값은 점수와 결과 제목을 같이 찍어서 눈으로 보며 정했다. 어느 점수 구간부터 관련 없는 것이 나오는지를 확인하고 그 경계를 잡았다.
검색어 하나로 정하면 그 검색어에만 맞는 값이 되므로 여러 개로 확인했다. 시간 제한도 함께 뒀는데 무제한이면 느린 조회가 계속 잡고 있기 때문이고 제한에 걸리면 부분 결과라는 것을 로그로 남겼다.
다른 기본값 훑기
검색 말고도 기본값을 그대로 쓰고 있는 자리를 전부 훑었다. 데이터베이스 연결 풀과 HTTP 클라이언트와 캐시와 큐 다섯 군데였고 대부분 기본값 그대로였다.
연결 풀 크기가 기본값이라 요청이 몰릴 때 대기가 생기고 있어서 프로세스 수에 맞춰 실측 후 올렸다. 전부 바꾼 것은 아니고 재시도 횟수처럼 그대로 두는 것은 왜 그대로 두는지를 주석으로 적었는데 기본값을 쓰는 것과 안 본 것은 다르기 때문이다.
셋을 같이 본 검증
건수를 줄여 비용과 속도가 나아졌지만 품질이 나빠졌을 수 있어서 지표를 함께 봤다. 검색 후 클릭률은 올랐고 결과 없음 비율이 조금 늘어 있었다.
결과 없음이 는 것은 점수 하한 때문이었고 관련 없는 것을 안 보여 주니 아예 없는 경우가 생긴 것이다. 결과가 없으면 하한을 풀고 다시 찾되 관련도가 낮을 수 있다는 표시를 붙였다. 비용과 속도만 보고 품질을 안 보면 개선이 아니라 교환이 되므로 셋을 같이 봤다.
정리
- 기본값은 어느 상황에도 안 맞을 수 있다
- 가져와서 버리는 것이 있으면 그만큼 비용이 든다
- 건수만이 아니라 다른 기본값도 본다
- 하한이 없으면 억지로 채우면서 품질이 나빠진다
- 하한은 점수와 결과를 같이 찍어 여러 입력으로 정한다
- 시간 제한을 두고 부분 결과임을 표시한다
- 기본값을 쓰는 자리를 훑고 그대로 두는 이유를 적는다
- 비용과 속도와 품질 셋을 같이 본다