검색어 자동완성 API 최적화 - 11만 개 데이터에서 100ms 내에 응답

프로젝트 소개

• NewCodes는 기업 기술 블로그 큐레이팅 서비스
• Spring Boot + PostgreSQL 아키텍처
• 검색어 자동완성 기능 구현: Term 기반 추천, 자모 분리 검색, 초성 검색, 기업 페이지 추천

성능 문제 발견

• Term 테이블에 11만 개 데이터 축적
• API 응답 시간이 1000ㅡ 이상으로 증가
• 목표: 100ms 이내 응답

1차 시도: 인덱스 추가 (1000ms → 700ms)

• varchar_pattern_ops를 사용한 LIKE 접두사 검색 최적화 인덱스 생성
• CONCURRENTLY 옵션으로 서비스 중단 없이 인덱스 생성
• term, decomposed_term, chosung 컬럼에 각각 인덱스 적용

2차 시도: LOWER 함수 인덱스 (700ms → 110ms)

• LOWER() 함수 사용으로 인한 풀스캔 문제 발견
• 함수 기반 인덱스(Functional Index) 생성
• LOWER(컬럼명) varchar_pattern_ops 형태로 인덱스 재구성

3차 시도: JOIN → EXISTS (110ms → 100ms)

• Corporation과 Article의 INNER JOIN이 성능 병목
• EXISTS 서브쿼리로 변경하여 스캔 범위 축소
• "데이터 존재 여부"만 확인하도록 최적화

4차 시도: 비정규화 & 커버링 인덱스 (100ms → 90ms)

• total_frequency 컬럼 추가로 집계 연산 제거
• GROUP BY, SUM 연산을 미리 계산된 값으로 대체
• 커버링 인덱스로 I/O 횟수 감소
• INCLUDE 절로 term과 total_frequency를 인덱스에 포함

5차 시도: JDBC Template (90ms → 80ms)

• JPA/Hibernate 오버헤드 제거
• JDBC Template으로 직접 쿼리 실행
• 단순 조회에서는 ORM 레이어 생략이 효과적

Nginx Rate Limiting 문제 해결

• 초기 설정: 1초에 2회 제한, burst 10
• 100ms 디바운싱으로 인한 요청 실패 발생
• 개선: 1초에 10회 허용, burst 20으로 변경
• 444 → 429 status code 변경

응답 데이터 크기 축소

• JSON 필드명 제거, 배열 기반 응답으로 변경
• 타입을 숫자로 구분 (0: Corporation, 1: Theme, 2: Term)
• 네트워크 전송 시간 감소

CompletableFuture 병렬 처리

• Corporation, Theme, Term 조회를 독립적으로 동시 실행
• 순차 실행 대비 최대 응답 시간만큼만 소요
• ExecutorService와 예외 처리 추가

최종 성과

• 초기 1000ms → 최종 80ms (개발 서버), 40ms (운영 서버)
• 약 90% 이상 성능 개선

주요 학습 내용

• 문제 정의와 방향성 설정의 중요성
• AI 활용과 개발자의 검수 균형
• 전체 아키텍처 관점의 설계 필요
• 인덱스 종류 선택: 단일/복합/커버링 인덱스
• 함수 사용 시 인덱스 무효화 주의
• JPA 내부 동작 이해
• EXPLAIN을 통한 쿼리 실행 계획 분석

향후 개선 방향

• Trie 자료구조 사용
• 자주 검색되는 용어 캐싱
• CDN 활용 (글로벌 서비스 시)

[winterjung]

잘 읽었습니다. 처음엔 단순히 인덱스 걸었다는 글이려나? 싶었는데 이에 그치지 않고 다양한 방법을 시도해주시고 공유해주셔서 좋네요. 차후엔 말씀하신대로 trie를 써봐도 좋겠고 혹은 최근 검색이 많이된 트렌드 term은 좀 더 가중치를 준다거나 하는식으로 개선해봐도 좋겠네요!
하나 궁금한건 term과 decomposed term 둘 다 or 조건으로 조회하시던데 decomposed term가 상위호환이니 이 필드만 조회해도 되지않나하는점이네요. 쿼리가 “넹”이어도 “ㄴㅔㅇ”로 분리되니 “네이버”로 검색될거라 생각해서요. 실제 term이 “넹”인것도 마찬가지로 검색될테고.

[newcodes7]

말씀해주신 것처럼 decomposed term만으로 조회해도 충분합니다. 이게 생긴 이상 term은 불필요한 조건이었는데 이를 고려하지 못했던 것 같습니다. 덕분에 수정했습니다. 감사합니다!

[skageektp]

긱뉴스 보러 온 사람들이 보고 싶은 내용이라기엔~ 조금 거시기 한데? 라는 느낌이 없잖아 있는게 아닌가 싶네요.

[crawler]

글 쓰는 거야 자유긴 한데...

검색어 자동완성 API 최적화 - 11만 개 데이터에서 100ms 내에 응답

제목은 이렇게 거창한데 실제로는 인덱스도 적용이 안 된 상태라면 어이가 없을 수밖에 없죠.

마켓컬리에서 실제 서비스를 최적화 하는 것도 신규 서비스 배포 전에 실험과 개선을 반복한 이야기 정도로 겸손한 제목인데 정말 이 글의 제목에 어그로가 하나도 없다고 할 수 있을까요?

지금 반발은 독자가 제목을 보고 클릭하면서 기대한 것과 실제 내용과의 차이에서 나오는 괴리감에서 오고 있다고 생각합니다.
저도 새로운 최적화 방법 배울 기대하고 들어왔다가 실망하고 나갑니다.

[kunggom]

뭐가 거창한지 정말로 이해가 되지 않습니다.
레코드 수가 뭐 100만 건, 1000만 건씩 되는 것도 아니고 10만 건 조금 넘는 규모라는 것이 제목에서부터 박혀 있는데, 거기서 기본에 충실하기보다 뭔가 거창한 최적화를 기대한다는 것 자체가 좀 이상하지 않습니까? 대체 무슨 거창한 것을 기대한 것인지 궁금합니다.
DB가 제대로 최적화되어 있지 않은 상태에서 기본에 충실하게 하나씩 맞춰 나가는 구성의 글을 올린 것이 그 자체로 그렇게 어그로 취급받아야 할 것인지 잘 모르겠군요. 제 생각에는 '최고의 무언가가 아닌 것은 여기에 올리는 것 자체가 잘못이다'라는 식의 배타적 분위기는 유해하다고 생각합니다.

[crawler]

거기서 기본에 충실하기보다 뭔가 거창한 최적화를 기대한다는 것 자체가 좀 이상하지 않습니까?

사람은 아는 만큼 보입니다.
이해를 쉽게 하기 위해 저는 지금 게시판 만들기의 예시를 생각하고 있습니다.

초보 개발자에게 첫 포폴로 많이 추천됐던 것이 게시판 만들기입니다.

단순하게 생각하면 간단합니다.
글을 올리고, 목록에서 보이면 끝입니다. 정말 간단하게 만들면 백엔드 DB조차도 필요하지 않을지 모릅니다.

그런데 사람은 아는 만큼 보입니다.
게시판을 진지하게 만들면 DB부터 시작해서 댓글 기능, 로그인, 로그인을 발전시키면 OAuth 인증이나 JWT, 단순 글쓰기 기능에서도 이미지 및 영상 첨부, 글 서식 지원, XSS부터 시작하는 보안까지.

같은 텍스트라도 읽는 사람의 배경 지식에 따라 그리는 이미지가 크게 달라질 수 있습니다.

kunggom님이 제목을 보고 어떤 자동완성을 상상하신지는 알겠습니다.

그런데 읽는 독자 각자 다른 인생을 살아왔고, 결국 독자들이 상상한 기능은 서로 크게 다를 겁니다.

어떤 의도로 댓글을 작성하시는지도 알겠습니다.
저도 그 의견에 동의하지만, 지금 글 쓴 분의 상황과는 크게 맞지 않는 말이란 걸 아실 거라고 믿습니다.

[kunggom]

"지금 글 쓴 분의 상황과는 크게 맞지 않는 말"이라는 부분에 대해 조금 더 설명을 부탁드려도 될까요?
원문 글에 따르면 해당 프로젝트는 "개인 프로젝트이고 트래픽이 엄청 많거나 수익을 내야 하는 서비스는 아니"라고 명시되어 있습니다. 따라서 뭔가 거창한 최적화가 들어간다면 그건 그저 개인적인 호기심 등에 의한 것이지, 실용적인 이유는 아닐 것으로 추정할 수 있습니다. 따라서 그 정도의 기술적 노력이 투입되지 않는 것이 이상하다고 생각하지는 않는데, 유독 몇몇 분들의 반응이 강하게 부정적인 것이 이해가 되지 않는 것입니다. 제목에 인용된 수치 같은 부분이 본문 내용과 합치하지 않는 것도 아니고 말이죠.

[crawler]

저는 kunggom님이 제가 말한 게시판 비유도 이해하지 못 할 정도로 배경 지식이 없는 개발자라고 생각하지 않습니다.

지금 의견 차이는 Abusing 유저에 대한 인식부터 오는 거 같아서 마지막으로 말씀 드리겠습니다.

제가 기대했던 것은 시맨틱 검색입니다.
시맨틱 검색이라는 것이 AI 열풍인 지금에 있어서 전혀 현실성 없는 주제도 아니며, 개인이라도 충분히 구현 가능한 걸 아실 거라고 믿습니다.

애초에 저희가 제목을 누를 때부터 글 쓴 사람의 배경을 이해하면서 누르는 게 아니지만, 만약 트래픽이 엄청 많거나 수익을 내야 하는 서비스 가 아니라고 해도 충분히 구현 가능하다는 말입니다.

그리고 저는 지금 제목에 대해서만 말하고 있습니다.

원문 글에 따르면 해당 프로젝트는 ~

제목을 보고 상상했던 이미지에 대하여 말하고 있는데 이 부분은 지금 저희의 대화에서 필요가 없는 부분이죠.

지금 글 쓴 분의 상황
지금 kunggom님이 글 쓴 분을 뭐라고 생각하시는 지 알 거 같습니다. 초보 개발자고, 무슨 글을 쓰든 이해해줘야만 하는 개발자로 보시는 거 같네요.

어제 말한 듯이 flagged 당하지 않았다면 저도 거기에 동의했겠지만, 쓴 글을 추천 조작한 시점부터 이 얘기는 무의미합니다.

그리고 만약 정말로 어뷰징이 적발된 사람이 다음날 다시 글을 쓰는 것이 문제라고 생각한다면

위에서 이렇게 말하셨네요.
flagged 당하고도 글을 쓸 자유가 있다면 거기에 대해서 비판할 자유도 있습니다.
본인이 말씀 하신 것처럼 지금 댓글에서 flagged 당한 사람에게 조금 더 엄격하게 말하는 것이 문제가 있다고 생각하면 댓글에서 지적할 게 아니라 운영진에게 건의해보시길 바랍니다.

[kunggom]

임베딩을 넣거나 해서 개떡같이 입력해도 찰떡같이 검색 후보를 추천해주는 그런 종류의 서비스에 대한 최적화 경험 공유를 생각하셨다는 것이군요.
그런 것이라면 차라리 "검색어 추천" 정도의 제목에서 기대해야 하는 게 아닌가 싶지만, 어떤 것을 예상하셨는지는 알겠습니다.

어뷰징에 비판적인 입장은 이해합니다만, 마지막 문장은 은근슬쩍 논지를 기술적 미숙함에서 커뮤니티 규칙 위반에 관한 문제로 바꾸고 "너의 논리와 주장으로 너를 반박해 주겠다"는 어설픈 태극권 시도인 것 같아 좀 실망스럽군요.
차라리 처음부터 어뷰징 한 가지만을 비판하셨다면 설득력이 있었을 것입니다. 정말로 그랬다면, 설령 정말로 위 글이 최신 DBMS에서의 벡터 임베딩 최적화 등 원래 기대했었다고 주장하신 내용이 담겨 있었더라도, 혹은 "겸손한 제목"이 사용되었더라도 글쓴이의 최근 어뷰징 이력에 대한 적대적 반응이 나왔을 것이고, 그 부분에 대해 저는 아무런 이의가 없습니다. 그건 기술적 내용과는 별로 상관이 없는 내용이니까요.

제가 반대하는 것은, 그 양상이 왜 "기술적 미숙함"에 대한 지적으로 표출되는가 하는 것입니다. 어뷰징이 용납할 수 없는 행동이라면, 당연히 내용과는 관계없이 비난받아 마땅하겠지요. 그러면 거기에 내용에 대한 비판이 들어갈 이유가 있을까요? 그런데 여기에 달린 댓글들은 하나같이 내용이 기술적으로 미숙하다는 뉘앙스가 다수네요. crawler님께서도 저에게 "초보 개발자의 게시판 만들기"와 같은 비유를 하시면서 "아는 만큼 보인다"고 하셨고 말이죠. 이러면 어뷰징이라는 건 오히려 부차적인, 나중에 가져다 붙인 문제가 아닌지 의심해봐야 하지 않겠습니까.

댓글 내용대로라면, 만약 원래 글이 정말로 crawler님께서 기대하는 종류의 내용이었다고 해도 어뷰징 자체만으로 비판을 하셨을 것입니다. 아니면 설마 어뷰징을 했는데도 불구하고 본인이 생각하기에 글 내용은 마음에 드는 경우 "엄격하게" 말할 자유를 행사할 필요가 없는 걸까요?
그래서 다시 질문드립니다. 정말로 원 글쓴이의 어뷰징 때문에 글쓴이를 비판하는 것이라면, 어뷰징이 아니라 내용에 관한 비판 위주로 댓글을 쓰신 이유가 있을까요?

[crawler]

만약 원래 글이 정말로 crawler님께서 기대하는 종류의 내용이었다고 해도 어뷰징 자체만으로 비판을 하셨을 것입니다.

엥? 아니요? 저는 제가 기대하는 내용이었으면 아무 불만 없었을 겁니다.
제가 돈 주고 보는 글도 아니고, 내용만 마음에 들면 흡수하면 제 이득이죠.

다만 그게 아니었기 때문에 이 사람 뭐 하는 사람이지? 라고 찾아보는 계기를 만들었고, 까고 보니 flagged여서 피드백 할 때 배려할 필요도 못 느꼈던 겁니다.

kunggom님은 참 신기합니다. 마치 이타적인 것처럼 사이트의 분위기를 생각하면서도, 그 분위기를 주장하느라 본인이 댓글에서 다른 사람들의 말할 자유를 방해하는 것은 신경도 쓰지 않습니다.

태극권이라는 말을 하셨죠.
저는 최대한 kunggom님이 이렇게 행동하는 의도를 이해해보려고 노력하는데, 지금 kunggom님은 주장에 매몰되어 타인의 마음을 멋대로 단정 짓고, 재단하는 거 같습니다.
지금도 제 의도를 전혀 파악하지 못했으면서 사실인 것처럼 긴 글을 쓰신 게 그 증거입니다.

그렇게 확신할 수 있는 이유가 궁금하지만, 이유를 듣지는 못할 거 같군요.

kunggom님이 정말 최대한 글쓰기를 장려하려는 걸지, 아니면 flagged에 대해 다른 의도가 있는 건지는 모르겠지만,
전자라면 저야 이득이고 후자라면 관리자님이 처리해주시겠죠.

결국 저에게 어느 쪽이든 이득이 될 테니 계속 그렇게 행동해주셨으면 좋겠습니다.

[kunggom]

"다른 사람들의 말할 자유를 방해"했다는 부분에 대한 근거가 있을까요? 이건 좀 이해가 안 되는군요. 제가 뭐 이 공간에 대한 관리 권한이 있어서 타인이 글이나 댓글 쓰는 걸 차단할 수 있는 것도 아닌데 말입니다. 실제로도 이렇게 긴 댓글을 잘만 쓰셨지 않습니까.
단순히 타인의 의견에 반대하는 댓글을 다는 것이 남의 말할 자유를 막는 것이라면, crawler님도 지금 저의 발언할 자유를 침해하고 있는 것으로 봐야 할 것입니다. 그게 아니라면 논리적으로 내로남불 아니겠습니까?

그리고 crawler님도 인정하신 것처럼, 결국 어뷰징 여부는 판단 기준에서 전혀 중요하지 않았다는 것입니다.
이건 "어제 말한 듯이 flagged 당하지 않았다면 저도 거기에 동의했겠지만, 쓴 글을 추천 조작한 시점부터 이 얘기는 무의미합니다."라는 내용과 모순 아닙니까?
지금 계속하여 논점과 주장이 바뀌는 것으로 보이는데, 한 가지로 고정해 주셨으면 좋겠습니다.

[ifmkl]

최고의 무언가를 요구한적은 없습니다. 다만 공통적으로 제목과 본문과 괴리를 느낀 분들의 의견이 있는것도 사실이며, 기존 어뷰징된 글에 대한 별도의 의사표명없이 바로 그 다음날 본인블로그의 글을 news에 올리는게 누군가에겐 다른 의도로 보일 수도 있는거죠. 그리고 개인적으로도 어뷰징을 단순실수로 넘기는 태도가 좋은 태도로 보이진 않는데, 어뷰징이 별거 아닌것 처럼 여겨지는 분위기도 유해하다고 생각할 수 있는 거겠죠?

[kunggom]

저는 커뮤니티의 주제와 충분히 연관성이 있고 AI 슬롭이 아닌 글에 대해 "이 글은 우리 커뮤니티의 수준에 어울리지 않는 수준 미달이다"라고 단체로 비난하는(혹은 그런 것처럼 보이는) 행위는 어쩌면 투표 조작보다도 더 커뮤니티의 성장과 유지에 해롭다고 봅니다. 이는 해당 커뮤니티의 대외적 이미지를 배타적으로 보이게 할 수 있으며, 그로 인하여 잠재적인 신규 사용자 유입을 크게 방해할 수 있기 때문입니다.

물론 이것이 비판을 하지 말자는 이야기는 아닙니다. 하지만 적어도 이런 분위기는 좀 이상하다고 생각하네요. 공통적으로 자신이 기대한 내용이 아니었다는 점에 대한 실망만 있을 뿐, 건설적으로 보이는 분석 및 피드백은 소수였으니 말입니다.

그리고 만약 정말로 어뷰징이 적발된 사람이 다음날 다시 글을 쓰는 것이 문제라고 생각한다면, 이번 기회에 운영진에게 정식으로 관련 규정 추가를 건의해 보시는 건 어떨까요? 이미 어느 정도는 제재가 있는 것으로 알고 있습니다만, 그것이 모자라다고 생각하시는 것 같으니 말입니다.

[ifmkl]

참 어뷰징 보다도 네거티브한 의견개진이 안좋은 행위로 보시니 최대한 재주껏 어뷰징도 노력해보겠습니다.

[bandcrownie]

육룡의시대, 웹삼국무쌍전처럼 타 사이트 갤러리에 본인 또한 홍보를 자주 하신 것 같습니다.
자신의 미완성 작업물을 찍먹용으로 내세우고 이후에 해당 프로젝트를 쉽게 유기하는 태도를 보았을 때 딱히 본 글과 뭐가 다를까 싶은데..왜 남에겐 엄격한 잣대를 적용하는걸까요.

디시는 어린애들 노는 곳이니 마음대로 해도 괜찮고, 긱뉴스는 본인이 애정하는 곳이니 다른 누군가 더럽히면 못참는 걸까요.

딱히 논리적으로 말하고 싶은거 아니고 그냥 내로남불 하는게 신박해서 하는 말이니 반박하는 님 말이 맞습니다. 어뷰징 화이팅입니다.

[ifmkl]

네 저도 님 말 맞다고 생각합니다. 답변안달면 정신승리하실거 같으니 진짜 승리하셨다고 생각시라고 답 달아드립니다.

[ifmkl]

전 오히려 이해가 가지 않네요. 단체로 조직적으로 비난하기 위해 올리신걸로 보시고 계신걸까요? 님 주장이야 말로 각 개인들이 개진할 수 있는 의견을 오히려 네거티브하게 모시는 거 같으신데요? 앞으로 개발 일지 정도의 글(printf로 별그리기 개선을 위해 목표를 세우고 개선해서 for문을 썼어요!)의 글들을 올려도 똑같이 따뜻한 마음씨로 봐주시길 바랍니다.

[tensun]

검색 자동완성 API를 최적화된 서비스 같은 제목에 내용은 그냥 디비 검색 최적화네요.
상업용이라면 오라클 최적화로 충분히 가능하고, 자동완성은 기존 서비스 많아요. 차별점 이야기도 없고 본인 습작 수준의 내용입니다.
좀 보기 거북합니다

[h3lloworld]

당연히 해야하는 작업을 대단한 최적화 처럼 적어서 심지어 이런 사이트에 올리는 건 오히려 부정적인 효과를 일으킬 수 있을듯 합니다. 기업 기술 블로그에 이런 글은 안 쓰겠죠.

[moderator]

운영자입니다.
현재 댓글 논의가 게시물의 기술적 내용과 무관한 부분까지 복합적으로 얽히며 과열되는 양상이 보여 안내드립니다.

기술적 토론과 피드백은 언제든 환영합니다.
의견은 다양할 수 있으나, 댓글 작성 시에는 상대방에 대한 기본적인 예의와 논리 중심의 논의를 부탁드리며, 개인이나 이력보다는 현재 게시물의 내용 자체를 중심으로 이루어지길 바랍니다.

사이트 이용법 의 댓글 작성 가이드를 다시 한 번 확인해 주시기 바랍니다.

• 친절하고 점잖게 얘기해주세요.
• 글쓴이를 저격하지 말아주세요.

참고로, 플래그된 게시물에 대해서는 이미 기록 및 시스템상 조치가 이루어지고 있으며, 관련 운영 정책과 시스템은 지속적으로 개선해 나가겠습니다.
또한 운영에 대한 의견과 피드백이 있다면 편하게 메일로 문의주세요.

[kunggom]

네, 알겠습니다.

[kunggom]

댓글 분위기가 좀 이상하다고 생각합니다. 혹시 처음 올라올 때와 비교하여 제목이나 내용이 바뀐 게 있나요? 이 정도 글이 올라오는 것 자체가 이상하다고 생각되지는 않습니다.
"기업 기술 블로그에 이런 글은 안 쓰겠죠."와 같은 의견도 있는데, 목표 성능을 정의하고 이를 달성하기 위해 개선을 반복하는 것은 기업 기술 블로그에서 종종 올라오는 내용입니다.
예를 들면 제가 예전에 본 것으로는 다음과 같은 글이 있네요.

• 신규 서비스 배포 전에 실험과 개선을 반복한 이야기

[kuthia]

말씀하신 것에는 동의합니다.
하지만 현재 사태는 어뷰징한 유저의 태도에 대한 지적이라고 봅니다. 포스팅의 수준이 어떻고 하는 것은 논점에서 벗어난 것 같아요.
비우호적인 반응은 글쓴이의 어뷰징 전적이라는 배경 때문이겠죠. 내용이 어떻고는 불필요한 사족이라고 봅니다.

[kunggom]

그래서 그 부분이 의문인 것입니다.
차라리 모두가 "이 사람 어뷰저에요!"와 같이 반응했다면 이런 댓글은 안 달았겠지요. 그런데 댓글은 대부분 원래 글의 수준을 논하는 것이었으니, 그 부분이 이상하다는 것입니다. 정말로 어뷰징이 문제라서 그런 거면 글의 수준 운운은 완전히 불필요한 사족이 아니겠습니까.

[nemorize]

동의합니다.
심지어 "2025년 5월부터 저 혼자 군대에서 만들기 시작했어요!" 라는걸 보면 기업 블로그도 아니고...

물론 공유된 내용이 "당연히 해야하는 작업"임을 부정하긴 힘들고,
"차별점 이야기도 없고 본인 습작 수준의 내용"인 것도 맞지만,

긱뉴스가 이런거 공유하면 안되는 분위기의 공간이었나요?
당연히 해야하는 작업들을 해 본 경험을 공유하면 안되는걸까요?
차별점이 없는 경험은 공유하면 안되는걸까요?
습작 수준의 경험은 공유하면 안되는걸까요?

[ifmkl]

그렇게 보이셨을 수도 있겠네요. 제가 댓글을 아래와 같이 단 이유는 두가지였습니다. 첫번째 올린 글 show gn의 글은 어뷰징으로 flagged 되었음. 하루 후 본인의 velog 글을 요약하여 새로 글을 올렸으나, 글 자체의 내용이 실질적으로 올라올 만한 글인가? 작성자 본인의 고민과 노력이 보였냐고 묻는다면 다른분들 의견처럼 검색은 보편적으로 기술이 어느정도 나와 있는 영역인데 기술적인 부분보다 블로그 내용 자체가 둘러서 본인 서비스의 홍보 연장 선상으로 생각되어 남긴 부분입니다.

[kunggom]

어뷰징 플래그로 미운 털이 박힌 게 가장 큰가 보군요.
블로그 내용 자체가 본인 서비스의 홍보의 연장선상인 것은 다른 기업의 기술 블로그도 마찬가지이기 때문에, 단순히 그것만으로 배척하는 것은 꽤 민감한 기준이라고 생각합니다.
그리고 이 글에서 작성자 본인의 고민과 노력이 보였는가 하는 부분에 있어서도, 인덱스를 걸면 성능이 개선될 거라는 가설이 부정되자 실행 계획도 살펴보고 비즈니스 로직을 고려하여 쿼리나 스키마를 바꿔나가는 식으로 개선을 반복하여 목표 성능을 달성하는 건 충분한 고민과 노력이 아닌가 싶습니다.

[newcodes7]

이번 글과 저번 글 관련해서 죄송하다는 말씀을 드립니다.
안 쓰는 계정 2개로 upvote를 했던 건 제 실수이며 어리석은 행위였습니다.

오랜 시간 공들였던 프로젝트가 사람들 눈에 더 띄었으면 하는 바람에 잘못된 행동을 했습니다.
그런데 그런 이유가 있었다 해도 규칙 위반을 정당화할 수 없다는 건 사실입니다.
제가 함부로 올린 upvote로 인해 누군가의 글 순위는 내려가야 했을 것이고, 사이트의 질서를 어지럽혔을 것입니다.

또한, flagged된 바로 다음 날 다른 새로운 글을 올렸던 건 충분히 오해의 소지가 있을 거 같습니다.
솔직히 말해서는 사이트 이용제재가 따로 없어서 바로 올려도 되나 싶었습니다. 이는 제 생각이 짧았습니다.
지금 생각해보면 제재 여부와 관계없이 자제했어야 했습니다.
반대의 입장에서 생각해봤을 때, 저라도 제가 좋아하는 공간에 누군가가 똑같은 행동을 했을 때 좋게 보이진 않았을 것입니다.

저는 그 동안 개발을 시작하고 나서 무조건적으로 '공유'가 좋다고 생각하며 실천해왔었습니다.
하지만 이번을 계기로 공유를 해야 할 공간이 따로 있고, 해야 할 때가 따로 있음을 느꼈습니다.
또한, 누군가가 애정과 관심을 가지는 공간에 내가 새롭게 들어왔다면 우선 상대방을 최대한 존중하는 게 맞다고 느꼈습니다.
그렇기에 이용수칙부터 읽고 사이트의 분위기도 살펴보며 이에 어긋나는 행동을 하지 말아야 했습니다.

제 잘못을 인정하는 바이며, 이렇게나마 소명을 드립니다.
다음부터는 더 성숙하게 이용할 수 있도록 하겠습니다.

[roxie]

:+1:

[ifmkl]

블로그도 가서 원문도 읽어보고 왔습니다. 제목과 실제내용 사이 괴리가 좀 느껴지네요. 구현하신 기능이나 개선한 방향 등은 이미 기존에 존재하는 여러 오픈소스들에 구현, 반영되있는 부분이고, 작업하신 건 본인 서비스에서 최초 단순하게 기능 구현해뒀던 검색을 고도화한 부분인데 제목만 보면 알고리즘 대대적 개선한 것 같은 느낌이,, 이전글도 홍보로 flagged 되셨던데 작성 하실때 조금더 고민이 필요하시지 않을까 싶네요.

[newcodes7]

그렇게 느끼셨다면 죄송합니다. 각자마다 제목을 보고 기대하는 내용이 다르리라 생각합니다. 다만 최대한 기대하는 내용이 비슷하게 명확한 제목을 작성해야 하는 게 맞습니다. 이는 주의하겠습니다.

또한, 이전 글과는 별개로 봐주셨으면 합니다. 이전 글은 제가 미사용 계정 2개를 사용해서 upvote를 시도하다가 flagged 되었습니다. 이는 엄연한 제 실수이며, 글 자체의 문제가 아니었음을 알려드리고 싶습니다.

[click]

lower() 인덱스 대신 GIN 인덱스를 사용해보는건 고려해보셨을지 궁금하네요. 어차피 jdbctemplate로 raw sql 쓰셨으니 이 참에 FTS는 어떠신가요?

CompletableFuture.supplyAsync() 를 사용한 비동기 방식도 별도 ExecutorService를 지정하지 않는다면 forkjoinpool의 commonpool을 사용하니
리퀘스트 스레드 대신 사용하는 commonpool이 가득 차는 정도까지(cpu 코어 - 1개) 동시접속자가 많아지면 감당하지 못할 수도 있습니다.
이 부분은 reactive 방식으로 변경하거나 jvm 버전을 올려서 가상 스레드를 도입하는 편이 깔끔하게 해결할 수 있을 겁니다.

[newcodes7]

안녕하세요! 먼저 피드백 댓글 달아주셔서 정말 감사합니다.

GIN 인덱스는 해당 경우에서 필요하지 않다고 판단했습니다! 현재 검색어 자동완성 추천 API에서는 term 자체만 필요합니다. 해당 term이 어떤 article들에 속하는지는 필요하지 않습니다.
반면에, 검색 API에서는 GIN 인덱스와 유사한 인덱스를 사용하고 있습니다. postgres의 extension인 paradeDB를 활용해서 BM25 인덱스를 사용합니다.
포스팅에는 자세히 안 나와있지만 현재는 ExecutorService를 별도로 지정해서 사용하고 있습니다. 다만 말씀해주신 것처럼 reactive 방식이나 가상 스레드도 추후 고려해보겠습니다!!