상품 상세 React 전환기안녕하세요, 29CM 프론트엔드 개발자 권형주입니다.이번 포스팅에서는 기존 29CM 의 주요 도메인 중 하나인 상품 상세 페이지를Angular 에서 React 로 전환을 결정하게 된 이유와, 전환 과정에서 어려웠던 점과 이를 해결해나간 과정들을 소개하고자 합니다.React!!!!? React 전환을 결정하게 된 계기저희 팀에서 Angular 에서 React 로 전환을 결정하게 된 가장 큰 계기는 Angular 개발자 채용의 어려움입니다.비지니스는 점점 커져가는데 채용이 쉽지 않아 서비스 규모와 비교해 상대적으로 부족한 3명으로 구성된 프론트엔드팀으로 개발을 진행하고 있었고 더해서 목적 조직으로의 전환도 앞두고 있었죠.또한 아래와 같은 문제들을 겪고 있기도 했었습니다.한 번 배포하는 데에 평균 10~15분 정도 걸리는 이슈Docker 를 사용하고 있지만 layer caching 을 활용할 수 없고 image cache 를 사용하지 않는 환경이라 매번 빌드/배포를 반복해야 하는 상황에러 로그를 남기지 않고 있어 배포 후 장애 디버깅의 어려움마지막으로는 관리되고 있지 않는 어마어마한 레거시의 무덤들이 산재하고 있어 더 이상의 방목은 힘들다는 판단이 있었습니다.레거시의 무덤 ?이러한 이유들을 기반으로 팀 내에서 방향성에 대한 논의가 있었고 최종적으로는 React 전환을 결정하게 되었습니다.? React 전환 방향React 전환에 앞서 하나의 고려사항이 있었습니다. 저희 백엔드 팀에서는 MSA 로 전환하는 과정에 있었는데요, 저희 프론트엔드팀도 Micro Frontend 를 장기적으로는 지향하고자 하는 마음이 있어 바로는 진행하지 못하더라도 우선 SPoF 부터 제거하는 것을 중점에 두고 있는 상황이었습니다.SPoF 를 제거하기 위해 각각의 워크스페이스별 도메인을 분리하고 서버를 각각 띄우도록 구성했으며, 하나의 서버에 장애가 발생하더라도 다른워크스페이스 서버에는 접근이 가능하도록 진행하고자 했었습니다..만허허.. 이런.. 진행 과정에서 몇 가지 문제가 발생했습니다.앱 내에서 상품 상세 페이지 같은 경우 별도의 전용 웹뷰를 통해 사용하도록 개발이 되어 있었습니다만, 이번 작업을 통해 페이지 주소가 바뀌게 됨으로써 추가적으로 대응이 필요한 상황이었습니다.대응을 하지 않으면 React 상품 상세 페이지를 띄웠을 때 위 처럼 웹뷰가 무한으로 push 되는 현상이 발생했기에신규 도메인에 대한 대응은 필수불가결했습니다.이에,앱의 하위 버전에서는 기존 Angular 페이지로 연결을 시키고앱의 신규 버전 부터는 React 페이지로 연결을 시키기로 했습니다.모바일 팀과 논의 후 앱의 신규 버전부터 신규 도메인이 대응되어 있는지를 User-Agent 의 특정 값을 통해 판단하도록 협의했고, 이 값이 포함된 경우에는 “기존 Angular 페이지와 React 페이지 둘 다 정상 작동되도록 패치된 버전이다”는 것을 알려주는 용도로 사용했습니다.그리고 React 페이지에 문제가 발생할 때는 이 값을 기준으로 기존 Angular 페이지로 롤백

사진출처 : https://24ways.org/2017/levelling-up-for-junior-developers/Intro안녕하세요! 비브로스 웹프론트엔드팀에 합류하게 된 조영동입니다.약 7주동안 신입 개발자 온보딩 프로세스를 거치며 느꼈던 경험과 제 생각을 나눌 수 있는 기회가 되서 영광입니다!그럼 본격적으로 제가 경험한 7주간의 온보딩 과정을 소개 하도록 하겠습니다.?1. 7주동안 경험한 것신입 부스터에게 무려 10단계의 온보딩 프로세스를 제공해서 온전히 기술에 대한 적응 기간을 주는 점이 좋았습니다. 아무래도 개발자로써는 첫 입사이기 때문에 모르는 부분이 많아서 걱정이 됬습니다.하지만 온보딩 과정에서 한 챕터마다 해야할 부분이 분명했기 때문에 과정을 진행하면서 완료표시를 누를 때마다 성취감을 느낄 수 있어서 좋았고 실무가 어떻게 진행될지 확인할 수 있었습니다.온보딩 과정 중 특히 앵귤러에 대한 걱정이 이만저만이 아니였습니다.앵귤러는 처음이고 생소한데 그동안 개발 공부를 하면서 프론트엔드 삼대장 중 가장 러닝커브가 높은 프레임워크라고 많이 들었던 터라 낮선 프레임워크를 접하는 불안감이 있었습니다.?프레임워크만의 강점 앵귤러가 모든 부분을 지원하는 프레임워크라서 초기에 어렵다는 말이 많지만 유지보수할 때 리액트보다 오히려 쉽다는 의견이 많습니다. 오히려 자유도가 없는 프레임워크기 때문에 프레임워크 특성상 코드 작성에 있어서 정형화된 패턴이 있기 때문에 유지보수에 특화되어 있는 장점이 있는 것 같습니다. 이 부분이 사실일지는 실무를 경험해보면서 제가 직접 확인해봐야겠습니다.?친절한 공식 문서 아직은 어렵긴하지만 앵귤러 공식 가이드가 초심자가 쉽게 따라할 수 있도록 작성되어 있어서 생각보다 초기에 받아들이기 쉽다고 느꼈습니다. 물론 이후에 배워야할게 많다는 점을 체감할 수 있었지만 공식문서가 어떤 문서보다 보기 편하게 작성되서 잘 읽혔고 라이브 예제도 첨부되어 있어서 어떻게 동작하는지 실행을 해보며 쉽게 이해할 수 있었습니다.진짜 배울게 많은 러닝커브? 초반에는 앵귤러 가이드에서 튜토리얼을 진행하면서 객체지향 방식을 채택해서 사용한다는점, constructor에서 의존성을 주입할 수 있는 점, 템플릿과 css가 분리된 형태라는 점을 제외하고 리액트와 비슷한 점이 많다고 생각을 했습니다. 근데 이후에 RxJS, Form, Router, Pipe, directive, operator등 앵귤러에서 새롭게 배워야되는 부분들이 계속 추가 되는 것을 확인하면서 프레임워크답게 정말 소소한 것까지 많은 것을 제공하기 때문에 시작 지점에 배울게 진짜 많다는 것을 느낄 수 있었습니다.최신 자료 부족 앵귤러는 자료가 부족하다는 말을 SPA 삼대장과 비교하면서 많이 들었습니다. 그래도 앵귤러가 가장 오래된 프레임워크로 알고 있었기 때문에 리액트보다 상대적으로 자료가 적다는 의미가 아닐까 추측을 했었는데 생각보다 더 자료가 부족했습니다. 앵귤러 공식 가이드북은 초심자도 쉽게 접근할 수 있도록 작성되었지만 오류가 발생했을 때 검색을 하면 다른 프레임워크는 최

안녕하세요. 비브로스 웹프론트엔드팀 신입 개발자 박서영입니다. ? 저는 현재 입사 5주차로 온보딩 프로그램을 진행 중입니다. 입사하기 전 새로운 환경(새로운 팀, 새로운 사람들, 새로운 기술 스택과 업무툴 등 )에 어떻게 적응해야 할 지 걱정이 많았었습니다. 하지만 제 걱정과 달리, 팀 협업 시스템과 기술 스택에 잘 녹아들 수 있었는데 바로 온보딩 프로그램 덕분이었다고 생각합니다.저희 팀은 어떤 방식으로 온보딩을 진행하고 있는지 경험을 공유하고, 좋았던 점과 아쉬웠던 점에 대해서 함께 이야기 나눠보고자 합니다.웹프론트엔드 팀의 서류합격자라면 과제 명세서와 함께 팀 소개 문서를 받게 됩니다. 이 문서에는 현재 웹프론트엔드팀이 어떤 프로젝트를 진행하고 있고, 어떤 기술 스택을 사용하고 있으며 어떤 워크툴을 활용해서 일을 하게 되는지, 팀 개발문화 전반에 대해 상세하게 작성되어있습니다. 많은 신입분들이 회사에 기대하는 점 중 하나가 ‘개발문화`와 이를 지탱하는 협업 시스템일 텐데요. 저는 이 문서를 읽고 나서, ‘꼭 회사에 합격에서 개발문화를 체험해보고 싶다’라고 다짐했던 기억이 납니다. 실제 입사를 하고 나서도 협업 시스템에 굉장한 만족감을 느꼈습니다.매일 오전, 스크럼을 통해 전날 한 일과 오늘 할 일 등 전체적인 업무 진행 상황을 공유합니다. 다른 팀원들이 어떤 작업을 하고 있고, 어떤 기술적 문제를 해결하고 있는지 들을 수 있어서 좋았습니다. 또 스크럼을 통해 스스로 업무 생산성을 체크하고 이를 기반으로 테스크 수행 기간을 점차 정확하게 산정할 수 있어서 도움이 많이 되었습니다.2021 프로그래머스 데브 설문조사에 따르면, ‘현재 개발팀에 도입된 것이 무엇이 있느냐?’는 질문에 코드리뷰가 1위를, ‘현재 팀에 가장 도입하고 싶은 것이 무엇이냐’라는 질문에 코드리뷰가 3위를 차지했습니다. 결과에서 살펴볼 수 있듯이 현재 많은 개발팀들이 코드리뷰 시스템을 도입하거나 도입을 계획하고 있습니다. 이쯤되면 도대체 왜 모두가 코드리뷰를 하는 것일까 궁금해지는데요. 제가 온보딩 과정을 통해 느낀 코드리뷰의 장점은 ‘상향 평준화’라고 생각합니다.이미지 출처한 달 동안 제가 받은 코드리뷰를 세어보니 총 134개였습니다. 변수 네이밍부터 성능 최적화까지 세밀하면서도 강도 높은 코드리뷰를 경험할 수 있었습니다. 사실 면접 때 함수형 프로그래밍을 지향한다고 말했지만, 외부 상태를 변경하는 함수를 짜거나 인자로 전달된 데이터를 직접 변경하는 등 다소 부끄러운 순간들도 있었습니다. 그동안 ‘작동만 하면 되는 코드’를 짰다면 이제는 ‘준수하게 작동하는’ 코드를 짜야 하는 주니어 개발자가 되었음을 실감했던 것 같습니다.받았던 코드리뷰 중 하나를 소개하자면,이미지 출처두 배열의 차집합을 구하는 상황에서const difference = array1.filter(a⇒array2.includes(a));를 조건 반사하듯이 썼다가 시간복잡도에 대한 피드백을 받았었습니다. 업무시간 동안 해결하지 못해서, 퇴근하고 예제코드를 만들어가 알고리즘에 관심 있는 주니어분들과 함께 토

FE-Weekly-Pick에서는 최근에 팀 내에서 진행했던 스터디 내용을 정리하는 의미에서, 4회에 걸쳐 자바스크립트 (프론트엔드) 프레임워크를 소개하는 시리즈를 연재할 예정입니다. 금주부터 아래와 같은 목차로 진행되니 많은 관심 부탁드립니다.Vue.js는 Evan You가 만들었으며, 2014년 릴리즈를 시작으로 꾸준히 발전하고 있는 자바스크립트 프레임워크이다. 앞서 소개된 Angular나 React보다 덜 알려져 있으나, 최근 Vue.js 포럼에 한국어 카테고리가 추가될 정도로 인지도에 상승 곡선을 그리는 추세이다. Vue.js를 접하는 사람들의 반응은 두 가지이다. 낯설거나 혹은 친절하거나. 전자는 (현재 이 글을 읽고 있는 당신을 포함하여) Vue.js를 처음 접하는 사람일 것이고, 후자는 단 한 번이라도 Vue.js의 가이드를 읽어보거나 사용해보고 싶다는 생각을 한 사람일 것이다.Vue.js는 발음대로 철저히 뷰(View)에 최적화 된 프레임워크이다. 컨트롤러 대신 뷰 모델을 가지는 MVVM(Model-View-ViewModel) 패턴을 기반으로 디자인 되었으며, 컴포넌트(Components)를 사용하여 재사용이 가능한 UI들을 묶고 뷰 레이어를 정리하는 것을 가장 강력한 기능으로 꼽는다. 또한 템플릿(Template) 위주의 개발을 권장한다. 이러한 특징들은 다음 목차에서 다루어질 내용의 미리보기 격으로, 앞에서 장황하게 설명하기보다 본론으로 들어가 샘플 코드와 함께 Vue.js를 이해하는 것이 더 좋을 것이다. 최근 Vue.js는 2.0 버전으로 업데이트 되었으며 앞으로 보게 될 예제 또한 최신 버전 기준으로 작성된 점을 참고하길 바란다.기본적으로 Vue.js는 사용할 때 신경 써야 할 의존성을 가지고 있지 않다. 2.0부터 Virtual DOM의 구현체인 Snabbdom을 사용하고 있지만, 필요에 의해 수정한 소스로 내장해 사용하고 있어 따로 설치하거나 버전을 신경 쓸 필요가 없다. Vue.js는 템플릿 엔진을 따로 사용하지 않고 웹 컴포넌트 스펙과 유사하게 구현된 HTML 형식의 커스텀 엘리먼트를 이용해 Virtual DOM 렌더 함수로 컴파일하도록 내부에서 구현했다.vue-cli는 프로젝트를 쉽게 구성할 수 있도록 미리 정의된 설정들을 사용할 수 있게 한다. Vue.js 전용 Yeoman이라고 생각하면 된다.을 이용해 쉽게 설치가 가능하며, 아래와 같은 기본 설정들을 제공한다.• : 특별한 모듈 관리 도구를 사용하지 않고 HTML 파일 1개로 구성하는 제일 간단한 조합아래와 같이 사용한다.프로젝트 규모나 필요에 의해 옵션을 선택해서 미리 구성된 설정들을 이용할 수 있기 때문에, 일일이 설정하면서 생기는 문제들로 스트레스를 받지 않는다.Vue.js는 인스턴스 생성 시 인자로 전달받는 객체를 이용해 상태를 관리하게 되는데, 안의 내용이 변경되면 내부에서 인지하고 그 데이터를 사용하는 컴포넌트들이 스스로 업데이트를 한다. 이때 디버깅의 편의를 위해 에 직접 접근하지 않고 따로 스토어 패턴을 이용해서 데이터를 관리하는 객체를 구현할 수 있으며, 결국 Flux 아키텍처와 유사한 구조도 생각해 볼 수 있다. 이렇게 간단하게 스토어를 구현할 수 있으나 직접 만들지 않고, Flux와 Elm 아키텍처에서 영감을 얻어 Vue.js를 확장한 Vuex 사용도 가능하다. 여기서 직접 다루진 않겠지만, 문서 내용을 보면 Flux 아키텍처를 알고 있는 사람이라면 익숙한 단어와 그림이 보일 것이다.요즘 프론트엔드 프레임워크는 그 자체도 중요하지만, 개발할 때 사용할 전용 개발 도구의 지원도 필수가 된 것 같다. Vue.js도 React와 Redux의 개발 도구만큼 유용한 전용 크롬 개발도구 플러그인을 지원한다. react-devtools처럼 커스텀 엘리먼트의 계층 구조와 바인드 된 컴포넌트 정보를 볼 수 있으며 Vuex 관련 도구도 지원한다.Vue.js에서는 단일 파일 컴포넌트(Single File Components)를 제공하는데, 이 단일 파일 컴포넌트를 정상적으로 사용하려면 Webpack이나 Browserify를 통해 빌드한 후 브라우저에서 사용 가능한 자바스크립트를 한 파일로 번들링하는 과정을 거쳐야 한다. 여기서 필요한 각 도구의 설정들은 직접 할 필요 없이 vue-cli를 이용해 쉽게 세팅 적용이 가능하다. (단일 파일 컴포넌트에 대한 설명은 4. 컴포넌트 목차에서 대신한다)React에서 사용하는 JSX를 Vue.js에서도 이용하고자 한다면 함수를 직접 작성하고 바벨 플러그인을 이용해 번들링 단계에서 적용할 수 있다.구현 코드는 React와 상당히 유사한데 아래와 같다.React, Angular 2와 마찬가지로 대부분의 모던 브라우저를 지원하며 인터넷 익스플로러는 9 버전부터 지원한다. Compatibility Note에 적혀있는 내용에 따르면 ES5 기능 중에 폴리필이 불가능한 기능을 이용하기 때문이라고 한다. 그래서 추가적인 폴리필을 이용해도 낮은 버전의 인터넷 익스플로러 지원은 불가능해 보인다.뷰 모델(View Model)은 Vue.js의 기초이자 절대 놓쳐서는 안 될 개념 중 하나이다. 뷰 모델은 다음 한 줄로 요약할 수 있다.Vue.js에서는 생성자 함수의 인스턴스를 생성하면서 뷰 모델을 다루게 된다. 아래 예제와 같이 인스턴스를 생성할 때 뷰와 데이터를 연결하기 위한 옵션을 설정할 수 있다. 자주 사용되는 옵션 정보는 다음과 같으며, 더 많은 옵션은 API 문서에서 카테고리에서 확인할 수 있다.뷰 모델의 인스턴스가 정상적으로 생성되었다면 Vue.js를 사용하기 위한 절반의 준비는 끝났다.Vue.js에서 뷰 모델이 생성되는 순간부터 중요한 사이클이 시작된다. 생명 주기(Lifecycle)라고 부르며 다음 다이어그램을 이해한다면, 위에서 뷰 모델을 생성하기 위해 설정된 옵션들이 어떠한 용도로 사용되었는지 파악할 수 있다. 다이어그램에서 빨간색 박스는 생명 주기의 단계를 나타내며, 뷰 모델 생성 옵션 중 생명 주기 훅에 해당하는 콜백 메서드들이 실행되는 시점이기도 하다. 생명 주기 훅을 기준으로 생명 주기 각 단계에서 하는 일을 정리하면 다음과 같다.• ~ : 데