결제 연동을 하기 위해서는 가장 간단한 방법으로 포트원 API를 이용하는 것이다. 각 PG사에서 제공하는 API를 이용하여 개발해야 하고 각 PG사마다 제공하는 API에 맞게 개발을 해야 하는데 포트원 API를 사용하면 모든 PG사와 결제수단을 쉽게 이용할 수 있다. 그리고 테스트 연동도 제공한다. 테스트 연동을 하면 자정 전에 결제 취소가 자동으로 된다. PG는 Payment Gateway 약자로 거래 및 결제를 도와주는 결제 대행사이다. 포트원은 모든 PG 모아서 한 번에 제공해 준다. 포트원 API 결제 프로세스결제 프로세스는 간단하다. 구매 페이지에서 결제창을 호출하고 PG사에 결제 인증을 요청한 다음 PG사에서 받은 결제 키 전달받는다. 그리고 PG사에 결제 요청을 하고 카드사에 결제 요청을..
Vault를 적용하게된 계기는 application.yml 파일에 DB접속 URL 등 다양한 개인정보들이 git에 노출되는것이 문제여서 적용하게 되었다. 기존에는 Jasypt 를 이용해서 암호화 하였는데 이것 역시 secret 키값이 프로젝트 코드속에 있어서 마음만 먹으면 secret 키값을 알아내서 암호화를 풀수 있다.Vault는 분산시스템에서 사용되고 시크릿한 정보들을 스프링 클라우드에서 데이터를 가져온다. 지금 프로젝트에서는 분산 시스템이 아니지만 나중에 분산시스템으로 변경 했을때 사용될수 있을것 같아서 미리 도입해 보았다. 그리고 환경변수에 값을 인입하는 방법도 있지만 그 많은 개인정보들을 환경변수에서 관리하면 데이터들이 늘어날수록 관리의 복잡성이 늘어나서 한계가 있다.환경변수에는 비밀정보가 아닌..
회원가입을 하기 위해서 3가지 흐름이 있다. 회원가입 로직1. 회원가입시 입력한 인증번호 확인2. member 테이블에 회원정보 저장3. account 테이블에 회원 인증정보 저장 위 로직 설명account 테이블이 따로 있는 이유는 회원 종류가 늘어날때 회원 종류의 테이블을 모두 돌아야 해서 회원 종류의 확장을 고려해 account 인증 테이블을 추가하였다.member테이블에 먼저 저장하는 이유는 member 테이블에 있는 전화번호 등 유효성검사를 하고 member 엔티티가 저장되고 생성된 id 값을 account 테이블에 넣기 위해서이다. [기존 코드]기존코드에서는 아래 코드처럼 Service 하나에서 위 로직을 모두 넣었다. @Transactionaloverride fun signUp(creat..
기존 2차 프로젝트에서 기준에서 3차 프로젝트를 하면서 2차 프로젝트의 자바 코드를 코틀린 코드로 변환을 완료하였다.2차 프로젝트 깃허브 링크 3차 프로젝트 깃허브 링크 프로젝트 환경Spring Boot 3.3.2Java 17코틀린 사용하면서 느낀 장단점Lombok 제거전환과정에서 자바와 가장 컸던 점은 코틀린에서는 Lombok을 안쓴다는 점이다. Lombok을 안쓰는 이유코틀린에서는 타입추론 기능이 있어서 변수앞에 타입을 안붙인다. 변수 값에 의해서 타입이 정해진다. 그래서 변수 앞에는 val이나 var을 붙이는데 val은 Getter 기능이 포함되어 있고 var은 Getter, Setter가 포함되어 있다.@Data 대신에 Data Class를 사용하면 equals(), hashcode(), toSt..
회원가입 이메일 인증 방법 개선전에는 MemberEntity에 enabled 필드를 추가하여 회원가입시 DB에 가입정보를 insert할때 enabled 필드에 false값을 넣어서 회원을 비활성화 하고 전송된 인증메일에 링크를 누르면 enabled 값을 true로 변경하여 회원을 활성화 시켰다. 하지만 이 방법은 회원이 인증을 하지 않으면 DB에 쓰레기 값만 남게 되고 회원이 다시 똑같은 아이디(email)로 회원가입을 못한다. 그래서 이메일로는 인증번호를 전송하고 회원가입 화면에서 인증번호를 제대로 기입해야 회원가입이 완료되도록 설정하였다. 인증번호 유효성은 Redis를 활용하였다. DB를 사용안하고 Redis를 활용한 이유는 DB에 직접 접근하지 않고 Redis 캐싱을 활용하여 인증을 빨리 할수있고 ..
회원가입 후 스프링 시큐리티의 기능을 활용해 계정을 비활성화하고 이메일 인증을 하여 회원을 활성화하는 방식으로 가장 간단하게 이메일 인증을 구현하였다. 1. mail 의존성 추가. implementation 'org.springframework.boot:spring-boot-starter-mail' 2. 구글 계정 생성 -> 2차 비밀번호 적용 -> 앱 비밀번호 생성.이메일을 막 보내게되면 계정이 정지될 수도 있으니 새로운 계정으로 하는 걸 추천한다. 계정 생성 후 2차 비밀번호를 적용하면 앱 비밀번호를 생성할 수 있는데 이 앱 비밀번호를 이용해서 메일을 전송할 수 있다. 3. application.yml 설정Gmail SMTP 연결을 위한 설정이다. 위에서 생성한 앱 비밀번호를 password칸에..
CI/CD 툴은 대표적으로 젠킨스가 있지만 젠킨스는 별도의 서버가 필요하는 등 설정이 어렵다. 그래서 규모가 작은 프로젝트에 적합하고 빠르게 구축이 가능한 Github Actions를 선택하였다. Github Actions 플로우Github Actions 빌드 배포 플로우는 Github Actions를 작동시켜서 빌드 결과물 jar 파일을 S3에 전송한다. 그리고 S3에 있는 jar파일을 CodeDeploy가 EC2에 배포 해서 실행 시킨다. 위에서 Github Actions가 CI(지속적인 통합) 역할을 하고 CodeDeploy가 CD(지속적인 배포) 역할을 한다.Github Actions는 프로젝트 소스를 빌드및 테스트코드도 실행시켜 배포하기에 적합한 소스인지 확인 한다. 만약 테스트 코드중 하나라..
파라미터 유효성 검증에 대한 코드 리팩토링 과정을 설명한다. 파라미터 유효성 규칙 추가처음에 유효성 검증을 위해 회원가입 컨트롤러에서 CreateMemberRequest DTO를 받아서 회원가입 로직을 처리하고. 앞에 @Validated를 붙이고 DTO 필드에 어노테이션을 이용하여 필드마다 유효성 규칙을 추가하였다. 파라미터에 대한 유효성 검증을 하였다. 위 방식의 문제는 유효성 규칙을 통과 못했을때 응답하는 messgae가 너무 정형화 되지않은 형식으로 된다. 사용자한테 아래 메시지대로 보여주면 이해하지 못하므로 필요한 메시지를 정형화 시켜야 된다. BindingResult 이용해서 파라미터 유효성 에러 메시지 정형화메시지를 정형화 되도록 하기 위해서 첫째로 BindingResult를 쓰는 방법이 있..
자바 11 -> 17업그레이드와 스프링시큐리티 5버전에서 6버전에서 업그레이드 하고나서 발생한 error와 warning을 수정한 과정이다. 업그레이드 하고 나서 security 설정 부분에서 에러가 발생하여 에러를 수정하였다.SecurityConfiguration 수정 cors() 메서드 들어가서 documentation에 들어가서 삭제된 이유를 확인해보니 공식문서에 아래와 같은 이유가 있었다. 단순하게 이해해서 이전 방식(메서드 체이닝)이 가독성이 안좋기도 하고 람다 방식과 메서드 체이닝 방식 같이 사용하기 때문에 혼란을 야기한다는 뜻 같았다. 그래서 메서드 체이닝 방식을 완전히 삭제 한 것 같다. 그래서 아래처럼 메서드 체이닝 방식을 모두 람다식으로 수정하였다. 그리고 cors.disable()..
1차 프로젝트에서 Mybatis를 적용한 아키텍쳐는 단순히 Service에서 MybatisRepository를 의존한 것이다. JPA를 변환하고자 했을때 단순하게 생각하면 아래 아키텍쳐를 가질 수 있다.하지만 위 설계는 DIP를 위반한 것이다. 왜냐면 고수준 Service가 저수준 MybatisRepository와 JpaRepository를 직접 의존하기 때문이다. MybatisRepository를 지우지 않고 JPA 기능을 추가한 이유는 언제든지 수정중인 소스를 운영에 반영할수 있도록 하기 위함이다. JPA기능을 추가하고 테스트코드도 작성되지 않은 상태에서 Mybatis 기능을 삭제해버리면 이 소스를 운영에 반영 할 수 없다. 그래서 언제든지 운영에 반영할 필요가 있을때 빠르게 수정중인 소스에서 Myb..
1차 팀프로젝트에서는 Springboot 2.7, Mybatis, SpringSecurity 5.x 버전을 이용해서 개발을 하고2차 팀프로젝트에서는 1차 프로젝트 레파지토리를 복사하여 Springboot 3.2, Jpa, SpringSecurity 6.x 버전으로 업그레이드 하는걸로 목표 삼았다. 1차 팀프로젝트를 버전 업그레이드와 1차에서 못한 기능들을 개발하고 1차에서는 지키지 못한 Solid 설계 원칙을 지켜 적용시키기로 하였다. 1차 팀프로젝트에서는 문서관리를 Jira, Github, Notion, Google Docs 4개 툴에서 관리하여 스프린트를 잘 지키지 못하여서 이번에는 Github 하나의 툴에서 관리하도록 하였다.1차 팀프로젝트 문서관리 정리 링크 : https://deftkang.ti..
이 문제는 입출력 관계를 이해하기 어려웠다. Queue라는 말을해서 문제푸는 방법의 힌트를 주긴했지만 문제 자체를 이해하기는 쫌 어려웠던것 같다. 문제 이해아래 입력에서 왜 출력 5가 나왔냐면 [입력] -> [출력]6 0 51 1 9 1 1 1 입력단계에서 첫번째줄 6은 문서의 개수고 0은 몇번째로 출력되는지 알고싶은 문서의 번호이다. 문서의 번호는 0부터 시작하고 몇번째로 출력되는지는 1부터 시작한다. 문서의 개수가 6이므로 문서 배열은 {0, 1, 2, 3, 4, 5} 이렇게 된다. 그리고 중요도의 배열은 {1, 1, 9, 1, 1, 1} 이 된다.이 둘의 관계를 배열로 묶으면 {{0, 1}, {1, 1..