Developer K

2장. 효과적인 피드백 활용 레거시 코드 변경 알고리즘 변경 지점을 식별한다. 테스트 지점을 찾는다. 의존관계를 깬다. 테스트 루틴을 작성한다. 변경시키고 리팩토링한다. 3장. 감지와 분리 레거시코드를 원자 단위까지 분리하여 변경지점을 식별한다. 의존관계를 가진 객체의 경우 Mock/Fake 객체를 사용하기 위해 인터페이스로 의존성을 깬다. 테스트 루틴을 작성 -> 수정 -> 테스트 성공 -> 리팩토링 단계를 반복한다. 4장. 봉합 자바에서는 클래스패스를 이용한 다른 버전의 클래스를 만들수 있다. 5장. 레거시 코드를 위한 도구 JUnit 6장. 고칠 건 많고 시간은 없고 발아(Sprout) Method / Class: 메서드/클래스를 추가 포장(Wrap) Method / Class: 기존 메서드/클래스를 포장하는 메서드/클래스를 추가(데코레이터 패턴) 7장. 코드 하나 바꾸는데 왜 이리 오래 걸리지? 의존관계 반전 원칙 당신의 코드가 인터페이스에 종속되는 경우, 그 의존관계는 사실 경미한 수준으로 눈에 잘 띄지 않는다. 인터페이스가 변하지 않는 한, 코드를 변경시킬 필요는 없다. 또한 인터페이스들은 그들 아래에 위치한 코드에 비해 훨씬 적은 빈도로 변경된다. 인터페이스를 하나 가지고 있는 경우, 그 인터페이스를 구현하는 클래스들을 편집하거나 그 인터페이스를 구현하기 위한 새로운 클래스들을 추가할 수 있다. 물론 그 인터페이스를 사용하는 코드에 영향을 주지도 않는다. 이런 이유 때문에 구체 클래스보다는 인터페이스나 추상 클래스에 종속되는 편이 좋다. 덜 변하는 것들에 종속됨으로써 특정 변경이 초래할지도 모를 대규모 재컴파일 사태의 위험을 최소화할 수 있다. 8장. 특징, 어떻게 추가할까? 테스트 주도 개발 실패 테스트 케이스를 작성한다. 컴파일되게 만든다. 테스트에 통과하도록 만든다. 중복을 제거한다. 반복한다....

AOP Aspect Oriented Programming 독립적인 모듈화가 불가능한 트랜잭션 경계설정과 같은 부가기능을 모듈화하는 작업 Aspect: 핵심기능에 부가되어 의미를 갖는 특별한 모듈 AOP는 Aspect를 분리함으로써 핵심기능을 설계하고 구현할 때 객체지향적인 가치를 지킬 수 있도록 도와주는 것(토비의 스프링) Transaction 더 이상 나눌 수 없는 단위 작업 SQL을 이용해 다중 로우의 수정이나 삭제를 했을 때, 일부는 되고 나머지는 안되는 경우는 없다. DB가 트랜잭션을 보장해 준다고 믿음. 여러 SQL이 실행될 때, 어느 한 SQL이 장애가 발생하면 이전에 실행된 SQL 작업은 취소해야 하는데, 이 취소 작업을 "트랜잭션 롤백" 여러 SQL이 실행될 때, 모든 SQL이 성공적으로 마무리했다면, DB에 해당 SQL 작업들을 확정해야 하는데, 이 확정 작업을 "트랜잭션 커밋" JDBC의 트랜잭션은 default 로 setAutoCommit(true) 이므로, 프로그램적으로 여러개의 SQL에 대하여 트랜잭션 경계설정을 하기 위해서는 autoCommit을 false로 설정해야 한다. CGLIB Code Generator Library 런타임에 동적으로 클래스의 프록시를 생성함 JDK Dynamic Proxy 보다 더 빠르다. JDK Dynamic Proxy 의 경우 리플렉션을 이용해 인터페이스의 구현 클래스를 위임하는 프록시 클래스를 이용하며, CGLIB는 클래스 파일을 상속받아서 프록시 클래스를 만들어 낸다. JDK Dynamic Proxy(인터페이스 필요), CGLIB(인터페이스 필요없음) AspectJ 는 스프링 컨테이너를 사용하지 않는 경우에도 프록시 클래스 생성을 해주며, 런타임시 바이트코드를 조작하는 방식을 사용한다. IOC 제어권의 이전을 통한 제어관계 역전 오브젝트가 자신이 사용할 오브젝트를 스스로 선택하지 않고 생성하지...

인터페이스(Interface) 둘 사이를 연결하는 매개체 public abstract method로 구성 모든 변수는 public static final로 구성 instance를 생성할 수 없음 interface간의 상속(extends)이 가능 class는 interface를 구현(implements)함으로 추상메서드들의 오버라이딩 관계가 성립함 interface의 형을 대상으로 참조변수의 선언이 가능 자바8 부터 default 메서드, static 메서드 정의 가능 마커 인터페이스로 사용하기도 함 상속(Inheritance) 연관된 일련의 클래스들에 대해 공통적인 규약을 정의할 수 있습니다. 자식클래스의 인스턴스가 생성되면 부모클래스 생성자부터 자식클래스 생성자 순으로 호출된다. 단일 상속 static 변수는 상속하지 않는다. 자식클래스는 부모클래스의 모든 특성을 지닌다. IS - A 관계 오버로딩(Overloading) 메서드 오버로딩: 한 클래스 내에 동일한 이름의 메서드를 둘 이상 정의할 때, 각 메서드 매개변수의 선언이 다를 경우 생성자 오버로딩 : 한 클래스 내에 생성자의 매개변수를 각기 달리 정의할 경우 오버라이딩(Overriding) 부모 클래스에서 정의된 메서드를 자식 클래스에서 다시 재정의 final 클래스를 정의하는데 다른 클래스가 상속하는 것을 원하지 않을 때 메서드를 정의하는데 다른 클래스에서 오버라이딩을 원하지 않을 때 static 클래스 변수: 모든 인스턴스가 공유하는 변수를 선언 클래스 메서드: 인스턴스 생성을 할 필요없이 바로 사용하는 메서드를 선언 JVM의 메모리 영역 Method 영역: 메서드의 바이트코드, static 변수 Stack 영역: 지역변수, 매개변수 Heap 영역: 인스턴스 Wrapper 클래스 기본 자료형을 객체로 만들거나(boxing) Wrapper 클래스 인스턴스를 기본자료형으로 ...

스프링부트와 Google App Engine 구글 앱엔진을 사용하려면 먼저 구글 클라우드 SDK 를 설치합니다. 구글 클라우드 SDK 설치는 여기 를 참고하세요. 스프링 부트를 Google AppEngine 으로 deploy하기 스프링 부트에서 Google App Engine 으로 deploy를 위해서는 app.yaml 파일과 pom.xml 파일에 appengine-maven-plugin 추가만 해주면 됩니다. app.yaml 파일은 다음과 같이 생성합니다. app.yaml 설정 정보는 여기 를 확인하세요. 위의 app.yaml 스크린샷에서는 runtime 환경은 java 이고, appEngine은 가변형 환경입니다. service 는 앱엔진에 올라간 서비스명을 의미합니다. default 는 기본 서비스명입니다. resources 는 앱엔진 머신 스펙을 의미합니다. cpu는 1개, memory 는 1.5gb를 의미합니다. manual_scaling 은 가변환경에서 인스턴스의 갯수를 설정합니다. pom.xml 파일에는 다음과 같이 설정합니다. <plugin> <groupId>com.google.cloud.tools</groupId> <artifactId>appengine-maven-plugin</artifactId> <version>1.3.2</version> </plugin> 커맨드라인에  mvn appengine:deploy 를 실행하면 deploy가 됩니다. 스프링 부트 스케쥴링 기능을 Google AppEngine 크론 작업으로 대체하기 스프링 부트에서 스케쥴링은 크론 작업이라는 구글 클라우드 앱엔진 내의 서비스로 별도로 수행됩니다. 관련해서는 이미 포스팅한  Dolphin 1 문서를 참조하세요. 스프링 부트 + MySQL을 Google Cloud Platform(GCP) - SQL...

적금 만기 해지 후 잔액을 예금상품으로 가입할 수 있도록 시뮬레이션 기능 제공. 기본적인 로직은 다음과 같습니다. Simulator 페이지에 접근하면 적금계좌가 존재하는지 살펴봅니다. 적금계좌가 존재하지 않을 경우 적금계좌 생성(적금 상품 추천 폼) 페이지로 이동합니다. 적금계좌가 존재할 경우, 만기에 도달한 계좌가 있는지 살펴봅니다. 만기 계좌가 존재하지 않을 경우, 계좌 목록이 보여지게 됩니다. 만기 계좌가 존재 할 경우, 계좌 목록에 만기 해지 처리를 위한 버튼이 노출됩니다. 시뮬레이션을 위해서 임의의 시간을 표현하는 버튼이 존재합니다. 2019년 02월 11일 이라는 버튼이 가로로 길게 뻗어서 놓여 있습니다. 이 버튼을 클릭하면 다음 달로 시간이 흘러가게 되고 적금계좌가 존재한다면 적금납부일에 맞춰 자동으로 납입합니다. Alert 메시지창에 날짜가 변경되었다고 알려줍니다. 날짜 변경버튼은 이제 2019년 3월 11일이 되었고, 적금계좌의 잔액이 증가했습니다. 남은 기간도 365에서 337일로 줄고, 적금 납입 회차가 2회분으로 추가 납입했음을 알 수 있습니다. 적금이 만기에 도달하면 만기 해지 버튼이 나타납니다. 적금을 해지하기 전까지는 날짜 버튼을 클릭해도 날짜가 변경되지 않습니다. 만기 해지 버튼을 클릭하면 원금 합계와 세전이자를 합한 금액에 이자소득세를 뺀 금액(15.4%)이 내 가상의 지갑으로 입금됩니다. 입금된 금액은 21,899,011원 입니다. 금액이 적힌 버튼을 클릭하면 상세한 지갑 입출내역이 보여집니다. 금액과 입출유형, 거래시각이 나타나있습니다. 지갑 버튼 옆에 예금 개설 버튼도 새로 생깁니다. 지갑에 돈이 일정이상 있을경우 버튼이 활성화됩니다. 예금 개설을 진행하면 지갑에 있는 잔액을 예금 계좌 개설에 사용합니다. 예금 개설 버튼을 클릭하면 가입 금액은 지갑에 보유중인 금액으로 정해지며, 해당 가...

가입금액만 입력하면 가장 많은 이자를 얻을 수 있는 금융상품 추천. 은행에서 가입할 수 있는 상품 중에는 예금과 적금 상품이 있습니다. 예금은 목돈을 일정기간동안 예치한 뒤 원금과 이자를 받는 상품이며, 적금은 정해진 시기마다 일정 금액을 계속 납입한 뒤 일정기간이 지난뒤 납입 총 원금과 그에 따른 이자를 받는 상품입니다. 상품에 가입할 때는 이자를 가장 많이 주는 상품에 가입하는것이 당연하지요. 국내 예/적금을 운용하는 금융권들은 다양한 상품이 출시되어 있는데, 상품마다 가입조건이 다르고, 그에 다른 우대금리도 다릅니다. 개인에게 가장 적합한 상품을 찾기 위해서는 다양한 정보가 필요합니다. 직업, 연령대, 성별 등등 아주 많은 개인정보가 필요하고 그걸 다 입력하면 나에게 가장 적합한 상품을 찾을 수 있습니다. 하지만, Dolphin 프로젝트는 가장 단순하게 가입 금액 기준으로 세전이자를 가장 많이 받을 수 있는 상품을 추천하는것이 목표입니다. 예금이자계산법은 다음과 같습니다. 적금이자계산법은 다음과 같습니다. 출처: 카카오뱅크 정기예금 상품설명서, 카카오뱅크 자유적금 상품설명서 이제 Dolphin에서 적금 상품 추천을 위한 가입금액 입력화면을 보겠습니다. 월 납입금액을 입력하는 Form 화면에 달랑 input 필드 하나만 존재합니다. 금액만 입력하면 상품이 추천됩니다. 가입기간은 1년단위로 고정되어 있습니다. 가입기간이 1년보다 짧으면 은행에서는 금리가 대폭 줄입니다. 거의 금리혜택을 볼 수 없도록 상품을 구성해두었습니다. 가입기간이 너무 길면 가입자 입장에서는 너무 답답합니다. 그래서 1년을 기준으로 잡았습니다. 월 납입 금액을 입력 후 엔터키를 누르면 세전이자가 가장 높은 순으로 3개의 상품을 추천합니다. 1등부터 3등까지 은행명과 상품명, 예상 만기해지금액, 상품 최종업데이트 시간이 나와있습니다. 예상 만기해지금액 버튼을 클릭하면 상품 상세정보 Modal 레이어가 나옵니다...

100자 이내의 짧은 글을 쓸 수 있는 게시판 제공. Dolphin Project에서 가장 메인 서비스는 예적금 시뮬레이터이므로, 다른 기능 구현은 차후로 미뤄뒀지만, 사용자와 소통할 수 있는 최소한의 기능은 제공하는게 맞다는 생각이 들어 아주 단순한 게시판 기능을 제공합니다. 사용자가 글을 쓰려면 로그인을 먼저 해야합니다. 글을 등록 후 삭제할 때 글 작성자를 식별할 수 있어야 하기 때문입니다. 게시판은 Dolphin Frontend Main 페이지에 자리잡았습니다. 사용자가 가장 먼저 만나게 되는 웹페이지이므로 적당하다고 생각합니다. 다음은 로그인을 하기 전 사용자가 볼 수 있는 메인 페이지입니다. 글 상단에는 작성일(MMM-dd-yyyy)과 작성자 고유번호(#numbers)가 노출됩니다. Dolphin 은 네이버 로그인을 사용하기 때문에, 사용자를 식별할 수 있는 정보는 저 고유번호가 됩니다. 하단에는 글 내용이 자리잡습니다. 스크린샷에서는 Hello, world!! 라는 문구가 보이네요. 글은 최대 100자까지 허용합니다. 버튼 두개(Newer, Older) 는 페이징 버튼인데, Newer는 최근페이지로 이동을 하며, Older는 지나간 글을 보는 페이징버튼입니다. 기본 페이지 사이즈는 20개입니다. 오른쪽으로 보이는 글 작성 폼은 현재 로그인 하기 전이므로 textarea 는 disabled 처리되어 있고 Login버튼이 자리잡고 있습니다. 다음은 사용자가 로그인 한 뒤의 메인페이지입니다. 변경된 부분은 사용자 고유번호 뒤에 Remove 버튼이 나타났습니다. 해당 글 작성자가 로그인한 사용자일 경우에만 보이게 됩니다. 오른쪽 글 작성 폼도 이제 활성화 되었습니다. 아주 단순한 Textarea 창과 Submit 버튼이 자리잡고 있습니다. 다음은 작성자가 아닌 다른 사용자가 로그인한 경우 입니다. 사용자 고유번호(#54097272) 옆에 Remove 버튼이...

별도의 회원가입 없이 소셜 로그인 기능 제공으로 간편한 로그인 가능. Dolphin 프론트엔드는 회원가입 절차가 따로 없고, 간단하게 소셜 로그인 기능을 제공함으로써 회원가입, 인증절차를 생략했습니다. 우선, 간단하게 국내에서 잘 알려진 네이버의 API를 사용합니다. 네이버 개발자센터 웹사이트 에서 네이버 아이디로 로그인 기능을 살펴봅니다. 개발 문서를 자세히 살펴보고 API 신청을 합니다. 애플리케이션의 이름을 정하고 필요한 정보를 필수/선택에 체크합니다. 밑으로 내려보면 로그인 API 서비스 환경 부분에서 환경 추가 셀렉트박스에서 PC 웹을 선택하면 다음과 같은 입력폼이 나타납니다. 서비스 URL은 내 웹애플리케이션의 URL이 될 예정입니다. 지금은 개발상태이므로 localhost를 입력했습니다. Callback URL은 네이버 OAuth 인증 url로 호출하면, 인증절차 후 네이버에서 리다이렉트해줄 url을 뜻합니다. 저는 /naver/login 으로 했습니다. 등록이 완료되면 client-id와 client-secret 값을 제공해줍니다. 이 값을 이용해서 인증처리를 할 수 있습니다. spring.io 웹사이트의 튜토리얼 문서를 보면 Facebook 소셜 로그인 기능에 대한 설명이 자세하게 나와있습니다. 이 부분을 참고합니다. Spring Boot and OAuth2 pom.xml 파일에 의존성을 추가하고 Application 클래스에 @EnableOAuth2Sso 애너테이션을 선언합니다. 튜토리얼대로 application.yaml 파일(application.properties)에 설정 정보를 입력합니다. clientId, clientSecret 값은 네이버 개발자센터에서 받은 대로 입력합니다. accessTokenUri는 네이버의 경우 https://nid.naver.com/oauth2.0/token 입니다. userAuthorizationUri는 네이버의 경우 https://ni...

금융감독원 OPEN API를 사용하여 데이터 수집 금융감독원 금융상품통합비교공시 사이트에서 제공하는 OPEN API 를 사용합니다. 먼저, API 키를 신청합니다. https://finlife.fss.or.kr/PageLink.do?link=openapi/certification&menuId=2000119  로 접속합니다. 약관에 동의하고 본인인증 후, 신상정보를 넘기면 바로 API 키를 받을 수 있습니다. 상세 및 테스트 페이지를 들어가보면 요청 파라미터와 응답 API 형태를 확인할 수 있습니다. 요청은 다음과 같습니다. 읽어보면 서비스 명에 따라 url이 달라지는 부분을 제외하면 요청 URL은 크게 달라지지 않습니다. 파라미터에 인증키, 권역코드, 페이지번호를 전달하면 됩니다. 응답부분은 서비스마다 다르지만 공통 응답 형태는 다음과 같습니다. 에러코드, 에러메시지, 전체 개수, 전체 페이지, 현재 페이지 번호 입니다. 예금상품 조회 서비스나 적금상품 조회 서비스의 경우 공통적으로 금융회사 코드와 이름을 전달해주는데 해당 금융회사의 상세한 정보를 보려면 금융회사 조회 서비스도 호출하는게 나중에 좋을것 같습니다. Spring으로 HTTP 통신을 위해서 Apache HttpComponent 라이브러리를 사용합니다. 메이븐에 다음과 같이 의존성을 추가합니다. <dependency> <groupId>org.apache.httpcomponents</groupId> <artifactId>httpclient</artifactId> </dependency> 다음은 API를 호출하는 간단한 소스코드 조각입니다. CloseableHttpClient httpClient = HttpClients.createDefault(); URI uri = new URIBuilder() .setScheme("http") .setHos...

Docker에 MySQL을 사용하겠습니다. docker run -d -p 3306:3306 -e MYSQL_ROOT_PASSWORD=password --name mysql mysql docker run은 도커 이미지를 컨테이너로 등록하는 명령어입니다. -d(Detached) 는 detached 모드로 사용한다는것을 말합니다. -d 를 적지않으면 foreground모드로 작동합니다. foreground모드는 컨테이너를 실행한 콘솔에 표준입출력(STDIN/STDOUT/STDERR)을 사용하여 작동함을 말합니다. detached모드는 모든 I/O가 네트워크 접속 또는 공유 볼륨을 통해서 작동하므로 컨테이너는 더이상 커맨드라인을 Listening 할 필요가 없습니다. 자세한 내용은 여기 를 참조하세요. -p(Port) 는 컨테이너가 호스트에 노출(EXPOSE)할 포트를 설정합니다. 형식은 호스트포트:컨테이너포트 입니다. MySQL의 Well-known 포트인 3306을 설정할 경우를 예를 들면 3306:3306은 호스트포트도 3306이고 컨테이너 포트도 3306임을 말합니다. 컨테이너에 MySQL 데몬이 돌고 있고 이 MySQL의 포트가 3306으로 설정되어 있다면 컨테이너가 노출할 포트를 3306으로 하고, 호스트에서 컨테이너로 접속할 포트도 3306으로 한다고 했을경우, 호스트에서 3306으로 접속하면 도커 컨테이너의 3306포트가 열린 컨테이너로 접속합니다. 자세한 내용은 여기 를 참조하세요. -e(Environment) 옵션은 환경변수를 추가하는 설정입니다. 도커 컨테이너가 새롭게 생성될 경우 지정하면 해당 환경변수를 도커 컨테이너 생성시에 추가합니다. MySQL Official 이미지의 환경변수 MYSQL_ROOT_PASSWORD=password 를 추가하면 MySQL Root 사용자의 비밀번호를 password 로 하겠다는 뜻입니다. 자세한 내용은 여기 를 참조하세요. --name 은 컨테이너의 이름을 정합니다. --name ...

생성자 대신 정적 팩터리 메서드를 사용할 수 없는지 생각해 보라 생성자 인자가 많을 때는 Builder 패턴 적용을 고려하라 private 생성자나 enum 자료형은 싱글턴 패턴을 따르도록 설계하라 객체 생성을 막을 때는 private 생성자를 사용하라 불필요한 객체는 만들지 말라 유효기간이 지난 객체 참조는 폐기하라 종료자 사용을 피하라 equals를 재정의할 때는 일반 규약을 따르라 equals를 재정의할 때는 반드시 hashCode도 재정의하라 toString은 항상 재정의하라 clone을 재정의할 때는 신중하라 Comparable 구현을 고려하라 클래스와 멤버의 접근 권한은 최소화하라 public 클래스 안에는 public 필드를 두지 말고 접근자 메서드를 사용하라 변경 가능성을 최소화하라 계승하는 대신 구성하라 계승을 위한 설계와 문서를 갖추거나, 그럴 수 없다면 계승을 금지하라 추상 클래스 대신 인터페이스를 사용하라 인터페이스는 자료형을 정의할 때만 사용하라 태그 달린 클래스 대신 클래스 계층을 활용하라 전략을 표현하고 싶을 때는 함수 객체를 사용하라 멤버 클래스는 가능하면 static으로 선언하라 새 코드에는 무인자 제네릭 자료형을 사용하지 마라 무점검 경고(unchecked warning)를 제거하라 배열 대신 리스트를 써라 가능하면 제네릭 자료형으로 만들 것 가능하면 제네릭 메서드로 만들 것 한정적 와일드카드를 써서 API 유연성을 높여라 형 안전 다형성 컨테이너를 쓰면 어떨지 따져보라 int 상수 대신 enum을 사용하라 ordinal 대신 객체 필드를 사용하라 비트 필드(bit field) 대신 EnumSet을 사용하라 ordinal을 배열 첨자로 사용하는 대신 EnumMap을 이용하라 확장 가능한 enum을 만들어야 한다면 인터페이스를 이용하라 작명 패턴 대신 어노테이션을 사용하라 Override 어노테이션은 일관되게 사용하라 자료형을 정의할 때 표식 인터페이스를 사용하라...

식품을 추가하면, 해당 식품이 어떤 종류인지 사람은 쉽게 유추할 수 있다. 예를들어, 우유, 치즈 같은 제품은 유제품으로 분류할 수 있고, 사과, 바나나, 딸기 같은 제품은 과일로 분류할 수 있다. 이렇게 같은 특성을 지닌 부류나 범위를 범주 , 또는 카테고리 라고 한다. 사용자가 새로운 식품을 추가하면, 해당 식품이 어느 범주에 속하는지를 분류해서 입력값으로 넘겨준다면 좋겠지만, 너무 많은 입력을 요구하면 View가 복잡해지고 사용자 편의성이 떨어지게 된다. 따라서, 입력되는 식품명을 기반으로 해당 식품의 범주가 어디에 속하는지 분류해준다면 편리할 것이다. 식품명에 따른 범주화해주는 로직은 다음과 같다. 사용자로부터 식품명을 입력받는다. 사전에 분류해둔 키워드 데이터들과 입력받은 식품명의 유사도를 측정한다. 측정된 유사도 결과값 중에서 가장 유사한 키워드의 범주를 반환한다. 예를들어, {사과, 바나나, 딸기} 는 "과일" 이라는 집단으로 분류하고, {우유, 치즈, 요거트} 는 "유제품" 이라는 집단으로 분류한다. 사용자가 입력한 식품명이 "맛있는 사과 5kg (23과내)" 라고 주어졌을 때, "사과" - "맛있는 사과 5kg (23과내)" 와 유사도를 측정하고, "바나나" - "맛있는 사과 5kg (23과내)" 와 유사도를 측정하고, "딸기" - "맛있는 사과 5kg (23과내)" 와 유사도를 측정한다. 같은 방식으로 유제품의 키워드들과도 유사도를 측정한다. 키워드 각각 주어진 식품명과 유사도를 측정해서 나온 결과 값이 가장 높은 키워드의 범주값을 반환한다. 키워드 데이터와 주어진 문자열 사이의 유사한 정도를 측정하기 위해서 자카드 유사도 라는 알고리즘을 사용한다. 자카드 유사도( 자카드 지수 )는 두 집합 사이의 유사도를 측정하는 방법이다. 자카드 유사도 알고...