해킹왕 양선규

객체 지향 프로그래밍(OOP)에서 지향해야 할 5가지 설계 원칙을 SOLID라고 칭한다. 개인 프로젝트를 시작하면서, 완벽하고 빈틈없는 코드를 짜겠다 라는 목표를 세웠다. 그러나 생각만 하는 것 보다는, 5원칙을 참고하여 좀더 명확한 목표를 잡고 프로그래밍 하는 것이 낫겠다고 느꼈다. 지금까진 SOLID 원칙이 중요하다고 지나가듯이 들었던 말들 뿐이었는데, 이번에 제대로 공부해보며 어째서 중요한 것인지 이해할 수 있었다.  5원칙 중에는 나도 모르게 이미 적용하고 있던 것들도 있었고, 하긴 하는데 왜 하는지는 모르는 것도 있었고, 아예 모르는 것도 있었다. 실무 가서 일하다 보면 혼나고 깨지면서 자동으로 이 5원칙에 따라 코드를 짜게 된다던데, 지금부터 미리 5원칙을 이해하고 코드를 설계할 수 있다면 큰..

스프린트 2가 종료되었다. 6일이 걸렸으니 스프린트 1에 비해 3배는 빨리 끝났다.당연한 거겠지만 환경설정과 학습 시간이 빠지고, 기능 구현에만 집중하니 작업이 훨씬 빨랐던 것 같다.스프린트 2에서 구현한 기능은 아래와 같다.마이페이지 조회마이페이지 내 정보 수정판매중인 차량 목록 조회 프론트와 백엔드를 함께 진행하며 느낀건데, 확실히 백엔드가 좀 더 논리적으로 생각할 게 많은 것 같다. 물론 내가 백에 좀 더 신경을 쓰고 있는 것도 사실이지만, 백 로직을 생각하는 것이 3배는 머리아픈 것 같다. 백은 깊고, 프론트는 넓은 것 같다고 느꼈다. 개인적인 생각이다. 프론트엔드에서 어려웠던 점 - 다양하고 자잘한 이슈들마이페이지 조회와 내 정보 수정 기능은 백에서는 아주 수월했다. 쉽게 구현할 수 있었다. 하..

신뢰성이 중요한 중고차 거래에 필요한 차량 정보를 담기 위해서는 꽤 많은 테이블이 필요했다.차량 목록 조회 기능을 구현하는 것에만 5개의 테이블이 엮여있었고, 5개 테이블을 전부 조인해서 데이터를 가져와야 했다. 썬카는 차량 한대 당 메인 이미지 1개와 나머지 이미지들이 존재하며, 대표 이미지 여부는 is_primary 필드로 구분된다.메인 이미지는 가장 먼저 화면에 보여야 하기 때문에, 나머지 이미지들과 dto 별도의 필드에 담길 필요가 있었다.따라서 처음엔 메인 이미지를 조회한 후 나머지 이미지를 추가로 조회하는 방식으로 진행했었는데, 이 과정에서 N + 1 문제가 발생했다. N + 1문제- 최초 1번의 쿼리로 N개의 레코드를 조회한 후, 추가로 N개의 쿼리를 실행하게 되는 상황- 자동차가 10대라면..

백엔드로써 프론트엔드와 협업하기 위해, 커뮤니케이션 비용을 줄인 효율적인 업무를 위해 API 명세서는 반드시 필요하다고 할 수 있다. 명확하게 정리된 API 명세서가 있다면 프론트엔드는 해당 자료를 참고하여 좀 더 수월하게 작업할 수 있고, 서로 엇갈려 불필요한 오류를 맞이할 일도 줄어든다.  1. 의존성 추가// build.gradledependencies { // 생략.. implementation 'org.springdoc:springdoc-openapi-starter-webmvc-ui:2.8.0'} build.gradle에 swagger 사용을 위한 springdoc-openapi 의존성을 추가한다. 단 여기서 스프링 부트 버전과 openapi 버전이 반드시 호환되어야 한다.각 스프링 부트 버전마..

# application.propertiesspring.application.name=suncar# DBspring.datasource.url=jdbc:mysql://localhost:3307/suncarspring.datasource.username=rootspring.datasource.password=0000spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driverspring.jpa.hibernate.ddl-auto=updatespring.jpa.show-sql=true# JWTjwt.secret=BTpHjyFDurb0PefLrKP+e4vKKwNCw+rUoMEpQjde7T6EzB9QjtoqC7MFVcHwbFPr+r4/OlR9ZiB5rpG0axOd4Q..

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

매 요청마다 인가된 사용자가 요청하는 것인지 확인하기 위하여, 로그인 성공 시 JWT Access Token을 발급하고 사용자 요청 시 마다 토큰을 함께 전달받아 검증하는 로직을 추가하기로 했다. Spring Boot에서 JWT Access Token의 발급 및 검증은 Spring Security를 이용해 구현할 수 있다. 근데 생각보다 많이 복잡했다. Spring Security- Spring 기반 애플리케이션의 인증(Authentication)과 인가(권한 부여, Authorization)를 위한 보안 프레임워크 Spring Security - 특징- 포괄적인 보안 기능 : 인증, 권한 부여, 세션 관리, CSRF 보호 등 다양한 보안 기능 제공- 필터 체인 아키텍처 : 들어오는 HTTP 요청은, 여..

중고차 거래 플랫폼은 가치가 큰 물건을 거래하는 만큼 신뢰성 있는 데이터가 중요하기에, 실제로 데이터를 삭제하지 않고 논리적으로만 삭제하는 Soft delete 방식이 적합하다고 생각했다. 실수로 데이터가 삭제되어도 쉽게 복구할 수 있기 때문에 데이터 관리와 안정성이 중요한 경우 적합한 방식이라고 할 수 있다. Soft delete- 데이터베이스에서 레코드를 물리적으로 삭제하지 않고, 논리적으로 삭제된 것처럼 표시하는 기술- 일반적으로 테이블에 is_deleted 등의 필드를 추가하여 삭제된 상태를 표시한다. Soft delete - 필요성- 안전한 데이터 관리 : 우발적인 데이터 손실 방지- 데이터 복구 용이성 : 필요시 간단히 플래그만 변경하여 복구 가능- 유연한 데이터 접근 : 필요에 따라 삭제된 ..

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

비즈니스 로직에서 발생하는 모든 예외를 캐치하고 일관된 형태로 응답하기 위해서, 전역 핸들러와 커스텀 예외를 구현했다.예외 처리 로직을 비즈니스 로직으로부터 분리할 수 있고, 클라이언트는 일관된 형태의 예외를 응답받기 때문에 예외에 대한 처리를 유연하게 할 수 있게 된다.  예외 전역 핸들러(Global Exception Handler)- 애플리케이션에서 발생하는 모든 예외를 일관되게 처리하는 메커니즘- Rest api를 구현한 Spring Boot에서는 @RestControllerAdvice 어노테이션으로 이를 구현한다. 예외 전역 핸들러 - 필요성- 코드 중복 제거 : 각 서비스마다 예외 처리 로직을 반복할 필요 없음, try-catch 블록 최소화- 일관된 오류 응답 : 모든 API에서 일관된 형태..