"왜 자바스크립트는 스레드를 하나만 쓰면서 동시에 여러 일을 하는 것처럼 보일까?" 이 질문에 답하기 위해서는 자바스크립트의 실행 엔진뿐만 아니라, 이를 둘러싼 런타임 환경(Browser, Node.js)의 구조를 이해해야 한다.

본 글에서는 자바스크립트가 왜 싱글 스레드 노선을 택했는지, 그리고 비동기 처리의 핵심인 이벤트 루프와 await의 필요성에 대해 기술적인 관점에서 분석한다.

1. 자바스크립트는 왜 싱글 스레드인가?

멀티 스레드는 여러 작업을 병렬로 처리할 수 있어 효율적으로 보이지만, 그만큼 복잡한 문제를 동반한다. 자바스크립트가 싱글 스레드 모델을 유지하는 이유는 크게 두 가지로 요약할 수 있다.

자원 공유와 동기화 문제(Deadlock & Race Condition)

멀티 스레드 환경에서는 여러 스레드가 동일한 자원(메모리 등)에 동시에 접근할 수 있다. 이때 자원을 선점하기 위한 경쟁 상태(Race Condition)가 발생하거나, 서로의 작업이 끝나기를 무한정 기다리는 데드락(Deadlock) 상태에 빠질 위험이 크다. 자바스크립트는 이러한 복잡한 동기화 문제를 피하고 설계의 단순함을 유지하기 위해 싱글 스레드를 선택했다.

DOM 조작의 일관성

자바스크립트의 주된 역할은 웹 페이지의 UI를 조작하는 것이다. 만약 여러 스레드가 동시에 같은 DOM 요소에 접근하여 하나는 삭제하고, 하나는 수정을 시도한다면 화면은 예측 불가능한 상태가 될 것이다. 싱글 스레드 방식은 한 번에 하나의 작업만 수행함으로써 UI 렌더링의 일관성을 보장한다.

2. 어떻게 싱글로 멀티인척 작동할까?

자바스크립트 엔진 자체는 싱글 스레드이지만, 실제 자바스크립트가 실행되는 런타임(Browser/Node.js)은 멀티 스레드처럼 동작한다.

비동기 작업의 흐름

1. Call Stack: 자바스크립트 엔진의 메인 스레드로, 현재 실행 중인 함수들이 쌓인다.
2. Web API: 브라우저에서 제공하는 멀티 스레드 영역이다. setTimeout, fetch, DOM 이벤트 등이 여기서 처리된다. 자바스크립트 엔진은 시간이 오래 걸리는 작업을 여기에 던지고 다음 코드를 실행한다.
3. Task Queue & Event Loop: Web API에서 완료된 작업의 콜백 함수들이 대기하는 곳이다. 이벤트 루프(Event Loop)는 Call Stack이 비어있는지 끊임없이 확인하며, 비어있을 때 큐에 쌓인 작업을 스택으로 옮겨 실행한다.

태스크 큐의 우선순위: 매크로 vs 마이크로

모든 비동기 작업이 같은 대기열에 서는 것은 아니다. 큐는 크게 두 종류로 나뉘며 엄격한 우선순위를 가진다.

3. 왜 동기 함수 대신 비동기와 await을 쓰는가?

"결국 기다려야 한다면, 그냥 동기 함수(Sync)로 처리하면 되지 않을까?"라는 의문이 생긴다. 하지만 동기 처리는 웹 환경에서 치명적인 결함을 만든다.

블로킹(Blocking) 현상

동기 함수는 결과가 나올 때까지 메인 스레드를 점유한다. 예를 들어 네트워크 호출을 동기식으로 처리하면, 데이터를 받아오는 몇 초 동안 브라우저는 모든 동작을 멈춘다. 사용자는 버튼을 클릭할 수도, 화면을 스크롤할 수도 없는 '프리징(Freezing)' 현상을 겪게 된다.

await의 본질: 비차단(Non-blocking) 대기

await은 코드를 동기적으로 작성할 수 있게 해주지만, 동작 방식은 철저히 비동기적이다.

• await을 만나면 해당 함수의 실행은 일시 중단된다.
• 하지만 메인 스레드(Call Stack)는 해제되어 다른 UI 인터랙션이나 스크립트를 처리할 수 있게 된다.
• 비동기 작업이 완료되면 이벤트 루프에 의해 다시 스택으로 돌아와 중단되었던 지점부터 실행을 재개한다.

즉, await은 "메인 스레드를 쉬게 하면서 효율적으로 기다리는 방법"이지, 단순히 실행 순서를 맞추기 위한 도구가 아니다.

결론: 효율적인 싱글 스레드 활용

자바스크립트는 싱글 스레드라는 제약을 역설적으로 비동기 처리를 통해 강점으로 승화시켰다. 복잡한 스레드 관리 없이도 이벤트 루프를 통해 고성능의 논블로킹 I/O를 실현한 것이다.

프론트엔드 개발자에게 비동기 처리 이해는 필수적이다. 마이크로태스크의 높은 우선순위를 활용해 시급한 데이터를 먼저 처리하고, 무거운 작업은 적절히 분산하여 사용자 경험(UX)을 극대화하는 설계 능력이 곧 실력이다.

다음글은 마이크로태스크 큐를 활용해 실제 서비스의 렌더링 성능을 화하는 구체적인 사례를 다뤄 볼 것이다.

원문: Announcing TypeScript Native Previews - Microsoft Dev Blogs

개요

Microsoft TypeScript 팀이 2025년 5월 22일, TypeScript Native Previews의 광범위한 가용성을 발표했습니다. 이는 지난 3월에 공개된 네이티브 코드로 포팅된 TypeScript 컴파일러의 첫 번째 공개 프리뷰입니다.

핵심 성능 개선

10배 빠른 컴파일 속도

• 기존 TypeScript: JavaScript 기반 (Strada)
• 새로운 TypeScript: Go 언어로 작성된 네이티브 코드 (Corsa)
• 성능 향상: 대부분의 프로젝트에서 10배 빠른 속도 달성
• 개선 요소:
  • 네이티브 컴파일 언어 사용 (Go)
  • 공유 메모리 병렬 처리
  • 동시성 최적화

설치 및 사용법

1. npm을 통한 설치

npm install -D @typescript/native-preview

2. 명령줄 사용

# 기존 tsc 대신 tsgo 사용
npx tsgo --project ./src/tsconfig.json

# 진단 정보와 함께 실행
npx tsgo -p . --noEmit --extendedDiagnostics

3. VS Code 확장 프로그램

• 확장 프로그램명: "TypeScript (Native Preview)"
• 설치 방법: VS Code Extension Marketplace에서 설치
• 활성화 방법:
  • 명령 팔레트에서 "TypeScript Native Preview: Enable (Experimental)" 실행
  • 또는 설정에서 "typescript.experimental.useTsgo": true 추가

실제 성능 비교

Sentry 프로젝트 기준 성능 테스트

기존 TypeScript 5.8 (Strada):

Files:                         9306
Lines of TypeScript:        1113969
Memory used:               3356832K
Total time:                  72.81s  # 1분 이상 소요

새로운 TypeScript Native (Corsa):

Files:              9292
Lines:           1508361
Memory used:    3892267K
Total time:        ~7.3s   # 약 10배 빠름

주요 기능 지원 현황

✅ 완전 지원

• 타입 체킹: 대부분의 타입 체킹 기능 완전 지원
• JSX: JSX 타입 체킹 지원 추가됨
• JavaScript + JSDoc: JSDoc 기반 타입 체킹 지원
• 기본 완성 기능: 코드 완성 기능 구현

🚧 개발 중인 기능

• 자동 임포트: 아직 구현되지 않음
• 찾기/참조: find-all-references 기능 개발 중
• 이름 변경: rename 기능 개발 중
• 시그니처 도움말: signature help 개발 중

❌ 아직 미지원

• 빌드 모드: --build 플래그 미지원
• 선언 파일 생성: --declaration 미지원
• 다운레벨 컴파일: 일부 구버전 타겟 미지원
• 프로젝트 참조: 언어 서비스에서 프로젝트 참조 미지원

알려진 차이점 및 주의사항

1. 모듈 해석 방식 변경

기존 설정에서 오류가 발생할 수 있습니다:

// ❌ 더 이상 권장되지 않음
{
  "compilerOptions": {
    "moduleResolution": "node",
    "module": "commonjs"
  }
}

// ✅ 권장 설정
{
  "compilerOptions": {
    "module": "preserve",
    "moduleResolution": "bundler"
  }
}

2. TypeScript 6.0 호환성

• node/node10 해석 방식은 TypeScript 6.0에서 제거될 예정
• node16, nodenext, bundler 해석 방식 사용 권장

로드맵 및 업데이트

단기 계획 (2025년 말까지)

• 완전한 컴파일러: --build 등 주요 기능 완성
• 언어 서비스: 대부분의 편집기 기능 구현
• API 안정화: API 레이어 완성

업데이트 정책

• 야간 빌드: 매일 새로운 개발 버전 배포
• 자동 업데이트: VS Code 확장 프로그램 자동 업데이트
• 문제 발생 시: "TypeScript Native Preview: Disable" 명령으로 비활성화 가능

개발자 권장사항

1. 시도해보기

• 새로운 프로젝트나 테스트 환경에서 먼저 시도
• 기존 프로젝트는 백업 후 테스트

2. 문제 보고

• 예상과 다른 동작 발견 시 GitHub 이슈 트래커에 보고
• 구체적인 재현 단계와 함께 보고

3. 점진적 도입

• 현재는 프리뷰 단계이므로 프로덕션 환경에서는 주의
• 안정화 후 TypeScript 7로 정식 출시 예정

결론

TypeScript Native Previews는 TypeScript 생태계의 중요한 발전입니다. 10배 빠른 컴파일 속도는 대규모 프로젝트에서 개발자 경험을 크게 향상시킬 것으로 예상됩니다.

현재는 프리뷰 단계이지만, 지속적인 개발과 커뮤니티 피드백을 통해 안정적인 TypeScript 7로 발전할 예정입니다. 개발자들은 이 기회에 새로운 네이티브 TypeScript를 미리 경험해보고 피드백을 제공하는 것이 좋겠습니다.

참고 자료:

• 원문: Announcing TypeScript Native Previews
• TypeScript Native Preview npm 패키지
• TypeScript GitHub 저장소

예측가능한 코드, 상태관리와 밀접한 개념인 부수효과(Side Effect)에 대해 알아보자.

부수효과(Side Effect)란?

부수효과는 함수가 실행될 때 _함수 외부의 상태를 변경_하거나, 외부 상태에 의존하는 모든 행위를 말한다.

부수효과에서 언급하는 '외부'는 함수의 스코프 밖에 있는 모든 것을 의미한다. 하.. 스코프는 또 뭐지? => 클릭

1. 예시로 이해해보자

// 🚨 부수효과가 있는 함수들

// 1. 외부 변수 변경
let total = 0;
const addToTotal = (num: number) => {
  total += num;  // 외부 변수 total을 변경
};

// 2. 콘솔 출력
const logUser = (user: User) => {
  console.log(user);  // 외부 환경(콘솔)에 출력
};

// 3. API 호출
const saveUser = async (user: User) => {
  await fetch('/api/users', {  // 외부 서버와 통신
    method: 'POST',
    body: JSON.stringify(user)
  });
};

// 4. DOM 조작
const updateUI = (element: HTMLElement) => {
  element.textContent = 'Updated!';  // DOM 상태 변경
};

2. 순수 함수(Pure Function)의 예시

// ✅ 부수효과가 없는 순수 함수들

// 1. 입력값에 따른 출력값만 반환
const double = (num: number): number => {
  return num * 2;
};

// 2. 객체 변환
const formatUser = (user: User): FormattedUser => {
  return {
    fullName: `${user.firstName} ${user.lastName}`,
    age: calculateAge(user.birthDate)
  };
};

// 3. 배열 변환
const filterActiveUsers = (users: User[]): User[] => {
  return users.filter(user => user.isActive);
};

3. 부수효과의 특징

1. 예측 불가능성

• 외부 상태에 의존하므로 결과를 예측하기 어려움
• 테스트가 복잡해짐

// 🚨 예측 불가능성 예시
let globalCount = 0;

const increment = () => {
  globalCount++;
  return globalCount;
};

console.log(increment()); // 1
console.log(increment()); // 2
// 다른 개발자가 globalCount를 100으로 변경했다면?
console.log(increment()); // 101 (예측 불가능!)

// ✅ 예측 가능한 코드
const increment = (count: number) => {
  return count + 1;
};

console.log(increment(0)); // 1
console.log(increment(1)); // 2
console.log(increment(2)); // 3 (항상 예측 가능!)

2. 디버깅의 어려움

• 문제 발생 시 원인 파악이 어려움

• 상태 변경의 흐름을 추적하기 어려움

  // 🚨 디버깅이 어려운 코드예시
  

// 1. 첫 번째 코드 (부수효과 있음) let user = { name: '김지성' };

const updateUser = () => { user.name = '박지성'; // 🚨 외부 변수 직접 수정 console.log('User updated'); };

updateUser(); console.log(user); // { name: '박지성' }

// 2. 두 번째 코드 (순수 함수) const user = { name: '김지성' };

const updateUser = (user: User) => { return { ...user, name: '박지성' }; // ✅ 새로운 객체 반환 };

const newUser = updateUser(user); console.log(user); // { name: '김지성' } (원본 유지) console.log(newUser); // { name: '박지성' } (새로운 객체)

주요 차이점:

1. 원본 데이터 변경 여부

   • 첫 번째: 원본 user 객체를 직접 수정
   • 두 번째: 원본은 그대로 두고 새로운 객체를 반환

2. 함수의 예측 가능성

   • 첫 번째: 함수 호출 시 외부 변수 user의 상태에 따라 결과가 달라짐
   • 두 번째: 입력값이 같으면 항상 같은 결과를 반환

3. 디버깅 용이성

   • 첫 번째: user.name이 어디서 변경되었는지 추적이 어려움
   • 두 번째: 상태 변경이 명확하게 함수의 반환값으로 표현됨

4. 사용 예시 // 첫 번째 방식 let user = { name: '김지성' }; updateUser(); // user가 변경되었는지 확인하려면 user를 직접 확인해야 함

// 두 번째 방식 const user = { name: '박지성' }; const updatedUser = updateUser(user); // 변경된 내용이 명확하게 updatedUser에 담겨있음

두번째 방식 특히 React의 불변성(Immutability) 원칙에 맞다. 불변성(Immutability): 데이터가 한번 생성되면 그 값을 변경할 수 없고, 대신 새로운 데이터를 생성하여 사용해야 한다는 원칙. React에서 불변성을 지키면 상태 변경의 추적이 용이해짐. 예측 가능한 애플리케이션을 만들 수 있다.

>3. **코드 재사용성 저하**
   - 외부 상태에 의존하므로 다른 환경에서 재사용이 어려움

### 4. 부수효과를 최소화하는 방법

```typescript
// 🚨 부수효과가 많은 코드
class UserManager {
  private users: User[] = [];

  addUser(user: User) {
    this.users.push(user);
    console.log(`User added: ${user.name}`);
    this.saveToDatabase(user);
    this.updateUI();
  }
}

// ✅ 부수효과를 분리한 코드
class UserManager {
  private users: User[] = [];

  // 순수 함수: 데이터 변환만 담당
  addUser(user: User): User[] {
    return [...this.users, user];
  }

  // 부수효과를 명시적으로 분리
  async handleUserAddition(user: User) {
    const newUsers = this.addUser(user);
    await this.saveToDatabase(user);
    this.notifyUserAdded(user);
    this.updateUI(newUsers);
  }
}

5. React에서의 부수효과 관리

무한 렌더링 가능성

const UserProfile: React.FC = () => {
  const [user, setUser] = useState<User | null>(null);

  // 이 함수는 컴포넌트가 렌더링될 때마다 새로 생성됨
  const fetchUser = async () => {
    const response = await fetch('/api/user');
    const data = await response.json();
    setUser(data);  // setUser 호출 → 상태 변경 → 컴포넌트 재렌더링
  };

  return <div>{user?.name}</div>;
};

문제점:

• fetchUser 함수가 컴포넌트 내부에 있어서, 컴포넌트가 렌더링될 때마다 새로운 함수가 생성됨
• 이 함수가 setUser를 호출하면 상태가 변경되어 컴포넌트가 다시 렌더링됨
• 다시 렌더링되면 fetchUser가 다시 생성되고... 이렇게 무한 루프가 발생할 수 있음

데이터 페칭 시점 불명확

const UserProfile: React.FC = () => {
  const [user, setUser] = useState<User | null>(null);

  const fetchUser = async () => {
    const response = await fetch('/api/user');
    const data = await response.json();
    setUser(data);
  };

  // fetchUser를 어디서 호출해야 할지 명확하지 않음
  return <div>{user?.name}</div>;
};

문제점:

• fetchUser 함수는 정의만 되어있고, 어디서 호출해야 할지가 명확하지 않음
• 컴포넌트가 처음 마운트될 때 자동으로 데이터를 가져오지 않음
• 사용자가 직접 호출해야 하는지, 자동으로 호출되어야 하는지 불명확

부수효과와 렌더링 로직이 섞여있음

const UserProfile: React.FC = () => {
  const [user, setUser] = useState<User | null>(null);

  // 데이터 가져오기 (부수효과)
  const fetchUser = async () => {
    const response = await fetch('/api/user');
    const data = await response.json();
    setUser(data);
  };

  // UI 그리기 (렌더링 로직)
  return <div>{user?.name}</div>;
};

문제점:

• 데이터를 가져오는 로직(fetchUser)과 UI를 그리는 로직(return)이 한 컴포넌트에 섞여있음
• 이렇게 되면 코드가 복잡해지고 유지보수가 어려워짐

개선된 버전

const UserProfile: React.FC = () => {
  const [user, setUser] = useState<User | null>(null);

  // useEffect로 데이터 가져오기 로직을 분리
  useEffect(() => {
    const fetchUser = async () => {
      const response = await fetch('/api/user');
      const data = await response.json();
      setUser(data);
    };

    fetchUser();  // 컴포넌트 마운트 시 한 번만 실행
  }, []);  // 빈 배열: 의존성이 없으므로 마운트 시 한 번만 실행

  // UI 그리기 로직만 남음
  return <div>{user?.name}</div>;
};

장점:

1. useEffect를 사용해 데이터 가져오기 로직을 분리
2. 컴포넌트 마운트 시 한 번만 실행되도록 명확하게 지정
3. UI 그리기 로직만 남아서 코드가 깔끔해짐

이렇게 하면 코드가 더 예측 가능하고 유지보수하기 쉬워짐

결론

이 글을 여기까지 훑고 부수효과가 무엇이고, 프로그램에 어떤 영향을 미칠 수 있는지 정도 이해했다면 성공적이라고 생각한다. 부수효과는 코드의 예측 가능성과 유지보수성을 저하시키는 주요 원인이다. 하지만 현실적인 프로그래밍에서 부수효과를 완전히 제거하기는 불가능에 가깝다.

따라서 이 글의 핵심은 부수효과의 제거가 아닌 _'이 함수를 호출하면 외부에 어떤 영향을 줄지 코드만 봐도 알 수 있게 하자'_이다.

// ❌ 숨겨진 부수효과
const addToCart = (item) => {
  const newItem = { ...item, id: Date.now() };
  cart.push(newItem); // 🚨 전역 배열 변경 (숨겨진 부수효과)
  return newItem;
};

// ✅ 명시적 부수효과
const createCartItem = (item) => {
  return { ...item, id: Date.now() }; // 순수 함수
};

const addToCart = (item) => {
  const newItem = createCartItem(item);
  cart.push(newItem); // 명시적으로 전역 상태 변경
  return newItem;
};

웹 애플리케이션 개발이 점점 복잡해지면서, 초기의 단일 구조(Monolithic) 애플리케이션은 여러 문제점을 드러냈습니다. 이런 문제를 해결하기 위해 등장한 것이 3계층 구조(3-Tier Architecture) 입니다. IBM, Oracle, Microsoft 등의 기업들은 엔터프라이즈 애플리케이션 개발 가이드에서 단일 구조의 한계를 극복하기 위한 다계층 아키텍처의 중요성을 강조해왔습니다.

단일 구조의 문제점

모든 것이 한 곳에 섞임:

• 한 파일에 HTML, CSS, JavaScript, 데이터베이스 쿼리가 모두 섞여 있어 변경이 어려웠습니다.

• 화면 디자인만 바꾸고 싶어도 데이터 처리 코드까지 건드려야 했습니다.
• TV 채널만 바꾸려고 할 때마다 전체 설정을 들어가서 바꿔야 하는 느낌.

코드 재활용이 어려움:

• 모듈화가 되지 않으니 같은 기능이 필요할 때마다 처음부터 다시 코드를 작성해야 했습니다.

테스트가 복잡:

• 특정 기능만 테스트하고 싶어도 전체를 실행해야 했습니다.

이러한 문제를 해결하기 위해 애플리케이션을 기능별로 분리하는 계층화된 접근 방식이 필요!

프레젠테이션 계층 (Presentation Tier) React, Redux, 컴포넌트, UI

비즈니스 계층 (Business Tier) UseCase, 비즈니스 로직, 인터페이스

데이터 계층 (Data Tier) Repository 구현체, API 호출, DB 접근

// 데이터 계층: UserRepositoryImpl.ts
export class UserRepositoryImpl implements UserRepository {
  async getUser(): Promise<User> {
    const response = await fetch('https://XXXXXX.co.kr/product/user', {
      method: 'GET',
      headers: {
        'Content-Type': 'application/json',
        Authorization: `Bearer ${localStorage.getItem('XXXX-accessToken')}`,
      },
    });

    if (!response.ok) {
      throw new Error('존재하지 않는 id입니다. 관리자에게 문의해주세요.');
    }

    const data = await response.json();
    return {
      userId: data.userId,
      name: data.name,
      // 기타 필드...
    };
  }
}

// 비즈니스 계층: GetUserUseCase.ts
export class GetUserUseCase {
  constructor(private repository: UserRepository) {}

  async execute(): Promise<User> {
    return this.repository.getUser();
  }
}

// 프레젠테이션 계층: actions.ts
export const getUserAction = createAsyncThunk<User, void, { rejectValue: string }>(
  'user/getUser',
  async (_, { rejectWithValue }) => {
    const useCase = new GetUserUseCase(repository);
    try {
      const user = await useCase.execute();
      return user;
    } catch (error) {
      return rejectWithValue((error as Error).message);
    }
  },
);

// 인터페이스 (추상화)
interface UserRepository {
  getUser(): Promise<User>;
}

// 비즈니스 계층: 인터페이스에 의존
class GetUserUseCase {
  constructor(private repository: UserRepository) {}

  async execute(): Promise<User> {
    return this.repository.getUser();
  }
}

// 비즈니스 계층: 구체적인 구현체에 직접 의존
class GetUserUseCase {
  private repository = new UserRepository(); // 직접 의존!

  async execute(): Promise<User> {
    return this.repository.getUser();
  }
}

문제 상황: 상태는 변했는데 콘솔에는 예전 값이?

리액트와 리덕스로 개발하다 보니 이런 상황을 자주 마주쳤습니다.

// Redux 상태를 가져옴
const userDataState = useAppSelector(selectUserState);

useEffect(() => {
  // Redux 액션 디스패치
  dispatch(getUserAction())
    .unwrap()
    .then(() => {
      // 데이터가 바뀌었을 거라 기대하지만...
      console.log('userDataState:', userDataState); // 여전히 초기값(null)이 출력됨 😱
    });
}, []);

위 코드에서 저는 getUserAction이 성공적으로 완료된 후 업데이트된 userDataState를 콘솔에서 보길 기대했습니다. 하지만 실제로는 변경 전의 값(보통 초기값인 null)이 출력됩니다. (더 정확히는 리듀서에서 loading 값이 false로 나옵니다. 일단 값이 안들어갔다고 생각하시면 됩니다.)

왜 이런 일이 발생할까?

"클로저" 때문입니다 클로저가 뭐지? 클릭

자바스크립트의 클로저(Closure)란 _함수가 자신이 생성된 환경의 변수를 기억하는 특성_입니다.

이 코드에서:

1. .then(() => { ... }) 콜백 함수가 생성되는 시점에 userDataState는 초기값(null)입니다.
2. 이 콜백은 해당 시점의 userDataState 값을 "기억"합니다.
3. 비동기 작업이 완료되어 Redux 상태가 업데이트되더라도, 이미 생성된 콜백 내부의 userDataState 참조는 여전히 초기값을 가리킵니다.

실제 사례와 문제점

제가 개발 중인 로그인 프로세스에서 이러한 문제가 발생했습니다:

dispatch(getUserAction())
  .unwrap()
  .then(() => {
    console.log('userDataState from getUserAction', userDataState); // null이 출력됨

    dispatch(initUserAction())
      .unwrap()
      .then(() => {
        console.log('userDataState from initUserAction', userDataState); // 여전히 null 출력됨

        // 이후 로직...
      });
  });

이 문제로 인해:

1. 상태 업데이트 여부를 콘솔로 확인하기 어려웠습니다.
2. 업데이트된 상태에 의존하는 후속 로직이 올바르게 동작하지 않았습니다.
3. 디버깅이 복잡해졌습니다.

해결 방법: 클로저 함정 피하기

1. 액션 결과 직접 사용하기

방법 중 하나는 Redux 상태를 참조하지 않고, 액션의 결과를 직접 사용하는 것입니다:

dispatch(getUserAction())
  .unwrap()
  .then((userResult) => {
    console.log('User data from action result:', userResult); // 여기서는 최신 데이터 접근 가능

    // 다음 액션으로 필요한 값 전달
    return dispatch(initUserAction()).unwrap().then(() => userResult.userId);
  })
  .then((userId) => {
    // 전달받은 값으로 작업
    dispatch(fetchProducts({ userId: Number(userId) }));
  });

2. Promise 체인 활용하기

Promise 체인을 사용하여 각 단계의 결과를 다음 단계로 전달합니다:

dispatch(getUserAction())
  .unwrap()
  .then(() => {
    const userId = localStorage.getItem('userId');
    if (!userId) throw new Error('사용자 ID를 찾을 수 없습니다.');

    // 이 값을 다음 단계로 전달
    return dispatch(initUserAction()).unwrap().then(() => userId);
  })
  .then((userId) => {
    // 전달받은 userId 사용
    return dispatch(fetchProducts({ userId: Number(userId) }));
  })
  .then(() => {
    // 최종 성공 처리
    message.success('로그인에 성공했습니다.');
    navigate('/admin');
  });

3. 필요한 시점에 상태 다시 가져오기

리덕스 스토어에 직접 접근하여 최신 상태를 가져올 수도 있습니다:

import { store } from '../path/to/store';

dispatch(getUserAction())
  .unwrap()
  .then(() => {
    // 스토어에서 최신 상태 직접 가져오기
    const currentState = store.getState();
    console.log('Current user state:', currentState.user);

    // 이후 로직...
  });

교훈

1. 클로저의 작동 방식 이해하기: 비동기 콜백에서 외부 변수를 참조할 때 클로저 함정에 주의하자.

2. 상태 의존성 최소화하기: 비동기 액션 체인에서는 이전 단계의 결과를 직접 다음 단계로 전달하자.

3. 필요시 최신 상태 직접 접근하기: 꼭 필요하다면 스토어에서 최신 상태를 직접 가져오는 방법을 사용하자

4. 디버깅 전략 세우기: 상태 변화를 디버깅할 때는 컴포넌트 리렌더링이나 useEffect가 실행되는 시점에 로그를 확인하자.

정리

• 클로저 좋다.

• 하지만 비동기 환경에서 명심하자.
• 특히 상태 관리에서.

"Hook은 컴포넌트의 최상위 레벨에서만 호출해야 한다"

리액트를 사용하다 보면 마주치는 규칙 중 하나는 "Hook은 컴포넌트의 최상위 레벨에서만 호출해야 한다"는 것이다. 특히 useState를 조건문이나 반복문, 중첩된 함수 내부에서 사용하면 안 된다. 이 규칙을 어기면 어떤 문제가 발생하는지, 그리고 왜 이런 규칙이 존재하는지 자세히 알아보자.

리액트 Hooks의 동작 원리

Hook과 순서 의존성

리액트는 내부적으로 컴포넌트의 상태(state)를 관리하기 위해 '순서'에 의존한다. 컴포넌트가 렌더링될 때마다 Hook이 호출되는 순서를 기억하여 각 Hook과 해당 상태를 연결한다.

예를 들어, 다음과 같은 컴포넌트가 있다고 가정해 보자.

function ProfileCard() {
  const [name, setName] = useState('홍길동');       // 첫 번째 Hook
  const [age, setAge] = useState(30);             // 두 번째 Hook
  const [isAdmin, setIsAdmin] = useState(false);  // 세 번째 Hook

  // ...
}

리액트는 내부적으로 이 Hook들을 배열 형태로 저장하고 관리한다. 첫 번째 렌더링에서는:

1. 첫 번째 useState: 'name' 상태를 '홍길동'으로 초기화
2. 두 번째 useState: 'age' 상태를 30으로 초기화
3. 세 번째 useState: 'isAdmin' 상태를 false로 초기화

다음 렌더링에서도 같은 순서로 Hook이 호출되기 때문에, 리액트는 각 Hook 호출이 어떤 상태와 연결되어 있는지 정확히 알 수 있다.

조건부 Hook 사용 시 발생하는 문제

이제 useState를 조건문 안에서 사용하면 어떤 일이 발생하는지 살펴보자.

function ProfileCard({ isAdmin }) {
  const [name, setName] = useState('홍길동');       // 항상 첫 번째 Hook

  if (isAdmin) {
    const [adminSince, setAdminSince] = useState('2023-01-01');  // 조건부 두 번째 Hook
  }

  const [age, setAge] = useState(30);             // 조건에 따라 두 번째 또는 세 번째 Hook

  // ...
}

첫 렌더링에서 isAdmin이 true인 경우:

1. 첫 번째 useState: 'name' 상태 초기화
2. 두 번째 useState: 'adminSince' 상태 초기화
3. 세 번째 useState: 'age' 상태 초기화

하지만 다음 렌더링에서 isAdmin이 false로 바뀌면:

1. 첫 번째 useState: 'name' 상태 (유지)
2. 두 번째 useState가 호출되지 않음
3. 두 번째(원래는 세 번째) useState: 이제 이 Hook은 이전 렌더링의 'adminSince' 상태를 참조하게 된다.

이렇게 되면 리액트는 'age' 상태를 'adminSince' 상태로 오인하게 되며, 이는 버그를 발생시킬 수 있다.

실제 예시로 살펴보기

더 구체적인 예시로 문제를 살펴보자.

function Counter({ showSpecialCounter }) {
  const [count, setCount] = useState(0);

  if (showSpecialCounter) {
    const [specialCount, setSpecialCount] = useState(10);
  }

  const [step, setStep] = useState(1);

  return (
    <div>
      <p>일반 카운터: {count}</p>
      <button onClick={() => setCount(count + step)}>증가</button>
      <p>스텝: {step}</p>
      <button onClick={() => setStep(step + 1)}>스텝 증가</button>
    </div>
  );
}

이 컴포넌트는 다음과 같은 시나리오에서 문제가 발생한다:

1. 처음에 showSpecialCounter가 true인 경우:

• 첫 번째 Hook: count = 0
• 두 번째 Hook: specialCount = 10
• 세 번째 Hook: step = 1

2. 사용자가 "스텝 증가" 버튼을 클릭하여 step을 2로 변경한다.

3. 부모 컴포넌트에서 showSpecialCounter를 false로 변경한다.

4. 다음 렌더링에서:

• 첫 번째 Hook: count = 0 (유지)
• 두 번째 Hook: 이제 specialCount의 Hook이 사라지고, 원래 세 번째였던 Hook이 두 번째가 된다.
• 리액트는 두 번째 Hook에 저장된 값(원래는 specialCount의 10)을 step의 값으로 사용한다.

결과적으로 step은 사용자가 설정한 2가 아닌 10으로 표시되며, "증가" 버튼을 클릭하면 count가 1씩 증가하는 것이 아니라 10씩 증가하게 된다.

리액트 개발자 도구 경고

리액트는 이러한 문제를 방지하기 위해 개발 모드에서 Hook 규칙 위반을 감지하고 경고를 표시한다.

React Hook "useState" is called conditionally. React Hooks must be called in the exact same order in every component render.

이 경고는 우리가 앞서 살펴본 문제를 방지하기 위한 것이다.

조건부 상태를 관리하는 올바른 방법

조건부로 상태를 사용해야 하는 경우, Hook을 컴포넌트 최상위 레벨에 배치하고 조건을 내부 로직에 적용하는 것이 올바른 방법이다.

function ProfileCard({ isAdmin }) {
  const [name, setName] = useState('홍길동');
  const [adminSince, setAdminSince] = useState(isAdmin ? '2023-01-01' : null);
  const [age, setAge] = useState(30);

  // adminSince를 조건부로 사용
  const adminSection = isAdmin && (
    <div>
      <h3>관리자 정보</h3>
      <p>관리자 등록일: {adminSince}</p>
    </div>
  );

  return (
    <div>
      <h2>{name}, {age}세</h2>
      {adminSection}
    </div>
  );
}

또는 조건에 따라 다른 컴포넌트를 렌더링하는 방법도 있다:

function AdminProfile() {
  const [adminSince, setAdminSince] = useState('2023-01-01');
  // ...
  return <div>관리자 프로필...</div>;
}

function UserProfile() {
  // 관리자 상태 없음
  // ...
  return <div>일반 사용자 프로필...</div>;
}

function ProfileContainer({ isAdmin }) {
  return isAdmin ? <AdminProfile /> : <UserProfile />;
}

결론

리액트의 Hook은 호출 순서에 의존하여 상태를 관리하는 특성을 가지고 있다. 따라서 useState와 같은 Hook은 항상 컴포넌트의 최상위 레벨에서, 그리고 렌더링마다 동일한 순서로 호출되어야 한다.

조건문 안에서 Hook을 사용하면 렌더링마다 Hook의 호출 순서가 바뀔 수 있어 의도치 않은 상태 불일치와 버그가 발생할 수 있다. 이를 방지하기 위해서는 Hook을 최상위에 배치하고, 조건부 로직은 Hook 호출 이후에 처리하는 것이 중요하다.

• 트렁크(Trunk) / 메인 브랜치(Main Branch)

• CI/CD (지속적 통합/배포)
• 소규모 빈번한 커밋
• 피처 플래그(Feature Flag)
• 자동화된 테스트
• 코드 리뷰

들어가며: 왜 트렁크 기반 개발인가?

소프트웨어 개발에서 가장 중요한 것 중 하나는 "얼마나 빠르고 안정적으로 새로운 기능을 사용자에게 전달할 수 있는가" 이다. 트렁크 기반 개발은 이러한 목표를 달성하기 위한 현대적인 개발 방식이다.

트렁크? 빤스인가?

트렁크 기반 개발은 개발자들이 작은 단위의 변경사항을 자주 메인 브랜치(트렁크)에 병합하는 버전 관리 방식이다. 이는 마치 나무의 줄기(trunk)처럼 하나의 중심 줄기에 모든 변경사항이 모이는 형태를 띈다.

실제 시나리오로 이해하기

팀 프로젝트 상황을 가정해보겠다:

상황: 온라인 쇼핑몰 개발 프로젝트
팀원: 프론트엔드 개발자 A, 백엔드 개발자 B, C

1일차 아침:
- A: 장바구니 UI 개선 작업 시작
- B: 결제 API 수정 작업 시작
- C: 상품 검색 기능 개선 작업 시작

1일차 오후:
- A: 장바구니 아이콘 변경사항 커밋 및 병합 (15줄 수정)
- B: 결제 API 유효성 검사 로직 추가 커밋 및 병합 (20줄 수정)
- C: 검색 알고리즘 최적화 부분 커밋 및 병합 (30줄 수정)

2일차:
- 각자 남은 작업을 작은 단위로 나누어 지속적으로 커밋 및 병합

기존 Git Flow와의 차이점

Git Flow 방식

Feature Branch 방식:
1. feature/cart-improvement 브랜치 생성
2. 2주간 작업
3. 100개 이상의 파일 변경
4. PR 생성
5. 코드 리뷰에 3일 소요
6. 충돌 해결에 2일 소요

트렁크 기반 개발 방식

1. 트렁크에서 직접 작업 또는 초단기 브랜치 생성
2. 하루 작업
3. 5-10개 파일 변경
4. PR 생성
5. 코드 리뷰 30분 소요
6. 충돌 최소화

트렁크 기반 개발의 장점

1. 지속적 통합의 실현

• 작은 변경사항의 빈번한 병합으로 통합 문제 최소화
• 실시간으로 문제 발견 및 해결 가능

2. 효율적인 코드 리뷰

• 작은 단위의 변경사항으로 리뷰어의 부담 감소
• 더 깊이 있는 코드 리뷰 가능

3. 빠른 배포 주기

• 언제든 배포 가능한 상태 유지
• 새로운 기능의 빠른 출시 가능

실전 적용을 위한 Best Practice

1. 작은 단위로 개발하기

나쁜 예:
- 한 번에 전체 회원가입 기능 구현 (500줄 변경)

좋은 예:
- 회원가입 입력 폼 UI 구현 (50줄)
- 이메일 유효성 검사 추가 (30줄)
- 비밀번호 정책 구현 (40줄)
- API 연동 구현 (60줄)

2. 피처 플래그 활용하기

피처 플래그(Feature Flag): 코드 안에 "스위치"를 심어두는 개발 기법. 이 스위치를 통해 프로덕션 환경에서도 새로운 기능을 안전하게 켜고 끌 수 있다.

// 피처 플래그 예시
if (featureFlags.isEnabled('new-payment-system')) {
    // 새로운 결제 시스템 코드(특정 사용자에게만 새 기능을 보여줄 수 있음)
    processNewPayment();
} else {
    // 기존 결제 시스템 코드
    processOldPayment();
}

3. 자동화된 테스트 구축

커밋 시 자동 실행되는 테스트:
1. 단위 테스트
2. 통합 테스트
3. 코드 커버리지 검사
4. 린트 검사

트렁크 기반 개발 도입 시 주의사항

1. 팀 문화의 변화

• 작은 단위 커밋에 대한 팀원 합의 필요
• 빠른 코드 리뷰 문화 정착 필요

2. 테스트 자동화 필수

• 지속적 통합을 위한 테스트 인프라 구축
• 테스트 작성을 일상화

3. 점진적 도입

• 소규모 프로젝트부터 시작
• 팀원들의 적응 기간 필요

마치며

트렁크 기반 개발은 현대 소프트웨어 개발에서 CI/CD를 실현하는 핵심 방법론이다. 필자가 참고한 본문에 의하면 작은 변경사항의 빈번한 통합이라는 단순한 원칙이 가져오는 효과는 매우 크다고 한다. 처음에는 도전적으로 느껴질 수 있지만, 팀의 생산성과 코드 품질을 크게 향상시킬 수 있다.

글을 읽기 전에 SEO가 뭔지 빠르게 알고 가기 => SEO가 뭐징?

필요성

고생해서 웹 서비스 하나 만들었다. ⇒ 사용자가 있어야 의미가 있다. ⇒ 사용자에게 노출시켜야한다. ⇒ 지인들에게 일일이 url을 나눠준다?ㄴㄴ ⇒ 구글에 검색하게 한다. => 서비스 이름, 관련 검색어를 구글에 검색했을때 우리 서비스가 상위에 노출되어야한다.

• 구글 검색창에 내가 만든 서비스 명을 검색했을때 나오게 하려면 구글의 검색 인덱스에 등록되어야 한다.

• 이를 위해 구글 서치 콘솔에 사이트를 등록하고 인덱싱을 요청해야한다.
• 그냥 자연 크롤링도 가능하지만 상대적으로 시간이 오래걸린다.
• 그렇다고 구글 서치 콘솔 등록만으로 상위 노출이 보장되지는 않는다.
• SEO 최적화, 양질의 컨텐츠, 사용자 경험 등이 모두 중요하다.
• 구글 서치 콘솔 등록은 이 과정의 첫 단계이다.

정리하자면

구글검색창에 검색 시 나의 프로젝트가 빨리빨리 상위에 뜨기 위해서는 구글 서치 콘솔등록 + 메타데이터 최적화(SEO)를 해야한다.

메타데이터 최적화(SEO) 먼저 해보자

nextjs 공식문서 참조

공식문서에 나오는 5가지 메타데이터 요소들의 필요성 요약

favicon.ico (파비콘)

• 웹브라우저 탭에 보이는 작은 아이콘
• 사용자가 여러 탭을 열었을 때 어떤 사이트인지 빠르게 구분 가능
• 네이버 -> 녹색 N, 깃헙 -> 고양이 모양

icon (일반 아이콘)

• 모바일 기기나 데스크톱에서 웹사이트 바로가기 아이콘
• 앱 아이콘처럼 보이는 큰 아이콘
• 사용자 기기의 홈 화면이나 바탕화면에 웹사이트 바로가기를 만들 때 사용

manifest.json

• 웹앱의 설치 및 표시 방식을 정의하는 설정 파일
• PWA(Progressive Web App) 구현에 필요한 정보를 포함
• 사용자가 웹사이트를 마치 모바일 앱처럼 사용할 수 있게 해줌

opengraph-image (오픈그래프 이미지)

• 링크 공유 시 보이는 대표 이미지
• 링크의 미리보기 이미지를 예쁘게 만들어줌
• 사용자의 클릭율에 영향

robots.txt

• 검색엔진 크롤러에게 웹사이트 탐색 규칙을 알려주는 파일
• 어떤 페이지를 검색 결과에 보여줄지, 숨길지 지정
• 웹사이트의 중요한 페이지는 노출하고, 민감한 페이지는 숨기는 역할
• SEO(검색 엔진 최적화)에 매우 중요한 파일
• 예: 관리자 페이지는 숨기고, 검색 결과 페이지는 검색 노출

예시 코드(필자의 프로젝트에 맞는 코드이기 때문에 참고용으로만 봐주세요..)

import { MetadataRoute } from 'next'

export default function robots(): MetadataRoute.Robots {
  const baseUrl = process.env.NEXT_PUBLIC_SITE_URL || 'https://npmhub.vercel.app'

  return {
    // 크롤러 규칙
    rules: [
      {
        // 구글 크롤러에 대한 특별 규칙
        userAgent: 'Googlebot',
        allow: [
          '/',             
          '/search/*',        
          '/detail/*',      
        ],
        disallow: [
          '/api/*',         // API 엔드포인트 제외
          '/_next/*',       // Next.js 내부 파일 제외
          '/static/*',      // 정적 파일 제외
        ],
      },
      {
        // 다른 모든 크롤러에 대한 규칙
        userAgent: '*',
        allow: [
          '/',
          '/search/*',
          '/detail/*',     
        ],
        disallow: [
          '/api/*',
          '/_next/*',
          '/static/*',
        ],
      }
    ],
    // 사이트맵 위치
    sitemap: `${baseUrl}/sitemap.xml`,
    // 표준 호스트 선언
    host: baseUrl,
  }
}

sitemap.xml (필자는 ts 확장자로 함. Next.js 13 이상에서는 sitemap.ts 파일로 만들어도 자동으로 XML 형식으로 변환해줌.)

• 웹사이트의 페이지 구조를 검색엔진에 알려주는 지도 역할
• 각 페이지의 중요도(priority)와 업데이트 주기(changeFrequency) 정보 제공
• 검색엔진이 누락 없이 사이트의 모든 중요 페이지를 발견할 수 있도록 안내
• 효율적인 색인 생성으로 검색 노출 가능성 증가

import type { MetadataRoute } from 'next'

export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  const baseUrl = process.env.NEXT_PUBLIC_SITE_URL || 'https://npmhub.vercel.app'

  const staticPages: MetadataRoute.Sitemap = [
    {
      url: `${baseUrl}`,
      lastModified: new Date(),
      changeFrequency: 'daily',
      priority: 1.0
    },
  ]

  return staticPages
}

여기까지 SEO 최적화가 되었다면!

Google Search Console에 등록하기

Google Search Console <= 여기에 들어가서

선택을 하는데 지금은 DNS 관련 비용없이 해야하기 때문에 필자는 오른쪽의 url 접두어를 선택하여 vercel로 배포한 url을 넣었다.

그럼 verfication 코드를 보여주는데 이걸 메타데이터 파일에 추가한다.

// app/layout.tsx
... 생략
export const metadata: Metadata = {
  ... 생략
  verification: {
    google: 'KKAVIyXJmhqKL0jj2c6OT8mUawJAktjzV88OUMnCm_s', 
  }, // 여기여기
  category: 'Technology',
 };
... 생략
export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        <ClientRoot>
          <ClientLayout>{children}</ClientLayout>
        </ClientRoot>
      </body>
    </html>
  );
}

verfication 코드 넣어야하는 이유

• 사이트 전체 소유권 확인
• 하위 페이지 메타데이터에 중복 추가할 필요 없음
• Next.js에서는 루트 레이아웃의 메타데이터가 전체 사이트에 적용됨

이후 콘솔에 만든 사이트맵을 제출한다. 제출하는 이유는

• 구글 검색 엔진이 웹사이트의 모든 중요 페이지를 더 빠르고 정확하게 발견
• 수동으로 모든 페이지를 크롤링하는 시간 단축

필자는 sitemap.ts로 만들었지만 여기에서의 등록은 sitemap.xml로 해야한다. 그러면 nextjs가 알아서 ts확장자를 xml로 변환해준다.

이후 구글 서치 콘솔에 인덱싱이 될 때까지 기다린다. 며칠 ~ 몇 주 걸린다고 한다.

양자역학적인 현상을 쓴다? 0과 1이 동시에 존재한다..? 전자가 저기있을 수도 있고 여기 있을 수도 있다..? 그러나 관측하는순간 여기에 나타난다..?

이게 뭐고 뭐가 대단하길래 요즘 난리일까? 빠르게 알아보자.

양자 컴퓨터의 기본 개념

양자 컴퓨터는 양자역학적 현상을 활용하여 연산을 수행하는 새로운 패러다임의 컴퓨터이다. 일반 컴퓨터가 비트(0 또는 1)를 사용한다면, 양자 컴퓨터는 큐비트(quantum bit)를 사용하여 정보를 처리한다.

중첩 상태의 이해

양자역학에서는 전자가 동시에 여러 위치에 존재할 수 있는 특이한 현상이 있다. 이를 중첩 상태라고 한다.

'무슨 소리인가 1이면 1이고 0이면 0이지..' 싶을 때

종이 앞면에 새와 뒷면에 새장이 그려진 종이를 빠르게 회전시켰을 때 새와 새장이 동시에 존재하는 것처럼 보이는 상태와 비슷하다. 이걸 파바박 돌리면 밑에 그림처럼 보이는 상태

관측의 역설

중첩 상태의 특징은 관측하는 순간 하나의 상태로 "붕괴"한다는 것이다. 양자역학에서 관측이란 단순히 눈으로 보는 것이 아니라 물리적으로 부딪히는 것에 가까운 개념이다. 이는 회전하는 동전을 잡는 순간 반드시 한 면만 보이는 것과 같은 원리이다.

양자 컴퓨터의 연산 능력

양자 컴퓨터의 강력한 점은 동시 연산 능력이다. 예를 들어 10개의 비트로는 2¹⁰ = 1024가지 경우의 수가 가능한데, 일반 컴퓨터는 이를 하나씩 계산해야 한다. 반면 양자 컴퓨터는 10개의 큐비트로 1024가지 상태를 동시에 다룰 수 있다. 0과 1의 상태를 동시에 갖기 때문이다.

0과 1의 상태를 동시에 갖는데 왜 10개의 큐비트로 1024가지 상태를 동시에 다룰 수 있는 것인가 이해가 되지않는다면 =>큐비트는 단순히 0 또는 1을 담는 그릇이 아니라, '가능성'을 담는 그릇이라고 생각하면 쉬울 것 같다. 큐비트 N개를 모으면 2^N개의 모든 가능성을 동시에 담고 연산을 수행할 수 있는, 지수적으로 강력한 '가능성의 덩어리' 라고 생각해보자.

현실적 제약

당연히 현재 인프라로는 제약이 있다. 중첩 상태는 극도로 민감해서 먼지 하나라도 묻으면 안 되며, 관측하는(부딪히는) 순간 상태가 깨진다. 따라서 계산만 하고 그 안에서 최적의 결론을 찾아야 하며, 이 상태를 유지하기 위한 인프라 비용이 매우 크다. 온도도 낮아야하고 진공이어야 하고 등등.. 양자역학을 전공하시는 분들의 팟캐스트나 강연을 참고한 결과 현재의 인프라로 상용화되기에는 수지타산이 안맞는다고 한다.

현재 웹 보안에 대한 위협

요즘 양자컴퓨터 양자컴퓨터 말이 많은 이유가 바로 '이제 암호화 어떡하징?'에 대한 걱정 때문이다.

현재 웹 보안의 근간인 RSA 암호화를 예로 들어보자. 서버는 두 개의 소수를 선택한다. 53(비밀키)과 59(공개키)라고 가정하자. 이 두 수를 곱하면 3127이 된다. 서버는 59라는 공개키만 클라이언트에게 제공하고 53이라는 비밀키는 안전하게 보관한다.

이제 클라이언트가 중요한 정보를 서버로 전송하고 싶다면:

1. 공개키(59)와 n값(3127)을 사용해 데이터를 암호화한다
2. 암호화된 데이터를 서버로 전송한다
3. 서버는 자신만 알고 있는 비밀키(53)를 사용해 이 데이터를 복호화한다

실제로는 훨씬 더 큰 소수를 사용하기 때문에, 일반 컴퓨터로는 공개키만으로 비밀키를 찾아내는 것이 거의 불가능하다. n값을 소인수분해하여 비밀키를 찾으려면 수백 년이 걸리기 때문이다.

*하지만 양자 컴퓨터는 이야기가 다르다. 양자 컴퓨터는 모든 가능한 소인수를 동시에 계산할 수 있다. *

예를 들어 3127이라는 숫자의 소인수를 찾기 위해:

일반 컴퓨터: 2로 나눠보고, 3으로 나눠보고... 하나씩 시도
양자 컴퓨터: 모든 수로 동시에 나눗셈 시도 가능

즉, 양자 컴퓨터는 서버의 비밀키를 매우 빠른 시간 내에 찾아낼 수 있다는 것이다. 이는 현재 웹 보안의 기반을 흔들 수 있는 심각한 위협이 된다.

일반 컴퓨터: 가능한 모든 열쇠 조합을 하나씩 시도 → 수백 년 소요
양자 컴퓨터: 모든 조합을 동시에 시도 → 매우 빠른 시간 내 해결 가능

이것이 바로 새로운 암호화 방식, 특히 양자 내성 암호화(Post-Quantum Cryptography)가 필요한 이유이다. 양자 컴퓨터로도 풀 수 없는 새로운 수학적 문제를 기반으로 한 암호화 방식을 개발해야 한다. 무언가가 상용화 되기 위해서는 그에 대응할 수 있는 울타리가 만들어져야하는데 아마 비용과 이 문제가 양자컴퓨터의 상용화의 발목을 잡고 있지 않을까 싶다. _(개인적인 생각입니다.) _

웹 개발에 미치는 영향

필자는 웹 개발자를 꿈꾸는 새싹이기 때문에 이 글이 결론적으로 이러한 파도속에서 어떤 웹 개발자로 준비해야하는가로 끝나야 그림이 예쁠 것 같아 정리해본다.

웹 개발에서 렌더링은 CPU, GPU, RAM이 협력하여 웹 페이지를 화면에 그리는 과정이다.

하드웨어별 역할

• CPU: JavaScript 실행, DOM 조작

• GPU: 그래픽 처리, 애니메이션
• RAM: 임시 데이터 저장

_계산이 빠르게 되면 렌더링이 엄청 빨라지려나? 싶었지만 현재로서는 양자 컴퓨터가 웹 렌더링에 직접적인 영향을 미치지는 않는다고한다. _

왜?

렌더링과 양자컴퓨팅의 관계를 보면 알 수 있다.

• 렌더링의 특성:

- 순차적 처리가 필요한 작업이 많음
- 실시간 처리가 필요함
- 결과를 즉시 관찰해야 함

• 양자컴퓨터의 특성: ```
• 특정 종류의 병렬 계산에 강점
• 중간 관찰이 불가능
• 결과 관찰 시 상태가 무너짐
• 매우 불안정한 환경

웹 렌더링 과정:

1. HTML 파싱 → 2. CSS 계산 → 3. 레이아웃 계산 → 4. 페인팅
(각 단계가 이전 단계의 결과에 의존적)

양자컴퓨팅이 잘 하는 것:

독립적인 많은 계산을 동시에 처리
예) 1024개의 숫자를 동시에 더하기

여기서 집중!!

왜 렌더링에 적합하지 않은가:

1. 순차성

• 렌더링은 이전 단계의 결과를 보고 다음 작업을 결정해야 함
• 양자컴퓨터는 중간 결과 확인이 불가능

2. 실시간성

• 웹은 실시간 상호작용이 필요
• 양자컴퓨터는 결과 관찰에 제약이 있음

3. 안정성

• 렌더링은 지속적이고 안정적인 처리 필요
• 양자컴퓨터는 극도로 통제된 환경 필요

따라서 현재의 CPU, GPU가 렌더링에 더 적합한 구조를 가지고 있다. 양자컴퓨터는 암호화 해독이나 대규모 데이터 분석 같은 특수한 계산에 더 적합하다.

그렇다면 웹 개발자가 준비해야 할 역량

보안 관련 역량

• 양자 내성 암호화에 대한 이해
• 새로운 보안 프로토콜 학습
• 암호화 관련 최신 동향 파악(현실적으로는 이 방법이 양자시대 속 작은 무기를 갖추는데 도움이 될 것 같다.)

양자 컴퓨터 시대가 도래하더라도 계산하는 하드웨어가 바뀌는것이기때문에 웹 개발의 기본 원칙은 변하지 않을 것이라고 한다. 다만 보안과 암호화 분야에서 큰 변화가 예상되므로, 이에 대한 준비가 필요할 것 같다.

사실 클로저는 자바스크립트 고유의 개념이 아니다. 클로저의 정의가 ECMAScript사양에 등장하지 않는다.

MDN(신뢰할 수 있는 개발자 문서. 공식문서는 아님) 曰: “클로저는 함수와 그 함수가 선언된 렉시컬 환경과의 조합이다.”

하... 렉시컬은 또 무엇일까? 이왕 하는 김에 쉽고 빠르게 보고 오자. ⇒ 렉시컬 빠르게 집어넣기 클릭

클로저 이해를 돕기 위한 개념부터 슥

렉시컬 스코프 개념을 이해했다면 술술 읽힐겁니다.

함수는 '태어난 곳'과 '일하는 곳'이 다를 수 있다. 그래서 함수는 '일하는 곳'과 관계없이 자신이 '태어난 곳'의 환경을 기억해야 하는데, 이때 '태어난 곳'(정의 된 위치, 환경)이 바로 상위 스코프이다. => 기억해야 한다.

다시! 상위 스코프란?: 함수의 정의가 위치하는 스코프

이를 위해 함수는 자신의 내부슬롯[[Environment]]에 자신이 정의된 환경, 즉 상위 스코프의 참조를 저장한다.

함수의 [[Environment]]가 어떻게 상위 스코프를 결정하는지 보면:

• 상위 스코프 결정 시점
  • 함수 정의가 평가될 때(코드가 실행되기 전) 상위 스코프가 결정된다.
    • 이것이 바로 '렉시컬 스코프'.
    • [[Environment]]의 역할
    • 함수가 자신이 태어난(정의된) 환경을 기억하게 해준다.

예제 코드로 이해하기

자바스크립트 deep dive 24-04

const x = 1;

function foo() {
    const x = 10;
    bar();
}

function bar() {
    console.log(x);
}

• bar 함수는 전역에서 정의되었으므로 전역 스코프를 기억한다.

• 그래서 bar 함수가 어디서 호출되든 상관없이 전역의 x값인 1을 참조한다.
• foo 안에서 호출되어도 마찬가지이다.

즉, 함수의 상위 스코프는 함수를 어디서 호출하는지가 아니라, 함수를 어디서 정의했는지에 따라 결정된다. 이것이 바로 렉시컬 스코프의 핵심이다.

본격적으로 클로저하게 클로저 보기

이 코드하나 머리에 박아놓고 클로저하면 떠올리기

    function foo() {
        const x = 1;
        const y = 2;

        function bar() {
            console.log(x); // bar는 foo의 x에 접근 가능
        }
        return bar;
    }

    const bar = foo();  // foo를 실행하고 bar 함수를 반환받음
    bar();  // bar 실행

생명 주기 관점에서 보기

    function outer() {
        const name = "철수";  // 원래는 outer 함수 종료시 사라져야 할 변수

        function inner() {
            console.log(name);  // 하지만 inner가 name을 기억함
        }
        return inner;  // inner 함수 반환
    }

    const savedFunc = outer();  // outer는 실행 종료됨
    savedFunc();  // 여전히 "철수" 출력 가능!

• 보통의 경우: outer 함수가 끝나면 그 안의 변수들(name)은 사라져야 함

• 클로저의 경우: inner 함수가 name을 참조하고 있어서 사라지지 않고 유지됨

여기에서 의문이 들 수도 있다! (의문 없다면 pass)

“엥? outer() 함수는 일급객체로써 변수 savedFunc에 넣었기때문에 savedFunc(); 를 실행하면 outer(); 가 실행되니까 애초에 이 결과가 당연한거 아니야?” 라고 생각이 들었다면

그렇게 오해할 수 있지만 실제로는 다르게 작동한다.

        function outer() {
            const name = "박지성";

            function inner() {
                console.log(name);
            }
            return inner;  // inner 함수를 '반환'
        }

        // 여기서 잘 보면
        const savedFunc = outer();  // (1) outer 함수가 실행되고 inner 함수를 반환
        savedFunc();  // (2) 저장된 inner 함수를 실행

const savedFunc = outer()에서 일어나는 일:

1. outer 함수가 실행됨
2. inner 함수가 생성됨
3. inner 함수가 반환되어 savedFunc에 저장됨
4. outer 함수의 실행은 여기서 완전히 종료됨

savedFunc()에서 일어나는 일:

• 저장된 inner 함수가 실행됨
• outer 함수가 다시 실행되는 것이 아님!
• 이전에 저장된 inner 함수가 실행되는 것

다시 보자면

    // 이렇게 생각이 들 수 있는데
    const savedFunc = outer;  // outer 함수 자체를 저장
    savedFunc();  // outer 함수를 실행

    // 실제로는 이렇게 동작함
    const savedFunc = outer();  // outer()의 반환값(inner 함수)을 저장
    savedFunc();  // 저장된 inner 함수를 실행

비유하자면

• outer()는 "조리법"을 주는 게 아니라
• "이미 완성된 요리(inner 함수)"를 주는 것이다.
• 그래서 나중에 savedFunc를 실행할 때는 처음부터 다시 요리하는 게 아니라
• 이미 만들어진 요리(inner)를 사용한다.

"일찍 소멸된다"는 의미

    function foo() {
        const x = 1;
        const y = 2;

        // 케이스 1: 클로저가 모든 변수 유지
        function bar() {
            console.log(x, y);  // x와 y 모두 필요
        }

        // 케이스 2: 최적화된 클로저
        function optimizedBar() {
            console.log(x);  // x만 필요
            // y는 사용하지 않아서 메모리에서 일찍 제거됨
        }
    }

이게이게 자바스크립트 엔진의 최적화를 도와준다.

• optimizedBar는 x만 사용하므로 y는 메모리에서 제거
• • 불필요한 메모리 점유를 줄임

클로저 때문에 가능한 것들(많이 쓰이는 방법)

function counter() {
    let count = 0;  // 외부에서 직접 접근 불가능한 변수

    return {
        increase() { count++; },
        decrease() { count--; },
        getCount() { return count; }
    };
}

const myCounter = counter();
myCounter.increase();  // count는 private하게 보호됨
console.log(myCounter.getCount());  // 1

메모리 관점에서의 이해

function bigFunction() {
    const bigData = new Array(10000);  // 큰 데이터
    const smallData = "hello";         // 작은 데이터

    return function() {
        console.log(smallData);  // smallData만 사용
        // bigData는 사용하지 않으므로 메모리에서 제거됨
    };
}

• 최적화 전: bigData와 smallData 모두 메모리 유지

• 최적화 후: smallData만 메모리에 유지, bigData는 일찍 소멸

• 이렇게 클로저는 함수가 자신이 생성된 환경의 변수를 기억하되, 실제로 사용하는 변수만을 메모리에 유지하는 최적화된 방식으로 동작한다.
  • 메모리 효율성 & 코드의 캡슐화를 동시 달성!

결론

그래서 자바스크립트에서 클로저가 뭐냐고 물어보면 뭐라고 답해야하지..?!

• 함수와 그 함수가 선언될 당시의 lexical environment의 상호관계에 따른 현상.
• 내부함수가 외부함수의 생명 주기가 종료된 후에도 외부함수의 변수를 참조(이게 핵심)할 수 있는데, 이때 해당 변수들 중 내부함수가 실제로 사용하는 변수만을 선택적으로 기억하여 메모리 효율을 높임.

아니 그럼 렉시컬 스코프와 클로저가 뭐가 다른거지?

렉시껄 스코프는 "함수를 어디에 선언했는지"에 따라 상위 스코프를 결정하는 규칙이다.

    const x = 1;

    function foo() {
        const x = 10;
        bar();
    }
    function bar() {
        console.log(x); // 1
    }
    foo();

• bar가 전역에서 선언되었으므로 전역 스코프의 x를 참조

클로저는 이 렉시컬 스코프의 규칙을 기반으로, "이미 생명 주기가 끝난 외부 함수의 변수를 참조하는 현상"이다.

    function foo() {
        const x = 1;
        return function bar() {
            console.log(x); // 1
        }
    }

    const savedBar = foo(); // foo는 실행 종료
    savedBar(); // 하지만 여전히 x에 접근 가능

• foo 함수는 종료됐지만 반환된 bar가 x를 여전히 참조 가능

즉:

• 렉시컬 스코프: 상위 스코프를 결정하는 규칙
• 클로저: 이 규칙을 활용해 이미 종료된 함수의 변수를 참조하는 현상
• 클로저는 렉시컬 스코프라는 규칙이 있기에 가능한 현상이라고 볼 수 있다.

모던 자바스크립트 Deep Dive 예시코드 참고

자바스크립트에서 렉시컬 스코프는 "함수가 어디서 호출되는지"가 아니라 _"함수가 어디서 정의되었는지"_에 따라 상위 스코프가 결정되는 것을 말한다.

1. 함수의 위치에 따른 스코프 차이

먼저 첫 번째 코드를 보면:

const x = 1;

function outerFunc() {
  const x = 10;
  innerFunc();
}

function innerFunc() {
  console.log(x);
}

outerFunc(); // 출력결과: 1

이 코드에서 함수 innerFunc는 전역에서 정의되었다. 따라서 innerFunc의 상위 스코프는 전역이다. innerFunc가 outerFunc 내부에서 _호출_되더라도, innerFunc는 전역 변수 x의 값인 1을 출력한다.

2. 중첩 함수의 렉시컬 스코프

두 번째 코드를 살펴보면:

const x = 1;

function outerFunc() {
  const x = 10;
  const innerFunc = () => {
    console.log(x);
  }
  innerFunc();
}

outerFunc(); // 출력결과: 10

이번에는 innerFunc가 outerFunc 내부에서 정의되었다. 렉시컬 스코프의 규칙에 따라, innerFunc의 상위 스코프는 자신이 정의된 위치인 outerFunc의 스코프가 된다. 따라서 innerFunc는 outerFunc의 지역 변수 x값인 10을 참조한다.

3. 함수의 호출 위치와 렉시컬 스코프

마지막 예제를 보면:

const x = 1;

function foo() {
  const x = 10;
  bar();
}

function bar() {
  console.log(x);
}

foo(); // 출력: 1
bar(); // 출력: 1

이 예제에서 bar 함수는 전역에서 정의_되었다. bar가 foo 내부에서 호출되든, 전역에서 직접 호출되든 상관없이, bar의 _상위 스코프는 항상 전역 스코프이다. 따라서 두 경우 모두 전역 변수 x의 값인 1을 출력한다.

핵심 정리

렉시컬 스코프는 함수를 어디서 호출하는지가 아니라, 어디에 선언하는지에 따라 결정됨.

중첩 함수의 경우, 상위 스코프는 함수가 정의된 위치의 스코프가 됨.

전역에서 정의된 함수의 상위 스코프는 항상 전역 스코프.

결론

렉시컬 스코프란? 이라고 물어본다면 함수가 선언된 위치에 따라 상위 스코프가 결정되는 것! 이는 함수가 호출된 위치와는 무관하게 함수가 정의된 위치에서 상위 스코프가 고정적으로 결정됨!

JavaScript에서 "함수는 일급 객체이다"라는 개념을 설명하기 위해 작성.

javascript에서 다음과 같은 조건을 만족하는 객체를 일급 객체라 한다.

1. 무명의 리터럴로 생성할 수 있다. 즉, 런타임에 생성이 가능하다.
2. 변수나 자료구조(객체, 배열 등)에 저장할 수 있다.
3. 함수의 매개변수에 전달할 수 있다.
4. 함수의 반환값으로 사용할 수 있다.

뭔말인지 모르겠다면 여기를 먼저 보고 가기

무명의 리터럴이란?

이름이 없는 값을 직접 코드에 작성하는 것을 말한다. 예를 들어 let num = 5;에서 5가 무명의 리터럴이다. 리터럴을 딱 이렇게 생각해보자

const x = "이곳에 위치할 수 있다.";

const z = function() {};    // 함수 이름이 없기 때문에 무명의 리터럴이라고 하는것이다. 

여기서 또 잠깐.

런타임에 생성이란?

프로그램이 실제로 실행되는 시점에 만들어진다는 의미이다. 코드가 작성된 시점이 아니라, 실제로 그 코드가 실행되는 순간에 메모리에 생성된다. 아래 예시 코드에서 makeCounter 함수가 호출될 때마다 새로운 함수가 그 순간(런타임)에 생성되는 것을 말한다.

즉, 이름 없이 값을 직접 쓰고(무명의 리터럴), 그 값이 프로그램이 실행되는 순간에 만들어진다(런타임에 생성)는 의미이다.

이참에 다른 개념도 알아보기

컴파일 타임(Compile time)

컴파일 타임은 프로그램이 실행되기 전, 소스 코드가 기계어로 변환되는 시점을 말한다. 이때 생성되거나 결정되는 것들을 '컴파일 타임에 생성된다' 또는 '정적(static)으로 생성된다'고 표현한다.

컴파일 타임: 소스코드에 직접 작성된 상수, 클래스 정의 등 런타임: 사용자 입력에 따른 값, 함수 실행 결과 등

다시 '일급객체'로 돌아와서.

모던 자바스크립트 Deep Dive 18-01 예제 코드

// 1. 무명의 리터럴로 생성: 함수를 이름 없이 변수에 직접 할당
const increase = function (num) {
  return ++num;
}

const decrease = function (num) {
  return --num;
}

// 2. 자료구조(객체)에 저장: 함수를 객체의 프로퍼티로 저장
const auxs = { increase, decrease };

// 3. 함수의 매개변수로 전달: aux 매개변수로 함수를 전달받음
function makeCounter(aux) {
  let num = 0;

  // 4. 함수의 반환값으로 함수를 사용: 새로운 함수를 생성하여 반환
  return function () {
    num = aux(num); // 전달받은 함수(aux)를 실행
    return num;
  };
}

// makeCounter 함수에 increase 함수를 전달하여 새로운 함수 생성
const increaser = makeCounter(auxs.increase);
console.log(increaser()); // 1
console.log(increaser()); // 2

// makeCounter 함수에 decrease 함수를 전달하여 새로운 함수 생성
const decreaser = makeCounter(auxs.decrease);
console.log(decreaser()); // -1
console.log(decreaser()); // -2

결론

일급객체란? 이라고 물어본다면? 함수를 일반 객체처럼 변수에 할당할 수 있고, 다른 함수의 매개변수로 전달하거나 반환값으로 사용할 수 있으며, 객체의 프로퍼티로도 할당할 수 있는 성질!

JavaScript에서 "함수는 일급 객체이다" => 함수를 객체처럼 사용가능하다. 왜? 유연성과 재사용성을 위해!

개념 및 코드 참고: 모던 자바스크립트 Deep Dive

Vercel Serverless Function으로 Mixed Content 에러 해결하기

문제 상황

HTTPS로 배포된 React 애플리케이션에서 HTTP API(서울시 문화행사 정보)를 호출하려고 할 때 Mixed Content 에러가 발생한다. 하필 서울시 open api는 https 프로토콜을 제공하지 않기 때문에

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests

(https로 변환하는 방법) 위 방법도 안먹힌다.

// ❌ 직접 HTTP API를 호출하는 경우
fetch('http://openapi.seoul.go.kr:8088/API_KEY/json/culturalEventInfo/1/5/');
// Mixed Content 에러 발생!

원인

• 보안상의 이유로 브라우저는 HTTPS 페이지에서 HTTP 리소스를 직접 불러오는 것을 차단한다
• 사용자의 데이터를 보호하기 위한 보안 정책때문..

해결 방법

Vercel의 Serverless Function을 프록시로 사용하여 HTTP API 호출을 우회한다.

1. API 라우트 설정 (/api/events.js)

const axios = require('axios');

module.exports = async (req, res) => {
  try {
    // 서버 사이드에서 HTTP API 호출
    const API_KEY = process.env.REACT_APP_API_KEY;
    const response = await axios.get(
      `http://openapi.seoul.go.kr:8088/${API_KEY}/json/culturalEventInfo/1/5/`
    );

    // 응답 데이터 확인 및 반환
    if (!response.data.culturalEventInfo) {
      throw new Error(response.data.RESULT?.MESSAGE || 'API 호출 실패');
    }

    res.status(200).json(response.data);
  } catch (error) {
    console.error('Server Error:', error);
    res.status(500).json({
      error: true,
      message: error.message || 'Internal Server Error'
    });
  }
};

2. Vercel 설정 (vercel.json) (netlify도 당연히 가능함. 경로나 파일명만 살짝 달리해야함.)

{
  "version": 2,
  "rewrites": [
    {
      "source": "/api/:path*",
      "destination": "/api/:path*"
    }
  ]
}

3. React 컴포넌트에서 API 호출(App.js 일부)

const fetchEvents = async () => {
  try {
    // ✅ HTTPS로 제공되는 Vercel Function 호출
    const response = await fetch('/api/events');
    const data = await response.json();

    if (data.error) {
      throw new Error(data.message);
    }

    setEvents(data.culturalEventInfo.row || []);
  } catch (err) {
    console.error('Error details:', err);
    setError(err.message);
  }
};

전체 App.js 코드

import { useState, useEffect } from 'react';
import './App.css';

function App() {
  const [events, setEvents] = useState([]);
  const [error, setError] = useState(null);

  useEffect(() => {
    const fetchEvents = async () => {
      try {
        const response = await fetch('/api/events');
        console.log('Response status:', response.status);

        const data = await response.json();
        console.log('Response data:', data);

        if (data.error) {
          throw new Error(data.message);
        }

        setEvents(data.culturalEventInfo.row || []);
      } catch (err) {
        console.error('Error details:', err);
        setError(err.message);
      }
    };

    fetchEvents();
  }, []);

  if (error) {
    return <div>에러 발생: {error}</div>;
  }

  return (
    <div className="App">
      <h1>서울시 문화행사 정보</h1>
      {events.length === 0 ? (
        <p>로딩중...</p>
      ) : (
        <ul>
          {events.map((event, index) => (
            <li key={index} style={{marginBottom: '20px', textAlign: 'left'}}>
              <h3>{event.TITLE}</h3>
              <p>분류: {event.CODENAME}</p>
              <p>장소: {event.PLACE}</p>
              <p>날짜: {event.DATE}</p>
              <p>요금: {event.USE_FEE}</p>
              {event.MAIN_IMG && (
                <img 
                  src={event.MAIN_IMG}
                  alt={event.TITLE}
                  style={{maxWidth: '200px'}}
                />
              )}
            </li>
          ))}
        </ul>
      )}
    </div>
  );
}

export default App;

작동 원리

1. 브라우저가 안전한 HTTPS 연결을 통해 Vercel Serverless Function을 호출한다.
2. Serverless Function이 서버 사이드에서 HTTP API를 호출한다.
3. 받아온 데이터를 다시 HTTPS를 통해 브라우저로 전달한다.

[브라우저] → HTTPS → [Vercel Function] → HTTP → [서울시 API]

브라우저: "물건이 왔는데 가져오기 무서워요.. Vercel Function님 대신 가져와주세요ㅎ" (브라우저가 Vercel Function에 HTTPS로 요청)

Vercel Function: 응 알겠어. 나는 브라우저가 아니라 서버라서 http/https 모두 가져올 수 있어. (Vercel이 서버에서 HTTP API 호출)

Vercel Function: 자 받아. 가져왔어. (Vercel이 데이터를 HTTPS로 브라우저에 전달)

구현 순서

1. /api/events.js 파일 생성 및 서버리스 함수 구현
2. vercel.json 설정으로 API 라우트 경로 매핑
3. React 컴포넌트에서 API 호출 코드 수정
4. Vercel 환경변수 설정 (REACT_APP_API_KEY)
5. 배포 및 테스트

주의사항

• 환경변수는 반드시 Vercel 대시보드에서도 설정해야 함.
• 로컬 개발 환경에서는 .env.local 파일에 환경변수를 설정.
• API 응답의 에러 처리를 반드시 구현해야 디버깅 편함

이렇게 Vercel Serverless Function을 활용하면 Mixed Content 에러를 해결하면서도 보안을 유지할 수 있다! 이것이 바로 서버리스 아키텍처라고 한다. 엥? vercel 서버를 사용하는데 왜 서버less 지? => 내가 서버 관리안하고 vercel서비스가 서버 관리를 해주므로 서버리스라고 하는 것이다.

미들웨어 프록시란?

프록시는 클라이언트(브라우저)와 서버 사이에 중계 역할을 하는 서버입니다. 클라이언트가 특정 서버에 직접 요청을 보내지 않고, 중간에 위치한 프록시 서버가 요청을 대신 전달하고 그 응답을 다시 클라이언트로 보내는 방식입니다.

미들웨어 프록시는 개발 환경에서 자주 사용되며, 개발 중 클라이언트와 외부 API 간의 요청을 중계하여 발생할 수 있는 CORS(Cross-Origin Resource Sharing) 문제를 우회할 수 있도록 도와줍니다.

왜 미들웨어 프록시가 필요한가?

React 같은 싱글 페이지 애플리케이션(SPA)을 개발할 때, 클라이언트 측에서 외부 API로 요청을 보낼 때 CORS 정책에 의해 브라우저에서 차단될 수 있습니다. 브라우저는 동일 출처 정책(Same-Origin Policy)을 따르기 때문에, 클라이언트가 다른 도메인에 직접적으로 요청을 보내는 것을 허용하지 않습니다. 이 문제를 해결하기 위해 개발 환경에서는 프록시 미들웨어를 사용합니다.

개발 환경 http://localhost:3000 브라우저'에서' 외부 API 요청'을'차단하는 겁니다.

미들웨어 프록시 사용법 (React와 http-proxy-middleware)

React에서 개발 환경에서만 동작하는 미들웨어 프록시는 http-proxy-middleware 라이브러리를 사용해 설정할 수 있습니다. 이 미들웨어는 주로 create-react-app 환경에서 사용되며, 로컬 개발 서버(webpack-dev-server)에서 동작합니다.

http-proxy-middleware 설정 방법

1. 설치

먼저 http-proxy-middleware 라이브러리를 프로젝트에 설치합니다:

npm install http-proxy-middleware --save

2. setupProxy.js 파일 생성

src/ 디렉토리에 setupProxy.js 파일을 생성합니다. 이 파일에 프록시 설정을 추가합니다. 예를 들어, 클라이언트에서 /api로 시작하는 모든 요청을 외부 API 서버로 프록시하려면 다음과 같은 설정을 사용할 수 있습니다:

const { createProxyMiddleware } = require('http-proxy-middleware');

module.exports = function(app) {
  app.use(
    '/api',
    createProxyMiddleware({
      target: 'https://api.example.com', // 외부 API 서버의 주소
      changeOrigin: true, // 서버의 origin을 변경
      pathRewrite: {
        '^/api': '', // /api로 시작하는 경로를 빈 문자열로 바꿈
      },
    })
  );
};

이 설정은 다음과 같은 역할을 합니다:

• /api 경로로 들어오는 모든 요청을 https://api.example.com으로 프록시합니다.
• pathRewrite 설정을 통해 /api 부분을 제거하고 실제 API 서버로 요청을 보냅니다.

3. 프록시 동작 과정

클라이언트가 http://localhost:3000/api/some-endpoint로 요청을 보낼 경우, 이 요청은 미들웨어 프록시에 의해 https://api.example.com/some-endpoint로 전달됩니다. 클라이언트는 이 과정을 인식하지 못하고, 응답만 받게 됩니다.

주의사항: 배포 환경에서의 프록시

중요한 점은 이 미들웨어 프록시는 개발 환경에서만 동작한다는 것입니다. create-react-app으로 시작한 개발 서버(webpack-dev-server)가 실행될 때만 프록시가 활성화됩니다. 하지만 배포된 환경에서는 이 미들웨어가 동작하지 않습니다.

왜 배포 환경에서는 동작하지 않는가?

• 정적 파일로 배포: React 애플리케이션이 배포되면, 일반적으로 Vercel, Netlify, GitHub Pages와 같은 플랫폼에서 정적 파일로 제공됩니다. 이때 프론트엔드 애플리케이션은 webpack-dev-server 같은 Node.js 서버를 사용하지 않으며, 단지 정적 파일(HTML, CSS, JavaScript)로만 제공됩니다. 따라서 setupProxy.js에 설정된 프록시 미들웨어는 더 이상 작동하지 않습니다.
• CORS 문제: 배포 환경에서는 클라이언트에서 API 서버로 직접 요청을 보내기 때문에 다시 CORS 문제가 발생할 수 있습니다. 이 문제를 해결하려면 배포 환경에서도 CORS를 허용할 수 있는 백엔드 서버가 필요하거나, 외부 API가 CORS 요청을 허용해야 합니다.

배포 환경에서의 해결 방법

1. API 요청을 직접 HTTPS로 보내기: 배포된 애플리케이션은 보안(HTTPS)으로 제공되므로, API 요청도 HTTPS로 보내야 합니다. 만약 API 서버가 HTTPS를 지원하면, 클라이언트에서 직접 HTTPS로 요청을 보내어 CORS 문제를 피할 수 있습니다.

   엥간~한 openAPI서버들은 HTTPS를 지원하기때문에 기존 http로 보냈던 API를 https로 바꿔주면 됩니다.

2. 백엔드 서버 설정: 백엔드 서버가 있다면, 클라이언트가 외부 API로 직접 요청을 보내는 대신 백엔드 서버로 요청을 보내게 하고, 백엔드가 외부 API에 요청한 결과를 클라이언트로 전달하도록 설정할 수 있습니다. 이 방식은 클라이언트와 외부 API 간의 CORS 문제를 우회할 수 있는 좋은 방법입니다.

3. 서버리스 함수(Serverless Function) 사용: Vercel이나 Netlify와 같은 호스팅 플랫폼에서는 서버리스 함수(예: AWS Lambda)로 API 요청을 중계할 수 있습니다. 클라이언트가 서버리스 함수로 요청을 보내면, 이 함수가 외부 API로 요청을 보내고, 응답을 다시 클라이언트로 전달합니다. 이를 통해 CORS 문제를 해결할 수 있습니다.

예시: 서버리스 함수 사용

Vercel에서는 서버리스 함수를 쉽게 설정할 수 있습니다. 예를 들어, Vercel에서 API 요청을 처리하는 서버리스 함수는 다음과 같습니다:

// api/proxy.js

export default async function handler(req, res) {
  const response = await fetch('https://api.example.com/some-endpoint');
  const data = await response.json();
  res.status(200).json(data);
}

클라이언트는 /api/proxy 경로로 요청을 보내면, Vercel 서버리스 함수가 외부 API에 요청을 보내고, 응답을 전달합니다. 이 방법은 배포 환경에서도 CORS 문제를 해결할 수 있습니다.

결론

• 미들웨어 프록시는 개발 환경에서 CORS 문제를 해결하고, 클라이언트와 외부 API 간의 요청을 중계하는 역할을 합니다. 하지만 이는 배포 환경에서는 동작하지 않기 때문에 클라이언트에서 직접 HTTPS로 API 요청을 보내거나 백엔드 서버를 이용해 요청을 중계해야 합니다.
• 배포 환경에서는 백엔드 서버 또는 서버리스 함수가 이러한 역할을 대신하여 CORS 문제를 해결하고, 클라이언트가 안정적으로 API와 통신할 수 있도록 도와줍니다.

요약

• 미들웨어를 통해 프록시 역할을 수행하도록 코드를 작성한다!
• http-proxy-middleware 같은 라이브러리는 미들웨어 코드로서 프록시 기능을 구현한다!
• 이 경우 미들웨어가 프록시 서버 역할을 간접적으로 수행한다!
• 클라이언트가 서버에 요청을 보내면, 미들웨어가 그 요청을 가로챈다!
• 미들웨어는 요청을 처리하고, 다른 서버로 전달하는 역할(프록시 역할)을 한다!
• 해당 서버의 응답을 다시 받아서 클라이언트에게 반환한다!

프론트엔드 개발자에게 있어 코드의 품질과 일관성을 유지하는 것은 매우 중요합니다. 특히, 현업에서는 혼자 프로젝트를 진행하는 경우가 거의 없다는 것은 학부생도 알고 있는 사실이죠. 팀 단위로 프로젝트를 진행할 때, 모든 팀원이 동일한 코드 스타일을 따르는 것은 유지보수성과 가독성을 높이는 핵심 요소이자 배려이자 개념이자 기본 소양입니다.

이러한 상황에서 강력한 도구가 바로 ESLint이며, 그 중심에는 프로젝트의 .eslintrc.json 설정 파일이 있습니다.

왜 .eslintrc.json을 사용해야 하는가?

1. 코드 품질 유지

.eslintrc.json 파일은 프로젝트의 ESLint 설정을 정의하는 파일입니다. ESLint는 코드 품질을 자동으로 검사해주고, 일관되지 않은 코드 스타일이나 잠재적인 에러를 발견할 수 있습니다. 이 파일은 팀 내에서 일관된 코드 스타일을 유지하는 데 매우 중요한 역할을 합니다. 이를 통해 개발자는 팀원들 간에 서로 다른 코드 스타일로 인해 발생하는 불필요한 충돌을 줄일 수 있습니다.

2. 버그 예방

규칙 기반의 ESLint 설정은 잠재적인 버그를 미리 찾아낼 수 있도록 돕습니다. 예를 들어, 변수 선언 후 사용하지 않았거나, 올바르지 않은 비교 연산자를 사용한 경우 경고 메시지를 통해 버그 발생을 예방할 수 있습니다. 이는 사소해 보이지만, 시간이 지남에 따라 큰 문제로 발전할 수 있는 버그들을 조기에 잡아내는 데 매우 유용합니다.

3. 일관된 코드 스타일

팀이 커질수록 코드 스타일의 통일성은 점점 더 중요해집니다. 프로젝트 초기부터 ESLint 설정을 확립해놓으면, 팀원들이 동일한 코드 스타일 규칙을 따르게 되어 리뷰 시간도 단축되고, 코드 가독성도 높아집니다. ESLint는 코딩 컨벤션을 강제할 수 있는 다양한 플러그인과 규칙을 제공합니다. 예를 들어, 세미콜론 사용 여부, 들여쓰기 스타일, 함수의 선언 방식 등 일관된 스타일을 유지하는 데 도움을 줍니다.

좀 더 직관적이게 예시로 보여드리겠습니다.

ESLint 설정 (.eslintrc.json)

{
  "env": {
    "browser": true,
    "es2021": true
  },
  "extends": [
    "eslint:recommended",
    "plugin:react/recommended",
    "airbnb",
    "prettier"
  ],
  "parserOptions": {
    "ecmaFeatures": {
      "jsx": true
    },
    "ecmaVersion": 12,
    "sourceType": "module"
  },
  "rules": {
    "semi": ["error", "always"],        // 세미콜론을 항상 사용
    "quotes": ["error", "single"],      // 문자열을 항상 single quote로 사용
    "indent": ["error", 2],             // 들여쓰기를 2칸으로 강제
    "react/jsx-indent": ["error", 2],   // JSX 들여쓰기를 2칸으로 강제
    "react/prop-types": "off"           // PropTypes 사용을 끔 (TypeScript 대체)
  }
}

ESLint 규칙 설명

• semi: ["error", "always"]: 세미콜론을 항상 붙이도록 강제.
• quotes: ["error", "single"]: 문자열은 항상 '(single quote)로 작성하도록 강제.
• indent: ["error", 2]: 들여쓰기를 2칸으로 고정.
• react/jsx-indent: ["error", 2]: JSX에서도 들여쓰기를 2칸으로 고정.
• react/prop-types: "off": PropTypes를 사용하지 않도록 하고, 대신 TypeScript를 사용하는 경우를 대비.

코드 예시

1. 잘못된 코드 (ESLint 규칙 위반)

import React from "react"

function MyComponent(props) {
 return (
  <div>
    <h1>Hello, {props.name}</h1>
    <p>This is my component</p>
  </div>
 )
}

• 문제점:
  • 세미콜론이 누락됨 (semi 규칙 위반).
  • 들여쓰기가 4칸으로 되어 있음 (indent 규칙 위반).
  • 문자열이 더블 쿼트로 되어 있음 (quotes 규칙 위반).

2. ESLint가 자동으로 수정한 코드 (규칙 적용)

import React from 'react';  // single quotes and semicolon

function MyComponent(props) {  // indent fixed
  return (
    <div>
      <h1>Hello, {props.name}</h1>
      <p>This is my component</p>
    </div>
  );  // semicolon added
}

• 수정 사항:
  • 세미콜론이 추가됨.
  • 들여쓰기가 4칸에서 2칸으로 변경됨.
  • 문자열이 더블 쿼트에서 싱글 쿼트로 변경됨.

이제 뭔가 느낌이 오시죠? 많이 쓰이는 플러그인 Prettier와 비슷한 느낌이 있습니다.

4. 협업에 준비된 개발자로서의 필수 요소

함께 개발할 준비가된 개발자라면 .eslintrc.json 파일의 중요성을 이해하고 프로젝트에서 이를 적극적으로 사용해야 합니다! 내가 만든 음식이 아무리 맛있어도 플레이팅이 개판이면 내 정성을 몰라주는건 당연합니다.

기술 면접에서 나올 수 있는 질문들

기술 면접에서 ESLint와 .eslintrc.json 설정 파일에 대해 질문이 자주 나온다고 합니다(제가 이 글을 쓰게된 이유입니다). 면접관은 당신이 얼마나 협업을 고려한 개발을 하고 있는지, 코드 품질 관리에 신경을 쓰고 있는지를 확인하려 할 것입니다. => 실력만큼 협업할 준비가 되었는지에 대한 역량도 당연히 중요하겠죠?

1. ESLint란 무엇인가요?

• ESLint는 JavaScript 코드의 품질을 분석하고 오류를 찾아내는 도구입니다. 코드 스타일을 통일하고 잠재적인 오류를 사전에 방지하기 위해 사용됩니다. (여기서 만약 "ESLint는 ES(Ecma Script)와 Lint를 합친 것으로, (Ecma라는 기구에서 만든 Script가 표준 Javascript이기 때문에) 자바스크립트 코드의 에러를 표시해 줍니다. 아, Lint는 Linter의 약자로 에러가 있는 코드에 표시를 달아주는것을 뜻합니다." 까지 말한다면 바라보는 눈빛이 달라지겠네요.)

2. 프로젝트에서 .eslintrc.json 파일을 사용하는 이유는 무엇인가요?

• .eslintrc.json 파일은 프로젝트의 코드 스타일 규칙과 오류 탐지 규칙을 설정하는 곳입니다. 이를 통해 팀원들이 일관된 코드 스타일을 유지하고, 코드에서 발생할 수 있는 잠재적 오류를 미리 잡아낼 수 있습니다.

3. ESLint와 Prettier의 차이점은 무엇인가요?

• ESLint는 주로 코드의 품질과 오류를 검사하는 도구이며, Prettier는 코드의 포매팅(형식화)을 위한 도구입니다. 두 도구는 서로 보완적으로 사용될 수 있습니다. ESLint는 예를 들어 변수를 사용하지 않는 것 같은 논리적 오류를 찾아내고, Prettier는 코드의 들여쓰기나 세미콜론 위치 같은 포매팅을 자동화합니다.

4. ESLint 설정을 어떻게 관리하나요?

• 일반적으로 .eslintrc.json 파일을 루트 디렉토리에 두고, 프로젝트 전반에 걸친 코드 스타일과 규칙을 정의합니다. 추가로 프로젝트의 상황에 따라 eslint-plugin-react, eslint-plugin-import와 같은 플러그인들을 사용하여 더 구체적인 규칙을 설정할 수 있습니다.

5. ESLint를 CI/CD 파이프라인에 통합할 수 있나요?

• 네, ESLint를 CI/CD 파이프라인에 통합하면 자동으로 코드 품질을 체크할 수 있습니다. 코드를 푸시하거나 풀 리퀘스트를 생성할 때 자동으로 ESLint 규칙이 적용되어 코드 품질을 보장할 수 있습니다.

결론

협업할 준비가 되어있는 프론트엔드 개발자라면 ESLint와 .eslintrc.json 파일은 필수 도구!

_mockapi를 사용법에 포커스를 맞춘 오픈소스 스튜디오(Open Source Studio) 02분반 실습용 참고자료입니다. _

시작하기

무료버전 사용하시면 됩니다. 클릭! => mockapi 사이트 접속 'Get started' 버튼 눌러주세요.

회원가입(저는 깃허브 sign in 했습니다.)

• 로그인 후 프로젝트 폴더로 이동됩니다. 무료버전은 계정 당 프로젝트 1개까지 생성가능합니다.
• 알맞은 프로젝트 이름으로 하나 생성해주세요. (사진을 보시면 저는 OSS_Example로 미리 만들었습니다.)
• 프로젝트 생성 후 클릭하여 이동해주세요

• 보시면 자동으로 API 앤드포인트가 생성됩니다.

• 무료버전은 이 API 앤드포인트하나로 간단한 CRUD가 가능합니다.

  짚고 넘어가기(미리 알아두면 좋습니다. 귀찮으시면 넘어가셔도 문제는 없습니다.)

• 저는 앤드포인트에서 'api'(보라색부분)을 prefix로 추가했습니다.

• • 엔드포인트에 api를 붙이는 이유는 사용자가 보는 웹페이지와 서버에 데이터를 요청하는 API를 쉽게 구분하려고 하기 위함입니다. 이렇게 하면 코드가 더 명확해지고, 어떤 주소가 API 요청인지 알기 쉬워집니다.
• • • 예를 들어보겠습니다: 사용자가 글 목록을 보는 페이지 주소는 handong.com/posts라고 가정해봅시다. 그럼 당연히 서버에서 글 목록 데이터를 가져오는 API 주소도 필요합니다. 이때 handong.com/api/posts처럼 api를 붙이면 이 주소는 데이터를 가져오는 API임을 명확히 알 수 있습니다. 이렇게 하면:
    • example.com/posts*: 사용자에게 보여주는 웹페이지.
    • example.com/api/posts*: 서버에서 데이터를 받아오는 API. 이런 식으로 두 가지를 쉽게 구분할 수 있습니다.

  ---

  아주 간단하게 Resource(Entity) 만들기

  여기에서 resource는 Entity를 의미합니다.

• 엥? Entity가 뭐징?

• • Entity는 데이터베이스에서 객체지향적으로 테이블을 표현한 용어입니다.
• • 자바에서 Object느낌입니다.
• • 저는 게시판을 만들었기때문에 Board라는 이름으로 게시판 Entity를 생성했고, 그 안에는 제목, 내용, 작성자, 생성날짜, 수정날짜 등이 속성으로 들어갑니다.

• 일단 new resouce 클릭
• Resource name 입력: 만들고자 하시는 직관적인 테이블 이름으로 지어주세요. (영어로만 입력가능합니다.)
• Schema 생성:: 저는 게시판 엔티티를 만들고자 했기 때문에 사진과 같이 생성날짜, 수정날짜, 제목, 내용 등을 추가했습니다.
• • 여기에서 자동으로 있는 id는 pk로 사용되기 때문에 냅두시고 따로 pk추가 안하셔도 됩니다.
• • 데이터 타입은 맨 오른쪽(날짜 => date.recent) 타입에서 만드시고자하는 속성에 맞는 타입 찾아서 선택하시면 됩니다.
• • 이 이상 건들게 없습니다. 바로 Create 눌러주세요.

이렇게 resource 생성되면 다 끝난겁니다. resource는 무료버전에서 최대 2개까지 생성가능합니다. 삭제하고 다시만들기 가능합니다.

• 파란색 progress 바를 보시면 저는 28입니다. 이건 이 resource안에 데이터가 28개 들어있다는 의미입니다.
• progress 바에 커서 올리시고 원하는 수치를 클릭하면 자동랜덤으로 데이터 생성됩니다. 만들어보시고 삭제도 해보세요. 이제 이 api만 어디에 복사하시거나 창 열어두시고 개발준비 하시면 됩니다.

api사용해서 crud 테스트 해보기

지금부터 아까만든 api사용법을 코드안에 주석으로 설명하겠습니다. _이 글에서는 mockapi에서 생성한 api를 어떻게 쓰는지만 다루겠습니다. _

GET

const Home = () => {
  const [posts, setPosts] = useState([]);
  const [openUpdateModal, setOpenUpdateModal] = useState(false);
  const [openCreateModal, setOpenCreateModal] = useState(false);
  const [selectedPost, setSelectedPost] = useState(null);

  const fetchData = async () => {
    // 일단 이 부분만 보시면 됩니다.
    const response = await axios.get(
      // http method로 GET을 사용하고 
      // 아까 복사하신 'api + 만드신 resource 이름' 넣으시면 됩니다.
      "https://66fa7fb3afc569e13a9bfcce.mockapi.io/api/BoardEntity"
    );
    setPosts(response.data);
  };
  ...

• 여기에서 :endpoint 를 만드신 리소스 명으로 넣어주시면 됩니다.
• 코드보시면 저는 리소스이름이 BoardEntity라서 https://66fa7fb3afc569e13a9bfcce.mockapi.io/api/BoardEntity입니다.

POST(Create)

  const handleCreate = async (values) => {
    try {
      // 여기를 보시면 됩니다.
      await axios.post(
        "https://66fa7fb3afc569e13a9bfcce.mockapi.io/api/BoardEntity",
        {
          ...values,
          createdAt: new Date().toISOString(),
          modifiedAt: new Date().toISOString(),
        }
      );
      form.resetFields();
      onClose();
    } catch (error) {
      console.error("글 작성 중 오류 발생:", error);
    }
  };

• post는 api url이 get과 동일하고 http method를 get -> post로 바꾸고 body만 추가하면 됩니다.

UPDATE(mockapi 사용시 patch말고 put을 사용하셔야합니다.)

  const handleUpdate = async () => {
    try {
      const values = await form.validateFields();
      // 여기를 보시면 됩니다.
      await axios.put(
        `https://66fa7fb3afc569e13a9bfcce.mockapi.io/api/BoardEntity/${board.id}`,
        {
          ...values,
          modifiedAt: new Date().toISOString(),
        }
      );
      form.resetFields();
      onClose();
    } catch (error) {
      console.error("글 수정 중 오류 발생:", error);
    }
  };

• 다를거 없습니다. 아까 pk로 자동생성된다던 id를 앤드포인트 끝에 넣어주시면 해당 아이디의 글이 수정요청됩니다.

DELETE

  const handleDeletePost = async (postId) => {
    try {
      // 여기를 보시면 됩니다.
      await axios.delete(
        `https://66fa7fb3afc569e13a9bfcce.mockapi.io/api/BoardEntity/${postId}`
      );
      fetchData();
    } catch (error) {
      console.error("글 삭제 중 오류 발생:", error);
    }
  };

• http method를 delete로 하시고 update처럼 id를 앤드포인트 끝에 넣어주시면 해당 아이디의 글이 삭제요청됩니다.

깃허브 repo 이동 demo사이트 이동

배포된 사이트와 GitHub 저장소를 꼭 참고해주시기 바랍니다. 이 프로젝트는 MockAPI 생성 및 간단한 사용법을 시연하는 데 목적이 있기 때문에, 컴포넌트를 세부적으로 나누지 않고 단순하게 작성했습니다. 따라서, 이 코드 자체는 최적화된 예제는 아니며, API 사용법을 중심으로 참고해 주시면 감사하겠습니다.

GitHub보시고 React 관련 세부 사항이나 궁금한 점이 있으시면, 언제든지 질문해 주세요. 수업 시간이나 TA 세션외에도 메일주시면 답변드리겠습니다.

글 좋아요 및 팔로우 해주시면 복 받으실겁니다.

2.2.1 Overview of HTTP

HTTP(HyperText Transfer Protocol)은 웹의 핵심이 되는 애플리케이션 계층 프로토콜이다.

왜 HyperText일까?

HyperText: HTTP는 HyperText를 전송하기 위해 만들어진 프로토콜이이다.

HyperText는 단순한 텍스트가 아니라, 링크를 통해 다른 문서나 리소스로 쉽게 이동할 수 있는 텍스트를 말한다.

클라이언트 프로그램과 서버 프로그램은 HTTP 메시지를 서로 교환하는 방식으로 동작한다. 여기서 클라이언트는 웹 브라우저(예: 크롬, 인터넷 익스플로러)이고, 서버는 웹 서버(예: 아파치, 마이크로소프트 IIS)이다.

웹 페이지는 여러 개의 객체들로 구성된다.

객체는 HTML 파일, 이미지 파일(JPEG), 자바스크립트 파일, CSS 파일 등과 같이 하나의 URL로 접근할 수 있는 모든 파일이다. 일반적으로 웹 페이지는 하나의 기본 HTML 파일과 그 안에 참조된 여러 객체들로 이뤄져 있다. 예를 들어, 하나의 웹 페이지에 HTML 텍스트와 5개의 JPEG 이미지가 있다면, 총 6개의 객체를 가진 것이다.

HTTP는 웹 클라이언트가 서버에 웹 페이지를 요청하고 서버가 그 요청에 응답하는 방식을 정해준다. Figure 2.6을 보면, 클라이언트(PC나 스마트폰)가 서버에 HTTP 요청을 보내고, 서버는 이에 대해 HTTP 응답을 보내는 과정이 나타나 있다.

이때, HTTP는 전송 계층 프로토콜로 TCP를 사용한다.

클라이언트와 서버 간에 TCP 연결이 먼저 이루어지고, 그 위에서 HTTP 요청과 응답이 오간다.

중요한 점은 HTTP는 '무상태 프로토콜(stateless)'이라는 것이다.

서버는 클라이언트에 대한 정보를 저장하지 않는다. 예를 들어, 클라이언트가 같은 객체를 몇 초 간격으로 두 번 요청하더라도, 서버는 이전 요청을 기억하지 않고 동일한 객체를 다시 전송한다.

HTTP에는 여러 버전이 있는데, 초기 버전인 HTTP/1.0은 1990년대에 도입되었다. 현재는 HTTP/1.1이 주로 사용되지만, 최근에는 HTTP/2도 많이 도입되고 있다.

2.2.2 Non-Persistent and Persistent Connections

많은 인터넷 애플리케이션에서 클라이언트와 서버는 오랜 기간 동안 통신하며, 클라이언트가 일련의 요청을 보내고 서버가 각 요청에 응답하는 경우가 많다. 애플리케이션과 그 사용 방식에 따라, 이 일련의 요청들은 연달아, 주기적으로, 또는 간헐적으로 이루어질 수 있다. 이러한 클라이언트-서버 상호 작용이 TCP를 통해 이루어질 때, 애플리케이션 개발자는 중요한 결정을 내려야 한다.

각 요청/응답 쌍을 별도의 TCP 연결로 보낼 것인가, 아니면 모든 요청과 해당 응답들을 동일한 TCP 연결로 보낼 것인가?

전자의 경우, 애플리케이션은 비지속 연결을 사용한다고 하며, 후자의 경우는 지속 연결을 사용한다고 한다. 이 설계 문제를 깊이 이해하기 위해, 비지속 연결과 지속 연결의 장단점을 HTTP라는 특정 애플리케이션을 통해 살펴보자. HTTP는 비지속 연결과 지속 연결 모두를 사용할 수 있다. 기본 모드에서는 지속 연결을 사용하지만, HTTP 클라이언트와 서버는 비지속 연결을 사용하도록 구성될 수 있다.

비지속 연결을 사용하는 HTTP

비지속 연결을 사용하는 경우 서버에서 클라이언트로 웹 페이지를 전송하는 과정을 단계별로 살펴보자. 여기서는 페이지가 기본 HTML 파일과 10개의 JPEG 이미지로 구성되어 있으며, 이 11개의 객체가 모두 동일한 서버에 있다고 가정한다. 또한, 기본 HTML 파일의 URL은

http://www.someSchool.edu/someDepartment/home.index

라고 가정해보자. 이때 일어나는 과정은 다음과 같다.

1. HTTP 클라이언트 프로세스는 서버 www.someSchool.edu의 80번 포트로 TCP 연결을 시작한다. 이 TCP 연결과 관련된 소켓이 클라이언트와 서버에 각각 생성된다.

2. HTTP 클라이언트는 이 소켓을 통해 서버로 HTTP 요청 메시지를 보낸다. 요청 메시지에는 경로 이름 /someDepartment/home.index가 포함된다.

3. HTTP 서버 프로세스는 이 소켓을 통해 요청 메시지를 수신하고, 스토리지(RAM 또는 디스크)에서 /someDepartment/home.index 객체를 가져와 HTTP 응답 메시지에 캡슐화한다. 그런 다음 이 응답 메시지를 소켓을 통해 클라이언트로 전송한다.

4. HTTP 서버 프로세스는 TCP에 연결을 닫으라고 알린다.

   하지만 TCP는 클라이언트가 응답 메시지를 정확히 수신했는지 확신할 때까지 실제로 연결을 종료하지 않는다.

5. HTTP 클라이언트는 응답 메시지를 수신한다. 이때 TCP 연결이 종료된다. 메시지에는 캡슐화된 객체가 HTML 파일이라는 내용이 포함되어 있다. 클라이언트는 응답 메시지에서 파일을 추출하고, HTML 파일을 분석하여 10개의 JPEG 객체에 대한 참조를 찾는다.

6. 앞의 1~4단계를 참조된 각 JPEG 객체에 대해 반복한다.

위의 과정에서 브라우저는 웹 페이지를 수신하면서 이를 사용자에게 보여준다.

위 단계들은 비지속 연결을 사용한 예를 보여준다.

여기서 각 TCP 연결은 서버가 객체를 전송한 후에는 다른 객체를 위해 유지되지 않는다.

HTTP/1.0은 비지속 TCP 연결을 사용한다. 각 비지속 TCP 연결은 정확히 하나의 요청 메시지와 하나의 응답 메시지를 전송한다. 따라서 이 예에서 사용자가 웹 페이지를 요청할 때 총 11개의 TCP 연결이 생성된다.

소요 시간 계산

이제 간단한 계산을 통해 클라이언트가 기본 HTML 파일을 요청하고 전체 파일을 수신하기까지 걸리는 시간을 추정해보자. 이를 위해 우리는 RTT(Round-Trip Time)를 정의한다.

RTT는 작은 패킷이 클라이언트에서 서버로 이동한 다음 다시 클라이언트로 돌아오는 데 걸리는 시간이다.

RTT에는 패킷 전파 지연, 중간 라우터와 스위치에서의 패킷 대기 지연, 그리고 패킷 처리 지연이 포함된다. (이러한 지연에 대해서는 이전 글을 참고하자.)

사용자가 하이퍼링크를 클릭하면 그림 2.7과 같이 브라우저가 브라우저와 웹 서버 간에 TCP 연결을 시작한다. 이때 "three-way handshake"가 필요하다. 먼저 클라이언트가 작은 TCP 세그먼트를 서버로 보내고, 서버는 이를 확인하여 작은 TCP 세그먼트로 응답하며, 마지막으로 클라이언트가 서버에 다시 확인 응답을 보낸다.

이 three-way handshake의 처음 두 부분은 한 번의 RTT를 소요한다.

왜 three-way handshake라고 명명했을까: three-way handshake는 클라이언트와 서버가 TCP 연결을 설정하는 과정에서 3번의 메시지 교환이 이루어지기 때문에 이런 이름이 붙었다. 간단히 이 3단계 과정을 살펴보면 다음과 같다.

1. SYN (Synchronize) - 첫 번째 메시지: 클라이언트가 서버에 연결을 요청하는 메시지(SYN 패킷)를 보냄.
2. SYN-ACK (Synchronize-Acknowledge) - 두 번째 메시지: 서버가 요청을 수락하고, 연결을 설정할 준비가 되었음을 알리는 메시지(SYN-ACK 패킷)를 클라이언트에게 응답함.
3. ACK (Acknowledge) - 세 번째 메시지: 클라이언트가 서버의 응답을 확인하고, 연결이 설정되었음을 알리는 메시지(ACK 패킷)를 서버에 다시 보냄.

이처럼 연결을 설정하는 데 3번의 단계를 거치므로 3-방향 핸드셰이크(three-way handshake)라고 부르는 것이다. 이 과정을 통해 클라이언트와 서버는 서로의 존재를 확인하고 데이터 전송을 위한 안정적인 경로를 만들 수 있다.

three-way handshake의 처음 두 부분이 완료된 후, 클라이언트는 TCP 연결에 HTTP 요청 메시지와 three-way handshake의 세 번째 부분(확인 응답)을 함께 보낸다. 요청 메시지가 서버에 도착하면, 서버는 HTML 파일을 TCP 연결로 보낸다. 이 HTTP 요청/응답 과정은 또 다른 RTT를 소요한다.

따라서 대략적인 총 응답 시간은 2 RTT + 서버의 HTML 파일 전송 시간이 된다.

지속 연결을 사용하는 HTTP

비지속 연결에는 몇 가지 단점이 있다.

첫째, 각 요청된 객체마다 새로운 연결이 생성되고 유지되어야 한다.

이러한 각 연결에 대해 TCP 버퍼를 할당하고, 클라이언트와 서버 모두에서 TCP 변수를 유지해야 한다. 이는 동시에 수백 개의 다른 클라이언트로부터 요청을 처리할 수 있는 웹 서버에 상당한 부담을 줄 수 있다.

둘째, 앞에서 설명한 것처럼 각 객체는 두 번의 RTT 지연을 겪게 된다.

첫 번째 RTT는 TCP 연결을 설정하는 데, 두 번째 RTT는 객체를 요청하고 수신하는 데 사용된다.

HTTP/1.1의 지속 연결에서는 서버가 응답을 보낸 후에도 TCP 연결을 열어 둔다. 이후의 요청과 응답은 동일한 연결을 통해 이루어질 수 있다. 특히, 전체 웹 페이지(위 예에서는 기본 HTML 파일과 10개의 이미지)는 하나의 지속 TCP 연결을 통해 전송될 수 있다. 또한 동일한 서버에 있는 여러 웹 페이지도 동일한 클라이언트와의 하나의 지속 연결을 통해 전송될 수 있다. 이러한 객체에 대한 요청은 응답을 기다리지 않고 연속적으로(파이프라이닝) 이루어질 수 있다. 일반적으로 HTTP 서버는 일정 시간 동안 사용되지 않을 때(구성 가능한 타임아웃 간격) 연결을 닫는다. 서버가 연속적인 요청을 받으면 객체를 연속적으로 전송한다. HTTP의 기본 모드는 파이프라이닝을 사용하는 지속 연결이다.

원문 작성자: Matías Hernández, 참고 링크: Improve Runtime Type Safety with Branded Types in TypeScript

코드의 안전성과 신뢰성을 높이기 위해 타입스크립트를 사용한다는 것은 이미 잘 알려진 사실이다. 하지만 인생이 다 그렇듯 만능과 완벽은 존재하지 않는다. 특히 런타임 에러를 막기 위해서는 더 정교한 타입 시스템이 필요할 수 있다. 이때 브랜디드 타입(Branded Types)이 도움을 줄 수 있다.

이번 글에서는 브랜디드 타입(Branded Types)이 무엇인지, 어떻게 사용하는지, 그리고 어떤 장점이 있는지 살펴보겠다.

런타임과 빌드타임: 타입스크립트의 한계 이해하기

이 부분 알면 넘어가시고 모르시면 꼭 보시고 기본으로 깔고 가셔야합니다.

• 런타임(Runtime): 코드가 실제로 실행되는 시점. 런타임에 발생하는 에러는 코드가 실행되는 도중에 감지되므로, 문제 해결이 까다롭고 실행 중에 예기치 않은 동작을 유발할 수 있다.

• 빌드타임(Build Time): 코드를 작성하고 컴파일하는 시점으로,** 타입스크립트는 이 단계에서 타입 검사를 수행한다.** 잘못된 타입 사용이나 타입 불일치를 컴파일 타임에 미리 감지해줌으로써 런타임 에러를 줄일 수 있다.

타입스크립트는 주로 빌드타임에 타입 검사를 통해 코드를 검증하고, 안전성을 높인다.

그러나!!!!!! 타입스크립트의 기본 타입만으로는 런타임에 발생할 수 있는 모든 오류를 방지하기에는 부족할 때가 있다. 여기서 우리는 브랜디드 타입이 등장하게 된 배경을 알 수 있다.

타입스크립트에서 브랜디드 타입이 필요한 이유

타입스크립트는 빌드타임에 타입 검사를 통해 데이터가 올바르게 전달되는지 검증한다. 그러나 데이터의 구체성이나 특수성이 충분히 표현되지 않는 경우가 종종 발생한다. 예를 들어, 사용자, 게시물, 댓글을 다루는 애플리케이션을 만든다고 가정해보자.

type User = {
  id: string;
  name: string;
}

type Post = {
  id: string;
  ownerId: string;
  comments: Comment[];
}

type Comment = {
  id: string;
  timestamp: string;
  body: string;
  authorId: string;
}

위 코드를 보면 User, Post, Comment는 모두 id 속성을 가지고 있다. 그러나 이 속성들은 모두 단순히 string 타입이기 때문에, 타입스크립트 입장에서는 이 id들이 서로 구분되지 않는다.

즉, 아래와 같은 코드에서도 에러를 감지하지 못한다.

async function getCommentsForPost(postId: string, authorId: string) {
  const response = await api.get(`/author/${authorId}/posts/${postId}/comments`);
  return response.data;
}

const comments = await getCommentsForPost(user.id, post.id);  // 타입스크립트는 에러를 인식하지 못함

위 코드에서는 getCommentsForPost 함수를 호출할 때 매개변수의 순서가 잘못되었다. 그러나 타입스크립트는 user.id와 post.id가 모두 string 타입이므로 문제를 인식하지 못한다. 이 때문에 런타임에 잘못된 응답을 받게 되고, 디버깅이 어려워진다.

타입스크립트가 더욱 정교한 타입 안전성을 제공하기 위해 탄생한 것이 바로 "브랜디드 타입"이다.

브랜디드 타입(Branded Types)이란?

브랜디드 타입은 기존 타입에 특정한 태그(brand)를 부여하여 더 구체적이고 유일한 타입을 만드는 방법이다. 이렇게 하면 단순한 기본 타입보다 더 명확하고 안전하게 데이터를 모델링할 수 있다.

간단한 브랜디드 타입 구현 예시

type Brand<K, T> = K & { __brand: T };
type UserID = Brand<string, "UserId">;
type PostID = Brand<string, "PostId">;

위 코드는 UserID와 PostID라는 두 개의 새로운 타입을 만들어낸다. __brand 속성으로 고유성을 부여하여 타입을 더욱 세밀하게 구분할 수 있다.

이제 UserID와 PostID는 단순한 string이 아닌 고유한 타입이 된다. 이를 활용하면 잘못된 데이터가 전달될 가능성을 줄일 수 있다.

개선된 예시

type UserID = Brand<string, "UserId">;
type PostID = Brand<string, "PostId">;

type User = {
  id: UserID;
  name: string;
}

type Post = {
  id: PostID;
  ownerId: UserID;
  comments: Comment[];
}

async function getCommentsForPost(postId: PostID, authorId: UserID) {
  const response = await api.get(`/author/${authorId}/posts/${postId}/comments`);
  return response.data;
}

const comments = await getCommentsForPost(user.id, post.id);  // ❌ 타입 오류 발생

이제 user.id와 post.id가 각각 UserID와 PostID 타입을 가지므로, 잘못된 인자를 전달할 경우 타입스크립트가 이를 감지할 수 있다. 이로써 컴파일 타임에 잘못된 타입 사용을 미리 방지할 수 있다.

브랜디드 타입의 한계와 개선된 구현(중요)

위 방법은 간단하고 유용하지만 몇 가지 문제점이 있다:

1. __brand 속성은 빌드타임에만 존재하며, 런타임에는 사라진다.
2. __brand 속성이 코드 자동 완성(IntelliSense)에 노출되어, 개발자가 오용할 수 있다.
3. 단순한 문자열 기반 태깅은 안전하지 않으며, 중복된 타입을 만들 수 있다.

뭐라는거지? 이게 왜 문제라는거지? 싶으신 저같은 분들을 위한 쉬운 설명

1. __brand 속성은 빌드타임에만 존재하며, 런타임에는 사라진다.

• 타입스크립트는 컴파일 타임에만 타입을 체크하고, 그 결과물을 런타임에 사용할 자바스크립트 코드로 변환한다.

• type Brand<K, T> = K & { __brand: T } 같은 브랜디드 타입은 타입스크립트가 컴파일 중에만 확인하고, 실제로 자바스크립트 코드로 변환된 후에는 사라진다. 즉, 런타임에는 __brand 속성이 존재하지 않게 된다.

왜 문제가 될까?

• 브랜디드 타입은 런타임에 타입의 고유성을 보장하는 것이 아니라, 컴파일 시점에만 타입 검사를 위해 존재한다. 따라서 컴파일을 거친 이후 실제 실행 중에는 __brand가 사라지기 때문에, 런타임에 이 타입을 검사할 수 없다.
• 즉, 타입 안정성을 보장하기 위해 브랜디드 타입을 사용하지만, 런타임에는 사라져버리기 때문에 컴파일 타임에서만 안전성을 확보할 수 있다는 한계가 있다.

2. __brand 속성이 코드 자동 완성(IntelliSense)에 노출되어, 개발자가 오용할 수 있다.

• IntelliSense는 개발자가 코드 작성 시 자동 완성 기능을 제공하는 툴.

• __brand라는 속성은 브랜디드 타입을 만들기 위해 우리가 태그로 사용한 속성이다. 하지만 이 속성은 개발자가 직접 조작할 의도로 만든 것이 아니다.
• 문제는 __brand가 자동 완성 기능(IntelliSense)에 노출된다는 것이다. 개발자가 코드 작성 중에 이 속성을 볼 수 있고, 오용할 가능성이 생긴다.

예를 들어:

type UserId = Brand<string, "UserId">;

const userId: UserId = "12345" as UserId;

// IntelliSense 자동 완성 기능에서 `userId.__brand`를 볼 수 있게 된다.

• 자동 완성 기능에서 __brand 속성이 노출되면, 개발자가 의도치 않게 __brand 속성을 참조하거나 조작할 수 있다. 이는 타입 안전성을 깨뜨릴 수 있는 잠재적인 문제이다.

3. 단순한 문자열 기반 태깅은 안전하지 않으며, 중복된 타입을 만들 수 있다.

• type Brand<K, T> = K & { __brand: T }에서 T는 보통 "UserId"나 "Email" 같은 문자열로 사용된다. 그러나 문자열 기반으로 태그를 붙이는 것은 안전하지 않을 수 있다.

왜 문제가 될까?

• 동일한 문자열 값을 사용하여 다른 브랜디드 타입을 만들게 되면 타입의 고유성이 사라지게 된다. 즉, 중복된 브랜디드 타입을 생성할 위험이 있다.

예시:

type UserId = Brand<string, "Id">;
type ProductId = Brand<number, "Id">;

const userId: UserId = "12345" as UserId;
const productId: ProductId = 67890 as ProductId;

• 위 예시에서 "Id"라는 동일한 문자열을 다른 두 타입 (UserId, ProductId)에 태그로 사용했다. 이 경우, 타입스크립트는 UserId와 ProductId를 서로 구분하지 못할 수 있고, 의도치 않게 두 타입이 혼동될 수 있다.

• 따라서 단순히 문자열로 태깅하는 것만으로는 완벽한 안전성을 보장할 수 없다는 한계가 있다.

이 문제를 해결하기 위해 unique symbol을 사용한 개선된 브랜디드 타입 구현이 필요하다.

개선된 브랜디드 타입 구현

declare const __brand: unique symbol;

type Brand<B> = { [__brand]: B };
export type Branded<T, B> = T & Brand<B>;

이제 __brand를 unique symbol로 선언함으로써 고유성을 보장한다. 이를 통해 더 이상 __brand 속성이 외부에 노출되지 않고, 같은 이름의 브랜드라도 고유한 심볼을 가지기 때문에 중복될 가능성이 없다.

브랜디드 타입이 가져다주는 이점

1. 명확성

브랜디드 타입을 사용하면 변수의 의도를 더 명확하게 표현할 수 있다. 예를 들어, UserID와 PostID가 단순한 문자열이 아닌 고유한 타입으로 정의되어 각 용도의 혼동을 방지할 수 있다.

2. 안전성과 정확성

타입 간의 불일치를 더 쉽게 감지하고 런타임 오류를 줄일 수 있다. 잘못된 데이터가 전달될 경우 컴파일 타임에 에러를 발생시킨다.

3. 유지보수성

팀원들이 코드의 의도를 쉽게 이해할 수 있다. => 이게 정말 중요한 것 같다.

브랜디드 타입의 활용 예시

1. 커스텀 유효성 검사

브랜디드 타입을 사용해 이메일 주소와 같은 사용자 입력을 검증할 수 있다.

type EmailAddress = Brand<string, "EmailAddress">;

function validEmail(email: string): EmailAddress {
  // 이메일 유효성 검사 로직
  return email as EmailAddress;
}

2. 도메인 모델링

특정 도메인을 구체적으로 표현할 때 유용하다. 예를 들어, 자동차 제조 라인에서 다양한 속성을 안전하게 관리할 수 있다.

type CarBrand = Brand<string, "CarBrand">;
type EngineType = Brand<string, "EngineType">;

3. API 응답 및 요청

API 호출에서 성공 및 실패 응답을 구분하여 타입 안정성을 높일 수 있다.

type ApiSuccess<T> = T & { __apiSuccessBrand: true };
type ApiFailure = {
  code: number;
  message: string;
  error: Error;
} & { __apiFailureBrand: true };

결론

브랜디드 타입은 타입스크립트의 타입 시스템을 한층 강화하여 코드의 안전성과 명확성을 높여주는 강력한 도구.

• 데이터의 형태와 의도를 더욱 구체적으로 표현

• 컴파일 타임에 잘못된 사용을 감지

실습해보기

실습링크 솔루션링크

TypeScript에서 인터페이스(interface)와 타입(type)은 모두 객체의 형태와 구조를 정의하는 데 사용됨.

1. 인터페이스와 타입의 탄생 배경

인터페이스는 TypeScript가 처음 설계될 때부터 있던 기능임. Java와 같은 객체 지향 언어의 영향을 받아 클래스와 연동되는 구조적인 정의가 필요했기 때문에 인터페이스가 도입되었음.

타입은 이후 TypeScript에 추가된 기능으로, 더 유연하고 함수형 프로그래밍 스타일을 지원하는 방식으로 설계되었음. 다양한 데이터 구조를 유연하게 정의할 수 있는 도구로 발전했음.

2. 인터페이스와 타입의 핵심 차이점

2.1 선언적 확장

인터페이스는 선언적 확장이 가능 즉, 동일한 이름의 인터페이스를 여러 번 선언할 수 있으며, TypeScript는 이를 하나의 인터페이스로 병합함. 이는 코드 확장성과 유지보수 측면에서 큰 장점을 가짐. 하지만 이미 선언된 interface를 모르고 중복 사용할 경우 오류가 나는 경우가 있어 이는 단점이 될 수도 있음.

  interface User {
    name: string;
  }

  interface User {
    age: number;
  }

  const user: User = {
    name: "박지성",
    age: 25, // 병합된 인터페이스를 통해 이름과 나이 모두 사용 가능
  };

타입은 확장될 수 없고, 한 번 선언된 타입은 재선언할 수 없음.

  type User = {
    name: string;
  };

  // Error: Duplicate identifier 'User'. 발생
  type User = {
    age: number;
  };

2.2 유니온(Union)과 인터섹션(Intersection)

타입은 유니온과 인터섹션 타입을 지원함. 즉, 여러 타입을 조합하거나(유니온), 합칠 수(인터섹션) 있음.

  type Pet = { name: string };
  type Dog = Pet & { breed: string }; // 인터섹션

  const dog: Dog = { name: "Buddy", breed: "Labrador" };

유니온 타입도 가능

  type StringOrNumber = string | number;

반면, 인터페이스는 유니온 타입을 지원하지 않음.

2.3 클래스와의 호환성

인터페이스는 주로 클래스와 연동해서 사용됨. TypeScript에서 인터페이스는 클래스의 형태를 정의하고 클래스가 특정한 구조를 따르게 강제할 수 있음.

  interface Animal {
    name: string;
    speak(): void;
  }

  class Dog implements Animal {
    name = "Buddy";
    speak() {
      console.log("Woof!");
    }
  }

타입은 클래스에 직접적으로 사용되기보다는 객체의 구조를 정의하거나 함수의 반환 타입 등을 정의하는 데 자주 사용됨.

3. 장단점

3.1 인터페이스의 장점

• 확장성: 여러 번 선언이 가능하고 병합되므로 코드 확장이 용이함.

• 클래스와의 자연스러운 연동: 클래스가 특정 구조를 따르게 할 때 유용함.

3.2 인터페이스의 단점

• 유연성 부족: 유니온 타입이나 인터섹션 타입을 지원하지 않음.

• 구조적 제한: 더 복잡한 구조나 동적 타입을 선언하는 데 제약이 있음.

3.3 타입의 장점

• 유연성: 유니온과 인터섹션 타입 지원으로 복잡한 타입을 표현할 수 있음.

• 복합 타입 지원: 객체, 유니온, 인터섹션 등 다양한 형태의 타입 선언이 가능.

3.4 타입의 단점

• 확장성 부족: 한 번 선언된 타입은 재선언할 수 없으므로 확장성 면에서 인터페이스보다 제한적임.

4. 예시 코드

4.1 인터페이스 사용 예시

interface User {
  name: string;
  age: number;
}

const user: User = {
  name: "박지성",
  age: 25,
};

4.2 타입 사용 예시

type User = {
  name: string;
  age: number;
};

const user: User = {
  name: "박지성",
  age: 25,
};

4.3 유니온 타입 예시

type StringOrNumber = string | number;

let value: StringOrNumber;

value = "하잉";
value = 123;

4.4 인터섹션 타입 예시

type Person = { name: string };
type Employee = { employeeId: number };

type Staff = Person & Employee;

const staff: Staff = {
  name: "박지성",
  employeeId: 217,
};

5. 공식 문서 권장 사항

TypeScript 공식 문서에서는 인터페이스와 타입을 사용하는 상황에 대해 다음과 같은 가이드를 제시함:

5.1 인터페이스를 사용할 때

• 객체 지향적인 구조가 필요한 경우: 클래스와 연동하여 사용할 때는 인터페이스를 사용하는 것이 좋음.
• 확장과 병합이 필요할 때: 여러 선언을 병합하여 하나의 인터페이스로 만들 수 있으므로, 확장이 예상되는 경우 인터페이스를 권장함.

  interface Animal {
    name: string;
  }

  interface Animal {
    age: number;
  }

  const animal: Animal = { name: "강아지", age: 3 };

5.2 타입을 사용할 때

• 유연한 타입 조합이 필요한 경우: 유니온 타입이나 인터섹션 타입을 사용할 때는 타입을 사용하는 것이 적합함.

• 동적이고 복합적인 타입을 다룰 때: 함수형 프로그래밍 스타일을 따르거나, 다양한 데이터 구조를 유연하게 정의할 때는 타입을 사용하는 것이 더 적합함.

  type ID = string | number;

6. 결론

인터페이스와 타입은 TypeScript에서 각각의 강점과 용도를 가지고 있음. 객체지향적인 구조를 정의하고 확장이 필요한 경우에는 인터페이스가 적합하며, 유연하고 복잡한 데이터 구조를 정의할 때는 타입을 사용하는 것이 좋음.

권장사항 요약:

• 클래스와 연동, 확장성: 인터페이스 사용
• 유니온, 인터섹션, 복합 타입: 타입 사용

7. 보충내용

extends와 &의 차이점

• 위 내용에서 타입에서 인터섹션을 사용하여 속성 확장이 가능하다고 언급하였음. interface도 객체지향적으로 extends 상속이 가능함.
• extends*: 상속을 의미. 타입의 인터섹션과 기능은 같지만 개념이 다름.

• extends는 상속 개념으로, 인터페이스 확장을 위해 사용됨.

• &는 여러 타입을 결합하는 방식으로, 모든 속성을 합쳐 새로운 타입을 만듬.

• extends 예시:

  interface Person {
    name: string;
    age: number;
  }
  
  interface Employee extends Person {
    salary: number;
  }

Omit 사용 방법

Omit은 타입이나 인터페이스에서 특정 속성을 제외하고 싶을 때 사용됨.

• 타입에서 Omit 사용:

  type Person = { name: string; age: number; address: string; }
  type PersonWithoutAddress = Omit<Person, "address">;

• 인터페이스에서 Omit 사용:

  interface Person {
    name: string;
    age: number;
    address: string;
  }
  
  interface PersonWithoutAddress extends Omit<Person, "address"> {}

요약

• extends: 상속 개념으로, 인터페이스를 확장할 때 사용.
• &: 여러 타입을 합쳐 새로운 타입을 만들 때 사용.
• Omit: 특정 속성을 제외한 타입이나 인터페이스를 정의할 때 사용.

모든 내용과 이미지는 Computer Networking- A Top Down Approach-Pearson을 참고하였습니다.

Chapter 1.5

이번 글에서는 네트워크의 프로토콜 계층 구조와 서비스 모델을 다루며, 인터넷 프로토콜 스택과 OSI 모델에 대해 설명할 것임. 또한, 네트워크 통신에서의 캡슐화(encapsulation)와 역캡슐화(de-encapsulation) 과정도 포함하여 정리할 것임.

1. 네트워크 계층 구조의 필요성

인터넷은 매우 복잡한 시스템임. 수많은 애플리케이션과 프로토콜, 다양한 종단 시스템, 패킷 스위치 및 다양한 링크 레벨 매체들이 존재함. 이 복잡한 시스템을 어떻게 체계적으로 정리할 수 있을까? 다행히 네트워크 아키텍처를 설명하는 계층적 구조가 존재함. 계층적 구조는 복잡한 시스템을 명확하게 설명하고 유지보수할 수 있는 유용한 도구임.

2. OSI 7계층 모델과 인터넷 프로토콜 스택

OSI 모델

OSI 모델은 7계층으로 이루어진 네트워크 통신 모델임:

1. Application (응용)
2. Presentation (표현)
3. Session (세션)
4. Transport (전송)
5. Network (네트워크)
6. Data Link (데이터 링크)
7. Physical (물리)

이 중에서 Presentation과 Session 계층은 인터넷 프로토콜 스택에서 생략됨. 이 두 계층의 기능은 필요에 따라 응용 프로그램에서 구현됨.

• Presentation 계층은 데이터를 암호화하거나, 압축하고, 기계 특유의 형식으로 변환하는 역할을 함. 예를 들어, HTTPS 프로토콜에서 암호화와 복호화가 이 계층에서 이루어짐.

• Session 계층은 통신 중 동기화와 체크포인트, 데이터 교환 복구 등을 담당함. 하지만, 이 기능도 애플리케이션에서 구현될 수 있음.

인터넷 프로토콜 스택(중요!!!!)

인터넷 프로토콜 스택은 OSI 모델보다 간소화된 5계층 모델로 이루어짐:

1. Application (응용)
2. Transport (전송)
3. Network (네트워크)
4. Link (데이터 링크)
5. Physical (물리)

• Application Layer (응용 계층): 사용자가 사용하는 애플리케이션과 해당 프로토콜을 포함함. 예를 들어 HTTP, FTP, SMTP 등이 있음.

• Transport Layer (전송 계층): 애플리케이션 간 데이터 전송을 담당하며, TCP와 UDP 프로토콜이 사용됨. TCP는 신뢰성 있는 데이터 전송을 보장하는 반면, UDP는 신뢰성 없이 빠르게 데이터를 전송함.
• Network Layer (네트워크 계층): 데이터를 송수신할 경로를 찾아주며, IP 주소와 라우팅을 담당함.
• Link Layer (데이터 링크 계층): 인접한 네트워크 장치 간의 데이터 전송을 담당하며, 이더넷이나 Wi-Fi 등이 속함.
• Physical Layer (물리 계층): 물리적인 매체를 통해 데이터를 전송함. 케이블이나 무선 신호를 통해 데이터를 비트 단위로 주고받음.

3. 캡슐화(Encapsulation)와 역캡슐화(De-encapsulation)

네트워크에서 데이터가 전송될 때, 각 계층은 데이터를 처리하면서 자신만의 헤더를 추가하는 캡슐화 과정을 거침. 그리고 수신 측에서 이 헤더들을 제거하는 역캡슐화 과정을 거쳐 데이터가 상위 계층으로 전달됨.

캡슐화

1. Application Layer: 사용자가 입력한 데이터가 메시지로 전송됨.
2. Transport Layer: 메시지에 세그먼트가 추가됨.
3. Network Layer: 세그먼트에 IP 헤더를 추가하여 데이터그램이 됨.
4. Link Layer: 프레임 헤더와 프레임 트레일러가 추가됨.
5. Physical Layer: 비트로 변환되어 물리적 매체를 통해 전송됨.

역캡슐화

수신 측에서는 이 과정을 역순으로 수행함. 물리 계층에서 받은 비트 데이터를 링크 계층에서 프레임으로 처리하고, 네트워크 계층에서 데이터그램으로 변환하여 목적지까지 도달함.

4. Why Layering?

계층 구조의 주요 이점은 다음과 같음:

1. 복잡한 시스템 처리:
   • 복잡한 네트워크 시스템을 계층으로 나눠서 각 계층의 기능을 명확하게 정의할 수 있음.
2. 모듈화의 장점:
   • 계층 구조 덕분에 한 계층의 구현을 변경하더라도 다른 계층에 영향을 미치지 않음. 이를 통해 시스템 유지보수 및 업데이트가 용이해짐.
3. 계층화의 단점:
   • 계층 구조는 중복된 기능을 초래할 수 있음. 예를 들어, 오류 검출 기능이 여러 계층에서 중복되어 있을 수 있음. 또한, 각 계층에서 추가되는 오버헤드로 인해 성능 저하가 발생할 수 있음.

결론

네트워크 통신의 계층적 구조는 복잡한 시스템을 이해하고 관리하는 데 유용한 도구임. OSI 모델과 인터넷 프로토콜 스택은 계층적 구조의 대표적인 예로, 네트워크 통신의 각 단계에서 어떤 일이 일어나는지 명확하게 설명함. 캡슐화와 역캡슐화 과정은 데이터를 안전하고 효율적으로 전달하기 위한 핵심 개념임.