두 가지 방식

암묵적 연결 (Implicit Association)

label 태그가 input 을 감싸는 방식. id/for 없이 자동 연결.

<label>
    <input type="checkbox"> 가방
</label>

명시적 연결 (Explicit Association)

input 에 id 부여, label 의 for 속성으로 연결.

<input type="checkbox" id="cate_bag">
<label for="cate_bag">가방</label>

비교

각각 언제 쓰나

암묵적 방식이 적합한 경우

• 체크박스/라디오 + 텍스트가 나란히 붙어있는 기본 폼
• PHP/JS 로 동적으로 여러 개 생성하는 경우 (id 관리 부담 제거)
• 별도 커스텀 디자인 없이 기본 브라우저 체크박스 사용

<!-- PHP 동적 생성 예시 -->
<?php while($row = fetch()) { ?>
    <label>
        <input type="checkbox" name="item_<?=$row['id']?>"> 
        <?=$row['name']?>
    </label>
<?php } ?>

명시적 방식이 적합한 경우

• input 과 label 이 DOM 상 떨어져 있어야 하는 레이아웃
• 접근성 심사 대상 공공기관/정부 사이트 (WCAG 엄격 준수)

<input type="checkbox" id="agree">
<label for="agree">동의합니다</label>

커스텀 체크박스

두 방식 모두 커스텀 체크박스 구현 가능. 원리는 동일 (CSS + 인접 형제 선택자).

명시적 방식

<div class="custom-check">
    <input type="checkbox" id="agree">
    <label for="agree">동의합니다</label>
</div>

.custom-check input { display: none; }
.custom-check label::before {
    content: '';
    display: inline-block;
    width: 18px; height: 18px;
    border: 2px solid #ccc;
    border-radius: 3px;
    vertical-align: middle;
    margin-right: 6px;
}
.custom-check input:checked + label::before {
    background: #169dab;
    border-color: #169dab;
}

암묵적 방식

<label class="custom-check">
    <input type="checkbox">
    <span>동의합니다</span>
</label>

.custom-check input { display: none; }
.custom-check span::before {
    content: '';
    display: inline-block;
    width: 18px; height: 18px;
    border: 2px solid #ccc;
    border-radius: 3px;
    vertical-align: middle;
    margin-right: 6px;
}
.custom-check input:checked + span::before {
    background: #169dab;
    border-color: #169dab;
}

차이점

핵심 제약

CSS + 선택자는 뒤쪽 형제만 선택 가능. input 이 반드시 텍스트(span/label) 보다 앞에 와야 한다.

<!-- 올바름: input 먼저 -->
<label><input type="checkbox"><span>텍스트</span></label>

<!-- 안 됨: span 먼저 → CSS 제어 불가 -->
<label><span>텍스트</span><input type="checkbox"></label>

실무 트렌드

• 대부분 암묵적 방식 사용 (기본 폼)
• 커스텀 UI 컴포넌트 라이브러리 (MUI, Ant Design 등) 는 내부적으로 명시적 방식 사용
• React/Vue 컴포넌트에서는 자동 id 생성 유틸(useId 등) 로 명시적 방식 편하게 처리

주의사항

암묵적 방식에서 흔한 실수

<!-- 잘못: label 안에 여러 input -->
<label>
    <input type="checkbox"> 옵션A
    <input type="checkbox"> 옵션B
</label>

<!-- 올바름: input 하나당 label 하나 -->
<label><input type="checkbox"> 옵션A</label>
<label><input type="checkbox"> 옵션B</label>

명시적 방식에서 흔한 실수

<!-- 잘못: id 중복 -->
<input type="checkbox" id="item"> <label for="item">A</label>
<input type="checkbox" id="item"> <label for="item">B</label>

<!-- 올바름: id 유일 -->
<input type="checkbox" id="item_1"> <label for="item_1">A</label>
<input type="checkbox" id="item_2"> <label for="item_2">B</label>

결론

둘 다 표준이고 둘 다 접근성 충족. 커스텀 체크박스도 둘 다 가능. 프로젝트 상황에 맞게 선택하면 된다.

옛날엔 a 안에 button 넣고 JS 로 stopPropagation 했는데, HTML 표준 위반이라는 걸 알게 됐고 모던 표준 (Stretched Link) 으로 정리해 둠.

카드나 영역 전체를 클릭 가능하게 만들 때, a/button 으로 컨텐츠를 감싸지 않고 별도 요소를 만들어 absolute 로 영역 전체 덮는 패턴.

1. 왜 필요한가

리스트 카드, 메뉴 항목, 알림 같은 UI 에서 영역 전체가 클릭 가능해야 사용자 경험이 좋음.

• 모바일에서 좁은 텍스트만 탭 영역이면 누르기 어려움
• 카드 어디 눌러도 동일 동작이 직관적

2. 옛날 방식 - 카드 전체를 a 로 감싸기

<a href="/product/1">
    <article class="card">
        <img>
        <h3>상품명</h3>
        <p>가격</p>
        <button>찜</button>
    </article>
</a>

문제 - HTML 표준 위반

<a> 의 content model 은 "Transparent, but there must be no interactive content descendant". 즉 a 안에 a, button, input, select 같은 인터랙티브 요소를 두면 표준 위반.

3. 옛 회피 방식 - JS stopPropagation + z-index

<a href="/product/1">
    <article class="card">
        <img>
        <h3>상품명</h3>
        <button onclick="event.stopPropagation()">찜</button>
    </article>
</a>

button 클릭이 부모 a 까지 이벤트 전파되지 않게 JS 로 막음.

문제

4. 모던 표준 - Stretched Link

크게 두 가지 방식. 둘 다 표준 패턴, 케이스 따라 선택.

방식 A - 가상요소 패턴

a 자체는 의미 있는 텍스트 (상품명 등) 를 그대로 표시하고, ::after 가상요소가 부모 영역 전체 덮음. Bootstrap 4.3 (2020) 부터 공식 stretched-link 헬퍼.

마크업

<article class="card">
    <img>
    <h3>
        <a href="/product/1" class="stretched-link">스튜디오 메신저</a>
    </h3>
    <p>2,377,000</p>
    <button class="like">찜</button>
</article>

CSS

.card {
    position: relative;        /* stretched-link::after 의 기준 */
}

.stretched-link::after {
    content: "";
    position: absolute;
    inset: 0;                  /* 부모 카드 전체 덮음 */
    z-index: 1;
}

.like {
    position: relative;        /* z-index 적용 위해 필요 */
    z-index: 2;                /* stretched-link 위로 (별도 클릭 가능) */
}

핵심

• <a> 자체는 자기 자리에서 시각 텍스트 (상품명 등) 그대로 표시
• ::after 가상요소가 부모 카드 전체 덮어 클릭 영역 확장
• 시각: a 텍스트 평소처럼 보임 + 카드 전체 클릭 가능
• 자식 button/a 는 z-index 더 높게 두면 별도 클릭 가능

Bootstrap 5 의 stretched-link 실제 코드

.stretched-link::after {
    position: absolute;
    top: 0;
    right: 0;
    bottom: 0;
    left: 0;
    z-index: 1;
    content: "";
}

→ Bootstrap 이 정확히 이 방식. inset: 0 대신 top/right/bottom/left 분리 (구 브라우저 호환).

장점

방식 B - 빈 a 패턴

가상요소 대신 빈 a 자체를 absolute 로 만드는 방식. 동일한 효과지만 a 가 빈 태그가 됨. feelavel 등 실제 회사 코드에서도 흔히 사용.

<article class="card">
    <img>
    <h3>스튜디오 메신저</h3>
    <p>2,377,000</p>
    <a href="/product/1" class="stretched-link"></a>     <!-- 빈 a -->
</article>

.stretched-link {
    position: absolute;
    inset: 0;
    z-index: 1;
}

두 방식 비교 (둘 다 표준)

어느 걸 선택?

→ 둘 다 표준이고 광범위 사용. 케이스 따라 선택.

5. 빈 a/button 의 접근성 보완 - sr-only / aria-label

컨텍스트: 4-2 변형 (빈 a) 또는 6번 Stretched Button (빈 button) 사용 시 보완책. 정통 방식 (4번 가상요소 + 의미 텍스트) 사용 시 불필요.

빈 <a></a> 또는 <button></button> 은 시각 사용자에겐 잘 동작하지만 스크린리더 사용자에겐 의미가 약함.

빈 a 의 문제

<article class="card">
    <img>
    <h3>스튜디오 메신저</h3>
    <p>2,377,000</p>
    <a href="/product/1" class="stretched-link"></a>
</article>

스크린리더가 이 a 를 읽을 때:

• "Link" (정확한 의미 모름)
• 또는 href URL 자체를 읽음 ("product 1" 등)

시각 사용자는 카드 컨텐츠 보고 "이건 상품 카드 링크" 이해 가능. 하지만 스크린리더 사용자는 그 연결이 약함.

보완 방법 1 - sr-only 텍스트

<a href="/product/1" class="stretched-link">
    <span class="sr-only">스튜디오 메신저 상품 상세보기</span>
</a>

.sr-only {
    position: absolute;
    width: 1px;
    height: 1px;
    padding: 0;
    margin: -1px;
    overflow: hidden;
    clip: rect(0, 0, 0, 0);
    white-space: nowrap;
    border: 0;
}

sr-only (screen reader only) = 시각 hide + 스크린리더 인식. 거의 0 사이즈로 줄여서 시각상 안 보이지만 DOM 에 존재.

보완 방법 2 - aria-label

<a href="/product/1" class="stretched-link" aria-label="스튜디오 메신저 상품 상세보기"></a>

aria-label 속성으로 스크린리더용 라벨 제공.

두 방법 비교

→ 상황 따라 골라쓰기. 빈 a/button stretched link 쓸 땐 둘 중 하나 반드시 사용.

6. button 버전 - Stretched Button

페이지 이동이 아니라 모달/액션이 필요하면 a 대신 button.

<div class="dropdown">
    <h2>현재 옵션 이름</h2>
    <p>설명 텍스트</p>
    <button class="stretched-btn" aria-label="옵션 변경"></button>
</div>

.dropdown { position: relative; }

.stretched-btn {
    position: absolute;
    inset: 0;
    z-index: 1;
    background: transparent;
    border: 0;
    cursor: pointer;
}

컨셉 동일. a 와 button 만 다름.

7. 자식 안에 또 다른 클릭 요소 두기

stretched-link 위에 다른 button/a 두려면:

.stretched-link { z-index: 1; }

.child-btn {
    position: relative;        /* z-index 적용 위해 필요 (정적 박스에 z-index 무효) */
    z-index: 2;                /* stretched-link 위로 */
}

핵심

• 자식에 position: relative 안 주면 z-index 적용 안 됨 (static 박스는 z-index 무시)
• z-index 더 높게 두면 클릭이 위에서 잡힘

8. 한계 / 주의점

9. 역사

10. 참고

• Bootstrap stretched-link: https://getbootstrap.com/docs/5.0/helpers/stretched-link/
• HTML Spec a content model: https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-a-element
• MDN position absolute: https://developer.mozilla.org/en-US/docs/Web/CSS/position
• MDN inset: https://developer.mozilla.org/en-US/docs/Web/CSS/inset

PHP 가 URL 의 정보를 받아서 변수에 담는 패턴 정리

1. URL 이란?

https://example.com/page.php?cate_no=101&keyword=메신저
                              └────────┘ └──────────┘
                              파라미터 1   파라미터 2

• ? 뒤부터 = 쿼리스트링 (query string)
• & 로 여러 파라미터 구분
• 형식: 이름=값

2. PHP 가 URL 의 값 받는 법: $_GET

PHP 는 URL 의 파라미터를 자동으로 읽어서 $_GET 이라는 배열에 담아둠.

// URL: ?cate_no=101&keyword=메신저
$_GET['cate_no']    // → "101"
$_GET['keyword']    // → "메신저"

비유: URL = 편지봉투, $_GET = 편지 내용을 PHP 가 자동으로 꺼내 담아둔 메모지

3. 값이 있는지 체크: isset()

URL 에 그 파라미터가 없으면 $_GET['cate_no'] 자체가 존재하지 않음 → 그냥 쓰면 에러.

isset($_GET['cate_no'])  // 있으면 true, 없으면 false

비유: "이 메모지에 cate_no 라는 항목이 있나요?" 확인

4. 짧은 if-else: 삼항 연산자 (? :)

$a = (조건) ? (참일 때 값) : (거짓일 때 값);

긴 if-else 를 한 줄로 줄임:

// 긴 버전
if (isset($_GET['cate_no'])) {
    $cate_no = $_GET['cate_no'];
} else {
    $cate_no = 0;
}

// 짧은 버전 (같은 의미)
$cate_no = isset($_GET['cate_no']) ? $_GET['cate_no'] : 0;

비유: "있으면 A, 없으면 B"

5. 타입 강제 변환: (int), (string) 등

URL 에서 받은 값은 항상 문자열. 숫자처럼 쓰려면 강제로 변환.

$_GET['cate_no']           // → "101"   ← 문자열 (따옴표 있음)
(int)$_GET['cate_no']      // → 101     ← 진짜 숫자

왜 필요? SQL 쿼리에 숫자만 들어가야 안전 (보안 + 정확성).

$cate_no = (int)$_GET['cate_no'];  // 숫자 강제 변환
// "101abc" → 101 (뒤 abc 무시)
// "메신저" → 0   (숫자 아니면 0)

비유: "이거 숫자로 받아라" 강제 명령

6. 양쪽 공백 제거: trim()

사용자가 실수로 검색어 앞뒤에 공백 넣을 수 있음. trim() 으로 제거.

trim("  메신저  ")  // → "메신저"

7. 조립: 실전 패턴

지금까지 배운 거 다 합치면:

// URL 의 cate_no 받아서 안전하게 처리
$cate_no = isset($_GET['cate_no']) ? (int)$_GET['cate_no'] : 0;
//          └─────────────────┘   └──────────────────┘   └┘
//          (1) 있는지 체크         (2) 숫자로 변환        (3) 없으면 default

// keyword 도 비슷 (단 문자열은 trim 까지)
$keyword = isset($_GET['keyword']) ? trim($_GET['keyword']) : '';

8. 한 줄 요약

$변수 = isset($_GET['이름']) ? (타입)$_GET['이름'] : 기본값;

9. 모던 PHP 에선?

PHP 7+ 에선 더 짧은 문법 (?? null coalescing 연산자) 가능:

// PHP 7+
$cate_no = (int)($_GET['cate_no'] ?? 0);

// PHP 4.4 (회사 환경) — 위 문법 안 됨, 풀어 써야 함
$cate_no = isset($_GET['cate_no']) ? (int)$_GET['cate_no'] : 0;

→ Laravel 같은 framework 쓰면 더 짧음:

$cate_no = $request->integer('cate_no', 0);

framework 가 isset/타입변환/default 다 알아서 해줌.

10. 다양한 예시 (실전 시나리오)

같은 패턴이 여러 사이트/페이지에서 어떻게 쓰이는지.

예시 1. 게시판 페이지네이션

URL: /board.php?page=3

$page = isset($_GET['page']) ? (int)$_GET['page'] : 1;
// → URL 에 page=3 → $page = 3 (3번째 페이지 보여주기)
// → URL 에 page 없으면 → $page = 1 (첫 페이지 default)

예시 2. 쇼핑몰 카테고리 + 정렬

URL: /shop.php?category=fashion&sort=price

$category = isset($_GET['category']) ? trim($_GET['category']) : 'all';
$sort     = isset($_GET['sort'])     ? trim($_GET['sort'])     : 'reg';
// → category=fashion → 패션 카테고리만
// → sort=price → 가격순 정렬

예시 3. 검색 결과

URL: /search.php?q=메신저&type=goods

$keyword = isset($_GET['q'])    ? trim($_GET['q'])    : '';
$type    = isset($_GET['type']) ? trim($_GET['type']) : 'all';
// → q=메신저 → "메신저" 검색
// → type=goods → 상품에서만 검색

예시 4. 사용자 프로필

URL: /user.php?id=123

$user_id = isset($_GET['id']) ? (int)$_GET['id'] : 0;

if ($user_id === 0) {
    // 잘못된 접근 → 메인페이지 redirect 같은 처리
    header('Location: /');
    exit;
}
// → id=123 → 123번 사용자 프로필 보여주기

예시 5. 다중 옵션 (체크박스 등)

URL: /filter.php?colors[]=red&colors[]=blue&colors[]=green

$colors = isset($_GET['colors']) ? $_GET['colors'] : array();
// → $colors = array('red', 'blue', 'green')
// → URL 에 [] 붙으면 PHP 가 자동으로 배열로 받음

예시 6. 가격대 필터

URL: /goods.php?min=10000&max=50000

$min_price = isset($_GET['min']) ? (int)$_GET['min'] : 0;
$max_price = isset($_GET['max']) ? (int)$_GET['max'] : 999999999;
// → min=10000, max=50000 → 1만원~5만원 사이
// → 둘 다 없으면 전체 (0 ~ 매우 큰 수)

11. 다음에 코드 볼 때

회사 PHP 페이지 어디서든 위 패턴 보면:

"아, URL 의 값 안전하게 받아서 변수에 담는 거구나"

라고 바로 이해 가능.

input의 :checked 상태랑 CSS 형제 선택자(+, ~)만으로 JS 없이 토글, 탭, 모달, 아코디언을 만들 수 있다. input을 숨기고, label을 클릭 영역으로 쓰고, :checked에 따라 형제 요소 스타일을 바꾸는 게 핵심. 체크박스는 ON/OFF, 라디오는 택일 상황에 쓰고, 패턴은 총 7가지 정리했다.

1. 핵심 원리

[1] input (시각 hide)
[2] label (실제 클릭 영역, for=input id 매칭)
[3] :checked + sibling selector → 형제 요소의 스타일 변경

핵심 selector

input 시각 hide 방법 비교

2. Checkbox vs Radio — 어떤 걸 쓸까

둘 다 위 핵심 원리(:checked + sibling)로 동일하게 동작하지만, 의미(시멘틱)가 다름.

차이

선택 기준 (한 줄 가이드)

본질이 boolean(켜다/끄다)이면 checkbox, 둘 이상의 명시적 옵션 중 택일이면 radio.

예시

둘 다 가능한 경우

"전체/중고" 같이 두 옵션이라면 둘 다 구현 가능:

<!-- radio (택일이 명확) -->
<input type="radio" name="filter" value="all">전체
<input type="radio" name="filter" value="used">중고

<!-- checkbox (단순화 — "중고만 보기" 의미) -->
<input type="checkbox" name="used_only">중고만 보기

→ form 데이터 처리 방식이 다름.

• radio: ?filter=all 또는 ?filter=used (둘 다 명시 값)
• checkbox: 체크 시 ?used_only=on, 미체크 시 파라미터 없음

의도에 따라 결정. 둘 다 명시 값으로 보내야 하면 radio, 미체크가 기본 의미면 checkbox.

3. 장단점

장점

• JS 없이 동작 (가벼움, 의존성 없음)
• form submit 자동 처리 (input 값이 form data에 포함)
• 접근성 (키보드 탐색, 스크린리더 — opacity 방식 hide 시)
• 브라우저 호환성 좋음 (모든 모던 브라우저)

단점

• 마크업 순서 제약: sibling selector라서 input → label → target 순서 필요
• target은 input의 형제(sibling) 만 가능 (자식 X, 부모 X) — :has() 로 일부 우회 가능
• 복잡한 인터랙션은 결국 JS 필요

4. 패턴 7가지

패턴 1. 토글 스위치 (ON/OFF)

iOS 스타일 토글.

언제 쓰나: 알림 ON/OFF, 다크모드, 설정값 토글

<div class="toggle">
    <input type="checkbox" id="alarm" name="alarm" class="toggle__input">
    <label for="alarm" class="toggle__label">
        <span class="toggle__knob"></span>
    </label>
</div>

.toggle__input { position: absolute; opacity: 0; pointer-events: none; }

.toggle__label {
    position: relative; display: inline-block;
    width: 40px; height: 24px;
    background: #ccc; border-radius: 999px;
    cursor: pointer; transition: background 0.25s;
}

.toggle__knob {
    position: absolute; top: 2px; left: 2px;
    width: 20px; height: 20px;
    background: #fff; border-radius: 50%;
    transition: transform 0.25s;
}

/* :checked 시 */
.toggle__input:checked + .toggle__label { background: #169DAB; }
.toggle__input:checked + .toggle__label .toggle__knob { transform: translateX(16px); }

패턴 2. 세그먼티드 컨트롤 (radio 택일)

탭처럼 보이지만 본질은 radio.

언제 쓰나: 필터 (전체/중고), 정렬 옵션, 탭 메뉴

<div class="segment">
    <input type="radio" name="filter" id="all" value="all" checked>
    <label for="all">전체</label>
    <input type="radio" name="filter" id="used" value="used">
    <label for="used">중고</label>
    <span class="segment__indicator"></span>
</div>

.segment { position: relative; display: inline-flex; padding: 2px;
    background: #fff; border: 1px solid #ddd; border-radius: 999px; }

.segment input { position: absolute; opacity: 0; pointer-events: none; }

.segment label { position: relative; z-index: 1; padding: 6px 16px;
    color: #999; cursor: pointer; transition: color 0.2s; white-space: nowrap; }

.segment input:checked + label { color: #fff; }

.segment__indicator { position: absolute; top: 2px; bottom: 2px; left: 2px;
    width: calc(50% - 2px);
    background: #222; border-radius: 999px;
    transition: transform 0.25s; pointer-events: none; }

/* "중고" 체크 시 indicator 우측으로 */
.segment input[value="used"]:checked ~ .segment__indicator {
    transform: translateX(100%);
}

핵심 함정 — indicator 가 label 너비와 안 맞을 때

두 label 자연 너비가 다르거나 (글자 길이 차이), flex: 1 안 주면 indicator 가 label 너비랑 어긋남.

해결 두 가지:

1. container width 명시 + label flex: 1 (옵션 고정일 때 권장)

.segment {
    width: 84px;
    height: 32px;
    box-sizing: border-box;
}
.segment label { flex: 1; }                    /* 균등 50% */
.segment__indicator { width: calc(50% - 2px); } /* container padding 보정 */

장점: 디자인 시안과 정확 매칭, indicator 완벽 정렬 단점: 컴포넌트마다 width/height 매번 명시

2. 가변 (label padding으로 사이즈) (옵션 동적일 때)

.segment label { flex: 1; padding: 7px 14px; }

장점: 글자 길이/옵션 추가 시 자동 대응, padding만 조정 단점: 디자인 시안 정확 매칭 미묘 차이 가능

옵션이 N개일 때 (3개 이상)

flex: 1 은 자식 수에 따라 균등 분배 (반반 한정 X). 옵션 N개면 각 100/N %.

.segment label { flex: 1; }                              /* 자동으로 100/N % 균등 */
.segment__indicator { width: calc(100% / 3 - 2px); }     /* 3개면 33.33% */

/* transform은 인덱스 × 100% */
.segment input[value="opt2"]:checked ~ .segment__indicator {
    transform: translateX(100%);
}
.segment input[value="opt3"]:checked ~ .segment__indicator {
    transform: translateX(200%);
}

비균등 비율 원하면 flex 값 다르게: flex: 1 vs flex: 2 → 1:2 비율.

패턴 3. 아코디언 / 펼치기

체크박스 toggle 로 컨텐츠 show/hide. (또는 HTML5 <details> 사용 가능)

언제 쓰나: FAQ, 약관 펼치기, 설정 그룹

<div class="accordion">
    <input type="checkbox" id="faq1" class="accordion__input">
    <label for="faq1" class="accordion__title">자주 묻는 질문 1</label>
    <div class="accordion__content">
        답변 내용입니다.
    </div>
</div>

.accordion__input { display: none; }   /* 아코디언은 display:none 무방 (form 데이터 의미 없음) */

.accordion__title { display: block; padding: 16px;
    background: #f5f5f5; cursor: pointer; }

.accordion__content {
    max-height: 0;                      /* 닫힌 상태 */
    overflow: hidden;
    transition: max-height 0.3s ease;
}

/* checked 시 펼침 */
.accordion__input:checked ~ .accordion__content {
    max-height: 500px;                  /* 충분히 큰 값 */
}

더 단순한 버전: HTML5 <details> + <summary> — 아예 input 없이도 됨.

패턴 4. 모달 / 팝업 열기·닫기

체크박스로 overlay show/hide. JS 없이 모달.

언제 쓰나: 햄버거 메뉴, 간단한 팝업, lightbox

<input type="checkbox" id="modal" class="modal__input">
<label for="modal" class="modal__open">팝업 열기</label>

<div class="modal__overlay">
    <div class="modal__box">
        팝업 내용
        <label for="modal" class="modal__close">X</label>
    </div>
</div>

.modal__input { display: none; }
.modal__overlay {
    display: none;
    position: fixed; top: 0; left: 0; right: 0; bottom: 0;
    background: rgba(0,0,0,0.5); z-index: 1000;
}
.modal__input:checked ~ .modal__overlay { display: flex; }

패턴 5. 별점 평가

radio 5개 + label로 별. CSS만으로 별점 UI.

언제 쓰나: 리뷰 별점, 만족도 평가

<div class="rating">
    <input type="radio" name="rate" id="r5" value="5"><label for="r5">★</label>
    <input type="radio" name="rate" id="r4" value="4"><label for="r4">★</label>
    <input type="radio" name="rate" id="r3" value="3"><label for="r3">★</label>
    <input type="radio" name="rate" id="r2" value="2"><label for="r2">★</label>
    <input type="radio" name="rate" id="r1" value="1"><label for="r1">★</label>
</div>

.rating {
    display: inline-flex;
    flex-direction: row-reverse;        /* 우→좌 정렬 (호버/체크 ~로 좌측 별 채우기 위해) */
}

.rating input { display: none; }

.rating label {
    color: #ccc; font-size: 24px; cursor: pointer;
}

/* 체크된 별 + 그 좌측(=row-reverse 기준 ~) 모두 노란색 */
.rating input:checked ~ label,
.rating label:hover,
.rating label:hover ~ label {
    color: #ffc107;
}

패턴 6. 탭 컨텐츠 전환

radio + 탭별 컨텐츠 swap. JS 없이 탭.

언제 쓰나: 상품 상세 탭(상세/리뷰/Q&A), 카테고리 탭

<div class="tabs">
    <input type="radio" name="tab" id="tab1" checked><label for="tab1">탭1</label>
    <input type="radio" name="tab" id="tab2"><label for="tab2">탭2</label>

    <div class="tabs__content tab1">탭1 내용</div>
    <div class="tabs__content tab2">탭2 내용</div>
</div>

.tabs__content { display: none; }

#tab1:checked ~ .tab1,
#tab2:checked ~ .tab2 { display: block; }

단점: id 가 글로벌이라 페이지에 같은 패턴 여러 개 두기 까다로움. 컴포넌트 단위로 쓸 때는 JS가 더 깔끔.

패턴 7. 검색창 확장

체크박스 toggle로 input 펼치기.

언제 쓰나: 헤더 검색 아이콘 → 입력창 확장

<input type="checkbox" id="search-toggle" class="search__toggle">
<label for="search-toggle" class="search__icon">🔍</label>
<div class="search__form">
    <input type="text" placeholder="검색어 입력">
</div>

.search__toggle { display: none; }
.search__form {
    width: 0; overflow: hidden;
    transition: width 0.3s ease;
}
.search__toggle:checked ~ .search__form { width: 200px; }

5. 주의 사항

6. 참고

• MDN: <input type="checkbox">
• MDN: :checked pseudo-class
• MDN: Sibling combinators (+, ~)

문제 상황

CSS 파일명이 Main.css로 되어 있어 소문자 main.css로 바꾸려고 했다. 에디터나 탐색기에서 이름만 바꾼 뒤 Git 상태를 확인했는데, 변경사항 목록에 아무것도 잡히지 않았다.

왜 이런 일이 생기는가

Git은 기본적으로 파일명 대소문자 차이를 "변경"으로 보지 않는 설정이 적용되어 있다. 즉, Main.css와 main.css를 같은 파일로 취급해서 변경사항이 없다고 판단한다.

왜 위험한가

운영 서버에서는 대소문자가 다르면 완전히 다른 파일로 취급한다. 예를 들어 실제 파일이 Main.css인데 HTML에서 <link href="main.css">로 참조하면 로컬에서는 정상 로드되지만 서버에서는 파일을 찾지 못한다.

실제 파일명이 Main.css인 경우 기준

로컬에서는 잘 작동하던 페이지가 배포 후 CSS/JS가 깨지는 현상이 생긴다. 로컬에서 재현이 안 되기 때문에 원인을 찾기 어렵다.

해결 방법: git mv 명령어 사용

파일명 대소문자만 바꿀 때는 에디터나 탐색기에서 바꾸지 말고, 터미널에서 git mv 명령어로 변경한다.

git mv Main.css main.css
git commit -m "Main.css 파일명 소문자로 변경"
git push

이렇게 하면 Git이 파일명 변경을 정상적으로 인식한다.

git mv 실행 시 에러가 나는 경우

다음과 같은 에러가 발생할 수 있다.

fatal: renaming 'Main.css' failed: Invalid argument

이는 일부 환경에서 대소문자만 다른 두 파일명을 같은 파일로 인식해, 자기 자신으로의 이름 변경을 거부하기 때문이다. 이때는 임시 파일명을 거쳐 두 단계로 변경한다.

# 1단계: 임시 파일명으로 변경
git mv Main.css temp-main.css
git commit -m "임시 파일명 변경"

# 2단계: 최종 파일명으로 변경
git mv temp-main.css main.css
git commit -m "파일명 소문자로 변경"

git push

이미 에디터나 탐색기에서 바꿔버린 경우

이 상태에서는 git status에 아무 변경사항도 잡히지 않는다. Git이 파일명 변경을 감지하지 못했기 때문이다.

되돌리거나 별도 작업을 할 필요 없이, 그 상태 그대로 아래 명령어를 실행해본다.

git mv Main.css main.css

Git 내부 기록은 여전히 Main.css이므로 위 명령어가 그대로 처리되는 경우가 많다.

다만 환경에 따라서는 디스크상으로 이미 main.css로 바뀌어 있어 Main.css를 찾지 못한다는 에러가 발생할 수 있다. 이때는 고민하지 말고 곧바로 임시 파일명 2단계 방식으로 진행한다. 이 경우 디스크에 이미 존재하는 이름(main.css)부터 시작한다.

git mv main.css temp-main.css
git commit -m "임시 파일명 변경"

git mv temp-main.css main.css
git commit -m "파일명 소문자로 변경"

core.ignorecase 설정에 대해

Git에는 파일명 대소문자 구분 여부를 제어하는 core.ignorecase 옵션이 있다.

git config core.ignorecase false

이 값을 false로 바꾸면 에디터나 탐색기에서 이름만 바꿔도 Git이 변경사항으로 인식한다.

다만 기본값이 true로 되어 있는 데는 이유가 있다. 파일시스템 자체가 대소문자를 구분하지 않는 환경에서 이 설정을 강제로 켜면, 추적되지 않는 파일명 충돌이 발생하거나 동일 파일이 두 번 등록되는 등 예상치 못한 문제가 생길 수 있다.

따라서 팀 표준으로 권장하기보다는, 동작 원리를 이해한 사람이 필요할 때 선택적으로 쓰는 옵션 정도로 인지하는 편이 안전하다. 적용한다면 팀 전체가 사전 합의 후 동일하게 설정해야 한다.

예방 체크리스트

• 새 파일은 처음부터 소문자 + 하이픈 규칙을 따른다 (예: main-banner.css)
• 대문자가 섞인 파일명을 발견하면 에디터/탐색기 대신 git mv를 사용한다
• HTML/CSS/JS에서 파일 경로를 작성할 때 실제 파일명과 대소문자를 정확히 일치시킨다
• 커밋 전 git status로 파일명 변경이 정상적으로 잡혔는지 반드시 확인한다

요약

1. 파일명의 대소문자만 변경하면 Git이 변경을 감지하지 못할 수 있다.
2. 이때는 반드시 git mv 명령어를 사용한다.
3. git mv가 실패하면 임시 파일명을 거쳐 두 단계로 나누어 변경한다.
4. core.ignorecase 설정은 동작 원리를 이해한 뒤 팀 합의를 거쳐 신중히 적용한다.

사실 평소엔 <form> 태그를 잘 안 썼다. 로그인이든 검색이든 그냥 <div>로 감싸고 버튼에 이벤트 걸어서 JS로 값 긁어 보내는 식이었고, 동작은 잘 되니까 굳이 form을 써야 할 이유를 못 느꼈다.

그러다 최근에 레거시 페이지 리뉴얼 작업을 하면서 <form> 태그를 엄청 많이 보게 됐다. 처음엔 "요즘도 이렇게 form을 많이 쓰나?" 싶었는데, 찬찬히 뜯어보니 form이 엔터키 제출, 한글 IME 처리, 브라우저 자동완성, 스크린리더 인식 같은 걸 전부 공짜로 해결하고 있었다. 그동안 내가 div로 만들고 JS로 일일이 막고 있던 것들이다.

이 문서는 그때 정리해둔 내용.

1. form을 쓰는 이유

• 엔터키 자동 제출 — input 포커스 상태에서 엔터 치면 submit 발생
• 스크린리더 접근성 — "폼" 랜드마크로 인식됨
• 브라우저 기본 검증 — required, type, pattern 속성
• 한글 IME 처리 — 조합 중 엔터와 제출용 엔터를 브라우저가 구분
• FormData로 전체 값 일괄 수집 가능

2. 기본 구조

<form action="/order/submit" method="post">
    <input type="text" name="buyer_name" required>
    <button type="submit">주문하기</button>
</form>

3. 실전 예제

3-1. 상품 검색 (GET)

<form action="/goods/search" method="get" role="search">
    <label for="keyword" class="sr-only">상품 검색</label>
    <input type="search" id="keyword" name="keyword"
           placeholder="브랜드, 상품명 입력" required>
    <button type="submit">검색</button>
</form>

• GET 쓰면 URL에 쿼리스트링 남아서 즐겨찾기/공유 가능
• type="search"는 모바일에서 X 버튼 자동 제공

3-2. 로그인

<form action="/member/login" method="post">
    <label for="user_id">아이디</label>
    <input type="text" id="user_id" name="user_id"
           autocomplete="username" required>

    <label for="user_pw">비밀번호</label>
    <input type="password" id="user_pw" name="user_pw"
           autocomplete="current-password" required>

    <label>
        <input type="checkbox" name="remember" value="Y">
        로그인 상태 유지
    </label>

    <button type="submit">로그인</button>
</form>

• autocomplete="current-password" 있어야 브라우저/비밀번호 매니저가 인식
• 회원가입 시엔 new-password 사용

3-3. 회원가입 (검증 속성 활용)

<form action="/member/join" method="post">
    <input type="email" name="email" required
           placeholder="이메일">

    <input type="password" name="password"
           minlength="8" maxlength="20"
           pattern="(?=.*[A-Za-z])(?=.*\d).{8,}"
           title="영문+숫자 포함 8자 이상" required>

    <input type="tel" name="phone"
           pattern="010-?\d{4}-?\d{4}"
           placeholder="010-0000-0000" required>

    <input type="date" name="birth" max="2010-12-31">

    <button type="submit">가입하기</button>
</form>

• type="email" — 브라우저가 @ 포함 여부 자동 검증
• pattern — 정규식 검증
• title — 검증 실패 시 툴팁 메시지

3-4. 장바구니 수량 변경

<form action="/cart/update" method="post">
    <input type="hidden" name="cart_id" value="12345">

    <label for="qty">수량</label>
    <input type="number" id="qty" name="qty"
           min="1" max="99" value="1" required>

    <button type="submit">변경</button>
</form>

• type="number" + min/max — 음수/초과 입력 차단
• 상품 ID 같은 값은 type="hidden"

3-5. 주문/결제 (배송지)

<form action="/order/pay" method="post" id="orderForm">
    <fieldset>
        <legend>배송지 정보</legend>

        <input type="text" name="receiver" placeholder="받는 분"
               required autocomplete="name">

        <input type="tel" name="receiver_phone"
               placeholder="연락처" required autocomplete="tel">

        <input type="text" name="zipcode" readonly required
               autocomplete="postal-code">
        <button type="button" onclick="openZipcodePopup()">우편번호 찾기</button>

        <input type="text" name="addr1" readonly required
               autocomplete="address-line1">
        <input type="text" name="addr2" placeholder="상세주소"
               autocomplete="address-line2">

        <textarea name="delivery_memo" maxlength="50"
                  placeholder="배송 요청사항"></textarea>
    </fieldset>

    <fieldset>
        <legend>결제수단</legend>
        <label><input type="radio" name="pay_method" value="card" checked> 신용카드</label>
        <label><input type="radio" name="pay_method" value="vbank"> 무통장입금</label>
        <label><input type="radio" name="pay_method" value="kakao"> 카카오페이</label>
    </fieldset>

    <label>
        <input type="checkbox" name="agree" required>
        주문 내용 확인 및 결제 동의 (필수)
    </label>

    <button type="submit">결제하기</button>
</form>

• <fieldset> + <legend> — 접근성에서 섹션 그룹핑
• autocomplete 속성 — 브라우저 자동완성 지원 (결제 컨버전 향상)

3-6. 상품 이미지 업로드 (리뷰 작성)

<form action="/review/write" method="post" enctype="multipart/form-data">
    <input type="hidden" name="goods_no" value="98765">

    <select name="rating" required>
        <option value="">별점 선택</option>
        <option value="5">★★★★★</option>
        <option value="4">★★★★</option>
        <option value="3">★★★</option>
    </select>

    <textarea name="content" minlength="10" maxlength="1000"
              required placeholder="10자 이상 작성"></textarea>

    <input type="file" name="photos[]"
           accept="image/*" multiple>

    <button type="submit">리뷰 등록</button>
</form>

• 파일 업로드 시 enctype="multipart/form-data" 필수
• accept="image/*" — 모바일에서 카메라/갤러리 바로 열림
• name="photos[]" — 다중 파일을 배열로 서버 수신

4. JS와 함께 쓰는 패턴

요즘은 form을 써도 실제 제출은 Ajax로 처리하는 경우가 많다. 페이지 새로고침이 일어나면 SPA 흐름이 깨지기 때문이다. 그래서 "form의 기본 동작은 쓰되, 실제 전송만 JS가 가로채는" 방식이 자주 나온다. 엔터키 제출이나 접근성 같은 form의 이점은 그대로 가져가면서 제출 로직만 커스텀하는 패턴이다.

4-1. 제출 가로채서 Ajax로 보내기

<form id="searchForm" action="/goods/search" method="get">
    <input type="search" name="keyword" required>
    <button type="submit">검색</button>
</form>

<script>
document.getElementById('searchForm').addEventListener('submit', function(e) {
    e.preventDefault(); // 기본 제출 막기

    const formData = new FormData(this);
    const params = new URLSearchParams(formData);

    fetch('/goods/search?' + params)
        .then(res => res.json())
        .then(data => renderResults(data));
});
</script>

• FormData(this) — 폼 안의 모든 input 값을 한 번에 수집
• JS가 안 되는 환경에서도 action이 있어서 fallback 작동

4-2. 제출 전 커스텀 검증

form.addEventListener('submit', function(e) {
    const price = this.querySelector('[name=min_price]').value;

    if (Number(price) < 1000) {
        e.preventDefault();
        alert('최소 금액은 1,000원입니다.');
        return;
    }
    // 통과하면 그대로 제출됨
});

5. 주의사항

버튼 type 명시

form 안의 <button>은 기본값이 type="submit". 제출하면 안 되는 버튼(우편번호 찾기, 중복확인 등)은 반드시 type="button" 명시.

<button type="button" onclick="checkDuplicate()">중복확인</button>
<button type="submit">가입하기</button>

form 중첩 금지

<form> 안에 <form> 넣으면 브라우저가 바깥 form 무시함.

엔터키 의도치 않은 제출 방지

단일 input만 있는 form에서 엔터치면 자동 제출됨. 원치 않으면:

<form onsubmit="return false;">

한글 IME 이슈

textarea에서 한글 조합 중 엔터 → 줄바꿈인지 제출인지 헷갈림. compositionstart/compositionend 이벤트로 구분 필요.

let isComposing = false;
textarea.addEventListener('compositionstart', () => isComposing = true);
textarea.addEventListener('compositionend', () => isComposing = false);
textarea.addEventListener('keydown', (e) => {
    if (e.key === 'Enter' && !isComposing && !e.shiftKey) {
        e.preventDefault();
        form.requestSubmit();
    }
});

6. input type 치트시트 (자주 쓰는 것)

마무리

레거시 페이지를 리뉴얼하면서 느낀 건, 예전 개발자들이 <form>을 쓴 게 구식이라서가 아니라 그게 가장 안정적인 방식이라서였다는 점이다. 엔터키, 자동완성, 접근성, IME… 내가 div로 만들고 JS로 하나씩 막아가며 해결했던 문제들을 form은 태그 하나로 해결하고 있었다.

익숙하지 않다고 피하지 말고, 상황에 맞게 form을 쓸 수 있어야겠다는 생각이 들었다. 이 문서가 과거의 나 같은 사람한테 도움이 되면 좋겠다.

댓글, 채팅, 리뷰처럼 사용자가 입력한 텍스트를 고정폭 박스 안에 보여줘야 할 때, 띄어쓰기 없이 길게 붙여 쓴 문자열(예: URL, 연속된 영문/숫자)이 레이아웃을 밀어내는 문제가 생긴다.

| 댓글 영역 |
-----------
| https://verylongurlexampledotcomsomethingsomething... |  ← 박스 밖으로 삐져나감

이걸 해결하려고 검색하면 word-break, overflow-wrap, word-wrap 같은 속성들이 우르르 나오는데, 비슷해 보여도 동작이 제각각이다. 상황에 맞춰 골라 써야 한다.

네 가지 속성 한눈에 보기

1. word-break: break-all

글자 단위로 무조건 끊는다. 공백이 있어도 무시하고 줄 끝에 도달하면 바로 끊어버림.

.text-a { word-break: break-all; }

2. overflow-wrap: break-word

평소엔 단어 단위로 끊고, 한 단어가 너무 길어 넘칠 때만 중간에서 끊는다. 가장 자연스러운 줄바꿈 동작.

.text-b { overflow-wrap: break-word; }

3. overflow-wrap: anywhere

break-word와 동작은 비슷하지만 min-content 계산에도 영향을 준다. 테이블 셀처럼 컨테이너가 콘텐츠 크기에 맞춰 늘어나는 환경에서 더 안정적.

.text-c { overflow-wrap: anywhere; }

4. word-wrap: break-word (구 이름)

overflow-wrap이 표준으로 정리되기 전 이름. 동작은 overflow-wrap: break-word와 완전히 동일하고, IE5.5부터 지원하므로 레거시 호환용으로만 병기한다.

.text-d {
    overflow-wrap: break-word;
    word-wrap: break-word;   /* IE 대응 */
}

실제 차이 비교

같은 문자열을 폭 200px 박스에 넣고 속성만 바꿔보면 차이가 확실히 보인다. 실제 사용자 입력과 비슷하게, 공백이 섞인 문장을 예시로 들어보자.

입력: "안녕하세요 https://verylongurlexampledotcomsomething 입니다"

word-break: break-all

| 안녕하세요 https:/ |
| /verylongurlexamp |
| ledotcomsomething |
| 입니다            |

→ "안녕하세요"와 "https://" 사이 공백을 무시하고 글자 단위로 뚝뚝 끊음. 한글 문장도 중간에 끊길 수 있음.

overflow-wrap: break-word

| 안녕하세요          |
| https://verylongur |
| lexampledotcomsome |
| thingsomething     |
| 입니다             |

→ 일반 단어 사이는 공백 기준으로 자연스럽게 끊고, 긴 URL만 중간에서 끊음. 한글 문장은 깨지지 않음. 가독성 훨씬 좋음.

이래서 사용자 입력 텍스트에는 overflow-wrap: break-word가 기본값처럼 쓰인다.

참고: 공백 없는 문자열만 있으면 결과가 같아 보인다

입력: "https://verylongurlexampledotcomsomethingsomething"

이 경우엔 break-all과 break-word 둘 다 동일하게 글자 단위로 끊은 결과가 나온다.

| https://verylongur |
| lexampledotcomsome |
| thingsomething     |

하지만 동작 원리는 전혀 다르다. break-all은 항상 글자 단위로 끊고, break-word는 공백이 없어서 어쩔 수 없이 글자 단위로 끊은 것뿐. 공백이 포함된 순간 위 비교처럼 결과가 갈린다.

상황별 선택 가이드

⚠️ 함정: 테이블 셀 안에서는 overflow-wrap: break-word가 안 먹힌다

여기까지 읽고 "그럼 overflow-wrap: break-word로 통일해야지!" 하고 적용했는데 전혀 동작하지 않는 경우가 있다. 바로 테이블 셀(td) 안에 텍스트가 있을 때다.

왜 안 될까

테이블은 기본적으로 콘텐츠 크기에 맞춰 폭이 자동으로 늘어나는 레이아웃이다. 긴 단어가 들어오면 브라우저는 줄바꿈 대신 "셀을 넓히는" 쪽을 선택한다.

그런데 overflow-wrap: break-word는 "넘칠 때만 끊는다"는 조건부 속성이다. 테이블이 애초에 넘치지 않게 셀을 늘려버리니까 발동 조건 자체가 성립하지 않는다.

같은 CSS, 다른 결과

<!-- div 안: 정상 동작 -->
<div style="width:200px; overflow-wrap:break-word;">
  verylongurlexampledotcom...
</div>
→ 200px에서 칼같이 끊김 ✅

<!-- td 안: 무시됨 -->
<table style="width:200px;">
  <tr><td style="overflow-wrap:break-word;">
    verylongurlexampledotcom...
  </td></tr>
</table>
→ 셀이 단어 길이만큼 늘어나서 테이블이 밖으로 삐져나감 ❌

테이블 셀 해결책 세 가지

1. table-layout: fixed 추가

테이블 폭을 콘텐츠와 무관하게 고정시키면 break-word가 정상 동작한다. 단, 다른 셀 폭 계산 방식까지 바뀌므로 기존 레이아웃이 틀어질 수 있다.

table { table-layout: fixed; width: 100%; }

2. overflow-wrap: anywhere 사용

break-word와 비슷하지만 min-content 계산에도 영향을 준다. 즉 테이블이 셀을 늘려서 피하는 것 자체를 막는다. 별도 설정 없이 테이블 셀에서도 동작.

td { overflow-wrap: anywhere; }

단, IE 미지원이고 Safari는 15 이상부터 지원. 레거시 필요 없으면 가장 깔끔한 선택.

3. 그냥 word-break: break-all

레이아웃 계산과 무관하게 무조건 끊어버리므로 테이블 안이든 밖이든 상관없이 동작한다. 단어 중간이 끊기는 건 감수.

td { word-break: break-all; }

테이블 셀 선택 가이드

실제 사용 사례

• Tailwind CSS — break-words 유틸리티 = overflow-wrap: break-word
• Bootstrap — text-break 유틸리티 = word-wrap + overflow-wrap: break-word
• 슬랙, 디스코드 웹, 카카오톡 웹 — 채팅 메시지 영역에 동일 패턴 사용

사용자 입력 텍스트를 다루는 거의 모든 서비스가 overflow-wrap: break-word 방식을 쓴다.

정리

• word-break: break-all은 공백도 무시하고 끊기 때문에 한국어 문장을 중간에서 쪼갤 수 있다. 일반 텍스트엔 부적합.
• 사용자 입력 같은 자연스러운 문장엔 overflow-wrap: break-word가 기본 선택.
• 단, 테이블 셀 안에서는 break-word가 안 먹히므로 overflow-wrap: anywhere나 table-layout: fixed를 써야 한다.
• 레거시까지 챙겨야 하거나 테이블 구조를 건드리기 애매하면, word-break: break-all이 가장 확실하고 안전한 선택지다. (실무에선 이쪽으로 타협하는 경우도 많다)
• IE 지원이 필요하면 overflow-wrap과 함께 구 이름인 word-wrap: break-word를 병기한다.

Blade란?

Laravel에서 HTML을 만들어주는 템플릿 엔진.

파일 확장자는 .blade.php
HTML 안에서 @문법, {{ }}를 사용해 서버 데이터를 화면에 출력한다.

🐸 React로 치면 JSX 안에서 map이나 조건 렌더링 하는 느낌이랑 비슷하다.

🐸 퍼블리셔 입장에서는
"하드코딩 HTML → 데이터 기반 UI로 바꾸는 과정"이라고 보면 이해가 쉽다.

1. 변수 출력 {{ }}

<span>{{ $user['name'] }}</span>

• 변수 값을 HTML에 출력
• <, > 같은 HTML 태그는 자동으로 escape 처리됨 (안전)

🐸 사용자 이름, 텍스트 같은 기본 출력에 사용

2. 반복문 @foreach

@foreach ($products as $product)
    <div class="product-item">
        <p>{{ $product['name'] }}</p>
        <p>{{ $product['price'] }}원</p>
    </div>
@endforeach

• 배열 데이터를 반복해서 UI 생성
• 상품 리스트, 게시글 목록 등 반복되는 구조에 사용

🐸 같은 구조 HTML을 여러 개 찍어내는 느낌
🐸 처음엔 그냥 PHP for문 아닌가..? 했는데 써보니까 또 다름

3. 조건문 @if

@if (!empty($products))
    <div>상품이 있습니다</div>
@endif

• 조건이 참일 때만 출력

🐸 데이터 있을 때만 영역 보여주기 같은 데 많이 씀

4. 조건 분기 @if / @elseif / @else

@if ($product['status'] === 'sale')
    <span>판매중</span>
@elseif ($product['status'] === 'soldout')
    <span>품절</span>
@else
    <span>준비중</span>
@endif

🐸 상태값에 따라 UI 바꿀 때 사용
🐸 이런 건 거의 무조건 들어가는 듯

5. 변수 존재 여부 @isset

@isset($user)
    <div>{{ $user['name'] }}</div>
@endisset

• 변수가 존재하고 null이 아닐 때만 출력

🐸 로그인 정보나 선택된 값 있을 때 체크용

6. 데이터 접근 방식

서버 데이터 예시:

$product = [
    'id' => 1,
    'name' => '스니커즈',
    'price' => 120000,
];

사용:

{{ $product['name'] }}
{{ $product['price'] }}

🐸 배열에서 값 꺼내는 건 그냥 JS랑 비슷해서 금방 익숙해짐

7. @forelse (이거 은근 중요)

@forelse ($products as $product)
    <p>{{ $product['name'] }}</p>
@empty
    <p>등록된 상품이 없습니다</p>
@endforelse

• 데이터 있으면 반복
• 없으면 empty UI 출력

🐸 이거 몰라서 if + foreach 따로 썼었는데
🐸 그냥 이거 쓰는 게 훨씬 깔끔함

8. HTML 그대로 출력 {!! !!} (주의)

{!! $description !!}

• HTML 태그 그대로 출력
• escape 안됨

⚠️ 사용자 입력 데이터면 위험함 (XSS)

🐸 진짜 필요한 경우 아니면 잘 안 쓰는 게 맞는 듯

9. 컴포넌트 분리 @include

@include('components.product-card', ['product' => $product])

• 반복 UI를 분리해서 재사용
• 유지보수에 중요

🐸 같은 UI 여러 번 쓰면 이거로 빼는 게 편함
🐸 안 빼면 나중에 수정 지옥됨

10. Blade 주석

{{-- 이 주석은 브라우저에 보이지 않음 --}}

🐸 HTML 주석이랑 다르게 아예 안 내려감

11. 실전 예시 (상품 리스트)

@if (!empty($products))
<div class="product-list">

    @foreach ($products as $product)
        <div class="product-card">
            <h3>{{ $product['name'] }}</h3>
            <p>{{ $product['price'] }}원</p>

            @if ($product['status'] === 'sale')
                <span class="badge">판매중</span>
            @else
                <span class="badge">품절</span>
            @endif
        </div>
    @endforeach

</div>
@endif

🐸 실제로는 이런 구조 계속 반복해서 쓰게 됨
🐸 데이터 체크 + 반복 + 조건 이 세 개가 거의 기본 패턴

12. 자주 쓰는 문법 요약

한줄 정리

🐸 결국 Blade는
"데이터 받아서 HTML 찍어내는 도구"라고 생각하면 편하다.

iframe은 생각보다 자주 보이지만,
막상 직접 다루려고 하면 높이 문제나 도메인 제약 때문에 꽤 까다로운 태그다.

특히 그냥 붙여 넣기만 하면 되는 줄 알았다가
높이가 안 맞거나, 내부 페이지에 접근이 안 되거나, 반응형 대응이 꼬이는 경우가 많다.

이번 글은 실무에서 iframe을 쓸 때 헷갈리기 쉬운 포인트들을 기준으로 정리해봤다.

iframe이란?

HTML 페이지 안에 또 다른 HTML 페이지를 삽입하는 태그.
말 그대로 "내부 프레임(inline frame)".

<iframe src="/other_page.php" width="400" height="300"></iframe>

왜 쓰는지

• 외부 콘텐츠 삽입 — 유튜브, 지도, 결제창 등 다른 도메인의 페이지를 그대로 가져올 때
• 독립된 환경 격리 — iframe 안의 CSS/JS가 부모 페이지에 영향을 주지 않음 (반대도 마찬가지)
• 레거시 페이지 재사용 — 기존 페이지를 수정 없이 다른 페이지 안에 넣고 싶을 때

언제 쓰는지

• 결제 모듈 (KCP, 이니시스 등) — 보안상 iframe 필수
• 외부 서비스 임베드 (YouTube, Google Maps, 광고)
• 사이드 패널에 별도 페이지를 띄울 때

장점

• 부모/자식 페이지의 CSS, JS가 서로 완전히 격리됨
• 외부 도메인 콘텐츠를 간단히 삽입 가능
• 페이지 전체 새로고침 없이 iframe만 교체 가능

주의할점 (단점)

1. 높이 자동조절 불가

iframe은 일반 <div>와 다르게 height: auto가 안 먹힌다. height를 지정하지 않으면 브라우저 기본값 150px이 적용된다.

그래서 아무 생각 없이 붙이면
내용은 많은데 iframe은 150px짜리 박스만 보이는 상황이 생긴다.

콘텐츠에 맞추려면 JS로 내부 scrollHeight를 읽어서 직접 세팅해야 한다.

// iframe 내부 페이지에서 부모 iframe 높이를 세팅
parent.document.getElementById("my_iframe").height = document.body.scrollHeight;

상한/하한이 필요하면 Math.min, Math.max를 사용한다.

// 최소 205px, 최대 495px
const nextHeight = Math.max(Math.min(document.body.scrollHeight, 495), 205);
parent.document.getElementById("my_iframe").height = nextHeight;

2. HTML 속성 height vs CSS style.height 충돌

iframe의 높이를 세팅하는 방법이 두 가지 있다.

// 방법 1: HTML 속성
iframe.height = "300";

// 방법 2: 인라인 스타일
iframe.style.height = "300px";

이 두 가지를 섞어 쓰면 충돌이 발생한다.
인라인 style이 HTML 속성보다 우선하므로, 이전에 style.height를 세팅한 적이 있으면 이후 iframe.height 변경이 무시될 수 있다.

한 가지 방식으로 통일하거나, 전환 시 이전 값을 초기화해야 한다.

// 인라인 스타일 초기화
iframe.style.height = "";

실무에서는 이런 식으로 섞어 쓰다가
“분명 높이를 바꿨는데 왜 안 바뀌지?” 하고 한참 헤매는 경우가 많다.

3. CSS !important와의 관계

#my_iframe { height: 495px !important; }
#my_iframe { max-height: 495px !important; }

height: !important는 JS의 인라인 스타일 세팅도 덮어쓸 수 있어서,
동적 높이 제어가 필요하면 max-height/min-height를 사용하는 것이 좋다.

4. 성능

별도 문서를 로드하므로 CSS, JS 등 리소스가 이중으로 로딩된다.
페이지에 iframe이 많을수록 성능 부담이 커진다.

5. SEO

iframe 안의 콘텐츠는 검색엔진에서 별도의 페이지로 인식된다.

즉,

• iframe src의 페이지는 따로 크롤링될 수 있지만
• 부모 페이지의 SEO에는 거의 기여하지 않는다

👉 iframe은 SEO에 불리하다기보다
SEO 관점에서 “기여하지 않는 구조”에 가깝다.

6. 반응형 어려움

내부 콘텐츠 크기가 변해도 부모가 자동으로 감지하지 못한다.
MutationObserver 등으로 변화를 감시하고 수동으로 높이를 업데이트해야 한다.

new MutationObserver(function() {
    parent.document.getElementById("my_iframe").height = document.body.scrollHeight;
}).observe(document.body, { childList: true, subtree: true });

7. 크로스 도메인 제약

다른 도메인의 iframe이면 JS로 내부 콘텐츠에 접근할 수 없다 (동일 출처 정책).
이 경우 postMessage를 사용해야 한다.

8. postMessage

postMessage는 부모 페이지와 iframe 사이에서
👉 메시지 형태로 데이터를 주고받는 방식이다.

// iframe 내부에서 부모에게 높이 전달
parent.postMessage({ type: 'resize', height: document.body.scrollHeight }, '*');

// 부모 페이지에서 수신
window.addEventListener('message', function(e) {
    if (e.data.type === 'resize') {
        document.getElementById("my_iframe").style.height = e.data.height + 'px';
    }
});

⚠️ 보안 주의

parent.postMessage(data, '*');

*는 모든 도메인을 허용하는 방식이라 위험하다.

parent.postMessage(data, 'https://example.com');

window.addEventListener('message', function(e) {
    if (e.origin !== 'https://example.com') return;
});

iframe을 쓰면 안 되는 경우

• 같은 도메인인데 단순 UI 삽입 → AJAX + div가 훨씬 편함
• SEO가 중요한 콘텐츠 → 본문, 상품 설명
• 반응형이 중요한 경우 → 유지보수 난이도 상승

대안

한 줄 요약

iframe은 격리와 외부 삽입에는 강하지만, 높이 제어와 SEO, 반응형 대응에서 까다롭다.

모바일 검색 페이지에서 검색창이 아닌 다른 영역(스와이퍼, 빈 공간 등)을 터치해도 키보드가 올라왔다.

원인

document 전체에 touchstart 이벤트를 걸어서 검색창에 .focus()를 주고 있었다.

// 문제의 코드
document.addEventListener('touchstart', focusWithGesture, { passive: true });

의도는 iOS 대응이었다. iOS에서는 사용자 제스처 없이 호출한 .focus()로는 키보드가 뜨지 않기 때문에, 첫 터치를 캐치해서 포커스를 주려고 한 것이다. 근데 대상이 document라 어디를 터치하든 키보드가 올라왔다.

해결

이벤트 대상을 document → 검색 입력창으로 변경하고, 한 번 실행 후 이벤트를 제거했다.

var searchBox = document.getElementById('mainSearchBox');

function focusOnce() {
    searchBox.focus();
    searchBox.removeEventListener('touchstart', focusOnce);
}

searchBox.addEventListener('touchstart', focusOnce, { passive: true });

정리

배운 점

• iOS 모바일 브라우저는 사용자 제스처(터치) 컨텍스트 안에서만 input.focus()로 키보드를 띄울 수 있다
• 그래서 window.onload에서 .focus()를 호출해도 키보드가 안 뜬다
• 이벤트 위임할 때 대상 범위를 꼭 확인하자. document에 거는 건 진짜 필요한 경우만

목록 UI를 구현하다 보면 데이터 로딩 동안 화면이 비거나 레이아웃이 밀리는 상황을 자주 마주친다.
스켈레톤 UI(Skeleton UI)는 그 순간을 채우기 위한 로딩 패턴으로, 실제 콘텐츠와 비슷한 형태의 회색 블록을 먼저 보여준다.
뼈대(skeleton)만 먼저 그려두고, 데이터가 준비되면 실제 콘텐츠로 교체하는 방식이다.

2. 왜 써야 하는가?

기존 방식의 문제

[데이터 로딩 중] → 빈 화면 or 스피너 → [콘텐츠 등장]

빈 화면이나 스피너는 사용자 입장에서 "뭔가 고장난 건가?" 하는 불안감을 준다.
또한 콘텐츠가 갑자기 나타나면서 레이아웃이 툭툭 밀리는 현상(Layout Shift)이 발생한다.

스켈레톤의 장점

[데이터 로딩 중] → 스켈레톤(뼈대) → [콘텐츠 등장]

3. 언제 쓰는가?

스켈레톤은 모든 로딩에 쓰는 게 아니다. 상황에 맞게 선택해야 한다.

4. 구현 방법 2가지

방법 A — 별도 스켈레톤 마크업 교체

스켈레톤 전용 HTML을 따로 만들어두고, 로딩 시작 시 삽입 → 완료 시 실제 콘텐츠로 교체하는 방식.

흐름

API 호출 시작 → 스켈레톤 HTML 삽입 → 데이터 수신 → 실제 콘텐츠 HTML로 교체

HTML (스켈레톤 전용)

<div class="card-skeleton">
  <div class="skeleton skeleton--thumbnail"></div>
  <div class="skeleton skeleton--title"></div>
  <div class="skeleton skeleton--desc"></div>
</div>

CSS

.skeleton {
  position: relative;
  display: block;
  overflow: hidden;
  background: #ececec;
  border-radius: 4px;
}

/* shimmer 애니메이션 */
.skeleton::after {
  content: "";
  position: absolute;
  top: 0;
  left: -120px;
  width: 80px;
  height: 100%;
  background: linear-gradient(
    90deg,
    rgba(255, 255, 255, 0) 0%,
    rgba(255, 255, 255, 0.7) 50%,
    rgba(255, 255, 255, 0) 100%
  );
  animation: shimmer 1.4s infinite;
}

@keyframes shimmer {
  0%   { left: -120px; }
  100% { left: 100%; }
}

.skeleton--thumbnail { width: 100%; height: 180px; }
.skeleton--title     { width: 70%; height: 16px; margin-top: 12px; }
.skeleton--desc      { width: 50%; height: 12px; margin-top: 8px; }

JS

async function loadCard() {
  // 스켈레톤 삽입
  container.innerHTML = skeletonHTML;

  const data = await fetchData();

  // 실제 콘텐츠로 교체
  container.innerHTML = renderCard(data);
}

장점

• CSS가 짧고 단순하다
• 스켈레톤 모양을 자유롭게 만들 수 있다

단점

• 마크업이 바뀌면 스켈레톤 HTML도 같이 수정해야 한다
• 컴포넌트마다 별도 파일이 필요하다

방법 B — CSS 클래스 토글

기존 실제 마크업에 .skeleton 클래스만 추가/제거하는 방식.
별도 스켈레톤 HTML이 필요 없다.

흐름

페이지 렌더링 → section에 .skeleton 클래스 추가 → 데이터 수신 → .skeleton 클래스 제거

HTML (실제 마크업 그대로 사용)

<!-- 로딩 중: skeleton 클래스 있음 -->
<section class="card-section skeleton">
  <h2 class="card-title">인기 상품</h2>
  <ul class="card-list">
    <li class="card-item">
      <span class="card-rank">1</span>
      <span class="card-name">상품명</span>
    </li>
  </ul>
</section>

<!-- 로딩 완료: skeleton 클래스 제거 -->
<section class="card-section">
  ...
</section>

CSS

/* 스켈레톤 상태일 때 하위 요소를 덮어씀 */
.skeleton .card-title,
.skeleton .card-rank,
.skeleton .card-name {
  position: relative;
  overflow: hidden;
  background: #ececec;
  color: transparent;        /* 텍스트 숨기기 */
  border-radius: 4px;
  pointer-events: none;      /* 클릭 막기 */
}

.skeleton .card-title  { width: 80px; height: 18px; }
.skeleton .card-rank   { width: 16px; height: 14px; }
.skeleton .card-name   { width: 74%; height: 14px; }

/* shimmer */
.skeleton .card-title::after,
.skeleton .card-rank::after,
.skeleton .card-name::after {
  content: "";
  position: absolute;
  top: 0; left: -120px;
  width: 80px; height: 100%;
  background: linear-gradient(
    90deg,
    rgba(255,255,255,0) 0%,
    rgba(255,255,255,0.7) 50%,
    rgba(255,255,255,0) 100%
  );
  animation: shimmer 1.4s infinite;
}

@keyframes shimmer {
  0%   { left: -120px; }
  100% { left: 100%; }
}

JS

async function loadCard() {
  section.classList.add('skeleton');

  const data = await fetchData();
  renderCard(data);

  section.classList.remove('skeleton');
}

장점

• 별도 스켈레톤 HTML이 필요 없다
• 마크업이 바뀌어도 HTML은 수정 불필요 (CSS만 조정)
• PHP처럼 서버에서 마크업을 미리 그리는 환경에 특히 적합

단점

• CSS가 길어진다 (하위 요소 전부 스타일 덮어써야 함)
• color: transparent, pointer-events: none 등 예외 처리가 많아진다

5. 방법 선택 기준

6. shimmer 애니메이션 원리

스켈레톤의 핵심인 shimmer(반짝임) 효과는 ::after 가상 요소로 구현한다.

[회색 박스 - overflow: hidden]
       ↑
  [흰색 빛줄기 - position: absolute]
  left: -120px → left: 100% 로 이동 (animation)

overflow: hidden 덕분에 빛줄기가 박스 밖으로 나가면 잘려서 보이지 않는다.
이 빛줄기가 왼쪽에서 오른쪽으로 반복 이동하면서 shimmer 효과가 만들어진다.

7. 실무 팁

키워드 너비를 다르게 줘서 자연스럽게 만들기

모든 항목의 너비가 똑같으면 부자연스러워 보인다.
nth-child로 항목마다 너비를 다르게 주면 실제 텍스트처럼 보인다.
방법 B(클래스 토글)에서는 요소에 color: transparent와 background가 이미 적용되어 있으므로, width를 직접 덮어쓰면 된다.

.skeleton .card-name                           { width: 74%; }
.skeleton .card-item:nth-child(2n) .card-name  { width: 62%; }
.skeleton .card-item:nth-child(3n) .card-name  { width: 84%; }
.skeleton .card-item:nth-child(5n) .card-name  { width: 56%; }

로딩 완료 후 부드럽게 전환

스켈레톤에서 실제 콘텐츠로 바뀔 때 transition을 주면 덜 튀어보인다.

.card-section {
  transition: opacity 0.2s ease;
}
.card-section.skeleton {
  opacity: 0.8;
}

접근성 처리

스켈레톤 UI에서 접근성의 핵심은 스켈레톤 요소 하나하나를 스크린 리더에게 설명하는 게 아니라,
컨테이너가 현재 로딩 중이라는 상태만 전달하는 것이다.
aria-busy="true"는 "이 영역은 아직 준비 중"이라는 신호를 스크린 리더에 보내고, 내부 콘텐츠 읽기를 보류하게 한다.

<section aria-busy="true" aria-label="콘텐츠 로딩 중">

// 완료 후: 로딩 끝났음을 알림
section.setAttribute('aria-busy', 'false');
section.removeAttribute('aria-label');

정리

스켈레톤 UI는 단순한 로딩 효과가 아니다.
화면을 미리 채워두는 것 자체가 사용자에게 "지금 잘 되고 있다"는 신호를 주는 UX 장치다.

TypeScript와 Next.js로 코드를 작성하다 보니, 종종 낯선 느낌표(!)를 마주쳤다. 내가 아는 느낌표는 != 같은 연산자에 쓰이는 "not" 정도였는데, 갑자기 변수 뒤에 붙는 느낌표가 등장하니 궁금증이 생겼다. 그래서 찾아보았다.

const dislikePost = async () => {
    "use server";
    try {
      const session = await getSession();
      await db.like.delete({
        where: {
          id: {
            postId: id,
            userId: session.id!,
          },
        },
      });
      revalidatePath(/post/${id});
    } catch (e) {}
  };

session.id!의 느낌표는 TypeScript에서 Non-Null Assertion Operator라고 불린다.

Non-Null Assertion Operator

• 이 연산자는 값이 null 또는 undefined가 아닐 것이라고 개발자가 확신하는 경우에 사용한다.
• TypeScript는 기본적으로 값이 null 이나 undefined일 가능성을 엄격하게 체크하기 때문에, 해당값이 확실히 존재한다고 알려주지 않으면 에러를 발생시킬 수 있다.

왜 session.id!에 느낌표를 붙였을까?

session.id가 타입 정의상 string | undefined와 같이 undefined가 포함될 수 있는 경우, TypeScript는 안전성을 위해 에러를 발생시킬 수 있다.

const session: { id?: string } = { id: undefined }; // id가 없을 수도 있는 상황

이런 상황에서 session.id!는 "내가 개발자인 내가 확신하는데, 이 값은 절대 undefined가 아니야!"라고 TypeScript에게 알려주는 것이다.

즉, !를 붙임으로써 타입 검사기를 속이고 해당 값이 반드시 존재한다고 강제한다.

undefined를 처리하기 위한 의미 undefined와 관련이 있지만 정확히는 TypeScript의 타입 검사기가 undefined 가능성을 인지하고, 그로 인해 발생할 수 있는 오류를 방지하기 위해 사용하는 것이다. undefined일 수도 있는 값을 개발자가 확실히 존재한다고 보장하기 위한 도구라고 이해하면 쉽다.

주의점

• !를 사용할 때는 정말 해당 값이 존재한다는 확신이 있을 때만 사용해야 한다. 그렇지 않으면 런타임 오류가 발생할 수 있다. 만약 값이 undefined일 가능성을 제대로 처리하고 싶다면 다음과 같이 조건문을 추가하는 것이 더 안전하다.

if (!session?.id) {
  throw new Error("Session ID is not available!");
}
await db.like.delete({
  where: {
    id: {
      postId: id,
      userId: session.id,
    },
  },
});

배운점 & 느낀점

유용해 보이지만, 함부로 쓰면 위험할 수 있는 연산자(?)를 또 하나 알게 되었다. css에서는 !important / typescript any가 있었는데 또 하나 추가되었따. 강제로 선언하는 역할을 하기 때문에 사용하는게 신중함이 필요하다고 했으니 .... 간단한 프로젝트에서는 !의 남발을 피해야겠지만, 프로젝트 규모가 커지면 어쩔 수 없이 사용하는 경우도 생길 것 같다..... 하지만 typescript는 안전성이 중요하기 때문에 안쓰려고 노력해야겠다

실제로 css에서 !important 많이 사용하고 있다 .. 코드가 방대해지면 어쩔 수 없을 거 같다 ^^

createObjectURL

• URL.createObjectURL은 브라우저에서 로컬 파일을 로드하여 미리보기를 제공하는 간단한 방법이다.

export default function AddProduct() {
  const [preview, setPreview] = useState(""); // 이미지 미리보기 URL 저장
  const onImageChange = (event: React.ChangeEvent<HTMLInputElement>) => {
    const {
      target: { files },
    } = event;
    if (!files) return; // 파일이 없으면 종료

    const file = files[0];
    const url = URL.createObjectURL(file); // 파일 객체로 URL 생성
    setPreview(url); // URL 상태 업데이트
  };

  return (
    <div>
      <input type="file" onChange={onImageChange} />
      {preview && <img src={preview} alt="Preview" />}
    </div>
  );
}

• 브라우저에서 로컬 파일을 간단히 로드 가능
• 이미지 파일을 업로드하기 전에 사용자에게 미리보기를 제공함
• 메모리 누수를 방지하려면 사용 후 URL을 해제해야함. (URL.revokeObjectURL(url);)

arrayBuffer

• arrayBuffer는 파일 데이터를 버퍼로 변환하여 서버에 저장하는 방법이다.
• 파일 데이터를 직접 변환하고 저장할 수 있음
• 주로 테스트나 임시 파일 작업에 사용(이미지 업로드한척 해야할때 사용)
• 보안 문제: 클라이언트가 악의적인 파일 이름이나 데이터를 보낼 경우 서버가 위험에 노출될 수 있기에 실제 이미지 업로드로는 권장하지 않음

if (data.photo instanceof File) {
  const photoData = await data.photo.arrayBuffer(); // 파일 데이터를 ArrayBuffer로 변환
  await fs.appendFile(`./public/${data.photo.name}`, Buffer.from(photoData)); // 서버에 파일 저장
  data.photo = `/${data.photo.name}`; // 저장된 경로를 photo에 할당
}

CloudFlare Images (사용 추천)

• Cloudflare Images는 이미지 업로드와 관리를 위한 유료 서비스
• 월 $5로 간단한 이미지 처리와 저장 가능.
• API를 사용하여 이미지를 업로드하고 URL로 접근 가능

Cloudflare Images 설정 과정

1. Cloudflare 계정 생성 및 로그인

• Cloudflare에서 계정 생성 후 로그인.

2. Images 서비스 활성화

• Images → Overview로 이동.
• 결제 설정 후 서비스 활성화.

3. API 토큰 생성

• Images → API → Create API Token으로 이동.
• "Read and write to Cloudflare Stream and Images" 템플릿 사용. (Use template 버튼)
• Analytics 권한 삭제.
• Create Token을 클릭하고 생성된 토큰을 복사.

4. .env 파일에 설정 추가

• Images - Overview > 생성된 API 토큰, Account ID, Account Hash를 .env 파일에 저장

  //env
  CLOUDFLARE_API_TOKEN=your_api_token
  CLOUDFLARE_ACCOUNT_ID=your_account_id
  CLOUDFLARE_ACCOUNT_HASH=your_account_hash

배운점 & 느낀점

아직 유료서비스를 결제할 단계는 아닌거 같아서 간단하게 arrayBuffer나 createObjectURL를 사용해서 이미지 업로드를 해보았다. 보안 이슈로 인해 권장하지는 않지만 어떤식으로 동작하는지에 대해 자세히 알게 되는 시간이었고, 나중에 포트폴리오나 다른 작업을 하게 된다면 유료 서비스도 한번 사용해보고 싶다.

.superRefine

ctx.addIssue를 통해 원하는 만큼 이슈를 추가할 수 있다. 함수 실행 중에 ctx.addIssue가 호출되지 않으면 유효성 검사가 통과

fatal: true설정 시, 그 다음 refine이 실행되는 것을 방지 z.NEVER 설정 시, 반환 값 자체를 사용하기 위해서가 아닌, 타입 시스템을 맞추기 위함 (함수가 특정한 타입 검사를 통과시키면서도, 그 결과 값을 반환할 필요가 없을 때 사용) https://zod.dev/?id=superrefine

import { z } from "zod";

const schema = z.object({
  password: z.string(),
  confirmPassword: z.string(),
}).superRefine(({ password, confirmPassword }, ctx) => {
  if (password !== confirmPassword) {
    ctx.addIssue({
      code: z.ZodIssueCode.custom,
      message: "Passwords do not match",
      fatal: true, // 추가 검사 중단
    });
  }
});

schema.parse({
  password: "12345",
  confirmPassword: "123",
}); // 에러: "Passwords do not match"

z.NEVER

• 기본적으로 어떤 값도 통과시키지 않음 → "절대 유효하지 않음"을 명시.
• 타입 시스템에서 특정 값이나 조건을 명시적으로 차단하려는 경우 사용.
• 기본적으로 모든 입력을 거부하는 스키마
• API 스키마에서 특정 필드의 사용을 차단
• 타입 유효성 검사에서 never 타입을 활용하여 실수를 방지.

import { z } from "zod";

// 특정 필드 차단
const userSchema = z.object({
  id: z.string(),
  role: z.enum(["admin", "user"]),
  extra: z.NEVER, // 이 필드는 절대 허용되지 않음
});

userSchema.parse({
  id: "123",
  role: "admin",
  extra: "unexpected_field", // 에러 발생: 'extra' 필드는 허용되지 않음
});

// 타입만 검사 (값을 반환하지 않음)
const neverSchema = z.NEVER;
const result = neverSchema.safeParse("anything"); // 항상 실패

배운점 & 느낀점

Zod를 배워서 유효성검사 하는 법을 배웠는데, 이 개념들은 좀 심화과정인거 같다. 커스텀 유효성 검사와 타입 안정성을 높이는데 중요한 개념인거 같아서 나중에 타입스크립트도 함께 더 작업을 하게 된다면 꼭 사용해야 할 필수 개념같다. 지금은 아직 초보 이슈로... 더 공부하는걸로~

Image 컴포넌트

기본 jsx img가 지원하지 않는 여러가지 강력한기능을 지원한다.

• 로딩 전후로 컴포넌트 위치가 밀리는 content shift를 방지한다.
• 압축률이나, 화면 크기별 압축 옵션을 제공한다.
• 필수 prop으로 src, width, height, alt를 입력해야한다.
• width, height를 모른다면, fill을 써주면 된다.
• fill은 이미지를 자동으로 부모컴포넌트의 크기로 맞춰주는 역할을 한다.

    <Image fill src={photo} alt={title} /> //quality 속성도 있음 (1이면 화질이 저하됨)

Image Hostnames

• NextJS의 Image는 이미지를 자동으로 최적화를 해주어 성능을 향상시키고 빠른 로딩이 되도록 해 준다. 하지만 외부 호스트의 이미지(다른 사이트의 이미지 링크 등)를 불러올 때는 보안 상의 이유로 이 기능이 허용되지 않는다. 따라서 next.config.mjs에서 hostname들을 등록해 주어야 한다. (nextConfig > images > remotePatterns > hostname)

import type { NextConfig } from "next";

const nextConfig = {
  images: {
    remotePatterns: [
      {
        hostname: "avatars.githubusercontent.com",
      },
    ],
  },
};

export default nextConfig;

배운점 & 느낀점

매번 이미지 크기로 고통 받았는데, Next.js는 알아서 이미지도 맞게 넣어주고 최적화도 해준다니 정말 갓벽한거 같다..

Middleware

• 말 그대로 중간에서 동작하는 일종의 소트프웨어를 뜻한다. 어떤 것과 다른것 사이에서 실행되는 코드.
• 미들웨어를 사용하면 request가 완료되기 전에 코드를 실행할 수 있다.
• 이미지, CSS, JS, Favicon 요청 등 웹 사이트의 모든 단일 request 하나하나 마다 미들웨어가 실행

예를들어 user가 profile 페이지로 이동하면 그 request는 profile 페이지로 가고 user에게 profile 페이지를 줘야한다. 그러다 미들웨어를 활성화하면 그 사이에서 실행될 어떤 코드를 갖게 된다. 따라서 profile 페이지로 이동하기 전에 임의의 코드를 실행할 수 있다.

미들웨어 사용 케이스

1. 인증 및 권한 부여: 특정 페이지나 API 라우트에 대한 액세스 권한을 부여하기 전에 사용자 신원을 확인하고 세션 쿠키를 확인할 때 사용할 수 있다.
2. 서버 사이드 리디렉션: 특정 조건(예: local, 사용자 조건)에 따라 서버에서 사용자를 리디렉션함.
3. 경로 Rewriting: request 속성을 기반으로 API 라우트 또는 페이지에 대한 라우트를 동적으로 재작성하여 A/B 테스트, 기능 출시 또는 레거시 경로를 지원한다.
4. 봇 탐지: 봇 트래픽을 탐지하고 차단하여 리소스를 보호한다.
5. 로깅 및 분석
6. 기능 플래그 지정

Response

Fetch API의 Response 인터페이스는 request에 대한 response를 나타낸다.

Matcher

• matcher를 사용하면 matcher에 지정한 특정 경로들에서만 미들웨어가 실행되도록 할 수 있다.

  matcher: ["/((?!_next/static|_next/image|favicon.ico|.*\\.(?:svg|png|jpg|jpeg|gif|webp)$).*)"]

Runtimes

Next.js에는 애플리케이션에서 사용할 수 있는 두 가지 서버 런타임이 있다.

1. Node.js 런타임(기본값): 생태계의 모든 Node.js API 및 호환 패키지에 액세스
2. Edge 런타임: 제한된 API를 지원하는 Edge 런타임

Edge Runtime

• Edge Runtime는 일종의 제한된 버전의 node.js로 생각하면 된다.
• 미들웨어는 현재 Edge Runtime과 호환되는 API만 지원함

배운점 & 느낀점

페이지 이동 전에 보여져야 할 것과 안 보여져야 할 것을 미리 구분할 수 있다는 점이 정말 편리하게 느껴졌다. 단순히 "중간에 끼어드는 코드"라는 개념을 넘어서, 보안, 최적화, 유저 경험 같은 다양한 측면에서 큰 역할을 할 수 있다는 점이 인상 깊었다.

실제로 사용하면 정말 유용할 것 같지만... 솔직히 아직은 조금 많이 어렵다...😅 그래도 배우면서 "언젠가 이걸 자유자재로 다룰 수 있다면 정말 멋질 것 같다!"라는 생각이 들었다.

bcrypt

• 비밀번호를 해시할 때 사용하는 라이브러리
• 해시함수는 단방향 멱등성 함수
• 데이터베이스에 비밀번호를 그대로 저장하지 않는다.(해킹의 위험성)
• 정해진 입력에 따라 정해진 난수를 출력함

  npm i bcrypt
  npm i @types/bcrypt

12345 => hashFunction(12345) => 4rejglkdhlk4-gdfh-096   (O) //단방향임

hashFunction(4rejglkdhlk4-gdfh-096) => 12345            (X)

bcrypt하는 이유

• 보안상 데이터가 유출되어도, 원본 비밀번호를 알 수 없으니 해킹당하지않음
• 정형데이터로 정해진 양식, 정해진 길이로 맞출 수 있음

bcrypt.hash(비밀번호, saltRounds, function(err, hash) {
// 비밀번호 DB에 해시를 저장하세요.
});

---
const hashedPassword = await bcrypt.hash(result.data.password, 12); 
//해싱 알고리즘을 12번 실행하겠다

iron-session

• JavaScript에서 사용되는 세션 관리 라이브러리로, 안전성과 stateless(무상태) 특징을 갖춘 쿠키 기반 세션을 제공함
• 쿠키 기반 세션 : 사용자 브라우저에 쿠키를 전송하고, 이 쿠키를 통해 세션을 관리, 사용자가 요청을 보낼 때마다 쿠키가 자동으로 서버로 전송
• Stateless 설계 : 세션 데이터를 서버에 저장하지 않고 쿠키에 저장하므로, 서버는 상태를 유지하지 않아도 됨 => 서버의 부하를 줄이고 확장성을 높이는데 유리함
• 데이터 암호화 및 복호화 : 단순히 사용자 데이터를 쿠키에 저장하면 보안 문제가 발생할 수 있어 Iron-Session은 데이터를 암호화하여 쿠키에 저장하고, 서버에서 복호화하여 사용함

npm i iron-session
https://github.com/vvo/iron-session

1password password generator (비밀번호 생성기) https://1password.com/password-generator

배운점 & 느낀점

지금까지 회원가입 프로세스를 공부해보았는데.. 어떤분이 요약해주신게 있어서 올려본다..

1. zod를 이용해서 회원가입 폼을 검증 a. 검증 실패 시, 오류 메세지를 띄움
2. 검증 성공 시, bcrypt를 이용해서 유저가 입력한 비밀번호 해싱 a. 해싱된 비밀번호가 데이터베이스에 저장됨
3. 유저가 입력한 유저명, 이메일, 해싱된 비밀번호를 이용해서 DB에 유저를 생성
4. 유저를 성공적으로 생성했다면 브라우저에 쿠키를 반환 a. iron session을 통해 설정한 cookieName에 해당하는 쿠키가 있는 지 확인하고, 없다면 세션 데이터를 암호화하고 쿠키를 설정함 (쿠키를 설정할 때는 쿠키에 저장할 데이터를 암호화하여 저장함)
5. 위 단계를 모두 통과했다면 특정 페이지로 리다이렉트 처리

validator

• 문자열 유효성 검사 라이브러리

  npm i validator
  npm i --save-dev @types/validator

import validator from 'validator';

const isEmailValid = validator.isEmail('test@example.com'); // true
console.log(isEmailValid);

-----

const phoneSchema = z
  .string()
  .trim()
  .refine(
    (phone) => validator.isMobilePhone(phone, "ko-KR"),
    "Wrong phone format"
  );

coerce

• coerce는 기본 값을 강제로 변환
• 내장 생성자(String(input), Number(input), new Date(input) 등))를 사용하여 모든 입력을 강제함

import { z } from 'zod';

const schema = z.object({
  phoneNumber: z.coerce.number(),
});

const result = schema.parse({ phoneNumber: "1234567890" });
console.log(result); // { phoneNumber: 1234567890 }

-----

const tokenSchema = z.coerce.number().min(100000).max(999999);

배운점 & 느낀점

• input의 값은 항상 string으로 오기 때문에 전화번호 같은건 꼭 number로 가져와야 하므로 coerce는 zod와 함께 잘 쓰일 거 같다.
• 앞으로 폼 데이터 처리할 때 적극 활용해봐야겠다.

Prisma

• 데이터베이스와 애플리케이션 사이에서 통역사 역할을 해주는 도구
• 내가 사용하는 데이터베이스에 맞춰 필요한 파일이나 마이그레이션 파일을 자동으로 생성해주기 때문에 정말 유용함
• SQL을 몰라도 데이터베이스를 효율적으로 다룰 수 있게 도와줘서 개발 초보자에게도 유용함

Prisma 기능 및 장점

1. 데이터베이스 스키마 정의
2. 자동 마이그레이션
3. 타입 안전성 제공
4. 다양한 데이터베이스 지원
5. 빠른 생산성

1. Prisma 설치와 초기화

• vscode 확장 프로그램에서 "Prisma" 설치하면 도움됨
• 설치

  npm i prisma

• 초기화

  npx prisma init

초기화 결과

• prisma/schema.prisma 파일 생성: 이 파일에서 데이터베이스의 구조와 규칙(스키마)을 정의.
• .env 파일 생성: 데이터베이스에 접속하기 위한 DATABASE_URL 환경 변수가 여기에 저장.
• 중요: .env 파일에는 중요한 정보가 들어 있으므로 절대 깃헙에 올리지 않도록 .gitignore에 포함해야 합니다.

.env 파일 수정

DATABASE_URL="file:./database.db"

2. SQLite와 Prisma

• 초보자가 배우기엔 SQLite가 쉽고, 로컬에서 실행할 수 있어 추천함
• 추가로 VSCode에서 SQLite Viewer 확장 프로그램을 설치하면 데이터베이스를 시각적으로 볼 수 있어 편리함

3. Prisma Schema와 Models

• 애플리케이션 도메인의 엔터티를 나타냅다.
• 데이터베이스의 테이블(PostgreSQL과 같은 관계형 데이터베이스) 또는 컬렉션(MongoDB)에 매핑
• 모델(Model)은 데이터베이스에서 테이블과 비슷한 개념으로, 우리가 다룰 데이터를 어떻게 저장할지 정의한다.

Schema 파일 (schema.prisma)

• schema.prisma는 데이터베이스에 어떤 데이터가 저장될지 설명한다.

  model User {
  id             Int     @id @default(autoincrement())//기본 키, 자동 증가
  username         String     @unique                     .//고유값
  email         String? @unique                        // 선택적 필드 (?)
  password         String?
  phone         String? @unique
  githubId         String? @unique
  avatar         String?                                //이미지 넣을때(깃허브면 프로필 사진 저장 가능)
  createdAt     DateTime @default(now())            //생성 시간
  updatedAt     DateTime @updatedAt                    //수정 시간
  }

<save 시 릴레이션 자동완성 방법>

플러그인 prisma 다운
cmd + shift + p로 JSON settings 파일을 열고

"[prisma]": {
"editor.defaultFormatter": "Prisma.prisma"
}

4. 마이그레이션(Migrations)

• 스키마 파일을 수정한 후, 데이터베이스에 반영하려면 마이그레이션이 필요하다.

  npx prisma migrate dev
  

Enter a name for the new migration: -> 이름을 정해주고 엔터 (예시: add_user, smstoken)

- 새로운 마이그레이션 파일을 생성하고 변경 사항을 데이터베이스에 적용
- 개발 환경에서만 사용! 프로덕션 환경에서는 사용 금지!
- Prisma는 mpx prisma generate 명령어도 같이 실행한다.

### 5. Prisma Client
- Prisma Client는 Prisma가 자동으로 생성해주는 타입 안전한 쿼리 빌더이다.
- 데이터베이스와 상호작용할 때 사용할 수 있다.
- 설치

npm install @prisma/client

- 사용 예시
``` jsx
  import { PrismaClient } from "@prisma/client";
  const db = new PrismaClient();

  async function createUser() {
    await db.user.create({
      data: {
        username: "홍길동",
        phone: "010-1234-5678",
      },
    });
  }

  createUser();

//export default db;

6. Prisma Studio

• Prisma Studio는 데이터베이스를 시각적으로 관리할 수 있는 UI(편집기)
• Prisma 스키마 파일에 정의된 모든 모델 목록을 확인하고 데이터베이스를 관리할 수 있다.
• Client의 어드민을 위한 UI

  npx prisma studio

• http://localhost:5555/ 로 열림
• 새로운 사용자를 추가하거나 새로운 모델을 만드는 것과 같은 것을 하고 싶다면 schema.prisma 파일을 수정하고 migrate한 다음 변경사항을 studio에 반영하고 싶다면 studio를 끄고 npx prisma studio 재시작하는걸 추천

  schema.prisma 파일 수정 npx prisma migrate dev로 마이그레이션 적용 Studio를 다시 실행 (npx prisma studio)

7. Relations

• Relation는 Prisma 스키마의 두 모델 간의 연결이다.
• Relation(관계)는 데이터의 구조를 설계하고, 관련된 데이터를 효율적으로 조회하고나 조작할 수 있도록 도와준다.
• @relation(fields, references) : 관계를 정의하고, 외래 키 필드와 참조되는 모델의 필드를 연결.

model SMSToken {
  // id         Int      @id @default(autoincrement())
  id Int @id @default(autoincrement())
  token      String   @unique
  created_at DateTime @default(now())
  updated_at DateTime @updatedAt
  user       User     @relation(fields: [userId], references: [id])
  userId     Int
}

//user       User 까지만 작성하면 자동완성으로 relation은 나옴!! -편안-

8. onDelete

• Relations(관계)로 작업을 할 때 꼭 알아야 함.
• 위 SMSToken 코드를 보면 user는 필수값이다. (물음표가 없기 때문)
• 필수값인 경우에는 삭제를 못한다.
• 서로 연관된 모델이 지워질때 삭제가 가능해진다.
• onDelete 행위는 늘 고려해야한다.

model SMSToken {
  // id         Int      @id @default(autoincrement())
  id Int @id @default(autoincrement())
  token      String   @unique
  created_at DateTime @default(now())
  updated_at DateTime @updatedAt
  user       User     @relation(fields: [userId], references: [id], onDelete: Cascade)
  userId     Int
}

onDelete

Cascade: 참조 레코드를 삭제하면 참조 레코드의 삭제가 트리거된다. (사용자가 삭제됐을때 사용자가 연결된 모든 SMSToken들도 같이 지워진다) Restrict: 참조 레코드가 있는 경우 삭제를 방지한다. NoAction: Restrict과 유사하지만 사용 중인 데이터베이스에 따라 다르다. SetNull: 참조 필드가 NULL로 설정된다. (optional일 때만 정상 작동/사용자가 삭제됐을때 null로 설정) SetDefault: 참조 필드가 기본값으로 설정된다.

배운점 & 느낀점

초기 설정이 좀 복잡해보이기는 하는데 다른 데이터베이스를 다루는 프로그램(?)보다는 단순하다고 하니 열심히 연습해봐야겠다. db 초기 설계만 잘끝낸다면 분명 좋은 프로젝트가 완성되지 않을까 하는 기대가 생긴다!

Zod에는 몇 가지 문자열 관련 유효성 검사가 포함되어 있다. (https://zod.dev/?id=strings)

문자열 스키마를 만들 때 몇 가지 오류 메시지를 지정할 수 있다. const name = z.string({ required_error: "Name은 필수입니다.", invalid_type_error: "Name은 문자열이어야 합니다.", });

유효성 검사 메서드를 사용할 때 추가 인수를 전달하여 사용자 지정 오류 메시지를 제공할 수 있다. z.string().min(5, { message: "5글자 이상 되어야합니다." });

.refine 메서드를 통해 사용자 지정 유효성 검사를 할 수 있다. (https://zod.dev/?id=refine) z.string().refine((val) ⇒ val.length ≤ 255, {message: “255이하의 문자열이어야 합니다.”});

.refine 은 2개의 인수를 받습니다.

1. 유효성 검사 함수
2. 몇가지 옵션 제공되는 옵션은 다음과 같습니다.

• message: 에러 메세지 지정
• path: 에러 경로 지정
• params: 에러시 메세지를 커스텀하기 위해 사용되는 객체