JJuuuunn

[DataBase] 트랜잭션 이란?

JJuuuunn — Tue, 2 Dec 2025 20:00:29 +0900

1. 트랜잭션이란 무엇인가요?

트랜잭션(Transaction)이란 데이터베이스의 상태를 변환시키는 하나의 논리적인 작업 단위를 의미합니다. 여러 개의 SQL 명령어(쿼리)가 하나의 묶음처럼 처리되어, 이 묶음 속의 작업들이 모두 성공하거나 (Commit), 모두 실패하여 원래 상태로 되돌아가야 (Rollback) 하는 특성을 가집니다.

가장 대표적인 예는 은행 계좌 이체입니다. A 계좌에서 돈을 인출하는 작업과 B 계좌로 돈을 입금하는 작업은 단 하나의 논리적 작업(이체)이며, 둘 중 하나라도 실패하면 데이터의 불일치(돈이 사라지거나 생성됨)가 발생하므로 전체 작업을 취소해야 합니다. 트랜잭션은 이러한 데이터의 일관성을 보장하는 핵심 메커니즘입니다.

2. 트랜잭션의 핵심: ACID 속성

모든 트랜잭션은 데이터의 무결성과 일관성을 보장하기 위해 반드시 ACID라는 네 가지 속성을 만족해야 합니다.

속성	원어	설명
원자성	Atomicity	트랜잭션 내의 모든 작업은 전부 성공하거나 전부 실패하여 취소되어야 합니다. (All or Nothing)
일관성	Consistency	트랜잭션이 성공적으로 완료되면 데이터베이스는 언제나 일관된 상태를 유지해야 합니다. (데이터 제약 조건 준수)
격리성	Isolation	동시에 실행되는 여러 트랜잭션은 서로에게 영향을 미치지 않고 독립적으로 실행되어야 합니다.
영속성	Durability	트랜잭션이 성공적으로 완료(Commit)되면, 그 결과는 시스템 오류에도 불구하고 영구적으로 보존되어야 합니다.

3. 트랜잭션 격리 레벨 상세 분석

**격리성(Isolation)**은 동시성 제어의 핵심이며, 데이터베이스는 여러 트랜잭션이 동시에 접근할 때 발생하는 충돌(Concurrency Problem)을 방지하기 위해 네 가지 **격리 레벨(Isolation Level)**을 제공합니다. 격리 수준이 높을수록 데이터 일관성은 높아지지만, 동시 처리 성능은 낮아집니다.

3-1. 동시성 문제 3가지 (격리 레벨이 해결해야 하는 문제)

문제 유형	설명
Dirty Read	커밋되지 않은(롤백될 가능성이 있는) 데이터를 다른 트랜잭션이 읽는 현상.
Non-Repeatable Read	한 트랜잭션 내에서 같은 데이터를 두 번 조회했을 때, 그 사이에 다른 트랜잭션이 수정 및 커밋하여 조회 결과가 달라지는 현상.
Phantom Read	한 트랜잭션 내에서 특정 조건으로 레코드를 두 번 조회했을 때, 그 사이에 다른 트랜잭션이 새로운 레코드를 삽입 및 커밋하여 조회 결과의 행 개수가 달라지는 현상.

3-2. 네 가지 격리 레벨과 해결 관계

격리 레벨	Dirty Read 방지	Non-Repeatable Read 방지	Phantom Read 방지	성능
Read Uncommitted	$\text{X}$	$\text{X}$	$\text{X}$	가장 높음
Read Committed	$\text{O}$	$\text{X}$	$\text{X}$	높음
Repeatable Read	$\text{O}$	$\text{O}$	$\text{X}$	보통
Serializable	$\text{O}$	$\text{O}$	$\text{O}$	가장 낮음

1. Read Uncommitted (레벨 0)

설명: 커밋되지 않은 데이터도 읽기 허용(가장 낮은 격리성).
주요 문제: Dirty Read 발생. (매우 불안정)

2. Read Committed (레벨 1)

설명: 커밋된 데이터만 읽을 수 있도록 허용. Dirty Read를 방지하는 기본 수준입니다.
기본 설정: Oracle, SQL Server, PostgreSQL 등 다수 상용 DB의 기본값으로, 일관성과 성능의 적절한 균형을 제공합니다.
주요 문제: Non-Repeatable Read, Phantom Read는 발생할 수 있습니다.

3. Repeatable Read (레벨 2)

설명: 트랜잭션 내에서 동일 데이터를 조회하면 항상 같은 값을 보장합니다. Non-Repeatable Read를 방지합니다.
기본 설정: MySQL의 기본값입니다.
주요 문제: Phantom Read는 발생할 수 있습니다. (새로운 행 삽입에 대해서는 락을 걸지 못할 수 있음)

4. Serializable (레벨 3)

설명: 가장 엄격한 격리 수준으로, 트랜잭션을 순차적으로 실행하는 것과 동일한 효과를 내어 모든 동시성 문제를 해결합니다.
단점: 동시성이 크게 떨어져 성능 저하가 가장 심합니다.

4. Spring Boot에서의 트랜잭션 활용: @Transactional

Spring Boot 환경에서는 @Transactional 어노테이션을 사용하여 비즈니스 로직에 트랜잭션을 쉽게 적용할 수 있습니다.

@Service
public class UserService {

    @Transactional
    public void transferMoney(Long fromId, Long toId, int amount) {
        // ... 메서드 내용
    }
}

기본 롤백 정책: @Transactional은 기본적으로 언체크 예외 (RuntimeException) 발생 시 Rollback을 수행합니다. 체크 예외 (Exception) 발생 시에는 기본적으로 Commit을 수행합니다.

격리 레벨 지정: 필요에 따라 격리 레벨을 지정할 수 있습니다.

@Transactional(isolation = Isolation.READ_COMMITTED)
public void readOnlyOperation() { ... }

트랜잭션과 격리 레벨을 이해하는 것은 데이터를 다루는 모든 백엔드 개발자에게 안정적인 시스템 구축을 위한 필수 지식입니다.

[Spring Boot] JPA의 ddl-auto 옵션들

JJuuuunn — Mon, 10 Nov 2025 22:51:04 +0900

1. ddl-auto란?

ddl-auto는 Data Definition Language(DDL)의 자동 처리를 의미합니다. 이는 Spring Boot에서 JPA(Java Persistence API) 구현체인 Hibernate를 사용할 때 데이터베이스 스키마(테이블, 컬럼, 제약 조건 등)를 애플리케이션 시작 시점에 자동으로 관리하도록 지시하는 설정 옵션입니다.

간단히 말해, 우리가 정의한 JPA 엔티티(Java 클래스)와 실제 데이터베이스의 스키마를 동기화하는 방식을 결정하는 핵심 설정입니다.

이 옵션을 통해 개발자는 매번 수동으로 SQL DDL 문을 작성할 필요 없이 편리하게 스키마를 관리할 수 있지만, 운영 환경에서는 매우 신중하게 사용해야 합니다.(가능한 none 또는 validate 추천)

2. 설정 파일 위치 (application.yml / application.properties)

Spring Boot 애플리케이션에서 JPA(Hibernate)의 ddl-auto 옵션을 설정하는 가장 기본적인 방법은 설정 파일(yml / properties)을 이용하는 것입니다.

## application.yml
spring:
  jpa:
    hibernate:
      ddl-auto: [원하는 옵션 입력] # 예: none, validate, update, create-drop 등
    show-sql: true # SQL 쿼리 로그 출력 여부 (선택 사항)

## application.properties
spring.jpa.hibernate.ddl-auto=[원하는 옵션 입력] # 예: none
spring.jpa.show-sql=true # SQL 쿼리 로그 출력 여부 (선택 사항)

3. ddl-auto 옵션들

ddl-auto 옵션	동작	추천 사용 환경	주의사항
none	스키마 자동 변경 작업 없음	프로덕션 (운영)
validate	엔티티와 DB 스키마 일치 여부 검증만 수행	프로덕션 (운영)	일치하지 않으면 앱 시작 실패. 데이터 보호 목적.
update	스키마를 비교하여 차이점만 변경 (데이터 유지)	개발 ️	프로덕션에서 사용 시 예상치 못한 오류 발생 위험이 큽니다.
create	기존 스키마 삭제 후 새로 생성 (데이터 삭제)	개발 초기	매번 데이터가 초기화됩니다.
create-drop	create 후, 애플리케이션 종료 시 삭제	테스트 환경 ⚙️	임시 DB 상태 유지가 필요할 때 유용합니다.

4. 운영 환경에서 고려하면 좋은 사항

운영 환경(프로덕션)은 데이터의 무결성과 안정적인 서비스 연속성이 최우선입니다. 따라서 ddl-auto 옵션은 자동 스키마 변경을 시도하는 update, create, create-drop을 절대 사용해서는 안 됩니다.

안전한 운영을 위해 고려해야 할 사항은 다음과 같습니다.

4 - 1. ddl-auto 설정의 원칙 준수

운영 환경에서는 반드시 다음 중 하나의 옵션을 사용하여 Hibernate가 DB 스키마를 건드리지 않도록 해야 합니다.

none: 가장 보수적이고 안전한 설정. 스키마 관리 책임을 Hibernate에서 완전히 분리합니다.
validate: 스키마 변경은 하지 않지만, 앱 시작 시 엔티티와 DB 스키마가 일치하는지 검증하여 잠재적인 문제를 미리 발견합니다.

4 - 2. 데이터베이스 마이그레이션 도구 활용

운영 환경에서 스키마 변경이 필요할 때는 Hibernate의 자동 기능을 사용하는 대신, 버전 관리와 롤백 기능을 제공하는 전문 도구를 사용해야 합니다.

Flyway 또는 Liquibase: SQL 스크립트 기반으로 스키마 변경 이력을 관리하여, 배포 시점에 안전하고 제어된 방식으로 스키마 변경을 적용할 수 있습니다.

4 - 3. 환경별 설정 분리

로컬 개발 환경과 운영 환경의 설정 파일을 분리하는 것이 중요합니다. Spring Boot의 Profile 기능을 사용하여 환경(예: application-dev.yml, application-prod.yml)에 따라 ddl-auto 옵션을 다르게 설정해야 합니다.

개발 환경 예시: ddl-auto: update
운영 환경 예시: ddl-auto: none 또는 ddl-auto: validate

[Vue.js] Watch 사용 시 ref 와 reactive 차이

JJuuuunn — Sun, 3 Aug 2025 10:33:14 +0900

1. `ref`와 `reactive`

ref: 주로 원시 타입(String, Number, Boolean 등)을 반응형으로 만들 때 사용하지만, 객체나 배열도 감쌀 수 있습니다.
.value를 통해 값에 접근하고 변경합니다.
reactive: 객체(Object)나 배열(Array)과 같은 참조 타입만을 반응형으로 만들 때 사용합니다.
.value 없이 직접 속성에 접근하고 변경합니다.

2. `watch(ref)`

watch 함수에 ref로 선언된 변수를 직접 전달하면, ref의 .value 속성 변화를 감지합니다.

코드 예시:

<template>
  <div>
    <p>Count: {{ count }}</p>
    <button @click="increment">Increment Count</button>

    <p>User Name: {{ user.name }}</p>
    <p>User Age: {{ user.age }}</p>
    <button @click="changeUserName">Change User Name</button>
    <button @click="replaceUser">Replace User Object</button>
  </div>
</template>

<script setup>
import { ref, watch } from 'vue';

const count = ref(0);
const user = ref({ name: 'Alice', age: 30 });

watch(count, (newValue, oldValue) => {
  console.log(`count가 ${oldValue}에서 ${newValue}로 변경되었습니다.`);
});


watch(user, (newValue, oldValue) => {
  console.log('user 객체가 변경되었습니다.', newValue, oldValue);
}, { deep: true }); // 객체 내부의 변화까지 감지하려면 deep: true 필요

const increment = () => {
  count.value++;
};

const changeUserName = () => {
  user.value.name = 'Bob'; // 내부 속성 변경
};

const replaceUser = () => {
  user.value = { name: 'Charlie', age: 25 }; // 새로운 객체 할당
};
</script>

특징:

ref가 원시 타입일 경우: ref의 .value가 변경될 때마다 콜백 함수가 실행됩니다.
ref가 객체/배열일 경우: ref의 .value에 새로운 객체/배열이 할당될 때 (즉, 참조가 바뀔 때) 감지됩니다.
객체/배열 내부의 속성 변화까지 감지하려면 deep: true옵션을 사용해야 합니다. .value를 직접 감시하는 것은 권장되지 않으며, ref자체를 감시하고deep: true를 사용하는 것이 일반적입니다.

3. `watch(reactive)`

watch 함수에 reactive로 선언된 객체를 직접 전달하면, 해당 객체 내부의 모든 속성 변화를 깊게 감지합니다. deep: true 옵션을 명시적으로 설정할 필요가 없습니다.

코드 예시:

<template>
  <div>
    <p>State Name: {{ state.name }}</p>
    <p>State Age: {{ state.age }}</p>
    <p>State City: {{ state.address.city }}</p>
    <button @click="changeName">Change Name</button>
    <button @click="changeCity">Change City</button>
  </div>
</template>

<script setup>
import { reactive, watch } from 'vue';

const state = reactive({
  name: 'Alice',
  age: 30,
  address: {
    city: 'Seoul',
    zip: '12345'
  }
});

// reactive 객체 내부의 어떤 속성이든 변화하면 감지 (deep 옵션 불필요)
watch(state, (newValue, oldValue) => {
  console.log('state 객체에 변경이 발생했습니다.', newValue, oldValue);
});

const changeName = () => {
  state.name = 'Bob'; // 얕은 속성 변경
};

const changeCity = () => {
  state.address.city = 'Busan'; // 깊은 속성 변경
};

// reactive 객체 자체를 새로운 객체로 '교체'하는 것은 반응형을 잃게 만듭니다.
// 이는 reactive의 설계 목적과 맞지 않습니다.
// state = { name: 'Charlie', age: 25 }; // 이 방법은 reactive의 반응성을 깨뜨림!
</script>

특징:

reactive는 항상 객체/배열만을 다루며, watch에 reactive 객체를 전달하면 기본적으로 깊은 감지(deep watching)가 활성화됩니다.
reactive 객체 자체를 새로운 객체로 재할당하는 것은 반응성을 잃게 만듭니다. reactive는 객체 내부의 변경에 최적화되어 있습니다. 만약 객체 자체를 교체해야 한다면 ref를 사용하는 것이 더 적합할 수 있습니다.

4. 언제 무엇을 사용해야 할까?

구분	`watch(ref)`	`watch(reactive)`
감지 대상	`ref`의 `.value`의 변화 (원시 타입, 객체/배열 교체)	`reactive` 객체 내부의 모든 속성 변화
깊은 감지	객체/배열일 경우 `deep: true` 옵션 필요	기본적으로 깊은 감지 활성화 (옵션 불필요)
새로운 객체 할당	`ref.value = newObject` 형태로 객체 교체 가능	`reactive` 객체 자체 교체는 반응성을 잃음
주요 사용처	- 단일 원시 값의 변화 감지 - 객체/배열의 참조 변경 감지 - 특정 객체/배열의 내부 깊은 변화를 선택적으로 감지 (`deep: true`와 함께)	- 복잡한 객체/배열의 다양한 내부 속성 변화 감지
주의 사항	객체/배열 내부 변화 감지 시 `deep: true` 사용 여부 고려	`reactive` 객체 자체를 통째로 교체하지 말 것

결론적으로:

단일 값 (원시 타입 또는 참조 자체가 중요한 객체/배열)의 변화를 감지할 때는 watch(ref)를 사용하고 필요에 따라 deep: true를 고려
복잡한 객체/배열의 내부 속성 변경을 자동으로 깊게 감지하고 싶을 때는 watch(reactive)를 사용하는 것이 편리합니다. 단, reactive 객체 자체를 통째로 교체하는 상황은 피해야 합니다.

[CSS] Grid에서 % 와 fr 단위 차이

JJuuuunn — Wed, 21 May 2025 12:40:43 +0900

Intro

사내 프로젝트를 진행하는 도중 Grid를 사용하여 레이아웃을 짜는 도중에 row가 5줄이고 각각 14px 만큼 gap을 가지는 레이아웃을 만들기 위해 처음에는 % 단위를 사용하여 grid-template-rows를 값을 넣고 row-gap을 추가하였을 때 전체 높이(height)가 부모 요소의 크기를 초과하는 문제가 발생하였다.

이 문제를 해결하기 위해 fr 단위를 사용했더니 정확히 부모 요소 높이에 맞춰서 원하는 레이아웃이 배치가 되었다.

이 과정을 정리하며 CSS Grid에서 %와 fr 단위의 차이를 알아보려 한다.

문제 원인

grid-template-rows: repeat(5, 20%);
row-gap: 14px;

% 단위는 부모 요소의 height를 기준으로 계산되기에 위와 같이 CSS 를 적용 시키면 gap은 계산에 포함되지 않고 별도로 추가 되어 전체 높이(height)는 (20% + 20% + 20% + 20% + 20%) + (14px * 4) = 100% + 56px 이 되어버린다.

해결 방법 : fr

% 단위 대신 fr 단위를 사용할 경우 전체 높이(height)에서 먼저 gap 의 총 크기를 먼저 계산 한 후 남은 공간에 대해서 계산이 들어간다.

fr (fraction)은 남은 공간을 기준으로 비율을 나누기 때문에 아래와 같이 작성하면,

grid-template-rows: repeat(5, 1fr);
row-gap: 14px;

각 row의 크기는 (100% - (14px * 4)) / 5 의 크기가 되어 부모 요소의 크기보다 커지는 문제를 해결할 수 있다.

즉, fr은 gap까지 고려된 상태에서 균등 분배되는 구조

	%	fr (fraction)
기준	부모 요소의 크기	gap을 제외한 남은 공간
gap 고려	❌ (무시됨)	✅ (제외 후 분배)
실제 높이 초과 가능성	있음	없음
유용한 상황	부모 크기 정확히 아는 경우	동적 높이, 균등 분배할 때 유리

[JavaScript] Closure 란?

JJuuuunn — Sat, 29 Mar 2025 21:39:49 +0900

JavaScript에서 클로저(Closure)란?

클로저(Closure)는 함수가 자신이 선언된 렉시컬 환경(Lexical Environment)을 기억하고, 그 환경에 접근할 수 있는 기능을 의미합니다. 즉, 내부 함수가 외부 함수의 변수에 접근할 수 있으며, 외부 함수 실행이 끝난 후에도 변수의 값을 유지할 수 있습니다.

클로저의 기본 개념

함수 내부에서 선언된 함수

클로저는 보통 함수 내부에서 정의된 또 다른 함수로 구성됩니다. 내부 함수는 외부 함수의 변수를 참조할 수 있으며, 외부 함수 실행이 종료된 후에도 변수의 값을 유지합니다.

예제 코드

function outerFunction(outerVariable) {
    return function innerFunction(innerVariable) {
        console.log(`Outer Variable: ${outerVariable}, Inner Variable: ${innerVariable}`);
    };
}

const newFunction = outerFunction('Hello');
newFunction('World'); // Outer Variable: Hello, Inner Variable: World

클로저의 활용 사례

데이터 은닉 (Encapsulation)

클로저를 활용하면 외부에서 직접 접근할 수 없는 변수를 만들고, 특정 함수만이 이를 조작할 수 있도록 할 수 있습니다.

function counter() {
    let count = 0;
    return {
        increment: function () {
            count++;
            console.log(count);
        },
        decrement: function () {
            count--;
            console.log(count);
        }
    };
}

const myCounter = counter();

myCounter.increment(); // 1
myCounter.increment(); // 2
myCounter.decrement(); // 1

이벤트 리스너와 클로저

클로저는 이벤트 핸들러에서도 유용하게 사용됩니다. 예를 들어, 버튼을 클릭할 때 특정 값을 유지하고 싶을 때 사용할 수 있습니다.

function attachClickEvent(buttonId) {
    let count = 0;
    document.getElementById(buttonId).addEventListener('click', function () {
        count++;
        console.log(`Button clicked ${count} times`);
    });
}
attachClickEvent('myButton');

closure 를 사용하여 memoize 구현하기

closure를 사용하여 memoize 함수 안에 캐시 기능을 하는 map 객체를 구현하여 동일한 인자값을 들어오는 경우 불필요한 연산 처리 없이 바로 값을 리턴하도록 구현

const memoize = (func) => {
    const cache = new Map();
    return (x) => {
        if (cache.has(x)) {
            console.log('캐시에서 가져옴');
        }

        const result = func(x);
        cache.set(x, result);
        
        return result;
    }
}

클로저의 주의점

메모리 관리
클로저는 외부 함수의 변수를 유지하기 때문에 불필요한 메모리 사용을 초래할 수 있습니다. 따라서, 사용이 끝난 클로저는 참조를 제거하여 가비지 컬렉션이 가능하도록 해야 합니다.
성능 이슈
클로저가 너무 많아지면 성능 저하를 유발할 수 있으므로, 필요할 때만 사용하도록 주의해야 합니다.

[Vue.js] 리스트 렌더링

JJuuuunn — Sat, 22 Mar 2025 16:00:07 +0900

Vue.js 리스트 렌더링

Vue.js에서 리스트 렌더링은 배열이나 객체를 기반으로 동적인 목록을 생성하는 데 사용됩니다.

이를 위해 v-for 디렉티브를 사용하며, 각 항목을 반복하여 렌더링할 수 있습니다.

기본적인 `v-for` 사용법

v-for 디렉티브는 배열의 각 요소를 반복하여 출력할 때 사용됩니다.

// 숫자 범위
<ul>
  <li v-for="n in 10">
    {{ n }}
  </li>
</ul>

// 배열 또는 객체
<ul>
  <li v-for="item in items">
    {{ item.text }}
  </li>
</ul>

인덱스 사용

두번째 선택 인자를 통해서 인덱스를 가져와서 사용할 수도 있습니다.

<ul>
  <li v-for="(item, index) in items">
    {{ index + 1 }}번쨰 : {{ item.text }}
  </li>
</ul>

객체 사용시

객체의 속성을 반복할 때, 객체를 받아서 사용할 수도 잇찌만 아래와 같이 value, key 형식으로 따로 받아서 사용가능 하며 이때는 세번째에 선택인자로 인덱스를 가져올 수 있습니다.

<ul>
  <li v-for="(value, key) in myObject" :key="key">
    {{ key }}: {{ value }}
  </li>
</ul>

Key 속성을 통한 상태 유지

v-for로 렌더링 된 리스트를 업데이트 할 경우 기본적으로 in-place patch 전략을 사용하며 아이템의 순서가 변경된 경우 DOM 요소를 이동하는 대신 변경이 필요한 인덱스의 요소를 패치하여 렌더링 합니다.

리스트 업데이트 시 주의점

Vue는 리스트 업데이트 시 :key를 사용하여 효율적으로 DOM을 갱신합니다.
가능하면 고유한 id 값을 :key에 지정하는 것이 좋습니다.

v-if와 v-for를 같이 사용한 경우

v-if가 우선순위가 더 높으므로 v-if가 먼저 동작한 뒤 v-for가 동작합니다.

결론

Vue.js의 리스트 렌더링은 v-for 디렉티브를 활용하여 쉽게 구현할 수 있으며, 배열뿐만 아니라 객체에도 적용할 수 있습니다. 성능 최적화를 위해 :key 속성을 적절히 활용하는 것이 중요합니다.

[Vue.js] 조건부 렌더링

JJuuuunn — Fri, 21 Mar 2025 20:00:36 +0900

Vue.js 조건부 렌더링이란?

Vue.js에서 조건부 렌더링이란 특정 조건에 따라 DOM 요소를 표시하거나 제거하는 기능을 의미하며, 이를 통해 사용자는 동적으로 화면을 구성할 수 있습니다.

v-if

v-if는 조건이 참일 경우 요소를 렌더링하고, 거짓이면 DOM에서 제거합니다.

<template>
  <button v-if="isVisible" @click="isVisible = false">내용 숨기기</button>
  <button v-else @click="isVisible = true">내용 보이기</button>
  <p v-if="isVisible">v-if를 이용하여 내용이 사라지게도 보이게 할 수 있습니다.</p>
</template>

<script setup>
import { ref } from 'vue'

const isVisible = ref(true);
</script>

v-else 및 v-else-if

v-else는 v-if 조건이 거짓일 때만 요소를 렌더링하며, v-else-if는 추가적인 조건을 설정할 때 사용됩니다.

<template>
  <p v-if="status === 'A'">버튼 A를 눌렀습니다.</p>
  <p v-else-if="status === 'B'">버튼 B를 눌렀습니다.</p>
  <p v-else>나머지 버튼들을 눌렀습니다.</p>
  <button @click="status = 'A'">버튼 A</button>
  <button @click="status = 'B'">버튼 B</button>
  <button @click="status = 'C'">버튼 C</button>
  <button @click="status = 'D'">버튼 D</button>
</template>

<script setup>
import { ref } from 'vue'

const status = ref("loading");
</script>

v-show

v-show는 display 속성을 변경하여 요소를 숨깁니다. v-if와 달리 요소를 제거하지 않으므로, 자주 변경되는 경우에 더 적합합니다.

<div id="app">
  <p v-show="isVisible">이 문장은 보일 수도 있고 숨겨질 수도 있습니다.</p>
  <button @click="isVisible = !isVisible">토글</button>
</div>

<script>
  const app = Vue.createApp({
    data() {
      return {
        isVisible: true
      };
    }
  }).mount("#app");
</script>

결론

Vue.js의 조건부 렌더링을 사용하면 동적으로 요소를 표시하거나 숨길 수 있으며, v-if는 조건에 충족하지 못하는 경우 DOM을 조작하여 요소를 제거하고, v-show는 CSS를 사용하여(display: none;) 요소를 숨깁니다.

초기 렌더링 시 부담을 줄이고 싶은 경우에는 v-if를 사용하고, 자주 변경이 필요한 경우에는 v-show를 사용하면 됩니다.

[Vue.js] ref 와 reactive 차이점

JJuuuunn — Mon, 3 Mar 2025 23:06:40 +0900

Vue.js에서 상태 관리를 위해 ref와 reactive를 사용할 수 있습니다. 두 방식 모두 반응형(Reactivity) 시스템을 제공하지만, 사용 방법과 동작 방식에서 차이가 있다

ref란?

ref는 Vue 3에서 제공하는 반응형 상태 관리 방법 중 하나로, 기본형(Primitive) 데이터와 객체(Object) 모두를 반응형 상태로 만들 수 있습니다. 반응형 변수를 개별적으로 관리할 때 유용하며, 값에 접근할 때 .value를 사용해야 합니다.

ref의 특징

기본형 데이터(숫자, 문자열, 불리언 등)와 객체를 감쌀 수 있음
반응형으로 관리하기 위해 .value 프로퍼티를 사용
템플릿에서 자동으로 언래핑(자동으로 .value가 적용됨)

기본형 데이터에서 ref 사용

기본형 데이터를 다룰 때 ref를 사용하는 예제입니다.

import { ref } from 'vue';

export default {
  setup() {
    const count = ref(0);
    
    function increment() {
      count.value++;
    }
    
    return { count, increment };
  }
};

객체에서 ref 사용

객체를 ref로 감싸는 경우에도 사용할 수 있습니다.

import { ref } from 'vue';

export default {
  setup() {
    const user = ref({ name: 'Alice', age: 25 });
    
    function updateAge() {
      user.value.age++;
    }
    
    return { user, updateAge };
  }
};

ref의 자동 언래핑(Auto-unwrapping)

템플릿에서는 .value를 사용하지 않아도 자동으로 반응형 데이터가 접근됩니다.

<template>
  <p>Count: {{ count }}</p>
  <button @click="increment">증가</button>
</template>

reactive란?

reactive는 객체(Object)만 반응형으로 만들 수 있으며, 속성 그대로 접근할 수 있습니다. reactive를 사용하면 객체 내부의 모든 속성이 반응형으로 처리됩니다.

reactive 예제

import { reactive } from 'vue';

export default {
  setup() {
    const state = reactive({
      count: 0
    });
    
    function increment() {
      state.count++;
    }
    
    return { state, increment };
  }
};

ref와 reactive의 차이점

ref	reactive
기본형 데이터와 객체 모두 감싸서 반응형 상태로 변환	객체만 반응형 상태로 변환
`.value`를 사용하여 값에 접근	속성 그대로 접근 가능
반응형 변수를 개별적으로 관리 가능	객체의 모든 속성이 반응형으로 처리됨

결론

ref는 기본형 데이터와 객체 모두를 반응형으로 만들 수 있으며, .value를 통해 접근해야 합니다. 반면, reactive는 객체만 반응형으로 만들 수 있으며, .value 없이 속성 그대로 접근할 수 있습니다. 프로젝트의 요구사항에 맞춰 적절한 방식을 선택하는 것이 중요합니다.

[HTML] LocalStorage 와 SessionStorage

JJuuuunn — Thu, 20 Feb 2025 16:00:56 +0900

WebStorage(웹 스토리지)란?

Web Storage(웹 스토리지) 는 브라우저에 데이터를 저장하는 방법 중 하나로, 클라이언트 측에서 데이터를 영구적 또는 일시적으로 저장할 수 있도록 합니다. 대표적으로 LocalStorage와 SessionStorage가 있으며, 기존의 쿠키(Cookie)보다 더 많은 데이터를 저장할 수 있고 보안적으로도 안전합니다.

LocalStorage

LocalStorage는 사용자가 데이터를 삭제하지 않는 한 브라우저에 영구적으로 저장됩니다. 즉, 페이지를 닫거나 브라우저를 종료해도 데이터가 유지됩니다.

// LocalStorage 데이터 저장
localStorage.setItem('username', 'JohnDoe');

// 데이터 가져오기
const user = localStorage.getItem('username');
console.log(user); // JohnDoe

// 데이터 삭제
localStorage.removeItem('username');

SessionStorage

SessionStorage는 사용자가 페이지를 닫거나 브라우저를 종료하면 데이터가 자동으로 삭제됩니다. 즉, 세션이 유지되는 동안만 데이터를 저장합니다.

// SessionStorage 데이터 저장
sessionStorage.setItem('sessionData', 'Temporary Info');

// 데이터 가져오기
const sessionData = sessionStorage.getItem('sessionData');
console.log(sessionData); // Temporary Info

// 데이터 삭제
sessionStorage.removeItem('sessionData');

쿠키(Cookie)란?

쿠키는 웹 사이트가 사용자의 브라우저에 저장하는 작은 데이터 파일입니다. 주로 사용자 인증, 세션 유지, 광고 추적 등에 사용됩니다.

// 쿠키 저장 (유효기간 설정)
document.cookie = "username=JohnDoe; expires=Fri, 31 Dec 2025 23:59:59 GMT; path=/";

// 쿠키 가져오기
console.log(document.cookie);

LocalStorage, SessionStorage, 쿠키 비교

항목	LocalStorage	SessionStorage	Cookie(쿠키)
데이터 유지 기간	영구적	세션 종료 시 삭제	설정된 만료일에 따라 다름
저장 용량	최대 5MB	최대 5MB	약 4KB
서버 전송	전송되지 않음	전송되지 않음	매 요청마다 서버로 전송됨
보안	JavaScript에서 접근 가능 (XSS 공격 주의)	JavaScript에서 접근 가능 (XSS 공격 주의)	보안 취약 (HTTPOnly 옵션 사용 가능)

결론

LocalStorage와 SessionStorage는 쿠키보다 더 많은 데이터를 저장할 수 있고, HTTP 요청 시 불필요한 데이터 전송을 방지할 수 있는 장점이 있습니다. 그러나 XSS 공격에 취약할 수 있으므로 민감한 정보는 저장하지 않는 것이 좋습니다. 쿠키는 서버와의 통신이 필요한 경우 유용하지만, 데이터 용량이 작고 보안 취약점이 존재하므로 사용 시 주의해야 합니다.

[Frontend] Axios Interceptor vs Transform(Request/Response)

JJuuuunn — Tue, 18 Feb 2025 23:00:04 +0900

1. Axios란?

Axios는 브라우저와 Node.js 환경에서 사용 가능한 HTTP 클라이언트 라이브러리입니다. 주로 API 요청을 보낼 때 사용되며, 응답을 처리하는 기능을 제공합니다.

2. Axios Interceptor

Interceptor는 요청(request) 또는 응답(response)이 처리되기 전후에 실행되는 기능입니다. 이를 통해 공통적인 요청/응답 로직을 중앙에서 관리할 수 있습니다.

요청 인터셉터(Request Interceptor)

요청을 보내기 전에 특정 작업을 수행할 수 있습니다. 예를 들어, 모든 요청에 인증 토큰을 추가하는 경우가 있습니다.

axios.interceptors.request.use(
  (config) => {
    config.headers.Authorization = `Bearer ${localStorage.getItem('token')}`;
    return config;
  },
  (error) => {
    return Promise.reject(error);
  }
);

응답 인터셉터(Response Interceptor)

서버에서 응답을 받은 후 데이터 변환, 오류 처리 등을 수행할 수 있습니다.

axios.interceptors.response.use(
  (response) => {
    return response.data; // 응답 데이터만 반환
  },
  (error) => {
    console.error('API Error:', error);
    return Promise.reject(error);
  }
);

3. Axios Transform(Request/Response)

Transform 기능은 요청을 보내거나 응답을 받기 전에 데이터를 변환하는 기능을 제공합니다. 특정 요청 또는 응답에서만 변환이 필요할 때 유용합니다.

요청 데이터 변환(Request Transform)

요청을 보내기 전에 데이터를 변환하는 기능입니다.

axios.post('/user', { name: 'John' }, {
  transformRequest: [(data, headers) => {
    return JSON.stringify(data); // 데이터를 JSON 문자열로 변환
  }]
});

응답 데이터 변환(Response Transform)

응답을 받은 후 데이터를 가공하는 기능입니다.

axios.get('/user', {
  transformResponse: [(data) => {
    return JSON.parse(data).map(user => user.name.toUpperCase());
  }]
}).then(response => console.log(response));

4. Interceptor vs Transform 비교

Interceptor	Transform
글로벌하게 요청/응답을 가로채어 처리 가능	개별 요청/응답에서 데이터 변환 가능
모든 API 요청에 공통적인 로직을 적용할 때 사용	특정 API 요청/응답에서만 변환이 필요할 때 사용
주로 인증 토큰 추가, 로딩 스피너 표시, 공통 오류 처리 등에 활용	데이터 포맷 변경, 특정 응답 가공 등에 활용

결론

Axios의 Interceptor와 Transform은 각각의 역할이 다릅니다. Interceptor는 모든 요청/응답을 가로채는 데 유용하며, Transform은 특정 요청이나 응답에서만 데이터 변환이 필요할 때 사용됩니다. 개발자는 프로젝트의 요구사항에 따라 적절한 방식을 선택해야 합니다.

[참고]

APIDog - Axios 문서