ssooo_kk_77.log

AI 도구 링크 모음

Sat, 27 Jun 2026 09:58:29 GMT

최근 AI 도구들을 찾아보면서 업무나 사이드 프로젝트에 활용해볼 만한 사이트들을 정리해두고 싶었다. 각 도구를 깊게 사용해본 것은 아니지만, 어떤 기능을 제공하는지와 실제 업무에서 어떻게 연결해볼 수 있을지 간단히 메모해본다.

1. AI 에이전트 / 업무 자동화

Hermes Agent

링크: https://www.elancer.co.kr/blog/detail/1086
키워드: AI 에이전트, 기억, 반복 업무 자동화, 개인 비서

Hermes Agent는 서버나 PC에 상주하면서 사용자의 선호도, 반복 업무, 자주 하는 지시사항을 기억하고 학습하는 AI 에이전트 개념으로 소개되어 있다.

단순히 한 번 답변을 생성하는 챗봇이라기보다, 사용자의 업무 패턴을 기억하고 반복되는 작업을 스킬처럼 저장해두는 방식에 가깝다.

업무에 연결해본다면 반복 보고서 작성, 일정 요약, 자주 쓰는 문서 양식 생성, Slack이나 Telegram과 연동한 개인 업무 비서처럼 활용할 수 있을 것 같다.

Ennoia

링크: https://ennoia.so/
키워드: AI 에이전트 플랫폼, 싱글 에이전트, 멀티 에이전트, 앱 제작

Ennoia는 원티드에서 제작한 기업용 AI 에이전트 플랫폼이다. 싱글 에이전트, 멀티 에이전트, 앱 제작 기능을 제공하는 것으로 보인다.

개인용 AI 도구보다는 조직이나 팀 단위에서 반복 업무를 자동화하고, 여러 에이전트가 역할을 나눠 일하는 흐름을 만들 때 활용할 수 있을 것 같다.

요구사항 정리, 문서 요약, 고객 문의 분류, 운영 리포트 생성 같은 반복 업무를 에이전트 단위로 나눠 자동화하는 방식이 가능해 보인다.

Google Opal

링크: https://opal.google/landing/
키워드: AI 워크플로우, 노코드 AI 앱, 흐름 제어

Google Opal은 LLM의 동작을 순서에 맞게 구성하고, 하나의 흐름으로 제어할 수 있는 서비스로 보인다.

단순히 프롬프트를 한 번 입력하는 것이 아니라, 입력 → 분석 → 요약 → 결과 생성처럼 여러 단계를 연결해서 사용할 수 있다는 점이 흥미로웠다.

블로그 초안 작성, 경쟁사 분석, 회의록 요약, 기획서 초안 생성처럼 반복되는 AI 작업 흐름을 하나의 미니 앱처럼 만들어둘 수 있을 것 같다.

2. AI 개발 방식 / 하네스 엔지니어링

하네스 엔지니어링

링크: https://madplay.github.io/post/harness-engineering#google_vignette
키워드: AI 개발 자동화, 에이전트 작업 환경, 테스트, 피드백 루프

하네스 엔지니어링은 AI 에이전트가 일을 잘할 수 있도록 작업 환경을 설계하는 개념에 가깝다.

처음에는 프롬프트를 잘 쓰는 것만 중요하다고 생각했는데, AI가 프로젝트를 이해하고 안정적으로 작업하려면 폴더 구조, 규칙 문서, 테스트 기준, 리뷰 흐름 같은 환경도 함께 정리되어 있어야 한다는 점이 인상적이었다.

프로젝트에 rules.md, API 명세, 컴포넌트 작성 규칙, 테스트 기준 등을 정리해두고 AI 도구가 그 규칙을 참고해서 작업하도록 만드는 방식으로 활용할 수 있을 것 같다.

3. 프롬프트 / 디자인 참고 도구

Claude Prompts KR

링크: https://claude-prompts-kr.vercel.app/
키워드: 프롬프트 모음, 업무 템플릿, 분석 프롬프트

Claude Prompts KR은 다양한 상황에서 사용할 수 있는 프롬프트 예시를 모아둔 사이트다.

예를 들어 경쟁사 분석을 하고 싶을 때 아래와 같은 프롬프트를 가져와서 사용할 수 있다.

Analyze [COMPANY/PRODUCT] against its top 5 competitors.
Compare on [DIMENSIONS].
Identify where it leads, where it lags, and where the biggest opportunities are.

프롬프트가 길지 않아도 목적, 비교 대상, 기준이 명확하면 좋은 결과를 얻을 수 있다는 점이 좋았다.

경쟁사 분석, 기획서 초안, 사용자 리서치 정리, 마케팅 문구 작성, 회고 작성 등에 활용할 수 있을 것 같다.

getDesign.md

링크: https://getdesign.md/
키워드: 디자인 프롬프트, UI 참고, Markdown 기반 디자인 설명

getDesign.md는 마음에 드는 디자인을 고르고, 해당 디자인을 설명하는 Markdown 프롬프트를 복사해 사용할 수 있는 사이트다.

PPT나 웹사이트, 랜딩 페이지, 포트폴리오 페이지를 만들 때 원하는 디자인 방향을 LLM에게 설명하기가 어려운데, 이런 프롬프트를 활용하면 스타일을 더 구체적으로 전달할 수 있을 것 같다.

업무에 연결해본다면 관리자 페이지 UI 톤 정리, 랜딩 페이지 초안, PPT 디자인 방향 설정, 사이드 프로젝트 화면 구성에 활용할 수 있을 것 같다.

4. AI 기반 웹사이트 생성 도구

Readdy

링크: https://readdy.ai/project
키워드: AI 웹사이트 생성, 노코드, 퍼블리싱

Readdy는 AI 기반 노코드 웹사이트 생성 및 퍼블리싱 플랫폼이다. 웹사이트 초안을 만들고, 수정 후 배포까지 이어갈 수 있는 도구이다.

랜딩 페이지 초안 제작, 서비스 소개 페이지, 포트폴리오 페이지, 이벤트 페이지처럼 빠르게 형태를 확인해야 하는 작업에 활용할 수 있을 것 같다.

개발자 입장에서는 완성된 서비스를 모두 대체한다기보다, 초기 화면 구조나 디자인 방향을 빠르게 잡는 용도로 참고하면 좋을 것 같다.

GraphRAG, Knowledge Graph, Ontology의 차이점

Tue, 16 Jun 2026 07:13:16 GMT

GraphRAG, Knowledge Graph, Ontology는 뭐가 다를까?

최근 GraphRAG를 공부하면서 가장 헷갈렸던 부분이 Ontology, Knowledge Graph, GraphRAG의 차이였다.

처음에는 세 개가 거의 같은 개념인 줄 알았다. 자료를 보다 보면 "온톨로지를 설계한다", "지식 그래프를 구축한다", "GraphRAG를 적용한다"는 말이 한꺼번에 등장하는 경우가 많아서 더 헷갈렸다.

이번에 관련 자료들을 찾아보면서 나름대로 이해한 내용을 정리해 보려고 한다.

결론부터 말하면 세 개는 서로 다른 역할을 가지고 있다.

Ontology
↓
Knowledge Graph
↓
GraphRAG

생각보다 관계가 단순했다.

Ontology는 설계도에 가깝다

Ontology는 쉽게 말해서 데이터의 구조와 관계를 정의하는 설계도다.

예를 들어 호텔 고객 경험(CX) 플랫폼을 만든다고 가정해 보자.

우리 시스템에는 다음과 같은 데이터가 존재할 수 있다.

고객(Customer)
예약(Reservation)
객실(Room)
체크인(Check-In)
설문(Survey)
VOC

이때 단순히 데이터가 존재하는 것만으로는 부족하다.

서로 어떤 관계를 가지는지도 정의해야 한다.

예를 들면

고객 → 예약한다 → 예약

고객 → 작성한다 → 설문

고객 → 등록한다 → VOC

예약 → 포함한다 → 객실

설문 → 평가한다 → 객실

같은 관계들이다.

Ontology는 이런 관계를 정의하는 단계라고 보면 된다.

중요한 점은 아직 실제 데이터는 없다는 것이다.

홍길동 고객이 예약을 했는지, 어떤 설문을 작성했는지는 중요하지 않다.

단지 "고객은 예약을 할 수 있다", "고객은 설문을 작성할 수 있다" 같은 규칙을 정의하는 것이다.

Knowledge Graph는 실제 데이터가 들어간 결과물

Ontology가 설계도라면 Knowledge Graph는 실제 데이터가 채워진 상태다.

예를 들어 Ontology에서

고객 → 설문 작성

이라는 관계를 정의했다면,

Knowledge Graph에서는

홍길동 → 설문#123 작성

김철수 → 설문#456 작성

이영희 → 설문#789 작성

처럼 실제 데이터가 연결된다.

개인적으로는 객체지향의 Class와 Instance 관계로 이해하니까 가장 쉬웠다.

Ontology = Class

Knowledge Graph = Instance

즉,

Ontology + 실제 데이터
= Knowledge Graph

라고 생각하면 이해하기 편하다.

지하철 노선도로 생각하면 이해가 쉽다

개인적으로는 지하철 노선도로 비유하니까 가장 이해가 잘 됐다.

Ontology

Ontology는 지하철 노선도를 설계하는 단계다.

강남역 ↔ 역삼역 ↔ 선릉역

어떤 역이 존재하고 어떤 역끼리 연결되는지를 정의한다.

아직 실제 열차가 운행되는 것은 아니다.

그냥 구조만 설계한 상태다.

Knowledge Graph

Knowledge Graph는 실제 운행 데이터가 들어간 상태다.

강남역
↓
2호선

역삼역
↓
2호선

선릉역
↓
2호선

여기에

현재 승객 수

혼잡도

첫차/막차 시간

환승 정보

같은 실제 데이터가 추가된다.

즉 단순 노선도가 아니라 실제 운영 정보를 담고 있는 지하철 시스템이 되는 것이다.

GraphRAG

GraphRAG는 이 노선도를 이용해서 최적 경로를 찾아주는 앱이라고 생각하면 된다.

예를 들어 사용자가

서울역에서 잠실역까지 가장 빠르게 가는 방법은?

이라고 물어보면,

앱은 노선도를 따라가면서

서울역
↓
시청역
↓
을지로입구
↓
잠실역

같은 경로를 탐색한다.

GraphRAG도 비슷하다.

질문이 들어오면 데이터 간의 관계를 따라가면서 필요한 정보를 수집하고, 그 결과를 LLM에게 전달한다.

GraphRAG는 그래프를 활용한 RAG

그럼 GraphRAG는 정확히 무엇일까?

이름 그대로 RAG(Retrieval Augmented Generation)에 그래프를 결합한 방식이다.

기존 RAG는 보통 다음과 같이 동작한다.

질문
↓
벡터 검색
↓
관련 문서 추출
↓
LLM 응답 생성

반면 GraphRAG는

질문
↓
그래프 탐색
↓
관련 데이터 수집
↓
LLM 응답 생성

방식으로 동작한다.

예를 들어 사용자가

최근 체크인 만족도가 낮은 이유는 무엇인가요?

라고 질문했다고 가정해 보자.

기존 RAG는 체크인 관련 문서 몇 개를 찾아서 답변할 가능성이 높다.

하지만 GraphRAG는 관계를 따라가면서 정보를 수집할 수 있다.

체크인 만족도
↓
체크인 대기시간
↓
프런트 직원 수
↓
주말 방문객 증가
↓
VOC 불만 내용

이런 식으로 관련 데이터를 탐색하고 연결한다.

그래서 단순히 체크인 관련 문서만 찾는 것이 아니라 체크인 만족도에 영향을 줄 수 있는 다양한 정보들을 함께 고려할 수 있다.

실제 프로젝트에서는?

요즘 설문조사 플랫폼이나 VOC 분석 플랫폼은 단순히 설문 데이터만 분석하지 않는다.

고객 정보, 예약 정보, 결제 정보, VOC, CRM 데이터까지 함께 활용한다.

예를 들어 호텔 서비스에서

고객
예약
체크인
객실
설문
VOC

를 모두 연결해 두었다고 가정해 보자.

그러면 AI는 단순히

객실 만족도가 낮습니다.

수준의 답변이 아니라

객실 만족도가 낮은 고객의 73%는 체크인 대기시간도 길었으며, VIP 고객군에서 해당 현상이 더 자주 발생했습니다.

같은 형태의 분석도 가능해진다.

이런 관점에서 보면 GraphRAG의 핵심은 LLM 자체보다 데이터 간의 관계를 얼마나 잘 설계했는지에 있는 것 같다.

마무리

처음에는 GraphRAG만 공부하면 될 줄 알았다.

그런데 공부할수록 GraphRAG보다 먼저 Ontology 설계가 중요하다는 생각이 들었다.

관계가 제대로 정의되지 않으면 아무리 좋은 LLM을 붙여도 의미 있는 결과를 얻기 어렵기 때문이다.

내가 이해한 기준으로 정리하면 다음과 같다.

Ontology : 개념과 관계를 정의하는 설계도
Knowledge Graph : 실제 데이터가 연결된 그래프
GraphRAG : 그래프를 활용해 정보를 탐색하고 검색하는 기술

그리고 지하철 노선도로 비유하면

Ontology = 노선도 설계

Knowledge Graph = 실제 운행 정보가 포함된 노선도

GraphRAG = 노선도를 활용해 최적 경로를 찾아주는 앱

정도로 이해할 수 있을 것 같다.

Next.js에서 PWA로 오프라인 입력 데이터를 저장하고 재전송하기

Wed, 21 Jan 2026 23:50:39 GMT

현재 진행 중인 프로젝트에서 네트워크가 불안정한 환경에서도 사용자가 입력한 자료가 사라지지 않도록 개선하는 작업을 진행했다.

단순히 오프라인에서도 화면이 보이게 하는 것뿐 아니라, 사용자가 작성한 폼 데이터와 등록/수정 요청을 브라우저에 저장해두고 온라인 상태로 돌아왔을 때 다시 전송하는 흐름이 필요했다. 이 과정에서 PWA, Service Worker, Cache Storage, IndexedDB를 함께 적용하게 되었고, 적용하면서 알게 된 내용을 정리해보려고 한다.

PWA(Progressive Web App)

PWA는 Progressive Web App의 약자로, 웹을 앱처럼 동작하게 만드는 여러 기능을 포함한다. 홈 화면 설치, 전체 화면 실행, 푸시 알림 같은 기능도 PWA의 일부지만, 이번 프로젝트에서 중요했던 부분은 오프라인 대응이었다.

PWA를 적용하면 네트워크가 불안정하거나 끊긴 상황에서도 캐시된 리소스를 활용해 화면을 유지할 수 있다. 또한 자주 사용하는 파일을 캐시해두면 재방문 시 로딩 속도도 개선할 수 있다.

이번 프로젝트에서 기대했던 효과는 크게 두 가지였다.

1️⃣ 오프라인 또는 느린 네트워크에서도 최소한의 화면을 유지하는 것 2️⃣ 오프라인 상태에서 입력한 데이터를 저장해두고, 온라인 전환 시 다시 전송하는 것

즉, 단순히 앱처럼 설치되는 웹을 만드는 것이 아니라, 네트워크 상태가 좋지 않아도 사용자가 하던 작업을 이어갈 수 있도록 만드는 것이 핵심이었다.

🧩 PWA를 구성하는 기본 요소

PWA를 적용할 때 기본적으로 봐야 하는 요소는 크게 세 가지다.

1️⃣ HTTPS Service Worker는 보안 연결 환경에서 동작하기 때문에 운영 환경에서는 HTTPS가 필요하다.

*2️⃣ Manifest * 앱 이름, 아이콘, 시작 URL, 테마 색상처럼 브라우저가 이 웹앱을 설치 가능한 앱으로 인식하기 위한 정보를 담는다.

3️⃣ Service Worker Service Worker는 브라우저와 서버 사이에서 네트워크 요청을 가로채고, 캐시 전략이나 오프라인 동작을 처리하는 역할을 한다.

처음에는 이 세 가지를 각각 따로 봤지만, 실제로 구현해보니 역할을 나누어 이해하는 것이 더 중요했다. Manifest는 설치 정보를 담당하고, Service Worker는 요청 처리와 캐싱을 담당한다. 그리고 실제 데이터 저장은 Cache Storage와 IndexedDB를 상황에 맞게 나누어 사용해야 했다.

🗂️ Cache Storage와 IndexedDB의 역할 나누기

오프라인 대응을 하면서 가장 먼저 정리해야 했던 부분은 어떤 데이터를 어디에 저장할 것인가였다.

정적 리소스와 사용자가 입력한 데이터는 성격이 다르기 때문에 별도의 저장소를 필요로 할 것 같다는 생각이 들었다.

Cache Storage

Service Worker가 관리하는 응답 캐시 저장소로 JS, CSS, 이미지, 페이지 문서, API 응답처럼 네트워크 응답 형태로 다루기 좋은 데이터에 적합하다.

IndexedDB

브라우저 내장 로컬 DB에 가깝다. 리스트, 셀렉트 옵션, 트리 데이터처럼 구조화된 조회 데이터를 저장하거나, 오프라인 상태에서 발생한 등록/수정 요청을 큐 형태로 쌓아두기 좋다.

이번 프로젝트에서는 역할을 아래처럼 나누었다.

Cache Storage

앱 실행에 필요한 정적 리소스
Next.js 번들
이미지
페이지 문서 캐시

IndexedDB

온라인 상태에서 조회한 셀렉트 목록
폼 작성에 필요한 기준 데이터
오프라인 상태에서 작성한 등록/수정 요청
온라인 복귀 시 재전송할 요청 큐

이렇게 나누니 구조가 더 명확해졌다. Cache Storage는 앱을 다시 켜기 위한 껍데기 역할을 하고, IndexedDB는 화면 안에 채워 넣을 데이터와 사용자가 입력한 요청을 보관하는 역할을 하게 되었다.

⚙️ Next.js에 PWA 적용하기

Next.js에서 PWA를 적용하기 위해 next-pwa를 사용하여 Workbox 기반으로 서비스 워커와 캐시 전략을 빌드 단계에서 생성하는 방식을 선택했다.

기본 설정은 아래와 같이 구성했다.

const withPWA = require("next-pwa")({
  dest: "public",
  register: true,
  skipWaiting: true,
  clientsClaim: true,
  cacheOnFrontEndNav: true,
  cacheStartUrl: true,
  disable: process.env.NODE_ENV === "development",
  fallbacks: {
    document: "/",
  },
  runtimeCaching: [
    // cache rules
  ],
});

각 옵션의 역할을 정리하면 다음과 같다.

dest : "public"은 생성된 sw.js와 Workbox 관련 파일을 public 폴더에 생성하기 위한 설정이다. Service Worker는 브라우저에서 정적 파일처럼 접근할 수 있어야 하므로 일반적으로 public에 생성되도록 둔다.

register: true는 앱에서 Service Worker를 자동으로 등록하도록 한다.

skipWaiting: true는 새 Service Worker가 설치되었을 때 대기 상태에 머무르지 않고 바로 활성화되도록 하는 옵션이다.

clientsClaim: true는 활성화된 Service Worker가 현재 열려 있는 탭도 바로 제어하도록 한다. skipWaiting과 함께 사용하면 업데이트된 Service Worker를 비교적 빠르게 반영할 수 있다.

disable: process.env.NODE_ENV === "development"는 개발 환경에서는 PWA를 비활성화하기 위한 설정이다. 개발 중에는 캐시가 오히려 디버깅을 방해할 수 있기 때문에 운영 환경에서만 활성화되도록 했다.

🧱 App Shell 방식으로 오프라인 화면 유지하기

PWA를 적용하면서 가장 먼저 마주한 문제는 오프라인 상태에서 새로고침을 했을 때 앱이 아예 뜨지 않는 상황이었다.

사용자가 이미 화면을 보고 있다가 네트워크가 끊기는 것은 어느 정도 대응할 수 있었지만, 오프라인 상태에서 새로고침을 하거나 특정 URL로 바로 접근하면 문서 요청이 실패하면서 앱 자체가 뜨지 않았다.

이 문제를 해결하기 위해 App Shell 방식을 사용했다.

App Shell

앱을 실행하는 데 필요한 최소한의 껍데기를 캐시해두고, 오프라인에서도 우선 앱의 기본 화면을 띄우는 방식이다. 이후 화면에 필요한 실제 데이터는 IndexedDB에서 복원한다.

이번 설정에서는 아래 옵션들이 이 역할을 했다.

cacheStartUrl: true,
cacheOnFrontEndNav: true,
fallbacks: {
  document: "/",
},

cacheStartUrl: true는 앱의 시작 URL을 캐시에 저장한다. 오프라인에서 /로 폴백할 계획이라면 시작 URL 자체가 캐시에 있어야 안전하다.

cacheOnFrontEndNav: true는 Next.js의 클라이언트 라우팅 상황에서도 캐시가 쌓이도록 도와준다.

fallbacks: { document: "/" }는 문서 요청이 실패했을 때 /로 폴백하도록 한다. 즉, 오프라인에서 어떤 경로를 새로고침하더라도 우선 앱의 진입점을 띄우고, 이후 필요한 데이터는 별도로 복원하는 방향이다.

정리하면 아래와 같다.

오프라인에서 문서 요청 실패 ↓ 캐시된 "/" 문서로 폴백 ↓ 앱 Shell 실행 ↓ IndexedDB에서 화면 데이터 복원

🧠 runtimeCaching 설정하기

다음으로는 어떤 요청을 어떤 전략으로 캐싱할지 정리했다.

모든 요청을 같은 방식으로 캐싱하면 문제가 생길 수 있다. JS/CSS 번들처럼 변경이 적고 해시가 붙는 파일은 캐시에 오래 두어도 괜찮지만, 페이지 데이터나 API 응답처럼 최신성이 중요한 데이터는 네트워크를 먼저 확인하는 편이 낫다.

그래서 요청 성격에 따라 캐시 전략을 나누었다.

1️⃣. Next 데이터 JSON은 Network First

{
  urlPattern: /^\/_next\/data\/.*\.json$/i,
  handler: "NetworkFirst",
  options: {
    cacheName: "next-data",
    networkTimeoutSeconds: 3,
  },
}

/_next/data/*.json은 페이지 전환이나 프리패치에서 사용되는 데이터다. 최신 데이터가 중요하기 때문에 NetworkFirst 전략을 사용했다.

다만 네트워크가 애매하게 느릴 때 계속 기다리면 화면이 멈춘 것처럼 보일 수 있다. 그래서 networkTimeoutSeconds: 3을 두어 3초 안에 응답이 오지 않으면 캐시로 폴백하도록 했다.

2️⃣. Next 정적 번들은 Cache First
{ urlPattern: /^https?./_next/static/./i, handler: "CacheFirst", options: { cacheName: "next-static", }, }

/_next/static 하위의 JS/CSS 번들은 파일명에 해시가 붙기 때문에 캐시와 잘 맞는다. 한 번 받은 파일은 빠르게 재사용하는 것이 더 중요하다고 판단해 CacheFirst 전략을 사용했다.

3️⃣. 이미지는 Stale While Revalidate

{
  urlPattern: /^https?.*\/_next\/image\?url=.*/i,
  handler: "StaleWhileRevalidate",
  options: {
    cacheName: "next-image",
    expiration: {
      maxEntries: 200,
      maxAgeSeconds: 60 * 60 * 24 * 30,
    },
  },
}

이미지는 매번 최신을 받기보다 일단 빠르게 보여주는 것이 사용자 경험에 더 좋을 때가 많다. 그래서 캐시에 이미지가 있으면 먼저 보여주고, 뒤에서 최신 이미지를 받아 캐시를 갱신하는 StaleWhileRevalidate 전략을 사용했다.

이미지 캐시는 용량이 커질 수 있기 때문에 최대 개수와 보관 기간도 함께 제한했다.

4️⃣. 문서 요청은 Network First

{
  urlPattern: ({ request }) => request.mode === "navigate",
  handler: "NetworkFirst",
  options: {
    cacheName: "pages",
    networkTimeoutSeconds: 3,
    expiration: {
      maxEntries: 50,
      maxAgeSeconds: 60 * 60 * 24 * 7,
    },
  },
}

문서 요청은 오프라인 새로고침 안정성과 관련이 있다. 온라인 상태에서는 최신 문서를 받는 것이 좋지만, 오프라인이거나 네트워크 응답이 늦으면 캐시된 문서를 보여줘야 한다.

그래서 문서 요청은 NetworkFirst로 두고, 네트워크 응답이 3초 이상 지연되면 캐시로 폴백하도록 했다.

📝 Manifest 설정하기

PWA로 설치 가능한 앱처럼 동작하려면 Manifest 설정도 필요하다.

Next.js App Router에서는 app/manifest.ts로 Manifest를 제공할 수 있다.

import type { MetadataRoute } from "next";

export default function manifest(): MetadataRoute.Manifest {
  return {
    name: "My Next PWA",
    short_name: "MyPWA",
    description: "Next.js로 만든 PWA",
    start_url: "/",
    display: "standalone",
    background_color: "#ffffff",
    theme_color: "#000000",
    icons: [
      {
        src: "/icon-192x192.png",
        sizes: "192x192",
        type: "image/png",
      },
      {
        src: "/icon-512x512.png",
        sizes: "512x512",
        type: "image/png",
      },
    ],
  };
}

start_url: 설치된 앱을 실행했을 때 처음 열리는 경로다.

display: "standalone"은 주소창이 보이지 않는 독립 앱처럼 실행되도록 한다.

icons: 홈 화면에 추가했을 때 사용할 아이콘이다. 보통 192px, 512px 아이콘은 기본적으로 준비하는 것이 좋다.

Pages Router를 사용하거나 public/manifest.json으로 직접 제공하는 경우에는 _app.tsx 또는 문서 설정에 아래처럼 manifest 링크를 추가할 수 있다.

🔍 빌드 후 Service Worker 확인하기

설정을 마친 뒤 npm run build와 npm run start로 운영 빌드 환경에서 실행하면 public 폴더에 sw.js와 Workbox 관련 파일이 생성된다.

브라우저에서는 DevTools의 Application 탭에서 Service Worker가 정상적으로 등록되었는지 확인할 수 있다.

여기서 Service Worker 상태가 활성화되어 있고 실행 중으로 표시되면 기본 등록은 정상적으로 된 것이다.

💾 오프라인 입력 데이터 저장하기

PWA 설정만으로는 오프라인에서 입력한 데이터를 저장하고 재전송할 수 없다. Service Worker와 Cache Storage는 앱을 띄우고 리소스를 캐싱하는 데 도움을 주지만, 사용자가 작성한 폼 데이터나 등록 요청은 별도로 저장해야 한다.

이번 프로젝트에서는 온라인 상태일 때 미리 조회한 셀렉트 목록과 폼 입력 데이터를 IndexedDB에 저장했다.

오프라인 상태에서 사용자가 등록 또는 수정 요청을 하면, 바로 API를 호출하는 대신 요청 정보를 IndexedDB에 큐 형태로 저장했다. 이후 온라인 상태로 돌아오면 큐에 쌓인 요청을 하나씩 꺼내 서버로 전송하도록 구성했다.

흐름을 정리하면 아래와 같다.

온라인 상태 ↓ 셀렉트 목록, 기준 데이터 조회 ↓ IndexedDB에 저장

오프라인 상태 ↓ 사용자가 폼 작성 후 등록/수정 ↓ API 요청 대신 IndexedDB Queue에 저장

온라인 전환 ↓ Queue에서 요청을 하나씩 꺼냄 ↓ 서버로 재전송 ↓ 성공한 요청은 Queue에서 제거

이 방식의 장점은 사용자가 네트워크 상태를 크게 신경 쓰지 않고 작업을 이어갈 수 있다는 점이다. 오프라인 상태에서 작성한 데이터가 사라지지 않고, 온라인으로 돌아왔을 때 자동으로 전송되기 때문이다.

✅ 적용하면서 느낀 점

이번 작업을 하면서 PWA는 단순히 Manifest를 추가하고 Service Worker를 등록하는 것으로 끝나는 기능이 아니라는 것을 느꼈다.

오프라인 화면을 유지하려면 Cache Storage가 필요하고, 사용자가 입력한 데이터를 보관하려면 IndexedDB가 필요했다. 또한 온라인으로 돌아왔을 때 요청을 다시 보내려면 큐 구조와 재전송 흐름도 함께 설계해야 했다.

특히 Cache Storage와 IndexedDB의 역할을 나누는 것이 중요했다.

Cache Storage는 앱을 다시 실행할 수 있게 해주는 정적 리소스와 응답 캐시에 적합했고, IndexedDB는 화면에 뿌릴 구조화된 데이터와 오프라인 요청을 저장하는 데 더 적합했다.

처음에는 오프라인 대응을 “캐시를 잘 하면 되는 문제”라고 생각했지만, 실제로는 화면 유지, 데이터 복원, 사용자 입력 저장, 온라인 복귀 후 동기화까지 함께 고려해야 하는 작업이었다.

앞으로 비슷한 기능을 구현하게 된다면 먼저 아래 질문부터 정리해볼 것 같다.

오프라인에서도 꼭 보여줘야 하는 화면은 어디까지인가? 어떤 데이터는 캐시하고, 어떤 데이터는 IndexedDB에 저장할 것인가? 사용자가 오프라인에서 작성한 요청은 어떤 형식으로 저장할 것인가? 온라인으로 돌아왔을 때 요청을 어떤 순서로 재전송할 것인가? 재전송 실패 시 사용자에게 어떻게 보여줄 것인가?

이번 경험을 통해 PWA는 단순히 웹을 앱처럼 보이게 만드는 기술이 아니라, 네트워크가 불안정한 상황에서도 사용자의 작업 흐름을 최대한 유지하기 위한 구조라는 것을 알게 되었다.

OpenLayers Overlay와 iframe 레이어 문제

Sun, 11 Jan 2026 23:41:21 GMT

대시보드 화면에서 지도를 렌더링하고, 그 위에 여러 위젯을 iframe 형태로 배치하는 구조를 작업한 적이 있다. 지도 위에는 OpenLayers Overlay를 사용해 마커 클릭 시 팝업을 띄우고 있었다.

처음에는 단순한 레이어 문제라고 생각했다. 팝업이 위젯 아래로 가려졌기 때문에 z-index를 조정하면 해결될 것이라고 생각했지만 실제 구조를 확인해보니 그 문제가 아닌걸 알 수 있었다.

📌 문제 상황

대시보드 상위 페이지에 지도를 렌더링하고, 그 위에 iframe 형태의 위젯 UI가 함께 배치된 구조였다.

지도 위에는 OpenLayers Overlay를 사용해 마커 클릭 시 팝업을 띄우고 있었다. 그런데 위젯을 접거나 펼칠 때 iframe 상단 타이틀 영역이 레이아웃을 차지하면서, 지도 Overlay 팝업이 iframe 아래로 가려지는 현상이 발생했다.

대시보드 상위 페이지
├─ 지도 영역
│  └─ OpenLayers Overlay 팝업
└─ iframe 위젯 영역
   └─ 위젯 UI

지도 자체는 정상적으로 렌더링되고 있었지만, 팝업 일부가 보이지 않거나 클릭할 수 없는 상태가 되었다.

❗ 핵심 원인

구조를 뜯어보면 지도와 Overlay는 대시보드 상위 문서의 DOM 안에서 OpenLayers 기준으로 렌더링되고 있었다. 반면 위젯은 지도 위에 겹쳐진 iframe 레이어이다.

지도 + Overlay
→ 대시보드 DOM 안에서 OpenLayers 기준으로 위치 계산

iframe 위젯
→ 지도 위에 겹쳐진 별도의 레이어

즉, 지도 Overlay는 지도 좌표 기준으로는 정상 위치에 있었다. 하지만 iframe은 화면 상단 기준으로 레이아웃을 차지하고 있었고, 이 둘의 표시 기준이 달라 Overlay가 iframe 아래로 가려지는 문제가 발생했다.

기존 Overlay 구현 코드

기존에는 마커를 클릭하면 팝업 DOM을 생성하고, Vue 컴포넌트를 마운트한 뒤 OpenLayers Overlay로 지도에 추가하는 방식이었다.

/**
 * 클릭된 장비 마커에 팝업을 표시합니다.
 * - 동일 장비(eqpmSn)에 대해 중복 팝업을 방지합니다.
 * @param {IEquipment} item - 클릭된 장비 정보
 * @param {[number, number]} coordinate - 팝업 표시 좌표
 */
function showClickPopup(item: IEquipment, coordinate: [number, number]) {
  // 이미 열린 팝업이면 중복 생성 방지
  if (clickPopupOverlays.has(item.eqpmtSn)) return;

  const map = imgMapRef.value?.getImgMapInstance();
  if (!map) return;

  const el = document.createElement('div');
  el.className = 'marker-popup-container click-popup';

  const app = createApp(PopupContent, {
    data: item,
    onClose: () => clearClickPopup(item.eqpmtSn)
  });

  app.mount(el);

  const overlay = new Overlay({
    element: el,
    positioning: 'center-center',
    stopEvent: true,
    offset: [0, 0],
    position: coordinate
  });

  map.addOverlay(overlay);
  makeOverlayDraggable(overlay, map);

  clickPopupOverlays.set(item.eqpmtSn, overlay);
  clickPopupApps.set(item.eqpmtSn, app);
}

이 구조에서 팝업 DOM은 Vue로 생성했지만, 최종적으로는 OpenLayers Overlay로 지도에 추가된다. 즉, Overlay는 항상 OpenLayers가 생성한 overlay container 안에서 렌더링된다.

🔄 시도했던 방법 — Teleport

처음에는 이 문제를 레이어 문제로 판단했다. 그래서 Overlay UI를 지도 컨테이너 밖으로 빼면 iframe 레이아웃의 영향을 덜 받지 않을까 생각했다.

이때 검토했던 방법이 Vue의 Teleport였다.

Overlay 내부의 Vue 컴포넌트를 body 같은 다른 DOM 위치로 이동시키면, iframe 아래로 가려지는 문제를 피할 수 있지 않을까 생각했다.

Teleport란?

Vue의 Teleport는 컴포넌트를 현재 컴포넌트 트리 위치와 상관없이 지정한 다른 DOM 위치로 렌더링할 수 있게 해주는 기능이다.

대표적인 사용 예시는 다음과 같다.

모달
툴팁
글로벌 팝업

부모 컴포넌트의 overflow, z-index, stacking context 영향을 피하고 싶을 때 자주 사용한다.

👉 Teleport의 한계

Teleport는 Vue 컴포넌트의 DOM 위치만 이동시킬 뿐, 브라우저 렌더링 컨텍스트나 외부 라이브러리의 좌표 계산 방식까지 바꾸지는 않는다.

OpenLayers Overlay는 지도 컨테이너를 기준으로 좌표를 계산하고 렌더링한다. 반면 Teleport는 Vue 컴포넌트가 어느 DOM 위치에 그려질지만 바꾼다.

Teleport
→ Vue 컴포넌트 DOM 위치 이동

OpenLayers Overlay
→ 지도 좌표와 Overlay container 기준으로 위치 계산

즉, 두 기능은 역할과 책임 레벨이 다르다.

Teleport를 사용하면 DOM 위치는 이동시킬 수 있지만, OpenLayers가 Overlay를 지도 좌표 기준으로 관리한다는 사실은 변하지 않는다. 결과적으로 Teleport를 사용해도 Overlay가 가지는 근본적인 구조는 바뀌지 않았다.

그래서 이 방식은 문제를 해결하기보다는 화면에 보이는 DOM만 우회해서 옮기려는 시도에 가깝다고 판단했다.

✅ 해결 방법

Overlay를 지도 컨테이너 밖으로 억지로 옮기기보다 Overlay가 표시되는 기준을 조정하는 방향으로 접근을 바꿨다.

Overlay가 iframe 상단 영역과 겹치는 위치에 표시되면서 가려지는 것이었기 때문에 팝업을 띄울 때 현재 위젯이 접혀 있는지, 펼쳐져 있는지에 따라 iframe이 차지하는 영역을 확인하고 Overlay가 해당 영역과 겹치지 않도록 표시 위치를 조정했다.

기존에는 마커 좌표를 그대로 Overlay 위치로 사용했다.

const overlay = new Overlay({
  element: el,
  positioning: 'center-center',
  stopEvent: true,
  offset: [0, 0],
  position: coordinate
});

하지만 iframe 타이틀 영역이나 위젯 영역이 지도 위를 덮는 경우에는 팝업이 그 영역 안으로 들어가지 않도록 offset 또는 표시 기준을 조정해야 했다.

예를 들어 팝업이 위젯 상단 영역과 겹칠 수 있는 경우에는 Overlay의 위치를 그대로 사용하지 않고, 위젯이 차지하는 높이만큼 화면 안쪽으로 내려주거나, 팝업이 보이는 방향으로 offset을 조정하는 식으로 처리했다.

const overlay = new Overlay({
  element: el,
  positioning: 'bottom-center',
  stopEvent: true,
  offset: [0, adjustedOffsetY],
  position: coordinate
});

✅ 정리

OpenLayers Overlay는 지도 좌표와 지도 컨테이너를 기준으로 동작
iframe은 별도의 문서와 레이어 컨텍스트를 가짐
Teleport는 Vue 컴포넌트의 DOM 위치를 이동시키는 도구

HLS와 WebRTC

Sun, 11 Jan 2026 23:29:54 GMT

HLS와 WebRTC, 실시간 CCTV 위젯에서는 무엇을 선택해야 할까?

대시보드에 실시간 CCTV 영상 위젯을 만드는 기능을 개발하면서 HLS를 사용한 적이 있다. 처음에는 CCTV 영상을 화면에 보여주는 작업이라 단순히 영상 URL을 받아 video 태그에 연결하면 될 것이라고 생각했다. 하지만 실제로 구현해보니 생각보다 고려할 부분이 많았다.

브라우저에서 HLS를 바로 재생할 수 있는지, CCTV URL이 바뀌었을 때 기존 플레이어를 어떻게 정리할지, 단일 영상과 여러 영상을 보여주는 화면을 어떻게 나눌지, 라이브 영상의 지연 시간과 안정성 사이에서 어떤 값을 선택할지 등을 함께 봐야 했다.

이 과정에서 자연스럽게 HLS와 WebRTC의 차이도 궁금해졌다. 둘 다 웹에서 영상을 다룰 때 자주 언급되는 기술이지만, 실제로는 목적이 다르다. HLS는 안정적으로 영상을 전달하는 데 강점이 있고, WebRTC는 지연 시간을 줄여 실시간으로 주고받는 데 강점이 있다.

이번 글에서는 HLS와 WebRTC가 각각 어떤 방식으로 동작하는지, 그리고 대시보드 CCTV 위젯 같은 상황에서는 어떤 기준으로 선택하면 좋을지 정리해보려고 한다.

HLS란?

HLS는 HTTP Live Streaming의 약자다. 이름 그대로 HTTP 기반으로 영상을 전달하는 스트리밍 방식이다.

HLS는 하나의 긴 영상을 그대로 보내는 것이 아니라, 영상을 작은 조각으로 나눈 뒤 클라이언트가 그 조각들을 순서대로 받아 재생한다. 이때 어떤 조각을 어떤 순서로 받아야 하는지 알려주는 파일이 .m3u8 플레이리스트다.

흐름을 단순하게 보면 아래와 같다.

원본 영상
  ↓
작은 세그먼트로 분할
  ↓
.m3u8 플레이리스트 생성
  ↓
브라우저에서 세그먼트를 순서대로 받아 재생

웹에서 HLS를 사용할 때는 보통 hls.js 같은 라이브러리를 사용한다. 내가 구현한 CCTV 위젯에서도 브라우저에서 HLS를 재생하기 위해 hls.js를 사용했다.

import Hls from 'hls.js';

const videoRef = ref(null);
let hls: Hls | null = null;

const initPlayer = (url: string) => {
  if (!url) return;

  const video = videoRef.value as HTMLVideoElement;

  if (Hls.isSupported()) {
    if (hls) {
      hls.destroy();
      hls = null;
    }

    hls = new Hls({
      liveSyncDuration: 30,
      maxBufferLength: 60,
      maxMaxBufferLength: 120,
    });

    hls.attachMedia(video);
    hls.loadSource(url);

    hls.on(Hls.Events.MANIFEST_PARSED, () => {
      video.play();
    });
  } else if (video.canPlayType('application/vnd.apple.mpegurl')) {
    video.src = url;
    video.addEventListener('loadedmetadata', () => {
      video.play();
    });
  }
};

코드만 보면 단순히 HLS 소스를 로드하고 재생하는 것처럼 보이지만, 실제로는 몇 가지를 신경 써야 했다.

첫 번째는 브라우저 지원 여부였다. 모든 브라우저가 HLS를 같은 방식으로 지원하지 않기 때문에, 먼저 Hls.isSupported()로 hls.js 사용 가능 여부를 확인했다. 지원되는 환경에서는 hls.js를 통해 .m3u8 스트림을 video 태그에 연결했고, 네이티브 HLS를 지원하는 환경에서는 video.canPlayType('application/vnd.apple.mpegurl') 조건으로 직접 재생할 수 있도록 분기했다.

두 번째는 CCTV URL이 바뀌는 상황이었다. 대시보드 위젯에서는 사용자가 다른 CCTV를 선택할 수 있기 때문에, 처음 한 번 연결한 스트림만 계속 재생하는 구조로는 부족했다. 그래서 props.cctvurl 변경을 감지하고, URL이 바뀔 때마다 플레이어를 다시 초기화하도록 구성했다.

watch(
  () => props.cctvurl,
  async (newUrl) => {
    await nextTick();
    if (videoRef.value) initPlayer(newUrl);
  }
);

여기서 중요한 점은 기존 HLS 인스턴스를 정리하는 것이었다. 새로운 CCTV 스트림을 연결하기 전에 기존 hls 인스턴스가 남아 있으면 이전 스트림 연결이 유지되거나 불필요한 리소스를 계속 사용할 수 있다. 그래서 새 인스턴스를 만들기 전에 기존 인스턴스가 있다면 destroy()로 정리한 뒤 다시 생성하도록 했다.

세 번째는 라이브 버퍼 설정이었다.

hls = new Hls({
  liveSyncDuration: 30,
  maxBufferLength: 60,
  maxMaxBufferLength: 120,
});

실시간 CCTV라고 해서 무조건 지연 시간을 최소화하는 것만 중요한 것은 아니었다. 대시보드 관제 화면에서는 영상이 너무 자주 끊기지 않고 안정적으로 재생되는 것도 중요했다. 그래서 라이브 버퍼 목표 시간과 최대 버퍼 길이를 설정해, 실시간성과 재생 안정성 사이에서 균형을 맞추려고 했다.

WebRTC란?

HLS를 사용하면서 같이 비교해보게 된 기술이 WebRTC였다. 직접 프로젝트에 적용해본 것은 아니지만, 영상 스트리밍 방식을 찾아보다 보면 HLS와 함께 자주 언급되는 기술이라 차이를 정리해보고 싶었다. WebRT는 Web Real-Time Communication의 약자다. 브라우저에서 별도 플러그인 없이 오디오, 비디오, 데이터를 실시간으로 주고받기 위한 기술이다. HLS처럼 서버에 있는 영상 조각을 받아 재생하는 방식이라기보다, 연결을 맺은 뒤 미디어 스트림을 실시간으로 주고받는 방식에 가깝다.

그래서 WebRTC는 화상회의, 음성 통화, 원격 제어처럼 지연 시간이 짧아야 하는 서비스에서 많이 사용된다. 예를 들어 사용자의 카메라 영상을 가져오는 기본 코드는 아래처럼 작성할 수 있다.

const stream = await navigator.mediaDevices.getUserMedia({
  video: true,
  audio: true,
});

const video = document.querySelector('video') as HTMLVideoElement;
video.srcObject = stream;

다만 실제 서비스에서 WebRTC를 사용하려면 이 코드만으로 끝나지는 않는다. 서로 연결 정보를 주고받는 signaling 과정이 필요하고, 네트워크 환경에 따라 STUN, TURN 서버를 사용해야 할 수도 있다. 여러 사용자가 동시에 연결되는 구조라면 SFU 같은 미디어 서버도 고려해야 한다.

정리하면 WebRTC는 지연 시간을 줄이는 데 강점이 있지만, 그만큼 연결 관리나 서버 구성 측면에서 고려할 부분도 많아 보였다. 그래서 단순히 실시간 영상이면 WebRTC가 더 좋다라고 보기보다는, 서비스에서 어느 정도의 실시간성이 필요한지를 먼저 봐야 한다고 느꼈다.

HLS와 WebRTC 비교

두 기술을 비교할 때 가장 먼저 봐야 할 기준은 지연 시간이 얼마나 중요한지라고 생각했다.

HLS는 HTTP 기반으로 동작하고, 영상을 작은 조각으로 나누어 받아 재생하는 방식이다. 그래서 기존 웹 서버나 CDN과 잘 맞고, 여러 사용자가 안정적으로 영상을 보는 상황에 적합하다. 대신 구조적으로 어느 정도의 지연 시간은 발생할 수 있다.

반대로 WebRTC는 연결을 맺은 뒤 미디어 스트림을 실시간으로 주고받는 방식이라 지연 시간을 줄이는 데 강점이 있다. 다만 signaling, STUN/TURN, 미디어 서버 같은 요소를 함께 고려해야 해서 HLS보다 구현과 운영이 복잡할 수 있다.

두 방식의 차이를 간단히 정리하면 아래처럼 볼 수 있다.

기준	HLS	WebRTC
목적	안정적인 영상 전달	지연 시간을 줄인 실시간 통신
방식	영상을 조각으로 나누어 HTTP로 재생	연결을 맺고 미디어 스트림을 실시간 전송
지연 시간	상대적으로 있음	낮음
구현 난이도	비교적 단순	상대적으로 복잡
확장성	CDN 활용이 쉬움	대규모 확장 시 별도 미디어 서버 고려 필요
적합한 사례	라이브 방송, VOD, CCTV 모니터링	화상회의, 원격 제어, 양방향 영상 통신

CCTV 위젯에서는 왜 HLS를 사용했을까?

내가 개발했던 CCTV 위젯은 사용자가 대시보드에서 영상을 확인하는 용도에 가까웠다. 영상을 보면서 카메라와 양방향으로 통신하거나, 화면에서 즉시 장비를 제어하는 구조는 아니었다. 여러 위젯이 함께 있는 대시보드 안에서 CCTV 영상을 안정적으로 보여주는 것이 더 중요한 상황이었다.

이 기준으로 보면 HLS가 더 잘 맞는 방식이라고 생각했다. 지연 시간을 최대한 줄이는 것보다, 브라우저에서 안정적으로 재생되고 기존 웹 구조 안에서 비교적 단순하게 다룰 수 있는 점이 더 중요했기 때문이다.

실제 구현에서도 단순히 영상 URL을 연결하는 것에서 끝나지는 않았다. CCTV URL이 바뀌면 새로운 스트림을 다시 연결해야 했고, 단일 화면과 멀티 화면도 나누어 보여줘야 했다. 영상이 없는 경우에는 빈 상태도 필요했다. 이런 흐름을 처리할 때 hls.js를 사용하면 스트림 연결, 재초기화, 브라우저 지원 분기를 비교적 일관된 방식으로 가져갈 수 있었다.

물론 CCTV라고 해서 항상 HLS가 맞다고 생각하지는 않는다. 만약 영상을 보면서 장비를 바로 제어해야 하거나, 현장 상황이 거의 즉시 반영되어야 하는 서비스라면 WebRTC를 검토해야 할 것 같다. 몇 초의 지연도 문제가 되는 상황이라면 안정적인 재생보다 낮은 지연 시간이 더 중요한 기준이 될 수 있기 때문이다.

결론적으로 단순히 현재 상황을 모니터링하는 정도라면 HLS로도 충분할 수 있고, 즉각적인 상호작용이 필요하다면 WebRTC가 더 적합해 보인다고 생각했다.

실무에서 선택할 때 보는 기준

이번에 HLS를 사용하고 WebRTC와 비교해보면서, 영상 스트리밍 방식을 선택할 때는 몇 가지 기준을 먼저 봐야겠다고 생각했다.

1️⃣ 지연시간이 얼마나 중요한가?

몇 초 정도의 지연이 허용되는 화면이다? HLS 사용자의 행동이나 현장 상황이 거의 바로 반영되어야 한다? WebRTC

2️⃣ 양방향 통신이 필요한가?

사용자가 영상을 보기만 하는 구조이다? HLS 서로 영상을 주고받거나, 사용자의 입력이 영상 흐름에 바로 영향을 주는 구조이다? WebRTC

3️⃣ 같은 영상을 얼마나 많은 사용자가 보는가?

여러 사용자가 같은 영상을 안정적으로 봐야 한다? HLS 왜냐하면 HTTP 기반으로 동작하고 CDN을 활용하기 쉬워 확장성 측면에서 유리하기 때문이다. 반면 WebRTC는 낮은 지연 시간을 얻을 수 있지만, 사용자가 많아질수록 미디어 서버나 연결 구조를 더 신경 써야 할 것 같다.

4️⃣ 운영 복잡도

HLS는 상대적으로 단순하게 구성 가능. WebRTC는 signaling, STUN/TURN, 연결 상태 관리 같은 요소를 함께 봐야 하기 때문에, 초저지연이 꼭 필요한 서비스인지 먼저 판단하는 것이 중요하다고 느꼈다.

비전공자 개발자의 CS 공부기록(2)

Sat, 19 Apr 2025 07:38:49 GMT

📌 웹 애플리케이션 아키텍처의 구조와 역할

웹 클라이언트

사용자가 웹에 접근할 때 사용하는 프로그램
크롬, 사파리, 엣지 등의 웹 브라우저

웹 서버

웹 클라이언트로부터 HTTP 요청을 받아 데이터를 전달하는 프로그램
아파치 웹 서버, IIS(Internet Information Services), 엔진엑스(Nginx) 등

WAS(Web Application Server)

웹 서버로부터 주로 동적 콘텐츠를 받아 이를 처리한 뒤, 그 결과를 다시 웹 서버에 전달하는 중간자 역할
웹 서버가 해야 하는 일을 나눠 가지며 서버의 부담을 줄이고 전체 웹 통신의 효율을 높이는 조력자 역할
톰캣, 제우스, IBM 웹스피어 등

데이터베이스(DB)

웹 서비스에 필요한 다양한 데이터를 체계적으로 저장하는 곳이며 WAS에서 동적 콘텐츠를 제공하기 위해 접근하는 장소
MySQL, 오라클, MongoDB 등

📌 HTTP란?

HTTP(Hypertext Transfer Protocol) 란 웹 브라우저와 웹 서버 간에 데이터를 주고 받기 위해 사용하는 클라이언트/서버 모델을 따르는 프로토콜이다.

특징

한 번 통신을 주고받으면 연결을 끊는 비연결성 프로토콜이다.

헤더 · '헤더명: 헤더값'의 형식으로 작성하며 대소문자를 구분하지 않는다. · 헤더 종류

 ㄴ 공통 헤더 : Date / Cache-control
 ㄴ 요청 헤더 : Host / User-Agent
 ㄴ 응답 헤더 : Server / Location
 ㄴ 엔티티 헤더(메시지 본문에 대한 정보를 포함하는 헤더) : Content-Length / Content-Type
 ![](https://velog.velcdn.com/images/ssooo_kk_77/post/486e0b01-ddfd-488c-9d35-2b82f7aa828a/image.png)

한계 ㄴ 정보를 암호화하지 않은 상태로 보내기 때문에 정보 유출의 위험에 노출될 가능성이 높다. ㄴ 통신 상대를 확인하지 않기 때문에 누가 요청을 보냈는지, 통신 중인 상대가 허가된 상대인지 파악할 방법이 없다.
상태 코드 1️⃣XX : 웹 서버가 현재 요청을 받았으며 작업을 진행하고 있다. 100(Continue) : 서버가 요청을 받았으며 추가 요청을 기다리고 있음.

2️⃣XX : 클라이언트가 요청한 작업을 서버가 성공적으로 처리했다. 200(Ok) : 요청이 성공적으로 되었습니다. 201(Created) : 요청이 성공적이었으며 그 결과로 새로운 리소스가 생성되었습니다. 204(No Content) : 요청은 성공적으로 처리되었지만 응답 본문이 없습니다.

3️⃣XX : 리다이렉션 완료 응답으로 요청을 완료하기 위해 재전송이 필요하다. 301(Moved Permanently) : 추가로 요청한 페이지로 영구 이동되었습니다. 302(Found) : 추가로 요청한 페이지로 일시적으로 이동되었습니다. 304(Not Modified) : 리소스가 수정되지 않았으므로 캐시된 데이터를 사용해도 됩니다.

4️⃣XX : 클라이언트측에 오류가 있다. 400(Bad Request) : 클라이언트의 요청 내용에 문제가 있습니다. 401(Unauthorized) : 인증되지 않은 사용자입니다. 404(Not Found) : 요청에는 문제가 없으나 요청한 데이터가 없습니다.

5️⃣XX : 서버가 요청을 수행하지 못했음. 500(Internal Server Error) : 서버 내부적으로 오류가 발생해 응답에 실패했습니다. 502(Bad Gateway) : 서버가 다른 서버로부터 잘못된 응답을 받는 등 서버간의 네트워크에 문제가 생겨 통신이 제대로 되지 않습니다. 503(Service Unavailable) : 서버가 일시적으로 과부하 상태이거나 유지보수 중입니다. 504(Gateway Timeout) : 게이트웨이 또는 프록시 서버가 응답을 기다리다 시간이 초과되었습니다.

📌 HTTPS란?

HTTP 계층 아래 SSL이라는 보안 계층이 추가된 프로토콜이다.

🔆 SSL의 동작 과정 SSL은 공개키 기법과 대칭키 기법이라는 두 암호화 기법을 함께 사용한다. (관련 포스팅 보기) SSL은 크게 핸드셰이크, 세션, 세션 종료의 세 단계로 이루어진다.

1단계 : 클라이언트가 랜덤한 데이터와 함께 현재 지원할 수 있는 암호화 방식을 서버에 전달한다. 2단계 : 서버가 클라이언트에게 랜덤 데이터와 지원 가능한 암호화 방식, 인증서(서버가 공식적으로 인증된 기관인 CA에서 발급받은 문서)를 전달한다. 3단계 : 인증서를 발급받은 클라이언트는 이 인증서가 제대로 된 문서인지 검증하기 위해 CA가 발급한 인증서 목록 중에서 서버가 전달한 인증서가 있는지 확인한다. 인증서가 목록에 있다면 한 번 더 확인하기 위해 CA에서 공유하는 공개키를 가지고 인증서를 복호화한다. 복호화에 성공한다면 이 인증서는 서버가 자신의 비밀키로 암호화했다는 것이 검증되니 서버를 신뢰할 수 있게 된다. 4단계 : 본격적으로 키를 주고받기 위해 클라이언트는 실제 데이터 통신에서 사용할 대칭키를 임시로 만든다.(이 때 대칭키는 클라이언트와 서버가 서로 주고받은 랜덤한 데이터를 조합한 임시키이다.)임시키는 대칭키이기 때문에 앞서 갖고 있던 공개키로 암호화해 서버에 전달한다. 5단계 : 키를 받은 서버는 자신이 갖고 있던 비밀키로 암호를 해독해 임시 키를 전달받는다. 6단계 : 클라이언트와 서버의 임시 키는 일련의 과정을 거쳐 세션 키로 바뀌고 이 세션키를 이용해 본격적으로 클라이언트와 서버가 통신을 할 수 있게 된다.

[출처] - 그림으로 쉽게 이해하는 웹/HTTP/네트워크

DHTMX 간트차트 구현기

Sat, 12 Apr 2025 05:24:56 GMT

진행하는 프로젝트에서 간트차트로 일정관리하는 기능 개발을 담당하게 되어 여러 라이브러리를 비교하던 중

UI가 깔끔하고
React를 지원하며
문서화가 잘 되어있는

DHTMLX(공식문서) 라이브러리를 사용하기로 했다.

주요 기능들과 커스텀한 내용을 소개해보자면

1️⃣ 커스텀 스크롤

원래 기본 스크롤은 왼쪽 그리드 영역은 고정이고 오른쪽 차트 영역을 스크롤하는 것이었다. 하지만 위와같이 그리드 영역이 좁아질 경우 데이터를 제대로 보여주지 못하는 문제가 있어 그리드 영역과 차트 영역 각각에 스크롤을 설정해 컨트롤할 수 있게 개선이 필요했다.

          gantt.config.layout = {
                css: "gantt_container",
                cols: [
                    {
                        width: 400,
                        min_width: 400,
                        rows: [
                            {view: "grid", scrollable: true, scrollX: "gridScrollHor", scrollY: "scrollVer"},
                            {view: "scrollbar", id: "gridScrollHor", height: 20},
                        ],
                    },
                    {
                        rows: [
                            {view: "timeline", scrollable: true, scrollX: "timelineScrollHor", scrollY: "scrollVer", width: 1},
                            {view: "scrollbar", scroll: "x", id: "timelineScrollHor", height: 20},
                        ],
                    },
                    {view: "scrollbar", id: "scrollVer"},
                ],
            };

왼쪽 그리드 영역은 width를 400px로 고정하고 그 외의 영역은 timeline이 차지하도록 width : 1을 설정했다.

2️⃣ locale ko로 수정

gantt.locale = {
                date: {
                    month_full: ["1월", "2월", "3월", "4월", "5월", "6월", "7월", "8월", "9월", "10월", "11월", "12월"],
                    month_short: ["1월", "2월", "3월", "4월", "5월", "6월", "7월", "8월", "9월", "10월", "11월", "12월"],
                    day_full: ["일요일", "월요일", "화요일", "수요일", "목요일", "금요일", "토요일"],
                    day_short: ["일", "월", "화", "수", "목", "금", "토"],
                },
                labels: {
                    new_task: "새일정",
                    dhx_cal_today_button: "오늘",
                    day_tab: "일",
                    week_tab: "주",
                    month_tab: "월",
 ...

한국어로 date 표시 및 ui 요소(버튼명, 폼 필드명 등)에 표시되는 라벨명 수정

++ 라벨 추가는

gantt.locale.labels.section_modification_reason = "일정 변경 사유";

3️⃣ date 순서 변경

기본 date format은 dd-mm-yy 순

✔️ yy-mm-dd순으로 변경

 gantt.config.date_format = "%Y-%m-%d %H:%i";

4️⃣ onBeforeLightbox

일정 등록/수정/삭제를 위한 모달을 lightbox라고 하는데 이 모달이 열리기전에 하고자 하는 작업을 설정할때 사용하는 함수이다.

gantt.attachEvent("onBeforeLightbox", function(id) {
    const task = gantt.getTask(id);
    task.my_template = `Holders: ${task.users}
    Progress: ${task.progress*100}%`;
    return true;
});

나는 여기에 따로 외부에서 만든 셀렉트 박스 컴포넌트를 주입하기 위해

gantt.config.buttons_right = ["dhx_delete_btn"];
gantt.config.lightbox.sections = [
                                {
                                    name: "food", 
                                    height: 35,
                                    map_to: "food",
                                    type: "textarea",
                                },
                                {
                                    name: "drink", 
                                    height: 20,
                                    map_to: "drink",
                                    type: "custom",
                                },

lightbox.sections의 type을 custom으로 설정하고

 const addMuntoContainer: LightboxControl = {
                render: function (sns: any) {
                    return ``;
                },

                set_value: function (node: HTMLElement, value: string, task: any, section: any) {
                    ...
                },

                get_value: function (node: HTMLElement, task: any, section: any) {
                    return task.muntno || "";
                },
            };

  gantt.form_blocks["custom"] = addMuntoContainer;

form_blocks의 type이 custom인 영역에 div태그를 추가해주었다.

5️⃣ onLightbox

모달이 열렸을 때 실행하는 함수로 onBeforeLightbox에서 생성한 div 태그를 찾아 외부에서 만든 컴포넌트를 렌더링 해주었다.

            gantt.attachEvent("onLightbox", function (id: number) {
                const task = gantt.getTask(id);

                const lightbox = document.querySelector(".custom_muntno_container");

                if (lightbox) {
                    if (rootInstance) {
                        rootInstance.unmount();
                    }

                    rootInstance = createRoot(lightbox);
                    rootInstance.render(
                        ,
                    );
                }
            });

6️⃣ onLightboxSave

모달에서 save 버튼 클릭 시 실행되는 함수로 api 연동이나 validation check 로직을 정의했다.

gantt.attachEvent("onLightboxSave", function(id, task, is_new){
    //any custom logic here
    return true;
})

 gantt.templates.lightbox_header = function (start: Date, end: Date, task: GanttTask) {
                let headerName;
                if (currentLevelRef.current === 1) {
                    if (task.text !== "새 일감") {
                        headerName = "일감 수정";
                    } else {
                        headerName = "일감 등록";
                    }
                }
                return headerName;
            };

8️⃣ timeline 영역 헤더 커스텀

  // timeline 헤더 설정
            gantt.config.scales = [
                {
                    unit: "day",
                    step: 1,
                    format: function (date: Date) {
                        const monthNames = ["01", "02", "03", "04", "05", "06", "07", "08", "09", "10", "11", "12"];
                        const day = date.getDate();
                        const month = date.getMonth();
                        const dayString = day < 10 ? `0${day}` : day;
                        return `${monthNames[month]}.${dayString}`;
                    },
                },
            ];

기본 timeline 헤더 커스텀한 timeline 헤더

9️⃣ 레벨에 따라 일감을 스타일링하고 싶을 때

 gantt.templates.task_class = function (start: Date, end: Date, task: GanttTask) {
                // 최상위 일감
                if (!task.parent) {
                    return "highlight-parent-task";
                }

                // 하위 일감
                const parentTask = gantt.getTask(task.parent);
                if (parentTask) {
                    return "highlight-child-task";
                }
                return "";
            };

클래스를 다르게 주어

부모일감과 하위일감의 색을 커스텀할 수 있다.

🔟 onLightboxDelete

lightbox에서 삭제 버튼을 클릭했을때 실행되는 함수이다. true를 return하면 정상정으로 삭제를 진행, false를 return하면 삭제가 진행되지 않는다.

gantt.attachEvent("onLightboxDelete", function(id){
    const task = gantt.getTask(id);
    if (task.duration > 60){
        alert("The duration is too long. Please, try again");
        return false;
    }
    return true;
})

1️⃣1️⃣ onAfterTaskUpdate

일감이 수정된 후 실행되는 함수

gantt.attachEvent("onAfterTaskUpdate", function(id,task){
    //any custom logic here
});

1️⃣2️⃣ 드래그 관련 함수

onTaskDrag : 드래그할 때 실행되는 함수

gantt.attachEvent("onTaskDrag", function(id, mode, task, original){
  //any custom logic here
});

onAfterTaskDrag : 드래그 완료 후 실행되는 함수

gantt.attachEvent("onAfterTaskDrag", function(id, mode, e){
  //any custom logic here
});

onBeforeTaskDrag : autoScehduling을 직접 구현하다보니 최상위 일감의 드래그를 막는 로직이 추가로 필요했다.(최상위 일감은 하위 일감들의 일정에 따라 계산되는 일정) 일정을 드래그하여 조정하기 전 최상위 일감인지 먼저 판단 후 최상위면 false를 return하여 드래그를 방지했다.

    gantt.attachEvent("onBeforeTaskDrag", function (id: string, mode: string, e: MouseEvent) {
                const task = gantt.getTask(id);

                // 부모 Task 드래그 방지
                if (task.type === "project" || gantt.hasChild(id)) {
                    return false;
                }

                return true;
            });

➕ 이 외에도 다양한 커스텀 가능한 이벤트들이 정의되어 있고 설명과 예시도 문서화로 잘 구성되어 있어서 다음에도 간트 차트를 구현한다면 dhtmlx 라이브러리를 사용할 것 같다. 🧷 이벤트 문서

AES 암호화를 활용한 익명 투표

Sat, 22 Mar 2025 06:54:43 GMT

프로젝트의 기능 중 하나인 투표를 담당하면서 db에서 추적되지 않는 익명투표를 위해 암호화에 대해 공부하며 기록을 남기게 되었다.

전체적인 프로세스는 다음과 같다. 1️⃣ 투표를 익명으로 생성 시 db에서 추적이 불가능하게 하기 위해 먼저 사용자 id를 해시하고 2️⃣ 이 값의 일부로 고유한 AES키를 생성해 서버에 전달한다. 3️⃣ 이를 해당 투표의 고유 id로 정의하고 4️⃣ 사용자가 투표 답변, 수정, 삭제 시 동일한 방법으로 서버에 고유한 키를 보내면 5️⃣ 서버에 저장되어 있던 암호화된 투표 고유 id와 비교해 자신이 생성한 투표인지 아닌지를 판단할 수 있게 하였다.

따라서 사용자의 원래 id를 서버에 전달하지 않고 db에는 사용자를 식별할 수 있는 정보가 없으므로 익명성이 보장된다.

코드를 살펴보자면

import forge from "node-forge";

function getSignature(publicKey: string, content: string): string {
  const md = forge.md.sha256.create();
  md.update(publicKey);
  const key = md.digest().getBytes(16); // AES-128 사용

먼저 사용자 ID를 해시하여 AES 키를 생성하고

  const iv = "0000000000000000";

동일키에 동일 암호문이 나와야 하기 때문에 IV (초기화 벡터)를 고정시킨다.

const cipher = forge.cipher.createCipher("AES-CBC", key);
cipher.start({ iv: iv });
cipher.update(forge.util.createBuffer(content));
cipher.finish();

const encrypted = cipher.output.getBytes();

forge 라이브러리를 사용하여 AES-CBC 암호화 객체를 생성하고 위에서 만든 AES 키를 설정한다. 이 후 암호화된 데이터를 바이트 배열로 변환하여 저장한다.

 return forge.util.encode64(encrypted);

최종으로 IV와 암호화된 데이터를 Base64로 인코딩하여 반환하는 함수를 만들었다.

이후 테스트를 진행하였는데 url로 이 키를 전달할 시 기호(?*^% 등)가 빈 문자열로 들어가는 이슈로 인해 투표를 생성한 사람과 동일함에도 매칭이 안되는 문제가 생겼다.

url-safe 문자열로 변환하기 위해 encodURIComponent로 한번 감싸서 보내 해결할 수 있었다.

 return encodeURIComponent(forge.util.encode64(encrypted));

➕ 추가로 알게 된 것 ➕

AES는 대칭 키 암호화 방식으로 고정된 키와 초기화 벡터(IV)를 사용해 데이터를 암호화한다.

여기서 대칭키 암호 알고리즘과 비대칭키 암호 알고리즘을 비교하며 좀 더 알아보자면 다음과 같은 특징이 있다.

✔️ 대칭키 암호 알고리즘

하나의 키로 암호화/복호화를 모두 수행하는 알고리즘
암호화하는 암호키와 복호화하는 해독키가 같다.
따라서 이 키는 절대 외부에 노출되면 안되고 해당 키를 Secret Key라고 부른다.
프론트엔드와 백엔드 간의 동일한 키를 공유해야하기 때문에 키 관리에 대한 어려움이 있고, 잦은 키 변경이 있는 경우에는 불편함을 초래할 가능성이 있다.
비대칭키 암호 알고리즘보다 속도가 빠르다.
키가 노출되면 암호화된 데이터를 복호화할 수 있다는 취약성이 있다.

✔️ 비대칭키 암호 알고리즘

- 암호화/복호화 시의 키가 서로 다른 키를 의미한다.

공개키와 개인키를 사용한다.
한 쌍의 키가 존재하며 하나는 특정 사람만이 가지는 개인키이며 하나는 누구나 가질 수 있는 공개키이다.
예를들어 공개키로 암호화한 데이터는 개인키로만 복호화할 수 있고 반대로 개인키로 암호화한 데이터는 공개키로만 복호화할 수 있다.
누군가 공개키를 가로채더라도 개인키를 모르기 때문에 데이터를 온전히 복호화할 수 없다.
주로 키 교환이나 인증에 사용한다.
대칭키 암호 알고리즘에 비해 느리다.

참고

간트차트 빌드 에러

Mon, 17 Mar 2025 23:23:58 GMT

💥 에러 발생

처음 간트차트를 구현할 때 다른 라이브러리들 처럼 상단에 import를 해서 useEffect 내에서 초기화 후 렌더링하는 방식으로 로직을 짰다.

const GanttChart: React.FC = () => {
    const ganttContainer = useRef(null);

 useEffect(() => {
        // Gantt 초기화
        if (ganttContainer.current) {

        ...

        gantt.init(ganttContainer.current);

          return () => {
          gantt.clearAll();
       };
    }
}, []);

return (

로컬에서는 문제가 없었는데 빌드를 하니 다음과 같은 에러가 발생하였다.

❓ 에러 원인

해당 프로젝트는 Next 프레임워크를 사용하고 있다.

dhtmlx-gantt는 DOM을 직접 조작하는 라이브러리이고 Next는 서버사이드 렌더링(SSR)을 수행하므로 DOM이 없는 서버에서 dhtmlx-gantt를 실행하려고 했던 것이 원인이었다.

❗에러 해결

1️⃣ useEffect와 typeof window를 사용하여 클라이언트 환경에서만 실행되도록 한다. 2️⃣ Next는 import 구문을 SSR 단계에서 처리하므로 클라이언트 환경에서 동적으로 로드하기 위해 required를 사용한다.

최종 코드

import React, { useEffect, useRef } from "react";
import "dhtmlx-gantt/codebase/dhtmlxgantt.css";

const GanttChart: React.FC = () => {
    const ganttContainer = useRef(null);

    useEffect(() => {
        if (typeof window !== "undefined" && ganttContainer.current) {
            const gantt = require("dhtmlx-gantt");
            if (ganttContainer.current) {
                gantt.init(ganttContainer.current);
                gantt.parse({
                    data: [
                        { id: 1, text: "Task #1", start_date: "01-04-2023", duration: 5, progress: 0.6 },
                        { id: 2, text: "Task #2", start_date: "06-04-2023", duration: 3, progress: 0.4, parent: 1 },
                    ],
                });
            }
        }
    }, []);

    return ;
};

export default GanttChart;

수정 후 다시 시도하니 빌드가 자알 된다!😊

비전공자 개발자의 CS 공부기록(1)

Mon, 17 Feb 2025 01:10:31 GMT

클라이언트 기반 데이터 저장 방식

📌 쿠키

사용자의 브라우저에 저장되는 작은 데이터 조각으로 필요할 때 쉽게 데이터를 받아 사용 가능하다.
만료 기간이 정해져 있지 않은 쿠키인 세션 쿠키(Session cookie)와 만료 기간이 존재하는 영구 쿠키(persistent cookie)가 있다. (위 사진에서 theme 세션이 세션 쿠키, refresh_token이 영구 쿠키에 해당한다.)
세션 쿠키는 브라우저가 종료될 때 함께 사라지는 반면, 영구 쿠키는 만료기간이 끝나면 삭제된다.
동작 1️⃣ 클라이언트가 서버에 웹 페이지를 요청하면 서버는 요청에 대한 응답과 함께 쿠키정보를 전송한다. 2️⃣ 응답을 받은 클라이언트는 메시지 안에 있던 쿠키 정보를 브라우저 공간에 저장한다. 3️⃣ 이후부터 클라이언트에서 서버로 보내는 모든 요청에 쿠키 정보를 담아 전달한다. 4️⃣ 서버는 이러한 요청 메시지의 쿠키 정보를 확인해 사용자를 식별하거나 적절한 데이터를 보내준다.
단점
- 누구나 쉽게 접근이 가능하고 조작할 수 있기 때문에 탈취되거나 변조될 위험이 크다.
- 요청마다 메시지에 쿠키 정보가 함께 전송되기 때문에 오가는 데이터의 양도 더 커져 웹 통신의 성능이 떨어지는 원인이 될 수 있다.
- 사용자가 방문한 웹 사이트에서 직접 발행하는 퍼스트 파티 쿠키와 제삼자가 발행한 서드 파티 쿠키로 구분할 수 있다.
- 서드파티 쿠키는 사용자로부터 충분한 동의를 받지 않고 웹 브라우징 활동을 추적해 표적 광고에 이용하기 때문에 개인 정보 침해의 소지가 있다.
- 개인 정보와 같은 민감한 데이터보다는 팝업 다시 보지 않기, 다크 모드 여부 등의 용도로 쿠키를 사용할 수 있다.

📌 로컬 스토리지 vs 세션 스토리지

로컬 스토리지
- 한 번 브라우저에 저장되면 의도적으로 삭제하지 않는 이상 데이터가 유지된다.
- 자동 로그인 등의 용도로 사용할 수 있다.
세션 스토리지
- 브라우저 탭이 닫힐 때 데이터도 함께 삭제된다.
- 일회성 정보의 데이터 저장 용도로 활용할 수 있다.

📌 쿠키와 웹 스토리지 비교

쿠키	웹 스토리지
4KB까지 저장이 가능하다.	5MB ~ 10MB까지 저장이 가능하다.
클라이언트와 서버 양쪽 모두 값에 접근 가능하다.	클라이언트 단에서만 접근 가능하다.
HTTP 헤더에 담겨 서버로 전송된다.	따로 서버 전송을 하지 않기 때문에 네트워크 통신량이 줄어든다.

📌 Index DB

데이터의 형태가 문자열로 한정된 쿠키나 웹 스토리지에 반해, Key Value 한 쌍을 저장하며 , File/Blob 포함 다양한 자바스크립트 데이터 타입 지원한다.
용량 제한이 특별히 없다.
복잡한 구조의 데이터나 큰 규모의 데이터를 괸리해야할 때 유용하게 사용할 수 있다.
same origin policy 를 따르며 온라인/오프라인 환경 모두에서 쿼리 지원한다.

서버 기반 데이터 저장 방식

📌 세션

정보를 서버에서 관리하기 때문에 보안이 우수하다.
클라이언트별로 고유 ID를 부여해 관리하기 때문에 각 클라이언트의 요구에 맞는 맞춤형 서비스를 제공할 수 있다.
사용자가 많아지거나 관리해야 하는 데이터의 양이 많아지면 서버의 부담이 커진다는 단점이 있다.
브라우저에서 값을 보여주는 것보다 상대적으로 데이터 제공 속도가 느릴 수 있다.
동작 1️⃣ 로그인한 사용자의 정보를 서버에 전달한다. 2️⃣ 서버는 요청을 보낸 클라이언트가 이전에 접근한 적이 있는지 확인하고 없다면 고유한 값인 세션 ID를 발급해 자신의 메모리에 저장하고 요청에 대한 응답과 함께 세션 ID를 클라이언트에 전달한다. 3️⃣ 클라이언트는 전달받은 세션 ID를 쿠키에 저장한다. 4️⃣ 가령 사용자가 장바구니 api를 요청하면 클라이언트는 요청과 함께 쿠키 안의 세션ID를 함께 전달한다. 5️⃣ 요청을 받은 서버는 메모리에서 자신이 받은 세션ID에 해당하는 클라이언트가 있는지 확인하고 있다면 장바구니 정보를 조회해 응답 데이터로 전송한다.

이미지 출처

엑셀 파일 업로드를 구현해보자

Sun, 02 Jun 2024 07:23:29 GMT

이번에 구현하게 된 기능은 엑셀 파일 업로드이다.

먼저 input을 정의해주고 onChange 함수 작성

const uploadedFileRefPut = useRef(null);

const handleFileChange = useCallback(async (event, fileRef) => {
    const selectedFile = event.target.files?.[0];

    if (selectedFile) {
       fileRef.current = selectedFile;
       const reader = new FileReader();
       reader.onload = async (e: ProgressEvent) => {
           if (e.target && e.target.result) {
              const data = new Uint8Array(e.target.result as ArrayBuffer);
              const workbook = XLSX.read(data, { type: "array", bookVBA: true });
              const worksheet = workbook.Sheets[workbook.SheetNames[0]];
              const jsonData: ExcelData[] = XLSX.utils.sheet_to_json(worksheet);
          }
      };

        reader.readAsArrayBuffer(selectedFile);
   }
}, []);

버튼 클릭 시 업로드를 수행 할 함수 작성

// 엑셀 파일로 일괄 수정
    const handlePutExcel = (e: React.FormEvent) => {
        e.preventDefault();

        if (!uploadedFileRefPut.current) {
            toast.error("엑셀 파일을 업로드 해주세요.");
            return;
        }

        const formData = new FormData();

        formData.append("file", uploadedFileRefPut.current);
        uploadUserExcelPut(formData);
    };

최종 구현된 코드는 위와 같지만 초기에 upload할 파일을 useState로 상태를 관리하고 있었다.

const [uploadedFile, setUploadedFile] = useState(null);

  const jsonData: ExcelData[] = XLSX.utils.sheet_to_json(worksheet);
  setUploadedFile(jsonData);
}

이렇게 onChange 됐을 때 setUploadedFile로 상태를 업데이트 해 주었음에도 업로드 버튼을 클릭하면 계속 엑셀 파일이 없다는 toast 에러가 뜨는 문제가 발생했다.

디버깅을 해보니 uploadedFile이 null로 찍히고 있었다... 왜 null이지? 나는 분명 setUploadedFile로 업데이트를 해주었는데...

한참 헤맨 끝에 찾은 원인은 uploadedFile이 클로저이기 때문이었다.

❔ 원인 엑셀 파일 업로드라는 버튼을 클릭하면 input이 있는 모달이 뜨는데 모달이 열린 시점에는 uploadedFile 상태를 클로저로 기억하고 있어서 상태가 업데이트된 이후에도 null 값을 유지하고 있었다.

두 가지의 해결 방법이 있다.

❕방법 1

uploadedFile 상태가 변경될 때마다 handleUpload 함수를 새로 정의하기 위해 useCallback으로 감싸고 의존성 배열에 uploadedFile을 추가하기

    const handleUpload = useCallback(async () => {
        if (!uploadedFile) {
            toast.error("엑셀 파일을 업로드 해주세요.");
            return;
        }

        const formData = new FormData();
        formData.append("file", uploadedFile);

        await uploadUserExcel(formData);
    }, [uploadedFile]);

❕방법 2

useRef를 사용하여 파일 상태를 저장하고 이를 참조하여 항상 최신 상태를 유지하는 방법

위의 최종 코드와 동일

두 방법 모두 상태가 변경될 때마다 handleUpload 함수가 최신 상태를 참조하게 되어 uploadedFile 상태의 동기화를 유지할 수 있게 된다!

나는 상태변경 이후 추가적인 UI의 변경이 없고 리렌더링이 필요하지 않았기 때문에 두 번째 방법으로 구현하기로 했다!

자바스크립트의 기본기가 중요하다는 것을 다시금 느끼게 된 과정이었다.

🧷 참고

Sortablejs를 이용한 Drag and Drop 구현

Sun, 02 Jun 2024 06:21:46 GMT

처음 구현하는 기능은 언제나 떨리고 조금 설렌다🤓

프론트엔드에서 흔하게 접할 수 있는 Drag and Drop 기능과 새로 정렬된 리스트의 순서를 서버에 바로 반영해 새로고침해도 정렬이 유지되는 기능 구현해보자!

내가 사용한 라이브러리는 react-sortablejs이다.

1️⃣ 설치

npm i react-sortablejs

2️⃣ Drag and Drop 구현

깃헙 공식 문서에 나와있는 기본형은 아래와 같다.

import React, { FC, useState } from "react";
import { ReactSortable } from "react-sortablejs";

interface ItemType {
  id: number;
  name: string;
}

export const BasicFunction: FC = (props) => {
  const [state, setState] = useState([
    { id: 1, name: "shrek" },
    { id: 2, name: "fiona" },
  ]);

  return (
    
      {state.map((item) => (
        {item.name}
      ))}
    
  );
};

오 생각보다 단순하다..!

import { ReactSortable } from "react-sortablejs";

const [list, setList] = useState(lists);

 ({ ...item, id: item.tid }))} setList={setList} className="flex list-none flex-col gap-[20px]" onEnd={handleDragEnd}>
            {list?.map((item, index) => (
                
            ))}

전체 리스트 목록을 ReactSortable 컴포넌트로 감싸고 필요한 속성 값을 지정해주면 끝!

다양한 옵션을 제공하는데 그 중 사용한 것에 대해 간략히 정리를 하자면

tag ReactSortable 컴포넌트가 어떤 HTML 태그나 컴포넌트로 렌더링될지를 지정하는 속성이다. 나는 TopicList가 li태그이기 때문에 ul로 지정해주었다.
animation 항목을 정렬할 때 이동하는 애니메이션의 속도를 밀리초(ms) 단위로 설정. 만약 animation={0}으로 설정하면 애니메이션 없이 즉시 이동된다.
list ReactSortable에서 사용할 항목 배열로 필수로 지정해주어야 하는 속성이다.
setList 항목 목록의 상태를 설정하는 함수로 정렬된 후의 새로운 상태를 받아 컴포넌트의 상태를 업데이트해준다. list와 마찬가지로 필수로 지정해주어야 한다.
onEnd onEnd?: ((evt: Sortable.SortableEvent, sortable: Sortable | null, store: Store) => void)

ReactSortable 컴포넌트에서 드래그 앤 드롭 작업이 끝났을 때 호출되는 콜백 함수를 지정하고자 할 때 사용하는 속성이다. 이 콜백 함수는 SortableEvent 객체를 매개변수로 받아 드래그된 항목과 그 위치 변경에 대한 정보를 제공한다.

나는 드래그가 끝나고 변경된 위치를 서버에 반영해 새로고침해도 정렬이 유지되도록 구현하고 싶었기 때문에 handleDragEnd라는 콜백 함수를 지정해주었다.

3️⃣ 정렬 구현

const handleDragEnd = (event) => {
    const updatedList = [...list];
    const movedItem = updatedList.splice(event.oldIndex, 1);
    updatedList.splice(event.newIndex, 0, movedItem);
    setList(updatedList);
};

SortableEvent 객체의 주요 속성은 다음과 같다.

item : 드래그된 DOM 요소
from : 드래그 시작 위치의 DOM 요소
to : 드롭된 위치의 DOM 요소
oldIndex : 드래그 시작 전의 요소 인덱스
newIndex : 드래그 후의 요소 인덱스
1. 먼저 리스트 배열의 복사본을 만들고
2. 복사본을 splice메소드를 사용해 oldIndex 속성으로 드래그 한 요소를 제거한다.
3. 복사본을 다시 splice 메소드로 드래그한 후 인덱스 위치에 제거한 요소를 삽입한 후 setList로 상태를 업데이트 해준다.

4️⃣ 최종

새로 정렬된 리스트를 서버에 반영하면 새로고침해도 정렬된 리스트가 유지된다!

🧷 참고

react-sortablejs

브라우저 렌더링 과정에 대해 알아보자

Thu, 07 Mar 2024 04:03:17 GMT

1. DOM 트리 빌드

이전 단계에서 통신을 통해 받아온 html 파일들은 바이트 형태로 전달된다. 바이트 > 문자 > 토큰 > 노드 > 객체 모델로 전환하는 작업이 수행되고 최종 트리 형태의 DOM이 출력된다. + 만약 html 파싱 중 link 태그나 style 태그를 만날 경우 블로킹되어 CSSOM 생성으로 넘어간다.

2. CSSOM 트리 빌드

css 파일도 html 파일과 마찬가지로 트리 형태의 객체 모델로 전환하는 과정을 거친다. css 파싱이 완료되면 html 파싱이 중단된 시점으로 돌아가 다시 html을 파싱한다.

3. Render Tree 생성

기존에 제작된 DOM과 CSSOM을 결합하여 Render Tree를 생성한다. + 화면에 렌더링되는 노드만으로 구성된다. (display : none이나 meta 태그 등은 렌더트리를 구성하지 않음)

4. JS 파싱 후 AST 생성

html 파싱 중 js 즉, script 태그를 만나게 되면 blocking되어 제어권을 JS엔진에게 넘겨주어 JS 파싱으로 넘어간다. 소스코드를 토큰으로 분해하고 파싱해 AST라는 추상적 구문 트리로 생성한 뒤 인터프리터가 읽을 수 있도록 바이트코드를 생성하여 실행한다.

이후 js 파싱과 실행이 종료되면 렌더링 엔진으로 다시 제어권이 넘어가 html 파싱이 중단된 시점부터 다시 시작하여 dom 생성을 재개한다.

5. Layout

Render Tree의 노드들의 위치와 크기를 계산하는 단계

6. Paint

계산된 값들을 기반으로 화면에 필요한 요소들을 실제로 그리는 작업을 실행한다.

7. Reflow & Repaint

아래 3가지의 경우와 같이 html 요소의 크기나 위치를 변경해야 하는 경우가 발생하면 렌더링 트리의 요소의 크기와 위치를 다시 계산하는 reflow 과정을 거쳐 다시 페인팅하는 repaint 가 발생한다. + 리렌더링 조건 1. 자바스크립트에 의한 노드 추가 또는 삭제 2. 브라우저 창 리사이징에 의한 뷰포트의 크기 변경 3. html 요소의 레이아웃에 변경을 발생시키는 width, height 등의 스타일 변경

++ Composition

레아아웃과 페인트를 수행하지 않고 레이어의 합성만 실행시키는 단계 Transform, opacity와 같은 요소들을 의미한다.

웹 브라우저에 해당 도메인 주소를 입력했을 때 데이터를 받아오는 과정

Wed, 06 Mar 2024 10:33:19 GMT

주소창에 url을 입력하면 DNS서버(domain name system의 약자로 도메인 이름과 IP 주소를 매핑해주는 서버)에 요청하기 전에 먼저 CDN에 캐싱된 dns 기록들을 확인한다.
- CDN : 콘텐츠 전송 네트워크로 여러 개의 서버를 이용해 웹 콘텐츠를 사용자와 가까운 서버에서 전송함으로써 전송 속도를 높인다는 장점을 가진다. AWS나 SK브로드밴드, KT 등의 예가 있다.
만약 캐싱된 기록이 있으면 요청을 보내지 않고 바로 ip 주소를 반환하고 없으면 dns 서버 요청으로 넘어간다.
가장 가까운 dns 서버에서 도메인 이름에 해당하는 IP 주소를 찾기 위해 dns query를 전달한다.
dns query는 현재 dns 서버에서 원하는 ip 주소가 존재하지 않으면 다른 dns 서버를 방문하는 과정을 원하는 IP 주소를 찾을 때까지 반복한다.
찾던 IP 주소를 전달 받으면 이 IP 주소를 이용하여 웹 브라우저는 웹 서버에게 해당 웹 사이트에 맞는 html 문서를 요청한다.
해당 HTTP 요청 메세지는 TCP/IP 프로토콜을 사용하여 서버로 전송된다.
전송 제어 프로토콜인 TCP는 데이터의 전송을 제어하고 데이터를 어떻게 보낼지 어떻게 맞출지? 정한다.
IP의 특징인 비신뢰성과 비연결성으로 인해 IP 프로토콜 만으로는 통신을 할 수 없기 때문에 신뢰성과 연결성을 책임지는 TCP를 활용하여 통신한다.
TCP는 3-웨이 핸드셰이크라는 작업을 진행하면서 연결 및 데이터를 수신받는다.
1. SYN단계 : 클라이언트는 서버에 클라이언트의 ISN을 담아 SYN을 보낸다.
2. SYN + ACK 단계 : 서버는 클라이언트의 SYN을 수신하고 서버의 ISN을 보내며 승인번호로 클라이언트의 ISN + 1을 보낸다.
3. ACK 단계 : 클라이언트는 서버의 ISN + 1한 값인 승인번호를 담아 ACK를 서버에 보낸다. 이렇게 3-웨이 핸드셰이킹 과정 이후 신뢰성이 구축되고 데이터 전송을 시작한다.
- SYN : SYNchronization의 약자, 연결 요청 플래그
  - ACK : Acknowledgement의 약자, 응답 플래그
  - ISN : Initial Sequence Numbers의 약자로 초기 네트워크 연결을 할 때 할당된 32비트의 고유 시퀀스 번호
4-웨이 핸드셰이크라는 과정을 통해 연결을 종료한다.
1. 클라이언트가 연결을 닫으려고 할 때 FIN으로 설정된 세그먼트를 보낸다.
2. 서버는 클라이언트로 ACK라는 승인 세그먼트를 보내고 자신의 통신이 끝날 때까지 기다린다.
3. 서버는 일정 시간 이후 클라이언트에 FIN이라는 세그먼트를 보낸다.
4. 클라이언트는 확인했다는 메세지인 ACK를 보내고 서버는 CLOSED 상태가 된다. 이후 클라이언트는 어느 정도의 시간을 대기한 후 연결이 닫히고 클라이언트와 서버의 모든 자원의 연결이 해제된다.
특정 데이터 요청을 브라우저로부터 받게되면 웹 서버는 페이지의 로직이나 데이터베이스 연동을 위해 WAS에게 이들의 처리를 요청한다. 웹 서버의 과부하 방지를 위한 WAS(사용자의 컴퓨터나 장치에 웹 어플리케이션을 수행해주는 미들웨어)는 해당 요청을 통해 동적인 페이지 처리를 담당하고 DB에서 필요한 데이터 정보를 받아 그에 맞는 파일을 생성한다.

웹 서버 : 정적인 파일(HTML, CSS, 이미지 파일)을 처리 WAS : 동적인 파일(JS, TS)을 처리
WAS에서의 작업 처리 결과들을 웹 서버로 전송하고, 웹 서버는 웹 브라우저에게 html 문서 결과를 전달한다. 전달 과정에서 status code를 통해 서버 요청에 따른 결과 및 상태를 전달한다.

1xx : 정보가 담긴 메세지
2xx : response 성공
3xx : 클라이언트를 다른 URL로 리다이렉트
4xx : 클라이언트 측에서 에러 발생
5xx : 서버 측에서 에러 발생

💡

requestAnimationFrame을 사용해 ProgressBar 만들기

Thu, 18 Jan 2024 14:31:25 GMT

⚒️ setInterval과 requestAnimationFrame

첫 번째, 두 번째 막대는 각각 setInterval과 requestAnimationFrame을 이용해서 너비값을 증가시키는 애니메이션이다.

setInterval을 이용한 막대 그래프는 requestAnimationFrame을 이용한 막대 그래프에 비해 일정한 간격으로 실행이 되지 않고 프레임이 유연하지 못한 것을 확인할 수 있다.

setInterval을 사용한 애니메이션

const startInterval = () => {
  const interval = document.querySelector('#interval') as HTMLDivElement;

  const id = setInterval(() => {
    interval.style.width = `${intervalWidth}px`;
    intervalWidth += 1;

    if (intervalWidth > window.innerWidth) clearInterval(id);
  }, 1000 / 60);
};

requestAnimationFrame을 사용한 애니메이션

const startAnimationFrame = () => {
  const animationFrame = document.querySelector(
    '#animationFrame'
  ) as HTMLDivElement;

  animationFrame.style.width = `${requestWidth}px`;
  requestWidth += 1;
  const id = requestAnimationFrame(startAnimationFrame);
  if (requestWidth > window.innerWidth) cancelAnimationFrame(id);
};

이렇게 다르게 동작하는 이유는 setInterval로 width를 자주 변경하게 되면 자바스크립트가 실행되는 동안(브라우저에서 다른 작업이 처리되는 동안) 레이아웃 변경이 지정된 간격보다 더 늦게 또는 더 빠르게 실행될 수 있다. 즉 간격이 일정하지 못하게 되고 실제 화면에 렌더링 되는 프레임의 수가 줄어드는 frame drop 현상으로 이어지게 된다. 이로인해 버벅이는 듯한 애니메이션으로 이어지게 되는 것이다.

반면 requestAnimationFrame은 브라우저의 렌더링 주기와 동기화 돼서 실행이된다. requestAnimationFrame 콜백에 DOM을 변경하는 함수를 넣어주면 해당 변경은 브라우저의 렌더링 주기에 최적화된 방식으로 반영이 되기 때문에 setInterval보다 requestAnimation을 사용할 때 더 유연한 애니메이션을 제공할 수 있게된다.

✔️ requsetAnimationFrame으로 scroll에 따른 progessBar 구현하기

비용이 많이 드는 레이아웃 변경 대신 transform의 scaleX로 progressBar의 너비값이 변하도록 적용했다.

전체 코드

function ScrollProgressBar() {
  const [progess, setProgress] = useState(0);
  const rafRef = useRef(null);

  useEffect(() => {
      const scroll = () => { 
          const scrollTop = document.documentElement.scrollTop
          // 문서 전체 높이 - 뷰포트 높이 값
          const height = document.documentElement.scrollHeight - document.documentElement.clientHeight

          // 중복된 작업이 반복적으로 일어나지 않도록 방지코드
          if (rafRef.current) {
              cancelAnimationFrame(rafRef.current)    
          }

          rafRef.current = requestAnimationFrame(() => {
              setProgress(scrollTop / height)
          })
      }

      window.addEventListener('scroll', scroll)

      return () => {
          if (rafRef.current) {
              cancelAnimationFrame(rafRef.current)    
          }

          window.removeEventListener('scroll', scroll)
      }
  },[])
  return (
      

      
  )
}

💡

참고

프로젝트를 최적화하는 다양한 방법 - lazy loading

Wed, 17 Jan 2024 08:54:00 GMT

✔️ 코드 스플리팅(Code-Splitting)

: 커다란 번들을 작은 여러개의 청크로 나누는 과정으로 코드 스플리팅을 통해 유저가 필요하지 않은 코드들을 다운 받지 않도록 할 수 있다.

➕ 코드 스플리팅 적용 시 이점

: 어플리케이션 규모가 커질수록 번들 사이즈는 증가하게 되고 초기 로딩 속도가 증가할수 밖에 없다. 이때 코드 스플리팅을 적용하면 현재 필요한 코드만 다운 받을 수 있게 되어 첫 페이지 랜딩 속도를 더 빠르게 향상시켜 사용자 경험을 향상시킬 수 있다.

<공식 문서> 앱의 코드 양을 줄이지 않고도 사용자가 필요하지 않은 코드를 불러오지 않게 하며 앱의 초기화 로딩에 필요한 비용을 줄여줍니다.

➕ React.lazy 적용하기

1️⃣ import 하기

import {lazy, Suspense} from "react"

2️⃣ const 컴포넌트명(변수명) = lazy(() => import('@componenets/auth/PrivateRoute'))

const OtherComponent = React.lazy(() => import('./OtherComponent'));

3️⃣ Suspense로 컴포넌트들 감싸주기

: lazy 컴포넌트는 Suspense 컴포넌트 하위에서 렌더링되어야 한다.

     Loading...}>

4️⃣ fallback 옵션 지정하기

: Suspense는 컴포넌트가 lazy loading되는 동안 보여줄 ui를 만드는 fallback props를 제공한다.

import React, { Suspense } from 'react';

const OtherComponent = React.lazy(() => import('./OtherComponent'));

function MyComponent() {
  return (
    
      Loading...}>
        
      
    
  );
}

5️⃣ 프로젝트에 적용해보기

lazy 적용 전 유저가 첫 페이지를 만나기까지 걸리는 시간 > 1.27s

lazy 적용 후 유저가 첫 페이지를 만나기까지 걸리는 시간 > 407.17ms

대략 0.87s가 더 빨라진 것을 확인할 수 있다!!

💡

Next를 Next 답게 사용하는 방법

Wed, 10 Jan 2024 11:28:41 GMT

✔️ Image 컴포넌트 사용

lazy loading : 이미지 로드하는 시점을 지연시키는 기능을 제공한다. 따라서 스크린 밖에 있는 이미지들은 로딩을 지연시키고 스크린 안에 있는 이미지만을 로드해 불필요한 대역폭 사용을 줄이고 필요한 이미지만 빠르게 로드할 수 있도록 최적화 할 수 있다. (우선적으로 로딩 시키고 싶다면 priority 속성을 추가하면 된다!)
*이미지 사이즈 최적화 *
- 사용자의 디바이스에 맞는 이미지 사이즈를 만들어 다운로드 할 수 있게 제공
- webp와 같은 용량이 작은 포맷으로 변환하여 제공(이미지에 대한 최초 요청 시에 Next.js 서버에서 진행)
- 이후 요청에는 캐시가 만료될 때까지 캐시 된 이미지가 제공되기 때문에 첫 번째 요청보다 훨씬 빠르게 이미지를 보여줄 수 있게 된다.
*placeholder 제공 *: 레이아웃이 흔들리는 현상을 방지하기 위해 placeholder를 제공 해 이미지가 로드되기 전에도 이미지 높이만큼 영역을 표시해서 이미지가 로드된 후에 레이아웃이 흔들리지 않도록 할 수 있다.

import logoImg from '@/assets/logo.png'

export default function Header() {
    return(

                ▽ ▽ ▽ ▽ ▽ ▽ ▽

import logoImg from '@/assets/logo.png'
import Image from "next/image";

export default function Header() {
    return(

Network/Headers/Content-Type에서 확인 가능

💡

참고

전역 상태 관리 라이브러리인 Recoil에 대해 알아보자

Wed, 03 Jan 2024 05:07:20 GMT

❓Recoil 이란?

React 애플리케이션 상태 관리를 위한 라이브러리
Facebook에서 개발한 상태 관리 라이브러리로 atom 이라는 단위로 상태를 정의하고 이를 이용해 컴포넌트 사이에서 데이터를 공유하며 상태를 업데이트한다.

❗Recoil 사용시 장점

간편한 상태관리: 간편하게 상태를 정의하고 관리할 수 있다.
최적화된 리렌더링: 내부적으로 최적화되어 있기 때문에 필요한 경우에만 리렌더링된다.

서로 다른 selector가 같은 atom을 참조하고 setter의 결과로 원본 atom에 변화가 있더라도, 또다른 selector가 참조하고 있는 필드가 변경되지 않았다면 recoil이 이를 판단해서 영리하게 리렌더링을 일으키지 않는다.
복잡한 애플리케이션에 적합: 복잡한 상태 관리를 효과적으로 다루는데 적합하다.

📌 Atom과 Selector

Atom

: 앱의 상태를 정의하는 단위로 atom 함수를 통해 생성한다. atom의 값을 읽는 컴포넌트들은 암묵적으로 atom을 구독하기 때문에 atom에 어떤 변화가 있으면 그 atom을 구독하는 모든 컴포넌트가 재 렌더링 되는 결과가 발생한다.

기본형

function atom({
    key: string, // 내부적으로 atom을 식별하는데 사용되는 고유한 문자열
    default: T | Promise | RecoilValue, // atom의 초깃값 또는 Promise 또는 동일한 타입의 값을 나타내는 다른 atom이나 selector
}): RecoilState

ex)

import { atom } from "recoil";

const userState = atom({
    key : 'userState',
    default : null,
})

Selector

: 상태 변화를 만들어 내는 함수로 다른 atom이나 selector로부터 값을 계산한다.

기본형

  function selector({
    key: string, // 내부적으로 atom을 식별하는데 사용되는 고유한 문자열
    get: ({
      get: GetRecoilValue // selector는 읽기만 가능한 상태를 반환한다.
    }) => T | Promise | RecoilValue,
    set?: ( // selector는 쓰기 가능한 상태를 반환한다.
      {
        get: GetRecoilValue,
        set: SetRecoilState,
        reset: ResetRecoilState,
      },
      newValue: T | DefaultValue,
    ) => void,
  })

ex)

import { selector } from "recoil";

const userNameState = selector({
    key : 'userNameState',
    get : ({get}) => {
        const user = get(userState);
        return user ? user.name : 'Guest';
    }
})

📌 Recoil에서 자주 사용하는 Hook

useRecoilState(state)
- Atom 값을 읽고 업데이트하는데 사용되는 훅으로 useState과 비슷한 구조이지만 전역 상태를 다룬다는 점에서 차이가 있다. 상태가 업데이트 되었을 때 리렌더링을 하도록 컴포넌트를 구독한다.
```
import {atom, useRecoilState, RecoilRoot} from "recoil";
```
const countState = atom({
```
key : 'countState',
default : 0,
```
});

function Counter() {
```
const [count, setCount] = useRecoilState(countState);

return(
    
        Count : {count} 
        
        
     
);
```
}

useRecoilValue(state)

단순히 Atom 값을 읽는데에 사용되며 상태 업데이트를 트리거하지 않는다.
```
import {selector, useRecoilValue, RecoilRoot} from 'recoil';
```

const userNameState = selector({

key : 'userNameState',
get : ({get}) => {
    const user = get(userState);
    return user ? user.name : 'Guest';
},

});

function UserInfo() {

const userName = useRecoilValue(userNameState);

return Welcome, {userName}!

}

useSetRecoilState(state)

Atom 값을 업데이트하는 setter 함수를 반환한다.

import {atom, useSetRecoilState, RecoilRoot} from 'recoil';

const countState = atom({
    key : 'countState',
    default : 0,
});

function Counter() {
    const setCount = useSetRecoilState(countState);

    return(
        
            
        
    );
}

useResetRecoilState

Atom 값을 초기값으로 리셋하는 함수를 반환한다.
```
import {atom, useResetRecoilState, RecoilRoot} from 'recoil';
```

const countState = atom({

key : 'countState',
default : 0,

});

function ResetButton() {

const resetCount = useResetRecoilState(countState);

return(
    
        
    
);

}

📌 그렇다면 프로젝트에 적용해보자!

1️⃣ 설치

npm install recoil
yarn add recoil

2️⃣ RecoilRoot로 컴포넌트 감싸기

export const NextProvider = ({ children }: Props) => {
  return (
    
      
        ...
      
    
  );
};

3️⃣ 지도 전역 상태 설계

: 기존 Map, Marker에 전달하던 상태 및 상태 관리 함수는 모두 삭제 후 전역으로 상태 관리하도록 적용

• mapState : 지도의 기본 상태를 저장 • currentStoreState : 현재 선택한 맛집 상태를 저장 • locationState : 현재 위치 및 zoom 상태를 저장

Atom 값 설계
```
// atom/index
```

export const mapState = atom({ key: "map", default: null, dangerouslyAllowMutability: true, });

export const currentStoreState = atom({ key: "store", default: null, });

export const locationState = atom({ key: "location", default: { lat: DEFAULT_LAT, lng: DEFAULT_LNG, zoom: DEFAULT_ZOOM, }, });


- #### Map 컴포넌트에 적용

// components/map export default function Map({ lat, lng, zoom }: MapProps) { const setMap = useSetRecoilState(mapState); const location = useRecoilValue(locationState);

- #### Marker 컴포넌트에 적용

export default function Marker({ store }: MarkerProps) { const map = useRecoilValue(mapState);


- #### Markers 컴포넌트에 적용

// components/markers export default function Markers({ stores }: MarkerProps) { const map = useRecoilValue(mapState); const setCurrentStore = useSetRecoilState(currentStoreState); const [location, setLocation] = useRecoilState(locationState);





### 4️⃣ 검색 기능 전역 상태 설계
: 기존 SearchFilter에 전달하던 상태 및 상태 관리 함수는 모두 삭제 후 전역으로 상태 관리하도록 적용

> searchState : 검색 상태를 저장

- ####  Atom 값 설계

// atom/index

export const searchState = atom({ key: "search", default: null, });


- ####  SearchFilter 컴포넌트에 적용

export default function SearchFilter() { const [search, setSearch] = useRecoilState(searchState);

return ( ... setSearch({ ...search, q: e.target.value })} ... />

ssooo_kk_77.log

AI 도구 링크 모음

1. AI 에이전트 / 업무 자동화

Hermes Agent

Ennoia

Google Opal

2. AI 개발 방식 / 하네스 엔지니어링

하네스 엔지니어링

3. 프롬프트 / 디자인 참고 도구

Claude Prompts KR

getDesign.md

4. AI 기반 웹사이트 생성 도구

Readdy

GraphRAG, Knowledge Graph, Ontology의 차이점

GraphRAG, Knowledge Graph, Ontology는 뭐가 다를까?

Ontology는 설계도에 가깝다

Knowledge Graph는 실제 데이터가 들어간 결과물

지하철 노선도로 생각하면 이해가 쉽다

Ontology

Knowledge Graph

GraphRAG

GraphRAG는 그래프를 활용한 RAG

실제 프로젝트에서는?

마무리

Next.js에서 PWA로 오프라인 입력 데이터를 저장하고 재전송하기

PWA(Progressive Web App)

🧩 PWA를 구성하는 기본 요소

🗂️ Cache Storage와 IndexedDB의 역할 나누기

⚙️ Next.js에 PWA 적용하기

🧱 App Shell 방식으로 오프라인 화면 유지하기

App Shell

🧠 runtimeCaching 설정하기

📝 Manifest 설정하기

🔍 빌드 후 Service Worker 확인하기

💾 오프라인 입력 데이터 저장하기

✅ 적용하면서 느낀 점

OpenLayers Overlay와 iframe 레이어 문제

📌 문제 상황

❗ 핵심 원인

기존 Overlay 구현 코드

🔄 시도했던 방법 — Teleport

Teleport란?

👉 Teleport의 한계

✅ 해결 방법

✅ 정리

HLS와 WebRTC

HLS와 WebRTC, 실시간 CCTV 위젯에서는 무엇을 선택해야 할까?

HLS란?

WebRTC란?

HLS와 WebRTC 비교

CCTV 위젯에서는 왜 HLS를 사용했을까?

실무에서 선택할 때 보는 기준

1️⃣ 지연시간이 얼마나 중요한가?

2️⃣ 양방향 통신이 필요한가?

3️⃣ 같은 영상을 얼마나 많은 사용자가 보는가?

4️⃣ 운영 복잡도

비전공자 개발자의 CS 공부기록(2)

📌 웹 애플리케이션 아키텍처의 구조와 역할

📌 HTTP란?

특징

📌 HTTPS란?

DHTMX 간트차트 구현기

1️⃣ 커스텀 스크롤

2️⃣ locale ko로 수정

3️⃣ date 순서 변경

4️⃣ onBeforeLightbox

5️⃣ onLightbox

6️⃣ onLightboxSave

7️⃣ lightbox header name 설정

8️⃣ timeline 영역 헤더 커스텀

9️⃣ 레벨에 따라 일감을 스타일링하고 싶을 때

🔟 onLightboxDelete

1️⃣1️⃣ onAfterTaskUpdate

1️⃣2️⃣ 드래그 관련 함수

AES 암호화를 활용한 익명 투표

간트차트 빌드 에러

💥 에러 발생

❓ 에러 원인

❗에러 해결

비전공자 개발자의 CS 공부기록(1)