5. 단위 추출, 새로운 의미 수준

챕터 5: 단위 추출 & 새로운 의미 수준 창조 - 개념으로 복잡성 정복하기

목표:

추상화의 궁극적인 목표가 단순히 코드를 숨기는 것이 아니라, 복잡함 속에서 '명확한 새로운 의미 수준(New Semantic Level)'을 창조하는 것임을 이해시킨다. (다익스트라 인용)

복잡한 코드나 반복되는 패턴 뒤에 숨어있는 핵심 개념(본질)을 식별하는 능력을 기른다.

식별된 개념에 **정확하고 명료한 이름('새로운 단어')**을 부여하고, 그 **정의('명시적 계약')**를 코드로 설계하는 구체적인 과정을 학습한다.

이 과정을 통해 코드베이스의 **표현력과 '단순함(Simple)'**을 극대화하는 창조적 설계 능력을 훈련한다.

1. 도입: 추상화의 정수(精髓) - 새로운 '단어'를 발명하라

•

복습 & 다음 단계: 우리는 '얽힘'을 보고, '복잡성'을 이해하고, '일반해'를 알며, '경계 설계' 관점에서 '조립'하는 법을 배웠다. 이제 추상화의 가장 강력하고 창조적인 단계로 나아간다.

•

다익스트라 소환: "추상화의 목적은 모호하게 만드는 것이 아닌, 아주 명확한 새로운 의미 수준을 만드는 것이다." 이 말의 진짜 의미를 파헤쳐 보자. 추상화는 단순히 코드를 숨기거나 재사용하는 기술적 행위를 넘어, 복잡한 현실 세계의 문제를 **'이름 붙일 수 있는 새로운 개념'**으로 정복하는 지적 활동이다.

•

'추출'을 넘어서: 이전 단계에서 배운 '단위 추출'이나 리팩토링은 중요하다. 하지만 이 챕터의 목표는 한 단계 더 나아가, 추출된 단위에 **'영혼'(의미)**을 불어넣고, 코드베이스 전체에서 통용될 **'새로운 어휘'**를 창조하는 것이다. 당신은 이제 코드 '분석가'를 넘어 코드 '언어학자'가 되어야 한다. 

2. 언제 '새로운 단어'가 필요한가? (신호 감지)

단순히 모든 함수/컴포넌트가 '새로운 의미'는 아니다. 언제 특별히 '명확한 새로운 의미 수준'을 창조해야 할까?

•

반복되는 복잡성: 여러 곳에서 유사하지만 미묘하게 다른 방식으로 구현되는 복잡한 로직 덩어리를 발견했을 때. (e.g., 다양한 종류의 할인율 계산 로직)

•

'이름 없는' 코드: 코드를 읽을 때 "이 블록은 대체 '뭐라고 불러야 할지' 모르겠다" 싶은, 책임이 모호하고 설명하기 어려운 부분을 마주했을 때.

•

흩어진 비즈니스 규칙: 하나의 비즈니스 규칙(e.g., 사용자 등급별 권한 정책)이 여러 컴포넌트나 훅에 걸쳐 if문 등으로 흩어져 있을 때.

•

정책/제약 조건 강제: 특정 방식(e.g., 접근 제어, 입력 형식 검증)이 시스템 전반에 걸쳐 일관되게 적용되어야 할 필요성을 느낄 때.

3. '의미 수준' 창조 과정: 복잡성에서 개념으로 (How-to)

'새로운 단어'를 발명하고 '정의'하는 구체적인 5단계 프로세스를 제시한다.

•

1단계: 본질 식별 - 구현 너머의 '의미' 찾기:

◦

복잡한 코드 덩어리를 보며 "이 코드는 '기술적으로(How)' 무엇을 하는가?"를 넘어, "'그래서(What/Why)' 무엇을 달성하려는 것인가?"를 질문한다. 숨겨진 **핵심 '목적'이나 '개념'**을 찾아낸다.

◦

비유: "사용자 역할을 확인하고, 특정 기능 플래그가 켜져 있는지 보고, 데이터 상태에 따라 버튼을 활성화/비활성화하는 코드" 이면의 본질은 **"특정 액션에 대한 사용자 권한 확인"**일 수 있다.

•

2단계: '단어' 발명 - 개념에 이름 붙이기:

◦

식별된 핵심 개념(본질)을 가장 정확하고, 간결하며, 명료하게 나타내는 **'새로운 단어'(이름)**를 발명한다. 이 이름은 팀과 코드베이스의 새로운 '공식 어휘'가 된다.

◦

가이드라인: 구현 세부사항(e.g., checkUserRoleAndFlag)보다 **'의미'(e.g., useAccessControl, PermissionGuard)**를 반영해야 한다. 모호하거나 너무 일반적인 이름(e.g., Helper, Utils)은 피한다.

•

3단계: '정의' 내리기 - 명시적 계약(인터페이스) 설계:

◦

발명한 '단어'(함수/컴포넌트/훅)가 무엇을 의미하는지, 즉 어떤 책임을 지고 외부와 어떤 **'계약(인터페이스 - Props, 함수 시그니처, 타입)'**으로 소통할지를 정밀하게 설계한다. 이것이 새로운 의미 수준의 '문법'이자 공식 '정의'이다.

◦

가이드라인: 인터페이스는 최소한으로 필요한 것만 노출하고(캡슐화), 안정적이어야 하며(구현 변경에 영향받지 않도록), 예측 가능해야 한다(이름과 동작 일치).

•

4단계: 구현 및 캡슐화 - '정의'에 생명 불어넣기:

◦

설계된 '계약(인터페이스)'에 따라 실제 코드를 구현한다. 이때, 원래의 복잡했던 로직(세부사항)은 이 새로운 단위 내부로 숨겨 캡슐화한다.

◦

핵심: 구현이 인터페이스를 따르게 해야지, 구현의 편의를 위해 인터페이스(계약)를 타협해서는 안 된다.

•

5단계: '의미' 검증 및 공유 - 새로운 어휘 전파:

◦

만들어진 '단어'와 '정의'가 정말로 명확하고 유용한 새로운 의미 수준을 창조했는지 검증한다. 이 추상화를 사용함으로써 주변 코드가 더 '단순해지고(Simple)' 읽기 쉬워졌는가?

◦

새로운 개념과 그 사용법을 팀과 공유하고 코드베이스 전반에 일관되게 적용될 수 있도록 문서화하거나 컨벤션으로 만든다.

4. 사례 연구: 복잡한 조건부 렌더링 → PermissionGuard

'의미 수준 창조 과정'을 구체적인 예시로 보여준다.

•

얽힌 코드 (Before): 사용자 역할, 기능 플래그, 데이터 상태 등 다양한 조건이 뒤섞여 UI 일부를 보여주거나 숨기는 로직이 컴포넌트 내부에 복잡하게 얽혀 있는 코드 제시. (이전 ArticleDisplay 예시 활용 또는 강화)

// Bad Example: Tangled conditions = No clear semantic level
function ArticleActions({ article, user, featureFlags }) {
  const canEdit = /* 복잡한 편집 권한 체크 로직 */;
  const canDelete = /* 복잡한 삭제 권한 체크 로직 */;
  const canPublish = /* 복잡한 발행 권한 체크 로직 */;
  // ... 이 로직들이 다른 컴포넌트에도 반복됨 ...

  return (
    <div>
      {canEdit && <EditButton />}
      {canDelete && <DeleteButton />}
      {canPublish && <PublishButton />}
    </div>
  );
}
TypeScript
복사

•

'의미 수준 창조' 과정 적용:

본질 식별: 이 코드의 본질은 "특정 액션(편집, 삭제, 발행)을 수행할 권한이 있는지 확인하고, 그 결과에 따라 UI를 보여주는 것"이다.

'단어' 발명: PermissionGuard (컴포넌트) 또는 useAuthorization(훅)

'정의' 내리기 (계약 설계): PermissionGuard는 requiredPermission: string (e.g., "article:edit") prop을 받고, 현재 사용자가 해당 권한이 있으면 children을 렌더링하고, 없으면 아무것도 렌더링하지 않거나 fallback prop을 렌더링한다. 권한 확인 로직(How)은 내부에 캡슐화한다.

구현 및 캡슐화: useContext 등으로 현재 사용자 정보를 가져와 권한을 확인하는 로직을 PermissionGuard 컴포넌트 내부에 구현한다.

'의미' 검증:

•

단순해진 코드 (After): PermissionGuard를 사용하여 리팩토링된 코드 제시. 코드가 이제 '권한 확인'이라는 새롭고 명확한 의미 수준에서 읽힘을 강조.

// Good Example: New Semantic Level "PermissionGuard" created
function ArticleActions({ article }) {
  return (
    <div>
      <PermissionGuard requiredPermission="article:edit" resource={article}>
        <EditButton />
      </PermissionGuard>
      <PermissionGuard requiredPermission="article:delete" resource={article}>
        <DeleteButton />
      </PermissionGuard>
      <PermissionGuard requiredPermission="article:publish" resource={article}>
        <PublishButton />
      </PermissionGuard>
    </div>
  );
}
// 코드가 훨씬 선언적이고, 권한 확인(How) 로직이 숨겨져 'What'만 드러남.
TypeScript
복사

5. 실전 연습: '새로운 단어' 발명하기

독자가 직접 '새로운 의미 수준'을 창조하는 연습.

•

문제 코드 제시: 여러 컴포넌트에서 반복되는 복잡한 데이터 포맷팅 로직 (e.g., 날짜, 통화, 사용자 이름 등을 특정 규칙에 따라 조합하여 표시) 또는 복잡한 상태 전이 로직 (e.g., 주문 상태 변경 로직) 제시.

•

과제: 제시된 코드의 본질을 식별하고, 그 본질을 나타내는 '새로운 단어'(이름)를 발명하며, 그 단어의 **'정의'(인터페이스/계약)**를 설계해 보시오. 왜 이것이 '명확한 새로운 의미 수준'을 만든다고 생각하는지 설명하시오.

6. 결론: 당신은 코드의 '언어학자'다

•

다익스트라 재인용 및 강조: 추상화는 모호함이 아닌 **'정밀한 의미'**를 창조하는 행위다.

•

가장 강력한 추상화는 **문제의 본질을 꿰뚫는 '이름'**을 찾아내고 그 '정의'를 명확히 하는 것에서 시작된다.

•

이 능력은 단순히 기술을 아는 것을 넘어, 복잡성을 '개념'으로 정복하는 가장 창조적이고 강력한 엔지니어링 기술이다. 이 기술을 연마하는 것이 '숙련'의 핵심이다. (다음 챕터 예고)

이 플랜은 '단위 추출'을 넘어 추상화의 본질인 **'의미 창조'**에 집중하며, 다익스트라의 통찰을 구체적인 실천 방법론으로 연결합니다. 독자가 수동적으로 지식을 습득하는 것을 넘어, 능동적으로 개념을 정의하고 설계하는 창조적 활동에 참여하도록 유도합니다.