10월부터 장고 REST API로 백엔드를, 리액트로 프론트엔드를 사용하여 SPA 웹사이트를 설계, 개발하고 배포하는 프로젝트를 진행하고 있다. 나는 프론트엔드 개발을 맡았고, 서규가 백엔드를 맡았다.
둘 다 리액트와 장고에 대한 사전 지식이 거의 전무하다시피 한 상황에서 실제 액티브 유저가 1,000명 가까이 되며 매년 2-300명씩 추가될 가능성이 있는 비교적 큰 웹사이트를 개발하게 되었다. 코드 리뷰와 최적화 및 리팩토링을 앞둔 상황에서 지난 3개월간 설계, 개발 및 배포 과정에서 맞닥뜨렸던 수 많은 어려움들을 다시 정리하고, 학습하는 포스트를 시리즈로 진행하려 한다.
프로세스
첫 째로, 9월에 우리에게 프로젝트를 의뢰한 클라이언트를 직접 만나서 설계 및 계획 단계를 논의했다. 이 단계에서는 Coursera의 웹개발 코스에서 배운 내용을 참고했다. 그 내용은 아래와 같다.
Most clients have NO IDEA what they want.
대부분의 클라이언트는 자신이 무엇을 원하는지 모른다. 자신의 사업에 대해서는 잘 알고 있지만, 웹사이트를 어떻게 만들고 어떻게 작동하는지에 대한 지식이 없다. 그래서 적당한 질문을 통해 고객이 무엇을 원하는지 파악할 수 있어야 한다. 가장 정확한 것은, 여러가지 레퍼런스를 보여주면서 어떤 점이 좋고 나쁜지를 이야기 나누는 방법이다.
클라이언트에게 웹사이트의 규칙을 설명한다.
적은 정보를 올릴수록 효과적이다. LESS IS MORE.
가장 중요한 정보를 고객이 식별할 수 있도록 돕는 것이 웹사이트의 목적이라는 것을 알린다.
Find a way for the client to invest in the project.
클라이언트가 프로젝트에 투자하게 만들어라. 포트폴리오를 위해 무료로 작업을 해 주는 경우에는 더 그렇다. 고객에게 무언가를 맡겨라. 무료로 하는 작업이라 해도, 제품의 사진을 위한 비용은 지불하게 하거나, 사진사를 직접 구하게 하거나 등. 클라이언트가 프로젝트에 추가적인 자신의 자원을 투자하게 되면, 금액은 크지 않더라도 더욱 진지한 자세로 프로젝트에 임하게 된다.
Have client designate ONE PERSON responsible for decisions.
결정을 내리는 책임자를 명확하게 지정해 달라고 말한다. 제안에 대한 결정은 양측이 결정권자를 통해서만 합의하도록 한다.
Limit number of revisions UPFRONT.
수정 횟수는 미리 정한다. 돈을 받고 작업을 하는 경우에는 수정 횟수에 추가 금액을 바로 반영하지 말고, 무료 수정 횟수를 미리 정한다. 그 이후에는 시간당 비용이 발생한다는 것을 알린다.
Google for 'web development client questionnaire.'
웹개발 단계에서의 클라이언트들이 자주 하는 질문을 검색해본다.
Get an idea of what the client has right now.
클라이언트가 가진 웹사이트의 현 상황을 점검한다.
내가 졸업한 학부의 학과 웹사이트를 만드는 일이었기에, 내가 학교를 다닐 때 웹사이트 사용자의 입장에서의 요구 사항을 정확히 인지할 수 있었다. 실제로 어떤 웹사이트가 필요한지 듣고, 정해진 예산 및 시간 내에서 어떤 부분이 구현 가능하고 불가능한지, 만약 불가능할 경우 클라이언트의 요구 사항에 대한 대안은 어떤 것들이 있는지를 설명했다.
이 프로젝트에는 디자이너 2명, 프론트엔드 개발자 1명, 백엔드 개발자 1명 총 네명이 참여했고, 긴밀한 협업이 필요했으므로 협업 도구로 노션을 이용하여 프로젝트 문서를 정리했다. 이후 하위 노트를 다섯 개의 카테고리로 나누어 다음과 같이 정리했다.
A. 프로젝트 기획
B. 회의록
C. 개발 진행과정
D. 디자인 진행과정
E. 계약서, 결제 및 대금 관련 문서
프로젝트 설계와 기획, 진행 과정에 대한 모든 사안은 A 노트에 정리했다. 모두가 합의하고 인지할 수 있는 프로젝트 이름과 기간, 레퍼런스 웹사이트에 대한 정보를 명시하고, 아래와 같이 각자가 프로젝트에 사용한 언어 및 도구에 대해서도 정리했다.
격주에 한 번 정도로 이루어진 회의 내용은 프로젝트에 참여한 모든 사람들이 공유할 수 있게 B 노트에 기록해 두었다. 그리고, 클라이언트도 진행 과정을 참고할 수 있게끔 모든 문서를 공유했다.
이후 기능별로 카테고리를 나누어 위와 같이 체크리스트로 정리하였고, 이 내용을 바탕으로 Github 리포지터리의 Project 탭을 이용해서 개발상 진행 과정을 정리했다.
협업
코드 버전 관리: Git, Github
프로젝트 개발 기획 및 일정 관리: notion
프로젝트 문서 관리: notion
협업 방식: Git Flow
프론트엔드, PM
Chaewon Kang
언어: HTML, CSS, JavaScript
프레임워크: React
상태관리: Redux
파일관리: yarn, npm
백엔드
Seogyu Kim
언어: Python
프레임워크: Django, Django-rest-framework
디자인
YinYang(Seunghyun Lee, Yubin Park)
툴: Xd
그리고 추가로 프로젝트 진행 시 알게 된 유용한 링크와 정보 등에 대해서 공유하는 표도 만들었다.
이후 개발 팀은 Github에 프로젝트 리포지터리를 생성했고, Git Flow 방식을 채택하여 프로젝트를 진행했다. 이 과정에서 backend/frontend 폴더를 구분하지 않고 루트 디렉터리를 통째로 pull하여 프로젝트를 진행하다 보니, 나중에는 코드의 버전이 꼬여 난항을 겪었던 일이 많았다. 다음 번 프로젝트에서는 frontend/backend 폴더별로 코드 버전관리를 하기로 절치부심 했다.
전체적인 기획을 끝낸 이후에는 아래의 프로세스를 따랐다.
- 단계를 쪼개서, 시기별 구현 목표를 세운다. 우리는 헤더와 푸터, 메인 화면 디자인을 먼저 잡고 세부 카테고리를 절차적으로 하나씩 구현했다. 이후 웹사이트의 전체 기능과 연동할 필요성이 적은 것들을 마지막에 구현한다. 이를테면 맵 API나 설치 형식의 서비스들.
- 디자이너가 디자인을 전달하면 그 디자인에 대해 프론트엔드 개발자와 논의한다. 어떤 부분이 구현 가능하고 불가능한지 회의해서 수정된 안으로 최종 디자인을 결정한다.
- 웹사이트 UI를 구현하고, 로컬에서 백엔드 서버를 켜서 연동 테스트를 한다. 이 과정에서 백엔드 개발자와의 논의가 필요한 부분이 있다면 상황에 반응적으로 논의하고, 수정을 거친다. 이를테면 CRUD작업 시 맞춰줘야 하는 JSON 객체의 필드 형태나 데이터 타입 등.
- 구현이 1차로 완료된 뷰에 대해서 디자이너와 다시 논의하여 디테일한 부분들을 수정한다. 구현을 하다가 빠뜨린 부분들에 대해 디자인을 다시 잡고, 구현을 보충한다.
맞닥뜨린 어려움들
프론트엔드 개발자로서 React를 이용하면서 개발 과정에서 겪었던 어려움은 다음과 같았다.
리액트의 어려움
1. 클래스형 컴포넌트 / 함수형 컴포넌트
오라일리에서 발간된 책으로 React를 처음 공부한 나는 클래스형 컴포넌트가 이제는 잘 쓰이지 않는 형식이라는 것을 제대로 인지하지 못했다. 나중에 가서는 인지는 하게 되었지만, 이미 시작한 거 그냥 진행해 보자! 라는 생각이 더 컸던 점도 있다.
리액트 공식 문서의 Hook 개요를 보면, 리액트에서 추구하는 명료성과 재사용성의 기준에서 봤을 때 Class 컴포넌트를 사용함에 있어 필요한 부가적 개념이 많아 Hook을 도입했다고 쓰여 있다. 그러나 내 경우에는 useState 등의 훅보다 생명주기 함수들이 더욱 명료하게 여겨졌다.
그러나 클래스형 컴포넌트를 사용하여 개별 컴포넌트에서 상태관리를 해야 하는 경우가 많아지면서 코드가 난잡해져 갔고, 린터가 보내는 워닝 사인이 늘어나기 시작했고, 구멍난 옷을 새로운 천으로 기워서 때우는 패치워크식의 코드들이 늘어나기 시작했다.
그래서 함수형 컴포넌트의 Hook을 제대로 다시 공부하고, 클래스형 컴포넌트로 작성된 컴포넌트들을 함수형 컴포넌트로 리팩토링 하고자 한다.
2. CSS/SCSS/Styled Component
현재는 기본 CSS를 이용하여 스타일을 지정하고 있다. 물론, 웹팩이 알아서 번들을 잘 해 주며, SCSS와 Styled Component를 공부하기도 했지만 아직까지는 CSS가 익숙해서 그런지 CSS가 더 편하다. 하지만 앞으로 리액트를 계속 이용할 생각이라면, Styled Component를 이용해야 할 필요성을 느낀다.
3. Axios
Axios를 더 제대로 공부해야 겠다는 생각. 현재는 단순히 POST와 GET만을 이용하고 있지만, 나중에 수정 및 삭제를 구현해야 할 경우. 특히나 JWT token을 이용하여 권한 관리를 해 주어야 하는 웹사이트의 경우, HTTP 통신이 잦은 경우에는 Axios Interceptor 등의 개념이 아주 유용할 것이다.
4. 반응형 디자인, 크로스브라우징
IE에서는 제대로 테스트를 해볼 수 조차 없었다. 크롬, 사파리에서만 테스트를 했으나 기본적으로 적용되어 있는 스타일을 해제한다든지, 브라우저와 관계없이 멀티스크린으로 사용하는 대형 스크린에 일관된 스타일을 적용 하는 문제들에 어려움을 겪었다. 브라우저 리사이징 breakpoint를 제대로 설정하고, 디자인 단계에서도 이러한 한계들을 사전에 설명할 수 있어야 한다.
5. 라이브러리 사용
React modal 등의 라이브러리를 사용하면서, 더이상 업데이트 되지 않거나 사용상 한계가 많은 라이브러리를 제대로 인지하지 못해 문제가 발생한 경우도 있었다. npm patch 폴더를 만들어 해결하기는 했지만, 앞으로 간단한 뷰가 아니라 뷰에서 통신이나 사용자 반응이 긴밀하게 연결되어 있는 경우, 가급적 컴포넌트를 직접 만들자.
6. Webpack
CRA 없이 리액트를 만들어 보는 경험은 무조건 필요하다. 특히 개발 모드, 프로덕션 모드를 구분하여 테스트를 진행하는 것은 무조건 필요하다.
7. 상태 관리
가장 큰 문제 요인은 상태관리다. 전역 상태관리가 필요한 경우 Redux, Redux Middleware을 사용해 더 효율적인 상태 관리를 할 줄 알아야 함을 절실히 느꼈다. 현재는 개별 컴포넌트 단위에서의 상태 관리가 주를 이루고 있다. 이를 하나의 스토어로 통합하고, 더욱 최적화된 데이터 관리가 가능하도록 하자.
배포의 어려움
각자의 로컬에서 구현 및 테스트를 하는 과정에서는, 이미 작성한 코드를 최적화 하는 과정, 그리고 서버를 구동하여 CRUD를 테스트하는 일(데이터 fetching 및 post, 로그인/로그아웃 권한 등)을 제외하고 예상보다 큰 어려움은 없다고 생각했다. 그런데 진짜 난관은 배포 단계에서 찾아왔다.
Django와 React를 하나의 서버에서 구동시키기 위해 배포 단계에서 고려해야 할 제약들이 상당히 많았다. 그러나 모든 문제는 HTTP 통신 지식이 부족하다는 것으로 귀결됐다. 따라서 프론트엔드 개발자로서 기본적으로 알아두어야 할 통신 관련 지식을 더 보충하기로 했다.
1. HTTP 통신에 대한 지식
MIME TYPE Error, URL Redirection, HTTP 통신 시 Request 헤더 및 지켜주어야 하는 컨텐츠 타입 등.
앞으로 이어질 시리즈에서 이러한 어려움들을 극복해 보자.
