온갖 동적 요소가 모인 밀리의 서재의 Ex-Web
[코드스테이츠 PMB 10기] 프론트엔드 Front-end
기획자의 눈에 보이는
밀리의 서재 프론트엔드
1. 기획자에게 개발이란
기획자에게 있어, 개발지식은 무엇이고 어디까지 알아야 되는가를 설명하기 앞서 한 때 엄청 유행했던 컴공 개그를 보여주면서 시작하고자 한다. (ㅋㅋ)
위의 게시글을 보면서 만약 빵 터졌다면, (삐빅!) 당신은 컴공입니다! 해당 내용은 '남행열차' 가사를 컴퓨터공학에서 쓰이는 여러 단어들로 재구성한 모습이다.
하지만 만일 컴퓨터공학에 대한 지식이 없는 사람이라면? 어떻게 반응하게 될까?
위의 그림처럼 '그냥 발음이 비슷한 영어단어를 사용한 건가?' 생각해서 저렇게 대답할 지도 모른다. (ㅋㅋ)
이처럼 개뱔 관련 지식은 개발을 배우지 않은 사람들에게는 외계어나 다름이 없다. 그런데 만약 이 상황이 한 팀으로 빠르게 업무를 수행해야 하는 팀 내에서 일어난다면?
만일 개발지식이 전무한 기획자가 다수의 개발자들과 하나의 프로젝트를 진행해야 하는 상황이 온다면 어떨까? 장담컨데, 기획자는 기획자대로 개발자는 개발자대로 엄청 답답해 하면서 감정은 감정대로 상하고, 일은 일대로 진척되지 않을 것이다.
왜냐하면 '이 기능이 필요해요, 이렇게 해주세요.' 라고 해도 개발자는 개발 상으로 문제가 생길 것 같다면 '안 돼요.' 를 반복할 것이기 때문이다. 물론, 처음에는 '무엇 때문에 안 될 것 같다.' 라고 많은 부연설명을 해주겠지만, 아무리 말해도 알아듣지 못하는 상황이 지속된다면 결국 포기하지 않을까?
한 팀, 한 공동체로서 같은 목표를 향해 같이 달려가야 하는 관계에서 이렇게 대화의 골이 생겨버리면 정상적으로 업무를 수행하기가 어렵다. 그렇다고 영원히 개발자를 만나지 않을 수 있는 것도 아니다. 기획자 또는 PM의 위치에 자리잡게 된다면, 개발자란 사람들은 일을 그만 둘 때까지 지속적으로 만나야 하는 사람들이다.
그러므로, 기획자는 개발 용어를 아는 것 뿐만 아니라 개발이 원활하게 진행될 수 있도록 개발 그 자체에 대한 이해도가 요구된다.
개발, 어디까지 알아야 하나요?
기획자에게 개발에 대한 지식이 요구된다는 사실에 납득을 했다면, 자연스럽게 생기는 의문점이 있을 것이다. 바로 '어디까지' 알아야 하는 것일까. 라는 질문이다.
해답을 짚기 전에, 알아야 할 점은 IT 산업에서 일하는 기획자에게 필요한 건 '파이썬', '자바'가 아니라 '커뮤니케이션' 이라는 점이다. 즉, 'IT 산업에서 일하기 위해서는 코딩을 반드시 할 수 있어야 해!' 가 아니라 '개발자와 적당히 소통할 수 있을 만큼은 알아야 해.' 인 것이다.
또한, 기업의 리스크 관리를 위해서라도 PM은 개발 지식이 있어야 한다. 일례로 기술 스택 (각 기술 및 사용환경) 에 대한 이해도가 있는 서비스 기획자는 해당 기술의 한계를 이해하고 있기 때문에 어떠한 문제 상황이 생겼을 때 해당 상황에 맞는 솔루션을 제공해줄 수 있다. 이러한 솔루션을 제공해 줄 수 있다는 것은 시간적˙금전적 제한이 있는 환경에서 기업이 감당해야 할 리스크를 줄여줄 수 있다는 것과 다름이 없다.
2. Hi, Front-end
밀리의 서재, 랜딩페이지 역사 탐색
그래서 이번 포스팅에서는 위클리 과제로도 한창 분석하고 있는, 밀리의 서재 프론트엔드를 탐색해보고자 한다. 밀리의 서재를 택하게 된 이유로는, 밀리의 서재가 랜딩페이지에서 A/B test를 진행했던 것이 아니었나 의구심이 들었기 때문이다.
밀리의 서재를 그냥 구글에 검색하면, 위의 페이지로 이동할 수 있는 링크가 첫 상단에 뜨게 된다. 하지만 위클리 과제를 수행하기 위해 밀리의 서재를 검색하고서 여러 사이트를 타고 들어갔을 때는 아래와 같은 랜딩페이지를 발견했다.
개인적인 의견으로는 첫번째 랜딩페이지보다는 위의 두번째 랜딩페이지가 좀 더 스크롤을 하면 다양한 동적 요소가 나오기 때문에 더 좋을 것 같은데, 왜 밀리의 서재에서는 첫번째의 랜딩페이지를 선택했던 걸까?
밀리의 서재 관계자가 아니기 때문에 정확한 근거는 찾을 수 없었지만, 첫번째와 두번째의 가장 큰 차이점은 '조정석' 이라는 모델의 유무였다. 그래서 개인적으로 밀리의 서재가 첫번재 랜딩페이지로 바꾼 이유는 2021년에 조정석이라는 모델을 기용하면서 '밀리의 서재 - 조정석' 이라는 연결고리를 만들었고, TV CF를 통해 유입시킨 고객들을 랜딩페이지에서도 이탈시키지 않기 위해 조정석의 이미지를 넣은 게 아닐까 싶다. (아래의 랜딩페이지는 또 탐색을 해보니 2020년에 사용했던 랜딩페이지로 보인다.)
What is 'Front-end'
그럼 본격적으로 밀리의 서재 프론트엔드를 탐색하기 이전, 프론트엔드란 무엇이고 어떤 기술들을 사용하는지 부터 찬찬히 알아가보도록 하겠다.
먼저 프론트엔드가 무엇인지를 알기 위해서는 백엔드 역시 알아야 한다. 이 둘의 관게는 위의 빙산처럼 나타낼 수 있는데, 웹 서비스를 사용하는 유저들이 볼 수 있는 부분이 프론트엔드이고 유저들은 못 보지만 모든 기능들이 돌아가고 있는 부분이 백엔드라 할 수 있다.
즉, 사용자 웹/앱을 통해 클라이언트에 접속하고 클라이언트의 여러 기능을 조작하면서 서버에 정보를 주고 받는 요청을 보낼 때 사용자의 요청에 반응하는 부분을 '프론트엔드(Front-end)'라 부르는 것이다. 그리고 이 프론트엔드를 구성하는 기술은 크게 3가지로, HTML(Hypertext Markup Language), CSS(Cascading Style Sheets), JavaScript 가 이에 해당한다.
<웹 기초 설명> 의 비유를 좀 가져와보자면, HTML은 문서의 뼈대이고, CSS는 문서를 꾸며주는 살갗, JS는 문서를 동작하게 해주는 근육이라 할 수 있다. 그렇다면 위의 내용을 토대로 밀리의 서재 랜딩페이지가 어떤 기술스택을 사용했는지 꼼꼼히 분석해보고자 한다.
(*이때, 소스코드의 파일이 좀 더 잘 정리되어 있고, 해당 랜딩페이지를 통해 클론 프로젝트를 진행한 자료를 발견하여 기술 스택을 좀 더 명확히 정리할 수 있을 밀리의 서재 Ex-web을 분석해보고자 한다.)
3. 본격적으로 탐색하기
반응형 웹 페이지
먼저 밀리의 서재가 반응형인지, 적응형인지 알아보기 위하여 페이지의 사이즈를 줄였다가 키워보고 앱 화면 역시 어떻게 보이는 지 살펴보았다. 그 결과, 밀리의 서재는 반응형 웹으로 지원하고 있는 것을 알 수 있었다.
반응형 웹은 하나의 템플릿으로 모바일, 태블릿, 데스크탑 등 모든 기기에 대응할 수 있는 웹으로 마크업 작업을 할 때 고정된 px값이 아닌 em, rem, %처럼 백분율 값으로 작업해야 한다.
소스코드 구성
소스코드를 먼저 확인해봤을 때, company 파일 내부에 <assets>, <css>, <script> 폴더가 존재하고 실제 웹페이지 소스코드를 담고 있는 company.html이 존재하고 있었다.
<assets> 에서는 웹 페이지에서 사용할 여러 이미지 사진들이 저장되어 있었고, <css>에는 해당 웹사이트를 꾸미기 위한 css 코드, <script>에서는 JavaScript 기능 코드 파일들이 담겨져 있었다.
HTML
기본적인 element (텍스트, 링크 등) 들을 적용
HTML은 <요소이름>내용</요소이름> 과 같은 형태로 어떤 요소들로 문서를 이루고 있는 지를 나타낸다.
보통은 <head>, <body> 로 나뉘고 <body>는 또 <header>, <main>, <footer> 등의 요소로 나타내는 것으로 알고 있었는데, 밀리의 서재는 놀랍게도 <body>의 구성요소를 모두 <section>으로 구분을 하고 있었다. 그리고 <section>의 내부에서는 또 <div>로 구분하고 있는 것을 확인할 수 있었다.
좀 더 명확한 조사를 위해, 밀리의 서재에서 주로 사용되고 있는 HTML 태그에 대해 조금 학습해보았다.
˙<head> : 해당 문서에 대한 정보인 메타데이터 (metadata)의 집합을 정의함
˙<body> : 해당 문서의 콘텐츠 영역을 정의함
˙<section> : HTML 문서에 포함된 독립적인 섹션 (section)을 정의함
˙<div> : HTML 문서에서 특정 영역이나 구획을 정의함
여기에서 <section> 과 <div>의 차이점은 또 무엇일까, 하는 궁금증이 들어 찾아보니 논리적인 구분이 필요하다면 <section>을, 단순한 블럭요소가 필요하다면 <div>를 쓴다고 한다. 하지만 <section>을 모두 <div>로 대치해도 사실 상관은 없고, 단순히 각 목적에 맞게 시멘틱한 태그를 쓰고자 HTML5부터 도입된 태그들이라 한다. 즉, 논리적인 맥락을 찾기 위한 요소라 이해하면 될 것 같다.
밀리의 서재는 총 7개의 논리적 맥락을 구성하고자 했다.
이때 놀라운 점은 밀리의 서재 로고, 로그인버튼 및 구독상품을 안내할 수 있는 버튼은 어느 section에도 포함시키지 않고 <div>를 통해 구성하고 있다는 점이다. 그리고 하나하나의 섹션을 설명하기 앞서 공통적으로 floating button이 존재했는데, 이 button은 각 섹션에서 가장 후킹할 수 있는 문구로 변환되고 있었다.
<headersection>
<headersection>에서는 만일 <header>이라는 태그를 했을 때 주로 넣을 요소들로 구성되어 있었다. '당신의 소중한 일상.' 이라는 title에 '더 가치있는 것들로 채워볼까요?' 라는 subTitle 등 아래로 스크롤하는 느낌의 위 아래로 움직이는 화살표 아이콘이 포함되어 있다.
<introStart>
<introStart> 에서는 '독서와 무제한 친해지리' 라는 타이틀과 벽에 고정되어 있는 선반에서 놓여있는 책을 묘사하고자 한 이미지를 사용한 듯 하다. 그리고 이 section에서 흥미로운 지점을 발견했는데, 분명 img introStartMain lax라는 클래스로 김영하 작가의 사진이 렌더링되어야 하는데 되지 않았다는 점이다.
위의 사진에도 볼 수 있듯, 원래 김영하 작가의 사진이 보여야 하는데 빈 공백만 보이고 있다는 사실을 알 수 있다. 화면을 크게 하든, 작게 하든 똑같이 안 나오는 걸로 봐서 렌더링 중에 무언가 문제가 생긴 게 아닐까 예상해 볼 수 있다.
<intro5mBooks>
<intro5mBooks>에서는 '모두의 취향의 만족시키는' 이라는 title과 '10만 권의 전자책 중 골라 읽어요'라는 subTitle, 그리고 '어제, 오늘 그리고 미래의 베스트셀러까지! 무제한 독서를 통해 당신의 인생책을 만나보세요' 라는 description lax <div>를 대표적으로 찾을 수 있다.
그리고 보여주고 있는 10만권의 책은 src에서 하나씩 다 렌더링해온 것으로 스크롤에 따라 transform: translateY가 달라지는 걸 확인할 수 있었다.
<introGenreContents>
<introGenreContents> 에서도 title, subTitle, description을 찾을 수 있었는데, 이 section에서 눈여겨 봐야 할 점은 스크롤에 따라 왼쪽에서 오른쪽으로 이동하는 상자들이었다. lax blockContainer이라는 클래스로 하나하나의 <div> 속에 구성되어 있었는데, class에 아마 스크롤에 따라 좌측에서 우측으로 이동하는 script 구문이 짜여져 있는 것이 아닐까 생각이 들었다.
<introMillieBooks>
<introMillieBooks> 에서는 밀리의 오리지널 콘텐츠, 오디오북과 챗북을 소개하는 section이었다. 여기에서의 독특한 부분은 '들어보기' 버튼이었는데, 해당 버튼을 클릭하게 되면 실제 화면에 보여지는 배우가 읽어주는 리딩북 youtube화면으로 이동하게끔 설계가 되어 있었다.
<introOriginalPaperBooks>
<introOriginalPaperBooks> 에서는 밀리의 오리지널 북을 소개하는 section으로 맨 위에서 아래로 내려감에 따라 종이 상자의 뚜껑이 열리며 여러 콘텐츠들이 튀어나오는 것처럼 묘사를 해놓았다.
<introPrice>
<introPrice>는 밀리의 서재 랜딩페이지의 가장 마지막 section으로 밀리의 서재가 제시하는 구독권의 가격을 제시하고 있다. 이 부분에서는 '밀리의 서재를 정기구독하고' 라는 title 는 <p> (문단을 구성) 태그로, 나머지는 <div> 태그로 구성하였다. 특히, 전자책과 종이책 두개의 card를 하나의 <div> 속에 위치시켰으며 각각의 card 역시 <div>의 요소로 묶여 있었다.
CSS
element들에 sytle (색깔, 크기, 배치) 적용
CSS는 요소이름{내용} 과 같은 형태로 쓰여지며, HTML이 어떠한 모습으로 표현될 지 각 요소들의 표시방식을 정의한다. CSS를 적용하는 방식으로는 3가지로 나뉘는데, 인라인 스타일, 내부 스타일 시트, 외부 스타일 시트로 구분된다. (참고)
앞서 소스코드의 구성을 살펴보았을 때, CSS 파일이 따로 나뉘어져 있었기 때문에 밀리의 서재는 외부 스타일 시트로 구성되어 있지 않을까 생각을 해 보았고, 그 예상은 적중했다. 외부 스타일시트는 위의 그림과 같이 <head> 태그 내에 <link> 태그를 사용하여 외부 스타일 시트를 포함하면 된다.
CSS를 본격적으로 탐색해보기 위해서는 요소{내용} 또는 .{내용} 으로 각 요소가 잘 구분되어 있어야 했는데, 맨 위에 올린 사진처럼 밀리의 서재 CSS 파일은 이상하게 파일 형식이 좀 깨져있는 것 같았다. 그래서 가장 잘 확인할 수 있는 background 부분만 바꾸면서 CSS가 어떻게 동작하는 지 확인해보고자 한다.
확인해본 바와 같이 원래 #FFEB60로 살짝 레몬빛이 나던 배경색이 #FFFFFF 하얀색의 코드로 바꾸자 레몬빛이었던 모든 배경화면이 하얀색으로 바뀐 것을 확인할 수 있다. 이처럼 CSS는 link가 삽입된 html의 모든 스타일을 책임진다고 할 수 있다.
JavaScript
웹 내의 동적요소 및 상호작용 추가
JavaScript는 객체 기반의 스크립트 언어로 웹의 동작을 구현할 때 쓰이는 언어이다. 주로 <script> 요소 내부에 직접 스크립트를 작성하거나 외부 스크립트 파일의 주소를 src속성값으로 명시하면 된다.
밀리의 서재의 경우, 직접 내부에 스크립트를 작성하기도 하였고 앞서 소스코드의 구성에서도 확인했듯 script파일에 따로 저장되어 있는 것을 src로 불러오기도 하였다. 여러 동적 요소들이 있지만, 가장 확인해보기 쉬운 function firstFreeStart() 부분을 살펴보기로 하였다.
해당 기능은 예상하건데 밀리의 서재 1개월 무료구독을 시작하기 위한 function으로 sesstionStorage를 열어 채널에 가입하기 위한 정보를 일시적으로 저장하고, location.href 기능을 사용하여 로그인 화면으로 이동시켜주는 것으로 보인다. setItem이 키-값 쌍을 일시적으로 보관하는 문구라고 하는데, 'ga_feature'이 키이고, 'joinchannel'을 값이라 할 수 있다.
즉, 클릭을 했을 때 로그인 화면으로 넘겨주는 것 역시 JS가 해주고 로그인이 될 지 말 지의 그 과정 역시 JS가 하는 것이다. (HTML, CSS는 로그인 화면만 구성한다.)
좀 더 IT적 지식이 있었다면, 로그인 버튼에서 어떻게 JS를 넣었는 지 역시 분석을 해보고 싶었지만 script 파일이 한 줄로만 구성되는 형식으로 클린코드가 아니었기 때문에 아쉽지만 여기에서 포스팅을 마무리하려 한다.
번외로, functioni FirstFreeStart() 위의 function은 유저 트래킹을 위한 코드라고 한다. 밀리의 서재 랜딩페이지를 분석했을 때 Google Analytics를 위한 코드 역시 존재했으므로 아마 랜딩페이지에서의 유저들의 행태를 분석하기 위해 기입한 코드일 것 같다.
4. 탐색을 마무리하며
HTML과 CSS는 비교적 쉬운 코드라 쉽게 분석을 할 수 있었지만 JS같은 경우에는 특정 요소를 보여주는 것이 아니라 function으로 작성되는 코드이기 때문에 분석하는데 좀 힘들었다.
또한, 이번 학습에서는 리액트와 같은 프레임워크도 학습을 했었는데 해당 프레임워크가 쓰여졌는 지에 대한 분석은 하지 못해서 아쉽다. 그래도 이후에 이 과제를 하게 될 누군가를 위해 최대한 내가 아는 지식 내에서 자세히 설명하고자 노력하였다. (용량은 거의 초과되었지만!)
이후에는 JS도, Node.js도, React도 모두 잘 찾는 PM이 되고자 관련 서적을 많이 읽어두어야겠다:)
참고자료.
