클라이언트와 백엔드 사이에 파일을 주고 받는 것은 쉬워보이지만, '잘' 하는 것은 매우 까다롭다. 파일을 받는 것도 클라이언트, 보여주는 것도 클라이언트인데 굳이 백엔드에서 파일을 처리해야 하는 이유는 무엇인지 고민해 보았다.

파일 처리 시 클라이언트와 백엔드 장단점 비교

🤔 처리 능력

사용자의 장치 성능에 따라 다르겠지만 일반적인 상황에서 서버에 요청을 보내 처리하는 것보다 사용자의 컴퓨터로 처리하는 게 더 빠르다고 한다. 다만 특정 작업은 모바일에서는 아예 처리가 불가능한 경우가 발생할 수도 있고, 사용자의 컴퓨팅 성능은 천차만별이다. 부담이 되는 작업을 사용자에게 전가하고 UX 예측을 할 수 없는 것은 매우 불안한 선택이다. 예측할 수 없는 부분에 기대어 프로그래밍을 할 순 없다.

백엔드 역시 서버의 사양과 현재 부하 상태에 따라 속도가 달라질 수 있다. 그러나 개발자가 직접 관리하고 확인할 수 있고, 필요하면 서버 성능을 높여서라도 해결할 수 있다.

🤔 데이터 저장 주체

만약 S3에 이미지를 저장한다고 했을 때 사실 이미지 파일을 백에 전송해 S3에 저장하는 것보다 바로 클라이언트에서 S3에 저장하여 저장소 위치를 백에 보내는 방법이 파일 전송을 1단계 줄일 수 있다. 파일 전송 API가 줄어드니 클라이언트가 이미지를 저장할 때도 자연스럽게 레이턴시가 줄어들 것이다.

파일 처리를 백엔드에서 한다고 가정하면, 백엔드는 클라이언트에서 저장한 파일을 다시 가져와서 최적화를 한 이후 다시 저장해야 한다. 위에서 내린 결론상 이미지 리사이징 등의 작업은 백엔드에서 하는 것이 옳은데, 최적화를 한다는 가정하에는 오히려 파일 전송이 1회 증가할 수 있다. 다만 이런 방식의 작업 방법은 사용자가 파일이 최적화 과정을 거치는 동안 기다리지 않아도 된다.

🤔 비즈니스 로직

이런 상황이 현실에서 발생할 가능성은 없겠지만, 만약 이미지 파일을 업로드하는데 동시 사용자가 1억 명이라고 한다면 다시 생각할 필요가 있다. 서버의 부하가 엄청난 상황에서 파일 작업까지 하려면 서버는 당연히 더 힘들 것이다. 때문에 파일 처리를 클라이언트에서 한다면 이런 부하를 줄일 수 있다.

다만 이런 경우가 실제로 발생할 가능성은 거의 없을 것이고, 발생한다고 하더라도 최근에는 파일을 업로드라고, 처리하는 서버를 따로 분리하여 부하를 분산시키는 방향으로 작업을 하기 때문에 대부분 백엔드에서 파일을 다룬다.

나의 생각

이 외에도 어떤 기술 스택을 사용하는지에 따라 처리 속도나 효율이 달라질 수 있을 것이다. 이미지 처리가 많지 않고, 간단하다면 클라이언트에서 다 처리해도 되겠지만 개인적으로 파일을 포함한 모든 데이터는 백엔드에서 관리하는 것이 데이터 관리나 개발자 간 역할 구분에 좋다고 생각한다.