• 데이터가 많을 경우 한눈에 파악이 어려움
• 시각화를 통해 데이터의 특징을 빠르고 직관적이게 전달 가능
• 패턴과 이상치를 쉽게 발견 가능
• 설명과 설득을 돕는 도구 역할 수행

  데이터 형태

  • 정형 데이터 ㅡ '엑셀'과 '데이터베이스' 같이 표 형태로 정리되어 있어 구조가 명확한 데이터
  • 비정형 데이터 ㅡ '텍스트'와 '이미지', '영상' 같이 정해진 구조 없이 다양한 형태로 존재하는 데이터

    데이터 타입

  • 범주형 데이터 ㅡ 구분하기 위한 이름이나 종류를 나타내는 데이터 ex) 성별, 지역, 상품 종류
  • 순서형 데이터 ㅡ 순서의 의미는 있으나 순서 간 차이의 크기는 알 수 없는 데이터 ex) 만족도, 등급, 순위
  • 이산형 데이터 ㅡ 셀 수 있는 정수 값으로 이루어진 데이터 ex) 구매 횟수, 방문자 수
  • 연속형 데이터 ㅡ 소수점까지 표현 가능한 연속적인 데이터 ex) 키, 몸무게, 온도
  • 시계열 데이터 ㅡ 시간의 흐름에 따라 기록된 데이터 ex) 일별 매출, 월별 방문자 수
  • 위치정보형 데이터 ㅡ 위치 좌표를 기준으로 표현되는 데이터 ex) 위도와 경도, 지도 좌표
  • 텍스트 데이터 ㅡ 문장이나 단어 형태로 저장된 데이터 ex) 리뷰 내용, 뉴스 기사

    '분포'를 통한 파악

  • 이상한 값이 존재하는지 확인하는 방법
  • 데이터가 어떻게 퍼져 있는지 ?
  • 중앙값 : 값을 크기 순으로 놓았을 때 가운데에 있는 값
  • 분산/표준편차 : 값들이 서로 얼마나 퍼져 있는지를 나타내는 기준
  • 이상치 : 다른 값들과 많이 떨어져 있는 값

    * histogram, Box plot 사용

    분포의 해석

  • 평균과 중앙값 차이가 크다 -> 일부 값이 결과를 왜곡하는지 확인 필요
  • 분산이 매우 크다 -> 값 차이가 커서 비교가 어려움 -> 범위를 맞추는 작업(데이터 스케일 조정) 필요
  • 특정 구간에 데이터가 몰렸다 -> 큰 값의 영향을 줄이기 위한 변환 검토 필요
  • 이상치가 다수 존재한다 -> 분석에 포함할지 여부에 대한 기준 설정 필요
  • 결측값이 존재한다 -> 데이터 손실을 줄이기 위한 처리 방법 선택 필요

    '상관관계'를 통한 파악

  • 상관관계는 두 변수 사이의 함께 변하는 정도를 의미
  • 양의 상관관계는 함께 증가하는 경향을 의미
  • 음의 상관관계는 한쪽이 증가하면 다른 쪽이 감소하는 경향을 의미

    Pair Plot, Heatmap, Bubble chart 사용

    

• 범주형 데이터 -> 항목별 값을 비교하고 싶을 때 -> 막대그래프
• 범주형 데이터 -> 전체에서 비율을 파악하고 싶을 때 -> 원그래프
• 수치형 데이터 -> 값의 분포를 확인하고 싶을 때 -> 히스토그램
• 수치형 데이터 -> 분포와 이상치를 함께 확인하고 싶을 때 -> 박스플롯
• 수치형 데이터 -> 두 값의 관계를 확인하고 싶을 때 -> 산점도
• 시계열 데이터 -> 시간에 따른 변화를 확인하고 싶을 때 -> 선그래프
• 위치정보형 데이터 -> 지역별 차이를 확인하고 싶을 때 -> 지도 시각화
• 텍스트 데이터 -> 단어 사용 빈도를 확인하고 싶을 때 -> 워드 클라우드

시각화 도구 설치

uv add matplotlib
uv add seaborn
uv add folium

numpy 가 필요한 이유

• Numerical Python의 줄임말로, 많은 양의 데이터를 반복문 없이 한 번에 계산하고 분석하기 위해 필요하다.

  # 설치
  uv add numpy 
  

라이브러리 불러오기

import numpy as np -> 가상 환경이 켜져 있어야 한다. .venv\Scripts\activate

### 배열 생성
- axis=0 (1차원), axis=1 (2차원), axis=2 (3차원)
- np.array(data) ㅡ 기존 data를 배열로 생성
- np.zeros(shape) ㅡ shape에 맞는 모든 요소가 0인 배열 생성
- np.ones(shape) ㅡ shape에 맞는 모든 요소가 1인 배열 생성
- np.full(shape, value) ㅡ shape에 맞는 모든 요소가 value인 배열 생성
- np.arrange(start, end, step) ㅡ 일정 간격의 연속된 숫자 배열 생성
- np.linspace(start, end, num) ㅡ 지정한 개수로 균등 분할된 배열 생성

1차원 배열

arr1 = np.array([1, 2, 3, 4, 5]) print(arr1)

2차원 배열

arr2 = np.array([ [1, 2, 3, 4, 5], [6, 7, 8, 5, 2], [1, 5, 2, 3, 5] ]) print(arr2)

3차원 배열

arr3 = np.array([ [ [0, 255, 255], [255, 255, 0] ], [ [255, 0, 0], [0, 0, 255] ] ]) print(arr3)

import numpy as np

모든 값이 0인 배열을 생성(np.zeros(shape))

data1 = np.zeros((2, 3)) print(data1)

바깥부터 센다

data2 = np.ones((2,3,2)) print(data2)

내가 원하는 숫자

my_num = np.full((3, 2, 1), 999) print(my_num)

연속적인 숫자 배열을 생성 -> np.arrange(start, end, step)

data3 = np.arange(0,10,2) print(data3)

정해진 범위 안에 내가 지정한 개수만큼 배열 생성

실수로 반환한다.

data4 = np.linspace(1, 10, 4) # 마지막 숫자가 개수 (start 부터 end 까지 동일한 간격으로 num 개만큼 생성) print(data4)

### 랜덤 배열 생성
- np.random.rand(shape) ㅡ 0 이상 1 미만의 실수로 이루어진 배열 생성
- np.random.randn(shape) ㅡ 평균 0, 표준편차 1의 정규분포 배열 생성
- np.random.randint(low, high, shape) ㅡ 지정 범위의 정수로 이루어진 배열 생성
- np.random.random(shape) ㅡ 0 이상 1 미만의 실수 배열 생성

import numpy as np

np.random.rand(axis0, axis1, axis2)

0과 1사이의 실수 랜덤 배열 생성

튜플로 넣지 않고 두개 데이터 넘긴다

data1 = np.random.rand(2,3, 2) # 1차원 2차원 3차원

print(data1)

평균이 0, 표준편차 1의 정규분포 배열 생성

0에 가까운 데이터 생성 해줘 (안정적)

data2 = np.random.randn(2,3) print(data2)

지정 범위의 정수로 이루어진 배열 생성

시드를 고정하면 랜덤한 내용을 저장할 수 있다.

np.random.seed(123)

data3 = np.random.randint(start, end, shape)

data3 = np.random.randint(0, 10, (2, 3)) print(data3)

arr2 = np.arange(0,10) print(arr2)

(1, 10), (2, 5), (5, 2), (10, 1)

arr2_reshpae = arr2.reshape(2, 5) #첫번쨰가 1이어도 위에와 다르다 print(arr2_reshpae)

### 배열 속성
- 배열.shape ㅡ 배열의 각 차원 크기를 튜플로 표현
- 배열.ndim ㅡ 배열이 몇 차원 데이터인지 나타냄
- 배열.size ㅡ 배열에 포함된 전체 데이터 개수 의미
- 배열.dtype ㅡ 배열에 저장된 데이터의 자료형 의미

### 배열 변환
- 배열.reshape(shape) ㅡ 배열의 데이터는 유지하고 형태만 변경
- 배열.flatten() ㅡ 다차원 배열을 1차원 배열로 변환
- 배열.T or 배열.transpose() ㅡ 전치행렬(행렬 전환)

### 배열 연산
- np.sum(배열) ㅡ 전체 합
- np.mean(배열) ㅡ 평균
- np.max(배열) ㅡ 최댓값
- np.min(배열) ㅡ 최솟값
- np.std(배열) ㅡ 표준편차
- np.var(배열) ㅡ 분산
- np.describe() ㅡ 위 내용들 한꺼번에 정리해서 보여줌

평균에 몰려있으면 분산, 표준편차가 작다.

데이터가 제각각 흩어져 있으면 분산, 표준편차가 크다.

최댓값이 어느 위치에 있나요? -> 인덱싱 쉽게 하기 위함 (값은 상관 없음)

np.argmax(data1)

최솟값이 어느 위치에 있나요?

np.argmin(data1)

data_2d = np.array([ [10, 20, 30], [40, 50, 60] ])

axis=0 분홍색 안에 있는 파란색을 더하라.

print(np.sum(data_2d, axis=0))

axis=1 파란색 안에 있는 요소를 더하라

print(np.sum(data_2d, axis=1))

data_3d = np.array([ [ [255, 0, 0], [0, 255, 0] ], [ [0, 0, 255], [255, 255, 0] ] ])

axis=0 분홍색 안에 있는 파란색을 더하라.

print(np.sum(data_3d, axis=0)) print(" ")

axis=1 파란색 안에 있는 요소를 더하라

노란색 위아래를 더해서 한 열, 두번째도 마찬가지로 더해서 한 열 print(np.sum(data_3d, axis=1)) print(" ")

한줄 한줄 더해서

axis=2 노란색 안에 있는 요소를 더하라

print(np.sum(data_3d, axis=2))

### 이미지 데이터

이미지 불러오기 (uv add pillow)

from PIL import Image from IPython.display import display

image = Image.open("./images/dog.jpg") display(image)

import numpy as np image_arr = np.array(image) print(image_arr)

이렇게 해서 정사각형인지 아닌지도 판별이 가능하겠다.. h랑 w랑 개수 똑같이..

print(image_arr.shape)

shape 는 (h,w,cㅡ채널 수(R,G,B))

png는 RGBA(A는 투명도)

image_arr[:, :, 0] = 0 image2 = Image.fromarray(image_arr) display(image2)

이렇게 하면 색 변경 불가한 화이트 보드

white_board = np.full((200, 200), 255, dtype=np.uint8)

이렇게 하면 3차원 (색깔 변경 가능한 보드)

white_board_with_rgb = np.full((200, 200, 3), 255, dtype=np.uint8)

white1 = Image.fromarray(white_board) display(white1) white2 = Image.fromarray(white_board_with_rgb) display(white2)

***

# pandas 다루기
- 데이터 분석에 관련된 기능을 제공하는 파이썬 라이브러리 
- csv, txt, excel 처리가 용이함

import pandas as pd

### 시리즈
- 1차원 데이터 구조
![](https://velog.velcdn.com/images/leave_a_comment/post/343f67fb-47cb-4d2b-b0da-c97eb658b78c/image.png)



- 시리즈.index : 데이터의 위치와 기준을 나타내는 정보
- 시리즈.values : 저장된 실제 데이터 값
- 시리즈.dtype : 저장된 데이터의 자료형
- 시리즈.name : 데이터의 의미 정보
- 시리즈.size : 데이터의 개수

import pandas as pd visitors = pd.Series( [120, 100, 30, 200, 80], name="일일 마트 방문자 수" ) print(visitors)

print(visitors.index) print(visitors.values) print(visitors.dtype) print(visitors.name) print(visitors.size)

#### 인덱스와 함께 생성

name_data = pd.Series( data=[24, 31, 26], index=["김영철","송윤지","임수현"], name="나이" ) name_data

#### 연산

크기가 다른 인덱스끼리 만나면 결측치가 발생한다.

data1 = pd.Series([1,2,3]) data2 = pd.Series([10,20,30])

index가 0,1,2가 아니라 2,0,1로 변한다

data3 = pd.Series([10,20,30], index=[2,0,1]) data4 = pd.Series([10,20,30,40])

문자열과 숫자 연산은 불가능

데이터의 dtype을 바꾸는 메소드

data3_str = data3.astype(str)

#### 결측치

결측치가 있기 때문에 float로 출력됨

print(data3+data4)

data1 = pd.Series( data=[10, 20, 30], index=["부산", "울산", "대구"] ) print(data1)

data2 = pd.Series( data=[1, 2, 3, 4], index=["광주", "부산", "울산", "대구"] ) print(data2)

print (" ") add_data = data1 + data2 print(add_data) print(add_data.isna()) # 결측치가 존재하는지

print(add_data.fillna(1)) # 결측치를 1로 채운다 print(add_data.dropna()) # 결측치를 제거한다

import numpy as np import pandas as pd

np.nan -> 결측치 표시

data = pd.Series([1,2,np.nan, 4]) print(data)

결측치 유무 판별

print(data.isna()) print(data.isnull())

print("개수 :",data.isna().sum())

#### 통계

data.sum() data.min() data.max()

한번에 알려줌

data.describe()

![](https://velog.velcdn.com/images/leave_a_comment/post/c12c3c91-6bad-4b9b-a885-c8b73d4c3429/image.png)


### 데이터프레임
- 행과 열로 구성된 표 형태 데이터 구조
- 여러개의 Series가 모여 이루어졌다

import pandas as pd data_row_list = [ {"이름": "김영철", "성별": "M", "나이": 24, "키": 179.4}, {"이름": "송윤지", "성별": "F", "나이": 31, "키": 161.0}, {"이름": "임수현", "성별": "F", "나이": 26, "키": 174} ]

df = pd.DataFrame( data=data_row_list, columns=["이름", "성별", "나이", "키"] )

### 데이터프레임 속성
- 데이터프레임.index : 행의 위치와 기준을 나타내는 정보
- 데이터프레임.columns : 각 열의 이름과 데이터 의미 정보
- 데이터프레임.values : DataFrame에 저장된 실제 데이터 값
- 데이터프레임.dtypes : 각 열별 데이터 타입 정보
- 데이터프레임.shape : 행과 열의 개수를 튜플로 표현
- 데이터프레임.size : 전체 데이터 요소 개수
- 데이터프레임.ndim : 데이터가 몇 차원 구조인지 표현

데이터프레임에서 인덱스 설정하기

df.set_index("이름") df.reset_index()

### 데이터프레임 조회 및 검색

df.iloc[:, 열위치]

1번째에서 끝까지

df.iloc[:, 1:]

조회 3가지

df[] 열 이름으로 조회 할 떄만

df.loc[], df.iloc[]

df.loc[행, 열]

이름으로 조회

1) 열 조회 df[열이름] / df.loc[:, 열이름]

df.loc[:, ["이름"]]

2) 행 조회 df.loc[행이름, :]

df.loc[0, :]

3) 셀 조회 df.loc[행이름, 열이름]

df.loc[0, "이름"]

위치로 조회 df.iloc[행, 열]

1) 열 조회 df.iloc[:, 열위치]

df.iloc[:, 0]

2) 행 조회 df.iloc[행위치, :]

df.iloc[0, 1:]

3) 셀 조회 df.iloc[행위치, 열위치]

df.iloc[0, 0]

#### 조건부 조회

age_data3.loc[age_data3["이름"] == "김영철"]

송으로 시작해야 함

age_data3["이름"][1].startswith("송")

str 사용해야 함 !

age_data3["이름"].str.startswith("송")

age_data3.iloc[: , [0]]

endswith

contains

데이터 길이로 정제할 때 사용 .str.len()

pandas에서는 기호로 작성

조건 2개 and, &

조건 또는 or, |

### 데이터프레임 편집
- reset_index() 인덱스를 열로 이동시킨다

- 왜 필요한가?  조건으로 조회 후 인덱스가 연속되지 않기 떄문에 나중 조회에서 실수할 수 있다. 
- 초기화 해주는 게 좋다. 
#### 인덱스가 없는 데이터일 경우

age_data3.reset_index(drop=True) # index 열을 만들지 않는다.

#### 병합

#예제 데이터 import pandas as pd data1 = pd.DataFrame( data=[["강남", 1, 2], ["서초", 4, 5], ["노원", 5, 6]], columns=["지역명", "지점수", "매출"] ) data1

data2 = pd.DataFrame( data=[["강남", 10, 20], ["도봉", 40, 50], ["노원", 50, 60]], columns=["지역명", "지점수", "매출"] ) data2

data3 = pd.DataFrame( data=[["강남", 10, 20], ["도봉", 40, 50], ["노원", 50, 60]], columns=["지역명", "방문자수", "직원 수"] ) data3

데이터 병합

import pandas as pd

how = left # df1에 있는 지역명만 정리할거다 how = right # df2에 있는 지역명만 정리할거다 inner는 둘다 있는 지역명만, outer는 있는 지역명 전부

total_data = pd.merge( left=data1, right=data2, how="outer", # left, right, inner, outer on="지역명" # 무엇을 기준으로 ? )

total_data

total_data2 = pd.merge( left=data2, right=data3, how="inner", on="지역명" )

total_data2

#### 연산

데이터프레임 연산 : 행이름, 열이름이 같은 값끼리 연산된다.

시리즈 연산 : 인덱스명이 같은 값끼리 연산된다.

data1 + data2

### 데이터프레임 통계

결측치가 몇개 있는지

total_data.info()

df.info(): 데이터 수(행 개수), 열 개수, 열 이름, 데이터 타입, 결측치 개수

RangeIndex: 행 정보

Data columns : 열 정보

Non-null count : 결측치가 아닌 값 개수

데이터가 4개 있다 (4 entries)

5개의 열이 있다

지점수, 매출에 각각 1개의 결측치가 있다

열이 지점'수'인데 Dtype이 Str인지 아닌지 확인함으로써 이상한 데이터인지 확인

자리가 결측치인지 아닌지

total_data.isna()

total_data.isna().sum(axis=0) # axis=0 열별 결측치 개수 axis=1 행별 결측치 개수

total_data.describe() total_data.describe(include=["string"]) # 범주형 데이터 (카테고리)

성별에 대한 요약이 unique(종류)=3 개이면 잘못된 데이터 임을 파악

#### 데이터 불러오기

파일 불러오기

# pd.read_csv(파일경로, 인코딩)

txt

csv : 데이터가 쉼표로 구분되어 있다 -> 용량이 작다

tsv : 데이터가 탭으로 구분되어 있다

xls, xlsx 엑셀

```

1. Vscode > Extension > Python 설치
2. 기본 프로필 cmd로 선택
3. uv 설치
   • 파이썬 설치부터 라이브러리 관리까지 한 번에 도와주는 최신 도구
   • 폴더 경로 '한글' 사용 금지, 폴더 이름 변경 금지, .venv 폴더 내 파일을 직접 수정하거나 이동하지 말기. 라이브러리 관리는 uv add, uv remove 명령어 사용

     .python-version 은 파이썬 버전 작성 파일, pyproject.toml 는 프로젝트의 이름, 버전, 필요한 라이브러리 리스트 총괄 관리하는 핵심 파일

4. 가상환경 생성 (명령어: uv venv)
5. 가상환경 활성화 (명령어: source .venv/bin/activate)
6. 라이브러리 설치 (명령어: uv add jupyter)

   uv.lock 에 yarn.lock 처럼 정확한 라이브러리 버전 정보가 기록된다.

7. Jupyter Notebook (Extension 추가)
   • 코드 한 줄마다 실행 결과를 즉시 확인하며 학습 가능

변수/자료형과 관련 메소드

1. input

• 사용자 입력

  name = input("이름을 입력하세요")

2. list

• 여러 값을 순서대로 저장

  amounts = [100, 200, 300]

3. tuple

• 여러 값을 순서대로 저장 (* 수정 불가)

  amounts = (100, 200)

4. dict

• key, value 값을 함께 저장

  customers = {
    name: "나짱",
  }

5. set

• 중괄호({})로 선언. 중복 없는 값만 저장
• 원소의 순서가 의미 없으므로 인덱싱, 슬라이싱 불가

  container = {1, 2, 3}
  

합집합: | 또는 'union' 교집합: & 또는 'intersection' 차집합: - 또는 'difference' 대칭 차집합: ^ 또는 'symmetric_difference'

6. 슬라이싱
- data[start:end] :  인덱스 n에서 end-1까지 추출
- data[start:] 인덱스 m에서 끝까지 추출
- data[:end] 처음부터 end-1까지 추출

7. f-문자열
- 문자열 앞에 f를 붙이고 중괄호({})안에 변수나 표현식을 직접 넣을 수 있음

str = 'like this'

문자열 앞에 f 붙이기

print(f'do it {str}')

8. 문자열.capitalize()
- 맨 앞 문자 제외하고 소문자 처리

9. 문자열.strip()
- 양쪽에서 공백이나 지정한 문자열을 제거한 문자열 반환 (왼쪽은 lstrip, 오른쪽은 rstrip)

10. 문자열.count(sub) 
- 특정 문자열이 나타나는 횟수를 반환

11. range(n)
- 정수 0부터 n-1까지 범위의 리스트 생성

dd = list(range(8)) print(dd) dd.extend([4]) print(dd)

이렇게 하면 안됨. print(dd.extend([4])) => None 으로 출력됨

12. range(m, n)
- 정수 m부터 n-1까지 범위의 리스트 생성

13. range(m, n, x)
- 정수 m부터 n-1까지 x간격으로 생성

14. 리스트 삭제
- del 리스트[index]
- 리스트[start:end] = []
- 리스트.remove(값)
- 리스트.pop()

15. 리스트 추가
- 리스트 + [1,2,3]
- 리스트.extend([1,2,3])
- 리스트.append(값)
- 리스트.insert(index, value)

16. 딕셔너리 메소드
- 딕셔너리.keys() : 키 반환
- 딕셔너리.values() : value 반환
- 딕셔너리.items() : dict_items([('city', 'Seoul'), ('forecast', ['Sunny'])]) 형태로 반환
- 딕셔너리.clear() : 모든 요소 삭제
- 딕셔너리.get(key, "대신할 값")


### 참고

무슨 자료형인지 확인

print(type(x),type(y), type(z))

a를 b로 나눈 몫

a // b

a를 b로 나눈 나머지

a % b

a의 b제곱

a ** b

아래와 같이 한화를 가독성 있게 표현 가능

money = 10_000_000_000

"i'm" (o)

'I'M' (X)

'i'm' (O)'

줄바꿈 \n

여러줄은 '''''', """"""

"""""" 이렇게 하면 줄바꿈 생략 가능

긴글일때에는 따옴표를 3개 작성한다. ''', """

review = """
안녕하세요 오늘 짜장면은 정말 맛있었습니다.
"""

곱하기 연산

star = "*" result = star * 10

리스트 요소 변경

nums = list(range(8)) nums[2:4] = [20, 30]

nums[4:] = [50,60,70,80]

딕셔너리는 인덱싱, 슬라이싱 불가

del 딕셔너리[key] 사용하여 key 삭제 가능 in 연산자 사용해 해당 key가 있는지 확인 가능

***
## 반복문과 함수
1. enumerate
- index와 값을 함께 변수로 가져오고 싶을 때 사용
- 주로 특정 위치의 값을 제어하고 싶을 때 사용

fruits = ['apple', 'orange'] for idx, fruit in enumerate(fruits): print(idx, fruit)

***

2. def (함수 정의)
- *args, **kwargs : 매개변수의 수가 정해져 있지 않을 때 
- *args는 함수에 전달된 인수들을 튜플 형태로 받아서 처리
- **kwargs는 함수에 전달된 인수들을 딕셔너리 형태로 받아서 처리

def get_average_score(*args): length = len(args) return sum(args) / length

avg_score = get_average_score(70,70,70)

print(int(avg_score))

3. lambda
- 한줄 코드 작성

evens = list(filter(lambda x: x % 2 == 0, numbers))

4. 파일 읽기

import os

current_path = os.getcwd() files = os.listdir() os.mkdir("test")

오류 없이 파일 만들기

if not os.path.exists("test"): print("exist")

print(current_path) print(files)

5. 파일 생성
- w 모드로 파일을 생성할 경우 덮어쓰기 되어 이전의 내용은 지워진다. 

import os

def make_folder(forder_name): if not os.path.exists(forder_name): os.mkdir("test2")

make_folder("test2")

mode: w(writeㅡ생성), r(readㅡ읽기), a(appendㅡ추가)

""" with open(경로, mode="", encoding="") as 별칭: 실행할 코드 """

with open("./test2/mytest.txt", mode="w", encoding="utf-8") as f: f.write("hihi")

with open("./mytest.txt", mode="w", encoding="utf-8") as f: f.write("hihihihihih")

6. 예외 처리

try: 실행코드 except Exception as e: 오류가 나왔을 경우 실행할 코드 finally: 오류 여부와 상관없이 마지막에 실행할 코드

7. 시간 표현

from datetime import datetime, timedelta now = datetime.now()

#대소문자 구분해야함

print(now.strftime(format="%Y년-%m월-%d일 %H시 %M분 %S초")) print(f"1일 후: {now + timedelta(days=1)}") print(f"1시간 후: {now + timedelta(hours=1)}") print(f"1분 후: {now + timedelta(minutes=1)}")

#날짜 차이 구하기 from datetime import datetime

start_date = datetime(2026, 6, 20) end_date = datetime(2026, 6, 23)

diff = end_date - start_date

print(diff) print(diff.total_seconds()/60/60)

***
## 클래스 
- 클래스ㅡ는 데이터와 기능을 하나로 묶어준다.

class User: pass

user1 = User() user2 = User()

1. 생성자

class User: # init은 객체 생성 시 자동 실행 def init(self, name, email, department): self.name = name self.email = email self.department = department

def send_email(self):
    print(f"{self.department}의 {self.name}님에게 {self.email}로 이메일을 보냈습니다.")

def print_profile(self):
    print("이름", self.name)
    print("이메일:", self.email)
    print("부서:", self.department)

1. 내장 메소드

str : print를 실행했을 때 화면에 보여줄 내용을 정의하는 메소드 repr : 객체를 개발자가 확인하기 좋은 형태로 표현하는 메소드 len : len을 실행했을 때 어떤 값을 반환할지 정의하는 메소드 eq : ==연산자로 두 객체를 비교할 때 어떤 기준으로 같은지 판단할지 정의

2. 내부용 메소드
- _로 시작하는 메소드는 내부 사용 목적


3. 데코레이터
- 함수나 메소드의 동작 방식을 감싸서 확장하는 문법
- 기존 코드를 수정하지 않고 역할이나 성격을 추가하는 방법
- 클래스, 머신러닝, 딥러닝, ai 프레임워크 전반에서 매우 자주 등장한다.

@property : info()가 아니라 info로 사용한다. 값처럼 보이지만 내부에서는 함수가 실행된다. @classmethod : 객체를 만드는 책임을 클래스에게 맡긴다. 새로운 객체를 만드는 방법을 정의한다. @staticmethod : 해당 클래스와 의미적으로 관련된 기능을 묶기 위함 ```

이번 프로젝트를 진행하면서 Manifest V3의 구조와 파일 간 메시지 통신 방식을 이해할 수 있었고, 특히 return true의 역할을 직접 경험해볼 수 있었습니다.

1. 파일별 역할

Manifest V3에서는 각 파일이 명확한 역할을 가지고 있습니다.

• manifest.json — 확장 프로그램 설정 (이름, 버전, 권한, 실행 스크립트 등록)
• content.js — 검색 결과 페이지에 UI 및 버튼 생성
• background.js — Service Worker에서 핵심 로직 처리
• job_detail.js — 상세 페이지에서 데이터 수집

각 파일은 서로 직접 접근할 수 없으며 메시지(Message) 를 통해 통신합니다.

2. content.js

먼저 검색 결과 페이지에서 동작을 실행할 버튼을 생성했습니다.

버튼을 생성한 뒤 Object.assign()으로 스타일을 한 번에 적용했습니다.

Object.assign(openButton.style, {
  position: "fixed",
  top: "20px",
  right: "20px",
  zIndex: "999999",
  padding: "10px 16px",
  borderRadius: "8px",
  border: "none",
  background: "#2563eb",
  color: "white",
  cursor: "pointer",
  fontSize: "13px",
});

Object.assign(closeButton.style, {
  position: "fixed",
  top: "70px",
  right: "20px",
  zIndex: "999999",
  padding: "10px 16px",
  borderRadius: "8px",
  border: "none",
  background: "#dc2626",
  color: "white",
  cursor: "pointer",
  fontSize: "13px",
});

document.body.appendChild(openButton);
document.body.appendChild(closeButton);

Object.assign()을 사용하면 여러 스타일 속성을 객체 형태로 한 번에 적용할 수 있어 관리하기 편합니다.

또한 position: fixed와 높은 z-index를 사용해 어떤 페이지에서도 버튼이 항상 화면 위에 표시되도록 구현했습니다.

3. Background로 메시지 전달

버튼을 클릭하면 실제 작업은 background.js에서 처리하도록 구현했습니다.

const { newCount, totalCount, stop } =
  await chrome.runtime.sendMessage({
    type: "OPEN_JOBS",
    jobs,
  });

chrome.runtime.sendMessage()를 이용해 Background로 작업을 요청하고, await으로 작업이 완료될 때까지 기다린 뒤 결과를 받아옵니다.

4. background.js

Background에서는 메시지를 받아 필요한 작업을 수행합니다.

chrome.runtime.onMessage.addListener(
  (message, sender, sendResponse) => {
    // ...
  }
);

이번 프로젝트에서는 메시지 처리 과정에서 chrome.storage.local과 popup도 함께 사용했습니다.

chrome.storage.local

chrome.storage.local은 크롬 확장 프로그램 전용 저장소입니다.

웹에서 사용하는 localStorage와 비슷하지만, 확장 프로그램 환경에서 사용할 수 있도록 제공되는 API입니다.

주로 작업 상태나 설정값처럼 브라우저를 종료해도 유지되어야 하는 데이터를 저장할 때 사용합니다.

popup

popup은 확장 프로그램 아이콘을 클릭했을 때 표시되는 작은 HTML 화면입니다.

현재 작업 상태를 보여주거나 간단한 설정 화면을 구현할 때 자주 사용됩니다.

5. return true를 꼭 추가해야 하는 이유

이번 프로젝트에서 가장 오래 헤맸던 부분이 바로 이것이었습니다.

Chrome의 메시지 채널은 리스너 함수가 종료되는 순간 함께 닫힙니다.

chrome.runtime.onMessage.addListener(
  (message, sender, sendResponse) => {
    handleMessage(message).then(sendResponse);

    return true;
  }
);

handleMessage()처럼 비동기 작업이 끝난 뒤 sendResponse()를 호출하는 구조라면 return true가 반드시 필요합니다.

return true는 Chrome에게

"아직 응답이 끝나지 않았으니 메시지 채널을 유지해 주세요."

라고 알려주는 역할을 합니다.

만약 return true가 없다면 비동기 작업이 끝나기 전에 채널이 먼저 닫히게 되고 sendResponse()가 호출되더라도 응답은 무시됩니다.

문서에서는 간단하게 설명되어 있는 내용이지만 직접 경험해보니 Manifest V3의 비동기 메시지 통신에서 가장 중요한 부분 중 하나라는 것을 알게 되었습니다.

온톨로지는 현실 세계의 지식이나 정보를 지도처럼 그려내 AI가 사람처럼 사고할 수 있도록 돕는 구조적 기반이다. 즉 특정 분야에 존재하는 개념이나 관계를 명확하게 정의하고 구조화한 지식 모델이다.

온톨로지 구성 요소

1. 개체

• 도메인 안에서 실제로 존재하고 식별할 수 있는 구체적인 대상 ex) 배달원, 특정 배달 주문

2. 클래스

• 유사한 개체들을 묶는 범주로, 도메인의 기본 분류 체계를 형성 ex) DeliveryWorker(배달원), Order(주문)

3. 속성

• 클래스에 속한 개체가 공통으로 가진 고유한 특징이나 상태를 설명하는 요소 ex) 배달원 - 현재 위치, 근무 가능 여부, 주문 - 배달 주소, 주문 시간

4. 관계

• 두 개체가 어떻게 연결되어 있는지를 나타내는 의미적 연결 ex) 배달원은 직원이다 (is-a), 주문은 배달 주소를 가지고 있다 (have-a)

5. 제약 조건

• 속성과 관계가 지켜야 하는 규칙, 도메인 일관성 유지 ex) 한 배달원은 같은 시간에 두 주문을 수행할 수 없다

온톨로지의 필요성 : 데이터가 가진 의미와 그 관계가 정리 되어 있어야 한다

팔란티어는 온톨로지가 데이터, 사건, 자원을 현실 세계의 관계로 재구성해 공통된 언어의 명확한 시스템을 제공한다고 강조했다. 온톨로지로 인해 복잡하고 비효율적인 데이터 전처리 및 정제 작업의 부담을 크게 줄일 수 있다.

개인적으로는 데이터베이스의 ERD를 설계할 때 저장하려는 데이터 간의 관계와 구조를 미리 예측해 설계해야 한다는 점에서 온톨로지와 닮았다고 느꼈다. 엔티티들을 관계로 엮어 전체 구조를 그려나가는 과정이 마인드맵과도 비슷하다고 생각했다.

서비스마다 도메인 정책과 용어 정의가 모두 다르기 때문에 기업별 온톨로지 정의는 반드시 필요하다고 생각한다.

특히 Claude Code를 사용하면서 매번 바로잡아야 했던 내용들을 온톨로지를 통해 선제적으로 명확히 잡고 갈 수 있을 것 같다. 잘못된 결과를 고치기 위한 반복 작업이 줄어드는 만큼 결과적으로 비용 효율도 높아질 수 있다고 본다.

결국 AI를 잘 활용하는 핵심은 의미와 맥락의 일관성을 확보하는 데 있고 토큰 비용 절감은 그 과정에서 자연스럽게 따라오는 부산물이라고 생각한다.

LLM이란 무엇인가?

LLM은 Large Language Model로 직역하면 거대언어모델인데 그 의미는 수많은 파라미터, 즉 모델 내부의 가중치를 학습해 언어의 규칙과 패턴을 익히는 모델이다.

'이 문맥에서 어떤 단어가 올 가능성이 높은가?'를 예측하면서 언어를 배우고, 이를 통해 문장을 생성하게 된다.

이런 예측의 기반이 되는 것은 트랜스포머라는 구조인데,

트랜스포머가 거대 언어 모델에 특히 적합한 이유는 위치 인코딩과 Self-Attention이라는 두 가지 핵심 기술 덕분이다.

위치 인코딩은 단어가 나타나는 순서 정보를 담아 단어를 순차적으로 입력하지 않아도 위치를 알 수 있게 하고, Self-Attention은 입력된 단어들의 관계를 한꺼번에 계산하면서 실제로 중요한 부분에 더 집중하도록 가중치를 부여한다.

이 덕분에 긴 문장을 처리하거나 문장 속 멀리 떨어져 있는 단어들 사이의 관계도 훨씬 잘 파악할 수 있게 되고, 복잡한 연산을 병렬로 나눠 처리할 수 있어 GPU를 활용한 대규모 학습이 가능해진다.

LLM의 작동 방식

대부분의 LLM은 크게 두 단계의 학습 과정을 거친다.

사전학습(Pretraining) 단계에서는 방대한 양의 텍스트 데이터를 기반으로 문맥을 이해하고 언어의 패턴을 익힌다. 이 단계는 레이블이 없는 데이터를 사용하는 비지도 학습으로 이루어지기 때문에, 별도의 데이터 레이블링 없이도 대규모 학습이 가능하다. 이렇게 만들어진 범용 모델을 파운데이션 모델이라고 한다.

파인튜닝(Fine-Tuning) 단계에서는 요약, 번역, 질의응답 등 특정 태스크에 적합한 데이터셋으로 추가 학습을 진행한다. -> 특정 업무에 필요한 지식과 답변 방식을 덧붙이게 된다. (파인튜닝 외에도 프롬프트 튜닝, 어댑터 등의 맞춤화 기법이 있다.)

LLM의 한계

LLM은 한 번에 처리할 수 있는 입력의 길이가 정해져 있어서 입력이 너무 길어지면 문맥의 앞부분을 잊어버리거나 처리하지 못하는 경우가 생긴다.

할루시네이션 현상도 인간이 판별해야한다.

프롬프트를 더 잘 입력하기 위한 LLM Deep Dive

1. 토큰과 토크나이저 — LLM이 텍스트를 "보는" 방식
2. 트랜스포머 아키텍처 — LLM의 두뇌 구조
3. Pre-training에서 RLHF까지 — LLM이 똑똑해지는 과정
4. 컨텍스트 윈도우와 어텐션 그리고 확률의 세계

이 글을 다 읽고 나면, LLM에게 프롬프트를 줄 때 "왜 이렇게 써야 하는지"가 자연스럽게 이해될 것입니다!!!

1. 토큰과 토크나이저: LLM이 텍스트를 보는 방식

• LLM은 토큰 단위로 텍스트를 처리
• 토큰은 통계적으로 자주 함께 등장하는 문자열 조각이다.

1-1. 토크나이저의 작동 원리

• 토크나이저는 텍스트를 토큰으로 분할하는 알고리즘
• 대부분의 현대 LLM은 BPE(Byte Pair Encoding) 또는 그 변형을 사용한다.

모든 텍스트는 개별 바이트로 분해되고 가장 자주 연속으로 등장하는 짝을 찾아 하나의 토큰으로 병합한다. 이 과정을 원하는 어휘 크기에 도달할 때까지 반복한다.

대부분의 LLM은 영어 기준으로 학습이 되었기 때문에 한국어보다 영어가 더 효율적이다. 영어로 짜는 프롬프트에 익숙해져야겠다.(오늘부터 영어공부 드간다)

• 모든 LLM에는 처리 가능한 최대 토큰 수가 있다.
• 입력 토큰 + 출력 토큰 = 전체 토큰 사용량*

참고) 글자 수 세기 같은 작업이 어렵다, JSON보다 CSV가 토큰 효율이 높을 수 있다.

1-2. 트랜스포머 아키텍처: LLM의 두뇌 구조

• 트랜스포머의 핵심 셀프 어텐션
• 셀프 어텐션은 각 토큰이 다른 모든 토큰과의 관련도 점수를 계산한다.
• 셀프 어텐션은 내부적으로 Query, Key, Value로 벡터를 산정한다. Query (Q): "나는 어떤 정보가 필요한가?" — 현재 토큰의 질문 Key (K): "나는 어떤 정보를 가지고 있는가?" — 각 토큰의 라벨 Value (V): "내가 제공할 실제 정보" — 각 토큰의 실제 내용

1. 각 토큰이 Q, K, V를 생성
2. Q와 모든 K의 유사도를 계산 (= 어텐션 점수)
3. 어텐션 점수로 V를 가중 합산 (= 컨텍스트를 반영한 새로운 표현)

참고) 관련 정보를 가까이 배치, 마크다운, 번호 매기기 등은 모델이 정보의 관계를 파악하는 데 도움을 줍니다.

1-3. LLM의 학습 세단계

1. Pre-training - 언어를 배운다
2. Fine-tuning - 대화를 배운다
3. RLHF / RLAIF - 좋은 답변을 배운다

1-4. 컨텍스트 윈도우와 어텐션 그리고 확률의 세계

• 컨텍스트 중간에 배치된 정보는 처음이나 끝에 배치된 정보보다 누락될 가능성이 높습니다.

참고) 실전에서의 대응: [프롬프트 구성 권장 순서]

1. 시스템 지시사항 (역할, 규칙) ← 처음: 높은 주목도
2. 참조 데이터, 배경 정보 ← 중간: 상대적으로 낮은 주목도
3. 핵심 질문 또는 작업 지시 ← 끝: 높은 주목도

• 셀프 어텐션의 계산 복잡도는 O(n²)로 긴 컨텍스트는 느리고 비싸다.

• LLM의 본질을 한 마디로 요약하면** 주어진 텍스트 다음에 올 토큰의 _확률 분포_를 예측하는 모델 **이다.

입력: "오늘 날씨가 정말"

모델이 예측한 다음 토큰 확률:
  "좋다"    → 35%
  "춥다"    → 20%
  "덥다"    → 15%
  "맑다"    → 12%
  "흐리다"  → 5%
  "나쁘다"  → 3%
  ...       → (나머지 토큰들의 확률 합 = 10%)

여기서 어떤 토큰을 실제로 선택할지를 결정하는 것이 디코딩 전략(Decoding Strategy)입니다.

Temperature(온도)는 확률 분포의 "뾰족함"을 조절합니다.

Temperature = 0 (또는 매우 낮음)

• 같은 입력에 거의 같은 출력
• 적합한 용도: 사실 기반 답변, 코드 생성, 분류, 데이터 추출

Temperature = 1.0 (기본값)

• 원래 학습된 확률 분포를 그대로 사용
• 적합한 용도: 일반적인 대화

Temperature > 1.0 (높은 값)

• 창의적이지만 불안정: 예상치 못한 표현이 나올 수 있음
• 적합한 용도: 창작, 브레인스토밍, 다양한 아이디어 생성

2. 프롬프트 잘 쓰는 방법

• *명확한 지시 *

❌ 모호한 프롬프트:

"이 코드를 개선해줘"

✅ 구체적인 프롬프트:

"이 Python 코드의 성능을 개선해줘.

• 시간 복잡도를 O(n²)에서 O(n log n)으로 줄여줘
• 원래 함수의 입출력 인터페이스는 유지해줘
• 변경한 부분에 주석을 달아줘"

• 역할 부여

  당신은 10년 경력의 시니어 백엔드 개발자입니다. 코드 리뷰 시 다음 관점에서 검토합니다:

  • 보안 취약점
  • 성능 병목
  • 에러 핸들링
  • 코드 가독성

• 예시 제공

• 제약 조건 명시

• 구분자 활용

3. 대규모 분석 작업을 위한 전략

3-1. 청킹

3-2. Map-Reduce

• Map 단계

다음 고객 리뷰 500건을 분석해주세요.

각 리뷰에 대해:
1. 감성 (긍정/부정/중립)
2. 주요 불만/칭찬 카테고리
3. 긴급도 (1~5)

결과를 JSON 배열로 출력해주세요.

• Reduce 단계 (Map 결과를 종합)

다음은 고객 리뷰 1만 건을 500건씩 분석한 결과 20개입니다.

이 결과들을 종합하여:
1. 전체 감성 분포
2. 상위 5개 불만 카테고리와 비율
3. 긴급 조치가 필요한 이슈
4. 개선 제안 우선순위

를 작성해주세요.

3-3. 반복 정제

--- 1차 프롬프트 ---
"이 API 문서를 읽고 모든 엔드포인트의 목록을 추출해주세요."

--- 2차 프롬프트 ---
"1차 결과를 검토해주세요. 
 원본 문서와 대조하여 누락된 엔드포인트가 있는지 확인하고,
 각 엔드포인트의 HTTP 메서드와 파라미터 정보를 보완해주세요."

--- 3차 프롬프트 ---
"최종 엔드포인트 목록을 OpenAPI 3.0 YAML 형식으로 변환해주세요.
 각 엔드포인트에 description을 추가해주세요."

3-4. 분할 정복

전체 작업: "이 프로젝트의 보안 취약점을 분석해주세요"

분할:
├── 작업 1: SQL Injection 취약점 스캔
├── 작업 2: XSS 취약점 스캔
├── 작업 3: 인증/인가 로직 검토
├── 작업 4: 의존성 패키지 취약점 확인
└── 작업 5: 환경 변수/시크릿 노출 검토

통합: 각 작업의 결과를 종합하여 우선순위별 보안 보고서 작성

3-5. 일관된 프롬프트 템플릿

ANALYSIS_TEMPLATE = """
### 역할
당신은 {domain} 전문 분석가입니다.

### 작업
아래 데이터를 분석하여 {task_description}을 수행하세요.

### 규칙
- 원본 데이터에 없는 정보를 추론하지 마세요
- 확실하지 않은 항목은 "불확실"로 표시하세요
- 결과는 아래 JSON 스키마를 정확히 따르세요

### 출력 형식
```json
{output_schema}

4. 할루시네이션 대응

4-1. 근거 기반 답변 강제

"아래 문서만을 근거로 질문에 답변해주세요.
 - 문서에 명시된 정보만 사용하세요
 - 문서에 없는 정보는 '문서에 해당 정보가 없습니다'라고 답해주세요
 - 답변할 때 근거가 되는 문서의 해당 부분을 인용해주세요

[문서]
...

[질문]
..."

4-2. 자기 검증

"답변을 작성한 후, 다음을 자체 검증해주세요:
 1. 각 사실적 주장 옆에 [확신도: 상/중/하] 표시
 2. 확신도가 '하'인 항목은 별도 목록으로 분리
 3. 원본 데이터와 대조하여 불일치 항목 표시"

4-3. Temperature 낮추기

Temperature = 0 설정

→ 가장 확률이 높은 토큰만 선택
→ 창의적이지만 부정확한 내용 생성 확률 감소
→ 사실 기반 작업에 필수

4-3. 구조화된 출력 + 필수 필드

{
  "answer": "답변 내용",
  "confidence": 0.85,
  "sources": ["문서 3.2절", "표 4"],
  "caveats": ["매출 데이터는 3분기까지만 반영"],
  "unable_to_determine": ["4분기 예측치는 문서에 없음"]
}

4-4. 최신 정보가 특정 도메인 정보는 직접 제공

[시스템]
아래 검색 결과를 참고하여 질문에 답변하세요.
검색 결과에 없는 내용은 답변하지 마세요.

[검색 결과]
1. [출처: 2024년 3분기 실적 보고서] "..."
2. [출처: 제품 매뉴얼 v3.2] "..."

[질문]
3분기 매출은 얼마인가요?

RAG (검색 증강 생성)

RAG(Retrieval-Augmented Generation)는 LLM에게 질문과 함께 관련 정보를 검색하여 제공함으로써, 더 정확하고 최신의 답변을 생성하게 하는 기법입니다.

[기존 방식]
질문 → LLM (학습된 지식만으로 답변) → 답변
        ⚠️ 학습 이후 정보 부재, 환각 위험

[RAG 방식]
질문 → 검색 엔진 (관련 문서 검색) → 질문 + 검색 결과 → LLM → 답변
        ✅ 최신 정보 활용, 근거 기반 답변

1. 임베딩과 벡터 검색

임베딩이란? 임베딩(Embedding)은 텍스트를 의미를 보존하는 고차원 벡터로 변환하는 것입니다.

"강아지"     → [0.82, -0.15, 0.43, ...]
"puppy"      → [0.80, -0.12, 0.45, ...]  ← 의미가 비슷 → 벡터가 가까움
"자동차"     → [-0.31, 0.67, -0.22, ...]  ← 의미가 다름 → 벡터가 멀음

에이전트

에이전트란? LLM 에이전트(Agent)는 단순히 텍스트를 생성하는 것을 넘어, 목표를 이해하고, 계획을 세우고, 도구를 사용하여 작업을 수행하는 시스템입니다.

[일반 LLM 사용]
사용자: "서울 날씨 알려줘"
LLM: "제가 실시간 날씨 정보에 접근할 수 없습니다."

[에이전트]
사용자: "서울 날씨 알려줘"
에이전트 사고: "날씨 정보가 필요하다 → weather API를 호출하자"
  → weather_api("서울") 호출
  → 결과: {"temp": 15, "condition": "맑음"}
에이전트: "서울의 현재 날씨는 맑음이며, 기온은 15도입니다."

에이전트의 핵심 구성 요소

1. LLM (두뇌) 모든 판단과 계획의 중심입니다. 사용자의 요청을 이해하고, 어떤 도구를 어떤 순서로 사용할지 결정합니다.

2. 도구 (Tools / Functions) 에이전트가 외부 세계와 상호작용하는 수단입니다.

3. 메모리 / 상태 에이전트가 작업 진행 상황을 추적하는 메커니즘입니다.

Tool Use 메커니즘

Tool Use (함수 호출) 메커니즘 에이전트의 핵심 기능인 Tool Use는 다음과 같이 작동합니다.

1. 사용자가 질문/요청
    ↓
2. LLM이 사용 가능한 도구 목록에서 적절한 도구 선택
    ↓
3. LLM이 도구 호출에 필요한 파라미터를 JSON으로 생성
    ↓
4. 시스템이 실제로 도구를 실행
    ↓
5. 도구의 실행 결과를 LLM에게 전달
    ↓
6. LLM이 결과를 해석하여 답변 생성 (또는 추가 도구 호출)

주요 에이전트 패턴

패턴 1: ReAct (Reasoning + Acting) 가장 기본적이고 널리 사용되는 패턴입니다.

Thought: 사용자가 서버 에러의 원인을 파악하길 원한다.
         먼저 최근 로그를 확인해야 한다.
Action:  read_log(service="api-server", last="1h")
Observation: [TimeoutError] DB connection pool exhausted at 14:32...

Thought: DB 커넥션 풀이 소진된 것이 원인이다.
         DB의 현재 연결 수를 확인하자.
Action:  query_db("SELECT count(*) FROM pg_stat_activity")
Observation: count: 150 (max_connections: 100)

Thought: 최대 연결 수를 초과했다. 어떤 쿼리가 연결을 점유하고 있는지 확인.
Action:  query_db("SELECT query, state FROM pg_stat_activity WHERE state='active'")
Observation: 대부분 analytics_daily 배치 쿼리가 점유 중...

Thought: 원인을 파악했다. 사용자에게 보고하자.
Answer:  "서버 에러의 원인은 analytics_daily 배치 작업이 DB 연결을 
         과도하게 점유하여 커넥션 풀이 소진된 것입니다. ..."

패턴 2: Plan and Execute 복잡한 작업을 먼저 계획한 후 순차적으로 실행합니다.

[계획 단계]
목표: "프로젝트의 보안 취약점을 분석하고 보고서를 작성하라"

계획:
1. 프로젝트 구조 파악 (read_file)
2. 의존성 패키지 취약점 스캔 (run_command: npm audit)
3. 코드 내 SQL Injection 패턴 검색 (search_code)
4. 코드 내 XSS 패턴 검색 (search_code)
5. 환경 변수/시크릿 노출 검사 (search_code)
6. 결과 종합하여 보고서 작성

[실행 단계]
→ 계획의 각 단계를 순차 실행, 필요시 계획 수정

패턴 3: Multi-Agent 여러 전문 에이전트가 협력하여 작업을 수행합니다.

[오케스트레이터 에이전트]
    ├── [리서치 에이전트] - 정보 수집 전문
    ├── [코딩 에이전트] - 코드 작성 전문
    ├── [리뷰 에이전트] - 코드 검토 전문
    └── [테스트 에이전트] - 테스트 작성 및 실행 전문

에이전트의 현실적 한계

1. 누적 오류 단계가 많아질수록 각 단계의 작은 오류가 누적됩니다.

2. 도구 선택 실수 LLM이 잘못된 도구를 선택하거나, 올바른 도구에 잘못된 파라미터를 전달할 수 있습니다.

3. 무한 루프 에이전트가 같은 행동을 반복하거나, 실패를 인식하지 못하고 계속 시도할 수 있습니다.

4. 비용 폭발 복잡한 작업에서 에이전트가 수십 번의 LLM 호출을 하면 비용이 급격히 증가합니다.

** 안전한 에이전트 설계 원칙 **

1. 최소 권한 원칙: 에이전트에게 필요한 최소한의 도구만 제공
2. 인간 확인 단계: 위험한 행동(삭제, 전송 등) 전에 사용자 확인
3. 실행 제한: 최대 반복 횟수, 최대 비용, 타임아웃 설정
4. 로깅: 모든 도구 호출과 결과를 기록하여 디버깅 가능하게
5. 롤백 가능성: 에이전트의 행동을 되돌릴 수 있는 메커니즘 준비

멀티모달 LLM

멀티모달 LLM이란? 멀티모달(Multimodal) LLM은 텍스트뿐 아니라 이미지, 오디오, 비디오, 문서 등 다양한 형태의 입력을 이해하고 처리할 수 있는 모델입니다.

[텍스트 전용 LLM]
입력: 텍스트 → 출력: 텍스트

[멀티모달 LLM]
입력: 텍스트 + 이미지 + PDF + ... → 출력: 텍스트 (+ 이미지)

멀티모달 비용 고려 이미지 입력은 텍스트보다 토큰 소모가 큽니다.

일반적인 이미지 토큰 소모

• 저해상도 (512×512): ~85 토큰
• 중해상도 (1024×1024): ~170 토큰
• 고해상도 (2048×2048): ~680 토큰
• 매우 큰 이미지: 1,000+ 토큰

실전 팁

• 이미지 + 구체적 질문을 결합하세요. 맥락 없는 이미지만 보내면 일반적인 설명만 돌아옵니다.
• 비전은 "대략적 이해"에 강하고 "정밀 측정"에 약합니다. 정확한 수치가 필요하면 텍스트로 제공하세요.
• PDF에서 표가 많다면 텍스트 추출 후 전달하는 것이 더 정확할 수 있습니다.
• 디버깅에 적극 활용하세요. 에러 화면 스크린샷은 텍스트로 옮기는 것보다 정보 손실이 적습니다.
• 여러 이미지를 한 번에 비교할 수 있습니다. "이 두 디자인의 차이점을 찾아줘" 같은 요청이 가능합니다.

프론트엔드 개발을 하다 보면 성능 최적화 이야기를 정말 많이 듣는다.

• React 렌더링 최적화
• 이미지 최적화
• Code Splitting
• Virtualization
• 캐싱

하지만 정작 성능이 무엇이냐고 물어보면 의외로 명확하게 설명하기 어렵다.

최근 MDN의 Performance Fundamentals 문서를 읽다가 인상 깊었던 부분이 있었다.

MDN은 성능을 단순히 "빠른 코드"가 아니라

사용자가 얼마나 빠르고 부드럽게 느끼는가

라고 설명한다.

이번 글에서는 MDN의 내용을 바탕으로 웹 성능의 기본 개념들을 정리해보려고 한다.

성능은 결국 사용자가 느끼는 것이다

개발자는 종종 숫자에 집중한다.

예를 들면

• API 처리량
• 초당 요청 수(TPS)
• CPU 사용량
• 메모리 사용량

같은 것들이다.

물론 이런 지표들도 중요하다.

하지만 사용자는 이런 숫자를 체감하지 않는다.

사용자가 실제로 느끼는 것은 훨씬 단순하다.

• 버튼을 눌렀을 때 얼마나 빨리 반응하는지
• 페이지가 얼마나 빨리 나타나는지
• 스크롤이 얼마나 부드러운지
• 애니메이션이 끊기지 않는지

결국 성능 최적화의 목적은 벤치마크 점수를 높이는 것이 아니라, 사용자가 답답함 없이 서비스를 이용할 수 있도록 만드는 것이다.

웹 성능을 결정하는 네 가지 요소

MDN에서는 웹 성능을 크게 네 가지 관점으로 설명한다.

1. Responsiveness (반응성)

사용자의 입력에 얼마나 빠르게 반응하는지를 의미한다.

예를 들어 사용자가 버튼을 클릭했을 때

버튼 클릭
 ↓
API 요청
 ↓
화면 변경

이 과정이 오래 걸리면 사용자는 서비스가 느리다고 느낀다.

실제로 사용자는 몇 초가 걸렸는지보다

"내 행동에 바로 반응했는가"

를 훨씬 중요하게 생각한다.

그래서 스켈레톤 UI, Optimistic Update 같은 기법이 등장하게 된다.

2. Frame Rate (프레임 레이트)

화면이 얼마나 부드럽게 움직이는지를 의미한다.

우리가 흔히 말하는 60FPS, 120FPS가 여기에 해당한다.

프레임이 떨어지면 다음과 같은 현상이 발생한다.

• 스크롤 끊김
• 애니메이션 버벅임
• 드래그 지연
• 화면 전환 시 뚝뚝 끊기는 느낌

브라우저는 이러한 문제를 줄이기 위해 GPU를 활용한다.

특히 다음과 같은 속성은 GPU 가속을 받을 수 있다.

transform
opacity

반면 아래 속성들은 레이아웃 계산을 유발할 수 있다.

top
left
width
height

그래서 애니메이션을 구현할 때는 transform, opacity 기반으로 작성하는 경우가 많다.

3. Memory Usage (메모리 사용량)

메모리를 적게 사용하는 것이 항상 좋은 것은 아니다.

예를 들어

• 캐시 데이터
• 이미지
• 상태 정보

등을 적절히 메모리에 유지하면 오히려 더 빠른 사용자 경험을 제공할 수 있다.

중요한 것은

불필요하게 점유하는 메모리를 줄이는 것

이다.

대표적인 메모리 문제는 다음과 같다.

• 이벤트 리스너 해제 누락
• requestAnimationFrame 정리 누락
• 타이머 정리 누락
• 대용량 객체 참조 유지

특히 React에서는 useEffect의 cleanup 함수가 중요하다.

4. Power Usage (전력 사용량)

성능은 배터리와도 연결된다.

특히 모바일 환경에서는 더욱 중요하다.

예를 들어

setInterval(() => {
  doSomething();
}, 16);

처럼 지속적으로 작업을 수행하면

• CPU 사용량 증가
• 발열 증가
• 배터리 소모 증가

로 이어질 수 있다.

사용자가 오래 사용할 수 있는 서비스를 만드는 것도 성능 최적화의 일부다.

웹 성능은 로딩 속도만의 문제가 아니다

많은 사람들이 성능이라고 하면 페이지 로딩 속도만 떠올린다.

하지만 실제로는 훨씬 넓은 개념이다.

사용자가 서비스를 이용하는 과정은 다음과 같다.

첫 화면 표시
 ↓
사용 가능 상태
 ↓
부드러운 상호작용
 ↓
전체 콘텐츠 로딩 완료

이 모든 과정이 성능 경험을 구성한다.

특히 사용자는 모든 리소스가 완전히 로딩되는 시점보다

"언제부터 사용할 수 있었는지"

를 더 중요하게 느끼는 경우가 많다.

그래서 최근에는 체감 성능(User Perceived Performance)이 더욱 중요해지고 있다.

브라우저는 생각보다 많은 최적화를 해준다

우리는 단순히 JavaScript 코드를 작성하지만, 브라우저 내부에서는 다양한 최적화가 이루어진다.

예를 들어

• JIT 컴파일
• Hidden Class
• Inline Cache
• GPU 가속
• 병렬 파싱
• 레이아웃 최적화

등이 있다.

특히 JavaScript 엔진은 자주 실행되는 코드를 머신 코드로 최적화해 실행 속도를 높인다.

그래서 객체 구조를 일정하게 유지하거나, 예측 가능한 코드를 작성하는 것이 성능에 영향을 줄 수 있다.

실제 프론트엔드에서 자주 사용하는 성능 최적화 방법

불필요한 렌더링 줄이기

• React.memo
• useMemo
• useCallback

등을 활용해 불필요한 연산과 렌더링을 줄인다.

다만 모든 곳에 사용하는 것이 아니라

비용이 큰 연산에 선택적으로 적용하는 것

이 중요하다.

Virtualization 활용하기

리스트를 한 번에 모두 렌더링하지 않고,

현재 화면에 보이는 영역만 렌더링한다.

예를 들어

• FlashList
• react-window
• react-virtualized

같은 라이브러리가 대표적이다.

수천 개의 아이템을 다루는 경우 성능 차이가 크게 나타난다.

요청 수 줄이기

불필요한 API 요청은 사용자 경험을 악화시킨다.

예를 들어

API 10개 요청
 ↓
각 요청마다 네트워크 지연 발생
 ↓
체감 속도 저하

로 이어질 수 있다.

그래서 다음과 같은 전략을 사용한다.

• 캐싱
• 요청 병합
• Prefetch
• Debounce
• Throttle

결국 성능의 핵심은

예전에는 성능을

"코드가 얼마나 빠르게 동작하는가"

라고 생각했다.

하지만 실제 서비스를 개발하면서 느낀 건

"사용자가 얼마나 빠르게 느끼는가"

가 훨씬 중요하다는 점이었다.

사용자는 JIT 컴파일이나 번들 크기를 직접 보지 않는다.

대신

• 버튼이 즉시 반응하는지
• 화면이 빠르게 나타나는지
• 스크롤이 부드러운지
• 기다리는 시간이 길지 않은지

를 경험한다.

결국 좋은 성능이란 단순히 숫자를 개선하는 것이 아니라

사용자가 스트레스 없이 서비스를 이용할 수 있도록 만드는 것에 더 가깝다고 생각한다.

• 렌더링 최적화
• bundle size 감소
• memoization
• virtualization

그런데 막상 서비스를 만들다 보면, 생각보다 더 자주 체감되는 건 네트워크 속도 문제였다.

분명 React 렌더링은 빠른데

• API 응답이 늦게 오고
• 첫 화면이 늦게 뜨고
• 버튼 누른 뒤 반응이 한 박자 늦는다

결국 사용자 입장에서 중요한 건

“얼마나 빨리 반응하냐”

에 가까웠다.

그 과정에서 자주 보게 되는 개념이 바로 Latency(지연 시간)다.

이번 글에서는 Latency가 정확히 뭔지, 웹 성능과 왜 연결되는지 정리해보려 한다.

Latency란?

Latency는 간단히 말하면

요청을 보내고 응답을 받을 때까지 걸리는 시간

이다.

예를 들어 브라우저가

GET /api/user

요청을 보냈다고 해보자.

그럼 내부적으로는 생각보다 많은 과정이 발생한다.

브라우저
  ↓
DNS 조회
  ↓
서버 연결(TCP)
  ↓
HTTPS 연결(TLS)
  ↓
서버 요청 전달
  ↓
서버 응답 생성
  ↓
브라우저 응답 수신

우리가 흔히 "응답이 느리다"고 느끼는 건 이 전체 과정에서 발생하는 시간 때문이다.

왜 모바일에서 더 체감될까?

개발할 때는 대부분 빠른 Wi-Fi 환경을 사용한다.

그래서 성능 문제가 잘 안 느껴질 때가 많다.

그런데 실제 사용자 환경은 다르다.

• 지하철
• LTE
• 불안정한 공용 Wi-Fi
• 해외 로밍

같은 환경에서는 Latency가 훨씬 커진다.

예를 들어

3G 환경에서는 요청 하나마다 수백 ms씩 지연될 수도 있다.

여기에

• API 여러 개
• 이미지 요청
• 폰트 요청

까지 겹치면 체감 속도는 급격하게 느려진다.

첫 요청이 특히 느린 이유

처음 요청은 단순히 API만 호출하는 게 아니다.

그 전에

DNS Lookup
→ TCP Handshake
→ TLS Handshake

과정을 먼저 거친다.

즉

• 서버 주소 찾기
• 연결 생성
• HTTPS 보안 연결

비용이 포함된다.

그래서 첫 요청(TTFB)이 상대적으로 느리다.

반대로 두 번째 요청부터는 이미 연결이 유지되고 있어서 더 빨라진다.

Chrome DevTools에서 보면 보이는 것들

Chrome DevTools → Network 탭을 열어보면 요청 시간들이 꽤 자세하게 나온다.

처음엔 그냥 지나쳤는데, 알고 보니 각각 의미가 있었다.

DNS Lookup

example.com → IP 주소 변환

과정.

도메인이 많아질수록 DNS 조회도 늘어난다.

TCP Handshake

브라우저와 서버가 실제 연결을 맺는 과정.

쉽게 말하면

"우리 이제 통신 시작하자"

정도 느낌이다.

TLS Handshake

HTTPS 보안 연결 생성 과정.

보안 연결은 필수지만 비용도 존재한다.

Waiting (TTFB)

서버가 응답을 생성하는 시간.

예를 들어

• DB 조회
• SSR 렌더링
• 인증 처리

같은 작업이 오래 걸리면 여기 시간이 길어진다.

Receiving

실제 다운로드 시간.

파일 크기가 클수록 오래 걸린다.

예

• 큰 이미지
• 무거운 JS bundle
• 큰 JSON 응답

등.

그래서 요청 수가 중요하다

예전에는

"코드 실행 속도"

만 성능이라고 생각했는데 실제 서비스에서는 요청 수가 더 중요할 때도 많았다.

예를 들어

API 10개 요청

이 발생하면 요청마다 Latency가 누적된다.

특히 모바일 환경에서는 이 차이가 꽤 크게 체감된다.

그래서 프론트엔드 최적화에서는

• unnecessary fetch 제거
• API 합치기
• 이미지 최적화
• 캐싱

같은 작업이 중요해진다.

체감 성능을 줄이는 방법

재밌는 건 실제 속도보다

"빠르게 느껴지게 만드는 것"

도 굉장히 중요하다는 점이다.

대표적인 게 Optimistic UI다.

예를 들어

• 좋아요
• 채팅
• 장바구니

같은 기능은 서버 응답 전에 먼저 UI를 업데이트한다.

즉

응답 기다리기

가 아니라

일단 보여주기
→ 나중에 검증

방식이다.

실제 네트워크 속도는 그대로여도 체감 Latency는 훨씬 줄어든다.

결국 핵심은

웹 성능은 단순히 React 렌더링 속도만의 문제가 아니다.

실제로는

• 네트워크
• 서버 응답
• 연결 생성
• 파일 다운로드

비용이 더 큰 경우도 많다.

특히 모바일 환경에서는

"몇백 ms 차이"

가 UX에 엄청 큰 영향을 준다.

그래서 프론트엔드 성능 최적화는 결국

• 렌더링 최적화
• 네트워크 최적화
• 캐싱 전략
• 요청 구조 설계

전부 함께 고려해야 하는 문제에 가까웠다.

• 객체 구조(shape)를 일정하게 유지하라
• 동적 프로퍼티 추가를 조심하라
• 객체를 렌더마다 새로 만들지 마라

처음엔 그냥 "최적화 팁"처럼 보이지만, 사실 이건 전부 JavaScript 엔진(V8)의 내부 최적화 방식과 연결되어 있다.

이번 글에서는

• JIT 컴파일
• Hidden Class
• Inline Cache

가 실제로 어떻게 동작하는지, 그리고 왜 React 성능과 연결되는지 정리해보려 한다.

(V8 기준으로 설명)

먼저 큰 흐름

JavaScript는 기본적으로 동적 언어다.

즉 이런 코드가 있을 때

obj.a

엔진은 런타임마다

• a 프로퍼티가 진짜 있는지
• 객체 구조가 뭔지
• 타입이 뭔지

확인해야 할 수도 있다.

원래라면 굉장히 느릴 수 있는 구조다.

그래서 현대 JS 엔진은 내부적으로 엄청난 최적화를 수행한다.

전체 동작 흐름

JavaScript
  ↓
Parser
  ↓
AST 생성
  ↓
Interpreter (Bytecode 실행)
  ↓
Profiler (실행 패턴 수집)
  ↓
JIT Compiler
  ↓
Optimized Machine Code

핵심은:

처음엔 빠르게 실행하고, 자주 쓰이는 코드를 나중에 최적화한다

는 점이다.

1. JIT 컴파일 (Just-In-Time)

왜 필요할까?

예전 JavaScript 엔진은

코드 한 줄 해석 → 실행

방식이었다.

즉 인터프리터 기반.

하지만 이 방식은 반복 실행되는 코드에서 비효율적이었다.

현대 엔진 방식

요즘 엔진은

1. 처음엔 빠르게 인터프리트
2. 실행 패턴 수집
3. 자주 실행되는 코드 발견
4. 최적화된 머신코드 생성

흐름으로 동작한다.

이걸 JIT(Just-In-Time) 컴파일이라고 한다.

예시

function add(a, b) {
  return a + b;
}

처음엔 일반적인 방식으로 실행된다.

하지만 계속

add(1, 2);
add(3, 4);
add(5, 6);

처럼 숫자만 들어온다면 엔진은 판단한다.

"이 함수는 숫자 계산 전용이네?"

그 순간 JIT가 최적화를 시작한다.

최적화되는 부분

원래 JS는 매 호출마다

• 타입 검사
• 연산 방식 결정

같은 작업을 해야 한다.

하지만 숫자만 들어온다고 확신하면

타입 검사 생략

가능해진다.

즉 거의 네이티브 코드 수준으로 빨라진다.

그런데 문제 발생

갑자기

add("a", "b");

가 들어오면?

기존 최적화 가정이 깨진다.

엔진은

Deoptimization (deopt)

을 수행한다.

즉

• 최적화 취소
• 일반 인터프리트 모드 복귀

가 발생한다.

핵심

JavaScript 엔진은

"예측 가능한 코드"

를 굉장히 좋아한다.

즉

• 타입 안정성
• 일관된 호출 패턴

이 중요하다.

2. Hidden Class

이건 V8 최적화의 핵심 중 하나다.

JavaScript 객체의 문제

JS 객체는 동적으로 구조가 바뀔 수 있다.

const user = {};

user.name = "me";

런타임에 프로퍼티가 계속 추가된다.

문제는 CPU는 원래

struct User {
  char* name;
}

같은 고정 구조를 좋아한다는 점이다.

그래서 등장한 Hidden Class

V8은 객체를 내부적으로

"고정 구조처럼"

관리한다.

예를 들어

const user = {
  name: "me",
  age: 20,
};

를 만들면 내부적으로

HiddenClass1
- name → offset 0
- age → offset 1

같은 구조를 생성한다.

왜 빠를까?

user.name

접근 시

offset 0 접근

만 하면 된다.

즉 일반 해시 탐색이 아니라:

거의 C 구조체 접근처럼 동작한다.

문제 상황

const a = { x: 1, y: 2 };

const b = { y: 2, x: 1 };

겉보기엔 같아 보이지만

• 프로퍼티 생성 순서가 다름
• Hidden Class도 다르게 생성됨

즉 엔진 입장에서는 서로 다른 객체 구조다.

React에서 왜 중요할까?

예

const state = {
  name,
  age,
};

객체 구조가 계속 일정하게 유지되면 엔진 최적화가 잘 유지된다.

반대로

const obj = {};

if (condition) {
  obj.name = "me";
}

처럼 구조가 계속 바뀌면 최적화가 깨질 가능성이 높아진다.

즉

객체 shape 안정성

이 성능과 연결된다.

3. Inline Cache (IC)

이건 Hidden Class와 연결되는 최적화다.

문제

user.name

를 매번

• 프로퍼티 탐색
• 위치 검색

하면서 찾으면 느리다.

해결 방식

엔진은 캐싱한다.

예를 들어

"이 객체는 HiddenClass1 이었지?"

를 기억해둔다.

그러면 다음 접근부터는

바로 offset 접근

가능하다.

이걸 Inline Cache(IC)라고 한다.

즉

"이 형태의 객체는 여기 접근하면 된다"

를 캐싱하는 구조다.

동작 흐름

처음 접근

lookup 발생

두 번째부터

cache hit

즉 훨씬 빨라진다.

문제 상황 — Megamorphic

foo(obj1);
foo(obj2);
foo(obj3);

근데 매번 객체 shape가 다르다면?

엔진 입장에서는

"왜 맨날 다른 객체가 들어오지?"

상태가 된다.

이를

Megamorphic

상태라고 부른다.

즉 Inline Cache가 너무 많은 형태를 처리해야 해서 최적화 효율이 떨어진다.

React와 연결되는 부분

예를 들어

<Component style={{ color: "red" }} />

이 코드는 렌더마다

{ color: "red" }

새 객체를 생성한다.

즉

• 새 reference
• 새 allocation
• GC 증가
• shape 최적화 방해 가능성

이 생긴다.

그래서

• useMemo
• useCallback
• 객체 memoization

같은 패턴이 중요해진다.

실제 프론트엔드 예시

좋지 않은 패턴

items.map((item) => ({
  ...item,
  active: true,
}));

렌더마다

• 새 객체 생성
• 새 allocation
• GC 비용 증가

가 발생한다.

물론 무조건 나쁘다는 건 아니지만:

자주 렌더되는 대규모 리스트

에서는 성능에 영향을 줄 수 있다.

전체 흐름 정리

1단계 — 인터프리트

일단 빠르게 실행

2단계 — 패턴 수집

엔진이 관찰한다.

- 숫자만 오네?
- 객체 구조 일정하네?
- 호출 패턴 안정적이네?

3단계 — Hidden Class 생성

객체 구조 최적화

4단계 — Inline Cache 적용

프로퍼티 접근 캐싱

5단계 — JIT 최적화

최적화된 머신코드 생성

6단계 — 예측 실패

타입이나 구조가 바뀌면

deopt 발생

다시 일반 모드로 복귀

결국 핵심은 하나

JavaScript 엔진 최적화는 결국

"예측 가능한 코드"

를 좋아한다.

즉

• 타입 안정성
• 객체 구조 안정성
• 일관된 호출 패턴

이 성능 최적화의 핵심이다.

이걸 이해하면

• 왜 객체 shape 유지가 중요한지
• 왜 dynamic property 추가가 느릴 수 있는지
• 왜 React re-render 최적화가 필요한지
• 왜 useMemo/useCallback을 쓰는지

를 단순 React 레벨이 아니라

"엔진 수준"

에서 이해할 수 있게 된다.

"페이지를 이동했다 돌아오면 왜 점점 느려지지?"

처음엔 렌더링 문제처럼 보이지만 실제 원인은 대부분 cleanup 누락이다.

특히 requestAnimationFrame은 컴포넌트가 사라져도 자동으로 멈추지 않는다.

명시적으로 취소하지 않으면 이전 루프가 계속 살아 있고, GPU 메모리도 계속 쌓인다.

App Router처럼 페이지 전환이 잦은 환경에서는 특히 더 잘 드러난다.

• 이전 페이지의 animation loop가 계속 실행되고
• geometry / material / texture가 GPU 메모리에 남아 있으며
• 결국 탭이 느려지거나 WebGL context limit에 걸리기도 한다

이번 글에서는 Three.js를 React useEffect 안에서 안전하게 사용하는 방법과 정확히 무엇을 cleanup 해야 하는지 정리해보려 한다.

문제 — 멈추지 않는 루프

보통 Three.js를 처음 세팅하면 이렇게 작성한다.

useEffect(() => {
  const renderer = new THREE.WebGLRenderer({ canvas });

  const scene = new THREE.Scene();

  const geometry = new THREE.BoxGeometry();

  const material = new THREE.MeshBasicMaterial({
    color: "blue",
  });

  const mesh = new THREE.Mesh(geometry, material);

  scene.add(mesh);

  const animate = () => {
    requestAnimationFrame(animate);

    mesh.rotation.y += 0.01;

    renderer.render(scene, camera);
  };

  animate();
}, []);

[] 덕분에 마운트 시 한 번만 실행된다.

문제는

언마운트 시 아무것도 정리하지 않는다는 것

이다.

컴포넌트가 사라져도 내부적으로는

animate()
  ↓
requestAnimationFrame(animate)
  ↓
animate()
  ↓
...

루프가 계속 반복된다.

즉 페이지를 이동해도 이전 animation loop가 백그라운드에서 계속 살아 있게 된다.

해결 — cleanup 함수 사용

useEffect는 cleanup 함수를 반환할 수 있다.

useEffect(() => {
  // 초기화

  return () => {
    // cleanup
  };
}, []);

이 함수는

• 컴포넌트 언마운트 시
• 의존성 변경 직전

자동으로 실행된다.

Three.js 리소스 정리는 모두 여기서 수행해야 한다.

requestAnimationFrame 취소

먼저 animation loop를 멈춰야 한다.

let rafId = 0;

const animate = () => {
  rafId = requestAnimationFrame(animate);

  renderer.render(scene, camera);
};

animate();

return () => {
  cancelAnimationFrame(rafId);
};

핵심은

rafId = requestAnimationFrame(animate);

처럼

매 프레임마다 최신 ID를 저장하는 것

이다.

cleanup 시 마지막 예약 ID를 취소하면 다음 프레임부터 루프가 멈춘다.

중요한 문제 — GPU 메모리는 자동 해제되지 않는다

루프를 멈췄다고 끝난 게 아니다.

Three.js의

• geometry
• material
• texture

같은 객체들은 내부적으로 GPU(WebGL)에 업로드된다.

즉 JavaScript 객체가 GC 대상이 되더라도

GPU 메모리는 별도로 dispose 해야 한다.

dispose()

return () => {
  cancelAnimationFrame(rafId);

  geometry.dispose();

  material.dispose();

  texture.dispose();

  renderer.dispose();
};

각각 의미는 다음과 같다.

특히 texture.dispose()는 자주 빠뜨린다.

material.dispose()를 호출해도 texture는 자동 해제되지 않는다.

실제 패턴

보통은 이런 형태로 정리한다.

useEffect(() => {
  const canvas = canvasRef.current;

  if (!canvas) return;

  const renderer = new THREE.WebGLRenderer({
    canvas,
    antialias: true,
  });

  const scene = new THREE.Scene();

  const camera = new THREE.PerspectiveCamera(
    60,
    canvas.clientWidth / canvas.clientHeight,
    0.1,
    100,
  );

  camera.position.z = 3;

  const geometry = new THREE.BoxGeometry(1.5, 1.5, 1.5);

  const material = new THREE.MeshBasicMaterial({
    color: "#2563eb",
    wireframe: true,
  });

  const mesh = new THREE.Mesh(geometry, material);

  scene.add(mesh);

  let rafId = 0;

  const animate = () => {
    rafId = requestAnimationFrame(animate);

    mesh.rotation.y += 0.01;

    renderer.render(scene, camera);
  };

  animate();

  return () => {
    cancelAnimationFrame(rafId);

    geometry.dispose();
    material.dispose();

    renderer.dispose();
  };
}, []);

데모 전환 시 — 의존성 변경 패턴

탭 기반으로 여러 데모를 교체하는 경우에는

useEffect(() => {
  const cleanup = initDemo(activeDemo, canvas);

  return () => {
    cleanup();
  };
}, [activeDemo]);

형태를 자주 사용한다.

흐름은

이전 cleanup 실행
  ↓
raf 취소 + dispose
  ↓
새 데모 초기화

순서로 진행된다.

즉 데모를 빠르게 전환해도 이전 WebGL 리소스가 남지 않는다.

OrbitControls / GUI도 cleanup 필요

Three.js 자체뿐 아니라 부가 라이브러리도 정리해야 한다.

특히 OrbitControls는 이벤트 리스너를 등록하기 때문에 dispose하지 않으면 마우스 이벤트가 계속 살아 있다.

window 이벤트 리스너도 주의

이건 Three.js 외부 문제지만 정말 자주 놓친다.

const onResize = () => {
  // resize 처리
};

window.addEventListener("resize", onResize);

cleanup에서 반드시 제거해야 한다.

return () => {
  window.removeEventListener("resize", onResize);
};

canvas 이벤트도 동일하다.

canvas.addEventListener("mousemove", onMouseMove);

↓

canvas.removeEventListener("mousemove", onMouseMove);

정리하지 않으면

• stale closure
• 중복 이벤트 실행
• 메모리 누수

문제가 발생할 수 있다.

정리

Three.js를 React에서 사용할 때 핵심은 결국 하나다.

초기화한 것은 반드시 cleanup에서 역순으로 정리한다.

• animation loop 중단
• GPU 리소스 dispose
• 이벤트 리스너 제거

이 세 가지만 제대로 관리해도 Next.js 환경에서 Three.js를 훨씬 안정적으로 사용할 수 있다.

"전송 버튼을 눌렀는데 내 메시지가 바로 안 뜬다."

WebSocket 기반이든 HTTP 기반이든, 서버 응답 이후에만 메시지를 추가하면 그 사이 UI가 멈춘 것처럼 보인다.

특히 네트워크가 느릴수록:

• 버튼을 눌렀는데 반응이 없고
• 메시지가 늦게 나타나며
• UX가 답답하게 느껴진다.

이번 글에서는 채팅 메시지 전송에 Optimistic Update를 적용하는 방법과, 서버 메시지와 로컬 메시지를 어떻게 동기화하는지 정리해보려 한다.

기본 구조 — pending 상태 추가

먼저 메시지 타입에 pending 상태를 추가한다.

type LocalMessage = ChatMessage & {
  pending?: boolean;
};

• 서버 메시지 → pending 없음 또는 false
• 아직 서버 확인 전인 메시지 → pending: true

즉:

"아직 서버 검증이 끝나지 않은 임시 메시지"

라는 상태를 표현하는 용도다.

실제로는 이 한 줄의 타입 확장만으로도 Optimistic Update의 기반이 만들어진다.

메시지 전송 — 먼저 렌더링하고 나중에 전송

const sendMessage = useCallback((content: string) => {
  const ws = wsRef.current;

  if (!ws || ws.readyState !== WebSocket.OPEN) return;

  // 1. 먼저 UI에 추가
  const optimistic: LocalMessage = {
    id: `pending_${Date.now()}`,
    content,
    author: currentUser,
    createdAt: new Date().toISOString(),
    pending: true,
  };

  setMessages((prev) => [...prev, optimistic]);

  // 2. 실제 전송은 그 다음
  ws.send(
    JSON.stringify({
      type: "chat:send",
      payload: { content },
    }),
  );
}, []);

핵심은 순서다.

기존 방식은:

전송 → 서버 응답 → 렌더

였다면,

Optimistic Update는:

렌더 → 전송 → 서버 검증

순서로 동작한다.

즉 유저 입장에서는 버튼을 누르는 즉시 내 메시지가 화면에 보인다.

서버 응답 처리 — pending 메시지 교체

이후 서버에서 chat:message 이벤트가 도착하면:

1. 내가 보낸 pending 메시지인지 확인
2. 맞다면 실제 서버 메시지로 교체
3. 아니라면 다른 유저 메시지로 추가

처리한다.

case "chat:message": {
  const incoming = data.payload.message;

  setMessages((prev) => {
    const pendingIdx = prev.findIndex(
      (m) =>
        m.pending &&
        m.content === incoming.content &&
        m.author.id === incoming.author.id,
    );

    // 1. pending 메시지 교체
    if (pendingIdx !== -1) {
      const next = [...prev];
      next[pendingIdx] = incoming;
      return next;
    }

    // 2. 중복 방지
    if (prev.some((m) => m.id === incoming.id)) {
      return prev;
    }

    // 3. 다른 유저 메시지 추가
    return [...prev, incoming];
  });
}

전체 흐름

전송 버튼 클릭
  ↓
pending 메시지 즉시 추가
(id: pending_xxx, pending: true)
  ↓
WebSocket 전송
  ↓
서버에서 chat:message 이벤트 도착
  ↓
pending 메시지 탐색
  ↓
일치하면 → 서버 메시지로 교체
불일치하면 → 새 메시지 추가

핵심 — pending 메시지 매칭 기준

가장 중요한 건:

"서버 메시지와 어떤 기준으로 매칭할 것인가"

다.

현재 구현에서는:

m.pending &&
m.content === incoming.content &&
m.author.id === incoming.author.id

조건으로 찾고 있다.

왜 id로 비교하지 않을까?

pending 메시지의 id는:

pending_123123

같은 임시값이다.

반면 서버 메시지는:

msg_87asd7

처럼 실제 DB 기반 id를 가진다.

즉 서로 값이 다르기 때문에 id 비교로는 매칭할 수 없다.

그래서:

• content
• author.id

조합으로 "같은 메시지"인지 판단한다.

UI에서 pending 상태 표현하기

pending 플래그를 사용하면 전송 중 상태를 자연스럽게 표시할 수 있다.

{messages.map((msg) => (
  <div
    key={msg.id}
    style={{
      opacity: msg.pending ? 0.5 : 1,
    }}
  >
    {msg.content}

    {msg.pending && (
      <span>전송 중...</span>
    )}
  </div>
))}

유저 입장에서는:

1. 메시지가 즉시 나타나고
2. 서버 응답 전까지 흐리게 표시되며
3. 서버 확인 후 정상 상태로 변경

되는 흐름으로 보인다.

주의할 점 — rollback 처리

현재 구조는 사실상:

ws.send(...)

후 응답을 기다리지 않는 fire-and-forget 방식이다.

즉 전송 실패 시 pending 메시지가 계속 남아 있을 수 있다.

실패 처리 방법

예를 들어 연결이 끊겼다면:

setMessages((prev) =>
  prev.filter((m) => !m.pending),
);

처럼 rollback 처리할 수 있다.

또는:

pending: "failed"

같은 상태를 추가해:

• 재전송 버튼
• 실패 표시 UI

를 제공할 수도 있다.

케이스별 처리 전략

정리

채팅에서 Optimistic Update의 핵심은 결국 두 가지다.

먼저 보여주고,

나중에 서버 상태와 맞춘다.

그리고 서버 응답이 도착하면:

임시 메시지를 실제 메시지로 교체한다.

이 흐름만 잘 설계해도 채팅 UX 체감 속도는 꽤 크게 개선된다.

특히 React를 사용하다 보면:

• 왜 useMemo를 쓰는지
• 왜 .map() 남발이 성능에 안 좋은지
• 왜 key가 중요한지
• 왜 Set으로 중복 제거를 하는지

같은 것들이 결국 자료구조/알고리즘 개념과 연결된다.

1. 왜 useMemo가 필요한가

핵심은:

같은 계산을 매 렌더마다 다시 하지 않기 위해

자료구조/알고리즘 관점에서는:

• 연산 비용 감소
• 시간복잡도 최소화
• 캐싱(Cache)

개념에 가깝다.

예를 들어:

const sorted = users.sort(...)

이 코드가 렌더마다 실행되면:

렌더 횟수 × 정렬 비용

이 계속 발생하게 된다.

정렬은 일반적으로:

O(n log n)

복잡도를 가지기 때문에 데이터가 많아질수록 부담이 커진다.

useMemo는 결국 캐싱

useMemo는 내부적으로 보면:

{
  deps: [...],
  cachedValue: result
}

처럼 이전 계산 결과를 저장해두는 개념에 가깝다.

예를 들면:

const sorted = useMemo(() => {
  return users.sort(...)
}, [users])

이렇게 작성하면:

• users가 변경되지 않는 동안
• 이전 계산 결과를 재사용

하게 된다.

즉:

불필요한 O(n log n) 연산을 줄이는 것

이 핵심이다.

2. 왜 .map() 남발하면 느릴까

핵심은:

배열 순회는 공짜가 아니다

.map()은 기본적으로:

O(n)

복잡도를 가진다.

예를 들어:

users.map(...)
posts.map(...)
comments.map(...)

이런 코드가 렌더마다 반복되면:

O(n) + O(n) + O(n)

비용이 계속 발생한다.

더 위험한 건 중첩 반복문

예:

users.map(user => {
  posts.map(post => ...)
})

이 경우는:

O(n²)

까지 증가할 수 있다.

React에서 특히 문제가 되는 이유는:

• state 변경
• props 변경
• context 변경

등으로 렌더링이 자주 발생하기 때문이다.

즉 .map()이 렌더마다 계속 반복 실행된다.

실무에서 사용하는 해결 방법

1. Memoization

const items = useMemo(() => {
  return data.map(...)
}, [data])

불필요한 반복 계산을 줄인다.

2. Virtualization

예:

• FlashList
• react-window

화면에 보이는 아이템만 렌더링해 렌더 비용을 줄인다.

3. Normalization

배열 대신 객체나 Map 형태로 관리한다.

예:

usersById[user.id]

이런 방식은 탐색 비용을 줄일 수 있다.

3. 왜 key가 중요한가

이건 React의 Diffing 알고리즘과 연결된다.

React는 이전 배열과 새 배열을 비교할 때:

"누가 누구인지"

판별해야 한다.

예:

[
  { id: 1 },
  { id: 2 },
  { id: 3 }
]

React는 key 기반으로 비교한다.

key={item.id}

그런데 index를 쓰면?

예를 들어:

A B C

상태에서 앞에 D가 추가되면:

D A B C

가 된다.

하지만 key={index}를 사용하면 React는:

0 = A → D로 착각
1 = B → A로 착각
2 = C → B로 착각

하게 된다.

그 결과:

• DOM 재사용 꼬임
• state 꼬임
• 불필요한 re-render 증가

같은 문제가 발생할 수 있다.

자료구조 관점으로 보면 결국:

고유 식별자(primary key)

문제에 가깝다.

DB에서 id가 중요한 이유와 비슷하다.

4. 왜 Set으로 중복 제거를 할까

배열에서 중복 검사를 할 때 보통:

arr.includes(x)

를 사용한다.

하지만 includes는:

O(n)

복잡도를 가진다.

예를 들어:

const result = []

for (const item of items) {
  if (!result.includes(item)) {
    result.push(item)
  }
}

이 방식은 최악의 경우:

O(n²)

까지 증가할 수 있다.

Set은 해시 기반

반면 Set은 해시 기반 자료구조라 탐색 비용이 매우 낮다.

const set = new Set(items)

검색은 평균적으로:

O(1)

에 가깝다.

그래서 실무에서는:

const unique = [...new Set(items)]

패턴을 굉장히 자주 사용한다.

예를 들어:

onlineUsers = [...new Set(users)]

처럼 websocket 중복 유저 제거에도 많이 사용된다.

결국 React 성능 최적화도 대부분 자료구조와 알고리즘 개념 위에서 동작한다.

Next.js App Router 환경에서 Emotion을 사용하다 보면 아래와 같은 오류를 종종 보게 됩니다.

Warning: Prop `className` did not match

또는:

• Hydration mismatch
• 스타일 깜빡임(FOUC)
• 스타일 우선순위 꼬임
• 서버/클라이언트 스타일 불일치

이번 글에서는 왜 이런 문제가 발생하는지 간단하게 정리해보겠습니다.

App Router는 기본적으로 Server Component 기반

Next.js App Router는 기존 Pages Router와 달리 기본적으로 Server Component 기반 구조입니다.

즉 컴포넌트가:

1. 서버에서 먼저 렌더링되고
2. HTML이 전달된 뒤
3. 클라이언트에서 hydration 되는 방식입니다.

반면 Emotion은:

• 런타임에서 스타일 생성
• 동적으로 className 생성
• 스타일 삽입 순서(insertion order) 관리

같은 특징을 가지고 있습니다.

즉 Emotion은 기본적으로 클라이언트 환경에서 동작하는 CSS-in-JS 방식에 더 가깝습니다.

여기서 App Router와 충돌이 발생할 수 있습니다.

가장 많이 발생하는 문제: className 불일치

Emotion은 렌더링 시점마다 className을 생성합니다.

예를 들면:

css-1abcde
css-92kda

같은 형태의 className이 만들어집니다.

그런데 App Router 환경에서는:

1. 서버 렌더링
2. 클라이언트 hydration
3. 다시 렌더링

과정을 거치면서 스타일 생성 순서가 달라질 수 있습니다.

그 결과:

Warning: Prop `className` did not match

같은 hydration 오류가 발생하게 됩니다.

왜 App Router에서 더 자주 발생할까?

React 18 + App Router는 아래 기능들을 적극적으로 사용합니다.

• Streaming SSR
• Suspense
• Concurrent Rendering

이 환경에서는 컴포넌트 렌더링 순서가 항상 동일하지 않을 수 있습니다.

하지만 Emotion은:

• 어떤 컴포넌트가 먼저 렌더됐는지
• 어떤 스타일이 먼저 삽입됐는지

에 영향을 많이 받습니다.

즉:

렌더링 순서가 바뀌는 환경에서 런타임으로 스타일을 생성하다 보니 문제가 발생하는 것

에 가깝습니다.

실제로 나타나는 현상들

1. Hydration mismatch

Warning: Prop `className` did not match

서버와 클라이언트의 className이 달라지는 문제입니다.

2. 스타일 깜빡임 (FOUC)

초기 렌더 시 스타일이 적용되지 않았다가 뒤늦게 적용되는 현상입니다.

3. 스타일 우선순위 꼬임

Emotion의 insertion order가 달라지면서 예상과 다른 스타일이 적용될 수 있습니다.

4. 특정 상황에서 스타일이 사라지는 문제

재현 조건이 일정하지 않은 경우가 많아 디버깅도 쉽지 않습니다.

styled-components도 비슷한데 왜 Emotion 이야기가 더 많을까?

Emotion은 특히:

• 런타임 의존성
• cache 관리
• insertion order

영향을 크게 받습니다.

그래서 App Router 환경에서는 설정이 조금만 어긋나도 문제가 쉽게 발생합니다.

특히 아래 설정이 중요합니다.

CacheProvider
useServerInsertedHTML

이 설정 없이 사용하면 스타일 충돌 가능성이 높아집니다.

해결 방법

보통은 Emotion Registry를 직접 구성해서 사용합니다.

예를 들면:

'use client'

import { CacheProvider } from '@emotion/react'
import createCache from '@emotion/cache'

그리고 Next.js의:

useServerInsertedHTML()

를 사용해 서버 렌더링 시 style 태그를 직접 삽입합니다.

핵심은:

서버와 클라이언트의 스타일 생성 순서를 최대한 동일하게 맞추는 것

입니다.

그래서 요즘은 어떤 방식이 많이 쓰일까?

최근 App Router 환경에서는 아래 스타일링 방식 선호도가 높아지고 있습니다.

• Tailwind CSS
• CSS Modules
• Panda CSS
• Vanilla Extract

이유는:

• hydration 문제 감소
• 서버 컴포넌트 친화적
• 런타임 비용 감소
• 번들 크기 감소

같은 장점 때문입니다.

마무리

Emotion 자체가 문제 있는 라이브러리는 아닙니다.

다만 Next.js App Router + React 18 환경에서는:

• Streaming SSR
• Concurrent Rendering
• Server Components

구조와 런타임 스타일 생성 방식이 충돌하기 쉬운 편입니다.

그래서 최근에는 빌드 타임 기반 스타일링 방식도 많이 사용되는 추세입니다.

React Native에서는 성능 이슈가 비교적 쉽게 발생하는 만큼 리스트 렌더링에는 FlashList를 사용하며 최대한 최적화를 고려하고 있다.

이번 글에서는 FlashList + Sticky Header를 구현하면서 특히 애를 먹었던 부분들과 그 과정에서 정리한 포인트들을 공유해보려고 한다.

첫 번째 시도

FlashList에서 제공하는 stickyHeaderIndices 옵션을 활용해 Sticky Header를 구현해보았다.

하지만 예상과는 다른 문제가 발생했다.

문제점

stickyHeaderIndices는 renderItem으로 렌더링되는 항목에만 적용되며, ListHeaderComponent에는 적용할 수 없었다.

그 결과 리스트의 첫 번째 상품 아이템이 고정되는 현상이 발생했고, 의도했던 Sticky Header와는 전혀 다른 어색한 UI가 만들어졌다.

두 번째 시도

그래서 다음으로는:

ListHeaderComponent를 사용하지 않고 Header 자체를 renderItem 안으로 넣어보자

라는 방향으로 구현을 변경했다.

이를 위해 리스트 데이터에 타입을 부여해 각 아이템 역할을 구분하도록 구성했다.

• type: 'header' → Sticky Header 영역
• type: 'item' → 일반 상품 아이템

이렇게 하면 Header 역시 리스트 아이템처럼 취급되기 때문에 stickyHeaderIndices를 적용할 수 있을 것이라 생각했다.

하지만 이 방식 역시 FlashList의 구조와 완전히 잘 맞는 방식은 아니었다.

FlashList 입장에서는 Header 또한 일반 아이템과 동일하게 처리되기 때문에:

• 재사용 대상이 되고
• 스크롤 상황에 따라 unmount / mount가 발생할 수 있으며
• Sticky 상태에서 불필요한 re-render가 발생할 가능성이 있었다.

결과적으로 FlashList의 가상화 장점을 일부 희생하는 구조에 가까웠다.

또한 성능 관점에서도 아쉬움이 있었다.

FlashList는 기본적으로 아이템 가상화에 최적화된 리스트인데, stickyHeaderIndices는 내부적으로 레이아웃 계산과 위치 보정 과정을 수행하기 때문에 스크롤 중 추가 비용이 발생할 수 있었다.

세 번째 시도

최종 구현 방식

결국 FlashList에서 제공하는 스크롤 이벤트를 활용해 현재 스크롤 위치를 직접 추적하는 방식으로 구현했다.

스크롤 중 전달받는 현재 Y축 값을 기준으로 Header의 위치를 비교하고, 특정 시점부터 Header를 show / hide 하도록 구성했다.

실제 구현에서는 Header의 opacity 값을 조정해 스크롤 위치에 따라 자연스럽게 나타나고 사라지는 형태로 처리했다.

이를 통해 Sticky Header를 실제로 고정시키지 않더라도, 사용자 입장에서는 자연스러운 Sticky UI처럼 느껴지도록 구현할 수 있었다.

무엇보다 레이아웃 재계산을 최소화하면서 JS → UI 업데이트 비용도 줄일 수 있었고, 결과적으로 성능과 UX 모두 만족할 수 있는 방향으로 마무리할 수 있었다.

• 캐싱은 자주 사용되는 데이터를 한 번 받아온 후에 그 데이터를 임시 저장소에 저장하여 동일한 데이터를 빠르게 불러와서 사용하는 기법을 말한다.
• 메모리 계층 구조에서 캐시는 디스크나 메인 메모리보다 더 빠르게 데이터를 불러와 사용해야 할 때 쓰인다.

캐싱의 종류?

• 캐싱에는 여러 종류가 존재한다.

1) 브라우저 캐시

• 변화가 적은 데이터라면 캐싱을 적용해 볼 수 있다. HTML, CSS, JavaScript, 이미지 등 웹 자원을 로컬 디스크에 저장해둔다. 이는 로컬 저장소에 캐시되기 때문에 단일 사용자를 대상으로 하며, 해당 사용자의 정보만을 저장한다. ex) Etag와 Cache-Control은 브라우저 캐시와 관련된 HTTP 헤더로, 웹 브라우저가 서버에서 자원을 어떻게 캐시할지를 결정하는 데 사용된다.

• HTTP 헤더의 ETag는 특정 버전의 리소스를 식별한다. 클라이언트는 데이터를 최초로 받은 이후 동일한 리소스를 요청할 때, 이전에 받은 Etag 값을 If-None-Match 헤더에 포함하여 요청을 보낸다.

• If-Modified-Since* 캐시된 리소스의 Last-Modified 값 이후에 서버 리소스가 수정되었는지 확인합니다. 서버는 이 Etag와 리소스의 현재 Etag를 비교하여, 리소스가 변경되지 않았다면 304 Not Modified 상태 코드와 함께 빈 응답을 보내고, 리소스가 변경되었으면 새로운 리소스를 반환한다.

• HTTP 헤더의 Cache-Control은 클라이언트(브라우저)와 서버 간의 캐시 동작을 제어한다.

  no-cache: 서버에서 데이터를 확인해야 하며, 이전에 캐시된 데이터를 사용하지 않도록 합니다.

• no-store*: 데이터가 캐시되지 않도록 합니다.

• max-age*: 리소스가 캐시된 후 최대 몇 초 동안 유효한지 지정합니다.

• public*: 리소스가 모든 캐시에 저장될 수 있음을 의미합니다.

• private*: 리소스는 사용자별로 개인적인 캐시에 저장됩니다.

• must-revalidate*: 캐시된 리소스가 만료되었을 경우, 서버에서 리소스를 다시 확인해야 함을 의미합니다.

• s-maxage*: 중간 서버에서만 적용되는 max-age 값을 설정하기 위해 사용합니다. 예를 들어, Cache-Control 값을 s-maxage=31536000, max-age=0 과 같이 설정하면 CDN에서는 1년동안 캐시되지만 브라우저에서는 매번 재검증 요청을 보내도록 설정할 수 있습니다.

no-cache 속성은 캐시를 먼저 사용하기 이전에 서버에 해당 캐시를 사용해도 되는지에 관해 검증 요청을 보내는 속성이다. 
no-cache 속성이 없는 경우 캐시가 있다면 바로 캐시를 쓰지만(max-age=0), no-cache 속성이 있는 경우 캐시를 바로 쓰지 않고 서버에 이 캐시를 사용해도 되는지에 대한 허락을 맡기 때문에 요청에 대한 시간이 소요될 수 있다.

no-store는 개인정보 등 private 한 데이터가 있는 경우 이 속성을 사용할 수 있다. (캐시를 만들어서 저장조차 하지 않는다.)
private cache에 반대되는 shared cache 가 존재한다.

Cache-Control max-age 값 대신 Expires 헤더로 캐시 만료 시간을 정확히 지정할 수도 있습니다.

• Cache-Control은 리소스를 어떻게 캐시할지에 대한 지침을 제공하며, Etag는 리소스의 변경 여부를 확인하는 데 사용된다.

2) 프록시 캐시

• 공유 캐시(shared cache)로 한 명 이상의 사용자에 의해 재사용되는 응답을 저장한다. no-cache는 최신화가 필요한 stale 데이터를 사용하고 싶을 때 사용하고, 이러한 데이터를 사용해서 문제가 발생한다면 504 에러를 반환하는 must-revalidate를 사용하면 된다.

3) CDN 캐시

• CDN은 성능 향상을 위해 클라이언트의 요청이 같은 서버로 가는 것을 막는다. CDN 캐시는 웹 자원의 정적 파일을 캐시하여 빠른 응답을 제공한다.

  일반적으로 캐시를 없애기 위해서 CDN Invalidation을 수행한다고 한다. CDN에 저장되어 있는 캐시를 삭제한다는 뜻이다. 브라우저의 캐시는 다른 곳에 위치하기 때문에 CDN 캐시를 삭제한다고 해서 브라우저 캐시가 삭제되지는 않는다.

데이터 페칭 라이브러리에서는 캐싱을 어떻게 처리할까?

React Query

• 서버에서 받은 데이터를 클라이언트의 로컬 메모리나 로컬 스토리지, 또는 IndexedDB에 저장하여 다음에 동일한 요청이 있을 경우 네트워크 요청을 생략하고 캐시된 데이터를 반환할 수 있습니다.
• staleTime을 설정하여 데이터가 "stale" 상태(즉, 오래된 상태)가 되기까지의 시간을 지정할 수 있고, cacheTime을 통해 캐시된 데이터를 얼마나 오래 보존할지 설정할 수 있습니다.

staleTime: 데이터를 얼마나 오래 캐시할지 지정합니다. 이 시간이 지나면 데이터는 "stale" 상태가 됩니다. cacheTime: 캐시된 데이터를 언제까지 저장할지 지정합니다. 이 시간이 지나면 캐시된 데이터는 삭제됩니다. refetchOnWindowFocus: 브라우저 창이 포커스를 받을 때 데이터를 자동으로 재페칭할지 여부를 설정합니다.

ref) https://yozm.wishket.com/magazine/detail/2341/ ref) https://toss.tech/article/smart-web-service-cache

* useImperativeHandle

• 부모 컴포넌트가 자식 컴포넌트의 특정 기능에 접근하도록 허용. 일반적으로 ref와 함께 사용되며, forwardRef가 필요함. 부모가 자식 컴포넌트의 특정 기능(예: focus, scroll)을 직접 호출.

[사용 예시]

const FancyInput = React.forwardRef((props, ref) => {
  const inputRef = React.useRef();
  React.useImperativeHandle(ref, () => ({
    focus: () => {
      inputRef.current.focus();
    },
  }));
  return <input ref={inputRef} />;
});

function Parent() {
  const ref = React.useRef();

  return (
    <div>
      <FancyInput ref={ref} />
      <button onClick={() => ref.current.focus()}>포커스</button>
    </div>
  );
}

* useLayoutEffect

• DOM이 렌더링된 직후, 브라우저가 그리기 전에 동기적으로 실행. DOM 변경 후 바로 실행이 필요한 경우에 적합하다. useEffect와 비슷하지만 실행 시점이 다르다.

[사용 시기]

DOM 요소의 위치, 크기 조정이 필요할 때. 애니메이션 효과나 스크롤 위치 설정.

[차이점]

useEffect: 렌더링 이후 실행 (비동기). useLayoutEffect: 렌더링 직전에 실행 (동기).

function LayoutEffectExample() {
  const divRef = React.useRef();

  React.useLayoutEffect(() => {
    console.log(divRef.current.offsetHeight);
  }, []);

  return <div ref={divRef}>레이아웃 확인</div>;
}

* useTransition

• 상태 업데이트를 긴급/비긴급으로 나누어 처리한다. 사용자 인터페이스가 부드럽게 유지. React 18의 Concurrent Mode에서 유용.

  function App() {
  const [isPending, startTransition] = React.useTransition();
  const [count, setCount] = React.useState(0);
  
  const handleClick = () => {
    startTransition(() => {
      setCount((c) => c + 1);
    });
  };
  
  return (
    <div>
      <button onClick={handleClick}>클릭</button>
      {isPending ? <p>로딩 중...</p> : <p>결과: {count}</p>}
    </div>
  );
  }
  

#### * useId
- 고유한 ID를 생성해서 HTML에 사용한다. 나는 폼에 적용했었다. 컴포넌트간 충돌이 없어 유용하다.

function Component() { const id = React.useId();

return ( 입력창 ); }

#### * useDefferedValue
- 부하가 큰 연산의 업데이트를 지연시켜 UI 성능 개선. UI가 느려지지 않도록 함.

function App({ value }) { const deferredValue = React.useDeferredValue(value);

return

#### * useActionState
- 비동기 액션의 상태를 더 명확하고 직관적으로 관리할 수 있다. (기존 useFormState 훅을 개선했다.)

"use client";

function App() { const [state, submitAction, isPending] = useActionState(customAction, initialState); // initialState like {error: null}

return (
    <form action={submitAction}>
    <button disabled={isPending}></button>
    {state.error && <span>error</span>}
    </form>
)

}

``` 리액트 훅이므로 클라이언트 컴포넌트에서 사용해야 한다. pending 상태와 useState, onSubmit 함수를 축약해 개인적으로 가독성과 데이터 응집도가 높아졌다고 생각한다.

“form, input, button 요소에 action 및 formAction props로 Server Action을 전달하면 JavaScript가 비활성화되었거나 코드가 로드되기 전에도 사용자가 폼을 제출하고, 오류를 표시할 수 있게 되었다.”

JavaScript가 비활성화되거나 코드가 로드되기 전에 사용자가 form을 제출할 수 있으면 뭐가 좋은걸까?

사용자의 인터넷 연결이 느리거나, 장치 성능이 낮거나, JavaScript가 비활성화된 환경에서도 폼 제출 기능이 정상적으로 작동하도록 보장해줄 수 있다. 이로써 웹사이트의 접근성을 높여 모든 사용자에게 일관된 경험을 제공할 수 있게 되고, 결과적으로 사용자가 겪을 수 있는 잠재적인 문제를 줄이고 더 많은 사용자가 서비스를 이용할 수 있게 하는 것이다.

• 리액트 상태 관리 라이브러리들 (feat. 장단점)
• 상태 관리에 Redux를 선택하게 된 계기
• Redux 셋팅하기
• Next.js에 Redux를 적용하며 마주하게 된 사사로운 오류사항들
• 번외

🛠️ 리액트 상태 관리 라이브러리들 (feat. 장단점)

리액트 상태 관리 라이브러리에는 다양한 종류가 있다. 익숙한 것들만 간단히 나열해보자면 Recoil, Redux, Jotai, Mobx, zustand 등등 ...

우리가 사용할 기술을 선정할 때 고려해야 할 것이 몇가지 있다. 각 기술의 특성과 장단점을 무조건 파악을 해야 한다는 거다.

제일 주의해야하는 건 무작정 '남들이 다 사용하니까' 선택하는 일이다.

그렇게 되면 내가 만들 프로젝트와 그 기술의 성격이 맞지 않을 수가 있고, 몸집이 커진 프로젝트를 다시 싹 다 갈아 엎어야 하는 대참사가 발생할 수도 있다.

상태관리에 Redux를 선택하게 된 계기

위와 같은 다양한 라이브러리 중 나는 zustand 또는 Redux 사이에서 고민하게 되었다.

나의 상황을 적어보자면

1) 온전히 혼자 작업을 해야 한다. 2) 최대한 빠르게 작업을 마무리 하면 좋다. 3) 두 라이브러리 모두 사용해 본 경험이 없거나 적다.

위 같은 상황에서 빠르고 쉽게 작업할 수 있는 zustand 를 선택하는게 더 효율적이었겠지만, 나는 redux를 선택했다!

왜냐면 redux는 대규모 프로젝트에 더 적합하기 때문이다. (나는 런칭해서 운영까지, 즉 유지보수까지 해보고 싶었기 때문이다.) 그리고 '쉬운걸 먼저 적용해버리면 나중에 더 큰 어려움을 마주하게 되지 않을까? 그러니까 어려운 것부터 먼저 깊게 다뤄보자!' 싶은 마음이었다.

따라서 redux를 next.js(App Route) + typescript 에 적용하게 되는데 ,,,

Redux 셋팅하기

자 차근차근 적용해보도록 하자.

우선, redux와 관련 패키지를 설치해야 한다.

Redux 설치

npm install @reduxjs/toolkit react-redux

Redux 설정

일단, store를 만든다. 이때 store는 redux의 모든 상태들을 관리하게 된다.

// store.ts

import { configureStore } from "@reduxjs/toolkit";
import rootReducer from "./rootReducer";

export const makeStore = () => {
  return configureStore({
    reducer: rootReducer,
  });
};


export type AppStore = ReturnType<typeof makeStore>;
export type RootState = ReturnType<AppStore["getState"]>;
export type AppDispatch = AppStore["dispatch"];

slice 생성

slice는 액션 및 리듀서를 포함한다.

import { createSlice } from "@reduxjs/toolkit";

const userAuthSlices = createSlice({
  name: "userAuth", // slice 식별
  initialState: { name: "subeen" },
  reducers: {
    setUserAuth: (state, action) => {
      state.name = action.payload;
    },
  },
});

export const { setUserAuth } = userAuthSlices.actions;

export default userAuthSlices.reducer;

이때, name에 따라 slice가 식별되니 직관적이게 작명하도록 유의한다.

Provider 설정

Provider를 설정해 모든 페이지에서 Redux 상태에 접근할 수 있도록 한다.

Next.js App Router 구조에서는 app/layout.tsx 파일에서 설정한다.

"use client";

import React from "react";
import { Provider } from "react-redux";
import { makeStore } from "./lib/store";

const store = makeStore(); // makeStore 함수를 호출하여 스토어 객체를 생성합니다.

const ClientLayout: React.FC<{ children: React.ReactNode }> = ({
  children,
}) => {
  return (
    <Provider store={store}>
      {/* store 객체를 Provider에 전달합니다. */}
      <main>{children}</main>
    </Provider>
  );
};

export default ClientLayout;

import Footer from "@/components/Footer";
import Header from "@/components/Header";
import type { Metadata, Viewport } from "next";
import { Inter } from "next/font/google";
import ClientLayout from "./ClientLayout";
import "./globals.css";

const inter = Inter({ subsets: ["latin"] });

export const metadata: Metadata = {
  title: "Create Next App",
  description: "Generated by create next app",
};

export const viewport: Viewport = {
  initialScale: 1,
  width: "device-width",
};

const RootLayout = ({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) => {
  return (
    <html lang="en">
      <body className={inter.className}>
        <ClientLayout>
          <Header />
          {children}
        </ClientLayout>
        <Footer />
      </body>
    </html>
  );
};

export default RootLayout;

위의 코드를 보면 바로 Provider로 감싸는 대신 ClientLayout으로 감쌌는데, 이는 Redux가 클라이언트 컴포넌트에서만 작동하는 훅을 사용해야하기 때문이다. (useSelector, useDispatch)

여기서 잠깐

Redux는 클라이언트 사이드 상태 관리 (브라우저 환경에서 동작하는 상태 관리 도구) 라이브러리이기 때문에 "use client" 지시어가 필요하다.

("use client" 지시어는 초기 페이지 로딩 속도나 사용자 경험에 부정적인 영향을 미칠 가능성이 있다. 번들 크기가 커져 페이지 로드 시간이 증가하는 단점도 있다.)

보통 그래서 next-redux-wrapper 라이브러리를 사용한다.

Redux 사용 예시

컴포넌트에서 redux 상태와 액션 사용 방법이다. useSelector와 useDispatch 훅을 이용하여 상태를 조회하고, 액션을 디스패치 할 수 있다.

// app/login/page.tsx
'use client';

import { useState } from 'react';
import { useDispatch } from 'react-redux';
import { login } from '../../features/userSlice';
import { useRouter } from 'next/navigation';

const LoginPage = () => {
  const [email, setEmail] = useState('');
  const [password, setPassword] = useState('');
  const dispatch = useDispatch();
  const router = useRouter();

  const handleLogin = async (e: React.FormEvent) => {
    e.preventDefault();

    // 실제로는 백엔드에서 로그인 API 호출
    const userData = {
      id: '123',
      name: 'John Doe',
      email: email,
    };

    // 로그인 성공 시 Redux에 사용자 정보를 저장
    dispatch(login(userData));

    // 대시보드로 리디렉션
    router.push('/dashboard');
  };

  return (
    <form onSubmit={handleLogin}>
      <div>
        <label>Email</label>
        <input
          type="email"
          value={email}
          onChange={(e) => setEmail(e.target.value)}
          required
        />
      </div>
      <div>
        <label>Password</label>
        <input
          type="password"
          value={password}
          onChange={(e) => setPassword(e.target.value)}
          required
        />
      </div>
      <button type="submit">Login</button>
    </form>
  );
};

export default LoginPage;

Next.js에 Redux를 적용하며 마주하게 된 사사로운 오류사항들

가장 많이 언급되는 불편함: 새로고침 하면 날라가요 ,,,

이를 해결하기 위한 몇가지 방법이 있다.

아. 일단 왜 이런 문제가 발생하냐면, 브라우저를 새로고침 하면 페이지 전체를 다시 로드하기 때문에 Redux 상태가 초기화된다.

첫번째 해결방법) redux-persist 라이브러리 사용

간략한 사용법 설명

npm install redux-persist

2. 스토어 설정

   // lib/store.ts
   import { configureStore } from '@reduxjs/toolkit';
   import { persistStore, persistReducer } from 'redux-persist';
   import storage from 'redux-persist/lib/storage'; // 기본적으로 localStorage 사용
   import rootReducer from './rootReducer'; // 모든 리듀서를 합친 rootReducer
   

const persistConfig = { key: 'root', storage, // localStorage에 저장 };

const persistedReducer = persistReducer(persistConfig, rootReducer);

export const store = configureStore({ reducer: persistedReducer, });

export const persistor = persistStore(store);

<br>

3. Provider 설정
<br>

// app/layout.tsx 'use client';

import './globals.css'; import { Provider } from 'react-redux'; import { store, persistor } from '../lib/store'; import { PersistGate } from 'redux-persist/integration/react'; import Header from '../components/Header';

export default function RootLayout({ children }: { children: React.ReactNode }) { return (

<br>


redux-persist의 PersistGate를 사용하여, 스토어가 복원되기 전까지 앱을 지연시킬 수 있다.

<br>



만약 세션 중에만 상태를 유지하고 싶다면 redux-persist/lib/storage/session을 사용할 수 있다.

<br>


__단점__
- 스토리지의 크기가 제한적이고, 복잡한 상태 관리에는 다소 비효율적일 수 있습니다.
상태가 커질수록 브라우저 로딩 시간이 길어질 수 있음.








<br><br>

**두번째 해결방법) localStorage나 sessionStorage 직접 사용**
<br>


1. store가 업데이트 될 때마다 localStorage에 상태 저장
<br>

<br>


__장점__
- redux-persist보다 가볍고, 직접 제어 가능.
- 상태가 단순한 경우 빠르게 적용 가능.
<br>
__단점__
- 수동으로 상태 직렬화/역직렬화를 관리해야 하므로 코드 복잡도가 약간 증가.
- 상태가 클 경우 저장 성능에 영향을 줄 수 있음.






<br>
<br>


**세번째 해결방법) 쿠키 사용**

<br>

쿠키를 사용하여 상태를 저장할 수 있지만, 쿠키는 브라우저가 서버에 전송하는 용도로 주로 사용되므로 큰 데이터를 저장하는 데는 부적합하다. 그러나 인증 정보나 작은 상태값을 저장하는 데에는 적합.

<br>

<br>



__장점__
- 인증 정보나 작은 상태 저장에 적합.
- 서버 사이드 렌더링(SSR)과 쉽게 연동 가능.
<br>
__단점__
- 쿠키는 용량 제한이 있으므로 큰 데이터를 저장할 수 없음.
- 보안 이슈가 있을 수 있으며, 민감한 정보는 적절히 암호화 필요.





<br><br>





**네번째 해결방법) 서버 사이드에서 상태 저장**

<br>

Next.js의 API Routes를 활용하여 서버에 상태를 저장하고, 필요할 때 API를 통해 불러오는 방법.


<br>

<br>

새로고침 시 상태가 서버로부터 복원될 수 있도록 useEffect로 API를 호출하여 상태를 불러오고, 저장할 때는 API로 상태를 보낸다. 

<br>


__장점__
- 큰 데이터를 저장하거나, 보안이 필요한 상태 관리에 적합.
- 서버에서 관리되므로 클라이언트 측의 저장 용량 한계를 걱정할 필요 없음.
<br>
__단점__
- 상태 저장 및 불러오는 로직이 복잡해질 수 있음.
- 상태 저장/복원 시 네트워크 지연이 발생할 수 있음.


<br>



<br>

**나는 위 방법들 중에 localStorage 직접 설정을 택했다.**

<br>

redux-persist 는 나중에 사용해보도록 하자 ~

<br><br>




#### localStorage에 직접 설정하기
<br>

<br>

이런식으로 작성했더니 타입 오류가 났다.

<br>


makeStore 함수에 직접적으로 subscribe 메서드를 호출하려고 했기 때문이다. 

makeStore 함수는 store를 반환하는 함수이지 store 자체가 아니다.

(makeStore 함수가 호출된 후에 반환된 store 인스턴스를 사용해야 함)



<br>




코드를 수정해준 후, 디버깅을 해보았는데 store를 참조하고 있지 않았다.

(그래서 자꾸 데이터가 보존되지 않고 날아감)


<br>


각 store는 name에 따라 식별되고 있는데, localStorage에서 가져온 이 데이터가 어느 store에 대한 데이터인지 매칭이 안되고 있었다. 



<br>

따라서 아래와 같이 수정해주었다. 

const parsedState = JSON.parse(serializedState);

// 로컬 스토리지의 상태를 rootReducer의 구조에 맞게 변환
return {
  userAuth: parsedState, // userAuth로 감싸기
};

<br><br>


이상으로 Redux 적용기 1탄을 마무리해보도록 하겠다. 




<br><br>


~~velog 예쁘고 가독성 있게 작성하는거 왜케 어려워 ...~~