[주저리] 입사 8개월 차

katanazero·2021년 5월 19일
2

diary

목록 보기
1/3
post-thumbnail

매일을 기록한다는 것은 어렵지만, 가끔은 이렇게 돌아보는 시간을 가지고자 합니다. 의견 이나 경험담 댓글은 언제나 환영합니다.🥰


현재 재직중인 회사에는 2020.09.21 첫 출근 하였다.(면접 및 과제전형 진행)
나는 첫번째 프론트엔드 개발자로 입사를 하였다. 어느덧 입사 8개월 차!

  • 프론트엔드 기술스택을 정의하는 작업을 진행했다. 입사 당시에 vue 3(3.0.0)가 릴리즈 되었다. SEO 및 서드파티 라이브러리들에 대한 지원이 미비하여 후에 진행을 하기로 결정을 하였고 이전에는 vue 2 기준으로 진행하기로 하였다.

  • 사내에 외주로 진행하던 프로젝트 결과물을 검토해달라는 요청을 받아 진행을 하였다. react.js + next.js 로 작업된 프로젝트 였는데 외주분이 작업하다가 도망(연락두절;)😓을 갔다고 하였다. 프로젝트를 살펴보니 작업도 엉성하고 막코딩이 되어있었다. 이것을 살려서 쓰기에는 공수가 더 든다는 결론을 내리고 vue.js 로 다시 작업을 하겠다고 보고를 하고 내부에서 진행을 하는것으로 결정하였다. 그렇게 작업을 하던 중 기획을 갈아 엎는다고 하여 해당 프로젝트는 중단이 되었고 후에 다시 논의하기로 이야기가 마무리되었다.

  • 팀원이 늘어나면서 어떻게 협업을 해야 하는지에 대한 의견을 나누는 시간이 있었다. Slack, Trello, Notion, Git flow 방식 및 도구를 활용하는 거로 결정이 되었다. Forking workflow 방식은 아니었으며 Git flow workflow 방식으로 진행을 하기로 하였다. (master 와 develop 브랜치는 항상 유지가 되고, 필요에 의해 브랜치를 전략적으로 생성하여 작업합니다) 후에, 좀 더 적합한 방법이 있거나 효율적인 방법이 있다면 다시 조율하기로 하였다.

  • 사내에 고도몰5로 구축된 쇼핑몰 사이트를 개발관련해서 검토해달라는 요청을 받아 검토를 진행하였다. 고도몰 관련한 추가 개발(log, 커스텀마이징, 관리자 성능이슈 등)에 대해서는 개발이 어렵다라는 의견으로 회신을 하였다. 실제 개발팀 내에서 PHP 를 다뤘으나 주 업무로 맡아서 진행할 개발자는 존재하지 않았다. 고도몰5를 살펴보니 일반 PHP 웹으로 개발하는 것과는 별개로 고도몰 구조에 맞게 학습을 해야하고 로컬 개발환경을 구축하는 것도 불가능하고 동작에 메인(코어) 부분은 건들 수 없기 때문이었다.

  • 회사 홈페이지 관련하여 개선을 해달라고 하여 작업을 하였다. 오랜만에 jQuery 를 만지니까 옛날 생각이 새록새록 났다. 작업을 마무리하고, 욕심이 나서 vue.js 로 재개발을 하여 담당자에게 역제안을 하였다. 이유는 홈페이지가 반응형으로 구축 되어있는데, 반응형이라고는 하나 UI 일그러지는거도 심하고 누군가 우리 홈페이지를 들어온다면 좋은 인상을 주기 어렵다라는 생각이 들었기 때문이다. 하지만 나의 작업물은 반려되었다. 이러한 문제들을 인지하고 있으나 개선 하려는 의지가 없었던것으로 생각한다.



  • 인증(oAuth 2.0 based) 관련한 admin 프로젝트를 진행하였다.(비밀키, scope, 클라이언트 ID 관리 및 발급된 access token 확인 등) 이거는 Quasar 프레임워크(vue.js 기반)를 사용하여 진행했다. 이전에는 Vuetify 를 사용했었지만, 다양하게 경험해보고 싶기도 하고 문서 및 사용법이 친절하게 정리가 되어있어서 선택하였다. 그리고 계속 업데이트에 대한 지원을 해주고있어서 안정적으로 사용이 가능하다는 믿음도 선택을 하는데 이유가 되었었다.(SPA, PWA, SSR 등 다양한 빌드옵션도 매력이라고 생각을 한다. UI 컴포넌트를 살펴보면 마테리얼 디자인을 따르고 있는게 확인이 된다.)

oAuth 2.0 에 대해서 조금은 살펴볼수 있는 프로젝트여서 좋았다. 프론트엔드 입장에서는 토큰을 잘 받아서 쿠키 또는 로컬스토리지에 보관을 하다 API 호출 시 커스텀 헤더에 실어서 보내주면 끝이기는 하지만 좋은 개발자가 되고자 한다면 한번 내용을 살펴보는게 좋다고 생각을 한다.

간단하게 정리를 하자면, 사용자(resource owner = user)가 자원(resource server)에 서비스를 필요로하는데 인증 서버(authorization server) 에 인증 과정을 거쳐 발급된 access token 을 가지고 자원 요청 시 전달하여 서비스를 제공을 받는거다. 인증과정은 크게 4가지로 분류 되고 있다.(Authorization Code Grant / Implicit Grant / Password Grant / Client Credentials Grant)
access token 을 발급받는다고 모든 자원에 접근이 가능하지 않으며 scope 를 통해 제한이 가능하다. 추가로 보안상 resource server 에서는 access token 유효성 검사(validate access token)를 위해 인증 서버에 요청하는 로직을 추가한다.


  • CSS Architecture 정의 하였다. 작성법은 BEM(Block-Element-Modifier) 방식을 기준으로 정의를 하였다.
    BEM 을 선택한 이유는, HTML 을 작성하다보면 블록단위로 구성이 된다는걸 알 수가 있는데 BEM 도 이를 따라가서 구조적으로 이점이 있다고 생각했으며 작성 시 클래스 선택자만을 보고 마크업 구조와 역할을 파악하기 좋았다. 그리고 CSS Pre-Processor 로 SCSS 를 사용했기 때문에 부모 참조자(&) 연산자와 사용하면 축약해서 작성이 가능하여 궁합이 좋았다.(&__nav {})
    이외에는 파일 구조라던가, 파일 네이밍 컨벤션 등에 대한 내용을 추가로 같이 정의를 하였다. 커뮤니티에 피드백을 받고자 올렸는데, 다행스럽게(?😅) 다들 좋아요 및 공유하기만 해주셔서 무사히 넘어갔다.

  • 11월 초 부터 A 프로젝트가 갑자기 발생하여 개발팀은 1월 초까지 정신없이 프로젝트를 진행하였다. 1월 중순에 첫 웨비나 라이브를 진행하는데 문제가 발생 하였다. 실제 접속자가 50명도 안되는데 병목현상이 발생하여 사이트가 502 error 가 발생해서 정상적으로 이용이 불가능하였다. 인프라는 Azure 를 사용하고 있었는데 첫번째 원인은 낮은 DB 사양으로 커넥션이 넘쳐서 데드락이 발생하였다. 백엔드 파트에서 이 부분은 DB 사양 업그레이드로 해결을 하였다.
    그럼에도 불구하고 사이트가 불안정한 모습을 보였다. 원인을 찾고자 백엔드 파트는 부하 테스트(stress test)를 진행하였으며, 클라이언트에서 통신 시 병목현상이 걸리는걸 발견하였다. 실제로 프론트엔드 이슈인지를 검토하기 위해서 nuxt.js 프로젝트를 새로 생성 후 axios 를 통해서 API 를 단 2번만 호출하는 샘플을 작성하여 배포 후 테스트를 진행하였다. 샘플 프로젝트에서도 여전히 병목이 걸리면서 불안정한 모습을 보여서 프론트엔드 이슈는 아닌걸로 결론이 났다. 인프라 이슈로 좁혀졌는데 Azure App Service 내에 로깅이라던가 확인이 어려워 백엔드 파트에서는 인프라 사양을 올리는걸로 해결을 하였다.
    이 프로젝트를 진행하면서 Azure Media Player 를 다루었는데 커스텀이 쉽지 않다는걸 느꼈다. 스트리밍 서비스를 Azure Media Service 를 사용하므로 해당 스트리밍 재생에 최적화된 플레이어 SDK 로 Azure Media Player 를 강제로 사용을 해야만 했었다. UI 커스텀을 했으나, 잔버그들이 많아서 담당자와 협의 후 기본 UI 스킨으로 롤백시켰다.
    HTML5 video element 기반이기 때문에 HTMLMediaElement 에서 등록가능한 이벤트들은 그대로 사용이 가능했다. 왜 인프런이나 패캠에서도 기본 video 태그 또는 vimeo 같은곳에서 제공해주는 기본 플레이어를 사용하는지 알거같았다.

  • 11월 ~ 1월 까지 정신없이 보내고, 바로 A 프로젝트 모바일 웹을 작업하였다. 반응형으로 작성하기에는 모바일 퍼스트로 디자인이 되어있지 않았기에 @nuxtjs/device 모듈을 활용하여 agent 검사하여 m 도메인을 태워서 해결을 하였다.
    @nuxtjs/device 모듈을 추가하여, 미들웨어에서 디바이스 타입에 따라 redirect() 분기처리를 해주었다.
export default function (context) {
  const { app, store, route, params, query, env, isDev, isHMR, redirect, error, $config, next } = context;

  // Server-side
  if (process.server) {
    const { req, res, beforeNuxtRender } = context;
  }

  // Client-side
  if (process.client) {
    const { from, nuxtState } = context;
  }

  if (context.$device.isMobileOrTablet) {
    if (!route.fullPath.includes('/m')) {
      if (store.getters.getIsMobileMenu) store.dispatch('isMobileMenuCloseAction');
      redirect(`/m${route.fullPath}`);
    }
  }
}

주의할 점은 redirect 시, 해당 미들웨어가 다시 동작을 하기 때문에 기저조건을 잘 처리해줘야 한다.
한달 정도 일정을 잡았는데, 생각보다 일찍 마무리가 되어서 이후에는 다른 프로젝트 admin 을 작업하기 시작하였다.
물론 중간중간 이슈들이 발생하여 처리를 해주었다.(쿠키 도메인 이슈, Azure Media Player 모바일 웹 터치 이슈, UI 이슈 등)


  • 위 프로젝트를 마무리하고, 이번에는 B 프로젝트 admin 작업을 진행하였다.
    Quasar 프레임워크(vue.js 기반)를 사용하여 개발을 진행하였다. Quasar 프레임워크(v2)가 beta 버전을 통해 먼저 vue.js 3버전을 지원하기 시작하였다. vue.js 3 문서번역도 참여했었고 사용해보고 싶어서 근질근질 하던참에 beta release note 를 살펴보았다. (https://github.com/quasarframework/quasar/issues/7836)
    back office 라 당연히 SSR 은 필요가 없으며, 2월 10일에는 SSR 모드가 출시 준비가 되었다는 내용 이외에는 심각한 이슈가 없는 것으로 판단하여 beta 임에도 사용하기로 결정하였다. 일부 Quasar 컴포넌트 이벤트명이라던가 속성들이 변경된 거 이외에는 사용하는 데 크게 불편함을 느낄 수가 없었으며, 기존에 사용하던 Quasar v1 처럼 정상동작을 해주니 Quasar 개발자들에게 정말 감사함까지 들었다.(Q1 2021 에 v2 안정화 버전을 정식 출시한다니 너무 기대가 된다)
    잠깐 vue.js 3 이야기를 간단하게 하자면, Composition API 가 추가가 되었으며, v-model multiple bind 가 가능하며 Reactivity API(reactive, ref), root element 가 기존에는 오직 1개만 가능했으나 3 버전 부터는 그러한 제한이 없다.

확실히 vue.js 3버전은 react hooks 같다는 생각을 많이했으며, mixin 보다는 코드흐름이나 유지보수 측면에서도 확실히 괜찮다는 생각을 많이하였다.(mixin 은 엄격한 네이밍규칙을 따르지 않으면 메서드명 또는 상태명이 중복이 될수도 있으며, 특정 컴포넌트에서 2개이상의 mixin 을 사용하는 경우 로직의 흐름을 따라가기 어렵다.

그리고 Options API(data, computed, methods 등) 도 직관적이지만 결국에는 컴포넌트에 작성된 코드가 커질경우 로직에 대한 코드가 여기저기로 흩어져서 흐름을 따라가기 어렵다.


  • B 프로젝트 admin 작업을 마무리하고, 이번에는 C 프로젝트 admin 재개발을 진행하였다.(현재 진행중)
    베트남 외주개발을 맡겨 개발된 react.js 로 만들어진 프로젝트다. 이거는 새로 입사한 신입 프론트엔드 친구와 협의하여 react.js + material ui 로 진행하기로 하였다. 상태관리 라이브러리는 recoil 을 사용하기로 했다.
    create-react-app 프로젝트 생성 후, 구조 및 규칙 등을 논의하고 작업을 진행했다. 중간중간 리팩토링 및 주석도 꼼꼼하게 작성을 하였다. 네이밍 컨벤션은 handle[Subject]eventName = handleCloseClick 로 정했다. api 메서드 컨벤션은 find / create / update / delete / request 로 정했다.
    성능 이슈가 있었는데 React.memo() 를 활용하여 최적화 해줬다. 상태가 너무 많아 관리하기 어려워서 useReducer() 훅을 사용하여 관리하는 형태로 코드를 변경하기도 하였다. 이 부분은 커스텀 훅(useCommonStates.js)을 작성하여 다른 컴포넌트에서도 사용가능하게 해두었다.
    react 는 프로젝트를 진행하면서, 아무 생각없이 작업을 하면 성능 이슈를 쉽게 마주치겠구나 생각을 하였다.
export default (api, oAuthApi, axios) => ({
  /**
   * GET /terms
   * @param {string} queryString
   * @returns {Promise<*>}
   */
  async findTermList(queryString) {
    const URL = `/terms`;
    return api.get(`${URL}?${queryString}`);
  },


  /**
   * PUT /terms/{targetUuid}
   * @param {string} targetUuid
   * @param {string} type
   * @param {string} lang
   * @param {string} name
   * @param {string} content
   * @param {string} description
   * @returns {Promise<void|AxiosResponse<any>|IDBRequest<IDBValidKey>>}
   */
  async updateTermById(targetUuid, { type, lang, name, content, description }) {
    const URL = `/terms`;
    const requestBody = {
      type,
      lang,
      name,
      content,
      description,
    };
    return api.put(`${URL}/${targetUuid}`, requestBody);
  },

  /**
   * POST /terms
   * @param {string} type
   * @param {string} lang
   * @param {string} name
   * @param {string} content
   * @param {string} description
   * @returns {Promise<*>}
   */
  async createTerm({ type, lang, name, content, description }) {
    const URL = `/terms`;
    const requestBody = {
      type,
      lang,
      name,
      content,
      description,
    };
    return api.post(URL, requestBody);
  },

  // .. 이하 생략
});

Azure 에서 nuxt.js 가 병목현상이 일어나는 부분은 아직도 의아하다. 이전 직장에서는 AWS EC2 로 구성해서 pm2 로 올리고 했을때는 그런 현상이 전혀 일어나지 않았다. Azure 내에서 뭔가 문제가 있는건 분명한데 검색을 해도 원인이 나오지 않으니 우리만 겪는 트러블인가 생각이 들었다.

A 프로젝트 중간에 조금 여유가 생겨 PWA 를 적용하여, push notification 을 구현하면 사용자에게 좋은 경험을 주겠구나해서 시도를 하였다. 하지만 마케팅 동의 등에 정책적인 부분과 로그인한 사용자에게만 보내려면 백엔드 개발자들에게 협력을 요청해야해서 코드들을 롤백시키고 지워버렸다. 아쉽기는 하다.(FCM 을 활용하여 구현하였다.)
삽질기 : https://velog.io/@katanazero86/PWA-%EB%A5%BC-%ED%99%9C%EC%9A%A9%ED%95%9C-push-notification-%EA%B5%AC%ED%98%84-%ED%9B%84%EA%B8%B0feat.-FCM

작성을 하면서, 내용이 길어지다 보니 이만 줄이도록 하겠다.

profile
developer life started : 2016.06.07 ~ 흔한 Front-end 개발자

2개의 댓글

comment-user-thumbnail
2021년 6월 17일

개발공부를 시작한지 얼마 안된 코린이입니다, 모르는부분 검색하다 타고 들어오게 되었는데,
실제 현업에 계신 분이 어떤 일을 하시는지 살짝이나마 들여다 볼수 있어서,
늘 궁금하던 부분이 조금 해소도 되고, 어떤 부분들을 준비하고 채워가야 할지 그려보게 되었습니다
다 이해하진 못했어도^^; 생생하고 소중한 공유 정말 감사합니다! 🙏

1개의 답글