공부하자

• [Spring] API Key를 이용한 인증 처리 로그인 이후 인증을 유지하기 위해 프론트엔드에 아이디와 비밀번호를 저장하는 것은 적절하지 않다.특히 비밀번호는 매우 민감한 정보이기 때문에 가능한 한 클라이언트에서 계속 가지고 있지 않는 것이 좋다.REST API는 기본적으로 무상태성(Stateless)을 지향한다.즉, 서버가 클라이언트의 상태를 계속 저장하고 관리하기보다는 각 요청에 필요한 인증 정보를 클라이언트가 전달하는 방식을 사용한다.따라서 다음과 같은 방식으로 인증 정보를 전달할 수 있다.대신 아이디와 비밀번호를 직접 전달하지 않고, 인증을 위한 별도의 무작위 값인 API Key를 사용하는 방식으로 개선할 수 있다.2. API Key 발급회원이 생성될 때 UUID를 이용해 API Key를 생성한다.@Entity@Getter@NoArgsConst.. 2026.09.01
• [Spring] 예외 처리 | ServiceException과 전역 예외 처리 1. 예외가 많아질 때 발생하는 문제서비스를 구현하다 보면 다양한 예외 상황이 발생한다.예를 들어 로그인만 하더라도 다음과 같은 경우가 있을 수 있다.상황예외아이디가 존재하지 않음NotFoundUsername비밀번호가 일치하지 않음MismatchPassword블랙리스트 사용자BlacklistUsername인증 대기 상태NotAuthentication예외 상황마다 별도의 클래스를 만드는 것이 정석적인 방법이 될 수 있다.하지만 작은 프로젝트에서 모든 예외 케이스마다 클래스를 만드는 것은 오히려 복잡도를 높일 수 있다.따라서 프로젝트 규모에 따라 적절한 예외 처리 방식을 선택할 필요가 있다.2. RsData를 이용한 응답 형식RsData는 API 응답을 일정한 형식으로 전달하기 위해 사용하는 클래스이다.pu.. 2026.09.01
• 1차 프로젝트 회고 8월 24일부터 31일까지 프로그래머스 1차 프로젝트를 진행했다.모든 팀이 동일한 주제로 프로젝트를 진행했기 때문에, 같은 요구사항을 어떻게 설계하고 구현하는지가 중요했다.이번 프로젝트에서 나는 공통 예외 처리, 주문 내역 조회 및 페이지네이션, 이메일 기반 주문 조회, 이메일 확인 기능, 상품 검색 기능을 담당했다.공통 예외 처리프로젝트 초반에는 여러 API에서 발생하는 예외를 일관된 형태로 처리할 수 있도록 공통 예외 처리 구조를 구현했다.ApiException을 만들어 HTTP 상태 코드와 에러 코드를 함께 관리하고, GlobalExceptionHandler에서 해당 예외를 한 곳에서 처리하도록 구성했다. 클라이언트에는 code, message, timestamp를 포함한 ErrorResponse를.. 2026.09.01
• 백엔드 데브코스 12기 36일차 이 날은 프로젝트 발표를 진행한 날이었다. 내가 발표를 맡게 되어 주말부터 발표 준비를 계속해서 진행했다.1. 발표 자료 수정주말 동안 PPT를 계속 읽어보면서 우리 팀이 실제로 구현한 기능과 구현하지 않은 기능을 하나씩 확인하고 수정했다. 처음에는 만들어둔 발표 자료를 그대로 사용하면 될 것 같았지만, 내용을 다시 살펴보니 실제 구현 내용과 조금 다르게 작성된 부분도 있었고, 발표에서 추가로 설명하면 좋을 기능들도 있었다.그래서 어떤 기능을 발표에 포함하면 좋을지 계속 고민하면서 팀원들에게 자료 수정을 요청했다. 발표 자료는 한 사람이 만드는 것이 아니라 팀에서 실제로 개발한 내용을 정확하게 담아야 하기 때문에, 각 기능을 담당한 팀원들에게 구현 내용을 확인하면서 수정하는 과정이 필요했다.디자인도 여러.. 2026.08.31
• 백엔드 데브코스 12기 35일차 이 날은 카페 메뉴 관리 서비스의 주문 조회와 상품 검색을 중심으로 기능을 개선하고, 오후에는 발표 자료를 준비한 날이었다. 처음에는 주어진 요구사항에 맞게 기능을 구현하는 데 집중했지만, 개발을 진행하면서 실제 사용자의 입장에서 불편한 부분을 발견하고 이를 개선하는 경험을 할 수 있었다.특히 상품 검색 기능 개선, 주문 목록 정렬, 상품 목록 페이지네이션 및 UI 개선을 진행하면서 단순히 API를 구현하는 것보다 프론트엔드와 백엔드가 실제 서비스에서 어떻게 연결되는지 고려하는 것이 중요하다는 것을 배울 수 있었다.1. 상품 검색 기능 개선가장 집중해서 개선한 기능은 상품명 검색이었다.기존 상품 검색은 사용자가 상품명을 정확하게 입력해야 검색되는 방식이었다. 하지만 실제 서비스를 사용하는 입장에서는 상품.. 2026.08.30
• 백엔드 데브코스 12기 34일차 주문 및 상품 관리 기능 개선과 배포이번 작업에서는 주문 취소 기능을 실제 DELETE API와 연동하고, 상품 목록의 서버 사이드 페이지네이션과 검색 기능을 구현했다. 또한 기능 구현을 마무리한 후 Railway에 프로젝트를 배포하면서 실제 서비스 환경에서 발생하는 오류를 해결하는 경험까지 할 수 있었다.백엔드 구현상품 검색 API 리팩토링상품명 검색 기능을 추가하기 위해 기존 상품 목록 조회 API를 리팩토링했다. 검색 조건을 동적으로 적용하기 위해 Spring Data JPA의 Specification을 활용했다.검색어가 입력되지 않았거나 공백만 입력된 경우에는 검색 조건을 적용하지 않고 전체 상품을 조회하도록 처리했으며, 검색어가 입력된 경우에는 like를 사용해 상품명에 검색어가 포함된 상품을 .. 2026.08.27
• Spring Boot 프로젝트 Railway 배포하기 + 배포 과정에서 발생한 오류 해결 1. Railway를 이용한 Spring Boot 배포이번 프로젝트에서 작성한 Spring Boot 서버를 실제 서버에 배포하기 위해 Railway를 사용했다.프로젝트 구조는 다음과 같이 프론트엔드와 백엔드가 하나의 GitHub Repository에 함께 존재하는 형태였다.project/├── backend/│ ├── build.gradle│ ├── gradlew│ └── src/│├── frontend/│ ├── package.json│ └── ...│└── README.md Railway에서 GitHub Repository를 연결한 뒤 배포를 시도했는데, 처음부터 몇 가지 오류가 발생했다.2. Railway가 프로젝트를 인식하지 못하는 문제발생한 오류처음 배포했을 때 다음과 같은 오.. 2026.08.27
• 백엔드 데브코스 12기 33일차 주문 조회 기능 구현이번 작업에서는 주문 조회 기능을 개선하면서 백엔드 API 구현부터 프론트엔드 페이지 구현 및 API 연동까지 하나의 기능을 전체적으로 구현해보았다. 특히 이메일을 입력해 주문 내역을 조회하는 과정과 동적인 페이지네이션을 직접 구현하면서 백엔드와 프론트엔드가 API를 통해 어떻게 연결되는지 경험할 수 있었다.백엔드 구현기존 주문 조회 API는 페이지별 주문 목록만 반환하고 있어 프론트에서 전체 페이지 수를 알 수 없었다. 이 때문에 프론트에서 페이지네이션 개수를 임의로 정해야 하는 문제가 있었다.이를 해결하기 위해 Page의 getTotalPages()를 활용하고, totalPages와 주문 목록을 함께 반환하는 OrderListResponse DTO를 추가했다. 이를 통해 프론트에서.. 2026.08.26
• 백엔드 데브코스 12기 32일차 오늘은 팀원들이 각자 구현한 CRUD를 하나로 합치는 작업을 진행했다. 이 과정에서 Git 충돌을 해결하는 데 어려움이 있었지만, 각자의 Pull Request를 2명 이상이 리뷰하도록 하면서 수정할 부분이 없는지 확인하고 코드를 개선할 수 있었다. 팀원들의 피드백을 통해 혼자 개발할 때 놓칠 수 있는 부분을 발견하고 수정하는 데 많은 도움을 받았다. Postman으로 API를 직접 테스트하면서 요청과 응답을 확인하니 API 테스트가 훨씬 수월했다. 백엔드에는 CORS를 추가하고, 기존에 구현한 주문 내역 리스트 API를 프론트와 연결했다. 또한 기존에는 모든 주문 내역을 반환하도록 구현했지만, 실제 사용자의 입장에서는 본인의 주문 내역만 확인할 수 있어야 한다고 생각해 이메일별 주문 리스트를 반환하는 .. 2026.08.25