4L : 좋았던 점(Liked), 배운 점(Learned), 부족했던 점(Lacked), 바라는 점(Longed for)을 돌아보는 회고 방식

이 방식으로 지난 중급 프로젝트 '최애의 포토'에 대한 회고를 진행해보려고 한다.

Liked (좋았던 점)

처음으로 BE에 집중해보겠다 다짐하고 들어갔던 프로젝트였다. 결국에는 풀스택으로 마무리했지만 이전까지 주로 FE 위주 작업만 해왔던 나로서는 긴장되는 시작이었다. 예상되는 문제도 어떻게 풀어나갈지 고민하며 BE의 재미를 느낄 수 있었던 점, 프로젝트의 전체적인 이해와 발표로 깔끔히 마무리한 점은 좋았다.

Learned (배운 점)

단순 코드를 짠다기보다, 생각해야 한다는 점을 배웠다. 하나의 사건에 발생되는 문제들을 개발자는 생각해내야하며 그것을 어떻게 해결할건지에 대한 고찰이 필요하다. 초기 단계에 개발해야 하는 내용을 충분히 이해하고 처음부터 구조를 알맞게 작성하는 것이 효율적이다. 그리고 각 개발에 어떤 기능을 접목시킬지에 대한 정보력 또한 실력이라고 느꼈다.

Lacked (부족했던 점)

'주도적'이지 못했다. 팀장이 아니더라도 충분히 주도적으로 기능을 찾아온다던지, 더 좋은 코드는 무엇일지에 대해 노력했어야 했다. 이는 내가 이전에 봐왔던 팀원들에게서 배운 모습인데 내가 그러지 못했기에 프로젝트에서 나는 잘했다고 안심하거나 다른 팀원을 원망하기엔 자격이 없는 것 같다.

Longed for (바라는 점)

앞으로의 나에게 바라는 점은 '같이 하고싶은 팀원'이 되는 것이다. 이분이랑 하면 프로젝트가 잘 될 것 같아! 라는 생각이 함께 있는 동기들, 나아가 앞으로 마주할 팀원들에게 들게하고 싶다.

상황 설명

포토카드 거래 서비스에서 카드 구매 하나가 완료되려면 다음 작업이 모두 이루어져야 한다.

1. market_items    — 판매 수량(soldQuantity) 차감, 품절이면 상태 SOLD_OUT 변경
2. my_cards        — 판매자 보유 카드 수량 차감
3. user_points     — 구매자 포인트 차감
4. user_points     — 판매자 포인트 지급
5. orders          — 주문 생성
6. my_cards        — 구매자 카드 추가(upsert)

이 구조에서 동시 요청이 들어올 경우 네 가지 문제가 발생할 수 있다. 재고 초과 판매 -- 동시 구매 요청이 같은 재고를 중복 차감한다. 보유량 초과 등록 — 여러 판매글에 보유 수량 이상의 카드를 등록할 수 있다. 품절 처리 중 교환 신청이 통과되는 불일치 — 품절 처리와 교환 거절이 분리되어 있으면 그 사이에 새 교환 신청이 끼어든다. 동시 승인으로 발생하는 이중처리 — 동시 승인 요청으로 같은 교환이 두 번 처리된다.

Solution_1 낙관적 잠금으로 재고 초과 방지

기존 방식의 문제

const item = await prisma.marketItem.findUnique({ where: { id } });

if (item.quantity - item.soldQuantity < requestedQty) {
  throw new Error('재고 부족');
}

await prisma.marketItem.update({
  where: { id },
  data: { soldQuantity: { increment: requestedQty } },
});

두 요청이 같은 재고를 동시에 읽으면 둘 다 "재고 있음"으로 판단하여 중복 차감이 발생한다.

요청 A: findUnique → soldQuantity=4, quantity=5 → 재고 1개 확인 ✓
요청 B: findUnique → soldQuantity=4, quantity=5 → 재고 1개 확인 ✓
요청 A: update soldQuantity → 5 (재고 소진)
요청 B: update soldQuantity → 6 (재고 초과!)

Solution -- 조건부 updatdeMany 읽은 시점의 값과 현재 DB 값이 정확히 일치할 때만 업데이트되는 조건을 추가한다.

const marketItem = await tx.marketItem.findUnique({
  where: { id: marketItemId },
});

const updatedStock = await tx.marketItem.updateMany({
  where: {
    id: marketItemId,
    status: 'SELLING',
    quantity: marketItem.quantity,          // ← 읽은 시점의 값과 정확히 일치해야만 갱신
    pricePerCard: marketItem.pricePerCard,
    soldQuantity: {
      lte: marketItem.quantity - quantity,
    },
  },
  data: {
    soldQuantity: { increment: quantity },
  },
});

if (updatedStock.count === 0) {
  throw new AppError(
    '판매 가능한 카드 수량이 부족합니다.',
    409,
    ERROR_CODES.INSUFFICIENT_STOCK,
  );
}

그 사이 다른 요청이 값을 바꿨다면 WHERE 조건이 맞지 않아 업데이트되는 행이 없게 된다. count === 0이면 충돌이 발생한 것으로 판단해 즉시 실패 처리한다.

같은 원리를 두 가지 케이스에 추가 적용

보유량 초과 등록 방지 — 여러 판매글의 수량 합산을 WHERE 조건에 포함한다.

const updated = await prisma.marketItem.updateMany({
  where: {
    id: itemId,
    status: 'SELLING',
    soldQuantity: {
      lte: item.quantity,  // ← 기존 판매글 수량 합산을 WHERE 조건에 포함
    },
  },
  data: item,
});

if (updated.count === 0) {
  return null;
}

포인트 차감 음수 방지 — WHERE balance >= amount 조건으로 잔액 부족 시 차감을 원천 차단한다.

const deductedPoint = await tx.userPoint.updateMany({
  where: {
    userId: buyerId,
    point: { gte: totalPrice },  // ← 잔액이 충분한 경우만
  },
  data: {
    point: { decrement: totalPrice },
  },
});

if (deductedPoint.count === 0) {
  throw new AppError(
    '보유 포인트가 부족합니다.',
    409,
    ERROR_CODES.INSUFFICIENT_POINTS,
  );
}

왜 비관적 잠금이 아닌 낙관적 잠금인가

비관적 잠금(SELECT FOR UPDATE)은 트랜잭션 동안 row를 잠금 상태로 두기 때문에 다른 요청은 락 해제까지 대기해야 한다. 즉, 병목과 데드락의 위험이 있다.

따라서 락 없이 동시처리가 가능하며 충돌 시 즉시 실패를 감지하고, 읽기 성능을 유지하며 대기없이 처리할 수 있다는 점에서 낙관적 잠금을 선택했다.

이중 방어 구조 낙관적 잠금을 선택한 만큼 안정성을 보완하기 위해 2단계 방어 구조를 구성했다.

1차 — 애플리케이션 레벨
  재고 조회 후 수량 확인 → 사전 검증
  → 명백히 불가능한 요청을 빠르게 걸러냄

2차 — DB 레벨 (낙관적 잠금)
  조건부 updateMany 원자 연산
  → 1차를 뚫고 들어온 동시 요청도 차단

낙관적 잠금의 핵심은 quantity > 0이 아닌 quantity = 읽은_시점_값이다. 이 차이가 "재고가 0이 되었는지"를 확인하는 것과, "내가 읽은 이후 아무도 건드리지 않았는지"를 확인하는 것의 차이다.

updateMany가 영향을 준 row 수(count)를 항상 확인하는 습관을 들이자. 그 숫자가 0이라면 누군가 먼저 선점한 것이다.

이 과정에서 발생한 교환 제안 생성 로직의 TOCTOU(Time of Check to Time of Use)에 대해 이야기를 나눠보고자 한다.

TOCTOU란?

TOCTOU는 "확인한 시점"과 "사용한 시점" 사이의 간격에서 발생하는 Race Condition이다.

쉽게 말하면 이렇다.

A가 냉장고에 계란이 1개 있는 걸 확인했다. B도 냉장고에 계란이 1개 있는 걸 확인했다. A가 계란을 꺼냈다. B도 계란을 꺼내려 했지만 이미 없다.

"확인"과 "사용" 사이에 다른 누군가가 끼어들 수 있다는 게 핵심이다. 싱글스레드 환경이라면 문제가 없지만, 서버는 수많은 요청을 동시에 처리하기 때문에 이 간격이 버그의 원인이 된다.

기존 코드와 문제점

기존 코드

교환 제안 생성 로직 (exchangeService.create())은 아래 두 단계로 이루어진다.

// exchangeService.js
const create = async ({ proposerId, marketItemId, offeredCardId }) => {
  // ... 유효성 검사 생략

  // 1단계: 중복 제안 확인
  const duplicate = await exchangeRepository.findWaitingExchange(
    marketItemId,
    proposerId,
  );

  if (duplicate) {
    throw new AppError(
      '이미 대기 중인 교환 신청이 있습니다.',
      409,
      ERROR_CODES.DUPLICATE_EXCHANGE,
    );
  }

  // 2단계: 교환 제안 생성
  const proposal = await exchangeRepository.create({
    proposerId,
    marketItemId,
    offeredCardId,
  });

  return proposal;
};

// exchangeRepository.js
const findWaitingExchange = async (marketItemId, proposerId) => {
  return prisma.exchangeProposal.findFirst({
    where: {
      marketItemId,
      proposerId,
      status: 'WAITING',
    },
  });
};

const create = async ({ marketItemId, proposerId, offeredCardId }) => {
  return prisma.exchangeProposal.create({
    data: {
      marketItemId,
      proposerId,
      offeredCardId,
    },
  });
};

언뜻 보면 문제없어 보인다. 중복 확인을 하고, 없으면 생성한다.

하지만 여기에 TOCTOU가 숨어있다.

문제 발생 시나리오

같은 유저가 클라이언트에서 실수로(혹은 네트워크 재시도로) 동시에 두 개의 요청을 보내는 상황을 가정해보자.

시간 →

요청 A: [중복 확인: 없음] -------- [제안 생성 완료]
요청 B:         [중복 확인: 없음] -------- [제안 생성 완료]
                     ↑
              이 사이에 A가 끼어들지 못함
              (확인은 했지만 아직 생성 전)

두 요청이 거의 동시에 들어오면:

1. 요청 A가 findWaitingExchange 실행 → 결과: 없음
2. 요청 B가 findWaitingExchange 실행 → 결과: 없음 (A가 아직 생성 안 했으니까)
3. 요청 A가 create 실행 → 제안 생성 완료
4. 요청 B가 create 실행 → 중복 제안 생성됨 ❌

중복 확인과 생성이 트랜잭션으로 묶여 있지 않아서 두 작업 사이에 다른 요청이 끼어들 수 있다.

왜 문제가 되는가

이 서비스에서 동일한 유저가 동일한 마켓 아이템에 교환 제안을 두 개 보내면:

• 판매자는 같은 제안이 두 개 쌓여 혼란이 생긴다.
• 판매자가 두 제안을 모두 승인하려 할 수 있다. (승인 로직에서 두 번째는 막히지만, 상태 관리가 복잡해진다.)
• 서비스 신뢰도가 떨어진다.

해결 방법

방법 1: 트랜잭션으로 묶기

가장 직관적인 해결책은 중복 확인과 생성을 하나의 트랜잭션으로 묶는 것이다.

// exchangeRepository.js - 개선된 create
const create = async ({ marketItemId, proposerId, offeredCardId }) => {
  return prisma.$transaction(async (tx) => {
    // 트랜잭션 안에서 중복 확인
    const duplicate = await tx.exchangeProposal.findFirst({
      where: {
        marketItemId,
        proposerId,
        status: 'WAITING',
      },
    });

    if (duplicate) {
      throw new AppError(
        '이미 대기 중인 교환 신청이 있습니다.',
        409,
        ERROR_CODES.DUPLICATE_EXCHANGE,
      );
    }

    // 같은 트랜잭션 안에서 생성
    return tx.exchangeProposal.create({
      data: {
        marketItemId,
        proposerId,
        offeredCardId,
      },
    });
  });
};

확인과 생성이 하나의 트랜잭션으로 묶이면 그 사이에 다른 트랜잭션이 끼어들 수 없다.

단, Prisma의 기본 트랜잭션 격리 수준은 데이터베이스 설정에 따라 다르다. PostgreSQL 기준 기본값은 READ COMMITTED인데, 이 수준에서도 동시 요청이 완전히 차단되지는 않는다. 확실히 막으려면 격리 수준을 높이거나, 아래 방법 2를 함께 사용하는 것이 좋다.

방법 2: DB 유니크 제약 추가

근본적인 해결책은 데이터베이스 레벨에서 중복을 막는 것이다. 애플리케이션 코드가 아무리 잘 짜여 있어도, DB 제약이 없으면 예외 경로에서 중복이 생길 수 있다.

Prisma 스키마에 유니크 제약을 추가한다.

// schema.prisma
model ExchangeProposal {
  id           Int      @id @default(autoincrement())
  marketItemId Int
  proposerId   String
  offeredCardId Int
  status       ExchangeStatus @default(WAITING)
  createdAt    DateTime @default(now())

  @@unique([marketItemId, proposerId, offeredCardId])
}

이렇게 하면 동일한 (marketItemId, proposerId, offeredCardId) 조합으로 두 번째 INSERT가 들어올 때 DB가 자체적으로 에러를 반환한다. 애플리케이션에서 이 에러를 잡아서 적절한 응답으로 변환하면 된다.

// exchangeRepository.js
const create = async ({ marketItemId, proposerId, offeredCardId }) => {
  try {
    return await prisma.exchangeProposal.create({
      data: { marketItemId, proposerId, offeredCardId },
    });
  } catch (e) {
    // Prisma unique constraint 에러 코드: P2002
    if (e.code === 'P2002') {
      throw new AppError(
        '이미 대기 중인 교환 신청이 있습니다.',
        409,
        ERROR_CODES.DUPLICATE_EXCHANGE,
      );
    }
    throw e;
  }
};

두 방법의 비교

두 방법을 함께 적용하는 것이 가장 안전하다. 트랜잭션으로 애플리케이션 레벨에서 먼저 막고, DB 제약으로 최후의 방어선을 구축하는 방식이다.

최종 코드

// exchangeRepository.js - 최종 개선 버전
const create = async ({ marketItemId, proposerId, offeredCardId }) => {
  try {
    return await prisma.$transaction(async (tx) => {
      const duplicate = await tx.exchangeProposal.findFirst({
        where: { marketItemId, proposerId, status: 'WAITING' },
      });

      if (duplicate) {
        throw new AppError(
          '이미 대기 중인 교환 신청이 있습니다.',
          409,
          ERROR_CODES.DUPLICATE_EXCHANGE,
        );
      }

      return tx.exchangeProposal.create({
        data: { marketItemId, proposerId, offeredCardId },
      });
    });
  } catch (e) {
    if (e.code === 'P2002') {
      throw new AppError(
        '이미 대기 중인 교환 신청이 있습니다.',
        409,
        ERROR_CODES.DUPLICATE_EXCHANGE,
      );
    }
    throw e;
  }
};

구매와 교환 승인 로직에서는 $transaction과 조건부 갱신으로 동시성 문제를 잘 처리하면서, 정작 교환 제안 생성에서는 이 패턴이 빠져있었다. 기능이 작동한다고 해서 정합성이 보장되는 건 아니다.

TOCTOU는 로컬 테스트에서는 재현하기 어렵다. 동시 요청을 의도적으로 만들지 않으면 발견하기 힘들고, 운영 환경에서 트래픽이 많아질수록 발생 확률이 올라간다.

데이터 정합성은 애플리케이션 레벨과 DB 레벨 두 곳에서 모두 지켜야 한다는 것을 이번 리뷰를 통해 다시 한번 확인했다.

포토카드 거래 플랫폼을 만들면서 동시 구매 문제를 해결한 방법을 공유합니다.

문제상황: 동시에 두 명이 같은 카드를 사면?

마켓플레이스에 잔여 수량이 1장인 포토카드가 올라와 있다고 가정해보자. A와 B가 동시에 구매 요청을 보내면 어떻게 될까?

[A 요청] 잔여 수량 조회 → 1장 남음 → 구매 진행
[B 요청] 잔여 수량 조회 → 1장 남음 → 구매 진행
[A 요청] soldQuantity 1 증가 → soldQuantity = 1
[B 요청] soldQuantity 1 증가 → soldQuantity = 2  ← 수량이 1인데 2가 팔림

이것이 Lost Update 문제다. 두 트랜잭션이 같은 데이터를 읽고, 서로의 변경을 덮어쓴다.

해결 방법은 두 가지

1. 비관적 잠금 (Pessimistic Locking)

"누군가 이 데이터를 바꿀 것이다"고 가정하고, 읽는 시점부터 잠근다.

SELECT * FROM market_items WHERE id = 1 FOR UPDATE;

• 장점: 충돌이 절대 발생하지 않음
• 단점: 락을 기다리는 동안 다른 모든 트랜잭션이 블로킹됨 → 처리량 저하

2. 낙관적 잠금 (Optimistic Locking)

"충돌이 드물 것이다"고 가정하고, 잠금 없이 진행한다. 대신 쓸 때 "내가 읽은 이후로 데이터가 바뀌지 않았는지" 조건을 걸어서 검증한다.

충돌이 감지되면 → 에러를 던지거나 재시도한다.

포토카드 거래처럼 동시 구매 빈도가 낮고, 쓰기보다 읽기가 훨씬 많은 환경에 적합하다.

일반적인 낙관적 잠금: version 필드

교과서적인 낙관적 잠금은 테이블에 version 컬럼을 추가한다.

-- 테이블
ALTER TABLE market_items ADD COLUMN version INT DEFAULT 0;

// 읽을 때
const item = await prisma.marketItem.findUnique({ where: { id } });
// item.version = 3

// 쓸 때: version이 내가 읽은 값과 같을 때만 업데이트
const updated = await prisma.marketItem.updateMany({
  where: { id, version: item.version },  // 조건 검증
  data: {
    soldQuantity: { increment: 1 },
    version: { increment: 1 },           // 버전 증가
  },
});

if (updated.count === 0) {
  throw new Error('다른 사람이 먼저 구매했습니다. 다시 시도해주세요.');
}

updated.count === 0이면 다른 트랜잭션이 먼저 version을 올렸다는 뜻이다.

참고로 Prisma는 @version을 공식 지원하지 않는다 (GitHub 이슈 #4988). updateMany를 활용해서 직접 구현해야 한다.

우리 프로젝트의 구현: version 없이 비즈니스 조건으로 검증

version 컬럼 없이도 낙관적 잠금을 구현할 수 있다. 비즈니스 불변식(invariant)을 WHERE 조건에 직접 넣으면 된다.

구매 API의 orderRepository.purchase를 살펴보자.

재고 차감: soldQuantity 조건부 업데이트

// orderRepository.js
const updatedStock = await tx.marketItem.updateMany({
  where: {
    id: marketItemId,
    status: 'SELLING',
    quantity: marketItem.quantity,         // 내가 읽은 total quantity와 같아야 함
    pricePerCard: marketItem.pricePerCard, // 가격이 바뀌지 않아야 함
    soldQuantity: {
      lte: marketItem.quantity - quantity, // 아직 구매 가능한 수량이 남아있어야 함
    },
  },
  data: {
    soldQuantity: { increment: quantity },
  },
});

if (updatedStock.count === 0) {
  throw new AppError(
    '판매 가능한 카드 수량이 부족합니다.',
    409,
    ERROR_CODES.INSUFFICIENT_STOCK,
  );
}

핵심은 soldQuantity: { lte: marketItem.quantity - quantity } 조건이다.

• 내가 트랜잭션을 시작할 때 soldQuantity를 읽었다.
• 업데이트 시점에 이 조건이 만족하지 않으면 — 즉, 다른 트랜잭션이 먼저 재고를 줄였다면 — updateMany는 아무 행도 수정하지 않고 count: 0을 반환한다.
• count === 0을 체크해서 충돌을 감지하고 에러를 던진다.

이 방식의 장점은 비즈니스 의미가 명확하다는 것이다. "재고가 충분한 경우에만 차감한다"는 도메인 규칙이 코드에 그대로 드러난다.

포인트 차감: 잔액 조건부 업데이트

같은 원리가 포인트 차감에도 적용된다.

// 구매자 포인트 조건부 차감
const deductedPoint = await tx.userPoint.updateMany({
  where: {
    userId: buyerId,
    point: { gte: totalPrice }, // 잔액이 충분한 경우에만
  },
  data: {
    point: { decrement: totalPrice },
  },
});

if (deductedPoint.count === 0) {
  throw new AppError(
    '보유 포인트가 부족합니다.',
    409,
    ERROR_CODES.INSUFFICIENT_POINTS,
  );
}

point >= totalPrice 조건을 WHERE에 걸었기 때문에, 포인트가 부족한 상태에서는 절대 차감이 일어나지 않는다. 애플리케이션 레벨의 포인트 검증과 DB 레벨의 원자적 차감이 한 쿼리에서 동시에 이루어진다.

포인트 박스 시스템에도 동일한 패턴이 사용된다.

// pointRepository.js
const updated = await tx.userPoint.updateMany({
  where: {
    userId,
    OR: [
      { lastSpinAt: null },
      { lastSpinAt: { lte: availableBefore } }, // 쿨다운이 지난 경우에만
    ],
  },
  data: {
    point: { increment: amount },
    lastSpinAt: now,
  },
});

if (updated.count === 0) {
  return null; // 쿨다운 중 → 상위에서 PointBoxCooldownError
}

동시에 두 개의 포인트 박스 요청이 들어와도, 첫 번째 요청이 lastSpinAt을 갱신하면 두 번째 요청의 lastSpinAt: { lte: availableBefore } 조건이 실패해서 count: 0이 반환된다.

전체 트랜잭션 흐름

구매 로직은 하나의 $transaction 안에서 아래 순서로 실행된다.

$transaction 시작
  │
  ├─ 1. marketItem 조회 (status, quantity, soldQuantity, price 읽기)
  │
  ├─ 2. marketItem.soldQuantity 조건부 증가
  │      WHERE soldQuantity <= quantity - n   ← 낙관적 잠금 포인트 ①
  │      count === 0 → INSUFFICIENT_STOCK 에러
  │
  ├─ 3. myCard.quantity 조건부 감소 (판매자 카드 차감)
  │      WHERE quantity >= n                  ← 낙관적 잠금 포인트 ②
  │      count === 0 → INSUFFICIENT_STOCK 에러
  │
  ├─ 4. userPoint 조건부 차감 (구매자 포인트)
  │      WHERE point >= totalPrice            ← 낙관적 잠금 포인트 ③
  │      count === 0 → INSUFFICIENT_POINTS 에러
  │
  ├─ 5. 판매자 포인트 증가
  │
  ├─ 6. Order 생성
  │
  ├─ 7. 구매자 myCard upsert (카드 지급)
  │
  ├─ 8. PointLog 생성 (구매자 SPEND / 판매자 EARN)
  │
  └─ 9. soldQuantity === quantity면 status → SOLD_OUT
         + WAITING 상태 교환 신청 전부 REJECTED

각 단계에서 조건이 실패하면 트랜잭션 전체가 롤백된다. 한쪽 포인트만 차감되거나, 카드만 지급되는 부분 성공 상태가 존재하지 않는다.

Service 계층의 사전 검증은 왜 있을까?

orderService.js를 보면 트랜잭션에 진입하기 전에 이미 한 번 검증을 한다.

// orderService.js
const marketItem = await marketRepository.findMarketItemById(marketItemId);

if (!marketItem) {
  throw new AppError('판매글을 찾을 수 없습니다.', 404, ...);
}

if (marketItem.status !== 'SELLING') {
  throw new AppError('현재 판매 중인 포토카드가 아닙니다.', 409, ...);
}

if (marketItem.sellerId === buyerId) {
  throw new AppError('본인이 등록한 포토카드는 구매할 수 없습니다.', 409, ...);
}

트랜잭션 안에서도 같은 검증이 다시 일어나는데, 왜 Service에서 미리 할까?

이유는 사용자 경험과 DB 부하 때문이다.

• 존재하지 않는 상품 ID, 본인 상품 구매처럼 데이터 경쟁 없이 확정적으로 실패할 케이스는 트랜잭션을 열기 전에 빠르게 걸러낸다.
• 트랜잭션은 DB 커넥션을 점유하는 비싼 작업이다. 명백히 실패할 요청에 트랜잭션을 낭비할 필요가 없다.

반면 재고, 포인트처럼 동시성 경쟁이 발생할 수 있는 항목은 트랜잭션 내에서 조건부 업데이트로 다시 검증한다. Service의 사전 검증은 이 경우를 막아주지 못한다. Service가 읽은 값과 Repository가 실제로 쓰는 시점 사이에 데이터가 바뀔 수 있기 때문이다.

[Service] 재고 1 확인 → OK
          ↕ (이 사이에 다른 요청이 재고를 0으로 만듦)
[Repository] 트랜잭션에서 조건부 업데이트 → count: 0 → 에러

낙관적 잠금 vs 비관적 잠금 정리

포토카드 거래 플랫폼처럼 특정 상품에 동시 구매가 몰리는 경우는 드물기 때문에 낙관적 잠금이 적합하다.

단, 인기 아이돌의 한정판 포토카드처럼 수백 명이 동시에 구매를 시도한다면, 대부분의 요청이 충돌로 실패하게 된다. 이런 경우엔 Redis 기반 분산 락이나 Queue를 통한 직렬화 처리를 고려해야 한다.

정리

이 프로젝트에서 낙관적 잠금은 별도의 version 컬럼 없이 비즈니스 조건 자체를 WHERE 절에 넣는 방식으로 구현했다.

• soldQuantity <= quantity - n → 재고 초과 판매 방지
• point >= totalPrice → 포인트 음수 방지
• lastSpinAt <= availableBefore → 포인트 박스 중복 획득 방지

핵심은 단순하다. 읽은 값이 쓰는 시점에도 유효한지, 조건을 WHERE에 걸고 updateMany의 count로 검증한다. Prisma가 낙관적 잠금을 공식 지원하지 않아도, 이 패턴 하나로 동시성 문제를 충분히 방어할 수 있다.

이번에 시작하는 프로젝트에서는 API 요청 도구로 Axios를 사용하고, 서버 상태 관리를 위해 TanStack Query를 도입했다.

공통 에러 처리는 단순하게 API 요청 함수 내에서 처리하면 되는 작업이라고 생각할 수 있지만 화면이 늘어나고 API 요청이 많아졌기에 매번 직접 파싱하지 않는 방법을 찾고자했고, Axios를 사용하여 서버 에러 응답을 FE에서 사용하기 쉬운 에러 객체로 정규화하고 TanStack Query는 그 에러를 서버 상태의 일부로 관리하도록 했다.

Axios와 TanStack Query의 역할 분리

Axios와 TanStack Query는 모두 API 요청 과정에서 사용되지만, 담당하는 역할은 다르다

따라서 두 도구를 함께 사용할 때는 에러 처리 책임도 분리할 수 있다.

Axios에서는 서버 에러 응답을 프론트엔드에서 사용하기 쉬운 형태로 가공하고, TanStack Query에서는 가공된 에러 객체를 error 상태로 관리한다.

Backend Error Response
↓
Axios Response Interceptor
↓
Error Code 추출
↓
Frontend Error 객체로 정규화
↓
TanStack Query error 상태로 전달
↓
Component UI 처리

이 구조를 사용하면 컴포넌트에서 매번 서버 응답 구조를 직접 확인하지 않아도 된다.

컴포넌트는 TanStack Query가 전달한 error 객체를 기준으로 화면에 필요한 처리를 담당하면 된다.

BE 에러 응답 포맷

{
  "success": false,
  "code": "PHOTO_CARD_NOT_FOUND",
  "message": "Photo card not found"
}

이전 프로젝트와 동일하게

로 처리하였다.

포인트는 FE에서 message가 아닌 code를 기준으로 에러를 처리한다는 점 즉, 서버의 message는 개발자가 에러 상황을 확인하기 위한 값이고, 사용자에게 보여줄 문구는 FE에서 code를 기준으로 매핑한다.

Axios intercepter에서 에러 객체 정규화

백엔드에서 공통 응답을 내려주더라도, 각 컴포넌트에서 매번 error.response.data.code에 접근해 메시지를 매핑하면 같은 로직이 반복된다.

그래서 Axios Response Interceptor에서 서버 에러 응답을 한 번 가공하기로 했다.

Interceptor에서는 서버 응답에서 code를 추출 → 해당 코드에 맞는 사용자 메시지를 찾아 에러 객체에 추가한다.

api.interceptors.response.use(
  (response) => response,

  (error) => {
    const code = error.response?.data?.code;

    error.code = code;
    error.userMessage = getErrorMessage(code);

    return Promise.reject(error);
  }
);

이렇게 하면 이후 API 요청을 사용하는 쪽에서는 서버 응답 구조를 직접 알 필요가 없다.

try {
  await createPhotoCard(data);
} catch (error) {
  console.log(error.userMessage);
}

즉, Axios Interceptor는 서버에서 내려온 에러 응답을 프론트엔드에서 다루기 쉬운 형태로 정규화하는 역할을 한다.

# 흐름 정리
server response
{
  success: false,
  code: "INSUFFICIENT_POINT",
  message: "Not enough point"
}

↓ Axios Response Interceptor

frontend error
{
  code: "INSUFFICIENT_POINT",
  userMessage: "포인트가 부족합니다."
}

TanStack Query에서 에러 상태 다루기

TanStack Query는 queryFn 또는 mutationFn에서 발생한 에러를 error 상태로 관리한다.

이때 중요한 점은 함수 내부에서 에러가 발생하거나 rejected promise가 반환되어야 TanStack Query가 에러 상태로 인식한다는 것이다.

Axios는 HTTP 실패 응답을 자동으로 rejected promise로 처리한다. 따라서 Axios Interceptor에서 에러 객체를 가공한 뒤 Promise.reject(error)로 반환하면, TanStack Query는 이 에러를 그대로 error 상태에 담아준다.

const { data, error, isError } = useQuery({
  queryKey: ["photoCards"],
  queryFn: getPhotoCards,
});

if (isError) {
  console.log(error.userMessage);
}

Mutation에서도 같은 방식으로 에러를 다룰 수 있다.

const mutation = useMutation({
  mutationFn: createPhotoCard,
  onError: (error) => {
    console.log(error.userMessage);
  },
});

이후 각 화면에서 error.userMessage를 사용해 Toast, Modal, Form Error 등 상황에 맞는 UI 처리를 선택하면 된다.

정리

Axios
- HTTP 요청 수행
- Response Interceptor에서 Error Code 추출
- 사용자 메시지 매핑
- 에러 객체 정규화

TanStack Query
- queryFn / mutationFn 실행
- loading / error 상태 관리
- retry / refetch 관리
- 정규화된 error 객체 전달

즉 핵심은

Axios Interceptor는 에러를 가공하는 계층이고, TanStack Query는 에러 상태를 관리하는 계층이다.

다음은 이걸 활용하여 컴포넌트 UI를 작성해보겠다.

이 글은 Tailwind CSS v4 기준으로 작성되었다.

기존 CSS 작성 방식

처음 React를 공부할 때는 일반 CSS 방식으로 스타일을 작성했다.

<button className="btn-primary">버튼</button>

.btn-primary {
  background-color: blue;
  padding: 8px 16px;
  border-radius: 8px;
}

이 방식은 가장 익숙하고 이해하기에는 쉬웠다.

하지만 프로젝트가 커질수록 몇 가지 불편한 점이 있다

• 클래스 이름을 계속 고민해야 함
• css 파일 이동이 많아짐
• 스타일 충돌 가능성 존재
• 어디에서 사용되는 클래스인지 찾기 어려움

그래서 이후에는 CSS Module이나 styled-components 방식도 사용해보게 되었다.

Tailwind를 처음 접하였을 때

솔직히 처음에는 코드가 오히려 복잡해보였다.

<button className="bg-blue-500 px-4 py-2 rounded text-white"> 버튼 </button>

스타일이 전부 className 안에 들어가 있다 보니 HTML이 너무 길어 보인다는 느낌도 있었다. "오히려 더 불편하지않은가?" 라는 생각도 들었지만 현업에서 많이 사용하는 이유를 찾아보고자 더 공부해보려고 마음먹었다.

Tailwind의 장점

빠른 UI 개발

Tailwind는 미리 정의된 utility class를 조합해서 스타일을 작성하는 방식이다.

<div className="p-4 bg-white rounded-lg shadow-md">

기존 CSS처럼

• CSS 파일 생성
• 클래스 이름 작성
• 다시 컴포넌트로 이동

과정을 반복하지 않아도 되기 때문에 빠르게 화면을 구성할 수 있다는 장점이 있다고 한다.

특히 프로토타입 제작이나 초기 UI 작업 속도가 빠르다는 의견이 많았다.

class명 고민 ❌

기존 CSS에서는 스타일을 만들 때마다 이름을 계속 지어야 했다.

.container {} .wrapper {} .box {} .card {}

프로젝트가 커질수록 이름이 겹치거나, 어떤 역할인지 애매해지는 경우도 있었다.

하지만 Tailwind는 이미 정의된 utility class를 조합하는 방식이라 이런 고민이 줄어든다고 한다.

전역 클래스 명 충돌 걱정 감소

기존 CSS는 전역 스타일 충돌 문제가 자주 발생한다. 특히 여러 사람이 함께 작업하는 프로젝트에서는 같은 클래스 이름을 사용하는 상황도 생길 수 있다.

Tailwind는 필요한 utility class를 직접 조합해서 사용하는 방식이기 때문에, 전역 클래스 이름이 겹칠 걱정이 상대적으로 줄어든다는 장점이 있다. (CSS Module이나 styled-components처럼 스코프를 완전히 격리해주는 방식은 아니지만, 클래스 이름 충돌로 인한 문제는 훨씬 덜 발생한다.)

반응형 작업에 용이

Tailwind는 반응형 스타일을 쉽게 작성할 수 있도록 breakpoint 문법을 제공한다.

<div className="text-sm md:text-lg lg:text-2xl">

별도의 media query를 작성하지 않아도 되기 때문에 반응형 UI를 빠르게 적용할 수 있다는 점이 많이 언급되었다.

React / Next.js 생태계와 좋은 궁합

최근 React 기반 프로젝트에서는 Tailwind를 사용하는 경우가 많다고 한다.

특히

• Next.js
• shadcn/ui
• Vercel 기반 프로젝트

등 최신 React 생태계와 함께 자주 사용된다는 점도 특징이라고 느꼈다.

컴포넌트 기반 개발 방식과 utility class 방식이 잘 어울린다는 의견도 많았다.

디자인 규칙 유지

Tailwind는 spacing, color, size 등이 일정한 규칙 안에서 제공된다.

그래서 프로젝트 전체에서 디자인 스타일을 통일하기 쉽다는 장점이 있다고 한다.

여러 명이 함께 작업할 때 UI 일관성을 유지하는 데 도움이 된다는 글들도 많이 볼 수 있었다.

현업에서 자주 쓰이는 cn() 패턴

현업 React + Tailwind 코드를 보면 아래와 같은 패턴이 자주 등장한다.

import { clsx } from "clsx";
import { twMerge } from "tailwind-merge";

export function cn(...inputs) {
  return twMerge(clsx(inputs));
}

<button className={cn("px-4 py-2 rounded", isActive && "bg-blue-500", "bg-gray-200")}>
  버튼</button>

• clsx는 조건부 클래스를 깔끔하게 처리해주고
• tailwind-merge는 충돌하는 클래스를 자동으로 합쳐준다

shadcn/ui 같은 라이브러리에서도 이 패턴을 기본으로 사용하고 있어서, Tailwind를 실제로 사용하게 된다면 함께 알아두면 좋을 것 같다.

Tailwind v4에서 달라진 점

2025년 초에 Tailwind CSS v4가 정식 릴리즈되면서 설정 방식이 꽤 달라졌다. 공식 문서를 보면서 따라할 때 버전 차이로 혼란스러울 수 있으니 알아두면 좋다.

Tailwind가 무조건 정답일까?

여러 자료를 찾아보면서 Tailwind가 무조건 모든 프로젝트의 정답은 아니라는 의견도 많았다.

대표적인 단점과 함께, 현업에서 어떻게 대응하는지도 정리해보았다.

그래서 프로젝트 규모나 팀 스타일에 따라

• 일반 CSS
• CSS Module
• styled-components
• Tailwind

중 적절한 방식을 선택하는 것이 중요하다고 느꼈다.

처음에는 단순히 “요즘 많이 사용하는 CSS 방식” 정도로 생각했다.

하지만 여러 자료를 찾아보면서 Tailwind는 단순 유행이라기보다 빠른 UI 개발과 유지보수를 고려한 방식이라는 점을 조금 이해할 수 있었다.

아직 직접 많이 사용해보지는 않았지만, 앞으로 React와 Next.js 프로젝트를 진행하면서 Tailwind를 직접 사용해보고 장단점을 더 체감해보고 싶다.

습관 관리 프로젝트에서 "습관 삭제" 기능을 구현하다가 뜻밖의 고민에 빠졌다. 처음엔 당연히 DELETE 쿼리를 쓰면 된다고 생각했는데, 막상 구현하려고 보니 두 가지 문제가 걸렸다.

첫 번째. 습관을 삭제하면 연결된 체크 기록(habitLogs)이 cascade로 함께 날아간다. 사용자가 한 달 동안 쌓아온 기록이 습관 하나 삭제로 전부 사라지는 건 말이 안 됐다.

두 번째. UX 문제였다. 오늘 아침에 이미 체크한 습관을 낮에 삭제했는데 목록에서 즉시 사라지면 어색하다. "삭제했으니 오늘은 유지되고, 내일부터 안 보이는" 동작이 훨씬 자연스럽다.

이 두 가지 이유로 Soft Delete를 선택했다.

Hard Delete vs Soft Delete

먼저 개념부터 정리하자.

Hard Delete는 DELETE 쿼리로 DB에서 행을 완전히 제거하는 방식이다. 구현이 단순하고 DB를 깔끔하게 유지할 수 있다. 하지만 한 번 지우면 복구가 어렵고, 연관 데이터까지 함께 사라질 수 있다.

Soft Delete는 실제로 삭제하지 않고 "삭제됐다"는 표시만 남기는 방식이다. 행은 DB에 그대로 있고, deletedAt이나 isDeleted 같은 필드로 상태를 관리한다.

스키마 설계: isDeleted가 아니라 endAt을 선택한 이유

Soft Delete를 구현할 때 가장 먼저 결정해야 할 건 어떤 필드로 상태를 표현할 것인가다. 흔히 isDeleted: Boolean 방식을 많이 쓴다. 직관적이고 간단하다. 그런데 이 프로젝트에선 endAt: DateTime?을 선택했다.

이유는 하나다. 삭제 여부뿐만 아니라 삭제 시점도 함께 남길 수 있기 때문이다.

• isDeleted: true → "지워졌다"는 사실만 알 수 있다
• endAt: 2024-11-15 → "언제 지워졌는지"까지 알 수 있다

게다가 이 프로젝트에서 핵심 요구사항이 "삭제 당일은 목록에 유지되고, 다음 날부터 제외"였기 때문에, 날짜 기반 필드가 훨씬 다루기 쉬웠다.

model Habit {
  id        Int       @id @default(autoincrement())
  studyId   Int       @map("study_id")
  habitName String    @map("habit_name")
  startAt   DateTime  @map("start_at")
  endAt     DateTime? @map("end_at")  // null이면 활성, 값이 있으면 종료
  // ...
}

null이면 현재 활성 상태, 값이 있으면 해당 날짜에 종료된 습관이다.

삭제 처리: DELETE 대신 UPDATE

실제 삭제 로직은 단순하다. DELETE 대신 endAt을 오늘 날짜로 업데이트한다.

jsexport const deleteHabit = async (studyId, habitId) => {
  const habit = await prisma.habit.findFirst({
    where: { id: habitId, studyId },
  });

  if (!habit) throw new HabitNotFoundError();

  // 이미 종료된 습관은 다시 삭제 불가
  if (habit.endAt !== null) {
    throw new BadRequestError("이미 종료된 습관은 삭제할 수 없습니다.");
  }

  // 실제 삭제 대신 endAt을 오늘 날짜로 설정
  await prisma.habit.update({
    where: { id: habitId },
    data: { endAt: getTodayKST() },
  });
};

한 가지 주의할 점은 if (habit.endAt !== null) 체크다. 이미 종료된 습관에 다시 삭제 요청이 들어왔을 때 멱등하게 처리하거나(아무것도 안 함), 아니면 에러를 던질 수 있다. 이 프로젝트에서는 "이미 종료된 습관"이라는 상태를 명확히 알려주는 게 낫다고 판단해서 에러를 던졌다.

getTodayKST()는 UTC 기준 날짜 밀림 문제를 방지하기 위해 KST 기준으로 오늘 날짜를 반환하는 유틸 함수다. 한국 서비스라면 이 부분이 꽤 중요하다. (별도 포스팅으로 정리 예정)

조회 필터링: 삭제 당일을 목록에 유지하는 법

Soft Delete에서 가장 신경 써야 할 부분이 조회 쿼리다. 조건을 빠뜨리면 삭제된 데이터가 그대로 노출된다. 이 프로젝트의 요구사항은 이랬다:

삭제 당일은 목록에 유지되고, 다음 날부터 자동으로 제외된다.

이를 구현한 조회 조건은 다음과 같다.

const habits = await prisma.habit.findMany({
  where: {
    studyId,
    startAt: { lte: now },
    OR: [
      { endAt: null },           // 종료일이 없는 활성 습관
      { endAt: { gt: today } },  // 종료일이 오늘보다 미래인 습관 (삭제 당일 포함)
    ],
  },
  include: {
    habitLogs: {
      where: { logDate: today },
    },
  },
});

endAt: { gt: today } 조건이 핵심이다. endAt이 오늘과 같은 날짜라면 이미 gt 조건에서 걸러지기 때문에, 삭제 당일은 목록에 포함되고 그 다음 날부터 제외된다.

조건을 정리하면 이렇다:

실제로 cascade는 어떻게 됐을까?

처음 고민의 시작이었던 cascade 문제로 돌아가보자.

Soft Delete를 쓰면 부모 행(Habit)이 실제로 삭제되지 않기 때문에, DB에 설정된 onDelete: Cascade가 동작하지 않는다. 덕분에 habitLogs는 안전하게 보존된다. 다만 여기서 한 가지 확인해야 할 게 있다.

Soft Delete 상태의 부모에 연결된 자식 데이터를 조회할 때, 자식 쿼리에서도 부모의 soft delete 상태를 체크하는지 확인해야 한다. 이 프로젝트에서는 항상 habitId를 기준으로 조회하고, 습관 자체의 활성 여부는 습관 목록 조회 단계에서 필터링하기 때문에 문제가 없었다.

Soft Delete의 단점도 솔직하게

장점만 있는 건 아니다. Soft Delete를 선택할 때 감수해야 할 것들도 있다.

DB에 데이터가 계속 쌓인다. 삭제해도 행이 남아있으니 테이블이 계속 커진다. 서비스 규모가 커지면 일정 기간이 지난 종료 데이터를 주기적으로 정리하는 배치 작업이 필요하다.

조회 쿼리마다 조건을 추가해야 한다. 깜빡하고 endAt 조건을 빠뜨리면 삭제된 데이터가 그대로 노출된다. 팀 전체가 이 규칙을 공유하고 있어야 하고, ORM 레벨에서 글로벌 스코프로 자동 적용하는 방법도 고려해볼 수 있다. Prisma에서는 middleware 또는 $extends를 활용할 수 있다.

언제 써야 할까?

Soft Delete가 항상 정답은 아니다.

이 프로젝트처럼 사용자의 행동 기록이 핵심 가치인 서비스라면 Soft Delete가 더 안전한 선택이다. 데이터는 복구할 수 있지만, 한 번 날린 신뢰는 복구하기 어렵다.

언뜻 단순해 보이는 기능이었지만 테스트하다가 이상한 점을 발견했다.

버그 발견

두 가지 이상의 항목을 수정한 뒤 수정 완료를 눌렀더니, 마지막 항목만 저장되고 이전에 수정한 내역들은 반영이 되지 않았다.

원인 분석

코드에 이유가 있었다.

// 기존 코드
const [editingHabitId, setEditingHabitId] = useState(null);
const [editingValue, setEditingValue] = useState("");

editingHabitId는 현재 포커스된 항목 하나의 ID만 기억한다. 그렇기에 수정 후 다른 항목을 수정하면서 포커싱이 옮겨지면 editingHabitId가 덮어씌워지고, 이전 변경사항은 상태에 남아있지 않게 되는 것이다.

"수정 완료"로직도 마찬가지였다.

// editingHabitId 하나만 저장 → 마지막으로 편집한 항목만 API 호출
if (editingHabitId !== null && editingValue.trim() !== originalHabitName) {
  await editHabit(editingHabitId, editingValue.trim());
}

결국 저장할 수 있는 건 editingHabitId 하나뿐이니, 마지막으로 클릭한 항목만 전송됐던 것이다.

해결 방향

이것을 해결하기 위해 여러 방안을 모색해봤지만 별다른 수가 떠오르지 않았고 생각해낸 방법은 "수정 완료를 누르기 전까지 모든 변경사항을 어딘가에 쌓아두면 좋겠다"였다.

항목 하나를 추적하는 editingHabitId대신, 변경된 모든 항목을 담는 객체를 도입해보기로 했다.

// { [habitId]: 수정된 이름 } 형태로 누적
stagedEdits = {
  1: "운동하기 (수정됨)",
  3: "물 마시기 (수정됨)",
}

스테이징의 의미처럼 아직 서버에는 반영되지 않은, 저장 직전 상태를 나타내기 위해 stagedEdits로 변수명을 정했다.

API가 항목 하나씩만 받더라도 문제없었다. Promiss.all로 병렬 호출하면 여러 항목을 동시에 전송할 수 있다.

// PATCH /habits/1
// PATCH /habits/3   → 세 요청이 동시에 전송됨
// PATCH /habits/5
await Promise.all(editPromises);

구현

① stagedEdits 상태 추가

const [stagedEdits, setStagedEdits] = useState({});

② 편집값이 바뀔 때마다 누적

jsconst handleEditChange = (habitId, value) => {
  setEditingValue(value);  // 인풋 표시용 (기존 유지)
  setStagedEdits((prev) => ({ ...prev, [habitId]: value }));  // 변경사항 누적
};

③ 수정 완료 시 stagedEdits 전체를 API로 전송

jsconst handleConfirm = async () => {
  const editPromises = Object.entries(stagedEdits)
    .filter(([, name]) => name.trim())
    .map(([id, name]) => editHabit(Number(id), name.trim()));

  await Promise.all(editPromises);
  setStagedEdits({});  // 저장 후 초기화
};

파생 버그 - 수정한 내용이 화면에서 사라진다

이렇게 수정 후 테스트를 진행해보니 먼저 수정한 습관 이후에 다른 습관으로 포커싱을 옮겨 수정하려고하면 화면에는 이전 이름이 다시 나타났다.

stagedEdits에는 잘 저장되어있는데, 화면만 초기화된 것이다.

원인은 각 항목이 편집 모드에서 벗어날 때 habit.habitName(서버의 원본값)을 그대로 표시하기 때문이었다.

// 편집 모드가 아닐 때 원본값만 표시 → staged된 값이 무시됨
<span>{habit.habitName}</span>

서버 데이터는 아직 바뀌지 않았으니 어쩌면 당연한 결과였다. stagedEdits에 값이 있으면 그걸 우선 보여주도록 수정했다.

// 부모 컴포넌트 — stagedName prop 추가
<HabitItem
  stagedName={stagedEdits[habit.id]}
  ...
/>

// HabitItem — staged 값이 있으면 우선 표시, 없으면 원본
<span>{stagedName ?? habit.habitName}</span>

항목으로 다시 돌아올 때도 이전 편집값이 복원되어야 한다.

const handleEditStart = (habit) => {
  setEditingHabitId(habit.id);
  // stagedEdits에 값이 있으면 복원, 없으면 원본값으로 시작
  setEditingValue(stagedEdits[habit.id] ?? habit.habitName);
};

파생 버그 - 삭제한 항목에 API가 호출된다

항목을 삭제한 뒤 "수정 완료"를 눌렀더니 에러가 발생했다. 삭제한 항목의 ID가 stagedEdits에 그대로 남아있어, 이미 존재하지 않는 항목에 PATCH 요청이 날아갔기 때문이었다.

삭제 시 stagedEdits도 함께 정리하면 해결된다.

jsconst handleDelete = async (habitId) => {
  await removeHabit(habitId);

  setStagedEdits((prev) => {
    const next = { ...prev };
    delete next[habitId];  // 삭제한 항목은 stagedEdits에서도 제거
    return next;
  });
};

최종 흐름

"운동하기" 클릭 → "헬스" 입력
→ stagedEdits = { 1: "헬스" }

"물 마시기" 클릭 → "운동하기"는 화면에 "헬스"로 유지
→ "물 2L" 입력
→ stagedEdits = { 1: "헬스", 3: "물 2L" }

수정 완료 클릭
→ PATCH /habits/1, PATCH /habits/3 동시 호출
→ 둘 다 저장 ✅

처음에는 단순한 버그처럼 보였지만, 고치는 과정에서 파생 버그가 두 번이나 더 나왔다. 공통된 원인은 하나였다. "저장 전 클라이언트 상태"를 명확하게 설계하지 않으면 화면과 실제 데이터가 어긋난다.

stagedEdits 패턴은 할 일 목록, 설정 화면, 인라인 편집이 있는 어떤 UI에서라도 응용할 수 있다고 한다. 다음에 비슷한 UX를 구현하게 된다면 이 구조를 떠올려봐야겠다.

페이지의 흐름은 아래와 같다.

생성된 스터디(studyId)에 대해 비밀번호를 입력하고 일치하면 '오늘의 습관'페이지로 이동할 수 있다.

하지만 로그인 기능이 없는 상태였기에 다음과 같은 문제가 발생했다.

• URL 직접 접근
• 새로고침 시 비밀번호 재입력 여부

이 글에서는 위 문제를 해결하기 위해 어떤 구조를 설계했고, 그 과정에서 어떤 시행착오를 겪었는지 정리해보겠다.

구조

우선 연관된 페이지의 기능 구조는 아래와 같다.

Study 페이지

• 스터디 단위의 페이지
• 각 스터디는 studyId(PK)와 비밀번호(password)를 가진다.

오늘의 습관 페이지

• 각 스터디에 속한 "오늘의 습관" 관리 페이지

스터디 페이지에서 비밀번호 인증 후 오늘의 습관 페이지로 이동하는 구조

문제 해결 접근 방법

1. 비밀번호를 계속 사용

가장 먼저 떠올린 방법은 비밀번호를 계속 들고 다니면서 요청마다 검증하는 방식이었다. 하지만 매 요청마다 비밀번호를 처리해야하는 것은 상당히 비효율적이라 생각해 다른 방식을 찾아보았다.

2. 단순 인증 여부만 저장

다음으로 생각한 방법은 비밀번호를 입력하여 입장에 성공하였을 때, 인증 여부만 저장하는 것이었다. 그런데 이렇게 하면 어떤 스터디에 대한 인증인지 구분할 수 없어 제대로 관리가 되지 않을 수 있다.

3. studyId를 저장하는 방식

비밀번호 인증 후 studyId를 세션에 담아 url과 일치하는지를 비교하여 인증 여부를 판단하는 것을 떠올렸다.

이 경우 다른 스터디로 이동하면 어떻게 해야할 지 해결이 되지 않았다.

최정 해결 방법: Session을 활용한 study 단위 인증 상태를 관리

앞서 고민했던 방식들의 공통 문제는 두 가지였다.

1. 인증 상태를 어떻게 유지할 것인지 (새로고침 시 인증 유지)
2. 인증되지 않은 사용자가 URL을 직접 입력했을 때, 이를 어떻게 막을 것인지(url 직접 접근)

Session 사용

인증 상태를 유지하는 방법으로

• localStorage에 저장
• 매 요청마다 비밀번호 입력
• Session 사용

이렇게 세 가지를 떠올렸고, session을 선택한 이유는 다음과 같다.

인증 상태를 서버에서 안전하게 관리 가능

• 비밀번호를 저장하지 않아도 됨
• 인증 결과만 서버에 담아둠

보안 측면에서 유리

새로고침 시에도 상태 유지 가능

• session은 서버에 저장되기에 브라우저는 sessionId를 쿠키로 유지

추가 요청 없이 인증 상태 확인 가능

• 매 요청마다 비밀번호를 다시 확인할 필요가 없음

Session 구조

req.session.auth = {
    [studyId]: true
};

: 해당 스터디에 대해 인증이 완료 됨

인증 흐름

1️⃣ 비밀번호 인증

if (password가 일치하면) { req.session.auth[studyId] = true; }

2️⃣ 이후 요청 처리

if (!req.session.auth?.[studyId]) { return res.status(403); }

이후 매 요청에서 session을 통하여 인증 상태를 확인하고 인증 상태는 스터디 단위로 관리한다

session을 처음 사용해보기에 session에 담는 값을 통하여 인증 상태를 관리하는 구조를 처음 접해보고 이해해보며 글을 정리해본다.

그래서! 다시 정리해서 기록해두고자 한다.

DB

관계형 데이터베이스

데이터를 테이블(표) 형태로 저장하는 구조

like Excel

• 테이블 -> 시트
• 행(Row) -> 데이터 한 줄
• 열(Column) -> 데이터 항목

이것들이 서로 연관을 지어있기에 이를 관계형 데이터베이스라 한다.

Primary Key (PK)

각 데이터를 구분하는 고유한 값

📍 중복 불가능
📍 NULL 불가능
❗ 테이블당 하나 존재

으로 이것은 데이터를 식별하는 기준이 된다.

Foreign Key (FK)

Foreign key는 다른 테이블의 PK를 참조하는 값이다.

예를 들어 하나의 게시글을 두고, 이 게시글이 어떤 사용자의 게시글인지는 users.id를 보면 알 수 있다.

테이블 간 연결을 해주며 데이터의 일관성을 유지하는 역할을 한다.

참조 무결성

이런 Foreign Key에서 중요한 개념으로 참조 무결성이 있다.

FK는 반드시 존재하는 PK만 참조할 수 있다

이것은 존재하는 값들만 사용이 가능하다는 의미이고, 잘못된 데이터 연결을 막아준다

관계 (Relationship)

관계는 테이블과 테이블 사이의 연결 구조를 의미한다.

🔗 1 : N (일대다)

가장 많이 사용하는 관계

→ 한 명의 사용자가 여러 개의 게시글을 가질 수 있다

🔗 N : 1 (다대일)

→ 여러 게시글은 하나의 사용자에 속한다

🔗 N : N (다대다)

→ 여러 개가 서로 여러 개와 연결되는 구조

사용자 ↔ 태그
학생 ↔ 수업

이 경우 중간 테이블이 필요하다.

제약 조건 (Constraints)

기본 개념에 대해 알아보았고 이제 제약 조건에 대해 알아보고자 한다

제약조건이라함은

잘못된 데이터가 들어오는 것을 막기 위한 규칙
즉, 데이터의 정확성과 일관성을 유지하기 위한 장치

대표적인 제약 조건들을 정리해서 보겠다.

제약 조건

예시를 살펴보자.

실습 과제로 나왔던 온라인 강의 플랫폼 테이블 구조 설계다.

요구사항
**요구사항:**

- 수강생은 이름, 이메일, 가입일 정보를 가진다
- 강사는 이름, 이메일, 소개글, 전문 분야 정보를 가진다
- 강의는 제목, 설명, 가격, 카테고리, 생성일 정보를 가지며, 한 명의 강사가 여러 강의를 만들 수 있다
- 수강생이 강의를 결제하면 수강 등록이 되고, 등록일과 결제 금액이 기록된다
- 수강생은 수강 중인 강의에 별점(1~5)과 텍스트 리뷰를 남길 수 있다
- 한 수강생이 같은 강의에 리뷰를 중복으로 남길 수 없다

**설계 조건:**

- PK, FK 명시
- UNIQUE 제약조건이 필요한 곳을 찾아서 적용
- DEFAULT 값이 적절한 곳에 설정

수강생

강사

강의

수강 / 결제

리뷰

정답이 맞는지는 모르지만, 이런 식으로 개념과 제약 조건을 사용해보았다.

Prisma

Prisma는 ORM으로, 객체를 스키마(schema)로 정의한 다음 그 객체와 내가 선택한 데이터베이스를 연결시켜주는 매개체이다.

ORM은 무엇인가

여기서 처음 듣는 단어인 ORM이 무엇인지에 대해 짚고 넘어가보자 ORM은 👉 데이터베이스를 코드(객체)처럼 다루게 해주는 개념이다.

기존 방식에서는 DB에 접근할 때 SQL을 직접 작성해야 했다. '어떤 데이터를 어떻게 가져올지'를 쿼리로 직접 표현했던 반면 ORM을 사용하면 DB를 직접 다루는 대신 코드에서 정의한 모델을 기준으로 데이터를 다룬다.

SQL 방식 → DB 중심
ORM 방식 → 코드(객체) 중심

즉, ORM은 DB를 다루는 방식을 "쿼리"에서 "객체"로 바꿔주는 역할을 한다. 이로 인하여 SQL 작성 부담이 줄어들고, 코드 흐름 안에서 데이터를 다룰 수 있게 되는 것이다.

Prisma의 역할

ORM의 개념에 대해 정리를 해보았고, 다시 돌아와 Prisma를 보자. Prisma는 그것을 실제로 사용할 수 있게 해주는 도구이다

단순히 DB에 연결하는 역할이 아닌

• DB 구조를 코드로 정의하고
• 그 구조를 실제 DB와 연결해주는 역할을 한다.

그럼 어떻게 연결을 해줄까?

Prisma의 흐름

1. schema로 구조 정의
2. DB에 반영
3. 코드에서 사용

1. 구조 정의 (schema)

먼저 schema.prisma 파일에서 DB 구조를 정의한다.

이곳에서

• 테이블(model)
• 필드
• 관계 전부 코드로 작성한다.

2. DB 반영 (migration)

schema를 작성한 뒤에 이 내용을 실제 DB에 반영해야 한다.

이 과정을 migration이라고 한다.

• 코드로 정의한 구조를 실제 DB에 적용하는 단계

3. 코드에서 사용 (Prisma Client)

DB가 생성되면 이제 Prisma Client를 통해 데이터를 다룬다.

예를 들어 User 데이터를 조회한다고 하면

import { PrismaClient } from "@prisma/client";

const prisma = new PrismaClient();

async function getUsers() {
  const users = await prisma.user.findMany();
  console.log(users);
}

getUsers();

• user라는 모델을 기준으로 findMany() 메서드를 호출해서 데이터를 가져온다.

또 다른 예시로 데이터를 생성할 수도 있다.

await prisma.user.create({
  data: {
    email: "test@test.com",
  },
});

• 이런 식으로 SQL 없이도 데이터를 조회하고 생성할 수 있다.

Prisma를 다시 정리해보면,

코드로 DB 구조 정의 → DB에 반영 → 코드로 데이터 사용

SQL을 대신하여 코드로 작업할 수 있게 해준다는 점에서 마음에 들기도 했다.

하지만 가장 중요한 데이터베이스 관련 개념이 정리되어있지 않으면 제대로 사용할 수 없기에 이것에 대한 복습도 필요해보인다.

데이터베이스를 설계하다 보면 '데이터베이스를 나누는 기준'에 대한 고민이 생긴다. 이걸 정립해주는 개념이 정규화(Normalization)이다.

정규화란

데이터의 중복을 줄이고, 이상 현상을 방지하기 위해 테이블을 구조적으로 나누는 과정

정규화를 해야하는 이유

정규화를 하지 않았을 경우 발생하는 문제에 대해서 살펴보자.

❌ 1. 중복 데이터 발생

학생 | 과목 | 교수
------------------
A    | DB   | Kim
A    | OS   | Lee

👉 학생 A가 여러 번 반복됨

❌ 2. 수정 이상 (Update Anomaly)

교수 이름이 바뀌면?

👉 모든 행을 다 수정해야 한다

→ 하나라도 빠지면 데이터 불일치 발생

❌ 3. 삽입 이상 (Insert Anomaly)

새로운 과목을 추가하려는데 학생이 없다면?

👉 데이터를 넣을 수 없음

❌ 4. 삭제 이상 (Delete Anomaly)

학생 A를 삭제하면?

👉 해당 과목 정보까지 같이 사라짐

이러한 문제 발생을 방지하기 위하여 정규화를 사용한다.

정규화의 목적

정규화는 단순히 테이블을 나누는 것이 아니다.

데이터를 일관성 있고 효율적으로 관리하기 위한 구조를 만드는 과정이다.

• 데이터 중복 제거
• 이상 현상 방지 (Update / Insert / Delete)
• 데이터 무결성 유지
• 유지보수 용이성 향상

정규화 과정

정규화는 단계적으로 진행되며, 일반적으로 제3정규형(3NF)까지 적용한다.

1️⃣ 제1정규형 (1NF)

👉 모든 컬럼은 원자값(Atomic Value)을 가져야 한다

❌ 정규화 전

학생 | 전화번호
------------------------
A    | 010-1111, 010-2222

👉 하나의 컬럼에 여러 값이 존재

✅ 정규화 후

학생 | 전화번호
------------------------
A    | 010-1111
A    | 010-2222

👉 하나의 컬럼에는 하나의 값만 존재

2️⃣ 제2정규형 (2NF)

부분 함수 종속 제거

👉 기본키의 일부에만 의존하는 컬럼 제거

❌ 정규화 전

학생ID | 과목ID | 학생이름
---------------------------
1       | DB     | Kim
1       | OS     | Kim

👉 학생이름은 학생ID에만 의존

✅ 정규화 후

학생 테이블
학생ID | 이름
------------
1      | Kim

수강 테이블
학생ID | 과목ID
-------------
1      | DB
1      | OS

👉 테이블을 분리하여 중복 제거

3️⃣ 제3정규형 (3NF)

이행 함수 종속 제거

👉 기본키가 아닌 컬럼이 다른 컬럼에 의존하는 경우 제거

❌ 정규화 전

학생ID | 학과ID | 학과명
-------------------------
1      | 10     | 컴퓨터공학

👉 학과명은 학과ID에 의존

✅ 정규화 후

학생
학생ID | 학과ID

학과
학과ID | 학과명

👉 관계를 분리하여 구조 개선

하지만 이런 정규화에도 한계는 있다. 너무 많이 나누게 되면

• JOIN 증가
• 쿼리 성능 저하
• 구조 복잡도 증가

이런 경우에는 반정규화(Denormalization)를 고려하기도 한다.

React에서 배열을 랜더링 하는 코드는 자주 사용된다.

예를 들어 간단한 리스트를 출력한다고 해보자.

const items = ["Apple", "Banana", "Cherry"];

function App() {
  return (
    <ul>
      {items.map((item) => (
        <li>{item}</li>
      ))}
    </ul>
  );
}

이 코드는 정상적으로 동작하지만, 콘솔을 보면 이런 경고가 뜬다.

Each child in a list should have a unique "key" prop.

왜 이러한 경고가 발생하는 것일까? React의 랜더링 방식을 다시 살펴보면 알 수 있다.

React는 상태가 변경될 때마다 이전 화면과 새로운 화면을 비교해서 바뀐 부분만 업데이트한다.

그런데 key가 없다면 React는 '이 요소가 이전에 있던 그 요소가 맞는지'에 대하여 정확히 판단할 수 없다.

const items = ["A", "B", "C"];

이렇게 key가 없을 때는

{items.map((item) => (
  <li>{item}</li>
))}

이 상태에서 "A"가 삭제되면

["B", "C"]

React는 단순히 순서 기준으로 비교하기에

A → B (변경됨)
B → C (변경됨)
C → 삭제됨

즉, 모든 요소가 바뀐 것으로 인식

이것은 단순한 성능 문제에 그치지 않고 실제 UI에 이러한 일이 일어날 경우 예를 들어

• input에 입력한 값이 다른 아이템으로 이동
• 체크박스 상태가 꼬임
• 애니메이션이 이상하게 동작

과 같은 일이 일어날 수 있다

그래서 key를 설정해주면

{items.map((item) => (
  <li key={item}>{item}</li>
))}

값이 아닌 key를 기준으로 비교하여

A → 삭제됨
B → 그대로 유지
C → 그대로 유지

필요한 부분만 업데이트를 진행한다

주의점

결론부터 말하면 아무 값이나 넣으면 안된다

key는 단순히 값이 있으면 되는 것이 아닌

요소를 안정적으로 식별할 수 있는 값

이어야 한다.

❌ 잘못된 예

<li key={Math.random()}>{item}</li>

• 렌더링될 때마다 값이 바뀜
• React 입장에서는 매번 새로운 요소 👉 불필요한 재렌더링 발생 (성능 문제)

<li key={index}>{item}</li>

• 배열 순서가 바뀌면 key도 같이 바뀜 👉 다른 요소를 같은 요소로 착각 (버그 발생)

✅ 올바른 기준

<li key={item.id}>{item.name}</li>

• 고유하다 (unique)
• 변하지 않는다 (stable) 👉 이 두 가지 조건이 가장 중요하다

따라서 key는 아무 값이 아닌, 👉 “변하지 않는 고유한 식별자”를 넣어야 한다.

Flutter로 프로젝트를 진행했던 것과는 여러 구조들이 다를 것이라고 생각해서 관련된 내용을 정리하고 시작하고자 한다.

📦 기본 폴더 구조

React에서 가장 기본적인 폴더 구조를 알아보자.

src/
├── components/     // 재사용 가능한 UI 컴포넌트
├── pages/          // 페이지 단위 컴포넌트
├── styles/         // 전역 스타일 관리
│   ├── colors/
│   │   └── colors.css
│   ├── fonts/
│   │   └── fonts.css
│   └── global/
│       ├── reset.css
│       └── common.css
├── api/            // API 요청 함수
├── hooks/          // custom hook
├── utils/          // 공통 함수
└── assets/         // 이미지, 아이콘
    └── images/

폴더별 역할 정리

components

재사용 가능한 UI 조각

• Button
• Card
• Header
• ItemCard

  여러 페이지에서 사용할 수 있도록 만드는 것이 핵심

pages

화면 단위

• MainPage
• Detailpage 등등

하나의 화면 = 하나의 페이지

styles

전역 스타일 관리

• colors.css
• fonts.css
• reset.css
• common.css

디자인과 관련된 파일들

api

서버 통신

* 예시
export async function getProducts() {
  const res = await fetch('/products');
  return res.json();
}

API 로직을 분류하여 관리하면 컴포넌트가 깔끔해진다

hooks

function useProducts() {
  // 데이터 fetch 로직
}

로직 재사용을 위한 공간

utils

공통 함수

assets

이미지, 아이콘

Flutter와 React 폴더 구조 차이

Flutter로 프로젝트를 진행할 때는 MVC, MVVM 같은 아키텍처 패턴 중심으로 폴더를 나누는 경우가 많았다.

하지만 React는 조금 다르게 접근한다는 것을 알았다.

⚛️**React는 '역할'보다 '기능(UI)'으로 나눈다

• 이 파일이 어디에 사용되는가

컴포넌트가 기본 단위인 React에서는 컴포넌트 하나 자체가 구조 역할을 하기에 이러한 특징이 생긴다.

또한 React는 공식적으로 정해진 폴더 구조가 없다고 한다.

그래서 작은 프로젝트는 단순 구조로 진행되지만, 커질 수록 feature 기반으로 확장되는 경우가 많다고 한다.

프로젝트를 시작하기 전에 폴더 구조와 같은 여러 컨벤션들을 미리 정리하고 약속해두고 시작하면서 진행 중에 생기는 크고 작은 이슈들을 미리 방지하기에 유리함을 느꼈다.

이 과정에서 디자인 시스템을 정리할 때 .css뿐만 아니라 .js로도 관리하는 방법이 있다는 것을 알게 되어 두 방식의 차이를 정리하고 어떤 상황에서 적합한지 비교해보고자 한다.

우선 디자인 시스템이 무엇인지 짚고 넘어가자

디자인 시스템이란

프로젝트 전반에서 일관성을 유지하기 위해 미리 정의해두는 값과 규칙들의 집합

즉,

• 색상
• 폰트
• 여백
• 컴포넌트 스타일 이러한 요소들을 매번 새로 정의하는 것이 아닌, 한 곳에 모아두고 재사용하는 것을 말한다.

.css로 디자인 시스템 관리하기

가장 일반적인 방법으로 CSS 변수를 사용해서 관리하는 것이다.

:root {
  --color-primary: #99C08E;
  --color-gray-01: #f5f5f5;
  --font-size-base: 16px;
}

사용 시

.button {
  background-color: var(--color-primary);
  font-size: var(--font-size-base);
}

특징

• 스타일을 CSS 레벨에서 정의
• 전역적으로 사용 가능
• 브라우저가 직접 처리

장점

• 가장 표준적인 방식
• 스타일과 자연스럽게 연결됨
• 재사용성이 높음
• 협업에 유리 (디자이너와 공유하기 쉬움)

단점

• 동적인 처리에 한계가 있음
• 조건에 따라 값을 바꾸기 어려움

.js로 디자인 시스템 관리하기

디자인 값을 JavaScript 객체로 관리하는 방법도 있다.

export const colors = {
  primary: "#99C08E",
  gray01: "#f5f5f5",
};

export const fontSize = {
  base: "16px",
};

사용 시

<div style={{ color: colors.primary, fontSize: fontSize.base }} />

특징

• 디자인 값을 데이터처럼 관리
• 필요한 곳에서 import 해서 사용

장점

• 조건 처리 가능 (다크모드 등)
• JS 로직과 쉽게 결합 가능
• 자동완성, 타입 지원 가능
• 단점*
• 인라인 스타일이 많아질 수 있음
• CSS와 분리되어 어색할 수 있음
• 스타일 재사용성이 떨어질 수 있음

📃정리

언제 무엇을 사용해야 할까

.css가 적합한 경우

• 색상, 폰트, spacing 같은 기본 디자인 토큰
• 공통 스타일 (버튼, 레이아웃 등)
• 프로젝트 전체에서 사용하는 값

👉 정적인 디자인 정의

.js가 적합한 경우

• 다크모드 같은 조건에 따라 변하는 값
• 계산이 필요한 스타일
• 컴포넌트 내부에서만 사용하는 값

👉 동적인 로직이 필요한 경우

정적인 디자인 처리는 .css, 동적인 처리는 .js가 어울린다고 정리할 수 있다. 상황에 따라 다르지만 .js를 컴포넌트처럼 import해서 사용하는 점에 있어 더 쉽고 다양하게 사용할 줄 알았는데 디자인 시스템을 구성하는 관점에서 .css가 프로젝트에 용이할 것 같다는 점이 의외였다.

useState, useEffect 등 use-로 시작하는 함수들을 자주 보게 된다. 이들 모두 React에서 제공하는 Hook이다.

이러한 Hook 중 useMemo와 useCallback에 대해서 알아보고자 한다.

useMemo

useMemo는 값을 기억하는 Hook이다.

const memoizedValue = useMemo(() => {
  return 계산값;
}, [의존성]);

특정 값의 계산 결과를 저장해두고 의존성(dependency)이 변경될 때만 다시 계산한다.

불필요한 반복 계산을 막기 위한 Hook

const sortedList = useMemo(() => {
  return [...items].sort((a, b) => a - b);
}, [items]);

위 코드를 보면 items가 바뀔 때만 정렬을 다시 수행한다. 그렇지 않으면 이전에 계산된 결과(sortedList)를 그대로 재사용한다.

여기서 헷갈리기 쉬운 부분이 있다. 의존성 배열[items]는 값을 저장하는 것이 아닌, 다시 계산할지 판단하는 기준이다.

정리하자면

• useMemo는 계산 결과를 기억하고, 의존성이 변경될 때만 다시 실행된다.
• 불필요한 계산을 줄이기 위해 사용한다.

남용하면 생기는 문제

const sum = useMemo(() => a + b, [a, b]);

이건 그냥

const sum = a + b;

이렇게 가벼운 계산에는 그냥 쓰는 것이 좋다 -> 코드의 복잡성만 향상

• 성능 저하 useMemo도 비용이 있다. 의존성 비교 비용, 메모리 사용, Hook 실행 비용이 있기에 무조건 빠르게만 해주는 도구가 아니라는 점을 인지해야한다.

• 의존성 관리 실수

  const value = useMemo(() => {
  return count * 2;
  }, []);

  count가 바뀌어도 값이 안바뀐다.

정리하자면 useMemo는

비싼 계산을 줄이기 위한 선택적 최적화

이기에

- 계산 비용이 크거나
- 렌더링마다 실행이 부담되거나
- 실제 성능 문제가 발생했을 때

사용하는 것이 좋다.

useCallback

useCallback은 함수를 기억하는 Hook이다.

const memoizedFn = useCallback(() => {
  실행할 함수
}, [의존성]);

특정 함수를 저장해두고, 의존성(dependency)이 변경될 때만 새로운 함수를 생성한다

불필요한 함수 재생성을 막기 위한 Hook

천천히 알아보자.

❌ useCallback 없이

function Parent() {
  const [count, setCount] = useState(0);

  const handleClick = () => {
    console.log("클릭");
  };

  return (
    <div>
      <button onClick={() => setCount(count + 1)}>+</button>
      <Child onClick={handleClick} />
    </div>
  );
}

여기서 handleClick 함수는 랜더링이 될 때마다 새로 생성된다

버튼을 눌러 `count`증가 -> Parent 다시 렌더링 -> `handleClick` 새로 생성

이렇게 되면 React 기본 구조상 부모 컴포넌트가 렌더링되면 자식 컴포넌트도 함께 렌더링된다.

사실 handleClick이 새로 생성되는 것이 직접적인 문제가 되는 것은 아니다. 하지만 최적화를 했을 때는 문제가 발생한다.

예를 들어, 자식 컴포넌트를 React.memo로 감싸 불필요한 렌더링을 막으려고 한다고 가정해보자.

const Child = React.memo(({ onClick }) => {
  console.log("Child 렌더링");
  return <button onClick={onClick}>Click</button>;
});

이 경우 props인 onClick이 변경되지 않으면 Child는 다시 렌더링되지 않아야 한다. 하지만

const handleClick = () => {
  console.log("클릭");
};

이 함수는 렌더링이 될 때마다 새로 생성되기 때문에 props가 변경된 것으로 인식된다 결과적으로 Child 컴포넌트의 리렌더링을 막을 수 없는 것이다. 이 문제를 해결하기 위해 useCallback를 사용한다.

function Parent() {
  const [count, setCount] = useState(0);

  const handleClick = useCallback(() => {
    console.log("클릭");
  }, []);

  return (
    <div>
      <button onClick={() => setCount(count + 1)}>+</button>
      <Child onClick={handleClick} />
    </div>
  );
}

이렇게 하면 렌더링이 다시 발생해도 handleClick함수는 새로 생성되지 않고 유지된다. Child 컴포넌트의 불필요한 리렌더링을 방지할 수 있는 것이다.

남용하면 생기는 문제

useCallback은 기본이 아닌 최적화 도구

▪️ 코드가 오히려 복잡해진다

const handleClick = useCallback(() => {
  console.log("클릭");
}, []);

단순한 함수라면 굳이 필요가 없다

▪️ 성능이 더 나빠질 수도 있다

• 의존성 배열을 비교하는 비용 발생
• 메모이제이션 자체도 비용이 있음 → 작은 코드에서는 오히려 손해

▪️ 의존성 관리 실수

const handleClick = useCallback(() => {
  console.log(count);
}, []);

count가 바뀌어도 반영되지 않음 (버그)

useMemo와 useCallback에 대해 정리해보았다. React의 여러 Hook을 알게 될 때마다 어떻게 사용해야 더 좋은 코드가 나오는지 생각해보게 되는 것 같다.

익숙해질 수 있도록 여러 응용을 다뤄보자.

컴포넌트란?

UI를 구성하는 가장 독립적인 단위

React에서 화면은 하나의 덩어리가 아니라, 여러 개의 작은 조각들로 나뉘어 만들어진다.

이 작은 조각 하나하나를 컴포넌트(Component)라고 한다.

Flutter에서 Widget과 비슷한 역할이라고 볼 수 있다.

다만 React에서 컴포넌트는 단순한 UI 요소뿐만 아니라 상태(state), 이벤트, 로직까지 함께 관리한다는 점에서 더 넓은 개념이다.

컴포넌트 구성

앞에서 컴포넌트는 단순한 UI 조각이 아니라 상태(state), event, logic을 함께 관리하는 단위라고 했다.

그렇다면 남은 구성요소는 무엇일까?

• Props (데이터 전달)

부모 컴포넌트에서 자식 컴포넌트로 전달되는 값

앞서 컴포넌트 분리를 다루면서 알아보았던 props다.

• State (상태 관리)

컴포넌트 내부에서만 관리되는 값

이것도 State를 알아보자에서 다루어보았다.

• Event (이벤트 처리)

간단하게 말하자면 사용자의 행동(클릭, 입력)등을 처리하는 부분이다.

• Logic (비즈니스 로직)

조건문, 반복문, 데이터 처리 등 실제 동작을 담당하는 부분이다.

• UI (렌더링)

최종적으로 화면에 보여지는 부분이다.

컴포넌트는 이렇게 구성되어있는 하나의 작은 프로그램 단위 라고 볼 수 있다.

컴포넌트 작성

이제 컴포넌트를 어떻게 만드는지 알아보자

두 가지의 방식이 존재한다

- 함수형 컴포넌트 (Functional Component)
- 클래스 컴포넌트 (Class Component)

• 함수형 컴포넌트 (Functional Component)

function Hello() {
  return <h1>Hello World</h1>;
}

또는

const Hello = () => {
  return <h1>Hello World</h1>;
};

이런 식으로 함수 형태로 작성되는 컴포넌트이다. 이러한 함수형 컴포넌트 특징으로는

• 코드가 간결하고 직관적
• useState,useEffect와 같은 Hook을 사용할 수 있다

• 클래스 컴포넌트 (Class Component)

import React, { Component } from "react";

class Hello extends Component {
  render() {
    return <h1>Hello World</h1>;
  }
}

클래스 문법을 사용해 만드는 컴포넌트로 -this를 사용해야하며

• lifecycle 매서드를 사용하고
• 상대적으로 코드가 복잡하다.

함수형 컴포넌트 vs 클래스 컴포넌트

작성 방식을 간단하게 알아보았고, 차이점을 정리해보자

클래스 컴포넌트는 아직 친숙하지 않은 느낌이라 이해가 쉽지는 않다. 어떤 때에 어떤 것을 사용하는 것이 좋은지도 알아보자

어떤 것을 사용해야 할까?

쉽게 결론이 나왔다.

과거에는 state와 lifecycle을 사용하기 위해 클래스 컴포넌트를 사용해야 했지만, Hook이 등장하면서 함수형 컴포넌트에도 동일한 기능을 모두 구현할 수 있게 되었다.

코드도 더 짧고, 가독성도 좋아졌다.

마지막으로 내용을 정리해보자면,

- 컴포넌트는 UI를 구성하는 독립적인 단위이면서 props, state, event, logic, UI로 구성된다
- 함수형 / 클래스 두 가지의 방식이 존재하며 현재는 함수형 컴포넌트 방식이 많이 사용된다

컴포넌트 분리도 공부해보며 React를 다루면서 컴포넌트라는 단어는 많이 들었지만 제대로 이해하고나니 다른 개념들도 확실하게 잡히는 것 같아 좋았다.

컴포넌트 분리, 이전에 Flutter에서 Widget을 따로 분리해서 사용했던 것처럼 쉬울 줄 알았다. 오만했다고 볼 수 있다. React에서 해보니 영- 감을 못잡았기 때문이다.

기준

그냥 Widget을 똑 떼어내어 사용할 곳에서 import 해오는 방식과는 무엇인가 달랐다. 그 이질감의 원인을 알아내고자 컴포넌트 분리의 기준을 찾아보았다.

이 UI가 독립적으로 재사용 가능한가?

이렇게 생각해도 확 와닿지 않았기에 코드로 살펴보겠다.

<div>
  <h2>할 일 목록</h2>
  <input />
  <button>추가</button>
</div>

이 코드를

function TodoInput() {
  return (
    <div>
      <input />
      <button>추가</button>
    </div>
  );
}

이렇게 하면 TodoInput을 불러와 다른 곳에서도 사용할 수 있다. 처음에 느꼈던 것과 비슷해서 반복인 느낌이 들었기에 더 찾아보니 나는 작성법에서 어려움을 느꼈던 것이었다.

고로 분리해서 필요한 곳에서 재사용한다는 것은 맞는 흐름이었고, 분리 과정에서 데이터 전달 방법과 같은 작성이 어려웠던 것이기에 이걸 다시 알아보고자 한다.

props

컴포넌트를 나누는 순간, 데이터의 흐름도 같이 설계해야 한다

먼저 분리하기 전 코드를 살펴보자.

function App() {
  const [title, setTitle] = useState("");

  const handleSubmit = (e) => {
    e.preventDefault();
    if (title.trim() === "") return;

    console.log(title);
    setTitle("");
  };

  return (
    <form onSubmit={handleSubmit}>
      <input
        value={title}
        onChange={(e) => setTitle(e.target.value)}
      />
      <button type="submit">추가</button>
    </form>
  );
}

여기서 TodoForm으로 입력 부분을 분리해보겠다.

function TodoForm() {
  const [title, setTitle] = useState("");

  const handleSubmit = (e) => {
    e.preventDefault();
    if (title.trim() === "") return;

    console.log(title);
    setTitle("");
  };

  return (
    <form onSubmit={handleSubmit}>
      <input
        value={title}
        onChange={(e) => setTitle(e.target.value)}
      />
      <button type="submit">추가</button>
    </form>
  );
}

이렇게 뚝 떼어내어서 가져오면 문제가 발생한다 할 일을 추가하는 로직은 부모인 App에 있어야하는데 자식인 TodoForm으로 들어가있다.

이렇게되면 상태 관리와 UI 역할이 섞이게 되어 문제가 된다

📌여러 컴포넌트에서 사용해야 하는 state는 부모에서 관리하는 것이 더 적절하기 때문이다

이걸 해결하기 위해 부모에 함수를 만들고

const handleAdd = (title) => {
  ...
};

이걸 props안 onAdd로 전달한다.

<TodoForm onAdd={handleAdd} />

그리고 자식에서 이 함수를 받아서 실행한다

function TodoForm({ onAdd }) {
  ...
  onAdd(title);
}

이렇게 해서 TodoForm의 코드는

import { useState } from 'react';

function TodoForm({ onAdd }) {
  const [title, setTitle] = useState('');

  const handleSubmit = (e) => {
    e.preventDefault();
    if (title.trim() === '') return;
    onAdd(title.trim());
    setTitle('');
  };

  return (
    <form onSubmit={handleSubmit}>
      <input
        type="text"
        value={title}
        onChange={(e) => setTitle(e.target.value)}
        placeholder="할일 입력..."
      />
      <button type="submit">
        추가
      </button>
    </form>
  );
}

이렇게 된다.

이제 추출을 해서 사용해보자

export / import

만든 TodoForm 마지막에

export default TodoForm;

export default를 넣어 외부에서 사용할 수 있게 만들고

App으로 돌아와서

import TodoForm from './components/TodoForm';

를 통해 import 해준다.

그리고

    <form onSubmit={handleSubmit}>
      <input
        value={title}
        onChange={(e) => setTitle(e.target.value)}
      />
      <button type="submit">추가</button>
    </form>

이 부분을

      {/* props로 함수 전달 */}
      <TodoForm onAdd={handleAdd} />

이렇게 변경해주면 깔끔하게 사용할 수 있다.

props vs state

마지막으로 둘의 차이를 비교해보자

📦 props

외부(부모)에서 전달받는 데이터

<TodoForm onAdd={handleAdd} />
function TodoForm({ onAdd }) {
  return <button onClick={onAdd}>추가</button>;
}

부모 → 자식으로 전달
읽기 전용 (수정 불가)
컴포넌트 입장에서는 “받아서 쓰는 값”

⚙️ state

컴포넌트 내부에서 관리하는 데이터

const [title, setTitle] = useState("");

컴포넌트 내부에서 생성
setState로 변경 가능
값이 바뀌면 UI가 다시 렌더링됨

🔥 가장 중요한 차이

👉 누가 데이터를 바꾸는가?

function App() {
  const [todos, setTodos] = useState([]);

  return <TodoForm onAdd={setTodos} />;
}

• todos → state (App이 관리)

• onAdd → props (TodoForm에게 전달)

• 데이터는 App이 가지고 | 행동은 TodoForm이 실행

컴포넌트 분리에서 막혔던 작성법을 다시 공부해보았다. 컴포넌트 분리, 그리고 props가 조금은 이해되었다. 다음 응용에서는 잘해보자!

React를 처음 배우면서 가장 많이 사용하게 되는 것이 바로 state다.

그런데 사용하다보니 한 가지 의문이 들었다.

모든 값을 state로 관리해야 할까?

처음에 했던 생각

처음에는 이렇게 생각했다.

• 값이 있으면 일단 state로 만들자
• 바뀔 가능성이 있으면 state 그러다 보니, 그냥 다 state 쓰면 되는 거 아닌가?

그래서 이런 코드가 자연스럽게 나왔다.

const [name, setName] = useState("Kim");
const [age, setAge] = useState(20);
const [title, setTitle] = useState("Hello");

이해보다는 받아들여서 쓰기 시작하다보니

“모든 값을 state로 관리해야 하는 것인가?”

하는 궁금증이 생겼다.

💡 state와 일반 변수의 차이

찾아보다보니 기준을 하나 잡을 수 있었다.

👉 “이 값이 바뀔 때 화면(UI)이 다시 그려져야 하는가?”

React의 렌더링이란?

이것에 대해 이해하기 위해 렌더링을 짚어보고 넘어가겠다.

React는 상태(state)가 변경되면 컴포넌트를 다시 실행하고 UI를 다시 그린다

state 변경 → 컴포넌트 함수 재실행 → UI 업데이트

즉, state는 단순한 값이 아니라 렌더링을 발생시키는 기준이다

✅ 그냥 변수로 충분한 경우

const title = "Hello";

👉 특징:

• 값이 바뀌지 않음
• UI에 영향 없음

✅ state가 필요한 경우

const [count, setCount] = useState(0);

👉 특징:

• 값이 변경됨
• 변경되면 UI가 다시 렌더링되어야 함

📌 핵심 기준

👉 렌더링을 발생시키지 않는 값은 state가 아니다

⚠️ state를 남용하면 생기는 문제

1️⃣ 불필요한 리렌더링

state가 바뀌면 컴포넌트가 다시 렌더링된다. 👉 필요 없는 값까지 state로 만들면 성능에 영향을 줄 수 있다.

2️⃣ 코드 복잡도 증가

• state 많아짐
• 관리 어려움
• 읽기 힘든 코드

3️⃣ 의도 파악이 어려워짐

👉 어떤 값이 중요한 상태인지 헷갈림

🔥 다시 정리해보면

처음에는 이렇게 생각했다.

“state는 그냥 값 저장하는 도구다”

하지만 지금은 이렇게 이해하고 있다.

👉 state는 “UI를 바꾸기 위한 상태”다

🧠 정리

React는 단순히 값을 저장하는 방식이 아니라

👉 “상태 변화에 따라 UI를 다시 그리는 구조”였다

그래서 중요한 건

• 값을 저장하는 것보다
• 어떤 값을 state로 관리할지 판단하는 것

이었다.

모든 값이 state일 필요는 없다  
렌더링이 필요한 값만 state로 관리하자

실습 적용

이전에 TodoList를 구현해보면서 state가 언제 필요한지 더 명확하게 이해할 수 있었다.

• 할 일 추가

  const [todos, setTodos] = useState([]);
  

function handleAddTodo(title) { const newTodo = { id: Date.now(), title, completed: false, };

setTodos([...todos, newTodo]); }

할 일을 추가하면 todos 상태가 변경되고 UI도 함께 업데이트된다. 이 경우 state가 반드시 필요하다

* **완료 처리**
```jsx
function handleToggleTodo(id) {
  const updated = todos.map((todo) =>
    todo.id === id
      ? { ...todo, completed: !todo.completed }
      : todo
  );

  setTodos(updated);
}

completed 값이 바뀌면서 UI에서 할일/완료 목록이 이동한다.
state 변화 → UI 변화가 연결되는 구조였다

👉 결국 중요한 것은 state를 사용하는 것이 아니라 언제 사용해야 하는지를 아는 것이었다

핵심 개념 정리

🔹 useState

React에서 데이터를 관리하기 위해 사용한다.

const [title, setTitle] = useState("");
const [todos, setTodos] = useState([]);

• title → input 값 저장
• todos → 할 일 목록 저장

🔹 React의 데이터 흐름

TodoList를 만들면서 가장 중요했던 개념은 다음 흐름이었다.

입력 → state 변경 → 화면 자동 업데이트

React는 state가 바뀌면 UI가 자동으로 다시 그려진다.

Todo 데이터 구조

각 todo는 다음과 같은 형태로 구성했다.

{
  id: Date.now(),
  title: title,
  completed: false,
  createdAt: new Date().toLocaleString()
}

• id → 고유값

• title → 할 일 내용

• completed → 완료 여부

• createdAt → 생성 시간

기능 구현 과정

할 일 추가 (Create)

💡 핵심

• input 값 → state로 관리

• 버튼 클릭 → 배열에 추가

  function handleAddTodo() {
  if (title === "") return;
  
  const newTodo = {
    id: Date.now(),
    title: title,
    completed: false,
    createdAt: new Date().toLocaleString(),
  };
  
  setTodos([...todos, newTodo]);
  setTitle("");
  }

❗ 중요 포인트

기존 배열을 직접 수정하지 않고 새로운 배열을 만들어야 한다

👉 그래서 spread 사용

목록 출력 (Read)

배열을 화면에 출력할 때는 map을 사용한다.

<ul>
  {todos.map((t) => (
    <li key={t.id}>
      <div>{t.title}</div>
      <div>{t.createdAt}</div>
    </li>
  ))}
</ul>

❗ 중요 포인트

• map은 배열을 순회하면서 UI를 만든다

• key는 반드시 필요

할일 삭제 (Delete)

삭제는 filter를 사용한다.

function handleDeleteTodo(id) {
  setTodos(todos.filter((t) => t.id !== id));
}

💡 핵심

삭제 = 특정 값을 제외하고 남긴다

완료 처리 (Update)

완료 상태 변경은 map을 사용한다.

function handleDoneTodo(id) {
  const newTodos = todos.map((t) => {
    if (t.id === id) {
      return {
        ...t,
        completed: !t.completed,
      };
    }
    return t;
  });

  setTodos(newTodos);
}

💡 핵심

수정 = map 삭제 = filter

UI 처리

🔹 완료 상태 스타일

<li className={t.completed ? "completed" : ""}>

회고

아직 제대로 TodoList를 마스터하지 못한 것 같다. map과 filter를 사용함에 있어서, 그리고 구조대로 코드를 작성함에 있어서 미숙해서 복습 겸 정리를 진행했다.