New-Item -Path $PROFILE -ItemType File -Force

2. 프로필 열기

notepad $PROFILE

3. 아래 함수 붙여넣기

function prompt {
    "$(Get-Date -Format 'HH:mm:ss') PS $($executionContext.SessionState.Path.CurrentLocation)> "
}

4. VSCode 터미널 재시작

📌 Introduction

많은 React 애플리케이션에서 흔히 발생하는 문제는 데이터 fetching, 상태 관리, 비즈니스 로직을 컴포넌트 안에 모두 넣어버리는 것이다.

다음과 같은 코드를 본 적 있을 것이다:

function UserProfile({ username }) {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState(null);

  useEffect(() => {
    setLoading(true);
    fetch(`/api/users/${username}`)
      .then(res => res.json())
      .then(data => {
        setUser(data);
        setLoading(false);
      })
      .catch(err => {
        setError(err.message);
        setLoading(false);
      });
  }, [username]);

  if (loading) return <div>Loading...</div>;
  if (error) return <div>Error: {error}</div>;
  if (!user) return null;

  return (
    <div>
      <h1>{user.name}</h1>
      <p>{user.bio}</p>
    </div>
  );
}

이 방식은 다음 문제를 만든다:

• 데이터 fetching
• 상태 관리
• 에러 처리
• 로딩 상태 처리
• UI 렌더링

→ 모든 책임이 컴포넌트에 몰림

🚨 Problem: 관심사 혼합 (Mixed Concerns)

이 구조의 문제:

• 테스트 어려움
• 재사용성 낮음
• 유지보수 어려움
• 캐싱 없음
• 상태 관리 복잡

→ ✅ Solution: Custom Hooks + React Query

해결 방법:

로직 → Custom Hook으로 분리 UI → 순수 컴포넌트로 유지

장점:

• 관심사 분리
• 자동 캐싱
• 테스트 용이
• 재사용성 증가

🏗 Architecture 구조

[ Presentation Layer ]

• UI만 담당
• props 기반

[ Logic Layer ]

• Custom Hooks
• 상태 관리
• 데이터 fetching
• 비즈니스 로직

1️⃣ 순수 UI 컴포넌트 만들기

// src/components/UserCard.tsx
import type { User, UserSearchItem } from "../types/User";

interface UserCardProps {
  user: User | UserSearchItem;
  onClick: () => void;
}

export const UserCard = ({ user, onClick }: UserCardProps) => {
  return (
    <div onClick={onClick}>
      <img src={user.avatar_url} />
      <h3>{"name" in user ? user.name : user.login}</h3>
      <p>@{user.login}</p>
    </div>
  );
};

핵심:

• 상태 없음
• side effect 없음
• props → JSX

2️⃣ Custom Hook으로 로직 분리

// src/hooks/useSearchUsers.ts
import { useQuery } from "@tanstack/react-query";
import { githubApi } from "../services/githubApi";

export const useSearchUsers = (query: string) => {
  const { data, isLoading, error, refetch } = useQuery({
    queryKey: ["users", query],
    queryFn: async () => {
      const response = await githubApi.get(
        `/search/users?q=${encodeURIComponent(query)}`
      );

      // 비즈니스 로직 (정렬)
      return response.data.items.sort((a, b) => b.score - a.score);
    },
    enabled: query.length > 2,
    staleTime: 5 * 60 * 1000,
  });

  return {
    users: data || [],
    isLoading,
    error,
    refetch,
  };
};

핵심:

• API 호출
• 캐싱
• 정렬 로직

→ 모두 Hook 내부

3️⃣ 페이지 로직 조합 (Composition)

// src/hooks/useHomePage.ts
import { useState } from "react";
import { useNavigate } from "react-router-dom";
import { useSearchUsers } from "./useSearchUsers";

export const useHomePage = () => {
  const [searchQuery, setSearchQuery] = useState("");
  const { users, isLoading, error } = useSearchUsers(searchQuery);
  const navigate = useNavigate();

  const handleSelectUser = (username: string) => {
    navigate(`/user/${username}`);
  };

  return {
    searchQuery,
    setSearchQuery,
    users,
    isLoading,
    error,
    handleSelectUser,
  };
};

4️⃣ 페이지 컴포넌트 (완전 단순화)

// src/pages/HomePage.tsx
import { useHomePage } from "../hooks/useHomePage";

export const HomePage = () => {
  const {
    searchQuery,
    setSearchQuery,
    users,
    isLoading,
    error,
    handleSelectUser,
  } = useHomePage();

  return (
    <div>
      <input onChange={(e) => setSearchQuery(e.target.value)} />

      {isLoading && <div>Loading...</div>}
      {error && <div>Error</div>}

      {users.map(user => (
        <div key={user.login} onClick={() => handleSelectUser(user.login)}>
          {user.login}
        </div>
      ))}
    </div>
  );
};

⚙️ Advanced: Repo 정렬 Hook

// src/hooks/useFetchRepos.ts
import { useState } from "react";
import { useQuery } from "@tanstack/react-query";

export const useFetchRepos = (username: string) => {
  const [sortCriteria, setSortCriteria] = useState("stars");

  const { data, isLoading, error } = useQuery({
    queryKey: ["repos", username],
    queryFn: async () => {
      const response = await fetch(`/users/${username}/repos`);
      return response.json();
    },
    enabled: !!username,
  });

  const sortedRepos = data
    ? [...data].sort((a, b) => {
        if (sortCriteria === "stars") {
          return b.stargazers_count - a.stargazers_count;
        }
        return a.name.localeCompare(b.name);
      })
    : [];

  return {
    repos: data || [],
    sortedRepos,
    isLoading,
    error,
    sortBy: setSortCriteria,
  };
};

🧪 테스트 예시

Hook 테스트

import { renderHook } from "@testing-library/react";

test("useSearchUsers works", async () => {
  const { result } = renderHook(() => useSearchUsers("react"));
});
컴포넌트 테스트
test("UserCard renders", () => {
  render(<UserCard user={{ login: "test" }} onClick={() => {}} />);
});

🔄 마이그레이션 전략

Before
function UserProfile({ id }) {
  useEffect(() => {
    fetchUser(id);
  }, []);
}

After
function useUser(id) {
  return useQuery({
    queryKey: ["user", id],
    queryFn: () => fetchUser(id),
  });
}

🎯 결론

→ 컴포넌트 = UI 전용 → Hook = 로직 전용

결과:

• 유지보수 ↑
• 테스트 ↑
• 재사용 ↑
• 코드 가독성 ↑
• 📌 핵심 요약
• ❌ 컴포넌트에 로직 넣지 말 것
• ✅ Custom Hook으로 분리
• ✅ React Query 활용
• ✅ UI는 pure하게 유지

클린 코드의 심리학: 우리는 왜 지저분한 코드를 작성하는가

우리는 모두 클린 코드의 중요성을 알고 있다. 단일 책임 원칙, 명확한 네이밍, 적절한 추상화, 테스트 가능성.

그럼에도 불구하고 실제 프로젝트에서는 점점 비대해지는 컴포넌트, 복잡한 조건문, 분리되지 않은 상태 관리 코드가 만들어진다.

이 문제는 기술 부족 때문만은 아니다. 대부분은 인간의 인지 구조와 심리적 편향에서 비롯된다.

이 글에서는 우리가 왜 지저분한 코드를 작성하게 되는지, 그리고 이를 어떻게 구조적으로 개선할 수 있는지를 정리한다.

1. 계획 오류 (Planning Fallacy)

왜 발생하는가

우리는 작업에 필요한 시간을 항상 과소평가한다.(혹은 초기 기획이 변경되면서) 그리고 마감이 다가오면 구조 개선이나 리팩토링은 가장 먼저 포기된다.

그 결과:

• 임시 구현이 영구 코드가 되고
• 리팩토링은 “다음에”로 미뤄지며
• 구조는 점점 복잡해진다

해결 방안

• 리팩토링 시간을 명시적으로 포함한다 기능 구현 시간과 별도로 구조 정리 시간을 계획에 포함한다.

• 작업 단위를 더 작게 나눈다 “완성된 기능”이 아니라 “리뷰 가능한 최소 단위”로 쪼갠다.

• 초기 구현은 단순하게 제한한다 첫 버전은 단일 책임만 만족하도록 설계하고, 확장은 이후에 진행한다.

• PR 크기를 제한한다 변경 범위가 과도해지면 구조를 다시 점검한다.

2. 매몰비용 오류 (Sunk Cost Fallacy)

왜 발생하는가

이미 많은 시간을 들여 작성한 코드일수록 수정하기 어려워진다. “여기까지 만들었는데 다시 하긴 아깝다”는 생각이 작동한다.

하지만 유지보수 비용은 과거의 투입 시간이 아니라 미래의 복잡성에 의해 결정된다.

해결 방안

• 코드를 결과물이 아니라 실험으로 인식한다 코드는 언제든 교체 가능한 산출물이다.

• 삭제를 전제로 리팩토링을 검토한다 고치는 것이 아니라 다시 작성하는 것이 더 나은지 항상 비교한다.

• 변경 전후를 객관적으로 비교한다 가독성, 테스트 용이성, 책임 분리 정도를 기준으로 평가한다.

• 리팩토링 체크리스트를 만든다

  • 중복이 제거되었는가?
  • 책임이 분리되었는가?
  • 테스트가 더 쉬워졌는가?

3. 복잡성 편향 (Complexity Bias)

왜 발생하는가

우리는 단순한 해결책보다 복잡한 설계를 더 “미래지향적”이라고 착각한다.

• 확장성을 과대평가하고
• 아직 존재하지 않는 요구사항을 대비하며
• 불필요한 추상화 계층을 만든다

그 결과, 실제 요구사항보다 훨씬 복잡한 구조가 만들어진다.

해결 방안

• YAGNI 원칙을 적용한다 지금 필요하지 않다면 구현하지 않는다.

• 구체 구현 후 추상화한다 최소 2~3개의 실제 사용 사례가 생긴 뒤 공통화를 고려한다.

• 질문을 고정한다

  • 이 기능은 현재 요구사항에 포함되는가?
  • 확장 가능성에 대한 명확한 근거가 있는가?

• 컴포넌트 역할을 명확히 분리한다

  • UI 전용
  • 상태 관리 전용
  • 도메인 로직 전용

4. 결정 피로와 인지 부하 (Decision Fatigue & Cognitive Load)

왜 발생하는가

작업 시간이 길어질수록 판단의 질은 떨어진다. 상태가 많아질수록, 분기가 깊어질수록, 머릿속에서 동시에 추적해야 할 정보가 증가한다.

인간의 작업 기억은 제한적이다. 그 한계를 초과하면 코드 품질은 급격히 저하된다.

해결 방안

• 상태 개수 제한 규칙을 둔다 한 컴포넌트에 상태가 과도해지면 분리를 검토한다.

• 조건문 깊이를 제한한다 중첩이 깊어지면 함수를 분리한다.

• 세션 단위로 작업한다 일정 시간마다 구조를 다시 검토한다.

• 패턴을 표준화한다 팀 내 상태 관리 방식과 구조 패턴을 통일한다.

• 구조 점검 질문을 활용한다

  • 이 컴포넌트의 책임을 한 문장으로 설명할 수 있는가?
  • 테스트 시 mocking 범위가 과도하지 않은가?

핵심 정리

🛠 어떻게 개선할 수 있는가?

1. 시작은 작게, 점진적으로 확장하기

처음부터 모든 기능을 하나의 거대한 컴포넌트에 담지 않는다. 현재 요구사항을 충족하는 최소 단위 구현부터 시작하고, 필요할 때 확장한다.

예시

const UserDashboard = () => {
  const { users, loading, error } = useUsers();

  if (loading) return <LoadingSpinner />;
  if (error) return <ErrorMessage error={error} />;

  return <UserList users={users} />;
};

이 구조의 특징은 다음과 같다:

• 데이터 패칭은 useUsers 훅에 위임
• 로딩과 에러 처리는 명확하게 분리
• UI 렌더링은 UserList에 위임
• 각 책임이 한눈에 보임

핵심은 처음부터 확장성을 설계하지 않는 것이다. 필요가 생길 때, 실제 사용 사례를 기반으로 확장한다.

2. 팀 및 심리적 환경 정비

클린 코드는 개인의 의지로만 유지되지 않는다. 구조를 유지할 수 있는 환경이 필요하다.

반드시 필요한 요소

• 리팩토링 시간 확보 기능 개발과 동일한 수준으로 구조 개선 시간을 인정한다.

• 실수를 인정할 수 있는 문화 “처음에 잘못 설계했다”는 말을 할 수 있어야 구조 개선이 가능하다.

• 코드 리뷰 활성화 단순 동작 확인이 아니라 구조, 책임 분리, 확장성 관점에서 리뷰한다.

• 클린 코드 사례 공유 좋은 사례를 반복적으로 노출시키면 팀 기준이 정립된다.

3. 작은 습관이 구조를 만든다

거대한 리팩토링보다 더 중요한 것은 반복 가능한 습관이다.

① 5분 규칙

구현 전에 5분 동안 “가장 단순한 해결책은 무엇인가?”를 먼저 고민한다.

대부분의 과도한 추상화는 이 5분을 생략하면서 시작된다.

② 코드 리뷰 체크 질문

• 이 코드를 다른 사람에게 자신 있게 설명할 수 있는가?
• 리뷰어에게 보여주기 꺼려지는 부분은 없는가?

감정적 기준이지만, 구조적 문제를 빠르게 드러낸다.

③ 미래의 나 테스트

• 6개월 후에 이 코드를 쉽게 이해할 수 있는가?
• 변경이 생겼을 때 어디를 수정해야 할지 명확한가?

클린 코드는 현재의 동작이 아니라 미래 변경 비용을 낮추는 설계다.

결론

클린 코드는 기술적 테크닉의 문제가 아니다. 그것은 다음을 관리하는 문제에 가깝다.

• 시간 압박
• 인지적 한계
• 심리적 편향

시작은 작게. 구조는 명확하게. 확장은 필요할 때만.

이 원칙을 반복적으로 적용할 때 비로소 지저분해지지 않는 코드가 만들어진다.

지저분한 코드는 기술이 부족해서 생기는 문제가 아니다. 대부분은 인간의 인지적 한계와 심리적 편향에서 비롯된다.

클린 코드는 “더 잘 짜는 능력”의 문제가 아니라, 구조적 제약을 설계하고 편향을 통제하는 습관의 문제에 가깝다.

좋은 코드는 의지로 유지되지 않는다. 환경과 규칙이 그것을 가능하게 만든다.