#1. Gulp 로 퍼블리싱 개발환경 만들기 - 입문

오늘은 퍼블리싱 개발환경에 대해서 이야기 해보려고 한다. 사실 프론트앤드 개발환경도 아니고 "퍼블리싱(Publishing) 개발환경이라는 것을 만들 필요가 있는가?"에 대해서 이야기 하기 전에 몇가지 용어정리를 하려고 한다.

 

프론트 앤드 개발 분야를 업무 특성으로 나누자면 HTML/CSS쪽과 Javascript쪽으로 분야를 나눠 볼수 있는데 HTML/CSS를 전문으로 작업하는 것을 "퍼블리싱", 거기에 Javascript를 코딩하는 것을 "UI 개발"로 용어를 정리하도록 하겠다.

그리고 오늘부터 약 3~5개 정도의 포스트를  퍼블리싱 관련 개발환경을 만드는 내용을 소개해 볼까 한다.

 

여기서 "퍼블리싱을 하는데도 개발환경이 필요한가요?" 라는 질문을 할 수도 있다. 그도 그럴 것이 예전엔 그냥 HTML 문서를 로컬환경에서 그냥 만들고 브라우저에 HTML파일을 던져 넣으면 코딩 결과를 바로 확인 할 수 있었는데 괜한 작업환경 셋팅때문에 시간만 잡아먹는 것이 아닌가 하고 말이다.

 

하지만 내 대답은 "당연히 개발환경은 필요하다."라고 말해주고 싶다.

필요없으면 내가 왜 이런 글을 쓰고 있겠어??

최근의 퍼블리싱 동향을 살펴보면 EJS라던지, PUG라던지 하는 HTML 템플릿 환경이라던가 SCSS, SASS와 같은 전처리 스타일시트 같은 것들이 점점 자리를 잡아가고 있다. 왜냐하면 코딩의 효율성을 올리고 반복작업을 최소화하여 효율을 올리기 위해서다.

하지만 이런 환경을 도입하는데 있어서 가장 큰 문제는 과거의 방식과는 다르게 브라우저에서 바로 결과를 확인할 수 없다는데 있다. 코딩의 결과를 확인하기 위해서는 매번 컴파일 과정을 거쳐야고 이런 컴파일 과정이 쌓이면 생각보다 꽤 오랜 시간을 잡아먹는 작업이 된다. 결국 이런 과정들은 업무의 효율을 떨어뜨리는 나쁜 작업환경이 된다. 결국 업무 효율을 높이기 위해 도입한 기술들이 오히려 시간을 잡아먹는, "언 발에 오줌누는" 작업밖에 안되는 아이러니를 갖게 된다.

그래서 나는 컴파일을 자동화하고 알아서 소스코드들을 정리하고 소스코드의 변경을 감지하여 자동으로 재 배포해서 브라우저를 자동으로 새로고침해주는 자동화툴을 도입하여 작업의 효율을 높이고 조금 더 스마트하게 개발환경을 만드는 작업을 진행하려고 한다.

 

우리는 아래의 목적에 맞게 툴을 선택하고 셋팅하려고 한다.

 

• SCSS 전처리 스타일시트를 도입한다.
• 로컬 웹서버를 통해 작업 결과를 확인할 수 있어야한다.
• 코드가 수정되거나 파일이 변경 및 추가되면 자동으로 컴파일을 진행하여 브라우저에 반영되어야한다.
• 이미지 파일의 최적화 과정이 필요하다.(용량을 줄여준다)
• EJS나 PUG를 도입할 것인가에 대한 것은 프로젝트 성격에 따라 다르니 이번 포스트에선 그냥 HTML로 작업하는 것으로 하자.

위의 다섯가지 목적에 맞는 것으로 자동화 툴을 찾다가 Webpack이랑 Gulp 두가지 중 하나를 적용해야겠다 싶어서 테스트를 해봤는데 Webpack은 "퍼블리싱"작업만 하기에는 애매한게 "퍼블리싱"작업은 프론트 앤드 개발의 효율을 위해서 HTML / CSS 작업을 선 작업한뒤 전달하는 과정인데 파일을 막 압축해버리고 여러 파일을 하나로 뭉쳐버리면 이후 작업자가 손을 대기에 무리가 있을것으로 생각이 들었다. 그래서 Gulp를 이용해 환경을 만들어봐야겠다 생각을 했다.

(뭐, Webpack도 잘 셋팅하면 Gulp와 다르지 않게 작업할 수 있다고 들었으니 나중에 Webpack으로 환경을 다시 만들어봐야겠다.)

 

일단 Gulp로 개발환경을 셋팅하기 위해서는 몇가지 준비물이 필요한데 그것은 Node.js다. Node.js는 링크를 붙여줄테니 가서 다운로드하고 설치하고 돌아오기 바란다. (https://nodejs.org/ko/)

아참, 무조건 최신소스가 좋다고 "최신기능"이라는 버튼을 눌러 다운로드 받지 마라. 그건 Nightly 버전이라고 안정화가 안된 버전이라 이상동작할 때가 많다. "안정적, 신뢰도 높음" 버튼을 눌러 다운로드 받아라. 제발.

 

Node.js 설치와 관련된 내용은 https://blog.thereis.xyz/13?category=713655 여기를 참고하자. 

 

자, 퍼블리싱을 위한 개발환경 셋팅을 위한 준비작업은 마쳤다.

이제 서론은 여기까지 하고 다음 포스트 부터 즐겁게 작업을 진행해보자.

 

본론은 여기서 끝!

잠깐 잡소리를 덧 붙이자면,

 

이번 포스트가 짧은 이유는, 일단 글이 너무 많은데다 전통적인 방식의 퍼블리싱과 최근의 퍼블리싱 개발환경에 대한 썰을 푸느라 글을 쓰고 지우고 쓰고 지우고를 이틀내내 했더니 더이상 글이 안 써져서 어쩔 수가 없었다. 여태까지 포스팅 했던 글 중에서 이정도로 고민을 하면서 쓴 포스팅이 별로 없었는데 글이란 것은 참으로 어려운 것 같다.

 

사실 이번 글에서 가장 고민이 되었던 질문이 "퍼블리셔도 개발자인가?"라는 질문인데 이게 참 애매한 부분이 있다. HTML/CSS를 "개발"의 범주에 넣을 것인가 말 것인가에 대한 생각이다. 이것에 대해서 나는 아직 결론을 내리지 못한 주제로 퍼블리셔 직군에 있는 사람들이 혹시라도 오해하여 개발자 우월주의처럼 보이지는 않을까 하면서 고민했다.

 

혹시라도 내 의도와는 다르게 비춰지는 것이 아닐까 고민이 되었고 그래서 이 짧은 포스팅은 무려 이틀동안이나 고민을 하게 만들었다. 사실 개발(開發)의 의미가 "무언가를 만들어낸다"는 의미로 접근을 하면 퍼블리셔도 개발자의 범주에 속할 수 있으나 IT에서의 개발은 관용적으로 컴퓨터 언어를 이용해 프로그램을 만드는 작업이라는 의미로 접근하면 엄밀하게 HTML/CSS는 그 범위 바깥에 있다고 보여지기 때문이다. 물론 HTML도 마크업 언어로 컴퓨터 언어라고 볼 수 있으나 기본적으로 조건문, 반복문, 함수와 같은 공학적 요소가 없어서 흔히 이해하는 프로그래밍과는 거리가 있다고 생각할 수도 있기 때문이다. 어떤 시각으로 문제를 바라보느냐에 따라 대답은 다를 수 있고 이것을 갖고 얼마든지 밤새도록 안주삼아 떠들 수 있지만 결국 이것은 개인의 문제로 남기고 스스로가 생각해 답을 내려야겠다고 생각했다.

 

하지만 나는 아직 이 문제에 답을 내리지 못했다.