티스토리 뷰
0. 어때요, 서버는 잘 떴나요?
npm run serve의 결과로 띄워진 http://localhost:8080 에 브라우저로 접속해서,
아래와 같은 화면을 띄웠다면 이제 절반은 끝낸 겁니다(시작이 절반이니까요?)
아, 시작하기에 앞서서 당부드리자면 오늘은 좀 지루한 이야기를 해야 할 거 같습니다.
그러니 좀 더 집중해서 글을 읽어주시면 좋을 거 같습니다. 저도 지루한 이야기는 별로 좋아하지 않습니다만, 지루하더라도 해야하는, 이야기는 해야하니까요ㅎㅎㅎ
아, 뭐 그렇다고해서 되~~~~게 어려운 개념을 설명하려는 건 아닙니다.
물론 듣는 이에따라서는 이게 대체 뭔 소리야? 라고 생각할 수도 있긴합니다.
그러니 차근차근 설명을 시작해보도록 하겠습니다.
1. SPA (Single Page Application)
SPA에 대해 이야기 해봅시다.
어느 시점에선가부터 웹 개발을 좀 한다 싶으면, 꺼내지는 키워드들이 몇가지가 있습니다.
그 중에 매우 흔한 키워드가 바로 이 SPA 인데요. 사실 SPA는 SPA라는 축약어에 모든 의미를 다 담고 있습니다. Single Page Application. 이 세 단어로 의미와 사용법, 심지어 어떻게보면 아키텍쳐까지 다 설명을 해버립니다.
SPA에서 꼭 기억하셔야 할 개념은, 실제 사용되는 건 딱! 딱! Just One, 하나의 페이지 라는 겁니다.
(주구장창 싱글 페이지 싱글 페이지, 하나의 페이지, 온리 원, 저스트 원...이걸 계속 반복 말씀드리고 있습니다. 그만큼 중요하단거지만 그게 전부라는 반증입니다)
좀 더 쉬운 설명을 위해 예시를 들어보겠습니다.
도서관리를 하는 웹 서비스를 여러분이 개발하려고 합니다.
읽고 싶은 책을 검색하고, 책을 빌리고, 반납하는 정도의 서비스를 하는 웹 페이지입니다.
이런 서비스를 만들 때, 기존의 JSP/PHP/ASP 와 같은 기술을 사용하셨다면 아마 무수히 많은 JSP, PHP, ASP 파일들을 만드셨을 겁니다. 사용자가 서비스에 접근시 맨 처음 보여야 하는 home.jsp가 있을 거구요, 로그인을 해야하니까 login.jsp도 있어야 겠죠. 아, 저흰 도서관리를 하는 웹 서비스니까 책을 검색하는 search.jsp, 책을 대여하는 rent.jsp, 책을 반납하는 return.jsp 도 필요할 거 같네요.
뭐, 이 이외에도 아주 많은 페이지들이 각자의 용도에 맞게 생성이 되었을겁니다.
그리고 여기에서 우리가 주목해야 할 포인트는 아주 많은 페이지입니다.
아주 많다, 라는 건 1개가 아니라는 소리죠. 이 서비스를 위해선 N개의 파일들이 필요하다라는거죠.
하지만 SPA는 어떨까요.
이름이 모든 걸 대변한다고 말씀드렸죠.
싱글 페이지 어플리케이션.
딱! 하나의!! 파일!!!
네, 그렇습니다.
SPA는 HTML 파일 하나.
단 하나의 파일(페이지)만을 가지고 웹 서비스를 제공합니다.
좀 더 정확하게 말을 해볼께요. 단 하나의 '정적 페이지(a.k.a HTML)'만을 가지고 웹 서비스를 제공한다, 바로! 이겁니다!
2. 삼위일체
아, 고백합니다. 사실 파일 하나로 서비스를 제공하는 건 맞는데요 그게 또 파일 하나로 다 커버를 하느냐고 물어보시면 그건 또 아니거든여...그러니가 진짜 정말로 리얼리 온리 원 에이치티엠웰 파일 이즈 올 커버 ㅇㅈ? ㄴㅇㅈ, 동의보감? 이냐고 물으신다면...좀 애매합니다.
왜 번복해서 헷갈리게 하냐구요?
정말 웹 서비스를 제공하는데 HTML 파일 하나만으로 될까요?
아니죠, 그럴리가요.
실제 여러분이 개발한 서비스를 제공하기 위해서 필요한 건 아래의 3개라고 보시면 됩니다.
1. 웹 서비스의 밑 바탕을 이루는 HTML 파일(예를 들어, index.html)
2. 스크립트 코드들이 빌드된 Javascript 파일(예를 들어, build.js)
3. 이미지, 폰트와 같은 정적 리소스(예를 들어 *.jpg, *.png, *.woff)
보통 이렇게 3가지 구성으로 SPA의 기반이 마련되고, 하나의 웹 서비스를 제공할 수 있는 겁니다.
3. N개의 vue 파일
한 파일로 제공하는 서비스지만 한 파일 같지 않은 한 파일의 SPA.
내꺼인 듯 내꺼 아닌 내꺼 같은 너...ㅈㅅ....
거기에 좀 더 헷갈릴 수 있는 대목이 ㄷㄷㄷㅈ!
단 하나의 파일, 이라는 개념을 좀 더 파고들어가보겠습니다.
여기서부턴 천천히 따라와주세요.
스프링의 MVC구조가 익숙하신 분이라면, 컨트롤러 역할의 JAVA 파일에서 아래와 같은 리턴 형태를 많이 보셨을 겁니다.
return “redirect:/”;
혹은
return “home”;
위와 같이 문자열을 정의하여 리턴해주면, 그에 맞게 이름이 일치하게끔 매핑된 파일, 혹은 해당 URL 경로에 지정해놓은 파일이 불리게 됩니다. 이때 각 조건에 맞춰서 호출되는 파일들이 바로, JSP/PHP/ASP 기반으로 작성된 파일들이었습니다. 그리고 이것이 그동안 활용되던 웹 서비스의 동작 방식이구요.
웹 서비스의 접속시 최초로 보이는 home.jsp
로그인을 해야하니까, 로그인 기능이 있는 login.jsp
책을 검색하고 그 결과가 나오는 search.jsp
찾은 책을 빌리는 rent.jsp, 책을 반납하는 return.jsp
대략 이런 파일들 말이죠
(혹은 ModelAndView나, HTML 태그를 문자열 형태로 리턴하는 방법등등 다양하지만, 결코 이 모든 것들은 1개 파일로 이루어진 구성이라고 말할 수가 없습니다)
물론 SPA도 비슷합니다.
일반적으로 SPA도 개발을 할 때는 각 파일별로 기능이 나누어져 있습니다.
얼레, 뭐야? 그럼 다를 게 없는 거 아냐?
다를 게 있습니다. 바로 이 SPA의 파일들은 실제 서비스에 직접적으로 사용되진 않습니다.
JSP/PHP/ASP에서와 같이 각 파일별로 기능을 개발했는데, 서비스에 사용되지 않는다…라니? 이게 콩이여 된장이여 말이여 빙구여, 뭔 귀신 씨나락 까먹는 소리인가 싶으실거에요. 이해합니다...프로젝트 현장에 Vue.js 교육을 해드릴때도 여기서 헤매시는 분들이 여럿 있으시더라구요.
여기서 저희가 주목해야 할 포인트는 바로 직접적으로라는 대목입니다.
단순히 파일명에서부터 출발해보겠습니다.
JSP 기반의 프로젝트라면 JSP파일을 사용합니다.
PHP 기반이라면, PHP 파일을 이용하겠죠.
우리는 Vue.js 기반을 공부하고 있습니다. 그럼, 당연히 Vue파일을 활용합니다.
즉, 확장자가 .vue 인 파일들에 우리는 기능을 개발하고 정의할 겁니다.
어, 근데 이상한 점이 있어요.
SPA에서는 하나의 파일로 서비스를 제공한다고 하지 않았나요?
근데 vue 파일'들'이라니요? ‘들’은 하나가 아니잖아요?
네, 맞습니다. vue파일들이 서비스를 제공하게 됩니다.
다만, N개로 이루어진 형태가 아니라 단일화된 하나의 파일로써 서비스를 제공하게 됩니다.
(집중 박수 세번 짝, 짝, 짝. 별표 5개 땅★따라★땅★따라★땅★)
앞선 2번 삼위일체 항목을 먼저 언급드렸던 이유가 바로 이겁니다.
자...다시 한 번 SPA에서 서비스를 제공하기 위해 기본적으로 필요한 3가지를 되짚어 봅시다.
1. 웹 서비스의 밑 바탕을 이루는 HTML 파일(예를들어, index.html)
2. 스크립트 코드들이 빌드된 Javascript 파일(예를들어, build.js)
3. 이미지, 폰트와 같은 정적 리소스(예를들어, *.jpg, *.png, *.woff)
여기서, 2번 항목으로 쓰인 Javascript 파일
이 파일이 바로 N개의 vue 파일들이 컴파일과 빌드를 거쳐서 단일화 된 파일입니다.
그리고 사실상 SPA의 주축, 뼈대 역할을 하는 HTML 파일에는 아래와 유사한 <body> 태그가 작성되게 됩니다.
<body>
<div id=app></div>
<script src=/dist/build.js></script>
</body><body> 태그의 내부를 잘 봐주세요.
우선, id가 app인 <div> 태그가 하나 있구요.
그 아래에 <script> 태그를 사용해서 Javascript 파일인 build.js를 품고 있다는 걸 아실 수 있습니다.
4. 정리
어...? 어어...?
뭐야 갑자기 왜 벌써 정리야...?
아직 설명해야 할 게 산더미아냐?
네 맞습니다. 아직 설명드려야 할 게 많아요.
대체 어떻게 vue 파일들이 컴파일/빌드를 통해 단일화해서 build.js가 되는지.
그 build.js가 어떻게 HTML에서 활용되어 화면을 렌더링 하는지.
앞서 설명한 return “home”; 을 통해 home.jsp를 호출하던 것과 같은 매커니즘은 vue에서 어떻게 정의하고 어떻게 동작하는지.
...등등등을 설명해야 하지만,
사실 여기까지 보시는 것만으로도 슬슬 머리가 아파오시지 않을까 싶습니다.
그래서 한 번 끊고 포스팅을 이어가려고 합니다.
자, 정리해보겠습니다.
1. SPA는 단일 파일로 하나의 ‘웹 서비스’를 제공한다.
2. 서비스의 기능 구현은 각 역할에 맞는 vue파일에 정의한다
3. 하지만 이때 개발한 N개의 vue 파일은 컴파일&빌드되어 1개의 Javascript가 된다.
4. HTML파일은 빌드된 Javascript 파일을 활용한다.
이렇게 4줄로 이번 포스팅에서 설명한 개념이 축약되었습니다.
참 짧은데...풀어쓰고 풀어쓰니 참 길게도 적었네요.
그럼 다음 편에서 뵙도록 하겠습니다.
질문은 언제나 환영합니다. 댓글은 언제든 남겨주세요.
-1. 부록
그냥 또 가기엔 섭섭하니 부록 하나를 남겨보겠습니다.
가장 근본적인 질문을 던져볼게요.
JSP/PHP/ASP 잘 쓰고 있고 저는 그게 더 편해요.
근데 왜 굳이 SPA를 해야하나요?
ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
맞는말입니다. 굳이, SPA를 고집해서 서비스를 구축하실 필요는 없습니다.
잘 돌아가는 시스템은 건드는 게 아냐, 라는 이쪽 업계의 전통적인 명언이 떠오르네요.
SPA도 분명 장단이 여러개 있습니다.
가장 대표적으로 제시하는 장점은 역시, 최초의 접속 이후로는 브라우저가 캐싱처리를 통해 보다 빠른 서비스를 제공할 수 있다는 점. 그와 동시에 최초 접속 시 필요한 js파일 및 리소스 파일이 많기에 처음 1번이 제법 느릴 수도 있다는 점.
REST API로 백엔드와 통신하는 게 국룰이 된 현재의 웹 서비스 체계에서는 유연하게 데이터를 요청하고 받을 수 있다는 장점, 그와 동시에 활용되는 데이터에 대한 메모리 관리를 브라우저의 가비지 컬렉터에 전적으로 의존한다는 단점(물론 이건 IE만 아니면 정말 앵간해선 다 커버가 되는데...아시잖아요, 여러분? 대한민국은 IE 못 버려...거기에 한 발 더 나아가 우리회사는...IE......후우, 할말하않)
결국 이 물음에 대한 결론을 지어보자면,
개발하고자 하는 서비스에 대한 철저한 분석을 바탕으로 적절한 아키텍쳐를 구성해야 한다는 게 답입니다.
뭐, 사실 뻔한 답이긴 합니다만...글로벌 트렌드가 어떠니, 이거 좋다던데, 라며 던지시고는 AS-IS에서 되던건데 외않됀데? 라는 분들을 너무나도 많이 겪었고, 논리를 바탕으로 설득하려해도 아몰랑 스킬에 울화통 터지는 건 결국 개발자인 제가 되더라구요.
네, 그러니 여러분들도 SPA가 정말 우리 서비스와 맞는 걸까? 에 대한 고민을 한 번 정도 해보시기 바랍니다. 이상, 제 마음을 대변하는 짤로 이번 포스팅 끝!
'개발 > 프론트엔드(Front-end)' 카테고리의 다른 글
| [Vue.js_#03] N : 1 (feat. webpack) (2) | 2020.10.05 |
|---|---|
| [Vue3] Font Awesome 적용하기 (0) | 2020.09.30 |
| [Vue3] Vue 3.0 One Piece가 릴리즈 되었습니다. (0) | 2020.09.26 |
| [Vue.js_#01] 일단 서버를 띄우자 (0) | 2020.09.21 |
| [Vue.js_#00] 원래 시험공부는 방청소부터 하는거랬다. (0) | 2020.09.21 |