// context7
// 최신 라이브러리 참고할 수 있도록 도움
claude mcp add --scope user --transport http context7 https://mcp.context7.com/mcp

// Sequential thinking mcp server
// 복잡한 문제해결을 단계별로 분석하고 추론할 수 있도록 도움
"sequential-thinking": {
  "command": "npx",
  "args": [
    "-y",
    "@modelcontextprotocol/server-sequential-thinking"
  ]
}

// shadcn/ui mcp
// 문서나 예제를 빠르게 가져오는데 도움

AI 작업 관리 도구

랜딩페이지나 투두리스트앱은 AI 를 활용하여 간단히 만들 수 있는데, 쇼핑몰과 같은 복잡한앱은 어떻게 체계적으로 관리하고 개발을 할 수 있을까? 핵심은 복잡한 프로젝트를 작은 작업들로 나눠서 순차적으로 완료

TASKMASTER AI

사용자와 AI 가 협력해서 체계적으로 개발 분석할까요? 이 작업은 복잡하니 나눌까요? 최신 기술스택을 조사할까요? 처럼 협력해서 진행 Main Model: 메인으로 사용할 AI Model Research Model: 최신 정보 검색이나 기술 동향 조사 Fallback Model: 메인 Model 실패 시 자동 전환되는 Model

// 실행 순서

// docs 폴더에 작성된 PRD 파싱
// 작업이 완료되면 tasks 폴더에 task 생성됨
task-master parse-prd

// 모든 task 목록 보기
// 여기서 복잡한 task 는 서브 task 들로 나눠주기
task-master list

// 현재 각 task 들에 대한 서브 task 들을 생성
task-master expand --all

// 서브 task 까지 보기
task-master list --with-subtasks

// Status 변경하여 취소하거나 스킵할거 수정작업

// 작업 시작
task-master next

Shrimp Task Manager

AI 가 개발자가 되어 주도적으로 개발 시니어 개발자 고용한 느낌 스스로 기술 스택 조사, 프로젝트 규칙 정하고, 작업 계획 세운 후에 구현까지

// 실행 순서

// shrimpt-task-manager 설치
git clone https://github.com/...
cd mcp-shrimp-task-manager
npm install
npm run build

// 프로젝트내에서 사용하기위한 mcp 세팅
args: 빌드로 생성된 파일을 사용하기위해 경로 뒷부분에는 /dist/index.js
DATA_DIR: 태스크 관리했던 다양한 데이터 저장

// 현재 프로젝트 구조 스캔
// 개발 표준과 규칙을 자동 설정
// 어떤 기술스택, 구조를 가져갈 지 초기화
init_project_rules

// 큰 요청을 단계별 실행 가능한 계획으로 나눠줌 
plan_task: [ROADMAP.md 에 생성된 task 제목]
@docs/ROADMAP.md

// 위 내용이 요청되면 태스크가 서브 태스크로 나눠질 수 있음

// 현재 생성된 task 들 확인
list_tasks

// 프로젝트 완성을 위해 하나씩 수행
execute_task

// 중간에 수정해야할 부분이 있다거나 추가할 부분이 있다면 
// plan task 로 생성하고 차례대로 다시 실행

// 어떠한 작업을 수행했고, 어떠한 작업이 남았는지 확인
list_tasks

// 연속 모드 사용하면 모든 작업 알아서 순차적 수행

// 모든 작업 완료한 후 클로드 init

개발 오류 줄이기

AI 에게 개발을 진행시킨 결과물의 오류 줄이는 방법

테스트 코드

비즈니스 로직이나 API 연동과 같은 코드를 구현한 다음에는 playwright mcp 를 활용해서 통합 테스트하는 프롬프트 추가

린트 및 타입 체크

스스로 검사 및 빌드

// CLAUDE.md

## 작업 관료 체크리스트
npm run check-all
npm run build

Claude Agent Skills

Claude 를 위한 업무 메뉴얼 ex)) 엑셀, PPT 가이드라인 제공하여 일관된 수준으로 높은 퀄리티의 결과물을 받을 수 있도록

기본적으로 Claude 에는 몇 가지 스킬이 내장되어있는데, 만약 요청으로 "PPT 제안서를 만들어줘" 라고 한다면, 자동으로 PPTX 스킬문서를 확인하여 전문가수준으로 만들어줌

스킬 폴더는 아래와 같이 구성되어 있음 지침서: 메뉴얼 참고자료: 추가 정보 스크립트: 실제 실행되는 코드 파일

이게 MCP, 서브 에이전트와 무슨 차이가 있을까?

★ MCP 와 서브 에이전트는 사용을 하든 안하든 Context 에 자리를 차지하고 있는 상태인데, 스킬은 차지하고 있는게 아닌 점진적으로 로드된다. 즉, 컨텍스트 공간을 효율적으로 사용

이게 가능한 이유는

1. 클로드가 처음 시작할 때 모든 skill.md 파일들을 훑어보면서 프론트매터 정보인 name, description 만 먼저 읽음 이렇다보니 적은 토큰으로도 많은 스킬 정보들을 파악할 수 있음
2. 실제로 해당 스킬을 사용해야할 때 로드됨 ( 이때 컨텍스트 메모리에 할당 )
3. 리소스 로드. skill.md 파일을 읽다가 참조 링크를 발견하면 필요한 순간에만 열어서 확인. 스크립트 코드의 경우 컨텍스트에 로드하지 않고 직접 실행 후 결과만 컨텍스트에 할당

★ 여러 스킬을 조합하여 함께 사용 가능 예를들어 워드문서에 데이터 차트를 넣어달라 요청하면 문서 스킬과 차트 생성 스킬을 조합하여 복잡한 작업을 완성

추가 2.1.0 : context: 프론트매터에 context 를 fork 로 설정하면 서브 에이전트처럼 컨텍스트를 별도로 지님 agent: context 가 fork 로 설정되어있을 때 사용할 에이전트 유형. Explore, Plan, general-purpose ... 별도의 컨텍스트를 지닌 상태에서 설정하는거보면 서브 에이전트 느낌? hooks: 해당 스킬 사용 트리거에 따라 특정 이벤트 실행 가능

대체해야할 작업 커스텀 커맨드 => skills 자주 사용하는 서브 에이전트 => skills 일회성 서브 에이전트 => sub agent mcp => mcp tool search

플러그인

매번 프로젝트 생성할때마다 이전 프로젝트의 서브에이전트, mcp, 훅, 커스텀커맨드, 스킬... 등을 복붙으로 가져오면 번거로움 플러그인으로 패키징하여 불러올 수 있음 또한, 전세계 사람들이 이미 구현해둔 패키징들을 마켓플레이스에서 가져올 수 있음

MCP Tool Search

MCP 를 필요할때만 불러와 컨텍스트에 할당하여 사용해 효율 측면에서 좋음 MCP 가 컨텍스트 윈도우의 10%를 넘으면 자동으로 활성화

// settings.local.json
"env": {
    // 10% 가 아닌 5% 로 설정
    // true 로 설정 시 항상 활성화
    "ENABLE_TOOL_SEARCH": "auto:5"
}

Agent Teams

기존 서브 에이전트는 독립된 공간에서 독자적으로 실행된 결과를 메인에 넘기는거였다면 Agent Teams 는 하나의 팀을 이루면서 서로 소통하면서 협업하는 방식 각 팀원들은 메인 세션처럼 CLAUDE.md, mcp, skills 이런거는 동일하게 로드됨 공식문서는 팀원 3~5명 권장

Agent Teams 를 사용해서 직장인 점심 도시락 배달 서비스 런칭 기획안을 만들어줘.

팀원 4명을 생성해줘.
- 팀원 1: 시장 조사 담당 (시장규모, 타겟 고객, 성장 추이)
- 팀원 2: 경쟁사 분석 담당 (직접/간접 경쟁사, 차별화 전략)
- 팀원 3: 예산안 담당 (초기 투자, 운영비, 손익분기점)
- 팀원 4: 일정표 담당 (5단계 로드맵, 마일스톤)

각 팀원이 작업을 마치면 결과를 하나의 기획안으로 종합해줘.

Agent Teams 활성화

// settings.local.json
"env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}

효율적으로 Agent Teams 사용하기

비용은 절반이며, 품질은 2배

1. 계획 승인 모드 일반적으로 팀을 생성하면 바로 코딩을 시작하는데, 프롬프트에 다음 내용 추가

   각 팀원이 변경하기 전에 plan approval 을 받도록 해줘 위 프롬프트는 팀원이 읽기 전용 모드(plan mode)가 됨

   • 1. 팀 생성
     • 2. 계획 분석 (plan mode)
     • 3. 계획 제출 (리드에게 보고)
     • 4. 승인/거절 (리드가 판단)
     • 5. 구현 시작 (승인 후 실행)

     TeamCreate 로 에이전트 팀 생성해줘 // 서브 에이전트로 진행하는거 방지 에이전트 팀으로 프로젝트 코드를 병렬 리뷰하고 문제를 수정해줘 각 팀원이 변경하기 전에 plan approval 을 받도록 해줘

     팀원 1 (보안): API 키 노출, XSS 취약점, 환경변수 안전성 팀원 2 (성능): 'use cache' 패턴, 리렌더링, 이미지 최적화 팀원 3 (아키텍처): 의존성 방향 (app->features->shared->ui), cn() import 경로

2. 모델믹싱 Agent Teams 의 토큰 사용량은 활성 팀의 수에 비례해서 증가 즉, 적절한 모델을 각 팀원에 맞게 분배하는게 중요

리드: 조율, 추론, 계획 검토, 작업 분해, 품질 판단 / Opus 추천 팀원: 코드 생성, 파일 편집, 구현 작업 / Sonnet 추천 현재 세션 모델이 opus 라면 리드는 자동으로 Opus

팀원은 모두 Sonnet 사용해

3. 여러 측면에서 생각
   • 팀원들끼리 소통이 필요한가? 서브 에이전트로도 충분하지 않은가
   • 작업이 끝난 팀원은 즉시 종료. 팀원 세션이 살아있으면 계속 토큰 소모
   • CLAUDE.md 에 완료 후 즉시 종료, 반복 3회 제한 등 규칙 생성

Hooks 이벤트 자동화

팀원 에이전트는 맡은 작업을 다 끝내거나 지시를 기다릴때 idle 상태가 됨 Claude 의 Hooks 로 이런 상태변환을 감지할 수 있음

1. TeammateIdle 팀원 단위로 발동되며, 팀원이 모든 일을 마치고 idle 상태에 들어가려할 때 발동되는 훅

   작업이 끝나면 요약 보고서를 작성해라

   조금전에 처리한 업무와 관련된 일을 시킬 수 있음

2. TaskCompleted 태스크 단위로 발동되며, 팀원이 해당 작업을 다 완료한 상태에 발동되는 훅

하나의 팀원이 3개의 Task 를 진행한다고 가정했을때 TaskCompleted 훅은 3번, TeammateIdle 훅은 1번 발동 그래서 TaskCompleted 훅은 해당 Task 에 대한 검증을 수행하는데 사용되고, TeammateIdle 훅은 팀원 전체 작업을 검증하는데 사용

클로드 코드에서 모델은 아래와 같이 구성되어있다. Opus: 상급 Sonnet: 중급 Haiku: 초급 만약 기획을 Opus 로 짜고, 코드는 Sonnet 으로 작성하고 싶다면 매번 모델을 변경하면서 번거롭게 해야할까?

/model opusplan

/model 에서는 앞선 3개의 종류만 명시되어있는데, 공식문서를 읽다보니 발견된 opusplan! 설계나 기획은 opus 를 사용하고, 실제 코드 작성할때는 내부적으로 Sonnet 으로 전환됨 유용하게 사용할 수 있을 것 같다

Context window

현재까지의 대화를 담은 통 보통 200K tokens (책 한권 분량) 차면 찰수록 AI 가 바보가 될 확률이 올라감 input(입력) 과 output(응답) 모두 컨텍스트에 담김 서브 에이전트, MCP 등 확장 기능도 Context window 차지

1. 새로운 기능 구현할 때 clear 명령
2. 구현하면서 /context 로 현재 컨텍스트 사용량 체크
3. 컨텍스트 사용량이 70%를 넘어가면 clear, 계속 대화를 이어가고 싶다면 compact

   /model sonnet[1m]

   위와 같이 입력하면 100만 토큰(Beta) 지정

최대 사용량 비교

플랜별로 어떤 모델을 사용하면 좋을지 정리

사용량 확인

/usage

Current session: 5시간 단위로 리셋 Current week(all models): 일주일 단위로 리셋 opus, sonnet, haiku Current week(sonnet only): 일주일 단위로 리셋 sonnet

/statusline

토큰 효율적으로 사용 방법

명확하게 범위를 제한해서 요청하기 ex)) 간단한, 단일 파일로, ~줄 이하, 배포/테스트/빌드 제외

응답 출력 스타일 변경

(구)
/output-style
(현)
/config 안에 들어있음

1. Default: 기본값
2. Explanatory: 코드 작성하면서 중간중간 교육적 인사이트 제공. 왜 이렇게 구현했으며 패턴은 무엇인지
3. Learning: 통찰력 공유 및 TODO 마커를 남겨서 사용자가 직접 구현하도록 유도

settings.json 파일내에 outputStyle 지정 시 매번 해당 스타일로 응답

나만의 커스텀 출력 만들기

아래와 같이 형식이 나뉘어져 있음

1. 출력 스타일의 메타정보를 갖고 있는 프론트 메터 부분 name, description 외에 keep-coding-instructions: true 가 선언되어있어야 코드 작성됨
2. 실제 어떻게 응답하라는 지침

이렇게 설정하면 /output-style 에서 해당 커스텀 스타일을 선택할 수 있음

메모리 파일

세션을 종료(/exit) 하면 백지 상태가 됨 이 프로젝트에서 매번 지켜야할 규칙 정리 (CLAUDE.md) 매번 세션 시작할때 Claude 가 자동으로 읽음

이미 프로젝트가 진행되어있는 경우
아래 명령어를 통해 초기 CLAUDE.md 파일 생성
현재 프로젝트 구조 분석해서 규칙 정리
/init

현재 작성된 사용자, 프로젝트, 로컬 등 메모리 편집하고 싶다면
/memory

CLAUDE.md 파일은 500줄 이하로 유지 권장 그러므로 파일 참조 import 구문을 적극 활용하여 작성하기

모듈형 규칙

CLAUDE.md 파일에 import 구문으로 작성하면 정리가 안되고 방대해지는 문제가 있음 모듈형 규칙을 사용하면 디렉토리 구조가 더 깔끔해지고 별도의 import 도 필요없이 매번 세션 시작할때마다 rules 도 함께 읽음

추가로 특정 디렉토리나 파일에만 적용시키고 싶은 경우 path frontmatter 사용 ex)) API 작성 규칙

.claude/rules/ 디렉토리에 md 파일 배치

각 파일은 하나의 주제를 다루어야함 파일명만 봐도 내용을 알 수 있어야함

MCP 활용

Context7: AI 어시스턴트들이 항상 최신 라이브러리 정보를 알 수 있게 도와주는 서비스

클로드코드에서 권장하는 개발 워크플로우

Explore(탐색): 도메인 지식, 관련 파일, 이미지 등 정보 수집 plan(계획): 특정 문제에 접근하는 방법에 대한 계획 code(구현): "~기능 만들어줘" 진행 단계마다 멈춰서 "이 부분은 잘 동작할까?", "빠뜨린 건 없는가?" 검증 commit(커밋)

프롬프트 엔지니어링 기법

1. CoT (생각의 사슬) Chain of Thought. 단계별로 문제를 해결하면 일반적으로 복잡한 작업에서 오류가 줄어듬

2. 페르소나 특정 도메인 지식을 필요로 할 때 역할을 부여하면 성능을 크게 향상시킬 수 있음

커스텀 커맨드 만들기

/.claude/commands 경로에 md 파일로 생성한 파일은 커맨드로 사용할 수 있음 그룹화도 가능

/.claude/commands/git/commit.md 작성된 md 파일을 명령어로 사용

/git:commit

동적 파라미터 커맨드

$ARGUMENTS 또는 $숫자 를 이용해서 커맨드 명령어 뒤에 입력한 내용이 동적으로 들어감

// git/commit.md
---
description: git 커밋 생성
---
커밋 메시지: $ARGUMENTS
/git:commit 로그인 기능 완료

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

커밋메시지: $1, $2
/git:commit 로그인기능 장바구니기능

추가 (3/17):

skills 로 통합되어 슬래쉬 명령어 할 필요 없이 요청에 맞는 커맨드를 자체적으로 찾아 실행 커스텀 커맨드(레거시) => skills

서브 에이전트

프로젝트를 진행하면 새로운 기능, 코드 리뷰, 보안취약점, 테스트 등과 같이 여러 고려할 사항이 있는데 이걸 하나의 에이전트에서 하면 전문성도 떨어지고, 메인 컨텍스트의 맥락도 어지럽혀짐 그래서 서브 에이전트로 각각 처리하는 방식이 베스트

/agents

추가 (3/17):

Claude Code 에 Skills 라는게 업데이트되면서 서브 에이전트는 Skills 로도 생성이 가능하며 컨텍스트 효율 측면에서도 우위 일회성이 아닌 이상 skills 로 구현하기

호출방법

1. Claude 가 우리 요청을 분석해서 적절한 서브 에이전트 자동 호출
2. 프롬프트 요청 시 해당 서브 에이전트 언급해서 요청

주요 이점

유연한 권한: 코드리뷰의 경우 READ 권한만 부여 재사용성: 한번 생성하면 다양한 프로젝트에서 사용하며 일관된 워크플로우 제공 전문 지식: 서브 에이전트만의 페르소나를 입력 컨텍스트 보존: 각 서브 에이전트는 자체 컨텍스트에서 작동하여 결과만 요약하여 메인 컨텍스트에 전달

훅

Claude Code 생명주기 다양한 지점에서 실행되는 명령어

1. Bash 와 같은 명령어가 실행된 이후 작업될 내용
2. 코드 수정 후 포맷팅 작업을 한다던가
3. Claude 에게 특정 작업을 요청 후 슬랙에서 완료했다는 알람을 받는다던가

기본 패턴

의존성이 없는 객체는 생성 시 스스로 정해짐 무기에 대한 선택 불가

class Adventurer {
  final Weapon = Gun();

  const Adventurer();

  void attack() {
    // 무기로 때립니다
  }
}

생성자 주입

가장 일반적으로 사용되며 불변성 강조에 사용 객체를 생성할 때 필요한 의존성을 명시적으로 전달하여 무기에 대한 선택이 가능 ( 단, 무기는 객체 생성 시 필수로 전달 ) 코드의 가독성과 유지보수성을 높임

final Weapon weapon = Gun();

final Adventurer adventurer = Adventurer(weapon);

adventurer.attack();

속성 주입

무기가 없이도 어드벤처는 존재 가능하고 이후에 장착 일부 의존성이 필수가 아닌 선택적으로 주입되어야 할 때 유용

final Adventurer adventurer = Adventurer();

final Weapon weapon = Axe();

adventurer.equip(weapon);

메서드 주입

행동을 할 때 무기를 주입 특정 메서드에서만 의존성이 필요한 경우에 사용

final Adventurer adventurer = Adventurer();

final Weapon weapon = Axe();

final Weapon weapon2 = Gun();

adventurer.attack(weapon2);

정리해보자면, 생성자 주입: 기본적인 필수 의존성 속성 주입: 선택적인 의존성 ( 주입된 객체 필드에 저장 ) 메서드 주입: 선택적이면서 특정 메서드 ( 매개변수에서 주입된 객체 1회성 사용 ) ※ 메서드 주입 과정에서, 주입된 객체를 필드에 저장하는 순간 그건 더 이상 메서드 주입이 아닌 속성 주입

의존성 주입 왜 필요해? 빼빼로 클래스에 대해 내부에서 초코 코팅을 선언하면, 빼빼로 클래스는 초코만 생성 가능. 즉, 딸기, 아몬드와 같은 맛을 동시에 생성할 수 없음

get_it 이론

서비스 로케이터 기반 간단하고 가벼운 의존성 주입 라이브러리

서비스 로케이터 객체의 인스턴스를 관리하고 검색하는 디자인 패턴 의존성 주입이 적용되지 않은 상황에 객체간의 의존성 해결에 사용 장점 싱글톤 패턴이며, 모든 의존성이 중앙 집중식 관리. 단점 객체가 자신에게 필요한 의존성을 클래스 내부에서 직접 조회하는 방식이기 때문에, 외부에서 객체를 생성하거나 사용하는 입장에서는 해당 객체가 어떤 의존성에 의존하고 있는지 명확히 드러나지 않는다.

get_it 실습

enum 컴파일 타임에 고정된(const) 값들의 집합이며, 내부에는 가변 상태를 가질 수 없다.

// 아래 코드에 int counter 넣는건 부적절 (가변이어서)
enum CounterMode {
  plus,
  minus;

  CounterMode next() {
    switch (this) {
      case CounterMode.plus:
        return CounterMode.minus;
      case CounterMode.minus:
        return CounterMode.plus;
    }
  }
}

상태에 대한 이해를 돕기 위한 추가 코드

enum TrafficLight { 
    red,
    yellow,
    green;

    TrafficLight next() {
      switch (this) {
          ...
      }
    }
  }
}

TrafficLight light = TrafficLight.red;

TrafficLight 는 총 3개의 상태를 가지고 있으며 현재 red 로 초기화
next() 안에 switch 의 this 는 red

주로 enum 으로 상태를 선언하고 해당 enum 을 컨트롤하는 class 를 따로 구현해 비즈니스 로직 구현

get_it 실습코드

// main.dart
final GetIt locator = GetIt.instance;

void main() {
  locator.registerSingleton<CounterModel>(CounterModel());
  locator.registerSingleton<CounterModeModel>(CounterModeModel());
  runApp(const CounterApp());
}

// screen.dart
locator.get<CounterModel>().counter.toString();

위 코드에서 알 수 있듯이 Dart 에서는 Type 값으로 해당하는 인스턴스를 불러올 수 있다 Dart 는 런타임 후에도 타입 정보가 유지되기 때문 ( TS 에서는 컴파일 후 삭제되어서 Type 값으로 특정 값 리턴 불가 )

injectable 이론

@Annotation 을 이용한 의존성 주입. 주로 get_it 과 함께 사용 injectable: 클래스나 함수에 어노테이션 추가하여 의존성을 자동으로 등록 get_it: 불러오기만 담당

// dependency.dart

import 'package:get_it/get_it.dart';
import 'package:injectable/injectable.dart';
import 'dependency.config.dart';

final GetIt locator = GetIt.instance;

@injectableInit
void configureDependencies() => locator.init();

위와 같이 파일 생성 후 아래 명령어 실행 build_runner 는 모든 작성된 코드를 훑어보면서 @Annotation 이 발견되면 그에 맞는 .g.dart 혹은 .config.dart 파일을 자동으로 생성 injectable 라이브러리와 build_runner 사이에는 어떤 파일에 @injectableInit 이라고 써놓여져있으면 build_runner 실행 시 .config.dart 를 붙인 설정 파일을 만들어줌

flutter pub run build_runner build --delete-conflicting-outputs

아래 코드는 build_runner 실행으로 인해 생성된 코드

// dependency.config.dart

import 'package:get_it/get_it.dart' as _i1;
import 'package:injectable/injectable.dart' as _i2;

extension GetItInjectableX on _i1.GetIt {
// initializes the registration of main-scope dependencies inside of GetIt
  _i1.GetIt init({
    String? environment,
    _i2.EnvironmentFilter? environmentFilter,
  }) {
    _i2.GetItHelper(
      this,
      environment,
      environmentFilter,
    );
    return this;
  }
}

dependency.dart 파일에 @singleton, @injectable 등으로 마킹해둔 클래스들이 dependency.config.dart 에 정의됨 이후 locator.init() 을 호출하면, dependency.config.dart 안의 로직이 실행되면서 Get_It 에 모든 객체가 담김

순서 흐름

1. dependency.dart 파일 생성
2. 의존성 부분들에 @Annotation 선언
3. build_runner 실행
4. 자동으로 @Annotation 선언된 부분들에 대한 코드 생성
5. init() 함수 호출하여 get_it 에 자동 주입

   ㅡㅡㅡㅡㅡㅡㅡㅡㅡ 변경 전 ㅡㅡㅡㅡㅡㅡㅡㅡㅡ
   void main() {
   locator.registerSingleton<CounterModel>(CounterModel());
   locator.registerSingleton<CounterModeModel>(CounterModeModel());
   runApp(const CounterApp());
   }
   

// model.dart class CounterModel { ... } class CounterModeModel { ... }

ㅡㅡㅡㅡㅡㅡㅡㅡㅡ 변경 후 ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ void main() { configureDependencies(); runApp(const CounterApp()); }

// model.dart @singleton class CounterModel { ... } @singleton class CounterModeModel { ... }

### provider 이론
InheritedWidget 을 더 쉽게 사용할 수 있게 해주는 wrapper
위젯트리 전반에 걸쳐 데이터와 객체를 전달하고 관리해주는 상태 관리 라이브러리

// listen: 등록된 객체의 값이 변경될때마다 해당 위젯 재빌드 여부 Provider.of(context, listen: true);

// Provider.of 에서 listen: false 와 동일 context.read()

// Provider.of 에서 listen: true 와 동일 context.watch()

아래와 같은 방식으로 상위 위젯에 등록 후 하위 위젯들이 사용

void main() { runApp( MultiProvider( providers: [ Provider(create: (context) => CounterModel()), Provider(create: (context) => CounterModeModel()), ], child: const CounterApp(), ), ); }

>**의존성 주입 라이브러리가 필요한 이유**
화면을 만들때마다

ViewModel(FetchUseCase(Repository(DataSource(LocalDB())))

이런식으로 코드를 가져오는게 아닌

context.read()

한줄이면 끝


<hr/>

## 아키텍처 학습
여러 기능과 상태를 어떻게 구성하고 관리할지
### MVC 이론
**Model**
데이터와 비즈니스 로직을 관리하는 부분

class Model { int _count = 0; int get count => _count;

void increment() {
      _count++;
}

}

**view**
사용자 인터페이스 부분

class _ViewState extends State{ ...

@override
Widget build(BuildContext context) {
    return Scaffold(
        ...
    )
}

}

**controller**
Model 과 View 사이의 상호작용 관리

class Controller { final Model _model;

Controller(this._model);

void increment(){
    _model.increment();
}

}

위 코드를 통해 알게된 점은 class 에 변수 선언된 경우 get 으로 가져오는게 한 세트이며, 변수 선언할 때 어떤 값이 들어가야 할지 정의된 경우 enum 사용
controller 는 model 의 데이터와 로직을 호출하여 동작하므로, 두 계층 간의 결합이 발생한다

### MVVM 이론
주로 UI 가 많은 애플리케이션 개발에 적용되는 패턴
MV 까지는 MVC 와 동일

**viewModel**
view 와 model 의 중재자 역할
MVC 에서 model 은 변수, 비즈니스 로직을 담당
viewModel 은 변수, 비즈니스 로직 + 상태( 화면에 반영 ) 담당

#### MVC 와 MVVM 의 가장 큰 차이

**MVC 패턴:** View 가 중심이 되어 Controller 의 메서드를 호출하고, 그 결과를 setState() 를 통해 직접 UI에 반영. 즉, View 가 상태 변화와 화면 갱신을 직접 트리거해야 하므로 주로 StatefulWidget 구조를 가짐

**MVVM 패턴:** ValueNotifier 와 ValueListenableBuilder 가 데이터 바인딩 역할을 수행. ViewModel 이 변수, 상태, 비즈니스 로직을 전담하며, View 는 이를 관찰할 뿐 직접적인 화면 반영 로직(setState)을 갖지 않음. 결과적으로 View 는 로직으로부터 자유로운 StatelessWidget 중심의 선언적 구조

**ValueNotifier:** 데이터를 보관하고 변하는지 감시
**ValueListenableBuilder:** 해당하는 ValueNotifier 값이 변경되면 해당 부분만 다시 그림

ValueListenableBuilder( valueListenable: counterViewModel.counter,

builder: (context, counter, child) => Text( counter.toString(), style: Theme.of(context).textTheme.headlineMedium, ), ),

### 클린 아키텍처

svg 이용할때는 flutter_svg 라이브러리 사용

ListTile

리스트 한줄을 위해 미리 만들어진 위젯 leading, title, subtitle, trailing 이용하여 UI 구성

UI 배치

css에서 absolute, fixed 사용하듯이 flutter 에서는 Stack 과 Positioned 위젯 사용하여 배치 ( e.g. FAB )

FAB 에는 heroTag 라는게 존재하는데, 한 위젯내에 여러 FAB 가 선언되는 경우 동일한 default tag 값이 설정됨 페이지 이동 시 동일한 tag 값은 애니메이션 과정에서 오류 발생. 애니메이션 과정은 다음과 같음 A 라는 FAB 의 heroTag 가 b1 이라면, 이동할 페이지의 FAB 역시 heroTag 가 b1 일때, 자연스러운 FAB 레이아웃 이동 애니메이션이 동작

외부 API 연동하기

http 라이브러리 이용하여 통신 안드로이드에서 인터넷 접근 권한 허용을 위해 아래 파일 수정

android > app > src > main > AndroidManifest.xml

IOS 에서는 기본으로 인터넷 접근 권한이 포함되어 있음 FutureBuilder Future 상태를 감시하다가 결과에 맞는 UI 그려주는 위젯 실행 흐름 api 호출 > 생성자에 결과 담기 > initState 에서 해당 fetch 함수 결과를 변수에 초기화 > FutureBuilder 에서 동적 UI 페인팅

factory 객체를 만들기 전에 가공하거나 조건을 걸고 싶을 때 사용하는 특별한 생성자 late 변수 선언 먼저 하고 초기화는 나중에

날씨앱

플랫폼별 퍼미션 설정

모든 앱은 OS 안에서 격리된 공간인 샌드박스 안에서만 실행. 앱은 기본적으로 자신의 폴더 외에는 접근이 안되는데, 선언된 퍼미션을 통해 샌드박스를 뚫고 외부 데이터에 접근 가능

Google Play나 Apple App Store는 앱이 선언한 권한과 실제 기능이 일치하는지 심사하고, 권한 선언 없이 민감한 데이터에 접근하려고 시도하는 앱은 아예 스토어 등록 자체가 거부됨

android

// AndroidManifest.xml
// 위치정보

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />

ios

// Info.plist
// 위치정보

<key>NSLocationWhenInUseUsageDescription</key>
<string>This app needs access to location when open.</string>
<key>NSLocationAlwaysUsageDescription</key>
<string>This app needs access to location when in the background.</string>

위치 및 시간 변경

async 함수 내에서 context 사용법?

예를 들어 로그인 버튼 클릭하고 서버로부터 응답 받기 전에 사용자가 뒤로가기를 눌러 현재 위젯이 사라진 경우 해당 로그인 함수 안에 context 는 이미 dispose 된 context 를 사용하려하여 에러 발생 이 경우 State 클래스에 정의된 멤버 변수인 mounted 로 해결

Future<void> login(BuildContext context) async {
    await Future.delayed(const Duration(seconds: 2)); // 서버 요청 가정

    // 해결 코드
     if (!mounted) return; 

    // ⚠️ 파란 밑줄
    Navigator.of(context).push(
      MaterialPageRoute(builder: (_) => const HomePage()),
    );
  }

  @override
  Widget build(BuildContext context) {
    return ElevatedButton(
      onPressed: () => login(context),
      child: const Text('로그인'),
    );
  }

super(): 부모 클래스의 생성자 호출

class DialPhone {
  int? year;

  DialPhone() {
    print("다이얼을 돌려서 전화를 겁니다");
  }

  void whenCame() {
    print("188년에 발명되었습니다 $year");
  }
}

class ButtonPhone extends DialPhone {
  int? to;

  ButtonPhone() {
    print("이 전화기는 버튼을 눌러서 전화를 겁니다");
  }

  @override
  void whenCame() {
    print("1963년 발명 $year $to");
  }
}

class SmartPhone extends ButtonPhone {
  String maker;
  String model;

  SmartPhone({required this.maker, required this.model, int? year, int? to}) : super() {
    super.year = year;
    super.to = to;
  }
}

void main() {
  SmartPhone sp = new SmartPhone(maker:"애플", model: "아이폰20", year:30,to:50);
  sp.whenCame();
}

// print 결과 ▼
// 다이얼을 돌려서 전화를 겁니다
// 이 전화기는 버튼을 눌러서 전화를 겁니다
// 1963년 발명 30 50

Stateless 위젯의 특징

일회성 UI 요소로 사용되며 상태가 바뀌어야할 때 기존 위젯을 제거하고 새롭게 위젯을 생성

내부적으로 abstract 형식으로 Stateless 가 정의되어있음 그래서 build 메소드의 경우 자식 클래스에서 재정의 해주어야함

추상클래스 abstract body{} 가 없는 메소드의 경우 반드시 자식 요소에서 재정의 해주어야함

abstract class Animal{
  void makeSound();
}

class Dog extends Animal{

  @override
  void makeSound(){
    print("왈왈");
  }
}
void main(){
  Dog dog = Dog();
  dog.makeSound();
}

Element 트리란 무엇일까요

Widget tree 이렇게 그려줘라고 지시하는 설계도 역할

Element tree Widget tree와 렌더 트리 중간에서 서로를 연결시키면서 앱의 효율적인 UI 업데이트를 관리 Widget tree가 생성될때마다 이에 근거해서 flutter 프레임워크가 즉시 함께 생성하고 컨트롤해줌 따라서 Widget tree의 모든 위젯은 1대1 맞대응 형식으로 Element tree에 링크되어 있음 연결된 Widget 의 모든 정보를 가지고 있음 ( 위치, 타입, 크기, 배경색 등..) 그래서 어떤 Widget 의 상태가 변경되어서 빌드 메소드가 호출되고 Widget tree 가 리빌드 된다면 이와 연결되어 있는 Element tree 도 함께 리빌드 되는것이 아닌 새롭게 리빌드된 Widget 의 위치나 타입 속성등이 이전 Widget과 일치하면 이전 Widget과의 연결을 끊고 새롭게 생성된 Widget 인스턴스로 링크만 업데이트해줌 렌더 트리가 이 부분을 다시 앱 화면에 그려주게 됨 그 외 상태 변화가 없는 Widget들은 그대로 유지

Render tree UI 를 실제로 화면에 표시하기 위해서 각 위젯의 위치와 크기를 계산하고 그리는 역할

예를 들어 앱의 특정 텍스트 위젯에 전달되는 문자열이 setState 를 통해 바뀌었다면 기존 텍스트 위젯을 그대로 수정하는것이 아니라 빌드 메소드를 다시 호출하여 완전히 새로운 텍스트 위젯 인스턴스를 생성

간단 요약

Widget이 바뀌면 무조건 새로운 Widget 만들어지고, Element는 조건이 맞으면 재사용되고, (매핑된 새 Widget과 기존 Widget의 runtimeType과 key가 동일할 때, 즉 직접적으로 key 를 선언하여 명시하거나, Text 위젯에서 Icon 위젯처럼 변경하지 않는 이상 리빌드 되지 않음 ) RenderObject는 실제 렌더링에 영향이 있을 때만 layout/paint 된다. Widget tree 내에서 변경된 부분은 새롭게 Widget이 만들어지고 Element tree 는 기존 Widget 은 버리고 새롭게 만들어진 Widget 과 링크해주고, 그외 변경되지 않은 Widget들은 재사용

Stateful 위젯의 구성과 특징

Stateless 위젯과 거의 동일하게 동작하는데, 가장 큰 차이는 Stateful 위젯 생성 시 State Object 도 함께 생성됨 Stateful 위젯 생성하는데 비용이 많이 드는 이유가 State Object 때문 이러한 State Object 를 버리고 새로 만들기보단 그대로 유지한 채 최대한 재사용하며 상태의 변화에 따라 새롭게 생성된 Stateful 위젯으로 링크만 업데이트되는 전략

State Object 는 위젯이 Element Tree에 처음 연결될 때 한 번 생성되고, Element가 제거(dispose)될 때 함께 메모리에서 해제된다. 쉽게 설명하자면 해당 위젯이 화면에서 완전히 제거될 때 메모리에서 정리되어 함께 사라진다.

왜 모든 Widget 들(Stateful Widget 포함)이 불변성을 가져야 할까요?

위젯은 변하면 무조건 재생성함. 이 자체가 불변성 Stateful 위젯 역시 불변성으로 인해 재생성 해야하니 비용이 많이드는 State Object 은 Stateful 위젯에 포함하지 않고 Element tree 에 State Object 가 존재하는것

1. 예측 가능한 UI 구조가 필요. Widget 이 절대 변하지 않으니 데이터 전달로 인해서 발생하는 상태의 변화는 오직 Build 메소드를 통해서만 이루어짐

2. Element 트리의 최적화 기존 Element 를 유지한 채 링크를 업데이트하는 방식으로 Widget 만 새로 연결함으로 그 성능을 효율적으로 유지

3. 위젯 비교 및 정보 확인의 편리성 한번 생성된 Widget 은 변하지 않으므로, 기존 Widget 과 새 Widget 을 비교해서 바뀐 부분만 다시 그릴 수 있음

final 과 const 이해하기

const 컴파일 타임때 변수의 값을 결정하며, 이후 해당 값은 절대 변하지 않음 동일한 const 생성자는 컴파일 타임에 단 하나의 인스턴스만 생성되어 같은 객체 참조를 재사용

const Text('Hello') === const Text('Hello') // true

immutable 한 변수나 위젯에 사용하여 재사용 가능 현재는 flutter 에서 immutable 한 요소는 자동으로 컴파일 시점에 const 객체처럼 취급

final 런타임때 변수의 값을 결정하며, 이후 해당 값은 절대 변하지 않음 Widget 은 런타임에 사용되는 불변 객체로, 생성자는 필드를 final 로 초기화하는것이 적절 Widget 앞에 const 를 붙이면 런타임마다 새로 만들지 않고, 동일 인스턴스를 재사용하라는 의미

setState 메소드와 제네릭

setState 로 인해 값이 변경되면, 해당 값을 사용하는 Widget 에 Dirty mark 를 해주어서 해당 부분만 리빌드 시 다시 생성

colorScheme 앱 전반에서 사용할 수 있도록 정리해둔 색상 팔레트 정밀한 색상 통제가 필요할 때 사용

// 아래 코드는 colorSchemeSeed 와 비슷하지만,
// 전체적인 조화에 맞춰 생성된 컬러에 대해
// 수정하거나 정교하게 통제 가능
colorScheme: ColorScheme.fromSeed(seedColor: Colors.deepPurple) 

colorSchemeSeed 하나의 seed 색상을 중심으로 자동으로 flutter 가 전체적인 조화에 맞춘 컬러를 계산해줌 디자인 지식이 부족해도 손쉽게 색상 테마를 구성할 수 있도록 해줌

Stateful 위젯 인스턴스의 리빌드

.of(context) 는 현재 BuildContext 에서 가장 가까운 일치하는 위젯을 반환

State Object 개념 확실히 이해하기

// Widget
class MyWidget extends StatefulWidget{
    ...
}

// State Object (Widget 아님)
class _MyWidgetState extends State<MyWidget>{
    ...
}

Widget 속성 이해하기

initState State Object 가 처음 생성될 때 딱 한번 실행되는 상태 초기화 시켜주는 메소드

@override
void initState() {
    color = widget.passedColor;
    super.initState();
}

웹서버: 정적인 리소스를 제공하는 서버. 페이지(CSR, SSG), 이미지... 웹어플리케이션서버: 동적인 리소스를 생성해 제공하는 서버. 페이지(SSR, ISR), DB, API...

AWS 서비스 안내

Amplify

기본 제공 CI/CD 워크플로를 통해 웹 애플리케이션의 글로벌 배포와 호스팅을 지원하는 완전관리형 서비스 Elastic Beanstalk처럼 개발과 배포를 쉽게 만들어준다

1. npm i -g @aws-amplify/cli Amplify 를 사용하기위해 글로벌 설치
2. amplify confiure aws console 에 로그인 후 region 선택
3. IAM 유저 생성 aws 상호작용 하기위한 유저나 어플리케이션에대한 권한 부여. 생성된 액세스 키 및 시크릿 액세스 키를 입력하면 세팅 작업 끝
4. 간단한 Next 애플리케이션 배포하기위한 npm init next-app
5. git repository 생성
6. Amplify hosting 에 추가하기위한 init 생성한 Next 애플리케이션을 amplify init
7. add 커맨드를 이용하여 Amplify hosting 추가 amplify add hosting 이 과정에서 CD(자동배포) 선택 가능
8. aws 페이지에서 Amplify Hosting 시작하기 페이지가 나옴
9. github 체크한 경우 repository 및 브런치 선택
10. 빌드 설정
11. 검토
12. 배포 완료
13. 자동 배포

EC2

Elastic Compute Cloud(EC2) 비용/성능/용량 측면에서 유연한 클라우드 컴퓨팅 서비스 실제 서버를 구축하는 형식이 아닌 AMI 기반으로 형성된 가상 서버를 임대해서 사용 사용한만큼 지불

EC2 인스턴스(가상 서버)는 운영체제와 기본 소프트웨어가 포함된 AMI(Amazon Machine Image)를 기반으로 생성된다. vCPU/vRAM/Storage/Network 등 다양한 스펙의 인스턴스 타입이 존재

머신 이미지: 사전 구성 템플릿

Auto scaling 인스턴스 그룹화하여 자동으로 확장/축소 가능

ssh 프로토콜 다른 컴퓨터에 안전하게 원격 접속하기 위한 범용 프로토콜

ssh -i "nextajs_ec2_keypair.pem" ec2-user@ec2-13....ap-northeast-2.compute.amazonaws.com

위와 같은 방법으로 가상 서버 접속 후 git repository 연결 및 프로젝트 실행

브라우저는 포트 번호를 명시하지 않으면 기본적으로 80번 포트를 사용 따라서 자동 할당된 공인 IP 주소를 브라우저에 입력하면 13.125.26.212:80 으로 요청이 전송된다. 이때 가상 서버에서 Nginx가 80번 포트를 리스닝하도록 설정되어 있다면, 운영체제는 해당 요청을 80번 포트에 바인딩된 Nginx 프로세스로 전달한다

위 정리된 이미지의 실행 순서를 정리하자면

1. 13.125.26.212 접근
2. 80번 포트(Nginx)에 접근
3. Nginx 에서 3000번 포트로 전달
4. 가상 서버에 실행된 Next 서버에 접근

위 방식은 현재 포어그라운드로 터미널 종료되거나 ssh 끊기면 서버가 종료 그래서 pm2 라는 프로세스 매니저를 사용하여 SSH 연결과 무관하게 Next 서버를 독립적으로 실행하고, 문제 발생 시 자동 재시작되도록 구현

S3

Simple Storage Service(S3) 유연하고 확장성 있는 클라우드 스토리지 서비스 중 하나 객체 저장 뿐만 아니라 웹 어플리케이션 호스팅 가능

cli 를 통해서 S3에 배포 시도 시, AWS 의 권한 필요하여 IAM 추가

IAM: 위에서도 설명했지만, AWS와 상호작용하기 위한 profile, 허용된 권한을 확인한 후 해당 profile에 맞는 Access Key와 Secret Key를 설정

버킷 정책을 통해 특정 접근에 대해서만 권한(리소스 접근)을 허락하게 설정 가능

CloudFront

CDN 서비스 서버와 사용자 사이의 물리적 거리를 줄여 로딩 속도 향상 가장 가까운 캐시 서버가 컨텐츠 전송

위 이미지를 기준으로 설명하면,

1. 사용자가 데이터를 요청
2. CloudFront 에서 사용자가 요청한 데이터가 있는지 확인
3. 없으면 CloudFront 는 EC2 에서 데이터를 요청하고, 받은 값을 캐시
4. 다른 사용자가 동일한 데이터를 요청 시 캐시된 값을 반환

정적/동적 컨텐츠 분산 제공 (트래픽이 몰리지 않도록) 지리적 제한 설정 (특정 국가에서 보지 못하도록) 다른 서비스와 연계 (Lambda@Edge 를 이용해 요청을 가로채서 캐싱, 헤더 변경 가능)

S3 버킷을 CloudFront 로 처리하고 배포하기

1. CloudFront 배포 생성
2. 기존 생성된 S3 버킷을 원본 도메인으로 설정
3. S3 버킷 정책 업데이트
4. 배포된 CloudFront 도메인 접근 시 index.html 접근
5. 오류 페이지 설정에서 사용자 정의 오류 응답 생성하여 404 페이지 대응

webp, AVIF 등의 차세대 형식으로 변환 디바이스 사이즈에 맞는 이미지 불러오기 레이지 로딩 적용 블러 이미지 활용 기타등등..

이러한 작업을 Nextjs 에서는 Image 컴포넌트로 쉽게 구현 가능

외부 서버에 보관된 이미지 사용하는 방식이라면 보안때문에 차단된 상태

// next.config.js
const nextConfig = {
    ...
    images: {
        domains: ["~.net"]
    }
}

동적으로 메타데이터 설정하기

// 정적
export const metadata : Metadata = {
    ...
}

or

// 동적
// Page 에서 props 로 전달받은 값을 그대로 사용 가능
export async function generateMetadata({searchParams}): Promise<Metadata> {
    const { q } = await searchParams;

    // API 호출도 가능
    // const response = await fetch(...)

    return {
        title: `${q} : 검색`,
        ...
    }
}

위 방식대로 작성하면 해당 페이지에 설정한 메타데이터가 index.html 에 설정됨

병렬 라우트

하나의 화면안에 여러개의 페이지를 병렬로 함께 렌더링

폴더구조
parallel
    - @feed
        - setting
            page.tsx
        - page.tsx
    - @sidebar
        - page.tsx
    - layout.tsx
    - page.tsx

@sidebar 와 같이 @ 붙은 형식을 Slot 이라 부름 병렬로 렌더링 될 페이지 컴포넌트를 보관하는 폴더 여기서 선언된 page.tsx 는 부모 layout.tsx 의 props 로 전달됨

export default function Layout({
    children,
      sidebar
}:{
    children: ReactNode;
    sidebar: ReactNode;
}) {
    return (
        <div>
            {children}
              {sidebar}
        </div>
    )
}

// /parallel 경로 접근 시
{@feed 의 page.tsx}
{@sidebar 의 page.tsx}
{parallel 의 page.tsx}

// /parallel/setting 경로 접근 시
{@feed/setting 의 page.tsx}
{@sidebar/setting 의 page.tsx} // 없으면 @sidebar 에서 이전에 렌더링한 page.tsx
{parallel/setting 의 page.tsx} // 없으면 parallel 에서 이전에 렌더링한 page.tsx

그래서 <Link/> 태그가 아닌 직접 접속 시 이전에 렌더링한 page 가 없으므로 404 PageNotFound
이 경우 404 대신 각 Slot 폴더에 default.tsx 파일 생성해주면 이게 보여짐

Intercepting Route

인터셉팅 라우트

특정 경로 접속 시 원래 렌더링되어야 할 페이지가 아닌 우리가 원하는 페이지를 대신 렌더링

Link, Router.push 와 같은 메소드로 페이지 이동 시에만 적용됨

app
    - (.)book/[id]
    - book/[id]

(경로) 을 붙임으로써 가로채라 여기서 (.)book/[id] 는 동일한 경로에 있음을 의미

만약 Modal 형식을 위해 인터셉팅 라우팅을 적용한다면, 해당 (.)book/[id] 의 page.tsx 가 백그라운드 배경으로 띄어짐 원래 탐색하고 있던 페이지가 병렬로 함께 백그라운드 배경으로 설정되어야함 (병렬 + 인터셉팅)

app
    - @modal
        - book/[id]
            - page.tsx
        - default.tsx
    - book/[id]
        - page.tsx
    - layout.tsx

// layout.tsx
export default function Layout({children, modal}){
    return (
        <>
            // book/1 경로 접근 시
            {children} // book/1 은 intercepting route
                       // children 도 결국엔 병렬라우팅처럼 동작하므로 이전 페이지인 page.tsx 나타남
            {modal}    // @modal/book/1
        </>
    )
}

서버 액션이란?

서버에서만 실행되는 비동기 함수를 브라우저가 직접 호출 조금 더 간결하고 편리하게 서버측 동작을 정의하는데 적합

async function createReviewAction(){
    "use Server"
    ...
}

return (
    <form action={createReviewAction}>
        ...
    </form>
)

브라우저에서 폼을 제출하면 서버 액션을 요청(요청 주소: 현재 브라우저 주소)하는 request 가 서버로 날라감 서버 액션은 컴파일 결과 특정한 해시값을 갖는 API 로써 생성 request header 에 Next-Action 에 현재 요청하고 싶은 서버 액션 해시값을 함께 요청

그럼 서버 액션의 응답은 어떻게 받아야하나요?

useActionState 는 form 태그에 대한 핸들링 지원

const [state, formAction, isPending] = useActionState(핸들링하려는 액션함수, 폼 상태 초기값);

return(
    <form action={formAction}>
        ...
    </form>
)

다양한 재검증 방식

next-cache 에서 제공하는 revalidatePath 를 이용하면 해당 경로를 재검증하게됨 서버측에서만 호출 가능하여 서버 페이지나 서버 액션에서만 호출 가능 풀 라우트 캐시와 데이터 캐시가 PURGE(삭제) 되고, 새로고침 후 접근하면 Dynamic 하게 그려짐

revalidatePath 에서 제공하는 여러 기법

1. 특정 경로의 모든 동적 페이지를 재검증

   revalidatePath("/book/[id]","page");

2. 특정 레이아웃을 갖는 모든 페이지 재검증

   revalidatePath("/(with-searchbar)","layout");

3. 모든 데이터 재검증

   revalidatePath("/","layout");

4. 태그 값으로 데이터 재검증

   await fetch(
   ...,
   {next: {tags: [`review-{bookId}`]}}
   )
   

revalidatePath(review-{bookId}); ```

Streaming 이란 강물, 하천을 의미하는 단어로 큰 데이터를 잘게 쪼개어 흐르듯이 보내주는걸 뜻함 영상뿐만 아닌 웹 서비스에서도 사용할 수 있게 Next.js 에서 스트리밍 기능을 제공

이전에는 페이지를 불러오는 과정에서 데이터 통신과 같은 시간이 다소 걸리는 작업이 있는경우 전체적으로 화면을 전달받는데 시간이 걸림

비동기 작업이 없는 즉시 화면에 렌더링 가능한 컴포넌트만 브라우저에게 보내준 다음에 비교적 늦게 작업이 완료되는 컴포넌트는 작업이 완료된 후에 보내줌

Dynamic 페이지에 주로 사용 async Page 에서만 지원 서로 다른 경로간의 탐색 시 최초 로드에 최적화된 방식

아래 형식처럼 같은 위치에 loading.tsx 를 만들어주면 끝
동일한 페이지내에서 이동(쿼리 스트링) 시 동작x
    - 이유는 클라이언트 라우트 캐시에 이미 RSC Payload 가 최초 받아올 때 저장되어 서버로 부터 받아오는게 아니므로

search
    - loading.tsx
    - page.tsx

※주의: 여기서 loading.tsx 는 마치 레이아웃처럼 해당 경로 아래 있는 모든 비동기 페이지를 스트리밍 되도록 설정

search
    - /setting
        - page.tsx // /setting 경로에 접근 시 페이지내에 비동기 동작이 완료될 때 까지 상위 loading.tsx 보여짐
    - loading.tsx
    - page.tsx

좀 더 세밀한 스트리밍을 위한 Suspense

loading.tsx 이외에 컴포넌트 단위로 비동기 작업 하고있는 컴포넌트에 대해 스트리밍을 적용시키고 싶다면 Suspense 사용

💡 Suspense 는 로드될때까지 로딩을 보여주는 컴포넌트로만 알고 있었는데, 스트리밍이라는 최적화 기법도 적용되는거였구나

에러 핸들링

try catch 문으로 모든 예외처리하기 번거로우니 error.tsx 사용 error.tsx 선언된 위치의 layout.tsx 까지만 그림

search
    - /setting
        - page.tsx // /setting 경로에 접근하여 에러 발생 시 상위 error.tsx 반환
    - error.tsx
    - page.tsx

error.tsx 에 "use client" 사용하는 이유 사전렌더링 시 서버에서 그려질때 적용되는거 이외에 하이드레이션 과정에서도 에러 발생 시 error.tsx 파일이 필요하므로

export default function Error({error, reset}:{error: Error, reset: ()=>void}){

// reset 은 서버측에서 실행한 서버컴포넌트는 다시 실행하지 않음
// 클라이언트에서 서버로부터 이미 받았었던 정보로 다시 렌더링함

// 그래서 router.refresh 로 백그라운드에서 서버컴포넌트 다시 받아와 적용하고
// reset 으로 에러바운더리 상태 초기화

    onClick={()=>{
        startTransition(()=>{
            router.refresh();
            reset();
        })
    }

}

Soft Navigation 이란?

router.refresh 는 소프트 네비게이션이다 브라우저는 현재 페이지를 유지한 채로, 변경이 필요한 부분만 동적으로 업데이트 (스크롤 위치, 입력 폼 내용 유지 가능)

startTransition 이란?

콜백함수 안에 정의된 UI 변경 작업을 일괄 적용시켜줌 즉, router.refresh 와 reset 이 한몸처럼 적용되도록

App Router 에서의 데이터 페칭

필요한 컴포넌트에서 필요한 데이터를 불러오자 중복 요청을 보내도 Request Memoization 으로 인해 한 번의 요청만 간다

fetch 를 통한 API 요청 시 아래 이미지와 같이 동작한다

API 콘솔 찍는 방법

// config.js

const nextConfig = {
    logging:{
        fetches:{
            fullUrl:true,
        }
    }
}

다양한 fetch 캐시 옵션들 (데이터 캐시)

no-store: 캐시 저장x force-cache: 캐시 저장 next:{revalidate:3}: 3초간 캐시 저장, 3초 이후 요청 들어오면 stale 상태로 변경되고 우선 이 stale 값으로 페이지 그리고나서 다음 요청 부터 최신 데이터로 그려짐

3초 경과 => 요청 => stale 값 => 요청 => 최신 데이터 즉, 2번째 요청부터 최신 데이터로 갱신되어 그려짐

next:{tags:["a"]}: 요청이 들어왔을 때 데이터를 최신화

※ 데이터 캐시

• 백엔드서버로부터 불러온 데이터를 거의 영구적으로 보관하기 위해 사용
• 서버 가동중에는 영구적으로 보관된다

Request Memoization

하나의 페이지를 이루고 있는 여러개의 컴포넌트에서 중복적으로 발생하는 요청들을 캐싱해서 한 번만 요청하도록 하나의 페이지를 렌더링하는 동안 중복된 API 요청을 캐싱하기 위해 존재 렌더링이 종료되면 모든 캐시가 소멸된다 아래 이미지는 no-store 기준

Full Route Cache

Next 서버 측에서 빌드 타임에 특정 페이지의 렌더링 결과를 캐싱하는 기능(SSG) Static Page 에 대해서만 Full Route Cache 적용 대부분의 페이지를 Full Route Cache 를 지원하는 Static Page 로 만들것을 권장

Dynamaic Page

• 캐시되지 않는 Data Fetching 사용하는 경우
• 동적 함수( 쿠키, 헤더, 쿼리스트링 )를 사용하는 경우

fetch 에 revalidate 가 선언된 경우 데이터 캐시 및 풀 라우트 캐시도 업데이트됨(ISR) 이것도 동일하게 지난 후 요청 시 stale 값을 보여주고, 이후 요청 시 갱신된 데이터 및 페이지 반환

빌드 에러 발생

// SearchBar.tsx

"use client"
...
const searchParams = useSearchParams();

빌드 과정에서 서버에서 사전 렌더링 시 서버 컴포넌트와 클라이언트 컴포넌트를 실행하여 페이지를 그리는데 쿼리스트링의 값은 알 수 없으므로 에러가 발생 그래서 아래와 같이 수정해주어야함 사전 렌더링에서 배제되고, 오직 클라이언트 측에서만 렌더링되도록

"use client"
...
<Suspense fallback={<div>Loading...</div>}>
    <SearchBar/>
</Suspense>

useSearchParams() 는 비동기 함수 즉, 클라이언트에서 쿼리스트링을 불러오는 때인 브라우저에 마운트 되는 시점 전까지 Suspense

generateStaticParams

Page Router 에서 SSG 형식을 위해 getStaticPaths 설정해준 것처럼 App Router 에서도 Static Page 를 위해 generateStaticParams 설정하면 빌드과정에서 설정한 Params 로 Static Page 생성

※주의: 만약 fetch 에 cache 설정이 되어있지 않더라도 이 페이지는 Static Page 로 생성됨

export function generateStaticParams(){
    return [{id:"1"},{id:"2"},{id:"3"}]
}

export default async function Page({params}){
    const {id} = params; // 1,2,3
    ...
}

위 코드는 1, 2, 3 이외에 Param 에 접근하면 Dynamic Page 로 생성되고, next 캐시에 등록되어 다시 접근 시 Static Page 로 반환

반대로 1, 2, 3 이외에 접근 시 404 페이지로 리다이렉트 시켜주고싶다면

export const dynamicParams = false;

🤔 궁금한점.. 슬러거의 경우 Dynamic Page 로 생성? generateStaticParams 설정 안해주면 Dynamic Page 인가? 그럼 next 서버에도 캐시된 페이지가 저장이 안되나?

라우트 세그먼트

풀 라우트 캐시를 설정하기 위해 데이터 캐싱 및 동적인 함수 사용 유무를 컴포넌트마다 확인해야하는 번거로움있음 그래서 나온 라우트 세그먼트. 페이지의 동작을 강제로 설정 하지만 권장되는 방식은 아님. 이미 빌드타임때 세세하게 확인해서 Dynamic, Static 으로 변환해주고 있기 때문

export const dynamic = ""

1. auto: 기본값, 아무것도 설정 안함
2. force-dynamic: 페이지를 강제로 Dynamic 설정
3. force-static: 페이지를 강제로 Static 설정
        - 쿼리 스트링과 같은 동적 함수가 선언된 경우 쿼리값은 항상 빈값으로 설정됨
        - 즉, 항상 같은 빈 결과 페이지가 반환됨
4. error: 페이지를 강제로 Static 설정
        - 데이터 캐싱x 및 동적함수 사용된 경우 빌드 에러 발생

클라이언트 라우터 캐시

브라우저에 저장되는 캐시 페이지 이동을 효율적으로 진행하기 위해 페이지의 일부 데이터 보관

공통된 레이아웃을 서버로부터 중첩으로 불러오지 않고, 클라이언트 라우터 캐시에 저장해두었다가 불러오는 형식 예를들어 공통 레이아웃에 new Date 를 선언한 경우 페이지 이동 시 시간초가 변동되지 않는다 (새로고침 시 초기화)

books/1/1 와 같은 중첩된 파라미터의 경우 [...id] 형식으로 폴더 생성 주의: books 경로와 같이 파라미터가 존재하지 않는 경우는 404 페이지 반환 해결법: 옵셔널 캐치 올 세그먼트로 [[...id]] 형식으로 폴더 생성

Layout

Layout 의 경우 아래 이미지와 같이 하위 경로에 대해서는 중첩 적용 된다

Route Group

(with-searchbar) 와 같은 형식으로 폴더 생성 경로상에는 아무런 영향 끼치 않으며 Layout 에 대해 동일한 적용이 가능

React Server Component

Page Router 에서 JS Bundle 에 상호작용이 필요없는 JS 파일들도 같이 포함되어 브라우저에서 한번 더 실행 될 필요 없다고 느낌 그래서 상호작용이 필요한 컴포넌트만 JS Bundle 에 포함시키자 그러면 Bundle 용량도 줄고 TTI 시간도 단축되지 않을까? 대부분의 페이지를 서버 컴포넌트로 생성하자

• 서버 컴포넌트: 서버 측 사전렌더링 시에만 딱 1번 실행
• 클라이언트 컴포넌트: 서버 측 사전렌더링 및 하이드레이션 때 실행되어 총 2번

클라이언트 컴포넌트에서 서버 컴포넌트는 import 할 수 없다

이유는 위에 설명했듯이 JS Bundle 에는 상호작용에 필요한 파일만 있고, Bundle 파일로 하이드레이션 과정을 거치고 한번 더 클라이언트 컴포넌트가 호출될텐데 여기서 import 된 서버 컴포넌트는 Bundle 에 포함되어 있지 않으므로

이런 문제가 빈번히 발생하다보니 Next 에서는 import 된 서버 컴포넌트의 경우 자동으로 클라이언트 컴포넌트로 변환함

편법: 클라이언트 컴포넌트에서 children 형식으로 서버 컴포넌트 받으면 문제 없음

서버 컴포넌트에서 클라이언트 컴포넌트로 직렬화 되지 않은 props 는 전달 불가능

함수와 같은 직렬화 불가능한 값은 props 로 전달이 안된다 서버에서 사전렌더링 되는 방식을 좀 더 살펴보자면 서버 컴포넌트만 우선 RSC Payload 형식으로 변환됨 RSC Payload 는 직렬화된 데이터로 되어있음 이 과정에서 함수도 직렬화되어있을텐데 함수는 직렬화로 표현 안되므로 에러

※ RSC Payload

• React Server Component 의 순수한 데이터 (직렬화한 결과물)
  • 서버 컴포넌트 렌더링 결과(마크업과 유사한)만 포함되어 있어 결과물 안에 서버 코드는 노출 x
  • 연결된 클라이언트 컴포넌트들의 위치 포함
  • 클라이언트 컴포넌트에게 전달하는 props 값 포함

페이지 이동의 경우 Network탭

최초 페이지 접근하여 사전 렌더링시 서버 컴포넌트 먼저 실행되어 RSC Payload 값으로 변환되고, 클라이언트 컴포넌트 실행된 결과값과 합쳐져 html 페이지 생성되고 클라이언트로 전달 이후 하이드레이션을 위해 JS Bundle 추가로 클라이언트로 전달

다른 경로로 이동 시 index.html 파일을 또 생성하여 주는게 아닌 이동하는 페이지의 RSC Payload 와 JS Bundle 을 서버로부터 받아 CSR 처럼 렌더링해줌

테스트는 빌드 파일로 해야 확인 가능

<Link/>, router.~

(프리페칭이 적용 안되어있다면) 링크 눌러서 해당 페이지로 이동할 때 RSC Payload, JS Bundle 받아옴

(프리페칭 적용 되어있다면) 링크 누르기 전에 이미 링크에 해당하는 페이지들이 Static 인 경우 RSC Payload, JS Bundle 받아옴 Dynamic 인 경우 RSC Payload 만 받고 페이지 이동 하고 나서 JS Bundle 받음

프롬프트창 +버튼 > Knowledge 가이드 라인으로 앞으로 모든 요청에 대해 아래 사항을 준수해달라고 설정

Edit 버튼 클릭 시 DOM 요소를 선택할 수 있게되고, 해당 DOM 요소에 대해 프롬프트 입력하여 수정 가능

Google AI Studio 의 System Instructions 에 구글 스프레드 시트을 위한 초기 가이드라인 설정

Google SpreadSheet 새 문서 만들고 상단에 설정에서 Apps Script 설정 Apps Script: docs, spread, drive 등 여러 서비스들을 코드로 자동화 작성할 수 있게하는 공간

AI Studio 에서 나온 GAS 코드를 붙여넣고 저장 및 우측 상단 새 배포 클릭 배포된 링크를 AI Studio 에 결과 코드중 GOOGLE_URL 코드영역에 링크 붙여넣기 해당 코드를 Lovable 프롬프트에 복붙 후 Edit 버튼 클릭하여 폼 영역 클릭 후 프롬프트 전송 이제 해당 폼에서 전송 시 구글 스프레드 시트에 내용 추가됨

Bolt.new 로 크리에이터 후원 갤러리 만들기

github 에 올린 이미지를 cnd 형식으로 빠르게 불러오기위해 jsdelivr 사용 후원은 buymeacoffee 사용 웹사이트 생성은 bolt.new 사용

v0 와 Notion API를 사용하여 애드핏 블로그 만들기

v0 에서 프롬프트 입력하여 사이트 생성 code 모드 클릭 시 직접 파일에 들어가 수정 가능

Notion 에서 API Key 생성 후 env.local NOTION_API_KEY 부분에 붙여넣기 내 DB템플릿 에 들어가서 설정 > 연결 > 생성한 API Key 연결 그리고 DB 템플릿 URL 의 중간 부분에 키값을 NOTION_DATABASE_ID 부분에 붙여넣기 배포 진행 시 vercel 에서 진행되고, vercel 에서 환경변수 세팅해야 정상 동작 카카오 에드핏에 설정 후 심사

Orchids 와 latpeed로 나만의 지식 상품 만들고 수익화하기

Gemini 를 사용해 주제에 대한 프롬프트 정보를 얻은 후 해당 정보 딥 리서치 활성화 후 검색

Orchids: 디자인에 조금 더 신경 쓴 웹사이트 생성

• Lovable 과 동일하게 visual edit mode 클릭 시 DOM 요소에 대해 프롬프트 입력하여 수정 가능 추가로 이미지 변경이나 텍스트를 직접 GUI 로 제공하여 편리

latpeed: pdf, 전자책과 같은 매체를 상품으로 사고 팔 수 있는 사이트

Mocha 로 유행하는 테스트 서비스 만들고 쿠팡 파트너스로 수익화하기

Mocha: Lovable, v0, Orchids 와 같은 웹사이트 생성툴이며, 이것 역시 동일한 기능들 제공

Zero-shot

• 예시없이 요청하는 경우

One-shot

• 예시를 하나 제공하는 경우

Few-shot

• 여러 예시를 제공하는 경우

생각의 사슬

AI 가 자신의 사고 과정을 단계별로 설명하도록 요청하는 기법 툴에서 생각중.. 이런 경우 추론 모델

잘게 나누어 질문하기

AI 가 해결해야 할 여러 개의 작은 하위 문제로 나누어 단계별로 요청하는 기법

컨텍스트 제공하기

작업과 관련된 최대한 많은 정보 제공

Tip)

"이 작업을 완벽하게 수행하기위해 추가로 필요한 정보가 있다면, 나에게 질문해줘" AI 가 스스로 부족한 정보를 파악하고 역으로 질문하게 만드는 사용 방법

AI 에게 질문을 만들게 하기

AI 에게 직접적으로 답을 요구하는 대신 "이 문제를 해결하기 위해 내가 너에게 어떤 질문을 해야 할까?" 또는 "내 질문을 어떻게 더 효과적으로 만들 수 있을까?" 라고 물어보기

구글의 5단계 프롬프트 프레임워크 (TCREI)

어떤 생성형 AI 도구에서든 통용되는 가장 강력하고 기본적인 공식 TCREI: 신중하게 정말 훌륭한 입력을 만든다

<div> 와 <span> 는 요소에 아무런 의미가 없음 사이트에 <div> 와 <span> 이 많다는 것은 적절하게 작성하고 있지 않다는 것 다른 적절한 HTML 요소를 사용할 수 없을 때 마지막으로 선택하는 태그임

header 와 footer

<header> 도입부, 헤딩, 헤딩 그룹, 목차, 검색, 로고, 글로벌 네비게이션 바 <footer> 저자, 저작권, 연락처, 관련 문서 <header> 와 <footer> 는 Sectioning Root(body) 안에 또는 Sectioning 콘텐츠(article, aside, nav, section) 감쌀 때 사용

Sectioning 콘텐츠

<section> 제목이 있는 주제별 콘텐츠 그룹 한 페이지에 카드 형식의 콘텐츠들이 나뉘어져 있을 때 각각 section 으로 선언 <article> 섹션 요소 중 독립적으로 배포 가능한 완결형 콘텐츠 뉴스 기사, 블로그 본문, 사용자 댓글 등 <header>, <footer> 요소를 내부에 사용하는 것은 선택사항

<nav> 현재 사이트 또는 일부를 링크하고 있는 주요 탐색 세션

<aside> 페이지의 주된 내용과 관련이 약해 구분할 필요가 있는 섹션 광고 배너 등

※ 모든 Sectioning 콘텐츠는 Heading ( h1 ~ h6 ) 콘텐츠를 포함하는 것을 강력하게 권장

main

<main> 문제의 핵심 주제 또는 애플리케이션의 핵심 기능과 직접 관련 있는 콘텐츠 영역을 의미 페이지마다 반복되지 않는 내용을 포함해야한다 하나의 페이지 안에서 하나의 <main> 요소만 표시할 수 있고, <header> , <footer> , Sectioning 콘텐츠의 자식이 될 수 없다 <body> , <div> 요소를 제외한 다른 요소의 자손이 될 수 없다

dialog

<dialog> 사용자와 상호작용하는 응용프로그램( 대화상자 )를 의미 팝업 등 <dialog> 가 열릴 때 키보드 초점이 <dialog> 안 쪽에 항상 고정 또한, 키보드 사용자가 Tab 키만을 시용해서 <dialog> 안 쪽에 있는 이동 가능한 컨트롤들을 탐색할 수 있어야 함

figure

<figure> 문서의 주된 흐름을 위해 참조하는 독립적인 완결형 요소 이미지, 도표, 코드 등의 내용물과 설명을 포함

<figure>
  <img/>
  <figcaption>설명</figcaption>
</figure>

mark

<mark> 독자의 주의를 끌기 위한 하이라이트 노란색 형관펜을 칠한 것 처럼 강조

address

<address> 보통 footer 의 안 쪽 저작권, 저자의 정보, 연락처 등을 나타내는 곳에 사용 접근성과 SEO 측면에서 좋음

ins 와 del

<ins> 추가한 내용 <del> 삭제한 내용 주로 쇼핑몰에서 기존 가격에 <del>로 줄 긋고 할인된 최종 가격에 <ins>

화면 낭독기 사용자도 웹 문서에서 heading 만 따로 추려서 음성으로 받은 다음에 관심있는 영역으로 이동해서 해당 영역을 음성으로 읽음

Outline

간결하게 추려낸 주요 내용. 윤곽 heading 과 section 으로 구성

chrome 의 HeadingMap extension 으로 heading 이 얼마나 잘 구성되어 있는지 한 눈에 확인 가능 올바른 작성법은 1부터 순차적으로 작성해야함 ex)) h1 없이 h2 사용 x

Heading

문서의 개요를 형성하는 필수 아이템 사이트와 화면 낭독기에 개요를 적극적으로 드러내는 방법

Title vs Heading

<title> 요소는 문서의 제목이며 한번만 사용 가능 <h*> 요소는 섹션의 제목이며 여러 번 사용 가능

Sectioning

개요의 범위를 명시적으로 지정 <article> 기사 본문, 맥락 독립적으로 배포 가능 <aside> 배너와 같은 페이지의 주요 내용이 아닌 부수적 내용 <nav> 사이트의 주된 탐색 메뉴 <section> 주제별로 나누거나 묶음

※ 여기서 주의점 HTML5 의 Outline 알고리즘은 웹 개발자가 heading 의 수준을 부적절하게 마크업을 했더라도 그것을 보정해주는 기능이 들어가 있음 ( 하지만 의존하면 안됨. 명세와 다르게 동작하기때문 )

<h1>A
<article>
  <h1>B
  <section>
    <h1>C

위 코드는 HTML5 명세의 의도대로라면 h1 A, h2 B, h3 C 로 계층이 나타내어져야 하지만, 브라우저/화면 낭독기에는 모두 같은 depth, 즉, h1 A, h1 B, h1 C 로 나타남

결론

heading 을 반드시 사용하고, heading 과 section 을 1:1 로 매핑하기 HTML5 개요 알고리즘에 의존하지 않기

분류 Metadata 콘텐츠

작성법 본문을 가장 잘 설명하는 키워드 중심으로 작성하며 페이지마다 구체적이고 고유한 키워드 사용. 반복하는 키워드는 최소화하며 구체적인 키워드를 앞으로 배치

구분자 구분자는 대시(-), 파이프(|), 콜론(:) 을 추천 언더바(_)는 인접 키워드를 하나로 연결하기 때문에 추천하지 않음

크롤링 Javascript 에 의해 동적으로 생성된 페이지 타이틀도 크롤링 한다

접근성 화면 낭독기 사용자는 웹 페이지 접속 시 가장 먼저, 페이지 타이틀을 음성으로 전달받음 Info. 화면 낭독기 사용자는 음성 낭독기 속도를 2배속 이상으로 들음 불필요한 정보들을 건너뛰기 위해서 따라서 페이지 타이틀은 간결하게 집어넣기

메타데이터

문서에 대한 정보를 제공

<html lang="ko"> 본문에서 사용중인 언어 검색 엔진이 특정 언어의 웹 페이지를 검색할 때 도움을 주며 화면 낭독기 사용자들이 웹 페이지를 읽을 때 어떤 음성 엔진을 사용해야하는지 힌트를 주기도 함

<meta charset="utf-8"> 한글뿐만 아니라 전세계 모든 국가의 언어를 웹 페이지에 문제없이 표시 할 수 있음

<meta name="description" content="A description of the page"> 검색 엔진의 검색 결과 화면에 노출되는 텍스트 검색 결과 화면에 사이트에 대한 설명을 원하는대로 표시하고 싶을 때

<meta name="keywords" content="free, anynone"> 많은 마케터들이 키워드에 사이트와 상관없는 정보를 집어넣음 그래서 구글 검색 엔진은 키워드를 신뢰하지 않음

<meta name="viewport" content="width=device-width, initial-scale=1"> 사이트가 모바일에서도 볼 수 있도록 최적화 되어있는지 제공 데스크탑에서는 브라우저 내에 보이는 사이트 영역만큼을 viewport 모바일에서는 문서의 전체 크기가 viewport 모바일에서도 화면에 보이는 영역만큼이 viewport 가 되기 위해 즉, 데스크탑과 일치시키기 위해서 width=device-width 선언. initial-scale=1 은 줌 비율이 1을 의미

실제 적용 사례 구글의 자체적인 알고리즘으로 사람들이 많이 클릭하는 페이지를 추려서 소개

최종 메타데이터 요약

What working group 에서 만들어지는 표준을 w3c 에 제안을하고, 검토하고 수락하는 과정을 거치는데 이 과정이 불필요하다 느껴져서 wwg 가 직접 표준을 만들고 유지보수하기를 원했음. 그러다가 2019년부터 wwg 에서 만든 표준이 공식적으로 채택되어 w3c 에서 유지보수하던 HTML5 표준은 폐기된 표준이 되었음

caniuse 는 웹 기술( HTML,css,js )들의 표준 명세를 브라우저가 실제로 어느정도로 구현했는지 호환성 정보를 확인할 수 있음

주요 HTML 콘텐츠 분류

HTML5 이전에 block 컨테이너라 부르던 류들은 주로 Flow 컨텐츠라 부름 inline 컨텐츠라 부르던 요소들은 Phrasing 컨텐츠로 대부분 들어가게됨

Flow 콘텐츠

body 에 포함할 수 있는 모든 요소 ( block, inline... )

Metadata 콘텐츠

주로 문서의 head 안에 들어가며 콘텐츠와 문서를 구조화 하는 요소를 의미 base, link, meta, noscript, script, style, template, title 일부 요소는 경우에 따라 Flow 콘텐츠 ( body 안에서 사용 가능한 script, template ..)

Heading 콘텐츠

h1, h2, h3, h4, h5, h6, hgroup

Sectioning 콘텐츠

이 콘텐츠는 암시적인 개요를 형성 article, aside, nav, section

Phrasing 콘텐츠

단락을 형성하는 구문 콘텐츠

Embedded 콘텐츠

외부 자원을 참조하는 콘텐츠 audio, canvas, embed, iframe, img, math, object, picture, svg, video

Interactive 콘텐츠

사용자와 상호 작용할 수 있는 콘텐츠 a, audio, button, details, embed, iframe, img, input, label, select, textarea, video

그 외 기타 콘텐츠

Palpable content

• 비어있지 않은, hidden 속성이 없는. 볼 수 있는 콘텐츠

Script-supporting element

• 렌더링하지 않지만 사용자에게 기능을 제공 ( script, template )

Transparent content models

• 투명 콘텐츠 모델 a, ins, del, object, video, audio, map, noscript, canvas 문서 노드에서 제거해도 문서가 유효하게 유지 ex)) a 태그안에 있는 요소들이 a 태그가 사라져도 구조가 유효함
• 자기 바로 부모의 콘텐츠 모델을 따라야함*

위 내용들을 함축한 퀴즈

네이티브 앱이란?

특정 플랫폼 ( IOS, Android ) 을 위해 최적화 되어 개발된 애플리케이션

장점

• 최적화된 코드로 빠른 성능을 제공
• 카메라, GPS 등 기기의 하드웨어에 접근 가능

단점

• 각 플랫폼마다 별도로 개발해야함
• 스토어에서 앱 심사 과정을 거쳐야함

웹앱이란?

웹 기술을 사용하여 개발하며, 별도의 다운로드 없이 모바일 브라우저를 통해 접근

장점

• 어떤 운영 체제에서도 실행 가능
• 하나의 코드베이스로 운영 가능

단점

• 네이티브 앱보다 느리며, 기기의 모든 기능을 사용할 수 없음

하이브리드 앱이란?

네이티브 앱 + 웹앱 웹 기술로 개발하여 네이티브 앱의 웹뷰를 통해 실행 ※ 웹뷰: 네이티브 애플리케이션에서 웹 페이지를 표시하기 위해 사용되는 컴포넌트

장점

• 하나의 코드베이스로 여러 플랫폼에서 운영 가능
• 카메라, GPS 등 네이티브 앱의 기능적 이점을 모두 활용 가능
• 앱 스토어를 통하지 않아도 웹 코드를 수정함으로써 변경 가능

단점

• 순수 네이티브 앱에 비해 렌더링 성능이 떨어짐

네이티브 앱 개발

React-Native 는 각 플랫폼의 네이티브 코드와 직접적인 상호작용 가능 안드로이드나 IOS 각각의 네이티브 UI 컴포넌트를 사용해서 구축 즉, 같은 코드를 사용해도 결과가 플랫폼에따라 다르게 나옴 일관성있는 UX 설계에 도움

왜 순수 네이티브 앱에 비해 느릴까?

React-Native 의 동작 매커니즘을 살펴보자:

1. Javascript 로 작성된 코드는 하나의 큰 번들 파일로 번들링된다.
2. 이 번들 파일은 애플리케이션이 실행될 때 Javascript Thread 에서 처리됨.
3. Bridge 가 Javascript 와 네이티브 코드간의 상호작용을 중재하며, Javascript 에서 발생한 명령을 네이티브 스레드로 전달하여 실제 네이티브 코드의 실행을 가능하게 함. 또한, 네이티브 코드가 실행한 결과를 Javascript 코드로 다시 전달한다.

위 과정에서 진행되는 통신 지연은 순수 네이티브 앱 보다 성능 저하가 발생

React Native CLI

React Native 프로젝트를 생성, 관리, 빌드하고 디버깅하는데 사용되는 표준 도구

• 자유도가 높아 React Native 를 100% 사용 가능
• 직접 네이티브 설정에 접근하고 수정할 수 있어서 복잡한 네이티브 기능이나 타사 네이티브 모듈을 쉽게 통합 가능
• 다양한 라이브러리 사용 가능
• 앱의 빌드 설정 및 종속성 등을 자세히 조정 가능

🔒 Next Auth

Next.js 애플리케이션에서 간단하고 확장 가능한 사용자 인증을 구현하기 위한 라이브러리 여러 인증 공급자와 세션 기반 및 JWT 기반의 인증을 지원

JWT 와 Session 방식의 차이

JWT: 클라이언트측에서 사용자 인증에 필요한 정보를 암호화 한 웹 토큰 저장

Session: 서버측에 사용자의 상태 정보를 저장하고 관리. 클라이언트는 세션 ID 만 가지고 있음

Prisma 를 사용하고 있다면 Prisma adapter 사용하여 손쉽게 연결 가능 Next-auth 회원가입 시 유저정보를 prisma 로 supabase에 저장 https://authjs.dev/getting-started/adapters/prisma

공용 인증 시작 전 중복된 계정으로 로그인하는경우 예외처리해주어야함 (e.g.) Gmail: test@gmail.com / Kakao: test@gmail.com allowDangerousEmailAccountLinking: true 추가해주기

32byte 의 랜덤문자열 생성하고 NEXTAUTH_SECRET 환경변수에 저장 [Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes([guid]::NewGuid().ToString() + [guid]::NewGuid().ToString())).Substring(0, 32)

구글 인증 시작하기

https://console.cloud.google.com/apis/credentials

1. OAuth 동의 화면탭 설정
2. 사용자 인증 정보탭에서 OAuth 클라이언트 ID 설정
3. 설정된 GOOGLE_CLIENT_ID 와 GOOGLE_CLIENT_SECRET 환경변수에 저장

네이버 인증 시작하기

https://developers.naver.com/main/

1. 네이버 로그인 배너 클릭 > 오픈 API 이용 신청 > 서비스 URL 에 호스트 추가
2. Callback URL 에 ~/api/auth/callback/naver 추가
3. 클라이언트 아이디 및 시크릿 키 NAVER_CLIENT_ID, NAVER_CLIENT_SECRET 환경변수에 저장

카카오 인증 시작하기

https://developers.kakao.com/ ※ Prisma Schema 의 Account 모델에 refresh_token_expires_in 필드를 옵셔널하게 추가해 주어야함

1. 내 애플리케이션 > 앱 설정 > 앱 키 REST API 키를 KAKAO_CLIENT_ID 환경 변수에 저장
2. 내 애플리케이션 > 제품 설정 > 카카오 로그인 > 보안 발급받고 코드를 KAKAO_CLIENT_SECRET 환경 변수에 저장하고 카카오 로그인탭 들어가서 활성화 및 redirect url ~/api/auth/callback/kakao 설정
3. 동의항목 탭에서 개인정보 수집할 정보들 설정 (email 은 받지 못해서 prisma schema email 부분 optional 로 줌)

api/auth/[...nextauth]/route.ts 전체 코드

export const authOption: NextAuthOptions = {
  session: {
    strategy: "jwt" as const,
    maxAge: 60 * 60 * 24,
    updateAge: 60 * 60 * 2,
  },
  adapter: PrismaAdapter(prisma) as any,
  providers: [
    GoogleProvider({
      clientId: process.env.GOOGLE_CLIENT_ID || "",
      clientSecret: process.env.GOOGLE_CLIENT_SECRET || "",
    }),
    NaverProvider({
      clientId: process.env.NAVER_CLIENT_ID || "",
      clientSecret: process.env.NAVER_CLIENT_SECRET || "",
    }),
    KakaoProvider({
      clientId: process.env.KAKAO_CLIENT_ID || "",
      clientSecret: process.env.KAKAO_CLIENT_SECRET || "",
    }),
  ],
  ],
  pages: {
    signIn: "/users/signin",
  },
  callbacks: {
    // useSession 의 data 에서 id 도 불러와지도록 설정
    session: ({ session, token }) => ({
      ...session,
      user: {
        ...session.user,
        id: token.sub,
      },
    }),
    jwt: async ({ user, token }) => {
      if (user) {
        token.sub = user.id;
      }
      return token;
    },
  },
};
const handler = NextAuth(authOption);

export { handler as GET, handler as POST };

// signInPage.tsx
signIn("google 혹은 naver 혹은 kakao", { callbackUrl: "/" });

로그인 유무 체크하여 url 접속 허용

//middleware.ts

export { default } from "next-auth/middleware";

// 로그인 정보 없이 /mypage 로 들어온 경우 로그인 페이지로 리다이렉트
export const config = { matcher: ["/mypage"] };