Dorong Dorong 💻😴

FSD 아키텍처와 함께 생각해보기

Vue3에서 React.js로 프로젝트를 마이그레이션하면서 Feature-Sliced Design(FSD) 아키텍처를 도입하기로 결정했습니다. 그 과정에서 배럴 파일(barrel files)에 대한 고민이 생겼고, 최근 몇 년 사이에 이에 대한 관점이 많이 바뀌었다는 것을 발견했습니다.

배럴 파일이란?

배럴 파일은 여러 모듈을 하나의 파일(주로 index.js 또는 index.ts)에서 다시 내보내는 패턴입니다. 이 패턴은 코드 정리와 import 문을 단순화하는 데 도움이 됩니다.

배럴 파일 없이:

// 각 파일에서 개별적으로 가져오기 
import { Button } from "../components/Button"; 
import { TextField } from "../components/TextField"; 
import { Checkbox } from "../components/Checkbox";

배럴 파일 사용 시:

// 하나의 경로에서 모든 컴포넌트 가져오기 
import { Button, TextField, Checkbox } from "../components";

배럴 파일의 실제 구현

일반적인 배럴 파일 (components/index.ts):

// 와일드카드 내보내기 (권장하지 않음) 
export * from './Button'; 
export * from './TextField'; 
export * from './Checkbox'; 

// 또는 명시적 내보내기 (권장) 
export { Button } from './Button'; 
export { TextField } from './TextField'; 
export { Checkbox } from './Checkbox';

배럴 파일의 성능 문제

Marvin의 JavaScript 생태계 속도 개선: 배럴 파일 문제 글에서 지적한 바와 같이, 배럴 파일은 다음과 같은 성능 문제를 일으킬 수 있습니다:

1. 모듈 그래프 복잡성 증가: 배럴 파일이 증가할수록 모듈 간 의존성 그래프가 복잡해집니다.
2. 불필요한 모듈 로딩: 특히 와일드카드 내보내기(export * from)를 사용할 경우, 실제로 필요하지 않은 모듈까지 로드될 수 있습니다.

모듈 그래프 비교

배럴 파일 없이:

App.js
├── Button.js
├── TextField.js
└── Checkbox.js

배럴 파일 사용 시:

App.js
└── components/index.js
    ├── Button.js
    ├── TextField.js
    └── Checkbox.js

성능 테스트 결과 예시

모듈 수배럴 파일 없음배럴 파일 사용차이

참고: 이 수치는 예시용이며, 실제 프로젝트에서는 다양한 요인에 따라 달라질 수 있습니다.

FSD 아키텍처에서의 배럴 파일

Feature-Sliced Design(FSD)은 배럴 파일과 유사한 패턴을 의도적으로 활용합니다. 이는 단순히 코드 작성의 편의성을 위한 것이 아니라, 아키텍처의 구조와 목적을 반영한 결정입니다.

FSD는 애플리케이션을 기능 단위로 분할하고 계층화된 구조를 만드는 것을 목표로 합니다. 이 구조에서 각 레이어(layer)와 슬라이스(slice)는 명확한 책임과 역할을 가집니다. 배럴 파일과 유사한 패턴을 사용함으로써, FSD는 다음과 같은 이점을 얻습니다:

• 캡슐화: 각 모듈의 내부 구현을 숨기고 공개 API만을 노출합니다.
• 의존성 관리: 상위 레이어가 하위 레이어에만 접근할 수 있도록 제한합니다.
• 재사용성: 공통 기능을 쉽게 공유하고 재사용할 수 있게 합니다.
• 유지보수성: 코드 구조를 일관되게 유지하여 개발자가 쉽게 이해하고 수정할 수 있게 합니다.

이러한 구조는 대규모 프로젝트에서 코드의 조직화와 관리를 용이하게 만들어, 장기적으로 프로젝트의 확장성과 유지보수성을 향상시킵니다. 따라서 FSD에서 배럴 파일과 유사한 패턴의 사용은 단순한 편의성을 넘어서, 아키텍처의 핵심 원칙을 실현하기 위한 전략적 선택이라고 볼 수 있습니다.

FSD에서의 배럴 파일 활용 - 실제 경험과 팁

FSD 아키텍처를 실제 프로젝트에 적용해본 경험에 따르면, 배럴 파일(Public API)의 주요 이점 중 하나는 유지보수성 향상입니다. 이에 대해 이너서클 재직자 과정에서 만난 동료 개발자분께서 다음과 같은 인사이트를 공유해주셨어요:

"FSD를 사용하면서 느낀 바로는, Public API를 활용하는 주된 이유 중 하나가 유지보수에 있습니다. 예를 들어, entities/user의 스키마가 일부 변경되더라도 features/loginUser, features/registerUser 등에서 import 구문을 변경할 필요가 없어집니다."

이는 FSD의 핵심 원칙 중 하나인 모듈 간 의존성 관리와 일치하는 관점입니다.

배럴 파일 생성 자동화

대규모 프로젝트에서 매번 수동으로 배럴 파일(Public API)을 관리하는 것은 번거로울 수 있습니다. 이를 해결하기 위한 실용적인 접근 방법으로, 배럴 파일을 자동으로 생성하는 스크립트를 활용할 수 있습니다.

예를 들어:

pnpm api features/loginUser

이러한 CLI 명령어를 통해 features/loginUser 내부의 모듈을 자동으로 분석하고, 명시적으로 내보내는 배럴 파일을 생성할 수 있습니다. 이때 _로 시작하는 파일이나 폴더는 내부용으로 간주하여 자동으로 제외할 수 있습니다.

명시적 내보내기의 중요성

앞서 언급했듯이, 와일드카드 내보내기(export * from './module')는 권장되지 않습니다. 대신, 명시적 내보내기를 사용하면 성능 이슈를 최소화하면서도 FSD의 이점을 충분히 활용할 수 있습니다.

// Good: 명시적 내보내기
export { LoginForm } from './LoginForm';
export { useAuth } from './useAuth';
export type { User } from './types';

이러한 접근 방식은 모듈의 공개 API를 명확히 정의하고, 불필요한 의존성을 방지하며, 코드의 가독성과 유지보수성을 향상시킵니다. 좀 더 상세한 예시를 들어볼게요.

스크립트에 대한 폴더 구조 예시:

project-root/
├── src/
│   ├── features/
│   │   └── loginUser/
│   │       ├── ui/
│   │       ├── model/
│   │       └── index.ts (자동 생성될 파일)
│   └── ... (다른 FSD 폴더들)
├── scripts/
│   └── generate-barrel.ts
├── package.json
└── tsconfig.json

scripts/generate-barrel.ts 파일의 내용:

import fs from 'fs';
import path from 'path';

function generateBarrel(directory: string) {
  const files = fs.readdirSync(directory);
  const exports: string[] = [];

  files.forEach(file => {
    if (file.startsWith('_') || file === 'index.ts') return;

    const filePath = path.join(directory, file);
    const stats = fs.statSync(filePath);

    if (stats.isDirectory()) {
      exports.push(`export * from './${file}';`);
    } else if (file.endsWith('.ts') || file.endsWith('.tsx')) {
      const name = path.parse(file).name;
      exports.push(`export { ${name} } from './${name}';`);
    }
  });

  const content = exports.join('\n') + '\n';
  fs.writeFileSync(path.join(directory, 'index.ts'), content);
}

const targetDir = process.argv[2];
if (!targetDir) {
  console.error('Please specify a target directory');
  process.exit(1);
}

const fullPath = path.resolve(process.cwd(), targetDir);
generateBarrel(fullPath);
console.log(`Barrel file generated for ${fullPath}`);

package.json에 스크립트 추가:

{
  "scripts": {
    "api": "ts-node scripts/generate-barrel.ts"
  }
}

이제 pnpm api features/loginUser 명령어를 실행하면, src/features/loginUser/index.ts 파일이 자동으로 생성되거나 업데이트됩니다! 아래부터는 좀 더 일반적인 예시를 들어볼게요.

FSD 기본 폴더 구조:

src/
├── app/        # 글로벌 설정, 스타일, 프로바이더
├── processes/  # 비즈니스 프로세스
├── pages/      # 페이지 컴포넌트
├── widgets/    # 복합 UI 블록
├── features/   # 사용자 인터랙션
├── entities/   # 비즈니스 엔티티
└── shared/     # 공유 유틸리티, UI 키트

FSD에서의 배럴 파일 사용 예시

features/auth/index.ts (적절한 배럴 파일 사용):

// 명시적 내보내기 - 공개 API를 명확히 정의
export { LoginForm } from './ui/LoginForm';
export { useAuth } from './model/useAuth';
export type { AuthUser } from './model/types';

균형 잡힌 접근법: 실제 구현 예시

1. 구조화된 배럴 파일 사용:

features/
├── auth/
│   ├── ui/
│   │   ├── LoginForm.tsx
│   │   └── RegisterForm.tsx
│   ├── model/
│   │   ├── useAuth.ts
│   │   └── types.ts
│   └── index.ts  # 아키텍처 경계에만 배럴 파일 사용
└── userProfile/
    ├── ui/
    ├── model/
    └── index.ts

2. 명시적 내보내기:

// features/auth/index.ts
// 명시적 내보내기로 공개 API 정의
export { LoginForm } from './ui/LoginForm';
export { RegisterForm } from './ui/RegisterForm';
export { useAuth } from './model/useAuth';
export type { User, AuthCredentials } from './model/types';

3. FSD 아키텍처 규칙에 따른 가져오기:

// 잘못된 방식: 레이어 우회
import { Button } from '@/shared/ui/Button';

// 올바른 방식: 아키텍처 경계 존중
import { Button } from '@/shared/ui';

4. 실제 React 컴포넌트 예시:

// features/auth/ui/LoginForm.tsx
import { useState } from 'react';
import { Button, TextField } from '@/shared/ui';
import { useAuth } from '../model/useAuth';
import type { AuthCredentials } from '../model/types';

export const LoginForm = () => {
  const [credentials, setCredentials] = useState({
    email: '',
    password: ''
  });
  const { login, isLoading } = useAuth();

  const handleSubmit = (e: React.FormEvent) => {
    e.preventDefault();
    login(credentials);
  };

  return (
    
      <TextField
        label="Email"
        value={credentials.email}
        onChange={(e) => setCredentials(prev => ({
          ...prev,
          email: e.target.value
        }))}
      />
      <TextField
        type="password"
        label="Password"
        value={credentials.password}
        onChange={(e) => setCredentials(prev => ({
          ...prev,
          password: e.target.value
        }))}
      />
      
        {isLoading ? 'Logging in...' : 'Login'}
      
    
  );
};

현대적 도구의 영향

최신 빌드 도구들은 배럴 파일의 성능 문제를 일부 완화할 수 있습니다:

번들러별 최적화 설정:

Vite 설정 예시:

// vite.config.js
export default {
  build: {
    target: 'esnext',
    minify: 'esbuild',
    rollupOptions: {
      output: {
        manualChunks(id) {
          // 최적화된 청크 설정
        }
      }
    }
  }
}

Webpack 설정 예시:

// webpack.config.js
module.exports = {
  optimization: {
    usedExports: true, // 트리 쉐이킹 활성화
    moduleIds: 'deterministic',
    splitChunks: {
      chunks: 'all',
    }
  }
}

성능 측정 - 실시간 프로젝트 모니터링

// build-analyzer.ts
import { performance } from 'perf_hooks';

export function measureBuildTime(taskName: string, task: () => void) {
  const startTime = performance.now();
  task();
  const endTime = performance.now();
  console.log(`Task "${taskName}" took ${endTime - startTime}ms`);
}

// 사용 예시
measureBuildTime('Module compilation', () => {
  // 빌드 로직
});

결론 - 프로젝트 규모별 권장 접근법

소규모 프로젝트 (10,000줄 이하)

src/
├── components/
│   └── index.ts  # 배럴 파일 사용 가능
├── hooks/
│   └── index.ts  # 배럴 파일 사용 가능
└── utils/
    └── index.ts  # 배럴 파일 사용 가능

중간 규모 프로젝트 (10,000~50,000줄)

src/
├── features/
│   ├── feature1/
│   │   └── index.ts  # 아키텍처 경계에만 배럴 파일
│   └── feature2/
│       └── index.ts
└── shared/
    ├── ui/
    │   └── index.ts  # 명시적 내보내기 사용
    └── lib/
        └── index.ts  # 명시적 내보내기 사용

대규모 프로젝트 (50,000줄 이상)

src/
├── app/
├── processes/
├── pages/
│   └── index.ts  # 엄격하게 제한된 배럴 파일
├── widgets/
│   └── index.ts  # 엄격하게 제한된 배럴 파일
├── features/
│   └── [각 기능별]/
│       └── index.ts  # 공개 API만 명시적 내보내기
├── entities/
│   └── [각 엔티티별]/
│       └── index.ts  # 공개 API만 명시적 내보내기
└── shared/
    └── [각 모듈별]/
        └── index.ts  # 성능 측정 후 결정

배럴 파일의 사용은 결국 개발 경험과 성능 사이의 균형을 찾는 문제라 생각합니다.

FSD 아키텍처를 도입한다면, 배럴 파일의 장단점을 인식하고 프로젝트의 규모와 팀의 필요에 맞게 적절히 조절하는 것이 중요할 것 같아요.

명확한 아키텍처 경계, 명시적인 내보내기, 그리고 현대적인 빌드 도구를 활용한다면, 배럴 파일의 이점을 취하면서도 성능 문제를 최소화할 수 있습니다!

왜 인프라와 데브옵스를 공부하게 되었나요? 🤔

안녕하세요, 오늘은 인프라와 데브옵스에 관한 이야기를 적어보려 합니다. (연휴라 오랜만에 적어봅니다! 삼일절 만세!)

현재 저는 회사에서 도커와 쿠버네티스 환경에서 작업 중이에요. 팀원들과 원활한 소통을 위해 스터디와 같은 다양한 학습을 시작하게 되었습니다.

하지만 단순히 개념만 공부하는 것은 아쉬웠어요.

그래서 실제로 인프라를 운영하는 데브옵스 팀과의 협업이라는 관점에서 정리해보고 싶었습니다.

또한 제가 개인적으로 운영 중인 상용 프로젝트에서도 수의사분들의 운영비용 절감을 위해 인프라 학습이 큰 도움이 될 것이라고 판단했어요. 이런 실질적인 필요성이 더 깊은 학습을 가능하게 만들어줍니다.

이 글은 현재 제게 필요한 내용과 제 주관이 들어간 정리본이니, 읽으시는 분들도 꼭 교차검증이나 추가적인 학습을 진행하시는 것을 추천드려요!

인프라 지식의 실무적 가치 🌉

• 인프라를 이해하면 개발 환경과 배포 과정을 완벽하게 제어할 수 있어요.
• 클라우드 인프라에 능숙해지면 리소스 확장과 비용 최적화를 손쉽게 관리할 수 있어요.
• 도커 & 쿠버네티스를 자연스럽게 다루면 어떤 환경에서도 일관된 개발과 신속한 배포가 가능해져 작업 효율이 크게 향상돼요!

데브옵스 철학 💭

• 데브옵스 철학에서는 개발이 운영까지 하는 것을 원칙으로 해요.
• 개발자가 운영환경까지 관여하는 것을 다루는 것이 데브옵스 철학이에요.
• 이때 많이 다루는 기술셋 중 하나가 도커와 쿠버네티스예요.

도커 역량은 어느정도가 필요할까요? 🐳

• 개발자는 기본적으로 애플리케이션을 Docker 컨테이너를 사용하여 패키징, 배포, 실행하는 전체 과정인 도커라이징을 할 수 있어야 해요.
• 컨테이너 상황에서의 최적화와 일반적인 애플리케이션 배포 상황에서의 최적화 방법이 다르기 때문이에요.
  • 예: 컨테이너 내부는 불변성(immutability)을 가지므로 로그를 어떻게 관리할지 고민해야 해요.
  • 컨테이너 이미지 크기 최소화: 불필요한 파일과 종속성을 제거하여 이미지 크기를 줄여야 해요.
  • 컨테이너 내부의 데이터를 외부로 링크를 걸어줄 때 사용하는 기능(볼륨)을 통해 영속적 데이터를 관리해야 해요.
• 도커로 갔을 때 어떤 특성이 있고 어떤 식으로 최적화해야 할지 이런 것들을 설계할 수 있어야 해요.
  • 이미지 레이어 최적화 (캐싱 활용)
  • 멀티 스테이지 빌드 사용: 하나의 Dockerfile에서 여러 단계를 거쳐 최종 이미지를 만드는 방법으로, 빌드 도구나 소스 코드 없이 실행 파일만 포함된 작은 크기의 최종 이미지를 생성해요.
  • 비루트 사용자로 애플리케이션 실행하기
  • 환경변수를 통한 설정 관리

아키텍처 설계 방법은? 🏗️

• 일반적으로 단순히 애플리케이션을 배포해서 서비스할 때는 모놀리식(Monolithic) 상태로 배포해야 할 때가 있어요.
• 도커나 쿠버네티스를 다루다 보면 마이크로서비스 상태로 설계하고 쪼개야 할 때가 많아요.
• 쿠버네티스의 특성을 활용하는 경우도 많아요.
  • 서비스 분리와 독립적 스케일링
  • 장애 격리(Fault Isolation)
  • 기능별 배포 및 롤백 용이성
• 예시)
  • 모놀리식 아키텍처는 전체 애플리케이션이 하나의 큰 코드베이스로 구성되어 있어 개발, 테스트, 배포가 상대적으로 간단해요.
  • 그러나 아래와같은 이유로 도커나 쿠버네티스와 같은 컨테이너 기술을 다루다 보면, 애플리케이션을 마이크로서비스 아키텍처로 설계하고 분할해야 하는 경우가 많아져요.
    • 독립적인 배포: 각 서비스를 개별적으로 배포할 수 있어, 전체 시스템을 중단하지 않고도 특정 기능을 업데이트하거나 확장할 수 있어요 (API 서버, 프론트엔드, 데이터베이스 등으로 분리하여 각각을 독립적인 컨테이너로 운영).
    • 리소스 효율성: 쿠버네티스의 특성상 각 서비스에 필요한 리소스를 개별적으로 할당하고 관리할 수 있어, 메모리와 CPU 사용을 최적화할 수 있어요.
    • 기술 다양성: 각 마이크로서비스는 독립적이므로, 서비스별로 가장 적합한 기술 스택을 선택할 수 있어요.

프론트엔드 개발자도 배포에 관심을 가져야 해요! 🌐

당장 도커까진 아니더라도, React.js를 다루는 프론트엔드 개발자분들 중에 배포를 완전히 백엔드 개발자나 인프라팀에 넘기고 관심을 두지 않는 경우가 있어요. 하지만 이러면 많이 아쉽잖아요?!

아래에 제 기준을 적어놨어요.

• FE도 배포를 클라우드쪽에 하다보니 클라우드 기술들을 많이 알고 있어야 해요.
• 이를테면 FE쪽에서 다루다보면 Node.js로 개발하고 서빙을 하게 돼요.
• 실제로 클라우드를 사용하게 되면 'CFS3'라고 많이 이야기를 하는데, 이는 CloudFront 더하기 S3로 스태틱하게 파일을 빌드해서 서빙한다는 뜻이에요.
• 이런 것들을 하기 위해서는 데브옵스팀과 이야기를 해야 하고, 적어도 내가 개발하는 시스템이 어떤 형상으로 배포되어 서빙될 것인지 그 구조를 알아야 인프라팀이나 데브옵스팀, 혹은 클라우드 엔지니어와의 대화가 편하실 거예요.

그러니 프론트엔드 개발자분들도 배포 과정과 인프라에 대해 알고 계셔야 좋습니다!!

데브옵스 엔지니어와의 협업은 어떻게 이루어질까요? 🤝

• 데브옵스 엔지니어는 서비스를 오픈하기 전이나 인프라에 배포하기 전에 쿠버네티스에 배포하기 위해 몇 가지 질문을 하게 돼요 (이때 잘 대답하기 위해 지금부터 설명할 내용들을 학습해보아요).
• 이때 쿠버네티스나 도커 같은 기반기술을 폭넓게 알고 있지 않으면 문제가 되는 경우가 많아요.
  • 리소스 요구사항(CPU, 메모리)
  • 네트워크 정책 및 요구사항
  • 환경변수 및 구성 관리 방법
  • 상태 관리 전략

그럼 협업을 위해 알아야 할 쿠버네티스 이론은 무엇이 있을까요? ☸️

• 운영 측면에서 필요한 쿠버네티스 이론이 있고 개발이나 배포 측면에서 필요한 쿠버네티스 이론이 있어요.
• 개발자는 개발이나 배포 측면에서 필요한 쿠버네티스 이론을 많이 다루는 것이 좋아요.

개발자가 알아야 할 쿠버네티스 리소스 📦

• 개발이나 배포 측면에서 다루는 쿠버네티스 리소스들은:
  • 파드(Pod): 쿠버네티스의 가장 기본적인 배포 단위예요 (원래 표기는 Pod이며 한글로는 '파드'로 표기해요).
  • 서비스(Service): 파드 집합에 대한 단일 진입점을 제공하는 추상화 계층이에요.
    • 서비스는 여러 파드에 걸쳐 트래픽을 로드밸런싱 해주는 역할을 해요.
    • ClusterIP, NodePort, LoadBalancer, ExternalName 등 다양한 유형이 있어요.
    • 서비스 디스커버리와 내부 DNS를 통해 마이크로서비스 간 통신을 가능하게 해요.
    • 파드의 생성, 삭제, 재시작에 관계없이 안정적인 엔드포인트를 제공해요.
    • 레이블 셀렉터를 통해 어떤 파드가 서비스에 포함될지 결정해요.
  • 인그레스(Ingress): 클러스터 외부에서 내부 서비스로의 HTTP/HTTPS 라우팅 규칙 관리예요.
  • 인그레스 컨트롤러(Ingress Controller): 인그레스 규칙을 실제로 구현하는 컴포넌트예요.
• 컨트롤 플레인 영역은 아직 깊게 알 필요 없다고 판단했어요. 기본적인 것만 알면 됩니다!
  • 기본적인것의 예시:
    • kube-apiserver가 무슨 일을 하는지, kube-dns(CoreDNS)가 무슨 일을 하는지 정도의 기본 개념만 알면 돼요.

데브옵스/인프라 전문가가 알아야 할 것 🔍

• 인프라를 전문적으로 다루거나 데브옵스를 하게 되면 컨트롤 플레인 영역에서 다루는 4대 컴포넌트에 대해 상세히 알아야 해요.
  • kube-apiserver: API 요청을 처리하는 프론트엔드예요.
  • etcd: 클러스터 상태를 저장하는 키-값 데이터베이스예요.
  • kube-scheduler: 파드를 노드에 할당하는 컴포넌트예요.
  • kube-controller-manager: 다양한 컨트롤러를 실행하는 컴포넌트예요.
• IRSA(IAM Roles for Service Accounts) 같은 인증 방식에 대해서도 잘 알아야 해요.
  • 서비스 계정에 대한 IAM 역할을 기반으로 한 보안 인증 정보 체인을 사용하는 방식이에요.
• GKE(Google Kubernetes Engine), AWS의 EKS(Elastic Kubernetes Service) 등 각 클라우드에서 제공하는 쿠버네티스 환경들의 특성에 대해서도 잘 알아야 해요.

리소스 설계와 구성 결정 📝

현재 환경

• 우리는 현재 OKD(OpenShift Kubernetes Distribution)라는 쿠버네티스 배포판을 사용하고 있어요.
• OKD는 Red Hat의 오픈소스 엔터프라이즈 쿠버네티스 플랫폼으로, 기본적인 쿠버네티스 기능 외에도 다양한 추가 기능들을 제공합니다.

OKD 내부 리소스 설계

• OKD 환경에서 리소스 구성을 어떻게 할지 설계하여 데브옵스 팀에 가이드를 제공해야 합니다:
  • Routes vs Ingress: OKD는 Route라는 고유 리소스를 제공하며, 이는 기본적으로 HAProxy 기반 인그레스 컨트롤러와 함께 작동해요.
  • 템플릿과 오퍼레이터: OKD에서 제공하는 템플릿과 오퍼레이터를 활용하여 애플리케이션 배포를 단순화할 수 있어요.
  • 프로젝트와 네임스페이스: OKD의 프로젝트는 쿠버네티스 네임스페이스의 확장 개념으로, 추가적인 보안 및 관리 기능을 제공해요.
  • DeploymentConfig: OKD에서는 Deployment 대신 DeploymentConfig를 사용할 수 있으며, 더 세밀한 배포 전략을 제공해요.

커스텀 리소스 및 확장 구성

• 특정 요구 사항에 따라 추가 구성이 필요할 수 있습니다:
  • 커스텀 리소스(CustomResources) 정의를 통해 OKD에서 기본적으로 제공하지 않는 리소스 타입을 구현할 수 있어요.
  • 스테이트풀셋(StatefulSet) 구성으로 상태 유지가 필요한 애플리케이션(예: 데이터베이스)을 관리할 수 있어요.
  • 서비스 메시(Service Mesh): OKD에서는 Red Hat Service Mesh(Istio 기반)를 통합하여 마이크로서비스 간 통신을 관리할 수 있어요.

인그레스 및 트래픽 관리 옵션

• OKD 환경에서 다양한 인그레스 옵션을 고려할 수 있습니다:
  • 기본 HAProxy 인그레스: OKD는 기본적으로 HAProxy 기반 인그레스 컨트롤러를 제공해요.
  • NGINX 인그레스 컨트롤러: 고부하 트래픽 환경에서는 NGINX 인그레스 컨트롤러를 대안으로 설치할 수 있어요.
    • 장점: 고성능, 세밀한 설정 가능, 광범위한 커뮤니티 지원
    • 단점: 추가 구성 및 관리 필요
  • API 게이트웨이: Kong, Ambassador 등의 API 게이트웨이를 OKD 위에 설치하여 고급 라우팅 기능을 활용할 수 있어요.

OKD의 대안책 검토

• 현재 OKD를 사용 중이지만, 필요에 따라 다른 쿠버네티스 배포판도 고려할 수 있습니다:
  • EKS(Amazon Elastic Kubernetes Service): AWS 환경에서 관리형으로 쿠버네티스를 운영하고 싶을 경우
    • 장점: 관리 부담 감소, AWS 서비스와의 통합 용이
    • 단점: OKD의 추가 기능들(CI/CD 통합, 개발자 카탈로그 등) 부재
  • GKE(Google Kubernetes Engine): Google Cloud에서 관리형 쿠버네티스를 원할 경우
  • AKS(Azure Kubernetes Service): Microsoft Azure에서 관리형 쿠버네티스를 원할 경우
  • Rancher: 다중 클러스터 관리 기능이 필요한 경우의 대안

개발자와 운영 협업

• 개발 팀에서도 인프라를 충분히 이해할 필요가 있습니다:
  • OKD의 웹 콘솔을 통해 개발자들도 배포 및 모니터링 과정에 참여할 수 있어요.
  • 개발자와 운영팀이 함께 사용할 수 있는 OKD의 CI/CD 파이프라인 구성이 가능해요.
  • 개발자들이 직접 애플리케이션 리소스 요구사항(CPU, 메모리, 스토리지 등)을 정의하도록 가이드해줘야 해요.

리소스 관리 전략 ⚙️

• 특히 쿠버네티스 환경에서는 리소스를 어떻게 쪼개고 나눌 것인지 결정이 필요해요.
• 어느 부분을 ConfigMap에 두고 어느 부분을 Secret으로 관리할 것인지에 대한 설계도 개발 팀에서 제공하면 좋아요.
  • ConfigMap: 환경별 설정, 로그 레벨, 앱 구성 등 민감하지 않은 설정이에요.
  • Secret: API 키, 인증서, 패스워드 등 민감한 정보예요.

마치며 

이상으로 인프라와 데브옵스에 관한 중요 개념들을 간략히 보았습니다! 이 글이 여러분의 학습과 업무에 도움이 되었으면 좋겠어요.

다시 한번 말씀드리지만, 이 글은 제 주관적인 관점과 경험을 바탕으로 작성되었답니다. 꼭 다른 자료들도 함께 참고하시고, 실무에 적용하실 때는 교차검증을 하시는 것을 추천드려요!

궁금한 점이나 의견이 있으시면 언제든지 댓글로 남겨주세요. 함께 성장하는 기회가 되었으면 좋겠습니다. 

감사합니다!

시간이 지난 후, 코드를 리팩토링 하는 과정에서 작업 이유에 대해 찾아보기 위해 TIL 카테고리를 만들었습니다!

오늘은 Vanilla JavaScript로 웹 컴포넌트를 만들던 중 마우스 다운(mousedown) 이벤트와 마우스 업(mouseup) 이벤트, 그리고 클릭(click) 이벤트 간의 충돌이 발생해, 각 이벤트의 동작이 서로 독립적으로 실행될 수 있도록 조정한 내용을 간단히 기록하려합니다.

문제 상황: 두 경우의 이벤트 핸들링

사용자가 상품 버튼을 클릭했을 때, 다음과 같은 시나리오를 생각했습니다:

1. 잔액이 부족한 경우
2. 잔액이 충분한 경우
3. 마우스 다운/업 이벤트와 클릭 이벤트의 상호작용

이러한 상황에서 마우스 업 이벤트의 동작에 가려져 클릭 이벤트가 동작하지 않는 상황이 발생했어요.

해결 방법: 조건부 이벤트 등록

먼저 기존 코드입니다.

  setEvent() {
    const { onSelect, onMouseDown, onMouseUp } = this.props;

    if (onSelect) {
      this.addEvent('click', '.product-button', (e) => {
        const button = e.target.closest('.product-button');
        if (!button) return;
        const productId = Number(button.dataset.id);
        onSelect(productId);
      });
    }

    if (onMouseDown) {
      this.addEvent('mousedown', '.product-button', onMouseDown);
    }

    if (onMouseUp) {
      this.addEvent('mouseup', '.product-button', onMouseUp);
    }
  }

변경된 코드입니다.

setEvent() {
  const { onSelect, onMouseDown, onMouseUp, product } = this.props;

  // 가격이 부족할 때만 mousedown/mouseup 이벤트 등록
  if (onMouseDown && this.state.balance < product.price) {
    this.addEvent('mousedown', '.product-button', () => {
      onMouseDown(product);
    });
    this.addEvent('mouseup', '.product-button', () => {
      onMouseUp();
    });
  } else {
    // 가격이 충분하거나 조건에 맞지 않으면 click 이벤트만 등록
    this.addEvent('click', '.product-button', (e) => {
      const button = e.target.closest('.product-button');
      if (!button) return;
      const productId = Number(button.dataset.id);
      onSelect(productId);
    });
  }
}

핵심 접근 방식

1. 조건부 이벤트 등록: 현재 상태에 따라 적절한 이벤트를 동적으로 바인딩합니다.
2. 이벤트 위임: closest() 메서드를 활용해 이벤트 버블링을 효율적으로 처리합니다. (글에는 없지만 component.js에서 처리)
3. 상태 기반 로직: balance와 product.price를 비교하여 이벤트 흐름을 제어합니다.

오늘 HTTP 메서드에 대한 질문을 받았습니다. 답변을 드리려고 하다보니 제가 GET, POST, DELETE, PUT, PATCH 같은 기본적인 메서드 외에는 잘 모른다는걸 알게됐어요🥲 특히 HEAD나 OPTIONS 같은 메서드들은 존재의 유무는 알았으나, 실제로 어떻게 활용되는지 명확하게 인지하지도 못했습니다.

그래서 신입 시절의 기억도 되살리고, 부족했던 부분도 채워보고자 HTTP 메서드와 그 사용법에 대해 정리해보려고 해요.

특히 React와 Next.js를 사용하시는 분들을 위해 실제 개발 환경에서 어떻게 활용되는지 구체적인 예시와 함께 설명해드리겠습니다.

HTTP 메서드 Next.js 는 Pages Router방식이 더 익숙하신 분들을 위해 API Routes handler 문법(pages/api/ 디렉토리 사용)인 Next.js 12 이전의 방식으로 작성했습니다.

App Router 방식만을 알고 계신 분들은, export async function GET() 처럼 HTTP 메서드를 함수 이름으로 사용하는 새로운 convention 방식 등을 포함한 여러 차이점이 있지만 문서를 확인하며 진행하신다면 문제없이 이해하실 수 있을 거라 생각합니다.

HTTP 메서드란?

HTTP 메서드는 클라이언트와 서버 간의 통신에서 어떤 동작을 수행할지 지정하는 방법입니다. REST API에서 매우 중요한 역할을 하며, 각 메서드는 특정한 목적을 가지고 있습니다. 이를 제대로 이해하고 사용하는 것이 웹 개발의 기초가 되죠.

주요 HTTP 메서드 살펴보기

1. GET 메서드

GET은 리소스를 조회하는 데 사용되는 가장 기본적인 메서드입니다.

React에서의 사용 예시:

// React 컴포넌트에서 데이터 조회
const UserProfile = () => {
  const [user, setUser] = useState(null);

  useEffect(() => {
    const fetchUser = async () => {
      try {
        const response = await fetch('/api/users/1');
        const data = await response.json();
        setUser(data);
      } catch (error) {
        console.error('Error fetching user:', error);
      }
    };

    fetchUser();
  }, []);

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

Next.js API Route에서의 처리:

// pages/api/users/[id].ts
import type { NextApiRequest, NextApiResponse } from 'next'

export default async function handler(
  req: NextApiRequest,
  res: NextApiResponse
) {
  if (req.method !== 'GET') {
    return res.status(405).json({ message: 'Method not allowed' });
  }

  const { id } = req.query;
  // DB 조회 로직
  const user = await prisma.user.findUnique({
    where: { id: Number(id) }
  });

  res.status(200).json(user);
}

2. POST 메서드

POST는 새로운 리소스를 생성하는 데 사용됩니다.

React에서의 사용 예시:

// 새 사용자 등록 폼
const RegisterForm = () => {
  const handleSubmit = async (event) => {
    event.preventDefault();
    const formData = new FormData(event.target);

    try {
      const response = await fetch('/api/users', {
        method: 'POST',
        headers: {
          'Content-Type': 'application/json',
        },
        body: JSON.stringify({
          name: formData.get('name'),
          email: formData.get('email'),
        }),
      });

      if (!response.ok) throw new Error('Registration failed');
      
      const data = await response.json();
      // 성공 처리
    } catch (error) {
      // 에러 처리
    }
  };

  return (
    <form onSubmit={handleSubmit}>
      <input name="name" type="text" required />
      <input name="email" type="email" required />
      <button type="submit">등록</button>
    </form>
  );
};

3. PUT과 PATCH 메서드

// pages/api/users/[id].ts
export default async function handler(
  req: NextApiRequest,
  res: NextApiResponse
) {
  const { id } = req.query;

  if (req.method === 'PUT') {
    // 전체 데이터 교체
    const userData = req.body;
    await prisma.user.update({
      where: { id: Number(id) },
      data: userData,
    });
    return res.status(200).json({ message: 'User updated' });
  }

  if (req.method === 'PATCH') {
    // 부분 데이터 수정
    const updates = req.body;
    await prisma.user.update({
      where: { id: Number(id) },
      data: updates,
    });
    return res.status(200).json({ message: 'User partially updated' });
  }
}

4. DELETE 메서드

React에서의 사용 예시:

const DeleteUserButton = ({ userId }) => {
  const handleDelete = async () => {
    try {
      const response = await fetch(`/api/users/${userId}`, {
        method: 'DELETE',
      });

      if (!response.ok) throw new Error('Delete failed');
      // 성공 처리
    } catch (error) {
      // 에러 처리
    }
  };

  return (
    <button onClick={handleDelete}>
      사용자 삭제
    </button>
  );
};

React와 Next.js에서는 이러한 메서드들을 사용하여 서버와 효과적으로 통신하고, RESTful API를 구현할 수 있습니다.

자주 사용되지 않지만 알아두면 유용한 HTTP 메서드들

1. HEAD 메서드

HEAD 메서드는 GET과 동일한 요청을 보내지만, 응답으로 헤더만 받고 본문은 받지 않습니다.

주요 사용 사례:

• 큰 파일을 다운로드하기 전에 파일 크기 확인
• 리소스가 변경되었는지 검사(Last-Modified 확인)
• 리소스 존재 여부 확인

// Next.js에서 HEAD 메서드 처리 예시
export default async function handler(req: NextApiRequest, res: NextApiResponse) {
  if (req.method === 'HEAD') {
    // 파일 정보만 확인
    const fileStats = await getFileStats('large-file.pdf');
    
    res.setHeader('Content-Length', fileStats.size);
    res.setHeader('Last-Modified', fileStats.mtime.toUTCString());
    return res.status(200).end();
  }
}

// React에서 HEAD 요청 예시
const checkFileDetails = async () => {
  try {
    const response = await fetch('/api/files/large-file.pdf', {
      method: 'HEAD'
    });
    
    const fileSize = response.headers.get('Content-Length');
    const lastModified = response.headers.get('Last-Modified');
    
    console.log(`File size: ${fileSize} bytes`);
    console.log(`Last modified: ${lastModified}`);
  } catch (error) {
    console.error('Error checking file:', error);
  }
};

1. OPTIONS 메서드와 CORS

OPTIONS는 서버가 지원하는 메서드와 기능을 확인하는 데 사용됩니다. 

주로 CORS의 Preflight 요청에서 핵심적인 역할을 합니다.

주요 사용 사례:

• CORS 사전 검사
• 서버 지원 기능 확인
• API 엔드포인트 메타데이터 조회

Next.js에서 CORS 설정 예시:

// pages/api/users/[id].ts
import Cors from 'cors';

// CORS 미들웨어 초기화
const cors = Cors({
  methods: ['GET', 'POST', 'PUT', 'PATCH', 'DELETE', 'OPTIONS'],
  origin: ['https://allowed-origin.com'],
  credentials: true,
});

// 미들웨어 실행 함수
const runMiddleware = (req: NextApiRequest, res: NextApiResponse, fn: Function) => {
  return new Promise((resolve, reject) => {
    fn(req, res, (result: any) => {
      if (result instanceof Error) {
        return reject(result);
      }
      return resolve(result);
    });
  });
};

export default async function handler(
  req: NextApiRequest,
  res: NextApiResponse
) {
  // CORS 미들웨어 실행
  await runMiddleware(req, res, cors);

  // OPTIONS 요청 처리
  if (req.method === 'OPTIONS') {
    return res.status(200).end();
  }

  // 다른 메서드 처리...
}

브라우저의 Preflight 요청 예시:

// React에서 CORS 관련 OPTIONS 요청이 발생하는 상황
const fetchWithCustomHeaders = async () => {
  try {
    const response = await fetch('https://api.example.com/data', {
      method: 'GET',
      headers: {
        'Custom-Header': 'value',  // 커스텀 헤더 추가시 자동으로 preflight 요청 발생
      },
      credentials: 'include',  // 인증 정보 포함
    });
    
    const data = await response.json();
    return data;
  } catch (error) {
    console.error('Error:', error);
  }
};

CORS와 Preflight 요청의 이해

브라우저는 특정 조건에서 실제 요청 전에 OPTIONS 메서드를 사용한 Preflight 요청을 자동으로 보냅니다.

Preflight 요청이 발생하는 경우:

1. 커스텀 헤더를 포함할 때 (예: Authorization)
2. 단순하지 않은 Content-Type을 사용할 때
3. 단순하지 않은 메서드를 사용할 때 (GET, HEAD, POST 외)

// Preflight 요청 예시 (브라우저 개발자 도구에서 보이는 형태)
OPTIONS /api/data HTTP/1.1
Host: api.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: authorization, content-type
Origin: https://your-app.com

// 서버 응답 예시
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://your-app.com
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: authorization, content-type
Access-Control-Max-Age: 86400

3. CONNECT 메서드

CONNECT는 프록시 서버를 통해 SSL/TLS 터널을 구성할 때 사용됩니다.

주요 사용 사례:

• HTTPS 프록시 연결 설정
• 웹소켓 연결 업그레이드
• 프록시 서버를 통한 암호화된 통신

// Node.js에서 CONNECT 요청 처리 예시
const net = require('net');
const server = require('http').createServer();

server.on('connect', (req, clientSocket, head) => {
  // 프록시 연결 설정
  const { port, hostname } = new URL(`http://${req.url}`);
  const serverSocket = net.connect(port || 80, hostname, () => {
    clientSocket.write('HTTP/1.1 200 Connection Established\r\n\r\n');
    serverSocket.write(head);
    serverSocket.pipe(clientSocket);
    clientSocket.pipe(serverSocket);
  });
});

4. TRACE 메서드

TRACE는 요청 메시지가 프록시나 방화벽을 통과하면서 어떻게 변경되는지 추적하는 데 사용됩니다.

주요 사용 사례:

• 디버깅
• 요청 메시지 변조 감지
• 프록시 체인 추적

// Next.js에서 TRACE 메서드 처리 예시
export default function handler(req: NextApiRequest, res: NextApiResponse) {
  if (req.method === 'TRACE') {
    // 요청 헤더와 경로 정보를 그대로 반환
    const responseBody = {
      method: req.method,
      url: req.url,
      headers: req.headers,
      path: req.url
    };
    
    res.setHeader('Content-Type', 'message/http');
    return res.status(200).json(responseBody);
  }
}

// 보안상의 이유로 대부분의 서버는 TRACE 메서드를 비활성화합니다

보안 고려사항

// Next.js에서 메서드 제한 구현 예시
export default function handler(req: NextApiRequest, res: NextApiResponse) {
  // 허용되지 않는 메서드 차단
  const allowedMethods = ['GET', 'POST', 'OPTIONS'];
  if (!allowedMethods.includes(req.method)) {
    return res.status(405).json({ 
      error: 'Method Not Allowed',
      allowedMethods 
    });
  }

  // TRACE 메서드는 명시적으로 차단
  if (req.method === 'TRACE') {
    return res.status(403).json({ 
      error: 'TRACE method is disabled for security reasons' 
    });
  }
}

이러한 HTTP 메서드들은 특수한 상황에서 유용할 수 있지만, 보안을 고려해 신중하게 사용해야 합니다.

특히 TRACE 메서드는 보안상의 이유로 대부분의 프로덕션 환경에서 비활성화되어 있습니다.

멱등성

HTTP 메서드에 대한 마지막 설명으로 중요한 개념인 멱등성에 대해 간단히 설명드리겠습니다.

멱등성(Idempotency)이란 동일한 요청을 한 번 보내는 것과 여러 번 보내는 것이 서버의 상태에 동일한 영향을 미치는 것을 의미합니다.

주요 HTTP 메서드의 멱등성은 다음과 같습니다:

멱등성을 가진 메서드:

1. GET: 리소스를 조회만 하므로 멱등
2. HEAD: GET과 동일하게 리소스 정보만 조회하므로 멱등
3. PUT: 리소스를 대체(덮어쓰기)하므로 멱등
4. DELETE: 리소스를 삭제하므로 멱등 (이미 삭제된 리소스를 다시 삭제해도 상태는 동일)
5. OPTIONS: 서버 리소스가 지원하는 메서드 정보를 조회하므로 멱등
6. TRACE: 요청 메시지를 그대로 반환하므로 멱등

멱등성이 없는 메서드:

1. POST: 새로운 리소스 생성 또는 데이터 처리를 요청하므로 멱등하지 않음
   • 예: 같은 주문을 여러 번 POST하면 여러 개의 주문이 생성됨
2. PATCH: 리소스의 부분 수정이므로 멱등하지 않을 수 있음
   • 예: 숫자를 1씩 증가시키는 PATCH 요청은 멱등하지 않음

멱등성이 중요한 이유:

1. 네트워크 오류 시 재시도 전략 수립 가능
2. 서버의 안정성과 예측 가능성 보장
3. 캐싱 전략 수립에 도움

API를 설계할 때는 각 메서드의 멱등성 특성을 고려하여 적절한 메서드를 선택하는 것이 중요합니다.

번외: REST API vs GraphQL 

HTTP 메서드를 공부하면서 빼놓을 수 없는 이야기가 하나 있는데요, 바로 GraphQL입니다. REST API만 사용하다가 처음 GraphQL을 접했을 때 상당히 신기했습니다. "아니, HTTP 메서드도 없이 어떻게 API를 만든다는 거지?" 하면서요. 😅

GraphQL이란?

GraphQL은 Facebook에서 개발한 API를 위한 쿼리 언어입니다. REST API와는 달리, GraphQL은 단일 엔드포인트에서 모든 데이터 요청을 처리하고, 클라이언트가 필요한 데이터를 정확히 지정할 수 있습니다.

REST API vs GraphQL 비교

// REST API 방식
// GET /api/users/1
// GET /api/users/1/posts
// GET /api/users/1/followers

// GraphQL 방식
const query = `
  query {
    user(id: 1) {
      name
      email
      posts {
        title
        content
      }
      followers {
        name
      }
    }
  }
`;

Next.js에서 GraphQL 사용 예시

// pages/api/graphql.ts
import { ApolloServer } from 'apollo-server-micro';
import { typeDefs } from './schema';
import { resolvers } from './resolvers';

const apolloServer = new ApolloServer({
  typeDefs,
  resolvers,
});

export const config = {
  api: {
    bodyParser: false,
  },
};

export default async function handler(req, res) {
  await apolloServer.start();
  await apolloServer.createHandler({
    path: '/api/graphql',
  })(req, res);
}

React에서 GraphQL 사용 예시 (Apollo Client)

import { useQuery } from '@apollo/client';

const GET_USER = gql`
  query GetUser($id: ID!) {
    user(id: $id) {
      name
      email
      posts {
        title
      }
    }
  }
`;

function UserProfile({ userId }) {
  const { loading, error, data } = useQuery(GET_USER, {
    variables: { id: userId },
  });

  if (loading) return 'Loading...';
  if (error) return `Error! ${error.message}`;

  return (
    <div>
      <h1>{data.user.name}</h1>
      <p>{data.user.email}</p>
      <h2>Posts</h2>
      <ul>
        {data.user.posts.map(post => (
          <li key={post.id}>{post.title}</li>
        ))}
      </ul>
    </div>
  );
}

REST API vs GraphQL: 각각의 장단점

// GraphQL과 REST API를 함께 사용하는 하이브리드 접근
// pages/api/hybrid/[...path].ts
export default async function handler(req, res) {
  // 파일 업로드는 REST API로 처리
  if (req.url.startsWith('/api/upload')) {
    return handleFileUpload(req, res);
  }

  // 복잡한 데이터 쿼리는 GraphQL로 처리
  if (req.url.startsWith('/api/graphql')) {
    return handleGraphQLRequest(req, res);
  }

  // 단순한 CRUD는 REST API로 처리
  return handleRESTRequest(req, res);
}

언제 무엇을 선택할까?

• REST API가 좋은 경우:
  • 단순한 CRUD 작업이 주를 이루는 경우
  • 캐싱이 중요한 경우
  • 파일 업로드/다운로드가 많은 경우
  • 팀이 REST에 더 익숙한 경우
• GraphQL이 좋은 경우:
  • 복잡한 데이터 관계를 다루는 경우
  • 모바일 앱에서 데이터 사용량 최적화가 필요한 경우
  • 실시간 업데이트가 필요한 경우
  • API 변경이 자주 발생하는 경우

실제로 기업들에서 두 방식을 함께 사용하는 하이브리드 접근을 택하고 있는걸로 알고 있습니다. GitHub이 대표적인 예시인데요, 요구 사항에 가장 잘 부합하고 가장 편안하게 사용할 수 있는 API를 사용하라 권고하고 있고, 파일 업로드 같은 기능은 REST API로, 복잡한 데이터 쿼리는 GraphQL로 처리하고 있습니다.

오늘은 제가 Context API에서 Zustand로 상태관리 도구를 전환하게 된 과정과 2024년 현재 리액트 상태관리 라이브러리들의 현황에 대해 이야기해보려 합니다.

1. Context API의 한계와 상태관리 라이브러리의 필요성

Context API로 시작한 이유

처음 알리니 프로젝트를 시작할 때는 Context API만으로 충분하다고 생각했습니다. 사용자 인증, 테마, 언어 설정 등 전역적으로 공유되어야 하는 상태들을 관리하는 데 Context API 만으로 충분했습니다.

// 초기 Context API 사용 예시
const PetContext = React.createContext<PetContextType | undefined>(undefined);

export const PetProvider: React.FC<PropsWithChildren> = ({ children }) => {
  const [petData, setPetData] = useState<PetData>({
    allergies: [],
    symptoms: [],
    foodLog: []
  });

  return (
    <PetContext.Provider value={{ petData, setPetData }}>
      {children}
    </PetContext.Provider>
  );
};

한계점 발견

하지만 프로젝트가 커지면서 여러 가지 한계점이 드러나기 시작했습니다:

• 불필요한 리렌더링: Context의 값이 변경될 때마다 해당 Context를 구독하는 모든 컴포넌트가 리렌더링되었습니다. 
• 코드 복잡도 증가: 여러 개의 Context를 중첩해서 사용하다 보니 Provider Hell이 발생했습니다.
• 상태 업데이트 로직 관리의 어려움: 비동기 작업과 복잡한 상태 업데이트 로직을 처리하는 데 한계가 있었습니다.

2. 주요 상태관리 라이브러리 비교 분석

Redux

Redux는 오랫동안 리액트 생태계의 표준과 같은 상태관리 라이브러리 입니다.

Redux의 핵심 개념

• Action: 상태 변경을 위한 이벤트를 설명하는 객체
• Reducer: Action을 받아 상태를 변경하는 순수 함수
• Store: 애플리케이션의 전체 상태를 보관하는 객체

Redux 미들웨어 생태계

• Redux Thunk: 비동기 작업을 처리하기 위한 가장 기본적인 미들웨어
• Redux Saga: 복잡한 비동기 흐름을 제어하기 위한 미들웨어
  • Generator 함수를 사용한 선언적 비동기 처리
  • 복잡한 시나리오(API 요청 취소, 재시도 등) 처리 가능
• Redux Toolkit: 보일러플레이트 코드를 줄이기 위한 공식 도구

그러나 Redux는 다음과 같은 단점이 있습니다:

• 많은 보일러플레이트 코드
• 학습 곡선이 가파름
• 작은 상태 변화에도 많은 코드 필요

Recoil

Facebook에서 만든 상태관리 라이브러리입니다.

장점

• React와의 높은 호환성
• 간단한 API (atom, selector)
• 비동기 데이터 처리가 쉬움

단점

• 아톰으로 관리되는 전역 상태를 어떤 컴포넌트라도 바로 아톰을 구독해서 업데이트를 받기에, 의존성이 여러 방향으로 엮이면서 예측하기 힘들어집니다.

Zustand

가볍고 직관적인 API를 제공하는 현대적인 상태관리 라이브러리입니다.

주요 특징

• 최소한의 보일러플레이트
• TypeScript 지원이 훌륭함
• Redux DevTools 지원
• 미들웨어 시스템 (persist, devtools 등)

예시 코드:

import create from 'zustand'

interface PetStore {
  symptoms: Symptom[]
  addSymptom: (symptom: Symptom) => void
  foodLogs: FoodLog[]
  addFoodLog: (log: FoodLog) => void
}

const usePetStore = create<PetStore>((set) => ({
  symptoms: [],
  addSymptom: (symptom) => set((state) => ({
    symptoms: [...state.symptoms, symptom]
  })),
  foodLogs: [],
  addFoodLog: (log) => set((state) => ({
    foodLogs: [...state.foodLogs, log]
  }))
}))

3. 실제 프로젝트에서의 선택: Zustand

알리니 프로젝트에서의 요구사항

1. 실시간 데이터 업데이트
2. 복잡한 상태 관리 (알레르기 증상, 음식 기록, 분석 데이터)
3. 성능 최적화
4. TypeScript 지원

Zustand 선택 이유

1. 간단한 설정과 사용법: 별도의 Provider 설정이 필요 없고, 직관적인 API를 제공합니다.
2. 성능 최적화: 필요한 상태만 구독하여 불필요한 리렌더링을 방지합니다.
3. TypeScript 지원: 타입 추론이 잘 동작하여 개발 생산성이 향상되었습니다.
4. 미들웨어 지원: persist 미들웨어를 통해 로컬 스토리지 연동이 쉬웠습니다.

Context API와의 조화

Context API와 Zustand를 함께 사용할 수 있습니다. 저는 다음과 같이 역할을 구분했습니다:

• Context API: 테마, 인증 등 애플리케이션의 전반적인 설정과 관련된 상태 관리 (단어 그대로 특정 맥락을 씌울때 사용했습니다.)
• Zustand: 비즈니스 로직과 관련된 복잡한 상태 관리

4. 결론

2024년 현재, 저는 다음과 같은 기준으로 상태관리 라이브러리를 선택했습니다:

1. 작은 프로젝트: Context API만으로도 충분
2. 중간 규모 프로젝트: Zustand
3. 대규모 프로젝트: Redux Toolkit 또는 Zustand

알리니와 같이 실시간 데이터 처리와 복잡한 상태 관리가 필요한 프로젝트에는 Zustand가 특히 적합했습니다. 코드가 간결하면서도 강력한 기능을 제공하며, 특히 TypeScript와의 호환성이 뛰어나 개발 경험이 매우 좋았습니다.

프론트엔드 개발을 하다 보면 크로스브라우징 이슈는 피할 수 없습니다.

::-webkit-input-placeholder와 같은 브라우저별 프리픽스(-webkit-, -moz-, -ms- 등)를 일일이 추가하는 건 굉장히 번거로운 작업이예요.

사실 현업에서는 개발자가 직접 이러한 프리픽스를 추가하는 것이 매우 곤란한 일입니다.

(저도 관련된 대화를 나누다 알게됐어요!)

이러한 문제를 해결하기 위해 번들러를 통해 자동으로 프리픽스를 추가해주는 방법인 Autoprefixer를 사용할 수 있습니다.

PostCSS를 기본적으로 사용하는 라이브러리라면, 혹은 CSS로 변환한 후 postcss-loader가 처리하게 한다면 개발자가 각 브라우저 환경에 맞게 스타일을 따로 작성하지 않아도 Autoprefixer가 웹킷 프리픽스와 같은 것을 자동으로 붙여줍니다.

이번 포스트에서는 PostCSS와 Autoprefixer를 활용해 해당 ISSUE를 해결하는 방법을 실제 프로젝트 경험을 바탕으로 상세히 알아보겠습니다!

PostCSS와 Autoprefixer란?

PostCSS

• JavaScript 플러그인을 사용해 CSS를 변환하는 도구
• "Post-processor"라고도 불리는 이유는 CSS를 작성한 후에 처리하기 때문
• CSS 구문 분석에 최적화된 파서를 사용해 높은 성능을 보임
• CSS 전처리기(Sass)나 후처리기로 사용 가능 (이 부분은 제가 헷갈렸던 부분이라 아래 추가설명을 넣었어요!)
  1. CSS 전처리기(SASS):
     CSS 기능을 확장한 언어 입니다. 변수, 중첩 규칙, 믹스인 등을 지원하고, PostCSS는 Sass로 작성한 코드를 처리할 수 있지만, PostCSS 자체는 Sass 문법을 사용하진 않아요.
  2. CSS 후처리기:
     PostCSS는 CSS코드가 작성된 후에 추가적인 변환 작업을 수행하는 도구로 사용될 수 있습니다.
     예를 들어, 제가 지금 작성하는 Autoprefixer 같은 플러그인을 사용해서 자동으로 브라우저 프리픽스를 추가할 수 있는 것처럼요!
• 200개 이상의 플러그인으로 다양한 기능 제공 (생태계가 큽니다!)
• 모듈화된 구조로 필요한 기능만 플러그인으로 선택적 추가 가능

Autoprefixer

• PostCSS의 대표적인 플러그인
• 브라우저 프리픽스를 자동으로 추가해주는 도구
• Browserslist 설정을 통해 지원 브라우저 범위 지정 가능

Create React App과 Vite의 기본 지원

해당 부분은 Webpack을 직접 설정하지 않을 땐 어떻게 되는 건지, 기본 설정이 되어 있는지 등이 궁금해 찾아보게 됐습니다.

Create React App (CRA)

• PostCSS와 Autoprefixer가 기본으로 설정되어 있음
• 별도 설정 없이 바로 사용 가능
• browserslist 설정도 기본 제공

CRA의 package.json을 보시면 아래와 같은 코드를 확인하실 수 있습니다.

"browserslist": {
  "production": [
    ">0.2%",
    "not dead",
    "not op_mini all"
  ],
  "development": [
    "last 1 chrome version",
    "last 1 firefox version",
    "last 1 safari version"
  ]
}

Vite

• PostCSS는 기본 지원
• Autoprefixer는 별도 설치 필요

yarn add -D autoprefixer

// vite.config.js
import autoprefixer from 'autoprefixer'

export default {
  css: {
    postcss: {
      plugins: [
        autoprefixer()
      ]
    }
  }
}

현재 프로젝트에 Custom Webpack 설정하기

커스텀 Webpack 설정에서는 수동으로 PostCSS와 Autoprefixer를 설정해야 합니다.

필요한 패키지 설치

yarn add -D postcss postcss-loader autoprefixer

웹팩 설정 예시

module.exports = {
  module: {
    rules: [
      {
        test: /\.module\.scss$/,
        use: [
          "style-loader",
          {
            loader: "css-loader",
            options: {
              modules: {
                localIdentName: "[name]__[local]--[hash:base64:5]",
              },
              importLoaders: 2,
            },
          },
          {
            loader: "postcss-loader",
            options: {
              postcssOptions: {
                plugins: [
                  ["autoprefixer"]
                ],
              },
            },
          },
          "sass-loader",
        ],
      },
      {
        test: /\.(scss|css)$/,
        exclude: /\.module\.scss$/,
        use: [
          "style-loader",
          {
            loader: "css-loader",
            options: {
              importLoaders: 2,
            },
          },
          {
            loader: "postcss-loader",
            options: {
              postcssOptions: {
                plugins: [
                  ["autoprefixer"]
                ],
              },
            },
          },
          "sass-loader",
        ],
      },
    ],
  },
  // ... 기타 웹팩 설정
};

실수했던 부분과 해결 방법

package.json에 작성돼야 하는 json 문법을. browserslistrc 파일에 적용해 버렸어요. 공식 문서를 읽다 순간적으로 착각했습니다. 너무 간단하지만 제 기준에서 치명적인 실수란 생각이 들어 기록해두려 합니다!

Browserslist 설정 오류

Error [BrowserslistError]: Unknown browser query `{`. Maybe you are using old Browserslist or made typo in query.

.browserslistrc 파일 사용 (권장)

저는 최종적으로 아래의 코드로 수정했습니다!

# 프로덕션 환경
[production]
>0.2% # 전 세계 사용률 0.2% 이상인 브라우저
not dead # 공식 지원이 중단되지 않은 브라우저
not op_mini all # Opera Mini 브라우저 제외

# 개발 환경
[development]
last 1 chrome version # 최신 크롬 버전
last 1 firefox version # 최신 파이어폭스 버전
last 1 safari version # 최신 사파리 버전

해결방법 2: package.json에 설정

{
  "browserslist": {
    "production": [
      ">0.2%",
      "not dead",
      "not op_mini all"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
  }
}

Browserslist 설정 가이드

주요 쿼리 설명

• >0.2%: 전 세계 사용률 0.2% 이상인 브라우저
• not dead: 공식 지원이 중단되지 않은 브라우저
• not op_mini all: Opera Mini 브라우저 제외
• last 1 chrome version: 최신 크롬 버전
• last 2 versions: 각 브라우저의 최신 2개 버전
• > 1%: 전 세계 점유율 1% 이상
• IE 11: IE 11 지원

설정 테스트

• browserslist.dev에서 설정을 테스트할 수 있음
• 어떤 브라우저가 포함되는지 실시간으로 확인 가능

실제 동작 예시

변환 전 CSS

.example {
  display: flex;
  user-select: none;
}

변환 후 CSS

.example {
  display: -webkit-box;
  display: -ms-flexbox;
  display: flex;
  -webkit-user-select: none;
     -moz-user-select: none;
      -ms-user-select: none;
          user-select: none;
}

주의사항과 팁!

• 로더 순서: PostCSS 로더는 Sass 로더 이후, CSS 로더 이전에 위치해야 합니다.  
  1. sass-loader (SCSS -> CSS 변환)
  2. postcss-loader (자동 프리픽스 추가)
  3. css-loader (CSS -> JS 변환)
  4. style-loader (JS -> style 태그 삽입)
• 성능 최적화: development 환경에서는 source map을 활성화하고, production에서는 비활성화하는 것이 좋습니다.
• 브라우저 지원 범위: browserslist 설정을 통해 지원할 브라우저 범위를 적절히 조절해야 합니다.

주의사항과 팁에서의 Development 환경에서 source map 활성화하는 이유 & Production 환경에서 비활성화 하는 이유에 대해서만 좀 더 자세히 알아볼게요!

Development 환경에서 source map 활성화하는 이유:

1. 디버깅 용이성
   • 개발 중에는 원본 소스 코드와 변환된 코드를 매핑하여 쉽게 디버깅할 수 있습니다
   • 브라우저의 개발자 도구에서 실제 작성한 CSS 파일의 위치와 라인을 정확히 확인 가능
   • PostCSS로 변환된 코드가 아닌 원본 코드를 직접 확인하며 수정 가능
2. 개발 효율성
   • 코드 수정 시 즉각적인 피드백 확인 가능
   • CSS 문제 발생 시 정확한 위치 추적이 가능하여 수정 시간 단축
   • 복잡한 스타일 구조에서도 원본 코드 위치를 쉽게 파악!

Production 환경에서 source map 비활성화하는 이유:

1. 파일 크기 최적화
   • source map 파일은 원본 코드와 변환된 코드의 매핑 정보를 포함하므로 상당한 크기를 차지
   • 프로덕션 환경에서는 불필요한 데이터 전송을 줄여 로딩 속도 향상
   • 일반적으로 source map 파일은 원본 파일 크기의 절반 이상을 차지할 수 있음
2. 보안 강화
   • source map이 노출되면 원본 코드 구조가 드러날 수 있음
   • 악의적를 가진 사용자가 코드 구조를 분석하는 것을 방지
   • 기업의 proprietary 코드 보호!!
3. 성능 최적화
   • 브라우저가 source map을 처리하는 추가적인 작업 제거
   • 초기 페이지 로딩 시간 단축
   • 서버 대역폭 사용량 감소

실제 설정 예시! (프로젝트 코드보다 간략화)

// webpack.config.js
module.exports = {
  mode: process.env.NODE_ENV,
  module: {
    rules: [{
      test: /\.css$/,
      use: [
        'style-loader',
        {
          loader: 'css-loader',
          options: {
            sourceMap: process.env.NODE_ENV === 'development'
          }
        },
        {
          loader: 'postcss-loader',
          options: {
            sourceMap: process.env.NODE_ENV === 'development'
          }
        }
      ]
    }]
  }
};

결론

PostCSS와 Autoprefixer를 사용하면 크로스브라우징을 위한 수동 작업을 자동화할 수 있습니다.

CRA나 Create Vite같은 경우 이미 이러한 기능을 기본으로 제공하고 있으며, 커스텀 웹팩 설정에서도 간단한 설정만으로 동일한 기능을 사용할 수 있습니다.

특히 Browserslist 설정을 통해 프로젝트의 브라우저 지원 범위를 명확히 하고, 필요한 프리픽스만 추가함으로써 최적화된 CSS를 생성할 수 있겠죠?!

.browserslistrc 파일을 사용하면 설정 관리가 더욱 용이해지며, 다른 도구들과도 설정을 공유할 수 있습니다.

여기서 "다른 도구들"은 주로 다음과 같은 CSS 또는 JavaScript 도구들을 의미합니다!

1. Autoprefixer: CSS에 필요한 브라우저 프리픽스를 자동으로 추가해주는 도구로, Browserslist 설정을 통해 어떤 프리픽스를 추가할지 결정 (지금까지 설명드린 내용이죠?!)
2. Babel: 최신 JavaScript 코드를 구형 브라우저에서도 작동할 수 있게 변환해주는 도구로, Browserslist 설정을 통해 지원할 브라우저 정의 가능
3. ESLint: JavaScript 코드의 품질을 관리하는 도구로, Browserslist와 함께 사용해 특정 브라우저 환경에 맞는 코드 스타일 적용 가능
4. Stylelint: CSS 스타일을 검사하는 도구로, Browserslist 설정을 참고하여 브라우저 호환성 관련 규칙 적용 가능

즉, .browserslistrc 파일을 사용하면 이러한 다양한 도구들이 동일한 브라우저 지원 범위를 공유하게 되어, 개발 및 유지보수 과정에서 일관성을 유지할 수 있습니다!