첫 리액트 개발 도전기(1) - 일을 시작하는 순간, motiiv

본 포스트는 서비스 소개부터 협업을 통해 배운 점까지의 이야기를 담고 있습니다.


다크 모드가 정말 예쁜 모티브 구경 가기 : www.motiiv.site/

26기 SOPT에서 서버 개발을 하다보니, 내가 보내주는 이 데이터들이 도대체 프론트에서 어떻게 굴러가고 있는건지 궁금해지기 시작했다. 프론트 개발이 어떻게 이루어지는지를 잘 모르니 서버 연결 중에 오류가 나도 로그에 찍힌 상태 코드를 보며 "음.. 400인데... 콘솔로 뭐가 안 들어오는지 찍어볼게! 아마 이게 안 들어오고 있는거 아닐까..?"라고 대답해줄 수밖에 없어서 프론트 개발자들에게 미안하기도 했다. 그래서 어차피 이제 막 개발에 입문한 김에 전체 개발 사이클을 경험해보고, 겸사겸사 내가 프론트엔드 개발을 더 재밌어 하는지 백엔드 개발을 더 재밌어 하는지 알아보자!라는 마음으로 27기 SOPT 웹파트에 지원했고, 러닝커브 대마왕 리액트와의 사투가 시작되었다🔥

결론부터 말하면.. 프론트 개발자로 참여한 앱잼을 한 번 경험하니, 서버 개발자로서 고민하면 좋을 점들을 여러가지 알 수 있었다. 사실 오류가 났을 때 서버로서 해줄 수 있는 건 로그를 보며 원인을 함께 찾아가는게 전부였지만, 하나의 API에 해당 뷰에서 필요한 모든 정보를 보내주는 것이 프론트 개발자들이 서버 연결 작업을 한 번만 해도 되어서 편하다는 것(물론 이것은 클라이언트 개발자와 사전에 정보를 어떻게 보내주는게 좋을지 상의하는 것이 필요하다!)과 보내고자 하는 데이터 타입과 개수에 따라서 정말 딱 필요한 형식으로 보내주어야 작업이 수월하다는 것을 깨달을 수 있었다. (STORM에서 정수 데이터인 user_idx만 보내는 API가 있었는데, 이때 내가 습관대로 data를 객체로 감싸서 보냈더니 프론트 개발자가 이렇게 한 겹 더 감싸서 보내는 이유가 있냐고 물어봤었다. 그땐 이게 무슨 차이라고 이렇게 물어보는걸까 했는데 지금 생각해보니 프론트 입장에서는 정말 쓸데없이 데이터 형식을 맞추는 귀찮은 작업을 한 번 더 해야 했던 거다. 특히 STORM은 네이티브 안드로이드로 개발되어서 data class를 따로 만들어야 해서 더 귀찮았을 것이다. 부족한 서버였어서 미안했다 우리 클라들..) 덧붙여 전체 API 명세서를 빠르게 넘겨주는 것도 생각보다 정말 중요했다. 요것은 백엔드 개발자로서 느낀 점들.

그럼 프론트 개발자로서 나는 어떤 것들을 배웠을까? 차분히 되돌아보고자 한다.


---



💡motiiv💡

나름의 거창한 목표가 있었던 지난 앱잼과는 달리 사실 이번 앱잼의 목표는 간단했다. 내가 꼭 일해보고 싶었던 디자이너와 같은 서비스를 개발해보고, 나보다 선배 개발자가 있는 팀에 들어가 잔뜩 질문을 던지며 프론트라는 세계에 대해 최대한 이것 저것 많이 건드려볼 수 있는 팀. 그리고 감사하게도 이 모든 조건을 충족하는 멋진 'motiiv'라는 팀을 만났다!

(pc에서 이미지를 클릭해야 gif가 정상적으로 재생된다.) 기간 내에 반응형 작업 및 다크모드까지. 우리 모티버들의 손발 척척 모먼트가 보이는가.

motiiv는 동기부여 영상을 보고 바로 작업에 착수할 수 있도록 사용자 맞춤형 동기부여 영상을 추천해주는 플랫폼이다. 쉽고 빠르게 로그인할 수 있도록 소셜 로그인을 붙여야 했고, 언제 어디서든 바로 작업에 착수할 수 있도록 워크 스페이스 플로팅 버튼이 존재해야 했고, 눈의 피로도를 줄이기 위해 다크모드 기능이 있어야 했다. 처음엔 단순히 동영상만 시청할 수 있는 플랫폼이겠거니 생각했는데, 생각보다 구현해야 할 기능이 엄청 많아서 놀랐던 기억이 난다.

팀빌딩이 끝난 후, 모티브의 노션에 들어가 기획/디자인 파트 사람들이 모티브의 핵심 가치부터 시작해서 브랜딩 과정에 대해 쭉 정리해놓은 글을 읽었다. 사실 개발자가 읽으라고 정리해놓은 글은 아닌 것 같은데 재밌어 보여서 읽었다. '사용자가 동기부여를 받고 일을 바로 시작하게 한다'라는 목표를 달성하기 위해(어쩌면 이 목표에서 벗어나지 않기 위해) 계속해서 고민하고, 어떤 기능을 제공하면 좋을지 가지를 뻗어나가는 작업을 거쳐왔다는 것을 눈으로 보며 읽으니 왜 이런 기능과 이런 디자인이 나왔는지 이해할 수 있었다. 그래서 조금 많긴 하지만 기간 안에 최대한 모든 기능을 구현하려고 더 노력했던 것 같다. 이처럼 개발자가 모든 기획/디자인 회의에 참여할 수는 없으니 그들의 사고의 흐름을 읽어볼 수 있도록 정리된 문서를 남겨두는 것도 참 좋다는 생각을 했다. 서비스 자체를 이해하는데도 정말 큰 도움이 되고, 만약 수정이 필요한 부분을 발견한다면 상대방이 이렇게 작업한 의도를 이해한 후 수정 요청을 할 수 있기 때문에 훨씬 마찰이 줄어들 수 있겠다고 느꼈기 때문이다.

3주동안 99% 리모트 작업만으로 이렇게 멋진 결과물을 낸 모티브에 대한 이야기를 시작한다 :)



---


앱잼에서 웹 개발자의 역할은 아래와 같다.

1. 디자인 시안대로 뷰를 제작한다. 반응형 작업 시작 시기는 팀바팀.
2. 클릭 이벤트 등 서비스의 기능을 구현한다. 이때 API 명세서를 참고하여 바로 서버를 연결만 하면 되도록 임의의 데이터를 만들어 데이터 바인딩을 해놓는다.
3. 서버를 연결하고 서버와 함께 열심히 오류를 잡는다.
4. QA 종료 후 페이지 호스팅! 호스팅 된 후에도 열심히 QA를 하며 오류가 없는지 점검한다.

위의 개발 순서에 따라 먼저 진행했던 반응형 작업부터 이야기하고자 한다.


---


💡디자이너와 협업할 때💡

디자이너도 웹개발자도 모두 웹 서비스를 개발해보는 것은 처음이다보니 처음에 가장 애를 먹었던 부분이 바로 break point를 잡는 부분이었다. 혹시라도 프론트 개발 때문에 고민하다 여기까지 흘러온 프론트 개발자가 있다면... 꼭 양옆 마진 최소를 기준으로 뷰를 나눠서 작업하소서!!! 그게 가장 작업하기 편하더이다...

프론트 작업을 할 때 받았던 뷰별 예시들. 영상 스와이프 양옆 마진이 최소일 때의 뷰를 피그마에 작업해두고 구간별로 브라우저 너비를 조정했을 때 어떻게 변하는지에 대해서 자세하게 이야기를 나눴다.

모티브의 경우에는 웹, 태블릿, 모바일 3개의 반응형 뷰가 필요했다. 처음엔 '데스크탑은 1280, 태블릿은 768, 모바일은 375로 잡아서 작업한대'라는 어디서 주워 들은 이야기로부터 시작해 열심히 브레이크 포인트를 잡고 작업을 하고 있는데, 갑자기 의문이 들었다. 태블릿이 768px부터 1280px까지인거야 아님 375px부터 768px 까지인거야? 다들 어떻게 작업하고 있었는지 확인해보니 과연 제각각이었다.

style 폴더 내부에 theme.js 파일을 만들어서 반응형 뷰 너비 및 컬러를 관리했다. 이렇게 따로 정의해둔 덕분에 훨씬 코드도 깔끔해졌고, 어떤 뷰에 해당하는 미디어 쿼리인지 구별하기 쉬웠다.

<!-- theme.js -->

const size = {
mobile: '480px',
tablet: '768px',
laptop: '1024px',
desktop: '1280px'
};

const theme = {
// 잔뜩 뒤섞여있던 혼란의 브레이크 포인트를 어떻게든 수습했다..
mobile375: `(max-width: ${size.mobile})`,
mobile: `(max-width: ${size.tablet})`,
tablet768: `(max-width: ${size.tablet})`,
tablet: `(min-width: ${size.tablet})`,
laptop: `(min-width: ${size.laptop})`,
maxlaptop: `(max-width: ${size.laptop})`,
desktop: `(min-width: ${size.desktop})`,
maxdesktop: `(max-width: ${size.desktop})`
};

디자이너와 긴급 회의(!)를 거친 결과, 기존에 작업하던대로 1280px, 768px, 375px로 뷰를 넘겨주되, 해당 너비일 때가 각 뷰의 양 옆 마진이 최소일 때라고 합의를 봤다. 모든 뷰에서 너비를 늘이면 '양 옆 마진만' 늘어나게 되며, 모바일의 경우 768px 이하까지, 태블릿의 경우 1024px 이하까지, 1024px ~ 1280px의 경우 필요하다면 웹 개발자가 자율적으로 반응형 작업을 진행한 후 디자이너에게 보여주고, 데스크탑의 경우 1280px 이상일 때 보일 수 있도록 말이다!

이렇게 최대 몇 px까지 해당 뷰를 보여줄지 확실하게 정하니 max-width만 사용할 수 있어서 처음에 브레이크 포인트를 잘 논의하는게 중요하다는 것을 깨달을 수 있었다. 단순히 브레이크 포인트 지점만 정하는 것이 중요한 게 아니라 '구간'을 고려하며 서로 논의하고, 반응형 작업이 어떻게 이루어질 것인지(모티브처럼 마진만 조절할 것인지 아니면 영상 썸네일 비율에 맞춰서 이미지가 커지거나 작아지는 방식으로 할 것인지)를 정하는 것이 정말 중요하다는 것 또한 배울 수 있었다. 역시.. 클라이언트 개발은 다른 파트와의 소통이 정말 중요한 파트라는 걸 반응형 작업을 하면서 다시 한 번 깨달았다.


---


💡styled-components? SCSS?💡

웹파트가 모여서 가장 먼저 결정해야 했던 것은 코드 컨벤션(ESLint, prettier), 커밋 컨벤션, boiler-plate 작업(파일 구조를 어떻게 나눌지), 그리고 CSS 작업을 어떤 방식으로 할 것인가였다! 처음에 styled-components와 SCSS 중 어떤 방식을 선택하는 것이 더 효율적일까에 대해 논의하는 과정이 꽤 뜨거웠다.

* SCSS : global style을 미리 정의해놓고 입히기 쉽다. 비슷한 component들에 스타일을 먹이기 훨씬 간편하다.
* styled-components : props에 의한 조건부 스타일링이 쉽고, 별도의 css 파일이 없어도 된다.

어떤 것이 더 효율적인가에 대한 논쟁이 끝나지 않아서, 만약 SCSS처럼 공통적으로 자주 쓰이는 스타일들을 지정할 수 있는 방식을 찾는다면 styled-components를 사용하기로 하고 하루 정도 열심히 찾다가 하위 전체 컴포넌트가 공유하는 value를 지정하는 ThemeProvider, 전체 파일에 공통 css를 적용할 수 있는 GlobalStyle 등을 찾게 되어 styled-components를 쓰기로 결정했다.

처음엔 단순히 뷰를 디자인대로만 구현하면 될 거라고 생각했는데, 효율적인 코드를 위해서 이런 부분부터 신중하게 고민하는 팀원들을 보며 조금 더 진지하게 깔끔한 코드에 대해서 고민하고 신경써야겠다는 다짐을 했다. 정말 생각보다 좋은 코드를 위해서 고민해야할 부분이 많다는 걸 피부로 느꼈던 순간이었다!



---


💡motiiv의 기능💡

이번 글은 앱잼 웹파트 최종 과제로 제출했던 구현 보고서를 첨부하며 마무리하려 한다! 3주 안에 완성했다고 믿기 힘들만큼 퀄리티가 높다. 모든 팀원들이 각자의 자리에서 열심히 노력한 덕분이다.

motiiv 기능 소개

디자인 요소들이 디자이너들이 원하는 그대로 화면에 구현될 수 있도록 마지막까지 하나 하나 살펴보며 세심하게 수정했고, 기획자들이 생각했던 기능들이 모두 구현될 수 있도록 state와 밤샘 사투를 벌였다..!!

이 부분과 관련된 이야기는 다음 포스팅에서 :)