<div id="readability-page-1" class="page"><div><p><h2 id="13a2" data-testid="storyTitle">당근 리브랜딩 캠페인 페이지를 개발하며 배운 것</h2></p><div><h2 id="96b7">Gastby로 랜딩 페이지 만들기 개발 회고 및 팁</h2><div><a rel="noopener follow" href="/@june.jung?source=post_page-----b41d866df9b7--------------------------------"><div aria-hidden="false"><p><img alt="Hyeonsu Jung" src="https://miro.medium.com/v2/resize:fill:88:88/1*Pw-f41EMnVJw_1Jcc3_zoA.png" width="44" height="44" loading="lazy" data-testid="authorPhoto"></p></div></a><a href="https://medium.com/daangn?source=post_page-----b41d866df9b7--------------------------------" rel="noopener follow"><div aria-hidden="false"><p><img alt="당근 테크 블로그" src="https://miro.medium.com/v2/resize:fill:48:48/1*Bm8_nGjfNiKV0PASwiPELg.png" width="24" height="24" loading="lazy" data-testid="publicationPhoto"></p></div></a></div></div><p id="e28c">2023년 8월, 당근마켓이 당근으로 <a href="https://about.daangn.com/blog/archive/%EB%8B%B9%EA%B7%BC-%EB%A6%AC%EB%B8%8C%EB%9E%9C%EB%94%A9-%EC%84%9C%EB%B9%84%EC%8A%A4%EB%AA%85-%EB%A1%9C%EA%B3%A0-%EB%A6%AC%EB%89%B4%EC%96%BC/" rel="noopener ugc nofollow" target="_blank">새로 거듭났습니다</a>.</p><p id="b673">지역 생활 커뮤니티로서 더 당근다워진, 더 선명해진 비전을 사용자에게 잘 전달하기 위해 당근 리브랜딩 캠페인 페이지도 문을 열었는데요. 해당 랜딩 페이지를… 바로 제가 개발했답니다! (하하 감사합니다)</p><p id="d8db">전사 차원에서 진행된 리브랜딩 프로젝트의 랜딩 페이지를 개발하면서 큰 성취감도 느꼈지만 또 그에 따른 부담감도 있었는데요. 개발하며 겪은 크고 작은 어려움을 공유하고, 다음에 또 랜딩 페이지를 개발한다면 어떤 식으로 진행할지 고민을 담은 글을 작성해보려 합니다.</p><p id="743b">랜딩 페이지를 개발하는 많은 프론트엔드 개발자분께 도움이 되었으면 좋겠네요!</p><h2 id="4f7c">개발 프레임워크 선택</h2><p id="d375">당근 리브랜딩 캠페인 페이지 개발 프레임워크로 Gatsby를 선택했어요. Gatsby를 선택한 이유는 사실 길게 고민하지 않았어요. 리브랜딩 캠페인 페이지가 나가야 하는 시간이 거의 한 달 정도 남은 상태였고, 새로운 기술을 배워 적용할 시간이 충분치 않았거든요. 또 주어진 기획안을 구현할 때 Gastby를 썼을 때 가져갈 수 있는 장점도 분명했어요.</p><p id="69c6">각자 처한 상황과 기획안에 맞게 더 편안하고 익숙한, 또 잘 할 수 있는 프레임워크를 택하는 게 중요할 것 같습니다.</p><h2 id="88fc">주로 사용된 개발 프레임워크 및 라이브러리 정리</h2><figure></figure><ul><li id="7970">TypeScript (언어)</li><li id="80a1">GSAP (애니메이션)</li><li id="5788">Gatsby (리액트 기반 프레임워크)</li><li id="9a69">Vanilla Extract (스타일)</li><li id="4fce">Cloudflare (배포)</li></ul><h2 id="bb27">Gatsby 장점</h2><ul><li id="8626">기획에 공유하기 기능이 있어서 이벤트 경품에 대한 링크를 공유하면 경품에 맞는 OG image와 title, description을 따로 보여줘야 하는 기획이 있었어요. 기존 CSR 프레임워크로 작업했으면 이 작업에서 커스텀으로 html을 여러 벌 뽑아주는 작업이 따로 필요했을 텐데, Gatsby를 선택함으로써 해당 작업이 많이 쉬워졌어요.</li><li id="76d4">gatsby의 여러 plugin들을 활용할 수 있다는 것이 큰 장점이었어요. clarity나 google analytics 같은 로그 툴을 붙일 때도 head 태그 안에 스크립트를 넣어주는 귀찮은 작업도 미리 만들어진 플러그인에 id 값만 넣으면 알아서 붙여주고, favicon과 같은 manifest 작업도 플러그인에 이미지 단 하나만 넣어주면 알아서 환경에 맞는 favicon을 미리 다 생성해 놓아요.</li><li id="3516">특히 image 관련 플러그인을 사용하면 브라우저 크기에 맞는 이미지 생성 및 제공을 알아서 처리해 주니 (img의 srcSet과 media와 같은 프로퍼티) 특별히 이미지에 대해서 처리해 줄 게 없었어요. 그냥 preload 해줄지 아니면 lazy 하게 로딩할지만 내가 알아서 판단해서 선언해 놓으면 끝이었어요.</li></ul><h2 id="465e">Gatsby 단점</h2><ul><li id="e79d">Gatsby는 SSG(Static Site Generation)예요. 정적으로 미리 페이지를 뽑아놔요. 기획 중에 모바일과 데스크탑에서 다른 애니메이션을 보여줘야 하는 요구사항이 있었어요. SSG는 알다시피 유저의 브라우저 크기를 미리 알 수가 없어요. 어쩔 수 없이 클라이언트 사이드에서 breakpoint를 계산하고 그에 맞는 애니메이션을 적용해야 했는데, 거기서 조금 많이 엉키는 부분이 많았던 것 같아요.</li><li id="2fa5">GSAP 라이브러리를 사용하는데, GSAP는 구현 방식이 “1번 네모 상자가 왼쪽으로 90px이동” → “2번 세모 상자가 아래로 70px이동” → “등등”과같이 순차적으로 애니메이션을 선언하는 식으로 구현해요. 그리고 <code>ScrollTrigger</code> 라고 하는 친구와 함께 사용하면 스크롤이 어디에 도착했을 때 위에 선언한 애니메이션을 실행해요. 혹은 스크롤의 진행과 함께 애니메이션이 진행된다는 여부를 지정할 수 있어요.</li><li id="22c5">근데 사용자가 브라우저 크기를 동적으로 변경했을 때, (예를 들어 데스크탑 → 모바일 브레이크 포인트로 넘어갔을 때) 데스크탑의 애니메이션과 모바일의 애니메이션이 부딪혀서 요소의 크기가 지정한 대로, 혹은 원하는 대로 움직이지 않는 경우가 몇몇 있어 다른 방식으로 해결해야 했습니다.</li></ul><h2 id="5b97">브레이크 포인트 잘 나누기</h2><p id="8f52">브레이크 포인트는 반응형 웹에서 사이즈가 변화하는 지점을 말하는데요. 어떤 크기의 화면으로, 어떤 환경에서 사이트를 보더라도 모두 불편함 없는 유려한 경험을 주기 위해 브레이크 포인트를 잘 나누는 게 중요해요. 저는 처음부터 브레이크 포인트를 조금 여유롭게 잡았어요.</p><ul><li id="b8ef">0px ~ 360px</li><li id="3d13">360px ~ 768px</li><li id="f1e9">768px ~ 990px</li><li id="544a">990px ~ 1200px</li><li id="e76a">1200px ~</li></ul><p id="d7ff">정확하게 말하면 <code>360px ~ 768px</code> 이 부분이 조금 문제가 됐어요. 해당 브레이크 포인트에 작업을 하면 <code>361px</code>과 <code>767px</code>을 동시에 고려한다는 의미가 돼요. 모바일과 태블릿 크기의 기기에서 같은 레이아웃을 가진다면 크게 문제가 되지 않지만, 만약 둘의 레이아웃이 다르다면 그때부터 많이 힘들어져요.</p><p id="6f71">처음부터 “스마트폰, 태블릿”이 아니라 “작은 스마트폰, 큰 스마트폰, 태블릿”으로 나눠서 갔으면 수월하게 작업했을 것 같아요.</p><ul><li id="d23c">0px ~ 360px (작은 스마트폰)</li><li id="b332">360px ~ 480px (큰 스마트폰)</li><li id="12b1">480px ~ 768px (작은 태블릿)</li><li id="4087">768px ~ 990px (큰 태블릿)</li><li id="4be8">990px ~ 1200px (작은 데스크탑)</li><li id="87b5">1200px ~ (큰 데스크탑)</li></ul><h2 id="2567">처음부터 안드로이드, iOS 에뮬레이터를 켜고 개발을 하자.</h2><p id="7c22">저는 보통 랜딩 페이지 개발을 할 때 데스크탑 유저를 중심으로 생각했는데요. 이번 프로젝트는 당근 앱으로 월 1800만 명의 사용자에게 소식을 전하는 만큼, 모바일 유저의 경험도 주요하게 살폈어요. 그런데 실제로 리브랜딩 랜딩 페이지를 오픈하려고 살펴보니 모바일 사용량이 압도적으로 많더라고요. 그중에서도 안드로이드 유저가 정말 많다는 사실을 발견하며 사용자에 대해 다시 한번 이해할 수 있게 되었어요.</p><p id="8d98">랜딩 페이지 개발을 할 때 항상 크롬 브라우저를 켜놓고 개발했어요. 랜딩 페이지 개발 막바지 거의 1–2주간은 android 기기에서의 이슈를 해결하는데 시간을 쓴 것 같아요. 차라리 안드로이드 에뮬레이터를 켜고 거기에서 로컬로 띄워서 개발을 시작했다면 돌아가는 시간이 더 적지 않았을까 하는 생각이 드네요.</p><p id="e974">이처럼 자신이 만들고 있는 랜딩 페이지가 대상으로 하는 유저를 처음부터 잘 생각하고, 우선순위를 잘 따지는 게 중요해요.</p><h2 id="7ba9">라이브러리 선택을 할 땐 최대한 메이저 라이브러리를 선택하자.</h2><p id="1d41">랜딩 페이지를 만들 때 스크롤 트랜지션과 같은 애니메이션을 도와주는 라이브러리인 <code>gsap</code> 를 사용했어요. 그리고 해당 라이브러리를 한 번 감싸서 React Component로 만들어 놓고 애니메이션을 선언적으로 사용할 수 있는 라이브러리인 <code>react-gsap</code>이 있었어요.</p><p id="e634">저는 <code>React</code>를 사용하고 있기도 했고, 리액트 컴포넌트로 선언해서 사용하는 방식이 애니메이션이 어떻게 흘러가는지 직관적이기도 해서 <code>react-gsap</code> 를 사용했어요.</p><p id="d2a7">결론을 말하자면 프로젝트 막바지에는 <code>gsap</code> 로 마이그레이션 했어요.</p><p id="ab73">브레이크 포인트별로 애니메이션과 트렌지션을 따로 걸어줘야 하는 상황이 있었는데 <code>react-gsap</code> 에는 클라이언트 사이드에서 어떤 애니메이션을 보여줘야 하는지 결정하는 순간에 충돌이 나는 이슈가 있었고, 따로 브레이크 포인트와 관련된 인터페이스를 제공해 주지 않았어요.</p><p id="d873">하지만 <code>gsap</code> 라이브러리에는 브레이크 포인트와 관련된 인터페이스가 있었어요. <code>react-gsap</code> 가 <code>gsap</code> 의 인터페이스를 그대로 pass 해주고 있지도 않고, 문서도 잘 적혀있지도 않았어요.</p><p id="abdf">제가 오픈소스 제공자라고 해도 메인 라이브러리인 <code>gsap</code> 를 먼저 고치고 문서도 고치지, 그 외에 파생된 라이브러리는 업데이트가 그보다 느리고, 관리도 덜 될 것 같아요. 항상 정상적인 동작만 생각해서 정상적으로 동작했으면 좋겠지만 여러 가지 요인들 때문에 그렇지 못할 가능성이 높아요.</p><p id="0cde">라이브러리 선택할 땐 최대한 메이저 라이브러리를 선택하지, 정말 급한 경우가 아니라면 파생된 라이브러리를 선택하는 일은 지양해야 할 것 같아요.</p><h2 id="cce7">모바일 hover 스타일링</h2><ul><li id="7a05">보통 hover 스타일링을 할 때 아래와 같이 스타일링을 할 텐데 모바일에서 hover를 아래와 같이 스타일링하면 hover가 된 상태로 포커스가 옮겨가기 전까지 hover를 유지하는 현상이 있어요.</li></ul><pre><span id="beab">div:hover {<br>  color: "black"<br>}</span></pre><ul><li id="3df7">본래 hover라는 이벤트가 “마우스”를 올렸을 때 일어나는 이벤트인데, 모바일 기기 마우스가 없기 때문에 이벤트의 발생과 종료가 애매해요.</li><li id="a31d">그래서 hover media query를 통해서 기본적으로 현재 기기가 호버 메커니즘을 지원하는지 여부에 따라서 스타일링을 할 수 있어요.</li></ul><pre><span id="f541">@media (hover: hover) {<br>  /* when hover is supported */<br>  a:hover {<br>    color: white;<br>    background: black;<br>  }<br>}</span></pre><ul><li id="7534">또한 <a href="https://www.npmjs.com/package/postcss-hover-media-feature" rel="noopener ugc nofollow" target="_blank">Post CSS 플러그인</a> (<strong>PostCSS Hover Media Feature)</strong> 같은 걸 활용할 수도 있어요.</li><li id="5ddf">참고 <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/@media/hover" rel="noopener ugc nofollow" target="_blank">MDN</a></li></ul><h2 id="ff5f">안드로이드 웹뷰에서 강제 다크모드가 적용되는 것에 대해서</h2><blockquote><p id="d6fd"><em>Thanks to Edward</em></p></blockquote><ul><li id="5bdd">회사마다 안드로이드 환경에서 웹뷰의 다크모드에 대한 설정이 다 다르겠지만, 만약 랜딩 페이지가 오직 라이트 모드에서만 동작을 원한다고 해도 meta 설정을 해야 해요. 그렇지 않으면 유저의 시스템 테마를 보고 강제로 다크로 입히는 설정이 안드로이드에 있어요.</li></ul><figure><figcaption>web.dev</figcaption></figure><ul><li id="7c90">그렇기에 오직 라이트모드로 디자인이 되어있더라도, 혹은 반대로 다크모드로만 의도된 디자인이더라도, 우리는 루트나 메타 태그로 color-scheme을 명시해야 해요. 그렇지 않으면 시스템 테마에 의해 원하지 않는 컬러가 들어갈 수도 있어요.</li><li id="24af">제가 헷갈렸던 부분은 ‘<code>color-scheme: dark light</code>가 아니라 <code>only light</code> 가 되어야 하는 게 아닌가?’하는 부분이었는데, 이후 살펴보니 <strong>애초에 color-scheme을 아예 제공해 주지 않아서 값이 </strong><code><strong>normal</strong></code><strong> 로 들어가서 유저 에이전트에 의해서 원치 않는 테마가 들어간 것이 문제</strong>였다는 걸 발견했어요. 따라서<code>dark light</code> 라도 명시를 해줬다는 것이 중요해요.</li><li id="a07d">그리고 <code>only light</code>로 더 명시적으로 할 수도 있다는 것을 새롭게 알게 됐어요.</li><li id="3f00"><code>dark light</code>로 지정해도 이 페이지가 <strong>“dark와 light를 제공할 수도(강조) 있다.”</strong> 인 거지 <strong>“dark와 light를 무조건 지원한다”</strong> 가 아니에요.</li><li id="beaa">따라서 개발자가 아래와 같은 코드로 dark 모드에 대한 스타일이 지정이 되어있으면, 개발자의 의도대로 동작한다는 얘기예요. 이게 없으면 위에서 말한 것처럼 유저 시스템 테마에 의해 원치 않는 스타일이 들어갈 수 있어요.</li><li id="909d">아래와 같이 넣으면 돼요.</li></ul><pre><span id="c39e">@media (prefers-color-scheme: dark) {<br>  fieldset {<br>    background-color: darkslategray;<br>  }<br>}</span></pre><pre><span id="78fb">:root {<br>  color-scheme: dark light;<p>  /* 명시적 light 모드 */<br>  color-scheme: only light;<br>}</p></span></pre><pre><span id="f521">&lt;meta name="color-scheme" content="light dark"&gt;</span></pre><p id="7fe5">추가적으로 크롬 데스크탑 브라우저에서 안드로이드의 강제 다크모드를 디버그 하고 싶다면 크롬에서 chrome://flags/ 에 들어가서 <code>Auto Dark Mode for Web Contents</code> 옵션을 <code>Enabled</code>로 변경하고 테스트해 보면 돼요.</p><figure><figcaption>chrome://flags/</figcaption></figure><p id="711c">참고</p><ul><li id="8ba5"><a href="https://web.dev/color-scheme/" rel="noopener ugc nofollow" target="_blank">web.dev</a></li><li id="927c"><a href="https://developer.android.com/develop/ui/views/layout/webapps/dark-theme" rel="noopener ugc nofollow" target="_blank">android dark theme</a></li></ul><h2 id="2cf9">그 외에 자잘한 이슈들 혹은 레슨런</h2><h2 id="8766">iOS에서 <code>overflow: hidden</code>과 <code>border-radius</code> 속성을 적용하려면 <code>isolation: isolate</code>를 잊으면 안돼요.</h2><ul><li id="8edd">iOS safari에서는 요소를 레이어링하는 메커니즘인 <a href="https://developer.mozilla.org/ko/docs/Web/CSS/CSS_positioned_layout/Understanding_z-index/Stacking_context" rel="noopener ugc nofollow" target="_blank">쌓임맥락</a>이 다른 브라우저들과 다르기 때문에 isolate 옵션을 통해서 overflow hidden을 적용하고자 하는 요소에 쌓임 맥락을 격리해 주면 돼요.</li></ul><h2 id="d89f">전체 화면을 덮는 모달 같은 것이 요구사항에 있다면 히스토리 API 조작을 해야 해요.</h2><ul><li id="29be">안드로이드 유저들은 뒤로 가기 버튼을 눌러서 모달을 끄거나 페이지를 나가는 것이 익숙한 방식인데, 히스토리 조작을 하지 않는다면 뒤로 가기 버튼을 눌렀을 때 페이지를 이탈해 버려요.</li><li id="2277">이건 큰 이슈이기 때문에 히스토리 조작을 해서 모달을 켤 때 history.pushState 해주고, <code>popstate</code> 이벤트 리스너를 붙여서 popstate가 일어날 때 모달을 닫아주기만 하면 돼요.</li></ul><h2 id="1d21">안드로이드에서 Video Tag에 백그라운드 컬러가 원하는 컬러가 적용되지 않는 현상</h2><ul><li id="18ac">모바일 디바이스에서 사용되는 GPU (그래픽카드)에 따라서 보이는 RGB 값에 제한이 있는 경우가 있어요. 색을 전부 표현하지 못하고 제한시켜서 보여주는 현상이 있어요.</li><li id="632b">랜딩 페이지 같은 경우에는 비디오 태그에 대비를 살짝 늘리는 방식으로 해결했는데, 모든 안드로이드 기기에 다 대응이 될지는 모르겠어요. 테스트폰에서는 대응이 됐어요.</li></ul><pre><span id="9dca">filter: contrast(101%);</span></pre><ul><li id="7b07">참고: <a href="https://stackoverflow.com/questions/35214962/html5-video-background-color-not-matching-background-color-of-website-in-some" rel="noopener ugc nofollow" target="_blank">https://stackoverflow.com/questions/35214962/html5-video-background-color-not-matching-background-color-of-website-in-some</a></li></ul><h2 id="84c6">iOS 모바일 기기에서 요소에 터치할 때 나오는 음영에 대해서</h2><ul><li id="64ae">iOS 모바일 기기에서 버튼과 같은 요소 터치하면 검은색 배경이 잡히는 현상이 있어요. 아래와 같이 스타일을 주면 없앨 수 있어요.</li></ul><pre><span id="8f5b">* {<br>  -webkit-tap-highlight-color:rgba(255,255,255,0);<br>}</span></pre><h2 id="fb98">모바일 기기에서 핀치 줌 막기</h2><ul><li id="be99">리브랜딩 페이지와 같이 일관된 경험이 중요한 페이지에서 유저가 임의로 줌을 해서 이상한 경험하는 것을 막고 싶다면 아래와 같은 메타 태그를 작성해서 막을 수 있어요.</li></ul><pre><span id="8371">&lt;meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1.0, minimum-scale=1, user-scalable=0"&gt;</span></pre></div></div>

당근마켓 팀블로그 - Medium

Gastby로 랜딩 페이지 만들기 개발 회고 및 팁
2023년 8월, 당근마켓이 당근으로 새로 거듭났습니다.
지역 생활 커뮤니티로서 더 당근다워진, 더 선명해진 비전을 사용자에게 잘 전달하기 위해 당근 리브랜딩 캠페인 페이지도 문을 열었는데요. 해당 랜딩 페이지를… 바로 제가 개발했답니다! (하하 감사합니다)
당신 근처의 당근
전사 차원에서 진행된 리브랜딩 프로젝트의 랜딩 페이지를 개발하면서 큰 성취감도 느꼈지만 또 그에 따른 부담감도 있었는데요. 개발하며 겪은 크고 작은 어려움을 공유하고, 다음에 또 랜딩 페이지를 개발한다면 어떤 식으로 진행할지 고민을 담은 글을 작성해보려 합니다.
랜딩 페이지를 개발하는 많은 프론트엔드 개발자분께 도움이 되었으면 좋겠네요!
개발 프레임워크 선택
당근 리브랜딩 캠페인 페이지 개발 프레임워크로 Gatsby를 선택했어요. Gatsby를 선택한 이유는 사실 길게 고민하지 않았어요. 리브랜딩 캠페인 페이지가 나가야 하는 시간이 거의 한 달 정도 남은 상태였고, 새로운 기술을 배워 적용할 시간이 충분치 않았거든요. 또 주어진 기획안을 구현할 때 Gastby를 썼을 때 가져갈 수 있는 장점도 분명했어요.
각자 처한 상황과 기획안에 맞게 더 편안하고 익숙한, 또 잘 할 수 있는 프레임워크를 택하는 게 중요할 것 같습니다.
주로 사용된 개발 프레임워크 및 라이브러리 정리
TypeScript (언어)
GSAP (애니메이션)
Gatsby (리액트 기반 프레임워크)
Vanilla Extract (스타일)
Cloudflare (배포)
Gatsby 장점
기획에 공유하기 기능이 있어서 이벤트 경품에 대한 링크를 공유하면 경품에 맞는 OG image와 title, description을 따로 보여줘야 하는 기획이 있었어요. 기존 CSR 프레임워크로 작업했으면 이 작업에서 커스텀으로 html을 여러 벌 뽑아주는 작업이 따로 필요했을 텐데, Gatsby를 선택함으로써 해당 작업이 많이 쉬워졌어요.
gatsby의 여러 plugin들을 활용할 수 있다는 것이 큰 장점이었어요. clarity나 google analytics 같은 로그 툴을 붙일 때도 head 태그 안에 스크립트를 넣어주는 귀찮은 작업도 미리 만들어진 플러그인에 id 값만 넣으면 알아서 붙여주고, favicon과 같은 manifest 작업도 플러그인에 이미지 단 하나만 넣어주면 알아서 환경에 맞는 favicon을 미리 다 생성해 놓아요.
특히 image 관련 플러그인을 사용하면 브라우저 크기에 맞는 이미지 생성 및 제공을 알아서 처리해 주니 (img의 srcSet과 media와 같은 프로퍼티) 특별히 이미지에 대해서 처리해 줄 게 없었어요. 그냥 preload 해줄지 아니면 lazy 하게 로딩할지만 내가 알아서 판단해서 선언해 놓으면 끝이었어요.
Gatsby 단점
Gatsby는 SSG(Static Site Generation)예요. 정적으로 미리 페이지를 뽑아놔요. 기획 중에 모바일과 데스크탑에서 다른 애니메이션을 보여줘야 하는 요구사항이 있었어요. SSG는 알다시피 유저의 브라우저 크기를 미리 알 수가 없어요. 어쩔 수 없이 클라이언트 사이드에서 breakpoint를 계산하고 그에 맞는 애니메이션을 적용해야 했는데, 거기서 조금 많이 엉키는 부분이 많았던 것 같아요.
GSAP 라이브러리를 사용하는데, GSAP는 구현 방식이 “1번 네모 상자가 왼쪽으로 90px이동” → “2번 세모 상자가 아래로 70px이동” → “등등”과같이 순차적으로 애니메이션을 선언하는 식으로 구현해요. 그리고 ScrollTrigger 라고 하는 친구와 함께 사용하면 스크롤이 어디에 도착했을 때 위에 선언한 애니메이션을 실행해요. 혹은 스크롤의 진행과 함께 애니메이션이 진행된다는 여부를 지정할 수 있어요.
근데 사용자가 브라우저 크기를 동적으로 변경했을 때, (예를 들어 데스크탑 → 모바일 브레이크 포인트로 넘어갔을 때) 데스크탑의 애니메이션과 모바일의 애니메이션이 부딪혀서 요소의 크기가 지정한 대로, 혹은 원하는 대로 움직이지 않는 경우가 몇몇 있어 다른 방식으로 해결해야 했습니다.
브레이크 포인트 잘 나누기
브레이크 포인트는 반응형 웹에서 사이즈가 변화하는 지점을 말하는데요. 어떤 크기의 화면으로, 어떤 환경에서 사이트를 보더라도 모두 불편함 없는 유려한 경험을 주기 위해 브레이크 포인트를 잘 나누는 게 중요해요. 저는 처음부터 브레이크 포인트를 조금 여유롭게 잡았어요.
0px ~ 360px
360px ~ 768px
768px ~ 990px
990px ~ 1200px
1200px ~
정확하게 말하면 360px ~ 768px 이 부분이 조금 문제가 됐어요. 해당 브레이크 포인트에 작업을 하면 361px과 767px을 동시에 고려한다는 의미가 돼요. 모바일과 태블릿 크기의 기기에서 같은 레이아웃을 가진다면 크게 문제가 되지 않지만, 만약 둘의 레이아웃이 다르다면 그때부터 많이 힘들어져요.
처음부터 “스마트폰, 태블릿”이 아니라 “작은 스마트폰, 큰 스마트폰, 태블릿”으로 나눠서 갔으면 수월하게 작업했을 것 같아요.
0px ~ 360px (작은 스마트폰)
360px ~ 480px (큰 스마트폰)
480px ~ 768px (작은 태블릿)
768px ~ 990px (큰 태블릿)
990px ~ 1200px (작은 데스크탑)
1200px ~ (큰 데스크탑)
처음부터 안드로이드, iOS 에뮬레이터를 켜고 개발을 하자.
저는 보통 랜딩 페이지 개발을 할 때 데스크탑 유저를 중심으로 생각했는데요. 이번 프로젝트는 당근 앱으로 월 1800만 명의 사용자에게 소식을 전하는 만큼, 모바일 유저의 경험도 주요하게 살폈어요. 그런데 실제로 리브랜딩 랜딩 페이지를 오픈하려고 살펴보니 모바일 사용량이 압도적으로 많더라고요. 그중에서도 안드로이드 유저가 정말 많다는 사실을 발견하며 사용자에 대해 다시 한번 이해할 수 있게 되었어요.
랜딩 페이지 개발을 할 때 항상 크롬 브라우저를 켜놓고 개발했어요. 랜딩 페이지 개발 막바지 거의 1–2주간은 android 기기에서의 이슈를 해결하는데 시간을 쓴 것 같아요. 차라리 안드로이드 에뮬레이터를 켜고 거기에서 로컬로 띄워서 개발을 시작했다면 돌아가는 시간이 더 적지 않았을까 하는 생각이 드네요.
이처럼 자신이 만들고 있는 랜딩 페이지가 대상으로 하는 유저를 처음부터 잘 생각하고, 우선순위를 잘 따지는 게 중요해요.
라이브러리 선택을 할 땐 최대한 메이저 라이브러리를 선택하자.
랜딩 페이지를 만들 때 스크롤 트랜지션과 같은 애니메이션을 도와주는 라이브러리인 gsap 를 사용했어요. 그리고 해당 라이브러리를 한 번 감싸서 React Component로 만들어 놓고 애니메이션을 선언적으로 사용할 수 있는 라이브러리인 react-gsap이 있었어요.
저는 React를 사용하고 있기도 했고, 리액트 컴포넌트로 선언해서 사용하는 방식이 애니메이션이 어떻게 흘러가는지 직관적이기도 해서 react-gsap 를 사용했어요.
결론을 말하자면 프로젝트 막바지에는 gsap 로 마이그레이션 했어요.
브레이크 포인트별로 애니메이션과 트렌지션을 따로 걸어줘야 하는 상황이 있었는데 react-gsap 에는 클라이언트 사이드에서 어떤 애니메이션을 보여줘야 하는지 결정하는 순간에 충돌이 나는 이슈가 있었고, 따로 브레이크 포인트와 관련된 인터페이스를 제공해 주지 않았어요.
하지만 gsap 라이브러리에는 브레이크 포인트와 관련된 인터페이스가 있었어요. react-gsap 가 gsap 의 인터페이스를 그대로 pass 해주고 있지도 않고, 문서도 잘 적혀있지도 않았어요.
제가 오픈소스 제공자라고 해도 메인 라이브러리인 gsap 를 먼저 고치고 문서도 고치지, 그 외에 파생된 라이브러리는 업데이트가 그보다 느리고, 관리도 덜 될 것 같아요. 항상 정상적인 동작만 생각해서 정상적으로 동작했으면 좋겠지만 여러 가지 요인들 때문에 그렇지 못할 가능성이 높아요.
라이브러리 선택할 땐 최대한 메이저 라이브러리를 선택하지, 정말 급한 경우가 아니라면 파생된 라이브러리를 선택하는 일은 지양해야 할 것 같아요.
모바일 hover 스타일링
보통 hover 스타일링을 할 때 아래와 같이 스타일링을 할 텐데 모바일에서 hover를 아래와 같이 스타일링하면 hover가 된 상태로 포커스가 옮겨가기 전까지 hover를 유지하는 현상이 있어요.
div:hover {
  color: "black"
}
본래 hover라는 이벤트가 “마우스”를 올렸을 때 일어나는 이벤트인데, 모바일 기기 마우스가 없기 때문에 이벤트의 발생과 종료가 애매해요.
그래서 hover media query를 통해서 기본적으로 현재 기기가 호버 메커니즘을 지원하는지 여부에 따라서 스타일링을 할 수 있어요.
@media (hover: hover) {
  /* when hover is supported */
  a:hover {
    color: white;
    background: black;
  }
}
또한 Post CSS 플러그인 (PostCSS Hover Media Feature) 같은 걸 활용할 수도 있어요.
참고 MDN
안드로이드 웹뷰에서 강제 다크모드가 적용되는 것에 대해서
Thanks to Edward
회사마다 안드로이드 환경에서 웹뷰의 다크모드에 대한 설정이 다 다르겠지만, 만약 랜딩 페이지가 오직 라이트 모드에서만 동작을 원한다고 해도 meta 설정을 해야 해요. 그렇지 않으면 유저의 시스템 테마를 보고 강제로 다크로 입히는 설정이 안드로이드에 있어요.
그렇기에 오직 라이트모드로 디자인이 되어있더라도, 혹은 반대로 다크모드로만 의도된 디자인이더라도, 우리는 루트나 메타 태그로 color-scheme을 명시해야 해요. 그렇지 않으면 시스템 테마에 의해 원하지 않는 컬러가 들어갈 수도 있어요.
제가 헷갈렸던 부분은 ‘color-scheme: dark light가 아니라 only light 가 되어야 하는 게 아닌가?’하는 부분이었는데, 이후 살펴보니 애초에 color-scheme을 아예 제공해 주지 않아서 값이 normal 로 들어가서 유저 에이전트에 의해서 원치 않는 테마가 들어간 것이 문제였다는 걸 발견했어요. 따라서dark light 라도 명시를 해줬다는 것이 중요해요.
그리고 only light로 더 명시적으로 할 수도 있다는 것을 새롭게 알게 됐어요.
dark light로 지정해도 이 페이지가 “dark와 light를 제공할 수도(강조) 있다.” 인 거지 “dark와 light를 무조건 지원한다” 가 아니에요.
따라서 개발자가 아래와 같은 코드로 dark 모드에 대한 스타일이 지정이 되어있으면, 개발자의 의도대로 동작한다는 얘기예요. 이게 없으면 위에서 말한 것처럼 유저 시스템 테마에 의해 원치 않는 스타일이 들어갈 수 있어요.
아래와 같이 넣으면 돼요.
@media (prefers-color-scheme: dark) {
  fieldset {
    background-color: darkslategray;
  }
}
:root {
  color-scheme: dark light;
  /* 명시적 light 모드 */
  color-scheme: only light;
}
<meta name="color-scheme" content="light dark">
추가적으로 크롬 데스크탑 브라우저에서 안드로이드의 강제 다크모드를 디버그 하고 싶다면 크롬에서 chrome://flags/ 에 들어가서 Auto Dark Mode for Web Contents 옵션을 Enabled로 변경하고 테스트해 보면 돼요.
참고
web.dev
android dark theme
그 외에 자잘한 이슈들 혹은 레슨런
iOS에서 overflow: hidden과 border-radius 속성을 적용하려면 isolation: isolate를 잊으면 안돼요.
iOS safari에서는 요소를 레이어링하는 메커니즘인 쌓임맥락이 다른 브라우저들과 다르기 때문에 isolate 옵션을 통해서 overflow hidden을 적용하고자 하는 요소에 쌓임 맥락을 격리해 주면 돼요.
전체 화면을 덮는 모달 같은 것이 요구사항에 있다면 히스토리 API 조작을 해야 해요.
안드로이드 유저들은 뒤로 가기 버튼을 눌러서 모달을 끄거나 페이지를 나가는 것이 익숙한 방식인데, 히스토리 조작을 하지 않는다면 뒤로 가기 버튼을 눌렀을 때 페이지를 이탈해 버려요.
이건 큰 이슈이기 때문에 히스토리 조작을 해서 모달을 켤 때 history.pushState 해주고, popstate 이벤트 리스너를 붙여서 popstate가 일어날 때 모달을 닫아주기만 하면 돼요.
안드로이드에서 Video Tag에 백그라운드 컬러가 원하는 컬러가 적용되지 않는 현상
모바일 디바이스에서 사용되는 GPU (그래픽카드)에 따라서 보이는 RGB 값에 제한이 있는 경우가 있어요. 색을 전부 표현하지 못하고 제한시켜서 보여주는 현상이 있어요.
랜딩 페이지 같은 경우에는 비디오 태그에 대비를 살짝 늘리는 방식으로 해결했는데, 모든 안드로이드 기기에 다 대응이 될지는 모르겠어요. 테스트폰에서는 대응이 됐어요.
filter: contrast(101%);
참고: https://stackoverflow.com/questions/35214962/html5-video-background-color-not-matching-background-color-of-website-in-some
iOS 모바일 기기에서 요소에 터치할 때 나오는 음영에 대해서
iOS 모바일 기기에서 버튼과 같은 요소 터치하면 검은색 배경이 잡히는 현상이 있어요. 아래와 같이 스타일을 주면 없앨 수 있어요.
* {
  -webkit-tap-highlight-color:rgba(255,255,255,0);
}
모바일 기기에서 핀치 줌 막기
리브랜딩 페이지와 같이 일관된 경험이 중요한 페이지에서 유저가 임의로 줌을 해서 이상한 경험하는 것을 막고 싶다면 아래와 같은 메타 태그를 작성해서 막을 수 있어요.
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1.0, minimum-scale=1, user-scalable=0">
이 글은 제가 당근 리브랜딩 랜딩 페이지를 만들며 겪었던 개발적인 내용들을 적어놓은 글이에요. 개발 이외에 느꼈던 부분들은 제 개인 블로그에 작성해 놓았어요.
끝으로, 지역 로컬 커뮤니티라는 더 선명해진 꿈을 향해 달려가는 당근은 이 여정에 함께 할 다양한 직군을 채용하고 있어요. 당근이 만들어낸 이야기를 흥미롭게 봐 주셨다면, 앞으로 함께 만들어 가보는 건 어떨까요?
🔥 지금 채용 중인 공고 바로가기
당근 팀 채용
당근 리브랜딩 캠페인 페이지를 개발하며 배운 것 was originally published in 당근 테크 블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.

당근 리브랜딩 캠페인 페이지를 개발하며 배운 것

댓글