다른 분들처럼 나도 이런 경로를 밟아왔습니다:
- 현재 GitHub 저장소에서 다운로드한 목록으로 시작합니다.
- 바로 2,000개 항목 제한에 부딪힙니다.
- 아, 정규식(Regex)을 쓸 수 있구나 - 최고!
- 복잡한 정규식은 쉽게 100자를 넘습니다.
- 쪼개야 합니다.
- 정규식을 다듬는데, 어이쿠, 이 것도 100자를 넘었네요.
- 더 세밀하게 쪼개야 합니다.
제한 조건과 춤을 추는 것은 불가능한 일이 아니라, 그저 짜증나는 일일 뿐입니다. 특히 그 제한이 인위적인 경우 더더욱 그렇죠. 그렇다고 해서, 이 필터링이 동기식(synchronous)으로 이루어지며 확장된 처리가 성능 문제를 일으킬 수 있다는 점, 그리고 가능한 한 많은 사용자에게 적합한 제한을 설정하려는 어려움은 충분히 이해합니다. 따라서 제한 조건 때문에 고생하고는 있지만, 그것에 대해 합리적으로 이의를 제기할 수는 없습니다.
여기 word_watcher.rb에서 필터링 코드를 확인했습니다. 개발자로서 플러그인을 작성해 보려는 시도를 해보고 싶지만, 그 코드는 확장 가능해 보이지 않습니다. 플러그인에서 JavaScript를 연결하여 Ruby 프로세스를 보완하는 방법을 전혀 알지 못합니다… 혹은 word_watcher 코드의 작성 방식상 그것이 가능한지조차 모르겠습니다.
방대한 목록을 처리하는 부담을 덜어주기 위한 개선 아이디어를 하나 제안합니다.
각 유형의 감시 목록(watch list)마다 전체 목록을 처리하는 대신, 서로 다른 필터 블록들을 순환하는 방식을 고려해 보세요. 예를 들어, 가장 흔하고 악용되는 필터를 block1에, 나머지를 block2~n에 배치할 수 있습니다. 동기식 필터링 프로세스는 한 번에 하나의 블록만 처리하며, 최종 저장(Save) 작업 시에만 모든 필터에 대한 완전한 순환을 수행합니다. 블록은 기존 목록에서 작동하므로, 누군가가 변경을 가할 필요가 없습니다. 기존 목록은 1,000개 항목의 블록으로 나뉘어지므로, block1은 1~1000번 항목, block2는 1001~2000번 항목 등이 됩니다. 최적화를 원하는 관리자는 이제 더 높은 우선순위의 필터를 목록 앞쪽으로 이동시킬 수 있습니다.
이 방식의 장점 중 하나는 문제를 포착하기 위해 전체 목록을 처리할 필요가 없다는 것입니다. 가장 가능성이 높은 문제는 더 작은 블록에서 포착될 수 있으며, 동기식 프로세스는 더 작은 블록의 처리를 더 빨리 완료할 수 있습니다. 물론, 감시 텍스트가 첫 번째 블록에서 발견되지 않으면 다른 블록을 처리해야 합니다. 이는 덜 가능성이 있는 악용을 포착하기 위한 약간 더 많은 오버헤드를 의미합니다. 이는 선택적 튜닝의 문제가 됩니다 - 만약 누군가가 그렇게 하고 싶다면 말이죠.
여기서 추가 옵션으로, 관리자가 블록 크기를 선택할 수 있도록 할 수 있습니다. 블록 크기를 줄이면, 예를 들어 루프 사이클당 500개 항목으로 줄이면, 각 동기식 프로세스는 더 빨리 진행되지만 처리해야 할 블록 수는 더 많아질 수 있습니다. 이는 존재하는 악용의 종류와 목록이 얼마나 잘 우선순위가 정해져 있는지에 따라 달라집니다. 다시 말하지만, 이러한 종류의 튜닝은 선택적이며, 솔직히 말하면 많은 관리자가 이런 식으로 심도 있는 튜닝을 하리라고는 의심합니다.
참고로, 정밀 튜닝은 정량화 가능한 지표가 있음을 의미합니다: 감시 단어(watch-word) 처리에 얼마나 많은 시간을 소요하고 있으며, 실제로 얼마나 많은 문제를 포착하고 있는가? 이런 네디한 수준의 세부 사항은 나중에 개선 사항으로 남기거나, 정말로 원한다면 플러그인으로 구현하는 것이 적절할 것입니다.
궁극적으로 "감시 단어 블록 처리"가 여기서 설명된 대로 구현된다면, 목록의 항목 수는 2,000개를 초과하도록 확장될 수 있습니다. 네, 더 긴 목록을 읽고 분할하는 데 일부 오버헤드가 발생할 것입니다. 다시 한번 말하지만, 이 프로세스에 얼마나 많은 시간이 소비되는지에 대한 지표가 있다면, 관리자는 최적화를 위한 자체 임계값을 결정할 수 있습니다… 하지만 많은 사람들이 이 정도로 깊이 파고들지는 않을 것 같네요. 공개된 가이드라인은 다음과 같은 것이 될 수 있습니다: “감시 단어 블록 처리 없이 제한은 2,000개 감시 단어로 유지됩니다. 블록 처리를 사용할 경우 특정 제한은 없지만, 항목 수가 증가함에 따라 성능 저하가 두드러지게 증가하므로, 실용적인 제한은 약 5,000개로 추정됩니다.”
여기서 기쁨을 느낄 수 있을까요?