개발 진행 #5

JWT 토큰의 USER 추출 방식

처음에는 username으로 진행했다가 id 기반으로 변경하였다.

1. username은 추후 닉네임/아이디 변경 기능이 추가될 수 있기 때문이다. 즉, PK가 더 이상 아닐 수 있게 된다.
2. username은 VARCHAR -> 평균 바이트 수가 더 큰 반면, userId는 고정 길이 4비트이므로 인덱스가 항상 더 빠르다. 즉, 검색 속도가 훨씬 빠르다.
3. user_id를 통해 그 회원의 옷, 프리셋, 옷 계획등을 전부 join을 통해서 찾아야 하는데, 숫자 조인이 문자열 조인보다 훨씬 안정적이고 빠르다.

퀵등록 기능에서 이미지 처리 방식을 어떻게 설계할 것인가.

해당 문제를 해결하기 위해 다음과 방식을 시도했다.

1. 색상별 이모지 파일을 각각 등록

   단순히 색깔을 변경한 이미지를 준비하면 된다. 티셔츠가 있다면 빨간 티셔츠, 파란 티셔츠… 이렇게 모든 색깔 옷 이미지를 준비하는 것이다. 문제는 의상 종류가 많아지고 색이 추가될수록 만들어야 할 이미지도 많아진다는 점, 의상이 추가되거나 색이 추가될수록 이미지를 계속 만들어서 넣어줘야 하기 때문에 유지보수가 번거롭다는 점이 있다.

   1. 장점 : 구현이 매우 단순하다.
   2. 단점 : 이미지 리소스 급증으로 앱 용량 최적화 문제가 발생할 수 있다. 추가 등록에 대한 유지 보수가 필요하다.

2. CSS mask-Image 활용

의상의 각 종류의 이미지는 1장만 준비한 채 CSS로 색상 변경을 구현한다. 서버로 전송받을 때는 컬러 코드의 내용을 전송해 이후 랜더링할 때 불러온다. Background층과 Mask층으로 분리된다. Background층은 유저가 선택한 색상이 칠해지는 바닥이고, Mask 층은 제공해준 이미지처럼 의상의 형태를 가진 마스크 형태로 제작된다.

이미지 하나로 무한한 색상 표현이 가능하고 옷 추가 시에도 이미지 하나만 추가하면 되기 때문에 유지보수가 간편하다. 하지만 프론트에서 마스크 형태 제작, 즉 레이어 분리 작업이 필요하다.

그래서 프로젝트에서 선정된 최종적인 해결방안은

기본 이모지 + 동적 색상 적용 방식을 선택하였다. 색상 팔레트가 확장될 가능성이 크기 때문에 초기 레이어 분리 작업 시간이 조금 더 많이 들더라도 장기적인 유지보수와 앱 용량 관리를 위해 동적 색상 적용 방식을 선택하였다.

서버 전송 방식

서버가 받을 때 이미지 파일을 생성해서 서버에 올리는 방식과 색상 코드와 서브 카테고리를 텍스트 데이터로 받는 방식이 있었다.

1. 이미지 파일 생성

프론트엔드에서 색을 입힌 뒤 이미지 파일로 변환해서 서버로 전송하는 방법이다. 서버나 다른 플랫폼에서 이 이미지를 볼 때 별도의 처리 없이 그냥 '그림'으로 바로 보여줄 수 있다. 또한 백엔드 측에서는 기존 API를 수정할 필요가 거의 없다. 하지만 유저가 옷을 등록할 때마다 이미지 파일이 서버에 쌓여서 비용이 발생하며, 이미지 파일로 변환하는 방식을 추가로 학습해야 한다.

1. 텍스트 데이터로 보내는 방식

저장할 때 프론트엔드에서는 서버로 { "category": "t-shirt", "color": "#FF0000", "isDefaultImage": true ... } 처럼 텍스트 데이터만 보낸다. 이렇게 하면 서버 저장 공간을 거의 차지하지 않게 된다. 이미지 파일 대비 수천 배 절약 효과를 불러올 수 있으며 네트워크 전송 속도가 빨라 앱이 가볍게 느껴진다. 또한 나중에 유저가 의상 데이터를 수정(예를 들어 색)한다고 할 때 데이터 한 줄만 수정하면 돼서 관리가 편한다. 다만 백엔드에서 API를 수정하거나 퀵등록 전용 API를 필요로 한다.

구분	이미지 파일 전송 방식	텍스트 데이터 전송 방식
저장 용량	파일 개수만큼 증가	수천 배 이상 절약 효과
앱 성능	이미지 로딩에 부담이 있음	로딩 속도가 매우 빠름
유지보수	이미지를 다시 그려서 재업로드	색상 코드 수정만으로 즉시 반영

따라서 백엔드에서 기존 API를 추가/수정 하기로 했다.

• image 필드를 Optional로 변경하고
• 대신 어떤 아이콘인지 식별할 수 있는 subCategory (예: 't_shirt', 'coat') 필드를 추가로 받는다.
• 서버에서는 image가 없으면 subCategory 값을 확인해 기본 이미지 경로를 imageUrl에 넣어 저장.

이후 방식 1로 채택되며 imageUrl이 빈 값("")이거나 null이면 퀵등록 정보(subCategory, colorCode)를 사용하고, 사진이나 카메라로 등록일 때는 imageUrl을 채워서 보내도록 api를 수정할 계획이다.

프로젝트 초기 단계에서는 다음과 같은 기술적 검토와 협업 프로세스가 선행되어야 한다고 느꼈다.

1. 유연한 데이터 설계 : 이미지 파일 자체를 데이터로 보지 않고, '이미지 틀(Category) + 속성(Color)'과 같이 정보를 분리하여 관리하는 설계 역량이 필요하다.
2. FE, BE간 밀접한 프로토콜 정의 : 새로운 기능을 도입할 때 기존 API를 재활용할지, 전용 API를 신설할지에 대해 개발 초기 단계에서 합의가 이루어져야 구현 단계의 충돌을 막을 수 있다.