현대백화점 미래전략팀을 통해 개발자로의 인턴생활을 마치며

현대백화점 미래전략팀을 통해 개발자로의 인턴생활을 마치며

중개 플랫폼 like 헤이딜러 세탁특공대나 런드리고는 플랫폼이라기보다는 자사 서비스를 제공되는 형태입니다. 그렇기 때문에 수선을 요청하면 자사 담당자들이 검수하고 수선을 진행되는 형태입니다. 우리는 조금 차별점을 두고 싶었고 현실 성취한 헤이딜러의 모델을 벤치마킹하려고 했다. 대부분의 사람들은 수선을 자주이용하지는 않을 것입니다. 그렇기 때문에 수선에 대한 가격도 잘 모를 뿐더러 어떤게 이상적인 가격인지 모르는게 대부분입니다. 그래서 우리는 수선전에 사진을 통해 상품에 대한 견적을 받아볼 수 있도록 앱을 기획하고 개발했다.

그리고 이 상태에서 수선요청하기 아니면 수선거절하기를 통해 현실 수선프로세스를 진행할지에 대한 여부를 판가름했다. 만일 수선을 요청한다면 해당업체와의 거래가 체결되고 상품이 수거대기 상태로 변경되며 집앞에 놓아두면 수거를 진행합니다.

DDD를 반영하고 싶었다.

myOrder.changeOrderMemo

를 수행하도록 했다. 그런 식으로 함으로써 도메인이 무슨 기능을 수행해야하는지 알 수 있었으며 내부적으로 상태를 변경할때에 대한 제약사항을 코드안에 정의함으로써 불가능하다면 에러를 뱉도록 하던가 핸들링을 해줬습니다. 엄청나게 짜임새 있던 DDD는 아니었지만 도메인을 어떻게 이용하고 도메인 로직을 어떻게 작성해야하는지에 관련해서 고민해볼 수 있었어요. 현실 배송과 수거과 실현하는 주문과정을 처리하는건 쉽지는 않았습니다.

물론 현업에 계신분들이 보시면 비웃을정도로 이게 돌아가? 하겠지만돌아가는 가고 테스팅도 끝내긴했다. 견적서 작성, 수선업자가 수락거절, 배송, 실가격 측정, 수선, 배송, 완료와 같은 상태를 관리해야했다. 가장 아쉬운건 위의 상태의 과정을 State-Pattern을 사용해서 보다.

로그를 찍는 것

어드민외에도 개발자에게는 log만큼 중요한게 없을 것입니다. logback을 사용해서 로그를 기록했다. logback쓰는거 처음이었는데 Slf4j인터페이스의 구현체라서 이전에 찍었던 로그들을 별상이하게 수정할 필요도 없었습니다. 로그는 INFO, WARN, ERROR만 기록되게 했다. DEBUG레벨을 써보니까 정말 별의별개 다. 찍혀서 이거 찍히면 크기가 너무 커질거 같아서 뺏다. 이걸 한 폴더에서 보시면 가독성 너무 안좋게 계속 쌓이길래날짜별로 생성되게 했다 로그 단계별로 분리해서 찍히도록 했다.

사실 이렇게 로그를 기록해야하는 필요성이 있는 프로젝트가 처음이라 이렇게 하는방법이 맞는지도 잘 모르겠었다. 로그를 만드는방법만 나오지 로그방안을 어떻게 수립해야하는지는 구글뒤져봐도 분명히 찾기가 어려웠다. 그래서 내가 쓰고 내가 볼거니까 내가 필요한 로그들을 기록하게 했다.

JWT토큰과 ROLE에 따른 접근권한

캡스톤 프로젝트 복실이에서 JWT를 사용했던 경험을 살려 이번에도 JWT를 사용해서 로그인을 진행했습니다. 다만 카카오톡을 활용하지는 않고 우리 서비스상에서 정보들을 관리하도록 했다. 이전에 반쪽짜리 JWT라면 이번에는 90짜리 JWT였다고 생각합니다. 10을 제외한 이유는 Redis를 사용하여 블랙리스트로 토큰 만료 여부를 가리지 않았기 때문에 10을 제외했다.

스프링 시큐리티를 사용하였고 현실 유저 비밀번호가 DB에 저장될때도 암호화 했다.

그래서 아무리 어드민이라고 해도 디비만 보고 비밀번호 유추를 할 수 없도록 했다. 소비자 경험을 위해서 액세스토큰과 리프래쉬 토큰을 도입하여, 현실 액세스토큰이 만료되더라도 리프래쉬토큰으로 다시 토큰을 발급하여 사용할 수 있도록 했다. 당연하게도 리프래쉬 토큰은 유저DB에서 관리시키도록 했으며, 경우에 따라서 계속 업데이트 되도록 로직을 짰다.

사용자에게 알림이 날라오는것의 의미

유저 수선업자 유저

그리고 각 단계가 진행됨에 따라서 각 디바이스에 알림으로 아래와 같이 요청이 가야했다. 근데 테스트를 하던 중 유저 수선업자의 알림은 수선업자에게 잘 도착하지만, 유저 내가 이 이야기를 한 챕터로 뽑아 써내려가는 이유는 이곳에서 내 머릿속을 스쳤던 안일한 생각 때문입니다. 에이 공지 안가면 필요할때 어플 들어가서 확인하면 되지 라는 생각은 너무나도 안일하고 무책임했던 생각이었다.

얼핏ALLFIT은 앱에서 수선체결이 진행되고 배송이 시작되고 다시 유저에게 수선품목이 돌아오기까지의 과정은 앱에서 알림을 받아볼 수 없었습니다. 위에서 언급했던거와 같이 세특과 API연동이 이루어지지 않았고 그렇기 때문에 작업들이 실시간 동기화 되지 않았기 때문입니다.

자주 묻는 질문