완전히 코딩 초보는 아니었어요. 학교에서 풀스택 프로젝트도 꽤 해봤죠. 하지만 실무 경험은 전혀 없었습니다. 실제 트래픽도 없었고, 사용자 이탈을 걱정하며 QA가 압박하는 상황도 겪어본 적이 없었죠.

회사에 들어가 보니, 이커머스 홈페이지는 체감상 정말 느렸습니다. QA는 매주 같은 메시지를 남겼어요.

"홈페이지 또 느려요 😭" "히어로 영역 + 상품 그리드 로딩 너무 오래 걸려요" "3초 넘게 걸려서 유저들이 떠나요"

리포트를 열어보면 끔찍한 워터폴이 보였고, 저는 그저 멍해질 수밖에 없었습니다.

스택만 보면 최신이었어요: S3 + CloudFront + SPA. “모듈화”를 위해 추천 영역이나 배너 같은 부분은 iframe으로 구성되어 있었습니다. 이론상으로는 플러그 앤 플레이 구조였죠. 하지만 실제로는 무겁고 깨지기 쉬운 시스템이었습니다.

뭔가 잘못됐다는 건 느꼈지만, 그걸 설명할 언어가 없었습니다. 각 iframe이 사실상 거대한 중복 의존성 그래프를 드러내고 있다는 걸 그땐 몰랐죠.

모놀리식 구조의 달콤한 단순함

하나의 SPA는 처음 만들 때는 정말 깔끔해 보입니다.

하나의 앱, 하나의 배포. 상품 리스트, 상세 페이지, 이벤트, 프로모션… 전부 한 곳에 넣으면 되죠. 다른 곳에서 재사용하고 싶으면 iframe으로 감싸서 넣으면 끝.

빠르고 실용적인 선택처럼 보입니다.

하지만 그게 함정입니다.

iframe은 단순히 UI를 임베드하는 게 아닙니다. 런타임 전체를 임베드하는 것입니다.

우리는 단순히 "배너"를 넣은 게 아니라, 거대한 React 애플리케이션을 작은 창 안에 또 하나 띄우고 있었던 겁니다.

각 “모듈”은 사실상 새로운 앱 인스턴스를 브라우저에서 다시 부팅하게 만들고 있었어요.

이 시스템은 기술적으로는 최신이었지만, 구조적으로는 과부하 상태였습니다. iframe이 문제를 만든 게 아니라, 문제를 숨길 수 없게 만든 것이었습니다.

1. 무게 문제: 작은 UI에 너무 많은 코드

이 문제는 보통 여기서 가장 먼저 드러납니다.

유저는 단순한 프로모션 페이지를 열었을 뿐인데, 브라우저는 전체 쇼핑몰 애플리케이션을 다운로드합니다.

상품 목록 로직, 상세 페이지, 이벤트 처리, 라우팅, 공통 컴포넌트… 시간이 지나며 쌓인 모든 것들이 포함됩니다.

즉, 키오스크 하나 보려고 쇼핑몰 전체를 로딩하는 셈입니다.

모놀리식 SPA는 기능이 늘어날수록 번들이 커지기 때문에 이런 문제가 생깁니다. 결과적으로:

• JavaScript 용량 증가
• 파싱 및 실행 시간 증가
• 첫 인터랙션 지연
• 저사양 기기에서 메모리 압박

iframe은 이 불일치를 눈에 보이게 만들었습니다.

작은 화면 하나를 위해 전체 앱을 초기화해야 했고, 그 비용을 페이지 내에서 여러 번 반복해서 지불하게 만든 거죠.

핵심 문제: UI는 작아 보이지만, 실제 런타임 비용은 거대하다. 그리고 iframe은 이 거짓말을 드러냈다.

2. 보이지 않는 콘텐츠 문제: 크롤러가 못 보는 구조

두 번째 문제는 더 미묘해서 더 오래 방치되기 쉽습니다.

문제의 시작은 클라이언트 렌더링 SPA였습니다. 검색 엔진이 JavaScript를 실행할 수는 있지만, 핵심 콘텐츠를 여기에 의존하는 건 위험한 선택입니다.

iframe은 여기에 한 단계 더 복잡성을 추가했습니다.

SPA 자체도 인덱싱이 불안정한데, iframe으로 콘텐츠를 분산시키면서 더 어려워진 겁니다.

중요한 포인트는 이겁니다:

• SPA는 기본적으로 콘텐츠를 “숨기고”
• iframe은 그걸 “더 고치기 어렵게 만든다”

iframe을 제거해도 문제가 해결되진 않습니다. 핵심은 서버에서 콘텐츠를 렌더링하는 것(SSR) 입니다.

내가 잘못 이해했던 부분

한동안 저는 이걸 단순히 “성능 문제”라고 생각했습니다.

그래서 네트워크 지연, 이미지 용량, CDN 캐시 같은 것들을 살폈죠.

물론 중요했습니다. 하지만 본질은 아니었습니다.

진짜 문제는 아키텍처의 형태였습니다.

앱은 너무 많은 책임을 가지고 있었고, 너무 많은 코드가 공유되고 있었으며, 하나의 배포 단위에 너무 많은 것이 들어 있었습니다.

iframe은 문제를 만든 게 아니라, 그걸 여러 번 실행하게 만들어서 드러낸 것뿐이었습니다.

그때 깨달았습니다. 문제를 잘못 보고 있었다는 것을.

그래서 매니저에게 요청했습니다. 단순한 최적화가 아니라, 구조적인 개선을 하자고요.

• 번들 줄이기
• 사용하지 않는 코드 제거
• 페이지 분리
• 빌드 파이프라인 개선
• 모든 페이지가 모든 기능을 들고 다니지 않도록 만들기

이 대화는 코드만큼 중요했습니다.

실제로 도움이 된 것들

우리는 완전히 새로 만들지 않았습니다. 마이크로 프론트엔드로 전환하지도 않았습니다.

대신 시스템을 작고, 깔끔하게 만들었습니다.

1. Tree shaking & dead code 제거

사용되지 않는 코드들을 제거했습니다.

이건 사소해 보이지만, 죽은 코드도 여전히 다운로드되고, 파싱되고, 실행됩니다.

2. SWC 도입

빌드 속도를 개선했습니다.

이건 단순히 시간을 절약한 게 아니라, 개발 방식 자체를 바꿨습니다.

빌드가 빠르면:

• 더 자주 리팩토링하고
• 코드 분리를 시도하고
• 구조 개선을 두려워하지 않게 됩니다

3. 페이지 및 코드 분리

필요한 것만 로딩하도록 했습니다.

"지금 필요 없는 기능은 다운로드하지 않는다"

이 단순한 원칙이 큰 변화를 만들었습니다.

결과

결과는 명확했습니다.

• 배포 시간: 10분 → 2분
• 로딩 시간: 3초 이상 → 1초 이하

이건 단순한 숫자가 아닙니다.

팀의 행동 자체를 바꿉니다.

• 빠른 배포 → 빠른 피드백
• 빠른 피드백 → 더 높은 자신감
• 높은 자신감 → 더 좋은 아키텍처 결정

핵심 교훈

브라우저가 로딩해야 하는 것을 줄여라.

iframe이 문제인 게 아닙니다. SPA가 문제인 것도 아닙니다.

문제는 이겁니다:

거대한 모놀리스를 여러 번 로딩하는 구조

좋은 구조는 보통 다음을 포함합니다:

• 경험 단위로 페이지를 분리
• SSR 또는 프리렌더링 사용
• 라우트/기능 단위로 코드 분할
• iframe은 정말 필요한 경우에만 사용
• 불필요한 런타임 공유 최소화

결론

이 프로젝트에서 가장 어려웠던 건 코드가 아니라 인정이었습니다.

아키텍처가 문제라는 걸 인정하는 것.

문제를 버그 단위로 보지 않고 패턴으로 보기 시작했을 때, 비로소 해결의 방향이 보였습니다.

• 너무 많은 코드
• 너무 강한 결합
• 그리고 iframe으로 증폭된 구조적 문제

이글은 원문을 번역했습니다. 원문도 제가 작성했습니다: https://dev.to/deadlocker/i-joined-my-first-job-and-the-homepage-took-forever-to-load-e9o

skills-npm은 이 문제를 꽤 우아하게 해결합니다. 핵심은 단순합니다. AI 지침을 npm 패키지 안에 같이 실어서 배포하자는 것입니다.

문제: 업데이트되지 않는 CLAUDE.md

에이전트에게 컨텍스트를 주는 방법은 크게 두 가지입니다. 직접 프롬프트에 넣거나, CLAUDE.md 같은 파일에 적어두는 것이죠. 두 번째 방식이 현실적으로 더 낫습니다. 그런데 문제가 있습니다.

• 버전 미스매치: CLAUDE.md에 "이 SDK는 이렇게 써라"라고 적어뒀는데, SDK가 업데이트되면 이 파일은 자동으로 바뀌지 않습니다. 누군가 수동으로 바꿔야 합니다. 근데 아무도 안 합니다. 저도 안 했습니다.
• 레포 간 단절: 프론트엔드 레포를 열어놓은 에이전트는 백엔드 레포의 비즈니스 로직이나 테라폼으로 관리되는 인프라 구조를 모릅니다. 레포가 늘어날수록 개발자가 직접 설명해야 할 게 쌓입니다.

본질적으로, AI에게 전달하는 컨텍스트가 코드와 분리된 채 관리되고 있다는 구조적 문제입니다.

기존 방식: Git 기반 스킬 배포의 한계

현재 가장 많이 쓰이는 건 vercel-labs/skills 같은 Git 기반 스킬 CLI입니다. npx skills add로 Git 레포에서 스킬을 클론해서 프로젝트에 연결하는 방식이죠. 쓸 만하긴 한데 한계가 명확합니다.

• 툴이랑 따로 놀음: 스킬 버전이랑 실제 툴 버전이 별도로 관리됩니다. SDK가 1.0에서 2.0으로 올라갔는데 스킬은 여전히 1.0 기준이어도 아무도 모릅니다.
• 팀 공유가 번거로움: 클론된 파일을 레포에 커밋하든지, 새 머신마다 다시 설치하든지 둘 중 하나입니다. 둘 다 별로입니다.

skills-npm: npm 패키지에 AI 지침을 번들링

skills-npm이 제안하는 컨벤션은 이겁니다. SDK 개발자가 npm publish할 때 AI 지침 파일도 같이 실어서 보낸다. 소비자는 npm install하면 자동으로 그 지침이 에이전트가 읽을 수 있는 위치로 심볼릭 링크됩니다.

SDK 버전이 2.0으로 올라가면 SKILL.md도 2.0에 맞게 업데이트됩니다. npm install만 하면 에이전트가 읽는 지침도 즉시 최신화되는 겁니다. 따로 관리할 게 없습니다.

skills-npm 생태계의 3 주체

공급자 (SDK 개발자)

• SDK 프로젝트 내 skills/<스킬명>/SKILL.md 작성
• package.json의 files 필드에 "skills" 포함
• skills-npm 에서 제안하는 방법을 참고

소비자 (앱 개발자)

• npm i -D skills-npm 설치
• prepare 스크립트에 skills-npm 등록
• npm install 시 skills/npm-<패키지명>-<스킬명> 경로로 자동 심볼릭 링크 생성

AI 에이전트 (Cursor, Claude Code, Codex 등)

• 심볼릭 링크된 skills/npm-* 경로 스캔
• SKILL.md를 읽어 SDK 사용법과 시스템 간 연동 로직 파악

심볼릭 링크(symlink)라는 게 낯설 수 있는데, 실제 파일을 복사하는 게 아니라 node_modules 안에 있는 원본을 가리키는 포인터를 만드는 겁니다. 그래서 npm update로 패키지가 바뀌면 에이전트가 읽는 내용도 자동으로 바뀝니다.

설정 방법

공급자: 패키지 구조

my-sdk/
├── package.json
├── dist/
└── skills/
    └── data-integrity/   ← 스킬 이름
        └── SKILL.md

package.json에서 files 필드에 skills를 반드시 포함해야 합니다. 빠뜨리면 npm publish할 때 해당 디렉토리가 제외됩니다.

{
  "name": "@my-org/my-sdk",
  "version": "1.3.0",
  "files": [
    "dist",
    "skills",
    "index.d.ts"
  ]
}

소비자: 설치 및 설정

npm i -D skills-npm

{
  "scripts": {
    "prepare": "skills-npm"
  }
}

prepare 훅을 쓰는 이유는 npm install 직후 자동으로 실행되기 때문입니다. 팀원이 클론하고 npm install만 해도 세팅이 끝납니다.

.gitignore에 아래도 추가합니다. 심볼릭 링크를 커밋할 필요는 없습니다.

skills/npm-*

고급 설정: skills-npm.config.ts

모노레포 환경이거나 특정 패키지의 스킬만 주입하고 싶을 때 씁니다.

import { defineConfig } from 'skills-npm'

export default defineConfig({
  source: 'package.json',
  agents: ['cursor', 'claude-code'],
  gitignore: true,
  include: ['@my-org/*'], // 사내 SDK 스킬만 주입, 외부 패키지 제외
})

include를 안 쓰면 node_modules 전체를 스캔합니다. 외부 패키지가 skills를 가지고 있는 경우 원치 않는 지침이 주입될 수 있으니, 조직 스코프(@my-org/*)로 필터링하는 게 안전합니다.

Git 기반 vs npm 기반 비교

두 방식은 경쟁 관계가 아닙니다. Git 기반은 npm에 올라오지 않은 커뮤니티 스킬이나 빠른 실험에 여전히 편하고, npm 기반은 팀이 직접 만든 SDK에 지침을 번들링하거나 버전 고정이 중요한 환경에 적합합니다.

주의할 점

몇 가지 트레이드오프가 있습니다.

추가 패키징 작업이 생깁니다. SDK 릴리즈마다 SKILL.md도 챙겨야 합니다. 코드 변경 없이 지침만 업데이트하는 경우라도 버전을 올려야 합니다. 처음엔 번거롭습니다.

토큰 관리는 여전히 필요합니다. skills-npm이 심볼릭 링크를 깔아준다고 해서 에이전트가 알아서 적절히 읽는 건 아닙니다. 로더 설정에 따라 모든 스킬이 한꺼번에 컨텍스트에 들어올 수도 있습니다. 스킬이 많아질수록 메타데이터만 먼저 노출하고 필요한 것만 로드하는 레이지 로딩 전략을 고민해야 합니다. 무지성으로 다 넣으면 토큰만 낭비됩니다.

에이전트마다 지원 방식이 다릅니다. Cursor, Claude Code, Codex 스킬 파일을 읽는 방식이 완전히 동일하지 않습니다. skills-npm.config.ts의 agents 옵션으로 타깃 에이전트를 명시하는 게 좋습니다.

semver로 지침 변경을 관리하는 방법

지침도 코드처럼 semver로 관리하면 의도치 않은 변경을 막을 수 있습니다.

• Patch (0.0.x): 오탈자 수정, 예시 개선, 설명 명확화
• Minor (0.x.0): 새 API 사용법 추가, 기존 내용은 건드리지 않음
• Major (x.0.0): API 시그니처 변경, 기존 권장 방식 폐기, 스킬 이름 변경

production 에이전트 워크플로라면 버전을 고정("1.3.0")하는 게 낫습니다. 범위("^1.3.0")로 쓰면 마이너 업데이트에 지침이 자동으로 바뀌는데, 에이전트가 갑자기 다른 패턴으로 코드를 짜기 시작하면 디버깅이 귀찮아집니다.

마치며

skills-npm이 해결하는 건 사실 단순합니다. "AI 지침이 코드랑 같이 버전 관리되면 좋겠다"는 것이죠. npm이 이미 그 인프라를 갖추고 있으니, 거기에 올라타는 겁니다.

아직 현장에서 이 컨벤션을 지원하는 npm 패키지 수가 많지는 않습니다. @slidev/cli, eslint-vitest-rule-tester, @vueuse/skills 등 몇 가지가 있고, 생태계는 만들어지는 중입니다. 직접 쓰는 내부 SDK가 있다면 SKILL.md 하나 추가하고 package.json에 "skills" 한 줄 넣는 것부터 시작해볼 만합니다. 앞으로 npm 패키지에 skills를 넣으며 관리를 해봐야겠습니다.

ai-chatbot 의 구조 분석

ai-chatbot 은 보편적으로 사용되는 UI와 기능들을 갖추고 있습니다.

• 로그인 및 회원가입
• 메시지 입력 후 챗봇 답변 받기
• LLM 모델 선택
• 각 채팅 별 세션 분리
• 입력한 메시지 수정 기능
• 여러 Tool 제공
  • 날씨 조회
  • 문서(document) 작성 기능
• Artifact 기능
  • 문서(document) 작성
    • Text kind
    • Code kind
    • Sheet kind
    • Image kind

구조 분석

Next app 라우터로 auth 그룹과 chat 그룹을 Route group으로 나눠놨습니다. chat 그룹에는 챗봇 기능에 대한 컴포넌트들이 모여있습니다. Chat이라는 컴포넌트가 챗봇 기능을 담당하는 핵심적인 컴포넌트입니다. 구조는 다음과 같습니다:

Page 컴포넌트 분석

역할

Page 컴포넌트는 서버 사이드 페이지 컴포넌트로, 특정 채팅 ID에 해당하는 채팅 데이터를 가져와 클라이언트 컴포넌트인 Chat과 DataStreamHandler를 렌더링합니다. 인증, 권한 확인, 데이터 조회 및 변환을 처리합니다.

주요 기능

1. 파라미터 처리
   • props.params.id를 통해 동적 라우트에서 채팅 ID를 추출. (Next.js Dynamic route 참고)
2. 데이터 조회
   • getChatById(id): DB에서 채팅 데이터를 조회.
   • getMessagesByChatId(id): 해당 채팅의 메시지 목록을 조회.
   • 조회된 채팅이 없으면 notFound()로 404 응답.
3. 인증 및 권한 확인
   • auth()를 호출해 사용자 세션을 확인.
   • 세션이 없으면 /api/auth/guest로 리다이렉트.
   • 채팅이 private인 경우:
     • 세션에 사용자 정보가 없거나, 사용자가 채팅 소유자가 아니면 notFound() 호출.
4. 데이터 변환
   • convertToUIMessages: DB 메시지(DBMessage)를 클라이언트용 UIMessage 포맷으로 변환.
     • id, parts, role, createdAt, experimental_attachments를 매핑.
     • content는 곧 deprecated될 예정이므로 빈 문자열로 설정.
5. 쿠키 기반 모델 선택
   • cookies()를 사용해 chat-model 쿠키를 확인.
   • 쿠키가 없으면 DEFAULT_CHAT_MODEL을 사용.
   • 쿠키가 있으면 해당 값을 selectedChatModel로 전달.

특징

• 서버 사이드에서 실행되며, 클라이언트로 데이터를 전달하기 전에 인증과 권한을 철저히 확인.
• 쿠키를 활용해 사용자 선호 모델을 동적으로 반영.
• 메시지 데이터를 클라이언트 포맷으로 변환해 Chat 컴포넌트에 전달.

Chat 컴포넌트 분석

역할

Chat 컴포넌트는 클라이언트 사이드에서 동작하는 채팅 UI 컴포넌트로, 사용자와 AI 간의 대화를 관리하고 표시합니다. @ai-sdk/react의 useChat 훅을 사용해 메시지 상태를 관리하며, 메시지 입력, 투표, 아티팩트 등을 처리합니다.

주요 기능

1. 상태 관리
   • useChat 훅(ai-sdk 문서 참고):
     • messages, setMessages: 메시지 목록 관리.
     • input, setInput: 사용자 입력 관리.
     • handleSubmit, append: 메시지 전송 및 추가.
     • status, stop, reload: 채팅 상태 및 제어.
     • 커스텀 설정:
       • id: 채팅 ID.
       • initialMessages: 초기 메시지 목록.
       • experimental_throttle: 100ms로 요청 제한.
       • generateId: UUID 생성.
       • experimental_prepareRequestBody: 요청 본문에 id, message, selectedChatModel 포함.
       • onFinish: 채팅 완료 시 사이드바 히스토리 캐시 갱신.
       • onError: 에러 발생 시 토스트 알림 표시.
   • useState:
     • attachments: 첨부 파일 상태 관리.
   • useSWR(SWR 문서 참고):
     • /api/vote?chatId=${id}에서 투표 데이터 조회 (메시지가 2개 이상일 때).
   • useArtifactSelector: 아티팩트 표시 여부 확인.
2. UI 구성
   • ChatHeader: 채팅 상단 바 (모델, 공개 상태, 읽기 전용 여부 표시).
   • Messages: 메시지 목록 표시 및 투표, 메시지 수정, 리로드 기능.
   • MultimodalInput: 텍스트 및 첨부 파일 입력 폼 (읽기 전용이 아닌 경우 표시).
   • Artifact: 추가 콘텐츠 (예: 이미지, 파일) 표시 및 관리.
3. 이벤트 처리
   • 메시지 전송: handleSubmit 또는 append 호출.
   • 입력 중단: stop 호출.
   • 메시지 리로드: reload 호출.
   • 첨부 파일 관리: setAttachments로 상태 업데이트.
   • 캐시 갱신: mutate로 사이드바 채팅 히스토리 갱신.

특징

• 클라이언트 사이드에서 동작하며, 실시간 메시지 및 첨부 파일 관리.
• useChat 훅을 활용해 AI 대화 상태를 효율적으로 관리.
• SWR을 사용해 투표 데이터를 비동기적으로 로드.
• 읽기 전용 모드와 아티팩트 표시 여부를 동적으로 처리.
• 에러 핸들링 및 사용자 피드백(토스트) 제공.

요약 비교

• Page: 서버 사이드에서 데이터 조회, 인증, 권한 확인, 데이터 변환을 처리하며 Chat 컴포넌트에 필요한 데이터를 준비.
• Chat: 클라이언트 사이드에서 사용자 인터랙션과 UI 렌더링을 담당하며, AI 대화와 실시간 상태를 관리.
• 연결점: Page가 Chat에 initialMessages, selectedChatModel, session 등을 전달해 초기 상태를 설정.

브라우저 렌더링 과정에 대해서 설명해주세요

익숙한 질문인가요? 웹 개발자 기술 면접의 단골 질문이지만, 저는 지금까지 '대충' 알고 넘어갔었습니다. 이번 기회에 브라우저를 제대로 알고자 Chromium project를 분석해보려고합니다. Chromium을 분석 대상으로 선정한 이유는 현대 웹 브라우저 생태계에서의 압도적인 영향력 때문입니다. 현재 시장 점유율이 가장 높은 Google Chrome을 비롯하여 Microsoft Edge, Opera, Naver Whale, Brave, Vivaldi 등 수많은 주요 웹 브라우저들이 Chromium의 오픈 소스 코드를 기반으로 개발되고 있습니다. 이 글에서는 브라우저의 동작 방식부터 Chromium의 실제 구조까지 파헤쳐보겠습니다.

🤔 브라우저는 어떻게 동작할까?

먼저 브라우저가 어떻게 동작하는지 알아보겠습니다. MDN의 How browsers work 문서에 따르면 브라우저의 렌더링 단계를 다음과 같이 설명합니다.

⚡️ 핵심 렌더링 단계

1. 파싱 (Parsing)
   • HTML → DOM 트리 변환 (HTMLParser)
   • CSS → CSSOM 트리 변환 (StyleEngine 처리)
2. 렌더 트리 생성
   • DOM + CSSOM 결합 → 화면에 표시될 요소만 선택
   • display: none 요소는 제외, visibility: hidden은 포함
3. 레이아웃 (Reflow)
   • 뷰포트 크기 기반으로 픽셀 단위 위치 계산
   • 상대 단위(%, rem) → 절대 픽셀 값으로 변환
4. 페인트 (Paint)
   • 그리기 명령(PaintRecord) 생성
   • 레이어 분할: 3D transform, opacity 등의 속성은 별도 레이어로 렌더링
5. 합성 (Compositing)
   • GPU 가속으로 레이어 병합 (컴포지터 스레드 담당)
   • 스크롤, 애니메이션은 리페인트 없이 처리 가능

브라우저는 DOM/CSSOM → 렌더 트리 → 레이아웃 → 페인트 → 합성 과정을 거칩니다.

🌐 Chromium은 무엇인가?

Chromium은 Google이 주도하는 오픈 소스 웹 브라우저 프로젝트입니다. 우리가 흔히 사용하는 Google Chrome 브라우저는 바로 이 Chromium 프로젝트의 소스 코드를 기반으로 만들어졌습니다. (Chrome 과 Chromium은 같은게 아닙니다!)

주요 특징은 다음과 같습니다:

1. 핵심 엔진 제공 (Blink, V8)
   • Blink 렌더링 엔진 (WebKit에서 파생):
     • Blink 소개: Blink가 Chromium 프로젝트의 렌더링 엔진임을 설명합니다.
     • MDN 웹 문서 용어 사전 - Blink: Blink가 WebKit의 WebCore 라이브러리 포크로 시작되었음을 설명합니다.
     • Wikipedia - Blink (browser engine): Blink가 Chromium 프로젝트의 일부이며, WebKit에서 포크(fork)된 배경을 설명합니다.
   • V8 JavaScript 엔진:
     • V8 공식 웹사이트
     • Wikipedia - V8 (JavaScript engine): V8 엔진이 Google Chrome 브라우저를 위해 개발되었고 Chromium 프로젝트의 일부임을 설명합니다.
2. Chrome과의 차이 (독점 기능, 코덱 등)
   • Chrome vs Chromium 비교: 자동 업데이트, 미디어 코덱(MP3, H.264, AAC) 및 Flash 지원(과거), 오류 보고 등 Chrome에 추가된 기능과 Chromium과의 차이를 설명합니다.
   • Chrome vs Chromium 주요 차이점: Chrome이 Chromium 기반에 자동 업데이트, Google 동기화, 미디어 코덱 등 독점 코드를 추가했다고 설명합니다.
   • Google Chrome과의 차이: Chrome은 독점 라이선스를 가지며 MP3, H.264, AAC 코덱 및 Adobe Flash(과거)를 지원하지만 Chromium은 그렇지 않다고 설명합니다.
3. 빠른 개발 주기 (기능 실험 및 테스트)
   • Chromium 공식 문서 - Chrome 릴리스 주기: 현재 Chrome이 4주마다 새로운 메이저 버전을 안정 채널(Stable Channel)에 출시하는 빠른 주기를 설명합니다. 새로운 기능은 메인 브랜치에서 개발되고 테스트 단계를 거쳐 배포됩니다.
   • Chromium 공식 문서 - 기능 출시 프로세스: 새로운 기능이 Chromium 내에서 프로토타입으로 시작하여 플래그(flag) 뒤에서 개발되고, 개발자 테스트(Dev Trials), 오리진 트라이얼(Origin Trial) 등을 거쳐 최종적으로 출시되는 과정을 설명합니다. 이는 Chrome 안정 버전에 포함되기 전에 Chromium에서 먼저 구현되고 테스트됨을 보여줍니다.

🏰 Chromium 아키텍처 탐구: 탭 하나가 멈춰도 전체 브라우저는 괜찮은 이유

참고 문서 https://www.chromium.org/developers/design-documents/multi-process-architecture/

혹시 웹 서핑 중 특정 웹 페이지 하나 때문에 브라우저 전체가 멈추거나 꺼져버리는 답답한 경험을 해보신 적 있나요? 2000년대 중반의 웹 브라우저들은 종종 이런 문제를 겪곤 했습니다. 마치 오래된 싱글태스킹 운영체제에서 응용 프로그램 하나가 시스템 전체를 마비시키는 것처럼, 웹 페이지나 플러그인 하나가 브라우저 전체를 멈추게 만들 수 있었습니다.

하지만 오늘날 우리가 사용하는 Chrome과 같은 최신 브라우저들은 훨씬 안정적입니다. 그 비결은 바로 Chromium의 멀티 프로세스 아키텍처(Multi-Process Architecture) 에 있습니다. Chromium은 이 아키텍처를 통해 마치 현대 운영체제가 여러 응용 프로그램을 독립된 프로세스로 분리하여 안정성과 보안을 확보하는 것과 같은 이점을 웹 브라우징 환경에 가져왔습니다.

핵심 아이디어: 분리하고 보호

Chromium은 브라우저의 기능을 여러 개의 독립적인 프로세스(Process) 로 나눕니다.

1. 브라우저 프로세스 (Browser Process):
   • 브라우저의 '두뇌' 역할을 합니다.
   • 사용자 인터페이스(UI)를 담당하고, 다른 모든 프로세스(렌더러, GPU 등)를 관리합니다.
   • 각 렌더러 프로세스와 통신하며 상태를 관리하는 RenderProcessHost 객체를 가집니다.
2. 렌더러 프로세스 (Renderer Process):
   • 실제 웹 페이지를 화면에 그리는(렌더링) 작업을 담당합니다. 각 탭이나 프레임은 일반적으로 별도의 렌더러 프로세스에서 실행됩니다. (물론, 특정 조건 하에서는 프로세스를 공유하기도 합니다.)
   • HTML 파싱과 레이아웃을 위해 Blink 렌더링 엔진을 사용합니다. 각 렌더러 프로세스는 부모인 브라우저 프로세스와 통신하고 전역 상태를 관리하는 RenderProcess 객체를 가집니다.
   • 각 문서(프레임)는 RenderFrame 객체에 해당하며, 이는 브라우저 프로세스의 RenderFrameHost와 통신합니다.

멀티 프로세스 아키텍처의 장점

이렇게 프로세스를 분리함으로써 Chromium은 여러 가지 중요한 이점을 얻습니다.

1. 안정성 (Stability): 만약 하나의 탭(렌더러 프로세스)에서 오류가 발생하거나 멈추더라도, 해당 탭만 영향을 받고 브라우저 전체가 다운되지 않습니다. 문제가 생긴 탭에는 "앗, 이런!" 화면이 표시되고, 사용자는 해당 탭만 새로고침하여 복구할 수 있습니다.
2. 보안 (Security): 각 렌더러 프로세스는 샌드박스(Sandbox) 라는 제한된 환경에서 실행됩니다. 이는 렌더러 프로세스가 사용자의 파일 시스템, 네트워크, 입력 장치 등에 직접 접근하는 것을 막아줍니다. 만약 악의적인 웹사이트가 렌더러 프로세스를 장악하더라도, 샌드박스 덕분에 시스템 전체에 미치는 피해를 크게 줄일 수 있습니다.
3. 자원 관리 (Resource Management): 사용자가 보지 않는 숨겨진 탭이나 백그라운드 탭(렌더러 프로세스)의 우선순위를 낮출 수 있습니다. 시스템 메모리가 부족할 경우, 운영체제는 이런 우선순위가 낮은 프로세스의 메모리를 먼저 디스크로 옮깁니다(스왑 아웃). 이를 통해 사용자가 현재 보고 있는 활성 탭이 더 빠르고 부드럽게 동작하도록 돕습니다. 메모리가 충분할 때는 이 과정이 눈에 띄지 않으므로 성능 저하 없이 효율적인 메모리 관리가 가능합니다.

👩🏽‍🎤 Blink 는 어떻게 작동하는가

How Blink works 문서에서는 Blink의 작동 방식에 대해서 다음과 같이 설명합니다. 자세한 설명은 문서를 참고바랍니다.

Blink의 역할

Blink는 웹 브라우저 탭 안에서 웹 콘텐츠를 렌더링하는 핵심 엔진입니다. 주요 역할은 다음과 같습니다.

• 웹 표준 구현: HTML, CSS, Web IDL 등 웹 플랫폼의 다양한 기술 표준을 해석하고 처리합니다. (e.g. HTML standard)
• JavaScript 실행: V8 JavaScript 엔진을 내장하여 웹 페이지의 동적인 기능을 수행합니다.
• 리소스 요청: 웹 페이지에 필요한 이미지, 스타일 시트 등의 자원을 네트워크를 통해 가져옵니다.
• DOM 트리 구축: 다운로드한 HTML 코드를 바탕으로 웹 페이지의 구조를 나타내는 DOM (Document Object Model) 트리를 만듭니다.
• 스타일 및 레이아웃 계산: CSS를 해석하여 각 요소의 시각적인 스타일을 결정하고, DOM 트리를 기반으로 화면에 어떻게 배치할지 계산합니다.
• 그래픽 렌더링: 계산된 스타일과 레이아웃 정보를 바탕으로 실제 화면에 콘텐츠를 그립니다 (Chrome Compositor 활용).

Blink는 웹 페이지의 코드를 해석하고 시각적으로 표현하여 사용자가 웹 콘텐츠를 볼 수 있도록 하는 핵심적인 렌더링 기능을 제공하는 엔진입니다. Chromium, Opera, Android WebView와 같은 다양한 웹 브라우저 환경에서 content public APIs를 통해 사용됩니다.

Blink와 프로세스 구조

Chromium은 여러 개의 프로세스를 사용하는 구조입니다. 크게 하나의 브라우저 프로세스와 여러 개의 샌드박스 처리된 렌더러 프로세스로 나뉩니다. Blink는 바로 이 렌더러 프로세스 안에서 동작합니다.

렌더러 프로세스는 왜 이렇게 많을까요?

가장 큰 이유는 보안 때문입니다. 서로 다른 웹사이트의 정보가 담긴 메모리 공간을 분리하는 것이 중요합니다. 이를 사이트 격리(Site Isolation)라고 부릅니다. 이상적으로는 각 렌더러 프로세스가 하나의 웹사이트만을 담당해야 합니다.

하지만 현실은 조금 다릅니다. 사용자가 너무 많은 탭을 열거나 기기의 메모리가 부족할 때는 하나의 렌더러 프로세스가 여러 개의 다른 웹사이트 (iframe이나 탭)를 함께 처리하기도 합니다. 따라서 렌더러 프로세스, iframe, 탭 사이에는 1:1 관계가 없습니다.

샌드박스 안에서 Blink는 뭘 할 수 있을까요?

렌더러 프로세스는 샌드박스라는 제한된 환경에서 실행되기 때문에, 시스템 자원(파일 접근, 오디오 재생 등)에 직접 접근하거나 사용자 정보(쿠키, 비밀번호 등)를 함부로 사용할 수 없습니다. Blink가 이러한 작업을 수행하려면 브라우저 프로세스에 요청해야 합니다.

브라우저 프로세스와 렌더러 프로세스는 어떻게 소통할까요?

이 둘 사이의 통신은 Mojo라는 기술을 통해 이루어집니다. 과거에는 Chromium IPC라는 방식을 사용했지만, 현재는 Mojo로 대체되고 있습니다. Chromium 내부적으로는 브라우저 프로세스를 여러 개의 "서비스"로 나누는 작업(Servicification)이 진행 중이며, Blink 입장에서는 Mojo를 통해 이러한 서비스들과 편리하게 상호작용할 수 있습니다.

렌더러 프로세스 내의 스레드 구조

하나의 렌더러 프로세스 안에는 다음과 같은 종류의 스레드가 존재합니다.

• 메인 스레드 (Main Thread): Blink에서 가장 중요한 작업들이 대부분 이 스레드에서 처리됩니다. JavaScript 실행 (Worker 제외), DOM 조작, CSS 처리, 스타일 계산, 레이아웃 계산 등이 모두 메인 스레드에서 이루어집니다. Blink는 이 메인 스레드의 성능을 최대한으로 끌어올리도록 매우 잘 최적화되어 있습니다. (대부분의 작업이 단일 스레드에서 처리된다고 가정합니다.)
• 워커 스레드 (Worker Threads, N개): 웹 워커(Web Workers), 서비스 워커(ServiceWorker), 워크릿(Worklets)과 같은 별도의 작업을 병렬로 처리하기 위해 Blink가 필요에 따라 여러 개의 워커 스레드를 생성할 수 있습니다.
• 내부 스레드 (Internal Threads, 몇 개): Blink와 V8 엔진 내부적으로 특정 작업을 처리하기 위해 사용되는 스레드들입니다. 예를 들어, 웹 오디오 처리, 데이터베이스 작업, 가비지 컬렉션(GC) 등이 이러한 내부 스레드에서 실행될 수 있습니다.

스레드 간 통신 방식:

서로 다른 스레드끼리 정보를 주고받기 위해서는 메시지 전달 방식을 사용해야 합니다. PostTask API를 통해 작업을 특정 스레드의 작업 큐에 추가하는 방식으로 통신합니다. 공유 메모리 방식은 성능상의 특별한 이유가 있는 극히 일부 경우를 제외하고는 권장되지 않습니다. 따라서 Blink 코드베이스에서 MutexLock과 같은 동기화 메커니즘을 많이 찾아볼 수 없는 이유이기도 합니다.

렌더링 파이프라인

그래서 어떻게 렌더링 하는가에 대한 것이 웹 프론트엔드 개발자에게 중요할 것입니다. 렌더링 각 단계에 대한 자세한 설명은 이 문서를 참고하세요.

전체적인 렌더링 흐름은 다음과 같습니다:

조금 더 자세한 다이어그램:

👾 Chromium 에 대해 알아보며...

처음에는 단순히 "브라우저가 어떻게 화면을 그리는지"에 대한 호기심으로 시작했던 여정이었습니다. 렌더링 과정의 각 단계를 하나씩 따라가다 보니, 그 뒤에 숨겨진 Chromium의 거대한 아키텍처와 혁신적인 아이디어들을 마주하게 되었습니다.

Chromium에 대해 더 알아본 뒤에 Firefox와 최근에 개발이 시작된 ladybird 프로젝트 등도 살펴봐야 겠습니다.

요약 테이블 데이터에서 특정 열들을 그룹으로 묶어서 보여주는 컴포넌트를 구현하는 과정에 관한 글입니다. 테이블을 구현하는데에 그루핑한 데이터를 표현하는 방법을 찾는 분들께 아이디어가 될 수 있습니다.

이번 글에서는 엑셀 파일을 테이블로 나타내기에 이어서, 로드한 데이터를 그루핑하여 테이블로 나타내는 법을 공유드리려고 합니다.

상품 판매내역 엑셀 파일에서 상품을 그루핑하여 한번에 상품 요소들만 봐야하는 경우가 있습니다. 데이터를 그룹화하여 테이블 형태로 보여주는 React 컴포넌트를 설계하고 구현하는 방법에 대해 자세히 다루어 보겠습니다.

🤔 문제 정의

쇼핑몰 운영자는 상품 판매내역 파일을 받아서 확인합니다. 문제는 위의 이미지처럼 상품들이 판매된 순서대로 나열되어 있어서 상품들을 구조화해서 확인하기가 어렵습니다. 그래서 같은 카테고리로 묶고 각 옵션도 상품에 따라 묶어서 아래와 같이 나타내려고 합니다.

단순히 나열되어 있던 형태에서 각 카테고리 및 상품에 어떤 요소가 속해있는지 더욱 보기 쉬워졌습니다.

이때, column 값은 사용자가 정의함에 따라 무엇이든 될 수 있습니다. 왼쪽에 있는 column일수록 상위 그룹입니다. 그룹화해야하는 column의 수가 최대 10개라고 가정할 때 테이블 컴포넌트를 어떻게 설계하고 구현해야 할까요?

👀 데이터를 그룹화하여 보여주는 플로우

사용자가 엑셀 파일을 업로드하고 이를 그루핑 테이블로 변환하는 과정은 다음과 같습니다.

1. 엑셀 파일 업로드
2. 엑셀 파일을 JSON 데이터로 변환
3. 사용자가 그루핑하기를 원하는 column 선택
4. 그루핑 대상 column으로 그루핑 데이터 생성
5. 그루핑 데이터를 그루핑 테이블을 통하여 렌더링

여기서 4~5번 플로우를 구현해야 하므로 해당 부분을 좀더 구체화하도록 하겠습니다.

🔎 그루핑 테이블 스펙

그루핑 테이블과 원본 데이터 테이블에 비해서 다음의 특징을 가집니다.

• 중복되는 값이 존재하지 않습니다.
• 같은 그룹일 경우에는 그룹 대상 값의 셀이 하위 셀들을 모두 포함하도록 행병합되어 나타납니다.
  

🌚 데이터 구조 설계

기본 테이블에 보여줄 데이터는 JSON으로 변환되기 때문에 다음과 같이 정의합니다.

// table/tableData.ts

export type TableData = Record<string, string>[]; // key-value 배열

그렇다면 그루핑 데이터는 어떻게 해야할까요? 그루핑 데이터를 설계하기 위해서는 그루핑 테이블을 만들기 위해서 어떤 정보가 필요한지 살펴봐야합니다. 그루핑 데이터를 컴포넌트로 작성하면 다음과 같습니다.

function GroupedTable(): React.ReactElement {
    return (
        <table>
            <thead>
            <tr>
                <th>카테고리</th>
                <th>상품</th>
                <th>옵션</th>
            </tr>
            </thead>
            <tbody>
            <tr>
                <td rowSpan={2}>의류</td>
                <td>후드</td>
                <td>사이즈=M</td>
            </tr>
            <tr>
                <td>셔츠</td>
                <td>사이즈=L</td>
            </tr>
            <tr>
                <td rowSpan={5}>음식</td>
                <td rowSpan={2}>감바스</td>
                <td>팩=4팩</td>
            </tr>
            <tr>
                <td>팩=2팩</td>
            </tr>
            <tr>
                <td rowSpan={3}>닭강정</td>
                <td>양념=없음</td>
            </tr>
            <tr>
                <td>양념=간장</td>
            </tr>
            <tr>
                <td>양념=매운맛</td>
            </tr>
            </tbody>
        </table>
    );
}

첫번째로 테이블 헤더에 column이 필요합니다. 두번째로 테이블 바디에 보여줄 각 column에 해당하는 값들이 필요합니다. 마지막으로 각 테이블 셀에 rowSpan 값을 넣고있는 것을 확인할 수 있습니다. rowSpan은 해당 셀을 행으로 몇 칸을 차지하게 할 것인지에 대한 속성값입니다.

rowSpan값을 보면 각 그룹들의 최하위 요소들의 개수를 넣고 있습니다. (1개라면 넣지 않습니다. - 그러면 default로 1이 세팅됩니다.)

각 요소들을 그룹화하고 최하단 요소의 개수를 세어서 rowSpan 값으로 지정한다는 점에서 트리 자료구조가 적합하다고 판단했습니다.

위의 트리형태에 중복제거와 그룹별 하위 노드 조회를 빠르게 하기 위해 key value 형태로 하위 노드를 관리하도록 했습니다.

export interface IGroupedTableDataNode {
    get childrenNodes(): Record<string, IGroupedTableDataNode>;
    // key 값은 column에 해당하는 value <ex) 의류, 음식> 중복되면 안되므로 key값으로 설정
    // value는 그룹에 해당되는 하위 노드

    get values(): string[]; // 노드의 column에 해당하는 value들 배열
    get countLeafNodes(): number; // 말단 노드의 개수

    insert: (value: string) => void; // 새로운 하위 노드 삽입
}

정의한 데이터 타입 IGroupedTableDataNode를 다음의 플로우에서 활용합니다.

상위컴포넌트가 그룹화 객체 변환 함수에 원본데이터 TableData를 입력하면 함수는 IGroupedTableDataNode를 반환하고 이를 그루핑 테이블에 전달하면 그루핑 테이블 컴포넌트가 생성되게 됩니다.

🛠️ 구현

앞에서 정의한 데이터들을 종합해서 코드를 작성하면 다음과 같습니다.

// table/TableData.ts
export type TableData = Record<string, string>[];

export interface TableCellInfo {
    // 테이블 셀에 데이터
    value: string;
    rowSpan: number;
}

export type TableRow = TableCellInfo[];
export type TableRows = TableRow[];

export interface IGroupedTableDataNode {
    get childrenNodes(): Record<string, IGroupedTableDataNode>;
    // key 값은 column에 해당하는 value <ex) 의류, 음식> 중복되면 안되므로 key값으로 설정
    // value는 그룹에 해당되는 하위 노드

    get values(): string[]; // 노드의 column에 해당하는 value들 배열
    countLeafNodes(): number; // 말단 노드의 개수

    insert: (value: string) => void; // 새로운 하위 노드 삽입
}

export class GroupedTableDataNode implements IGroupedTableDataNode {
    private _childrenNodes: Record<string, IGroupedTableDataNode>;

    constructor() {
        this._childrenNodes = {};
    }

    get childrenNodes(): Record<string, IGroupedTableDataNode> {
        return this._childrenNodes;
    }

    get values(): string[] {
        return Object.keys(this._childrenNodes);
    }

    countLeafNodes(): number {
        // 트리의 말단 노드의 개수를 세어주는 메서드
        // 재귀 함수
        // 재귀 탈출 조건은 하위 노드가 없는 것 -> 없을 경우 1반환
        if (this.values.length === 0) {
            return 1;
        }

        let cnt = 0;

        for (const node of Object.values(this._childrenNodes)) {
            cnt += node.countLeafNodes();
        }

        return cnt;
    }

    insert(value: string): void {
        // 새로운 하위 노드 삽입
        if (!this._childrenNodes[value]) {
            // value에 하위 노드가 존재하지 않을 경우 새로운 노드 삽입
            this._childrenNodes[value] = new GroupedTableDataNode();
        }
    }
}

그루핑 테이블 컴포넌트를 소비하는 상위 컴포넌트를 작성하겠습니다. 테스트를 위해서 사용자가 변환하려는 원본데이터와 그루핑하려는 열 이름 순열도 같이 정의하겠습니다.

상위 컴포넌트 코드 예시는 다음과 같습니다.

// App.tsx
import React from 'react';
import './App.css';
import GroupedTable from "./table/GroupedTable";
import {IGroupedTableDataNode, TableData} from "./table/TableData";
import {groupingTableData} from "./table/groupingTableData";

const data: TableData = [
    {
        '카테고리': '의류',
        '상품': '후드',
        '옵션': '사이즈=M'
    },
    {
        '카테고리': '음식',
        '상품': '감바스',
        '옵션': '팩=4팩',
    },
    {
        '카테고리': '음식',
        '상품': '닭강정',
        '옵션': '양념=없음'
    },
    {
        '카테고리': '음식',
        '상품': '감바스',
        '옵션': '팩=2팩'
    },
    {
        '카테고리': '의류',
        '상품': '후드',
        '옵션': '사이즈=M'
    },
    {
        '카테고리': '음식',
        '상품': '닭강정',
        '옵션': '양념=간장',
    },
    {
        '카테고리': '음식',
        '상품': '닭강정',
        '옵션': '양념=매운맛',
    },
    {
        '카테고리': '의류',
        '상품': '셔츠',
        '옵션': '사이즈=L',
    },
];

const columns: string[] = ['카테고리', '상품', '옵션'];

function App() {
      // data는 원본 데이터, columns는 그루핑하려는 열 이름 순열
    const groupedData: IGroupedTableDataNode = groupingTableData(data, columns);

    return (
        <div className="App">
            <section style={{padding: '30px'}}>
                <GroupedTable groupedData={groupedData} columns={columns} />
            </section>
        </div>
    );
}

원본데이터를 그루핑테이블 컴포넌트로 전달하기 이전에 변환을 해야합니다. 변환 로직을 수행하는 그룹화 객체 변환 함수 코드입니다.

// table/groupingTableData.ts

import {GroupedTableDataNode, IGroupedTableDataNode, TableData} from "./TableData";

export function groupingTableData(tableData: TableData, columns: string[]): IGroupedTableDataNode {
    // 루트 노드 생성
    const root: IGroupedTableDataNode = new GroupedTableDataNode();

    for (const row of tableData) {
        // row 행 하나씩 트리에 삽입
        let curNode: IGroupedTableDataNode = root;

        for (const column of columns) {
            const value = row[column];

            curNode.insert(value);
            curNode = curNode.childrenNodes[value];

            if (!curNode) {
                // curNode가 null이나 undefined일 경우
                throw new Error('IGroupedTableDataNode 노드가 생성되지 않았습니다.');
            }
        }
    }

    return root;
}

최종적으로 데이터를 보여주는 그루핑 테이블 컴포넌트 코드입니다.

// table/GroupedTable

import React from 'react';
import './DataTable.css';
import {IGroupedTableDataNode, TableRow, TableRows} from "./TableData";

// HTMLTableElement 의 data와 children props를 제외하고 상속
export interface GroupedTableProps extends Omit<React.HTMLProps<HTMLTableElement>, 'data' | 'children'> {
    groupedData: IGroupedTableDataNode;
    columns: string[];
}

function GroupedTable(props: GroupedTableProps): React.ReactElement {
    const {groupedData, columns} = props;

    const tableCells: TableRows = groupedDataToTableRows(groupedData);

    return (
        <table {...props}>
            <thead>
            <tr>
                {
                    columns.map(column => (
                        <th key={column}>{column}</th>
                    ))
                }
            </tr>
            </thead>
            <tbody>
            {
                tableCells.map((row, index) => (
                    <tr key={index}>
                        {
                            row.map((d, index) => (
                                <td key={index}
                                    rowSpan={d.rowSpan}>
                                    {d.value}
                                </td>
                            ))
                        }
                    </tr>
                ))
            }
            </tbody>
        </table>
    );
}

export default GroupedTable;

function groupedDataToTableRows(groupedData: IGroupedTableDataNode, initTableRow: TableRow = []): TableRows {
    // TODO 그루핑 데이터를 테이블 행들로 변경하는 함수
      // 아래에 구현 설명이 있습니다.
}

그루핑 데이터를 테이블 view 데이터로 변환

테이블에 보여져야하는 데이터를 첫번째 행부터 순차적으로 만들면 다음과 같습니다.

// 첫번째 행
const data = [
  [
    {value: '의류', rowSpan: 2},
    {value: '후드', rowSpan: 1},
    {value: '사이즈=M', rowSpan: 1}
  ]
]

// 두번째 행
const data = [
  [
    {value: '의류', rowSpan: 2},
    {value: '후드', rowSpan: 1},
    {value: '사이즈=M', rowSpan: 1}
  ],
  [
    {value: '셔츠', rowSpan: 1},
    {value: '사이즈=L', rowSpan: 1}
  ]
]

// 세번째 행
const data = [
  [
    {value: '의류', rowSpan: 2},
    {value: '후드', rowSpan: 1},
    {value: '사이즈=M', rowSpan: 1}
  ],
  [
    {value: '셔츠', rowSpan: 1},
    {value: '사이즈=L', rowSpan: 1}
  ],
  [
    {value: '음식', rowSpan: 5},
    {value: '감바스', rowSpan: 2},
    {value: '팩=4팩', rowSpan: 1}
  ],
]

// 네번째 행
const data = [
  [
    {value: '의류', rowSpan: 2},
    {value: '후드', rowSpan: 1},
    {value: '사이즈=M', rowSpan: 1}
  ],
  [
    {value: '셔츠', rowSpan: 1},
    {value: '사이즈=L', rowSpan: 1}
  ],
  [
    {value: '음식', rowSpan: 5},
    {value: '감바스', rowSpan: 2},
    {value: '팩=4팩', rowSpan: 1}
  ],
  [
    {value: '팩=2팩', rowSpan: 1}
  ],
]

// 네번째 행
const data = [
  [
    {value: '의류', rowSpan: 2},
    {value: '후드', rowSpan: 1},
    {value: '사이즈=M', rowSpan: 1}
  ],
  [
    {value: '셔츠', rowSpan: 1},
    {value: '사이즈=L', rowSpan: 1}
  ],
  [
    {value: '음식', rowSpan: 5},
    {value: '감바스', rowSpan: 2},
    {value: '팩=4팩', rowSpan: 1}
  ],
  [
    {value: '팩=2팩', rowSpan: 1}
  ],
  [
    {value: '닭강정', rowSpan: 3},
    {value: '양념=없음', rowSpan: 1}
  ],
]

위의 데이터의 형태로 바뀌어야 GroupedTable컴포넌트에서 데이터를 의도한대로 나타낼 수 있습니다.

그루핑 데이터를 위의 코드처럼 view를 위한 데이터로 변환해주는 groupedDataToTableRows 함수입니다.

// table/GroupedTable

function groupedDataToTableRows(groupedData: IGroupedTableDataNode, initTableRow: TableRow = []): TableRows {
    // 그루핑 데이터를 테이블 행들로 변경하는 함수
    // 재귀 함수

    const result: TableRows = [];

    if (groupedData.values.length === 0) {
        // 하위 노드가 없다면 재귀 함수 탈출
        return [initTableRow];
    }

    for (let i = 0; i < groupedData.values.length; i++) {
        const val = groupedData.values[i];

        if (i === 0) {
            // 첫번째라면 initTableRow를 포함해서 행 생성
            const childNode = groupedData.childrenNodes[val];
            const newRow = groupedDataToTableRows(childNode, initTableRow.concat([{value: val, rowSpan: childNode.countLeafNodes()}]));
            result.push(...newRow);
            continue;
        }

        // 두번째 이상의 value라면 initTableRow (이전 값)들을 제외한 현재 노드와 하위노드 추가
        const childNode = groupedData.childrenNodes[val];
        const newRow = groupedDataToTableRows(childNode, [{value: val, rowSpan: childNode.countLeafNodes()}]);
        result.push(...newRow);
    }

    return result;
}

😎 결과

4개의 column으로 데이터를 만들어서 테스트를 하면 다음과 같이 나타납니다.

const data: TableData = [
    {
        '카테고리': '상의',
        '상품': '후드',
        '색상': '블랙',
        '사이즈': 'L'
    },
    {
        '카테고리': '상의',
        '상품': '셔츠',
        '색상': '화이트',
        '사이즈': 'M'
    },
    {
        '카테고리': '상의',
        '상품': '후드',
        '색상': '블랙',
        '사이즈': 'S'
    },
    {
        '카테고리': '하의',
        '상품': '슬랙스',
        '색상': '블랙',
        '사이즈': 'M'
    },
    {
        '카테고리': '하의',
        '상품': '슬랙스',
        '색상': '화이트',
        '사이즈': 'S'
    },
    {
        '카테고리': '하의',
        '상품': '청바지',
        '색상': '블루',
        '사이즈': 'M'
    },
    {
        '카테고리': '상의',
        '상품': '후드',
        '색상': '레드',
        '사이즈': 'L'
    },
    {
        '카테고리': '상의',
        '상품': '후드',
        '색상': '레드',
        '사이즈': 'M'
    },
    {
        '카테고리': '하의',
        '상품': '슬랙스',
        '색상': '블랙',
        '사이즈': 'L'
    },
];

const columns: string[] = ['카테고리', '상품', '색상', '사이즈'];

🤓 인사이트

• 트리와 DFS를 FE개발하면서 자주 사용하지 않았는데 이번 문제와 같은 상황에서는 배열만으로 구현하는 로직에 비해 쉽게 해결할 수 있었습니다. 상위 요소와 하위 요소간의 관계를 갖는 상황에서 트리를 더 활용해볼 수 있을 것 같습니다.
• 데이터 간의 변환이 자주 일어났습니다. 변환하는 기능들을 좀 더 쉽게 해줄 모듈(커스텀 훅 또는 라이브러리)가 필요합니다.
• 핵심로직이 설명없이 보면 이해하기가 힘들었습니다. 동료 또는 미래의 나를 위해서 트리 구조와 DFS 알고리즘처럼 이해가 필요한 코드는 자세한 설명 문서 또는 코멘트가 필요하다는 것을 느꼈습니다.

엑셀 파일을 업로드하고 이를 테이블로 보여줘야하는 요구사항이 생겼습니다.

💻코드

하나의 파일에 해당 기능을 모두 구현한 코드입니다.

import React, {useState} from 'react';
import * as XLSX from 'xlsx';

const ExcelReader: React.FC = () => {
  const [data, setData] = useState<Record<string, string>[]>([]);

  const tableHead = Array.from(data.reduce((acc, cur) => {
    // 키값을 모두 Set 객체에 add
    Object.keys(cur).forEach(k => acc.add(k));
    return acc;
  }, new Set<string>()));

  const handleFileUpload = (e: React.ChangeEvent<HTMLInputElement>) => {
    // 파일을 업로드 했을 때의 처리
    const file = e.target.files?.[0];
    if (file) {
      const reader = new FileReader();
      reader.onload = (evt) => {
        const bstr = evt.target?.result as string;
        const wb = XLSX.read(bstr, {type: 'binary'});
        const wsname = wb.SheetNames[0];
        const ws = wb.Sheets[wsname];
        const data: Record<string, string>[] = XLSX.utils.sheet_to_json(ws);
        setData(data);
      };
      reader.readAsBinaryString(file);
    }
  };

  return (
    <div>
      <input type='file' onChange={handleFileUpload} />
      <table>
        <thead>
        <tr>
          {tableHead.map((value) => (
            <td key={value}>{value}</td>
          ))}
        </tr>
        </thead>
        <tbody>
        {data.map((row, i) => (
          <tr key={i}>
            {tableHead.map((key) => (
              <td key={key}>{row[key] ?? ''}</td>
            ))}
          </tr>
        ))}
        </tbody>
      </table>
    </div>
  );
};

export default ExcelReader;

이 코드는 엑셀 파일을 업로드하고, 그 내용을 웹 페이지의 테이블로 나타내는 기본적인 기능을 구현한 것입니다.

화면은 다음과 같이 나타납니다. [파일 선택전]

[파일 선택 후]

🤓코드 단계적 설명

React에서 엑셀 파일을 업로드하고, 그 내용을 웹 페이지의 테이블로 나타내는 작업은 다음과 같은 단계로 구성했습니다.:

1. 파일 업로드: 사용자가 엑셀 파일을 웹 페이지에 업로드할 수 있도록 input 태그를 사용하여 파일 업로드 기능을 구현합니다.

2. 파일 읽기: 업로드된 파일을 읽기 위해 FileReader 객체를 사용합니다. 이 객체는 웹 애플리케이션에서 비동기적으로 데이터를 읽을 수 있게 해줍니다.

3. 엑셀 파싱: 'xlsx' 라이브러리를 사용하여 엑셀 파일을 파싱합니다. 이 라이브러리는 엑셀 파일을 JSON 형식으로 변환해줍니다.

4. 테이블 렌더링: 파싱된 데이터를 기반으로 React 컴포넌트 내에서 테이블을 렌더링합니다.

🌵코드 분리 및 리팩토링

파일 업로드 컴포넌트와 데이터를 보여주는 테이블 컴포넌트를 나누면 다음과 같이 만들 수 있습니다.

// FileUpload.tsx
import React from 'react';
import * as XLSX from 'xlsx';

interface FileUploadProps {
  onFileUpload: (data: Record<string, string>[]) => void;
}

const FileUpload: React.FC<FileUploadProps> = ({onFileUpload}) => {
  const handleFileUpload = (e: React.ChangeEvent<HTMLInputElement>) => {
    const file = e.target.files?.[0];
    if (file) {
      const reader = new FileReader();
      reader.onload = (evt) => {
        const bstr = evt.target?.result as string;
        const wb = XLSX.read(bstr, {type: 'binary'});
        const wsname = wb.SheetNames[0];
        const ws = wb.Sheets[wsname];
        const data: Record<string, string>[] = XLSX.utils.sheet_to_json(ws);
        onFileUpload(data);
      };
      reader.readAsBinaryString(file);
    }
  };

  return <input type='file' onChange={handleFileUpload} />;
};

export default FileUpload;

// DataTable.tsx
import React from 'react';

interface DataTableProps {
  data: Record<string, string>[];
}

const DataTable: React.FC<DataTableProps> = ({data}) => {
  const tableHead = Array.from(data.reduce((acc, cur) => {
    Object.keys(cur).forEach(k => acc.add(k));
    return acc;
  }, new Set<string>()));

  return (
    <table>
      <thead>
      <tr>
        {tableHead.map((value) => (
          <td key={value}>{value}</td>
        ))}
      </tr>
      </thead>
      <tbody>
      {data.map((row, i) => (
        <tr key={i}>
          {tableHead.map((key) => (
            <td key={key}>{row[key] ?? ''}</td>
          ))}
        </tr>
      ))}
      </tbody>
    </table>
  );
};

export default DataTable;

// ExcelReader.tsx
import React, {useState} from 'react';
import FileUpload from './FileUpload';
import DataTable from './DataTable';

const ExcelReader: React.FC = () => {
  const [data, setData] = useState<Record<string, string>[]>([]);

  return (
    <div>
      <FileUpload onFileUpload={setData} />
      <DataTable data={data} />
    </div>
  );
};

export default ExcelReader;

코틀린은 자료형에 대해 명시적으로 선언할 수도 있고, 타입 추론을 통해 생략할 수도 있습니다.

코틀린의 자료형은 기본형과 참조형으로 구분할 수 있습니다. 기본형은 정수, 실수, 문자, 불리언 등의 원시 타입을 의미하며, 참조형은 배열, 컬렉션, 클래스, 인터페이스 등의 객체 타입을 의미합니다.

🚄배열 생성 함수

• arrayListOf는 수정 가능한 리스트를 생성하는 함수입니다. 내부적으로는 배열로 데이터를 저장하는 ArrayList 클래스를 사용합니다. arrayListOf 함수는 매개변수로 임의의 개수의 값을 받아서 리스트에 추가합니다. arrayListOf 함수로 생성된 리스트는 add, remove, set 등의 메소드로 요소를 추가하거나 삭제하거나 변경할 수 있습니다.
• listOf는 읽기 전용 리스트를 생성하는 함수입니다. listOf 함수는 매개변수로 임의의 개수의 값을 받아서 리스트에 추가합니다. listOf 함수로 생성된 리스트는 읽기 전용이기 때문에 요소를 추가하거나 삭제하거나 변경할 수 없습니다. 만약 수정 가능한 리스트를 생성하고 싶다면 mutableListOf 함수를 사용할 수 있습니다.
• arrayOf는 배열을 생성하고 초기화하는 함수입니다. arrayOf 함수는 매개변수로 임의의 개수의 값을 받아서 배열에 저장합니다. arrayOf 함수로 생성된 배열은 대괄호를 사용해서 인덱스로 요소에 접근하거나 변경할 수 있습니다. 배열의 크기는 생성 시에 결정되며, 요소를 추가하거나 삭제할 수 없습니다. 만약 배열의 크기가 정해지지 않은 경우에는 arrayOfNulls 함수를 사용할 수 있습니다.

fun main(args: Array<String>) {
    val arr: ArrayList<Int> = arrayListOf<Int>()
    arr.add(3)
    arr.add(5)
    arr.add(5)
    arr[1] = 4
    println(arr)
//    output: [3, 4, 5]

    val lis: List<Int> = listOf<Int>(244, 222, 111)
//    lis.add X 추가 불가
//    lis.set X 수정 불가
//    lis[2] = 55 X 수정 불가
    println(lis)
//    output: [233, 222, 111]

    val arra: Array<Int> = arrayOf<Int>(11, 11, 22)
//    arra.add 추가 불가
    arra[1] = 4
    println(arra[0])
    println(arra[1])
    println(arra[2])
    println(arra.size)
//    output: 11
//            4
//            22
//            3
}

코틀린에서 MutableList와 ArrayList는 둘 다 수정 가능한 리스트를 생성하는 함수입니다. 하지만 MutableList는 인터페이스이고, ArrayList는 클래스입니다1. MutableList는 ArrayList 외에도 다른 구현체를 가질 수 있습니다. 예를 들어, LinkedList도 MutableList의 구현체입니다2. ArrayList는 내부적으로 배열로 데이터를 저장하고, LinkedList는 노드로 데이터를 저장합니다3. 따라서 두 클래스는 추가, 삭제, 검색 등의 연산에 대한 성능 차이가 있습니다3.

MutableList와 ArrayList의 차이점을 요약하면 다음과 같습니다:

• MutableList는 인터페이스이고, ArrayList는 클래스입니다.
• MutableList는 ArrayList 외에도 다른 구현체를 가질 수 있습니다.
• ArrayList는 내부적으로 배열로 데이터를 저장하고, LinkedList는 노드로 데이터를 저장합니다.
• ArrayList와 LinkedList는 추가, 삭제, 검색 등의 연산에 대한 성능 차이가 있습니다.

fun main(args: Array<String>) {
    val arr: ArrayList<Int> = arrayListOf<Int>()
    arr.add(3)
    arr.add(5)
    arr.add(5)
    arr[1] = 4
    println(arr)
//    output: [3, 4, 5]
    val mutLis: MutableList<Int> = mutableListOf<Int>()
    mutLis.add(10)
    mutLis.add(9)
    mutLis.add(8)
    mutLis[1] = 0
    println(mutLis)
//    output: [10, 0, 8]
}

🛎코틀린 컬렉션 인터페이스

• 컬렉션은 List, Set, Map 등의 인터페이스로 표현되며, 각각 순서가 있는 원소의 집합, 중복이 없는 원소의 집합, 키와 값의 쌍의 집합을 나타냅니다.
• 컬렉션은 변경 가능한(mutable) 컬렉션과 변경 불가능한(immutable) 컬렉션으로 구분할 수 있습니다. 변경 가능한 컬렉션은 원소를 추가하거나 삭제하거나 수정할 수 있으며, 변경 불가능한 컬렉션은 한 번 생성된 후에는 원소를 변경할 수 없습니다.
• 컬렉션을 생성하는 방법에는 listOf, setOf, mapOf 등의 함수와 mutableListOf, mutableSetOf, mutableMapOf 등의 함수가 있습니다. 전자는 변경 불가능한 컬렉션을 생성하고, 후자는 변경 가능한 컬렉션을 생성합니다.

중요

insert할 때 SET Names utf4mb4가 되어 있도록 하기

브라우저에서는 iframe과 부모가 도메인이 다르다면 서로의 컨텐츠를 직접 조작할 수 없도록 막아 놨기 때문에 메세지를 통해 iframe과 부모 같의 정보를 교환할 수 있습니다.

✉️ iframe에서 부모로 메세지 보내기

• 부모 컨텐츠에서는 메세지 이벤트 리스너를 등록합니다.

  <script>
  window.addEventListener('message', e => {
      console.log(e.data);
  });
  </script>