실 상황을 본문에서 설명한 io bound task만 있는 서비스가 아니라 cpu bound task 서비스라고 가정한다면 어떨까요?
실제 환경의 서비스는 생각보다 복합적입니다. ui를 그리는데 필요한 데이터 서빙 api만 서버가 아닙니다
Validation 및 JSON serialization 작업이 메인 스레드에서 이루어지는 연산이다보니, 마냥 우습게 볼 일이 아닙니다. TS 백엔드 진영에선 가장 보편적으로 쓰이는게 class-validator/class-transformer 입니다. 그리고 이 친구의 초당 검증 가능량이 4MB 정도인데, 이 말은 메인 스레드에서 초당 4MB 이상 처리할 수 없다는 뜻이거든요.
DB 입출력이야 메인이 아닌 백그라운드 스레드에서 동작하는 것인지라, 백엔드 서버 기준 (TS 서버 기준) 동접에 크게 영향을 주지는 않습니다. 서비스 성격에 따라 한 번에 전송되는 DTO 양이 크면, 오히려 validation 느린게 더 무섭습니다 (실제로 건당 데이터가 큰 서비스를 만들었을 때, NestJS 동접이 한 자릿수이던 사례도 있ㅅ브니다).
작성자분은 병목 상황을 개선하는게 목표가 아니라 실 상황과 유사한 환경에선 유효성 검사 라이브러리의 성능차는 크게 유의미하지 않다를 주장하는게 아닐까 싶어요.