검색 설명: React 19를 기준으로 개발 환경 구성, Hooks, Actions, 상태 관리, TanStack Query, React Hook Form, 컴포넌트 설계, 성능 최적화, 테스트와 접근성을 정리합니다. -->
React는 컴포넌트를 조합해 사용자 인터페이스를 만드는 대표적인 프론트엔드 라이브러리입니다. 이 글에서는 React 19를 기준으로 개발 환경 구성부터 Hooks, Actions, 상태 관리, 서버 데이터 처리, 폼 검증, 컴포넌트 설계, 성능 최적화, 테스트와 접근성까지 실무에서 필요한 핵심 내용을 정리합니다.
```React 문법만 나열하는 것이 아니라 상태를 어디에 두어야 하는지, 서버 데이터와 클라이언트 상태를 어떻게 구분하는지, 컴포넌트를 어떤 기준으로 분리해야 하는지까지 실무 관점에서 살펴봅니다.
1. React 개발 환경 설정
React 프로젝트를 시작할 때는 먼저 애플리케이션의 렌더링 방식과 배포 구조를 결정해야 합니다.
| 선택 | 적합한 프로젝트 | 주요 특징 |
|---|---|---|
| Next.js | SEO, 서버 렌더링, 라우팅이 필요한 서비스 | SSR, SSG, ISR, Server Components 지원 |
| Vite | 관리자 화면, 대시보드, 내부 SPA | 빠른 개발 서버와 간결한 프로젝트 구성 |
서버 렌더링, 라우팅, 검색엔진 최적화까지 필요하다면 Next.js가 적합하고, 가볍고 빠른 순수 SPA를 만들고 싶다면 Vite로 시작할 수 있습니다.
# Next.js 프로젝트
npx create-next-app@latest my-app --typescript --tailwind --app
# Vite 기반 React SPA
npm create vite@latest my-app -- --template react-ts
cd my-app
npm install
npm run dev
# React 19 코어 패키지 설치
npm install react@19 react-dom@19단순히 익숙한 도구를 선택하기보다 SEO, 인증, 라우팅, 배포 환경, 서버 데이터 처리 방식 등을 먼저 정한 후 프로젝트 생성 도구를 선택하는 것이 좋습니다.
2. Hooks 기본기
React 함수형 컴포넌트에서는 Hooks를 이용해 상태, 생명주기, 참조값과 메모이제이션을 처리합니다.
| Hook | 용도 |
|---|---|
useState |
컴포넌트 로컬 상태 관리 |
useEffect |
외부 시스템과의 동기화 및 부수 효과 처리 |
useCallback |
함수 참조값 메모이제이션 |
useMemo |
계산 결과 메모이제이션 |
useRef |
DOM 또는 렌더링과 무관한 변경 가능 값 참조 |
useReducer |
복잡하거나 연관된 상태 변경 관리 |
커스텀 데이터 조회 Hook
import { useState, useEffect } from 'react';
function useFetch<T>(url: string) {
const [data, setData] = useState<T | null>(null);
const [loading, setLoading] = useState(true);
useEffect(() => {
let cancelled = false;
fetch(url)
.then((response) => response.json())
.then((result) => {
if (!cancelled) {
setData(result);
}
})
.finally(() => {
if (!cancelled) {
setLoading(false);
}
});
return () => {
cancelled = true;
};
}, [url]);
return { data, loading };
}Hook 사용 규칙
- Hook은 컴포넌트의 최상위에서만 호출합니다.
- 조건문, 반복문, 중첩 함수 안에서 Hook을 호출하지 않습니다.
- Hook은 React 함수형 컴포넌트 또는 커스텀 Hook 안에서 호출합니다.
useEffect의존성은 ESLint의exhaustive-deps규칙으로 관리합니다.- cleanup 함수는 언마운트뿐 아니라 의존성이 변경될 때도 실행됩니다.
- 여러 상태가 항상 함께 변경된다면
useReducer사용을 검토합니다.
useEffect는 모든 데이터 계산을 처리하는 도구가 아닙니다. props나 state만으로 계산할 수 있는 값은 렌더링 과정에서 직접 계산하고, 브라우저 API나 외부 서버 같은 시스템과 동기화할 때 Effect를 사용하는 것이 좋습니다.
3. React 19 주요 기능
React 19에서는 폼 제출과 비동기 작업을 Actions 중심으로 처리할 수 있게 되었습니다. 대표적인 API는 useActionState, useOptimistic, use()입니다.
| API | 용도 |
|---|---|
useActionState |
Action 실행 결과와 pending 상태 관리 |
useOptimistic |
서버 응답 전 낙관적으로 UI 갱신 |
use() |
Promise 또는 Context 값을 읽고 Suspense와 연동 |
| React Compiler | 컴포넌트와 값을 빌드 단계에서 자동 최적화 |
useActionState로 폼 상태 관리
import { useActionState } from 'react';
type FormState = {
error?: string;
};
function ProfileForm({
updateName,
}: {
updateName: (
prevState: FormState,
formData: FormData
) => Promise<FormState>;
}) {
const [state, formAction, isPending] = useActionState(
updateName,
{}
);
return (
<form action={formAction}>
<label htmlFor="name">이름</label>
<input id="name" name="name" />
<button type="submit" disabled={isPending}>
{isPending ? '저장 중...' : '저장'}
</button>
{state.error && (
<p role="alert">{state.error}</p>
)}
</form>
);
}useOptimistic으로 낙관적 업데이트
import { startTransition, useOptimistic } from 'react';
function LikeButton({
likes,
addLike,
}: {
likes: number;
addLike: () => Promise<void>;
}) {
const [optimisticLikes, addOptimisticLike] =
useOptimistic(likes, (currentLikes) => currentLikes + 1);
const handleClick = () => {
startTransition(async () => {
addOptimisticLike();
await addLike();
});
};
return (
<button type="button" onClick={handleClick}>
좋아요 {optimisticLikes}
</button>
);
}use()로 Promise 읽기
import { use } from 'react';
type Comment = {
id: string;
text: string;
};
function Comments({
commentsPromise,
}: {
commentsPromise: Promise<Comment[]>;
}) {
const comments = use(commentsPromise);
return (
<ul>
{comments.map((comment) => (
<li key={comment.id}>{comment.text}</li>
))}
</ul>
);
}4. 상태 관리 전략
React 상태 관리에서 가장 중요한 것은 라이브러리 선택보다 상태의 소유자와 수명 주기를 정하는 것입니다. 모든 상태를 전역 저장소에 넣으면 데이터 흐름을 추적하기 어려워지고 불필요한 리렌더링이 증가할 수 있습니다.
| 상태 범위 | 추천 도구 | 적합한 경우 |
|---|---|---|
| 컴포넌트 로컬 | useState, useReducer |
해당 컴포넌트와 자식만 사용하는 상태 |
| 일부 트리 공유 | Context + useReducer | 테마, 인증 사용자처럼 자주 변경되지 않는 값 |
| 전역 클라이언트 상태 | Zustand | 메뉴 상태, 모달, 폼 위저드 단계 등 |
| 복잡한 도메인 상태 | Redux Toolkit | 액션 추적과 명시적인 상태 변경이 필요한 대규모 팀 |
| 서버 데이터 | TanStack Query, SWR | 캐싱, 재검증, 중복 요청 제거가 필요한 API 데이터 |
Zustand 전역 상태 예제
import { create } from 'zustand';
interface CounterStore {
count: number;
increase: () => void;
decrease: () => void;
}
export const useCounterStore = create<CounterStore>((set) => ({
count: 0,
increase: () =>
set((state) => ({
count: state.count + 1,
})),
decrease: () =>
set((state) => ({
count: state.count - 1,
})),
}));서버에서 받아온 API 데이터를 Zustand나 Redux에 다시 복사해 저장하지 않는 것이 좋습니다. 서버 데이터는 캐시 만료, 재조회, 중복 요청 제거 같은 별도의 문제가 있으므로 TanStack Query와 같은 서버 상태 관리 도구로 처리하는 편이 안전합니다.
5. 서버 상태와 데이터 페칭
서버 상태는 컴포넌트 내부에서 직접 생성하는 일반적인 클라이언트 상태와 성격이 다릅니다. 네트워크 요청, 로딩, 오류, 캐싱, 데이터 만료, 백그라운드 재검증과 같은 요소를 함께 다뤄야 합니다.
TanStack Query를 사용하면 API 데이터의 수명 주기와 캐시를 선언적으로 관리할 수 있습니다.
import {
useMutation,
useQuery,
useQueryClient,
} from '@tanstack/react-query';
type Todo = {
id: string;
title: string;
};
async function fetchTodos(): Promise<Todo[]> {
const response = await fetch('/api/todos');
if (!response.ok) {
throw new Error('할 일 목록을 불러오지 못했습니다.');
}
return response.json();
}
function TodoList() {
const queryClient = useQueryClient();
const {
data = [],
isPending,
error,
} = useQuery({
queryKey: ['todos'],
queryFn: fetchTodos,
staleTime: 30_000,
});
const addTodo = useMutation({
mutationFn: async (title: string) => {
const response = await fetch('/api/todos', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
},
body: JSON.stringify({ title }),
});
if (!response.ok) {
throw new Error('할 일을 등록하지 못했습니다.');
}
return response.json();
},
onSuccess: () => {
queryClient.invalidateQueries({
queryKey: ['todos'],
});
},
});
if (isPending) {
return <p>로딩 중...</p>;
}
if (error) {
return <p role="alert">불러오기 실패</p>;
}
return (
<ul>
{data.map((todo) => (
<li key={todo.id}>{todo.title}</li>
))}
</ul>
);
}실무 체크포인트
queryKey에는 해당 데이터를 구분할 수 있는 조건을 모두 포함합니다.staleTime은 데이터 변경 빈도에 맞게 설정합니다.- HTTP 상태 코드를 확인하고 실패 응답에서는 명시적으로 예외를 발생시킵니다.
- 목록 전체를 다시 조회할 필요가 없다면
setQueryData로 캐시를 직접 변경할 수 있습니다. - 낙관적 업데이트를 적용할 때는 실패 시 이전 캐시로 되돌리는 rollback 전략을 함께 설계합니다.
6. 폼 처리와 검증
입력 필드가 많아질수록 직접 state를 연결하는 방식은 코드가 복잡해지고 리렌더링 범위도 커질 수 있습니다. React Hook Form과 Zod를 조합하면 폼 상태와 타입 안전한 검증 규칙을 함께 관리할 수 있습니다.
import { useForm } from 'react-hook-form';
import { zodResolver } from '@hookform/resolvers/zod';
import { z } from 'zod';
const loginSchema = z.object({
email: z
.string()
.email('올바른 이메일 주소를 입력하세요.'),
password: z
.string()
.min(8, '비밀번호는 8자 이상 입력하세요.'),
});
type LoginFormValues = z.infer<typeof loginSchema>;
function LoginForm() {
const {
register,
handleSubmit,
formState: {
errors,
isSubmitting,
},
} = useForm<LoginFormValues>({
resolver: zodResolver(loginSchema),
});
const onSubmit = async (values: LoginFormValues) => {
const response = await fetch('/api/login', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
},
body: JSON.stringify(values),
});
if (!response.ok) {
throw new Error('로그인에 실패했습니다.');
}
};
return (
<form onSubmit={handleSubmit(onSubmit)} noValidate>
<div>
<label htmlFor="email">이메일</label>
<input
id="email"
type="email"
aria-invalid={Boolean(errors.email)}
{...register('email')}
/>
{errors.email && (
<p role="alert">
{errors.email.message}
</p>
)}
</div>
<div>
<label htmlFor="password">비밀번호</label>
<input
id="password"
type="password"
aria-invalid={Boolean(errors.password)}
{...register('password')}
/>
{errors.password && (
<p role="alert">
{errors.password.message}
</p>
)}
</div>
<button type="submit" disabled={isSubmitting}>
{isSubmitting ? '로그인 중...' : '로그인'}
</button>
</form>
);
}클라이언트 검증은 사용자 경험을 개선하기 위한 기능입니다. 보안과 데이터 무결성을 위해 서버에서도 동일한 검증 규칙을 반드시 적용해야 합니다.
7. 컴포넌트 설계 패턴
컴포넌트가 지나치게 커지면 UI, 상태 변경, API 호출과 비즈니스 규칙이 한곳에 섞이게 됩니다. 화면 구조와 동작을 분리하고 변경 가능성이 다른 코드를 서로 다른 경계로 나누는 것이 중요합니다.
Error Boundary
Error Boundary는 하위 컴포넌트 트리에서 발생한 렌더링 오류가 애플리케이션 전체로 확산되는 것을 막습니다.
import {
Component,
type ErrorInfo,
type ReactNode,
} from 'react';
type ErrorBoundaryProps = {
fallback: ReactNode;
children: ReactNode;
};
type ErrorBoundaryState = {
hasError: boolean;
};
class ErrorBoundary extends Component<
ErrorBoundaryProps,
ErrorBoundaryState
> {
state: ErrorBoundaryState = {
hasError: false,
};
static getDerivedStateFromError(): ErrorBoundaryState {
return {
hasError: true,
};
}
componentDidCatch(
error: unknown,
errorInfo: ErrorInfo
) {
console.error(error, errorInfo);
}
render() {
if (this.state.hasError) {
return this.props.fallback;
}
return this.props.children;
}
}Compound Component
함께 사용되는 여러 컴포넌트가 하나의 상태를 공유해야 한다면 Compound Component 패턴을 활용할 수 있습니다.
import {
createContext,
useContext,
useState,
type ReactNode,
} from 'react';
type TabsContextValue = {
activeTab: string;
setActiveTab: (id: string) => void;
};
const TabsContext =
createContext<TabsContextValue | null>(null);
function useTabsContext() {
const context = useContext(TabsContext);
if (!context) {
throw new Error(
'Tabs.Tab은 Tabs 내부에서 사용해야 합니다.'
);
}
return context;
}
function Tabs({
defaultTab,
children,
}: {
defaultTab: string;
children: ReactNode;
}) {
const [activeTab, setActiveTab] =
useState(defaultTab);
return (
<TabsContext.Provider
value={{ activeTab, setActiveTab }}
>
{children}
</TabsContext.Provider>
);
}
Tabs.Tab = function Tab({
id,
children,
}: {
id: string;
children: ReactNode;
}) {
const {
activeTab,
setActiveTab,
} = useTabsContext();
return (
<button
type="button"
role="tab"
aria-selected={activeTab === id}
onClick={() => setActiveTab(id)}
>
{children}
</button>
);
};컴포넌트 분리 기준
- 하나의 컴포넌트가 여러 종류의 책임을 동시에 수행하는지 확인합니다.
- 비즈니스 로직은 커스텀 Hook 또는 별도 모듈로 분리합니다.
- 페이지 전체가 아닌 기능 단위로 Error Boundary를 배치합니다.
- 범용화를 위해 지나치게 많은 props를 추가하지 않습니다.
- 재사용 횟수보다 변경 이유가 다른지를 기준으로 분리합니다.
8. 성능 최적화
React 애플리케이션의 성능 문제는 무조건적인 메모이제이션보다 잘못된 상태 위치, 불필요하게 큰 컴포넌트 범위, 연속적인 네트워크 요청에서 발생하는 경우가 많습니다.
import {
memo,
useCallback,
useMemo,
} from 'react';
type Item = {
id: string;
name: string;
};
const ListItem = memo(function ListItem({
item,
onClick,
}: {
item: Item;
onClick: (id: string) => void;
}) {
return (
<button
type="button"
onClick={() => onClick(item.id)}
>
{item.name}
</button>
);
});
function List({
items,
}: {
items: Item[];
}) {
const sortedItems = useMemo(
() =>
[...items].sort((a, b) =>
a.name.localeCompare(b.name)
),
[items]
);
const handleClick = useCallback(
(id: string) => {
console.log(id);
},
[]
);
return (
<div>
{sortedItems.map((item) => (
<ListItem
key={item.id}
item={item}
onClick={handleClick}
/>
))}
</div>
);
}성능 최적화 우선순위
- React DevTools Profiler로 실제 병목을 측정합니다.
- 상태가 필요한 범위보다 높은 위치에 있지 않은지 확인합니다.
- 한 번의 사용자 동작에서 API 요청이 순차적으로 실행되는 waterfall을 확인합니다.
- 리스트에는 배열 index가 아닌 안정적인 ID를 key로 사용합니다.
- 비싼 계산 또는 참조 안정성이 필요한 부분에만 메모이제이션을 적용합니다.
- 대용량 목록은 페이지네이션이나 가상 스크롤을 적용합니다.
React Compiler를 적용하면 컴포넌트와 값의 메모이제이션을 자동화할 수 있습니다. 다만 Hook 규칙이나 데이터 흐름이 잘못 설계된 문제까지 자동으로 해결하는 것은 아니므로 상태 소유권과 컴포넌트 경계를 먼저 올바르게 설계해야 합니다.
9. 테스트
React 컴포넌트 테스트는 내부 state나 함수 호출 횟수보다 사용자가 실제로 보는 화면과 수행하는 동작을 기준으로 작성하는 것이 좋습니다.
Vite 기반 프로젝트에서는 Vitest와 React Testing Library를 함께 사용할 수 있습니다.
import {
fireEvent,
render,
screen,
} from '@testing-library/react';
import {
describe,
expect,
it,
} from 'vitest';
import { Counter } from './Counter';
describe('Counter', () => {
it('버튼을 클릭하면 값이 증가한다', () => {
render(<Counter />);
const button = screen.getByRole('button', {
name: /count/i,
});
fireEvent.click(button);
expect(
screen.getByText('1')
).toBeInTheDocument();
});
});좋은 테스트의 기준
getByTestId보다getByRole,getByLabelText를 우선 사용합니다.- 구현 세부사항이 아닌 사용자가 확인할 수 있는 결과를 검증합니다.
- API 모킹은 MSW를 이용해 네트워크 계층에서 처리할 수 있습니다.
- 정상 흐름뿐 아니라 로딩, 오류, 빈 데이터 상태를 함께 테스트합니다.
- 버그 수정 시 동일한 상황을 재현하는 회귀 테스트를 추가합니다.
10. 접근성
접근성은 개발이 완료된 후 별도로 추가하는 기능이 아닙니다. 처음부터 시맨틱 HTML을 사용하고 키보드 이동과 스크린 리더를 고려하면 많은 문제를 예방할 수 있습니다.
| 항목 | 적용 기준 |
|---|---|
| 시맨틱 태그 | div 대신 button, nav, main, header 등을 사용합니다. |
| 이미지 대체 텍스트 | 정보를 전달하는 이미지에는 의미 있는 alt를 작성합니다. |
| 키보드 이동 | Tab과 Shift+Tab만으로 핵심 기능을 사용할 수 있어야 합니다. |
| 모달 | aria-modal, focus trap, 닫힌 후 포커스 복귀를 처리합니다. |
| 색상 대비 | 일반 텍스트는 WCAG AA 기준에 맞는 대비를 유지합니다. |
| 오류 메시지 | role="alert"와 입력 필드 연결을 고려합니다. |
자동 검사 도구만으로 모든 접근성 문제를 찾을 수는 없습니다. 브라우저의 키보드 탐색, 스크린 리더, 실제 포커스 이동을 함께 확인해야 합니다.
11. React 실무 설계
React에서는 컴포넌트 트리의 모양보다 데이터 흐름을 어떻게 설계하는지가 더 중요합니다. 서버 상태, 클라이언트 상태, 폼 상태를 구분하고 각 컴포넌트가 담당하는 책임을 작게 유지해야 합니다.
| 결정 지점 | 확인 질문 | 실무 기준 |
|---|---|---|
| 컴포넌트 경계 | 서로 다른 이유로 변경되는 코드가 섞여 있는가? | UI, 외부 연동, 설정, 핵심 규칙을 분리합니다. |
| 상태 | 상태가 어디에서 생성되고 언제 사라지는가? | 상태 소유자와 수명 주기를 명확하게 드러냅니다. |
| 서버 데이터 | 데이터가 언제 오래된 것으로 판단되는가? | 캐시 키와 재검증 정책을 명시합니다. |
| 오류 | 실패했을 때 사용자는 어떤 화면을 보는가? | Error Boundary, 오류 메시지, 재시도 정책을 설계합니다. |
| 성능 | 불필요한 렌더링과 API waterfall이 있는가? | Profiler와 네트워크 분석으로 측정한 후 개선합니다. |
상태를 구분하는 방법
- 서버 상태: API에서 조회하며 캐싱과 재검증이 필요한 데이터
- 클라이언트 상태: 모달, 메뉴, 선택값처럼 브라우저에서 생성되는 UI 상태
- 폼 상태: 입력값, 검증 오류, 제출 상태
- URL 상태: 검색어, 페이지 번호, 필터처럼 공유와 복원이 필요한 상태
- 파생 상태: 기존 props나 state로 계산할 수 있는 값
다른 상태에서 계산할 수 있는 값을 다시 useState에 저장하면 두 값이 서로 달라지는 문제가 발생할 수 있습니다. 가능한 경우 렌더링 중 계산하거나 비용이 큰 계산에만 useMemo를 적용합니다.
12. React 운영 기준
운영 환경에서는 화면이 정상적으로 렌더링되는 것만으로 충분하지 않습니다. 로딩, 실패, 데이터 없음, 권한 부족, 네트워크 지연 같은 다양한 상태를 사용자가 이해할 수 있도록 설계해야 합니다.
필수 운영 항목
- State ownership: 상태를 실제로 사용하는 가장 가까운 위치에서 관리합니다.
- Server state cache: API별 캐시 키, 만료 시간과 재조회 정책을 정합니다.
- Error Boundary: 기능 단위 오류 격리와 fallback UI를 제공합니다.
- Loading UI: 긴 요청에서 사용자가 현재 상태를 알 수 있도록 표시합니다.
- 관측성: 프론트엔드 오류와 API 실패를 추적할 수 있는 로깅 체계를 구성합니다.
- 접근성 테스트: 핵심 사용자 플로우를 키보드와 보조 기술로 검증합니다.
- API timeout과 재시도 횟수
- 인증 토큰 만료 시 사용자 처리 방식
- 배포 후 JavaScript chunk 캐시 불일치
- 소스맵 공개 범위와 오류 추적 시스템 연계
- 환경 변수와 API 주소의 빌드·런타임 구분
13. React 검증 전략
React 애플리케이션은 함수 단위 테스트만으로 전체 품질을 보장하기 어렵습니다. 사용자가 실제로 수행하는 시나리오를 중심으로 단위 테스트, 통합 테스트와 E2E 테스트를 구성해야 합니다.
| 품질 축 | 검증 방법 | 완료 기준 |
|---|---|---|
| 정확성 | 정상, 실패, 빈 데이터 케이스를 자동화합니다. | 핵심 사용자 시나리오가 반복 실행되어 통과합니다. |
| 회귀 방지 | 버그 수정 시 재현 테스트를 추가합니다. | 동일 장애가 다시 배포되지 않습니다. |
| 접근성 | Role, Label, 키보드 이동과 포커스를 확인합니다. | 핵심 기능을 키보드만으로 사용할 수 있습니다. |
| 성능 | Profiler, 번들 크기와 Web Vitals를 확인합니다. | 목표 성능 지표를 배포 전후로 비교할 수 있습니다. |
| 운영성 | 로그, 오류 추적, API 실패율을 확인합니다. | 문제가 발생했을 때 원인을 추적할 수 있습니다. |
권장 테스트 구성
- 단위 테스트: 순수 함수, 커스텀 Hook, 검증 규칙
- 컴포넌트 테스트: 렌더링, 사용자 입력, 오류 메시지
- 통합 테스트: API 모킹을 포함한 기능 단위 플로우
- E2E 테스트: 로그인, 결제, 등록처럼 중요한 사용자 여정
- 접근성 테스트: axe와 수동 키보드 검증
14. 다음 학습 단계
React 컴포넌트와 상태 관리의 기본기를 익혔다면 프로젝트 목적에 따라 다음 기술로 학습 범위를 확장할 수 있습니다.
React 개발에서 중요한 것은 Hooks API를 많이 아는 것이 아니라 상태의 소유권, 서버 데이터의 수명 주기, 컴포넌트 경계와 오류 처리 방식을 명확하게 설계하는 것입니다.
작은 프로젝트에서는 로컬 상태를 우선 사용하고, 공유 범위가 넓어질 때 Context나 전역 상태 도구를 적용하며, 서버 데이터는 별도의 서버 상태 관리 도구로 분리하는 것이 안정적인 출발점입니다. 이후 테스트, 접근성, 오류 추적과 성능 측정을 개발 과정에 함께 포함하면 운영 가능한 React 애플리케이션으로 발전시킬 수 있습니다.
```'개발 가이드 > Frontend' 카테고리의 다른 글
| Next.js 완전 가이드 (1) | 2026.07.29 |
|---|
댓글