해킹왕 양선규

일반적인 배포는 많이 해 봤지만, 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, 카테시..

기능 명세서 단위로 봤을 때, 구현한 기능은 2개 뿐이다. 로그인 그리고 회원가입.무슨 이거 2개 만드는데 3주나 걸렸냐 싶겠지만, 진짜 오래 걸린 것 맞다. 처음 진행하는 개인 프로젝트다 보니 생각보다 기능구현 외에 할 일이 정말 많다는 것을 느꼈다.회사에서 잠깐 일을 했더라도, 전부 짜여진 코드의 틀 위에서 약간의 기능 추가와 수정, 관리 정도였고.. 아예 환경세팅부터 시작하는 것은 처음이었으니 그럴 만도 하겠다. 지난 3주를 돌아보면 나는 단 하루도 쉰 날이 없는데 왜 이렇게 지체되었을까 라는 의문이 든다.아침에 일어나 운동을 갔다오고, 밥 먹고 하루종일 컴퓨터 앞에만 앉아있는데 말이다. 뭐 예비군도 갔고, 가끔 술도 마셨고 그러긴 했지만 그건 큰 핑계가 되지 못한다. 3주는 너무 길다.기간이 지체..

JPA는 기본적인 CRUD 메서드들을 다양하게 지원하지만, 테이블 간 조인이 복잡하거나 동적 쿼리가 필요한 경우엔 사용하기 어렵다. @Query나 JPQL을 이용해 쿼리를 작성하면 문자열 조합이 필요하기 때문에 오류 가능성이 높아진다. 따라서 안전한 쿼리를 만들기 위해 QueryDSL을 도입했다. QueryDSL- Spring Boot에서 타입 안전한 쿼리를 생성할 수 있게 해주는 프레임워크- Java 코드를 사용하여 SQL, JPQL, MongoDB 쿼리 등 다양한 쿼리를 작성할 수 있게 함- 특히 JPA와 함께 사용될 때 강력한 기능을 발휘 QueryDSL과 타입 안전성의 관계- 타입 안전성 : 코드(쿼리)에서 사용되는 데이터가, 그 데이터에 적합한 타입으로만 보장하는 특성. (숫자는 숫자로, 문자열..

시작 단계에서의 내가 지향하는 프로젝트의 방향성적은 기능을, 완벽하고 확실하게 구현하기다양한 상황을 고려한 예외 처리테스트 코드 작성실무에서 사용되는 코드와 최대한 비슷하게 구현하기유지보수성 생각하기재사용성확장성가독성 ( 코드 컨벤션, 주석, 변수명 등 )왜 개인 프로젝트를 시작했는가?나는 백엔드다.아직까지 개인 프로젝트를 한 번도 해 보지 않았다.한 번쯤은 프론트, 백엔드 그리고 프로젝트의 시작과 끝까지 모든 것을 혼자 해결하며 프로젝트 흐름을 이해하고 싶었다.그래서 개인 프로젝트를 하기로 결정했다.실무에서 많이 사용되는 RestAPI 방식으로 진행하고 싶었다.그래서 템플릿 엔진을 사용하는 SSR 방식이 아닌, Vue를 사용한 프론트엔드를 따로 분리하여 직접 작업하기로 했다.왜 중고차 거래 플랫폼인가?..