안나의 전두엽 어딘가

[React] React 19에서의 폼 처리 방식: Form Action, useActionState, useFormStatus, useOptimistic

제가안난데여♪(´ε｀*) — Fri, 2 May 2025 16:43:31 +0900

이 글은 Udemy의 【한글자막】 React 완벽 가이드 2025 with React Router & Redux 를 수강하고 정리한 내용입니다.

Form Action이란?

React 19에서는 <form action={someFunction}>처럼 action 속성에 함수를 전달할 수 있습니다. 이때 React는 다음과 같은 동작을 자동으로 수행합니다:

preventDefault() 자동 호출 → 직접 막을 필요 없음
FormData 객체를 해당 함수에 인자로 전달
<input>, <select> 등에 설정된 name 속성을 기반으로 FormData 구성
제출이 완료되면 자동으로 폼 초기화

<form action={myAction}>
  <input name="email" />
  <button>Submit</button>
</form>

주의: 모든 입력 요소에는 반드시 name 속성을 지정해야 합니다. 그래야 FormData에 포함됩니다.

useActionState 훅

useActionState는 폼의 상태와 액션 함수를 연결하여, 액션 함수의 반환값을 쉽게 UI에서 사용할 수 있도록 도와주는 React 19의 새로운 훅입니다.

const [formState, formAction, isPending] = useActionState(actionFn, initialState);

actionFn: 폼 제출 시 실행될 함수. (prevState, formData)를 인자로 받습니다.
initialState: 초기 상태
반환 배열 :
- formState: 현재 상태
- formAction: form 요소의 action에 전달할 수 있는 React가 감지 가능한 래핑된 함수
  - 리액트가 래핑된 함수를 만드는 이유
    더보기
    React는 다음과 같은 일을 자동으로 해줘야 해요:
    
    FormData를 자동으로 꺼내서 넘겨주고,
    
    상태 변화를 감지하고 (isPending 같은),
    
    폼 제출 중 상태를 관리하고,
    
    렌더링도 적절히 트리거해야 하죠.
    
    ⚙️ 그래서 React는 우리가 전달한 함수를 직접 쓰지 않고, 내부적으로 새로운 함수를 만듭니다.
    
    이 새 함수는 다음과 같은 일을 합니다:
    
    function wrappedAction(formData) { // isPending = true 로 설정 // 우리 액션(myAction)을 실행 // 결과를 상태로 저장 // isPending = false 로 변경 }
    
    이렇게 감싼 함수를 React가 추적 가능한 형태로 만들어서 formAction으로 돌려주는 겁니다.
- isPending: 비동기 요청 중 여부
  - 폼이 현재 제출 중일때 true, 그렇지 않을때는 false 값을 가진다.

✅ 예시: 유효성 검사 및 에러 처리

function signupAction(prevState, formData) {
  const email = formData.get("email");
  const password = formData.get("password");

  const errors = [];

  if (!email.includes("@")) errors.push("잘못된 이메일 형식입니다.");
  if (!password || password.length < 6) errors.push("비밀번호는 6자 이상이어야 합니다.");

  if (errors.length > 0) {
    return { errors, enteredValues: { email, password } };
  }

  return { errors: null };
}

const [formState, formAction] = useActionState(signupAction, { errors: null });

<form action={formAction}>
  <input name="email" defaultValue={formState.enteredValues?.email} />
  <input name="password" type="password" defaultValue={formState.enteredValues?.password} />
  {formState.errors && <ul>{formState.errors.map(e => <li key={e}>{e}</li>)}</ul>}
  <button>Sign Up</button>
</form>

useFormStatus: 제출 중 상태 추적

useFormStatus는 현재 <form>의 제출 상태와 관련된 다양한 정보를 제공하는 React 19의 훅입니다. 특히 폼의 자식 컴포넌트에서 제출 상태에 따라 UI를 동적으로 제어할 수 있도록 해줍니다.

제출 중일 때 버튼 비활성화
로딩 스피너 표시
상태에 따라 메시지 표시 등

import { useFormStatus } from "react";

function SubmitButton() {
  const { pending } = useFormStatus(); // 현재 폼의 제출 상태

  return (
    <button disabled={pending}>
      {pending ? "Submitting..." : "Submit"}
    </button>
  );
}

주의

useFormStatus는 <form> 태그 안에 위치한 컴포넌트에서만 사용할 수 있습니다. <form> 외부에서 호출하면 동작하지 않습니다.

해당 폼 요소의 직접적인 하위 자식 컴포넌트여야 합니다. 즉, 같은 컴포넌트 트리 안에 있어야 합니다.

✅ 반환되는 객체 속성

useFormStatus()는 단순히 pending만 제공하는 것이 아니라 여러 상태 정보를 담고 있는 객체를 반환합니다:

속성명	설명
pending	폼이 제출 중일 때 true, 그렇지 않으면 false
data	폼 제출 시 함께 전송되는 FormData 객체
method	폼 요청 방식 (예: "post" 등)
action	폼에 지정된 액션 함수 또는 URL
enctype	폼 인코딩 타입 (기본은 application/x-www-form-urlencoded)

✅ 일반적으로 가장 많이 사용하는 속성은 pending이며, 제출 상태에 따라 버튼을 비활성화하거나 메시지를 띄우는 데 활용됩니다.

useOptimistic: 낙관적 UI 업데이트

useOptimistic은 사용자의 액션이 서버에 반영되기 전, 예상 결과를 먼저 UI에 반영하여 즉각적인 피드백을 주는 방식입니다. 예를 들어 유저가 투표 버튼을 클릭하면, 서버에 반영되기 전에 일단 UI 상의 투표 수부터 바꿔 보여줄 수 있습니다.

✅ 사용법

const [optimisticState, updateOptimistically] = useOptimistic(
  initialValue,          
  (previousValue, action) => newValue 
);

1️⃣ 첫 번째 인자: 초기 상태 값

예: 현재 투표 수 (votes)

2️⃣ 두 번째 인자: 업데이트 함수

React가 useOptimistic 내부적으로 폼 제출 중에 호출합니다.
첫 번째 매개변수는 React가 전달하는 이전 상태(previousValue)입니다.
두 번째 매개변수는 개발자가 updateOptimistically() 호출 시 전달한 사용자 정의 값 입니다.

반환값

optimisticState
- 낙관적으로 관리되는 상태입니다.
- 폼이 제출되는 동안에만 이 값이 UI에 표시됩니다.
- 폼 제출이 끝나면 이 상태는 사라지고, 앱의 원래 상태로 복귀합니다.
updateOptimistically(action)
- 낙관적 UI 상태를 적용하고 싶을 때 사용하는 함수입니다.
- 폼 액션 내부에서 호출됩니다.
- 인자로 넘긴 값은 useOptimistic()의 두 번째 인자인 함수의 두 번째 매개변수로 전달됩니다.

✅ 실제 예시: 투표 수를 즉시 반영하는 컴포넌트

import { OpinionsContext } from "../store/opinions-context.jsx";
import { use, useActionState, useOptimistic } from "react";

export function Opinion({ opinion: { id, title, body, userName, votes } }) {
  const { upvoteOpinion, downvoteOpinion } = use(OpinionsContext);

  // 낙관적 상태 설정: 'up'이면 +1, 'down'이면 -1
  const [optimisticVotes, setVotesOptimistically] = useOptimistic(
    votes,
    (prevVotes, mode) => (mode === "up" ? prevVotes + 1 : prevVotes - 1),
  );

  // 서버 요청 전 낙관적 업데이트 후 실제 서버에 반영
  async function upVoteAction() {
    setVotesOptimistically("up");
    await upvoteOpinion(id);
  }

  async function downVoteAction() {
    setVotesOptimistically("down");
    await downvoteOpinion(id);
  }

  // 각각의 폼 액션 상태 관리
  const [upVoteFormState, upVoteFormAction, upVotePending] =
    useActionState(upVoteAction);
  const [downVoteFormState, downVoteFormAction, downVotePending] =
    useActionState(downVoteAction);

  return (
    <article>
      <header>
        <h3>{title}</h3>
        <p>Shared by {userName}</p>
      </header>
      <p>{body}</p>
      <form className="votes">
        <buttonformAction={upVoteFormAction}
          disabled={upVotePending || downVotePending}
        >
           
        </button>

        <span>{optimisticVotes}</span>

        <buttonformAction={downVoteFormAction}
          disabled={upVotePending || downVotePending}
        >
           
        </button>
      </form>
    </article>
  );
}

useOptimistic(초기값, 업데이트 함수)를 사용하여 상태를 낙관적으로 관리합니다.
실제 비동기 작업이 완료되기 전에 setVotesOptimistically("up") 등을 호출해 UI를 즉시 반영합니다.
실제 서버 작업은 await upvoteOpinion(id)에서 진행됩니다.
폼 제출 중에는 optimisticVotes 값이 화면에 표시되고, 제출이 완료되면 이 값은 사라지고 실제 상태로 대체 됩니다.
만일 폼 제출 과정에서 오류가 발생했다면 이전 상태로 롤백되어집니다.

버튼마다 다른 액션 처리하기

React의 폼은 각 버튼에 formAction 속성을 지정하면, 같은 <form> 안에 있어도 서로 다른 함수를 실행할 수 있습니다.

<form>
  <button formAction={saveDraft}>임시 저장</button>
  <button formAction={submitFinal}>최종 제출</button>
</form>

Form Action vs onSubmit

비교 항목 Form Action onSubmit

선언 방식	<form action={function}>	<form onSubmit={handler}>
기본 동작 방지	자동	수동 (event.preventDefault())
데이터 수집 방식	자동으로 FormData 제공	event.target에서 수동 수집
비동기 처리 지원	✔ (Promise 지원)	✔ (직접 핸들링)
상태 관리	useActionState로 간편하게 처리	수동으로 useState 등 사용

도움이 되셨다면 ❤️ 좋아요와 댓글로 피드백 주세요!

궁금한 점이 있다면 언제든지 질문 환영입니다

지금까지 읽어주셔서 감사합니다!

[React] React에서 폼(form) 다루기 :: 추출, 유효성검증, 초기화, 제출

제가안난데여♪(´ε｀*) — Tue, 29 Apr 2025 14:49:30 +0900

이 글은 Udemy의 【한글자막】 React 완벽 가이드 2025 with React Router & Redux 를 수강하고 정리한 내용입니다.

리액트나 일반 HTML에서 form을 다룰 때, 생각보다 다양한 문제를 마주치게 됩니다.

단순히 "입력값 받아서 제출"하는 걸 넘어, 다음과 같은 고민들이 따라오죠:

어떻게 입력값을 깔끔하게 추출할까?
유효성 검사는 언제, 어떻게 해야 깔끔할까?
입력 후 초기화는 어떻게 해야 할까?
리액트에서는 form 제출을 어떻게 다뤄야 할까?

이번 글에서는 위의 문제들을 하나씩 정리하고, 실제로 어떤 방식으로 해결하는 게 좋은지 이야기해보겠습니다.

1. 입력 데이터 추출 방법

폼에서 입력된 값을 가져오는 방식은 상황에 따라 다르게 선택할 수 있습니다.

✅ 방법 1: useState로 입력 상태 관리 (양방향 바인딩)

const [username, setUsername] = useState("");

<input value={username} onChange={(e) => setUsername(e.target.value)} />

리액트에서 가장 많이 사용하는 방식
실시간으로 상태를 추적하고 활용 가능
단점: 코드가 조금 길어질 수 있음

✅ 방법 2: useRef로 DOM 요소 접근

const inputRef = useRef();

function handleSubmit(event) {
  event.preventDefault();

  const input = inputRef.current.value;
}

...

<input ref={inputRef} />

값이 필요할 때만 추출하면 되는 경우 사용
렌더링을 발생시키지 않음 (퍼포먼스 유리)
단점: 리액트의 상태 흐름에서 벗어날 수 있음

✅ 방법 3: FormData API로 한 번에 추출

function handleSubmit(e) {
  e.preventDefault();
  const formData = new FormData(e.target);
  const data = Object.fromEntries(formData.entries());
}

form 전체 데이터를 한 번에 가져올 수 있음
input에 name 속성이 필수
체크박스처럼 여러 값을 가지는 경우는 formData.getAll() 사용 필요
- 특정 name 에 해당하는 모든 값을 배열로 가져옴

function handleSubmit(e) {
  e.preventDefault();
  const formData = new FormData(e.target);
  const acquisitionChannel = formData.getAll("acquisition"); // 체크박스 
  const data = Object.fromEntries(formData.entries());
  data.acquisition = acquisitionChannel;
}

2. 유효성 검증 (Validation)

폼에서 유효성 검사는 UX에 직접적인 영향을 주는 요소입니다.

너무 이르거나 너무 늦은 타이밍에 표시되면 사용자가 불편을 느낄 수 있어요.

✅ 방법 1: 실시간 검증 (onChange)

<input value={email} onChange={(e) => {
  setEmail(e.target.value);
  setError(!validateEmail(e.target.value));
}} />

입력할 때마다 검증
❌ 문제: 사용자가 입력을 마치기도 전에 에러가 떠버리는 UX

✅ 방법 2: 포커스 해제 시 검증 (onBlur)

<input onBlur={() => setTouched(true)} />

사용자가 입력 후 포커스를 벗어나면 검증
✅ UX 관점에서 가장 적절한 타이밍

✅ 방법 3: useRef와 입력 완료 시 검증

상태 관리 없이 입력 완료 타이밍에 값을 꺼내서 검증
단순한 검증 로직에 유용

✅ 방법 4: HTML의 내장 속성 사용

<input required minLength={5} />

브라우저 기본 유효성 검사가 작동
간단한 유효성에는 매우 유용

3. 폼 초기화 처리

입력 완료 후 상태를 초기 상태로 되돌리는 방법입니다.

✅ 방법 1: useState로 초기값 설정

setUsername(""); // 다시 빈 문자열로

가장 일반적인 리액트 방식

✅ 방법 2: useRef 초기화

inputRef.current.value = "";

DOM을 직접 조작하는 방식이라 권장되진 않지만, 간단한 경우 사용 가능

✅ 방법 3: event.target.reset() 사용

function handleSubmit(e) {
  e.preventDefault();
  e.target.reset(); // form 전체 초기화
}

한 줄로 폼 전체를 초기화 가능
상태를 쓰지 않는 경우 특히 유용

4. 양식 제출 제어 (submit 제어)

✅ HTML의 기본 동작

<form> 태그는 원래 서버로 데이터 제출 + 전체 페이지 새로고침을 유발합니다.

이건 전통적인 SSR(Server-Side Rendering) 방식에 맞춘 설계죠.

✅ 리액트에선 왜 문제가 될까?

리액트는 CSR(Client-Side Rendering) 기반입니다.

즉, 페이지 전체를 새로고침하면:

리액트가 관리하던 상태가 날아가고
앱 흐름이 깨지며
사용자 경험이 떨어지게 됩니다

그래서 반드시 기본 submit 동작을 막아야 합니다.

✅ 해결 방법

1️⃣ type="button" 사용

<form>
  <button type="button">제출</button>
</form>

<button>의 기본값은 type="submit"이므로 명시적으로 설정해야 함

2️⃣ onSubmit + preventDefault()

<form onSubmit={(e) => {
  e.preventDefault();
  // 사용자 입력 처리 로직
}}>
  <button type="submit">제출</button>
</form>

가장 일반적인 방식

3️⃣ formAction (React 19 이상)

<form>
  <button formAction={handleAction}>제출</button>
</form>

서버 액션과 연동되는 새로운 방식
React 19에서만 사용 가능

도움이 되셨다면 ❤️ 좋아요와 댓글로 피드백 주세요!

궁금한 점이 있다면 언제든지 질문 환영입니다

지금까지 읽어주셔서 감사합니다!

[React] 왜 React에서는 form submit을 기본으로 두면 안 될까?

제가안난데여♪(´ε｀*) — Tue, 29 Apr 2025 11:03:40 +0900

이 글은 Udemy의 【한글자막】 React 완벽 가이드 2025 with React Router & Redux 를 수강하고 정리한 내용입니다.

HTML에서 <form> 태그는 원래 서버로 데이터를 보내기 위한 용도다

HTML에서 <form> 태그는 **서버로 데이터를 제출(submit)**하고, 새로운 페이지를 받아오기 위한 구조로 설계됐다. 폼 안에서 버튼을 누르면 브라우저는 기본적으로 다음과 같은 흐름으로 동작한다:

브라우저 기본 동작

버튼 클릭 → 폼 제출 (submit 이벤트 발생)
입력값을 포함해서 서버로 HTTP 요청 전송
서버가 요청을 처리하고 새로운 HTML 페이지를 응답
전체 페이지가 새로고침되면서 새 화면이 열린다

왜 이렇게 설계됐을까? (→ SSR 기반 구조)

이 흐름은 웹 초창기부터 사용되던 전통적인 방식이다.

즉, SSR(Server-Side Rendering) 구조에 최적화되어 있었다.

✅ SSR(Server-Side Rendering) 방식이란?

모든 HTML 페이지를 서버에서 렌더링해서 생성하고
사용자의 요청마다 서버가 새 페이지를 보내주는 구조
폼 제출도 서버로 요청 → 서버가 새 HTML을 만들어서 응답 → 전체 페이지 교체

그래서 폼 제출 시 전체 페이지 새로고침은 자연스러운 동작이었다.

⚠️ 그런데, 리액트에서는 문제가 된다 (→ CSR과 충돌)

리액트 같은 프론트엔드 프레임워크는 대부분 CSR(Client-Side Rendering) 방식을 사용한다.

✅ CSR(Client-Side Rendering) 방식이란?

처음 로딩 시 HTML 한 번만 받아오고, 이후부터는
브라우저 안에서 자바스크립트가 동적으로 화면을 그린다
페이지 전환이나 상태 변경이 새로고침 없이 빠르게 이루어진다

그런데 <form> 제출 시 브라우저 기본 동작을 막지 않으면?

전체 페이지가 새로고침되고
리액트가 관리하던 모든 상태(state)가 초기화된다
예상하지 않은 서버 요청이 발생해서 의도한 흐름이 깨질 수 있다

CSR의 장점이 완전히 사라져버린다.

️ React에서 폼 제출 시 주의할 점

CSR 기반 앱에서는 폼 제출의 기본 동작을 제어해야 한다.

주로 아래 3가지 방법을 사용한다.

1️⃣ 버튼에 type="button"을 명시하기

HTML에서는 <button>의 기본 type이 submit이다.

따라서 폼 안의 버튼은 기본적으로 폼 제출을 유발한다.

만약 단순한 클릭 이벤트만 처리하고 싶다면,

type="button"을 명시해서 제출을 막아야 한다.

<form>
  <button type="button">로그인</button> {/* 이 버튼은 form 제출 안 함 */}
</form>

참고: type="button"은 "폼 제출이 아닌 버튼"임을 명시하는 것이지, 이미 발생한 submit 이벤트를 막는 것은 아니다.

2️⃣ onSubmit 핸들러에서 preventDefault() 호출하기

폼 제출을 직접 다룰 경우에는,

onSubmit 이벤트 핸들러를 등록하고 preventDefault()를 호출해야 한다.

function handleSubmit(e) {
  e.preventDefault(); // ✅ HTTP 요청과 새로고침 방지
  // 여기에 로그인 처리 로직 작성
}

<form onSubmit={handleSubmit}>
  <button type="submit">로그인</button>
</form>

이 방법은, 폼 자체를 유지하면서 제출 흐름만 제어하고 싶을 때 유용하다.

(예: 로그인, 회원가입 API 요청 보내기 등)

3️⃣ (React 19 이상) formAction 속성 사용하기

React 19부터는 폼 제출을 더 선언적으로 처리할 수 있는

formAction 속성이 새롭게 도입되었다.

<form>
  <button formAction={handleLogin}>로그인</button>
</form>

formAction은 버튼 클릭 시 지정된 함수가 호출된다.
특히 **서버 액션(Server Actions)**과 함께 사용할 때 강력하다.
클라이언트 액션에서도 사용할 수 있지만,
주로 React Server Components 환경에서 많이 활용된다.

참고: formAction은 React 19 이상에서만 사용할 수 있다.

아직은 전통적인 onSubmit + preventDefault() 패턴이 더 보편적이다.

참고: CSR vs SSR 한눈에 정리

구분 CSR (Client-Side Rendering) SSR (Server-Side Rendering)

렌더링 위치	브라우저(클라이언트)	서버
최초 로딩 속도	느릴 수 있음 (JS 다운로드 필요)	빠름 (HTML 바로 렌더링)
화면 전환 속도	빠름 (새로고침 없이 변경)	느림 (매번 서버 요청)
사용 예시	React, Vue, Next.js (CSR모드)	전통적인 서버 웹사이트, Next.js(SSR모드)

도움이 되셨다면 ❤️ 좋아요와 댓글로 피드백 주세요!

궁금한 점이 있다면 언제든지 질문 환영입니다

지금까지 읽어주셔서 감사합니다!

[React] 리액트 컴포넌트 스타일링

제가안난데여♪(´ε｀*) — Wed, 23 Apr 2025 13:41:54 +0900

이 글은 Udemy의 【한글자막】 React 완벽 가이드 2025 with React Router & Redux 를 수강하고 정리한 내용입니다.

바닐라 CSS 스타일 컴포넌트에 스코핑 방법

리액트에서 바닐라 CSS를 사용하는 경우, CSS가 리액트 컴포넌트에 스코프가 자동으로 적용되지 않습니다. 이는 CSS가 전역적으로 적용되기 때문에, 컴포넌트가 여러 개 있을 때 스타일이 서로 충돌할 수 있습니다.

즉, 같은 페이지에 존재하는 A 컴포넌트와 B 컴포넌트가 존재한다고 할때, A 컴포넌트의 스타일에 필요한 css가 B컴포넌트의 스타일에 영향을 미칠 수 있습니다. 이를 해결하기 위해서 리액트 컴포넌트에 CSS를 스코프(scope)하기 위해 몇가지 방법을 소개해드리겠습니다.

1️⃣ style Prop 사용하여 Inline(인라인)으로 css 적용하기

style Prop을 사용해서 CSS를 자바스크립트 객체로 작성하여 JSX에서 스타일을 적용할 수 있습니다. 이 방법을 통해 간단한 스타일링이나, 동적인 스타일 변경을 할 때 사용 가능 합니다.

style Prop 기본 사용법

CSS 속성 이름은 camelCase로 작성
값은 문자열 또는 숫자로 작성

function App() {

  return (
    <div>
      <button 
        style={{
          backgroundColor: 'red',  // 고정된 색상
          color: 'white',
          padding: '10px 20px',
          border: 'none',
          cursor: 'pointer'
        }} 
      >
        Click me!
      </button>
    </div>
  );
}

export default App;

동적 스타일링 가능

import React, { useState } from 'react';

function App() {
  // useState 훅을 사용하여 isClicked 상태를 정의합니다. 초기 값은 false입니다.
  const [isClicked, setIsClicked] = useState(false);

  // 버튼 클릭 시 호출되는 함수입니다. 상태를 반전시켜 isClicked 값을 변경합니다.
  const handleClick = () => {
    setIsClicked(prev => !prev); // 이전 상태의 반대로 값을 변경합니다.
  };

  // 버튼 스타일을 동적으로 생성합니다. isClicked 상태에 따라 배경색이 바뀝니다.
  const buttonStyle = {
    backgroundColor: isClicked ? 'green' : 'red', // 상태에 따라 배경색을 green 또는 red로 설정
    color: 'white', 
    padding: '10px 20px',
    border: 'none', 
    cursor: 'pointer'
  };

  return (
    <div>
      {/* label 태그는 버튼을 설명하는 텍스트를 포함합니다. 
           isClicked 상태에 따라 'clicked' 클래스를 동적으로 추가 */}
      <label className={`label ${isClicked ? 'clicked' : ''}`}>Button</label>

      {/* 버튼은 style prop을 사용하여 동적으로 스타일을 적용하고, 
           클릭 시 handleClick 함수가 호출되어 isClicked 상태가 변경됩니다. */}
      <button style={buttonStyle} onClick={handleClick}>
        {/* 버튼 텍스트는 isClicked 상태에 따라 'Clicked' 또는 'Click me!'로 변경 */}
        {isClicked ? 'Clicked' : 'Click me!'}
      </button>
    </div>
  );
}

export default App;

style Prop 사용 시 장점

컴포넌트 내에서 간편한 스타일링
동적 스타일 적용
외부 라이브러리 의존성 없음

style Prop 사용 시 단점

스타일 재사용 어려움
성능 이슈
- 매번 새로운 스타일 객체가 생성되어 리렌더링 성능에 영향을 미칠 수 있다.
복잡한 스타일링에 한계
스타일 객채와 jsx의 상태와 강한 의존성

2️⃣ CSS Module 사용하기

CSS Modules은 CSS 클래스 이름을 자동으로 고유하게 만들어주는 방법입니다. 이를 통해 각 컴포넌트에서 사용하는 CSS가 전역에 영향을 미치지 않게 할 수 있습니다.

create-react-app을 사용하면, CSS Modules는 기본적으로 지원됩니다. .module.css 확장자를 사용하면 됩니다.

Button.module.css

/* Button.module.css */
.button {
  background-color: green;
  color: white;
  padding: 10px;
}

Button.js

// Button.js
import React from 'react';
import styles from './Button.module.css';

function Button() {
  return <button className={styles.button}>Click me!</button>;
}

export default Button;

위의 코드에서 Button.module.css는 CSS Module을 사용하여 자동으로 고유한 클래스 이름을 생성합니다. styles.button을 사용하여 클래스 이름을 적용하면, 해당 CSS가 다른 컴포넌트의 스타일에 영향을 미치지 않습니다.

3️⃣ Styled Components

CSS-in-JS 방식을 사용하는 라이브러리입니다.

말 그대로 CSS 코드를 자바스크립트 안에 작성할 수 있게 해줍니다. 그리고 중요한 건, 작성한 스타일이 해당 컴포넌트에만 적용된다는 점입니다.

즉, 스타일이 자동으로 스코프(scope)되어 다른 컴포넌트와 충돌하지 않도록 해줍니다.

styled-component 설치

npm install styled-components

사용 방법 예시

// Button.jsx
import styled from 'styled-components';

const StyledButton = styled.button`
  background-color: #4caf50;
  color: white;
  padding: 10px 16px;
  border: none;
  border-radius: 5px;
  cursor: pointer;

  &:hover {
    background-color: #45a049;
  }
`;

function Button({ children }) {
  return <StyledButton>{children}</StyledButton>;
}

export default Button;

이렇게 하면 StyledButton은 내부적으로 고유한 클래스명을 생성하고, 이 스타일은 다른 컴포넌트와 절대 충돌하지 않습니다. 마치 컴포넌트 하나하나가 스타일 영역을 가지는 것처럼 작동합니다.

props로 동적 스타일 처리하기

styled-components는 props를 받아서 CSS 값을 동적으로 지정할 수 있습니다.

const Input = styled.input`
  background-color: ${({ invalid }) => $invalid ? "#fed2d2" : "#d1d5db"};
  color: ${({ invalid }) => $invalid ? "#ef4444" : "#374151"};
`

<Input $invalid={emailNotValid} />

이런 방식으로 유효성 검증에 따라 스타일을 다르게 보여줄 수 있어 사용자 경험을 향상시킬 수 있습니다.

$ 접두사는 왜 쓰는 걸까? styled-components는 $로 시작하는 props는 자동으로 필터링해서 DOM에 전달하지 않도록 처리해줍니다. $invalid는 오직 스타일링에서만 사용되고, 실제 HTML 속성에는 포함되지 않기 때문에 불필요한 경고 없이 안전하게 스타일을 제어할 수 있습니다.

중첩 스타일, @media, hover 등의 사용법

styled-components는 일반 CSS 문법을 거의 그대로 사용할 수 있기 때문에, 다음과 같은 고급 기능들도 자연스럽게 적용할 수 있습니다.

✅ 중첩 선택자 (&)

const Header = styled.header`
  padding: 2rem;
  background-color: #f0f0f0;

  & h1 {
    font-size: 2rem;
    margin-bottom: 1rem;
  }

  & p {
    color: #555;
  }
`

&는 해당 styled 컴포넌트 자신을 가리킵니다. 위 예제는 Header 안의 h1과 p에 각각 스타일을 주는 방법입니다.

✅ 미디어 쿼리 (@media)

const Header = styled.header`
  margin-bottom: 2rem;

  @media (min-width: 768px) {
    margin-bottom: 4rem;
  }
`

스크린 크기에 따라 스타일을 다르게 적용할 수 있습니다. 일반 CSS에서 하던 방식 그대로 작성하면 됩니다.

✅ Pseudo 선택자 (예: :hover, :focus)

const Button = styled.button`
  background-color: #4caf50;
  color: white;

  &:hover {
    background-color: #45a049;
  }
`

hover 상태도 마찬가지로 &:hover와 같이 작성하면 됩니다. &는 항상 해당 요소 자신을 의미합니다. 빈칸 없이 이어서 써야 pseudo 선택자로 인식됩니다.

장점

스타일 충돌 걱정 X: 자동으로 고유 클래스 생성
props로 동적 스타일 처리 가능
컴포넌트 기반의 스타일링
기존 CSS 문법 대부분 사용 가능
구조화된 스타일 관리가 쉬움

주의할 점

런타임에서 CSS를 처리하므로, 매우 큰 프로젝트에서는 퍼포먼스 이슈 가능성 있음
CSS가 JS 내부에 있어 초반엔 낯설 수 있음

4️⃣ Tailwind

Tailwind CSS는 유틸리티 퍼스트(Utility-First) CSS 프레임워크입니다.

기존의 class="btn primary" 같은 추상적인 클래스명 대신, class="bg-blue-500 text-white p-4 rounded"처럼 직관적인 유틸리티 클래스들을 조합해서 스타일을 만듭니다.

설치 방법

프로젝트에 Tailwind 설치 (예: Vite 기준)

npm install -D tailwindcss postcss autoprefixer
npx tailwindcss init -p

설정 파일 (tailwind.config.js) 예시

module.exports = {
  content: ["./index.html", "./src/**/*.{js,ts,jsx,tsx}"],
  theme: {
    extend: {},
  },
  plugins: [],
}

전역 CSS 파일 설정 (index.css 등)

@tailwind base;
@tailwind components;
@tailwind utilities;

사용법

1️⃣ 기본 사용법

Tailwind는 미리 정의된 수많은 클래스들로 구성되어 있어서, 따로 .css 파일 없이도 className을 통해 바로 스타일을 만들 수 있습니다.

<button className="bg-blue-500 text-white font-bold py-2 px-4 rounded">
  로그인
</button>

위 예시처럼 bg-blue-500, text-white, px-4, rounded 등은 각각의 스타일 속성 하나에 대응하는 클래스입니다.

2️⃣ 접두어로 반응형 디자인 구성

sm:, md:, lg: 같은 접두어만 붙이면 화면 크기에 따라 반응형 스타일링이 가능합니다.

<div className="text-base md:text-xl lg:text-2xl">
  스크린 크기에 따라 글자 크기 변화
</div>

기본은 text-base
768px 이상(md): text-xl
1024px 이상(lg): text-2xl

이처럼 미디어 쿼리도 직관적인 접두어로 처리할 수 있습니다.

3️⃣ 접두어로 가상 선택자 처리

마우스를 올렸을 때, 클릭했을 때, 포커스됐을 때 등 가상 선택자도 접두어로 처리합니다.

<button className="bg-blue-500 hover:bg-blue-600 focus:ring-2 active:scale-95">
  상호작용 가능한 버튼
</button>

hover:bg-blue-600: 마우스를 올리면 배경색 변경
focus:ring-2: 포커스 시 ring 효과
active:scale-95: 클릭 시 약간 작아지는 애니메이션

Tailwind의 진짜 강점은 반응형 접두어 + 상태 접두어를 조합해서 사용할 수 있다는 점입니다.

<button className="bg-blue-500 hover:bg-blue-600 md:hover:bg-green-500">
  반응형 hover 버튼
</button>

작은 화면에서는 hover:bg-blue-600
md 이상에서는 hover:bg-green-500

이렇게 화면 크기와 상태를 동시에 고려한 스타일도 아주 간결하게 구현할 수 있습니다.

자주 쓰는 클래스 예시

목적 클래스 예시

배경색	bg-red-500, bg-gray-100
글자 색	text-white, text-gray-800
마진/패딩	m-4, mt-2, p-6, px-4
폰트 스타일	font-bold, text-xl, tracking-wide
정렬	flex, justify-between, items-center
버튼 꾸미기	hover:bg-blue-700, rounded, shadow

장점 및 단점

스타일 충돌 걱정 없음 (클래스를 직접 조합)
반응형, 상태 변화도 직관적인 클래스 조합
따로 CSS 파일 안 만들어도 돼서 빠름
⚠️ 하지만 클래스가 너무 많아지면 가독성이 떨어질 수도 있음
→ clsx, classnames, 컴포넌트 분리로 해결 가능

팁: 클래스 너무 길어져 가독성이 떨어져요

이럴 땐 Tailwind와 함께 clsx 또는 classnames 라이브러리를 활용하거나, 컴포넌트 단위로 분리해서 관리하는 방법도 있어요.

npm install clsx

import clsx from 'clsx';

const buttonClass = clsx(
  'bg-blue-500',
  'text-white',
  'font-bold',
  'py-2',
  'px-4',
  'rounded',
  { 'opacity-50': isDisabled }
);

도움이 되셨다면 ❤️ 좋아요와 댓글로 피드백 주세요!

궁금한 점이 있다면 언제든지 질문 환영입니다

지금까지 읽어주셔서 감사합니다!

[React] Tailwind 사용하여 스타일링 하기

제가안난데여♪(´ε｀*) — Wed, 23 Apr 2025 13:40:16 +0900

이 글은 Udemy의 【한글자막】 React 완벽 가이드 2025 with React Router & Redux 를 수강하고 정리한 내용입니다.

Tailwind CSS는 유틸리티 퍼스트(Utility-First) CSS 프레임워크입니다.

설치 방법

프로젝트에 Tailwind 설치 (예: Vite 기준)

npm install -D tailwindcss postcss autoprefixer
npx tailwindcss init -p

설정 파일 (tailwind.config.js) 예시

module.exports = {
  content: ["./index.html", "./src/**/*.{js,ts,jsx,tsx}"],
  theme: {
    extend: {},
  },
  plugins: [],
}

전역 CSS 파일 설정 (index.css 등)

@tailwind base;
@tailwind components;
@tailwind utilities;

사용법

1️⃣ 기본 사용법

Tailwind는 미리 정의된 수많은 클래스들로 구성되어 있어서, 따로 .css 파일 없이도 className을 통해 바로 스타일을 만들 수 있습니다.

<button className="bg-blue-500 text-white font-bold py-2 px-4 rounded">
  로그인
</button>

위 예시처럼 bg-blue-500, text-white, px-4, rounded 등은 각각의 스타일 속성 하나에 대응하는 클래스입니다.

2️⃣ 접두어로 반응형 디자인 구성

sm:, md:, lg: 같은 접두어만 붙이면 화면 크기에 따라 반응형 스타일링이 가능합니다.

<div className="text-base md:text-xl lg:text-2xl">
  스크린 크기에 따라 글자 크기 변화
</div>

기본은 text-base
768px 이상(md): text-xl
1024px 이상(lg): text-2xl

이처럼 미디어 쿼리도 직관적인 접두어로 처리할 수 있습니다.

3️⃣ 접두어로 가상 선택자 처리

마우스를 올렸을 때, 클릭했을 때, 포커스됐을 때 등 가상 선택자도 접두어로 처리합니다.

<button className="bg-blue-500 hover:bg-blue-600 focus:ring-2 active:scale-95">
  상호작용 가능한 버튼
</button>

hover:bg-blue-600: 마우스를 올리면 배경색 변경
focus:ring-2: 포커스 시 ring 효과
active:scale-95: 클릭 시 약간 작아지는 애니메이션

Tailwind의 진짜 강점은 반응형 접두어 + 상태 접두어를 조합해서 사용할 수 있다는 점입니다.

<button className="bg-blue-500 hover:bg-blue-600 md:hover:bg-green-500">
  반응형 hover 버튼
</button>

작은 화면에서는 hover:bg-blue-600
md 이상에서는 hover:bg-green-500

이렇게 화면 크기와 상태를 동시에 고려한 스타일도 아주 간결하게 구현할 수 있습니다.

자주 쓰는 클래스 예시

목적 클래스 예시

배경색	bg-red-500, bg-gray-100
글자 색	text-white, text-gray-800
마진/패딩	m-4, mt-2, p-6, px-4
폰트 스타일	font-bold, text-xl, tracking-wide
정렬	flex, justify-between, items-center
버튼 꾸미기	hover:bg-blue-700, rounded, shadow

장점 및 단점

스타일 충돌 걱정 없음 (클래스를 직접 조합)
반응형, 상태 변화도 직관적인 클래스 조합
따로 CSS 파일 안 만들어도 돼서 빠름
⚠️ 하지만 클래스가 너무 많아지면 가독성이 떨어질 수도 있음
→ clsx, classnames, 컴포넌트 분리로 해결 가능

팁: 클래스 너무 길어져 가독성이 떨어져요

이럴 땐 Tailwind와 함께 clsx 또는 classnames 라이브러리를 활용하거나, 컴포넌트 단위로 분리해서 관리하는 방법도 있어요.

npm install clsx

import clsx from 'clsx';

const buttonClass = clsx(
  'bg-blue-500',
  'text-white',
  'font-bold',
  'py-2',
  'px-4',
  'rounded',
  { 'opacity-50': isDisabled }
);

도움이 되셨다면 ❤️ 좋아요와 댓글로 피드백 주세요!

궁금한 점이 있다면 언제든지 질문 환영입니다

지금까지 읽어주셔서 감사합니다!

[React] Styled Components 사용하기

제가안난데여♪(´ε｀*) — Wed, 23 Apr 2025 13:38:42 +0900

이 글은 Udemy의 【한글자막】 React 완벽 가이드 2025 with React Router & Redux 를 수강하고 정리한 내용입니다.

styled-component 는 CSS-in-JS 방식을 사용하는 라이브러리입니다.

즉, 스타일이 자동으로 스코프(scope)되어 다른 컴포넌트와 충돌하지 않도록 해줍니다.

styled-component 설치

npm install styled-components

사용 방법 예시

// Button.jsx
import styled from 'styled-components';

const StyledButton = styled.button`
  background-color: #4caf50;
  color: white;
  padding: 10px 16px;
  border: none;
  border-radius: 5px;
  cursor: pointer;

  &:hover {
    background-color: #45a049;
  }
`;

function Button({ children }) {
  return <StyledButton>{children}</StyledButton>;
}

export default Button;

props로 동적 스타일 처리하기

styled-components는 props를 받아서 CSS 값을 동적으로 지정할 수 있습니다.

const Input = styled.input`
  background-color: ${({ invalid }) => $invalid ? "#fed2d2" : "#d1d5db"};
  color: ${({ invalid }) => $invalid ? "#ef4444" : "#374151"};
`

<Input $invalid={emailNotValid} />

이런 방식으로 유효성 검증에 따라 스타일을 다르게 보여줄 수 있어 사용자 경험을 향상시킬 수 있습니다.

$ 접두사는 왜 쓰는 걸까? styled-components는 $로 시작하는 props는 자동으로 필터링해서 DOM에 전달하지 않도록 처리해줍니다. $invalid는 오직 스타일링에서만 사용되고, 실제 HTML 속성에는 포함되지 않기 때문에 불필요한 경고 없이 안전하게 스타일을 제어할 수 있습니다.

중첩 스타일, @media, hover 등의 사용법

styled-components는 일반 CSS 문법을 거의 그대로 사용할 수 있기 때문에, 다음과 같은 고급 기능들도 자연스럽게 적용할 수 있습니다.

✅ 중첩 선택자 (&)

const Header = styled.header`
  padding: 2rem;
  background-color: #f0f0f0;

  & h1 {
    font-size: 2rem;
    margin-bottom: 1rem;
  }

  & p {
    color: #555;
  }
`

&는 해당 styled 컴포넌트 자신을 가리킵니다. 위 예제는 Header 안의 h1과 p에 각각 스타일을 주는 방법입니다.

✅ 미디어 쿼리 (@media)

const Header = styled.header`
  margin-bottom: 2rem;

  @media (min-width: 768px) {
    margin-bottom: 4rem;
  }
`

스크린 크기에 따라 스타일을 다르게 적용할 수 있습니다. 일반 CSS에서 하던 방식 그대로 작성하면 됩니다.

✅ Pseudo 선택자 (예: :hover, :focus)

const Button = styled.button`
  background-color: #4caf50;
  color: white;

  &:hover {
    background-color: #45a049;
  }
`

hover 상태도 마찬가지로 &:hover와 같이 작성하면 됩니다. &는 항상 해당 요소 자신을 의미합니다. 빈칸 없이 이어서 써야 pseudo 선택자로 인식됩니다.

장점

스타일 충돌 걱정 X: 자동으로 고유 클래스 생성
props로 동적 스타일 처리 가능
컴포넌트 기반의 스타일링
기존 CSS 문법 대부분 사용 가능
구조화된 스타일 관리가 쉬움

주의할 점

런타임에서 CSS를 처리하므로, 매우 큰 프로젝트에서는 퍼포먼스 이슈 가능성 있음
CSS가 JS 내부에 있어 초반엔 낯설 수 있음

도움이 되셨다면 ❤️ 좋아요와 댓글로 피드백 주세요!

궁금한 점이 있다면 언제든지 질문 환영입니다

지금까지 읽어주셔서 감사합니다!

[React] CSS Module 사용하기

제가안난데여♪(´ε｀*) — Wed, 23 Apr 2025 13:37:24 +0900

이 글은 Udemy의 【한글자막】 React 완벽 가이드 2025 with React Router & Redux 를 수강하고 정리한 내용입니다.

create-react-app을 사용하면, CSS Modules는 기본적으로 지원됩니다. .module.css 확장자를 사용하면 됩니다.

Button.module.css

/* Button.module.css */
.button {
  background-color: green;
  color: white;
  padding: 10px;
}

Button.js

// Button.js
import React from 'react';
import styles from './Button.module.css';

function Button() {
  return <button className={styles.button}>Click me!</button>;
}

export default Button;

도움이 되셨다면 ❤️ 좋아요와 댓글로 피드백 주세요!

궁금한 점이 있다면 언제든지 질문 환영입니다

지금까지 읽어주셔서 감사합니다!

[React] style Prop 사용하여 Inline(인라인)으로 css 적용하기

제가안난데여♪(´ε｀*) — Wed, 23 Apr 2025 13:36:04 +0900

이 글은 Udemy의 【한글자막】 React 완벽 가이드 2025 with React Router & Redux 를 수강하고 정리한 내용입니다.

style Prop 기본 사용법

CSS 속성 이름은 camelCase로 작성
값은 문자열 또는 숫자로 작성

function App() {

  return (
    <div>
      <button 
        style={{
          backgroundColor: 'red',  // 고정된 색상
          color: 'white',
          padding: '10px 20px',
          border: 'none',
          cursor: 'pointer'
        }} 
      >
        Click me!
      </button>
    </div>
  );
}

export default App;

동적 스타일링 가능

import React, { useState } from 'react';

function App() {
  // useState 훅을 사용하여 isClicked 상태를 정의합니다. 초기 값은 false입니다.
  const [isClicked, setIsClicked] = useState(false);

  // 버튼 클릭 시 호출되는 함수입니다. 상태를 반전시켜 isClicked 값을 변경합니다.
  const handleClick = () => {
    setIsClicked(prev => !prev); // 이전 상태의 반대로 값을 변경합니다.
  };

  // 버튼 스타일을 동적으로 생성합니다. isClicked 상태에 따라 배경색이 바뀝니다.
  const buttonStyle = {
    backgroundColor: isClicked ? 'green' : 'red', // 상태에 따라 배경색을 green 또는 red로 설정
    color: 'white', 
    padding: '10px 20px',
    border: 'none', 
    cursor: 'pointer'
  };

  return (
    <div>
      {/* label 태그는 버튼을 설명하는 텍스트를 포함합니다. 
           isClicked 상태에 따라 'clicked' 클래스를 동적으로 추가 */}
      <label className={`label ${isClicked ? 'clicked' : ''}`}>Button</label>

      {/* 버튼은 style prop을 사용하여 동적으로 스타일을 적용하고, 
           클릭 시 handleClick 함수가 호출되어 isClicked 상태가 변경됩니다. */}
      <button style={buttonStyle} onClick={handleClick}>
        {/* 버튼 텍스트는 isClicked 상태에 따라 'Clicked' 또는 'Click me!'로 변경 */}
        {isClicked ? 'Clicked' : 'Click me!'}
      </button>
    </div>
  );
}

export default App;

style Prop 사용 시 장점

컴포넌트 내에서 간편한 스타일링
동적 스타일 적용
외부 라이브러리 의존성 없음

style Prop 사용 시 단점

스타일 재사용 어려움
성능 이슈
- 매번 새로운 스타일 객체가 생성되어 리렌더링 성능에 영향을 미칠 수 있다.
복잡한 스타일링에 한계
스타일 객채와 jsx의 상태와 강한 의존성

도움이 되셨다면 ❤️ 좋아요와 댓글로 피드백 주세요!

궁금한 점이 있다면 언제든지 질문 환영입니다

지금까지 읽어주셔서 감사합니다!

[React] 커스텀 훅(Custom Hook)

제가안난데여♪(´ε｀*) — Tue, 22 Apr 2025 16:20:18 +0900

이 글은 Udemy의 【한글자막】 React 완벽 가이드 2025 with React Router & Redux 를 수강하고 정리한 내용입니다.

React를 사용하다 보면 컴포넌트마다 비슷한 로직이 반복되는 경우가 많습니다.

예를 들어, 데이터를 가져오기 위해 useEffect 안에서 fetch 요청을 보내고, loading 상태와 error 상태를 관리하는 코드를 여러 컴포넌트에서 반복하게 되기도 합니다.

이럴 때 유용하게 사용할 수 있는 것이 바로 "커스텀 훅(Custom Hook)" 입니다.

먼저, 리액트 훅의 두 가지 규칙부터 다시 복습!

리액트 훅은 컴포넌트 함수 또는 다른 훅 안에서만 사용 가능
- 일반 함수에서는 사용 불가능합니다.
훅은 조건문, 반복문, 중첩 함수 안에서 호출하면 안 됨

커스텀 훅이 필요한 이유

중복되는 훅 로직을 재사용하기 위해
상태(useState)나 사이드 이펙트(useEffect) 같은 훅을 포함한 로직을 분리하여 깔끔하게 유지
JSX를 반환하지 않는 순수한 로직은 컴포넌트로 분리할 수 없기 때문에, 커스텀 훅으로 처리
동일한 훅 로직을 다양한 컴포넌트에서 사용 가능
설정에 따라 유연하게 동작을 바꿀 수 있도록 설계할 수 있음

예시: 데이터를 fetch하는 커스텀 훅

아래는 useFetch라는 커스텀 훅의 예시입니다.

이 훅은 fetch 함수와 초기값을 인자로 받아 데이터를 가져오고, 상태를 관리합니다.

import { useEffect, useState } from "react";

export function useFetch(fetchFn, initialValue) {
  const [isFetching, setIsFetching] = useState();
  const [error, setError] = useState();
  const [fetchedData, setFetchedData] = useState(initialValue);

  useEffect(() => {
    async function fetchData() {
      setIsFetching(true);
      try {
        const data = await fetchFn();
        setFetchedData(data);
      } catch (error) {
        setError({ message: error.message || "Failed to fetch data." });
      }

      setIsFetching(false);
    }

    fetchData();
  }, [fetchFn]);

  return {
    isFetching,
    error,
    fetchedData,
    setFetchedData,
  };
}

이 커스텀 훅이 하는 일

데이터를 비동기적으로 받아오고
로딩 상태와 에러 상태를 자동으로 처리하며
필요하면 setFetchedData로 데이터를 외부에서 업데이트할 수도 있도록 합니다

커스텀 훅 사용의 특징

useFetch 같은 커스텀 훅은 use로 시작해야 React가 훅으로 인식합니다.
커스텀 훅은 JSX를 반환하지 않으며, 컴포넌트처럼 상태 관리 로직만 분리하는 데 초점을 둡니다.
동일한 커스텀 훅을 여러 컴포넌트에서 사용해도, 상태는 공유되지 않습니다.
→ 각 컴포넌트는 훅을 독립적으로 사용하며, 각각의 상태를 가집니다.
setFetchedData처럼 상태 업데이트 함수를 반환값에 포함시켜 외부에서 데이터 제어도 가능합니다.

⚠️ 커스텀 훅 만들 때 주의할 점

이름은 반드시 use로 시작해야 React가 이를 훅으로 처리할 수 있습니다.
내부에서 다른 훅(useState, useEffect 등)을 자유롭게 사용할 수 있습니다.
위에서 언급한 훅의 규칙은 커스텀 훅에도 동일하게 적용됩니다.
- 조건문 안에서 훅을 사용하면 안 되고, 최상위 레벨에서만 호출해야 합니다.

도움이 되셨다면 ❤️ 좋아요와 댓글로 피드백 주세요!

궁금한 점이 있다면 언제든지 질문 환영입니다

지금까지 읽어주셔서 감사합니다!

[React] HTTP 통신 : fetch로 데이터 요청하고 로딩/에러 처리까지

제가안난데여♪(´ε｀*) — Tue, 22 Apr 2025 10:19:02 +0900

이 글은 Udemy의 【한글자막】 React 완벽 가이드 2025 with React Router & Redux 를 수강하고 정리한 내용입니다.

이번 글에서는 React에서 HTTP 요청을 다루는 데 사용되는 기본적인 fetch API와 이를 어떻게 효율적으로 처리할 수 있는지에 대해 알아보겠습니다. 특히, 로딩 상태와 에러 처리를 어떻게 관리하는지를 다룰 예정입니다.

✅ 기본 fetch API 사용법 (GET 요청)

1. fetch + .then() 사용

useEffect(() => {
  fetch('<http://localhost:3000/places>')
    .then((response) => response.json())
    .then((resData) => setAvailablePlaces(resData.places));
}, []);

response.json()은 비동기 작업이므로 두 번째 .then()에서 실제 데이터를 처리하기 위해 then 체인을 두번 사용하게 됩니다.
useEffect에 빈 의존성 배열 ([]) 을 전달해야, 초기 렌더링 시 한 번만 실행됩니다. (무한루프 방지)

2. async/await 방식

useEffect(() => {
  async function fetchPlaces() {
    const response = await fetch('<http://localhost:3000/places>');
    const resData = await response.json();
    setAvailablePlaces(resData.places);
  }
  fetchPlaces();
}, []);

async/await 방식은 코드가 간결하고 가독성이 좋으며, 에러 처리에도 유리합니다.

✅ 로딩 상태 관리

데이터를 요청하는 동안 isFetching 상태를 true로 설정하고, 완료되면 다시 false로 변경합니다.

const [isFetching, setIsFetching] = useState(false);

useEffect(() => {
  async function fetchPlaces() {
    setIsFetching(true); // ✅ 요청 시작 시
    const response = await fetch('<http://localhost:3000/places>');
    const resData = await response.json();
    setAvailablePlaces(resData.places);
    setIsFetching(false); // ✅ 요청 완료 시
  }
  fetchPlaces();
}, []);

렌더링 흐름 요약

️ 초기 렌더링: isFetching=false, 데이터는 빈 배열
로딩 시작: isFetching=true, 로딩 UI 표시 가능
✅ 로딩 완료: isFetching=false, 데이터 반영

1. 초기 렌더링 (첫 번째 렌더링)

페이지에 처음 접속하면 useEffect가 실행되기 전에 컴포넌트가 렌더링됩니다.
초기 상태는 isFetching이 false, availablePlaces는 빈 배열입니다.
이때, "Fetching..." 같은 로딩 메시지가 없다면 그냥 빈 UI가 렌더링됩니다.

2. useEffect 실행

useEffect가 실행되면 fetchPlaces 함수가 호출되고, **setIsFetching(true)*가 실행됩니다.
이때, isFetching 값이 true로 변경되고, 첫 번째 리렌더링이 발생합니다.
- 이 리렌더링에서는 isFetching이 true로 변경된 상태이므로, 로딩 UI(예: "Fetching...")가 나타날 수 있습니다.

3. fetch 완료 후 상태 업데이트

fetch 요청이 끝나면, 응답을 받아서 setAvailablePlaces(resData.places)와 setIsFetching(false)를 호출합니다.
이때 setAvailablePlaces와 setIsFetching(false)가 두 번 호출됩니다.
- 두 번째 리렌더링이 발생하고, isFetching이 false로 바뀌며 데이터도 업데이트됩니다.

✅ HTTP 에러 처리

API 요청 중 실패할 경우를 대비해 try-catch로 에러를 처리합니다.

const [error, setError] = useState();

useEffect(() => {
  async function fetchPlaces() {
    setIsFetching(true);

    try {
      const response = await fetch('<http://localhost:3000/places>');
      const resData = await response.json();

      if (!response.ok) {
        throw new Error('Failed to fetch places.');
      }

      setAvailablePlaces(resData.places);
    } catch (error) {
      setError({ message: error.message || 'Could not fetch places.' });
    }

    setIsFetching(false);
  }

  fetchPlaces();
}, []);

위치 정보 수신 전에 로딩이 끝나버리는 문제

문제 상황

위치 기반으로 장소 데이터를 정렬하려는 로직에서, 위치 정보 수신 전에 isFetching을 false로 설정해버려서, 정렬 전 데이터가 화면에 잠깐 노출되는 UX 버그가 발생했습니다.

useEffect(() => {
  async function fetchPlaces() {
    setIsFetching(true);

    try {
      const response = await fetch("<http://localhost:3000/places>");
      const resData = await response.json();

      // ✅ 위치 요청 (비동기)
      navigator.geolocation.getCurrentPosition((position) => {
        const sortedPlaces = sortPlacesByDistance(
          resData.places,
          position.coords.latitude,
          position.coords.longitude
        );
        setAvailablePlaces(sortedPlaces);
      });
    } catch (error) {
      setError({ message: error.message });
    }

    setIsFetching(false); // ❗ 위치 정렬이 끝나기 전에 로딩 상태 종료됨
  }

  fetchPlaces();
}, []);

실제 콘솔 로그 흐름 예시

[1] ===   [fetchPlaces] 시작 ===
[2]   [isFetching] true 설정됨
[3]   [fetch] 요청 성공
[4]   [JSON 파싱 완료] {places: Array(18)}
[5]   [위치 요청] 사용자 위치 가져오는 중...
[6] ✅ [isFetching] false 설정됨    // <===   위치 기반 정렬은 아직 안 끝났음
[7] ===   [fetchPlaces] 종료 ===
[8] ✅ [위치 정보] 수신 완료: latitude: 37.4111, longitude: 127.0983
[9]  ️ [정렬 완료] 거리순 장소 목록: (18) [...]
[10]   [setAvailablePlaces] 정렬된 데이터 적용

문제의 원인

포인트 설명	설명
⚠️ getCurrentPosition()은 비동기	위치 정보는 즉시 반환되지 않고, 나중에 콜백이 실행됩니다.
⚠️ setIsFetching(false)가 너무 일찍 실행됨	위치 정보가 도착하기도 전에 로딩을 종료시켜 버립니다.
⚠️ 사용자 입장에선 이상하게 느껴짐	처음엔 기본 정렬 데이터가 보이다가, 몇 초 후에 갑자기 재정렬되어 "깜빡이거나 버벅이는 UI" 가 됩니다.

✅ 해결 방법

이 문제를 해결하기 위해서는 위치 정보 요청과 로딩 상태 변경을 적절히 관리해야 합니다. setIsFetching(false)를 위치 정보 수신 후에 변경되도록 수정하여, 데이터가 제대로 정렬된 후에 로딩 상태가 종료되도록 합니다.

수정된 코드

useEffect(() => {
  async function fetchPlaces() {
    setIsFetching(true);

    try {
      const response = await fetch("<http://localhost:3000/places>");
      const resData = await response.json();

      navigator.geolocation.getCurrentPosition((position) => {
        const sortedPlaces = sortPlacesByDistance(
          resData.places,
          position.coords.latitude,
          position.coords.longitude
        );
        setAvailablePlaces(sortedPlaces);
        setIsFetching(false); // ✅ 위치 기반 정렬이 끝난 후 로딩 종료
      });
    } catch (error) {
      setError({ message: error.message });
      setIsFetching(false); // ⚠️ 에러가 난 경우도 잊지 말고 로딩 종료
    }
  }

  fetchPlaces();
}, []);

변경 후 로그 흐름 예시

[1] ===   [fetchPlaces] 시작 ===  
[2]   [isFetching] true 설정됨  
[3]   [fetch] 요청 성공  
[4]   [JSON 파싱 완료] {places: Array(18)}  
[5]   [위치 요청] 사용자 위치 가져오는 중...  
[6] ===   [fetchPlaces] 종료 ===  
[7] ✅ [위치 정보] 수신 완료: latitude: 37.4111713, longitude: 127.098369  
[8]  ️ [정렬 완료] 거리순 장소 목록: (18) [...]  
[9]   [setAvailablePlaces] 정렬된 데이터 적용  
[10] ✅ [isFetching] false 설정됨

이제 setIsFetching(false)가 위치 정보를 받고, 장소 목록을 정렬한 후 호출되므로, 로딩 UI가 올바르게 처리됩니다.

✅ 기본 fetch API 사용법 (PUT 요청)

https.js

export async function updateUserPlaces(places) {
  const response = await fetch("<http://localhost:3000/user-places>", {
    method: "PUT",
    body: JSON.stringify({ places }), // {places: places}와 동일
    headers: {
      "Content-Type": "application/json",
    },
  });

  const resData = await response.json();

  if (!response.ok) {
    throw new Error("Failed to update user places.");
  }

  return resData.message;
}

App.jsx

export async function handleSelectPlace(selectedPlace) {
		// 상태 업데이트
    setUserPlaces((prevPickedPlaces) => {
      ....
      return [selectedPlace, ...prevPickedPlaces];
    });

    // backend 통신 함수 호출
    try {
      await updateUserPlaces([selectedPlace, ...userPlaces]);
    } catch (error) {
      console.error("Error updating user places:", error);
      setUserPlaces(userPlaces); // 백엔드 단에서 에러가 발생했을 때, 원래의 userPlaces로 되돌리기
    }
  }

✅ 낙관적 업데이트 vs 비관적 업데이트

낙관적 업데이트 (Optimistic Update)

“낙관적 업데이트(Optimistic Update)”는 UI를 더 빠르게 반응시키기 위한 전략 중 하나로 서버의 응답을 기다리지 않고, 사용자에게 먼저 결과가 적용된 것처럼 보여주는 방식 말합니다.

사용자 행동에 즉시 반응하여 UI를 먼저 업데이트한 후, 백엔드 응답 결과에 따라 유지하거나 롤백합니다.

async function handleSelectPlace(selectedPlace) {
  setUserPlaces((prevPickedPlaces) => [selectedPlace, ...prevPickedPlaces]);

  try {
    await updateUserPlaces([selectedPlace, ...userPlaces]);
  } catch (error) {
    console.error("Error updating user places:", error);
    setUserPlaces(userPlaces); // ❗ 실패 시 원래 상태로 되돌리기
  }
}

✅ 장점

체감 성능이 빠르고 반응성이 좋음
UX가 즉각적이고 부드러움

❌ 단점

실패 가능성을 고려해야 하며
되돌리기(rollback) 로직을 반드시 구현해야 함

비관적 업데이트 (Pessimistic Update)

서버의 응답을 받은 후에야 UI를 업데이트합니다.

async function handleSelectPlace(selectedPlace) {
  await updateUserPlaces([selectedPlace]);

  setUserPlaces((prevPickedPlaces) => {
    if (prevPickedPlaces.some((place) => place.id === selectedPlace.id)) {
      return prevPickedPlaces;
    }
    return [selectedPlace, ...prevPickedPlaces];
  });
}

✅ 특징

안정성은 높지만
사용자 입장에서 반응이 느려 보일 수 있음

도움이 되셨다면 ❤️ 좋아요와 댓글로 피드백 주세요!

궁금한 점이 있다면 언제든지 질문 환영입니다

지금까지 읽어주셔서 감사합니다!

[React] 리액트 클래스 컴포넌트, 왜 아직도 알아야 할까?

제가안난데여♪(´ε｀*) — Fri, 18 Apr 2025 22:13:30 +0900

이 글은 Udemy의 【한글자막】 React 완벽 가이드 2025 with React Router & Redux 를 수강하고 정리한 내용입니다.

이번 글에서는 클래스 컴포넌트의 구조, 생명주기 메서드, 컨텍스트 사용 방식, 그리고 오류 경계까지 정리해봤습니다. ✍️

클래스 컴포넌트 기본 구조

class MyComponent extends React.Component {
  render() {
    return <h1>Hello, {this.props.name}!</h1>;
  }
}

React.Component를 상속받아 정의합니다.
render() 메서드 안에서 JSX를 반환해야 합니다.

왜 존재할까?

React 16.8 이전에는 state나 생명주기 메서드를 사용하려면 클래스 컴포넌트로 작성해야 했습니다.

이후 Hooks가 등장하면서 함수형 컴포넌트에서도 동일한 기능이 가능해졌고, 지금은 함수형이 대세가 되었습니다.

클래스에서 상태(State) 관리

constructor() {
  super(); // 반드시 호출
  this.state = {
    showUsers: true,
    // 다른 상태들도 이 객체 안에 정의
  };
}

toggleUsersHandler() {
  this.setState((prevState) => {
    return { showUsers: !prevState.showUsers };
  });
}

클래스 컴포넌트에서는 상태를 객체로 관리되어 집니다.
생성자(constructor)에서 this.state = { ... }로 초기화합니다.
상태 변경은 this.setState()로 수행하며 기존 상태와 병합되므로 전체를 덮어쓰지 않기 때문에 부분 업데이트가 가능합니다.
이벤트 핸들러는 반드시 this 바인딩 필요 합니다.

this.toggleUsersHandler.bind(this)

생명주기 메서드 (Lifecycle Methods)

함수형 컴포넌트의 useEffect()와 대응되는 클래스 컴포넌트의 고유 메서드입니다.

생명주기 메서드 언제 실행되나요? useEffect와 비교

componentDidMount()	컴포넌트가 마운트된 직후 실행됨	useEffect(() => { }, [])
componentDidUpdate()	컴포넌트가 업데이트된 후 실행됨	useEffect(() => { }, [value])
componentWillUnmount()	컴포넌트가 언마운트되기 직전에 실행됨	useEffect(() => { return () => {} }, [])

✅ componentDidMount는 API 호출이나 초기 설정 작업에 자주 사용됩니다.

클래스 컴포넌트에서 Context 사용하기

✅ 방법 1: <Context.Consumer> 사용

<UsersContext.Consumer>
  {(ctx) => <div>{ctx.users[0].name}</div>}
</UsersContext.Consumer>

함수형과 클래스형 컴포넌트 모두에서 사용할 수 있습니다.
단점 : 매번 Consumer로 감싸야 하기 때문에 코드가 길어지고 복잡해질 수 있습니다.

✅ 방법 2: static contextType 사용하기 (클래스 컴포넌트 전용)

import UsersContext from "../store/users-context";

class UserFinder extends Component {
  static contextType = UsersContext;

  componentDidMount() {
    console.log(this.context.users); // 여기서 컨텍스트 데이터 사용 가능
  }

  render() {
    return <Users users={this.context.users} />;
  }
}

클래스 컴포넌트에서 가장 많이 쓰는 Context 접근 방식입니다.
컴포넌트에 static contextType = UsersContext를 선언하면, → React가 내부적으로 해당 Context의 값을 this.context에 자동으로 넣어줍니다
단점: 한 컴포넌트에 오직 하나의 context만 연결 가능

왜 static이어야 할까?

static 속성은 클래스의 인스턴스가 아니라 클래스 자체에 바인딩되는 속성입니다.

따라서 React는 컴포넌트가 인스턴스화되기 전에 이 정보를 미리 읽고 준비할 수 있습니다.

즉, 렌더링 전에 "아, 이 컴포넌트는 어떤 Context랑 연결되어 있어야 하구나!" 를 인지할 수 있는 방식이에요.

❓ 그럼 왜 하나만 연결 가능?

contextType은 하나의 값만 가질 수 있는 정적 속성

즉, static이라는 속성은 중복 선언이 불가능하니까

오류 경계(Error Boundary)

하위 컴포넌트에서 예기치 못한 오류가 발생하더라도 자동으로 감지하고 처리하여 전체 앱이 죽지 않도록 방지하기 위해 사용합니다.
단,이 기능은 클래스 컴포넌트에서만 구현할 수 있습니다.

import { Component } from 'react';

class ErrorBoundary extends Component {
  constructor() {
    super();
    this.state = { hasError: false };
  }

  componentDidCatch(error, info) {
    // 오류 로깅 가능
    this.setState({ hasError: true });
  }

  render() {
    if (this.state.hasError) {
      return <p>문제가 발생했습니다.  </p>;
    }

    return this.props.children;
  }
}

export default ErrorBoundary;

사용 예시:

import ErrorBoundary from './ErrorBoundary';
import Users from './Users';

function App() {
  return (
    <ErrorBoundary>
      <Users />
    </ErrorBoundary>
  );
}

Users 컴포넌트에서 오류가 발생해도 전체 앱이 중단되지 않고 "문제가 발생했습니다" 메시지를 출력하게 됩니다.

⚠️ 주의할 점

반드시 클래스 컴포넌트여야 합니다.

함수형 컴포넌트에서는 componentDidCatch()를 사용할 수 없습니다.

여러 오류 처리 방식이 필요하다면 각 컴포넌트에 별도의 오류 경계를 만들 수도 있습니다.

도움이 되셨다면 ❤️ 좋아요와 댓글로 피드백 주세요!

궁금한 점이 있다면 언제든지 질문 환영입니다

지금까지 읽어주셔서 감사합니다!

[React]⚡️React 성능 최적화 정리: memo, useMemo, 그리고 key의 역할까지!

제가안난데여♪(´ε｀*) — Thu, 17 Apr 2025 21:45:27 +0900

이 글은 Udemy의 【한글자막】 React 완벽 가이드 2025 with React Router & Redux 를 수강하고 정리한 내용입니다.

memo 함수

memo 함수는 불필요한컴포넌트를 다시 렌더링 하지 않도록 방지하는 함수입니다.

import React, { memo } from "react";

const MyComponent = memo(function MyComponent(props) {
  // ...
});

부모 컴포넌트가 렌더링되면 자식 컴포넌트도 기본적으로 함께 렌더링됩니다. 하지만 자식 컴포넌트의 props가 변하지 않았다면 굳이 다시 렌더링할 필요가 없습니다.
이럴 때 memo로 감싸면, props가 이전과 동일할 경우 렌더링을 건너뜁니다. 즉, 컴호넌트 함수가 다시 호출 되지 않게 됩니다.
✅ 사용 전: 상태 변경 시 Counter 컴포넌트가 계속 실행됨

✅ 사용 후: memo 적용 시 Counter는 props가 동일하면 재실행되지 않음

✅ 작동 원리

memo는 이전 props와 새로운 props를 얕게(shallow) 비교해서 동일하면 컴포넌트를 재실행하지 않도록 막습니다.
함수 컴포넌트 내의 상태가 바뀌는 건 막지 않아요. 부모 컴포넌트로부터 호출되는 경우에만 최적화됩니다.

⚠️ 모든 컴포넌트에 memo를 쓰는 건 오히려 성능 저하를 불러올 수 있습니다.

props가 객체나 함수일 경우 비교가 까다로워 매번 새로 만들어졌다고 판단할 수 있기 때문입니다.

그래서 렌더링이 자주 발생하지만 props는 거의 바뀌지 않는 컴포넌트에만 사용하는 게 좋습니다.

useMemo() 훅

useMemo()는 컴포넌트 내부의 복잡한 연산이 포함된 함수의 재실행을 방지하는 데 사용됩니다.
memo가 전체 컴포넌트의 리렌더링을 막는 것과 달리, useMemo는 특정 값의 계산 결과를 메모이제이션합니다.

const initialCountIsPrime = useMemo(
  () => isPrime(initialCount),
  [initialCount]
);

첫 번째 인자는 실행할 함수를 전달하고, 두 번째 배열은 해당 함수를 다시 실행할 조건을 지정합니다.
의존성 배열 내 값이 바뀌지 않는 한, 이전에 계산한 값을 재사용합니다.

⚠️ useMemo 또한 모든 연산에 무조건 사용하는 것은 좋지 않습니다.

메모이제이션을 위한 연산도 비용이 들기 때문에, 연산이 무겁고 자주 바뀌지 않는 값에만 사용하는 것이 좋습니다

컴포넌트 함수의 실행 흐름

컴포넌트가 실행되면, React는 가상 DOM(Virtual DOM) 을 생성합니다.
이 가상 DOM과 이전 렌더의 가상 DOM을 비교하여 변경 사항을 찾아냅니다.
변경된 부분만 실제 DOM에 적용하여 성능을 최적화합니다.

가상 DOM을 사용하는 이유는 실제 DOM 조작보다 훨씬 빠르게 메모리에서 연산이 가능하기 때문입니다.

State 관리에서 key의 역할

컴포넌트는 각자 고유한 state를 가지며, 같은 컴포넌트를 여러 번 사용해도 상태는 서로 독립적입니다.
배열을 렌더링할 때 key 값을 index로 사용하는 것은 지양해야 합니다.
그 이유는 다음과 같습니다:

문제점:

배열 앞에 요소가 추가되면 기존 index가 바뀌어, 잘못된 상태가 다른 항목에 적용될 수 있습니다.
React가 변경 여부를 정확하게 파악하지 못해 전체 항목을 다시 렌더링할 수 있습니다.

해결 방법:

key는 고유 ID를 사용하는 것이 바람직합니다.
이렇게 하면 React가 각 항목을 정확히 추적할 수 있어 불필요한 렌더링을 줄이고 성능도 향상됩니다.

key의 또 다른 역할

<Counter initialCount={chosenCount} />

위 코드에서 chosenCount가 변경되어도, Counter 컴포넌트는 재사용되며 내부 상태는 유지됩니다.
이는 useState(initialCount)가 최초 렌더링 시 초기값만 사용하는 특성 때문입니다.

<Counter key={chosenCount} initialCount={chosenCount} />

반면, key를 설정하면 React는 chosenCount가 바뀔 때 이전 컴포넌트를 언마운트하고 새로 마운트합니다.
즉, 완전히 새로운 컴포넌트로 인식하게 됩니다.

참고: key는 props처럼 전달되지만, 자식 컴포넌트에서는 props.key로 접근할 수 없습니다.

이는 React 내부에서만 사용하는 식별자입니다.

상태 업데이트의 스케줄링 & 배칭

setState는 즉시 실행되지 않고, React가 업데이트 일정을 조정합니다 (비동기 처리).
따라서 상태를 설정한 직후 console.log로 출력하면, 이전 값이 출력되는 경우가 많습니다.

안전한 상태 업데이트 방식:

setCount(prev => prev + 1);

위와 같이 이전 상태를 기반으로 한 함수형 업데이트를 사용하면,
상태 업데이트가 여러 번 연달아 일어나도 정확하게 처리됩니다.

배칭(Batching)

여러 개의 상태 업데이트가 동시에 발생하면 React는 이를 하나의 렌더링으로 묶어 처리합니다.
이렇게 하면 불필요한 렌더링을 줄이고 성능을 최적화할 수 있습니다.

Million.js로 React 성능 최적화

Million은 React 앱의 렌더링 성능을 향상시켜주는 경량 라이브러리입니다.

npm install million

// vite.config.js
import MillionLint from "million/compiler";
import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";

export default defineConfig({
  plugins: [MillionLint.vite({ auto: true }), react()],
});

설정만으로 자동 성능 최적화를 적용할 수 있습니다.

마무리 정리

기능 목적 사용 시기

memo	불필요한 자식 렌더링 방지	props가 자주 바뀌지 않는 경우
useMemo()	복잡한 계산 결과 캐싱	무거운 연산이 있을 때
key	컴포넌트 구분 & 성능 최적화	리스트 렌더링, 상태 꼬임 방지
함수형 setState	상태 안정적 업데이트	여러 상태 업데이트가 동시에 일어날 때

도움이 되셨다면 ❤️ 좋아요와 댓글로 피드백 주세요!

궁금한 점이 있다면 언제든지 질문 환영입니다

지금까지 읽어주셔서 감사합니다!

[React] React로 퀴즈 앱 만들기 | 개발 회고

제가안난데여♪(´ε｀*) — Wed, 16 Apr 2025 22:43:45 +0900

이 프로젝트는 Udemy의 【한글자막】 React 완벽 가이드 2025 with React Router & Redux 강의 일부의 연습 프로젝트 입니다.

React Quiz App

이 프로젝트는 사용자가 문제을 읽고 시간 제한 내에 답안을 선택하는 퀴즈 앱 입니다. 주어진 문제를 다 풀면 결과 페이지를 제공합니다. 단순히 문제를 풀기만 하는 UI가 아닌, 상태 관리와 퀴즈 흐름에 초점을 맞춰 구현했습니다. 이를 통해 React에서 컴포넌트를 어떻게 효율적으로 설계하고, Context API와 상태 관리를 어떻게 활용할 수 있는지에 대한 경험을 쌓을 수 있었습니다.

특히, 각 문제의 상태(문제 풀이 중, 정답 확인, 시간 초과 등)를 어떻게 처리할지에 대한 고민과, 시간 제한 및 문제 흐름을 어떻게 자연스럽게 관리할 수 있을지에 대한 구현이 주요 포인트였습니다.

이 글에서는 퀴즈 앱의 주요 기능과 구현 과정, 그리고 퀴즈 앱을 만들면서 고민했던 부분들에 대해 차례대로 설명하려 합니다.

프로젝트 개요

배포 링크 & 깃허브

프로젝트 소개

컴포넌트: 앱을 작은 독립적인 부분으로 나눠 관리.
useState: 퀴즈 진행 상태(현재 문제, 선택한 답 등) 관리.
useEffect: 타이머와 상태 변화 관리.
useContext: 사용자 답안 상태를 전역적으로 관리.
useReducer: 복잡한 상태 관리 (답안 추가 등).
조건부 렌더링: 퀴즈 화면과 결과 화면 전환.

핵심 기능

퀴즈 문제 & 보기 랜덤 셔플
타이머 기반 자동 진행
사용자 답안 저장 및 요약
Context API 기반 상태 관리

️ 구현 과정 및 내부 로직

1️⃣ 전체적인 흐름

퀴즈 시작: 사용자가 앱을 시작하면, Quiz 컴포넌트가 렌더링되어 문제들이 섞인 상태로 표시됩니다.
문제 풀기: 각 문제는 제한 시간이 주어지며, 사용자는 보기를 선택하거나 Skip 버튼을 눌러 문제를 건너뛸 수 있습니다.
답안 제출: 사용자가 답을 선택하면, userAnswerContext를 통해 답안 상태가 저장되고, 타이머가 종료되면 자동으로 정답이 표시됩니다.
다음 문제로 이동: 정답을 확인한 후, Quiz 컴포넌트는 자동으로 다음 문제로 넘어가며, 마지막 문제까지 진행합니다.
결과 화면: 모든 문제를 끝내면 Summary 컴포넌트가 렌더링되어 정답, 오답, 건너뛴 문제 수와 비율을 표시하고, 각 문제에 대한 사용자 선택 및 결과를 출력합니다.
상태 관리: UserAnswerContext와 useReducer를 통해 사용자의 답안을 관리하고, 각 컴포넌트 간 상태를 공유합니다.

2️⃣ 구조

폴더 구조

  src
├──   assets
├──   components
│   ├──   Answers.jsx
│   ├──   Header.jsx
│   ├──   ProgressBar.jsx
│   ├──   Question.jsx
│   ├──   Quiz.jsx
│   └──   Summary.jsx
├──   constants
│   ├── ❓ nonsense_questions_ko.js
│   ├── ❓ questions.js
│   ├── ❓ questions_ko.js
│   └── ❓ stages.js
├──   store
│   └──   user-answer-context.jsx
├──   App.jsx
├──   index.css
└──   main.jsx

컴포넌트 구조

App
├── Header (상단 로고 + 타이틀)
│ 
├── UserAnswerContextProvider
│   ├── Quiz (퀴즈 진행 중일 때 렌더링)
│   │   ├── Question (질문 + ProgressBar)
│   │   │   └── ProgressBar (타이머 진행 바)
│   │   ├── Answers (선택지 버튼들)
│   │   └── Skip 버튼 영역
│   │
│   └── Summary (퀴즈 종료 후 결과 요약 화면)
│       └── 각 질문에 대한 결과 항목

3️⃣ 주요 컴포넌트 및 기능

1. App.jsx (메인 컴포넌트)

퀴즈 앱의 전체 흐름을 제어하는 루트 컴포넌트
viewMode 상태로 현재 화면을 관리
- "quiz" → Quiz 컴포넌트 렌더링
- "summary" → Summary 컴포넌트 렌더링

  // 현재 화면 모드를 상태로 관리 (퀴즈 화면 또는 결과 화면)
  const [viewMode, setViewMode] = useState("quiz");
  
  // 화면 모드를 변경하는 함수 (퀴즈 화면 -> 결과 화면)
  function handleViewModeChange(mode) {
    setViewMode(mode); // 새로운 화면 모드로 상태 업데이트
  }

  return (
    <>
		    ...
        {/* viewMode 상태에 따라 퀴즈 화면 또는 결과 화면을 렌더링 */}
        {viewMode === "quiz" && ( <Quiz quizzes={shuffledQuizzes} onQuizEnd={handleViewModeChange} /> )}
        { viewMode === "summary" && <Summary />  }
		    ...
    </>
  );

QUIZS 데이터에서 문제와 보기 순서를 lodash로 셔플하여 출제

// QUIZS에서 문제를 가져와서 순서를 섞고, 각 문제에 대한 답변 순서도 섞음
  const shuffledQuizzes = _.shuffle(QUIZS).map((quiz) => ({
    ...quiz,
    answers: _.shuffle(quiz.answers), // 답안 순서 셔플
    correctAnswer: quiz.answers[0], // 첫 번째 답안을 정답으로 설정
  }));

전역 상태 관리용 UserAnswerContextProvider로 감싸, 하위 컴포넌트에서 사용자 답변 데이터를 공유 및 추적

return (
  <><Header /> {/* 상단 고정 헤더 */}
    <UserAnswerContextProvider>
      {currentView}
    </UserAnswerContextProvider>
  </>
);

2. Quiz.jsx (퀴즈 진행 컴포넌트)

Quiz 컴포넌트는 퀴즈의 전체 흐름을 관리하는 중심 컴포넌트로, 하나의 문제에 대해 퀴즈 문제 표시 → 사용자 선택 확인 → 정답 공개라는 3단계 상태 전환 로직을 갖는다.
상태는 useState로 관리하며, 각각 다음과 같이 상태가 전환 되어진다.
QUIZ: 문제 풀이 단계
- 시간 만료 시: handleTimeOut → handleSkipClick 호출 → CORRECT 상태로 이동
- 사용자 선택 시: handleAnswerSelect → SELECTED 상태로 이동

function handleAnswerSelect(answer) {
  setSelectedAnswer(answer);
  setQuizStage(STAGES.SELECTED);
  addUserAnswer({ ... });
}

function handleSkipClick() {
  setQuizStage(STAGES.CORRECT);
  addUserAnswer({ result: "skipped", ... });
}

SELECTED: 사용자가 선택한 답안을 보여주는 단계
- 시간 만료 시: handleTimeOut → CORRECT 상태로 이동

**function handleTimeOut() {
  if (quizStage === STAGES.QUIZ) {
    handleSkipClick();
  } else if (quizStage === STAGES.SELECTED) {
    setQuizStage(STAGES.CORRECT);
  } else {
    handleNextQuestion();
  }
}**

CORRECT: 정답을 보여주는 단계
- 시간 만료 시: handleTimeOut → handleNextQuestion 호출 → 다음 문제로 이동, QUIZ 상태 이동

function handleNextQuestion() {
  if (currentQuizIndex >= quizzes.length - 1) {
    onQuizEnd("summary");
    return;
  }
  setSelectedAnswer("");
  setCurrentQuizIndex((prev) => prev + 1);
  setQuizStage(STAGES.QUIZ);
}

Question 컴포넌트에 key를 부여함으로써 상태가 바뀔 때마다 React가 컴포넌트를 새로 마운트하게 하여 타이머가 정상적으로 초기화되도록 설계

<Question
  key={`${currentQuizIndex}-${quizStage}`}
  question={quiz.text}
  quizStage={quizStage}
  onTimeOut={handleTimeOut}
/>

사용자의 선택한 답은 컨텍스트를 통해 관리하여 저장 및 추적.
Skip버튼을 통해 사용자가 문제를 건너뛰고 바로 정답을 확인할 수 있도록 기능을 추가 QUIZ 상태에서만 표시되도록 조건부 렌더링

{quizStage === STAGES.QUIZ && (
  <button type="button" onClick={handleSkipClick}>Skip</button>
)}

⏳ 3. ProgressBar.jsx (진행 바 컴포넌트)

ProgressBar는 퀴즈 상태에 따라 자동으로 제한 시간을 계산하고, 남은 시간을 10ms 단위로 실시간 표시하는 컴포넌트
퀴즈를 푸는 단계(QUIZ)에서는 10초, 선택 확인이나 정답 공개 단계에서는 1초의 시간이 주어지며, 해당 시간은 상태 변화마다 자동 설정
첫 번째 useEffect에서는 정해진 시간 후 자동 전환을 위한 setTimeout을 등록하고, 상태 변경이나 언마운트 시 이를 정리

useEffect(() => {
  const timer = setTimeout(() => {
    onTimeOut();
  }, time);

  return () => clearTimeout(timer); // 상태 변경 시 타이머 초기화
}, [time]);

두 번째 useEffect에서는 남은 시간을 10ms 단위로 감소시키는 인터벌을 설정하고, 퀴즈 상태가 바뀔 때마다 남은 시간을 다시 초기화하고 새 인터벌을 시작

useEffect(() => {
  setRemainingTimer(time); // 상태 전환 시 남은 시간 초기화

  const interval = setInterval(() => {
    setRemainingTimer((prevTime) => prevTime - 10);
  }, 10);

  return () => {
    clearInterval(interval); // 상태 변경 또는 언마운트 시 인터벌 정리
  };
}, [time]);

진행 바는 <progress> 태그로 구현되며, value와 max 속성으로 남은 시간의 진행률 표시
정답이 공개되는 단계에서는 answered 클래스를 조건부로 추가해 스타일을 바꾸어 시각적으로 상태 전환을 표시

<progress
  className={quizStage !== STAGES.QUIZ ? "answered" : ""}
  value={remainingTimer}
  max={time}
/>

4. Answers.jsx (선택지 목록 컴포넌트)

퀴즈에서 사용자가 선택한 답변과 정답을 시각적으로 구분하여 보여주는 컴포넌트.
현재 문제의 답변 리스트를 렌더링하고, 선택 이벤트 처리
quizStage에 따라 답변 버튼의 클래스를 동적으로 설정.
- STAGES.SELECTED: 사용자가 답을 선택한 상태에서 해당 답에 "selected" 클래스 추가.
- STAGES.CORRECT: 정답을 표시하는 단계에서 정답에는 "correct"(초록), 틀린 답에는 "wrong" (빨강) 클래스 추가.

function getClassName(answer) {
  if (quizStage === STAGES.SELECTED) {
    return answer === selectedAnswer ? "selected" : "";
  }

  if (quizStage === STAGES.CORRECT) {
    if (answer === correctAnswer) return "correct";
    if (answer === selectedAnswer && selectedAnswer !== correctAnswer)
      return "wrong";
  }

  return "";
}

quizStage가 "QUIZ"일 때만 선택이 가능하도록 disabled 설정.

<button
  className={getClassName(answer)} // 동적으로 스타일 클래스 지정
  disabled={quizStage !== STAGES.QUIZ} // 퀴즈 푸는 중에만 클릭 가능
  type="button"
  onClick={() => handleAnswerSelect(answer)} // 답안 선택 핸들러
>
  {answer}
</button>

5. Summary.jsx (요약 결과 화면 컴포넌트)

퀴즈가 끝나면 정답/오답/스킵 비율을 시각적으로 요약
userAnswer: 사용자 답안 배열을 UserAnswerContext에서 가져와서 퀴즈 결과를 처리.
문제 통계 계산:
- 총 문제 수, 정답 수, 오답 수, 건너뛴 문제 수 계산.
- 각 항목의 비율을 백분율로 계산하여 표시.

const correctAnswers = userAnswer.filter((answer) => answer.result === "correct").length;
const wrongAnswers = userAnswer.filter((answer) => answer.result === "wrong").length;
const skippedAnswers = userAnswer.filter((answer) => answer.result === "skipped").length;

const getPercentage = (count) => Math.round((count / totalQuestions) * 100);

사용자의 응답 결과를 하나씩 나열하며, 정답 여부와 선택한 항목을 강조 표시
- skipped된 문제는 "SKIPPED"로 표시, 선택된 답은 정답/오답에 따라 스타일링.
- context.answers와 questions 데이터를 매핑하여 렌더링

<ol>
  {userAnswer.map((answer, index) => {
    const { id, question, selectedAnswer, result } = answer;
    return (
      <li key={id}>
        <h3>{index + 1}</h3>
        <div className="question">{question}</div>
        {result === "skipped" ? (
          <p className="user-answer wrong">SKIPPED</p>
        ) : (
          <div className="answer">
            <p className={`user-answer ${result}`}>{selectedAnswer}</p>
          </div>
        )}
      </li>
    );
  })}
</ol>

6. user-answer-context.jsx (Context API + 상태관리)

사용자 답안을 전역 상태로 관리하고, 이를 다른 컴포넌트에서 공유할 수 있도록 하는 Context.
- Context: UserAnswerContext 생성.
- Reducer: useReducer 훅을 이용하여 상태 관리.
- Provider: UserAnswerContextProvider 컴포넌트로 자식 컴포넌트에 상태 및 함수를 제공.

왜 사용자 답안을 Context로 관리했을까?

초기에 Prop Drilling 없이 상태를 컴포넌트 내부에서 관리했지만,

Answer에서 업데이트한 사용자 답안을 Summary에서 사용해야 했음.

App에서 Quiz와 Summary를 조건부로 렌더링하고,

Answer → Quiz → App → Summary로 불필요한 props 전달이 이뤄질 수밖에 없는 구조였음.

이런 불필요한 **prop 전달(Prop Drilling)**을 피하고, 상태를 일관되게 접근하고 관리하기 위해 Context API를 도입함.

1. Context 생성:

사용자 답안을 저장하고 업데이트할 수 있는 Context를 생성.
userAnswer는 사용자 답안을 배열로 저장하며, 기본값은 빈 배열.
addUserAnswer는 답안을 추가하는 함수로 초기에는 빈 함수로 설정.

export const UserAnswerContext = createContext({
  userAnswer: [],
  addUserAnswer: () => {},
});

2. Reducer 정의:

userAnswerReducer는 사용자 답안을 관리하는 리듀서.
ADD_USER_ANSWER 액션이 발생하면 payload로 전달된 답안을 기존 상태에 추가하여 새로운 상태를 반환.

function userAnswerReducer(state, action) {
  switch (action.type) {
    case "ADD_USER_ANSWER":
      return [...state, action.payload];
    default:
      return state;
  }
}

3. Provider 정의

UserAnswerContextProvider는 이 Context를 제공하는 컴포넌트로, useReducer를 사용하여 상태(userAnswerState)와 상태 업데이트 함수(userAnswerDispatch)를 관리합니다. 이 컴포넌트는 자식 컴포넌트들에게 userAnswer와 addUserAnswer를 제공하며, 이를 통해 다른 컴포넌트에서 사용자 답안 상태를 조회하고 업데이트할 수 있습니다.

주요 단계:

useReducer: userAnswerState와 userAnswerDispatch를 관리.
addAnswer 함수: ADD_USER_ANSWER 액션을 디스패치하여 사용자가 선택한 답안을 상태에 추가.
UserAnswerContext.Provider: 상태와 함수를 자식 컴포넌트들에 전달.

export default function UserAnswerContextProvider({ children }) {
  // 상태 관리: useReducer로 상태(userAnswerState) 및 상태 업데이트(userAnswerDispatch) 처리
  const [userAnswerState, userAnswerDispatch] = useReducer(userAnswerReducer, []);

  // 사용자 답안을 추가하는 함수
  function addAnswer(answer) {
    userAnswerDispatch({ type: "ADD_USER_ANSWER", payload: answer });
  }

  // Context 값 제공
  const ctxValue = {
    userAnswer: userAnswerState,  // 현재 상태 값
    addUserAnswer: addAnswer,     // 답안 추가 함수
  };

  // 자식 컴포넌트들에 Context 값을 제공
  return <UserAnswerContext.Provider value={ctxValue}>{children}</UserAnswerContext.Provider>;
}

Context 사용 흐름 요약

사용자가 답안을 선택하면 addAnswer 함수로 답안을 디스패치 (userAnswerDispatch).
userAnswerReducer는 액션을 처리하고 새로운 배열을 반환
React가 상태 변경을 감지하고 컴포넌트를 리렌더링
UserAnswerContext.Provider를 통해 최신 상태를 자식 컴포넌트들에게 전달

결과 예시

️ 트러블슈팅

❌ 1. 퀴즈가 두 개씩 넘어가는 문제

문제 원인:

const timer = setTimeout(() => {
  onTimeExpired();
}, TIMER);

setTimeout이 컴포넌트 렌더링 때마다 중복 실행되어, onTimeExpired()가 두 번 이상 호출됨.
특히 Question 컴포넌트가 상태 변화로 인해 리렌더링될 경우 타이머가 새로 생성되며 중복 타이머 발생.

해결 방법:

useEffect를 사용해 타이머 생성을 제어하고, 클린업 함수로 이전 타이머 제거.

useEffect(() => {
  const timer = setTimeout(() => {
    onTimeExpired();
  }, TIMER);

  return () => clearTimeout(timer);
}, [onTimeExpired]);

이렇게 하면 Question이 리렌더링될 때 기존 타이머 제거 + 새 타이머 생성으로 중복 실행 방지

❌ 2. ProgressBar가 리셋되지 않는 문제

문제 원인:

quizStage가 "showSelectedAnswer" → "showCorrectAnswer"로 바뀌어도
ProgressBar의 time 값은 변경되지만 컴포넌트 자체는 리렌더링되지 않음.
React는 같은 컴포넌트에 prop만 바뀐다고 해서 완전히 리셋하지 않음.

해결 방법:

key props를 사용해 Question 컴포넌트를 강제로 재마운트.
key가 바뀌면 React는 해당 컴포넌트를 완전히 제거 후 다시 생성함.

<Question
  key={`${currentQuizIndex}-${quizStage}`} //   이게 핵심!
  question={quiz.text}
  time={time}
  isAnswered={quizStage !== "quiz"}
/>

✅ 이렇게 하면 quizStage가 바뀔 때마다 ProgressBar도 초기화되어 새로 시작됨.

❌ 3. 초기에는 질문만 셔플했지만 답안마다 셔플하려다 App 렌더링 시 셔플로 변경

문제 원인:

답안 목록을 출력할 때 답안을 매번 셔플하려고 했더니 렌더링 시마다 답 순서가 바뀌어 혼란 발생.

해결 방법:

앱이 최초 렌더링될 때 질문 + 답안을 모두 셔플해서 일관된 순서 유지.
lodash.shuffle을 사용하여 초기화 단계에서만 섞이도록 수정.

배운 점 & 느낀 점

useReducer와 Context API를 함께 활용해 복잡한 전역 상태를 구조적으로 관리하는 법을 익혔다.
상태 흐름을 설계하면서 전역 상태와 지역 상태의 경계에 대해 고민해볼 수 있었다.
타이머 기능을 구현하며 useEffect와 setInterval의 클린업 처리의 중요성을 체감했다.
조건부 렌더링과 분기 처리를 통해 앱의 흐름을 명확하게 제어할 수 있었다.
사용자 경험을 고려해 선택지 셔플, 시도 횟수 제한, 정답 확인 등 다양한 로직을 React로 유연하게 구현할 수 있었다.
전역 상태를 기반으로 Answer, Quiz, Summary 컴포넌트 간의 데이터를 주고받으며 prop drilling 없이 컴포넌트 간 소통하는 구조를 설계해볼 수 있었다.
작은 기능이라도 커스텀 훅으로 분리해서 재사용성과 가독성을 높이는 습관을 들이게 되었다.

[React] Side Effects / useEffect 훅 / useCallback 훅

제가안난데여♪(´ε｀*) — Fri, 11 Apr 2025 13:25:30 +0900

이 글은 Udemy의 【한글자막】 React 완벽 가이드 2025 with React Router & Redux 를 수강하고 정리한 내용입니다.

https://github.com/An0401na/React_Study/tree/main/11-Side-Effects-useEffec

React_Study/11-Side-Effects-useEffect at main · An0401na/React_Study

Contribute to An0401na/React_Study development by creating an account on GitHub.

github.com

Side Effect(부수 효과)란?

Side Effect(부수 효과)란 컴포넌트가 렌더링되는 과정과는 직접적인 관련이 없지만, 애플리케이션이 정상적으로 작동하기 위해 반드시 수행되어야 하는 작업을 의미합니다.

예를 들어, 사용자의 위치 정보를 가져오는 작업은 화면(UI)을 그리는 데 직접 영향을 주지는 않지만, 앱 기능에는 꼭 필요한 동작이죠. 이런 작업들이 바로 부수 효과입니다.

function App() {
  // 브라우저로부터 사용자 위치 정보를 가져오는 코드 (부수 효과)
  navigator.geolocation.getCurrentPosition((position) => {
    const sortedPlaces = sortPlacesByDistance(
      AVAILABLE_PLACES,
      position.coords.latitude,
      position.coords.longitude
    );
  });

  return (
    <><Modal ref={modal}>{/* ... */}</Modal>
      <header>{/* ... */}</header>
      <main>{/* ... */}</main>
    </>
  );
}

이 코드처럼 위치 정보를 가져오는 작업은 화면에 바로 영향을 주지 않기 때문에 Side Effect라고 할 수 있습니다.

Side Effect로 인해 발생할 수 있는 문제: 무한 루프

부수 효과는 꼭 필요하지만, 잘못 사용하면 무한 루프 같은 문제가 생길 수 있습니다.

아래 코드를 보면, 컴포넌트가 렌더링될 때마다 getCurrentPosition이 호출되고, 그 결과로 상태가 업데이트되면 다시 렌더링이 발생하게 됩니다. 이게 반복되면서 렌더링 → 위치 정보 요청 → 상태 업데이트 → 또 렌더링이라는 무한 루프가 생길 수 있습니다.

function App() {
  const [avaliablePlaces, setAvaliablePlaces] = useState();

  // 컴포넌트가 렌더링될 때마다 위치 정보 요청 → 상태 변경 → 다시 렌더링
  navigator.geolocation.getCurrentPosition((position) => {
    const sortedPlaces = sortPlacesByDistance(
      AVAILABLE_PLACES,
      position.coords.latitude,
      position.coords.longitude
    );
    setAvaliablePlaces(sortedPlaces);
  });

  return <>{/* ... */}</>;
}

export default App;

이런 상황은 사용자 경험에도 안 좋고, 성능에도 큰 영향을 미칩니다.

이럴 때 문제를 해결하기 위해 사용하는 것이 바로 useEffect입니다.

useEffect로 Side Effect를 안전하게 처리하기

useEffect란?

useEffect는 리액트가 화면을 그린 뒤(DOM 렌더링 이후) 특정 작업(부수 효과)을 실행할 수 있도록 도와주는 Hook입니다.

useEffect(() => {
  // 실행할 부수 효과 코드
}, [의존성 배열]);

첫 번째 인자: 실행할 함수 (부수 효과 코드)
두 번째 인자: 의존성 배열 — 이 안의 값이 변경될 때만 함수가 다시 실행됨
→ 빈 배열 []을 넣으면 컴포넌트가 최초 렌더링 될 때 한 번만 실행됨

✅ 예제1 : useEffect로 무한 루프 방지

function App() {
  const [avaliablePlaces, setAvaliablePlaces] = useState([]);

  // 컴포넌트가 처음 렌더링될 때만 위치 정보를 요청함
  useEffect(() => {
    navigator.geolocation.getCurrentPosition((position) => {
      const sortedPlaces = sortPlacesByDistance(
        AVAILABLE_PLACES,
        position.coords.latitude,
        position.coords.longitude
      );
      setAvaliablePlaces(sortedPlaces);
    });
  }, []); // 빈 배열: 의존성 없음 → 최초 렌더링 때만 실행

  return <>{/* ... */}</>;
}

export default App;

이처럼 useEffect를 사용하면 위치 정보 요청이 최초 한 번만 실행되기 때문에 불필요한 재렌더링이나 무한 루프 문제를 깔끔하게 방지할 수 있습니다.

✅ 예제2 : useEffect로 브라우저 API 싱크에 활용하기

useEffect를 활용하면 dialog의 showModal 메소드나 close 메소드와 같은 DOM API와 속성 값 또는 상태 값이 동기화 될 수 있도록 도움을 받을 수 있습니다.

function Modal({ open, children }) {
  const dialog = useRef();

  if (open) {
    dialog.current.showModal();
  } else {
    dialog.current.close();
  }

  return createPortal(
    <dialog className="modal" ref={dialog} open={open}>
      {children}
    </dialog>,
    document.getElementById("modal"),
  );
}

위 코드는 open이라는 상태가 true 일경우 dialog의 참조를 활용해 showModal 메소드를 호출하고 있습니다. 그러나 초기 상태에서는 참조와 jsx 코드의 dialog 연결되지 않은 상태에서 dialog.current.close()를 호출하게 되어 참조가 undefined 상태이기 때문에 호출에 실패하게 됩니다.

이를 해결하기 위해 useEffect를 사용하는 것이 좋습니다.

import { useEffect, useRef } from "react";

function Modal({ open, children }) {
  const dialog = useRef();

  // 컴포넌트 함수가 실행된 후에 부수효과 함수를 실행하여 dailog 참조가 undefined를 방지
  useEffect(() => {
    if (open) {
      dialog.current.showModal();
    } else {
      dialog.current.close();
    }
  }, [open]); // open이 변경될 때마다 실행

  return createPortal(
    <dialog className="modal" ref={dialog}>
      {children}
    </dialog>,
    document.getElementById("modal"),
  );
}

useEffect로 정의한 effect 함수는 컴포넌트 함수에 바로 이어 실행되어 집니다.

useEffect에 등록된 함수는 컴포넌트 함수보다 먼저, 혹은 같이 실행 되는 것이 아니라 컴포넌트가 렌더링된 후, 즉 화면이 실제로 그려진 뒤에 실행됩니다. 때문에 참조와 dialog간의 연결은 effect 함수가 실행될 시점에서 이미 만들어져있을 것입니다.

또한 의존성 배열에 open 참조를 추가하여 open 값이 변경 될때마다 effect 함수를 실행시켜 모달의 열림여부를 변경할 수 있게 됩니다.

✅ 예제3 : useEffect의 Cleanup 함수로 타이머 제어하기

useEffect는 부수 효과를 실행할 수 있을 뿐 아니라, 클린업(Cleanup) 함수를 통해 부수 효과를 정리하는 작업도 할 수 있습니다. 이 클린업 함수는 실행되는 시점은 아래와 같습니다.

컴포넌트가 화면에서 사라질 때(언마운트) 실행
다시 렌더링되기 전에 실행

이 개념을 타이머(setTimeout)와 함께 사용하는 예제를 살펴보겠습니다.

function DeleteConfirmation({ onConfirm, onCancel }) {
  console.log("Timer started");
  setTimeout(() => {
    onConfirm();
  }, 5000);

  return (
    <div>
      <button onClick={onCancel} className="button-text">
        No
      </button>
      <button onClick={onConfirm} className="button">
        Yes
      </button>
    </div>
  );
}

위 컴포넌트는 삭제 확인 모달에서 사용되는 컴포넌트로, 생성된 뒤 5초가 지나면 자동으로 onConfirm()을 호출합니다.

하지만 문제는 다음과 같습니다:

사용자가 No 버튼을 눌러 모달을 닫으면 이 컴포넌트는 사라지지만,
타이머는 계속 동작하기 때문에 5초 후 onConfirm()이 여전히 실행됩니다.

이렇게 되면 사용자가 취소했음에도 불구하고 삭제가 실행되는 원하지 않는 동작이 발생합니다.

이 문제를 해결하려면 컴포넌트가 사라질 때 타이머도 함께 정리해줘야 합니다. 이럴 때 useEffect의 클린업 함수가 유용하게 쓰입니다.

function DeleteConfirmation({ onConfirm, onCancel }) {
  useEffect(() => {
    console.log("Timer started");

    const timer = setTimeout(() => {
      onConfirm();
    }, 5000);

    // 클린업 함수: 컴포넌트가 사라지기 전에 실행되어 타이머 정리
    return () => {
      console.log("Timer cleared");
      clearTimeout(timer);
    };
  }, []); 

  return (
    <div>
      <button onClick={onCancel} className="button-text">
        No
      </button>
      <button onClick={onConfirm} className="button">
        Yes
      </button>
    </div>
  );
}

useEffect 안에서 setTimeout을 설정하고, 클린업 함수를 이용해 clearTimeout()으로 타이머를 정리하여 문제를 방지하였습니다.

이처럼 클린업 함수는 부수 효과로 인한 리소스 낭비나 잘못된 동작을 방지하는 데 꼭 필요합니다.

useCallback 훅으로 함수 재생성 문제 해결하기

앞 예제에서 useEffect 내부에서 onConfirm 함수를 사용하고 있었죠. 이럴 경우 onConfirm이 변경되면 effect가 다시 실행되기 때문에, 의존성 배열에 넣어주는 것이 일반적인 패턴입니다.

function DeleteConfirmation({ onConfirm, onCancel }) {
  useEffect(() => {
    console.log("Timer started");

    const timer = setTimeout(() => {
      onConfirm();
    }, 5000);

    // 클린업 함수: 컴포넌트가 사라지기 전에 실행되어 타이머 정리
    return () => {
      console.log("Timer cleared");
      clearTimeout(timer);
    };
  }, [ onConfirm ]); 

  return ();
}

예제에서처럼 onConfirm 함수 안에서 상태를 변경하게 되면, 이 함수는 컴포넌트가 리렌더링될 때마다 새로운 함수로 다시 생성됩니다.

그 결과, 리액트는 다음처럼 판단합니다:

“의존성 배열에 있는 값(onConfirm)이 바뀌었네? → 그럼 effect 함수를 다시 실행해야지!”

그런데 effect 함수 안에서 상태를 변경하게 되면, 그 상태 변경으로 인해 컴포넌트가 다시 리렌더링됩니다. 그러면 onConfirm 함수도 다시 생성되고, useEffect는 또다시 그 변화를 감지하고 다시 실행됩니다.

이 흐름을 정리하면 다음과 같습니다:

1. effect 실행 → 상태 변경
2. 상태 변경 → 리렌더링
3. 리렌더링 → onConfirm 새로 생성
4. onConfirm 변경 → effect 다시 실행
5. effect 실행 → 상태 변경 → ...

이런 문제를 해결하기 위해 우리는 useCallback 훅을 사용할 수 있습니다.

✅ 왜 이런 문제가 생기는 걸까?

리액트에서는 컴포넌트가 리렌더링될 때마다 컴포넌트 내부에 선언된 함수들도 새로 만들어집니다.

그 함수의 내용이 같더라도 주소값이 다르기 때문에 다른 함수로 간주됩니다.

예를 들어 아래 두 코드의 handleRemovePlace는 매 렌더링마다 새로 만들어져서 주소가 바뀌게 됩니다:

function App() {
  const handleRemovePlace = () => {
    // 상태 업데이트
  };
}

이렇게 되면 이 함수를 useEffect 의존성 배열에 넣었을 때 리렌더링마다 계속해서 effect가 실행되는 부작용이 생깁니다.

→ 바로 이런 문제를 useCallback이 해결해주는 것!

useCallback 란?

useCallback은 함수의 재생성을 방지해주는 React 훅입니다.

컴포넌트가 리렌더링되더라도, 훅 내부에 지정된 함수를 메모리로서 내부에 저장하기 때문에 의존성 배열에 있는 값들이 바뀌지 않으면 같은 함수(주소)를 재사용합니다.

const memoizedFn = useCallback(() => {
  // 여기에 재생성하지 않고 유지하고 싶은 함수 로직
}, [의존성]);

첫 번째 인자: 재사용하고 싶은 함수
두 번째 인자: 의존성 배열 — 이 안의 값이 변경될 때만 함수가 다시 생성됨
→ 빈 배열 []을 넣으면 컴포넌트가 최초 렌더링 될 때 한 번만 생성됨

✅ 예제: useCallback으로 무한 루프 방지하기

// App.jsx
import { useEffect, useRef, useState, useCallback } from "react";

function App() {
  const [modalIsOpen, setModalIsOpen] = useState(false);
  const selectedPlace = useRef(null);

  // useCallback으로 감싸서 함수가 리렌더링될 때마다 재생성되지 않도록 함
  const handleRemovePlace = useCallback(() => {
    console.log("Removing place..." + selectedPlace.current);
    setModalIsOpen(false);
  }, []);

  const handleStopRemovePlace = () => {
    setModalIsOpen(false);
  };

  return (
    <>
      <Modal open={modalIsOpen} onClose={handleStopRemovePlace}>
        <DeleteConfirmation
          onCancel={handleStopRemovePlace}
          onConfirm={handleRemovePlace}
        />
      </Modal>
    </>
  );
}

여기서 handleRemovePlace는 useCallback으로 감싸져 있기 때문에, App 컴포넌트가 다시 렌더링되더라도 주소가 바뀌지 않습니다.

→ 따라서 DeleteConfirmation 컴포넌트의 useEffect 안에서 onConfirm이 바뀌었다고 감지되지 않으므로 불필요한 재실행이나 무한 루프를 방지할 수 있게 되는 것입니다.

모든 부수 효과에 useEffect를 써야 할까?

❌ 꼭 그렇진 않습니다!

모든 Side Effect에 useEffect를 사용할 필요는 없습니다. 오히려 불필요하게 useEffect를 사용하면 코드가 복잡해지고 성능에도 안 좋을 수 있습니다.

❌ 불필요한 useEffect 예시 1.

예를 들어 아래처럼 사용자의 클릭 이벤트에 따라 실행되는 로직은 useEffect 없이도 전혀 문제가 없습니다.

  function handleSelectPlace(id) {
    setPickedPlaces((prevPickedPlaces) => {
      if (prevPickedPlaces.some((place) => place.id === id)) {
        return prevPickedPlaces;
      }
      const place = AVAILABLE_PLACES.find((place) => place.id === id);
      return [place, ...prevPickedPlaces];
    });

    // 로컬 스토리지에 저장된 id 목록을 가져옴, 없으면 빈 배열로 초기화
    const storedIds = JSON.parse(localStorage.getItem("selectedPlaces") || []);
    // 로컬 스토리지에 저장된 id 목록에 선택한 장소 id가 없으면 추가
    if (storedIds.indexOf(id) === -1) {
      // 로컬 스토리지에 선택한 장소 id를 추가
      localStorage.setItem(
        "selectedPlaces",
        JSON.stringify([id, ...storedIds]),
      );
    }
  }

이 코드는 사용자가 클릭했을 때만 실행됩니다.
무한 루프가 발생하지 않기 때문에 useEffect를 쓸 필요가 없습니다.
또, useEffect는 컴포넌트 최상단에서만 사용할 수 있기 때문에, if문이나 중첩 함수 내부에서는 사용할 수 없습니다.

결국 useEffect는 다음과 같은 상황에서만 사용하는 것이 적절합니다:

컴포넌트가 마운트된 이후에 실행되어야 하는 코드일 때
무한 루프를 방지할 필요가 있을 때

❌ 불필요한 useEffect 예시 2.

useEffect(() => {
  const storedIds = JSON.parse(localStorage.getItem("selectedPlaces")) || [];
  const storedPlaces = storedIds.map((id) =>
    AVAILABLE_PLACES.find((place) => place.id === id)
  );
  setPickedPlaces(storedPlaces);
}, []);

이 코드도 사실 useEffect가 필요하지 않습니다.

localStorage.getItem()은 동기적이고 즉시 완료되는 작업입니다.
콜백 함수도 없고, 브라우저에 요청을 보내는 것도 아닙니다.
따라서 렌더링 이후에 실행될 이유도 없습니다.

이런 경우는 아예 상태 초기화 코드로 빼서 처리하는 게 더 적절합니다:

const storedIds = JSON.parse(localStorage.getItem("selectedPlaces")) || [];
const storedPlaces = storedIds.map((id) =>
  AVAILABLE_PLACES.find((place) => place.id === id)
);

const [pickedPlaces, setPickedPlaces] = useState(storedPlaces);

이렇게 하면 불필요한 useEffect도 줄이고, 코드도 더 간결해집니다.

[React] Prop Drilling / Context API / Provider Pattern / userReducer

제가안난데여♪(´ε｀*) — Wed, 9 Apr 2025 18:09:28 +0900

이 글은 Udemy의 【한글자막】 React 완벽 가이드 2025 with React Router & Redux 를 수강하고 정리한 내용입니다.

https://github.com/An0401na/React_Study/tree/main/10-Advanced-State-Managemen-with-Context-useReducer

React_Study/10-Advanced-State-Managemen-with-Context-useReducer at main · An0401na/React_Study

Contribute to An0401na/React_Study development by creating an account on GitHub.

github.com

Prop Drilling

React에서 상태나 함수를 하위 컴포넌트로 넘기다 보면 어느새 중간 컴포넌트들이 prop을 '전달만' 하고 있는 걸 발견하게 됩니다. 이게 바로 Prop Drilling 문제 입니다. 예시를 들어서 설명해보겠습니다.

상품을 조회하고 장바구니에 담을 수 있는 간단한 쇼핑 앱을 만든다고 가정해봅시다.

이 앱의 최상위 컴포넌트인 App에는 두 가지 주요 영역이 있습니다.

Shop: 여러 개의 상품을 보여주는 영역
Header: 장바구니 정보를 보여주는 영역

Shop 컴포넌트는 각 상품을 나타내는 여러 개의 Product 컴포넌트로 구성되어 있고,

Header 컴포넌트는 장바구니 UI를 담당하는 CartModal, 그리고 장바구니에 담긴 상품 리스트를 보여주는 Cart 컴포넌트로 구성됩니다.

상품을 장바구니에 담기 위해 필요한 함수인 onUpdateCart는 App 컴포넌트에 정의되어 있고,

이 함수는 최종적으로 Product에서 사용되지만, App → Shop → Product를 거쳐야 전달됩니다.

또한 cart 상태 역시 App → Header → CartModal → Cart 순으로 전파되어야 합니다.

이처럼 실제로 prop을 사용하지 않는 중간 컴포넌트들까지 prop을 전달해야 하는 구조가 만들어지고,

컴포넌트가 많아질수록 전달 경로는 복잡해지며 가독성과 유지보수성이 떨어지게 됩니다.

이것이 바로 Prop Drilling입니다.

Component Composition(컴포넌트 합성)으로 Prop Drilling 줄이기

위와 같은 Prop Drilling 문제는 컴포넌트 합성(Component Composition)을 통해 어느 정도 완화할 수 있습니다.

Before

// App.jsx
<Shop onAddItemToCart={handleAddItemToCart} />

// Shop.jsx
export default function Shop({ onAddItemToCart }) {
  return (
    <ul>
      {DUMMY_PRODUCTS.map((product) => (
        <Product {...product} onAddToCart={onAddItemToCart} />
      ))}
    </ul>
  );
}

이 경우 onAddItemToCart는 실제로는 Product 컴포넌트에서 사용하는 함수인데, Shop이 그저 전달만 하고 있었습니다.

✅ After (컴포넌트 합성 활용)

// App.jsx
<Shop>
  {DUMMY_PRODUCTS.map((product) => (
    <Product {...product} onAddToCart={handleAddItemToCart} />
  ))}
</Shop>

// Shop.jsx
export default function Shop({ children }) {
  return <ul>{children}</ul>;
}

이제 Shop은 children을 렌더링하는 단순한 래퍼 역할만 하며, Product에서 필요한 prop을 직접 받을 수 있게 되어 불필요한 prop 전달을 줄이며 Prop Drilling 문제를 해결할 수 있습니다.

그러나 위 해결 방법으로 모든 컴포넌트 층에 사용하기는 적합하지 않습니다.

그 이유는 모든 컴포넌트에서 이 방법을 사용해 문제를 해결한다면 결국 모든 컴포넌트가 앱 컴포넌트에 포함될 것이고 나머지 컴포넌트는 감싸는 래퍼 용도로만 사용될 것이기 때문입니다.

이 문제를 다시 해결하기 위해서 아래에서 Context API에 대해 설명하겠습니다.

Context API

Context는 React 앱 전체에 전역 상태를 공유할 수 있도록 도와주는 기능입니다. 간단히 말해, 중간 컴포넌트들을 불필요한 prop 전달을 거치지 않고도 필요한 컴포넌트에서 직접 데이터에 접근할 수 있게 해줍니다. 이를 통해 Prop Drilling 문제를 효과적으로 해결할 수 있습니다.

전과 같은 상황에서, 더 이상 onUpdateCart 함수나 Cart 상태를 props를 통해 하나하나 전달할 필요가 없습니다. Shop, Product, Header, CardModal, Cart 등 하위 컴포넌트 모두가 Cart Context에 접근하여 장바구니 상태를 읽거나 업데이트 할 수 있습니다.

Context를 사용하기 위해선 보통 3가지 단계로 구성됩니다:

1. Context 생성

import { createContext } from 'react';

export const CartContext = createContext({
  items: [],
});

createContext()를 사용해 Context를 생성합니다.
여기서 지정한 값은 기본값이며, Provider 없이 Context를 사용할 경우에만 사용됩니다.
즉, 실질적인 데이터는 다음 단계인 Provider에서 제공합니다.

2. State 연결 & Provider로 값 제공

Context를 사용하고자 하는 컴포넌트들을 Provider로 감싸고, useState로 관리되는 실제 상태 값을 value로 전달합니다. 예를 들어, 장바구니 데이터를 상태로 관리하고자 할 때 다음과 같이 useState를 사용해 상태를 정의할 수 있습니다.

const [shoppingCart, setShoppingCart] = useState({
  items: [],
});

이 상태를 CartContext.Provider의 value로 전달하면, 하위 컴포넌트들은 Context를 통해 이 데이터를 사용할 수 있게 됩니다.

<CartContext.Provider value={shoppingCart}>
  <Header />
  <Shop>
    <Product {...product} onAddToCart={handleAddItemToCart} />
  </Shop>
</CartContext.Provider>

이렇게 하면 더 이상 shoppingCart를 props로 직접 전달하지 않아도, CartContext에 연결된 모든 컴포넌트에서 장바구니 상태에 접근할 수 있습니다.
useContext(CartContext)를 사용하는 모든 컴포넌트는 이 value 값에 접근할 수 있습니다.

참고로, createContext() 함수에서 설정하는 초기값은 Provider 없이 Context를 사용할 경우에만 사용됩니다. 실질적으로 하위 컴포넌트에 전달되는 값은 value={shoppingCart}에서 지정한 값입니다. 또한 초기값을 설정할 경우 자동완성에 도움을 받을 수 있다.

React 19 이상에서는 .Provider를 생략할 수 있습니다! Context 객체를 바로 JSX 태그처럼 사용할 수 있습니다.

<CartContext value={shoppingCart}>
  <Header />
  <Shop>
    <Product {...product} onAddToCart={handleAddItemToCart} />
  </Shop>
</CartContext>

3. useContext로 값 사용

하위 컴포넌트에서는 useContext(CartContext)를 사용하여 값에 직접 접근할 수 있습니다.

import { useContext } from "react";
import { CartContext } from "../store/shopping-cart-context.jsx";

export default function Cart() {
  const cartCtx = useContext(CartContext);

  return (
    <div id="cart">
      {cartCtx.items.length === 0 && <p>No items in cart!</p>}
      {cartCtx.items.length > 0 && (/* 생략 */)}
    </div>
  );
}

React 19에서는 use() 훅도 사용할 수 있습니다.

React 19에서는 새로운 use() 훅을 통해 조건문 안에서도 Context 값을 사용할 수 있습니다.

import { use } from 'react';
import { CartContext } from "../store/shopping-cart-context.jsx";

export default function Cart() {
  if (true) {
    const cartCtx = use(CartContext);
    // 조건 안에서도 훅 사용 가능!
  }

  return (
    <div id="cart">
      {/* 렌더링 */}
    </div>
  );
}

useContext()는 컴포넌트 최상위 레벨에서만 사용 가능하지만,
use() 훅은 if문, 반복문 등 어느 곳에서든 자유롭게 사용할 수 있는 장점이 있습니다.

Context는 단순한 값뿐만 아니라, 상태와 함께 동작 함수도 함께 전달할 수 있습니다.

const ctxValue = {
  items: shoppingCart.items,
  addItemToCart: handleAddItemToCart, //함수 추가
};

return (
  <CartContext.Provider value={ctxValue}>
    {/* 컴포넌트들 */}
  </CartContext.Provider>
);

하위 컴포넌트에서는 이렇게 사용합니다:

import { useContext } from "react";
import {CartContext} from "./store/shopping-cart-context.jsx";

export default function Product({ ...prop }) {
    const { addItemToCart } = useContext(CartContext);
    return (
        <button onClick={() => addItemToCart(id)}>Add to Cart</button>
    );
}

props 없이도 함수 호출이 가능하니 코드가 훨씬 깔끔해집니다.

컨텍스트 값이 바뀌면 컴포넌트가 재실행 됩니다.

useContext()로 값을 사용하고 있는 컴포넌트는, Context 값이 변경되면 React에 의해 자동으로 다시 실행됩니다. Context 값을 사용 중인 모든 컴포넌트가 자동으로 다시 렌더링됩니다.

이는 상태(state)나 props와 마찬가지로, 변경된 데이터를 기반으로 최신 UI를 보여주기 위한 동작입니다.

React에서 Context를 사용하는 더 깔끔한 방법: Context Provider를 별도 컴포넌트로 분리하기

Before

shopping-cart-context.jsx

export const CartContext = createContext({
  items: [],
  addItemToCart: () => {},
  updateItemQuantity: () => {},
});

App.jsx

import { useState } from "react";
import { CartContext } from "./store/shopping-cart-context";
import { DUMMY_PRODUCTS } from "./dummy-products";
import Header from "./components/Header";
import Shop from "./components/Shop";

function App() {
  const [shoppingCart, setShoppingCart] = useState({ items: [] });

  function handleAddItemToCart(id) {
    // 로직 생략
  }

  function handleUpdateCartItemQuantity(productId, amount) {
    // 로직 생략
  }

  const ctxValue = {
    items: shoppingCart.items,
    addItemToCart: handleAddItemToCart,
    updateItemQuantity: handleUpdateCartItemQuantity,
  };

  return (
    <CartContext.Provider value={ctxValue}>
      <Header />
      <Shop products={DUMMY_PRODUCTS} />
    </CartContext.Provider>
  );
}

export default App;

위와 같이 CartContext를 따로 파일을 분리해두었지만, 정작 아이템을 추가하거나 수량을 변경하는 상태 관리 코드는 모두 App.jsx 내부에 존재합니다.

이 구조는 간단한 앱에서는 문제가 없지만, 여러 개의 Context가 필요한 복잡한 앱에서는 문제가 됩니다.

예를 들어 Cart 외에 User, Theme, Auth 등 다른 Context가 추가되면, 각각의 상태 관리 함수들이 모두 App.jsx에 쌓이게 되죠. 결과적으로 App 컴포넌트는 상태 관리 코드의 집합소가 되고, 이는 유지보수에 취약하며, 컴포넌트 역할 분리 원칙에도 어긋나게 됩니다.

✅ After: CartContextProvider로 상태 관리까지 분리

CartContext만이 아니라, 상태와 그에 관련된 모든 로직을 별도의 Provider 컴포넌트로 추출할 수 있습니다.

이제 CartContextProvider를 만들고, 그 안에서 상태 관리와 Context 제공을 함께 처리합니다.

shopping-cart-context.jsx

import { createContext, useState } from "react";
import { DUMMY_PRODUCTS } from "../dummy-products.js";

export const CartContext = createContext({
  items: [],
  addItemToCart: () => {},
  updateItemQuantity: () => {},
});

export default function CartContextProvider({ children }) {
  const [shoppingCart, setShoppingCart] = useState({ items: [] });

  function handleAddItemToCart(id) {
    // 로직 생략
  }

  function handleUpdateCartItemQuantity(productId, amount) {
    // 로직 생략
  }

  const ctxValue = {
    items: shoppingCart.items,
    addItemToCart: handleAddItemToCart,
    updateItemQuantity: handleUpdateCartItemQuantity,
  };

  return (
    <CartContext.Provider value={ctxValue}>
      {children}
    </CartContext.Provider>
  );
}

App.jsx

import CartContextProvider from "./store/shopping-cart-context";

function App() {
  return (
    <CartContextProvider>
      <Header />
      <Shop />
    </CartContextProvider>
  );
}

여기서 핵심은 children prop을 활용하여 CartContextProvider가 Context를 사용해야 하는 모든 컴포넌트를 감싸도록 만든 점입니다. 상태 관리와 핸들러 로직은 모두 CartContextProvider 안으로 옮겨졌고, App 컴포넌트는 필요한 컴포넌트만 렌더링하는 역할만 하게 됩니다. App 컴포넌트는 View 계층만 담당하는 단순한 구조로 바뀌었습니다.

useReducer 란?

useReducer는 상태(state)와 그 상태를 어떻게 바꿀지 정해주는 로직(reducer 함수)을 관리하는 React의 내장 훅입니다.

useState와의 차이점은?

구분	useState	useReducer
사용 시기	단순한 상태 관리	상태가 복잡하거나, 여러 조건에 따라 바뀔 때
상태 타입	보통 하나의 값 (예: 숫자, 문자열)	주로 객체로 관리
상태 변경 방식	직접 setState 호출	dispatch로 액션 전달 후 reducer에서 처리
예시	setCount(count + 1)	dispatch({ type: 'INCREMENT' })

Before: useState로 상태 관리

기존에는 useState를 사용해서 장바구니 상태를 관리했었습니다. 이렇게 되면 상태 변경 로직이 여러 함수에 나누어져 있고 로직이 복잡해질수록 setState로 관리하는 코드가 길어지게 됩니다.

const [shoppingCart, setShoppingCart] = useState({ items: [] });

function handleAddItemToCart(id) {
  // 아이템 추가 로직이 여기
}

function handleUpdateCartItemQuantity(productId, amount) {
  // 수량 업데이트 로직이 또 여기
}

이렇게 되면 상태를 바꾸는 로직이 여러 함수에 흩어져 있고, 기능이 많아질수록 setState가 점점 복잡하고 길어집니다.

✅ After: useReducer 로 전환

1. useReducer 생성

const [shoppingCartState, shoppingCartDispatch] = useReducer(
  shoppingCartReducer,   // 상태를 어떻게 바꿀지 정의한 reducer 함수
  { items: [] }          // 초기 상태
);

shoppingCartState: 현재 상태
shoppingCartDispatch: 액션을 발생시키는 함수
shoppingCartReducer: 상태를 업데이트하는 함수

2. Reducer 함수 만들기

function shoppingCartReducer(state, action) {
  if (action.type === "ADD_ITEM") {
    // 아이템 추가 로직
    return { // 업데이트 된 상태 반환
      ...state,
      items: updatedItems,
    };
  }

  if (action.type === "UPDATE_ITEM") {
    // 수량 업데이트 로직
    return { // 업데이트 된 상태 반환
      ...state,
      items: updatedItems,
    };
  }

  return state; // 기본은 이전 상태 그대로 반환
}

state: snapshot으로 찍은 현재 상태 객체 (ex. { items: [...] })
action: 상태를 어떻게 바꿀지를 담은 객체 (예: { type: 'ADD_ITEM', payload: 1 })

우리가 상태 업데이트를 위해 써야 하는 코드는 이전보다 조금 길어질 수 있습니다.

하지만 중요한 차이는 그 로직이 React 컴포넌트 바깥, 리듀서 함수 안에 모여있다는 점이에요.

그리고 useReducer를 사용할 때는 상태를 직접 다루는 특별한 setState 함수를 기억하지 않아도 됩니다.

그저 dispatch로 "이런 행동을 하겠다!"라고 의도(action)만 전달하면,

React가 자동으로 가장 최신 상태의 스냅샷을 reducer에 전달해줍니다.

즉, 이전 상태 참조 문제 없이 안정적으로 상태를 변경할 수 있죠!

3. Reducer 함수 사용

function handleAddItemToCart(id) {
  shoppingCartDispatch({ type: "ADD_ITEM", payload: id });
}

function handleUpdateCartItemQuantity(productId, amount) {
  shoppingCartDispatch({
    type: "UPDATE_ITEM",
    payload: { productId, amount },
  });
}

이렇게 하면 App이나 Context Provider 컴포넌트는 dispatch만 호출하면 되고,

실제 상태 업데이트 로직은 모두 reducer 안에서 깔끔하게 처리됩니다.

useReducer로 상태가 바뀌는 흐름, 어떻게 작동할까?

우리가 흔히 useState로 상태를 관리할 때는 상태를 바꾸고자 할 때 setState를 직접 호출하죠.

그런데 useReducer를 쓰면 그 흐름이 달라집니다. 대신 훨씬 더 구조적이고 예측 가능한 방식으로 동작합니다.

shoppingCartDispatch({ type: "ADD_ITEM", payload: itemId });

이렇게 dispatch 함수를 호출하면 무슨 일이 일어날까요?

dispatch()가 액션을 발생시킴
- 위 예시에서는 "ADD_ITEM"이라는 행동의 의도(type)와, 어떤 아이템을 추가할지에 대한 정보(payload)를 보냈어요.
리듀서 함수가 호출됨
- useReducer는 이 dispatch를 받자마자, 우리가 정의해둔 shoppingCartReducer() 함수에 현재 상태(state)와 보낸 action을 넘겨줘요.
- 이 리듀서 함수는 “어떤 액션을 어떻게 처리할지”에 대한 규칙을 정해둔 곳이죠.
```
function shoppingCartReducer(state, action) {
  if (action.type === "ADD_ITEM") {
    // 새로운 상태 계산
    return {
      ...state,
      items: [...state.items, action.payload],
    };
  }
  return state; // 기본은 상태 그대로 반환
}
```
리듀서에서 반환한 새 상태로 업데이트
- 리듀서 함수는 바뀐 상태(예: items가 추가된 배열)를 새로운 객체로 만들어 반환합니다.
- useReducer는 이 새 상태를 shoppingCartState에 저장합니다.
상태를 제공하는 컨텍스트의 value가 변경됨
- 예를 들어 ShoppingCartContext.Provider의 value={{ shoppingCartState, shoppingCartDispatch }}가 있었다면, 이 중 shoppingCartState가 바뀌면서 전체 value 객체가 새로 생성됩니다.
그 컨텍스트를 구독 중인 컴포넌트들이 리렌더링됨
- useContext(ShoppingCartContext)로 해당 값을 쓰고 있는 컴포넌트들이 자동으로 리렌더링되며, 최신 shoppingCartState 값을 받아 UI를 업데이트해요.

왜 이 흐름이 좋을까?

상태 변경 로직이 하나의 리듀서 함수 안에 깔끔하게 정리됨
복잡한 상태도 다양한 액션을 통해 관리할 수 있음
상태 업데이트가 항상 이전 상태를 기반으로 안전하게 처리됨
컨텍스트와 함께 쓰면 앱 전체에서 상태를 예측 가능하게 공유할 수 있음

IntelliJ에서 React prettier 설정

제가안난데여♪(´ε｀*) — Tue, 8 Apr 2025 18:13:03 +0900

BackEnd 공부를 하다가 최근 React 공부를 시작하게 되어 IntelliJ에서 React 환경을 구축하였다.

코딩하는 과정에서 저장시 코드 정렬이 되지 않아 Prettier 플러그인 재설치 하였으나 그래도 안되더라 …

아래 명령어를 사용해 해당 프로젝트에 프리티어를 설치한다.

npm i --save-dev prettier

그 다음 File > Setting > Languages & Frameworks > JavaScript > Prettier 들어간다. Automatic Prettier configuration 체크 후 Run on Save 까지 체크하고 적용하면

저장 시에 코드가 자동 정렬된다!

만약 이렇게 해도 적용이 안된다면 Manual Prettier configuration을 선택하여 Prettier package를 찾아서 선택해주자.

[React] React 완벽 가이드 - React로 프로젝트 관리 앱 만들기 | 개발 회고

제가안난데여♪(´ε｀*) — Tue, 8 Apr 2025 17:51:47 +0900

Project Manage

React 기반 프로젝트 관리 애플리케이션

프로젝트 개요

이 프로젝트는 Udemy의 【한글자막】 React 완벽 가이드 2025 with React Router & Redux 강의 일부의 연습 프로젝트 입니다.

프로젝트 소개

이 프로젝트는 사용자가 여러 프로젝트를 생성하고, 각 프로젝트에 대한 작업(Task)을 추가하고 관리할 수 있는 프로젝트 관리 애플리케이션입니다. 각 프로젝트에는 제목, 설명, 마감일을 설정할 수 있고, 작업(Task)을 추가하여 관리할 수 있습니다. 또한, 사이드바를 통해 프로젝트를 선택하고 선택한 프로젝트의 세부 정보 확인, 작업 입력 및 관리, 중복 방지, 모달 경고 등의 기능이 포함되어 있습니다. 프로젝트가 선택되지 않았을 때는 적절한 메시지가 화면에 표시됩니다.

React: 컴포넌트 기반 UI 개발
useState: 상태 관리
useRef: 비동기적인 상태 변화 없이 DOM을 직접 참조

기능 요약

✅ 프로젝트 생성	제목, 설명, 마감일 입력 필드가 있음
❌ 중복 방지	동일한 프로젝트 제목을 가진 항목은 생성 불가
⚠️ 유효성 검사	입력 필드가 비어 있으면 경고 모달 표시
작업(Task) 추가	각 프로젝트에 작업을 개별적으로 추가 가능
️ 작업(Task) 삭제	각 작업 삭제 가능
프로젝트 삭제	현재 보고 있는 프로젝트를 삭제
선택 안 됨	프로젝트가 선택되지 않았을 때 별도 안내 UI 표시

️ 구현 과정 및 내부 로직

github repo

1️⃣ 전체적인 흐름

사용자가 + Add Project 버튼을 클릭하면 CreateProject 컴포넌트가 렌더링되어 제목, 설명, 마감일을 입력받습니다.
프로젝트가 생성되면 사이드바(SideBar)에 추가되고, 클릭 시 해당 프로젝트가 선택됩니다.
선택된 프로젝트의 세부 정보는 ProjectDetail에서 확인할 수 있으며, 작업(Task)을 추가/삭제할 수 있습니다.
새로운 작업은 ProjectTask 컴포넌트를 통해 입력받아 addTaskFromProject 함수로 프로젝트에 추가됩니다.
각 작업 옆의 Clear 버튼을 누르면 handleClearTaskToProject 함수가 호출되어 해당 작업을 삭제합니다.
아무 프로젝트도 선택되지 않은 상태에서는 NoProjectSelected 컴포넌트가 표시됩니다.
모든 로직은 useProjects 커스텀 훅을 통해 상태와 함께 관리됩니다.

2️⃣ 폴더 구조

src/
│
├── assets/                  # 이미지 등 정적 자산
│   └── no-projects.png
│
├── components/              # UI 컴포넌트 모음
│   ├── CreateProject.jsx         # 프로젝트 생성 폼
│   ├── CreateProjectTask.jsx     # 작업(Task) 입력 UI
│   ├── Input.jsx                 # 공통 입력 필드 컴포넌트
│   ├── Modal.jsx                 # 모달 컴포넌트
│   ├── NoProjectSelected.jsx     # 프로젝트 선택되지 않았을 때 UI
│   ├── ProjectDetail.jsx         # 프로젝트 상세 정보 및 Task 관리
│   ├── ProjectTask.jsx           # 작업(Task) 섹션 컨테이너
│   ├── ProjectTaskList.jsx       # 작업(Task) 리스트
│   └── SideBar.jsx               # 프로젝트 목록 및 선택
│
├── hooks/
│   └── useProjects.js        # 상태 및 로직 관리 커스텀 훅
│
├── App.jsx                   # 전체 앱 UI 구성
├── index.jsx                 
└── index.css

3️⃣ 주요 컴포넌트 및 기능

1. App.jsx (메인 컴포넌트)

모든 상태와 로직은 useProjects 커스텀 훅에서 관리
현재 상태에 따라 렌더링할 컴포넌트를 결정하는 currentView 변수를 사용해 동적으로 UI를 전환 :
- 프로젝트 생성 중: CreateProject
- 프로젝트 선택됨: ProjectDetail
- 아무 프로젝트도 선택되지 않음: NoProjectSelected

let currentView;

if (isCreatingProject) {
  currentView = (
    <CreateProject
      onClickSaveProject={saveProject}
      onClickCancleProject={cancleProject}
    />
  );
} else if (selectedProject) {
  currentView = (
    <ProjectDetail
      project={selectedProject}
      onClickDeleteProject={deleteProject}
      onClickAddTask={addTaskFromProject}
      onClickClearTask={handleClearTaskToProject}
    />
  );
} else {
  currentView = (
    <NoProjectSelected onClickCreatingProject={startCreatingProject} />
  );
}

최종적으로 SideBar 컴포넌트와 함께 상태에 맞는 메인 뷰를 렌더링

return (
  <main className="h-screen my-8 flex gap-8">
    <SideBarprojects={projects}
      selectedProject={selectedProject}
      onClickSelectedProject={selectProject}
      onClickCreatingProject={startCreatingProject}
    />
    {currentView}
  </main>
);

️ 2. SideBar.jsx (사이드바 컴포넌트)

현재 등록된 프로젝트 목록을 표시하고 선택 가능
선택된 프로젝트는 강조 표시됨
+ Add Project 버튼으로 프로젝트 생성 뷰 진입 가능

<button onClick={onClickCreatingProject}>+ Add Project</button>
{projects.map(project => (
  <button
    key={project.id}
    className={project.id === selectedProject?.id ? 'active' : ''}
    onClick={() => onClickSelectedProject(project.id)}
  >
    {project.title}
  </button>
))}

️ 3. CreateProject.jsx (프로젝트 생성 컴포넌트)

사용자로부터 프로젝트 제목, 설명, 마감일을 입력받아, App.jsx로 전달하는 역할을
useRef를 통해 입력 필드의 값을 관리하여 불필요한 리렌더링 없이 데이터를 추출
유효성 검사와 중복 검사 기능이 내장되어 있으며, 오류 발생 시 Modal 컴포넌트를 통해 사용자에게 피드백을 제공
입력이 유효한 경우 부모로부터 전달받은 onClickSaveProject(title, description, dueDate) 함수를 호출해 프로젝트를 저장
UI 구성은 Input 컴포넌트를 재사용하여 일관성 있는 입력 필드를 구현, 버튼 클릭 시 취소 또는 저장 이벤트 트리거

// 입력값 추적용 useRef
const projectTitleRef = useRef("");
const projectDescriptionRef = useRef("");
const projectDueDateRef = useRef("");

// 저장 버튼 클릭 시 입력값 유효성 검사 및 저장 시도
function handleSaveClick() {
  const title = projectTitleRef.current.value;
  const description = projectDescriptionRef.current.value;
  const dueDate = projectDueDateRef.current.value;

  if (title.trim() === "" || description.trim() === "" || dueDate.trim() === "") {
    invalidCaseModal.current.open(); // 빈 입력값이 있을 경우 경고 모달
    return;
  }

  const isSaved = onClickSaveProject(title, description, dueDate);
  if (!isSaved) {
    duplicatedCaseModal.current.open(); // 중복된 타이틀인 경우 경고 모달
    return;
  }
}

4. Modal.jsx (모달 컴포넌트)

사용자 피드백을 위한 모달 창을 생성하는 컴포넌트
React Portal을 사용하여 모달을 루트 DOM 외부에 렌더링하고, useImperativeHandle + useRef 조합으로 외부 컴포넌트에서 모달을 제어
부모 컴포넌트에서는 ref.current.open()로 모달 호출

useImperativeHandle(ref, () => {
  return {
    open() {
      dialog.current.showModal(); // HTML <dialog> API를 통해 모달 열기
    },
  };
});

createPortal을 통해 #modal-root 요소에 모달을 렌더링하여, 구조적으로 앱의 나머지 UI와 분리되면서도 전역적으로 표시
buttonCaption으로 버튼 라벨을 커스터마이징 가능

<dialog ref={dialog}>
  {children} // 모달 내부 컨텐츠
  <form method="dialog">
    <button>{buttonCaption}</button> 
  </form>
</dialog>

5. ProjectDetail.jsx (프로젝트 상세 보기)

선택된 프로젝트의 제목, 설명, 마감일, 작업 목록을 보여주는 컴포넌트입
작업은 하위 컴포넌트인 ProjectTask를 통해 추가 및 삭제
마감일은 MM/DD/YYYY 형식으로 포맷팅
ProjectTask에 작업 배열과 함께 작업 추가/삭제 핸들러를 전달

// 작업 추가 핸들러
function handleAddTaskClick(newTask) {
  if (newTask.trim() !== "") {
    onClickAddTask(project, newTask); // 부모로 프로젝트와 작업 텍스트 전달
  }
}

// 작업 삭제 핸들러
function handleClearTaskClick(index) {
  onClickClearTask(project, index); // 삭제할 작업의 인덱스를 기준으로 처리
}

6. ProjectTask.jsx (프로젝트 작업 컴포넌트)

선택된 프로젝트의 작업(Task) 목록을 관리하는 중간 컴포넌트
하위에 CreateProjectTask(입력창 + 추가 버튼)와 ProjectTaskList(작업 목록 출력)를 포함
입력된 작업은 유효성 검사를 거쳐 상위 컴포넌트로 전달
작업이 없을 경우 사용자에게 안내 메시지를 출력.

<h2>Tasks</h2> // 섹션 제목

<CreateProjectTask handleAddTaskClick={handleAddTaskClick} />

{tasks.length === 0 ? (
  <p>This Project does not have any task yet.</p>
) : (
  <ProjectTaskList tasks={tasks} onClickClear={onClickClear} />
)}

⚠️ 7. NoProjectSelected.jsx (프로젝트 선택되지 않음 컴포넌트)

사용자가 프로젝트를 선택하지 않았을 경우에 보여주는 메시지를 처리하는 컴포넌트
프로젝트 선택이 없을 때, 해당 컴포넌트가 화면에 표시됩니다.

function NoProjectSelected({ onClickCreatingProject }) {
  return (
    <div>
      <h2>No project selected</h2>
      <p>Please select a project or create a new one.</p>
      <button onClick={onClickCreatingProject}>Create New Project</button>
    </div>
  );
}

결과 화면

️ 트러블슈팅

❌ 1. 프로젝트 저장 버튼 클릭 시 프로젝트가 추가되지 않는 문제

문제 원인: 잘못된 이벤트 처리 방식

<button
  className="..."
  onClick={() =>
    onClickSaveProject(
      projectTitle.current.value,
      projectDescription.current.value,
      projectDueDate.current.value,
    )
  }
>
  Save
</button>

문제 설명:

onClick 이벤트 핸들러 내부에서 바로 onClickSaveProject()를 실행하고 있음.
이 버튼이 <form> 내부에 있기 때문에, 버튼 클릭 시 **기본적으로 form 제출 이벤트(submit)**가 발생함.
그러나 onClick 내부에서 이를 preventDefault() 하지 않고 즉시 실행하면서, 페이지가 새로고침되거나 의도한 대로 동작하지 않음.
이로 인해 프로젝트 저장 함수가 정상적으로 실행되지 않거나, 실행되어도 곧바로 리렌더링되어 효과가 사라지는 것처럼 보였음.

해결 방법: 폼의 기본 제출 동작 방지

✅ 방법 1 – e.preventDefault() 사용

function handleSaveClick(e) {
  e.preventDefault(); // ✅ form 기본 동작 막기
  onClickSaveProject(...);
}

<button onClick={handleSaveClick}>Save</button>

✅ 방법 2 – 버튼의 type을 "button"으로 명시

<button type="button" onClick={handleSaveClick}>Save</button>

두 방법 모두 페이지 새로고침을 방지하여 상태 유지 및 정상적인 프로젝트 추가 가능
type="button"을 사용하면 더 간단하고 실수를 줄일 수 있음

⚠️ 현재 구조의 문제점: Prop Drilling

현재 프로젝트는 상위 컴포넌트(App.jsx)에서 관리하는 상태와 함수를 여러 하위 컴포넌트에 **props로 계속 전달하는 구조(prop drilling)**를 가지고 있다.

예를 들어, 프로젝트 추가 함수(onAddProject)가 App → SideBar → CreateProject로 전달되는 식이여서 아래와 같은 문제가 발생된다.

중간 컴포넌트가 필요 없는 props를 전달만 하는 역할을 하게 됨
컴포넌트 간 결합도가 높아지고, 가독성 저하
규모가 커질수록 상태 관리가 복잡해짐

이 문제를 해결하기 위해 다음시간에 Context 학습해보도록 하겠다!

배운 점 & 느낀 점

ref와 status를 적절히 활용해 상태 관리와 DOM 제어에 익숙해졌다.
ReactDOM.createPortal을 사용해 모달을 루트 밖에 안전하게 렌더링하는 법을 배웠다.
<button type="button">을 명시하지 않으면 예상치 못한 폼 제출 이슈가 생길 수 있다는 걸 알게 되었다.
Tailwind CSS 사용법을 익힐 수 있었다.
커스텀 훅으로 상태 로직을 분리하면서 관심사 분리(SOC)의 중요성을 체감했다.
prop drilling을 겪으며 전역 상태 관리나 Context API의 필요성을 느꼈다.

[Spring] 빈 스코프

제가안난데여♪(´ε｀*) — Wed, 26 Mar 2025 15:38:23 +0900

이 글은 인프런에서 김영한 님의 "스프링 핵심원리 - 기본편"을 수강 후 공부한 내용을 정리한 게시글입니다. 부족한 부분이 있다면 언제든 지적 부탁드립니다.

✏️ 빈 스코프란?

스코프는 빈이 존재할 수 있는 범위를 의미한다.

싱글톤: 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프이다.
프로토타입: 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는 매우 짧은 범위의 스코프이다.
웹 관련 스코프
- request: 웹 요청이 들어오고 나갈때 까지 유지되는 스코프이다.
- session: 웹 세션이 생성되고 종료될 때 까지 유지되는 스코프이다.
- application: 웹의 서블릿 컨텍스트와 같은 범위로 유지되는 스코프이다
컴포넌트 스캔 자동 등록

@Scope("prototype")
@Component
public class HelloBean {}

수동 등록

@Scope("prototype")
@Bean
PrototypeBean HelloBean() {
	return new HelloBean();
}

✏️ 프로토타입 스코프

프로토타입 스코프는 싱글톤 스코프와 다르게 스프링 컨테이너에서 조회하면 스프링 컨테이너는 항상 새로운 인스턴스를 생성해서 반환한다.

프로토타입 스코프의 빈을 스프링 컨테이너에 요청한다.
스프링 컨테이너는 이 시점에 프로토타입 빈을 생성하고, 필요한 의존관계를 주입한다
스프링 컨테이너는 생성한 프로토타입 빈을 클라이언트에 반환한다.
이후에 스프링 컨테이너에 같은 요청이 오면 항상 새로운 프로토타입 빈을 생성해서 반환한다

특징

스프링 컨테이너에 요청할 때 마다 새로 생성된다.
스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입 그리고 초기화까지만 관여한다.
빈의 소멸 콜백을 하는 @PreDestory 같은 종료 메소드는 호출 되지 않는다.
그래서 프로토타입 빈은 프로토타입 빈을 조회한 클라이언트가 관리해야 한다. 종료 메서드에 대한 호출도 클라이언트가 직접 해야한다

package hello.core.scope;
import org.junit.jupiter.api.Test;
import
        org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Scope;
import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import static org.assertj.core.api.Assertions.*;
public class PrototypeTest {
    @Test
    public void prototypeBeanFind() {
        AnnotationConfigApplicationContext ac = new
                AnnotationConfigApplicationContext(PrototypeBean.class);
        System.out.println("find prototypeBean1");
        PrototypeBean prototypeBean1 = ac.getBean(PrototypeBean.class);
        System.out.println("find prototypeBean2");
        PrototypeBean prototypeBean2 = ac.getBean(PrototypeBean.class);
        System.out.println("prototypeBean1 = " + prototypeBean1);
        System.out.println("prototypeBean2 = " + prototypeBean2);
        assertThat(prototypeBean1).isNotSameAs(prototypeBean2);
        ac.close(); //종료
    }
    @Scope("prototype")
    static class PrototypeBean {
        @PostConstruct
        public void init() {
            System.out.println("PrototypeBean.init");
        }
        @PreDestroy
        public void destroy() {
            System.out.println("PrototypeBean.destroy");
        }
    }
}

프로토타입 빈을 2번 조회했으므로 완전히 다른 스프링 빈이 생성되고, 초기화도 2번 실행된 것을 확인할 수 있다.

싱글톤 빈과 프로토타입 빈을 함께 사용시 문제점

싱글톤 빈과 함께 사용할 때는 의도한 대로 잘 동작하지 않으므로 주의하자.

<프로토타입만 사용하는 경우>

public class SingletonWithPrototypeTest1 {
    @Test
    void prototypeFind() {
        AnnotationConfigApplicationContext ac = new
                AnnotationConfigApplicationContext(PrototypeBean.class);
        PrototypeBean prototypeBean1 = ac.getBean(PrototypeBean.class);
        prototypeBean1.addCount();
        assertThat(prototypeBean1.getCount()).isEqualTo(1);
        PrototypeBean prototypeBean2 = ac.getBean(PrototypeBean.class);
        prototypeBean2.addCount();
        assertThat(prototypeBean2.getCount()).isEqualTo(1);
    }
    @Scope("prototype")
    static class PrototypeBean {
        private int count = 0;
        public void addCount() {
            count++;
        }
        public int getCount() {
            return count;
        }
        @PostConstruct
        public void init() {
            System.out.println("PrototypeBean.init " + this);
        }
        @PreDestroy
        public void destroy() {
            System.out.println("PrototypeBean.destroy");
        }
    }
}

프로토타입 빈만 사용할 경우 클라이언트가 스프링컨테이너에게 프로토타입 빈을 요청하게 되면 새로 생성해여 반환하기 때문에 항상 count 의 값는 초기값 0에서 1증가하여 1을 반환하게 된다.

이번에는 clientBean 이라는 싱글톤 빈이 의존관계 주입을 통해서 프로토타입 빈을 주입받아서 사용하는 예를 보자

<싱글톤 빈에서 프로토타입 빈을 사용하는 경우>

package hello.core.scope;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Scope;
import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import static org.assertj.core.api.Assertions.*;

public class SingletonWithPrototypeTest1 {

	@Test
    void singletonClientUsePrototype() {
        AnnotationConfigApplicationContext ac = new
                AnnotationConfigApplicationContext(ClientBean.class, PrototypeBean.class);

        ClientBean clientBean1 = ac.getBean(ClientBean.class);
        int count1 = clientBean1.logic();
        assertThat(count1).isEqualTo(1);

        ClientBean clientBean2 = ac.getBean(ClientBean.class);
        int count2 = clientBean2.logic();
        assertThat(count2).isEqualTo(2);

    }

    static class ClientBean {

        private final PrototypeBean prototypeBean;

        @Autowired
        public ClientBean(PrototypeBean prototypeBean) {
            this.prototypeBean = prototypeBean;
        }

        public int logic() {
            prototypeBean.addCount();
            int count = prototypeBean.getCount();
            return count;
        }
    }

    @Scope("prototype")
    static class PrototypeBean {

        private int count = 0;

        public void addCount() {
            count++;
        }

        public int getCount() {
            return count;
        }

        @PostConstruct
        public void init() {
            System.out.println("PrototypeBean.init " + this);
        }

        @PreDestroy
        public void destroy() {
            System.out.println("PrototypeBean.destroy");
        }
    }
}

clientBean 은 싱글톤이므로, 보통 스프링 컨테이너 생성 시점에 함께 생성되고, 의존관계 주입도 발생한다.

그렇기 때문이 clientBean이 생성될때 의존관계에 있는 프로토타입 빈도 생성되고 주입받게 된다.

이때 프로토타입의 빈의 count 값은 초기값 0이다.

다음 count를 증가시키는 메소드를 호출하게 되면 clientBean 을 스프링 컨테이너에 요청해서 받는다.싱글톤이므로 항상 같은 clientBean이 반환되어 의존하고 있는 프로토타입을 접근할 수 있다. 이때 clientBean이 참조하고 있는 프로토타입 빈은 변하지 않기 때문에 동일한 빈의 메소드를 실행하게 되어 count 값이 1 증가하여 1이 된다.

이후 다른 클라이언트가 count를 증가시키는 메소드를 호출하게 되면 위와 동일하게 동일한 프로토타입의 빈을 참조하게 되어 1이었던 count 값을 2로 증가하게 된다.

여기서 중요한 점은 clientBean이 내부에 가지고 있는 프로토타입 빈은 이미 과거에 주입이 끝난 빈이다. 주입 시점에 스프링 컨테이너에 요청해서 프로토타입 빈이 새로 생성이 된 것이지, 사용 할 때마다 새로 생성되는 것이 아니다!

스프링은 일반적으로 싱글톤 빈을 사용하므로, 싱글톤 빈이 프로토타입 빈을 사용하게 된다. 그런데 싱글톤 빈은 생성 시점에만 의존관계 주입을 받기 때문에, 프로토타입 빈이 새로 생성되기는 하지만, 싱글톤 빈과 함께 계속 유지되는 것이 문제다

싱글톤 빈과 프로토타입 빈을 함께 사용시 문제점 해결하기 - Provider

@Autowired
private ObjectProvider<PrototypeBean> prototypeBeanProvider;
public int logic() {
    PrototypeBean prototypeBean = prototypeBeanProvider.getObject();
    prototypeBean.addCount();
    int count = prototypeBean.getCount();
    return count;
}

지정한 빈을 컨테이너에서 대신 찾아주는 DL(Dependency Lookup)서비스를 제공하는 것이 바로 ObjectProvider 이다.
ObjectProvider의 prototypeBeanProvider.getObject() 를 호출하면 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아서 반환하고 항상 새로운 프로토타입 빈이 생성된다.
ObjectProvider: ObjectFactory상속, 옵션, 스트림 처리등 편의 기능이 많고, 별도의 라이브러리 필요 없음, 스프링에 의존

@Autowired
private Provider<PrototypeBean> provider;
public int logic() {
    PrototypeBean prototypeBean = provider.get();
    prototypeBean.addCount();
    int count = prototypeBean.getCount();
    return count;
}

javax.inject.Provider 라는 JSR-330 자바 표준을 사용한다.(스프링 부트 3.0은 jakarta.inject.Provider 사용 - gradle 에 추가)
provider 의 get() 을 호출하면 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아서 반환하고 항상 새로운 프로토타입 빈이 생성되는 것을 확인 할 수 있다.
자바 표준이고, 기능이 단순하므로 단위테스트를 만들거나 mock 코드를 만들기는 훨씬 쉬워진다.

✏️ 웹 스코프

동시에 여러 HTTP 요청이 오면 정확히 어떤 요청이 남긴 로그인지 구분하기 어렵다.

이럴때 사용하기 딱 좋은것이 바로 request 스코프이다.

특징

웹 스코프는 웹 환경에서만 동작한다.
스프링이 해당 종료시점까지 관리한다. 따라서 종료 메소드가 호출된다.

종류

request: HTTP 요청 하나가 들어오고 나갈 때 까지 유지되는 스코프, 각각의 HTTP 요청마다 별도의 빈 인스턴스가 생성되고, 관리된다.
session: HTTP Session과 동일한 생명주기를 가지는 스코프
application: 서블릿 컨텍스트( ServletContext )와 동일한 생명주기를 가지는 스코프
websocket: 웹 소켓과 동일한 생명주기를 가지는 스코프

✏️ request 스코프 예제

동시에 다양한 http 요청이 들어오더라도 UUID와 requestURL을 로그에 함께 남겨 요청을 구분해보자.

build.gradle 에 web 라이브러리 추가

implementation 'org.springframework.boot:spring-boot-starter-web'

MyLogger

package hello.core.common;
import org.springframework.context.annotation.Scope;
import org.springframework.stereotype.Component;
import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import java.util.UUID;
@Component
@Scope(value = "request")
public class MyLogger {

    private String uuid;
    private String requestURL;

    public void setRequestURL(String requestURL) {
        this.requestURL = requestURL;
    }

    public void log(String message) {
        System.out.println("[" + uuid + "]" + "[" + requestURL + "] " +message);
    }

    @PostConstruct
    public void init() {
        uuid = UUID.randomUUID().toString();
        System.out.println("[" + uuid + "] request scope bean create:" + this);
    }

    @PreDestroy
    public void close() {
        System.out.println("[" + uuid + "] request scope bean close:" + this);
    }
}

@Scope(value = "request")를 사용해서 request 스코프로 지정했다. 이제 이 빈은 HTTP 요청 당 하나씩 생성되고, HTTP 요청이 끝나는 시점에 소멸된다.
이 빈이 생성되는 시점에 자동으로 @PostConstruct 초기화 메서드를 사용해서 uuid를 생성해서 저장해둔다.
이 빈은 HTTP 요청 당 하나씩 생성되므로, uuid를 저장해두면 다른 HTTP 요청과 구분할 수 있다.
이 빈이 소멸되는 시점에 @PreDestroy 를 사용해서 종료 메시지를 남긴다.
requestURL 은 이 빈이 생성되는 시점에는 알 수 없으므로, 외부에서 setter로 입력 받는다.

위 MyLogger를 사용할 테스트 컨트롤러와 서비스 코드를 작성해보자.

LogDemoController

package hello.core.web;
import hello.core.common.MyLogger;
import hello.core.logdemo.LogDemoService;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.ResponseBody;
import javax.servlet.http.HttpServletRequest;

@Controller
@RequiredArgsConstructor
public class LogDemoController {

		private final LogDemoService logDemoService;
    private final MyLogger myLogger;

    @RequestMapping("log-demo")
    @ResponseBody
    public String logDemo(HttpServletRequest request) {
        String requestURL = request.getRequestURL().toString();
        myLogger.setRequestURL(requestURL);
        myLogger.log("controller test");
        logDemoService.logic("testId");
        return "OK";
    }
}

LogDemoService

package hello.core.logdemo;
import hello.core.common.MyLogger;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Service;

@Service
@RequiredArgsConstructor
public class LogDemoService {

		private final MyLogger myLogger;

    public void logic(String id) {
        myLogger.log("service id = " + id);
    }

}

위와같이 코드를 작성하고 실행하게 되면 오류가 난다.

Error creating bean with name 'myLogger': Scope 'request' is not active for the
current thread; consider defining a scoped proxy for this bean if you intend to
refer to it from a singleton;

위와 같은 오류가 나는 이유는 컨트롤러에 MyLogger를 주입받는 부분때문이다.private final MyLogger myLogger;
스프링 어플리케이션을 실행하는 시점에 싱글톤 빈은 생성되어 주입할 수 있지만 request 스코프 빈은 아직 생성이 되지 않는 상태에서 주입을 하려고 했기 때문이다.

위와 같은 문제는 Provider와 프록시로 해결할 수 있다.

✏️ 스코프와 Provider

LogDemoController

package hello.core.web;
import hello.core.common.MyLogger;
import hello.core.logdemo.LogDemoService;
import lombok.RequiredArgsConstructor;
import org.springframework.beans.factory.ObjectProvider;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.ResponseBody;
import javax.servlet.http.HttpServletRequest;

@Controller
@RequiredArgsConstructor
public class LogDemoController {

    private final LogDemoService logDemoService;
    private final ObjectProvider<MyLogger> myLoggerProvider;

    @RequestMapping("log-demo")
    @ResponseBody
    public String logDemo(HttpServletRequest request) {
        String requestURL = request.getRequestURL().toString();
        MyLogger myLogger = myLoggerProvider.getObject();
        myLogger.setRequestURL(requestURL);
        myLogger.log("controller test");
        logDemoService.logic("testId");
        return "OK";
    }
}

LogDemoService

package hello.core.logdemo;
import hello.core.common.MyLogger;
import lombok.RequiredArgsConstructor;
import org.springframework.beans.factory.ObjectProvider;
import org.springframework.stereotype.Service;

@Service
@RequiredArgsConstructor
public class LogDemoService {

    private final ObjectProvider<MyLogger> myLoggerProvider;

    public void logic(String id) {
        MyLogger myLogger = myLoggerProvider.getObject();
        myLogger.log("service id = " + id);
    }

}

ObjectProvider 덕분에 ObjectProvider.getObject() 를 호출하는 시점까지 request scope 빈의생성을 지연할 수 있다.
ObjectProvider.getObject() 를 호출하시는 시점에는 HTTP 요청이 진행중이므로 request scope 빈의 생성이 정상 처리된다.
ObjectProvider.getObject()를 LogDemoController LogDemoService에서 각각 한번씩 따로호출해도 같은 HTTP 요청이면 같은 스프링 빈이 반환된다!

✏️ 스코프와 프록시

LogDemoController

package hello.core.web;
import hello.core.common.MyLogger;
import hello.core.logdemo.LogDemoService;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.ResponseBody;
import javax.servlet.http.HttpServletRequest;

@Controller
@RequiredArgsConstructor
public class LogDemoController {

    private final LogDemoService logDemoService;
    private final MyLogger myLogger;

    @RequestMapping("log-demo")
    @ResponseBody
    public String logDemo(HttpServletRequest request) {
        String requestURL = request.getRequestURL().toString();
        myLogger.setRequestURL(requestURL);
        myLogger.log("controller test");
        logDemoService.logic("testId");
        return "OK";
    }
}

LogDemoService

package hello.core.logdemo;
import hello.core.common.MyLogger;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Service;

@Service
@RequiredArgsConstructor
public class LogDemoService {

    private final MyLogger myLogger;

    public void logic(String id) {
        myLogger.log("service id = " + id);
    }
}

MyLogger

@Component
@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class MyLogger {
				...

}

proxyMode = ScopedProxyMode.TARGET_CLASS 를 추가해주자.
- 적용 대상이 인터페이스가 아닌 클래스면 TARGET_CLASS 를 선택
- 적용 대상이 인터페이스면 INTERFACES 를 선택
- 이렇게 하면 MyLogger의 가짜 프록시 클래스를 만들어두고 HTTP request와 상관 없이 가짜 프록시 클래스를 다른 빈에 미리 주입해 둘 수 있다.
어노테이션에 proxyMode를 지정해줬을 뿐인데 아까는 주입문제로 오류났던 Controller 와 Service가 정상 동작 한다. 그 이유는 CGLIB라는 라이브러리로 클래스를 상속받은 가짜 프록시 객체를 만들어서 주입하기 때문이다!
@Scope 의 proxyMode = ScopedProxyMode.TARGET_CLASS) 를 설정해줬을 뿐인데 아까는 주입문제로 오류났던 Controller 와 Service가 정상 동작 한다. 그 이유는 스프링 컨테이너는 CGLIB라는 바이트코드를 조작하는 라이브러리를 사용해서, MyLogger를 상속받은 가짜 프록시 객체를 생성하여 주입하기 때문이다.
실제로 request 스코프 빈이 생성 되기 전 MyLogger를 출력하면 아래와 같다.
- MyLogger$$EnhancerBySpringCGLIB 이라는 클래스로 만들어진 객체가 대신 등록된 것을 확인할 수 있다. 그리고 스프링 컨테이너에 "myLogger"라는 이름으로 진짜 대신에 이 가짜 프록시 객체를 등록한다. ac.getBean("myLogger", MyLogger.class) 로 조회해도 프록시 객체가 조회되는 것을 확인할 수 있다. 그래서 의존관계 주입도 이 가짜 프록시 객체가 주입된다.
myLogger = class hello.core.common.MyLogger$$EnhancerBySpringCGLIB$$b68b726d
그러면 가짜 프록시 객체가 어떻게 MyLog의 메소드에 접근할 수 있을까 ?
- 가짜 프록시 객체는 내부에 진짜 myLogger 를 찾는 방법을 알고 있다.
- 클라이언트가 myLogger.log() 을 호출하면 사실은 가짜 프록시 객체의 메서드를 호출한 것이다.
- 가짜 프록시 객체는 request 스코프의 진짜 myLogger.log() 를 호출한다.
- 가짜 프록시 객체는 원본 클래스를 상속 받아서 만들어졌기 때문에 이 객체를 사용하는 클라이언트 입장에서는 사실 원본인지 아닌지도 모르게, 동일하게 사용할 수 있다(다형성)

<정리>

CGLIB라는 라이브러리로 내 클래스를 상속 받은 가짜 프록시 객체를 만들어서 주입한다.이 가짜 프록시 객체는 실제 요청이 오면 그때 내부에서 실제 빈을 요청하는 위임 로직이 들어있다.
가짜 프록시 객체는 실제 request scope와는 관계가 없다. 그냥 가짜이고, 내부에 단순한 위임 로직만 있고, 싱글톤 처럼 동작한다.
프록시 객체 덕분에 클라이언트는 마치 싱글톤 빈을 사용하듯이 편리하게 request scope를 사용할 수 있다.
사실 Provider를 사용하든, 프록시를 사용하든 핵심 아이디어는 진짜 객체 조회를 꼭 필요한 시점까지 지연처리한다는 점이다. 단지 애노테이션 설정 변경만으로 원본 객체를 프록시 객체로 대체할 수 있다. 이것이 바로 다형성과 DI 컨테이너 가 가진 큰 강점이다.꼭 웹 스코프가 아니어도 프록시는 사용할 수 있다.

[Spring] 빈 생명주기 콜백

제가안난데여♪(´ε｀*) — Wed, 26 Mar 2025 15:36:19 +0900

이 글은 인프런에서 김영한 님의 "스프링 핵심원리 - 기본편"을 수강 후 공부한 내용을 정리한 게시글입니다. 부족한 부분이 있다면 언제든 지적 부탁드립니다.

✏️ 빈 생명 주기 콜백

스프링 어플리케이션 시작 시점에 필요한 연결을 미리 해두고 어플리케이션 종료 시점에 연결을 모두 종료하는 객체 초기화 작업과 종료 작업이 필요하다.

package hello.core.lifecycle;
public class NetworkClient {

    private String url;

    public NetworkClient() {
        System.out.println("생성자 호출, url = " + url);
        connect();
        call("초기화 연결 메시지");
    }

    public void setUrl(String url) {
        this.url = url;
    }

    //서비스 시작시 호출
    public void connect() {
        System.out.println("connect: " + url);
    }

    public void call(String message) {
        System.out.println("call: " + url + " message = " + message);
    }

    //서비스 종료시 호출
    public void disconnect() {
        System.out.println("close: " + url);
    }
}

위 예제 코드에서 생성자 호출시 connect() 메소드를 실행하여 연결을 맺는 초기화 작업을 수행하도록 되어있다.

그러나 위 코드를 실행해보면 이상한 결과가 나온다.

생성자 호출, url = null
connect: null
call: null message = 초기화 연결 메시지

이런 결과가 나오는 이유는 객체가 생성된 후에 url을 주입하기 때문이다.

처음에는 객체를 생성할때 파라미터로 url을 주입해주면 되지 않나 생각했는데

이 객체는 스프링 컨테이너가 올라갈때 빈으로 생성되야 하기 때문에 url을 사용자가 입력할 수 없다.

또한 객체의 생성과 초기화를 분리하는 것이 좋다.

생성자는 필수 정보(파라미터)를 받고, 메모리를 할당해서 객체를 생성하는 책임을 가진다. 반면에 초기화는 이렇게 생성된 값들을 활용해서 외부 커넥션을 연결하는등 무거운 동작을 수행한다.

따라서 생성자 안에서 무거운 초기화 작업을 함께 하는 것 보다는 객체를 생성하는 부분과 초기화 하는 부분을 명확하게 나누는 것이 유지보수 관점에서 좋다. 물론 초기화 작업이 내부 값들만 약간 변경하는 정도로 단순한 경우에는 생성자에서 한번에 다 처리하는게 더 나을 수 있다

이러한 이유로 생성자에서 url을 저장하지 않는다.

그렇다면 스프링 빈은 객체 생성 → 의존 관계 주입 라이프 사이클을 가지게 되는데 의존 관계 주입이 끝난 후에 개발자는 객체를 호출 해야 온전하게 의도한 바대로 객체를 사용할 수 있다.

그렇게 하기 위해서는 의존관계 주입이 끝난 시점을 개발자가 알아야한다.

이 시점을 스프링이 알려준다.

스프링은 의존관계 주입이 완료되면 스프링빈에게 콜백 메서드를 통해 초기화 시점을 알려주는 다양한 기능을 제공한다.

또한 스프링은 스프링 컨테이너가 종료되기 직전에 소멸 콜백을 준다.

따라서 종료 작업을 안전하게 진행할 수 있다.

<스프링 빈의 이벤트 라이프사이클>

스프링 컨테이너 생성

-> 스프링 빈 생성

-> 의존관계 주입

-> 초기화 콜백

-> 사용

-> 소멸 전 콜백

-> 스프링 종료

초기화 콜백: 빈이 생성되고, 빈의 의존관계 주입이 완료된 후 호출

소멸전 콜백: 빈이 소멸되기 직전에 호출

✏️ 빈 생명주기 콜백 방법

인터페이스(InitializingBean, DisposableBean)

package hello.core.lifecycle;
import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.InitializingBean;
public class NetworkClient implements InitializingBean, DisposableBean {
    private String url;
    public NetworkClient() {
        System.out.println("생성자 호출, url = " + url);
    }
    public void setUrl(String url) {
        this.url = url;
    }
    //서비스 시작시 호출
    public void connect() {
        System.out.println("connect: " + url);
    }
    public void call(String message) {
        System.out.println("call: " + url + " message = " + message);
    }
    //서비스 종료시 호출
    public void disConnect() {
        System.out.println("close + " + url);
    }
    @Override
    public void afterPropertiesSet() throws Exception {
        connect();
        call("초기화 연결 메시지");
    }
    @Override
    public void destroy() throws Exception {
        disConnect();
    }
}

InitializingBean, DisposableBean 인터페이스를 사용한다.
InitializingBean은 afterPropertiesSet() 메서드로 초기화를 지원한다.
DisposableBean은 destroy() 메서드로 소멸을 지원한다
단점
- 이 인터페이스는 스프링 전용 인터페이스이다. 따라서 해당 코드가 스프링 전용 인터페이스에 의존한다.
- 초기화, 소멸 메소드의 이름을 변경할 수 없다.
- 개발자가 코드를 고칠 수 없는 외부 라이브러리에는 적용할 수 없다.
거의 사용하지 않는다.

설정 정보에 초기화 메서드, 종료 메서드 지정

package hello.core.lifecycle;
public class NetworkClient {
    private String url;
    public NetworkClient() {
        System.out.println("생성자 호출, url = " + url);
    }
    public void setUrl(String url) {
        this.url = url;
    }
    //서비스 시작시 호출
    public void connect() {
        System.out.println("connect: " + url);
    }
    public void call(String message) {
        System.out.println("call: " + url + " message = " + message);
    }
    //서비스 종료시 호출
    public void disConnect() {
        System.out.println("close + " + url);
    }
    public void init() {
        System.out.println("NetworkClient.init");
        connect();
        call("초기화 연결 메시지");
    }
    public void close() {
        System.out.println("NetworkClient.close");
        disConnect();
    }

@Configuration
static class LifeCycleConfig {
    @Bean(initMethod = "init", destroyMethod = "close")
    public NetworkClient networkClient() {
        NetworkClient networkClient = new NetworkClient();
        networkClient.setUrl("<http://hello-spring.dev>");
        return networkClient;
    }
}

설정 정보에 @Bean(initMethod = "init", destroyMethod = "close") 처럼 초기화, 소멸 메서드를 지정할 수 있다.
메서드 이름을 자유롭게 설정할 수 있다.
스프링 빈이 스프링 코드에 의존하지 않는다.
코드가 아니라 설정정보를 사용하기 때문에 코드를 고칠 수 없는 외부 라이브러리에도 초기화, 종료 메소드를 적용할 수 있다.
destroyMethod 속성
- @Bean의 destroyMethod 는 기본값이 (inferred) (추론)으로 등록되어 있다. 이 추론 기능은 close , shutdown 라는 이름의 메서드를 자동으로 호출해준다. 이름 그대로 종료 메서드를 추론해서 호출해준다. 따라서 직접 스프링 빈으로 등록하면 종료 메서드는 따로 적어주지 않아도 잘 동작한다

@PostConstruct, @PreDestroy 애노테이션 지원

package hello.core.lifecycle;
import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
public class NetworkClient {
    private String url;
    public NetworkClient() {
        System.out.println("생성자 호출, url = " + url);
    }
    public void setUrl(String url) {
        this.url = url;
    }
    //서비스 시작시 호출
    public void connect() {
        System.out.println("connect: " + url);
    }
    public void call(String message) {
        System.out.println("call: " + url + " message = " + message);
    }
    //서비스 종료시 호출
    public void disConnect() {
        System.out.println("close + " + url);
    }
    @PostConstruct
    public void init() {
        System.out.println("NetworkClient.init");
        connect();
        call("초기화 연결 메시지");
    }
    @PreDestroy
    public void close() {
        System.out.println("NetworkClient.close");
        disConnect();
    }
}

최근 스프링에서 가장 권장하는 방법이다.
javax.annotation.PostConstruct이다. 스프링에 종속적인 기술이 아니라 JSR-250라는 자바 표준이다. 따라서 스프링이 아닌 다른 컨테이너에서도 동작한다
유일한 단점은 외부 라이브러리에는 적용하지 못한다는 것이다. 외부 라이브러리를 초기화, 종료 해야 하면 @Bean의 기능을 사용하자.
정리
- @PostConstruct, @PreDestroy 애노테이션을 사용하자
- 코드를 고칠 수 없는 외부 라이브러리를 초기화, 종료해야 하면 @Bean 의 initMethod , destroyMethod 를 사용하자.

[Spring] 의존관계 자동 주입2

제가안난데여♪(´ε｀*) — Wed, 26 Mar 2025 15:33:50 +0900

이 글은 인프런에서 김영한 님의 "스프링 핵심원리 - 기본편"을 수강 후 공부한 내용을 정리한 게시글입니다. 부족한 부분이 있다면 언제든 지적 부탁드립니다.

다양한 의존 관계 주입 방법에 대해서는 “이전 게시물”을 확인해주세요.

이전 게시물 - 의존관계 자동주입 1

✏️ 자동 주입 대상을 옵션으로 처리

주입할 스프링 빈이 없어도 동작해야 할 때가 있다.

그런데 @Autowired 만 사용하면 required 옵션의 기본값이 true 로 되어 있어서 자동 주입 대상이 없으면 오류가 발생한다. 이를 해결하기 위해서는 아래와 같이 3가지 방법을 가지고 옵션처리하여 해결할 수 있다.

아래 예시에서 Member 는 스프링 빈이 아니다.

@Autowired(required=false) : 자동 주입할 대상이 없으면 수정자 메서드 자체가 호출 안됨
//호출 안됨 @Autowired(required = false) public void setNoBean1(Member member) { System.out.println("setNoBean1 = " + member); } //결과 없음
org.springframework.lang.@Nullable : 자동 주입할 대상이 없으면 null이 입력된다.
//null 호출 @Autowired public void setNoBean2(@Nullable Member member) { System.out.println("setNoBean2 = " + member); } //결과 setNoBean2 = null
Optional<> : 자동 주입할 대상이 없으면 Optional.empty 가 입력된다.
//Optional.empty 호출 @Autowired(required = false) public void setNoBean3(Optional<Member> member) System.out.println("setNoBean3 = " + member); } //결과 setNoBean3 = Optional.empty

✏️ 생성자 주입을 선택하자!

생성자 주입 방식을 선택하는 이유는 여러가지가 있지만, 프레임워크에 의존하지 않고, 순수한 자바 언어의 특징을 잘 살리는 방법이기도 하다.
기본으로 생성자 주입을 사용하고, 필수 값이 아닌 경우에는 수정자 주입 방식을 옵션으로 부여하면 된다. 생성자 주입과 수정자 주입을 동시에 사용할 수 있다.
항상 생성자 주입을 선택해라! 그리고 가끔 옵션이 필요하면 수정자 주입을 선택해라. 필드 주입은 사용하지 않는 게 좋다.

✏️ 롬북 Lombok

생성자 주입을 작성하는 과정에서 비슷한 코드르 여러번 작성하게 된다.

다 형식이 정해져 있는 코드들이기때문에 이를 롬북이라는 라이브러리에서 코드 작성을 간소화 시켜준다.

@RequiredArgsConstructor 기능을 사용하면 final이 붙은 필드를 모아서 생성자를 자동으로 만들어준다. (다음 코드에는 보이지 않지만 실제 호출 가능하다.)

✏️ 특정 빈을 조회할 때 조회된 빈이 2개 이상이면 ?

ac.getBean(DiscountPolicy.class) 으로 DiscountPolicy스프링 빈 조회하려고 한다.

근데 이때 DiscountPolicy의 하위 타입인 FixDiscountPolicy , RateDiscountPolicy둘다 스프링 빈으로 선언되어 있어 ac.getBean(DiscountPolicy.class) 으로 조회하게 되면 반환되는 빈이 2개가 되어 NoUniqueBeanDefinitionException 오류가 발생한다.

NoUniqueBeanDefinitionException: No qualifying bean of type
'hello.core.discount.DiscountPolicy' available: expected single matching bean
but found 2: fixDiscountPolicy,rateDiscountPolicy

이때 하위 타입으로 지정할 수 도 있지만, 하위 타입으로 지정하는 것은 DIP를 위배하고 유연성이 떨어진다. 그리고 이름만 다르고, 완전히 똑같은 타입의 스프링 빈이 2개 있을 때 해결이 안된다.

@Autowired 필드명 매칭

@Autowired 는 타입 매칭을 시도하고, 이때 여러 빈이 있으면 필드 이름, 파라미터 이름으로 빈 이름을 추가 매칭한다.

@Autowired
private DiscountPolicy rateDiscountPolicy;

DiscountPolicy 타입으로 매칭을 시도하고 그 결과 여러 개의 빈이 존재할 경우 rateDiscountPolicy 라는 이름을 가진 빈이 있는지 추가로 확인한다.

@Qualifier @Qualifier끼리 매칭 빈 이름 매칭

@Qualifier 는 추가 구분자를 붙여주는 방법이다. 주입시 추가적인 방법을 제공하는 것이지 빈 이름을 변경하는 것은 아니다.

@Component
@Qualifier("mainDiscountPolicy")
public class RateDiscountPolicy implements DiscountPolicy {}

@Component
@Qualifier("fixDiscountPolicy")
public class FixDiscountPolicy implements DiscountPolicy {}

@Autowired
public OrderServiceImpl(MemberRepository memberRepository,
                        @Qualifier("mainDiscountPolicy") DiscountPolicy discountPolicy) {
    this.memberRepository = memberRepository;
    this.discountPolicy = discountPolicy;
}

@Qualifier 가 mainDiscountPolicy 를 찾은 다음 매칭 한다.
만약 @Qualifier 가 mainDiscountPolicy 인 빈이 없다면 빈 이름이 mainDiscountPolicy 빈을 찾아 매칭 시킨다.
빈 이름도 동일한 빈이 없다면 NoSuchBeanDefinitionException 예외를 발생한다.

@Primary 사용

@Primary 는 우선순위를 정하는 방법이다. @Autowired 시에 여러 빈이 매칭되면 @Primary 가 우선권을 가진다.

@Component
@Primary
public class RateDiscountPolicy implements DiscountPolicy {}

@Component
public class FixDiscountPolicy implements DiscountPolicy {}

//생성자
@Autowired
public OrderServiceImpl(MemberRepository memberRepository,
                        DiscountPolicy discountPolicy) {
    this.memberRepository = memberRepository;
    this.discountPolicy = discountPolicy;
}

우선순위가 더 높은 RateDiscountPolicy를 주입힌다.

✏️ 조회한 빈이 모두 필요할 때 List, Map

의도적으로 정말 해당 타입의 스프링 빈이 다 필요한 경우도 있다.

즉, DiscountPolicy 타입의 모든 빈을 다 조회하고 싶은 경우를 말한다.

이런 경우에는 아래와 같이 List나 Map 자료구조로 모두 조회할 수 있다.

static class DiscountService {

    private final Map<String, DiscountPolicy> policyMap;
    private final List<DiscountPolicy> policies;

    public DiscountService(Map<String, DiscountPolicy> policyMap, List<DiscountPolicy> policies) {
        this.policyMap = policyMap;
        this.policies = policies;

        System.out.println("policyMap = " + policyMap);
        System.out.println("policies = " + policies);
    }
}

Map<String, DiscountPolicy> : map의 키에 스프링 빈의 이름을 넣어주고, 그 값을 DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아준다.
List : DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아준다.

✏️ 빈 등록 결론

편리한 자동 기능을 기본으로 사용하자
직접 등록하는 기술 지원 객체는 수동 등록하자
다형성을 적극 활용하는 비즈니스 로직은 수동 등록을 고민해보자

[Spring] 컴포넌트 스캔 & 의존관계 자동 주입

제가안난데여♪(´ε｀*) — Wed, 26 Mar 2025 15:31:52 +0900

이 글은 인프런에서 김영한 님의 "스프링 핵심원리 - 기본편"을 수강 후 공부한 내용을 정리한 게시글입니다. 부족한 부분이 있다면 언제든 지적 부탁드립니다.

✏️ 자동으로 스프링 빈을 등록해 → 컴포넌트 스캔(@ComponentScan, @Component)

컴포넌트 스캔이란 ?

지금까지의 과정에서 자바 코드의 @Bean 이나 XML의 <bean> 를 통해서 직접 스프링 빈을 등록
상당히 귀찮고 누락할 수 있는 가능성이 높다는 문제점을 지닌다.
이를 해결하기 위해 컴포넌트 스캔이라는 기능을 통해서 스프링 빈을 자동으로 등록할 수 있다.

컴포넌트 스캔 사용하기

컴포넌트 스캔을 사용하려면 먼저 @ComponentScan 을 설정 클래스에 붙여준다.
기존의 AppConfig와는 다르게 @Bean으로 등록한 클래스가 하나도 없다!

AutoAppConfig.java

package hello.core;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.FilterType;
import static org.springframework.context.annotation.ComponentScan.*;
@Configuration
@ComponentScan
public class AutoAppConfig {

}

컴포넌트 스캔은 @Component 어노테이션이 붙은 클래스를 스캔해서 스프링 빈으로 등록한다.
그래서 스프링 빈으로 등록하고 싶은 클래스를 컴포넌트 스캔의 대상이 되도록 @Component 어노테이션을 붙여주자.

MemoryMemberRepository.java

@Component
public class MemoryMemberRepository implements MemberRepository {}

RateDiscountPolicy.java

@Component
public class RateDiscountPolicy implements DiscountPolicy {}

MemberServiceImpl.java

@Component
public class MemberServiceImpl implements MemberService {

		private final MemberRepository memberRepository;

		@Autowired
		public MemberServiceImpl(MemberRepository memberRepository) {
				this.memberRepository = memberRepository;
		}
}

✏️ 의존관계 자동 주입(@Autowired)

@Autowired 는 의존관계를 자동으로 주입해준다

OrderServiceImpl.java

@Component
public class OrderServiceImpl implements OrderService {

		private final MemberRepository memberRepository;
		private final DiscountPolicy discountPolicy;

		@Autowired
		public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
			this.memberRepository = memberRepository;
			this.discountPolicy = discountPolicy;
		}

}

@Autowired 를 사용하면 생성자에서 여러 의존관계도 한번에 주입받을 수 있다

✏️ 컴포넌트 스캔과 자동 의존관계 주입의 동작 과정

@ComponentScan
- @ComponentScan 은 @Component 가 붙은 모든 클래스를 스프링 빈으로 등록한다.
- 이때 스프링 빈의 기본 이름은 클래스명을 사용하되 맨 앞글자만 소문자를 사용한다.
  - 빈 이름 기본 전략: MemberServiceImpl 클래스 memberServiceImpl
@Autowired 의존관계 자동 주입
- 생성자에 @Autowired 를 지정하면, 스프링 컨테이너가 자동으로 해당 스프링 빈을 찾아서 주입한다.
- 기본 조회 전략은 타입이 같은 빈을 찾아서 주입한다.

✏️ 탐색 위치와 기본 스캔 대상

탐색할 패키지의 시작 위치 지정

모든 자바 클래스를 다 컴포넌트 스캔하면 시간이 오래 걸린다. 그래서 꼭 필요한 위치부터 탐색하도록 시작 위치를 지정할 수 있다.

@ComponentScan(basePackages = "hello.core",}

basePackages : 탐색할 패키지의 시작 위치를 지정한다. 이 패키지를 포함해서 하위 패키지를 모두 탐색한다.
basePackages = {"hello.core", "hello.service"} 이렇게 여러 시작 위치를 지정할 수도 있다.
basePackageClasses : 지정한 클래스의 패키지를 탐색 시작 위치로 지정한다.
만약 지정하지 않으면 @ComponentScan 이 붙은 설정 정보 클래스의 패키지가 시작 위치가 된다.
설정 정보 클래스의 위치를 프로젝트 최상단에 두는 것을 권장.최근 스프링 부트도 이 방법을 기본으로 제공한다.
스프링 부트를 사용하면 스프링 부트의 대표 시작 정보인 @SpringBootApplication 를 이 프로젝트 시작 루트 위치에 두는 것이 관례이다. (그리고 이 설정안에 바로 @ComponentScan 이 들어있다!)

컴포넌트 스캔 기본 대상

컴포넌트 스캔은 @Component 뿐만 아니라 다음과 내용도 추가로 대상에 포함한다.

@Controller : 스프링 MVC 컨트롤러로 인식
@Service : 사실 @Service 는 특별한 처리를 하지 않는다. 대신 개발자들이 핵심 비즈니스 로직이 여기에 있겠구나 라고 비즈니스 계층을 인식하는데 도움이 된다
@Repository : 스프링 데이터 접근 계층으로 인식하고, 데이터 계층의 예외를 스프링 예외로 변환해준다.
@Configuration : 앞서 보았듯이 스프링 설정 정보로 인식하고, 스프링 빈이 싱글톤을 유지하도록 추가 처리를 한다.

사실 애노테이션에는 상속관계라는 것이 없다. 그래서 이렇게 애노테이션이 특정 애노테이션을 들고 있는 것을 인식할 수 있는 것은 자바 언어가 지원하는 기능은 아니고, 스프링이 지원하는 기능이다.

✏️ 중복 등록과 충돌

자동 빈 등록 vs 자동 빈 등록

컴포넌트 스캔에 의해 자동으로 스프링 빈이 등록되는데, 그 이름이 같은 경우 스프링은 오류를 발생시킨다.
- ConflictingBeanDefinitionException 예외 발생

수동 빈 등록 vs 자동 빈 등록

수동 빈 등록이 우선
- 수동 빈이 자동 빈을 오버라이딩

✏️ 다양한 의존관계 주입 방법

생성자 주입

생성자를 통해서 의존관계를 주입 받음
특징
- 생성자 호출 시점에 딱 1번만 호출됨이 보장
- 불변, 필수 의존관계에서 사용
생성자가 딱 1개만 있으면 @Autowired를 생략 가능

@Component
public class OrderServiceImpl implements OrderService {

    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;

    @Autowired
    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy
            discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }
}

수정자 주입(setter 주입)

setter 메소드(수정자 메소드)를 통해서 의존관계를 주입 받음
특징
- 자바빈 프로퍼티 규약의 수정자 메소드 방식을 사용하는 방법
- 선택, 변경 가능성이 있는 의존관계에서 사용
@Autowired 의 기본 동작은 주입할 대상이 없으면 오류가 발생한다. 주입할 대상이 없어도 동작하게 하려면 @Autowired(required = false) 로 지정하면 된다.

@Component
public class OrderServiceImpl implements OrderService {

    private MemberRepository memberRepository;
    private DiscountPolicy discountPolicy;

    @Autowired
    public void setMemberRepository(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }

    @Autowired
    public void setDiscountPolicy(DiscountPolicy discountPolicy) {
        this.discountPolicy = discountPolicy;
    }
}

필터 주입

필드에 바로 주입
특징
- 코드가 간결하지만 외부에서 변경이 불가능해서 테스트하기 어려움
- DI 프레임워크가 없으면 아무것도 할 수 없다.
- 사용하지 말자!!!!
  - 어플리케이션의 실제 코드와 관계없는 테스트 코드가 생성됨
  - 스프링 설정을 목적으로 하는 @Configuration 같은 곳에서만 특별한 용도로 사용하자.

@Component
public class OrderServiceImpl implements OrderService {
    @Autowired
    private MemberRepository memberRepository;
    @Autowired
    private DiscountPolicy discountPolicy;
}

일반 메소드 주입

일반 메소드를 통해서 주입
특징
- 한번에 여러번 필드를 주입받을 수 있다.
- 일반적으로 잘 사용하지 않음

@Component
public class OrderServiceImpl implements OrderService {

    private MemberRepository memberRepository;
    private DiscountPolicy discountPolicy;

    @Autowired
    public void init(MemberRepository memberRepository, DiscountPolicy
            discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }
}

[Spring] 싱글톤 컨테이너

제가안난데여♪(´ε｀*) — Wed, 26 Mar 2025 15:30:40 +0900

이 글은 인프런에서 김영한 님의 "스프링 핵심원리 - 기본편"을 수강 후 공부한 내용을 정리한 게시글입니다. 부족한 부분이 있다면 언제든 지적 부탁드립니다.

✏️ 싱글톤 패턴을 사용하는 이유

스프링 없는 순수한 DI 컨테이너를 가진 어플리케이션을 사용자에게 배포 했다고 생각해보자.

그 어플리케이션이 대박이 나서 동시 접속자수가 만명이 넘는다.

그러면 만명 사용자가 동시다발적으로 서버에 요청을 보내게 된다.

이 어플리케이션에서의AppConfig 는 아래와 같다

package hello.core;
import hello.core.discount.DiscountPolicy;
import hello.core.discount.RateDiscountPolicy;import hello.core.member.MemberRepository;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import hello.core.member.MemoryMemberRepository;
import hello.core.order.OrderService;
import hello.core.order.OrderServiceImpl;

public class AppConfig {

    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }

    public OrderService orderService() {
        return new OrderServiceImpl(
                memberRepository(),
                discountPolicy());
    }

    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }

    public DiscountPolicy discountPolicy() {
        return new RateDiscountPolicy();
    }
}

이 때, 로그인을 만 명이 동시에 한다고 생각해보면 로그인이 기능이 있는 memberService() 메소드가 만번 실행되고 return new MemberServiceImpl(memberRepository()); 가 만 번 실행된다.

그러면 MemberServiceImpl 인스턴스가 만 개이 생성되게 된다. 또한 memberRepository()도 호출되면서 MemoryMemberRepostiory 인스턴스도 만 개가 생성된다.

이렇게 되면 메모리 낭비가 엄청나게 된다.

이를 해결하기 위해서 해당 객체의 인스턴스들을 1개만 생성해두고 공유해서 사용하도록 설계하면 된다.

그렇게 설계해둔 것이 싱글톤 패턴이다.

우리가 자바를 배우면서 변수를 공유 한다고 하면 떠오르는 키워드가 있을 것이다.

바로 static 이를 사용해서 딱 1개만 생성하여 사용하면 된다.

✏️ 싱글톤 패턴 구현

싱글톤 패턴

클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴을 말한다.
객체 인스턴스가 2개 이상 생성하지 못하도록 막아야 한다.
private 생성자를 사용해서 외부에서 임의로 new 키워드를 사용하지 못하도록 막는다.
인스턴스를 1개만 생성하여 공유해서 서용하도록 설계한다.
우리가 자바를 배우면서 변수를 공유 한다고 하면 떠오르는 키워드가 있을 것이다.
바로 static 이를 사용해서 딱 1개만 생성하여 사용하면 된다.

싱글톤 예제

package hello.core.singleton;
public class SingletonService {

	//1. static 영역에 객체를 딱 1개만 생성해둔다.
	private static final SingletonService instance = new SingletonService();

	//2. public으로 열어서 객체 인스턴스가 필요하면 이 static 메서드를 통해서만 조회하도록 허용한
	다.
	public static SingletonService getInstance() {
		return instance;
	}

	//3. 생성자를 private으로 선언해서 외부에서 new 키워드를 사용한 객체 생성을 못하게 막는다.
	private SingletonService() {
	}

	public void logic() {
		System.out.println("싱글톤 객체 로직 호출");
	}

}

static 영역에 객체 instance를 미리 하나 생성해서 올려둔다.
이 객체 인스턴스가 필요하면 오직 getInstance() 메서드를 통해서만 조회할 수 있다. 이 메서드를 호출하면 항상 같은 인스턴스를 반환한다.
딱 1개의 객체 인스턴스만 존재해야 하므로, 생성자를 private으로 막아서 혹시라도 외부에서 new 키워드로 객체 인스턴스가 생성되는 것을 막는다.

추가적으로 외부에서 SingletonService.getInstace() 를 통해 서비스를 호출하게 되면 같은 인스턴스를 반환해주는다는 것을 알 수 있다.

싱글톤 패턴의 문제점

싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다.
의존관계상 클라이언트가 구체 클래스에 의존한다. DIP를 위반한다.
클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다.
테스트하기 어렵다.
내부 속성을 변경하거나 초기화 하기 어렵다.
private 생성자로 자식 클래스를 만들기 어렵다.
결론적으로 유연성이 떨어진다

✏️ 스프링에서의 싱글톤 컨테이너

위와 같은 싱글톤 패턴의 문제점이 존재해서 스프링에서는 스프링 빈을 싱글톤으로 관리해준다.

싱글톤 컨테이너

스프링 컨테이너는 싱글턴 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리한다.
스프링 컨테이너는 싱글톤 컨테이너 역할을 한다. 이렇게 싱글톤 객체를 생성하고 관리하는 기능을 싱글톤 레지스트리라 한다.
스프링 컨테이너의 이런 기능 덕분에 싱글턴 패턴의 모든 단점을 해결하면서 객체를 싱글톤으로 유지할 수 있다.

스프링 컨테이너를 사용하는 테스트 코드

@Test
@DisplayName("스프링 컨테이너와 싱글톤")
void springContainer() {
		ApplicationContext ac = new
		AnnotationConfigApplicationContext(AppConfig.class);
		//1. 조회: 호출할 때 마다 같은 객체를 반환
		MemberService memberService1 = ac.getBean("memberService",
		MemberService.class);
		//2. 조회: 호출할 때 마다 같은 객체를 반환
		MemberService memberService2 = ac.getBean("memberService",
		MemberService.class);
		//참조값이 같은 것을 확인
		System.out.println("memberService1 = " + memberService1);
		System.out.println("memberService2 = " + memberService2);
		//memberService1 == memberService2
		assertThat(memberService1).isSameAs(memberService2);
}

✏️ 싱글톤 방식의 주의점

싱글톤 방식은 여러 클라이언트가 하나의 인스턴스를 공유하기 때문에 싱글톤 객체는 상태를 유지하게 설계하면 안된다!!
무상태(stateless)로 설계해야 한다.
스프링 빈의 필드에 공유 값을 설정하면 큰 장애가 발생!

상태를 유지할 경우 발생하는 문제점 예시

package hello.core.singleton;
public class StatefulService {
	private int price; //상태를 유지하는 필드
	public void order(String name, int price) {
		System.out.println("name = " + name + " price = " + price);
		this.price = price; //여기가 문제!
	}
	public int getPrice() {
		return price;
	}
}

package hello.core.singleton;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;
import org.springframework.context.ApplicationContext;
import
		org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Bean;
public class StatefulServiceTest {
	@Test
	void statefulServiceSingleton() {
		ApplicationContext ac = new
				AnnotationConfigApplicationContext(TestConfig.class);
		StatefulService statefulService1 = ac.getBean("statefulService",
				StatefulService.class);
		StatefulService statefulService2 = ac.getBean("statefulService",
				StatefulService.class);
		//ThreadA: A사용자 10000원 주문
		statefulService1.order("userA", 10000);
		//ThreadB: B사용자 20000원 주문
		statefulService2.order("userB", 20000);
		//ThreadA: 사용자A 주문 금액 조회
		int price = statefulService1.getPrice();
		//ThreadA: 사용자A는 10000원을 기대했지만, 기대와 다르게 20000원 출력
		System.out.println("price = " + price);
		Assertions.assertThat(statefulService1.getPrice()).isEqualTo(20000);
	}
	static class TestConfig {
		@Bean
		public StatefulService statefulService() {
			return new StatefulService();
		}
	}
}

ThreadA가 사용자A 코드를 호출하고 ThreadB가 사용자B 코드를 호출한다 가정하자.
StatefulService 의 price 필드는 공유되는 필드인데, 특정 클라이언트가 값을 변경한다.
사용자A의 주문 금액은 10000원이 되어야 하는데, 20000원이라는 결과가 나왔다.

✏️ @Configuration과 싱글톤

@Configuration
public class AppConfig {

	@Bean
	public MemberService memberService() {
		return new MemberServiceImpl(memberRepository());
	}

	@Bean
	public OrderService orderService() {
		return new OrderServiceImpl(
				memberRepository(),
				discountPolicy());
	}

	@Bean
	public MemberRepository memberRepository() {
		return new MemoryMemberRepository();
	}

 ...
}

memberService 빈을 만드는 코드를 보면 memberRepository() 를 호출한다.

이 메서드를 호출하면 new MemoryMemberRepository() 를 호출한다.

orderService 빈을 만드는 코드도 동일하게 memberRepository() 를 호출한다.

이 메서드를 호출하면 new MemoryMemberRepository() 를 호출한다.

결과적으로 각각 다른 2개의 MemoryMemberRepository 가 생성되면서 싱글톤이 깨지는 것 처럼 보인다.

그러나 실질적으로는 memberRepository 인스턴스는 1개의 인스터스로 공유되어 사용되어진다.

그래서 스프링은 클래스의 바이트코드를 조작하는 라이브러리를 사용한다.

모든 비밀은 @Configuration 을 적용한 AppConfig 에 있다.

그렇게 될 수 있는 이유는 스프링 컨테이너가 싱글톤 레지스트리이기 때문이다. 따라스 스프링 빈이 싱글톤이 되도록 보장 해준다.

그렇다면 스프링 빈이면 무조건 싱글톤일까 ?

그것도 아니다. @Bean만 사용해도 스프링 빈으로 등록되지만, 싱글톤을 보장하지 않는다.

@Configuration 을 붙이면 바이트코드를 조작하는 CGLIB 기술을 사용하기 때문에 싱글톤을 보장하는데 CGLIB 기술 없이 빈을 등록하면 순수한 AppConfig로 스프링 빈에 등록된다.

그렇다면 CGLIB는 무엇일까 ?

빈으로 등록될때 CGLIB라는 바이트코드 조작 라이브러리를 사용해서 내가 생성한 클래스를 상속 받은 임의의 다른 클래스를 만들고 그 클래스를 스프링 빈으로 등록한다.

그리고 등록한 그 클래스가 싱글톤이 되도록 보장해준다. CGLIB 내부에서 해당하는 스프링 빈이 존재하면 존재하는 빈을 반환하고 없으면 스프링빈으로 등록하는 내부 로직이 있기 때문에 싱글톤이 보장 될 수 있다.

@Configuration 을 적용하지 않고, @Bean 만 적용하면 어떻게 될까?

@Configuration 을 붙이면 바이트코드를 조작하는 CGLIB 기술을 사용해서 싱글톤을 보장하지만, 만약 @Bean만 적용하면 어떻게 될까?

CGLIB 기술 없이 순수한 AppConfig로 스프링 빈에 등록된다.

[Spring] 스프링 컨테이너와 스프링 빈

제가안난데여♪(´ε｀*) — Wed, 26 Mar 2025 15:27:51 +0900

이 글은 인프런에서 김영한 님의 "스프링 핵심원리 - 기본편"을 수강 후 공부한 내용을 정리한 게시글입니다. 부족한 부분이 있다면 언제든 지적 부탁드립니다.

✏️ 스프링 컨테이너

AppConfig

package hello.core;
import hello.core.discount.DiscountPolicy;
import hello.core.discount.RateDiscountPolicy;import hello.core.member.MemberRepository;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import hello.core.member.MemoryMemberRepository;
import hello.core.order.OrderService;
import hello.core.order.OrderServiceImpl;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
@Configuration
public class AppConfig {
    @Bean
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }
    @Bean
    public OrderService orderService() {
        return new OrderServiceImpl(
                memberRepository(),
                discountPolicy());
    }
    @Bean
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }
    @Bean
    public DiscountPolicy discountPolicy() {
        return new RateDiscountPolicy();
    }
}

스프링 컨테이너 생성

//스프링 컨테이너 생성
ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);

ApplicationContext 는 인터페이스이며 스프링 컨테이너라 한다.
스프링 컨테이너는 XML을 기반으로 만들 수 있고, 애노테이션 기반의 자바 설정 클래스로 만들 수 있다.
직전에 AppConfig 를 사용했던 방식이 애노테이션 기반의 자바 설정 클래스로 스프링 컨테이너를 만든 것이다.
AnnotationConfigApplicationContext는 ApplicationContext의 인터페이의 구현체
스프링 컨테이너를 생성할 때는 구성 정보 (= AppConfig.class (빈 관계 정보))를 지정해주어야 한다.
스프링 컨테이너의 스프링 빈 저장소에 빈 이름을 key로 빈 객체를 value로 하여 스프링 빈을 등록한다
빈 이름은 메서드 이름을 사용한다. ( 경우에 따라 빈 이름을 직접 부여할 수 있다. )
빈 이름은 유일해야한다.(유니크 해야한다.)
스프링 컨테이너는 설정 정보(= AppConfig.class )를 참고해서 의존관계를 주입(DI) 한다.

✏️ 스프링 빈 조회

기본

package hello.core.beanfind;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.config.BeanDefinition;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import static org.assertj.core.api.Assertions.assertThat;
class ApplicationContextInfoTest {

	AnnotationConfigApplicationContext ac = new
			AnnotationConfigApplicationContext(AppConfig.class);

	@Test
	@DisplayName("모든 빈 출력하기")
	void findAllBean() {
		String[] beanDefinitionNames = ac.getBeanDefinitionNames();
		for (String beanDefinitionName : beanDefinitionNames) {
			Object bean = ac.getBean(beanDefinitionName);
			System.out.println("name=" + beanDefinitionName + " object=" +
					bean);
		}
	}

	@Test
	@DisplayName("애플리케이션 빈 출력하기")
	void findApplicationBean() {
		String[] beanDefinitionNames = ac.getBeanDefinitionNames();
		for (String beanDefinitionName : beanDefinitionNames) {
			BeanDefinition beanDefinition =
					ac.getBeanDefinition(beanDefinitionName);
			//Role ROLE_APPLICATION: 직접 등록한 애플리케이션 빈
			//Role ROLE_INFRASTRUCTURE: 스프링이 내부에서 사용하는 빈
			if (beanDefinition.getRole() == BeanDefinition.ROLE_APPLICATION) {
				Object bean = ac.getBean(beanDefinitionName);
				System.out.println("name=" + beanDefinitionName + " object=" +
						bean);
			}
		}

	}
}

ac.getBeanDefinitionNames() : 스프링에 등록된 모든 빈 이름을 조회한다.
ac.getBean() : 빈 이름으로 빈 객체(인스턴스)를 조회한다.
- ac.getBean(빈이름, 타입)
- ac.getBean(타입)
- 조회 대상 스프링 빈이 없으면 예외 발생NoSuchBeanDefinitionException: No bean named 'xxxxx' available
스프링이 내부에서 사용하는 빈은 getRole() 로 구분할 수 있다.
ROLE_APPLICATION : 일반적으로 사용자가 정의한 빈
ROLE_INFRASTRUCTURE : 스프링이 내부에서 사용하는 빈

동일한 타입이 둘 이상

MemberRepository memberRepository = ac.getBean("memberRepository1", MemberRepository.class);

타입으로 조회시 같은 타입의 스프링 빈이 둘 이상이면 오류가 발생한다. 이때는 빈 이름을 지정하자.
ac.getBeansOfType() 을 사용하면 해당 타입의 모든 빈을 조회할 수 있다.

상속 관계

부모 타입으로 빈을 조회하면, 자식 타입도 빈도 함께 조회한다.
그래서 모든 자바 객체의 최고 부모인 Object 타입으로 조회하면, 모든 스프링 빈을 조회한다.

✏️ BeanFactory와 ApplicationContext

BeanFactory

스프링 컨테이너의 최상위 인터페이스
스프링 빈을 관리하고 조회하는 역할을 담당
getBean() 제공

ApplicationContext

BeanFactory 기능을 모두 상속받아서 제공
빈을 관리하고 조회하는 기능과 같이 수 많은 부가기능을 제공
BeanFactory를 직접 사용할 일은 거의 없다. 부가기능이 포함된 ApplicationContext를 사용
메시지소스를 활용한 국제화 기능
환경변수 기능을 제공하여 로컬, 개발, 운영등을 구분해서 처리
애플리케이션 이벤트 기능을 통해 이벤트를 발행하고 구독하는 모델을 편리하게 지원
편리한 리소스 조회하는 기능을 제공하여 파일, 클래스패스, 외부 등에서 리소스를 편리하게 조회

✏️ 다양한 설정 형식 지원 - 자바 코드, XML

애노테이션 기반 자바 코드 설정 사용

new AnnotationConfigApplicationContext(AppConfig.class)

XML 설정 사용

GenericXmlApplicationContext 사용해서 xml 설정 파일을 지정

package hello.core.xml;
import hello.core.member.MemberService;
import org.junit.jupiter.api.Test;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.GenericXmlApplicationContext;
import static org.assertj.core.api.Assertions.*;
public class XmlAppContext {
	@Test
	void xmlAppContext() {
		ApplicationContext ac = new
				GenericXmlApplicationContext("appConfig.xml");

		MemberService memberService = ac.getBean("memberService",
				MemberService.class);
		assertThat(memberService).isInstanceOf(MemberService.class);
	}
}

✏️ 스프링 빈 설정 메타 정보 - BeanDefinition

BeanDefinition 추상화를 이용하여 구현 객체를 다양한 설정 형식에 맞게 바꿔 끼울 수 있다.
BeanDefinition 을 빈 설정 메타정보라 한다.
@Bean , 당 각각 하나씩 메타 정보가 생성된다.
스프링 컨테이너는 이 메타정보를 기반으로 스프링 빈을 생성한다.
AnnotationConfigApplicationContext는 AnnotatedBeanDefinitionReader를 사용해서 AppConfig.class 를 읽고 BeanDefinition 을 생성한다.

[Spring] 스프링의 핵심 원리 이해2 - 객체 지향 원리 적용

제가안난데여♪(´ε｀*) — Wed, 26 Mar 2025 15:26:41 +0900

이 글은 인프런에서 김영한 님의 "스프링 핵심원리 - 기본편"을 수강 후 공부한 내용을 정리한 게시글입니다. 부족한 부분이 있다면 언제든 지적 부탁드립니다.

✏️ 비즈니스 설계 Remind

✏️ DIP, OCP 위반 상황 설명

지난 시간에는 정액 할인 정책만 구현하여 의존해두었는데 요구 사항이 정률 할인 정책으로 변경되었다.

변경에 따라 RateDiscountPolicy를 구현하고 할인 정책을 변경하려면 클라이언트인 OrderServiceImpl코드를 고쳐야 한다.

public class OrderServiceImpl implements OrderService {
		// private final DiscountPolicy discountPolicy = new FixDiscountPolicy();
		private final DiscountPolicy discountPolicy = new RateDiscountPolicy();
}

이렇게 될 경우 DIP, OCP 를 위반하게 되는 문제가 발생된다!

DIP (의존관계 역전 원칙) : 추상화에 의존 해야 한다.
- 주문서비스 클라이언트( OrderServiceImpl)는 DiscountPolicy인터페이스에 의존하면서 DIP를 지킨 것 같아 보이지만 클래스 의존관계를 분석해보면 추상(인터페이스) 뿐만 아니라 구체(구현) 클래스에도 의존하고 있다. ⇒ DIP 위반 !→ 구체(구현) 클래스: FixDiscountPolicy, RateDiscountPolicy
- ![image](<https://github.com/SpringSync/Spring-Basic/assets/99172832/26a873ff-8b3b-4b1b-a3c3-9718ecfda683>) ![image](<https://github.com/SpringSync/Spring-Basic/assets/99172832/19e4c289-e6c9-4fbf-997f-6f91354fafe9>) 위 그림처럼 의존되어 있다고 생각하지만 실제로는 아래 그림처럼 의존되어있다.
- → 추상(인터페이스) 의존: DiscountPolicy
OCP (개방폐쇄의 원칙) : 확장에는 열려있으나 변경에는 닫혀 있어야 한다.
- 지금 코드는 기능을 확장해서 변경하면, 클라이언트 코드에 영향을 준다! 즉, FixDiscountPolicy를 RateDiscountPolicy로 변경하는 순간 OrderServiceImpl의 소스
- 코드도 함께 변경해야 한다! ⇒ OCP 위반!

이를 해결하기 위해서는 ?

인터페이스(추상)에만 의존하도록 변경해야한다!
public class OrderServiceImpl implements OrderService { //private final DiscountPolicy discountPolicy = new RateDiscountPolicy(); private DiscountPolicy discountPolicy; }
위 코드는 인터페이스에만 의존하도록 코드를 변경하였지만 구현체가 없어서 NullPointException이 발생한다.
이를 해결하기 위해서는 누군가가 클라이언트인 OrderServiceImpl 에 DiscountPolicy의 구현 객체를 대신 생성하고 주입해주어야 한다. 그 역할을 하는 것이 다음에 알아 볼 AppConfig이다.

✏️ 관심사 분리 - AppConfig

관심사 분리

주문에 대한 서비스와 멤버를 관리하는 서비스가 각각의 역할(인터페이스)를 하듯이 구현 객체를 생성하고 연결하는 역할을 하는 클래스를 별도로 만들어서 관심사를 분리해야 한다.

애플리케이션의 전체 동작 방식을 구성(config)하기 위해, 구현 객체를 생성하고, 연결하는 책임을 가지는 별도의 설정 클래스인 AppConfig를 만들어보자.

AppConfig

위 사진과 같이 AppConfig가 MemberServiceImpl과 MemoryMemberRepository와 같이 구현 객체를 생성하여 주입해줄 수 있도록 만들어 볼 것이다.

어떻게 하느냐?

AppConfig 에서 MemberService 구현 객체를 생성해서 반환하는 메소드를 만들어 둘 것이다. → memberService()

package hello.core;
import hello.core.discount.FixDiscountPolicy;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import hello.core.member.MemoryMemberRepository;
import hello.core.order.OrderService;
import hello.core.order.OrderServiceImpl;
public class AppConfig {

    public MemberService memberService() {
        return new MemberServiceImpl(new MemoryMemberRepository());
    }

    public OrderService orderService() {
        return new OrderServiceImpl(
                new MemoryMemberRepository(),
                new FixDiscountPolicy());
    }

}

위 코드의 memberService() 메소드를 설명하면 MemberServie의 구현 객체인 MemberServiceImpl 를 생성하여 반환하는 메소드 이다.

이 메소드를 통해서 처음 어플리케이션이 실행되면서 MemberService 가 생성되어야 할 때 MemberServiceImpl을 생성하고 주입할 수 있다.

orderService() 메소드 또한 OrderService 구현 객체인 OrderServiceImpl를 생성하여 반환하는 메소드이다.

MemberServiceImpl - 생성자 주입

Appconfig의 memberService()

public MemberService memberService() {
        return new MemberServiceImpl(new MemoryMemberRepository());
}

AppConfig에서 MemberServiceImpl를 생성하면서 MemberRepository의 구현 객체인 MemoryMemberRepository 객체를 생성하고 주입하고 있다.

즉 참조값을 생성자를 통해서 전달하고 있다.

이렇게 객체를 생성하면서 주입하기 위해서는 MemberServiceImpl의 생성자 메소드에서 파라미터를 MemberRepositoy로 받고 있어야 한다.

package hello.core.member;

public class MemberServiceImpl implements MemberService {

    private final MemberRepository memberRepository;

    public MemberServiceImpl(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }

		. . .

}

MemberRepositroy의 구현객체의 생성은 AppConfig에서만 일어날 뿐 MemberServiceImpl에서는 넣어준 객체를 주입만 한다.

MemberServiceImpl입장에서 생성자를 통해 어떤 구현 객체가 들어올지(주입될지)는 알 수 없다. 어떤 구현 객체를 주입할지는 오직 외부( AppConfig)에서 결정된다. 그렇기 때문에 MemberServiceImpl 은 이제부터 의존관계에 대한 고민은 외부(AppConfig)에 맡기고 실행에만 집중하면 된다.

클라이언트인 memberServiceImpl 입장에서 보면 의존관계를 마치 외부에서 주입해주는 것 같다고 해 DI(Dependency Injection) 우리말로 의존관계 주입 또는 의존성 주입이라 한다

[객체를 생성하고 연결하는 역할]과 [실행하는 역할]이 명확하게 분리 되었다.

결과적으로 MemberServiceImpl인 구현 객체는 MemberRepository인 인터페이스에만 의존하게 된다. ⇒ DIP 완성!

OrderServiceImpl - 생성자 주입

AppConfig - orderService()

public OrderService orderService() {
        return new OrderServiceImpl(
                new MemoryMemberRepository(),
                new FixDiscountPolicy());
}

package hello.core.order;
import hello.core.discount.DiscountPolicy;
import hello.core.member.Member;
import hello.core.member.MemberRepository;

public class OrderServiceImpl implements OrderService {

    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;

    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy
            discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }
		. . .
}

설계 변경으로 OrderServiceImpl 은 FixDiscountPolicy 를 의존하지 않는다!
단지 DiscountPolicy 인터페이스만 의존한다.
즉 구현객체에 의존하지 않고 인터페이스에만 의존한다.
OrderServiceImpl 입장에서 생성자를 통해 어떤 구현 객체가 들어올지(주입될지)는 알 수 없다.
OrderServiceImpl 의 생성자를 통해서 어떤 구현 객체을 주입할지는 오직 외부( AppConfig)에서 결정한다.
OrderServiceImpl 은 이제부터 실행에만 집중하면 된다.
OrderServiceImpl 에는 MemoryMemberRepository , FixDiscountPolicy 객체의 의존관계가 주입된다.

실행

package hello.core;
import hello.core.member.Grade;
import hello.core.member.Member;
import hello.core.member.MemberService;
public class MemberApp {
    public static void main(String[] args) {
        AppConfig appConfig = new AppConfig();
        MemberService memberService = appConfig.memberService();
        Member member = new Member(1L, "memberA", Grade.VIP);
        memberService.join(member);
        Member findMember = memberService.findMember(1L);
        System.out.println("new member = " + member.getName());
        System.out.println("find Member = " + findMember.getName());
    }
}

package hello.core;
import hello.core.member.Grade;
import hello.core.member.Member;
import hello.core.member.MemberService;
import hello.core.order.Order;
import hello.core.order.OrderService;
public class OrderApp {
    public static void main(String[] args) {
        AppConfig appConfig = new AppConfig();
        MemberService memberService = appConfig.memberService();
        OrderService orderService = appConfig.orderService();
        long memberId = 1L;
        Member member = new Member(memberId, "memberA", Grade.VIP);
        memberService.join(member);
        Order order = orderService.createOrder(memberId, "itemA", 10000);
        System.out.println("order = " + order);
    }
}

정리

객체의 생성과 연결은 AppConfig가 담당한다.
AppConfig 는 어플리케이션의 실제 동작에 필요한 구현 객체를 “생성”한다.
- MemberServiceImpl
- MemoryMemberRepository
- OrderServiceImpl
- FixDiscountPolicy
AppConfig는 생성한 객체 인스턴스의 참조(레퍼런스)를 생성자를 통해서 주입(연결)해준다.
- MemberServiceImpl → MemoryMemberRepository
- OrderServiceImpl → MemoryMemberRepository , FixDiscountPolicy

AppConfig 리팩토링

new MemoryMemberRepository() 이 부분이 중복 제거되었다. 이제 MemoryMemberRepository 를다른 구현체로 변경할 때 한 부분만 변경하면 된다.
AppConfig 를 보면 역할과 구현 클래스가 한눈에 들어온다. 애플리케이션 전체 구성이 어떻게 되어있는지 빠르게 파악할 수 있다.

package hello.core;
import hello.core.discount.DiscountPolicy;
import hello.core.discount.FixDiscountPolicy;
import hello.core.member.MemberRepository;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import hello.core.member.MemoryMemberRepository;
import hello.core.order.OrderService;
import hello.core.order.OrderServiceImpl;
public class AppConfig {

    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }

    public OrderService orderService() {
        return new OrderServiceImpl(
                memberRepository(),
                discountPolicy());
    }

    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }

    public DiscountPolicy discountPolicy() {
        return new FixDiscountPolicy();
    }
}

✏️ 새로운 구조

AppConfig의 등장으로 애플리케이션이 크게 사용 영역과, 객체를 생성하고 구성(Configuration)하는 영역으로 분

리되었다.

FixDiscountPolicy RateDiscountPolicy 로 변경해도 구성 영역만 영향을 받고, 사용 영역은 전혀

영향을 받지 않는다.

AppConfig의 discountPolicy()

public DiscountPolicy discountPolicy() {
		// return new FixDiscountPolicy();
		 return new RateDiscountPolicy();
}

이제 할인 정책을 변경해도, 애플리케이션의 구성 역할을 담당하는 AppConfig만 변경하면 된다. 클라이언트 코드인 OrderServiceImpl 를 포함해서 사용 영역의 어떤 코드도 변경할 필요가 없다.

위와 같이 AppConfig 코드만 변경해주면 주입관계가 위 사진과 같이 변경된다.

✏️ 좋은 객체 지향 설계를 하고 있을까?

SRP 단일 책임 원칙

한 클래스는 하나의 책임만 가져야 한다.

구현 객체를 생성하고 연결하는 책임은 AppConfig가 담당

클라이언트 객체는 실행하는 책임만 담당

OCP 개방 폐쇄의 원칙

소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.

AppConfig가 FixDiscountPolicy 객체 인스턴스를 클라이언트 코드 대신 생성해서 클라이언트 코드에 의존관계를 주입했다.

DIP 의존 관계 역전 원칙

추상화에 의존해야지, 구체화에 의존하면 안된다.

AppConfig가 의존관계를 FixDiscountPolicy → RateDiscountPolicy 로 변경해서 클라이언트 코드에 주입하므로 클라이언트 코드는 변경하지 않아도 됨

제어의 역전 IoC(Inversion of Control)

기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성하고, 연결하고, 실행했다. → 구현 객체가 프로그램의 제어 흐름을 스스로 조종
반면에 AppConfig가 등장한 이후에 구현 객체는 자신의 로직을 실행하는 역할만 담당한다. 프로그램의 제어 흐름은 이제 AppConfig가 가져간다. 예를 들어서 OrderServiceImpl 은 필요한 인터페이스들을 호출하지만 어떤 구현 객체들이 실행될지 모른다.
프로그램에 대한 제어 흐름에 대한 권한은 모두 AppConfig가 가지고 있다. 심지어 OrderServiceImpl 도AppConfig가 생성한다. 그리고 AppConfig는 OrderServiceImpl 이 아닌 OrderService 인터페이스의 다른 구현 객체를 생성하고 실행할 수 도 있다. 그런 사실도 모른체 OrderServiceImpl 은 묵묵히 자신의 로직을 실행할 뿐이다.
이렇듯 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 제어의 역전(IoC)이라 한다.

+) 프레임워크 vs 라이브러리

프레임워크가 내가 작성한 코드를 제어하고, 대신 실행하면 그것은 프레임워크가 맞다. (JUnit)
반면에 내가 작성한 코드가 직접 제어의 흐름을 담당한다면 그것은 프레임워크가 아니라 라이브러리다.

의존관계 주입 DI(Dependency Injection)

정적인 클래스 의존관계

클래스가 사용하는 import 코드만 보고 의존관계를 판단

동적인 객체 인스턴스 의존 관계

애플리케이션 실행 시점에 실제 생성된 객체 인스턴스의 참조가 연결된 의존 관계
애플리케이션 실행 시점(런타임)에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서 클라이언트와 서버의 실제 의존관계가 연결 되는 것을 의존관계 주입이라 한다.
객체 인스턴스를 생성하고, 그 참조값을 전달해서 연결된다.
의존관계 주입을 사용하면 클라이언트 코드를 변경하지 않고, 클라이언트가 호출하는 대상의 타입 인스턴스를 변경할 수 있다.
의존관계 주입을 사용하면 정적인 클래스 의존관계를 변경하지 않고, 동적인 객체 인스턴스 의존관계를 쉽게 변경할 수 있다.

IoC 컨테이너, DI 컨테이너

AppConfig 처럼 객체를 생성하고 관리하면서 의존관계를 연결해 주는 것을 IoC 컨테이너 또는 DI 컨테이너라 한다.

✏️ 스프링으로 전환

AppConfig 스프링 기반으로 변경

package hello.core;
import hello.core.discount.DiscountPolicy;
import hello.core.discount.RateDiscountPolicy;import hello.core.member.MemberRepository;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import hello.core.member.MemoryMemberRepository;
import hello.core.order.OrderService;
import hello.core.order.OrderServiceImpl;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
@Configuration
public class AppConfig {
    @Bean
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }
    @Bean
    public OrderService orderService() {
        return new OrderServiceImpl(
                memberRepository(),
                discountPolicy());
    }
    @Bean
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }
    @Bean
    public DiscountPolicy discountPolicy() {
        return new RateDiscountPolicy();
    }
}

설정을 구성한다는 뜻의 @Configuration 을 붙여준다.
메서드에 @Bean 을 붙여준다. 이렇게 하면 스프링 컨테이너에 스프링 빈으로 등록한다.

MemberApp에 스프링 컨테이너 적용

package hello.core;
import hello.core.member.Grade;
import hello.core.member.Member;
import hello.core.member.MemberService;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
public class MemberApp {
    public static void main(String[] args) {
// AppConfig appConfig = new AppConfig();
// MemberService memberService = appConfig.memberService();
        ApplicationContext applicationContext = new
                AnnotationConfigApplicationContext(AppConfig.class);
        MemberService memberService =
                applicationContext.getBean("memberService", MemberService.class);
        Member member = new Member(1L, "memberA", Grade.VIP);
        memberService.join(member);
        Member findMember = memberService.findMember(1L);
        System.out.println("new member = " + member.getName());
        System.out.println("find Member = " + findMember.getName());
    }
}

OrderApp에 스프링 컨테이너 적용

package hello.core;
import hello.core.member.Grade;
import hello.core.member.Member;
import hello.core.member.MemberService;
import hello.core.order.Order;
import hello.core.order.OrderService;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
public class OrderApp {
    public static void main(String[] args) {
// AppConfig appConfig = new AppConfig();
// MemberService memberService = appConfig.memberService();
// OrderService orderService = appConfig.orderService();
        ApplicationContext applicationContext = new
                AnnotationConfigApplicationContext(AppConfig.class);
        MemberService memberService =
                applicationContext.getBean("memberService", MemberService.class);
        OrderService orderService = applicationContext.getBean("orderService",
                OrderService.class);
        long memberId = 1L;
        Member member = new Member(memberId, "memberA", Grade.VIP);
        memberService.join(member);
        Order order = orderService.createOrder(memberId, "itemA", 10000);
        System.out.println("order = " + order);
    }
}

스프링 컨테이너

ApplicationContext 를 스프링 컨테이너라 한다.기존에는 개발자가 AppConfig 를 사용해서 직접 객체를 생성하고 DI를 했지만, 이제부터는 스프링 컨테이너를 통해서 사용한다.
스프링 컨테이너는 @Configuration이 붙은 AppConfig 를 설정(구성) 정보로 사용한다. 여기서 @Bean 이라 적힌 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록한다. 이렇게 스프링 컨테이너에 등록된객체를 스프링 빈이라 한다.
스프링 빈은 @Bean 이 붙은 메서드의 명을 스프링 빈의 이름으로 사용한다. ( memberService , orderService )
이전에는 개발자가 필요한 객체를 AppConfig 를 사용해서 직접 조회했지만, 이제부터는 스프링 컨테이너를 통해서 필요한 스프링 빈(객체)를 찾아야 한다. 스프링 빈은 applicationContext.getBean() 메서드를 사용해서 찾을 수 있다.
기존에는 개발자가 직접 자바코드로 모든 것을 했다면 이제부터는 스프링 컨테이너에 객체를 스프링 빈으로 등록하고, 스프링 컨테이너에서 스프링 빈을 찾아서 사용하도록 변경되었다

[백준 Java] 1407번 2로 몇 번 나누어질까

제가안난데여♪(´ε｀*) — Sun, 23 Mar 2025 22:43:38 +0900

문제

[Gold IV] 2로 몇 번 나누어질까 - 1407

문제 링크

성능 요약

메모리: 11552 KB, 시간: 76 ms

풀이

범위가 무려 1≤A≤B≤1015 로 엄청나다.

그래서 A ~ B 까지 순회하면서 더할 수는 없다.

1 ~ n까지 소수 x의 배수의 개수를 구하는 방식을 이용하였다.

1 ~ n까지 수들은 소수 x로 몇번 나누어 떨어질까 ?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

- 1 - 2 - 1 - 3 - 1 - 2 - 1 - 4 - 1 - 2

1부터 20까지 순회하며 각 수를 소인수분해 했을때 2가 몇 번씩 들어가는지 적어보았다.

이를 2가 들어간 횟수만큼 동그라미로 표현하게 되면 아래 사진과 같이 표시되며 오른쪽과 같은 의미를 가질 수 있다.

위를 참고하여

| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 |

2로 나누어 지지 않는 수(홀수)는 20=1인 2의 거듭제곱 꼴 중 가장 큰 약수를 가진다.

그러면 여기서 홀수의 개수는 어떻게 구할까 ?

ceil(20/2) = 10

| 2 | 4 | 6 | 8 | 10 | 12 | 14 | 16 | 18 | 20 |

4로 나누어 지지 않는 수는 21=2인 2의 거듭제곱 꼴 중 가장 큰 약수를 가진다.

그러면 여기서 4로 나누어 지지 않는 수의 개수는 어떻게 구할까 ?

ceil(10/2) = 5

| 4 | 8 | 12 | 16 | 20 |

8로 나누어 지지 않는 수는 22=4인 2의 거듭제곱 꼴 중 가장 큰 약수를 가진다.

그러면 여기서 8로 나누어 지지 않는 수의 개수는 어떻게 구할까 ?

ceil(5/2) = 3 (이런 경우 때문에 올림을 해야한다)

| 8 | 16 |

16로 나누어 지지 않는 수는 23=8인 2의 거듭제곱 꼴 중 가장 큰 약수를 가진다.

그러면 여기서 8로 나누어 지지 않는 수의 개수는 어떻게 구할까 ?

ceil(2/2) = 1

| 16 |

32로 나누어 지지 않는 수는 24=16인 2의 거듭제곱 꼴 중 가장 큰 약수를 가진다.

그러면 여기서 16로 나누어 지지 않는 수의 개수는 어떻게 구할까 ?

ceil(1/2) = 1

이렇게 20 ~ 24 들을 가장 큰 약수로 가지는 수들의 개수를 각각 알아봤다.

이 수를 다 더하면

110 + 25 + 43 + 81 + 16*1 = 56

이며 이 숫자는 1 ~ 20까지의 2의 거듭제곱큰약수들의 합이 된다.

이를 이용하여 1 ~ B 에서 1 ~ A-1을 빼주면 A~B까지의 합을 구할 수 있다.

f(B) - f(A-1)

‍ 코드

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.StringTokenizer;

public class Main_1407 {
    static long A;
    static long B;

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());

        A = Long.parseLong(st.nextToken());
        B = Long.parseLong(st.nextToken());

        // A부터 B까지의 수 중 2의 거듭제곱 꼴이면서 가장 큰 약수를 찾아 더하여 출력
        System.out.println(twoCount(B) - twoCount(A - 1));
    }

    /**
     * A부터 B까지의 수 중 2의 거듭제곱 꼴이면서 가장 큰 약수를 찾아 더하는 메서드
     *
     * @param n 약수를 찾을 대상 숫자
     * @return 2의 거듭제곱 꼴이면서 가장 큰 약수를 찾아 더한 결과
     */
    private static long twoCount(long n) {
        long result = 0;
        long divisor = 1;

        // 2의 거듭제곱 꼴이면서 가장 큰 약수를 찾기 위한 반복문
        while (n > 0) {
            // 현재의 divisor로 나누어지지 않는 숫자의 가장 큰 약수를 찾아 더함
            long indivisibleNumberCnt = n / divisor;

            // 결과에 현재 divisor와 가장 큰 약수를 곱하여 누적
            result += divisor * indivisibleNumberCnt;

            // 다음 거듭제곱으로 이동
            divisor *= 2;
        }
        return result;
    }
}

[ 참고 ]

[Docker] permission denied while trying to connect to the Docker daemon socket at unix 에러 해결

제가안난데여♪(´ε｀*) — Sun, 23 Mar 2025 22:26:32 +0900

Docker를 컨테이너에서 실행하거나, 호스트의 Docker 소켓(/var/run/docker.sock)을 컨테이너에 마운트하여 사용하는 경우, 예상치 못한 권한 문제로 인해 Docker 명령이 작동하지 않을 때가 있습니다. 이 글에서는 Docker 소켓 접근 권한 문제를 해결하는 방법을 단계별로 안내합니다.

1. 증상

[runner@ae8762224dd7 /]$ docker ps
permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.45/containers/json": dial unix /var/run/docker.sock: connect: permission denied

Docker가 설치된 것 같지만, docker 명령이 제대로 실행되지 않는 경우가 있습니다. 이 문제는 주로 Docker 소켓 파일(/var/run/docker.sock)의 소유권 문제로 발생합니다.

2. 원인

Docker 데몬은 Unix 소켓을 통해 명령을 수신하며, /var/run/docker.sock 파일에 대해 읽기 및 쓰기 권한을 가진 사용자나 그룹만 Docker 명령을 사용할 수 있습니다. 이 소켓 파일은 기본적으로 docker 그룹에 속한 사용자만 접근할 수 있도록 설정되어 있습니다. 따라서, 소켓 파일에 접근하려는 사용자가 docker 그룹에 속해 있지 않다면 Docker 명령이 작동하지 않습니다.

3. 해결 방법

1) Docker 소켓의 소유 계정과 그룹 확인

우선, /var/run/docker.sock의 소유자와 그룹을 확인합니다.

ls -l /var/run/docker.sock

출력 예시는 다음과 같을 수 있습니다:

srw-rw---- 1 docker docker 0 Nov  4 12:00 /var/run/docker.sock

여기서 docker:docker는 소켓 파일의 소유자와 소유 그룹입니다. 즉, Docker 소켓에 접근하려면 docker 그룹에 속해 있어야 합니다.

2) 사용자 추가 및 그룹 변경

Docker 소켓 파일을 사용하려는 계정이 docker 그룹에 속해 있지 않다면, 동일한 그룹을 가진 계정을 생성하거나, 현재 계정을 docker 그룹에 추가합니다.

예를 들어, 소켓 파일의 소유주가 docker:docker라면, 다음 명령어로 docker 사용자 계정을 만들고 전환하여 문제를 해결할 수 있습니다.

3) 현재 사용자에게 docker 그룹 추가

만약 현재 사용 중인 계정으로 Docker에 접근하고 싶다면, 현재 계정을 docker 그룹에 추가합니다.

# 현재 계정이 docker 그룹에 속해 있도록 설정합니다.
usermod -aG docker $(whoami)

그룹 설정을 변경한 후에는 로그아웃했다가 다시 로그인하거나, newgrp docker 명령을 사용하여 변경 사항을 적용합니다.

4) Docker 실행 확인

설정이 완료되면 docker 명령어가 정상적으로 작동하는지 확인합니다.

docker --version

정상적으로 Docker 버전 정보가 출력되면 설정이 완료된 것입니다.

정리

Docker 소켓 파일(/var/run/docker.sock)의 소유자와 소유 그룹을 확인합니다.
필요한 경우 docker 그룹과 동일한 계정을 생성하거나 현재 계정을 docker 그룹에 추가하여 권한 문제를 해결합니다.
그룹 변경 후 Docker 명령이 작동하는지 확인합니다.

위의 단계를 따라 권한 문제를 해결하면 Docker 명령을 정상적으로 사용할 수 있을 것입니다.

[참고] centos 버전을 7이 아닌 8을 사용하는 이유 : /actions-runner/externals/node20/bin/node: /lib64/libm.so.6: version GLIBC_2.27' not found (required by /actions-runner/externals/node20/bin/node)

제가안난데여♪(´ε｀*) — Sun, 23 Mar 2025 22:25:48 +0900

Self-hosted runner 를 구축하기 위해서 Centos7을 컨테이너로 띄웠고 ci/cd 파이프라인을 도는 과정에서 오류가 발생하였다.

발생 오류

  Run actions/checkout@v2
    with:
      repository:
      token: ***
      ssh-strict: true
      persist-credentials: true
      clean: true
      fetch-depth: 1
      lfs: false
      submodules: false
      set-safe-directory: true
  /actions-runner/externals/node20/bin/node: /lib64/libm.so.6: version GLIBC_2.27' not found (required by /actions-runner/externals/node20/bin/node)
  /actions-runner/externals/node20/bin/node: /lib64/libstdc++.so.6: version GLIBCXX_3.4.20' not found (required by /actions-runner/externals/node20/bin/node)
  /actions-runner/externals/node20/bin/node: /lib64/libstdc++.so.6: version CXXABI_1.3.9' not found (required by /actions-runner/externals/node20/bin/node)
  /actions-runner/externals/node20/bin/node: /lib64/libstdc++.so.6: version GLIBCXX_3.4.21' not found (required by /actions-runner/externals/node20/bin/node)
  /actions-runner/externals/node20/bin/node: /lib64/libc.so.6: version GLIBC_2.28' not found (required by /actions-runner/externals/node20/bin/node)
  /actions-runner/externals/node20/bin/node: /lib64/libc.so.6: version GLIBC_2.25' not found (required by /actions-runner/externals/node20/bin/node)

발생 원인

에러 메시지는 GitHub Actions 러너가 사용하는 Node.js 실행 파일이 필요로 하는 여러 라이브러리 버전이 현재 CentOS 7 시스템에 설치된 버전보다 낮기 때문에 발생하고 있습니다. 각 라이브러리의 요구사항은 다음과 같습니다:

GLIBC: GNU C Library로, 시스템의 기본 라이브러리입니다. 여러 버전의 프로그램이 이 라이브러리를 필요로 하며, 버전이 낮으면 호환성 문제가 발생할 수 있습니다.

libstdc++: GNU Standard C++ Library로, C++ 프로그램을 실행하는 데 필요합니다.

해결 방법

Centos버전을 8로 변경

[Centos] Failed to download metadata for repo 'appstream' 에러 해결

제가안난데여♪(´ε｀*) — Sun, 23 Mar 2025 22:24:48 +0900

발생 에러

[root@e12ebc3453d8 /]# yum update
Failed to set locale, defaulting to C.UTF-8
CentOS Linux 8 - AppStream                                                                     0.0  B/s |   0  B     00:00
Errors during downloading metadata for repository 'appstream':
  - Curl error (6): Couldn't resolve host name for <http://mirrorlist.centos.org/?release=8&arch=x86_64&repo=AppStream&infra=container> [Could not resolve host: mirrorlist.centos.org]
Error: Failed to download metadata for repo 'appstream': Cannot prepare internal mirrorlist: Curl error (6): Couldn't resolve host name for <http://mirrorlist.centos.org/?release=8&arch=x86_64&repo=AppStream&infra=container> [Could not resolve host: mirrorlist.centos.org]

발생 원인

CentOS Linux EOL

CentOS 8이 2021년 12월 31일에 공식적으로 지원이 종료(EOL, End of Life)되면서, 기본 리포지토리(mirrorlist.centos.org)는 더 이상 CentOS 8 패키지에 대한 업데이트나 접근을 제공하지 않습니다. 이로 인해 CentOS 8에서 기본 mirrorlist 경로를 사용하면 패키지 다운로드에 실패하게 됩니다.

해결 방법:Vault 저장소로 변경

/etc/yum.repos.d/CentOS-Linux-AppStream.repo 파일에서 mirrorlist 대신 vault.centos.org URL을 baseurl로 지정함으로써, EOL 버전 패키지에 접근할 수 있습니다. Vault 저장소는 CentOS 8 패키지를 포함하고 있지만, 더 이상 업데이트나 보안 패치를 제공하지 않으므로 최신 보안이 필요한 환경에서는 CentOS Stream이나 다른 지원되는 운영체제로 업그레이드하는 것이 좋습니다.

AppStream 뿐만 아니라 Baseos, Extra에서도 모두 발생하니 모든 파일을 아래와 같이 바꿔줍니다.

YUM 레포지토리 파일 수정/etc/yum.repos.d/CentOS-Linux-AppStream.repo 파일을 열고, 다음과 같이 수정합니다:

# vi CentOS-Linux-AppStream.repo
-----

[appstream]
name=CentOS Linux 8.5.2111 - AppStream
#mirrorlist=http://mirrorlist.centos.org/?release=8.5.2111&arch=$basearch&repo=AppStream&infra=$infra
baseurl=http://vault.centos.org/$contentdir/8.5.2111/AppStream/$basearch/os/
gpgcheck=1
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficial
~

YUM 레포지토리 파일 수정/etc/yum.repos.d/CentOS-Linux-BaseOS.repo 파일을 열고, 다음과 같이 수정합니다:

# vi CentOS-Linux-BaseOS.repo
-----

[baseos]
name=CentOS Linux 8.5.2111 - BaseOS
#mirrorlist=http://mirrorlist.centos.org/?release=8.5.2111&arch=$basearch&repo=BaseOS&infra=$infra
baseurl=http://vault.centos.org/$contentdir/8.5.2111/BaseOS/$basearch/os/
gpgcheck=1
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficial

YUM 레포지토리 파일 수정/etc/yum.repos.d/CentOS-Linux-Extras.repo 파일을 열고, 다음과 같이 수정합니다:

# vi CentOS-Linux-Extras.repo
-----

[extras]
name=CentOS Linux 8.5.2111 - Extras
#mirrorlist=http://mirrorlist.centos.org/?release=8.5.2111&arch=$basearch&repo=extras&infra=$infra
baseurl=http://vault.centos.org/$contentdir/8.5.2111/extras/$basearch/os/
gpgcheck=1
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficial
~

+) Centos7에서는

YUM 레포지토리 파일 수정:/etc/yum.repos.d/CentOS-Base.repo 파일을 열고, base, updates, extras 섹션을 다음과 같이 수정합니다:
[base] name=CentOS-$releasever - Base baseurl=http://vault.centos.org/7.9.2009/os/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 [updates] name=CentOS-$releasever - Updates baseurl=http://vault.centos.org/7.9.2009/updates/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 [extras] name=CentOS-$releasever - Extras baseurl=http://vault.centos.org/7.9.2009/extras/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
YUM 캐시 청소:
```
yum clean all
```
변경한 후에는 YUM 캐시를 청소하세요:
패키지 설치:
yum update

[CI/CD] GitHub-hosted runner 와 Self-hosted runner 란?

제가안난데여♪(´ε｀*) — Sun, 23 Mar 2025 22:24:00 +0900

GitHub-hosted runner: GitHub에서 제공하는 서버에서 작업을 실행하는 방식. 사용자는 인프라를 관리할 필요 없이 자동으로 제공된 환경에서 빌드, 테스트, 배포 작업을 수행할 수 있다.

Self-hosted runner: 사용자가 직접 서버를 설정하고 관리하여 GitHub Actions의 작업을 실행하는 방식. 자신의 인프라에서 작업을 처리하므로 사용자 제어가 가능하지만 유지 관리와 리소스 관리는 사용자의 책임이 된다.

항목 GitHub-hosted Runner Self-hosted Runner

인프라 제공 및 관리	GitHub에서 제공하는 인프라에서 자동 실행	사용자가 runner 서버를 지정하여 직접 서버를 설정 및 관리하여 실행
비용	제한된 무료 실행 시간 제공, 추가 리소스는 유료 플랜 필요	GitHub Actions 사용 비용 없음, 서버 유지 비용은 사용자 부담
커스터마이징	제한적, 표준화된 GitHub 환경에서 실행	사용자가 런너 환경을 자유롭게 설정 가능
성능 및 리소스 제한	GitHub이 제공하는 기본 리소스로 제한됨	사용자가 필요에 맞춰 리소스(예: CPU, 메모리) 설정 가능
네트워크 접근성	고정 IP 주소 제공하지 않음, GitHub IP 범위로 설정 필요	내부 네트워크 자원에 자유롭게 접근 가능
운영 체제 선택	Linux, Windows, macOS 선택 가능	사용자가 직접 설정한 운영 체제에서 실행
유지 보수	GitHub이 런너 인프라 관리 및 유지 보수	사용자 직접 인프라 관리 및 유지 보수 필요
네트워크 속도 및 성능	GitHub의 네트워크 및 인프라 성능에 의존	사용자가 설정한 네트워크 성능에 따라 다름
IP 주소 고정 여부	고정되지 않음, IP 범위는 제공	사용자가 설정한 고정 IP 가능
보안 제어	GitHub이 관리하는 보안 정책에 따름	사용자가 서버의 보안 정책 및 접근 제어 가능

Self-hosted runner 구축기 보러가기 ⏬

[CI/CD] gitHub Action으로 CI/CD 구축하고 인간젠킨스 탈출하다! (feat. Self-hosted runner)

[DevOps] Jenkins로 CI/CD 구축하기-1 (Jenkins 설치편)

제가안난데여♪(´ε｀*) — Sun, 23 Mar 2025 22:20:29 +0900

0. 들어가기 전에

회사에서 하고 있는 프로젝트에 바로 ci/cd를 구축하면 좋겠다만 ci/cd가 처음인 나는 전에 했던 프로젝트를 가지고 ci/cd를 구축해보려고 한다.

플리보따리 라는 프로젝트인데 이 프로젝트는 현재 팀원이 gitAction으로 cicd를 구축해두어서 나는 따로 포크해와 jenkins로 구성해보려고 한다.

위와 같은 구조를 가지도록 목표하고 있다.

기회가 된다면 Nginx도 추가해보고 싶다.

우선 대충 이 정도만 띄워서 되는지만 확인해보는 것이 단기 목표이다!

가보자고

1. Jenkins 컨테이너 생성하기

젠킨스 도커 컨테이너를 생성할 것이다.

서버에는 이미 도커가 설치되어 있었다. 도커를 설치하는 과정은 넘어간다.

swapfile 도 2기가 설정해두었다. 이 과정도 기록하지는 않는다. 참고링크에서 참고하자.

우선 설치하기 전 생성할 컨테이너에 Java17을 설치 하려고 한다. 자바 11을 쓴다면 아래와 같이 간단하게 명령어를 작성하여 컨테이너를 만들 수 있지만 현재로서는 Jenkins 이미지 중에 Java17을 지원하는 것은 없다.

sudo docker run -d --name jenkins -p 8081:8080 jenkins/jenkins:jdk11

그래서 Java17설치하는 Dockerfile을 작성하고 그 Dockerfile을 통해 이미지를 만들고 이미지를 실행시켜 컨테이너를 만들 것이다.

Dockerfile 작성
# Dockerfile FROM jenkins/jenkins USER root # OpenJDK 17 설치 RUN apt-get update && apt-get install -y openjdk-17-jdk # Jenkins 시작 USER jenkins
Docker 이미지 빌드
- Dockerfile 이 있는 디렉토리에서 위 명령어를 실행한다.
- 여기서 t 옵션은 빌드된 이미지에 태그를 부여하는 데 사용된다. jenkins는 이미지의 이름이 된다.
- **.**은 Dockerfile이 있는 현재 디렉토리를 나타낸다.
sudo docker build -t jenkins .
Jenkins 컨테이너 생성
- 호스트의 8081 포트와 컨테이너의 8080 포트를 매핑하여 호스트의 8081 포트를 통해 컨테이너의 Jenkins 서버에 접근할 수 있게 했다.
(서버ip):8081 를 브라우저에 url로 입력해 이동하면 젠킨스 아저씨를 만날 수 있다. 바로 요렇게
sudo docker run -d --name jenkins -p 8081:8080 jenkins

~~(이 아저씨가 나중에 되게 화낸다던데…. )~~

2. Jenkins 설정

젠아저씨가 기다리라는 대로 기다리면 아래와 같은 화면이 뜬다.

패스워드를 입력해야 하는데 입력하기 위해서는 젠킨스가 설치된 컨테이너에 접속해 위에 빨간 글씨로 적혀있는 디렉토리로 이동하면 초기 관리자 키가 적혀 있다.

// jenkins 컨테이너에 접속
$ sudo docker exec -it jenkins bash
// 초기 관리자 키 확인
$ cat /var/jenkins_home/secrets/initialAdminPassword

위 명령어를 통해 출력된 키를 입력하고 Continue 하면 아래와 같이 초기 플러그인 설정이 나온다.

나는 추천 플러그인들을 설치하고 넘어갔다.

다 되면 유저 설정을 해보자

다 끝나면 Jenkins에 접속할 URL을 설정할 수 있다.

나는 아래와 같이 바꿔주었다.

아니 근데 왜 저 url로 들어가면 화내는거임 ?

아오

저 설정은 뭔지 모르겠고 그냥 8081로 접속해주자 ㅎㅎ..

짜자자잔

이제 모든 설정은 마쳤으니 CI를 구축해보자 !

참고 링크

https://seongwon.dev/DevOps/20220713-CICD란/

[DevOps] CI/CD란..?

제가안난데여♪(´ε｀*) — Sun, 23 Mar 2025 22:18:43 +0900

0. 배경

회사에서 참여하게 된 프로젝트로 인해 CI/CD를 공부 해야겠다는 생각이 들었다.

프로젝트에서 나는 A 서비스를 제공하는 웹서버(간단하게 A서버라고하자)를 구축하고 수정해야 했다. ( 물론 내가 다하진 않는다. 나의 기여도는 개미 눈물만큼? )

근데 A 서비스 서버는 대략 8개 ..? 정도 되는 서비스로 이루어져 있었다. ~~(자세히는 모르지만 이게 MSA?)~~

그래서 소스코드를 수정하고 테스트 서버에서 수정사항이 반영됐는지 확인하기 위해서는 1번 서비스에서 war 파일을 생성해서 옮기고…

2번 서비스에서는 jar 파일을 생성해서 올리고…

엔진엑스를 다시 실행시키고 ..

어쩌구 저쩌구 하는 상당히 복잡한 과정 ,, 워드로 두, 세장이 작성될 만큼에 서버 구축 과정이 다시 수행되어야 한다.. ( 물론 생략하는 부분도 생기겠지.. )

아무튼 이걸 설명을 듣고 이게 맞나..

자동화 되는 게 있을 거 같은데 라는 생각을 하게 되었고 그게 CI/CD 의 과정이라는 것을 깨닫게 되었다.

+) 아무래도 프로젝트가 너무 커서 프로젝트에는 ci/cd를 적용하지는 못할 듯 싶다..

1. CI (Continuous Integration)

빌드, 테스트의 자동화

CI/CD의 CI 는 “지속적인 통합”을 의미한다.

코드에 변경사항이 있을 경우 자동으로 빌드, 테스트 되어 공유 레포지토리에 통합된다.

마틴 파울러는 CI의 4가지 규칙이 있다고 언급하였다. 규칙은 다음과 같다.

모든 소스코드가 살아있고(현재 실행되고) 누구든 현재의 소스에 접근할 수 있는 단일 지점을 유지할 것
빌드 프로세스를 자동화해서 누구든 소스로부터 시스템을 빌드하는 단일 명령어를 사용할 수 있게 할 것
테스팅을 자동화해서 단일 명령어로 언제든지 시스템에 대한 건전한 테스트 수트를 실행할 수 있게 할 것
누구나 현재 실행 파일을 얻으면 지금까지 가장 완전한 실행 파일을 얻었다는 확신을 하게 할 것

CI 과정이 자동화로 수행된다면 Git에 push, merge를 하게 될 경우 정상적으로 빌드가 되는 지 테스트 과정을 자동으로 확인하고 빌드가 성공적으로 이루어지면 수정된 코드가 받아들여지게 된다.

2. CD (Continuous Deployment or Continuous Delivery)

배포의 자동화

CD는 두가지 의미가 있다.

지속적인 제공과 지속적인 배포이다.

지속적인 제공(Delivery)는 CI 과정을 거치게 되면 레포지토리에 자동으로 업로드 되는 것을 말한다. 그렇게 레포지토리에 업로드된 코드가 문제가 없는지 검증 후에 수동으로 배포해야한다.

여기서 더 나아간 게 지속적인 배포 (Deployment)이다.

이게 바로 내가 하고 싶은 작업이다.

레포지토리에 수정이 반영된 버전으로 서버에 자동으로 배포하는 과정을 말한다.

3. CI/CD의 대표적인 툴

Jenkins, Buildkite, Github Actions, GitLab CI/CD, Bitbucket Pipelines, Circleci 등이 있다. 이 중에서 가장 많이 사용되는 것은 Jenkins이다.

참고 링크

https://seongwon.dev/DevOps/20220713-CICD란/

[Docker] DockerHub에 이미지 올리기

제가안난데여♪(´ε｀*) — Sun, 23 Mar 2025 22:15:01 +0900

이미지 저장소

도커는 빌드한 이미지를 서버에 배포하기 위해 직접 파일을 복사하는 방법 대신 도커 레지스트리(Docker Registr)y라는 이미지 저장소를 사용한다.

도커 명령어를 이용하여 이미지를 레지스트리에 push 하고 다른 서버에서 pull 받아 사용하는 구조로 git과 비슷하다고 생각하면 될 것 같다.

도커 레지스트리는 오픈소스로 무료로 설치할 수 있고 설치형이 싫다면 도커(Docker Inc.)에서 서비스 중인 도커 허브Docker Hub를 사용할 수 있다.

Docker Hub

도커 허브는 도커에서 제공하는 기본 이미지 저장소로 ubuntu, centos, debian등의 베이스 이미지와 ruby, golang, java, python 등의 공식 이미지가 저장되어 있다.

일반 사용자들이 만든 이미지도 50만 개가 넘게 저장되어 있고 다운로드 횟수는 80억 회를 넘는다고 한다.

이전에 만들었던 Ruby 웹 어플리케이션 이미지를 docker hub에 저장해보자.

이전 게시물 → [Docker] Docker 이미지 만들고 컨테이너 생성하기

app.rb 코드 수정

나는 이전에 만들었던 웹 어플리케이션 (이름 : app)을 가상머신에서 도커허브로 올린 다음

회사에서 할당받은 서버에서 내려 받으려고 한다.

할당받은 서버에서도 app.rb가 똑같이 작성되어 있고 컨테이너 이미지가 모두 존재하기 때문에

만일 하나를 대비하여 차이점을 주기 위해 app.rb 의 코드를 수정하여 다시 이미지 빌드를 하였다.

app.rb

require 'sinatra'
require 'socket'

get '/' do
  "Hello World! This is #{Socket.gethostname}"
end

⤵INPUT

docker build -t app .

회원가입

다음 DockerHub 도커허브 사이트에 접속해서 회원가입을 먼저 해주자.

⤵INPUT

docker login

⤴ OUTPUT

Docker ID 또는 이메일 주소로 로그인하여 Docker Hub에서 이미지를 푸시하고 가져오세요. Docker ID가 없으면 <https://hub.docker.com/으로> 이동하여 ID를 만드세요.

비밀번호나 PAT(Personal Access Token)를 사용하여 로그인할 수 있습니다. 제한된 범위의 PAT를 사용하면 보안이 강화되며 SSO를 사용하는 조직에 필요합니다. <https://docs.docker.com/go/access-tokens/에서> 자세히 알아보세요.

사용자 이름: dksek3050
비밀번호:
경고! 귀하의 비밀번호는 /home/user/.docker/config.json에 암호화되지 않은 상태로 저장됩니다.
이 경고를 제거하려면 자격 증명 도우미를 구성하십시오. 보다
<https://docs.docker.com/engine/reference/commandline/login/#credentials-store>

로그인 성공

영어 울렁증 있는 나는 냅다 번역기 돌려버림

비밀번호가 config.json 파일에 무려 암호화가 되지 않은 상태로 저장된다고 한다.

비밀번호를 통합해서 쓰는 나는 간단 비밀번호로 바꿔주었다.

그리고 config.json 당장 들어가버림.

어라 암호화 안되어 있다고 했는데 인코딩만 되어 있는거 같다. 디코딩해보자

헉 바로 바로 보인다. 비밀번호 또 바꾸러가야지 총총 ..

회사 서버를 쓰거나 공용으로 접속할 수 있는 서버에서 실습을 진행하는 사람들은 본인이 자주 쓰는 비밀번호는 사용하지 않으며 비밀번호가 노출되지 않도록 주의해야 할 것 같다.

config.json 파일에 저장된 정보가 로그아웃하기 전 까지 로그인 정보가 유지된다.

추가적으로 로그아웃 하게 되면 config.json에 있는 내용은 지워진다 !

이미지 태그

도커 이미지 이름은 다음과 같은 형태로 구성된다.

[Registry URL]/[사용자 ID]/[이미지명]:[tag]

Registry Url은 기본적으로 도커 허브를 바라보고 있고 사용자 ID를 지정하지 않으면 기본 값(library)을 사용한다. 따라서 ubuntu = library/ubuntu = doker.io/library/ubuntu 는 모두 동일한 표현이다.

도커의 tag 명령어를 이용하여 기존에 만든 이미지를 추가로 이름을 지어 줄 수 있다.

docker tag SOURCE_IMAGE[:TAG] TARGET_IMAGE[:TAG]

이전에 만든 app 이미지에 계정 정보와 버전 정보를 추가해보자.

⤵INPUT

docker tag app anna/anna-app:1

“anna 라는 ID를 사용”하고 이미지 이름을 anna-app으로 변경하였다.

첫번째 버전이므로 태그는 1로 지정하였다.

⤴ OUTPUT

이미지 목록을출력해보면 app 과 anna/anna-app이 모두 존재함을 알 수 있는데 image를 보니 같은 아이디를 가지고 있는 걸로 보아 같은 이미지를 참조하고 있음을 확인 할 수 있었다.

이미지 푸시(push)

이제 push라는 명령어를 이용하여 도커 허브에 이미지를 올려보자.

⤵INPUT

docker push anna/anna-app:1

⤴ OUTPUT

어라 ? 거부됐다 왜지 ?

찾아보니 **Docker Hub에 로그인한 ID외 이미지의 유저 ID가 달라서** 이다.

이미지 태그를 재설정해주자.

이미지 다시 태그

⤵INPUT

docker tag app dksek3050/anna-app:1

⤴ OUTPUT

이미지 다시 푸시(push)

⤵INPUT

docker push dksek3050/anna-app:1

⤴ OUTPUT

성공 !

이제 도커 허브에 저장된 50만 개의 이미지에 새로운 이미지가 하나 추가되었다.

이제 어디서든 dksek3050/anna-app:1이미지를 사용할 수 있다.

Private Docker Registry

도커 이미지를 비공개로 저장하려면 Docker Cloud를 유료로 사용하거나

도커 Registry 서버를 자체적으로 구축해야합니다.

나는 도커 레지스트리 서버를 구축해서 그 서버에 이미지를 저장해보겠다.

도커 레지스트리 서버도 도커 이미지를 다운받아 컨테이너를 띄어서 구축할 수 있다.

⤵INPUT

도커 레지스트리에 저장된 이미지는 파일로 저장되기 때문에 호스트(로컬)의 디렉토리를 마운트 해야한다. (S3 저장소를 사용할 수도 있다.)

docker run -d \\
-v $PWD/registry:/var/lib/registry \\
-p 5000:5000 \\
distribution/registry:2.6.0

v $PWD/registry:/var/lib/registry: 호스트 시스템의 현재 디렉토리에 있는 registry 디렉토리를 컨테이너 내부의 /var/lib/registry 디렉토리와 연결한다.이렇게 함으로써 호스트 시스템의 파일을 컨테이너 내부에서 사용할 수 있다.
p 5000:5000: 호스트의 포트 5000과 컨테이너의 포트 5000을 매핑이것은 호스트 시스템에서 Docker 레지스트리에 접근하기 위해 사용된다.즉, 호스트의 5000번 포트를 통해 컨테이너의 5000번 포트에 연결된다.
distribution/registry:2.6.0: 사용할 Docker 이미지를 지정한다.여기서는 Docker 레지스트리 이미지의 버전 2.6.0을 사용합니다.

⤴ OUTPUT

이제 레지스트리 서버의 아이피와 포트 정보를 이미지 명에 추가하면 바로 사용할 수 있다.

⤵INPUT

docker tag app localhost:5000/dksek3050/anna-app:1

이 명령은 **app**이라는 이름의 Docker 이미지를 **localhost:5000/dksek3050/anna-app:1**이라는 태그로 다시 태그
- app: 이미지의 현재 이름이며, 빌드된 Docker 이미지의 이름이다.
- localhost:5000/dksek3050/anna-app:1: 새 태그로, 이것은 레지스트리 호스트 **localhost**의 포트 5000에 있는 Docker 레지스트리의 **dksek3050**네임스페이스 아래에 anna-app 리포지토리의 버전 1을 나타낸다.

docker push localhost:5000/**dksek3050**/**anna**-app:1

이 명령은 지정된 Docker 이미지를 Docker 레지스트리로 푸시
- localhost:5000/dksek3050/anna-app:1: 푸시 할 이미지의 목적지이다. 앞서 태그한 이미지인 **localhost:5000/dksek3050/anna-app:1**을 로컬 Docker 레지스트리에 푸시한다.

⤴ OUTPUT

이제 레지스트리 서버에 이미지가 파일로 잘 저장되었는지 마운트 된 디렉토리를 살펴보자.

⤵INPUT

tree registry

⤴ OUTPUT

user@user-VirtualBox:~$ tree registry
registry
└── docker
    └── registry
        └── v2
            ├── blobs
            │   └── sha256
            │       ├── 20
            │       │   └── 20b669cab462d559d98bcf239b5af8845b32ea3b0eade1cf37d1f0a08748c14f
            │       │       └── data
            │       ├── 26
            │       │   └── 262c764cde3bf49fbbe7b12253dfeb14cd14eec4ac7ee11309946c8423777833
            │       │       └── data
            │       ├── 4f
            │       │   └── 4f4fb700ef54461cfa02571ae0db9a0dc1e0cdb5577484a6d75e68dc38e8acc1
            │       │       └── data
            │       ├── 6c
            │       │   ├── 6ccac03c405d0a8003c6e7681d43ead31346aec0bcf66f2e022e1aab3b7ed1b6
            │       │   │   └── data
            │       │   └── 6cdaa9e5748ae6aae5c76730ad8c34dd0594aa3c1e165ea9970475d817335cee
            │       │       └── data
            │       ├── a0
            │       │   └── a07bfac88e40c4c6a1c139d31f41c8af375e5028c51cdb5cecb86032117d4621
            │       │       └── data
            │       ├── b2
            │       │   └── b2a4edb7bfbd9b5d00fb86ecd4df90e3d723a984320d1818fcb3a6b387131e8c
            │       │       └── data
            │       ├── df
            │       │   └── df2fac849a4581b035132d99e203fd83dc65590ea565435a266cb0e14a508838
            │       │       └── data
            │       ├── f9
            │       │   └── f9841d926cf5e1a20e500f332b6c93dc294f09f6e5b876e3d994946d53b6c40a
            │       │       └── data
            │       └── fb
            │           └── fbfce4c3047e0b27a1007eaa604026ffa41592fe5f3e60582b52345864cb3abd
            │               └── data
            └── repositories
                ├── dksek3050
                │   └── anna-app
                │       ├── _layers
                │       │   └── sha256
                │       │       ├── 20b669cab462d559d98bcf239b5af8845b32ea3b0eade1cf37d1f0a08748c14f
                │       │       │   └── link
                │       │       ├── 262c764cde3bf49fbbe7b12253dfeb14cd14eec4ac7ee11309946c8423777833
                │       │       │   └── link
                │       │       ├── 4f4fb700ef54461cfa02571ae0db9a0dc1e0cdb5577484a6d75e68dc38e8acc1
                │       │       │   └── link
                │       │       ├── 6ccac03c405d0a8003c6e7681d43ead31346aec0bcf66f2e022e1aab3b7ed1b6
                │       │       │   └── link
                │       │       ├── 6cdaa9e5748ae6aae5c76730ad8c34dd0594aa3c1e165ea9970475d817335cee
                │       │       │   └── link
                │       │       ├── a07bfac88e40c4c6a1c139d31f41c8af375e5028c51cdb5cecb86032117d4621
                │       │       │   └── link
                │       │       ├── b2a4edb7bfbd9b5d00fb86ecd4df90e3d723a984320d1818fcb3a6b387131e8c
                │       │       │   └── link
                │       │       ├── df2fac849a4581b035132d99e203fd83dc65590ea565435a266cb0e14a508838
                │       │       │   └── link
                │       │       └── fbfce4c3047e0b27a1007eaa604026ffa41592fe5f3e60582b52345864cb3abd
                │       │           └── link
                │       ├── _manifests
                │       │   ├── revisions
                │       │   │   └── sha256
                │       │   │       └── f9841d926cf5e1a20e500f332b6c93dc294f09f6e5b876e3d994946d53b6c40a
                │       │   │           └── link
                │       │   └── tags
                │       │       └── 1
                │       │           ├── current
                │       │           │   └── link
                │       │           └── index
                │       │               └── sha256
                │       │                   └── f9841d926cf5e1a20e500f332b6c93dc294f09f6e5b876e3d994946d53b6c40a
                │       │                       └── link
                │       └── _uploads

73 directories, 34 files

이미지가 레이어 별로 예쁘게 저장된걸 확인할 수 있다.

보안

도커 레지스트리는 일반적인 HTTP 프로토콜을 사용하여 이미지를 전송한다. 따라서 SSL(HTTPS)을 사용하지 않으면 이미지 내용이 유출될 수 있다. 이런 보안 이슈 때문에 도커는 기본적으로 로컬(localhost) 서버를 제외하곤 HTTP 사용을 금지하고 있으며 이런 보안위험을 무시하려면 도커 엔진을 실행할 때 허용 옵션을 넣어야 한다.

배포하기

컨테이너 배포 방식

드디어 드디어 서버 관리의 꽃! 배포deploy를 해보겠다!

기존에 어플리케이션을 배포할때는 사용하는 언어, 프레임워크, 웹, 리눅스 배포판, 개발자의 취향등에 따라서 각각 다른 방식을 사용하였다.

새로운 서버를 세팅하고 한번에 배포를 성공한다는건 힘든 일이었고 검증하기도 어려웠다.

그러나 컨테이너를사용하면 어떤 언어, 어떤 프레임워크를 쓰든 상관없이 배포 방식이 동일해지고 단순해진다.

그냥 이미지를 받고 컨테이너를 실행하면 끝이다. !

로컬에서 도커 허브로 올린 이미지 받아서 컨테이너 띄우기

⤵INPUT

docker pull dksek3050/anna-app:1

⤴ OUTPUT

⤵INPUT

docker run -d -p 8080:4567 dksek3050/anna-app:1

⤴ OUTPUT

+) 추가적으로 할당받은 서버에 컨테이너를 띄우게 되면

차란 배포 성공 ! 이제 저 ip랑 구매한 도메인이랑 연결 시켜주면 우리가 사용하는 웹서비스가 완성되는것이다. (대충)

컨테이너 업데이트

도커를 사용하면 업데이트 방식도 배포와 큰 차이는 없다.

최신 이미지를 기반으로 새 컨테이너를 만들고 이전 컨테이너를 중지 및 삭제를 하면 된다.

최신 소스를 어떻게 복사할지 서버 프로세스는 어떻게 재시작을 할지 고민할 필요가 없다.

그냥 통째로 바꾼다.

이런 방식은 매우 단순하지만, 컨테이너가 멈추는 순간 실행 중인 프로세스가 종료되고 프로세스가 종료되면 고객들은 접속이 안 되고 접속이 안 되면 매출이 떨어지고 매출이 떨어지면 월급이 안나오기 때문에 무중단을 고려한 nginx나 HAProxy같은 로드 발란서Load Balancer와 2대 이상의 컨테이너를 사용해야 한다.

그것에 대해서는 다음에 알아보자.

이렇게 해서 초보 Docker 입문은 끝이 났다.

다음번에는 프로젝트로 만들었던 spring을 한번 띄워보자..

참고 링크

https://subicura.com/2017/02/10/docker-guide-for-beginners-create-image-and-deploy.html

https://sjh9708.tistory.com/81

[Docker] Docker 권한 설정하기

제가안난데여♪(´ε｀*) — Sun, 23 Mar 2025 22:12:27 +0900

실행 환경

Ubuntu 22.04

Docker 권한 설정

Docker 에서 모든 도커 관련된 작업이 root 사용자에게만 권한이 허용되어 있기 때문에

도커 명령어를 입력하기 위해서는

sudo

를 앞에 붙여주어야만 가능하다.

이를 root 계정이 Host의 기본 유저에게 권한을 주도록 바꿔볼 것이다.

아래 명령어는 새로운 터미널을 띄어서 수행하도록 하자!

sudo usermod -a -G docker [사용자 이름]   # [사용자이름]에게 권한주기
sudo service docker restart

위 처럼 명령어를 입력한 후 vm을 다시 시작해보자.

아까와 똑같은 명령어를 sudo를 적지 않아도 잘 실행 됨을 확인 할 수 있다.

이제 도커 세팅을 마쳤으니 제대로 실습해보자 !

다음게시글 -> [Docker] Docker 컨테이너 실행하기

참고 링크

[Docker] 도커 설치하기

제가안난데여♪(´ε｀*) — Sun, 23 Mar 2025 22:11:28 +0900

실행 환경

Ubuntu 22.04

Docker 설치

⭐공식 문서 링크

1. 우분투 시스템 패키지 업데이트

리눅스 계열 운영체제에서 쓰이는 패키지 관리 툴인 apt를 최신 버전으로 업데이트 한다

sudo apt-get update

2. 필요한 패키지 설치

sudo apt-get install apt-transport-https ca-certificates curl gnupg-agent software-properties-common

apt-transport-https : https를 통해 데이터나 패키지에 접근할 수 있다. (링크)
ca-certificates : Certificate Authority - certificates라는 뜻으로 SSL기반 웹 애플리케이션이 SSL연결의 진위여부를 판별할 수 있게 해준다.
curl : 링크로 데이터를 다운 받을 수 있게 해주는 도구
software-properties-common : 우분투에서 PPA를 사용하기 위한 패키지

PPA : Personal Package Archive.우분투는 우분투 소프트웨어 센터에 등록된 프로그램 및 버전만 다운받을 수 있다. 이 방식이 편리하고 검증된 프로그램만 다운 받을 수 있다는 점에서 안전하지만 새로운 버전이 빨리 업데이트 되지 않는다는 단점이 있다. 업데이트 주기는 우분투가 업데이트 되는 6개월인데, 보다 자유롭게 최신 버전과 등록되지 않은 프로그램을 다운 받을 수 있도록 도와 주는 것이 PPA다.

3. Docker의 공식 GPG키를 추가

curl -fsSL <https://download.docker.com/linux/ubuntu/gpg> | sudo apt-key add -

| : 파이프라인. 한 명령어에서 나온 결과값을 다음 명령어에 넣어준다.
sudo apt-key add - : 패키지 키를 추가한다

GPG키 : GNU Privacy Guardgpg키는 도커에만 존재하는 것은 아니고, 리눅스 패키지 관리 툴이 이 프로그램 패키지가 유효한지 확인하기 위해 설치 전 gpg키로 검증하는 과정을 거친다고 한다. 그래서 curl로 gpg키를 다운받아 apt 키 리스트에 추가해야 한다.

4. Docker의 공식 apt 저장소를 추가

sudo add-apt-repository "deb [arch=amd64] <https://download.docker.com/linux/ubuntu> $(lsb_release -cs) stable"

sudo add-apt-repository [저장소 이름]

이 명령어를 실행하면 apt 리스트에 도커가 추가된다. (저장소 이름은 구글에 프로그램과 ppa로 검색하면 찾을수 있다.)

5. 시스템 패키지 업데이트

최신 도커 버전을 다운받기 위해 패키지를 업데이트 한다.

sudo apt-get update

6. Docker 설치

sudo apt-get install docker-ce docker-ce-cli containerd.io

도커 엔진은 유료로 제공되는 기업용 솔루션인 EE(Enterprise Edition)와 무료로 제공되는 CE(Community Edition)로 나뉘는데, CE버전을 설치했다.

7. Docker가 설치 확인

7-1 도커 실행상태 확인

sudo systemctl status docker

7-2 도커 실행

sudo docker run hello-world

위와 같이 "해당 컴퓨터에는 hello-world 라는 도커 이미지가 없다" 라는 오류가 나면 정상적으로 설치가 완료!

다음게시글 -> [Docker] 권한 설정하기

참고 링크

[Docker] 버츄얼박스(VirtualBox) & 우분투(Ubuntu) 설치

제가안난데여♪(´ε｀*) — Sun, 23 Mar 2025 22:09:39 +0900

버츄얼박스(VirtualBox) & 우분투(Ubuntu) 다운로드

도커는 리눅스 컨테이너 기반의 기술이기 때문에 윈도우나 맥에서 실습하기 위해서는 가상의 리눅스 환경을 만들어 주어야한다.

이를 위해 Vitrual Box와 Ubuntu를 사용하여 실습을 진행하려 한다.

버츄얼 박스 버전 : VirtualBox-6.1.50-161033-Win

우분투 버전 : ubuntu-22.04.3-desktop-amd64

Ubuntu 다운로드

Virtual Box 다운로드

이전에 VirtualBox 7.0을 깔았을때는 아래와 같은 오류가 났다.

설치 파일을 실행시켰을 때 아래와 같은 오류가 뜬다면 Microsoft Visual C++ 2019를 설치하자.

Microsoft Visual C++ 2019 다운로드

ARM64: 스마트폰, 태블릿PC의 CPU코어 설계 회사

X86: 32bit 윈도우즈 운영체제가 동작하는 CPU의 총칭.

X64: 64bit 윈도우즈 운영체제가 동작하는 CPU의 총칭.

가상머신에서 우분투 환경 세팅

1. 가상 머신 생성

다운 받은 Virtual Box를 실행한다.

[새로만들기] - 종류 : Linux, 버전: Ubuntu 64 bit
메모리크기 2048mb
하드 디스크 - 디폴트 설정이게 원인인지는 확실히 모르겠지만 기본 메모리 크기로 설정했다가 우분투 크기보다 작아서 우분투 설치를 못했다..생각보다 넉넉하게 잡아주자… !!!
위 설정대로 하면 제대로 깔려요 !
그래서 가상머신 다시 설치함 ..

2. 가상머신 실행

시작버튼을 눌러 가상머신을 실행하자

미리 다운받아 두었던 ubuntu .iso 파일을 선택하여 시작해 준다.

“Try or Install Ubuntu” 선택

3. 우분투 설치

언어 리스트 쭉 내리면 [한국어] 선택 - [Ubuntu 설치] 선택
키보드 레이아웃 [Korean] - [Korean] - [계속하기]
업데이트 및 기타 소프트웨어 - 최소설치나는 최소설치만 해주었다.
설치형식 - 기본 설정에서 바꾸지 않았다.
사용자 정보 입력
설치완료
다시 시작하자.

설치 완 !

7.. 재부팅 후 password 설정

터미널을 열고

명령어를 입력하여 비밀번호를 바꿔주자

꽤나 깐깐하다 rootroot 하려다가 퇴짜먹었다

dkssk123

다음은 설치한 우분투에 도커를 깔아보자.

다음게시글 -> [Docker] 도커 설치하기

참고 링크

[Ubuntu] 우분투 ↔ 윈도우 클립보드 공유 안됨 문제, VirtualBox 가상 광 디스크 삽입 문제

제가안난데여♪(´ε｀*) — Sun, 23 Mar 2025 21:59:46 +0900

⚙ 우분투↔ 윈도우 클립보드 공유 안됨 문제

⚙ VirtualBox 가상 광 디스크 삽입 문제

VirturalBox 의 Ubuntu에서 도커를 설치하는 실습을 하던 중

우분투와 윈도우간의 클립보드가 공유되지 않은 것에 대한 불편함을 느끼게 되었다.

전에 가상머신을 사용했을때 내 기억으론 복붙이 공유가 되었던거 같은데 왜 그런지 문제를 찾아보았다.

첫 번째로는 [장치] - [클립보드 공유] - [양방향]

전혀 먹지 않았다.

또 검색해본 결과 이걸 해소하기 위한 게스트 확장을 설치하는 것이었다.

[장치] - [게스트 확장 CD 이미지 삽입]

띠용

오류가 났다.

이상태로 나는 우분투 버전도 바꿔서 다시 깔아보고

VBox도 다시 깔아보고

블로그에서 입력하라는 명령어들도 다 입력해보았지만 안됐다..

찾아보니 자세한 정보를 봤을때 VERR_RDM_MEDIA_LOCKED라는 오류였고 이는 이미 삽입이 되어 있어서 락이 걸려 있다는 내용이라고 했다.

해결해보자.

가상머신 종료
VBox 에서 [가상머신 선택] - [설정] - [저장소] - [VbBoxGuestAddition.iso] - 디스크모양선택 - [가상드라이브에서 디스크 꺼내기]
최초 VirtualBox 설치될때 기본적으로 자동 삽입이 되어 있어서 또 삽입하려니까 lock이 걸린거 같다.

그렇게 설정을 해주고 나면 iso가 있던 곳이 비어있음을 확인할 수 있다.

가상머신을 다시 켜서 [장치] - [게스트 확장 CD 이미지 삽입]을 선택
뜨시는 분들은 실행하시면 됩니당
하면 아래왜 같이 알림창이 뜬다는데 나는 안떠서 강제 실행 해주었다.
상태바에 저렇게 CD 모양이 생겼고 누르면 이런 파일들이 들어가 있는데 여기서 [프로그램 실행]을 누르면 된다는 사람들도 있었다.
나는 눌러도 아무 반응이 없어서 강제실행해야한다.
해당 파일에서 터미널을 열자
자동 실행 파일을 실행시켜주자
sh autorun.sh
인증짜잔 이게 드디어 떴다 ㅠㅠㅠㅠㅠㅠㅠ
설치 완료! 껐다 켜보자
새 터미널에서 reboot 명령어를 치면 간단하게 재시작 할 수 있다.

드디어 윈도우에서 우분투로 복붙성공 !!!!

Linux Ubuntu 복사하기 : < Shift + Ctrl + C >

Linux Ubuntu 붙여넣기 : <Shift + Ctrl + V >

참고 링크

https://sidepower.tistory.com/43#google_vignette

https://arkainoh.blogspot.com/2016/09/virtualbox.guest.additions.html

GitHub Pages에 리액트 프로젝트(React + Vite) 배포하기

제가안난데여♪(´ε｀*) — Sun, 23 Mar 2025 18:05:28 +0900

이번 블로그 글에서는 GitHub Pages를 사용해 특정 폴더 안에 있는 리액트 프로젝트를 배포하는 방법에 대해 다룹니다. 배포한 프로젝트는 https://username.github.io/repository-name/ 형식으로 접근할 수 있게 됩니다. 저는 레포지토리 안의 디렉토리에 배포 파일이 존재하기 때문에, 아래와 같은 URL로 접근할 수 있도록 설정했습니다.

https://an0401na.github.io/React_Study/08-Refs-Portals/

Refs & Portals

The Almost Final Countdown Stop the timer once you estimate that time is (almost) up

an0401na.github.io

제가 위와 같이 설계했던 이유는 리액트 강의를 들으며 만들었던 페이지를 같은 레포지토리의 다른 디렉토리로 구분하여 배포할 예정이 있기 때문입니다.

React_Study/            # 레포지토리 이름
 ├── 08-Refs-Portals/   # 첫 번째 배포된 리액트 페이지
 │    └── dist/         # 빌드된 파일
 ├── 09-AnotherPage/    # 두 번째 배포될 리액트 페이지
 │    └── dist/         # 빌드된 파일
 ├── 10-AnotherExample/ # 세 번째 배포될 리액트 페이지
 │    └── dist/         # 빌드된 파일
 └── ...                # 추가적인 배포될 페이지들

위와 같은 구조로 각 페이지마다 별도의 디렉토리를 두고, 각 디렉토리마다 dist 폴더에 빌드 파일을 생성하여 배포합니다. 각 페이지는 https://username.github.io/React_Study/08-Refs-Portals/, https://username.github.io/React_Study/09-AnotherPage/와 같은 URL로 접근할 수 있게 됩니다.

1. GitHub 블로그 만들기

GitHub에서 프로젝트를 배포하려면 먼저 GitHub Page를 활성화 하기 위해 깃허브 블로그를 생성해주어야 합니다.

New 버튼을 눌러 새로운 레포지토를 생성하는데 꼭 <본인계정명>.github.io로 생성해주세요.

2. 프로젝트 올릴 레포 만들기

배포할 리액트 프로젝트를 GitHub에 올릴 레포지토리를 생성합니다. 해당 레포지토리에는 main 브랜치에서 소스 코드가 관리되고, gh-pages 브랜치에는 배포 파일이 관리됩니다.

3. 레포지토리의 디렉토리 구조

프로젝트 구조는 아래와 같으며, 리액트 프로젝트의 소스 코드가 08-Refs-Portals 폴더 내에 위치한다고 가정합니다.

gh-pages 브랜치에서 목표로하는 디렉토리 구조는 아래와 같습니다.

React_Study/       # 레포지토리명 
 └── 08-Refs-Portals/ # 레포지토리 안의 폴더명
      └── dist/    # 빌드된 파일

4. 빌드 준비하기

1. 프로젝트 디렉토리에서 필요한 의존성을 설치합니다. (프로젝트 경로에서 실행)

PS C:\\workspace\\React_Study\\08-Refs-Portals> npm install

2. gh-pages를 개발 의존성으로 설치합니다.

PS C:\\workspace\\React_Study\\08-Refs-Portals>  npm install --save-dev gh-pages

package.json 설정

homepage를 GitHub Pages URL로 설정합니다. 그리고 deploy 스크립트를 추가합니다.

  "homepage": "https://an0401na.github.io/React_Study/08-Refs-Portals/",
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview",
    "deploy": "gh-pages -d dist"
  }

vite.config.js 설정

Vite의 base 경로를 설정하여 GitHub Pages에서 서브 폴더로 배포될 수 있도록 합니다.

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

export default defineConfig({
  plugins: [react()],
  base: '/React_Study/08-Refs-Portals/'
})

5. 빌드 실행

PS C:\\workspace\\React_Study\\08-Refs-Portals> npm run build

이 명령어로 main 브랜치에서 dist 폴더에 빌드된 파일들이 생성됩니다.

6. 배포 파일 커밋

1. dist 폴더에 있는 파일들을 main 브랜치에 강제로 추가합니다.

PS C:\\workspace\\React_Study\\08-Refs-Portals> git add -f dist/*

주의: 소스 코드가 아닌 dist 디렉토리만 추가해야 합니다. 소스 코드와 함께 올라가면, GitHub Pages에서 index.html이 아닌 소스 코드가 보여질 수 있습니다.

2. main 브랜치로 커밋을 진행합니다.

PS C:\\workspace\\React_Study\\08-Refs-Portals>  git commit -m "Deploy updated build to gh-pages"

중요: 아직 PUSH는 하지마세요. gh-pages 브랜치에 푸시할 준비가 되지 않았으므로, 푸시 작업은 아직 하지 않습니다 build된 파일은 다른 브랜치(gh-pages)에 올릴테니까요.

7. Push

레포지토리 루트 디렉토리로 이동한 후, gh-pages 브랜치로 배포 파일을 푸시합니다.

PS C:\\workspace\\React_Study> git subtree push --prefix 08-Refs-Portals/dist origin gh-pages

만약 gh-pages 브랜치가 아직 생성되지 않았다면, 아래 명령어로 새로운 브랜치를 생성합니다.

PS C:\\workspace\\React_Study> git checkout --orphan gh-pages

8. GitHub Pages 설정

GitHub에서 프로젝트 페이지를 활성화하려면 Settings > Pages에서 배포할 브랜치로 gh-pages를 선택합니다.

Source에서 gh-pages를 선택하고, Save 버튼을 클릭합니다.

9. 배포 완료

배포가 완료된 후, 아래 URL을 통해 프로젝트를 확인할 수 있습니다:

https://username.github.io/React_Study/08-Refs-Portals/

[React] React 완벽 가이드 - Refs(참조) & Potals(포탈) 활용하기

제가안난데여♪(´ε｀*) — Sun, 23 Mar 2025 17:25:10 +0900

이 글은 Udemy의 【한글자막】 React 완벽 가이드 2025 with React Router & Redux 를 수강하고 정리한 내용입니다.

useRef를 이용하여 만든 Timer Challenge 방문하기

https://an0401na.github.io/React_Study/08-Refs-Portals/

Refs & Portals

The Almost Final Countdown Stop the timer once you estimate that time is (almost) up

an0401na.github.io

Refs (참조) 란?

Refs(References)는 React에서 특정 DOM 요소나 클래스형 컴포넌트의 인스턴스에 직접 접근할 수 있도록 도와주는 기능입니다.

상태 vs 참조 (useState vs useRef)

✅ 상태(useState)를 사용해야 할 경우:

UI에 즉시 반영되어야 하는 값
상태 변경 시 컴포넌트를 다시 렌더링해야 하는 경우

✅ 상태를 사용하지 말아야 할 경우:

UI에 영향을 주지 않는 값 (ex. 타이머 ID, 이전 값 저장 등)
내부적으로만 관리되며, 렌더링과 관계없는 값

✅ 참조(useRef)를 사용해야 할 경우:

컴포넌트가 다시 실행되지 않도록 해야 하는 값
참조 값 변경 → 컴포넌트 리렌더링 없음
DOM 요소에 직접 접근해야 할 때 (ex. focus(), scrollTo() 등)

useRef (참조)를 사용하면 왜 리렌더링 되지 않을까?

React에서는 상태가 변경되면 리렌더링이 트리거됩니다. 이때 useState는 상태를 저장하고 관리하는 데 사용되며, 상태 값이 변경되면 컴포넌트를 리렌더링합니다. 반면, useRef는 상태 값을 저장하지 않고 단순히 값을 참조하는 용도로 사용됩니다.

useRef로 관리되는 값은 렌더링과 관계없는 값입니다. 예를 들어, layerName.current.value처럼 current는 참조 객체로, 그 안의 value는 값이 됩니다. 여기서 value가 변경되더라도 React는 이를 감지하지 않습니다. 즉, useRef는 값이 변해도 리렌더링을 트리거하지 않기 때문에 UI에 변화가 반영되지 않습니다.

useRef는 주로 DOM 요소에 직접 접근하거나, 렌더링과 관련 없는 값을 저장하는 데 유용합니다. 예를 들어, 타이머 ID, 폼 입력 값 등과 같이 컴포넌트 리렌더링 없이 유지해야 하는 값들을 useRef로 관리하는 것이 적합합니다.

useRef 훅으로 JSX 요소 연결하기

useRef 훅은 리렌더링 없이 특정 DOM 요소에 접근할 때 사용됩니다.

이 예제에서는 useRef를 사용하여 <input> 요소를 참조하고, 버튼 클릭 시 입력된 값을 가져와 useRef를 업데이트하는 방식으로 동작합니다.

import { useState, useRef } from "react";

export default function Player() {
    // useRef를 사용하여 input 요소에 대한 참조 생성
    const playerName = useRef();
    
    // 플레이어 이름을 상태로 관리 (null 초기값)
    const [enteredPlayerName, setEnteredPlayerName] = useState(null);

    function handleClick() {
        // useRef를 통해 input 요소의 현재 값 가져오기
        setEnteredPlayerName(playerName.current.value);
    }

    return (
        <section id="player">
            {/* enteredPlayerName이 있으면 표시, 없으면 'unknown entity' 출력 */}
            <h2>Welcome {enteredPlayerName ?? "unknown entity"}</h2>
            <p>
                {/* input 요소에 ref 속성 연결 */}
                <input ref={playerName} type="text" />
                {/* 버튼 클릭 시 handleClick 함수 실행 */}
                <button onClick={handleClick}>Set Name</button>
            </p>
        </section>
    );
}

1️⃣ useRef로 참조 생성

const playerName = useRef();
playerName은 특정 DOM 요소를 참조하는 객체가 됩니다.

2️⃣ JSX에서 ref 속성을 사용하여 요소와 연결

<input ref={playerName} type="text" />

이 input 요소는 이제 playerName.current를 통해 접근할 수 있습니다.

3️⃣ 버튼 클릭 시 input 값을 가져와 상태 업데이트

function handleClick() {
    setEnteredPlayerName(playerName.current.value);
}

playerName.current.value를 읽어 enteredPlayerName 상태로 저장합니다.

useRef 으로 타이머 제어하기

시작한 타이머를 멈추려면 setTimeout의 반환값(타이머 ID)이 필요하기 때문에 clearTimeout(timerId)와 같이 호출하면 해당 타이머가 취소할 수 있습니다. 그러나 이때 변수를 사용하게 되면 문제가 발생하게 되는데 이런 경우를 아래 예제를 통해 알아보도록 합시다.

1️⃣ 변수(let timer 사용)의 문제점

import { useState } from "react";

let timer; // ❌ 전역 변수 사용 (문제 발생 가능)

function TimerChallenge() {
    const [timerExpired, setTimerExpired] = useState(false);

    function handleStart() {
        timer = setTimeout(() => {
            console.log("타이머 끝!");
            setTimerExpired(true);
        }, 5000);
    }

    function handleStop() {
        clearTimeout(timer);
    }

    return (
        <div>
            <button onClick={handleStart}>Start</button>
            <button onClick={handleStop}>Stop</button>
        </div>
    );
}

문제 발생:

let timer가 전역 변수라 여러 개의 타이머를 관리하기 여렵다는 문제가 발생합니다.

TimerChallenge 컴포넌트가 여러 개 생기면, 모든 인스턴스가 같은 timer 변수를 공유됩니다.
하나의 컴포넌트에서 handleStart를 실행하고, 다른 컴포넌트에서 handleStop을 실행하면 엉뚱한 타이머가 멈출 수 있습니다.

컴포넌트가 재렌더링되면 timer 값이 유지되지 않는 문제가 발생합니다.

setTimerExpired(true)가 실행되면 상태가 변경(setState)됨 → 리렌더링 발생
리렌더링 시 let timer 변수는 초기화 됩니다.
handleStop에서 clearTimeout(timer)을 호출해도 이전에 저장한 timer와 다를 수 있습니다. (타이머가 멈추지 않을 가능성이 있음)

2️⃣ useRef를 사용한 해결 방법

useRef는 렌더링을 발생시키지 않고 값을 유지할 수 있습니다.

import { useRef, useState } from "react";

function TimerChallenge() {
    const timer = useRef(null); // ✅ useRef를 사용하여 유지되는 값 저장
    const [timerExpired, setTimerExpired] = useState(false);

    function handleStart() {
        timer.current = setTimeout(() => {
            console.log("타이머 끝!");
            setTimerExpired(true);
        }, 5000);
    }

    function handleStop() {
        clearTimeout(timer.current);
    }

    return (
        <div>
            <button onClick={handleStart}>Start</button>
            <button onClick={handleStop}>Stop</button>
        </div>
    );
}

✅ 각 컴포넌트 인스턴스마다 독립적인 timer 값을 가집니다.

useRef를 사용하면, 컴포넌트별로 개별적인 timer 값을 유지합니다.
첫 번째 코드처럼 let timer가 전역적으로 공유되지 않음 → 여러 개의 TimerChallenge 인스턴스가 독립적으로 작동 가능합니다.

✅ 리렌더링이 발생해도 timer.current 값이 유지될 수 있습니다.

useRef는 상태 변경(setState)으로 인해 컴포넌트가 리렌더링 되어도 값이 초기화되지 않습니다.
setTimerExpired(true)로 인해 리렌더링이 일어나더라도 기존 타이머 ID가 유지됨 → handleStop이 정확한 타이머를 중지할 수 있습니다.

커스텀 컴포넌트로 Refs(참조) 전달

	import { useState, useRef } from "react";

function TimerChallenge() {
    const timer = useRef();
    const dialog = useRef();
    
		const [timerExpired, setTimerExpired] = useState(false);

    function handleStart() {
        timer.current = setTimeout(() => {
            console.log("타이머 끝!");
		        setTimerExpired(true);
            dialog.current.showModal(); // 타이머 끝나면 모달 표시 / 내장된 dialog 요소에 showModal 메소드 존재
        }, 5000);
    }

    function handleStop() {
        clearTimeout(timer.current);
    }

    return (
    	<>
    		{/* ResultModal 컴포넌트에 ref 전달 */}
            {<ResultModal ref={dialog} targetTime={targetTime} result="lost"/>}
            <div>
                <button onClick={handleStart}>Start</button>
                <button onClick={handleStop}>Stop</button>
            </div>
        </>
    );
}

import {forwardRef} from "react";

const ResultModal = forwardRef(function ResultModal ({ result, targetTime }, ref){
    return (
        <dialog ref={ref} className="result-modal">
            <h2>You {result}</h2>
            <p>
                target time : {targetTime}
            </p>
            <p>
                You stopped the timer with <strong>X seconds left.</strong>
            </p>
            <form method="dialog">
                <button>Close</button>
            </form>
        </dialog>
    );
});

export default ResultModal;

ResultModal은 forwardRef를 통해 ref를 받을 수 있도록 설정되어 있음.
부모 컴포넌트 TimerChallenge에서 useRef()를 사용하여 dialog라는 ref를 생성.
ResultModal ref={dialog}로 전달하면, dialog.current가 <dialog> 요소를 직접 가리킴.
dialog.current.showModal()을 호출하면 <dialog>이 표시됨.

리액트 19 이후에서는 아래와 같이 forwardRef를 사용하지 않고 간단하게 ref 를 자식 컴포넌트의 props를 통해 전달 받을 수 있습니다.

export default function ResultModal ({ ref, result, targetTime }){
    return (
        <dialog ref={ref} className="result-modal" open={true}>
            <h2>You {result}</h2>
            <p>
                target time : {targetTime}
            </p>
            <p>
                You stopped the timer with <strong>X seconds left.</strong>
            </p>
            <form method="dialog">
                <button>Close</button>
            </form>
        </dialog>
    );
}

userImperativeHandle 훅으로 컴포넌트 API 노출

리액트에서 useImperativeHandle 훅은 컴포넌트 내부에서 사용할 수 있는 메서드나 프로퍼티를 외부로 노출할 때 유용하게 사용됩니다. 일반적으로 ref는 DOM 요소나 컴포넌트 인스턴스를 참조하는 데 사용되지만, useImperativeHandle을 사용하면 외부에서 ref를 통해 특정 메서드를 호출할 수 있도록 설정할 수 있습니다.

import { useState, useRef } from "react";

function TimerChallenge() {
    const timer = useRef();
    const dialog = useRef();
    const [timerExpired, setTimerExpired] = useState(false);

    // 타이머 시작
    function handleStart() {
        timer.current = setTimeout(() => {
            console.log("타이머 끝!");
            setTimerExpired(true);
            dialog.current.open();  // 타이머 끝나면 모달을 열기 위해 open 메서드 호출
        }, 5000);
    }

    // 타이머 멈추기
    function handleStop() {
        clearTimeout(timer.current);
    }

    return (
        <>
            {/* ResultModal에 ref를 전달하여 외부에서 open을 호출할 수 있도록 함 */}
            <ResultModal ref={dialog} targetTime={5} result="lost" />
            <div>
                <button onClick={handleStart}>Start</button>
                <button onClick={handleStop}>Stop</button>
            </div>
        </>
    );
}

import { forwardRef, useImperativeHandle, useRef } from "react";

const ResultModal = forwardRef(function ResultModal({ result, targetTime }, ref) {
    const dialog = useRef();

    // 외부에서 호출할 수 있도록 open 메서드 노출
    useImperativeHandle(ref, () => {
        return {
            open() {
                dialog.current.showModal();  // dialog를 열기 위한 메서드
            }
        };
    });

    return (
        <dialog ref={dialog} className="result-modal">
            <h2>You {result}</h2>
            <p>Target time: {targetTime}</p>
            <p>
                You stopped the timer with <strong>X seconds left.</strong>
            </p>
            <form method="dialog">
                <button>Close</button>
            </form>
        </dialog>
    );
});

export default ResultModal;

TimerChallenge 컴포넌트는 버튼 클릭 시 타이머를 시작하고, 타이머가 끝나면 ResultModal을 열기 위해 dialog.current.open()을 호출합니다.
ResultModal 컴포넌트는 forwardRef와 useImperativeHandle을 사용하여 부모 컴포넌트에서 ref를 통해 접근할 수 있는 open 메서드를 노출합니다. 이 메서드는 dialog DOM 요소를 열기 위해 사용됩니다.
ResultModal의 ref는 TimerChallenge에서 전달되며, 이 ref는 useImperativeHandle을 통해 외부에서 호출 가능한 메서드를 노출하게 됩니다.

이 패턴의 장점

캡슐화 및 재사용성: ResultModal 내부 구현에 대한 정보를 숨기고, 외부에서는 open 메서드만을 호출하여 모달을 열 수 있습니다.
컴포넌트 독립성: ResultModal 컴포넌트는 외부에서 open 메서드를 통해 호출되므로, TimerChallenge는 ResultModal의 내부 구조에 의존하지 않습니다.
유연성: open 메서드는 언제든지 ResultModal 내부에서 변경할 수 있으며, 외부 코드에는 영향을 주지 않습니다.

React의 포털 (Portal)

포털(Portal)은 React에서 제공하는 기능 중 하나로, 컴포넌트의 렌더링 위치를 DOM 트리 내의 다른 위치로 옮길 수 있는 기능입니다. React 애플리케이션 내에서 특정 UI 요소(예: 모달, 팝업 등)가 페이지의 다른 위치에 렌더링되어야 할 때 유용하게 사용됩니다. 이를 통해 UI를 더 깔끔하게 관리할 수 있으며, 예를 들어 모달, 드롭다운, 툴팁 등 페이지 상단이나 다른 위치에 띄워야 할 UI에 유용합니다.

컴포넌트 렌더링 위치 변경: 포털을 사용하면, 예를 들어 모달이나 대화 상자처럼 중요한 UI 요소를 페이지 내 다른 위치에 렌더링할 수 있습니다.
DOM 트리 외부에 렌더링: 보통 모달 같은 UI는 페이지 내 다른 요소들과 겹치지 않도록 페이지의 최상위에 렌더링됩니다.
접근성 향상: 포털을 활용하면 HTML 요소의 위치를 의미적으로 더 적절한 곳으로 옮길 수 있어 접근성을 높일 수 있습니다.

예제

ResultModal 컴포넌트에서 createPortal을 사용하여 모달을 별도의 DOM 노드로 렌더링합니다.
TimerChallenge 컴포넌트에서 타이머 만료 시 모달을 열도록 합니다.

import { forwardRef, useImperativeHandle, useRef } from "react";
import { createPortal } from "react-dom";  // 포털을 사용하려면 react-dom에서 가져와야 함

const ResultModal = forwardRef(function ResultModal({ result, targetTime }, ref) {
    const dialog = useRef();

    useImperativeHandle(ref, () => {
        return {
            open() {
                dialog.current.showModal(); 
            }
        };
    });

    // 포털을 사용하여 모달을 'modal'이라는 id를 가진 div로 렌더링
    return createPortal(
        <dialog ref={dialog} className="result-modal">
            <h2>You {result}</h2>
            <p>Target time: {targetTime}</p>
            <p>
                You stopped the timer with <strong>X seconds left.</strong>
            </p>
            <form method="dialog">
                <button>Close</button>
            </form>
        </dialog>,
        document.getElementById('modal')  // 모달을 ID가 'modal'인 DOM 요소로 렌더링
    );
});

export default ResultModal;

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <link rel="icon" type="image/svg+xml" href="/vite.svg" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Refs & Portals</title>
  </head>
  <body>
    <div id="modal"></div>
    <div id="content">
      <header>
        <h1>The <em>Almost</em> Final Countdown</h1>
        <p>Stop the timer once you estimate that time is (almost) up</p>
      </header>
      <div id="root"></div>
    </div>
    <script type="module" src="/src/main.jsx"></script>
  </body>
</html>

포털을 사용하면, #modal이라는 div에 모달을 렌더링합니다.

[React] 컴포넌트 속성에 컴포넌트 전달하기

제가안난데여♪(´ε｀*) — Tue, 18 Mar 2025 23:41:29 +0900

React에서 children을 활용한 유연한 컴포넌트 만들기

React에서 컴포넌트를 만들다 보면, 내부에 어떤 내용이 들어올지 모르는 컨테이너 역할의 컴포넌트를 만들 일이 많다. 예를 들어, Sidebar, Dialog, Card 같은 컴포넌트들은 내부에 들어갈 요소가 정해져 있지 않다.

이럴 때 React의 children prop을 활용하면 꽤 유연하게 컴포넌트를 만들 수 있다. 하지만 children 외에도 특정 prop으로 컴포넌트를 직접 전달하는 방식도 있는데, 이 방법을 활용하면 더 구조적으로 UI를 구성할 수도 있다.

이번에 children과 특정 prop을 활용해 재사용 가능한 컴포넌트를 어떻게 만들고 활용할 수 있는지 직접 예제를 통해 정리해 보자.

children prop이란?

children은 컴포넌트가 감싸고 있는 내용을 그대로 전달해주는 특별한 prop이다. 부모 컴포넌트가 자식 요소를 렌더링할 때, 해당 요소를 동적으로 전달하는 데 사용된다.

예제: 기본적인 children 사용법

const Box = ({ children }) => {
  return <div className="box">{children}</div>;
};

const App = () => {
  return (
    <Box>
      <p>이 내용이 children으로 전달됩니다!</p>
    </Box>
  );
};

Box 컴포넌트 내부에서 {children}을 사용해서, 부모가 전달한 요소를 그대로 렌더링할 수 있도록 했다.

children을 활용한 유연한 컴포넌트 만들기

예를 들어, 여러 개의 콘텐츠 블록(이미지, 표, 텍스트, 버튼 등)을 표시해야 한다고 해보자.

각 블록은 제목을 가지고 있고, 내부에는 다양한 요소가 들어갈 수 있다. 이럴 때 Section 컴포넌트를 만들어서 재사용하면 좋다.

1. Section 컴포넌트 구현

const Section = ({ title, children }) => {
  return (
    <section className="box">
      <h2 className="title">{title}</h2>
      <div>{children}</div>  {/* children을 활용하여 다양한 요소를 삽입 가능 */}
    </section>
  );
};

Section 컴포넌트는 title과 children을 props로 받아, 제목을 표시하고 내부에 어떤 내용이든 들어갈 수 있도록 {children}을 활용했다.

2. Section 컴포넌트 활용

이제 Section을 사용해서 **네 가지 다른 섹션(이미지, 표, 텍스트, 버튼)**을 만들어 보자.

const App = () => {
  return (
    <div className="grid">
      <Section title="이미지">
        <img src="https://via.placeholder.com/150" alt="샘플 이미지" className="img" />
      </Section>

      <Section title="표">
        <table className="table">
          <thead>
            <tr>
              <th>항목</th>
              <th>값</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td>A</td>
              <td>100</td>
            </tr>
            <tr>
              <td>B</td>
              <td>200</td>
            </tr>
          </tbody>
        </table>
      </Section>

      <Section title="텍스트">
        <p className="text">이것은 샘플 텍스트입니다.</p>
      </Section>

      <Section title="버튼">
        <button className="btn">클릭</button>
      </Section>
    </

3. children을 사용하면 어떤 점이 좋을까?

✅ 재사용 가능 → Section 컴포넌트는 내부 콘텐츠에 구애받지 않고 여러 곳에서 사용 가능

✅ 유연성 → children을 활용하면 다양한 요소(이미지, 표, 버튼 등)를 자유롭게 삽입 가능

✅ 가독성 향상 → 코드가 모듈화되어 유지보수가 쉬워짐

특정 prop을 활용하여 컴포넌트 전달하기

children 외에도 특정 prop을 사용해서 컴포넌트를 직접 전달할 수 있다.

이 방식은 Vue의 Named Slots과 비슷하게 활용할 수 있으며, 특정 역할을 명확하게 나눠야 할 때 더 유용하다. 예를 들어, Card 컴포넌트에서 헤더와 푸터를 따로 지정하고 싶다면 특정 prop을 활용할 수 있다.

1. 특정 prop을 활용한 Card 컴포넌트

const Card = ({ header, content, footer }) => {
  return (
    <div className="card">
      {header && <div className="card-header">{header}</div>}
      <div className="card-content">{content}</div>
      {footer && <div className="card-footer">{footer}</div>}
    </div>
  );
};

header, content, footer를 prop으로 받아서 명확하게 역할을 분리했다.

2. Card 컴포넌트 활용

const App = () => {
  return (
    <div className="p-6 space-y-4">
      <Card
        header={<h2>  카드 제목</h2>}
        content={<p>이것은 카드의 내용입니다.</p>}
        footer={<button className="btn-primary">확인</button>}
      />

      <Card
        header={<h2>  데이터 카드</h2>}
        content={
          <table className="table">
            <thead>
              <tr>
                <th>항목</th>
                <th>값</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td>A</td>
                <td>100</td>
              </tr>
            </tbody>
          </table>
        }
        footer={<span>업데이트: 2025-03-18</span>}
      />
    </div>
  );
};

✅ 여기서 핵심은 header, content, footer에 컴포넌트를 직접 전달했다는 점이다.

children vs. 특정 prop 선택 기준

선택 기준 children 사용 특정 prop 사용

단순한 컨텐츠 삽입	✅	❌
여러 개의 영역이 필요한 경우	❌	✅
명확한 구조 분리가 필요한 경우	❌	✅
유연한 콘텐츠 삽입이 필요한 경우	✅	✅

한 개의 콘텐츠만 받는다면 children이 더 간단하고,

여러 개의 영역을 나눠야 한다면 특정 prop을 활용하는 것이 좋다!

[React] React 완벽 가이드 - 섹션 5: React로 투자 계산기 만들기 | 개발 회고

제가안난데여♪(´ε｀*) — Tue, 18 Mar 2025 02:25:43 +0900

이 글은 Udemy의 【한글자막】 React 완벽 가이드 2025 with React Router & Redux 를 수강하고 정리한 내용입니다.

프로젝트 개요

자세한 코드는 여기로 https://github.com/An0401na/React_Study/tree/main/01-starting-project

이번 프로젝트에서는 React를 활용한 투자 계산기를 개발했다.

사용자가 입력한 데이터를 기반으로 연간 투자 금액, 예상 수익률, 투자 기간을 계산하여

매년 누적된 투자 금액과 이자를 시각적으로 보여주는 기능을 구현했다.

React: 컴포넌트 기반 UI 개발
useState: 사용자 입력값을 상태로 관리
map(): 배열 데이터를 테이블 형식으로 렌더링
Intl.NumberFormat: 숫자를 화폐 단위로 변환

️ 구현 과정

1️⃣ 상태 관리 & 입력값 처리 (App.jsx)

사용자의 입력값을 useState로 관리하고, 변경될 때마다 상태를 업데이트하도록 했다.

또한 duration 값이 1년 이상인지 확인하여 유효한 경우에만 결과를 출력하도록 처리했다.


const [inputs, setInputs] = useState({
  initialInvestment: 10000, // 초기 투자금
  annualInvestment: 1200,   // 연간 투자금
  expectedReturn: 6,        // 예상 수익률 (%)
  duration: 10              // 투자 기간 (년)
});

const inputIsValid = inputs.duration >= 1;

function handleInputValueChange(inputIdentifier, newValue) {
  setInputs(prevInputs => ({
    ...prevInputs,
    [inputIdentifier]: +newValue // 문자열 → 숫자로 변환
  }));
}

✅ 배운 점

React에서 상태(state)를 객체로 관리할 때, 기존 데이터를 보존하면서 업데이트하는 패턴을 익혔다.
조건부 렌더링 (&&)을 활용해 특정 조건에서만 UI를 보여주는 방법을 활용했다.
+newValue를 사용하여 문자열을 숫자로 변환하여 상태를 업데이트하는 방식에 대해 알게 되었다.

2️⃣ ️ 입력 폼 컴포넌트 (Input.jsx)

컴포넌트 재사용성을 고려하여 입력 폼을 Input 컴포넌트로 분리했다.

onChange 이벤트를 활용해 부모 컴포넌트(App.jsx)의 상태를 업데이트한다.

export default function Input({ label, inputIdentifier, value, onChangeValue }) {
  function handleChange(event) {
    onChangeValue(inputIdentifier, event.target.value);
  }

  return (
    <p>
      <label>{label}</label>
      <inputtype="number"
        required
        value={value}
        onChange={handleChange}
      />
    </p>
  );
}

✅ 배운 점

props를 활용한 컴포넌트 재사용성 향상
onChange 이벤트 핸들러를 부모로 전달하는 리프팅(lifting state up) 패턴 적용

3️⃣ 투자 결과 테이블 렌더링 (Result.jsx)

입력된 값들을 기반으로 투자 결과를 연도별로 계산하여 테이블로 출력했

금액은 Intl.NumberFormat을 사용하여 화폐 형식으로 변환했다.

const results = calculateInvestmentResults(input);
let totalInterest = 0;
let investedCapital = input.initialInvestment;

return (
  <table id="result">
    <thead>
      <tr>
        <th>Year</th>
        <th>Investment Value</th>
        <th>Interest (Year)</th>
        <th>Total Interest</th>
        <th>Invested Capital</th>
      </tr>
    </thead>
    <tbody>
      {results.map((result) => {
        totalInterest += result.interest;
        investedCapital += input.annualInvestment;

        return (
          <tr key={result.year}>
            <td>{result.year}</td>
            <td>{formatter.format(result.valueEndOfYear)}</td>
            <td>{formatter.format(result.interest)}</td>
            <td>{formatter.format(totalInterest)}</td>
            <td>{formatter.format(investedCapital)}</td>
          </tr>
        );
      })}
    </tbody>
  </table>
);

✅ 배운 점

.map()을 사용해 배열 데이터를 동적으로 테이블에 렌더링
누적 값 (totalInterest)을 매년 업데이트하면서 계산하는 패턴

️ 트러블슈팅

❌ 1. Hydration Error: In HTML, whitespace text nodes cannot be a child of <tr>

발생 원인: JSX에서 <tr> 내부에 {/* 주석 */}을 사용하면서 불필요한 공백이 발생했기 때문

✅ 해결 방법:

JSX 내부에서는 주석을 <tr> 내부가 아닌 바깥쪽에 배치해야 한다.

{/* 각 연도의 투자 결과 표시 */}
<tr key={result.year}>
  <td>{result.year}</td>{/*태그 내(HERE) 주석 작성시 오류*/}
  <td>{formatter.format(result.valueEndOfYear)}</td>
  <td>{formatter.format(result.interest)}</td>
  <td>{formatter.format(totalInterest)}</td>
  <td>{formatter.format(investedCapital)}</td>
</tr>

❌ 2. useState 상태 업데이트 문제

문제 원인: useState의 불변성 위반

const [inputs, setInputs] = useState({INPUT});

function handleInputValueChange(input, newValue){
    setInputs(prevInputs => {
        console.log("Inputvalue change:", input, ":", newValue);
        let current = prevInputs;
        current.INPUT.initialInvestment = newValue; // ❌ 상태 직접 변경 (잘못된 코드)

        return current;
    })
}

문제 설명:

prevInputs를 직접 변경하면 React가 상태 변경을 감지하지 못해 컴포넌트가 리렌더링되지 않음.
React 상태는 불변성(immutable)을 유지해야 함.

✅ 해결 방법:

새로운 객체를 반환해야 함!

const [inputs, setInputs] = useState(INPUT);

function handleInputValueChange(input, newValue) {
    setInputs(prevInputs => {
        console.log("Input value change:", input, ":", newValue);
        return {
            ...prevInputs, // 기존 상태 복사
            [input]: newValue, // 변경된 값 적용
        };
    });
}

❌ 3. 변경된 값이 console.log에 찍히지 않는 문제

문제 원인: 잘못된 참조 사용

console.log("initialInvestment : "+INPUT.initialInvestment);

문제 설명:

INPUT은 useState로 관리하는 상태(state)가 아니고 단순한 변수이므로 상태 변경이 반영되지 않음.
console.log("initialInvestment : " + INPUT.initialInvestment);는 상태 업데이트 전 값을 참조함.

✅ 해결 방법:

상태 값인 inputs를 사용해야 변경된 값을 확인할 수 있음.

console.log("initialInvestment : " + inputs.initialInvestment);

프로젝트 결과물

배운 점 & 느낀 점

✅ useState를 활용한 상태 관리의 중요성을 다시 한 번 깨달았다.

✅ 컴포넌트 재사용성을 고려해 작은 단위로 분리하는 것이 유지보수에 도움이 된다.

✅ JSX에서 불필요한 공백을 조심해야 한다는 점을 배웠다.

✅ React에서 데이터 흐름을 관리하는 패턴 (props 전달, lifting state up 등)을 실습했다.

✅ +newValue를 사용하여 문자열을 숫자로 변환하여 상태 관리

이번 프로젝트를 통해 React의 기본 개념을 정리하고, 실제로 적용할 수 있었다!

더 나은 사용자 경험을 위해 차트 라이브러리와 애니메이션을 추가하는 것도 흥미로울 것 같다.

[React]스프레드 연산자를 통한 속성 전달 방식- id 전달

제가안난데여♪(´ε｀*) — Wed, 12 Mar 2025 01:39:51 +0900

속성(props) 전달에서 발생하는 문제와 해결 방법

리액트에서 커스텀 컴포넌트에 속성을 전달할 때, HTML의 기본 속성인 id나 className 같은 속성이 정상적으로 전달되지 않는 문제가 발생할 수 있습니다. 이 문제를 해결하는 방법과 함께, Forwarded Props를 이용해 어떻게 이러한 속성들을 전달할 수 있는지 설명해 보겠습니다.

1. 기본 코드 예시

먼저, 아래와 같은 기본 코드를 봅시다:

function UserProfile({name, age, children}) {
  return (
    <div >
      <h2>{name}</h2>
      <p>{age} years old</p>
      <div>{children}</div>  {/* 자식 요소 출력 */}
    </div>
  );
}

function App() {
  return (
    <UserProfile id="profile" className="user" name="John" age={30}>
      user
    </UserProfile>
  );
}

위 코드에서는 App 컴포넌트에서 UserProfile 컴포넌트로 id와 className을 전달하고 있습니다. 하지만 커스텀 컴포넌트인 UserProfile은 HTML 기본 속성을 자동으로 전달하지 않기 때문에, id="profile"과 className="user"가 실제로 div 태그에 적용되지 않습니다.

2. 문제점: 속성이 전달되지 않음

리액트에서 UserProfile 같은 커스텀 컴포넌트는 JSX에서 전달받은 속성을 기본적으로 DOM 요소로 전달하지 않습니다. 예를 들어, id와 className은 UserProfile 컴포넌트 내부에서 사용되지 않으며, 이 때문에 CSS가 적용되지 않습니다.

3. 해결 방법 1: 명시적으로 전달하기

이 문제를 해결하려면, UserProfile 컴포넌트에서 id와 className 속성을 명시적으로 div 태그에 전달해야 합니다.

function UserProfile({ name, age, children, id }) {
  return (
    <div id={id}>
      <h2>{name}</h2>
      <p>{age} years old</p>
      <div>{children}</div>  {/* 자식 요소 출력 */}
    </div>
  );
}

function App() {
  return (
    <UserProfile id="profile" className="user" name="John" age={30}>
      user
    </UserProfile>
  );
}

위처럼 UserProfile 컴포넌트 내에서 id={id}와 같은 방식으로 속성들을 명시적으로 전달하면, id와 className이 div 태그에 적용됩니다. 하지만, 만약 전달할 속성이 많아진다면, 코드가 복잡해질 수 있습니다.

4. 해결 방법 2: 구조분해할당과 스프레드 연산자 사용하기

속성 전달을 더욱 간단하게 처리하려면, 구조분해 할당과 스프레드 연산자(...props)를 사용할 수 있습니다. 이렇게 하면, UserProfile 컴포넌트에서 전달받은 모든 속성들을 자동으로 div 태그에 전달할 수 있습니다.

function UserProfile({ name, age, children, ...props }) {// 'name', 'age', 'children'을 구조분해하고, 나머지 props는 'div'에 전달
  return (
    <div {...props}> {/* 모든 속성(props)을 div에 전달 */}
      <h2>{name}</h2>
      <p>{age} years old</p>
      <div>{children}</div>  {/* 자식 요소 출력 */}
    </div>
  );
}

function App() {
  return (
    <UserProfile id="profile" className="user" name="John" age={30}>
      user
    </UserProfile>
  );
}

위와 같이 스프레드 연산자(...props)를 사용하면, UserProfile 컴포넌트로 전달된 모든 속성이 div 태그에 자동으로 적용됩니다. 이제 id, className, 그리고 다른 속성들도 문제없이 div 태그에 전달되어 적용됩니다.

5. 결과

위 코드에서는 id="profile"과 className="user"가 div 태그에 정상적으로 적용되어, 스타일링이 잘 이루어집니다. 브라우저에서 렌더링된 HTML은 다음과 같을 것입니다:

<div id="profile" class="user">
  <h2>John</h2>
  <p>30 years old</p>
  <div>user</div>
</div>

[React] 함수형 컴포넌트의 반환 return 값 조건 & Fragment(프래그먼트) <>...</>

제가안난데여♪(´ε｀*) — Tue, 11 Mar 2025 23:10:22 +0900

일반적인 함수에서 return 값을 두 개 가질 수 없듯이 함수형 컴포넌트에서도 여러 개의 요소를 반환 할 수 없다.

리액트 컴포넌트는 반드시 하나의 요소를 반환 해야한다. 이와 같이 리액트의 함수형 컴포넌트의 return 값에는 몇가지 조건이 있다.

✅ 1. 반드시 하나의 리액트 엘리먼트(React Element)를 반환해야 한다.

❌잘못된 예시 (여러 개의 요소를 반환)

function Welcome() {
  return <h1>Hello</h1>
         <p>React!</p>;  // 오류 발생 ❌
}

그러나 화면의 UI를 구성하기 위해서 하나의 엘리먼트로는 부족한 경우가 많다. 이를 해결하기 위해 불필요한 <div> 로 감쌀 수 있다.

⭕ 올바른 예시 (하나의 부모 요소로 감싸기)

function Welcome() {
  return (
    <div>
      <h1>Hello</h1>
      <p>React!</p>
    </div>
  );
}

불필요한 요소를 사용하지 않기 위해 Fragment (<>...</>) 를 사용하여 불필요한 <div> 없이도 감쌀 수 있다.

import { Fragment } from 'react';

function Welcome() {
  return (
    <Fragment>
      <h1>Hello</h1>
      <p>React!</p>
    </Fragment>
  );
}

function Welcome() {
  return (
    <>
      <h1>Hello</h1>
      <p>React!</p>
    </>
  );
}

✅ 2. 반드시 유효한 JSX 또는 리액트 엘리먼트를 반환 해야한다.

return 값으로 일반 문자열이나 숫자를 직접 반환하면 오류가 발생한다.

❌ 잘못된 예제:

function Welcome() {
  return "Hello, React!"; // 오류 발생 ❌
}

리액트 컴포넌트는 반드시 JSX 또는 React.createElement()를 반환해야 한다

⭕ 올바른 예제 (JSX를 사용):

function Welcome() {
  return <h1>Hello, React!</h1>; // 올바름 ⭕ 
}

또는 React.createElement를 사용:

function Welcome() {
  return React.createElement("h1", null, "Hello, React!"); // 올바름 ⭕ 
}

✅ 3. 배열 반환 가능 (React 16 이상)

React 16 이상에서는 배열을 반환하여 여러 개의 요소를 감싸지 않고도 렌더링할 수 있다.

⭕ 배열을 반환하는 예제:

jsx
복사편집
function Welcome() {
  return [
    <h1 key="1">Hello</h1>,
    <p key="2">React!</p>
  ];
}

배열 반환 시, 각 요소에는 key를 부여하자. 리액트가 리스트를 렌더링할 때 효율적으로 업데이트할 수 있도록 하기 위해

✅ 4. null, false, undefined, []도 반환 가능 (렌더링 안 됨)

아무것도 렌더링하고 싶지 않다면 null, false, undefined 등을 반환할 수 있다

예제:

function Welcome() {
  return null; // 화면에 아무것도 출력되지 않음
}

function Welcome({ show }) {
  return show ? <h1>Hello, React!</h1> : null;
}

위 코드에서 show가 true이면 <h1>Hello, React!</h1>를 렌더링하고, false이면 아무것도 렌더링하지 않는다.

[React] Element와 Componet의 차이

제가안난데여♪(´ε｀*) — Tue, 11 Mar 2025 22:40:30 +0900

Element

앱의 UI를 구성하는 가장 단위
immutable 객체(불변)
화면에 표시할 내용을 기술하는 단순한 객체이며, 실제 DOM 요소를 직접 만들지는 않는다.
React.createElement() 함수로 생성되며, JSX를 사용하면 더 쉽게 작성 가능하다.

const element = <h1>Hello, React!</h1>;

아래 element는 화면에 <h1>Hello, React!</h1>를 표현하는 객체일 뿐, 아직 실제 DOM에 반영된 것은 아니다. 리액트는 이러한 엘리먼트를 ReactDOM.render() 혹은 useState, useEffect 등의 업데이트 과정에서 가상 DOM을 통해 실제 DOM으로 변환합니다.

Component

리액트 엘리먼트를 반환하는 함수 또는 클래스
컴포넌트는 여러개의 엘리먼트들을 조합하여 재상용할 수 있도록 설계된다.
JSX를 반환하는 함수형 컴포넌트(Function Component) 또는 React.Component를 상속받는 클래스형 컴포넌트(Class Component)로 만들 수 있다.
컴포넌트는 자체적인 상태(state)와 생명주기(lifecycle) 를 가질 수 있다(함수형 컴포넌트에서는 useState, useEffect 같은 훅을 사용).

function Welcome() {
  return <h1>Hello, React!</h1>;
}

위의 Welcome 컴포넌트는 <h1>Hello, React!</h1> 엘리먼트를 반환하는 함수형 컴포넌트이다.
컴포넌트를 사용할 때는 JSX에서 태그처럼 사용

// jsx 미사용 시
const element = React.createElement(Welcome);

// jsx 사용시
const element = <Welcome />;

[React] React 완벽 가이드 - 섹션 3: 리액트의 핵심 - 컴포넌트, JSX, 속성, 상태 등

제가안난데여♪(´ε｀*) — Mon, 3 Mar 2025 18:05:33 +0900

이 글은 Udemy의 【한글자막】 React 완벽 가이드 2025 with React Router & Redux 를 수강하고 정리한 내용입니다.

Componet

재사용이 가능한 구성요소이다.
HTML, CSS, 자바스크립트 로직 등을 포함하고 있다.
사용하는 이유
- 컴포넌트가 없다면 html 코드가 방대하고 복잡해져 유지보수가 어려워질 수 있다.
- 오류 가능성이 줄어든다.
- 코드를 재활용 하는 방식이기 때문에 한 부분에서 일괄적으로 수정이 가능하다.
- 공통된 기능을 제공하는 유사한 코드가 묶여 작성되어 개발 과정이 단순해진다.
- 각 컴포넌트들 마다 각 기능별로 관심사가 분리되어 작업된다.
컴포넌트 저장 및 좋은 프로젝트 구조
src - assets - components - Header - Header.jsx - Header.css - App.jsx

JSX

JavaScript Syntax Extention, JavaScript 의 확장된 문법
함수를 추가하여 컴포넌트 생성이 가능하다.
JSX 문법은 브라우저에서는 사용이 불가능하지만 리액트 개발을 위해 작성하는 코드로 브라우저에 도달하기 전에 개발 서버에서 브라우저에서 사용 가능 하도록 변환된다.\
컴포넌트로 인식되기 위한 규칙
- 함수의 제목이 대문자로 시작
- 함수의 반환 값이 렌더링이 가능한 값(즉, 화면에 보여져야 하는 내용)

// App.jsx
// Header 컴포넌트 생성
function Header() {
  return ( // 반호나 값이 여러줄인 경우 괄호로 묶기
    <header>
      <img src="src/assets/react-core-concepts.png" alt="Stylized atom" />
      <h1>React Essentials</h1>
      <p>
        Fundamental React concepts you will need for almost any app you are going to build!
      </p>
    </header>
  );
}

// Header 컴포넌트 사용
<Header></Header>
// or
<Header/>

Element Rendering

Element 는 React 의 가장 작은 단위를 의미한다. (Element는 Componet의 “구성요소”) const element = <h1>Hello, world</h1>;
리액트로 구현된 어플리케이션은 일반적으로 하나의 루트 DOM 노드가 존재한다. <div id="root"></div>
이 루트 DOM 노드에 들어가는 모든 엘리먼트들을 React DOM에서 관리한다.
리액트 엘리먼트를 렌더링 하기 위해서는 DOM 엘리먼트를 ReactDOM.createRoot()에 전달한 다음, React 엘리먼트를 root.render()에 전달해야 한다.
```
const root = ReactDOM.createRoot(
  document.getElementById('root')
);
const element = <h1>Hello, world</h1>;
root.render(element);
```
import ReactDOM from "react-dom/client"; import App from "./App"; import "./index.css"; const entryPoint = document.getElementById("root"); ReactDOM.createRoot(entryPoint).render(<App />);
컴포넌트 계층구조를 의미하는 컴포넌트 트리는 리액트를 통해 화면으로 렌더링 될 뿐, 커스텀 컴포넌트는 실제로 렌더링된 DOM에 나타나지 않는다.

동적 값 출력 및 활용

jsx 또는 리액트에 중괄호{}를 사용하여 동적인 값을 출력 가능
요소 태그 사이에 넣을 수도 있고, 속성 값으로서도 사용할 수 있다.
단, 동적인 값을 표현할때 따옴표를 작성하지 않는다.

<p>{동적인 값의 변수}</p>
<img src={동적인 값의 변수}/>

const reactDescriptions = ["Fundamental", "Crucial", "Core"];

function genRandomInt(max) {
  return Math.floor(Math.random() * (max + 1));
}

function Header() {
  return (
    <header>
      <img src="src/assets/react-core-concepts.png" alt="Stylized atom" />
      <h1>React Essentials</h1>
      <p>
        {reactDescriptions[genRandomInt(2)]} React concepts you will need for
        almost any app you are going to build!
      </p>
    </header>
  );
}

이미지를 가져오는 최적의 방법 - import
- 이미지를 이런 식으로 불러올 경우 배포 시 이미지 파일이 무시되거나 유실 될 수 있다.
- 여러 추가적인 최적화 단계를 사용할 수 없다.
```
import reactImg from './src/assets/react-core-concepts.png';

...
<img src={reactImg} alt="Stylized atom" /> 
```
<img src="src/assets/react-core-concepts.png" alt="Stylized atom" />

Prop(속성)

Prop는 부모 → 자식 컴포넌트로 데이터를 전달하는 방법 (부모 → 자식 방향으로만 데이터 전달 가능)
읽기 전용이므로 자식 컴포넌트에서 prop 값을 변경 불가능하다.
일반적으로 props 라고 불리는 하나의 매개변수(변수명수정가능)만 사용해서 데이터를 전달할 때는 커스텀 특성은 key로 속성의 값은 value 형태로 객체화 되어 저장된다.

// 부모
function App() {
	return (
		...
		<CoreComcept title="Components" description="blablabla" image ={Img} />
		// or
		<CoreComcept {...CORE_CONCEPT[0]} /> // 스프레드 연산자 사용
		...
	);

// 자식
function CoreComcept (props) { 
	return (
		<img src={props.image} />
		<h3> {props.title}</h3>
		<p>{props.descriptsion>/<p>
	);
}

// 구조분해 한 방식
function CoreComcept ({image, title, description}) { // 
	return (
		<img src={image} />
		<h3> {title}</h3>
		<p>{description}>/<p>
	);
}

Children Prop

컴포넌트 태그 사이의 텍스트를 저장하는 prop
prop의 명이 무조건 children이어야 함.

<TapButton>buttonName</TapButton>

------------------------------

export default function TapButton(props) {
	return <button>{props.childeren}</button>; // props.childeren === buttonName
// or
export default function TapButton({childeren}) { // 객체 구조분해
	return <button>{childeren}</button>; // props.childeren === buttonName

Event 처리

button 태그의 on ~ 으로 시작하는 prop 추가 (ex)onClick)
- 커스텀 컴포넌트인 TabButton의 propd으로 생성한 onSelect는 개발자 임의로 명칭을 변경가능하다.
on ~ 으로 시작하는 이벤트 prop(여기서는 onClick)의 값은 함수. (onSelect 속성 값을 onClick으로 넘겨줌으로 여기서는 onSelect 를 예시로 든다.)
- onSelect=handleSelect() 와 같이 소괄호를 붙이지 않는다. 이 경우 handleSelect()의 반환 값이 속성의 값으로 전달되어 렌더링 될 때 바로 실행되기 때문
- onSelect=hadleSelect 와 onSelect={() => handleSelect('component')} 두 방식은 함수의 참조값을 전달하며 두 방식의 차이는 매개변수를 넘길 수 있다, 없다 의 차이를 가진다.
TapButton을 실행하면 handleSelect 함수가 실행

// App.jsx
function App() {
	
	function handleSelect(selectedButton) {
		// selectedButton => component, jsx, props, state
		
	}
	return (
		<TapButton onSelect={() => handleSelect('component')}>component</TapButton>
		<TapButton onSelect={() => handleSelect('jsx')}>jsx</TapButton>
		<TapButton onSelect={() => handleSelect('props')}>props</TapButton>
	);
}
------------------------------

export default function TapButton({childeren , onSelect}) {
	return <button onClick={onSelect}>{childeren}</button>;
}

UI가 업데이트 되지 않는 이유 - State를 사용하는 이유

// App.jsx
function App() {
	let tabContent = "hello";
	
	function handleSelect(selectedButton) {
		tabContent = selectedButton;
		console.log(tabConent)
	}
	
	return (
		<TapButton onSelect={() => handleSelect('component')}>component</TapButton>
		{tabContent}
	);
}

------------------------------

export default function TapButton({childeren , onSelect}) {
	return <button onClick={onSelect}>{childeren}</button>;
}

App.jsx의 component 버튼을 누르면 handleSelect 함수를 통해 tabContent의 값이 “component”로 변경 될 것이다. 그리고 {tabContent}의 내용의 hello 에서 component로 변경될 것이라 예상하지만 아무리 버튼을 눌러도 콘솔에 찍히는 로그만 component로 변경되어 찍힐 뿐, 화면의 텍스트는 바뀌지 않는 것을 확인할 수 있다.
그 이유는 handleSelect 함수가 실행되었어도 변수만 변경될 뿐, App 컴포넌트 함수가 실행되지 않아 UI가 업데이트 되지 않는 것이다.
그러므로 App 컴포넌트 함수가 재실행 되어야 한다는 것을 리액트에게 알려줄 필요가 있다.
이는 State 를 이용하여 구현 가능하다.

State(상태) & Hook(훅)

use ~ 로 시작하는 모든 함수는 리액트 Hook 이다.
- Hook은 컴포넌트 함수 또는 다른 리액트 Hook에서만 호출 될 수 있다.
- Hook은 컴포넌트 함수 최상위에서 호출해야하며 내부 함수나 if문 또는 loop문 안에 중첩되어선 안된다.
리액트 라이브러리의 useState 라는 함수의 도움을 받아 리액트에게 데이터가 변한 것을 알려주면 리액트가 UI를 업데이트 하도록 한다.
- useState Hook은 일부 컴포넌트에 연결된 상태를 관리하는데, 일부 데이터가 변경되면 이 Hook이 자신이 속한 컴포넌트 함수를 활성화 하여 리액트에 의해 재검토하게 된다.
- useState의 반환 값은 배열로, 첫번째 요소는 컴포넌트 실행 주기의 현재 데이터 값이며, 두번째 요소는 이 상태를 업데이트 하기 위해 실행되는 함수이다. 두번째 요소인 함수가 호출되면 리액트에 컴포넌트 함수가 다시 실행되어야 함을 알려준다.

import {useState} from 'react';

function App() {
	const [selectedTopic, setSeletedTopic] =	useState("hello");
	
	function handleSelect(selectedButton) {
		setSeletedTopic(selectedButton);
		console.log(selectedTopic)
	}
	
	return (
		<TapButton onSelect={() => handleSelect('component')}>component</TapButton>
		{selectedTopic}
	);
}

조건적 콘텐츠 렌더링

import {useState} from 'react';

function App() {
	const [selectedTopic, setSeletedTopic] =	useState("hello");
	
	function handleSelect(selectedButton) {
		setSeletedTopic(selectedButton);
		console.log(selectedTopic)
	}
	
	return (
		...
		{!selectedTopic ? <p>hello</p> : <p>{EXAMPLES[selectedTopic].title}</p>}
		// or
		{!selectedTopic && <p>hello</p>}
		{selectedTopic &&  <p>{EXAMPLES[selectedTopic].title}</p>}
	);
}

Css 스타일링 및 동적 스타일링

jsx 에서는 버튼에 클래스를 추가하기 위해서는 className을 사용한다.

// App.jsx
function App() {
	const [selectedTopic, setSeletedTopic] =	useState("hello");
	
	function handleSelect(selectedButton) {
		setSeletedTopic(selectedButton);
		console.log(selectedTopic)
	}
	
	...
	return (
		<TapButton isSelected={isSelected==='component'}
							 onSelect={() => handleSelect('component')}>component</TapButton>
	);
}

------------------------------

export default function TapButton({childeren , onSelect, isSelected}) {
	return <button className={isSelected ? 'active' :undefined} onClick={onSelect}>{childeren}</button>;
}

List 데이터 동적 츨력

.map 함수를 이용하여 list 의 수만큼 자동으로 컴포넌트가 출력할 수 있도록 수정
.map 함수를 이용하여 list 데이터를 출력 할때 각 항목을 식별할 수 있는 key를 부여하면 리액트가 변경을 효율적으로 감지하며 key 값을 기준으로 어떤 요소가 변경, 추가, 삭제 되었는지 판단하기 때문에 불필요한 리렌더링을 방지하고, 렌더링 성능을 최적화 할 수 있다.
key 속성이 없다면 매번 전체 리스트를 다시 렌더링하여 불필요한 렌더링이 발생하고, 리스트 중간에 요소가 추가, 삭제 되는 경우 모든 항목을 다시 그릴 수 있어 성능 저하에 발생한다.

// 부모
function App() {
	return (
		...
		<CoreComcept title="Components" description="blablabla" image ={Img} />
		// or
		<CoreComcept {...CORE_CONCEPT[0]} /> // 스프레드 연산자 사용
		...
		// or
		{CORE_CONCEPT.map((conceptItem) => <CoreComcept key={conceptItem.title} {...CORE_CONCEPT[conceptItem]} /> ) // map 함수로 list 동적 출력
	);

[React] React 완벽 가이드 - 섹션 1: 시작하기

제가안난데여♪(´ε｀*) — Sat, 15 Feb 2025 00:49:30 +0900

이 글은 Udemy의 【한글자막】 React 완벽 가이드 2025 with React Router & Redux 를 수강하고 정리한 내용입니다.

리액트는 무엇일까?

사용자 인터페이스를 구축하기 위한 자바스크립트 라이브러리
리액트는 자바 스크립트 라이브러리라서 재 로딩 없이 웹페이지와 페이지에 표시되는 사용자 인터페이스를 업데이트 가능하기 때문에 사용자에게 즉각적인 반응과 부드러운 전환 경험을 제공한다.
- 자바 스크립트는 백그라운드에서 실행되기 때문에 로딩이 완료된 페이지를 재로딩 없이 새로운 데이터로 업데이트가 가능하다.

리액트가 자바스크립트 라이브러리라면 왜 자바스크립트가 아닌 리액트를 사용해야 할까?

순수 자바스크립트만으로 구현하는 것 보다 쉽고 빠르게 구축하도록 도와주기 때문
HTML 코드와 자바스크립트 코드를 섞어 쓸 수 있다.
선언형으로 작성하기 때문(목표로 하는 상태를 정의할 뿐, 거쳐야할 단꼐는 정의하지 않는다.)
- 자바스크립트는 명령형 (거쳐야할 단계들을 정의한다.) → 번거로움

[CI/CD] gitHub Action으로 CI/CD 구축하고 인간젠킨스 탈출하다! (feat. Self-hosted runner)

제가안난데여♪(´ε｀*) — Wed, 6 Nov 2024 22:42:00 +0900

0. 들어가기 전

1. 환경

Host 서버
- CentOS Linux 7 (Core)
- Linux 3.10.0-862.el7.x86_64
Docker 버전
- Docker version 19.03.4
Self-hosted runner 컨테이너
- CentOS Linux 8
프로젝트
- Java 11
- Maven

2. 배경

나는야 인간 젠킨스 … 수동 배포를 맡고 있지.

두 프로젝트를 진행하면서 본사 외부에서 본사 개발 서버에 배포 요청이 들어올 때마다 곤란하곤 했다. 또 작업 후에 배포까지 바로 못해드리는 경우가 있어서 수정사항 확인이 늦어지곤 했는데 이를 해결 하기 위해 CI/CD를 구축해보고자 마음먹었다.

3. 설계 히스토리

gitAciton 을 선택하게 된 배경
- 더보기
  CI/CD 툴은 Jenkins와 gitAction 중에 고민하였다.
  하루라도 빨리 CI/CD를 구축하기 위해 러닝커브가 낮다는 gitAction으로 정했다.
  형상관리도 git으로 하고 있기에 다른 개발자 분들도 배포상태를 확인하는데 더 편리하지 않을까 싶었다.

Self-hosted runner 를 선택하게 된 배경
- GitHub-hosted runner 와 Self-hosted runner 란?
- 더보기
  
  처음에는 GitHub-hosted runner를 사용하여 배포하려고 했으나, 성공하지 못했다.
  
  그 이유는 회사의 개발 서버로 배포하는 것이 목표였으며, 이를 위해 runner 서버에서 사내 개발 서버로 배포 파일을 전송하기 위해서는 scp 명령어를 사용하는 ssh 포트 개방이 필요했다. 그러나 GitHub-hosted runner의 경우 고정된 IP 주소나 도메인을 제공하지 않으며, GitHub-hosted runner는 GitHub 인프라에서 동적으로 실행되기 때문에 작업을 처리하는 동안 IP 주소가 계속 변경된다. 이로 인해 방화벽 규칙에 IP 주소를 등록해 포트를 개방하는 방식은 사용할 수 없었다. 결과적으로 빌드된 파일을 개발 서버로 전송할 수 없었으며, 이 문제를 해결하기 위해 설계를 변경해야 했다.
  
  이러한 문제를 해결하기 위해, Self-Hosted Runner를 사내 네트워크 내부에 구축하여 개발 서버와 통신할 수 있는 환경을 만들고자 했다.

Self-hosted runner 를 어디에 어떻게 구축할 것인가 ?
- 더보기
  배포 서버에 구축할 수도 있었지만, 해당 서버는 다른 프로젝트도 함께 사용하고 있어 서버에 영향을 최소화하기 위해 도커로 구축하기로 했다. 또한, 프로젝트 자체도 도커로 관리되고 있었기 때문에 runner 서버를 도커 컨테이너에서 운영하면 함께 관리하기에 더 적합할 것이라 판단하여 도커 컨테이너에 runner를 띄우기로 했다.

아래는 ssh 포트 개방 불가 문제를 해결하기 위해 생각하며 작성했던 메모들이다. 기록을 위함이 참고는 말자 ㅎ

1. 깃 액션에 vpn 설정해서 내 vpn 계정으로 사내망 접근
  [Access Private Server with GitHub Actions (VPN connection)](https://medium.com/@mahmutali.mas/access-private-server-with-github-actions-vpn-connection-cf20313abdd5)

     - vpn 접근울 위한 인증서 필요 → 인프라팀에 요청해보자.
     - vpn  관련하여 관리하고 있는 인증서가 없다고함.
     - vpn 설정해서 사내망 접근 방법은 불가…
2. github Action IP 주소를 확인해서 인바운드 규칙에 적용하고 배포 후에 인바운드 규칙에서 제거
     - 고정 ip 가 아니고 매번 배포 할때마다 ip 주소 확인해야함 → 자동 배포의 의미가 없음
     - 보안 취약 위험성 있음
3. 배포 서버에 셀프 호스티드 러너 서버를 도커 컨테이너로 띄운 다음에 거기에 java랑 빌드 도구 설치해두고 여기서 빌드 후 빌드가 다 되면 배포 컨테이너로 배포 파일 옮겨서 배포
     - 성공!
4. 젠킨스……

4. 목표 설계 아키텍처

Git에서 변경 사항을 푸시하면 GitHub Actions가 동작.
Self-hosted runner 컨테이너가 빌드 작업을 수행
빌드된 .war 파일을 웹서버 컨테이너로 이동.
웹서버 컨테이너를 재시작하여 새로운 버전의 애플리케이션을 배포.

5. ⭐작업 요약⭐

CentOS 8 컨테이너를 생성
컨테이너 내에 Docker를 설치하여 컨테이너 내부에서 .war 파일을 옮길 수 있도록 구성
Java 및 Maven을 설치하고 빌드 환경 설정
GitHub 페이지에서 self-hosted runner 생성 및 컨테이너 내에 action-runner 설치 및 연결
GitHub Actions 워크플로우 (.yml 파일) 작성하여 CI/CD 파이프라인 구축

1. CentOS 8 컨테이너를 생성

0. Self - hosted runner 로 사용할 컨테이너 생성 - ⭐Dockerfile⭐

아래 작업들을 Dockerfile에 작성하여 한번에 해결 할 수 있도록 정리하였다.

1. CentOS 8 컨테이너를 생성
2. 컨테이너 내에 Docker를 설치하여 컨테이너 내부에서 .war 파일을 옮길 수 있도록 구성
3. Java 및 Maven을 설치하고 빌드 환경 설정

Dockerfile⏬

# CentOS 8 이미지를 기반으로 시작
FROM centos:8

# BaseOS, Extras, AppStream 리포지토리 파일 수정 (vault.centos.org로 변경)
RUN sed -i 's|^mirrorlist=|#mirrorlist=|g' /etc/yum.repos.d/CentOS-Linux-BaseOS.repo \
    && sed -i 's|^#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' /etc/yum.repos.d/CentOS-Linux-BaseOS.repo \
    && sed -i 's|^mirrorlist=|#mirrorlist=|g' /etc/yum.repos.d/CentOS-Linux-Extras.repo \
    && sed -i 's|^#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' /etc/yum.repos.d/CentOS-Linux-Extras.repo \
    && sed -i 's|^mirrorlist=|#mirrorlist=|g' /etc/yum.repos.d/CentOS-Linux-AppStream.repo \
    && sed -i 's|^#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' /etc/yum.repos.d/CentOS-Linux-AppStream.repo \
    && sed -i 's|$releasever|8.5.2111|g' /etc/yum.repos.d/CentOS-Linux-BaseOS.repo /etc/yum.repos.d/CentOS-Linux-Extras.repo /etc/yum.repos.d/CentOS-Linux-AppStream.repo

# YUM 캐시를 정리하고 새로고침
RUN yum clean all && yum makecache

# 시스템의 패키지 목록을 업데이트하여 최신 버전으로 유지
RUN yum update -y

# Docker 설치를 위해 필요한 도구 패키지 설치 (yum-utils)
RUN yum install -y yum-utils

# Docker의 공식 저장소를 시스템에 추가하여 Docker 패키지 다운로드 가능하게 설정
RUN yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

# Docker CLI를 포함한 Docker 패키지 설치
RUN yum install -y docker-ce-cli

# Docker 버전 확인 (설치가 제대로 되었는지 검증)
RUN docker --version

# Java 11 OpenJDK 설치
RUN yum install -y java-11-openjdk

# Maven 설치
RUN yum install -y maven

# 기본 쉘로 시작
CMD ["/bin/bash"]

# --------------------------------------
# --------------------------------------
# 빌드 
# docker build -t cicd-docker-image .

# 실행
# docker run -it --name my_cicd_container -v /var/run/docker.sock:/var/run/docker.sock cicd-docker-image /bin/bash

만약 위 도커파일이 제대로 빌드 되지 못한다면 아래 과정을 손수 경험하자 ^_^

잘 실행된다면 4번(GitHub 페이지에서 self-hosted runner 생성 및 컨테이너 내에 action-runner 설치 및 연결)으로 바로 넘어가자.

1. centos:8 이미지 받기

docker pull centos:8

[참고] centos 버전을 7이 아닌 8을 사용하는 이유

[참고] centos 버전을 7이 아닌 8을 사용하는 이유 : /actions-runner/externals/node20/bin/node: /lib64/libm.so.6: ve

Self-hosted runner 를 구축하기 위해서 Centos7을 컨테이너로 띄웠고 ci/cd 파이프라인을 도는 과정에서 오류가 발생하였다.

velog.io

2. Centos 컨테이너 생성 및 실행

docker run -it --name cicd_runner -v /var/run/docker.sock:/var/run/docker.sock centos:8 /bin/bash

/var/run/docker.sock 을 마운트 하는 이유 : 호스트 머신의 Docker 엔진에 접근해 docker cp 명령어를 사용하기 위함.

이 runner 컨테이너에서 .war 파일를 web 서버 컨테이너로 옮겨야한다.
runner 컨테이너에서 web 서버 컨테이너로 옮기기 위해 docker cp 명령어를 사용해야한다.
컨테이너 내부에서 호스트의 도커를 컨트롤 하기 위해서는 호스트 머신의 Docker 엔진에 접근할 수 있어야 한다.
그러기 위해서는 docker.sock 파일을 마운트하여 컨테이너를 생성하고, Docker CLI를 설치하여 컨테이너 내에서 실행된 Docker 명령어가 호스트의 Docker 환경에 영향을 미치게 된다. 따라서, 이 방법을 사용할 때는 주의가 필요하다.

이러한 설정을 통해, runner 서버에서 호스트의 Docker 환경을 활용하여 컨테이너를 관리하고 빌드 작업을 수행할 수 있다.

3. Centos8 기본 레포지토리 변경

CentOS 8이 2021년 12월 31일에 공식적으로 지원이 종료되면서, 기본 리포지토리(mirrorlist.centos.org)는 더 이상 CentOS 8 패키지에 대한 업데이트나 접근을 제공하지 않는다. 이로 인해 CentOS 8에서 기본 mirrorlist 경로를 사용하면 패키지 다운로드에 실패하게 된다. 이를 접근 가능한 리포지토리 url로 변경해주어야 한다.

yum update

위 명령어를 입력 시 아래와 같이 오류가 발생한다면 아래 링크를 참고하여 해결하자.

[Centos]Failed to download metadata for repo 'appstream' 에러 해결

[Centos] Failed to download metadata for repo 'appstream' 에러 해결

Failed to download metadata for repo 'appstream' 에러 해결

velog.io

2. Docker CLI를 포함한 Docker 패키지 설치

docker cp 명령어를 사용하기 위해 컨테이너 내에서 docker CLI를 설치한다.

앞서 말했다시피 /var/run/docker.sock 을 마운트 하여 컨테이너를 생성했기 때문에 호스트 머신의 Docker 엔진에 접근이 가능해졌다.

# 시스템의 패키지 목록을 업데이트하여 최신 버전으로 유지
yum update

# Docker 설치를 위해 필요한 도구 패키지 설치 (yum-utils)
yum install -y yum-utils

# Docker의 공식 저장소를 시스템에 추가하여 Docker 패키지 다운로드 가능하게 설정
yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

# Docker CLI를 포함한 Docker 패키지 설치
yum install -y docker-ce-cli

# Docker 버전 확인 (설치가 제대로 되었는지 검증)
docker --version

+) 만약 설치가 제대로 된 것 같은데 실행이 안된다면 /var/run/docker.sock 의 소유계정과 그룹을 살펴보자.

[Docker] permission denied while trying to connect to the Docker daemon socket at unix 에러 해결

Docker를 컨테이너에서 실행하거나, 호스트의 Docker 소켓(/var/run/docker.sock)을 컨테이너에 마운트하여 사용하는 경우, 예상치 못한 권한 문제로 인해 Docker 명령이 작동하지 않을 때가 있습니다. 이

velog.io

3. Java 및 Maven을 설치하고 빌드 환경 설정

1. java 11 설치

+) 자바를 설치하긴 했는데 워크플로우 타면서 java 인식이 안되서 빌드가 안되는 문제가 있었다.

그래서 나는 워크플로우에 자바 set 하는 단계를 추가하여 해결하였다. 만약 java 설치에 애를 먹는다면 넘어가도 될 것 같다.

# 설치
yum install -y java-11-openjdk

# 설치 확인
java --version

2. maven 설치

# 설치
yum install maven -y

# 설치 확인
mvn -v

4. self-hosted runner 생성

1. GitHub 설정

Github Actions을 사용하고자 하는 저장소에서 Settings - Actions - Runners로 이동
New self-hosted runner 를 클릭하여 runner를 생성
Runner image를 runner 서버 환경에 맞게 설정
아래 사진과 같이 환경에 맞게 명령어를 제공해주는데 차근차근 서버에 입력해보자

2. 컨테이너 설정

Download

 # 폴더 생성
 $ mkdir actions-runner && cd actions-runner

 # 최신 러너 패키지 다운로드
 $ curl -o actions-runner-linux-x64-2.320.0.tar.gz -L https://github.com/actions/runner/releases/download/v2.320.0/actions-runner-linux-x64-2.320.0.tar.gz

 # 선택 사항: 해시 검증
 # 해시 검증 패키시 다운
 $ yum install -y perl-Digest-SHA
 # 해시 검증
 $ echo "93ac1b7ce743ee85b5d386f5c1787385ef07b3d7c728ff66ce0d3813d5f46900  actions-runner-linux-x64-2.320.0.tar.gz" | shasum -a 256 -c

 # 설치 프로그램 추출
 $ tar xzf ./actions-runner-linux-x64-2.320.0.tar.gz

아래 과정은 GitHub Actions의 Self-hosted Runner를 설치하는 과정이다. 위에서 runner 로 사용할 컨테이너를 생성해두었으니 그 컨테이너 내부에서 아래 명령어를 하나씩 입력하자.

Configure

# GitHub Actions Self-Hosted Runner를 GitHub 리포지토리에 등록
$ ./config.sh --url https://github.com/An0401na/CICD-Test --token AXUUDYARWPNHASTYBPWTWPLHFDNX6

# 마지막 단계, 실행하기!
$ ./run.sh

⏬ [트러블 슈팅] Must not run with sudo

⚽ 발생 오류

[root@9ca5fc8c7aa5 actions-runner]# ./config.sh --url https://github.com/An0401na/CICD-Test --token 
Must not run with sudo

⚽발생 원인
./config.sh 스크립트를 실행할 때 "Must not run with sudo"라는 오류 메시지가 나타나는 것은 스크립트가 sudo로 실행되었기 때문이다. GitHub Actions의 self-hosted runner 설정 시 sudo를 사용하지 않아야 한다.
아래 ./config.sh 명령어를 실행하기 전에 runner를 관리할 사용자 계정을 생성해야 한다.

⚽ 해결방법
컨테이너 내부에서 docker.sock을 사용하려면, docker 그룹과 컨테이너 내부의 사용자 설정이 일치해야 한다. 이를 위해 컨테이너 내부에서 docker 그룹 ID를 호스트와 동일하게 맞추고, 해당 사용자 계정을 docker 그룹에 추가하는 방법이 있다.

# 컨테이너 내부에서 실행

# docker.sock 파일의 소유자를 확인하려면 다음 명령어를 사용
$ ls -l /var/run/docker.sock

# -- 아래와 같은 형식으로 출력
srw-rw----. 1 root 1001 0 Oct  2 02:22 /var/run/docker.sock

- root는 파일의 소유자(user)
- 1001는 파일의 소유 그룹(group)ID

docker.sock 을 소유하고 있는 그룹은 docker 이고 docker 의 그룹 ID가 1001임을 기억하자.
runner 컨테이너 내부에서 아래 명령어 실행

⏬ [트러블 슈팅] ldd: warning: you do not have execution permission for `./bin/libcoreclr.so'

⚽발생 오류

[runner@1fe76c6022dc actions-runner]$ ./config.sh --url https://github.com/An0401na/CICD-Test --token AXUUDYFGWY3AOXFA6SULMMDHFDVIM
ldd: warning: you do not have execution permission for `./bin/libcoreclr.so'
ldd: warning: you do not have execution permission for `./bin/libSystem.Security.Cryptography.Native.OpenSsl.so'
ldd: warning: you do not have execution permission for `./bin/libSystem.IO.Compression.Native.so'
Libicu's dependencies is missing for Dotnet Core 6.0
Execute sudo ./bin/installdependencies.sh to install any missing Dotnet Core 6.0 dependencies.

⚽발생 원인

경고 메시지 ldd: warning: you do not have execution permission for는 ./bin/libcoreclr.so, ./bin/libSystem.Security.Cryptography.Native.OpenSsl.so, ./bin/libSystem.IO.Compression.Native.so 파일들이 실행 권한이 없어 의존성 확인에 실패했음을 의미한다.

아래 명령어를 따라가며 해결하자.

⚽해결 방법

# root로 계정 전환
$ exit 

# 모든 바이너리 파일에 대해 실행 권한 부여
$ chmod +x ./bin/*

# 의존성 설치 스크립트 실행
$ ./bin/installdependencies.sh

# /actions-runner 디렉토리에 대한 쓰기 권한 부여
$ chmod -R 777 /actions-runner

# runner로 계정 전환
su runner

# GitHub Actions Self-Hosted Runner를 GitHub 리포지토리에 등록
$ ./config.sh --url https://github.com/An0401na/CICD-Test --token AXUUDYARWPNHASTYBPWTWPLHFDNX6

Runner를 생성하기 위한 몇가지 정보를 받는다. 나는 아래와 같이 입력했지만 선택사항이므로 잘 해석해서 입력하면 된다.

# Runner Registration

Enter the name of the runner group to add this runner to: [press Enter for Default] 

Enter the name of runner: [press Enter for 1fe76c6022dc] CICD-Test

This runner will have the following labels: 'self-hosted', 'Linux', 'X64' 
Enter any additional labels (ex. label-1,label-2): [press Enter to skip] self-hosted,centos8,docker

√ Runner successfully added
√ Runner connection is good

# Runner settings

Enter name of work folder: [press Enter for _work] cicd_work

√ Settings Saved.

이로써 GitHub Action Self-hosted runner가 정상적으로 생성되었다.

$ ./run.sh

실행하면

이렇게 리스닝 상태임을 확인할 수 있다.

5. GitHub Actions 워크플로우 작성

Github 페이지의 Action 탭을 활용해 자동으로 생성할 수도 있고,

레포명/.github/workflows/????.yml 로 생성하여 워크플로우를 작성할 수도 있다.

나는 후자를 택하였다.

CICD-Test/.github/workflows/cicd.yml 로 지정하였다.

name: CI/CD Pipeline  # 파이프라인의 이름 정의

on:
  push:  # 'push' 이벤트에 대한 트리거 설정
    branches:
      - main  # 'main' 브랜치에 푸시될 때 트리거 발생
  pull_request:  # 'pull_request' 이벤트에 대한 트리거 설정
    branches:
      - main  # 'main' 브랜치로의 PR 생성 시 트리거 발생

jobs:
  build:
    runs-on: self-hosted  # 셀프 호스티드 러너에서 이 작업이 실행됨 (GitHub 호스티드 대신 로컬 서버에서 실행)

    steps:
      - name: Checkout code  # 코드를 체크 아웃하는 단계
        uses: actions/checkout@v2  # GitHub Actions에서 제공하는 체크아웃 액션 사용
        # 이 단계에서는 레포지토리의 코드를 셀프 호스티드 러너로 가져옵니다.

      - name: Set up JDK 11  # JDK 11을 설정하는 단계
        uses: actions/setup-java@v1  # GitHub Actions에서 제공하는 Java 설정 액션 사용
        with:
          java-version: '11'  # 사용할 Java 버전을 '11'로 지정
        # 이 단계에서는 JDK 11을 설치하여 빌드 환경을 준비합니다.

      - name: Build with Maven  # Maven을 사용하여 프로젝트 빌드
        run: mvn package  # Maven으로 패키지 명령 실행
        # 이 단계에서는 Maven을 사용해 프로젝트를 빌드하여 .war 파일을 생성합니다.
        # Gradle을 사용하는 경우, ./gradlew build 명령을 사용해야 합니다.

      - name: Backup existing ROOT.war and copy new WAR file  # 기존 WAR 파일 백업 및 새 WAR 파일 복사
        run: |
          TIMESTAMP=$(date +%Y%m%d%H%M%S)  # 현재 시간 포맷: YYYYMMDDHHMMSS
          # 현재 시간을 기준으로 타임스탬프를 생성하여 백업 파일 이름에 사용

          # 기존 ROOT.war 파일을 ROOT.war.<현재시간> 으로 백업
          docker exec web_container mv /usr/local/tomcat/webapps/ROOT.war /usr/local/tomcat/webapps/ROOT.war.$TIMESTAMP
          # 기존 웹 컨테이너 내의 ROOT.war 파일을 백업

          # 새로운 WAR 파일을 컨테이너에 복사
          docker cp target/test-0.0.1-SNAPSHOT.war web_container:/usr/local/tomcat/webapps/ROOT.war
          # Maven 빌드로 생성된 새로운 WAR 파일을 웹 컨테이너에 복사
        # 이 단계에서는 기존 Tomcat 서버의 ROOT.war 파일을 백업하고, 새로운 WAR 파일을 덮어씌웁니다.

      - name: Restart web server container  # 웹 서버 컨테이너 재시작
        run: |
          docker restart web_container
        # Tomcat 웹 서버가 실행 중인 Docker 컨테이너를 재시작하여 새로운 WAR 파일이 반영되도록 합니다.

Checkout code: 레포지토리의 코드를 셀프 호스티드 러너로 가져오는 단계입니다. 이 작업이 완료되면 로컬에서 코드를 사용할 수 있습니다.
Set up JDK 11: 이 단계는 Java 11 버전을 빌드 환경에 설치하고 설정합니다. 이후 Maven을 통해 프로젝트를 빌드할 때 Java 11을 사용할 수 있게 됩니다.
Build with Maven: Maven을 사용하여 Java 프로젝트를 빌드하고, 패키징된 결과물인 .war 파일을 생성합니다.
Backup existing ROOT.war and copy new WAR file: 이 단계에서는 Tomcat 컨테이너 내의 기존 ROOT.war 파일을 백업하고, 새로 빌드된 .war 파일을 Tomcat 컨테이너로 복사합니다.
Restart web server container: Tomcat 웹 서버가 실행되는 Docker 컨테이너를 재시작하여 새 .war 파일이 반영되도록 합니다.

이런 구조로 CI/CD 파이프라인을 구성하면 코드가 푸시되거나 PR이 생성될 때 자동으로 빌드 및 배포가 이루어집니다.

위와 같이 작성 후 main 브랜치에 커밋하게 되면 아래와 같이 Action 탭에서 요청한 워크플로우가 돌아감을 확인할 수 있다.

6. 짜잔 완성

CI/CD 워크플로우가 잘 돌아가서 배포가 성공적으로 되었다 !

+) 디벨롭 버전

슬랙 알람을 추가 했고 active profile 이 올바르게 지정되었는지 확인하는 작업을 추가하였다.

그리고 빌드와 배포 과정을 나누었고 빌드가 제대로 됐을때만 배포가 이뤄지게 하였다.

name: CI/CD Pipeline

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  build:
    runs-on: self-hosted
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Notify Slack - Build Started
        run: |
          curl -X POST -H 'Content-type: application/json' --data "{\"text\":\"[CI/CD] Build has started by ${GITHUB_ACTOR}.\"}" ${{ secrets.WEBHOOK_SLACK_URL }}

      - name: Check active profile
        run: |
          if ! grep -q 'spring.profiles.active=main' src/main/resources/application.properties; then
            echo "Error: spring.profiles.active is not set to 'main'."
            exit 1  # 프로파일이 맞지 않으면 빌드 실패
          fi
      - name: Set up JDK 11
        uses: actions/setup-java@v1
        with:
          java-version: '11'
      - name: Notify Slack - Build Status
        run: |
          curl -X POST -H 'Content-type: application/json' --data "{\"text\":\"[CI/CD] Build Status: Success by ${GITHUB_ACTOR}.\"}" ${{ secrets.WEBHOOK_SLACK_URL }}

  deploy:
    runs-on: self-hosted
    needs: build  # 'build' 작업이 성공해야 이 작업이 실행됨
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'  # main 브랜치에 푸시될 때 실행됨
    steps:
      - name: Backup existing ROOT.war and copy new WAR file
        run: |
          TIMESTAMP=$(date +%Y%m%d%H%M%S)  # 현재 시간 포맷: YYYYMMDDHHMMSS

          # 기존 ROOT.war 파일을 ROOT.war.<현재시간> 으로 백업
          docker exec web_container mv /usr/local/tomcat/webapps/ROOT.war /usr/local/tomcat/webapps/ROOT.war.$TIMESTAMP

          # 새로운 WAR 파일을 컨테이너에 복사
          docker cp target/test-0.0.1-SNAPSHOT.war web_container:/usr/local/tomcat/webapps/ROOT.war
      - name: Restart web server container
        run: |
          docker restart web_container

다음에는 도커 레포지토리를 통한 빌드와, 젠킨스를 활용한 CI/CD 구축에 도전해봐야겠다.

[Database-MySQL] Select 쿼리로 테이블 정의서 만들기 (sql to 정의서)

제가안난데여♪(´ε｀*) — Fri, 20 Sep 2024 19:02:28 +0900

SELECT 
	a.TABLE_NAME '테이블명',
	b.ORDINAL_POSITION '순번', 
	b.COLUMN_NAME '필드명', 
	b.COLUMN_KEY 'KEY', 
	b.COLUMN_TYPE '데이터길이', 
	b.IS_NULLABLE 'NULL값여부', 
	b.COLUMN_DEFAULT '기본값', 
	b.COLUMN_COMMENT '필드설명' 
FROM information_schema.TABLES a 
	JOIN information_schema.COLUMNS b 
	ON a.TABLE_NAME = b.TABLE_NAME 
	AND a.TABLE_SCHEMA = b.TABLE_SCHEMA 
WHERE a.TABLE_SCHEMA = '스키마명(수정하세요)' 
-- AND a.TABLE_NAME = '테이블명(수정하세요)' // 특정 테이블만 조회할때
ORDER BY a.TABLE_NAME, b.ORDINAL_POSITION

위 쿼리를 입력하면 아래와 같이 테이블 정의서에 필요한 내용들을 조회할 수 있다.

csv로 빼내서 출력도 가능하고 그대로 드래그 해서 복사해서 엑셀에 붙여넣기도 가능하다.

덕분에 2시간, 3시간 걸릴거 한시간만에 뚝딱 해결해버렸다.

참고

https://m.blog.naver.com/lgr0406/222220564883

[SQL] Mysql 테이블 정의서 만들기

결과물 이걸 csv 로 내려받으면 엑셀로 작업할 수도 있다. 참고 https://didalsgur.tistory.com/35

blog.naver.com

99클럽 코테 스터디 15일차 TIL /[프로그래머스] 소수찾기

제가안난데여♪(´ε｀*) — Mon, 5 Aug 2024 18:23:12 +0900

문제

[level 2] 소수 찾기 - 42839

문제 링크

성능 요약

메모리: 84.5 MB, 시간: 23.86 ms

접근법

문제 요약

1개 이상 7개 이하의 자연수들을 개수 상관없이 한번씩만 뽑아서 만들 수 있는 숫자가 소수인지 판별하는 문제

범위 체크 및 시간복잡도 예상

1 ≤ numbers의 길이 ≤ 7
numbers를 이루고 있는 숫자 들은 0 ~ 9 자연수 이다.
$O(N^2)$ 보다는 작아야한다.

풀이법

⭕ 접근 방법. 완탐

숫자 문자열로부터 가능한 모든 순열 생성:
- 각 자리 숫자를 사용하여 순열을 만들고, 각 순열조합이 소수인지 확인
- 자리수의 중복을 방지하기 위해 방문 여부를 체크하는 배열을 사용
소수 판별:
- 각 생성된 숫자가 소수인지 확인. 소수 판별은 2부터 해당 숫자의 제곱근까지의 수로 나누어지는지 확인하는 방식으로 수행하여 시간복잡도를 줄인다.
- 소수라면 이를 HashSet 저장하여 중복된 소수의 처리를 방지한다.

➡️ 해당 풀이법의 시간 복잡도 : $O(N! \sqrt{N})$

SUCCESS

고냥 단박에 성공

‍ 코드

import java.util.*;

class Solution {

    // 소수를 저장하는 HashSet, 중복 소수를 자동으로 제거함
    static HashSet<Integer> prime = new HashSet<>(); 
    // 각 종이 조각의 방문 여부를 체크하는 배열
    static boolean visited[]; 
    // 입력된 종이 조각 숫자 문자열
    static String nums; 

    // 주어진 종이 조각 숫자 문자열에서 만들 수 있는 소수의 개수를 반환하는 메서드
    public int solution(String numbers) {
        nums = numbers; // 전역 변수 nums에 입력된 숫자 문자열 할당
        visited = new boolean[numbers.length()]; // 숫자 문자열 길이만큼 방문 여부 배열 초기화

        // 숫자를 조합하여 소수를 찾는 메서드 호출
        makeNumber(0 , ""); 

        // HashSet에 저장된 소수의 개수를 정답으로 반환
        int answer = prime.size(); 
        return answer; // 소수의 개수 반환
    }

    // 주어진 깊이에서 숫자를 조합하여 소수를 찾는 메서드
    private void makeNumber(int depth, String number) {
        // 현재 조합된 숫자가 소수인지 확인
        if(!number.isEmpty()) {
            isPrime(number);
        }

        // 재귀 호출 종료 조건: 현재 깊이가 숫자 문자열 길이 이상일 때
        if(depth >= nums.length()){ 
            return; // 메서드 종료
        }

        // 숫자 문자열의 각 자리수를 순회하며 숫자 조합 생성
        for (int i = 0; i < nums.length(); i++) {
            if(visited[i]) continue; // 이미 방문한 자리수는 건너뜀
            visited[i] = true; // 현재 자리수 방문 처리
            number = number + nums.charAt(i); // 현재 자리수의 숫자를 조합에 추가
            makeNumber(depth+1, number); // 다음 깊이로 재귀 호출
            number = number.substring(0, number.length()-1); // 마지막에 추가한 자리수의 숫자를 제거
            visited[i] = false; // 방문 처리 해제
        }
    }

    // 주어진 문자열이 소수인지 확인하고, 소수라면 HashSet에 추가하는 메서드
    private void isPrime(String number) {
        int n = Integer.parseInt(number); // 문자열을 정수로 변환
        if(n == 0 || n == 1){ // 0이나 1은 소수가 아님
            return; // 메서드 종료
        }

        // 2부터 n의 제곱근까지의 수로 나누어지는지 확인
        for (int i = 2; i <= Math.sqrt(n); i++) {
            if(n % i == 0) { // 나누어 떨어지면 소수가 아님
                return; // 메서드 종료
            }
        }

        // 소수라면 HashSet에 추가
        prime.add(n); 
    }
}

99클럽 코테 스터디 13일차 TIL / [프로그래머스] 입국심사

제가안난데여♪(´ε｀*) — Sat, 3 Aug 2024 22:16:52 +0900

# [level 3] 입국심사 - 43238

[문제 링크](https://school.programmers.co.kr/learn/courses/30/lessons/43238)

### 성능 요약

메모리: 99.7 MB, 시간: 107.77 ms

import java.util.*;

class Solution {
    public long solution(int n, int[] times) {
        
        long answer = 0;
        Arrays.sort(times);
        // 이분탐색 기준은 모든 인원이 입국심사를 받는데 걸리는 시간
        // 1분 동안 모든 인원이 입국심사를 전부 받았나? -> X
        // 2분 동안 모든 인원이 입국심사를 전부 받았나? -> X
        // 3분 동안 모든 인원이 입국심사를 전부 받았나? -> O
        // 4분 동안 모든 인원이 입국심사를 전부 받았나? -> O
        // 5분 동안 모든 인원이 입국심사를 전부 받았나? -> O
        // 의 형태를 띄기때문에 이분탐색으로 풀이 가능
        long left = 1;
        long right = times[0] * (long)n; // 가장 오래 걸리는 경우 (심사하는데 걸리는 시간이 가장 긴 시간 * 입국신사 기다리는 사람의 수)
        long mid = (left + right)/2;
        while (left <= right){
            if(isAllPass(mid, n , times)){ // mid 시간내에 모든인원이 입국심사를 받았는지 확인
                // 받았다면 더 짧은 시간 범위를 확인
                right = mid -1 ;
                answer = mid;
            }else{
                // 못받았다면 시간을 늘려서 더 긴 시간 범위 확인
                left = mid +1;
            }
            mid = (left + right)/2;            
        }
        return answer;
    }
    public boolean isAllPass(long time, int n, int[] times){
        int pass = 0;
        for(int i = 0; i < times.length; i ++){
            pass += time/times[i];
            if(pass >= n){
                return true;
            }
        }
        return false;
    }
}

99클럽 코테 스터디 11일차 TIL /[프로그래머스]가장 큰 수

제가안난데여♪(´ε｀*) — Thu, 1 Aug 2024 23:22:48 +0900

문제

[level 2] 가장 큰 수 - 42746

문제 링크

성능 요약

메모리: 124 MB, 시간: 215.48 ms

접근법

문제 요약

0 또는 양의 정수가 주어졌을 때, 정수를 이어 붙여 만들 수 있는 가장 큰 수를 알아내는 문제

범위 체크 및 시간복잡도 예상

numbers의 길이는 1 이상 100,000 이하
numbers의 원소는 0 이상 1,000 이하

풀이법

⭕ 접근 방법. 우선순위 큐

PriorityQueue를 사용하자!

static PriorityQueue<Integer> *pq* = new PriorityQueue<>((o1, o2) -> {return o2-o1;});

위와 같이 PQ를 사용하여 우선순위 조건을 변경하면 큰 값이 우선이 되도록 qp를 생성할 수 있다.

pq 는 힙으로 구성되어 있기 때문에 시간복잡도는 O(logN)을 가진다.

➡️ 해당 풀이법의 시간 복잡도 : $O(NlogN)$

FAIL

답을 봐서 문제를 푼 경우

- 두 문자열을 더해서 길이를 같게 만든 후에 우선순위를 비교한다는 아이디어를 떠올리지 못하였다 ‍♀️

‍ 코드

import java.util.*;

class Solution {
        public String solution(int[] numbers) {
            String nums[] = new String[numbers.length];
            for (int i = 0; i < numbers.length; i++) {
                nums[i] = String.valueOf(numbers[i]);
            }

            Arrays.sort(nums,(o1, o2) -> {
                String s1 = o1 + o2;
                String s2 = o2 + o1;
                return s2.compareTo(s1);
            });

//            System.out.println(Arrays.toString(nums));

            StringBuilder answer = new StringBuilder();
            for (int i = 0; i < nums.length; i++) {
                if(i == 0 && nums[0].equals("0")) return "0";
                answer.append(nums[i]);
            }
            return answer.toString();
        }
}

99클럽 코딩테스트 준비 개발자 취업 항해99 TIL

안나의 전두엽 어딘가

[React] React 19에서의 폼 처리 방식: Form Action, useActionState, useFormStatus, useOptimistic

Form Action이란?

useActionState 훅

React는 다음과 같은 일을 자동으로 해줘야 해요:

⚙️ 그래서 React는 우리가 전달한 함수를 직접 쓰지 않고, 내부적으로 새로운 함수를 만듭니다.

✅ 예시: 유효성 검사 및 에러 처리

useFormStatus: 제출 중 상태 추적

✅ 반환되는 객체 속성

useOptimistic: 낙관적 UI 업데이트

✅ 사용법

✅ 실제 예시: 투표 수를 즉시 반영하는 컴포넌트

버튼마다 다른 액션 처리하기

Form Action vs onSubmit

[React] React에서 폼(form) 다루기 :: 추출, 유효성검증, 초기화, 제출

1. 입력 데이터 추출 방법

✅ 방법 1: useState로 입력 상태 관리 (양방향 바인딩)

✅ 방법 2: useRef로 DOM 요소 접근

✅ 방법 3: FormData API로 한 번에 추출

2. 유효성 검증 (Validation)

✅ 방법 1: 실시간 검증 (onChange)

✅ 방법 2: 포커스 해제 시 검증 (onBlur)

✅ 방법 3: useRef와 입력 완료 시 검증

✅ 방법 4: HTML의 내장 속성 사용

3. 폼 초기화 처리

✅ 방법 1: useState로 초기값 설정

✅ 방법 2: useRef 초기화

✅ 방법 3: event.target.reset() 사용

4. 양식 제출 제어 (submit 제어)

✅ HTML의 기본 동작

✅ 리액트에선 왜 문제가 될까?

✅ 해결 방법

1️⃣ type="button" 사용

2️⃣ onSubmit + preventDefault()

3️⃣ formAction (React 19 이상)

[React] 왜 React에서는 form submit을 기본으로 두면 안 될까?

브라우저 기본 동작

왜 이렇게 설계됐을까? (→ SSR 기반 구조)

⚠️ 그런데, 리액트에서는 문제가 된다 (→ CSR과 충돌)

️ React에서 폼 제출 시 주의할 점

1️⃣ 버튼에 type="button"을 명시하기

2️⃣ onSubmit 핸들러에서 preventDefault() 호출하기

3️⃣ (React 19 이상) formAction 속성 사용하기

참고: CSR vs SSR 한눈에 정리

[React] 리액트 컴포넌트 스타일링

바닐라 CSS 스타일 컴포넌트에 스코핑 방법

1️⃣ style Prop 사용하여 Inline(인라인)으로 css 적용하기

style Prop 기본 사용법

style Prop 사용 시 장점

style Prop 사용 시 단점

2️⃣ CSS Module 사용하기

Button.module.css

Button.js

3️⃣ Styled Components

styled-component 설치

사용 방법 예시

props로 동적 스타일 처리하기

중첩 스타일, @media, hover 등의 사용법

장점

주의할 점

4️⃣ Tailwind

설치 방법

사용법

자주 쓰는 클래스 예시

장점 및 단점

팁: 클래스 너무 길어져 가독성이 떨어져요

[React] Tailwind 사용하여 스타일링 하기

설치 방법

사용법

자주 쓰는 클래스 예시

장점 및 단점

팁: 클래스 너무 길어져 가독성이 떨어져요

[React] Styled Components 사용하기

styled-component 설치

사용 방법 예시

props로 동적 스타일 처리하기

중첩 스타일, @media, hover 등의 사용법

장점

주의할 점

[React] CSS Module 사용하기