ssibongee/freelec-springboot2-webservice

스프링 부트와 AWS로 혼자 구현하는 웹 서비스

Ahn Siwon @ssibongee

Hello, I am a server developer who enjoys tackling complex business problems through code.

Currently, I am working at Toss Place, a company at the forefront of innovating offline payments in Korea.

At Toss Place, we are seeking colleagues to join us in revolutionizing the offline payments industry. We would be delighted if you could join us.

Experience

Server Developer at Toss Place  _{(Full-time, Jan 2023 ~)}

Server Developer at Channel Corp  _{(Full-time, Aug 2021 ~ Dec 2022)}

freelec-springboot2-webservice's Issues

머스테치로 화면 구성하기

1. 템플릿 엔진

• 템플릿 엔진이란 지정된 템플릿 양식과 데이터가 합쳐져서 HTML 문서를 출력하는 소프트웨어를 의미하며 크게 서버 템플릿 엔진과 클라이언트 템플릿 엔진으로 나누어진다.
• JSP, Freemarker 등을 서버 템플릿 엔진이라고 하며 Vue, React 등이 클라이언트 템플릿 엔진에 해당한다.
• 서버 템플릿 엔진과 클라이언트 템플릿 엔진의 코드가 실행되는 영역에 차이가 있는데 서버 템플릿 엔진을 이용한 화면 생성은 서버에서 자바 코드로 문자열을 만든 뒤 이를 HTML로 변환하여 브라우저로 전달하며 이 때 자바스크립트 코드는 단순 문자열로 취급한다.
• 자바스크립트는 브라우저 위에서 동작하며 자바 스크립트가 실행되는 장소는 서버가 아닌 브라우저이기 때문에 브라우저에서 작동될 때 서버 템플릿 엔진의 손을 벗어나 제어가 불가능하다.
• Vue, React를 이용한 SPA는 브라우저에서 화면을 생성하며 이미 코드가 서버에서 벗어난 경우이기 때문에 서버에서는 JSON 혹은 XML 형식의 데이터만 전달하고 클라이언트에서 조립한다.
• 최근에는 React, Vue 같은 자바스크립트 프레임워크에서 서버사이드 랜더링을 지원한다.

2. 머스테치

• 머스테치는 수 많은 언어들을 지원하는 가장 심플한 템플릿 엔진이다.
• 머스테치는 다른 템플릿 엔진보다 심플하며, 로직 코등를 사용할 수 없어 View의 역할과 서버의 역할을 명확하게 분리한다.
• 머스테치는 자바스크립트와 자바 두 가지가 모두 있기 때문에 하나의 문법으로 클라이언트와 서버 템플릿을 모두 사용가능하다.
• 템플릿 엔진은 화면의 역할에만 충실하는 것이 좋기 떄문에 너무 많은 기능을 제공하면 API와 템플릿 엔진, 자바 스크립트가 서로 로직을 나누어갖게되어 유지보수가 힘들어진다.

3. JPA에서 복잡한 쿼리 수행

• JPA에서 엔티티 클래스나 Spring Data JPA에서 제공하는 기능만으로는 처리하기 어렵기 때문에 별도의 프레임워크를 사용하여 쿼리를 작성한다.
• 대표적으로 QueryDsl, Jooq, MyBatis 등이 있으며 조회는 위의 프레임워크 중 하나를 선택해서 수행하고 등록, 수정 및 삭제는 Spring Data JPA를 통해 진행한다.
• 이 중에서 잘 사용되는 프레임워크는 QueryDsl인데 QueryDsl은 다음의 장점들이 존재한다.
• 타입 안정성이 보장된다 : 문자열로 쿼리를 생성하는 것이 아닌 메서드 기반의 쿼리를 생성하기 때문에 오타나 존재하지 않는 컬럼명을 명시할 경우 IDE에서 컴파일 타입에 오류를 발견할 수 있다.
• 여러 회사에서 사용하고 있으면 이러한 이유때문에 많은 회사와 개발자들이 사용하고 있기때문에 국내 자료와 레퍼런스가 많다.

스프링 시큐리티와 OAuth2.0으로 로그인 기능 구현하기

1. 스프링 시큐리티

• 스프링 시큐리티는 막강한 인증(Authentication)과 인가(Authorization) 기능을 가진 프레임워크이다.
• 스프링 시큐리티는 스프링 기반의 애플리케이션에서 보안을 위한 표준이라고 볼 수 있으며 인터펩터, 필터 기반의 보안 기능을 구현하는 것보다 스프링 시큐리티를 통해 구현하는 것을 적극적으로 권장하고 있다.
• 스프링 프로젝트인 MVC, Data, Batch 처럼 확장성을 고려한 프레임워크이기 때문에 요구사항을 손쉽게 추가하고 변경할 수 있다.

2. 소셜 로그인

• 로그인을 직접 구현할 경우 배보다 배꼽이 더 커지는 경우가 많은데 이는 로그인 보안, 비밀번호 찾기, 변경, 회원가입시 이메일 및 전화번호 인증, 회원정보 변경 등 많은 것들을 직접 구현해야 한다.
• 소셜 로그인을 사용하면 이를 구글, 페이스북, 카카오,네이버 등의 서비스에 맡기면 되니 서비스 개발에 집중할 수 있다.

3. OAuth2

• 스프링 팀에서 기존 스프링 부트1.5에서 사용되던 spring-security-oauth 프로젝트는 유지 상태로 결정했으며 더 이상 신규 기능은 추가하지 않고 버그 수정 정도의 기능만 추가될 예정이며 신규기능은 oauth2 라이브러리에서만 지원하겠다고 선언하였다.
• 기존에 사용되던 방식은 확장포인트가 적절하게 오픈되어있지 않아 직접 상속하거나 오버라이딩 해야하고 신규 라이브러리의 경우 확장 포인트를 고려해서 설계된 상태이다.
• 스프링 부트 1.5 방식과 스프링 부트 2.0 방식의 설정에는 차이가 존재하는데 1.5 버전에서는 url 주소를 모두 명시해야하지만 2.0에서는 클라이언트 인증정보만 입력하면 된다.
• 1.5 버전에서는 직접 입력했던 값들은 2.0 버전으로 오면서 모두 enum으로 대체되었으며 CommonOAuth2Provider 라는 enum이 새로 추가되어 구글, 깃허브, 페이스북, 옥타의 기본 설정값들은 모두 여기서 제공하게 된다.
• 하지만 이외에 네이버, 카카오와 같은 다른 소셜 로그인을 추가한다면 직접 다 추가해주어야 한다.

테스트코드 작성하기

1. 단위테스트와 TDD

• TDD (Test Driven Development)은 테스트가 주도하는 개발을 의미하며 다음의 TDD 사이클에 입각하여 테스트 코드를 작성하는 것으로 개발을 시작한다.
  • 실패하는 테스트를 작성한다
  • 테스트가 통과하는 프로덕션 코드를 작성한다.
  • 테스트가 통과하면 프로덕션 코드를 리팩토링한다.
• 단위테스트는 TDD의 첫번째 단계인 기능 단위의 테스트코드를 작성하는 것을 의미한다.
• TDD와 달리 테스트 코드를 꼭 먼저 작성해야하는 것도 아니고 리팩토링 또한 포함되지 않은 순수한 테스트 코드를 작성하는 것을 의미한다.

2. 테스트 코드를 작성해야하는 이유

• 단위 테스트는 개발 초기에 문제를 발견하게 도와준다.
• 단위 테스트는 나중에 코드를 리팩토링하거나 라이브러리를 업그레이드 하는 등의 상황에서 기존의 코드가 올바르게 동작하는지 확인할 수 있다.
• 단위 테스트는 기능에 대한 불확실성을 감소시킨다.
• 단위 테스트는 시스템에 대한 실제 문서를 제공한다.

3. 기존의 수동 테스트가 가지고 있는 단점

• 서버를 실행하고 API 테스트 도구를 사용하여 요청을 보내고 요청결과를 눈으로 검증하는 과정을 매번 반복해야 한다.
• 사람이 직접 눈으로 검증을 해야 한다.
• 새로운 기능이 추가되었을 때 기존의 기능이 정상적으로 동작하는지 보장할 수 없다.

테스트 코드는 위의 단점을 모두 해결해주기 때문에 개발자는 더이상 테스트를 위해 서버를 시작하고 종료하는 행위를 반복하거나 눈으로 수동 검증을 하거나 새로운 기능을 추가할 때마다 기존의 기능을 다시 하나하나 테스트할 필요가 없다.

프로젝트에 JPA 적용하기

1. 프로젝트에 JPA를 적용해야 하는 이유

• 기존에는 MyBatis와 같은 SQL 매퍼를 이용해 데이터베이스 쿼리를 작성했다.
  • 데이터 테이블 중심의 개발과 객체지향의 패러다임 차이 때문에 다음의 문제들이 발생한다.
  • 실제로 개발을 하는 시간보다 SQL을 작성하는 시간이 많다.
  • 객체 모델링보다는 테이블 모델링에만 집중하고 객체를 단순히 텡티블에 맞추어 데이터 전달의 역할만 하는 기형적인 형태의 개발이 이루어진다.
  • 결국, 객체지향을 객체지향 답게 사용하지 못하고 테이블 중심의 개발이 이루어진다.

2. 데이터베이스 테이블 중심의 설계의 문제점

• 수백개 수천개의 테이블에 대한 SQL을 작성하는 단순 반복 작업을 수백번 반복해야 한다.
• 데이터베이스는 어떠헥 데이터를 저장할지에 대한 초점이 맞춰진 반면 객체지향은 메세지를 기반으로 기능과 속성을 한 곳에 관리하는 기술이라는 패러다임의 불일치가 발생한다.
• 상속 등의 다양한 객체 모델링을 데이터베이스에서 구현할 수 없기 때문에 점차 데이터 베이스 모델링에만 집중하게 된다.
• 결국 SQL에 종속적인 개발이 이루어진다.

3. ORM과 JPA의 역할

• ORM은 객체지향과 관계형 데이터베이스 사이에서 둘의 패러다임을 일치시켜주기 위한 기술이다.
• 개발자는 객체지향 프로그래밍을하고 ORM기술을 통해 관계형 데이터베이스에 맞게 SQL을 대신 생성한다.
• SQL에 종속적인 개발로부터 벗어나고 객체 중심의 개발을 통해 생산성과 유지보수성이 향상된다.

4. Spring Data JPA

• JPA는 인터페이스로서 ORM 기술에 대한 자바 표준명세서이며 이를 사용하기 위해서는 구현체가 필요하며 대표적으로 Hibernate를 구현체로 사용한다.
• Spring Data JPA는 구현체들을 좀 더 사용하기 쉽게 추상화시킨 모듈이다.
• Spring Data JPA를 사용함으로써 구현체에 대한 추상화를 제공하는데 이는 곧 Hibernate 이외에 다른 구현체로 손쉽게 교체할 수 있다는 것이다.
• 뿐만아니라 Spring Data JPA는 다른 데이터베이스로 교체를 용이하게 해준다 만약 대규모 트래픽이 발생하여 더이상 관계형 데이터베이스로 처리가 불가능하여 MongoDB와 같은 NoSQL로 변경해야 한다면 Spring Data MongoDB로 의존성만 교체해주면 된다.

5. JPA 테스트 작성하기

• 기존에 사용하던 @WebMvcTest의 경우 JPA기능이 작동하지 않고 Controller, ControllerAdvice 등의 외부 연동과 관련된 부분만 활성화된다.
• JPA기능까지 테스트를 할 때에는 @TestRestTemplate을 이용해야 한다.

6. 기존의 Date와 Calander 클래스의 문제점

• 불변 객체가 아니기 때문에 멀티 스레드 환경에서 잠재적인 문제 요인을 가지고 있다.
• 데이터 값 설계가 잘못되어서 명시적인 표현과 실제 값 사이의 차이가 존재한다.
  • Calander.OCTOBER 의 값을 9를 나타낸다.