해킹왕 양선규

HTTP에 SSL 인증서(암호화라고 보면 됨)를 적용한 것이 HTTPS 이다. 웹을 서비스하기 위해서 SSL 인증서는 필수라고 할 수 있다. SSL 인증서가 없다면 1차적으로 브라우저에 안전하지 않다는 경고가 뜨며, 데이터가 평문으로 노출되어 탈취당할 가능성이 있고, 최신 웹 프로토콜이나 기술들과 호환되지 않을 수 있다. 심지어 개인정보를 취급하는 웹 사이트의 경우 암호화 등의 보안 조치를 취하는 것이 법적으로 의무화 되어 있고, HTTPS는 암호화를 적용하는 가장 쉽고 표준적인 방법이기 때문에 적용하지 않을 이유가 없다. SSL 인증서를 적용하는 대표적인 방법은 크게 두 가지가 있다.1. AWS의 ACM, Route53, 로드 밸런서를 이용한 SSL 인증서 적용2. Let's Encrypt, 가비아(또..

일반적인 배포는 많이 해 봤지만, CI/CD 파이프라인 구축과 무중단 배포는 한 번도 해본 적 없었다. 개인 프로젝트 때 반드시 해 보고 싶었던 것 중 하나였기에, 이번에 직접 구축해 보았다. Jenkins와 Blue/Green 전략을 활용해서 무중단 배포 CI/CD 파이프라인을 구축했고, 문제 발생 시 한 단계 전으로 수동 롤백이 가능하도록 했다. Jenkins 설정이 약간 복잡한 듯 싶었지만 Jenkins가 복잡한 게 아니라 CI/CD와 무중단 배포 구현이 복잡한 거였다. 난 EC2 프리티어 인스턴스와 RDS 프리티어 데이터베이스를 사용했다. 글에서는 기본 배포가 이미 되어 있다고 가정한다. 나는 프리티어를 쓰는 만큼, Jenkins와 스프링 부트 애플리케이션 서버를 단일 프리티어 인스턴스 내에 두었..

테스트 코드처음으로 테스트 코드라는 것을 작성해 보았다. 단위 테스트, 통합 테스트에 대해 공부하고 그것을 적용해 테스트 코드를 작성했다. 테스트 코드는 말 그대로 테스트이기 때문에 간단할 것이라고 생각했지만 생각보다 고려할 것이 많았다. 물론 그냥 내 맘대로 짜면 짤 수도 있었겠지만, 무엇이 좋은 테스트인가? 어떤 것을 테스트해야 하는가? 모킹은 어느 정도 수준까지 해야 하는가? 테스트 해야 할 흐름은 어떤 것들이 있는가? 즉, 최적의 테스트 라는 게 무엇인지를 깊이 탐구하는 것과, 그것을 알기 위해 테스트라는 것 자체를 깊게 이해해야 했기에 많은 시간이 걸렸던 것 같다. 테스트는 보는 이로 하여금 테스트의 의도가 명확히 전해져야 하고, 그것을 위해 조금의 불편함도 감수할 수 있어야 한다. 쓸데없이 복..

일반적인 Hard Delete 방식을 사용했다면 외래키 관계를 이용한 엔티티와 DB 레벨에서의 cascade를 이용할 수 있었을 테지만, 중고차 거래 플랫폼 특성상 데이터의 신뢰도가 중요했기 때문에 Soft Delete 방식을 채용했다. 그로 인해 연쇄 삭제 기능은 서비스 레벨에서의 delete() 메서드 조합이나 QueryDsl 커스텀 쿼리를 통해 직접 구현해야 했다. 처음엔, 모든 엔티티가 상속받는 BaseEntity에 존재하는 softDelete() 메서드를 Facade 서비스 클래스에서 전부 호출해서 삭제할까 생각했다. 하지만, 그러면 제공되는 인자는 CarListing.id(판매 차량 id) 한개 뿐일텐데 이걸로 repository 조회해서 연관된 엔티티 id를 얻고 하는 일련의 작업을 서비스 ..

썬카의 기능이 조금씩 많아지니, 코드를 수정할 때마다 매번 Postman으로 api를 호출해보는 나를 발견할 수 있었다. 이 작업이 번거롭다고 느껴지는 순간, 테스트 코드를 도입할 때가 왔다고 느꼈다. 그래서 잠시 스프린트는 접어두고 테스트 코드를 도입한 후 작업에 들어가기로 했다. 처음 작성해 보는 테스트 코드였지만, 나는 말 그대로 테스트만 하는 코드인데 오래 걸리겠어? 라고 생각했다. 그러나 이렇게나 생각할 게 많고 복잡할 줄 몰랐다. 테스트의 종류도 여러 가지였고 각각 어떤 테스트인지, 어떤 상황에서 도입해야 하는지, 우선순위는 어떻게 되는지 전부 생각해야 했다. 테스트 코드 자체도 전부 처음 보는 방식, 메서드들이라 기존의 난 완전 백지 상태나 다름이 없었어서 완전히 하나하나 차근히 공부하면서 ..

스프린트 3이 종료되었다. 스프린트 2 회고에서 차량 등록, 조회를 어떻게 구현할지 걱정했지만 훌륭히 구현해 냈다.이번에 구현한 기능은 아래와 같다.차량 등록판매 차량 상세 조회 차량 정보를 다루는 엔티티가 무려 10개였기 때문에, 백엔드 코드 작성이 매우 매우 어려웠다. 애플리케이션 레벨에서 관계는 어떻게 정의하며, repository와 service는 어떤 구조로 작성하고 관리하는지, 쿼리는 어떻게 최적화 하는지 등등… 고민해보지 못했던 문제들을 많이 만났다. 스프린트 2의 유저 관련 로직을 짤 때보다 10배는 더 어려웠던 것 같다. 이번 스프린트 3을 진행하며 가장 크게 배운 것은 객체지향적 설계와 SOLID원칙, 그리고 쿼리 최적화이다. 백엔드에서 어려웠던 점 - 객체지향적 설계와 N+1, 카테시..

차량 상세조회 기능을 구현하며 차량 관련 엔티티 10개를 조회해야 했는데, 이 과정에서 Lazy Loading, fetchJoin, BatchSize를 공부하고 적용해 보았다. 백엔드에서 쿼리 짜는 게 제일 어려운 것 같다. 아래는 Lazy Loading, fetchJoin(), BatchSize에 대해 내가 정리한 글이다.https://yskisking.tistory.com/316 JPA 쿼리 최적화 - Lazy loading, fetchJoin(), BatchSize개인 프로젝트 썬카에서 차량 상세 조회 기능을 만들다가 쿼리 최적화 문제에 부딪혔다.무려 10개의 엔티티를 전부 조회해야 했고 성능 부분을 신경쓰지 않을 수 없었기에, 자연스럽게 Lazy loadingyskisking.tistory.com..

차량 판매등록 기능은 카히스토리 api를 사용해 받아온 데이터를 등록해야 하지만, api를 아직 도입하지 못해서(너무 비싸..) 임시로 더미 데이터를 입력하는 방식으로 구현했다. 해당 기능은 인터페이스를 통해 구현된 facade 서비스 클래스에 존재하는데, 기존엔 배포용 차량 판매등록 기능과 더미 데이터 판매등록 기능이 하나의 인터페이스에 공존하고 있었고, 그것을 두개의 구현체로 구현했었다. 배포 때는 배포 판매등록 기능, 개발 때는 더미 판매등록 기능이 이용 되어야 하며, 두 기능은 하나의 환경에서 동시에 사용되지 않아야 한다. 따라서 하나의 인터페이스에서 파생된 두 구현체는, 사용되지 않는 메서드까지 상속받아 무의미하게 구현하고 있는 상태였다( ISP 위반 ). 또한 두 구현체는 같은 부모 인터페이스..

차량 판매등록 기능을 구현하며 객체지향적 설계를 한 것에 대해 정리해 보고자 한다. 차량 등록에 필요한 엔티티는 10개이며, 판매되는 자동차 1대가 10개 엔티티의 데이터를 전부 필요로 한다. 현재 차량 정보를 조회하는 카히스토리 api는 도입하지 않았기 때문에(너무 비싸..) 도입했다는 가정 하에 api 리턴값과 동일한 형태의 테이블을 설계했고, 그에 맞는 더미 데이터 생성 로직을 작성했다. 그 더미 데이터를 이용해 차량 등록 기능을 구현해 보았다. 다만 엔티티가 너무 많았기 때문에 코드가 길어졌고, 하나의 서비스 클래스에 이 모든 로직을 (엔티티 저장, dto변환, 더미데이터 생성 등) 담는 건 매우 좋지 않은 설계라고 생각되었다. 따라서 각 엔티티별 서비스 클래스에 create 메서드를 각각 만들고..

차량 판매등록 기능을 구현하는데, 차량 관련 엔티티 10개에 대한 반복적인 작업을 해야 했다.각 엔티티 만들고, 서비스 인터페이스 + 구현체 만들고, DTO 만들고... 전부 하나하나 일일이 해야 했다. 최대한 효율적으로 작업할 수 있는 방법은 없을까 많이 고민했지만, 엔티티 자체가 많은 거라 어쩔 수 없이 반복작업이 필요한 부분이었다. 그래도 유지보수성을 조금이라도 올리기 위해, facade 서비스 클래스를 따로 만들어서 여러 엔티티를 거치는 비즈니스 로직은 여기서 처리하고, 나머지 각 엔티티 별 서비스에서는 최대한 단일 책임 원칙(SRP)을 지켜 해당 엔티티에만 영향을 주는 로직을 작성하기로 했다. 그러나 정말 무의미하다고 느껴졌던 부분이, DTO 엔티티를 변환하기 위한 팩토리 메서드를 작성할 때였..