리액트 퍼블리셔 가이드 1편 - 웹 퍼블리셔란? 리액트 퍼블리셔 로드맵

시작

안녕하세요. 이 글은 퍼블리셔 초심자 분들을 위한 가이드입니다.
해당 글은 로드맵에 관련된 글로 전체 맥락을 파악하기 위해 자세하거나 세세한 글은 어느정도 생략이 되었습니다.
리액트 퍼블리셔는 어떤 과정을 통해 될 수 있는 것인지 대략적인 과정을 나타낸 글입니다.
이 글이 도움이 될 수 있길 바라며, 행복한 코딩 하세요!

1. 웹 퍼블리셔란?

1-1 웹 퍼블리셔 소개

퍼블리싱을 직역하면 출판입니다.
발행 배포한다는 의미인데, 서점에서 완성된 책을 낸다는 느낌보다는,
개발의 첫 코드를 작성해서 개발자들이 쓸 수 있는 코드를 만든다는 느낌에 가깝습니다.
즉 개발자들이 쓰는 UI 코드 소스를 만든다고 볼 수 있습니다.

이러한 퍼블리셔의 주업무는
디자인된 이미지를 코드로 바꿔주는 작업으로 ‘디자인적인 코딩’을 주업무로 합니다.
디자인적 지식과 개발 지식이 모두 필요로 하는 직업이죠.

디자인과 개발 사이의 중간 역할이며, 실질 업무는 코드 작성이기 때문에, 프론트엔드 개발의 일부분이기도 합니다.
(실제로 미국에서는 프론트엔드 개발이라고 부릅니다.)

참조
https://namu.wiki/w/퍼블리싱

1-2 퍼블리셔 vs 프론트엔드

그렇다면 프론트엔드 개발의 일부분이기도 하고
실제로 미국에서 퍼블리셔를 프론트엔드 개발자라고도 부른다면,
퍼블리셔는 프론트엔드와 뭔 차이인걸까요?

공통점

일단 둘의 공통점은 화면을 구현한다는 점입니다.
사용자의 눈에 보이는 코딩 작업을 하는데,
사용하는 언어도 HTML, CSS, JavaScript로 같습니다.

차이점

반면, 둘의 차이점은 화면 구현의 목적이 다릅니다.
퍼블리셔는 디자인적인 요소나 움직임을 반영하기 위해 화면구현을 하고,
프론트엔드 개발자는 정보를 전달하기 위해 화면구현을 합니다.

이 둘은 비슷한듯하면서, 역할이 명확히 다릅니다.
외국은 어떨지 모르겠지만, 국내에서는 이 둘을 다르게 보고 있다는 점을 알아둡시다!

1-3 리액트 퍼블리셔

그렇다면 우리가 되기 위한 리액트 퍼블리셔는 무엇일까요?
리액트 퍼블리셔는 말그대로 ‘리액트'를 할 줄 아는 퍼블리셔를 의미합니다.

이를 알기 위해선 먼저 ‘리액트'에 대해서 먼저 알아보겠습니다.

리액트란?

리액트는 JavaScript 기반으로 만들어진 프레임워크(Framework)입니다.
이렇게 이야기하면 그럼 또 ‘프레임워크’가 뭐지?라고 생각하실 수 있습니다.
이해를 쉽게 예를 들어보겠습니다.

JavaScript를 통해 코딩을 하다보면, 어떤 사이트이든 항상 만들어야하는 뼈대들이 있을 것입니다.
그 뼈대가 되는 코드들을 구현하기 위해서, 매 프로젝트마다 같은 작업이 필요로 하다면 어떨까요?
매우 비효율적이라고 느껴질 것입니다.
그래서 이러한 비효율적인 반복노동을 줄이기 위해 사람들은 생각을 합니다.

“반복되는 부분을 매번 코드 짤 필요 없이, 어느정도 뼈대(Framework)를 만들어놓고 그걸 가져다 쓰자!”

이러한 생각에서 만들어진 것이 프레임워크입니다.

프레임워크는 편리함이 있다는 대신에 일정 규칙을 따라 쓰여지도록 만들어졌습니다.
그 규칙을 어느 정도 숙지하고 공부할 필요가 있습니다.
마치 자동차를 운전하려면, 교통 법규도 알아야되고, 신호도 지켜야되는 것처럼 말이죠.

리액트(React) 또한 이러한 프레임워크 중에 하나이기 때문에,
자바스크립트만 안다고 끝이 아니라, 리액트를 사용하는 방법을 따로 공부해야되는 것입니다.

그래서 리액트를 공부하고 다룰 줄 아는 퍼블리셔를 ‘리액트 퍼블리셔'라고 부릅니다.

다른 프레임워크

리액트가 아니더라도 다양한 프레임워크들이 있습니다.
다른 프레임워크를 선택해서 개발할 수도 있습니다.
스펙트럼을 넓히고 싶다면 여러 개의 프레임워크를 익혀도 됩니다.

리액트는 리액트의 장점이 있을 것이고, 뷰는 뷰의 장점, 각자 각각의 장점이 있을 것입니다.
처음 배우는 것이든 이미 다른 경험이 있든, 우리는 그 프레임워크를 배우고자 선택합니다.
프레임워크를 선택한 것은 해당 프레임워크의 장점이 있기 때문입니다.

각 프레임워크의 점유율이나, 국내 시장 인력 분포, 시장의 수요가 많냐 적냐 등을 따질 수도 있고,
프레임워크의 난이도가 쉬운지에 따라서, 혹은
프레임워크의 기능이나 자유도, 코딩 방법이 어떠하냐에 따라 선택할 수도 있습니다.
프레임워크를 선택하는 것은 본인의 자유입니다.

하지만, 여기에선 리액트 퍼블리셔를 목표로 가이드를 진행하고 있습니다.
다른 프레임워크도 있음을 인지하고, 다양한 관점에서 리액트를 배우셨으면 좋겠습니다.

2. 리액트 퍼블리셔 로드맵

2-0 리액트 퍼블리셔 로드맵

들어가기에 앞서
초심자의 이해를 위한 전체 로드맵 설명 목적이므로 자세한 설명은 생략하겠습니다.
리액트 퍼블리셔가 되는데까지 기본적인 로드맵은 이렇습니다.

가장 기본이 되는 HTML, CSS, JavaScript 를 먼저 배우고
그 다음 선택해서 배우면 됩니다.
여러가지를 한꺼번에 배워도 됩니다.
하지만 필요에 따라 배우는 것을 추천드립니다.

CSS에서 반복되는 코드가 불편하다면, SASS를 먼저 배워보는 것을 추천드립니다.

프레임워크를 빨리 경험해보고 싶거나,
컴포넌트를 이용한 UI 모듈화를 해보고싶다면, 리액트를 먼저 배워도 됩니다.

그냥 다 하고 싶으면 한꺼번에 배워도 무방합니다.
결국 나중 가면 다 배우게되는 언어입니다.

중요한 것은 필요도 없는 것을 억지로 공부하려고 하기보단
현재 필요에 따라 지금 코딩이 너무 불편한데 더 편한 방법은 없을까? 고민도 해보고
그 과정에서 얻게 되는 지식이 가장 자연스럽고 재미있습니다.

물론 필요한 상황을 만들기가 어렵겠지만,
개인 프로젝트를 진행하다보면 분명 필요한 지식이 생기게 됩니다.
이것 저것 만들려고 시도해보고, 그 과정에서 필요한 것을 공부해보세요.

추가로 로드맵에 구글과 OKKY가 있는데,
딱히 사용법을 알려줄 게 있는 건 아니라서, 설명은 없습니다.
하지만 코딩에 있어서 구글링은 매우 중요한 실력이기 때문에 넣어봤습니다.

국내 커뮤니티인 OKKY를 넣기도 했는데, 해외 커뮤니티인 Stack Overflow를 쓰셔도 무방합니다.
각자의 성격에 맞는 커뮤니티가 있을 것입니다.
구글링을 통해 도저히 못찾겠는 부분이 있다면, 인터넷에 계신 여러분들의 선배들에게 질문하셔도 됩니다.

구글링은 매우 중요한 실력입니다.

여기까지 전체 로드맵에 대한 설명이었고
이후 HTML 부터 해당 언어에 대해 설명하겠습니다.

2-1 HTML

HTML은 웹사이트에 있어서 가장 기본이 되는 언어입니다.
웹사이트의 뼈대를 잡는 아주아주 쉽고 기본적인 언어입니다.
배우는 시간도 그렇게 오래 걸리지 않고,
복잡하게 머리를 써야할 부분도 없습니다.

그냥 HTML의 태그(tag)를 한번씩 써보고 아 이런거구나 경험해보시면 됩니다.

출처 네이버 : 네이버 HTML

보여지는 사진이 바로 HTML의 모습입니다.
스타일이나 기능이 없는 그냥 문서라고 보시면 됩니다.
인터넷의 초창기를 떠올려보면 되실겁니다.

HTML의 뜻도 HyperText Markup Language의 약자입니다.
HyperText는 문서를 링크로 연결해놓았다는 뜻으로
사이트의 링크를 누르면 해당 페이지로 이동하는 그것을 의미합니다.

Markup은 화면에 어떻게 보여질지 정한다는 의미입니다.

즉 링크로 이어져있는 인터넷 문서들을
화면에 구조적으로 표현하기 위한 언어가 HTML입니다.

단순하게 ‘웹사이트 전용 문서 언어'라고 생각하시면 됩니다.

2-2 CSS

CSS 는 사이트의 스타일을 담당하는 언어입니다.
기능적인 요소는 없고, 오로지 스타일만 담당합니다.
그래서 CSS를 개발언어라고 보지 않습니다. 이름의 뜻도 Style Sheet 입니다.

hover나 animation같이 어느정도 움직임도 수행합니다.
(그 외에 동적인 역할은 JavaScript를 통해 진행합니다.)

출처 네이버 : css가 적용된 모습

CSS가 적용되면 우리가 흔히 아는 웹 사이트의 모습이 됩니다.
이 과정에서 디자인적 요소가 많이 반영되기에 퍼블리셔들이 주 업무가 이 곳에서 발생한다고 볼 수 있습니다.

2-3 JavaScript

JavaScript부터는 HTML과 CSS와는 다르게 개발언어라고 볼 수 있습니다.
JavaScript는 사이트의 기능을 담당합니다.
서버로부터 정보를 받아서 화면에 보여지게끔 하는 ‘정보전달’의 기능도 하지만,
사이트의 외형을 바꾸게 하는 ‘동적요소'의 기능도 합니다.

출처 네이버 : 네이버 다크모드

단순한 예로 화면의 라이트/다크 모드 버튼이 있습니다.
버튼을 클릭하면 JavaScript가 스타일을 바꾸게끔 명령해서, 라이트 모드가 다크 모드로 바뀌게끔 할 수 있습니다.

이 외에도, JavaScript는 여러가지 기능들을 수행할 수 있습니다.

2-4 SASS / SCSS

SASS는 CSS 언어의 일종입니다.
CSS에서 불편한 점을 보완해서 만든 것이 SASS입니다.
SCSS 도 있는데, SASS가 지나치게 축약이 심해서 어느정도 축약을 덜 시킨 것이 SCSS입니다.

SASS는 Syntactically Awesome Style Sheets 의 약자로 직역하면 문법적으로 멋진 스타일 시트입니다.
그냥 CSS 상위호환이라고 생각하시면 됩니다.
SCSS또한 Sassy CSS 의 약자로 얘도 직역하면 멋진 CSS 입니다.
그냥 둘다 CSS 상위호환이란 뜻입니다.
(SCSS가 SASS보다 더 나중에 나온 언어이며, 개인적으로 SCSS가 SASS보다 더 편하다고 생각합니다.)

CSS를 이용하면서 가장 불편한 점은
반복되는 노가다성 작업입니다.

예를들어 중복되는 클래스가 있는데, 뒷 숫자만 다른 경우가 있다고 가정해봅시다. 이게 1~100까지라고 가정한다면
CSS는 중복되는 클래스 명을 일일이 100번 다 써줘야합니다.
하지만 SCSS 는 그럴 필요가 없습니다.

반복되는 노가다성 작업을 줄일 수 있습니다.

2-5 jQuery

jQuery는 JavaScript 라이브러리입니다.
많은 웹사이트가 jQuery에 의존해서 만들어졌지만, 현재는 상황이 많이 바뀌었습니다.
이 글에서 jQuery를 소개하는 이유는 React를 쓰는 이유를 설명하기 위함이지, jQuery 사용을 권장하는 것이 아닙니다.
오히려 jQuery는 낡고 오래된 라이브러리라고 소개하려고 합니다.

사실 JavaScript는 그 자체로는 좋은 언어가 아닙니다.
10일 남짓한 기간에 개발된 언어이며,
그래서 많은 불편함들이 존재하는 언어입니다.

불편함들을 해소하기 위해 여러 라이브러리가 등장했습니다.
그 중에 하나가 jQuery였고, 초창기엔 많은 인기를 얻었습니다.
하지만 시간이 지날수록 jQuery에도 불편함이 나타났고
현재는 React나 Vue 같은 다른 프레임워크가 주목받고 있는 상황입니다.

React와의 차이점

React와의 차이점은 바로 DOM입니다.
DOM은 쉽게 얘기하면, 문서 구조입니다.
웹브라우저에서 개발자도구에 들어가면 Element에 나타나는 문서 구조가 바로 DOM이라고 보면 쉽습니다.

이 DOM을 직접 건드냐 간접적으로 건드냐 차이가 바로 jQuery와 React의 차이입니다.
React는 Virtual DOM이라는 가상의 DOM을 하나 더 만들어 그 가상의 DOM을 조작합니다.
그래서 실제 DOM 에서 불필요한 연산이 발생하지 않고, 더 가볍고 빠른 속도를 냅니다.

그 외에도 리액트의 여러 장점들이 있습니다.

2-6 React

앞서 jQuery와의 차이점, React로 넘어오는 이유를 DOM을 통해 설명했습니다.
이번엔 DOM 외에도 React의 여러 장점들에 대해서 설명을 해보려고 합니다.

컴포넌트

React는 컴포넌트를 사용합니다.
컴포넌트란? 커스터마이징이 가능한 모듈을 의미합니다.

크고 복잡한 웹사이트를 만들 때 한번에 만드려면 매우 어려울 것입니다.
이럴 때 각 영역을 나눠서 만들고 나중에 조립을 한다면 어떨까요?
일이 훨씬 쉬워지고, 분업도 가능할 것이며, 코드의 가독성도 올라갈 것입니다.

React는 반복되거나 복잡한 영역을 나눠서
컴포넌트화가 가능하다는 장점이 있습니다.

생태계

React는 다양한 사용자들이 있습니다.
다른 라이브러리보다 커뮤니티가 활발합니다.
그만큼 시장 규모도 크고
수요도 많다고 볼 수 있습니다.
(여러 대기업에서 React를 사용해
사이트를 구축해놓았습니다.)

경쟁 모델로는 Vue가 있긴 하지만,
React 또한 좋은 커뮤니티가 형성되어 있어 접근이 용이합니다.

다양한 기능

Vue보다 접근이 어렵긴 하지만
React는 하나의 기능을 만들 때 여러가지 방법을 사용할 수 있습니다.

예를 들어 반복작업을 할 때,
React는 for문을 쓸 수도 있고,
map함수를 쓸수도 있고, component를 여러개 쓸 수도 있습니다.
하지만 vue는 v-for 하나입니다.

그래서 보다 광범위하고 복잡한 기능을 만들 땐
숙련된 개발자에게 더 나은 옵션을 제공합니다.

참조
https://appmaster.io/ko/blog/vuejs-dae-baneung
https://ljh86029926.gitbook.io/coding-apple-react/1/why-learn-react

2-7 React UI Library

UI 라이브러리는 다양하게 있습니다.
Ant Design / Mui / Sementic / BootStrap 등(이거 외에도 엄청 많습니다.)이 있는데
UI 라이브러리는 무엇을 쓰든 크게 상관은 없습니다.
필요에 따라 자유롭게 사용하시면 됩니다.

UI 라이브러리를 쓰는 이유는, 굳이 하나하나 만들 필요 없이 이미 만들어진 UI를 쓸 수 있기 때문입니다.
그래서 기능구현이나, 동적요소를 새로 만들 필요 없이
이미 구현된 것들을 그냥 가져다가 쓰면됩니다.

장점

UI 라이브러리는 장점과 단점이 명확합니다.
장점으론 시간 단축이 됩니다.
이미 만들어진 걸 쓰면 되기 때문에, 해당 기능이나 디자인을 만들 시간이 절약됩니다.

단점

반면 단점도 분명합니다.
라이브러리에서 지원하지 않는 기능이 있을 경우 커스텀하기 어렵다는 점이 단점입니다.
물론 지원하는 기능까지는 매우 편리하게 사용할 수 있지만,
지원하지 않는 부분을 만드려면, 일이 매우 복잡해집니다.

라이브러리의 CSS 클래스를 다 뜯어 고치는 등
기본 html태그를 쓰는 거보다 시간이 더 오래 걸릴수도 있습니다.

라이브러리를 쓰기 이전에, 내가 만들고자 하는 것이
해당 UI 라이브러리로 구현 가능한지 먼저 파악하는 것이 좋습니다.

2-8 Git

다음으로 깃입니다.
깃은 내가 만든 파일을 저장하기 위한 저장소라고 보시면 되는데,
단순히 USB나 SSD같은 저장소를 의미하지 않습니다.
단순 저장소랑은 다르게 내가 작업해서 변경된 내용을 체크해주고, 협업하도록 도와주는 저장소라고 보시면 됩니다.

그 내용을 깃의 장점을 통해 설명하겠습니다.
깃을 사용하면 크게 3가지 장점이 있습니다.

버전관리

깃을 사용하면 좋은 점은 버전 관리가 된다는 점입니다.

예를 들어 내가 작업하던 파일을 날짜별로 구분해서 따로 저장해본다고 가정해봅시다.
1일에 작업한 거, 2일에 작업한거, 3일에 작업한거 다 따로따로 저장해 놓는다면
전체 파일의 용량이 매우 커질 뿐만아니라,
뭐가 달라졌는지 체크하기도 힘듭니다.

하지만 깃을 쓰면 이야기가 달라집니다.
깃은 파일을 업로드할 때마다 달라진 부분만 체크해서 파일이 수정되기 때문에,
각 날짜별로 어떤 작업을 했는지 알기가 수월하고,
전체 파일의 용량도 현저히 낮아 효율적이고 빠릅니다.

불필요한 파일 간소화

깃은 node_modules라는 폴더 안에
많은 용량을 차지하고 있지만, 개발 과정에서 언젠가는 쓸 수도 있는 모듈 파일들을 모아 놓습니다.

이 node_modules폴더는 저장소에 올리기엔 용량이 너무 많아
이를 저장소에 올려놓지 않게 설정해 놓습니다.(일반적으로)

대신에 패키지로 따로 분류해 언제든 설치할 수 있게 되어있습니다.
즉, 우리가 자주 쓰지만 변경이 일어나지 않는 모듈들은 굳이 저장소에 올리지 않게 하고
모듈만 모아놓은 사이트에서 다운받게 설정해놓았습니다.

실질적으로 변경이 일어나는 데이터들만 저장소에 올라가게 해서
전체 용량을 최소화 한다는 장점이 있습니다.

협업 가능

깃의 또 다른 장점은 협업이 가능하다는 점입니다.
내가 작업하다가 다른 사람이 동시에 작업하는 경우가 있을텐데
코딩이 온라인 게임은 아니기 때문에, 작업내용이 실시간으로 반영되진 않습니다.

하지만 저장소에 다른사람이 저장한 내용을 불러와
내 파일의 변경사항을 반영해서 저장할 수 있기 때문에,
협업이 가능하다는 장점이 있습니다.

업무를 하다보면 퍼블을 다 끝마치고 기능개발을 하는 경우도 있겠지만
그렇지 않은 경우도 있습니다.
프론트엔드 개발자와 동시에 작업을 해야되는 경우도 생기는데,
이럴 때 깃을 사용할 줄 모른다면 난감할 것입니다.

깃 사용법을 익힌다면 후에 협업하는 상황이 나타났을 때 매우 편리합니다.

마치며

여기까지 웹 퍼블리셔에 대한 소개와, 리액트 퍼블리셔가 되기 위한 로드맵을 설명드렸습니다.

긴 글 읽어주셔서 감사합니다!

PAEDDI

시작

목차