dyeon-dev.log https://velog.io/ https://dyeon-dev.vercel.app/blog Mon, 02 Mar 2026 11:31:44 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed dyeon-dev.log https://velog.velcdn.com/images/dyeon-dev/profile/fc32a22c-e203-477a-9f17-1aca0c792af0/social_profile.png https://velog.io/ Copyright (C) 2019. dyeon-dev.log. All rights reserved. <![CDATA[네이버 부스트캠프 웹・모바일 10기 과정 수료 후기 🍀]]> https://velog.io/@dyeon-dev/%EB%84%A4%EC%9D%B4%EB%B2%84-%EB%B6%80%EC%8A%A4%ED%8A%B8%EC%BA%A0%ED%94%84-%EC%9B%B9%E3%83%BB%EB%AA%A8%EB%B0%94%EC%9D%BC-10%EA%B8%B0-%EA%B3%BC%EC%A0%95-%EC%88%98%EB%A3%8C-%ED%9B%84%EA%B8%B0 https://velog.io/@dyeon-dev/%EB%84%A4%EC%9D%B4%EB%B2%84-%EB%B6%80%EC%8A%A4%ED%8A%B8%EC%BA%A0%ED%94%84-%EC%9B%B9%E3%83%BB%EB%AA%A8%EB%B0%94%EC%9D%BC-10%EA%B8%B0-%EA%B3%BC%EC%A0%95-%EC%88%98%EB%A3%8C-%ED%9B%84%EA%B8%B0 Mon, 02 Mar 2026 11:31:44 GMT 네부캠이 끝난지 거의 한 달이 되어간다. 그동안 이력서도 업데이트 하고, 피드백 특강도 받으면서 2월달 시간이 빠르게 흘렀다. 와중에 10기 캠퍼들의 포스트 캠프(네트워킹) 자리까지 마련되면서 많은 담소를 직접 나누기도 했다.!

매주 네부캠 내에서 회고를 작성했지만, 무탈하게 끝난 기념으로 전체 회고를 작성해보려 한다.

지원 동기?

우선, 지원하게 된 동기는 나는 프론트엔드 개발자를 희망했었다. 하지만 결국에 웹 개발을 잘 하기 위해서는 백엔드 역량도 어느정도 필요할 것이라는 생각이 들었다. 오롯이 나의 욕심에 의한 웹 풀스택 개발자로 나아가기 위한 첫 여정을 네부캠에서 하고 싶었다. 공식 홈페이지에 소개되어있던 지속가능한 개발자, 학습 철학 등이 나의 추구하는 방향과 아주 잘 맞아보였다.

8개월간의 여정이 끝난 시점에서 나는 무엇을 얻었는가?

베이직(2주), 챌린지(4주), 멤버십(22주) 총 28주

프론트엔드에만 관심있던 내가 백엔드까지 사고를 확장하면서 소프트웨어 아키텍처의 설계 능력을 더욱 갖췄다고 할 수 있을 것 같다. 네부캠에서 많은 미션들을 겪으면서 모든 결정에 설계-구현 사고 흐름을 적용하게끔 만들었다. 그만큼 소프트웨어에는 '정답'이 없다는 것을 깨달았고, 내가 생각하는 논리적인 구조만으로 상대방을 설득하고 프로젝트에 적용시켜야 한다.

또한, 8개월의 시간이 흐름에 따라 AI 도구들도 정말 비약적으로 발전했다. 그런 도구들을 매번 습득해나가면서 함께 성장했던 것 같다. 덕분에 AI 관련 활동들도 많이 해봤다. 아마 현업 수준으로 바이브 코딩도 많이 해봤을 거다.. 많은 인사이트를 얻게 해줬고 앞으로의 개발 경험에도 도움이 많이 될 거라고 생각한다~!

4주간의 챌린지는 CS 기초를 다지는 시간들!

챌린지에서는 Low Level CS 지식에 밀착해서, 실제 시스템을 작은 단위로 구현하며 검증하는 미션들 위주였다. 멤버십 과정으로 가기 위해서는 챌린지를 잘 해내야하는데, 내 기억으론 고3때보다 잠을 더 못잤던 기억이 있다..하하 나는 컴퓨터공학 유사 전공 계열(데이터사이언스)로 핵심적인 로우 레벨까지는 자세하게 배우지 못했어서 많이 힘들었던 기억이 있다. 그래도 이전에 정처기나 CS 공부를 조금이나마 했었기 때문에 깨어있는 시간들을 갈아넣어서 학습하고 미션을 해결하려고 많이 노력했다.

가장 기억에 남는 활동은, “영상 업로드→처리→검증” 프로세스를 큐/매니저/이벤트 루프로 나눠 비동기 파이프라인을 시뮬레이션했던 것이다. 스레드 풀과 멀티 스레드 등 비동기 프로그래밍을 가능하게 하는 것들을 깊이있게 학습하면서 Node.js나 브라우저 내부 구조를 직접 탐구했다. 이런 시뮬레이터의 핵심 구조를 본보기 삼아서 영상 비동기 업로드 처리를 구현했던 기억이 있다. 이처럼 동작 원리를 이해하기 위해, 추상 개념을 구현체(도구)로 내려서 확인하는 미션들을 통해 CS의 기초를 다질 수 있었다.

그래도 열심히 했던게 헛되지 않았고 🥹 감사하게도 멤버십 과정까지 참여하게 되었다!

다사다난 했던 멤버십 과정!

바닐라JS부터 리액트 프로젝트.. 그리고 그룹 프로젝트까지.. 총 6번의 굵직한 플젝들

멤버십 때 경험했던 것처럼 미션을 해결해나가는 과정에는 정답이 없다. 그래서 매주 매칭된 팀원들과 함께 설계와 구현 과정들을 공유하고 서로 피드백도 주고 받으면서 성장해나갔다.

제일 처음 했던 프로젝트는 바닐라 자바스크립트 방식으로 EJS 템플릿을 사용해서 SSR으로 렌더링 처리하는 프로젝트였다. 이후 바닐라 자바스크립트를 기반으로 한 SPA 패턴의 컴포넌트 렌더링 아키텍처를 구현하는 프로젝트를 진행하면서, Store 클래스의 Pub/Sub (Observer) 패턴 등을 직접 구현하며 향후 사용할 리액트 프레임워크의 동작원리의 기반을 다졌다.

웹 애플리케이션의 역사를 생각해봤을 때 초창기 전통적인 페이지 기반의 SSR 방식에서 필요한 부분만 부분적으로 업데이트하는 현대의 SPA 방식으로 넘어가는 그 전환점들을 직접 프로젝트로 경험해보며 웹의 역사를 직접적으로 알아갈 수 있었다. 관련 포스팅

그리고 일련의 활동에서 배운 것들을 정리하고, 캠퍼들에게 공유하는 시간이 좋았다. 아무래도 같은 내용을 함께 학습하고 있다보니까 함께 소통하면서 얻어갈 수 있는 것들이 정말 많았다. 항상 스크럼 때 다양한 주제로 이야기를 나누게 되었고, 매주 동료 피드백에서 팀원들에게 전문성 기르기(PROFESSIONAL)와 함께 자라기(TOGETHER) 키워드를 가장 많은 피드백으로 받기도 했다.

팀 프로젝트 잘하는 법

그리고 _그룹 스프린트_를 진행하면서 3주간 페어프로그래밍으로 구현하고, 2주간 다른 팀의 코드를 리팩토링하는 활동까지 했다. 이때 배운 것과 느낀게 굉장히 많았다.

본격적인 팀 프로젝트를 진행하니까 내 코드만 이해하는게 아니라 다른 사람의 코드까지 이해 해야됐다. 그래서 우리팀은 모든 팀원의 코드 리뷰를 필수적으로 진행했다. 그리고 페어프로그래밍을 통해 문제가 발생했던 상황을 유연하게 대처하기도 했다. 또한 테스트 코드를 통해 결함없는 환경이 구축될 수 있도록 했다.

특히, 리팩토링 과정에서는 다른 팀이 설계하고 구현해둔 코드는 이해하기가 더더욱 쉽지 않았다. 이때 팀의 개발 일지와 설계 문서를 참고하니 많은 도움이 되었다.

이처럼 그룹 스프린트 동안에 겪은 문제 상황과 해결법을 몸소 느낀 뒤로 팀 프로젝트를 '잘'하기 위해 여러 방법을 체계화했다. 이렇게 체계화한 습관은 _그룹 프로젝트_에서도 그대로 이어졌다.

  • PR 템플릿을 활용해서 문제 상황 해결 과정을 자세하게 남기기
  • 개발일지 작성하기
  • 모든 팀원이 꼼꼼하게 코드리뷰 남기기
  • 팀원들과 설계 문서 필수로 작성하기
  • 아키텍처 구조화를 이미지로 많이 생성하기
  • 의견 논의가 있을 때 discussions 사용하기

프로젝트가 잘 나아가기 위해서는 팀원들과의 이해도를 잘 맞춰야 한다. 서로 이해한 수준이 다르면 코드는 산으로 갈 수 있기 때문이다. 따라서 나의 생각을 정확하게 전달하고 다른 사람의 의도를 정확하게 파악하는 소프트스킬을 팀 프로젝트를 통해서 많이 배울 수 있었다.

TADAK 팀 프로젝트

열정적인 팀원들을 만나 최종 팀 프로젝트를 성공적으로 마칠 수 있었다. 첫 일주일간 아이디어 기획 회의만 진행했었는데 우리들의 공통된 문제의식을 찾기 위해 노력했다. 아무래도 취준생 입장이니 학습하는데에 몰입을 해야되고 그곳에 재미를 느끼면 좋겠다는 생각을 했다. 그래서 지루한 고테 공부에 게이미피케이션을 적용하여 알고리즘 배틀 플랫폼을 만들었다.

깃허브 바로가기

프로젝트의 목표는 다음과 같았다.

  • 최소기능구현(MVP)으로 핵심 기능들을 먼저 만들고 추가적인 기능을 확장해나가기
  • 사용자 피드백을 꾸준히 받으며 서비스 개선해나가기
  • 실시간성, 공정성, 보안, 안정성, 사용자 경험을 모두 만족하는 서비스 만들기
  • 확장성을 고려한 아키텍처 구성하기

목표를 이루기까지 정말 많은 시행착오들이 있었는데, 매주 데모를 진행하면서 프로젝트의 버그나 개선점을 많이 찾아낼 수 있었다. 그 결과 매주 업데이트한 버전을 배포하고 릴리즈에 기록했다. 그리고 매주 구글폼으로 사용자 피드백을 받아서 프로젝트의 목적에 달성했는지 평가했다.

최종 발표 당일에 예상치 못한 버그가 발생했다.. 다행히(?) 발표 순서 전에 발견을 했고 점심시간에 모여 팀원들과 의견을 나누며 한시간 이내로 문제를 해결했다. 아마 위에서 언급했던 모든 팀원이 이해도를 맞추던 습관 덕분에 어느 지점에서 문제가 발생했는지 빠르게 파악할 수 있었다. 팀원들과 함께 원인을 파악할 수 있었던 결과였기 때문에 다시 한 번 습관의 중요성을 그때 가장 크게 느꼈다.

회고글을 적다보니 8개월간 정말 많은 것들을 배우고 성장했다는 생각이 든다. 좋은 동료들을 만나 크게 성장한 것 같아서 뿌듯하고, 앞으로의 개발할 날들을 더욱 기대하면서 이만 마무리하겠다! 😉

부스트캠프 감사합니다~!!

]]> <![CDATA[공간데이터 타입과 R-tree 구조]]> https://velog.io/@dyeon-dev/%EA%B3%B5%EA%B0%84%EB%8D%B0%EC%9D%B4%ED%84%B0-%ED%83%80%EC%9E%85%EA%B3%BC-R-tree-%EA%B5%AC%EC%A1%B0 https://velog.io/@dyeon-dev/%EA%B3%B5%EA%B0%84%EB%8D%B0%EC%9D%B4%ED%84%B0-%ED%83%80%EC%9E%85%EA%B3%BC-R-tree-%EA%B5%AC%EC%A1%B0 Wed, 29 Oct 2025 02:57:16 GMT 지도 기능을 구현하기 위해서 데이터베이스에 위도, 경도 좌표 저장이 필요했다. 효율적으로 좌표를 저장하기 위해서 "공간데이터" 타입을 설정해줄 수 있다.

공간데이터를 적용하기 전에, 공간데이터 타입의 종류와 데이터베이스에 따른 차이점 등을 알아보자. R-tree 자료구조 기반으로 공간인덱싱이 활용이 되는데, 데이터베이스에 따라 실제 R-tree 기반의 종류도 조금씩 다르다. 이에 대해 더 자세히 살펴보자.

공간데이터 타입 종류

MySQL에서 제공하는 공간 데이터의 종류는 총 7가지이다. 단일 타입으로는 Point, LineString, Polygon 세 가지이다.

  • Point: 좌표 공간의 한 지점
  • LineString: 다수의 Point를 연결해주는 선분
  • Polygon: 다수의 선분이 연결되어 닫혀있는 상태

나머지 타입들은 이 세 가지 타입의 조합이다.

  • Geometry, Multipoint, Multilinestring, Multipolygon, Geometrycollection

TypeORM 공식문서를 참고해보면 MySQL, PostgreSQL 등 DB에서 공간데이터를 생성하는 방법으로 크게 두 가지가 나온다. (먼저 공간 인덱스를 사용하는 열에 spatial: true 옵션을 사용하여 인덱스를 추가한다.)

1. POINT 타입 (MySQL POINT 타입)

@Entity()
export class Thing {
    @Column("point")
    @Index({ spatial: true })
    point: string
}

⚙️ 내부 동작

  • 내부적으로 2차원 좌표 (x, y) 를 저장
  • 인덱스는 R-Tree 기반(MyISAM) 또는 B-Tree-like Spatial Index(InnoDB)로 구현
  • ST_Distance(), MBRContains() 등 Bounding Box 기반 연산이 가능

특징

  • 저장 형태: POINT(x, y) 또는 WKB(Binary)
  • 표현 가능 객체: 단일 점(Point)만 가능
  • SRID 없음: 좌표계 정보 없음, 단순 2D 좌표

2. GEOMETRY 타입 + SRID (PostGIS 또는 MySQL Geometry 타입)

export interface Geometry {
    type: "Point"
    coordinates: [Number, Number]
}

@Entity()
export class Thing {
    @Column("geometry", {
    spatialFeatureType: "Point",
    srid: 4326,
    })
    @Index({ spatial: true })
    point: Geometry
}

⚙️ 내부 동작

  • geometry는 공간객체를 추상화된 타입으로 저장
  • srid: 4326을 지정하면, MySQL이 해당 좌표계를 기준으로 지구구면 연산(거리, 면적 등)을 수행
  • 인덱스는 단순 bounding box가 아니라, 좌표계 변환 + 공간 연산까지 고려

특징

  • 공간 객체의 모든 타입을 포괄하는 슈퍼 타입
  • 저장 형태: WKT(POINT(lon lat)) 또는 WKB(Binary)
  • 표현 가능 객체: Point, LineString, Polygon, MultiPoint 등 모든 공간 객체
  • 인덱스: R-Tree 기반 Spatial Index (GiST/Spatial) 좌표계 기반 공간 인덱싱

POINT / GEOMETRY 타입 핵심 차이 정리

GEOMETRY
 ├── POINT
 ├── LINESTRING
 ├── POLYGON
 └── MULTI* (복수형 버전)
비교 항목 point geometry
데이터타입 단일 Point만 저장 Point, Line, Polygon 등 다양한 공간 객체
공간 인덱스 단순 R-Tree (Bounding Box) 고급 GiST / R-Tree 기반
공간 연산 함수 지원 MBRContains, MBRWithin 등 단순 직사각형 기반, (ST_Distance, ST_Within 일부만) ST_Contains, ST_Intersects, ST_Distance 등 모든 ST_* 함수 완전 지원
(정밀 공간 연산)
좌표계 변환 불가능 (단순 숫자좌표) 가능 (예: EPSG:3857 ↔ EPSG:4326)
사용 목적 내부 좌표 계산, 단순 위치정렬 지도/GIS용 실제 좌표계 기반 분석

어떤 상황에 어떤 데이터 타입이 적합할까?

상황 적합한 타입
“유저가 마지막으로 클릭한 위치를 기록” point
“서울시 내 카페를 반경 2km 이내 검색” geometry + SRID=4326
“행정구역 폴리곤과 포함 여부 판정” geometry
“지도 렌더링 / 거리 계산 / 좌표 변환” geometry

하지만 어떤 데이터베이스를 사용하느냐에 따라 같은 point, geometry 타입이어도 내부 동작이 다르다.

  • MySQL에서는 POINT + SRID가 부분지원(메타데이터 수준)
  • PostGIS에서는 POINT + SRID가 완전한 공간객체 지원
항목 MySQL PostGIS
POINT + SRID SRID 저장만 가능, 좌표계 변환/지구거리 불가 완전한 geometry 연산 지원
GEOMETRY(Point) + SRID 동일하게 SRID 적용, 모든 공간연산 가능 완전 동일 (내부적으로도 같은 구조)
권장 방식 GIS 분석 목적이면 geometry(Point, srid) 둘 다 가능
정리하자면
- POINT + SRID는 단순히 좌표계 정보만 메타데이터로 포함한 버전
- GEOMETRY(Point, SRID)는 GIS 전용 연산, 좌표계 변환, 거리 계산 등 고급 기능까지 가능한 완전한 공간객체

👉 “지도 서비스 수준의 공간 연산”을 한다면 geometry(Point, 4326)
👉 반면 “그냥 위치좌표만 저장”하는 경우라면 POINT SRID 4326으로 충분하다.

데이터베이스의 R-tree 구조

두 가지 타입은 공간 인덱스를 만들기 위해 R-Tree를 기반으로 동작한다. 하지만 그 구현 방식과 제한사항도 DB 엔진(MyISAM, InnoDB, PostGIS)에 따라 다르다.

DB 엔진 POINT 인덱스 구조 내부 알고리즘 한계
MyISAM (MySQL) R-Tree 전통적 R-Tree SRID/좌표계, 트랜잭션 미지원, 단순 Bounding Box, InnoDB 대비 안정성 낮음
InnoDB (MySQL 5.7+) “R-Tree-like” (B-Tree + Spatial extension) B-Tree 기반으로 구현된 공간인덱스 구조 (R-Tree와 유사한 구조로 최적화) MBR(최소경계사각형) 단위 비교, 진짜 R-Tree는 아님
PostGIS (PostgreSQL) GiST 기반 R-Tree variant R-Tree의 일반화 버전 (GiST) 완전한 공간 연산, SRID/좌표계 지원

MyISAM (MySQL)

  • MySQL의 초기 공간 인덱스 엔진으로, 정통적인 R-Tree 구조를 사용한다.
  • 인덱스 노드에는 각 포인트나 도형을 감싸는 MBR(Minimum Bounding Rectangle, 최소경계사각형) 이 키로 저장된다.
  • 공간 연산(MBRContains, MBRIntersects, MBRWithin 등) 시 R-Tree 탐색 과정을 통해 MBR이 겹치는 후보군을 빠르게 필터링한다.
  • 인덱스는 다차원 분할 로직을 사용하며, 삽입/삭제 시 노드 분할(splitting), 재삽입(reinsertion) 등의 전통적인 R-Tree 알고리즘을 수행한다.
  • 트랜잭션과 외래키 제약은 지원하지 않지만, 순수 공간 탐색 성능은 InnoDB보다 빠른 경우가 많다.

✏️ 내부 연산 과정

  1. 쿼리(예: MBRContains()) 시, R-Tree 인덱스가 각 객체의 MBR을 계층적으로 탐색
  2. MBR이 겹치는 후보군만 빠르게 반환
  3. 필요 시 애플리케이션 레벨에서 추가적인 geometry 연산 수행

➡️ 즉, 진짜 R-Tree 구조를 구현한 MySQL의 고전적 공간 인덱스 엔진으로,
MBR 단위의 공간 필터링을 빠르게 수행하는 구조이다.

MySQL InnoDB의 Spatial Index

  • 이름은 “R-Tree 기반”이지만, 진짜 R-Tree는 아니다.
  • InnoDB의 페이지 구조는 기본적으로 B-Tree 입니다.
    그래서 공간 인덱스도 B-Tree 페이지를 확장해서 저장한다.
  • 이때 키로 쓰이는 건 MBR (Minimum Bounding Rectangle) 값이다.
  • 즉, "x_min, y_min, x_max, y_max" → 1차원 key로 변환해서 B-Tree에 저장

➡️ R-Tree의 개념(공간 분할, bounding box) 은 차용하지만,
알고리즘과 트리 구조 자체는 B-Tree이다.

✏️ 내부 연산 과정

  1. 쿼리(예: ST_Within()) 시, 인덱스가 각 포인트의 MBR을 조회
  2. 후보군을 MBR 기준으로 필터링
  3. 그 다음 “정확한 계산” 없이 결과 반환 (MBR 기반만 수행)

즉, “Bounding box overlap check”까지만 하는 1단계 필터이다.

PostGIS GiST 인덱스

  • GiST(Generalized Search Tree)는 PostgreSQL이 제공하는 인덱스 프레임워크로,
    R-Tree, B-Tree, kNN, HNSW 등 다양한 인덱스를 일반화할 수 있다.
  • PostGIS는 이 GiST 프레임워크 위에 R-Tree-like 알고리즘을 구현했다.

✏️ GiST의 구조

  • 각 노드에 저장되는 값은 Bounding Box + Consistency Function
  • Consistency Function이란:
    “이 인덱스 항목이 쿼리 조건에 부합하는가?”를 판단하는 함수.
    (예: does overlap?, is within?, distance < threshold?)

    ⚙️ 두 단계 필터링

  1. Rough filter: Bounding box로 후보군을 찾음
    → R-Tree처럼 빠름
  2. Exact filter: 실제 geometry 연산 수행 (ST_Within, ST_Intersects 등)

➡️ 즉, R-Tree의 공간 계층 구조 + 정확한 geometry 연산까지 포함된 진짜 공간 인덱스

MySQL InnoDB
 └── B-Tree Page → MBR(x_min, y_min, x_max, y_max)
      └── Record → WKB binary of geometry
      (정렬 기준: Bounding Box 좌표)

PostGIS GiST
 └── GiST Node → Bounding Box + Consistency Function
      ├── Leaf → geometry binary (w/ SRID)
      └── 연산 단계: Rough Filter → Exact Geometry Check
]]> <![CDATA[에어비엔비 지도 검색 분석 🔍]]> https://velog.io/@dyeon-dev/%EC%97%90%EC%96%B4%EB%B9%84%EC%97%94%EB%B9%84-%EC%A7%80%EB%8F%84-%EA%B2%80%EC%83%89-%EB%B6%84%EC%84%9D https://velog.io/@dyeon-dev/%EC%97%90%EC%96%B4%EB%B9%84%EC%97%94%EB%B9%84-%EC%A7%80%EB%8F%84-%EA%B2%80%EC%83%89-%EB%B6%84%EC%84%9D Wed, 29 Oct 2025 00:07:52 GMT 에어비엔비 지도 검색 분석

에어비엔비에서 아무런 검색값 없이 검색하게 되면 내 근처의 숙소 리스트를 보여줍니다. 그런데 저는 로그인을 하지 않았고, 위치 허용 여부를 선택한 적 없습니다. 그런데 어떻게 내 근처의 숙소 리스트를 보여줄까요?

에어비엔비의 경우 URL 파라미터의 값으로 상태관리를 주로 하는 것 같아보였습니다. 그래서 URL을 분석해보았습니다. Airbnb는 검색 조건을 모두 GET Query로 노출시키는 방식이며,
날짜/인원 선택에 따라 "검색 모드, 좌표, 달력 사용 여부, 장기 숙박 옵션, 필터 UI 상태" 같은 메타 정보까지 URL에 포함됩니다.

아무것도 선택 없이 검색한 경우

https://www.airbnb.co.kr/s/homes?
refinement_paths[]= /homes
&location_search=NEARBY
&source=structured_search_input_header
&search_type=unknown
  • 다른 건 거두절미 하고, location_search=NEARBY 라고 보입니다.
  • 현재 사용자의 위치 기반으로 근처 지역 숙소 검색한다는 뜻이겠죠.
  • 즉, 위치·날짜·인원 미선택 → 기본적으로 내 주변 기반 탐색

날짜, 인원을 선택하고 검색할 경우 URL

https://www.airbnb.co.kr/s/homes?
refinement_paths[]= /homes
&location_search=NEARBY
&source=structured_search_input_header
&search_type=unknown
&flexible_trip_lengths[]=one_week
&center_lat=37.45
&center_lng=126.73
&monthly_start_date=2025-11-01
&monthly_length=3
&monthly_end_date=2026-02-01
&search_mode=regular_search
&price_filter_input_type=2
&channel=EXPLORE
&date_picker_type=calendar
&checkin=2025-11-01
&checkout=2025-11-04
&adults=2
&drawer_open=true
  • center_lat, center_lng 값과 location_search=NEARBY 값이 보입니다.
  • location_search=NEARBY: 위치 검색 옵션이 “내 주변” 모드라는 의미
  • center_lat , center_lng: 실제 계산된 지도 중심 좌표

지도 이동 기반으로 검색할 경우 URL

https://www.airbnb.co.kr/s/homes?
refinement_paths[]= /homes
&location_search=NEARBY
&source=structured_search_input_header
&search_type=user_map_move
&flexible_trip_lengths[]=one_week
&monthly_start_date=2025-11-01
&monthly_length=3
&monthly_end_date=2026-02-01
&search_mode=regular_search
&price_filter_input_type=2
&channel=EXPLORE
&date_picker_type=calendar
&checkin=2025-11-01
&checkout=2025-11-04
&adults=2
&price_filter_num_nights=3
&ne_lat=37.61692080810032
&ne_lng=126.80809670588201
&sw_lat=37.255288467379465
&sw_lng=126.60219879834523
&zoom=10.876819265101252
&zoom_level=10.876819265101252
&search_by_map=true
  • search_type이 unknown에서 user_map_move(지도 이동 기반 검색)으로 바뀌었습니다.
  • 이 경우 지도 화면에 보이는 영역(뷰포트)을 기준으로 사용자가 지도를 움직이면 화면에 보이는 영역만 숙소를 다시 검색합니다.
  • ne_lat, ne_lng, sw_lat, sw_lng 4개의 좌표도 추가되었습니다. 이건 현재 화면에 보이는 사각형 영역(Bounding Box)를 의미합니다.
    • 지도 화면에서 위쪽 오른쪽 끝의 좌표(ne)
    • 지도 화면에서 아래쪽 왼쪽 끝의 좌표(sw)
  • zoom / zoom_level: 지도 확대 수준 (클수록 좁은 범위)
  • 즉, 지도 이동 시 화면 좌표 계산 → bounding box 생성 → 해당 범위 내 숙소만 다시 fetch 과정을 반복합니다.

URL에서 확인했다시피, 저는 위치 정보를 허용한적이 없는데 지도 중심 좌표가 들어간 것을 확인하였습니다. 그리고 상황별로 위치 좌표를 사용하는 의미와 방식이 다릅니다. 정리해보자면,

검색바 기반 검색의 경우 (검색어가 없을 때)

  • 위치 기반으로 근처 지역 숙소 검색

    검색바 기반 검색의 경우 (검색어가 있을 때)

  • 중심 좌표(center_lat, center_lng) + 반경(radius) 방식

    지도 기반 검색의 경우

  • 지도의 실제 화면 영역(bounding box)로 판단
  • 화면이 가로/세로 비율을 가지므로 중심점 + 거리만으로는 표현 불가

왜 위치 허용을 하지 않았는데도 center_lat / center_lng가 보일까?

Airbnb에서 위치 권한을 허용하지 않았는데도 center_lat / center_lng같은 좌표들이 나타나는 이유는 실제로 내부에서 IP 기반 GeoIP 위치 값을 받아오기 때문입니다. 즉, geolocation API가 아니어도 Airbnb는 사용자의 대략적인 지역 좌표를 추정할 수 있습니다.

1) Airbnb는 먼저 navigator.geolocation을 시도하지 않는다.

  • Airbnb는 브라우저 권한 요청을 사용자에게 먼저 띄우지 않습니다.
  • 대부분의 사용자에게 "위치 권한 허용" 팝업이 뜬 적이 없을 것이다.
  • Airbnb는 geolocation API 없이도 사용자의 위치를 알고 싶어하기 때문에 서버에서 IP 기반으로 대략적인 위·경도를 계산해서 URL에 넣습니다.

2) IP 기반 GeoIP 정보는 위도/경도를 제공한다.

  • GeoIP DB는 단순히 “대한민국/서울” 수준이 아니라, 대략적인 위도(latitude)·경도(longitude)까지 제공합니다.
  • 예) IP → 서울시 관악구 주변 → lat=37.47, lng=126.95 같은 값 반환
  • 그래서 위치 권한을 전혀 허용하지 않아도 center_lat, center_lng, 지도 중앙 좌표, 주변 숙소 선택 같은 것들이자동으로 가능합니다.

3) 검색 조건이 두 단계로 동작한다.

  • location_search=NEARBY 위치 검색 옵션으로 “내 주변” 검색 모드로 동작하고,
  • center_lat & center_lng 등의 실제 계산된 지도 중심 좌표를 통해 검색합니다.

이렇듯, geolocation을 허용하는 팝업이 뜨지 않고 Airbnb는 사용자 경험을 위해 좌표가 가능한 한 항상 존재하도록 설계했습니다.

]]> <![CDATA[React의 상태 관리 - useReducer, ContextAPI]]> https://velog.io/@dyeon-dev/React%EC%9D%98-%EC%83%81%ED%83%9C-%EA%B4%80%EB%A6%AC https://velog.io/@dyeon-dev/React%EC%9D%98-%EC%83%81%ED%83%9C-%EA%B4%80%EB%A6%AC Tue, 21 Oct 2025 00:47:59 GMT 리액트에서의 상태는 시간이 지나면서 변할 수 있는 동적 데이터이며, 값이 변경될 때마다 컴포넌트의 렌더링 결과물에 영향을 준다. 리액트 앱 내의 상태는 지역 상태 / 전역 상태 / 서버 상태로 구분할 수 있다. 리액트 내부 API만을 사용해서 상태를 관리할 수 있지만 성능 문제와 상태의 복잡성으로 인해 Redux, Recoil, Zustand와 같은 상태 라이브러리를 활용하기도 한다.

상태(state)의 세 가지 구분

구분 저장 위치 예시 특징
지역 상태 (Local State) 특정 컴포넌트 내부 (useState, useReducer) 입력값, 모달 열림 여부 등 해당 컴포넌트 안에서만 접근 가능
전역 상태 (Global State) 여러 컴포넌트에서 공유 (Context, Redux, Recoil 등) 로그인 정보, 테마 모드 등 앱 전역에서 접근 가능
서버 상태 (Server State) 외부 서버(백엔드 API 등)에 저장 게시글 목록, 유저 정보, 상품 데이터 등 React 외부의 데이터 — 네트워크 요청으로 가져와야 함

지역 상태 (Local State)

지역 상태는 컴포넌트 내부에서 사용되는 상태로, 예를 들어 체크박스의 폼의 입력값 등이 해당한다. 주로 useState 훅을 가장 많이 사용하며 때에 따라 useReducer와 같은 훅을 사용하기도 한다.

전역 상태 (Global State)

전역 상태는 앱 전체에서 공유되는 상태를 의미한다. 여러 개의 컴포넌트가 전역 상태를 사용할 수 있으며 상태가 변경되면 컴포넌트들도 업데이트 된다. Prop drilling 문제를 피하고자 지역 상태를 해당 컴포넌트들 사이의 전역 상태로 공유할 수도 있다.

서버 상태 (Server State)

서버 상태는 사용자 정보, 글 목록 등 외부 서버에서 저장해야 하는 상태를 의미한다. UI 상태와 결합하여 관리하게 되며 로딩 여부나 에러 상태 등을 포함한다.

서버 상태도 결국 서버에서 가져온 데이터지만 React 내부에선 그냥 useState나 useReducer 같은 훅으로 관리되는 지역 상태이다.

그런데 서버 상태는 일반 상태랑 다르다

비슷하게 관리할 수는 있지만, 서버 상태만의 특성이 있다.

항목 지역/전역 상태 서버 상태
데이터 출처 클라이언트 내부에서 생성 서버(API)에서 가져옴
최신성 항상 최신 (즉시 수정 가능) 시간이 지나면 “오래됨”
갱신 방식 setState()로 직접 수정 다시 fetch해야 함
비동기성 거의 없음 항상 비동기 (로딩/에러 필요)
동기화 필요성 없음 서버 데이터와 동기화 필요

단순히 useState로 서버 데이터를 관리하면 로딩 상태 / 에러 처리 / 캐싱 / 리페치(refetch) / 동시성 관리 등을 직접 다 구현해야 해서 복잡해진다.

그래서 등장한게 react-query, SWR와 같은 서버 상태 관리 라이브러리이다. 서버와의 동기화, 캐싱, 비동기 처리 등 때문에 최근에는 전용 라이브러리로 관리하는 추세다.

상태로 정의하기 전에 고려해야 할 점

상태가 업데이트 될 때마다 리렌더링이 발생하기 때문에 유지보수 및 성능 관점에서 상태의 개수를 최소화하는 것이 바람직하다. 가능하다면 상태가 없는 Stateless 컴포넌트를 활용하는게 좋다.

어떤 값을 상태로 정의할 때는 다음 2가지 사항을 고려해야 한다.

1. 시간이 지나도 변하지 않는다면 상태가 아니다.

상태는 시간에 따라 변할 수 있는 값을 관리하기 위한 것이다. 따라서 컴포넌트의 라이프사이클 동안 변하지 않는 값이라면 굳이 상태로 둘 필요가 없다.

하지만 동일한 참조를 유지해야 한다면

상태로 둘 필요는 없지만, 그 값을 렌더링 과정에서는 "하나의 동일한 객체로 유지"해야 할 필요는 있다.

  • 렌더링될 때마다 새로 만들어지면 안되는 값이라면 그 참조를 일정하게 유지하는 방법이 필요한 것이다.
  • 객체 참조 동일성을 유지하는 방법을 고려해야 한다.

예를 들어, "시간이 지나도 변하지 않는 값"으로 컴포넌트가 마운트될 때만 스토어 객체 인스턴스를 생성하고, 언마운트될 때까지 해당 참조가 변하지 않는다고 가정해보자.

const store = new Store(); // 매번 새로운 인스턴스 생성

이처럼 단순히 상수 변수에 저장하는 방법이 있을 것이다. 하지만 이런 방식은 다음과 같은 문제점이 있다.

  • 함수형 컴포넌트는 렌더링될 때마다 함수가 다시 실행되므로 상수에 객체를 저장하면 매번 새로운 객체가 생성된다.
  • 이 객체가 Context나 props 등으로 전달되면, 매번 참조가 달라져서 불필요한 리렌더링이 자주 발생할 수 있다.

이 문제를 해결하려면, 컴포넌트가 마운트될 때 한 번만 객체를 생성하고 이후 렌더링에서도 같은 참조를 유지하도록 만들어야 한다.

동일한 객체 참조를 유지하는 3가지 방법

객체 참조 동일성을 유지하기 위해 사용되는 방법 중 하나는 메모이제이션이다. 1. useMemo 사용 (권장되지 않음)

const store = useMemo(() => new Store(), []);
  • 렌더링 간 동일한 객체를 유지할 수 있다.
  • 하지만 useMemo는 성능 최적화를 위한 메모이제이션용 훅이며, 객체 참조 유지를 위한 용도로 사용하는 것은 권장되지 않는다.

2. useState의 지연 초기화(Lazy Initialization) 사용

const [store] = useState(() => new Store());
  • useState의 초기값 함수를 사용하면, 마운트 시점에 한 번만 실행된다.
  • 이후 렌더링에서도 동일한 인스턴스가 유지된다.
  • 기술적으로는 잘 동작하며, 실제로 동일한 객체 참조를 보장할 수 있다.

하지만 의미론적으로는 좋은 방법이 아니다.

  • useState는 본래 “시간이 지나면서 변하고, 렌더링 결과에 영향을 주는 값”을 관리하기 위해 설계된 훅이다.
  • 그러나 위와 같은 경우의 목적은 “상태 변화”가 아닌 “객체 참조의 동일성 유지”이므로, 의미상으로는 useRef를 사용하는 것이 더 적합하다.

3. useRef 사용 (가장 권장되는 방식)

const store = useRef<Store>(null);

if (!store.current) {
  store.current = new Store();
}
  • useRef는 렌더링이 다시 일어나도 같은 객체를 계속 유지한다.
  • useRef.current는 React가 재렌더링 시에도 초기화하지 않기 때문에 “마운트 시 한 번 생성 → 언마운트 전까지 동일 참조 유지”에 가장 적합하다.
  • React 공식문서에서도 이 목적에는 useRef를 사용하는 것을 권장한다.

2. 파생된 값은 상태가 아니다.

SSOT 원칙

SSOT (Single Source of Truth) : 하나의 데이터는 단 하나의 출처(source) 에서만 생성·수정되어야 한다.

React에서도 이 원칙은 그대로 적용된다. 다른 값에서 파생될 수 있는 데이터는 상태로 두지 말고, 단일 출처(SSOT) 원칙을 지켜야 한다.

부모로부터 전달받은 props나 기존 상태에서 계산 가능한 값은 새로운 상태로 관리하면 안 된다.

문제예시1. props를 상태로 복사한 경우

import { useState } from "react";

type UserEmailProps = {
  initialEmail: string;
};

function UserEmail({ initialEmail }: UserEmailProps) {
  // ❌ props 값을 별도 상태로 복사
  const [email, setEmail] = useState(initialEmail);

  const onChangeEmail = (e: React.ChangeEvent<HTMLInputElement>) => {
    setEmail(e.target.value);
  };

  return (
    <div>
      <input type="text" value={email} onChange={onChangeEmail} />
    </div>
  );
}
  • initialEmail이 바뀌어도 email 상태는 자동으로 갱신되지 않는다.
  • useEffect로 동기화를 시도하면, 사용자의 입력과 부모 데이터가 충돌할 수 있다. (사용자가 수정한 값이 부모의 변경으로 덮어써질 위험)
  • 즉, 두 개의 출처(initialEmail, email) 가 생겨서 SSOT가 깨진다.

해결 방법: 상태 끌어올리기

  • 상태를 하위 컴포넌트에 두지 말고, 상위 컴포넌트로 끌어올려(Lifting State Up) 단일 출처(props)로 관리한다.
  • 자식은 부모의 setEmail을 호출해 부모 상태를 갱신한다.
    import { useState } from "react";

type UserEmailProps = { email: string; setEmail: React.Dispatch<React.SetStateAction>; };

// 상태를 부모로부터 props로 받기만 함 (출처는 부모 하나) function UserEmail({ email, setEmail }: UserEmailProps) { const onChangeEmail = (e: React.ChangeEvent) => { setEmail(e.target.value); };

return (

); }

// 부모 컴포넌트: 상태의 "단일 출처" function ParentComponent() { const [email, setEmail] = useState("example@email.com");

return (

사용자 이메일 수정

현재 이메일: {email}

); }

export default ParentComponent;


#### 문제예시2. 내부 상태끼리 동기화한 경우
```ts
const [items, setItems] = useState<Item[]>([]);
const [selectedItems, setSelectedItems] = useState<Item[]>([]);

useEffect(() => {
  setSelectedItems(items.filter(item => item.isSelected));
}, [items]);
  • items와 selectedItems가 서로 다른 출처로 존재해 동기화 누락·불일치·추적 어려움이 발생할 수 있다.
  • 단순히 계산 가능한 값인데, 별도의 상태로 관리하면서 불필요한 렌더링이 추가된다.

해결 방법: 계산된 값으로 처리

  • selectedItems를 상태로 두지 말고, 계산된 값으로 처리한다.
  • 변수에 계산 결과를 담으면 리렌더링 횟수를 줄일 수 있다.
    const selectedItems = items.filter(item => item.isSelected);
  • 계산 비용이 크다면 성능 문제가 발생할 수도 있기 때문에 useMemo로 최적화한다.
  • items가 변경될 때만 계산을 수행하고 결과를 메모이제이션하여 성능을 개선할 수 있다.
    const selectedItems = useMemo(
() => veryExpensiveCalculation(items),
[items]
);

useState vs useReducer, 어떤 것을 사용해야 할까

useState는 단순한 상태 관리에는 충분하지만, 상태구조가 복잡해지거나 여러 필드가 서로 연관될 땐 관리가 어려워진다. 이럴 땐 useReducer를 사용하는 것이 더 안전하고 명확하다.

useReducer 사용을 권장하는 경우는 크게 2가지가 있다.

  1. 하위 필드가 많은 복잡한 상태 로직을 다룰 때 → 여러 속성을 가진 객체 상태를 관리할 때

  2. 다음 상태가 이전 상태에 의존할 때 → “size가 바뀌면 page를 0으로 초기화해야 한다”처럼 상태 간 규칙(비즈니스 로직)이 존재할 때

복잡한 검색 쿼리 상태 관리 상황

리뷰를 필터링하는 검색 기능을 만든다고 가정해보자.

정보를 필터링해서 보여주기 위한 쿼리를 상태로 저장해야 할 것이다. 이러한 쿼리는 단순하지 않고 검색 날짜, 리뷰 점수, 키워드 등 많은 하위 필드를 가지게 된다. 페이지네이션까지 고려한다면 페이지, 사이즈 등의 필드도 추가될 수 있다.

type ReviewRatingString = '1' | '2' | '3' | '4' | '5';

interface SearchParams {
    startDate: Date;
    endDate: Date;
    rating: ReviewRatingString[];
    keywords: string[];

  // 이외 기타 필터링 검색 옵션
}

interface SearchState {
    filter: SearchParams;
    page: string;
    size: number;
}

문제: useState 관리의 한계

이러한 데이터 구조를 useState로 다루면 상태를 업데이트할 때마다 잠재적인 오류 가능성이 증가한다. 예를 들어 page 값만 업데이트하고 싶어도 우선 전체 데이터를 가지고 온 다음 page 값을 덮어쓰게 되므로 size나 filter 같은 다른 필드가 수정될 수 있어 의도치 않은 오류가 발생할 수 있다.

또한, 'size 필드를 업데이트할 때는 page 필드를 0으로 설정해야 한다.' 등의 특정한 업데이트 규칙이 있다면 useState만으로는 한계가 있다. 이럴때는 useReducer를 사용하는게 좋다.

useReducer는 '무엇을 변경할지'와 '어떻게 변경할지'를 분리하여 dispatch를 통해 어떤 작업을 할지를 액션으로 넘기고 reducer 함수 내에서 상태를 업데이트하는 방식을 정의한다. 이로써 복잡한 상태 로직을 숨기고 안정성을 높일 수 있다.

해결: useReducer로 상태 변경 로직을 명확히 분리

1. Action(무엇을 할지) 정의 

type Action =
 | { type: 'filter'; payload: SearchParams }
 | { type: 'navigate'; payload: string }
 | { type: 'resize'; payload: number }
  • 'filter' → 새로운 검색 조건으로 필터링
  • 'navigate' → 페이지 이동
  • 'resize' → 페이지 크기 변경

2. Reducer(어떻게 할지) 정의

const reducer: React.Reducer<SearchState, Action> = (state, action) => {
    switch (action.type) {
        case 'filter':
        // 필터가 바뀌면 페이지를 0으로 초기화
            return { ...state, filter: action.payload, page: 0 };

       case 'navigate':
      // 페이지 이동
        return { ...state,  page: action.payload };

      case 'resize':
        // 페이지 크기 변경 시, page도 0으로 초기화
       return { ...state, page: 0, size: action.payload };

      default:
            return state;
    }
}

3. useReducer 사용

const [state, dispatch] = useReducer(reducer, getDefaultState());
  • state → 현재 상태 (SearchState)
  • dispatch(action) → 상태 변경을 요청하는 함수

4. dispatch로 상태 변경하기 

// dispatch 예시 
dispatch({ payload: filter, type: "filter" })
dispatch({ payload: 3, type: "navigate" })
dispatch({ payload: 20, type: "resize" })

이처럼 무엇을 변경할지(action)만 전달하면, 어떻게 변경할지는 reducer내부에서 일관적으로 처리된다. 즉, 상태 변경 로직이 한 곳으로 모여 있어 안전하고 추적이 쉽다.

구분 useState useReducer
상태 구조 단순 (원시값) 복잡한 객체 구조
상태 간 규칙 관리 어려움 reducer에서 일관 처리 가능
코드 중복 많음 (매번 스프레드 연산) 최소화 (action 기반)
유지보수성 낮음 높음 (로직 집중)

전역 상태 관리

어떤 상태를 컴포넌트 내부에서만 사용하는게 아니라 다른 컴포넌트와 공유할 수 있는 전역 상태로 사용하는 방법은 크게 리액트 Context API를 사용하는 방법과 외부 상태 관리 라이브러리를 사용하는 방법이 있다.

Context API + useState / useReducer

Context API는 다른 컴포넌트들과 데이터를 쉽게 공유하기 위한 목적으로 제공되는 API이다.

  • 깊은 레벨의 컴포넌트 사이에 데이터를 전달하는 Prop Drilling 같은 문제를 해결하기 위한 도구로 활용된다.
  • Context API는 엄밀히 말하면 전역 상태 관리를 위한 솔루션보단, 여러 컴포넌트 간에 값을 공유하는 솔루션에 가깝다.
  • useState나 useReducer 같이 지역 상태를 관리하기 위한 API와 결합하여 상태를 공유하기 위한 방법으로 사용되기도 한다.

Context API 활용팁: 유틸리티 함수를 정의하여 더 간단한 코드로 컨텍스트와 훅을 생성

  • 자주 사용되는 Provider와 해당 컨텍스트를 사용하는 훅을 간편하게 생성하여 생산성을 높일 수 있다.
  • 대규모 애플리케이션이나 성능이 중요한 애플리케이션에서 권장되지 않는 방법이다. 왜냐하면 Context Provider의 props로 주입된 값이나 참조가 변경될 때마다 해당 컨텍스트를 구독하고 있는 모든 컴포넌트가 리렌더링되기 때문이다.
  • 물론 Context를 생성할 때 관심사를 잘 분리해서 구성하면 리렌더링 발생을 최소화할 수는 있겠지만, 애플리케이션이 커지고 전역 상태가 많아질수록 불필요한 리렌더링과 상태의 복잡도가 증가한다.
]]> <![CDATA[useState, useEffect, useRef 훅 잘쓰는법]]> https://velog.io/@dyeon-dev/useState-useEffect-useRef-%ED%9B%85-%EC%9E%98%EC%93%B0%EB%8A%94%EB%B2%95 https://velog.io/@dyeon-dev/useState-useEffect-useRef-%ED%9B%85-%EC%9E%98%EC%93%B0%EB%8A%94%EB%B2%95 Mon, 20 Oct 2025 23:15:28 GMT 리액트에 훅이 추가(리액트 16.8 버전)되기 이전에는 클래스 컴포넌트에서만 상태를 가질 수 있었다. componentDidMount, componentDidUpdate와 같이 하나의 생명주기 함수에서만 상태 업데이트에 따른 로직을 실행시킬 수 있었다.

리액트 훅이 추가되면서 함수 컴포넌트에서도 클래스 컴포넌트와 같이 컴포넌트의 생명주기에 맞춰 로직을 실행할 수 있게 되었다.

  • 비즈니스 로직 재사용
  • 작은 단위로 코드 분할 테스트 용이
  • 사이드 이펙트와 상태를 관심사에 맞게 분리

useState

리액트 함수 컴포넌트에서 상태(status)를 관리하기 위해 useState 훅을 활용할 수 있다. useState 훅을 사용하면 함수형 컴포넌트에서도 상태를 유지하고, 이 상태값이 업데이트 될 때마다 컴포넌트가 자동으로 리렌더링 된다.

useState는 무엇을 반환하나

React의 useState는 다음 두 가지를 반환한다.

const [state, setState] = useState(initialValue);
  • state: 현재 렌더링 시점의 상태값 (즉, 화면에 보이는 값)
  • setState: 상태를 바꾸도록 React에게 요청(scheduling) 하는 함수

React는 함수형 컴포넌트가 한 번 렌더링될 때마다 고정된 state 스냅샷을 사용한다. 즉, setState()를 호출해도 그 자리에서 state가 즉시 상태를 바꾸지 않는다.

예시를 통해 이해해보자.

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

function handleClick() {
  setCount(count + 1);
  console.log(count); // 여전히 0, 바로 바뀌지 않음 
}
  • setCount(count + 1)을 실행하면 React가 “이 컴포넌트를 다시 렌더링해야겠다” 하고 업데이트를 예약(scheduling) 한다. → 실제로 count가 변경된 상태는 “다음 렌더링 때” 반영된다. 그래서 React의 상태 업데이트는 비동기적(asynchronous) 으로 작동한다.

이 비동기적 특성 때문에, 이전 상태를 기준으로 새 상태를 계산해야 하는 경우 (prevState) => newState 형태를 써야 정확한 결과를 얻는다.

setCount(prev => prev + 1);
setCount(prev => prev + 1);
setCount(prev => prev + 1);
// 결과적으로 count가 +3이 됨

실제 useState의 튜플을 살펴보자

function useState<S>(
  initialState: S | (() => S)
): [S, Dispatch<SetStateAction<S>>];

type Dispatch<A> = (value: A) => void;
type SetStateAction<S> = S | ((prevState: S) => S);
  • useState가 반환하는 튜플의 첫번째 요소는 현재 상태값으로, 제네릭으로 지정한 S 타입이다.
  • 두번째 요소는 컴포넌트에서 상태를 업데이트할 수 있는 Dispatch의 함수이다.
  • Dispatch 함수의 제네릭으로 지정한 SetStateAction에는 useState로 관리할 상태 타입인 S 또는 이전 상태 값을 받아 새로운 상태를 반환하는 함수인 (prevState: S) => S)가 들어갈 수 있다.

이처럼 함수형 업데이트를 사용하면 실제로 비동기적으로 동작하는 상태 업데이트를 이전 상태값을 ‘동기적으로 참조’해서 계산할 수 있다.

useState의 사용팁: 하나의 컴포넌트 안에 useState를 여러 개 쓸 수 있다. 그런데 useState가 많다는건 컴포넌트의 역할이 크다는 뜻이다. 즉, 의존되는 컴포넌트가 많은 것이기 때문에 수정할 필요가 있을 수 있다.

useEffect

useEffect는 렌더링 이후 리액트 함수 컴포넌트에 어떤 일을 수행해야 하는지 알려주기 위해 등록하는 함수이다. DependencyList라는 의존성 배열을 사용한다.

useEffect 타입 정의를 살펴보자

function useEffect(effect: EffectCallback, deps?: DependencyList): void;

type DependencyList = readonly unknown[];
type EffectCallback = () => void | Destructor;

EffectCallback

  • 첫번째 인자이자 effect의 타입인 EffectCallback은 Destructor를 반환하거나 아무것도 반환하지 않는 함수이다.
  • Promise 타입은 반환하지 않으므로 useEffect의 콜백함수에는 비동기 함수가 들어갈 수 없다. 비동기 함수를 호출한다면 경쟁 상태를 불러일으킬 수도 있다.

deps

  • 두번째 인자인 deps는 옵셔널하게 제공되고 effect가 수행되기 위한 조건을 나열한다.

  • deps가 변경되었는지를 얕은 비교로만 판단하기 때문에, 실제 객체 값이 바뀌지 않았더라도 객체의 참조 값이 변경되면 콜백 함수가 실행된다.

    type SomeObject = {
  name: string;
  id: string;
}
interface LabelProps {
  value: SomeObject;
}

const Label: React.FC<LabelProps> = ({ value }) => {
  useEffect(() => {
    // value.name과 value.id를 사용해서 작업한다
  }, [value]);
}

    → 부모에서 받은 인자를 직접 deps로 작성한 경우, 원치 않는 렌더링이 발생할 수 있다. 이를 방지하기 위해 실제 사용되는 값을 useEffect의 deps로 사용해야 한다.

    const Label: React.FC<LabelProps> = ({ value }) => {
  useEffect(() => {
    // value.name과 value.id 대신 name, id를 직접 사용한다
  }, [value.name]);
}

이처럼 useEffect는 Destructor를 반환하는데 이것은 마운트가 해제될 때 실행하는 함수이다.

  • deps가 빈배열일 때는 useEffect의 콜백 함수는 컴포넌트가 처음 렌더링될 때만 실행되고, Destructor(클린업 함수)는 컴포넌트가 마운트 해제될 때 실행된다.
  • deps 배열이 있다면, 배열 값이 변경될 때마다 Destructor가 실행된다.

비동기로 처리되는 useEffect

useEffect도 마찬가지로 비동기로 동작하기 때문에 선언을 먼저 해도 레이아웃 배치와 화면 렌더링이 모두 완료된 후에 실행된다. 그런데 만약 name을 지정하는 setName이 오랜 시간이 걸린 후에 실행된다면? → 사용자는 빈 이름을 오랫동안 보고 있어야 할 것이다.

이런 문제를 해결하기 위해 useLayoutEffect 훅을 사용할 수 있다.

동기적으로 처리되는 useLayoutEffect

useLayoutEffect는 화면이 렌더링 되기 전에 콜백 함수를 실행한다. useEffect는 비동기로 동작해서 화면 업데이트를 방해하지 않지만, 동기적인 방식이 필요하다면 useLayoutEffect를 사용하면 된다.

useEffect의 사용팁: useEffect내의 deps를 올바르게 명시하지 않아서 발생하는 사이드 이펙을 해결하는 것이 더 많은 비용이 발생할 수 있다. 따라서 사용하는 방식을 올바르게 익혀두도록 하자. (useEffect 사용을 지양하는 방법도 있음)

useRef

useRef로 관리되는 변수는 값이 바뀌어도 값을 기억하고 있어 재렌더링이 발생하지 않는다. 

const ref = useRef(initialValue);
  • React는 ref를 렌더링 간에도 “같은 객체로 유지”시켜준다.
  • 즉, ref.current 안의 값은 렌더링 사이에서도 사라지지 않고 유지된다.

useState와 useRef 차이

구분 useState useRef
값 변경 시 렌더링? 다시 렌더링됨 렌더링 안 됨
언제 읽을 수 있나? 다음 렌더 후에 즉시 읽을 수 있음
주 사용 목적 화면 상태(UI 값) 렌더링과 무관한 값, DOM, 타이머 등

값을 보존하는 상자

useRef는 useState와 다르게 렌더링과 무관한 값을 기억해야 할 때 사용된다.

ex)

  • 이전 상태 기억하기

    const prevValue = useRef<number>();
useEffect(() => {
prevValue.current = count; // 이전 값 저장
}, [count]);

  • 타이머 ID 저장하기

    const timeoutId = useRef<number>();
timeoutId.current = window.setTimeout(...);

  • 렌더링 횟수 카운트

    const renderCount = useRef(0);
renderCount.current += 1;
console.log("렌더 횟수:", renderCount.current);

DOM 요소에 접근할 때 사용

React는 기본적으로 “선언적 UI” 방식이다. 직접 DOM을 조작하는 대신, 상태(state)가 바뀌면 React가 알아서 DOM을 업데이트한다. 그런데 특정 상황에서는 React의 자동 업데이트보다 더 직접적인 제어가 필요할 때가 있다. 이럴 때 “실제 DOM 노드에 접근” 해야 한다.

<input /> 요소에 foucs를 설정하거나 특정 컴포넌트의 위치로 스크롤 하는 등의 DOM요소에 직접 접근해야 할 때 사용할 수 있다.

function SearchInput() {
  const inputRef = useRef<HTMLInputElement>(null);

  useEffect(() => {
    // 컴포넌트가 마운트되면 자동 포커스
    inputRef.current?.focus();
  }, []);

  return <input ref={inputRef} placeholder="검색어 입력" />;
}
  • React가 <input> 엘리먼트를 렌더링
  • 해당 DOM 요소를 inputRef.current에 저장
  • 이후 직접 inputRef.current.focus() 호출

→ React가 대신 해줄 수 없는, “DOM API 호출” (focus, scroll, measure 등) 을 직접 수행할 수 있게 된다.

DOM 접근이 필요한 경우

상황 사용하는 이유
입력창 포커스 자동 focus(), blur() 제어
스크롤 제어 특정 위치로 scrollIntoView()
요소 크기/좌표 측정 getBoundingClientRect() 로 위치 계산
캔버스/비디오 제어 <canvas>, <video> 의 내부 API 직접 제어
외부 라이브러리 연동 chart.js, mapbox 등 React 외부 DOM이 필요한 라이브러리 접근

일반적인 경우에는 DOM에 직접 접근하는 것은 권장하지 않는다.

]]> <![CDATA[Debounce과 Throttle을 활용한 최적화]]> https://velog.io/@dyeon-dev/Debounce%EA%B3%BC-Throttle https://velog.io/@dyeon-dev/Debounce%EA%B3%BC-Throttle Thu, 02 Oct 2025 17:03:57 GMT Debounce

디바운스는 짧은 시간 동안 동일한 이벤트가 연속적으로 발생할 때, 마지막 이벤트만 실행되도록 하는 기법으로 성능 최적화에 자주 사용된다. 많은 이벤트가 발생하는 상황에서 불필요한 함수 호출을 줄이고, 최종 입력이나 동작만 반영하고 싶을 때 활용된다.

활용 예시

1) 검색 자동완성 사용자가 키보드를 입력할 때마다 API 요청을 보내면 서버 부하가 크다. 디바운스를 적용하면 입력이 멈춘 뒤 일정 시간이 지난 후에만 검색 요청을 보낸다. 2) 입력 검증 (Form Validation) 이메일, 비밀번호 등 실시간 입력 검증 시 매 글자마다 검증하지 않고, 입력이 멈춘 후에만 검증 로직을 실행한다. 3) 마우스 Hover 기반 UI 처리 마우스 이동 시 mousemove 이벤트는 매우 빈번하게 발생한다. 예: 특정 UI에서 마우스를 올리면 다른 데이터가 노출될 때, 디바운스를 적용하여 불필요한 연속 호출을 막는다. 실제 사례: 과거 아마존은 마우스 움직임의 x, y 좌표 기울기를 계산해 좌우 45도 기울기 기준으로 스와이핑과 스크롤을 구분, 스크롤 동작일 경우 스와이프 기능을 preventDefault()로 막는 방식에 디바운스를 활용했다. 4) 윈도우 리사이즈 이벤트 처리 브라우저 창 크기를 변경하면 resize 이벤트가 매우 자주 발생한다. 디바운스를 적용해 최종적으로 크기 변경이 끝난 뒤 일정 시간 후에 한 번만 실행되도록 할 수 있다. 예: "창 크기 변경 후 2초가 지나면 레이아웃 다시 계산" 같은 방식.

디바운싱 간단 예시 코드(ts)

  titleInput?.addEventListener('input', debounce(function(e: Event) {
    console.log(e.target.value)
  }, 300))

  const debounce = <E extends Event>(fn: (e: E) => void, delay: number) => {
    let timer: number | undefined;
    return (e: E) => {
      if (timer) clearTimeout(timer);
      timer = window.setTimeout(() => fn(e), delay);
    };
  };
  1. input 이벤트 등록
    사용자가 입력 필드에 값을 입력할 때마다 input 이벤트가 발생하고, 이 이벤트를 addEventListener로 감지한다.
  2. debounce 래퍼 적용
    이벤트 핸들러로 바로 함수를 전달하는 대신, debounce 함수로 감싼 핸들러를 전달한다. 이렇게 하면 입력이 연속으로 빠르게 발생해도 최종 입력 후 일정 시간 동안 추가 입력이 없을 때만 실제 함수가 실행된다.
  3. 타이머 관리
    debounce 내부에서는 setTimeout을 사용해 지정된 지연 시간(delay) 이후에 콜백을 실행한다. 새로운 이벤트가 발생하면 이전에 설정된 타이머를 clearTimeout으로 취소하고, 다시 타이머를 설정한다. 따라서 마지막 입력만 유효하게 처리된다.
  4. 실제 콜백 실행
    지연 시간이 모두 지나면 fn(e)가 실행된다.
    • 여기서 e는 input 이벤트 객체이며, e.target은 이벤트가 발생한 input 요소를 가리킨다.
    • 따라서 e.target.value를 통해 사용자가 최종적으로 입력한 텍스트 값을 얻을 수 있다.
    • 이렇게 하면 사용자가 키보드를 빠르게 입력할 때마다 매번 실행되지 않고, 최종적으로 멈춘 시점의 값만 처리된다.

Throttle

쓰로틀(throttle)은 짧은 시간 동안 동일한 이벤트가 연속적으로 발생할 때, 일정 주기마다 한 번씩만 실행되도록 하는 기법이다. debounce와 비슷한 개념이지만, throttle은 일정 주기마다 함수를 실행하는 방식이라는 점에서 차이가 있다. throttle의 설정 시간으로 100ms를 주게 되면, 해당 이벤트는 100ms 동안 최대 한 번만 발생하게 된다. 즉 마지막 함수가 호출된 후 일정 시간이 지나기 전에 다시 호출되지 않도록 한다. 디바운스와 달리 “마지막 이벤트만 실행”하는 것이 아니라, 일정 간격을 두고 주기적으로 실행하는 점이 특징이다.

활용 예시

1) 스크롤 이벤트 처리 스크롤할 때 scroll 이벤트는 수십~수백 번씩 연속 발생한다. 스크롤 위치에 따라 헤더 숨김/노출, 무한 스크롤 데이터 로드 등을 처리할 때 쓰로틀을 적용하면 0.2초 간격마다 실행되도록 제한할 수 있다. 2) 마우스 이동(mousemove) 이벤트 드래그 앤 드롭 구현 시 마우스를 조금만 움직여도 이벤트가 과도하게 발생한다. 쓰로틀을 적용해 일정 간격마다 좌표를 갱신하면 부드럽게 UI를 업데이트할 수 있다. 3) 페이지네이션 (버튼 기반 로드) 사용자가 버튼을 너무 빨리 여러 번 클릭하는 경우, API가 중복 호출될 수 있다. 쓰로틀을 적용해 1초에 1번만 클릭 이벤트 처리되도록 제한하면 서버 요청을 보호할 수 있다. 4) 리사이즈 중간 값 반영 디바운스는 보통 리사이즈가 끝난 후 한 번 실행되지만, 쓰로틀은 리사이즈가 진행되는 동안에도 0.5초 간격으로 레이아웃 계산 같은 작업을 수행할 수 있다. 즉, 사용자에게 실시간에 가까운 피드백을 주면서도 성능 부담을 줄일 수 있다.

쓰로틀링 간단 예시 코드(ts)

 // throttle 유틸 함수
const throttle = <E extends Event>(fn: (e: E) => void, limit: number) => {
  let waiting = false;

  return (e: E) => {
    if (!waiting) {
      fn(e); // 즉시 실행
      waiting = true;
      setTimeout(() => {
        waiting = false; // 일정 시간 후 다시 실행 가능
      }, limit);
    }
  };
};

// 사용 예시: 스크롤 이벤트
const scrollHandler = throttle((e: Event) => {
  console.log("현재 스크롤 위치:", window.scrollY);
}, 500);

window.addEventListener("scroll", scrollHandler);
  1. 이벤트 등록
    scroll 이벤트에 throttle로 감싼 함수를 등록한다.
  2. 즉시 실행 & 대기 상태 진입
    이벤트가 발생했을 때 waiting이 false라면 fn(e)를 실행하고, waiting을 true로 바꾼다.
  3. 지정된 시간 동안 무시
    setTimeout을 사용해 일정 시간(limit) 동안은 새로운 이벤트를 무시한다.
  4. 재실행 가능 상태로 전환
    limit 시간이 지나면 waiting을 false로 되돌려 다시 실행할 수 있다.

debounce vs throttle 비교

debounce

  • 스크롤이 내리다가 스크롤을 멈추고 특정 시간 후 이벤트가 하나 발생한다.

    throttle

  • 이벤트가 하나 발생한 뒤 특정 시간동안 이벤트가 발생하지 않지만 그 시간이 지나면 다시 이벤트가 동작한다.

Leading edge vs Tradiling edge

debounce는 연이어 발생한 이벤트를 하나의 그룹으로 묶어서 처리하는 방식으로, 주로 처음이나 마지막으로 실행된 함수를 처리하는 방식으로 사용된다. debounce의 예시 코드는 마지막으로 실행된 함수를 처리하는 방식이고, 처음은 다루지 않았다. debounce의 개념으로 이벤트의 처음이나 마지막을 처리하는 방식을 나눠서 살펴볼 수 있다.

Leading edge

  • 처음 실행하는 함수를 처리
  • 처음에 실행한 함수를 실행하고 그 뒤의 이벤트들을 무시함
  • 예시: 입력 필드에 '안녕하세요' 입력시 'ㅇ'만 요청이 보내짐
Tradiling edge
  • 가장 마지막에 실행하는 함수를 처리
  • 마지막에 실행한 함수를 실행하고 그 전의 이벤트들을 무시함

Debounce Leading edge vs Trottle 차이

요청이 들어왔을 때 그 후 일정 시간 동안 모든 요청을 무시한다는 것에서 Leading edge과 Trottle 작동이 유사하기도 하다. 그렇다면 이 두 개는 어떤 차이가 있는걸까?

Debounce Leading edge

  • 설정한 타이머 시간 안에 요청이 지속적으로 들어올 경우 모든 요청을 무시하게 된다.

Trottle

  • 반면에 Trottle은 지속적으로 요청이 들어올 경우 정해진 타이머 시간이 지나면 요청을 허용한다.

디바운싱 적용해보기

디바운싱을 간단하게 Tradiling edge 방식으로 글자수 계산에 적용해보았다. 디바운싱을 0.3초로 설정해두어 매번 요청하는 부하를 줄일 수 있었다.

]]> <![CDATA[OSI 7 Layer의 역할을 파악하자]]> https://velog.io/@dyeon-dev/OSI-7-Layer%EC%9D%98-%EC%A0%84%EC%86%A1 https://velog.io/@dyeon-dev/OSI-7-Layer%EC%9D%98-%EC%A0%84%EC%86%A1 Thu, 02 Oct 2025 08:20:52 GMT

학습목표: OSI 7계층에서 각각 어떤 역할을 하는지 명확하게 파악한다.

  • 각 계층의 데이터 전송 단위 / 목적지 식별 방법 / 물리적 하드웨어에 대해 이해한다.

이전까지 OSI 7 계층 중에서 응용계층을 중점적으로 학습하고 구현했었다. 웹 개발을 하다보면 사용자와 밀접하게 닫는 부분이기도 하고 여러 네트워크 서비스를 제공하는 계층이기 때문에 응용 계층을 가장 많이 접할 수 밖에 없다. 그런데 개발자는 다양한 상황의 오류를 마주할 수 있기 때문에 네트워크 통신에 대한 내용도 알아야 한다.

따라서 네트워크 통신이 일어나는 과정을 7단계로 나눈 네트워크 참조모델인 OSI 7 계층에 대해 알아보자.

🌐 OSI 7 계층 정리

네트워크 참조모델에서 각각의 계층이 하는 일은 명확하게 정해져있다. 따라서 계층별 목적에 맞는 프로토콜과 장비를 구성하면 네트워크의 구성과 설계, 문제 진단과 해결이 용이해진다.

1. 물리 계층(Physical Layer)

  • 역할: 비트 신호를 유무선 통신 매체를 통해 운반하는 계층
  • 데이터 단위: 비트(0, 1로 이루어진 신호로 구성)
  • 목적지 식별: 없음(단순 신호 전달)
  • 관련 하드웨어: 허브, 리피터, 케이블, 커넥터, NIC(물리적 부분)
  • 역할: 같은 LAN에 속한 호스트끼리 올바르게 정보를 주고받기 위한 계층
  • 데이터 단위: 프레임 (Frame)
  • 목적지 식별: MAC 주소 (물리적 주소, 48비트)
  • 관련 하드웨어: 스위치, 브리지, NIC(논리적 부분)

같은 네트워크에 속한 호스트를 식별할 수 있는 주소(MAC 주소)를 사용하고, 물리계층을 통해 주고받는 정보에 오류를 식별한다.

3. 네트워크 계층 (Network Layer)

  • 역할: LAN을 넘어 다른 네트워크와 통신을 주고받기 위해 필요한 계층
  • 데이터 단위: 패킷 (Packet)
  • 목적지 식별: IP 주소
  • 관련 하드웨어: 라우터, L3 스위치

네트워크 통신 과정에서 호스트를 식별할 수 있는 주소(IP 주소)가 필요하다.

3계층까지는 물리적 계층이었기 때문에 관련 하드웨어가 존재했고, 4계층부터는 소프트웨어적 계층이기 때문에 소프트웨어 프로토콜과 관련이 있다.

4. 전송계층 (Transport Layer)

  • 역할: 네트워크를 통해 송수신되는 패킷은 전송 도중에 유실되거나 순서가 뒤바뀔 때도 있는데, 전송 계층은 이러한 상황에 대비해 신뢰성 있는 전송을 가능하게 하는 계층
  • 데이터 단위: 세그먼트 (Segment, TCP) / 데이터그램 (Datagram, UDP)
  • 목적지 식별: 포트(Port) 번호
  • 대표 프로토콜: TCP, UDP
  • 특징: 방화벽, 로드밸런서와 밀접

포트(Port) 정보를 통해 특정 응용 프로그램과의 연결 다리 역할을 수행하는 계층이다.

5. 세션 계층 (Session Layer)

  • 역할: 응용 프로그램 간의 연결 상태를 의미하는 세션(Session)을 관리하기 위한 계층
  • 데이터 단위: 데이터 (Data)
  • 목적지 식별: 세션 ID, 소켓 (IP + Port 조합)
  • 대표 프로토콜: RPC, NetBIOS

프로그램 간의 연결 상태를 유지하거나 새롭게 생성하거나 연결을 끊는 역할을 수행한다.

6. 표현 계층 (Presentation Layer)

  • 역할: 인코딩, 압축, 암호화와 같은 작업을 수행하며 번역가와 같은 역할을 하는 계층
  • 데이터 단위 (PDU): 데이터 (Data)
  • 목적지 식별: 없음 (데이터 변환만 담당)
  • 특징: JPEG, MP3, SSL/TLS 등의 데이터의 표현 방식 통일

7. 응용 계층 (Application Layer)

  • 역할: 사용자와 네트워크 서비스 간 인터페이스 제공
  • 데이터 단위: 데이터 (Data, Message)
  • 목적지 식별: 애플리케이션 식별자 (URL, 메일 주소 등)
  • 특징: HTTP, FTP, SMTP 등
계층 데이터 단위 목적지 식별 주요 역할 하드웨어 예시
7 응용 데이터 URL, 메일주소 사용자 서비스 -
6 표현 데이터 없음 암호화/압축 -
5 세션 데이터 세션 ID 연결 관리 -
4 전송 세그먼트/데이터그램 포트 번호 신뢰성, 흐름 제어 방화벽, LB
3 네트워크 패킷 IP 주소 라우팅, 경로 선택 라우터
2 데이터링크 프레임 MAC 주소 오류 검출, 프레임 전송 스위치, 브리지
1 물리 비트 없음 신호 전송 허브, 케이블

각 계층에 대해 살펴보았으니, 각 계층에 특징이 될만한 것들을 살펴보자!

물리계층, 데이터링크 계층의 통신 매체와 네트워크 장비

  • 통신 매체는 의외로 모든 성능의 기본이 되는 경우가 많다.
  • 연결 매체의 성능이 뒷받침되지 않으면 호스트의 빠른 속도는 아무런 효용이 없다.
    • 예를 들어, 호스트가 1초에 100GB를 송신할 수 있어도, 1초에 1GB씩 송수신 가능한 통신 매체를 사용하면 송수신이 불가능하다.

물리계층과 데이터링크 계층에 속한 다양한 네트워크 하드웨어

1. 유선 LAN - 이더넷

물리계층과 데이터링크 계층에는 LAN 내의 호스트들이 올바르게 정보를 주고받을 수 있게 해주는 이더넷이 있다.

  • 이더넷은 IEEE 802.3 이름으로 국제 표준화된 기술이다.
  • 이더넷 프레임은 프리앰블, 수신지 MAC 주소, 타입/길이, 데이터, FCS 등의 정보를 포함하고 있다.

개발자 입장에서 특정 이더넷 표준을 자세히 들여다봐야하는 상황은 많지 않지만, 다음 2가지 사항은 기억해두는 것이 좋다.

1) 오늘날의 (유선) LAN 대부분이 이더넷 표준을 따르기 때문에 대다수의 LAN 장비들이 특정 이더넷 표준을 따른다. 2) 이더넷 표준이 달라지면 통신 매체의 종류를 비롯한 신호 송수신 방법, 나아가 최대 지원 속도도 달라진다.

유선 통신 매체 - 트위스티드 페어(twisted pair cable) 케이블

  • 구리선을 통해 전기적으로 신호를 주고 받는 통신 매체
  • 두가닥(pair)씩 꼬아져있는(twisted) 구리선
  • 성능은 카테고리를 통해 알 수 있다.

이더넷 LAN 장비로 허브와 스위치가 있다. 허브와 스위치는 물리 계층과 데이터링크 계층의 중간 노드이다.

허브

  • 물리 계층에 존재
  • 여러 대의 호스트를 브로드캐스트로 연결한다.
  • 허브는 전달받은 신호를 모든 포트로 내보낸다.
  • 오늘날에는 허브 대신 스위치를 사용하는 경우가 많다.

스위치

  • 스위치는 허브의 한계를 보완하기 위한 데이터링크 계층의 네트워크 장비이다.
  • 스위치가 전달받은 신호를 원하는 포트에만 내보낼 수 있다.
  • MAC 주소 테이블을 만들어 참조를 통해 가능하다.
  • VLAN 기능을 통해 같은 스위치에 연결된 모든 호스트를 하나의 네트워크로 간주하고 싶지 않을 때, 여러 논리적인 네트워크로 나누고 싶을 때 사용한다.

2. 무선 LAN - WiFi

무선 통신 매체 - 전파와 WiFi

  • 전파는 약 3kHz부터 3THz 사이의 진동수를 갖는 전자기파를 의미한다.
  • 진동수 2.4GHz, 5GHz 정도는 알아두는 것이 좋다.
  • 주로 와이파이를 사용할 때 활용된다.

와이파이

  • IEEE 802.11 표준을 따르는 무선 LAN 기술이다.
  • 같은 지역 내에 2.4GHz / 5GHz 대역을 사용하는 무선 네트워크가 여러개 존재할 수 있다.

네트워크 계층 - IP

LAN을 넘어서 다른 네트워크와 통신을 주고받으려면 네트워크 계층 이상의 기술이 필요하다.

여기서 중요하게 사용되는 기술이 네트워크 계층의 핵심 프로토콜인 IP이다.

IP의 목적과 특징

목적은 크게 2가지이다.

  1. 주소 지정: 네트워크 간의 통신 과정에서 호스트를 특정하는 역할을 수행한다.
  • 패킷을 올바르게 전송하기 위해 송신지와 수신지의 IP 주소와 MAC 주소가 모두 필요하다.
  • MAC 주소보다는 IP 주소가 우선적으로 활용된다.
  • 서로 다른 네트워크에 속한 두 호스트가 네트워크 간 통신을 수행할 때 IP 주소를 바탕으로 패킷을 전달한다.
  • 이때 라우터 장비가 사용된다. 최적의 경로를 결정하고 해당 경로로 패킷을 내보낸다. (라우팅 과정)
  1. 단편화: 데이터를 여러 IP 패킷으로 쪼개어 보내는 역할을 수행한다.
  • MTU(Maximum Transmission Unit) 단위에 따라 패킷을 쪼애서 전송한다. - 최대 1500 바이트
  • 쪼개서 전송된 패킷들은 수신지에서 재조합된다.
  • IP 패킷 헤더: 식별자 / 플래그 / 단편화 오프셋

특징

  • 신뢰할 수 없는 통신이자, 비연결형 통신
  • 전송 계층의 TCP, UDP의 존재 목적과 직결된다.
  • 비연결형 프로토콜 - 상대 호스트의 수신 가능 여부는 고려하지 않고, 수신지를 향해 그저 패킷을 전송할 뿐

스위치와 라우터의 역할은 비슷하지만, 라우터는 ip자체로 제한(차단)을 둘수있다. 따라서 외부 ip주소를 관리가능하다. 현대에는 스위치도 발전을 해서 라우터의 역할까지 수행할 수 있다.

전송 계층 - TCP와 UDP

IP의 한계

IP는 네트워크 계층의 프로토콜로, "주소 지정"과 "패킷 전달/단편화" 까지만 책임진다. 하지만 다음은 책임지지 않는다.

  • 패킷이 도착했는지 보장하지 않음 (손실 가능)
  • 패킷이 순서대로 도착하는지 보장하지 않음 (라우팅 경로가 다르면 순서가 바뀔 수 있음)
  • 패킷이 중복될 수도 있음
  • 패킷의 무결성을 보장하지 않음 (손상될 수도 있음) 즉, IP만으로는 "데이터를 확실하게 전달한다"는 보장이 전혀 없다.

전송 계층의 TCP와 UDP가 존재하는 이유는, IP 혼자서는 통신 품질을 보장하지 못하기 때문이다.

TCP (Transmission Control Protocol)

목적: IP 위에서 신뢰성 있는 연결 제공 기능:

  • 연결 지향적 (3-way handshake로 세션 수립)
  • 데이터 전송 순서 보장 (시퀀스 번호)
  • 데이터 무결성 확인 (체크섬, 재전송)
  • 흐름 제어, 혼잡 제어

활용 예시: 웹(HTTP/HTTPS), 이메일(SMTP), 파일 전송(FTP)

즉, “IP가 불안정하니 내가 대신 신뢰성을 책임지겠다.”

UDP (User Datagram Protocol)

목적: IP의 단순, 빠른 성격을 그대로 활용 기능:

  • 비연결형, 확인/재전송 없음
  • 순서 보장 없음
  • 단순히 IP 주소 + 포트만 붙여서 보냄

활용 예시: 스트리밍, 게임, DNS

즉, “IP의 불안정성을 그대로 쓰지만, 대신 속도와 단순성을 확보하겠다.”

네트워크 상에서 호스트가 실행하는 프로세스를 어떻게 식별할 수 있을까? 포트 번호를 통해 식별할 수 있다. 네트워크 패킷을 주고받는 프로세스에는 포트 번호가 할당된다. 즉, IP주소 + 포트 번호를 통해 '특정 호스트가 실행하는 특정 프로세스'를 식별할 수 있다. 이러한 식별은 전송 계층(TCP, UDP)의 주된 목적이다. 192.168.0.15:8000 같은 포트번호를 헤더에서 명시하는 필드가 존재한다.

TCP의 연결 수립

TCP는 UDP와 달리 송수신 이전에 연결을 수립하고, 송수신 이후에는 연결을 종료한다. TCP는 패킷을 주고받기 전에 연결 수립 과정을 거친다. TCP의 연결 수립는 쓰리 웨이 핸드셰이크(Three-way-handshake)를 통해 이뤄진다.

  1. [송수신 방향 A -> B] SYN 세그먼트 전송
  2. [송수신 방향 B -> A] SYN+ACK 세그먼트 전송
  3. [송수신 방향 A -> B] ACK 세그먼트 전송

]]> <![CDATA[민감 정보를 담은 쿠키를 안전하게 보호하자!]]> https://velog.io/@dyeon-dev/%EB%AF%BC%EA%B0%90-%EC%A0%95%EB%B3%B4%EB%A5%BC-%EB%8B%B4%EC%9D%80-%EC%BF%A0%ED%82%A4%EB%A5%BC-%EC%95%88%EC%A0%84%ED%95%98%EA%B2%8C-%EB%B3%B4%ED%98%B8%ED%95%98%EC%9E%90 https://velog.io/@dyeon-dev/%EB%AF%BC%EA%B0%90-%EC%A0%95%EB%B3%B4%EB%A5%BC-%EB%8B%B4%EC%9D%80-%EC%BF%A0%ED%82%A4%EB%A5%BC-%EC%95%88%EC%A0%84%ED%95%98%EA%B2%8C-%EB%B3%B4%ED%98%B8%ED%95%98%EC%9E%90 Fri, 26 Sep 2025 02:51:58 GMT

학습 목표: 민감한 정보를 담은 쿠키를 안전하게 보호하기 위해 브라우저 레벨부터 서버 속성까지 다양한 방법을 학습한다.

웹 브라우저에 저장되는 쿠키

로그인을 진행하면서 세션-쿠키 방식으로 구현했다. 이때 세션ID를 브라우저의 쿠키에 저장하게 되고, 브라우저와 서버는 쿠키 정보를 주고받는다.

쿠키를 저장하는 공간을 전통적으로 쿠키 통(COOKIE_JAR)라고 부른다. 브라우저는 헤더로 Set-Cookie를 받으면 COOKIE_JAR를 업데이트 해야한다.

쿠키의 특징

  • 쿠키는 브라우저의 신원으로, 같은 도메인에서 동일한 쿠키가 사용된다. 그래서 동일한 쿠키를 사용하면 동일한 사용자라고 인식한다. 이는 보안 측면에서 문제가 될 수 있다.
  • 같은 도메인 내에서는 모든 API 요청에 자동으로 세션 쿠키가 포함된다.
  • 이는 개인 프라이빗 데이터가 유출되는 것이다.
  • 공격자가 서버나 브라우저를 이용해 쿠키를 탈취할 가능성이 있다.

쿠키의 한계

이렇게 보안 기능이 따로 없는 쿠키를 위해 실무적으로 방어를 해줘야한다.

  • 브라우저 레벨: SOP(기본), CORS 정책 적절 설정
  • 쿠키 옵션: HttpOnly, Secure, SameSite
  • 서버 쪽: CSRF 토큰, Origin/Referer 검사, 출력 이스케이프, CSP로 XSS 차단

동일 출처 정책(SOP)

일단 감사하게도, 브라우저 레벨에서 동일 출처 정책(SOP) 기능이 장착되어있다. 서버가 Set-Cookie로 세션을 내려주면 브라우저가 동일 출처로 자동 저장·전송한다. 동일 출처란 같은 origin, 같은 호스트명, 같은 포트를 가진 웹페이지에만 전송을 허용하는 것이다.

왜 SOP가 중요하냐면

  • SOP는 다른 출처(교차 출처)의 스크립트가 해당 응답을 읽지 못하게 막는다.
  • 즉, 공격자 페이지에서 요청을 보내는 것 자체는 (브라우저가 허용하면) 가능하더라도, 응답을 읽어 처리하는 단계를 차단함으로써 데이터 유출을 막는다. 이 방법으로, 웹사이트의 프라이빗 데이터가 그 웹사이트에만 유지되고 다른 서버의 공격자에게 유출되지 않을 수 있다.

SOP가 못막는 것

SOP는 교차 출처 간의 호출을 막지만, 이런 SOP가 막지 못하는 게 있다. 폼 전송과 같은 교차 사이트 요청 위조(CSRF) 공격을 가능하게 한다. 즉, 공격자가 사용자의 브라우저로 요청을 보내게 해서 쿠키는 자동으로 포함될 수 있는 것이다.

<!-- 공격자가 만든 페이지 -->
<form action="https://bank.example/add" method="POST">
  <input name="amount">
  <button>OK</button>
</form>

CSRF 방어

SOP의 한계로 인해 CSRF 방어(토큰, SameSite 등)가 필요하다. 폼 전송을 위한 안전한 솔루션은 SameSite 쿠키이다. 만약 서버가 자신의 쿠키를 SameSite로 설정해두면, 브라우저는 폼 전송이 교차 차이트일 때 그 쿠키를 전송하지 않는다.

  • Set-Cookie: SameSite=Lax
  • SameSite 속성은 Lax, Strict, None 3가지이다.
속성 교차 사이트 GET 요청 (링크 클릭 등) 교차 사이트 POST / AJAX / iframe 등 동일 사이트 GET/POST 요청 특징 / 주의점
Lax ✅ 쿠키 전송 (탑레벨 내비게이션의 안전한 GET은 허용) ❌ 쿠키 전송 안 함 ✅ 쿠키 전송 기본값. 일반적인 사용성(링크 통한 로그인 유지)과 보안을 균형 있게 지원
Strict ❌ 쿠키 전송 안 함 ❌ 쿠키 전송 안 함 ✅ 쿠키 전송 가장 보안 강력. 교차 사이트에서 들어오는 모든 요청에 쿠키 차단 → 외부 리디렉션(OAuth, 결제) 깨질 수 있음
None ✅ 쿠키 전송 ✅ 쿠키 전송 ✅ 쿠키 전송 교차 사이트 요청에도 항상 쿠키 전송. 반드시 Secure와 함께 사용해야 하고 CSRF 방어(토큰, Origin 검증 등) 필요.
외부 연동(소셜 로그인, 결제 콜백 등) 시 사용

XSS 공격의 방어막

  • HttpOnly
    • 브라우저 내부에서만 사용 (요청 시 자동 포함)
    • JS 코드에서는 접근 불가
  • Content-Security-Policy(CSP): 콘텐츠 보안 정책

콘텐츠 보안 정책

XSS 공격의 방어막 중 하나는 Content-Security-Policy(CSP) 헤더이다. 이 헤더의 전체 사양은 복잡하지만, 가장 단순한 예시는 default-src 키워드 뒤에 공백으로 구분된 서버 목록을 설정하는 것이다.

  • Content-Security-Policy: default-src 'self'

브라우저에게 리스트된 출처를 제외한 CSS, JS, 이미지 등 어떤 리소스도 로드하지 말라고 요청한다. 만약 공격자가 페이지에 <script>를 추가했더라도 브라우저는 그 스크립트를 로드하거나 실행하지 않는다.

[로그인 요청 시 세션-쿠키 설정]

]]> <![CDATA[WS + WAS 서버 Nginx로 배포하기(ft. 배포 스크립트)]]> https://velog.io/@dyeon-dev/WS-WAS-Nginx-%EB%B0%B0%ED%8F%AC https://velog.io/@dyeon-dev/WS-WAS-Nginx-%EB%B0%B0%ED%8F%AC Thu, 25 Sep 2025 21:39:53 GMT

학습 목적: WS 와 WAS 를 명확하게 책임/역할 별로 구분하는 것

학습 목적을 달성하기 위해 정적 컨텐츠는 Web Server, 동적 컨텐츠는 WAS가 담당하도록 했습니다. 쉽게 말해, WAS 앞단에 Web Server를 하나 둬서 효율적으로 서버 트래픽을 관리하는 것입니다.

브라우저에서 정적 컨텐츠를 만나면 Web Server는 WAS로 서빙하는 역할을 해주어야 합니다. 이러한 역할을 해주는 고성능 웹서버 프로그램인 Nginx를 사용했습니다.

배포를 위해 1) Nginx와 2) pm2를 설정해주고, 3) 배포 스크립트를 작성했어요. 🛠️

배포 환경

  • VMware Fusion
  • Ubuntu 24.04
  • 서버 스택
    • git
    • npm
    • pm2: 앱은 PM2로 127.0.0.1:3000에서 동작
    • Nginx: Node 3000 + Nginx 80

우분투 서버로 배포를 진행했고, 아래와 같은 로직으로 구성했습니다. 빌드 → Nginx 설정 적용 → 정적, 동적 컨텐츠 리버스 프록시 → pm2 프로세스로 WAS 실행

이 글에서 VMware 우분투 환경 설정 과정은 생략합니다.

1) Nginx 설정

우분투 서버에 Nginx 설치 및 시작

  • Ubuntu에서 Nginx를 설치하면 자동으로 systemd 서비스(nginx.service)에 등록됩니다.
  • 서버가 부팅될 때 systemd가 nginx를 기동합니다. → 즉, 기본적으로 OS 레벨에서 항상 실행 중이에요.
    sudo apt update
sudo apt install nginx -y
sudo systemctl enable nginx    # 부팅 시 자동 시작
sudo systemctl start nginx
sudo systemctl status nginx --no-pager # active (running) 상태여야 정상.

방화벽(ufw) 개방

sudo ufw allow 'Nginx Full'   # 80/443 허용
sudo ufw status

테스트

→ 설정 OK 나와야 함.
외부 브라우저에서 확인
http://172.30.1.86/
→ 기본 Nginx 웰컴 페이지가 보여야 정상.

동작 확인 (서버 → 외부 순서)

# Nginx가 80 포트 리슨 중인지
sudo ss -lntp 'sport = :80'

# Nginx 경유 헬스체크(프록시 OK 확인)
curl -i http://127.0.0.1/health

# 정적 파일 핑(있을 경우)
curl -I http://127.0.0.1/assets/

외부(맥)에서

http://172.30.1.86/health
http://172.30.1.86/

Nginx에 .conf 파일 만들기

sudo mkdir -p /etc/nginx/conf.d
sudo nano /etc/nginx/conf.d/codestargram.conf
.conf에서 리버스 프록시 설정 
# /etc/nginx/conf.d/codestargram.conf

# 앱(백엔드) 업스트림: PM2가 띄운 Node 서버
upstream codestargram_app { # 백엔드 서버(3000)를 논리적 그룹으로 묶는 곳
    server 127.0.0.1:3000;
    keepalive 64; # Nginx ↔ WAS 사이 연결 재사용. 요청마다 TCP를 새로 열지 않고, 성능/지연에 이점.
}

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;  # 어떤 Host로 오든(도메인/IP) 수신

    # 정적 빌드 자산 (Vite dist/assets)
    location /assets/ {
        alias /var/www/codestargram/repo/web-p3-codestargram2/dist/assets/;
        access_log off;
        expires 1y;
        # expires/Cache-Control로 강한 캐시 적용해 성능↑ (Vite의 해시 파일명과 궁합 좋음)
        add_header Cache-Control "public, max-age=31536000, immutable";
        try_files $uri =404;
    }

    # 헬스체크(앱으로 프록시) - 모니터링/로드밸런서가 이 경로를 주기적으로 호출해 상태 확인
    location = /health {
        proxy_pass http://codestargram_app;
        proxy_http_version 1.1;
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Connection        "";
    }

    # 나머지 모든 경로는 Node 앱으로 프록시
    location / {
        proxy_pass http://codestargram_app;
        proxy_http_version 1.1;

        # 표준 프록시 헤더
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Connection        "";
    }
}

📌 conf 흐름 클라이언트 요청 → Nginx :80 수신

  • /assets/* → Nginx가 직접 /var/www/codestargram/.../dist/assets/에서 파일 제공(고속·캐시 가능)
  • /health → Nginx가 PM2에서 띄운 Node.js WAS(127.0.0.1:3000)로 프록시
  • 나머지 /* (/login, /register, /api/...,그 외 모든 경로) → 전부 WAS(127.0.0.1:3000)로 프록시

Nginx 적용 시 장점

  • Nginx가 빠르게 캐시/서빙 → WAS 부하 감소
  • 동적/API는 프록시로 WAS에 전달 → 보안/구조 분리
  • 프록시 헤더로 진짜 IP/프로토콜을 WAS가 정확히 알 수 있음
  • upstream으로 확장성(멀티 WAS, 로드밸런싱) 확보

2) pm2 설정

pm2를 왜 사용할까?

PM2는 Process Manager의 약자로 NodeJS 프로세서를 관리하는 원활한 서버 운영을 위한 패키지입니다. 개발할 때 nodemon을 쓴다면, 배포할 때는 pm2를 씁니다.

  • 서버를 백그라운드에서 실행시켜 터미널을 닫아도 꺼지지 않음.
  • 서비스를 제공하고 있는 도중 서버가 다운되어도 서버를 다시 켜줌.
  • Node.js는 싱글 스레드 기반이지만, 멀티 코어 혹은 하이퍼 스레딩을 사용할수 있게 해줌.
  • 클라이언트로부터 요청이 올 때 알아서 요청을 여러 노드 프로세스에 고르게 분배함. (로드 밸런싱)

pm2 설정 파일 만들기 (ecosystem.config.js)

pm2를 보다 수월하게 관리하기 위해 ecosystem.config.js 라는 파일을 만들어 설정할 수 있습니다. 프로젝트 루트에 ecosystem.config.js을 생성합니다.

pm2 ecosystem # ecosystem.config.js 파일이 생성

저는 ESM을 사용중이었기 때문에 ecosystem.config.cjs 로 변경했습니다.

module.exports = {
  /* apps 항목은 pm2에 사용할 옵션을 기재 */
  apps : [{
    name: 'codestargram2', // app 이름 
    script: 'server/app.js', // 실행할 스크립트 파일
    cwd: __dirname,          // 레포 루트 기준 실행 (deploy.sh가 cd 후 실행)
    // 워칭(운영에서는 비활성)
    watch: false,
    // watch: ["server", "src"],       // 개발용: 필요 시 경로 지정
    // ignore_watch: ["node_modules", "logs", "dist"],

    // 로그
    merge_logs: true,
    time: true,
    out_file: "/var/www/codestargram/logs/out.log",
    error_file: "/var/www/codestargram/logs/error.log",

    env: {
      NODE_ENV: "production",
      PORT: 3000                      // Nginx upstream과 일치
    },
    env_development: {
      NODE_ENV: "development",
      PORT: 3000
    }
  }],
};

3) 배포 스크립트 작성 과정

1. 빌드

정적 컨텐츠를 Nginx를 통해 처리한다고 했습니다. 정적 컨텐츠 산출물을 위해 Vite의 빌드 과정이 필요합니다. Vite는 public/ 하위 파일을 그대로 dist/로 복사하고, 루트에 있는 index.html을 도입점으로 하여 dist/에 AST 기반 최적화를 통해 빌드 산출물을 생성합니다. 이걸 서버에서 사용할 수 있게끔 해야하기 때문에 코드를 서버로 전달해야합니다.

2. 코드 배포 방식

처음에는 코드 배포를 어떻게 할지부터 고민했습니다. 맥에 있는 프로젝트를 우분투 서버에서 배포 스크립트(deploy.sh)로 돌려야 했기 때문에 아래의 두 가지 방식 중에 고민했습니다.

옵션 A) Git 기반 (반복 배포용)

  • 서버가 Git clone으로 코드를 가져오는 구조
  • 로컬에서 푸시 → 서버에서 deploy.sh 실행만 하면 됨. (또는 GitHub Actions로 자동 실행)

옵션 B) rsync로 맥 → 서버 직접 동기화(즉시 적용용)

  • 맥의 폴더를 서버로 복사하는 구조
  • deploy.sh의 “git 변경 감지” 부분은 맞지 않으므로 건너뛰거나 비활성화해야 함.

옵션 A 선택

배포 스크립트가 git fetch / rev-parse를 쓰기 때문에, Git을 사용하는 구조가 깔끔합니다. 또한, 운영 환경에서는 항상 Git 저장소와 동기화된 코드로 빌드하는 게 가장 안전하다고 판단했습니다. 그래서 “로컬에서 코드 수정 → GitHub에 push → 서버에서 pull 후 빌드” 흐름을 기본 원칙으로 잡았습니다.

3. 배포 스크립트 작성

매번 수동으로 git pull, npm install, npm run build, pm2 restart 하는 건 번거롭고, 실수하기 쉽습니다. 그래서 이 과정을 하나로 묶은 자동화 스크립트(deploy.sh)를 만들기로 했습니다.

정리하면, “Git → 빌드 → 배포 → PM2 재시작 → 헬스체크 → 롤백 → Nginx 리로드” 전체 과정을 자동화한 파일입니다.

서버에서 직접 스크립트 파일을 만들어서 작성해도 되지만, 개발 편의성을 위해 프로젝트에서 스크립트를 작성하고 맥(로컬) 환경에 있는 배포 스크립트를 서버로 업로드 해주었습니다.

deploy.sh 

#!/usr/bin/env bash
set -euo pipefail

# ==========================
# 고정 설정
# ==========================
APP_NAME="codestargram2"
REPO_DIR="/var/www/codestargram/repo/web-p3-codestargram2"   # Git 작업 디렉토리
STATIC_DST="/var/www/codestargram/repo/web-p3-codestargram2/dist"    # Nginx 정적 자산 경로
HEALTH_URL="http://127.0.0.1:3000/health"                    # 앱 헬스체크 엔드포인트
RELEASES_DIR="/var/www/codestargram/releases"                # 빌드 산출물 보관
KEEP_RELEASES=5                                              # 보관 개수
NODE_ENV="production"

# 배포 브랜치
BRANCH="deploy"

# ==========================
# 유틸 함수
# ==========================
log() { printf "\033[1;36m[deploy]\033[0m %s\n" "$*"; }
err() { printf "\033[1;31m[error]\033[0m %s\n" "$*" >&2; }
die() { err "$*"; exit 1; }
need() { command -v "$1" >/dev/null 2>&1 || die "필요 명령어가 없습니다: $1"; }

# ==========================
# 전제 체크
# ==========================
need git; need npm; need pm2; need curl; need rsync
mkdir -p "$STATIC_DST" "$RELEASES_DIR"

[ -d "$REPO_DIR/.git" ] || die "REPO_DIR 경로가 Git repo가 아닙니다: $REPO_DIR"

log "USING REPO_DIR=$REPO_DIR, BRANCH=$BRANCH"
cd "$REPO_DIR"

# ==========================
# Git 동기화
# ==========================
log "원격 브랜치 존재 확인: origin/$BRANCH"
git ls-remote --exit-code --heads origin "$BRANCH" >/dev/null \
  || die "원격에 브랜치가 없습니다: origin/$BRANCH"

log "git fetch origin $BRANCH"
git fetch origin "$BRANCH"

LOCAL=$(git rev-parse HEAD || echo "UNKNOWN")
REMOTE=$(git rev-parse "origin/$BRANCH")

if [ "$LOCAL" = "$REMOTE" ]; then
  log "변경 사항 없음 → 종료"
  exit 0
fi

log "변경 사항 감지됨 (local=$LOCAL, remote=$REMOTE) → 원격 상태로 맞춤"
git reset --hard "origin/$BRANCH"

# ==========================
# 빌드
# ==========================
log "의존성 설치 (빌드용: dev 포함)"
if [ -f package-lock.json ]; then
  npm ci
else
  npm install
fi

log "빌드 실행"
export NODE_ENV="$NODE_ENV"
npm run build

# (선택) 런타임 최적화: dev 제거
log "런타임 최적화: devDependencies 제거"
npm prune --omit=dev


[ -d "dist" ] || die "dist 디렉토리가 없습니다. 빌드 스크립트를 확인하세요."

# ==========================
# 릴리스 보관 + 정적 자산 배포
# ==========================
TS=$(date +"%Y%m%d-%H%M%S")
RELEASE_DIR="$RELEASES_DIR/$TS"
log "릴리스 보관 디렉토리: $RELEASE_DIR"
mkdir -p "$RELEASE_DIR"
cp -R dist/* "$RELEASE_DIR/"

log "현재 정적 자산 백업 및 교체"
mkdir -p "$STATIC_DST/.backup"
if [ -n "$(ls -A "$STATIC_DST" 2>/dev/null || true)" ]; then
  rsync -a --delete "$STATIC_DST/" "$STATIC_DST/.backup/$TS/"
fi
rsync -a --delete "$RELEASE_DIR/" "$STATIC_DST/"

# 오래된 릴리스 정리
log "오래된 릴리스 정리(최신 ${KEEP_RELEASES}개만 유지)"
ls -1t "$RELEASES_DIR" | tail -n +$((KEEP_RELEASES+1)) | while read -r old; do
  rm -rf "$RELEASES_DIR/$old"
done || true

# ==========================
# PM2 무중단 재시작
# ==========================
log "PM2 startOrReload (ecosystem.config.js)"
pm2 startOrReload ecosystem.config.cjs --update-env || {
  err "ecosystem.config.cjs 실행 실패 → 단일 스크립트로 재시도"
  pm2 restart "$APP_NAME" || pm2 start server/app.js --name "$APP_NAME"
}

# ==========================
# 헬스체크
# ==========================
log "헬스체크: $HEALTH_URL"
RETRY=20
SLEEP=1
ok=false
for i in $(seq 1 $RETRY); do
  if curl -fsS "$HEALTH_URL" >/dev/null 2>&1; then
    ok=true; break
  fi
  sleep "$SLEEP"
done

if [ "$ok" != true ]; then
  err "헬스체크 실패! 롤백 수행"
  if [ -d "$STATIC_DST/.backup/$TS" ]; then
    rsync -a --delete "$STATIC_DST/.backup/$TS/" "$STATIC_DST/"
  fi
  pm2 reload "$APP_NAME" || true
  die "배포 실패(헬스체크 불통). 롤백 완료."
fi

# ==========================
# Nginx 리로드(선택)
# ==========================
if command -v nginx >/dev/null 2>&1; then
  log "Nginx 설정 테스트"
  if nginx -t; then
    log "Nginx 리로드"
    nginx -s reload || systemctl reload nginx || true
  else
    err "Nginx 설정 테스트 실패(무시하고 진행)"
  fi
fi

log "✅ 배포 완료: $TS"

📌 deploy.sh 스크립트 요약

1. 배포 스크립트를 진행할 브랜치를 deploy로 설정했어요. 따로 배포 전용 브랜치를 만들어서 하는 것을 추천합니다.

2. Git 동기화 부분을 넣었어요. 스크립트 초반에는 항상 Git 원격 브랜치와 맞추는 절차를 넣었습니다.

  • git fetch 로 원격 최신 상태 가져오기
  • git rev-parse 로 로컬/원격 해시 비교
  • 해시 값이 다르면 git reset --hard origin/<branch> 로 맞췄습니다.
    • reset --hard 말고 git merge로 해도 되지만, 서버에서 실수로 수정 후 커밋된게 있으면 충돌이 발생할 수 있고, 수동 머지를 해야합니다. 결과적으로 배포 자동화가 깨지고, 사람이 개입해야 합니다.
    • reset --hard을 사용하면 현재 작업 트리를 원격 브랜치와 100% 동일하게 만들기 때문에 항상 깔끔한 상태에서 빌드를 보장할 수가 있습니다.

3. 빌드 & 배포 과정을 자동화했어요. Git 동기화가 끝나면 바로 의존성 설치 후 빌드를 진행합니다.

  • npm ci 또는 npm install 로 의존성 설치
  • npm run build 로 빌드
  • 산출물(dist/)을 /var/www/codestargram/releases 에 타임스탬프별로 보관
  • 최신 결과물을 /var/www/codestargram/repo/web-p3-codestargram2/dist 로 덮어쓰기

그리고 오래된 릴리스는 자동으로 정리해서, 서버 공간을 아끼도록 했습니다.

4. 서버 프로세스 재시작을 PM2로 처리했어요. 빌드된 코드가 준비되면 배포 스크립트와 pm2 연동을 진행합니다.

  • pm2 startOrReload ecosystem.config.cjs 실행
    • 최초 실행 시 → PM2가 새 앱을 띄우고
    • 이후 실행 시 → 무중단 reload가 됨
  • 만약 설정 파일이 없다면, server/app.js를 직접 PM2로 띄우도록 예외 처리
  • 이렇게 하면 Node.js 앱이 항상 살아 있고, 서비스가 끊기지 않습니다.

5. 헬스체크와 롤백을 넣었어요. 단순히 재시작만 하면 끝이 아니라, 정말 서버가 잘 떴는지 확인해야 합니다.

  • curl 로 http://127.0.0.1:3000/health 요청
  • 실패하면 → 직전에 백업해둔 정적 자산을 다시 복원
  • 그리고 PM2를 이전 상태로 돌려서, 사용자가 다운타임을 겪지 않게 했습니다.

6. 마지막으로 Nginx 설정 리로드까지 정적 자산을 /var/www/codestargram/repo/web-p3-codestargram2/dist 에 새로 배치했으니, 필요할 때 Nginx도 리로드하게 했습니다.

  • nginx -t 로 설정 확인 후 nginx -s reload

4. 서버에 배포 스크립트 설정

1. 배포 스크립트를 설정을 위한 서버 준비를 1회 진행해줍니다.

ssh kimdayeon@172.30.1.86

# 디렉터리 준비
sudo mkdir -p /var/www/codestargram/{repo,releases,scripts,logs}
sudo chown -R $USER:$USER /var/www/codestargram

# 코드 클론 (GitHub)
cd /var/www/codestargram/repo
git clone https://github.com/<YOU>/web-p3-codestargram2 .   # 또는 SSH URL
git checkout deploy  # 배포 브랜치

# PM2 설정 파일을 repo 루트에 둠 (ecosystem.config.js)
# deploy.sh는 /var/www/codestargram/scripts/deploy.sh 에 둘 것

서버에서 혼란이 없도록, 디렉토리 구조와 경로를 역할에 따라 생성했습니다.

  • repo: 서버에서 git clone한 결과물
    • /repo/ecosystem.config.cjs으로 pm2 설정
    • /repo/web-p3-codestargram2/dist에서 Nginx로 정적 파일 서빙
  • releases: 릴리즈 보관용
  • scripts: 배포 스크립트
  • logs: 로그 기록

이렇게 정리하면, 파일이 어디에 있는지 바로 파악이 가능합니다.

2. 맥(로컬) 환경에 있는 배포 스크립트를 서버로 업로드해주고, 실행권한 설정을 해줍니다.

# 맥에서
scp /경로/deploy.sh kimdayeon@172.30.1.86:/var/www/codestargram/scripts/deploy.sh
ssh kimdayeon@172.30.1.86 "chmod +x /var/www/codestargram/scripts/deploy.sh \"

3. 서버에 패키지 설치가 안되어있다면 해줍니다.

# 패키지 업데이트
sudo apt update

# curl 설치 (없다면)
sudo apt install -y curl

# Node.js 20.x 설치 (LTS 권장)
curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install -y nodejs

# 설치 확인
node -v
npm -v

# pm2 설치 및 확인
sudo npm install -g pm2
pm2 -v

✅ 주요 체크 포인트

  • /var/www/codestargram/repo/web-p3-codestargram2 에 실제 레포가 클론되어 있어야 합니다. (.git 존재)
  • ecosystem.config.cjs 는 레포 루트에 위치해야 합니다.(없으면 PM2가 server/app.js로 fallback)
  • 관련 패키지가 서버에 설치되어있어야 합니다.

5. 배포 스크립트 실행 및 결과

체크 포인트를 확인했다면 스크립트를 실행합니다.

/var/www/codestargram/scripts/deploy.sh

변경사항이 있을 시: deploy로 PR 생성/머지 후 스크립트 실행

변경사항이 없을 시: 변경사항 없음 -> 종료

배포 결과물

서버 주소에서 배포된 코드가 실행된 걸 확인할 수 있었습니다.

]]> <![CDATA[웹 요청 방식 비교 분석 Form vs Fetch API - 네트워크 계층과 브라우저 처리 관점의 차이]]> https://velog.io/@dyeon-dev/%EC%9B%B9-%EC%9A%94%EC%B2%AD-%EB%B0%A9%EC%8B%9D-%EB%B9%84%EA%B5%90-%EB%B6%84%EC%84%9D-Form-vs-Fetch-API-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EA%B3%84%EC%B8%B5%EA%B3%BC-%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80-%EC%B2%98%EB%A6%AC-%EA%B4%80%EC%A0%90%EC%9D%98-%EC%B0%A8%EC%9D%B4 https://velog.io/@dyeon-dev/%EC%9B%B9-%EC%9A%94%EC%B2%AD-%EB%B0%A9%EC%8B%9D-%EB%B9%84%EA%B5%90-%EB%B6%84%EC%84%9D-Form-vs-Fetch-API-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EA%B3%84%EC%B8%B5%EA%B3%BC-%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80-%EC%B2%98%EB%A6%AC-%EA%B4%80%EC%A0%90%EC%9D%98-%EC%B0%A8%EC%9D%B4 Fri, 19 Sep 2025 03:06:28 GMT

목차

  1. 개요 - 무엇이 다른가?
  2. 요청(Request) 생성 방식
  3. 응답(Response) 처리 방식
  4. 브라우저 동작과 UX
  5. 네트워크 계층 관점 요약
  6. 결론

1. 개요 - 무엇이 다른가?

단순 HTML <form> 전송 방식과 fetch API 전송 방식은 기능적으로는 "서버로 HTTP 요청을 보낸다"는 점에서 같지만, 네트워크 계층 동작 방식과 브라우저 처리 관점에서 중요한 차이가 있다.

핵심 차이점 ** ◦ 요청 생성 주체: 브라우저 자동 생성 vs 개발자 직접 제어 ◦ 응답 처리 방식: 브라우저의 페이지 전환 vs 자바스크립트 코드 처리 ◦ 사용자 경험(UX): 전체 페이지 새로고침 vs 부분적 동적 업데이트**

이 두 방식의 근본적인 차이점을 가지고 자세히 알아보겠다.

2. 요청(Request) 생성 방식

브라우저와 서버가 통신하기 위해서는 HTTP 스펙에 맞는 요청과 응답을 해야한다. 먼저 브라우저에서는 표준 헤더가 담긴 요청을 서버에게 보낸다. 이때 요청 방식에 따라 브라우저에서 작동하는 방식과 직접 제어하는 방식으로 나뉜다.

HTML Form

  • 브라우저가 자동으로 HTTP 요청 메시지를 구성한다.
    • method="GET"이면 Query String
    • method="POST"이면 application/x-www-form-urlencoded 기본 인코딩
  • 기본적으로 브라우저가 표준 헤더(Content-Type, Accept) 등을 자동 세팅한다.
  • 개발자가 세밀하게 헤더나 요청 바디를 통제하기 어렵다.

fetch API

  • 개발자가 요청을 직접 제어한다.
  • HTTP 메서드, 헤더, 바디(JSON, FormData, Blob 등)를 자유롭게 지정 가능하다.
  • 쿠키/인증 정보를 포함할지(credentials 옵션) 등 네트워크 계층의 동작을 선택적으로 제어할 수 있다.

3. 응답(Response) 처리 방식

서버는 브라우저에게 받은 요청에 따른 응답을 해준다. 이때 브라우저의 응답은 서버에서 페이지를 직접 던져주면서 새로 로드되거나, 비동기 객체를 사용하여 페이지가 새로 로드되지 않고 자바스크립트에서 세부적인 컨트롤이 가능한 방식으로 나뉜다.

HTML Form

  • 서버 응답(HTML, Redirect 등)은 브라우저가 새 페이지로 로드하거나 리다이렉트 처리한다.
  • 즉, 브라우저 렌더링 파이프라인에 직접 연결 → 응답은 자동으로 화면 전환으로 이어진다.
  • 응답을 자바스크립트 코드로 가공할 수는 없다.

fetch API

  • 응답이 Promise<Response> 객체로 전달된다.
  • 응답 본문을 response.json(), response.text() 등으로 직접 파싱해 사용자가 원하는 로직으로 처리할 수 있다.
  • 화면 전환은 자동으로 일어나지 않으며, SPA 방식에서 필요한 UI만 갱신이 가능하다.

HTML Form 방식이 자바스크립트 개입이 어려운 이유

<form>의 전송 결과는 브라우저 렌더링 파이프라인으로 바로 들어간다. (응답 본문 = 새 페이지로 렌더링) 응답 데이터를 JS 코드에서 직접 가공하거나 조건에 따라 분기 처리하는 것은 불가능하다. 따라서 "조건에 따라 다른 페이지로 보낸다" 같은 로직은 서버에서 결정해야 한다.

HTML Form 전송 + Redirect 처리 흐름

Form 전송 후 서버가 3xx 상태 코드(302 Found, 303 See Other 등)를 응답하면, 브라우저는 자동으로 Location 헤더에 지정된 URL로 이동한다. 이 과정에서 개발자가 중간에 자바스크립트로 개입할 수 없다. 즉, 리다이렉트를 서버가 제어해야 한다.

HTTP/1.1 302 Found
Location: /home  → 브라우저는 /home 자동 이동된다!

  • 메서드 변환: 302/303이면 보통 GET으로 전환
  • 전형적 PRG(Post/Redirect/Get) 패턴에 적합

fetch Redirect 처리 (브라우저 기준)

fetch는 응답이 JS로 전달되고, 서버가 3xx 응답을 보내면 브라우저 fetch가 내부적으로 그 리다이렉트를 따라가서 최종 응답까지 자동으로 받아온다.

const res = await fetch("/login", { method: "POST" }); // follow(기본)
if (res.redirected) {
  // 필요하면 여기서 직접 네비게이션
  window.location.href = res.url;
}

  • 기본값 redirect: "follow"으로 자동 추적하고, 중간의 3xx 응답은 JS에 노출되지 않고, Promise는 최종 응답으로 resolve 된다.
  • 브라우저에선 보안 때문에 헤더(Location)를 노출하지 않는다. 바디도 접근 불가하다.
  • 페이지 네비게이션은 일어나지 않는다. 단지 네트워크 레벨에서 추가 요청을 수행해 최종 리소스를 받아올 뿐이고, 화면 전환은 location.href 등으로 직접한다.

4. 브라우저 동작과 UX

위의 응답에 따라 브라우저의 동작 과정이 달라지고 사용자 경험까지 달라지게 된다.

HTML Form

  • 기본 동작: 요청을 보내고 응답에 따라 페이지 리로드(Full reload)
  • 사용자는 새로고침(깜빡임) 경험을 겪는다.
  • History API와 결합하지 않으면 SPA 같은 UX를 만들기 어렵다.

fetch API

  • 요청-응답이 백그라운드 비동기 처리.
  • 페이지 전환이 일어나지 않음 → 기존 화면 상태 유지 가능.
  • 부분 렌더링이나 동적 업데이트에 유리.

5. 네트워크 계층 관점 요약

구분 HTML Form fetch API
요청 생성 브라우저가 자동 조립 (제한적 제어) 개발자가 완전 제어 가능
응답 처리 브라우저가 페이지로 렌더링 JS 코드에서 직접 가공
네트워크 연결 쿠키/세션 자동 포함 credentials 옵션으로 통제
UX 영향 전체 페이지 리로드 페이지 유지 + 부분 업데이트

6. 결론

  • HTML Form: 전통적인 MPA (Multi-Page Application) 패턴에 적합하며, 서버가 렌더링을 주도하고 브라우저가 자동으로 처리하는 방식.
  • Fetch API: 현대적인 SPA (Single-Page Application) 패턴의 핵심으로, 클라이언트(개발자 코드)가 요청과 응답을 세밀하게 제어하는 방식.

두 방식은 동일한 HTTP 계층을 사용하지만, '응답 처리 주체'와 '화면 갱신 방식'에서 본질적인 차이를 보인다.

]]> <![CDATA[Node.js의 net 모듈로 웹 서버 만들기]]> https://velog.io/@dyeon-dev/Node.js%EC%9D%98-net-%EB%AA%A8%EB%93%88%EB%A1%9C-%EC%9B%B9-%EC%84%9C%EB%B2%84-%EB%A7%8C%EB%93%A4%EA%B8%B0 https://velog.io/@dyeon-dev/Node.js%EC%9D%98-net-%EB%AA%A8%EB%93%88%EB%A1%9C-%EC%9B%B9-%EC%84%9C%EB%B2%84-%EB%A7%8C%EB%93%A4%EA%B8%B0 Wed, 17 Sep 2025 00:10:26 GMT

목차

  1. Node.js는 서버가 아니다. 그럼 어떻게 서버를 만들 수 있는걸까?
  2. net 모듈 - 웹 서버 만드는 도구
  3. 서버 객체 생성하기
  4. HTTP 응답 형식 직접 작성해보기
  5. HTTP 요청 구조에서 method, url 추출
  6. 결론 및 향후 목표

1. Node.js는 서버가 아니다. 그럼 어떻게 서버를 만들 수 있는걸까?

Node.js 자체는 웹 서버가 아니다. Node.js는 구글의 V8 엔진으로 자바스크립트 런타임 환경을 제공하는 프로그램일 뿐이다. 웹 브라우저말고도 자바스크립트를 실행할 수 있도록 해준다. 서버는 특정 포트를 열고 클라이언트의 요청을 기다리는 역할을 한다. Node.js는 이러한 서버 기능을 구현할 수 있는 API를 제공하기 때문에, 직접 코드를 작성해서 서버를 만들 수 있다.

node.js의 웹 서버 프로그래밍에는 2가지 방식이 있다.

  • node.js에서 기본으로 제공해 주는 모듈을 이용
    • net 모듈 사용
    • http 모듈 사용
  • Express 등의 웹 프레임워크 사용

웹 서버 방식의 이해도를 높이기 위해 net 모듈을 사용해서 웹 서버를 만들어보자.

2. net 모듈 - 웹 서버 만드는 도구

Node.js의 net 모듈은 TCP 통신을 위한 기본적인 도구이다. 이 모듈을 사용하여 소켓 통신을 구현하고, 서버와 클라이언트 간의 데이터 스트림을 다룰 수 있다. net 모듈로 특정 포트에서 연결을 기다리고, 연결이 들어오면 데이터를 주고받는 Socket 객체를 생성한다. 이 Socket 객체를 통해 들어오는 요청을 처리한다.

3. 서버 객체 생성하기

net 모듈을 불러오고 createServer() 메서드를 통해 TCP 서버 객체를 생성한다. 서버 객체를 생성한 후 특정 포트번호로 listen() 메서드를 호출하면 해당 포트로 웹 서버 통신이 시작된다.

import * as net from "node:net";
const PORT = process.env.PORT || 3000;

const server = net.createServer((socket)=> {
    // 클라이언트로부터 데이터를 수신할 때 
    socket.on("data", (data) => {
        console.log(data.toString());
        // 클라이언트에게 데이터 반환
        socket.write(`서버가 보낸 응답: ${data}`); 
    }
})

server.listen(PORT, () => {
    console.log(`TCP server (net) listening at http://localhost:${PORT}/index.html`);
});
  • 브라우저에 http://localhost:3000/ 을 입력했을 때 socket.on() 메서드를 통해 클라이언트로부터 온 데이터를 수신한다.
  • data 정보는 Buffer 형식으로 들어오고, 이를 문자열로 바꿔서 확인해보면 다음과 같은 정보가 담겨있다.
    GET / HTTP/1.1
Host: localhost:3000
Connection: keep-alive
Cache-Control: max-age=0
sec-ch-ua: "Not)A;Brand";v="8", "Chromium";v="138", "Google Chrome";v="138"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "macOS"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: x_auth=eyJhbGciOiJIUzI1NiJ9.NjZjOTZkOTQ3NDllOGQ4ZTUyZWM3ZDQ3.PCwoG67FlL4g66sRfkvwJVgjS-NLIY9q-yzb9qq5tgY

Buffer란?

  • 바이너리 데이터를 다루는 객체이다.
  • Node.js는 데이터를 주고받을 때 Buffer 객체 형태로 처리한다.
  • Buffer는 메모리에 직접 할당된 고정 크기 버퍼로, I/O 작업(파일 읽기, 네트워크 통신 등)의 효율을 높여준다.
  • toString() 메서드를 사용하여 Buffer의 내용을 문자열로 변환할 수 있다.

4. HTTP 응답 형식 직접 작성해보기

브라우저에 http://localhost:3000/ 을 입력했을 때, 위의 코드에서 socket.write()가 작동하지 않고, 값이 없거나 오류가 출력된다.

그 이유는 다음과 같다. net 서버는 단순히 TCP Socket을 통한 원시 데이터(Raw Data)만 주고받을 수 있다. 브라우저는 HTTP 프로토콜만 사용하기 때문에 net 서버가 브라우저의 HTTP 요청을 처리할 수 없는 것이다. 이를 해결하기 위해 브라우저 규약에 맞게 HTTP 응답 형식을 직접 작성해서 클라이언트가 정상 파싱하도록 해야 한다.

  • 공식문서: Node.js HTTP response.writeHead(), response.write() 섹션 참고.

그럼 HTTP 응답 형식부터 자세히 알아보자! (이게 핵심) HTTP(Hypertext Transfer Protocol)는 텍스트 기반 프로토콜로, 규칙에 맞춰 개발해서 서로 정보를 교환할 수 있도록 한다. 클라이언트와 서버는 상태 줄, header, 빈 줄(CRLFCRLF), body 구조 순서로 통신한다.

header의 역할(메타데이터)

  • Content-Type: body를 어떤 형식으로 해석할지 지정
  • Content-Length / Transfer-Encoding: 응답 body 길이나 전송 방식(예: chunked)을 알려, 클라이언트가 어디까지를 body로 읽을지 판단하게 함. 둘 중 하나는 필수. 없으면 클라이언트는 응답 경계를 알 수 없음.
  • Connection: keep-alive/close 여부를 지정
  • 그 외 캐시, 쿠키, CORS 등 클라이언트 동작을 결정하는 다양한 정책 전달.

    body의 역할(실제 데이터)

  • HTML, JSON, 이미지 등 클라이언트가 최종적으로 사용하는 페이로드
  • 일부 상태코드(예: 204, 304)나 요청 메서드(HEAD)에서는 응답에 body가 포함되지 않는다.
구분 204 No Content 304 Not Modified
목적 요청에 대한 응답으로 보낼 새로운 콘텐츠가 없을 때 사용한다. 클라이언트의 캐시된 리소스가 최신 상태임을 알린다.
사용 시점 PUT, DELETE, POST 등 서버의 리소스를 변경하는 요청이 성공했을 때 주로 사용한다. 캐시된 리소스를 확인하기 위한 조건부 GET, HEAD 요청에 대한 응답으로 사용한다.
캐시 기본적으로 캐시될 수 있다. ETag 헤더가 포함될 수 있다. 캐시를 활용하기 위한 상태 코드다.
클라이언트 동작 클라이언트는 현재 페이지를 유지하거나, 서버의 성공 응답을 바탕으로 다음 작업을 진행한다. 클라이언트는 가지고 있는 캐시된 복사본을 그대로 사용한다.

빈 줄(CRLFCRLF)

  • 헤더들은 \r\n으로 줄바꿈하며, 헤더 종료 후 반드시 빈 줄 \r\n을 넣는다.
  • 그 다음이 body. 이 경계가 없으면 클라이언트는 파싱할 수 없다.

그럼 HTTP 응답 형식을 직접 작성해보자.

const server = net.createServer((socket)=> {
  socket.on("data", (data) => {
    try {
      const body = `<h1>HTTP 응답 바디</h1>`;
      const header = 
      `HTTP/1.1 200 OK\r\n` +
      `Content-Type: text/html; charset=UTF-8\r\n` +
      `Content-Length: ${Buffer.byteLength(body)}\r\n` + 
      `\r\n`;
      const response = header + body;
      socket.write(response);
      socket.end();
    } catch (error) {
        console.error();
    } 
  })

  socket.on("error", (err) => {
    console.error("Socket error:", err.message);
    try { socket.destroy(); } catch {}
  });
})

브라우저에 접속하면 body로 선언한 부분이 표시된다. Response Header에도 적용한 부분이 적용되어 있다.

5. HTTP 요청 구조에서 method, url 추출

HTTP 요청은 GET / HTTP/1.1과 같이 시작하는 Request Line과 헤더로 구성된다. 이 Request Line에서 URI를 추출하고 각 URI에 맞는 HTML 페이지를 응답하도록 분기처리를 해준다.

// ["GET", "/", "HTTP/1.1"]
    const [method, url] = data.toString().split(" ");

    const serverSideRendering = (url) => {
      switch (url) {
        case "/":
          return fs.readFileSync("./views/index.html");
        case "/login":
          return fs.readFileSync("./views/login.html");
        case "/register":
          return fs.readFileSync("./views/register.html");
        default:
          return `<h1>not found page</h1>`;
      }
    }

위 부분을 body 부분에 넣어주면 서버사이드렌더링이 적용된다!

const body = serverSideRendering(url);

6. 결론 및 향후 목표

이렇게 net 모듈을 사용해서 Node.js 서버의 기초를 직접 만들어보았다. HTTP 요청과 응답 형식을 알아보고 HTTP/1.1 헤더를 수동으로 작성해보았다. Node.js 서버의 기초이기 때문에 Express를 활용하기 위한 기본기를 다지는 경험이었다. 또한, 서버가 정적 HTML로 응답해주는 방식으로 MPA 구조와 SSR 방식의 기초를 다졌다.

하지만 지금까지 구현한 소스 코드는 stylesheet 와 파비콘 등을 지원하지 못하고 있다. 이후 더 다양한 컨텐츠 타입을 지원하도록 개선해 볼 것이다. MIME 타입을 적용하고 서버 코드를 확장하는 방식으로 진행할 것이다.

]]> <![CDATA[ESLint, Preitter 제대로 알고 사용하자]]> https://velog.io/@dyeon-dev/ESLint-Preitter-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EC%95%8C%EA%B3%A0-%EC%82%AC%EC%9A%A9%ED%95%98%EC%9E%90 https://velog.io/@dyeon-dev/ESLint-Preitter-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EC%95%8C%EA%B3%A0-%EC%82%AC%EC%9A%A9%ED%95%98%EC%9E%90 Wed, 03 Sep 2025 18:56:37 GMT 코드의 품질을 위해 ESLint와 Preitter를 보통 혼합해서 쓴다. 왜 그럴까? 하는 역할은 비슷해보이는데 어떤 게 달라서 둘 다 같이 써야하는지 알아보고 각각 어떤 설정이 어떤 역할을 하는건지 파악해보자.

VSCode가 코드의 Lint Error를 잡는 것부터, 저장 시 자동 수정하는 설정까지 복잡한 조건 설정 과정을 적용해보자!

ESLint

ESLint는 코드 품질을 개선하고 런타임에 버그가 발생하지 않도록 사전에 버그를 수정하는 데 도움이 되는 linter이다.

'Lint'는 실제로 보풀이라는 뜻이다. ESLint는 거슬리는 보풀 같은 코드를 깔끔하게 만들어준다는 뜻이라고 보면 된다.ㅎ

ESLint를 사용하는 이유

  • 코드 일관성 유지: 코드 스타일 가이드를 준수하여 일관성 있는 코드 작성 가능
  • 버그 및 오류 방지: 잠재적인 버그나 오류를 사전에 찾아내고 수정할 수 있다.
  • 팀 협업 강화: 팀원 간에 코드 품질을 통일시켜 협열 효율을 높일 수 있다.

v9.x 버전 마이그레이션 사항

  • eslintrc는 더 이상 사용되지 않는다. eslintrc 구성 형식을 사용해야 하는 경우 ESLINT_USE_FLAT_CONFIG 환경 변수를 false으로 설정해야 한다.

이 글에서는 v9.x 버전으로 다룬다.

플러그인 제공

ESLint 에서 많이 사용하는 plugin 으로는 기본인 plugin:@typescript-eslint/recommended 가 있다.
그리고 Airbnb, Google 등에서 본인들의 ESLint style 을 작성하여 npm 모듈로 제공하고 있다.

규칙

공식 문서의 Rules Reference를 확인해보면, 각 규칙에는 있는 이모지 표시로 규칙 활성화와 자동 수정 여부를 확인할 수가 있다.

  • ✅ recommendedconfig 설정 시 활성화 되는 규칙
  • 🔧 --fix 명령어로 자동으로 수정할 수 있는 규칙

세 가지 오류 수준을 통해 ESLint가 규칙을 적용하는 방식을 세부적으로 제어할 수 있다.

  1. "off" or "0"
  • 규칙을 해제, 해당 규칙을 사용하지 않음
  1. "warn" or "1"
  • 규칙을 경고로 설정, 규칙을 강제하지 않고 경고만 해줌
  1. "error" or "2"
  • 규칙을 에러로 설정, 통합 테스트, build, PR등의 경우에 에러 발생

설치

npm init @eslint/config@latest
  1. How would you like to use ESLint? // eslint를 어떤 방식으로 쓸거에요?
  • To check syntax only // 문법적 오류만 잡을거에요
  • To check syntax and find problems // 문법이랑 에러도 잡을거에요
  1. What type of modules does your project use? // 프로젝트에선 어떤 모듈화를 사용하나요?
  • JavaScript modules (import/export)
  • CommonJS (require/exports)
  • None of these
  1. Which framework does your project use? // 어떤 프레임워크를 사용하나요?
  • React
  • Vue.js
  • None of these // 안써요
  1. Does your project use TypeScript? // 프로젝트는 typescript를 사용하나요?
  • y/s로 대답
  1. Where does your code run? // 당신의 코드는 어디서 돌리나요?
  • browser
  • Node
  1. Which package manager do you want to use? // 패키지 매니저 선택
  • npm
  • yarn
  • pnpm

설치를 완료하면 eslint.config.mjs 파일이 생성된다. 생성된 파일에 설정들을 추가해보자.

export default defineConfig([

    { files: ["app.js", "server/**/*.js"], languageOptions: { globals: globals.node } },
    { files: ["features/**/*.js"], languageOptions: { globals: globals.browser }},
    js.configs.recommended,
    {
        rules: {
            "no-unused-vars": "warn",
            // "no-undef": "warn",
        },
    },

]);
  • "eslint:recommended": ESLint가 권장하는 규칙. 위에서 본 ✅ 표시 적용
  • rules: ESLint는 규칙이 있어야 그걸 보고 코드를 검사한다. 새 객체를 정의하여 규칙을 개별적으로 구성할 수 있다.
    • no-undef: 코드에서 선언되지 않은 식별자를 사용하면 오류를 표시하는 규칙이다. 하지만 globals 설정을 해주면 이런 오류를 잡아주기 때문에 따로 처리하지 않았다. 또한, TypeScript 계획이 있다면 no-undef는 TS가 잡아주므로 끄는 편(off)이 일반적이다.
  • browser 코드와 node 코드를 files 패턴으로 분리해 각각 globals를 적용해야 한다. globals.browser/globals.node를 languageOptions.globals에 넣어야 no-undef 오탐이 생기지 않는다.

    왜 globals 설정이 no-undef 오탐을 줄이나요?

     - 문제: 브라우저/노드 환경에는 미리 제공되는 전역 식별자들이 있는데, ESLint가 이를 모르면 no-undef로 오탐한다.
 - 브라우저 전역 예시: `window`, `document`, `navigator`, `location` 등
 - 노드 전역 예시: `process`, `dirname`, `Buffer`, `global` 등
 - 해결: `globals` 패키지의 `globals.browser`, `globals.node`를 ESLint 설정의 `languageOptions.globals`에 주입하면, 해당 식별자들을 “이미 전역에 존재하는 읽기전용 변수”로 인식해서 no-undef 오탐이 사라진다.

Preitter

Preitter는 포맷팅 역할을 해서 코드를 일관성 있게 만들어준다. ESLint와 달리 규칙이 미리 세팅되어 있기 때문에 설정 없이도 npx prettier . --write 명령어로 바로 사용해볼 수 있는 간편함이 있다.

Preitter 설치

npm install --save-dev --save-exact prettier

.prettierrc 파일 추가

.prettierrc 파일을 추가해서 직접 커스텀을 해도 된다.

{
  ------------------------
  기본 포맷팅 설정
  ------------------------
  // 한 줄의 최대 길이를 설정 (기본값: 80)
  // 이 길이를 초과하면 자동으로 줄바꿈이 발생
  "printWidth": 80,

  // 들여쓰기 시 사용할 공백 문자 수 (기본값: 2)
  // useTabs가 false일 때만 적용됨
  "tabWidth": 2,

  // 들여쓰기에 탭 문자 사용 여부 (기본값: false)
  // true: 탭 문자 사용, false: 공백 문자 사용
  "useTabs": false,

  // 문장 끝 세미콜론 사용 여부 (기본값: true)
  // true: 모든 문장 끝에 세미콜론 추가
  // false: 필요한 경우에만 세미콜론 추가
  "semi": true,

  ------------------------
  따옴표 관련 설정
  ------------------------
  // 문자열에 작은따옴표 사용 여부 (기본값: false)
  // true: 'string', false: "string"
  "singleQuote": true,

  // 객체 속성에 따옴표 추가 방식 (기본값: "as-needed")
  "quoteProps": "as-needed",
  // - "as-needed": 필요한 경우에만 따옴표 추가
  // - "consistent": 하나라도 따옴표가 필요하면 모든 속성에 따옴표 추가
  // - "preserve": 입력된 따옴표 스타일 유지

  // JSX에서 작은따옴표 사용 여부 (기본값: false)
  // singleQuote 설정과 독립적으로 동작
  "jsxSingleQuote": true,

  ------------------------
  쉼표 및 괄호 설정
  ------------------------
  // 객체, 배열 등의 후행 쉼표 설정 (기본값: "es5")
  "trailingComma": "es5",
  // - "all": 모든 구문에서 후행 쉼표 사용 (함수 인자 포함)
  // - "es5": ES5에서 유효한 위치에만 후행 쉼표 추가
  // - "none": 후행 쉼표 사용 안 함

  // 객체 리터럴의 중괄호 주위 공백 추가 (기본값: true)
  // true: { foo: bar }, false: {foo: bar}
  "bracketSpacing": true,

  // JSX 요소의 > 위치 설정 (기본값: false)
  // true: 마지막 줄에 > 위치, false: 다음 줄에 > 위치
  "bracketSameLine": false,

  // 화살표 함수 매개변수 괄호 사용 방식 (기본값: "always")
  "arrowParens": "always",
  // - "always": (x) => x
  // - "avoid": x => x (매개변수가 하나일 때)

  ------------------------
  특수 포맷팅 설정
  ------------------------
  // 줄 끝 문자 설정 (기본값: "lf")
  "endOfLine": "lf",
  // - "lf": \n (Unix)
  // - "crlf": \r\n (Windows)
  // - "cr": \r (Mac OS)
  // - "auto": 첫 줄 끝 문자 유지

  // 마크다운 텍스트의 줄바꿈 방식 (기본값: "preserve")
  "proseWrap": "always",
  // - "always": 항상 printWidth에 따라 줄바꿈
  // - "never": 줄바꿈 하지 않음
  // - "preserve": 원본 텍스트 줄바꿈 유지

  // HTML 공백 처리 방식 (기본값: "css")
  "htmlWhitespaceSensitivity": "strict",
  // - "css": CSS display 속성 기준으로 처리
  // - "strict": 모든 공백을 유지
  // - "ignore": 모든 공백을 무시
}

하지만 Preitter는 단순히 코드를 예쁘게 만들어주는 역할만 하고, 코드 품질과 관련된 검사는 ESLint의 몫이다. 그래서 Preitter는 ESLint와 통합하는 방법을 제공한다. eslint-plugin-prettier를 설치하면 된다. 공식문서에 설명된 것처럼 코드 포맷팅 관련 문제에는 Prettier를, 코드 품질 관련 문제에는 ESLint를 사용해보자. 

"devDependencies": {
    "@eslint/js": "^9.34.0",
    "eslint": "^9.34.0",
    "eslint-config-prettier": "^10.1.8",
    "globals": "^16.3.0",
    "prettier": "3.6.2"
}

지금까지 설치한 각 패키지들의 핵심 기능을 설명하면 다음과 같다.

핵심 린팅 도구
• eslint: JavaScript/TypeScript 코드의 문제점을 검사하는 린터
• @eslint/js: ESLint의 JavaScript 관련 기본 설정

코드 스타일링
• prettier: 코드 포맷터 • eslint-config-prettier: 서로 충돌하는 옵션이 있으면 Preitter 규칙을 사용하여 충돌 방지

ESLint config에서 Preitter 설정

ESLint와 Preitter의 충돌을 설정해주기 위해 eslint.config.mjs에서 설정을 해줘야 한다.

import prettierConfig from "eslint-config-prettier";

export default defineConfig([
    {
        files: ["app.js", "server/**/*.js"],
        languageOptions: { globals: globals.node },
    },
    {
        files: ["features/**/*.js"],
        languageOptions: { globals: globals.browser }.
    },
    js.configs.recommended,
    prettierConfig, // Prettier와 충돌하는 규칙 비활성화
]);

🐛eslint-plugin-prettier 설정은 뺐어요. 이렇게 통합하는 과정에서 여러 블로그 글을 참고하다보면 eslint-config-prettier뿐만 아니라 eslint-plugin-prettier 플러그인을 추가로 사용하는 경우도 있다. 이건 Prettier가 ESLint 규칙으로 통합돼서 실행할 수 있도록 해주는 기능이다.

그런데,, 나도 처음에 eslint-plugin-prettier 플러그인으로 다음과 같이 통합해주는 과정을 거쳤는데 그렇게 하니까 몇가지 부분에서 통합이 제대로 이뤄지지 않는 문제상황을 겪었다.

import prettier from 'eslint-plugin-prettier';

...

{
        plugins: { prettier },
        rules: {
            "prettier/prettier": "error", // Prettier 규칙 위반 시 오류 표시
        },
    },

.prettierrc에서 분명 싱글 따옴표(') 규칙으로 설정을 했는데 ESLint로 통합해서 적용할 때 더블 따옴표(") 규칙으로 적용되면서 Prettier 규칙을 위반했다고 빨간줄이 생기는 오류가 발생했다.

이 부분에 대해서 왜 그런지 찾아보다가.. 처음에는 뭔말인지 잘 모르고 넘어갔던 공식문서에서 언급한 부분을 다시 한 번 보게 되었다. 이 플러그인은 특정 상황에서는 유용할 수 있지만 일반적으로 권장되지는 않는 방식이라고 하는데, 이렇게 통합이 잘 되지 않는 문제가 발생하기도 해서 권장되지 않는다고 설명한게 아닐까 생각이 든다..!

자동화 설정

매번 npm run lint를 돌리거나 빨간줄을 직접 수정하기에는 상당히 귀찮다. 이걸 해결해주기 위해 코드를 저장할 때 자동으로 코드포맷팅을 해주는 자동화 설정을 해주자.

폴더 상위 디렉토리에 .vscode/settings.json를 추가한다.

{
    // ESLint 확장 프로그램 활성화
    "eslint.enable": true,


    // 기본 코드 포맷터를 Prettier로 설정
    "editor.defaultFormatter": "esbenp.prettier-vscode",


    // 파일 저장 시 자동으로 코드를 포맷팅
    "editor.formatOnSave": true,
    "editor.codeActionsOnSave": {
        "source.fixAll.eslint": "explicit", // ESLint 오류 자동 수정
        "source.organizeImports": "explicit" // import 문 자동 정리
    },

    // ESLint가 검사할 파일 타입들을 지정
    "eslint.validate": [
        "javascript",
        "javascriptreact",
        "typescript",
        "typescriptreact"
    ],

    "prettier.requireConfig": true, // .prettierrc 파일이 있을 때만 Prettier를 사용 (프로젝트별 설정 강제)

    // .mjs 파일을 JavaScript로 인식하도록 설정
    "files.associations": {
        "*.js": "javascript",
        "*.mjs": "javascript"
    },


    // 탭 크기를 2칸으로 설정하고, 탭 대신 스페이스 사용
    "editor.tabSize": 2,
    "editor.insertSpaces": true,


    // 파일 저장 시 빈 줄 제거
    "files.trimTrailingWhitespace": true,
    "files.insertFinalNewline": true
}

참고자료

]]> <![CDATA[ER 다이어그램을 단계별로 설계하자]]> https://velog.io/@dyeon-dev/ER-%EB%8B%A4%EC%9D%B4%EC%96%B4%EA%B7%B8%EB%9E%A8%EC%9D%84-%EB%8B%A8%EA%B3%84%EB%B3%84%EB%A1%9C-%EC%84%A4%EA%B3%84%ED%95%98%EC%9E%90 https://velog.io/@dyeon-dev/ER-%EB%8B%A4%EC%9D%B4%EC%96%B4%EA%B7%B8%EB%9E%A8%EC%9D%84-%EB%8B%A8%EA%B3%84%EB%B3%84%EB%A1%9C-%EC%84%A4%EA%B3%84%ED%95%98%EC%9E%90 Tue, 02 Sep 2025 14:19:35 GMT ERD(Entity Relationship Diagram)란?

ER 다이어그램은 실세계에 존재하는 물건을 여러 가지 속성을 가진 엔티티로 파악하고 엔티티(entity) 사이의 상호 관계를 관계(relationship)로 표현한 그림이다. ER 다이어그램의 속성은 데이터이므로 ER 다이어그램을 통해 시스템에서 사용하는 각 데이터의 상호 관계를 읽을 수가 있다.

ER 다이어그램은 엔티티, 속성, 관계 3가지로 구성된다.

엔티티

실세계에 존재하는 물건에 해당

  • 독립 엔티티
    • 다른 엔티티에 의존하지 않고 존재하는 것
  • 종속 엔티티
    • 다른 엔티티에 의존하여 존재하는 것

속성

엔티티에 포함된 데이터가 속성이다.

관계

엔티티 간의 연관을 나타내는 것으로 의존 정도에 따라 점선 또는 직선으로 표현한다.

  • 실선 관계
    • 자식 엔티티의 기본키(PK) 가 부모 엔티티의 기본키를 포함할 때
    • 즉, 부모가 없으면 자식이 존재할 수 없음
  • 점선 관계
    • 자식 엔티티가 부모 엔티티의 기본키를 포함하지 않고, 대신 부모의 키를 외래키(FK) 로만 가질 때
    • 자식이 부모의 존재에 “의존”은 하지만, PK 차원에서는 독립적이기 때문에 점선 관계가 됨

그림에서 '주문'은 다른 엔티티에 의존하지 않기 때문에 독립 엔티티이며, '주문 상세'은 '주문' 없이 존재하지 않기 때문에 종속 엔티티이다. 또한, '주문'과 '주문 상세'는 종속 관계(식별 관계)에 있어 실선으로 이어지고 하나의 '주문'은 하나 이상의 '주문 내역'과 1:N으로 연관된다.

마스터 자료와 트랜잭션 자료

  • 리소스 엔티티
    • DB 설계에서 '마스터'가 될 수 있는 엔티티
    • ex) 거래처, 고객, 상품 등 기본적으로 필요한 데이터
  • 이벤트 엔티티
    • DB 설계에서 트랜잭션이 될 수 있는 엔티티
    • ex) 주문, 발주 등 어떤 사건이 일어났을 때 발생하는 데이터

'고객'은 리소스 엔터티이므로 마스터가 될 수 있다. 하지만 '주문'은 트랜잭션이 되기 때문에 이벤트 엔티티이다.

Step 1. 리소스 엔티티 추출 및 정의

시스템 전체를 나타내는 요구 사항 분석 명세서 등으로부터 리소스 엔티티를 추출하고 영역을 정의한다.

설명, 제약, 규칙, 범위가 될 수 있는 것은 빠짐없이 찾아내서 엔티티의 영역을 정의한다. 이는 데이터 모델을 만들 때 필요한 것이다.

모든 엔티티는 충분히 의미가 있는 것이어야 한다. 즉, 각 엔티티가 '무엇을 위해 존재하는가?', '누가 관리를 할 것인가?'를 중심으로 체크한다.

Step2. 이벤트 엔티티 추출 및 정의

리소스와 마찬가지로 현재 파악 가능한 이벤트 엔티티를 찾아내고 각 영역을 정의한다.

관계에 대한 의미를 정의하는 문장은 '~한다'는 동사 구문을 갖게 된다. 화살표 방향에 따라 '부모 엔티티는 자식 엔티티를 ~한다.'로 통일하면 알기 쉬울 것이다.

이 단계에서 📌 ERD 주요 엔티티를 정의해보자! 정리가 길어서 아래에 작성해두었다.

Step3. 추출한 엔티티들 사이에 관계를 표현

엔티티 사이의 관계에 대한 의미를 파악하고 정의한다. 모든 관계의 선은 방향성에 대한 이유가 있어야 한다.

이 단계에서 ☁️ ERD cloud로 ER 다이어그램을 만들어보자!

  • 리소스 엔티티는 보라색으로 지정해두었다.
  • N:M 관계를 1:N 관계로 중간테이블로 분리한 엔티티는 주황색으로 지정해두었다.

Step4. ER 다이어그램 체크리스트

마지막으로 체크리스트로 제대로 ERD를 만들었는지 점검해보자!

엔티티

체크항목 질문
이름 중복된 것 없나? 변수 스타일의 이름은 피할 것
필요성 꼭 필요한 것인가? 속성이 되어야 하지 않나?
일반화 일반화/특수화가 필요한가?

관계

체크항목 질문
다중도 1:1, 1:n 적합한가? 올바른 방향인가?
중복 중복되는 관계는 없는가?
이름 이름이 올바로 붙여 있는가? 관계 이름이 중복된 것은 없는가?

완전성

체크항목 질문
의존 관계 의존 관계와 독립 관계가 구별되어 정확히 표현되었나?
엔티티 빠진 엔티티는 없나?
연관 빠진 연관은 없나?

📌 ERD 주요 엔티티 정리

1. 고객 (Customer) 엔티티

역할: 쇼핑몰을 이용하는 사용자 주요 속성: 고객ID(PK), 이름, 이메일, 주소, 연락처 등 관계:

  • 고객 → 주문 (1:N, 고객은 여러 주문을 할 수 있음)
  • 고객 → 장바구니 (1:1 또는 1:N).
  • 고객 → 리뷰 (1:N, 여러 리뷰 작성 가능)

2. 상품 카테고리 (Category) 엔티티 역할: 상품을 분류하는 체계 주요 속성: 카테고리ID(PK), 카테고리명, 상위 카테고리ID(계층적 구조 가능) 관계:

  • 카테고리 → 상품 (1:N, 한 카테고리에 여러 상품 소속)

3. 상품 (Product) 엔티티 역할: 판매되는 개별 상품 주요 속성: 상품ID(PK), 상품명, 가격, 재고수량, 설명 등 관계:

  • 상품 → 주문상세 (1:N, 상품은 여러 주문에 포함될 수 있음)
  • 상품 → 장바구니아이템 (1:N)
  • 상품 → 리뷰 (1:N)
  • 상품 → 카테고리 (N:1)

4. 주문 (Order) 역할: 고객이 상품을 구매하기 위해 생성하는 거래 단위 주요 속성: 주문ID(PK), 고객ID(FK), 주문일자, 배송주소, 주문상태 관계:

  • 주문 → 주문상세 (1:N, 한 주문은 여러 상품을 가짐)
  • 주문 → 트랜잭션 (1:N, 주문에 대해 여러 결제/환불 내역이 있을 수 있음)

5. 주문상세 (OrderDetail) 역할: 주문 안에 포함된 개별 상품 항목 주요 속성: (주문ID + 상품ID) = PK (복합키), 수량, 단가. 관계:

  • 주문상세 → 주문 (N:1)
  • 주문상세 → 상품 (N:1)

특징: 부모의 PK를 포함하므로 Identifying 관계(실선)

6. 장바구니 (Cart / CartItem) 역할: 고객이 결제 전 담아둔 상품 목록 주요 속성: 카트ID(PK), 고객ID(FK), 상품ID(FK), 수량 관계:

  • 장바구니 → 고객 (N:1)
  • 장바구니 → 상품 (N:1)

7. 상품리뷰 (Review) 역할: 고객이 구매한 상품에 대해 남기는 평가/코멘트 주요 속성: 리뷰ID(PK), 고객ID(FK), 상품ID(FK), 평점, 내용, 작성일 관계:

  • 리뷰 → 고객 (N:1)
  • 리뷰 → 상품 (N:1)

8. 트랜잭션 (Transaction) 역할: 주문에 대해 발생한 금전적 거래 내역 (결제, 취소, 환불 등) 주요 속성: 트랜잭션ID(PK), 주문ID(FK), 결제일자, 결제수단, 금액, 상태 관계:

  • 트랜잭션 → 주문 (N:1)
]]> <![CDATA[이벤트 핸들러(Event Handler) 정리]]> https://velog.io/@dyeon-dev/%EC%9D%B4%EB%B2%A4%ED%8A%B8-%ED%95%B8%EB%93%A4%EB%9F%ACEvent-Handler https://velog.io/@dyeon-dev/%EC%9D%B4%EB%B2%A4%ED%8A%B8-%ED%95%B8%EB%93%A4%EB%9F%ACEvent-Handler Thu, 28 Aug 2025 17:01:25 GMT 이벤트와 핸들러의 기본 개념

"이벤트"는 우리가 웹 페이지에서 마우스를 클릭하거나 키보드를 누르는 것과 같은 사용자 행동, 또는 인풋 창에 포커스가 맞춰지거나 문서 로드가 완료되는 것과 같이 특정 시점에 발생하는 모든 행동을 의미한다. 이러한 이벤트가 발생했을 때 특정 함수를 실행하도록 할당하는 것을 "핸들러"라고 한다. 이벤트가 발생했을 때 브라우저에게 이벤트 핸들러의 호출을 위임하는 것을 이벤트 핸들러 등록이라 한다.

이처럼 이벤트와 그에 대응하는 함수(이벤트 핸들러)를 통해 사용자와 애플리케이션은 상호작용을 할 수 있다. 이와 같이 이벤트 중심으로 제어하는 방식을 이벤트 드리븐 프로그래밍(event-driven programming)이라 한다.

🚀 이벤트 핸들러 할당 방식

사용자가 버튼을 "클릭"했을 때 메시지를 처리하고 싶다면, 개발자가 명시적으로 함수를 호출하는 것이 아니라 브라우저에게 함수 호출을 위임하는 것이다. 아래의 코드를 살펴보면 알겠지만 onclick 프로퍼티에 함수를 할당했다.

HTML 속성 방식 (어트리뷰트 방식)

html과 js를 분리하지 않는 방식이다. onclick 어트리뷰트로 하게되면 함수 호출문을 직접 할당하는 방식이라 잘 쓰진 않는다.

하지만 CBD 방식의 Angular/React/Svelte/Vue.js 같은 프레임워크에서는 이벤트 핸들러 어트리뷰트 방식으로 이벤트를 처리한다. CBD에서는 HTML, CSS, JS가 다른 개별 요소가 아닌, 뷰를 구성하기 위한 요소로 보기 때문에 관심사가 다르다고 생각하지 않는다.

1. 인라인 코드로 작성

<button onclick="alert('click')">클릭</button>

2. onclick 속성에 직접 함수명 지정

  • 이벤트 핸들러 안에서 직접 실행할 코드를 문자열로 작성하는 방식이기 때문에 ()를 붙여야 실행 된다.
    <button onclick="sayHello()">클릭</button>
<script>
function sayHello() {
    alert("Hello");
}
</script>
  • onclick="sayHello()" 어트리뷰트는 파싱되어 다음과 같은 함수를 암묵적으로 생성하고, 이벤트 핸들러 어트리뷰트 이름과 동일한 키 onlick 이벤트 핸들러 프로퍼티에 할당한다.
    function onclick(event) {
sayHello();
}
  • 이처럼 동작하는 이유는 이벤트 핸들러에 인수를 전달하기 위해서다. 만약 이벤트 핸들러 어트리뷰트 값으로 함수 참조를 할당해야한다면 이벤트 핸들러에 인수를 전달하기는 곤란하다.
    <!-- 이벤트 핸들러에 인수를 전달하기는 x -->
<button onclick="sayHello">클릭</button>

JS에서 할당 방식 (이벤트 핸들러 프로퍼티 방식)

html과 js를 분리하는 방식이다. DOM 노드 객체는 이벤트에 대응하는 이벤트 핸들러 프로퍼티를 가지고 있다. 이벤트 핸들러 프로퍼티 키는 어트리뷰트와 마찬가지로 on+이벤트 종류를 나타내는 이벤트 타입으로 이뤄져있다. 이벤트 핸들러 프로퍼티에 함수를 바인딩하면 이벤트 핸들러가 등록된다.

3. DOM 요소에 ID를 부여한 후 자바스크립트에서 객체.핸들러 = 핸들러(함수) 할당

  • 이때 핸들러 할당 시 함수명 뒤에 괄호를 붙이지 않아야 함수 객체 자체를 직접 할당할 수 있다.
  • ()가 있으면, sayHello()가 즉시 실행된 결과값(여기서는 undefined)이 onclick에 들어가 버려서 크롬창 열자마자 alert 창이 떠버린다.
    <button id="btn">클릭</button>
<script>
const el = document.getElementById('btn')
el.onclick = sayHello;
</script>

4. addEventListener

  • 하나의 이벤트에 여러 핸들러를 등록할 수 있기 때문에 가장 권장되는 방식이다.
  • addEventListener도 이벤트 핸들러를 등록하는 방식과 삭제하는 방식이 다양하다.

4-1. addEventListener(이벤트, 함수핸들러)

<button id="btn2">클릭</button>
<script>
  function sayHello() {
    alert("Hello");
  }

  const el = document.getElementById('btn2')
  el.addEventListener("click", sayHello);
</script>

4-2. *addEventListener(이벤트, 함수 직접 작성) - 익명함수로 등록 *

<button id="btn2">클릭</button>
<script>
  const el = document.getElementById('btn2')
  el.addEventListener("click", () => {
      alert("Hello");
  });
</script>

4-3. addEventListener 삭제

  • removeEventListener를 사용하여 할당된 핸들러를 삭제

💡 이벤트 리스너 삭제할 때 주요포인트

  • 익명 함수(() => { ... })로 등록한건 제거가 불가능하다.
    <button id="btn2">클릭</button>
<script>
const el = document.getElementById('btn2');
// 익명 함수로 등록
el.addEventListener("click", () => {
  alert("Hello");
});
// 아래 코드는 제거 불가능 (참조가 다르기 때문)
el.removeEventListener("click", () => {
  alert("Hello");
});
</script>

- `removeEventListener`는 반드시 `addEventListener`에서 등록한 **동일한 함수 객체 참조**를 써야 작동하기 때문이다. JS 엔진은 겉보기엔 코드가 같아도, "완전히 별개 함수"로 인식하기 때문에 나중에 제거할 가능성이 있으면 별도 **함수 선언/변수에 담아서 등록**해야 한다.
```js
<button id="btn2">클릭</button>
<script>
  function sayHello() {
    alert("Hello");
  }

  const el = document.getElementById('btn2');

  // 이벤트 등록
  el.addEventListener("click", sayHello);

  // 3초 후에 이벤트 제거
  setTimeout(() => {
    // 함수 참조로 등록 → 제거 가능
    el.removeEventListener("click", sayHello);
    alert("이제 클릭해도 반응 안 함!");
  }, 3000);
</script>

4-4. DOMContentLoaded처럼 문서 로드 완료 시 발생하는 이벤트의 경우, 반드시 addEventListener를 사용해야 한다.

  • HTML에 직접 할당하면 동작하지 않는다.
  • DOMContentLoaded 전용 핸들러 속성(onDOMContentLoaded)은 없다. document.onDOMContentLoaded = ... 이런 건 동작 X
  • 반면, load, beforeunload 같은 이벤트는 window.onload, window.onbeforeunload 같은 핸들러 속성도 제공된다.

💡 팁 : 가급적 addEventListener로 통일하는 것이 좋다.

아래에서 DOMContentLoaded와 관련된 문서 로딩 시점의 이벤트제어를 정리했다.

📃 문서 로딩 시점의 이벤트 제어(DOMContentLoaded, load, beforeunload, unload)

공식 문서에 따르면 HTML 문서의 생명주기엔 다음과 같은 3가지 주요 이벤트가 관여한다고 한다.

  • DOMContentLoaded : 브라우저가 HTML을 전부 읽고 DOM 트리를 완성하는 즉시 발생한다. 이미지 파일(<img>)이나 스타일시트 등의 기타 자원은 기다리지 않는다.
  • onload : HTML로 DOM 트리를 만드는 게 완성되었을 뿐만 아니라 모든 콘텐츠(images, script, css, etc)가 모두 불러오는 것이 끝났을 때 발생한다.
  • beforeunload/unload : 사용자가 페이지를 떠날 때 발생한다.

따라서 위의 순서대로 생명주기가 실행된다. 각각의 시점 이벤트이기 때문에 이벤트를 주입해서 사용해주면 된다.

// only document
window.addEventListener("DOMContentLoaded", (event) => {
    console.log("DOMContentLoaded");
});

// after resources (css, images)
window.addEventListener("onload", (event) => {
    console.log("load");
});

// before unload
window.addEventListener("beforeunload", (event) => {
    console.log("beforeunload");
});

// resource is being unloaded
window.addEventListener("unload", (event) => {
    console.log("unload");
});

주로 어떤 상황에서 활용될까?

DOMContentLoaded

DOM이 준비된 것을 확인한 후 원하는 DOM 노드를 찾아 핸들러를 등록해 인터페이스를 초기화할 때 사용된다. 앞에서 언급했던 것처럼 이 이벤트를 다루려면 addEventListener를 사용해야 한다.

<script>
  function ready() {
    alert('DOM이 준비되었습니다!');

    // 이미지가 로드되지 않은 상태이기 때문에 사이즈는 0x0입니다.
    alert(`이미지 사이즈: ${img.offsetWidth}x${img.offsetHeight}`);
  }

  document.addEventListener("DOMContentLoaded", ready);
</script>

<img id="img" src="https://en.js.cx/clipart/train.gif?speed=1&cache=0">

위 예시에서 DOMContentLoaded은 DOM이 로드되었을 때 실행된다. 따라서 밑에 위치한 img뿐만 아니라 모든 요소에 접근할 수 있다. 하지만 이미지 파일의 로딩은 기다리지 않기 때문에 alert 창에는 이미지 사이즈가 0으로 뜬다.

이와 같은 특징을 브라우저 렌더링 과정에 대입해서 살펴보자.

💡 "렌더링 과정 중 DOM 트리가 완성되면 DOMContentLoaded 이벤트가 발생한다"

여기서 말하는 DOM 트리가 완성되는 단계를 브라우저가 동기적으로, 즉 위에서 아래로 순차적으로 실행되는 관점에서 좀 더 자세히 살펴보자. 이 과정에서 HTML을 파싱하면서 자바스크립트와 CSS를 만났을 때 DOMContentLoaded 이벤트처리는 어떻게 되는가?

1. HTML 문서를 처리하는 도중에 <script> 태그를 만났을 때

  • DOM 트리 구성을 중단하고 <script>를 실행한다. <script>가 끝나면 다시 HTML 문서 처리를 재개한다.
  • 따라서 DOMContentLoaded 이벤트 역시 <script> 안에 있는 스크립트가 처리되고 난 후에 발생한다.
    <script>
document.addEventListener("DOMContentLoaded", () => {
  alert("DOM이 준비되었습니다!");
});
</script>

- 위 코드의 결과를 보면, 스크립트가 모두 실행되고 나서야 DOMContentLoaded 이벤트가 발생한다.
- 따라서 "라이브러리 로딩이 끝나고…"가 먼저 보인 후 "DOM이 준비되었습니다!"가 출력된다.

**2. HTML 문서를 처리하는 도중에 외부 스타일시트를 만났을 때**
- HTML 파싱 중에 `<link rel="stylesheet">`를 만나면 CSS 파싱은 비동기적으로 진행될 수 있다. 즉, **외부 스타일시트는 DOM에 영향을 주지 않기 때문에 DOMContentLoaded는 외부 스타일시트가 로드되기를 기다리지 않는다.**
- 따라서 DOMContentLoaded 이벤트가 발생할 때 CSSOM이 모두 준비됐다는 보장은 없다.
- 보통은 **CSS 파일이 아직 다운로드 중이어도 DOMContentLoaded가 발생**할 수 있다.

- 💥 그런데 한가지 예외가 있다. **스타일시트를 불러오는 태그 바로 다음에 스크립트가 위치하면 이 스크립트는 스타일시트가 로드되기 전까지 실행되지 않는다.**
```js
<link type="text/css" rel="stylesheet" href="style.css">
<script>
  // 이 스크립트는 위 스타일시트가 로드될 때까지 실행되지 않습니다.
  // 스크립트에서 요소의 좌표 정보를 사용하고 있다.
  alert(getComputedStyle(document.body).marginTop);
</script>
  • <link>와 <script> 사이에 다른 태그가 끼면, 스크립트 실행이 그 CSSOM을 보장해서 기다리지는 않는다.
  • 왜냐하면 그 시점에서는 해당 스크립트가 “바로 직전에 선언된 스타일시트와 직접 연관 있을 가능성”이 낮다고 보기 때문이다.

load

DOMContentLoaded 이벤트는 DOM만 보장했다면, load 이벤트는 DOM + CSSOM + 이미지/폰트 같은 모든 리소스까지 준비 완료되었을 때 실행된다.

<script>
  window.onload = function() { // window.addEventListener('load', (event) => {와 동일합니다.
    alert('페이지 전체가 로드되었습니다.');

    // 이번엔 이미지가 제대로 불러와 진 후에 실행됩니다.
    alert(`이미지 사이즈: ${img.offsetWidth}x${img.offsetHeight}`);
  };
</script>

<img id="img" src="https://en.js.cx/clipart/train.gif?speed=1&cache=0">
  • 위 예시에서 window.onload는 이미지가 모두 로드되고 난 후 실행되기 때문에 이미지 사이즈가 제대로 출력된다.

beforeunload

사용자가 페이지를 떠날 때 추가 확인을 요청할 수 있는데, 이는 beforeunload를 통해 제어해주면 된다.

// use addEventListener beforeunload
window.addEventListener("beforeunload", (event) => {
  // 표준에 따라 기본 동작 방지
  event.preventDefault();
  // Chrome에서는 returnValue 설정이 필요함
  event.returnValue = "";
});

  • 페이지를 벗어날때 나오던 위와 같은 알림 창이 바로 이런 상황에서 처리를 해준 것이다. 이벤트를 막아서 "정말 떠날 건지 확인"하는 경고창을 띄울 수 있다.
  • 표준(HTML Living Standard) 에서는 event.preventDefault() 호출만으로도 충분하다고 정의돼 있다. 하지만 크롬, 사파리, 엣지, 파이어폭스 등 주요 브라우저에서는 호환성을 위해 event.returnValue에 무언가를 할당해야 대화상자가 뜨도록 바뀌었다.

unload

unload 페이지가 완전히 종료될 때 마지막으로 할 수 있는 작업 이벤트이다. 페이지 종료 시 마지막 정리 작업이나 통계, 로그 전송 같은 목적에만 쓸 수 있다. 만약, 사용자와 상호작용(경고창 등)을 하려면 반드시 beforeunload를 써야 한다.

unload 이벤트는 사용자가 페이지를 떠날 때 발생하므로 unload 이벤트에서 분석 정보를 서버로 보낼 수도 있을 것이다.

세션 종료 로그 보내기

window.addEventListener("unload", () => {
  // 사용자가 페이지를 떠날 때 서버로 로그 전송
  navigator.sendBeacon("/log", JSON.stringify({ action: "exit", time: Date.now() }));
});

Analytics / 페이지 사용 통계 기록

window.addEventListener("unload", () => {
  // 페이지를 떠날 때 사용자가 머문 시간을 서버에 기록
  const timeSpent = Date.now() - performance.timing.navigationStart;
  navigator.sendBeacon("/analytics", JSON.stringify({ timeSpent }));
});
  • navigator.sendBeacon()를 쓰면 비동기 HTTP 요청을 안전하게 보낼 수 있다.
  • 일반 fetch나 XMLHttpRequest는 unload 시점에서는 대부분 취소된다.

⌨️ 자주 사용되는 이벤트(Event)

다양한 이벤트 타입이 있지만, 자주 사용되는 몇 가지를 중심으로 살펴보자.

마우스 클릭 이벤트

  • click : 요소를 클릭할 때 발생
  • dblclick : 더블 클릭할 떄 발생

키보드 이벤트

이벤트 객체를 인수로 받아, 어떤 키가 눌렸는지(event.key), 현재 이벤트 타입(event.type) 등 다양한 정보를 활용할 수 있다.

  • keyup: 누른 키에서 손을 뗄 때 실행
  • keydown: 키보드를 누를 때 실행. 키를 누르고 있을 때 단 한번만 실행
  • keypress(deprecated): 키보드를 누를 때 실행. 키를 누르고 있을 때 계속 실행

1️⃣ keyup

  • 언제? 키에서 손을 뗐을 때 실행

  • 특징

    • 입력이 끝났을 때를 감지할 수 있음
    • 입력 중에는 동작 안 하고, 손을 뗐을 때만 발생

  • 사용 예시

    • 검색창 자동완성 (keyup 시점에 서버 요청 보내기)
    • 입력 완료 후 유효성 검사 (비밀번호 길이, 이메일 포맷 체크 등)
    • 키 누르고 있다가 뗄 때 어떤 동작을 멈추는 상황 (게임 캐릭터 이동 중지)

  • 사용법

    • 핸들러는 이벤트객체 (event) 를 인수로 받음.

      <body>
<input id="text" type="text" />

<script>
const input = document.getElementById("text");
input.addEventListener("keyup", (event) => {
  console.log("현재 입력값:", event, event.key);
});
</script>
</body>

  • 결과값

    - `"텍스트"` : 입력한 특정 텍스트가 콘솔창에 출력됨
- `event` : 해당 키보드 이벤트 관련된 모든 정보가 콘솔창에 출력됨
- `event.key` : 오직 키보드 값만 콘솔창에 출력됨

2️⃣ keydown

  • 언제? 키를 "누르는 순간" 단 한 번 실행
  • 특징
    • 어떤 키든(문자, 화살표, F1~F12, ESC 등) 전부 인식 가능
    • 반복 입력(꾹 누르고 있을 때도 계속 발생)
  • 사용 예시
    • 단축키 구현 (Ctrl + S, ESC 눌렀을 때 동작 등)
    • 방향키로 캐릭터 움직이기
    • 입력 도중 특정 키 막기 (예: 숫자만 입력 허용)
      document.addEventListener("keydown", (e) => {
if (e.key === "Escape") {
console.log("ESC 눌렀다!");
}
});

3️⃣ keypress (⚠️ 현재는 표준에서 deprecated, 대부분 keydown으로 대체)

  • 언제? 키를 눌러서 실제 "문자"가 입력될 때 실행
  • 특징
    • 문자를 표현할 수 있는 키만 인식 (예: a, 1, ; 등)
    • 화살표키, F1 같은 제어 키는 감지 못함
    • 한글/이모지 같은 조합형 문자는 제대로 인식되지 않음
  • 사용 예시
    • 과거에는 "입력되는 문자 자체" 확인할 때 사용했음 (예: 텍스트 입력 감시)
    • 지금은 input 이벤트나 keydown을 대신 사용 권장

key 이벤트 발생 순서

키를 누르면 keydown 이벤트가 발생, 이어서 바로 keypress 이벤트가 발생. 그런 다음 키가 해제되면 keyup 이벤트가 생성된다.

💡 keydown > keypress > keyup 순으로 이벤트 진행

직접 코드로 확인: https://jsbin.com/vigimenaji/edit?html,output

포커스 이벤트(Input 창)

  • focus : 포커스가 맞춰질 때

  • blur : 포커스를 잃을 때

  • 사용자가 폼에 입력할 때 UI를 동적으로 변경할 수 있다. 

    <body>
  <input id="text" type="text" />

  <script>
    const input = document.getElementById("text");
    input.addEventListener("focus", () => {
      input.style.backgroundColor = "lightblue";
    });

    input.addEventListener("blur", () => {
      input.style.backgroundColor = null;
    });
  </script>
</body>

마우스 이벤트

  • mousemove : 마우스를 움직일 때마다 발생한다.
    • event.clientX와 event.clientY를 사용하여 마우스 포인터의 현재 위치를 파악할 수 있다.
    • 이를 활용하여 웹 페이지에서 마우스 커서를 따라 움직이는 요소를 만들 수 있다. 
 <body>
    <div
      id="box"
      style="
        position: relative;
        width: 100px;
        height: 100px;
        border: 2px solid lightblue;
      "
    ></div>

    <div
      id="circle"
      style="
        position: absolute;
        width: 10px;
        height: 10px;
        background-color: lightpink;
        border-radius: 50%;
      "
    ></div>

    <script>
      const box = document.getElementById("box");
      const circle = document.getElementById("circle");

      box.addEventListener("mousemove", (event) => {
        circle.style.top = `${event.clientY}px`;
        circle.style.left = `${event.clientX}px`;
      });
    </script>
  </body>

윈도우 이벤트

  • resize : 윈도우 창의 크기가 변경될 때 발생한다.
    • 오직 window 객체에서만 발생한다.
    • 이를 통해 창의 너비와 높이 값을 업데이트하여 반응형 웹 디자인에 활용할 수 있다.
      <script>
window.addEventListener("resize", () => {
  document.body.innerText = `현재 창 크기는 ${window.innerWidth} x ${window.innerHeight}`;
});
</script>

값 변경 이벤트

  • input: 입력 필드의 값이 어떤 방식으로든 변경되었을 때마다 발생

    • 사용자가 키보드로 입력하는 것뿐만 아니라, 마우스로 붙여넣기, 음성 인식, 드래그 슬라이더 조작 등 다양한 방법으로 입력 필드(input, textarea, checkbox, radio, select 등)의 값이 달라졌을 때 트리거된다.
    • 따라서 실시간으로 입력 필드 값의 변화를 감지하여 즉각적으로 반응해야 하는 경우 유용하게 사용된다.
      • 실시간 유효성 검사: 사용자가 입력할 때마다 입력값의 유효성을 검사하여 오류 메시지를 즉시 보여줄 수 있다.
      • 값 변화 시 처리: 입력 필드에 텍스트를 입력하면 해당 텍스트를 다른 요소에 즉시 표시하거나, 특정 단어를 다른 것으로 자동으로 바꾸는 등의 처리를 할 수 있다. 
        <input type="text" id="input"> oninput: <span id="result"></span>
<script>
input.oninput = function() {
result.innerHTML = input.value;
};
</script>

  • change: 입력 필드에서 포커스가 해제된 후에 값이 변경되었을 때 발생

    • change 이벤트는 input 이벤트와는 달리 HTML 요소가 포커스를 잃었을 때 사용자 입력이 종료되었다고 인식하여 발생한다. 
      <input type="text" onchange="alert(this.value)">
<input type="button" value="버튼">

즉, 사용자가 입력을 하고 있을 때는 input 이벤트가 발생하고, 사용자 입력이 종료되어 값이 변경되면 change 이벤트가 발생한다.

참고자료

]]> <![CDATA[로그인 방식에는 어떤 것들이 있을까? Express에 적용해보자 (세션, 쿠키)]]> https://velog.io/@dyeon-dev/%EB%A1%9C%EA%B7%B8%EC%9D%B8-%EB%B0%A9%EC%8B%9D%EC%97%90%EB%8A%94-%EC%96%B4%EB%96%A4-%EA%B2%83%EB%93%A4%EC%9D%B4-%EC%9E%88%EC%9D%84%EA%B9%8C-Express%EC%97%90-%EC%A0%81%EC%9A%A9%ED%95%B4%EB%B3%B4%EC%9E%90-%EC%84%B8%EC%85%98-%EC%BF%A0%ED%82%A4 https://velog.io/@dyeon-dev/%EB%A1%9C%EA%B7%B8%EC%9D%B8-%EB%B0%A9%EC%8B%9D%EC%97%90%EB%8A%94-%EC%96%B4%EB%96%A4-%EA%B2%83%EB%93%A4%EC%9D%B4-%EC%9E%88%EC%9D%84%EA%B9%8C-Express%EC%97%90-%EC%A0%81%EC%9A%A9%ED%95%B4%EB%B3%B4%EC%9E%90-%EC%84%B8%EC%85%98-%EC%BF%A0%ED%82%A4 Tue, 26 Aug 2025 13:38:54 GMT 우리가 사용하는 브라우저는 HTTP 통신을 통해 클라이언트와 서버가 통신을 한다. 그런데 이 HTTP 규약은 stateless하다는 특징이 있다. 그럼 사용자가 로그인을 할 때 새 탭에서 로그인을 할 경우 매번 로그인을 시도해야 된다. 그래서 로그인을 할 때 정보를 어딘가에 저장해두면 문제를 쉽게 해결할 수가 있다.

그 때 사용하는 것이 바로 브라우저의 스토리지이다. 쿠키 같은 것을 사용해서 해당 로그인 정보를 브라우저에 저장해서 로그인을 편리하게 구현할 수 있다.

쿠키란?

  • 쿠키는 서버가 클라이언트에게 전송하는 작은 데이터 파일이다.
  • 쿠키는 클라이언트에 저장되고 key와 value로 구성된다. 
  • 서버에게 받은 쿠키는 정보들을 웹 브라우저에 저장하고 
  • 브라우저가 자동으로 요청 시마다 쿠키를 서버로 전송한다.
  • 용량 제한이 있다. (도메인별 약 4KB 정도)

쿠키의 수명과 브라우저 동작

쿠키는 만료 시간(Expire/Max-Age)에 따라 세션 쿠키(브라우저 종료 시 삭제) / 영속 쿠키(만료일까지 유지)로 나뉜다.

  • 세션 쿠키 (Session Cookie): Expires나 Max-Age를 설정하지 않은 경우 기본값
    • 브라우저 종료 시 자동 삭제
    • 로그인 유지가 되지 않음
  • 영속 쿠키 (Persistent Cookie): Expires(특정 날짜/시간)나 Max-Age(초 단위 유효시간)를 지정한 경우
    • 지정한 시간이 될 때까지 브라우저를 껐다 켜도 그대로 남아있음
    • 자동 로그인 유지 가능

{ Expires, Max-Age } 옵션을 지정하지 않으면 원래는 세션 쿠키가 되어야 한다. 즉, 브라우저를 닫으면 삭제되는 게 정상이다. 그런데 브라우저마다 동작이 좀 다르다!

  • Chrome, Edge, 일부 최신 브라우저 → 세션 복원(Session Restore) 기능이 켜져 있으면, 세션 쿠키도 다시 복원해버린다. 그래서 브라우저를 종료했다 다시 열어도 쿠키가 남아있는 것처럼 보인다.
  • Firefox, Safari → 옵션을 껐으면 세션 쿠키는 닫을 때 지워진다.

🔑 쿠키 로그인 방식

  1. 클라이언트가 로그인을 시도한다.
  2. 로그인을 성공했을 경우, 서버는 토큰을 생성해서 클라이언트에 전달한다.
  3. 클라이언트는 쿠키에 토큰을 저장한다.
  4. 해당 웹사이트를 방문할 때마다 쿠키는 서버에 보내지게 된다.
  5. 서버에서는 토큰이 유효한지 판단을 하며 클라이언트와 통신한다.

이 과정에서 중요한 부분은 클라이언트에 저장이 된다는 점이다. 이 사실은 여러 상황으로 직결될 수 있다.

  • 모든 브라우저에서 지원한다.
  • 서버에서 따로 저장을 하지 않기 때문에 서버 과부화가 일어나지 않는다.
  • 누군가가 쿠키에 담긴 나의 토큰 정보를 빼앗긴다면 나인척 할 수 있다. (보안 취약)   보안적으로 봤을 때, 토큰이 탈취 될 가능성이 있어서 쿠키만 사용한다는 것은 좋은 생각이 아니다.

그래서 로그인을 유지시키기 위해서는 쿠키 방법에 세션 방법을 추가해서 중요한 정보는 서버에 저장하여 보안을 관리한다.

세션이란?

  • 세션은 브라우저 저장소가 아니다.
  • 세션은 서버 메모리/DB 같은 서버 측에 저장되는 정보이다.
  • 세션은 “로그인한 사용자" 정보를 쿠키에 저장하지 않고 서버에 저장하며, 대신 쿠키에는 이를 식별할 수 있는 세션 ID를 저장한다. 
  • 이처럼 세션도 쿠키를 이용하지만 추정 불가능한 세션 ID를 주고받기 때문에 보안상 안전하다. 
  • 따라서 노출되면 안 되는 중요한 정보는 세션을 이용하여 저장한다.
  • 세션은 서버에 저장되다 보니까, 너무 많이 담기면 서버 과부화가 일어날 가능성이 생긴다.
  • 서버에서 사용되다 보니까, 쿠키보다는 탈취되는 과정이 어렵다.

⚠️ 주의) 여기서 말하는 세션은 세션 스토리지랑은 다른거다!

 

🔑 전통적인 세션 로그인 방식

  1. 클라이언트가 로그인을 시도한다.
  2. 로그인에 성공했을 경우, 서버는 클라이언트 고유 세션 ID를 생성하고 서버에 저장한다.
  3. 서버는 클라이언트에게 세션 ID를 전달하고 쿠키에 저장한다.
  4. 클라이언트는 세션 ID를 쿠키에서 가져오면서 서버와 통신한다.
  5. 서버는 세션 ID가 유효한지 확인한다.   세션 방식에서는 세션 ID의 반쪽은 사용자 브라우저에 쿠키로 저장되고, 나머지 반쪽은 서버에 저장된다고 생각하면 된다.

이처럼 이 세션 ID를 사용해서 어떤 사용자가 서버에 로그인 되었음이 지속되는 이 상태를 '세션'이라고 한다.

정리

  • 쿠키 = 브라우저 저장소 (데이터 자체가 클라이언트에 있음)
  • 세션 = 서버 저장소 (브라우저에는 "세션ID"만 저장, 본 데이터는 서버에 있음)

Express 환경에서 session + cookie 적용해보기

🔧 서버 개발 환경

Node.js: v22 (LTS)
Express: v5.1.0
템플릿 엔진 EJS: v3.1.10
low DB: NeDB

🤔 고민과 선택 과정

세션+쿠키 방식의 로그인을 적용하기 전에, express-session + nedb-session-store 모듈을 사용할지 직접 세션을 커스텀할지 고민하였다. 왜냐하면 세션ID를 만들어서 세션DB까지 구현하는 요구사항이라면, 굳이 모듈에 대한 의존성 없이도 커스텀 방식으로 구현은 가능하기 때문이다. 하지만 아래와 같은 이유로 각각의 특징과 트레이드오프를 생각해서 모듈 방식으로 선택했다.

커스텀 세션 방식 (NeDB+sid)

  • 현재 NeDB를 사용중이라 동일한 스토리지로 간단하게 확장이 가능하다. 따로 세션 저장소 구현체를 설치하지 않아도 된다.
  • 커스텀 로직(세션 스키마, 만료 정책 등)을 세밀하게 제어하기에 용이하다.
  • 의존성 최소화하기 위해 굳이 모듈이 없어도 요구사항을 충족할 수 있다.
  • 쿠키와 세션 옵션을 따로 설정해줘야 한다.
    // 세션 생성 및 쿠키 설정
const sessionId = randomUUID()
const now = Date.now()
const maxAgeMs = 1000 * 60 * 60 * 24 * 7 // 7일
await createSession({
sessionId,
username: user.username,
nickname: user.nickname,
createdAt: new Date(now).toISOString(),
expiresAt: new Date(now + maxAgeMs),
})
res.cookie('sid', sessionId, {
httpOnly: true,
sameSite: 'lax',
maxAge: maxAgeMs,
})

모듈 방식 (express-session, nedb-session-store)

  • express-session를 사용하면 세션 ID를 저장하기 위한 호환되는 세션 스토어 사용을 권장한다.
  • 이후 Redis나 MongoDB와 같은 스토어와 교체 용이성이 좋다.
  • 세션 스토어를 사용하면 Passport, Flash, CSRF 등 express-session에 기대는 미들웨어를 함께 쓸 때 유용하다.
  • 쿠키와 세션 옵션이 일원화되어 있어 편리하게 로직을 관리할 수 있다.
    app.use(session({
  secret: 'your-secret',      
  resave: false,
  saveUninitialized: false,
  cookie: {
    httpOnly: true,
    sameSite: 'lax',
  }
}))

요구사항 충족과 더불어 확장성을 고려해서 모듈 방식을 선택했다. lowDB로 NeDB를 선택했던 것도 mongoDB와 유사성 및 교체 용이성을 바라보고 결정했기 때문에 이번에도 스토어와의 교체 용이성을 위해 nedb-session-store를 사용했다. 그리고 모듈의 쿠키+세션 옵션이 간편한 것도 좋았다.

구현 과정

  1. session과 cookie-parser, nedb-session-store 모듈 설치 npm i express-session cookie-parser nedb-session-store
  • express-session: 세션 관리용 미들웨어로 세션 관리 시 클라이언트에 세션 쿠키를 보낸다.
  • cookie-parser: 요청과 함께 들어온 쿠키를 해석하여 곧바로 req.cookies객체로 만든다.
  • nedb-session-store: 세션 데이터를 NeDB 파일(DB)로 저장하게 해주는 어댑터로 express-session의 세션 저장소(store) 구현체 중 하나이다.
  1. app.js 설정
  • 세션은 사용자별로 req.session 객체 안에 유지된다.
  • 안전하게 쿠키를 전송하려면 쿠키에 서명을 추가해야하고, 쿠키를 서명할 때 secret 값이 필요하다.
    • cookie-parser의 secret과 같게 설정하는 것이 좋다.
const cookieParser = require('cookie-parser')
const session = require('express-session')
const NedbStore = require('nedb-session-store')(session)

// cookieParser에 비밀키를 넣어 요청온 쿠키값이 내가 서명한 쿠키인지 파악한다.
// 암호 키를 작성하는 것에는 크게 규격이 없으며 개발자의 자유이다. 단 쉽게 유추할 수 있는 값은 사용하지 말자.
app.use(cookieParser(process.env.COOKIE_SECRET);

app.use(session({
  secret: process.env.COOKIE_SECRET, // 암호화하는 데 쓰일 키
  resave: false, // 세션을 언제나 저장할지 설정함
  saveUninitialized: true, // 세션에 저장할 내역이 없더라도 처음부터 세션을 생성할지 설정
  store: new NedbStore({ filename: './data/sessions.db' }), // 세션 객체에 세션스토어를 적용 
  cookie: {    //세션 쿠키 설정 (세션 관리 시 클라이언트에 보내는 쿠키)
    maxAge: 1000 * 60 * 60 * 24 * 7,
    httpOnly: true, // 자바스크립트를 통해 세션 쿠키를 사용할 수 없도록 함
    sameSite: 'lax', // CSRF 위험을 줄임, 완전 차단은 아니고 “안전한” 탐색에서만 허용
    // Secure: true // https 환경에서만 session 정보를 주고받도록처리
  },
  // name: 'session-cookie' // 세션 쿠키명 디폴트값은 connect.sid이지만 다른 이름을 줄수도 있다.
}));

app.get('/', (req, res, next) => {
 // 세션에 데이터를 설정하면, 모든 세션이 설정되는게아니라, 요청 받은 고유의 세션 사용자의 값만 설정 된다.
 // 즉, 개인의 저장 공간이 생긴 것과 같다.
 req.session.id = "hello"; 
}

✍️ 인증(서명)된 쿠키

cookieParser(process.env.COOKIE_SECRET) cookieParser의 첫번째 인수로 비밀 키를 넣어줄 수 있다. 서명된 쿠키가 있는 경우, 제공한 비밀 키를 통해 해당 쿠키가 내가 만든 쿠키임을 검증할 수 있다. 쿠키는 클라이언트에서 위조하기 쉬우므로, 비밀 키를 통해 만들어낸 서명을 쿠키 값 뒤에 붙이는 것이다! 이렇게 작성하면 서명된 쿠키를 생성하고 활용할 때 서버와 클라이언트 PC만 알아볼 수 있도록 통신하게 된다.

💾 세션 스토어

세션 스토어는 세션이 데이터를 저장하는 곳을 말한다. 대표적으로 Memory Store, File Store, Mongo Store 가 있다. default 값은 Memory Store인데, 메모리는 서버나 클라이언트를 껐다 키면 사라지는 휘발성이다. 그래서 세션을 저장할 고유 저장소를 따로 지정해야 한다.

  • 어떤 DB를 사용하는지 따라서 store를 이 API 문서를 보고 선택하면 된다.

필자는 인메모리 방식인 nedb-session-store를 설치해서 lowDB로 저장 관리했다.

이렇게 하고 나서 처음 서버를 올리면 sessions.db 가 생긴다. 사용자가 로그인에 성공해서 서버에 접속할 때 이 sessions.db에 유저 정보의 세션 ID가 생긴다.

{
   "_id":"RIERELq-eIFQ-Uw9ubtI1mL749qAhu_K",
   "session":{
      "cookie":{
         "originalMaxAge":604800000,
         "expires":{
            "$$date":1756807508766
         },
         "httpOnly":true,
         "path":"/",
         "sameSite":"lax"
      },
      "user":{
         "username":"ekdus",
         "nickname":"dayeonkim"
      }
   },
   "expiresAt":{
      "$$date":1756807578016
   },
   "createdAt":{
      "$$date":1756202708767
   },
   "updatedAt":{
      "$$date":1756202778017
   }
}

_id 가 세션 ID로 생성되었다.

브라우저에서 세션 쿠키를 확인해보면

connect.sid: s:RIERELq-eIFQ-Uw9ubtI1mL749qAhu_K.C5F3R%2FIMTdZkfQVa%2FiBld1Z6zn0CwyQ3ifjwjDVejQo

connect.sid로 같은 RIERELq-eIFQ-Uw9ubtI1mL749qAhu_K 값으로 생성된걸 확인할 수 있고, .뒤에 C5F3R%2FIMTdZkfQVa%2FiBld1Z6zn0CwyQ3ifjwjDVejQo 값은 COOKIE_SECRET으로 서명(signature)된 값이다. 이는 암호화(encryption)와는 다른 값이다. s는 서명(signed) 쿠키라는 표시이다.

  1. loginController 설정
    // POST /login
const postLogin = async (req, res) => {
 try {
     const { username, password } = req.body
     const user = await findUserByUsername(username)
     // 세션에 사용자 정보 저장
     req.session.user = { username: user.username, nickname: user.nickname }
     return res.status(200).json({ success: true, message: '로그인 성공' })
 } catch (err) {
     console.error('postLogin error:', err)
     return res.status(500).json({ success: false, message: '서버 오류' })
 }
}
    req.session.user에 사용자 정보(이름, 닉네임)를 저장해서 세션 스토어에 값이 같이 저장되도록 했다. 이렇게 하면 로그인 이후 요청들에서 미들웨어가 connect.sid로 세션을 찾아 req.session.user를 다시 채워준다. 그래서 매번 DB 조회할 필요없이 어디서든 req.session.user로 로그인 상태/사용자 식별이 가능하다.

세션의 한계와 보안 이슈

세션은 쿠키보다 안전해 보이지만, 단점도 존재한다.

  1. 서버 자원 부담
    세션은 서버 메모리/DB에 저장되므로, 동시 접속자가 많을수록 서버에 부하가 생길 수 있다.
    (해결책: Redis 같은 외부 세션 저장소를 사용)

  2. 확장성 문제
    서버를 여러 대 운영할 때 세션을 공유하지 않으면 사용자마다 로그인 상태가 달라지는 문제가 생긴다.
    (해결책: 공용 세션 저장소 사용)

  3. 세션 하이재킹 위험
    세션 ID가 탈취되면, 아이디/비밀번호를 몰라도 그대로 로그인 상태가 된다.
    (예: XSS, 네트워크 스니핑, 세션 고정 공격 등)

방어 방법

  1. 쿠키 보안 속성
  • HttpOnly: true → JS에서 접근 차단(XSS 방어)
  • Secure: true → HTTPS에서만 전송
  • SameSite: strict/lax → CSRF 공격 방어
  1. 세션 관리
  • 로그인 성공 시 세션 ID를 새로 발급(Session Regeneration)
  • 세션에 IP, User-Agent 등을 기록해서 매 요청마다 검증
  • 일정 시간 활동 없으면 세션 만료 (Idle Timeout)
  1. 전송 보안
  • HTTPS 필수 → 네트워크에서 세션 ID 탈취 방지 확장성
  • Redis 같은 외부 세션 스토어 사용 → 서버 여러 대 운영 시에도 안정적

이런 방법들을 조합해야 안전한 세션 관리가 가능하다.

참고자료

cookie-parser, sign

session 미들웨어

]]> <![CDATA[렌더링 방식 어떤걸 선택하는게 좋을까? CSR(SPA), SSR(MPA)]]> https://velog.io/@dyeon-dev/%EB%A0%8C%EB%8D%94%EB%A7%81-%EB%B0%A9%EC%8B%9D-%EC%96%B4%EB%96%A4%EA%B1%B8-%EC%84%A0%ED%83%9D%ED%95%98%EB%8A%94%EA%B2%8C-%EC%A2%8B%EC%9D%84%EA%B9%8C-CSRSPA-SSRMPA https://velog.io/@dyeon-dev/%EB%A0%8C%EB%8D%94%EB%A7%81-%EB%B0%A9%EC%8B%9D-%EC%96%B4%EB%96%A4%EA%B1%B8-%EC%84%A0%ED%83%9D%ED%95%98%EB%8A%94%EA%B2%8C-%EC%A2%8B%EC%9D%84%EA%B9%8C-CSRSPA-SSRMPA Mon, 25 Aug 2025 13:31:18 GMT 초창기 웹 애플리케이션 (MPA, SSR)

📌 MPA (Multi-Page Application)

  • 다중 페이지로 이뤄져있어 변경사항이 있을 때마다 서버로 페이지를 요청해서 새로 렌더링 한다.

웹 애플리케이션의 역사를 보자면, 초창기 웹은 텍스트 중심의 단순 문서였다. 따라서 MPA(Multi-Page Application) 방식으로 구현되었다. MPA는 페이지 변경시마다 서버에 페이지 요청을 하여 새로고침이 발생하고 깜빡임이 있었다. 웹의 발전과 함께 복잡도가 증가하면서 MPA 방식의 성능 이슈가 발생했다.

이후 2004년 웹 시장에서는 굉장히 획기적인 일이 발생한다. 바로 제시 제임스(Jesse James)라는 사람이 Ajax 기술 사양을 발표하여 JavaScript를 통해 서버로부터 비동기적으로 데이터를 처리하는 획기적인 기술을 제시했다. Ajax 기술의 등장으로 필요한 부분만 리로드할 수 있게 되어 성능 문제가 해결되었다.

📌 전통적인 Page기반 SSR (Server-Side Rendering)

이런식으로 서버에서 html로 페이지를 다 만들어서 클라이언트에게 주는 것을 SSR이라고 한다.

SSR 동작 흐름

  1. 사용자가 웹 접속 후 브라우저가 서버에 리소스를 요청한다.
  2. 서버는 즉시 렌더링 가능한 초기 콘텐츠가 로딩된 html 파일을 만든다. (리소스 체크, 컴파일 후 완성된 HTML 컨텐츠로 만든다.)
  3. 초기 렌더링: 브라우저에 전달되는 순간, 이미 렌더링 준비가 되어있기 때문에 HTML은 즉시 렌더링 된다. 그러나 사이트 자체는 조작 불가능하다. (Javascript가 읽히기 전이다.)
  4. JS 처리: 브라우저가 자바스크립트를 다운받는다. 다운 받아지고 있는 사이에 유저는 콘텐츠는 볼 수 있지만 사이트를 조작할 수는 없다. 이때의 사용자 조작을 기억하고 있는다.
  5. JS가 서버에서 전달된 HTML에 이벤트리스너 등을 할당해서 인터랙티브한 페이지를 제공한다. JS까지 성공적으로 컴파일 되었기 때문에 기억하고 있던 사용자 조작이 실행되고 이제 웹 페이지는 상호작용 가능해진다.

SSR 특징 - 웹 성능 지표 관점

  • 👍 FCP가 빠르다.
    • FCP(First Contentful Paint): 사용자가 화면에서 콘텐츠를 볼 수 있는 페이지 로드 타임라인의 첫 번째 지점
  • 👎 TBT가 발생한다.
    • Total Blocking Time(TBT) : FCP로부터 TTI(사용자가 페이지에서 상호작용이 가능한 시점)까지의 시간

더욱 늘어난 니즈 (SPA, CSR)

📌 SPA (Single-Page Application)

하지만 갈수록 더욱 복잡해지는 애플리케이션은 니즈가 늘어났다. 하나의 페이지 안에서 데이터를 받아 와서 필요한 부분만 부분적으로 업데이트하도록 하는 SPA(Single-Page Application)가 등장했다.

📌 CSR (Client-Side Rendering)

CSR은 모든 렌더링 작업을 브라우저에서 수행하는 방식이다. 서버로부터 최소한의 HTML과 JS 파일을 받아 브라우저가 이를 기반으로 UI를 동적으로 생성한다. CSR은 빠르게 SPA의 표준으로 자리잡았으며 페이지 전환 시 전체 페이지를 다시 로드하지 않고 필요한 부분만 업데이트함으로써 사용자 경험을 크게 향상했다.

CSR 동작 흐름

  1. 사용자가 웹 접속 후 브라우저가 서버에 리소스 요청한다.
  2. 서버는 간단한 HTML 파일과 JS 파일을 브라우저로 전송한다. 주로 <div id="root"></div>와 같은 최소한의 구조만 포함된다. (TTFB)
  3. 초기 렌더링: 브라우저가 HTML과 CSS를 다운로드하고 렌더링해서 초기 페이지 구조를 만든다. (이때 SSR과 달리 사용자는 빈 화면을 보게된다.)
  4. JS 처리: 브라우저는 HTML에 포함된 script 태그를 통해 JS를 다운로드하고 실행한다.
  5. JS가 서버에서 전달된 HTML에 기능을 추가해서 페이지가 인터렉티브해진다.
  6. fetching data: 데이터를 위한 API가 호출되고, 서버가 API로부터의 요청에 응답한다. (이때 사용자는 placeholder를 보게 된다.)
  7. API로부터 받아온 data를 placeholder 자리에 넣어준다.
  8. UI 완성: 이 데이터를 기반으로 UI가 완성되고, 이때 LCP(Largest Contentful Paint)가 측정된다.

CSR 특징 - 웹 성능 지표 관점

  • 👍 TTFB가 빠르다.
    • TTFB(Time to First Byte): 요청을 보내고 응답의 첫번째 바이트가 도착하기까지의 시간
    • 서버가 복잡한 HTML을 렌더링하지 않고, 빈 HTML+JS 번들 링크만 보내주면 되기 때문에 작업이 단순하여 TTFB가 빠른 경향이 있다.
  • 👎 FCP / LCP가 안좋다.
    • FCP(First Contentful Paint): 브라우저가 요청을 보낸 시점부터 DOM의 첫 번째 콘텐츠가 화면에 렌더링되는 시점
    • LCP(Largest Contentful Paint): 브라우저가 요청을 보낸 시점부터 가장 큰 콘텐츠 요소가 화면에 렌더링되는 시점
    • 빈 HTML+JS 파일 링크를 줘도, 사용자가 실제로 콘텐츠를 보려면 JS 실행 후에야 보이기 때문에 늦어진다.
    • fetch로 json 형식으로 받아서 렌더링하는 서버랑 통신하는 과정까지 마쳐야하기 때문에 첫페이지가 느리다.

CSR의 문제점

1. 초기 로딩 속도 CSR에서는 HTML, CSS 렌더링 후 JS 파일을 다운로드, 파싱, 실행해야지만 인터랙티브한 페이지를 볼 수 있다. 이 모든 과정이 순차적으로 이루어져야하기 때문에 FCP, LCP를 포함한 초기 로딩 성능을 저하한다. 이는 사용자가 사용하는 디바이스의 성능이 안좋거나 네트워크 연결 속도가 느릴수록 로딩 시간이 길어지기 때문에 저사양 디바이스에서 사용자 경험이 크게 떨어질 수 있다.

2. 사용자 경험 서버에서 최소한의 HTML만 제공되기 때문에 JS 실행 전까지는 빈 화면 또는 로딩 스피너만 보여주게 된다. 또한 대량의 데이터를 가져오는 애플리케이션에서는 data fetching 및 렌더링 과정이 길어져 사용자가 주요 콘텐츠를 보는 시간이 길다.

3. JS bundle size JS는 클라이언트에서 다운받는다. 기능이 많아질수록 JS bundle size도 늘어나 브라우저가 이를 처리하는데 많은 시간이 소요된다.

4. SEO 검색 엔진 크롤러는 주로 서버에서 렌더링된 HTML 콘텐츠를 인덱싱한다. 하지만 CSR에서는 하나의 div 태그가 포함된 HTML만 제공하기 때문에 검색 순위가 낮아질 수 있다.

5. 성능 최적화 초기 렌더링 시 HTML 구조가 거의 없기 때문에 브라우저에서 효율적인 HTML 캐싱이 어렵다. 또한 data fetching, 상태관리, 컴포넌트 렌더링 등의 모든 작업을 클라이언트에서 처리하기 때문에 브라우저의 부하가 증가한다.

📌 CSR의 문제점 해결을 위한 현대적인 SSR 방식

CSR은 위와 같은 한계가 있기 때문에, 이를 보완하기 위해 현대적인 SSR 방식이 발전했다. 전통적인 SSR은 서버에서 완성된 HTML을 내려주기 때문에 초기 렌더링은 빠르지만, 매 요청마다 서버 부하가 커지고 동적인 상호작용 구현이 제한적이라는 단점이 있었다.

이를 해결하기 위해 Hydration 기반 SSR이 등장했다. 서버는 미리 렌더링된 HTML을 클라이언트로 보내 즉시 콘텐츠를 보여주고(FCP 개선), 이후 브라우저에서 자바스크립트가 실행되면서 해당 HTML과 매칭되어 이벤트 바인딩과 상호작용이 가능해진다. 이렇게 하면 SSR의 빠른 초기 로딩과 CSR의 동적 인터랙션을 모두 누릴 수 있다. Next.js, Nuxt.js 같은 프레임워크들이 대표적이다. 또한, SSR의 성능 문제를 개선하기 위해 *SSG(Static Site Generation), ISR(Incremental Static Regeneration) *같은 방식도 도입되었다.

  • SSG는 빌드 시점에 HTML을 생성해 두어 요청 시 즉시 반환할 수 있어 TTFB와 FCP가 모두 빠르다. 다만, 데이터가 자주 바뀌는 페이지에는 적합하지 않다.
  • ISR은 특정 주기로 정적 페이지를 다시 생성하는 방식으로, 최신성을 유지하면서도 정적 사이트의 속도를 유지할 수 있다.

현대 웹은 이러한 전략들을 혼합해 사용한다. 예를 들어, 블로그 글 목록은 SSG로, 실시간 데이터가 필요한 대시보드는 SSR로, 로그인이나 마이페이지 같은 일부 영역은 CSR로 구현하는 Hybrid Rendering 방식이 일반적이다.

💡 따라서 오늘날의 SSR은 단순히 “서버에서 렌더링한다”에 그치지 않고, CSR의 장점을 흡수해 초기 로딩 성능과 SEO, 상호작용성을 모두 고려하는 진화된 렌더링 방식으로 이해할 수 있다.

SSR vs CSR

SSR CSR
장점 초기 로딩 속도가 빠름, SEO가 쉬움 화면 깜빡임이 없어 좋은 사용자 경험 제공, 초기 로딩 이후 구동 속도 빠름
단점 페이지 이동 시 화면 깜빡임으로 사용자 경험 저하, 매번 요청을 보내기 때문에 서버 과부하 발생 가능 초기 로딩 속도가 느림, SEO가 어려움
]]> <![CDATA[Node.js에서 EJS 이미지 파일 업로드 및 삭제 구현]]> https://velog.io/@dyeon-dev/Node.js%EC%97%90%EC%84%9C-EJS-%EC%9D%B4%EB%AF%B8%EC%A7%80-%ED%8C%8C%EC%9D%BC-%EC%97%85%EB%A1%9C%EB%93%9C-%EB%B0%8F-%EC%82%AD%EC%A0%9C-%EA%B5%AC%ED%98%84 https://velog.io/@dyeon-dev/Node.js%EC%97%90%EC%84%9C-EJS-%EC%9D%B4%EB%AF%B8%EC%A7%80-%ED%8C%8C%EC%9D%BC-%EC%97%85%EB%A1%9C%EB%93%9C-%EB%B0%8F-%EC%82%AD%EC%A0%9C-%EA%B5%AC%ED%98%84 Wed, 20 Aug 2025 11:40:45 GMT 클라이언트에서 이미지 업로드하기

html에서 이미지를 업로드하기 위해서는 input 태그의 type="file"을 사용하면 된다. 그리고 addEventListener로 이벤트 변경이 일어나는걸 감지해서 img 태그의 profileImage.src에 해당 파일을 삽입한다.

<form id="mypageForm" class="mypage-form">
  <div class="form-image">
    <img src="/images/profile.jpg" alt="프로필 이미지" id="profileImage" name="profileImage">
    <input type="file" id="input-file" accept="image/*">
    <label for="input-file">수정</label>
  </div>
</form>

<script>
  let profileImage = document.getElementById('profileImage');
  let inputFile = document.getElementById('input-file');

  inputFile.addEventListener('change', function(e) {
      const file = e.target.files[0];
      if (file) {
          profileImage.src = URL.createObjectURL(file);
      }
  })
</script>

그럼 이미지 파일을 선택하고 업로드가 된다. 그런데 이 파일을 서버에 POST 요청을 하면 문제가 생기고 DB에 저장할 수도 없다! 파일을 무작정 body에 담아서 POST 요청을 보내면 서버는 파일을 가져오지 못한다.

해결방법: multer 미들웨어 사용

일반적으로 클라이언트에서 서버로 폼 데이터(form data)가 전송될 때 해당 데이터는 인코딩되어 전송된다. 이때 파일을 전송하려면 form 태그의 enctype 속성을 "multipart/form-data"로 바꿔줘야 한다. enctype 속성은 입력된 데이터가 서버에 전송될 때 인코딩되는 방식을 결정한다. 디폴트는 application/x-www-form-urlencoded인데, 이 경우 모든 문자를 인코딩하여 전송하게 되며, 위에서 언급한 multipart/form-data는 모든 문자를 인코딩하지 않고 전송한다. mutler가 바로 이 multipart/form-data를 다루기 위한 node.js의 미들웨어다.

  1. 뷰 폼을 multipart/form-data로 전송하도록 수정

    <form id="mypageForm" class="login-form" enctype="multipart/form-data">

  2. multer 모듈 설치 `npm i multer'

  3. 라우터에서 multer 미들웨어를 추가해 파일을 public/uploads에 저장

  • 가장 기본적인 형태의 multer 사용이다. destination으로 경로를 지정해주었고, filename으로 파일명을 지정해주었다.
  • 파일명 생성 로직을 UUID 기반의 안전한 규칙으로 구현했다.
  • 이때 mime type 설정을 해주면 원하는 타입만 필터링이 가능하다. image 파일만 업로드가 가능하도록 필터를 추가하여 다른 파일은 거부되도록 했다.
  • 파일사이즈는 최대 5MB로 제한되게 하여 비용/저장 공간을 관리했다.
  • 이로인해 전송받은 파일은 node.js 내부의 uploads 디렉터리에 저장될 것이다.
    const express = require('express')
const router = express.Router()
const multer = require('multer')
const path = require('path')
const fs = require('fs')

// 업로드 스토리지 설정 (public/uploads) const storage = multer.diskStorage({ destination: (req, file, cb) => { const uploadPath = path.join(__dirname, '..', 'public', 'uploads') fs.mkdir(uploadPath, { recursive: true }, (err) => cb(err, uploadPath)) }, filename: (req, file, cb) => { const ext = path.extname(file.originalname).toLowerCase() const unique = (crypto.randomUUID ? crypto.randomUUID() : crypto.randomBytes(16).toString('hex')) cb(null, ${unique}${ext}) }, })

// 이미지 파일만 허용 const fileFilter = (req, file, cb) => { if (file.mimetype && file.mimetype.startsWith('image/')) return cb(null, true) cb(new Error('이미지 파일만 업로드할 수 있습니다')) } const upload = multer({ storage, fileFilter, limits: { fileSize: 5 * 1024 * 1024 } })


4. 컨트롤러에서 req.file을 읽어 profileImage 경로(/uploads/파일명)를 DB에 저장
```js
// POST /mypage
const postMypage = async (req, res) => {
    try {
        const { nickname, password } = req.body
        const username = res.locals.user.username

        const fieldsToUpdate = {}
        // 파일 업로드가 있는 경우 public 상대 경로로 저장
        if (req.file) {
            const relativePath = path.posix.join('/uploads', req.file.filename)
            fieldsToUpdate.profileImage = relativePath
        }
    }
}

이미지 삭제하기

  • 삭제 버튼을 만들고 클릭하면 profileImage.src에 기본 이미지를 할당하고 inputFile.value = ''처리를 해준다.
  • 이렇게까지만 하면 서버로 삭제의사가 전달되지 않아 DB에 profileImage가 그대로 남아있다.

해결방법: 삭제 플래그 설정

이미지를 제거하면 그 결과를 서버에게 알려줘야한다. 그런데 직접적으로 알릴 방법이 없다. 그래서 삭제 버튼을 누르면 변경되는 값(0,1)을 통해 서버가 감지해서 기존 파일을 삭제하고 DB에서 삭제가 이뤄지도록 구현했다.

  • 뷰에 숨은 필드 removeProfileImage를 추가해, 삭제 버튼 클릭 시 서버로 값이 1로 전송되도록 한다.
  • 컨트롤러에서 removeProfileImage === '1'이면 기존 파일을 삭제하고(fs.unlink), DB의 profileImage를 null로 업데이트한다.
  • 새 파일이 업로드되면 그 경로가 우선 적용된다.
  • 이렇게 하면 프로필 삭제 후 저장 → 다시 들어가면 기본 이미지로 보인다.
<div class="form-image-buttons">
  <label for="input-file">수정</label>
  <label id="delete-image">삭제</label>
</div>

<input type="hidden" id="removeProfileImage" name="removeProfileImage" value="0">


<script>
  let profileImage = document.getElementById('profileImage');
  let inputFile = document.getElementById('input-file');

  inputFile.addEventListener('change', function(e) {
      const file = e.target.files[0];
      if (file) {
          profileImage.src = URL.createObjectURL(file);
          // 파일을 새로 선택하면 removeProfileImage를 0으로 되돌린다.
          document.getElementById('removeProfileImage').value = '0'
      }
  })

  let deleteImage = document.getElementById('delete-image');
  deleteImage.addEventListener('click', function(e) {
    profileImage.src = '/images/profile.jpg';
    inputFile.value = ''
    document.getElementById('removeProfileImage').value = '1'
  })
</script>
// POST /mypage
const postMypage = async (req, res) => {
    try {
        const { nickname, password, removeProfileImage } = req.body
        const username = res.locals.user.username

        const fieldsToUpdate = {}
        // 삭제 플래그가 있으면 이미지 제거
        if (removeProfileImage === '1') {
            // 기존 파일 삭제 시도
            const current = await findUserByUsername(username)
            if (current && current.profileImage) {
                const absolute = path.join(__dirname, '..', 'public', current.profileImage)
                fs.unlink(absolute, () => {})
            }
            fieldsToUpdate.profileImage = null
        }
        // 새 파일 업로드가 있는 경우 설정 (삭제 플래그보다 우선)
        if (req.file) {
            const relativePath = path.posix.join('/uploads', req.file.filename)
            fieldsToUpdate.profileImage = relativePath
        }
    }
}

]]> <![CDATA[Express+EJS 템플릿으로 HTML 렌더링하기]]> https://velog.io/@dyeon-dev/ExpressEJS-%ED%85%9C%ED%94%8C%EB%A6%BF%EC%9C%BC%EB%A1%9C-HTML-%EB%A0%8C%EB%8D%94%EB%A7%81%ED%95%98%EA%B8%B0 https://velog.io/@dyeon-dev/ExpressEJS-%ED%85%9C%ED%94%8C%EB%A6%BF%EC%9C%BC%EB%A1%9C-HTML-%EB%A0%8C%EB%8D%94%EB%A7%81%ED%95%98%EA%B8%B0 Tue, 19 Aug 2025 14:29:42 GMT EJS란?

EJS는 html의 태그처럼 자바스크립트 내용을 삽입할 수 있다. 일반 html 파일은 무조건 <script> 태그를 사용해서 분리시켜야하지만, EJS는 지정된 태그를 통해 스트립트 내용을 하나의 요소처럼 사용될 수 있게 한다. 또한, 서버에서 보낸 변수를 가져와 사용할 수 있다! 기본 세팅은 Node.js의 Express를 사용한다.

EJS 템플릿

템플릿 엔진: 문법과 설정에 따라 파일을 html 형식으로 변환시키는 모듈 Embedded JavaScript의 약자로 자바스크립트가 내장되어 있는 html 파일

ejs 설치

npm install ejs

템플릿 엔진 설정하기

app.set("view engine", "ejs")

EJS 엔진에서는 기본적으로 views 폴더에 템플릿 파일 저장 app.set("views", "./views")

템플릿 파일에서 사용하는 정적 파일 제공 (CSS, JS, 이미지 등) app.use(express.static('public'))

EJS 문법

코드를 내장시키는 <%%> 태그

ejs에는 자바스크립트를 내장시킬 수 있는 2가지 태그가 있다. 가장 기본은 <%%>이고, 이 사이에 자바스크립트 내용을 넣으면 된다.

파일 불러오는 <%-include()%>

<%-include('view의 파일')%>

  • 다른 view 파일을 불러올 때 사용한다.
  • 예를 들어, 공통 컴포넌트를 빼고 불러올 때 유용하게 사용할 수 있다.
    • navbar 같은 공통 컴포넌트 로직을 따로 navbar.ejs 파일로 만들어서 main.ejs 파일에서 <%-include('navbar') %> 으로 불러오면 된다.

변수의 값을 출력하는 <%= %>

<%= 변수 %>

  • EJS는 Node(Express)에서 res.render(view, data)로 넘긴 값을 템플릿에서 바로 사용할 수 있다.
  • 방식은 심플하고 서버사이드 렌더링(SSR)에 잘 맞는다.

사용법

  • 컨트롤러(라우트)에서 데이터 전달
    // 예: 컨트롤러
app.get('/profile', (req, res) => {
res.render('profile', {
  title: '프로필',
  user: { username: 'dyeon', nickname: '다연' },
  posts: [{ id: 1, text: 'hi' }, { id: 2, text: 'hello' }]
})
})
  • EJS에서 사용
    <!-- profile.ejs -->
<h1><%= title %></h1>
<p>닉네임: <%= user.nickname %></p>
    <% posts.forEach(post => { %>
  • <%= post.text %>
    • <% }) %>
```

EJS로 로그인 화면 구현 및 처리하기

EJS 파일 생성 및 구현

  • 기존 html를 거의 그대로 사용한다.
  • 컴포넌트를 추가해야되면 <%-include() %>를 사용해서 원하는 부분에 추가한다.
    // views/login.ejs
<%-include('navbar') %>
```

EJS 파일을 불러오기 위한(로그인 화면 불러오기) 컨트롤러 및 라우터 구현

html 코드를 적었으니까 이걸 보여줘야한다. /login 루트 경로 접속 시 위의 코드인 login.ejs가 로그인 화면으로 나타나도록 한다.

  1. *컨트롤러 코드 작성 *
  • 로그인 관련 컨트롤러 함수를 작성할 loginController.js 파일을 생성
  • login.ejs 파일을 렌더링하는 컨트롤러 getLogin 함수를 구현하고 모듈로 내보냄.
  • /login 경로로 GET 요청 시 실행됨.
    // controllers/loginController.js
const getLogin = (req, res) => {
  res.render('login')
}

module.exports = { getLogin }


2. **로그인 관련 라우트 코드 작성**
- 로그인 관련 라우트 코드를 작성할 `loginRoutes.js` 파일을 생성함.
- /login 경로로 GET 요청 시 `getLogin` 함수가 실행되도록 라우팅을 설정하고 라우터를 내보냄.
```js
// routes/loginRoutes.js
const express = require('express')
const router = express.Router()
const loginController = require('../controllers/loginController')

router.get('/login', loginController.getLogin)

module.exports = router
  1. app.js에서 로그인 라우트가 실행되도록 추가
    app.use('/', require('./routes/loginRoutes'))

로그인 처리 (POST 요청) 구현

사용자가 아이디와 비밀번호 입력 후 로그인 클릭 시 POST 방식으로 서버에 정보를 보내도록 한다.

  1. login.ejs 폼 태그의 method를 post로 설정하고 action을 /login 경로로 지정

    <form action="/login" method="post" class="login-form">

  2. /login 경로로 POST 요청이 들어왔을 때 처리할 함수를 loginController.js에 추가

  • POST 요청을 처리하는 postLogin 함수를 작성하고, 요청 본문에서 사용자 아이디와 비밀번호를 가져옴
  • 임시로 아이디 'admin'과 비밀번호 '1234'가 일치하면 로그인 성공, 아니면 실패 메시지를 반환하도록 구현함 (아직 컨트롤러가 잘 작동하는지만 확인, 향후 DB로 연결 예정)
    // POST /login
const postLogin = (req, res) => {
  const { username, password } = req.body
  if(username === 'admin' && password === '1234') {
      res.redirect('/')
  } else {
      res.send('로그인 실패')
  }
}
  1. 로그인 라우트에 postLogin 함수를 가져와 POST 방식 /login 요청 시 실행되도록 설정함.
    const { getLogin, postLogin } = require('../controllers/loginController')

router.route('/login').get(getLogin).post(postLogin)


## EJS로 데이터 넘기기(ft.쿠키로 로그인 관리)
사용자의 로그인 정보를 저장하고 navbar나 페이지에서 **로그인 여부에 따라 분기처리**를 해주어야 한다.
로그인 상태 관리를 위해 세션없이 **쿠키로 로그인 상태를 관리**하고, **미들웨어에서 로그인 유저를 `res.locals.user`에 넣으면 모든 EJS에서 사용이 가능하다.**

1. **로그인 성공 시 쿠키로 사용자 정보 저장**
- username, nickname 데이터 쿠키 심기

```js
// controllers/loginController.js (성공 시)
res.cookie('user', JSON.stringify({ username: user.username, nickname: user.nickname }), { httpOnly: false })
  1. 서버에서 locals로 로그인 상태 전역 주입
  • 매 요청마다 쿠키에 user가 정보가 있으면 로그인 상태이기 때문에 res.locals.user로 주입
// app.js
const cookieParser = require('cookie-parser')
app.use(cookieParser())

app.use((req, res, next) => {
  res.locals.user = req.cookies.user ? JSON.parse(req.cookies.user) : null
  next()
})
  1. EJS에서 분기 렌더링
  • 응답 데이터에 locals.user가 있다면
  • 변수 문법을 사용하여 EJS 템플릿에 데이터를 넣어준다.
  • 이렇게 구현하면 로그인 성공 후 navbar에 닉네임/글쓰기/로그아웃이 표시되고, 비로그인 시 로그인/회원가입이 표시된다.
<% if (locals.user) { %>
  <span class="user-name">안녕하세요, <%= user.nickname %>님!</span>
  <button class="write-btn" href="#">글쓰기</a>
  <form action="/logout" method="post">
    <button class="logout-btn" type="submit">로그아웃</button>
  </form>
<% } else { %>
  <form action="/login" method="get">
    <button class="login-btn" type="submit">로그인</button>
  </form>
  <form action="/signup" method="get">
    <button class="signup-btn" type="submit">회원가입</button>
  </form>
<% } %>
]]> <![CDATA[CSS Layout]]> https://velog.io/@dyeon-dev/CSS-Layout https://velog.io/@dyeon-dev/CSS-Layout Tue, 19 Aug 2025 00:01:53 GMT elements가 배치(Layout)되는 방식

엘리먼트를 화면에 배치하는 것을 레이아웃 작업이라고도 하며, 렌더링 과정이라고도 한다. 엘리먼트는 위에서 아래로 순서대로 블록을 이루며 배치되는 것이 기본이다. 하지만 웹사이트의 배치는 다양하게 표현 가능해야 하기 때문에, 이를 다양한 방식으로 배치할 수 있도록 CSS에는 추가적인 속성을 제공한다.

아래의 속성들을 중심으로 엘리먼트의 배치를 이해하는 것이 중요하다.

  • display(block, inline, inline-block)
  • position(static, absolute, relative, fixed)
  • float(left, right)

display 속성

위에서 아래로 쌓이는 블록 요소 (display:block)

display 속성이 block이거나 inline-block인 경우 그 엘리먼트는 벽돌을 쌓는 블록을 가지고 쌓인다. 높이값을 더 주면 더 높은 크기로 엘리먼트가 쌓인다. inline-block은 블록 요소 특성 일부를 갖지만, inline처럼 흐름에 따라 좌우로 배치 가능하다. inline 엘리먼트처럼 전후 줄바꿈 없이 한 줄에 다른 엘리먼트들과 나란히 배치되지만, block 엘리먼트처럼 width와 height 속성 지정 및 margin과 padding 속성의 상하 간격 지정이 가능하다. 

<div>block1</div>
<p>block2</p>
<div>block3</div>

좌우로 흐르는 인라인 요소 (display:inline)

display속성이 inline인 경우는 우측으로, 그리고 아래쪽으로 빈자리를 차지하며 흐른다. 참고로, inline속성의 엘리먼트는 높이와 넓이를 지정해도 반영이 되지 않는다.

<div>
  <span>나는 어떻게 배치되나요?</span>
  <span>좌우로 배치되는군요</span>
  <a>링크는요?</a>
  <strong>링크도 강조도 모두 좌우로 흐르는군요</strong>
</div>

position 속성

좀 다르게 배치시키기 (position속성)

엘리먼트 배치가 순서대로만 위아래로 또는 좌우로 흐르면서 쌓이기만 하면, 다양한 배치를 하기 어렵다. position속성을 사용면 상대적/절대적으로 어떤 위치에 엘리먼트를 배치하는 것이 수월하다.

  1. 기본 static: 그냥 순서대로 배치

  2. absolute: 기준점에 따라 특별한 위치에 위치

    • 배치 흐름(normal flow)에서 제거하고 top/left/right/bottom 값에 따라 특정 기준점(containing block) 기준으로 위치시킴
    • 기준점을 찾는 규칙은 조상 요소 중에서 position 속성이 static이 아닌 요소를 기준점으로 삼음.
    • 즉, relative / absolute / fixed / sticky 이 네 가지 중 하나가 설정된 조상이 있으면, 그 요소의 padding box가 기준이 됨.
    • 만약 조상들 중에 전부 static만 있다면? 결국 브라우저 뷰포트(<html> 요소)가 기준점이 됨.

  3. relative: 원래 자신이 위치해야할 곳을 기준으로 이동

    • *배치 흐름(normal flow)에서 계속 포함 *하기 때문에 원래 있어야할 자리 (normal flow 배치 자리)를 차지한 채로, 시각적으로만 이동
    • 따라서 아래에 오는 다른 요소가 그 빈자리를 차지하지 못함
    • 겹쳐 보이더라도 실제 배치 흐름은 깨지지 않음
    • top/left/right/bottom 값만큼 보이는 박스만 움직임

  4. fixed: viewport(전체화면)좌측,맨위를 기준으로 동작

relative vs absolute

기본 배치에서 벗어나서 떠있기 (float:left / right)

float 속성으로 원래 flow에서 벗어날 수 있고 둥둥 떠다닐 수 있다. 일반적인 배치에 따라서 배치된 상태에서 float는 벗어난 형태로 특별히 배치된다. 따라서 뒤에 block엘리먼트가 float된 엘리먼트를 의식하지 못하고 중첩되어서 배치된다. float의 속성은 이런 독특함 때문에 웹사이트 레이아웃 배치에서 유용하게 활용되기도 하는데, flex, grid 같은 최신 레이아웃 시스템이 등장하기 전까지는 굉장히 많이 쓰였다. float는 사실상 텍스트 감싸기나 간단한 좌우 배치 정도에서 유용하다. 레이아웃 전체를 짜는 용도로 쓰기엔 한계가 커서 지금은 flex/grid로 대체되었다.

code > http://jsbin.com/cutivij/2/edit?html,css,output

float를 사용한 레이아웃 예시 (한계)

<div class="container">
  <div class="box">1</div>
  <div class="box">2</div>
  <div class="box">3</div>
</div>

.container {
  width: 300px;
  border: 1px solid #333;
  overflow: hidden; /* clearfix 용도로 사용 */
}

.box {
  float: left;
  width: 100px;
  height: 100px;
  line-height: 100px;
  text-align: center;
  background-color: lightblue;
  margin-right: 10px;
}
  • 박스 간격 조절이 어려움 (margin으로만)
  • 수직 정렬 불가 (line-height 트릭 사용)
  • 컨테이너 높이 자동 조절이 안 됨 (clearfix 필요)

flex로 바꾼 예시 (해결)

.container {
  display: flex;
  justify-content: space-between; /* 수평 간격 조절 */
  align-items: center;            /* 수직 정렬 */
  width: 300px;
  border: 1px solid #333;
}

.box {
  width: 100px;
  height: 100px;
  background-color: lightgreen;
  text-align: center;
  line-height: 100px; /* 수직 정렬은 align-items로도 가능 */
}
  • justify-content로 박스 간격 자유롭게 조절 가능
  • align-items로 수직 중앙 정렬 가능
  • 컨테이너 높이 자동 조절 (clearfix 필요 없음)
  • 순서 변경, 감싸기(wrap) 등도 간단하게 처리 가능 (flex-wrap: wrap;)

유연한 박스 모델을 제공 (flexbox)

Flexbox는 CSS의 레이아웃 모듈 중 하나로, 유연한 박스 모델을 제공하여 엘리먼트를 쉽게 배치할 수 있도록 도와준다. Flexbox는 주로 수평 정렬, 수직 정렬, 아이템 간 간격 설정 등을 다루는 데 사용된다.

  1. 주 축 (Main Axis)과 교차 축 (Cross Axis)
  • Flex 컨테이너는 주 축과 교차 축을 가지며, 이 축들을 기준으로 아이템들이 배치
  • 기본적으로 주 축은 수평 방향이고, 교차 축은 수직 방향
  • 주 축과 교차 축은 Flex 컨테이너의 속성에 따라 결정
  1. Flex Container (부모 요소)
  • Flexbox를 적용하는 컨테이너
  • display: flex 또는 display: inline-flex를 사용하여 컨테이너를 정의
Flex 컨테이너 속성 설명
flex-direction 아이템들이 배치되는 주 축의 방향을 설정
justify-content 주 축에서 아이템들을 정렬하는 방법을 설정.
align-items 교차 축에서 아이템들을 정렬하는 방법을 설정.
flex-wrap 아이템들이 한 줄에 모두 배치되지 않을 경우 줄 바꿈 여부를 설정.
align-content 교차 축에서 여러 줄이 있을 때 줄 전체 묶음을 정렬
  1. Flex Items (자식 요소)
  • Flex 컨테이너 내부에 있는 엘리먼트들을 Flex 아이템이라고 함
Flex 아이템 속성 설명
flex-basis 아이템의 기본 크기를 설정
flex-grow 아이템의 남는 공간 활용에 대한 증가 비율을 설정.
flex-shrink 아이템의 감소 비율을 설정.
align-self 개별 아이템의 교차 축 정렬 방법을 설정. (Flex 컨테이너의 align-items를 재정의할 수 있음.)

정리

레이아웃의 방법은 여러가지가 있다. 어떤 방법을 선택할지 고민하는 습관을 들이자.

display 속성 특징
block 전체 너비 차지, 위에서 아래로 쌓임, 높이/너비 적용 가능
inline 좌우로 흐름, 높이/너비 적용 불가
inline-block inline처럼 좌우로 흐르면서, block처럼 높이/너비 적용 가능
position 속성 특징
static 기본, normal flow
relative 원래 자리 기준으로 이동, flow 유지
absolute flow에서 제거, 조상 요소 중 position이 static이 아닌 요소 기준 배치
fixed viewport 기준으로 고정 배치
sticky 스크롤 위치에 따라 relative → fixed 전환

float는 과거 레이아웃(2~3단 컬럼)에서 사용했으나, flex/grid 등장으로 레이아웃 용도는 감소했다. 최신 웹에서는 flex / grid 활용하여 유지보수가 용이하고 직관적이게 구현하자.

  • 특별한 위치에 배치 → position: absolute / relative 활용
  • 단순 좌우 배치 → inline-block이나 float 가능
  • 텍스트/요소 간 간격 → margin과 padding 활용
  • 브라우저 호환성 확인 필수

참고자료

]]> <![CDATA[HTML 배치를 위한 태그 (ft. 웹페이지 구조로 살펴보기)]]> https://velog.io/@dyeon-dev/HTML-%EB%B0%B0%EC%B9%98%EB%A5%BC-%EC%9C%84%ED%95%9C-%ED%83%9C%EA%B7%B8-ft.-%EC%9B%B9%ED%8E%98%EC%9D%B4%EC%A7%80-%EA%B5%AC%EC%A1%B0%EB%A1%9C-%EC%82%B4%ED%8E%B4%EB%B3%B4%EA%B8%B0 https://velog.io/@dyeon-dev/HTML-%EB%B0%B0%EC%B9%98%EB%A5%BC-%EC%9C%84%ED%95%9C-%ED%83%9C%EA%B7%B8-ft.-%EC%9B%B9%ED%8E%98%EC%9D%B4%EC%A7%80-%EA%B5%AC%EC%A1%B0%EB%A1%9C-%EC%82%B4%ED%8E%B4%EB%B3%B4%EA%B8%B0 Mon, 18 Aug 2025 13:07:41 GMT 1️⃣ HTML 문서의 기본 구조

HTML 문서의 기본 구조는 다음과 같다. 이렇게 작성하는 건 '웹 콘텐츠를 작성할 준비가 되어있는 상태'로 만드는 작업이다.

<!DOCTYPE html>
<html lang="ko">
  <head>
    <meta charset="utf-8">
    <title>여기에는 문서의 제목을 입력해주세요</title>
  </head>
  <body>
    여기에 웹페이지에 표시할 콘텐츠(태그)를 입력해주세요
  </body>
</html>

HTML 코드를 보면 계층적이다. 브라우저는 HTML 정보를 tree 구조로 보관하고 있다. HTML은 적절한 tag를 사용해서 구조를 만든다.

<head> 태그

  • html 문서의 meta 정보이다.
  • <head>의 안에 작성되는 태그들은 웹 브라우저 화면에 표시될 콘텐츠를 나타내는 것은 아니지만, 웹페이지의 품질에 영향을 주는 중요한 정보들이다.
  • 다양한 설정 태그를 추가 입력할 수 있다.

<body> 태그

  • 화면에 보여지기 위한 정보이다.
  • 텍스트나 이미지, 미디어 요소 등 다양한 콘텐츠들을 포함하여 웹페이지를 풍성하게 꾸밀 수 있다.

2️⃣ 화면의 배치 (layout) 를 위한 태그

실제 웹 페이지에서 이 태그들이 실제 사용된 예시를 알아보자. 개발자도구로 elements를 확인해보면 <body> 안에 여러 태그들이 쓰이고 있다.

화면에서 레이아웃 구조를 나타내기 위해서 어떤 태그를 사용할까?

대표적으로 header, section, aside, nav, footer가 있다.

이는 Top-down방식으로 HTML구조를 만들때 이용한다.

<header> 태그

<header>는 웹 페이지의 맨 위에 있는 글로벌 헤더나, 글이나 콘텐츠의 서두[서론/서문/도입부]를 나타낼 때 사용한다. 여기에는 웹 페이지의 제목, 로고, 주요 네비게이션 메뉴 등이 포함될 수 있다.

  • 네이버 메인페이지 - 네이버 HTML의 태그를 확인해보면, <header>안에 검색 영역인 <section>과 메뉴 영역인 <nav>가 있다.

  • 애플 공식홈페이지

    • 애플 웹 페이지에서는 헤더 영역이<div id="globalheader">으로 쓰이고 있다. 이 부분에 궁금증이 들어서 왜 헤더 태그가 아닌 div 태그를 쓴 건지, 시맨틱 태그가 고려된게 맞는지 gpt에게 물어봤다. 이유는 애플의 프론트엔드 철학과 호환성 때문이라고 한다. 간단하게 말하자면, 애플은 디자인 가이드라인과 일관성을 최우선시하기 때문에 많은 페이지와 컴포넌트를 공유하는데, CSS/JS에서 #globalheader라는 고정 ID를 사용하는 게 유지보수 측면에서 훨씬 단순하여 구현 방식에서 <header>를 쓰면 의미상 더 명확하지만, <div>를 택한 것이다. 즉, 시맨틱 태그 대신 호환성과 레거시 유지보수를 우선한 선택이라고 보면 된다. (시맨틱 태그를 고려하지 않은 게 아님)
    • 헤더 영역 안에 보조 콘텐츠 영역인 <aside>와 메뉴 영역인 <nav>가 있다.

💡랜드마크 role="banner" 속성을 사용하자 ! (ARIA role 속성)

HTML에서 "랜드마크(landmark)"란 웹 페이지의 구조를 설명하고 웹 접근성을 향상시키는 데 사용되는 특별한 역할을 하는 요소이다.

header의 HTML 요소(Element)의 확장 개념으로 좀 더 명확한 HTML 요소의 구조와 의미를 부여하는 역할을 하는 role 속성의 값은 banner이다. 이는 스크린 리더를 사용하는 사용자를 위한 웹 접근성을 고려하기 위해 사용된다. <header>가 <body> 바로 아래에 있지 않고 <article>, <section>, <nav> 등 다른 페이지 영역 내부에 포함될 경우, 접근성 트리에서는 일반 section 역할로 인식될 수 있다. 이때는 명시적으로 role="banner"를 지정해주는 것이 유용하다. <header> 태그에 명시적으로 role 속성의 값이 banner로 지정되어 있지 않으면 웹 접근성을 위한 스크린 리더는 HTML 문서의 맥락상 global header인지 판단한다.

global header임을 명시적으로 나타내기 위해서는 role="banner"를 사용하는 것이 좋다.

<header role="banner">
    <h1>웹사이트 제목<h1>
    .... 로고, 네비게이션, 검색....
</header>

<section> 태그

<section> 태그는 문서, 애플리케이션의 일반적인 섹션을 나타낸다. 더 적합한 의미를 가진 요소가 없을 때 논리적인 측면에서 주제별 콘텐츠 그룹을 나타내는데 사용한다. <section> 태그를 일반 컨테이너로 사용하면 안된다. 단순 스타일링이 목적이라면 <div> 태그를 사용해야 한다.

<section>과 <article> 태그의 차이점

  • <section> 태그는 문서나 애플리케이션의 논리적인 측면에서 주제별 콘텐츠 그룹을 나타내는데 사용된다.
  • <article> 태그는 문서, 페이지, 애플리케이션, 또는 사이트에서 독립적으로 배포 가능하거나 재사용할 수 있는 콘텐츠를 묶는 영역으로 사용된다. 예를 들어, 게시판 글, 뉴스 기사, 블로그 글, 댓글 등이 있다. <article> 태그 내에서 <section> 태그를 사용하는 것은 가능하다.

<aside> 태그

<aside> 태그는 페이지의 주요 콘텐츠 영역의 보조 콘텐츠 영역을 나타낸다. 주요 콘텐츠와 상호작용하지 않고 보조적인 역할을 하는 내용이 포함될 수 있다. 주로 문서의 주요 내용과 관련된 별도로 분리된 추가 정보를 제공하는 데 사용해야 하며, 문서의 주요 내용에 포함되는 내용을 나타내는 데는 사용해서는 안된다.

사용 예제로는 사이드바에서 많이 사용된다.

블로그 사이드바

<article>
    <h1>블로그 포스트 제목</h1>
    <p>블로그 내용...</p>
</article>
<aside>
    <!-- 블로그 포스트와 관련된 추가 정보 -->
    <h2>관련 포스트</h2>
    <ul>
        <li><a href="#">포스트 1</a></li>
        <li><a href="#">포스트 2</a></li>
        <li><a href="#">포스트 3</a></li>
    </ul>
</aside>

광고 배너

<main>
    <h1>제품 소개</h1>
    <p>제품에 대한 자세한 정보...</p>
</main>
<aside>
    <ins>
        <!-- 제품 관련 광고 배너 -->
        <img src="광고이미지.jpg" alt="제품 광고">        
    </ins>
</aside>

인용구

<article>
    <h1>역사적 이벤트</h1>
    <p>이벤트에 대한 설명...</p>
</article>
<aside>
    <!-- 역사적 이벤트와 관련된 인용구 -->
    <blockquote>
        <p>역사는 어떤 상황에서든 경험된 것이 아니라, 해석된 것이다.</p>
        <span>칼 유워스</span>
    </blockquote>
</aside>

<nav> 태그는 다른 웹 페이지로 연결하거나, 현재 웹 페이지의 콘텐츠 내부로 연결되는 탐색(navigation)을 위한 링크(links)가 있는 영역을 나타낸다. 일반적인 예로는 메뉴, 목차, 색인 등이 있다.

주요 네비게이션 메뉴

<nav>
    <ol>
        <li><a href="/">홈</a></li>
        <li><a href="/products">제품</a></li>
        <li><a href="/products/category1">카테고리 1</a></li>
        <!-- Breadcrumbs를 사용하여 사용자는 현재 페이지가 "홈 > 제품 > 카테고리 1 > 현재 페이지"임을 이해할 수 있고, 각 부분을 클릭하여 해당 페이지로 이동할 수 있다. -->
        <li aria-current="page">현재 페이지</li>
    </ol>
</nav>

웹 페이지의 맨 하단에 있는 global footer를 나타내거나, 글이나 콘텐츠 영역에 대한 작성자, 저작권 정보, 관련 문서에 대한 링크 등의 내용을 나타낸다.

💡랜드마크 role="contentinfo" 속성을 사용하자 ! (ARIA role 속성)

footer의 HTML 요소(Element)의 확장 개념으로 좀 더 명확한 HTML 요소의 구조와 의미를 부여하는 역할을 하는 role 속성의 값은 contentinfo이다. 이는 스크린 리더를 사용하는 사용자를 위한 웹 접근성을 고려하기 위해 사용된다.

대부분의 웹 접근성을 위한 스크린리더에서는 <footer> 태그가 HTML 문서의 맥락상 global footer인지 판단한다. 그래서, <footer> 태그에 role="contentinfo"를 추가하지 않아도 되지만, 일부 스크린리더에서 global footer인지 판단하지 못하는 문제가 있다. 웹 접근성을 위해 이 문제를 해결하려면 <footer> 태그에 role="contentinfo"를 명시적으로 추가해야 한다.

<footer role="contentinfo">
    <address>
        © 2025 웹 페이지 제작자
        <a href="mailto:contact@example.com">contact@example.com</a>
    </address>
</footer>

대표적으로 3개의 웹 페이지에서 확인한 결과, 애플 공식홈페이지에서만 footer에서 role="contentinfo"을 사용중이었다.

👀 웹 페이지 대충 비교 분석해보기

  • 애플 공식홈페이지
    • 애플 웹 페이지에서는 *<section> 태그를 사용한 영역은 없다. *
    • 대신 <div> 태그에 고유 id로 시맨틱 태그를 적용하였다.
    • 총 8개의 모든 영역을 <div id="1_section">, <div id="2_section">.. 식으로 나누었다.
    • 전체적으로 <div> 태그를 많이 썼다. *그럼에도 불구하고 프론트엔드 설계랑 철학이 엿보이는 것 같다. *
  • 네이버 메인페이지
    • 네이버 웹 페이지에서는 *<section> 태그를 검색 영역에서만 사용했다. *
    • *네이버는 특징적으로 게시판 글, 뉴스 기사를 주로 다루기 때문에 <article> 태그가 있을 줄 알았는데 없었다. * 비슷한 의미로 <section> 영역도 콘텐츠 부분에 사용하지 않은 점이 궁금하다.
  • NOL 야놀자 메인페이지
    • 야놀자 웹 페이지에서는 총 12개 영역 중에 2개의 영역에서만 <section> 태그를 사용했다.
    • 특가 호텔 슬라이더와 기획전 모음 영역. 두 곳에서만 사용되고,
    • 나머지 영역들에서는 <div> 태그로 사용*됐는데, 왜 통일성 없이 이렇게 했는지 궁금하다. 통일성을 못찾아서 어떤 기준으로 한 건지 분석 실패..

3️⃣ 정리

태그를 사용할 때는 웹 페이지의 내용을 시맨틱하게 구조화하여 이해하기 쉽게 작성하는 것이 기본이다.

시맨틱 태그는 SEO, 접근성, 협업 효율성 측면에서 장점이 크다.

다만, 실무에서는 프레임워크나 레거시 코드, 유지보수 편의성 때문에 <div> 같은 비시맨틱 태그를 전략적으로 활용하는 경우도 많다. 따라서 “시맨틱 태그 vs 비시맨틱 태그”의 이분법보다는 상황에 맞는 균형 잡힌 선택이 필요하다.

또한, 웹 접근성을 높이기 위해 landmark role(role="banner", role="contentinfo" 등)을 명시적으로 병행하는 습관을 가지는 것이 좋다.

참고자료

]]>