옷 사진 데이터 설계 방식에 대한 고민

이번 프로젝트에서 팀장을 맡게 되었다. 기획자가 따로 없어서 기획자의 역할을 같이 했기 때문에 '나날이' 프로젝트에서 가장 시간 투자를 많이하고 고민을 많이 한 부분이 기획과 백엔드 설계에 대한 방식이다.

 

그렇기 때문에 기획과 설계에 대한 내용을 정리하려고 한다.

 

 

옷 데이터를 저장하는 방법

 

처음에는 공공데이터를 활용하려고 했으나 생각보다 데이터가 좋지 않아보여서 무신사에서 크롤링을 해서 그 사진들로 추천하는 방식으로 변경하였다.

 

사진 데이터를 어떻게 저장할지에 대한 고민이 있었다.

 

Outfit 테이블에 넣을 사진 데이터 예시

 

Garment 테이블에 넣을 사진 데이터들 예시

옷 사진은 전체 코디 사진, 아이템별 사진으로 저장된다.

 

옷은 db에 저장해서 필요한 상황에 맞게 select 해오기로 했다. 옷을 저장할 때 저장되는 테이블에는 사진 url과 이름, id라는 기본적인 값과 온도, 강수량, 자외선 수치의 범위가 저장된다. 예를 들어 니트는 10도 ~ 20도의 온도,  1, 2단계의 자외선 수치, 모든 강수량으로 저장된다.

 

(Id, ImgName, ImgUrl, temp_from, temp_to, uv_from, uv_to, rain_from, rain_to)라는 테이블에 (Id, ImgName, ImgUrl, 10, 20, 1, 2, 0, 100)값이 저장되는 것이다.

 

 

이 부분에서 고민이 많았다. 처음에는 Weather 테이블을 별도로 만들어서 그 안에 enum 값으로 온도, 강수량, 자외선 수치를 넣는 방식을 생각했다. 이후에는 온도, 강수량, 자외선 수치를 각각 나눠서 테이블을 만드는 방식도 생각했었다.

 

하지만 다대다 매핑으로 굳이 매핑하지 않아도 어차피 옷들은 날씨에 따라 추천되는 방식으로만 사용되기 때문에 옷 테이블에 날씨에 대한 정보를 넣는 방향으로 설계를 바꿨다. 또한, 테이블이 분리되지 않았기 때문에 원하는 데이터를 select할 때의 이점도 존재했다.

 

 

 

원하는 옷 사진을 select 해서 넘겨주는 방법

 

Garment

@Query("select g from Garment g where g.temp_from < :temp and g.temp_to > :temp and g.uv_from < :uv " +
        "and g.uv_to > :uv and g.rain_from < :rain and g.rain_to > : rain and g.category = 'outer'")
List<Garment> findAllByCategoryIsOuter(@Param(value = "temp") Long temp, @Param(value = "uv") Long uv, @Param(value

outer를 예시로 들면 where 문 안에 온도, 자외선 수치, 강수량의 범위를 적어주는 쿼리를 날린다. 이렇게 하면 해당되는 날씨의 아우터 목록이 나오게 된다.

 

 

Outfit

@Query("select o from Outfit o where o.temp_from < :temp and o.temp_to > :temp and o.uv_from < :uv " +
        "and o.uv_to > :uv and o.rain_from < :rain and o.rain_to > : rain and o.style = :style")
List<Outfit> findAllOutifs(@Param(value = "temp") Long temp, @Param(value = "uv") Long uv,
                           @Param(value = "rain") Long rain, @Param(value = "style")Style style;);

Outfit에서도 범위를 지정하여서 select 해주면 된다. 여기에는 style이 추가로 들어간다. style이란 옷 스타일을 고를 수 있게 사용자에게 입력받는 것이다. 이후에 사진들 중에서 랜덤으로 하나를 추출해서 추천해주던가 최적화된 옷을 고르는 방법에 대한 고민은 추가로 해봐야겠다.

 

 

 

AI 개발자가 추천시스템 모델을 구현할 수 없는 상황이라 이러한 기능을 내가 구현하기로 했는데 어떻게 설계해야지 좋은 방법인지에 대한 고민이 계속 들었다. AI 로직을 사용하지 않고 기능을 구현하다보니 만족스럽지 못했지만 주어진 환경에서 그나마 최선의 선택을 해야하기에 많은 고민을 했었다.

 

계속 설계 방식을 바꿨는데, 좋아요 누른 사진을 마이페이지에 보여주고 상황에 따라 동적으로 사진들이 바뀌는 상황에서 고민 끝에 나쁘지 않은 설계를 하게 되어서 다행이라고 생각한다.

 

 

많은 선택지가 있는데 그 중에서 가장 최선이라고 생각되는 방식으로 설계하는 해야한다는 점과 설계 방식은 계속해서 바뀔 수 있고, 처음에 좋은 설계 방식을 정하는 것도 좋지만 많은 고민과 시도를 통해 완성해나가는 것도 좋다는 생각이 들었다.

 

 

이전의 프로젝트에서도 설계를 할 때 이렇게 많은 고민을 했던 적이 없었다. 내가 팀장이라는 직책을 맡아서 책임감도 느꼈고, 다른 개발자가 구현하지 못한 기능까지 커버해야 한다는 압박감 때문인 것 같다.

 

 

이번 경험을 통해 개발을 할 때 설계 방식에 대한 중요성을 깨닫게 되었다. 어떠한 방식으로 접근해서 설계를 할 것인지 충분히 고민해보는 경험은 좋은 개발자로의 성장으로 이루어질 것이다.