BAEK'space

Claude Code for Front-end #5: 서브에이전트 실전 활용기

백씨네 — Wed, 7 Jan 2026 20:46:56 +0900

한국어 키워드로 각 분야 전문가를 호출하는 나만의 워크플로우

들어가며

이번 글에서는 제가 Claude Code의 서브에이전트 시스템을 실제로 어떻게 활용하고 있는지, 제 경험을 중심으로 풀어서 보여드리려고 합니다.

기본 개념은 공식 문서를 참고하되, 단순 설명에 그치지 않고 제가 실제 프로젝트에서 어떻게 적용했는지를 위주로 정리했습니다.

물론 이 방식이 정답은 아니고, 각자의 개발 환경에 맞게 가볍게 참고하시고 필요한 부분만 가져가시면 좋습니다.

1️⃣ Claude Code 에이전트 구조 이해하기

메인 에이전트와 서브에이전트의 관계

Claude Code를 사용하다 보면 "메인 에이전트"와 "서브에이전트"라는 용어를 마주하게 됩니다. 처음에는 이 둘의 차이가 명확하지 않아서 혼란스러울 수 있는데, 제 경험상 다음과 같이 이해하시면 도움이 됩니다:

메인 에이전트 (Main Agent):

여러분이 대화하는 "바로 그 Claude"
전체 대화 흐름을 관리하고 조율하는 역할
프로젝트 컨텍스트를 계속 유지하며 대화

서브에이전트 (Sub-Agent):

특정 작업을 위해 잠깐 호출되는 전문가
독립적인 컨텍스트에서 작업 수행
작업 완료 후 결과를 메인 에이전트에게 전달하고 종료

실제로는 어떻게 작동할까?

제가 겪은 실제 상황으로 설명드리겠습니다:

나: "이 코드 성능 최적화해줘"

[메인 에이전트가 판단]
→ 성능 최적화는 performance-engineer 에이전트의 전문 분야
→ Task 도구로 performance-engineer 호출
→ 작업 결과를 받아서 나에게 전달

나: "고마워, 그럼 테스트도 작성해줘"

[메인 에이전트가 다시 판단]
→ 테스트 작성은 quality-engineer 에이전트의 전문 분야
→ Task 도구로 quality-engineer 호출
→ 작업 결과를 받아서 나에게 전달

이렇게 메인 에이전트는 오케스트라 지휘자처럼 전체를 조율하고, 서브에이전트들은 각 파트의 전문 연주자처럼 특정 작업을 수행합니다.

왜 이런 구조가 필요한가?

컨텍스트 관리:

하나의 대화에 모든 작업 내용을 담으면 컨텍스트 창이 금방 찹니다
서브에이전트가 자체 컨텍스트에서 작업하면 메인 대화가 깨끗하게 유지됩니다

전문성 향상:

각 에이전트는 특정 도메인에만 집중하므로 더 정확한 결과를 냅니다
성능 최적화 전문가와 보안 검토 전문가는 다른 관점을 가집니다

재사용 가능:

한 번 만든 에이전트는 모든 프로젝트에서 활용 가능
팀원과 공유하여 일관된 품질 유지

2️⃣ 서브에이전트의 종류 (공식 문서 기반)

이 섹션은 Claude Code 공식 문서를 기반으로 작성되었습니다.

내장 에이전트 (Built-in Agents)

Claude Code에 기본으로 탑재된 에이전트는 다음 4개입니다:

/agents 출력:

Built-in agents (always available)
  general-purpose · sonnet    # 범용 작업 처리
  statusline-setup · sonnet   # 상태바 설정
  output-style-setup · sonnet # 출력 스타일 설정
  Explore · haiku             # 빠른 코드베이스 탐색

확인 방법:

/agents

서브에이전트 우선순위

같은 이름의 에이전트가 여러 곳에 있을 때 적용되는 우선순위:

프로젝트 > CLI > 사용자 > 플러그인 > 내장
(.claude/agents/) > (--agents) > (~/.claude/agents/) > (플러그인) > (Built-in)

실무 팁:

프로젝트별 특화 에이전트는 .claude/agents/에 두세요
범용적으로 쓰는 에이전트는 ~/.claude/agents/에 두세요

3️⃣ 서브에이전트 생성 방법 (공식 문서)

방법 1: /agents 명령어 (권장)

/agents

생성 단계:

"Create New Agent" 선택
User-level 또는 Project-level 선택
Claude가 초안 생성 (권장)
도구 권한 선택 (체크박스 UI)
e 키로 편집기에서 프롬프트 수정
저장

제 경험: Claude가 생성한 초안을 기반으로 커스터마이징하는 것이 처음부터 작성하는 것보다 훨씬 빠르고 효과적입니다.

방법 2: 수동 파일 생성

파일 형식 (~/.claude/agents/agent-name.md):

---
name: agent-name
description: 에이전트가 언제 호출되어야 하는지 설명
tools: Read, Grep, Glob, Bash # 선택사항
model: sonnet # 또는 inherit, opus, haiku
---

시스템 프롬프트가 여기에 들어갑니다.

에이전트의 역할, 능력, 접근 방식을 명확히 정의하세요.

필드 설명:

필드필수설명

name	✅	소문자와 하이픈만 사용
description	✅	자연어로 목적 설명
tools	❌	생략 시 모든 도구 상속
model	❌	sonnet, opus, haiku, inherit

자세한 내용은 공식 문서를 참고하세요.

4️⃣ 제가 사용하는 에이전트 (개인 경험)

이 섹션부터는 제 개인적인 경험과 의견입니다.

현재 설치된 에이전트

제 ~/.claude/agents/ 디렉토리에는 14개의 에이전트가 있습니다:

backend-architect.md        # 백엔드 아키텍처 설계
devops-architect.md         # 배포 및 인프라
frontend-architect.md       # 프론트엔드 아키텍처
learning-guide.md           # 개념 설명 및 학습
performance-engineer.md     # 성능 최적화
python-expert.md            # Python 전문
quality-engineer.md         # 테스트 작성
refactoring-expert.md       # 리팩토링
requirements-analyst.md     # 요구사항 분석
root-cause-analyst.md       # 근본 원인 분석
security-engineer.md        # 보안 검토
socratic-mentor.md          # 소크라테스식 멘토링
system-architect.md         # 시스템 아키텍처
technical-writer.md         # 기술 문서 작성

주로 사용하는 에이전트 예시

root-cause-analyst.md - 가장 자주 쓰는 에이전트:

---
name: root-cause-analyst
description: 근본 원인 분석 전문가. 버그나 에러 발생 시 체계적으로 원인을 파악합니다.
tools: Read, Grep, Glob, Bash
model: sonnet
---

당신은 시스템적 사고를 기반으로 문제의 근본 원인을 파악하는 전문가입니다.

분석 프로세스:

1. 증상 수집 및 재현
2. 가설 수립
3. 증거 수집
4. 원인 검증
5. 해결 방안 제시

표면적 증상이 아닌 근본 원인을 찾아내는 것이 목표입니다.

사용 예시:

나: "API 응답이 느려"
→ root-cause-analyst가 DB 쿼리, 네트워크, 캐싱 등 체계적으로 분석
→ "N+1 쿼리 문제로 확인됨" 결과 전달

에이전트를 구하는 곳

제가 에이전트 템플릿을 구하는 사이트는 다음과 같습니다:

SuperClaude_Framework - Claude Code를 체계적인 개발 플랫폼으로 변환하는 강력한 메타프로그래밍 프레임워크
AI Template - 다양한 분야별 에이전트 템플릿, 실제 예제/레시피 포함
GitHub에서 claude code agents 키워드로 최신 템플릿 탐색
커뮤니티(예: Reddit, Discord)에서 사용자 공유 목록 활용

주의: 다운로드한 에이전트는 반드시 검토 후 사용하세요. 시스템 프롬프트가 예상과 다를 수 있습니다.

5️⃣ 한국어 트리거 시스템 (제 워크플로우)

이 부분은 제가 사용하는 방식이며, 정답은 아닙니다.

CLAUDE.md 설정 방식

제 경우 ~/.claude/CLAUDE.md에 다음과 같이 설정했습니다:

#   [CRITICAL] 한국어 에이전트 자동 실행 규칙

**중요**: 다음 키워드 감지 시 **즉시 Task 도구 호출**

##   키워드별 매핑

###   분석 요청

| 키워드             | 실행 도구                                | 예시               |
| ------------------ | ---------------------------------------- | ------------------ |
| "분석해줘", "봐줘" | Task(subagent_type="root-cause-analyst") | "이 코드 분석해줘" |
| "왜 안돼?", "원인" | Task(subagent_type="root-cause-analyst") | "왜 느려?"         |

###  ️ 개발 요청

| 키워드         | 실행 도구                                  | 예시                   |
| -------------- | ------------------------------------------ | ---------------------- |
| "리팩토링해줘" | Task(subagent_type="refactoring-expert")   | "이 코드 리팩토링해줘" |
| "최적화해줘"   | Task(subagent_type="performance-engineer") | "성능 최적화해줘"      |
| "테스트 작성"  | Task(subagent_type="quality-engineer")     | "테스트 작성해줘"      |

###   코드 품질

| 키워드      | 실행 도구                               | 예시               |
| ----------- | --------------------------------------- | ------------------ |
| "리뷰해줘"  | Task(subagent_type="code-reviewer")     | "이 코드 리뷰해줘" |
| "보안 체크" | Task(subagent_type="security-engineer") | "보안 체크해줘"    |

작동 원리

중요: 이것은 Claude Code의 내장 기능이 아닙니다.

사용자: "이 코드 분석해줘"
Claude가 시스템 프롬프트로 CLAUDE.md 내용을 인식
[CRITICAL] 규칙에서 "분석해줘" 키워드 발견
Task 도구로 root-cause-analyst 호출
결과 전달

한계:

Claude가 100% 규칙을 따르는 것은 아님 (확률적 모델)
복잡한 문장에서는 키워드 감지 실패 가능
명시적 호출이 더 확실함

명시적 호출 예시

규칙에 의존하지 않고 직접 호출하는 방법:

> root-cause-analyst 서브에이전트를 사용하여 이 코드를 분석해줘
> performance-engineer 에이전트로 최적화해줘
> quality-engineer로 테스트를 작성해줘

이 방식이 더 확실하고 안정적입니다.

6️⃣ 서브에이전트 활용 방향성

1. 단일 책임 원칙으로 나누기

제 경험상 에이전트는 하나의 명확한 목적만 가질 때 가장 효과적입니다:

❌ "모든 것을 하는 슈퍼 에이전트" 하나
✅ 작업별로 분리된 여러 에이전트

실제 사례:

초기: super-developer.md (코드 작성, 리뷰, 테스트, 배포 모두 담당)
→ 성능이 일관적이지 않음
→ 때로는 리뷰만 하고, 때로는 테스트를 건너뜀

개선:
- code-reviewer.md (리뷰 전문)
- quality-engineer.md (테스트 전문)
- refactoring-expert.md (리팩토링 전문)
→ 각 에이전트가 자신의 역할에 집중
→ 결과의 일관성과 품질 향상

2. 에이전트 체이닝 전략

여러 에이전트를 순차적으로 활용하는 방법:

예시 워크플로우:

1단계: requirements-analyst
   "이 기능 요구사항 정리해줘"
   → 기능 명세서 생성

2단계: frontend-architect
   "이 명세서 기반으로 컴포넌트 구조 설계해줘"
   → 컴포넌트 설계도 생성

3단계: quality-engineer
   "이 설계에 맞는 테스트 케이스 작성해줘"
   → 테스트 코드 생성

4단계: security-engineer
   "보안 취약점 검토해줘"
   → 보안 리포트 생성

각 단계의 출력물이 다음 단계의 입력이 되는 구조입니다.

3. 프로젝트별 특화 에이전트

프로젝트마다 다른 에이전트를 활용하는 것이 효과적입니다:

Next.js 프로젝트 (.claude/agents/nextjs-expert.md):

---
name: nextjs-expert
description: Next.js App Router 전문가. 페이지/API 생성 및 최적화에 사용하세요.
tools: Read, Edit, Write, Bash
model: inherit
---

당신은 Next.js 15 App Router 전문가입니다.

App Router 패턴:

-   서버 컴포넌트 우선 사용
-   'use client' 최소화
-   metadata 자동 생성
-   동적 라우팅 ([slug], [...slug])

성능 최적화:

-   next/image 사용
-   Suspense + Streaming
-   Static Generation 활용

모든 코드는 TypeScript + Tailwind CSS로 작성합니다.

Python 프로젝트 (.claude/agents/python-expert.md):

---
name: python-expert
description: Python 코드 작성 및 최적화 전문가
tools: Read, Edit, Write, Bash
model: sonnet
---

당신은 Python 모범 사례 전문가입니다.

코드 스타일:

-   PEP 8 준수
-   Type hints 적극 활용
-   Docstring 작성

성능 최적화:

-   List comprehension 활용
-   Generator 패턴 사용
-   asyncio for I/O bound tasks

7️⃣ 실전 팁과 트러블슈팅

Claude 생성 초안 활용

❌ 처음부터 수동으로 작성
✅ /agents → Generate with Claude → 커스터마이징

Claude가 생성한 초안을 기반으로 수정하는 것이 훨씬 빠릅니다.

description 필드 상세히 작성

# ❌ 일반적인 설명

description: "코드 리뷰를 수행합니다"

# ✅ 적극적 사용 유도

description: "코드 리뷰 전문가. 코드 변경 후 적극적으로 사용하세요."

description 필드를 상세히 작성하면 Claude가 적절한 타이밍에 에이전트를 제안합니다.

도구 권한 제한

# ❌ 모든 도구 허용 (tools 필드 생략)

---

## name: code-reviewer

# ✅ 필요한 도구만 허용

---

name: code-reviewer
tools: Read, Grep, Glob, Bash

---

필요한 도구만 허용하면 에이전트가 집중된 작업을 수행합니다.

성능 트레이드오프 인식

지연시간:

서브에이전트는 매번 깨끗한 상태로 시작
컨텍스트 수집에 약간의 지연 발생

제 경험:

간단한 작업: 메인 대화에서 직접 처리가 더 빠름
복잡한 작업: 서브에이전트 활용이 효과적

트러블슈팅: 에이전트가 호출되지 않을 때

제가 겪은 문제:

CLAUDE.md의 [CRITICAL] 표시 누락
키워드 오타
Claude가 규칙을 무시함

해결 방법:

# CLAUDE.md 확인
cat ~/.claude/CLAUDE.md | head -n 20

# [CRITICAL] 표시 확인
grep -n "CRITICAL" ~/.claude/CLAUDE.md

대안: 명시적으로 에이전트 이름 호출

> root-cause-analyst 에이전트를 사용해줘

트러블슈팅: 에이전트 목록이 안 보일 때

원인: 파일이 올바른 위치에 없음

해결:

# 디렉토리 확인
ls -la ~/.claude/agents/

# 파일 확장자 확인 (.md 필수)
ls ~/.claude/agents/*.md

# YAML frontmatter 검증
head -n 10 ~/.claude/agents/code-reviewer.md

마무리

제 경험 요약

효과적이었던 것:

Claude 생성 초안 → 커스터마이징
작업별로 분리된 에이전트 (단일 책임 원칙)
명시적 호출 (키워드 트리거보다 안정적)
프로젝트별 특화 에이전트 (.claude/agents/)
에이전트 체이닝으로 복잡한 워크플로우 구성

덜 효과적이었던 것:

만능 슈퍼 에이전트 (역할이 불명확해짐)
복잡한 한국어 트리거 규칙 (간단한 문장만 작동)
모든 도구에 대한 무제한 권한 (집중력 저하)

Claude Code for Front-end #4: Claude Code를 200% 활용하는 법

백씨네 — Wed, 7 Jan 2026 20:45:20 +0900

AI와 대화하는 방법이 생산성을 결정한다

들어가며

Claude Code 설치했다고 끝난 게 아닙니다. 진짜 실력은 어떻게 말을 거는가에서 갈립니다.

같은 도구를 써도 누군가는 1시간 걸릴 작업을 10분에 끝내고, 누군가는 여전히 "왜 안 되지?"를 반복합니다. 차이는 단순합니다. 프롬프트를 어떻게 쓰느냐.

오늘은 매일 쓰는 실전 프롬프트 패턴을 공개합니다. 복붙해서 바로 쓸 수 있는 것들만 모았습니다.

프롬프트의 기본 구조

모든 좋은 프롬프트는 이 4요소 구조를 따릅니다:

[컨텍스트] + [작업] + [제약조건] + [출력 형식]

실전 예시:

컨텍스트: Next.js App Router 프로젝트입니다.
작업: 사용자 프로필 페이지를 생성하세요.
제약조건: TypeScript를 사용하고, Tailwind CSS로 스타일링하세요.
출력 형식: page.tsx와 관련 컴포넌트를 별도 파일로 분리하세요.

버전 호환성: Next.js 13+ 버전은 모두 App Router를 지원합니다. 버전 번호를 생략하면 Claude가 프로젝트 환경에 맞게 대응합니다.

이 구조만 지켜도 응답 품질이 2배 이상 향상됩니다.

1️⃣ "분석해줘" vs "성능 병목 3개 찾아서 개선안까지 제시해줘"

❌ 애매한 요청

"이 컴포넌트 좀 봐줘"
"코드 분석 좀"
"최적화해줘"

Claude의 마음: "뭘 봐드릴까요...? 뭘 분석할까요...? 어떻게 최적화할까요...?"

✅ 구체적인 요청

"상품 목록 컴포넌트에서 1000개 항목 렌더링 시 느린 이유 찾고,
가상화 적용 전후 비교 코드 작성해줘"

또는:

"장바구니 페이지의 리렌더링 이슈 분석해서:
1. 불필요한 리렌더링 지점 표시
2. useMemo/useCallback 적용 위치
3. 적용 후 예상 성능 개선율"

결과 차이: 5분 vs 30초 + 정확도 3배

2️⃣ 컨텍스트는 AI의 연료입니다

❌ 컨텍스트 없는 요청

"API 호출 에러 나는데 고쳐줘"

Claude: "어떤 API요? 어떤 에러요? 어디서요? "

✅ 컨텍스트 충분한 요청

"사용자 인증 API 호출에서 401 에러 발생.

위치:
- 파일: api/auth/login.ts
- 함수: loginUser

현재 상황:
- POST /api/auth/login 호출
- 로컬에서는 정상, 프로덕션에서만 401
- 요청 헤더: Content-Type: application/json
- 응답: {error: 'Unauthorized', code: 'AUTH_FAILED'}

확인 필요:
1. CORS 설정 이슈
2. 토큰 전달 방식
3. 환경변수 차이"

프롬프트 작성 전 다음을 확인하세요:

[ ] 파일 경로가 명시되어 있는가?
[ ] 에러 메시지가 원문 그대로 포함되어 있는가?
[ ] 환경 정보(로컬/프로덕션, 브라우저 등)가 있는가?
[ ] 이미 시도한 해결책이 언급되어 있는가?

3️⃣ 단계별 실행 패턴

복잡한 작업은 한 번에 다 시키지 마세요. 단계별로 쪼개면 정확도가 올라갑니다.

예시: 새 기능 구현 (즐겨찾기 기능)

1단계: 요구사항 정리

"게시글 즐겨찾기 기능 요구사항 정리해줘:
- 사용자가 게시글을 즐겨찾기 추가/제거
- 즐겨찾기 목록 조회
- 실시간 상태 반영"

2단계: API 설계

"위 요구사항 기반으로 API 명세 작성:
- RESTful 엔드포인트
- 요청/응답 스키마
- 에러 케이스"

3단계: 상태 관리

"TanStack Query 훅 구현:
- useFavoritePost (mutation)
- useFavoritePosts (query)
- Optimistic update 포함"

라이브러리 명칭: React Query는 v4부터 TanStack Query로 브랜딩 변경되었습니다. 두 이름 모두 사용 가능합니다.

4단계: UI 구현

"FavoriteButton 컴포넌트 구현:
- 로딩/성공/실패 상태
- 토스트 메시지
- 접근성 고려"

장점: 각 단계마다 검토하고 피드백 가능. 수정 비용 최소화.

4️⃣ "왜"를 물어보는 습관

코드만 받지 말고, 이유를 물어보세요. 학습 효과가 10배입니다.

"useCallback을 여기 쓴 이유는?"

"왜 상태를 Context로 올렸어?"

"이 최적화가 실제로 효과 있는 케이스는?"

"다른 방법도 있었을 텐데 왜 이 방법을 선택했어?"

Claude는 답하면서 동시에 트레이드오프, 대안, 주의사항까지 설명해줍니다.

5️⃣ 비교 요청 패턴

선택지가 있을 때 "이게 나아?" 대신 "A와 B 비교해줘"

❌ 막연한 질문

"이 라이브러리 좋아? 저 라이브러리 좋아?"

✅ 비교 요청

"프로젝트에 적합한 상태 관리 라이브러리 비교:

프로젝트 특성:
- React 18 기반 웹 애플리케이션
- 전역 상태: 사용자 인증, UI 테마
- SSR/SSG 필요

비교 기준:
1. 서버 사이드 렌더링 호환성
2. 학습 곡선
3. 번들 사이즈
4. DevTools 지원
5. 커뮤니티 및 생태계

각 기준별 점수와 최종 추천 + 이유"

결과: 명확한 의사결정 근거 확보

6️⃣ 에러 해결 골든 템플릿

에러 발생 시 이 템플릿을 사용하세요:

"[에러 메시지 원문 그대로]

발생 위치:
- 파일: [경로]
- 라인: [번호]
- 함수/컴포넌트: [이름]

재현 방법:
1. [단계1]
2. [단계2]
3. [에러 발생]

시도한 것:
- [시도1] → [결과]
- [시도2] → [결과]

의심 지점:
- [가설1]
- [가설2]

원인 분석 + 해결 방법 제시해줘"

실전 예시

"TypeError: Cannot read property 'map' of undefined

발생 위치:
- 파일: components/item-list.tsx
- 라인: 42
- 컴포넌트: ItemList

재현 방법:
1. 목록 페이지 접속
2. 카테고리 필터 선택
3. 로딩 후 에러 발생

시도한 것:
- items가 undefined인지 체크 → 여전히 에러
- optional chaining 사용 → 화면 깜빡임 발생

의심 지점:
- TanStack Query에서 초기 data가 undefined
- 조건부 렌더링 타이밍 이슈

원인 분석 + 해결 방법 제시해줘"

7️⃣ 리팩토링 요청의 기술

❌ 모호한 요청

"이 코드 리팩토링해줘"

✅ 명확한 목표

"사용자 프로필 컴포넌트 리팩토링:

현재 문제:
- 300줄 넘는 단일 컴포넌트
- useEffect 5개 중첩
- Props drilling 3단계

목표:
1. 컴포넌트 분리 (UI/로직)
2. Custom Hook으로 로직 추출
3. Props drilling → Context API
4. 테스트 가능한 구조

단, 기존 API 호출 로직은 유지
(데이터 fetch 및 mutation 훅)"

리팩토링 체크리스트

[ ] 현재 문제점이 구체적으로 명시되어 있는가?
[ ] 리팩토링 목표가 명확한가?
[ ] 유지해야 할 것이 명시되어 있는가?
[ ] 파일 분리 계획이 있는가?

8️⃣ 점진적 개선 패턴

완벽한 코드를 한 번에 요구하지 마세요. 단계별로 개선하세요.

1차: "기본 기능 구현 (빠르게)"
2차: "타입 안정성 강화"
3차: "에러 핸들링 추가"
4차: "성능 최적화"
5차: "접근성 개선"

각 단계마다 테스트하고 다음으로 넘어가면 안정적입니다.

실전 적용:

// 1차 요청
"로그인 폼 기본 기능만 빠르게 구현:
- 이메일/비밀번호 입력
- 제출 시 API 호출
- 성공 시 대시보드 이동"

// 2차 요청 (1차 완료 후)
"위 코드에 React Hook Form + Zod 추가:
- 이메일 형식 검증
- 비밀번호 최소 8자
- 실시간 에러 표시"

// 3차 요청 (2차 완료 후)
"에러 핸들링 강화:
- 네트워크 에러
- 401/403/500 응답 처리
- 사용자 친화적 메시지"

9️⃣ 학습 모드 활성화

"React Query의 staleTime vs cacheTime 차이를
초등학생도 이해할 수 있게 설명 +
실제 사용 예시 3가지"

"Next.js App Router의 Server Component가
왜 빠른지 내부 동작 원리부터 차근차근"

"useMemo가 오히려 성능 악화시키는 케이스
3가지 + 각각 해결법"

팁: "왜", "어떻게", "언제"를 조합하면 깊이 있는 답변이 나옵니다.

협업 시뮬레이션 - 코드 리뷰 요청

Claude를 페어 프로그래밍 파트너로 활용하세요.

"내가 작성한 이 코드 리뷰해줘.
시니어 개발자 관점에서:

1. 잠재적 버그
2. 성능 이슈
3. 가독성 문제
4. 보안 취약점
5. 개선 제안

각 항목마다 심각도(상/중/하) 표시하고
우선순위 순서로 정렬해줘"

결과: 실제 코드 리뷰처럼 건설적인 피드백을 받습니다.

실전 활용 가이드

템플릿 모음

복붙해서 바로 쓰는 3가지 핵심 템플릿입니다.

버그 수정

**[버그 제목]**

증상: [사용자가 겪는 문제]
재현 조건: [발생 상황]
에러 로그:

[스택 트레이스]

원인 분석 → 수정 → 테스트 케이스 작성

기능 구현

**[기능명] 구현**

사용자 스토리: [역할]로서 [목적]을 위해 [기능]을 원한다

수용 조건:

-   [ ] [조건1]
-   [ ] [조건2]

기술 제약: [제약사항]

→ 단계별 구현 계획 먼저 세워줘

성능 최적화

**성능 최적화: [대상]**

현재 지표: LCP [수치] / FID [수치] / 번들 [크기]
목표: LCP < 2.5s / FID < 100ms / 번들 -30%

→ 병목 분석 → 개선안 → 예상 효과

금지어 목록

이런 표현은 피하세요:

❌ 주관적 표현✅ 객관적 기준

"좀 더 좋게"	"응답 속도 200ms 이하로"
"깔끔하게"	"함수당 20줄 이하, 중첩 3단계 이하"
"잘"	"TypeScript strict 모드 통과하게"
"대충"	"MVP 수준으로 (에러 핸들링 제외)"

원칙: 주관적 단어는 객관적 기준으로 바꾸세요.

고급 프롬프트 기법

체인 프롬프트 (Multi-step Prompts)

복잡한 작업은 여러 단계로 분할합니다:

1단계: 분석

"현재 인증 시스템의 구조를 분석하고 다음을 파악하세요:
1. 사용 중인 인증 방식
2. 토큰 저장 위치와 방식
3. 보안 취약점"

2단계: 설계

"분석 결과를 바탕으로 JWT 기반 인증 시스템의 구조를 설계하세요:
1. 파일 구조
2. API 엔드포인트
3. 상태 관리 방식"

3단계: 구현

"설계한 구조대로 인증 시스템을 구현하세요.
먼저 src/lib/auth/types.ts부터 시작하세요."

출력 형식 제어

변경 전후 비교 요청:

"리팩토링 전후 코드 나란히 보여줘 (diff 형식)

### Before
```typescript
[기존 코드]

문제점:
- [문제 1]
- [문제 2]
```
### After
```typescript
[개선된 코드]
```

개선점:
- [개선 1]
- [개선 2]"

실전 꿀팁 3가지

1. 파일 경로는 항상 명시

✅ "src/app/(pages)/products/[id]/page.tsx 수정" 

❌ "페이지 파일 수정"

Claude가 컨텍스트를 정확히 파악합니다.

2. 에러 메시지는 원문 그대로

번역하거나 요약하지 마세요. 복붙이 답입니다.

❌ "타입 에러 나요" 
✅ "Type 'string | undefined' is not assignable to type 'string'"

3. 우선순위 명시

"다음 순서로 진행:
1순위: 보안 이슈 수정
2순위: 성능 최적화
3순위: 코드 정리"

프롬프트 품질 체크리스트

효과적인 프롬프트를 작성했는지 확인하세요:

명확성

[ ] 작업 내용이 구체적으로 명시되어 있는가?
[ ] 기술 스택과 도구가 명시되어 있는가?
[ ] 파일 경로가 정확한가?

완결성

[ ] 필요한 모든 컨텍스트를 제공했는가?
[ ] 제약조건이 명시되어 있는가?
[ ] 예상 출력 형식이 정의되어 있는가?

실행가능성

[ ] 작업이 명확한 단계로 나뉘어 있는가?
[ ] 각 단계가 검증 가능한가?
[ ] 성공 기준이 정의되어 있는가?

효율성

[ ] 불필요한 정보가 없는가?
[ ] 우선순위가 명확한가?
[ ] 예시 코드가 포함되어 있는가?

마무리: 프롬프트는 대화입니다

Claude Code는 명령을 실행하는 도구가 아니라 함께 문제를 푸는 동료입니다.

핵심 원칙

구체적이고 명확하게 - 모호함을 제거하고 정확한 요구사항 전달
구조화된 형식 사용 - 일관된 템플릿으로 정보 전달
충분한 컨텍스트 제공 - 프로젝트 환경과 현재 상태 공유
단계별 분할 - 복잡한 작업을 관리 가능한 단위로 분해
검증 가능한 출력 - 성공 기준과 테스트 방법 명시

실천 가이드

명령하지 말고 협의하세요
결과만 받지 말고 이유를 물어보세요
한 번에 끝내려 하지 말고 단계별로 진행하세요

제가 오늘 공유한 패턴들, 내일 당장 써보세요. 일주일만 써봐도 체감합니다.

Claude Code, 이제 제대로 부려먹을 시간입니다.

Claude Code for Front-end #3: MCP 서버로 Claude Code 능력 확장하기

백씨네 — Wed, 7 Jan 2026 20:43:15 +0900

프로덕션 레벨 개발을 위한 7가지 필수 MCP 서버 활용법

1️⃣ 들어가며

Claude Code를 쓰면서 이런 생각 해보신 적 있나요?

"음... React 공식 문서 찾아보고 돌아와야겠네"

"이 UI 컴포넌트 만드는 데 시간이 너무 오래 걸리는데..."

"코드베이스가 너무 커서 뭐가 어디 있는지 찾기도 힘들어"

저도 그랬습니다. Claude Code는 분명 강력한 도구인데, 뭔가 2% 부족한 느낌이었죠. 그 2%를 채워주는 게 바로 MCP 서버입니다.

실제로 저는 7개의 MCP 서버를 프로젝트에 도입한 후 개발 생산성이 3배 이상 향상되었습니다. 이 글에서는 그 경험을 바탕으로 실전에서 검증한 MCP 서버들과 활용법을 공유하고자 합니다.

2️⃣ MCP란 무엇인가?

기본 개념

MCP(Model Context Protocol)는 AI 모델과 외부 시스템 간 표준화된 통신 프로토콜입니다. Claude Code에 새로운 능력을 부여하는 플러그인 시스템으로 이해할 수 있습니다.

아키텍처 구조

MCP는 클라이언트-서버 구조로 동작하며, Claude Code가 클라이언트 역할을 수행합니다.

핵심 구성 요소:

Tools: 실행 가능한 함수 인터페이스
- 명확한 입력 파라미터 스키마 정의
- 구조화된 결과 반환
- 에러 처리 및 재시도 로직 포함
Resources: 외부 데이터 소스 접근
- 파일 시스템, 데이터베이스, API 엔드포인트
- 읽기/쓰기 권한 설정
- 캐싱 및 동기화 전략
Prompts: 재사용 가능한 프롬프트 템플릿
- 파라미터화된 구조
- 컨텍스트 주입 및 변수 치환

3️⃣ MCP 서버 설정 가이드

설정 파일 위치

Claude Code의 설정 파일은 기본적으로 프로젝트의 .claude 디렉토리에 있습니다.

하지만 2편에서와 같이 프로젝트에서만 사용하는 MCP가 아닌 전역적으로 사용하는 MCP는 ~/.claude.json 파일에 있습니다.

아래는 mcp를 세팅하는 파일의 예시입니다.

기본 설정 구조

// mcp.json 또는 ~/.claude.json
{
    "mcpServers": {
        "context7": {
            "command": "npx",
            "args": ["-y", "@upstash/context7-mcp@latest"]
        },
        "sequential-thinking": {
            "command": "npx",
            "args": ["-y", "@modelcontextprotocol/server-sequential-thinking"]
        },
        "magic": {
            "type": "stdio",
            "command": "npx",
            "args": ["@21st-dev/magic"],
            "env": {
                "TWENTYFIRST_API_KEY": ""
            }
        },
        "playwright": {
            "command": "npx",
            "args": ["@playwright/mcp@latest"]
        },
        "serena": {
            "command": "uvx",
            "args": ["--from", "git+https://github.com/oraios/serena", "serena", "start-mcp-server"]
        },
        "notion": {
            "type": "http",
            "url": "<https://mcp.notion.com/mcp>"
        },
        "figma": {
            "type": "http",
            "url": "<https://mcp.figma.com/mcp>"
        }
    }
}

4️⃣ 실전 MCP 서버 7종 실전 가이드

설치 방법 2가지 중 하나를 선택하여 설치합니다.
설치 방법은 각 서버의 공식 문서를 참고하면 더 자세한 내용을 확인할 수 있습니다.

1. Sequential-Thinking - 체계적 사고 엔진

복잡한 문제를 단계별로 분석하고 논리적으로 해결책을 도출해야 할 때, Sequential-Thinking MCP는 Claude의 사고 과정을 체계화하는 데 도움을 줍니다.

주요 기능

단계별 문제 분해: 복잡한 문제를 작은 단위로 나누어 순차적으로 해결
가설 검증: 여러 가능성을 검토하고 최적의 해결책 도출
사고 과정 추적: 각 단계의 추론 과정을 투명하게 공개

실전 활용

복잡한 버그 디버깅:

"이 React 컴포넌트에서 무한 리렌더링이 발생하는 원인을 단계별로 분석해줘"

Sequential-Thinking이 수행할 수 있는 분석 예시:

컴포넌트 의존성 그래프 분석
useEffect 의존성 배열 검토
상태 업데이트 패턴 확인
부모-자식 컴포넌트 간 props 전달 추적
최종 원인 특정 및 해결책 제시

아키텍처 설계:

"마이크로서비스 아키텍처로 전환하기 위한 단계별 마이그레이션 전략을 수립해줘"

설정 방법:

claude mcp add sequential-thinking npx @modelcontextprotocol/server-sequential-thinking

"sequential-thinking": {
  "command": "npx",
  "args": ["-y", "@modelcontextprotocol/server-sequential-thinking"]
},

2. Magic - UI 컴포넌트 생성 마법사

수천 개의 검증된 UI 패턴을 기반으로 프로덕션 레벨의 컴포넌트 생성을 지원합니다. 21st.dev의 방대한 컴포넌트 라이브러리를 활용합니다.

주요 기능

컴포넌트 생성: /ui 명령으로 즉시 UI 컴포넌트 생성
디자인 시스템 통합: 기존 디자인 시스템과 자연스럽게 통합
접근성 준수: WCAG 2.1 AA 기준 자동 적용
반응형 설계: 모든 디바이스에 최적화된 레이아웃

실전 활용

복잡한 폼 생성:

"/ui 다단계 회원가입 폼 with 유효성 검사"

생성되는 컴포넌트:

const MultiStepForm = () => {
    const [currentStep, setCurrentStep] = useState(0)
    const [formData, setFormData] = useState({
        // 구조화된 폼 데이터
    })

    // 유효성 검사 로직
    // 단계별 네비게이션
    // 접근성 속성 자동 적용
    // 에러 핸들링
}

대시보드 위젯:

"/ui 실시간 매출 차트 대시보드 카드"

설정 방법:

npx @21st-dev/cli@latest install <client> --api-key <key>

"magic": {
    "type": "stdio",
    "command": "npx",
    "args": ["@21st-dev/magic"],
    "env": {
        "TWENTYFIRST_API_KEY": ""
    }
},

3. Context7 - 최신 문서 실시간 참조

프레임워크와 라이브러리는 빠르게 변화합니다. Context7은 항상 최신 공식 문서를 참조하여 정확한 코드를 생성하는 데 도움을 줍니다.

주요 기능

실시간 문서 조회: 공식 문서의 최신 버전 자동 참조
버전별 API 지원: 특정 버전에 맞는 정확한 구현
마이그레이션 가이드: 버전 업그레이드 시 변경사항 안내

실전 활용

Next.js 15 최신 기능 활용:

"Next.js 15의 새로운 Partial Prerendering을 구현해줘"

Context7이 공식 문서를 참조하여:

최신 API 사용법 확인
Breaking changes 체크
Best practices 적용

React 19 신기능:

"React 19의 use() 훅을 활용한 데이터 페칭 구현"

설정 방법

claude mcp add context7 -- npx -y @upstash/context7-mcp

"context7": {
    "command": "npx",
    "args": ["-y", "@upstash/context7-mcp@latest"]
},

4. Serena - 프로젝트 메모리 시스템

대규모 코드베이스를 효과적으로 이해하고, 프로젝트 컨텍스트를 세션 간에 유지합니다. 심볼 수준의 코드 분석이 가능합니다.

주요 기능

심볼 탐색: 함수, 클래스, 변수를 정확하게 찾고 분석
프로젝트 메모리: 아키텍처 결정사항, 코딩 컨벤션 저장
의존성 추적: 코드 변경 시 영향받는 부분 자동 감지
리팩토링 지원: 안전한 심볼 이름 변경 및 이동

실전 활용

프로젝트 온보딩:

"/sc:load 프로젝트 구조와 주요 패턴을 분석해줘"

Serena가 수행하는 작업:

프로젝트 구조 스캔
주요 패턴 식별
코딩 컨벤션 추출
메모리에 저장

심볼 리팩토링 전체 예시:

Before:

// utils/api.ts
export function getUserData(id: string) {
    return fetch(`/api/users/${id}`)
}

// components/Profile.tsx
import { getUserData } from '@/utils/api'

export default function Profile({ userId }: { userId: string }) {
    const data = await getUserData(userId)
    return <div>{data.name}</div>
}

// components/Settings.tsx
import { getUserData } from '@/utils/api'

export default function Settings({ currentId }: { currentId: string }) {
    const user = await getUserData(currentId)
    return <div>{user.email}</div>
}

프롬프트:

"getUserData 함수를 fetchUserProfile로 모든 참조와 함께 변경해줘"

After (Serena 자동 리팩토링):

// utils/api.ts
export function fetchUserProfile(id: string) {
    return fetch(`/api/users/${id}`)
}

// components/Profile.tsx
import { fetchUserProfile } from '@/utils/api'

export default function Profile({ userId }: { userId: string }) {
    const data = await fetchUserProfile(userId)
    return <div>{data.name}</div>
}

// components/Settings.tsx
import { fetchUserProfile } from '@/utils/api'

export default function Settings({ currentId }: { currentId: string }) {
    const user = await fetchUserProfile(currentId)
    return <div>{user.email}</div>
}

✅ Serena가 자동으로 처리한 작업:

함수명 변경: getUserData → fetchUserProfile
모든 import 문 업데이트 (2개 파일)
모든 함수 호출 업데이트 (2개 파일)
타입 정의 일관성 유지
의존성 그래프 자동 분석

설정 방법

claude mcp add-json "serena" '{"command":"uvx","args":["--from","git+https://github.com/oraios/serena","start-mcp-server"]}'

"serena": {
    "command": "uvx",
    "args": ["--from", "git+https://github.com/oraios/serena", "serena", "start-mcp-server"]
},

5. Playwright - E2E 테스트 자동화

실제 브라우저에서 사용자 시나리오를 테스트하고, 시각적 회귀를 방지할 수 있습니다.

주요 기능

브라우저 자동화: Chrome, Firefox, Safari 지원
스크린샷 캡처: 시각적 회귀 테스트
네트워크 모킹: API 응답 시뮬레이션
접근성 테스트: WCAG 준수 자동 검증

실전 활용

사용자 플로우 테스트:

"결제 프로세스 전체 E2E 테스트 작성"

생성되는 테스트:

test("결제 플로우", async ({ page }) => {
    // 1. 상품 선택
    await page.goto("/products")
    await page.click('[data-testid="product-1"]')

    // 2. 장바구니 추가
    await page.click('button:has-text("장바구니 담기")')

    // 3. 결제 진행
    await page.goto("/checkout")
    await page.fill('[name="cardNumber"]', "4242424242424242")

    // 4. 결제 완료 확인
    await expect(page).toHaveURL("/order/complete")
})

설정 방법

claude mcp add playwright npx @playwright/mcp@latest

"playwright": {
    "command": "npx",
    "args": ["@playwright/mcp@latest"]
},

6. Figma MCP Server - 디자인과 코드의 완벽한 통합

베타 주의사항: Figma MCP 서버는 현재 오픈 베타 중입니다. 일부 기능이 제한될 수 있으며, 성능 이슈가 발생할 수 있습니다.

Figma MCP 서버는 디자인 파일을 개발 워크플로우에 직접 통합하여, AI가 디자인 정보와 컨텍스트를 이해하고 코드를 생성할 수 있게 합니다. Model Context Protocol의 표준 인터페이스를 통해 데이터 소스와 AI 에이전트가 상호작용합니다.

사용 요구사항

플랜: Professional, Organization, Enterprise 플랜의 Dev 또는 Full 시트
지원 도구: MCP를 지원하는 코드 에디터 (VS Code, Cursor, Windsurf, Claude Code)

주요 기능

프레임에서 코드 생성: Figma 프레임을 선택하여 즉시 코드로 변환. 새로운 플로우 구축이나 앱 기능 반복 개발에 최적
디자인 컨텍스트 추출: 변수, 컴포넌트, 레이아웃 데이터를 IDE로 직접 가져오기. 디자인 시스템과 컴포넌트 기반 워크플로우에 특히 유용
Make 리소스 검색: Make 파일에서 코드 리소스를 수집하여 LLM에 컨텍스트로 제공. 프로토타입에서 프로덕션 애플리케이션으로 전환 시 도움
Code Connect로 일관성 유지: 실제 컴포넌트를 재사용하여 출력 품질 향상. 생성된 코드를 코드베이스와 일관되게 유지

연결 방법

Figma MCP 서버는 두 가지 방식으로 연결 가능합니다:

Remote MCP Server: Figma의 호스팅 엔드포인트에 직접 연결 (데스크톱 앱 불필요)
Local MCP Server: 로컬 머신의 Figma 데스크톱 앱을 통해 실행

Remote Server 설정 (Claude Code)

터미널에서 다음 명령 실행:
claude mcp add --transport http figma <https://mcp.figma.com/mcp>
Claude에서 /mcp 입력하여 MCP 서버 관리 후 figma 선택
Authenticate 선택하여 인증 진행
Allow Access 클릭하여 권한 부여
Claude Code에서 Authentication successful. Connected to figma 메시지 확인
/mcp 명령으로 연결 상태 최종 확인

설정 코드 (Remote)

"figma": {
  "url": "https://mcp.figma.com/mcp",
  "type": "http"
}

실전 활용 예시

디자인 시스템 컴포넌트 동기화:

"Figma의 Button 컴포넌트를 모든 variant와 함께 React 코드로 변환"

디자인 토큰 추출:

"Figma에서 색상, 타이포그래피, 스페이싱 변수를 추출하여 CSS 변수로 변환"

프레임을 컴포넌트로 변환:

"선택한 Figma 프레임을 반응형 React 컴포넌트로 변환 (Tailwind CSS 사용)"

참고: Remote 서버는 점진적으로 배포 중입니다. MCP 클라이언트에서 0개의 도구가 표시되면 아직 액세스가 활성화되지 않은 것입니다.

7. Notion MCP - AI와 워크스페이스의 완벽한 연결

Notion MCP는 AI 도구가 Notion 워크스페이스에 안전하게 액세스할 수 있도록 하는 호스팅 서버입니다. Model Context Protocol(MCP) 오픈 표준을 통해 AI 어시스턴트가 Notion 워크스페이스와 상호작용할 수 있습니다. ChatGPT, Cursor, Claude 같은 인기 AI 어시스턴트와 원활하게 작동하도록 설계되었습니다.

왜 필요한가?

간편한 설정: OAuth를 통한 간단한 연결, 지원되는 AI 도구에서 원클릭 설치
전체 워크스페이스 액세스: AI 도구가 사용자와 동일하게 Notion 페이지를 읽고 쓸 수 있음
AI 최적화: 효율적인 데이터 포맷팅으로 AI 에이전트를 위해 특별히 구축

주요 활용 사례

문서 생성: 연구 및 프로젝트 데이터에서 PRD, 기술 스펙, 아키텍처 문서 생성
검색 및 답변: AI가 모든 Notion 및 연결된 워크스페이스 콘텐츠를 검색
작업 관리: 작업 설명에서 코드 스니펫 생성 및 프로젝트 상태 자동 업데이트
보고서 작성: 여러 소스에서 릴리즈 노트, 프로젝트 업데이트, 성과 보고서 생성
캠페인 계획: 포괄적인 브리프 생성 및 마케팅 채널 전반의 진행 상황 추적

설정 방법

claude mcp add --transport http notion <https://mcp.notion.com/mcp>

"notion": {
  "type": "http",
  "url": "<https://mcp.notion.com/mcp>"
}

실전 활용 예시

프로젝트 문서 자동 생성:

"이번 스프린트의 완료된 태스크를 기반으로 릴리즈 노트를 Notion에 작성"

기술 스펙 작성:

"코드베이스 분석 결과를 바탕으로 API 문서를 Notion에 생성"

회의록 정리:

"오늘 회의 내용을 정리해서 Notion 회의록 데이터베이스에 추가"

프로젝트 상태 업데이트:

"Git 커밋 기반으로 프로젝트 진행 상황을 Notion 대시보드에 업데이트"

5️⃣ 실전 워크플로우

풀스택 기능 개발 워크플로우

1. Figma: 디자인 컴포넌트 추출 및 동기화
   ↓
2. Magic: UI 컴포넌트 생성 및 보완
   ↓
3. Sequential-Thinking: 비즈니스 로직 설계
   ↓
4. Context7: 최신 API 패턴 확인
   ↓
5. Serena: 코드베이스 통합 및 리팩토링
   ↓
6. Playwright: E2E 테스트 작성
   ↓
7. Notion: 기능 문서화

대규모 리팩토링 워크플로우

1. Serena: 의존성 그래프 분석
   ↓
2. Sequential-Thinking: 리팩토링 전략 수립
   ↓
3. Context7: 새 API 마이그레이션 가이드
   ↓
4. Playwright: 회귀 테스트
   ↓
5. Notion: 변경사항 문서화

버그 수정 워크플로우

1. Sequential-Thinking: 버그 원인 분석
   ↓
2. Serena: 영향 범위 파악
   ↓
3. Context7: 올바른 해결책 확인
   ↓
4. Playwright: 버그 재현 테스트
   ↓
5. Notion: 버그 리포트 작성

6️⃣ 단계별 추천

입문자를 위한 시작 순서

Context7 설치: 최신 문서 참조를 위한 기본 도구
Magic 설치: UI 컴포넌트 생성
Playwright 설치: 테스트 자동화

중급자 확장 패키지

Serena 추가: 프로젝트 메모리 관리
Sequential-Thinking 추가: 복잡한 문제 해결
Notion 연동: 문서화 시스템

고급 사용자를 위한 확장

Figma: 디자인 시스템 통합
추가 MCP 서버 탐색 및 커스터마이징
모든 MCP 조합 최적화

7️⃣ 마무리하며

이 7개의 핵심 MCP 서버는 제가 실제 프로덕션 환경에서 검증한 조합입니다. 각 서버는 특정 영역에서 Claude Code의 능력을 향상시키며, 함께 사용했을 때 시너지 효과를 발휘할 수 있습니다.

핵심 메시지

점진적 도입: 모든 MCP를 한 번에 설치하기보다는 필요에 따라 추가하세요
워크플로우 중심: 자신의 개발 패턴에 맞는 MCP를 선택하세요
조합의 힘: 단일 MCP보다 적절한 조합이 더 효과적일 수 있습니다

실전 팁

Sequential-Thinking + Serena = 체계적인 코드 분석
Magic + Figma = 디자인 시스템 자동화
Context7 + Notion = 최신 문서 관리 체계
Serena + Playwright = 리팩토링 후 자동 검증

Claude Code를 단순한 코드 보조 도구가 아닌, 실제 팀의 일원으로 활용할 수 있는 단계로 나아가 보세요.!

Claude Code for Front-end #2: .claude 디렉토리

백씨네 — Wed, 7 Jan 2026 20:41:32 +0900

모든 프로젝트에 적용되는 나만의 AI 환경 - 프로젝트를 넘나들며 일관성 유지하기

1️⃣ 들어가며

1편에서 프로젝트별 CLAUDE.md 작성법을 소개했습니다. 각 프로젝트에서 Claude Code가 의도를 정확히 이해하고 코드를 작성할 수 있게 되었습니다.

그런데 여러 프로젝트를 진행하면서 한 가지 패턴을 발견했습니다.

모든 CLAUDE.md에서 반복되는 내용이 존재합니다.

# 프로젝트 A의 CLAUDE.md
- TypeScript에서 `any` 타입 사용 금지
- TODO 주석 대신 완전한 구현
- Git feature branch 전략 사용
- 한국어로 응답

# 프로젝트 B의 CLAUDE.md
- TypeScript에서 `any` 타입 사용 금지 (또 쓴다...)
- TODO 주석 대신 완전한 구현 (또 쓴다...)
- Git feature branch 전략 사용 (또...)
- 한국어로 응답 (또...)

이런 규칙들은 프로젝트별이 아니라 개인의 코딩 철학입니다.

이를 해결하는 방법이 바로 ~/.claude/ 디렉토리입니다.

2️⃣ .claude 디렉토리란?

홈 디렉토리의 전역 설정

~/.claude/ 는 홈 디렉토리에 만드는 전역 설정 공간입니다.

# macOS/Linux
~/.claude/
└── CLAUDE.md

# Windows
C:\\\\Users\\\\[username]\\\\.claude\\\\
└── CLAUDE.md

설정 우선순위 체계

Claude Code는 다음 순서로 설정을 읽어옵니다:

1. Claude Code 기본 동작
   ↓
2. ~/.claude/CLAUDE.md (전역 설정)
   ↓
3. [프로젝트]/CLAUDE.md (프로젝트 설정)
   ↓
4. 대화 중 명시적 지시

중요한 점: 아래 단계가 위 단계를 덮어씁니다.

예시:

전역: "한국어로 응답"
프로젝트: "영어로 응답" (문서화 프로젝트)
결과: 해당 프로젝트에서는 영어로 응답

언제 전역으로 빼야 하는가?

전역으로 관리 (~/.claude/):

개인 코딩 철학 (any 금지, DRY 원칙)
선호하는 응답 언어
Git 워크플로우
보편적인 품질 기준

프로젝트별 관리 (CLAUDE.md):

기술 스택 (Next.js, React, Vue)
디렉토리 구조
프로젝트 특화 패턴
개발 명령어

판단 기준: "다른 프로젝트에서도 똑같이 적용할 규칙인가?"

3️⃣ ~/.claude/CLAUDE.md 구조

전역 설정에서 제가 실제로 사용하는 규칙들을 소개합니다.

1. 언어 설정

# Language Preference

Always respond in Korean using formal language (존댓말).

효과: 모든 프로젝트에서 한국어로 대화할 수 있습니다. 영어 문서화가 필요한 프로젝트에서만 CLAUDE.md에서 재정의합니다.

2. TypeScript 규칙

## TypeScript Rules

### Type Safety
- **Never use `any` type** - Always use `unknown`, specific types, or generics
- Prefer interfaces over types for object shapes
- Always define return types for functions
- Use strict mode settings

### Examples

```typescript
// ❌ Bad
function fetchData(): any {
  return fetch('/api/data')
}

// ✅ Good
interface ApiResponse {
  data: User[]
  total: number
}

async function fetchData(): Promise<ApiResponse> {
  const response = await fetch('/api/data')
  return response.json()
}

효과: Claude Code가 절대 any 타입을 제안하지 않습니다.

3. 코드 품질 기준

## Code Quality Standards

### Implementation Rules
- **No TODO comments** - Implement completely or don't start
- **No magic numbers/strings** - Define as constants
- **No console.log** - Use proper logging utility
- **Maximum function length**: 30 lines
- **Maximum component length**: 150 lines

### Examples

```typescript
// ❌ Bad
function calculate(price: number) {
  // TODO: add tax calculation
  return price * 1.1  // Magic number
}

// ✅ Good
const TAX_RATE = 0.1

function calculate(price: number): number {
  return price * (1 + TAX_RATE)
}

효과: Claude Code가 항상 완전한 코드를 작성하며, magic number를 상수로 정의합니다.

4. Git 워크플로우

## Git Workflow

### Branch Strategy
- Always work on feature branches
- Never commit directly to `main` or `master`
- Use meaningful commit messages

### Commit Message Format
- feat: Add user authentication 
- fix: Resolve login redirect issue 
- refactor: Simplify API client logic

### Before Commit Checklist
1. Run linting: `npm run lint`
2. Run tests: `npm run test`
3. Review changes: `git diff`

효과: Claude Code가 Git 작업 시 항상 feature branch를 사용하고, 린트/테스트를 실행합니다.

5. 금지 패턴

## Prohibited Patterns

- ❌ **No `any` type**
- ❌ **No TODO comments**
- ❌ **No console.log** (use logger)
- ❌ **No inline styles** (use CSS/Tailwind)
- ❌ **No magic numbers** (define constants)
- ❌ **No partial implementations** (complete or don't start)

효과: 이런 패턴을 제안하면 즉시 거부하고 대안을 제시합니다.

4️⃣ 실제 적용 효과

Before: 반복 설명의 지옥

프로젝트 A에서:

나: "API 호출 함수 만들어줘"
Claude: [함수 생성]
나: "any 타입 쓰지 마"
Claude: [수정]
나: "console.log 빼고"
Claude: [수정]
나: "TODO 주석 말고 완전히 구현해"
Claude: [수정]

프로젝트 B로 이동:

나: "API 호출 함수 만들어줘"
Claude: [함수 생성]
나: "any 타입 쓰지 마" (또...)
Claude: [수정]
나: "console.log 빼고" (또...)
Claude: [수정]

After: 한 번 설정, 영원히 적용

~/.claude/CLAUDE.md 설정 후:

나: "API 호출 함수 만들어줘"
Claude: [any 없이, console.log 없이, 완전히 구현된 함수 생성]

모든 프로젝트에서 동일하게 적용됩니다.

5️⃣ 전역 vs 프로젝트별 분리 전략

제가 실제로 사용하는 분리 기준입니다.

전역 설정 (~/.claude/CLAUDE.md)

1. 언어 및 커뮤니케이션:

- 응답 언어 (한국어/영어)
- 응답 스타일 (formal/casual)
- 설명 상세도

2. 코딩 철학:

- TypeScript any 금지
- DRY (Don't Repeat Yourself) 원칙
- SOLID 원칙
- 완전 구현 원칙 (No TODO)

3. Git 워크플로우:

- Feature branch 전략
- Commit message 형식
- PR 전 체크리스트

4. 품질 기준:

- 함수 최대 길이
- 컴포넌트 최대 길이
- 네이밍 컨벤션 기본 원칙
- 금지 패턴

프로젝트별 설정 (CLAUDE.md)

1. 기술 스택:

- 프레임워크 (Next.js, React, Vue)
- 상태 관리 (Zustand, Redux, Recoil)
- 스타일링 (Tailwind, styled-components)

2. 프로젝트 구조:

- 디렉토리 구조
- 파일 명명 규칙
- Import 경로 (alias)

3. 개발 명령어:

- dev server 실행
- build 명령어
- 테스트 실행

4. 특화 패턴:

- API 호출 패턴
- 컴포넌트 템플릿
- 상태 관리 패턴

판단 플로우차트

규칙을 추가하려고 합니다
    ↓
이 규칙이 모든 프로젝트에 적용되나요?
    ↓
YES → ~/.claude/CLAUDE.md
NO → [프로젝트]/CLAUDE.md

6️⃣ 작성 팁

1. 점진적으로 추가하기

처음부터 완벽한 전역 설정을 만들 필요는 없습니다.

권장 방법:

프로젝트 2-3개에서 CLAUDE.md 작성
반복되는 규칙 발견
전역으로 이동
프로젝트별 CLAUDE.md에서 제거

예시:

# 프로젝트 A, B, C 모두에서 발견
"TypeScript any 금지"
→ ~/.claude/CLAUDE.md로 이동

# 프로젝트 A, B, C의 CLAUDE.md에서 제거
이제 각 프로젝트는 자신만의 특화 설정만 유지

2. 실제 사용 기반

이론이 아닌 실제 사용 패턴을 문서화합니다.

❌ 나쁜 예:

# 읽은 책의 모든 원칙을 나열
- SOLID 원칙
- GoF 디자인 패턴 23가지
- Clean Code 규칙 100가지

✅ 좋은 예:

# 실제로 자주 지적하는 것만
- any 타입 금지 (매번 지적함)
- TODO 주석 금지 (매번 지적함)
- console.log 금지 (매번 지적함)

3. 정기적 업데이트

워크플로우가 변경되면 설정도 함께 업데이트합니다.

업데이트 시점:

새로운 금지 패턴 발견 시
개발 프로세스 변경 시
새 프레임워크 도입 시

예시:

# 6개월 전: React Class Components 사용
## Component Rules
- Use class components with lifecycle methods
- Use HOCs (Higher-Order Components) for reusability
- Manage state with this.setState()

# 현재: React Hooks 전환 완료
## Component Rules
- Use functional components with Hooks
- Use custom hooks for reusability
- No class components (use hooks instead)
- Prefer useState and useEffect

7️⃣ 완성 템플릿

바로 복사해서 사용할 수 있는 ~/.claude/CLAUDE.md 템플릿입니다.

# Global Claude Code Configuration

This file contains my personal coding preferences applied to all projects.

## Language Preference

Always respond in Korean using formal language.

## TypeScript Rules

### Type Safety
- Never use `any` type - use `unknown`, specific types, or generics
- Prefer interfaces over types for object shapes
- Always define return types for functions

### Examples

```typescript
// ❌ Bad
function getData(): any {
  return fetch('/api/data')
}

// ✅ Good
interface ApiResponse {
  data: unknown
  status: number
}

async function getData(): Promise {
  const response = await fetch('/api/data')
  return response.json()
}
```

## Code Quality Standards

### Implementation Rules
- No TODO comments - implement completely or don't start
- No magic numbers/strings - define as constants
- No console.log - use proper logging utility
- Maximum function length: 30 lines
- Maximum component length: 150 lines

### Examples

```typescript
// ❌ Bad
function calculate(price: number) {
  // TODO: add tax calculation
  console.log(price)
  return price * 1.1
}

// ✅ Good
const TAX_RATE = 0.1

function calculate(price: number): number {
  logger.debug('Calculating price with tax', { price })
  return price * (1 + TAX_RATE)
}
```

## Git Workflow

### Branch Strategy
- Always work on feature branches
- Never commit directly to `main` or `master`
- Branch naming: `feature/feature-name`, `fix/bug-name`

### Commit Message Format
```
feat: Add new feature
fix: Resolve bug
refactor: Improve code structure
docs: Update documentation
test: Add or update tests
```

### Before Commit Checklist
1. Run linting
2. Run tests
3. Review changes with `git diff`

## Prohibited Patterns

- ❌ No `any` type
- ❌ No TODO comments
- ❌ No console.log
- ❌ No inline styles
- ❌ No magic numbers
- ❌ No partial implementations

## Naming Conventions

### General Rules
- **Constants**: UPPER_SNAKE_CASE
- **Functions**: camelCase
- **Classes/Components**: PascalCase
- **Files**: Match the export (PascalCase for components, camelCase for utilities)

### Examples

```typescript
// Constants
const API_BASE_URL = '<https://api.example.com>'
const MAX_RETRY_COUNT = 3

// Functions
function fetchUserData() {}
function calculateTotalPrice() {}

// Classes/Components
class UserService {}
function UserProfile() {}

// Files
UserProfile.tsx // Component file
apiClient.ts // Utility file
```

## Code Organization

### Import Order
1. External packages (react, next, lodash)
2. Internal absolute imports (@/components, @/lib)
3. Relative imports (./components, ../utils)

### File Structure
- Keep files under 300 lines
- One component per file
- Co-locate related files (component + styles + tests)

## Comments

### When to Comment
- ✅ Complex algorithms
- ✅ Business logic rationale
- ✅ Non-obvious workarounds

### When NOT to Comment
- ❌ Obvious code behavior
- ❌ TODO/FIXME (complete or create ticket)
- ❌ Commented-out code (use git history)

## Testing

### Test Coverage Goals
- Critical paths: 80%+
- Utilities: 90%+
- Components: 70%+

### Test Naming
```typescript
// ✅ Good
describe('UserService', () => {
  it('should return user data when user exists', () => {})
  it('should throw error when user not found', () => {})
})
```

8️⃣ 정리

핵심 포인트

전역 설정의 힘:

한 번 작성으로 모든 프로젝트 적용
반복 설명 제거
일관된 코드 품질 유지

분리 전략:

전역: 개인 철학, 언어, 워크플로우
프로젝트별: 기술 스택, 구조, 특화 패턴

작성 팁:

점진적으로 추가
실제 사용 기반
정기적 업데이트

시작하기

# 1. ~/.claude 디렉토리 생성
mkdir ~/.claude

# 2. CLAUDE.md 생성
touch ~/.claude/CLAUDE.md

# 3. 위 템플릿 복사하여 시작
# 4. 프로젝트별 CLAUDE.md에서 중복 제거

체크리스트

[ ] ~/.claude 디렉토리 생성
[ ] CLAUDE.md 작성 (언어, TypeScript, 품질 기준)
[ ] 프로젝트별 CLAUDE.md에서 중복 제거
[ ] 새 프로젝트에서 테스트
[ ] 정기적 업데이트 계획

효과

반복 설명 제거: 모든 프로젝트에 자동 적용
일관된 품질: 개인 기준 유지
시간 절약: 프로젝트 전환 시 재설명 불필요
팀 온보딩: 새 팀원이 규칙 이해 용이

베스트 프랙티스

점진적 추가: 필요한 규칙부터 하나씩 추가
실제 사용 기반: 이론이 아닌 실제 사용 패턴 문서화
정기적 업데이트: 워크플로우 변화에 맞춰 수정
플래그 활용: 상황에 맞는 플래그 조합 실험

.claude 디렉토리는 프로젝트를 넘나들며 일관성을 유지하는 핵심입니다. 지금 바로 ~/.claude/ 디렉토리를 만들고 나만의 AI 환경을 구축해보세요.

Claude Code for Front-end #1: CLAUDE.md 작성 가이드

백씨네 — Wed, 7 Jan 2026 20:39:40 +0900

Claude Code와 대화하는 법 - AI에게 프로젝트를 설명하는 가장 효과적인 방법

1️⃣ 들어가며

Claude Code에게 "회원가입 페이지 만들어줘"라고 요청했을 때 두 가지 상황이 벌어집니다.

상황 A: "어떤 필드가 필요하신가요? 어떤 상태 관리 라이브러리를 쓰시나요? 스타일링은 어떻게 하시나요?"

상황 B: "React Hook Form과 Zod로 이메일/비밀번호/비밀번호 확인 필드를 만들었습니다. Zustand로 인증 상태를 관리하고 Tailwind로 스타일링했습니다."

차이는 단 하나, CLAUDE.md 파일의 존재 여부입니다.

2️⃣ CLAUDE.md가 필요한 이유

AI 코딩 도구의 핵심은 "컨텍스트"

Claude Code는 대화할 때마다 프로젝트의 맥락을 파악해야 합니다. CLAUDE.md는 프로젝트의 설명서로, 한 번 작성하면 Claude Code는 모든 대화에서 이 정보를 참고합니다.

Claude Code는 세션을 시작할 때 다음 순서로 컨텍스트를 구성합니다:

1. 전역 설정 로드: ~/.claude/ 디렉토리의 공통 규칙

2. 프로젝트 설정 파싱: CLAUDE.md 읽기 및 분석

3. 환경 정보 수집: Git 상태, 파일 구조, 의존성

4. 컨텍스트 통합: 우선순위에 따른 규칙 병합

이 과정에서 CLAUDE.md는 프로젝트별 컨텍스트의 단일 진실 공급원(Single Source of Truth)으로 작동합니다.

매번 설명하는 것 vs 한 번 작성하는 것

CLAUDE.md 없이 작업할 때:

개발자: "API 호출 함수 만들어줘"
Claude: "어떤 HTTP 클라이언트를 사용하시나요?"
개발자: "axios요"
Claude: "base URL은 어디에 있나요?"
개발자: ".env에 API_URL이요"
Claude: "에러 처리는 어떻게 하시나요?"
개발자: "try-catch로 하고 toast로 보여줘요"

CLAUDE.md 작성 후

개발자: "API 호출 함수 만들어줘"
Claude: "axios 인스턴스 사용해서 POST 요청 함수를 만들었습니다.
        에러는 try-catch로 처리하고 toast로 사용자에게 보여줍니다."

실제 비교 사례

같은 요청, 다른 결과:

// CLAUDE.md 없을 때
async function fetchData(id: string) {
    // TODO: implement API call
    throw new Error("Not implemented")
}

// CLAUDE.md 있을 때
async function fetchData(id: string) {
    try {
        const response = await apiClient.get(`/items/${id}`)
        return response.data
    } catch (error) {
        toast.error("데이터를 불러오는데 실패했습니다.")
        throw error
    }
}

3️⃣ 기본 구조 잡기

CLAUDE.md는 5개 핵심 섹션으로 구성합니다.

1. 프로젝트 개요 (Project Overview)

프로젝트의 정체성을 한눈에 보여줍니다.

## Project Overview

This is a web application built with modern React ecosystem.

**Tech Stack**:

-   Framework: Next.js 15.0.0 with App Router
-   Language: TypeScript 5.3
-   Package Manager: pnpm 8.9.0
-   State Management: Zustand + TanStack Query
-   Styling: Tailwind CSS
-   Form: React Hook Form + Zod

필수 정보:

프레임워크 및 버전 (API 호환성에 필수)
언어 및 타입 시스템
패키지 매니저
주요 라이브러리

기술적 중요성: 버전 정보는 API 호환성, 기능 가용성, 마이그레이션 경로 결정에 필수적입니다.

2. 디렉토리 구조 (Directory Structure)

Claude가 파일을 어디에 만들어야 하는지 판단할 수 있게 합니다.

## Directory Structure

src/
├── app/
│ ├── (pages)/ # Route groups (괄호는 라우팅 제외용 그룹 폴더를 의미)
│ │ ├── [id]/ # Dynamic routes
│ │ └── page.tsx # Route pages
│ ├── (shared)/ # Shared components
│ ├── api/ # API routes (route.ts)
│ └── layout.tsx # Root layout
├── components/ # Reusable components
├── lib/ # Utilities
└── types/ # Type definitions

### Directory Naming Rules

-   `(name)/`: Route groups - URL에 포함되지 않음
-   `[param]/`: Dynamic route segments
-   `_name/`: Private folders - 라우팅에서 제외

### Directory Roles

-   `(pages)/`: Route group for page components
-   `(shared)/`: Shared resources across the app
-   `api/`: Next.js API routes (route.ts files)
-   `components/`: Reusable UI components

Before:

개발자: "UserProfile 컴포넌트 만들어줘"
Claude: "어디에 만들까요?"

After:

개발자: "UserProfile 컴포넌트 만들어줘"
Claude: "src/components/user/UserProfile.tsx에 생성했습니다"

설계 원칙:

실제 디렉토리 구조와 동기화 유지
특수 폴더 규칙 명시 (route groups, dynamic segments)
각 디렉토리의 역할 1줄 설명

3. 코드 컨벤션 (Code Conventions)

일관된 코드 스타일을 유지합니다.

## Code Conventions

### Naming Rules

-   **Components**: PascalCase (`UserCard.tsx`, `DashboardLayout.tsx`)
-   **Pages**: 항상 `page.tsx` (Next.js App Router)
-   **Layouts**: 항상 `layout.tsx` (Next.js App Router)
-   **API Routes**: 항상 `route.ts` (Next.js App Router)
-   **Utilities**: camelCase (`formatDate.ts`, `apiClient.ts`)
-   **Hooks**: `use` prefix (`useAuth.ts`, `useDebounce.ts`)
-   **Types**: PascalCase with suffix (`UserData.types.ts`)
-   **Constants**: UPPER_SNAKE_CASE (`API_BASE_URL`, `MAX_RETRY_COUNT`)

### TypeScript Guidelines

**Type vs Interface 선택 기준:**

-   ✅ `interface`: 객체 shape 정의, 확장 가능한 구조
-   ✅ `type`: Union, Intersection, Utility types, Tuple, Function types

**규칙:**

-   **Never use `any`** - use `unknown` with type guards
-   Always define prop types for components
-   Use explicit return types for functions

### Examples

\```typescript
// ❌ Bad
function getData(): any {
return fetch('/api/data')
}

// ✅ Good
interface ApiResponse {
data: User[]
total: number
}

async function getData(): Promise<ApiResponse> {
const response = await fetch('/api/data')
return response.json()
}
\```

### Prohibited Patterns

-   ❌ **No `any` type** - Use specific types or `unknown`
-   ❌ **No TODO comments** - Complete implementations only
-   ❌ **No inline styles** - Use Tailwind classes
-   ❌ **No magic numbers** - Define as constants
-   ❌ **No console.log** - Use proper logging utility

적용 기준:

ESLint 규칙과 동기화
Prettier 설정 반영
프레임워크 권장사항 준수

4. 개발 명령어 (Essential Commands)

Claude가 직접 명령어를 실행할 수 있게 합니다.

## Essential Commands

### Development
```bash
pnpm dev              # Run dev server (port 3000)
pnpm dev:turbo        # Run with Turbopack
```

### Build & Quality Checks
```bash
pnpm build            # Production build
pnpm lint             # ESLint check
pnpm format           # Prettier formatting
pnpm test             # Run tests
pnpm typecheck        # TypeScript check
```

### Package Management
```bash
pnpm install              # Install dependencies
pnpm add [package]        # Add package
pnpm add -D [package]     # Add dev dependency
```

자주 사용하는 명령어만 선별하세요. 모든 명령어를 나열할 필요는 없습니다.

5. 실용적 예제 (Common Patterns)

자주 만드는 패턴을 템플릿화합니다.

## Common Patterns

### Client Component with State
```typescript
'use client'

import { useState } from 'react'
import { useQuery } from '@tanstack/react-query'

export function UserList() {
  const { data, isLoading } = useQuery({
    queryKey: ['users'],
    queryFn: fetchUsers,
  })

  if (isLoading) return <div>Loading...</div>

  return (
    <ul>
      {data?.map((user) => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  )
}
```

### API Client Pattern
```typescript
// lib/apiClient.ts
import axios from 'axios'

export const apiClient = axios.create({
  baseURL: process.env.NEXT_PUBLIC_API_URL,
  headers: {
    'Content-Type': 'application/json',
  },
})

apiClient.interceptors.request.use((config) => {
  const token = localStorage.getItem('token')
  if (token) {
    config.headers.Authorization = `Bearer ${token}`
  }
  return config
})
```

### React Query Mutation
```typescript
// api/user.mutation.ts
import { useMutation } from '@tanstack/react-query'
import { apiClient } from '@/lib/apiClient'

export const useCreateUser = () => {
  return useMutation({
    mutationFn: async (data: CreateUserRequest) => {
      const response = await apiClient.post('/users', data)
      return response.data
    },
    onSuccess: () => {
      toast.success('생성되었습니다')
    },
    onError: (error) => {
      toast.error('생성에 실패했습니다')
    }
  })
}
```

4️⃣ 작성 후 테스트하기

Claude Code에게 질문해보기

CLAUDE.md를 작성한 후 실제로 테스트해보세요.

테스트 질문 1: "새로운 페이지를 만들려면 어디에 파일을 생성해야 해?"
기대 응답: "src/app/(pages)/ 디렉토리에 page.tsx 파일을 생성하면 됩니다."

테스트 질문 2: "API 호출은 어떻게 해야 해?"
기대 응답: "apiClient를 사용하고 React Query의 useMutation을 활용하세요."

테스트 질문 3: "개발 서버 실행 명령어는?"
기대 응답: "pnpm dev 명령어로 개발 서버를 실행할 수 있습니다."

테스트 질문 4: "컴포넌트 파일명은 어떻게 지어?"
기대 응답: "PascalCase로 작성합니다. 예: UserCard.tsx"

테스트 질문 5: "any 타입 사용해도 돼?"
기대 응답: "any 타입은 사용 금지입니다. unknown이나 구체적인 타입을 사용하세요."

응답 품질 확인 체크리스트

올바른 디렉토리를 제안하는가?
프로젝트의 코딩 스타일을 따르는가?
사용하는 라이브러리를 올바르게 적용하는가?
명령어를 정확하게 실행하는가?
금지 패턴을 피하는가?

구문 검증

마크다운 구문을 검증합니다:

# markdownlint를 사용한 린팅
npx markdownlint-cli CLAUDE.md

# 또는 VS Code 확장 프로그램 사용
# markdownlint extension by David Anson

5️⃣ 완성 템플릿

다음은 바로 복사해서 사용할 수 있는 CLAUDE.md 템플릿입니다.

# CLAUDE.md

This file provides guidance to Claude Code when working with this repository.

## Project Overview

This is a **[프로젝트 유형]** built with:
- **Framework**: [Next.js 15 / React / Vue]
- **Language**: TypeScript
- **Package Manager**: [pnpm / npm / yarn]
- **State Management**: [Zustand / Recoil / Redux]
- **Styling**: [Tailwind CSS / styled-components]
- **Form**: [React Hook Form / Formik]

## Directory Structure

```
src/
├── app/              # [설명]
├── components/       # [설명]
├── lib/             # [설명]
└── types/           # [설명]
```

### Directory Roles
- `app/`: [역할 설명]
- `components/`: [역할 설명]
- `lib/`: [역할 설명]

## Code Conventions

### Naming Rules
- **Components**: PascalCase (`UserCard.tsx`)
- **Utilities**: camelCase (`formatDate.ts`)
- **Constants**: UPPER_SNAKE_CASE (`API_BASE_URL`)

### TypeScript Guidelines
- Never use `any` type
- Prefer interfaces over types
- Define prop types for all components

### Prohibited Patterns
- ❌ TODO comments
- ❌ console.log
- ❌ Inline styles

## Essential Commands

### Development
```bash
[dev command]          # Run dev server
[build command]        # Production build
[test command]         # Run tests
```

### Package Management
```bash
[install command]      # Install dependencies
[add command]          # Add new package
```

## Common Patterns

### Component Template
```typescript
[자주 사용하는 컴포넌트 패턴]
```

### API Call Pattern
```typescript
[API 호출 패턴]
```

### State Management
```typescript
[상태 관리 패턴]
```

6️⃣ 정리

CLAUDE.md는 프로젝트와 AI 사이의 공통 언어입니다.

핵심 체크리스트

[ ] 프로젝트 개요 작성 (기술 스택, 버전)
[ ] 디렉토리 구조 설명 (파일 위치 가이드)
[ ] 코드 컨벤션 명시 (네이밍, 패턴, 금지사항)
[ ] 개발 명령어 정의 (dev, build, lint, test)
[ ] 실용적 예제 포함 (자주 쓰는 패턴)
[ ] 작성 후 테스트 (질문으로 검증)

효과

반복 설명 제거 → 개발 시간 단축
일관된 코드 품질 유지
팀원 온보딩 시간 감소
AI와의 협업 효율 극대화

베스트 프랙티스

정기적 업데이트: 프로젝트 진화에 따라 CLAUDE.md 동기화
실제 사용 기반: 팀이 실제로 따르는 규칙만 문서화
구체적 예시: 추상적 설명보다 코드 예시 선호
버전 명시: 의존성 버전 명확히 기록

30분 투자로 수십 시간의 반복 설명을 절약할 수 있습니다. 지금 바로 프로젝트 루트에 CLAUDE.md를 만들어보세요.

자바스크립트 엔진(V8)의 작동 원리

백씨네 — Sat, 12 Apr 2025 02:06:02 +0900

V8과 자바스크립트 엔진 개요

1. 자바스크립트는 어떻게 실행되는가?

자바스크립트는 사람이 작성한 텍스트 코드를 브라우저 나 Node.js 내부의 자바스크립트 엔진(V8 등)이 해석하고 실행한다.

자바스크립트 실행 과정은 크게 파싱 -> 컴파일 -> 실행 순으로 진행되며, 최적화도 동시에 수행된다.

2. 엔진이 무엇이고 V8은 왜 유명한가?

자바스크립트 엔진은 JS 코드를 실행하는 핵심 시스템이고, V8은 성능과 범용성에서 가장 뛰어난 엔진이다.

엔진 : 자바스크립트 코드를 파싱, 컴파일, 실행하는 시스템
V8 : 구글이 만든 JS 엔진으로, 빠른 속도, JIT 컴파일, Node.js에서 사용되면서 JS 생태계를 주도

2.1. 자바스크립트 엔진의 정의

자바스크립트 엔진은 JS 소스 코드를 읽고(파싱) -> 기계어로 바꾸고(컴파일) ->실행하는 소프트웨어이다

브라우저(Chrome)나 런타임(Node.js) 내부에 포함되어 있으며, 사용자가 작성한 코드가 실제로 작동할 수 있게 만들어주는 실행기(interpreter + compiler)이다.

2.2 V8 엔진이 유명한 이유

특징	설명
빠른 속도	JIT 컴파일러와 다양한 최적화 기술로 빠른 실행 속도 확보
Node.js의 엔진	브라우저 외에도 서버(Node.js)에서 JS를 실행할 수 있게 한 기발
WebAssembly 지원	JS 외에도 다른 언어로 작성된 코드를 실행할 수 있다.
크로스 플랫폼	Window, Linux, macOS 등 어디서든 작동 가능
오픈 소스	누구나 분석 및 커스텀마이징 가능, 생태계 확장에 기여

2.3. V8 엔진이 탑재된 대표 플랫폼

Google Chrome
Node.js
Electron (데스크탑 앱 프레임워크)
Deno
Cloudflare Workers / Vercel Edge Functions 등 서버리스 플랫폼

3. 인터프리터 vs 컴파일러 비교

3.1. 요약

특징	인터프리터(Interpreter)	컴파일러 (Compiler)
실행 방식	한 줄씩 바로 해석하며 실행	전체 코드를 한 번에 기계어로 번역 후 실행
실행 속도	초기 실행은 빠름, 전체는 느릴 수 있음	초기 느리지만 실행 중 속도 빠름
디버깅	에러가 발생한 줄에서 바로 확인 가능	컴파일 타임에 전체 에러 확인 가능
메모리 사용	적음	상대적으로 많음
예시 언어	JS, Python	C, C++, Rust

3.2. JIT 컴파일

JIT : Just-In-Time Compiler

JIT 컴파일은 실행 중(Interpreting 도중)에 자주 실행되는 부분을 기계어로 변환하여 실행 속도를 높이는 하이브리드 방식이다.

3.2.1. 동작 흐름

인터프리터로 전체코드 실행
실행 중 프로파일링 ( 자주 쓰이는 코드 확인)
자주 쓰이는 코드 (핫 코드) 를 JIT 컴파일러가 기계어로 변환
이후 이 기계어 코드로 빠르게 실행

3.2.2. JIT와 다른 컴파일 방식들

방식	설명	예시
AOT (Ahead-Of-Time)	실행 전에 전체 소스코드를 미리 기계어로 변환	C, C++, Rust, Swift
JIT (Just-In-Time)	실행 중에 필요한 부분만 기계어로 컴파일	Java, JS(V8), Kotlin/Native 일부
인터프리팅	기계어 변환 없이, 바로 한 줄씩 실행	JS, Python, Ruby

V8 내부 구조

V8은 파서 -> 인터프리터 (Ignition) -> JIT (TurboFan)로 구성되어, 실행 중 최적화를 반복하여 성능을 끌어올리는 구조이다.

1. V8 흐름

소스코드
-> Parser (파서)
-> AST (추상 구문 트리)
-> Interpreter (Ignition)
-> Bytecode 생성 및 실행
-> Hot Code 감지
-> JIT Compiler (TurboFan)
-> 최적화된 기계어 코드
-> CPU에서 실행

2. 상세 설명

2.1. Parser (파서)

자바스크립트 소스를 읽어서 AST(abstract syntax tree)로 변환
문법 오류 체크도 이 단계에서 처리됨

2.2. Ignition (인터프리터)

AST를 바이트코드(bytecode)로 변환하고 즉시실행
빠른 시작이 가능함
코드 실행 중 어떤 함수가 자주 호출되는지 프로파일링을 시작함

2.3. Profiler (프로파일러)

어떤 함수/루프가 자주 실행되는지 기록 -> Hot Code 식별
성능을 향상할 수 있는 대상만 JIT 컴파일러로 넘김

2.4. TurboFan (JIT 컴파일러)

Hot Code를 받아서 기계어로 컴파일
이 코드는 이후 재사용됨 -> 실행 속도 급격히 향상
다양한 최적화 수행
- Inline Caching : 객체 프로퍼티 접근을 캐싱
- Escape Analysis : 객체가 함수 밖에서 사용되지 않으면 스택에 할당
- Dead Code Elimination : 실행되지 않는 코드는 제거
- Function Inlining : 자주 호출되는 함수 내부로 코드 삽입
- Constant Folding : 계산 가능한 상수는 미리 처리

2.5. Garbage Collector ( GC )

필요 없는 메모리를 자동으로 회수함
V8은 Generational GC 방식 사용:
- New Space (짧게 살아남는 객체)
- Old Space (오래 살아있는 객체)

부가 구성요소

IC (Inline Cache) : 객체 접근을 캐싱하여 반복 성능 향상
Hidden Class / Map : 객체 구조를 정형화시켜 빠르게 접근 가능하게 함
Zone memory allocator : 단기 메모리 관리를 위한 전용 영역

3. Ignition / TurboFan

Ignition : 바이트 코드를 생성하고 실행하는 인터프리터
TurboFan : 실행 중인 핫코드를 기계어로 최적화 컴파일하는 JIT 컴파일러

3.1. Ignition : 바이트코드를 실행하는 인터프리터

항목	설명
역할	자바스크립트 소스코드를 바이트코드로 변환하고 실행함
특징	빠른 시작(Startup Time), 저메모리 소비
도입 배경	기존에는 AST -> 기계어로 전환하던 방식에서 더 유연한 실행을 위해서 등장
장점	빠르게 실행 시작 가능하며, JIT 컴파일 대상 탐지 가능 (프로파일링 포함)

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

add(1, 2)

위 함수가 처음 실행될 때, Ignition이 바이트코드를 만들어 바로 실행한다.
반복 실행되면 이 함수는 'Hot Code'로 감지되고, TruboFan에게 넘겨진다.

3.2. TurboFan : 기계어로 변환하는 JIT 컴파일러

항목	설명
역할	자주 실행되는 코드(핫코드)를 JIT 컴파일하여 네이티브 코드로 변환
특징	SSA 기반 중간 표현(IR)을 사용하여 다양한 최적화 수행
장점	실행 속도를 극적으로 향상, 캐시된 기계어 코드 재사용

3.3. SSA 기반 중간 표현

SSA란?

Static Single Assignment - 정적 단일 할당
"모든 변수는 딱 한 번만 할당된다."
어떤 값이 어디서 생성되고, 어디로 흐르는지를 명확하게 추적할 수 있게 만드는 구조

예시

// 기존코드 

let x = 1;
x = x + 2;
x = x * 3;

// SSA로 변환하면
x1 = 1 // 최초 할당
x2 = x1 + 2 // x1의 결과로 x2 생성
x3 = x2 * 3 // x2의 결과로 x3 생성

변수명이 바뀌면서 모든 값이 어떤 연산 결과인지 명확하게 추적할 수 있게 된다.

중요한 이유?

x3는 x2가 있어야만 계산이 되고
x2는 x1이 있어야만 계산이 된다.

그래프 형태로 데이터 흐름을 추적할 수 있게 된다. -> 컴파일러 입장에서 최적화하기 좋은 조건

만약!

"x2가 필요 없는 값이면 x3도 필요 없다" -> 불필요한 연산 통째로 제거 가능

최적화 기법

최적화 기법	설명	예시
Dead Code Elimination	결과에 영향을 주지 않는 연산 제거	let a = 5; → a 안 쓰면 제거
Constant Folding	고정된 값을 미리 계산	2 + 3 → 5로 변환
Value Numbering	같은 연산은 하나만 남김	a + b, a + b → 한 번만 수행
Copy Propagation	중간 변수 제거	let x = y; let z = x; → z = y;
Loop-Invariant Code Motion	루프 밖으로 고정 연산 이동	for (...) { const x = 3 + 4; } → 루프 밖으로 이동

즉, 값이 “언제”, “어디서”, “무엇으로” 바뀌는지를 정확히 알 수 있기 때문에, 공격적인 최적화가 가능

3.4. Ignition과 TurboFan의 협업

단계	역할
1단계	Ignition이 바이트코드 생성 및 초기 실행
2단계	실행 중 반복된 함수/루프를 HotCode로 식별
3단계	TurboFan이 해당 코드 JIT 컴파일-> 네이티브 기계어 생성
4단계	이후부터는 기계어 코드가 재사용되어 성능 급상승

4. 결론

TurboFan의 핵심 : '실행하면서 배우고, 자주 쓰는 코드는 더 빠르게 실행되도록 만든다.'

V8은 코드 실행 중에도 계속해서 학습하고, 분석하고, 최적화한다.
이를 통해 한 번 실행된 코드라도 점점 더 빠르게 동작하게 만드는 것이 이 구조의 핵심이다.
V8은 JS 엔진이라기보단 하나의 런타임 머신에 가깝다.

V8 엔진이 좋아하는 코드 스타일과 싫어하는 패턴

JIT-friendly VS JIT-unfriendly

V8은 타입이 일관되고 구조가 고정된 코드를 좋아하며, 동적으로 구조가 바뀌는 객체나 예외적 흐름을 싫어한다.

1. V8이 좋아하는 코드 스타일 (JIT-Friendly)

패턴	설명
일관된 객체 구조	프로퍼티 순서와 수가 고정되어야 Hidden Class를 재사용할 수 있음
일관된 변수 타입	타입이 계속 바뀌지 않아야 인라인 캐싱이 잘 작동
짧고 명확한 함수	인라인 최적화 및 빠른 실행 가능
배열은 같은 타입만 사용	배열 내부에 숫자, 문자열, 객체가 섞이면 최적화 깨짐
클래스 사용 권장	클래스는 Hidden Class를 잘 활용하기에 성능상 이점 존재
반복문에서 상수는 루프 밖으로 이동	for 내부에서 불필요한 연산 제거 가능
try-catch는 제한적으로만 사용	예외 흐름은 최적화의 적 → 별도 핸들링 로직으로 분리 추천

2. V8이 싫어하는 코드 스타일 (JIT Unfriendly)

패턴	설명
동적 프로퍼티 추가/삭제	객체 구조(Hidden Class)가 계속 바뀌면 JIT 포기
타입이 자주 바뀌는 변수	let x = 1; x = '문자열'; → 인라인 캐싱 불가
배열에 타입 섞기	[1, 2, "3", {a: 1}] → 일반 객체 배열로 강등
delete 키워드 사용	Hidden Class 깨짐, JIT 무력화
객체에 프로퍼티 순서가 자주 바뀜	내부적으로 새 Hidden Class를 생성해야 함
with, eval 사용	스코프 예측이 어려워 최적화 불가 영역으로 간주됨
클로저 안에서 객체 참조가 바뀌는 패턴	캐시 무효화 발생 → 느려짐

3. 예시 코드

// JIT-friendly
function createUser(name, age){
    return {name, age}
}

// JIT-unfriendly
function createUser(name, age){
    const obj = {}
    if(name) obj.name = name;
    if(age) obj.age = age;
    return obj;
}

4. Hidden Class

V8의 핵심 최적화 전략 중 하나, JS처럼 동적인 언어에서도 정적 언어처럼 빠르게 객체에 접근할 수 있도록 만들어주는 구조

Hidden Class는 V8이 객체 구조를 정적으로 가정하고 최적화하기 위해 내부적으로 생성하는 '클래스 설계도'이다.

4.1 왜 필요한가?

JS는 객체 구조가 동적으로 바뀔 수 있는 언어이다.

const obj = {}
obj.name = "Baek"
obj.age = 32

obj는 객체지만, 실제로는 런타임에서만 구조가 결정됨
일반적으로는 프로퍼티 접근 시 obj['name']처럼 처리해야 함 -> 느림

그래서 V8은 객체가 만들어지는 순서와 구조를 분석해서 '이 구조는 이런 프로퍼티를 갖는다'라는 설계도(클래스)
를 내부적으로 생성한다 -> Hidden Class

4.2. Hidden Class 예시

const user = {}      // HiddenClass A 생성 
user.name = "Baek";  // HiddenClass B 생성 (name 있음)
user.age = 32        // HiddenClass C 생성 (name, age 있음)

user 객체의 구조가 변경될 때마다 V8은 새로운 Hidden Class를 생성한다.
객체마다 해당 클래스에 대한 포인터를 저장해 둔다.
프로퍼티 접근 시 이 클래스를 참조해서 빠르게 오프셋을 계산한다.

즉, user.name 은 내부적으로 'C클래스에서 name은 0번째 위치'처럼 인덱스로 바로 접근한다.

4.2.1. 의문

동적으로 객체를 만들 때 프로퍼티를 하나씩 추가하면,
예를 들어 빈 객체에서 시작해서 3개의 속성을 추가하면 Hidden Class가 3개 생긴다고 들었습니다.

그러면 A → B → C처럼 계속 생성된다는 건데,
이 Hidden Class들이 계속 메모리에 남는 거라면 너무 비효율적인 거 아닌가요?

어딘가에 저장되고 있다는 건, 결국 리소스 낭비 아닌가요?

그리고 한 번에 객체를 만들 때, 예를 들어
const obj = { name: "", age: "" }
처럼 선언하면 이건 Hidden Class가 생기는 게 아니라 그냥 객체일 뿐인가요?

Hidden Class는 단기적인 메모리 비용을 감수해서 장기적인 실행 속도 최적화를 이끌어내는 구조이며, 오히려 성능 향상에 훨씬 이득이다.

Hidden Class는 항상 생성된다 (정적/동적 상관없이)
- 객체를 만들 때 V8은 항상 Hidden Class를 생성한다.
- 즉, { name: "", age: "" }처럼 한 번에 선언하더라도 내부적으로는 Hidden Class가 만들어진다.
- 이 경우에도 Hidden Class는 생성된다. 다만 초기 상태에서 완성된 구조이기 때문에 추가 전이 없이 Hidden Class 1개만 생성되어 최적화 관점에서 가장 유리한 케이스가 된다.
Hidden Class가 계속 생성되는 것은 맞다.
- 각각의 상태 (A, B, C)에 대해 Hidden Class를 만들고, 내부적으로 클래스 전이 트리로 연결해 둔다.
그럼 메모리 낭비 아냐? → 아니다.
- Hidden Class는 재사용됨. 같은 구조를 가진 객체가 또 생기면 기존 Hidden Class를 그대로 쓴다.
- 또한 V8은 이 전이 정보를 효율적인 트리 구조로 관리하고, 메모리 낭비를 줄이기 위해 불필요한 클래스는 GC로 제거할 수 있다.
- 무엇보다, 이 구조 덕분에 obj.name 같은 속성 접근을 일반 객체처럼 느리게 하지 않고, 내부적으로는 정적 오프셋 기반으로 obj[0]처럼 빠르게 접근할 수 있음. → 이게 V8의 JIT 최적화 성능의 핵심
Hidden Class는 객체의 속성 추가 순서가 일치하면, V8은 기존에 만든 Hidden Class 전이 경로를 그대로 재사용한다

const obj = {};
obj.name = 'Kim';     // Hidden Class A → B
obj.age = 30;         // Hidden Class B → C

const obj2 = {};
obj2.name = 'Kimss';  // ❗ A → B (재사용됨)
obj2.age = 31;        // ❗ B → C (재사용됨)

V8 입장에서 보면 obj2도 똑같은 속성 추가 순서로 객체를 만들었기 때문에 Hidden Class A → B → C 전이 경로를 그대로 다시 따라감

포인트	설명
최초 객체	프로퍼티 추가 순서 따라 Hidden Class A → B → C 생성
다음 객체	동일한 순서로 추가되면 기존 전이 트리를 그대로 재사용
V8 입장	“이 구조는 이미 봤다!” → 새 Hidden Class 생성 ❌
장점	메모리 낭비 없이, 빠른 객체 구조 캐시 + JIT 최적화 가능

4.3. Hidden Class가 깨지는 경우

구조가 일관되지 않으면 V8은 Hidden Class를 재활용할 수 없고, 매번 새로 만들어야 해서 최적화가 깨진다.

순서 변경, delete, eval, 동적 프로퍼티 등

const user1 = {};
user1.name = 'A';
user1.age = 20;

const user2 = {};
user2.age = 30;
user2.name = 'B';  // 순서가 다르기 때문에 다른 Hidden Class 생성됨

4.4 Hidden Class를 잘 활용하기 위해서

프로퍼티는 항상 동일한 순서로 추가하기
- 속성 추가 순서와 구조가 같다면 Hidden Class는 무조건 재사용
- 그래서 “객체를 만들 때 항상 같은 순서로, 같은 구조로” 만드는 습관이 V8 JIT 최적화에서 매우 중요한 포인트
객체 구조는 가급적 초기화 시점에 완성하기
delete는 사용 자제 → undefined 할당 추천
클래스를 사용하면 Hidden Class를 일관되게 유지하기 쉬움

웹 성능 최적화 - 애니메이션 최적화

백씨네 — Wed, 2 Apr 2025 17:58:58 +0900

️ 애니메이션 최적화

쟁크(Jank) 현상

애니메이션이 부드럽지 않고 끊기는 현상

DOM 업데이트 시 Reflow가 발생함
Reflow는 레이아웃 계산과 Paint 재수행을 유발
이로 인해 프레임 드랍과 성능 저하 발생

Reflow

레이아웃을 다시 계산하는 과정

처리 순서

DOM + CSSOM 파싱
Render Tree 생성
Layout 계산 및 배치
Paint
Composite

Repaint

레이아웃 재계산 없이 화면을 다시 그리는 과정
예: color, background-color 변경 등

처리 순서

DOM + CSSOM 파싱
Render Tree 생성
Layout 계산 및 배치 (변경 없을 시 생략 가능)
Paint
Composite

애니메이션 성능 최적화 전략

부드러운 애니메이션을 위해 Reflow/Repaint를 최소화
가능하면 GPU 가속을 활용 (transform, opacity 등)

❌ Reflow를 유발하는 CSS 속성

레이아웃에 영향을 주는 속성들
width, height, margin, padding, border
top, left, right, bottom, display, position

❌ Repaint를 유발하는 CSS 속성

시각적 스타일에 영향을 주는 속성들
color, background-color, border-color, box-shadow

⭕️ Reflow & Repaint 모두 피할 수 있는 속성

GPU 렌더링 최적화 가능
transform, opacity

React Testing Tutorial(9) - findBy

백씨네 — Wed, 18 Sep 2024 16:27:57 +0900

findBy

React Testing Library에서 DOM요소를 찾을 때 많이 쓰이는 메서드 중 하나인 findBy는 비동기적으로 요소를 찾을 때 유용하다.
API 호출이나, 타이머처럼 일정 시간이 지난 후에 렌더링 되는 요소를 테스트할 때 주로 사용된다.

findBy는 Promise를 반환한다. 지정된 시간 내에 해당 요소를 찾으면 resolve, 그렇지 않으면 reject 된다.

사용시기

데이터 패칭 이후 나타나는 요소
setTimeout, setInterval 등으로 일정 시간이 지난 후 나타나는 요소
상태 변경으로 인한 렌더링 결과물

findBy와 getBy는 유사하지만 비동기 요소를 기다린다는 점에서 다르다.
promise를 반환하기 때문에 주로 async/await와 함께 사용된다.

const element = await findByText("로딩 완료")

작성 예시

import React, { useEffect, useState } from "react"

const UserProfile = () => {
    const [loading, setLoading] = useState(true)
    const [user, setUser] = useState("")

    useEffect(() => {
        setTimeout(() => {
            setUser("홍길동")
            setLoading(false)
        }, 2000)

    }, [])

    if (loading) {
        return <div>로딩 중...</div>
    }
    return <div>사용자 이름: {user}</div>
}

export default UserProfile

import { render, screen } from '@testing-library/react';
import UserProfile from './UserProfile';

test('사용자 이름을 API 호출 후 렌더링한다', async () => {
  render(<UserProfile />);
  expect(screen.getByText('로딩 중...')).toBeInTheDocument();
  const userNameElement = await screen.findByText('사용자 이름: 홍길동');
  expect(userNameElement).toBeInTheDocument();
});

위의 코드는 실패한다.

이유는 기본적으로 findBy가 기다리는 시간은 1000ms로 설정되어 있기 때문이다.
하지만 작성한 컴포넌트는 2000ms 뒤에 상태를 바꾸는 동작을 하기 때문에 실패하는 코드가 된다.

이를 해결하기 위해서 findBy~ ()의 3번째 인자값을 이용해서 시간을 지정할 수 있다.

const userNameElement = await screen.findByText("사용자 이름: 홍길동",{},{
    timeout:2000
})

다시 작성된 테스트코드를 보면 timeout을 이용해서 기다리는 시간을 늘려 2초를 기다리는 테스트 코드로 만들었다. 그 결과 해당 테스트 코드는 통과할 수 있게 되었다.

React Testing Tutorial (8) - getAllBy..., textMatch

백씨네 — Wed, 11 Sep 2024 20:41:27 +0900

getAllBy-

이전까지 getBy-를 이용해서 한 개의 요소를 찾는 방법을 배웠다. 여러 개의 요소가 있는 상황을 테스트하는 상황도 있을 것이다. 이때 사용할 수 있는 방법으로 getAllBy-가 있다.

getAllBy-는 getBy-와 비슷하지만, 여러 개의 요소를 찾을 때 사용한다.
이전 글들은 1개의 요소를 찾을 때 사용했지만, 이번 글에서는 여러 개의 요소를 찾을 때 사용하는 방법을 알아보자.

사용법

const elements = screen.getAllByRole("textbox")
expect(elements).toHaveLength(2) // textBox가 2개 있을 때

주의사항

getAllBy-는 요소가 없을 때 에러를 발생시킨다.
getAllBy-는 요소가 1개일 때도 에러를 발생시킨다.
getAllBy-는 요소가 2개 이상일 때 사용한다.
getAllBy-는 배열을 반환한다.

getBy-와 getAllBy-의 차이점

메서드	반환 값	요소가 없을 때	요소가 여러 개일 때	사용 시점
`getBy`	하나의 요소	에러 발생	첫 번째 요소만 반환	요소가 하나일 것으로 예상될 때
`getAllBy`	요소들의 배열	에러 발생	모든 요소를 배열로 반환	요소가 여러 개일 것으로 예상될 때

textMatch

textMatch는 React Testing Library에서 사용하는 옵션 중 하나로, 요소를 찾을 때 텍스트 일치 조건을 지정하는 방법이다.
주로 getByRole, getByText, findByText 등의 메서드와 함께 사용하며, 특정 텍스트와의 일치 기준을 설정할 수 있다.

사용법

단순 텍스트 일치

가장 기본적인 방식으로, 텍스트가 완전히 일치하는 경우에만 요소를 찾는다.

screen.getByText("Hello, World!", { exact: true })

exact 옵션은 텍스트가 완전히 일치하는지 여부를 설정하는 옵션이다. 기본값은 true이며, false로 설정하면 대소문자를 구분하지 않고 일치하는 요소를 찾는다.

정규 표현식 사용

정규 표현식을 사용하여 텍스트를 찾을 수 있다. 정규 표현식을 사용하면 텍스트의 일부만 일치하거나 대소문자를 구분하지 않고 찾을 수 있다.

screen.getByText(/hello/i) // 대소문자 구분 없이 hello를 찾음
screen.getByText(/world/) // world를 포함하는 텍스트를 찾음

함수 사용

함수를 사용하여 텍스트를 찾을 수 있다. 함수를 사용하면 텍스트를 동적으로 찾을 수 있다.
함수의 인자값은 2가지이다.

(content?: string, element?: Element | null) => boolean

// hello로 시작하는 텍스트를 찾음
screen.getByText((content, element) => content.startsWith("hello"))

// p 태그 중 hello를 포함하는 텍스트를 찾음
screen.getByText((content, element) => {
    return content.includes("hello") && element.tagName === "P"
})

React Testing Tutorial(7) - getByDisplayValue, getByAltText, getByTitle, getByTestId

백씨네 — Sun, 8 Sep 2024 19:48:10 +0900

getByDisplayValue()

폼 요소(<input/>,<textarea/> 등)에 표시된 텍스트 값을 기반으로 DOM요소를 찾는 데 사용된다.

주로 폼 입력 필드의 값을 확인하거나 해당 값을 가진 요소를 대상으로 테스트할 때 유용하다.

사용 예시

import { render, screen } from '@testing-library/react';

test('input 요소에 입력된 값을 찾습니다.', () => {
  render(<input value="테스트 값" />);

  const inputElement = screen.getByDisplayValue('테스트 값');
  expect(inputElement).toBeInTheDocument();
});

위 코드에서 getByDisplayValue('테스트 값')은 value 속성이 '테스트 값'인 input 요소를 찾는다.

getByAltText()

img, area, input 요소에서 alt 속성을 기반으로 찾는다. 주로 이미지를 대상으로 접근성 테스트나 이미지의 존재 여부를 확인할 때 유용하게 사용된다.

사용 예시

import { render, screen } from '@testing-library/react'

test('이미지 요소에 설정된 alt 텍스트를 통해 이미지를 찾습니다.', () => {
  render(<img alt="테스트 이미지" src="/test.png" />)

  const imageElement = screen.getByAltText('테스트 이미지')
  expect(imageElement).toBeInTheDocument()
})

getByTitle()

요소의 title 속성을 기반으로 DOM 요소를 찾는데 사용된다. title 속성은 주로 요소에 대한 추가 정보를 제공하는 툴팁 형태로 나타나며, 접근성을 개선하거나 사용자에게 추가적인 정보를 제공할 때 유용하다.

사용 예시

import { render, screen } from '@testing-library/react'

test('title 속성을 가진 요소를 찾습니다.', () => {
  render(<button title="저장">Save</button>)

  const buttonElement = screen.getByTitle('저장')
  expect(buttonElement).toBeInTheDocument()s
})

getByTestId()

DOM 요소를 특정 테스트 ID 속성을 통해 찾는데 사용된다.
요소를 선택하는 데 있어 명확한 방식으로 요소에 data-testid 라는 속성을 추가하여 테스트에서 쉽게 선택할 수 있도록 한다

보통 테스트에서만 사용되고, 실제로 UI에서는 보이지 않는다.

사용 예시

import { render, screen } from '@testing-library/react'

test('data-testid를 통해 요소를 찾습니다.', () => {
  render(<div data-testid="custom-element">테스트</div>)

  const element = screen.getByTestId('custom-element')
  expect(element).toBeInTheDocument()
});

getByTestId

React Testing Tutorial(6) - getByLabelText(), getByPlaceholderText(), getByText()

백씨네 — Sun, 1 Sep 2024 16:59:00 +0900

1. getByLabelText()

getByLabelText 함수는 폼 요소를 테스트할 때 주로 사용되다.
<label> 요소에 연결되어 있는 폼 요소(ex: input, textarea 등)를 쉽게 찾을 수 있게 도와준다.
label에 연결된 폼 요소는 보통 접근성을 위해서 사용되며, getByLabelText를 사용하면 사용자가 실제로 인터페이스와 상호작용하는 방식과 유사한 방식으로 테스트할 수 있다.

사용 예시

아래와 같은 폼 요소가 있을 때

<label for="username">Username</label>
<input id="username" />

<label for="password">Password</label>
<input id="password" />

테스트 코드를 작성 시 getByLabelText()를 이용해서 input요소를 선택할 수 있다.

text('폼 요소 테스트', () =>{
    render(<FormComponent/>)

    const usernameInput = screen.getByLabelText("Username")
    const passwordInput = screen.getByLabelText("Password")

    export(usernameInput).toBeInTheDocument()
    export(passwordInput).toBeInTheDocument()
})

getByLabelText('Username')은 "Username"이라는 텍스트가 들어간 <label>과 연결된 input 요소를 반환한다.

테스트에서 특정 폼 요소를 정확히 선택하고, 접근성을 높이는데 매우 유용하다.

만약 여러 개의 요소가 있을 시 테스트는 실패한다.

< form>
    <label htmlFor="email1">Email</label>
     <input id="email1" type="email" /> 

     <label htmlFor="email2">Email</label> 
     <textArea id="email2" type="email" />
</form>


// 위의 폼 요소에서 테스트를 진행할 때

test('중복된 레이블 텍스트를 가진 요소-실패케이스', ()=>{
    render(<Form />)
    const emailInput = screen.getByLabelText('Email')

    // 어느 'Email' 레이블과 연결된 요소를 선택할지 모르기 때문에 오류가 난다. 
    expect(emailInput).toBeInTheDocument()
})

test('중복된 레이블 텍스트를 가진 요소-성공케이스', ()=>{
    const emailInput = screen.getByLabelText('Email', { 
        selector: 'input' 
    })
    // selector 옵션을 사용하여 두 번째 textarea 요소를 선택합니다.
    expect(emailInput).toBeInTheDocument()
    const emailTextarea = screen.getByLabelText('Email', { 
        selector: 'textarea' 
    })
    expect(emailTextarea).toBeInTheDocument()
})

요소가 input과 textarea로 다르기 때문에 getByLabelText()의 두 번째 인자 값인 option을 이용하여 어떤 요소를 선택할지 지정을 하면 테스트를 성공할 수 있다.

2. getByPlaceholderText()

입력 필드('input', 'textarea' 등)에서 placeholder 속성값을 기반으로 요소를 찾을 때 사용한다.

label이 없는 경우에도 사용자 인터페이스에서 입력 요소를 쉽게 찾을 수 있게 도와준다.

사용 예시

function Form() {
  return (
    <div>
      <input placeholder="Enter your name" />
      <input placeholder="Enter your email" />
    </div>
  )
}




  // 폼 요소에 대한 테스트를 진행할 수 있습니다.
test('getByPlaceholderText를 사용한 요소 선택', () => {
  render(<Form />);

  const nameInput = screen.getByPlaceholderText('Enter your name');
  const emailInput = screen.getByPlaceholderText('Enter your email');

  expect(nameInput).toBeInTheDocument();
  expect(emailInput).toBeInTheDocument();
});

주로 사용되는 상황

label이 없는 입력 필드 : label이 없고 placeholder 속성만 있는 경우
placeholder 텍스트를 이용해서 간결하게 테스트를 작성할 때
사용자가 폼을 작성할 때 placeholder는 중요한 힌트를 제공하기 때문에, 이를 기반으로 테스트하는 것이 사용자 경험을 검증하는데 도움이 된다.

3. getByText()

가장 기본적이고 많이 쓰이는 함수로, 요소의 텍스트 콘텐츠를 기반으로 특정 요소를 선택할 때 사용한다.
주로 p태그, div태그, span 태그에 감싸있는 특정 텍스트를 선택할 때 사용한다.

사용예시

function Component() {
  return (
    <div>
      <h1>Welcome to My Website</h1>
      <p>This is a paragraph with some text.</p>
      <button>Click Me</button>
    </div>
  )
}


test('getByText()를 이용한 요소 선택', ()=>{
    renter(<Component />)

    const headingElement = screen.getByText('Welcome to My Website')
    expect(headingElement).toBeInTheDocument()

    const buttonElement = screen.getByText('Click Me')
    expect(buttonElement).toBeInTheDocument()

    const paragraphElement = screen.getByText('This is a paragraph with some text.')
    expect(paragraphElement).toBeInTheDocument();
})

위와 같이 h1, p, button 관계없이 text를 포함하는 요소를 선택할 때 사용한다.

기본적으로 getByText()는 정확하게 일치하는 텍스트를 찾는다 하지만 두 번째 인자값인 option을 이용해서 부분적으로 일치하는 텍스트를 찾을 수 있다.

test('getByText()를 이용한 요소 선택', ()=>{
    renter(<Component />)

    const headingElement = screen.getByText('Welcome to My', {
        exact:false
    })
    expect(headingElement).toBeInTheDocument()
})

exact를 false로 지정하여 부분적으로 일치하는 요소를 찾을 수 있고, 또 다른 방법으로는 selector를 이용해서 특정한 HTML 태그를 지정해서 사용할 수 있다.

test('getByText()를 이용한 요소 선택', ()=>{
    renter(<Component />)

    const buttonElement = screen.getByText('Click Me', { 
        selector: 'button' 
    }); 
    expect(buttonElement).toBeInTheDocument();
})

React Testing Tutorial(5) - getByRole, getByRole option

백씨네 — Sun, 25 Aug 2024 16:02:17 +0900

getByRole

접근성 트리를 통해 요소를 찾아내는 데 사용하는 메서드이다.
사용자가 페이지에서 상호작용 할 수 있는 요소를 찾아내는 데 도움을 준다.

주요 개념

1. 역할 기반 탐색

getByRole은 HTML의 role 속성에 따라 요소를 찾아낸다. 이 role은 스크린 리더와 같은 접근성 도구가 웹 페이지를 해석할 때 사용하는 중요한 속성이다.

2. 일치 기준

기본적으로 역할 기반으로 찾지만 추가적으로 name옵션을 사용하여 요소의 텍스트나 aria-label과 같은 접근성 속성도 검사할 수 있다.

3. 다양한 HTML 요소 탐색

버튼, 링크, 이미지, 체크박스 등 다양한 HTML 요소를 탐색할 수 있다.
<button>, <a>, <input type='checkbox'> 등은 각각 button, link , checkbox와 같은 역할을 한다.

'getByRole'을 사용하는 이유

접근성을 테스트하기 위해서 가장 권장되는 메서드이기 때문에 getByRole을 사용한다.
getByRole메서드를 사용하면 접근성 트리를 기반으로 요소를 찾기 때문에 실제 사용자 경험과 가장 가까운 테스트를 작성할 수 있다.

getByRole Option - name

getByRole('textbox')를 통해서 input 태그를 찾을 수 있다.
하지만 테스트하는 요소에서 input과 textarea 2개를 동시에 쓸 경우 테스트에서 실패를 한다.
그 이유는 input과 textarea는 text를 입력할 수 있는 동일한 역할로 인식하기 때문이다.

getByRole은 요소 한 개를 찾는 메서드이기 때문에 여러 요소를 찾게 되면 테스트에서 결과를 실패로 반환한다.

해결하기 위해서

이러한 문제를 해결하기 위해서 getByRole의 옵션 추가로 작성하여 해결할 수 있다.

name 옵션 이용하기
ex) getByRole(role, {name: ""})

접근 가능한 name

1. label

<label for="username">Username</label>
<input id="username" type="text"/>

이 경우, input 요소의 접근 가능한 이름은 "Username"이다.
대소문자를 구분하기 때문에 주의해서 사용해야 한다.

// pass
getByRole('textbox',{
    name: 'Username'
})

//fail
getByRole('textbox',{
    name:'username'
})

//(정규식을 사용해서 대소구분 없이 사용가능하다 : /username/i)
getByRole('textbox', { 
    name: /username/i   // 정규식 사용, 대소문자 무시
})

2. 버튼의 텍스트 콘텐츠

<button> , <a>, <input type="button"> 과 같은 요소의 텍스트 콘텐츠는 그 요소의 접근 가능한 이름이 된다.

<button>Submit</button>

이 경우, 버튼의 접근 가능한 이름은 "Submit" 이 된다.

getByRole('button', {name:"Submit"})

3. aria-label 속성

aria-label속성은 요소의 접근 가능한 이름을 명시적으로 정의한다.

<input aria-label="Search" type="text" />

이 경우, input 요소의 접근가능한 이름은 "Search"가 된다.

getByRole('textbox', { name: 'Search' });

getByRole Option - level

<>
    <h1>Job application form</h1>
    <h2>Section 1</h2>
</>

h1~h6의 경우 heading을 이용해서 요소를 찾을 수 있다.

하지만 위에서의 h1~h6는 모두 heading의 역할을 가지고 있기 때문에 구분을 해줘야 한다.

이 경우, 사용할 수 있는 option으로 level이라는 것이 있다.

h1~h6까지 차례로 level 1~6이다.

// <h1>Job application form</h1>
getByRole('heading', {
    level:1 
})


// <h2>Section 1</h2>
getByRole('heading', {
    level:2
})

여러 가지 options

getByRole에는 위에서 말한 2가지 옵션뿐 아니라 여러 가지가 더 있다.
name, level, hidden, selected, checked...

모두 비슷한 맥락으로 해당 요소를 찾을 수 있도록 도와주는 역할이고 option을 이용해서 더 명확한 요소를 지정할 수 있다는 것을 알고 있으면 될 것 같다.

더 자세한 옵션은 공식문서를 참고하면 된다.

https://testing-library.com/docs/queries/byrole

React Testing Tutorial(4) - RTL Queries

백씨네 — Thu, 15 Aug 2024 15:55:35 +0900

RTL Queries는 React Testing Library (RTL)에서 제공하는 DOM 요소를 선택하고 검증하기 위한 함수들을 의미한다.

RTL은 React 컴포넌트의 UI와 상호작용을 테스트하기 위해서 사용되는 라이브러리로 이 라이브러리의 핵심 기능 중 하나가 queries이다.

RTL에서 제공하는 주요 queries

1. getBy

조건에 맞는 단일 요소를 반환, 찾지 못하면 테스트가 실패한다.

// 'submit' 텍스트를 포함하는 요소를 반환
getByText('submit')

2. queryBy

조건에 맞는 단일 요소를 반환, 찾지 못하면 'null'을 반환
요소가 1개 이상 있을 경우 에러를 발생한다.

// 'submit' 텍스트를 포함하는 요소를 반환하거나 null을 반환
queryByText('submit')

3. findBy

비동기적으로 단일 요소를 찾으며, Promise를 반환
요소를 찾으면 해당 요소를 반환하고, 찾지 못하면 에러 발생

// 비동기적으로 'submit' 텍스트를 포함하는 요소를 찾는다.
findByText('submit')

4.getAllBy

조건에 맞는 모든 요소를 배열로 반환
하나도 없을 경우 테스트가 실패한다.

//'submit'텍스트를 포함하는 모든 요소를 배열로 반환
getAllByText('submit')

5. queryAllBy

조건에 맞는 모든 요소를 배열로 반환
요소가 없으면 빈 배열을 반환

// 'submit'텍스트를 포함하는 모든 요소를 배열로 반환
// 없으면 []
queryAllByText('submit')

6. findAllBy

비동기적으로 조건에 맞는 모든 요소를 배열로 반환한다.
Promise를 반환한다.

// 비동기적으로 'submit'텍스트를 포함하는 모든 요소를 반환
findAllByText('submit')

실제 사용하기

실제 쿼리를 형성하기 위해서는 예시에서 본 것처럼 접미사를 포함하여 작성해야 한다.

접미사는 Role, LabelText, PlaceHolderText, Text, DisplayValue, AltText, Title, TestId 가 있다.

접미사를 포함한 예시

getByRole()
queryByLabelText()
findByPlaceholderText()
getAllbyText()
queryByDisplayValue()
findAllByAltText()
getByTitle()
getByTestId()

getByRole() queryByLabelText() findByPlaceholderText() getAllbyText() queryByDisplayValue() findAllByAltText() getByTitle() getByTestId()

React Testing Tutorial(3) - Assertion, Matchers

백씨네 — Sat, 10 Aug 2024 13:24:09 +0900

Assertions

테스트에서 코드의 특정 조건이나 표현이 예상대로 작동하는지를 확인하는 구문을 의미한다.
테스트 중인 코드가 기대한 결과를 반환하는지, 특정 상태에 있는지를 확인하기 위해서 사용된다.

즉, Assertion은 코드의 동작이 기대와 일치하는지 확인해 주고, 예상과 일치하지 않을 경우 테스트를 실패로 표시한다.

테스트를 통과/실패로 만들어 예상과 실제 결과 간의 불일치를 조기에 발견할 수 있게 도와준다.

사용 예시

expect(value).toBe(expectedValue)

위의 구문이 Assertion으로 value가 expectedValue와 동일한지 검사한다.

Matchers

테스트 대상 코드의 결과를 예상한 값과 비교하는 데 사용되는 함수이다. expect와 함께 사용되고, 올바로 작동하는지 확인하는 Assertion을 만든다.

단순한 값을 비교하는 것뿐만 아니라, 요소 존재 여부, 텍스트 내용, 스타일 등 다양한 조건을 확인할 수 있다.

예를 들어 toBeNull, toBeTruthy, toContain 등이 있다.

jest에서 사용할 수 있는 matcher

https://jestjs.io/docs/using-matchers

DOM 테스트

DOM을 테스트하기 위해서 Jest DOM을 추가적으로 설치하여 테스트할 수 있다.
jest DOM을 이용하면 프런트엔드 프레임워크에서 컴포넌트를 테스트할 수 있다.

jest DOM을 이용하면 일반적인 Jest Matcher보다 DOM 요소에 특화된 매처를 제공하므로 훨씬 의미 있는 테스트를 진행할 수 있다.

기본적으로 jest에 포함되지 않은 toBeInTheDocument, toHaveTextContent, toBeVisible 등의 Matcher가 있다.

jestDOM에서 사용할 수 있는 Matcher

https://github.com/testing-library/jest-dom

jest-dom의 깃허브에서 사용할 수 있는 matcher와 언제 사용하면 좋을지에 대한 내용, 예시를 포함하고 있으니 확인해 보면 좋을 것 같다.

무엇에 대해서 테스트를 진행할 것인가?

늘 테스트 코드를 작성하고 싶다고 생각하고, 테스트 코드가 좋다는 것은 알고 있었다. 하지만 무엇을 테스트해야 하며, 어떤 것을 테스트할지 고민을 하다가 결국 못하는 상황의 반복이었다.

어떤 것을 테스트해야 할까?

테스트 코드에 대해서 명확하게 설정되어 있는 규칙은 없다. 하지만 리엑트에서 테스트할 가치가 있는 것에 대한 가이드라인은 있다.

컴포넌트가 오류 없이 잘 렌더링 되는가?
props와 함께 컴포넌트가 잘 렌더링 되는가?
다른 상태에서 컴포넌트가 잘 렌더링 되는가?
- 예를 들어, nav bar가 로그인 상태에서는 보이지만 로그아웃 된 상태에서는 안 보여야 하는 경우
컴포넌트가 이벤트에 올바르게 작동하는가?
- 예를 들어, 버튼이나, form 컨트롤 같은 컴포넌트에 적용할 수 있다.

어떤 것을 테스트하지 말아야 할까?

반대로 테스트를 하지 않는 것이 좋은 경우가 있다.

구현 세부정보
서드파티 코드 ( 내가 작성하지 않은 코드 )
- 다른 사람이 만든 라이브러리 같은 경우 테스트를 진행하지 않아도 된다.
사용자 관점에서 중요하지 않는 코드

이렇게 총 7가지의 가이드라인은 기초적인 것이며, 이것을 바탕으로 테스트 코드를 작성하면서 서비스를 구현하면 좋을 것 같다.

React Testing Tutorial (2) - Code Coverage

백씨네 — Fri, 2 Aug 2024 00:33:35 +0900

1. Code Coverage

테스트가 얼마나 코드베이스를 덮고 있는지 측정한다.
코드 적용 범위는 테스트된 소프트 웨어 코드의 양을 이해하는데 도움이 되는 측정 기준이다.
테스트의 품질을 평가하는 데 도움이 되는 매우 유용한 측정 기준이다.

Coverage의 종류

Statement coverage (명령문 커버리지)

명령문 커버리지는 코드의 각 명령문이 최소한 한 번은 실행되었는지를 확인한다.
코드의 모든 명령문이 실행되었는지 확인하여, 테스트가 충분히 이루어졌는지 확인한다.
아래의 예시에서는 2번 실행되었는지 여부를 체크할 수 있다.

function add(a,b) {
    let sum = a + b // 명령문 1
    return sum;  // 명령문 2
}

Branches coverage (브랜치 커버리지)

코드 내의 모든 조건문의 모든 분기가 실행되었는 지를 확인한다.
예를 들어 if, else, switch 등의 모든 가능한 경로가 테스트되었는지를 확인한다.
브랜치 커버리지는 if문의 true와 fasle 분기가 모두 실행되었는지 확인한다.

function isEven(numn){
    if(num % 2 === 0){ // 브랜치 1
        return true;
    }else{ // 브랜치 2
        return false;
    }
}

Function coverage (함수 커버리지)

코드 내의 모든 함수가 최소한 한 번은 호출되었는지를 확인한다.
즉, 테스트가 코드의 모든 함수를 호출했는지 평가한다.

function multiply(a, b) { // 함수 1 
    return a * b; 
} 
function divide(a, b) { // 함수 2 
    if (b !== 0) { 
        return a / b; 
    } else { 
        throw new Error("Division by zero"); 
    } 
}

Line coverage (라인 커버리지)

코드의 각 라인이 최소한 한 번은 실행되었는지를 확인한다.
코드의 정확성과 품질을 평가하는데 좋은 지표가 된다.

function calculateTotal(price, tax) {
    let total = price + tax; // 라인 1
    if (total > 100) { // 라인 2
        return total - 10; // 라인 3
    }
    return total; // 라인 4
}

2. Coverage 사용하기

coverage를 사용하기 위해서 --coverage 옵션을 추가하여 사용할 수 있다.
기존에 프로젝트에서 test라는 스크립트를 이용해서 테스트를 하고 있었고, coverage용 스크립트를 추가로 작성해 준다.

"scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject",
    "coverage": "react-scripts test --coverage" // test와 동일한 스크립트에 --coverage를 추가한다.
},

이렇게 작성하고 나면 npm run coverage를 이용해서 coverage 기능을 사용할 수 있게 된다.

실행해 보면 아래와 같은 결과가 나온다. 위에서 설명했던 커버리지를 종류별로 볼 수 있게 된다.
![[jest-4.png]]

퍼센티지가 높을수록 많은 코드를 테스트했다는 의미이다.

coverage에 --watchAll 옵션을 추가해서 사용하게 되면 파일이 변경될 때 자동으로 실행하는 것뿐 아니라 조금 더 자세한 결과를 볼 수 있다.

포함할 폴더 지정하기

jest coverage를 이용할 때 coverage에 감지되는 디렉터리를 지정할 수 있다.
이 또한, Script를 이용할 수 있다.

--collectCoverageFrom

collectCoverageFrom 옵션을 이용해서 코드 커버리지 수집 시 어떠한 파일을 포함할지를 지정할 수 있다.
특정 파일이나 디렉터리만 커버리지 리포트에 포함할 수 있다.

{
  "scripts": {
    "test": "react-scripts test",
    "coverage": "react-scripts test --coverage --watchAll --collectCoverageFrom='src/component/**/*.{ts,tsx}'"
  },
}

위의 스크립트를 통해서 src/component 안에 있는 ts, tsx 파일만 리포트에 포함시키도록 지정할 수 있다.

제외하고 싶은 파일 패턴

 "coverage" : "react-scripts test --coverage --watchAll --collectCoverageFrom='src/component/**/*.{ts,tsx}' --collectCoverageFrom='!src/component/**/*.{types, stories, constants,test,spec}.{ts,tsx}'"

collectCoverageFrom 옵션의 경우 연속해서 쓸 수 있다.
위의 예시는 ts, tsx 파일 앞에 types, stories, contants, test, spec 이 붙은 파일을 리포트에서 제외하겠다는 의미로 사용할 수 있다.

목표 설정하기

테스트를 진행하면서 해당 테스트의 코드 커버리지의 목표치를 coveragethreshold를 이용하여 설정할 수 있다.

이 옵션을 이용하여 각 커버리지에 대한 최소한의 커버리지 비율을 지정할 수 있고, 설정한 목표치에 충족하지 않으면 테스트가 실패한다. 목표를 설정하여 코드 품질을 유지하고 테스트 커버리지를 높일 수 있다.

coverageThreshold 사용하기

사용하는 방법은 package.json에 jest 필드를 이용하여 설정할 수 있다.

{
  "jest": {
    "coverageThreshold": {
      "global": {
        "branches": 80,
        "functions": 90,
        "lines": 90,
        "statements": 90
      },
      "./src/componentA.js": { 
          "branches": 70, 
          "functions": 80, 
          "lines": 85, 
          "statements": 85
       }
    }
  }
}

이 예시는 전역적으로 설정하는 것과 특정 파일에 대한 설정을 볼 수 있다.

설정된 커버리지 목표를 충족하지 못하면 테스트가 실패한다.

React Testing Tutorial (1) - Filtering, Grouping

백씨네 — Tue, 23 Jul 2024 13:34:21 +0900

Filtering Tests

Jest의 Watch 모드에서 특정 테스트만 실행하고 싶을 때, t,p를 누르면 된다.

p를 누르면 테스트 파일명을 입력할 수 있는 프롬프트가 나타난다. 테스트 파일명에 대한 정규식을 입력하면 해당 정규식을 만족하는 테스트 파일만 실행된다.

또 다른 방법으로는 t를 누르면 테스트명을 입력할 수 있는 프롬프트가 나타난다. t는 테스트명에 대한 정규식을 입력할 수 있게 해 준다. 이 경우 해당 정규식을 만족하는 테스트만 실행된다.

jest watch 모드

test name

file name

코드를 이용한 방법 - `test.only`, `test.skip`

test.only를 사용하면 해당 테스트만 실행된다. test.skip을 사용하면 해당 테스트는 실행되지 않는다.

test.only("this will be the only test that runs", () => {
    expect(true).toBe(false)
})

위 코드에서는 test.only가 사용되었기 때문에 해당 테스트만 실행된다.

test.skip("this test will be skipped", () => {
    expect(true).toBe(false)
})

위 코드에서는 test.skip이 사용되었기 때문에 해당 테스트는 실행되지 않는다.

Grouping Tests

`describe`를 이용한 그룹화

테스트를 그룹화하여 관리할 수 있다. describe 함수를 사용하면 된다.

describe(name, fn) 함수는 두 개의 인자를 받는다. 첫 번째 인자는 그룹의 이름이고, 두 번째 인자는 그룹에 속하는 테스트들을 정의하는 함수이다.

describe("group", () => {
    test("test1", () => {
        expect(true).toBe(true)
    })
    test("test2", () => {
        expect(true).toBe(true)
    })
})

위 코드에서는 group이라는 그룹에 test1, test2라는 두 개의 테스트가 속해있다.

describe 함수 또한 filtering을 할 수 있다. describe.only를 사용하면 해당 그룹만 실행된다. describe.skip을 사용하면 해당 그룹은 실행되지 않는다.

describe.only("group", () => {
    test("test1", () => {})
    test("test2", () => {})
})

describe.skip("group", () => {
    test("test3", () => {})
    test("test4", () => {})
})

그리고 describe 함수는 중첩해서 사용할 수 있다.

describe("group1", () => {
    test("test1", () => {})
    test("test2", () => {})
    describe("group2", () => {
        test("test3", () => {})
        test("test4", () => {})
    })
})

Filename Conventions

Jest는 테스트 파일을 찾을 때 특정한 파일명 규칙을 따른다. Jest는 __tests__ 디렉토리에 있는 파일과 test.js나 spec.js로 끝나는 파일을 찾아서 테스트 파일로 인식한다.

예를 들어 아래와 같은 파일 구조를 가진 프로젝트가 있다고 가정하자.

.
├──/__tests__
│└── my-test.js
└── my-test.spec.js

위 프로젝트에서 my-test.js와 my-test.spec.js 파일은 Jest에 의해 테스트 파일로 인식된다.

항상 테스트 중인 코드 옆에 테스트 파일을 두고 상대경로가 짧아지도록 하는 것이 좋다.

Aliases

it과 test

it과 test는 동일한 함수이다. 둘 중 어떤 것을 사용해도 상관없다. it은 test의 alias이다.

test("this is a test", () => {})
it("this is a test", () => {})

fit과 test.only

fit과 test.only는 동일한 함수이다. 둘 중 어떤 것을 사용해도 상관없다. fit은 test.only의 alias이다.

test.only("this is the only test that runs", () => {})
fit("this is the only test that runs", () => {})

xit과 test.skip

xit과 test.skip은 동일한 함수이다. 둘 중 어떤 것을 사용해도 상관없다. xit은 test.skip의 alias이다.

test.skip("this test will be skipped", () => {})
xit("this test will be skipped", () => {})

웹 페이지 렌더링 방식 이해: CSR, SSR, SSG, ISG

백씨네 — Wed, 10 Jul 2024 16:24:20 +0900

웹 페이지를 표시하는 방법

페이지를 렌더링 하는 방법에는 CSR, SSR, SSG, ISG 가 있다.

React를 처음 배울 때 CSR, SSR의 기본적인 차이점에 대해서 공부했었고, 이때의 개념으로 CSR, SSR을 사용해 왔다. 하지만 Next를 공부하면서 SSG, ISG에 대한 개념을 접하게 되었고 이 부분에 대해서 미흡하여 글을 작성했다.

1. CSR : 클라이언트 사이드 렌더링

특징
- 모든 렌더링 작업이 사용자 브라우저에서 진행된다.
- 페이지 로딩 후 필요한 데이터만 서버로부터 비동기적으로 불러와서 처리한다.
장점
- 사용자 인터랙션이 매우 빠르고, 애플리케이션의 동적인 부분을 효과적으로 처리할 수 있다.
단점
- 초기 로딩 시 모든 스크립트를 불러와야 해서 시간이 오래 걸릴 수 있다
- 검색 엔진 최적화(SEO)에 불리하다.
보안
- 코드 스플리팅 : JS 번들을 여러 개의 청크로 나누어 필요한 시점에만 로드하도록 구성한다.
- SSR 또는 프리렌더링 : 검색 엔진 최적화를 위해서 서버 사이드 렌더링으로 변경하거나 프리렌더링 기술을 사용하여 초기 페이지 로딩 시 검색 엔진이 크롤링할 수 있는 HTML을 제공한다.
- 동적 임포트 : 사용자 경험에 필수적이지 않은 컴포넌트는 동적으로 불러와서 처리한다

sequenceDiagram
    participant 사용자
    participant 브라우저
    participant 서버
    사용자->>브라우저: 페이지 요청     
    브라우저->>서버: HTML/CSS/JS 요청     
    서버->>브라우저: HTML/CSS/JS 응답     
    브라우저->>브라우저: 페이지 렌더링     
    브라우저->>서버: API 요청(데이터 필요)     
    서버->>브라우저: API 응답     
    브라우저->>브라우저: 데이터로 페이지 업데이트

2. SSR : 서버 사이드 렌더링

특징
- 서버에서 HTML을 완성하여 브라우저로 보내주고, 브라우저는 이를 받아서 화면에 표시한다.
장점
- 초기 페이지 로딩 속도가 빨라 사용자가 컨텐츠를 빠르게 볼 수 있으며, SEO에 유리하다.
단점
- 각 페이지 요청에 대해 서버에서 렌더링을 해야 하기 때문에 서버 부하가 크다.
- 사용자 인터랙션이 CSR에 비해 느리다.
보안
- 캐싱 : 페이지나 데이터를 캐시 하여 반복적인 서버 요청을 줄인다. 서버 부담을 감소하고 응답 시간을 단축할 수 있다.
- 부하 분산 : 로드 밸런서를 활용하여 요청을 여러 서버에 분산시키고, 서버의 과부하를 방지한다.
- 데이터 패칭 최적화 : 데이터를 필요한 최소한으로 불러오고, 사용자의 인터랙션에 따라 데이터를 추가로 불러오는 방식으로 구성한다.

sequenceDiagram
    participant 사용자
    participant 브라우저
    participant 서버
    사용자->>브라우저: 페이지 요청
    브라우저->>서버: 페이지 요청
    서버->>서버: HTML 렌더링
    서버->>브라우저: 렌더링된 HTML 응답
    브라우저->>브라우저: 페이지 표시

3. SSG : 정적 사이트 생성 (Static Site Generation)

특징
- 빌드 타임에 모든 페이지를 HTML로 미리 생성한다.
장점
- 매우 빠른 로딩 속도와 높은 보안성을 제공한다.
- 서버 부하가 거의 없다.
단점
- 사이트에 실시간으로 변하는 데이터를 표현하기 어렵다.
- 업데이트가 필요한 경우 전체 사이트를 다시 빌드해야 한다.
보안
- ISG : 특정 페이지만 재생성하여 전체 사이트의 재빌드 없이 최신 데이터를 반영할 수 있다.
- 클라이언트 사이드 자바스크립트를 사용하여 최신 데이터를 동적으로 불러온다.

sequenceDiagram
    participant 사용자
    participant 브라우저
    participant 서버
    사용자->>브라우저: 페이지 요청
    브라우저->>서버: HTML 요청
    Note right of 서버: 빌드 타임에 생성된 HTML
    서버->>브라우저: 정적 HTML 응답
    브라우저->>브라우저: 페이지 표시

4. ISG : 점진적 정적 재생성 (Incremental Static Regeneration)

특징
- SSG의 개념을 확장하여, 사이트가 이미 빌드된 후에도 특정 페이지를 요청받을 때 해당 페이지만 다시 생성하고 캐시를 업데이트할 수 있다.
장점
- 정적 사이트의 빠른 로딩 속도와 보안성을 유지하면서, 필요에 따라 특정 페이지만 업데이트할 수 있는 유연성을 제공한다.
단점
- 전체적으로 SSG에 비해 구현 복잡성이 증가한다.
- 재생성 주기 관리가 필요하다.
보안
- 재생성 전략 최적화 : 트래픽이 많은 시간대에 재생성을 피하고, 낮은 트래픽 시간대에 자동으로 페이지를 재생성하도록 스케줄링한다.
- 효율적인 캐시 관리 : 캐시 된 페이지의 만료 신간을 적절하게 설정하고, 필요할 때만 페이지를 재생성하도록 구현한다

sequenceDiagram
    participant 사용자
    participant 브라우저
    participant 서버
    사용자->>브라우저: 페이지 요청
    브라우저->>서버: HTML 요청
    alt 페이지가 캐시에 있음
        서버->>브라우저: 캐시된 HTML 응답
    else 페이지 재생성 필요
        서버->>서버: HTML 재생성
        서버->>브라우저: 새로운 HTML 응답
    end
    브라우저->>브라우저: 페이지 표시

각 렌더링 방식의 우선순위

아래의 상황은 일반적인 상황일 때를 말한 것이다. 각 프로젝트에 따라서 다를 수 있기 때문에 프로젝트에 맞춰서 선택해야 한다.

업데이트 주기에 따라 (업데이트 주기가 짧을수록)

CSR > SSR > ISG > SSG

SEO(검색 엔진 최적화)의 중요도에 따라

SSR > ISG > SSG > CSR

초기 로딩 속도에 따라

SSG > ISG > SSR > CSR

사용자 인터랙션의 복잡성에 따라

CSR > SSR > ISG > SSG

트래픽 부하 대응에 따라

SSG > ISG > SSR > CSR

보안성에 따라

SSG > ISG > SSR > CSR

네트워크 관리사 2급 실기 기출문제 - 라우터

백씨네 — Sat, 22 Jun 2024 01:31:43 +0900

모드 종류

사용자 모드 : Router>
관리자 모드 : Router#
설정모드 : Router(config)#
라인설정모드 : Router(config-line)#
인터페이스 모드 : Router(config-if)#

FastEthernet 0/0의 IP를 192.168.0.100/24 로 설정

접기/펼치기


en
conf t
interface fastethernet 0/0
ip add 192.168.0.100 255.255.255.0
no shutdown
exit
exit
copy r s

Serial 2/0 대역폭 2048로 설정

접기/펼치기


en

conf t

interface serial 2/0

bandwidth 2048

exit

exit

copy r s

Serial 2/0 클럭속도 72k

접기/펼치기

en
conf t
interface serial 2/0
clock rate 72000
exit
exit
copy r s

FastEthernet 0/0 Description : ICQA 설정

접기/펼치기


en

conf t

interface fastethernet 0/0

description ICQA

exit

exit

copy r s

Serial 2/0을 사용가능하게 IP 주소를 192.168.0.101/24와 두번째 IP 192.168.0.102.24로 설정

접기/펼치기


en

conf t

interface serial 2/0

ip add 192.168.0.101 255.255.255.0

ip add 192.168.0.102 255.255.255.0 secondary

no shutdown

exit

exit

copy r s

기본 게이트웨이 설정 IP: 192.168.0.10 +

접기/펼치기


en
conf t
ip default-gateway 192.168.0.10
exit
copy r s

기본 네트워크를 192.168.0.10 으로 설정

접기/펼치기

en
conf t
ip default-network 192.168.0.10
exit
copy r s

DHCP 네트워크를 192.168.100.0/24 서버이름 : icqa +

접기/펼치기


en

conf t

ip dhcp pool icqa

network 192.168.100.0 255.255.255.0

exit

exit

copy r s

Telnet password를 icqa로 변경 +

접기/펼치기


en

conf t

line vty 0 4

password icqa

login # 반드시 로그인

exit

exit

copy r s

Telnet 연결 후 3분 50초 동안 입력 없으면 세션 자동 종료 +

접기/펼치기


en
conf t
line vty 0 4
exec-timeout 03 50
exit
exit
copy r s

console 0의 패스워드를 ICQA로 설정하고 로그인

접기/펼치기


en

conf t

line console 0

password ICQA

login

exit

exit

copy r s

Serial 2/0 활성화

접기/펼치기


en

conf t

interface serial 2/0

no shutdown

exit

exit

copy r s

Hostname을 network2로 변경하고 console 0의 password를 router5로 변경 후 로그인 +

접기/펼치기


en

conf t

hostname network2

line console 0

password router 5

login

exit

exit

copy r s

인터페이스 정보를 확인하고 저장

접기/펼치기


en

show interface

copy r s

접속한 사용자 정보 확인 후 저장

접기/펼치기


en

show user

copy r s

라우팅 테이블 정보를 확인하고 저장 +

접기/펼치기


en

show ip route

copy r s

플래시 정보를 확인하고 저장 +

접기/펼치기


en

show flash

copy r s

프로세스 정보를 확인하고 저장 +

접기/펼치기

en
show process
copy r s

router에 access-list 1이 설정되어 있을 때 fastethernet 0/0에 적용하시오

접기/펼치기

pc -> router : in
router -> pc : out

en
conf t
ip access-group 1 in 
ip access-group 1 out
exit
exit
copy r s

router 1 에 OSPF 를 설정하시오 x

접기/펼치기

en
conf t
router ospf 1
network 192.70.100.0 0.0.0.255 a

정적 라우팅

접기/펼치기

en
conf t
ip route 192.188.20.0 255.255.255.0 176.18.1.2
exit
copy r s

Formik 이쁘게 사용하기

백씨네 — Mon, 17 Jun 2024 18:00:11 +0900

RHF은 폼 데이터를 DOM 수준에서 관리하기 때문에 처리가 효율적이고 상호 작용이 가능하다. 하지만상태를 사용하지 않기 때문에 현재 상태에 대한 추적이 어렵다. 현재 상태를 동기화하거나 조건부 논리를 폼상태로 관리해야 할 땐 어려울 수 있다.

이를 보안하기 위해서 RHF는 watch 함수를 이용해서 특정 필드나 모든 폼의 필드를 감시하고 상태 변화를 감지하는 기능을 추가했다.

Controlled Component(제어 컴포넌트)와 Uncontrolled Component(비제어 컴포넌트)

제어 컴포넌트는 사용자의 입력을 기반으로 자신의 state를 관리하고 업데이트할 수 있다.
'신뢰 가능한 단일 출처'로 만들어 두 요소를 결합시킨 것이다.

반대로 비제어 컴포넌트는 입력 데이터의 상태를 직접 관리하지 않는다. Dom 자체가 데이터를 처리하고 저장하는 역할을 한다. 전통적인 HTML 폼 입력과 유사하며, React에서는 ref를 이용해서 필요할 때 입력 요소의 현재 값을 직접 접근할 수 있다.

이외에 RHF와 Formik을 간단히 비교했을 때

RHF(React-Hook-Form)

종속성 없음
번들 크기 작음
리렌더 횟수 적음

Formik

다른 라이브러리의 종속성
번들 크기 큼 (RHF와 비교)
키 입력 시 상태 변경에 의해 리렌더

하지만 난 Formik을 쓴다.

현재 프로젝트를 진행 중인 입장에서 RHF과 Formik을 간단하게 비교해 봤다. 정말 간단하게 비교한 내용이고 성능과 렌더링 횟수를 직접 분석한 글도 찾아봤다.

그러면서 RHF을 쓰면 간단하게 쓸 수 있다고 생각한 것도 많았다. 하지만 현재 프로젝트를 진행 중이기 때문에 이미 Formik을 쓰고 있었다.
프로젝트를 진행하면서 Form 관련해서 더 최적화를 하고 싶었기 때문에 RHF을 알아보게 되었고, 유효성 검사가 편리하고, 코드의 간결성함에 매력을 느꼈지만, 단순히 이러한 이유 때문에 기존의 스택을 대체하는 것은 실질적인 문제가 있었다...

이미 사용 중인 기술을 뒤엎어 새로운 라이브러리를 사용한다는 것은 상당한 비용과, 시간이 들고 프로젝트의 기존 코드베이스에 깊이 통합된 라이브러리를 변경하면, 많은 부분에서 수정이 필요할 뿐 아니라 새로운 에러 발생 가능성이 있다고 판단했다.

그렇다고 지금부터 작성하는 코드를 RHF으로 변환하는 것은 프로젝트 빌드 크기에 영향을 미칠 수 있다고 생각했다.

그렇다면 어떻게 해야 할까?

내가 바꾸려고 생각했던 가장 큰 이유 중 하나는 Formik을 효과적으로 사용하고 있지 못한다고 판단했다. 처음 프로젝트에 참여할 때 Formik을 처음 쓰게 되었고, 기존 코드에 작성 방식을 따르며 사용하고 있었지만, 기존 코드를 제대로 알고 사용한 것이 아니었고, 문제없이 작동이 되었기에 더 깊게 생각하지 않았던 것이 이 사태를 불러온 것 같다.

그래서 공식문서부터 차근차근 읽으며 사용법을 다시 익히기로 했다

1. 기존에 쓰던 useFormik() 대신 사용하기

// before
const formik = useFormik({
    initialValues: {},    
    onSubmit: (values) => {},    
    validationSchema: Yup.object({}),
})

return (
    <form>
        <input/>
        <button type="submit"/>
    </form>
)


//after

return (
    <Formik initialValues={initialValues} onSubmit={handleSubmit} validationSchema={validationSchema}>
        {(props)=>(
            <Form>
                <Field></Field>    
                <button type="submit"></button>
            </Form>
        )}
    </Formik>
)

useFormik() 대신 Formik 컴포넌트를 이용하기로 했다.
Formik 컴포넌트를 직접 사용함으로써 리렌더링의 최적화를 할 수 있게 되었다.
기존에는 onChange로 인해서 키를 누를 때마다 리렌더링이 일어났지만 Formik, Form, Field 컴포넌트를 이용하면서 리렌더링이 최소화되었다.
(Form을 쓰는 상단에서 리렌더링이 되는 것이 아닌 Field 내부에서 리렌더링이 되는 것으로 추측됨.)

2. Formik 컴포넌트 안에 props 사용하기

Formik 컴포넌트 안에서 쓰는 props의 역할은 폼의 상태 관리와 동작 제어를 할 때 사용된다.

<Formik>
    {(props)=>(
        <Form>
            // formik의 values에 접근 가능
            {props.valuse} 
             //ddsfs//df
             <button disabled={props.isSubmitting}/>
        </Form>
    )}
</Formik>

대표적으로 2개를 사용해 봤는데, values를 이용해서 formik의 값에 접근할 수 있고 isSubmitting을 이용해서 onSubmit 함수가 동작하는 상태를 boolean 타입으로 알 수 있다.
이를 이용해서 버튼 비활성화나 버튼의 UI를 변경할 수 있고, 중복 제출을 막을 수 있다.

3. Field 컴포넌트

Field 컴포넌트는 기본적으로 input과 같다.
name
- formik의 values에 대응하는 키값을 넣어서 사용한다.
type
- input의 타입을 바꿀 수 있다 ( input, checkbox...)
as
- "select" , "textarea", "input"으로 사용할 수 있다.

<Field name="email" type="" as="" />

4. 유효성 검사 및 ErrorMessage 컴포넌트

Yup을 이용하여 유효성 검사를 하는 방식을 선택하였고, Yup에 유효성 검사로직이 잘 구현되어 있기 때문에 해당 라이브러리를 추가 설치하여 사용했다.

npm install Yup

Formik의 props 중 validationSchema를 이용하여 적용하였다.

/*

valuse = {
    name : ""
    emaile :""
    option : [
        {id:"",value:""}
        {id:"",value:""}
    ]
    checked : []
}

*/


const validationSchema = Yup.object({
    // string 타입검사
    name: Yup.string().required('필수 입력사항입니다.'),
    //string, email 형식검사
    email: Yup.string().email('이메일 형식이 아닙니다.').required('필수 입력사항입니다.'),
    // 배열의 각 요소에 대한 검사
    option: Yup.array().of(
        Yup.object().shape({
            value: Yup.string().required('필수 입력사항입니다.'),
        }),
    ),
    // 배열 타입의 value에 대한 검사
    checked: Yup.array().min(1, '최소 1개 이상 선택해주세요.'),
})

<Formik validationSchema={validationSchema}>
    // 중략..
    <div>
        email
        <Field name="email" type="" as="text" />
        <ErrorMessage name="email" component={'div'} />
    </div>
</Formik>

는 유효성 검사 후 error에 대해서 지정한 message를 출력해 준다.

중요한 것은 component이다.
간혹 ErrorMessage에서 component에 CSS가 적용이 안된다고 하는데

component를 안 쓰게 되면 text로 들어가기 때문이다.

(ErrorMessage의 CSS가 적용이 안된다면 component를 확인해 보길...)

또한 compnent를 이용하면 컴포넌트를 이용하여 만들 수 있다

위에 1은 input에 대한 CSS가 전혀 없지만 기존에 만든 Input 컴포넌트를 이용해서 component속성에 넣어주면 위와 같이 적용된다

Field, ErrorMessage 컴포넌트에서 모두 사용가능

<div>
    email
    <Field name="email" component={Input} />
    <ErrorMessage name="email" component={'div'} className="text-xl text-fm-text-800" />
</div>

5. 중복되는 Field 코드 제거

Form을 만들 때 보통 여러 개의 input과 같이 만들게 될 것이다.
그러면 각 value 마다 Field, ErrorMessage를 만드는 것은 매우 코드가 지저분하게 보일 수 있다.

<>
    <div>
        name:
        <Field name="name" />
        <ErrorMessage name="name" component={Button} />
    </div>
    <div>
        id:
        <Field name="id" />
        <ErrorMessage name="id" component={Button} />
    </div>
    <div>
        pw:
        <Field name="pw" />
        <ErrorMessage name="pw" component={Button} />
    </div>
</>

이를 조금 더 간단하고, 재사용성을 늘리기 위해서 아래와 같이 묶어서 사용할 수 있다.

const FormikInput = ({ label, ...props }) => {    
    const [field, meta] = useField(props.name) // 공식문서에는 props로 되어있는데 TS오류로 props.name을 쓰면 문제 없이 작동했다. (이유를 모르겠네....)

    return (
        <div>
            <label htmlFor={props.name}>{label}</label>
            <Input {...field} {...props} />
            {meta.touched && meta.error ? <Button>{meta.error}</Button> : null}
        </div>

    )
}

return (
    // 중략
    <FormikInput label="name" name="name" />
    <FormikInput label="id" name="id" />
    <FormikInput label="pw" name="pw" />

)

6. FieldArray: 값이 배열인 필드 (ex. checkbox)

체크박스에 대한 formik을 사용할 때 보통 value의 타입이 배열일 것이다.

//예를 들면
initalValues = {
    option: [
        { id: 1, title: 'option1', value: '1' },
        { id: 2, title: 'option2', value: '1' },
    ],
}

이때는 를 이용한다.

<FieldArray name="option">
    {(arrayHelper) => (
        <>
        {values.option &&
            values.option.length > 0 &&
            values.option.map((option, index) => (
                    <div key={option.id}>        
                        <div>{option.title}</div>
                        <Field name={`option.${index}.value`} />
                        <Button
                            type={'button'}        
                            onClick={() => arrayHelper.remove(index)}
                            className="inline"
                        >
                            -
                        </Button>
                        <ErrorMessage
                            name={`option.${index}.value`}
                            component={'div'}
                            className="text-xl text-fm-text-800"
                        />
                    </div>
                ))}
            // 배열에 추가하는 버튼
            <Button
                type="button"
                onClick={() =>
                    arrayHelper.push({
                        id: values.option.length + 1,
                        title: `option${values.option.length + 1}`,
                        value: '',
                    })
                }
            >
                +
            </Button>
        </>
    )}
</FieldArray>

간단하게 구현한 FieldArray 컴포넌트이다.
arrayHelper를 통해서 option의 배열옵션을 사용할 수 있다.

그래서 버튼의 onClick 이벤트를 보면 arrayHelper.remove, arrayHelper.push 등 배열 메서드를 사용할 수 있다.

새로운 프로젝트를 진행했다면 React-Hook-Form을 썼을 것 같지만 지금 내 상황에서는 Formik을 더 잘 쓰는 것이 낫다고 생각했고, 더 잘 쓰기 위해서 공식문서를 살펴봤다.

RHF을 한 번도 써본 적이 없기 때문에 직접적인 비교를 할 수는 없지만, Formik이 나쁜, 못 쓸만한 라이브러리는 아니라고 생각한다.

상태를 이용한 Form 데이터 관리가 많다면 Formik도 좋은 선택지인 것 같다.

웹페이지 성능 최적화 - 웹사이트 로딩시간을 6.3초에서 0.6초로 줄이기

백씨네 — Fri, 19 Apr 2024 18:23:38 +0900

문제

프론트엔드 개발에서 사용자 경험은 매우 중요하다.
이를 향상시키기 위해서 'Lighthouse'라는 도구를 활용할 수 있다. 이 도구는 현재 구현 중인 웹사이트를 분석하여 개선이 필요한 부분을 알려주고, 어떤 점을 개선해야 할지 알려준다.

(성능 참.. 처참하다...)

결론을 먼저 보여주자면

단순히 숫자로 보면 성능점수가 2배로 증가했다.
다른 것보다 LCP가 6.3초에서 0.6초로 끌어올렸다.

분석 및 해결

사실 앞의 문제와 결론을 보면 약간의 어그로성이 있다..^^
누군가는 나랑 비슷한 상황이 있을 것 같아서, 이런 방법을 초기에 생각하지 못해서 도움이 될까 블로그에 작성했다.

환경

Next v13.5.6
tailwind
S3 - 이미지 관리

위에 문제를 보면 내 웹사이트는 LCP에서 가장 큰 문제가 있었다.

LCP는 웹페이지 로딩 성능을 측정하는 지표이고, 사용자가 페이지를 방문했을 때 가장 큰 컨텐츠 요소가 화면에 완전히 표시되기까지 걸리는 시간을 나타낸다.

화면에 완전히 표시되는 것을 기준으로 하기 때문에 사용자 경험에 직접적인 영향을 미친다.

이를 해결하기 위해서 가장 먼저 생각했던 방법은 이미지의 크기를 줄이는 것이라 생각했다.

1. 이미지 크기 줄이기

사용자가 사이트를 방문했을 때 이미지를 요청해서 다운받는 과정이 있다. 이미지가 크면 그 이미지를 다운로드하고 보여주기까지 느릴 수밖에 없다고 생각했고 이미지 크기를 줄이기로 했다.

1-1. 업로드하는 S3에 avif, webp 확장자로 올리기

이미지를 png로 올리는 것이 아니라 직접 avif 확장자로 변환해서 업로드하는 방식으로 바꿔봤다.
기본적으로 불러오는 이미지의 크기가 작기 때문에 속도에 개선은 됐지만 좀 미미한 것 같았다.

1-2. Next.js에서 제공하는 최적화

Next.js는 이미지에서 최적화 기능이 제공된다.

직접 이미지를 avif나 webp 방식으로 변환해서 올리는 과정은 중간에 변환하는 과정이 있어서 불편하다...

하지만 next에서 기본제공하는 것이 있었다..

<Image
    // unoptimized // default : false
/>

"unoptimized" 기능은 기본적으로 꺼져있다. 메인화면의 Visual(banner)를 압축하지 않고 보여주겠다며 작성했었는데.. 너무 안 좋은 선택이었다. ( 가만히 두면 될걸.....ㅋㅋ)

그래서 unoptimized = {false} 돌려놨다. ( 정확히는 해당 속성을 지웠다.)

그리고 next.config.js를 수정하였다.

//next.config.js

images: {
    formats: ['image/avif', 'image/webp'],
},

이미지의 포맷을 avif와 webp로 지정하였다.

이렇게 했을 때 기존보다 약간의 개선은 있었지만 드라마틱한 변화는 없었다.

2. Visual 컴포넌트 수정

이 부분에서 좋은 결과를 얻었는데, 웹 성능을 크게 고려하지 않고 화면을 만들다 보니 신경을 쓰지 못했던 부분이었다.

핵심은 클라이언트 사이드 -> 서버사이드 컴포넌트로 변경했다.

현재 만든 웹사이트는 반응형을 고려하여 작업을 하다 보니 View port에 따라서 맞는 이미지를 보여주는 식으로 작업을 했다. 그래서 클라이언트 사이드에서 viewport를 체크하고 브레이크 포인트에 따라서 조건부렌더링을 이용해서 작업했는데, 이 부분이 LCP 성능 저하의 큰 영향이 있었다.

그래서 서버사이드에서 HTML을 생성해서 브라우저에서 받아 화면이 그려지고 클라이언트 측에서 뷰포트를 측정하고 맞는 이미지를 가져와서 사용자에게 보여주는! 이 과정으로 인해 느렸던 것이다.

그래서 클라이언트 사이드에서 서버사이드로 변경하였다.

기존

// 기존

const Visual = () =>{
    const [client, setClient] = useState(false)
    const renderSize = useRecoilValue(SettingState) // 상태로 가지고 있었음..
    useEffect(() => {
        setClient(true)
    }, [])
    if (client)
        return (
         <div className="relative h-[260px] w-full justify-center overflow-hidden md:h-[480px] pc:h-[400px]">
            {renderSize === 'mobile' ? (
                <Image
                    src={s3.path/main_mobile}
                    alt={'banner'}
                    fill
                    sizes="100%"
                    priority
                />
            ) : renderSize === 'pc' ? (
                <Image                
                    src={s3.path/main_pc}
                    alt={'banner'}
                    fill
                    sizes="100%"
                    priority
                />
            ) : (
                <Image
                    src={s3.path/main_tablet}
                    alt={'banner'}
                    fill
                    sizes="100%"
                    priority
                />
            )}
        </div>
    )
}

변경


const Visual = () =>{
    return (
        <div className="relative h-[260px] w-full justify-center overflow-hidden md:h-[480px] pc:h-[400px]">
            <Image
                className="block md:hidden"
                src={s3.path/main_mobile}
                alt={'banner'}
                fill
                sizes="100%"
                priority
            />

            <Image
                className="hidden md:block pc:hidden"
                src={s3.path/main_tablet}
                alt={'banner'}
                fill
                sizes="100%"
                priority
            />

            <Image
                className="hidden pc:block"
                src={s3.path/main_pc}
                alt={'banner'}
                fill
                sizes="100%"
                priority
            />
        </div>
    )
}

이런 식으로 모든 필요 이미지를 처음에 만들고 CSS의 Display:none/block과 미디어쿼리를 이용해서 사용자에게 보일 요소와 안보일 요소를 지정한다.

결과

결과는 처음에 보여준 사진처럼 6.3초에서 0.6초로 초기 화면을 보여주는데 많은 이득을 챙길 수 있었다. 모든 페이지에 이렇게 해야 한다는 것은 아니지만 적어도 처음 들어오는 메인화면의 Visual 영역은 이렇게 해서 웹사이트에서 이탈을 막을 수 있으면 더 좋을 것 같다.

고려해야 할 점

1. 이미지 최적화

처음 진입할 때 이미지를 S3에서 요청해서 가져온다. 이 부분에서 이미지의 크기가 컸다면 아마 시간은 더 걸렸을 것이다. 하지만 위에서 첫 번째 해결방법으로 이미지를 최적화했던 방식을 같이 생각해 보면 기존엔 300KB의 이미지를 불러왔지만 20KB 대 3개(각 디바이스)의 이미지로 가져온 것으로 단순 산술로도 충분히 이득인 작업이었다고 생각한다.

2. 슬라이드

아직 이 부분은 구현하기 전이지만 슬라이드 배너일 경우 5장의 슬라이더면 15개의 이미지가 나올 것 같다.. none/block 방식으로 모든 이미지를 미리 요청하고 화면을 보여주는 것이 맞는 방법일지는 확실하지 않지만 나쁘지 않았던 방식이라 생각한다. 다른 웹 몇 군데에서도 이렇게 하는 것 같으니... 일단 더 찾아봐야 할 것 같다.

V8 엔진 메모리 구조 - 힙(Heap)과 스택(Stack)

백씨네 — Mon, 11 Mar 2024 16:12:41 +0900

자바스크립트는 싱글 스레드이기 때문에 V8은 자바스크립트 하나의 컨텍스트당 한 개의 프로세스를 사용한다. 만약 서비스 워커를 사용한다면 워커 또한 각각 새로운 V8 프로세스를 생성한다.

실행 중인 프로그램은 V8 프로세스에서 할당된 일정량의 메모리로 표현되고 이를 Resident Set이라고 한다.

V8 프로세스(Resident Set) 하나는 크게 하나의 힙 메모리와 스택 메모리로 나뉜다.

스택(Stack) 메모리

스택 메모리는 함수 호출과 실행 컨텍스트, 그리고 원시타입의 변수 값을 저장하는 데 사용된다.

실행 컨텍스트와 함수 호출
- 함수 호출 시 생성되는 실행 컨텍스트를 순서대로 저장하는 구조이다. 실행 컨텍스트는 해당 함수의 변수, 매개변수, 반환 주소 및 기타 실행에 필요한 정보를 포함한다.
- 함수가 호출될 때마다 새로운 실행 컨텍스가 스택의 맨 위에 push 되고, 함수 실행이 완료되면 pop 되어 제거된다.
- LIFO(Last In, First Out) 원칙을 따른다.
원시 타입의 데이터 저장
- 스택 메모리는 원시 타입의 데이터를 저장하는 데 사용된다. 원시 값은 변수에 직접 할당되며, 함수의 실행 컨텍스트 내에 위치한다.
- 원시 타입의 데이터는 값 자체가 스택에 저장되기 때문에 데이터를 전달할 때는 값의 복사본이 생성되어 전달된다.
효율적인 메모리 관리
- 스택 메모리는 자동으로 관리되며, 함수 호출과 반환 과정에서 데이터의 할당과 해제가 빠르게 이루어진다.
- 재귀 함수의 과도한 호출로 인해서 스택 오버플로 가 발생할 수 있다.
  - 스코프와 변수의 접근성
  - 스택에 저장된 변수는 해당 변수가 선언된 함수의 스코프 내에서만 접근할 수 있다.
  - 함수가 종료되면 해당 함수의 실행 컨텍스트와 함께 스택에서 제거되므로, 해당 함수의 로컬변수에는 더 이상 접근할 수 없다.

힙(Heap) 메모리

힙은 동적으로 할당된 객체들이 저장되는 메모리 영역이다. JS에서 객체, 문자열, 클로저 등은 힙에 저장된다. 힙은 구조화되지 않은, 즉 고정되지 않는 메모리 할당에 사용되며, 가비지 컬렉터(GC)에 의해 관리된다.

New Space (Young Generation)
- New space는 빈번하게 발생하는 소규모의 가비지 컬렉션을 위해 설계된 영역이다.
- 새로 만들어지는 모든 객체를 저장하고 이 객체들은 짧은 생명주기를 가진다.
- 주로 Scavenge GC(마이너 GC) 알고리즘을 사용한다.
- Semi-space라 불리는 두 개의 부분으로 나뉜다. (From-sapce와 To-space)
- New Space 영역의 크기는 --min_semi_space_size와 --max_semi_space_size V8엔진의 플래그 값을 사용해 조정할 수 있다.
- 일부 객체가 여러 번의 가비지 컬렉션을 살아남는 경우, 더 긴 생명주기를 가질 가능성이 높다고 판단되어 Old Space로 이동된다. (promotion)
Old Space (Old Generation)
- New Space에서 살아남은 객체들이 이동하는 영역이다.
- Mark-Sweep 및 Mark-Compact GC(메이저 GC) 알고리즘을 사용한다. (Incremental Marking 알고리즘도 있다.)
- Old Space 영역의 크기는 --initial_old_space_size와 --max_old_space_size V8 엔진의 플래그 값을 사용해 조정할 수 있다.
- Old pointer space, Old data space로 나뉜다.
  - old pointer space : 살아남은 객체들을 가지며, 이 객체는 다른 객체를 가리키는 포인터를 포함하고 있어, 객체 간의 관계를 나타낸다.
  - 스칼라 값(원시 데이터)이나 포인터가 아닌 데이터를 저장한다. number, string, boolean 값 등이 포함될 수 있다.
Large Object Space
- 일반적인 가비지 컬렉션 과정에서 처리하기에 너무 큰 객체들은 별도로 관리하기 위한 공간이다. 대형 객체들은 이 공간에 직접 할당되며, 가능한 복사를 피하여 관리된다.
Code Space
- JIT 컴파일러에 의해 컴파일된 실행 가능한 코드를 저장한다. 이 공간은 코드를 효율적 실행을 위해 최적화되어 있다.
Cell Space, Property Cell Space, Map Space
- 각 영역은 모두 같은 크기의 객체들을 포함하며, 특수한 목적을 가진 메모리 공간들이다. 그래서 저장되는 객체의 종류에 제약을 두어 가비지 컬렉션보다 단순하고 효율적으로 만든다.
- Cell Space : Cells를 저장하는 공간으로 Cell은 작은 데이터 조작이나, 단일 포인터를 저장하는 데 사용한다. 간단한 데이터 구조나 참조를 위한 공간으로 활용할 수 있다.
- Property Cell Space : Property Cells를 저장하는 공간이다. 객체의 속성에 대한 메타 데이터나 속성의 값 자체를 저장하는 데 사용한다. 객체의 속성정보를 중앙화하여 관리함으로써, 속성 접근 시의 성능 최적화에 기여한다.
- Map Space : Map은 V8 엔진에서 객체의 구조를 설명하는 데 사용되는 중요한 메타데이터이다. 객체의 타입, 속성의 구조, 프로토타입 체인 정보 등을 담고 있다. 이를 통해 객체의 속성 접근과 타입 최적화가 이루어진다. 객체 지향 프로그래밍에서의 클래스와 유사한 역할을 함

출처 : ToastUI 블로그 -https://ui.toast.com/weekly-pick/ko_20200228

Mockoon을 활용한 프론트엔드 개발 효율성 향상: 가상서버 및 Proxy 설정

백씨네 — Sun, 3 Mar 2024 14:42:29 +0900

1. Mockoon이란?

Mockoon은 로컬 환경에서 REST API 모킹을 설계하고 실행할 수 있는 가장 간편하고 빠른 방법을 제공한다. 또한 시간을 절약할 수 있고, OpenAPI 사양과 호환이 되는 완벽한 도구이다. (출처 : https://mockoon.com/)

Mockoon을 사용하는 이유

문제 발생

시작은 개발을 진행하면서 일반적인 플로우는 아래와 같을 것이다.

(2~3번이 바뀔 수 있고, 같이 진행될 수 있지만...)

하고 싶은 말은 백엔드가 만들어져야 프론트엔드가 확실하게 만들어진다. 이다.

현재 우리 팀은 프론트엔드는 백엔드가 작업을 할 때 퍼블리싱을 하고, json파일을 만들어서 필요한 데이터를 임시로 만들어서 작업을 한 후 백엔드가 완료가 되면 프론트에서 API를 연결하여 실제 백엔드에서 오는 요청에 따라서 처리하는 과정으로 만들고 있다.

위와 같은 병목 현상이 있었고, 임시 데이터를 실제 API 및 실제 요청 데이터로 바꾸면서 생기는 에러, 딜레이(정적인 데이터가 아니라 요청해서 가져오는 과정이기 때문에...)를 컨트롤할 수 없고 API가 완성된 후 다시 시간을 들여서 고쳐야 했다.

해결 방법

위의 문제를 파악한 후 들은 생각은 아래와 같다.

실제 백엔드 API와 같은 결과를 줄 수 있는 서버를 열어서 프론트에서 요청과 응답으로 확실하게 화면을 만들기

그러면서 한편으로 생각한 것은 당장 프론트도 만들기 벅찬데 무슨 서버까지 관리를 하냐... 그러면서 Mocking에 대해서 찾아보던 중 Mockoon에 대해서 알게 되었다.

Mockoon은 무엇인가?

Mockoon의 핵심 기능은 처음 설명한 것과 같다. 로컬 환경에서 REST API 모킹을 할 수 있다는 것이다.

쉽게 말하면 API가 없지만 만들어서 쓸 수 있다는 것이다.

Mockoon은 로컬 환경에서 REST API 모킹을 설계하고 실행할 수 있는 가장 간편하고 빠른 방법을 제공한다. 또한 시간을 절약할 수 있고, OpenAPI 사양과 호환이 되는 완벽한 도구이다.

1. 로컬 환경에서 REST API 모킹을 설계하고 실행할 수 있다.

나는 Mockoon을 처음 보자마자 POSTMAN이 떠올랐다. 그래서 간단한 기능을 쉽게 쓸 수 있을 것이라 생각했다. (앱을 설치해서 사용한다. CLI로도 사용할 수 있다.)

우리 팀은 프론트랑 백엔드랑 분리되어 있으며 프론트에서 API를 요청하는 곳이 DEV환경 서버에 직접 요청해서 가져온다. 그래서 dev환경 서버에 배포되어 있지 않은 API를 접근할 수 없다.

하지만 Mockoon을 이용하면 간단하게 로컬환경에서 서버를 열고, 해당 서버에 엔드포인트를 만들어서 요청을 하고 받을 수 있다.

get요청으로 /newTest로 엔드포인트를 지정해서 만든 것이다. 왼쪽에 보면 localhost:5555로 서버가 되어있는 것이 보일 것이다.

즉, newTest는 http://localhost:5555/newTest 로 요청을 보내면 {"test":true}를 응답으로 받는 것이다.

이렇게 간단하게 로컬환경에서 설정 및 사용할 수 있다. (뒤에서 자세히 설명할 예정)

2. OpenAPI 사양과 호환

Swagger에서 캡처한 화면이다.
여기서 OAS3가 핵심인데, OAS는 OpenAPI Specification 3.0으로 RESTful API를 위한 표준 언어에 구애받지 않는 인터페이스 정의이다. 이 사양을 통해 사람과 컴퓨터 모드 소스코드, 추가문서, 네트워크 트래픽 검사 없이도 서비스의 기능을 발견하고 이해할 수 있다.

Swagger는 OpenAPI 사양을 활용한 것이고 이걸 Mockoon에서도 사용할 수 있다는 의미이다.

2. Mockoon-설치

1. Mockoon 설치

1-1. 설치하기

https://mockoon.com/

공식 홈페이지에서 다운로드를 이용해서 진행할 수 있다.

각 OS에 맞는 앱을 설치하거나, CLI 환경을 이용해서 사용할 수 있다.

나는 앱을 설치해서 사용했고, Docs 기능별로 CLI를 사용하는 방법도 있으니 찾아보면서 하면 어렵지 않을 것이다.

2. Mockoon 세팅

2-1. 기본 세팅

setting 탭에서 5555라고 쓰여있는 곳이 port를 의미하는 것이다.
로컬 환경에서 mocking을 위한 툴이기 때문에 localhost:port로 진입이 가능하다.

중요 !! : Router 탭 옆에 재생버튼을 눌러야 서버가 열린다.

2-2. router 설정

기본적인 router는 +를 이용해서 HTTP route로 설정할 수 있다.
Method를 선택하고, End-Point를 지정한 후 응답 body를 작성해 주면 된다.
원한다면 응답 코드도 바꿀 수 있고, 중간에 Response 1 옆의 + 를 이용하면 여러 시나리오를 만들 수 있다.

200, 401,404 등등... 그리고 사용해보지 않았지만 응답을 랜덤 하게 주는 것도 가능해서 랜덤 한 응답에 대응하는 것도 미리 구현할 수 있는 것 같다.

이렇게 하면 기본적인 http:localhost:5555/newTest 라우터가 완성됐다.

2-3. Header 설정

작업을 하면서 CORS error가 발생해서 해결하기 위해 Header에 설정을 추가해 줬다.

Header 탭을 이용해서 모든 요청에 대해서 지정한 Header를 포함해서 작성할 수 있다. 하단에 있는 CORS headers 버튼만으로도 한 번에 다 추가되니 값만 원하는 대로 바꿔서 사용할 수 있다.

2-4. Swagger에 만들어진 API를 Mockoon에 사용하기

사용하는 swagger 주소에 -json을 붙이면 JSON 형태로 나온다.

https://example.swagger-json << 이런 식으로..

JSON으로 작성된 내용

이 내용을 .json파일로 만든다.

import를 이용해서 Swagger에서 가져온 json을 넣어주면 Mockoon에서 쓸 수 있는 .json 형태로 다시 변환해 준다.

mockoon.json(mockoon으로 변환한 JSON)에는 port 등 기본적인 설정이 되어 있기 때문에 git을 이용해서 공유해서 팀원들끼리 공유도 쉽게 가능하다.

swagger.json -> mockoon.json으로 변환해서 mockoon.json 파일을 열면 사용 가능하다.

2-5. Proxy 설정

Mockoon을 사용하고자 하는 이유 중 가장 큰 이유를 차지하는 Proxy기능이다. Proxy 설정을 이용해서 실제 서버와 Mockoon을 동시에 사용하면서 Mockoon이 일종의 Proxy서버의 역할을 하게 되는 것이다.

2-4에서 이미 정의되어 있는 API를 Swagger.json으로 사용하는 방법을 적었지만, 나는 쓰지 않고 있다.

내가 쓰는 방법은 Proxy 설정을 활성화하고 TargetURL을 지정한다.

Proxy탭에서 Target URL을 지정하고 Enable proxy mode를 체크하여 활성화해 준다.
Proxy 설정이 되어있는지 확인하는 방법은 좌측에 서버 이름 옆에 마크유무에 따라서 활성화상태인지 아닌지 확인할 수 있다.

Proxy 설정을 해서 얻는 가장 큰 장점은 기존에 완성되어 있는 API를 그대로 쓸 수 있다. 는 점이다.

Mockoon을 통해 가상서버를 실행할 때, 지정된 엔드포인트가 없는 경우 요청이 TargetURL로 전송된다.
이 방식을 통해 백엔드 개발이 완료되기 전에 요청경로와 응답데이터를 설정하여 실제 요청 경로로의 요청/응답 처리 로직을 개발할 수 있다.

실제 개발 중인 페이지에서 DevTools의 네트워크 탭

Mockoon 라우터

위의 사진은 localhost:5555에서 요청/응답을 받은 결과물이다. 200으로 성공적으로 응답을 받았다. 하지만 아래 mockoon에 세팅되어 있는 라우터는 /newTest 1개밖에 없다.

이 결과물이 Proxy를 이용한 것이다. /client/~~ 로 요청했지만, Mcokoon에는 엔드포인트가 없기 때문에 지정해 놓은 target URL인 실제 API에 요청을 해서 응답을 전달해 준다.

3. Mockoon 활용 후

Mockoon을 활용한 개발 프로세스

Mockoon의 여러 특징과 장점을 활용하여 우리 팀의 프론트엔드의 개발 프로세스가 아래와 같은 플로우로 바뀌었다.

백엔드가 완성되기 전에 작업을 진행해야 하는 경우나, 가상 서버를 세팅해서 요청/응답 로직이 필요하다면 Mockoon을 활용하는 방법을 생각해 보면 좋을 것 같다.

TypeScript - Utility Types

백씨네 — Fri, 23 Feb 2024 13:47:01 +0900

1. keyof

interface User{
    id:number
    name:string
    age:number
    gender:"M" | "F"
}

type UserKey = keyof User // "id" | "name" | "age" | "gender"

const uk:UserKey = "id"
const uk2:UserKey = "score" // 오류 발생

keyof를 이용해서 객체 타입의 모든 키를 문자열 또는 숫자 리터럴 유티온 타입으로 추출할 수 있게 해 준다.

keyof 예시 1

객체의 키를 매개변수로 받는 함수를 정의할 때, 해당 객체 타입의 keyof를 이용하여 타입 안전성을 보장할 수 있다.

interface Person {
    name: string
    age: number
}

type PersonKey = keyof Person // 'name' | 'age'

function getProperty<T, K extends keyof T> (obj: T, key: K){
    return obj[key]
}

const person: Person = { name: "Alice", age:30 }
const personName = getProperty(person, "name") // 가능 - "Alice"
const personAge = getProperty (person, "age") // 가능 - 30
const personGender = getProperty (person, "gender") // Person에 gender가 없기 때문에 오류

keyof 예시 2

객체타입을 매핑하여 새로운 타입을 생성할 수 있다

type ReadonlyPerson = {
    readonly [P in keyof Person]: Person[P]
}

keyof는 typescript에서 타입의 안전성을 강화하고 타입 간의 관계를 더 명확하게 표현할 수 있도록 도와준다.

2. Partial

Partial은 타입을 옵셔널로 바꿔주는 역할을 한다. 기존에 선언되어 있던 interface가 옵셔널이 아니지만 옵셔널로 필요한 상황이 있을 때 사용할 수 있다.

Partial<T>로 작성할 수 있고 T는 변경할 interface가 들어온다.

interface User {
    id: number
    name: string
    age: number
    gender: "M" | "F"
}

// Partial<User>은 아래와 같은 형태라고 생각하면 된다.

//  interface User {
//        id?: number
//        name?: string
//        age?: number
//        gender?: "M" | "F"
//  }



let admin: Partial<User> = {
    id:1,
    name:"Bob",
    job : "manager"  // 오류 발생 
}

User의 interface를 옵셔널로 만든 것이기 때문에 User에 없는 job을 넣게 되면 오류가 발생한다.

3. Required

Partial과 반대로 모두 필수로 바꿔준다.

interface User{
    id: number
    name: stirng
    age?: number
}


let admin: Required<User> = {
    id: 1,
    name: "Bob",
    age : 30 // age를 안쓰면 오류 발생
}

User에서는 age가 옵셔널이었지만 admin 타입을 Required로 지정하였기 때문에 age도 필수로 넣어줘야 한다.

4. Readonly

이전에 typescript의 class를 공부하면서 사용해 본 readonly랑 역할은 같다.
하지만 Readonly<T>는 타입을 사용할 때 기존에 있던 타입에 readonly를 할당하는 것과 같다.

interface User{
    id: number
    name: string
    age?: number
}

let admin: Readonly<User> = {
    id: 1,
    name: "Bob",
}


admin.id=24 // 오류발생

Readonly를 이용해서 타입을 지정했기 때문에 id를 수정할 수 없게 된다.

5. Record

Record<K,T>에서 K는 key를 뜻하고, T는 type을 뜻한다.

사용 예시 1

유저의 학년별 점수를 입력한다 했을 때


interface Score {
    "1": "A" | "B" | "C" | "D"
    "2": "A" | "B" | "C" | "D"
    "3": "A" | "B" | "C" | "D"    
    "4": "A" | "B" | "C" | "D"
}

const score :Score = {    
    1: "A",    
    2: "B",    
    3: "A",    
    4: "C",
}

이렇게 작성할 수 있을 것이다. 이런 형태를 Recode를 사용한다면 더 간단하게 작성할 수 있다.


type Grade = "1" | "2" | "3" | "4"
type Score = "A" | "B" | "C" | "D"

const score :Record<Grade,Score>= {
    1: "A",    
    2: "B",    
    3: "A",    
    4: "C",
}

이렇게 작성할 수 있고, 객체의 key에는 Grade로 지정한 것만, 객체의 value에는 Score로 지정한 것만 사용가능하게 되어 타입을 지정하는데 안전성을 높일 수 있다.

사용 예시 2

interface User {
    id:number
    name:string
    age:number
}

function isValid(user:User) {
    const result = {
        id: user.id > 0,
        name: user.name !== "",
        age: user.age >0 
    }
    return result
}

이러한 예시 코드가 있을 때 result의 타입을 Recode를 이용해서 지정할 수 있다.

...

function isValid(user: User) {
    const result:Record<keyof User, boolean> = {
        id: user.id > 0,
        name: user.name !== "",
        age: user.age >0 
    }
    return result
}

keyof를 이용해서 User 인터페이스의 key값을 얻을 수 있고 result의 value 값은 boolean이므로 위의 예시와 같이 사용이 가능하다.

6. Pick

Pick<T, K>는 타입에서 원하는 key를 선택해서 사용하고 싶을 때 Pick을 사용한다.
이미 정의되어 있는 타입이 여러 개일 때 일부만 가져와서 쓸 수 있다.

interface User {
    id:number    
    name:string    
    age:number    
    gender : "M" | "F"
}



const admin: Pick<User, "id" | "name"> = {
    id: 1,
    name : "Bob"
}

7. Omit

Omit<T, K>는 Pick의 반대이다.
Type에서 일부를 선택했던 pick과 달리 Omit은 일부를 제외하고 사용할 수 있다.


interface User {
    id:number
    name:string
    age:number
    gender : "M" | "F"
}


const admin: Omit<User, "age" | "gender"> = {
    id: 1,
    name : "Bob"
}

8. Exclude

Exclude<T1, T2>는 두 가지 타입을 이용해서 작성을 하는데 T1의 타입에서 T2와 공통된 타입을 지우고 사용할 수 있다.

Omit과 비슷하다고 느낄 수 있다 하지만 Omit 은 객체타입에서 특정 속성을 제외할 때 사용하고, Exclude는 유니언 타입에서 특정 멤버 타입을 제외할 때 사용된다.

Omit은 객체의 구조를 변경하지만 Exclude는 타입의 구성을 변경한다.

type T1 = string | number | boolean
type T2 = string | boolean

type ExcludeType = Exclude<T1, T2> // number만 남게 된다.

9. NonNullable

NonNullable<type>은 타입에서 null, undefined를 제외한다.

type T1 = string | null | undefined | void
type T2 = NonNullable<T1>

TypeScript - Generic

백씨네 — Thu, 22 Feb 2024 16:16:12 +0900

제네릭을 이용하면 class, function, interface를 다양한 타입으로 재사용할 수 있다.
선언할 때 파라미터만 적어두고 사용할 때 타입을 지정해 주는 방법이다.

기본적인 제네릭 사용 방법

function getSize(arr : number[]) :number {
    return arr.length
}

const arr1 = [1,2,3]
getSize(arr1) // 3

const arr2 = ["1","2","3"]
getSize(arr2) // 3

동일한 형태로 만들었지만 매개변수가 number이냐, string이냐 에 따라서 에러가 생기는 부분이 있을 것이다.
이걸 빠르게 해결하기 위해선

유니온을 이용한 방법

function getSize (arr: number[] | string []) : number{
    return arr.length
}

이렇게 arr의 타입을 여러 개 지정한다면 가능하다.. (유니온 타입으로 하는 방법 말고 오버로드해서 사용할 수 있다.)

하지만 arr가 확실하게 정해진 것이 아니고 boolean 타입이나 object 타입으로 들어올 경우도 있다.

const arr3 = [true, true, false]

const arr4 = [{}, {}, {name : "baekspace"}]

이렇게 여러 개의 타입이 들어온다면 모든 것을 다 지정해 주는 것보다 제네릭을 이용해서 작성하는 것이 효율적이다.

제네릭을 이용한 방법

위에서 썼던 getSize()를 제네릭을 이용하여 작성하면 아래와 같다.

function getSize<T>(arr:T[]):number{  // 가능
    return arr.length
}

function getSize<Key>(arr:Key[]):number{  // 가능
    return arr.length
}

const arr1 = [1,2,3]
getSize<number>(arr1) // 가능
getSize(arr1) // 가능

여기서 T는 반드시 T라고 적을 필요는 없다. 많은 곳에서 이렇게 쓰고 있기 때문에 T를 적었지만, A라고 해도 되고 Key라고 해도 가능하다.

사용할 때는 <>를 이용해서 타입을 지정해 주면 된다. (안 쓰더라도 타입스크립트가 유추는 한다.)

interface에서 제네릭 사용 방법

interface Mobile<T> {
    name: string
    price: number
    option: T
}

// object의 타입이 지정되어있다면 그대로 쓸 수 있음.
// <object>  ->  <{color:string; coupon:boolean}>
const m1 :Mobile<object> = {
    name:"s22",
    price: 1000,
    option :{
        color:"red",
        coupon:false
    }

}

const m2 :Mobile<string> = {
    name:"s21",
    price: 900,
    option :"good"
}

제네릭을 이용해서 하나의 타입만 받지만 여러 형태의 객체를 만들 수 있다.

제네릭 응용

interface User{
    name:string
    age:number
}

interface Car{
    name:string
    color:string
}

interface Book{
    price:number
}

const user :User = {name:"a", age:10}
const car:Car = {name:"bmw", color:"red"}
const book:Book = {price :3000}  

function showName (data) : string{
    return data.name
}


showName(user)
showName(car)
showName(book)

이렇게 아무것도 선언하지 않으면 data가 any 타입으로 메서드를 호출하는 곳에서는 문제가 없지만 book를 인자값으로 넣어주는 마지막 메서드를 사용할 때 문제가 생길 수 있다.

그래서 data에 제네릭으로 타입을 지정한다.

function showName<T>(data:T) : string{
    return data.name
}

이렇게 작성하고 나면
return data.name 에 오류가 발생한다.

Property 'name' does not exist on type 'T'.(2339)

인자값으로 넣어주는 book에는 name이 없기 때문이다. 그래서 name이 있는 인자값만 호출할 수 있도록 T를 더 명확하게 쓰면 된다.

function showName<T extends {name:string}>(data:T) : string{
    return data.name
}

이렇게 타입을 지정하게 되면

어떠한 타입이 들어올 때 그 타입은 name 객체를 확장한 형태이다.

라는 것을 알려줄 수 있다.

참고로 name이 string 이여야 하고, name이 없는 book의 경우에는 인자 값으로 사용할 수 없기 때문에

showName(book) 은 사용할 수 없다.

interface Car{
    name:boolean
    color:string
}

...

showName(car) // 사용 불가

위에서 {name:string} 객체를 확장한 타입이 들어올 것이라고 했지만 Car의 name 타입을 바꾸게 된다면 이것 또한 name이 string이 아니기 때문에 에러를 발생하고, showName(car) 또한 사용할 수 없다.

TypeScript - class (feat.예시코드)

백씨네 — Thu, 22 Feb 2024 11:48:10 +0900

접근 제한자 - public, private, protected

접근 제한자를 이용해서 class의 멤버의 접근 범위를 제한할 수 있다.
접근 제한자는 public, private, protected 3가지가 있다.

결론부터 말하자면

public : 어디서나 접근이 가능하다. public으로 지정하거나 아무것도 지정하지 않으면 기본적으로 public이다.
private : 해당 클래스의 내부에서만 접근이 가능하다. 상속을 하더라도 접근할 수 없다.
protected : 해당 클래스, 파생된 클래스 내부에서만 접근이 가능하다. (인스턴스에서 접근이 불가능)

1. public


class Car {
    color : string;
    public wheel : number;
    constructor( color : string , wheel:number) {
        this.color = color
        this.wheel = wheel
    }

    start(){
        console.log('start')
    }
}

const bmw = new Car("red", 4)
console.log(bmw.color) // 접근 제한자를 지정하지 않아도 기본적으로 public이다.
console.log(bmw.wheel) // 접근 가능

2. private

class Car {
    private name : string = "car"
    color : string
    constructor( color : string ) {
        this.color = color
    }

    start(){
        console.log('start')
        console.log(this.name ) // 여기서는 사용 가능하다.
    }
}

class Bmw extends Car {
    constructor(color:string){
        super(color)
    }
    showName (){
        console.log(this.name) // Error : name이 private 이기 때문에 접근할 수 없다.
    }
}


const z4 = new Bmw("black")

name을 private로 지정할 경우 상속을 받았다 하더라도 사용할 수 없고 private를 지정한 클래스 내부에서만 쓸 수 있다.

Property 'name' is private and only accessible within class 'Car'.

private 대신 '#'을 붙여도 된다.

class Car2 {
    #name : string = "car2"
    start(){
        console.log(this.#name)
    }
}

3. protected


class Car {
    protected name : string = "car"
    public name2 : string = "car2"
    color : string

    constructor( color : string ) {
        this.color = color
    }
    start(){
        console.log('start')
    }
}



class Bmw extends Car {
    constructor(color:string){
        super(color)
    }
    showName (){
        console.log(this.name)
    }
}




const z4 = new Bmw("black")

console.log(z4.name) // protected 인 name은 오류
console.log(z4.name2) // public 인 name2는 접근가능

class 내부에서 사용할 때는 protected와 public이 같은 것 같지만 인스턴스를 생성하게 되면 차이점이 생긴다.
protected를 지정한 name은 클래스 인스턴스에서 접근이 불가능하고 public인 name2만 클래스 인스턴스에서 접근이 가능하다.

readonly, static, abstract

4. readonly

접근 제한자는 아니지만 typescript에서 제공하는 키워드인 readonly는 속성이 선언된 후에 변경할 수 없음을 나타낸다.

즉, 속성의 가시성이나 접근성을 제한하지 않고, 속성의 불변성을 선언할 때 사용한다.

class Car {
    readonly make: string
    readonly model: string
    constructor(make: string, model: string) {
        this.make = make
        this.model = model
    }
}

const myCar = new Car("Toyota", "Corolla")
console.log(myCar.make) // Toyota
console.log(myCar.model) // Corolla
myCar.make = "Honda"; // 오류: 'make'는 읽기 전용 속성이므로 할당할 수 없습니다.

5. static

class Car {
    readonly make: string
    readonly model: string
    static wheels = 4

    constructor(make: string, model: string) {
        this.make = make
        this.model = model
    }

    start(){
        console.log('start')
        console.log(this.wheels) // 오류발생
        console.log(Car.wheels) // 클래스를 직접 참조
    }

    static stop(){
        console.log('stop')
    }
}


const myCar = new Car("Toyota", "Corolla")
console.log(myCar.wheels) // 오류발생
console.log(Car.wheel) // 클래스를 직접 참조

static 키워드를 붙인 속성이나 메서드는 인스턴스에 속하는 것이 아닌 해당 클래스 자체에 속하게 된다.
그래서 해당 클래스를 이용해서 인스턴스를 생성하지 않고도 접근이 가능하다.

6. abstract

추상 클래스

abstract class Car {
    color : string

    constructor( color : string ) {
        this.color = color
    }

    start(){
        console.log('start')
    }

    abstract doSomething():void
}

const myCar = new Car("red") // Error: 추상 클래스는 인스턴스로 생성할 수 없다.

class Bmw extends Car {
    constructor(color:string){
        super(color)
    }
    doSomething(){
        console.log('go...!')
    }
}

추상 클래스는 abstract 키워드를 클래스 앞에 선언하여 만든다.

추상 클래스의 가장 큰 특징은 추상 클래스를 이용하여 직접 인스턴스를 만들 수 없다. 추상 클래스는 다른 클래스에 상속해서 사용한다. 또, abstract를 이용해서 추상 메서드를 만들 때는 로직이 없이 작성한 후 상속받은 클래스에서 구체적인 구현을 해줘야 한다.

TypeScript - function

백씨네 — Thu, 22 Feb 2024 11:35:16 +0900

this

interface User{
    name:string;
}

const Sam:User = {
    name:'Sam'
}

function showName(this:User, age:number, gender:'m'|'f') { // this를 사용하기 위해서 매개변수에 this와 this의 타입을 지정한다.
    console.log(this.name, age, gender)
}

const a = showName.bind(Sam);
a(30, 'm')

this를 Sam으로 바인딩하고 this를 사용하기 위해서 Sam의 타입과 같은 User로 명시해 준다.
이렇게 하면 this를 이용할 수 있다.

함수의 첫 번째 매개변수로 'this' 타입을 지정하는 것은 'this'의 컨텍스트를 명시적으로 선언하는 방법이다. 함수가 호출될 때 'this'가 가리킬 객체의 타입을 지정해 주는 것으로, 실제 함수 호출 시에는 'this' 매개변수를 제공하지 않는다.

bind에 대해서 공부하기 [[https://youtu.be/KfuyXQLFNW4?si=JtEKSdzzneXpFjVL]]

overloading

동일한 함수 이름에 대해 여러 개의 타입 서명을 선언하는 기능을 말한다.
이를 통해서 함수가 다양한 타입의 인수를 받아들일 수 있도록 하며 각각의 인수 타입 조합에 따라 다른 타입의 반환 값을 가질 수 있게 한다.

오버로드 서명 선언 : 함수의 여러 호출 가능한 서명을 선언한다. 이 서명에는 구현을 포함하지 않는다.
구현 서명 선언 : 실제 함수 구현과 매칭되는 서명. 이 서명은 오버로드 서명보다 더 일반적인 형태를 가지며, 실제 함수 로직을 포함한다.
함수 구현 : 실제 로직을 구현한다. 구현 내에서는 인수의 타입을 체크하여 다양한 시나리오에 맞게 로직을 분기처리한다.

사용 예시 1

//오버로드 서명
function greet(name:string): string;
function greet(age:number): string;

// 구현 서명 및 함수 구현
function greet(nameOrAge: string | number): string {
    if(typeof nameOrAge === "string") {
        return `Hello, ${nameOrAge}` // 이름이 들어올 때
    } else {
        return `You are ${nameOrAge} years old` // 나이가 들어올 때 
    }
} 


//사용 시
const greeting1 = greet("Baekspace")
const greeting2 = great(30)

console.log(greeting1) // "Hello Baekspace"
console.log(greeting2) // "You are 30 years old"

사용 예시 2

interface User{
    name: string;
    age: number;
}

function join(name: string, age: string): string;
function join(name: string, age: number): User;
function join(name: string, age: number | string): User | string {
    if(typeof age === "number") {
        return {
            name,
            age,
        };
    }else{
        return "나이는 숫자로 입력해주세요.";
    }
}


const sam: User = join("Sam", 30); 
console.log(sam)// {name:"Sam", age:30} 출력

const jane: string = join("Jane", "30"); 
console.log(jane)// "나이는 숫자로 입력해주세요 출력"

주의사항

오버로드 서명은 구현보다 위에 선언되어야 한다.
구현 서명은 공개되지 않으며, 외부에서는 볼 수 없다.
구현은 모든 오버로드 서명을 충족할 수 있어야 한다.

[코딩앙마 : https://youtu.be/prfgfj03_VA?si=GkfK6PdhXkkIpDLz]

TypeScript - interface

백씨네 — Thu, 22 Feb 2024 11:32:25 +0900

index signature

Index Signature은 객체의 속성 이름과 타입이 미리 정의되어 있지 않을 때, 객체에 동적으로 속성을 추가할 수 있는 방법을 제공한다.

기본형태

interface Obj{
    [key : T] : U
}

// T : 인덱스의 타입 (대부분 string 이나 number)
// U : 값의 타입

사용 예시

type Score = "A" | "B" | "C"

interface User {
    name: string
    age: number
    [grade: number]: Score
}


let user: User = {
    name: "xx",
    age: 30,
    1: "A",
    2: "B",
}

index signature를 사용하면 타입 체크 시 유연성이 증가하지만, 해당 객체의 명확한 구조를 판단할 수 없기 때문에 주의해서 사용해야 한다.

implements

클래스가 특정 인터페이스를 충족시키도록 강제하는 데 사용한다. 인터페이스는 메서드와 속성의 이름 및 타입을 정의할 수 있는 구조적 타이핑 시스템의 일부이다.

클래스가 인터페이스를 구현할 때, 그 클래스는 인터페이스에 정의된 모든 속성과 메서드를 구현해야 한다.
이를 통해서 typescript는 타입 안정성을 제공하며, 객체 지향 디자인 원칙을 따르는 코드를 작성하는데 도움이 된다.

사용 예시

interface Animal {
    speak() : string;
}

class Dog implements Animal{
    speak(){
        return '멍!'
    }
}

Dog 클래스는 Animal 인터페이스를 구현하기 때문에 speak 메서드가 포함되어야 한다.

만약 Dog 클래스에서 speak 메서드가 없다면 오류가 발생할 것이다.

핵심

클래스는 여러 인터페이스를 구현할 수 있으며 각 인터페이스는 쉼표로 구분된다.

class A implements a,b,c {}

'implements'는 클래스가 인터페이스의 구조적 계약을 준수하도록 강제하여, 타입 안정성과 예측 가능한 코드 구조를 제공한다.
인터페이스 내의 속성이 선택적(optional) 일 때, 클래스는 그 속성을 반드시 구현할 필요가 없다.

interface Employee {
    id:number;
    name:string;
    email?:string;
}


class PartTimeEmployee implements Employee {
    id:number
    name:string

    constructor(id:number, name:string){
        this.id = id;
        this.name = name;
    }
}

class FullTimeEmployee implements Employee {
    id:number
    name:string
    email:string

    constructor(id:number, name:string, email:string) {
        this.id = id;
        this.name = name;
        this.email = email;
    }
}

PartTimeEmployee와 FullTimeEmployee 모두 Employee 인터페이스를 이용하여 구현했지만, email은 선택적 요소로 필요한 클래스에서만 포함하여 구현할 수 있다.

extends

인터페이스를 확장할 때 사용할 수 있다.

interface Car {
    color:string;
    wheel:number;
    start():void;
}

interface Bmw extends Car{
    door:number;
    stop():void;
}

interface Toy {
    type : string
}

const bmw :Bmw = {
    door: 4,
    wheel: 4,
    color: 'blue',
    stop : () => {
        console.log("stop!!")
    },
    start: ()=>{
        console.log('start!!')
    }
}

interface BmwToyCar extends Bmw, Toy {
    price : number
}

const bmwtoycar : BmwToyCar = {
    price: 0,    
    door: 0,    
    stop: ()=>{},    
    color: "",    
    wheel: 0,    
    start: ()=>{},    
    material: ""
}

Bmw 인터페이스를 이용하게 되면 Bmw 내부에서 쓴 것뿐만 아니라 Car 안에 포함되어 있는 속성도 다 작성해야 한다.

implements와 마찬가지로 여러 인터페이스를 이용해서 확장할 때 쉼표로 구분한다.

[코딩앙마 : https://youtu.be/OIMPLNICzoc?si=xi9nbAoIzi_76lcg]

JavaScript - Closure(클로저)

백씨네 — Wed, 21 Feb 2024 14:38:08 +0900

Closure

클로저는 함수와 그 함수가 선언된 렉시컬 환경과의 조합이다. 클로저는 자바스크립트에서 매우 중요한 개념으로 함수가 생성될 때의 환경을 기억하게 해 주며, 이를 통해서 여러 패턴, 기법을 구현할 수 있다.

클로저의 정의와 작동원리

클로저는 함수가 선언된 시점의 스코프에 있는 모든 변수에 대한 참조를 유지한다.
- 함수가 실행될 때마다 해당 스코프에 접근할 수 있음을 의미한다.
클로저는 함수가 실행되어 외부 스코프에서의 실행이 종료되어도 해당 함수의 스코프 내에 선언된 변수들에 대한 접근을 가능하게 한다.
- 자바스크립트의 함수는 외부 스코프에 정의된 모든 변수에 접근할 수 있다.

클로저 예시


function outerFunction (arg) {
    var variableInOuterFunction = arg

    function bar() {
        console.log(variableInOuterFunction)
    }

    bar()
}

outerFunction("hello closure")

내부 함수가 외부 범위에서 변수에 액세스 하려는 것을 확인할 수 있다.
외부 함수의 변수는 내부 함수에 의해 닫혔거나 바인딩되었다.

클로저는 함수가 선언될 때의 주변환경을 기억하는 함수 라고 할 수 있다.

이를 통해 함수는 자신이 생성될 때의 환경에 있던 변수들을 기억하여 나중에도 계속 접근할 수 있다.

모듈 패턴 같은 객체를 쉽게 구성할 수 있다.


function createCounter() {
    let val = 0;
    return {
        increment() { val++ },
        getVal() { return val }
    }
}

let counter = createCounter();
counter.increment();
console.log(counter.getVal()); 
counter.increment();
console.log(counter.getVal());

이 패턴은 데이터를 캡슐화하고 공개 인터페이스를 통해 데이터에 접근하는 방법을 제공한다.

'createCounter' 함수는 'val'이라는 변수를 가지고 있으며, 이 변수는 함수가 반환하는 객체의 'increment' 메서드와 'getVal' 메서드를 통해서만 접근이 가능하다. 'createCounter' 함수가 호출될 때마다 새로운 'val' 변수가 생성되고, 이 변수는 각각의 counter 인스턴스에 대해 고유하다.

외부에서 직접 접근할 수 없게 함으로써 데이터를 안전하게 보호한다.

클로저의 이점

메모리 효율성 : 특정 데이터에 대한 접근을 필요한 함수에만 제한하여 메모리 사용을 최적화할 수 있다.
코드의 모듈성과 재사용성 증가 : 공통 기능을 가진 함수를 쉽게 생성하고 재사용할 수 있다.

클로저 주의사항

메모리 누수 : 클로저를 부적절하게 사용하게 되면 사용하지 않은 메모리가 해제되지 않아 메모리 누수가 발생한다.
성능 고려사항 : 불필요한 메모리 사용을 피하기 위해서 적절히 사용해야 한다.

클로저의 이점과 주의사항을 보면 메모리 효율성과 메모리 누수가 쓰여있다.

메모리를 효율적으로 쓰는데 누수가 생긴다..?

클로저의 사용 방식에 따라 두 가지 특성이 공존할 수 있다.

메모리 효율성

클로저는 특정 함수에서만 필요한 데이터에 대한 접근을 제한함으로써 메모리를 효율적으로 사용할 수 있게 해 준다. 예를 들어, 클로저를 사용하여 특정 함수에 대한 설정이나 상태를 저장하는 경우, 이 데이터는 해당 함수가 실행될 때만 메모리에 유지되고, 다른 부분의 코드에서는 접근할 수 없기 때문에 메모리를 절약할 수 있다.

함수가 실행될 때마다 필요한 데이터를 생성하고 불필요할 때는 자동으로 정리하여 메모리 사용을 최소화한다.

메모리 누수

반면, 클로저를 부적절하게 사용하면 누수가 발생할 수 있다. 클로저는 외부 함수의 변수에 대한 참조를 유지하기 때문에, 이 변수들은 내부 함수가 살아 있는 한 가비지 컬렉터에 의해 수집되지 않는다.

만약 클로저가 큰 데이터 구조를 참조하고 있고, 이 클로저가 오랜 시간 동안 메모리에서 제거되지 않는다면, 필요하지 않은 데이터가 메모리에 계속 남아 있게 되어 메모리 누수가 발생할 수 있다.

효율적인 클로저 사용법

클로저가 필요한 경우에만 사용하고, 불필요한 참조를 피해야 한다.
큰 데이터 구조를 참조하는 클로저는 주의해서 사용해야 하며, 가능한 한 생명주기를 짧게 유지해야 한다.
클로저를 사용한 후에는 클로저가 참조하는 외부 변수를 해제하거나 null로 설정하여 가비지 컬렉터가 수집할 수 있도록 해야 한다.

브라우저 탭간 통신하기 : BroadCast Channel API ( feat. Next.js)

백씨네 — Tue, 16 Jan 2024 17:19:37 +0900

브라우저 탭 사이에 데이터 공유하기

프론트 작업을 하면서 A태그의 target:_blank를 이용해서 새 탭을 열어서 작업을 하는 과정이 있었다.
기존에 열고 있던 페이지가 (A) 새로운 탭이 (B)라고 했을 때, A와 B는 동일한 오리진으로 로컬 스토리지를 공유할 수 있었다.

현재 로컬 스토리지에서 Access Token을 관리하는 로직으로 프로젝트를 만들고 있다.
그래서 처음 진입을 하는 과정에서는 액세스 토큰을 사용할 때 문제가 없었다. 하지만 B에서 작업을 하던 중 Access Token의 만료로 다시 재발급을 받아 로컬 스토리지를 바꿨을 때 A에서는 아직 기존에 있는 Access Token을 들고 있었고 어떠한 작업을 할 때 Access Token이 필요하지만 과거의 Access Token을 가지고 있었기 때문에 에러를 발생하는 문제가 발생했다.

이를 해결하기 위해서 B페이지에서 새로운 token으로 갱신을 할 때 기존에 있는 페이지에서도 바꿔주면 되지 않을까?라는 생각을 했고 그러기 위해서 탭 간 통신을 할 수 있는 과정이 필요했다.

위의 상황은 내가 겪을 상황이지만 정리하자면

내 애플리케이션의 상태를 탭 사이에 공유해야 한다.

방법

1. Local Storage Event
  - 기본적으로 로컬 스토리지가 변하는 것에 대해서 이벤트를 감지할 수 있다고 있다. 만약에 단순히 로컬 스토리지만 관리한다고 했을 때는 이것을 써도 좋을 것 같다.
1. window.postMessage
  - window 객체 안에 있는 postMessage를 이용하는 방법도 있다. 다른 탭이나 윈도우, ifame 간에 메시지를 전달할 수 있다.
  - 서로 다른 origin에서도 가능
1. service worker
  - 웹의 백그라운드 작업을 처리하는 데 사용되고, 푸시 알림, 네트워크 요청 캐시 등의 기능을 제공
  - 탭 간의 통신보다는 오프라인 경험, 데이터 캐싱, 백그라운드 동기화에 적합
  - serviceworker.js를 만들어 관리해야 한다.
2. BroadCast Channel API
  - 같은 Origin을 가진 다양한 브라우저 컨텍스트 사이에서 간단하게 데이터 교환을 할 수 있는 API
  - 동일한 Origin 내에서 데이터 공유 및 실시간 커뮤니케이션에 이상적이다.

선택

단순 로컬 스토리지뿐 아니라 메시지를 주고받을 수 있다, 추후 어떠한 상황이 있을지 아직 모른다는 점 (확장성)
브라우저 탭 간에 통신이 되고 그 데이터를 송수신한다는 점
같은 오리진이라는 점
간단하게 사용할 수 있어야 한다는 점

위의 세 가지를 고려해서 broadcast channel API를 선택하게 되었다.

BroadCast Channel API

BroadCast Channel API는 같은 오리진에서 사용할 수 있다는 점으로 송수신자를 별도로 표기하지 않아도 된다. 마지막까지 봤었던 window.postMessage는 다른 오리진간에도 가능하기 때문에 보안을 위해서 메시지를 보낸 출처를 확인하는 과정이 있었다.

postMessage 예시

// 송신자 
const childWindow = window.open('https://example.com/child-page.html'); 

// 메시지 전송 
childWindow.postMessage('데이터', 'https://example.com');



//수신자

// 메시지 수신 리스너 설정 
window.addEventListener('message', (event) => { 
// 보안을 위해 메시지를 보낸 출처 확인 
    if (event.origin !== 'https://example.com') return;
    console.log('Received message:', event.data); 
});

반면에 broadcast channel API는 동일 오리진이기 때문에 다른 검증과정은 없고 인스턴스를 통해서 송수신을 했다.

Broadcast Channel API 예시

//송신자

const channel = new BroadcastChannel('채널이름')
channel.postMessage('데이터')

//수신자

const channel = new BroadcastChannel('채널이름'); 
// 메시지 수신 리스너 설정 
channel.onmessage = (event) => { console.log('Received message:', event.data); };

조금 더 간단하게 쓸 수 있었고 다른 여러 창이 열려있는 상황에서도 동기화를 시킬 수 있다고 생각했고, 그래서 BroadCast Channel API를 이용하기로 했다.

BroadCast Channel API는 브라우저 기반 API이기 때문에 클라이언트 사이드에서만 사용할 수 있다.

어떻게 사용했는가?

브라우저 기반 API이므로 클라이언트 사이드에서 써야 한다. 우리의 프로젝트에서 어디에서나 작동하는 client side 컴포넌트는 root에 react-qeury(tanstack-query)를 세팅한 부분이다.

그래서 react-query를 세팅한 컴포넌트에서 수신을 하면 recoil을 통해서 로컬스토리지를 변경하는 로직을 추가하였다.

//rootwrap.tsx


const channel = new BroadcastChannel('bc')

channel.onmessage = (e) => {
    if (e.data) {
        setAccessToken(e.data) // recoil
    }
}

기본적으로 우리 프로젝트에서 토큰이 만료되면 토큰이 만료됐다는 에러를 던지고 그걸 브라우저에서 감지하게 되면 재발급을 한 후 새로운 토큰을 이용해서 재요청을 진행한다.
그래서 토큰을 재발급받는 과정 뒤에 postMessage를 사용하였다.

const sendMessage = (message: string) => {
    if (typeof window !== 'undefined') {
        const channel = new BroadcastChannel('bc')        
        channel.postMessage(message)
    }
}


// 토큰 발급 받은 후
sendMessage(accesstoken)

이러한 과정을 통해서 동일한 오리진의 다른 탭에서 토큰을 재발급받더라도 토큰 받을 후 로직에 sendMessage를 통해서 모든 탭의 토큰에 최신화를 시켜줄 수 있는 과정을 만들었다.

Broadcast Channel API 원리

출처 : MDN web Docs - Broadcast Channel API

일반적인 BroadcastChannel의 원리는 크게 3단계이다.

채널 생성 및 관리
메시지 큐잉 및 전달
이벤트 전파

1. 채널 생성 및 관리

브라우저는 각각의 BroadcastChannel 인스턴스에 대한 참조를 관리한다. 주로 브라우저의 메모리 내에서 채널 이름을 키로 해서 관리된다.
채널을 동일한 이름으로 생성된 모든 BroadcastChannel 인스턴스에 자동으로 연결된다.

2. 메시지 큐잉 및 전달

메시지가 postMessage()를 통해서 전송되면, 브라우저는 해당 메시지를 내부적인 메세지 큐에 넣는다.
브라우저는 동일한 채널에 가입된 모든 인스턴스들에게 메시지를 전달한다. 비동기적으로 수행되며, 발신 컨텍스트는 수신 컨텍스트의 응답을 기다리지 않는다.

3. 이벤트 전파

메시지가 큐에 삽입되면, 브라우저는 해당 채널에 모든 컨텍스트에 대해 이벤트를 발생시킨다.
각 컨텍스트는 자신의 이벤트 루프 내에서 message 이벤트를 수신하며, 등록된 onMessage 이벤트 핸들러가 메시지를 처리한다.

Broadcast Channel API 특징

1. 동기화와 동시성 제어

브라우저는 각 BroadcastChannel인스턴스 간의 동기화를 담당한다. 다른 탭이나 윈도우가 동시에 동일한 채널에 접근하더라도 메시지가 올바르게 전달되도록 보장한다.
메시지는 순차적으로, 전송된 순서대로 처리되며, 이를 통해서 동시성 문제를 방지한다.

2. 보안 및 격리

BroadcastChannel 은 동일 출처 정책을 준수한다. 채널이 출처가 다른 탭이나 윈도우 간에 격리되어 있음을 의미한다.
내부적으로 브라우저는 출처 정보를 사용하여 각 채널 범위를 결정하고, 오직 같은 출처의 컨텍스트만 메시지를 수신할 수 있도록 한다.

StyleXjs : StyleX 세팅 및 기초 (feat. NEXT)

백씨네 — Tue, 26 Dec 2023 00:25:21 +0900

StyleX 세팅 및 기초

공식문서 : https://stylexjs.com/

StyleX

stylexjs.com

현재 프론트엔드 개발에서 React는 중요한 역할을 하고 있다. React를 개발한 Metark StyleX 라는 새로운 CSS-in-JS 라이브러리를 만들었는데, 이는 React와 잘 호환될 것으로 추측된다. Next.js 또한 React 기반 프레임워크이므로 Next.js와 React를 사용하는 프로젝트에서는 StyleX를 쓰게 될 것이라 생각하고 StyleX의 세팅 및 기초에 대해서 알아봤다.

꽤 빠르게 올라갈 것 같은 느낌이다...

웹 앱 스타일링을 위한 간단하고 사용하기 쉬운 JS 구문 및 컴파일러
인라인스타일과 정적 CSS의 장점을 결합한 방식이다.
스타일을 정의하고 사용하기 위해서는 컴포넌트 내의 로컬 지식만 있으면 되고, 미디어 쿼리와 같은 기능을 유지하면서 특정성 문제를 피할 수 있다.
StyleX는 충돌이 없는 Atomic CSS를 사용하여 최적화된 스타일을 빌드한다.
~~(요즘 Atomic이 트랜드인건가..?)~~

확장성

Atomic CSS로 CSS 파일 크기를 최소화한다.
컴포넌트 수가 증가하더라도 CSS 크기가 균등하게 유지된다.
커지는 코드베이스 내에서도 스타일은 읽기 쉽고 유지보수가 가능하다.

각 스타일 규칙을 가장 작은 단위로 분해하여 개별 클래스로 만드는 방식이다.
프로젝트의 컴포넌트 수가 증가하더라도 CSS 파일 크기가 균등하게 유지된다.
결과적으로 이를 통해서 중복을 줄이고 CSS 파일 크기를 최소화할 수 있다.

예측 가능성

요소에 적용된 클래스 이름은 해당 요소에만 직접 스타일을 적용할 수 있다.
특정성 문제가 없다.
마지막으로 적용된 스타일이 항상 승리한다!

클래스 이름은 각 요소에만 적용되기 때문에 다른 요소에는 영향을 주지 않으며 이로 인해 CSS의 특정성 문제가 발생하지 않는다.
또한, 마지막에 작성된 스타일이 항상 우선적으로 적용된다.

재조합 (요소를 분해 조합하여 재사용 가능하다)

조건부 스타일 적용
컴포넌트와 파일 경계를 넘어 임의의 스타일을 병합하고 조합한다.
컴포넌트 내의 로컬 상수와 표현식을 사용하여 스타일을 DRY하게 유지하거나 성능에 대해 걱정하지 않고 스타일을 반복한다.

조건부 스타일을 통해서 상황에 맞는 다양한 스타일링이 가능하고, 스타일을 자유롭게 병합하고 조합할 수 있다. 그리고 여러 컴포넌트에서 공통으로 사용되는 색상이나 글꼴과 같은 상수를 로컬 상수로 선언하여 재사용할 수 있다.

빠름

런타임에 스타일 주입이 없다.
모든 스타일은 컴파일 타임에 정적 CSS 파일에 번들링된다.
클래스 이름을 병합하는 런타임을 최적화한다.

런타임에서 스타일을 주입하는 것이 아닌 컴파일 타임에 정적 CSS 파일에 번들링 되기 때문에 빠르다. 또한, 클래스 이름을 병합하는 런타임을 최적화하여 빠르게 렌더링 할 수 있다.

타입 안정성

타입 안정성 API
타입 안정성 스타일
타입 안정성 테마

설치

$ npm install --save @stylexjs/stylex

$ npm install --save-dev @stylexjs/babel-plugin
# next.js
$ npm install --save-dev @stylexjs/nextjs-plugin

Next에서 사용하기 위해서 .babelrc.js 파일을 생성하고 아래와 같이 작성한다.

module.exports = {
    presets: ["next/babel"],
    plugins: [
        [
            "@stylexjs/babel-plugin",
            {
                dev: process.env.NODE_ENV === "development",
                runtimeInjection: false,
                genConditionalClasses: true,
                treeshakeCompensation: true,
                unstable_moduleResolution: {
                    type: "commonJS",
                    rootDir: __dirname,
                },
            },
        ],
    ],
}

그리고 next.config.js 파일에 아래와 같이 작성한다.

/** @type {import('next').NextConfig} */
const styleXPlugin = require("@stylexjs/nextjs-plugin")

const nextConfig = {}

module.exports = styleXPlugin({
    rootDir: __dirname,
})(nextConfig)

dev-runtime 설치

컴파일러 및 빌드 프로세서를 이용하지 않고 styleX를 사용하기 위해선 dev-runtime을 설치해야 한다.

$ npm install --save-dev @stylexjs/dev-runtime

이렇게 설치를 하면 프로덕션에 배포할 준비가 될 때까지 추가 설정 없이 @stylexjs/stylex를 가져와서 사용할 수 있다.

이 부분은 아직 설정하는 방법을 못 찾았다...
아시는 분 공유 좀...

ESLint 플러그인

StyleX 컴파일러는 스타일의 유효성을 검사하지 않으며 많은 유효하지 않은 스타일을 컴파일할 수 있다. 스타일을 작성할 때 스타일의 유효성을 검사하기 위해서는 ESLint 플러그인을 설치해야 한다.

$ npm install --save-dev @stylexjs/eslint-plugin

그리고 .eslintrc.js 파일에 아래와 같이 작성한다.

module.exports = {
    extends: "next/core-web-vitals",
    plugins: ["@stylexjs"],
    rules: {
        // The Eslint rule still needs work, but you can
        // enable it to test things out.
        "@stylexjs/valid-styles": "error",
        "ft-flow/space-after-type-colon": 0,
        "ft-flow/no-types-missing-file-annotation": 0,
        "ft-flow/generic-spacing": 0,
    },
}

오류

Syntax error: "next/font" requires SWC although Babel is being used due to a custom babel config being present.
styleX에서 직접 언급한 내용을 따르면
This is an issue that we cannot fix on our end. StyleX is dependent on a Babel plugin. Using it within NextJS means using Webpack+Babel and not SWC.
next/font only works if you use SWC. Sorry, there's nothing we can do about this.
라고 했다.
마지막줄에 "SWC를 사용하는 경우에만 작동합니다. 죄송하지만 이 문제에 대해서는 저희가 할 수 있는 일이 없습니다."
라고 하는 것을 보면 StyleX에서 할 수 있는 건 없는 것 같고 이 오류가 발생하지 않게 하기 위해서
next/font를 사용하지 않는 방법으로 가야 할 것 같다.

기존

import type { Metadata } from "next"
import { Inter } from "next/font/google"
import "./globals.css"

const inter = Inter({ subsets: ["latin"] })

export const metadata: Metadata = {
    title: "Create Next App",
    description: "Generated by create next app",
}

export default function RootLayout({ children }: { children: React.ReactNode }) {
    return (
        <html lang="en">
            <body className={inter.className}>{children}</body>
        </html>
    )
}

아래와 같이 수정한다.

수정

import type { Metadata } from "next"
import "./globals.css"

export const metadata: Metadata = {
    title: "Create Next App",
    description: "Generated by create next app",
}

export default function RootLayout({ children }: { children: React.ReactNode }) {
    return (
        <html lang="en">
            <body className={""}>{children}</body>
        </html>
    )
}

font를 사용하지 않고 className을 빈 문자열로 설정한다.

styleX의 핵심 기능

styleX의 핵심은 두 가지 기능으로 요약될 수 있다.

stylex.create
stylex.props

스타일을 생성하는 데 사용되는 create 함수와 스타일을 적용하는 데 사용되는 props 함수이다.

핵심 조건

StyleX는 사전 컴파일에 의존하므로 모든 스타일을 정적으로 분석할 수 있어야 한다.
즉, 모든 "원시 스타일 객체"는 오직 하나만 포함해야 한다.

가능한 것

객체 리터럴
문자열 리터럴
숫자 리터럴
배열 리터럴
'null' or 'undefined'
상수, 간단한 표현식, 내장 메서드 (예:.toString())
동적 스타일을 위한 화살표 함수

불가능한 것

함수호출 ( StyleX 함수 제외)
다른 모듈에서 가져온 값 (.stylex.js 파일에서 stylex를 사용하여 만든 CSS 변수 제외)

기본적인 사용법

stylex.create

import * as stylex from "@stylex/stylex"
const styles = stylex.create({
    base: {
        fontSize: 16,
        lineHeight: 1.5,
        color: "rgb(60, 60, 60)",
    },
    highlighted: {
        color: "rebeccapurple",
    },
})

Pseudo-classes

의사 클래스 (예 : :hover)는 스타일 객체의 키로 사용할 수 있다.

const styles = stylex.create({
    base: {
        fontSize: 16,
        lineHeight: 1.5,
        color:{
            default: "rgb(60, 60, 60)",
            ":hover": "rebeccapurple",
        },
        }
    },
})

원하는 속성에 default를 이용해서 기본값을 지정하고 hover, active, focus 등의 의사 클래스를 키로 스타일을 지정할 수 있다.

media queries (반응형)

styleX를 이용한 반응형 스타일링은 아래와 같이 작성한다.

const styles = stylex.create({
    wrapper: {
        display: "flex",
        width: {
            default: "200px",
            "@media (min-width: 600px)": "400px",
        },
    },
})

조금 더 편하게 쓰기 위해서 범위를 지정하고 사용할 수 있다.

const MEDIA_MOBILE = '@media (min-width: 600px)' as const;
const styles = stylex.create({
    wrapper: {
        display: "flex",
        width: {
            default: "200px",
            [MEDIA_MOBILE]: "400px",
        },
    },
})

이를 이용해서 활용하는 방법은 아래와 같다.

const styles = stylex.create({
    button: {
        backgroundColor: {
            default: "blue",
            [MEDIA_MOBILE]: "red",
            ":hover": {
                default: "skyblue",
                [MEDIA_MOBILE]: "black",
            },
        },
    },
})

여러 스타일 지정하기

const styles = stylex.create({
    // ...지정 스타일
})
const text = stylex.create({
    // ...지정 스타일
})

stylex.props

지정한 스탕을 적용하기 위해서는 stylex.props를 사용한다.

import * as stylex from "@stylex/stylex"
const styles = stylex.create({
    base: {
        fontSize: 16,
        lineHeight: 1.5,
        color: "rgb(60, 60, 60)",
    },
    highlighted: {
        color: "rebeccapurple",
    },
})
function MyComponent({ highlighted }) {
    return (
        <div {...stylex.props(styles.wrapper)}>
            <div {...stylex.props(styles.container)}>
                <p {...stylex.props(styles.button, text.base)}>Hello world</p>
            </div>
        </div>
    )
}

예시 코드

create-next-app을 이용해서 예시 코드를 작성해 보았다.

// layout.tsx
import type { Metadata } from "next"
import "./globals.css"

export const metadata: Metadata = {
    title: "Create Next App",
    description: "Generated by create next app",
}

export default function RootLayout({ children }: { children: React.ReactNode }) {
    return (
        <html lang="en">
            <body>{children}</body>
        </html>
    )
}

// page.tsx
import * as stylex from "@stylexjs/stylex"

export default function Home() {
    return (
        <div {...stylex.props(styles.wrapper)}>
            <div {...stylex.props(styles.container)}>
                <p {...stylex.props(styles.button, text.base)}>Hello world</p>
            </div>
        </div>
    )
}

const MEDIA_MOBILE = "@media (min-width: 600px)"
const styles = stylex.create({
    wrapper: {
        width: "100vw",
        height: "100vh",
    },
    container: {
        display: "flex",
        width: "100%",
        height: "100%",
        flexDirection: "column",
        alignItems: "center",
        justifyContent: "center",
        backgroundColor: "rgb(255, 171, 171)",
    },
    button: {
        backgroundColor: {
            default: "blue",
            [MEDIA_MOBILE]: "red",
            ":hover": {
                default: "skyblue",
                [MEDIA_MOBILE]: "black",
            },
        },
        width: {
            default: "200px",
            [MEDIA_MOBILE]: "400px",
        },
        height: "50px",
        justifyContent: "center",
        alignItems: "center",
        display: "flex",
        cursor: "pointer",
    },
})
const text = stylex.create({
    base: {
        fontSize: 16,
        lineHeight: 1.5,
        cursor: "pointer",
        color: {
            default: "rgb(255, 255, 255)",
            ":hover": "rgb(0, 0, 0)",
        },
    },
    highlighted: {
        color: "rebeccapurple",
    },
})

예시 코드의 결과물

231110 - 카카오 로그인 (feat. KOE010)

백씨네 — Fri, 10 Nov 2023 21:11:28 +0900

카카오 로그인 토큰 받기

문제

카카오 로그인 중 2단계에 해당하는 토큰을 받아오는 과정에서 axios로는 정상적으로 받아오는데 fetch로는 받아오지 못하는 문제가 발생했다.
처음에 fetch를 사용했던 방법은

const url = `https://kauth.kakao.com/oauth/token`
const body = {
        grant_type: 'authorization_code',
        client_id: process.env.REST_API as string,
        redirect_uri: process.env.REDIRECT as string,
        code,
    }
const result = await fetch(url, {
        method: 'POST',
        headers: {
            'Content-Type': 'application/x-www-form-urlencoded;charset=utf-8',
        },
        body: JSON.stringify(body),
    })
const data = await result.json()

을 사용했다.

하지만 이 방법은 아래와 같은 오류(KOE010)를 발생했다.

{
  error: 'invalid_client',
  error_description: 'Bad client credentials',
  error_code: 'KOE010'
}

카카오 로그인 공식 문서를 보면 해당 오류는 클라이언트 시크릿(Client secret) 기능을 사용하는 앱에서 토큰 요청 시 client_secret 값을 누락했거나 잘못된 값을 전달한 경우 발생한다고 한다.

하지만 나는 클라이언트 시크릿 기능을 활성화하지 않은 상태이기 때문에 이 오류가 발생할 수 없다.

다른 방법

axios로 요청을 보내는 방법을 사용했더니 정상적으로 토큰을 받아왔다. 그래서 axios와 fetch의 차이점을 찾아보았다.

차이점

Content-Type과 요청 본문의 형식

카카오 API는 일반적으로 application/x-www-form-urlencoded 형식의 데이터로 요청을 받는다. axios를 사용할 때, 요청 본문은 자동으로 application/x-www-form-urlencoded 형식으로 변환됩니다. headers에서 설정한 Content-Type과 일치합니다.
반면, fetch를 사용할 때는 JSON.stringify(body)를 사용하여 요청 본문을 JSON 형식으로 변환합니다. 그러나 headers에서 설정한 Content-Type은 application/x-www-form-urlencoded이다.

그래서 형식이 맞지 않아 오류가 발생한 것이다. 형식을 맞춰 주기 위해서 fetch를 사용할 때는 URLSearchParams를 사용하여 요청 본문을 application/x-www-form-urlencoded 형식으로 변환해주어야 한다.

어떻게 보면 너무 어이없는 실수를 한 것 같다.

해결

axios 방식

const url = `https://kauth.kakao.com/oauth/token`
const body = {
        grant_type: 'authorization_code',
        client_id: process.env.REST_API as string,
        redirect_uri: process.env.REDIRECT as string,
        code,
    }
const {data} = await axios.post(
    url,
    {
        grant_type: 'authorization_code',
        client_id: process.env.REST_API as string,
        redirect_uri: process.env.REDIRECT as string,
        code,
    },
    {
        headers: {
            'Content-Type': 'application/x-www-form-urlencoded;charset=utf-8',
        },
    },
)

fetch 방식

const url = `https://kauth.kakao.com/oauth/token`
const fetchBody = new URLSearchParams({
        grant_type: 'authorization_code',
        client_id: process.env.REST_API as string,
        redirect_uri: process.env.REDIRECT as string,
        code,
})

const result = await fetch(url, {
        method: 'POST',
        headers: {
            'Content-Type': 'application/x-www-form-urlencoded;charset=utf-8',
        },
        body: fetchBody,
    })
const data = await result.json()

231109 - Monorepo를 이용한 Next.js 프로젝트 구성하기 (feat. pnpm)

백씨네 — Thu, 9 Nov 2023 16:23:37 +0900

Monorepo를 이용한 Next.js 프로젝트 구성하기 (feat. pnpm)

모노레포를 위한 pnpm 설치

해당 모노레포의 패키지는 pnpm을 이용한다.

pnpm : https://pnpm.io/ko/installation

pnpm은 npm과 비슷한 패키지 매니저이다.
- 하드 링크와 심볼릭 링크를 사용하여 중복된 패키지를 여러 프로젝트에서 재사용한다. ( 디스크 공간 절약 )
- 즉, npm은 패키지를 중복해서 설치하지만 pnpm은 패키지를 공유한다.
pnpm은 패키지를 병렬로 설치하기 때문에 npm보다 빠르다.

# homebrew로 설치
$ brew install pnpm

# Powershell
$ iwr https://get.pnpm.io/install.ps1 -useb | iex


# npm으로 설치
$ npm install -g pnpm


# 다른 방법도 많이 있다..

루트 지정

작업을 진행할 루트 디렉토리를 지정하고 해당 디렉토리에서 pnpm init을 실행한다.

$ mkdir next-monorepo
$ cd next-monorepo
$ pnpm init
$ pnpm -v # 버전 확인

package.json이 생성이 된다.

{
    "name": "monorepotest2",
    "version": "1.0.0",
    "description": "",
    "main": "index.js", // 필요 없으므로 삭제
    "packageManager": "pnpm@8.10.2"
    "scripts": {
        "test": "echo \"Error: no test specified\" && exit 1"
    },
    "keywords": [],
    "author": "",
    "license": "ISC"
}

package.json 세팅 이후 프로젝트에 맞게 디렉토리 구조를 설정한다.

디렉토리 구조 설정

$ mkdir packages
$ mkdir packages/components
$ mkdir packages/api
$ mkdir packages/utils

$ mkdir apps
$ mkdir apps/client
$ mkdir apps/admin

프로젝트마다 원하는 디렉토리 구조는 다르겠지만 예시로 위와 같이 만든다.

components 디렉토리는 공통으로 사용할 컴포넌트를 모아놓는다.
api 디렉토리는 api 요청을 모아놓는다.
utils 디렉토리는 공통으로 사용할 유틸리티 함수를 모아놓는다.

그리고 만들어진 디렉토리들을 monorepo로 사용하기 위해서 워크스페이스 설정을 해주어야 한다.

워크스페이스 설정

루트 디렉토리에 pnpm-workspace.yaml 파일을 생성한다.

packages:
    - "packages/*"
    - "apps/*"

pnpm-workspace.yaml 파일은 pnpm이 모노레포를 인식할 수 있도록 해주는 파일이다.
위와 같이 설정하면 packages와 apps 디렉토리를 모두 인식한다.

해당 디렉토리들 내에 위치한 각각의 package.json 파일들을 인식하여 의존성을 관리한다.

현재까지 디렉토리 구조

 next-monorepo
 ┣  apps
 ┃ ┣  admin
 ┃ ┗  client
 ┣  packages
 ┃ ┣  api
 ┃ ┣  components
 ┃ ┗  utils
 ┣  package.json
 ┗  pnpm-workspace.yaml

각 프로젝트에 Next 설치

# next-monorepo 디렉토리에서

$ cd apps/client
$ pnpx create-next-app@latest .

$ cd apps/admin
$ pnpx create-next-app@latest .

각 서비스를 위한 apps 디렉토리 내부에서 next를 설치한다.

Next도 동일하게 쓰는 건데 왜 따로 설치하는지 의문이 들 수 있다.
하지만 각각의 서비스마다 필요한 패키지가 다를 수 있기 때문에 따로 설치한다.
또한 독립적인 배포를 위해서도 따로 설치한다.

프로젝트 실행하기

각 page.tsx 파일에 Hello, Client!! 와 Hello, Admin!! 을 출력하는 코드를 작성한다.

루트 디렉토리에서 --filter을 이용해서 해당 서비스를 실행한다.

pnpm --filter [서비스명] [명령어] 명령어를 작성해야 한다.

# 클라이언트를 실행하기 위해서 루트 디렉토리에서 client 실행
$ pnpm --filter client dev

# 어드민을 실행하기 위해서 루트 디렉토리에서 admin 실행
$ pnpm --filter admin dev

매번 --filter 서비스명을 지정하는 것이 번거롭기 때문에 루트에 있는 package.json의 script를 이용해서 지정하여 쓸 수 있다.

{
    "name": "monorepotest2",
    "version": "1.0.0",
    "description": "",
    "main": "index.js",
    "scripts": {
        "test": "echo \"Error: no test specified\" && exit 1",
        "client": "pnpm --filter client",
        "admin": "pnpm --filter admin"
    },
    "keywords": [],
    "author": "",
    "license": "ISC"
}

이후 아래와 같이 실행할 수 있다.

# 루트 디렉토리에서
$ pnpm client dev
$ pnpm admin dev

현재까지 디렉토리 구조

 next-monorepo
 ┣  apps
 ┃ ┣  admin
 ┃ ┃ ┗  (next 설치됨)
 ┃ ┗  client
 ┃ ┃ ┗  (next 설치됨)
 ┣  node_modules
 ┣  packages
 ┃ ┣  api
 ┃ ┣  components
 ┃ ┗  utils
 ┣  package.json
 ┗  pnpm-workspace.yaml

각 프로젝트에 next를 설치했지만 루트 디렉토리에 node_modules가 생성되었다.
이는 pnpm이 모노레포를 인식할 수 있도록 해주는 pnpm-workspace.yaml 파일이 있기 때문이다.

즉, 각 프로젝트에 공통된 패키지가 있다면 루트에서 설치하여 각 프로젝트는 하나의 패키지로 관리할 수 있다.

공통 패키지

공통 패키지 설치

만약 각 프로젝트에 recoil을 설치하고 싶다면 루트 디렉토리에서 설치하면 된다.

# 루트 디렉토리에서
$ pnpm install recoil

ERR_PNPM_ADDING_TO_ROOT Running this command will add the dependency to the workspace root, which might not be what you want - if you really meant it, make it explicit by running this command again with the -w flag (or --workspace-root). If you don't want to see this warning anymore, you may set the ignore-workspace-root-check setting to true.

이는 해당 패키지가 루트 디렉토리에 설치되었기 때문에 발생하는 에러이다. 프로젝트 내부에서 설치해야 할 것을 잘못 설치하는 상황을 방지하기 위해서 발생하는 에러이다.

하지만 우리는 루트 디렉토리에 설치하고 싶다. 이를 위해서는 -w 를 추가해 주면 된다.

# 루트 디렉토리에서
$ pnpm install recoil -w

그러면 이렇게 문제없이 설치가 된다

공통 패키지 사용하기

공통으로 사용하는 components, api, utils를 packages 디렉토리를 만들었고
하위에 각 디렉토리를 만들었을 때 각각의 디렉토리마다 package.json을 생성해야 한다.

# /packages 각 디렉토리에서
$ npm init

각 디렉토리마다 package.json을 생성하고 해당 필요한 패키지를 설치한다.

 packages
 ┣  api
 ┃ ┗  package.json
 ┣  components
 ┃ ┗  package.json
 ┗  utils
 ┃ ┗  package.json

공통 패키지 작성하기

components 디렉토리에 Button 컴포넌트를 만들고 각각의 프로젝트에서 사용하기 위해서 package.json을 지정해야 한다.

공통으로 사용할 컴포넌트

// /packages/components/Button.tsx
import React from "react"

interface ButtonProps {
    children: React.ReactNode
}

export const Button = ({ children }: ButtonProps) => {
    return <button>{children}</button>
}

공통으로 사용할 컴포넌트를 만든 후 사용할 프로젝트에서 해당 패키지를 설치한다.

Client 측에서 components 패키지를 이용하겠다.

# 루트 디렉토리에서
$ pnpm --filter client add components --workspace
$ pnpm client add components --workspace
$ pnpm client add utils --workspace
$ pnpm client add api --workspace


# 즉
$ pnpm --filter [서비스명] add [패키지명] --workspace

pnpm client으로 쓸 수 있는 이유는 위에서 루트 package.json에 script로 작성해 뒀기 때문이다.

패키지를 이용하겠다는 명령어를 쓰고 나면 client 디렉토리의 package.json이

{
    "dependencies": {
        "components": "workspace:^"
    }
}

이렇게 추가됐을 것이다. 이는 해당 프로젝트에서 components 패키지를 사용하겠다는 의미이다.

또한 node_modules 디렉토리에 components 디렉토리가 생성되어 있을 것이다.


 node_modules
 ┗  components
 ┃ ┣  Button.tsx
 ┃ ┗  index.ts

반드시 공유하고 싶은 디렉토리(패키지)는 package.json이 있어야 한다.

컴포넌트 내부 디렉토리 구조

그리고 컴포넌트가 많을 때 아래와 같은 경우로 디렉토리를 설정할 경우도 있다.


 components
┣  Box
┃ ┗  index.tsx
┣  Icon
┃ ┣  ArrowDown.tsx
┃ ┗  index.ts
┣  boxIcon
┃ ┗  index.tsx
┣  button
┃ ┗  index.tsx
┣  input
┃ ┗  index.tsx
┣  index.ts
┗  package.json

패키지로 내보내는 components 디렉토리 내부에 각각의 컴포넌트를 디렉토리로 만들 경우 index를 이용해서 내보내고 components/index.ts를 만들어 각각의 디렉토리도 내보내야 한다.

Icon을 예시로 살펴보면

ArrowDown.tsx로 만든 컴포넌트를 내보내기 위해서 Icon/index.ts를 만들어야 한다.

// /packages/components/Icon/index.ts
export * from "./ArrowDown"

그리고 components/index.ts를 만들어서 각각의 디렉토리를 내보내야 한다.

// /packages/components/index.ts

//...
export * from "./Box"
export * from "./Icon"
// ...

이렇게 하면 components 패키지를 설치한 프로젝트에서 아래와 같이 사용할 수 있다.

// (client 프로젝트에서 사용할 곳)/page.tsx

import { Button, Box, Icon } from "components"

//...
return (
    <>
        <Button />
        <Box />
        <Icon />
    </>
)
//...

모노레포를 이용한 components 패키지 완성

모노레포를 이용한 components 패키지 완성!!!

Next 13 공식문서 읽기 (3)

백씨네 — Tue, 7 Nov 2023 20:45:28 +0900

라우팅 기본

모든 애플리케이션의 뼈대는 라우팅이다.
라우팅의 기본 개념과 Next.js에서 라우팅 처리하는 방법에 대해서 소개한다.

용어

next13 tree

트리 (Tree) : 계층 구조를 시각화하기 위한 규칙.
- 부모 및 자식 구성 요소가 있는 구성 요소 트리
- 폴더 구조
  - 하위 트리 : 트리의 일부, 새 루트(first)에서 시작하여 Leaves(last)에서 끝난다.
  - 루트 : 트리 또는 하위트리 (예: 루트 레이아웃)의 첫 번째 노드
  - Leaf : URL 경로의 마지막 세그먼트와 같이 하위 트리에 자식이 없는 노드

next 13 url

URL 세그먼트 : 슬래시로 구분된 URL 경로의 일부
URL 경로 : 도메인 다음에 오는 URL의 일부 ( 세그먼트로 구성된다.)

App Router

Next.js v13은 React Server Components 기반의 새로운 App router를 선보였다.

공유 레이아웃
중첩 라우팅
로딩 상태
오류 처리 등을 지원한다.

App Router는 App이라는 새로운 디렉터리에서 작동한다. App 디렉터리는 페이지 디렉터리와 함께 작동하여 점진적인 채택을 허용한다.

이전 동작을 위해 페이지 디렉터리에 다른 경로를 유지하면서 애플리케이션의 일부 경로를 새로운 동작으로 선택할 수 있다.

중요

App Router는 Page Router보다 우선이다. 디렉터리가 동일한 URL 경로로 사용하지 않아야 하며, 충돌을 방지하기 위해서 Build 과정에서 오류가 발생한다.

기본 내부 구성요소

기본적인 앱 내부 구성요소

권장 사항:서버 구성 요소를 처음 사용하는 경우 서버 페이지를 확인한다.

폴더 및 파일 역할

Next.js는 파일 시스템 기반 라우터를 사용한다. ( 파일을 이용하여 라우터를 설정한다.)

page.js
Route 세그먼트에 표시되는 UI를 만들기 위해서 파일을 사용한다.(특수파일 : loading, layout, error... )

경로 세그먼트

경로의 각 폴더는 Route Segment를 나타낸다. 각 Route Segment는 URL 경로의 해당 세그먼트에 매핑된다.

중첩 라우팅

중첩 라우팅은 폴더를 서로 중첩하여 만들 수 있다. 예를 들어 App 디렉터리에서 두 개의 새 폴더를 중첩하여 /dashboard/setting 경로를 추가할 수 있다.

/dashboard/setting 는 세 가지의 세그먼트로 구성된다.

/ : 루트 세그먼트
dashboard : 세그먼트
setting : Leaf 세그먼트

파일 규칙

Next.js는 중첩된 경로에서 특정 동작을 사용하여 UI를 만드는 특수한 파일을 지원한다.

layout : 세그먼트 및 해당 자식에 대한 공유 UI
page : 경로의 고유 UI 및 경로를 공개적으로 접근할 수 있도록 한다.
loading : 세그먼트 및 해당 자식에 대한 Loading UI
not-found : 세그먼트 및 해당 자식에 대한 Not-Found UI
error : 세그먼트 및 해당 자식에 대한 Error UI
global-error : 글로벌 Error UI
route : Server-side API 엔드포인트
template : layout과 비슷하지만 자식요소마다 새로운 인스턴스를 생성
default : 병렬 Route에 대한 폴백 UI

구성요소 계층

라우터 세그먼트의 특수 파일에 정의된 반응 구성요소는 특정 계층으로 렌더링 된다.

layout
template
error.js : error boundary
loading.js : suspense boundary
not-found.js : error boundary
page.js or 중첩된 layout.js

중첩 라우터에서 세그먼트의 구성요소는 상위 세그먼트 구성요소 내부에 중첩된다.

Colocation

특수 파일 외에도 App 디렉터리의 폴더 내에 자신의 파일을 배치할 수 있는 옵션이 있다. (예: 구성요소, 스타일, 테스트 등)

폴더는 route로 정의되지만 page.js 또는 route.js에서 반환되는 내용만 주소로 지정이 가능하다.

/component/button : 라우팅 불가
/lib/constants : 라우팅 불가
/dashboard : 라우팅 가능 ( /dashboard/page 아님!)
/dashboard/nav : 라우팅 불가
/api : 라우팅 가능 ( /api/route 아님!)
/api/db : 라우팅 불가

고급 라우팅 패턴

앱 라우터는 고급 라우팅 패턴을 구현하는데 도움이 되는 규칙을 제공한다.

병렬 라우트 :독립적으로 탐색할 수 있는 두 개 이상의 페이지를 동일한 페이지에서 동시에 표시할 수 있다. 자체 하위 탐색이 있는 분할 보기 (예: 대시보드)에 사용할 수 있다.
라우팅 가로채기 : 경로를 가로채서 다른 경로의 컨텍스트에 표시할 수 있다. 현재 페이지의 컨텍스트를 유지할 때 사용할 수 있다. (예 : 하나의 작업을 편집하거나 피드에서 사진을 확장하는 동안 모든 작업을 볼 수 있다.)

이러한 패턴을 통해서 복잡했던 기능을 쉽게 구현할 수 있다.

사진 및 내용 출처 : NEXT 공식문서 (https://nextjs.org)

Next 13 공식문서 읽기 (2)

백씨네 — Sun, 5 Nov 2023 02:16:32 +0900

Next.js 프로젝트 구조

최상위 파일 및 폴더, 구성파일 및 라우팅 규칙에 대한 내용을 설명한다.

최상위 폴더

app : 앱라우터
pages : 페이지 라우터
public : 서비스의 정적 자산(데이터)
src : 애플리케이션 원본 폴더 (선택사항 )

최상위 파일

next.config.js : Next.js에 대한 구성 파일
package.json : 프로젝트 종속성 및 스크립트
instrumentation.ts : OpenTelementry / instrumentation file (이 부분에 대한 개념은 아직... 애플리케이션의 모니터링을 위한 것 같다.)
middleware.ts : Next.js 요청 미들웨어
.env : 환경변수
.env.local : 로컬 환경변수
.env.production : 배포 환경변수
.env.development : 개발 환경변수
.eslintrc.json : ESLint의 구성파일
.gitignore : 무시할 git 파일/폴더 설정
next-env.d.ts : Next.js의 스크립트 선언 파일
tsconfig.json : 타입스크립트 설정 파일
jsconfig.json : 자바스크립트 설정 파일

앱 라우팅 규칙

1. 라우팅 파일

layout : 레이아웃 파일
page : 페이지 파일
loading : 로딩 UI
not-found : Not found UI
error : 에러 UI
global-error : 전역 오류 UI
route : 라우터
template : 템플릿 파일(탐색 중인 자식에 대한 새로운 레이아웃)
default : 병렬 라우터 fallback 페이지

2. 중첩 라우팅

folder : route segment
folder/folder : 중첩 route segment

예를 들어, "http://localhost:3000/about"에 대한 라우터는

루트에서 about 폴더를 만들어서 사용한다.

/app
    /about
        page.ts

이렇게 하면 /about에 대한 라우팅을 할 수 있다.

그러므로 "http://localhost:3000/about/me"에 대한 라우팅은

/app
    /about
        /me
            page.ts

위와 같은 방법으로 라우팅을 설정할 수 있다.

3. 동적 경로 ( Dynamic Routes)

[folder] : 동적 경로 세그먼트
[...folder] : Catch-all 경로 세그먼트
[[...folder]] : Catch-all 경로 세그먼트 (옵션)

4. 라우트 그룹 및 Private 폴더

(folder): 라우팅에 영향을 주지 않고 경로를 그룹화 (group)
_folder : 라우팅에서 폴더 및 모든 자식 세그먼트 숨김 ( private )

5. 병렬 및 인터셉트 라우트

@folder : 명명된 슬롯
(.)folder : 동일 레벨에서 가로채기
(..)folder : 한 단계 위에서 가로채기
(..)(..)folder : 두 단계 위에서 가로채기
(...)folder : 루트에서 가로채기

6. 메타데이터 파일 규칙

6-1. 앱 아이콘

이름	확장자	설명
favicon	.ico	파비콘 파일
icon	.ico, .jpg, .png, ...	앱 아이콘 파일
icon	.js, .ts, .tsx	생성된 앱 아이콘
apple-icon	.ico, .jpg, .png, ...	Apple 앱 아이콘 파일
apple-icon	.js, .ts, .tsx	생성된 Apple 앱 아이콘

6-2. 오픈그래프 및 트위터 이미지

이름	확장자	설명
opengraph-image	.jpg, .png, .gif, .jpeg	오픈그래프 이미지 파일
opengraph-image	.js, .ts, .tsx	생성된 오픈그래프 이미지
twitter-image	.jpg, .png, .gif, .jpeg	트위터 이미지 파일
twitter-image	.js, .ts, .tsx	생성된 트위터 이미지

6-3. SEO

이름	확장자	설명
sitemap	.xml	사이트맵 파일
sitemap	.ts, .js	생성된 사이트맵
robots	.txt	로봇 파일
robots	.js, .ts	생성된 로봇 파일

사진 및 내용 출처 : NEXT 공식문서 (https://nextjs.org)

Next 13 공식문서 읽기 (1)

백씨네 — Fri, 3 Nov 2023 01:46:45 +0900

NextJS 공식문서 읽기

https://nextjs.org/docs

Next.js란?

풀스택 웹 애플리케이션을 구축하기 위한 리액트 프레임워크이다.

React 컴포넌트를 사용하여 UI를 구축하고 Next.js를 사용하여 추가적인 기능과 최적화 작업을 수행한다.

Next.js에서 번들링, 컴파일 등 React에 필요한 툴링을 추상화하여 자동으로 구성한다.

이를 통해 설정에 시간을 할애하는 대신 애플리케이션 구축을 하는데에 집중할 수 있다.

Next.js의 주요 특징

1. 라우팅

레이아웃, 중첩라우팅, 로딩, 에러 처리 등을 지원하는 서버 컴포넌트 위에 구축된 파일 시스템 기반 라우터

2. 렌더링

클라이언트 및 서버 컴포넌트를 사용한 클라이언트 및 서버 측 렌더링
Next.js를 사용하는 서버에서 정적 및 동적 렌더링을 통해서 최적화했다.

3. 데이터 패칭

서버 컴포넌트에서 async/await 기능을 이용해서 데이터 가져오기를 간소화하고 요청 메모, 데이터 캐싱 및 재검증을 위한 확장된 fetch API를 제공한다.

4. 스타일링

CSS 모듈, 테일윈드, CSS-in-JS 등 선호하는 스타일링 방법 지원

5. 최적화

이미지, 글꼴 및 자바스크립트 최적화를 통해 응용 프로그램의 핵심 웹 바이탈, 사용자 환경을 개선할 수 있다. (최적화해서 성능을 좋게 했다.)

6. 타입스크립트

타입스크립트에 대한 향상된 지원

App router VS Page Router

Next.js에는 App router와 page router라는 두 개의 다룬 라우터가 있다.

앱 라우터는 서버 컴포넌트 및 스트리밍과 같은 리액트 최신 기능을 사용할 수 있는 최신 라우터이다.

페이지 라우터는 Next.js에서 기존에 사용하던 라우터로 서버가 렌더링 한 React 응용 프로그램을 구축할 수 있고, 이전 Next.js 응용 프로그램에서 계속 지원된다.

Next.JS 설치하기

시스템 요구사항

Node.js v18.17 이상
window(WSL포함), macOS, Linux 지원

자동 설치

$ npx create-next-app@latest

위의 명령어를 이용하여 앱을 시작한다. 명령어를 이용하면 자동으로 설정을 해준다.

명령어를 입력하게 되면 프롬프트가 나타나는데
프로젝트 이름, 타입스크립트, ESLint, 테일윈드, "src/" 디렉터리, App Router, alias, configured의 사용여부를 확인하여 프로젝트의 이름으로 디렉터리를 만들고 필요한 종속성을 설치한다.

수동 설치는... 공식문서에서 확인하기..
- https://nextjs.org/docs/getting-started/installation

디렉터리 만들기

Next.js는 파일 시스템 라우팅을 사용한다. 즉, 애플리케이션의 경로는 파일(디렉터리) 구조에 따라 결정된다.

app/ 디렉터리 밑에 layout.tsx와 page.tsx 파일을 추가하면 사용자가 애플리케이션의 루트로 진입할 때 렌더링 된다. (''/'')

// app/layout.tsx

export default function RootLayout({
  children,
}: {
  children: React.ReactNode
}) {
  return (
    <html lang="en">
      <body>{children}</body>
    </html>
  )
}

// app/page.tsx

export default function Page() {
  return <h1> Hello, Next.js! </h1>
}

위와 같이 layout과 page의 초기를 설정할 수 있다.

public 디렉터리

이미지, 글꼴 등 정적 자산을 저장할 public 디렉터리를 만들고, public 디렉터리 내부의 파일은 기본 URL(/)에서 시작하는 코드로 참조할 수 있습니다.

개발 서버 실행

"npm run dev"를 이용해서 개발 서버를 실행할 수 있다.
실행 완료 후 'http://localhost:3000'로 애플리케이션을 볼 수 있다.
layout.tsx를 편집하고 저장하게 되면 브라우저에서 업데이트된 결과를 볼 수 있다.

사진 및 내용 출처 : NEXT 공식문서 (https://nextjs.org)

231010 - NextJS 클라이언트에서 S3 업로드

백씨네 — Wed, 11 Oct 2023 10:20:08 +0900

오늘 내가 배운 것

1. 문제 발생

2. 원인 및 목적

1. 문제 발생

HTTP 413 Error 발생

2. 원인 및 목적

Next.js를 이용하고 있는 프로젝트는 클라이언트 측에서 빠르게 업로드를 하기 위해서 S3에 업로드를 하고 URL을 반환받아서 DB에 저장하는 방식을 선택했다.

하지만 요청할 때 보내는 데이터의 크기가 크기 때문에 413 Error가 발생하였다. 요청 크기에 제한이 있어서 발생할 수 있는 문제이다.

내가 시도한 방법과 해결한 방법을 적어놨는데, 이 방법이 효율적인지는 알 수 없지만 방법 중에 하나이기 때문에 언젠가 쓸 수 있는 방법이라고 생각한다.

2-1. NextJS pages/api 라우터 이용 ( multer, config ) ( 실패 )

클라이언트는 NextJS를 이용하기 때문에 pages/api 라우터를 이용해서 S3에 업로드하려고 했다.

업로드할 동영상 파일을 선택한 뒤, formData 형식으로 변환한다.
변환된 formData를 multer를 이용해 api 라우터를 통해 S3에 업로드한다.

위와 같은 과정으로 클라이언트단에서 업로드를 처리하려 했으나 API에서 Request를 받는 과정에서 413 Error가 발생했다.

413 에러는 Payload Too Large로 요청 데이터의 크기가 너무 커서 발생하는 에러이다.

제일 먼저 검색해서 나온 해결 방법은 'experimental' 속성을 이용하여 크기 제한을 늘리는 것이었다.

// next.config.js
module.exports = {
    experimental: {
        serverActions: true,
        serverActionsBodySizeLimit: "500mb",
    },
}

// pages/api - video.js
//  pages/api 라우터 부분은 대략적으로 흐름만 확인..

export const config = {
    api: {
        bodyParser: false,
        responseLimit: false,
    },
}

export const upload = multer({
    storage: multerS3({
        s3: s3 as S3,
        bucket: 'mybucket', // 버킷 이름
        key(req, file, callback) {
            const ext = path.extname(file.originalname)
            const basename = path.basename(file.originalname, ext)
            callback(null, `interview/${basename}_${Date.now()}${ext}`)
        },
    }),
    limits: {
        fileSize: 500 * 1024 * 1024, // 500MB
    },
}).single('file')

export default (req: MulterRequest, res: NextApiResponse) => {
    if (req.method === 'POST') {
        upload(req as any, res as any, (err) => {
            if (err) {
                return res.status(400).send(err)
            }
            if (!req.file) {
                return res.status(400).send('No file uploaded')
            }
            return res.status(200).json({ url: req.file.location })
        })
    } else {
        res.status(405).end()
    }
}

하지만 실. 패.

위에 내용을 보면 bodyParser을 비활성화하는 로직이나 multer에서 걸릴만한 fileSize를 늘려주는 방법을 했지만 제대로 동작하지 않았다.

여기서 검색해서 얻은 결과는 pages/api 방식은 요청을 보내는데 제한이 있다는 점이었고, 이 부분에 대해서 제한을 해제하는 방법이 쉽지 않거나 없다는 점이다. (나는 못 찾았다.. 시도한 여러 방법이 다 실패.. )

그래서 라우터에서 업로드를 하는 것이 아닌 바로 클라이언트에서 S3로 직접 업로드하는 방식을 택했다.
서버의 요청 크기제한 문제를 피할 수 있고, 서버의 부하를 줄일 수 있다고 생각했다.

2-2. Client 측에서 미리 서명된 S3 URL을 이용하여 업로드하기

API 라우터를 이용해서 S3에 업로드를 할 위치 및 서명된 url을 생성한다. (이때, AWS의 키나 정보들이 서버 사이드로 동작하기 때문에 보안 측면에서 조금 이점이 있다고 생각한다.)

서명된 URL은 S3에 업로드할 파일의 위치와 파일명을 포함하고 있으며, 이 URL을 이용하여 클라이언트에서 업로드를 진행한다.

AWS S3와 같은 스토리지 서비스에서 자주 사용되는 방법인데, 서명된 URL을 이용하여 업로드를 진행하면 서버에서 업로드를 하지 않기 때문에 서버의 부하를 줄일 수 있고, 클라이언트에서 직접 업로드를 하기 때문에 빠르게 업로드를 할 수 있다.
또한 만료 시간을 설정할 수 있기 때문에 보안 측면에서도 안전하다. (만료 시간이 지나면 해당 URL은 더 이상 사용할 수 없다.)

생성된 URL을 이용하여 데이터를 업로드하기 위해서 'put'요청을 하고, 다운로드(view)를 위해서 'get'요청을 한다.

밑에 코드는 upload를 위한 코드이기 때문에, 해당 url로 put 요청을 하는 코드이다.

// pages/api - video.ts

import AWS from "aws-sdk"
import { NextApiRequest, NextApiResponse } from "next/types"

AWS.config.update({
    region: "my-region",
    accessKeyId: "aws-key",
    secretAccessKey: "aws-secretsKey",
})
const s3 = new AWS.S3()

export default (req: NextApiRequest, res: NextApiResponse) => {
    const newFileName = `${Date.now()}_${req.body.fileName}`
    const params = {
        Bucket: "my bucket",
        Key: `interview/${newFileName}`, // 버킷안에 interview 디렉토리의 newFileName이름으로 저장
        Expires: 60, // 서명된 url은 1분간 유효하다.
    }

    s3.getSignedUrl("putObject", params, (err, url) => {
        if (err) {
            res.status(500).json({ error: "Internal Server Error" })
        } else {
            // url은 서명된 url이며, fileUrl은 DB에 저장 될 S3 버킷의 pathName이다.
            res.status(200).json({ url, fileUrl: `/interview/${newFileName}` })
        }
    })
}

// Client Component - submitHandler에서 아래의 방법으로 업로드하고, 반환받은 fileUrl을 DB에 저장한다.

try {
    setLoading(true)
    const config = {
        headers: { "Content-Type": "video/*" },
        api: { bodyParser: false },
    }
    const {
        data: { url: signedURL, fileUrl }, // api 라우터에서 signedURL과 path로 저장할 fileUrl을 반환 받는다.
    } = await axios.post("/api/upload/video-url", { fileName: file.name }) // 업로드 했을 때 file의 상태로 데이터를 가지고 있고, file.name을 이용해서 url을 만들 기 위해서 api라우터로 보내준다.

    const data = await axios.put(signedURL, file, config) // 서명된 url에 put 요청으로 file을 보낸다.
    const submitData = await updataCourseApplyStep2({ id, interview_url: fileUrl })
    setLoading(false)
    if (submitData.updated) setIsStep(step + 1)
} catch (e) {
    console.log(e)
}

드디어 성. 공.

클린 코드, 효율적인 코드인지는 모르겠지만 해당 방법을 통해서 body의 내용이 큰 동영상 파일을 업로드할 수 있었다.

backend를 이용한 방법이나 AWS Ramda를 이용하는 방법도 생각해 봤지만 클라이언트단에서 하는 방법을 생각했고, AWS Ramda를 익히고 적용하기엔 조금 오래 걸릴 것 같아서 위의 방법을 이용했다.

230925 - React 컴포넌트의 유연성과 최적화 ( 조건부 렌더링, 다이나믹 컴포넌트, 고차컴포넌트(HOC))

백씨네 — Mon, 25 Sep 2023 18:20:09 +0900

오늘 내가 배운 것

1. 조건부 렌더링

2. 다이나믹 컴포넌트

3. 고차 컴포넌트(HOC)

React Component의 유연성과 최적화

React를 이용하면서 컴포넌트를 다룰 때, 렌더링 최적화하는 여러 방법이 있다.
여러 방법 중 3가지를 최근에 접하게 되었고, 이에 대해서 살펴보려고 한다.

각 방식의 렌더링 최적화 측면과 적용 상황을 정리하였다.

1. 조건부 렌더링

1-1. 렌더링 최적화

조건부 렌더링은 필요한 부분만 렌더링을 수행하기 때문에 렌더링 성능에 도움을 줄 수 있다. 불필요한 컴포넌트의 렌더링을 방지하기 때문에 페이지의 성능을 향상할 수 있다.

1-2. 적용 상황

간단한 조건에 따른 뷰 변경이 필요할 때 사용한다. 자주 변경되는 UI 부분에 유용하다.

주의 : 복잡한 조건이나 중첩된 조건이 많아지면 코드가 복잡해질 수 있다. 그리고 컴포넌트의 라이프사이클을 고려할 때는 조건부 렌더링만으로 부족할 수 있다.

1-3. 적용 예시

const App = (props) => {
    if (props.isLoggedIn) {
        return <Dashboard />
    } else {
        return <Login />
    }
}

2. 다이나믹 컴포넌트

2-1. 렌더링 최적화

코드 분할과 지연 로딩을 통한 성능 최적화에 유용할 수 있다. 예를 들어, 다이나믹 임포트를 통해 런타임에 필요한 컴포넌트만 로딩할 수 있습니다. 그렇기 때문에 초기 로딩 성능을 개선할 수 있다.

2-2. 적용 상황

여러 컴포넌트 중 하나를 동적으로 선택해야 할 때 사용한다.

주의 : 모든 컴포넌트가 공통된 props나 상태를 공유해야 하는 경우에는 적합하지 않을 수 있다. SSR을 사용하는 경우 다이나믹 임포트를 주의해야 한다.

2-3. 적용 예시

const Dashboard = () => <div>Dashboard</div>
const Login = () => <div>Login</div>

const App = (props) => {
    const { id } = props
    const DynamicComponent = props.componentType === "Dashboard" ? Dashboard : Login

    return <DynamicComponent id={id} />
}

3. 고차 컴포넌트(HOC)

Higher-Order Component로 다른 컴포넌트를 인자로 받아 새로운 컴포넌트를 반환한다.

3-1. 렌더링 최적화

고차 컴포넌트 자체는 렌더링 성능을 직접적으로 최적화하는 것은 아니지만 고차 컴포넌트를 통해 렌더링 로직을 분리하거나 제어할 수 있기 때문에 간접적으로 최적화에 도움을 줄 수 있다.

주의 : 코드의 재사용성에는 좋지만 너무 많은 로직을 HOC로 분리하게 되면 컴포넌트 구조가 복잡해질 수 있다. props 네이밍 충돌이 발생할 가능성이 있다.

3-2. 적용 상황

코드의 재사용성과 유지 보수성을 높이는데 주로 사용된다.

3-3. 적용 예시

// id에 따른 컴포넌트 변경
const withLogger = (WrappedComponent) => {
    return (props) => {
        return <WrappedComponent {...props} />
    }
}

const MyComponent = (props) => {
    return <div>{props.id}</div>
}

const MyComponentWithLogger = withLogger(MyComponent)

230920 - Next param

백씨네 — Thu, 21 Sep 2023 09:02:12 +0900

오늘 내가 배운 것

1. URL의 param 얻기

URL의 param 얻기

CRUD를 할 때 특정 글을 보거나 수정하거나 삭제하기 위해서 동적 매개 변수인 url의 param를 이용해서 해당 글을 찾아서 그 내용을 보여주거나, 수정하고, 삭제할 수 있는 기능을 구현할 수 있다.

커뮤니티 게시글에 대한 url이 아래와 같을 때

https://a.com/user/:id

여기서 id값이 특정 게시물마다 바뀌며 이 id 값을 param이라고 한다.

1-1. Client Component

클라이언트 컴포넌트에서 params 얻기 위해서 useParams라는 client component hook을 이용해서 얻을 수 있다.

const params = useParams()

이 hook은 클라이언트 컴포넌트에서만 사용 가능하므로, 서버 컴포넌트에서는 사용할 수 없다. 그렇기 때문에 클라이언트 컴포넌트에서 params를 얻기 위해서 새로운 파일로 해당 로직을 분리하고 상단에 'use client'를 이용해서 client compnent로 변경하게 되면 useParams()를 이용해서 id 값을 구할 수 있다.

1-2. Server Component

서버 컴포넌트를 이용하는 방법은 서버 사이드 라우팅 라이브러리를 이용하는 방법과 Next.js에서 제공하는 getServerSideProps, getStaticProps를 이용하는 방법이 있다.

export async function getServerSideProps(context) {
    const { id } = context.params

    return {
        props: {
            id,
        },
    }
}

Next.js의 페이지 컴포넌트에서만 이용이 가능하다. 이를 이용해서 렌더가 되기 전 server에서 처리 후 데이터를 클라이언트 측으로 전달한다.

230919 - Next Component, Cache

백씨네 — Tue, 19 Sep 2023 23:04:54 +0900

오늘 내가 배운 것

1. Component

2. 사용 예시

3. Cache

출처 : 생활코딩 Next 13강의

출처 : 생활코딩 Next 13 강의

1. Component

Client Component

react를 사용하면서 여태까지 구현해왔던 방식이다. 주로 브라우저에서 실행된다.
useState, useEffect, onClick, onChange, useRouter, useParams... 과 같이 클라이언트 단에서 조작할 수 있는 것을 의미한다.

사용자와 상호 작용을 할 수 있는 컴포넌트이다.

Server Component

서버단에서 조작을 위해서 사용하는 방식이다.
secure data나 cookie, header에 접근할 수 있다.
Server Component 에서는 Client Component를 이용하게 되면 에러를 발생할 수 있다.

사용자에게 단순히 화면을 보여주는 역할을 하는 컴포넌트이다.

Next.js 컴포넌트

next.js에서는 기본적으로 서버 컴포넌트로 간주하기 때문에 클라이언트 컴포넌트를 이용하기 위해서 특정한 조치가 있어야한다.

'use client'를 이용하면 클라이언트 컴포넌트가 된다.

2. 사용 예시

"use client"
import Link from "next/link"
import "./globals.css"
import { useEffect, useState } from "react"

export default function RootLayout({ children }) {
    const [topics, setTopics] = useState([])
    useEffect(() => {
        fetch("http://localhost:9999/topics")
            .then((res) => res.json())
            .then((res) => setTopics(res))
    }, [])
    return // <>렌더 내용</>
}

해당 코드는 클라이언트 컴포넌트로 JS가 실행되지 않으면 상태를 가져올 수 없다. 이런 것을 해결하기 위해서 클라이언트 컴포넌트를 서버 컴포넌트로 바꾸어 사용한다.

'use client' 를 없앤다.
상태 관련 클라이언트 메서드(useState, useEffect..)를 지운다.
async-await를 이용하여 비동기를 동기적으로 사용한다.

import Link from "next/link"
import "./globals.css"

export default async function RootLayout({ children }) {
    const resp = await fetch("http://localhost:9999/topics")
    const topics = await resp.json()
    return // <>렌더 내용</>
}

이렇게하면 서버에서 최종적인 정적의 데이터만 사용자에게 넘겨서 화면을 그려준다. ( JS 내용은 제외된다.)

정적 데이터, 파일으로 화면을 그리게 되면 장점이 생긴다.

사용자에게 JS를 전송하지 않기 때문에 용량이 적어진다.
접근하는 서버가 같은 서버라면 빠르게 처리하여 보여줄 수 있다.
서버에서 렌더링이 끝난 후 데이터를 보내기 때문에 JS가 실행되지 않더라도 화면을 그리는데 문제가 없다.

3. Cache

Next.js에서는 기본적으로 요청과 응답에 의해서 얻은 데이터를 보관하는 캐시의 기능을 가지고 있다.

캐시 기능은 기존에 요청해서 얻은 데이터를 저장시켜두고 다시 로드가 되었을 때, 저장되어 있는 데이터를 가져오는 것을 말한다. 이를 이용하여 성능을 좋게 만들 수 있지만 상황에 따라서 새롭게 업데이트 된 내용을 불러와서 보여야 하는 경우에는 옳지 않은 방법일 수 있다.

그렇기 때문에 여러 방법을 이용해서 이 기능을 끄거나 주기를 짧게 하여 데이터를 계속 최신화 하는 방법이 있다.

주기적으로 업데이트 하기

fetch("https://...", { next: { revalidate: 10 } })

이 방법은 뒤에 있는 숫자(10초)주기로 데이터를 업데이트하는 방식이다.
지정된 숫자를 이용해서 했을 때, 그 주기에 맞춰지기 전까지는 직전 데이터를 이용한다. ( 10초의 경우 10초가 되기 전에 데이터가 바뀌어도 기존의 데이터를 사용함)
그래서 0을 넣어 매번 업데이트를 할 수 있다.

cache 기능을 비활성화 하기

fetch("https://...", { cache: "no-store" })

이 방법을 이용해서 캐싱자체를 안하는 방법을 구현 할 수 있다.

230918 - Next Routing (라우팅)

백씨네 — Mon, 18 Sep 2023 18:14:49 +0900

오늘 내가 배운 것

1. Routing
2. Dynamic routing
3. Next.js Routing
4. SPA

1. Routing

https://example.com/dashboard/analytics

example.com : Domain : example.com은 도메인이라고 부른다.
dashboard/analytics : 도메인 뒤를 path라고 부른다.
dashboard, analytics : path의 구성요소로 segment라고 부른다.

라우팅이라는 것은 경로에 따라서 어떤 컨텐츠를 어떤 방식으로 보여줄 것인가를 결정하는 것이라고 한다.

2. Dynamic routing

다이나믹 라우팅은 동적라우팅, 적응형 라우팅이라고도 한다.

https://example.com/read/1
https://example.com/read/2

위의 경로에서 1이나 2처럼 어떤 값이 올지 모르는(동적으로 바뀌는) 것을 말한다.

3. Next.js Routing

3-1. 기본

Next.js에서 라우팅을 위해서 디렉토리를 이용해서 할 수 있다.
path가 '/create'라고 한다면

https://localhost:3000/create

src/app/create 디렉토리를 이용해서 라우팅을하고 create/page.js의 파일을 이용해서 화면을 그릴 수 있다.

|- /src
|--- /app
|----- /create
|------- /layout.js
|------- /page.js
|----- /read
|------- /page.js

3-2. 다이나믹 라우팅

동적으로 변하는 id값을 가진 라우팅상황에서 path가 '/read/[id]'라고 한다면

https://localhost:3000/read/1
https://localhost:3000/read/2

src/app/read/[id] 디렉토리를 이용해서 라우팅하고 [id]/page.js 파일을 이용해서 화면을 그릴 수 있다.

|- /src
|--- /app
|----- /read
|------- /[id]
|--------- /page.js

// src/app/read/[id]/page.js
const Read = (props) => {
    return (
        <>
            <h2>Read</h2>
            param : {props.params.id}
        </>
    )
}

export default Read

4. SPA

Next.js는 SSR이나 SSG에 강점이 있지만 SPA방식으로 이용할 수 있다.
예를 들어 a태그를 이용해서 화면을 변경할 때 layout을 제외한 일부분만 변경되는 화면이여도 a태그를 이용한 화면에서는 서버를 이용해서 화면을 다시 그려서 클라이언트로 보내주기 때문에 HTML 전체를 다시 요청해서 그려서 사용자에게 보여준다.
이 과정에서 리소스를 많이 사용하기 때문에 서비스를 제공하는 개발자(제공자)가 비용이 많이 들어갈 뿐만 아니라 서비스를 이용하는 이용자도 시간을 사용하게 된다.
이를 해결하기 위해서 a태그 대신 next/link의 Link 컴포넌트를 이용할 수 있다.

Link 컴포넌트

// a태그
<h1>
    <a href="/">WEB</a>
</h1>

// Link 컴포넌트
<h1>
    <Link href="/">WEB</Link>
</h1>

Link 컴포넌트를 이용한 후 해당 페이지를 이동하기 전 hover 이벤트 발생시에 해당 라우터에서 데이터를 프리패치 할 수 있는 기능이 있다. 프리패치 기능은 대상 페이지의 데이터를 미리 로드하여 사용자가 해당 링크를 클릭했을 때 빠르게 페이지를 보여줄 수 있도록 도와준다.
Link 컴포넌트를 사용하면 서버의 부하를 줄이고, 사용자에게 더 나은 경험을 제공할 수 있습니다.

230918 - NEXT.JS 사용하기

백씨네 — Mon, 18 Sep 2023 18:04:33 +0900

오늘 내가 배운 것

1. NextJS란?

2. Next의 특징

3. 설치하기

1. NextJS란?

Next.js는 React를 기반으로 만들어진 웹 프레임워크이다.
서버 사이드 렌더링(SSR), 정적 사이트 생성(SSG), 클라이언트 사이드 렌더링(CSR) 등 다양한 렌더링 방식을 지원한다.

2. Next의 특징

1. SSR과 SSG 지원 : 서버사이드 렌더링과 정적 사이트 생성을 쉽게 구현할 수 있어서 검색 엔진 최적화(SEO)에 유리하다.
1. 빠른 성능 : 코드 스플리팅, 레이지 로딩, 프리페칭 등을 자동으로 지원하여 애플리케이션 성능을 최적화한다.
1. API Routes : 'pages/api' 디렉토리를 이용하여 API 엔드포인트를 생성할 수 있다. (프론트 서버의 개념)
1. 동적 라우팅 : 파일과 폴더 구조를 이용하여 라우팅을 자동으로 설정한다.

3. 설치하기

# next 최신버전을 현재 디렉토리에 설치하기
npx create-next-app@latest .

230829 - Frequency Counter (빈도 카운터) 패턴

백씨네 — Wed, 30 Aug 2023 01:53:13 +0900

오늘 내가 배운 것

1. Frequency Counter

2. 두 가지 배열이 주어졌을 때 첫 번째 배열의 각 요소가 두 번째 배열에 있는지 확인하기

3. 시간 복잡도 VS 공간 복잡도

1. Frequency Counter

데이터의 빈도수를 계산하기 위한 알고리즘 패턴
배열이나 문자열 등의 자료구조에서 특정 요소가 몇 개 있는지 셀 때 주로 사용된다.

// [1,2,1,3]
{
    "1": 2,
    "2": 1,
    "3": 1
}

키는 배열의 요소, 값은 해당 요소의 빈도수이다.

주로 사용하는 상황

1. 두 개의 배열이나 문자열이 같은 요소로 이루어져 있는지 확인하기
1. 배열이나 문자열에서 특정 요소의 빈도수를 찾기
1. 데이터의 분포를 빠르게 파악하기

등...

2. 두가지 배열이 주어졌을 때 첫 번째 배열의 각 요소가 두 번째 배열에 있는지 확인

방법 1

1번 배열의 제곱과 2번 배열이 맞는지 반복문을 통해서 검증한다.

function same(arr1, arr2) {
    if (arr1.length !== arr2.length) return false
    for (let i = 0; i < arr1.length; i++) {
        let correctIndex = arr2.indexOf(arr1[i] ** 2)
        if (correctIndex === -1) return false
        arr2.splice(correctIndex, 1)
    }
    return true
}

console.log(same([1, 2, 3], [4, 1, 9])) // true
// console.log(same([1, 2, 3], [4, 1, 4])) // false
// console.log(same([1, 2, 3], [4, 1, 9, 4])) // false

이 방법은 시간 복잡도가 O(n^2)이다. for문을 1번밖에 사용하지 않았지만 indexOf()가 내부적으로 반복문을 사용하기 때문에 O(n^2)이다.

방법 2

빈도 카운터 패턴을 이용하는 방법

function same2(arr1, arr2) {
    if (arr1.length !== arr2.length) return false
    let frequencyCounter1 = {}
    let frequencyCounter2 = {}
    for (let val of arr1) {
        frequencyCounter1[val] = (frequencyCounter1[val] || 0) + 1
    }
    for (let val of arr2) {
        frequencyCounter2[val] = (frequencyCounter2[val] || 0) + 1
    }
    for (let key in frequencyCounter1) {
        if (!(key ** 2 in frequencyCounter2)) return false
        if (frequencyCounter2[key ** 2] !== frequencyCounter1[key]) return false
    }
    return true
}

console.log(same2([1, 2, 3], [4, 1, 9])) // true
// console.log(same2([1, 2, 3], [4, 1, 4])) // false

두 개의 루프를 이용해서 시간이 오래 걸릴 거라 생각했지만 중첩이 아니기 때문에 3n 일 뿐이다 - 두 개의 루프가 하나의 중첩 루프보다 효율적이다

위의 same2는 O(3n)이지만 빅오 표기법은 O(n)로 표현한다.

3. 시간 복잡도 VS 공간 복잡도

위의 빅오 표기법은 시간 복잡도에 대한 표현이었다.
방법 1과 2의 공간 복잡도를 보면 각각 O(1), O(n)이다.

그래서 생기는 궁금증은

same은 O(1) 공간복잡도이고, O(n^2) 시간 복잡도이고,
same2는 O(n) 공간복잡도이고, O(n) 시간 복잡도이다

그러면 뭐가 더 효율적일까?

이런 문제는 로직을 사용하는 자원(시간, 공간)에 따라 달라지는 문제이다.

이거여서 좋다, 저거여서 좋다 보다는 처리를 빨리해서 값을 보여줘야 하는 경우에는 시간 복잡도가 더 효율적인 로직을 이용해야 하고, 한정되어 있는 메모리를 이용해야 하는 경우에는 공간 복잡도가 효율적인 것이 필요하다.

그래서 상황을 잘 고려한 로직이 필요할 것 같다.

개발자 공부순서 - 로드맵

백씨네 — Wed, 30 Aug 2023 00:23:25 +0900

독학 또는 추가적인 학습을 위한 로드맵 - https://roadmap.sh/

Developer Roadmaps - roadmap.sh

Community driven roadmaps, articles and guides for developers to grow in their career.

roadmap.sh

요즘은 이것저것 개념 공부, 적용해 보는 과정이고.. 추후에 어떻게 공부할지 찾아보다가 찾은 사이트..!

여러 포지션의 개발자가 어떤 순서대로 공부를 해야 할지 모른다면 위의 링크를 이용해서 필요한 것, 중요한 것을 파악하고 공부의 순서를 정하면 좋을 것 같다.

좌측은 포지션에 따른 로드맵이고 우측은 스킬에 대한 로드맵으로 되어있다.

블록체인 개발자 로드맵

블록체인 개발자를 생각한다면 위의 로드맵 순서대로 진행할 수 있겠다. 꼭 이 순서대로 진행해야 하는 것은 아니겠지만 기본적인 순서를 생각하기엔 좋은 사이트인 것 같다.

JS에 대한 로드맵

각 포지션에 대한 로드맵뿐 아니라 스킬의 로드맵도 있는데 그중 JavaScript에 대한 내용이다.

이를 이용해서 어떤 개념을 순서대로 익혀야 할지 감도 잡히는 것 같다. 또 이걸 이용해서 개발자 면접 준비하는 것도 좋지 않을까 싶다.

좋은 점은 각 개념에 대해서 간단한 설명과 참고할 사이트도 있어서.... 너무 좋...다..!

230823 - 알고리즘 적용하는 위치에 따른 방법 3가지 (SHA-256)

백씨네 — Thu, 24 Aug 2023 00:04:12 +0900

오늘 내가 배운 것

1. Node.js 환경

2. 브라우저 환경

3. crypto-js 라이브러리

4. Node.js VS 브라우저 VS 라이브러리 비교

블록체인을 하면서 해시 알고리즘을 이용하는 경우가 많이 있다. 그래서 오늘은 여러 암호화하는 방법 중 해시 알고리즘을 적용하는 위치에 따른 방법을 찾아봤다.

결론부터 말하자면 3가지가 있다.

Node.js 환경에서 내장 모듈
브라우저 환경에서 API 사용
라이브러리 (Node 환경, 브라우저 환경)

암호화를 위한 여러 알고리즘, 방식이 있지만 SHA-256을 이용하여 해시 값을 얻는 예시로 진행하려 한다.

SHA-256 : 256비트의 해시 값을 생성하는 암호화 해시 함수, 해싱 알고리즘으로 한번 해싱된 데이터는 원래 데이터로 되돌릴 수 없다.

해싱된 데이터가 맞는지 확인하는 방법은 새로 입력받은 데이터를 해싱한 후 같은 기존에 저장하고 있는 데이터와 비교하여 입력받은 데이터와 저장 데이터가 서로 같은지 확인한다.

1. Node.js 환경

Node.js환경에서는 ‘crypto’ 내장 모듈을 이용해서 SHA-256 해시를 생성할 수 있다.

const crypto = require("crypto");

const sha256 = (data) => {
    const hash = crypto.createHash('sha256');
    hash.update(data);
    return hash.digest('hex');
}

const myData = 'baekspace';
const myHash = sha256(myData);

console.log(myHash);

2. 브라우저 환경

브라우저에서는 ‘subtleCrypto’ API를 이용하여 SHA-256 해시를 생성할 수 있다. - crypto.subtle.digest()

const sha256 = async (data) => {
    const msgUint8 = new TextEncoder().encode(data) 
    const hashBuffer = await crypto.subtle.digest("SHA-256", msgUint8)
    const hashArray = Array.from(new Uint8Array(hashBuffer)) 
    const hashHex = hashArray.map((b) => b.toString(16).padStart(2, "0")).join("") 
    return hashHex
}

const myData = 'baekspace';
sha256(myData).then(hash => console.log(hash))

처음 입력받은 값을 msgUint8 변수로 변환하는 이유는 문자열을 바이트 배열로 변환하여 해싱 알고리즘이 처리할 수 있는 형태로 변경시키기 위한 과정이다.

이후 해시화를 한 후 다시 uint8Array로 변환한 다음 문자열로 변경해 주는 과정을 거친다.

3. crypto-js 라이브러리

서버, 브라우저 모두에서 사용할 수 있는 라이브러리를 이용한 방식이다.

const CryptoJS = require("crypto-js");

const myData = 'baekspace';
const myHash = CryptoJS.SHA256(myData).toString(CryptoJS.enc.Hex);

console.log(myHash);

4. Node.js VS 브라우저 VS 라이브러리 비교

당연히 세 가지 모두 같은 결과를 보여준다.

각 특징을 살펴보면

Node.js의 ‘crypto’ 모듈: Node.js의 내장 모듈이므로 추가적인 라이브러리 설치 없이 사용할 수 있으며, 성능도 최적화되어 있을 가능성이 높다. 서버 측에서 사용하는 경우에 적합
브라우저의 ‘subtleCrypto’ API: 브라우저가 지원하는 웹 암호화 API로, 클라이언트 측에서 안전하게 암호화 작업을 하고 싶을 때 사용할 수 있다. 브라우저에 최적화되어 있고, 웹 보안 관점에서 권장되는 방식
‘crypto-js’ 라이브러리: 클라이언트와 서버 모두에서 사용할 수 있는 라이브러리이다. 사용하기 쉽고 다양한 암호화 옵션이 있지만 외부 라이브러리이므로 성능과 크기 측면에서 다른 방식보다 미세하게 떨어질 수 있다.

원래 알고 있던 방법은 Node.js 환경, 라이브러리를 이용해서 해싱하는 것이었는데, 이번에는 서버단까지 데이터를 str형태로 끌고 가서 변환하고 싶지 않았고, 블록체인 특성상 프론트에서 처리하는 방식이 옳다고 생각했기 때문에 브라우저에서 해싱하는 방법을 찾았던 것이다.

즉, 암호화 또는 해싱이 필요한 위치를 고려해서 사용해야 한다는 것이다.

230821 - 빅오 표기법 ( Big O natation)

백씨네 — Tue, 22 Aug 2023 01:34:43 +0900

오늘 내가 배운 것

1. 빅오 표기법이란?

2. 표기방법

3. 잘못된 표기방법

4. 복잡도 알고리즘 비교

5. 시간 복잡도와 공간 복잡도의 상호 관계

1. 빅오 표기법이란?

빅오 표기법(Big O notation)은 알고리즘의 효율성을 설명할 때 주로 사용되는 수학적 표기법이다. 이 표기법은 입력 크기가 커짐에 따라 어떻게 알고리즘이 수행되는지, 얼마나 많은 리소스(시간, 메모리 등)가 필요하는지를 설명하는 데 사용된다.

빅오 표기법을 이용해서 시간 복잡도, 공간 복잡도에 따라 표기를 할 수 있다.

시간 복잡도 : 알고리즘이 실행되는데 필요한 단계의 수나 계산 시간을 표현한다.

공간 복잡도 : 알고리즘이 실행되는 동안 필요한 메모리 양을 나타낸다.

2. 표기 방법

O(1) : 상수 시간/공간 복잡도 : 입력 크기와 관계없이 일정한 시간/공간이 소요된다.
- 예) 단순 연산, 배열의 특정 인덱스 접근
O(log n) : 로그 시간/공간 복잡도 : 로그배만큼 시간/공간이 소요된다.
- 예) 이진 탐색
O(n) : 선형 시간/공간 복잡도 : 입력 크기에 비례하여 시간/공간이 소요된다.
- 예) 단순 탐색, 동적 배열, for문
O(n log n) : 선형 로그 시간/공간 복잡도 : 입력 크기와 로그배만큼 시간/공간이 소요된다.
- 예) 병합정렬, 퀵 정렬
O(n^2) : 제곱 시간/공간 복잡도 : 입력 크기의 제곱에 비례하는 시간/공간이 소요된다.
- 예) 버블 정렬, 이중 for문
O(2^n) : 지수 시간/공간 복잡도 : 입력 크기에 대해 지수적으로 시간/공간이 소요된다.
- 예) 피보나치수열, 재귀

3. 잘못된 표기방법

상수항, 영향력이 없는 항들은 무시한다.

O(2n) → O(n)
O(500) → O(1)
O(13n^2) → O(n2)
O(2n+100) → O(n)
O(100n+10) → O(n)
O(n^2+100n) → O(n^2)
O(100n^2+100) → O(n^2)

4. 복잡도 알고리즘 비교

O(1) > O(log n) > O(n) > O(n log n) > O(n^2) > O(2^n)

상수 > 로그 > 선형 > 선형 로그 > 제곱 > 지수 순으로 효율적이라고 할 수 있다.

상수가 가장 빠르고 효율적이며, 지수 복잡도로 갈수록 입력크기가 커지면 느려지기 때문에 피하는 것이 좋다.

5. 시간 복잡도와 공간 복잡도의 상호 관계

시간 복잡도와 공간 복잡도는 서로 상호 관계가 있을 수 있다.

예를 들어, 메모리(공간)를 더 사용하게 되면 연산을 줄일 수 있고, 반대로 시간을 더 사용하면 메모리를 절약할 수 있다. 대표적으로 캐싱이 있다.

캐싱 : 연산 결과를 저장하여 나중에 같은 계산을 할 때 값을 빠르게 얻을 수 있지만 값을 저장할 메모리가 필요하다.

출처 : https://www.udemy.com/course/best-javascript-data-structures/

230817 - GETH를 이용한 Ethereum private network 구축하기(POA)

백씨네 — Thu, 17 Aug 2023 20:49:05 +0900

Private Network

1. geth 설치하기

macOS 설치 방법

#brew 설치 확인하기
$ brew -v
$ brew tap ethereum/ethereum
$ brew install ethereum

# ethereum 업데이트하기
$ brew update
$ brew upgrade
$ brew reinstall ethereum

공식문서 : https://geth.ethereum.org/docs/getting-started/installing-geth

Installing Geth | go-ethereum

Guide to installing Geth

geth.ethereum.org

2. genesis.json 생성하기

{
    "config": {
        "chainId": 119, // 원하는 chainId를 지정한다.
        "homesteadBlock": 0,
        "eip150Block": 0,
        "eip155Block": 0,
        "eip158Block": 0,
        "byzantiumBlock": 0,
        "constantinopleBlock": 0,
        "petersburgBlock": 0,
        "istanbulBlock": 0,
        "berlinBlock": 0,
        "clique": {
            "period": 5, //블록생성 주기
            "epoch": 30000 // 블록을 그룹화하는 단위 30000개 블록마다 스냅샷을 생성한다.
        } // POA 합의 알고리즘 사용을 위해서 clique 속성을 이용한다.
    },
    "difficulty": "1",
    "gasLimit": "8000000",
    "extradata": "0x0000000000000000000000000000000000000000000000000000000000000000a22061Eb8c9702Cfac2d9d8ce6dfF9A195d05e810000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", // extradata를 이용해서 초기 참여자를 지정할 수 있다.
    "alloc": {
        "a22061Eb8c9702Cfac2d9d8ce6dfF9A195d05e81": { "balance": "100000000000000000000" },
        "12ec9720a6Cc8e48aD745eadeB49f2C38eC5Ef59": { "balance": "400000" },
        "13169CD3EA4041A546F7c70906fFFAa26D939b87": { "balance": "100000000000000000000" }
    } // 노드를 실행할 때 최초에 넣어줄 잔액이다. wei단위로 1eth = 10^18 wei이다.
}

genesis.json에서 계정을 작성할 때는 '0x'를 제외하고 작성한다.
extradata에는 0의 개수 그대로 유지해서 작성해야 한다. 위의 예시에서는 a22~e81까지가 하나의 계정이다.

3. Keystore

geth account new --datadir $PWD

명령어를 실행하면 비밀번호를 생성하라는 문구가 나온다.

'Your new account is locked with a password. Please give a password. Do not forget this password.'

해당 비밀번호는 생성한 key를 unlock 할 때 사용한다.
계정이 잠금상태일 때는 트랜잭션에 서명을 할 수 없지만 비밀번호를 통해서 unlock을 한 후 트랜잭션 서명에 사용할 수 있다.

키는 여러 개를 사용할 수 있으며, 노드를 실행할 때 언락을 할 계정을 지정한다.

--unlock '0xKEY1,0xKEY2...'

key 생성

4. 비밀번호를 txt 파일로 만들기

노드를 실행할 때 unlock 플래그를 이용해서 키를 잠금 해제하고 노드에서 사용하게 되는데 이를 쉽게 하기 위해서 txt파일로 지정해서 사용할 수 있게 한다.

Key가 여러 개인 경우에는 줄 바꿈을 통해서 각 키에 대한 비밀번호를 적어주면 된다.

줄바꿈을 이용해서 여러개의 비밀번호 지정하기

5. 제네시스 파일로 초기화

# 생성한 제네시스 블록을 이용해서 초기화하기
$ geth init --datadir $PWD genesis.json

위의 명령어를 이용해서 커스텀한 제네시스 블록으로 초기화할 수 있다.

6. 노드 실행 및 피어 맺기

노드를 실행하기 위해서 여러 명령어, 플래그를 이용한다.
명령어에 대한 자세한 설명은 'geth -h'를 이용하여 확인할 수 있다.
각 노드의 port는 겹치지 않도록 지정을 해야 한다.

node 1

geth \
--authrpc.addr 127.0.0.1 \
--authrpc.port 8551 \
--datadir $PWD \
--syncmode 'full' \
--allow-insecure-unlock \
--networkid 119 \
--maxpeers 5 \
--http \
--http.port 8545 \
--http.addr "0.0.0.0" \
--http.corsdomain "\*" \
--http.api "admin,eth,debug,miner,net,txpool,personal,web3" \
--ws \
--ws.port 3335 \
--ws.api eth,net,web3 \
--port 30303 \
--nodiscover \
--unlock '0xa22061eb8c9702cfac2d9d8ce6dff9a195d05e81' \
--password $PWD/password.txt \
--miner.etherbase "0xa22061eb8c9702cfac2d9d8ce6dff9a195d05e81" \
console

node 2

geth \
--authrpc.addr 127.0.0.1 \
--authrpc.port 8552 \
--datadir $PWD \
--syncmode 'full' \
--allow-insecure-unlock \
--networkid 119 \
--maxpeers 5 \
--http \
--http.port 8546 \
--http.addr "0.0.0.0" \
--http.corsdomain "\*" \
--http.api "admin,eth,debug,miner,net,txpool,personal,web3" \
--ws \
--ws.port 3334 \
--ws.api eth,net,web3 \
--port 30304 \
--unlock '0x13169CD3EA4041A546F7c70906fFFAa26D939b87' \
--bootnodes "enode://2549091a058dc0f3312654556bca621a84226b6e45270b838572b68ebdb1a7e8d9438ea9575dac31a8859b83b453a177eb58ac50a2940bab7a53bea69688ef56@127.0.0.1:30303" \
--password $PWD/password.txt \
console

두 노드를 실행할 때 명령어의 차이점이 있는데 --miner.etherbase, --nodiscover, --bootnodes 각각이 있거나 없을 수 있다.
(위의 모든 명령어는 필요한 것을 사용하면 된다.)

--miner.etherbase : 채굴 시 보상을 위해서 계정을 지정하는 것인데, POA에서는 채굴에 대한 보상이 없기 때문에 실질적으로 리워드가 주어지진 않지만, 계정을 지정해 주어야 마이닝을 실행할 수 있다.
- 노드 실행 후 콘솔에서 miner.setEtherbase("0x를 포함한 계정")을 이용해서 설정 가능하다.
--nodiscover : 노드가 다른 노드를 자동으로 찾지 못하게 한다. 특정 피어와만 연결하려면 이 옵션을 사용하고 --bootnodes 옵션으로 연결하려는 피어를 지정한다.
--bootnodes : 노드가 다른 노드와 연결할 때 사용한다. 실행 중인 'enode' URL을 지정해주어야 한다.
- 노드 실행 후 콘솔에서 admin.addPeer("enode URL")을 이용해서 설정 가능하다.

이렇게 해서 노드를 실행하고 피어를 맺을 수 있다. console 명령어를 이용해서 JS console을 열었고 지정했던 api를 사용할 수 있다.

위 : enode 아래 : 잠금 해제된 key

7. 블록생성하기

제네시스 블록으로 참여자를 1번 노드의 계정만 했기 때문에 해당 블록만 mining을 진행할 수 있다.
그러므로 1번 노드에서 miner.start()를 이용해서 블록을 생성할 수 있다.

위에서 --miner.etherbase 명령어를 안 쓰게 되면 Etherbase 관련 에러가 발생한다.
Etherbase 관련 에러가 발생하면 miner.setEtherbase("0x를 포함한 계정")를 이용해서 지정해 주고 miner.start 할 수 있다.

최초에 실행할 때 참여자를 1명만 지정했기 때문에 혼자서 mining이 가능하지만 2~3명 이상이 되면
Block sealing failed, err="signed recently, must wait for others" 에러가 발생한다.

참여자가 여럿일 때 혼자서 계속 블록을 생성할 수 있는 것이 아닌 다른 참여자도 miner.start를 지정해주어야 한다.
모두 마이닝을 시작하게 되면 2개 이상의 노드에서 번갈아가며 블록을 생성한다.

230814 - Electron 구조

백씨네 — Mon, 14 Aug 2023 16:18:41 +0900

오늘 내가 배운 것

1. Main Process

2. Renderer Process

3. Main-Renderer 통신

일렉트론 구조

일렉트론은 크게 2가지의 프로세스를 가지고 있다.

Main Process와 Renderer Process이다.

1. Main Process

메인 프로세스는 package.json의 main으로 지정해두었던 main 스크립트를 실행하는 프로세스를 말한다. 메인프로세스에서 실행되는 스크립트는 웹페이지를 GUI로 표시한다. Electron 앱은 항상 하나의 메인 프로세스만을 가진다.

Main Process의 기능 및 역할

애플리케이션의 생명 주기 관리
- 애플리케이션의 시작부터 종료까지 전체 생명 주기를 제어하고 필요한 로직을 처리한다.
브라우저 윈도우 생성
- ‘BrowserWindow’객체를 이용하여 브라우저 창을 생성하고 웹 페이지를 로드하여, GUI로 보여준다.
네이티브 기능 접근
- 메인 프로세스는 운영 체제의 파일 시스템, 네트워크, 하드웨어 등의 네이티브 자원에 직접 접근할 수 있다.
렌더러 프로세스와의 통신
- 메인프로세스는 렌더러 프로세스와 IPC를 통해 통신한다.이를 이용해서 네이티브 기능과 웹페이지 간의 상호작용을 지원한다.

2. Renderer Process

렌더러 프로세스는 웹 페이지의 렌더링과 관련된 모든 작업을 처리하며 Chromium을 사용해서 웹페이지를 보여준다. 크로미움을 사용하기 때문에 크로미움의 멀티 프로세스, 아키텍쳐를 사용한다. 각각의 Electron 웹페이지는 자체 프로세스로 동작한다.

Renderer Process 기능 및 역할

웹 페이지 렌더링
- 렌더러 프로세스는 Chrominum의 웹 렌더링 엔진을 사용하여 웹 페이지를 렌더링한다. 웹 페이지는 HTML/CSS, JS같은 웹 기술을 이용해서 UI를 구성할 수 있다.
각 창마다 독립적인 프로세스
- Electron에서 각 브라우저 윈도우는 독립된 렌더러 프로세스를 가진다. 그래서 하나의 윈도우에서 오류가 발생하더라도 다른 윈도우에는 영향을 미치지 않는다.
DOM과 JS API 접근
- 렌더러 프로세스는 웹 브라우저와 같이 DOM을 직접 조작하고 JS API를 사용할 수 있다.
메인 프로세스와의 통신
- 렌더러 프로세스는 메인 프로세스와 IPC를 통해 통신할 수 있으며, 이를 이용해서 네이티브 자원에 접근하거나 다른 렌더러 프로세스와 상호 작용할 수 있다.
보안
- 렌더러 프로세스는 직접 네이티브 자원에 접근할 수 없고 메인 프로세스를 통해 요청해야 하기 때문에 악의적인 코드의 실행을 제한할 수 있다.

3. Main-Renderer 통신

메인프로세스와 렌더러 프로세스가 서로 통신하는 방법으로 remote 모듈과 IPC 모듈을 이용할 수 있다.

remote 모듈

메인 프로세스에서만 사용가능한 API들을 렌더러 프로세스에서 이용할 수 있게 해주는 모듈이다.

IPC 모듈

ipcMain
- main 프로세스에서 renderer 프로세스로 비동기 통신을 한다.
ipcRenderer
- renderer 프로세스에서 main 프로세스로 비동기 통신을 한다.
IPC 모듈을 이용하여 메세지 주고 받기

모듈 import

//main Process
const { ipcMain } = require("electron")

//renderer Process
const { ipcRenderer } = require("electron")

main Process

// 이벤트 수신을 위한 등록
ipcMain.on("eventName", (event, args) =>{
	//코드 작성
	event.reply("responseEventName", responseArgs)
})

renderer Process

//main 프로세스로 메세지 전송 
ipcRenderer.send("eventName", args)

//응답 대기
ipcRenderer.on("responseEventName", (event, args)=>{
	//응답 처리
})

통신을 이용하여 할 수 있는 기능

창 관리 : 렌더러 프로세스에서 사용자의 액션에 따라서 새 창을 열고 기존 창을 닫는 창 관리 작업을 할 수 있다.
네이티브 자원 조작 : 메인 프로세스는 OS 수준의 네이티브 자원에 접근할 수 있어서 렌더러 프로세스에서 메인 프로세스로 요청을 보내 파일 시스템 작업, 네트워크 통신, 하드웨어 정보 수집 등을 할 수 있다.
상태 공유 : 여러 렌더러 프로세스간에 상태를 공유해야할 때, 메인 프로세스를 중앙 상태 저장소로 이용하여 데이터를 공유할 수 있다.
보안 제어 : 일부 보안에 민감한 작업은 메인 프로세스에서만 동작이 가능하고 이러한 작업을 렌더러 프로세스에서는 요청하고 응답 받을 수 있다.
네이티브 메뉴 및 알림 : 렌더러 프로세스에서 특정 이벤트 발생 시, 메인 프로세스에 알림을 보내 네이티브 메뉴를 변경하거나 시스템 알림을 표시할 수 있다.
외부 프로세스 관리 : 렌더러 프로세스에서 요청을 통해 메인프로세스가 외부 프로세스를 시작하고 제어할 수 있도록 한다.
사용자 설정 관리 : 사용자 설정을 메인 프로세스에서 관리하고, 렌더러 프로세스가 해당 설정을 읽고 변경할 수 있도록 설정 가능하다.
플러그인 또는 확장 기능 : 렌더러 프로세스에서 발생하는 특정 이벤트에 대한 응답으로 메인 프로세스에서 추가 기능을 수행하도록 하여 플러그인, 또는 확장 기능을 구현할 수 있다.

메인 프로세스와 렌더러 프로세스 간의 통신은 Electron 애플리케이션의 복잡한 작업을 가능하게 하고, 사용자 인터페이스와 백엔드 로직간의 상호작용을 지원한다.

CSS를 이용해서 Element를 숨기는 방법

백씨네 — Fri, 11 Aug 2023 18:54:05 +0900

Element 숨기기

Element를 숨기는 방법은 여러 방법이 있지만 그중에서 비용이 적게 들고 쉽게 할 수 있는 방법으로 CSS를 이용하는 방법이 있다.

기본적인 형태는 아래와 같다.

See the Pen Untitled by JJJ (@JJJ-the-animator) on CodePen.

여기서 2번을 숨길 것이다.

CSS를 이용해서 Element를 숨기는 대표적인 방법 3가지는 아래와 같다.

1. display 속성

display : none 을 이용한다.

See the Pen Untitled by JJJ (@JJJ-the-animator) on CodePen.

2. visibility 속성

visibility : hidden 을 이용한다. ( 2번 자리에 마우스를 올려보세요. )

See the Pen Untitled by JJJ (@JJJ-the-animator) on CodePen.

3. opacity 속성

opacity: 0 을 이용한다. ( 2번 자리에 마우스를 올려보세요. )

See the Pen Untitled by JJJ (@JJJ-the-animator) on CodePen.

hidden을 제외한 아무것도 설정하지 않았다.

예시를 보면 특징이 보이는데, 각 속성을 이용했을 때의 특징은 아래와 같다.

1. display 속성

웹 페이지에서 요소를 아예 제거한다. 그래서 해당 요소가 차지하는 공간도 없어지므로 옆에 있던 3번이 1번 옆으로 붙게 된다.

2. visibility 속성

웹 페이지에서 요소가 제거되는 것은 아니지만 보이지 않는다. 마우스 이벤트가 작동하지 않는다.

3. opacity 속성

웹 페이지에서 요소가 제거되는 것은 아니지만 보이지 않는다. 2번 visibility와 비슷하지만 투명도만 0이 된 것이기 때문에 마우스 이벤트가 적용이 된다.

230811 - Electron.js 기초

백씨네 — Fri, 11 Aug 2023 18:08:37 +0900

오늘 내가 배운 것

1. Eletron.js

2. 사용하기

Electron.js

일렉트론은 일반적인 웹 기술을 이용하여 데스크톱 애플리케이션을 만들기 위한 프레임워크이다.

JS, HTML/CSS를 이용하여 크로스 플랫폼 데스크톱 애플리케이션을 개발할 수 있다.

Electron은 Chrominum 웹 브라우저와 Node.js 런타임을 결합하여 사용하는 것이다.

크로스 플랫폼

크로스 플랫폼은 하나의 코드를 이용하여 여러 OS 환경, 디바이스에서 실행될 수 있게 하는 것이다.

이전에 React-Native를 이용해서 하나의 코드로 IOS, Android 환경에서 사용하는 애플리케이션을 빌드를 했던 것처럼 Electron도 하나의 코드를 이용해서 MacOS, Window, Linux OS에서 사용할 수 있는 애플리케이션을 만드는 것이다.

웹 기반

Electron은 웹을 기반으로 되어있기 때문에 웹페이지를 만들어 보았던 개발자가 쉽게 할 수 있다.

네이티브 기능

Node.js 런타임을 내장하고 있기 때문에 시스템 리소스에 접근이 가능하여 기본적인 OS 네이티브 기능을 활용할 수 있다.

대표적인 애플리케이션

Visual Studio Code
Slack
Discode

등이 있다.

사용하기

사용하기 전에 Node가 설치되어 있어야 한다.

Node가 설치되어 있다면 아래를 진행하면 된다.

1. 기본 설치

# electron-app 디렉토리 만들기
npx create-react-app electron-app

CRA를 진행한다. electron-app이라는 디렉토리를 생성하였다.

이후 electron-app으로 진입한다.

cd electron-app

electron을 설치한다.

npm install -save-dev electron

2. package.json 설정

scripts와 main을 지정해주어야 한다.

"scripts": {
        "start": "react-scripts start",
        "build": "react-scripts build",
        "test": "react-scripts test",
        "eject": "react-scripts eject",
        "electron": "electron ." 
    },

“electron . “ 명령어를 이용해서 개발 모드에서 앱을 열 수 있다.

‘npm run electron‘으로 electron . 명령어를 사용하기 위해서 scripts에 지정을 해둔다.

그리고 main을 지정해야 한다.

“main”은 electron 애플리케이션의 entry point이다.

작성한 코드가 일렉트론 앱에서 실행될 때 entery point인 main.js를 이용해서 열리고 main.js에 앱에 열릴 내용을 지정해 준다고 생각하면 된다. 기본적인 앱의 설정 내용들은 여기서 지정한다.

"main": "src/main.js"

최종적으로 작성되는 package.json은 아래와 같다.

{
    "name": "react-electron",
    "version": "0.1.0",
    "private": true,
    "main": "src/main.js", // 추가
    "dependencies": {
        "@testing-library/jest-dom": "^5.17.0",
        "@testing-library/react": "^13.4.0",
        "@testing-library/user-event": "^13.5.0",
        "react": "^18.2.0",
        "react-dom": "^18.2.0",
        "react-scripts": "5.0.1",
        "web-vitals": "^2.1.4"
    },
    "scripts": {
        "start": "react-scripts start",
        "build": "react-scripts build",
        "test": "react-scripts test",
        "eject": "react-scripts eject",
        "electron": "electron ." // 추가
    },
    "eslintConfig": {
        "extends": [
            "react-app",
            "react-app/jest"
        ]
    },
    "browserslist": {
        "production": [
            ">0.2%",
            "not dead",
            "not op_mini all"
        ],
        "development": [
            "last 1 chrome version",
            "last 1 firefox version",
            "last 1 safari version"
        ]
    }
}

3. src/main.js

src 디렉토리 안에 main.js를 추가하여 앱의 기본 설정 및 앱을 열었을 때 바라보게 되는 파일이나 주소를 지정해 줄 수 있다.

아래는 electron의 공식문서에서 가져온 내용이다.

// main.js

// Modules to control application life and create native browser window
const { app, BrowserWindow } = require('electron')
const path = require('path')

const createWindow = () => {
  // Create the browser window.
  const mainWindow = new BrowserWindow({
    width: 800,
    height: 600,
    webPreferences: {
      preload: path.join(__dirname, 'preload.js')
    }
  })

  // and load the index.html of the app.
  mainWindow.loadFile('index.html')

  // Open the DevTools.
  // mainWindow.webContents.openDevTools()
}

// This method will be called when Electron has finished
// initialization and is ready to create browser windows.
// Some APIs can only be used after this event occurs.
app.whenReady().then(() => {
  createWindow()

  app.on('activate', () => {
    // On macOS it's common to re-create a window in the app when the
    // dock icon is clicked and there are no other windows open.
    if (BrowserWindow.getAllWindows().length === 0) createWindow()
  })
})

// Quit when all windows are closed, except on macOS. There, it's common
// for applications and their menu bar to stay active until the user quits
// explicitly with Cmd + Q.
app.on('window-all-closed', () => {
  if (process.platform !== 'darwin') app.quit()
})

// In this file you can include the rest of your app's specific main process
// code. You can also put them in separate files and require them here.

mainWindow.loadFile(”index.html”)에 의해서 index.html 파일을 읽는다는 것을 확인할 수 있다.

이를 이용해서 배포된 주소로 앱을 만들 수 있다.

// index.html 파일 열기
mainWindow.loadFile("index.html") 

//https://example.com 웹사이트를 앱으로 만들 수 있다.
mainWindow.loadURL("https://example.com")

4. 실행하기

main.js와 loadURL을 지정한 후에 지정해 두었던 scripts를 이용해서 app을 볼 수 있다. ( 빌드되어 파일로 나오는 것이 아니라 확인하는 것이다. 실제 설치 파일로 추출하기 위해선 추가적인 작업이 필요하다.)

npm run electron

일반적인 web으로는 주소창 등 브라우저의 기본적인 것이 보이지만 electron으로는 브라우저의 기능을 제외하고 내용만 확인이 가능하다.

230728 - Hardhat

백씨네 — Fri, 28 Jul 2023 13:59:35 +0900

오늘 내가 배운 것

1. Hardhat

Hardhat이란?

하드햇이란 트리플과 비슷한 역할을 하는 Ethereum smartcontract를 개발, 컴파일, 테스트, 디버깅을 하기 위한 도구이자 프레임워크이다.

1. 설치

# hardhat 기본설치
$ npm init
$ npm install --save-dev hardhat

2. 사용하기

$ npx hardhat

npx를 이용하여 프로젝트를 생성할 수 있다.

JS뿐 아니라 TS에 대한 기본적인 설정이 되어 있는 프로젝트를 생성할 수 있다.

설치가 완료되면 아래와 같은 디렉토리가 생긴다.

3. 명령어 확인하기

설치가 완료된 후

$ npx hardhat

명령어를 다시 사용하게 되면 하드햇에서 제공하는 명령어나 옵션을 확인할 수 있다.

사진!!!!!

총 13가지의 명령어가 있고 각 명령어는 아래와 같이 사용한다.

# 초기화
$ npx hardhat clean
$ npx hardhat [명령어]

4. 각 명령어의 역할

check : 사용자 정의 확인 작업을 수행한다. hardhat.config 파일에 지정되어 있는 로직을 이용해서 검사할 수 있다.
clean : Hardhat의 캐시를 지우고 모든 컴파일된 스마트 컨트랙트를 삭제한다. 프로젝트를 깨끗한 상태로 재설정하는 데 사용한다.
compile : 프로젝트의 모든 스마트 컨트랙트를 컴파일한다. 컴파일 과정에서는 스마트 컨트랙트의 소스코드를 EVM 바이트코드로 변환한다.
console : Hardhat의 콘솔을 연다. 스마트 컨트랙트와 직접 상호 작용할 수 있다.
coverage: 테스트에 대한 코드 커버리지 보고서를 생성한다. 어떤 코드가 테스트 코드에 포함되었는지, 누락되었는지 확인할 수 있다.
flatten: 스마트 컨트랙트와 그 종속성을 평면화하여 출력한다. 여러 소스 파일에 걸쳐 분산된 스마트 컨트랙트를 단일 파일 합치는 과정이 있다.
gas-reporter:merge : 트랜잭션의 가스사용량을 추적하고 보고하는 도구이다. merge를 통해서 여러 가스보고서를 병합한다.
help : 도움말을 출력해 준다. 특정 명령어에 대한 도움말은 "npx hardhat help [명령어]"를 이용한다.
node: Hardhat Network위에 JSON-RPC 서버를 시작한다. 이를 이용해서 로컬에서 블록체인 시뮬레이션을 실행할 수 있다.
run : 프로젝트를 컴파일한 후 사용자 정의 스크립트를 실행한다.
test : test 디렉토리에 지정되어 있는 파일을 이용하여 Mocha테스트를 진행한다.
typechain : 컴파일된 스마트 컨트랙트에 대한 Typechain 타이핑을 생성한다. TypeScript에서 타입 안전성을 확보할 수 있다.
verify : Etherscan에서 컨트랙트를 점증한다. 컨트랙트가 소스코드와 일치하는지 확인하는 과정이다.

5. 각 옵션의 역할

--config : 사용할 Hardhat config 파일을 지정한다. Default로 현재 작업 디렉토리의 hardhat.config를 이용한다.
--emoji : hardhat 로그메시지에서 이모티콘을 사용하도록 설정한다.
--flamegraph : hardhat작업의 CPU 프로필을 수집하고, 그 결과를 flamegraph 형태로 출력한다.
--help : 도움말 메시지를 보여준다.
--max-memory : hardhat이 사용할 수 있는 최대 메모리 양을 MB eksdnlfh tjfwjdgksek.
--network : 이 옵션은 연결할 Ethereum 네트워크를 설정한다. config 파일에 정의된 네트워크를 이용해야 한다.
--show-stack-traces : 에러가 발생했을 때 스택 추적을 보여주도록 설정한다.
--tsconfig: 사용할 TypeScript config를 지정한다.
--typecheck : script, test의 TS 타입 검사를 활성화한다.
--verbose : Hardhat의 상세 로그를 활성화한다.
--version : 현재 사용 중인 hardhat의 버전을 출력한다.

6. Hardhat 네트워크 지정하기

// hardhat.config.ts

import { HardhatUserConfig } from "hardhat/config"
import "@nomicfoundation/hardhat-toolbox"

const config: HardhatUserConfig = {
    solidity: "0.8.18",
    networks: {
        ganache: {
            url: "http://127.0.0.1:8545", // Ganache URL
            chainId: 1337,
            accounts: require("./accounts.json").privateKey,
        },
        arbitrum: {
            url: "", // arbitrum-goerli 네트워크 infura
            chainId: 421613,
            accounts: require("./accounts.json").privateKey,
        },
        goerli: {
            url: "", // ethereum-goerli 네트워크 infura
            chainId: 5,
            accounts: require("./accounts.json").privateKey,
        },
    },
}

export default config

hardhat network를 설정하기 위해서 위에 같이 config를 이용하여 네트워크를 관리할 수 있다.

7. Hardhat Scripts

Hardhat에 scripts 디렉토리의 scripts 파일을 이용하여 Ethereum 네트워크와 상호작용을 하거나 컨트렉트 배포와 같은 복잡한 작업을 자동화할 수 있다.

//scripts/deploy.ts

import { ethers } from "hardhat"

async function main() {
    const currentTimestampInSeconds = Math.round(Date.now() / 1000)
    const unlockTime = currentTimestampInSeconds + 60

    const lockedAmount = ethers.parseEther("0.001")

    const lock = await ethers.deployContract("Lock", [unlockTime], {
        value: lockedAmount,
    })

    await lock.waitForDeployment()

    console.log(
        `Lock with ${ethers.formatEther(lockedAmount)}ETH and unlock timestamp ${unlockTime} deployed to ${lock.target}`
    )
}

// We recommend this pattern to be able to use async/await everywhere
// and properly handle errors.
main().catch((error) => {
    console.error(error)
    process.exitCode = 1
})

기본 프로젝트 설치 시 예시로 있는 scripts 파일이다.
배포를 위한 추가적인 scripts를 작성하여 배포를 진행할 수 있다.

8. 배포하기

배포하기 위해서는 run 명령어가 필요하다.

$ npx hardhat run --network goerli scripts/[스크립트파일이름]

#예시
$ npx hardhat run --network goerli scripts/deploy.ts

이러한 과정을 통해서 hardhat을 이용하여 지정해 놓은 goerli 네트워크에 배포를 진행할 수 있게 된다.

BAEK'space

Claude Code for Front-end #5: 서브에이전트 실전 활용기

한국어 키워드로 각 분야 전문가를 호출하는 나만의 워크플로우

들어가며

1️⃣ Claude Code 에이전트 구조 이해하기

메인 에이전트와 서브에이전트의 관계

실제로는 어떻게 작동할까?

왜 이런 구조가 필요한가?

2️⃣ 서브에이전트의 종류 (공식 문서 기반)

내장 에이전트 (Built-in Agents)

서브에이전트 우선순위

3️⃣ 서브에이전트 생성 방법 (공식 문서)

방법 1: /agents 명령어 (권장)

방법 2: 수동 파일 생성

4️⃣ 제가 사용하는 에이전트 (개인 경험)

현재 설치된 에이전트

주로 사용하는 에이전트 예시

에이전트를 구하는 곳

5️⃣ 한국어 트리거 시스템 (제 워크플로우)

CLAUDE.md 설정 방식

작동 원리

명시적 호출 예시

6️⃣ 서브에이전트 활용 방향성

1. 단일 책임 원칙으로 나누기

2. 에이전트 체이닝 전략

3. 프로젝트별 특화 에이전트

7️⃣ 실전 팁과 트러블슈팅

Claude 생성 초안 활용

description 필드 상세히 작성

도구 권한 제한

성능 트레이드오프 인식

트러블슈팅: 에이전트가 호출되지 않을 때

트러블슈팅: 에이전트 목록이 안 보일 때

마무리

제 경험 요약

추천 시작 방법

Claude Code for Front-end #4: Claude Code를 200% 활용하는 법

AI와 대화하는 방법이 생산성을 결정한다

들어가며

프롬프트의 기본 구조

1️⃣ "분석해줘" vs "성능 병목 3개 찾아서 개선안까지 제시해줘"

❌ 애매한 요청

✅ 구체적인 요청

2️⃣ 컨텍스트는 AI의 연료입니다

❌ 컨텍스트 없는 요청

✅ 컨텍스트 충분한 요청

3️⃣ 단계별 실행 패턴

예시: 새 기능 구현 (즐겨찾기 기능)

4️⃣ "왜"를 물어보는 습관

5️⃣ 비교 요청 패턴

❌ 막연한 질문

✅ 비교 요청

6️⃣ 에러 해결 골든 템플릿

실전 예시

7️⃣ 리팩토링 요청의 기술

❌ 모호한 요청

✅ 명확한 목표

리팩토링 체크리스트

8️⃣ 점진적 개선 패턴

9️⃣ 학습 모드 활성화

협업 시뮬레이션 - 코드 리뷰 요청

실전 활용 가이드

템플릿 모음

금지어 목록

고급 프롬프트 기법

실전 꿀팁 3가지

프롬프트 품질 체크리스트

마무리: 프롬프트는 대화입니다

핵심 원칙

실천 가이드

Claude Code for Front-end #3: MCP 서버로 Claude Code 능력 확장하기

프로덕션 레벨 개발을 위한 7가지 필수 MCP 서버 활용법

1️⃣ 들어가며

2️⃣ MCP란 무엇인가?

기본 개념

아키텍처 구조

3️⃣ MCP 서버 설정 가이드

설정 파일 위치

기본 설정 구조

4️⃣ 실전 MCP 서버 7종 실전 가이드