팀 프로젝트 Logoyogo 회고
Logoyogo 바로가기
깃헙 레포지토리 - 클라이언트 바로가기
깃헙 레포지토리 - 서버 바로가기
작년 9월 말부터 시작하여 달려온 여정이 어느덧 종점에 이르렀다는 것이 실감이 나지 않는다. 퇴근하고 노트북 앞에 앉아 과제를 어떻게 풀어야 하나 머리를 열심히 굴리던게 엊그저께 같은데 시간이 참 빠르다.
드디어 시작된 코드스테이츠에서의 마지막 프로젝트는 첫 프로젝트에서 느꼈던 아쉬움들을 개선해야겠다는 생각을 가진 채, 어떤 새로운 일들이 있을지 기대감에 부풀었다. 물론, 프로젝트 중후반에 접어들어서는 여전히 정신 없었다.
이번에는 첫 번째 프로젝트에 비해 상대적으로 충분한 기간이 주어진 만큼, 새롭고 흥미있는 기술을 사용하는 것을 목표로 했다. 그리고 저번 프로젝트에서 가장 아쉬움을 느꼈던 기획단계에서의 컨셉, 기능, 그리고 UX에 대한 논의를 충분히 진행하여 보다 완성도 있는 결과물을 내고자 했다. 구현할 기능의 우선순위를 명확하게 두어, UX의 질을 가급적 떨어뜨리지 않으면서 개발 과정에서도 차질이 안생기도록 하였다.
1. Logoyogo 개요
학부생 시절 과제를 특정 컨셉에 대한 과제물을 발표하다 보면 로고가 필요하곤 했다. 평소에 Photoshop을 비롯한 각종 편집 프로그램에 관심이 있어 직접 만들곤 했다. 로고를 만들기 위해 필요한 이미지, 폰트, 색상 조합을 선정하는 과정은 재미있었지만 괜찮은 결과물을 내려면 많은 시간을 투자해야 했다.
편집 프로그램에 관심이 많고, 만드는 것을 좋아하는 사람이라면 그 과정이 그저 즐거울지도 모르겠다. 하지만, 대부분의 사람들은 이러한 이미지 편집 프로그램을 능숙하게 다루지 못한다. 어디서 필요한 벡터 이미지와 폰트, 색상 조합을 구해야 할지도 막막할 것이다.
프로젝트 Logoyogo는 이러한 불편함을 해소하자는 의견에서 출발했다. 편집 프로그램을 잘 다루지 못하는 사람을 대상으로 쉽고 간단하게 양질의 로고를 제공하고, 필요하다면 간편하게 로고를 수정할 수 있는 서비스를 만들고자 했다.
2. 프론트엔드에서 적용한 기술스택
이번 프로젝트에서는 HTML5 캔버스를 활용한 로고 에디터가 핵심이었다. 백엔드 파트를 경험하고 싶은 욕심도 있었지만, 새로운 기술스택의 적용과 완성도 있는 결과물아라는 두 마리 토끼를 잡고 싶었다. 그래서 이번 프로젝트에서도 프론트 엔드를 맡아 진행하였다.
프론트 엔드에서 사용한 주요 기술스택과 이유를 이야기하고자 한다.
1. FabricJS
HTML Canvas 라이브러리에는 PixiJS, Konva, FabricJS 등이 있다. 이 중에서 사용하기로 결정한 라이브러리는 FabricJS로 이유는 아래와 같다.
- 4주라는 정해진 기한 안에 요구하는 기능들을 구현해야 했다. 따라서, 필요한 메서드들이 잘 갖추어져 개발에 차질이 없는 라이브러리를 선택하고자 하였다. FabricJS에서는 마우스를 이용한 객체 선택 및 크기 조절 액션은 기본적으로 제공한다. 또한, 캔버스와 오브젝트를 간편하게 JSON객체로 변환하거나 역으로 파싱할 수 있다.
- FabricJS는 객체 지향 라이브러리이다. 캔버스와 오브젝트를 클래스 형태로 제공한다. 이는 캔버스와 오브젝트를 클래스 단위로 커스터마이징하거나 관리할 수 있도록 한다.
- 공식문서의 예제, Docs가 잘 정리되어 있고, 라이브러리에 대한 유용한 정보와 예제를 구하기 용이하다.
- React와 FabricJS를 함께 사용하는데 치명적인 문제가 없다.
2. TypeScript
- 변수를 정적 타입으로 관리하여, 타입 불일치로 인한 오류들을 VSCode에서 바로 확인하고 해결할 수 있다.
- VSCode에서 제공하는 자동완성 기능으로 능률을 높일 수 있다. 특히, 경로가 다른 스크립트의 함수와 변수를 불러올 때 편리하다.
- 함수 및 변수에 대한 기능을 팀원과 명확하게 공유할 수 있다. 어떤 기능을 하는지, 어떤 변수를 받아야하는지를 타입을 확인하여 명확하게 이해할 수 있다.
3. React
- 각 페이지와 구성요소를 컴포넌트 단위로 구성하여 설계할 수 있으며, 재사용이 가능하다. 모달창에 적용하였다.
- React Router를 사용하여 페이지 간 관계와 흐름을 명료하게 할 수 있다.
- Hooks의 useEffect를 사용하면 라이프 사이클에 따라 원하는 액션을 특정 상태의 변화에 따라 실행시킬 수 있다.
4. Redux
- 상태를 전역으로 관리할 수 있다. 로그인, 모달창 상태 관리에 사용하였다.
- 상태를 드릴링으로 필요한 컴포넌트까지 전달하지 않더라도 접근할 수 있다.
5. Sass
- Sass에서 CSS 코드 작업을 HTML 구조와 유사하게 작업할 수 있다. 코드 구조의 직관성을 높일 수 있어 유용하였다.
- 변수를 특정 파일에 관리하여 CSS 스타일을 손쉽게 관리할 수 있다. 가령 특정 폰트의 색상 또는 크기를 변경하고자 하면, 해당 변수의 값만 변경하면 된다.
- & 선택자를 사용하면 스타일을 구조적으로 잘 정리할 수 있다.
3. 프로젝트의 주요기능
3. 1. 랜딩 페이지
랜딩 페이지에서는 어떤 서비스를 제공하고, 어떻게 사용하는지를 중점적으로 풀어내고자 하였다. 좋은 랜딩 페이지는 필요한 정보를 간결하고 명료하게 전달하면서, 사용자의 이목을 끌어야 한다고 생각한다. 개인적인 욕심으로는 스크롤 위치에 따른 CSS 애니메이션을 만들어보고 싶었지만, 일정 문제로 에디터 설명 항목에 포인트를 주는 것으로 정리하였다.
3. 2. 로고 요소 선택 페이지, 탬플릿 페이지
로고 제작은 최대한 쉽게 사용하되, 사용자가 원하면 커스터마이징을 할 수 있도록 계획했다. 사용자가 로고에 들어갈 요소를 하나 씩 선택하여 로고를 만들거나, 기존에 만들어진 탬플릿을 선택하여 로고를 만들 수 있도록 하였다. 뭔가 부족하다면, 에디터에서 수정할 수 있다.
로고 요소 선택 페이지에서는 도형, 색상, 배치를 선택할 수 있다. 로고에 사용하는 도형은 SVG 벡터 도형을 사용하였고, 해당 도형을 선택할 경우 에디터에서 도형에 대한 SVG Path값을 불러오도록 로직을 작성하였다.
로고 배치는 캔버스, 도형, 텍스트 상자의 높이, 폭을 계산하여 결정하도록 로직을 작성했다. 여기서 텍스트 상자의 폰트를 특정 값으로 설정하면 폰트 타입마다 폭이 바뀌는 문제가 발생했다. 캔버스 상에 텍스트 상자기 제대로 출력이 되지 않고, 위치 계산도 제대로 되지 않는 치명적인 문제였다. 이를 FabricJS의 ClearCache() 메소드를 사용하여, 폰트를 변경할 때마다 텍스트 상자의 폭을 다시 계산하도록 하여 해결할 수 있었다.
한편, 로고 탬플릿 선택 페이지는 FabricJS가 캔버스를 JSON으로 저장할 수 있다는 것을 활용하였다. 특정 탬플릿을 선택하면, 탬플릿에 해당하는 인덱스의 Canvas JSON 데이터를 에디터 컴포넌트로 전달하였다.
개인적으로 아쉬움이 많이 남는 파트이다. 우선 UX측면에서 사용자가 만족하는 로고를 만들려고 했다면, 선택페이지에서 선택 요소에 대한 결과물을 바로 확인할 수 있도록 만들어야 했다. 또한, 로고에 중요한 폰트에 대한 선택 기능도 추가되어야 했다.
또한 탬플릿 페이지의 경우 서버와 통신하여 ‘사용자가 저장한 로고 템플릿’을 출력하는 것으로 제공하고자 하였지만, 실제로 완벽하게 구현하지 못했다. 그리고 사용자가 원하는 로고를 쉽게 찾을 수 있도록 검색기능을 추가해야 했고, 필요한 로고를 스크롤 위치에 따라 서버에 요청하도록 해야했다. 디테일에서 놓친 부분이 굉장히 많은 파트였다.
3. 3. 에디터 페이지
로고 에디터 페이지에서는 탬플릿에서 선택한 로고나, 여러 요소를 조합하여 나온 로고를 수정할 수 있도록 하였다. 기본적으로 제공하는 기능은 ‘컬러 팔레트’, ‘텍스트’, ‘도형’, ‘클립아트’, ‘배경’이다. 사용자층이 디자인에 대한 감각이나 지식이 깊지 않다고 생각하고, 특정 요소를 선택하거나 검색하는 것만으로도 손쉽게 만들 수 있도록 하였다. 컬러 팔레트 탭은 마음에 드는 팔레트를 선택하면 캔버스 상의 요소들을 팔레트에 맞추어 바꾸어준다. 클립아트 탭은 외부 API로부터 원하는 벡터 그림을 가져올 수 있다.
FabricJS 라이브러리를 처음 사용하다보니 여러모로 고생했던 파트였다.
3. 4. 모달창 - 로그인, 회원가입 페이지
첫 프로젝트에서는 단순히 로그인, 회원가입 기능을 구현하고 에러 메시지를 하단에 출력하는 정도로 구현했었다. 이번 프로젝트에서는 각 항목의 유효성 검사를 실시간으로 확인하여, 사용자가 보다 쉽게 해당 기능을 이용할 수 있도록 만들었다.
모달창의 활성화 여부와 종류는 Redux의 전역상태로 관리하였다. 에디터 페이지의 Preview도 동일하다.
3. 5. 일반, 반응형 디자인
PC, 태블릿, 모바일에서 서비스를 이용할 수 있도록 했다. 미디어 쿼리를 사용하여 모바일에 중점을 두어 작업을 하였고, 특정 페이지의 경우 Section의 좌우 Padding으로 컨텐츠가 뭉개지지 않도록 1200px 구간을 별도로 작업하였다. 그리고 이전 프로젝트에서는 거의 사용하지 않았던 min-width를 적용하여 랜딩페이지의 특정 컨테이너가 지나치게 작아지는 문제가 발생하지 않도록 했다.
미디어 쿼리에서 !important를 지나치게 많이 사용했다는 아쉬움이 있다.
4. 마무리
4. 1. 잘했던 점
-
새로운 것에 적극적으로 도전해보는 자세. 저번 프로젝트의 Carousel, Drag and Drop과 달리 FabricJS는 한국어로 된 포스트를 정말 찾아보기 힘들다. 전적으로 영문으로 된 공식문서, StackOverFlow, 공식 GitHub 등에만 의존해야 하는 상황이었다. 그럼에도 차근차근 React로 FabricJS를 적용하는 것부터 시작하여 필요한 기능 구현과 에러 핸들링까지 해낼 수 있었다. 앞으로 배우고 싶은, 그리고 배워나가야 할 새로운 기술 스택들을 만나도 해낼 수 있을 거라는 확신이 든다.
-
사용자의 관점에서 PC, 모바일 환경을 테스트하고 지속적으로 피드백을 주고 받는 것. 개발에 몰입하다보면 단순히 ‘기능구현’을 목표로 하여 UX의 질을 낮추기도 한다. 첫 프로젝트에서 뼈저리게 느꼈던 문제이기도 했었다. 이를 자발적으로 PC, 모바일 등 여러 환경에서 사용해보면서 어떤 점이 아쉬웠는지 공유하는 과정으로 많이 해소할 수 있었다.
-
Task 카드의 세분화와 BugFix 및 Error Handling 카드 관리. Task 카드를 계획, 개발, 배포 단계마다 세분화하여 관리하였고, 덕분에 정해진 일정동안 요구하는 최소한의 기능을 구현할 수 있었다. 그리고, BugFix와 Error Hadnling 카드를 작성하여 원인, 진행현황, 해결방안 등을 팀원과 상세히 공유할 수 있었다.
4. 2. 부족했던 점
-
업무분담과 팀 전반에 대한 인적관리의 미흡. 오늘 어떤 작업을 했는지, 앞으로 어떤 작업을 해야 할지에 대해 명확하게 이야기되지 않다보니 작업의 비중이 한 쪽으로 지나치게 쏠려버렸다. 이 부분은 개인의 의지 문제도 있겠지만, 그런 환경에서도 최선의 결과를 낼 수 있도록 협의하여 더 나은 방법을 제시해야 했다.
-
다시금, 롱런을 하지 못한 것. 스케줄 및 체력관리를 하여 번아웃이 오지 않도록 해야 했는데, 이번에도 마지막 주에는 번아웃으로 2~3일 정도는 운동과 코드 작업을 제대로 하지 못했다. 종종 프로젝트의 결과물에 아쉬움을 느끼고 평일, 주말 안가리고 밀어붙이는게 문제가 되었던 것 같다. 회고를 작성하는 지금은 다시 운동을 병행하고 있지만, 여가시간을 활용하여 체력과 스트레스 관리를 어떻게 할지 더 생각을 해봐야겠다.
-
클린 코드에 대한 노력의 부족. 종종 정해진 기한 안에 기능을 구현해야 한다는 생각에 ‘다른 사람이 보기 쉬운, 재사용이 가능한 코드’를 작성해야 한다는 것을 망각한다. 서비스는 확장과 유지보수가 원활하도록 만들어져야 한다. SCSS와 에디터 컴포넌트에서 많은 아쉬움을 느꼈다.
Leave a comment