Storage

상품을 설계할 때는 단순히 현재 요구사항만 보고 개발을 시작하면 안 된다. 

처음에는 비슷해 보이는 서비스라도 비즈니스 모델(B2B, B2C, B2B2C, B2B2B)에 따라 앞으로의 확장 방향과 필요한 기능이 완전히 달라진다. 
설계 단계에서 이러한 특성을 고려하지 않으면 서비스가 성장할수록 구조적인 한계에 부딪히게 된다. 

개발은 어떻게든 구현할 수 있다. 하지만 잘못된 방향으로 설계된 구조 위에 기능을 계속 쌓아 올리다 보면 어느 순간 유지보수와 확장이 어려워지고, 결국 큰 비용을 들여 재설계를 해야 하는 상황이 발생한다. 
특히 기획 단계에서 비즈니스 모델에 대한 고려가 부족하다면 개발자가 먼저 문제를 인지하고 의견을 제시해야 한다고 생각한다. 

결국 만들어진 서비스의 기술적 책임은 개발자가 지게 되기 때문이다.

1. 왜 비즈니스 모델을 먼저 이해해야 할까?

서비스는 처음에는 단순하게 시작한다.
하지만 시간이 지나면서 아래에 정리한 요구사항이 추가된다. 
- 신규 고객 유입 사업 
- 확장 판매 채널 확대 
- 입점 업체 증가 
- 기업 고객 유치 
- 가격 정책 다양화 
- ...

이때 처음부터 비즈니스 모델을 고려하여 설계했다면 자연스럽게 확장할 수 있지만, 그렇지 않다면 기존 구조가 발목을 잡게 된다. 
따라서 상품 설계 시 가장 먼저 확인해야 하는 것은 다음과 같다. 

이 서비스는 B2B인가? B2C인가? B2B2C인가? 앞으로 어떤 방향으로 확장될 가능성이 있는가?

2. 기업의 특징 및 상품의 설계 고려방향

*B2B ( Business To Business )

기업이 기업에게 상품 또는 서비스를 판매하는 형태
( ERP, SaaS, AWS 등 솔루션회사)

특징

- 구매 금액이 크다. 
- 구매 결정권자가 여러 명일 수 있다. 
- 계약 기반으로 거래되는 경우가 많다. 
- 고객사별 가격 정책이 존재할 수 있다. 
- 재구매율이 높다. 
- 업무 효율성이 중요하다.

B2B 상품 설계시 고려사항

- 회원은 고객사(기업) 단위관리 
  ㄴ 기업과의 계약이기 때문에 기업기준으로 기업의 고객을 관리할수 있게 설계 고려 필요
  ㄴ 기업을 기준으로 두면 기업의 자회사? 이런 부분들도 어떻게 관리할지 고려해볼 수 있음
  ㄴ 기업단위로 정리하고, 기업의 회원을 등록하거나 회원단위로 가입하고 기업을 연결할 수 있음
- 견적(계약) 관리
  ㄴ 상품단계에서는 견적에서는 가격부분, 커스텀 필요한 부분을 고려해야함
  ㄴ 서비스를 파는지, 물건을 파는지, 물건을 만들어서 (발주) 파는지에 따라 상품 방향성이 다름
- 고객사별 가격 관리
  ㄴ 고객사별 할인방향에 따라 상품 단위로 할인할지, 견적단위로 할인할지, 특정상품은 견적할인에서도 제외처리 필요한지
- 특정상품을 제작(발주)까지 고려하는 경우 디테일 부분 고려
  ㄴ 마진율, 공급가에 관한 부분 고려 필요
  ㄴ 시안 및 디자인에디터라던지 상품을 디자인하는 시스템 고려 
  ㄴ 옵션 구조 단순화 필요 (뒤에 로직에서 복잡성 처리)
- 가격이 명확하지 않은 상품들에 대한 고려
  ㄴ 수량별로 가격이 다른 경우, 옵션별로 가격이 다른 경우
  ㄴ 가격이 싯가인 경우
- 그 외 내부 비즈니스로직에 특화되어 고려할수있다.

*B2C ( Business To Consumer )

기업이 일반 소비자에게 직접 판매하는 형태
( 쿠팡, 올리브영, 넷블릭스, 무신사 )

특징

- 사용자 수가 많다.
- 구매 금액이 상대적으로 작다. 
- 구매 결정이 빠르다. 
- 사용자 경험(UX)이 중요하다. 
- 마케팅의 영향이 크다.

B2C 상품 설계시 고려사항

- 장바구니 관리
  ㄴ 장바구니 내에서 상품 중복 허용할건지
- 상품옵션
  ㄴ 플랫폼에 성격에 맞는 상품들을 생성해줄 때 전부다 수용가능한지
  ㄴ 필수옵션과 부가적인옵션, 옵션 복잡도
- 재고를 고려할건지
- 상품의 주체 (입점제작사)
  ㄴ 상품의 입점제작사 관리 매핑 고민
- 입점제작사와 브랜드를 어떻게 관리하고 표기할것인지
- 가격정책 
  ㄴ 가격의 변동 관리
  ㄴ 이벤트성 할인 관리
- 프로모션, 기획전 관련 상품 관리 
- 검색 및 추천관련 고려
  ㄴ 상품을 원활하게 검색할수있게
  ㄴ 사용자의 추천을 가능하게 할수있는 정보
- 할인정책
  ㄴ 상품의 할인(멤버십, 쿠폰 등 ...)이 적용되었을때 할인 적용 및 할인금액 여부
  ㄴ 특정상품 카테고리 할인제외라던가 생각해볼수있음
- 정산로직
- 그 외 내부 비즈니스로직에 특화되어 고려할수있다.

*B2B2C ( Business To Business To Consumer )

기업이 다른 기업을 통해 최종 소비자에게 상품 또는 서비스를 제공하는 형태.
플랫폼 비즈니스 모델 ( 입점업체 -> 플랫폼 -> 소비자 )
( 배달의민족, 무신사, 오늘의집 )

특징

- B2B의 특징과 B2C의 특징을 모두 고려해야한다.

B2B2C 상품 설계시 고려사항

- 위에 정리한 B2B와 B2C를 모두 고려해야함
- 입점제작사 관리
  ㄴ 입점제작사 수수료율 기준 (파트너? 상품?)
- 내부 상품 및 발주 관리
  ㄴ 상품의 옵션수준 단순화
  ㄴ 디자인에디터나 시안 같은 디자인 필요한 경우
- 그 외 내부 비즈니스로직에 특화되어 고려할수있다.

*B2B2B ( Business To Business To Business )

기업이 다른 기업을 통해 또 다른 기업에게 상품 또는 서비스를 제공하는 형태
( 제조사/공급사 -> 플랫폼 -> 기업고객 )
( AWS -> 파트너사 -> 기업고객 )

특징

- B2B의 특징에 더 고도화된 부분을 고려해야함 

B2B2B 상품 설계시 고려사항

- 위에 정리한 B2B 고려해야함
- 내부 상품 및 발주 관리
  ㄴ 상품의 옵션수준 단순화
  ㄴ 디자인에디터나 시안 같은 디자인 필요한 경우
- 그 외 내부 비즈니스로직에 특화되어 고려할수있다.

1. 상품 정보와 관리 정보는 분리

상품에는 상품명, 상품코드, 카테고리와 같이 서비스 운영에 필요한 핵심 정보가 존재한다.
반면 관리자 메모, 운영 정책, 내부 관리용 데이터와 같은 정보는 상품 자체와는 성격이 다르다.
이러한 데이터를 모두 상품 테이블에 저장하게 되면 운영 요구사항이 추가될 때마다 상품 구조가 복잡해질 수 있다.
따라서 상품의 핵심 정보와 관리 목적의 정보는 별도의 매핑 테이블로 분리하는 것이 좋다.

2. 가격은 반드시 이력을 남길 수 있어야 한다.

가격은 상품 정보 중 가장 자주 변경되는 데이터다. 
이벤트 할인, 원가 변동, 프로모션 등 다양한 이유로 가격이 변경될 수 있기 때문에 현재 가격만 저장하는 방식은 한계가 있다. 
따라서 현재 가격과 가격 변경 이력을 분리하여 관리하는 것이 좋다. 
특히 운영 중에는 이런 요구사항이 자주 발생한다.

아래 상황을 고려하면 가격 이력 테이블은 사실상 필수에 가깝다.
- 지난달 가격이 얼마였는지 확인하고 싶다.
- 특정 기간 동안의 가격 변동 내역을 보고 싶다.
- 할인 적용 전 가격을 조회하고 싶다.

3. 상품 노출 정책은 별도로 관리하자

상품이 생성되었다고 바로 사용자에게 노출되는 것은 아니다. 
실제 서비스에서는 관리자(Admin)에서 상품을 생성한 후 Mall에 노출되기까지 여러 정책이 존재한다. 
가장 기본적으로는 상품 노출 여부와 상품 상태를 분리하는 것을 추천한다.

상품 노출 여부 
- 전시
- 비전시

상품 상태
- 판매중
- 판매중지
- 숨김
- 품절

*아래는 예시이고 운영정책에 따라 정해서 진행하면 좋음

리스트에는 노출하지 않지만 URL을 알고 있는 사용자만 접근할 수 있기 때문에 다음과 같은 상황에 활용할 수 있다. 
- 이벤트 상품
- 사전 공개 상품
- 테스트 상품

4. 정렬 정책은 초기에 고민하는 것이 좋다.

상품 서비스에서는 정렬 기능 요청이 생각보다 많다. 
대표적으로 다음과 같은 정렬이 존재한다. 
- 최신순 가격
- 오름차순 가격
- 내림차순
- 추천순
- 커스텀 정렬

특히 운영자는 특정 상품을 상단에 노출하고 싶어하는 경우가 많다. 
이를 위해 별도의 정렬값(sort order)을 두는 것이 좋다.

관련 적용하면 좋은 알고리즘
https://velog.io/@ksi05503/%EB%8B%B9%EC%8B%A0%EC%9D%98-%EC%96%B4%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98-%EB%A1%9C%EC%A7%81%EC%97%90-LexoRank-%EB%A5%BC-%EC%A0%81%EC%9A%A9%ED%95%B4%EC%95%BC%ED%95%98%EB%8A%94-%EC%9D%B4%EC%9C%A0

5. 검색 편의성을 위한 검색 키워드 컬럼을 고려한다.

개발 초기에는 검색엔진(엘라스틱서치, 오픈서치) 도입이 당장 필요하지는않다.
필요에따라 도입을 고려할수있는데 그전에는 like 검색을 통해서 상품 검색을 구성한다.
내부 검색 로직을 커스텀해서  어느정도 고도화를 할수있지만
상품명 및 일부 컬럼만을 가지고는 검색정확도를 올리기가 어렵다. 

사용자는 항상 정확한 상품명을 알고 검색하지 않는다.
예를 들어 상품명이 아래와 같다고 가정해보자.
"나이키 에어포스 1 로우 화이트" 하지만 실제 검색은 다음과 같이 이루어질 수 있다.
에어포스 AF1 흰운동화 나이키 신발 이처럼 상품명만으로는 검색 정확도를 높이는 데 한계가 있다.
따라서 검색 보조 키워드를 등록할 수 있는 기능을 제공하는 것이 좋다.

6. 상품은 최대한 독립적인 단위로 설계하자 

초기 설계 단계에서는 특정 비즈니스 요구사항에 맞춰 상품 구조를 복잡하게 만드는 경우가 있다. 
예를 들어 키트 상품이나 세트 상품을 상품 구조 자체에 녹여 설계하는 경우가 있다. 
하지만 이런 방식은 시간이 지나면서 확장에 제약이 될 수 있다. 
설계가 아니여도 운영단계에서도 세트상품을 상품에 녹여 상품을 구성할수 있는데 이부분도 주의하면 좋다.
상품은 최대한 독립적으로 관리하고, 여러 상품을 묶어 판매해야 한다면 별도의 묶음 상품 기능으로 해결하는 것이 좋다.

7. 상품 ID와 상품 코드는 구분하자 

상품 설계 시 자주 놓치는 부분 중 하나가 상품 ID와 상품 코드의 역할 구분이다. 
상품 ID는 시스템 내부 식별자다. 
상품 코드는 운영자와 외부 시스템이 사용하는 비즈니스 식별자다. 
이 둘의 역할을 분리해두면 상품 개편 시 유연하게 대응할 수 있다. 
예를 들어 기존 상품을 수정하는 대신 새로운 상품을 생성하고 상품 코드만 변경하는 방식도 가능해진다.

8. 상품(Product)과 옵션(Option)은 분리해서 관리하자 

상품을 설계하다 보면 상품 자체와 실제 판매 단위를 구분해야 하는 경우가 많다. 

예를 들어 아래와 같은 상품이 있다고 가정해보자.
사용자가 실제 구매하는 것은 상품 자체가 아니라 옵션이 포함된 특정 상품이다.

상품명 : 반팔 티셔츠

색상 : 블랙
사이즈 : M

색상 : 블랙
사이즈 : L

색상 : 화이트
사이즈 : M

만약 옵션 정보를 상품에 직접 저장하게 되면 상품 구조가 복잡해지고 확장에 제약이 발생한다. 
따라서 상품(Product)과 옵션(Option)은 분리하여 관리하는 것이 좋다.

갤럭시에서 아이폰으로 넘어가면서
(삼성페이의...소듕함ㅠ)

들고다니지도 않던 카드지갑의 
필요성을 간절히 느끼고 있던 순간!

어떤걸로 살까 고민끝에
'메종마르지엘라' 키링 카드지갑의 빈티지한
멋스러운 매력에 빠져 버렸어요+_+

MAISON MARGIELA
21 S/S 버전으로
품명 S55UI0302

얼마나 애타게 기다렸는지
아시다시피 매장이 몇군데 없어요

백화점에 전화를 걸어봤지만
계속된 재고 부족으로 실물을 못보고
구매한 상품!

마르지엘라의 시그니처인
저 넘버링

너무나 감성적이며
저 하얀 스티치를 밥풀이라고 많이들 부르시죠ㅎ_ㅎ

저는 디코드 프리오더로
298,000원에 구매 완료

사실 원했던건
사진속 실버색의 체인을 생각했고
저 사진을 보고 구매 한거 였는데

이미 출발 후에 문자로 

21SS 시즌에 검은색 체인으로 변경 되었다고...
프리오더 제작 과정에서 발생 될수 있는 사항이라
문자로 안내를 주셨다네요^^;;

프리오더란!!!!!!!!!!!

일반적인 판매와는 다른
브랜드의 컬렉션 상품을 한 시즌 빠르게
선공개 하여 합리적인 가격으로 
주문받아 정식 발매기간에 배송진행하는 서비스로

가격적으로 매우 좋은 가격으로 올라와서
인기상품들은 빨리 빠지는 경우도 많죠
(오랜 기다림은 필수 입니다만....)

실버체인이 아니라
아쉬움은 있지만

밥 풀 감 성 을
원했던거라 만족하며 사용하고 있어요!

한땀 한땀 바느질 퀄리티는
좋네요

실밥이 튀어나오지도 않고
아주 깔끔함은 인.정 

넉넉하게 넣을수 있는
6개의 수납공간과
전체적인 사이즈가 너무나 완벽 그 자체!
a n d
한 손안에 착 감기는
그립감

후기 보면 
마르지엘라 가죽 퀄리티가
안 좋다는 분들도 많은데

저는
가볍고 부드러워서
기분좋게 쓰고 있어요!

너무나 앙증 맞은 사이쥬

아쉬운 검정무광의 키링ㅋㅋㅋㅋㅋㅋㅋ
나름 무광의 빈티지함이
밥풀감성과 어울려서

실물은 또 
나쁘지 않아요>_<

이렇게 감싸는 느낌
너무 굿!

사용하다 보면 밥풀에 때가 많이 탈수 있다는데
조심하며 써야 겠어요

역시
♥메종마르지엘라 갬성♥

남녀 누구나 사용해도 무난한
키링카드지갑!

추천 추천 입니다

저번주에 용산 노보텔 앰배서더 호텔로
기분 좋은 호캉스를 다녀왔어요+_+

서울 드래곤시티는 4가지 컨셉의 호텔이 있는데
그랜드 머큐어 / 노보텔 스위트 
노보텔 스위트 / 이비스 스타일스 
총 4가지로 되어있어요.

용산역 3번출구랑 연결
가는내내 표지판 안내가 잘 되어
여행오신분들, 어른분들 등 등 헤매지 않게
잘 찾으실 수 있을겁니다!

1층 로비에서 친절하신 직원분께서
노보텔 OR 노보텔스위트 예약이신지 묻더라구요!
우리는 노보텔로 예약하여 바로 1층 로비에서
체크인 하였습니다.

작년에는 노보텔 스위트 앰배서더로
호캉스 간 적이 있었는데
노보텔 앰배서더도 역시 만족 스럽네요

짜 잔
입구를 지나 딱 보이는 정면샷 입니다
(뒤로는 세면대와 샤워실이 있구요)

생각보다 넓고 침대가 커서 너무 맘에 드네요ㅇ_ㅇ

정말 침대가 세상 잊혀지질 않네요ㅋ_ㅋ
푹신하고 포근하니
꿀 잠오게 만드는 룸컨디션 만족스럽습니다 

둘이서 대자로 크게 자도 여유있을 정도니..
이 정도면 대.만.족

하루종일 비가 내려
뷰가 좀 흐리지만

또 이런게 나름 분위기도 잡아주고
더 좋게만 느껴졌어요ㅎ_ㅎ 

침대 위 머리맡에
핸드폰 충전을 편리하게 할수 있도록 USB단자도 있어서
아주 유용합니다 

아 참
방안에 불끄는 스위치가 안 보여서 당황했는데

저기 전화기 전면에 터치식으로
불을 키고 끌수 있도록 되어 있어요~

이런 간이 쇼파도 유용하죠
둘이 앉기 딱 좋은 쇼파와 작은 테이블도 있어요ㅇ_ㅇ

개인 업무를 볼수 있는
사무용 책상도 있어서 출장오신
분들도 편하실 듯 합니다!

(저는 한번도 앉아 보진 않았지만요....!)

세면대 옆으로
샴푸,린스,바디워시,바디로션이 나란히 놓여있고
치약,칫솔은 구비 되어 있지 않습니다

혹시나 안 가져 오셨을시,
2층 CU편의점 가셔서 구매하시면 되요

(편의점도 커서 간식사러 가기 딱 좋습니다!)

개인적으로
변기칸과 샤워칸이 분리되어 있어서
좀 불편했네요ㅠ!

두 공간을 나누다 보니
변기칸이 좁아서 답답하다 해야되나
문도 미닫이 문이여서 정말 살짝 틈이 보여요..ㅋㅋㅋ

그치만 깔끔깨끗해서
나쁘진 않았어요~!

반대편으로 바라보면
이렇게 보이구요

세면대가 밖에 위치하여
바로바로 손 씻을수 있으니 편리 편리~

가운도 있어서
씻고 바로 꺼내 입으니 좋구요ㅎ_ㅎ

역시 야경이죠 야경 맛집 !

옆쪽 뷰는 허허벌판 공사판이라ㅋㅋㅋㅋㅋㅋㅋ 
시티뷰도 아니여서 오히려 저는
트여 있으니 좋아요 

배달음식은 1층 로비쪽으로 나가서
받아 오시면 됩니다 !
냉장고 안에 500ML 생수 두 통 있는데
냉장고가ㅋㅋㅋㅋ
계속 안 시원해져서 얼음컵 사다 마셨는데 생각해보니
얼음 요청하면 방으로 갖다 줍니다!

코로나 영향으로 부대시설은 거의 이용 못하고
방에만 있었지만,

또 갈 정도로
깔끔하고 친절해서 맘에 들어요 서울에서 이정도 호캉스면 만족!

JAVA

*int형 자릿수 구하기

Math.log10(num)+1 // int num = 숫자


*2차원 배열의 길이 구하기

int array = int[x][y];

array.length // x의 길이

array[y].length // y의 길이


*제곱함수

Math.pow(x,y); // x = 밑, y = 지수 ex) x^y // x의 y승

java(자바) - 정확한 숫자계산 할때 사용하는 빅데시멀(BigDecimal) 정리(형변환,선언,사칙연산)

자바에서 숫자값 계산을 할때 int, double등등을 사용하면 소숫점 값이 오차를 보이는데

오차를 만들지 않게 정확한 계산을 할때 사용합니다.

*선언

BigDecimal 변수명 = new BigDecimal(String숫자값);

BigDecimal num1 = new BigDecimal("1000.55");

BigDecimal num2 = new BigDecimal("0.5");

*사칙연산

num1.add(num2);   //덧셈 num1 + num2

num1.subtract(num2); //뺄셈 num1 - num2

num1.multply(num2);  //곱셈 num1 * num2

num1.multiply(num2);  //나눗셈 num1 / num2

*나눗셈 소수점처리

num1.divide(bdcl2 , 2(소수점자리수), BigDecimal.ROUND_UP); //올림

num1.divide(bdcl2 , 4, BigDecimal.ROUND_DOWN); //버림

num1.divide(bdcl2 , 3, BigDecimal.ROUND_HALF_UP); //반올림

num1.divide(bdcl2 , 1, BigDecimal.ROUND_HALF_DOWN); //반내림

*비교

num1.compareTo(num2);

//num1이 작으면 1 로 return

//num1이 같으면 0 로 return

//num1이 더크면 1 로 return

*소수점 처리

num1.setScale(소수점자릿수, BigDecimal.ROUND_UP)); //올림

num1.setScale(1, BigDecimal.ROUND_UP)); //올림

*타입변환

//빅데시멀(BigDecimal) -> 스트링(String)

num1.toPlainString();

//빅데시멀(BigDecimal) -> int/float/long 등

num1.intValue();

num1.floatValue();

num1.longValue();

에러 ( ORA-06550 )

ORA-06550: 줄 1, 열7:PLS-00201: 'PROC_INPUT_DATA' 식별자가 정의되어야 합니다

ORA-06550: 줄 1, 열7:PL/SQL: Statement ignored

-> 프로시저가 없는경우나 프로시저가 있는데 권한이 없는경우이 에러가 나옵니다.

해당 프로시저가 없을경우는 생성해주고, 

그 외에는    

문자열 오타를 확인하거나 오라클쪽에서 계정권한을 확인하시면 될것 같습니다.

java - 지정날짜의 월차이 차이 구하기 / 정확한 개월수 차이 구하기 / 날짜 차이 구하기 / 날짜 개월수 구하기

찾다가 오늘날짜에서의 개월수 차이 구하는 거밖에 안나와서 대충 만들었습니다.

부족하지만 필요하면 갖다쓰세요...

*윤년 계산법 = 현재년도 / 400  ( 나머지값이 0이면 29일 그외는 28일 )

*각 개월수별 범위

-3개월 89~92일

-6개월 181~184일

-12개월 365~366일

//시작

try {

String startDate = "20180101"; //시작날짜

String endDate = "20180301";  //마지막 날짜

// YYYY-MM-DD 로 만들기위해서 지우고 다시 생성해줌

startDate = startDate.replaceAll("-", "");

endDate = endDate.replaceAll("-", "");

String sd1 = startDate.substring(0, 4);

String sd2 = startDate.substring(4, 6);

String sd3 = startDate.substring(6, 8);

String ed1 = endDate.substring(0, 4);

String ed2 = endDate.substring(4, 6);

String ed3 = endDate.substring(6, 8);

startDate = sd1+"-"+sd2+"-"+sd3;

endDate = ed1+"-"+ed2+"-"+ed3;

// 날짜를 data타입으로 변경

SimpleDateFormat fm = new SimpleDateFormat("yyyy-MM-dd");

Date sDate = fm.parse(startDate);

Date eDate = fm.parse(endDate);

// 시간차이를 시간,분,초를 곱한 값으로 나누면 하루 단위가 나옴

long diff = eDate.getTime() - sDate.getTime();

        long diffDays = diff / (24 * 60 * 60 * 1000) ;

        long difMonth = (diffDays+1)/30; //총개월수 ( 대략 30으로 나눴을때 나오는 개월수 )

        long chkNum = 0; 

        int j=0;

        //개월수 체크 ( 시작한날짜월부터 위에서 대충 계산한 개월수까지 )

    //각 월별로 해당하는 월수에 맞게 더해줌

        for(int i=Integer.parseInt(sd2); j<difMonth; i++) {

        if(i==1 || i==3 || i==5 || i==7 || i==8 || i==10 || i==12 ) {

        chkNum += 31;

        }else if(i==4 || i==6 || i==9 || i==11 ) {

        chkNum += 30;

        }

        if(i==2) {

        //윤달체크

        if( ((Integer.parseInt(sd2))%400) == 0 ) {

        chkNum+=29;

        } else {

        chkNum+=28;

        }

        }

        j++;

 if(i>12) { i=1; j=j-1;}

        }

        long allMonth = (chkNum+1)/30; //진짜 총개월수

        if(diffDays < chkNum) { 

        allMonth = allMonth-1; // 대충 구한개월수는 더많을수 있어서 1빼줘서 진짜 개월수를 구함

        }

    System.out.println("날짜차이 =" + diffDays);

    System.out.println("총 차이  =" + chkNum); //실제 차이나야하는 총일수

    System.out.println("개월수 =" + difMonth);

    System.out.println("진짜개월수 =" + allMonth);

} catch (Exception e) {}

감사합니다

sysout으로 찍어놔서 확인해보시고 오류있으시면 댓글달아주세여..

제가확인할때는 괜찮았습니다.

착샷입니다. 다른거는 진짜 부해보여서 사고싶어도 살수가 없었는데

이건 좀 커버가되더라구요 물론 살을빼야겠습니다.

사이즈는 110으로 갔구요.

105정도 되는 사이즈입니다.

정사이즈 -5 다운하시면 될거같아요.

여자가 입어도 이쁘더라구요

여자친구도 입어봤는데 상당히 괜찮았어요

무게도 그렇게 무겁지가 않아서 착용했을때 착용감이 상당히 좋은편입니다.

덤블 시리즈 여러개 있는데 다 입어보시구 마음에 드시는걸로 구매하시면 좋을거 같아요

이정도로 글쓰고 마무리하겠습니다!!

이상으로 아디다스 덤블 후리스 ( ck0991 ) 리버서블 플리스자켓 구매후기였습니다.