이 글은 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를 사용함에 있어서, 그리고 구조대로 코드를 작성함에 있어서 미숙해서 복습 겸 정리를 진행했다.

배열이나 객체에서 값을 “꺼내서 변수에 바로 담는 문법”

아직 제대로 구조분해 할당의 개념을 이해하지 못한 것 같아 다시 정리하면서 공부해보고자 한다.

1️⃣ 배열 구조분해

기본 형태

const arr = [10, 20, 30];

const [a, b, c] = arr;

console.log(a); // 10
console.log(b); // 20

👉 순서대로 들어간다 (중요)

일부만 꺼내기

const [a, , c] = [10, 20, 30];

console.log(a); // 10
console.log(c); // 30

👉 필요 없는 값은 건너뛸 수 있음

기본값 설정

const [a = 1, b = 2] = [10];

console.log(a); // 10
console.log(b); // 2

👉 값이 없을 때만 기본값 사용

여기까지는 기본 구조로 쉽게 이해할 수 있다.

2️⃣ 객체 구조분해

기본 형태

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

const { name, age } = user;

console.log(name); // Kim

👉 key 이름 기준으로 꺼냄 (순서 X)

이걸 조금 더 자세히 보자

원래 데이터는

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

이 상태였다 여기서 user안에 있는 name을 꺼내서 쓰고싶으면

const name = user.name;

name이라는 새로운 변수에 user.name을 할당한다

이걸 구조분해로 하면

const { name } = user;

1. user 객체를 본다
2. 그 안에서 name이라는 key를 찾는다
3. 그 값을 꺼낸다
4. name이라는 변수에 넣는다

이렇게 된다.

정리하면, “user에서 name을 꺼내서 변수로 만든다”

변수 이름 바꾸기

const { name: userName } = user;

console.log(userName); // Kim

👉 name을 userName으로 바꿔서 사용

이것도 해석해보면

1. user 객체를 본다
2. name이라는 key를 찾는다
3. 그 값을 꺼낸다
4. userName이라는 변수에 넣는다

이렇게 된다.

3️⃣ 함수에서 구조분해

여기서부터 다시 어려워졌었기에 천천히 해보겠다.

먼저 구조분해 없이 코드를 보면

function printUser(user) {
  const name = user.name;
  const age = user.age;

  console.log(name, age);
}

printUser({ name: "Kim", age: 20 });

printUser라는 함수에서 user라는 매개변수로 값을 받는다. 이후 name과 age에 값을 할당한다.

이 과정을 구조분해로 줄여보자

매개변수 user로 객체를 받고 → 그 안에서 name, age를 꺼내서 → 각 변수에 값을 할당한다.

이 과정을 줄이면 다음과 같이 작성할 수 있다.

function printUser(user) {
  const { name, age } = user;

  console.log(name, age);
}

이해가 됐다

4️⃣ React에서 왜 사용할까?

React에서는 컴포넌트에 데이터를 전달할 때 props를 사용한다.

예를 들어 다음과 같은 객체가 있다고 하자.

const props = { title: "Hello", count: 1 };

❌ 구조분해를 사용하지 않는 경우

console.log(props.title);
console.log(props.count);

👉 props.를 계속 붙여야 해서 코드가 길어지고 👉 여러 번 사용할수록 가독성이 떨어진다.

✅ 구조분해를 사용하는 경우

const { title, count } = props;

console.log(title);
console.log(count);

👉 필요한 값만 꺼내서 바로 사용할 수 있다. 👉 코드가 짧아지고, 읽기 쉬워진다.

여기까지 이해했으면 React에서 실제로 사용하는 방법을 살펴보자

const MyComponent = ({ title, count }) => {
  return <div>{title} - {count}</div>;
};

👉 props를 받은 뒤 꺼내는 것이 아니라 👉 매개변수에서 바로 구조분해를 한다

5️⃣ useState에서 구조분해

먼저 useState란?

React에서 useState는 컴포넌트의 상태(state)를 관리하는 함수다.

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

👉 count는 현재 상태 값 👉 setCount는 상태를 변경하는 함수

🧠 그런데 왜 이렇게 생겼을까?

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

이건 사실 구조분해다.

구조분해 없이 살펴보면,

const result = useState(0);

👉 useState를 호출하면 배열이 반환된다. result = [현재값, 상태변경함수];

실제로 풀어보면

const result = useState(0);

const count = result[0];
const setCount = result[1];

이걸 줄인 것이 바로

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

🔗 정리

구조분해에 대해 정리해보면서 다시 이해해보았다. 특히 React에서는 props, useState처럼 데이터를 다루는 거의 모든 과정에서 구조분해가 사용된다. 그래도 억지로 암기하고 부딪혔다가 막혀서 다시 이해해보니 훨 이해가 잘되어서 다행이다. 앞으로도 이해하고 잘 사용해보자.

var
let
const

이 세 가지는 모두 변수를 선언하는 키워드이지만 스코프(scope), 재선언 여부, 호이스팅 방식 등이 서로 다르다. 특히 ES6 이후에는 let과 const가 등장하면서 var의 사용이 점점 줄어들게 되었다.

이번 글에서는 var, let, const의 특징을 살펴보고 서로 어떻게 다른지 비교해 보겠다.

1️⃣ var

var는 JavaScript 초기부터 존재하던 변수 선언 방식이다.

특징

1. 재선언 가능

   var a = 10;
   var a = 20;
   

console.log(a); // 20

같은 이름의 변수를 다시 선언해도 에러가 발생하지 않는다.

---

2. 재할당 가능

var a = 10; a = 30;

console.log(a); // 30

값을 다시 할당하는 것도 가능하다.

---

3. 함수 스코프 (Function Scope)

var는 함수 단위로 스코프가 생성된다.

function test() { var a = 10; }

console.log(a); // error

하지만 블록문에서는 스코프가 생성되지 않는다.

if (true) { var a = 10; }

console.log(a); // 10

이 때문에 의도하지 않은 변수 접근이 발생할 수 있다.

---

4. 호이스팅 (Hoisting)

`var`로 선언된 변수는 선언이 코드의 최상단으로 끌어올려진 것처럼 동작한다.

console.log(a); var a = 10;

실제로는 다음과 같이 동작한다.

var a; console.log(a); // undefined a = 10;

그래서 선언 전에 접근하면 `undefined`가 출력된다.

---

# 2️⃣ let

`let`은 ES6에서 도입된 변수 선언 방식이다.
기존 `var`의 문제점을 보완하기 위해 등장했다.

**특징**
1. 재선언 불가능

let a = 10; let a = 20; // error

같은 스코프에서 같은 이름의 변수를 다시 선언할 수 없다.

---

2. 재할당 가능

let a = 10; a = 30;

console.log(a); // 30

값 변경은 가능하다.

---

3. 블록 스코프 (Block Scope)

`let`은 블록 단위로 스코프가 생성된다.

if (true) { let a = 10; }

console.log(a); // error

이 특징 덕분에 변수의 사용 범위를 **더 안전하게 관리**할 수 있다.

---

4. Temporal Dead Zone (TDZ)

`let`은 선언 전에 접근할 수 없다.

console.log(a); // error let a = 10;

이 구간을 **Temporal Dead Zone (TDZ)**이라고 한다.

---

# 3️⃣ const

const는 **상수(Constant)**를 선언할 때 사용하는 키워드이다.

**특징**

1. 재선언 불가능

const a = 10; const a = 20; // error

---

2. 재할당 불가능

const a = 10; a = 20; // error

---

3. 선언과 동시에 초기화 필요

const a; // error

반드시 선언과 동시에 값을 할당해야 한다.

---

4. 객체와 배열은 내부 값 변경 가능

const user = { name: "Kim" };

user.name = "Lee";

console.log(user.name); // Lee

``` const는 변수의 재할당을 막는 것이지 객체 내부 값을 변경하는 것까지 막지는 않는다.

정리

var는 호이스팅과 함수 스코프 때문에 예측하기 어려운 동작을 만들 수 있다. 그래서 ES6 이후에는 let과 const를 사용하는 것이 일반적이다.

보통 다음과 같은 기준으로 사용한다.

기본적으로 const 사용 값이 변경될 가능성이 있으면 let 사용 var는 사용하지 않음

이 방식이 변수의 변경 가능성을 명확하게 하고 코드의 안정성을 높여 준다.

특히 객체와 배열 같은 참조 타입(Reference Type)에서는 복사의 방식에 따라 결과가 달라진다.

이때 등장하는 개념이 바로

**- Shallow Copy (얕은 복사)

• Deep Copy (깊은 복사)**

이다.

1️⃣ 왜 복사 문제가 발생할까?

먼저 JavaScript의 데이터 타입을 간단히 이해해야 한다.

JavaScript의 데이터는 크게 두 가지로 나뉜다.

원시 타입은 값 자체가 복사된다.

let a = 10;
let b = a;

b = 20;

console.log(a); // 10

하지만 객체나 배열은 메모리 주소가 복사된다.

const user1 = { name: "Kim" };
const user2 = user1;

user2.name = "Lee";

console.log(user1.name); // Lee

두 변수는 같은 객체를 가리키고 있기 때문이다.

이 문제를 해결하기 위해 객체를 복사하는 방법이 필요하다.

2️⃣ Shallow Copy (얕은 복사)

Shallow Copy는 객체의 최상위 수준만 복사하는 방식이다.

즉 새로운 객체가 만들어지지만 내부 객체는 동일한 참조를 공유한다.

예제로 살펴보자

const user = {
  name: "Kim",
  address: {
    city: "Seoul"
  }
};

const copyUser = { ...user };

copyUser.address.city = "Busan";

console.log(user.address.city); // Busan

spread operator를 사용하면 새로운 객체가 만들어지지만 address 객체는 같은 메모리를 참조한다.

그래서 내부 값을 변경하면 원본도 함께 변경된다.

Shallow Copy 방법

Object.assign({}, obj)

const copy = { ...obj };

const copy = array.slice();

const copy = Array.from(array);

하지만 이러한 방식은 중첩 객체까지는 복사하지 않는다.

3️⃣ Deep Copy (깊은 복사)

Deep Copy는 객체 내부의 모든 값까지 완전히 복사하는 방식이다.

즉 복사된 객체는 원본 객체와 완전히 독립적인 데이터가 된다.

const user = {
  name: "Kim",
  address: {
    city: "Seoul"
  }
};

const copyUser = structuredClone(user);

copyUser.address.city = "Busan";

console.log(user.address.city); // Seoul

이번에는 copyUser를 수정해도 원본 객체는 변경되지 않는다.

왜냐하면 내부 객체까지 완전히 새로운 메모리로 복사되었기 때문이다.

Deep Copy 방법

structuredClone

최근 JavaScript에서 제공하는 가장 안전한 방법이다.

const copy = structuredClone(obj);

JSON 방식

예전에는 다음 방식이 많이 사용되었다.

const copy = JSON.parse(JSON.stringify(obj));

하지만 다음과 같은 단점이 있다.

• 함수 복사 불가능

• undefined 값 제거

• Date 객체 손실

정리

JavaScript에서 객체를 복사할 때는 단순히 = 연산자를 사용하면 참조만 복사된다.

따라서 상황에 따라 다음과 같은 방법을 사용해야 한다.

• 단순 구조 → Shallow Copy

• 중첩 객체 존재 → Deep Copy

이 차이를 이해하는 것은 예상하지 못한 데이터 변경 버그를 방지하는 데 매우 중요하다.

우리는 백 번을 살아도 다 쓰지 못할 잠재력을 가지고 태어났다 - 데니스 웨이틀리

최근 읽은 책에서 마음에 와닿았던 말이다. 모두가 특출난 장점을 가지고있다고 나는 확신한다. 단지 사회와 어울리거나 어울리지 않는 것으로 재능이 인정받거나 그렇지 않거나라고 생각한다. 시대를 잘 타고났다라는 말이 적합하다고 느낀다.

시작에 앞서 이 말을 하는 이유는 나 자신을 믿는 것부터가 시작인 것 같다. 우리 모두 각자의 기준에서 성공하고 싶어한다(사회적 기준에서 성공하고 싶어하더라도 그 곳에 있는 '나'를 바라보는 것이 곧 각자의 기준이 된다고 생각한다). 그래서 "나는 안돼", "저 사람은 재능을 가지고 태어났어"하고 낙담하지 말고 내가 잘할 수 있는 것을 어떻게 살려서 남은 시간을 보내고 능동적으로 살아갈 것인지를 고민하는 것이 자기 자신에게 좋을 것 같다.

포트폴리오란?

포트폴리오가 무엇인지 정의해보고 들어가자

포트폴리오란 내가 지금까지 만든 프로젝트와 경험을 정리한 문서

이 정의를 보면 내가 해온 많을 수도 있고 적을 수도 있는 경험들을 최대한 정리해서 풍성한 문서를 작성하고 싶어진다.

그런데 이번 특강을 들으면서 위와 같은 생각이 취업에 유리하지 않다는 것을 느꼈다. 오늘 글의 내용에서 다룰 특강은 개발자H님의 포트폴리오 특강이다.

강사님의 포인트는 포트폴리오는 면접을 가기 위한 문서였다. 면접을 가기 위한 문서? 이 말에 거창한 포트폴리오만을 생각해오던 일종의 개념이 깨졌다. 포트폴리오의 목적은 합격 자체가 아니라 면접으로 이어지는 것이다.

이 관점에서 생각해보면 포트폴리오를 만드는 방식도 조금 달라진다.

• 모든 내용을 설명할 필요는 없다.

• 면접관이 이해하기 쉽게 작성해야 한다.

• 면접으로 이어질 만큼만 보여주면 된다.

포트폴리오 특강을 들으며 정리한 내용을 바탕으로 내가, 나아가 개발자가 어떤 방식으로 포트폴리오를 준비하고 공부해야 하는지에 대해 정리해보려고 한다.

면접관의 관점에서 본 포트폴리오

내 포트폴리오가 정말 화려하고 아무리 내 스타일대로 잘 작성되었다고해도 이것의 독자는 정해져있다. 바로 면접관이다.

포트폴리오는 결국 면접관이 읽는 문서다

여기까지도 우리는 쉽게 이해할 수 있다. 하지만 면접관이 과연 내 포트폴리오를 꼼꼼히 100% 이해하면서 읽어줄까? 여기서 조금 속상했지만, 결국 면접관도 상황이 있기에 제출하는 우리들의 기대와 다르게 처음부터 끝까지 꼼꼼하게 읽기는 어렵다. 한 포지션에 몇백 개의 포트폴리오가 들어오는 경우도 흔하기 때문이다. 또한 면접관은 채용 전담 업무만 진행하는 것이 아니기에 내 포트폴리오가 면접관의 컨디션이 안좋은 상태에서 읽히는 상황이 발생할 수도 있다.

여기서 우리는 불평을 하거나, 운이 좋지 않았다고 치부하고 넘어가기에는 이 문제를 아무도 해결해줄 수 없는 무한 반복일 것이다. 어떻게 해결할 수 있을까? 다시 말해 어떻게 만들어야 면접관이 내 포트폴리오를 다른 포트폴리오보다 조금이라도 더 읽어보거나 기억에 남게 할 수 있을까? 경쟁력을 갖추기 위해서는 두 가지를 챙겨야 한다.

• 가독성이 좋아야한다
• 면접관이 질문하기 쉽게 만들어야한다

면접관이 피로하지 않게 내 포트폴리오를 읽고, 이해하고, 질문할 수 있도록 설계된 문서여야 한다는 것이다.

그래서 첫 페이지가 중요하다

가독성, 그리고 면접관이 쉽게 이해할 수 있고 질문과 연관 지을 수 있어야한다는 자연스럽게 아래와 같은 말로 귀결된다.

첫 페이지가 가장 중요하다

면접관이 내 포트폴리오를 더 읽을 수 있게 유도해야한다. 이를 강사님은 호기심을 만드는 페이지라 표현했다. 첫 페이지를 보았을 때 "이 사람 뭐지?" 라는 반응이 나오면 성공이라고 볼 수 있다. 궁금해야 다음 페이지를 읽어볼 이유가 하나라도 더 생기기 때문이다.

그럼 무엇을 보여줘야할까? 세 가지를 정하고 들어가보자

• 개발자 컨셉 (타이틀)
• 강점 3가지
• 이미지 기반 디자인

개발자 컨셉 (타이틀)

컨셉이라함은 곧 타이틀을 말한다. "안녕하세요. 풀스택 개발자 xxx입니다." 이런 타이틀은 궁금증을 불러오지 않는다.

• 일당백 개발자 xxx입니다.
• 퍼포먼스에 진심인 개발자 xxx입니다. 이러한 타이틀은 면접관으로 하여금 궁금증을 만든다

강점 3가지

자신의 강점 3가지 정도를 압축해서 보여주자. 중요한 점은

문장은 20자 이내 / 가능하다면 숫자를 활용하여

이미지 기반 디자인

텍스트보다는 이미지가 눈에 더 쉽게 들어오고 이해하기 쉽다. 이미지로 표현은 조금 생소했다. 강사님이 추천해주신 방법으로는

• 핀터레스트에서 레쥬메(Resume) 템플릿 참고
• 프로젝트 스크린샷을 목업 이미지로 제작
• 텍스트보단 시각적 요소 활용 텍스트보단 시각적 요소 활용

여기서 숫자를 활용 이 부분이 중요하다고 느껴졌다. 추상적인 표현보다 프로젝트1_Backend개발 : 기여도 60% 와 같이 숫자를 활용하여 보여주면 훨씬 직관적으로 표현할 수 있다.

여기서 걱정되는 점은 '어느정도 숫자가 과하지 않을까?' 였는데 내가 충분히 잘 설명할 수만 있다면 숫자에 대한 걱정은 하지 않아도 된다고 하셨다.

또한 역할에 대한 설명을 적는 것도 좋은 방법이다. 'API 설계', '배포 자동화' 등 자신이 맡은 파트도 좋지만 역할을 정리해서 적어주는 것도 면접관에게 쉽게 나를 이해시킬 수 있는 방법이다.

영화의 예고편

첫 페이지의 구조를 잘 작성했다면 이제 내 프로젝트들과 경험을 소개해야한다. 포인트는

프로젝트 상세는 '영화의 예고편'처럼 작성한다

영화 예고편에서는 관객들의 흥미를 돋굴 수 있도록 중요한 장면들은 보여주지만 결말이나 핵심 내용은 숨겨둔다. 이것이 핵심이다. 포트폴리오도 마찬가지로 모든 것을 문서에 상세하게 담아내기보다는 면접에서 설명할 여지를 남겨두는 것이 중요하다

너무 많은 내용은 가독성을 저하시키고 면접관으로 하여금 흥미를 떨어트린다

어떻게 예고편을 꾸밀까?

기술 키워드와 간단한 설명을 중심으로 정리해보자

예를 들어,

Redis Cache 적용으로 API 응답속도 개선
JWT 기반 인증 시스템 구현
Docker 기반 배포 자동화

이 방식의 장점은 명확이다. 키워드를 확실하게 적어 면접관에게 질문을 떠올리게 유도할 수 있는 것이다.

또 하나는 앞서 첫 페이지에서 사용했던 이미지 활용이다.

• 프로젝트 스크린샷
• 목업 이미지
• 서비스 구조 이미지 등을 적극적으로 활용하여 프로젝트의 맥락을 텍스트로 길게 적어내지 말고 가시적으로 표현해보자.

대기업 vs 스타트업 전략

전체적인 구조와 작성법에 대해서는 잘 알아보았다.

이제 내가 서류를 낼 곳에 대해 알아보자. 크게 대기업과 스타트업으로 분류하였다. 모든 회사가 같은 기준으로 개발자를 채용하는 것은 아니다. 이 둘로 구분지은 이유는 둘의 관점이 꽤 다르기 때문이다.

대기업

대기업은 보통 스페셜리스트를 선호한다. 이미 개발 조직이 충분히 크고 체계가 잡혀있기 때문에, 특정 포지션에 정확하게 맞는 사람을 찾는 경우가 많다. 그래서 아래와 같은 특징들이 있다.

• 특정 기술 스택에 대한 깊은 경험
• 포지션에 맞는 전문성
• 즉시 투입 가능한 역량

즉,

넓은 경험보다 깊은 경험이 중요하다

스타트업 / 중소기업

반면 스타트업을 비롯한 중소기업은 조직 규모가 작고 빠르게 움직여야 하기 때문에 문제 해결 능력과 적응력을 더 중요하게 보는 경우가 많다.

• 다양한 경험
• 문제 해결 과정
• 협업과 커뮤니케이션
• 컬쳐핏(함께 일할 수 있는 사람인가)

즉,

제네럴리스트 성향이 더 유리할 수 있다

이 이야기로 미루어보았을 때, 중요한 것은 결국 전략을 세워야한다는 것이다.

목표하는 회사에 따라

• 강조할 경험
• 프로젝트 구성
• 기술 스택 설명

이 달라질 수 있기 때문이다.

나는 어떤 회사에 지원할 것인가

이것을 깊게 생각해보고 포트폴리오 전략을 세워보자

특강 회고

이번 특강은 포트폴리오 작성법에 대한 내용이었지만 듣다 보니 결국 개발 공부의 방향성에 대한 이야기라는 생각이 들었다.

본디 포트폴리오는 취업을 위한 문서이기 전에 지금까지 내가 어떤 방식으로 공부해왔는지를 보여주는 결과물이기 때문이다.

기록과 태도 특강을 듣고 정리하며 느낀 두 가지의 키워드다.

기록

• 어떤 문제를 해결했고
• 어떤 기술을 사용했고
• 왜 그런 선택을 했는지

이런 내용들은 시간이 지나면서 쉽게 잊혀진다. 그래서 더욱 기록으로 남겨둬야 단순한 경험에서 설명할 수 있는 경험이 된다.

또한, 숫자는 설득력을 높이기에 프로젝트를 진행할 때

• 성능 개선
• 운영 효율
• 사용자 변화 등의 내용을 숫자로 기록해두는 것도 중요하다고 하셨다.

태도

태도에 대한 내용이 많지 않았지만 내가 태도를 키워드로 뽑은 이유는 결국 내가 해온 경험을 소개하는 것이기에 개발 공부에 대한 내용이 포트폴리오의 내용일 것이다. 개발 공부는 생각보다 긴 과정이다. 그 꾸준함을 유지하는 태도가 가장 중요하다고 생각이 들었다.

스프린트를 진행한지도 벌써 한 달이 넘어갔다. 가장 두려운 점은 내가 합리화를 시작했거나 욕심이 사라졌을까하는 부분이다.

내가 나를 가장 잘 알기에 미연에 방지하고자 스터디도 진행했다. 정말 많은 도움이 되고있고, 좋은 동료도 얻었다. 이들과 함께 끝까지 가기 위해 지치더라도 꾸준히 나아갔으면 좋겠다.

그렇다면 여기서 한 가지 문제가 생긴다.

비동기 작업이 언제 끝나는지 어떻게 알 수 있을까?

예를 들어 서버에서 데이터를 가져오는 작업이 있다고 가정해보자.

fetchUserData();
console.log("다음 작업 실행");

만약 데이터를 가져오는 작업이 3초가 걸린다면, 데이터가 도착하기 전에 다음 코드가 먼저 실행될 수 있다.

이때 작업이 끝난 뒤 실행할 코드를 전달하는 방법이 필요하다.

그래서 등장한 것이 바로 콜백 함수(Callback) 이다.

콜백 함수 (Callback)

콜백 함수는 다른 함수에 인자로 전달되는 함수이다.

하지만 단순히 인자로 전달된다는 의미보다 중요한 것은 다음과 같다.

콜백 함수는 실행 시점을 다른 함수에게 맡긴다.

말이 어려우니 예제로 살펴보자.

function greet(name, callback) {
  console.log("안녕하세요 " + name);
  callback();
}

function sayGoodbye() {
  console.log("안녕히 가세요");
}

greet("홍길동", sayGoodbye);

결과

안녕하세요 홍길동
안녕히 가세요

여기서 sayGoodbye는 직접 호출되지 않았다. 대신 greet 함수 내부에서 실행된다.

즉,

일반 함수 → 내가 원할 때 실행 콜백 함수 → 다른 함수가 필요할 때 실행

이처럼 실행 제어권이 다른 함수에게 넘어가는 것이 콜백 함수의 특징이다.

콜백 지옥 (Callback Hell)

콜백 함수는 특히 비동기 처리에 유용하여 비동기 작업에 많이 사용되지만, 작업이 많아지면 문제가 발생한다.

이러한 구조를 콜백 지옥이라고 한다. 사진을 보면 알겠지만 가독성이 매우 떨어지며, 에러 처리가 어렵고, 유지보수가 힘들다는 단점이 있다.

이것을 해결하기 위해 등장한 것이 Promise다.

Promise

Promise는

비동기 작업의 성공 또는 실패 결과를 나타내는 객체 이다.

그러니까, "작업이 끝나면 결과를 알려줄게~"라는 약속이라고 이해할 수 있다.

이 Promise는 3가지의 상태를 가지는데

// 1. Pending (대기)
// - 작업이 진행 중
const promise = new Promise((resolve, reject) => {
    // 작업 중...
});

// 2. Fulfilled (이행)
// - 작업 성공
const promise = new Promise((resolve, reject) => {
    resolve('성공!');
});

// 3. Rejected (거부)
// - 작업 실패
const promise = new Promise((resolve, reject) => {
    reject('실패!');
});

Pending - 대기, Fulfilled - 성공, Rejected - 실패 이 세 상태를 기억해두자.

Promise 만들기

❗Promise를 만들 때는, 항상 이 작업이 성공할 수도 있고 실패할 수도 있다는 것을 명시해줘야한다.

성공 = reseolve 실패 = reject

const promise = new Promise((resolve, reject) => {
    // 비동기 작업
    const success = true;

    if (success) {
        resolve('성공 데이터'); // 성공
    } else {
        reject('에러 메시지');  // 실패
    }
});

• then() 과 catch() :

  const promise = new Promise((resolve, reject) => {
    setTimeout(() => {
        resolve('완료!');
    }, 1000);
  });
  

promise .then(result => { console.log('성공:', result); }) .catch(error => { console.log('실패:', error); });

// 출력 (1초 후): // 성공: 완료!

* finally()
성공/실패와 상관없이 실행:

fetchUser(123) .then(user => { console.log('성공:', user); }) .catch(error => { console.error('실패:', error); }) .finally(() => { console.log('작업 완료 (성공이든 실패든)'); // 로딩 스피너 숨기기 등 });

---

## async/await
Promise를 더 쉽게 사용하는 문법으로 가장 중요한 포인트는 **비동기 함수의 동기적 표현**이다.

* Promise를 동기 코드처럼 :

// ❌ Promise (then 체인) fetchUser(123) .then(user => { console.log(user); return fetchOrders(user.id); }) .then(orders => { console.log(orders); });

// ✅ async/await (읽기 쉬움) async function getUser() { const user = await fetchUser(123); console.log(user);

const orders = await fetchOrders(user.id);
console.log(orders);

}

`async` 키워드는 함수를 **비동기 함수**로 만들어준다.
그리고 또 하나 중요한 특징이 있다.
>`async` 함수는 항상 **Promise**를 반환한다.

async function hello() { return "안녕"; }

이 함수는 단순히 문자열을 반환하는 것처럼 보이지만 실제로는

function hello() { return Promise.resolve("안녕"); }

이것과 같은 의미를 가지고 있다.
그래서 `async`함수는 다음과 같이 사용 가능하다.

hello().then(msg => console.log(msg));

// 출력 안녕

---
* **await**

`await` 키워드는 **Promise가 완료될 때까지 기다리는 역할**을 한다
그러기에 반드시 **async 함수 내부에서만 사용이 가능**하다.

---

## 에러처리 (try / catch)

`async / await`에서는 에러 처리를 try / catch로 할 수 있다.
Promise의 `.catch()`와 같은 역할이다.

async function getUser() { try { const user = await fetchUser(123); console.log("사용자:", user); } catch (error) { console.error("에러 발생:", error); } }

간단한 개념들로 정리해봤는데, 실제 코드에서 사용해봐야 감을 찾을 것 같다. 다음은 실습을 통해 진행해보겠다.