Vue프로젝트에 적합한 퍼블리싱이란?
퍼블리싱된 파일을 vue에 적용하는 작업을 수월하게 하기 위해 퍼블리싱 단계에서 할 수 있는 일은 두가지가 있다.
- vue프로젝트의 폴더구조를 고려해 static file들을 배치한다.
- 사용하기로 협의된 디자인 프레임워크를 cdn방식으로 적극 활용한다.
퍼블리싱 단계에서 파일들을 관리하는 방법은 여러가지가 있는데 퍼블리싱하기 편한 폴더구조일수록 프로젝트에 이식하기 어려운 구조일 가능성이 다분하다. 예를들어 시안을 보고 작업한다고 할 경우 아래와 같이 폴더구조를 작성할 수 있다.
index.html
public/
design/
201011.psd
imgs/
dummy.png
css/
common.css
main.css
sub.css
lib/
framework.min.js
framework.min.css이렇게 구조를 작성할 경우 퍼블리싱 단계에서는 시안과 assets, library를 public폴더 하나에서 관리할 수 있어서 편리하겠지만, 이를 전부 프로젝트 폴더 구조에 맞춰 분리해야 하는 프론트엔드 개발단계에서는 좋아하지 않을것이다.
css를 예로 들자면 sass도 사용하지 않고, 컴포넌트 별 css파일 분리도 하지 않고 코드를 작성했을 경우 프론트엔드측 에서는 꽤나 까다로워진다. 시안에 맞춰 퍼블리싱만 해도 되는것과는 다르게 웹사이트가 원활하게 작동하도록 유지해야하는 최적화 단계에서 분리되지 않은 컴포넌트 css의 경우에는 필요하지 않은 컴포넌트의 css까지 매번 같이 불러와야 하기 때문에 속도가 느려진다. 그리고 sass등을 사용하지 않으면 자주 사용되는 메인색상등을 하나씩 찾아 바꿔주어야 하며 간단한 상속등의 작업도 하지 못하게 된다. 물론 색상코드를 찾아 수작업으로 변경하는것이 어려운 일은 아니지만 굳이 하지 않아도 되는 작업 하나하나가 쌓여 프론트 개발단에게 부담으로 돌아간다.
그리고 이런구조의 폴더구조는 vue프로젝트의 폴더구조와는 꽤나 다르다. 아래는 Nuxt.js 프로젝트의 폴더구조를 일부 발췌한것이다.
.editorconfig
nuxt.config.js
package.json
package-lock.json
assets/
css/
main.css
sub.css
mobile/
main.css
sub.css
scss/
common.scss
colors.scss
ui/
divider.scss
pagination.scss
menuList.scss
components/
Divider.vue
Pagination.vue
MenuList.vue
Pages/
Main.vue
Sub.vue한눈에 보더라도 기존의 폴더구조와는 달라보인다. 일단 public대신 assets이란 명칭의 폴더명을 사용하고 있으며 내부에서도 css, mobile, scss, colors.css등의 세분화된 구조로 분리해야 한다. 이런 작업을 프론트엔드단에서 해야하는 것도 문제지만, 더 큰 문제는 추가 페이지가 발생했을 경우이다.
퍼블리싱측 입장에서는 기존 구조에서 추가된 페이지만 있는 버전으로 업데이트해서 작업해도 되지만, 프론트단에서는 퍼블리싱단에서 이미 한번 전달받은 파일들을 세분화시켜 개발중에 있기 때문에 changed list를 보고 어떤 부분이 바뀌어었는지 하나하나 파악해가며 프로젝트를 업데이트해야 한다. 이런 작업이 많아질수록 개발속도는 저하되며 개발자의 모티베이션또한 떨어지게 된다.
두번째로는 디자인 프레임워크의 활용이다. input form이나 modal등의 기능은 직접 구현하는데는 무리가 있기 때문에 vuetify나 element등의 디자인 프레임워크를 활용하는데, 퍼블리싱단에서는 이를 적용하지 않고 개발하는 경우가 종종 있다. 어짜피 vue에서 적용할거 굳이 퍼블리싱단계에서부터 cdn써가며 복잡하게 작업해놓아야 하나? 라는 생각을 할수도 있겠지만 이는 틀린 생각이다.
기획했던 서비스를 디자인 단계, 퍼블리싱 단계, 프론트엔드 개발 단계에서 프로덕트를 직접 눈으로 확인할때 생각보다 큰 차이가 존재한다. 시안에서는 보지 못했던 미묘한 유격이나 디테일등이 퍼블리싱 단계에서 보이기도 하고, 실제로 디자인 프레임워크를 프론트 개발 단계에서 적용해놓고 보니 웹의 전체적인 느낌 자체가 달라지는 경우가 있다. 단계마다 발생하는 이러한 차이들은 뒤로갈수록 더욱 커지며 결국에는 처음에 기획했던것과 제품의 느낌이 달라져 디자인 변경이나 구조 변경등의 이슈가 발생하게 된다. 물론 이러한 개선점이 생기는것이 꼭 부정적인 것은 아니지는 않지만 최소한 퍼블리싱->프론트 과정에서 만큼이라도 동일한 프레임워크를 사용해 기획과의 괴리감을 줄여야 한다.
협업의 자세
서비스 제작은 혼자하는것이 아니다. 디자인, 퍼블리싱, 프론트, 백엔드, 서버, 운영등의 파트가 협력해 작업하는 다인 협동 프로젝트이다. 그러므로 자신의 시야에 보이는 방법대로만 일하는것이 아니라 다른 파트와의 소통과 협력을 통해 더욱 효율성높고 유기적인 협업 환경을 만드려는 노력이 필요하며 이는 자신의 성장뿐 아니라 조직 전체의 성장으로 이어질 것이다.