2주 동안 개발 지식 배운 기획자, 얼만큼 달라졌을까?
[코드스테이츠 PMB 10기] 개발 지식 점검하기
외계어 같던 개발자들의 언어가
외국어로 느껴지기 시작했달까...?
1. 아, 무슨 말을 하는 지는 알겠다!
6주차와 7주차, 총 2주에 걸쳐 개발 지식을 학습했다. 프론트엔드부터 백엔드까지, 데이터부터 기술 스택까지, 개발자들과 소통하기 위해 그들의 언어를 배우는 시간이었다. 감상부터 밝히자면, 개발자들이 지금 무슨 말을 하고 있는 지는 아는 기획자가 되었다. 물론, 개발자들이 개발을 배우기 위해 투자한 시간과 노력을 단숨에 따라잡을 수는 없다. 그래서 아직까지 '해석' 이상의 '독해'는 제대로 이루어지지 못하고 있다.
개발자들이라고 코딩이 쉬운 건 아니다그래도 이렇게 머릿속에 개발 지식의 대략적인 틀을 집어넣고 나니, 앞으로 개발자들의 말을 해석하느라 끙끙대는 일은 줄어들 것 같다. 새로운 외국어를 배우는 것이나 다름 없다는 생각이 든다. 현재로서는 단어를 암기하고, 문장 구조를 익히고, 형식을 외우는 단계인 듯하다. 이 지식을 응용하여 나만의 문장을 구성하고 더 나아가 자유롭게 의사소통하기 위해서는 조금 더 노력해야 할 것 같다.
2. 카카오톡 이모티콘 다시 분석하기
약 3주 전, 나는 위 포스팅에서 카카오톡 이모티콘의 플로우 차트를 그려보면서 6주차와 7주차의 포문을 열었다. 혼자서 생활코딩, 개발자 지인, 기타 자료들을 통해 어영부영 익힌 개발 지식만으로 풀어낸 포스팅이었다.
간단해도 너무 간단했던 당시 그려본 플로우 차트(ㅋㅋ)지금 다시 살펴보니 어설픈 부분이 한두 개가 아니지만, 그럼에도 나름대로 내가 아는 선에서 최선을 다하고자 노력한 모습도 보인다...ㅋㅋㅋ 그래서 이번 포스팅에서는 카카오톡 이모티콘을 여태까지 배운 내용을 바탕으로 다시 한 번 분석해보려고 한다. 그 과정에서 내가 새롭게 배우고 익힌 점을 점검해볼 수 있을 것 같다.
카카오 이모티콘은
GIF 파일이 아녜요
출처=https://www.kakaocorp.com/page/detail/9609지난 W6D1 과제의 주제였던 카카오 이모티콘은 알고 보면 매우 거대한 프로덕트이다. 2021년 11월 29일자 보도 자료에 다르면 카카오 이모티콘은 2011년에 출시되어 2021년을 기점으로 출시 10주년을 맞았고, 누적 개별 이모티콘 수 300,000개, 수익 시장 규모 7,000억 원에 달한다.
수많은 현직자들이 GIF 파일의 크기를 줄여야 하는 상황에 부딪히고 있다(...)카카오 이모티콘은 결국 사람들 간의 소통을 도와주는 움직이는 이미지이다. 이때의 '움직이는 이미지'는 통상적으로 무거운 데이터에 속한다. 우리가 일상에서 가장 쉽게 접할 수 있는 '움직이는 이미지'는 GIF 파일일 것이다. GIF 파일은 똑같은 화질의 MP4 등 동영상 파일과 비교했을 때 10배 정도 용량이 크다. 다양한 압축이 적용되는 동영상 파일에 비하여 압축이 부족하기 때문이다.
이러한 맥락을 고려했을 때, 나는 카카오 이모티콘은 움직이는 이미지이기는 하지만, 우리가 흔히 아는 GIF 파일과는 다른 형식일 것이라고 판단했다. 카카오톡과 같은 채팅 메신저는 속도와 안정성이 생명이기 때문이다. 특히 "카톡 하루 멈추면 우리나라가 돌아갈 수 있나?"라는 질문이 과장처럼 느껴지지 않을 만큼 전 국민의 채팅 메신저인 카카오톡에서 오가는 약 2,200억 건(2021년 기준)의 이모티콘이 모두 GIF 파일이라면 서버가 진작에 터졌어야 할 것이다.
아직 공부가 부족하여 카카오톡 이모티콘의 형식이나 원리를 정확히 알 수는 없지만, 실제로 다른 서비스들에서는 서버에서 GIF를 MP4 등으로 변환하여 저장, 제공하는 방법을 쓰고 있다고 한다. 화질, 용량, 최적화, CPU사용량 등에서 다양한 단점을 안고 있는 GIF 파일이지만 워낙 나에게 익숙한 형식이다 보니 막연하게 "움직이는 이미지는 다 GIF 아니야?"라고 단정지어 버렸던 것 같다.
크롬 개발자 도구로
카카오 이모티콘샵
뜯어보기
6주차와 7주차에는 웹과 앱에 대한 기초적인 지식을 익혔다. 그런데 아직까지 나는 앱보다는 웹에 대해 설명하는 것이 좀 더 편했고, 그래서 위 링크의 카카오 이모티콘샵 웹을 분석해보기로 했다. 과제 가이드라인 대로 UI, 클라이언트, 서버, DB로 나누어 살펴보고자 한다.
UI
User Interface의 줄임말로, 사용자와 제품/서비스의 사이에 위치하여 상호작용을 위해 존재하고 있는 시각적인 디자인(화면)이다. 좋은 UI는 심리학과 생리학에 기반하여 만들어지며, 사용자는 필요로 하는 요소를 쉽게 찾아 사용하고, 기획자는 그 요소로부터 명확하게 의도한 결과를 쉽게 얻어 낼 수 있어야 한다.
카카오 이모티콘샵의 홈 화면에서 사용자가 마주하게 되는 UI는 위와 같다. 최상단에는 보라색 배너로 카카오 이모티콘 플러스(정기구독 모델)의 가입을 유도하고, 왼쪽 상단의 팝업으로는 할인 쿠폰 지급을 알리고 있다. 스크롤을 내려도 이 두 가지 요소는 고정되어 있다. 따라서 기획자의 마케팅적 의도를 위와 같은 요소를 통해 드러내고자 했고, 사용자의 시선이 주로 머무는 상단에 이를 배치하여 클릭을 유도했다고 볼 수 있다.
뿐만 아니라 페이지 영역을 신규 이모티콘/인기 이모티콘/스타일로 구분하여 사용자가 원하는 이모티콘을 쉽게 찾을 수 있도록 했다. 스타일 영역의 경우, #귀여운/#큰이모티콘/#카카오공식과 같은 태그별로 이모티콘들을 분류하여 보여줌으로써 사용자의 탐색 및 구매를 도왔다.
클라이언트
카카오 이모티콘샵의 화면 영역을 크롬 개발자 도구로 살펴보니 7주차에서 클래스101 크리에이터 지원 페이지를 분석(참고)하면서 학습한 HTML, CSS, JS 코드를 발견할 수 있었다. HTML은 문서의 뼈대, CSS는 문서를 꾸며주는 살갗이고, JS 는 문서를 동작하게해주는 근육이라고 해당 포스팅에서 정리한 바 있다.
저번에 클래스101으로도 확인해보았듯이, 카카오 이모티콘샵의 살갗을 제거(!)해본다면 어떤 모습일지 궁금했다. 그래서 크롬 개발자 도구에서 <style> 태그를 Delete element 처리해보았다.
그랬더니 위 사진처럼 뼈대와 근육만 남은 모습(!)을 확인할 수 있었다. 같은 페이지를 보고 있는데도 CSS의 디자인적 요소를 제거하고 보니 많은 것이 달라졌다. 위 사진의 오른쪽 이미지들처럼, CSS가 없었을 때는 스타일 요소가 많을 경우에는 페이지 로딩이 느릴 수 밖에 없었고 스타일 작성 역시 제약점이 많아 모든 것을 다 표현할 수는 없었다고 한다.
HTML 페이지가 로드 될 때 CSS가 작동하는 방식. 출처=https://velog.io/@anhesu11/T.I.L-1st-Week-HTML-CSS왜냐하면 HTML 로딩 과 HTML 파싱 과정에서 모든 작업을 진행하였기 때문이다. 그런데 작성된 문서의 표현을 기술하기 위해 쓰이는 스타일시트 언어, CSS의 등장으로 웹에서 스타일을 지정하기 더더욱 편리해진 것이다.
서버
그렇다면 크롬 개발자 도구에서 서버 영역을 살펴보려면 어떻게 해야 될까? 여러 포스팅을 참고한 결과, Network 패널을 확인하면 된다고 한다.
ysh1394님의 벨로그 포스팅(참고)에 따르면 Network 패널이란 웹페이지를 로드하기 시작했을 때부터 웹페이지 안에 포함되어있는 이미지, 리소스 등을 서버를 통해서 각각의 이미지, 리소스를 가져오는데 얼마나 많은 시간이 걸리는지, 어떤 순서로 리소스를 가져오는지, 어떤 요청과 응답이 오고가는지 등, 웹페이지와 서버 사이에서의 데이터의 흐름을 분석하고, 문제 발생 시 해결책을 찾을 수 있는 곳이라고 한다.
비록 개발에 대한 지식이 부족하여 위와 같은 카카오 이모티콘샵의 Network 패널을 이해할 수는 없었지만(...) 서버 개발자들이 이 패널을 확인하면서 문제 해결 방법을 고민한다는 점은 알 수 있었다.
DB
웹 동작 방식. 출처=https://brunch.co.kr/@swimjiy/2카카오 이모티콘샵의 DB에는 어떤 데이터가 들어 있을까? 카카오 이모티콘샵이라는 웹페이지는 위와 같은 과정을 거쳐 동작한다. 그런데 위 이미지에서 Web Client, Web Server, DB까지는 익숙하게 마주친 용어인데, WAS는 낯설게 느껴져서 무슨 뜻인지 찾아보았다.
WAS는 웹 애플리케이션 서버의 줄임말로, 사용자 컴퓨터나 장치에 웹 애플리케이션을 수행해주는 미들웨어를 의미한다. 쉽게 말해 클라이언트로부터 메시지를 받으면 서버는 요청에 필요한 페이지의 로직이나 DB의 연동을 위해서 WAS에 이들의 처리를 요청한다. 그러면 WAS는 요청에 따라 페이지 처리를 담당하고 DB에서 데이터 정보를 받아온다. WAS는 이와 같은 과정으로 DB와 연동하여 데이터를 처리하고, 생성한 파일을 서버에게 반환한다.
웹 동작 방식을 클라이언트 > 서버 > DB > 서버 > 클라이언트로 비교적 간단하게 학습했다 보니 그 중간중간에 추가적인 과정이 있을 수 있음을 간과했던 것 같다. 이번 포스팅을 작성하면서 나름대로 다 안다고 생각했던 웹 동작 방식에 대한 지식을 추가로 학습할 수 있어 유익했다. 역시 개발 공부는 해도해도 끝이 없다는 말이 맞는 것 같다...!
참고자료
