우리는 단일 상품만 등록하는데,,

상품등록	그룹상품등록

네이버 솔루션 API 전환을 하다가 문득 그룹 상품 등록이 눈에 띄었다. 우리는 단일 상품만 쓰고 있는데,, 흠. 그룹 상품은 뭐지?

등록과 추천은 다른 이야기일지도

• 상품 등록 = 시스템에 상품을 넣는 기준
• 상품 추천 = 어떤 상품을, 어떤 기준으로 묶어서 보여줄지

셀파트너는 지금 단일 상품을 기준으로 상품을 추천해주고 있다.

그렇다면, 그룹 상품 등록은 우리에게 필요한 기능일까?

상품을 아주 단순하게 표현해보자면,,

• 상품 → 점

• 상품 추천의 단위 → 선

• A 상품과 B 상품이 자주 같이 팔린다면

• A와 B 사이에는 굵은 선이 하나 생긴다

그렇다면 상품 추천은 결국 점과 점을 어떻게 연결하느냐의 문제가 된다. 마치 그래프,, 라 할 수 있다.

문제는

다 연결하면 너무 복잡함

그럼 모든 상품을 전부 연결하면?

• A도 B랑 연결
• A도 C랑 연결
• B도 C랑 연결
• C도 D랑 연결

셀러 입장에서는

그래서 어쩌라고?,,,

모든 관계를 다 보여주는 건 판단을 오히려 어렵게 만들 것 같다. 그럼 정말 필요한 연결만 남길 수는 없을까?

MST: 꼭 필요한 연결만 남긴다는 생각

여기서 오늘 공부했던 개념이 최소 신장 트리(MST). 이름은 어렵지만,, 개념은 꽤 직관적이다.

모든 점을 연결하되, 가장 작은 연결만으로 설명하자

상품 추천으로 치환해보자면,,

• 다 묶을 필요는 없고,
• 가장 의미 있는 연결 몇 개면 충분하다는 것.

"왜 이 상품들이 추천 대상인지"

그럼 어떤 연결부터 남겨야 하는데?

연결은 줄이겠는데... 그럼 뭘 기준으로 남겨야 하나ㅏ,, 그래서 한 단계 더 들어가면 Kruskal 알고리즘이 등장한다.

Kruskal: 제일 확실한 것부터

1. 제일 확실한 관계부터 보기
2. 하나씩 연결해보기
3. 이미 충분히 연결된 경우는 넘어가기

"일단 잘 팔리는 조합부터 보자"

Union-Find: 이미 같은 묶음일까?

Kruskal이 제대로 동작하기 위해서는 이 두 상품이 이미 같은 그룹인지 확인이 필수다. 이걸 확인하는 게 Union-Find.

Union-Find는

• 상품이 어떤 그룹에 속해 있는지 관리하고
• 이미 묶인 상품을 또 묶지 않게 해준다

이게 없으면

• 비슷한 그룹이 계속 생기고
• 구조는 금방 복잡해짐

Path Compression

한 번 확인한 건, 다음엔 더 빠르게

Union-Find의 최적화 Path Compression

처음에는

• A랑 D가 같은 그룹인지 확인하려면
• A → B → C → D 여러 단계를 거쳐야 할 가능성이 높음

한 번 확인하고 나면

• A, B, C가 전부 바로 D를 가리키게 되는 것.

한 번 검증된 상품 묶음은 다음엔 훨씬 빠르게 판단할 수 있다.

데이터가 쌓이면 판단은 가벼워진다.

그래서

• MST: 꼭 필요한 만큼만 묶고
• Kruskal: 가장 신뢰할 수 있는 관계부터 선택하고
• Union-Find + Path Compression: 중복 없이, 점점 더 빠르게 판단

이긴 한데,, 결국 처음의 질문으로 돌아와서 그룹 상품 API 필요하다고? 라고 하면 아아직은,,,, 안필요한듯,, 그냥 공부에 의의를 두기로 ㅎ

나는

개발을 하다 보면 기능을 만드는 데만 집중하게 된다. 오늘도 스터디를 앞두고 시작하지 못한 쿠팡이 눈앞에 아른거렸다..

그렇지만,, 좋은 기능은 잠시 쉬었다 가는 것, 또 좋은 질문에서 시작한다고 생각한다.

• 이 기능은 왜 필요할까
• 이 구조는 누구를 위한 것일까
• 더 단순하게 설명할 방법을 없을까

계속 공부하고 질문하는 개발자 되기

다익스트라 알고리즘

한 지점에서 다른 지점까지 가는 최단 경로를 찾는 알고리즘.

네이버 지도나 구글 지도가 길 안내할 때 여러 개의 경로를 보여주는데, 그 밑바탕에 깔린 기본 알고리즘이 바로 이 다익스트라 알고리즘이라고 한다.

핵심 아이디어

가장 짧은 길을 하나씩 확정시키며 탐색해 나간다.

처음 시작 지점에서 "현재까지 가장 가까운 지점"을 하나씩 확정해 나가는 구조다.

• '지금 당장 최적'인 선택을 하고
• 그 선택이 전체적으로도 최적이라는 성질을 이용하는 것

일명 그리디(Greedy) 방식이다.

한 스텝씩, 한 노드 씩, "지금 계산된 것 중에 제일 짧은 길"을 선택하고 확정하고, 그 확정된 노드를 바탕으로 또 다른 노드를 업데이트한다.

이걸 반복하면 어느 순간 "모든 최단 거리"가 구해진다.

백트래킹은 조합을 찾는 데 좋고, 다익스트라는 '최적의 한 경로'를 찾는 데 강하다.

근래 데이터 파이프라인과 AI 작업의 시간 단축에 대해서 고민하고 있는데, "가장 효율적인 수집 경로",,,, 이게 곧 다익스트라 아닌가?

백트래킹도 그렇고 알고리즘을 다시 보다 보니 괜히 이름 붙은 알고리즘이 아니다. 하나의 코딩 테스트 문제를 해결하려고 만들어진 게 아니라 여러 실생활 문제에 응용될 수 있도록 설계되어 있다는 게 확 체감되는,,

"가장 빠른 길"을 찾아주는 알고리즘이 있다면 개발자에게도 셀러에게도 너무 좋쟈나..

끊임 없이 고민하는 직원 되기.

오늘 리마인드한 개념은 바로 백트래킹(backtracking).

이름만 들을 때는 뭔가 거창하고 어려운 알고리즘 같지만, 실제로 이해해보면 굉장히 단순하다.

막다른 길이면 다시 돌아가기

백트래킹은 미로에 비유하면 제일 이해가 잘 되는 것 같다.

길을 걷다가

• 막다른 길을 만나면 뒤로 돌아가고,
• 다른 길을 탐색해보고,
• 또 막히면 돌아오고,,

이걸 컴퓨터가 반복하는 것이 바로 백트래킹이다.

문제 해결에 적용해보면 "모든 가능한 선택을 해보되, 조건에 맞지 않으면 즉시 포기하고 되돌아가 다른 선택을 시도하는 방식"이 된다.

사람스러운(?) 방식 같기도,,

셀파트너는 오픈마켓 셀러가 해야 하는 복잡한 작업을 AI로 자동화해주는 서비스다. 셀러의 업무에 대해서는 아직 알아가는 중이긴 하지만, 업무의 절반이 여러 조합 중에서 좋은 조합을 찾는 일인 것 같다.

백트래킹 아이디어 기록해두기

• 상품명 키워드 조합 찾기
• 카테고리 추천 자동 필터링

셀러 본인이 하면 몇 시간씩 걸리겠지만 백트래킹 알고리즘을 쓴다면 조건에 맞지 않는 조합을 즉시 버려가면서 훨씬 빠르게 최적 조합에 도달할 수 있다.

아직 등록 시스템만 출시되었고, 이후 솔루션화시켜가는 과정 중에 있지만, 백트래킹이라는 알고리즘을 AI 안에 잘 접목 시켜보면, 생각보다 깔끔하고 똑똑한 시스템이 될 듯 하다. 개발자도 사용자도 만족하는,,

코테 준비하면서 알고리즘 공부할 때는,, 머리가 아주 지끈지끈 했었다. 막상 실무에 뛰어 들어보니, 우리 서비스처럼 '조건 많은 조합 문제'가 많은 분야에서는 백트래킹이라는 게 꽤 실용적이게 쓰일 수 있을 것 같다.

AI가 후보를 왕창 만들고 백트래킹이 그 후보를 똑똑하게 거르는 느낌?

언젠가는 이론을 실무에 녹일 수 있는 시니어가 되기를.

인수인계를 받아보니,,, "이 함수가 뭐 하는 함수지?" 싶은 순간이 꽤 많다. 함수 위에 친절하게 설명이 달려있는 경우, 아주 땡큐베리감사. 이런 설명을 Docstring이라고 하는데, 함수, 클래스, 모듈 어디든 쓸 수 있고, 커서를 올리면 그게 무슨 역할인지 바로 확인해줘서 꽤 유용하다.

Docstring, 어떻게 쓰는 게 좋을까?

사실 일반적으로 아는 방식은 그냥 따옴표 세 개 (""")로 감싸는 것. 그렇지만 좀 더 보기 좋게 쓰고 싶은 게 사람 마음. 대표적으로 Google 스타일이 많이 쓰인다고 한다.

def add(a, b):
    """
    두 수를 더해서 반환합니다.

    Args:
        a (int): 첫 번째 숫자
        b (int): 두 번째 숫자

    Returns:
        int: 두 수의 합
    """
    return a + b

이렇게 쓰면

• a와 b가 뭔지
• 반환값이 뭔지 한 눈에 볼 수 있다.

주요 기능

• Args: 함수에 들어가는 인자(파라미터) 설명
• Returns: 함수가 뭘 반환하는지
• Raises: 함수에서 어떤 에러가 발생할 수 있는지

def divide(a, b):
    """
    두 수를 나눕니다.

    Args:
        a (float): 분자
        b (float): 분모

    Returns:
        float: 나눈 결과

    Raises:
        ValueError: 분모가 0일 때
    """
    if b == 0:
        raise ValueError("분모는 0이 될 수 없습니다.")
    return a / b

인수인계를 받으면서, 백엔드 코드는 기본적인 주석이 달려 있어서 꽤 도움이 됐었는데, 크롤링 소스코드 쪽을 받고 나서 꼼꼼히 달려 있는 Docstring 덕분에 쉽지 않은 내용을 이해하는 데 큰 도움이 됐었던 것 같은,,,

개발할 때마다 매번 Docstring까지 쓰기는 쉽지 않겠지만, 협업을 하거나 인수인계를 할 일이 있다면 Docstring이 너무 큰 도움이 될 것.

문제 상황

• 아마존 상품의 카테고리(category)를 스크래핑해서 DB에 저장하려고 함
• 스크래퍼에서 category를 잘 파싱해서 객체에 넣었고,
• Mongoose 스키마에도 category: { type: String } 필드를 추가함
• 그런데 실제 MongoDB에는 category 필드가 저장되지 않았다..
• 프론트엔드(ProductCard)에서는 category가 계속 undefined/빈 값으로 표시됨

해결 과정

스크래퍼에서 category 파싱 확인

const category = $('#wayfinding-breadcrumbs_feature_div > ul > li:nth-child(1) > span > a').text().trim();
console.log('Scraped category:', category); // 잘 찍힘

• 콘솔에 원하는 카테고리 값이 잘 찍히고 있음

DB 저장 로직 점검

• scrapedProduct에는 category가 잘 들어가고 있었다
• DB에 저장하는 코드:

  product = {
  ...scrapedProduct,
  priceHistory: updatePriceHistory,
  // ...생략...
  category: scrapedProduct.category || existingProduct?.category || ""
  }

• findOneAndUpdate:

  const newProduct = await Product.findOneAndUpdate(
  { url: scrapedProduct.url },
  { $set: product },
  { upsert: true, new: true }
  );

콘솔 로그로 값 추적

• 파일 처음부터 끝까지 category 들어가는지 질척거리며 확인
• scrapedProduct에는 값이 있는데, newProduct에는 undefined라니.

DB document 직접 확인

• MongoDB에서 document를 조회해도 category 필드가 없었다,,

마이그레이션 스크립트로 기존 상품에 category 필드 추가

• 기존 상품에는 category가 없으니, 일괄 추가:

  db.products.updateMany(
  { category: { $exists: false } },
  { $set: { category: "" } }
  )

여전히 안됨......

• 코드, DB, 스크래퍼 모두 정상인데도 category가 저장되지도 출력되지도 않음...

원인: Mongoose 모델 캐싱/서버 재시작 필요했다고 한다

• Mongoose는 최초 모델 생성 시점의 스키마를 캐싱하기 때문에
• 개발 중 스키마를 수정(필드 추가)해도, 서버를 재시작하지 않으면 새 필드가 반영되지 않는다고;
• 서버를 완전히 재시작하니 category 필드가 정상적으로 DB에 저장되고 출력되는 것을 확인할 수 있었다. (나의 소중한 시간..)

결론

• Mongoose 스키마를 수정(필드 추가/변경)했다면, 반드시 서버를 재시작하자.
• 로그 살펴보며 질척거리는 게 답인 것 같긴 하다
• 기존 데이터에는 마이그레이션이 필요한데,, MS AI School 때 마이그레이션에 여러번 당한 적이 있어서 두려워했었던 것 같음

FastAPI와 Pydantic을 사용해서 API를 만들던 중,,, 프론트엔드와의 협업을 위해 응답(JSON)은 camelCase로, 파이썬 내부에서는 snake_case로 리팩토링을 하던 중이었다. Pydantic alias_generator 기능을 활용해 BaseModel을 상속한 CamelModel을 만들어 사용.

from pydantic import BaseModel

def to_camel(string:str) -> str:
    parts = string.split('_')
    return parts[0] + ''.join(word.capitalize() for word in parts[1:])

class CamelModel(BaseModel):
    class Config:
        orm_mode = True
        allow_population_by_field_name = True
        alias_generator = to_camel

이렇게 하면 snake_case로 작성한 필드가 응답에서 자동으로 camelCase로 변환되어 나가야 하는데,,,

500 에러가...

API를 호출했더니 아래와 같은 500 Internal Server Error 발생..

pydantic_core._pydantic_core.ValidationError: 7 validation errors for SumingData
sumingField
    Field required [type=missing, input_value={'example_field': 'value', ...}, input_type=dict]
...

분명 suming_field 등 snake_case로 값을 넘겼는데, pydantic이 camelCase(sumingField) 필드를 못찾겠다고 에러를 낸다. 리팩토링 전에는 동작하던 코드라 신입의 눈물... 고친 게 이것 뿐이라 분명 camelCase랑 snake_case 사이의 문제인 건 확실한데 뭐가 문제냐고 ㅠㅠ

원인 분석

• pydantic의 alias_generator 는 출력 시에는 camelCase로 변환해주지만,
• 입력 시에는 기본적으로 snake_case로 값을 받아야 한다.
• 그런데 pydantic v2에서는 설정 방식이 바뀌어서, allow_population_by_field_name 대신 populate_by_name을 써야 하고, Config 대신 model_config를 써야 한단다.

pydantic v1과 v2의 차이

해결 방법

pydantic v1

class CamelModel(BaseModel):
    class Config:
         orm_mode = True
        allow_population_by_field_name = True
        alias_generator = to_camel

pydantic v2

class CamelModel(BaseModel):
    model_config = {
        "orm_mode": True,
        "populate_by_name": True,
        "alias_generator": to_camel,
    }

• populate_by_name=True가 있어야 snake_case로도 값을 받을 수 있다.
• alias_generator는 camelCase로 변환해서 응답에 사용한다.

결론

• pydantic에서 snake_case ↔︎ camelCase 변환하려면 alias_generator를 활용하면 된다.
• 입력도 snake_case로 받고 싶으면
  • v1: allow_population_by_field_name = True
  • v2: populate_by_name = True
• pydantic 버전에 따라 설정법이 다르니 꼭 확인하자!

삽질에서 얻은 교훈

• 공식 문서와 마이그레이션 가이드를 꼭 읽자.
• 에러 메시지를 끝까지 읽고, 필드명이 어떻게 매핑되는지 꼼꼼히 확인하자.
• 기존 코드 리팩토링은 생각보다 훠어어어얼씬 더 까다롭다. (입사 전에는 리팩토링 무조건 필요하다고 생각했는데, 왜 회사들에서 리팩토링을 잘 안한다고 하는지 알 것 같다.ㅎ)

오늘 구현한 기능들

JWT 인증 시스템

• 회원가입/로그인: 사용자 계정 관리
• JWT 토큰: 상태를 저장하지 않는 토큰 기반 인증
• 비밀번호 해싱: bcrypt로 비밀번호 저장
• 라우트: 인증이 필요한 API 엔드포인트

프로젝트 구조 변경

Before

todo_api/
├── main.py        # 모든 API가 한 파일에
├── database.py
├── models.py
└── schemas.py

After

todo_api/
├── main.py        # 앱 설정만
├── database.py
├── models.py      # User 모델 추가
├── schemas.py     # User, Token 스키마 추가
├── auth.py        # JWT 관련 로직
├── dependencies.py # 의존성 주입
└── routers/
    ├── auth.py    # 인증 관련 API
    └── todos.py   # 할일 관련 API

학습 내용

JWT의 동작 원리

전통적인 세션 방식 vs jWT

# 세션 방식 (서버에 상태 저장)
login → 서버가 세션 ID 생성 → 메모리/DB에 저장 → 쿠키로 전달

# JWT 방식 (상태를 저장하지 않음)
login → 서버가 JWT 토큰 생성 → 클라이언트가 저장 → 매 요청마다 헤더에 포함

JWT 토큰 구조

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyIiwiZXhwIjoxNjM5...
헤더.페이로드.서명

FastAPI 의존성 주입

Java Spring과 비교

# FastAPI
@app.get("/todos")
def get_todos(current_user = Depends(get_current_user)):
    return current_user.todos

// Java Spring
@GetMapping("/todos")
public List<Todo> getTodos(@AuthenticationPrincipal User user) {
    return user.getTodos();
}

의존성 체인

get_current_user → oauth2_scheme → token 검증 → DB 조회 → User 객체 반환

데이터베이스 관계 모델링

# User : Todo = 1 : N 관계
class User(Base):
    todos = relationship("Todo", back_populates="owner")

class Todo(Base):
    owner_id = Column(Integer, ForeignKey("users.id"))
    owner = relationship("User", back_populates="todos")

마주친 문제들과 해결 과정

순환 Import 문제

문제: main.py ↔︎ routers 간 순환 참조

어제 router 설정하기 전에 get_db 함수를 main.py 안에 뒀었는데, 라우터를 오늘 설정하면서 순환 참조 문제가 발생했다.

# main.py에서 routers import
from routers import auth, todos

# routers에서 main.py의 get_db import
from main import get_db  # ❌ 순환 import

해결: 공통 모듈로 분리

# database.py로 get_db 이동
def get_db():
    db = SessionLocal()
    try:
        yield db
    finally:
        db.close()

SQLAlchemy 관계 설정 에러

예러 메시지

Mapper 'Todo' has no property 'user'

원인: back_populates 불일치

# ❌ 잘못된 설정
class User(Base):
    todos = relationship("Todo", back_populates="user")  # "user"

class Todo(Base):
    user = relationship("User", back_populates="todos")  # 실제 속성명

해결: 의미적으로 명확한 관계명 사용

back_populates의 역할을 잘 몰라서 발생한 오류. 다른 클래스에서 해당 관계를 반영하는 속성의 이름을 정확하게 적어줘야 한다.

# ✅ 올바른 설정
class User(Base):
    todos = relationship("Todo", back_populates="owner")

class Todo(Base):
    owner = relationship("User", back_populates="todos")

JWT 토큰 생성 실패

문제: access_token이 None으로 반환

찾아도 찾아도 안찾아져서 고생을 깨나했는데... 들여쓰기 문제였다.. 지옥의 Python 다시 만났다, 들여쓰기 문제.

# ❌ 들여쓰기 문제
def create_access_token(data: dict, expires_delta: Optional[timedelta] = None):
    if expires_delta:
        expire = datetime.utcnow() + expires_delta
    else:
        expire = datetime.utcnow() + timedelta(minutes=30)
        to_encode.update({"exp": expire})  # else 블록에만 있음!

해결: 들여쓰기

# ✅ 수정된 버전
def create_access_token(data: dict, expires_delta: Optional[timedelta] = None):
    to_encode = data.copy()

    if expires_delta:
        expire = datetime.utcnow() + expires_delta
    else:
        expire = datetime.utcnow() + timedelta(minutes=30)

    to_encode.update({"exp": expire})  # 항상 실행
    return jwt.encode(to_encode, SECRET_KEY, algorithm=ALGORITHM)

Swagger UI 인증 경로 문제

문제: "Auth Error: Not Found"

# dependencies.py
oauth2_scheme = OAuth2PasswordBearer(tokenUrl="login")  # ❌ 잘못된 경로

실제 엔드포인트: /auth/login Swagger 요청에 사용한 경로: /login

해결:

oauth2_scheme = OAuth2PasswordBearer(tokenUrl="auth/login")  # ✅ 올바른 경로

인증 시스템 비교: Java JWT vs Django vs FastAPI

이전에 Java JWT와 Django 인증 시스템을 사용해본 작은 경험으로 비교해보기.

설정 복잡도

Java Spring Security + JWT

// SecurityConfig.java
@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public JwtAuthenticationEntryPoint jwtAuthenticationEntryPoint() {
        return new JwtAuthenticationEntryPoint();
    }

    @Bean
    public JwtRequestFilter jwtRequestFilter() {
        return new JwtRequestFilter();
    }

    @Bean
    public PasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }

    @Override
    protected void configure(HttpSecurity httpSecurity) throws Exception {
        httpSecurity.csrf().disable()
            .authorizeRequests()
            .antMatchers("/auth/**").permitAll()
            .anyRequest().authenticated()
            .and()
            .exceptionHandling().authenticationEntryPoint(jwtAuthenticationEntryPoint)
            .and()
            .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS);

        httpSecurity.addFilterBefore(jwtRequestFilter, UsernamePasswordAuthenticationFilter.class);
    }
}

// JwtUtil.java (별도 유틸리티 클래스 필요)
@Component
public class JwtUtil {
    private String secret = "secret";

    public String generateToken(UserDetails userDetails) {
        Map<String, Object> claims = new HashMap<>();
        return createToken(claims, userDetails.getUsername());
    }
    // ... 더 많은 보일러플레이트 코드
}

Django REST Framework

# settings.py
INSTALLED_APPS = [
    'rest_framework',
    'rest_framework.authtoken',  # 또는 rest_framework_simplejwt
]

REST_FRAMEWORK = {
    'DEFAULT_AUTHENTICATION_CLASSES': [
        'rest_framework_simplejwt.authentication.JWTAuthentication',
    ],
    'DEFAULT_PERMISSION_CLASSES': [
        'rest_framework.permissions.IsAuthenticated',
    ],
}

# urls.py
from rest_framework_simplejwt.views import TokenObtainPairView

urlpatterns = [
    path('api/token/', TokenObtainPairView.as_view()),
]

# views.py
from rest_framework.decorators import api_view, permission_classes
from rest_framework.permissions import IsAuthenticated

@api_view(['GET'])
@permission_classes([IsAuthenticated])
def protected_view(request):
    return Response({'user': request.user.username})

FastAPI

# auth.py (핵심 로직만)
SECRET_KEY = "secret"
ALGORITHM = "HS256"

def create_access_token(data: dict):
    to_encode = data.copy()
    expire = datetime.utcnow() + timedelta(minutes=30)
    to_encode.update({"exp": expire})
    return jwt.encode(to_encode, SECRET_KEY, algorithm=ALGORITHM)

# dependencies.py
oauth2_scheme = OAuth2PasswordBearer(tokenUrl="auth/login")

async def get_current_user(token: str = Depends(oauth2_scheme)):
    # 간단한 의존성 주입
    return verify_and_get_user(token)

# main.py
@app.get("/protected")
def protected_route(user = Depends(get_current_user)):
    return {"user": user.username}

코드 가독성 및 유지보수성

인증 플로우

Java Spring Security

클라이언트 → SecurityFilterChain → JwtRequestFilter → UserDetailsService → Controller

• 장점: 매우 안전하고 검증된 패턴
• 단점: 설정이 복잡하고 러닝 커브 높음

Django

클라이언트 → Middleware → Authentication Class → Permission Class → View

• 장점: 배터리 포함, ORM과 완벽 통합
• 단점: 무겁고, API 전용으로는 오버엔지니어링

FastAPI 플로우

클라이언트 → OAuth2Scheme → Dependencies → Route Function

• 장점: 간단하고 직관적, 성능 우수
• 단점: 굳이 꼽자면,, 상대적으로 새로운 생태계라는 점이려나

실제 개발 경험 비교

개발 속도

FastAPI > Django > Java Spring

Java Spring Security

• ✅ 엔터프라이즈급 보안 기능
• ✅ 풍부한 생태계와 문서
• ❌ 설정 지옥, 높은 러닝 커브
• ❌ 보일러플레이트 코드 과다

Django + DRF

• ✅ 관리자 패널, ORM 등 풍부한 기능
• ✅ 검증된 보안 패턴
• ✅ 풍부한 써드파티 패키지
• ❌ 무거운 프레임워크
• ❌ API 전용 서비스에는 과도한 기능

FastAPI

• ✅ 빠른 개발 속도
• ✅ 자동 문서화
• ✅ 현대적인 Python 기능 활용
• ✅ 높은 성능
• ❌ 상대적으로 적은 레퍼런스
• ❌ 일부 고급 기능은 직접 구현 필요

프로젝트 개요

목표: FastAPI 기본 개념 익히기 기간: 하루 기능: 할일 CRUD(생성, 조회, 수정, 삭제)

사용한 기술 스택

• FastAPI: 메인 웹 프레임워크
• SQLAlchemy: ORM(데이터베이스 연동)
• Pydantic: 데이터 검증 및 직렬화
• SQLite: 데이터베이스(개발용)
• PyCharm Professional: 개발 환경

프로젝트 구조

todo_api/
├── main.py        # 메인 애플리케이션
├── database.py    # 데이터베이스 설정
├── models.py      # SQLAlchemy 모델
├── schemas.py     # Pydantic 스키마
└── requirements.txt

간단한 구조지만 실제 실무에서도 많이 사용하는 패턴이라고 한다.

학습 내용

FastAPI 기본 구조

from fastapi import FastAPI

app = FastAPI(title="할일 관리 API", version="1.0.0")

@app.get("/")
def read_root():
    return {"message": "Hello FastAPI!"}

Flask보다도 직관적이게 느껴지는 건,, 그 때보다 내가 조금은 성장했기 때문이려나? 아니면 실제 직관적인가.

자동 API 문서화

FastAPI에서 가장 인상 깊었던 기능은 자동 API 문서 생성이었다. 코드만 작성하면 http://localhost:8000/docs에서 바로 Swagger UI를 만들어줌;; Java에서 Swagger 설정하던 눈물의 시간들이 떠오른다..

타입 힌팅의 중요성

@app.get("/todos/{todo_id}", response_model=schemas.Todo)
def get_todo(todo_id: int, db: Session = Depends(get_db)):
    # ...

타입 힌팅을 제대로 해주면:

• 자동완성이 훨씬 정확해지고
• 런타임 에러를 미리 잡을 수 있으며
• API 문서에 타입 정보가 자동으로 표시된다고 한다.

Pydantic 데이터 검증

class TodoCreate(BaseModel):
    title: str
    description: Optional[str] = None

요청 데이터가 자동으로 검증되고, 잘못된 데이터가 오면 명확한 에러 메시지를 보여준다.

마주친 문제와 해결과정

Java 개발자가 겪는 Python 타입 차이

딱 하나 마주한 에러.

PydanticSchemaGenerationError: Unable to generate pydantic-core schema for <class 'sqlalchemy.sql.sqltypes.Boolean'>

문제: Java에서는 Boolean이 자연스러워서 그대로 사용 해결: Python에서는 소문자 bool을 사용

# ❌ Java 스타일로 작성
class Todo(BaseModel):
    completed: Boolean  # Java처럼 대문자

# ✅ Python 스타일로 수정
class Todo(BaseModel):
    completed: bool  # Python은 소문자

Java에서는 Boolean, String, Integer 같은 래퍼 클래스를 사용하지만, Python에서는 bool, str, int 같은 기본 타입을 사용한다는 것을 다시 한번 상기하며,,,

PyCharm

몇 년 전에 처음 Python 쓸 때는 VS Code가 훨씬 편했던 것 같은데, Professional 버전이라 그런가 아니면 IntelliJ에 익숙해져서 그런가 PyCharm이 이제는 꽤나 만족스럽다.

구현한 주요 기능들

할일 CRUD API

• GET /todos - 모든 할일 조회
• GET /todos/{id} - 특정 할일 조회
• POST /todos - 새 할일 생성
• PUT /todos/{id}/complete - 할일 완료 처리
• DELETE /todos/{id} - 할일 삭제

의존성 주입

Python FastAPI

def get_db():
    db = SessionLocal()
    try:
        yield db
    finally:
        db.close()

@app.get("/todos")
def get_todos(db: Session = Depends(get_db)):
    # db는 자동으로 주입됨
    return db.query(Todo).all()

; 없이 들여쓰기로만 구분하는 파이썬 문법에 오랜만에 어색함을 느끼며,,

Java Spring

@Service
public class TodoService {
    @Autowired
    private SessionFactory sessionFactory;

    public List<Todo> getTodos() {
        Session session = sessionFactory.getCurrentSession();
        return session.createQuery("FROM Todo", Todo.class).list();
    }
}

@RestController
public class TodoController {
    @Autowired
    private TodoService todoService;    // 의존성 주입

    @GetMapping("/todos")
    public List<Todo> getTodos() {
        return todoService.getTodos();
    }
}

이렇게 보니까 자바가 진짜 복잡하다는 게 새삼..

주요 차이점

FastAPI의 Depends()는 Spring의 @Autowired와 같은 역할을 한다. yield를 사용한 리소스 관리가 Python 답게 깔끔하다.

에러 처리

Python FastAPI

from fastapi import HTTPException

@app.get("/todos/{todo_id}")
def get_todo(todo_id: int):
    todo = db.query(Todo).filter(Todo.id == todo_id).first()
    if todo is None:
        raise HTTPException(status_code=404, detail="할일을 찾을 수 없습니다.")
    return todo

Java Spring

@RestController
public class TodoController {

    @GetMapping("/todos/{id}")
    public ResponseEntity<Todo> getTodo(@PathVariable Long id) {
        Todo todo = todoService.findById(id);
        if (todo == null) {
            return ResponseEntity.notFound().build();
        }
        return ResponseEntity.ok(todo);
    }

    // 또는 Exception Handler 사용
    @ExceptionHandler(TodoNotFoundException.class)
    public ResponsEntity<ErrorResponse> handleNotFound(TodoNotFoundException ex) {
        return ResponseEntity.status(404)
            .body(new ErrorResponse("할일을 찾을 수 없습니다."));
    }
}

주요 차이점

FastAPI에서는 Python 예외 처리 방식을 그대로 활용해서 raise HTTPException으로 간단하게 에러를 던질 수 있어서 직관적이었다.

FastAPI의 장점

일단 내가 오늘 경험한 장점으로는

• 문법이 직관적이고 (이것은 FastAPI의 장점인지, Python의 장점인지, 둘다인지 모르겠으나),
• 자동 API 문서화, 이거 너무 좋다.

다음 단계

오늘은 다시 Python 감을 찾느라고 기본 CRUD만 구현해봤는데,

• 사용자 인증 (JWT)
• 권한 관리
• 페이지네이션
• 검색 및 필터링
• 테스트 코드 작성
• Docker 컨테이너화

까지 차근차근 입사 전까지 공부해보면 좋겠다. 조금 더 여유가 된다면 웹크롤링까지!

마무리

오랜만에 Python 다시 만져봤는데 너무 재밌다. 잠 안 자고 더 하고 싶은 마음이 들지만,, 컨디션을 관리해야 하므로.

입사하면 실제로 FastAPI를 쓰게 될텐데, 벌써 새로운 공부들이 기대된다 히히 😛

핵심 서비스

• 1:1 전문가 상담
• 금융 카드뉴스
• 금융 챌린지
• 개인화된 대시보드

ERD 구조

📈 머니버디 ERD 구조
├── 👤 사용자 관리
│   ├── users (사용자)
│   ├── user_settings (사용자 설정)
│   ├── user_favorites (즐겨찾기)
│   ├── user_points (포인트)
│   └── user_activity_logs (활동 로그)
├── 👨‍💼 전문가 관리
│   ├── experts (전문가)
│   └── expert_specializations (전문분야)
├── 💬 상담 시스템
│   ├── consultations (상담)
│   ├── reviews (리뷰)
│   ├── chat_rooms (채팅방)
│   └── chat_messages (채팅 메시지)
├── 📰 컨텐츠 관리
│   ├── card_news (카드뉴스)
│   ├── card_news_likes (좋아요)
│   ├── daily_contents (오늘의 컨텐츠)
│   └── banners (배너)
├── 🏆 챌린지 시스템
│   ├── challenges (챌린지)
│   ├── challenge_participants (참여자)
│   └── challenge_records (기록)
└── 🔔 지원 시스템
    ├── notifications (알림)
    └── faq (FAQ)

엔티티 상세

Users

• 회원가입 시 일반 사용자/전문가 선택 가능
• is_active 플래그로 탈퇴 사용자 관리

Experts

• 관리자가 전문가 자격을 검증 후 승인
• 리뷰 기반 실시간 평점 계산
• 전문가별 차별화된 상담료 설정

Consultations

1. 요청 → 2. 승인 → 3. 진행중 → 4. 완료
                ↓
             취소 (언제든 가능)

그외

• 챌린지 시스템
• 카드뉴스 & 컨텐츠 시스템

API 설계

🌐 API 엔드포인트 구조
├── /api/auth/* (인증)
├── /api/experts/* (전문가)
├── /api/consultations/* (상담)
├── /api/chat/* (채팅)
├── /api/reviews/* (리뷰)
├── /api/card-news/* (카드뉴스)
├── /api/challenges/* (챌린지)
├── /api/daily-contents/* (오늘의 컨텐츠)
├── /api/banners/* (배너)
├── /api/favorites/* (즐겨찾기)
├── /api/notifications/* (알림)
├── /api/users/* (사용자)
├── /api/faq/* (FAQ)
├── /api/admin/* (관리자)
└── /api/analytics/* (분석)

API 상세

사용자 인증 API

// 회원가입 - 일반 사용자
POST /api/auth/register
{
  "email": "suming@example.com",
  "password": "password123",
  "name": "수밍킴",
  "user_type": "USER"
}

// 회원가입 - 전문가 (확장된 정보)
POST /api/auth/register
{
  "email": "jhpark@example.com",
  "password": "password123", 
  "name": "박재현",
  "user_type": "EXPERT",
  "expert_info": {
    "specialization": "투자 전문가",
    "experience_years": 10,
    "certification": "투자상담사, 재무설계사",
    "hourly_rate": 30000,
    "specializations": [
      {"category": "주식", "sub_category": "ETF"},
      {"category": "부동산", "sub_category": "부동산투자"}
    ]
  }
}

전문가 검색 & 필터링 API

// 전문가 목록 조회 (고급 필터링)
GET /api/experts?category=주식&rating_min=4.0&sort=rating&page=1&size=10

// 응답 예시
{
  "success": true,
  "data": {
    "experts": [
      {
        "expert_id": 1,
        "name": "박재현",
        "specialization": "투자 전문가",
        "rating": 4.8,
        "total_consultations": 150,
        "hourly_rate": 30000,
        "profile_image_url": "https://...",
        "specializations": ["주식", "부동산"],
        "is_favorited": false
      }
    ],
    "pagination": {
      "current_page": 1,
      "total_pages": 5,
      "total_count": 47,
      "has_next": true
    }
  }
}

챌린지 참여 API

// 챌린지 참여
POST /api/challenges/1/join
// 응답: 참여 성공 메시지

// 챌린지 기록 등록
POST /api/challenges/1/record
{
  "amount": 5000,
  "memo": "매일 5천원 씩 소수점 투자 챌린지",
  "proof_image_url": "https://...",
  "record_date": "2025-05-22"
}

// 내 챌린지 진행 현황
GET /api/challenges/my-participations
{
  "success": true,
  "data": {
    "participations": [
      {
        "challenge_title": "주린이 주식 입문 스터디 모임",
        "current_amount": 45000,
        "goal_amount": 100000,
        "progress_percentage": 45.0,
        "status": "진행중",
        "days_left": 15,
        "ranking": 23
      }
    ]
  }
}

실시간 채팅 API

// WebSocket 연결
ws://api.moneybuddy.com/ws/chat/{consultation_id}

// 메시지 전송
{
  "type": "message",
  "content": "안녕하세요",
  "message_type": "text"
}

// 메시지 수신
{
  "message_id": 123,
  "sender_id": 1,
  "sender_name": "수밍킴",
  "content": "안녕하세요",
  "message_type": "text",
  "created_at": "2025-05-22T21:06:00Z",
  "is_read": false
}

// 읽음 상태 업데이트
{
  "type": "read",
  "message_ids": [123, 124, 125]
}

개발 로드맵

핵심 MVP (2주차)

• 사용자 인증 시스템
• 전문가 조회 및 필터링
• 기본 상담 신청/관리
• 카드뉴스 기본 기능
• 오늘의 컨텐츠 시스템

주요 기능 (3주차)

• 실시간 채팅 시스템
• 전문가 승인 프로세스
• 챌린지 참여/기록 시스템
• 즐겨찾기 기능
• 기본 알림 시스템

고도화 (4주차)

• 프로필 관리 고도화
• 리뷰 시스템 구축
• 카드뉴스 작성/관리
• 챌린지 생성/관리
• 배너 시스템

완성도 향상 (5주차)

• 결제 시스템 연동
• 포인트 시스템 구축
• FAQ 시스템
• 고도화된 알림
• 관리자 대시보드
• 사용자 분석 시스템

발표 준비 (6주차)

두 가지 타입 변환 방식

1. 암시적 변환 (Implicit Conversion)
   • JS 엔진이 자동으로 타입을 변환
   • 일명 *"타입 강제 변환"* 또는 *"형 변환(coercion)"*
2. 명시적 변환 (Explicit Conversion)
   • 개발자가 직접 코드로 타입을 바꿈
   • String(), Number(), Boolean() 같은 함수 사용

암시적 타입 변환

자바스크립트는 표현식의 문맥에 따라 값을 자동으로 변환한다. 가장 흔한 예는 연산자(+, ==, 조건문 등)에서 발생한다.

숫자 ↔ 문자열

'5' + 1 // "51" → 문자열로 변환됨
'5' - 1 // 4 → 숫자로 변환됨
'5' * '2' // 10 → 숫자로 변환됨

• + 연산자는 하나라도 문자열이면 전체를 문자열로 변환
• 나머지 연산자(-, *, /)는 모두 숫자 변환을 시도

불리언 ↔ 다른 타입

!!"hello" // true
!!0 // false
!! undefined // false

Falsy 값 (Boolean으로 변환 시 false가 되는 값):

느슨한 비교 (==) 시의 암시적 변환

'5' == 5 // true (문자열 → 숫자 변환)
false == 0 // true
null == undefined // true
[] == '' // true
[] == 0 // true
[1] == 1 // true

혼란스럽기 때문에 실제 개발에서는 항상 === 사용 권장!

명시적 타입 반환

명시적 타입 변환은 개발자가 의도적으로 타입을 바꾸는 것이다.

문자열 변환

String(123) // "123"
(123).toString() // "123"

숫자 변환

Number("42") // 42
parseInt("42px") // 42
parseFloat("3.14") // 3.14
+true // 1
+"123.45" // 123.45

불리언 변환

Boolean(0) // false
Boolean("hello") // true

!!값 패턴도 많이 사용된다: !!"hello" → true

특별한 경우들

실전 팁

• 숫자 변환엔 Number(), 문자열 변환엔 String() 또는 .toString(), 불리언은 !! 또는 Boolean()
• 비교에는 항상 ===(엄격한 동등) 사용 → 예기치 않은 암시적 변환 방지
• undefined와 null 비교는 조심 (예: undefined == null은 true, ===은 false)

자바스크립트에서 문자열, 숫자, 불리언 같은 원시 값(primitive value)도 객체처럼 메서드나 속성을 사용할 수 있는데, 그게 가능한 이유는 자바스크립트 엔진이 일시적으로 원시 값을 래퍼 객체로 변환하기 때문이다. 이때 생성되는 객체가 바로 래퍼 객체이다.

작동 방식: "박싱(Boxing)"과 "언박싱(Unboxing)"

예시:

let str = "hello";
console.log(str.toUpperCase()); // "HELLO"

이 코드의 실제 내부 흐름:

1. str.toUpperCase()를 호출하면,
2. JS 엔진이 "hello"를 new String("hello")로 자동 박싱함
3. 해당 래퍼 객체의 메서드 .toUpperCase()가 호출됨
4. 결과 반환 후, 래퍼 객체는 즉시 폐기됨 (가비지 컬렉션 대상)

자바스크립트의 3가지 기본 래퍼 객체

잘못된 예시: (권장 X)

let x = new String("hello");
console.log(typeof x); // "object" ← 이제 더 이상 원시 타입 아님!

이렇게 만들면 비교 연산이나 타입 체크에서 예상치 못한 결과가 발생할 수 있다.

let a = "hello";
let b = new String("hello");

console.log(a === b); // false ← 타입 다름

일반적으로는 자동 변환만 믿고 쓰자

원시 값이 메서드나 속성을 호출하면 엔진이 자동으로 래퍼 객체를 생성해서 처리하므로, 개발자가 명시적으로 래퍼 객체를 생성할 일은 거의 없다.

console.log("abc".length); // 3 ← 자동으로 String 객체로 래핑됨

Java와 비교

요약

정의

"값이 할당되지 않은 상태"를 나타낸다. 자바스크립트 엔진이 자동으로 부여하는 값이다.

주로 발생하는 상황

변수 선언만 했을 때

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

함수에서 return을 생략했을 때

function doSomething() {}
console.log(doSomething()); // undefined

객체에서 존재하지 않는 속성을 접근할 때

let user = { name: "Alice" };
console.log(user.age); // undefined

배열에서 비어 있는 인덱스를 접근할 때

let arr = [1, , 3];
console.log(arr[1]); // undefined

매개변수가 전달되지 않았을 때

function greet(name) {
  console.log(name);
}
greet(); // undefined

typeof 결과

typeof undefined; // 'undefined'

null

정의

"명시적으로 값이 없음"을 나타낸다. 즉, 프로그래머가 의도적으로 "비어 있음"을 표현할 때 사용한다.

주로 사용하는 상황

초기값으로 명시적인 빈 상태 설정

let currentUser = null;

의도적으로 참조를 끊을 때

someElement = null; // GC 대상이 되도록

객체를 나중에 채울 예정임을 표현

let config = null; // 나중에 설정

typeof 결과

typeof null; // 'object' ← JS 초기 설계 실수

undefined vs. null 비교

사용 시 주의사항

• undefined는 암묵적이며 엔진이 부여하는 값이므로, 직접 할당하는 건 권장되지 않는다.

  let x = undefined; // ❌ 권장 X
  let x = null; // ✅ 명시적 빈 값

• 비교 시 느슨한 동등 (==) 비교는 혼란을 유발할 수 있다:

  null == undefined // true
  null === undefined // false

  → 실제 개발에서는 항상 ===을 사용하는 것이 좋다 (엄격한 비교).

요약

참조 타입은 값 자체가 아닌 메모리 주소(참조)를 통해 데이터를 다루는 타입이다. 객체, 배열, 함수 등 복잡한 구조의 데이터가 여기에 속한다.

자바스크립트의 주요 참조 타입

참조 타입의 특징

메모리 참조를 저장

변수에는 실제 값이 아닌 객체가 저장된 메모리 주소(참조)가 저장된다.

let obj1 = { name: "Alice" };
let obj2 = obj1;

ob2.name = "Bob";

console.log(obj1.name); // "Bob"

→ obj1과 obj2는 같은 객체를 가리키고 있기 때문에, 하나를 수정하면 다른 쪽에도 영향을 미친다.

얕은 복사 vs. 깊은 복사

• 얕은 복사 (Shallow Copy): 참조만 복사됨 → 원본 변경 시 영향 받음
• 깊은 복사 (Deep Copy): 값 자체를 완전히 복제 → 원본과 독립적

  // 얕은 복사
  let original = { a: 1 };
  let copy = original;
  copy.a = 2;
  

console.log(original.a); // 2

// 깊은 복사 let deepCopy = JSON.parse(JSON.stringify(original)); deepCopy.a = 100;

console.log(original.a); // 2 console.log(deepCopy.a); // 100

---
#### typeof 결과는 대부분 'object'
``` js
typeof {}; // "object"
typeof []; // "object"
typeof function(){} // "function" ← 특별 처리됨
typeof null; // "object" ← 버그로 인해 이 결과가 나옴

null이 object로 나오는 건 오래된 JS 설계 실수지만, 지금도 그대로 유지되고 있다.

속성 및 메서드 사용 가능

참조 타입은 속성(property)과 메서드(method)를 가질 수 있다:

let user = {
  name: "Jane",
  greet: function() {
    console.log("Hello!");
  }
};

console.log(user.name); // "Jane"
user.greet(); // "Hello!"

함수도 참조 타입

자바스크립트에서는 함수도 일급 객체(First-class object)로 취급되며 참조 타입이다:

function greet() {
  return "Hello";
}

let fn = greet;
console.log(fn()); // "Hello"

원시 타입과 참조 타입 비교

요약

• 참조 타입은 값이 아닌 주소(참조)를 저장
• 같은 객체를 참조하는 변수는 서로 영향을 줌
• 객체, 배열, 함수 등이 이에 해당
• 복사할 땐 얕은/깊은 복사 구분 필요
• typeof 결과 대부분 "object"

원시 값은 더 이상 나눌 수 없는, 기본적인 데이터 단위이다. 값 자체가 변수에 저장되며, immutable (불변)하다. 즉, 한 번 만들어진 원시 값은 변경될 수 없다.

자바스크립트의 원시 타입 종류

자바스크립트에는 총 7가지 원시 타입이 있다:

특징 정리

불변성 (Immutability)

let str = 'hello';
str[0] = 'H'; // 시도는 가능하지만 실제 값은 변하지 않음
console.log(str); // 'hello'

문자열을 바꾸는 것처럼 보여도, 실제로는 새로운 문자열이 생성된다.

값 복사 (값 전달)

원시 값은 값 자체가 복사되기 때문에, 다른 변수에 할당해도 원본은 영향받지 않는다.

let a = 10;
let b = a;
b = 20;
console.log(a); // 10

a와 b는 서로 완전히 독립적인 값이다.

타입 확인

typeof 연산자를 사용하여 원시 타입을 확인할 수 있다:

typeof 'hello';    // 'string'
typeof 42;         // 'number'
typeof true;       // 'boolean'
typeof undefined;  // 'undefined'
typeof null;       // 'object' ← 이건 JS 언어 설계상의 오래된 실수
typeof Symbol();   // 'symbol'
typeof 123n;       // 'bigint'

원시 값과 객체의 차이

예시: 문자열은 원시 타입인데 메서드를 쓸 수 있는 이유?

let name = "John";
console.log(name.toUpperCase()); // "JOHN"

• 문자열은 원시 타입이지만, 메서드를 호출하면 자바스크립트 엔진이 내부적으로 String 객체로 일시적으로 래핑(wrapping)한다.
• 이걸 "박싱(Boxing)"이라고 부른다.
• 이후 메서드 실행이 끝나면 다시 원시 값으로 돌아간다.

요약

원시 타입 (Primitive Types)

자바스크립트의 기본 데이터 타입은 다음과 같다:

참조 타입 (Reference Types)

• 객체(Object)
• 배열(Array)
• 함수(Function)
• 날짜(Date) 등등

  let obj = { name: 'John' };
  let arr = [1, 2, 3];
  let fn = function() { return 'Hello'; };

동적 타입 지정

변수는 어떤 타입이든 가질 수 있으며, 재할당을 통해 타입이 바뀔 수 있다:

let x = 10; // number
x = 'hello'; // 이제 string
x = true; // 이제 boolean

암시적 타입 변환 (Type Coercion)

자바스크립트는 상황에 따라 자동으로 타입을 변환한다:

'5' + 1 // '51' (문자열로 변환)
'5' - 1 // 4 (숫자로 변환)
true + 1 // 2 (true → 1)
false + '1' // 'false1'

이런 특징 때문에 버그 발생 가능성이 높고, 유지보수 시 주의가 필요하다.

타입 검사 방법

런타임에 타입을 확인하려면 typeof 연산자를 사용한다:

typeof 42 // 'number'
typeof 'hello' // 'string'
typeof null // 'object' ← 이건 자바스크립트의 오래된 버그
type of [] // 'object'
type of {} // 'object'
typeof function(){} // 'function'

엄격한 타입을 원한다면? → TypeScript

자바스크립트의 유연하지만 위험한 타입 시스템을 보완하기 위해 TypeScript가 등장했다. TypeScript는 정적 타입 검사, 인터페이스, 제네릭 등을 제공해 대규모 애플리케이션 개발에 더 적합하다.

요약

"use strict"란?

"use strict"는 자바스크립트에서 Strict Mode(엄격 모드)를 활성화하는 지시문이다. 이 모드를 사용하면 보다 안전하고 예측 가능한 코드 실행이 보장된다.

"use strict"; // 이 줄 이후부터 엄격 모드 적용

let x = 3.14;

문법

• 문자열 "use strict" 또는 'use strict'로 명시
• 스크립트 또는 함수의 첫 줄에 위치해야 작동함

왜 사용하는가?

자바스크립트는 초기 설계 시 유연함과 관용성(forgiveness)을 강조했기 때문에, 실수를 해도 경고 없이 넘어가는 경우가 많다. Strict Mode는 이런 관용적인 동작을 제한하고 오류를 강제로 발생시켜 개발자가 문제를 빨리 인지하도록 도와준다.

엄격 모드의 주요 특징

암시적 전역 변수 금지

"use strict";
x = 10; // ❌ ReferenceError: x is not defined

→ 선언하지 않은 변수는 자동으로 var로 처리되지 않고 에러 발생.

읽기 전용 속성 변경 금지

"use strict";
const obj = {};
Object.defineProperty(obj, "x", { value: 42, writable: false });

obj.x = 9; // ❌ TypeError: Cannot assign to read only property

중복된 매개변수 이름 허용 안 함

"use strict";
function sum(a, a, b) { // ❌ SyntaxError
  return a + b;
}

this가 undefined로 유지됨 (전역 객체 바인딩 금지)

"use strict";
function f() {
  console.log(this); // ✅ undefined
}
f();

→ 엄격 모드에서는 this가 자동으로 window(또는 global 객체)로 바인딩되지 않음.

삭제 불가능한 값 삭제 시 에러 발생

"use strict";
delete Object.prototype; // ❌ TypeError

예약어 사용 제한

아직 사용되지 않았지만 미래에 사용할 가능성이 있는 키워드는 사용할 수 없습니다.

"use strict";
let public = 1; // ❌ SyntaxError

어디에 쓰나?

파일 전체에 적용

"use strict";

function doSomething() {
  // strict mode 적용됨
}

특정 함수에만 적용

function processData() {
  "use strict";
  // 이 함수 내부만 strict mode 적용
}

사용 시 주의사항

• 최상단에 선언해야 함 (주석보다 먼저 위치하는 것이 안전)
• 라이브러리와 혼합 시 부분 적용 권장 (함수 단위로)

ES6 이후의 맥락

ES6부터는 모듈(.mjs)이나 클래스 내 코드는 자동으로 strict mode가 적용된다. 즉, 명시적으로 쓰지 않아도 엄격 모드가 기본이라는 점도 기억해두자!

정리

리터럴(literal)은 고정된 값 자체를 의미한다. 즉, 변수나 계산이 아닌 코드에 직접 작성된 값을 말한다.

let num = 10; // 숫자 리터럴 10
let str = "hello"; // 문자열 리터럴 "hello"
let flag = true; // 불리언 리터럴 true

위 예시에서 10, "hello", true는 모두 리터럴이다.

자바스크립트의 주요 리터럴 종류

숫자 리터럴 (Number Literal)

let a = 42; // 정수
let b = 3.14; // 실수
let c = 0b1010; // 2진수 (0b 또는 0B)
let d = 0o755; // 8진수 (0o 또는 0O)
let e = 0xFF; // 16진수 (0x 또는 0X)

문자열 리터럴 (String Literal)

let s1 = "hello";
let s2 = 'world';
let s3 = `template ${s1}`; // 템플릿 리터럴 (백틱 사용)

• 큰 따옴표 ", 작은 따옴표 ', 백틱 ̀ 모두 문자열 정의 가능
• 템플릿 리터럴은 문자열 내 변수 삽입 및 줄바꿈 가능

불리언 리터럴 (Boolean Literal)

let isActive = true;
let isComplete = false;

null 리터럴

let empty = null;

• "값이 없음" 또는 "의도적으로 비워둠"을 의미

undefined 리터럴

let notSet; // 선언만 하고 초기화하지 않으면 undefined

• 직접 쓰는 경우는 드물고, 자바스크립트가 자동으로 부여하는 값

객체 리터럴 (Object Literal)

let person = {
  name: "Alice",
  age: 30
};

• 중괄호 {}를 사용해 키-값 쌍으로 구성

배열 리터럴 (Array Literal)

let list = [1, 2, 3, 4];

• 대괄호 []를 사용해 값의 순서대로 나열

정규표현식 리터럴 (RegExp Literal)

let regex = /ab+c/i;

• /패턴/플래그 형식

심볼 리터럴 (Symbol Literal)

let sym = Symbol("id");

• 고유하고 변경 불가능한 식별자 생성

리터럴 vs. 표현식

즉, 리터럴은 평가할 필요가 없는 값, 표현식은 평가하면 결과가 나오는 코드이다.

정리

식별자란?

식별자(identifier)는 변수, 함수, 클래스, 매개변수 등 프로그래밍 요소를 식별하기 위한 이름이다.

let name = "John";
function sayHello() {
  console.log("Hello!");
}

위 코드에서 name과 sayHello는 모두 식별자이다.

식별자 작성 규칙 (ECMAScript 표준 기반)

자바스크립트 식별자는 다음과 같은 규칙을 따라야 한다:

시작 문자

• 문자(a-z, A-Z)
• 밑줄 _
• 달러 기호 $

✅ 가능한 예

let userName;
let _tempValue;
let $dollarSign;

❌ 잘못된 예

let 1stUser; // 숫자로 시작할 수 없음
let @price; // 특수문자 사용 불가

이후 문자

• 문자, 숫자, _, $ 사용 가능
• 숫자 사용은 가능하지만, 첫 글자로는 올 수 없음

유니코드 지원

ES6부터 유니코드 문자를 허용하므로 한글, 이모지 등도 식별자 이름으로 사용 가능은 하지만 권장되지 않는다 (유지보수 어려움).

let 이름 = "홍길동"; // 가능은 하지만 권장하지 않음
let 💻 = "컴퓨터"; // 가능하지만 실무에서는 피해야 함

식별자와 키워드

자바스크립트에서 예약어(키워드)는 식별자로 사용할 수 없다. 예: let, const, var, function, if, class, return 등

let if = 5; // ❌ 문법 오류

네이밍 컨벤션 (Naming Conventions)

자바스크립트에서 일반적으로 사용하는 작명 규칙은 다음과 같다:

정리

블록(Block)

정의

블록은 {} 중괄호로 묶인 코드 집합이다. 여러 문(statement)을 하나로 묶어서 제어문, 함수, 클래스 등의 내부에서 사용한다.

{
  let x = 10;
  console.log(x);
}

• 이 블록은 자체적인 스코프(scope)를 가진다.
• let, const는 블록 스코프를 따른다. (예: 블록 밖에서는 변수 x를 접근할 수 없음).

제어문(Control Statements)

제어문은 코드의 실행 흐름을 조건이나 반복에 따라 다르게 만들기 위해 사용된다. 주요 제어문은 다음과 같다.

조건문 (Conditional Statements)

if, else if, else

let score = 85;

if (score >= 90) {
  console.log("A");
} else if (score >= 80) {
  console.log("B");
} else {
  console.log("C");
}

• 조건이 true일 때 블록 내부 코드가 실행된다.
• 각 블록은 {}로 묶으며, 생략할 수도 있지만 가독성 유지 및 실수 방지를 위해 블록 사용 권장.

switch

let fruit = "apple";

switch (fruit) {
  case "apple":
    console.log("사과입니다.");
    break;
  case "banana":
    console.log("바나나입니다.");
    break;
  default:
    console.log("알 수 없는 과일입니다.");
}

• break 없으면 fall-through(다음 case로 넘어감) 발생.
• default는 일치하는 case가 없을 때 실행.

반복문 (Loops)

for

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

• 초기식, 조건식, 증감식으로 구성.
• 블록 내 코드를 반복 실행.

while

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

• 조건이 참일 동안 반복.

do...while

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

• 최소 한 번은 실행되고 조건 검사.

기타 제어 흐름문

break

• 반복문이나 switch 문에서 즉시 빠져나올 때 사용.

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

continue

• 현재 반복을 건너뛰고 다음 반복으로 넘어감.

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

return

• 함수에서 사용하며 값을 반환하고 실행을 종료함.

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

정리: 흐름도 개념

조건문
 └─> true → 블록 실행
 └─> false → 다음 조건 또는 else

반복문
 └─> 조건 → true → 블록 반복 실행
        → false → 반복 종료