나의 발자취

브라우저 작동 원리에 따른 앱 성능 최적화 (Web Browser Engineering)

달모드 — Tue, 3 Mar 2026 20:43:18 +0900

일단 기본적으로 브라우저 작동 원리를 생각해보면,

일단 브라우저는 HTML 문서를 받으면 파싱 처리를 진행한다.
파서는 받은 문서를 읽어서 DOM(Document Object Model) 트리를 생성한다. (DOM은 문서의 구조를 나타낸다.) 이 때 CSS를 처리해 CSSOM(CSS Object Model)을 만든다.
브라우저는 이 DOM 트리를 사용해 콘텐츠를 렌더링한다. (렌더링의 두 가지 주요 단계는 layout, paint이다.)
렌더링 1) 레이아웃: 브라우저는 CSS에 정의된 스타일과 레이아웃 규칙을 기반으로 각 요소의 크기와 위치를 계산한다.
렌더링 2) 페인트: 브라우저가 각 요소를 화면에 그린다.

이제 여기서, 앱의 성격을 이해하고 이 과정에다가 적용해야한다. 예를 들어 페이지 안에 수많은 요소들이 있다면, 브라우저는 레이아웃을 계산하는 데에 많은 시간을 소요하게 되고, 여기가 병목 지점이 된다. => 페이지의 요소 수를 최소화하거나, CSS grid를 사용하거나, Flexbox를 사용해서 레이아웃을 단순화시키는 것이 성능을 개선하는 방법이 된다.

자, 이제까지는 렌더링에 관한 성능 개선 방법이었는데 이번에는 '로딩'에 초점을 맞춰서 생각해보면

다시 위의 순서로 돌아가서, 브라우저가 HTML 문서를 받게 되는 1번 순서를 보자. 여기서, HTML문서를 받는다는 것은 문서에 참조된 리소스도 로딩한다는 것이다. 여기서 로딩할 게 많으면( 이미지, 스타일시트, 스크립트 등의 리소스) 여기가 병목이 된다. => lazy loading, prefetching, preloading 같은 resource hint를 사용. Chrome DevTools Performance tab - summary를 활용

Chrome 개발 블로그를 참고하면 매우 많은 도움이 된다.

출처:

https://developer.chrome.com/blog/inside-browser-part1

최신 웹브라우저 들여다보기 (1부) | Blog | Chrome for Developers

브라우저가 코드를 개략적인 아키텍처에서 구체적인 렌더링 파이프라인에 이르기까지 제대로 작동하는 웹사이트로 변환하는 방법을 알아보세요.

developer.chrome.com

https://web.dev/articles/critical-rendering-path/constructing-the-object-model

객체 모델 구성 | Articles | web.dev

브라우저가 DOM 및 CSSOM 트리를 구성하는 방법을 알아봅니다.

web.dev

React App 확장성을 위해 점검해 볼것

달모드 — Tue, 3 Mar 2026 20:17:53 +0900

GA4 필요한 어트리뷰션, 메트릭만 가지고 오기 위해 GraphQL 적용할 수 있는지? (REST API 대신)

GA4 데이터 받을 때, streaming방식 (덩어리 혹은 조각으로)으로 받을 수 있는지?

GA4에서 flushing을 응용해서 사용할 수 있는지 (전체 응답이 생성되기 전에 데이터를 브라우저에게 보낼 수 있는 능력)

chrome lighthouse에서 참고해볼 것들이 있는지

lazy(), Suspense()를 사용해서 로딩시간을 최적화할 수 있는지

on-demand code splitting을 적용할 부분이 있는지 -- (Intersection Observer API 사용해서)

Code Splitting -- critical path를 먼저 식별하고!! entry point / vendor / dynamic splitting 중에 어떤것이 제일 적합할지

BE - 거대한 인라인 스크립트를 피해야한다 (스크립트 크기가 1KB가 넘으면 인라인으로 작성하지 말것)

BE - 긴 태스크를 피해야하는데 메인 스레드를 점유하고 있는지 (작은 작업으로 분할했다고 하더라도!)

의존성 식별 (3rd party) -- Chrorme DevTools/Lighthouse/WebPageTest 같은 도구로 가장 느리게 로딩되는 서드파티 의존성을 식별, 로딩 최적화(lazy loading, code splitting, tree shaking(은 보통 번들러와 빌드 도구들이 많이 사용하곤 함))

번들 분석 - Webpack Bundle Analyzer, Lighthouse Treemap 등 번들 분석하고 가장 많은 공간을 차지하는 의존성을 식별

3rd party 의존성 configuration을 최적화

렌더링 패턴(SPA, MPA, server-side, static, partial hydration, progressive hydration, islands architecture, incremental static generation, streaming SSR, resumability, edge rendering 등) 맞는것 찾기

Food Delivery Service (WooWa Bros) system architecture

달모드 — Sat, 21 Feb 2026 01:50:03 +0900

These sources detail the sophisticated technical strategies employed by Woowa Brothers to maintain the stability and performance of the Baedal Minjok ecosystem (ref: https://techblog.woowahan.com/2667/). The documentation highlights the "Shop Exposure System," which utilizes Spring WebFlux, Redis, and DynamoDB to manage massive traffic through reactive programming and asynchronous non-blocking I/O. Another key focus is the "Ad Listing System," where Kotlin DSLs and Coroutines are used to simplify complex query logic and improve developer productivity. To ensure system resilience, the engineering teams implement circuit breakers, vendor redundancy, and fault isolation to prevent external service outages from degrading the user experience. By conducting regular dependency audits and adopting a CQRS pattern, the company manages the inherent risks of a large-scale microservices architecture. Ultimately, these texts illustrate a continuous commitment to infrastructure optimization and proactive monitoring to handle the volatile demands of real-time delivery services.

Preface: This is a reflection from a study group I participate in biweekly, in person.

In Week 1 (Session 1), we examined the live shopping event on Toss — a Korean fintech app that leverages open banking (My Data) and also offers stock trading, an expense tracker, and various credit card promotions. I had done this session on paper and hadn't transferred my notes to a computer, so afterward I redrew the architecture digitally to get AI feedback and continue the discussion.

This session was centered around designing a high-traffic store listing system — loosely modeled after real-world platforms like Baedal Minjok. As the moderator, I guided the group through 1) Functional Requirements, 2) Non-Functional Requirements, and 3) System Architecture.

1) Functional Requirements were split into frontend and backend:

Frontend

Store list
DSL store info (thumbnails, etc.)
Delivery zone detection and delivery fee filtering logic
Ad banners (curation)

Backend

Policy service

2) Non-Functional Requirements were broken into three areas: Performance, Availability, and Scalability.

Performance — Scale Estimation

DAU: 10 million
QPU: 579
Peak QPS: 100,000
Registered stores: 1 million
Response time: ~200ms

Availability: 99.999% Scalability target: 30 million DAU

The most interesting part was designing the 3) System Architecture. The key discussion questions we wrestled with were:

Which DB type should we use as the primary DB — synchronous or asynchronous?
What replication architecture should we apply to the RDB?
If we go with Load Balancer → Cache → Server → RDB, and then separate reads via CQRS, should Elasticsearch be treated as an independent search layer or appended to the read DB? (This question surfaced the fact that most of us had only used ES for search functionality, not as a primary data store.)
Should we split the RDB into Master/Slave, or is there a better alternative?
How does the cost of filtering in RDB compare to Elasticsearch, and why?
When choosing between Elasticsearch and DynamoDB as the primary DB, what are the tradeoffs?
What are the tradeoffs of using Elasticsearch as the primary DB rather than an RDB?
Instead of using store ID as the PK, what if we used geospatial data (like a QuadTree, similar to Google Maps) as the cache key — wouldn't that improve accuracy? And rather than putting everything in a single cache, what if we split it into four layers: top-ranked locations, detailed filtering, personalization, and real-time state changes?
If ES is used for caching and synced periodically with the RDB, what is the data retention span in ES? TTL? But it doesn't make sense to delete data after a fixed interval — searches would break.
If we split caching into popular areas (LFU), detailed filtering, personalization, and real-time state changes — how many cache instances do we need, and what does that structure look like?
If we set the PK to lat/lng coordinates by region — users within the same zone should see the same results, and this approach seems more semantically correct.
How exactly does distributed processing work using Elasticsearch nodes and shards?
Where should the cache sit, and what spec should it use?

This architecture diagram is the final output of our discussion.

After the session, I asked a generative AI to identify and correct any missing or incorrect parts of the architecture.

Self-Reflection: CQRS + CDC Architecture Study Session

What I Think Went Well

The decision to adopt CQRS with a CDC pipeline was the right call. At a peak QPS of 100,000, a single RDB handling both reads and writes would inevitably become the bottleneck. Separating the write path (server → Relational DB) from the read path (Worker → Redis / Elasticsearch → Local Cache) is a pattern that production systems at this scale actually use, and I'm glad the group landed on it organically rather than being told the answer.

The idea of splitting the cache into four distinct buckets — Popular Areas (LFU-based), Detailed Filtering, Personalization, and Real-time State Changes — also felt like a meaningful insight. Rather than dumping everything into one cache layer and hoping for the best, this approach respects the fact that different data has different access patterns, different TTL requirements, and different tolerance for staleness. Separating Real-time State Changes into its own Pub/Sub-driven bucket in particular shows an understanding that open/close status updates cannot be treated the same way as relatively stable store metadata.

Choosing Debezium → Kafka → Worker as the synchronization backbone was also well-reasoned. Polling the database for changes is fragile and expensive. CDC via binlog capture is how this problem is actually solved at scale, and the group arrived at this without it being handed to them.

Where I Was Wrong or Shallow

1. The Numbers Lack a Derivation

We stated DAU of 10 million, peak QPS of 100,000, and QPU of 579 — but I cannot clearly explain where QPU 579 came from. In any serious design review or technical interview, the derivation matters more than the number itself. The expected reasoning looks something like:

10,000,000 DAU
× avg. requests per session (e.g., 5)
/ 86,400 seconds
≈ ~578 avg QPS

Peak QPS = avg QPS × spike multiplier (e.g., ×150 during lunch rush)
≈ 86,700 → rounded to 100,000

Without walking through this explicitly, the numbers are just decoration. I need to be able to justify every figure I put on a design document.

2. I Was Confused About What Elasticsearch Actually Is

The question "what if we use ES as the primary DB?" came up in our session, and I didn't shut it down cleanly enough. The answer is: you can't, and you shouldn't. Elasticsearch does not support ACID transactions. It doesn't guarantee durability the way a relational database does. A partial update internally triggers a delete and reindex. It is a search index built on top of a document store — it is a derived view of your data, not the source of truth.

The correct mental model is: the Relational DB owns the truth, and ES reflects it. Elasticsearch answers questions like "which stores match this filter set sorted by distance?" It does not replace the system that answers "what is the canonical state of store #4821?"

Going forward, I need to be precise about this distinction every time ES comes up in a discussion.

3. The QuadTree / Geospatial PK Idea Was Undercooked

The suggestion to use geospatial data — specifically QuadTree-based region classification — as a cache key had the right instinct behind it: users in the same geographic zone should see the same results, so keying the cache by region rather than by individual user makes sense. However, the way I phrased it ("use lat/lng as the PK") is technically incorrect and would be a red flag in a design review.

Raw latitude/longitude coordinates are floating-point numbers. They're noisy. Two users standing ten meters apart will generate different coordinates, and floating-point precision differences mean you cannot reliably use them as cache keys. The correct approach is to discretize the space first — hash the coordinates into a fixed-size cell using a scheme like Geohash, Google S2, or Uber's H3. Then that cell ID becomes the cache key.

The distinction is: QuadTree is a data structure for spatial indexing and range queries. Geohash / H3 is a way to assign a stable string identifier to a geographic region. They solve adjacent but different problems. I was conflating the two, and I need to be clearer about which tool does what.

4. The Worker's Sequential Update Logic Has a Gap

We defined the update order as: ① Redis 1st → ② Redis 2nd → ③ Elasticsearch. But I never addressed the failure case: what happens if Redis update succeeds but ES indexing fails?In a distributed system, partial failures are not edge cases — they are normal operating conditions. At minimum, the design needs a retry mechanism: failed ES updates should be sent to a dead-letter queue or retry topic so they can be replayed without data loss. Without this, the system silently drifts into inconsistency and there's no way to detect it.

5. 99.999% Availability Was Written Without Infrastructure to Back It Up

Five nines means 5 minutes and 15 seconds of downtime per year. I wrote this number on the diagram without specifying what it actually requires: multi-AZ deployment, active-active configuration, automated failover under 30 seconds, and careful handling of network partitions. None of that was reflected in the architecture. If I'm going to claim 99.999%, the diagram needs to show how the system survives the loss of an availability zone. Otherwise it's a wish, not a design target.

What I'm Taking Away

The most valuable part of this session wasn't the final diagram — it was the questions the group asked that I couldn't fully answer in the moment. Those gaps are the actual learning agenda:

I need to internalize how to derive capacity numbers from first principles, not just state them.
I need a much cleaner mental model of ES: what it's good at, what it can't do, and where it fits in the data flow.
I need to understand spatial indexing properly — Geohash, S2, H3 — before I use geospatial data in any future design.
I need to design for failure, not just for the happy path. Every asynchronous update step needs a defined behavior on failure.
I need to treat availability targets as engineering commitments, not aspirational numbers.

The architecture we drew is directionally correct. The CQRS pattern, the CDC pipeline, the layered cache strategy — these are real solutions to real problems. But a correct direction with unexamined gaps is only halfway to a real design. The next session should revisit the failure modes, the capacity math, and the geospatial keying strategy with more rigor.

Resources I'm Going to Read

Designing Data-Intensive Applications — Martin Kleppmann. Covers CQRS, CDC, replication, and consistency models in depth. Most of the questions raised in this session are answered in this book. (need to buy this)
Elasticsearch: The Definitive Guide (https://www.elastic.co/docs/get-started). Will clear up my confusion about what ES is and isn't.
Uber Engineering Blog — H3: Hexagonal Hierarchical Spatial Index. The practical reference for geospatial discretization.
Martin Fowler — CQRS (martinfowler.com/bliki/CQRS.html). Short, authoritative, worth reading before the next session https://martinfowler.com/bliki/CQRS.html
Confluent Blog — Change Data Capture with Debezium. Will deepen my understanding of the CDC layer we designed.
Woowa Brothers Tech Blog (techblog.woowahan.com) — specifically the Store Exposure System series, again. Reading it after having designed our own version will make the differences much more instructive.
System Design Interview Vol. 2 — Alex Xu. The cache design chapters map directly onto what we discussed. (I have this book)

Azure 환경변수 가져오는 법

달모드 — Thu, 19 Feb 2026 12:36:07 +0900

az webapp config appsettings list --name [App Name] --resource-group [RG name] --output table

Azure Docker 배포 시 Web App Crash issue RCA

달모드 — Fri, 4 Jul 2025 12:48:36 +0900

FE/BE 따로 배포하다가 하나의 앱으로 합치고 FE앱에 .env 를 설정하는 구조로 변경함.

일단 앱은 이와 같은 구조로 되어있다. NginX reverse proxy로 포트 호스팅을 해주니 정상적으로 배포를 하는듯 보였음

Issue 4: Frontend image fails to load with its proper layouts
This issue occurred because I selected the amd64 architecture on deployment, which is compatible with Azure but not with Mac M3 (arm64). As a result, the app initially worked perfectly only on Chrome. However, when I checked again a couple of days later, it started working on Safari as well.

그리고, 배포 후 새로운 subroute를 추가했을 경우 배포 전 체크할 부분
1) .env에 새로운 route 추가했는지 (react route)와 해당 스크립트에서 이 변수를 사용하게끔(하드코딩 no) - 안그럼 axios error 남
2) 애져 환경 변수에 해당 변수 등록
3) FE app build 다시
4) 그 후 도커 이미지 만들고 다시 배포

Issue 5: Resolving nginx Default Page Instead of React App IssueProblem

nginx welcome page shown instead of React app
Static resources (images, CSS, JS) not loading
404 errors in browser console

Root Cause Analysis:

nginx Cannot Find React Build Files

Build files missing or incorrectly placed in /usr/share/nginx/html

Issues with build file copying process in Dockerfile

Incorrect nginx Configuration for React App

Missing MIME type configurations for static files

No SPA (Single Page Application) routing handling

정리하자면,

MIME 타입이 제대로 설정되지 않아 정적 파일들이 올바른 Content-Type으로 제공되지 않음
정적 파일 경로와 디렉토리 구조가 맞지 않음

Solution:
static 파일들의 경로와 MIME 타입 설정을 보완

1. Dockerfile Modification

빌드된 react앱이 nginx 서빙 디렉토리에 제대로 복사되지 않음(멀티스테이지 빌드에서 빌드 결과물 복사 방식이 부적절. nginx 서빙 디렉토리 구조가 없거나 잘못됐을 가능성)

# Create nginx serving directory
RUN mkdir -p /usr/share/nginx/html

# Copy build files to correct location
WORKDIR /usr/share/nginx/html
COPY --from=frontend-build /app/frontend/build/ .

2. nginx.conf Modifications

  # MIME 타입 명시적 정의 추가
  types {
      application/javascript  js;
      text/css               css;
      image/png              png;
      image/jpeg             jpg jpeg;
      image/svg+xml          svg;
      font/ttf               ttf;
      font/woff             woff;
      font/woff2            woff2;
  }

  # 정적 파일 위치별 설정 추가
  location /static/ {
      alias /usr/share/nginx/html/static/;
      expires 1y;
      add_header Cache-Control "public, immutable";
  }

  location /fonts/ {
      alias /usr/share/nginx/html/fonts/;
      expires 1y;
      add_header Cache-Control "public, immutable";
  }

Key Learnings:

Careful attention needed for file copy paths in Docker multi-stage builds
Understanding essential nginx configurations for serving SPAs
Importance of proper MIME type and path configurations for static files

한국어 정리

nginx 설정 관련 문제

문제: 기본 nginx 페이지만 표시되고 React 앱이 로드되지 않음

원인:

MIME 타입이 제대로 설정되지 않아 정적 파일들이 올바른 Content-Type으로 제공되지 않음
정적 파일 경로와 디렉토리 구조가 맞지 않음

해결: nginx

  # MIME 타입 명시적 정의 추가

  types {

      application/javascript  js;

      text/css               css;

      image/png              png;

      image/jpeg             jpg jpeg;

      image/svg+xml          svg;

      font/ttf               ttf;

      font/woff             woff;

      font/woff2            woff2;

  }

  # 정적 파일 위치별 설정 추가

  location /static/ {

      alias /usr/share/nginx/html/static/;

      expires 1y;

      add_header Cache-Control "public, immutable";

  }

  location /fonts/ {

      alias /usr/share/nginx/html/fonts/;

      expires 1y;

      add_header Cache-Control "public, immutable";

  }

2. Dockerfile 구조 문제

문제: 빌드된 React 앱이 nginx 서빙 디렉토리에 제대로 복사되지 않음

원인:

멀티스테이지 빌드에서 빌드 결과물 복사 방식이 부적절
nginx 서빙 디렉토리 구조가 없거나 잘못됨

해결: dockerfile

3. 프록시 설정 불일치

문제: package.json의 프록시 설정(3001)과 실제 백엔드 포트(5001) 불일치

원인: 개발 환경과 프로덕션 환경의 포트 설정 차이

해결: package.json의 프록시 설정을 실제 백엔드 포트에 맞게 수정

4. 정적 파일 경로 문제

문제: React 앱의 정적 파일(CSS, JS)을 찾지 못함

원인:

homepage 설정이 부적절
빌드된 파일의 경로가 nginx 설정과 불일치

해결: package.json의 homepage 설정 수정

5. Docker 이미지 아키텍처 문제

문제: 로컬(ARM64)과 Azure(AMD64) 환경의 아키텍처 차이

원인: M3 맥에서 빌드된 이미지가 Azure의 AMD64 환경과 호환되지 않음

해결: 명시적으로 AMD64 플랫폼 지정

주요 교훈:

프론트엔드 빌드 결과물의 디렉토리 구조를 정확히 이해하고 nginx 설정에 반영해야 함
개발 환경과 프로덕션 환경의 차이(포트, 경로 등)를 주의 깊게 관리해야 함
컨테이너화 시 호스트와 타겟 환경의 아키텍처 차이를 고려해야 함
nginx의 정적 파일 서빙 설정과 MIME 타입 설정이 중요함

맥 패러랠즈 이후 벽돌 이슈(검정화면) 해결방법

달모드 — Mon, 12 May 2025 00:42:29 +0900

결론부터

1. Control + Option + Shift + 전원 누르면 전에 안보이던 circle loading이 뜨는데 이때 바로 잽싸게

2. Option + Cmd + P + R 을 누르면 와이파이 네트워크 선택 창으로 넘어간다!

안될 경우, 재부팅하고 Cmd + R 바로 잽싸게 누르면 애플 로고 나옴!

기 적!

안될 경우 아래를 따라 읽어보도록

<서사 시작>

윈도우랑 같이 이용하려고 패러랠즈를 깔았는데 열고 닫을 때 snooze 모드일 때 조금 버벅이길래 뭔가 낌새가 이상했다. 그치만 애써 무시했다.

근데.. 완전히 셧다운했다가 다시 재부팅하려니까 완전 아무 것도 안켜지는것이다. 심지어 충전할때 충전음도 안 남.

맛이 간건가? 생각하면서 부팅 자체가 안되니까 OS 레벨의 문제라고 생각이 들었다.

트러블슈팅을 깊게 할 생각은 없어서 더이상 안알아보고 그냥 몇개월동안 방치했더랬다.

그러다가 이번에 다시 오기로 오랜만에 재부팅하려고 하면서 찾아보니까 나왔다.

물론... 와이파이 연결하고 나서 지구본이 돌아가는데 그 다음 화면으로 넘어가기까지 겁 - 나 오래 걸린다. 분명 0:19라고 써져있는데 19분이 지나도 진행바는 가운데에도 도달하지 못했다.

시간이 늦어서 그냥 자야겠다는 생각..;;; 했는데 다음화면으로 넘어감.

support.apple.com/mac/startup

-2100F라고 떠서 바로 잽싸게 다른 맥으로 찾아봄

이 화면이랑 정확함 그래서 여기서 찾아봄

https://support.apple.com/en-us/102675

If your Mac doesn't start up all the way - Apple Support

What to do if your Mac gets stuck on a screen during startup.

support.apple.com

여기서 위쪽 드롭다운에서 지금 내 맥북 스펙에 맞게 intel chip 으로 바꿈

https://support.apple.com/en-us/102518?choose-your-type-of-mac=intel-based-mac#internet

How to start up from macOS Recovery - Apple Support

macOS Recovery is your computer’s built-in recovery system, with utilities to reinstall macOS, repair or erase your startup disk, restore from a Time Machine backup, and more.

support.apple.com

그랬더니 여기서 하란대로 함. 부팅하고 바로 Cmd+R

켜짐!!

그러면 이제 네가지 복구 방법 있는데 (타임머신 / 사파리 / 볼륨 그룹 조절 / 진단인가 어쩌구)

난 볼륨 그룹 조절에서 그냥 바로 볼륨 그룹 없애버림. 미련없이 ㅂㅇ

그리고 macOS Sonoma 버전 새로 깔기 모드 선택해버림. (네트워크 연결이 되어있어야 서버로부터 새 OS 다운 가능)

그럼 됨

자바스크립트 Var, Let, Const

달모드 — Thu, 20 Mar 2025 18:09:21 +0900

원래 JS에서는 변수를 선언할 때 var만 사용할 수 있었다. 그런데 2015년부터 let과 const가 추가되었다.

그러면서 원래 사용되던 var를 이제는..변수를 사용할 때 사용하게 되면 다소 superfluous한 느낌이 되어서 이제 거의 JS를 사용할 땐 변수에는 let, 상수에서는 const를 사용하는 편이 되었다.

pc: educative

var는 스코프 밖에서도 되지만, let과 const의 경우는 그들이 선언된 스코프 내에서만 존재한다. 스코프란 함수도 될 수 있고, 루프도 될 수 있고, if 조건문도 될 수 있다. {}를 이용해서 열고 닫는 모든 것들이 scope가 될 수 있다.

그렇기 때문에 아래와 같이 루프 안에서만 j가 존재하기 때문에, 출력을 하려고 하면 오류가 나는 것이다.

pc: educative

만약에 내가 변수를 오버라이딩 하고 싶으면, let을 사용한다. 근데 만약에 내가 늘 똑같은 상수같은 변수를 사용해야하면, 이때는 const를 사용하는 것이다.

(let의 사용이 swift와 반대라서 헷갈릴수도.! ㅎ Swift는 변하면 안되는 상수가 let, 아닌 경우가 var)

결국 표로 정리하면 아래와 같다.

pc: educative

React 프로젝트 시작(CRA)

달모드 — Thu, 20 Mar 2025 17:40:29 +0900

CRA는 Create React App의 준말으로, 리엑트 코어팀 소속이자 리덕스를 만든 Dan Abranmov가 만든 리액트 스타터 팩이다.

yarn create react app projectname

npm install -g create-react-app

create-react-app projectname

으로 하면 projectname으로 된 폴더가 만들어지면서 그 안에 리액트 프로젝트가 생성된다.

예를 들어, yarn으로 프로젝트를 설치하면 이렇게.. 아래와 같이 뜨는데

pc:educative

yarn start

dev 서버를 시작하는 것이다. npm이면 npm start를 하면 됨.

yarn build

public server에 배포를 할 수 있게끔 앱의 빌드 폴더를 만드는 것이다. 개발용 빌드(yarn start)와 비교했을 때, public server용 빌드는 성능적으로 최적화되어있다. 그렇기 때문에 yarn start보다 yarn build를 했을 때 더 시간이 오래 걸린다.

yarn test

테스트를 실행하는건데, CRA를 하면 Jest도 같이 설치가 된다. 다른 테스팅 프레임워크와 비교했을 때, snapshot testing 기능도 들어있다. 이건 내가 만든 컴포넌트의 현재 state의 복사본을 생성한 후, 향후 테스트 state와 비교를 하는 기능이다.

yarn eject

앱의 Yarn coverage를 마치는 역할을 한다. 모든 빌드 스크립트, dependencies, config file이 현재 프로젝트 경로에 복사가 된다.

React 사전준비: 필요 라이브러리 및 패키지

달모드 — Thu, 20 Mar 2025 17:28:29 +0900

Node.js and npm

nvm을 이용해서 설치를 권장한다.

Yarn

Node, npm도 훌륭한 패키지 매니저긴 하지만, 페이스북에서 만든 yarn은 리액트를 좀더 쉽게 이용할 수 있도록 더 간결한 커맨드와 더 나은 캐싱을 제공하여 더 좋은 성능을 보인다.

npm install --global yarn

npm i -g yarn

을 사용해서 설치하면 된다.

Babel

리엑트 기반의 프로젝트를 만들 때 의존성(dependency)용으로만 사용된다(npm package임). 바벨은 이슈 없이 모던 브라우저의 기준에 맞지 않거나 표준화되지 않은 자바스크립트가 실행될 수 있도록 transpile 과정을 도와주는 역할이다. (transpiling: 소스 코드의 언어를, 기능적으로 완전히 똑같게 다른 언어로 바꾸는 과정을 말함. 여기선 JSX or ES2015+를 어느 브라우저에서든 유효하고 실행 가능한 자바스크립트로 변환하는 것을 뜻함.)

바벨은 코어 모듈(@babel/core)로 이루어저있는데, 보통 플러그인들은 프리셋들로 그룹이 지어져있다.

Note: Before Babel’s version 7 was released, this organization did not exist, and hyphens separated the packages. @babel/preset-react was called babel-preset-react, @babel/core was named babel-core, and so on.

그러므로 @babel/core가 아닌 babel-core라고 써져있어도 당황스러워하지 말자.( 이 경우 바벨 6 버전 이하라는 것이다.) 그러나 개발자에 따라 바벨 7과 호환이 되는데도 babel-을 사용하는 사람도 있다. 이때는 어떤 일때문에 그런지 readme를 확인하면 된다.

여기서 권장하는 리엑트 프리셋은 아래와 같다.

@babel/preset-env
@babel/preset-react
@babel/plugin-proposal-object-rest-spread
@babel/plugin-proposal-class-properties
@babel/plugin-syntax-dynamic-import

만약 Flow나 TypeScript와 같은 정적 타입을 작업할 때엔 @babel/preset-flow 혹은 @babel/preset-typescript 도 설치해야 한다(respectively).

npm install --save dev [package]

yarn add --dev [package]

로 설치 (--dev 나 --save dev는 devDependency에만 추가한다는 것이라 production code에는 추가되지 않을 것을 뜻함)

Webpack

웹팩은 리액트 생태계에서 제일 중심을 이루는 도구 중 하나다. 이게 없으면 리액트에서 효율적인 워크플로우는 불가능하다고 볼 수 있다. 웹팩은 모듈 번들러인데, Node.js같은 모듈 기반의 개발을 브라우저로 가져온 것이다. 이를 통해 앱 코드를 자체 파일에 깔끔하게 구조화하고, import 또는 require()를 통해 종속성을 사용할 수 있다. 이렇게 하면 종속성이 자체 모듈 범위에 로드되어서 모듈 내에서 사용할 수 있고, 결국 단일 자바스크립트 파일만 생성된다.

ESLint

정적 코드 분석에 필요한 도구이다. 거의 de-facto 스탠다드로 쓰이는. 리액트 프로젝트에서 eslint-plugin-react, eslint-plugin-babel, and eslint-plugin-react-hooks 와 같은 것들을 볼 수 있다.

Prettier

코드 포맷을 규칙적으로 교정해주는 툴 정도

브라우저 플러그인

크롬에 React Dev Tool, Redux Dev Tool이 있다.

pc: educative

[Two Pointers] 19. Remove Nth Node From End of List

달모드 — Thu, 13 Feb 2025 21:44:01 +0900

문제 링크

https://leetcode.com/problems/remove-nth-node-from-end-of-list/description/

문제 접근 방법

투포인터의 응용 문제이다.

tail으로부터 출발하면 투포인터 쓰지 않아도 되지 않나...생각했는데, 투포인터를 쓴대니까 right pointer로 삭제할 노드를 짚어내나? 라고 생각해서 접근했는데 이렇게는 도무지 투포인터 패턴으로 문제가 안풀리는거다.

일단 left pointer의 역할은 연결리스트 특성상 노드를 삭제하고 나면 삭제된 노드 이전 노드랑 연결하는 역할일거라 생각해서, left pointer는 루프가 끝났을 때 무조건 그 곳으로 가있어야할 것 같았고.. (즉, Nth Node - 1에 위치하고 있어야함)

그럼 left/right pointer 둘 중 어떤 걸로 삭제할 Nth Node를 짚어내나? 어떻게 하지..? 생각했는데 일단 right 포인터가 완전 tail으로 이동했다고 생각했을 때, left pointer와 right pointer가 주어진 n만큼 벌어져있으면 자연스럽게 left pointer는 삭제할 Nth Node에 위치할 것이라고 나왔다.

The optimized two-pointer approach removes the Nth node from the end of a linked list in one traversal by maintaining a fixed gap between two pointers. Initially, both left and right pointers start at the head, and the right pointer is moved forward by n steps, creating a gap of nodes. This gap ensures that when the right pointer reaches the end of the list, the left pointer is positioned just before the node to be removed. Both pointers then move forward together, maintaining the gap, until the right pointer reaches the end. At this point, the target node is skipped by updating the left pointer’s next link. If the right pointer reaches the end during the initial n steps, it indicates the head node is the target, which is removed by returning the next node of the head.

Initialize two pointers, left and right, both pointing to the head of the linked list.
Move the right pointer n steps ahead. This creates a gap of n nodes between the left and right pointers.
If, after moving the right pointer n steps forward, it becomes NULL, it means the head node is the target for removal. In this case, return head.next as the new head of the linked list, effectively removing the original head node.
If the right pointer hasn’t reached the end after moving n steps, move both the right and left pointers forward by one step at a time, maintaining the gap between them. This ensures that when the right pointer reaches the end of the linked list, the left pointer will be positioned just before the node that needs to be removed.
Once the right pointer reaches the end of the linked list, update left.next to left.next.next. This action skips over the target node, effectively removing it from the linked list.
Finally, return the original head, which now points to the updated linked list with the nth node removed.

pc: educative

고민한 부분, 주의사항

출처: eductive

example 4에서, 만약에 내가 삭제해야하는 Nth Node가 head인 경우의 테스트 케이스를 처리해주지 않아서 통과를 안하는거다!

세운 알고리즘 대로라면, gap으로 벌린 n이 너무 커서 right pointer가 Null으로 넘어가는 경우(if not right)에는 head를 버리는 거니까 head 이후의 노드들을 반환하는 경우도 처리를 해주어야 했다.

if not right:
return head.next

코드

# Definition for a Linked List node
# class LinkedListNode:
#     def __init__(self, data, next=None):
#         self.data = data
#         self.next = next

from linked_list import LinkedList
from linked_list_node import LinkedListNode

def remove_nth_last_node(head, n):
    left = right = head 
    for i in range(n):
      right = right.next
      
    if not right: # n의 크기가 연결리스트 크기만큼 큰 바람에 right가 None으로 벗어나서, head node를 없애야 하는 경우 
      return head.next
      
    while right.next:
      left = left.next
      right = right.next
    
    left.next = left.next.next
      
    
    return head

나의 발자취

브라우저 작동 원리에 따른 앱 성능 최적화 (Web Browser Engineering)

React App 확장성을 위해 점검해 볼것

Food Delivery Service (WooWa Bros) system architecture

Self-Reflection: CQRS + CDC Architecture Study Session

What I Think Went Well

Where I Was Wrong or Shallow

1. The Numbers Lack a Derivation

2. I Was Confused About What Elasticsearch Actually Is

3. The QuadTree / Geospatial PK Idea Was Undercooked

4. The Worker's Sequential Update Logic Has a Gap

5. 99.999% Availability Was Written Without Infrastructure to Back It Up

What I'm Taking Away

Resources I'm Going to Read

Azure 환경변수 가져오는 법

Azure Docker 배포 시 Web App Crash issue RCA

맥 패러랠즈 이후 벽돌 이슈(검정화면) 해결방법

자바스크립트 Var, Let, Const

React 프로젝트 시작(CRA)

React 사전준비: 필요 라이브러리 및 패키지

Node.js and npm

Yarn

Babel

Webpack

ESLint

Prettier

브라우저 플러그인

[Two Pointers] 19. Remove Nth Node From End of List

문제 링크

문제 접근 방법

고민한 부분, 주의사항

코드

풀고 나서 (접근법, 사용되는 알고리즘 개념)