전 세계 수백 개 DSP가 동시에 입찰가를 던지고, 낙찰자가 결정되며, 그 광고의 XML이 플레이어로 흘러들어와 파싱되고, 미디어가 다운로드되고, 수십 개의 트래킹 픽셀이 발사됩니다. 이 모든 과정의 뒤에는 IAB Tech Lab이 설계한 두 가지 핵심 표준이 있습니다 — VAST와 OpenRTB.

이 글은 두 표준의 구조를 단순한 개요가 아니라 공식 명세 수준의 깊이로 뜯어보는 기술 레퍼런스입니다. 모든 enum 값과 필드는 다음 1차 소스로 교차 검증했습니다.

• gwangy.com/docs/vast — VAST v3.0~v4.2 통합 명세
• IAB Tech Lab — VAST Standards
• IAB Tech Lab — OpenRTB 2.6 Spec
• IAB Tech Lab — AdCOM v1.0 FINAL

Fact-check 노트: OpenRTB 2.6의 enum(protocol/placement/playbackmethod 등)은 모두 AdCOM 1.0 사양으로 분리되어 관리됩니다. 이 글의 모든 enum 표는 AdCOM 1.0 FINAL에서 직접 추출한 값입니다.

1. 두 표준의 역할 한눈에

한 문장 요약: OpenRTB는 “어떤 광고를 살까”를 결정하는 시장이고, VAST는 “낙찰된 광고를 어떻게 재생하고 추적할까”를 알려주는 명세서입니다. AdCOM은 둘이 함께 쓰는 공용 사전이고, OMID는 결과를 측정하는 도구입니다.

2. VAST 상세 — 광고 소재 전달 명세

2.1 버전 진화

사실 확인: IAB Tech Lab의 공식 VAST Standards 페이지에 명시된 출시일 기준. 일부 자료는 VAST 4.0을 2016-04 또는 2016-10으로 표기하나, IAB Tech Lab 공식 페이지의 표기를 따랐습니다.

2.2 XML 최상위 구조

<VAST version="4.2" xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <Ad id="12345" sequence="1" adType="video" conditionalAd="false">
    <InLine>
      <AdSystem version="1.0">My Ad Server</AdSystem>
      <AdServingId>a532d16d-4d7f-4440-bd29-2ec0e693fc80</AdServingId>
      <AdTitle>My Campaign 2026 Q2</AdTitle>
      <Impression id="imp1"><![CDATA[https://tracker.example.com/imp]]></Impression>
      <Pricing model="CPM" currency="USD">3.50</Pricing>
      <Creatives>
        ...
      </Creatives>
    </InLine>
  </Ad>
</VAST>

<Ad> 는 두 가지 형태만 가질 수 있습니다.

Wrapper 체인 권고 한계: 일반적으로 3~5 hop. 깊어질수록 레이턴시·실패율이 누적되며, VAST 4.x에서는 Wrapper@followAdditionalWrappers="false"로 명시적으로 차단할 수 있습니다.

2.3 <Ad> 속성 전체 (v3.0 ~ v4.2)

2.4 Metadata 요소 전체

2.5 Linear 광고 — MediaFile 전체 속성

<Linear>
  <Duration>00:00:30</Duration>
  <SkipOffset>00:00:05</SkipOffset>
  <MediaFiles>
    <MediaFile delivery="progressive" type="video/mp4"
               width="1920" height="1080" bitrate="2000"
               minBitrate="1500" maxBitrate="3000"
               scalable="true" maintainAspectRatio="true"
               codec="avc1.4D401E" fileSize="7500000">
      <![CDATA[https://cdn.example.com/ad.mp4]]>
    </MediaFile>
    <Mezzanine type="video/mp4" delivery="progressive"
               width="3840" height="2160" codec="hevc">
      <![CDATA[https://cdn.example.com/ad-mezzanine.mp4]]>
    </Mezzanine>
    <InteractiveCreativeFile type="text/html"
                              apiFramework="SIMID"
                              variableDuration="false">
      <![CDATA[https://creative.example.com/simid.html]]>
    </InteractiveCreativeFile>
    <ClosedCaptionFiles>
      <ClosedCaptionFile type="text/vtt" language="ko">
        <![CDATA[https://cdn.example.com/captions-ko.vtt]]>
      </ClosedCaptionFile>
    </ClosedCaptionFiles>
  </MediaFiles>
</Linear>

<MediaFile> 속성 표:

Mezzanine (v4.0): SSAI(서버 사이드 광고 삽입) 환경에서 트랜스코딩 전 원본 고화질 소재. v4.1에서는 코덱·해상도 권장 사양이 추가되었습니다.

2.6 SkipOffset 형식

2.7 TrackingEvents — 전체 enum

2.8 ViewableImpression — MRC 기준

<ViewableImpression id="vi1">
  <Viewable><![CDATA[https://t.example.com/viewable]]></Viewable>
  <NotViewable><![CDATA[https://t.example.com/not-viewable]]></NotViewable>
  <ViewUndetermined><![CDATA[https://t.example.com/undetermined]]></ViewUndetermined>
</ViewableImpression>

MRC(Media Rating Council) Viewability 기준 — 비디오:

2.9 AdVerifications & OMID (v4.0+)

제3자 측정사가 OMID(Open Measurement Interface Definition) SDK를 통해 독립 검증을 수행합니다.

<AdVerifications>
  <Verification vendor="doubleverify.com-omid">
    <JavaScriptResource apiFramework="omid" browserOptional="true">
      <![CDATA[https://cdn.doubleverify.com/dvtp_src.js]]>
    </JavaScriptResource>
    <ExecutableResource apiFramework="omid" type="application/x-javascript">
      <![CDATA[https://cdn.doubleverify.com/native.so]]>
    </ExecutableResource>
    <TrackingEvents>
      <Tracking event="verificationNotExecuted">
        <![CDATA[https://t.doubleverify.com/no-exec]]>
      </Tracking>
    </TrackingEvents>
    <VerificationParameters><![CDATA[ctx=1234&cmp=5678]]></VerificationParameters>
  </Verification>
</AdVerifications>

2.10 SIMID vs VPAID — 인터랙티브 광고 변천사

<!-- SIMID 선언 -->
<InteractiveCreativeFile type="text/html"
                          apiFramework="SIMID"
                          variableDuration="false">
  <![CDATA[https://creative.example.com/simid.html]]>
</InteractiveCreativeFile>

2.11 Icons — AdChoices / DSA

<Icons>
  <Icon program="AdChoices" width="80" height="15"
        xPosition="right" yPosition="top"
        offset="00:00:00" duration="00:01:00" pxratio="2">
    <StaticResource creativeType="image/png">
      <![CDATA[https://example.com/adchoices@2x.png]]>
    </StaticResource>
    <IconViewTracking><![CDATA[https://t.example.com/icon-view]]></IconViewTracking>
    <IconClicks>
      <IconClickThrough><![CDATA[https://adchoices.example.com]]></IconClickThrough>
      <IconClickTracking><![CDATA[https://t.example.com/icon-click]]></IconClickTracking>
      <IconClickFallbackImages>
        <IconClickFallbackImage width="400" height="150">
          <AltText>AdChoices Info</AltText>
          <StaticResource creativeType="image/png">
            <![CDATA[https://example.com/fallback.png]]>
          </StaticResource>
        </IconClickFallbackImage>
      </IconClickFallbackImages>
    </IconClicks>
  </Icon>
</Icons>

2.12 VAST Macros — 28종 전체 (v4.2 기준)

VAST 매크로는 [BRACKET] 형식이며, 플레이어가 트래킹 URL을 호출하기 직전에 치환합니다. OpenRTB의 ${DOLLAR} 매크로와 다른 시스템입니다.

시간/카운트 매크로:

식별 매크로:

디바이스/사용자 매크로:

프라이버시 매크로:

이벤트/상태 매크로:

참고: 매크로의 정식 카탈로그는 별도 라이브 문서로 관리됩니다 → vast4-macros-latest. 신규 매크로는 IAB Tech Lab의 Working Group 승인 후 추가됩니다.

2.13 Error Codes — 전체 분류

<Error> URL 사용법:

<Error><![CDATA[https://errors.example.com/vast?code=[ERRORCODE]&aid=[ADSERVINGID]]]></Error>

3. OpenRTB 상세 — 실시간 입찰 표준

3.1 버전 진화

사실 확인: 3.0이 2017년에 먼저 나왔지만, 산업 표준은 여전히 2.x 계열입니다 (특히 2.5와 2.6). 3.0은 호환성·전환 비용 문제로 광범위하게 채택되지 못했습니다.

3.2 RTB 흐름 시퀀스

[1] 사용자가 영상 콘텐츠 재생
[2] Publisher 페이지/앱 → Ad Server (SSP)
[3] SSP가 BidRequest 생성
       │
       ├──→ DSP #1
       ├──→ DSP #2     (병렬 송신, tmax 내 응답 대기)
       ├──→ DSP #3
       └──→ DSP #N
              │
              ↓ BidResponse (price, adm=VAST URL or XML)
       │
[4] SSP: Second-Price Plus Auction → 낙찰자 결정
[5] SSP → 플레이어: 낙찰된 VAST URL/XML 전달
[6] 플레이어 → VAST 파싱 → MediaFile 다운로드 → 재생
[7] 플레이어 → DSP: nurl/burl 호출 (Win/Billing notice)
[8] 플레이어 → 트래킹: Impression, TrackingEvents 발화

전체 경매 시한: BidRequest.tmax (보통 80~120ms). 이 시간 내에 응답 못 한 DSP는 자동 탈락.

3.3 BidRequest 최상위 객체 — 핵심 필드

site vs app vs dooh: 셋 중 하나만 사용 (mutually exclusive).

3.4 Imp Object — 핵심 필드

3.5 Video Object — 핵심 필드 (OpenRTB 2.6)

3.6 AdCOM Enum — Creative Subtypes (= video.protocols)

⚠️ 주의: 일부 자료가 15를 VAST 4.2로 잘못 표기하는 경우가 있습니다. AdCOM 1.0 FINAL 기준 15 = VAST 4.3입니다.

3.7 AdCOM Enum — Plcmt Subtypes (= video.plcmt)

2023년 3월 업데이트로 기존 placement 필드가 Deprecated되고 plcmt로 대체되었습니다.

3.8 AdCOM Enum — API Frameworks (= video.api)

3.9 AdCOM Enum — Start Delay Modes (= video.startdelay)

3.10 AdCOM Enum — Playback Methods (= video.playbackmethod)

3.11 AdCOM Enum — Playback Cessation Modes (= video.playbackend)

3.12 AdCOM Enum — Slot Position in Pod (= video.slotinpod)

3.13 BidRequest 실전 예시 (Video, OpenRTB 2.6 공식 예시 인용)

{
  "id": "1234567893",
  "at": 2,
  "tmax": 120,
  "imp": [{
    "id": "1",
    "bidfloor": 0.03,
    "video": {
      "w": 640,
      "h": 480,
      "pos": 1,
      "startdelay": 0,
      "minduration": 5,
      "maxduration": 30,
      "maxextended": 30,
      "minbitrate": 300,
      "maxbitrate": 1500,
      "apis": [1, 2],
      "protocols": [2, 3],
      "mimes": ["video/x-flv", "video/mp4", "application/javascript"],
      "linearity": 1,
      "boxingallowed": 1,
      "playbackmethod": [1, 3],
      "delivery": [2],
      "battr": [13, 14],
      "companionad": [
        {
          "id": "1234567893-1",
          "w": 300, "h": 250, "pos": 1,
          "battr": [13, 14],
          "expdir": [2, 4]
        }
      ],
      "companiontype": [1, 2]
    }
  }],
  "site": {
    "id": "1345135123",
    "name": "Site ABCD",
    "domain": "siteabcd.com",
    "page": "http://siteabcd.com/page.htm",
    "publisher": {"id": "pub12345", "name": "Publisher A"}
  }
}

(출처: OpenRTB 2.6 Spec §6.2.4 Example 4 – Video)

3.14 Bid Object — BidResponse 핵심 필드

3.15 BidResponse — Markup 전달 방식 비교

Forfeit: 낙찰됐지만 markup 전달 실패로 광고가 안 나가는 경우. 이때도 노출 카운트는 0.

3.16 OpenRTB Substitution Macros — ${DOLLAR} 형식

VAST 매크로([BRACKET])와 다른 시스템입니다. 이건 거래소가 win/billing notice URL과 adm markup에 치환하는 매크로입니다.

암호화 치환: ${AUCTION_PRICE:B64} 형식으로 Base64 등 거래소-bidder 간 합의된 알고리즘 적용 가능.

4. 두 표준의 연동 — Field 매핑 표

DSP가 BidRequest의 어떤 필드를 보고 VAST의 어떤 요소를 만들어야 하는지의 매핑입니다.

5. 자주 헷갈리는 개념 정리

5.1 Impression vs ViewableImpression vs Billable Impression

핵심: 셋은 같은 광고의 서로 다른 단계 카운트. 광고주 계약서에 어떤 기준이 청구 대상인지 명시해야 합니다.

5.2 Auction Types — First Price vs Second Price Plus

사실 확인 정정: OpenRTB 명세는 “Second Price Plus”라고만 명시할 뿐, +$0.01은 표준이 아닙니다. 거래소 정책마다 다르며, 일부는 Bid Floor + 증분, 일부는 2위 + 증분을 사용합니다.

산업 동향: Google Ad Manager(2019), Open Bidding 등 주요 SSP가 First Price로 전환. 2026년 현재 First Price가 비디오 시장 다수.

5.3 VAST [BRACKET] vs OpenRTB ${DOLLAR}

섞임 주의: adm 필드에 VAST URL을 넣을 때 OpenRTB ${AUCTION_PRICE}와 VAST [CACHEBUSTING]이 함께 들어갈 수 있습니다. 각각 다른 단계에서 치환됩니다.

5.4 SSAI vs CSAI

6. CTV 환경 특이사항

6.1 Ad Pod — 연속 광고 묶음

전통 TV 광고처럼 한 브레이크에 여러 광고가 연달아 나가는 구조. OpenRTB 2.6에서 본격 표준화.

Static Pod (사전 정의된 슬롯 수):

{
  "imp": [
    {"id": "1", "video": {"podid": "pod-A", "slotinpod": 1, ...}},
    {"id": "2", "video": {"podid": "pod-A", "slotinpod": 0, ...}},
    {"id": "3", "video": {"podid": "pod-A", "slotinpod": -1, ...}}
  ]
}

Dynamic Pod (총 시간만 정해두고 DSP가 자유롭게):

{
  "imp": [{
    "id": "1",
    "video": {
      "podid": "pod-B",
      "poddur": 90,
      "maxseq": 5,
      "minduration": 15,
      "maxduration": 30,
      "mincpmpersec": 0.10
    }
  }]
}

VAST 쪽 대응:

<Ad sequence="1" breakId="pod-A" breakIndex="1">...</Ad>
<Ad sequence="2" breakId="pod-A" breakIndex="2">...</Ad>

6.2 CTV 환경 식별

7. 프라이버시 프레임워크

GPP는 GDPR/CCPA/기타 지역 규제 문자열을 통합한 차세대 포맷으로, 2022년 IAB Tech Lab 출시. 향후 표준이 GPP로 수렴할 것으로 예상.

8. 구현 체크리스트

8.1 VAST 응답 생성 측 (Ad Server / DSP)

☐ <VAST version="..."> — 협상된 버전 사용
☐ <AdServingId> 포함 (v4.0+ 필수, UUID 권장)
☐ <UniversalAdId> 포함 (중복 광고 탐지)
☐ <AdTitle> 포함 (InLine 필수)
☐ <Impression> 최소 1개, [CACHEBUSTING] 매크로 포함
☐ <Error> URL + [ERRORCODE] 매크로
☐ <MediaFile> type/width/height/delivery 모두 명시
☐ 다양한 bitrate 옵션 제공 (ABR)
☐ TrackingEvents: start, 4분위, complete 최소 포함
☐ ViewableImpression 3종 (Viewable/NotViewable/ViewUndetermined)
☐ AdVerifications (OMID) 포함
☐ Companion 광고 1개 이상 권장 (CTV)
☐ Wrapper 사용 시 followAdditionalWrappers, fallbackOnNoAd 명시

8.2 VAST 소비 측 (Video Player / SDK)

☐ Wrapper 체인 hop 제한 (3~5)
☐ tmax / 자체 타임아웃 내 응답 없으면 Error 301 발화
☐ 모든 트래킹 URL에서 매크로 치환 ([CACHEBUSTING] 필수)
☐ <Error> URL 호출 시 [ERRORCODE] 치환
☐ OMID SDK 초기화 (AdVerifications)
☐ ViewableImpression 판정 로직 (MRC 기준)
☐ SkipOffset 후 스킵 버튼 노출
☐ MediaFile 선택: bitrate × 네트워크 × 화면 크기 고려
☐ [PODSEQUENCE]/[PODCOUNT] 등 Pod 매크로 지원 (v4.1+)

8.3 OpenRTB BidRequest 송신 측 (SSP / Exchange)

☐ id 고유성 보장
☐ tmax 합리적 설정 (80~120ms 권장)
☐ video.protocols / mimes / api 정확히 명시
☐ video.plcmt 사용 (placement Deprecated)
☐ device.ifa, device.ua 포함 (프라이버시 허용 시)
☐ regs.gdpr / us_privacy / gpp 적용
☐ source.schain (Supply Chain) 포함 (Ads.txt/Sellers.json 검증용)
☐ bcat / badv / bapp 차단 리스트 적용
☐ site/app/dooh 중 정확히 하나

8.4 OpenRTB BidResponse 응답 측 (DSP)

☐ id, impid, price 필수
☐ adm 또는 nurl 중 하나로 markup 전달
☐ adomain 정확히 (block list 검증용)
☐ crid 일관성 (이전 노출과 동일 ID)
☐ mtype 명시 (2=Video)
☐ apis / protocol 명시
☐ 응답 시간 tmax 내 보장
☐ nurl/burl/lurl URL에 ${AUCTION_PRICE} 등 매크로 포함

9. 자주 발생하는 실전 문제 & 원인

10. 글로서리 (Glossary)

11. 마무리

VAST와 OpenRTB는 표면적으로는 각각 XML/JSON, 단독으로 존재하는 표준처럼 보이지만, 실제 광고 생태계에서는 하나의 흐름으로 동작합니다. OpenRTB가 0.1초 만에 경매를 끝내면, VAST가 그 결과를 받아 0.5~1초 안에 플레이어로 전달하고, 사용자가 광고를 보는 30초 동안 수십 개의 트래킹 픽셀이 두 표준의 매크로 시스템으로 치환되어 발사됩니다.

두 표준 모두 IAB Tech Lab에서 계속 진화 중입니다. 큰 흐름은:

• VAST: CTV/오디오 지원 강화 (4.3, CTV 2024)
• OpenRTB: Pod·CTV·Privacy 강화 (2.6-202303, GPP 통합)
• AdCOM: 두 표준의 공통 사전으로 분리되어 별도 진화

업계 표준을 따라가되, 구현 시 버전 호환성·매크로 치환·enum 정확성 세 가지에 가장 주의하세요. 경험상 트래킹 데이터 이상의 절반은 매크로 미치환, 사반은 enum 오인(특히 protocols 값), 나머지는 시간 초과(tmax)입니다.

1차 소스 (Fact-Check 기준)

• VAST 통합 명세 — gwangy.com/docs/vast
• IAB Tech Lab — VAST Standards
• OpenRTB 2.6 Spec (GitHub)
• AdCOM 1.0 FINAL (GitHub)
• VAST 4.x Macros Latest (Live Doc)
• IAB OMID SDK
• IAB GPP Specification
• IAB US Privacy String

이 글은 처음에 “Compose와 WebView는 근본적으로 안 맞는다”고 결론 내렸다가, 코드 이력을 다시 분석한 끝에 진짜 원인은 따로 있었다는 것을 깨달은 과정을 정직하게 기록한 것입니다. 40개의 커밋을 쏟아붓고도 못 찾았던, 그러나 단 한 줄이면 끝났던 그 원인 말입니다.

1. 문제의 발단: 멀쩡한 웹페이지가 Compose 안에서 무너지다

특정 고사양 웹 게임 페이지와 보상형 이벤트 페이지에서 치명적인 이슈가 보고되었습니다.

• 현상 1: 페이지 레이아웃이 통째로 무너지거나, height: 100vh 기반 요소들이 전부 0px로 찌그러짐.
• 현상 2: 특정 버튼이 수차례 클릭해야 겨우 한 번 반응하거나, 아예 클릭되지 않음.
• 현상 3: 이미지 리소스가 간헐적으로 깨지거나 로딩이 무한 루프에 빠짐.

일반적인 정적 HTML 페이지에서는 잘 드러나지 않지만, vh/vw 단위를 적극적으로 쓰는 SPA나 고도의 자바스크립트 인터랙션이 포함된 웹 게임에서 문제가 극대화됐습니다.

2. 반전: 진짜 원인은 ‘Compose’가 아니라 ‘layoutParams’였다

처음에는 Compose의 렌더링 파이프라인, 터치 이벤트 선점, 재구성(Recomposition) 등 거창한 구조적 문제를 의심했습니다. 모두 사실이긴 하지만, 가장 직접적인 원인은 어이없을 만큼 단순했습니다.

문제의 코드

AndroidView(
    factory = { ctx ->
        GwangyWebView(ctx)            // ← layoutParams 미설정 → 초기 크기 0×0
    },
    update = { wv ->
        wv.loadUrl(url)               // ← 크기가 0인 상태에서 즉시 호출됨
    },
    modifier = Modifier.fillMaxSize() // ← Compose 좌표계에만 적용, 내부 View엔 전달 안 됨
)

오동작 메커니즘

1. factory() 실행 → WebView 생성, layoutParams 없음 (초기 크기 = 0×0)
2. update() 실행 → loadUrl() 호출
3. 브라우저 엔진이 뷰포트를 등록: viewport height = 0px
4. CSS: height: 100vh → 100 × 0px = 0px 렌더링
5. 이후 뷰 크기가 커져도, 이미 vh=0으로 계산된 레이아웃은 그대로 굳어버림
   → vh 기반 요소 전부 0px로 붕괴

핵심: Modifier.fillMaxSize() ≠ layoutParams

이 버그의 본질은 두 개의 측정 시스템이 서로 독립적이라는 사실을 놓친 것입니다.

Compose 측정 시스템 (Modifier.fillMaxSize)
        │
        ▼
  AndroidView Wrapper (Compose 노드)
        │
        ▼
  View.layoutParams ← factory에서 별도로 설정해야 함 (자동 변환 안 됨!)
        │
        ▼
   실제 View (WebView)

Modifier.fillMaxSize()는 Compose 레이어의 측정 공간을 지정할 뿐, AndroidView가 내부 View를 만들 때 이 값을 LayoutParams로 변환해 전달해주지 않습니다. factory에서 명시하지 않으면 내부 View의 layoutParams는 WRAP_CONTENT(또는 0×0)로 남습니다.

한 줄이면 끝났다 — Compose에서도

AndroidView(
    factory = { ctx ->
        GwangyWebView(ctx).also { wv ->
            // 이 한 줄만 추가했어도 vh 문제는 해결됐다
            wv.layoutParams = ViewGroup.LayoutParams(
                ViewGroup.LayoutParams.MATCH_PARENT,
                ViewGroup.LayoutParams.MATCH_PARENT
            )
        }
    },
    ...
)

즉, “Compose를 버려야만 풀리는 문제”가 아니었습니다. factory 블록 안에서 layoutParams = MATCH_PARENT 한 줄만 추가했어도 vh 문제는 그대로 해결됐을 겁니다.

3. 40개 커밋의 삽질 기록

이 버그를 해결하는 데 약 40개의 커밋이 들었습니다. 그리고 솔직히 고백하면, 그 커밋들은 대부분 AI 코딩 어시스턴트가 작성했습니다. 정작 가장 단순한 해결책인 layoutParams = MATCH_PARENT 한 줄은 그 긴 여정 내내 단 한 번도 시도되지 않았습니다.

대신 시도된 것들은 이런 것들이었습니다.

왜 40개 커밋 동안 MATCH_PARENT를 시도하지 않았는가

원인은 하나입니다. Modifier.fillMaxSize()가 내부 View에도 자동 적용된다고 끝까지 잘못 믿었기 때문입니다.

// 이 코드를 보고 "WebView 크기는 fillMaxSize()로 이미 잡혔다"고 단정해버렸다
AndroidView(
    factory = { ctx -> GwangyWebView(ctx) },  // layoutParams 없음
    modifier = Modifier.fillMaxSize()          // Compose 레이어에만 적용됨
)

이 하나의 착각 위에서 렌더링 레이어, User-Agent, JS 폴리필, GPU/소프트웨어 렌더링 전환, DOM 진단 스크립트까지 — 전혀 다른 방향만 40번을 파고들었습니다. 잘못된 전제 하나가 얼마나 멀리까지 사람(과 AI)을 끌고 가는지 보여주는 사례입니다.

4. 그렇다면 Pure View 전환은 틀린 선택이었나?

아닙니다. 결과적으로 옳았습니다. 다만 이유를 정확히 알아야 합니다.

Pure View로 전환할 때 사실상 두 가지 변경이 동시에 일어났습니다.

vh 문제만 보면 layoutParams = MATCH_PARENT 한 줄로 Compose에서도 해결 가능했습니다. 하지만 두 변경이 한꺼번에 이뤄졌기에 그동안 “Compose를 버리니 해결됐다”고 결론지었던 것이죠. 정확한 진단은 vh + layoutParams, 그리고 Pure View 전환은 vh와 터치 문제를 모두 없앤 올바른 방향입니다.

A. GwangyWebActivity.kt: 독무대를 마련해주다

setContentView 시점에 이미 뷰 크기가 MATCH_PARENT로 확정되므로, loadUrl() 호출 시 브라우저 엔진이 올바른 viewport height를 등록합니다.

// rootLayout: MATCH_PARENT 명시 → WebView가 렌더링되기 전 뷰포트 크기 확정
val rootLayout = LinearLayout(this).apply {
    orientation = LinearLayout.VERTICAL
    layoutParams = ViewGroup.LayoutParams(MATCH_PARENT, MATCH_PARENT)  // ✅
}

// 네이티브 상단 툴바 (Compose 상단바 대신 시스템 안정성 확보)
val toolbar = Toolbar(this).apply {
    title = "GwangyBrowser"
    setNavigationIcon(R.drawable.ic_back)
}

// webView: MATCH_PARENT + weight=1 → 툴바를 제외한 나머지 공간 전체 점유
webView = GwangyWebView(this).apply {
    layoutParams = LinearLayout.LayoutParams(MATCH_PARENT, MATCH_PARENT, 1f)  // ✅
}

rootLayout.addView(toolbar)
rootLayout.addView(webView)

setContentView(rootLayout)
webView?.loadUrl(url)  // 뷰 크기 확정 후 로딩 시작 → vh CSS 정상 동작

B. GwangyWebView.kt: 브라우저 수준의 최적화 설정

단순 래핑을 넘어, WebView가 브라우저만큼의 성능을 내도록 세밀하게 튜닝했습니다.

• 세션 유지의 핵심: CookieManager.setAcceptThirdPartyCookies(true)로 서드파티 도메인 간 세션 공유를 허용했습니다. (보상 시스템에서 필수적)
• 브라우저급 뷰포트: useWideViewPort, loadWithOverviewMode, allowFileAccess 등을 조정했습니다.
• User-Agent Customizing: 일부 서버가 WebView를 봇으로 오인해 차단하는 것을 막기 위해 최신 모바일 크롬 문자열을 주입했습니다.
• 디버깅 활성화: setWebContentsDebuggingEnabled(true)로 PC 크롬 인스펙터를 1:1로 붙일 수 있게 했습니다.

5. AndroidView 인터롭, 제대로 쓰기

이번 일을 계기로 AndroidView 인터롭의 함정을 정리했습니다. WebView뿐 아니라 모든 View 래핑에 공통으로 적용됩니다.

factory vs update — 생명주기를 이해하라

처음 Composition 진입 시:  factory() → View 생성 및 1회 초기화
Recomposition(상태 변화):  update()  → 기존 View 재사용, 상태만 동기화
Composition에서 제거 시:    onRelease() → 리소스 해제

// ❌ 잘못된 예 — 변하는 값을 factory에서 캡처
AndroidView(
    factory = { ctx ->
        WebView(ctx).also { it.loadUrl(url) }  // url이 바뀌어도 factory는 재실행 안 됨!
    }
)

// ✅ 올바른 예 — 고정 설정은 factory, 변하는 값은 update
AndroidView(
    factory = { ctx ->
        WebView(ctx).apply {
            layoutParams = ViewGroup.LayoutParams(MATCH_PARENT, MATCH_PARENT)
        }
    },
    update = { wv -> if (wv.url != url) wv.loadUrl(url) }
)

인터롭에서 자주 터지는 버그 6가지

// ③ View 인스턴스를 Composition 밖으로 꺼내기
val webView = remember {
    WebView(context).apply {
        layoutParams = ViewGroup.LayoutParams(MATCH_PARENT, MATCH_PARENT)
    }
}
// ④ 생명주기 명시 연결
DisposableEffect(Unit) {
    webView.onResume()
    onDispose { webView.onPause() }
}
AndroidView(factory = { webView })

6. 렌더링 파이프라인 충돌 — 언제 Pure View가 ‘필수’인가

Compose와 View는 전혀 다른 렌더링 파이프라인을 가집니다.

Compose:  Composition → Layout → Draw → 단일 RenderNode 트리로 GPU에 한번에
View:     measure → layout → draw → 각 View가 Canvas에 직접, 일부는 독립 Surface 보유

AndroidView로 둘을 섞으면 충돌이 생기는 케이스가 있습니다. WebView의 vh 버그는 그중 타이밍 문제에 속하고, 더 심각한 것은 독립 Surface를 가진 View입니다.

의사결정 흐름도

사용하려는 View가 있다
        │
        ▼
SurfaceView 기반인가? (VideoView, GLSurfaceView, 카메라 HAL)
   예 ──┴── 아니오
   │              │
   ▼              ▼
Pure View      TextureView로 교체 가능한가?
Activity       예 ──┴── 아니오
               │            │
               ▼            ▼
        AndroidView      Pure View
        (TextureView)    Activity
               │
               ▼
        vh/vw CSS 사용 WebView인가?
          예 ──┴── 아니오
          │            │
          ▼            ▼
      Pure View    AndroidView
      Activity     (MATCH_PARENT 필수)

우리 앱의 다른 AndroidView 사용처 점검

이 깨달음으로 앱 전체의 AndroidView 사용처를 다시 훑었더니, 같은 버그가 한 군데 더 숨어 있었습니다.

광고 SDK View처럼 SDK가 직접 크기를 관리하고 vh를 쓰지 않는 경우는 문제가 없습니다. 공식 문서도 AndroidView는 “Compose 대응이 없는 SDK 컴포넌트를 래핑하는 용도”로 권장합니다.

7. 실제 사례 모음 (공개 출처)

우리만 겪은 게 아닙니다. 인터롭 함정은 공개적으로도 반복 보고됩니다.

특히 비디오/카메라를 Compose에서 다룬다면, 구글은 SurfaceView 직접 사용 대신 AndroidExternalSurface / AndroidEmbeddedExternalSurface(또는 Media3 PlayerSurface)를 공식 권장합니다.

참고 출처

• Using Views in Compose — Android Developers
• Surface types (Media3) — Android Developers
• Hardware Acceleration — Android Developers
• WebView not showing as full screen in Compose UI — Medium
• Why Your ExoPlayer Video Ignores Compose Clipping — Medium
• ViewCompositionStrategy Demystified — Android Developers Blog
• SurfaceView stretched/cropped on API 34 — androidx/media #1237

8. 오늘의 교훈

기술 자체보다 잘못된 전제 하나가 더 위험하다는 것을 배웠습니다. “Compose가 WebView와 안 맞는다”는 그럴듯한 가설이 진짜 원인(layoutParams 미설정)을 40개 커밋 동안 가려버렸으니까요.

정리하면 이렇습니다.

1. Modifier와 LayoutParams는 별개의 측정 시스템이다. Modifier.fillMaxSize()는 Compose 레이어 전용이며 내부 View에 자동 전달되지 않는다 — factory에서 layoutParams = MATCH_PARENT를 직접 설정하라.
2. vh/vw CSS 페이지는 loadUrl() 전에 뷰 크기가 확정돼 있어야 한다.
3. 그럼에도, 웹 게임처럼 복잡한 인터랙션·세션이 핵심이라면 Pure View Activity로 분리하는 것이 가장 안정적이다. vh와 터치 문제를 한 번에 없애준다.
4. 막혔을 때는 가설을 의심하라. 같은 방향으로 39번 더 파기 전에, 가장 단순한 전제부터 검증하는 편이 빠르다.

💡 한 줄 정리: 도화지(Compose)와 괴물(WebView)을 같이 그리는 것 자체는 가능하다. 단, 괴물에게 먼저 자리(layoutParams = MATCH_PARENT)를 정확히 내어줘라. 그게 안 되면 전용 운동장(Pure View)으로 보내라.

이 갈증을 해소하기 위해 전 세계 수많은 iOS 개발자들의 ‘바이블’로 통하는 Stanford University의 CS193P (Developing iOS Apps with Swift) 강의를 수강했습니다. 폴 헤가티(Paul Hegarty) 교수의 명강의를 따라가며 직접 구현했던 3개의 핵심 프로젝트와, 그 과정에서 배운 기술적 인사이트를 공유하고자 합니다.

1. 프로젝트 1: Calculator — Swift와의 첫인상

가장 먼저 시작한 프로젝트는 기본적인 계산기 앱(Calculator)이었습니다. 겉보기엔 단순하지만, 이 프로젝트의 진짜 목적은 MVC(Model-View-Controller) 패턴의 엄격한 적용에 있었습니다.

기술적 포인트

• Optional의 이해: Swift가 다른 언어와 구분되는 가장 큰 특징 중 하나인 Optional 처리를 확실하게 체득할 수 있었습니다. 값이 없을 수 있는 상황을 안전하게 다루는 법을 배웠습니다.
• Enum을 활용한 로직 분리: 연산 로직을 Enum으로 분리하여 코드를 구조화했습니다. 단순히 if-else 문을 나열하는 것이 아니라, 연산자의 성격(단항, 이항 등)에 따라 깔끔하게 분기 처리하는 방법을 익혔습니다.

회고: “Swift는 안전(Safety)을 최우선으로 하는 언어구나”라는 것을 깊이 실감했습니다. 컴파일러가 잡아주는 에러들을 수정해가며, 앱이 런타임에 죽는 것을 사전에 방지하는 Swift만의 철학을 느낄 수 있었습니다.

2. 프로젝트 2: Concentration — 데이터와 메모리 관리

두 번째 프로젝트는 같은 그림을 찾는 카드 맞추기 게임(Concentration)이었습니다. 이 단계에서는 시각적인 재미뿐만 아니라 앱의 뒷단에서 일어나는 효율적인 데이터 구조 설계에 집중했습니다.

기술적 포인트

• Struct vs Class: 언제 참조 타입(Class)을 쓰고, 언제 값 타입(Struct)을 써야 하는지 명확한 기준을 세울 수 있었습니다. Swift에서는 Struct가 단순한 데이터 컨테이너 이상의 강력한 역할을 한다는 것을 배웠습니다.
• Property Observer (didSet): 변수의 값이 변경될 때마다 UI를 자동으로 업데이트하거나 특정 로직을 실행하도록 하는 Property Observer 패턴의 편리함을 경험했습니다.

회고: 간단한 메모리 게임이지만, 그 뒤에 숨겨진 배열(Array)의 효율적인 관리와 상태 동기화가 얼마나 중요한지 깨달았습니다. 코드를 작성할 때 단순히 로직을 짜는 것을 넘어 메모리와 데이터의 흐름을 상상하게 되었습니다.

3. 프로젝트 3: PlayingCard — 아름다운 UI의 이면

세 번째는 트럼프 카드의 앞면과 뒷면을 커스텀하게 그려보는 프로젝트(PlayingCard)였습니다. 기본적인 UI 컴포넌트를 넘어서, 개발자가 직접 픽셀 단위로 통제하는 법을 배웠습니다.

기술적 포인트

• 커스텀 드로잉과 @IBDesignable: UIView를 상속받아 직접 화면에 그림을 그리는 방식을 학습했습니다. 특히 @IBDesignable과 @IBInspectable을 활용해 코드로 작성한 UI가 스토리보드에 실시간으로 반영되는 경험은 무척 인상적이었습니다.
• Core Graphics 활용: 단순히 이미지를 띄우는 것이 아니라, Core Graphics를 이용해 벡터 기반의 그래픽을 코드로 구현해 내는 방법을 배웠습니다.

회고: 코드로 직접 UI를 한 땀 한 땀 그려보며 느낀 성취감은 대단했습니다. 동시에 부드러운 애니메이션과 세밀한 UI 조정에 필요한 수학적 연산과 제약 사항들에 대해서도 깊이 고민해 보는 계기가 되었습니다.

마무리: 강의가 나에게 남긴 것

CS193P 강의를 수강하며 남긴 레포지토리들(Calculator, Concentration, PlayingCard)은 단순한 실습 결과물을 넘어 제 성장의 기록이 되었습니다.

이 강의는 단지 문법을 알려주는 것을 넘어, Apple이 어떤 철학으로 iOS와 Swift를 설계했는지 이해하게 해 주었습니다. 문서를 꼼꼼히 읽고 스스로 문제를 해결해 나가는 ‘엔지니어링 사고’가 확장되는 귀중한 시간이었습니다.

이제 막 Swift를 시작하시거나, 기존의 지식 위에 기본기를 더욱 탄탄하게 다지고 싶은 동료 개발자분들께 스탠포드 강의를 강력히 추천합니다!

작성된 코드들은 제 GitHub 레포지토리에서 확인하실 수 있습니다.

결과물: glenn-yu.github.io — Jekyll · 로그캣 부팅 인트로 · ⌘K 팔레트 · 다크/라이트 · giscus 댓글 · 커스텀 404. 전체 코드: glenn-yu/glenn-yu.github.io

왜 GitHub Pages 인가

선택지는 많습니다 — Vercel, Netlify, Cloudflare Pages 등. 그중 GitHub Pages 를 고른 이유는 단순합니다.

• 레포 = 사이트 — username.github.io 레포를 만들면 그게 그대로 사이트 URL.
• Jekyll 자동 빌드 — 마크다운만 push 하면 GitHub 가 알아서 빌드. CI 설정 필요 없음.
• 무료 + HTTPS 자동.
• 버전 관리가 곧 발행 이력 — git log 가 변경사항 기록.

단점이라면 “GitHub 화이트리스트된 Jekyll 플러그인만 쓸 수 있다” 정도. 일반 블로그로는 충분합니다.

5분 컷 — 한 줄로 사이트 띄우기

가장 빠른 코스부터 가봅시다.

1. GitHub 에서 새 레포: 이름은 정확히 <본인-username>.github.io, Public.
2. 클론하고 index.html 하나 만들어 push:

git clone https://github.com/<본인>/<본인>.github.io.git
cd <본인>.github.io
echo "<h1>Hello, world</h1>" > index.html
git add index.html
git commit -m "init"
git push origin main

1. 1~2분 후 https://<본인>.github.io 접속.

여기서 끝내도 됩니다. 정적 HTML/CSS/JS 만 잘 짜도 사이트 하나 만드는 데 충분해요. 하지만 글이 늘어나면 레이아웃·메타·목록 처리가 귀찮아지니, 다음 단계로 넘어갑니다.

Jekyll 로 본격 블로그 만들기

블로그 운영에는 Jekyll 이 편합니다. 마크다운 파일을 추가하면 곧 글이 됩니다.

최소 구성:

.
├── _config.yml          # 사이트 설정
├── _layouts/
│   ├── default.html     # 모든 페이지 공통 레이아웃
│   └── post.html        # 블로그 글 레이아웃
├── _includes/
│   ├── head.html
│   ├── header.html
│   └── footer.html
├── _posts/
│   └── YYYY-MM-DD-제목.md
├── assets/css/main.css
├── index.html           # 홈
└── about.md             # 소개

_config.yml 예시:

title: Glenn Yu
tagline: Mobile · Adtech Engineer
url: "https://glenn-yu.github.io"

author:
  name: Glenn Yu
  email: gwangy.yu@gmail.com
  github: glenn-yu

markdown: kramdown
permalink: /posts/:title/
timezone: Asia/Seoul

plugins:
  - jekyll-feed
  - jekyll-sitemap

Gemfile (로컬 미리보기 안 할 거면 없어도 됨):

source "https://rubygems.org"
gem "github-pages", group: :jekyll_plugins
group :jekyll_plugins do
  gem "jekyll-feed"
  gem "jekyll-sitemap"
end

글 한 편 (_posts/2026-05-08-hello.md):

---
title: "안녕하세요"
date: 2026-05-08 14:00:00 +0900
tags: [intro]
---

본문...

push 하면 /posts/안녕하세요/ 로 자동 발행됩니다.

한국어 친화 셋업

기본 시스템 폰트로도 작동하지만, 한국어 가독성에 진심이라면 Pretendard 추천입니다. CDN 한 줄로 끝납니다.

<link rel="stylesheet"
      href="https://cdn.jsdelivr.net/gh/orioncactus/pretendard@v1.3.9/dist/web/variable/pretendardvariable.min.css">

CSS 폰트 스택:

:root {
  --font-sans: "Pretendard Variable", Pretendard, -apple-system,
               BlinkMacSystemFont, "Apple SD Gothic Neo",
               "Segoe UI", Roboto, sans-serif;
}
body { font-family: var(--font-sans); }

다크/라이트 자동 + 수동 토글

prefers-color-scheme 미디어 쿼리만 쓰면 시스템 설정에 따라 자동 전환됩니다.

:root { --bg: #ffffff; --fg: #111418; }
@media (prefers-color-scheme: dark) {
  :root { --bg: #0e1116; --fg: #e6edf3; }
}

수동 토글까지 원하면 data-theme 속성으로 오버라이드를 추가합니다.

:root[data-theme="light"] { --bg: #ffffff; }
:root[data-theme="dark"]  { --bg: #0e1116; }

JS 로 토글하면서 localStorage 에 저장하면 페이지 이동에도 유지됩니다.

function toggleTheme() {
  var cur = document.documentElement.getAttribute('data-theme');
  var next = cur === 'dark' ? 'light' : 'dark';
  document.documentElement.setAttribute('data-theme', next);
  localStorage.setItem('theme', next);
}

페인트 깜빡임을 막으려면 <head> 에서 동기 스크립트로 미리 적용해 두세요.

색다른 한 끗 — 로그캣 부팅 인트로

여기부터는 취향 영역입니다. 저는 안드로이드 개발자 정체성을 살리고 싶어서, 사이트 첫 진입 시 adb logcat 같은 텍스트가 흐르는 인트로를 넣었습니다.

핵심 아이디어:

• sessionStorage 로 세션당 1회만 표시
• 클릭 / 키 입력으로 즉시 skip
• 텍스트는 한 줄씩 setTimeout 으로 출력
• 페이지 본문은 boot-pending 클래스로 잠시 숨김 → 인트로 끝나면 해제

요지만 옮기면:

function runBoot() {
  if (sessionStorage.getItem('boot-seen') === '1') return;
  // overlay 생성, 줄 단위로 setTimeout 출력
  // 끝나면 sessionStorage.setItem('boot-seen', '1')
}

전체 구현 보기.

⌘K 커맨드 팔레트

Linear / VSCode 의 그 팔레트입니다. Cmd+K 누르면 페이지·글·명령을 한 번에 검색.

페이지·글 데이터는 _layouts/default.html 에서 Liquid 로 주입합니다:

<script>
window.SITE_DATA = {
  pages: [
    { title: "Home",  url: "{{ '/' | relative_url }}" },
    { title: "About", url: "{{ '/about/' | relative_url }}" }
  ],
  posts: [
    {%- for p in site.posts -%}
      { title: {{ p.title | jsonify }},
        url: {{ p.url | relative_url | jsonify }} }
      {%- unless forloop.last -%},{%- endunless -%}
    {%- endfor -%}
  ]
};
</script>

JS 쪽에서는 Cmd+K 핸들링 + 간단한 퍼지 매칭 + 화살표 키 네비게이션만 있으면 됩니다.

SEO · 공유 기본 — 파비콘 + OG 이미지

여기는 건너뛰면 안 됩니다. 카카오톡·슬랙·트위터 어디든 링크 미리보기가 안 뜨면 사이트가 빈약해 보여요.

파비콘 (SVG 추천 — 모던 브라우저 모두 지원):

<link rel="icon" type="image/svg+xml" href="/assets/favicon.svg">
<link rel="icon" type="image/png" sizes="64x64" href="/assets/favicon.png">
<link rel="apple-touch-icon" href="/assets/apple-touch-icon.png">

Open Graph / Twitter Card 메타:

<meta property="og:type" content="website">
<meta property="og:title" content="{{ site.title }}">
<meta property="og:description" content="{{ site.description }}">
<meta property="og:image" content="{{ '/assets/og-image.png' | absolute_url }}">
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:image" content="{{ '/assets/og-image.png' | absolute_url }}">

OG 이미지는 1200×630 권장이지만 1200×1200 도 대부분 플랫폼이 받아줍니다. 디자이너 없으면 SVG 로 직접 그리고 macOS 의 qlmanage 로 PNG 변환 가능:

qlmanage -t -s 1200 -o . og-image.svg
mv og-image.svg.png og-image.png

포스트 UX 폴리시

읽기 시간 — kramdown 의 size 필터로 글자 수 세고 분 단위 환산. 한국어 기준 ~500자/분:

{%- assign chars = content | strip_html | size -%}
{%- assign rt = chars | divided_by: 500 | plus: 1 -%}
📖 {{ rt }}분 읽기

코드 복사 버튼 — <pre> 마다 버튼 주입:

document.querySelectorAll('.post-content pre').forEach(function (pre) {
  var btn = document.createElement('button');
  btn.textContent = 'Copy';
  btn.onclick = function () {
    var code = (pre.querySelector('code') || pre).textContent;
    navigator.clipboard.writeText(code);
    btn.textContent = 'Copied!';
    setTimeout(function () { btn.textContent = 'Copy'; }, 1500);
  };
  pre.appendChild(btn);
});

헤딩 앵커 — kramdown 은 auto_ids 가 기본 활성이라 h2 / h3 에 자동으로 id 가 붙습니다. JS 로 호버 시 보이는 # 링크만 추가하면 됩니다.

document.querySelectorAll('.post-content h2[id], .post-content h3[id]')
  .forEach(function (h) {
    var a = document.createElement('a');
    a.className = 'heading-anchor';
    a.href = '#' + h.id;
    a.textContent = '#';
    h.appendChild(a);
  });

giscus 댓글

Disqus 대신 GitHub Discussions 기반 giscus 를 썼습니다. 광고 없고, 댓글이 곧 디스커션이라 통계 보기도 편합니다.

셋업 순서:

1. 레포에 Discussions 활성화:

   gh api -X PATCH repos/<유저>/<레포> -f has_discussions=true
   

2. github.com/apps/giscus 에서 giscus 앱을 레포에 설치.
3. giscus.app 에서 설정 후 스크립트 카피.

스크립트 (_includes/giscus.html 같은 곳에 두고 post 레이아웃에서 include):

<script src="https://giscus.app/client.js"
        data-repo="<유저>/<레포>"
        data-repo-id="..."
        data-category="Announcements"
        data-category-id="..."
        data-mapping="pathname"
        data-theme="preferred_color_scheme"
        data-lang="ko"
        crossorigin="anonymous"
        async>
</script>

수동 테마 토글이 있으면 giscus iframe 한테도 알려줘야 합니다:

iframe.contentWindow.postMessage(
  { giscus: { setConfig: { theme: 'dark' } } },
  'https://giscus.app'
);

404 페이지에도 정체성을

/404.html 만들어 두면 GitHub Pages 가 안 잡히는 경로마다 자동으로 띄워줍니다. 저는 안드로이드 크래시 화면 미러링한 logcat 스타일로 만들었습니다.

FATAL EXCEPTION: main
Process: io.glenn.site, PID: 404
com.gwangy.site.RouteNotFoundException: no route matched "/asdf"
    at com.gwangy.site.Router.resolve(Router.kt:42)
    ...

JS 로 잘못 입력된 경로를 동적으로 박아 넣어서 어디서 길을 잃었는지 보여줍니다.

document.getElementById('bad-path').textContent
  = '"' + (location.pathname + location.search).slice(0, 80) + '"';

정리하며

하루 만에 만든 셋업이지만 글 쓸 환경으로는 충분합니다. 정리하면 이렇습니다.

필수

• username.github.io 레포 + index.html
• Jekyll layouts / includes / posts
• 다크 · 라이트 + 한국어 폰트
• 파비콘 + OG 이미지

있으면 좋은

• 정체성을 드러내는 한 끗 (부팅 인트로 같은)
• ⌘K 팔레트
• 읽기 시간 + 코드 복사 + 헤딩 앵커
• giscus 댓글
• 커스텀 404

다음은 사이트를 만지는 게 아니라 글을 쓰는 것입니다. 만든 도구를 실제로 쓰면서 부족한 부분을 발견하는 게 다음 사이클이에요.

읽어주셔서 감사합니다. 질문 / 제보 / 잘못된 부분은 아래 댓글이나 이슈 로 부탁드립니다 🙇‍♂️

GitHub Pages 와 Jekyll 을 이용해 블로그를 만들었습니다. 앞으로 다음과 같은 주제로 글을 정리해 나갈 예정입니다.

• Android / Kotlin — Jetpack Compose, Coroutines, 아키텍처 패턴
• 모바일 광고 SDK — SSP / Mediation / Bridge 구현
• 크로스플랫폼 — React Native · Flutter Bridge 작업기
• Tooling — Gradle, GitHub Actions, 자동화

왜 Jekyll 인가

• GitHub Pages 가 자동 빌드 — git push 만 하면 끝
• 마크다운 기반 — 글 쓰기에 집중
• 유연한 커스터마이징 — Liquid 템플릿 + Sass

다음 글 예고

다음 글에서는 이 블로그를 만들면서 한 결정들과 한국어 타이포그래피를 위한 Pretendard 적용기를 다뤄볼 예정입니다.

읽어주셔서 감사합니다 🙇‍♂️