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 키, 인증서, 패스워드 등 민감한 정보예요.

마치며 

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

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

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

감사합니다!

오늘 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로 처리하고 있습니다.

React.js와 Next.js 프로젝트를 진행하던 중, 처음 개발 공부를 시작할 때 고민했던 라이브러리와 프레임워크에 대해 다시 한번 정리해보기로 했습니다.

과거에는 이들을 완성된 로봇과 조립형 로봇에 비유하곤 했지만, 지금은 다르게 접근해보려 합니다.

그렇다면 공식 문서부터 확인해 보겠습니다!

공식 문서의 메인 페이지에서조차 "사용자 인터페이스를 만들기 위한 JavaScript 라이브러리" 라는 문구로 우리를 환영하고 있습니다.

그렇다면 수많은 사람들은 도대체 무엇 때문에 혼동하게 된 걸까요?

라이브러리와 프레임워크에 대해 간략히 설명드린 후 "React.js는 라이브러리일까?"  목차에서 다시 한번 정리해 보겠습니다. 

라이브러리와 프레임워크란?

라이브러리

검색 시 쉽게 아래의 내용들을 확인해 보실 수 있습니다.

"특정한 기능을 쉽게 사용할 수 있도록 미리 작성된 코드의 집합"

"개발자가 필요에 따라 라이브러리를 호출하여 사용하는 방식으로, 도구처럼 필요한 부분만 선택적으로 사용"

정리해 보자면, 무언가를 만들 때 유용한 도구 같은 친구네요.

마치 미용실에서 쓰는 도구나 공사 현장에서 쓰는 도구처럼, 특정한 문제를 해결해 주는 기능을 제공해 줍니다.

드라이기로 머리를 말릴 필요는 없지만, 필요하면 사용할 수 있는 것처럼 이런 도구들은 필요에 맞게 골라 쓸 수 있습니다.

프레임워크

라이브러리보다 더 큰 단위의 솔루션을 제공합니다.

라이브러리에서의 예시를 가져와 보겠습니다.

미용실에서 머리를 말리는 방법을 다 정해주고, 그 안에서 정해진 방법을 이용해 머리를 말리는(필요한 로직을 구현하는) 방식입니다.

그래서 Next.js는 React.js를 베이스로 해 웹을 만드는데 필요한 전체적인 해결책을 제공해 줍니다!

React.js와 Next.js의 관계

• React.js는 UI를 선언적으로 만들기 위한 라이브러리로, 필요한 기능을 선택적으로 사용합니다.
• Next.js는 웹 어플리케이션 개발에 필요한 전체적인 솔루션을 제공하며, React를 기반으로 다양한 기능을 포함한 프레임워크입니다.

지금까지 라이브러리, 프레임워크와 React,js, Next.js에 대해 간략히 설명드렸습니다.

이제 본론으로 들어가 보도록 하겠습니다!

React.js는 라이브러리일까?

저는 프레임워크와 라이브러리에 대한 학습에서 "프레임워크 없는 프론트엔드 개발 | 프란세스코 스트라츨로" 교재의,

"프레임워크는 코드를 호출하고 코드는 라이브러리를 호출한다"라는 문구가 가장 와닿았습니다.

교재를 학습하며 해당 문구가 라이브러리와 프레임워크의 차이에 대해 정말 잘 설명하고 있다는 생각이 들었어요.

발췌한 문장을 기반으로 다시 정리하자면,

• 프레임워크는 코드를 호출하여 실행 흐름을 제어합니다.
• 라이브러리는 개발자가 필요한 기능을 호출하여 사용하는 도구입니다.

발췌한 문장을 기반으로 글을 써 내려갈 예정이에요.

참고하여 읽으신다면 좀 더 도움이 되실 거라 생각합니다!

이는 React가 UI 컴포넌트를 만들고 관리하는 데 중점을 두기 때문입니다.

그러나 저를 포함한 많은 개발자들은 React를 프레임워크처럼 사용하고 있습니다.
이유가 뭘까요?

이는 리액트 생태계와 커뮤니티의 강력한 영향력 때문입니다.
React는 UI를 렌더링하는 라이브러리로 시작했지만, 생태계의 발전과 함께 많은 개발자들이 React를 이용해 프레임워크처럼 프로젝트를 구조화하고 있습니다. 

이제 지금까지의 내용을 토대로 실제 개발과정을 예시로 들어 다시 한번 정리해 보도록 할게요!

어떻게 사용해야 될까?

프로젝트를 진행할 때, 프레임워크와 라이브러리의 사용 방식과 목적을 명확히 이해하는 것이 중요합니다.

React를 프레임워크처럼 사용할 때와 라이브러리처럼 사용할 때의 차이를 이해하면 더 나은 선택을 할 수 있습니다.

React를 프레임워크처럼 사용할 때

커뮤니티와 생태계의 영향력

• 리액트는 초기 설정과 구조가 이미 잡혀있는 상태에서 시작하기 때문에 많은 개발자들은 이를 프레임워크처럼 사용하게 됩니다. 예를 들어, npm create-react-app으로 프로젝트를 시작하면 정해진 구조 안에서 개발을 진행하게 됩니다.

컴포넌트 내의 다양한 기능

• 리액트를 사용할 때 컴포넌트에 이벤트 핸들러, 비즈니스 로직, API 호출 등을 모두 포함시킵니다. 이러한 방식은 리액트가 코드를 호출하는 형태로 동작하게 하여 프레임워크처럼 느껴지게 만듭니다.

즉, React 컴포넌트가 모든 실행 흐름을 제어하며, 강한 결합이 발생할 수 있습니다.

장점:

• 빠른 개발 속도: 비즈니스 로직을 리액트 컴포넌트 내부에 통합하여 빠르게 개발할 수 있습니다.
• 코드 구조가 명확하고 일관성이 있습니다.

단점:

• 의존성 증가: 비즈니스 로직이 리액트 컴포넌트에 강하게 결합되어 있어, 리액트를 다른 라이브러리로 대체하기 어렵습니다.
• 이는 향후 마이그레이션 시 큰 비용을 초래할 수 있습니다.

React를 라이브러리처럼 사용할 때

비즈니스 로직과 UI 렌더링을 분리하고, 이 둘을 연결하는 인터페이스를 두는 방법

상태 관리와 UI 업데이트

• 리액트에서 setState를 호출하면 UI가 리렌더링 됩니다. 이 점을 활용하여, setState를 UI를 업데이트하는 요소로 간주하고, UI 업데이트가 필요한 시점에만 setState를 호출하게 합니다.
• 이런식으로 비즈니스 로직은 리액트와 독립적으로 동작하도록 합니다. 이렇게 하면 리액트는 오로지 UI를 렌더링하는 역할만 하게 되며 상태 관리를 최소화할 수 있습니다.

비즈니스 로직 분리

• 비즈니스 로직은 퓨어한 자바스크립트로 작성하여 리액트와 독립적으로 동작하도록 합니다.
• 이를 통해 비즈니스 로직은 UI와 별개로 작동하게 됩니다.

UI 렌더링에만 집중

• 리액트를 순수 UI 렌더링 라이브러리로 사용하려면 비즈니스 로직을 리액트 외부의 순수 자바스크립트 클래스 등의 코드로 분리합니다. 리액트는 오직 데이터를 화면에 렌더링하는 역할만 수행합니다.
• 비즈니스 로직을 담당하는 클래스 등의 자바스크립트 코드로 작성하여, 데이터 처리와 상태 관리를 독립적으로 수행합니다.

인터페이스를 통한 통신

• 비즈니스 로직과 리액트 컴포넌트 간의 데이터 통신(연결)을 담당하는 인터페이스를 설계하여, 상태 변경을 리액트에 전달합니다.
• 이 인터페이스는 비즈니스 로직의 상태 변경을 감지하고, 필요한 시점에 리액트의 setState를 호출하여 UI를 업데이트합니다.

간단한 구현 예시

/**
* 비즈니스 로직 - 순수 자바스크립트 클래스
*/
class BusinessLogic {
  constructor() {
    this.data = null;
    this.listeners = [];
  }

  setData(newData) {
    this.data = newData;
    this.notifyListeners();
  }

  getData() {
    return this.data;
  }

  addListener(listener) {
    this.listeners.push(listener);
  }

  notifyListeners() {
    this.listeners.forEach(listener => listener(this.data));
  }
}

/**
* 리액트 컴포넌트 - UI 렌더링
*/
import React, { useState, useEffect } from 'react';

const TestComp = ({ businessLogic }) => {
  const [data, setData] = useState(businessLogic.getData());

  useEffect(() => {
    const handleDataChange = (newData) => {
      setData(newData);
    };

    businessLogic.addListener(handleDataChange);

    return () => {
      businessLogic.removeListener(handleDataChange);
    };
  }, [businessLogic]);

  return (
    <div>
      <h1>{data}</h1>
    </div>
  );
};

/**
* 비즈니스 로직과 리액트 컴포넌트 사용
*/
const logic = new BusinessLogic();
logic.setData("커피 마시고싶다..");

const App = () => (
  <TestComp businessLogic={logic} />
);

export default App;

장점

• 만약 리액트를 시장에서 더이상 원하지 않게 되거나 새로운 UI 렌더링 라이브러리(예: 스벨트)를 사용하고 싶을 때, 라이브러리처럼 구현했다면 전환이 매우 쉽습니다.
• 비즈니스 로직이 리액트와 독립적이기 때문입니다.

단점

• 실제 사례 드묾: 많은 회사들이 라이브러리처럼 구현하는 방식을 채택하지 않습니다. 이는 개발 비용과 시간이 많이 들기 때문입니다.
• 높은 개발 비용: 비즈니스 로직과 UI를 분리하여 모든 것을 인터페이스로 관리하면 개발 비용이 많이 듭니다. 이렇게 하면 초기 런칭이 어려워질 수 있습니다.

아래에서 좀 더 상세히 저의 생각을 풀어보려 합니다.

위와 중복되는 내용이 있지만 흐름을 위해 그대로 적어보도록 하겠습니다!

기술 부채와 그 관리

저는 기술 부채에 대해 개발 과정에서 단기적인 이익을 위해 장기적인 유지보수 비용을 증가시키는 선택이라고 생각합니다.

그리고 이 기술 부채의 개념은 "React.js의 라이브러리와 프레임워크 방식의 결정"에 도움을 줄 것이라 생각해요!

그래서 지금부터 React를 프레임워크처럼 사용할 때와 라이브러리처럼 사용할 때의 기술 부채를 비교해 보도록 하겠습니다.

프레임워크처럼 사용할 때의 기술 부채

• 강한 결합으로 인해 다른 라이브러리로 전환이 어려워집니다.
• 비즈니스 로직이 React 컴포넌트에 깊이 결합되어 유지보수가 어렵습니다.

라이브러리처럼 사용할 때의 기술 부채

• 초기 개발 비용이 높을 수 있습니다.
• 각 기능이 분리되어 있어 개발 속도가 느려질 수 있습니다.

기술 부채 관리의 중요성

기술 부채를 효과적으로 관리하는 것은 중요합니다.

프로젝트의 요구사항과 일정에 맞게 기술 부채를 잘 조정하면, 장기적으로 더 나은 유지보수와 확장성을 확보할 수 있습니다.

무엇보다 저는 기술 부채가 생겨도 청산만 잘하면 문제가 없다고 생각합니다.

그래서 기술 부채를 잘 내는 것도 저는 중요한 능력이라고 보고있습니다.

개발자가 이쁜 코드만 작성하는 예술가는 아니니까요.

그러니 무언가를 사용할 때 단순하게 정의된 특정 단어나 문장만을 받아들이는 게 아니라 상대적으로 생각하는 습관을 들일 수 있다면 빠른 성장에 유리하지 않을까 생각합니다.

결론

React는 공식적으로 라이브러리이지만, 많은 개발자들이 프레임워크처럼 사용하고 있습니다.

프로젝트의 특성과 요구사항에 따라 React를 어떻게 사용할지 결정하는 것이 중요합니다.

기술 부채를 관리하면서, 프레임워크와 라이브러리의 차이를 이해하고 적절하게 활용하면 성공적인 개발을 이룰 수 있습니다.

상대적으로 사고하고, 상황에 맞는 최선의 선택을 하는 습관을 기르면 더욱 빠르게 성장할 수 있을 것입니다!

여러분들께서 이 글을 읽고 난 후에도, 계속 학습하며 다양한 의견을 접하게 되시겠죠?!

자신들만의 단어로 설명할 수 있게 되고, 개발 방향에 대한 길잡이 역할에 도움이 될 수 있기를 바라며 이만 마치겠습니다.

렌더러 프로세스 이전의 핵심 단계

렌더링 과정을 더 효율적으로 만들 수는 없을까라는 생각에 크리티컬 패스(Critical Path)에 대해 다시 학습하던 중 렌더러 프로세스가 화면을 렌더링 하기 전에 무슨 일이 일어나는지에 대해 궁금증이 생겼습니다.
자연스럽게 Chrome for Developers를 읽어보았고 그 결과, 지금부터 설명하게 될 단계들이 렌더러 프로세스 이전에 어떻게 진행되는지에 대한 내용을 드디어 발견했습니다!

브라우저 주소창에 url을 입력 후 웹사이트가 사용자에게 보이기까지 과정 중에서 사용자에게 사이트가 보이기 직전까지인 렌더러 프로세스에게 데이터가 전달되기까지 5가지의 과정으로 진행이 되며 이 과정들에 대해 작성하였습니다.

저와 같은 궁금증을 가진 다른 분들이 계시지 않을까?
라는 생각이 제가 첫 번째 블로그 포스팅을 하게 된 이유입니다.
제가 읽은 내용을 기반으로 작성된 렌더러 프로세스 이전의 다양한 단계들에 대해 살펴보며, 궁금증이 해소되시길 바라겠습니다!

1단계: 입력 처리 (Handling Inputs)

사용자가 주소 표시줄에 text를 입력하기 시작하면 브라우저 프로세스 안에 있는 UI 스레드가 가장 먼저 유저가 입력한 이 text 값을 통해서 '검색어 또는 URL인가요?'라고 물으며 판단을 합니다.

Chrome에서는 주소 표시줄이 검색 입력란이기도 하므로 UI 스레드가 입력된 text 파싱 하여 Search Query로 판단 후 검색엔진(Search Engine)에게 보내어 검색이 되게 만들지 URL이라고 판단하여 Network Thread에게 전달할지 준비하는 과정입니다.

여기까지는 사용자가 Enter 키를 누르기 전까지의 과정이란 걸 기억해 주세요!

2단계: 내비게이션 시작 (Start Navigation)

1단계에서 사용자가 입력값을 다 입력한 다음 Enter 키를 누르면 2단계가 시작되며 UI 스레드가 네트워크 호출(Network call initiates)을 시작합니다.
이때 네트워크 호출이란 Network thread에게 URL을 전달하는 것을 의미하며 사이트 콘텐츠를 가져오는 과정입니다.

로딩 스피너가 표시되고 네트워크 스레드가 DNS 조회와 같은 적절한 프로토콜을 통과하고 요청에 TLS 연결을 설정합니다.
이 시점에서 네트워크 스레드는 301과 같은 HTTP Status Code인 서버 Redirection 헤더를 수신할 수 있습니다. 이 경우 네트워크 스레드는 UI 스레드에게 Redirect 해야 한다는 통신을 하고 UI 스레드는 다른 URL 요청 즉, 다른 네트워크 호출을 시작합니다.
이때 301 코드가 아니라면 3단계 과정인 응답 읽기(Read Response)가 진행됩니다.

다만 어째서 네트워크 호출 과정을 Network Thread가 직접적으로 하는 것이 아니라 UI Tread를 거쳐 이루어질까요? 그 이유는 로딩 스피너(Loading spinner)와 렌더러 프로세스(Renderer process) 탐색에 있습니다.

위 사진의 가장 왼쪽 탭 키에서 파랗게 돌아가고 있는 로딩 스피너가 보이실 겁니다.
이렇게 로딩 스피너를 탭의 왼쪽 모서리에 그리는 것을 관리하는 것이 UI Tread입니다.
네트워크 호출이 시작됐다는 것을 UI Tread가 알 수 없다면 로딩 스피너를 그릴 수 없습니다.
Network Thread가 UI Tread에게 네트워크 호출이 시작됐다는 것을 알리는 것보다 빠르게 로딩 스피너를 표시할 수 있습니다.

렌더러 프로세스 탐색과정은 4단계 렌더러 프로세스 찾기에서 자세히 적어보겠습니다.
UI 스레드가 네트워크 호출을 할 때 이 네트워크 호출은 서버와 통신을 하는 것이기에 수백 밀리초나 걸릴 수 있으므로 이 프로세스의 속도를 높이기 위한 최적화를 한다는 것만 기억해 주세요!

3단계: 응답 읽기 (Read response)

Response body (페이로드)가 네트워크 스레드로 들어오기 시작하면 네트워크 스레드는 Response Body의 데이터 타입을 확인해야 합니다.
확인 후 HTML 파일인 경우 다음 단계를 위해 데이터를 렌더러 프로세스에게 전달할 준비를 하고 ZIP 파일 또는 기타 파일 형식인 경우 다운로드 요청이므로 데이터를 다운로드 관리자에 전달해야 합니다. (a 태그에서의 다운로드는 사용자가 명시적으로 클릭하여 다운로드를 시작하는 수동적인 과정과는 다릅니다.)

확인은 어떤 식으로 이루어질까요?
Response body가 들어오기 시작하면 네트워크 스레드는 필요에 따라 스트림의 처음 몇 바이트를 확인합니다. 가정 먼저 Response body의 Content-Type 헤더에 표시되는 데이터 유형을 확인하지만, 누락되거나 잘못되었을 수 있으므로 여기에서 MIME 타입 스니핑 (MIME Type Sniffing)을 실행합니다.
Sniffing 단어 그대로 냄새를 맡는 것처럼 주로 데이터의 처음 몇 바이트를 분석하여 특정 파일 형식의 특징적인 패턴이나 식별자를 찾습니다. 이를 통해 정확한 MIME 타입을 확인하고, 그에 맞게 데이터를 처리할 수 있습니다.(MIME 타입 스니핑은 주로 보안 및 호환성 측면에서 사용되며, 예상치 못한 형식의 파일이나 악성 코드를 탐지하는 데 도움이 됩니다.)

이 과정에서 SafeBrowsing 검사 과정과 CORB(Cross Origin Read Blocking)과정도 진행됩니다.

먼저 SafeBrowsing은 구글에서 세이프 브라우징이라고 검색 시 제공을 합니다! Domain과 Response Data가 알려진 악성 사이트(Malicious site)와 일치하는 것으로 보이면 네트워크 스레드 알림이 경고 페이지(Warning page)를 표시합니다.

CORB 과정은 Same-Origin Policy와 관련이 있습니다.
Same-Origin Policy는 동일 출처 정책으로, 보안상의 이유로 동일한 출처(Origin)에서만 데이터에 접근이 허용되도록 하는 정책입니다.
즉, Same-Origin 데이터는 안전하고 신뢰할만하다고 말해주는 정책입니다.

CORB는 브라우저에서 페이지의 스크립트가 다른 출처의 리소스를 읽는 것을 방지하는 보안 메커니즘으로 특히, 브라우저는 스크립트가 데이터를 요청할 때, 이 데이터가 해당 스크립트의 출처와 다를 경우 CORB를 적용하여 데이터를 차단합니다.
이를 이용해 Renderer process에게 cross-site data를 전달하지 않게 됩니다.

물론 절대적인 것은 아닙니다.
CORS 설정을 사용하면 특정 도메인 간에 데이터 교환을 허용함으로써, Same-Origin Policy와 CORB에 의한 보안 정책을 유연하게 조절할 수 있습니다.
예시로 Spring Security 등의 보안 설정에서 허용할 도메인을 명시적으로 설정하는 걸 떠올리시면 쉽겠네요!

이 모든 3단계 과정을 통과한 HTML 파일 형식의 데이터를 렌더러 프로세스에게 전달할 준비를 합니다.

4단계: 렌더러 프로세스 찾기 (Find Renderer process)

1단계 - 3단계 까지의 데이터 타입과 안정성에 대한 검사가 완료되고 브라우저가 요청한 사이트로 이동해야 한다고 확신한다면 4단계가 시작되며 Network Thread 가 UI Thread에게 데이터가 준비되었음(Data is ready)을 알립니다.

이때 UI 스레드가 웹페이지 렌더링을 실행할 렌더러 프로세스를 찾는다고 오해하기 딱 좋습니다!
그렇지 않다는 의미겠죠?!
2단계에서 렌더러 프로세스 탐색과정에 대해 자세히 알아보자는 말을 했었습니다.
기억이 안나신다면 다시 올라가 확인해 주세요!
드디어 오래 걸리는 네트워크 호출시간을 활용한 렌더러 프로세스 탐색 최적화 과정에 대해 이야기할 차례입니다.

2단계에서 UI 스레드가 네트워크 스레드로 URL 요청을 보냈기에 어떤 사이트로 이동하는지 이미 알고 있을 겁니다. UI 스레드는 네트워크 요청과 동시에 렌더러 프로세스를 사전에 찾기 시작합니다.
병렬적으로 처리가 가능하기에 많은 시간을 아낄 수 있습니다!
그렇다면 모든 것이 예상대로 진행된 후 네트워크 스레드가 데이터를 수신했을 때 렌더러 프로세스가 이미 대기 상태에 있겠죠?!
이때 크로스 사이트로 Redirection 되는 경우 이 프로세스에서 찾는 렌더러 프로세스는 사용되지 않을 수 있으며, 이 경우 다른 프로세스가 필요할 수 있습니다.

이 과정 또한 정상적으로 진행되었다면 드디어!! 응답받은 데이터인 HTML 파일을 미리 찾아놓은 렌더러 프로세스에게 전달합니다!
이제 렌더러 프로세스는 렌더링 할 준비를 시작하게 되는데 이 직전에 발생하는 게 커밋내비게이션이라는 과정입니다.

5단계: 탐색 커밋 (Commit Navigation)

드디어 마지막 과정입니다!
해당 과정을 통해서 내비게이션이 커밋되고 이 과정이 끝나면 렌더러 프로세스 안에서의 렌더링 과정이 진행됩니다.

브라우저 프로세스 안의 UI 스레드가 HTML 파일 데이터를 가지고 있으므로 브라우저 프로세스에서 HTML 파일 데이터를 렌더러 프로세스에게 전달합니다.
프로세스에서 프로세스로의 데이터 전달이기에 IPC(Inter-Process Communication)를 활용하여 전달됩니다. 이때 데이터 스트림을 전달하므로 렌더러 프로세스가 HTML 데이터를 계속 수신할 수 있습니다.
그렇게 브라우저 프로세스에서 렌더러 프로세스로의 커밋이 완료됐다는 확인을 수신하면 내비게이션이 끝나게 되는데 그렇게 되면 이제 문서 로드 단계(Document Loading Phase)가 시작됩니다.
문서 로드 단계가 렌더러 프로세스가 시작되는 렌더링 과정입니다.

이 렌더링 과정이 시작되기 전 주소 표시줄이 사용자가 처음에 입력했던 그 주소창으로 업데이트되고 위 이미지에서 URL 주소 왼쪽 자물쇠 모양의 보안 표시기(Security indicator) 및 사이트 설정 UI가 업데이트됩니다.
이때 자물쇠 표시와 사이트 설정 UI는 이동 전 사이트가 아닌 이동할 사이트의 정보로 확인이 되어 해당 사이트의 시큐리티를 표시하는 것으로 업데이트가 됩니다.

마지막으로 내비게이션이 커밋되었다는 것은 세션 히스토리(Sesstion History)가 새롭게 추가되었다는 것을 의미합니다. 이는 뒤로 가기-앞으로 가기 버튼을 누르면 방금 이동한 사이트를 단계별로 진행할 수 있도록 탭의 세션 기록이 업데이트되는 과정입니다. 탭 또는 창을 닫을 때 탭/세션 복원을 용이하게 하기 위해 세션 기록은 하드 디스크에 저장됩니다.
그렇기에 화면이 그려지기 전이라도 커밋 내비게이션 과정까지만 완료가 되었다면 뒤로 가기를 하였을 때 바로 직전의 브라우저로 이동할 수 있는 것입니다!

추가 단계: 초기 로드 완료

5단계 과정까지 완료 후 최종적으로 렌더러 프로세스가 HTML 파일을 받으며 여러 가지 과정을 거치면서 브라우저 렌더링의 모든 과정이 끝나면 렌더러 프로세스는 모든 onload 이벤트가 페이지의 모든 프레임에서 실행이 완료된 후에 IPC를 통해 브라우저 프로세스에게 모든 과정이 완료되었음을 알립니다.
이 응답을 받은 브라우저 프로세스의 UI 스레드는 탭에서 로딩 스피너를 중지합니다!

이 시점 이후에도 클라이언트 측 JavaScript가 여전히 추가 리소스를 로드하고 새 뷰를 렌더링 할 수 있기 때문에 여전히 동적으로 페이지를 업데이트하고 확장할 수 있는 시점입니다.

더 알아보기!

• 사용자가 주소 표시줄에 다른 URL을 다시 입력하면?! - beforeunload 학습
• 서비스 워커
• Chrome 속도 높이기에 관련된 탐색 미리 로드
  등에 대한 추가적인 학습을 원하신다면 아래의 참고 자료를 읽어보시면 좋습니다!!

참고자료

Chrome for Developers - 탐색에서 발생하는 일