Backend/Spring Boot

이번 시간엔 내가 직접 만들고 있는 프로젝트 코드를 보면서 Request DTO부터 Response DTO까지 프로덕션 레벨 코드로 직접 보면서 흐름을 파악해 보는 시간을 가져보겠다. 이 글에서 다룰 내용은 다음과 같다.Request DTO의 역할과 유효성 검증Controller의 책임과 경계Service의 비즈니스 로직 처리Entity의 역할과 JPA 매핑Repository의 데이터 접근 계층Response DTO로 안전하게 데이터 반환전체 데이터 흐름의 시각화 계층형 아키텍처 스프링부트의 전형적인 3 티어 아키텍처는 이렇게 된다.┌─────────────────────────────────────────────────┐│ Presentation Layer ..

이번 시간엔 직렬화/역직렬화를 이해하고 DTO 중심으로 파헤쳐보는 시간을 가질 것이다. 직렬화는 객체 -> JSON으로, 역직렬화는 JSON -> 객체로 변환하는 과정이다. 이번 시간엔 1. 직렬화/역직렬화의 개념 2. Jackson의 내부 동작 원리 (Reflection) 3. Spring MVC에서의 자동화 (HttpMessageConverter) 4. 실무 DTO 패턴 (보안, 성능, 유지보수) 이 내용들을 다룰 것이다. 직렬화/역직렬화란? 직렬화는 spring만의 개념은 아니다. 자바 1.1 부터 존재했던 메모리 객체를 바이트 스트림으로 변환하는 기능이다. 자바 메모리에 존재하는 객체를 전송하거나 저장할 수 있도록 ‘0과 1(바이트)’로 변환하는 과정이다. 객체 -> 바이트 스트림...

공부를 하다 보면 왜 요즘 프로젝트엔 옛날과 다르게 DAO가 없고 Repository만 있을지 궁금증을 한 번쯤 가져봤을 거라고 생각한다. 오늘은 자바 진영에서 데이터 접근 계층이 어떻게 진화해왔고 왜 Repository가 표준이 되었는지 파헤쳐보는 시간을 가져보겠다. DAO 이전의 암흑기 2000년대 초반, Java 웹 개발은 JSP와 JDBC의 세상이었다. 그 시절 코드를 보자. " + rs.getString("name") + ""); } rs.close(); stmt.close(); conn.close();%> 저 시절엔 여러 문제점이 있었다. 비즈니스 로직과 DB 로직이 뒤섞임 -> 유지보수 지옥 SQL Injection 취약 -> 보안 리스크 Connection ..

Java 백엔드 개발을 하다 보면 DTO를 매일 마주한다. 컨트롤러와 서비스, 서비스와 리포지토리 사이에서 데이터를 주고받거나 API 요청/응답을 처리할 때 DTO는 사실상 필수 도구이다. 이전까진 record가 불변이다 뭐다 정돈 알고 있었는데 이번에 해커톤 개발을 하면서 dto 작업에 신경을 적게 쓰고 싶다는 생각이 들어서 다음 프로젝트부턴 도입해보려고 한다. Java 16부터 정식 도입된 record는 DTO의 정의 방식을 많이 바꿔놓았다. 얼핏 보면 비슷해보이는데 실제론 코드 작성량, 불변성, 확장성 등 여러 측면에서 차이가 있다. 그렇다면 Record가 기존 클래스와 어떤 것이 다르고 어떤 차이가 있는지 알아보자. 클래스 DTO 전통적으로 DTO는 대부분 클래스로 정의한다. public cla..

최근 해커톤을 진행하면서 습관 관리 앱을 개발하였다. 어려운 문제가 아니더라도 내가 직접 해결한 문제들은 가끔 이렇게 회고 식으로 글을 쓸 생각이다. 이런 식으로 피그마를 짰는데 로직을 구현하고 테스트를 해보니까 이번 주는 운동을 3번밖에 안했는데 AI는 잘했다고 하고 대시보드에는 완료율이 30%인 데이터 일관성 문제가 생겼다. 실제 데이터만으로 시연하기엔 어려움이 있어서 일주일치 더미 데이터를 미리 넣어뒀는데 대시보드에선 실제 DB 데이터를 사용하고 AI 분석엔 시연용 더미를 사용해서 완전히 다른 분석 결과가 나왔다. 딱 저번 주만 더미를 넣어서 풍부한 정보를 보여주고 이번주는 실제 데이터를 받아서 일관성 있는 답을 받게 해야 하는데 프로필마다 이게 맞지 않았다. // 대시보드 서비스public ..

러닝 앱 백엔드를 개발하면서 JWT 토큰 발급, 카카오 OAuth, 복잡한 보안 설정을 매번 거쳐서 API를 테스트하기엔 너무 번거로웠다. 특히 @AuthUser AuthenticatedUser user 파라미터를 사용하는 Controller들을 테스트할 때마다 실제 JWT 토큰을 만들어야 하는 상황이었다. 따라서 메인 로직은 건드리지 않으면서 테스트만을 위한 postman 프로필을 만들어 Mock 인증으로 우회하는 방법을 사용했다. 겪으면서 알게 된 것들이 꽤 있으므로 공유해보겠다. 구조📁 config ├── SecurityConfig.java (메인 보안 설정 - JWT 기반) ├── SecurityConfigPostman.java (테스트용 보안 설정 - Mock 기반) ├── Web..

프로젝트 진행하면서 프론트와 같이 카카오 로그인을 진행했는데 자꾸 KOE006과 KOE303 에러가 떴다. 생각보다 어렵진 않지만 다들 한 번씩 겪는 문제 중에 나같은 케이스가 있을 거라고 생각되어 공유한다. 개발 환경Frontend: React Native (Expo)Backend: Spring Boot 3.5.4OAuth: 카카오 로그인네트워크: 학교 Wi-Fi 환경 처음부터 AWS를 활용하면서 우리 아키텍처상 EC2와 DB를 Private 서브넷에 두고, 블루/그린 배포까지 고려했기 때문에 NAT 게이트웨이 비용이 걱정됐다. 그래서 같은 와이파이 내에서 임시로 환경을 구성해 테스트했는데, 생각해보니 테스트 목적이라면 프리 티어로 퍼블릭 서브넷에 EC2를 만들고 EIP만 연결해도 충분했는데 괜히 더..

친구들을 보면 당연하게 DTO에 롬복으로 Getter Setter를 사용하길래 왜 사용하냐고 했더니 그냥 getter 사용하면 setter도 같이 쓰는게 습관이 됐다고 했다. POJO 스타일의 Java 객체 설계에선 getter와 setter가 한 쌍으로 사용되기 때문에 그렇게 생각할 수 있긴 한데 DTO에선 setter를 사용하지 않는 것이 더 좋은 설계 방법이다. 이제 알아보자. DTO의 정의와 역할 DTO는 시스템 내에서 계층 간 데이터 전송을 위해 사용되는 객체이다. 일반적으로 서비스 계층과 프론트엔드 또는 컨트롤러 간에 데이터를 전달할 때 사용된다, DTO는 복잡한 비즈니스 로직을 처리하지 않고 단순히 데이터를 담고 전달하는 전송용 객체이다. 예를 들어 사용자 정보를 다룰 때 User..