[코딩온] 팀 프로젝트 1차 회고록

 

팀 프로젝트의 주제

부트캠프를 통해 학습한 HTML, CSS, JavaScript, jQuery를 활용하여 첫번쨰 홈페이지를 제작하게 되었다.
우리 팀은 소니의 음향기기 분야를 주제로 홈페이지를 리뉴얼해보기로 하였다.

주제를 선정한 이유

소니는 업체의 기원이라 할 수 있는 음향기기부터 카메라, 게임기, 스마트폰 등 복합적인 전자기기를 개발, 유통하는 회사이다. 따라서 홈페이지 또한 여러 전자기기가 복합적으로 섞여있는 구성을 갖고 있다. 하지만 소니의 뿌리라 할 수 있는 사업분야는 음향기기 사업이다. 그래서 음향기기를 전문적으로 다루는 홈페이지를 제작해보기로 논의한 끝에 결정하였다.

 

나의 담당 업무

 

1주일이란 짧은 개발 기간과 몇주 동안 공부했던 짧은 식견을 바탕으로 하였기에, 일단, 메인페이지, 화사에 대한 소개, 회사가 가지고 있는 기술령 총 세 페이지로 웹페이지를 제작하게 되었다. 나는 이 중에 화사에 대한 소개 파트를 맡기로 하였다.

 

맞닥뜨린 문제점

처음 팀 프로젝트를 진행하는 만큼, 몇 가지 문제점을 마주할 수 있었다.

 

1. 팀원들의 웹 디자인과 디자인 프로그램에 대한 사용 경험 부재.

처음 계획했던 작업 방식은
1. 본인이 담당한 페이지의  컨텐츠를 결정한다.
2. 각자 페이지에 대한 디자인을 \포토샵, 일러스트, 어도비 XD등을 활용해 디자인
 한다.
3. 이후  각자의 디자인을 의논하며 피드백을 통해 최종 결정을 낸 후 작업에 착수한다.
같은 작업 방식을 계획하고 있었다.
하지만 나는 팀원 들 중 유일한 전공자였기에 프로그램 개발에 대한 경험은 갖고 있었으나, 직접 프로젝트를 디자인해본 경험은 부족했다.

 

2.  생각했던 것보다 방대했던 데이터

처음엔 단순히 회사의 소개와 소니의 음향기기 사업이 어떻게 발전해왔는지를 대충 연혁표의 형태로 작성하면 웹페이지를 개발해나가면 된다고 생각했다. 하지만 내가 생각했던 것 이상으로 소니의 각 전자기기들은 밀접한 기술적 관련성을 갖고 있었다. 하다보니까, 처음엔 단순히 헤드셋에 대한 연혁만을 작성하려고 했는데, 그 시작을 쫒아 가려다보니, 워크맨, MP3, 헤드셋, 이어폰을 전부 다 하지 않으면 안되는 상황이 되었다.

 

3.  라이브러리 사용 경험의 부재

난 전공자였긴 하지만, 학부에서 팀 프로젝트를 할 때마다, 구해지는 팀원의 가능한 역량에 맞추어 개발 언어를 바꾸어가며, 대화에 참여해왔었다. 하지만 그러다 보니, 다양한 언어를 개발해본 경험은 있었으나, 부트캠프에 들어와 참여해본 결과, 언어에 대한 깊이는 부족했다는 걸 느꼈다. 그리고 프로젝트 개발에 사용할 수 있도록 만들어진 프레임워크나 라이브러리에 대한 지식도 부족한 편이었다.

 

해결 방법

 

1. 팀원들의 웹 디자인과 디자인 프로그램에 대한 사용 경험 부재.

다행이도 우리 팀에는 디자인 프로그램을 사용해본 경험을 가진 팀원 분이 계셨다. 만약에 없었더라면 프로젝트 화면을 구성하는데, 더 힘들지 않았을까? 어쨌든 프로그램의 경우에 설치 과정이 없어도 사용할 수 있는 "피그마"를 디자인 프로그램으로 작업을 진행했다.

1. 컨텐츠와 레이아웃 구상.
2. 디자인 구상

두 가지 업무로 역할을 나눠서 작업을 진행했다. 

 

1) 컨텐츠와 레이아웃 구상

1. 팀원들은 각자 페이지에 들어갈 컨텐츠를 구상하며 해당 컨텐츠를 어떤 방식으로 보여주고 싶은지 결정한다.
2. 일단, 디자인을 배제한 체로 와이어프레임 형태로 대략적인 틀만 작성하였다.
3. 각 팀원들은 서로 원하는 방식대로, 피그마의 도형을 활용하거나, 그림판의 펜을 통해서 직접 그려서 그려내는 방식을 사용하는 등, 자유롭게 구상도를 그렸다.

 

2)  디자인의 구상

팀원들의 대략적인 구상이 완료되면 와이어프레임의 구조와 내부 컨텐츠를 고려해서 적합한 디자인을 골라 포토샵과 피그마의 프로토타입 기능을 활용하여 대략적인 페이지의 구조를 잡는 작업을 진행한다. 이후 완료된 디자인 작업물들을  작업을 진행할 팀원들과의 토의를 통해 촤종 결정을 하게 되었다.

 

덕분에 전체 페이지를 통일성 있고 일관되게 제작할 수 있었다.
팀원들 또한 각자가 구현할 기능과 표현할 컨텐츠에 좀 더 집중할 수 있는 긍정적인 효과를 낼 수 있었다.

 

2.  내가 생각했던 것보다 방대했던 데이터

 

다른 업체의 홈페이지 리뉴얼을 프로젝트로 선택했더라도 비슷했을 것 같지만, 소니 역시 그냥 단순히 문어발로 사업을 확장해왔던 건 아닌 것 같았다.
만약에 그랬다면 예전에 망하고 말았던 대우나 지금 위기를 겪고 있는 카카오와 비슷한 상황이 돠었을 지 모른다. 어쩄거나, 데이터가 너무 많았기 때문에 연혁표에 들어갈 내용의 범위를 어떻게 정해야 하는지 검토가 필요했다.
나는 최대한 많은 내용을 넣고 싶었으나, 이미지의 양이 많아질 수록, 홈페이지가 길어지는 문제, 반응형 적용 시 시간이 더 걸릴 수 있다는 점을 팀원들이 제기하였다.
그래서 고민한 끝에 제품의 역사는 연대 별로, 화사의 역사는 연혁표를 유지하되, 꼭 필요 없을 것 같은 부분은 제회하는 형태로 개발 방향을 잡았다.   
개발 시간이 정해져 있다는 점도 고려사항이었다.

 

3. 라이브러리, 프레임워크 사용 경험의 부재

어떤 형태로 만들 것인지에 대한 방향성이 1,2번 문제를 해결하면서 선정되었기에 프로젝트에 사용할 라이브러리는 슬라이더 외에는 없었다. 해당 슬라이더의 경우, 사용자가 슬라이드한 방향에 따라 슬라이더의 방향이 바뀌도록 구현하고자 했는데, 그 당시 내가 가진 개발 능력으론 부족하다는 사실을 느껴서 슬라이더 관련 라이브러리를 검색해보기로 했다.

링크: Swiper - The Most Modern Mobile Touch Slider

1. SwiperJS
- 타이틀에도 써있듯이 가장 무난한 모바일 터치 슬라이더를 표방하는 플러그인이다.
- 장점은 현재 가장 오래된 슬라이더 관련 라이브러리 이기 때문에 광장히 많은 옵션을 갖고 있다는 점이었다.
- 해당 라이브러리는 반응형을 지원하고 있기에 모바일 사이트, PC웹에서도 사용하기 편하게 설정되어 있다.
- 또한 현재 현업에서 사용하는 React, Svelte, vue JS, Angular 등 다양한 툴을 지원한다는 장점이 있다.

 

링크 : slick - the last carousel you'll ever need

2. Slick

- Siwper보다 옵션 종류는 적지만 간단하다는 장점
- 스와이프를 기본으로 지원슬라이드를 동적으로 추가/제거하는 기능,
- 필터링으로 조건을 달아 슬라이드별로 숨기고 보이는 기능 등을 구현할 때 유용하다.
- 마크업 코드와 스타일 코드를 분리하여 작성할 수 있어, 유지보수가 용이
- 필요하지 않은 기능을 따로 가져와 쓸 수 없기에 웹페이지가 방대해 질 수록 부하가 걸릴 수 있다.

 

3. bxSlider

 

 

- JQuery를 활용해 간단하고 편하게 슬라이더를 개발할 수 있는 플러그인이다.
- JQuery의 기능 확장에 불과하기에 웹페이지 로드시 부담이 적다.
- 다양한 옵션을 제공해주고, 사용하기도 간편하다.
- 반응형 웹에서 화면 크기에 따라 슬라이더 자체를 감췄다가 보이게 하는 경우, 슬라이더가 표시되지 않을 수 있다.
- 컨텐츠의 길이가 길다면 오류가 발생될 여지가 있다(확인해보진 못함)ㄴ

 

그 외에도 다양한 라이브러리가 존재하지만, 시간 관계상 다 써보진 못했다. 그리고 앞으로 다양한 프론트엔드 쪽 개발 언어를 배우게 될 텐데, 그때마다 오류 없이 작동시킬 수 있는 Swiper JS를 이용해 프로젝트 페이지 상단의 슬라이더를 만들어보기로 하였다.

 

브랜치 규칙

 

지금은 팀원 별로 하나의 페이지를 개발했고, DB나 서버 쪽 소스를 추가해 개발하는 것이 아닌, HTML과 CSS를 이용한 화면 디자인에 간단한 함수 정도만 JS로 작성해 사용해보는 프로젝트였기에 브랜치 규칙을 작성하지 않아도 큰 문제는 없을 터였다. 하지만, 본래 무분별한 메인 브랜치로 푸시를 해버리면 깃허브를 이용한 협업을 배우는 의미도 없을 뿐더러, 실제로 지금은 팀원이 3명 밖에 없는 프로젝트 지만, 더 많은 팀원이 함께하는 프로젝트를 진행할 때 문제가 생길 것이다.
그래서 깃허브에 브랜치 규칙을 설정하였다. 덕분에 메인 브랜치로의 푸시는 막으면서 각자의 브랜치에서 작업을 한 뒤 팀원들에게 PR(Pull Request)를 거쳐서 승인을 받아 작업을 진행할 수 있도록 하기로 정했다.

 

파일 분할

 

작업 파일의 경우 디자인의 통일성을 유지시키기 위해서 몇가지 조치를 취하였다.

1. reset.css 파일의 사용

브라우저의 기본 스타일 설정으로 인해 서로의 작업 결과물이 달라질 것을 우려하였다.
모든 브라우저의 기본 디자인을 초기화 시킬 목적의 css 파일을 별도로 연결하는 방식으로 해결한다.

 

2. 반복되는 버튼 스타일과 @font-face 속성

반복되는 디자인으로 인해 동일한 css 속성들이 불필요하게 반복 사용될 것을 우려하였다.
마찬가지로 각자 별도의 css 파일로 분류해 연결하여 방지하였다.
덕분에 깃허브를 적극적으로 활용하고 숙달할 수 있었으며 어떤 데이터를 공유해야더욱 효율적으로 협업을 진행할 수 있을지 고려해보는 계기가 되었다.