[회고] 우테코 5주차 - 달리기를 말할 때 내가 하고 싶은 이야기

Marco·2022년 3월 13일

우아한테크코스

목록 보기

4/11

달리기를 말할 때 내가 하고 싶은 이야기

이번 주에는 운동을 딱 한 번 했다. 페어프로그래밍 주간에는 도저히 다른 활동에 시간을 내기 어려운 것 같다. 그래도 계속 이럴 수는 없으니까, 페어프로그래밍 주간에도 틈틈히 개념도 탄탄히 다지고 운동도 짬을 내서 조금 더 많이 해야겠다.

무라카미 하루키의 에세이 달리기를 말할 때 내가 하고 싶은 이야기에서 다음과 같은 구절이 있는데, 소설가든 프로그래머든 같은 맥락에서 공감할 수 있는 내용이라고 생각된다. 프로그래머는 많은 시간을 스스로 생각하고 소설가처럼 구조를 설계해나가는데 시간을 쏟는 것 같은데, 프로그래머도 소설가처럼 불건전한 영혼(?)에 가깝다고 볼 수 있다. 따라서 건전한 육체가 그 누구보다 필요하다.

참으로 불건전한 것을 다루기 위해서는 사람들은 되도록 건강하지 않으면 안 된다. 그것이 나의 행동 목표이다. 다시 말하면 불건전한 영혼은 또 건전한 육체를 필요로 하는 까닭이다. 역설적으로 들릴지도 모른다. 그러나 그것은 직업적인 소설가가 된 이래 지금까지, 내가 몸소 절실하게 느껴온 것이다. 건강한 것과 건강하지 못한 것은 결코 대극 점에 위치하고 있는 것이 아니다. 대립하고 있는 것도 아니다. 건강한 것과 건강하지 못한 것들은 서로를 보완하고, 어떤 경우에는 서로를 자연스럽게 감싸 안을 수 있는 것이다. 때때로 건전함을 지향하는 사람들은 건전한 것만을 생각하고, 불건전을 지향하는 사람들은 불건전한 것만을 생각한다. 그러나 그와 같은 편향은 인생을 진정으로 내실 있는 것으로 만들기는 어렵다.
< 달리기를 말할 때 내가 하고 싶은 이야기 - 무라카미 하루키>

하루키가 소설 쓰기의 많은 것을 매일 아침 길 위를 달리면서 배운 것처럼, 나도 프로그래밍 혹은 삶의 많은 것을 길 위에서 달리면서 배울 수 있지 않을까 기대한다.

나 자신에 대해 말한다면, 나는 소설 쓰기의 많은 것을 매일 아침 길 위를 달리면서 배워왔다.
< 달리기를 말할 때 내가 하고 싶은 이야기 - 무라카미 하루키>

새 미션 시작

이번 주 화요일에 [나만의 유튜브 강의실] 구현 미션이 시작되었다. 위니와 페어가 되어 화요일부터 금요일까지 페어프로그래밍을 진행하였다. 페어프로그래밍을 할 때마다 느끼는 거지만, 다들 배울 점이 많고 열정적이다! 위니도 나랑 비슷하게 프로그래밍을 배우기 시작한지 6개월 정도 밖에 되지 않았다고 한다. 우리는 이번 미션에서 요구하는 기능인 REST Api, 무한 스크롤, 스켈레톤 UI, 비동기 프로그래밍을 그 전에 해본 적이 없어서 미션에 대한 중압감을 많이 느꼈다.

설계

이번에는 MVC를 탈피해서 새로운 방식의 설계를 도전해보려는 마음도 살짝 먹었으나, 페어와 나는 설계에 힘을 많이 쏟다가는 기한 내 기능 구현도 제대로 못하겠다는 결론에 이르렀고 MVC 패턴 하에 기능 구현 및 에러 핸들링에 초점을 맞추기로 했다.

fetch, async/await

미션을 시작하고 youtube API key를 받아서 데이터를 fetch하여 콘솔에 찍었을 때 신기했다. 시작이 반이라고, 일단 데이터를 가져왔으니 데이터를 지지고 볶으면서 화면에 표시하면 되지 않겠는가? 자신감과 안도감이 생겼다.

무한스크롤과 IntersectionObserver

무한 스크롤은 IntersectionObserver을 사용하여 구현하였다. 처음에는 이를 Controller에 뒀다가 다음날 자고 일어나보니 당연히 View에 들어가야 한다는 생각이 들어서 리팩토링을 하였다. 그리고 IntersectionObserver가 scroll의 bottom을 감지하는 순간 customEvent를 dispatch하도록 하여 controller에서 해당 customEvent를 수신하여 다음 데이터를 fetch하고 render하는 메소드를 controller가 명령하도록 만들었다.

iframe srcdoc

fetch하여 render한 클립 영상은 iframe으로 구현하였는데, 유튜브에서 퍼가기 금지 설정되어 있는 영상은 iframe에 재생도 되지 않고 썸네일도 표시되지 않아 사용성이 떨어져 보였다. 그런데 youtubeAPI를 fetch할 때 퍼가기 가능한 동영상만 필터링하여 가져오는 방법은 아무리 찾아도 나오지 않아서 다른 해결책을 강구해야 했다. 그 결과, 썸네일 url도 데이터로 받고 있으니, iframe의 영상 영역을 각각 해당 썸네일 이미지로 직접 덮고 영상 링크를 걸어두면 어떤가 하는 의견을 주고 받았다. 그리고 우리가 덮은 썸네일 이미지를 유저가 클릭하면 iframe 내부에 영상이 자동재생되도록 하는 것이다. 이러한 아이디어를 해결할 수 있는 방법으로 iframe의 attribue 중 srcdoc이 있음을 찾게 되었고, 여러 시행착오 끝에 정상적으로 구현하게 되었다. 그런데 아쉬운 점은, 유튜브가 외부에서 자동재생 설정을 하려면 반드시 음소거 설정을 함께 하도록 하는 정책이 있어서, 구현 프로젝트에서 우리가 넣은 썸네일을 클릭하면 영상은 자동재생되나 소리는 나오지 않고 있다. 결국 사용성 개선에 대한 문제로 돌아오는데, 프론트엔드는 이러한 고민이 많이 필요한 것 같다.

localStorage

이 외에도 저장 버튼을 눌렀을 때, localStorage에 해당 영상 데이터를 저장하고, 다시 새로고침해서 동일한 영상을 찾게 되었을 때 localStorage에서 데이터를 가져와 해당 영상에 저장 버튼을 '저장됨' 버튼으로 변경하는 것도 쉽지 않았으나, 페어와 함께 결국 다 구현해냈을 때 큰 희열감이 들었다.

webpack

다 구현하고 webpack으로 build하고 deploy하는 데도 쉽지 않았다. 이번에는 이전 미션과 달리 프로젝트에 이미지 파일도 추가되었고, 비동기인 async/await도 포함되어 있었기 때문이었다.

이미지 파일을 webpack으로 build하기 위해서는 file-loader 패키지를 설치하고, webpack.config.js의 rules에 다음과 같은 설정을 추가해야 했다.

  module: {
    rules: [
      {
        test: /\.(png|jpe?g|gif)$/i,
          use: [
            {
              loader: 'file-loader',
              options: {
                pubilcPath: './',
                name: '[name].[ext]',
              },
            },
          ],
      },
    ]
  }

그리고 비동기 async/await 관련 웹팩 설정은 regeneratorRuntime is not defined 오류가 발생함으로써 인지하게 됐는데, 이를 해결하기 위해서는 코드가 컴파일될 때 async/await 문법을 해석하는데 필요한 regeratorRuntime을 추가해야 함을 알게 됐다.

따라서 @babel/plugin-transform-runtime 패키지를 설치하였고 webpack.config.js의 rules의 babel-loader 부분에 '@babel/plugin-transform-runtime plugin 설정을 추가함으로써 webpack build 및 deploy에 성공하였다.

  module: {
    rules: [
      {
        test: /\.js$/,
        exclude: /node_modules/,
        use: [
          {
            loader: 'babel-loader',
            options: {
              presets: ['@babel/preset-env'],
              plugins: ['@babel/plugin-transform-runtime'],
            },
          },
        ],
      },
    ]
  }

해당 미션 데모페이지는 다음과 같다.
마르코의 유튜브 강의실 데모페이지

코드리뷰 피드백

이번 미션에서 배정받은 리뷰어님은 Vallista님이셨다. 꼼꼼하게 내 코드를 살펴봐주셨고 내가 놓치고 있던 부분들에 대해 잘 짚어주셔서 많은 것을 배우게 되었다. 모든 질문에 대해 상세히 답변해주셨는데, 이를 정리한 내용은 다음과 같다.

테스트코드

로직의 정상 작동 결과는 하나뿐이지만, 오작동하는 케이스는 수십가지가 넘는다.
- 따라서 유저가 어떤 행동을 했을 때 오작동을 하면 유저에게 그에 대한 피드백이 필요하다. 이러한 오작동 케이스에 대한 수많은 문제를 정상적으로 사용할 수 있도록 유도하는 코드가 필요하다.
테스트코드는 오작동 문제 상황에 대한 코드 보완 여부를 협업하는 사람들과 공유하는 성격도 갖고 있다.
- 따라서 에러 상황에 대한 테스트코드를 많이 고민하고 작성수록, 이 테스트코드를 코드단위로 이행시켜서 효율성을 증대시킬 수 있다.
결론: 유저 관점에서 유저가 일으킬 수 있는 수많은 오작동 케이스를 커버할 수 있는 테스트코드를 작성하자. 그리고 테스트코드는 에러 상황 커버리지를 코드단위로 이행시키며 다양한 사람들에게 선한 영향력을 줄 수 있음을 염두하고 정성껏 작성하자!

설계

프로젝트에 적합한 설계가 무엇일지 고민하자.
작은 단위의 프로젝트의 경우 MVC는 오버스펙일 수도 있다.
MVC에서 벗어나서 새로운 시도를 해보는 것도 좋다.

함수 분리 기준

로직이 길어지는 경우(코드 10줄 초과)
두 번 이상 재사용될 수 있는 경우
그리고 함수가 길다고 느껴진다면
- 함수 분리 전에, 함수명이 잘못되었을 수도 있으니 함수명과 그 기능을 다시 잘 살펴보자.
- (MVC에서 controller는 model과 view가 만나는 전쟁터라서 비대해지기 쉽다 😿 )

크롬익스텐션 기능 추가

코딩을 처음 배울 때 만들었던 todo list 프로젝트를 활용하여, 작년 12월에 북마크 스크랩 크롬 익스텐션을 만들었다.
이름은 footmarker이고 크롬 웹스토어에 등록도 되어 있긴 하다.
이 토이 프로젝트를 만들었던 이유는, 하루에도 수 십개의 웹사이트 자료를 보면서 북마크를 하는데, 브라우저에 내장된 기본 북마크 기능에는 검색기능도 없고 등록 날짜도 기재되지 않으며 북마크의 이름으로 웹사이트의 타이틀만 가져온다는 것에 대한 아쉬움 때문이었다. 해당 페이지에서 내가 북마크하고 싶은 부분은 특정 섹션이며 섹션을 설명하는 해당 타이틀 태그(h1,h2,h3,h4)의 텍스트를 가져오고, 타이틀 책갈피 링크를 가져왔으면 좋겠다는 생각을 했다.

이러한 아이디어에서 시험 삼아 만들어 본 익스텐션이었고, 몇 개월간 잊고 있었는데, 시지프의 멋진 사이드 프로젝트를 보고 나의 작고 귀여운 프로젝트들도 아껴줘야겠다는 생각을 했다. 그래서 어젯밤에 한 가지 기능을 추가했는데, 그것은 바로 날짜별로 모은 북마크를 앵커 태그와 함께 클립보드에 복사하는 기능이다.

이렇게 Copy 버튼을 누르면, 해당 html을 복사하고