
게시판 본문을 데이터베이스에서 설계할 경우, 데이터 타입을 TEXT(64KB) 또는 MEDIUMTEXT로 설정하기도 한다.
UTF-8로 인코딩될 경우 1글자당 3바이트의 공간을 차지하게 되는데, TEXT는 약 2만 자 정도를 저장할 수 있다는 얘기다.
문득 궁금해졌다. 사람들이 자주 사용하는 Velog, 티스토리, 네이버 등은 이러한 글자 수 제한을 어떻게 설계하고 있을까?

TEXT보다 큰 MEDIUMTEXT 혹은 LONGTEXT로 설정하는 것등등, 여러 가지 접근 방법이 가능할 것으로 보인다.
실제로 어떻게 작동하는지 확인하고자, 각 블로그 서비스에 들어가 최대한 많은 글자를 입력해보았다. 비정상적인 방법을 사용한다.
Velog는 어떻게 구현되어 있을까? 무식한 방법으로 테스트 해보자!!! 😛😛😛
실제로 들어가 무수히 많은 글자를 작성해봤다. 복사-붙여넣기를 통해 글자 수를 무한정 늘리는 도중, 중간에 렉이 걸렸고 페이지에서 대기 요청이 발생했다. 결국 웹 브라우저가 과부화되어 연결이 끊겼다.
(일반적으로 이 정도로 많은 글자 수를 작성하는 일은 거의 없을 것이다...)

어찌 되었든, 클라이언트 측에서 글자 수를 제한하지는 않는다는 점은 확인할 수 있었다.
안타깝지만 서버 단에서 어떻게 처리되는지는, 제출 전에 브라우저가 끊겨 확인할 수 없었다.
네이버는 클라이언트 측에서 글자 수를 제한한다.
글자 수 최대를 넘었을 경우에 한 번 ,발행 버튼을 클릭했을 경우 한 번 더 글자 수 제한을 넘기는 것을 막는다.
클라이언트 단에서는 블로그의 작성 기준에 따라 선택적으로 글자 수 제한 UI를 적용할 수 있다.
하지만 JavaScript 우회를 통해 글자 수 제한을 무력화할 수 있기 때문에, 서버 측에서 반드시 유효성 검사를 진행해야 한다고 생각한다.
서버 측에서는 MEDIUMTEXT 등 넉넉한 데이터 타입으로 설계한 후, 설계 방침에 따라 글자 수 제한을 넘길 경우 에러 페이지를 반환하거나 예외처리를 진행하는 것이 필요하다.
요약하자면:
다시 생각해보니, 궁금할 필요도 없는 매우 간단한 문제였던 것 같다… 🙂
그래도 이런 식으로 어떤 문제에 대해 궁금증이 생기면 꼭 고민해보고 스스로 해결 방법을 찾아보는 습관을 들인다면
더 큰 문제를 마주할 때도 같은 접근 방법으로 해결해 나갈 수 있지 않을까 생각한다.