<h2>요약</h2>
<p>HuJSON (Human JSON)은 Tailscale이 구현한 JWCC (JSON With Commas and Comments) 포맷의 Go 라이브러리이다. JWCC는 표준 JSON에 <strong>주석</strong>과 <strong>후행 쉼표</strong> 두 가지만 추가한 최소 확장 포맷으로, 사람이 직접 편집하는 설정 파일 용도로 설계되었다.</p>
<h2>핵심 포인트</h2>
<h3>JWCC가 JSON에 추가하는 것 (딱 두 가지)</h3>
<ol>
<li><strong>주석</strong>: <code>// 라인 주석</code>과 <code>/* 블록 주석 */</code> — JSON에서 공백이 허용되는 모든 위치에 삽입 가능</li>
<li><strong>후행 쉼표</strong>: <code>[1, 2, 3,]</code>처럼 마지막 요소 뒤에 쉼표 허용</li>
</ol>
<p>이 두 가지는 설정 파일에서 가장 빈번하게 요청되는 기능이면서, JSON의 객체 모델을 변경하지 않는다. 모든 유효한 JSON은 유효한 JWCC이므로 하위 호환성이 완벽하다.</p>
<h3>왜 JSON5/YAML/TOML이 아닌가</h3>
<p>JWCC의 핵심 설계 원칙은 &quot;clarity, not terseness&quot; (간결함보다 명확함)이다.</p>
<table>
<thead>
<tr>
<th>거부된 기능</th>
<th>이유</th>
</tr>
</thead>
<tbody><tr>
<td>따옴표 없는 키/값 (JSON5, HJSON)</td>
<td>미래 키워드 추가를 차단, 파싱 모호성</td>
</tr>
<tr>
<td><code>NaN</code>/<code>Inf</code> (JSON5)</td>
<td>JSON과 다른 객체 모델 → 호환성 파괴</td>
</tr>
<tr>
<td>들여쓰기 기반 구조 (YAML)</td>
<td>공백 민감성으로 인한 파싱 사고</td>
</tr>
<tr>
<td>복합 데이터 타입 (TOML, CUE)</td>
<td>설정 파일에 비해 과잉 설계</td>
</tr>
</tbody></table>
<p>JSONC(VS Code가 사용하는 형식)와 가장 유사하지만, JSONC는 후행 쉼표 지원 여부가 문서마다 다르고 이름이 모호하다는 문제가 있다. JWCC는 이를 명시적으로 정의한다.</p>
<h3>HuJSON 라이브러리 (Go)</h3>
<p>Tailscale의 <code>github.com/tailscale/hujson</code> 패키지가 JWCC의 참조 구현체 역할을 한다. 주요 워크플로우:</p>
<ol>
<li>HuJSON 입력을 AST로 파싱 (<code>Parse</code>)</li>
<li>주석/후행 쉼표 제거하여 표준 JSON으로 변환 (<code>Minimize</code> / <code>Standardize</code>)</li>
<li>표준 JSON을 <code>encoding/json</code> 등 기존 JSON 라이브러리로 처리</li>
</ol>
<p>이 접근 방식 덕분에 기존 JSON 파서를 수정하지 않고도 HuJSON을 지원할 수 있다.</p>
<h3>실제 사용처</h3>
<ul>
<li><strong>Tailscale ACL</strong>: tailnet 정책 파일이 HuJSON 형식으로 작성됨</li>
<li><strong>Headscale ACL</strong>: Tailscale 오픈소스 대안인 Headscale도 HuJSON 정책 파일 지원</li>
</ul>
<h2>나의 생각</h2>
<p>JSON 설정 파일의 가장 큰 불편함은 주석을 쓸 수 없다는 것과, diff 충돌을 줄이려고 마지막 요소에 쉼표를 붙이지 못한다는 것이다. JWCC는 이 두 가지만 정확히 해결하고 나머지는 건드리지 않는다는 점에서 실용적이다.</p>
<p>JSON5처럼 따옴표 없는 키를 허용하면 편리해 보이지만, 파서 복잡도가 올라가고 미래 확장과 충돌할 수 있다. &quot;필요한 최소한만 추가&quot;라는 JWCC의 접근은 UNIX 철학과 일맥상통한다.</p>
<p>Headscale ACL 정책 파일에서 실제로 사용하고 있으므로, HuJSON 파서/포맷터 도구를 알아두면 디버깅에 유용할 것이다.</p>
<h2>Links</h2>
<ul>
<li>원본: <span class="wikilink-dead">REF-nigeltao-jwcc-spec</span></li>
<li>원본: <span class="wikilink-dead">REF-tailscale-hujson</span></li>
<li>관련 Permanent Note: [[]]</li>
</ul>


LIT-hujson-jwcc-overview

<h2>요약</h2>
<p>LDAP(Lightweight Directory Access Protocol)은 디렉토리 서비스에 접근하기 위한 표준 프로토콜이다. X.500의 DAP가 OSI 스택 위에서 동작하여 무거웠던 것을 TCP/IP 위에서 경량화한 것이 출발점이며, LDAPv3(RFC 4511, 2006년)에서 독립적인 디렉토리 서비스 프로토콜로 성숙했다. 핵심 설계 철학은 <strong>읽기·검색 최적화</strong>이며, 관계형 데이터베이스와 달리 트리 구조(DIT)에서 속성 기반 데이터를 관리한다.</p>
<h2>핵심 포인트</h2>
<h3>LDAP이란 무엇인가</h3>
<p>LDAP은 <strong>프로토콜</strong>이다. 디렉토리 서비스 자체가 아니라, 디렉토리 서비스에 <strong>접근하는 방법</strong>을 정의한다. 클라이언트(DUA)가 서버(DSA)에 요청을 보내고 응답을 받는 클라이언트-서버 모델이다.</p>
<pre><code>┌─────────┐   LDAP 프로토콜 (TCP/IP)   ┌─────────┐
│ 클라이언트 │ ◄──────────────────────► │   서버    │
│  (DUA)   │   포트 389 또는 636       │  (DSA)   │
└─────────┘                           └─────────┘
                                      디렉토리 데이터
                                      (DIT에 저장)
</code></pre><ul>
<li><strong>DUA (Directory User Agent)</strong>: 클라이언트. 사용자를 대신하여 디렉토리 접근</li>
<li><strong>DSA (Directory System Agent)</strong>: 서버. 디렉토리 정보 관리 및 요청 처리</li>
</ul>
<h3>X.500에서 LDAP으로: 왜 &quot;경량&quot;인가</h3>
<table>
<thead>
<tr>
<th>구분</th>
<th>X.500 DAP</th>
<th>LDAP</th>
</tr>
</thead>
<tbody><tr>
<td>프로토콜 스택</td>
<td>OSI 7계층 전체</td>
<td>TCP/IP</td>
</tr>
<tr>
<td>복잡도</td>
<td>높음 (BER 인코딩 전체)</td>
<td>낮음 (BER의 부분집합)</td>
</tr>
<tr>
<td>구현 난이도</td>
<td>높음</td>
<td>낮음</td>
</tr>
<tr>
<td>데이터 모델</td>
<td>X.500 (원본)</td>
<td>X.500 기반 (간소화)</td>
</tr>
<tr>
<td>배포 환경</td>
<td>폐쇄 네트워크</td>
<td>인터넷</td>
</tr>
</tbody></table>
<p>역사적 흐름:</p>
<ol>
<li><strong>1988</strong>: ITU-T가 X.500 디렉토리 서비스 표준 승인 (X.400 이메일 시스템 지원 목적)</li>
<li><strong>1989-1991</strong>: X.500을 인터넷에 배포하면서 DAP의 무거움 확인</li>
<li><strong>초기 LDAP</strong>: TCP/IP 위에서 X.500 게이트웨이에 접근하는 경량 프로토콜로 개발</li>
<li><strong>LDAPv3 (RFC 4511, 2006)</strong>: 게이트웨이 없이 독립적 디렉토리 서버 프로토콜로 진화</li>
</ol>
<p>핵심: LDAP의 &quot;Lightweight&quot;는 <strong>OSI 스택 대신 TCP/IP를 사용</strong>하고, <strong>X.500 DAP의 기능을 간소화</strong>했다는 의미이다.</p>
<h3>LDAP 프로토콜 연산 10가지</h3>
<p>모든 연산은 LDAPMessage 엔벨로프로 감싸지며, 고유한 messageID로 식별된다. 비동기 처리가 가능하여 여러 요청/응답이 순서 무관하게 교환된다.</p>
<table>
<thead>
<tr>
<th>연산</th>
<th>목적</th>
<th>비유</th>
</tr>
</thead>
<tbody><tr>
<td><strong>Bind</strong></td>
<td>인증 (연결의 신원 설정)</td>
<td>로그인</td>
</tr>
<tr>
<td><strong>Unbind</strong></td>
<td>연결 종료</td>
<td>로그아웃</td>
</tr>
<tr>
<td><strong>Search</strong></td>
<td>조건에 맞는 엔트리 검색</td>
<td>SELECT ... WHERE</td>
</tr>
<tr>
<td><strong>Add</strong></td>
<td>새 엔트리 생성</td>
<td>INSERT</td>
</tr>
<tr>
<td><strong>Delete</strong></td>
<td>엔트리 삭제</td>
<td>DELETE</td>
</tr>
<tr>
<td><strong>Modify</strong></td>
<td>엔트리 속성 변경</td>
<td>UPDATE</td>
</tr>
<tr>
<td><strong>Modify DN</strong></td>
<td>엔트리 이름/위치 변경</td>
<td>RENAME / MOVE</td>
</tr>
<tr>
<td><strong>Compare</strong></td>
<td>특정 속성값 존재 여부 확인</td>
<td>EXISTS 검사</td>
</tr>
<tr>
<td><strong>Abandon</strong></td>
<td>진행 중인 요청 취소</td>
<td>요청 취소</td>
</tr>
<tr>
<td><strong>Extended</strong></td>
<td>확장 연산 (StartTLS 등)</td>
<td>플러그인 연산</td>
</tr>
</tbody></table>
<p>참고: SQL과의 비유는 이해를 돕기 위한 것이며, LDAP은 관계형 모델이 아니라 트리 모델이므로 정확히 대응되지는 않는다.</p>
<h3>디렉토리 서비스 vs 관계형 데이터베이스</h3>
<p>LDAP 디렉토리는 &quot;특수한 데이터베이스&quot;이지만, 관계형 DB와는 설계 목적이 근본적으로 다르다.</p>
<table>
<thead>
<tr>
<th>특성</th>
<th>LDAP 디렉토리</th>
<th>관계형 데이터베이스</th>
</tr>
</thead>
<tbody><tr>
<td><strong>최적화 대상</strong></td>
<td>읽기·검색</td>
<td>읽기·쓰기 균형</td>
</tr>
<tr>
<td><strong>데이터 구조</strong></td>
<td>트리 (DIT)</td>
<td>테이블 (행/열)</td>
</tr>
<tr>
<td><strong>스키마</strong></td>
<td>objectClass 기반</td>
<td>테이블 스키마</td>
</tr>
<tr>
<td><strong>트랜잭션</strong></td>
<td>단일 연산 원자성만</td>
<td>ACID 트랜잭션</td>
</tr>
<tr>
<td><strong>참조 무결성</strong></td>
<td>제한적</td>
<td>강력 (외래 키)</td>
</tr>
<tr>
<td><strong>데이터 성격</strong></td>
<td>안정적, 자주 읽힘</td>
<td>빈번한 변경</td>
</tr>
<tr>
<td><strong>주요 용도</strong></td>
<td>사용자/그룹 관리, 인증</td>
<td>비즈니스 데이터, 트랜잭션</td>
</tr>
<tr>
<td><strong>쿼리 언어</strong></td>
<td>LDAP 검색 필터</td>
<td>SQL</td>
</tr>
</tbody></table>
<p>핵심: LDAP은 <strong>&quot;한 번 쓰고 자주 읽는&quot; 데이터</strong>에 적합하다. 사용자 계정, 조직 구조, 네트워크 자원 정보 등이 대표적이다.</p>
<h3>LDAP 포트와 보안</h3>
<table>
<thead>
<tr>
<th>포트</th>
<th>이름</th>
<th>보안</th>
<th>설명</th>
</tr>
</thead>
<tbody><tr>
<td>389</td>
<td>LDAP</td>
<td>비암호화 또는 StartTLS</td>
<td>평문으로 시작 후 StartTLS로 암호화 전환 가능</td>
</tr>
<tr>
<td>636</td>
<td>LDAPS</td>
<td>TLS/SSL</td>
<td>연결 시작부터 암호화</td>
</tr>
</tbody></table>
<ul>
<li><strong>StartTLS</strong>: 389 포트에서 평문 연결 후 TLS로 업그레이드. Extended 연산의 일종</li>
<li><strong>LDAPS</strong>: 636 포트에서 연결 시작부터 TLS. RFC에서 공식 표준화되지 않았으나 널리 사용됨</li>
<li><strong>LDAPI</strong>: UNIX 도메인 소켓을 통한 로컬 접근 (<span class="wikilink-dead">LIT-ldapi-summary</span> 참조)</li>
</ul>
<h3>LDAP RFC 시리즈</h3>
<p>LDAPv3는 RFC 4510을 로드맵으로 하는 9개 RFC로 구성된다:</p>
<table>
<thead>
<tr>
<th>RFC</th>
<th>내용</th>
</tr>
</thead>
<tbody><tr>
<td>4510</td>
<td>기술 사양 로드맵</td>
</tr>
<tr>
<td>4511</td>
<td>프로토콜 (연산, 메시지 구조)</td>
</tr>
<tr>
<td>4512</td>
<td>디렉토리 정보 모델 (스키마, DIT)</td>
</tr>
<tr>
<td>4513</td>
<td>인증 방법과 보안 메커니즘</td>
</tr>
<tr>
<td>4514</td>
<td>DN의 문자열 표현</td>
</tr>
<tr>
<td>4515</td>
<td>검색 필터의 문자열 표현</td>
</tr>
<tr>
<td>4516</td>
<td>LDAP URL 형식</td>
</tr>
<tr>
<td>4517-4518</td>
<td>구문, 매칭 규칙, 국제화</td>
</tr>
<tr>
<td>4519</td>
<td>사용자 애플리케이션용 스키마</td>
</tr>
</tbody></table>
<h3>LDAP의 3대 핵심 용도</h3>
<ol>
<li><strong>인증 (Authentication)</strong>: 사용자가 누구인지 확인 (Bind 연산)</li>
<li><strong>인가 (Authorization)</strong>: 사용자가 무엇을 할 수 있는지 결정 (ACL, 그룹 멤버십)</li>
<li><strong>사용자 정보 관리</strong>: 이름, 이메일, 소속, 권한 등 중앙 관리</li>
</ol>
<p>이 세 가지가 LDAP이 거의 모든 기업 인프라에 존재하는 이유이다.</p>
<h3>주요 LDAP 구현체</h3>
<table>
<thead>
<tr>
<th>구현체</th>
<th>설명</th>
</tr>
</thead>
<tbody><tr>
<td><strong>OpenLDAP</strong></td>
<td>오픈소스 LDAP 서버. MDB 백엔드, OLC(cn=config) 설정 (<a href="/blog/LIT-slapd-overview">LIT-slapd-overview</a> 참조)</td>
</tr>
<tr>
<td><strong>389 Directory Server</strong></td>
<td>Red Hat 후원 오픈소스. Red Hat IdM/FreeIPA의 기반 (<span class="wikilink-dead">LIT-389-directory-server-overview</span> 참조)</td>
</tr>
<tr>
<td><strong>Active Directory</strong></td>
<td>Microsoft의 디렉토리 서비스. LDAP + Kerberos + DNS 통합</td>
</tr>
<tr>
<td><strong>FreeIPA</strong></td>
<td>389 DS + MIT Kerberos + DNS + 인증서 관리 통합 (<a href="/blog/LIT-freeipa-overview">LIT-freeipa-overview</a> 참조)</td>
</tr>
<tr>
<td><strong>Apache Directory Server</strong></td>
<td>Apache Foundation의 Java 기반 LDAP 서버</td>
</tr>
</tbody></table>
<h2>나의 생각</h2>
<ul>
<li>LDAP의 본질은 **&quot;네트워크상의 전화번호부 프로토콜&quot;**이다. 전화번호부처럼 자주 찾아보지만 내용은 잘 바뀌지 않는 데이터를 트리 구조로 관리하고 빠르게 검색하는 것이 핵심 목적이다. [추론]</li>
<li>&quot;Lightweight&quot;라는 이름이 오해를 일으킬 수 있다. LDAP 자체가 단순하다는 뜻이 아니라, <strong>X.500 DAP에 비해</strong> 가볍다는 의미이다. 실제로 LDAP은 스키마, 리플리케이션, ACL 등 상당히 복잡한 체계를 가지고 있다. [추론]</li>
<li>이 vault의 기존 노트들과의 관계: <code>LIT-LDAP-data-model-summary</code>가 다루는 DN/RDN/objectClass는 LDAP이 <strong>무엇을 관리하는가</strong>(데이터 모델)에 해당하고, 이 노트의 연산/프로토콜은 <strong>어떻게 접근하는가</strong>(프로토콜)에 해당한다. 둘을 합쳐야 LDAP의 전체 그림이 된다.</li>
<li>디렉토리 서비스가 DB와 다른 가장 핵심적인 차이는 <strong>읽기 편향 최적화</strong>와 <strong>트리 기반 네임스페이스</strong>이다. 이 두 가지 설계 선택이 LDAP의 모든 특성(단일 연산 원자성, 제한적 참조 무결성, DIT 구조)을 결정한다. [추론]</li>
</ul>
<h2>Links</h2>
<ul>
<li>원본: <span class="wikilink-dead">REF-rfc4511-ldap-protocol</span></li>
<li>관련 (데이터 모델): <span class="wikilink-dead">LIT-ldap-data-model-summary</span></li>
<li>관련 (OpenLDAP): <a href="/blog/LIT-slapd-overview">LIT-slapd-overview</a></li>
<li>관련 (389 DS): <span class="wikilink-dead">LIT-389-directory-server-overview</span></li>
<li>관련 (LDAPI): <span class="wikilink-dead">LIT-ldapi-summary</span></li>
<li>관련 (FreeIPA): <a href="/blog/LIT-freeipa-overview">LIT-freeipa-overview</a></li>
<li>관련 (Kerberos): <span class="wikilink-dead">LIT-kerberos-implementations-overview</span></li>
<li>관련 (디렉토리 식별자 비교): <span class="wikilink-dead">LIT-directory-object-identifier-comparison</span></li>
<li>관련 Permanent Note: [[]]</li>
</ul>


LIT-ldap-overview

<h2>요약</h2>
<p>Linux에서 블록 디바이스를 식별하는 방법은 10가지 이상 존재하며, 각 방법은 스토리지 스택의 서로 다른 레이어에서 동작한다. 커널 디바이스 이름(<code>/dev/sdX</code>)은 부팅마다 변경될 수 있으므로, 안정적인 시스템 운영을 위해 UUID, PARTUUID 등 지속적 식별자를 사용해야 한다.</p>
<h2>핵심 포인트</h2>
<h3>1. UUID (Universally Unique Identifier) - 파일시스템 수준</h3>
<ul>
<li>파일시스템 포맷 시 자동 생성되는 128비트 식별자 (8-4-4-4-12 형식)</li>
<li>모든 Linux 파일시스템이 지원 (FAT/exFAT/NTFS는 더 짧은 형식 사용)</li>
<li>파일시스템을 다시 포맷하면 새로 생성됨</li>
<li>하드웨어 이동에도 유지됨 (콘텐츠 기반 식별)</li>
<li>조회: <code>blkid -s UUID</code>, <code>lsblk -o UUID</code>, <code>/dev/disk/by-uuid/</code></li>
<li><strong>fstab에서 가장 널리 권장되는 식별 방법</strong></li>
</ul>
<h3>2. PARTUUID (Partition UUID) - 파티션 테이블 수준</h3>
<ul>
<li>GPT: 파티션 엔트리에 저장된 128비트 UUID. 파일시스템 변경에도 유지됨</li>
<li>MBR: libblkid가 pseudo-PARTUUID 생성 (<code>SSSSSSSS-PP</code> 형식). 파티션 번호 변경 시 바뀔 수 있음</li>
<li>파일시스템과 독립적 -- 포맷해도 변경되지 않음</li>
<li>initramfs 없이도 커널이 직접 해석 가능 (임베디드 시스템에서 유용)</li>
<li>조회: <code>blkid -s PARTUUID</code>, <code>lsblk -o PARTUUID</code>, <code>/dev/disk/by-partuuid/</code></li>
<li><strong>가상 블록 디바이스(md RAID, LVM LV)에는 존재하지 않음</strong></li>
</ul>
<h3>3. LABEL (파일시스템 라벨) - 파일시스템 수준</h3>
<ul>
<li>사용자가 직접 설정하는 이름. 가독성이 좋음</li>
<li>최대 길이가 파일시스템마다 다름: ext4=16자, XFS=12자, Btrfs=256자, FAT=11자</li>
<li>설정 도구: <code>e2label</code>(ext), <code>xfs_admin -L</code>(XFS), <code>btrfs filesystem label</code>(Btrfs), <code>fatlabel</code>(FAT)</li>
<li>시스템 전체에서 고유해야 함. 디스크 복제 시 충돌 발생 가능</li>
<li>조회: <code>blkid -s LABEL</code>, <code>lsblk -o LABEL</code>, <code>/dev/disk/by-label/</code></li>
</ul>
<h3>4. PARTLABEL (GPT 파티션 라벨) - 파티션 테이블 수준</h3>
<ul>
<li>GPT 파티션 엔트리 헤더에 정의. 최대 72자</li>
<li>파일시스템 타입과 독립적. 포맷해도 유지됨</li>
<li>MBR에는 PARTLABEL 개념 없음 (GPT 전용)</li>
<li>설정 도구: <code>gdisk</code>, <code>cgdisk</code></li>
<li>조회: <code>blkid -s PARTLABEL</code>, <code>lsblk -o PARTLABEL</code>, <code>/dev/disk/by-partlabel/</code></li>
</ul>
<h3>5. 디바이스 경로 (커널 네이밍) - 커널 수준</h3>
<table>
<thead>
<tr>
<th>패턴</th>
<th>대상</th>
<th>예시</th>
</tr>
</thead>
<tbody><tr>
<td><code>/dev/sd[a-z][1-9]</code></td>
<td>SCSI/SATA/SAS/USB</td>
<td><code>/dev/sda1</code></td>
</tr>
<tr>
<td><code>/dev/nvme[C]n[N]p[P]</code></td>
<td>NVMe (컨트롤러C, 네임스페이스N, 파티션P)</td>
<td><code>/dev/nvme0n1p1</code></td>
</tr>
<tr>
<td><code>/dev/vd[a-z][1-9]</code></td>
<td>VirtIO (KVM/QEMU)</td>
<td><code>/dev/vda1</code></td>
</tr>
<tr>
<td><code>/dev/hd[a-d]</code></td>
<td>IDE (레거시)</td>
<td><code>/dev/hda1</code></td>
</tr>
<tr>
<td><code>/dev/xvd[a-z]</code></td>
<td>Xen</td>
<td><code>/dev/xvda1</code></td>
</tr>
</tbody></table>
<ul>
<li>커널이 디바이스를 발견하는 순서에 따라 할당 -&gt; 부팅마다 변경 가능</li>
<li>NVMe의 네임스페이스: NVMe SSD를 독립적인 논리 블록 주소 범위로 분할하는 기능. 대부분의 드라이브는 단일 네임스페이스(n1) 사용</li>
<li><strong>fstab이나 중요 설정에 사용하면 안 됨</strong></li>
</ul>
<h3>6. by-id - 하드웨어 시리얼 수준</h3>
<ul>
<li>하드웨어 시리얼 번호 기반 식별. <code>/dev/disk/by-id/</code></li>
<li>접두사로 전송 방식을 나타냄: <code>ata-</code>, <code>scsi-</code>, <code>nvme-</code>, <code>usb-</code>, <code>wwn-</code></li>
<li>형식 예시: <code>ata-Samsung_SSD_860_EVO_250GB_S3YJNB0K123456-part1</code></li>
<li>파일시스템 변경에도 유지되지만, 디바이스를 다른 컨트롤러로 이동하면 변경될 수 있음</li>
<li>파티션은 <code>-partN</code> 접미사 추가</li>
<li>WWN 심볼릭 링크도 이 디렉토리에 제공됨</li>
</ul>
<h3>7. by-path - 물리 경로 수준</h3>
<ul>
<li>PCI 물리 경로 기반 식별. <code>/dev/disk/by-path/</code></li>
<li>형식 예시: <code>pci-0000:03:00.0-nvme-1-part1</code></li>
<li>디바이스가 같은 컨트롤러의 다른 포트로 이동하면 변경됨</li>
<li>&quot;하드웨어 변경에 내성 있는 지속적 네이밍에 적합하지 않음&quot;</li>
<li>인프라 문서화 용도로만 권장</li>
</ul>
<h3>8. WWN (World Wide Name) - 하드웨어 고유 식별자</h3>
<ul>
<li>디바이스 제조사가 하드코딩한 전세계 고유 식별자</li>
<li>8바이트(64비트) 또는 16바이트(128비트). 16진수로 표현</li>
<li><code>/dev/disk/by-id/</code> 에 <code>wwn-0x...</code> 형식으로 심볼릭 링크 제공</li>
<li>Fibre Channel, SATA, SAS, SCSI, NVMe 등에서 사용</li>
<li>하드웨어 변경(포트, 컨트롤러 이동)에도 완전히 유지 -- 가장 안정적인 하드웨어 식별자</li>
<li>조회: <code>ls -l /dev/disk/by-id/ | grep wwn</code>, <code>scsi_id</code></li>
</ul>
<h3>9. Device Mapper 이름 - 가상화 레이어</h3>
<ul>
<li><code>/dev/mapper/&lt;VG&gt;-&lt;LV&gt;</code> 형식 (LVM)</li>
<li><code>/dev/mapper/&lt;이름&gt;</code> (LUKS/dm-crypt)</li>
<li>커널 내부 이름: <code>/dev/dm-N</code> (마이너 번호 순, 사용 지양)</li>
<li>LVM 경로(<code>/dev/VG/LV</code>)는 이미 지속적 네이밍 제공</li>
<li><code>lvm(8)</code>은 fstab에 <code>/dev/VG/LV</code> 형식 사용을 권장 (<code>/dev/mapper/VG-LV</code>는 내부 사용)</li>
</ul>
<h3>10. MD 디바이스 네이밍 - RAID 레이어</h3>
<ul>
<li><code>/dev/md0</code>, <code>/dev/md1</code>, <code>/dev/md127</code> 등</li>
<li>mdadm.conf에 등록된 어레이는 안정적인 이름, 미등록 어레이는 부팅마다 변경 가능</li>
<li>md 어레이 자체 UUID를 슈퍼블록에 저장 (파일시스템 UUID와는 별개)</li>
<li><code>/dev/disk/by-id/md-uuid-*</code> 심볼릭 링크 제공</li>
</ul>
<h3>MD RAID 디바이스에 PARTUUID가 없는 이유</h3>
<ol>
<li><strong>PARTUUID는 파티션 테이블에서 유래</strong>: GPT의 각 파티션 엔트리, 또는 MBR의 디스크 시그니처+파티션 번호에서 생성</li>
<li><strong>MD 디바이스는 가상 블록 디바이스</strong>: 커널의 md 드라이버가 생성하며, 어떤 물리적 파티션 테이블에도 엔트리로 존재하지 않음</li>
<li><strong>파티션 레이어 위에 위치</strong>: 스토리지 스택에서 MD는 파티션 위에 존재:<pre><code>물리 디스크 → 파티션 (PARTUUID 존재) → MD RAID (PARTUUID 없음) → 파일시스템 (UUID 존재)
</code></pre></li>
<li><strong>구성 파티션은 PARTUUID를 가짐</strong>: <code>/dev/sda1</code>, <code>/dev/sdb1</code>은 각각 PARTUUID가 있지만, 이들로 조립된 <code>/dev/md0</code>는 파티션 테이블에 없으므로 PARTUUID 없음</li>
<li><strong>mdadm은 자체 메타데이터를 사용</strong>: PARTUUID를 신경 쓰지 않고, 슈퍼블록의 어레이 UUID로 식별</li>
<li><strong>예외</strong>: md 디바이스 자체에 파티션 테이블을 만들면(md 위에 GPT 작성) 그 파티션들은 PARTUUID를 가지게 됨</li>
</ol>
<h3>지속성 종합 비교</h3>
<table>
<thead>
<tr>
<th>식별 방법</th>
<th>스택 레이어</th>
<th>리포맷 시</th>
<th>하드웨어 이동 시</th>
<th>디스크 복제 시</th>
<th>파티셔닝 변경 시</th>
</tr>
</thead>
<tbody><tr>
<td>UUID</td>
<td>파일시스템</td>
<td>변경됨</td>
<td>유지</td>
<td>충돌</td>
<td>유지</td>
</tr>
<tr>
<td>PARTUUID</td>
<td>파티션 테이블</td>
<td>유지</td>
<td>유지</td>
<td>충돌(GPT)/변경가능(MBR)</td>
<td>변경됨</td>
</tr>
<tr>
<td>LABEL</td>
<td>파일시스템</td>
<td>변경됨</td>
<td>유지</td>
<td>충돌</td>
<td>유지</td>
</tr>
<tr>
<td>PARTLABEL</td>
<td>파티션 테이블</td>
<td>유지</td>
<td>유지</td>
<td>충돌</td>
<td>변경됨</td>
</tr>
<tr>
<td>by-id</td>
<td>하드웨어</td>
<td>유지</td>
<td>컨트롤러 변경 시 변경</td>
<td>고유</td>
<td>유지</td>
</tr>
<tr>
<td>by-path</td>
<td>PCI 경로</td>
<td>유지</td>
<td>변경됨</td>
<td>N/A</td>
<td>유지</td>
</tr>
<tr>
<td>WWN</td>
<td>하드웨어</td>
<td>유지</td>
<td>유지</td>
<td>고유</td>
<td>유지</td>
</tr>
<tr>
<td>/dev/sdX</td>
<td>커널</td>
<td>유지</td>
<td>변경 가능</td>
<td>N/A</td>
<td>유지</td>
</tr>
<tr>
<td>/dev/mapper/VG-LV</td>
<td>LVM</td>
<td>유지</td>
<td>유지</td>
<td>충돌</td>
<td>N/A</td>
</tr>
<tr>
<td>/dev/mdN</td>
<td>md RAID</td>
<td>유지</td>
<td>유지</td>
<td>설정 의존</td>
<td>N/A</td>
</tr>
</tbody></table>
<h3>fstab 모범 사례 요약</h3>
<ul>
<li><strong>일반적인 경우</strong>: UUID 사용 (가장 안전)</li>
<li><strong>자주 포맷하는 파티션</strong>: PARTUUID 사용</li>
<li><strong>initramfs 없는 시스템</strong>: PARTUUID 사용 (커널 직접 해석)</li>
<li><strong>LVM 볼륨</strong>: <code>/dev/VG/LV</code> 사용 (이미 지속적)</li>
<li><strong>MD RAID</strong>: UUID 또는 LABEL 사용 (PARTUUID 불가)</li>
<li><strong>절대 사용 금지</strong>: <code>/dev/sdX</code> 등 커널 디바이스 이름</li>
</ul>
<h2>나의 생각</h2>
<p>디스크 식별 방법은 스토리지 스택의 계층적 구조를 그대로 반영한다. 물리 하드웨어(WWN, by-id) -&gt; PCI 경로(by-path) -&gt; 파티션 테이블(PARTUUID, PARTLABEL) -&gt; 파일시스템(UUID, LABEL) -&gt; 가상화 레이어(LVM, md RAID) 순으로 각 계층마다 고유한 식별 체계가 존재한다. MD RAID에 PARTUUID가 없는 것은 이 계층 구조에서 자연스러운 결과이며, 가상 블록 디바이스는 자체 메타데이터(md 슈퍼블록, LVM 메타데이터)로 식별한다는 원칙을 보여준다.</p>
<h2>Links</h2>
<ul>
<li>원본: <span class="wikilink-dead">REF-archwiki-persistent-block-device-naming</span></li>
<li>원본: <span class="wikilink-dead">REF-linux-device-path-naming-conventions</span></li>
<li>원본: <span class="wikilink-dead">REF-linux-wwn-world-wide-name</span></li>
<li>원본: <span class="wikilink-dead">REF-linux-device-mapper-lvm-naming</span></li>
<li>원본: <span class="wikilink-dead">REF-linux-md-raid-device-naming</span></li>
<li>원본: <span class="wikilink-dead">REF-linux-fstab-identification-best-practices</span></li>
<li>관련 Permanent Note: [[]]</li>
<li>관련 Reference Note: <span class="wikilink-dead">REF-lvm</span></li>
<li>관련 Reference Note: <span class="wikilink-dead">REF-luks</span></li>
</ul>


LIT-linux-disk-identification-overview

<h2>요약</h2>
<p>BDB(Berkeley DB)와 LMDB(Lightning Memory-Mapped Database)는 모두 임베디드 key-value 데이터베이스이지만, 설계 철학이 근본적으로 다르다. BDB는 자체 캐시(MPool), WAL, 2PL 등 전통적인 데이터베이스 서브시스템을 모두 갖춘 &quot;미니 RDBMS&quot;이며, LMDB는 OS의 메모리 매핑(mmap)에 캐싱을 위임하고 Copy-on-Write B+Tree로 WAL을 제거한 &quot;OS에 기대는 최소 설계&quot;이다. LMDB는 OpenLDAP의 Howard Chu가 BDB의 캐시 관리 문제를 해결하기 위해 개발했으며, 현재 OpenLDAP, 389 DS, MIT Kerberos 등이 BDB에서 LMDB로 마이그레이션하고 있다.</p>
<h2>핵심 포인트</h2>
<h3>설계 철학의 대비</h3>
<p>BDB와 LMDB의 근본적 차이는 **&quot;데이터베이스가 얼마나 많은 것을 직접 관리하는가&quot;**이다:</p>
<table>
<thead>
<tr>
<th>관심사</th>
<th>BDB</th>
<th>LMDB</th>
</tr>
</thead>
<tbody><tr>
<td>캐시 관리</td>
<td>자체 MPool (LRU)</td>
<td>OS mmap()에 위임</td>
</tr>
<tr>
<td>쓰기 내구성</td>
<td>WAL (데이터 2번 기록)</td>
<td>Copy-on-Write (데이터 1번 기록)</td>
</tr>
<tr>
<td>동시성 제어</td>
<td>2PL (기본) + MVCC (선택)</td>
<td>MVCC (기본, 단일 쓰기자)</td>
</tr>
<tr>
<td>복구</td>
<td>ARIES 기반 undo/redo 로깅</td>
<td>Shadow paging (로그 불필요)</td>
</tr>
<tr>
<td>튜닝</td>
<td>캐시 크기, 잠금 설정 등 다수</td>
<td><strong>Zero-tuning</strong></td>
</tr>
<tr>
<td>코드 크기</td>
<td>수백 KB</td>
<td>~32KB</td>
</tr>
</tbody></table>
<p>BDB는 모든 것을 스스로 관리하는 &quot;자급자족형&quot;이고, LMDB는 OS가 잘하는 일(메모리 관리, 페이지 캐싱)을 OS에 맡기는 &quot;위임형&quot;이다. [추론]</p>
<h3>LMDB가 탄생한 이유: BDB의 캐시 문제</h3>
<p>2009년 Howard Chu가 OpenLDAP 개발자 메일링 리스트에서 제기한 문제:</p>
<ol>
<li><strong>이중 캐싱</strong>: BDB의 MPool과 OS의 파일시스템 캐시가 같은 데이터를 중복 캐싱</li>
<li><strong>캐시 튜닝의 어려움</strong>: MPool 크기를 잘못 설정하면 성능이 급격히 저하</li>
<li><strong>잠금 경합</strong>: 2PL 기반 잠금이 고부하에서 병목</li>
</ol>
<p>LMDB는 이 세 가지를 모두 제거했다: mmap으로 이중 캐싱 제거, 튜닝 파라미터 제거, MVCC로 읽기-쓰기 간 잠금 제거.</p>
<h3>Copy-on-Write B+Tree: WAL 없는 ACID</h3>
<p>LMDB의 가장 혁신적인 설계는 <strong>Write-Ahead Logging 없이 ACID를 보장</strong>하는 것이다:</p>
<pre><code>기존 (BDB):
  1. 변경 내용을 WAL에 기록 (1번째 쓰기)
  2. 실제 데이터 페이지를 수정 (2번째 쓰기)
  → 데이터를 항상 2번 기록

LMDB:
  1. 변경된 페이지를 새 위치에 기록 (1번째이자 마지막 쓰기)
  2. B+Tree 루트를 새 트리로 원자적 갱신 (shadow paging)
  → 데이터를 1번만 기록
</code></pre><p>새 트리가 완전히 기록되기 전에 장애가 발생하면, 루트가 아직 이전 트리를 가리키므로 이전 상태가 그대로 유지된다. 이것이 &quot;copy-on-write&quot;의 내구성 보장 방식이다.</p>
<h3>성능 특성 비교</h3>
<table>
<thead>
<tr>
<th>항목</th>
<th>BDB</th>
<th>LMDB</th>
</tr>
</thead>
<tbody><tr>
<td>읽기 성능</td>
<td>보통</td>
<td><strong>수 배~수십 배 빠름</strong></td>
</tr>
<tr>
<td>읽기 확장성</td>
<td>잠금 경합으로 제한</td>
<td>CPU 코어 수에 선형 비례</td>
</tr>
<tr>
<td>쓰기 처리량</td>
<td>다중 쓰기자 가능</td>
<td>단일 쓰기자 (직렬)</td>
</tr>
<tr>
<td>벌크 로드</td>
<td>보통</td>
<td><strong>최고 수준</strong></td>
</tr>
<tr>
<td>메모리 효율</td>
<td>이중 캐싱 (MPool + OS)</td>
<td>단일 캐싱 (OS만)</td>
</tr>
<tr>
<td>디스크 효율</td>
<td>WAL로 2배 쓰기</td>
<td>1번 쓰기</td>
</tr>
</tbody></table>
<p>LMDB는 <strong>읽기 비중이 높은 워크로드에 최적화</strong>되어 있다. LDAP 디렉토리 서비스, DNS, Kerberos KDC 등은 읽기가 쓰기보다 압도적으로 많으므로, LMDB가 이상적인 선택이다. [추론]</p>
<h3>BDB→LMDB 마이그레이션의 두 가지 원인</h3>
<p>BDB에서 LMDB로의 마이그레이션은 <strong>기술적 이유와 정치적 이유</strong> 두 가지에 의해 가속화되었다:</p>
<ol>
<li><strong>기술적</strong>: LMDB의 성능 우위, zero-tuning, 더 작은 코드베이스</li>
<li><strong>정치적</strong>: 2013년 Oracle의 AGPL 라이선스 변경. BDB가 라이브러리이므로 링크하는 모든 프로그램이 AGPL 호환이어야 함 → 많은 오픈소스 프로젝트에서 사용 불가</li>
</ol>
<p>라이선스 변경이 없었더라도 LMDB가 기술적으로 우월하므로 마이그레이션은 일어났을 것이지만, AGPL 변경이 마이그레이션을 <strong>급격히 가속화</strong>했다. [추론]</p>
<h3>이 vault에서 조사한 프로젝트의 BDB→LMDB 상황</h3>
<table>
<thead>
<tr>
<th>프로젝트</th>
<th>BDB 상태</th>
<th>LMDB 상태</th>
</tr>
</thead>
<tbody><tr>
<td><strong>OpenLDAP</strong></td>
<td>back-bdb, back-hdb (deprecated)</td>
<td><strong>back-mdb가 기본</strong> (2012~)</td>
</tr>
<tr>
<td><strong>389 DS</strong></td>
<td>BDB 백엔드 (deprecated)</td>
<td><strong>LMDB로 마이그레이션 진행 중</strong></td>
</tr>
<tr>
<td><strong>MIT Kerberos</strong></td>
<td>DB2 백엔드 (기본)</td>
<td>LMDB 백엔드 지원 추가</td>
</tr>
</tbody></table>
<p>세 프로젝트 모두 <strong>LDAP/Kerberos 인프라</strong>라는 공통점이 있으며, 읽기 비중이 높은 워크로드 특성상 LMDB가 특히 적합하다.</p>
<h3>BDB의 현재 상태</h3>
<p>BDB는 사실상 <strong>레거시 상태</strong>이다:</p>
<ul>
<li>Oracle의 마지막 릴리스는 약 2020년 (18.1)</li>
<li>AGPL 라이선스로 인해 새 프로젝트에서의 채택이 거의 없음</li>
<li>기존 사용자들이 LMDB, RocksDB 등으로 이탈</li>
<li>그러나 RPM 등 일부 레거시 시스템에서는 여전히 사용 중</li>
</ul>
<h3>LMDB의 제한사항</h3>
<p>LMDB가 만능은 아니다:</p>
<ul>
<li><strong>단일 쓰기자</strong>: 높은 쓰기 동시성이 필요하면 RocksDB 등이 더 적합</li>
<li><strong>디스크 공간 비회수</strong>: 삭제해도 DB 파일 크기가 줄어들지 않음 (compaction 없음)</li>
<li><strong>메모리 매핑 의존</strong>: 32비트 시스템에서 주소 공간 제한</li>
</ul>
<p>쓰기 비중이 높은 워크로드(예: 로그 저장, 시계열 데이터)에는 RocksDB(LSM-Tree 기반)가 더 적합하다. [추론]</p>
<h2>나의 생각</h2>
<ul>
<li>LMDB의 &quot;OS에 위임&quot; 설계는 이 vault에서 반복적으로 나타나는 &quot;중간 레이어 제거&quot; 패턴의 전형이다. Ceph의 BlueStore가 파일시스템 레이어를 제거하고 raw block device를 직접 사용한 것과 같은 맥락이다 (<a href="/blog/LIT-ceph-overview">LIT-ceph-overview</a> 참조). 다만 방향이 반대이다 — BlueStore는 OS 파일시스템을 <strong>우회</strong>하고, LMDB는 OS 메모리 관리를 <strong>활용</strong>한다. [추론]</li>
<li>BDB의 역사는 오픈소스 라이선스 정책이 기술 생태계에 미치는 영향의 사례 연구이다. Sleepycat License → AGPL 변경 하나로 수십 년간 쌓인 생태계가 무너졌다. Heimdal이 미국 수출 규제 때문에 탄생한 것(<span class="wikilink-dead">LIT-kerberos-implementations-overview</span> 참조)과 마찬가지로, 기술 외적 요인이 기술 생태계를 결정적으로 바꾸는 사례이다. [추론]</li>
<li>Howard Chu가 OpenLDAP의 BDB 캐시 문제를 해결하려고 LMDB를 만들었고, 그 LMDB가 OpenLDAP뿐 아니라 389 DS, MIT Kerberos, Monero, Meilisearch 등 전혀 다른 영역에서도 채택된 것은 흥미로운 기술 전파 사례이다. 특정 문제를 위한 해결책이 범용 도구가 된 것이다. [추론]</li>
<li>LMDB의 Copy-on-Write B+Tree는 WAL을 제거함으로써 쓰기 I/O를 절반으로 줄인 것이 핵심이다. 이것은 단순한 최적화가 아니라 <strong>내구성 보장 메커니즘 자체를 교체</strong>한 것이다 — WAL 기반 &quot;실패 시 로그에서 복구&quot; 대신 shadow paging 기반 &quot;실패 시 이전 트리가 그대로 존재&quot;로 전환한 것이다. [추론]</li>
</ul>
<h2>Links</h2>
<ul>
<li>원본: <a href="/blog/REF-bdb-architecture">REF-bdb-architecture</a></li>
<li>원본: <span class="wikilink-dead">REF-lmdb-architecture</span></li>
<li>관련: <a href="/blog/LIT-slapd-overview">LIT-slapd-overview</a></li>
<li>관련: <span class="wikilink-dead">LIT-389-directory-server-overview</span></li>
<li>관련: <span class="wikilink-dead">LIT-kerberos-implementations-overview</span></li>
<li>관련: <a href="/blog/LIT-ceph-overview">LIT-ceph-overview</a></li>
<li>관련 Permanent Note: [[]]</li>
</ul>


LIT-bdb-lmdb-comparison

<h2>요약</h2>
<p>Ceph는 Object, Block, File 스토리지를 하나의 통합 시스템으로 제공하는 오픈소스 분산 스토리지 플랫폼이다. RADOS라는 자율적 분산 객체 저장소를 기반으로 하며, CRUSH 알고리즘으로 중앙 조회 테이블 없이 데이터 위치를 결정한다. 현재 Red Hat/IBM이 활발히 지원하고 있으며, 전 세계 3,000개 이상의 클러스터에서 1 엑사바이트 이상이 배포된 프로덕션 검증 시스템이다.</p>
<h2>핵심 포인트</h2>
<h3>아키텍처 개요</h3>
<p>Ceph의 기반은 <strong>RADOS (Reliable Autonomic Distributed Object Store)</strong> 이다. 모든 데이터는 최종적으로 RADOS 객체로 저장되며, 이 위에 3가지 클라이언트 인터페이스가 구축된다:</p>
<ul>
<li><strong>RGW (RADOS Gateway)</strong>: S3/Swift 호환 오브젝트 스토리지</li>
<li><strong>RBD (RADOS Block Device)</strong>: 스냅샷/클로닝 지원 블록 스토리지</li>
<li><strong>CephFS</strong>: POSIX 호환 분산 파일 시스템</li>
</ul>
<p>이 구조 덕분에 하나의 클러스터에서 오브젝트, 블록, 파일 스토리지를 모두 제공할 수 있다. GlusterFS가 파일 스토리지에 특화된 것과 대조적이다.</p>
<h3>4가지 데몬</h3>
<table>
<thead>
<tr>
<th>데몬</th>
<th>역할</th>
<th>비고</th>
</tr>
</thead>
<tbody><tr>
<td><strong>MON (Monitor)</strong></td>
<td>클러스터 맵 유지, Paxos 합의</td>
<td>과반수 쿼럼 필요</td>
</tr>
<tr>
<td><strong>OSD</strong></td>
<td>데이터 저장, 복제, 복구, 스크러빙</td>
<td>1 OSD ≈ 1 디스크</td>
</tr>
<tr>
<td><strong>MGR (Manager)</strong></td>
<td>모니터링, REST API, 플러그인</td>
<td>Dashboard 등 제공</td>
</tr>
<tr>
<td><strong>MDS</strong></td>
<td>CephFS 메타데이터 관리</td>
<td>다중 활성 인스턴스 확장 가능</td>
</tr>
</tbody></table>
<p>GlusterFS의 3 프로세스(glusterd, glusterfsd, client) 대비 컴포넌트가 더 많지만, 그만큼 각 컴포넌트의 책임이 명확히 분리되어 있다.</p>
<h3>CRUSH 알고리즘</h3>
<p>CRUSH(Controlled Replication Under Scalable Hashing)는 Ceph의 핵심이다. GlusterFS의 DHT와 유사하게 중앙 조회 테이블 없이 데이터 위치를 결정하지만, 결정적인 차이가 있다:</p>
<ul>
<li><strong>장애 도메인 인식</strong>: 복제본이 서로 다른 호스트, 랙, 데이터센터에 배치되도록 CRUSH Map의 계층 구조를 활용</li>
<li><strong>CRUSH Map</strong>: 6개 섹션(Tunables, Devices, Types, Buckets, Rules, Class)으로 구성된 클러스터 토폴로지 맵</li>
<li><strong>디바이스 클래스</strong>: HDD, SSD, NVMe 등을 구분하여 데이터 배치 정책에 활용</li>
</ul>
<p>GlusterFS의 DHT는 32비트 해시 공간의 범위를 brick에 할당하는 비교적 단순한 모델인 반면, CRUSH는 계층적 토폴로지와 장애 도메인을 고려한 더 정교한 배치를 수행한다. 이것이 Ceph가 대규모 클러스터에서 더 유리한 근본 이유이다. [추론]</p>
<h3>Cluster Map (5개 맵)</h3>
<p>Monitor가 관리하는 클러스터 상태 정보:</p>
<ol>
<li><strong>Monitor Map</strong> — 모니터 노드 정보</li>
<li><strong>OSD Map</strong> — OSD 인벤토리, 풀 정의, PG 수</li>
<li><strong>PG Map</strong> — Placement Group 상태/사용률</li>
<li><strong>CRUSH Map</strong> — 물리적 토폴로지</li>
<li><strong>MDS Map</strong> — 메타데이터 서버 상태</li>
</ol>
<h3>Placement Groups (PGs)</h3>
<p>PG는 RADOS 객체와 OSD 사이의 간접(indirection) 레이어이다. 객체를 개별적으로 OSD에 매핑하면 관리가 불가능해지므로, 객체들을 PG로 그룹핑한 후 PG를 OSD에 매핑한다. PG ID는 <code>hash(객체명) mod PG수 + 풀ID</code>로 계산된다.</p>
<p>이 간접 레이어 덕분에 OSD 추가/제거 시 모든 객체가 아닌 일부 PG만 이동하면 되어 리밸런싱 비용이 크게 줄어든다.</p>
<h3>데이터 보호: 복제 vs Erasure Coding</h3>
<p><strong>복제 (Replication)</strong>:</p>
<ul>
<li>Acting Set의 Primary OSD가 쓰기를 수락하고 다른 OSD에 복제</li>
<li>R3(3개 복제본) 권장. R2는 장기적으로 데이터 유실 위험</li>
<li>단순하고 빠르지만 스토리지 오버헤드가 큼 (R3 = 3배)</li>
</ul>
<p><strong>Erasure Coding (EC)</strong>:</p>
<ul>
<li>K+M 청크로 분할 (K개 데이터 + M개 패리티)</li>
<li>M개 장애까지 허용하면서 공간 효율적</li>
<li>Tentacle 릴리스의 <strong>FastEC</strong>로 소규모 I/O 성능이 2~3배 향상</li>
<li>6+2 EC에서 R3의 약 50% 성능, 공간은 33%만 사용</li>
</ul>
<h3>BlueStore (스토리지 백엔드)</h3>
<p>Ceph의 현재 기본 OSD 백엔드이다. 이전 FileStore가 로컬 파일 시스템(XFS) 위에서 동작하여 이중 쓰기 문제가 있었던 것과 달리, BlueStore는 로우 블록 디바이스에 직접 쓴다.</p>
<ul>
<li>RocksDB(BlueFS 위) 로 메타데이터 관리</li>
<li>3단계 디바이스 티어링: WAL(고속) → DB(SSD) → SLOW(HDD)</li>
<li>체크섬 기반 종단 간 데이터 무결성</li>
<li>투명한 압축 (다중 알고리즘)</li>
<li>FileStore 대비 대폭적인 성능 향상</li>
</ul>
<h3>인증: CephX</h3>
<p>Kerberos와 유사한 인증 프로토콜이다. 클라이언트가 Monitor에 세션 키를 요청하고, 이를 통해 OSD 접근 티켓을 획득한다. 티켓 만료 기능으로 탈취에 대비한다.</p>
<h3>데이터 무결성: Scrubbing</h3>
<ul>
<li><strong>일일 경량 스크럽</strong>: 크기/메타데이터 불일치 감지</li>
<li><strong>주간 심층 스크럽</strong>: 체크섬 대비 비트 단위 데이터 비교</li>
</ul>
<h3>현재 상태 (2026년 기준)</h3>
<p>Ceph는 GlusterFS와 대조적으로 매우 활발하게 개발/지원되고 있다:</p>
<ul>
<li>최신 안정 릴리스: <strong>Tentacle (v20.2.0)</strong>, 2025년 11월 출시</li>
<li>매년 새로운 안정 릴리스 주기 (3월 목표)</li>
<li>Red Hat/IBM 상용 지원 지속</li>
<li>Proxmox VE, OpenStack, Kubernetes(Rook) 등 주요 플랫폼과 통합</li>
<li>Bloomberg, DigitalOcean, CERN, 320개+ 통신사에서 프로덕션 운영</li>
</ul>
<h3>GlusterFS와의 핵심 차이점</h3>
<table>
<thead>
<tr>
<th>항목</th>
<th>Ceph</th>
<th>GlusterFS</th>
</tr>
</thead>
<tbody><tr>
<td>스토리지 타입</td>
<td>Object + Block + File 통합</td>
<td>File 전용</td>
</tr>
<tr>
<td>메타데이터</td>
<td>MDS (CephFS용), CRUSH 맵</td>
<td>없음 (DHT)</td>
</tr>
<tr>
<td>데이터 배치</td>
<td>CRUSH (계층적 토폴로지, 장애 도메인)</td>
<td>DHT (선형 해싱)</td>
</tr>
<tr>
<td>스토리지 백엔드</td>
<td>BlueStore (로우 디바이스 직접)</td>
<td>로컬 FS (XFS 등)</td>
</tr>
<tr>
<td>컴포넌트 수</td>
<td>4종 (MON, OSD, MGR, MDS)</td>
<td>3종 (glusterd, glusterfsd, client)</td>
</tr>
<tr>
<td>상용 지원</td>
<td>Red Hat/IBM 활발</td>
<td>EOL (2024.12.31)</td>
</tr>
<tr>
<td>복잡도</td>
<td>높음 (운영 전문성 필요)</td>
<td>낮음 (상대적으로 단순)</td>
</tr>
<tr>
<td>대규모 확장</td>
<td>우수</td>
<td>소중규모에서 우수</td>
</tr>
</tbody></table>
<h2>나의 생각</h2>
<ul>
<li>Ceph의 통합 스토리지 접근(Object + Block + File)은 인프라 단순화에 큰 장점이다. 하나의 클러스터로 다양한 워크로드를 처리할 수 있어 별도 스토리지 시스템을 운영할 필요가 줄어든다.</li>
<li>CRUSH의 장애 도메인 인식은 단순한 consistent hashing보다 훨씬 정교하다. 랙 단위, 데이터센터 단위로 복제본을 분산시킬 수 있어 물리적 장애에 대한 내성이 높다.</li>
<li>단점은 명확한 운영 복잡도이다. MON, OSD, MGR, MDS 4종 데몬을 관리해야 하고, CRUSH Map 설계, PG 수 튜닝 등 전문 지식이 필요하다. GlusterFS가 &quot;설치해서 바로 쓸 수 있는&quot; 느낌이라면, Ceph는 &quot;제대로 설계해야 성능이 나오는&quot; 시스템이다. [추론]</li>
<li>BlueStore의 로우 디바이스 직접 접근 설계는 성능 측면에서 올바른 방향이다. 파일 시스템 레이어를 제거함으로써 이중 쓰기 문제를 근본적으로 해결했다.</li>
<li>FastEC의 등장으로 Erasure Coding의 실용성이 크게 높아졌다. R3 대비 1/3 공간으로 절반의 성능을 제공하므로, 용량 효율이 중요한 환경에서 현실적인 선택지가 되었다.</li>
<li>GlusterFS가 EOL된 현시점에서, 분산 파일 스토리지가 필요한 새 프로젝트는 Ceph(CephFS)가 사실상 유일한 오픈소스 선택지라고 봐도 무방하다. [추론]</li>
</ul>
<h2>Links</h2>
<ul>
<li>원본: <span class="wikilink-dead">REF-ceph-architecture-overview</span></li>
<li>원본: <span class="wikilink-dead">REF-ceph-release-status</span></li>
<li>보조: <span class="wikilink-dead">AUX-glusterfs-vs-ceph-vs-hdfs-comparison</span></li>
<li>관련: <a href="/blog/LIT-glusterfs-overview">LIT-glusterfs-overview</a></li>
<li>관련: <a href="/blog/LIT-bdb-lmdb-comparison">LIT-bdb-lmdb-comparison</a></li>
<li>관련 Permanent Note: [[]]</li>
</ul>


LIT-ceph-overview

<h2>요약</h2>
<p>FreeIPA는 389 Directory Server, MIT Kerberos, Dogtag CA, SSSD, ISC BIND, Certmonger를 통합한 Linux/UNIX 환경의 중앙 집중식 ID 관리 솔루션이다. &quot;Identity, Policy, Audit&quot;의 약자로, 사용자·호스트·서비스 인증, 호스트 기반 접근 제어(HBAC), sudo 규칙, 인증서 관리, DNS를 하나의 시스템으로 관리한다. Active Directory와의 cross-realm 트러스트를 통해 이기종 환경 통합도 지원한다. Red Hat IdM은 FreeIPA의 상용 버전이다.</p>
<h2>핵심 포인트</h2>
<h3>아키텍처: 기존 오픈소스의 조합</h3>
<p>FreeIPA는 새로운 기술을 발명하지 않고, <strong>검증된 오픈소스 구성 요소들을 통합</strong>하는 접근을 취한다:</p>
<table>
<thead>
<tr>
<th>기능</th>
<th>구성 요소</th>
<th>역할</th>
</tr>
</thead>
<tbody><tr>
<td>디렉토리</td>
<td>389 Directory Server</td>
<td>사용자, 그룹, 호스트, 정책 등 모든 데이터의 주 저장소</td>
</tr>
<tr>
<td>인증</td>
<td>MIT Kerberos KDC</td>
<td>SSO 인증. IPA-KDB 플러그인으로 389 DS를 백엔드로 사용</td>
</tr>
<tr>
<td>인증서</td>
<td>Dogtag Certificate System</td>
<td>내부 CA. 인증서 발행·갱신·폐기</td>
</tr>
<tr>
<td>클라이언트</td>
<td>SSSD</td>
<td>클라이언트 측 인증 에이전트. 캐싱, 오프라인 인증</td>
</tr>
<tr>
<td>DNS</td>
<td>ISC BIND + 커스텀 플러그인</td>
<td>도메인 내 DNS 관리. 호스트 등록 시 자동 DNS 생성</td>
</tr>
<tr>
<td>인증서 갱신</td>
<td>Certmonger</td>
<td>인증서 만료 전 자동 갱신</td>
</tr>
</tbody></table>
<p>이 조합은 각 구성 요소를 단독으로 운영할 때의 복잡성을 제거한다. 예를 들어, MIT Kerberos만 단독으로 운영하면 principal 관리, keytab 배포, 데이터베이스 관리를 모두 수동으로 해야 하지만, FreeIPA에서는 <code>ipa user-add</code> 하나로 LDAP 엔트리 + Kerberos principal + 홈 디렉토리 설정이 동시에 이루어진다. [추론]</p>
<h3>IPA-KDB: 389 DS와 MIT Kerberos의 접착제</h3>
<p>IPA-KDB 플러그인은 FreeIPA 아키텍처의 핵심이다. MIT Kerberos의 DAL(Database Abstraction Layer) 인터페이스를 구현하여 <strong>389 DS를 Kerberos 데이터베이스로 사용</strong>하게 한다:</p>
<ul>
<li>IPAv2에서 사용하던 MIT kldap DAL 백엔드를 IPAv3에서 IPA-KDB로 교체</li>
<li>MS-PAC 처리를 통해 AD 트러스트 지원</li>
<li>Kerberos principal과 LDAP 엔트리의 1:1 매핑으로 통합 관리</li>
</ul>
<p>이것은 MIT Kerberos의 LDAP 백엔드 기능(<span class="wikilink-dead">LIT-kerberos-implementations-overview</span> 참조)을 FreeIPA에 특화시킨 것이다. [추론]</p>
<h3>HBAC: 호스트 기반 접근 제어</h3>
<p>HBAC은 FreeIPA의 정책(Policy) 기능 중 가장 핵심적인 것으로, &quot;누가, 어디서, 무엇을 할 수 있는가&quot;를 제어한다:</p>
<ul>
<li><strong>누구 (Who)</strong>: 사용자 또는 사용자 그룹</li>
<li><strong>어디 (Where)</strong>: 호스트 또는 호스트 그룹</li>
<li><strong>무엇 (What)</strong>: 서비스 (SSH, FTP 등)</li>
</ul>
<p>기본적으로 <code>allow_all</code> 규칙이 활성화되어 있으며, 세분화를 위해 이를 비활성화하고 개별 규칙을 생성한다. <code>ipa hbactest</code> 유틸리티로 정책 테스트 후 적용할 수 있어, 잘못된 정책으로 사용자가 잠기는 것을 방지한다.</p>
<h3>Sudo 규칙 중앙 관리</h3>
<p>FreeIPA는 개별 호스트의 <code>/etc/sudoers</code>를 관리하는 대신 <strong>중앙에서 sudo 규칙을 정의하고 배포</strong>한다:</p>
<ul>
<li>User Group, Host Group, Command Group을 사용하여 규칙 단순화</li>
<li>SSSD가 클라이언트에서 FreeIPA의 sudo 규칙을 가져와 적용</li>
<li><strong>주의</strong>: sudo 1.8.23+에서는 HBAC가 먼저 접근을 허용해야 sudo 규칙이 평가됨</li>
</ul>
<p>이것은 HBAC → sudo의 계층 구조로, HBAC이 &quot;문 앞 출입 통제&quot;이고 sudo가 &quot;문 안에서의 권한 제어&quot;라고 이해할 수 있다. [추론]</p>
<h3>AD 트러스트: 이기종 환경 통합</h3>
<p>IPAv3에서 도입된 AD 트러스트는 Samba와의 통합을 통해 구현된다:</p>
<ol>
<li><strong>Cross-realm Kerberos 트러스트</strong> 설정으로 AD 사용자가 IPA 도메인의 서비스에 접근</li>
<li><strong>IPA-KDB 플러그인</strong>이 Kerberos 티켓의 MS-PAC 데이터를 처리</li>
<li><strong>SSSD</strong>가 AD 사용자의 인증 흐름을 처리 (AD KDC → cross-realm → IPA KDC)</li>
<li><strong>IPASAM 백엔드</strong>가 389 DS에서 필요한 데이터를 RPC 서비스에 제공</li>
</ol>
<p>핵심은 AD 사용자가 <strong>IPA 도메인의 HBAC 및 sudo 규칙의 적용을 받는다</strong>는 것이다. AD에서 인증하되, 리소스 접근 권한은 IPA에서 제어한다.</p>
<h3>LDAPI와의 관계</h3>
<p>FreeIPA 서버 내부에서 IPA 프레임워크와 389 DS 간의 통신은 **LDAPI(LDAP over Unix Domain Socket)**를 사용한다 (<span class="wikilink-dead">LIT-ldapi-summary</span> 참조). 이를 통해:</p>
<ul>
<li>비밀번호 없이 SASL EXTERNAL 인증으로 389 DS에 접근</li>
<li>root 프로세스가 cn=Directory Manager로 자동 매핑</li>
<li>네트워크 오버헤드 없는 로컬 통신</li>
</ul>
<h3>4.13.0의 주요 변화</h3>
<p>최신 버전 4.13.0의 주목할 만한 변화:</p>
<ul>
<li><strong>Modern WebUI (Beta)</strong>: 기존 WebUI를 대체할 새 UI 베타</li>
<li><strong>DoT/DoH 지원</strong>: DNS 쿼리의 암호화로 보안 강화</li>
<li><strong>LDAP System Accounts</strong>: 시스템 계정의 완전한 관리 기능</li>
<li><strong>Random Serial Numbers (RSNv3)</strong>: 인증서 일련번호 예측 불가능하게 만들어 보안 강화</li>
<li><strong>170건+ 버그 수정</strong>: FIPS 모드, HSM 지원 등</li>
</ul>
<h3>FreeIPA가 통합하는 기술 스택 전체 그림</h3>
<pre><code>사용자/클라이언트
    │
    ├─ SSSD (클라이언트 에이전트)
    │     ├─ Kerberos 인증 처리
    │     ├─ HBAC 정책 평가
    │     ├─ sudo 규칙 가져오기
    │     └─ 캐싱 / 오프라인 인증
    │
FreeIPA 서버
    │
    ├─ 389 DS ←──LDAPI──→ IPA 프레임워크
    │     └─ 사용자, 그룹, 호스트, 정책, sudo 규칙 저장
    │
    ├─ MIT Kerberos KDC
    │     └─ IPA-KDB 플러그인 → 389 DS 백엔드
    │
    ├─ Dogtag CA
    │     └─ 인증서 발행/갱신/폐기
    │
    ├─ ISC BIND
    │     └─ DNS 관리 (호스트 자동 등록)
    │
    ├─ Certmonger
    │     └─ 인증서 자동 갱신
    │
    └─ Samba (AD 트러스트)
          └─ MS-RPC, Netlogon, IPASAM
</code></pre><h2>나의 생각</h2>
<ul>
<li>FreeIPA의 가치는 개별 구성 요소가 아니라 **통합(integration)**에 있다. 389 DS, MIT Kerberos, Dogtag는 모두 독립적으로 사용할 수 있는 성숙한 소프트웨어이지만, 이들을 하나로 묶어 &quot;사용자 추가 한 번에 모든 것이 설정되는&quot; 경험을 제공하는 것이 FreeIPA의 핵심 가치이다. [추론]</li>
<li>HBAC → sudo의 계층 관계는 잘 설계되어 있다. 호스트 접근 자체를 먼저 제어한 후, 접근이 허용된 호스트에서의 권한을 sudo로 세밀하게 조정하는 것은 Defense-in-Depth 원칙에 부합한다. [추론]</li>
<li>AD 트러스트 구현에서 IPA-KDB의 MS-PAC 처리는 Microsoft의 Kerberos 확장(<span class="wikilink-dead">LIT-kerberos-implementations-overview</span> 참조)을 오픈소스 측에서 호환 구현한 것이다. PAC에 로컬 그룹을 추가(augment)하는 설계는, AD 인증은 AD에서 하되 인가는 IPA에서 하는 명확한 책임 분리를 보여준다. [추론]</li>
<li>FreeIPA는 이 vault에서 조사한 여러 기술의 교차점이다: 389 DS(디렉토리), MIT Kerberos(인증), LDAPI(로컬 통신). 이 각각의 기술이 어떻게 작동하는지 이해하면 FreeIPA의 아키텍처가 자연스럽게 이해된다.</li>
</ul>
<h2>Links</h2>
<ul>
<li>원본: <span class="wikilink-dead">REF-freeipa-architecture</span></li>
<li>원본: <span class="wikilink-dead">REF-freeipa-release-status</span></li>
<li>관련 (LDAP 개요): <a href="/blog/LIT-ldap-overview">LIT-ldap-overview</a></li>
<li>관련: <span class="wikilink-dead">LIT-389-directory-server-overview</span></li>
<li>관련: <span class="wikilink-dead">LIT-kerberos-implementations-overview</span></li>
<li>관련: <span class="wikilink-dead">LIT-ldapi-summary</span></li>
<li>관련: <a href="/blog/LIT-slapd-overview">LIT-slapd-overview</a></li>
<li>관련: <span class="wikilink-dead">LIT-ldap-data-model-summary</span></li>
<li>관련: <span class="wikilink-dead">LIT-directory-object-identifier-comparison</span></li>
<li>관련 Permanent Note: [[]]</li>
</ul>


LIT-freeipa-overview

<h2>요약</h2>
<p>GlusterFS는 여러 서버의 디스크를 하나의 글로벌 네임스페이스로 합치는 오픈소스 분산 파일 시스템이다. 페타바이트 규모까지 확장 가능하고, POSIX 호환이며, 범용 하드웨어에서 동작한다. 가장 큰 아키텍처적 특징은 <strong>메타데이터 서버가 없다</strong>는 것으로, DHT(Distributed Hash Table) 기반의 elastic hashing으로 파일 위치를 결정한다. 다만 2024년 말 Red Hat의 상용 지원이 종료되어, 커뮤니티 주도의 유지보수만 이루어지고 있는 상황이다.</p>
<h2>핵심 포인트</h2>
<h3>아키텍처</h3>
<p>GlusterFS의 핵심은 <strong>메타데이터 서버 없는 설계</strong>이다. 전통적인 분산 파일 시스템(HDFS의 NameNode, CephFS의 MDS)과 달리, 파일명을 32비트 해시 공간에 해싱하여 어느 brick에 저장할지를 알고리즘적으로 결정한다. 이 접근은 메타데이터 서버가 SPOF(단일 장애점)이나 성능 병목이 되는 문제를 근본적으로 제거한다.</p>
<p>시스템은 크게 세 프로세스로 구성된다:</p>
<ul>
<li><strong>Glusterd</strong> (관리 데몬): 각 서버에서 실행, 클러스터 조율</li>
<li><strong>Glusterfsd</strong> (Brick 프로세스): 로컬 디스크 스토리지를 export</li>
<li><strong>Client Process</strong>: 볼륨을 마운트하여 통합 네임스페이스 제공</li>
</ul>
<p>클라이언트와 서버 간 I/O는 <strong>Translator</strong>라는 모듈형 레이어를 통해 처리된다. FUSE를 통해 유저스페이스에서 동작하므로 커널 수정 없이 사용 가능하다.</p>
<h3>볼륨 타입 (5가지)</h3>
<table>
<thead>
<tr>
<th>볼륨 타입</th>
<th>특징</th>
<th>적합 용도</th>
</tr>
</thead>
<tbody><tr>
<td><strong>Distributed</strong></td>
<td>파일을 brick에 분산, 중복 없음</td>
<td>용량 확장 (신뢰성 불필요)</td>
</tr>
<tr>
<td><strong>Replicated</strong></td>
<td>모든 brick에 동일 사본 유지</td>
<td>고가용성, 데이터 이중화</td>
</tr>
<tr>
<td><strong>Distributed Replicated</strong></td>
<td>복제 세트 간 분산</td>
<td>확장 + 신뢰성 동시 필요</td>
</tr>
<tr>
<td><strong>Dispersed</strong></td>
<td>Erasure coding 기반, 공간 효율적 중복</td>
<td>스토리지 효율 + 신뢰성</td>
</tr>
<tr>
<td><strong>Distributed Dispersed</strong></td>
<td>Dispersed의 분산 버전</td>
<td>대규모 erasure coding</td>
</tr>
</tbody></table>
<p>Dispersed 볼륨은 Replicated 대비 스토리지 효율이 높다. 예를 들어 1TB 데이터를 저장할 때 Replicated는 2TB가 필요하지만, Dispersed는 약 1.5TB로 가능하다.</p>
<h3>복제 메커니즘</h3>
<ul>
<li><strong>AFR (Automatic File Replication)</strong>: 확장 속성으로 복제본 일관성 유지. 하나의 brick만 살아있어도 복구 가능.</li>
<li><strong>Geo-Replication</strong>: 비동기 지리적 복제. Changelog 기반 변경 감지 + rsync 차등 동기화.</li>
</ul>
<h3>다른 분산 파일 시스템과의 비교</h3>
<p>GlusterFS는 메타데이터 서버가 없다는 점에서 CephFS, HDFS와 근본적으로 다르다. 중소 규모 클러스터에서 높은 읽기 처리량을 보이지만, 대규모 확장 시에는 CephFS가 더 유리하다는 평가가 있다. HDFS는 write-once/read-many 모델로 빅데이터에 특화되어 있어 범용 파일 시스템 용도로는 GlusterFS와 직접 비교 대상이 아니다.</p>
<h3>현재 상태 (2026년 기준)</h3>
<p>Red Hat이 2024년 12월 31일부로 Red Hat Gluster Storage 상용 지원을 종료했다. 엔지니어링 팀도 해산되어 업스트림 기여가 급감했다 (연간 1,000건+ → 2024년 31건). 오픈소스 커뮤니티가 유지보수를 이어가고 있으나, 새 프로젝트에 GlusterFS를 도입할 때는 이 점을 신중히 고려해야 한다. Fedora에서도 GlusterFS 패키지 퇴역(retire)을 논의한 바 있다.</p>
<h2>나의 생각</h2>
<ul>
<li>메타데이터 서버 없는 설계는 아키텍처적으로 매우 우아하다. SPOF를 제거하는 동시에 운영 복잡도를 줄인다. 그러나 이것이 대규모 확장에서는 오히려 한계가 될 수 있다 — 메타데이터 서버가 있는 시스템(Ceph)이 더 정교한 데이터 배치 결정을 내릴 수 있기 때문이다.</li>
<li>Red Hat 지원 종료는 프로덕션 환경에서의 도입에 큰 리스크 요인이다. 커뮤니티 유지보수만으로는 보안 패치나 버그 수정의 적시성을 보장하기 어렵다.</li>
<li>기존에 GlusterFS를 사용 중인 환경에서는 Ceph로의 마이그레이션을 검토할 시점이다.</li>
<li>Translator 기반 모듈형 아키텍처는 다른 분산 시스템 설계 시 참고할 만한 패턴이다. [추론]</li>
</ul>
<h2>Links</h2>
<ul>
<li>원본: <span class="wikilink-dead">REF-gluster-architecture-overview</span></li>
<li>원본: <span class="wikilink-dead">REF-redhat-glusterfs-eol</span></li>
<li>보조: <span class="wikilink-dead">AUX-glusterfs-vs-ceph-vs-hdfs-comparison</span></li>
<li>관련: <a href="/blog/LIT-ceph-overview">LIT-ceph-overview</a></li>
<li>관련 Permanent Note: [[]]</li>
</ul>


LIT-glusterfs-overview

<h2>요약</h2>
<p>slapd(Standalone LDAP Daemon)는 OpenLDAP 프로젝트의 LDAP 디렉토리 서버이다. 프론트엔드(네트워크/프로토콜)와 백엔드(데이터 저장)가 분리된 모듈형 아키텍처를 가지며, Overlay라는 미들웨어 레이어로 기능을 확장한다. 현재 권장 백엔드는 LMDB 기반의 MDB이며, syncrepl 프로토콜로 Provider/Consumer 복제를 지원한다. 2026년 현재 2.6.x 버전이 활발히 유지보수되고 있다.</p>
<h2>핵심 포인트</h2>
<h3>아키텍처: 프론트엔드/백엔드/Overlay 3계층</h3>
<p>slapd의 아키텍처는 3가지 레이어로 구성된다:</p>
<pre><code>클라이언트 요청
    ↓
[프론트엔드] ← 네트워크 접근, LDAP 프로토콜 처리
    ↓
[Overlay 스택] ← 요청 가로채기, 변환, 기능 확장 (0~N개 적재)
    ↓
[백엔드] ← 데이터 저장/검색
</code></pre><p>이 구조의 핵심 장점은 <strong>각 레이어를 독립적으로 교체/추가</strong>할 수 있다는 것이다. 백엔드를 MDB에서 LDAP 프록시로 바꾸거나, Overlay를 추가하여 비밀번호 정책이나 감사 로깅을 활성화하는 것이 서비스 아키텍처 변경 없이 가능하다.</p>
<p>동시에 임의의 수의 백엔드와 데이터베이스 인스턴스를 운영할 수 있어, 하나의 slapd가 여러 DIT를 서로 다른 백엔드로 서비스할 수도 있다.</p>
<h3>cn=config: 동적 설정</h3>
<p>전통적인 <code>slapd.conf</code> 파일 대신 <strong>LDAP 디렉토리 자체로 설정을 관리</strong>한다. <code>cn=config</code>라는 별도의 DIT가 설정을 담고 있으며, <code>ldapmodify</code> 등의 LDAP 명령으로 설정을 변경할 수 있다. 서비스 재시작이 필요 없다.</p>
<p>이것은 매우 독특한 설계이다 — 설정 자체가 LDAP 데이터이므로, 설정에 대한 접근 제어, 복제, 감사 로깅도 일반 LDAP 데이터와 동일한 메커니즘으로 처리된다. [추론]</p>
<h3>MDB 백엔드 (LMDB)</h3>
<p>현재 권장 기본 백엔드이다. OpenLDAP 자체에서 개발한 <strong>LMDB(Lightning Memory-Mapped Database)</strong> 를 사용하며, 이전의 Berkeley DB(BDB/HDB)를 대체한다.</p>
<p>핵심 특성:</p>
<ul>
<li><strong>캐싱 불필요, 튜닝 없이 최대 성능</strong> — BDB와 달리 캐시 크기, 체크포인트 등을 조정할 필요가 없음</li>
<li><strong>메모리 효율</strong>: back-hdb 대비 RAM 사용량 37%</li>
<li><strong>단일 파일 저장</strong>: 모든 DIT 데이터를 하나의 파일에 저장</li>
<li>Memory-mapped I/O를 사용하여 OS의 페이지 캐시를 그대로 활용</li>
</ul>
<p>BDB가 다양한 튜닝 파라미터(캐시 크기, 체크포인트 간격, IDL 캐시 등)를 요구하고 그에 따라 성능이 크게 좌우되었던 것과 대조적이다. LMDB의 &quot;제로 튜닝&quot; 설계 철학은 운영 복잡도를 크게 줄인다.</p>
<h3>Overlay 시스템</h3>
<p>Overlay는 프론트엔드와 백엔드 사이에 삽입되는 미들웨어로, 17종이 기본 제공된다. 주요 Overlay:</p>
<table>
<thead>
<tr>
<th>Overlay</th>
<th>용도</th>
<th>비고</th>
</tr>
</thead>
<tbody><tr>
<td><strong>syncprov</strong></td>
<td>syncrepl 복제의 provider 측 지원</td>
<td>복제의 핵심</td>
</tr>
<tr>
<td><strong>ppolicy</strong></td>
<td>비밀번호 정책 (만료, 이력, 잠금, 품질)</td>
<td>보안 필수</td>
</tr>
<tr>
<td><strong>memberof</strong></td>
<td>그룹 멤버십 자동 업데이트</td>
<td>그룹 관리 편의</td>
</tr>
<tr>
<td><strong>refint</strong></td>
<td>참조 무결성 유지</td>
<td>엔트리 삭제 시 자동 정리</td>
</tr>
<tr>
<td><strong>accesslog</strong></td>
<td>접근 로그 기록 (별도 DB)</td>
<td>감사/delta-syncrepl에 필요</td>
</tr>
<tr>
<td><strong>unique</strong></td>
<td>속성 값 유일성 강제</td>
<td>이메일 중복 방지 등</td>
</tr>
<tr>
<td><strong>pcache</strong></td>
<td>검색 결과 캐싱</td>
<td>프록시 환경에서 유용</td>
</tr>
<tr>
<td><strong>translucent</strong></td>
<td>원격 LDAP 엔트리의 로컬 오버라이드</td>
<td>하이브리드 디렉토리</td>
</tr>
</tbody></table>
<p>Overlay는 개별 데이터베이스에 적용하거나, 프론트엔드에 적용하여 모든 데이터베이스에 전역으로 적용할 수 있다.</p>
<h3>복제: Syncrepl</h3>
<p>slapd의 복제는 <strong>syncrepl</strong> (LDAP Content Synchronization Protocol, RFC 4533)을 사용한다.</p>
<p><strong>핵심 설계 결정 — Consumer-side 엔진:</strong>
syncrepl 설정은 consumer(소비자) 측에서 정의된다. 이것은 provider 재설정 없이 consumer를 추가할 수 있다는 의미이다. 이전의 slurpd(provider-side 복제)와 근본적으로 다른 접근이다.</p>
<p><strong>동기화 모드:</strong></p>
<ul>
<li><strong>refreshOnly</strong>: consumer가 주기적으로 provider를 폴링 (pull 방식)</li>
<li><strong>refreshAndPersist</strong>: 영구 연결을 유지하고 provider가 실시간 푸시 (push 방식)</li>
</ul>
<p><strong>entryUUID 기반 추적:</strong>
DN이 아닌 entryUUID로 엔트리를 식별한다. DN은 이름 변경 시 바뀔 수 있지만 entryUUID는 불변이다. 이를 통해 DN 변경에도 복제가 정확히 추적된다.</p>
<p><strong>Delta-Syncrepl:</strong>
일반 syncrepl이 변경된 엔트리 전체를 복제하는 반면, delta-syncrepl은 변경된 속성만 복제한다. accesslog overlay가 필요하며, 동기화가 크게 벗어나면 일반 syncrepl로 폴백한다.</p>
<h3>멀티 프로바이더 복제</h3>
<table>
<thead>
<tr>
<th>모드</th>
<th>설명</th>
<th>장단점</th>
</tr>
</thead>
<tbody><tr>
<td><strong>N-Way Multi-Provider</strong></td>
<td>모든 서버가 쓰기를 수락, 서로 복제</td>
<td>일관성 문제, split-brain 위험, 쓰기 부하 분산 안됨</td>
</tr>
<tr>
<td><strong>MirrorMode</strong></td>
<td>2개 provider 양방향 복제 + 외부 프론트엔드가 쓰기를 한 곳에 집중</td>
<td>단일 provider의 일관성 + HA, NTP 동기화 필수</td>
</tr>
</tbody></table>
<p>MirrorMode는 사실상 Active-Standby에 가깝다. 외부 로드밸런서가 모든 쓰기를 하나의 provider에 보내고, 장애 시 다른 provider로 전환한다. 진정한 multi-master가 아닌 점에 주의. [추론]</p>
<h3>ACL (접근 제어)</h3>
<p><code>to &lt;what&gt; by &lt;who&gt; [&lt;accesslevel&gt;] [&lt;control&gt;]</code> 형식으로 세밀한 접근 제어가 가능하다. 접근 레벨은 none → auth → read → write 순서이다. 프론트엔드 데이터베이스의 ACL은 모든 데이터베이스에 자동 추가된다.</p>
<h3>다른 LDAP 서버와의 비교</h3>
<ul>
<li><strong>vs Active Directory</strong>: AD는 Windows 생태계에 깊이 통합되어 있고 GUI가 뛰어나지만, 라이선스 비용이 들고 Windows에 종속된다. OpenLDAP은 크로스 플랫폼이고 무료이지만 관리가 CLI 중심이다.</li>
<li><strong>vs 389 Directory Server</strong>: 389 DS는 Red Hat이 개발하며, 내장형 멀티마스터 복제(최대 4-way, 자동 충돌 해결)가 OpenLDAP보다 강력하다. SUSE에서도 기본 LDAP 서버로 채택. 단, OpenLDAP에서 389 DS로의 마이그레이션은 단방향이다.</li>
</ul>
<h3>현재 상태 (2026년 기준)</h3>
<ul>
<li><strong>최신 LTS</strong>: 2.6.10 (2025-05-22)</li>
<li><strong>최신 기능 릴리스</strong>: 2.6.9 (2024-11-26)</li>
<li>활발히 유지보수 중이며, Feature Release와 LTS 두 트랙으로 관리</li>
<li>LMDB는 독립 프로젝트로도 널리 사용됨 (Monero, Caffe 등)</li>
</ul>
<h2>나의 생각</h2>
<ul>
<li>프론트엔드/백엔드/Overlay 3계층 아키텍처는 관심사 분리(Separation of Concerns) 원칙을 잘 따르고 있다. 특히 Overlay가 데코레이터 패턴처럼 동작하여 기능을 조합할 수 있는 점이 유연하다. [추론]</li>
<li>cn=config의 &quot;설정 자체가 LDAP 데이터&quot; 접근은 meta-circular한 설계로, 설정 관리에 별도 메커니즘이 필요 없다는 점에서 우아하다. 단, 학습 곡선이 높아 신규 사용자에게는 진입 장벽이 된다.</li>
<li>MDB(LMDB)의 &quot;제로 튜닝&quot; 철학은 Ceph의 BlueStore가 &quot;로우 디바이스 직접 접근&quot;으로 파일 시스템 레이어를 제거한 것과 유사한 근본적 접근이다. 중간 레이어를 제거하여 복잡도와 성능 문제를 동시에 해결한다. [추론]</li>
<li>syncrepl의 consumer-side 설계는 provider의 설정 변경 없이 consumer를 자유롭게 추가할 수 있어 운영상 큰 장점이다. 그러나 MirrorMode가 사실상 Active-Standby라는 점에서, 진정한 multi-master가 필요하면 389 DS가 더 적합할 수 있다.</li>
<li>Ceph/GlusterFS 같은 분산 스토리지와 달리, slapd는 &quot;디렉토리 서비스&quot;에 특화되어 있다. 읽기가 쓰기보다 압도적으로 많은 워크로드에 최적화되어 있으며, 이것이 LDAP 프로토콜 자체의 설계 의도이기도 하다.</li>
</ul>
<h2>Links</h2>
<ul>
<li>원본: <span class="wikilink-dead">REF-openldap-slapd-architecture</span></li>
<li>원본: <span class="wikilink-dead">REF-openldap-release-status</span></li>
<li>보조: <span class="wikilink-dead">AUX-ldap-server-comparison-openldap-ad-389ds</span></li>
<li>관련 (LDAP 개요): <a href="/blog/LIT-ldap-overview">LIT-ldap-overview</a></li>
<li>관련: <span class="wikilink-dead">LIT-389-directory-server-overview</span></li>
<li>관련: <span class="wikilink-dead">LIT-kerberos-implementations-overview</span></li>
<li>관련: <span class="wikilink-dead">LIT-ldapi-summary</span></li>
<li>관련: <a href="/blog/LIT-bdb-lmdb-comparison">LIT-bdb-lmdb-comparison</a></li>
<li>관련: <span class="wikilink-dead">LIT-ldap-data-model-summary</span></li>
<li>관련: <span class="wikilink-dead">LIT-contextcsn-replication-state-summary</span></li>
<li>관련 Permanent Note: [[]]</li>
</ul>


LIT-slapd-overview

<h2>원문 내용</h2>
<h3>Berkeley DB(BDB)란</h3>
<p>Berkeley DB는 임베디드(embedded) key-value 데이터베이스 라이브러리이다. 서버/클라이언트 모델이 아니며, 프로세스 내에서 API 호출을 통해 데이터베이스에 접근한다. C로 작성되었으며, C++, Java, Python, Ruby, Go 등 다양한 언어 바인딩을 제공한다.</p>
<h3>역사</h3>
<ul>
<li>UC Berkeley에서 Keith Bostic과 Margo Seltzer가 대학원생 시절 개발</li>
<li>초기: 인메모리와 온디스크 해싱을 통합하는 것으로 시작</li>
<li>Netscape의 후원으로 LDAP 서버 개발을 위한 트랜잭션 처리 기능 추가</li>
<li><strong>Sleepycat Software</strong>로 프로젝트 이전</li>
<li><strong>2006년: Oracle이 Sleepycat Software를 인수</strong></li>
<li>2013년: Oracle이 라이선스를 Sleepycat License에서 <strong>GNU AGPL v3</strong>로 변경</li>
<li>마지막 릴리스: 18.1 (약 2020년 5월)</li>
</ul>
<h3>아키텍처: 5개 서브시스템</h3>
<table>
<thead>
<tr>
<th>서브시스템</th>
<th>역할</th>
</tr>
</thead>
<tbody><tr>
<td><strong>Caching (MPool)</strong></td>
<td>인메모리 버퍼 풀. LRU 페이지 교체 정책 사용</td>
</tr>
<tr>
<td><strong>Datastore</strong></td>
<td>데이터 저장. 키-값 쌍을 DTAG 구조로 관리</td>
</tr>
<tr>
<td><strong>Locking</strong></td>
<td>2단계 잠금(2PL). 다수 읽기 커서 또는 단일 쓰기 접근</td>
</tr>
<tr>
<td><strong>Logging</strong></td>
<td>WAL(Write-Ahead Logging). ARIES 모델 기반 undo/redo</td>
</tr>
<tr>
<td><strong>Recovery</strong></td>
<td>체크포인팅. 장애 후 복구</td>
</tr>
</tbody></table>
<h3>데이터 접근 방법</h3>
<table>
<thead>
<tr>
<th>접근 방법</th>
<th>설명</th>
</tr>
</thead>
<tbody><tr>
<td><strong>B+Tree</strong></td>
<td>키 정렬 저장. 정확한 매칭 및 범위 스캔에 효율적. 가장 일반적</td>
</tr>
<tr>
<td><strong>Hash</strong></td>
<td>선형 해싱. 정확한 매칭 쿼리와 균등 키 분포에 적합</td>
</tr>
<tr>
<td><strong>Queue</strong></td>
<td>고정 크기 값. 순차 데이터</td>
</tr>
<tr>
<td><strong>Recno</strong></td>
<td>B+Tree 기반 순차 저장</td>
</tr>
</tbody></table>
<h3>동시성 제어</h3>
<ul>
<li>기본: <strong>2단계 잠금(Two-Phase Locking, 2PL)</strong> — 직렬화 가능 격리</li>
<li>이후 추가: <strong>MVCC (Multi-Version Concurrency Control)</strong> — 스냅샷 격리, 더 큰 캐시 필요</li>
<li>충돌 매트릭스로 계층적 데드락 방지</li>
</ul>
<h3>트랜잭션 및 ACID</h3>
<ul>
<li>완전한 ACID 준수</li>
<li>WAL(Write-Ahead Logging): 데이터를 <strong>두 번 기록</strong> (로그 + 실제 데이터)</li>
<li>LSN(Log Sequence Number)으로 로그 인덱싱</li>
<li>체크포인팅으로 인메모리 버퍼를 디스크에 플러시</li>
</ul>
<h3>페이지 포맷</h3>
<p>디스크와 메모리의 페이지 포맷이 동일하여 변환 오버헤드가 없다.</p>
<h3>SQL 지원</h3>
<p>Oracle이 11g R2 릴리스에서 SQLite API 기반 SQL 지원을 추가. SQLite를 BDB에 포함시켜 BDB를 스토리지 레이어로 사용.</p>
<h3>라이선스 변경의 영향</h3>
<p>2013년 AGPL로 라이선스 변경은 오픈소스 생태계에 큰 영향을 미쳤다:</p>
<ul>
<li>BDB는 라이브러리이므로 링크하는 모든 애플리케이션이 AGPL 호환 라이선스여야 함</li>
<li>많은 오픈소스 프로젝트와 모든 클로즈드 소스 애플리케이션에 문제 발생</li>
<li>이로 인해 여러 프로젝트가 <strong>BDB에서 LMDB 등 대안으로 마이그레이션</strong></li>
</ul>
<h3>사용 사례 (역사적)</h3>
<ul>
<li><strong>OpenLDAP slapd</strong>: back-bdb, back-hdb 백엔드 (현재는 LMDB의 back-mdb로 대체)</li>
<li><strong>389 Directory Server</strong>: BDB 백엔드 (현재 LMDB로 마이그레이션 중)</li>
<li><strong>MIT Kerberos</strong>: KDC DB2 백엔드</li>
<li><strong>Subversion</strong>: 리포지토리 스토리지</li>
<li><strong>RPM</strong>: 패키지 데이터베이스</li>
</ul>
<h2>메타 정보</h2>
<ul>
<li><strong>출처 유형</strong>: 학술 데이터베이스 백과사전, 공식 문서</li>
<li><strong>추가 출처</strong>:<ul>
<li><a href="https://www.oracle.com/database/technologies/related/berkeleydb.html">https://www.oracle.com/database/technologies/related/berkeleydb.html</a></li>
<li><a href="https://www.oracle.com/database/technologies/related/berkeleydb/berkeleydb-licensing.html">https://www.oracle.com/database/technologies/related/berkeleydb/berkeleydb-licensing.html</a></li>
</ul>
</li>
</ul>
<h2>Links</h2>
<ul>
<li>관련 Reference Note: <span class="wikilink-dead">REF-lmdb-architecture</span></li>
<li>관련 Literature Note: <a href="/blog/LIT-bdb-lmdb-comparison">LIT-bdb-lmdb-comparison</a></li>
</ul>


REF-bdb-architecture

<h2>Google AdSense란?</h2>
<p>웹사이트 퍼블리셔(게시자)가 자신의 사이트에 Google 광고를 게재하여 <strong>수익을 창출</strong>할 수 있게 해주는 광고 플랫폼이다.</p>
<p><strong>3자 구조</strong>:</p>
<ul>
<li><strong>광고주</strong>: Google Ads를 통해 광고 집행, 비용 지불</li>
<li><strong>Google</strong>: 광고주와 퍼블리셔를 연결하는 중개 플랫폼 (광고 경매 운영)</li>
<li><strong>퍼블리셔</strong>: AdSense에 가입, 사이트에 광고 코드 삽입, 수익 배분</li>
</ul>
<p>즉, <strong>Google Ads = 광고주 측 플랫폼</strong>, <strong>AdSense = 퍼블리셔 측 플랫폼</strong>이다.</p>
<h2>동작 방식</h2>
<pre><code>1. 퍼블리셔 가입 + Google 승인 심사
2. AdSense 스크립트를 사이트 &lt;head&gt;에 삽입
3. 사용자 페이지 방문 → AdSense 스크립트가 Google에 광고 요청
4. Google 실시간 경매 (Real-Time Bidding) → 낙찰된 광고 표시
5. 클릭 또는 노출 → 수익 발생
6. 월별 정산 → 퍼블리셔에게 지급
</code></pre><h2>수익 모델</h2>
<h3>과금 방식</h3>
<table>
<thead>
<tr>
<th>모델</th>
<th>설명</th>
</tr>
</thead>
<tbody><tr>
<td><strong>CPC (Cost Per Click)</strong></td>
<td>사용자가 광고 클릭 시 과금. 가장 일반적</td>
</tr>
<tr>
<td><strong>CPM (Cost Per Mille)</strong></td>
<td>광고 1,000회 노출당 과금. 트래픽 많은 사이트에 유리</td>
</tr>
<tr>
<td><strong>Active View CPM</strong></td>
<td>실제 화면에 보인 노출 1,000회당 과금 (뷰포트에 1초 이상 50% 이상)</td>
</tr>
</tbody></table>
<h3>수익 배분 비율</h3>
<p><strong>2024년~ 변경된 구조</strong>:</p>
<ul>
<li>구매 측 플랫폼 (Google Ads 등): 약 15% 수수료</li>
<li>판매 측 (AdSense): 20% 수수료</li>
<li><strong>퍼블리셔</strong>: 약 <strong>80%</strong> 수령 (판매 측 기준)</li>
</ul>
<p>(기존: Content 광고 퍼블리셔 68% / Search 광고 퍼블리셔 51%)</p>
<h3>지급 기준</h3>
<ul>
<li><strong>최소 지급액</strong>: $100</li>
<li><strong>지급 주기</strong>: 매월 21~26일 (전월 수익)</li>
<li><strong>지급 방법</strong>: 은행 계좌 이체 (한국은 외화 송금 → 원화 환전)</li>
</ul>
<h2>광고 유형</h2>
<h3>수동 배치 광고 단위</h3>
<table>
<thead>
<tr>
<th>유형</th>
<th>설명</th>
<th>용도</th>
</tr>
</thead>
<tbody><tr>
<td><strong>Display Ads</strong></td>
<td>반응형 배너 광고</td>
<td>사이드바, 콘텐츠 상하단 (범용)</td>
</tr>
<tr>
<td><strong>In-feed Ads</strong></td>
<td>콘텐츠 피드 사이 네이티브 광고</td>
<td>게시글 목록, 뉴스 피드</td>
</tr>
<tr>
<td><strong>In-article Ads</strong></td>
<td>본문 단락 사이 네이티브 광고</td>
<td>블로그 포스트, 기사</td>
</tr>
<tr>
<td><strong>Multiplex Ads</strong></td>
<td>그리드 형태 다중 광고 (구 Matched Content)</td>
<td>관련 콘텐츠 추천 영역</td>
</tr>
</tbody></table>
<h3>Auto Ads</h3>
<p>Google 머신러닝이 <strong>자동으로 최적 위치에 광고 배치</strong>하는 기능.</p>
<ul>
<li>AdSense 스크립트가 페이지 구조 분석 → ML이 위치 결정</li>
<li>인페이지 광고, 앵커 광고 (상/하단 고정), 전면 광고 (페이지 전환 시), 사이드 레일 광고 (좌우 여백)</li>
<li>AdSense 콘솔에서 사이트별 on/off, 광고 형식별 개별 토글, URL 패턴 제외 가능</li>
<li><strong>장점</strong>: 구현 간단, Google 자동 최적화</li>
<li><strong>단점</strong>: 레이아웃 제어 제한, 의도치 않은 위치에 광고 가능</li>
</ul>
<h2>사이트 적용 시 필수/선택 항목</h2>
<p>AdSense를 사이트에 적용할 때 3가지 요소가 등장하지만, 모두 필수는 아니다.</p>
<table>
<thead>
<tr>
<th>항목</th>
<th>역할</th>
<th>필수 여부</th>
</tr>
</thead>
<tbody><tr>
<td><strong>AdSense code snippet</strong> (<code>&lt;script&gt;</code>)</td>
<td>실제 광고 표시 코드. <code>&lt;head&gt;</code>에 삽입</td>
<td><strong>필수</strong> — 없으면 광고가 표시되지 않음</td>
</tr>
<tr>
<td><strong>ads.txt</strong></td>
<td>광고 인벤토리 판매 권한 선언 (광고 사기 방지)</td>
<td><strong>강력 권장</strong> — 없으면 광고 수익 제한 가능</td>
</tr>
<tr>
<td><strong>Meta tag</strong> (소유권 인증)</td>
<td>사이트 소유권 인증 수단 중 하나</td>
<td><strong>대체 가능</strong> — 여러 인증 방법 중 택 1</td>
</tr>
</tbody></table>
<h3>소유권 인증 방법 (택 1)</h3>
<p>AdSense 승인 시 사이트 소유권을 증명해야 하며, 아래 중 <strong>하나만</strong> 완료하면 된다:</p>
<table>
<thead>
<tr>
<th>방법</th>
<th>설명</th>
</tr>
</thead>
<tbody><tr>
<td><strong>Meta tag</strong></td>
<td><code>&lt;head&gt;</code>에 Google 제공 <code>&lt;meta&gt;</code> 태그 삽입</td>
</tr>
<tr>
<td><strong>HTML 파일 업로드</strong></td>
<td>Google 제공 HTML 파일을 도메인 루트에 배치</td>
</tr>
<tr>
<td><strong>DNS TXT 레코드</strong></td>
<td>도메인 DNS에 TXT 레코드 추가</td>
</tr>
<tr>
<td><strong>Google Analytics 연동</strong></td>
<td>기존 GA4 연동으로 인증</td>
</tr>
<tr>
<td><strong>Google Tag Manager 연동</strong></td>
<td>기존 GTM 연동으로 인증</td>
</tr>
</tbody></table>
<p>이미 GA4나 GTM이 사이트에 설정되어 있다면 meta tag 없이 인증을 완료할 수 있다.</p>
<h2>구현 방법</h2>
<h3>AdSense 스크립트 삽입</h3>
<p><code>&lt;head&gt;</code>에 단일 스크립트 태그 삽입:</p>
<pre><code class="hljs language-html"><span class="hljs-tag">&lt;<span class="hljs-name">script</span> <span class="hljs-attr">async</span>
  <span class="hljs-attr">src</span>=<span class="hljs-string">&quot;https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-XXXXXXXXXXXXXXXX&quot;</span>
  <span class="hljs-attr">crossorigin</span>=<span class="hljs-string">&quot;anonymous&quot;</span>&gt;</span><span class="hljs-tag">&lt;/<span class="hljs-name">script</span>&gt;</span>
</code></pre><ul>
<li><code>ca-pub-XXXXXXXXXXXXXXXX</code>: 퍼블리셔 ID</li>
<li><code>async</code>: 페이지 로딩 차단 안 함</li>
<li>이 스크립트 하나로 Auto Ads 활성화 (콘솔에서 켠 경우)</li>
</ul>
<h3>수동 광고 단위 배치</h3>
<p>특정 위치에 광고를 배치하려면 추가 코드 필요:</p>
<pre><code class="hljs language-html"><span class="hljs-tag">&lt;<span class="hljs-name">ins</span> <span class="hljs-attr">class</span>=<span class="hljs-string">&quot;adsbygoogle&quot;</span>
     <span class="hljs-attr">style</span>=<span class="hljs-string">&quot;display:block&quot;</span>
     <span class="hljs-attr">data-ad-client</span>=<span class="hljs-string">&quot;ca-pub-XXXXXXXXXXXXXXXX&quot;</span>
     <span class="hljs-attr">data-ad-slot</span>=<span class="hljs-string">&quot;1234567890&quot;</span>
     <span class="hljs-attr">data-ad-format</span>=<span class="hljs-string">&quot;auto&quot;</span>
     <span class="hljs-attr">data-full-width-responsive</span>=<span class="hljs-string">&quot;true&quot;</span>&gt;</span><span class="hljs-tag">&lt;/<span class="hljs-name">ins</span>&gt;</span>
<span class="hljs-tag">&lt;<span class="hljs-name">script</span>&gt;</span><span class="language-javascript">(adsbygoogle = <span class="hljs-variable language_">window</span>.<span class="hljs-property">adsbygoogle</span> || []).<span class="hljs-title function_">push</span>({});</span><span class="hljs-tag">&lt;/<span class="hljs-name">script</span>&gt;</span>
</code></pre><h3>ads.txt</h3>
<p>사이트 루트에 배치하는 텍스트 파일. 광고 인벤토리 판매 권한이 있는 업체를 선언한다.</p>
<pre><code># https://example.com/ads.txt
google.com, pub-XXXXXXXXXXXXXXXX, DIRECT, f08c47fec0942fa0
</code></pre><ul>
<li><strong>위치</strong>: 도메인 루트 (<code>https://example.com/ads.txt</code>)</li>
<li>Google이 강력히 권장. 없으면 수익에 영향 가능.</li>
</ul>
<h2>AdSense vs GTM: 왜 직접 삽입하는가?</h2>
<p>Google 공식 권장: AdSense는 GTM이 아닌 <strong>직접 HTML에 삽입</strong>.</p>
<table>
<thead>
<tr>
<th>항목</th>
<th>직접 삽입</th>
<th>GTM 경유</th>
</tr>
</thead>
<tbody><tr>
<td>로딩 타이밍</td>
<td>페이지 파싱과 동시</td>
<td>GTM 로드 후 실행 (지연)</td>
</tr>
<tr>
<td>광고 수익</td>
<td>최적</td>
<td>노출 기회 감소 가능</td>
</tr>
<tr>
<td>정책 준수</td>
<td>Google 공식 권장</td>
<td>비공식, 정책 위반 가능성</td>
</tr>
<tr>
<td>Auto Ads</td>
<td>완벽 지원</td>
<td>최적화 저하 가능</td>
</tr>
</tbody></table>
<p><strong>기술적 이유</strong>: AdSense는 DOM 구조를 초기에 분석해야 최적 배치를 결정할 수 있고, GTM을 거치면 추가 네트워크 왕복으로 First Ad Request가 지연됨. Google 광고 크롤러(Mediabot)가 GTM 동적 삽입을 감지하지 못할 수 있음.</p>
<p><strong>결론</strong>: GA4는 GTM을 통해, AdSense는 직접 삽입이 표준 패턴.</p>
<h2>AdSense vs Google Ad Manager (GAM)</h2>
<table>
<thead>
<tr>
<th>항목</th>
<th>AdSense</th>
<th>GAM</th>
</tr>
</thead>
<tbody><tr>
<td>대상</td>
<td>소~중규모 퍼블리셔</td>
<td>중대규모, 미디어 기업</td>
</tr>
<tr>
<td>광고 소스</td>
<td>Google 네트워크만</td>
<td>Google + 다른 네트워크 (header bidding)</td>
</tr>
<tr>
<td>직접 판매</td>
<td>불가</td>
<td>가능</td>
</tr>
<tr>
<td>설정 복잡도</td>
<td>낮음</td>
<td>높음</td>
</tr>
<tr>
<td>비용</td>
<td>무료 (수익 배분)</td>
<td>소규모 무료 / 대규모 유료</td>
</tr>
</tbody></table>
<p>GAM에서도 AdSense를 광고 소스 중 하나로 연동 가능 (backfill).</p>
<h2>주요 정책</h2>
<h3>무효 클릭 활동 (가장 엄격)</h3>
<ul>
<li>자기 클릭 금지, 클릭 유도 금지, 자동 클릭/봇 금지</li>
<li>위반 시 <strong>계정 영구 정지</strong> (복구 매우 어려움)</li>
</ul>
<h3>콘텐츠/배치 정책</h3>
<ul>
<li>불법/성인/허위 콘텐츠 금지</li>
<li>과도한 광고 배치 금지, 광고와 콘텐츠 명확 구분</li>
<li>팝업/팝언더 광고 배치 금지</li>
</ul>
<h2>AdSense ID 형식</h2>
<pre><code>ca-pub-XXXXXXXXXXXXXXXX
</code></pre><p>접두사 <code>ca-pub-</code> + 16자리 숫자. 계정당 하나. Google 정책상 한 사람/법인당 하나의 AdSense 계정만 허용.</p>
<h2>승인 프로세스</h2>
<ol>
<li>AdSense 가입 신청 + 사이트 URL 제출</li>
<li>확인용 스크립트를 <code>&lt;head&gt;</code>에 삽입</li>
<li>Google이 사이트 소유권 확인 + 콘텐츠 심사 (수일~수주)</li>
<li>승인 또는 거부 (거부 시 사유 + 재신청 가능)</li>
</ol>
<p><strong>주요 승인 요건</strong>: 충분한 오리지널 콘텐츠 (15~30개+), 명확한 내비게이션, 개인정보처리방침, 자체 도메인, 정책 준수</p>
<h2>GA4와의 연동</h2>
<p>AdSense를 GA4와 연동하면 광고 수익 데이터를 GA4 보고서에서 확인 가능.</p>
<ul>
<li><strong>연동 경로</strong>: GA4 Admin &gt; Product Links &gt; AdSense Links</li>
<li><strong>확인 가능 데이터</strong>: 페이지별 수익, 클릭수, 노출수, RPM, 트래픽 소스별 수익</li>
<li><strong>지연</strong>: 최대 24~48시간</li>
<li><strong>주의</strong>: GA4 수치는 추정치. 최종 정산은 AdSense 콘솔 기준</li>
</ul>
<h2>Links</h2>
<ul>
<li>원본: <span class="wikilink-dead">REF-google-adsense-how-it-works</span></li>
<li>관련 노트: <span class="wikilink-dead">REF-infra-gtm-adsense-setup</span></li>
<li>관련 노트: <span class="wikilink-dead">LIT-google-tag-manager-overview</span></li>
<li>관련 노트: <span class="wikilink-dead">LIT-google-analytics-4-overview</span></li>
</ul>


LIT-google-adsense-overview

gonnux의 개인 블로그 - 앱, 프로젝트, 기술 블로그

gonnux.com

Blog