입력을 어떻게 받나

요청 수를 20배로 만드는 것은 타이핑입니다. 그런데 한국어에서는 그 배수가 더 큽니다. 이 절은 입력 쪽에서 할 수 있는 일입니다.

조합 중 상태가 다 요청이 된다

한글은 자모를 조합해 글자를 만듭니다. 삼성을 입력하는 동안 화면에는 여러 중간 상태가 지나갑니다. 그 상태마다 요청을 보내면 한 글자에 요청이 두세 번 생깁니다.

그리고 그 중간 상태의 답은 대개 버려집니다. 사 는 삼 과 다른 글자여서 답이 완전히 다르고, 사용자는 그 답을 보려고 입력한 것이 아닙니다.

완성된 글자만 보내면 버려질 요청이 사라집니다. 이것은 서버가 아니라 입력 쪽에서 하는 결정입니다.

요청을 줄이는 것은 클라이언트의 일이다

서버는 들어온 요청을 거절할 수 없습니다. 요청 수를 줄이는 장치는 전부 클라이언트에 있습니다.

이 네 가지로 요청이 크게 줄어듭니다. 서버 용량 산정보다 이쪽이 값싼 개선입니다.

주의할 것은 기다리는 시간입니다. 너무 길게 기다리면 타이핑을 멈춘 뒤에도 제안이 늦게 뜨고, 그러면 100ms 목표를 지켜도 사용자에게는 느립니다.

늦게 온 답이 화면을 덮는 문제

요청을 여러 개 보내면 답이 보낸 순서대로 오지 않습니다.

삼 을 물어본 요청이 늦게 도착
삼성 을 물어본 요청이 먼저 도착

이때 늦게 온 삼 의 답이 화면을 덮으면 사용자가 삼성을 입력했는데 삼 의 제안이 보입니다.

그래서 답에 어느 입력에 대한 것인지를 담고, 지금 입력과 다르면 버립니다. 이것은 서버가 해결할 수 없는 문제입니다. 순서 보장을 서버에 요구하면 요청을 하나씩 보내야 하고, 그러면 느려집니다.

자모로 찾는 것은 다른 결정이다

ㅅㅅ 으로 삼성을 찾으려는 사람이 있습니다. 이것을 지원하려면 검색어마다 자모 형태를 함께 색인해야 합니다.

둘은 반대 방향처럼 보이지만 충돌하지 않습니다. 앞은 조합 중 상태를 보내지 않는 것이고, 뒤는 사용자가 의도적으로 자모만 입력한 경우를 다루는 것입니다. 다만 뒤쪽은 저장이 늘어나므로 요구사항에 있는지 확인하고 넣습니다.