기존에 카카오 로그인은 카카오 OAuth 인증을 담당하는 KakaoOAuthProvider가 OAuthProvider 인터페이스를 구현하는 구조였는데, 구글 로그인 방식을 추가하는 과정에서 구글을 독립적으로 구현할지, 아니면 범용 구조로 리팩토링할지 고민했다.

인터페이스를 활용하지 않고 구글 로그인을 독립적으로 구현한다면, 인터페이스 리팩토링 없이 GoogleOAuthProvider만 새로 구현하면 된다는 장점이 있었다.

KakaoOAuthProvider implements OAuthProvider
GoogleOAuthProvider  // 인터페이스 구현 안 함

와 같은 구조가 되는데, 해당 방식은 기존의 카카오 코드를 건드리지 않아 위험이 적고, 빠른 구현이 가능하다.

하지만, OAuthProvider라는 인터페이스가 이미 존재하는 상황에서 구글만 인터페이스를 구현하지 않으면 구조의 일관성이 깨진다고 판단했다. 둘 다 소셜 로그인이지만 AuthService에서도 카카오는 인터페이스 타입으로, 구글은 구체 클래스 타입으로 주입을 받는 어색한 상황이 생길 것이다.

또, 범용 구조로 리팩토링 하는 건 시간이 조금 더 걸릴지라도, 유지보수와 확장 측면에서 장점이 확실하였다.

유지보수 - 각 Provider는 자신의 API 응답만 파싱하고, AuthService는 공통 DTO만 다루면 된다. 만약 카카오가 API 응답 구조를 변경하더라도 KakaoOAuthProvider 내부만 수정하면 되고, AuthService는 건드릴 필요가 없다. 즉, 변경의 영향 범위가 최소화된다.

확장 - 또, 추후 새로운 소셜 로그인 방식이 추가된다면 OAuthProvider 인터페이스를 구현한 새 Provider 클래스만 만들면 되게 된다. AuthService의 기존 코드를 수정할 필요 없이, 새 Provider를 주입받아 사용할 수 있게 된다. 즉, 기존 코드를 건드리지 않고 기능을 추가할 수 있는 구조가 된다.

객체지향 설계원칙 중 OCP(개방-폐쇄 원칙)을 고려하였을 때도 범용 구조로 리팩토링을 진행하는 것이 좋을 것 같아, 범용 구조로 리팩토링을 진행하게 되었다.

OAuthUserInfoDTO 추가

범용 구조로 리팩토링을 진행하다보니, 한 가지 고민이 생겼다. 소셜 서비스로부터 사용자 정보를 전달 받을 때, 카카오와 구글에서 전달해주는 응답 구조가 달랐기 때문이다.

Kakao는 다음과 같이 중첩 구조로 응답을 주고,

{
  "id": 123456,
  "kakao_account": {
    "email": "test@kakao.com"
  }
}

Google에서는 다음과 같은 플랫 구조로 응답을 준다.

{
  "id": "123456",
  "email": "test@gmail.com"
}

어떻게 할지 고민을 하다 _Provider에서 API 응답을 자신에게 맞는 형태로 파싱한 뒤, 공통 DTO로 변환해주는 방식_으로 처리하였다.

카카오 응답 → KakaoUserInfoResponseDTO (중첩구조)
                    ↓ 변환
              OAuthUserInfoDTO(id, email)  ← 공통

구글 응답  → GoogleUserInfoResponseDTO (flat구조)
                    ↓ 변환
              OAuthUserInfoDTO(id, email)  ← 공통

KakaoUserInfoResponseDTO와 GoogleUserInfoResponseDTO는 각각 카카오, 구글의 API 응답 파싱용이고, OAuthUserInfoDTO는 유저의 정보를 AuthService에 전달해주는 공통 DTO이다.

현재 서비스에서 소셜 사용자의 소셜ID와 이메일 정보를 필요로 했기 때문에, 최종 코드는 다음과 같이 작성하였다.

KakaoUserInfoResponseDTO (기존 코드 유지)

package com.cookeep.cookeep.domain.user.dto;

import com.fasterxml.jackson.annotation.JsonIgnoreProperties;
import com.fasterxml.jackson.annotation.JsonProperty;

// DTO에서 요구로 하는 필드만 받아오도록 함
@JsonIgnoreProperties(ignoreUnknown = true)
public record KakaoUserInfoResponseDTO(
    @JsonProperty("id")
    Long id,

    @JsonProperty("kakao_account")
    KakaoAccount kakaoAccount
) {
    @JsonIgnoreProperties(ignoreUnknown = true)
    public record KakaoAccount(
        @JsonProperty("email")
        String email
    ) {}
}

package com.cookeep.cookeep.domain.user.dto;

import com.fasterxml.jackson.annotation.JsonIgnoreProperties;
import com.fasterxml.jackson.annotation.JsonProperty;

@JsonIgnoreProperties(ignoreUnknown = true)
public record GoogleUserInfoResponseDTO(
    @JsonProperty("id") String id,
    @JsonProperty("email") String email
) {
}

package com.cookeep.cookeep.domain.user.dto;

// 카카오, 구글 모두 공통적으로 소셜ID, 이메일 정보 필요
public record OAuthUserInfoDTO(
    String id,
    String email
) {
}

OAuthUserInfoDTO는 JSON을 직접 파싱하는 게 아니라 각 Provider에서 Java 코드로 직접 생성되므로 Jackson 어노테이션이 필요 없다. 또한 카카오는 id가 숫자(Long)이지만 구글은 문자열(String)로 내려온다. 서로 다른 타입(Long, String)을 일관되게 처리하기 위해 String으로 변환하였다.

OAuthProvider 범용 구조로 리팩토링

다음으로는, OAuthProvider를 범용 구조로 리팩토링해주었다.

기존 코드 (Kakao 단독)

package com.cookeep.cookeep.domain.user.application;

import com.cookeep.cookeep.domain.user.dto.KakaoUserInfoResponseDTO;
import com.cookeep.cookeep.domain.user.entity.Provider;

public interface OAuthProvider {
    Provider provider();
    String getKakaoAccessToken(String code, String redirectUri);
    KakaoUserInfoResponseDTO getKakaoUserInfo(String accessToken);
}

수정된 코드 (리팩토링 후)

package com.cookeep.cookeep.domain.user.application;

import com.cookeep.cookeep.domain.user.dto.OAuthUserInfoDTO;
import com.cookeep.cookeep.domain.user.entity.Provider;

public interface OAuthProvider {
    Provider provider();
    String getAccessToken(String code, String redirectUri);
    OAuthUserInfoDTO getUserInfo(String accessToken);
}

또, 이에 맞춰 KakaoOAuthProvider의 코드도 수정해줬다.

OAuthProvider에서 변경된 메서드명에 맞춰 메서드명과 반환 타입을 수정할 뿐만 아니라, 받아온 유저의 정보값을 OAuthUserInfoDTO에 맞게 변환하는 로직 또한 추가해주었다.

    // 소셜 액세스 토큰을 사용해 유저의 정보값을 받아옴
    public OAuthUserInfoDTO getUserInfo(String accessToken) {
        KakaoUserInfoResponseDTO kakaoUserInfo = WebClient.create(KakaoUserInfoURL)
            .get()
            .header(HttpHeaders.AUTHORIZATION, "Bearer " + accessToken) // access token 인가
            .header(HttpHeaders.CONTENT_TYPE, HttpHeaderValues.APPLICATION_X_WWW_FORM_URLENCODED.toString())
            .retrieve()
            .bodyToMono(KakaoUserInfoResponseDTO.class)
            .block();

        return new OAuthUserInfoDTO(
            String.valueOf(kakaoUserInfo.id()),
            kakaoUserInfo.kakaoAccount().email()
        );
    }

또, GoogleOAuthProvider도 구현하였다. KakaoOAuthProvider와 거의 유사하지만 다른 점이 있다면, 구글 id는 이미 String이기 때문에 getUserInfo에서 String.valueOf()로의 변환이 불필요하다는 점이다. 이메일 구조 또한 중첩이 아닌 플랫 구조이기 때문에 googleUserInfo.email()과 같이 간단하게 값을 받아왔다.



이후에는 AuthService와 AuthController 내에 구글 로그인 메서드를 작성해주었다.

구현 이후 테스트를 진행한 결과, 구글 로그인 또한 정상적으로 회원가입이 처리되는 것을 확인했다.

AuthSerivce 내 메서드 통합

이번에는 AuthService 내에 중복되는 부분을 하나의 메서드로 통합해보려 한다.

먼저, createKakaoUser와 createGoogleUser를 createSocialUser로 통합하였다. 이 부분은 크게 변동사항이 없어 넘어가도록 하겠다.

kakaoLogin과 googleLogin도 코드 자체는 거의 동일하다.

다음은 카카오로그인의 코드이다.

// 카카오 로그인
@Transactional
public SocialLoginResponseDTO kakaoLogin(String code, String redirectUri) {
    String kakaoAccessToken = kakaoOAuthProvider.getAccessToken(code, redirectUri);
    OAuthUserInfoDTO userInfo = kakaoOAuthProvider.getUserInfo(kakaoAccessToken);

    String kakaoId = userInfo.id();

    // provider = KAKAO, providerUserId인 값을 통해 이미 가입된 회원인지 식별
    Optional<UserAuth> existingUserAuth = userAuthRepository.findByProviderAndProviderUserId(KAKAO, kakaoId);

    String email = userInfo.email();

    // 신규 유저일 경우 User, UserAuth값을 새롭게 생성함
    UserAuth userAuth = existingUserAuth
       .orElseGet(() -> {
          User user = createSocialUser(email);

          return userAuthRepository.save(
             UserAuth.builder()
                .user(user)
                .provider(KAKAO)
                .providerUserId(kakaoId)
                .build());
       });

    User user = userAuth.getUser();

    // 액세스 토큰, 리프레쉬 토큰 발급
    TokenPair tokenPair = issueTokensAndUpsertSession(user);

    UserStatus userStatus = user.getUserStatus();
    NextStep nextStep = null;
    Boolean marketingConsent = user.getMarketingConsent();

    // 최초 회원가입한 소셜 로그인 유저일 경우
    if (user.getUserStatus() == UserStatus.CREATED) {
       // 최초 회원가입인 경우 TERMS 페이지로 이동,
       // 회원가입 이후 약관 동의까지 마친 경우 ONBOARDING 페이지로 이동
       nextStep = (marketingConsent == null)
          ? NextStep.TERMS
          : NextStep.ONBOARDING;
    }

    return new SocialLoginResponseDTO(
       user.getUserId(), tokenPair.accessToken(), tokenPair.refreshToken(),
       userStatus, nextStep
    );
}

kakaoOAuthProvider와 googleOAuthProvider만 다를 뿐, 나머지 로직은 완전히 같았기 때문에 하나의 socialLogin() 메서드로 통합하기로 했다.

하나의 메서드로 통합하기 위해서, OAuthProvider 인터페이스를 활용하였다.

Spring은 특정 인터페이스를 구현한 Bean이 여러 개 있을 때, List<인터페이스>를 주입 받으면 해당 구현체들을 모두 자동으로 담아준다. @Service가 붙은 클래스는 Spring이 자동으로 Bean으로 등록하게 되므로, KakaoOAuthProvider와 GoogleOAuthProvider도 모두 Bean으로 등록되어 있을 것이다. 따라서, List를 주입 받으면KakaoOAuthProvider와 GoogleOAuthProvider가 자동으로 리스트에 포함되기 때문에 이와 같은 구현이 가능하다.

private final List<OAuthProvider> oAuthProviders;

private OAuthProvider getProvider(Provider provider) {
    return oAuthProviders.stream()
        .filter(p -> p.provider() == provider)
        .findFirst()
        .orElseThrow(() -> new RuntimeException("지원하지 않는 소셜 로그인입니다."));
}

만약 카카오 로그인이 요청되어 getProvider(Provider.KAKAO)가 호출될 경우, provider() 메서드가 KAKAO를 반환하는 KakaoOAuthProvider가 반환된다. *이처럼 Provider별로 나누어져야 하는 처리는 해당 코드에서 처리되고, AuthService는 소셜 로그인 종류와 상관없이 동일한 방식으로 처리할 수 있게 된다. *

기존의 kakaoLogin 메서드에서 다음과 같았던 부분을

    String kakaoAccessToken = kakaoOAuthProvider.getAccessToken(code, redirectUri);
    OAuthUserInfoDTO userInfo = kakaoOAuthProvider.getUserInfo(kakaoAccessToken);

다음과 같이 변경하였다.

        // provider 타입에 따라 KakaoOAuthProvider 또는 GoogleOAuthProvider 반환
        OAuthProvider oAuthProvider = getProvider(provider);
        String accessToken = oAuthProvider.getAccessToken(code, redirectUri);
        OAuthUserInfoDTO userInfo = oAuthProvider.getUserInfo(accessToken);

이메일 일치 시 계정 통합

마지막으로, 현재 이메일은 중복을 허용하지 않고 있다.

기획에 따라, 이메일은 같지만 provider가 다른 경우 회원가입 과정에서 계정이 자동 통합되도록 하였다.

        // 신규 유저일 경우 User, UserAuth값을 새롭게 생성함
        UserAuth userAuth = existingUserAuth
            .orElseGet(() -> {
                // 동일한 이메일로 가입된 User가 존재하는지 확인
                // 존재하지 않을 경우 새로운 유저 생성
                User user = userRepository.findByEmail(email)
                    .orElseGet(() -> createSocialUser(email));

                // 기존 유저든 신규 유저든 UserAuth가 추가됨
                return userAuthRepository.save(
                    UserAuth.builder()
                        .user(user)
                        .provider(provider)
                        .providerUserId(socialId)
                        .build());
            });

로컬 회원가입은 기획 변경으로 수정할 부분이 남아있으므로, 해당 부분을 수정하면서 관련 코드를 추가할 예정이다.

마무리

이와 같은 과정을 통해 소셜 로그인을 범용 구조로 리팩토링하는 작업을 마무리했다.

처음에는 구글 로그인 코드를 추가하는 방식이 더 빠를 것 같아 고민하였지만, 범용으로 리팩토링을 마치고 나니 코드가 훨씬 깔끔해졌다.

이후 새로운 소셜 로그인이 추가되더라도 OAuthProvider를 구현한 Provider 클래스만 추가하면 되므로, 손쉽게 확장할 수 있는 구조가 되었다.

이번 리팩토링을 통해 단순한 기능 구현을 넘어, 확장성과 유지보수성을 고려한 구조 설계의 중요성을 체감할 수 있었다.

DML

• DML (Data Manipulation Language)

• INSERT, UPDATE, DELETE, MERGE

INSERT

테이블에 데이터를 입력하는 명령어

• INSERT INTO 테이블명 (컬럼명1, 컬럼명2, ...) VALUES (데이터1, 데이터2, ...);
  • 명시되지 않은 컬럼에는 NULL값이 입력됨
  • PK, NOT NULL 조건 주의!!!

• INSERT INTO 테이블명 VALUES (전체 컬럼에 입력될 데이터 리스트);
  • 데이터 유형이 맞지 않거나 누락된 데이터 있을 경우 에러 발생

• DEFALUT값이 있는 컬럼이어도 다른 데이터 INSERT시 데이터 정상 삽입됨

• VALUES 누락 주의!

UPDATE

이미 저장된 데이터를 수정하는 명령어

• UPDATE 테이블명 SET 컬럼명 = 새로운 데이터 (WHERE 수정할 데이터에 대한 조건);
  • ex) UPDATE 입사 SET 구분 = '경력' WHERE 입사자사번 = '220101';       입사자사번이 220101인 사원을 찾아 구분을 경력으로 수정함

• 여러 컬럼 수정시 SET절에 , (콤마)로 이어서 명시
  • SET 컬럼명1 = 데이터1, 컬럼명2 = 데이터2, ...

• WHERE 절이 없으면 테이블의 모든 Row가 변경되니 주의

DELETE

이미 저장된 데이터를 삭제하는 명령어

• DELETE FROM 테이블명 (WHERE 삭제할 데이터에 대한 조건);

• WHERE 절이 없으면 테이블의 모든 Row가 삭제되니 주의

WHERE 절 없는 DELETE vs TRUNCATE?

• 둘 다 테이블 전체 데이터 삭제 가능
• 삭제하고자 하는 마음이 확고하다면 TRUNCATE를 쓰는게 시스템 부하 측면에서 유리

• DELETE
  • COMMIT 전에 ROLLBACK 가능
• TRUNCATE
  • 별도의 로그를 쌓지 않아 ROLLBACK 불가능

• INSERT, UPDATE, DELETE

• 별도의 커밋 명령어를 실행해야 데이터 반영
• ROLLBACK 가능

MERGE

테이블에 새로운 데이터를 입력하거나 이미 저장되어 있는 데이터에 대한 변경 작업을 한 번에 할 수 있게 해주는 명령어

MERGE      INTO 타겟 테이블명      USING 비교 테이블명           ON 조건      WHEN MATCHED THEN           UPDATE                SET 컬럼명 = 새로운 데이터 [, 컬럼명 = 새로운 데이터 ...]      WHEN NOT MATCHED THEN           INSERT (컬럼명1, 컬럼명2, ...)]           VALUES (데이터1, 데이터2, ...);

TCL

• TCL (Transaction Control Language)

• COMMIT, ROLLBACK, SAVEPOINT

• 트랜잭션 : 쪼개질 수 없는 업무처리의 단위

트랜잭션의 특징

• 원자성
  • 한 트랜잭션 내의 동작들은 모두 성공하거나 모두 실패해야 함
• 일관성
  • 완료 후에도 DB가 가진 데이터에 일관성이 있어야 함
• 고립성
  • 고립되어 수행되어야 함
• 지속성
  • 성공적으로 수행시 변경된 데이터가 영구적으로 저장되어야 함

COMMIT

변경된 내용을 확정, 반영하는 명령어

• UPDATE한 뒤 오랜 시간 COMMIT이나 ROLLBACK하지 않으면 Lock에 걸려서 다른 사용자가 변경할 수 없는 상황이 발생할 수 있으니 주의해야 함

ROLLBACK

변경된 내용을 취소하는 명령어

SAVEPOINT

해당 지점까지 저장하는 명령어

DDL

• DDL (Data Definition Language)

• CREATE, ALTER, DROP, RENAME, TRUNCATE

CREATE

• 테이블을 생성하기 위한 명령어

CREATE TABLE 테이블명 (      컬럼명1   데이터 타입 (DEFAULT / NULL 여부),      ... );

• NULL 여부 명시하지 않으면 기본은 NULL 가능

• 테이블 생성시 지켜야 할 규칙 (지키지 않으면 에러 발생)
  • 테이블명은 고유해야 함
  • 한 테이블 내에서 컬럼명은 고유해야 함
  • 컬럼명 뒤에 데이터 유형과 크기가 명시되어야 함
  • 컬럼에 대한 정의는 괄호( ) 안에 기술
  • 각 컬럼들은 , (콤마)로 구분됨
  • 테이블명과 컬럼명은 숫자로 시작할 수 없음
  • 마지막은 ; (세미콜론)으로 끝남

• 테이블 생성시 권장 항목 (에러 발생 X)
  • 테이블명은 정체성을 나타내도록
  • 컬럼명 정의시 다른 테이블과 통일성있게

ALTER

• 테이블 구조를 불가피하게 변경할 경우

ADD COLUMN

ALTER TABLE 테이블명 ADD 컬럼명 데이터유형;

• 새로운 컬럼 추가
• 추가된 컬럼은 항상 맨 뒤, 위치 지정 불가
• ✅ 사용할 땐 ADD COLUMN 아니고 ADD임!!!

DROP COLUMN

ALTER TABLE 테이블명 DROP COLUMN 컬럼명;

• 컬럼 삭제
• 한 번 삭제한 컬럼은 복구 불가

MODIFY COLUMN

ALTER TABLE 테이블명 MODIFY (컬럼명1 데이터 유형 [DEFALUT 값][NOT NULL], 컬럼명2 데이터 유형 ...);

• 기존 컬럼 변경

RENAME COLUMN

서브쿼리 (Subquery)

스칼라 서브쿼리

• 주로 SELECT 절에 위치
• 컬럼이 올 수 있는 대부분 위치에 사용 가능
  • FROM 절은 불가능 (테이블명이 오는 위치라)

• 반드시 하나의 값만 반환해야 함
  • 그렇지 않은 경우 에러 발생

인라인 뷰

• FROM 절 등 테이블명이 올 수 있는 위치에 사용 가능

중첩 서브쿼리

• WHERE 절, HAVING 절에 사용 가능

메인쿼리와의 관계에 따라

• 비연관 서브쿼리
  • 메인쿼리와 관계를 맺고 있지 X
  • 즉, 서브쿼리 내에 메인쿼리 컬럼 X
• 연관 서브쿼리
  • 메인쿼리와 관계 O

반환하는 데이터 형태에 따라

뷰

• 뷰의 특징
  • 보안성
  • 독립성
  • 편리성

집합 연산자

• UNION은 UNION ALL보다 성능상 불리함
  • 중복된 행 제거하는 과정 거치므로

• INTERSECT에서 같은 컬럼에 서로 다른 ALIAS를 부여했을 경우, 헤더값은 첫 번째 쿼리를 따라감

그룹 함수

ROLLUP

• 소그룹 간의 소계 및 총계를 계산하는 함수
• 총합계!!!!

• ROLLUP(A,B) != ROLLUP(B,A)

• ROLLUP((A,B),C)
  • 중간 NULL이 마지막 한 칸
• ROLLUP(A,(B,C))
  • 중간 NULL이 뒤에 두 칸

CUBE

• 조합할 수 있는 모든 소그룹에 대해 소계 및 총계 계산
  • 번외) GROUP BY는 일방향으로 그룹핑

• ROLLUP(A,B)
  • ROLLUP은 중간 부분에서 A에 대한 총합계만 구함
• CUBE(A,B)
  • CUBE는 ROLLUP과 달리 중간부분에서 B에 대한 총합계도 구함

GROUPING SETS

• 특정 항목에 대해
• 마지막에 ( )가 없다면 총합계 계산 X
• ROLLUP, CUBE 사용 가능 (사용시 총합계 계산 O)

• ROLLUP
  • 인수 순서에 따라 결과 달라짐
• CUBE, GROUPING SETS
  • 인수 순서 영향 X

GROUPING

• 소계(합계)된 열은 1, 아니면 0

관계형 데이터베이스

• 관계형 데이터베이스

• 모든 데이터를 2차원 테이블 형태로 표현한 뒤 관계 정의

• TABLE

• 인스턴스 = Row, 속성 = Column

SELECT문

• SELECT문

• 저장되어 있는 데이터를 조회

• SELECT ***** FROM 테이블;
  • 전체 컬럼이 조회됨

• Alias (별칭)
  • TABLE AS T, TABLE T와 같이 사용 가능
  • Alias를 설정했는데 Alias가 아닌 테이블명 사용시 에러 발생

• ALIAS 별도로 지정 X시 컬럼명 대문자로 출력
  • ex) SELECT hire_date → 컬럼명 HIRE_DATE로 출력

• 산술연산자
  • NULL 포함시 결과값도 NULL

함수

문자 함수

CHR(아스키코드)

• 아스키코드 매핑되는 문자로
• CHR(65) → A

LOWER(문자열)

• 소문자로 변환
• LOWER('JENNIE') → jennie

UPPER(문자열)

• 대문자로 변환
• UPPER('jennie') → JENNIE

LTRIM(문자열[,특정문자]) *[]는 옵션

• 맨왼쪽에서 특정문자 제거
• 특정 문자 지정 X시 공백 제거
• 맨왼쪽에서 지정한 문자들이 연속해서 존재하는 동안만 제거됨 (= 그뒤에 있는 건 제거 X)
• LTRIM('AAABBABC', 'A') → BBABC (연속해서 있는 A 모두 제거됨)
• LTRIM('DATABASE', 'DE') → ATABASE (D만이라도 제거됨)

RTRIM(문자열[,특정문자]) *[]는 옵션

• 맨오른쪽에서 특정문자 제거
• 특정 문자 지정 X시 공백 제거
• 맨오른쪽에서 지정한 문자들이 연속해서 존재하는 동안만 제거됨 (= 그앞에 있는 건 제거 X)
• RTRIM('ABCABCC', 'C') → ABCAB (연속해서 있는 C 모두 제거됨)
• RTRIM('SQL', 'LE') → SQ (L만이라도 제거됨)

TRIM([위치] [특정 문자] [FROM] 문자열) *[]는 옵션

• 문자 한 글자만 지정 가능!!
• 옵션이 없을 경우
  • 양쪽(맨왼쪽, 맨오른쪽) 공백 제거
  • TRIM(' JENNIE ') → JENNIE
• LEADING
  • 맨왼쪽에서만 제거
  • TRIM(LEDAING '블' FROM '블랙핑크') → 랙핑크
• TRAILING
  • 맨오른쪽에서만 제거
  • TRIM(TRAILING '크' FROM '블랙핑크') → 블랙핑
• BOTH
  • 양쪽(맨왼쪽, 맨오른쪽)에서 제거
  • TRIM(BOTH 'A' FROM 'AAABACAAA') → BAC

SUBSTR(문자열, 시작점 [,길이] *[]는 옵션

• 원하는 부분만 잘라서 반환
• 길이 지정 X시 끝까지
• 문자열 맨앞 0 아니고 1부터 시작임!!
• 공백도 계산하기! 주의!

LENGTH(문자열)

• 문자열 길이 반환

REPLACE(문자열, 변경 전 문자열 [,변경 후 문자열]) *[]는 옵션

• 바꿔주는 함수
• 변경 후 문자열 명시 X시 문자열에서 변경 전 문자열을 제거함

LPAD(문자열, 길이, 문자)

• 문자열이 길이가 될 때까지 왼쪽을 특정 문자로 채움
• LPAD('JENNIE', 10, 'V') → VVVVJENNIE

CONCAT(문자열1, 문자열2)

• 문자열1과 문자열2를 연결해줌

숫자 함수

ABS(수)

• 절댓값 반환

SIGN(수)

• 부호 반환
• 양수 1, 음수 -1, 0이면 0

ROUND(수[,자릿수]) *[]는 옵션

• 지정된 소수점 자릿수까지 반올림하여 반환
• 자릿수 명시 X시 기본값 0
• ROUND(163.76, 1) → 163.8
• ROUND(163.76) → 164
• ROUND(163.76, -1) → 160

CEIL(수)

• 소수점 이하의 수 올림해서 반환
• CEIL(72.86) → 73
• CEIL(7.1) → 8

• ROUND(수)는 반올림, CEIL(수)는 올림

FLOOR(수)

• 소수점 이하의 수 버림
• FLOOR(22.6) → 22

MOD(수1, 수2)

• 수1 % 수2 반환 (=나머지값 반환)
• 수2가 0일 경우 1 반환

날짜 함수

SYSDATE

• 현재의 연, 월, 일, 시, 분, 초 반환
• SYSDATE → 2025-03-04 02:00:58

EXTRACT(특정 단위 FROM 날짜 데이터)

• 날짜 데이터에서 특정 단위(YEAR, MONTH, DAY, HOUR, MINUTE, SECOND)만을 출력
• EXTRACT(YEAR FROM SYSDATE) → 2025

ADD_MONTHS(날짜 데이터, 특정 개월 수)

• 날짜 데이터에서 특정 개월 수를 더한 날짜 반환
• 일자가 존재하지 않을 경우 해당 월의 마지막 일자 반환
• ADD_MONTHS(DATE '2025-01-31', 1) → 2025-02-28

변환 함수

명시적 형변환과 암시적 형변환

명시적 형변환 - 변환 함수 사용 암시적 형변환 - DB가 내부적으로 알아서

명시적 형변환에 쓰이는 함수

• TO_NUMBER(문자열)
  • 문자열 → 숫자형으로 변환
  • TO_NUMBER('1234') → 1234
  • TO_NUMBER('abc') → 에러 발생

• TO_CHAR(수 or 날짜[, 포맷]) *[]는 옵션
  • 수 or 날짜 → (포맷 형식의) 문자형
  • TO_CHAR(1234) → '1234'
  • TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') → '2025-03-04 20:47:38'

NULL 관련 함수

NVL(인수1, 인수2)

• 인수1이 NULL일 경우 인수2 반환
• 인수1이 NULL이 아닐 경우 인수1 반환

NULLIF(인수1, 인수2)

• 인수1과 인수2가 같으면 NULL 반환
• 같지 않으면 인수1 반환

COALESCE(인수1, 인수2, 인수3, ...)

• NULL이 아닌 최초의 인수 반환

NVL2(인수1, 인수2, 인수3)

• 인수1이 NULL이 아닌 경우 인수2 반환
• NULL인 경우 인수3 반환
• NVL에서 한 칸 밀린 버전이라고 생각하기...

CASE

• 별도의 ELSE가 없을 경우 NULL값이 DEFAULT값이 됨
• Oracle의 DECODE 함수도 같은 기능
  • DECODE또 DEFAULT값이 별도로 없을 경우 NULL값이 DEFAULT값이 됨

CASE WHEN SUBWAY_LINE = '1' THEN 'BLUE'          WHEN SUBWAY_LINE = '2' THEN 'GREEN'          WHEN SUBWAY_LINE = '3' THEN 'ORANGE'          [ELSE 'GRAY'] END

CASE SUBWAY_LINE          WHEN '1' THEN 'BLUE'          WHEN '2' THEN 'GREEN'          WHEN '3' THEN 'ORANGE'          [ELSE 'GRAY'] END

DECODE (SUBWAY_LINE, '1', 'BLUE', '2', 'GREEN', '3', 'ORANGE'[, 'GRAY'])

WHERE 절

비교 연산자

• 조건식 컬럼명 우측에 위치해도 정상적으로 동작 O

• SQL에서는 같음을 의미하는 연산자가 ==가 아니라 =이다.

부정 비교 연산자

SQL 연산자

• LIKE 앞뒤로 '%'가 붙으면 어디에든 해당 문자열이 들어간 행을 출력함

부정 SQL 연산자

논리 연산자

• 논리연산자 우선순위

• ( ) → NOT → AND → OR

GROUP BY, HAVING 절

GROUP BY

GROUP BY - 데이터를 그룹별로 묶을 수 있게 해줌

집계 함수

집계함수는 NULL 제외하고 연산!!

• COUNT(컬럼)
  • COUNT(DISTINCT 컬럼) - 중복 제거 후 Count
• SUM(컬럼)
• AVG(컬럼)
  • ex) NULL, 25, 65일 경우 (25+65)/2로 계산
• MIN(컬럼)
• MAX(컬럼)

HAVING

• GROUP BY절 사용시 WHERE 절처럼 사용하는 조건절
• 데이터를 그룹핑한 후 특정 그룹 골라낼 때 사용
• 테이블 전체가 한 개의 그룹이 되는 경우 GROUP BY 없이 HAVING만 단독으로 사용 가능

• SELECT문 논리적 수행 순서

• HAVING 절은 SELECT 절보다 먼저 수행되므로 SELECT 절에서 기술된 ALIAS 사용 불가

ORDER BY 절

ORDER BY

• SELECT한 데이터 정렬

• 조건 여러개 가능. 여러개일 경우 앞에서부터

• ASC 오름차순, DESC 내림차순
  • 옵션 생략시 ASC가 기본값

• Oracle은 NULL을 최댓값으로 취급함
  • 문제에서 Oracle이라고 명시하지 않았을 경우 DBMS마다 다르므로 주의

• 컬럼명 말고 숫자로도 가능
  • ex) ORDER BY 1 → 첫 번째 컬럼 기준으로 오름차순 정렬

JOIN

JOIN

• 테이블 간에 PK, FK의 연관 관계가 없어도 JOIN 가능

EQUI JOIN

• EQUAL JOIN (=)

Non EQUI JOIN

• Non EQUI JOIN (BETWEEN, >, >=, <, <=)

3개 이상 TABLE JOIN

• EQUI JOIN과 Non EQUI JOIN은 하나의 쿼리에서 같이 사용할 수 있다.

STANDARD JOIN

INNER JOIN

• JOIN 조건에 충족하는 데이터만 출력
• JOIN 조건을 ON을 사용해서 작성

OUTER JOIN

• 반대편 테이블의 옆에 (+) 기호 붙여서 작성
  • 한쪽에만 사용해야 함

• 반대편 테이블에 JOIN되는 데이터가 없는 Row들을 반대편 테이블 컬럼의 값이 NULL로 출력됨

FULL OUTER JOIN

• 모두 출력됨

NATURAL JOIN

• 같은 이름을 가진 컬럼들이 모두 동일한 데이터를 가지고 있을 경우 JOIN됨
• A NATURAL JOIN B
• NATURAL JOIN에는 ON 절 사용 불가, ALIAS 사용 불가 사용시 에러 발생

• JOIN ~ USING (특정 컬럼들)
  • 이 형태도 NATURAL JOIN임
  • 특정 컬럼들이 동일한 데이터를 가지고 있을 경우
  • 단, USING 사용시 ALIAS 사용 불가

CROSS JOIN

• 조합할 수 있는 모든 경우 출력
• Cartesian Product

출처

• 유선배 SQLD 과외노트

정규화 (Normalization)

• 정규화

• 엔터티를 작은 단위로 분리하는 과정
• 입력, 수정, 삭제 성능 일반적으로 향상됨
• 데이터의 무결성을 보장하기 위해 수행

• 제1정규형
  • 모든 속성은 반드시 하나의 값만 가져야 함
    
    
• 제2정규형
  • 모든 일반속성이 반드시 모든 주식별자에 종속되어야 함
  • 제2정규화 - 주식별자가 복합식별자인 경우 부분 종속을 없애야 함
  • 제2정규화 - 현재 테이블의 주제와 관련없는 컬럼을 다른 테이블로 뺌
    
    
• 제3정규형
  • 주식별자가 아닌 모든 속성 간에는 서로 종속될 수 없음
  • 제3정규화 - 일반속성에만 종속된 속성은 다른 테이블로 뺌
  • 제3정규형을 만족하는 엔티티의 일반 속성은 주식별자 전체에 종속적임

✅ 어떤 릴레이션 R이 제2정규형이고, 기본키에 속하지 않은 속성 모두가 기본키에 이행적 함수종속이 아닐 때 제3정규형에 속한다.

✅ 정규화는 논리 데이터 모델의 일관성을 확보하고 중복을 제거하여 속성들이 가장 적절한 인스턴스에 배치되도록 한다.       → 개념 데이터 모델 아님!!!! 논리 데이터 모델!!!!!!!!

반정규화 (De-Normalization)

• 반정규화

• 조회 성능 향상을 위해 데이터 중복 허용 / 데이터 그룹핑
• 입력, 수정, 삭제 성능은 저하될수도
• 정규화가 끝난 후에

• 테이블 병합
  • 1:1 / 1:M / 슈퍼 서브 타입
  • JOIN이 많을 경우 고려
  • 1:M 테이블 병합 - 1쪽 엔티티 속성 개수가 적은 경우에만

• 테이블 분할
  • 테이블 수직 분할
    • 일부 속성을 별도의 엔터티로. 1:1 관계 성립
    • 자주 사용 X거나 대부분의 속성값이 NULL일 경우 고려
  • 테이블 수평 분할
    • 인스턴스를 특정 기준으로 분할
    • 파티셔닝

• 테이블 추가
  • 중복 테이블 추가
    • 필요할 경우 데이터 중복 감안
  • 통계 테이블 추가
    • 통계치 미리 계산하여 저장
  • 이력 테이블 추가
    • ex) 상품 가격 이력 테이블
  • 부분 테이블 추가
    • 특정 범위 데이터를 자주 처리할 경우

• 컬럼 반정규화
  • 중복 컬럼 추가
  • 파생 컬럼 추가
  • 이력 테이블 컬럼 추가

• 관계 반정규화
  • 중복 관계 추가

트랜잭션 (Transaction)

• 트랜잭션

• 데이터를 조작하기 위한 하나의 논리적인 작업 단위

• 트랜잭션의 특징
  • 원자성
    • 전부 처리되거나 아예 하나도 처리되지 않아야 함
  • 일관성
    • 일관된 상태여야 함. 모순X
  • 고립성
    • 실행 중엔 다른 트랜잭션 접근 불가
  • 지속성
    • 성공적으로 실행 완료시 영속적으로 저장됨

✅ 순차적으로 수행되는 작업 A와 B가 원자성을 지닐 경우       A까지만 수행하고 오류 발생했다면 A를 undo해야 함

NULL

• NULL

• 존재하지 않음. 값이 없음. 모르는 값

• 가로 연산
  • NULL 포함시 결과값도 NULL

• 세로 연산
  • NULL값 제외하고 연산

• ✅ NULL과의 비교 연산 결과는 항상 Unknown (IS NULL 제외)
• SUM,COUNT, AVG 등 집계함수는 NULL 제외하고 연산

✅ WHERE COL IS NULL과 WHERE COL = NULL은 다름!!! ✅ NULL = NULL 연산의 결과는 FALSE 또는 Unknown

본질식별자 vs 인조식별자

• 본질식별자
  • 가공 X 원래의 식별자
  • 원조식별자

• 인조식별자
  • PK 속성이 두 개 이상인 경우 하나로 묶어서 사용하는 식별자

• 복합식별자인 경우 간결하게 대체하기 위해 인조식별자 생성 가능

✅ 인조식별자 사용시 중복 데이터 막기 어려워짐

출처

• 유선배 SQLD 과외노트

데이터 모델의 이해

모델링이란 현실 세계를 단순화하여 표현하는 기법 이다.

• 모델링의 특징
  • 추상화
    • 현실 세계를 일정한 형식에 맞추어 표현
  • 단순화
    • 복잡한 현실을 제한된 언어나 표기법으로 이해하기 쉽게 함
  • 명확화
    • 애매모호함을 배제하고 누구나 이해가 가능하도록 정확하게 현상을 기술

✅ 모델링 시스템 구현만을 위한다? → X      시스템 구현 포함 업무 분석 및 업무 형상화 목적

• 모델링의 관점
  • 데이터 관점
  • 프로세스 관점
  • 데이터와 프로세스의 상관 관점
    • 데이터-프로세스의 관계를 위주로 모델링
    • 프로세스의 흐름에 따라 데이터가 어떤 영향을 받는지

• 모델링시 유의사항
  • 중복
  • 비유연성
    • 유연성 - 유지보수를 위해
  • 비일관성
    • 다른 데이터 연관성 고려하지 않고 일부 데이터만 변경시 발생
    • 데이터 간 연관관계 명확하게 정의해야 함

✅ 유의사항 문제 나오면 중복, 비유연성, 비일관성 먼저 찾기

• 모델링 단계
  • 개념적 데이터 모델링
    • 첫 번째 단계, 전산적
  • 논리적 데이터 모델링
    • 두 번째 단계, 재사용성 높음
  • 물리적 데이터 모델링
    • 세 번째 단계, 실제 구현 위해

• 3단계 스키마 구조
  • 외부 스키마
    • 여러 사용자 관점
  • 개념 스키마
    • 통합된 관점. 모든 사용자 관점 통합
  • 내부 스키마
    • 물리적인 관점. 실질적

✅ <헷갈리지 않게 주의>       여러 사용자 → 외부 스키마       모든 사용자 관점 통합 → 개념 스키마

• 3단계 스키마 구조가 보장하는 독립성
  • 논리적 독립성
    • 개념 스키마가 변경되어도 외부 스키마는 영향 X
  • 물리적 독립성
    • 내부 스키마가 변경되어도 외부, 개념 스키마는 영향 X
    • ✅ 데이터베이스의 파일 구조 변화가 논리스키마에 영향을 주지 않음
    • ✅ 데이터베이스의 색인 구조 변화가 응용 프로그램에 영향을 주지 않음

• ERD
  • IE/Crow's Foot : 가장 많이 사용

• IE/Crow's Foot 표기법

✅ ERD 작성 순서

 엔터티 도출 및 그림    → 배치    → 관계 설정    → 관계명 기입    → 참여도 기입    → 필수/선택 여부 기입

엔터티 (Entity)

엔터티 - Table 인스턴스 - Row 속성 - Column

• 엔터티 특징
  • 업무에서 쓰이는 정보여야 함
  • 유니크함을 보장할 수 있는 식별자가 있어야 함 (중복X, 모호X)
  • 2개 이상의 인스턴스를 가지고 있어야 함
  • 반드시 속성을 가지고 있어야 함
  • 다른 엔터티와 1개 이상의 관계를 가지고 있어야 함

• 엔터티 분류 - 유형 vs 무형
  • 유형 엔터티
    • 물리적 형태 O
  • 개념 엔터티
    • 물리적 형태 X, 개념적
  • 사건 엔터티
    • 행위를 통해 발생

• 엔터티 분류 - 발생시점
  • 기본 엔터티
    • 원래 존재. 독립적. 자식 엔터티 가질 수 O
  • 중심 엔터티
    • 기본 엔터티로부터 파생, 행위 엔터티 생성
  • 행위 엔터티
    • 2개 이상의 엔터티로부터 파생
    • ex) 주문 내역, 이벤트 응모 이력

✅ 엔터티명 정할 때 규칙

   - 실제 쓰이는 용어 사용     - 영문 대문자 표기 / 한글 약어 X     - 단수 명사     - 띄어쓰기 X     - 의미상 중복 X (주문, 결제는 중복 가능)     - 명확하게 표현

속성 (Attribute)

속성 - 더이상 쪼개지지 X. 최소의 데이터 단위. 필요해야 함

• 특성에 따른 분류
  • 기본 속성
    • 바로 정의 가능
  • 설계 속성
    • 설계 과정에서 만들어짐
    • ex) 고유번호
  • 파생 속성
    • 다른 속성으로부터 파생된 속성
    • ex) 계산된 값

✅ 설계 vs 파생 헷갈리지 않게 주의       계산된 값은 파생된 속성이므로 파생속성!!!

• 구성 방식에 따른 분류
  • PK 속성
    • 유니크함 부여
  • FK 속성
    • 다른 엔터티와 관계 맺게 해주는 매개체 역할
  • 일반 속성
    • PK, FK 제외한 나머지

• 도메인 ✅
  • 속성이 가질 수 있는 속성값의 범위

• 용어 사전
  • 속성 이름 정확, 직관적으로 부여하기 위해
  • 용어 혼란 없애기 위해

• 시스템 카탈로그
  • 시스템 관련 데이터 담고있는 DB
  • SQL 이용하여 조회 가능

✅ 속성 명칭 - 다른 테이블이더라도 속성명 다르게!!!       전체 데이터 모델에서 유일성 확보하도록

관계 (Relationship)

• 존재 관계
  • 존재 자체로 연관성이 있는 관계
  • ex) 엄마-아기, 직원-부서, 학생-학과

• 행위 관계
  • 특정한 행위를 함으로써 연관성이 생기는 관계
  • ex) 회원-주문, 학생-출석부

• 표기법
  • 관계명 (Membership)
    • 관계의 이름
    • 명확한 문장, 현재형
    • ex) 포함한다, 소속된다 ex) 포함한다, 소속된다
  • 관계차수 (Cardinality)
    • 관계에 참여하는 수
  • 관계선택사양 (Optionality)
    • 필수/선택 여부

• ✅ 엔터티 간 관계 도출시 확인사항
  • 연관규칙 존재?
  • 정보 조합 발생 O?
  • 업무기술서, 장표에 관계연결에 대한 규칙 서술 O?
  • 업무기술서, 장표에 관계연결을 가능하게 하는 동사(Verb) 존재 O?

식별자 (Identifiers)

식별자 - 인스턴스를 구분 가능하게 해주는 대표격 속성

• 주식별자 (PK, Primary Key)
  • 유일성
    • _유니크함 부여_하여 식별 가능하도록
  • 최소성
    • 최소 개수 속성 (유일성 보장하는)
  • 불변성
    • 속성값 변하지 X
    • ✅ '자주 변하지 않는 것이어야 한다'라고 되어있어도 O
  • 존재성
    • 속성값 NULL X

• 분류 - 대표성 여부
  • 주식별자 (PK)
  • 보조식별자

• 분류 - 스스로 생성되었는지 여부
  • 내부식별자
    • 엔터티 내부에서 스스로 생성됨
  • 외부식별자 (FK)

• 분류 - 단일 속성 여부
  • 단일식별자
  • 복합식별자

• 분류 - 대체 여부
  • 본질식별자
    • 가공 X 원래의 식별자
    • 원조식별자
    • ✅ 엔터티 내 집합을 명확하게 설명할 수 있는 업무적으로 의미가 부여된 식별자
  • 인조식별자
    • PK 속성이 두 개 이상인 경우 하나로 묶어서 사용하는 식별자

• 식별자 관계
  • 부모 엔터티의 식별자가 자식 엔터티의 PK
  • 실선으로 표시
  • 부모 엔터티가 있어야 생성 가능
  • 단일식별자/복합식별자에 따라 1:1/1:M 결정
• 비식별자 관계
  • 부모 엔터티의 식별자가 자식 엔터티의 일반 속성
  • 점선으로 표시
  • 부모 엔터티 없이 자식 엔터티 생성 가능
  • 자식 엔터티 존재하는 상태에서 부모 엔터티 삭제 가능

출처

• 유선배 SQLD 과외노트

‘따끈’은 사용자가 카테고리별로 반려동물의 건강 상태에 대한 일지를 작성하고, 이를 기반으로 AI를 통해 건강 상태를 진단할 수 있는 반려동물 스킨케어 서비스이다.
일지를 작성할 때는 귀/눈/털/발톱/이빨 5개 카테고리 중에서 선택할 수 있고, 이외에도 카테고리별 제품 랭킹, 커뮤니티, 투두 등의 기능이 있다.





이중 내가 개발한 AI진단 방법은 다음과 같다.

1. 반려동물의 정보와 선택한 일지 기록을 토대로 ChatGPT에게 반려동물의 건강 상태 진단과 관련 제품을 추천해달라고 한다. (GPT의 모델은 chat gpt 4o를 사용하였다.)
2. 챗GPT가 추천한 제품을 네이버 쇼핑 API를 통해 네이버 쇼핑에 등록된 제품 정보를 불러와서 사용자에게 보여준다.
   
   
   
   

이 과정에서, 챗GPT가 해외 제품을 추천해주는 문제가 발생하였다.
질문 내용을 구성할 때 5개 제품을 추천 해달라고 했는데, 5개를 모두 한국 제품으로 추천해줄 때도 있지만 해외 제품을 추천할 때도 있었다.

추천해준 제품이 해외에서만 판매될 경우, 네이버 쇼핑 API에서 검색되지 않아 2번의 과정에서 _개 사료 등 '반려동물 스킨케어 서비스'라는 따끈 앱의 취지와는 맞지 않는 제품들_이 불러와지는 일이 발생하였다.



이를 해결하기 위해 먼저 단순히 챗GPT에게 보내는 질문의 내용에 “한국의 제품을 추천해달라”고 추가해보았으나, 여전히 해외 제품만을 추천하는 문제가 발생하였다. 별도의 질문을 통해 확인해보니 챗GPT는 제품이 어느 나라에서 판매되는지는 알 수 없다고 하였다.


고민 끝에 네이버 쇼핑 API로 제품 정보를 업데이트할 때 필터링을 하는 방법으로 이를 해결하였다.


네이버 쇼핑 API의 제품 정보에는 다양한 정보들이 저장되어 있는데, 다음과 같이 카테고리도 저장되어 있다.

관련도 순으로 검색 결과를 받아온 후 제품을 선택할 때, 다음과 같은 필터링을 추가하여 _지정한 카테고리 내의 제품_을 선택하도록 하였다.

public JSONObject getFilteredItems(JSONArray items) {

        for (int i = 0; i < items.length(); i++) {

            // 반복문을 돌면서 조건을 충족하는 값이 나오면 바로 종료, 해당 item으로 저장함
            JSONObject itemJson = items.getJSONObject(i);

            String category3 = itemJson.getString("category3");
            String category4 = itemJson.getString("category4");

            List<String> validCategory3 = Arrays.asList(
                    "미용/목욕", "강아지 건강/관리용품", "고양이 건강/관리용품"
            );
            List<String> validCategory4 = Arrays.asList(
                    "브러시/빗", "에센스/향수/밤", "샴푸/린스/비누", "이발기", "발톱/발 관리",
                    "드라이기/드라이룸", "미용가위", "타월/가운", "물티슈/크리너",
                    "눈/귀 관리용품", "구강청결제", "칫솔", "치약", "구강티슈", "구강관리용품"
            );

            if (validCategory3.contains(category3) && validCategory4.contains(category4)) {
                // 해당하는 카테고리값에 해당하는 제품이 나오면 즉시 반복문을 종료하고 해당 itemJson값을 리턴함
                return itemJson;
            }
        }

        return null;
    }

물론 챗GPT가 추천해준 제품과는 다른 제품을 가져올 수도 있다.

네이버 쇼핑 API에서 관련도 순으로 제품을 검색하므로 완벽하게 일치하지 않더라도 관련 키워드들이 들어간 제품을 선택한다. PM과 논의한 결과, 키워드를 통해 진단 내용에 맞는 제품들을 선택하므로 앱의 취지와도 적합하다는 판단이 들어 필터링으로 문제를 해결하였다.

관련 전체 코드는 아래 링크에서 확인할 수 있다. https://github.com/ttakkeun/Backend_Spring/pull/120

네트워크 통신 절차 (예시)

먼저, 다음과 같은 예시를 통해 이해해보자.

<PC 크롬 브라우저에서 네이버 웹사이트를 접속하는 경우>

1. 크롬 브라우저에서 www.naver.com을 입력한다.
2. 크롬 브라우저는 이를 네트워크에서 통신 가능한 '패킷(packet)' 형태로 만든다.
3. 해당 패킷을 네트워크에 흘려 보낸다.
4. 네트워크 중간에 있는 기기 '라우터(router)'들이 이 패킷을 읽고 네이버 서버로 전달한다.
5. 네이버 서버는 이 패킷을 다시 풀어 웹서버가 읽을 수 있는 형태로 만든 뒤, 웹서버에 전달한다.
   
   
   
   
   
   
   

   프로토콜

   
   프로토콜이란 쉽게 말해 통신을 위한 규약이다.
   예를 들어, A라는 사람이 생년월일 정보를 B에게 전달한다고 가정해보자. A가 "제 생년월일은 010203이에요"라고 한다면, B는 별다른 설명 없이도 앞의 01이 생년, 중간 두 자리 02이 월, 마지막 두 자리 03이 일이라는 것을 알고 있을 것이다.

이처럼 문법, 해당 문법의 의미, 이것으로 어떤 액션을 취할 것인지 등의 규칙 을 통틀어 '프로토콜'이라고 한다.
네트워크에서 계층이 존재할 경우, 하위 계층은 상위 계층에게 서비스를 제공하고 상위 계층은 이를 이용하게 된다. 그러기 위해서는 계층 간의 인터페이스_가 잘 정의되어 있어야 하며, 이 _정의된 인터페이스를 프로토콜이라고 한다.

OSI 7계층 모델과 예시

OSI 7계층이란 네트워크에서 통신이 일어나는 과정을 7단계로 나눈 것이다. 앞선 예시를 사진을 참고하며 다시 한 번 이해해보자.

• 앞선 예시에서 _송신 호스트_는 _사용자_이며, _수신 호스트_는 _네이버 서버_가 된다.

• 송신 호스트가 응용 계층(브라우저)에서 데이터(URL)을 입력한다.

• 해당 데이터는 전송이 되기 전 표현 계층, 세션 계층, 전송 계층, 네트워크 계층, 데이터 링크 계층을 차례대로 지나며, 필요한 데이터를 기존 데이터에 추가한다.

  • 각 계층에는 순서가 존재하며, 데이터는 해당 순서에 따라 전달된다.
  • 각 계층은 이전 계층으로부터 데이터를 전달받은 뒤, 자신의 계층에서 기존 데이터에 필요한 데이터들을 추가로 붙인다.

• 물리 계층에서는 _완성된 데이터를 네트워크에 전송_한다.

• 서버는 전달받은 데이터를 물리 계층 -> 응용 계층 순으로 전달한다.

  • 각 계층은 이전 계층으로부터 전달받은 데이터 중 필요한 데이터만 분리하여 해석한다.

• 응용 계층에서 전달 받은 요청을 수신 호스트에 전달한 뒤, 수신 호스트가 해당 요청의 응답을 다시 데이터로 만든다.
  
  
  
  
  
  
  

  OSI 7계층

이번에는 각 계층에 대해 조금 더 자세히 알아보자.

• 7계층 - 응용 계층 (Application Layer)

  • 사용자와 상호작용을 하는 계층

  • 응용 프로그램 및 사용자 인터페이스 제공

  • 웹 서비스의 UI부분, 사용자의 입출력(I/O) 담당

• 6계층 - 표현 계층 (Presentation Layer)

  • 응용-네트워크 계층 간 데이터를 적절히 표현하는 부분 담당
  • 데이터 형식 변환, 데이터 압축 및 암호화, 문자 코드 변환 등

• 5계층 - 세션 계층 (Session Layer)

  • 통신 세션을 구성하는 계층
  • 통신하는 사용자들을 동기화하고 오류복구 명령들을 일괄적으로 다
  • 통신을 하기 위한 세션을 확립/유지/중
  • TCP/IP 세션을 만들고 없애는 책임을 짐

• 4계층 - 전송 계층 (Transport Layer)

  • IP에 의해 전달되는 패킷의 오류를 검사하고 재전송 요구 등의 제어를 담당하는 계층
  • 즉 오류 검출 및 복구, 흐름 제어, 중복 검사 등을 담당하는 계층
  • 종단간(end-to-end) 신뢰성 있는 통신 제공 -> 상위 계층이 유효성, 효율성을 고려하지 않아도 되게 해줌

• 3계층 - 네트워크 계층 (Network Layer)

  • 경로를 선택하고 경로에 따라 패킷을 전달하는 역할
  • 흔히 말하는 '라우터'가 해당 역할을 함
  • 데이터를 목적지로 안전하고 빠르게 전달(라우팅)함
  • IP 주소를 사용하여 목적지 식별

• 2계층 - 데이터 링크 계층 (Data Link Layer)

  • 데이터의 오류와 흐름을 관리 -> 안전한 정보의 전달을 수행할 수 있도록 함
  • MAC 주소를 가지고 통신 (MAC 주소는 변동 X)

• 1계층 - 물리 계층 (Physical Layer)

  • 물리적인 연결과 전송 매체를 다룸
  • 데이터 비트를 신호로 변환하고 전송
  • 해당 계층은 전달만 함. 데이터가 무엇인지, 에러가 있는지는 신경 X
    
    
    
    
    
    
    

    TCP/IP 4계층 모델

    
    _OSI 7계층 모델_은 네트워크 통신 표준화를 위한 _개념 모델_이다.

즉, 실제로 인터넷 통신이 OSI 7계층 모델처럼 동작하지는 않는다. 실제 인터넷 통신의 대부분은 TCP/IP 통신을 사용한다.

TCP/IP 통신은 TCP와 IP에 기반한 통신 방법으로, 이 통신에 특화된 모델을 TCP/IP 4계층 모델이라 한다.

아래 사진에서 알 수 있듯, TCP/IP 4계층은 OSI 7계층과 유사하지만 4계층으로 간소화 되어 있다.

• 4계층 - 응용 계층 (Application Layer)

  • OSI 7계층 모델의 응용, 표현, 세션 계층 기능을 담당

• 3계층 - 전송 계층 (Transport Layer)

  • OSI 7계층 모델의 _전송 계층_과 같음
  • 프로세스 간의 신뢰성 있는 데이터 전송 담당

• 2계층 - 인터넷 계층 (Internet Layer)

  • OSI 7계층 모델의 _네트워크 계층_과 같음
  • 컴퓨터 간 라우팅 담당

• 1계층 - 네트워크 인터페이스 계층 (Network Interface Layer)

  • OSI 7계층 모델의 데이터 링크, 물리 계층 기능 담당
  • 네트워크 통신의 물리적인 부분

참고 링크

• https://ariz1623.tistory.com/327
• https://shlee0882.tistory.com/110
• https://blog.naver.com/ssudol2/223212288601

400 Bad Request

• 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음
• 요청 구문, 메세지 등의 오류
• *클라이언트는 요청 내용을 다시 검토하고, 보내야 함❗️ *
• ex) 요청 파라미터가 잘못되거나, API 스펙이 맞지 않을 때
  
  
  
  

404 Not Found

• 요청 리소스를 찾을 수 없음. 즉, 요청한 리소스가 서버에 없음
• 또는 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 싶을 때
  
  
  
  
  

무슨 차이일까?

나는 “요청 리소스를 찾을 수 없다”는 말을 DB에서 자원을 찾을 수 없다는 말로 해석해서 404도 적절하다고 생각했는데, 조금 더 찾아보니 404 Not Found는 API URI를 조회하지 못했다는 의미가 더 강하다고 한다.

404 Not Found 코드는 해당 리소스가 존재하지 않음을 나타낸다. 이와 달리 400 Bad Request의 경우에는 리소스가 아니라 설정 값을 나타내는 것이다.

만약 게시글에 대한 400 Bad Request가 발생할 경우 클라이언트에게 “게시글을 먼저 작성해주세요”라는 메시지를 반환하여 오류가 발생한 원인을 더욱 명확하게 알릴 수 있다.

정리

• 400 Bad Request
  • 클라이언트가 전송한 데이터가 부적절하거나, 요청 자체가 유효하지 않은 경우
  • 클라이언트가 요청을 수정하고 다시 시도하도록 유도하면 됨
• 404 Not Found
  • 클라이언트가 잘못된 URI를 시도했거나, 해당 리소스가 삭제되었을 가능성이 있음
  • 오류가 발생한 원인을 확인해야 함
    
    
    
    
    

결론!

• 즉, 클라이언트의 행동을 유도해야 하는지에서 핵심적인 차이가 있다❗️❗️
  • 만약 클라이언트의 행동을 교정해서 올바른 요청으로 만들 수 있다면 400이 좋은 선택이다.

참고 링크

• https://hyeon9mak.github.io/400-bad-request-vs-404-not-found/
• https://velog.io/@carrykim/HTTP-Stauts-4xx-%EC%97%90-%EB%8C%80%ED%95%9C-%EA%B0%9C%EC%9D%B8%EC%A0%81%EC%9D%B8-%EC%9D%B4%ED%95%B4

원시타입과 참조타입이란?

• 원시타입 : 논리형, 문자형, 정수형, 실수형 등의 실제 데이터(값)을 저장하는 타입
  • int, float, double, boolean 등
• 참조타입 : 객체가 생성된 메모리의 주소를 저장하는 타입
  • Integer, Float, Double, Boolean 등
    
    
    

실제로 값이 저장되는 영역은?

• 원시타입의 객체는 JVM 메모리 구조 중 Stack 메모리 영역에 저장된다.
• 참조타입의 실제 객체는 Heap 영역에 저장되며, 참조타입의 변수는 Stack 영역에 실제 객체 주소의 값을 저장하게 된다.
  
• 아래와 같은 두 변수가 있다고 가정해보자.
  

  int age = 25;
  String name = "커피";

  
  이 경우, age와 name의 값은 각각 다음과 같은 영역에 저장된다.

Boxing과 Unboxing이란?

• 참조타입은 원시타입을 _박스화한 자료형(boxed primitive type)_이라고 할 수 있다.
• 그래서 _원시타입을 참조타입으로 변환하는 과정_을 박싱(Boxing)이라고 한다.
• _참조타입을 원시타입으로 변환하는 과정_은 언박싱(Unboxing)이라고 한다.

public class BoxingUnBoxing {

    public static void main(String[] args) {

        // Boxing
        int i = 10;
        Integer integer = i; // 원시타입 i를 참조타입 integer에 대입

        System.out.println(i);
        System.out.println(integer);

        // UnBoxing
        Integer integer2 = 20;
        int i2 = integer2; // 참조타입 integer2를 원시타입 i2에 대입

        System.out.println(i2);
        System.out.println(integer2);
    }

}

결과
10
10
20
20

원시타입 vs 참조타입 비교

null을 담을 수 있는가?

• 원시타입 - 불가능
• 참조타입 - 가능
  

  int i = null; // 원시타입이므로 불가능
  Integer integer = null; // 가능

  
  
  
  

제네릭 타입에서 사용할 수 있는가?

• 원시타입 - 불가능
• 참조타입 - 가능
  

  List<int> i2; // 원시타입이므로 불가능
  List<Integer> integer2; // 가능

  
  
  
  

  접근속도?
  

• 원시타입(빠름) < 참조타입(느림)
• 참조타입은 값에 접근할 때 Unboxing 과정을 거쳐야 하므로 원시타입에 비해 접근 속도가 느리다.
• 단, 예외적으로 엄청 큰 숫자를 복사해야 한다면 참조 타입이 좋을 수도 있다. 아래 그래프에서 확인할 수 있듯, 원시타입인 long과 참조타입인 Long의 평균 실행시간은 다른 타입들에 비해 차이가 적다.
  
  
  

차지하는 메모리의 양?

• 참조타입(큼) > 원시타입(작음)
• 참조타입은 객체로 감싸져있기 때문에 차지하는 메모리의 양이 원시타입에 비해 크다.

결론!

원시타입은 성능과 메모리 면에서 장점이 있으므로 원시타입 사용을 먼저 고려해보면 좋을 것 같다. 다만 _null이나 제네릭 타입을 사용할 경우_에는 참조타입을 사용해야 한다.

참고 링크

• https://velog.io/@ljs0429777/자바의-원시타입을-이해해보자
• https://siyoon210.tistory.com/139