단순한 네비게이션이라도 프로젝트 규모가 커지면 관리 포인트가 기하급수적으로 늘어납니다. 이번 프로젝트에서는 단순히 UI를 그리는 수준을 넘어, 어느 환경에서도 일관되게 동작하고 스스로 데이터를 관리하는 '독립적인 위젯(Widget)' 구조를 설계하는 데 집중했습니다.

🧩 구조적 설계: 관심사의 분리

기능을 세분화하여 각 파일이 하나의 책임만 갖게 했습니다. 이는 정규화된 스크립트가 파일을 인식하기 좋게 만들 뿐만 아니라, 유지보수 효율을 극대화합니다.

src/widgets/navigation/
├── lib/
│   └── useNavigation.js       // 비즈니스 로직 (Data Engine)
├── ui/
│   ├── NavigationWidget.jsx   // 엔트리 포인트 (조립 공장)
│   ├── NavigationContext.jsx  // 데이터 공유 (중앙 방송국)
│   ├── Navigation.jsx         // 배치 설계도 (Layout)
│   ├── NavigationLayouts.jsx  // 레이아웃 디자인 패턴 (Pattern Components)
│   └── Brand.jsx, NavLinks.jsx... // 세부 UI 부품
└── index.js                   // 외부 노출 인터페이스

• 비즈니스 로직 엔진: URL 상태와 전역 상수를 조합해 데이터를 생성합니다. (#1)
• 중앙 방송국: 위젯 내부 어디서든 데이터에 접근하게 해줍니다. (#2)
• 레이아웃 설계도: UI의 뼈대와 배치 로직을 별도로 분리하여 시각적 일관성을 관리합니다. (#4)
• 순수 UI 부품: 각자의 스타일과 역할에만 집중합니다. (#5)

⚠️ 해결하고자 했던 문제: Props Drilling

파일을 세분화할수록 최상단에서 구한 데이터를 하위 부품까지 전달하는 과정이 번거로워집니다. 중간 단계 컴포넌트가 배달부 역할을 하게 되면, UI 구조를 살짝만 바꿔도 모든 Props 경로를 수정해야 하는 비효율이 발생합니다.

이 결합도(Coupling) 문제를 해결하기 위해 Context API를 활용한 캡슐화 전략을 선택했습니다.

🎯 핵심 전략: Context API를 통한 위젯 캡슐화

위젯 내부를 하나의 전용 컨텍스트로 감싸, 부품들이 중간 단계 없이 필요한 데이터를 직접 구독하도록 설계했습니다.

이 구조의 이점:

1. 독립성: 위젯은 외부로부터 어떤 데이터 주입도 필요로 하지 않습니다. 호출하는 즉시 스스로 동작합니다.
2. 확장성: 새로운 기능이 추가되어도 레이아웃 코드를 수정할 필요 없이, 해당 부품에서 컨텍스트 훅만 호출하면 됩니다.
3. 가독성: RootLayout은 복잡한 로직을 모른 채 위젯 한 줄로 깨끗하게 유지됩니다. (#6)

이어서 이 구조를 구현하기 위한 상세 코드와 함께, 서버 컴포넌트의 장점을 알고도 클라이언트 방식을 택한 '기술적 트레이드오프'를 공유하겠습니다.

Next.js 위젯 구현

1. 데이터 로직의 추상화

위젯에 필요한 모든 데이터와 상태 로직을 UI와 분리하여 커스텀 훅으로 관리합니다. 상세한 계산 로직은 훅 내부로 숨기고, UI에는 오직 필요한 데이터와 함수만을 반환하는 깨끗한 인터페이스를 제공합니다.

// #1. 비즈니스 로직 인터페이스 (src/widgets/navigation/lib/useNavigation.js)
// 상세 로직은 캡슐화하고 UI에 필요한 데이터 구조만 정의합니다.
export const useNavigation = () => {
  // ... 내부 계산 로직 (Github API 연동, URL 파라미터 파싱 등)은 생략

  return {
    username,      // 표시될 유저 이름
    avatarUrl,     // 프로필 이미지 경로
    customUsername,// 현재 커스텀 모드 여부
    getHref,       // 상태를 유지하며 경로를 생성하는 함수
    pathname       // 현재 경로 정보
  };
};

2. 기술적 구현: Context와 Widget

일관성 있는 시스템을 위해 위젯 내부의 데이터 방송국을 구축했습니다. 이 컨텍스트는 내부 부품들이 외부 간섭 없이 데이터를 수급하는 통로가 됩니다.

// #2. 중앙 방송국 (src/widgets/navigation/ui/NavigationContext.jsx)
'use client';
import { createContext, useContext } from 'react';

const NavigationContext = createContext(null);

export const useNavContext = () => {
  const context = useContext(NavigationContext);
  if (!context) throw new Error('useNavContext는 NavigationProvider 안에서만 쓰세요!');
  return context;
};

export const NavigationProvider = NavigationContext.Provider;

그다음, 비즈니스 로직과 UI를 결합하는 조립 공장(Widget)을 구축했습니다. 이 위젯은 외부에서 데이터를 주입받지 않고 스스로 로직을 수행하는 Self-contained 컴포넌트입니다.

// #3. 조립 공장 (src/widgets/navigation/ui/NavigationWidget.jsx)
'use client';
import { useNavigation } from '../lib/useNavigation';
import { NavigationProvider } from './NavigationContext';
import { Navigation } from './Navigation';

export const NavigationWidget = () => {
  const navData = useNavigation();
  return (
    <NavigationProvider value={navData}>
      <Navigation />
    </NavigationProvider>
  );
};

3. 레이아웃 로직의 분리

UI의 배치 로직(Navigation.jsx)과 실제 뼈대(NavigationLayouts.jsx)를 분리했습니다. 이를 통해 Navigation.jsx는 데이터 흐름이나 복잡한 스타일 코드 없이, 어떤 부품이 어디에 위치하는지 한눈에 보여주는 '설계도' 역할만 수행하게 됩니다.

// #4. 레이아웃 설계도 (src/widgets/navigation/ui/Navigation.jsx)
// 데이터를 받지 않고 오직 부품의 배치(Layout)만 정의합니다.
import * as Layout from './NavigationLayouts';
import { Brand } from './Brand';
import { NavLinks } from './NavLinks';
import { DarkModeToggle } from './DarkModeToggle';
import { TryYourself } from './TryYourself';

export const Navigation = () => {
  return (
    <Layout.Root>
      <Layout.LeftSide>
        <Brand />
        <Layout.ShowOnMobile><DarkModeToggle /></Layout.ShowOnMobile>
      </Layout.LeftSide>

      <Layout.RightSide>
        <TryYourself />
        <Layout.MenuWrapper>
          <NavLinks />
          <Layout.ShowOnDesktop><DarkModeToggle /></Layout.ShowOnDesktop>
        </Layout.MenuWrapper>
      </Layout.RightSide>
    </Layout.Root>
  );
};

4. UI 부품의 변화: 데이터 직접 구독

하위 부품들은 Props 배달을 기다리지 않습니다. 중앙 방송국에서 필요한 데이터만 직접 수령하는 구조를 통해 코드의 간결함을 유지합니다.

// #5. 데이터 직접 구독 부품 (src/widgets/navigation/ui/Brand.jsx)
import { useNavContext } from './NavigationContext';

export const Brand = ({ size = 32 }) => {
  const { avatarUrl, username, getHref } = useNavContext();
  return (
    <Link href={getHref('/')}>
      <Image src={avatarUrl} alt={username} width={size} height={size} />
      <span>{username}</span>
    </Link>
  );

5. 기술적 트레이드오프: 서버 컴포넌트와 DX

이 설계의 가장 큰 고민은 "순수 UI임에도 'use client'가 불가피한가?"였습니다. RSC(서버 컴포넌트)의 이점은 분명하지만, 저는 클라이언트 중심의 위젯 캡슐화를 선택했습니다.

① 위젯의 독립성 확보

RSC 방식을 유지하려면 데이터를 부모에서 구하거나 수동으로 넘겨야 하며, 이는 네비게이션을 레이아웃의 종속물로 만듭니다. 저는 어디에 꽂아도 즉시 돌아가는 독립 모듈로서의 가치를 우선했습니다.

② 유지보수와 확장성

프로젝트가 커질수록 Props 경로를 추적하는 비용은 커집니다. Context를 활용하면 구조가 깊어져도 하위 부품을 자유롭게 추가/삭제할 수 있는 유연한 아키텍처를 가질 수 있습니다.

③ 응집도의 역설

use client를 통해 위젯을 캡슐화하면 외부와의 결합도는 낮아지고 내부 응집도는 높아집니다. 최종적으로 layout.jsx는 비즈니스 로직을 전혀 모른 채 아래와 같이 선언적인 형태를 유지하게 됩니다.

// #6. 최종 레이아웃 적용 (src/app/layout.jsx)
import { NavigationWidget } from '@/widgets';

export default function RootLayout({ children }) {
  return (
    <html lang="ko">
      <body>
        <LayoutContainer nav={<NavigationWidget />}>
          {children}
        </LayoutContainer>
      </body>
    </html>
  );
}

6. 🏁 마치며: 최선의 선택

모든 기술 선택에는 트레이드오프가 존재합니다. 이번 설계는 "서버 컴포넌트의 순수성"과 "위젯 아키텍처의 편리함" 사이의 균형점을 찾는 과정이었습니다.

설계에 정답은 없지만, 자신의 철학을 코드로 녹여내고 그 이유를 증명하는 과정이 시니어 개발자로 가는 핵심임을 다시 한번 체감했습니다.

👉 프로젝트 라이브 데모 바로가기

목차

1. 문제: 왜 클라이언트에서 인증 API 호출이 실패할까?
2. 첫 번째 시도: 클라이언트 컴포넌트에서 직접 호출 (실패)
3. 두 번째 시도: 서버 컴포넌트에서 데이터 패칭 (성공)
4. 세 번째 시도: API Route(프록시) + 클라이언트 컴포넌트 (성공)
5. 최종 정리: Next.js에서 인증이 필요한 외부 API는 반드시 서버(API Route, 서버 컴포넌트)에서 호출하자!
6. 회고

1. 문제: 왜 클라이언트에서 인증 API 호출이 실패할까?

Next.js 15에서 조직의 GitHub 레포지토리 목록을 가져오는 기능을 만들고 싶었습니다.
처음에는 단순히 클라이언트 컴포넌트에서 fetch로 GitHub API를 호출하면 될 거라 생각했습니다.

하지만,

• 401 Unauthorized
• CORS 에러
• 환경변수 노출 불가

등의 문제에 부딪혔습니다.

2. 첫 번째 시도: 클라이언트 컴포넌트에서 직접 호출 (실패)

처음엔 아래처럼 작성했습니다.

// app/org-test/page.jsx
"use client";
import { useState } from "react";
import { getOrgRepos } from "../data"; // 서버에서 인증 토큰을 붙여 fetch하는 함수

export default function OrgTestPage() {
  const [orgName, setOrgName] = useState("");
  const [repos, setRepos] = useState([]);

  // ❌ 브라우저에서 직접 서버 함수 호출
  const handleFetch = async () => {
    const data = await getOrgRepos(orgName);
    setRepos(data);
  };

  return (
    <div>
      <input value={orgName} onChange={e => setOrgName(e.target.value)} />
      <button onClick={handleFetch}>레포 가져오기</button>
      <ul>
        {repos.map(repo => <li key={repo.id}>{repo.name}</li>)}
      </ul>
    </div>
  );
}

// app/data.js
export async function getOrgRepos(orgName) {
  const res = await fetch(
    `https://api.github.com/orgs/${orgName}/repos?per_page=100`,
    {
      headers: { Authorization: `Bearer ${process.env.GH_TOKEN}` }, // 환경변수 사용
    }
  );
  if (!res.ok) {
    // 에러 처리
    return [];
  }
  return res.json();
}

문제점

• 브라우저에서는 환경변수(GH_TOKEN)에 접근할 수 없음
• 인증 헤더가 누락되어 401 에러 발생
• CORS 정책에 막힘

3. 두 번째 시도: 서버 컴포넌트에서 데이터 패칭 (성공)

Next.js의 서버 컴포넌트는 서버에서만 실행되므로, 환경변수와 인증 토큰을 안전하게 사용할 수 있습니다.

// app/org-test/page.jsx
import { getOrgRepos } from "../data";

export default async function OrgTestPage() {
  const orgName = "preOnBorading-Idle";
  // ✅ 서버에서 환경변수(GH_TOKEN)로 안전하게 fetch
  const repos = await getOrgRepos(orgName);

  return (
    <div>
      <h1>조직명: {orgName}</h1>
      <ul>
        {repos.map(repo => <li key={repo.id}>{repo.name}</li>)}
      </ul>
    </div>
  );
}

결과

• 서버에서 안전하게 인증 토큰을 사용해 GitHub API 호출 성공
• 브라우저에는 토큰이 노출되지 않음

4. 세 번째 시도: API Route(프록시) + 클라이언트 컴포넌트 (성공)

클라이언트 컴포넌트에서 직접 외부 API를 호출하는 대신, 내 서버의 API Route(프록시)를 통해 데이터를 받아오는 구조로 변경했습니다.

4-1. API Route 생성 (app/api/org-repos/route.js)

// app/api/org-repos/route.js
export async function GET(request) {
  const { searchParams } = new URL(request.url);
  const org = searchParams.get("org");
  const response = await fetch(
    `https://api.github.com/orgs/${org}/repos?per_page=100`,
    {
      headers: { Authorization: `Bearer ${process.env.GH_TOKEN}` },
    }
  );
  const data = await response.json();
  return Response.json(data, { status: response.status });
}

4-2. 클라이언트 컴포넌트에서 API Route로 요청

// app/org-test/page.jsx
"use client";
import { useState } from "react";

export default function OrgTestPage() {
  const [orgName, setOrgName] = useState("");
  const [repos, setRepos] = useState([]);

  // ✅ 내 서버의 API Route로만 요청
  const handleFetch = async () => {
    const res = await fetch(`/api/org-repos?org=${encodeURIComponent(orgName)}`);
    const data = await res.json();
    setRepos(data);
  };

  return (
    <div>
      <input value={orgName} onChange={e => setOrgName(e.target.value)} />
      <button onClick={handleFetch}>레포 가져오기</button>
      <ul>
        {repos.map(repo => <li key={repo.id}>{repo.name}</li>)}
      </ul>
    </div>
  );
}

결과

• 브라우저에서는 내 서버의 API Route(/api/org-repos)로만 요청
• 서버(API Route)에서 환경변수/인증 토큰을 사용해 GitHub API에 안전하게 요청
• 브라우저에는 인증 정보가 노출되지 않으면서, 정상적으로 데이터가 출력됨

5. ✅ 최종 정리: Next.js에서 인증이 필요한 외부 API는 반드시 서버(API Route, 서버 컴포넌트)에서 호출하자!

• 브라우저(클라이언트 컴포넌트)에서는 외부 API에 직접 요청하지 않는다.
  • 인증 정보 노출, 401 에러, CORS 문제 등 다양한 위험이 있다.
• API Route(프록시) 또는 서버 컴포넌트에서만 외부 API와 통신한다.
  • 환경변수(토큰)를 안전하게 사용할 수 있고, 보안과 CORS 문제를 모두 해결할 수 있다.
• 클라이언트 컴포넌트에서는 내 서버의 API Route만 호출한다.
  • 서버가 외부 API와 통신한 결과만 받아서 화면에 렌더링한다.
• Next.js 15의 app/api 구조를 활용하면, 별도의 백엔드 없이도 안전하고 효율적으로 API 연동이 가능하다.

6. 회고

동적 입력/상호작용이 필요하면 프록시(API Route), 정적 데이터는 서버 컴포넌트에서 직접 패칭!

처음엔 클라이언트에서 바로 외부 API를 호출하려다 401 에러에 막혀서 당황했지만, 이번 경험을 통해서 동적 입력이 필요할 땐 프록시(API Route)를 사용하고 정적 데이터는 서버 컴포넌트를 써야 한다는 걸 이번에 확실히 배웠다.

기본적인 에러 유형

API 호출 실패는 크게 3가지 레이어에서 발생할 수 있습니다. 각 레이어가 “어떤 오류인지”를 구분해야, 그에 맞는 처리를 할 수 있습니다.

Transport-level 에러

• ** HTTP 프로토콜** 수준에서 리턴된 오류입니다.

• 예시: 서버가 4xx/5xx 상태 코드를 응답했을 때

  HTTP/1.1 404 Not Found
  { "message": "Not Found" }

  HTTP/1.1 500 Internal Server Error
  <html>…서버 오류 페이지…</html>

    // Fetch
  try {
  const res = await fetch('/api/data')
  // HTTP 오류라도 res.ok가 false면 직접 예외를 던져야 함
  if (!res.ok) throw new Error('요청 실패')
  const data = await res.json()
  } catch (err) {
    console.error(err) // 어떤 상태 코드인지 알 수 없음
  }
  
  // Axios
  try {
  const { data } = await axios.get('/api/data')
  } catch (err) {
  // err.response?.status에 접근해야 401/500 구분 가능
  console.error(err) 
  }

• 특징:

  • HTTP 상태 코드 자체가 실패를 의미
  • Fetch는 res.ok 검사, Axios는 자동으로 AxiosError를 던짐
  • 본문 형식(JSON, HTML 등)이 일정치 않아 파싱 로직이 복잡해질 수 있음

Business-level 에러

• HTTP 요청은 성공(200 OK)이지만, 응답 바디 내부에서 “비즈니스 로직 실패”로 표시된 오류입니다.

• 예시:

  • RESTful: { success: false, code: 'X', message: '…' }
  • 레거시: { result: 0, message: '…' }

  HTTP/1.1 200 OK
  Content-Type: application/json
  
  {
  "success": false,
  "code": "INVALID_INPUT",
  "message": "이름을 입력해주세요."
  }

  HTTP/1.1 200 OK
  Content-Type: application/json
  
  {
  "result": 0,
  "message": "비밀번호가 일치하지 않습니다."
  }

• 특징:

  • HTTP 200이지만 애플리케이션 로직에서 실패로 간주
  • success·code·result 등 필드명이 API마다 달라, 매번 커스텀 판별 코드가 필요

Network-level 에러

• 요청이 서버에 도달하지 못하거나, 응답 자체를 받지 못했을 때 발생하는 오류입니다.

• 예시:

  • 인터넷 끊김, DNS 실패, CORS 차단
  • 클라이언트 타임아웃 설정 초과

  // Fetch
  fetch('/api/data')
    .catch(err => console.error('Network Error:', err.message))
  
  // Axios
  axios.get('/api/data')
    .catch(err => {
      if (!err.response) {
        console.error('Network or CORS Error:', err.message)
      }
    })

• 특징:

  • err.response가 undefined이므로 HTTP 상태를 알 수 없음
  • 재시도, 오프라인 처리, 사용자 안내(UI) 등을 별도 구현해야 함

전역화된 에러 처리 전략

API 호출 중 발생하는 오류를 적절히 처리하지 않으면, 사용자 경험도 망가지고 디버깅도 어려워집니다. 특히 RESTful API가 아닌 레거시 응답 형식, 네트워크 끊김, 서버 내부 오류까지 모두 포괄하려면 단순한 try/catch를 넘어서 전역화된 에러 처리 전략이 필요합니다.

🔑 구현한 방법

ApiError

• HTTP·네트워크 오류와 비즈니스 실패를 하나로 묶어 전달
• message, status, code, cause를 포함해 일관된 에러 분기 지원

apiClient 인터셉터

• 모든 4xx/5xx·네트워크 예외를 ApiError로 변환
• 호출 코드에서는 instanceof ApiError만 체크하면 됨

safeAxios

• “통신은 성공했지만 비즈니스 로직 실패”(success: false 등) 감지
• validateSuccess·extractPayload 옵션으로 어떤 응답 구조도 재사용 가능

Global Error Handler (handleApiError)

• 에러 메시지 토스트, 로그인 리다이렉트, Sentry 로깅 등을 한곳에서 관리
• React Query onError → 전역 설정으로 중복 제거

ApiError - Error형태 정의

export class ApiError extends Error {
  readonly name = 'ApiError'
  readonly status?: number    // HTTP 상태 코드
  readonly code?: string      // 서버 비즈니스 오류 식별자
  readonly cause?: unknown    // 원본 응답이나 내부 예외

  constructor(message: string, options?: {status?:number;code?:string;cause?:unknown}) {
    super(message)
    this.status = options?.status
    this.code   = options?.code
    this.cause  = options?.cause
    Error.captureStackTrace?.(this, ApiError)
  }
}

• 왜 필요한가?

  • 기본 Error엔 status나 code 같은 메타정보가 없습니다.
  • ApiError의 메타정보를 활용해서 분기처리가 가능해집니다.

apiClient 인터셉터 - HTTP/네트워크 오류 일원화

const apiClient = axios.create({ baseURL, timeout:10000 })
apiClient.interceptors.response.use(
  response => response,
  err => {
    const status = err.response?.status
    const data   = err.response?.data ?? {}
    const msg    = data.message || err.message || '서버 오류 발생'
    throw new ApiError(msg, { status, code: data.code, cause: data })
  }
)

• 무엇을 하나?

  • 4xx/5xx, 네트워크 끊김 등 axios가 던지는 모든 에러를 가로채서 ApiError로 변환합니다.
  • 이후 호출 코드에선 axios.isAxiosError 체크 대신 단순 err instanceof ApiError만 쓰면 됩니다.

safeAxios - 비즈니스 실패 감지 + 데이터 추출

async function safeAxios<T>(
  config: AxiosRequestConfig,
  options?: {
    validateSuccess?: (data:any) => boolean,
    extractPayload?: (data:any) => T
  }
): Promise<T> {
  const res  = await apiClient.request(config)    // HTTP 레벨은 인터셉터가 처리
  const data = res.data ?? {}

  // 1) 비즈니스 실패 감지
  const isSuccess = options?.validateSuccess?.(data) ?? data.success !== false
  if (!isSuccess) throw new ApiError(data.message||'요청 실패', { status:res.status, code:data.code, cause:data })

  // 2) 필요한 부분만 꺼내기
  return options?.extractPayload?.(data) ?? (data.data ?? data)
}

• 왜 나눴나?

  • apiClient는 “통신 실패”만,
  • safeAxios는 “통신은 됐는데 비즈니스 로직상 실패”를 처리합니다.
  • validateSuccess/extractPayload 옵션으로 어떤 응답 구조도 유연하게 대응 가능합니다.

Global Error Handler - UX와 로깅 통합

function handleApiError(err: unknown) {
  if (err instanceof ApiError) {
    if (err.status === 401) return navigate('/login')
    toast.error(err.message)
    Sentry.captureException(err)
  } else {
    toast.error('알 수 없는 오류')
  }
}

• 어디서 쓰나?

  • React Query onError
  • 컴포넌트 catch 블록
  • 전역 에러 바운더리 등

React Query 전역 설정

const queryClient = new QueryClient({
  defaultOptions: {
    queries:   { onError: handleApiError },
    mutations:{ onError: handleApiError },
  }
})

• 장점

  • 모든 useQuery/useMutation에서 중복 없이 일관된 에러 UX 보장

이렇게 ApiError, apiClient 인터셉터, safeAxios, 그리고 Global Error Handler를 조합함으로써 모든 API 호출에 대해 일관된 에러 처리 체계를 확립할 수 있었습니다. 이 코드를 적용한 뒤에는 에러 대응 로직이 한눈에 명확해지고, 유지보수성과 시스템 안정성이 크게 향상된 것을 실감하고 있습니다.

Supabase의 Storage를 이용해 프로필 이미지를 업로드하고 불러오는 기능을 구현하면서,
React Query와 Zustand Store, API 서비스 레이어를 역할별로 명확하게 분리한 구조를 소개합니다.

🧩 문제 인식

처음에는 컴포넌트 내부에서 Supabase API를 직접 호출하고,
업로드나 이미지 조회 상태도 모두 컴포넌트에서 관리하고 있었습니다.

하지만 다음과 같은 문제가 발생했죠:

• ✅ 컴포넌트가 너무 많은 책임을 가짐 (API 호출 + 상태 관리 + 로직)
• ✅ 다른 페이지에서 재사용하려면 같은 로직을 반복해야 함
• ✅ 테스트와 유지보수가 어려움

🛠 구조 설계 방향

이런 문제를 해결하기 위해 다음과 같이 역할을 분리했습니다.

📦 1. 서비스 레이어 (profileService.ts)

export const profileService = {
  async uploadProfileImage(file: File, userId: string) {
    const { data, error } = await supabase.storage
      .from('images')
      .upload(`profile/${userId}`, file, { upsert: true })
    if (error) throw error
    return data
  },

  async getProfileImageUrl(userId: string): Promise<string> {
    const { data } = supabase.storage.from('images').getPublicUrl(`profile/${userId}`)
    if (!data?.publicUrl) throw new Error('이미지 URL이 없습니다.')
    return data.publicUrl
  },
}

• 👉 Supabase 호출만 담당
• 👉 캐시 무효화나 토스트는 하지 않음 (퓨어 로직만)

⚙️ 2. 쿼리 훅 (useProfileImageSuspenseQuery.ts, useUploadProfileImageMutation.ts)

export const useProfileImageSuspenseQuery = (profileId: string) =>
  useSuspenseQuery({
    queryKey: profileKeys.image(profileId),
    queryFn: () => profileService.getProfileImageUrl(profileId),
  })

export const useUploadProfileImageMutation = (profileId: string) => {
  const queryClient = useQueryClient()
  return useMutation({
    mutationFn: ({ file }) => profileService.uploadProfileImage(file, profileId),
    meta: {
      toastError: true,
      toastSuccess: true,
      toastSuccessMessage: '프로필 이미지가 정상적으로 업로드되었습니다',
    },
    onSuccess: () => {
      queryClient.invalidateQueries({ queryKey: profileKeys.detail(profileId) })
      queryClient.invalidateQueries({ queryKey: profileKeys.image(profileId) })
    },
    retry: 0,
  })
}

• 👉 쿼리 로직은 여기서 끝
• 👉 캐시 무효화, 토스트 등 부가 처리도 훅 내부에서 관리

🎨 3. 사용 예시 (컴포넌트)

const profileId = useUserStore((s) => s.profileId)
const { data: uploadedUrl } = useProfileImageSuspenseQuery(profileId)
const uploadMutation = useUploadProfileImageMutation(profileId)

• ✅ 컴포넌트는 데이터를 가져오기만 하면 됨
• ✅ uploadedUrl만 있으면 이미지를 그릴 수 있고
• ✅ uploadMutation.mutate({ file })만 호출하면 끝

✅ 구조 리팩터링 후의 이점

✍️ 마무리

이번 구조 리팩터링을 통해 컴포넌트는 순수 UI만 담당하도록 정리했고,
비즈니스 로직과 API 호출은 퓨어한 서비스 함수와 React Query 훅으로 분리했습니다.

👇 필요한 데이터만 넘기면 되니까…

const uploadMutation = useUploadProfileImageMutation(profileId)
uploadMutation.mutate({ file })

서비스의 규모가 커질수록 이런 구조가 협업과 유지보수에서 진가를 발휘합니다.
당신의 프로젝트에도 이 구조를 한번 적용해보세요! 😊

이 글에서는 이 두 가지 도구가 어떤 역할을 하고, 어떻게 측정 결과를 활용했는지 구체적으로 공유하려고 합니다.

😊 목차

1. Core Web Vitals란 무엇인가
2. 각 지표 설명 + 실측 적용 사례
3. Lighthouse란 무엇이고, 왜 같이 써야 하는가
4. 프로젝트에 어떻게 적용했고 어떤 결과를 얻었는가
5. 결론 및 인사이트

✅ Core Web Vitals란?

Core Web Vitals는 Google이 발표한 웹 성능 핵심 지표 세트로, 실제 사용자 환경에서의 경험 품질(User Experience)을 수치로 측정하는 데 초점을 맞춥니다.

크게 세 가지 지표로 구성되며, 각각은 웹사이트에서 사용자가 체감할 수 있는 가장 핵심적인 영역을 다루고 있습니다.

📊 주요 지표 분석 및 실측 결과

1. LCP (Largest Contentful Paint)

정의: 페이지 로딩이 시작된 시점부터 뷰포트 내 가장 큰 콘텐츠(주로 이미지 또는 텍스트 블록)가 화면에 완전히 렌더링되기까지의 시간을 측정합니다.

사용자 입장에서는 페이지가 얼마나 빨리 "보이는지"를 체감하는 데 핵심적인 지표입니다.

🧪 적용 사례

우리는 홈페이지(메인 리스트 뷰)를 대상으로 측정했습니다. 해당 페이지는 썸네일과 카드가 다수 포함되어 있어 LCP에 민감한 구조였습니다.

• 측정 결과: 2040ms
• Google 기준: 2500ms 이하면 "좋음"
  → 사용자가 큰 콘텐츠를 2초 내로 인지할 수 있어 성능이 우수한 것으로 평가되었습니다.

2. INP (Interaction to Next Paint)

정의: 사용자가 클릭, 탭, 키보드 입력 등의 상호작용을 했을 때, 그에 대한 시각적 반응(다음 렌더링)이 이뤄지기까지 걸린 시간을 측정합니다.

2024년부터 INP는 FID(First Input Delay)를 대체하는 공식 Core Web Vitals 반응성 지표로 채택되었습니다.

🧪 적용 사례

우리는 데이터 입력/수정이 빈번한 폼 페이지를 중심으로 INP를 측정했습니다. 해당 페이지에서는 실시간 검증, 오토세이브 등의 기능이 있어 반응성 측정이 매우 중요했습니다.

• 측정 결과: 96ms
• Google 기준: 200ms 이하면 "좋음"
  → 유저가 상호작용했을 때 빠르게 피드백이 이뤄졌으며, 전체적인 UX가 빠르고 민첩한 것으로 나타났습니다.

3. CLS (Cumulative Layout Shift)

정의: 페이지 로딩 중 발생하는 레이아웃 이동(예: 버튼이 밀리거나 광고가 늦게 떠서 내용이 아래로 밀리는 현상)의 누적 비율을 측정합니다.

예상치 못한 움직임은 사용자에게 혼란을 주고, 의도하지 않은 행동(예: 잘못된 클릭)을 유발할 수 있어 중요한 UX 요소입니다.

🧪 적용 사례

우리는 무한 스크롤 + 필터링 기능이 적용된 홈페이지 리스트 뷰에서 CLS를 측정했습니다.
콘텐츠가 동적으로 변경되고 레이아웃이 재정렬되는 시점이 있었기에 시각적 안정성 확인이 필요했습니다.

• 측정 결과: 0.002
• Google 기준: 0.1 이하면 "좋음"
  → 레이아웃 변화가 거의 없어 매우 안정적인 사용자 환경이 유지되고 있음을 확인했습니다.

🛠 Lighthouse는 어떤 역할을 할까?

Lighthouse는 Chrome DevTools에 내장된 웹 진단 도구로, 단순한 성능 측정에 그치지 않고 문제가 되는 요소와 개선 가이드를 함께 제공하는 것이 가장 큰 장점입니다.

📋 Lighthouse 진단 항목

1. Performance (성능): 페이지 속도, 요청 수, LCP, INP 등
2. Accessibility (접근성): 시멘틱 마크업, 대비, 키보드 네비게이션 등
3. Best Practices: HTTPS, 최신 JS 사용 여부, 보안 관련 사항
4. SEO: 메타 태그, 링크 구조, 크롤링 친화성 등
5. PWA: Progressive Web App 지원 여부

🔍 Lighthouse vs Core Web Vitals

📈 프로젝트에 어떻게 적용했는가?

1. 초기 진단: Lighthouse로 전체 페이지에 대한 성능 진단을 수행 → 개선이 필요한 영역 파악
2. 실제 사용자 기준 측정: Core Web Vitals를 통해 UX 품질 수치화 (LCP, INP, CLS 수치 확보)
3. 기준 설정: Google의 권장 범위를 기준으로 "좋음/보통/나쁨" 구간 설정
4. 리팩토링 우선순위 정렬: 응답 지연, DOM 크기, 이미지 최적화 등 항목 중심 개선
5. 지표 추적: 리팩토링 후 반복 측정을 통해 개선 효과 확인

🎯 최종 진단 결과 (Lighthouse 평균)

✍️ 결론 및 인사이트

이번 프로젝트를 통해 단순한 "속도 측정"에서 벗어나, 실제 사용자가 겪는 체감 성능을 정량화하고, 그 수치를 기반으로 한 리팩토링이 UX 품질을 크게 향상시킨다는 점을 경험할 수 있었습니다.

• Core Web Vitals는 UX를 직접 반영한 핵심 지표로써, 페이지가 실제로 얼마나 빠르고 안정적인지에 대한 사용자 중심의 판단 기준을 제공합니다.
• Lighthouse는 기술적인 관점에서 개선 포인트를 제시해주어, 두 도구는 함께 사용할 때 시너지가 큽니다.

성능을 단지 개발자의 시선이 아닌, 사용자의 입장에서 바라보는 것이 웹 품질을 향상시키는 첫걸음임을 다시 한 번 느꼈습니다.

import { create } from 'zustand'
export const use이름Store = create((set, get) => {
  return {
    상태: 초깃값,
    액션: 함수
  }
})

create 함수로 스토어를 생성합니다. create 함수의 콜백은 set, get 매개변수를 가지며, 이를 통해 상태를 변경하거나 조회할 수 있습니다. create 함수의 콜백이 반환하는 객체에서의 속성은 상태(State)이고, 메소드는 액션(Action)이라고 부릅니다. create 함수 호출에서 반환하는 스토어 훅(Hook)은, useCountStore와 같이 use 접두사와 Store 접미사로 명명해 각 컴포넌트에서 사용할 수 있습니다.

바로 사용해보자!

// src/store/useCountStore.ts
import { create } from 'zustand';

interface CountState {
  count: number;
  inc: () => void;
}

export const useCountStore = create<CountState>()((set) => ({
  count: 0,
  inc: () => set((s) => ({ count: s.count + 1 })),
}));

// App.tsx
const App = () => {
  const { count, inc } = useCountStore();
  return (
    <button onClick={inc}>
      Clicked {count} times
    </button>
  );
};

✅ 사용법이 매우 단순합니다.

2. 많이 사용되는 Slice 패턴으로 스토어 사용해보기

모듈별로 “slice”를 쪼개고 합치는 구조. 의존성 최소화 & 타입 분리에 유리합니다. (zustand.docs.pmnd.rs)

🟢 STEP 0 ― 기본 방식

// store.ts
import { create } from 'zustand';

export const useStore = create()((set) => ({
  count: 0,
  inc: () => set((s) => ({ count: s.count + 1 })),
  user: null as null | { name: string },
  login: (name: string) => set({ user: { name } }),
}));

🟡 STEP 1 ― 파일 분리 + 함수형 Slice

// slices/counterSlice.ts
export const createCounterSlice = (set) => ({
  count: 0,
  inc: () => set((s) => ({ count: s.count + 1 })),
});

// slices/userSlice.ts
export const createUserSlice = (set) => ({
  user: null as null | { name: string },
  login: (name: string) => set({ user: { name } }),
});

// store.ts
import { create } from 'zustand';
import { createCounterSlice } from './slices/counterSlice';
import { createUserSlice } from './slices/userSlice';

export const useStore = create()((set, get) => ({
  ...createCounterSlice(set, get),
  ...createUserSlice(set, get),
}));

이득 : 도메인별 파일 분리 → 도메인별 로직이 분리

🟠 STEP 2 ― Slice 타입 분리 & 재사용 액션

// types/counter.ts
export interface CounterSlice {
  count: number;
  inc: () => void;
}

// slices/counterSlice.ts
import { CounterSlice } from '../types/counter';

export const createCounterSlice = (
  set,
): CounterSlice => ({
  count: 0,
  inc: () => set((s) => ({ count: s.count + 1 })),
});

이득 :

• 각 Slice가 명시적 인터페이스를 갖게 되어 type확인이 가능

🟣 STEP 3 ― selectors.ts 도입

// selectors/counter.ts
import { useStore } from '../store';

export const useCount = () =>
  useStore((s) => s.count);               // 필요한 값만 호출

export const useInc = () =>
  useStore((s) => s.inc, (a, b) => a === b); // 필요한 함수만 호출

이득 :

• 컴포넌트가 필요한 값만 구독 → 불필요 렌더링 감소
• 컴포넌트 파일이 “UI 로직”에 집중, 스토어 호출은 한 줄

🔵 STEP 4 ― Immer·DevTools·Persist 한번에 래핑

import { create } from 'zustand';
import { devtools, persist, immer } from 'zustand/middleware';
import { createCounterSlice } from './slices/counterSlice';
import { createUserSlice } from './slices/userSlice';

export const useStore = create(
  devtools(
    persist(
      immer((set, get) => ({
        ...createCounterSlice(set, get),
        ...createUserSlice(set, get),
      })),
      {
        name: 'app-storage',
        partialize: (s) => ({ // persist 대상만 선택
          user: s.user,
        }),
      },
    ),
    { name: 'AppStore' },
  ),
);

이득 :

• 불변성(immer) + DevTools + 영속화를 Slice 코드 변경 없이 장착
• partialize로 필요 필드만 저장 → 용량·보안 부담 ↓

🟤 STEP 5 ― 테스트·SSR 친화 Store Factory

🏭 Store Factory란?

“필요할 때마다 새로운 Zustand 스토어 인스턴스를 만들어 주는 함수”
 create() 를 직접 호출하는 대신 팩토리 함수를 정의해 두고, 거기서 fresh store를 리턴하도록 하는 패턴입니다.

1. 왜 필요한가?

2. 기본 형태

// makeStore.ts
import { createStore } from 'zustand';
import { createCounterSlice } from './slices/counterSlice';
import { createUserSlice } from './slices/userSlice';

export type RootState = CounterSlice & UserSlice;

export function makeStore(preloaded?: Partial<RootState>) {
  return createStore<RootState>()((set, get) => ({
    ...createCounterSlice(set, get),
    ...createUserSlice(set, get),
    ...preloaded,            // 초기 상태 오버라이드
  }));
}

• createStore (= vanilla 모드)로 리액트 의존 없이 스토어 인스턴스를 생성.
• preloaded 매개변수로 테스트·SSR에서 초기 값을 주입 가능.

3. 사용 예시

3‑1. CSR(브라우저) 싱글턴

// useClientStore.ts
import { useStore as useZustandStore } from 'zustand';
import { makeStore } from './makeStore';

const clientStore = makeStore();       // 탭 당 1개
export const useClientStore = <T,>(sel: (s: RootState) => T) =>
  useZustandStore(clientStore, sel);

3‑2. Next.js SSR

// pages/index.tsx
export async function getServerSideProps() {
  const store = makeStore();
  await store.getState().fetchInitialData();   // 서버에서 데이터 채우기
  return {
    props: { initialZustandState: store.getState() },
  };
}

클라이언트에서는 makeStore(props.initialZustandState) 로 하이드레이션.

3‑3. 테스트

test('counter increments', () => {
  const store = makeStore({ count: 5 });
  store.getState().inc();
  expect(store.getState().count).toBe(6);
});

4. 장단점

5. 언제 안 써도 되나?

• 순수 CSR SPA이고,
• 전역 스토어를 싱글턴 하나로 충분히 쓰며,
• SSR·멀티 인스턴스·라이브러리 배포 요구사항이 없다면

그냥 create() 한 번 호출해서 내보내는 싱글턴 스토어면 됩니다.
Store Factory는 “격리가 꼭 필요한 시나리오”에서만 도입하세요.

• Store Factory = 스토어 인스턴스를 만들어 주는 함수
• SSR, 테스트, 동적 UI, 패키지 개발처럼 상태 격리가 필요한 상황에서 유용
• 평범한 CSR 앱이라면 싱글턴 스토어로도 충분—필요할 때만 쓰자!

// makeStore.ts
import { StateCreator, StoreApi, createStore } from 'zustand';
import { createCounterSlice } from './slices/counterSlice';
import { createUserSlice } from './slices/userSlice';

export type RootState = CounterSlice & UserSlice;

export const makeStore = (preloaded?: Partial<RootState>): StoreApi<RootState> =>
  createStore<RootState>((set, get) => ({
    ...createCounterSlice(set, get),
    ...createUserSlice(set, get),
    ...preloaded,
  }));

// store.ts (CSR 전용 훅)
import { useStore as useZustandStore } from 'zustand';
import { makeStore } from './makeStore';

const store = makeStore();
export const useStore = <T,>(selector: (s: RootState) => T) =>
  useZustandStore(store, selector);

• 테스트: const testStore = makeStore({ count: 42 }) → 단위 테스트에서 원하는 초기 상태 주입
• Next.js: getServerSideProps 마다 makeStore() 호출 → 요청 간 데이터 격리

📌 최종 구조 요약

src/
 ├─ store/
 │   ├─ makeStore.ts          # SSR·테스트 겸용
 │   ├─ store.ts              # CSR 훅
 │   └─ slices/
 │       ├─ counterSlice.ts
 │       └─ userSlice.ts
 ├─ selectors/
 │   ├─ counter.ts
 │   └─ user.ts
 └─ types/
     ├─ counter.ts
     └─ user.ts

🟢 나아가기 ― React Query ✕ Zustand 

서버 상태(server state)는 React Query, UI·글로벌 상태(client state)는 Zustand에 맡기는 것이 정석입니다. 둘을 자연스럽게 엮는 3가지 패턴을 살펴봅니다.

7‑1. 필터 Slice → 쿼리 키 연동

// slices/filterSlice.ts
export interface FilterSlice {
  keyword: string;
  setKeyword: (k: string) => void;
}

export const createFilterSlice = (set): FilterSlice => ({
  keyword: '',
  setKeyword: (k) => set({ keyword: k }),
});

// Posts.tsx
import { useQuery } from '@tanstack/react-query';
import { useStore } from '@/store';

const fetchPosts = async (keyword: string) => {
  const res = await fetch(`/api/posts?search=${keyword}`);
  return res.json();
};

export default function Posts() {
  const keyword = useStore((s) => s.keyword);
  const { data, isLoading } = useQuery(['posts', keyword], () => fetchPosts(keyword));

  if (isLoading) return <p>Loading…</p>;
  return (
    <ul>
      {data.map((p) => (
        <li key={p.id}>{p.title}</li>
      ))}
    </ul>
  );
}

• 쿼리 키에 Zustand 값을 포함 → 키가 변하면 자동으로 refetch.
• React Query 캐시는 그대로, 필터 UI는 Zustand로 독립 유지.

7‑2. 액션에서 queryClient.invalidateQueries() 호출

import { queryClient } from '@/lib/queryClient';

export const createTodoSlice = (set) => ({
  addTodo: async (title: string) => {
    await fetch('/api/todos', { method: 'POST', body: JSON.stringify({ title }) });
    queryClient.invalidateQueries(['todos']);  // ✅ 리스트 새로고침
  },
});

• 비즈니스 액션 안에서 서버 호출 후 React Query 캐시 무효화.
• 컴포넌트는 별도 로직 없이 최신 목록을 받습니다.

7‑3. useQuery 결과를 Zustand에 동기화 (옵션)

서버 데이터를 전역에서 읽기 전용으로 여러 컴포넌트가 소비해야 할 때만 권장.

const { data } = useQuery(['settings'], fetchSettings, {
  onSuccess: (settings) => useStore.setState({ settings }),
});

• React Query가 캐싱·로딩·에러를 담당하고,
• Zustand는 다른 액션이 참조할 수 있는 전역 스냅샷을 보관.

핵심은 역할 분리: 서버 동기화는 React Query, 앱 로컬 상태는 Zustand가 맡고, 교집합은 쿼리 키 or 캐시 무효화로 느슨하게 연결합니다.

📌 최종 구조 요약

src/
 ├─ store/
 │   ├─ makeStore.ts          # SSR·테스트 겸용 스토어 팩토리
 │   ├─ useClientStore.ts     # CSR 전용 훅 (싱글턴)
 │   └─ slices/
 │       ├─ counterSlice.ts
 │       ├─ userSlice.ts
 │       └─ filterSlice.ts
 ├─ selectors/                # (선택) 공통 셀렉터 모음
 │   ├─ counter.ts
 │   └─ user.ts
 ├─ types/                    # Slice 인터페이스 정의
 │   ├─ counter.ts
 │   └─ user.ts
 ├─ lib/
 │   └─ queryClient.ts        # React‑Query 전역 클라이언트
 ├─ pages/ or components/ …   # UI 컴포넌트

✅ 구조 설계 체크리스트

• Slice는 상태·액션만: UI 의존 코드(React import) 금지 → 테스트 용이.
• 미들웨어 래핑은 한곳: useClientStore.ts에서 DevTools·Persist 등 통합.
• 폴더 깊이 최소화: 3‑depth를 넘기지 않도록 유지하면 탐색·import가 편해집니다.
• SSR/CSR 분기 명확: 서버 로직은 makeStore, 클라이언트 로직은 useClientStore로 분리.

이 구조를 베이스로 팀·프로젝트 규모에 맞춰 선택적으로 selectors/, types/ 폴더를 생략하거나 추가하면 됩니다.

하지만 동시에 이런 질문들이 생기죠:

• loader와 React Query는 언제 어떤 기준으로 써야 하지?
• 에러는 어디서 어떻게 잡지? Suspense랑 ErrorBoundary는 어떻게 엮어야 해?
• 캐싱은 누가, 어디서 해주는 거야?

이 포스팅에서는 이 모든 흐름을 실전 기준으로 정리해봅니다.

📍 loader vs React Query: 언제 어떤 걸 써야 할까?

✅ 3가지 케이스 요약표

1. 🔐 인증, 404 판단 → loader + errorElement

✔️ 목적

• 로그인하지 않은 사용자는 로그인 페이지로 리다이렉트
• 존재하지 않는 ID면 404 페이지 표시
• 데이터는 컴포넌트에서 따로 fetch

💡 라우터 코드

<Route
  path="/admin/posts/:id"
  loader={protectedPostLoader}
  element={<AdminPost />}
  errorElement={<ErrorPage />}
/>

💡 loader 예시

// protectedPostLoader.ts
export async function protectedPostLoader({ params }) {
  const user = await checkAuth();
  if (!user) {
    return redirect('/login'); // 🔐 인증 체크
  }

  const res = await fetch(`/api/posts/${params.id}`);
  if (res.status === 404) {
    throw new Response('Not Found', { status: 404 }); // ❗ 존재하지 않으면 404
  }

  return null;
}

💡 컴포넌트 예시

export default function AdminPost() {
  const { id } = useParams();

  const { data} = useQuery({
    queryKey: ['post', id],
    queryFn: () => fetchPost(id), // ✅ 실제 데이터 요청은 여기서
    suspense: false,
    useErrorBoundary: false,
  });

  return (
    <div>
      <h1>{data.title}</h1>
      <p>{data.content}</p>
    </div>
  );
}

2. 🔁 일반 페이지 → React Query 단독

✔️ 목적

• 필터링, 탭, 리스트 페이지
• 인증, 404 등의 판단 불필요
• 빠른 캐싱과 상태 관리가 목적

💡 라우터 코드

<Route
  path="/products"
  element={
    <ErrorBoundary fallback={<ErrorPage />}>
      <Suspense fallback={<Loading />}>
        <ProductList />
      </Suspense>
    </ErrorBoundary>
  }
/>

💡 컴포넌트 예시

function ProductList() {
  const { data } = useQuery({
    queryKey: ['products'],
    queryFn: fetchProducts,
    suspense: true,
    useErrorBoundary: true,
    staleTime: 60_000, // 1분 캐시
  });

  return (
    <ul>
      {data.map((product) => (
        <li key={product.id}>{product.name}</li>
      ))}
    </ul>
  );
}

3. 🚀 빠른 퍼스트 로딩 + 캐싱 → loader + React Query 조합

✔️ 목적

• 페이지 진입 전에 loader로 먼저 fetch
• 컴포넌트는 React Query 캐시 재사용
• UX + 퍼포먼스 균형

💡 라우터 코드

<Route
  path="/posts"
  loader={postsLoader}
  element={
    <ErrorBoundary fallback={<ErrorPage />}>
      <Suspense fallback={<Loading />}>
          <PostsRoute />
      </Suspense>
    </ErrorBoundary>
  }
  errorElement={<ErrorPage />}
/>

💡 loader

export async function postsLoader() {
  const queryClient = new QueryClient();

  await queryClient.prefetchQuery({
    queryKey: ['posts'],
    queryFn: fetchPosts,
    staleTime: 10_000,
  });

  return {
    dehydratedState: dehydrate(queryClient),
  };
}

💡 컴포넌트

function PostsRoute() {
  const { dehydratedState } = useLoaderData();
  const queryClient = new QueryClient();

  return (
    <QueryClientProvider client={queryClient}>
      <Hydrate state={dehydratedState}>
        <Suspense fallback={<Loading />}>
          <Posts />
        </Suspense>
      </Hydrate>
    </QueryClientProvider>
  );
}

💡 Posts.tsx

function Posts() {
  const { data } = useQuery({
    queryKey: ['posts'],
    queryFn: fetchPosts,
    suspense: true,
    useErrorBoundary: true,
    staleTime: 10_000,
  });

  return <ul>{data.map(p => <li key={p.id}>{p.title}</li>)}</ul>;
}

⚠️ loader-only의 단점

loader는 매번 페이지 이동 시마다 fetch 요청을 다시 보냅니다.
즉, 같은 페이지를 왔다 갔다 해도 캐시 재사용 없이 계속 로딩됩니다.

→ 사용자 입장에선 UI가 깜빡이고 느려지는 경험
→ 서버 입장에선 불필요한 요청 증가

🧱 에러 처리 구조: 에러는 어디서 어떻게 처리하나?

📦 loader에서 발생한 에러 예시

export async function postsLoader() {
  const res = await fetch('/api/posts');

  if (!res.ok) {
    throw new Response('Not Found', { status: 404 });
  }

  return res.json();
}

// ErrorPage.tsx
const error = useRouteError();
if (isRouteErrorResponse(error)) {
  return <p>{error.status} - {error.statusText}</p>;
}

⚠️ errorElement를 쓸 땐 loader가 반드시 있어야 함!

// 잘못된 구조 ❌ (loader 없음 + errorElement 있음 → 작동안함)
<Route
  path="/posts"
  element={<Posts />}
  errorElement={<ErrorPage />} // 작동 안 함!
/>

// 올바른 구조 ✅
<Route
  path="/posts"
  loader={postsLoader}
  element={<Posts />}
  errorElement={<ErrorPage />}
 />

✅ staleTime은 얼마나 주는 게 좋을까?

staleTime: 10000 // 10초 동안 "fresh"로 간주 → fetch 생략

상황별 추천 기준

🎯 최종 추천 전략 요약

✅ loader + React Query 조합

✅ 반대로 React Query만 쓰는 게 나은 페이지

✅ 마무리

loader는 라우팅 제어에,
React Query는 데이터 캐싱과 UX 최적화에 집중!

너무 많이 쓰기보다는, 필요한 곳에만 loader를 정확히 사용하는 게 진짜 최적화입니다.

앱 프론트엔드(안드로이드,IOS)는 프로그램 자체를 앱 스토어를 통해서 사용자가 다운받기 때문에 백엔드에 요청만 보낸다. 하지만, 웹 프론트엔드(브라우저)는 사용자들한테 백엔드에서 관련된 프로그램을 전송하기 때문에 앱 프론트엔드 개발자보다 상대적으로 밀접하게 연결되어 있다.

가장 기본적인 인프라

생각해보기: 사용자가 많아져서 요청이 늘어나면 어떻게 될까?

서버에 요청이 많아질테니 서버의 응답속도를 보장하기 위해서 방안을 마련해야 한다 -> 스케일 아웃(Scale Out) or 스케일 업(Scale Up)

서버에 에러가 발생할 수 있기 때문에 서버의 성능을 높히는 방식보다는 서버의 개수를 늘리는 스케일 아웃 방식이 선호됨

스케일 아웃(Scale Out) / 스케일 인(Scale In) 서버(컴퓨터)의 개수를 늘리는 것 / 서버(컴퓨터)의 개수를 줄이는 것

스케일 업(Scale Up) / 스케일 다운(Scale Down) 서버(컴퓨터)의 성능을 높이는 것 / 서버(컴퓨터)의 성능을 낮추는 것

알아두자

DNS(Domain Name System) IP 주소(예: 192.0.2.44)를 사람이 읽을 수 있는 도메인 이름(예: www.amazon.com)으로 변환해주는 시스템

LB(Load Balancing) 애플리케이션을 지원하는 리소스 풀 전체에 네트워크 트래픽을 균등하게 배포하는 방법

Auto Scaling 클라우드 서비스의 핵심기술로 CPU, 메모리, 디스크, 네트워크 트래픽과 같은 시스템 자원들을 모니터링하여 서버 사이즈를 자동으로 조절 하는 방법

VPC(Virtual Private Cloud) 격리된 가상 네트워크 환경에서 리소스를 사용하는 방법

아마존에서 제공하는 서비스를 활용한 Scale Out

EC2(Elastic Compute Cloud) - 서버역할

클라우드 환경에서 컴퓨터를 사용할 수 있게 빌려주는 서비스

*컴퓨터만 빌려주는 방식이기 때문에 모든 설정을 내가 해야함

Route53 - DNS역할

DNS 역할과 설정된 서버 컴퓨터와 매칭하는 역할을 하는 서비스

ELB(Elastic Load Balancing) - Load Balancing 역할

둘 이상의 가용 영역에서 EC2 인스턴스, 컨테이너, IP 주소 등 여러 대상에 걸쳐 수신되는 트래픽을 자동으로 분산해주는 서비스

ASG(Auto Scaling Group) - Auto Scaling 역할

EC2와 같은 서비스를 그룹 단위로 구성하고 오토스케일링을 제공하는 서비스

정규 표현식

정규 표현식, 또는 정규식은 문자열에서 특정 문자 조합을 찾기 위한 패턴입니다.

정규 표현식 읽는 법

• 정규 표현식에서 슬래시(/) 안에 패턴을 넣고, 플래그를 통해 옵션을 줄 수 있습니다.

[출처]https://ji-musclecode.tistory.com/62

메타문자

정규표현식의 기초이자, 원래 그 문자가 뜻하는 바가 아닌 특별한 의미로 사용되는 문자열

메타문자 ( . )

한 문자를 매치합니다.

메타문자 ( + )

l이 1번 이상 반복된 경우(l,ll,lll…)을 매치합니다.

메타문자 ( | )

a 또는 b를 매치합니다.

메타문자 ( [ ] )

대괄호 안에 나열된 문자 e 또는 a를 매치합니다.

메타문자 ( - )

대/소문자 알파벳 A부터 Z까지 매치합니다.

메타문자 ( \ )

메타문자(.)는 패턴에 사용될 수 없지만 .를 정상적으로 매치합니다. *대괄호 안에 있는 메타문자는 메타문자()를 사용하지 않아도 기본적으로 매치합니다.

플래그

정규표현식의 옵션이자, 패턴 뒤에 붙여주는 문자열

예시 : /abc/

• g: /abc/g는 문자열 "abc abc abc"에서 모든 "abc"를 찾습니다.
• i: /abc/i는 "abc", "ABC", "AbC"와 모두 매치됩니다.

참고 자료

정규 표현식 - JavaScript | MDN

Regular expression syntax cheat sheet - JavaScript | MDN

• 컴파일러 vs 인터프리터 with.트랜스파일러
• TypeScript

학습 내용 정리

컴파일러 vs 인터프리터

컴파일러와 인터프리터는 모두 컴퓨터가 이해할 수 있는 기계어로 프로그램 코드를 변환하는 방식

컴파일러 (Compiler)

소스 코드를 전체를 기계어로 변환하여 실행 가능한 파일을 생성하는 프로그램

ex) C, C++, Rust, Go 등.

인터프리터 (Interpreter) - 스크립트 언어

소스 코드를 한 줄씩 읽어들이고 기계어로 변환하여 실행하는 프로그램

ex) Python, JavaScript, Ruby, PHP 등.

• ** JavaScript는 인터프리터 언어다.** → JavaScript는 소스 코드를 한 줄씩 읽어서 기계어로 변환하여 동작한다.

트랜스파일러

트랜스파일러는 사람이 이해할 수 있는 다른 언어로 프로그램 코드를 변환하는 방식

ex) Babel, tsc(TypeScript Compiler), EsBuild 등.

TypeScript

TypeScript 배경상황

• 브라우저가 실행할 수 있는 언어는 2가지가 있다.
  1. JavaScript
  2. WebAssembly(웹어셈블리)

TypeScript 특징

1. TypeScript를 브라우저에서 사용하려면 변환이 이루어져야 한다.

   → TypeScript는 트랜스파일러를 통해 JavaScript로 변환이 되어야 브라우저에서 실행이 가능하다.

2. TypeSciprt는 런타임 시점에서는 에러를 확인이 불가능하다.

   → TypeScript는 타입 안정성을 제공하는데 위와 같은 배경으로 인해서 IDE에서 오류를 통해서만 타입 안정성을 제공받을 수 있고 트랜스파일이 되어 JavaScript가 되면 런타임에서 확인이 불가능하다.

interface vs type aliases

• 무엇을 쓸지는 일관성 또는 의미적 엄밀함에 따라서 기준을 나눌 수 있다.

→ 어떤 기준으로 나눌지에 따라서 방법은 많기 때문에 일관성있게 작성만 되면 문제가 없다!

💡interface와 type기준 생각해보기

함수 혹은 컴포넌트를 만들게 되면 2가지의 기준이 생긴다.

1. 함수를 생성하는 관점 - 함수를 만드는 사람
2. 함수를 사용하는 관점 - 함수를 가져다 쓰는 사람

이런 상황에서 커뮤니케이션을 하려면 기준이 되는 interface가 있어야 한다. 그래서 자연스럽게 함수와 컴포넌트를 사용하는 사람은 interface를 통해서 타입을 명시해주는게 자연스럽다.

사용하는 사람은 컴포넌트에서 필요한 부분은 props로 넘기고, 함수에서 인자와 return 값을 통해서 사용한다.

Type은 형식의 규격과 같이 특정한 데이터를 정의할 때 사용할 수 있다.

ex) api 응답 데이터

→ api 응답 데이터도 사용자와 api가 통신하니까 interface로 볼 수 있지 않나?라고 생각이 들지만 특정한 데이터고 형식의 규격이라고 생각하고 접근하면 조금 납득이 될 수 있다.

알아두자

interface User{
    getName() : string; //function
    getName: () => string; //arrow function
}

1. TypeScript Enum은 javaScript로 변환되면 코드가 길어지고 결과값이 생각과 다를 수 있는 가능성이 있어서 사용을 지양한다.

• redux의 사용흐름
• useRef Hook 간단히 알아보기
• redux 코드 개선하기

학습 내용 정리

redux의 사용흐름

1. reducer(리듀서)를 생성하고, createStore 메소드를 이용해서 리듀서를 스토어에 연결합니다.

    // reducer.js
    export default function reducer(state, action) {
      if (state === undefined) { //초기값을 주려고 undefined설정
        return {
          user: null, 
          languages: [
            {
              name: "JavaScript",
              keyword: "Web Frontend",
            },
          ],
        };
      }
   
      // main.jsx
      import { legacy_createStore as createStore } from "redux";
      import reducer from "./reducer.js";
   
      const store = createStore(reducer); 

2. 사용하기 위한 컴포넌트의 상위 컴포넌트를 provider 컴포넌트로 감싸주고 store 속성에 생성해둔 스토어를 연결합니다.

      // main.jsx
      import { Provider } from "react-redux";
   
      <Provider store={store}>
        <App />
      </Provider>

3. 필요한 상태를 가져오기 위해서는 useSelector를 사용해서 가져온다.

   • (state) => state처럼 상태를 다 가져오는 것은 명시적이지 않기 떄문에 사용하려는 상태를 직접 전달하는 것이 좋다. → ❌ BAD: useSelector((state) => state) / ✅ GOOD: useSelector((state) => state.languages)

     //component.jsx
     import { useSelector } from "react-redux";
     
     export const Components = () => {
     const languages = useSelector((state) => state.languages); 
     }

4. 상태를 변화시키기 위해서는 useDispatch를 사용해서 action(액션)을 호출합니다.

   • 액션 type은 별도의 상수로 관리하는 것이 좋다.

     → ❌ BAD: add / ✅ GOOD: ADD_LANGUAGE

```jsx
//component.jsx
import { useDispatch } from "react-redux";

import { ADD_LANGUAGE } from "./action-type"

export const Components = () => {
const dispatch = useDispatch();

const addLanguage = () => {
  dispatch({
    type: ADD_LANGUAGE,
    name: "JavaScript",
  });
};
  return (
    <>
      <button onClick={addLanguage}>추가하기</button>
    </>
  );
}

//reducer.js
import { ADD_LANGUAGE } from "./action-type";

export default function reducer(state, action) {

  if (action.type === ADD_LANGUAGE) {
    return {
      ...state,
      languages: [
        ...state.languages,
        {
          name: action.name,
        },
      ],
    };
  }
}

// action-type.js
export const ADD_LANGUAGE = "ADD_LANGUAGE";
```

폼의 데이터를 처리하기 어렵다.

UI 업데이트 돔에 있지 않은 데이터를 참조하는 훅이 있다. → useRef

useRef

• UI 업데이트 돔에 있지 않는 데이터(렌더링에 필요하지 않는 값)를 참조하는 훅

폼과 관련된 데이터는 처리하기가 어렵다. 사용자의 이벤트를 처리하는건 어렵기 떄문에 이를 쉽게 지원하는 hook을 사용한다.

// input 요소를 생성하면 안에 value의 값이 있다.
const inputElement = document.querySelector('#myInput');
const inputValue = inputElement.value;

//useRef는 current라는 하나의 속성을 가지는 객체를 반환하는데,
//current 내부에 value의 값이 반환되도록 설계되어 있다.
inputRef = {
current: null,
};

사용 예시

const inputRef = useRef(null);

const addLanguage = () => {
  dispatch({
    type: ADD_LANGUAGE,
    name: inputRef.current.value,
  });
};

//input요소에 ref 속성에 ref를 연결한다.
<input type="text" ref={inputRef} onChange={addLanguage} />

redux 코드 개선하기

1. import { ADD_LANGUAGE } from "./action-type 를 사용해서 매번 type을 가져오는 것은 번거롭다. 이를 개선해보자.

// action-type.js
export const ADD_LANGUAGE = "ADD_LANGUAGE";

//data가 무엇이 될지 모르기 때문에 매개변수로 받아서 처리한다.
export const dispatchAddLang = (data) => ({
  type: ADD_LANGUAGE,
  ...data,
});

1. 1번 방식으로 하는 것은 사용자가 내부 로직을 이해하고 있어야 하는 종속성 문제가 있다. 이를 개선해보자.

// action-type.js
export const ADD_LANGUAGE = "ADD_LANGUAGE";

export const dispatchAddLang = (name, keyword) => ({
  type: ADD_LANGUAGE,
  name,
  keyword,
});

1. 아래처럼 2번 방식으로 동작하는 액션이 많이 생기는 바람에 동일한 로직이 반복되어 작성되는 문제가 생겼다. 이를 개선해보자.

export const ADD_LANGUAGE = "ADD_LANGUAGE";
export const EDIT_LANGUAGE = "EDIT_LANGUAGE";

export const dispatchAddLang = (name, keyword) => ({
  type: ADD_LANGUAGE,
  name,
  keyword,
});

export const dispatchEditLang = (name, keyword) => ({
  type: EDIT_LANGUAGE,
  name,
  keyword,
});

에자일 방법론은 전통적인 개발 방식인 폭포수(Waterfall) 모델과는 차별화된 접근을 가지고 있습니다. 이 방법론은 반복적이고 점진적인 개발을 통해 빠르게 결과물을 제공하고, 필요에 따라 변경 사항을 쉽게 반영할 수 있는 장점이 있습니다.

이미지출처

에자일의 필요성과 배경

소프트웨어 개발 환경은 지속적으로 변화하고 있으며, 이런 변화에 적절히 대응하기 위해서는 유연성이 필수적입니다. 고객의 요구사항은 프로젝트의 진행 중에도 변화할 수 있으며, 이러한 요구에 발빠르게 대응할 수 있는 개발 방법론이 필요해졌습니다. 에자일 방법론은 이러한 요구를 충족시키기 위해 개발된 것입니다.

에자일 방법론의 원칙

에자일 방법론의 기본 원칙은 고객의 최고의 가치를 제공하는 것입니다. 이는 고객과의 지속적인 협력을 통해 이루어지며, 팀원 간의 소통과 협업을 중요시합니다.

애자일 매니페스토 소개

애자일 방법론의 가장 중요한 문서 중 하나는 애자일 매니페스토입니다. 이 문서에는 에자일의 핵심 가치와 원칙이 담겨 있습니다. 애자일 매니페스토는 다음과 같은 네 가지 핵심 가치를 제시합니다.

• 개인과 상호작용을 프로세스와 도구보다 중요시한다.
• 작동하는 소프트웨어를 포괄적인 문서보다 중요시한다.
• 고객과의 협력을 계약 협상보다 중요시한다.
• 변화에 대한 반응을 계획을 따르는 것보다 중요시한다.

이미지출처

12가지 원칙

애자일 매니페스토에는 12가지 원칙이 포함되어 있습니다. 이 원칙들은 애자일 개발 팀이 따르는 기본적인 가이드라인 역할을 합니다. 이 중 몇 가지를 소개하자면:

• 고객의 만족은 최우선 목표입니다.
• 변화는 개발 주기의 어느 단계에서든 환영합니다.
• 빈번한 배포로 소프트웨어를 제공해야 합니다.

이외에도 여러 가지 원칙들이 있으며, 이들을 통해 팀은 고객의 요구를 충족시키기 위해 노력합니다.

에자일 방법론의 주요 프레임워크

에자일 방법론에는 여러 가지 주요 프레임워크가 존재합니다. 그 중에서 스크럼(Scrum), 칸반(Kanban), XP(익스트림 프로그래밍)가 널리 사용됩니다.

스크럼(Scrum)

스크럼은 에자일 방법론의 가장 대표적인 프레임워크 중 하나입니다. 이 방법론은 팀의 협업과 소통을 강조하며, 일정한 기간 내에 제품을 반복적으로 개선하는 방식으로 운영됩니다. 팀은 스프린트라는 짧은 주기를 설정하고, 이 주기 내에 목표를 달성하는 것을 목표로 합니다.

이미지 출처

스크럼의 구성 요소

스크럼은 주로 세 가지 역할로 구성됩니다: 제품 소유자(Product Owner), 스크럼 마스터(Scrum Master), 그리고 개발 팀입니다. 각 역할은 특정한 책임을 가지고 있으며, 팀원 간의 협력이 성공적인 스크럼을 위해 필수적입니다.

역할과 의무

• 제품 소유자 는 프로젝트의 비전과 우선 순위를 설정하고, 개발 팀과의 소통을 통해 고객의 요구를 반영합니다.
• 스크럼 마스터 는 팀이 스크럼을 올바르게 따르도록 돕고, 팀원 간의 장애물을 제거하는 역할을 합니다.
• 개발 팀 은 실제로 제품을 개발하는 역할을 맡습니다.

칸반(Kanban)

칸반은 지속적인 흐름과 시각화를 통해 팀의 작업 프로세스를 관리하는 방법론입니다. 칸반 보드는 작업이 진행되는 과정을 시각적으로 나타내어, 팀원들이 현재 진행 중인 작업을 쉽게 이해하고 관리할 수 있도록 돕습니다.

이미지출처

칸반의 기본 원칙

칸반의 주요 원칙은 명확하게 정의된 작업 프로세스를 유지하고, 작업 흐름을 시각적으로 보여주는 것입니다. 이를 통해 팀원들은 각 작업의 상태를 쉽게 파악할 수 있습니다.

칸반 보드 활용법

칸반 보드는 여러 가지 섹션으로 나뉘어져 있으며, 각 섹션은 작업의 상태를 나타냅니다. 예를 들어, "작업 대기", "진행 중", "완료"와 같은 상태로 나뉘어져 있으며, 각 작업의 진행 상태를 쉽게 확인할 수 있습니다. 이를 통해 팀원들은 작업의 진행 상황을 효과적으로 관리할 수 있습니다.

XP(익스트림 프로그래밍)

XP는 소프트웨어 개발의 품질을 높이기 위한 접근 방식입니다. 이 방법론은 고객과의 긴밀한 협력을 기반으로 하며, 테스트 주도 개발(TDD)과 같은 핵심 관행을 포함합니다.

XP의 핵심 관행

XP의 핵심 관행으로는 지속적인 통합, 테스트 주도 개발(TDD), 페어 프로그래밍 등이 있습니다. 이러한 방법론들은 소프트웨어의 품질을 높이는 데 큰 도움을 줍니다.

에자일 실천 방법

에자일 방법론을 실천하는 과정에는 여러 가지 단계가 있습니다. 스프린트 계획, 일일 스크럼 미팅, 회고 및 개선 등의 단계가 포함됩니다.

스프린트 계획 및 실행

스프린트 계획은 팀이 다음 스프린트에서 수행할 작업을 결정하는 단계입니다. 이 단계에서는 팀원들이 스프린트 동안의 목표와 작업을 명확히 정의합니다.

일일 스크럼 미팅

일일 스크럼 미팅은 팀원들이 하루 동안의 진행 상황을 공유하고, 각자의 작업을 조율하는 시간입니다. 이 미팅은 짧고 간결하게 진행되며, 팀 내의 소통을 활발하게 만들어 줍니다.

회고 및 개선

스프린트가 끝난 후, 팀은 회고를 통해 지난 스프린트 동안의 성과와 문제점을 분석합니다. 이를 통해 다음 스프린트에서의 개선점을 도출하고, 팀의 성장을 도모합니다.

에자일의 장점과 단점

에자일 방법론에는 여러 가지 장점과 단점이 존재합니다.

• 장점: 유연성, 고객 만족도, 팀 협업 에자일의 가장 큰 장점은 유연성입니다. 고객의 요구가 바뀔 때, 팀은 빠르게 이에 대응할 수 있습니다. 또한, 팀 간의 협력이 증진되어 더 나은 결과물을 생산할 수 있습니다.

• 단점: 초기 학습 곡선, 팀원 간의 의사소통 문제 반면, 에자일 방법론은 초기 학습 곡선이 가파를 수 있으며, 팀원 간의 의사소통 문제가 발생할 수 있습니다. 이는 팀의 운영에 큰 영향을 미칠 수 있습니다.

에자일 도입 사례

많은 조직들이 에자일 방법론을 도입하여 성공을 거두고 있습니다. 성공적인 도입 사례를 통해 어떻게 에자일을 잘 활용할 수 있는지 살펴보겠습니다.

성공적인 에자일 도입 사례

일부 기업들은 에자일 방법론을 통해 고객의 요구에 더욱 효과적으로 대응하고, 팀의 협업을 강화하는 성과를 얻었습니다.

실패 사례 및 교훈

그러나 에자일 도입이 항상 성공적인 것은 아닙니다. 일부 팀은 올바른 방법론을 따르지 않거나 팀원 간의 소통이 원활하지 않아 실패를 경험하기도 했습니다. 이러한 실패 사례를 통해 얻은 교훈은 향후 에자일을 도입하는 데 중요한 가이드라인이 됩니다.

에자일 도구 및 리소스

에자일 방법론을 효과적으로 구현하기 위해 다양한 도구와 리소스가 존재합니다. 대표적으로 JIRA, Trello와 같은 관리 도구가 있습니다. 이 도구들은 팀의 작업을 관리하고, 진행 상황을 시각화하는 데 유용합니다.

인기 있는 에자일 도구 소개 (JIRA, Trello 등)

• JIRA : 프로젝트 관리 및 이슈 추적 도구로, 에자일 팀에 최적화되어 있습니다.
• Trello : 직관적인 칸반 보드를 제공하여 작업 관리를 쉽게 할 수 있습니다. 참고할 만한 서적과 온라인 리소스 에자일 방법론에 대한 깊이 있는 이해를 위해 다양한 서적과 온라인 자료를 참고하는 것도 좋습니다. 여러 블로그와 강의에서 유용한 정보들을 찾아볼 수 있습니다.

상태 관리가 잘 이루어지지 않을 경우, 프롭스 드릴링(Prop Drilling) 문제를 발생시킬 수 있습니다. 이는 컴포넌트 간의 의존성을 높히기 때문에 의존성을 낮춰야만 데이터 흐름과 이벤트 처리를 쉽게 할 수 있습니다.

프롭스 드릴링(Prop Drilling)

• 여러 레벨의 컴포넌트가 있을 경우, 필요한 데이터가 최하위 컴포넌트까지 전달되기 위해 중간 컴포넌트이 이 데이터를 받아야 드릴처럼 밑으로 계속 전달하는 과정을 말합니다.

문제발생

• A 컴포넌트가 상태를 관리하고 B 컴포넌트가 A의 데이터를 사용하려고 할 때, B는 C에게 A의 데이터를 넘겨주고, C는 그 데이터를 받아서 UI를 렌더링해야 합니다. 이러한 방식은 상태 관리가 제대로 이루어지지 않아 데이터 흐름이 복잡해지고, 중간 컴포넌트를 거치는 과정에서 불필요한 데이터 전달이 증가하게 됩니다.

해결 방법: 상태관리 라이브러리(리덕스)를 통한 상태 관리

리덕스는 이러한 프롭스 드릴링 문제를 해결하는 데 매우 유용한 도구입니다.

리덕스

리덕스는 복잡한 애플리케이션의 상태 관리 및 데이터 흐름을 단순화하기 위한 JavaScript 라이브러리입니다. React와 함께 자주 사용되며, 전역 상태 관리의 필요성을 해결해줍니다. 이 글에서는 리덕스의 구조와 사용법, 그리고 리액트와의 관계에 대해 살펴보겠습니다.

리덕스의 데이터 흐름

리덕스는 데이터의 흐름을 일방향으로 유지하는 구조를 가지고 있습니다. 이를 통해 다음과 같은 과정을 거쳐 상태가 관리됩니다:

1. 액션 생성: 사용자의 상호작용으로 발생하는 이벤트에 대한 액션이 생성됩니다.
2. 액션 디스패치: 액션이 스토어에 전달되며, dispatch() 함수를 통해 호출됩니다.
3. 리듀서 호출: 현재 상태와 디스패치된 액션이 리듀서에 전달되어 새로운 상태를 반환합니다.
4. UI 업데이트: 상태가 변경되면, 관련 컴포넌트가 다시 렌더링되어 UI를 업데이트합니다.

리덕스의 기본 구조

• 스토어(Store): 애플리케이션의 상태를 저장하는 객체입니다. 스토어는 오직 하나만 존재해야 하며, 모든 상태 관리가 이 스토어를 통해 이루어집니다.
• 액션(Action): 상태의 변화를 설명하는 객체입니다. 액션 객체는 최소한 type 속성을 가져야 하며, 추가적인 데이터(payload)를 포함할 수 있습니다.
• 리듀서(Reducer): 액션을 처리하여 새로운 상태를 반환하는 순수 함수입니다. 현재 상태와 액션을 인자로 받아 다음 상태를 반환합니다.

리덕스 3가지 원칙

1. 진실은 하나의 근원으로부터 애플리케이션의 모든 상태는 하나의 저장소 안에 하나의 객체 트리 구조로 저장됩니다. =>스토어를 객체로 만들어라!

2. 상태는 읽기 전용이다 상태를 변화시키는 유일한 방법은 무슨 일이 벌어지는 지를 묘사하는 액션 객체를 전달하는 방법뿐입니다. =>모든 상태는 스토어에서 관리되며, 단순한 '액션'이라는 객체에 담아서만 상태를 변경한다.

3. 변화는 순수 함수로 작성되어야한다 액션에 의해 상태 트리가 어떻게 변화하는 지를 지정하기 위해 프로그래머는 순수 리듀서를 작성해야합니다. =>동일한 입력에 대해 항상 같은 결과를 반환하는 함수로 리듀서를 작성해야 됩니다.

👉JSX라 하며 JavaScript를 확장한 문법입니다. 👉JSX는 React “엘리먼트(element)” 를 생성합니다. -React 공식문서-

JSX(JavaScript XML)는 JavaScript에서 HTML과 유사한 구문을 사용하여 UI를 구성하는 문법입니다. React와 함께 사용되며, 개발자가 컴포넌트를 더 직관적으로 작성할 수 있도록 도와줍니다.

특징 7가지

1. Fragment Fragment는 여러 요소를 그룹화할 수 있는 방법입니다. React에서 컴포넌트를 반환할 때, 여러 개의 자식 요소를 반환해야 할 경우 Fragment를 사용하면 불필요한 DOM 요소를 생성하지 않고도 이를 처리할 수 있습니다.

import React from 'react';

const MyComponent = () => {
    return (
        <>
            <h1>제목</h1>
            <p>내용이 여기에 들어갑니다.</p>
        </>
    );
};

위의 예제에서 <>와 </>는 Fragment를 나타내며, 두 개의 자식 요소가 하나의 부모 요소에 포함되어 있습니다.

2. className JSX에서는 HTML의 class 속성을 className으로 사용해야 합니다. 이는 JavaScript의 예약어인 class와의 충돌을 피하기 위한 조치입니다. 따라서 CSS 클래스를 지정할 때는 항상 className을 사용해야 합니다.

<div className="my-class">안녕하세요!</div>

위의 코드에서 my-class라는 CSS 클래스가 div 요소에 적용됩니다.

3. HTML 태그 소문자 JSX에서는 HTML 태그를 소문자로 작성해야 합니다. 대문자로 작성하면 React는 이를 사용자 정의 컴포넌트로 인식하게 됩니다. 따라서 HTML 태그는 항상 소문자로 작성하는 것이 좋습니다.

// 올바른 예
const element = <div>Hello</div>;

// 잘못된 예 (React는 이를 사용자 정의 컴포넌트로 인식)
const element = <Div>Hello</Div>;

4. HTML 태그는 항상 닫아주기 JSX에서는 모든 HTML 태그를 반드시 닫아줘야 합니다. 이는 잘못된 HTML 구조를 방지하고, JSX 코드의 가독성을 높이는 데 기여합니다. 닫는 태그가 필요한 경우, 항상 명시적으로 닫아주는 것이 좋습니다.

// 올바른 예
<p>이것은 문단입니다.</p>
<img src="image.jpg" alt="이미지" />

// 잘못된 예
<p>이것은 문단입니다.</img>

5. JSX의 동적 표현식 JSX에서는 중괄호 {}를 사용하여 JavaScript 표현식을 삽입할 수 있습니다. 이를 통해 동적으로 값을 렌더링할 수 있습니다.

const name = "뤼튼";
const element = <h1>안녕하세요, {name}!</h1>;

6. 스타일링 방법 JSX에서는 여러 가지 방법으로 스타일을 적용할 수 있습니다. 여기에는 인라인 스타일, CSS 파일을 통한 스타일링, CSS 모듈, 그리고 Styled Components 등이 포함됩니다.

1. 인라인 스타일 JSX에서는 HTML의 style 속성을 사용하여 인라인 스타일을 적용할 수 있습니다. 이때 CSS 속성 이름은 카멜 케이스(camelCase)로 작성해야 하며, 값은 문자열로 지정합니다.

```jsx
const element = (
    <div style={{ color: 'blue', fontSize: '20px' }}>
        인라인 스타일 예제
    </div>
);
```

위의 예제에서 fontSize는 카멜 케이스로 작성되었고, 각각 문자열 값으로 지정되었습니다.

2. CSS 파일 CSS 파일을 생성하고 이를 컴포넌트에 import하여 스타일을 적용할 수 있습니다.

/* styles.css */
.my-class {
    color: red;
    font-size: 18px;
}

import './styles.css';

const element = <div className="my-class">CSS 파일 스타일 예제</div>;

이 방법은 스타일을 재사용하기 쉽고, CSS 파일에서 미디어 쿼리와 같은 복잡한 스타일링을 처리하는 데 유용합니다.

3. CSS 모듈 CSS 모듈은 클래스 이름을 지역화하여 같은 이름의 클래스를 다른 컴포넌트에서 충돌 없이 사용할 수 있도록 도와줍니다. CSS 파일의 이름을 [name].module.css로 지정해야 합니다.

/* styles.module.css */
.myClass {
    color: green;
    font-size: 22px;
}

import styles from './styles.module.css';

const element = <div className={styles.myClass}>CSS 모듈 스타일 예제</div>;

이 방법은 컴포넌트 간의 스타일 충돌을 방지하고, 유지보수를 쉽게 합니다.

4. Styled Components Styled Components는 CSS-in-JS 라이브러리로, JavaScript 파일 내에서 컴포넌트의 스타일을 정의할 수 있게 해줍니다. 이 방법은 스타일과 로직을 함께 묶을 수 있어 코드의 가독성을 높입니다.

import styled from 'styled-components';

const StyledDiv = styled.div`
    color: purple;
    font-size: 24px;
`;

const element = <StyledDiv>Styled Components 예제</StyledDiv>;

Styled Components를 사용하면 컴포넌트에 스타일을 적용할 때 더 많은 유연성을 제공하며, 동적 스타일링도 쉽게 처리할 수 있습니다.

7. 이벤트 처리 JSX에서는 이벤트 핸들러를 지정할 수 있으며, JavaScript 함수와의 연결이 간편합니다.

const handleClick = () => {
    alert('클릭되었습니다!');
};

const element = <button onClick={handleClick}>클릭하세요!</button>;

부수효과 3가지

1. UI 가독성이 올라간다 JSX는 HTML과 유사한 구문을 사용하여 UI를 구성하기 때문에, 코드를 읽고 이해하기가 쉽습니다. 개발자는 UI 구조를 직관적으로 파악할 수 있으며, HTML 요소와 JavaScript 로직이 함께 표현되므로 전체적인 흐름을 쉽게 이해할 수 있습니다. 이는 팀원 간의 협업을 원활하게 하고, 유지보수를 용이하게 합니다.

// Card.js
const Card = ({ title, content }) => {
    return (
        <div style={{ border: '1px solid #ccc', padding: '16px', borderRadius: '8px' }}>
            <h2>{title}</h2>
            <p>{content}</p>
        </div>
    );
};

// App.js
const App = () => {
    return (
        <div>
            <h1>안녕하세요!</h1>
            <Card title="첫 번째 카드" content="이것은 첫 번째 카드의 내용입니다." />
            <Card title="두 번째 카드" content="이것은 두 번째 카드의 내용입니다." />
        </div>
    );
};

이 예제에서 Card 컴포넌트는 제목과 내용을 받아서 UI를 구성합니다. JSX를 사용하여 HTML과 유사한 구조로 작성했기 때문에, 코드의 가독성이 높아졌습니다.

2. 개별 요소로 쪼개져 있기 때문에 재사용이 가능하다 JSX는 컴포넌트 기반 아키텍처를 지원합니다. 각 UI 요소를 별도의 컴포넌트로 분리하면, 해당 컴포넌트를 여러 곳에서 재사용할 수 있습니다. 이는 코드 중복을 줄이고, 효율적인 개발을 가능하게 합니다. 예를 들어, 버튼, 입력 필드 등 자주 사용되는 UI 요소를 컴포넌트로 정의하면, 필요할 때마다 쉽게 호출하여 사용할 수 있습니다.

// Button.js
const Button = ({ label, onClick }) => {
    return (
        <button onClick={onClick} style={{ padding: '10px 20px', borderRadius: '5px', backgroundColor: '#007bff', color: '#fff' }}>
            {label}
        </button>
    );
};

// App.js
const App = () => {
    const handleClick = (buttonLabel) => {
        alert(`${buttonLabel} 버튼 클릭됨!`);
    };

    return (
        <div>
            <h1>안녕하세요!</h1>
            <Button label="버튼 1" onClick={() => handleClick("버튼 1")} />
            <Button label="버튼 2" onClick={() => handleClick("버튼 2")} />
            <Button label="버튼 3" onClick={() => handleClick("버튼 3")} />
        </div>
    );
};

위의 예제에서 Button 컴포넌트는 라벨과 클릭 이벤트 핸들러를 받아서 여러 번 재사용되었습니다. 각각의 버튼 클릭 시 알림이 표시됩니다. 이처럼 컴포넌트를 분리하면 코드의 재사용성을 높이고, 유지보수가 용이합니다.

3. 트랜스파일러(Babel)을 사용해야 합니다. JSX는 브라우저가 직접 이해할 수 없는 문법입니다. Babel은 이러한 JSX 코드를 JavaScript로 변환해주는 트랜스파일러입니다. Babel을 사용하면, 최신 JavaScript 문법과 JSX를 구형 브라우저에서도 호환되도록 변환할 수 있습니다. 이를 통해 개발자는 최신 기능을 활용하면서도 넓은 호환성을 유지할 수 있습니다. 또한, Babel은 코드 최적화를 통해 성능을 향상시킬 수 있습니다.

이벤트 버블링(Event Bubbling)

이벤트 버블링은 DOM에서 발생하는 이벤트 전파 방식 중 하나로, 이벤트가 발생한 요소에서 시작해 그 부모 요소로 전파되는 과정을 의미합니다. 예를 들어, 버튼 클릭 이벤트가 발생하면 그 이벤트는 버튼에서 시작하여 버튼의 부모 요소, 조부모 요소 등으로 전파됩니다. 이 과정을 통해 개발자는 특정 요소에서 발생한 이벤트를 부모 요소에서 처리할 수 있습니다.

예시 코드

document.getElementById('parent').addEventListener('click', function() {
    console.log('부모 요소 클릭됨');
});

document.getElementById('child').addEventListener('click', function() {
    console.log('자식 요소 클릭됨');
});

위 코드에서 자식 요소를 클릭하면 '자식 요소 클릭됨'이 출력되고, 그 후 '부모 요소 클릭됨'이 출력됩니다. 이러한 특징은 이벤트 위임(Event Delegation) 기법을 사용할 때 유용합니다.

이벤트 currentTarget vs target

이벤트 객체에는 target과 currentTarget이라는 두 가지 속성이 있습니다.

• target: 이벤트가 발생한 실제 요소를 가리킵니다.
• currentTarget: 이벤트 리스너가 등록된 요소를 가리킵니다.

예시 코드

document.getElementById('parent').addEventListener('click', function(event) {
    console.log('target:', event.target);
    console.log('currentTarget:', event.currentTarget);
});

위 코드에서 부모 요소를 클릭하면 target은 클릭한 요소, currentTarget은 이벤트 리스너가 등록된 부모 요소를 가리킵니다.

클로저(Closure)

클로저는 함수가 자신의 외부 스코프에 접근할 수 있는 기능입니다. 즉, 함수가 생성될 때 그 함수가 정의된 환경을 기억하여, 나중에 호출될 때 그 환경에 접근할 수 있습니다. 클로저는 데이터 은닉, 상태 유지, 그리고 부분 적용과 같은 여러 가지 유용한 패턴을 가능하게 합니다.

예시 코드

function makeCounter() {
    let count = 0; // 클로저로 유지되는 상태

    return function() {
        count += 1;
        return count;
    };
}

const counter = makeCounter();
console.log(counter()); // 1
console.log(counter()); // 2

위 코드는 makeCounter 함수가 클로저를 사용하여 count 변수를 기억하고, 이를 통해 호출할 때마다 카운터를 증가시킵니다.

커링(Currying)

커링은 여러 개의 인자를 받는 함수를 단일 인자 함수의 연쇄로 변환하는 기법입니다. 즉, 인자를 하나씩 받아서 함수를 반환하는 방식입니다. 이를 통해 함수의 재사용성을 높이고, 부분 적용을 쉽게 할 수 있습니다.

커링의 장점

1. 함수의 이름을 지정하여 새로운 목적의 함수를 생성할 수 있다.
2. 실행을 지연시킬 수 있다.

예시 코드

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

const add10 = add(10);
const add100 = add(100);

console.log(add10(5));  // 15 ,1. 함수의 이름을 지정하여 새로운 목적의 함수를 생성할 수 있다.
console.log(add100(5)); // 105 ,1. 함수의 이름을 지정하여 새로운 목적의 함수를 생성할 수 있다.

function createCalculator(initialValue) {
    let value = initialValue;

    return {
      //2. 실행을 지연시킬 수 있다. , 지연시켜서 다른 동작을 하도록 구현할 수 있음
        add: function(num) {
            value += num;
            return value;
        },
        subtract: function(num) {
            value -= num;
            return value;
        },
        getValue: function() {
            return value;
        }
    };
}

const calculator = createCalculator(100);
console.log(calculator.add(50));      // 150
console.log(calculator.subtract(30));  // 120
console.log(calculator.getValue());    // 120

위 코드에서 createCalculator 함수는 초기값을 받아 여러 가지 계산을 수행할 수 있는 객체를 반환합니다. 이 객체는 add, subtract, getValue 메서드를 통해 값을 조작하고 조회할 수 있습니다.

Redux와 클로저

Redux는 상태 관리를 위한 라이브러리로, 미들웨어를 사용하여 비동기 작업이나 부가적인 기능을 추가할 수 있습니다. 다음은 Redux에서 클로저를 사용하는 예시입니다.

예시 코드

const redux = store => action => next => {
    console.log('액션:', action);
    return next(action);
};

위 코드는 액션이 발생할 때마다 로그를 남기는 미들웨어를 정의하는 코드입니다. 클로저를 통해 store와 action에 접근할 수 있습니다.

결론

이벤트 버블링을 통해 효율적으로 이벤트를 처리할 수 있으며, 클로저는 함수의 유연성을 높여줍니다.

자바스크립트는 웹 개발에서 필수적인 프로그래밍 언어로, 함수형 프로그래밍과 객체 지향 프로그래밍을 지원합니다. 이번 포스트에서는 자바스크립트의 함수와 클래스에 대해 살펴보겠습니다.

1. 함수 (Functions)

1.1. 함수 정의

function 함수이름(매개변수1, 매개변수2) {
    // 실행할 코드
    return 반환값;
}

1.2. 함수 호출

함수이름(값1, 값2);

1.3. 익명 함수와 화살표 함수

1.3.1. 익명 함수

const 익명함수 = function(매개변수) {
    // 실행할 코드
};

1.3.2. 화살표 함수

const 화살표함수 = (매개변수) => {
    // 실행할 코드
};

1.3.3. 화살표 함수의 특징

1. 문법적 간결성: 화살표 함수는 function 키워드를 생략할 수 있어 코드가 더 간결해집니다.
2. this 바인딩: 화살표 함수는 자신만의 this를 가지지 않고, 외부 스코프의 this를 그대로 사용합니다.

1.4. 즉시 실행 함수 (IIFE)

(function() {
    // 실행할 코드
    console.log("즉시 실행 함수");
})();

(() => {
    console.log("화살표 즉시 실행 함수");
})();

1.5. 콜백 함수 (Callback Functions)

function 콜백함수() {
    console.log("콜백 함수가 실행되었습니다.");
}

function 함수에콜백전달(콜백) {
    console.log("기타 작업 수행 중...");
    콜백(); // 콜백 함수 호출
}

함수에콜백전달(콜백함수);

1.6. 호이스팅 (Hoisting)

console.log(함수이름()); // "호이스팅 예제"

function 함수이름() {
    return "호이스팅 예제";
}

반면 화살표 함수는 변수에 할당되므로 호이스팅되지 않습니다.

console.log(화살표함수()); // TypeError: 화살표함수 is not a function

const 화살표함수 = () => {
    return "호이스팅 예제";
};

2. 클래스 (Classes)

2.1. 클래스 정의

class 클래스이름 {
    constructor(매개변수) {
        this.속성 = 매개변수;
    }

    메서드이름() {
        // 실행할 코드
    }
}

2.2. 클래스 인스턴스 생성

const 인스턴스 = new 클래스이름(값);

2.3. 상속

class 부모클래스 {
    constructor() {
        this.부모속성 = "부모 속성";
    }
}

class 자식클래스 extends 부모클래스 {
    constructor() {
        super(); // 부모 클래스의 생성자 호출
        this.자식속성 = "자식 속성";
    }

    메서드이름() {
        console.log(this.부모속성, this.자식속성);
    }
}

const 자식인스턴스 = new 자식클래스();
자식인스턴스.메서드이름(); // "부모 속성 자식 속성"

3. 함수와 클래스의 차이점

• 기능: 함수는 특정 작업을 수행하기 위한 것이며, 클래스는 객체를 생성하고 그 객체의 상태와 행동을 정의하는 설계도입니다.
• 재사용성: 함수는 단순한 작업을 반복적으로 수행하기 위한 것이고, 클래스는 객체 지향 프로그래밍을 통해 더 복잡한 구조를 만들 수 있습니다.

결론

자바스크립트에서 함수와 클래스는 각각의 목적과 특성을 가지고 있으며, 적절히 활용하면 더 효율적이고 유지보수가 쉬운 코드를 작성할 수 있습니다. 즉시 실행 함수와 콜백 함수, 화살표 함수의 특징 및 호이스팅 개념을 이해하는 것은 더욱 중요합니다. 웹 개발에서 이 두 가지 개념을 잘 이해하고 활용하는 것이 중요합니다.

1. Flexbox (Flexible Box Layout)

Flexbox는 CSS의 레이아웃 모듈 중 하나로, 복잡한 레이아웃을 간단하게 만들 수 있도록 도와줍니다.

1.1. 기본 개념

• Flex Container: Flexbox를 적용할 부모 요소.
• Flex Item: Flex Container 내부의 자식 요소.

1.2. 주요 속성

• flex-direction: 주 축의 방향을 설정합니다.
• justify-content: 주 축을 따라 아이템을 정렬합니다.
• align-items: 교차 축을 따라 아이템을 정렬합니다.
• flex-wrap: 아이템의 줄 바꿈을 설정합니다.

예시: Flexbox 사용

.flex-container {
    display: flex;
    justify-content: space-around;
}

2. Grid (CSS Grid Layout)

Grid는 2차원 레이아웃을 구성할 수 있는 강력한 CSS 모듈입니다. 행과 열로 구성된 그리드 시스템을 사용하여 복잡한 레이아웃을 쉽게 만들 수 있습니다.

2.1. 기본 개념

• Grid Container: Grid를 적용할 부모 요소.
• Grid Item: Grid Container 내부의 자식 요소.

2.2. 주요 속성

• grid-template-columns: 열의 크기를 설정합니다.
• grid-template-rows: 행의 크기를 설정합니다.
• grid-gap: 그리드 아이템 간의 간격을 설정합니다.

예시: Grid 사용

.grid-container {
    display: grid;
    grid-template-columns: repeat(3, 1fr);
    gap: 10px;
}

3. 배치 우선순위 (Stacking Context & z-index)

CSS에서 요소의 배치 우선순위는 z축을 기준으로 하며, 요소가 다른 요소 위에 겹쳐 보일 때 어떤 요소가 위에 위치할지를 결정합니다.

3.1. Stacking Context

Stacking context는 요소가 쌓이는 방식에 대한 특정 규칙을 적용하는 환경입니다. 새로운 stacking context는 아래와 같은 경우에 생성됩니다:

• 요소에 position 속성이 relative, absolute, fixed, 또는 sticky가 설정되고 z-index 값이 설정된 경우
• opacity 값이 0보다 작은 경우
• transform, filter, perspective 속성이 설정된 경우

3.2. z-index

z-index 속성은 요소의 쌓임 순서를 설정합니다. 값이 높을수록 위에 쌓입니다.

3.3. 배치 우선순위 규칙

1. 자연 순서: 문서의 흐름에 따라 위치.
2. z-index 값에 따라 정렬.
3. Stacking context 내에서의 정렬.

1. CSS의 기본 구조

CSS는 선택자(selector)와 선언 블록(declaration block)으로 구성됩니다. 선택자는 스타일을 적용할 HTML 요소를 지정하며, 선언 블록은 적용할 스타일 속성과 값을 포함합니다.

선택자 {
    속성: 값;
}

예시

h1 {
    color: blue;
    font-size: 24px;
}

2. CSS 선택자 상세 정리

CSS 선택자는 HTML 요소를 선택하여 스타일을 적용하는 데 사용됩니다. 선택자의 종류와 사용법을 자세히 살펴보겠습니다.

2.1 기본 선택자

• 요소 선택자 (Type Selector): 특정 HTML 요소를 선택합니다.

  h1 {
      color: blue;
  }

• 클래스 선택자 (Class Selector): 특정 클래스를 가진 요소를 선택합니다. 클래스 이름 앞에 점(.)을 붙입니다.

  .button {
      background-color: green;
  }

• 아이디 선택자 (ID Selector): 특정 아이디를 가진 요소를 선택합니다. 아이디 이름 앞에 해시(#)를 붙입니다.

  #header {
      font-size: 24px;
  }

2.2 그룹 선택자

여러 선택자를 한 번에 지정할 수 있습니다. 쉼표로 구분합니다.

h1, h2, h3 {
    color: purple;
}

2.3 자식 선택자

특정 요소의 직계 자식을 선택합니다. > 기호를 사용합니다.

ul > li {
    list-style-type: none;
}

2.4 후손 선택자

특정 요소의 모든 후손을 선택합니다. 공백을 사용합니다.

div p {
    color: red;
}

2.5 형제 선택자

• 일반 형제 선택자 (General Sibling Selector): 같은 부모를 가진 모든 형제를 선택합니다. ~ 기호를 사용합니다.

  h1 ~ p {
      color: gray;
  }

• 인접 형제 선택자 (Adjacent Sibling Selector): 바로 다음 형제 요소를 선택합니다. + 기호를 사용합니다.

  h1 + p {
      margin-top: 0;
  }

2.6 속성 선택자

특정 속성을 가진 요소를 선택합니다.

• 특정 속성이 있는 요소:

  a[href] {
      color: blue;
  }

• 특정 속성 값이 있는 요소:

  input[type="text"] {
      border: 1px solid black;
  }

2.7 가상 클래스 선택자

특정 상태의 요소를 선택합니다.

• 호버 (Hover): 마우스가 올라갔을 때

  a:hover {
      text-decoration: underline;
  }

• 포커스 (Focus): 요소가 포커스 되었을 때

  input:focus {
      border-color: blue;
  }

• 첫 번째 자식 (First Child): 첫 번째 자식을 선택합니다.

  li:first-child {
      font-weight: bold;
  }

2.8 가상 요소 선택자

특정 요소의 일부를 선택합니다.

• 첫 번째 줄 (First Line): 요소의 첫 번째 줄을 선택합니다.

  p::first-line {
      font-weight: bold;
  }

• 첫 번째 문자 (First Letter): 요소의 첫 번째 문자를 선택합니다.

  p::first-letter {
      font-size: 2em;
  }

2.9 복합 선택자

여러 선택자를 조합하여 더 구체적인 선택을 할 수 있습니다.

• 클래스와 요소 결합:

  div.myClass {
      background-color: yellow;
  }

• 아이디와 클래스 결합:

  #header .nav {
      color: white;
  }

3. 선택자의 우선 순위

CSS 선택자는 특정 요소에 스타일을 적용할 때 우선 순위를 가집니다. 일반적으로 우선 순위는 다음과 같습니다:

1. 인라인 스타일 (HTML 요소 내에서 직접 정의)
2. ID 선택자
3. 클래스 선택자, 속성 선택자, 가상 클래스
4. 요소 선택자, 가상 요소
5. 일반 선택자

우선 순위를 이해하고 사용하면 CSS를 더 효과적으로 관리할 수 있습니다.

4. CSS 속성

CSS에는 다양한 속성이 있으며, 그 중 일부는 다음과 같습니다.

4.1 색상 관련 속성

• color: 텍스트 색상
• background-color: 배경 색상

4.2 텍스트 관련 속성

• font-size: 글꼴 크기
• font-weight: 글꼴 두께
• text-align: 텍스트 정렬

4.3 박스 모델 관련 속성

• margin: 요소의 외부 여백
• padding: 요소의 내부 여백
• border: 요소의 테두리

5. 레이아웃 방법

CSS를 사용하여 웹 페이지의 레이아웃을 구성하는 방법에는 여러 가지가 있습니다.

5.1 플렉스박스(Flexbox)

플렉스박스는 1차원 레이아웃을 쉽게 만들 수 있도록 도와줍니다.

.container {
    display: flex;
    justify-content: space-between;
}

5.2 그리드 레이아웃(Grid)

그리드 레이아웃은 2차원 레이아웃을 만들기 위한 강력한 도구입니다.

.grid-container {
    display: grid;
    grid-template-columns: repeat(3, 1fr);
}

6. 미디어 쿼리

미디어 쿼리는 다양한 화면 크기와 장치에 맞게 스타일을 조정할 수 있도록 해줍니다.

@media (max-width: 600px) {
    body {
        background-color: lightblue;
    }
}

7. 마무리

CSS는 웹 페이지의 디자인과 레이아웃을 정의하는 데 필수적인 도구입니다. 이 포스트에서는 CSS의 기본 개념과 주요 기능을 살펴보았습니다. 더 깊이 있는 학습을 위해 공식 문서나 다양한 튜토리얼을 참고하시기 바랍니다.

참고 자료

• MDN Web Docs: CSS
• W3Schools: CSS Tutorial ```

✨custom label 적용하기

✅ 완료 및 결과 화면

3단계로 이루어진다.

1. labels.json파일을 생성한다.
2. personal access token을 생성한다.
3. 명령어를 입력하여 labels.json 적용한다.

1. labels.json파일을 생성한다.

• name, color, description을 포함한 형태로 작성한다.
• labels.json*

  [
   {
     "name": "💣 bug",
     "color": "006b75",
     "description": "Bug issue"
   },
   {
     "name": "🔧 chore",
     "color": "FDE9BC",
     "description": "Settings and other issues"
   },
   {
     "name": "🚀 feat",
     "color": "C51181",
     "description": "Function implementation issues"
   },
   {
     "name": "🍄 infra",
     "color": "E5B264",
     "description": "Infrastructure-related issues"
   },
   {
     "name": "🔨 refactor",
     "color": "9AE970",
     "description": "Refactoring-related issues"
   },
   {
     "name": "🌴 style",
     "color": "55AF2B",
     "description": "Style and css related issues"
   },
   {
     "name": "🔍 test",
     "color": "C5DEF5",
     "description": "Test-related issues"
   }
  ]
  

#### 2. personal access token을 생성한다.
- https://github.com/settings/apps 로 이동한다.
- 스크린샷으로 보여지는 방법으로 token을 발급받는다.
![](https://velog.velcdn.com/images/jungkyu_lol/post/437512a4-1808-4878-8c8e-56ae5fecf17f/image.png)
![](https://velog.velcdn.com/images/jungkyu_lol/post/b31e54a4-df4a-4a7c-a71f-b64430723ea1/image.png)
**완료가 되면 아래와 같이 출력된다.**
*작성자는 해당 token이 페이지를 벗어나면 더 이상 보여지지 않는 것으로 알고 있기 때문에 따로 메모해두길 바란다.*
![](https://velog.velcdn.com/images/jungkyu_lol/post/01113825-e13e-467d-9813-14d17cb2488e/image.png)


#### 3. 명령어를 입력하여 labels.json 적용한다.
- 아래 명령어 형식을 맞추어 입력한다.

npx github-label-sync --access-token {본인의 token} --labels ./labels.json {라벨을 업데이트하고 싶은 본인의 레포지터리}

---

## ✨custom issue template 적용하기

 ### ✅ 완료 및 결과 화면
![](https://velog.velcdn.com/images/jungkyu_lol/post/136efbce-24fb-4c52-a0f7-7b0ba22ff6f3/image.png)
>> **github에서 제공하는 GUI를 사용하는 방법**
>1. github에서 제공하는 templates 생성 기능을 이용한다.
>2. templates을 원하는 형식으로 수정한다.
>3. commit하여 업로드 한다.

--- 
### ✅ 완료 및 결과 화면

![](https://velog.velcdn.com/images/jungkyu_lol/post/78fa0b7d-76ed-4297-93c2-0f03709007a3/image.png)


>>  **직접 issue-form을 업로드하는 방법**
>1. issue_form.yml파일을 생성한다.
> 2. form을 원하는 형식으로 수정한다.
> 3. commit하여 업로드 한다.

### github에서 제공하는 GUI를 사용하는 방법
#### 1. github에서 제공하는 templates 생성 기능을 이용한다.
- 스크린샷으로 보여지는 방법으로 templates를 생성한다.
![](https://velog.velcdn.com/images/jungkyu_lol/post/3949476d-7cdd-4ef5-9465-ef07ce85e1ab/image.png)
#### 2. templates을 원하는 형식으로 수정한다.
- 원하는 대로 수정하면 된다.
*작성자는 **issue template이 팀원에게 issue 내용을 공유하는 것과 반복적인 작업을 줄이기 위한 것**이라고 생각한다. 그렇기 때문에 팀원에게 간결하게 정보를 잘 전달하는 형식을 가지면서 작성하기 번거롭지 않은 형식을 채택하길 권장한다.
- 화살표를 보면 위에서 적용한 lebel도 적용해 줄 수 있다.

**작성자가 추천하는 template content 형식**

📄 Describe

Please explain the issue in detail.

☑️ Tasks

• Write your to-do list here.

📋 Ref

Additional information or reference documents.

![](https://velog.velcdn.com/images/jungkyu_lol/post/42ff31f3-5aae-4e34-894d-7ff554706bc1/image.png)

#### 3. commit하여 업로드 한다.

![](https://velog.velcdn.com/images/jungkyu_lol/post/dfd69cb8-3807-4c35-8c2b-eb60d4e1f99e/image.png)

### 직접 issue-form을 업로드하는 방법
#### 1. issue_form.yml파일을 생성한다.
- .github/ISSUE_TEMPLATE 폴더 안에 생성한다.
#### 2. form을 원하는 형식으로 수정한다.
- 원하는 대로 수정하면 된다.
*아래 코드는 위에 작성자가 추천하는 template content 형식과 동일하게 만든 형태라고 보면 된다.
**issue_form.yml**

name: '✅ NEW Default' description: 'Feature 뉴 템플릿' labels: "\U0001F680 feat" title: '이슈 이름을 작성해주세요' assignees: [author] body:

• type: input id: description attributes: label: '이슈 내용(Description)' description: '이슈에 대해서 간략히 설명해주세요' validations: required: true

• type: textarea id: tasks attributes: label: '구현기능(Tasks)' description: '해당 이슈에 대해 필요한 작업목록을 작성해주세요' value: |

  - [ ] Task1

  validations: required: true

• type: textarea id: references attributes: label: '참조(References)' description: '해당 이슈과 관련된 레퍼런스를 참조해주세요' value: |

  - 참고자료

  validations: required: false

```

3. commit하여 업로드 한다.

1. Git의 기본 개념

• Git 저장소 (Repository): 프로젝트의 모든 파일과 변경 이력을 저장하는 공간. 로컬 저장소와 원격 저장소로 나뉩니다.
• 커밋 (Commit): 파일의 변경 사항을 저장하는 단위. 각 커밋은 고유한 해시값을 통해 이력을 추적합니다.
• 브랜치 (Branch): 독립적인 작업 공간으로, 여러 개발자가 동시에 작업할 수 있게 합니다.
• 머지 (Merge) vs 리베이스 (Rebase):
  • 머지: 두 브랜치를 합치는 과정.
  • 리베이스: 한 브랜치의 변경 사항을 다른 브랜치에 적용하여 커밋 이력을 깔끔하게 유지합니다. 출처: https://static-assets.codecademy.com/Courses/learn-git-github/git-rebase/git-merge-vs-git-rebase.svg

2. Git 사용 준비

1. Git 설치: 운영체제에 맞는 설치 파일을 다운로드하여 설치합니다.
2. GitHub 계정 생성 및 연동: GitHub에 가입 후 SSH 키를 생성하여 로컬 Git과 연동합니다.

3. 브랜치 생성 및 관리

브랜치 생성은 협업의 핵심입니다. 새로운 기능 개발 시 새로운 브랜치를 생성하세요.

git checkout -b new-feature

4. 코드 변경 및 커밋

변경 사항을 커밋할 때는 의미 있는 메시지를 작성하는 것이 중요합니다.

git add .
git commit -m "Add new feature"

5. 원격 저장소에 푸시

로컬 작업 내용을 원격 저장소에 푸시합니다.

git push origin new-feature

6. Pull Request 만들기

Pull Request는 팀원들과 코드 변경 사항을 공유하고 리뷰를 요청하는 중요한 단계입니다.

1. 해당 브랜치로 이동.
2. "Pull Request" 버튼 클릭.
3. 설명 작성 후 리뷰어 지정.

7. 머지하기

Pull Request가 승인되면 변경 사항을 메인 브랜치에 통합합니다. 머지 후 코드가 정상적으로 작동하는지 확인하세요.

Fast-forward

Fast-forward는 Git에서 브랜치를 병합할 때 발생하는 특별한 상황입니다. 두 브랜치가 서로 다른 커밋을 가지고 있을 때, 한 브랜치를 다른 브랜치에 병합할 때 Fast-forward가 가능하면, Git은 병합 커밋을 생성하지 않고 단순히 브랜치 포인터를 이동시킵니다. 출처: https://wikidocs.net/153871

Fast-forward의 특징

• 간단한 병합: 별도의 병합 커밋 없이 브랜치 포인터를 이동합니다.
• 이력 유지: 커밋 히스토리가 직선으로 이어져 변경 사항 추적이 용이합니다.
• 조건: 병합하려는 브랜치가 현재 브랜치의 직계 후손이어야 Fast-forward가 가능합니다.

  Fast-forward 방지

  Fast-forward를 방지하고 별도의 병합 커밋을 생성하고 싶을 경우 --no-ff 플래그를 사용합니다.

  git merge --no-ff feature

8. 리베이스 사용하기

리베이스를 통해 커밋 이력을 깔끔하게 유지할 수 있습니다.

git rebase main

9. 충돌 해결

머지나 리베이스 과정에서 충돌이 발생할 수 있습니다. 충돌 해결 방법은 다음과 같습니다.

1. 충돌 파일 수정.
2. 변경 사항 스테이징.
3. 커밋하여 충돌 해결.

Git과 GitHub을 활용하여 효율적인 협업을 진행해 보세요! 💻

10. 마무리

Git/GitHub을 통한 협업의 장점

1. 버전 관리: Git은 코드의 모든 변경 이력을 기록하여, 언제든지 이전 상태로 돌아갈 수 있습니다. 이는 실수로 인한 손실을 방지합니다.

2. 협업 용이성: 여러 개발자가 동시에 작업할 수 있어, 팀원 간의 효율적인 협업이 가능합니다. 브랜치 기능을 통해 각자 독립적으로 작업할 수 있습니다.

3. 코드 리뷰: GitHub의 Pull Request 기능을 통해 팀원 간의 코드 리뷰가 가능하며, 이는 코드 품질을 높이는 데 기여합니다.

4. 문서화: 프로젝트의 변경 이력과 논의 내용을 기록할 수 있어, 프로젝트의 진행 상황을 쉽게 파악할 수 있습니다.

좋은 커밋 메시지 작성법

좋은 커밋 메시지는 협업의 효율성을 높이고, 코드 이력을 이해하는 데 도움을 줍니다. 다음은 좋은 커밋 메시지를 작성하기 위한 몇 가지 팁입니다:

1. 명확하고 간결하게: 커밋 메시지는 변경 사항을 간단명료하게 설명해야 합니다. 예를 들어, "Fix bug in user authentication"처럼 구체적으로 작성합니다.

2. 현재형 사용: 커밋 메시지는 현재형으로 작성합니다. "Add feature" 대신 "Added feature"라고 하지 않습니다.

3. 커밋 목적 강조: 무엇을 변경했는지뿐만 아니라 왜 변경했는지도 설명합니다. 예를 들어, "Improve performance of data processing"처럼 작성합니다.

4. 문장 구조: 메시지는 제목과 본문으로 나누어 작성할 수 있습니다. 제목은 50자 이내로, 본문은 72자 이내로 작성하는 것이 좋습니다.

추가 리소스 링크

다음은 Git과 GitHub을 더 깊이 이해하고 활용하기 위한 유용한 리소스입니다:

• Git 공식 문서
• Git 실습