스프링 시큐리티는 스프링 기반의 어플리케이션에서 보안과 인증(Authentication)을 담당하는 프레임워크다. 인증, 권한부여, 보안, 세션관리 등의 기능을 제공하며 웹 애플리케이션 뿐만 아니라 서비스 계층에서의 보안기능을 구현하는 데 사용될 수 있다. 다양한 인증방식을 지원하는데 종류로는 기본적으로 폼 로그인 방식과 OAuth, OpenID Connect, LDAP, Kerberos 등의 다른 인증방식도 지원한다.

인증과 권한 부여를 위해 Authentication(인증)과 Authorization(권한 부여) 개념을 사용한다. Authentication은 주체의 신원을 확인하는 것이며, 이를 통해 해당 주체가 자원에 접근할 권한이 있는지 확인한다. Authorization은 인증된 주체가 특정 자원에 대해 어떤 권한을 가지고 있는지 확인하는 것이다.

스프링 시큐리티와 OAuth2를 활용하여 소셜로그인을 구현해보자.

구글 서비스 등록

1. 구글 클라우드 플랫폼 주소(https://console.cloud.google.com)로 이동하여 새 프로젝트를 만든 후, API 및 서비스 카테고리로 이동하여 사용자 인증정보를 클릭한다.

2. 사용자 인증 정보 만들기 - OAuth 클라이언트 ID - 동의 화면 구성

3. OAuth 동의 화면 - 어플리케이션 이름, 지원이메일, API범위(email, profile, openid) 설정

4. OAuth 클라이언트 ID 만들기 - 웹애플리케이션 설정 - 이름설정

5. 승인된 리디렉션 URI설정 스프링 부트2 버전의 시큐리티에서는 기본적으로 {도메인}/login/oauth2/code/{소셜서비스코드}로 리다이렉트 URL을 지원하고 있다. http://localhost:8080/login/oauth2/code/google 현재는 개발단계이므로 localhost로 등록하지만, 배포하게 되면 추가로 주소를 추가해야한다.

6. 모두 설정해준 뒤 돌아오면, 클라이언트ID와 보안비밀번호를 조회할 수 있다.

프로젝트 설정

application-oauth.properties 파일 구성

준비물은 위의 단계에서 조회된 클라이언트 ID와 클라이언트 보안 비밀번호다. resources 디렉토리에 application-oauth.properties 파일을 생성해주자.

spring.security.oauth2.client.registration.google.client-id=클라이언트 ID
spring.security.oauth2.client.registration.google.client-secret=클라이언트 보안 비밀번호
spring.security.oauth2.client.registration.google.scope=profile,email

application-xxx.propertis 파일은 'xxx'라는 이름의 프로파일을 지정하여 각각 다른 설정을 사용할 수 있다. 프로파일이란 애플리케이션을 실행할 때 사용하는 설정의 집합으로, 실행 환경에 따라 설정을 달리하여 관리할 수 있다. appication-oauth.properties 파일은 스프링부트 애플리케이션에서 OAuth 2.0 인증을 구현할 때 사용하는 프로퍼티 파일이다. 이 파일에는 OAuth 2.0 인증을 위한 클라이언트 ID, 클라이언트 시크릿, 리다이렉트 URI 등의 설정 정보가 포함된다. 이 파일을 사용하여 OAuth 2.0인증을 구현하면, 소셜 미디어 서비스에서 제공하는 OAuth 2.0 인증 API를 사용하여 사용자 인증을 처리할 수 있다. 이제 application-properties 파일에서 application-oauth.properties를 포함하도록 구성해야 한다. spring.profiles.include=oauth 이렇게 코드를 추가로 작성해주면, 이 설정값을 사용할 수 있게된다.

.gitignore 등록 클라이언트 ID와 보안 비밀은 보안이 중요한 정보들이다. 외부에 노출될 경우 언제든 개인정보를 가져갈 수 있는 취약점이 될 수 있으므로 .gitignore에 다음과 같이 추가하여 깃허브에 커밋되지 않도록 한다.

프로젝트 구현

User Entity 작성

@Getter
@NoArgsConstructor
@Entity
public class User extends BaseTimeEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(nullable = false)
    private String name;

    @Column(nullable = false)
    private String email;

    @Column
    private String picture;

    @Enumerated(EnumType.STRING)
    @Column
    private Role role;

    @Builder
    public User(String name, String email, String picture, Role role) {
        this.name = name;
        this.email = email;
        this.picture = picture;
        this.role = role;
    }

    public User update(String name, String picture) {
        this.name = name;
        this.picture = picture;

        return this;
    }

    public String getRoleKey() {
        return this.role.getKey();
    }

}

위 코드에서 User 엔티티는 데이터베이스에 저장되는 User 테이블과 매핑된다. Id와 컬럼들을 정의해주는 것을 알 수 있는데, 그 중 Role은 사용자의 역할을 나타내며 열거형 타입을 데이터베이스에서 문자열로 저장하도록 지정되어있다. 기본적으로는 int로 된 숫자가 저장되는데, 문자열로 저장하도록 별도로 설정해준 것이다.

Role 클래스 작성 각 사용자의 권한을 관리할 Enum 클래스 Role을 생성하여 작성하자.

@Getter
@RequiredArgsConstructor
public enum Role {

    GUEST("ROLE_GUEST", "손님"),
    USER("ROLE_USER", "일반 사용자");

    private final String key;
    private final String title;
}

스프링 시큐리티에서는 권한 코드에 항상 ROLE_이 앞에 있어야만 한다. GUEST와 USER 두 가지 상수로 정의하여 각각의 값을 가지고 있다.

이 클래스에서 두개의 final 필드인 key와 title은, 각각 사용자의 역할을 나타내는 문자열("ROLE_GUEST", "ROLE_USER")과 해당 역할의 한글 제목("손님", "일반 사용자")을 나타낸다.

UserRepository 생성

public interface UserRepository extends JpaRepository<User, Long> {
    Optional<User> findByEamil(String email);
}

findByEamil : 소셜로그인으로 반환되는 값 중 email을 통해 이미 생성된 사용자인지 처음 가입하는 사용자인지 판단하기 위한 메소드

스프링 시큐리티 설정

의존성 추가

build.gradle에 스프링 시큐리티 관련 의존성 추가

  implementation('org.springframework.boot:spring-boot-starter-oauth2-client')

spring-boot-starter-oauth2-client 의존성을 추가하여 스프링 부트 애플리케이션에서 OAuth2 서비스 제공자와 연동 후 로그인 및 사용자 인증 과정을 처리하도록 한다. 이 의존성은 스프링 시큐리티와 연동하여 사용할 수 있으며, OAuth2 클라이언트의 기능을 쉽게 사용할 수 있도록 필요한 라이브러리들을 자동으로 추가해준다.

OAuth 라이브러리를 이용한 소셜로그인 코드 작성 소셜로그인에 관한 설정 코드를 작성하는 클래스를 생성하는 것이므로, 설정 정보를 관리하기 위한 패키지인 config 패키지를 생성한다. 생성한 config 패키지 안에, 인증관련 설정파일을 다룰 패키지 auth를 생성한 후 설정클래스를 생성하여 아래와 같이 작성해준다.

@RequiredArgsConstructor
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {

    private final CustomOAuth2UserService customOAuth2UserService;

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
                .csrf().disable().headers().frameOptions().disable()
                .and()
                    .authorizeRequests().antMatchers("/", "/css/**", "/images/**", "/js/**", "/h2-console/**")
                    .permitAll()
                    .antMatchers("/api/v1/**").hasRole(Role.USER.name())
                    .anyRequest().authenticated()
                .and()
                    .logout().logoutSuccessUrl("/")
                .and()
                .oauth2Login()
                .userInfoEndpoint().userService(customOAuth2UserService);
    }
}

위의 코드에 관해 잠시 설명하자면

이 클래스는 WebSecurityConfigurerAdapter 클래스를 상속받아 구현현하는데, WebSecurityConfigurerAdapter 클래스는 스프링 시큐리티 구성을 위한 필수적인 메소드를 제공하는 추상 클래스다.

@EnableWebSecurity 는 스프링 시큐리티를 활성화 시키기 위한 어노테이션이다. HttpSecurity는 스프링 시큐리티에서 HTTP 요청에 대한 보안 처리를 구성하는 클래스다. 이 클래스를 사용하면 인증과 권한부여에 대한 설정을 지정할 수 있다. HttpSecurity 는 WebSecurityConfigurerAdapter 클래스를 상속하여 configure(HttpSecurity http)메소드를 재정의하여 사용한다.

// WebSecurityConfigurerAdapter 
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        this.disableLocalConfigureAuthenticationBldr = true;
    }

.csrf().disable().headers().frameOptions().disable() : csrf 보호기능과 frameOptions기능을 사용하지 않도록 설정하는 코드. h2-console 화면을 사용하기 위해 해당 옵션들을 disable로 설정한다.

authorizeRequests() 특정한 경로에 특정한 권한을 가진 사용자만 접근할 수 있도록 설정한다. URL별 권한 관리를 설정하는 옵션의 시작점이다.

.antMatchers()은 권한관리를 지정하는 옵션으로 URL, HTTP 메소드별로 관리가 가능하다. .permitAll() 메소드로 끝나는 경로에 있는 url은 무조건 접근을 허용하도록 설정한 것이고, hasRole()로 끝나는 경로에 있는 url은 권한을 가진 사람만 접근을 허용하도록 설정한 것이다.

anyRequest는 natMatchers에서 설정되지 않은 나머지 URL을 의미한다. .anyRequest.authenticated()는 즉 나머지 URL은 모두 인증된 사용자들에게만 허용하도록 설정한 것이다.

.logout().logoutSuccessUrl("/") 은 로그아웃에 대한 설정인데, 로그아웃에 성공했다면 "/" URL 주소로 이동된다.

oauth2Login : OAuth 2.0 기반 로그인 기능에 대한 여러 설정한다. userInfoEndpoint : OAuth 2.0 로그인으로 인증한 사용자 정보를 가져오는 엔드포인트를 설정들을 담당한다. userService : 소셜로그인 성공 시 가져온 사온자 정보를 처리할 UserService 인터페이스의 구현체를 등록한다.

Java 8버전부터 Collection 인터페이스에 추가된 API stream은 Collection 객체를 스트림으로 변환하여 데이터를 처리하는 다양한 연산을 수행하도록 도와주며 컬렉션, 배열 등의 데이터 소스로부터 요소를 추출하고 처리하는 기능을 제공한다. Stream에서 연산은 파이프라인을 통해 처리된다. 이는 여러개의 중간 연산과 최종연산이 순차적으로 연결된 것을 의미하는데, 스트림 파이프라인을 통해 코드를 간결하게 유지할 수 있다.

중간연산

중간연산은 여러번 사용될 수 있는데, 이 단계에서 자주 사용하는 메소드는 다음과 같다.

• filter() : 조건에 따라 요소를 필터링하여 만족하는 요소만 Stream으로 반환된다. 스트림에서 짝수만 반환하는 예시는 다음과 같다.

  List<Integer> list = Arrays.asList(1, 2, 3, 4, 5);
  Stream<Integer> stream = list.stream();
  Stream<Integer> evenStream = stream.filter(x -> x % 2 == 0);

위 코드에서 filter() 메소드는 각 요소 x에 대해 x % 2 == 0의 조건을 검사한 후, 만족하는 요소만을 선택하여 evenStream에 반환한다.

• map() : 스트림의 각 요소를 변환하는데, 입력값을 받아서 변환된 출력값을 반환한다.

  List<Integer> list = Arrays.asList(1, 2, 3, 4, 5);
  Stream<Integer> stream = list.stream();
  Stream<Integer> squaredStream = stream.map(x -> x * x);
  

// 출력값 : 1, 4, 9, 16, 25

위 코드에서 스트림의 map 메소드를 사용하여 각 요소를 제곱한 결과를 새로운 Stream으로 반환한다. 이 때 람다식 `x -> x * x`는 각 요소를 제곱하는 함수이다.

<hr>

* **`sorted()`** : 스트림의 요소를 정렬하여 새로운 스트림을 반환한다.
기본적으로는 `Comparable` 인터페이스를 구현한 객체에 대해서 오름차순으로 정렬한다. `Comparator`를 인자로 받는 오버로딩된 메소드를 사용하여 정렬방법으 지정할 수도 있다.
```java
List<String> list = Arrays.asList("apple", "banana", "cherry", "date");
Stream<String> stream = list.stream();

Stream<String> sortedStream = stream.sorted();
sortedStream.forEach(System.out::println);

// 출력 결과: apple, banana, cherry, date

위 코드에서는 String 타입의 요소를 가진 리스트에서 스트림을 생성하고 Sorted() 메소드를 호출하여 알파벳순으로 정렬된 스트림을 반환하고 출력한다.

• distinct() : 스트림의 요소 중에서 중복된 요소를 제거하여 새로운 Stream을 반환하며 중복을 판단할 때 equals() 메소드를 사용한다.

  List<Integer> list = Arrays.asList(1, 2, 3, 2, 4, 3, 5);
  Stream<Integer> stream = list.stream();
  

Stream distinctStream = stream.distinct(); distinctStream.forEach(System.out::println);

// 출력 결과: 1, 2, 3, 4, 5

위 코드에서는 Integer타입의 요소를 가진 리스트에서 스트림을 생성하고, distinct() 메소드를 호출하여 중복된 요소를 제거한 Stream을 반환하고 출력한다. 

<hr>

* **`limit()`** : 스트림 요소 중에서 처음부터 지정한 개수만큼 요소를 가져와 새로운 스트림을 반환한다.
```java
List<Integer> list = Arrays.asList(1, 2, 3, 4, 5);
Stream<Integer> stream = list.stream();

Stream<Integer> limitedStream = stream.limit(3);
limitedStream.forEach(System.out::println);

// 출력 결과: 1, 2, 3

위 코드에서는 limit() 메소드를 호출하여 처음 3개의 요소만을 가진 스트림을 반환하고 출력한다.

• flatMap() : 스트림의 각 요소들을 다른 스트림으로 변환한 후, 모든 스트림을 하나의 스트림으로 연결하여 반환한다.

  List<String> list1 = Arrays.asList("java", "python");
  List<String> list2 = Arrays.asList("stream", "lambda");
  Stream<List<String>> streamOfList = Stream.of(list1, list2);
  

Stream flatMapStream = streamOfList.flatMap(list -> list.stream()); flatMapStream.forEach(System.out::println);

// 출력 결과: java, python, stream, lambda

위 코드에서는 각각 두개의 문자열 리스트를 가진 스트림을 생성하고 flatMap() 메소드를 호출하여 각 리스트의 문자열 요소들을 하나의 스트림으로 연결 후 반환하고 출력한다. 


### 최종연산
최종연산은 스트림의 요소들을 처리하여 최종 결과를 반환하는 연산인데, 최종 연산을 수행한 후에는 더이상 스트림을 다룰 수 없다.

**1. 요소의 출력 : forEach()**
스트림의 각 요소를 소비하여 출력한다.
```java
List<Integer> list = Arrays.asList(1, 2, 3, 4, 5);
list.stream()
    .forEach(x -> System.out.print(x + " ")); 

// 출력 결과: 1 2 3 4 5

2. 요소의 소모 : reduce() 스트림의 요소를 하나씩 처리하여 최종적으로 하나의 결과값을 반환한다.

List<Integer> list = Arrays.asList(1, 2, 3, 4, 5);
Optional<Integer> sum = list.stream().reduce((x, y) -> x + y);
System.out.println(sum.get()); // 출력 결과: 15

3. 요소의 검색 : findFirst(), findAny() findFisrt(), findAny()는 스트림에서 요소를 검색하는 용도로 사용된다.

• findFirst() 메소드는 스트림에서 첫 번째 요소를 반환하거나, 스트림이 비어있다면 Optional.empty()를 반환하며, 일반적으로 정렬된 스트림에서 첫번째 요소를 찾는 데 사용된다.

  List<String> strings = Arrays.asList("apple", "banana", "avocado");
  Optional<String> firstA = strings.stream().filter(s -> s.startsWith("a")).findFirst();
  System.out.println(firstA.orElse("No strings found"));
  

//출력 결과 : apple

위 코드는 filter() 메소드를 사용하여 문자열 리스트에서 'a'로 시작하는 첫 번째 문자열을 찾기 위해 스트림을 필터링한 후, findFirst() 메소드를 통해 결과를 반환한다.

<hr>

* **`findAny()`** 메소드는 스트림에서 임의의 요소를 반환한다. 마찬가지로 스트림이 비어있다면 `Optional.empty()`를 반환하며 병렬처리된 스트림에서 사용되어 스트림의 모든 요소 중 하나를 찾을 때 유용하다.
```java
List<String> strings = Arrays.asList("apple", "banana", "avocado");
Optional<String> anyA = strings.parallelStream().filter(s -> s.contains("a")).findAny();
System.out.println(anyA.orElse("No strings found"));

//출력 결과 : banana

위 코드에서 출력되는 결과는 'banana' 또는 'avocado' 문자열 중 하나가 출력된다. findAll() 메소드는 임의의 요소를 반환하기 때문이다.

4. 요소의 검사 : anyMatch(), allMatch(), noneMatch() anyMatch(), allMatch(), noneMatch() 메소드는 모두 스트림의 요소를 조건식과 비교하여 boolean 값을 반환한다.

• anyMatch() 메소드는 만족하는 스트림의 요소가 하나라도 있는지 검사한다. 조건식을 만족하는 요소가 적어도 하나가 있다면 true를 반환하고 그렇지 않으면 false를 반환한다.

  List<String> strings = Arrays.asList("apple", "banana", "avocado");
  boolean anyContainsA = strings.stream().anyMatch(s -> s.contains("a"));
  System.out.println("Any string contains 'a': " + anyContainsA);
  

//출력 결과 : Any string contains 'a': true

위 코드는 문자열 리스트에서 'a'를 포함하는 요소가 하나 이상이 있는지 확인하는 예시다.

<hr>

* **`allMatch()`** 메소드는 조건식을 모든 스트림 요소에 대해 검사한다. 모든 요소가 조건식을 만족한다면 true를, 그렇지 않으면 false를 반환한다.
```java
List<String> strings = Arrays.asList("apple", "banana", "avocado", "cherry");
boolean allStartsWithA = strings.stream().allMatch(s -> s.startsWith("a"));
System.out.println("All strings start with 'a': " + allStartsWithA)

//출력 결과 : Any string contains 'a': false

위 코드에서는 각 요소 모두가 a를 포함하고 있지 않기 때문에 false를 반환한다.

• noneMatch() 메소드는 모든 스트림 요소가 조건식을 만족하지 않는지 검사한다. 모든 요소가 조건식을 만족하지 않으면 true, 하나라도 만족한다면 false를 반환한다.

  List<String> strings = Arrays.asList("apple", "banana", "avocado", "cherry");
  boolean noneContainsZ = strings.stream().noneMatch(s -> s.contains("z"));
  System.out.println("No string contains 'z': " + noneContainsZ);
  

//출력 결과 : Any string contains 'z': true

각 요소 모두가 'z'라는 문자열을 포함하고 있지 않으므로 반환되는 결과는 true 이다.
<br>

**5. 요소의 통계 : count(), min(), max()**

* **count()** 메소드는 스트림의 요소 수를 반환한다.
```java
List<String> strings = Arrays.asList("apple", "banana", "avocado", "cherry");
long count = strings.stream().count();
System.out.println("Number of strings: " + count);

// 출력 결과 : Number of strings: 4

위 코드에서 각 요소의 갯수는 4개 이므로 반환되는 값은 4다.

• min() 메소드는 스트림의 최소값을 반환한다.

  List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5);
  Optional<Integer> min = numbers.stream().min(Integer::compareTo);
  System.out.println("Minimum number: " + min.get());
  

//출력 결과 : Minimum number: 1

<hr>

* **`max()`** 메소드는 스트림의 최대값을 반환한다.
```java
List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5);
Optional<Integer> max = numbers.stream().max(Integer::compareTo);
System.out.println("Maximum number: " + max.get());

//출력 결과 : Maximum number: 5

6. 요소의 연산 : sum(), average()

• sum() 메소드는 스트림 요소들의 합을 반환한다. 요소들은 반드시 숫자형 데이터여야 한다.

  List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5);
  int sum = numbers.stream().mapToInt(Integer::intValue).sum();
  System.out.println("Sum of numbers: " + sum);
  

//출력 결과 : Sum of numbers: 15

<hr>

* **`average()`** 메소드는 스트림 요소들의 평균값을 반환한다. 역시 모두 숫자형 데이터여야 한다.
```java
List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5);
OptionalDouble avg = numbers.stream().mapToInt(Integer::intValue).average();
System.out.println("Average of numbers: " + avg.getAsDouble());

//출력 결과 : Average of numbers: 3.0

7. 요소의 수집 : collect() 스트림의 요소를 수집하는 용도로 사용된다. 스트림의 요소를 수집해서 다른 컬렉션에 담거나 문자열로 변환하는 등의 작업을 할 수 있다.

List<String> strings = Arrays.asList("apple", "banana", "avocado", "cherry");
List<String> longStrings = strings.stream()
                                  .filter(s -> s.length() >= 5)
                                  .collect(Collectors.toList());
System.out.println("Long strings: " + longStrings);

//출력 결과 : [apple, banana, avocado, cherry]

위 코드는 collect() 메소드를 사용해서 문자열 리스트에서 길이가 5 이상인 요소들만 골라서 새로운 리스트를 수집하는 예시다.

스트림 요소를 문자열로 결합할 수도 있다.

List<String> strings = Arrays.asList("apple", "banana", "avocado", "cherry");
String joinedString = strings.stream()
                             .collect(Collectors.joining(", "));
System.out.println("Joined string: " + joinedString);

//출력 결과 : oined string: apple, banana, avocado, cherry

위 코드는 문자열 리스트의 모든 요소를 쉼표로 구분한 문자열로 결합하는 예시다.

이처럼 collect() 메소드는 스트림의 요소를 수집하는 다양한 방법을 제공한다. 위의 예시 말고도 Collectors 클래스에서 제공하는 메소드들을 이용하여 원하는 수집 방식을 선택하여 사용할 수 있다.

생성일, 수정일 같은 중요한 정보를 기록하는 코드가 모든 테이블과 서비스 메소드에 반복적으로 작성된다면, 귀찮고 자칫 코드가 지저분해질 수 있다. 이런 문제를 해결하고자 JPA Auditing을 사용해 보려고 한다.

JPA Auditing은 JPA를 사용하여 엔티티의 생성일, 수정일 같은 정보를 자동으로 기록하고 추적하는 기능인데, 일반적으로 Spring Data JPA와 함께 사용된다.

JPA Auditing을 구련하려면 엔티티에 @EntityListeners 어노테이션을 사용하여 리스너를 등록해야 한다. 이 리스너는 엔티티의 상태가 변경될 때 마다 콜백 메소드를 호출하여 적절한 정보를 추적하고 기록한다.

JPA Auditing 적용

JPA Auditing 기능을 사용하기 위해 다음과 BaseTime엔티티를 생성한다.

@Getter
@EnableJpaAuditing
@MappedSuperclass
@EntityListeners(AuditingEntityListener.class)
public class BaseTimeEntity {

    @CreatedDate
    private LocalDateTime createdDate;

    @LastModifiedDate
    private LocalDateTime modifiedDate;
}

잠시 위의 코드를 설명해보자면

@EnableJpaAuditing JPA Auditing 어노테이션들을 모두 활성화 시키는 어노테이션

@MappedSuperClass JPA 어노테이션. 엔티티에서 공통적으로 사용하는 필드를 정의하는 추상 클래스임을 나타낸다. 즉, JPA Entity 클래스들이 BaseTimeEntity를 상속할 경우 필드들(createdDate, modifiedDate)도 컬럼으로 인식하도록 한다.

@EntityListeners(AuditingEntityListener.class) JPA Auditing을 구현하기 위한 어노테이션 중 하나로, BaseEntity 클래스에서 리스너를 사용하도록 설정한다.

@CreatedDate Entity가 생성되어 저장될 때 시간이 자동으로 저장된다.

@LastModifiedDate 조회된 Entity의 값을 변경할 때 시간이 자동으로 저장된다.

JPA Auditing 테스트 코드 작성

위와 같이 실제 구현 코드를 완성시켰으니, 이제 제대로 작동하는지 테스트를 해보자.

package com.myshop.domain.posts;

import org.junit.After;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.context.junit4.SpringRunner;

import java.time.LocalDateTime;
import java.util.List;

import static org.assertj.core.api.AssertionsForClassTypes.assertThat;

@RunWith(SpringRunner.class)
@SpringBootTest // 별다른 설정 없이 이 어노테이션을 사용할 경우 H2 데이터베이스를 자동으로 실행해줌
public class PostsRepositoryTest {

    @Autowired
    PostsRepository postsRepository;

    @After
    public void cleanup() {
        postsRepository.deleteAll();
    }

    @Test
    public void BaseTimeEntityTest() {

        //given
        LocalDateTime now = LocalDateTime.of(2023,3,19,0,0,0);
        postsRepository.save(Posts.builder()
                .title("생성일 제목")
                .content("생성일 내용")
                .author("테스트~")
                .build()
        );

        //when
        List<Posts> postsLists = postsRepository.findAll();

        //then
        Posts posts = postsLists.get(0);

        System.out.println(">>>> createdDate=" + posts.getCreatedDate()+", modifiedDate=" + posts.getModifiedDate());

        assertThat(posts.getCreatedDate()).isAfter(now);
        assertThat(posts.getModifiedDate()).isAfter(now);
    }

}

위 테스트 코드에서는 현재 시점의 LocalDateTime 정보를 생성한다. 생성된 정보는 save 메소드로 객체를 저장할 때 BaseEntity 클래스의 생성일(createdDate)과 수정일(modifiedDate) 정보가 자동으로 기록된다.

그 후, findAll() 메소드로 저장된 리스트들을 모두 불러온 뒤, 첫번째 엔티티 객체를 선택하여 posts 변수에 저장한 후 결과를 출력한다.

마지막으로 Posts 엔티티 객체의 생성일과 수정일이 테스트시점의 LocalDateTime 정보(now) 이후임을 검증한다.

테스트코드를 실행해보면 콘솔창에 createdDate와 modifiedDate가 조회된다!

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

ResponseEntity 클래스는 HTTP 응답(Response)을 나타내는 객체로, 반환된 HTTP 상태코드와 헤더, 응답 본문 등을 포함한다. ResponseEntity는 밑의 사진에서 보이는 것처럼 HttpEntity를 상속받았기 때문이다.

바로 위의 사진은 HTTP 클래스인데, 헤더와 바디를 멤버필드로 포함하고 있다.
즉 ResponseEntity는 HttpEntity 클래스의 멤버필드 headers, body와 자체적으로 갖고 있는 멤버필드 status(상태코드)를 포함하여 HttpStatus, HttpHeaders, HttpBody를 변수로 갖게 된다.

일반적으로 @Controller나 @RestController, @RequestMapping 메소드를 사용하여 HTTP 요청에 대한 응답을 반환할 때 사용한다.

예를 들어 HTTP 상태코드가 200인 응답을 반환하려면 다음과 같이 ResponseEntity를 사용할 수 있다.

@GetMapping("/hello")
public ResponseEntity<String> hello() {
    String message = "Hello, World!";
    return ResponseEntity.ok(message);
}

위 코드에서 ResponseEntity.ok(message)는 HTTP 상태코드 200과 "Hello, World!" 메세지를 가진 ResponseEntity 객체를 생성하여 반환한다.

@GetMapping("/users/{id}")
public ResponseEntity<User> getUserById(@PathVariable Long id) {
    User user = userRepository.findById(id)
        .orElseThrow(() -> new ResourceNotFoundException("User not found with id: " + id));
    return ResponseEntity.ok(user);
}

@ResponseStatus(HttpStatus.NOT_FOUND)
public class ResourceNotFoundException extends RuntimeException {
    public ResourceNotFoundException(String message) {
        super(message);
    }
}

위 코드는 ReponseEntity를 사용하여 404 Not Found 에러를 반환하는 코드다. 맨 처음으로 데이터베이스에서 해당 id값을 가진 사용자 정보를 조회하는 메소드가 보이는데, 이 때 findById() 메소드는 Spring Data JPA에서 제공하는 메소드중 하나로 결과를 Optional 타입으로 반환 한다.

Optional은 값이 없을 수도 있는 객체를 다룰 때 사용하는 클래스다. 이 타입을 사용하면 null 체크를 하지 않아도 되는 장점이 있다. Optional.empty() : 조회된 엔티티가 없는 경우 반환되는 객체 orElseThrow() : 예외를 발생시키는 메소드 orElse() : 기본값을 반환하는 메소드

따라서 위 코드에서는 userRepository.findById(id)를 호출하여 조회한 Optional 객체가 값이 없다면, orElseThrow 메소드가 ResourceNotFoundException 예외를 발생시킨다. 즉, "User not found with id: {id}"라는 메세지를 가진 ResourceNotFoundException 예외가 발생하여 HTTP 상태코드 404를 반환한다.

ResourceNotFoundException은 HTTP 요청에 대한 예외처리를 위한 사용자 정의 예외클래스다. @ResponseStatus(HttpStatus.NOT_FOUND) 어노테이션은 해당 예외가 발생했을 때, HTTP 응답 상태코드를 404 NOT FOUND로 설정해준다. 이는 REST API에서 자주 사용되는 응답 상태코드 중 하나로 클라이언트가 요청한 값이 존재하지 않는 경우에 사용된다.

ResponseEntity Customize

ResponseEntity는 상태코드와 헤더, 바디 중 원하는 것만 선택해서 반환할 수 있다는 큰 장점이 있다.

몇가지 예시를 들어보자

1. 상태코드와 헤더는 그대로 유지, 본문만 변경하고자 할 때

// 원래의 ResponseEntity 객체
ResponseEntity<String> responseEntity = ResponseEntity
    .status(HttpStatus.OK)
    .header("My-Header", "value")
    .body("original body");

// 상태 코드와 헤더는 그대로 유지하고, 본문만 변경한 새로운 ResponseEntity 객체
ResponseEntity<String> newResponseEntity = ResponseEntity
    .status(responseEntity.getStatusCode())
    .headers(responseEntity.getHeaders())
    .body("new body");

위의 코드에서, newResponseEntity 객체는 responseEntity 객체와 상태코드와 헤더가 동일하고, 본문만 "new body"로 변경된 새로운 객체가 된다.
2. 바디만 반환하는 경우

@GetMapping("/body")
public ResponseEntity<String> getBody() {
    return ResponseEntity.ok("response body");
}

위 코드에서 ResponseEntity 객체 생성 시, 생성자의 두번째 파라미터로 반환할 바디의 내용을 넘겨주면 된다.

3. 상태코드만 반환하는 경우 게시글의 삭제같은 경우처럼 반환타입이 따로 없는 경우가 있다. 이런 경우에는 상태코드만 반환해줄 수 있는데, 코드는 다음과 같다.

@DeleteMapping("/resources/{id}")
public ResponseEntity<Void> deleteResource(@PathVariable Long id) {
    boolean success = resourceService.deleteResource(id);
    if (success) {
        return ResponseEntity.status(HttpStatus.NO_CONTENT).build();
    } else {
        return ResponseEntity.status(HttpStatus.NOT_FOUND).build();
    }
}

위 코드는 게시글이 무사히 삭제된 경우와, 그렇지 않을 경우에 각각 다른 상태코드를 반환한다. 만약 삭제가 성공했다면 HttpStatus.NO_CONTENT 상태코드와 빈 바디를 가진 ResponseEntity를 반환한다. 반면 삭제에 실패했다면 HttpStatus.NOT_FOUND 상태코드와 함께 빈 바디를 가진 ResponseEntity를 반환한다.

ResponseEntity Methods

ResponseEntity의 메소드들은 서버에서 생성된 HTTP 응답을 생성하기 위한 다양한 방법을 제공해준다. 그 중 자주 사용되는 몇가지 메소드들을 살펴보자

ok() : HTTP 상태코드 200를 반환 notFound() : HTTP 상태코드 404를 반환 getBody() : HTTP 응답 바디에 대한 내용을 반환 getHeaders() : HTTP 응답 헤더에 대한 내용을 반환 getStatusCode() : HTTP 응답 상태코드를 반환한다. 200은 "OK", 404는 "Created", 404는 "Not Found" 등의 의미를 갖고 있다.`

ORM

ORM은 객체지향 프로그래밍 언어에서 사용되는 객체와 관계형 데이터베이스 사이의 데이터 변환 기술이다. ORM은 객체 지향적인 방식으로 데이터를 관리할 수 있도록 해주며, 객체 간의 관계를 강조하여 데이터를 저장하고 검색하는 것을 가능하게 해준다.

JPA

JPA는 ORM을 구현하는 자바 표준 기술이다. 애플리케이션 개발자가 객체를 사용하여 데이터를 저장하고 검색할 수 있도록 해주며 데이터베이스와의 통신, SQL 생성 및 실행, 객체와 테이블 간의 매핑, 캐시 및 트랜잭션 관리 등을 처리한다. 즉 객체를 사용하여 데이터베이스와 상호작용을 하도록 도와주므로 개발자는 데이터베이스와의 상호작용에 구체적인 구현을 신경쓰지 않아도 된다.

인터페이스인 JPA를 사용하기 위해서는 구현체가 필요한데 대표적으로는 Hibernate 등이 있다. 하지만 스프링에서 JPA를 사용할 때는 이 구현체들을 직접 다루지 않고, 구현체들을 좀더 쉽게 사용하고자 추상화시킨 Spring Data Jpa라는 모듈을 이용하여 JPA 기술을 다룬다.

Spring Boot에 Spring Data Jpa 적용하기

1. build.gradle에 의존성을 등록한다.

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
    implementation('org.projectlombok:lombok:1.18.24')

    implementation('org.springframework.boot:spring-boot-starter-data-jpa:2.7.7')
    implementation('com.h2database:h2:2.1.214')
}

h2database : 인메모리 관계형 데이트베이스인 h2database를 사용하면, 별도의 데이터베이스 서버를 설치하거나 구성할 필요 없이 애플리케이션에서 데이터베이스를 사용할 수 있다. 인메모리 데이터베이스를 사용할 경우 데이터베이스가 메모리 상에 존재하기 때문에 매우 빠르게 데이터를 처리할 수 있는 장점이 있다.

2. 도메인 클래스 작성

   package com.myshop.web.domain.posts;
   

import lombok.Builder; import lombok.NoArgsConstructor;

import javax.persistence.Entity; import javax.persistence.GeneratedValue; import javax.persistence.GenerationType; import javax.persistence.Id; import javax.persistence.Column;

@Entity @NoArgsConstructor public class Posts {

@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;

@Column(length = 500, nullable = false)
private String title;

@Column(columnDefinition =  "TEXT", nullable = false)
private String content;

private String author;

@Builder
public Posts(String title, String content, String author) {
    this.title = title;
    this.content = content;
    this.author = author;
}

}

```

위 코드는 JPA를 사용하여 게시글을 관리하기 위한 Posts 엔티티 클래스다. 주요 어노테이션 및 코드 설명을 간단히 해보자면

@Entity : 이 클래스가 JPA Entity임을 나타낸다. JPA Entity는 데이터베이스의 테이블과 매핑된다.

@NoArgsConstructor : lombok 어노테이션으로 파라미터가 없는 기본 생성자를 자동으로 생성해준다.

@Id : 해당 필드가 엔티티의 기본키(pk)임을 나타낸다.

@GeneratedValue : 기본키의 값을 자동으로 생성하기 위한 방법을 지정한다. GenerationType.IDENTITY 옵션을 추가해야만 auto_increment가 된다.

@Column : 필드가 데이터베이스의 컬럼과 매핑될 때 사용한다. length 속성은 문자열의 길이를 지정할 수 있으며(문자열의 경우 varchar(255)가 기본값이다. 사이즈를 늘리고 싶을 때 사용한다.) nullable 속성은 null값을 허용하는지 여부를 지정한다. columnDefinition 속성은 컬럼의 데이터 타입이나 기타 속성을 직접 지정할 수 있다.

@Builder lombok 어노테이션으로 해당 클래스를 빌더 패턴을 사용하여 객체로 생성할 수 있도록 해준다. 생성자 상단에 선언 시, 생성자에 포함된 필드만 빌더에 포함된다.

Entity 클래스에 Setter를 사용하지 않는 이유

여태 getter와 setter를 세트처럼 같이 사용해왔는데, Entity 클래스에는 Setter 메소드를 절대 만들지 않는다고 한다. 이유가 뭘까?

JPA에서는 객체의 상태를 변경할 때 객체의 생성자를 통해 초기화 하거나, 메소드를 추가하여 값을 변경한다. 이는 객체지향 프로그래밍의 캡슐화 원칙을 지키기 위해서다. 만약 setter 메소드를 사용하여 객체의 상태를 변경한다면, JPA는 이를 감지하지 못하게 되는 경우가 발생한다. JPA는 객체를 관리할 때 객체의 상태변화를 추적하여 적절한 SQL 쿼리를 생성하기 때문이다.

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

테스트코드를 작성하지 않는다면 오류가 발생하는 순간부터, 수정하고 반영하기 까지 계속 톰캣을 내렸다가 다시 실행하는 것을 반복한다. 테스트 코드를 작성하면, 이런 문제가 해결되는 것과 더불어 여러가지 장점이 있기 때문에 이번 프로젝트를 진행하면서 테스트 코드를 사용할 생각이다. 그럼 테스트코드를 작성하는 것의 여러가지 장점에 대해 살펴보자

1. 코드의 신뢰성 향상 테스트 코드는 어떤 상황에서도 코드가 잘 동작하는지를 검증한다. 때문에, 코드의 버그를 미리 찾아내고 수정함으로써 코드의 신뢰성을 높일 수 있다.

2. 리팩토링의 안전성 향상 코드를 리팩토링하면서 기능이 망가지지 않도록 하기 위해서는 테스트 코드가 필요하다. 리팩토링 과정에서 기능이 망가지지 않도록 코드를 안전하게 수정할 수 있다.

3. 문서화 역할 테스트코드는 개발자들이 작성한 코드를 설명해주는 문서역할을 할 수 있다. 테스트 코드를 작성하면서 코드가 어떻게 동작하는지에 대한 이해를 높일 수 있기 때문이다.

테스트 코드 작성

다양한 테스트코드 프레임워크가 있지만, 그중 자바용인 JUnit을 사용할 계획이다.

우선 간단한 API를 만들자.

package com.myshop.web;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class MyShopController {

    @GetMapping("/shop")
    public String myShop() {
        return "myShop";
    }
}

위에 쓰여진 코드를 잠깐 설명해보자면

@RestController : 스프링 프레임워크에서 제공하는 어노테이션 중 하나로, 웹 애플리케이션에서 Restful 웹 서비스를 개발할 때 사용한다. 이 어노테이션을 사용하면 해당 컨트롤러 클래스가 RESTful 웹서비스를 처리하는 컨트롤러임을 지정할 수 있다.

@GetMapping : HTTP GET 요청을 처리하기 위한 메서드를 지정하는 어노테이션이다.

이제 작성한 코드가 제대로 작동하는지 테스트를 해보자.

src 폴더 밑에는 main과 test 디렉토리가 존재하고있는데, 테스트 코드를 작성하기 위해 test 디렉토리에 main디렉토리에서 생성했던 패키지를 그대로 다시 생성하면 된다.

콘트롤러 이름은 기존 컨트롤러 이름 뒤에 Test를 붙여서 테스트용 컨트롤러임을 명시한다.

package myshop.web;

import com.myshop.web.MyShopController;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTest;
import org.springframework.test.context.junit4.SpringRunner;
import org.springframework.test.web.servlet.MockMvc;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.content;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get;

@RunWith(SpringRunner.class)
@WebMvcTest(controllers = MyShopController.class)
public class MyShopControllerTest {

    @Autowired
    private MockMvc mvc;

    @Test
    public void hello가_리턴된다() throws Exception {
        String myShop = "myShop";

        mvc.perform(get("/shop"))
                .andExpect(status().isOk())
                .andExpect(content().string(myShop));
    }
}

@RunWith(SpringRunner.class) JUnit을 확장하여 스프링 테스트를 수행하는 방법을 지정하는 어노테이션이다. 테스트클래스 실행시 실행자(runner)로 사용되는데, 스프링 컨텍스트를 로드하고 테스트에서 사용할 빈(bean)을 생성 및 주입(inject)하는 등의 스프링 테스트 환경을 설정한다. 위의 코드는 SpringRunner라는 스프링 실행자를 사용하여 스프링 부트 테스트와 JUnit 사이에 연결자 역할을 한다.

@WebMvcTest(controllers = MyShopController.class) 여러 스프링 테스트 어노테이션 중, Web(MVC)에 집중할 수 있는 어노테이션이다. 테스트할 컨트롤러만 로드되므로 더 빠르게 테스트를 수행할수 있다. @WebMvcTest 의 controllers 속성은 테스트할 컨트롤러 클래스를 작성한다.

@Autowired
    private MockMvc mvc;

MockMvc는 스프링 MVC테스트에서 사용되는 클래스로, 스프링 애플리케이션의 HTTP 요청 및 응답을 테스트하기 위한 모의 객체를 생성한다. @Autowired 어노테이션을 통해 의존성을 주입하여 사용할 수 있다. 요약하면 위 코드는 HTTP GET, POST 등에 대한 API 테스트를 할 수 있도록 @AutoWired 어노테이션을 통해 의존성을 주입한 것이다.

mvc.perform(get("/shop"))
                .andExpect(status().isOk())
                .andExpect(content().string(myshop));

위에서 보이는 perform, andExpect는 Spring MVC Test 프레임워크에서 제공하는 메소드들인데, 좀 더 자세히 알아보도록 하자.

mvc.perform(get("/shop")) MockMvc 객체의 perform() 메소드를 사용하여 "/shop" 주소로 HTTP GET 요청을 보낸다.

andExpect(status().isOk()) andExpect() 메소드를 사용하여 응답 상태코드가 200 OK인지 검증한다. 즉, HTTP 요청이 성공적으로 처리되어 200 상태코드를 반환하는지를 검증하는데, Boolean 값을 반환하며 상태코드가 200인 경우에만 테스트가 통과된다.

andExpect(content().string(hello)) HTTP 응답의 본문(content)을 검증하는 역할을 한다. 'string(hello)' 는 본문의 내용이 'hello' 문자열과 일치하는지를 검증한다. Boolean값을 반환하며 본문이 'hello' 문자열과 일치하는 경우에만 테스트가 통과된다.

무사히 실행이 완료되면 Tests passed에 초록색 체크아이콘이 생긴다.

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

gradle.build 파일을 열어서 코드를 학인해보면 다음과 같다.

plugins {
    id 'java'
}

group 'com.myshop'
version '1.0-SNAPSHOT'

repositories {
    mavenCentral()
}

dependencies {
    testImplementation 'org.junit.jupiter:junit-jupiter-api:5.8.1'
    testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.8.1'
}

test {
    useJUnitPlatform()
}

간단하게 작성되어있는 기본 코드에, 플러그인 의존성 관리를 위한 설정 코드를 작성해주자.

buildscript {
    ext {
        springBootVersion = '2.1.7.RELEASE'
    }
    Repositories {
        mavenCentral()
        jcenter()
    }
    dependencies {
        classpath("org.springframework.boot:spring-boot-gradle-plugin:${springBootVersion}")
    }
}

ext : build.gradle에서 사용하는 전역변수를 설정하겠다는 의미인데, ext 블록은 gradle 빌드 스크립트 전체에서 사용할 수 있는 추가 속성을 정의하기 위해 사용되는 특수한 블록이다. *'SpringBootVersion' * 라는 전역변수를 정의하고 그 값을 '2.1.7.RELEASE'로 설정하는 Groovy 스크립트다. 즉, spring-boot-gradle-plugin 라는 스프링 부트 그레이들 플러그인의 2.1.7 RELEASE를 의존성으로 받겠다는 의미이다.

Repositories : 각종 의존성(라이브러리)들을 어떤 원격 저장소에서 받을지 정한다.

다음은 앞서 선언한 플러그인 의존성들을 적용할 것인지를 결정하는 코드다.

    apply plugin: 'java'
    apply plugin: 'eclipse'
    apply plugin: 'org.springframewokr.boot'
    apply plugin: 'io.spring.dependency-management'

apply plugin: java : Java 플러그인을 적용하는 코드. Java 소스 코드를 컴파일하고 빌드할 수 있도록 도와준다. apply plugin: eclipse : 이클립스에서 프로젝트를 가져올 수 있도록 프로젝트 파일을 생성한다. apply plugin: org.springframework.boot : Spring Boot 애플리케이션을 빌드하기 위한 다양한 작업을 수행한다. apply plugin: io.spring.dependency-management : Spring Boot 프로젝트에서 의존성 관리를 위해 사용되는 플러그인을 적용하는 코드다. 이 플러그인은 Maven 중앙저장소에서 의존성을 관리하며, 버전충돌을 방지하고 라이브러리의 버전을 쉽게 업그레이드 할 수 있도록 도와준다.

  dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    testCompileOnly('org.springframework.boot:spring-boot-starter-test')
}

마지막으로 프로젝트 개발에 필요한 의존성들을 선언해준다. 처음엔 compile('org.springframework.boot:spring-boot-starter-web') 로 작성했지만, No candidates found for method call 메세지가 뜨면서 작동을 하지 않았다. 이유를 알아보니 Gradle 4.x 버전 이상부터는 implementation 이나 api 키워드를 대신 사용하도록 권장된다고 하여 바꿔준 것이다.

이렇게 개발에 필요한 빌드설정을 마쳤다. 모두 적용한 전체 코드는 이렇다.

 buildscript {
    ext {
        springBootVersion = '2.1.7.RELEASE'
    }
    repositories {
        mavenCentral()
        jcenter()
    }
    dependencies {
        classpath("org.springframework.boot:spring-boot-gradle-plugin:${springBootVersion}")
    }
}

apply plugin: 'java'
apply plugin: 'eclipse'
apply plugin: 'org.springframework.boot'
apply plugin: 'io.spring.dependency-management'

group 'com.myshop'
version '1.0-SNAPSHOT'
sourceCompatibility = 11

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    testCompileOnly('org.springframework.boot:spring-boot-starter-test')
}

test {
    useJUnitPlatform()
}     

이제 Reload Gradle Project를 클릭하여 프로젝트에 반영해주면 된다. 완료되면 우측의 Gradle 탭으로 들어가서 의존성들이 잘 받아졌는지 확인!

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

RDBMS는 데이터를 관리하고 저장하는 데 사용되는 소프트웨어다. 데이터를 테이블로 구성하고 각 테이블은 다른 테이블과 관계를 맺음으로써 생기는 관계에 의해 데이터를 구성하고 관리할 수 있다.

RDMS는 Oracle, MySQL, PostgreSQL 등 여러 종류가 있는데, 그 중 SQL Server에 대해 알아보려고 한다.

SQL Server?

SQL Server는 Microsoft Corporation(MSSQL)에서 개발한 관계형 데이터베이스 관리 시스템(RDBMS)이다. SQL Server는 데이터를 저장하고 관리하며, 클라이언트 응용 프로그램과 데이터베이스 서버 간의 통신을 관리한다.

MSSQL은 다른 RDBMS에서는 지원하지 않는 함수들도 제공한다.

T-SQL

T-SQL(Transact-SQL) 라고 불리는 프로그래밍 언어는, SQL-Server에서 사용된다. T-SQL은 SQL문법을 기반으로 한 확장된 형태의 언어인데, 데이터베이스 시스템의 데이터 관리, 데이터 조작, 저장 프로시저, 트리거, 함수 등을 정의하고 사용할 수 이쓴 강력한 기능을 제공한다. 다른 데이터베이스의 SQL과 문법적으로 굉장히 비슷하며, 마이크로소프트만의 기능이 있다.

다음은 T-SQL 에서만 지원하는 함수들이다. 추후에 자세히 다루겠지만, 지금은 간략하게 함수명과 어떠한 용도로 사용되는지만 작성하겠다.

T-SQL에서 제공하는 함수들

*FORMAT() * 지정된 형식의 문자열을 반환한다.

TRY_CONVERT() 데이터 형식을 변환하며, 변환에 실패하면 NULL을 반환한다.

CONCAT_WS()여러개의 문자열을 합칠 때 사용한다. 구분자를 지정하여 문자열을 연결할 수 있다.

STRING_AGG() 그룹화된 열의 값을 연결하여 문자열로 반환한다.

TRANSLATE() 문자열에서 지정된 문자를 다른 문자로 바꾼다.

IIF() 조건식에 따라 다른 값을 반환한다.

CHOOSE() 인덱스에 해당하는 값을 반환한다.

JSON_VALUE() JSON 문자열에서 지정된 속성의 값을 반환한다.

STRING_SPLIT() 문자열을 지정된 구분자로 분리하여 결과집합으로 반환한다.

COMPRESS() 데이터를 압축한다.

now(), curdate()

now() : 현재 날짜와 시간을 알려준다.

select now();

위 쿼리는 2023-03-10 14:29:36 로 반환된다.

curdate() : 현재의 날짜를 반환한다.

select curdate();

위 쿼리는 2023-03-10을 반환한다.

년/월/일/시간 추출

현재 시간에서 혹은 데이터베이스에 저장된 Date 타입의 데이터에서, 년도만 추출하고 싶거나 월만 추출하는 등 원하는 부분만 추출하여 조회할 수 있다.

1. 연도 추출

select year(now());

2. 월 추출

select month(now*());

3. 일 추출

   select date(now());

4. 시간

   select time(now());

time을 사용하는 경우 12:20:00 형태로 반환된다. 여기서 시, 분, 초 단위로 추출하고 싶다면 time대신 각각 hour, minute, second 를 작성하면 된다.

DATE_ADD(), DATE_SUB()

날짜에 연/월/일을 더하거나 뺄 수 있다.

DATE_ADD는 날짜에서 지정한 수 만큼 더한다.

select now() as 현재시간, date_add(now(), interval 1 day) as addDate;

위 코드를 간단하게 풀어보면, 현재날짜(now())에서 하루(1 day)를 더한 데이터가 조회된다. 한눈에 비교할 수 있도록 현재시간도 추가하여 조회한 결과는 아래와 같다.

쿼리에서 하루를 증가시키도록 작성했기 때문에, 현재 날짜와 add_date() 함수를 적용시킨 날짜를 비교해 보면 연도와 월은 같지만 일은 함수에서 지정해준 대로 1이 증가되어 있다.

하루 말고 10일을 증가시키고 싶다면 add_date 함수에서 수치만 조정해주면 된다. == 10 days

일 단위 말고도 월단위/연단위 증가도 모두 가능하다. 월단위 : date_add(now(), interval 1 month) 년단위 : date_add(now(), interval 2 year)

변경할 대상은 현재 날짜 말고도 date 형식이면 모두 올 수 있다.

select date_add('2023-02-01', interval 1 day);
select cu_name, cu_regdate 가입일자, date_add(cu_regdate, interval 1 day) add_date from my_customer;

'2023-02-01'이 첫번째 인자로 들어간 경우 조회하면 2023-02-02 가 반환된다. 두번째줄은 테이블에서 유저이름, 가입일자 컬럼과 add_date 함수로 가입일자에서 하루씩 증가시키도록 작성했다. date_add 함수의 첫번째 인자로 데이터베이스의 데이터타입 컬럼을 넘긴것이다.

두번재줄 쿼리를 돌린 결과다. 기존 가입 날짜와 add_date 컬럼을 비교해 보면 하루씩 증가가 된것을 볼 수 있다.

date_sub는 날짜에서 지정한 수 만큼 빼는 것이다.

select date_sub(now(), interval 1 month);

간단한 예시로 현재 날짜에서 한달을 빼도록 작성했다. 결과는 밑의 사진과 같이 나온다

사진을 보면 알 수 있듯이, 더하냐, 빼냐 그 차이일 뿐 date_add 함수와 작성하는 방법은 똑같다.

예시)

유저 테이블에서 가입한지 3개월 이내인 고객의 이름을 조회

select cu_name, cu_regdate from my_customer
where cu_regdate >= DATE_SUB(CURDATE(), INTERVAL 3 MONTH);

위 쿼리는 date_sub함수로 현재날짜에서 3개월을 뺀 날짜보다 같거나 큰 가입일자에 해당하는 유저를 반환하는 쿼리다. 현재날짜가 2023년 3월 10일이면, date_sub 함수에서 반환되는 날짜는 2022년 12월 10일이다.

조회조건인 유저의 가입일자가 2022년 12월 10일보다 큰 경우를 조회하는거니까 가입일자가 2022년 12월 10일부터 현재날짜까지 포함된 모든 유저의 이름을 반환한다.

DATEDIFF(), TIMEDIFF()

DATEDIFF : 두 날짜의 차이를 조회한다.

select datediff('2022-10-12', '2022-10-10');

두 날짜의 차이는 2일 이므로 쿼리 조회 시 2 라는 결과가 반환된다. 이 때 날짜 차이는 왼쪽을 기준으로 계산하는데, 왼쪽의 날짜가 오른쪽 날짜보다 크다면 양수를 반환하고, 적다면 음수로 반환된다.

select datediff('2022-10-12', '2022-10-14');

위 코드는 똑같이 2일 차이지만 2가 아닌 -2 를 반환한다. 왼쪽 날짜가 더 적으므로 음수로 반환되는 것이다.

TIMEDIFF : 두 시간의 차이를 조회한다.

select timediff('10:00:00', '09:00:00');

두 시간을 비교하면 조회되는 결과는 01:00:00 이다. 하지만 기준이 되는 앞의 시간이 뒤의 시간보다 늦다면 결과는 날짜를 비교하는 DATEDIFF() 함수와는 다른 형식으로 조회된다.

select timediff('10:00:00', '11:00:00');

왼쪽 시간이 오른쪽 시간보다 1시간이 늦다. 예상했던 조회결과는 -01:00:00 이었지만, 실제로 조회된 결과는 23:00:00 이다.

반환되는 값의 형식은 'HH:MM:SS' 인데, 이때 시간 값이 음수일 경우에 음수 부호 대신 하루를 나타내는 시간인 24를 더하여 양수 값으로 반환한다. 그래서 -1 에서 24를 더한 23:00:00 이 반환된다.

DATE_FORMAT()

DATE_FORMAT()은 날짜와 시간을 원하는 형식으로 지정할 수 있다. DATE_FORMAT() 함수 밑의 밑의 구문과 같이 사용된다.

DATE_FORMAT(date, format);

date는 날짜 형식(date, timestamp, datetime)의 데이터이며, format은 변환하고자 하는 날짜 형식을 지정하는 문자열이다.

SELECT DATE_FORMAT(NOW(), '%Y-%m-%d %H:%i:%s');

위 쿼리의 결과는 2023-03-10 10:30:00 로 현재 날짜를 지정한 형식으로 반환한다.

<날짜 FORMAT 코드>

%Y : 4자리 연도 (예: 2023) %y : 2자리 연도 (예: 23) %m : 월 (01부터 12까지) %c : 월 (1부터 12까지) %d : 일 (01부터 31까지) %e : 일 (1부터 31까지) %H : 24시간 형식으로 표시한 시 (00부터 23까지) %h : 12시간 형식으로 표시한 시 (01부터 12까지) %i : 분 (00부터 59까지) %s : 초 (00부터 59까지) %p : AM 또는 PM (대문자)

<구분자를 사용한 날짜 FORMAT 형식>

- : 하이픈(-) / : 슬래시(/) . : 마침표(.) : : 콜론(:) : 공백

예시)

SELECT DATE_FORMAT('2023-03-10', '%d-%m-%Y');

위 코드는 '2023-03-10' 을, 오른쪽의 날짜 포맷 형식에 맞춰서 반환될 것이다. '2023-03-10' 은 '%Y-%m-%d' 형식으로 되어있는데, 오른쪽의 날짜 포맷형식으로 바꾸면 조회되는 데이터는 '10-03-2023' 이다.

SELECT DATE_FORMAT('2023-03-10 14:30:45', '%Y년 %c월 %e일 %p %h시 %i분 %s초');

그럼 위의 쿼리는 어떻게 변경되어 나타날까? 구분자를 이용하여 날짜와 시간을 구분하는 대신 년,월,일,시,분,초로 형태를 지정하였으므로 조회되는 값은 아래와 같다.

2023년 3월 10일 오후 2시 30분 45초 와 같은 형식으로 조회될 것이다.

IFNULL()

IFNULL() 함수는 첫번째 인자값이 Null 인 경우, 두번째 인자값을 반환한다. 따라서 조회된 데이터가 Null인 경우, IFNULL 함수를 사용하여 다른 값을 반환할 수 있다.

예시)

위 사진에서 확인할 수 있듯이 유재석 유저는 email을 입력하지 않아 null로 표시되어 있다.

select * from cu_name, IFNULL(cu_email, '이메일없음') from my_customer;

위와 같이 IFNULL을 사용하여 첫번째 인자값인 이메일 컬럼의 값이 null인 경우, 두번째 인자값인 '입력안함' 으로 치환되어 표시되게 할 수 있다.

쿼리를 실행한 결과 위 사진같이 <null>로 표시됐던 데이터가 '이메일없음' 으로 치환되어 반환됐다.

COALESCE()

COALESCE() 함수는 여러개의 인자값을 받을 수 있다. 여러개의 인자를 받고 그 중 Null이 아닌 값을 반환한다.

위 사진을 보면 null값이 많이 보이는 유저 테이블이 보인다.

select cu_name, cu_phone, cu_address, coalesce(cu_phone, cu_address, '2번째대체값') from my_customer;

조회할 항목으로 coalesce를 추가해주면서 인자로 연락처, 주소, '2번째대체값' 으로 지정해줬다. 그 후 쿼리를 실행시키면 반환되는 테이블은 아래 사진과 같다. 맨 끝 컬럼에 coalesce 컬럼이 추가되면서, 전달받은 인자값 중 Null이 아닌 값이 표시된다. 고옹백 유저와 강태공 유저는 coalesce 인자로 전달된 cu_phone, cu_address 값이 모두 Null 이므로 마지막인자인 '두번째대체값' 이 채워진다. 강호동 유저는 cu_phone null값이지만 cu_address 컬럼에는 값이 있으므로 cu_address 값이 표시된다.

IS NULL / IS NOT NULL

1. IS NULL 조회되는 데이터가 null값인지 검사한다. 이 구문을 통해 지정한 컬럼이 null값인 경우에만 조회가 되도록 처리할 수 있다.

    select * from my_customer where cu_phone is null;

위의 쿼리를 실행하면 cu_phone이 null값인 행들만 조회된다.

2. IS NOT NULL 조회하려는 데이터가 null값이 아닌지 검사한다. 이 구문을 통해 지정한 컬럼이 null값인 경우는 조회가 되지 않도록 처리할 수 있다.

    select * from my_customer where cu_email is not null;

위의 쿼리를 실행하면 cu_email 이 null값이 아닌 행들만 조회된다.

IF함수 사용

조건문을 사용하여 조회된 데이터가 Null인 경우 다른 값을 출력하거나, 다른 처리를 할 수 있다. mariaDB 에서 IF함수는 다음과 같이 작성할 수 있다.

select IF(조건, 참일때 값, 거짓일때 값)

위의 구조에서 조건은 비교할 조건을 의미한다. 참일 때 값은 조건이 참인 경우 반환할 값, 거짓일 때 값은 조건이 거짓인 경우 반환할 값이다.

select IF(cu_phone is null, 'null값', cu_phone) as cu_phone
from my_customer;

위 쿼리를 풀어보자면 cu_phone 컬럼의 값이 null인 경우(true)에는 'null값'을 반환하고, cu_phone 컬럼의 값이 null이 아닌 경우(false)에는 해당 행의 cu_phone의 값을 그대로 반환한다는 뜻이다.

위의 쿼리를 실행시켜서 조회해보면, 7,8 행은 연락처 컬럼이 null이 아니라서 연락처 값을 그대로 반환, 9~11 행은 연락처 컬럼이 null이라서 IF함수에서 지정한 'null값' 이라는 문자열이 대체되어 조회된다.

IF함수는 null 값을 처리하는 것 말고도 다양한 경우에서 사용할 수 있을 것 같다. 다음에 기회가 된다면 IF함수로 처리할 수 있는 여러가지 경우를 터득하여 포스팅 할 계획이다.

서브쿼리란?

서브쿼리는 말그대로 메인쿼리에서 서브로 사용하는 또 다른 쿼리문이다. 메인쿼리에 종속적이며 서브쿼리가 사용되는 목적은 메인쿼리에서 최종적으로 필요한 데이터를 조회하기 위한 수단으로 사용된다.

서브쿼리는 더 복잡한 조건을 만족하는 검색이나 연산을 할 때 유용하므로 자주쓰이고 있다.

서브쿼리의 종류

중첩 서브쿼리(Nested Subquery)

WHERE절에서 사용하는 쿼리로, 서브쿼리 연산자를 사용하여 메인쿼리와 서브쿼리의 데이터를 비교하는 방식이다.

서브쿼리 연산자는 크게 비교 연산자와 EXISTS 연산자로 나눌 수 있다.

1. 비교연산자

비교 연산자는 서브쿼리의 결과값을 사용하여 메인쿼리의 조건식을 만족하는 데이터를 조회한다. 비교 연산자에는 대소비교 연산자(>, <, >=, <=), 등호연산자(=, <>) 등이 있다. 비교연산자를 활용하여 서브쿼리를 작성할 때는 서브쿼리로 조회되는 결과가 반드시 1건 이하여야 한다. == 단일행 서브쿼리

예시)

주문가격이 만원 이상인 고객들의 정보를 조회해보자

서브쿼리 없이 쿼리를 짠다면 밑의 코드처럼 될 것이다.

SELECT id
FROM 주문테이블
WHERE 주문가격 >= 10000;

SELECT id, 이름, 이메일
FROM 고객테이블
WHERE id in (위에서 실행한 쿼리의 결과값)

이렇게 두번에 걸쳐서 먼저 조건을 충족하는 고객id를 조회하는 쿼리를 작성 한 후에, 새로운 쿼리로 위의 쿼리에서 받은 조회결과를 조건으로 만족하는 름, 이메일을 다시 조회한다.

쿼리를 두번에 걸쳐서 짜줘야 해서 복잡하다. 서브쿼리를 사용하면 위의 두 개의 쿼리를 하나의 쿼리로 사용이 가능하다.

SELECT id, 이름, 이메일
FROM 고객테이블
WHERE id IN (
  SELECT 고객id
  FROM 주문테이블
  WHERE 주문가격 >= 10000
);

위 코드는 서브쿼리를 활용하여 처음에 따로 각각 작성했던 코드를 합친거랑 똑같은 결과가 조회된다.

메인쿼리의 조회 조건인 where절에서 ( ) 괄호안에 조건으로 사용할 데이터를 조회하는 서브쿼리를 작성해주면 된다.

2. EXISTS 연산자

EXISTS 연산자는 서브쿼리의 결과값이 존재 하는지 여부를 확인하여 메인쿼리의 조건식을 만족하는 데이터를 조회한다. 만약 결과값이 존재한다면 true를 반환하고, 존재하지 않으면 false를 반환한다. EXISTS 연산자는 NOT EXISTS 연산자와 함께 사용하며, 서브쿼리의 결과값이 존재하지 않는 데이터를 조회할 수도 있다.

예시)

고객 테이블에서 존재하는 이메일을 사용하는 주문이 있는지 확인하는 쿼리

SELECT *
FROM 고객테이블
WHERE EXISTS (
  SELECT *
  FROM 주문테이블
  WHERE 고객테이블.id = 주문테이블.고객id
    AND 고객테이블.이메일 = 주문테이블.이메일
);

위의 쿼리를 실행하면, 먼저 where절에 있는 exists 연산자로 평가될 서브쿼리가 먼저 실행된다. 만약 서브쿼리의 안에서 조회되는 행이 있다면(고객의 아이디와 일치하는 이메일을 사용하는 주문건수가 있다면), 즉 조회한 결과가 true 라면 해당 행을 모두 반환한다. 이 때 반환되는 행들은 여러행이 될 수 있다. == 다중 서브쿼리 만약 exists를 not exists로 바꾼다면 exists와 반대로 주문내역이 없는 고객정보가 담긴 행만 반환하게 된다.

인라인 뷰(Inline View)

FROM절에서 사용하는 서브쿼리. FROM절에는 조회할 테이블을 작성하는데, FROM절에서 서브쿼리를 사용한다면 서브쿼리에 의해 선택된 결과집합은 하나의 테이블로써 사용되므로 반드시 이름(별칭)이 필요하다.

예시)

주문을 한 고객중에서 가장 많은 금액을 결제한 정보를 조회

select main.*
from (
    select mc.*, sum(order_price) as 총주문금액
    from my_order o
    join my_customer mc on o.cu_id = mc.cu_id
    group by mc.cu_id
    order by 총주문금액 desc
    limit 1
     ) as main;

from절에 오는 서브쿼리에서는 조건을 만족하는 고객의 정보를 조회하는 쿼리문에 들어간다. 조회된 결과셋은 테이블로써 사용되므로 main 이라는 별칭이 들어간다.

메인쿼리에서 조회되는 * 는 모든 정보를 의미하는데, from절에서 조회되는 컬럼들에 한해서 조회가 가능하다.

근데 생각해보니, 저 예시는 from절 서브쿼리를 사용하지 않고 join으로도 조회가 가능한 것 같아서 쿼리를 짜보았다.

select m.*, sum(o.order_price) 총주문금액 from my_customer as m
join my_order o on m.cu_id = o.cu_id
group by m.cu_id
order by 총주문금액 desc
limit 1;

from절에 서브쿼리를 작성하지 않고 고객테이블과, 주문테이블을 조인하여 결과를 돌려봐도 결과는 똑같다.

동일한 결과를 반환한다면 인라인뷰와 join을 사용하는 방식과의 차이점은 뭘까?

*FROM절 서브쿼리 * FROM절에서 서브쿼리를 사용하는 방식은 서브쿼리 결과를 새로운 가상 테이블 만들어서 사용하는 방식이다. 따라서 서브쿼리가 실행될 때마다 해당 서브쿼리를 계산하고, 이를 메모리에 저장한 후에 다시 이를 이용해서 새로운 가상테이블을 만들어서 사용한다.

1. 서브쿼리 계산
2. 결과값 메모리에 저장
3. 새로운 가상테이블을 만들어서 사용 이 방식은 간단하지만 서브쿼리의 결과가 크거나 복잡할 경우에는 성능 이슈가 발생할 수 있다.

JOIN JOIN을 사용하는 방식은 두개 이상의 테이블을 합쳐서 결과를 가져오는 방식이다. 이 방식은 조인할 테이블이 많을수록 더 복잡해질 수 있지만, FROM절에 서브쿼리를 사용하는 것 보다 성능면에서 더 좋다.

결론 따라서, 일반적으로 데이터 양이 많거나 복잡한 쿼리의 경우에는 JOIN 방식을 사용하는 것이 더 좋다.

스칼라 서브쿼리(Scalar Subquery)

SELECT절에서 사용하는 서브쿼리다. 스칼라는 하나의 수치만으로 완전히 표시되는 값 이라는 단어의 뜻 그대로 하나의 행만 반환하고, 일치하는 값이 없다면 Null을 반환한다.

서브쿼리로 조회된 결과를 조회할 컬럼으로 사용한다.

예시)

가장 많이 주문한 고객의 이름과, 주문횟수 조회

SELECT 
  이름, 
  (SELECT COUNT(*) FROM 주문테이블 WHERE 고객id = 고객테이블.id) AS 주문횟수 
FROM 
  고객테이블 
ORDER BY 
  주문횟수 DESC 
LIMIT 1

위의 쿼리에서는 count함수로 주문횟수를 같이 조회하기 위해 select 절에 서브쿼리를 사용한 경우다.

다음은 스칼라 서브쿼리를 사용하지 않고 Join을 이용하여 같은 결과값을 조회하는 쿼리다.

select cu_name, count(*) 주문횟수 from my_order o
join my_customer mc on o.cu_id = mc.cu_id
group by mc.cu_id
order by 주문횟수 desc limit 1;

두 쿼리의 결과값은 동일하지만, 첫번째 쿼리는 스칼라 서브쿼리를 사용하여 각 고객의 주문횟수를 구하고, 그 결과를 각각의 행에 추가한다. 두번째 쿼리는 join을 사용하여 고객별 주문 수를 구한다. 조회하려는 데이터의 규모가 작다면 스칼라 서브쿼리나 join 중 어느것을 사용해도 큰 상관이 없지만, 대부분의 경우 더 효율적이고 빠른 join을 사용하는것이 더 권장된다.

자바스크립트의 대표적인 특징으로는 비동기처리, 병렬처리, 동시성 등.. 들어보긴 했지만, 당연히 되는 거라고 생각을 해왔다. 근데 자바스크립트는 싱글쓰레드로 동작을 하는 언어다.

싱글쓰레드는 자바스크립트 엔진에서 관리하는 하나의 호출스택(call stack)과 하나의 메모리힙(memory heap)만을 사용한다는 것을 의미한다.

자바스크립트 엔진 코드를 해석하고 실행하는 역할을 수행. 대표적으로 v8 엔진이 사용되며, 코드의 문법검사, 바이트코드로의 컴파일, 메모리관리, 콜스택의 구현 등을 수행한다. 호출스택 함수가 호출되면서 스택으로 쌓이는 곳 메모리힙 메모리 할당을 담당하는 곳

함수 호출 시 해당 함수의 실행 컨텍스트를 호출 스택에 쌓아 올리고, 함수가 반환되면 해당 실행 컨테스트를 스택에서 제거한다.

이렇듯 실행중인 함수를 쌓아두는 곳인 호출스택이 한개이기 때문에, 동시에 하나의 작업만 가능하다. 근데 어떻게 비동기 처리가 가능하게 된 걸까?

위의 사진에서 보면, 자바스크립트 엔진인 V8이 갖고있는 하나의 콜스택과 메모리힙이 보이고, 웹브라우저에서 제공하는 Web API가 있다는 것을 알 수 있다. Web API는 자바스크립트에서 제공되지 않는 브라우저의 기능을 활용할 수 있도록 제공되는 비동기처리 API 인데, 대표적으로 setTimeout, ajax, setInterval 등의 함수가 포함된다.

자바스크립트에서는 일반적으로 콜백함수를 사용하여 비동기작업을 처리한다. 대표적인 예로 setTimeout 함수를 사용하면, 일정 시간이 지난 후에 콜백 함수가 호출된다.

이러한 콜백함수는 호출 스택에 직접 추가되지 않고, Web API에서 비동기적인 처리를 마친 후 콜백큐에 저장된다. 이 콜백큐는 호출스택과는 별도의 큐로서, 콜백 함수들이 대기하고 있다.

Web API가 처리하는 비동기 작업과 콜백함수가 콜백큐에 추가되는 과정은 예로 다음과 같다.

console.log('aaa');

const button = document.querySelector('button');
button.addEventListener('click', () => {
  console.log('bbb');
});

console.log('ccc');

// 출력순서 : aaa, ccc

위 코드는 버튼 클릭이벤트를 처리하는 이벤트 핸들러를 등록하고, 버튼을 클릭하여 이벤트가 발생하면 콜백함수를 실행하는 코드다. 이 때 Web API가 하는 역할을 알아보자.

• 이벤트핸들러 등록 : addEventListener 메소드를 사용하여 버튼클릭 이벤트 핸들러를 등록
• 이벤트 대기 : 이벤트가 발생할 때 까지 대기
• 콜백 함수 추가 : 이벤트가 발생하면 콜백 함수를 콜백큐에 추가

위의 코드에서 aaa, ccc만 출력되는 이유는 아직 클릭이벤트가 발생하지 않았기 때문이다. 단지 Web Api는 버튼클릭 이벤트 핸들러를 등록해놓고, 클릭이벤트가 발생하면 그때 콜백함수를 콜백큐에 넘겨준다.

그럼 비동기처리의 결과로 콜백큐에 저장되어있는 콜백함수는 어떻게 실행되는걸까?

사진에서 보이는 event loop는 여기서 등장하게 되는데, 콜스택과 콜백큐를 모니터링하며 콜스택이 비어있을 때 콜백큐에서 콜백함수를 꺼내어 실행한다. 이벤트 루프는 계속해서 호출 스택과 콜백큐를 감시하면서 반복적으로 실행된다.

데이터들은 하나의 테이블에 모두 저장되는게 아니라, 데이터의 성격에 따라 여러 테이블에 나뉘어서 저장된다. 데이터의 성격에 따라 다른 테이블에 나뉘어 저장된다 해도, 테이블끼리 서로 유기적으로 연관되어 있는 경우가 대부분이다.

테이블별로 분리되어 있는 데이터들을 연결해서 하나의 셋으로 출력해야 할 때 쓰는 구문이 Join 이다.

만약 주문 테이블과 리뷰 테이블이 있다고 가정해보자.

주문내역에는 존재하지만, 리뷰를 작성하지 않아서 리뷰테이블에는 없는 데이터가 있을 수 있다.

이 때 주문 테이블과 리뷰 테이블을 Join하여 데이터를 조회할 때 리뷰가 없는 주문건도 조회를 할지, 아니면 리뷰가 작성된 주문건만 조회할 지 선택해야 한다.

join에는 여러 종류가 있는데, 출력하고자 하는 형식에 따라 join 종류 중 필요한 join 구문을 사용해야 한다.

1. inner join

inner join은 교집합 연산과 같다. 조회하려는 컬럼이 조인하려는 테이블 모두에 공통적으로 존재하는 데이터만 조인하여 출력한다.

20개의 주문건수가 존재하는 주문테이블과, 12개의 리뷰내역이 존재하는 테이블 두 개를 inner join 으로 조회하는 구문은 이렇다.

select o.order_state, o.order_price, r.review_content, r.review_score as 점수 from my_order o
left outer join my_review r
on o.order_id = r.order_id;

20행의 주문테이블과, 12행의 리뷰테이블을 left join 으로 묶어서 조회한 결과 리뷰내역이 존재하는 12개의 행들만 조회가 된다.

만약 여기서 리뷰가 쓰여지지 않은 주문내역도 같이 조회를 하고싶으면 어떻게 할까?

inner 를 left outer로 바꿔주면 된다.

left outer join

left outer join의 용도로 생각해볼 수 있는 것 중 하나는 다음과 같다.

만약 상품을 정렬하는 기능 중 '리뷰많은순' 으로 정렬을 해야한다고 가정해보자. 그 중 어제 등록된 상품은 아직 주문이 들어오지 않아 리뷰개수가 0일 것이다.

하지만 리뷰많은순 정렬을 클릭했을 때는 리뷰개수가 0인 상품들도 나와야 한다. 등록된 리뷰가 없다고 상품 목록에서 제외를 시키는것은 안되는데, 만약 이때 inner join을 이용하여 상품 목록을 보여주게 된다면 리뷰개수가 0인 상품들은 조회가 되지 않을것이다.

이때 사용하는 조인이 left outer join이다.

위에 사진은 inner join 으로 12개의 행이 조회되는 것을 볼 수 있다.

select count(*) from my_order as o
left outer join my_review r
on o.order_id = r.order_id;

이렇게 left outer 조인으로 바꿔주게 된다면 count 컬럼의 값은 inner join의 결과로 집계됐던 12행이 아닌 20행일 것이다. 리뷰가 0개인 것들도 조회를 해주는 것이다.

더 추가적으로 설명하자면 left outer join은 왼쪽에 오는 행이 기준이 된다. 위의 코드로 설명해보면 주문 테이블을 기준으로 리뷰 테이블을 조인한다. 조회 결과는 기준이 되는 왼쪽테이블의 모든 행과 오른쪽 테이블의 매칭되는 행을 조인하게되는데, 만약 오른쪽 테이블에서 매칭되는 행이 없으면 NULL 값이 반환된다.

left outer join과 반대되는 right outer join 은, 오른쪽 컬럼이 기준컬럼이 되어 오른쪽 테이블의 모든 행과 왼쪽 테이블의 매칭되는 행을 조인하게 된다.

Full outer join

full outer join은 기준이 되는 테이블이 없다. 상품테이블과 리뷰테이블을 조인하여 조회할 때 서로 매칭되는 값이 없어도 모두 출력해주는 합집합과 비슷하다. A테이블에만 존재하는 행 + B테이블에만 존재하는 행 + A,B 에 모두 존재하는 행(교집합)을 모두 출력할 때 full outer join을 사용한다.(모든 행이 조건에 관계없이 결합)

현재 사용중인 mariaDB는 Full outer join을 지원하지 않는다. mariaDB에서 full outer join을 사용하려면 union을 이용하여 조회해야 한다.

select pro_name, pro_price, review_content, review_score from my_products as p
left outer join my_review r
on p.pro_id = r.pro_id
union
select pro_name, pro_price, review_content, review_score from my_products as p
right outer join my_review r
on p.pro_id = r.pro_id;

full outer join은 결국 left outer join과 right outer join을 합친 것이기 때문에 두 조인 구문을 union을 이용해서 합쳐주면 결합한 모든 행들이 조회가 된다.

SQL에서 사용되는 중요한 구문 중 하나. 데이터를 그룹화하여 집계 함수를 사용하여 통계 정보를 생성하는 데 사용된다.

위 사진은 주문 테이블을 전체 조회한 결과다. 이 중에서 cu_id(고객id)가 1인 경우에만 조회하려면 다음과 같이 쿼리를 작성할 수 있다.

select * from my_order where cu_id = 1;

그럼 아래 사진처럼 cu_id가 1인 행들만 조회가 된다.

여기서 만약, 고객별로 총 구매개수를 알고싶으면 어떻게 해야할까? cu_id(고객id) 컬럼을 그룹화하여 주문수량의 총 개수를 구하면 된다. 그럴때 사용하는 구문이 Group by절이다.

그룹함수는 집계함수와 같이 사용된다. 집계함수는 그룹화된 각 컬럼 데이터들의 통계를 내기 위해 사용되는 함수다.

1. sum : 값을 모두 합산하여 반환한다.
2. avg : 평균값을 반환한다.
3. count : 열의 값을 모두 세어 반환한다.
4. max : 가장 큰 값을 반환한다.

group by절과 집계함수를 같이 사용하여 고객별로 총 구매수량을 구하는 함수는 아래와 같다.

select cu_id, sum(order_quantity) from my_order group by cu_id;

총 구매수량을 알기 위해 sum 집계함수를 사용했다. 만약 총 구매수량이 아니라 주문 횟수를 구하고 싶다면 sum 대신 count를 넣어서 조회하면 된다.

결론은 생각보다 간편하게 설치를 완료했다. 프로그램을 os에 맞게 설치하는 번거로운 과정도 없었다. 현재 맥os를 사용중인데 맥은 맥os용 패키지 관리자인 홈브류(Homebrew)라는 어플리케이션이 있다. 맥os로 프로그래밍을 하는 개발자에게는 거의 필수적인 도구이다. 필요한 도구나 시스템 패키지들을 설치하는 데 사용된다.

나는 아주 유용한 이 홈브류 어플리케이션을 통해 mysql 데이터베이스를 쉽게 설치하였다.

1. Homebrew 업데이트 $ brew update

2. my sql 설치 $ brew install mysql

설치가 무사히 완료되면 mysql_secure_intallation 문구가 출력된다! 이제 실행단계로 넘어가서 비밀번호를 설정해보자.

3. mysql -u root -p 명령어 입력 password를 입력하는 문구가 출력되는데 비번을 설정하지 않았으면 아무것도 입력하지 않고 엔터를 치면 된다.

4. user mysql 입력

5. select host, user, authentication_string from user; 위의 명령어를 입력하면 현재 패스워드 설정과 관련된 내용 리스트가 출력된다.

6. alter user 'root'@'localhost' identified with mysql_native_password by 'new_password_you_want' 유저정보를 수정하겠다는 명령어로 'new_password_you_want' 부분에 원하는 비밀번호를 입력한다.

이제 터미널에서 명령어로 설치하고 설정해줘야 하는 단계는 완료됐다. 본격적으로 인텔리제이로 넘어가서 DB와 연결해주면 된다.

7. 인텔리제이 - database - new(+) - mysql - 계정정보 입력 테스트 커넥션으로 접속테스트를 해본 후 성공하면 커넥션으로 연결해주자

8. 연동에 성공했으니 server object - 쿼리콘솔을 클릭하여 쿼리콘솔창을 연 후에 원하는 쿼리를 입력하여 실행!

Mustache란?

스프링과 같은 웹 프레임워크에서 사용되는 템플릿 엔진중 하나. Mustache는 간단하고 직관적인 구문을 사용하여 HTML, XML, JSON 등 다양한 형식의 템플릿을 작성할 수 있다.

Mustache 템플릿에서는 변수, 반복문, 조건문 등의 기본적인 로직을 작성할 수 있으며 HTML 태그나 자바스크립트 코드와 같은 부분을 제외한 일반 텍스트를 그대로 출력하므로, 코드의 가독성을 높이는 장점이 있다.

또한 수많은 언어를 지원하는 가장 심플한 템플릿 엔진으로 루비, 자바스크립트, 파이썬, PHP, 자바, 펄, Go, ASP 등 현존하는 대부분 언어를 지원하고 있다. 그래서 자바에서 사용될 때는 서버 템플릿 엔진으로, 자바스크립트에서 사용될 때는 클라이언트 템플릿 엔진으로 모두 사용할 수 있다.

자바 진영에서는 jsp, Thymeleaf 등의 서버 템플릿 엔진이 있는데, jsp는 이미 활용을 많이 해봤고 Thymeleaf는 아직 나에게는 문법이 다소 어려울 것 같아서 다른 템플릿 엔진보다 심플한 머스테치가 적당할 것 같다.

Mustache 플러그인 설치

인텔리제이 Plugins - Marketplace로 이동하여 Handlebars/Mustache를 선택 후 설치한다.

기본 페이지 만들기

1. 설치 후 가장먼저 해야 할 것은 build.gradle에 의존성을 등록하는 것이다.

   implementation 'org.springframework.boot:spring-boot-starter-mustache'

2. 그 다음으로 index.mustache를 src/main/resources/templates에 생성한다. 이 경로에 머스테치 파일을 두면 스프링 부트에서 자동으로 로딩한다.

3. index.mustache 코드를 채워주자

   <!DOCTYPE HTML>
   <html>
   <head>
    <title>스프링 부트 웹서비스</title>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
   </head>
   

스프링 웹서비스!

4. URL 매핑하기 매핑할 컨트롤러를 생성하여 다음과 같이 코드를 적어주자.

   @Controller
   public class indexController {
   
    @GetMapping("/")
    public String index() {
        return "index";
    }
   }

Test 코드 작성

여기까지 코드가 완성 되었으니, 이번에도 테스트 코드로 검증을 해보자.

@RunWith(SpringRunner.class)
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
public class IndexControllerTest {

    @Autowired
    private TestRestTemplate restTemplate;

    @Test
    public void mainPageLoading() {
        //when
        String body = this.restTemplate.getForObject("/", String.class);

        //then
        assertThat(body).contains("스프링 웹서비스");
    }
}

위 코드에서는 랜덤포트를 할당받고, TestRestTemplate을 사용하여 요청을 보내고 응답을 받는다. 그 후 assertThat을 사용하여 응답 body에 "스프링 웹서비스" 라는 문자열이 포함되어 있는지 검증한 후, 포함된다면 성공하고 포함되지 않는다면 실패하는 테스트 코드다.

TestRestTemplate의 getForObject 메소드는 HTTP GET 요청을 보내고 해당 URL의 응답을 객체로 반환한다. 위 코드에서는 '/' 경로에 GET 요청을 보내고, 반환된 응답을 String 형식으로 받아서 body 변수에 저장하게 된다.

참고로 body를 콘솔창에 출력해 보면 다음과 같다.

localhost:8080 경로로 접속해보면 화면에서도 잘 뜨는 것이 확인된다.

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

`` ERR! code ERESOLVE npm ERR! ERESOLVE could not resolve npm ERR! npm ERR! While resolving: @vue/eslint-config-standard@6.1.0 npm ERR! Found: eslint-plugin-vue@8.7.1 npm ERR! node_modules/eslint-plugin-vue npm ERR! dev eslint-plugin-vue@"^8.0.3" from the root project npm ERR! npm ERR! Could not resolve dependency: npm ERR! peer eslint-plugin-vue@"^7.0.0" from @vue/eslint-config-standard@6.1.0 npm ERR! node_modules/@vue/eslint-config-standard npm ERR! dev @vue/eslint-config-standard@"^6.1.0" from the root project npm ERR! npm ERR! Conflicting peer dependency: eslint-plugin-vue@7.20.0 npm ERR! node_modules/eslint-plugin-vue npm ERR! peer eslint-plugin-vue@"^7.0.0" from @vue/eslint-config-standard@6.1.0 npm ERR! node_modules/@vue/eslint-config-standard npm ERR! dev @vue/eslint-config-standard@"^6.1.0" from the root project npm ERR! npm ERR! Fix the upstream dependency conflict, or retry npm ERR! this command with --force, or --legacy-peer-deps npm ERR! to accept an incorrect (and potentially broken) dependency resolution. npm ERR! npm ERR! See /Users/경로/.npm/eresolve-report.txt for a full report.

npm ERR! A complete log of this run can be found in: npm ERR! /Users/경로/.npm/_logs/2023-02-09T04_09_30_005Z-debug-0.log minyounglee@Mins-MacBook-Pro vuestagram % npm install axios npm ERR! code ETARGET npm ERR! notarget No matching version found for @vue/eslint-config-standard@^8.0.3. npm ERR! notarget In most cases you or one of your dependencies are requesting npm ERR! notarget a package version that doesn't exist.

npm ERR! A complete log of this run can be found in: npm ERR! /경로/.npm/_logs/2023-02-09T04_16_30_419Z-debug-0.log ``

종속성을 해결할 수 없어서 발생한 오류. package.json 파일을 확인하니 @vue/eslint-config-standard 버전이 6.1.0 버전으로 되어있는데 설치된 모듈과 호환되지 않는 피어 종속성이 있는 것 같다.

해결방법 "eslint-plugin-vue": "^7.20.0" eslint의 플러그인 버전을 위와 같이 수정해 준 뒤 다시 설치를 시도한 결과 성공적으로 설치되었다

이번에 프로젝트를 생성 한 방법도 정석은 아니다. 앞으로 여러 Vue.js 3 프로젝트를 생성하면서 숙련된다면 추후에 수정할 예정이다.

우선 내가 프로젝트를 생성한 방법을 작성해보자...

1. 프로젝트를 생성할 디렉토리 만들기
2. 개발할 프레임워크 상단메뉴 File-Open 클릭하여 생성한 디렉토리 불러오기 (내가 쓰는 프레임워크는 인텔리제이!)
3. 로컬 터미널에서 node.js 버전 확인 node -v 확인되지 않다면 아래 링크로 접속하여 설치해주자. https://nodejs.org/ko/download/

• node.js는 npm을 사용하기 위해 필요하다.
• npm은 노드 패키지 매니저의 약자로 패키지를 관리하는 곳이다.

4. vue/cli 설치 npm install -g @vue/cli

위의 네 과정으로 vue 프로젝트를 생성하기 위한 준비는 끝났다. 이제 본격적으로 vue 프로젝트를 생성 해보자!

vue create 프로젝트명 그 후 사용하는 버전을 설정해 주면 vue 프로젝트 생성이 완료된다.

cd 프로젝트명 를 입력하여 생성된 프로젝트로 경로 이동을 한 후 npm run serve 명령어를 입력하여 프로젝트를 실행해 준다.

마지막으로 프로젝트가 무사히 실행된 것을 확인하려면 터미널창에 실행 성공 후 띄워진 localhost 주소로 접속하여 확인하면 된다.

이렇게 개발환경 세팅은 의외로 간단하다.

Tool : Spring Tool Suite 3 Project : Gradle Project Spring Boot : 2.3.7 Language : Java Java : 16

1. 프로젝트 생성

https://start.spring.io 페이지로 접속하면 쉽게 프로젝트를 생성할 수 있다.

*2. STS에서 생성한 프로젝트 Import *

프로젝트를 Import로 가져오는건 성공했지만, 예상대로 프로젝트에 빨간 x표시가 떴다.

알아보니 내가 사용하고 있는 JDK 버전은 11버전이였고, 프로젝트에서 요구하는 버전은 16버전 이였다.

JDK 16버전 설치를 한 뒤 Build Path에서 버전 재설정, 자바 컴파일러 재설정을 마쳐주니 x표시가 깔끔하게 사라졌다!

3. 실행하기

Run으로 실행을 돌려본 결과 콘솔창에 메세지들이 많이 뜬다! 하지만 한가지 거슬리는게 있으니.. INFO 속에 끼어든 WARN 메세지..

Web server failed to start. Port 8080 was already in use.

Action:

Identify and stop the process that's listening on port 8080 or configure this application to listen on another port.

8080은 이미 사용중인 포트번호라는 오류같다. 그럼 포트번호만 바꿔주도록 하자!

application.properties 파일을 연 다음에

#port change
server.port=8082

코드를 추가하도록 하자. 저장하고 난 후 다시 돌려보니 거슬리던 WARN 메세지가 사라졌다.

지속연결(Persistent Connections)

HTTP/1.1과 일부 HTTP/1.0에서는 TCP연결 문제를 해결하기 위해 지속연결을 고안하였다. 지속연결은 어느 한 쪽이** 명시적으로 연결을 종료하지 않는 이상 TCP연결을 계속 유지**하는 특징이 있다. 즉 한번의 연결로 여러번의 리퀘스트를 요청하고 리스폰스를 받을 수 있게 되었다. TCP커넥션의 연결과 종료를 반복하는 오버헤드를 줄이게 되고, 서버에 대한 과부하가 경감되며 리퀘스트/리스폰스가 빠르게 이루어진다는 장점을 갖고 있다.

파이프라인화

지속연결은 여러 리퀘스트를 보낼 수 있도록 파이프라인(HTTP pipelining)화를 가능하게 한다. 이전에는 리퀘스트 송신 후에 리스폰스를 수신할 때까지 기다린 뒤에 그다음 리퀘스트를 송신했던 것을 리스폰스를 기다리지 않고 바로 다음 리퀘스트를 연속적으로 보낼 수 있게 된 것이다.

쿠키

HTTP는 stateless 프로토콜이기 때문에, 과거에 교환했었던 리퀘스트와 리스폰스의 상태를 관리하지 않는다. 과거의 상태를 근거로 해서 현재 리퀘스트를 처리하는게 불가능하다. 이러한 특징들로 서버의 CPU나 메모리같은 리소스의 소비를 줄일수 있는 장점도 있다. 하지만 큰 단점도 존재하게 되는데 어떤 사이트에서 로그인을 한 뒤에 잠시 다른 사이트를 방문했다가 돌아왔을 때 로그인이 유지되지가 않아 불편함을 유발하는 점이다. 이러한 단점을 보완하기 위해 쿠키라는 시스템이 도입됐다.

쿠키는 서버에서 클라이언트로 리퀘스트에 대한 리스폰스를 보낼 때 쿠키를 발행하여 같이 송신한다. 리스폰스를 받은 클라이언트는 리스폰스로 보내진 Set-Cookie라는 헤더필드에 의해 쿠키를 보존하게 된다.

그 다음 재차 통신을 하게 될 때 클라이언트는 리퀘스트에 쿠키를 붙여서 송신하게 되면, 서버에서는 쿠키를 확인해서 어느 클라이언트가 접속했는지 확인하고 서버상의 기록을 확인해 이전 상태를 알 수 있게된다.

GET /reader/HTTP/1.1 Host: www.youngjin.com

2. 리스폰스(서버가 쿠키를 발행하여 송신)

HTTP /1.1 2000 OK DATE : The. 12 Jul 2012 07:12:20 GMT Server: Apache <Set-Cookie: sid=1342077140226724; // 내용생략>

3. 리퀘스트(보관하고 있던 쿠키를 자동 송신)

GET /image/HTTP/1.1 Host: www.youngjin.com Cookie: sid=1342077140226724

참고 : 그림으로 배우는 HTTP & Network Basic 참고 : 성공과 실패를 결정하는 1%의 네트워크 원리