땃쥐네

이번 글에서는 서비스 전반의 예외를 전역수준에서 어떻게 처리하여, 클라이언트에게 응답으로 내려줄지 다뤄보겠습니다. 기본적으로 스프링 웹 애플리케이션을 작성해보시면 오류가 발생했을 때 스프링이 알아서 에러 응답을 작성해줍니다만, 스프링이 작성한 예외 응답은 우리가 통제할 수 없는 영역 밖입니다. 우리가 통제할 수 있는 예외 응답을 내려줄 수 있도록 해야하는데요. 이 부분을 다뤄보겠습니다.  사실 메시지/국제화 처리 및 커스텀 예외 등을 정의해둔 터라 예외 처리에 대한 기틀은 전부 지난 글들에서 다뤘습니다.결론만 내려보면 전역 예외처리는 @RestControllerAdvice 및 @ExceptionHandler 를 써주고, 필터쪽 설정만 살짝 해주면 되긴합니다. 그러나 이렇게만 작성하면 글 분량이 없어지고 ..

이번에 다룰 주제는 메시지/국제화 기능 및 API 응답 규격입니다.  (자바코드로 예외 메시지 내려주게 하는 방법 이미지) 사용자에게 응답을 내려줄 때 내려줄 메시지를 java 코드 상에 직접 작성하는 방법도 있긴 하지만, 이 방법은 다국어에 대해 열려있지 못 한 방식입니다. 그래서, java 코드 상에서는 메시지를 식별할 수 있는 code 를 관리하고 이 code를 기반으로 사용자 환경에 따라 제각각 다른 메시지를 내려줄 수 있게 하려고 합니다. 또 저는, API 응답 규격을 일관된 방식으로 내려주고자 하기 위해 API 응답 규격을 정해두려고 합니다. 1. 메시지/국제화1.1 MessageResolver 인터페이스 정의package com.ttasjwi.board.system.core.messagein..

1. Slf4j1.1 Slf4j 란?Slf4j 는 다양한 로깅 프레임워크(예: java.util.logging, logback, Log4j )의 퍼사드 역할을 합니다.실제 로깅 도구들에 대한 일반 API를 제공하고 로깅을 실제 구현과 독립적으로 만듭니다. 그래서 보통 스프링 개발자분들은 Slf4j 인터페이스를 의존하여 개발하고 구현체로는 logback 을 많이 사용합니다.실제로 스프링부트의 웬만한 starter 의존성을 추가하면 slf4j 의존성이 추가되고 기본 구현체로는 logback 이 사용됩니다. 1.2 파라미터화 로깅 (Parameterized Logging)/String variable = "Hello ttasjwi";logger.debug("Printing variable value: " + ..

이번 글에서는 자바/코틀린에서의 예외 개념을 한 번 짚고, 왜 제가 프로젝트에서 커스텀 예외를 정의했는 지, 어떤 식으로 사용했는지 설명해보도록 하겠습니다. 1. 예외 계층 커스텀 예외를 설명하기 전에 Java의 예외 계층을 설명해보겠습니다.제가 지금 사용하는 언어는 Kotlin 이지만 기본기는 Java 쪽에 있기 때문에 Java 기준으로 설명하겠습니다. Throwable은 모든 예외와 오류의 최상위 조상 클래스입니다.이 아래에는 Exception과 Error가 있습니다.Error는 주로 JVM 관련 오류나 시스템적인 문제로, 개발자가 예측하거나 처리하기 어려운 심각한 문제들입니다.예: OutOfMemoryError, StackOverflowError 등Exception 은 주로 개발자가 처리할 수 있는..

보통 프로젝트를 진행하다보면 A -> B -> C -> D -> E 와 같은 의존방향의 코드는 자주 작성됩니다. 이렇게 의존성의 방향을 알 수 있으면 뭐를 고쳐야할지 잘 보일거에요. 근데 의존성의 방향을 잘 못 관리한다거나, 계층을 넘어 의존하는 코드를 작성하면서 관리하다보면 위 그림처럼 B에서 E를 강하게 의존한 코드를 작성하게 되는 일이 생기고(특히 테스트 코드), E가 변경되면 D 뿐만 아니라 B의 코드를 변경하게 되는 일이 빈번하게 발생합니다. 무엇이 무엇을 의존하는지, 의존성의 방향은 어떤지 통제하기 힘들어지면 향후 코드 관리가 점점 힘들어집니다.  외부 모듈들을 테스트를 해보고 싶은데 모두 끌어와서 실행해야한다는 점도 저를 귀찮게 하는게 많았습니다.이메일 발송 라이브러리가 잘 작동되는 지 확인..

이번 글에서는브랜치가 푸시될 때마다 프로젝트 작업물이 EC2에 무중단으로 배포될 수 있도록 해보겠습니다.1. GitHub Actions 에 DockerHub / EC2 접근 자격증명 부여이전 글에서 지속적 통합을 GitHub Actions 를 통해 했듯, 지속적 배포 역시 GitHub Actions 를 통해 수행할 것입니다. 그런데 이전 글에서는 DockerHub, EC2 에 접근하는 작업을 하지 않았지만 이번에는 접근하는 작업을 해야합니다.제 DockerHub 에 도커 이미지를 push 한다거나, EC2 에 SSH 에 접속한다거나 하는 작업에 있어서는 몇 가지 자격증명이 필요합니다. 이것들을 우선적으로 준비해보겠습니다.  1.1 [GitHub Actions] DockerHub 액세스 토큰 준비  Git..

이전 글에서 AWS 전반적인 인프라 환경을 구성했습니다. 이번에는 프로젝트를 생성하고,풀리퀘스트에 커밋이 올라올 때마다 빌드테스트가 자동화되도록 하겠습니다.1. 스프링부트 프로젝트 생성, Git - GitHub - Jira 연동 프로젝트를 생성해보겠습니다. 일단은 간단하게 프로젝트를 생성하고, 구조를 바꿀 일이 있다면 이후 글에서 바꾸도록 하겠습니다. 이번 글에서는 배포 자동화에 초점을 맞추고 있기 때문에 복잡한 설정은 하지 않을겁니다. 1.1 스프링부트 프로젝트 생성 Intellij Ultimate 를 쓴다면 Spring Boot Initializr 지원 기능이 있으므로 그걸 써도 됩니다.근데 그렇지 않은 분들이 더 많은 것 같고 웹의 Spring Initializr 로 프로젝트를 생성했습니다.저는 자..

일단 프로젝트는 대충 어떤 기능을 구현할 지 정했는데, 이것을 어디에 배포할 지가 문제입니다.취준생 입장에서 비싼 돈을 지불해가면서 서비스를 배포하는 것은 감당이 안 되는 지라 AWS 프리티어 기능을 사용하기로 했습니다. AWS 프리티어는 1년동안 일정 사용량 내에서 기능을 무료로 사용할 수 있기 때문에 취준생 입장에서 사용하는데 큰 부담이 안 되더라구요.  일단 배포 기본 아이디어는 VPC 를 준비하고, 퍼블릭 서브넷에 EC2 를 한 대 둔 뒤EC2 내에 Nginx(도커 컨테이너)를 통해 들어오는 요청을 뒤의 스프링 서버(도커 컨테이너)로 포워딩 시키는 방식을 사용할 생각입니다.  첫번째로 구현할 스토리, 백엔드 인프라 구성(AWS EC2) 입니다. 대강 이 작업이 어떤 가치가 있는 지, 이 작업이 만..