(Week 7) 또 한 번의 뒷북, 늦게나마 회고 쓰기 _ 코드스테이츠 PMB 11기| 회고

 4, 5주 차에 이어 또 한 번 뒤쳐져버린 주간 회고 타임. 굳이 굳이 핑계를 대자면 페어님이 마지막 리뷰를 늦게 해 주셔서 그렇지만, 정말 핑계일 뿐이다. 이전에도 마지막 리뷰는 종종 늦게 받는 경우가 있었기에...😂 내가 게을러서라는 게 사실이자 팩트이다. (잠시나마 페어님 탓해서 미안해요)

 역시 한 번 미루는 게 어렵지, 미루면 끝도 없다는 것을 새삼 깨닫는다. 9주 차에 쓰는 7주 차의 회고란^^,,,, 내용이 기억이나 나려나...? 아직 본격적으로 시작하지 않아서 그런지, 무지하다는 생각밖에 들지 않는다. 호달달 두려워🥶

 7주 차에 배운 내용을 키워드로 정리하자면 #앱과 #웹이다. 직접적인 개발까지는 아니지만, Front end 및 개발에 사용되는 API에 대한 개념도 학습하고, 앱이 어떤 유형으로 나누어지는지 등을 배웠다. 그래도 HTML, CSS, Javascript에 대해서도 보다 자세히 알게 되고, 이를 바탕으로 웹 화면의 Front를 읽는 방법도 습득한 느낌...? 하지만 단기간에 습득하는 것은.. 역시 무리무리...😅 여전히 모르겠는 것이 개발이고 데이터다😂

 

페어 리뷰 후기

 정말 거지 같았던 6주 차의 페어^^ 진짜 탈주 충동이 들 정도로 화나는 한 주였는데, 7주 차는 다행히.... 행복한 한 주를 보냈다. 성실한 페어님을 만나 (이전처럼) 많은 것을 배울 수 있어서 너무 다행이었다😭

 그리고 나랑 다른 스타일의 글을 작성하시는 부분이라 또 다른 점의 배움이 있었다. 나는 줄줄줄 글을 쓰는 TMT 스타일이라면, 7주의 페어님은 핵심만 간결하게 쓰는 깔끔한 스타일이셨다. 페어님의 과제를 보며 "설명이 많지 않아도 한 번에 이해할 수 있게 글을 작성할 수 있구나"라는 걸 배웠고, 내 글에도 조금이나마 적용해보고자 노력했던 한 주였다.

 물론 결과는.. 크게 달라지지 않았다. TMT 기질을 단번에 극복하는 것은 어려웠고, 만약 그렇다 해도 부자연스러웠지 않을까. 사람이 그렇게 휙휙 바뀌는 존재도 아니고, 나만의 스타일도 있으니? 너무 페어님을 따라 하려고 하기보다, 나의 단점을 개선하는 방향으로 생각하니 조금은 마음이 편해졌다.

 그리고 이번 페어님도 나를.. 춤추게 해... 물론 개선점도 짚어 주셨지만! 대체적으로 훈훈한 분위기의 피드백이 이어졌다. (혹시 이전 회고인 나의 극대노를 보셔서 그런가;;) 덕분에 자존감 회복도 하고, 자기반성도 하며 또 한 번 성장하는 한 주를 보냈다.

 

이번 주의 페어님

참선

 

---

Day 1

<텀블벅(tumblbug)>으로 Front end 이해하기 (Web) _코드스테이츠 PMB 11기| W7D1

"body - css" 부분에 대해 좀 더 명확한 설명이 있으면 좋을 것 같다. picture 컨테이너 자체가 CSS로 적용된 것인지, 해당 컨테이너 내부에 CSS 코드가 따로 적용되었다는 것인지 오해의 소지가 있다. 

 페어님이 제시해 주신 위의 의문을 해결하기 위해 다시 코드 창을 들여다봤다. 오랜만에 다시 봐서 그런지 더욱 낯설게 느껴지고, 코드를 찾는 작업도 벅차게 느껴진 듯하다. 

 페어님의 질문에 답을 하자면, picture라는 컨테이너 그 자체가 CSS 코드로 구성된 것 같다. 배너에 대한 picture 컨테이너를 봤을 때 이미지 크기와 첨부 파일 등이 나와있었기 때문이다. 뒷부분에 텍스트가 있어 html과 혼재되어 있나?라는 의문도 들었지만, 별도의 안내 문구가 아닌 주석으로 파악되는 요소였다. 

 한편으로는 "이미지를 넣는 것을 CSS라고 볼 수 있나?"라는 생각도 들었다. 하지만 현재 나의 배움 수준에서는... 이 정도가 최선(?)이었달까. 자세히 공부를 해 보면 정확한 답을 내릴 수 있겠지만 지금 수준에서는 추측만 할 뿐... 하나의 컨테이너 안에 여러 언어의 코드(html, css, javascript)가 혼재할 수 있는지, 아니면 별도의 컨테이너로 구성해야 하는지 등 추가적인 의문이 드는, 페어님의 예리한 질문이었다. 

 

"body-js"의 첫 문장에서 react-view를 반응형 페이지의 근거로 제시한 이유가 궁금하다. 반응형 페이지의 경우 css의 미디어 쿼리를 사용하는 것으로 알고 있어 더 자세한 설명이 필요하다.

 이 부분을 보고 머리를 한 대 얻어맞은 것 같았다. 나는 자세히 찾아보지도 않고, react-view를 번역하면 "반응형 보기"이기 때문에, '아, 코드도 직관적으로 작성했구나'라고 생각했다. 

 페어님의 말씀대로, 반응형 웹의 경우 head 부분에 CSS로 미디어 쿼리로 작성한다. 확인 결과 텀블벅도 마찬가지였으며, 코드 창에도 viewport라는 코드가 사용된 것을 확인할 수 있었다. 

 그렇다면 내가 잘못 생각했던 react-view는 무엇일까. 정확한 코드 기능을 확인하진 못했지만, 대체로 "사용자와의 인터렉션"을 위한 기능인 듯했다. 텀블벅에서 사용된 코드는 주로 스크롤과 관련된 기능으로, 사용자가 웹의 상하를 확인할 수 있도록 하는 기능이었다. 

 새삼스레 이런 기능도 javascript가 사용되는구나- 싶었고, 이름만 보고 잘못 이해한 내 자신을 다시 한번 반성하는 시간이었다.😓 (이런 것 때문에 페어 리뷰를 하는구나!!)

 

+ 추가적인 덧!

 페어님께서 감사하게도 함께 찾아봐주신(?) 나의 의문에 대한 답:) 해당 과제에서 슬라이드 형태로 작동하는 배너의 javascript에 대해 의문을 가졌었다. 코드 창을 뒤졌지만 결국 찾지 못했던.. 자동 슬라이드 배너 코드😂 마침 페어님도 궁금해하셔서 찾아보시고, 나에게도 그 해답을 공유해 주셨다.

 페어님의 조사 결과, swiper라는 jQuery 라이브러리가 적용된 것으로 추정된다. jQuery란 html에서 사용하는 자바스크립트 라이브러리로, 손쉽게 해당 기능을 구현할 수 있다고 한다. 아래 링크는 페어님이 첨부해 주신 슬라이드 배너 제작 코드에 관련된 글이다.

[js] Swiper 슬라이더 사용법 (왕초보를 위한 홈페이지 대문에 슬라이드 넣기)

 나 또한 페어님이 첨부해 주신 블로그 글을 보며 좀 더 깊은 이해를 할 수 있었다. 한편으로는 화살표를 눌러야 무빙이 일어나는 슬라이더만 해당하는 것인지, 아니면 자동 슬라이드도 해당되는지 등 추가적인 의문도 발생했다. 해당 부분은 자율 학습으로 좀 더 찾아보기로 하자! 

 다시 한번 나의 가벼운 의문을 함께 고민하고, 해결법을 찾아주신 페어님께 감사인사를 드린다:)

 

---

Day 2

모바일 App 유형 파헤치기 (feat. 텀블벅) #하이브리드 앱 _ 코드스테이츠 PMB 11기| W7D2

1. 모바일 웹 부분에서 대부분의 경우 반응형 웹으로 제작된다고 설명하셨지만, 보여주신 쿠팡의 이미지나 URL 앞에 m을 붙여 모바일 버전을 따로 제작하는 것은 적응형 웹이라 생각한다.
2. 모바일 웹의 특성 중 '실행 속도가 느리다'는 표현에 대한 특정 조건이나 기준이 있다면, 이해하는데 도움이 될 것 같다.

  역시나 날카로웠던 페어님의 지적! 대략적인 내용을 정리하다 보니 해당 부분을 명확히 짚고 넘어가지 않은 부분이😂 충분히 오해를 불러일으킬만한 부분이라 생각했다. 페어님의 말씀을 빌어 다시 한번 해당 부분을 정리해 보고자 한다.

모바일 웹

 모바일 웹의 경우 요약본에서 간단하게 언급한 것처럼, 단순하게 "모바일 기기에서 보는 PC 웹"이라 생각하면 된다. 대체로 모바일 환경에 맞춰 자동으로 폰트, 텍스트 크기, 콘텐츠, 아이콘 등을 조절해 보여주는 반응형 웹으로 제작되는 경우가 대부분이며, 웹만을 구축하면 자동으로 모바일에서도 이용할 수 있다.

 이와 달리 이미 PC 웹이 있지만, 이를 모바일에 더욱 핏(fit)하게 만들기 위해서 m.naver.com, m.coupang.com처럼 별도의 모바일 전용 웹을 구축하는 경우도 있다. 이러한 경우도 "모바일 웹"에 해당되며, 이 또한 여러 디스플레이의 크기에 맞춰 자동으로 배율을 조정한다. (대부분 기존 웹 URL 앞에 'm.'을 붙이는 형태)

✅ 중간 정리

• 웹은 어떤 기기에서 작동하느냐에 따라 PC웹과 모바일 웹으로 분류할 수 있다.
• 이와는 별개의 기준으로, "적응형 웹"과 "반응형 웹"으로도 구분한다. 적응형 웹의 경우 디바이스 별 레이아웃을 별개로 제작해야 하며, 반응형 웹의 경우 하나의 레이아웃(템플릿)으로 PC와 웹을 모두 사용할 수 있다는 특징이 있다.

 

모바일 웹의 경우 웹 기반의 형태이기 때문에 별도의 어플 설치가 불필요하며, 웹과 모바일에 동일한 서비스를 제공할 수 있다는 특징이 있다. 따라서 비교적 업데이트가 쉽고, App에 비해 구현 난이도가 낮다는 장점이 있다. 하지만 PC 웹과 다른 도메인을 사용해야 하며, 업데이트 또한 별도로 진행해야 한다는 한계가 존재한다. 또한 브라우저가 필수적이며 실행 속도가 느리다는 단점도 있다. 

 이때 말하는 실행 속도는, 네이티브 앱과 비교한 기준이다. 네이티브 앱과 달리 모바일 웹의 경우 브라우저를 통해 서버에 접속해 메뉴를 가져오고, 그 메뉴에 해당하는 기능을 수행하기 위해 다시 서버에 접속해서 응답을 받는 과정이 필요하기 때문이다. 따라서 모바일 웹은 상대적으로 실행 속도가 느리다는 단점이 있다.

💡 PC 웹과 모바일 웹의 차이는? 

 모바일 웹에 대한 내용을 배우고, 이런 질문이 떠올랐다. 어차피 PC웹을 모바일에서 비슷하게 볼 수 있는데 굳이 모바일 웹을 구현하는 이유는 무엇일까?

 개발자 지인에게 질문한 결과 둘의 관계에 대해 다음과 같은 답변을 줬다.

나이키 운동화(PC 웹)와 나이키 운동화 여아용(모바일 웹)의 관계

 이 답변을 듣고 단번에 이해했다. 나이키 운동화와 여아용이라 할 지라도 나이키 운동화라는 사실은 변함이 없다. 또 다른 예시를 들자면, 둘 다 인터넷인 점은 동일하지만, 즐겨찾기로 들어가는 것과 앱 스토어에서 설치가 필요하다는 것이다. 이처럼 PC 웹에 비해 더 작은 화면으로 구현될 수밖에 없는 모바일 환경을 고려하여 이에 최적화된 웹을 비교적 쉽게 만든 것이다.

 

+ 추가적인 덧!

 나의 과제를 보고 생각해 보신 바를 공유해 주신 페어님👍 정말 소중해 소중해:) 

 나는 과제를 통해 개념들을 정리하며, "네이티브 앱의 경우 리소스가 많이 필요하기에, 대규모 기업에서 주로 사용하는 형태"라고 언급했다. 하지만 이에 대한 페어님의 생각은 조금 다른 듯하다. 기업의 규모 이전에, 서비스의 형태와 목적이 우선적으로 고려되어야 하지 않을까?라는 생각이 드셨다고 한다. 대규모 기업이라도 굳이 네이티브 앱을 사용할 필요가 없을 수도 있고, 작은 기업이라도 반드시 네이티브 앱으로 구현해야 하는 서비스가 있기 때문이다.

 물론! 페어님의 말씀이 맞다. 나 또한 적극적으로 동의하는 바이고, 당연히 '서비스'가 우선적으로 고려해야 한다. 뭔가 변명을 하는 기분이지만...! 내가 언급했던 "네이티브 앱의 경우 대규모 기업에서 주로 사용한다"는 말의 의미는, 그만큼 많은 리소스가 요구되기 때문이라는 의미였다. 작은 회사들의 경우 상대적으로 리소스가 적기 때문에, 네이티브 앱을 구현하기 위해 많은 부담이 있을 것이다. 원하는 서비스 방향이 무조건 네이티브 앱 형태를 가져야 하는 경우가 아니라면, 이를 고집할 이유가 없다는 느낌이랄까?

 다시 한번 정리하자면, 앱의 형태를 결정하는 데에 있어서는 서비스를 최우선으로 고려해야 한다. 다만 네이티브 앱을 구현하는 데에 있어서는 비교적 많은 리소스가 요구되기 때문에, 신중하게 결정할 필요가 있다. 서비스 방향 및 구성, 주어진 리소스 등을 고려하여 앱 형태를 결정해야 한다.

 

---

Day 3

Open API 플랫폼 & 비전공자가 API를 마주하는 방법_코드스테이츠 PMB 11기| W7D3

 Day 3의 과제에서는 감사하게도 별다른 개선점을 언급해 주시지 않았다. 다만 페어님이 남겨주신 아쉬움이 있어 이에 대해 생각해 보고자 한다.

Open API의 한계를 언급해주신 부분에서 한계를 먼저 언급하고 이점을 소개했으면 이점을 더욱 강조할 수 있지 않을까 싶다. 물론 한계를 기술하는 대목이었지만, 이러한 불편함이 있음에도 불구하고 '기능과 데이터를 손쉽게 사용할 수 있다' 그래서 open API를 사용할 이유가 충분하다! 또한 위의 불편함 때문에 규모가 커지면 자체 API를 개발하기도 한다.라는 식으로 연결했어도 좋을 것 같다.

 역시 깔끔하게 글 쓰는 분이라 그런가. 글의 구성에 대한 부분을 언급해 주셔서 좋았다. 내가 과제에서 한계를 언급한 것은, 전문적인 개발자가 아니며, open API를 선택하기 전에 어떤 장/단점, 한계점이 있는지를 먼저 봐야 한다는 생각에서였다. (물론 내 글을 보고 어떤 의사결정이 일어나지는 않겠지만!) open API를 사용해 기능을 구현했는데, 추후 어려움이 있다면? 예상하지 못한 일이 발생한다면? 단순한 취미 생활이 아니라, 업무와 연결되는 부분이기 때문에 이러한 위험 요소에 대해 먼저 인지해야 한다고 생각했기 때문이다.

 하지만 페어님의 말씀도 일리가 있다. 굳이 한계를 먼저 언급할 필요는 없을 것이다. 이점을 먼저 언급한 후 "다만 이러한 한계도 있다"를 덧붙여도 나쁘지 않을 것이다. 이와 연결해 (페어님의 말씀대로) 한계가 있음에도 불구하고 이점의 영향 때문에 open API를 많이 사용한다-는 식의 기술 방식이 더욱 긍정적으로 보일 것 같기도 하다.

 이번 코멘트를 통해 "역시 글을 깔끔하게 잘 쓰는 분은 다르군..."이라는 생각을 다시 한번 하게 된 시간이었다😁👏

 

---

Day 4

다시보는 <디즈니 플러스(Disney+)>의 Flow_코드스테이츠 PMB 11기| W7D4

  Day 4의 과제는 6주 차 Day 1과 이어지는 과제로, 이전의 과제를 개선하는 데에 중점이 맞춰져 있다. 내용이 보충된 부분도, 아예 삭제된 부분도 있었기에, 약간의 차이가 있다는 점을 밝히고 시작한다.

기존 과제에서 언급해주신 것처럼 OTT를 사용하는 목적은 '영상 감상'이기에 이 부분에 중점을 두고 다뤄주셨으면 어땠을까 하는 아쉬움이 남는다.

 페어님의 코멘트에 공감하며, 나도 Day 4의 과제를 진행하면서 많이 고민했던 부분이다. 영화 감상까지 모두 고민해야 할까? 아니면 로그인 프로세스에 집중해야 할까? 그 결과 나는 후자를 택했다. 사실 할 수야 있었겠지만, 이 또한 나의 게으름 때문일까...^^ 당시에는 "하나라도 잘해보자!"라는 생각에서 "로그인 프로세스"에 집중했다.

(좌) W6D1, App 접속 ~ 작품 재생까지의 flow / (우) W7D4, App 접속 ~ 메인홈 도달까지의 flow

 좌측 이미지에서 <작품 선택> 이전까지의 과정을 보다 자세히 고민해서 우측의 flow chart 이미지로 구현했다. W7D4 과제를 시작할 때는 "뭐 수정할 게 있을까?"싶었지만, 동기님들과 Zoom에서 함께 고민하며 이에 대한 답을 찾았다.

 나와 같은 고민을 가진 동기님들이 있었기에, 서로의 과제에 대해 가감 없는 코멘트를 진행하고, 어떤 점이 추가되면 좋을지, 보다 집중하면 좋을 부분 등에 대해 조언해 준 동기님들이 있었기에 W7D4 과제의 가닥을 잡을 수 있었다. 이 자리를 빌려, 조언을 해 준 파프리카, 오은, oda 동기님께 감사 인사를 전한다!

 작품 선택~재생까지의 과정이 누락된 것에 대해 아쉬움을 표해주신 페어님께도, 섬세하고 디테일한 피드백에 대한 감사를 표합니다🙇‍♀!!!

 

 UI에 대해 더 이야기해주었으면 좋았을 거 같다. 디즈니 플러스, 넷플릭스, 왓챠를 모두 사용하는 입장에서 3개의 OTT 서비스의 UI는 비슷하지만, 확실히 다르게 느껴진다. 

3사 모두 콘텐츠를 취향, 최신작 등으로 분류하여 좌우 스크롤로 보여주는 것은 많은 콘텐츠를 페이지 이동 없이 편리하게 보여주기 위한 OTT 서비스의 기본적인 UI인 것으로 보입니다. 다만 디즈니 플러스의 UI는 사용자들이 본인들의 서비스를 왜 이용하는지에 대한 자신감을 내비치는 인상처럼 보여요. 상단의 메인 카테고리에서 디즈니, 픽사, 마블, 스타워즈와 같이 두터운 팬층을 보유한 콘텐츠들을 내세워 자신들의 강점을 확실히 어필하고 있습니다. 기존 OTT 서비스들과는 다르게 디즈니 플러스의 경우 콘텐츠 제작자에서 공급자로 확장했기 때문에 가능하지 않았을까 합니다. 현재 시청 중인 목록 또한 디즈니 플러스의 경우 한 페이지에 하나의 썸네일을 보여주어 콘텐츠를 더욱 강조한 느낌이 듭니다.

 아주 예리하면서도 좋은 지적이었다! 나도 비슷한 얘기를 스터디에서 나눠본 적이 있다. 비슷하면서도 약간씩은 다른 OTT의 메인 홈을 통해, 그들이 어떤 것을 강조하고 싶은지, 어떤 부분에 있어서 차별점을 가지는지 등에 대한 의견을 나눠본 기억이 난다.

 이 또한 변명이겠지만😂 제시된 과제 내용이 그에 초점이 맞춰지지 않았기 때문에 해당 부분을 언급하지 않았다. 적어도 내가 이해한 바로는 "UI-클라이언트-서버-DB"의 관계성을 중심으로, 서로 어떤 인터렉션이 일어나는지, 어떤 요청과 응답이 오가는지 등에 대해 생각해 보는 과제인 것 같았다. 

 따라서 페어님의 아쉬움에 충분히 공감하지만, 해당 과제의 범위에는 속하지 않는다고 생각했기에 누락되었다. 다음에 기회가 된다면, 하나의 분야에 대한 여러 프로덕트의 UI도 비교해 보는 시간을 가져봐야겠다는 생각이 들었다. 

 

---

거지 같은 Week 6을 보내고 만난 이번 주 페어님은, 나에게 많은 교훈을 주셨다. 물론 기대감이 예전 같지는 않았다는 것은 부정할 수 없는 사실이다. 하지만 이러한 점을 제외하고 생각해도, 이번 주의 페어님은 내게 많은 교훈을 주셨다.

 먼저 계속 언급했지만, 나와는 정반대의 글 스타일을 가지신 분이었다. 이제까지 만났던 페어님들 중 가장 깔끔하고 간결하게 글을 쓰시는 분이었는데, 핵심은 빠지지 않았다. 필요한 설명이 모두 들어가 있었으며, 유기적으로 연결되기까지 했다. 진짜 노올라웠던 페어님...👍👍👍

 두 번째는 나의 귀찮음과 얕은 지식을 간파당한 것이다. 내 지식은 여기까지니까, 가볍게 배웠으니까 더 이상은 몰라-라고 치부했던 부분을, 같은 수업을 들은 페어님은 더 많이 찾아보시고 공부하셨다. 그러고 그 결과를 내게 공유해 주시기까지...🤭 진짜 감사하면서도 한편으로는 많이 부끄러웠다. 나는 부족한 점을 알면서도 그냥 모른 채 했구나. 수업을 핑계로 외면했구나... 약 3주가 지나간 시점에서 회고를 쓰며 다시 한번 스스로를 반성했다ㅠ!!!

---

 바로 앞서 반성한 것과 연결되듯, 이번 회고는 역대급으로 매우 늦어졌다. 페어님이 아직 피드백을 안 주셨으니 나중에 해야지, 수업 내용과 데일리 과제를 해야 하니 조금 미뤄야지, 팀 프로젝트 전에 쉬는 시간을 가져야지 등... 별의별 이유로 미루고 미루다 여기까지 왔다. 역시 뭐든 한 번이 어렵지, 더 미루는 것은 어렵지 않다. 죄책감 또한 점점 더 가벼워졌다. 

 비록 밀렸던 Week 8에 대한 회고와, 이번 주였던 Week 9의 회고라는 새로운 짐이 추가되었지만....🤣🤣🤣 그래도 이번 반성을 계기로 얼른 쳐내야(?)겠다. 더는 미루지 말자!

 Week 7의 회고를 마무리하며, 나에게 많은 깨달음을 주셨던 페어님. 그리고 멘탈케어 및 과제에 대한 코멘트를 주신 파프리카, 오은, oda 동기님께도 감사인사를 전하며! Week 7도 끝! 

fin.