프로그래밍 언어는 문법만 다른 것이 아니라 타입을 다루는 방식, 객체 모델, 메모리 관리 방식, 함수 호출 방식, 동시성 모델에서 큰 차이가 있다. JavaScript, Java, Python, C++을 같은 기준으로 비교하면 각 언어가 왜 특정 분야와 프레임워크에서 많이 사용되는지도 함께 이해할 수 있다.

1. 전체 특징 한눈에 보기

2. 실행 방식과 Runtime

언어마다 작성한 코드가 CPU에서 실행되기까지의 과정이 다르다.

C++

Source
  ↓ Compiler
Machine Code
  ↓
CPU

Java

Source
  ↓ javac
Bytecode
  ↓
JVM
  ↓ JIT
Machine Code

Python

Source
  ↓
Bytecode
  ↓
Python VM

JavaScript

Source
  ↓
JS Engine
  ↓
Bytecode / JIT
  ↓
Machine Code

JavaScript

브라우저나 Node.js 같은 Runtime에서 실행된다. V8 같은 JavaScript Engine이 코드를 해석하고 필요에 따라 JIT 컴파일을 이용해 최적화한다.

브라우저에서는 JavaScript Engine뿐 아니라 DOM, Timer, fetch 같은 Web API도 함께 사용한다.

Java

소스 코드를 먼저 Bytecode로 컴파일하고 JVM이 이를 실행한다.

JVM은 실행 중 자주 사용되는 코드를 JIT 컴파일하여 Native Code로 최적화한다. JVM이 메모리 관리, Garbage Collection, Thread 관리도 담당한다.

Python

일반적인 CPython 구현에서는 소스 코드가 Bytecode로 변환되고 Python Virtual Machine이 이를 실행한다.

흔히 인터프리터 언어라고 부르지만 내부적으로 Bytecode 단계가 존재한다.

C++

실행 전에 Native Machine Code로 컴파일된다.

별도의 JVM이나 Python VM 없이 OS와 CPU에서 직접 실행되기 때문에 성능과 제어력이 높다.

핵심

Compile Time
→ 프로그램 실행 전 검사·변환 단계

Runtime
→ 프로그램이 실제 실행되는 시점과 환경

AOT
→ 실행 전에 Machine Code 생성

JIT
→ 실행 중 Machine Code로 컴파일·최적화

3. 타입 시스템

타입 시스템에서 가장 먼저 볼 것은 타입이 언제 결정되고 검사되는가이다.

정적 타입: Java / C++

변수를 선언할 때 타입이 정해지고 컴파일 단계에서 타입을 검사한다.

int age = 20;
String name = "Kim";

int age = 20;
std::string name = "Kim";

잘못된 타입을 사용하면 실행 전에 많은 오류를 발견할 수 있다.

int age = "20"; // Compile Error

동적 타입: JavaScript / Python

변수에 타입을 고정하지 않고 실행 중 값에 따라 타입이 결정된다.

let value = 10;
value = "hello";
value = true;

value = 10
value = "hello"

Python에서는 Type Hint를 사용할 수 있다.

def add(a: int, b: int) -> int:
    return a + b

하지만 기본적으로 Runtime에서 강제되는 것은 아니다.

JavaScript의 특징

암묵적 타입 변환이 존재한다.

1 == "1"   // true
1 === "1"  // false

따라서 일반적으로 === 사용을 권장한다.

핵심

Java / C++
→ Compile Time에 타입 검사

JavaScript / Python
→ Runtime에 타입이 결정되는 동적 타입

4. 값 / 객체 / 참조 / Pointer

객체를 이해할 때 가장 중요한 것은 변수에 실제 값이 들어가는지, 객체를 가리키는 정보가 들어가는지 구분하는 것이다.

JavaScript

Primitive와 Object를 구분한다.

const user = {
    name: "Kim"
};

const a = user;
const b = a;

b.name = "Lee";

console.log(a.name); // Lee

a, b가 같은 객체를 가리키고 있기 때문에 한쪽에서 객체를 수정하면 다른 쪽에서도 보인다.

객체 비교 역시 참조 기준이다.

{} === {} // false

Java

Primitive Type과 Reference Type을 구분한다.

int age = 20;
User user = new User();

개념적으로:

Stack                     Heap

age = 20

user ───────────────────→ User 객체
                           name
                           age

객체 변수에는 객체 전체가 아니라 객체를 가리키는 Reference가 저장된다.

Python

Python에서는 거의 모든 것이 객체다.

a = [1, 2]
b = a

b.append(3)

print(a)  # [1, 2, 3]

변수는 객체 자체라기보다 객체를 가리키는 이름처럼 이해하면 편하다.

C++

값, Pointer, Reference를 명시적으로 구분한다.

int a = 10;

int* p = &a;   // Pointer
int& r = a;    // Reference

• Pointer → 메모리 주소 저장
• Reference → 기존 객체의 별칭
• Value → 값 자체

C++은 이 차이를 개발자가 직접 다룬다는 점이 다른 언어와 크게 다르다.

5. 함수 호출과 인자 전달

Java

Java는 항상 Call by Value다.

void change(User user) {
    user.name = "Lee";
}

객체를 전달할 때도 객체 자체가 아니라 Reference 값의 복사본이 전달된다.

따라서 객체 내부 변경은 반영된다.

void change(User user) {
    user.name = "Lee";
}

하지만 매개변수를 다른 객체로 바꾸는 것은 외부 변수에 영향을 주지 않는다.

void change(User user) {
    user = new User();
}

JavaScript

JavaScript도 Call by Value다.

객체를 전달하면 객체를 가리키는 참조값이 복사된다.

function change(obj) {
    obj.name = "Lee";
}

const user = { name: "Kim" };

change(user);

console.log(user.name); // Lee

Python

Python은 일반적으로 Call by Sharing(Object Sharing)이라고 설명한다.

def change(arr):
    arr.append(3)

a = [1, 2]
change(a)

print(a)  # [1, 2, 3]

Mutable 객체 내부를 수정하면 외부에서도 변경이 보인다.

하지만 재바인딩은 외부에 영향을 주지 않는다.

def change(arr):
    arr = []

a = [1, 2]
change(a)

print(a)  # [1, 2]

C++

C++은 값 전달과 참조 전달을 직접 선택한다.

void change(int x) {
    x = 10;
}

값 전달.

void change(int& x) {
    x = 10;
}

참조 전달.

큰 객체는 복사 비용을 줄이기 위해 const reference를 많이 사용한다.

void print(const User& user) {
}

6. 객체 모델

Java

전형적인 Class 기반 객체지향 언어다.

Class
  ↓
Object

class User {
    String name;

    void hello() {
        System.out.println(name);
    }
}

주요 개념:

Encapsulation
Inheritance
Polymorphism
Abstraction
Interface

C++

C++ 역시 Class 기반 객체지향 언어다.

class Animal {
public:
    virtual void sound() {}
};

class Dog : public Animal {
public:
    void sound() override {}
};

생성자와 소멸자, virtual 함수, 객체 생명주기가 중요한 특징이다.

Python

Python도 Class 기반이지만 훨씬 동적이다.

class User:
    def __init__(self, name):
        self.name = name

user = User("Kim")
user.age = 20

Runtime에 객체 속성을 추가하는 것도 가능하다.

함수와 클래스 자체도 객체이기 때문에 Decorator 같은 기능도 자연스럽게 사용할 수 있다.

JavaScript

JavaScript는 본질적으로 Prototype 기반이다.

Object
  ↓
Prototype
  ↓
Prototype

예를 들어:

const arr = [1, 2, 3];

arr.map(x => x * 2);

map()을 찾을 때 Prototype Chain을 따라 Array.prototype까지 탐색한다.

JavaScript의 class는 Prototype 기반 객체 모델을 편리하게 사용하는 문법이다.

7. Mutable / Immutable / Equality

Mutable / Immutable

Mutable은 객체 내부 상태를 변경할 수 있다는 의미이고, Immutable은 생성된 값을 변경할 수 없다는 의미다.

JavaScript

객체와 배열은 기본적으로 Mutable이다.

const user = {
    name: "Kim"
};

user.name = "Lee"; // 가능

const는 객체가 Immutable이라는 의미가 아니다.

user = {}; // Error

단지 변수 재할당을 막는다.

Java

일반 객체는 Mutable할 수 있지만 String은 Immutable이다.

String s = "hello";

s = s + " world";

기존 문자열이 바뀐 것이 아니라 새로운 String 객체가 만들어진다.

Python

Mutable:

list
dict
set

Immutable:

int
float
str
tuple

C++

const를 통해 변경 가능성을 적극적으로 제어한다.

const int x = 10;

void print(const User& user) {
}

Equality / Identity

값이 같은 것과 같은 객체인 것은 다른 개념이다.

JavaScript

{} === {} // false

객체는 Reference를 비교한다.

Java

a == b       // Reference 비교
a.equals(b) // 값 비교

Python

a == b // 값 비교
a is b // 동일 객체 비교

C++

operator==를 오버로딩하여 값 비교 의미를 직접 정의할 수 있다.

bool operator==(const User& other) const {
    ...
}

8. 메모리 관리와 객체 생명주기

JavaScript

Garbage Collector가 사용하지 않는 객체를 정리한다.

객체 생성
↓
Reference 존재
↓
Reference가 모두 사라짐
↓
GC 대상

하지만 Closure, Event Listener, Timer 등이 객체를 계속 참조하고 있으면 불필요한 객체가 유지될 수 있다.

Java

JVM의 Garbage Collector가 Heap 객체를 관리한다.

GC Root에서 더 이상 도달할 수 없는 객체가 수거 대상이 된다.

GC가 있다고 해서 메모리 누수가 불가능한 것은 아니다.

불필요한 Reference 유지
→ 객체가 계속 Reachable
→ GC가 제거하지 못함

Python

주로 Reference Counting 방식으로 관리한다.

Object Reference Count
3 → 2 → 1 → 0
             ↓
           제거

순환 참조는 별도의 Garbage Collector가 처리한다.

C++

기본적인 Garbage Collector가 없다.

대신 RAII(Resource Acquisition Is Initialization)가 핵심이다.

{
    std::lock_guard<std::mutex> lock(mutex);

    // 작업
}

Scope가 끝나면서 객체가 소멸되고 Lock도 자동 해제된다.

Smart Pointer도 사용한다.

std::unique_ptr<User>
std::shared_ptr<User>
std::weak_ptr<User>

9. 함수 / Scope / Closure

JavaScript

함수가 일급 객체다.

const add = (a, b) => a + b;

function run(fn) {
    return fn(1, 2);
}

함수를 변수에 저장하고, 인자로 전달하고, 반환할 수 있다.

Closure도 핵심이다.

function outer() {
    let count = 0;

    return () => ++count;
}

const counter = outer();

counter(); // 1
counter(); // 2

JavaScript는 Lexical Scope를 사용한다.

또한 일반 함수와 화살표 함수의 this 동작이 다르다.

Python

Python에서도 함수는 일급 객체다.

def add(a, b):
    return a + b

fn = add
fn(1, 2)

Decorator와 Closure도 자주 사용한다.

def decorator(fn):
    def wrapper():
        print("before")
        fn()

    return wrapper

Python의 Scope는 LEGB 규칙을 따른다.

Local
Enclosing
Global
Built-in

Java

기본적으로 객체와 Method 중심이다.

Lambda와 Functional Interface를 통해 함수형 스타일을 사용할 수 있다.

list.stream()
    .filter(x -> x > 10)
    .map(x -> x * 2)
    .toList();

C++

Lambda와 함수 포인터를 사용할 수 있다.

auto add = [](int a, int b) {
    return a + b;
};

외부 변수 Capture도 가능하다.

[=] // 값 Capture

[&] // Reference Capture

10. Thread / 동시성 / 비동기

먼저 세 개념을 구분해야 한다.

Concurrency
→ 여러 작업을 함께 진행시키는 구조

Parallelism
→ 실제 여러 작업을 동시에 실행

Asynchronous
→ 작업 완료를 기다리지 않고 다른 작업 수행

JavaScript

기본 JavaScript 실행은 하나의 Main Thread에서 이루어진다.

Call Stack
    ↓
Event Loop
    ↓
Microtask Queue / Task Queue

Timer, Network, DOM Event 등은 Browser 또는 Node.js Runtime이 처리한다.

console.log("A");

setTimeout(() => {
    console.log("B");
}, 0);

console.log("C");

결과:

A
C
B

Promise와 async/await도 Event Loop와 연결된다.

async function getUsers() {
    const response = await fetch("/api/users");
    return response.json();
}

Single Thread ≠ 동시성 불가능
Async ≠ Multi Thread

Java

멀티스레드를 적극적으로 활용한다.

Request A → Thread 1
Request B → Thread 2
Request C → Thread 3

여러 Thread가 같은 객체를 공유하기 때문에 Thread Safety가 중요하다.

대표적으로:

synchronized
volatile
Atomic
ExecutorService
CompletableFuture
Virtual Thread

등을 사용한다.

Python

CPython에는 GIL(Global Interpreter Lock)이 있다.

여러 OS Thread를 만들 수 있지만 한 시점에는 하나의 Thread만 Python Bytecode를 실행한다.

따라서 일반적으로:

CPU Bound
→ multiprocessing

I/O Bound
→ threading / asyncio

방식을 사용한다.

asyncio는 Coroutine과 Event Loop를 이용한다.

C++

OS Thread를 직접 사용할 수 있다.

std::thread
std::mutex
std::atomic
std::condition_variable

그만큼 다음 문제를 직접 고려해야 한다.

Race Condition
Data Race
Deadlock

11. 프레임워크와 언어 특성

언어의 특성은 실제 프레임워크 설계에도 그대로 드러난다.

JavaScript + React / Node.js

React에서 특히 중요한 개념:

Function
Closure
Reference Equality
Immutability
Event Loop
Async

상태 변경과 렌더링을 제대로 이해하려면 객체 참조와 Closure를 이해해야 한다.

Node.js에서는 Event Loop와 비동기 I/O가 핵심이다.

Java + Spring

Spring에서 중요한 Java 특성:

Class / Object
Reflection
Annotation
Proxy
GC
Multi Thread
Thread Safety

Spring Bean은 기본적으로 Singleton이므로 여러 Thread가 동일 Bean을 동시에 사용할 수 있다.

따라서 Mutable 상태를 Bean 필드에 함부로 저장하면 Thread Safety 문제가 발생할 수 있다.

Python + FastAPI / Django

FastAPI:

Type Hint
Decorator
async / await
Coroutine

Python의 동적인 특성과 비동기 기능을 적극적으로 활용한다.

Django 역시 Class, Decorator, ORM 등 Python의 객체 모델을 많이 활용한다.

C++

C++은 특정 하나의 웹 프레임워크보다 다음 분야에서 많이 사용된다.

System Programming
Game Engine
Embedded
High Performance Application

이 환경에서는 특히:

Pointer / Reference
RAII
Object Lifetime
Memory Safety
Thread

에 대한 이해가 중요하다.

12. 핵심 비교

JavaScript
→ 동적 타입
→ Prototype 기반 객체 모델
→ Garbage Collector
→ 함수 / Closure 중심
→ Event Loop 기반 동시성

Java
→ 정적 타입
→ Class 기반 객체지향
→ JVM + Garbage Collector
→ Reference를 Call by Value로 전달
→ Multi Thread와 Thread Safety 중요

Python
→ 동적 타입
→ 거의 모든 것이 객체
→ Reference Counting + GC
→ 함수가 일급 객체
→ GIL + asyncio / multiprocessing

C++
→ 정적 타입
→ Class + Pointer + Reference
→ Native 실행
→ RAII 기반 자원 관리
→ Memory / Thread를 개발자가 직접 제어

결국 네 언어를 비교할 때는 다음 질문을 중심으로 보면 된다.

1. 코드는 어떤 Runtime에서 어떻게 실행되는가?
2. 타입은 언제 결정되고 검사되는가?
3. 변수는 값과 객체를 어떻게 저장하는가?
4. 함수에 인자를 넘기면 무엇이 전달되는가?
5. 객체 모델은 Class인가 Prototype인가?
6. 객체는 Mutable인가 Immutable인가?
7. 메모리와 객체 수명은 누가 관리하는가?
8. 함수와 Scope는 어떤 특징을 가지는가?
9. 여러 작업을 Thread / Event Loop / Async 중 어떻게 처리하는가?
10. 이러한 특성이 프레임워크에서 어떻게 활용되는가?

1. 변수 선언: let, const, var

JavaScript에서는 주로 let, const를 사용한다.

let age = 20;
const name = "Kim";

• let: 값 변경 가능
• const: 재할당 불가능
• var: 과거 문법. 함수 스코프와 호이스팅 문제 때문에 일반적으로 사용하지 않는다.

let a = 10;
a = 20; // 가능

const b = 10;
b = 20; // Error

기본적으로 const를 사용하고, 값이 바뀌어야 할 때만 let을 사용하는 방식이 일반적이다.

2. JavaScript의 주요 자료형

JavaScript의 기본 자료형은 다음과 같다.

let num = 10;              // number
let str = "hello";         // string
let bool = true;           // boolean
let empty = null;          // null
let value;                 // undefined
let big = 123n;            // bigint
let id = Symbol("id");     // symbol

Java와 다르게 정수와 실수를 별도의 타입으로 구분하지 않고 대부분 number로 처리한다.

typeof 10;    // "number"
typeof 3.14;  // "number"

3. 동적 타입 언어

JavaScript는 동적 타입 언어이다.

변수를 선언할 때 타입을 지정하지 않고, 실행 중에 다른 타입의 값을 넣을 수도 있다.

let value = 10;

value = "hello";
value = true;

Java에서는 변수의 타입이 고정되지만, JavaScript와 Python은 변수에 저장되는 값에 따라 타입이 결정된다.

4. 문자열

문자열은 ', ", 백틱 `을 사용할 수 있다.

const name = "Kim";
const age = 20;

백틱을 사용하면 문자열 안에 변수를 쉽게 넣을 수 있다.

const message = `이름은 ${name}, 나이는 ${age}살입니다.`;

이를 Template Literal이라고 한다.

5. 배열

JavaScript 배열은 서로 다른 타입의 값을 함께 저장할 수 있다.

const arr = [1, "hello", true];

주요 사용법:

arr.push(10);
arr.pop();

arr[0];
arr.length;

실제 웹 개발에서는 배열 자체보다 map, filter, find 같은 배열 메서드를 매우 자주 사용한다.

6. 객체

JavaScript에서 객체는 key-value 형태의 데이터를 저장한다.

const user = {
    name: "Kim",
    age: 20
};

값 접근:

user.name;
user["age"];

값 변경:

user.age = 21;

Java의 객체보다 Python의 dict와 비슷하게 느껴질 수 있지만, JavaScript에서는 객체가 언어 전체에서 매우 중요한 역할을 한다.

7. 함수

일반 함수:

function add(a, b) {
    return a + b;
}

함수 표현식:

const add = function(a, b) {
    return a + b;
};

화살표 함수:

const add = (a, b) => {
    return a + b;
};

한 줄이면 더 줄일 수 있다.

const add = (a, b) => a + b;

웹 개발, 특히 React에서는 화살표 함수를 매우 자주 사용한다.

8. 조건문과 반복문

Java와 거의 비슷하다.

if (age >= 20) {
    console.log("성인");
} else {
    console.log("미성년자");
}

반복문:

for (let i = 0; i < 5; i++) {
    console.log(i);
}

배열 순회에는 다음 방식도 자주 사용한다.

for (const value of arr) {
    console.log(value);
}

9. 구조 분해 할당

배열이나 객체에서 값을 쉽게 꺼낼 수 있는 문법이다.

const user = {
    name: "Kim",
    age: 20
};

const { name, age } = user;

배열에서도 사용할 수 있다.

const arr = [10, 20];

const [a, b] = arr;

React에서 매우 많이 등장한다.

const [count, setCount] = useState(0);

10. Spread 문법 ...

배열이나 객체의 값을 펼칠 때 사용한다.

const a = [1, 2];
const b = [...a, 3, 4];

객체:

const user = {
    name: "Kim",
    age: 20
};

const newUser = {
    ...user,
    age: 21
};

React에서 상태를 변경할 때 특히 자주 사용한다.

핵심 정리

let   → 재할당 가능
const → 재할당 불가능
var   → 가급적 사용하지 않음

JavaScript는 동적 타입 언어

배열 → []
객체 → {}

함수는 값처럼 변수에 저장 가능

() => {} → 화살표 함수

const { a, b } = obj
→ 구조 분해 할당

...arr / ...obj
→ Spread 문법

Part 2. JavaScript 타입 시스템

1. null vs undefined

둘 다 “값이 없음”을 나타내지만 의미가 다르다.

let a;
console.log(a); // undefined

let b = null;
console.log(b); // null

• undefined: 값이 아직 할당되지 않음
• null: 개발자가 의도적으로 “값 없음”을 넣음

실무에서는 API 응답, 초기 상태값, optional 값 처리할 때 자주 만난다.

2. == vs ===

1 == "1"   // true
1 === "1"  // false

==는 비교 전에 타입을 자동 변환한다.

===는 타입과 값이 모두 같은지 비교한다.

그래서 실무에서는 거의 항상:

if (a === b) {
}

처럼 ===를 사용한다.

3. 타입 강제 변환(Type Coercion)

JavaScript는 상황에 따라 타입을 자동으로 바꾼다.

"5" + 1   // "51"
"5" - 1   // 4

+는 문자열 연결로 동작할 수 있지만, -는 숫자 연산만 가능해서 숫자로 변환된다.

이런 암묵적 변환 때문에 JS에서 예상하지 못한 결과가 생길 수 있다.

4. Truthy / Falsy

JS에서는 boolean이 아니어도 조건문에서 참/거짓으로 판단된다.

Falsy 값:

false
0
""
null
undefined
NaN

이외 대부분의 값은 Truthy다.

if ("hello") {
    console.log("실행됨");
}

특히 주의할 것:

[]   // truthy
{}   // truthy

빈 배열과 빈 객체도 true 취급된다.

5. NaN

NaN은 Not a Number라는 뜻이다.

Number("hello"); // NaN

특이하게:

NaN === NaN // false

그래서 확인할 때는:

Number.isNaN(value);

을 사용한다.

6. typeof

타입 확인:

typeof 10          // "number"
typeof "hello"     // "string"
typeof true        // "boolean"
typeof undefined   // "undefined"
typeof {}          // "object"

그런데 유명한 예외가 있다.

typeof null // "object"

이건 JS 초기 설계에서 생긴 오래된 버그성 동작이다.

핵심 정리

undefined
→ 값이 아직 없음

null
→ 의도적으로 값 없음

== 
→ 타입 변환 후 비교

===
→ 타입 + 값 비교
→ 실무에서 기본 사용

Truthy / Falsy
→ 조건문에서 값 자체가 true/false처럼 평가됨

[]와 {}는 truthy

NaN
→ 숫자로 변환할 수 없는 값

typeof null === "object"
→ JS의 오래된 특이사항

Part 3. Scope와 실행 구조

1. Scope란?

Scope는 변수에 접근할 수 있는 범위다.

const a = 10;

function test() {
    const b = 20;
    console.log(a); // 가능
    console.log(b); // 가능
}

console.log(b); // 불가능

JS에는 크게 다음 범위가 있다.

Global Scope
Function Scope
Block Scope

2. Block Scope

let, const는 {} 단위로 범위가 나뉜다.

if (true) {
    const a = 10;
}

console.log(a); // Error

반면 var는 block scope가 아니라 function scope를 따른다.

if (true) {
    var a = 10;
}

console.log(a); // 10

이것도 var를 잘 쓰지 않는 이유 중 하나다.

3. Scope Chain

현재 범위에 변수가 없으면 바깥 범위로 올라가며 찾는다.

const a = 10;

function outer() {
    const b = 20;

    function inner() {
        console.log(a);
        console.log(b);
    }

    inner();
}

inner()는 자신의 scope → outer → global 순서로 변수를 찾는다.

이 구조를 Scope Chain이라고 한다.

4. Lexical Scope

JS는 함수가 어디에서 호출됐는지가 아니라, 어디에서 선언됐는지를 기준으로 바깥 scope를 결정한다.

const x = 10;

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

function run() {
    const x = 20;
    test();
}

run(); // 10

test()가 run() 안에서 호출됐지만, 선언된 위치가 global이므로 x = 10을 본다.

이걸 Lexical Scope라고 한다.

5. Execution Context

JS는 코드를 실행할 때 Execution Context(실행 컨텍스트)를 만든다.

쉽게 말하면:

현재 실행 중인 코드의 변수, 함수, scope 정보를 관리하는 실행 환경

함수가 호출될 때마다 새로운 실행 컨텍스트가 생성된다.

function a() {
    b();
}

function b() {
    console.log("hello");
}

a();

개념적으로:

Global Execution Context
        ↓
a() Execution Context
        ↓
b() Execution Context

가 만들어진다.

6. Call Stack

Execution Context는 Call Stack에 쌓인다.

function first() {
    second();
}

function second() {
    console.log("hello");
}

first();

실행 흐름:

Global
↓
first()
↓
second()
↓
second 종료
↓
first 종료

Stack이기 때문에 LIFO(Last In First Out) 구조다.

이 Call Stack 개념은 나중에 싱글 스레드와 Event Loop를 이해할 때 핵심이 된다.

핵심 정리

Scope
→ 변수에 접근할 수 있는 범위

let / const
→ block scope

var
→ function scope

Scope Chain
→ 변수를 현재 scope부터 바깥으로 찾아감

Lexical Scope
→ 함수가 선언된 위치 기준으로 scope 결정

Execution Context
→ 현재 실행 중인 코드의 환경 정보

Call Stack
→ 실행 컨텍스트가 쌓이는 구조
→ LIFO

Part 4. 함수와 Closure, this

1. JS에서 함수는 값이다

JavaScript에서 함수는 변수에 저장하거나, 다른 함수에 전달하거나, 반환할 수 있다.

const add = (a, b) => a + b;

즉 함수도 하나의 값처럼 다룬다.

2. Callback 함수

다른 함수에 인자로 전달되는 함수를 callback이라고 한다.

function run(callback) {
    callback();
}

run(() => console.log("hello"));

웹 개발에서 이벤트, 비동기 처리, 배열 메서드 등에 매우 자주 사용된다.

arr.map(x => x * 2);

3. 고차 함수

함수를 인자로 받거나 함수를 반환하는 함수를 고차 함수(Higher-Order Function)라고 한다.

대표적으로:

map()
filter()
reduce()

같은 배열 메서드가 있다.

4. Closure

Closure는 함수가 자신이 선언된 외부 Scope의 변수를 기억하는 특성이다.

function outer() {
    let count = 0;

    return () => {
        count++;
        return count;
    };
}

const counter = outer();

counter(); // 1
counter(); // 2

outer() 실행은 끝났지만 내부 함수가 count를 계속 기억한다.

즉:

함수 + 함수가 선언될 당시의 외부 환경
= Closure

React의 state, event handler, hook을 이해할 때 중요하다.

5. this

this는 현재 함수가 어떤 객체와 연결되어 실행되는지에 따라 값이 달라질 수 있다.

const user = {
    name: "Kim",

    hello() {
        console.log(this.name);
    }
};

user.hello(); // Kim

여기서 this는 user를 가리킨다.

6. 화살표 함수의 this

화살표 함수는 자신의 this를 새로 만들지 않는다.

바깥 Scope의 this를 그대로 사용한다.

const user = {
    name: "Kim",

    hello: () => {
        console.log(this.name);
    }
};

이 경우 this가 user를 가리킨다고 기대하면 안 된다.

그래서 객체 메서드에서는 일반 함수 문법을 사용하는 경우가 많다.

핵심 정리

JS에서 함수는 값처럼 사용 가능

Callback
→ 다른 함수에 전달되는 함수

고차 함수
→ 함수를 인자로 받거나 반환하는 함수

Closure
→ 함수가 외부 Scope의 변수를 기억하는 특성

this
→ 함수가 어떻게 호출되었는지에 따라 결정

화살표 함수
→ 자신의 this를 만들지 않음
→ 바깥 this 사용

Part 5. 객체 / Reference / Prototype / Class

1. 객체는 참조 타입

JS에서 객체와 배열은 값을 직접 복사하는 게 아니라 참조값을 다룬다.

const a = { name: "Kim" };
const b = a;

b.name = "Lee";

console.log(a.name); // Lee

a, b가 같은 객체를 가리키기 때문이다.

2. 얕은 복사

Spread를 사용하면 새 객체를 만들 수 있다.

const a = { name: "Kim", age: 20 };
const b = { ...a };

하지만 중첩 객체는 여전히 참조가 공유될 수 있다.

const a = {
    user: { name: "Kim" }
};

const b = { ...a };

b.user.name = "Lee";

console.log(a.user.name); // Lee

즉 ...은 기본적으로 얕은 복사(Shallow Copy)다.

3. 객체 비교

객체는 내용이 아니라 참조값을 비교한다.

{} === {} // false

반면:

const a = {};
const b = a;

a === b // true

같은 객체를 가리킬 때만 true다.

4. Prototype

JavaScript 객체는 다른 객체를 기반으로 기능을 상속받을 수 있다.

이 연결 구조가 Prototype이다.

예를 들어 배열에서:

const arr = [1, 2, 3];

arr.map(...)
arr.filter(...)

map, filter를 우리가 직접 만든 적이 없는데 사용할 수 있는 이유는 배열이 Array.prototype의 메서드를 상속받기 때문이다.

개념적으로:

arr
 ↓
Array.prototype
 ↓
Object.prototype

이렇게 prototype chain을 따라 메서드를 찾는다.

5. Prototype Chain

객체에서 어떤 속성이나 메서드를 찾을 때:

현재 객체에서 찾음
↓
없으면 prototype에서 찾음
↓
또 없으면 상위 prototype에서 찾음

이 구조를 Prototype Chain이라고 한다.

6. Class

JS에서도 Java처럼 class를 사용할 수 있다.

class User {
    constructor(name) {
        this.name = name;
    }

    hello() {
        console.log(`hello ${this.name}`);
    }
}

const user = new User("Kim");

하지만 JS의 class는 본질적으로 prototype 기반 구조를 더 익숙하게 표현한 문법이다.

7. 상속

class Animal {
    move() {
        console.log("move");
    }
}

class Dog extends Animal {
    bark() {
        console.log("bark");
    }
}

Java와 비슷하게 보이지만 내부적으로는 prototype chain을 사용한다.

핵심 정리

객체 / 배열
→ 참조 타입

const b = a
→ 같은 객체 참조

{ ...a }
→ 새 객체 생성
→ 하지만 얕은 복사

{} === {}
→ false
→ 객체는 참조값 비교

Prototype
→ 다른 객체의 기능을 상속받는 구조

Prototype Chain
→ 속성/메서드를 상위 prototype으로 찾아감

class
→ prototype 기반 객체 시스템을 감싼 문법

Part 6. 싱글 스레드 / 비동기 / Event Loop

1. JavaScript는 싱글 스레드

JavaScript는 기본적으로 한 번에 하나의 작업만 실행한다.

작업 A 실행
→ 작업 A 종료
→ 작업 B 실행

즉 JS 코드를 실행하는 Call Stack은 하나다.

2. 그럼 비동기는 어떻게 처리하나?

브라우저 환경에서는 오래 걸리는 작업을 브라우저가 대신 처리한다.

대표적으로:

setTimeout(...)
fetch(...)

개념적으로:

JavaScript
→ Call Stack

Browser
→ Timer
→ Network
→ DOM Event

JS 자체는 한 번에 하나만 실행하지만, 외부 작업은 브라우저가 처리할 수 있다.

3. Event Loop

비동기 작업이 끝나면 callback이 Queue에 들어간다.

Event Loop는 계속 확인한다.

Call Stack이 비었나?
↓
비었으면 Queue의 작업 실행

이 구조 덕분에 싱글 스레드에서도 비동기 처리가 가능하다.

4. 실행 순서 예시

console.log("A");

setTimeout(() => {
    console.log("B");
}, 0);

console.log("C");

결과:

A
C
B

setTimeout(..., 0)이라고 해도 바로 실행되는 것이 아니다.

callback은 Queue에서 기다리고, 현재 동기 코드가 모두 끝난 뒤 실행된다.

5. 동기 vs 비동기

동기:

const a = 1;
const b = 2;
console.log(a + b);

앞 작업이 끝나야 다음 작업이 실행된다.

비동기:

fetch("/api/users");
console.log("next");

네트워크 응답을 기다리는 동안 다음 코드가 계속 실행될 수 있다.

6. Callback 방식

초기 JS에서는 비동기 처리를 callback으로 많이 했다.

setTimeout(() => {
    console.log("done");
}, 1000);

하지만 여러 비동기 작업이 중첩되면 코드가 복잡해진다.

a(() => {
    b(() => {
        c(() => {
        });
    });
});

이런 형태를 흔히 Callback Hell이라고 한다.

7. Promise

Promise는 비동기 작업의 결과를 표현하는 객체다.

상태는 3개다.

pending
→ 진행 중

fulfilled
→ 성공

rejected
→ 실패

사용 예:

fetch("/api/users")
    .then(response => response.json())
    .then(data => console.log(data))
    .catch(error => console.error(error));

8. async / await

Promise를 더 읽기 쉽게 사용하는 문법이다.

async function getUsers() {
    const response = await fetch("/api/users");
    const data = await response.json();

    return data;
}

await는 Promise가 처리될 때까지 해당 async 함수의 다음 실행을 잠시 멈춘다.

중요한 점은 JS 전체 스레드를 멈추는 것은 아니다.

9. Microtask Queue

비동기 Queue가 하나만 있는 것은 아니다.

대표적으로:

Microtask Queue
→ Promise
→ async/await 후속 작업

Task Queue
→ setTimeout
→ setInterval
→ 일부 이벤트

일반적으로 현재 코드가 끝난 후:

Call Stack
↓
Microtask Queue
↓
Task Queue

순서로 처리된다.

10. 실행 순서 문제

console.log("A");

setTimeout(() => console.log("B"), 0);

Promise.resolve()
    .then(() => console.log("C"));

console.log("D");

결과:

A
D
C
B

이유:

동기 코드
→ A, D

Microtask
→ C

Task
→ B

핵심 정리

JavaScript
→ 싱글 스레드
→ Call Stack 하나

비동기 작업
→ 브라우저 Web API가 처리

작업 완료
→ Queue로 이동

Event Loop
→ Call Stack이 비면 Queue 작업 실행

Promise
→ 비동기 작업의 상태와 결과 표현

async / await
→ Promise를 읽기 쉽게 사용하는 문법

실행 우선순위
→ 동기 코드
→ Microtask
→ Task Queue

Part 7. 브라우저 / DOM / Event

1. 브라우저에서 JS의 역할

브라우저는 HTML, CSS, JavaScript를 함께 처리한다.

HTML → 구조
CSS → 스타일
JavaScript → 동작

JavaScript는 브라우저가 제공하는 API를 통해 화면과 상호작용한다.

2. DOM

DOM(Document Object Model)은 HTML 문서를 JavaScript가 다룰 수 있는 객체 구조로 표현한 것이다.

<button id="btn">클릭</button>

const btn = document.querySelector("#btn");

여기서 document는 현재 HTML 문서를 나타내는 객체다.

3. DOM 조작

요소 찾기:

const title = document.querySelector(".title");

내용 변경:

title.textContent = "Hello";

스타일 변경:

title.style.fontSize = "20px";

요소 생성:

const div = document.createElement("div");
div.textContent = "new";

4. window와 document

브라우저에서 가장 상위 객체는 보통 window다.

window.alert("hello");
window.location;

document도 window 아래에 있다.

개념적으로:

window
 └─ document
     └─ HTML DOM

5. Event

사용자의 행동이나 브라우저의 상태 변화를 Event라고 한다.

대표적인 이벤트:

click
input
change
submit
keydown
load
scroll

이벤트 등록:

btn.addEventListener("click", () => {
    console.log("clicked");
});

6. Event 객체

이벤트 핸들러에는 이벤트 정보가 전달된다.

btn.addEventListener("click", (event) => {
    console.log(event.target);
});

event.target은 실제 이벤트가 발생한 요소를 의미한다.

7. Event Bubbling

이벤트는 기본적으로 자식 요소에서 부모 요소 방향으로 전파된다.

<div id="parent">
    <button id="child">Click</button>
</div>

버튼 클릭 시:

button
→ div
→ body
→ document

방향으로 이벤트가 올라간다.

이를 Event Bubbling이라고 한다.

8. Event Capturing

반대로 부모에서 자식 방향으로 내려가는 단계도 있다.

document
→ body
→ div
→ button

이를 Capturing이라고 한다.

전체 흐름은:

Capturing
↓
Target
↓
Bubbling

이다.

9. preventDefault()

브라우저의 기본 동작을 막는다.

예를 들어 form은 submit 시 기본적으로 페이지를 이동하거나 새로고침할 수 있다.

form.addEventListener("submit", (event) => {
    event.preventDefault();
});

SPA나 React에서도 자주 접한다.

10. stopPropagation()

이벤트가 부모로 전파되는 것을 막는다.

button.addEventListener("click", (event) => {
    event.stopPropagation();
});

즉:

preventDefault()
→ 브라우저 기본 동작 차단

stopPropagation()
→ 이벤트 전파 차단

핵심 정리

DOM
→ HTML을 JS에서 다룰 수 있게 객체 구조로 표현

document
→ 현재 HTML 문서

window
→ 브라우저의 최상위 객체

Event
→ 클릭, 입력, 제출 등 사용자/브라우저 동작

Event Bubbling
→ 자식 → 부모

Event Capturing
→ 부모 → 자식

preventDefault()
→ 기본 동작 차단

stopPropagation()
→ 이벤트 전파 차단

Part 8. fetch / HTTP / CORS / 인증

1. fetch

브라우저에서 HTTP 요청을 보낼 때 사용하는 기본 API다.

const response = await fetch("/api/users");
const data = await response.json();

흐름은:

브라우저
→ HTTP 요청
→ 서버
→ HTTP 응답
→ JSON 변환

2. HTTP 요청 기본 구조

주로 쓰는 메서드:

GET    → 조회
POST   → 생성
PUT    → 전체 수정
PATCH  → 일부 수정
DELETE → 삭제

예:

await fetch("/api/users", {
    method: "POST",
    headers: {
        "Content-Type": "application/json"
    },
    body: JSON.stringify({
        name: "Kim"
    })
});

3. JSON

프론트와 백엔드가 데이터를 주고받을 때 매우 자주 사용한다.

JS 객체:

const user = {
    name: "Kim",
    age: 20
};

JSON 문자열로 변환:

JSON.stringify(user);

JSON 문자열을 객체로 변환:

JSON.parse(json);

4. fetch에서 주의할 점

fetch는 404, 500 응답이 와도 Promise 자체는 보통 reject되지 않는다.

const response = await fetch("/api/users");

if (!response.ok) {
    throw new Error("요청 실패");
}

즉:

네트워크 자체 실패
→ reject

HTTP 404 / 500
→ 응답은 정상적으로 도착
→ response.ok 확인 필요

5. Same-Origin Policy

브라우저는 보안을 위해 다른 출처의 리소스 접근을 제한한다.

Origin은 보통 다음 3개로 결정된다.

protocol + host + port

예:

https://example.com:443

이 중 하나라도 다르면 다른 Origin으로 본다.

6. CORS

CORS는 서버가 브라우저에게:

"이 Origin에서 오는 요청은 허용해도 된다"

라고 알려주는 방식이다.

예를 들어:

Frontend
http://localhost:3000

Backend
http://localhost:8080

포트가 다르므로 서로 다른 Origin이다.

서버가 적절한 CORS 헤더를 주지 않으면 브라우저가 요청을 차단할 수 있다.

중요한 점:

CORS는 브라우저의 보안 정책이다.

서버끼리 통신할 때는 일반적으로 CORS 문제가 발생하지 않는다.

7. Cookie

브라우저에 저장되는 작은 데이터다.

서버가:

Set-Cookie

헤더를 보내면 브라우저가 저장하고 이후 요청에 자동으로 포함할 수 있다.

주로:

로그인 상태
세션 ID
사용자 설정

등에 사용한다.

8. Session

Session 방식은 로그인 정보를 주로 서버에서 관리한다.

로그인
↓
서버가 Session 생성
↓
Session ID 발급
↓
브라우저 Cookie에 저장
↓
이후 요청마다 Session ID 전달

서버는 Session ID를 보고 사용자를 식별한다.

9. JWT

JWT 방식에서는 사용자 정보를 포함한 토큰을 클라이언트에 전달한다.

로그인
↓
서버가 JWT 발급
↓
클라이언트가 저장
↓
요청마다 JWT 전달

주로:

Authorization: Bearer <token>

형태로 전달한다.

10. Session vs JWT

핵심 차이는 상태를 어디서 관리하느냐다.

Session
→ 서버가 로그인 상태 관리

JWT
→ 토큰 자체에 인증 정보 포함

단, JWT라고 해서 무조건 더 좋거나 더 최신 방식인 것은 아니다.

서비스 구조와 보안 요구사항에 따라 선택한다.

핵심 정리

fetch
→ 브라우저 HTTP 요청 API

JSON.stringify()
→ JS 객체 → JSON 문자열

JSON.parse()
→ JSON 문자열 → JS 객체

response.ok
→ HTTP 요청 성공 여부 확인

Same-Origin Policy
→ 브라우저가 다른 출처 접근 제한

CORS
→ 서버가 다른 Origin의 요청을 허용하는 방식

Cookie
→ 브라우저에 저장되는 데이터

Session
→ 서버 중심 인증 상태 관리

JWT
→ 토큰 기반 인증

Part 9. Node.js / npm / package.json / Module / Vite

1. Node.js

Node.js는 브라우저 밖에서도 JavaScript를 실행할 수 있게 해주는 런타임 환경이다.

JavaScript = 언어

Browser
→ JavaScript + Browser API

Node.js
→ JavaScript + Node API

즉 Node.js가 있으면 서버, CLI, 빌드 도구 등을 JS로 만들 수 있다.

2. npm

npm은 Node.js 패키지 관리자다.

npm install axios

외부 라이브러리를 설치하고 관리할 수 있다.

대표 명령:

npm install
→ 의존성 설치

npm install 패키지명
→ 패키지 추가

npm run dev
→ package.json에 정의된 dev 명령 실행

3. package.json

프로젝트 정보와 의존성을 관리하는 파일이다.

{
  "name": "my-app",
  "scripts": {
    "dev": "vite"
  },
  "dependencies": {
    "react": "^19.0.0"
  }
}

주요 역할:

프로젝트 정보
의존성 목록
실행 명령어
빌드 설정

4. node_modules

npm으로 설치한 라이브러리들이 들어가는 폴더다.

node_modules/

보통 용량이 크기 때문에 Git에는 올리지 않는다.

대신 package.json과 lock 파일을 공유하고:

npm install

로 다시 설치한다.

5. Module

코드를 여러 파일로 나누고 필요한 것만 가져오는 방식이다.

export function add(a, b) {
    return a + b;
}

다른 파일:

import { add } from "./math.js";

이런 방식을 ES Module(ESM)이라고 한다.

6. CommonJS

Node.js에서는 과거에 CommonJS 방식도 많이 사용했다.

const express = require("express");

내보내기:

module.exports = something;

현재는 ES Module 방식도 많이 사용한다.

import express from "express";

7. Bundler

웹 프로젝트는 파일이 많아지기 때문에 여러 파일과 의존성을 정리해 브라우저가 사용할 수 있게 묶는 과정이 필요할 수 있다.

이 역할을 하는 도구가 Bundler다.

대표적으로:

Webpack
Rollup
esbuild

8. Vite

Vite는 현대 프론트엔드 개발에서 많이 사용하는 개발 서버 + 빌드 도구다.

npm create vite@latest
npm run dev

주요 역할:

개발 서버 실행
빠른 코드 변경 반영
모듈 처리
프로덕션 빌드

React 프로젝트 만들 때 자주 보게 된다.

9. 개발 환경 전체 흐름

대략 이렇게 연결된다.

JavaScript 코드
↓
npm으로 라이브러리 관리
↓
package.json에 의존성 기록
↓
Vite로 개발 서버 실행
↓
빌드
↓
브라우저에서 실행

핵심 정리

Node.js
→ 브라우저 밖에서 JS 실행

npm
→ JS 패키지 관리자

package.json
→ 프로젝트 설정 + 의존성 + 실행 명령

node_modules
→ 설치된 패키지 저장

ES Module
→ import / export

CommonJS
→ require / module.exports

Bundler
→ 여러 파일과 의존성을 웹 실행 형태로 묶음

Vite
→ 개발 서버 + 빌드 도구

Part 10. React를 이해하기 위한 JavaScript 핵심

React는 새로운 언어가 아니라 JavaScript를 기반으로 UI를 만드는 라이브러리다. 그래서 아래 JS 개념을 잘 알면 React 코드가 훨씬 쉽게 읽힌다.

1. 구조 분해 할당

React에서 매우 자주 등장한다.

const user = {
  name: "Kim",
  age: 20
};

const { name, age } = user;

배열 구조 분해:

const [a, b] = [10, 20];

React의 useState도 같은 문법이다.

const [count, setCount] = useState(0);

2. Spread와 불변성

React에서는 기존 객체를 직접 수정하기보다 새 객체를 만드는 방식을 많이 사용한다.

const user = {
  name: "Kim",
  age: 20
};

const newUser = {
  ...user,
  age: 21
};

배열도 동일하다.

const newArr = [...arr, 4];

핵심은:

기존 값 직접 변경 X
→ 새로운 객체/배열 생성

이걸 불변성(immutability)이라고 한다.

3. map

배열을 다른 배열로 변환한다.

const nums = [1, 2, 3];

const doubled = nums.map(n => n * 2);

React에서는 리스트 렌더링에 매우 자주 사용한다.

users.map(user => (
  <div>{user.name}</div>
));

4. filter

조건에 맞는 값만 남긴다.

const nums = [1, 2, 3, 4];

const even = nums.filter(n => n % 2 === 0);

삭제 처리에도 자주 사용한다.

const newUsers = users.filter(user => user.id !== id);

5. find

조건에 맞는 첫 번째 값을 찾는다.

const user = users.find(user => user.id === 3);

API 응답이나 상태에서 특정 데이터를 찾을 때 자주 사용한다.

6. 조건부 렌더링에 쓰이는 JS 문법

삼항 연산자:

const message = login ? "로그인됨" : "로그인 필요";

React:

{login ? <Main /> : <Login />}

AND 연산자도 자주 사용한다.

{login && <Profile />}

login이 truthy일 때만 <Profile />이 렌더링된다.

7. Optional Chaining

값이 없을 수도 있을 때 안전하게 접근한다.

user.profile.name

profile이 undefined면 에러가 발생한다.

그래서:

user?.profile?.name

처럼 사용할 수 있다.

API 데이터를 다룰 때 특히 자주 등장한다.

8. Nullish Coalescing

null 또는 undefined일 때 기본값을 사용한다.

const name = user.name ?? "Unknown";

||와 차이가 있다.

0 || 100   // 100
0 ?? 100   // 0

??는 null, undefined만 비어 있는 값으로 판단한다.

9. Callback과 이벤트

React 이벤트도 결국 함수를 전달하는 구조다.

function handleClick() {
  console.log("click");
}

<button onClick={handleClick}>
  Click
</button>

즉:

onClick
→ callback 함수 전달

이다.

10. Closure와 React

React의 함수 컴포넌트와 Hook에서는 closure가 중요하다.

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

  function handleClick() {
    console.log(count);
  }

handleClick은 선언될 당시의 count 값을 참조한다.

그래서 React에서 흔히 말하는:

stale closure

문제도 JS의 closure 특성과 관련되어 있다.

11. 비동기와 React

API 호출:

async function getUsers() {
  const response = await fetch("/api/users");
  const data = await response.json();

  return data;
}

React에서는 이런 비동기 작업을 상태와 연결한다.

개념적으로:

API 요청
↓
응답
↓
state 변경
↓
컴포넌트 다시 렌더링

React를 이해하려면 Promise, async/await가 중요한 이유다.

핵심 정리

React에서 특히 중요한 JS

구조 분해 할당
→ const { name } = user

Spread
→ ...obj, ...arr

불변성
→ 기존 값 수정 대신 새 값 생성

map
→ 배열 변환 / 리스트 렌더링

filter
→ 조건에 맞는 값만 유지

find
→ 특정 값 검색

?. 
→ 안전한 속성 접근

??
→ null/undefined 기본값 처리

Callback
→ 이벤트 처리

Closure
→ Hook과 상태 이해에 중요

async/await
→ API 통신에 필수

• DB = 데이터를 자주 읽고 관리하기 위한 것
• 디스크 저장 = 파일을 보존하거나 내보내기 위한 것

어떻게 저장할거임?

• 머리에 넣어두자 앱 재시작 필요 없음 (일시 상태) → 메모리 상태 간단한 설정값 → SharedPreferences 민감 정보 → flutter_secure_storage 레포트·로그·백업 → 디스크 저장(JSON/PDF) 구조적 데이터(검색·정렬·통계)→ Drift or SQLite 캐시·간단 저장 → Hive or Isar
• 실제로는 혼용해야지 반복적으로 조회·필터링해야 하는 구조적 데이터는 Drift/Hive 레포트/기록성 데이터는 파일 저장(JSON 또는 이진 파일)

1. 모델을 freezed 기반으로 통일

핵심 포인트

• Freezed는 불변성(immutability) 확보
• copyWith, equality, toString 자동 생성
• JSON 직렬화는 json_serializable로 자동 처리
• enum 직렬화는 JsonConverter로 관리

개선 이유

• 모델 필드 변경 시 JSON 변환 코드를 직접 수정해야 하는 문제 해소
• 타입 안정성 확보
• 전체 모델 구조를 일관적으로 유지하기 용이

Freezed 도입 효과

• 생성자 + 직렬화 코드 자동화
• state 관리 안정성 상승
• 유지보수 비용 감소

2. JSON 직렬화 / 역직렬화 흐름 정리

역직렬화(JSON → 객체)

• Dio가 JSON 문자열 → Map 변환
• Retrofit이 응답 타입을 보고 fromJson 호출
• json_serializable이 생성한 _$ModelFromJson 실행
• Freezed 내부의 구현체로 모델 생성
• 최종적으로 Dart 객체로 전달

직렬화(객체 → JSON)

• Dio가 객체에 toJson() 존재 여부 확인
• Freezed + json_serializable이 생성한 _$ModelToJson 실행
• Map → JSON 문자열 변환 후 API 요청

핵심 요약

• Retrofit은 타입 기반으로 자동 직렬화
• Freezed는 모델 구조를 일관적으로 유지
• json_serializable은 실제 변환 로직 담당

3. Repository / DataSource 추상화

문제점

• DataSource가 단일 구현체로 고정
• 테스트용 Mock과 실제 API 교체가 어려움
• Repository가 구현체에 직접 결합됨

개선 방향

• abstract DataSource 정의
• API 구현체, Mock 구현체를 별도 분리
• Repository는 인터페이스에만 의존
• main.dart에서 의존성 주입으로 구현체 교체

구조 요약

Cubit → Repository(인터페이스) → DataSource(인터페이스) → 구현체(API 또는 Mock)

장점

• 테스트 쉬움
• 교체 유연성 확보
• 의존성 역전(DIP) 적용
• 단일 책임(SRP) 유지

단점

• 파일 증가
• 작은 프로젝트에서 과한 구조 가능

4. 전체 아키텍처 레이어 맵

UI
  ↓
Cubit (State 관리)
  ↓
Repository (비즈니스 로직)
  ↓
DataSource (API, Mock)
  ↓
Model (Freezed)

핵심 원칙

• 상태는 불변성 기반
• 비즈니스 로직과 데이터 접근 분리
• 인터페이스 기반 의존
• 자동 코드 생성 활용

진행 예정

1. 앱이 종료돼도 데이터가 유지되게

• 디스크 저장 방식이나 클라이언트 DB(Hive/Drift) 사용 고려
• 클라이언트 DB를 적극적으로 활용하는 앱 사례가 많으며, 우리도 앱 고도화 단계에서 변동성이 낮은 데이터(예: 리포트 등)를 로컬에 캐싱해 전달하는 방식으로 활용 가능

웹페이지 리뉴얼은 참여 안 할수도..?

나중에 reactiveX, 추상화, 디자인 패턴, flutter에서의 상태 관리와 타이밍 이슈 처리 전략 같은 부분을 좀 더 개념적이고 기술적인 부분 위주로 학습해서 포스팅 해야겠다.

11/28주말 조금12/01 진행 내용

진행 상황

1. 상태 관리 구조 개선: Sealed Class → Freezed 전환

상태 관리를 기존의 수동 sealed class 방식에서 Freezed 기반 구조로 정리함. 특히 화면 성격별로 플래그 기반 단일 State와 유니온 타입 State를 구분하여 적용함.

MainScreen: 플래그 기반 단일 State로 정리

메인 화면은 동시에 여러 데이터를 들고 있고, 부분 업데이트가 잦음. 따라서 여러 클래스로 나누기보다 하나의 State 안에 플래그로 묶는 방식이 적합하다고 판단함.

@freezed
class MainScreenState with _$MainScreenState {
  const factory MainScreenState({
    @Default(UserRegistrationData()) UserRegistrationData userData,
    @Default(<Pet>[]) List<Pet> pets,
    @Default(false) bool isLoading,
    String? error,
  }) = _MainScreenState;
}

이 구조는 다음과 같은 장점을 가짐:

• copyWith()로 필요한 부분만 갱신하기 쉬움
• UI는 if (state.isLoading) 같은 단순 조건으로 분기함
• 등록 정보 + 펫 정보처럼 서로 다른 리소스를 동시에 관리하는 화면에 적합함

UserRegistration / PetRegistration: 유니온 타입 유지

등록 플로우는 단계가 명확한 구조라 유니온 타입이 더 자연스러움. 각 단계가 “명시적으로 표현되는” 것이 중요하다고 판단해 Freezed의 union type을 그대로 유지함.

@freezed
class PetRegistrationState with _$PetRegistrationState {
  const factory PetRegistrationState.initial(Pet pet) = PetRegistrationInitial;
  const factory PetRegistrationState.loaded(Pet pet) = PetRegistrationLoaded;
  const factory PetRegistrationState.loading() = PetRegistrationLoading;
  const factory PetRegistrationState.success(Pet pet) = PetRegistrationSuccess;
  const factory PetRegistrationState.failure(String message) = PetRegistrationFailure;
}

유니온 타입의 장점은 다음과 같음:

• when, map으로 모든 상태를 반드시 처리하게 되어 실수 방지
• 각 상태별로 필요한 데이터만 들고 있게 설계 가능함
• 단계가 명확한 “등록/입력 흐름”에 최적화되어 있음

정리:

• 메인 화면 → 플래그 기반 단일 State
• 등록 플로우 → Freezed 유니온 타입 두 방식을 상황에 맞게 병행함.

2. ReactiveX 패턴 적용: BehaviorSubject + switchMap

변경 사항 자동 반영, 요청 버전 관리, 타이밍 문제 해결을 위해 Repository 레이어에 ReactiveX 패턴을 도입함.

BehaviorSubject를 Repository에 추가함

각 Repository에서 BehaviorSubject<String?>를 사용해 “어떤 유저의 데이터가 변경됐는지”를 스트림 형태로 발행함.

final _userUpdateSubject = BehaviorSubject<String?>.seeded(null);

Stream<String?> get userUpdates => _userUpdateSubject.stream;

Future<void> registerUser(String userId, UserRegistrationData data) async {
  await dataSource.registerUser(userId, data);
  _userUpdateSubject.add(userId);
}

BehaviorSubject의 핵심 특징은 다음과 같음:

• “마지막 emit 값”을 기억함
• 새로운 구독자가 붙으면 그 값을 즉시 emit함
• Cubit이 늦게 구독해도 최신 데이터를 놓치지 않음

MainScreenCubit에서 switchMap으로 요청 버전 관리함

MainScreenCubit은 userUpdates 스트림을 구독하며, switchMap을 이용해 이전 API 요청을 취소하고 마지막 요청만 처리하는 방식을 적용함.

_userUpdateSubscription = userRegistrationRepository.userUpdates
    .where((userId) => userId != null && _currentUserId == userId)
    .switchMap(
      (userId) => Stream.fromFuture(
        userRegistrationRepository.getUserDataByUserId(userId!),
      ),
    )
    .listen(
      (userData) {
        emit(state.copyWith(
          userData: userData ?? state.userData,
          error: null,
        ));
      },
    );

이 방식의 장점은 다음과 같음:

• 연속으로 빠르게 업데이트가 들어와도 마지막 이벤트만 유효
• 오래 걸린 응답이 늦게 도착해 UI를 덮어쓰는 문제 방지
• BehaviorSubject와 조합하면 “초기 로딩 + 자동 새로고침”이 자연스럽게 연결됨

요약하면, BehaviorSubject는 최신 이벤트 보장, switchMap은 요청 버전 관리 이 두 가지가 결합해 타이밍 이슈 전반이 해결됨.

3. FastAPI 로컬 서버 구축

FastAPI로 직접 로컬 서버를 구축해 실제 API 구조와 더 유사한 환경을 구성함.

인메모리 DB 구조 설계

• Python 딕셔너리로 users, pets 저장
• user_id_counter, pet_id_counter로 ID 자동 증가
• login ID와 내부 시스템 ID를 별도로 관리

이 구조로 Flutter 측의 loginUserId와 서버 내부 primary key를 명확히 분리할 수 있었음.

환경 구성

FastAPI에서 CORS 설정 후 Flutter에서 바로 호출하도록 구성했고, Flutter 앱에서는 환경 변수를 다음과 같이 주입하는 방식으로 관리함.

flutter run --dart-define=API_BASE_URL=http://192.168.0.2:3000

환경별 서버 주소를 유연하게 바꿀 수 있는 구조로 개선함.

4. Retrofit + Dio로 Flutter API 클라이언트 정리

FastAPI와 통신하는 Flutter 클라이언트를 Retrofit + Dio 기반으로 재구성함.

• @RestApi(), @GET, @POST로 인터페이스만 작성
• JSON 직렬화와 실제 HTTP 요청은 자동 생성됨
• build_runner로 *.g.dart, *.freezed.dart 파일 생성

일관된 API 모델과 상태 모델을 유지할 수 있고, 404 응답을 에러가 아닌 “데이터 없음”으로 처리하는 식의 흐름 제어가 용이함.

if (e is DioException && e.response?.statusCode == 404) {
  return null;
}

등록 정보가 없을 때는 비정상 상황이 아니므로 이렇게 처리함.

5. 로그인 및 초기 로딩 처리 개선

listenWhen으로 불필요한 listener 호출 차단

listenWhen: (previous, current) {
  return previous.user?.id != current.user?.id;
},

• user.id가 실제로 바뀔 때만 listener가 실행되도록 구성함
• 로딩 플래그 변화나 사소한 state 변경에는 반응하지 않도록 최적화함

초기 진입 시 데이터가 비어 보이는 문제 해결

BlocListener는 첫 빌드 때 동작하지 않기 때문에, 필요한 경우 addPostFrameCallback으로 초기 loadData를 강제 실행하도록 구성함.

if (!state.isLoading &&
    state.userData.nickname == null &&
    state.pets.isEmpty &&
    loginState.loginUserId != null) {
  WidgetsBinding.instance.addPostFrameCallback((_) {
    context.read<MainScreenCubit>().loadData(loginState.loginUserId!);
  });
}

BehaviorSubject의 캐싱과 결합되면서 “초기 진입 / 로그인 변경 / 등록 완료 후 복귀 등 모든 타이밍에서 최신 상태 유지”가 가능해짐.

여기서부터 팀장님 피드백

진행 예정

1. Repository–DataSource 추상화

현재 DataSource가 단일 구현체라 Repository가 구체 클래스에 직접 결합된 구조. 테스트용 목업과 실제 API를 동일한 흐름으로 교체하려면 DataSource를 인터페이스로 추상화하는 구조가 필요.

개선 방향 요약

• abstract UserRegistrationDataSource 정의
• Mock / API 구현체 분리
• Repository는 인터페이스만 의존
• 저장 방식 변경 시에도 앱 흐름 유지

2. Freezed State를 Flag 기반으로 통일

MainScreen은 flag 기반 단일 state인데, UserRegistration / PetRegistration은 union type 구성.

등록 플로우는 단계가 많지 않고 전이가 단순하므로, MainScreen과 동일하게 단일 state + flag 기반이 더 적합한 구조.

예시 형태

@freezed
class PetRegistrationState with _$PetRegistrationState {
  const factory PetRegistrationState({
    @Default(Pet.empty()) Pet pet,
    @Default(false) bool isLoading,
    String? error,
  }) = _PetRegistrationState;
}

핵심 개념 Freezed는 상태 변경 지점을 제한하는 목적. state는 불변이며, 모든 변경은 copyWith 기반으로만 생성. 상태 추적, 디버깅, 변경 히스토리 파악이 쉬운 구조.

3. 모델(UserRegistrationData / Pet)을 Freezed로 전환

현재 모델은

• 직접 작성한 fromJson / toJson
• Equatable 기반 비교 형태로 구성.

필드 추가·변경 시 JSON 변환 코드도 매번 직접 수정해야 하는 구조라 유지보수 비용 증가.

개선 방향 모델을 Freezed + json_serializable 기반으로 재구성.

기대 효과 요약

• JSON 직렬화 자동화
• copyWith, equality, 불변성 자동 생성
• 타입 구조 일관성 확보
• 코드량 감소

이번 리팩까지 하고나면 플러터 학습 마무리하고 앱 실제 구조 살펴볼 예정

서비스 리뉴얼 참여(약 1주)해서 프레임워크 안쓰고 순수 웹 3대장으로 UI 고치고 배포하는 과정에서 병목 등의 문제 해결..?

제발 java랑 javascript 공부 좀 하자.. C python 해서 뭐할래 객체지향 프로그래밍도 더 깊게 공부해야 할 것 같다.

일에 바로 투입되지는 못하고.. 공부만 하고 있는 게 좀 죄송했다. 모두가 엄청 바쁘게 일 하는 상황에서 나만 1인분을 못하고 있었기 때문이다. '로그인-앱 등록-펫 등록' 이 짧은 흐름 하나를 구현해놓고 피드백을 받아가며 여러 방식으로 고쳐나갔는데 뭘 하고 있는 건지 티도 안났다.

근데? 오늘 처음 구현했던 코드를 보고 지금 코드를 보니 실무 바로 들어가서 AI 써재꼈으면 진짜 큰일났겠다 싶었다!

일단 하루 30분 할애해서 코드 보면서 피드백 해주시고.. 어떤 식으로 생각해야 하는지, 어떤 패키지들을 적용해볼 수 있는지 하나하나 짚어주시는 게 사실 자원을 엄청 쓰고 있다는 걸 알고 있어서 공부를 열심히 하려곤 했다. 근데 베이스가 너무 부족해서 힘들고 학습이 되긴 하는 건지 몰랐는데 좋은 코드가 어떤 건지 보는 눈과 짜임새 있게 코드를 구성하는 사고력이 생겨가는 것 같다.

물론 지금도 코드 쓰는 걸 버벅이고 생각의 흐름이 매끄럽지 못해 AI에게 많이 배우고 있지만.. 진짜 뭣도 모르면서 AI에게 거의 모든 걸 맡겼던 내가 얼마나 잘못된 방식을 선택했는지 깨닫는다.

주니어 개발자 내 자신 화이팅...

오늘 한 내용

1. 레이어 구조 정리

• 전체 구조를 UI → Cubit → Repository → DataSource 로 명확히 분리
• UI에서 Repository를 직접 호출하던 부분 제거
• Cubit이 비즈니스 로직과 데이터 접근을 전담하도록 구조 개선 → 상태관리·의존성·테스트 용이성이 크게 향상됨

2. 상태 클래스 개선

• 모든 상태 클래스를 sealed class + final class로 재구성
• switch 표현식 사용 가능
• 모든 상태 분기를 컴파일 타임에 강제할 수 있어 안정성 확보

3. GoRouter 실험

• pageBuilder 방식: 부모 페이지(Page)가 실제로 생성되는 구조
• redirect 방식: 부모 페이지 없이 자식 경로로 곧바로 이동
• AI는 redirect 방식이 URL 구조·뒤로가기 스택에 유리하다는데 뭐가 더 좋은지는..

4. MainScreen 구조 정비

• 메인 화면을 StatefulWidget → StatelessWidget 으로 변경
• 상태·데이터 로드를 담당하는 MainScreenCubit 신설
• 로그인 상태 변화에 따라 Cubit이 사용자·펫 데이터를 자동 재로딩 → UI는 “상태만 읽는 구조”로 단순화됨

5. 자동 새로고침 로직 정비

1) 수동 refresh 방식 사용해봄

• 등록 완료 후 UI 쪽에서 refreshUser / refreshPets 직접 호출
• print 디버깅으로 호출 시점·rebuild 문제 확인

2) Stream 기반 자동 동기화 사용해봄

• Repository에 StreamController.broadcast() 추가
• 데이터 변경 시 stream.add(userId)로 이벤트 발행
• MainScreenCubit이 stream을 listen()하여 같은 userId일 때 자동으로 refreshUser / refreshPets 실행
• 구독은 StreamSubscription으로 관리, Cubit close에서 취소 → 수동 refresh 불필요, 화면 자동 동기화 완성

6. 사용자 정보 수정 플로우

• 메인 화면에 유저 정보 수정 버튼 추가
• 기존 등록 플로우(닉네임 등 입력 화면)를 수정 모드로 재사용
• 기존 데이터가 TextField에 자동 세팅
• 수정 완료 시 stream 이벤트 → 메인 자동 새로고침

7. 디버깅 및 개념 정리

• Repository stream과 흐름 이해
• Repository를 전역 Provider로 두는 이유:
  • 의존성 주입
  • Stream 공유
  • 테스트 및 Mock 용이

피드백 받은 내용 한 번에 정리

1. 로딩/실패 상태 처리

• 새 데이터가 도착했을 때 Cubit이 로딩 중이거나 실패 상태라면 기존 데이터를 어떻게 유지/대체할지 타이밍을 고민해야 함

2. ReactiveX/Subject 개념

• 기본 Stream 외에 BehaviorSubject 같은 RX 개념도 존재. 마지막 emit 값을 캐싱해 두고 새 구독자가 즉시 현재 상태를 알 수 있어 UI 초기화에 유리

3. sealed class 대안

• sealed class를 쓰지 않고 MainState.loading, MainState.success처럼 상태를 한 객체 안에 묶는 패턴도 있음
• 더 immutable하게 만들고 싶다면 freezed 같은 코드 생성 패키지를 검토

4. 실제 API 콜 테스트

• 실제 REST API를 호출하는 플로우도 한번 테스트해 보자
• 간단한 서버를 띄우거나, 테스트용 HTTP 서비스를 이용해 보고, Retrofit 같은 REST 클라이언트도 경험해 보라고 권장

• 한 것 go router 사용 라우트 관리, cubit provider 주입 시점 조절, repo provider 사용

• 못 한 것 provider 내부 동작 살펴보기, sealed class 사용
• 과제는 아니었지만 이상하게 만들어서 수정이 시급한 것 레이어 분리 제대로(UI가 레포 호출 바로 못하게 - cubit이 처리)

어찌저찌했는데 머리에 다 들어온 건 아닌 듯

여기서부터 팀장님 피드백

Cubit 분리 전략

Cubit을 따로 만들지 않는 경우

등록 플로우 Cubit과 전역 리스트 Cubit을 분리하지 않고 하나로 운용할 때 두 방식 중 선택

방식 1: 파라미터 + 리프레시 호출

• 업데이트가 필요한 화면으로 파라미터 전달
• 변경 시 리프레시 신호를 보내서 해당 화면이 데이터 다시 로드
• 장점: 구조 단순
• 단점: 수동 리프레시 필요, 여러 화면 동기화 어렵다
• 사용 시기: 단순 플로우

방식 2: Repository 스트림 구독

• Repository에 스트림을 두고 데이터 변경 시 이벤트 발행
• Cubit 등이 스트림을 구독해 자동으로 상태 갱신
• 장점: 자동 동기화, 화면 여러 개여도 일관성 유지
• 단점: 구조 복잡
• 사용 시기: 데이터 공유가 많고 흐름이 복잡할 때

선택 기준

• 단순: 방식 1
• 복잡·다중 화면: 방식 2

디버깅 습관

의식의 흐름을 제대로

1. 갱신이 필요한 위치 확인
2. 갱신을 호출하는 코드 위치 확인
3. 호출은 되었는지, 수신은 되었는지, 수행은 되었는지 로그로 확인

이런게 자연스럽게 이뤄져야 함

로그 활용 잘하기

에러 떴으면 뭐라 떴는 지 좀 잘 보기

go_router 메서드 요약

context.go(path)

• 스택 전체 대체
• 뒤로가기 불가
• 로그인 성공 후 메인 이동 등

context.push(path)

• 스택에 화면 추가
• 뒤로가기 가능
• pop 결과값(Future) 받을 수 있음

context.pop([result])

• 현재 화면 제거
• push로 온 화면에서만 가능
• 이전 화면으로 결과 전달 가능

context.replace(path)

• 현재 화면만 교체
• 아래 스택 유지
• 뒤로가기 가능

context.canPop()

• pop 가능 여부 확인

context.goNamed(name, …)

• 라우트 이름 기반 go
• 동작은 go와 동일

context.pushNamed(name, …)

• 라우트 이름 기반 push
• 동작은 push와 동일

context.replaceNamed(name, …)

• 라우트 이름 기반 replace
• 동작은 replace와 동일

UI → Repository 직접 호출 금지

레이어는 제대로 짜놓고 왜 ui가 cubit 부르는거랑 repo 부르는 걸 섞어놨니..

잘못된 구조 (UI → Repository 직접 호출)

onPressed: () async {
  await context.read<PetRepository>().registerPet(userId, pet);
}

올바른 구조 (UI → Cubit → Repository)

onPressed: () {
  context.read<PetListCubit>().addPet(userId, pet);
}

class PetListCubit extends Cubit<PetListState> {
  Future<void> addPet(String userId, Pet pet) async {
    await repository.registerPet(userId, pet);
    emit(PetListLoaded([...pets, pet]));
  }
}

이유

• 비즈니스 로직은 Cubit에 집중
• UI는 “상태와 이벤트”만 알고 Repository는 Cubit만 알도록 분리
• 테스트 용이성
• 상태 흐름 일관성 유지

핵심: UI는 Cubit만 호출, Cubit이 Repository를 호출하는 구조

GoRoute : redirect / builder / pageBuilder 정리

redirect

• 라우팅 직전에 실행되어 경로만 변경하는 함수
• UI나 페이지를 만들지 않고 단순히 이동만 처리
• 인증 체크, 초기 플로우 분기 같은 상황에서 사용
• 부모 페이지 없이 바로 다른 경로로 이동하는 구조

builder

• child 라우트를 부모 위젯으로 감싸는 방식
• 반환값이 Widget이기 때문에 Navigator 스택에는 올라가지 않음
• 공통 Scaffold, AppBar, BlocProvider 같은 “레이아웃 래핑”에 사용
• 화면 구조는 부모 위젯이 존재하지만 “페이지 단위”는 아님

pageBuilder

• Navigator가 사용하는 실제 Page(MaterialPage 등)를 생성
• 부모 Page가 스택에 올라가고, 그 안에서 child가 보여지는 구조
• 뒤로가기 히스토리에도 부모 페이지가 포함됨
• 페이지 단위 공통 레이아웃이 필요할 때 사용

요약

• redirect: 경로만 변경, UI 없음
• builder: 부모 위젯 생성, Page는 아님
• pageBuilder: 부모 Page 생성, 스택에 올라감

• 레이어 제대로 고치고 디버깅 제대로 해서 내가 못고쳤던 문제 해결해보기

• go_route에서 리다이렉트말고 페이지 빌더 사용해보기
• 스트림 구독 vs 리프레시 주기

• Bloc 라이브러리에서 제공하는 단순 상태관리 클래스
• 메서드를 통해 상태 변경 → emit() 호출
• UI는 Cubit의 상태 스트림을 구독해 화면을 갱신함

Cubit 기본 구조

• State: 불변 객체, 여러 상태 클래스로 표현
• Cubit 클래스: 초기 상태 설정 → 메서드에서 emit() 호출
• 비동기/동기 모두 가능

UI와 Cubit 연결

• UI → Cubit: context.read<Cubit>().method()
• Cubit → UI: 상태 스트림 전달
• BlocBuilder: 상태 기반으로 UI 빌드
• BlocListener: 네비게이션·팝업 등 부수 효과 처리
• BlocConsumer: builder + listener 동시 사용

read / watch / select

• read(): Cubit 인스턴스 가져오기 (액션 호출용), 리빌드 없음
• watch(): Cubit 상태 전체 구독, 리빌드 발생
• select(): 특정 필드만 구독, 리빌드 최적화

Cubit 동작 원리

• 단방향 흐름: UI → Cubit → State → UI
• emit(): 새 상태를 스트림으로 내보냄
• 상태는 반드시 새로운 객체로 생성될 것

Cubit vs Bloc

• 공통: 단방향 데이터 흐름, 상태 기반 UI, 테스트 용이

• 차이점

  • Cubit: 메서드 → emit, 코드량 적음, 단순 로직에 적합
  • Bloc: Event → Handler → emit, 복잡한 로직·플로우에 적합

언제 어떤 걸 쓰는가

• Cubit: 단일 화면, API 호출 + 로딩/성공 구조 등 대부분의 케이스
• Bloc: 상태 흐름 복잡, 다단계 이벤트, 상태머신이 필요한 기능

여기부터는 팀장님 피드백 받은 내용들

context.read / watch / select

• flutter_bloc이 BuildContext에 추가한 확장 함수

• read() context.read<T>()

  • Cubit/Bloc 인스턴스를 가져오기만 함
  • 상태 변화와 무관, 리빌드 없음
  • 버튼 클릭처럼 Cubit 메서드 실행할 때 사용

• watch() context.watch<T>()

  • Cubit 상태를 구독해 상태가 바뀔 때마다 위젯 리빌드
  • 작은 위젯은 context.watch<Cubit>().state로 간단하게 사용

• select() context.select<T, R>(selector)

  • 상태의 특정 필드만 구독
  • selector 값이 바뀌지 않는 한 리빌드 없음 → 퍼포먼스 최적화

BlocBuilder vs watch

• BlocBuilder: 어떤 Cubit을 구독하는지 명시적, 리빌드 범위 제어에 유리
• watch: 간단하게 상태를 읽고 싶을 때 편함
• 둘 다 Cubit 상태에 따라 UI를 다시 그림

Repository를 Provider로 주입하자

• Repository를 Cubit 내부에서 직접 생성하는 대신 상위 위젯에서 Repository 인스턴스를 Provider로 만들어 하위에서 context.read<Repository>()로 가져와 사용

• 장점

  • 재사용성 증가
  • mock 교체 쉬워 테스트 편함
  • 여러 Cubit이 동일한 Repository 공유 가능
  • 의존성 주입 구조가 명확해짐

abstract class 대신 sealed class

• Dart 3에서 제공하는 sealed class는
  • 같은 파일 내부에서만 하위 타입 생성 가능
  • switch/case 문에서 누락된 상태가 있으면 컴파일러가 잡아줌
  • default 없이도 모든 상태를 안전하게 처리 가능
• Bloc/Cubit의 상태(State) 선언에 가장 안전한 방식

Repository를 직접 new 하지 말고 context.read()로 주입하는 이유

• Repository를 Cubit 안에서 직접 new 하면 Cubit이 특정 구현체에 묶여 결합도가 높아짐
• 테스트에서 Mock Repository로 교체하기 어렵고, 화면·플로우마다 다른 Repository를 쓰는 것도 불가능해짐
• Provider는 위젯 트리 상단에서 Repository 인스턴스를 한 번만 만들어 두고, 하위에서는 context.read<Repository>()로 받아서 사용
• Cubit은 생성 방식이나 구현체를 몰라도 되고, “필요한 의존성을 주입받아 쓰는” 구조가 됨
• 의존성 관리가 깔끔해지고 교체·모킹·재사용·라이프사이클 제어가 쉬워짐
• 결론적으로 Repository는 Provider가 만들고, Cubit은 read로 받아 쓰는 구조가 정석임

go_router와 Provider 주입 시점 조절

• go_router는 라우트 단위로 화면을 구성하는 패키지
• 특정 플로우(회원가입, 결제 등)에서만 필요한 Cubit은 해당 라우트 내부에서 Provider로 생성
• 장점
  • 플로우 종료 시 Cubit이 자동 dispose
  • 메모리 관리 깔끔
  • 라우트 단위로 상태 수명 주기를 통제할 수 있음

Flutter에서는 화면을 구성하는 모든 요소가 위젯이며, 위젯들은 부모-자식 관계로 이루어진 트리 구조를 형성한다. 위젯은 불변이기 때문에, UI가 변경될 때는 기존 위젯을 수정하는 대신 새로운 위젯을 다시 그려주는 방식으로 동작한다.

StatelessWidget과 StatefulWidget

공통점

두 위젯 모두 build(BuildContext) 메서드 안에서 “이 위젯이 어떤 UI인지”를 선언한다.

StatelessWidget

• 내부에 변경되는 상태가 없다.
• Text, Icon, Padding 같은 정적인 UI에 사용된다.
• 동일한 입력이 주어지면 항상 동일한 결과를 반환하며, 부모 위젯이 재빌드될 때만 다시 그려진다.

StatefulWidget

• 변경 가능한 상태를 가진다.
• StatefulWidget과 실제 상태를 보관하는 State 객체가 쌍으로 동작한다.
• setState()를 호출하면 해당 위젯만 다시 빌드되어 동적 UI를 만들 수 있다.
• 사용자 입력, 값 변화, 애니메이션 등 시간이 지나며 변하는 UI에 사용한다.

상태(State)의 개념

상태는 UI를 그리기 위해 필요한 데이터나 리소스를 의미한다. Flutter에서는 상태를 크게 두 가지로 나눈다.

Ephemeral State (지역 상태)

• 한 위젯 내부에서만 잠시 필요한 상태
• 예: 체크박스 선택 여부, 특정 화면의 입력값
• State + setState()로 관리한다.

App State (전역/공유 상태)

• 여러 화면 또는 여러 위젯에서 함께 사용하는 상태
• 예: 로그인 정보, 장바구니, 앱 설정 값
• InheritedWidget, Provider 등 상태관리 도구를 사용해 관리한다.

주요 상태관리 방식 요약

StatefulWidget + setState

• 간단한 로컬 상태에 적합
• 추가 패키지 없이 사용할 수 있고 이해하기 쉽다
• 하지만 공유 상태가 많아질수록 구조가 복잡해진다

InheritedWidget 계열 (InheritedNotifier / InheritedModel)

• 트리 상단에서 하위 위젯들에게 상태를 전달하는 Flutter 기본 메커니즘
• 직접 활용하면 코드가 복잡해 주로 기반 개념으로만 사용된다

ChangeNotifier + Provider

• Flutter 공식이 초보자에게 추천하는 방식
• ChangeNotifier 안에 상태를 보관하고 notifyListeners()로 변경을 알린다
• Provider는 이 변경을 구독하고 필요한 위젯만 다시 빌드한다
• 전역 상태를 깔끔하게 관리할 수 있고, MultiProvider로 여러 상태를 함께 관리할 수 있다
• 상태가 커지면 ChangeNotifier가 비대해지는 단점이 있다

기타 상태 관리 패키지 (Bloc, Riverpod 등)

• 팀 규모나 프로젝트 복잡도에 따라 선택
• 구조적이고 테스트하기 쉬운 상태관리 패턴 제공
• 보일러플레이트가 줄거나, 더 명확한 아키텍처를 만들 수 있다
• 러닝 커브가 존재하고 패키지 의존성이 추가된다

Flutter 상태관리와 Provider, 그리고 Repository 아키텍처 정리

Flutter에서 화면은 모두 위젯으로 이루어져 있으며, UI는 위젯 트리 형태로 그려진다. 위젯은 불변이기 때문에 상태가 변경되면 기존 위젯을 수정하는 것이 아니라 새로운 위젯을 다시 생성하는 방식으로 갱신된다. 이로 인해 상태가 필요 없는 UI는 StatelessWidget, 상태가 필요한 UI는 StatefulWidget으로 나뉘게 된다.

StatefulWidget은 특정 위젯 내부에서만 유효한 “지역 상태(ephemeral state)”를 관리하기에는 충분하지만, 앱의 여러 화면에서 공유해야 하는 전역 상태를 관리하기에는 한계가 있다. setState는 오직 자신의 위젯 내부만 업데이트하기 때문에, 상태를 다른 화면에 전달하려면 각 단계마다 파라미터로 넘겨야 하고, 구조가 빠르게 복잡해진다.

이 문제를 해결하기 위해 Flutter에서 널리 사용하는 방식이 Provider다. Provider는 ChangeNotifier 기반으로 상태를 객체 하나에 모아두고, notifyListeners()를 호출했을 때 해당 객체를 구독하는 Consumer만 다시 빌드된다. 이 덕분에 부모 위젯이 데이터를 일일이 전달하지 않아도 되고, 화면 어디에서든 동일한 상태를 쉽게 접근하고 변경할 수 있다.

나는 provider로 전역적으로 상태관리가 가능하도록 해서 학습을 하고 있었는데, 팀장님께서 실무에서 쓰는 상황들을 더 설명해주셨다. 아래 내용은 설명해주신걸 기억하기 위해 정리해둔 글이다.

Provider의 범위(Scope)와 라이프사이클

Provider는 흔히 “전역 상태관리 도구”로 오해되지만, 실제로는 상태를 원하는 범위의 서브트리에만 주입할 수 있는 도구다. 즉, Provider는 반드시 루트에만 두라는 규칙이 없다.

예를 들어 앱 구조가 다음과 같다고 하자.

MultiProvider
  └── App
        ├── Route A
        └── Route B

Provider는 다음과 같은 범위 중 어디든 주입할 수 있다.

• App 위 (전역)
• App 아래
• Route A 트리 내부
• Route B의 하위 위젯에서만 사용

Provider는 자신이 주입된 위치에 따라 lifespan(생명주기)이 결정된다. Provider가 트리에 붙어 있는 동안만 살아 있고, 해당 트리가 사라지면 Provider도 자동으로 dispose된다.

이 특징 때문에 실무에서는 다음과 같이 나누는 패턴이 일반적이다.

• 앱 전체에서 필요한 상태

  • 예: 로그인한 User 정보, 현재 재생 중인 음악, 설정 값
  • → 루트(MultiProvider) 또는 최상단에 주입

• 특정 플로우 안에서만 필요한 상태

  • 예: 회원가입 단계별 입력값, 특정 페이지에서만 쓰는 임시 필터 값
  • → 해당 Route 또는 해당 화면 트리에만 Provider 주입

이렇게 하면 “전역에 올릴 필요 없는 상태”를 전역에 올려서 메모리를 낭비하거나 잔존 데이터를 남기는 문제를 피할 수 있다.

Provider Shadowing: 가장 가까운 Provider를 읽는다

같은 타입의 Provider가 여러 레벨에 있을 수도 있다. 이 경우 Consumer<T> 또는 context.watch<T>()는 트리 아래에서 위로 올라가며 가장 가까운 Provider를 읽는다.

즉,

• Consumer는 “이 값이 어디서 왔는지” 모른다.
• 단지 “내 트리에서 가장 가까운 Provider”를 구독할 뿐이다.

이 특징을 이용하면 다음과 같은 패턴도 가능하다.

• 플레이어 상태는 전역 Provider에 두고
• 추천 페이지에서만 필요한 추천 알고리즘 상태는 추천 페이지 트리에 Provider를 두고
• 페이지를 벗어나면 추천 상태만 자연스럽게 dispose됨
• 하지만 전역 Provider에 있는 플레이어 상태는 유지됨

실무에서 화면별 상태와 전역 상태를 자연스럽게 분리하는 데 매우 유용한 방식이다.

Flutter에서도 Repository 레이어가 필요한 이유

상태관리와 별개로, Flutter의 아키텍처에서도 자바/Spring과 동일한 방식으로 Repository 패턴을 사용할 수 있다.

Repository의 목적은 명확하다. ** “UI나 비즈니스 로직이 데이터가 어디서, 어떻게 오는지 모르게 한다."**

Dart에는 interface 키워드는 없지만, abstract class를 통해 인터페이스와 동일한 역할을 만들 수 있다. Cubit/Bloc은 Repository의 인터페이스만 의존하고, API/캐시/Mock 구현체는 뒤에서 교체 가능하다.

레이어 구조

여러 디자인 패턴들이 있지만 다 비슷비슷하다. 중요한건 인터페이스를 잘 만드는 것이다. 내가 참여할 파트의 구조는 이런 식으로 되어있다.

Screen → Cubit/Bloc → Repository(인터페이스) → 구현체(API/캐시/Local)

• Screen UI 렌더링, 사용자 입력을 Cubit/Bloc에게 전달
• Cubit/Bloc 화면 상태/비즈니스 로직 담당. Repository 인터페이스만 호출
• Repository (abstract class) 앱 관점의 “데이터 가져오기 API” 정의
• 구현체(Impl) 실제 HTTP 요청, 로컬 DB, 캐시 등 상세한 데이터 접근 로직

이 구조가 가지는 가장 큰 장점은 UI가 데이터 출처를 전혀 모른다는 점이다. UI 입장에서는 단지 getUser()를 호출하는 것뿐이며, 그 뒤에서 실제 요청이 어떤 방식으로 이루어지는지는 Repository가 책임진다.

인터페이스를 잘 만드는 것이 핵심

Repository 패턴의 가치는 단순히 “코드 나누기”가 아니라, UI가 비즈니스 의미만 이해하고 구현 세부 사항을 모르게 만드는 데 있다.

Bad 예시:

Future<Response> get(String url);

Good 예시:

abstract class MusicRepository {
  Future<List<Music>> getRecommended();
}

이렇게 Repository 이름과 메서드가 “도메인 용어”를 표현해야 UI와 Cubit/Bloc이 데이터 구조 변경에 영향을 받지 않는다.

왜 Repository 패턴을 써야 하냐?

• API 변경에도 UI 로직 수정 없음
• 테스트 시 Mock Repository로 손쉽게 대체 가능
• 로컬 캐시 + API + DB 같은 복합 데이터 소스 구성에 적합
• 화면 로직(Cubit/Bloc)이 깔끔해지고 유지보수성 증가
• 실무 앱 대부분이 이 방식으로 성장함

즉, Flutter에서도 Repository 레이어는 데이터 로직을 독립시키고 UI·상태 로직을 깨끗하게 유지하는 핵심 아키텍처다.

이제 cubit을 이용한 걸로 다시 한번 로그인-회원가입-ㅁㅁ 등록 흐름을 만들어볼거다. Event → State 식으로 하면 복잡해지는 부분이? 있기 때문에 cubit만을 사용할 것 같다. 지금 일단 알려주신 단축키들 잘 활용해보자. cmd + . : 전구기능 실행 / option + shift + F : 줄맞춤 / Snippet + tap : 자동 완성

실무 배정을 앱 쪽으로 받게 되면서 flutter를 공부하게 됐다. 학습을 좀 깊게 해야할 듯

개발환경 세팅은 코딩 셰프의 mac 세팅 영상을 따라하다가, 공식 문서보고 그냥 좀 더 쉬운 방식으로 했다. 막히는 건 GPT로 해결.. 경로 중간에 한글이 포함되지 않도록 미리 주의합시다

코드팩토리의 플러터 프로그래밍 책을 기반으로 개념을 학습하고 있다.

Dart 언어의 장점

• 일관된 개발 경험: 모바일·웹·데스크톱을 하나의 언어로 개발
• 빠른 개발 사이클: Hot Reload 지원
• 타입 안정성: Null-safety 기반
• 성능 최적화 용이: VM + AOT 조합으로 런타임 성능 확보
• UI 지향 언어 디자인: 비동기 처리·상태 관리에 자연스러운 문법

Dart의 컴파일 방식(JIT / AOT)

JIT (Just-In-Time)

• 개발 단계용
• 코드를 실행 중에 바로 컴파일, Hot Reload 가능, 초기 실행은 느리지만 반복 개발 속도가 빠름

AOT (Ahead-Of-Time)

• 배포용
• 실행 전에 네이티브 코드로 미리 컴파일, 앱 시작 속도 빠르고 실행 성능 높음, 최종 빌드 시 용량은 커질 수 있음

Dart 기본 문법

• 변수 선언

  • var: 타입 추론 후 고정
  • dynamic: 어떤 타입도 허용, 런타임에 타입 결정
  • final: 런타임에 값 확정
  • const: 컴파일 타임 상수, 불변 + 컴파일 최적화

• 기본 타입

  • String, int, double, bool

• 컬렉션 타입

  • List: 순서 기반, 인덱스로 접근
  • Map: key–value 구조
  • Set: 중복 없음
  • enum: 값 집합 정이

• 제어문

  • if / else, switch
  • for, for-in, while, do-while

• 함수 문법

  • 반환값 + 매개변수
  • 익명 함수 & 람다 (args) => expr

• typedef

  • 함수 타입에 별칭 부여

• try / catch / finally

  • try: 실행
  • catch(e): 예외 처리
  • on SomeException: 특정 예외 처리
  • finally: 무조건 실행

• 비동기 문법

  • async, await 사용
  • Future: 1회성 비동기 결과
  • Stream: 지속적으로 여러 값을 방출
  • 

객체지향 개념 정리

클래스 (Class)

• 데이터(필드)와 동작(메서드)을 하나로 묶는 기본 단위
• 실제 앱 구조는 거의 전부 “클래스 기반”으로 설계됨
• Flutter 위젯도 모두 클래스 → Widget 이해 = Class 이해

인스턴스 (Instance) & 멤버 (Member)

• 클래스가 설계도라면 인스턴스는 그 설계도로 만든 실제 객체 (붕어빵틀과 붕어빵)
• 인스턴스화는 클래스를 실제 객체로 생성하는 과정
• 생성된 인스턴스는 각각 독립된 상태를 가짐. 인스턴스 멤버(필드/메서드)가 객체마다 독립적으로 존재
• 클래스를 인스턴스화 하면 클래스의 인스턴스를 변수로 저장 가능

생성자 (Constructor)

• 객체 생성 시 초기값을 정의
• 기본 생성자 + named constructor 모두 지원
• 생성자 오버로딩 대신 named constructor 방식 사용

게터 (Getter) / 세터 (Setter)

• 게터는 객체의 내부 값을 읽기 위한 접근자
• 세터는 객체의 내부 값을 변경하기 위한 설정자
• 최근 변수의 값을 불변성(인스턴스화 후 변경할 수 없는) 특성으로 사용해서 세터는 잘 안씀

상속 (extends)

• 부모 클래스의 기능을 그대로 물려받음
• 하나의 클래스만 상속 가능(단일 상속)
• 재사용성과 일관성을 유지할 때 유용
• Flutter에서 공통 UI/로직 구조를 만들 때 자주 등장

인터페이스 (implements)

• 클래스가 반드시 가져야 할 기능 “목록”
• Dart에서는 모든 클래스가 자동으로 인터페이스 역할 가능
• implements는 반드시 모든 메서드를 재정의해야 함
• 명확한 규약/프로토콜을 만들 때 효과적

추상 클래스 (abstract)

• 인스턴스를 만들 수 없음
• 공통 동작의 뼈대를 정의하는 용도
• “기능의 템플릿” 역할
• UI · 데이터 모델 계층에 자주 사용됨

오버라이드 (override)

• 상속받은 메서드/필드를 자식 클래스에서 재정의
• 클래스 간 동작을 상황에 맞게 다르게 표현
• @override 애노테이션을 사용해 의도를 명확히 표시함

믹스인 (Mixin)

• 상속과 달리 “기능만” 주입하는 방식
• 여러 클래스에 공통 기능을 공유하고 싶을 때 사용
• 다중 상속이 없는 Dart에서 재사용성을 강화하는 핵심 기능

제네릭 (Generics)

• 타입을 외부에서 주입해 재사용성과 안정성을 높임
• 클래스/함수/컬렉션 모두 제네릭을 사용 가능
• <> 안에 타입을 명시 List<int>, Map<String, dynamic>

스태틱 (Static)

• 클래스에 직접 귀속되는 값/메서드
• 인스턴스마다 복사되지 않고 모두가 공유
• 상태 보관용으로 남용은 위험 → 설정/상수에 적합

캐스케이드 연산자 (Cascade Operator)

• 하나의 인스턴스에 대해 연속적으로 필드·메서드를 호출하는 문법
• 인스턴스 초기화나 설정 코드를 간결하게 작성할 때 유용

플러터 구조와 통신

플러터 구조(Framework → Engine → Embedder)

• Framework(Dart): Material/Cupertino, Widgets, Rendering 등 UI 계층. 개발자가 직접 사용하는 부분
• Engine(C/C++): 렌더링, 텍스트 레이아웃, Dart VM, 이벤트 처리 등 핵심 런타임
• Embedder(Platform-specific): iOS/Android/웹 등 플랫폼에 맞게 화면, 스레드, 플러그인, 이벤트 루프를 설정

개발자가 Dart로 작성한 UI 코드는 Engine에서 처리되어 플랫폼 Embedder 위에서 실행되는 구조

플러터 vs 리액트 네이티브 플랫폼 통신 구조

• Flutter: Dart 코드가 직접 Engine을 통해 위젯을 렌더링 플랫폼 기능은 메서드 채널로 호출해 Native 서비스와 통신 → 브릿지 비용이 적고 렌더링을 엔진이 직접 수행하므로 성능 이점이 있음
• React Native: JavaScript ↔ Bridge ↔ Native 위젯 구조 → 브릿지를 거쳐 OEM UI를 렌더링하므로 통신 비용이 크고 Flutter보다 오버헤드가 큼

Flutter는 브릿지 없이 자체 엔진으로 UI를 그림, RN은 네이티브 UI를 호출하는 중간 브릿지가 필요

플러터에서의 위젯 (Widget)

모든 것이 위젯이다

위젯 (Widget)

• 플러터에서 화면을 구성하는 모든 요소의 최소 단위
• 텍스트, 버튼, 아이콘 같은 눈에 보이는 UI뿐만 아니라 레이아웃, 패딩, 정렬, 애니메이션 같은 보이지 않는 요소도 모두 위젯
• 플러터는 위젯 트리(widget tree) 구조로 화면을 구성 → 부모 위젯 안에 자식 위젯이 포함되며, 전체 화면이 트리처럼 표현

child와 children의 차이

• 구분	child	children
  수용 가능한 자식 수	1개	여러 개
  타입	Widget	List
  사용 목적	꾸미기, 감싸기, 위치 조정	레이아웃 배치, 리스트 구조
  사용 가능 예	Container, SizedBox	Row, Column, ListView

콜백 함수, 웹뷰 위젯, StatelessWidget vs StatefulWidget, setState

콜백 함수

• 특정 시점에 실행되도록 함수를 인자로 전달하는 구조
• 버튼 이벤트, 제스처, WebView 이벤트 등에서 사용
• UI가 이벤트 기반으로 동작하기 때문에 필수 개념

WebView 위젯

• 앱 내부에서 웹 페이지를 렌더링하는 위젯
• 결제 화면, 약관, 외부 링크 구현에 사용
• URL 로딩, 뒤로가기, JavaScript 통신 지원

StatelessWidget

• 내부 상태가 없는 위젯
• 부모가 전달한 값(생성자 매개변수)이 변경될 때만 build가 다시 실행됨
• 단순 UI 요소에 적합

StatefulWidget

• 상태(State)를 가지고 UI를 갱신하는 위젯
• 실제 상태는 State 객체에 저장됨
• 상태 변화에 따라 build가 재실행됨
• 입력값 변화, 애니메이션, 화면 갱신에 사용
• (사진 참고) 상태 변경이 없는 생명 주기 / StatefulWidget 생성자의 매개변수가 변경됐을 때의 생명 주기 / State 자체적으로 build()를 재실행할 때 생명주기

setState 함수

• StatefulWidget에서 UI를 다시 그릴 때 사용하는 함수
• setState 내부에서 상태 값을 변경하면 해당 위젯만 다시 build됨
• 전체 앱이 다시 그려지는 것이 아니라 필요한 위젯 트리만 갱신됨

디자인 패턴 비교 (MVC / MVP / MVVM / MVI)

아키텍처 패턴 비교표

왜 이런 디자인 패턴들이 중요한가?

1) 화면이 커질수록 코드가 복잡해지기 때문

• 버튼 하나 눌러도 다양한 로직이 필요한데, 이를 한 파일에서 처리하면 금방 “스파게티 코드”가 됨
  • UI 업데이트 / 데이터 갱신 / API 요청 / 라우팅 처리

2) UI와 비즈니스 로직을 분리하면 유지보수성이 올라감

• UI 변경 시 로직 영향 없음
• 로직 변경 시 UI 영향 없음
• 테스트가 쉬워짐

3) 플러터는 선언형 UI이기 때문에 “상태(State)” 설계가 핵심

• UI를 직접 수정하는 것이 아니라 상태를 바꾸면 UI가 자동 업데이트되는 구조 → 즉, “상태 중심 아키텍처"가 중요
• 그래서 MVC처럼 View와 Controller가 얽힌 구조는 잘 안 맞음 → MVVM 또는 MVI 계열이 적합

플러터는 어떤 아키텍처 패턴과 잘 맞는가? -> MVVM 또는 MVI 계열

• 선언형 UI 방식(Build를 계속 다시 그리는 구조)
• 상태 중심(State-driven) 아키텍처
• Provider, Riverpod, Bloc, Cubit 등 생태계 도구들이 모두 MVVM/MVI 구조를 지원

“MVC나 MVP처럼 View가 직접 로직을 호출하는 구조”보다 “ViewModel/Bloc 같은 상태 제공자를 구독해 UI를 만든다” 자연스러움

• 참고 : 플러터 아키텍쳐 패턴 - 플러터가 MVVM과 잘 맞는이유

플러터에서 자주 사용하는 상태관리 도구들

만약 팀에서 Bloc을 사용한다면?

MVI(Model–View–Intent) 기반 단방향 상태관리 아키텍처를 사용한다는 의미 View → Event → Bloc → 새로운 State → View rebuild

• 전통적인 MVVM은 ViewModel이 상태를 가지고 있고, View는 상태만 읽음(양방향 바인딩도 가능)

• Bloç을 쓴다면(MVI) MVVM보다 더 엄격한 단방향 흐름을 가짐 → 코드가 늘어나는 대신, 예측 가능성 + 테스트 용이성 + 유지보수성이 뛰어나 회사들이 선호함

  • View는 Event만 Bloc에게 전달
  • Bloc은 Event + 현재 State로 새로운 State를 생성
  • View는 이 State를 구독

백준 1644. 소수의 연속합 - python

문제 링크

문제 설명

하나 이상의 연속된 소수의 합으로 나타낼 수 있는 자연수들이 있다. 몇 가지 자연수의 예를 들어 보면 다음과 같다.

• 3 : 3 (한 가지)
• 41 : 2+3+5+7+11+13 = 11+13+17 = 41 (세 가지)
• 53 : 5+7+11+13+17 = 53 (두 가지)

하지만 연속된 소수의 합으로 나타낼 수 없는 자연수들도 있는데, 20이 그 예이다. 7+13을 계산하면 20이 되기는 하나 7과 13이 연속이 아니기에 적합한 표현이 아니다. 또한 한 소수는 반드시 한 번만 덧셈에 사용될 수 있기 때문에, 3+5+5+7과 같은 표현도 적합하지 않다.

자연수가 주어졌을 때, 이 자연수를 연속된 소수의 합으로 나타낼 수 있는 경우의 수를 구하는 프로그램을 작성하시오.

입력

첫째 줄에 자연수 N이 주어진다. (1 ≤ N ≤ 4,000,000)

출력

첫째 줄에 자연수 N을 연속된 소수의 합으로 나타낼 수 있는 경우의 수를 출력한다.

내 풀이

뭔가 굉장히 별로인 방법인걸 알지만 슬라이딩 윈도우 구현 방식이 기억이 안나 꾸역꾸역 풀었다. 당연히 시공간 자원 많이 씀.. 범위 설정을 자꾸 틀려서 연습을 많이 해야할 것 같다. 에라토스 뭐시기는 소수 구할 때 써야한다는 건 기억나는데 방법이 기억 안나서 나무위키 잠깐 봤음

# 백준 1644번 소수의 연속합

N = int(input())
answer = 0

# 예외 처리: 2 미만이면 만들 수 있는 연속 소수 합 없음
if N < 2:
    print(0)
    exit()

# 에라토스테네스의 체 (i*i부터 지우기)
temp_list = [i for i in range(N + 1)]
temp_list[0] = 0
temp_list[1] = 0

limit = int(N ** 0.5)
for i in range(2, limit + 1):
    if temp_list[i] != 0:
        start = i * i
        step = i
        for m in range(start, N + 1, step):
            temp_list[m] = 0

prime_list = [v for v in temp_list if v > 0]

# 두 포인터로 연속합 세기 (오른쪽 늘리고, N 이상이면 왼쪽 줄이기)
left = 0
right = 0
temp_sum = 0

while True:
    if temp_sum >= N:
        if temp_sum == N:
            answer += 1
        temp_sum -= prime_list[left]
        left += 1
    else:
        if right == len(prime_list):
            break
        temp_sum += prime_list[right]
        right += 1

print(answer)

아래는 gpt와 함께 코드를 효율적으로 다듬은 거다.

# 백준 1644번 소수의 연속합

N = int(input())
answer = 0

# 예외 처리: 2 미만이면 만들 수 있는 연속 소수 합 없음
if N < 2:
    print(0)
    exit()

# 에라토스테네스의 체 (i*i부터 지우기)
temp_list = [i for i in range(N + 1)]
temp_list[0] = 0
temp_list[1] = 0

limit = int(N ** 0.5)
for i in range(2, limit + 1):
    if temp_list[i] != 0:
        start = i * i
        step = i
        for m in range(start, N + 1, step):
            temp_list[m] = 0

prime_list = [v for v in temp_list if v > 0]

# 두 포인터로 연속합 세기 (오른쪽 늘리고, N 이상이면 왼쪽 줄이기)

left = 0
right = 0
temp_sum = 0

while True:
    if temp_sum >= N:
        if temp_sum == N:
            answer += 1
        temp_sum -= prime_list[left]
        left += 1
    else:
        if right == len(prime_list):
            break
        temp_sum += prime_list[right]
        right += 1

print(answer)

사실 오늘 스터디에서 두 문제를 풀어야 했지만 한 문제는 포기

https://supabase.com/docs/guides/functions/schedule-functions https://supabase.com/docs/guides/database/vault

수퍼베이스에서 기본 제공하는 스케줄러를 사용해서 예약 30분 전 슬랙 알림을 보내는 기능을 구현했다.

service_role_key를 헤더에 하드코딩하는 미친짓을 해보기도 하고 anon, publishable 키들을 사용해 보기도 하고 cron secret이라는 임시키를 만들어서 헤더에도 넣어보고 바디에도 넣어보았지만 401 에러만 뱉고 로그를 찍지도 않는 상황이 반복됐다.

• vault로 DB에 비밀 키 저장해봐라. edge function에는 env에 키 넣어두고 비교하게 하면 헤더에 하드코딩할 필요가 없다.
• 대부분 서비스가 JWT 토큰 검증할 텐데 이것도 그런 거 아니냐?

등의 조언을 들으면서 로그를 찍어보다가, 일단 edge function이 JWT 토큰 형식으로 Authorization 헤더 검사를 하는 것 같다는 결론에 도달했다. 공식 문서에서도 anon 키를 쓰라고 되어 있어서, 쓸데없이 하던 거 다 갖다 버리고 공식 문서대로 하되 anon 키를 vault에 저장해두고 불러 쓰는 식으로 바꾸니까 됐다.

-- **실행한 sql문 정리**

-- vault에 anon key 넣기

SELECT vault.create_secret(
  'eyJ...',  -- Dashboard의 실제 anon key (JWT 형식)
  'publishable_key'
);

-- pg_cron job 업데이트 (Authorization 헤더 포함)

SELECT cron.alter_job(
  (SELECT jobid FROM cron.job WHERE command LIKE '%check-reminders%' LIMIT 1),
  command := $$
  SELECT
    net.http_post(
      url := 'https://프로젝트.supabase.co/functions/v1/check-reminders',
      headers := jsonb_build_object(
        'Content-Type', 'application/json',
        'Authorization', 'Bearer ' || (
          SELECT decrypted_secret 
          FROM vault.decrypted_secrets 
          WHERE name = 'publishable_key'
        )
      ),
      body := '{}'::jsonb
    ) AS request_id;
  $$
);


-- 업데이트된 job 확인 (Authorization과 Bearer 포함 여부 확인용)
SELECT command 
FROM cron.job 
WHERE command LIKE '%check-reminders%';


-- 수동으로 함수 호출 테스트

SELECT
  net.http_post(
    url := 'https://프로젝트.supabase.co/functions/v1/check-reminders',
    headers := jsonb_build_object(
      'Content-Type', 'application/json',
      'Authorization', 'Bearer ' || (
        SELECT decrypted_secret 
        FROM vault.decrypted_secrets 
        WHERE name = 'publishable_key'
      )
    ),
    body := '{}'::jsonb
  ) AS request_id;

해결된 이유는... supabase key에 대한 깃허브 토론과 공식 문서에서 실마리를 찾을 수 있었다. 이런거 많이 봐야지 개발실력이 는다는 유튜브 영상을 봤는데, 트러블 슈팅할 때는 무조건 이것들부터 보는 습관을 길러야 할 것 같다.. API key가 있는 페이지만 봐서는 절대 이해 불가

https://supabase.com/docs/guides/api/api-keys https://github.com/orgs/supabase/discussions/29260

최근 Supabase는 보안 강화를 위해 anon / service_role 키 대신 publishable / secret 키 체계를 새로 도입했는데, 이 새 키들(욕 아님)은 JWT 형식이 아니다. 그래서 Authorization 헤더에 Bearer sb_publishable_... 형태로 넣으면 Edge Function이 “JWT가 아님”이라며 무조건 401을 반환한다.

반면에 기존의 anon 키는 여전히 JWT 기반이어서 기본적으로 JWT 검증이 걸려 있는 Edge Function에서도 정상적으로 인증이 통과된다. 즉, publishable 키로는 안 되고 anon 키로는 되는 이유가 바로 이 구조 차이 때문이다.

edge function에 자동으로 들어가있는 anon key는 로그 찍어보면 publishable형식이다. 그래서 DB에서 edge function 호출할 때 publishable 키를 써야 할 줄 알았지만? 요청 헤더에 JWT(= 레거시 anon 키)를 보내줘야 통과되는 구조라는 거임... 껄껄

기본 설정 그대로라면 Authorization 헤더 + JWT가 있어야 하는데, 헤더 검증을 안하게 하려면 배포 시 --no-verify-jwt 옵션을 사용했거나, 함수 설정에서JWT 검증 해 상태여야 한다고 한다. cli 가 익숙하지 않아서 edge funtion을 수동으로 배포한 사람은... 배포한 함수 페이지 -> details -> funciton configuration에서 끄면 되는 것 같다. 사이트가 많이 개편되어서인지 제대로 경로를 적어놓은 곳이 별로 없다.

AI는 anon key만 쓰거나 jwt 인증을 아예 꺼버리면 보안 쪽 문제가 있으니 cron_secret 같은 임시 키를 만들어서 요청 헤더나 body에 같이 넣고 Edge Function에서 직접 비교해서 외부 무단 접근 막으라는데 일단은 생략..

추후 변경 결국 jwt 검증 아예 끄고 랜덤값 생성한거 DB엔 valut로, edge funtion엔 환경변수로 넣음 헤더에서의 검증에서는 이 값을 사용하는걸로 바꿨음

1. DB 함수 / 프로시저

• Supabase(PostgreSQL)에서는 DB 함수가 곧 프로시저처럼 쓰임 데이터를 조회하거나 수정하는 로직을 DB 내부에 저장해두고 실행하는 코드 블록
• 실행 위치: 데이터베이스 내부
• 역할: 여러 SQL을 하나로 묶어 재사용·트랜잭션 처리에 사용
• 장점: 빠르고 일관성 있음
• 단점: DB 종속이고, 형상관리 어려움

2. 트리거 (Trigger)

• 특정 테이블에 INSERT, UPDATE, DELETE가 일어날 때 자동으로 DB 함수(프로시저)를 실행시키는 메커니즘
• 실행 위치: 데이터베이스 내부 (함수 호출자 역할
• 역할: 데이터 변경 감지 → 후속 처리 (예: 로그 기록, 알림 호출)
• 트리거 자체는 로직이 아니라 “언제 함수를 실행할지 정의한 연결 장치”

3. RPC (Remote Procedure Call)

• 정의: 클라이언트가 Supabase에 정의된 DB 함수를 원격으로 호출
• 실행 위치: Supabase API 게이트웨이를 통해 전달되어 DB 내부 함수가 실행
• 역할: REST API 없이도 데이터베이스 내부 로직(DB 함수)을 직접 호출할 수 있게 함
• 특징:
  • supabase.rpc('function_name') 형태로 호출
  • 네트워크 요청처럼 보이지만, 실제 연산은 DB 내부에서 수행되어 지연이 적음
  • DB 함수가 API처럼 동작하므로 백엔드 서버 없이도 비즈니스 로직 노출 가능

4. RLS (Row Level Security) 와 Policy

• RLS는 데이터베이스의 행 단위 접근 제어 기능, Policy는 그 RLS 위에서 구체적인 접근 조건을 정의하는 규칙
• 로그인된 사용자 정보(auth.uid())를 기준으로, 각 사용자가 자신에게 허용된 행만 조회·수정할 수 있도록 제한
• 실행 위치: DB 내부 (쿼리 실행 시점)
• 역할: “누가 어떤 조건에서 어떤 데이터에 접근 가능한가”를 정의하는 보안 레이어

5. Edge Function

• DB 밖에서 동작하는 서버리스 함수
• 실행 위치: Supabase의 Edge 네트워크 (Deno 기반 서버)
• 역할: 외부 API 호출, Slack 알림, 비즈니스 로직 등 DB에 넣기 애매한 서버 역할을 담당
• 장점: 서버 따로 안 두고 로직 추가 가능
• 단점: 형상관리·테스트 제약이 있어서 팀 규모 커지면 일반 서버 코드로 대체하는 경우 많음

DB 함수(=프로시저) 는 로직의 본체, 트리거는 그걸 자동으로 실행하는 장치, RPC는 DB 함수를 외부에서 API처럼 호출하는 통로, RLS는 접근을 제한하는 보안 규칙, Edge Function은 DB 밖에서 돌아가는 확장 로직이다.

supabase에 slack bot 연동하기

https://api.slack.com/apps/ create new app -> from a manifest -> select a workspace 해서 새 app 생성 app home -> Your App’s Presence in Slack에서 이름 바꿀 수 있음 OAuth & Permissions -> scope에서 chat:write 권한 추가, OAuth Tokens에서 install to 워크스페이스 이러면 Bot User OAuth Token 보일거임

supabase에서 bot token 사용해서 알림 보내는 트리거 함수를 edge function에 등록 settings -> edge functions -> secres에서 bot token 등록 (로컬에서 테스트할 땐 환경변수에 저장)

후술하지만 다른 방식도 있습니다

slack oicd 연동해뒀으면 Authentication에 Sign In / Providers 쪽에 slack oicd가 enabled되어 있을텐데... 봇을 쓴다고 해서 client id랑 client secret을 전부 바꿀 필요는 없는듯? 워크스페이스가 다를 때만 의미가 있는 것 같음

supabase에서 스케줄러 사용하기

문제 상황

• 30분 전 알림은 주기적 실행이 필요
• Docker 사내망 배포 환경
• 별도 스케줄러 인프라 구축 부담

해결 방법 비교

더 자세히 보면

Edge Function + pg_cron 선택 이유

1. 인프라 설정 불필요
   • 별도 서버/스케줄러 없음
   • pg_cron만 설정하면 자동 실행
2. 형상관리 가능
   • Edge Function 코드를 Git에 포함
   • 이전 Edge Function은 코드베이스에 없어 관리 어려움
3. 간단한 설정
   • SQL 한 번 실행으로 완료
   • Dashboard에서 환경 변수만 설정
4. 자동 실행
   • Supabase가 스케줄링 처리
   • 모니터링/로그 확인 용이

DB Function과 Edge Funciton -> 요즘은 안쓴다?

형상 관리가 어려워서 좀 복잡해지는 한이 있더라도 codebase로 옮기는 추세 slack 알림 연동 기능을 처음엔 edge function으로 작성했으나 코드로 마이그레이션 했음 gemini 코드 리뷰에서 원자성 보장을 위해 db function쓰는거 생각해보라 했지만 최대한 서버액션으로 처리하는걸로 결정

그러나... 주기적 알림을 추가 인프라를 만지지 않고 구현하려다보니 pg_cron을 사용하게 되면서 edge function을 다시 쓰게 되긴 했다

supabase cli로 edge function 배포하기

직접 사이트에서 edge function을 deploy해왔었는데 구글링하다가 발견.. 공식 문서를 잘 읽읍시다 https://supabase.com/docs/guides/functions/deploy post 401 에러에 마주쳤는데 이건 jwt 인증 끄고 해결..? https://github.com/orgs/supabase/discussions/33194 이건 좀 위험하다해서 cron secret을 헤더에 추가해서 검증...? 사실 이해가 좀 덜 되긴 했다. sql문 지금까지 실행하면서 policy / db함수 / edge function 만든 거 다시봐야될 것 같다.

SELECT cron.schedule(
  'check-reminders',
  '*/5 * * * *',  -- 매 5분마다
  $$
  SELECT
    net.http_post(
      url := 'https://프로젝트코드.supabase.co/functions/v1/함수이름',
      headers := jsonb_build_object(
        'Content-Type', 'application/json',
        'x-cron-secret', '임의의 값' 
      ),
      body := '{}'::jsonb
    ) AS request_id;
  $$
);

지금 당장 해야할 일들이 많이 쌓여있지만 너무 집중이 안되니까 기록이라도 하나 남겨놓으려고 오랜만에 블로그에 방문했다. 사실 그냥 조잘조잘 떠들 공간이 필요했답니다

출근 첫날엔 전반적인 회사생활에 대한 온보딩 교육, 앞으로 진행할 프로젝트에 대한 온보딩 교육을 들었다. 배정받은 장비로 작업 환경을 세팅했는데, 처음으로 맥북을 사용하게 돼서 적응하는게 쉽지 않았다. (요즘은 조금 적응했는데, 회사에서는 macOS 쓰고 집에서는 window 쓰니까 자꾸 키가 헷갈려서 킹받는다. 지금도 한영키 대신 caps lock, ctrl대신 fn 키 눌러대는 중)

업무 적응을 위해 일주일 간 토이 프로젝트를 진행하게 됐다. 회사에서 사용하고 있는 그룹웨어에서 좀 불편하게 되어 있는 기능이 하나 있는데, 그걸 확실히 개선한 시스템을 만들어서 사내망에 배포할 예정이다. 하루만에 프로젝트 범위 잡고 ERD, flow chart 작성 후, 수~금 3일간 개발을 진행했다. 처음에는 간단해보였지만, 생각보다 쉽지 않다. express, prisma, supabase, adminjs, react // potainer, nginx proxy manager, github action

이해가 안되는 게 많아도 어떻게든 기간안에 뭘 만드려고 바이브 코딩을 해댔는데, 회사에서 지원해준 cursor 팀 플랜에서 기본제공 20달러 + 청구형 50달러 사용을 달성했다. 금요일 퇴근할 때 쯤에 팀장님께서 언질주셔서 확인해보게 됐는데 ㄹㅇ 대충격 먹음 비싼 모델 막 쓴 게 문제가 된 것 같은데, 3일만에 70달러는 좀 아니잖아 징짜 cursor pro 결제해서 썼을때는 auto로 놓고 썼고 추가비용 들일도 없어서 너무 안일했다. 월급에서 깐다고 농을 하셨는데 눈치가 엄청 보였다. AI를 보조도구로만 사용해야하는 이유가 금액적인 부분에도 있는 듯 실제 프로젝트 투입되면 spring 사용할 것 같던데 더 걱정이다.

내 개발 실력을 키우는 것이 해결방안임이 자명함에도.... 일단 인턴 생활 중이니 업무 투입됐을 때 도움이 되어야 한다는 생각과 생산성 측면에서 AI를 안쓰는 건 불가능하다는 생각때문에 claude code, cursor 유료 플랜들을 막 찾아봤다. 개인적으로 이용중이던 chatGPT, cursor의 20$ 플랜 결제 중단하고 조만간 claude code의 100$ 플랜을 결제하게 될 것 같다^.^ 개비싸 진짜 IDE가 편하다고 머무르려고 하지 말고 더 성능좋고 가성비 좋은 걸 사용하자.. 회사의 지원이 어렵다면, 많은 걸 경험하고 배우는 입장이니 혼자서라도 사서 여러 방면에 사용해보자... 프롬프트 효율적으로 작성하는 법이랑 비용 아끼는 법들도 있으니 많이 찾아보자....

회사는 위치나 업무환경이 너무 좋고, 사람들도 좋다. 데일리 스크럼 참여하면서 뭐라도 한마디 내뱉는 게 아직은 어색하지만 개발팀 일원이 된 것 같아 기분이 미묘하다. 일이 많을 것 같긴 하지만, 바로 주요 업무에 투입되면서 배우는 부분이 엄청 많을 것 같다. 다만 어리벙벙한 나 때문에 동기가 고통받을 것 같아 미리 죄송함

공부를 계속하면서도 느끼는건데 개발자들은 정말 대단하다 저도 업계에서 살아남고 싶어요 흑흑 열심히 해볼게요

• 지금 쓰긴 귀찮아서 내일 수정 예정

CPU Scheduling 알고리즘

FCFS (First Come First Served)
SJF (Shortest Job First)
SRTF (Shortest Remaining Time First)
Round Robin
Multilevel Queue Scheduling

Semaphore와 Mutex Race Condition Deadlock Context Switching Multi-Level Feedback Queue Scheduler (MLFQS)

Project 1

Chapter 3. Machine-Level Representation of Programs
Chapter 12. Concurrent Programming

클라이언트-서버 모델 웹페이지

소켓(socket, bind, listen, accept, connect, close)웹페이지

파일 디스크립터 웹페이지

Datagram Socket vs Stream Socket웹페이지

CGI / WebServer / MIME Type웹페이지

HTTP (요청/응답, 헤더, 메소드, 상태코드, HEAD 메소드)웹페이지

Proxy

BSD소켓, IP, TCP, HTTP, file descriptor, DNS

웹 서버는 클라이언트(브라우저 등)와 HTTP 프로토콜을 사용해 통신한다. 클라이언트는 서버에 정적 콘텐츠 혹은 동적 콘텐츠를 요청하며, 요청 방식에 따라 서버의 응답 방식이 달라진다.

• 정적 콘텐츠(static content): 서버는 클라이언트의 요청을 받으면 디스크에서 해당 파일을 읽어 클라이언트로 전송한다.
• 동적 콘텐츠(dynamic content): 서버는 요청을 처리하기 위해 자식 프로세스(child process)를 생성하고, 그 안에서 프로그램을 실행하여 출력 결과를 클라이언트에게 반환한다.

이때 사용되는 것이 CGI (Common Gateway Interface) 표준이다. CGI는 다음과 같은 정보를 다룰 수 있는 규칙들을 정의한다.

• 클라이언트가 서버에 전달하는 프로그램 인자
• 서버가 자식 프로세스에 전달하는 환경 정보
• 자식 프로세스가 클라이언트에 출력 결과를 전달하는 방법

이러한 구조를 바탕으로, 정적 및 동적 콘텐츠를 모두 제공하는 웹 서버는 수백 줄의 C 코드만으로도 구현 가능하다. 이는 웹 통신의 본질이 클라이언트-서버 모델 + 소켓 통신 + 간단한 프로토콜 해석에 있음을 보여준다.

내가 궁금해서 찾아본 QnA

[1] 브라우저가 웹사이트를 처음 열었을 때

• 사용자가 https://www.google.com에 접속하면 브라우저는 내부적으로 다음 순서를 따른다:
  • getaddrinfo()로 도메인을 IP 주소로 변환 (DNS 질의 포함)
  • socket() 호출로 TCP 소켓 생성
  • connect()를 통해 서버에 3-way handshake 요청
  • 서버는 listen() 상태에서 대기 중이므로, accept()로 연결 수락 후 connfd 반환
  • 이 연결을 통해 서버는 HTML과 이미지, JS 등의 리소스를 응답하고 브라우저는 이를 화면에 렌더링

[2] 이후 같은 도메인에서 검색이나 이동이 발생했을 때

• HTTP/1.0 이라면 기본적으로 요청-응답 이후 TCP 연결을 끊는다 → 검색을 할 때마다 새로운 socket()과 connect() 호출
• HTTP/1.1 이상 이라면 기본적으로 Persistent Connection 유지:
  • 서버가 Connection: keep-alive 헤더를 응답에 포함하면,
  • 브라우저는 기존 TCP 연결을 재사용하여 요청을 보냄 (같은 connfd에서 rio_readlineb() 등으로 다시 처리)
  • 단, 서버가 연결을 닫거나 일정 시간이 지나면 새로운 연결을 다시 수립함

[3] 다른 도메인(예: naver.com)으로 이동했을 때

• 새로운 DNS 질의(getaddrinfo("www.naver.com"))를 통해 IP 주소 획득
• 별도의 socket() 및 connect()로 새로운 TCP 연결 생성
• 이 연결은 완전히 독립적인 소켓이며, 서버 측에서도 다른 프로세스 혹은 다른 listenfd에서 수락됨

[4] 브라우저의 "뒤로 가기" 버튼을 눌렀을 때

• 대부분의 경우 캐시된 페이지를 재활용 하며, 네트워크 요청이 발생하지 않음
• 발생해도 다음과 같은 캐시 제어 정책에 따름:
  • 200 (from cache): 완전히 로컬에서 렌더링
  • 304 Not Modified: 서버에 조건부 요청 (If-Modified-Since, If-None-Match 등)을 보내고 변경 없음 판단 시 캐시 사용
• 따라서 "뒤로 가기"는 소켓 재연결 없이도 동작하는 브라우저 레벨 히스토리 복원 에 해당

[5] 로그인 상태에서 새 탭을 열었을 때 로그인 유지 이유

• 로그인 정보는 TCP 연결이 아닌 HTTP 쿠키 에 저장됨
• 쿠키는 브라우저의 도메인 단위 저장소 에 기록되며, 같은 브라우저 프로세스에서 새 탭을 열더라도 다음 요청에 자동 첨부됨
• 따라서 새로 열린 탭에서 새로운 TCP 연결이 생성되더라도 로그인 상태는 쿠키를 통해 유지됨

[6] 같은 URL이라도 접근 경로(링크 클릭 vs 직접 입력)에 따른 차이

• HTTP 요청에 포함되는 Referer 헤더가 다름:
  • 링크 클릭 시: Referer는 이전 페이지의 URL
  • 주소창 직접 입력 또는 즐겨찾기 클릭 시: Referer는 빈 문자열이거나 존재하지 않음
• 서버는 이 값을 이용해 사용자 유입 경로, 광고 성과 측정, A/B 테스트 등을 수행할 수 있음

[7] 동일한 URL 요청 시 브라우저가 캐시를 사용할지 서버에 다시 요청할지 결정하는 기준

• 서버 응답의 헤더에 따라 달라짐:
  • Cache-Control: no-cache: 무조건 서버 재확인
  • ETag: 클라이언트는 If-None-Match로 조건부 요청 수행, 변경 없으면 304 응답
  • Expires: 기한 전까지는 재요청하지 않음
• 같은 URL이라도 HTTP 메서드(GET/POST), 헤더, 쿠키 상태, 캐시 제어 값에 따라 네트워크 요청 여부가 결정됨

[8] 브라우저에서 하나의 HTML 요청이 만들어내는 다수의 연결

• 브라우저는 HTML 본문 외에도 CSS, JS, 이미지 등 수십 개의 리소스를 병렬로 요청함
• HTTP/1.0: 한 연결당 하나의 리소스 → 다수의 socket() 호출과 connect() 필요
• HTTP/1.1: Persistent Connection + 파이프라이닝 가능 → 같은 연결 재사용
• HTTP/2: 하나의 TCP 연결 내에서 멀티플렉싱 을 통해 동시에 여러 요청/응답 처리

[9] keep-alive 연결은 언제 끊기는가?

• HTTP/1.1에서 기본적으로 Connection: keep-alive지만 무한히 유지되진 않음
• 서버는 일정 시간(timeout) 동안 추가 요청이 없으면 연결을 닫음
• 클라이언트도 명시적으로 Connection: close를 보낼 수 있음
• close 후에는 새로운 요청 시 새로운 TCP 연결을 열게 됨

[10] HTTP와 TCP의 관계, 그 사이에서 발생할 수 있는 문제들

• HTTP는 TCP 위에서 동작하는 텍스트 기반 프로토콜
• TCP는 바이트 스트림이므로, HTTP 메시지의 경계를 보장하지 않음
  • 예: 2개의 HTTP 요청이 하나의 TCP 세그먼트로 묶일 수도 있고 반대로 쪼개질 수도 있음
• 따라서 웹 서버는 버퍼 기반으로 \r\n 또는 헤더 길이를 기준으로 정확히 메시지를 파싱해야 함

[11] 서버는 동시에 여러 연결을 어떻게 처리하나?

• 전통적 방식: accept() 후 fork() 또는 pthread_create()로 각 연결을 분기 처리
• 현대적 방식:
  • select(), poll(), epoll() 등을 사용한 I/O Multiplexing
  • 비동기/논블로킹 소켓
  • 이벤트 기반 서버 (예: Node.js, Nginx)
• 이 모든 방법은 클라이언트 수 증가에 대응하기 위한 확장성 확보 방식임

[12] HTTPS의 등장으로 생기는 차이점

• HTTPS는 HTTP 메시지를 TLS를 통해 암호화하여 전송
• socket() 후 connect()까지는 같지만, 이후 TLS Handshake를 통해 인증서 교환 및 키 협상이 추가됨
• 이후부터는 애플리케이션 레벨에서는 평문처럼 GET /, Host: 등을 보내더라도 실제 전송은 모두 암호화됨
• HTTPS에서는 중간 프록시가 내용 파악 불가 , 캐시 활용도 제한됨

웹 서버(CS:APP 11.5)

웹 기초

웹은 HTTP(Hypertext Transfer Protocol)라는 텍스트 기반 애플리케이션 계층 프로토콜을 통해 클라이언트와 서버가 통신하는 구조다. 클라이언트인 브라우저는 서버와의 인터넷 연결을 열고 콘텐츠를 요청한 뒤, 서버가 응답을 보내고 연결을 종료하면 그 내용을 화면에 출력한다. 이 과정은 매우 단순한 요청-응답 패턴으로 이루어진다.

웹 서비스가 FTP와 같은 전통적인 파일 전송 서비스와 구별되는 가장 큰 특징은, 콘텐츠가 HTML(Hypertext Markup Language)이라는 언어로 작성된다는 점이다. HTML은 텍스트와 그래픽 요소들을 화면에 어떻게 표시할지를 지시하는 태그(tag)로 구성되며, 예를 들어 <b>Make me bold!</b>는 해당 텍스트를 굵게 표시하라는 지시다.

하지만 HTML의 진정한 힘은 문서 안에 하이퍼링크(hyperlink)를 포함할 수 있다는 점에 있다. 하이퍼링크는 인터넷상의 다른 호스트에 있는 콘텐츠를 참조할 수 있게 해준다. 예컨데 <a href="http://www.cmu.edu/index.html">Carnegie Mellon</a>이라는 태그는 'Carnegie Mellon'이라는 텍스트를 강조 표시하며, 사용자가 이를 클릭하면 브라우저는 CMU 서버에 저장된 index.html 파일을 요청하고, 응답을 받아 화면에 표시한다.

웹 컨텐츠

웹 서버와 클라이언트가 주고받는 웹 콘텐츠는 MIME 타입이 명시된 바이트 시퀀스로 구성된다. 서버는 이러한 콘텐츠를 두 가지 방식으로 제공할 수 있다. 첫째, 디스크에 저장된 파일을 그대로 반환하는 정적 콘텐츠(static content) 방식이 있다. 예를 들어 HTML, 이미지, CSS 파일 등이다. 둘째, 실행 가능한 프로그램을 실행한 결과(실행파일이 런타임에 만든 출력)를 반환하는 동적 콘텐츠(dynamic content) 방식이 있으며, 이는 CGI 방식 등으로 서버에서 프로그램을 실행하고 그 출력을 클라이언트에게 전달한다.

각 콘텐츠는 고유한 URL(Uniform Resource Locator)로 식별되며, 이는 서버 주소, 포트, 파일 경로, 그리고 필요시에는 프로그램 인자까지 포함한다. 예를 들어, http://host:port/path/to/file 같은 URL에서 클라이언트는 호스트와 포트를 통해 서버에 접속하고, 서버는 그 뒤의 경로를 해석해 파일을 찾는다. (? 로 파일 이름과 인자를 구분, &로 인자 연결)

서버는 URL의 경로(접미사)를 분석하여 정적 혹은 동적 콘텐츠인지를 판별하는데, 이는 서버마다 다르며 보통 cgi-bin과 같은 특정 디렉토리에 따라 결정된다. 또한 /만 있는 요청은 index.html 같은 기본 파일로 확장되어 처리된다.

HTTP 트랜잭션

HTTP 트랜잭션은 클라이언트와 서버 간의 요청(request)과 응답(response)을 텍스트 기반의 애플리케이션 계층 프로토콜인 HTTP를 통해 주고받는 과정을 말한다. 이 프로토콜은 단순하고 사람이 읽기 쉬운 형식으로, telnet 같은 도구를 통해 수동으로도 요청을 생성해 확인할 수 있다.

// 정적 컨텐츠를 제공하는 HTTP 트랜잭션의 예

1  linux> telnet www.aol.com 80       # 클라이언트가 Telnet 명령어로 AOL 웹 서버(포트 80)에 TCP 연결 시도
2  Trying 205.188.146.23...           # Telnet이 도메인명을 IP 주소(IPv4)로 변환하여 접속 시도 중
3  Connected to aol.com.              # TCP 연결 성공
4  Escape character is '^]'.          # Telnet 세션을 종료할 때 사용할 이스케이프 문자 안내
5  GET / HTTP/1.1                     # 요청 라인: 루트 페이지(/)를 요청하는 HTTP/1.1 GET 요청
6  Host: www.aol.com                  # 필수 요청 헤더: 요청한 호스트 이름 (HTTP/1.1에서 필수)
7                                     # 빈 줄: 헤더 종료를 나타내며, 본문이 없음을 의미 (GET 요청의 경우 일반적)
8  HTTP/1.0 200 OK                    # 응답 라인: HTTP/1.0 기반 응답이며, 상태 코드 200은 정상 처리 의미
9  MIME-Version: 1.0                  # MIME 버전 정보 (콘텐츠의 형식을 설명하기 위한 사양)
10 Date: Mon, 8 Jan 2010 4:59:42 GMT  # 응답이 생성된 시간 (표준 형식, GMT 시간대)
11 Server: Apache-Coyote/1.1          # 서버 소프트웨어 정보 (서버 식별용)
12 Content-Type: text/html            # 응답 본문의 MIME 타입 (HTML 문서임을 명시)
13 Content-Length: 42092              # 응답 본문의 바이트 수 (클라이언트는 이 길이만큼 읽으면 됨)
14                                    # 빈 줄: 응답 헤더 종료를 알림
15 <html>                             # 응답 본문 시작: HTML 페이지의 첫 줄
16 ...                                # 생략된 HTML 콘텐츠 (총 766줄)
17 </html>                            # HTML 문서 종료
18 Connection closed by foreign host. # 서버가 연결을 종료함 (HTTP/1.0은 기본적으로 비지속 연결)
19 linux>                             # Telnet 클라이언트도 종료됨, 셸로 복귀

// 동적 HTML 컨텐츠를 제공하는 HTTP 트랜잭션의 예

1  linux> telnet kittyhawk.cmcl.cs.cmu.edu 8000      # 클라이언트: kittyhawk 서버의 8000번 포트로 TCP 연결 시도
2  Trying 128.2.194.242...                           # telnet: 해당 호스트의 IP 주소로 DNS 해석 후 접속 시도
3  Connected to kittyhawk.cmcl.cs.cmu.edu.           # telnet: 서버와의 TCP 연결이 성공적으로 이루어짐
4  Escape character is ’^]’.                         # telnet: 연결 중 명령어를 빠져나오는 특수 키 안내
5  GET /cgi-bin/adder?15000&213 HTTP/1.0             # 클라이언트: CGI 프로그램 호출 요청 (파일명과 인자 포함한 GET 요청)
                                                        → URI: /cgi-bin/adder 프로그램을 15000, 213 인자와 함께 실행 요청
6                                                    # 클라이언트: 빈 줄을 통해 요청 헤더 종료 (필수, HTTP 규격상)
7  HTTP/1.0 200 OK                                   # 서버: 정상 처리 응답 (200 상태 코드)
8  Server: Tiny Web Server                           # 서버: 응답 헤더로 서버 종류 명시 (Tiny 서버 사용 중)
9  Content-length: 115                               # CGI 프로그램: 응답 본문의 총 바이트 수 (115바이트)
10 Content-type: text/html                           # CGI 프로그램: 응답 콘텐츠의 MIME 타입은 HTML
11                                                   # CGI 프로그램: 빈 줄로 응답 헤더 종료 표시
12 Welcome to add.com: THE Internet addition portal. # CGI 프로그램: HTML 본문 시작 – 첫 줄
13 <p>The answer is: 15000 + 213 = 15213             # CGI 프로그램: 실제 계산 결과가 포함된 HTML 문단
14 <p>Thanks for visiting!                           # CGI 프로그램: 마지막 안내 문구 포함 HTML 문단
15 Connection closed by foreign host.                # 서버: CGI 출력 완료 후 연결 종료
16 linux>                                            # 클라이언트: telnet 종료됨, 프롬프트로 돌아감

HTTP 요청은 클라이언트가 서버에 특정 리소스를 요구하기 위해 보내는 메시지로, 요청 라인, 요청 헤더, 그리고 빈 줄로 구성된다. 요청 라인은 보통 GET /index.html HTTP/1.1 형태를 가지며, 여기서 GET은 요청 메서드, /index.html은 요청하려는 리소스의 경로(URI), HTTP/1.1은 사용하는 프로토콜 버전을 의미한다. 이어지는 요청 헤더들은 클라이언트의 브라우저 정보나 허용 가능한 콘텐츠 형식 등을 전달하며, 특히 Host 헤더는 HTTP/1.1에서 필수로 포함되어야 하고, 요청 대상 서버의 도메인 이름을 명시한다. 마지막 빈 줄은 헤더의 끝을 나타내며, 이후에 본문(body)이 따라올 수도 있다. POST 요청의 경우가 바로 이런 예로, 클라이언트가 서버에 데이터를 전송할 필요가 있을 때 사용된다. 예를 들어 로그인 정보나 폼 데이터를 서버로 보낼 때, POST 요청은 요청 본문에 그 데이터를 포함시켜 전송한다. 이때 Content-Type이나 Content-Length 같은 헤더가 함께 사용되어, 본문의 데이터 형식과 길이를 서버에 알린다. 모든 HTTP 요청의 각 줄은 \r\n으로 끝나야 하며, 이는 HTTP 명세에서 정한 필수 형식이다.(\r 커서를 줄의 맨 앞으로 이동시킴, \n 현재 위치에서 줄을 바꿈)

HTTP 응답은 서버가 클라이언트의 요청에 대해 보내는 메시지로, 응답 라인, 응답 헤더, 빈 줄, 응답 본문으로 구성된다. 응답 라인은 예를 들어 HTTP/1.0 200 OK와 같은 형식으로, 서버가 응답하는 HTTP 버전, 상태 코드(예: 200은 성공), 상태 메시지를 포함한다. 응답 헤더는 Content-Type, Content-Length 등의 메타데이터를 담고 있으며, 이는 클라이언트가 응답 내용을 어떻게 해석할지 결정하는 데 도움을 준다. Content-Type은 MIME 타입을 명시하며, Content-Length는 본문의 크기를 바이트 단위로 제공한다. 빈 줄 이후에는 HTML 문서와 같은 실제 콘텐츠가 응답 본문으로 포함되며, 클라이언트는 이를 파싱해 화면에 출력한다. 이와 같은 구조 덕분에 브라우저는 텍스트 기반의 요청과 응답만으로도 웹 페이지를 정확히 렌더링할 수 있다.

동적 컨텐츠의 처리

웹 서버가 동적 콘텐츠를 제공하려면 단순히 파일을 읽어 반환하는 것과는 달리 여러 추가 작업이 필요하다. 클라이언트가 동적 콘텐츠를 요청할 때는, 실행할 프로그램과 인자를 함께 전달해야 하며, 서버는 이 요청을 해석해 프로그램을 실행하고 그 출력을 클라이언트에게 반환해야 한다. 이를 가능하게 해주는 표준이 바로 CGI (Common Gateway Interface) 다.

클라이언트는 GET 요청에서 인자를 URI의 일부로 전달한다. 예를 들어 adder?15000&213 같은 형식에서 ? 뒤가 인자이며, 여러 인자는 &로 구분된다. 공백과 같은 특수문자는 %20 같은 문자열로 인코딩된다.

서버는 이 요청을 받아 fork()로 자식 프로세스를 만든 뒤, execve()로 CGI 프로그램을 실행한다. 이때 서버는 QUERY_STRING이라는 환경 변수를 설정하고, 여기에 15000&213처럼 클라이언트가 넘긴 인자를 넣는다. CGI 프로그램은 실행 중에 getenv("QUERY_STRING")처럼 환경 변수에서 이 값을 읽을 수 있다.

CGI는 이 외에도 CGI 프로그램이 알아야 할 정보(요청 메서드, 서버 이름, 사용자 에이전트 등)를 위해 다양한 환경 변수를 정의한다. 예를 들어 REQUEST_METHOD, CONTENT_TYPE, SCRIPT_NAME 등이 있다.

CGI 프로그램의 출력은 표준 출력(stdout)을 통해 클라이언트로 직접 전달된다. 서버는 exec 전에 dup2()를 사용해 자식 프로세스의 stdout을 클라이언트 소켓 디스크립터로 리디렉션한다. 따라서 CGI 프로그램이 printf() 등을 호출하면, 그 출력은 그대로 웹 브라우저에 전달된다.

CGI 프로그램은 반드시 응답 헤더를 스스로 생성해야 한다. 서버는 콘텐츠의 타입이나 길이를 알 수 없기 때문에, CGI 프로그램이 Content-type과 Content-length 같은 HTTP 응답 헤더와 빈 줄을 직접 출력해야 한다. 그 뒤에 본문을 출력하는 구조다. 이는 정적 콘텐츠와 가장 큰 차이점 중 하나다.

Tiny Web Server 구현하기