5분 기록

[Calculus] 결정불능형 정리표

기록하는 남자 — Tue, 30 Sep 2025 21:22:50 +0900

[Analysis] lim (1/n) = 0의 ε–N 증명

기록하는 남자 — Tue, 30 Sep 2025 20:49:44 +0900

저 식을 통해 n > N이 되는 N이 존재함을 증명하면 된다. 그러면 n > N을 만족하는 n 에 대해서 위 식이 성립한다고 볼 수 있다. 즉, 수렴이 된다고 볼 수 있다.

SOLID 원칙

기록하는 남자 — Sun, 6 Apr 2025 17:44:35 +0900

SOLID 원칙이란?

SOLID = 객체지향 설계 5대 원칙의 앞글자를 딴 말

알파벳	원칙 이름	한글 설명
S	Single Responsibility Principle	단일 책임 원칙
O	Open/Closed Principle	개방-폐쇄 원칙
L	Liskov Substitution Principle	리스코프 치환 원칙
I	Interface Segregation Principle	인터페이스 분리 원칙
D	Dependency Inversion Principle	의존 역전 원칙

각 원칙 자세히 보기

S: 단일 책임 원칙 (Single Responsibility Principle)

한 클래스는 하나의 책임만 가져야 한다

한 클래스는 하나의 기능(역할)에만 집중해야 함
예: UserService는 사용자 관리만, EmailService는 이메일만

// ❌ 잘못된 예
class UserManager {
  createUser() { ... }
  sendWelcomeEmail() { ... } // 이메일은 다른 책임!
}

// ✅ 바른 예
class UserManager {
  createUser() { ... }
}

class EmailService {
  sendWelcomeEmail() { ... }
}

그냥 한 클래스는 자신과 관련된 것만 심플하게 책임을 가지도록

O: 개방-폐쇄 원칙 (Open/Closed Principle)

확장에는 열려 있고, 변경에는 닫혀 있어야 한다

새로운 기능은 기존 코드 수정 없이 확장 가능해야 함
예: 조건문 대신 다형성(Polymorphism)으로 확장

// ❌ OCP 위반: 조건문 방식

class BadPaymentProcessor {
  process(type) {
    if (type === 'credit') {
      console.log('  카드 결제 처리');
    } else if (type === 'paypal') {
      console.log('  페이팔 결제 처리');
    }
  }
}

const bad1 = new BadPaymentProcessor();
bad1.process('credit');

//   "카카오페이" 추가하려면 기존 메서드 수정해야 함
class BadPaymentProcessorV2 {
  process(type) {
    if (type === 'credit') {
      console.log('  카드 결제 처리');
    } else if (type === 'paypal') {
      console.log('  페이팔 결제 처리');
    } else if (type === 'kakao') {
      console.log('  카카오페이 결제 처리'); // ✋ OCP 위반: 기존 코드 수정
    }
  }
}

const bad2 = new BadPaymentProcessorV2();
bad2.process('kakao');



// ✅ OCP 준수: 다형성 방식

class PaymentMethod {
  pay() {}
}

class CreditCard extends PaymentMethod {
  pay() { console.log('  카드 결제 처리'); }
}

class PayPal extends PaymentMethod {
  pay() { console.log('  페이팔 결제 처리'); }
}

class GoodPaymentProcessor {
  constructor(method) {
    this.method = method;
  }
  process() {
    this.method.pay();
  }
}

const good1 = new GoodPaymentProcessor(new CreditCard());
good1.process();

//   "카카오페이"는 클래스만 추가하면 됨! 기존 코드 수정 ❌
class KakaoPay extends PaymentMethod {
  pay() { console.log('  카카오페이 결제 처리'); }
}

const good2 = new GoodPaymentProcessor(new KakaoPay());
good2.process(); // OCP 지킴

설명 요약

❌ BadPaymentProcessor는 기능을 추가할 때마다 조건문 늘어나고, 기존 코드를 직접 수정해야 해서 OCP를 위반함
✅ GoodPaymentProcessor는 새로운 기능이 생겨도 클래스만 추가하면 되므로 OCP를 만족함 (확장에는 열려 있고, 수정에는 닫혀 있음)

if문으로 조건 거는 걸로 전부 처리하면 나중에 변경사항 생기면 조건문 건드려서 코드 고쳐야 되니까

그냥 각각 상속한 각 클래스 사용하고 새로운 기능 오면 또 상속하는 새로운 클래스 만들어서 확장

L: 리스코프 치환 원칙 (Liskov Substitution Principle)

자식 클래스는 언제나 부모 클래스를 대체할 수 있어야 한다

자식 클래스가 부모 클래스의 역할을 깨면 안 됨

// ❌ 잘못된 예: LSP 위반
class PaymentService {
  process(amount: number) {
    console.log(`결제 ${amount}원 완료`);
  }
}

class BankTransferService extends PaymentService {
  process(amount: number) {
    // ❗ 부모 클래스는 항상 결제를 처리할 수 있다고 보장했는데,
    // 자식 클래스가 그 계약을 깨버림 (런타임 오류 발생)
    throw new Error("BankTransfer는 수동 처리만 지원함");
  }
}

// 위의 구조는 리스코프 치환 원칙(LSP)을 위반한 것!
// PaymentService를 기대한 코드에서 BankTransferService로 바꾸면 문제가 생김.


// ✅ 바른 예: LSP 준수

//   공통된 동작을 추상화한 인터페이스 정의
interface IPaymentService {
  process(amount: number): void;
}

// 카드 결제는 정상적으로 process 가능
class CardPaymentService implements IPaymentService {
  process(amount: number) {
    console.log(`카드로 ${amount}원 결제 완료`);
  }
}

// 은행 이체는 결제와는 다른 방식이므로, 아예 다른 클래스/메서드로 분리
class BankTransferService {
  requestManualTransfer(amount: number) {
    console.log(`수동 이체 요청: ${amount}원`);
  }
}

설명 요약

잘못된 예에선 부모(PaymentService)는 process()를 보장하지만
자식(BankTransferService)은 그걸 깨버림 → LSP 위반 ❌
바른 예에선 아예 인터페이스를 분리해서,
각 클래스가 자기 역할만 하도록 설계 → 안정성 확보 ✅

부모꺼 못쓰면 상속하지 말고 새로 만드셈.

I: 인터페이스 분리 원칙 (Interface Segregation Principle)

많은 기능을 가진 큰 인터페이스보단, 작고 구체적인 인터페이스로 나누자

// ❌ 잘못된 예: 지나치게 큰 인터페이스

interface Worker {
  work(): void;
  eat(): void;
}

// 로봇도 작업은 하지만, 밥은 안 먹음
class HumanWorker implements Worker {
  work() { console.log('사람이 일함'); }
  eat() { console.log('사람이 밥 먹음'); }
}

class RobotWorker implements Worker {
  work() { console.log('로봇이 일함'); }

  // ❗ 로봇은 밥을 먹지 않지만, 어쩔 수 없이 구현해야 함 → ISP 위반
  eat() {
    throw new Error("로봇은 밥을 먹지 않습니다");
  }
}



// ✅ 바른 예: 인터페이스 분리

interface Workable {
  work(): void;
}

interface Eatable {
  eat(): void;
}

class Human implements Workable, Eatable {
  work() { console.log('사람이 일함'); }
  eat() { console.log('사람이 밥 먹음'); }
}

class Robot implements Workable {
  work() { console.log('로봇이 일함'); }
}

설명 요약

❌ Worker 인터페이스는 너무 많은 역할을 담고 있어서, 어떤 구현체(로봇)는 필요 없는 eat()까지 구현해야 함 → ISP 위반
✅ 인터페이스를 Workable, Eatable로 작게 나누면, 클래스는 자신에게 필요한 기능만 선택해서 구현할 수 있음 → 유지보수성, 재사용성 향상

인터페이스 한번에 기능 다 넣지말고 잘개 쪼개서 사용할 수 있게하셈.

두 원칙 차이 한눈에 정리

원칙	핵심	개념위반 시	문제적용 시점
LSP (리스코프 치환 원칙)	“자식은 부모를 대체할 수 있어야 한다”	부모 타입으로 사용했을 때 예외가 발생하거나 기대한 동작이 깨짐	상속할 때 (클래스 간 관계)
ISP (인터페이스 분리 원칙)	“클라이언트는 자신이 사용하지 않는 인터페이스에 의존하지 말아야 한다”	불필요한 메서드를 강제로 구현해야 함 → 코드가 지저분해지고, 책임이 섞임	인터페이스 설계할 때 (타입 정의/구조 설계 시)

D: 의존 역전 원칙 (Dependency Inversion Principle)

고수준 모듈(비즈니스 로직)은 저수준 모듈(구현 디테일)에 의존하면 안 된다.
대신 추상화(인터페이스)에 의존해야 한다

즉, 구현이 아니라 인터페이스에 의존하라

// ❌ 나쁜 예: 구체 클래스에 직접 의존
class MySQLDatabase {
  connect() {
    console.log('MySQL 연결');
  }
}

class UserServiceBad {
  db = new MySQLDatabase(); //   문제! 특정 구현에 강하게 결합됨

  init() {
    this.db.connect();
  }
}

const badService = new UserServiceBad();
badService.init(); // ✅ 동작은 하지만 → 나중에 다른 DB로 바꾸려면 이 클래스 자체를 수정해야 함



// ✅ 좋은 예: 인터페이스(추상화)에 의존
interface Database {
  connect(): void;
}

class MySQLDatabaseV2 implements Database {
  connect() { console.log('MySQL 연결'); }
}

class PostgreSQLDatabase implements Database {
  connect() { console.log('PostgreSQL 연결'); }
}

class UserService {
  constructor(private db: Database) {} //   추상화에 의존

  init() {
    this.db.connect();
  }
}

//   실제 사용 시, 원하는 구현체를 외부에서 주입하면 됨
const goodService = new UserService(new PostgreSQLDatabase());
goodService.init(); // ✅ PostgreSQL 연결

설명 요약

❌ UserServiceBad는 MySQLDatabase라는 구체 구현에 직접 의존해서,
- 다른 DB를 쓰고 싶으면 내부 코드를 직접 고쳐야 함 → 결합도 높음, 확장성 낮음
✅ UserService는 Database라는 인터페이스(추상화)에만 의존하고,
- 구체 구현(MySQL, PostgreSQL)은 외부에서 주입(DI) → 확장성 높고, 유지보수 쉬움

구체(Concrete) = 실제 동작을 가지고 있는 구현체
추상(Abstract) = 어떤 기능이 있을지는 정해졌지만, 구현은 없는 틀(약속)

구분	뜻	예시
추상	기능(역할)만 정의된 틀	interface, abstract class
구체	실제 동작을 가진 클래스	class MySQLDatabase

실제 구현체말고 인터페이스를 비즈니스 로직 클래스가 사용하게 만드셈.

그래야 비즈니스 인스턴스 생성할 때 바꿔 뀌는 게 되니까

IoC & DI: DIP를 실현하는 핵심 도구들

IoC (Inversion of Control, 제어의 역전)

말 그대로: 제어 흐름의 주도권을 뒤집는다

보통 우리가 직접 객체를 new해서 제어하지만,
IoC에서는 외부에서 필요한 걸 알아서 넣어줌 → 그래서 제어가 “역전”됨

❌ 제어를 직접 하는 예:

class UserService {
  db = new MySQLDatabase(); // 직접 new 함 (제어권 자신에게 있음)
}

✅ IoC (제어의 역전):

class UserService {
  constructor(private db: Database) {} // 외부에서 넣어줌 (제어권을 위임함)
}

이처럼, 객체 생성이나 연결을 직접 하지 않고 외부에 맡기는 게 IoC야.
외부는 개발자가 아닌 프레임워크나 DI 시스템(컨테이너)

DI (Dependency Injection, 의존성 주입)

IoC를 실현하는 구체적인 방법

→ 필요한 의존성(객체)을 외부에서 주입해주는 방식

DI는 크게 3가지 방식이 있어:

방식	예시
생성자 주입	constructor(private db: Database) ← 우리가 방금 쓴 방식
세터 주입	setDatabase(db: Database) 같은 메서드로 설정
인터페이스 주입	인터페이스에서 주입받는 규약을 강제

생성자 주입 (Constructor Injection)

의존성을 생성자 매개변수로 주입
가장 일반적이고 안전한 방식 (불변성 유지)

interface Database {
  connect(): void;
}

class MySQLDatabase implements Database {
  connect() {
    console.log('MySQL 연결');
  }
}

class UserService {
  constructor(private db: Database) {}

  init() {
    this.db.connect();
  }
}

// 의존성 주입 (수동)
const db = new MySQLDatabase();
const userService = new UserService(db);
userService.init();

세터 주입 (Setter Injection)

의존성을 나중에 set 메서드를 통해 주입
초기화 시점 분리 가능, 유연하지만 실수로 안 넣으면 런타임 에러 위험 있음

interface Database {
  connect(): void;
}

class MySQLDatabase implements Database {
  connect() {
    console.log('MySQL 연결');
  }
}

class UserService {
  private db!: Database; // 주입 전까지 undefined (주의 필요)

  setDatabase(db: Database) {
    this.db = db;
  }

  init() {
    this.db.connect();
  }
}

// 사용
const userService = new UserService();
userService.setDatabase(new MySQLDatabase());
userService.init();

인터페이스 주입 (Interface Injection)

클래스가 "나는 이 의존성을 받아야 한다"는 메서드 구조를 강제
직접 주입하는 쪽이 주입 규약을 따름

interface Database {
  connect(): void;
}

interface DatabaseInjectable {
  injectDatabase(db: Database): void;
}

class MySQLDatabase implements Database {
  connect() {
    console.log('MySQL 연결');
  }
}

class UserService implements DatabaseInjectable {
  private db!: Database;

  injectDatabase(db: Database) {
    this.db = db;
  }

  init() {
    this.db.connect();
  }
}

// 외부에서 인터페이스 기반으로 주입
const userService = new UserService();
userService.injectDatabase(new MySQLDatabase());
userService.init();

방식	장점	단점	특징
생성자 주입	안정적, 불변성 유지	순환참조 시 불편	가장 일반적
세터 주입	유연, 선택적 의존성	안 주입하고 쓸 위험	설정 단계 분리
인터페이스 주입	주입 규칙 명확	구현 복잡도 ↑	Java/Spring 쪽에서 자주 사용

역할	설명
DIP	추상화에 의존하자
IoC	제어를 외부로 넘기자
DI	그 외부가 객체를 "주입"해주는 방식이다

순환 참조란?

두 클래스가 서로를 의존할 때 생기는 상황
즉,

A → B
B → A

둘 다 생성자에서 서로를 필요로 하면,
무한 루프에 빠져서 에러 나거나 앱이 제대로 동작 안 함.

TypeScript 예제: 생성자 주입 + 순환 참조

class A {
  constructor(private b: B) {}
}

class B {
  constructor(private a: A) {}
}

// 문제 발생 시도
const a = new A(new B(new A())); // ❌ 이런 식으로는 불가능

A를 만들려면 B가 필요하고,
B를 만들려면 또 A가 필요하고…
➡️ 끝이 없어서 스택 오버플로우 or 런타임 오류가 남

왜 생성자 주입이 순환 참조에 불리하냐?

생성자 주입은 "객체 생성 시점에 모든 의존성이 완성돼 있어야 함"
근데 A와 B가 서로를 필요로 하면 서로가 아직 생성 안 됐는데 필요로 함
즉, 순환 구조라 객체 생성 자체가 불가능해짐

해결 방법 1: 세터 주입으로 바꾸기

class A {
  private b!: B;
  setB(b: B) {
    this.b = b;
  }
}

class B {
  private a!: A;
  setA(a: A) {
    this.a = a;
  }
}

// 인스턴스 생성 후 의존성 연결
const a = new A();
const b = new B();

a.setB(b);
b.setA(a);

✅ 객체 먼저 만들고 나중에 연결하면 순환 참조 회피 가능!

해결 방법 2: DI 컨테이너가 순환 참조 감지 + Lazy Injection

프레임워크들은 종종 자동으로 감지해서 해결하려고 해:

NestJS 예: forwardRef()

@Injectable()
export class A {
  constructor(@Inject(forwardRef(() => B)) private b: B) {}
}

@Injectable()
export class B {
  constructor(@Inject(forwardRef(() => A)) private a: A) {}
}

✅ forwardRef()는 **"얘 나중에 올 거야"**라고 알려주는 것
➡️ NestJS가 순환 참조를 알고 나중에 연결해줌

요약

주입 방식	순환 참조에 강함?	이유
생성자 주입	❌ 약함	객체 생성 전에 의존성이 모두 있어야 해서
세터 주입	✅ 강함	생성 후 의존성 설정 가능
프레임워크 DI (forwardRef 등)	✅ 강함	내부적으로 Lazy Load, Proxy로 해결

Static Import, Dynamic Import

기록하는 남자 — Sat, 5 Apr 2025 14:01:19 +0900

JavaScript에서 모듈을 불러오는 방식에는 정적 임포트와 동적 임포트 두 가지가 있습니다. 각 방식의 특징과 차이점을 설명드리겠습니다.

정적 임포트 (Static Import)

정적 임포트는 컴파일 시점에 모듈을 가져오는 방식으로, import 키워드를 사용하여 모듈을 선언합니다.

특징:

컴파일 시점 로딩: 모든 정적 임포트는 코드가 실행되기 전에 로드됩니다.
상위 수준에서만 사용 가능: 모든 정적 임포트는 모듈의 최상위 수준에서만 선언할 수 있으며, 조건문이나 함수 내부에서는 사용할 수 없습니다.
문법적 엄격성: 모듈 경로는 문자열 리터럴로만 지정할 수 있으며, 변수나 표현식을 사용할 수 없습니다.

예시:

import { add, subtract } from './math.js';

console.log(add(2, 3));      // 5
console.log(subtract(5, 2)); // 3

장점:

정적 분석 가능: 코드의 모듈 의존성을 정적으로 분석할 수 있어, 트리 쉐이킹(tree-shaking)과 같은 최적화가 가능합니다.
빠른 초기 로딩: 필요한 모듈이 미리 로드되므로, 코드 실행 시 지연이 없습니다.

단점:

유연성 부족: 조건부 로딩이나 동적 경로 로딩이 불가능합니다.
큰 번들 크기: 모든 모듈이 한 번에 로드되므로, 사용되지 않는 코드까지 포함되어 번들 크기가 커질 수 있습니다.

동적 임포트 (Dynamic Import)

동적 임포트는 코드 실행 시점에 모듈을 비동기적으로 가져오는 방식으로, import() 함수를 사용합니다.

특징:

런타임 로딩: 코드가 실행되는 동안 필요한 시점에 모듈을 로드합니다.
비동기 처리: import() 함수는 프로미스(Promise)를 반환하므로, then 또는 async/await를 사용하여 처리할 수 있습니다.
유연성: 조건문, 함수 내부 등 어디에서나 호출할 수 있으며, 모듈 경로를 동적으로 지정할 수 있습니다.

예시:

// 조건부 로딩
if (user.isLoggedIn) {
  import('./dashboard.js')
    .then((module) => {
      module.loadDashboard();
    })
    .catch((error) => {
      console.error('Error loading dashboard:', error);
    });
}

// 동적 경로 로딩
const moduleName = 'analytics';
import(`./modules/${moduleName}.js`)
  .then((module) => {
    module.init();
  })
  .catch((error) => {
    console.error(`Error loading ${moduleName} module:`, error);
  });

장점:

번들 크기 최적화: 필요한 모듈만 로드하므로 초기 번들 크기를 줄일 수 있습니다.
유연성: 사용자 상호작용이나 특정 조건에 따라 모듈을 로드할 수 있습니다.

단점:

초기 로딩 지연: 모듈 로딩이 비동기적으로 이루어지므로, 로딩 완료 전까지 해당 모듈의 기능을 사용할 수 없습니다.
에러 처리 필요: 네트워크 문제 등으로 인해 모듈 로딩에 실패할 수 있으므로, 적절한 에러 처리가 필요합니다.

정적 임포트와 동적 임포트의 선택 기준

초기 로딩 성능이 중요한 경우: 동적 임포트를 사용하여 초기 번들 크기를 줄이고, 필요한 시점에 모듈을 로드하는 것이 좋습니다.
모든 기능이 즉시 필요하거나, 트리 쉐이킹*이 가능한 경우: 정적 임포트를 사용하여 코드의 일관성과 가독성을 유지하는 것이 좋습니다.

트리 쉐이킹*(Tree Shaking)이란?

사용되지 않는 코드(= dead code)를 정적 분석을 통해 번들에서 제거하는 최적화 기법

⚙️ 동작 원리

ESM (ECMAScript Module) 기반의 import/export 구조를 분석해서
어떤 코드가 실제로 사용되고 있는지 판단
사용되지 않는 코드는 DCE(Dead Code Elimination) 기법으로 제거됨

어떻게 적용하냐?

번들러(Webpack, Vite 등)가 트리 쉐이킹을 제대로 적용하려면
코드에 side effect가 없다는 걸 명확히 알려줘야 함

package.json에 명시

{
  "sideEffects": false
}

프로젝트 전체에 부작용(side effect)이 없음을 의미 → 안 쓰는 코드 safely 제거 가능

또는 일부만 예외로 설정할 수도 있음:

{
  "sideEffects": ["./src/styles/global.css"]
}

CSS처럼 import만 해도 효과가 있는 파일은 side effect 있음으로 간주해야 함

주의할 점

조건	설명
✅ ESM만 작동	import/export 문법 구조일 때만 트리 쉐이킹 가능
❌ CommonJS는 안 됨	require()는 정적 분석 불가 → 제거 못 함
⚠️ 동적 import는 감지 불가	import() 같은 동적 로딩은 분석 대상 아님
❗ side effect 있는 코드	명시하지 않으면 제거 안 됨 (실행되기만 해도 영향 주는 코드)

ESM = ECMAScript Module의 줄임말로,
JavaScript 표준 모듈 시스템을 의미함

import / export 문법 사용
정적 구조 → 코드 분석에 유리
브라우저, Node.js, Webpack, Vite 등에서 기본 지원

DCE(Dead Code Elimination)란?

실제로 실행되지 않는 코드(= dead code)를 빌드 타임에 제거하는 최적화 기법

“사용되지 않는다” ≠ “문법적으로 틀렸다”는 아님
단지 실행될 일이 없다는 걸 분석해서 제거하는 거야

어떻게 동작함?

정적 분석 기반

코드를 실행하지 않고도, 분기/사용 흐름을 따라가며 판단함

예시

function test() {
  return;
  console.log("이건 절대 실행 안 됨"); // dead code
}

또는

function unused() {
  console.log("누구도 날 안 써줘  ");
}

실제로는 누가 해줌?

Terser (Webpack의 기본 minifier)
esbuild, Rollup, Vite 등 자체적으로 DCE 내장

DCE가 제거하는 것들 예시

코드	제거 대상?	이유
if (false) { ... }	✅	절대 실행 안 됨
return; console.log(...)	✅	도달 불가
미사용 함수/변수	✅	호출/참조 안 됨
debugger;	✅	최적화 시 제거 대상

DCE가 안 되는 경우

eval() 같은 동적 실행
전역 오브젝트 조작 (window.someFunc = ...)
코드가 사이드 이펙트를 갖고 있을 경우

트리 쉐이킹은 모듈 단위의 사용 여부를 판단하고,
DCE는 모듈 안의 코드 흐름까지 살펴서 더 미세하게 제거

항목	트리 쉐이킹 (Tree Shaking)	DCE (Dead Code Elimination)
분석 대상	import / export	코드 내부의 조건문, 흐름, 변수 사용
레벨	모듈 수준	함수/블록/문장 수준
예시	안 쓰는 export 제거	도달 불가한 코드 제거
언제 작동?	ESM 기반에서만	ESM이 아니어도 가능
도구	Rollup, Webpack 등	Terser, esbuild 등

Error: Failed to load chunk server/chunks/ssr/

기록하는 남자 — Sat, 5 Apr 2025 13:38:48 +0900

Next.js에서 `@radix-ui/react-tabs`를 설치한 후,

`Error: Failed to load chunk server/chunks/ssr/` 같은 에러가 발생했다.

찾아보니 이 에러는 코드 스플리팅으로 분리된 청크(chunk) 파일들을 제대로 가져오지 못할 때 주로 발생하며,

특히 프로덕션 환경에서 캐시 문제로 인해 발생하는 경우가 많다고 한다.

프로덕션 환경이 아닌, 로컬 개발 환경에서 작업 중이었기 때문에,

파일 경로 문제를 의심해봤다.

import 경로를 확인해보니,

파일 이름 앞에 `\b`(백스페이스 문자)가 보이지 않게 들어가 있는 걸 발견했다.

이 문제는 Mac에서 VS Code로 파일을 생성하거나 이름을 수정할 때,

간혹 이런 제어 문자(`\b`)가 파일명에 끼어드는 경우가 있어서 발생한 것으로 보인다.

해당 파일을 삭제하고, 올바른 이름으로 다시 생성한 뒤 import를 수정하니 에러가 해결되었다.

정리

파일 시스템의 대소문자 구분: macOS의 기본 파일 시스템인 HFS+는 대소문자를 구분하지 않습니다. 따라서 VS Code에서 파일 이름의 대소문자를 변경할 경우, 내부적으로 혼동이 발생하여 숨겨진 제어 문자가 추가될 수 있습니다.

파일 이름에 보이지 않는 제어 문자(예: \b)가 포함되면, 웹 애플리케이션이 해당 파일을 정확하게 찾고 로드하는 데 문제가 발생할 수 있습니다. 이러한 문제가 발생하는 이유와 그로 인해 ChunkLoadError가 발생하는 과정을 설명드리겠습니다.

1. 파일 시스템과 모듈 번들러의 파일 처리

파일 시스템의 역할: 운영 체제의 파일 시스템은 파일 이름을 기반으로 파일을 관리하고 접근합니다. 파일 이름에 보이지 않는 제어 문자가 포함되면, 파일 시스템이 해당 파일을 예상과 다르게 처리할 수 있습니다.
모듈 번들러(Webpack 등)의 역할: 모듈 번들러는 소스 코드를 분석하여 의존성을 파악하고, 이를 기반으로 청크(chunk) 파일을 생성합니다. 이 과정에서 파일 경로와 이름이 정확해야 합니다.

2. 제어 문자로 인한 문제 발생 과정

파일 탐색 및 로딩: 애플리케이션이 특정 모듈이나 컴포넌트를 로드하려고 할 때, 해당 파일의 경로를 기반으로 파일 시스템에서 파일을 찾습니다. 파일 이름에 보이지 않는 제어 문자가 포함되어 있으면, 실제 파일 경로와 일치하지 않아 파일을 찾지 못할 수 있습니다.
청크 파일 생성 및 매핑: 모듈 번들러는 각 모듈을 청크로 분리하고, 이를 고유한 이름으로 저장합니다. 이때 파일 이름이 예상과 다르거나 일관되지 않으면, 생성된 청크 파일과 애플리케이션 코드 간의 매핑이 어긋나게 됩니다.

3. ChunkLoadError 발생

청크 로딩 실패: 애플리케이션이 특정 청크를 로드하려고 시도할 때, 해당 청크 파일을 찾지 못하면 ChunkLoadError가 발생합니다. 이는 브라우저가 지정된 경로에서 청크 파일을 가져오지 못했음을 의미합니다.
오류의 원인: 파일 이름에 포함된 보이지 않는 제어 문자로 인해, 파일 경로가 예상과 다르게 해석되거나, 파일이 존재하지 않는 것으로 인식되어 로딩에 실패하게 됩니다.

4. 해결 방안

파일 이름 검증: 파일을 생성하거나 수정할 때, 보이지 않는 제어 문자가 포함되지 않도록 주의해야 합니다. 특히, 파일 이름을 복사하거나 붙여넣기 할 때 이러한 문제가 발생할 수 있으므로, 텍스트 에디터나 IDE에서 파일 이름을 확인하는 것이 중요합니다.
문제 발생 시 조치: 만약 이러한 문제가 발생했다면, 해당 파일을 삭제하고 새로운 파일을 생성하여 올바른 이름으로 저장하는 것이 좋습니다.

이러한 과정을 통해, 파일 이름에 보이지 않는 제어 문자가 포함되는 것을 방지하고, 그로 인한 ChunkLoadError와 같은 오류를 예방할 수 있습니다.

개발(Development) 단계에서의 원인과 해결 방법

주요 원인:

파일 누락 또는 경로 문제:
- 개발 중에 파일 경로나 이름이 변경되었지만, 개발 서버가 이를 인식하지 못하여 이전 경로를 참조하는 경우입니다.
빌드 불일치:
- 코드 수정 후 개발 서버가 최신 빌드를 반영하지 못하여, 오래된 청크 파일을 로드하려는 경우입니다.

해결 방법:

개발 서버 재시작:
- 개발 서버를 재시작하여 변경 사항이 올바르게 반영되도록 합니다.
빌드 폴더 삭제 및 재빌드:
- 프로젝트의 빌드 폴더(예: .next 또는 dist 폴더)를 삭제한 후 애플리케이션을 다시 빌드하고 실행합니다.
브라우저 캐시 삭제:
- 브라우저의 캐시를 지운 후 페이지를 새로고침하여 최신 파일을 로드하도록 합니다.

프로덕션(Production) 단계에서의 원인과 해결 방법

주요 원인:

파일 누락 또는 경로 문제:
- 배포 시 청크 파일이 누락되었거나, 경로 설정이 잘못되어 클라이언트가 해당 파일을 찾지 못하는 경우입니다.
캐싱 문제:
- 사용자의 브라우저가 이전 버전의 파일을 캐시하고 있어, 최신 버전의 파일을 로드하지 못하는 경우입니다.
빌드 불일치:
- 서버에 배포된 파일과 클라이언트에서 요청하는 파일의 버전이 일치하지 않는 경우입니다. 예를 들어, 사용자가 애플리케이션을 사용하는 도중에 새로운 버전이 배포되어, 기존의 청크 파일이 삭제된 경우입니다.

해결 방법:

캐싱 전략 개선*:
- 청크 파일의 이름에 해시를 포함시켜 파일 변경 시 새로운 이름으로 생성되도록 합니다. 이를 통해 브라우저가 최신 파일을 로드하도록 유도합니다.
서비스 워커 활용:
- 서비스 워커를 사용하여 새로운 버전이 배포되었을 때 사용자에게 알리고, 페이지를 새로고침하도록 유도할 수 있습니다.
에러 핸들링 추가:
- 청크 로드 에러를 감지하여 사용자에게 알리고, 페이지를 자동으로 새로고침하거나 적절한 조치를 취하도록 합니다.

캐싱 전략 개선*

1. 브라우저 캐싱과 문제점

브라우저는 웹사이트의 자원(예: JavaScript 파일, CSS 파일 등)을 한 번 다운로드한 후, 성능 향상을 위해 이를 **캐시(cache)**에 저장합니다. 이렇게 하면 동일한 자원을 다시 다운로드하지 않고 캐시에서 불러와 페이지 로딩 속도가 빨라집니다.

문제점: 만약 서버에서 자원이 업데이트되었지만 파일명이 동일하다면, 브라우저는 캐시된 오래된 파일을 계속 사용할 수 있습니다. 이로 인해 사용자는 최신 변경 사항을 보지 못할 수 있습니다.

2. 해시를 파일명에 포함하는 이유

파일명에 **해시(hash)**를 추가하면, 파일 내용이 변경될 때마다 새로운 해시 값이 생성되어 파일명이 달라집니다. 이렇게 하면 브라우저는 파일명이 변경된 것을 감지하고, 캐시를 무시하고 최신 파일을 다시 다운로드합니다.

예시:

변경 전: main.js
변경 후: main.abc123.js (파일 내용 변경 시 해시 값 abc123 추가)

이러한 방식으로 파일명이 변경되면, 브라우저는 이를 새로운 파일로 인식하여 최신 버전을 로드하게 됩니다.

3. Webpack에서 해시 적용 방법

Webpack과 같은 모듈 번들러를 사용하면, 설정을 통해 파일명에 해시를 자동으로 추가할 수 있습니다. 이를 위해 output.filename 옵션에 [contenthash]를 사용합니다.

const path = require('path');

module.exports = {
  entry: './src/index.js',
  output: {
    filename: '[name].[contenthash].js', // 각 청크에 대해 contenthash 적용
    path: path.resolve(__dirname, 'dist'),
    clean: true, // 이전 빌드 파일 정리
  },
  // 추가적인 설정...
};

위 설정에서 [name]은 청크의 이름을, [contenthash]는 해당 청크의 내용 기반 해시를 의미합니다. 이렇게 하면 파일 내용이 변경될 때마다 새로운 해시 값이 생성되어 파일명이 달라집니다.

파일 내용이 변경되지 않았다면 동일한 해시 값을 가지므로, 브라우저는 기존 캐시를 재사용하여 불필요한 다운로드를 방지합니다.
변경 사항 즉시 반영: 파일 내용이 변경되면 새로운 해시 값이 적용된 파일명이 생성되어, 브라우저가 최신 파일을 로드합니다.

Next.js는 내부적으로 Webpack을 사용하여 빌드 프로세스를 관리하며, 프로덕션 환경에서 각 번들 파일의 이름에 **해시(hash)**를 자동으로 추가합니다. 이를 통해 파일 내용이 변경될 때마다 새로운 해시 값이 생성되어 브라우저가 최신 파일을 로드하도록 유도합니다. 따라서, 개발자가 별도로 Webpack의 output.filename 옵션을 설정하지 않아도 됩니다. 이러한 자동화된 해시 적용은 브라우저 캐싱 문제를 방지하고, 사용자에게 항상 최신 버전의 자산을 제공하는 데 도움이 됩니다.

ETag

기록하는 남자 — Sat, 5 Apr 2025 01:23:45 +0900

웹에서 캐시를 똑똑하게 하기 위해 사용하는 핵심 기술 중 하나가 바로 ETag입니다. ✨

ETag란?

"이 파일, 바뀐 거야? 안 바뀐 거야?"를 판단하기 위한 고유한 식별자

HTTP 응답 헤더에 포함돼서 브라우저에게 주어져요
이후 브라우저가 같은 리소스를 요청할 때, 이 ETag를 서버에 다시 보내면서 묻습니다:

"내가 가지고 있는 파일 ETag는 이건데, 바뀌었니?"

작동 방식

1. 클라이언트가 파일을 처음 요청

GET /main.js

2. 서버가 파일과 함께 ETag를 응답

200 OK ETag: "abc123" Content-Type: application/javascript

3. 클라이언트가 다음에 다시 요청할 때

GET /main.js If-None-Match: "abc123"

4. 서버가 확인 후 바뀐 게 없으면?

✅ 브라우저는 자기 캐시에 있는 파일을 그냥 씀
→ 네트워크 전송 없음 → 빠름!

ETag의 목적

목적	설명
캐시 최적화	변경되지 않았으면 재다운로드 안 함
네트워크 트래픽 감소	304 응답이면 파일 자체 안 보내도 됨
정확한 캐시 검증	단순 시간 기준(Last-Modified)보다 더 정밀하게 비교

ETag 값은 어떻게 만들어짐?

보통 파일의 내용(content) 기준으로 해시(hash)처럼 생성돼요
예: "abc123", "W/\"a1b2c3d4\""
→ 내용이 바뀌면 이 값도 바뀌어요

어디서 보냐?

크롬 개발자도구 → Network 탭 → 요청 헤더 & 응답 헤더 보면 이렇게 나옵니다:

Response Headers: ETag: "abc123" Request Headers: If-None-Match: "abc123"

요약

항목	설명
ETag	리소스 고유 ID (내용 기반)
목적	캐시된 파일이 변경됐는지 정확하게 확인
응답 예	ETag: "abc123"
장점	빠르고 정확한 캐시 판단, 네트워크 절약
주의	CDN/브라우저에 잘못된 ETag가 남으면 JS 깨질 수 있음

선언적 에러 처리

기록하는 남자 — Sat, 5 Apr 2025 00:31:29 +0900

선언적 에러 처리(declarative error handling)”**는 보통 프로그래밍 스타일에서 나오는 개념인데,
다른 방식인 명령형(imperative) 에러 처리랑 대비돼.

선언적 에러 처리란?

“무슨 일이 일어나야 하는지”에 집중하는 방식의 에러 처리

즉, 어떻게 처리할지를 직접 하나하나 코드로 지시하지 않고,
에러가 났을 때 자동으로 어떻게 반응할지를 선언적으로 지정해두는 거야.

예를 들어 보자: React / Next.js 기준

// React 18+
<Suspense fallback={<Loading />}>
  <SomeComponent />
</Suspense>

<ErrorBoundary fallback={<ErrorMessage />}>
  <ProblematicComponent />
</ErrorBoundary>

여기서 ErrorBoundary는 선언적 방식이야.

❌ 직접 try-catch 안 씀
✅ **“이 컴포넌트에서 에러 나면 이렇게 처리해”**라고 선언만 함

✅ 명령형 vs 선언형 에러 처리

구분	명령형 (Imperative)	선언형 (Declarative)
방식	직접 try-catch로 제어	에러 처리 "룰"을 선언
예시	try { ... } catch (e) { ... }	<ErrorBoundary fallback={...}>...</ErrorBoundary>
초점	"어떻게" 처리할지	"무슨 일이 나면" 처리할지

✅ 선언적 에러 처리가 잘 쓰이는 곳

React (Error Boundaries, Suspense)
Next.js (에러 페이지, app/error.tsx 같은 것들)
Zustand, Redux Toolkit (slice에서 에러 상태 지정)
GraphQL (Apollo Client에서 onError 핸들링)
RxJS (observable.catchError())

✨ 장점

코드가 깔끔해지고
관심사 분리가 잘 되고
유지보수가 쉬움
UI 흐름 제어가 자연스러움 (특히 React 같은 declarative 프레임워크에서)

요약

선언적 에러 처리란, ‘이 상황에서 이렇게 반응해’라고 선언만 해두는 방식의 에러 처리야.

[취업을 위한 CS 지식] 18강. CPU 스케줄링

기록하는 남자 — Thu, 3 Apr 2025 04:37:37 +0900

왜 CPU 스케줄링이 필요한가?

여러 프로세스나 스레드가 동시에 실행되려면 CPU를 나눠서 사용해야 한다.
하지만 CPU는 한 번에 하나의 작업만 처리할 수 있으므로, 어떤 프로세스가 언제 CPU를 사용할지 결정하는 과정이 필요하다.
이때 사용하는 것이 바로 CPU 스케줄링이다.

CPU 스케줄링의 대상이 되려면 'context(문맥)' 정보가 필요하다.
즉, 해당 프로세스가 어디까지 실행됐는지, 어떤 레지스터 값을 가졌는지 등 상태를 저장하고 불러올 수 있어야 한다.

CPU Utilization (CPU 활용률)

정의:
시스템이 가동되는 동안 CPU가 유휴(idle) 상태가 아닌 시간의 비율.
즉, CPU가 실제로 어떤 작업이든 수행한 시간 / 전체 시간.
CPU는 시스템의 핵심 자원이므로 효율적인 사용이 중요하지만, CPU 활용률이 높다는 것은 상황에 따라 해석이 달라질 수 있다. 적절한 수준(보통 60-80%)의 CPU 활용률은 자원을 효율적으로 사용한다고 볼 수 있지만, 지나치게 높은 활용률(90-100%)은 시스템 과부하나 병목 현상을 의미할 수 있다. 시스템 효율성은 CPU 활용률 외에도 처리량, 응답 시간, 다른 자원의 균형적 사용 등을 종합적으로 고려해야 한다.

프로세스의 특성과 스케줄링 전략

프로세스는 크게 두 가지 유형으로 나뉜다:

I/O 집중 프로세스 (I/O-bound process)
- CPU는 잠깐만 쓰고 대부분의 시간은 입출력(I/O) 작업에 사용함.
CPU 집중 프로세스 (CPU-bound process)
- 대부분의 시간 동안 CPU를 사용함.

스케줄링 전략에 따라 효율이 크게 달라짐.

I/O 중심 프로세스에 우선순위를 줄 경우
→ CPU는 짧게 쓰고 I/O로 넘어가므로
→ 그 사이에 CPU 집중 프로세스가 CPU를 사용할 수 있어
→ CPU를 효율적으로 쓸 수 있음 (병렬 처리 효과 극대화)
CPU 중심 프로세스에 우선순위를 줄 경우
→ I/O 프로세스는 CPU를 잠깐 쓰려고 오래 대기해야 하므로
→ 전체 시스템 자원 활용이 비효율적임.

CPU 스케줄러의 역할

CPU 스케줄러는 Ready Queue 내에서 어떤 프로세스를 실행시킬지 결정한다.
다양한 스케줄링 알고리즘이 존재 (FCFS, SJF, Round Robin 등)

선점형 스케줄링 (Preemptive Scheduling)

정의:

현재 실행 중인 프로세스를 강제로 중단시키고, 더 높은 우선순위의 프로세스나 다른 프로세스를 CPU에 할당하는 방식.

특징:

CPU를 사용할 수 있는 여러 프로세스들이 경쟁함.
우선순위, 남은 실행 시간, 응답 시간 등을 기준으로 더 적합한 프로세스가 있으면 선점 발생.
시스템 반응성이 좋음.

예시 스케줄링 알고리즘:

Round Robin
Shortest Remaining Time First (SRTF)
Priority Scheduling (선점형 방식일 경우)

예:

게임 중 알림(전화, 메시지 등)이 오면 현재 게임이 멈추고 알림 처리 → 선점형.

비선점형 스케줄링 (Non-Preemptive Scheduling)

정의:

한 번 CPU를 할당받은 프로세스는 스스로 작업을 끝내거나 입출력을 요청할 때까지 CPU를 계속 사용.

특징:

현재 실행 중인 프로세스가 CPU를 자발적으로 놓기 전까지 다른 프로세스는 대기.
선점이 없기 때문에 컨텍스트 스위칭 오버헤드가 적음.
다만 시스템 반응성은 떨어짐.

예시 스케줄링 알고리즘:

First-Come, First-Served (FCFS)
Shortest Job First (SJF, 비선점형)
Priority Scheduling (비선점형 방식일 경우)

예:

프린터로 문서를 출력하는 중엔 아무리 급한 문서가 있어도 현재 문서가 끝나야 출력됨 → 비선점형.

비교 정리

항목	선점형	비선점형
CPU 회수	강제로 회수 가능	자발적 반환만 가능
반응성	빠름	느림
복잡도	높음 (컨텍스트 스위칭 발생)	낮음
예시	Round Robin, SRTF	FCFS, SJF (비선점)

1. 선입 선처리(FCFS, First Come First Served)

개념

먼저 도착한 프로세스부터 CPU 할당하는 방식 (비선점형)
FIFO 방식 (큐에 먼저 들어온 순서대로 처리)

장점

구조가 단순하고 구현이 쉬움

단점

호위 효과 (Convoy Effect) 발생 가능
→ 실행 시간이 긴 프로세스가 먼저 도착하면, 뒤에 있는 짧은 프로세스들이 오랫동안 대기
응답 시간이 불균형함

convoy 호송하다, 호위하다 - 줄지어 행렬해서 뒤에는 느려짐.

2. 최단 작업 우선(SJF, Shortest Job First)

개념

실행 시간이 가장 짧은 프로세스에게 먼저 CPU를 할당
기본적으로 비선점형이지만, 선점형으로도 구현 가능 (SRT)

장점

평균 대기 시간이 가장 짧음

단점

실행 시간이 예측 가능해야 함
긴 작업은 계속 밀릴 수 있음 (starvation 가능성)

3. 라운드 로빈(Round Robin)

개념

FCFS 방식에 타임 슬라이스(time slice) 개념을 추가한 선점형 스케줄링
각 프로세스에 일정 시간만 CPU 할당 → 그 시간이 지나면 다음 프로세스로 전환

장점

모든 프로세스가 공평하게 CPU 사용
시스템 응답성이 좋음

단점

너무 짧은 타임 슬라이스는 오버헤드 증가
너무 긴 타임 슬라이스는 FCFS와 유사

4. 최소 잔여 시간 우선(SRT, Shortest Remaining Time)

개념

SJF의 선점형 버전
실행 중인 프로세스보다 더 잔여 시간이 짧은 프로세스가 도착하면 선점 발생

장점

평균 대기 시간이 매우 짧음
응답 속도도 빠름

단점

프로세스의 전체 실행 시간 추정 필요
잦은 선점으로 인한 컨텍스트 스위칭 오버헤드

5. 우선순위(Priority) 스케줄링

개념

각 프로세스에 우선순위 부여 → 높은 우선순위 먼저 실행
선점형 또는 비선점형 모두 가능

문제점

기아 현상 (Starvation)
→ 우선순위 낮은 프로세스가 계속 대기할 수 있음

해결 방법

에이징(Aging)
→ 오래 기다리는 프로세스의 우선순위를 점점 올려주는 방식

6. 다단계 큐 스케줄링 (Multilevel Queue Scheduling)

개념:

우선순위에 따라 여러 개의 큐(레벨)로 나눔
각 큐는 서로 독립적이고, 큐 간 이동이 없음
항상 가장 우선순위가 높은 큐에 있는 프로세스를 먼저 처리
→ 그 큐가 비어야 다음 우선순위 큐로 넘어감

특징:

각 큐는 다른 스케줄링 방식을 가질 수 있음 (예: 시스템 큐 = RR, 사용자 큐 = FCFS)
고정된 분류에 따라 프로세스가 큐에 들어가고, 절대 다른 큐로 이동하지 않음

단점:

큐 사이 전환이 불가 → 유연성이 떨어짐
낮은 우선순위 큐의 starvation 가능성 있음

7. 다단계 피드백 큐 스케줄링 (Multilevel Feedback Queue Scheduling)

개념:

다단계 큐 + 피드백 기능 결합
프로세스가 큐 사이를 이동 가능함
→ CPU 사용 시간에 따라 우선순위가 변동됨

동작 방식:

처음에는 가장 높은 우선순위 큐에 들어감
정해진 타임 슬라이스 내에 작업을 끝내면 종료
끝내지 못하면 우선순위가 낮은 큐로 이동
반대로, 오랫동안 대기한 프로세스는 aging을 통해 우선순위가 높아질 수 있음

목적:

CPU 집중형 프로세스와 입출력 집중형 프로세스를 구분하여 효율적으로 처리
시스템 반응성 향상 + 공정성 보장

장점:

유연하고, 다양한 프로세스 처리 가능
starvation 방지 (aging 덕분)

단점:

설계 및 구현이 복잡함
→ 큐의 수, 각 큐의 우선순위, 타임 슬라이스, 큐 이동 기준 등을 세밀하게 설계해야 함
타임 슬라이스 설정이 까다로움
→ 너무 짧으면 문맥 교환 증가, 너무 길면 반응성 저하
우선순위 조정 기준이 명확하지 않음
→ CPU 사용량이나 대기 시간 기준이 모호할 수 있음

리눅스의 CPU 스케줄링 정책 개요

리눅스는 여러 유형의 프로세스를 처리하기 위해 다양한 스케줄링 정책을 제공합니다. 크게 두 가지로 나뉩니다:

1️⃣ 실시간 프로세스를 위한 정책 (Real-time)

SCHED_FIFO (First In First Out)
SCHED_RR (Round Robin)

2️⃣ 일반 프로세스를 위한 정책

SCHED_NORMAL
SCHED_BATCH
SCHED_IDLE

각 스케줄링 정책 설명

정책	이름설명
SCHED_FIFO	실시간성 보장 필요 시 사용, 먼저 들어온 프로세스가 CPU를 계속 가짐 (선점 안 됨)
SCHED_RR	FIFO 기반 + 타임 슬라이스 (선점 가능, 실시간에서 사용)
SCHED_NORMAL	일반적인 사용자 프로세스에 사용, CFS(Completely Fair Scheduler) 기반
SCHED_BATCH	백그라운드 작업용, 인터랙티브 반응 필요 없는 배치 처리
SCHED_IDLE	CPU가 완전히 놀고 있을 때만 실행됨 (가장 낮은 우선순위)

❓ Q1. CPU가 놀고 있을 때 왜 정책(SCHED_IDLE)이 필요할까?

답변: 어떤 태스크는 중요하지 않고, 정말 시스템이 "할 일 없을 때만" 실행되길 바랄 수 있음.
- 예: 백그라운드에서 돌아가는 로그 정리, 통계 수집, 자동 백업 등
이럴 때 SCHED_IDLE로 태스크를 설정해두면 CPU가 유휴 상태일 때만 실행되고, 우선순위 높은 작업이 생기면 즉시 중단됨.
즉, 시스템 리소스를 전혀 방해하지 않도록 만든 정책임.

❓ Q2. SCHED_BATCH는 뭐고 왜 따로 있을까?

답변: SCHED_NORMAL은 **인터랙티브(사용자 반응)**에 최적화된 스케줄링이 적용됨. 예를 들어 마우스 클릭, 키보드 입력 등에 빠르게 반응해야 함.
하지만 어떤 프로세스는 사용자와 상호작용이 없는 순차적 작업만 한다면, 굳이 반응 속도를 신경 쓸 필요 없음.
- 예: 이미지 변환, 대량 데이터 처리, 보고서 생성 등.
이런 작업을 SCHED_BATCH로 설정하면, 인터랙티브 프로세스보다 CPU 우선순위는 낮지만, 효율적으로 긴 작업을 수행할 수 있도록 스케줄링됨.
CFS 안에서 처리되긴 하지만 반응성 평가를 하지 않음 → 더 효율적인 CPU 사용 가능.

❓ Q3. 왜 SCHED_FIFO가 실시간 보장을 하는 걸까?

답변: SCHED_FIFO는 "진짜로 선점이 없는" 스케줄링을 보장함.
- 어떤 실시간 태스크가 한 번 CPU를 잡으면 스스로 끝내거나 블록될 때까지 절대 빼앗기지 않음.
이 방식은 **시간 민감한 작업(예: 오디오 처리, 산업 제어)**에서 중요함.
- 예: 로봇 제어에서 "0.05초 안에 명령 내려야 함" → 절대 딜레이 허용 불가
단점은, 무한 루프 같은 실수를 하면 시스템 전체가 멈출 수 있음. 그래서 정말 조심해서 써야 하는 정책임.

CFS (Completely Fair Scheduler) – 리눅스 기본 스케줄러

CFS는 SCHED_NORMAL 정책에 적용되며, 프로세스에게 공평하게 CPU 시간을 분배하기 위해 만들어졌습니다.

vruntime (가상 실행 시간, virtural runtime)

프로세스의 실제 실행 시간이 아니라,
우선순위를 고려한 실행 시간

vruntime = 실제 실행 시간 × (기본 weight / 해당 프로세스 weight)

목적: CFS가 각 프로세스가 CPU를 얼마나 "공정하게" 사용했는지를 판단하기 위해 사용
핵심: 우선순위가 높은 프로세스는 vruntime이 느리게 증가 → 더 오래 실행될 수 있음

우선순위(nice)	숫자가 작을수록 우선순위 높음 (-20이 제일 높음, 19가 제일 낮음)
가중치(weight)	우선순위 높을수록 weight가 커짐
vruntime 증가 속도	weight가 커지면 vruntime 천천히 증가 → 자주 실행됨

상황 예시

Round 1:
  A, B 모두 vruntime이 비슷하다고 가정하면,
  CFS는 vruntime이 더 작은 A를 먼저 실행시킴.

Round 2:
  A는 실행되었지만 vruntime이 조금밖에 안 늘었음.
  B는 안 돌았기 때문에 vruntime 그대로.

  결과: 여전히 A의 vruntime이 작거나 비슷하므로, 또 A 실행.

Round 3:
  A 또 실행 → vruntime 조금 증가
  B는 여전히 큐에서 대기

...

이런 식으로 A는 계속 선택되기 쉬움 → 더 자주 실행됨

CFS의 타임 슬라이스 계산

타임 슬라이스는 고정값이 아닌 가중치(weight) 비율에 따라 동적으로 결정됩니다.

타임 슬라이스 = (프로세스 weight / 전체 weight 합) × CFS 큐에 대기하는 프로세스들의 타임 슬라이스 총량

목적: 이번 턴에 해당 프로세스가 CPU를 얼마나 오랫동안 사용할 수 있을지를 결정
핵심: 우선순위가 높은 프로세스는 더 긴 타임슬라이스를 받음

항목	vruntime 계산	타임슬라이스 계산
목적	공정성 판단 (누가 더 CPU 많이 썼는지 비교)	CPU 점유 시간 배정
작동 시점	프로세스가 실행된 후 vruntime에 반영	실행 전, 얼마나 CPU 줄지 계산
↕️ 우선순위 영향	높을수록 vruntime 증가가 느려짐 → 더 자주 실행	높을수록 더 많은 타임슬라이스 할당됨

프로세스의 스케줄링 정보 확인 방법

cat /proc/<PID>/sched

se.vruntime: 현재까지 누적된 가상 실행 시간
se.load.weight: 프로세스의 가중치 (우선순위 기반)
prio: 우선순위 값 (숫자가 낮을수록 우선순위 높음)

RB 트리 (Red-Black Tree)

CFS는 vruntime이 가장 작은 프로세스를 빨리 찾기 위해
RB 트리 자료구조 사용
효율적으로 최소값을 탐색 → 빠른 스케줄링 결정

[삼성 코테 기출] 감시

기록하는 남자 — Wed, 2 Apr 2025 23:02:24 +0900

https://www.acmicpc.net/problem/15683

완전탐색이다.

2차원배열을 쓰는 경우, 가능한 방향들을 노드라고 두고 그래프를 만들어서 탐색해나간다.
watch처럼 행동이 길어질 수 있는 연산은 추상화하고 코드를 구상해본다.

#include <iostream>
#include <vector>
#include <algorithm>
using namespace std;

int N, M;
int office[8][8];
int min_blind = 1e9;

vector<pair<int, int>> cctvs;
vector<int> cctv_type;

// 방향: 상 우 하 좌
int dy[4] = {-1, 0, 1, 0};
int dx[4] = {0, 1, 0, -1};

// 각 CCTV의 가능한 방향 조합
vector<vector<vector<int>>> directions = {
    {}, // 0번 CCTV 없음
    {{0}, {1}, {2}, {3}}, // 1번
    {{0, 2}, {1, 3}},     // 2번
    {{0, 1}, {1, 2}, {2, 3}, {3, 0}}, // 3번
    {{0, 1, 2}, {1, 2, 3}, {2, 3, 0}, {3, 0, 1}}, // 4번
    {{0, 1, 2, 3}} // 5번
};

// 감시 함수
void watch(int y, int x, int dir, int temp[8][8]) {
    while (true) {
        y += dy[dir];
        x += dx[dir];
        if (y < 0 || y >= N || x < 0 || x >= M || temp[y][x] == 6) break;
        if (temp[y][x] == 0)
            temp[y][x] = -1; // 감시 표시
    }
}

// 백트래킹
void dfs(int depth, int board[8][8]) {
    if (depth == cctvs.size()) {
        int cnt = 0;
        for (int i = 0; i < N; ++i)
            for (int j = 0; j < M; ++j)
                if (board[i][j] == 0)
                    cnt++;
        min_blind = min(min_blind, cnt);
        return;
    }

    int y = cctvs[depth].first;
    int x = cctvs[depth].second;
    int type = cctv_type[depth];

    for (auto &dirs : directions[type]) {
        int temp[8][8];
        copy(&board[0][0], &board[0][0] + 64, &temp[0][0]); // 배열 복사
        for (int d : dirs)
            watch(y, x, d, temp);
        dfs(depth + 1, temp);
    }
}

int main() {
    ios::sync_with_stdio(false);
    cin.tie(nullptr);

    cin >> N >> M;

    for (int i = 0; i < N; ++i)
        for (int j = 0; j < M; ++j) {
            cin >> office[i][j];
            if (1 <= office[i][j] && office[i][j] <= 5) {
                cctvs.push_back({i, j});
                cctv_type.push_back(office[i][j]);
            }
        }

    dfs(0, office);
    cout << min_blind << '\n';
    return 0;
}

플로이드-워셜 Floyd-Warshall

기록하는 남자 — Tue, 1 Apr 2025 03:39:18 +0900

#include <iostream>
#include <vector>
#include <climits>

using namespace std;

const int INF = 1e9; // 무한대 값 (INT_MAX 써도 됨)

// 1️⃣ Floyd-Warshall 알고리즘
// - 정점 수: V
// - 거리 행렬: dist[i][j] = i에서 j까지 최단 거리
// - 핵심 로직: 3중 for문으로 모든 경유점 k를 기준으로 경로를 갱신
//   시간복잡도: O(V³)
void floydWarshall(vector<vector<int>>& dist) {
    int V = dist.size();

    for (int k = 0; k < V; ++k) {         // 1️⃣ 경유 노드 k 선택 → O(V)
        for (int i = 0; i < V; ++i) {     // 2️⃣ 출발 노드 i → O(V)
            for (int j = 0; j < V; ++j) { // 3️⃣ 도착 노드 j → O(V)
                // i → k → j 경로가 기존 i → j보다 짧으면 갱신
                if (dist[i][k] < INF && dist[k][j] < INF) {
                    dist[i][j] = min(dist[i][j], dist[i][k] + dist[k][j]);
                }
            }
        }
    }
}

int main() {
    int V = 4; // 정점 수
    vector<vector<int>> dist(V, vector<int>(V, INF));

    // 2️⃣ 자기 자신까지는 거리 0 설정 → O(V)
    for (int i = 0; i < V; ++i) {
        dist[i][i] = 0;
    }

    // 3️⃣ 간선 정보 입력 → O(E)
    // 예: A → B (가중치)
    dist[0][1] = 5;
    dist[0][3] = 10;
    dist[1][2] = 3;
    dist[2][3] = 1;

    // 4️⃣ 최단 거리 계산
    floydWarshall(dist);

    // 5️⃣ 결과 출력 → O(V²)
    cout << "모든 쌍 최단 거리 행렬:\n";
    for (int i = 0; i < V; ++i) {
        for (int j = 0; j < V; ++j) {
            if (dist[i][j] == INF) cout << "INF ";
            else cout << dist[i][j] << " ";
        }
        cout << endl;
    }

    return 0;
}

/*
  전체 시간복잡도 요약:

1. 초기화
   - 자기 자신까지 거리 0 → O(V)
   - 간선 입력 → O(E)

2. 플로이드-워셜 알고리즘
   - 3중 for문 (경유지 k, 출발 i, 도착 j)
   - 각 루프 O(V)
   - 총 시간복잡도: O(V³)

3. 출력
   - 거리 행렬 출력 → O(V²)

  최종 시간복잡도 합산:

    O(V + E)      ← 초기화
  + O(V³)         ← 최단 거리 계산
  + O(V²)         ← 출력
  ---------------------------
  = **O(V³)** ✅ (지배항)

※ 간선 수(E)는 상수 수준이고, 전체 시간복잡도는 V³에 지배됨
*/

알고리즘음수 간선음의 사이클사용 목적

다익스트라	❌ 안 됨	❌ 안 됨	단일 시작점 최단 거리
벨만-포드	✅ 됨	✅ 감지 가능	단일 시작점 + 음수
플로이드-와샬	✅ 됨	❌ 안 됨	모든 쌍 최단 거리

플로이드-와샬은 음수 간선은 잘 처리할 수 있다. 단, 음의 사이클이 있으면 못한다.
그래서 dist[i][i] < 0 임을 확인해서 음의 사이클 감지