카카오톡 테스트 챗봇으로 ‘식단 조회’ 시 발생한 오류이다.

[Chat-GPT 오류 분석]

SpEL

Spring Expression Language

${….} or #{….} 식을 해석하려고 했는데, 해당 표현식에서 참조한 dietDate 속성이 null 객체에 대해 호출되었기 때문에 발생한 예외

• dietDate 속성을 찾음
• 해당 속성이 붙은 객체가 null 상태임
  • RequestDto로 파라미터들을 객체로 묶어놓음
  • RequestDto 객체가 null이라는 말
• 즉, null.dietDate를 참조한 상황

⇒ 로그를 확인해 관련 객체가 null이 아닌지 체크

[식단 조회 과정 디버깅 실행]

모든 파라미터들은 값이 잘 들어간 상태

→ 즉, RequestDto 객체는 null 이 아님

오류가 발생하는 지점

DietQueryServiceV2의 getDiets 메소드 내 코드에서 발생

List<DietDto> dietDtos = cacheServiceV2.getDietList(parameters, cafeteriaId);

디버깅을 따라가보면 이 코드 이후에 InvocableHandlerMethod 클래스 내의 doInvoke 메소드의 try-catch 문에서 InvocationTargetException 예외처리에서 걸림

catch (InvocationTargetException var9) {
    InvocationTargetException ex = var9;
    Throwable targetException = ex.getCause();
    if (targetException instanceof RuntimeException runtimeException) {
            throw runtimeException;

if문까지 실행된 후 runtimeException이 던져짐

그 후, DispatcherServlet 클래스의 doDispatch 메소드의 try-catch 문에서 Exception 예외에서 걸림

catch (Exception var20) {
        Exception ex = var20;
    dispatchException = ex;

그 후, catch 문을 벗어난 후 아래 문장 실행

this.processDispatchResult(processedRequest, response, mappedHandler, mv, (Exception)dispatchException);

catch (Exception var22) {
    Exception ex = var22;
    triggerAfterCompletion(processedRequest, response, mappedHandler, ex);

finally {
        if (asyncManager.isConcurrentHandlingStarted()) {
            if (mappedHandler != null) {
                mappedHandler.applyAfterConcurrentHandlingStarted(processedRequest, response);
        }
    } else if (multipartRequestParsed) {
              this.cleanupMultipart(processedRequest);
    }

• 첫 번째 if문을 실행 → false
• else-if 문 실행 → false

protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception

이 메소드에서 source code does not match bytecode라는 오류가 종종 뜸

그 후, doService 메소드로 이동

등등 그 후에도 여러 예외들로 계속 전파되어 콘솔에 오류 발생

결론적으로는 SpEL 오류라는 것.

이 코드를 자세히 보면 java.lang.reflect.InvocationTargetException 이 발생함

이 예외로 빠진다는 건, cacheServiceV2.getDietList 호출 내부에서 리플렉션으로 메서드를 호출하다가 예외가 터졌다는 의미

⚠️[InvocationTargetException]

리플렉션을 통해 메서드를 호출할 때, 그 메서드 내부에서 예외가 발생하면 그 예외를 감싸서 던지는 예외

Method method = someClass.getMethod("someMethod");
try {
    method.invoke(someObject);  // ← 내부에서 예외 발생하면
} catch (InvocationTargetException e) {
    Throwable realCause = e.getCause();  // 실제 예외 원인
}

[확인해야 할 것]

• getDietList내부에서 리플렉션을 사용하고 있는지 ? ⇒ NO
• 리플렉션 호출 대상 메서드에서 SpEL을 사용하는 로직이 있는지 ? ⇒ NO
• 캐시 관련 로직에서 SpEL을 key로 사용하고 있는지 ? ⇒ YES,,

@Cacheable(key = "#parameters.dietDate") 캐시 키값 설정을 위해 해당 코드를 사용중이었음

#parameters가 null이어서 .dietDate 접근할 수 없다는 뜻.

[예외 흐름 요약]

• cacheServiceV2.getDietList(parameters, cafeteriaId) 호출
• 내부에서 @Cacheable 애너테이션 처리 중 → SpEL 평가 수행
• SpEL 평가 중 parameters가 null → SpelEvaluationException 발생
• 이 예외는 리플렉션을 통해 메서드가 호출됐기 때문에 InvocationTargetException으로 감싸짐

[결론]

SpEL 문법 오류

[해결]

SpEL에서 null-safe 연산자 ?. 사용하기

@Cacheable(
    value = "dietList",
    key = "#parameters?.dietDate + '::' + #parameters?.period + '::' + #cafeteriaId",
    ...
)

이것만 수정하고 나니 실제로 오류는 해결됨

(하지만, SpEL 오류의 근본적인 이유와 dietDate 속성값은 null이 아닌데 null로 인식되는 이유를 모르겠음)

[추가로 알아볼 것]

• 리플렉션
• SpEL

자료 구조에서의 리스트 → 특징과 동작 원리 이해 필요

[배열]

(in 자료 구조)

메모리의 연속 공간에 값이 채워져 있는 형태의 자료구조

• 값을 인덱스를 통해 참조 가능

  [특징]

• 인덱스로 값에 바로 접근 가능 → 빠름

• 값의 삽입/삭제가 어려움

  • 연속적이므로 해당 인덱스 주변에 있는 값을 이동시키는 과정이 필요 → 느림

• 배열 크기는 선언할 때 지정

  • 한 번 선언 시, 크기 늘리거나 줄일 수 없음

[리스트]

(in 자료구조)

값과 포인터를 묶은 노드라는 것을 포인터로 연결한 자료구조

[특징]

• 인덱스가 없어 값에 접근하려면 Head 포인터부터 순서대로 접근해야 함 → 느림
• 포인터로 연결되어 삽입/삭제 빠름
• 선언 시, 크기 별도 지정 X
  • 크기 변경이 자유로움

파이썬에서는 배열과 리스트를 구분하지 않는다 !

→ 파이썬의 리스트 = 리스트 특징 + 배열 특징

• 인덱스로 바로 접근
• 가변적인 크기

[문제 풀이]

문제 1 - 숫자의 합 구하기 시간 제한 : 1초 | 난이도: 브론즈 IV | 백준 11720번

N개의 숫자가 공백 없이 써 있다. 이 숫자를 모두 합해 출력하는 프로그램을 작성하시오.

[입력]

1번째 줄에 숫자의 개수 N(1 ≤ N ≤ 100), 2번째 줄에 숫자 N개가 공백 없이 주어진다.

[출력]

입력으로 주어진 숫자 N개의 합을 출력한다.

[1단계 - 문제 분석]

파이썬의 리스트 자료 구조를 통해 쉽게 해결 가능

• 주어진 숫자를 리스트 형태로 저장 → list(input())
• index를 통해 탐색하며 각 자릿수의 값 더하기
  • 더할 때는 정수형으로 변환 필요
  • 리스트 내의 값은 str 형태

[2단계 - 슈도 코드 작성]

n값 받기
numbers 변수에 list 함수를 이용하여 숫자를 한 자리씩 나누어 받기
sum 변수 선언

for numbers 탐색:
        sum 변수에 numbers에 있는 각 자릿수를 가져와 더하기

sum 출력

[내가 푼 답안]

num = input()
numbers = list(input())
sum = 0

for n in numbers:
    sum += int(n)

print(sum)

[파이썬 형 변환]

• int형 → int(data)
• float형 → float(data)
• str형 → str(data)
• chr형 → chr(data)
• bool형 → bool(data)

bool 형 반환의 경우 int, float에서 변환할 때는 데이터가 0인지 아닌지, chr와 str에서 변환할 때는 값의 유무에 따라 True, False를 반환한다.

프로그램에서 발생하는 문법 오류나 논리 오류를 찾아 바로잡는 과정

코드의 오류는 어떻게 잡을까 ?

• 문법 오류 ⇒ 컴파일러
• 논리 오류 ⇒ 로직 step-by-step 검증

[디버깅 중요성]

문법 오류는 컴파일러가 찾아주지만, 논리 오류는 사용자의 의도와 코드의 흐름이 다르게 동작하는 것이므로 형태가 다양하다.

즉, 디버깅을 통해 어떤 흐름으로 동작하는지, 데이터의 상태 변화가 어떤지 등을 직관적으로 확인할 수 있다. 코딩테스트 응시 환경에서는 디버깅이 불가능하기 때문에, 디버깅을 익힌 경험으로 동작의 흐름을 예상할 수 있다.

[디버깅 하는 법]

• 중단점 = 브레이크 포인트 설정
  • 중단점 여러 개 설정 가능
• 디버깅 실행
  • 추적할 변숫값 지정 가능 → 변숫값이 의도한 대로 바뀌는지 확인

[Example]

# 배열의 주어진 범위의 합을 2로 나눈 몫을 구하시오.
import random

testcase = int(input())
answer = 0
A = [0] * (100001)

for i in range(0, 10001):
    A[i] = random.randrange(1, 101)

for t in range(1, testcase+1):
        start, end = map(int, input().split())

        for i in range(start, end + 1):
                answer = answer + A[i]

        print(str(testcase) + " " + str(answer/2))

[오류 1. 변수 초기화]

answer 에는 주어진 범위에 해당하는 값들의 합만 더해져야 한다.

for i in range(start, end + 1):
        answer = answer + A[i]

디버깅 시, 해당 for 문에서 answer 값이 이전의 수식 결과에 누적되어 더해지는 것을 발견했다.

⇒ answer 값 초기화 로직 추가해야 함

[오류 2. 반복문에서 인덱스 범위 지정]

A = [0] * (100001)

for i in range(0, 10001):
    A[i] = random.randrange(1, 101)

배열의 크기는 100001 만큼 할당했는데, 반복문의 범위를 10001 로 지정함.

⇒ 반복문 범위 수정 필요 0 하나 빠트림

[오류 3. 잘못된 변수 사용]

print(str(testcase) + " " + str(answer/2))

출력문에서 몇 번째 테스트인지 횟수를 출력하고 싶었으나, 반복문의 변수인 t 가 아닌 testcase 변수로 잘못 사용함.

[오류 4. 파이썬 자동 형 변환]

str(answer/2))

/ 나누기 연산자 사용 시, float 형으로 출력

// 몫 구하는 연산자 사용 시, int 형으로 출력

(+ % 나머지 값 구하는 연산자)

→ 실제 문제에서 몫은 자연수 값으로 출력을 원하기 때문에 실패로 결정됨

디버깅을 습관화 해놓아야 코딩 테스트 환경에서 디버깅 없이도 데이터의 상태 변화나 흐름을 캐치할 수 있을 것 같다 ..!!!

JSON Web Token

인증에 필요한 정보들을 암호화시킨 JSON 토큰

JWT 토큰을 HTTP 헤더에 실어 서버가 클라이언트를 식별하는 방식

(JWT 토큰 = Access Token)

[구조]

. 을 구분자로 Header, Payload, Signature 로 나뉜다.

• Header : JWT에서 사용할 타입과 해시 알고리즘의 종류

• Payload : 서버에서 첨부한 사용자 권한 정보와 데이터 → 실제로 사용될 정보들

  • key-value 로 이루어진 한 쌍을 Claim 이라고 한다.

  • 등록된 클레임

    • iss(issuer; 발행자)
    • exp(expireation time; 만료 시간)
    • sub(subject; 제목)
    • iat(issued At; 발행 시간)
    • jti(JWI ID)

  • 공개 클레임

    • 공개용 정보 전달을 위함
    • 클레임 이름을 주로 URI로 지음

  • 비공개 클레임

    • 공개되면 안 되는 클레임
    • 클라이언트-서버 간 통신에 사용

• Signature : Header & Payload 를 인코딩한 후 Header에 명시된 해시함수를 적용하고, 비밀키로 해시값 생성

-> 토큰의 위변조 여부 확인에 사용

[인증 과정]

1. 사용자가 서버에 로그인 인증 요청
2. 서버에서 Header, Payload, Signature 정의 후 JWT(액세스 + 리프레시)를 생성하여 쿠키에 담아 클라이언트로 전송
   • 서버는 리프레시 토큰을 DB에 별도 저장

3.클라이언트는 JWT를 로컬 스토리지에 저장

• 서버에 API 요청 시 Authorization header 에 Access Token을 담아 전송

4.서버는 토큰의 액세스 토큰의 유효성 검사

• 유효 X → 토큰 만료 에러 반환
  • 클라이언트는 리프레시 토큰으로 새로운 액세스 토큰 발급 요청
  • 서버는 DB의 리프레시 토큰과 비교 후 유효하다면 새로운 액세스 토큰 발급
  • 유효 O → 요청 처리

[궁금증]

리프레시 토큰이 탈취당한다면 무용지물 아닐까 ?

YES !

토큰 기반 인증의 특징 중 하나는 “무상태성” 이다.

사용자의 인증 정보가 담긴 토큰이 서버가 아닌 클라이언트에게 있기 때문에, 서버에서 따로 저장할 필요가 없다. 즉, stateless 인 것이다.

따라서 액세스 토큰을 탈취당하면 서버는 확인할 방법이 없다. 이를 위해 리프레시 토큰이라는 개념이 생겼다.

액세스 토큰의 유효기간(보통 30분)을 짧게 한다면 탈취당하더라도 오래 사용하지 못할 것이다. 하지만 사용장 입장에서는 유효기간이 끝날 때마다 토큰을 재발급해야 하는 번거로움이 있다. 따라서 리프레시 토큰의 유효기간을 길게 하여(보통 2주) 액세스 토큰이 만료되면 새로운 액세스 토큰을 발급할 수 있도록 하는 것이다. 결론적으로는 클라이언트 입장에서는 로그인 상태가 유지되는 것처럼 느껴진다.

하지만 리프레시 토큰은 “무효화” 할 수 있다는 장점이 있다. 리프레시 토큰은 서버에서도 저장을 하고 있다. 따라서 리프레시 토큰이 탈취당했을 때, 탈취당했다는 어떠한 요청이 오면 토큰을 무효화 시킬 수 있다는 것이다.

⇒ Refresh Token이 탈취되더라도 서버의 검증으로 AccessToken 재발급을 방지할 수 있다.

토큰은 어디에 저장될까 ?

Access Token은 요청 header의 authorization에 담긴다. → 공식 규격

Refresh Token은 http only cookie로 넘겨주면 js를 통한 접근이 불가능해지므로 스크립트 삽입 공격(XSS)은 막을 수 있다. 또한 http secure → https로만 통신하는 방법을 통해 쿠키에 보관하는 것이 좋다. 이렇게 하면 탈취 가능성은 거의 없다고 한다.

토큰의 유효성은 어떻게 검증할까 ?

토큰 기반 인증에서 리프레시 토큰 없이 무상태로 운영한다면, 서버는 클라이언트가 보낸 토큰을 어떤 데이터를 바탕으로 검증을 하는건지 궁금했다.

1. 서명 검증
   1. 서버는 토큰의 Signature를 서버에만 있는 비밀키를 사용해 검증 → 토큰의 위변조 확인 가능
2. Payload의 만료시간 확인
   1. 토큰의 exp 를 확인하여 유효 기간이 지났는지 판단

⇒ 즉, 토큰 그 자체가 데이터로 이루어져 있기 때문에, 토큰 자체로 인증을 처리함

[추가 보안 강화 방법]

1. JWT 토큰에 JTI (JWT ID) 포함 : 토큰 고유 식별자를 추가해 재사용 방지
2. 토큰 만료 시간 관리 : Access Token은 짧게, Refresh Token은 길게
3. 2FA(Two-Factor Authentication) : 추가 인증 단계 도입

[출처]

• https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-JWTjson-web-token-%EB%9E%80-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC#jwt_json_web_token_%EC%9D%B4%EB%9E%80

• https://pizza7311.me/post/dev/refresh-and-access-token

• https://stella-ul.tistory.com/entry/Access-Token%EC%9D%98-%EC%B7%A8%EC%95%BD%EC%A0%90%EA%B3%BC-Refresh-Token%EC%9D%84-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%8D%A8%EC%95%BC%ED%95%98%EB%8A%94%EC%A7%80

• https://velog.io/@thekim12/Refresh-Token-%EB%B3%B4%EC%95%88%EC%9D%98-%ED%95%B5%EC%8B%AC-%ED%83%88%EC%B7%A8%EB%A5%BC-%EB%A7%89%EB%8A%94-%EA%B2%83

원격 호스트에 접속하기 위해 사용되는 보안 프로토콜

→ TCP 22번 포트 사용하여 통신

Shell

명령어와 프로그램을 사용할 때 쓰는 인터페이스 / 커널과 사용자 간의 중간 역할

⇒ 사용자로부터 명령을 받아 해석하고 실행하는 역할

[배경]

• 기존 원격 접속 시 텔넷이라는 방식을 사용
  • 암호화 제공 X / 보안 상 취약 O
  • 암호화하는 SSH 기술 등장
• GCP 같은 클라우드 서비스에서 제공하는 서버는 기본적으로 원격 접속을 사용함
• 즉, 서버 생성 시 필수적으로 SSH 보안 과정 거치는 것 !

[작동 원리]

핵심 키워드 ⇒ KEY

• 사용자와 서버는 각각의 키를 보유
• 키를 사용해 연결 상대를 인증하고 안전하게 데이터 교환
• 클라이언트가 서버에 원격 접속하기 위해 서버의 TCP 22번 포트로 SSH 접속 요청

[키 생성 방식]

• 대칭키 방식

  클라이언트-서버 간 전체 연결을 암호화하는데 사용

  • 한 개의 키 사용 → 대칭 키

    ex)

  1. 사용자 or 서버는 하나의 대칭키를 만들어 서로 공유
  2. 공유된 대칭 키를 이용해 정보를 암호화
  3. 받은 쪽에서 동일한 대칭 키로 복호화하여 정보 습득
  4. 정보 교환 완료 시, 대칭 키 폐기
  5. 접속할 때마다 대칭 키 생성하여 사용

• 비대칭키 방식

  키 교환, 클라이언트 인증, 서버 인증에 사용

  • 사용자와 서버가 서로의 정체를 증명해야 함

  • 서버 or 사용자가 Key Pair 를 생성

    • Key Pair : 공개 키 / 개인 키 2가지로 이루어진 한 쌍
    • 공개 키 → 누구나 가질 수 있음
    • 개인 키 → 개인만 소유할 수 있음
    • .pub : 공개 키 / .pem : 개인 키 → 키 별로 파일 형식이 다름

    ex)

  1. 사용자가 키 페어 생성 후 공개 키를 서버에 전송
  2. 서버는 공개 키를 받아, 랜덤한 값 생성
  3. 사용자가 개인 키를 이용해 값 복호화 후 서버 전송
  4. 서버는 값을 받고 자신이 생성한 값과 비교
  5. 값이 일치한다면 인증된 사용자로 판단 후 접속 허용

애플리케이션 성능 지표 ⇒ 고객 만족도를 측정하는 지표

동작 방식

• 만족
  • 사용자가 모든 작업을 원활하게 진행
  • 응답 시간 ≤ T
• 허용
  • 사용자가 느리다는 생각을 하지만 작업을 마무리함
  • T < 응답 시간 ≤ 4T
• 불만
  • 사용자가 응답 속도의 느림으로 인해 작업을 마무리하지 않고 떠남
  • 4T < 응답 시간 or 오류
  • 오류율이 높으면 평균 응답 시간은 만족스러우나 Apdex 점수가 낮음

0 → 최악

1 → 만족

점수 높이는 방법

1. 코드 및 DB 쿼리 최적화
   1. 비효율적인 코드 사용 시, 많은 CPU 및 메모리 리소스를 요구하여 로드 시간이 느려짐
   2. 가장 좋은 방법
2. 과중한 작업에는 비동기 처리 사용
   1. 상호 통신 환경의 시스템 간에 애플리케이션에 필요한 처리 분산 가능
   2. 비동기 처리 시, 작업을 별도의 프로세스로 오프로드하여 메인 스레드가 사용자 요청을 처리할 수 있도록 리소스 확보
3. 트래픽 수요 증가에 맞춰 서버 확장
   1. 서버 용량을 늘리거나 부하 분산 기능을 사용하지 않는 상태에서 트래픽이 크게 증가하면 응답 시간이 느려짐

알고리즘 선택의 기준 ⇒ 시간복잡도

[정의]

주어진 문제를 해결하기 위한 연산 횟수

python → 2000만 번 ~ 1억 번의 연산을 1초의 수행 시간으로 예측

연산 횟수는 1초에 2000만 번을 기준으로 생각,,

[유형]

• 빅-오메가 : 최선일 때의 연산 횟수
• 빅-세타 : 보통일 때의 연산 횟수
• 빅-오 : 최악일 때의 연산 횟수

import random
findNumber = random.randrange(1, 101) # 1~100 사이 랜덤값 생성

for i in range(1, 101):
    if i == findNumber:
        print(i)
        break

• 빅-오메가 : 1번
  • 최선일 때 → 첫 번째 시도에 찾는 경우
• 빅-세타 : N/2번 (N은 데이터 개수)
  • 보통일 때 → 절반쯤 찾는 경우
• 빅-오 : N번
  • 최악일 때 → 100번째(마지막) 찾는 경우

코딩테스트에서는 빅-오 표기법 사용 → O(n)

⇒ 항상 최악의 경우 생각하기

코딩 문제에서 데이터 범위 확인(제일 큰 수 확인) !!

[연산 횟수 계산 방법]

• 연산 횟수 = 알고리즘 시간 복잡도 n값에 데이터의 최대 크기를 대입하여 도출

ex)

데이터 범위 : 0 ~ 100,0000

시간 제한 : 2초

⇒ 조건을 만족하려면 4000만 번 이하의 연산 횟수로 해결 필요

[사용가능한 2개의 알고리즘]

• 버블 정렬
  • O(n^2) → (100만)^2 > 4000만 번 👉🏼 부적합
• 병합 정렬
  • O(nlogn) → (100만)log(100만) < 4000만 번 👉🏼 적합

[시간 복잡도 도출 기준]

1. 상수는 시간 복잡도 계산에서 제회
2. 가장 많이 중첩된 반복문의 수행 횟수

N = 100000
cnt = 1

for i in range(N):
    print("연산 횟수" + str(cnt))
    cnt += 1

연산 횟수 = N

N = 100000
cnt = 1

for i in range(N):
    print("연산 횟수" + str(cnt))
    cnt += 1

for i in range(N):
    print("연산 횟수" + str(cnt))
    cnt += 1

for i in range(N):
    print("연산 횟수" + str(cnt))
    cnt += 1

연산 횟수 = 3N

⇒ 3배 차이

코딩 테스트에서는 상수를 무시하므로 시간복잡도는 O(N)으로 동일함

N = 100000
cnt = 1

for i in range(N):
    for j in range(N):
        print("연산 횟수" + str(cnt))
        cnt += 1

연산 횟수 = N^2

중첩이 있는 부분 O(N^2) → 시간 가장 많이 걸리기 때문

블로그 웹 페이지를 구현하는 실습을 진행하고 있다. 블로그 화면을 구성하기 위해 html과 js 파일을 작성하였다. html상에서 삭제 버튼을 클릭했을 때, js파일이 동작하여 파일을 삭제시키는 메소드 요청을 보내야 하는데, 버튼을 눌려도 아무런 반응이 없었다.

✔️원인

두 가지 원인을 생각했다.

1. 삭제 버튼을 인식하기 위해 작성한 html에서의 id값과 js에서의 id값의 불일치 문제
2. js 파일의 경로명 문제

결론은 경로 문제였다.

resources >> static >> article.js 와 같은 경로에 js 파일이 존재했기 때문에, html 파일에서 js 파일의 경로를 작성할 때 /static/article.js로 작성했다.

하지만 SpringBoot는 static, public, resources, META-INF/resources 폴더를 자동으로 정적 리소스 경로로 매핑한다.

예를 들어 src/main/resources/static/article.js 경로명이 있다면 웹에서 접근할 때는 👉🏼 http://localhost:8080/article.js 로 접근하는 것이다.

classpath:/static/
classpath:/public/
classpath:/resources/
classpath:/META-INF/resources/

SpringBoot의 정적 자원 매핑 경로는 위와 같다.

따라서 브라우저에서 접근할 때 /static/article.js가 아니라 /article.js라고 요청하면 Spring이 알아서 static 폴더 내부를 뒤져 찾아주는 것이다.

✔️결론

즉, 폴더명인 static은 경로에서 생략하는 것이 SpringBoot의 규칙임 ❗❗

✔️궁금증

그러면 html 파일이 들어있는 templates 폴더도 마찬가지일까? => 아니다.

웹페이지에 http://localhost:8080/templates/article.html 을 요청했을 때 404 에러가 떴다.

templates 폴더는 static 폴더와 다르게 동작한다.

templates 폴더는 정적 리소스가 아니라 템플릿 엔진이 처리하는 동적 리소스이다. 보통 Thymeleaf, Mustache, Freemarker 같은 템플릿 엔진에서 사용된다.

따라서 templates 안에 있는 파일들은 직접 URL로 접근할 수 없고, Controller에서 해당 파일 이름을 리턴해야 뷰로 렌더링된다.

@Controller
public class BlogController {
    @GetMapping("/blog")
    public String getBlogPage(Model model) {
        model.addAttribute("title", "블로그 제목");
        return "blog";  // → templates/blog.html 렌더링
    }
}

resources 폴더 하위에 data.sql 파일을 생성하고, 데이터를 삽입하는 INSERT문을 작성하였다. 애플리케이션을 실행시켰더니 위와 같은 오류가 발생했다.

✔️원인

Spring Boot에서 data.sql 파일을 사용하여 데이터베이스 스키마를 초기화하려고 할 때 발생하는 오류 중 하나이다.

SQL Script DataSource Initialization의 동작 방식 변경으로 인해 Hibernate 초기화 시점 변경

스프링 부트 2.5.x 이전 버전에서는 Hibernate가 초기화된 후에 'data.sql' 스크립트가 실행되었지만, 해당 버전부터는 data.sql 스크립트가 Hibernate 초기화되기 전에 실행되도록 기본 설정된다. 따라서 Hibernate 초기화 후에 'data.sql'스크립트를 실행되게 해야 한다.

✔️해결

// application.yml 설정 파일
spring:
  jpa:
    defer-datasource-initialization: true​

해당 설정은 Spring Boot에서 데이터소스 초기화를 지연시키는 설정이다. data.sql 스크립트를 지연시켜 Hibernate 초기화가 먼저 실행되도록 한다.

[출처]

• https://cocococo.tistory.com/entry/Spring-Boot-%EC%98%A4%EB%A5%98-datasql-Error-creating-bean-with-name-dataSourceScriptDatabaseInitializer-defined-in-class-path-resource

내가 공부하고 이해한 방식대로 정리를 해보려 한다.

Bean

우선 Bean이란 객체라고 생각하면 된다.

Java의 경우 객체를 생성할 때,

public class A {
    b = new B();
}

위와 같은 방식으로 new 키워드를 사용해 생성한다.

하지만 스프링에서는

public class A {
    private B b;
}

해당 객체를 선언해주는 방식이다.

위와 같은 방식으로 객체를 생성할 수 있는 이유는 스프링 컨테이너가 객체를 별도로 관리하고 생성해주기 때문이다.

즉, 객체를 직접 만드는 것이 아니라 A객체를 사용하고 싶다면 스프링 컨테이너가 객체 A를 생성하여 넘겨주는 방식이다.

그럼 스프링 컨테이너는 객체를 어떻게 인식할까 ? -> 사용자가 작성한 어노테이션을 통해 빈을 등록한다.

코드를 통해 빈 등록 과정을 알아보았다. @SpringBootApplication 이라는 어노테이션은 해당 클래스를 메인 클래스로 인식하고, 스프링 부트 사용에 필요한 기본 설정을 해준다.

@SpringBootApplication 구성

• @SpringBootConfiguration : 스프링 부트 관련 설정을 나타낸다. @Configuration을 상속해서 만든 어노테이션이다.

• @ComponentScan : 사용자가 등록한 빈을 읽고 등록한다. 또한 @Component라는 어노테이션을 가진 클래스를 찾아 빈으로 등록하는 역할을 한다.

• @EnableAutoConfiguration : 자동 구성을 활성화한다. 스프링 부트 서버가 실행될 때, 메타 파일을 읽고 정의된 설정들을 자동으로 구성하는 역할을 한다.

하지만 모든 빈에 @Component 어노테이션을 사용하지 않는다. 개발을 하면 용도에 따라 역할을 구분하기 위해 다른 어노테이션을 사용하기 때문이다.

• @Configuration -> 설정 파일 등록
• @Repository -> ORM 매핑
• @Controller, @RestController -> 라우터
• @Service -> 비즈니스 로직

자주 사용하는 어노테이션들이다.

@RestController 구성

앞서, @ComponentScan 이 @Component 어노테이션을 가진 클래스들을 찾아 빈으로 등록한다고 하였다.

하지만 다른 어노테이션을 사용했을 때는 어떻게 해당 클래스를 찾을 수 있는 것일까?

어노테이션의 구성을 살펴보았다.

@RestController는 @Controller와 @ResponseBody 이 2개의 어노테이션을 합친 것이라고 볼 수 있다.

하지만 여기서 @Component는 찾아볼 수 없다.

@Controller 구성

@Controller 어노테이션의 구성을 보니 비로소 @Component 어노테이션을 찾을 수 있었다.

즉, 다른 어노테이션들이 @Component 어노테이션을 감싸고 있는 구조이다. 따라서 위에서 소개한 4개의 어노테이션들도 @Component 어노테이션을 포함하고 있기 때문에 빈으로 등록될 수 있는 것이다.

Localhost

host는 주최자라는 의미로 IT에서 host는 네트워크를 이용하기 위해 네트워크에 연결된 장치를 의미한다. 루프팩 호스트명이라고도 한다.

즉, 그 장치는 노트북이 될 수도 스마트폰이 될 수도 아이패드가 될 수도 있다.

그럼 localhost는 무엇일까 ?

localhost는 네트워크 상에서 자신의 컴퓨터 주소를 의미한다.

즉, 내 컴퓨터의 주소 == localhost인 것이다. 따라서 다른 컴퓨터에서는 이 주소에 접근할 수는 없다.

localhost의 ip주소는 127.0.0.1이다. 우리가 흔히 알고 있는 네이버의 도메인명은 www.naver.com이다. 하지만 이론적으로 ip주소는 32비트 값의 숫자로 이루어져 있다.

네이버에 접속하는 과정을 설명해보자면 다음과 같다.

1. www.naver.com에 접속
2. DNS(도메인 네임 서버)에서 124.x.x.x와 같이 ip주소로 변환
3. 해당 ip주소로 데이터 요청
4. 화면 출력

www.naver.com이라는 주소는 숫자로 구성된 ip주소 대신에 가독성을 위해,, 비유하자면 별명을 붙여 부르는 것이라고 생각하면 될 것 같다.

그럼 127.0.0.1은 무엇일까 ?

컴퓨터 네트워크에서 localhost를 가리키는 특별한 ip주소이다.

인터넷에 연결되어 있지 않더라도 항상 동작한다는 특징이 있다. 또한, 고정적으로 localhost는 127.0.0.1이라는 ip주소를 갖는다.

cmd에서 ipconfig를 입력하고 볼 수 있는 ip주소는 사용중인 공유기의 주소이거나 외부 네트워크에 연결되어 있는 주소이다. 따라서 localhost는 다른 네트워크에 연결되지 않은 자신의 컴퓨터를 의미하는 것이다.

언제 사용하는지 ?

주로 네트워크 테스트 및 개발 목적으로 사용한다.

만약 로컬에서 서버를 실행시키고 테스트하려고 한다면, 브라우저에 localhost를 입력하여 자신의 컴퓨터 서버에 접속할 수 있다. 인터넷 연결없이도 작동하기 때문에 개발 및 테스트에 매우 편리하다는 장점이 있다.

[출처]

• https://unit-15.tistory.com/66
• https://allmeaning.tistory.com/entry/127001-%EC%9D%98%EB%AF%B8-Localhost-%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C

프로젝트 생성 후 빌드에서 오류가 발생하였다.

IntelliJ IDEA에서 SDK(Software Development Kit)는 특정 소프트웨어 프레임워크에 대한 응용 프로그램 개발 도구 모음이다. 예를 들어, Java로 애플리케이션을 개발하려면 Java SDK=JDK가 필요하다.

[원인]

자바와 프로젝트 버전이 맞지 않아 발생한다고 한다.

[해결]

프로젝트 버전을 맞추어 주자 ! 현재 JDK 버전 21 Java 버전 17

build.gradle 파일에서 괄호 안의 버전을 21로 변경해주었다.

성공!

[출처] https://ririthebest.tistory.com/entry/IntelliJ-Failed-to-calculate-the-value-of-task-compileJava-property-javaCompiler

자바에서 다룰 수 있는 데이터의 종류

✔️기본 타입(8개)

• boolean
• char
• byte
• short
• int
• long
• float
• double

정수 저장하는 타입 👉🏼 byte, short, int, long 실수 저장하는 타입 👉🏼 float, double » 타입마다 크기가 다르기 때문에, 다루는 값의 범위에 따라 적절한 타입을 선택해야 한다.

자바에서 영어, 한글 구분없이 문자 하나는 2바이트의 유니코드로 저장된다. 따라서 문자 타입을 나타내는 char는 2바이트이다.

✔️레퍼런스 타입(1개)

타입은 1개 이지만 용도는 3가지이다.

• 배열에 대한 레퍼런스 👉🏼 배열에 대한 주소 값
• 클래스에 대한 레퍼런스 👉🏼 객체에 대한 주소 값
• 인터페이스에 대한 레퍼런스

레퍼런스란? C언어의 포인터와 비슷한 개념이다. 한 가지 다른 점은 실제 주소값을 가지지 않는다는 것이다.

✔️문자열

반면, 문자열은 자바의 기본 타입에 속하지 않기 때문에 자바 라이브러리에서 제공하는 String 클래스를 이용한다.

String strName = "apple";

자바에서는 문자열과 기본 타입의 + 연산이 실행되면, 기본 타입의 값이 문자열로 바뀌고 두 문자열이 연결된 새로운 문자열이 생성된다.

strName + 1.8 -> "apple1.8"

✔️변수와 선언

변수 : 데이터를 저장하는 공간

변수를 선언하면 타입 크기의 메모리가 할당되며, 프로그램 실행 중 값을 쓰고 읽는 공간으로 사용된다.

int price;

데이터 타입과 변수 이름으로 선언한다. 실수는 저장되지 않는다❗

• 정수를 저장할 4바이트 공간이 할당
• 공간의 이름은 price로 붙임

char c1, c2, c3;

같은 타입의 변수는 ,로 여러 개 선언 가능하다.

🔹변수 선언과 동시에 초기화

int radius = 10;
char c1 = 'a', c2 = 'b', c3 = 'c';
double weight = 25.3;

🔹변수 읽기와 저장

radius = 10 * 5;
c1 = 'r';
weight = weight + 5.0; // 변수 값을 읽고 5.0을 더해 weight에 다시 저장

선언한 후에도 값을 다시 저장하고 읽을 수 있다.

✔️리터럴

프로그램에 직접 표현한 값

• 정수 : 34
• 실수 : 42.1
• 문자 : "%"
• 논리 : true
• 문자열 : "hi"

🔹정수 리터럴

int n = 15; // 10진수
int m = 015; // 8진수
int k = 0x15; // 16진수
int b = 0b0101; // 2진수

정수 리터럴은 기본적으로 int 타입으로 자동 컴파일된다. 만약 long 타입으로 지정하려면 숫자 뒤에 L 또는 l을 붙여야 한다. 보통 소문자 l은 숫자 1과 혼동되므로 대문자 L 을 사용하는 것이 좋다.

리터럴 뒤에 붙이는 알파벳을 접미사라고 한다. 앞에 붙이면 접두사라고 한다.

long g = 24L;

이미 long이라는 데이터 타입을 명시했는데, 왜 굳이 접미사를 붙여야 하는지 궁금했다.

여기서 먼저 알아야 하는 것은 변수에 값을 저장할 때는 "변수의 타입"과 "리터럴 타입"이 일치해야 한다는 것이다❗ (물론, 예외는 존재한다,,)

그래서 변수 선언 시 실행 과정을 알아보았다.

자바는 리터럴을 먼저 인식한 후 변수 타입을 고려하여 타입 변환을 수행한다는 것이다.

long s = 10;

위의 코드를의 코드를 컴파일러가 해석하는 과정을 설명해보자면

1. 리터럴 10을 인식 👉🏼 10은 정수 리터럴로 기본적으로 int 타입으로 해석

2. 리터럴 타입과 변수 타입을 비교 👉🏼 s는 long 타입이지만, 10은 int 타입

3. 형 변환 👉🏼 int 타입의 10을 long 타입으로 자동 변환

다른 경우를 보자.

long s = 2147483648;  // 컴파일 오류 ❌

2147483648은 기본적으로 int 타입으로 해석된다.

하지만 int의 최대값은 2147483647이므로 2147483648은 int 범위를 초과한다.

따라서 리터럴을 int로 먼저 인식해버려, 변수 타입을 고려하는 과정에서 오류가 발생하는 것이다.

접미사를 사용하는 경우

long s = 2147483648L;  // 정상 동작 ✅

L을 붙이면 처음부터 long 리터럴로 인식되므로 오류가 발생하지 않는다.

예외적인 상황을 보자.

byte s = 127;

byte의 범위는 -128 ~127이다 . 리터럴은 int 타입, 변수 타입은 byte이다. 위의 내용을 따르면 두 개의 타입이 다르므로 오류가 나야 정상이다. 하지만 리터럴이 int 타입일지라도 byte타입의 범위를 벗어나지 않으므로 문제가 없다.

double s = 3.14f;

이 경우도 마찬가지이다. 접미사 f를 명시하여 리터럴은 float 타입이지만 double의 데이터 범위가 더 크기 때문에 문제가 없다.

🔹실수 리터럴

12.  12.0  .1234  0.1234  1234E-4

소수점 형태나 지수 형태로 표현한다. 지수 e는 10의 n승을 나타낸다. e3은 10의 3승으로 1000을 나타낸다.

여기서 중요한것 e는 실수형을 나타내므로 그냥 1000이 아닌 1000.0이다.

실수 리터럴은 double 타입으로 자동 처리된다.

float f = 0.1234f;
double w = .1234D;

f = 0.1234로 하면 컴파일 오류가 난다. 기본 double타입으로 인식하고 변수 타입과 일치하지 않기 때문❗

🔹문자 리터럴

단일 인용부호 ' '로 표현하거나 \u 다음에 문자의 유니코드 값을 사용하여 표현한다.

char a = 'A';
char b = '글';
char c = \u0041;

🔹특수문자 리터럴

백슬래시 \ 다음에 특수 기호를 붙여 표현한다. 이스케이프 시퀀스라고도 한다.

🔹논리 리터럴과 boolean 타입

true, false

boolean a = true;
boolean b = 10 > 0; // 참이므로 true
boolean c = 1; // 타입 불일치 오류. 숫자를 참, 거짓으로 사용 불가

👻Tip. 기본 타입 이외의 리터럴

🔹null 리터럴

null은 기본 타입에 사용될 수 없고, 객체 레퍼런스에 대입된다.

int n = null; // 오류. 기본 타입은 불가
String str = null; // 정상

🔹문자열 리터럴

이중 인용부호 " " 사용하며, 모든 문자열은 String클래스의 객체이다.

String str = "Good";

🔹var 키워드

Java10 부터 지역 변수 선언 시, 변수 타입 대신 var 키워드를 사용할 수 있다.

var price = 200;
var name = "what";
var pi = 3.14;
var point = new Point();

리터럴 타입을 통해 자동으로 변수 타입을 지정한다.

하지만, 변수 선언문에 초깃값이 주어지지 않으면 오류가 발생한다.

var name;

타입을 추론할 수 없기 때문❗ 또한, var 사용은 지역 변수에만 한정된다는 점

✔️상수

변수 선언 시 final 키워드를 사용해 선언한다. 변수와 달리 실행 중에 값을 변경할 수 없다.

final double PI = 3.141592;

상수 선언은 변수 이름은 주로 대문자로 작성한다.

PI = 3.14; // 컴파일 오류

public class CircleArea {
    public static void main(String[] args) {
        final double PI = 3.14; // 상수 선언

        double radius = 10.0; // 리터럴 기본 타입은 double
        double circleArea = radius*radius*PI;

        System.out.println("면적:" + circleArea);
    }
}

✔️타입 변환

변수나 상수 또는 리터럴 타입을 다른 타입으로 바꾸는 것

🔹자동 타입 변환

치환문(=) 이나 수식 내에서 타입이 일치하지 않을 때, 컴파일러는 오류 대신 작은 타입을 큰 타입으로 자동 변환한다.

long m = 25; // 리터럴은 int. long으로 자동 변환
double d = 3.14 * 10; // 실수 연산을 위해 10이 10.0으로 자동 변환

🔹강제 타입 변환

개발자가 강제로 타입 변환을 지시하는 경우.

double d = 1.9;
int n = (int)d; // 강제 타입 변환

1.9에서 1만 저장된다. 이에 데이터 손실이 발생하게 된다. 캐스팅이라고도 부른다.

[출처]

• https://mgyo.tistory.com/214
• https://isoomni.tistory.com/entry/Java-%EB%AC%B8%EC%9E%90%EC%97%B4-String

식별자란 클래스, 변수, 상수, 메소드 등에 붙이는 이름을 말한다.

✔️식별자 이름 규칙

명명 규칙이라고도 한다. 모든 프로그래밍 언어별로 규칙이 존재하며 꼭 준수해야 한다.

• 특수문자, 공백은 불가 ❌
  • _, $ 는 예외로 사용 가능 ⭕
• 한글 사용 가능 ⭕
• 예약어 즉, 자바의 키워드는 사용 불가 ❌
• 첫 번째 문자로 숫자는 사용 불가 ❌
• 대소문자 구별 ⭕
• 길이 제한 ❌

int name; // 가능
char student_ID; // 언더바 사용 O
void $func() {} // $ 사용 O
class Monster3 {} // 숫자 O
int whatsYourNameMyNameIsKitae; // 길이 제한 X
int barChart; int barchart; // 대소문자 구별
int 가격; // 한글 O

int 3Chapter // 첫 번째 문자로 숫자 X
class if {} // 키워드 사용 X
char false; // 키워드 사용 X
void null() {} // 키워드 사용 X
class %calc {} // 특수기호 X

✔️자바 키워드

키워드란 자바에서 이미 용도가 정해진 것으로 예약어라고도 한다.

for, if, while, true, false, null, this, try, void, class, char, case, int, long 등등 많다.

✔️좋은 이름 붙이는 관습

1. 변수 이름만 보고도 어떤 의미인지 이해할 수 있도록 만든다.
2. 이름의 길이에 연연하지 말고 의미를 알 수 있게 충분히 긴 이름으로 만든다.
3. 언어의 관습을 따르는 것이 좋다

✔️자바 식별자 관습

• 클래스 이름

  • 첫 번째 문자는 대문자로 시작
  • 여러 단어가 붙여지면 첫 번째 문자만 대문자로 표시

    public class HelloWorld {}
    class AutoVendingMachine {}

• 변수, 메소드 이름

  • 첫 단어는 소문자로 표기
  • 이후의 각 단어 첫 번째 문자는 대문자로 표기

    int myAge;
    boolean isSingle;
    public int getAge() {return 20;}

• 상수 이름

  • 이름 전체를 대문자로 표기

    final double PI = 3.141592;

public class Hello {

    public static int sum(int n, int m) {
        return n + m;
    }

    // main() 메소드에서 실행 시작
    public static void main(String[] args) {
        int i = 20;
        int s;
        char a;

        s = sum(i, 10); // 메소드 호출
        a = '?';
        System.out.println(a);
        System.out.println("Hello");
        System.out.println(s);
    }
}

✔️클래스 만들기

가장 기본적인 것은 클래스를 만들고 그 안에 필드나 메소드와 같은 모든 프로그램 요소를 작성한다는 점이다. 클래스 바깥에는 어떤 것도 작성해서는 안된다.

class 키워드로 클래스명 Hello를 선언하고, {} 대괄호 사이에 코드를 작성한다. public은 접근지정자로 다른 모든 클래스에서 Hello 클래스를 자유롭게 사용할 수 있다는 의미로 지정해주는 것이다.

✔️주석문

주석문이란, 프로그램의 실행에 영향을 미치지 않으며, 코드에 대한 설명이나 특이사항 등을 자유롭게 기록하기 위해 사용한다.

그냥 메모하는 것이라고 이해했다.

• // 👉🏼 한 줄 주석 처리
• /* */ 👉🏼 여러 줄 주석처리

✔️main() 메소드

자바 프로그램은 main() 메소드에서부터 실행을 시작한다. main()은 반드시 public, static, void 타입으로 선언되어야 하며, 한 클래스당 단 하나의 main() 클래스를 가진다.

만약 여러 클래스를 작성한 경우, main() 클래스를 둔 파일만 실행되는 것이다.

✔️메소드

메소드는 멤버 함수이다.

메소드 개수는 제한이 없다.

위의 sum 메소드는 매개변수 n과 m을 가지고 합을 계산하는 함수이다.

s = sum(i, 10) 이 코드는 sum 메소드를 호출하는데, i와 10은 각각 매개변수 n과 m으로 전달된다. 그 후 합을 계산하여 그 결과를 s 변수로 반환한다.

✔️변수 선언

변수란 프로그램 실행 동안 데이터를 저장하는 공간이다.

지역변수 : 메소드 내에 선언되어 사용되는 변수

• 메소드 내에서만 사용 가능
• 메소드 실행이 끝나면 소멸됨

int i = 20; 👉🏼 변수를 선언하는 동시에 값 초기화

✔️문장

모든 문장은 세미콜론(;)으로 끝나야 한다.

자바 컴파일러는 세미콜론을 문장의 끝으로 인식한다.

✔️출력

데이터를 화면에 출력하려면 System.out.println() 또는 System.out.print()를 사용하면 된다.

println은 출력 후 다음 행으로 넘어가고, print는 다음 줄로 넘어가지 않는다.

System.out.print("Hello");
System.out.print("Java");

>> HelloJava

```java System.out.println("Hello"); System.out.println("Java");

Hello Java

하지만 다른 코드의 어노테이션은 동작을 잘 수행하는데, 특정 코드의 @Cacheable만 동작하지 않는 것이다.

구글링을 해본 결과 내부 메서드에 @Cacheable을 설정하면 동작하지 않는다는 것이다.

✔️Spring Cache 동작 원리

Spring Cache는 AOP를 이용한다. Aspect Oriented Programming ! 관점 지향 프로그래밍이라고 불린다.

@Cacheable이 설정된 메서드를 호출할 때, Proxy 객체가 생성되어 해당 호출을 intercept 한다. 그리고 proxy 객체가 다시 @Cacheable이 설정된 메서드를 호출하는 방법이다.

@Cacheable(
            value = "dietList",
            key = "#parameters.day + '::' + #parameters.period + '::' + #cafeteriaId",
            unless = "#result == null || #result.isEmpty()",
            cacheManager = "contentCacheManager"
    )
    // 식단 데이터 가져오기
    public List<DietDto> getDietList(HandleRequestDto parameters, int cafeteriaId) {
        System.out.println("getDietList 호출");
        // 오늘, 내일 문자열로 날짜 설정하기
        Date dietDate = getCurrentDate(parameters.getDay());
        // 식단 데이터 반환
        return dietRepositoryV2.findDietList(dietDate, parameters.getPeriod(), cafeteriaId);
    }

// 카테고리별 메뉴 리스트 생성하기
    public MultiValueMap<String, String> getDiets(HandleRequestDto parameters, int cafeteriaId) {
        List<DietDto> dietDtos = getDietList(parameters, cafeteriaId);
        MultiValueMap<String, String> dietList = new LinkedMultiValueMap<>(); // 중복 키 허용(값을 리스트로 반환)

        for (DietDto o : dietDtos) {
            String key = (o.getDishCategory() != null) ? o.getDishCategory()
                    : (o.getDishType() != null) ? o.getDishType()
                    : "메뉴";

            dietList.add(key, o.getDishName());
        }
        return dietList;
    }

getDietList함수에 @Cacheable을 적용했고, 같은 클래스 내부의 getDiets 함수 내에서 getDietList를 호출하는 코드이다.

@Cacheable self-invocation (in effect, a method within the target object calling another method of the target object). The cache annotation will be ignored at runtime

Spring AOP 기반의 @Cacheable은 자기 자신의 메서드를 호출할 때 동작하지 않는다. -> Self Invocation 문제 발생

위의 코드처럼 자기 자신의 메서드를 호출하면 프록시를 거치지 않아서 @Cacheable이 무시된다.

📑현재 코드 흐름

1. getDiets 실행
2. getDietList를 자기 자신이 직접 호출
3. 프록시를 거치지 않으므로 @Cacheable이 무시됨
4. 매번 db에서 데이터를 가져옴

해결 방법

@Cacheable 메서드를 외부에서 호출하도록 변경

현재 클래스가 아닌 다른 빈에서 getDietList를 호출하는 것 ! 이렇게 클래스를 분리하여 import하여 사용하는 방식으로 변경하였다.

또 다른 방법으로는 ApplicationContext를 이용해 프록시를 직접 호출하는 것이다. 클래스를 분리하기 어려운 경우에 사용할 수 있다.

@Autowired
private ApplicationContext applicationContext;

public MultiValueMap<String, String> getDiets(HandleRequestDto parameters, int cafeteriaId) {
    DietService dietServiceProxy = applicationContext.getBean(DietService.class); // 프록시를 직접 가져옴
    List<DietDto> dietDtos = dietServiceProxy.getDietList(parameters, cafeteriaId);

    MultiValueMap<String, String> dietList = new LinkedMultiValueMap<>();
    for (DietDto o : dietDtos) {
        String key = (o.getDishCategory() != null) ? o.getDishCategory()
                : (o.getDishType() != null) ? o.getDishType()
                : "메뉴";

        dietList.add(key, o.getDishName());
    }
    return dietList;
}

spring이 직접 프록시를 가져와 실행하므로 @Cacheable이 적용될 것이다.

하지만 서비스 클래스를 따로 분리해서 하는 방식이 명확하고 유지보수에 좋을 것 같아 저 방법을 사용하였다.

redis를 따로 설치하지 않고 redis cloud를 사용하였다.

캐시 설정 파일을 작성하고, 캐시 수명을 임의로 30분으로 설정하였다.

redis와 연결하기 위한 설정도 마쳤다. application.properites 파일에서 redis cloud의 정보를 확인하고 host, port, password를 작성하였다.

사용자 등록 여부를 확인하는 과정이 기능마다 하나씩 존재하기에 이 부분을 캐싱하였다. value : 캐시 네임스페이스 지정 key : 메소드의 파라미터를 지정해줌 unless : 특정 조건일 때 캐싱에서 제외함 cacheManager : 사용할 캐시 매니저 클래스 지정

테스트 코드를 작성하여 테스트를 진행하였다. 첫 번째 조회할 때에는 캐시DB에 데이터가 없기 때문에 DB를 조회하여 데이터를 가져온 후 캐시 DB에 저장한다. 두 번째 조회에서는 DB를 조회하는 것이 아니라 캐시 DB에서 가져와야 한다.

동일한 값이 반환되어야 하며, 캐싱이 적용된 메소드는 한 번만 실행되어야 한다. 즉 DB를 조회하는 쿼리문이 한번만 실행되어야 한다는 것이다. 그 후로는 캐시 DB를 사용하므로 ,,

실제 테스트를 진행해보았다. 처음 실행했을 때는 쿼리문도 같이 실행된 것을 볼 수 있다. 또한 redis insight에서도 데이터가 생성된 것을 볼 수 있다. 두 번째 실행에서는 쿼리문이 실행되지 않았고, 총 3개의 쿼리문이 실행되던 것이 하나가 줄어 두개의 쿼리문이 실행되는 것을 확인할 수 있다.

캐싱이 어떤 과정으로 발생하는지 알았으니, 캐싱 최적화 전략과 ttl 설정 등에 대해 더 조사해보아야겠다.

이때, 네트워크 시간에 배웠던 캐시 개념이 떠올랐다.

실제 데이터베이스에 접근하여 데이터를 가져오는 것이 일반적이라면, 캐시 DB를 도입하여 자주 쓰는 데이터들은 실제 DB까지 접근하지 않고 중간 다리 역할을 하는 캐시 DB를 통해 데이터를 가져와 시간을 절약시켜주는 효과를 얻을 수 있는 것이다.

먼저 중복되는 로직을 한 번 정리해보자.

1. 식당 또는 캠퍼스 찾기 기능 사용자 테이블에는 사용자id, 학과id, 캠퍼스id가 존재한다.

• 사용자가 캠퍼스 or 식당 정보 요청
• 사용자 테이블에서 사용자id로 사용자 존재 여부 확인
  • 사용자가 존재한다면 👉🏼 캠퍼스id 찾아 사용자의 캠퍼스에 존재하는 식당 반환
  • 사용자가 존재하지 않는다면 👉🏼 캠퍼스 반환

2. 학과 공지사항 조회 기능

• 사용자가 공지 사항 조회를 요청
• 사용자 테이블에서 사용자의 학과id 확인
• 사용자 학과 공지 사항 반환

3. 캠퍼스별 식당 식단 조회 기능

• 사용자가 식단 요청
• 사용자 테이블에서 사용자id 확인
• 사용자id로 캠퍼스 이름 찾기

위의 3가지 기능에서 동일하게 사용하는 로직이 사용자 테이블에 접근하여 사용자의 정보를 찾는 것이다.

사용자의 캠퍼스나 학과 정보는 변경이 거의 없는 데이터이고, 사용자가 요청할 때마다 사용자 테이블에 접근해야 하는 상황이라면 캐시화 하기에 매우 적절한 것 같다.

[출처]

• https://seungjjun.tistory.com/246
• https://yozm.wishket.com/magazine/detail/2296/

사용자가 요청한 식당의 메뉴들을 반환해주기 위해서는 식당의 카테고리와 메뉴들을 구분하고, 또 날짜 데이터와 덧붙여주어야 한다.

그래서 위의 코드와 같이 문자열 데이터를 계속해서 더해주는 코드가 여러 개 있다.

이전의 글에서 설명했듯이 String은 문자열 연산을 했을 때 메모리 내의 데이터가 불변이라 문자열이 더해진 새로운 객체를 또 생성하여 비효율적이라는 것을 알게 되었다.

반면에 StringBuffer는 가변적이라서 append 메소드를 사용해 문자열을 이어붙여주면 그 크기만큼 기존의 메모리 크기를 늘려준다. 즉, 새로운 객체를 생성하는 것이 아니라 기존 객체에 문자열이 더해지는 것이다.

따라서 오늘은 비효율적인 연산을 줄이고자 한다.

// title 데이터 연결
StringBuilder title = new StringBuilder("\uD83C\uDF71 ")
                .append(parameters.getCafeteriaName())
                .append("(")
                .append(parameters.getCampusName(), 0, 2)
                .append(") 메뉴");

// 메뉴 연결
StringBuilder description = new StringBuilder(dietDate)
                .append("\n\n")
                .append(dietDescription);

위와 같이 StringBuilder를 사용해 수정하였다. 멀티 스레드 환경이 아니기 때문에 굳이 StringBuffer를 사용하지 않았다.

함수의 인수를 통해 데이터를 전달하는 것은 코드를 읽는이에게 복잡함을 줄 수 있다. 다음 함수로 데이터를 전달하는 경우에는 Parameter로 넘기지 말고 Instance 변수를 활용하면 코드가 깔끔해진다. 출처

여러 개의 메소드에서 공통적으로 사용하는 파라미터들이 있어 이 변수들을 private 인스턴스 변수로 선언하여 여러 파라미터들을 전달하고 받아쓰는 것을 최소화시켰다.

StringBuffer와 String 중에 어떤 변수로 선언해야 할지 고민했었는데, 내가 현재 수정하고 있는 코드는 변수에 새로운 값을 계속 할당(덮어쓰기)하는 것이지, 문자열을 추가하거나 연산하는 것은 아니기 때문에 String으로 선언하였다.

private String kakaoId;
private String campusName;
private String day;
private String period;
private String cafeteriaName;

요청 파라미터를 처리하기 위해 필요한 변수들이 이렇게 5개가 있는데, 이 변수들을 DTO 객체로 묶었다.

이유는

1. 여러 메소드에서 위의 변수들을 필요로 함
2. 변경이 없어야 함 -> 불변성

인스턴스 변수를 사용하는 것이 바로 변수를 불러 사용할 수 있기 때문에, 코드 상 편리했지만 변수가 변경될 상황이 없고, 새로운 파라미터가 추가될 상황을 고려해서 하나의 객체로 만들기로 했다.

이렇게 HandleRequestDto 클래스를 만들어 총 5개의 변수들을 final로 선언하였다.

이렇게 객체를 생성해주고 메소드에 객체를 넘겨주면 getter 를 통해 값을 가져오는 방식으로 변경했다.

내가 이런 코드를 작성한 것에 대해 정확한 근거와 확신이 있어야 한다. 하지만,, 인스턴스 변수가 몇 개 존재할 때, 많은 건지 적은건지 또, 언제 DTO 클래스를 생성해서 사용하는 것이 더 효율적인건지 이런 기준들이 좀 모호한 것 같다. 개발을 더 많이 해보고 공부해봐야 저 기준들이 선명해질 것이다.