현재 개발중인 프로젝트
현재 개발중인 프로젝트, FSHS는 개인용 클라우드 서비스입니다.
이 프로젝트에서는 사용자가 가진 파일들을 표시할 때 백엔드에서 폴더와 파일의 정보를 가지고 와서 표시하고 있습니다.
문제상황
이 프로젝트에서는 /api/v1/files 라는 API를 이용해서 사용자가 가진 모든 파일과 폴더의 정보를 가지고 올 수 있었습니다.
{
"id": 0,
"originalFileName": "string",
"fileName": "string",
"fileSize": 0,
"fileExtension": "string",
"uploadDate": "2024-11-12T01:36:38.687Z",
"updateDate": "2024-11-12T01:36:38.687Z",
"url": "string",
"hasThumbnail": true,
"deleteDate": "2024-11-12T01:36:38.687Z",
"children": [
{
"id": 0,
"originalFileName": "string",
"fileName": "string",
"fileSize": 0,
"fileExtension": "string",
"uploadDate": "2024-11-12T01:36:38.687Z",
"updateDate": "2024-11-12T01:36:38.687Z",
"url": "string",
"hasThumbnail": true,
"deleteDate": "2024-11-12T01:36:38.687Z",
"children": [],
"directory": true,
"streaming": true,
"secrete": true,
"streamingMusic": true,
"streamingVideo": true,
"favorite": true,
"shared": true,
"deleted": true
}
],
"directory": true,
"streaming": true,
"secrete": true,
"streamingMusic": true,
"streamingVideo": true,
"favorite": true,
"shared": true,
"deleted": true
}위와 같이 폴더가 가진 정보와 함께 폴더 내부에 있는 파일의 정보들도 응답하도록 되어 있었습니다.
하지만 위와 같은 방식은 특정 사용자의 폴더와 파일의 총 개수가 2800개가 넘어가면서 문제가 발생했습니다.
/api/v1/files API를 호출하니 2800개의 정보가 Http 응답 하나에 너무 많은 정보가 들어가, 응답의 크기가 매우 커졌습니다. 때문에 응답시간이 매우 길어졌습니다.
프론트의 경우
위와 같이 2800개 정도의 폴더와 파일의 정보를 담은 응답의 총 용량은 1.4MB까지 늘어났고 응답 시간 또한 외부 접속시 3초, 로컬 환경에서 조차도 1.25초나 걸리게 되면서 로딩시간이 매우 길어지게 되었습니다.
또한 프론트엔드에서 다른 폴더로 넘어갈 때 마다 /api/v1/files API를 이용해 파일을 조회 했기 때문에 다른 폴더로 넘어갈 때 마다 3초 정도의 로딩이 발생하였습니다.
실제로 서비스를 사용해 보면서 다른 폴더로 넘어갈 때 마다 3초씩 로딩이 생기는 부분에서 상당한 불편함을 느꼈습니다.
백엔드의 경우
백엔드에서는 /api/v1/files API의 응답을 다른 API에서 포함하고 있는 경우가 있었습니다.
특히 로그인시 사용되는 /api/v1/auth/sign-in API의 경우 사용자의 JWT토큰 정보와 사용자의 모든 파일과 폴더 정보를 포함하고 있었기에 상당한 응답 시간을 가지고 있었습니다.
이런 API들을 swagger에서 요청할 경우 swagger와 브라우저가 매우 느려지는 문제가 발생하여 API 테스트가 불가능할 정도였습니다.
해결
모든 문제의 원인인 /api/v1/files API를 대신하여 다른 API를 사용하도록 하였습니다.
또한 다른 API들에서 /api/v1/files API와 같이 모든 폴더와 파일의 정보를 리턴하는 응답을 전부 수정하기로 하였습니다.
이 경우, 프론트엔드에서 폴더와 파일의 정보를 가지고 오게할 새로운 방법을 모색해야 했습니다.
그래서 매번 폴더에 들어갈 때 마다 전체 정보를 요청하지 않고 해당 폴더의 정보와 그 폴더에 포함된 파일과 폴더들만 요청하도록 전체적인 구조를 변경하였습니다.
그래서 기존에 존재하던 파일이나 폴더 하나의 정보를 응답하는 /api/v1/files/{id} API를 이용하기로 하였습니다.
기존 API에서는 자식 폴더와 파일들은 응답에 포함되지 않았으나 DTO수정으로 간단하게 자식 폴더와 파일을 응답에 추가할 수 있었다.
결과
이렇게 각 API들을 수정하니 매번 폴더에 들어갈 때 3초 정도 걸리던 로딩이 사라져서 사용자 경험이 매우 향상 되었습니다.
페이지에 들어갈 때마다 전체 파일과 폴더를 조회하던 것에서 특정 폴더의 정보만 조회하게 되어 페이지 로딩시간의 단위가 초에서 밀리초까지 줄어들었습니다.
회고
이 모든 문제의 발단은 프로젝트 개발하다가 처음 정한 구조를 까먹어서 발생한 문제였습니다.
프론트엔트 개발시에 /api/v1/files API 응답을 프론트엔드 전역에서 사용해서 API요청을 최소화 하려는 형태로 개발하려고 정해놓고 json형태의 정보를 전역에서 사용하는 법을 몰라서(...) 아무것도 시작하지 못한 채로 백엔드 개발에 치중했었습니다.
그 후, 시간이 흘러 프론트 개발을 시작하게 되었지만 처음에 정한 프로젝트 구조를 구체적으로 적어 놓지 않아서 백엔드 API 구성이 왜 이런지, 왜 이런 API가 필요한지 의문을 가지며 프론트엔드 개발에 착수했었습니다.
그 결과 한번만 쓰기로한 API를 남발하게 되면서 서버와 DB, 클라이언트 모두에게 큰 부담을 주는 결과를 초래하게 되었습니다.
이런 경험을 바탕으로 이제부터라도 프로젝트의 구조와 구성을 상세히 문서화하고 프론트와 협업시 제공하는 API문서에도 이 API가 어떤 응답을 주는지만 작성하는 것이 아닌 프론트엔드에서 어떤 부분에 사용되는지 또한 작성해야 하겠다고 느꼈습니다.
또한, 이런 경험들을 프론트엔드 개발을 하면서 겪었기 때문에 프론트를 경험하고 프론트엔드의 입장을 이해하면 더 나은 협업을 할 수 있겠다고 느꼈습니다.
결론
- 페이지 로딩시간이 길어짐
- 특정 API가 문제였음
- 기존 API를 수정하며 문제 해결
- 회고 결과 처음에 문서화를 제대로 하지 않아서 발생한 문제임
- 문서화를 잘 하자
