문서에서 /commands를 백틱 코드 형식으로 작성해 두었습니다. 그런데 "commands"로 검색하면 결과가 나오지 않습니다. 해당 토픽이 검색되려면 /commands로 검색해야 합니다.
이것은 의도된 동작인가요? 사용자가 /를 앞에 붙인 특정 명령어를 검색할 것이라고 기대하지는 않습니다. 제 생각에는 두 가지 방식으로 모두 해당 토픽을 찾을 수 있어야 합니다.
수정; 코드 포맷팅은 관련이 없으며, 단순히 "/commands"로 검색해도 동일한 문제가 발생합니다.
수정 2; 예를 들어 ".command"의 경우 이 문제를 재현할 수 없으며, "command"로 검색하면 이 경우 원하는 결과가 나옵니다.
희망 섞인 토픽 부스팅입니다. 
/commands를 검색할 때 재현되지 않습니다:
우리는 단순히 commands를 찾지 못했을 뿐이며, 이 경우를 찾아야 하는지 논쟁의 여지가 있지만, 엄밀히 말해 버그는 아닙니다.
“검색” 관련 설정을 찾아보았지만, 눈에 띄는 항목이 없었습니다. 뭘 찾아봐야 할지 혹시 아시나요?
아니요, 저는 그 동작이 의도된 거라고 생각합니다.
맞습니다. 사용자가 "을"을 포함해야 한다는 것을 사전에 알기를 기대하지는 않습니다. 이 동작이 의도된 것인지, 또는 가능한 우회책이 있는 이유가 있을까요? 왜냐하면 이것이 제 문서의 검색 가능성에 심각한 영향을 미치기 때문입니다.
검색은 복잡한 문제입니다 
이 내용을 노출시키고 싶지만, "commands"가 포함된 다른 문서들도 있고, "/commands"가 포함된 문서들이 이 경우에 표시되지 않기를 원한다면 어떻게 해야 할까요?
사용할 수 있는 한 가지 트릭은 게시물에 키워드를 포함하는 것입니다:
<small>Keywords: commands</small>
오, 맞아요, 복잡한 문제네요! /commands는 예시일 뿐이고, 실제로는 100개 이상의 명령어가 문서화되어 있습니다. 그래서 키워드를 사용하는 것이 대안이 될 수는 있지만, 이상적이지는 않아요.
해당 단어가 어딘가에 발견되면 검색 결과에 표시되어야 한다는 것이 제 이해입니다. 예를 들어:
/testcommand > 쿼리: testcommand > 
betacommand! > 쿼리: betacommand > 
!betacommand > 쿼리: betacommand >
여기서 /와 !의 차이는 무엇인가요?
이것은 데이터를 색인하는 방식 때문입니다:
“test /command” → “‘/command’:11 ‘test’:8A,10 ‘titl’:4A ‘uncategor’:9B”
“test !command” → “‘command’:11 ‘test’:8A,10 ‘titl’:4A ‘uncategor’:9B”
두 번째 경우에서 !가 사라진 것을 확인하실 수 있습니다. !를 유지하는 것을 반대하기로 결정했는데, 이는 검색에서 구두점 기호가 관련성이 없다고 판단되었기 때문일 것으로 추정됩니다.
아, 그렇군요. 제 생각에는 / 도 관련이 없을 것 같은데? 인덱싱이 어떻게 작동하는지는 정확히 모르겠지만, 이 부분을 변경할 수 있는 설정이 있다면 정말 큰 도움이 될 것 같습니다.
URL의 일부로 "somequery"를 입력하면 포럼 어딘가에 해당 URL이 있는 경우 https://domain.com/somequery-article-today라는 결과가 반환되는 것을 확인했습니다. 이는 예상되는 동작입니다. 이 두 가지가 얼마나 관련이 있는지는 모르겠지만, 이 경우 /가 관련이 없다는 점이 흥미로웠습니다.
더 깊이 파고들면서 발견한 또 다른 점은 슬래시로 구분된 문자열(query1/query2)입니다.
query1은 결과를 반환하지만 query2는 결과를 반환하지 않습니다. 제 생각에는 이것이 버그처럼 보이는데, 예상되는 동작이라고 보시나요? 
여전히 이것이 검색에 큰 영향을 미친다고 생각하므로 다시 올려봅니다. 최근 겪고 있는 불편한 점들 중 일부는 다음과 같습니다:
GitHub 링크 > 사용자 이름이나 저장소 이름이 검색되지 않음..
X 링크 > 사용자 이름이 검색되지 않음
이 외에도 많은 예시가 있습니다. 검색을 많이 의존하지 않는다면 이러한 문제들은 눈에 띄지 않을 수 있습니다. 검색 결과에서 보이는 부분에 영향을 주는 것이 아니라, 보이지 않는 부분에 영향을 주기 때문입니다. 우리는 항상 어떤 주제에 검색 가능성을 높이기 위해 키워드가 필요한지 계속 고민해야 하는 것이 아닙니다.
이 문제는 특히 초안/스태프 섹션에서 더 두드러집니다. 이 섹션의 게시글은 단순히 완성되지 않은 상태이거나, 때로는 수년간 그대로 방치되기도 하며, 통신 형식이 짧거나 내부적인 경우가 많습니다. 제가 이 키워드를 추가하지 않았다면, 스태프와 내부라는 키워드로 이 게시글을 찾을 수 없었을 것입니다.. 왜냐하면 Discourse가 단순히 이 단어들이 관련이 없다고 판단했기 때문인가요? 왜죠?
이것이 버그가 아니라 검색 색인 결정에 대한 매우 비범한 접근 방식이라는 데에 동의하기가 어렵습니다.
오늘 진행한 몇 가지 테스트 결과, 이 문제가 수정된 것 같습니다? 의도적인 수정인지는 확실하지 않지만, 감사합니다!
수정; 아니요, 같은 동작을 하고 있습니다. 
사실 이것은 PostgreSQL의 스테머(stemmer) / 토크나이저(tokenizer)가 작동하는 방식입니다. URL과 같이 혼동이 생길 수 있는 엣지 케이스에 대해 몇 가지 우회 방법을 마련해 두었지만, 전반적으로 이러한 작업의 상당 부분을 pg에 위임하고 있습니다.
흥미롭게도 몇 년 전에는 "URL 내 추가 인덱싱"을 위한 해킹 방식이 있었으나, 인덱스 부피 증가(index bloat) 문제로 @tgxworld가 제거했습니다.
제가 말씀드릴 수 있는 것은, 검색 시 이러한 유형의 엣지 케이스를 고려하고 있다는 것입니다. 하지만 pg fulltext의 기존 프레임워크를 우회하는 해킹 방식을 도입하기까지는 상당한 이유가 필요합니다.
답장 주셔서 감사합니다, Sam!
이 기술이 복잡한 부분이라는 점은 잘 이해하고 있어요. 혹시 좋은 우회 방법을 찾게 되길 바라면서, 그 사이에는 숨겨진 키워드와 이 제한을 우회하는 창의적인 방법들을 활용하고 있어요!
숨겨진 키워드를 일급 시민(first-class citizen)으로 취급하는 방식은 흥미롭다고 생각합니다.
