퍼블리싱 가이드를 만들며

드디어 숙원 과제 하나가 끝났다.

회사의 퍼블리싱 가이드를 만드는 것이다.

 

원래는 홈페이지 리뉴얼 작업을 하면서 하나하나 다듬어 나가려고 했지만,

몇달째 디자이너가 공석인 관계로 리뉴얼이 무산이 되었기 때문에

기존 홈페이지의 퍼블리싱 가이드를 만들게 되었다.

 

사용 언어는 간략하게 html, css, jQuery 이다. 바닐라 자바스크립트였다면 훨씬 좋았겠지만, 가장 손에 익어서 효율적이라고 생각했기 때문에 제이쿼리를 사용 했다. 게다가, 후임자가 아니면 볼 사람도 없는 순수하게 내부 소통용도의 문서이기 때문에 최대한 빠르고 간결하게 만드는 것이 우선이라고 생각했다.

 

작성 기간은 대략 3~4주 정도 걸린 것 같다.

어려워서가 아니라, 어떤 구성으로 만들어야 할지 고민이되었기 때문이다.

ui의 디자인 없이 원래 홈페이지의 디자인 컨셉을 따다가 붙이는 것도 조금 골치 아팠다.

 

누가 시킨일도 아니고, 꼭 필요한 일도 아닌..

회사입장에서는 계륵과도 같은 일이지만 굳이 홀로 작업을 한 이유는 다음과 같은 장점이 있기 때문이다.

 

퍼블리싱 가이드를 작성하는 것의 장점

1. 신입이 회사 홈페이지를 뜯어보며 공부하기에 좋다.

  나는 7개월차의 신입이다. 그리고, 퍼블리싱 작성 가이드는 입사 3달차부터 계획 했던 것이다. 그때의 나는 자주 수정이 요구되는 파일이 아니면 어떤 위치에 어떤 파일이 있는지 잘 몰랐었다. (내가 입사하기 전의)리뉴얼 이전과 이후 폴더가 어떻가 나뉘는지, 리뉴얼 이전의 파일들중에서 현재에도 쓰임이 있는 파일들이 있는지 등등을 파악하기 어려웠다. 

 

그래서 가장 먼저 작성 했던 내용이 프로젝트 환경을 요약한 내용과 폴더/및 파일의 위치였다.

쓰면서 하는 공부는 썩 좋아하지 않지만, 확실히 정리를 해놓으니 전체적인 구조를 알아보기에 편리했다.

 

이제 더이상 00씨 어디 페이지 뭐 고쳐줘~ 하실 때 '네?!' 하지 않아도 된다.ㅎㅎ

 

또, 전임자가 작성한 html 구조를 살펴본다던지, class나 id 이름등을 살펴보면서 규칙성을 발견하기도 좋다. css적용 내용이나 jquery 코드도 뜯어보면서 어떻게 구축하고 유지보수를 해왔는지에 대한 흔적도 살펴 볼 수 있었다.(swiper 라이브러리에 jquery를 덧대어 사용 했다던지..)  그 말은 앞으로 유지보수를 해나가는 데에 있어 방향성을 잡을 수 있다는 말과 같다. 예를 들어, 우리 회사는 각 페이지별로 css와 jquery가 중복되는 부분이 있었는데 이런 부분을 공통 css문서로 묶어야 겠다는 생각을 하게 되었다. 

 

2. API와 라이브러리의 간단한 활용 방법을 알아보기에 좋다.

 아직 API를 직접 가져다가 사용해 본 적이 없다. 연습용으로 datepicker나 지도 같은것들을 가져다 붙여봤을 뿐이다. 이번 기회에 우리 회사 홈페이지에 가져다 쓴 API 들이 어떤 것들이 있는지 직접 확인을 하고, 어떤 과정을 거쳐 사용했는지 살펴보았다. 또, 가져온 뒤에 어떻게 디자인을 가공하여 쓰는지도 확인 했다.

 

사실, 날씨 API나 영화 API처럼 데이터를 잔뜩 끌어오는 형태가 아니었기 때문에 key 값을 받아다가 코드를 그대로 입력하고, 디자인만 다듬어서 쓰면 되는 형태였기 때문에 크게 어려울 것은 없었다. 

하지만 상담 챗봇을 활용 할 때에 내담자의 정보를 가져오는 과정이라던가, 관련 코드를 어떻게 짰고 어디에 저장이 되어있는지까지는 확인을 할 수 있었다. 이 부분은 아마도 전 퍼블리셔가 아니라 백엔드 개발자님께서 짜신 코드 같았다. 

 

어려웠던 점

1. 목차설정

어떤 내용을 넣어야 할지, 어떻게 페이지를 나눠야 할지 정하는 것이 가장 어려웠다. 가이드라고는 하는데, 누구를 위해서 무엇을 가이드 해야하는지도 명확하지 않았다. 단순히 내가 공부하려고 만든 것이 1차적인 목적이라고 하더라도, 내부적인 소통에 쓰일 수 있기 때문에 필요한 내용들을 간결하게 집어넣는 것이 중요 했다.

 어떤 내용을 넣는지는 곧 퍼블리싱 가이드의 페이지를 나누는 데에도 중요한 근거가 되었다. 말하고 싶은 내용을 어떻게 카테고리화 하여 보여줄 것인지, 목차의 순서를 어떻게 잡아야 보는사람으로 하여금 이해가 빠를지를 생각해야 했다. 생각해보니 나름의 기획이 아니었던가 싶다. 

 

 결국, 있지도 않은 가상의 후임을 설정해서 '우리 회사 퍼블리싱 가이드 있으니 보면서 공부하고 있으세요~'라고 할 수 있을 정도의 수준으로 만들기로 결정 했다.

 

또, 가이드 내용중에 민감한 내용은 무엇인지를 파악하는 것도 어려웠다. 예를 들면, 폴더 구조의 경우 그냥 단순히 위치를 안내하는 것이라고 생각할 수 있지만 내부적으로 중요한 파일이나 API관련 내용들이 포함되어 있기 때문에 포함해도 되는 것인지 모호한 경우가 많았다. 아주 민감한 값이나 코드들은 생략하도록 했고, 완성된 퍼블리싱 가이드를 내부적으로'만' 가지고 있기로 백엔드 담당자님과 결론 내렸다.

 

2. ui를 어디까지 만들어놔야 좋을까?

어렵다기보다 제일 귀찮은 부분이었다. 헤더와 푸터는 어떻게 할지, lnb나 aside는 어떤 모양으로 존재하며, 어떤 인터랙션이 들어가야 할지를 고민해야 했다. 이렇게까지 할 건 아니었는데도 괜시리 '후임이 볼건데(?) 이정도는 해야지!' 라는 생각이 들어 계속 고치고 또 고쳤던 것 같다. 피그마를 사용해서 짜깁기를 하려고 하기도 했었다.

 

그런데 문제는.

내가 디자인 감각이 1도 없다는 것이다.

하면할수록 미궁으로 빠졌다.

 

그래서 그냥 기존 홈페이지의 ui디자인을 본따서 만들기로 했다. 메인 컬러, 폰트 사이즈, 포인트 주는 방법, 본문의 구조 까지 되도록 기존 디자인 가이드를 따르기로 했다. ui와 관련된 코드 작성은 의외로 쉬웠다. 이곳을 클릭하면 저곳에 클래스가 붙을것이고, 이 페이지인 것을 확인하면 저곳에 클래스가 붙으면 되겠다는 논리적인(?) 감각만 있으면 되었기 때문이다.  내게는 jqeury코드를 어떻게 짜는가보다, 이 곳의 글자 크기와 색상을 어떻게 정해서 어떻게 보기좋게 배치할 것인가가 더 어려운 문제였다. 

 

 

3. 디자이너 없는 스타일가이드

 그렇다. 우리회사에는 디자이너가 없다. 현재 몇달 째 공석인 상황이다. 아마 대강 만든 샘플용 템플릿을 디자이너에게 보여줘가며 이정도면 나쁘지 않겠죠? 라고 컨펌을 받았다면 조금 더 수월하게 진행되었을 수도 있다. 그래도 디자이너가 없었던 덕에 이것은 퍼블리싱 가이드니까, 내맘대로 해도 괜찮겠지. 디자인 퀄리티가 떨어져도 괜찮겠지 라며 자위할 수 있었다. 

 

진짜 문제는 컴포넌트 및 디자인 스타일에 관련한 내용을 작성할 때 발생했다.

디자이너가 어떤 의도를 가지고, 어떤 체계를 잡아서 디자인 했는지 확인할 길이 없으니

폰트 사이즈며, 제목과 본문의 단계, 글자 굵기, 각 페이지별로 적용된 메인 컬러나 포인트 컬러 등등을 하나하나 확인해서 나혼자 체계화를 해야 했던 것이다.

 

아하.. 이 부분은 h2가 들어가는군. 여기서부터는 h3군. 아니, 여기는 강조인데 이 컬러로..???

똑같은 본문인데 여기는 14px인데 저기는 15px이잖아..? 왜지? 다른데 또 이런식으로 적용된게 있나? 규칙성이 있는 건가? 예외적인 부분인가? 혼자서 질문을 던지고 혼자서 대답을 받아내며 작성 했다. 그래서인지 디자인 관련된 부분은 아주아주 빈약하다. 이걸 진짜 넣어도 되나 싶을정도로 빈약하다..ㅎ

 

생각해보건대, 정말로 후임이 생긴다면 디자이너가 온 이후에 들어왔으면 좋겠다. 

그리고 개발을 열심히 배워서 프론트엔드로 빨리 전향해야겠다. 

 

 

참고자료

퍼블리싱 가이드에 어떤 내용이 들어가야 하는지 몰라 헤맬 무렵에 참고했던 자료들이다.

- 퍼블리싱 가이드 레퍼런스 (교보문고)

http://image.kyobobook.co.kr/ink/html/guide/index.html

교보문고 웹퍼블리싱 가이드

퍼블리싱가이드계의 바이블과도 같다. 물론, 퍼블리싱가이드에 관련된 자료가 많지 않은 탓이기도 하다.

하지만 어떤 내용이 들어가야 하는지, 어떻게 구조화 해야할지, 어떤 ui를 넣어야 할지 등등의 기준이 되어준 고마운 자료이기도 하다. 

 

- js 코딩컨벤션(구글, w3school, 에어비앤비, 네이버)

https://www.w3schools.com/js/js_conventions.asp

JavaScript Style Guide

https://google.github.io/styleguide/jsguide.html

Google JavaScript Style Guide

https://github.com/ParkSB/javascript-style-guide#%ED%98%B8%EC%9D%B4%EC%8A%A4%ED%8C%85-hoisting

GitHub - parksb/javascript-style-guide: Airbnb JavaScript 스타일 가이드

https://github.com/naver/eslint-config-naver/blob/master/STYLE_GUIDE.md

GitHub - naver/eslint-config-naver: Naver JavaScript Coding Conventions rules for eslint

문법적인 부분은 w3school과 google의 도움을 받았다. 활용적인 부분에 대해서는 에어비엔비와 네이버의 가이드를 참고했다. 네이버도 에어비엔비의 가이드를 참고했다고 하는데, 정리가 정말 잘 되어있는 것 만큼은 확실해 보인다. 

다만, 우리 회사 퍼블리싱 가이드에는 참고했던 만큼의 내용이 들어가지는 않았다. jQuery를 주로 활용하기 때문이다.

 

그럼에도 JS코딩 컨벤션을 찾아보았던 이유는 다음 리뉴얼 때 JS로 변경할 계획이 (혼자)있기 때문이다. 

안되면 어쩔 수 없지뭐.

기초공부 열심히 했다 치겠다.

 

 

느낀점

1. 헤더, 푸터, ui 정도는 직접 만들어 쓰는 연습을 하자.

무슨말이냐면, 기존 홈페이지 디자인을 그대로 가져다 쓴다고 해서 코드 자체를 베껴오지 말자는 뜻이다. 어차피 공부목적으로 만드는 가이드이기 때문에 그냥 갖다 붙이는 것은 의미가 없다고 생각했다. 퍼블리싱도 다 스스로 해보아야 진짜 공부가 된다고 생각했다. 덕분에 swiper 라이브러리를 가져다 쓰면서 어떻게 보완을 하는지 배우기도 했고, ui 설계를 할 때 예외처리에 대한 고민을 해볼 수 있는 계기가 되기도 했다. 사실 이 부분이 제일 중요하다고 생각한다. css도 마찬가지이고, jqeury로 코드를 짤 때에도 마찬가지이다. 공통되는 부분과 그렇지 않은 부분을 설계당시에 고려해야 하는 능력도 필요 하며, 예외적인 부분을 조금이라도 미리 생각할 수 있다면 수정에수정에수정에수정을 거듭하는 일이 조금은 줄어들지 않을까 싶다. 

 

이런것도 문제 삼아서 해결해야하나? 하는 부분도 있었다.

 

예를 들면, 콘텐츠 섹션 별로 aside에 제목을 삽입해서 내비게이션 역할을 하게 했는데 섹션이 하나 뿐일 때에는 aside 가 꼭 있어야 하나?에 대한 고민이었다. 하단으로 섹션이 늘어질 경우를 생각해서 추가한 aside이니, 콘텐츠의 길이가 짧으면 굳이 있을 이유가 없었기 때문이다. 형식적으로라도 있어야 할지, 본질적인 역할에 충실해야 할지 홀로 고민을 했었다. 

 

 

2. 컴포넌트화, 코드의 재활용을 생각해보자.

다음 기회에 퍼블리싱 가이드를 작성할 기회가 또 있다면, 이 템플릿을 가져다가 수정해가면서 사용하면 좋겠다는 생각이 들었다. 또다시 디자인부터 구상(?)할 생각을 하니 너무나 골치 아팠기 때문이다. 그래서 웹컴포넌트로 작성을 하거나, 리액트, 뷰와 같은 프레임워크로 저장을 해둘까 한다.

 

3. 예외처리가 끝도 없다.

경험의 영역인 것 같다.

 

 

보완해야 할 점

예시

- aside 부분을 자동화 할 필요 있음. h3태그 내부에 있는 내용을 긁어서 자동입력 되게끔 하고싶다. 섹션이 추가될 때마다 html태그를 하나하나 작성하려니 조금 귀찮기도 하고... 

- 콘텐츠 길이가 짧으면 aside 부분에 on이 안붙는 현상.