Ionic 접하기


휴... 이제는 Ionic이냐...


어찌어찌하다 배우려고 마음만 먹고 공부할 생각도 사용을 고려한적도 없던 Ionic을 보기로 했다. (그냥 쓰윽...) 우선은 Ionic 공식 사이트에서 친해지기 모드로 쑤욱~ 훑어보자. 일단 닥치고 시작하는게 최고!!!.

Ionic 공식 사이트


우선 계정을 만들고 Get Started를 눌러 천천히 살펴보자.


1. Install Ionic

개발의 기본은 설치다. 가끔 이걸 잊는 사람들이 많다. Ionic을 시작하기 앞서 자신의 맥 혹은 윈도우에 Node.js가 필요하다. NPM을 사용해 cordova와 ionic을 설치한다.

$ npm install -g cordova ionic



2. Start a project

cordova와 ionic 설치가 정상적으로 완료되었으면(저 윗단계에서 실패하는 사람들도 많다. 처음엔 나도 그랬으니 좌절하지 말고 sudo도 해보고 권한 조정도 잘해보자!) 이제 프로젝트를 생성한다. 자신이 원하는 디렉토리로 이동한 후 아래와 같은 명령어를 실행한다.

$ ionic start myApp tabs


명령어는 ionic으로 시작하며 start는 신규 프로젝트를 생성한다. 여기서는 공식 사이트에 나온 그대로의 명령어를 따라하여 myApp이라는 프로젝트를 생성하였다. 그러면 tabs는 뭐지??

Ionic은 ready-made app templates(미리 만들어 놓은 템플릿...)을 제공한다. 빈 템플릿까지 총 3가지의 템플릿 중 하나로 앱을 생성할 수 있다. 위의 명령어는 3가지의 템플릿 중 하나인 tabs를 선택하여 앱을 생성하는 명령어이다.



blank는 빈 템플릿의 앱을 실행한다. tabs는 하단의 메뉴 버튼을 제공하며 메뉴가 단순할 때 이용하면 효과적일 것 같다. sidemenu는 말 그대로 사이드 내비게이션 메뉴를 제공하는 템플릿이다.


3. Run it

자 그럼 실행해 보자. (앱등이는 아니고 아이맥, 맥북, 아이폰만 사용하는 관계로 맥에서만 테스트 해보았다.)


$ cd myApp

먼저 생성한 프로젝트의 디렉토리로 이동한다.


$ ionic platform add ios

그 후에 ios(여기서는 ios로 테스트했다. android는 android를 입력하면 된다.) ios 플랫폼을 추가하는 명령어를 실행한 후,


$ ionic build ios

빌드과정을 마친후 마지막 명령어를 입력한다.


$ ionic emulate ios

그러면 아래와 같이 시뮬레이터가 실행된다. (다시한번 말하지만 Mac OS에서 ios를 실행한 결과이다.)





물론, 이 외에도 웹브라우저에서 확인할 수 있는 serve 명령어와 앱스토어에 있는 Ionic View라는 어플을 이용해서 실행 및 확인하는 방법등이 존재한다.


Ionic은 무엇인가?

자 일단 아무것도 모르는 상태에서 Ionic을 접해보았다. 그러면 이쯤에서 갑자기 이런 생각이 들것이다. '나 왜 지금 이걸 왜 쳐다보고 있지?! 근데 도대체 이게 뭐지??'

Ionic은 하이브리드 모바일 앱을 빠르고 간편하고 아름답게 만들기 위한 결합체(Combination)라고 한다.( Ionic in action 인용) 못믿겠지만 그렇다더라... 그러면 이 프레임워크는 어떻게 동작하는가?!
먼저 사용자가 앱을 실행하면 Device, 즉 기기는 cordova app wrapper를 로드한다. cordova는 html, css, js를 사용하여 실행할 수 있는 모바일 앱을 만드는 플랫폼으로 web application을 로드하는 native app이다. 우리는 이것을 하이브리드 모바일 앱이라고 부른다. 웹 앱과는 다르게 하이브리드 모바일 앱은 html, css, js를 사용하여 구현하지만 native app안에서 구동되기 때문에 기기의 고유 기능에 접근할 수 있다.
*오호... 그럼 앱 개발은 무조건 이걸로 하면 되겠네라는 쓸데없는 생각은 접어두자. 그런 생각을 하다가 망한 회사도 봤다. 그 부분은 추후에 언급하겠다.

cordova app wrapper가 열리면 cordova javascript api를 통하여 WebView가 index.html 파일을 렌더링한다. 이 index.html은 AngularJS의 인덱스 페이지로, 이제부터는 웹 어플리케이션이 실행된다. Ionic은 웹 어플리케이션에서 UI 컴퍼넌트를 렌더링하게 된다.

그럼 앱 개발자가 필요없겠네?!

대뜸 이런말부터 하면 좀 맞아야 된다.

우선은 네이티브 앱의 장점에 대해서 얘기해보자. 

장점 1. Native APIs

네이티브 앱이니까 당연한 이야기이지만 네이티브 API를 앱 내에서 직접 사용함으로써 플랫폼과 견고하게 연결될 수 있다.

장점 2. 성능

당연히 기기 혹은 환경 등에 맞는 최상의 성능까지 끌어올릴 수 있다.

장점 3. 동일한 환경

1번과 같은 이야기지만 동일하거나 친숙한 언어와 API를 사용하므로 개발자 친화적이다.

그러면 단점은 없을까??

단점 1. 언어(학습 혹은 개발자가 필요하다)

당연한 이야기지만 앱 개발에는 그에 맞는 언어가 필요하다. 그리고 플랫폼의 특정 API에 대한 선행지식이 반드시 필요하다. (그럼 Ionic은 아니냐!!!)

단점 2. 따로 개발해야한다.

뭐 특별히 방법이 없지는 않지만 그 성능과 잡무의 가능성을 생각하면 플랫폼에 맞게 따로 개발을 해야한다. 이는 곧 인건비의 상승!!! (심신의 안녕과 평화를 위해서는 인건비가 더 드는게 대수냐)

단점 3. 비용의 상승

2번에서 언급했듯이 따로 개발해야한다. 그러면 한 사람이 android와 ios를 둘 다 개발하거나 아니면 두 개발자가 한 app을 플랫폼 별로 따로 만들어야 한다. 전자의 개발자는 많이 없고(두 가지의 품질을 맞춰줄만한...) 그만큼 시간이 더 걸린다. 후자는 인원의 부담이 생긴다. 어찌됐건 쩐이 많이 든다.


내가 좀 아재스러워서 그런지 아니면 변화를 싫어해서 그런지는 모르겠지만 단점들에 대해 거부감은 없다. (상기 내용은 Ionic in actions에 기술된 내용이다.) 그만큼 장점들이 (특히나 성능에 있어서는 더할나위 없이) 단점을 커버할만큼의 이점을 준다고 생각한다. 우선, 플랫폼에 맞는 전문지식을 가진 개발자가 있기에 프로젝트의 한 부분을 맡길 수 있고 또 그걸 바탕으로 안정적인 개발이 진행될 수 있으며 사후 품질관리 역시도 원활하게 수행할 수 있지 않을까?!


카메라, 사진첩의 접근이라든지, 위치기반 서비스가 필요한 곳이라면 모바일 웹으로는 대체할 수 없는 프로젝트들이 상당수 존재한다. (물론 안되는거 빼고 까라면 까겠지만 성능과 기능의 구현에서는 많은 차이가 날 것이다.)


그런데 왜 Ionic을 사용하는가?! (물론 어쩔 수 없을때 사용하게 된다.) 네이티브 앱 개발자가 존재하지 않을 때, 비교적 간단한 어플리케이션을 빠르게 만들어야 할 때 필요할 것이며 이 외에도 저마다의 이유가 여럿 있을것이다. 그중에서도 위의 네이티브 앱의 단점 3가지 중 3가지 모두가 부담이 되거나 가능하지 않을 때에는 하이브리드가 정답이 될 수 있을것이다. (이 부분은 지극히 개인적인 의견임!!!) 그 중에서도 AngularJS에 대한 경험이 있다면 Ionic 사용이 도움이 될것이다.


맛보기는 여기까지만...

오늘은 Ionic의 간단한 설치와 프로젝트 생성, 프레임워크의 구조를 알아보았다. 다음에는 이것저것 하나씩 뜯어보겠다. 언제할지는 모른다. 안할수도 있다. 이건 연재가 아니기 때문에...


'Front' 카테고리의 다른 글

JavaScript[ECMAScript] 2. 불리언 타입  (0) 2016.07.08
JavaScript[ECMAScript] 1. 데이터 타입  (0) 2016.07.07
Angular Material  (1) 2016.06.17
AngularJS $watch  (0) 2016.06.16
HTML의 의미와 좋은 마크업  (0) 2014.12.30

Angular Material

얘네는 사람 빼고 다 만들 기세다...


프론트엔드 개발자들의, 아니 모든 개발자들의 숙명과도 같은 신기술 습득에 빡씨게 채찍질을 하는 교관같은 하나의 단체가 있다. 이 곳에 들어가기 위해서는 나같은 미개한 개발자는 다시 태어나야할 수준이지만 그래도 정말정말정말 입사하고싶은 곳, 바로 구글이다.

2년전 즈음에 구글은 머티리얼(혹은 매터리얼) 디자인을 공개했다. 이들의 목표는 야심차게도(어쩌면 그게 당연하게 느껴지지만) 시각 언어의 창조이다.

Create a visual language that synthesizes classic principles of good design with the innovation and possibility of technology and science.


이런 귀여운 생각을 한덕에 나는 또 구글링을하며 이들의 철학과 원칙들을 찾아보았다. (아이 고마워라...)


Material is the metaphor

머티리얼은 은유다. 난 이게 무슨 의미인지 모르겠다. 그들에 따르면 잘짜여진 공간과 움직임의 체계를 통합한 가설(혹은 이론)이라고 설명하면서 이딴 문장을 써놓으니 못알아 먹는게 당연하지! 계속하자면 종이와 잉크에 관한 연구를 통하여 영감을 받았다고 한다. 계속 못알아 먹겠다. 아무튼 이 원칙을 내 나름대로 판단해보자면 머티리얼 디자인은 아날로그적인 재료를 가지고 지금껏 발전시켜온 디자인과 동작등을 조합한 것이라고 보여진다.

Bold, graphic, intentional

이건 또 무슨 소리인가... 머티리얼의 기본요소는 출력물에 기초한다. 이러한 출력물의 요소는 타이포그래피, 그리드, 공간, 비율, 색상과 이미지군의 시각요소를 다루는 가이드들에서 기초했다. 초창기 웹 디자이너들의 디자인들이 거의 모든 지면 디자인에서부터 출발했으니 당연한 이야기가 아닐까?!

Motion provides meaning

계속해서 이해할 수 없는 것들이 나온다. 동작은 의미를 제공한다라... 아마 여기에서는 동작은 (사용자의) 의도를 규정한다 정도로 이해해야 할 것 같다... 근데 도대체 문서 만드는 자식분이 어떤 사람이길래 이렇게 철학적으로 말할까....

아무튼 기본원칙을 찾아보았다. 그러면 다른것을 좀 훑어보도록 하겠다. What is material? 메뉴의 Enviroment를 보자.


근데 여기서 나오는 환경이라는 단어, Enviroment는 일반적인 환경이라는 뜻 보다는 구성을 의미하는 것 같다. 머티리얼 디자인의 3차원 환경(구성 혹은 구조)에는 빛과, 재료, 그림자를 포함한다. 즉 빛, 재료, 그림자로 구성되어 있다는 뜻이다. (이건 내 마음대로의 해석이니 그냥 그러려니 하길...)


옆의 이미지를 확인해 보자. 파란색 배경 안에는 하나의 박스 모양 물체와 그 위의 다른 원형 물체가 있다. 각각의 물체들은 저마다의 z-index를 가지고 있어서 서로 붙어있지 않다는 것을 알 수 있다. 지금 옆의 예시 이미지에는 눈에는 보이지 않지만 빛이 존재한다. 그 빛이 있기 때문에 해당 물체들은 그림자를 가질 수 있게된다. 머티리얼 디자인은 이와같이 빛과 물체(재료), 그림자로 구성되어 있다는 것을 잘 보여주는 예이다. (근데 일장기 모양이라 별로...)


이 외에도 머티리얼 디자인의 공식 사이트를 확인하면 컬러 팔레트라던지 레이아웃 반응형 디자인에 대한 명세와 설명등이 나온다. 뭐... 하나같이 읽어도 읽지않은듯한 글들이 무더기로 나오고 가끔 동영상과 이미지들이 나온다.


자세한 사항은 https://material.google.com/ 이곳에서 확인해보기 바란다. 여기에 나오는 글들은 오역과 발역 그리고 숨통조이는 의역들이 난무하기에 원래의 의도와는 많이 다르므로 꼭 방문해 확인하자.


아... 끝을 맺으려고 보니 이 포스팅이 머티리얼 디자인에 대한 소개가 아님을 알아차렸다. 나란 새끼... 

자, 그럼 Angular Material(이하 am으로 퉁치겠다)을 알아보자.

What is Angular Material?

am은 AngularJS와 머티리얼 디자인을 사용하는 개발자를 위해 제공하는 프레임워크이다. am은 AngularJS답게 그에 맞는 지시자와 서비스, 기능 등을 제공한다.

사실 내가 처음부터 am을 찾아보고 사용하게 된 것은 아니다. am을 접하게 된 이유는 부트스트랩과 AngularJS의 조합이 마음에 들지 않아서이다. UI Bootstrap은 무언가 쓰기가 불편했다. 모바일 퍼스트 디자인이지만 약간 무겁게 느껴지기도 했고 (그렇다고 테스트를 해본것은 아니며 am이 더 빠르다는 의미도 아니다.) UI 자체가 오래봐서 그런지 질리기도 했다. 

am 공식사이트를 방문하면 버전 릴리즈 현황이나 구성 요소들의 데모, API 명세들을 제공한다. 일단 먼저 쑤욱 훑어보기를 바란다. 내가 처음 am을 사용하면서 신기방기했던것은 md-button이었다.


얼핏보면 부트스트랩이랑 색만 다른데 뭐가 신기하냐는 의문을 날릴지 모르겠지만 버튼을 직접 클릭해보면 조금 다르다는 것을 알수있다. 애니메이션이... 데모에서 볼수 없는 md-button의 설명은 DIRECTIVE 메뉴의 md-button에서 살펴볼 수 있다. 이 메뉴를 보면 잉크 리플(수면으로 퍼지는 효과)을 선택적으로 제공하는 버튼 지시자라고 명시하고 있다. 잉크는 머티리얼 디자인의 원칙인 은유에서 본적이 있을것이다. (그래서 뭐??) 그냥 그렇다고... 아무튼 나는 꽤나 신기했던 효과이다.


또 계속해서 데모를 훑어보면 그리드 리스트나 그리드 타일에 관해서도 확인할 수 있으며 사이드내비게이션, 툴바 등을 확인할 수 있을것이다. 기본적으로 am의 구조는 상단의 md-toolbar, 좌측의 md-sidenav, 콘텐츠 영역의 md-content로 구성되어있다. 물론 사이드내비게이션의 사용여부와 위치는 선택적인 것이다. 그럼 이제부터 따라하기 쉬운 간단한 예제를 만들어 보자.


먼저 선행되어야 할것은 관련 소스 내려받기다. (물론 이 중요한 것을 빼먹고 나한테 묻던 인간이 있었다. 그래서 명시했다.) 터미널을 열고 npm 혹은 bower에서 install angular-material --save를 실행한다. 그러면 현재 AngularJS에 맞게 디펜던시가 다운로드 되고 이제 그것을 이용해 개발을 시작하자. 'app'의 의존성에 'ngMaterial'을 추가해주면 끝.


위의 JSFiddle Result 항목을 보면 현재 마크업된 레이아웃을 확인할 수 있다. 잘빠진 3단 구성의 레이아웃이 완성됐다. 누구라도 개발환경만 갖춰져있다면 3분안에 완성할 수 있는 레이아웃이다. (빠르다!!! 개빠르다!!!)


HTML을 클릭해서 확인해보면 md-* 지시자들을 확인할 수 있다. 바로 위에서 설명했던 md-toolbar, md-sidenav, md-content를 확인할 수 있을것이다. 조금 더 자세하게 들여다 보자. 예제 파일을 만들어서 위의 코드를 복사해 자신의 파일을 만들어보자. 그리고 하나씩 지워보면서 기능에 대해 파악하겠다.


먼저 사이드내비게이션과 콘텐츠를 감싸고 있는 div의 flex를 지워보자. 그러면 사이드내비게이션과 콘텐츠의 높이가 잘리는 것을 확인할 수 있을것이다. 그러면 flex는 높이를 늘려주는 것인가?? 높이만 늘려주는 놈은 아니다. 이 녀석은 신기하게도 너비도 늘려준다.


md-content의 flex를 지워보자. 그러면 너비가 줄어드는 것을 확인할 수 있을것이다. 오호라... 너비나 높이를 늘려준다라... 또 하나의 flex가 있다. 툴바 안, span의 flex를 지워보자. 그러면 이번에는 끝에 있던 '메뉴영역'이 왼쪽으로 달려나올 것이다.


이것은 am에서 제공하는 공식적인 offset 먹이는 방법 중 하나다. 물론 다른 방식의 offset들도 존재하지만 float을 주거나 css를 수정해서 강제적으로 위치를 조정하는 것 보다 이렇게 사용하기를 권장한다.


layout은 무엇일까?? layout은 일종의 레이아웃 컨테이너 역할을 하는 녀석이다. 여기에 row 값을 주면 이 컨테이너는 행이 되어 한줄에 하위 요소들을 정렬시켜 주고 column 값을 매기면 열이되어 감싸주게 된다. body 엘리먼트의 layout이 바로 이런역할을 해주어 하위 요소 전체를 열로 만들어준다.


그런데 코드를 이리보고 저리보면 갑자기 의문이 들것이다. css에는 md-toolbar에 관한것이 아무것도 없는데(사실, css는 하나도 건들지 않았다) 왜 저런 푸르딩딩한 색상이 입혀져있는 것인가?? 저거 못바꾸는거야?? 뭐 이런 생각들. 누누이 얘기하지만 내가 그렇게 생각했었기 때문에 전혀 문제될 것 없다. 멍청하면 나처럼 부지런해지니까.


머티리얼 디자인으로 다시 돌아가서 색상 메뉴를 확인해보면 현재 am에서 사용하고 있는 컬러 팔레트를 확인할 수 있다. 19가지의 컬러 팔레트 중 테마를 하나 선정하여 고를 수 있다. 그렇다. 19가지 밖에는 없는것이다. 지쟈스... 뭐 이렇게 제한을 걸어둔것인가... 그러면 이제 css 떡칠을 해야할 것인지 고민에 빠질것이다. 물론 나 역시도 초반에 그런 ㅂㅅ짓을 시전할 뻔 했다.


다행히도 am은 $mdThemingProvider 서비스를 제공한다. 이 서비스는 19가지의 컬러팔레트의 기본 세팅을 바꿀 수 있으며 추가할 수도 있게 만들어준다. 오호 멋지다. (근데 처음부터 이렇게 안만들었으면 더 좋았을 수도...) 그런데 명세를 보면 볼수록 더 미궁에 빠지기 시작한다. 도대체 색상을 어떻게 추출해야되는 것인가?!

아니 몇개나 해야되는건데?? 왜 이따위로!!!!!


그렇게 좌절하다가 찾았다.


https://angular-md-color.com/#/ 이곳에 가서 원하는 색상을 추가하면 그것에 맞게끔 팔레트를 생성해주며 심지어 코드까지 제공한다. 색상의 디폴트는 500이니 필요에 따라서 수정하여 사용하면 되겠다. 기존의 색상으로 교체해 사용하길 원한다면 $mdThemingProvider 서비스에서 팔레트 이름을 선택하면된다. 표기법은 명세에 자세히 나와있으니 참고하면 되겠다.


뭐... 간략하게나마 Angular Material에 대해서 알아보았다. 아직은 상용 어플리케이션 개발에 다른 커스터마이징 없이 바로 적용하기에는 무리가 따르는 부분이 많다. md-data-table 같이 15년도 여름에 나왔어야 할 부분이 아직 나오지 않은 것처럼 여러가지가 미비하고 시각적인 부분 역시도 조금은 과하다 싶은 여백과 높이값 등의 문제들이 존재한다. 하지만 UI Bootstrap에 조금 지쳐있던 나로서는 사용하기에 무리가 없다고 판단했기에 현재 am을 즐겨 사용하고있다. 이 외에도 AngularJS 자체의 IE 호환성 문제가 있기에 사용과 적용에 앞서서 신중한 고민과 논의가 필요할 것 같다.

'Front' 카테고리의 다른 글

JavaScript[ECMAScript] 2. 불리언 타입  (0) 2016.07.08
JavaScript[ECMAScript] 1. 데이터 타입  (0) 2016.07.07
Ionic 하이브리드 앱  (0) 2016.06.28
AngularJS $watch  (0) 2016.06.16
HTML의 의미와 좋은 마크업  (0) 2014.12.30

$watch란 무엇인가?


AngularJS는 '안굴러'가는 '자바스크립트'가 맞다...


'$watch는 두려워할 정도로 어렵지 않으며 단순하고 또 유용하다'고 누군가의 기술 블로그에서 본적이 있었다... 물론, AngularJS에 대해서 선행지식이 어느 정도 있다면이라는 가정이 생략되었지만 말이다.


처음 이 $watch라는 녀석을 접했을 때에는 어느 상황에 써야되는지, 또한 $apply와는 뭐가 다른것인지 한참을 헷갈렸었다. (뭐... 혼자서 말도 안되게 무료 코드스쿨 강의만 보면서 B2C 웹앱을 만드는 중이었으니까...) 뭐 그렇다고 지금은 완벽히 명세를 이해했다는 것은 아니지만 아무런 스키마없이 개발을 해야했던 그 시기와는 좀 다르게 '써야 할 때'와 '고쳐야할 곳'을 어느정도 알겠다는 느낌(?!)은 온다.



$watch(watchExpression, listener, [objectEquality]);

Registers a listener callback to be executed whenever the watchExpression changes.



위 내용은 AngularJS의 $watch 메서드에 대한 공식 명세이다. 잘 보면 알겠지만 잘 보아도 모를 내용이다.

첫번째 인자인 watchExpression이 변하는 것을 감지하여 실행된다 정도로 알면 되겠다. 그런데 이것은 어떠한 상황에 적용되는 것인가??



1.외부연동


외부연동이 무엇을 기준으로 외부와 내부를 나누는가 부터 헷갈리기 시작한다면 당신은 나와 비슷한 과이다. 그러므로 친절히 설명은 하겠지만 내가 적는 이 글자들 역시도 내가 잘 못알아 먹기 때문에 세심한 주의와 다른 레퍼런스의 참고를 바란다.


예를 들면 제이쿼리나 다른 프레임워크를 AngularJS와 병행하여 사용할 때 스코프 내 변경 사항이 있을 때 다른 프레임워크에서 해당 변경 사항에 맞는 코드를 호출할 수 있도록 만들어 주는 것이다.



2.내부연동


그렇다면 내부연동할 때는 무엇을 해야하는거지?? 그럴때에는 $apply 메서드를 사용하면 된다. 다른 프레임워크에서의 변경사항이 발생했을때 AngularJS에서는 그 변화를 인지하지 못하므로 그것을 명시적으로 해결할때 사용하는 것이다.



기본적인 컨셉이 잡혔다면 쉬운 예제를 하나 만들어보도록 하자.





** 물론 실제 개발을 하면서 이렇게 무식하게 한글 텍스트를 '감시'하면서 리스트를 늘리는 일은 극히 드물것이다. 그렇지만 이게 가장 효과적으로 보여줄 수 있는 예제임에는 분명하다. alert으로 정신건강을 해하는 것 보다는...


코드를 보자. 첫번째 인자는 위에서 설명한 것으로 감시할 대상을 리터럴 형태로 표기하여 준다. 두번째 인자는 리스너이다. 여기에서는 새로운 값과 오래된 값 두가지의 인자를 받는데 만약 항상 모델의 값을 비교해야할 필요가 있다면 유용하게 써먹을 수 있을것이다.


위의 예제에서는 사용하지 않았지만 세번째 인자는 객체 동등성에 대한 평가로 알고있다. 물론 사용해 보진 않았다... 더 머리가 아플수도 있기에. 값은 boolean 타입.


$watch와 $apply의 차이만 알아도 AngularJS는 조금 더 친숙하게 러닝커브가 히말라야에서 백두산 정도로 우리에게 가까워질(응??!!) 수 있을 것이다.

'Front' 카테고리의 다른 글

JavaScript[ECMAScript] 2. 불리언 타입  (0) 2016.07.08
JavaScript[ECMAScript] 1. 데이터 타입  (0) 2016.07.07
Ionic 하이브리드 앱  (0) 2016.06.28
Angular Material  (1) 2016.06.17
HTML의 의미와 좋은 마크업  (0) 2014.12.30

Java나 C와 같은 개발 언어와는 다르게 HTML은 비교적 많은 이들이 쉽게 접근할 수 있는 언어입니다.(그래서 생기는 부작용들도 많지만...)


그런데 이렇게 쉽게 접근할 수 있는 언어를 사용하는 사용자들을 보면 코딩의 품질이 많이 떨어지는데, 그 이유는 무엇일까요?! 왜 쉬운 언어임에도 불구하고 코딩의 품질은 전체적으로 낮을까요?!


오늘은 HTML의 의미와 좋은 마크업에 대해서 알아보도록 하겠습니다.

(여기서는 시각적으로 우수한 마크업이 아닌 HTML 부분만을 언급합니다.)



HTMLHyper Text Markup Language의 약자로 Hyper Text와 Markup Language의 결합어입니다.


여기서 Hyper Text란 인터넷의 아버지라 불리우는 [테드 넬슨]이 처음으로 고안해낸 개념으로, 참조(하이퍼링크)를 통해 사용자가 한 문서에서 다른 문서로, 혹은 동일한 문서 내에서 이동할 수 있도록 만든 텍스트를 말합니다.


두번째로, Markup Language란 원래의 내용에 그것을 식별하거나 부가적인 정보를 표시하는 언어를 의미합니다. 쉽게 설명하자면 공부를 하며 교과서 안 텍스트나 그림 등에 표시를 하거나 추가로 설명을 다는 모든 행위에 사용된 글로 생각하시면 될 것 같습니다.


위의 두가지의 의미가 합쳐져서 만들어진 것이 바로 HTML입니다. 아마 이 글을 읽고 계신 분들 중에는 '아~ 그렇구나~'라고 생각하고 계시는 분들이 많을 것 같습니다.


이렇게 아주 기초적인 HTML의 어원과 기본 개념에 대해서 상세히 밝히는 이유는 이를 알아야만 좋은 품질의 마크업이 무엇인지를 조금 더 명확하게 깨달을 수 있기 때문입니다.


그러면 좋은 품질의 마크업이란 무엇일까요?!


제작하시는 분들마다 조금씩 우위를 두고 생각하시는 기준이 다르겠지만 거의 대부분의 프론트엔드 개발자 분들은 시맨틱 마크업이라 말씀하실 것 같습니다.


그렇다면 다시 시맨틱 마크업은 무엇을 의미할까 궁금해지실 겁니다.


Semantic은 '의미론적인'이라는 뜻을 가지고 있는 단어입니다. 해석하자면 '의미가 분명한 마크업'을 바로 시맨틱 마크업, 혹은 의미론적인 마크업이라고 할 수 있겠습니다. 마크업이라는 행위 자체가 바로 추가적인 정보를 다는 행위인데 그것의 정보가 올바르지 않다면 아무리 시각적으로 훌륭하고 UI가 뛰어난 웹 사이트라 하더라도 좋은 품질의 마크업으로 이뤄진 것이라 할 수 없습니다.


'의미가 분명한 마크업', 즉 시맨틱 웹은, 모두가 알고 계시는 '월드 와이드 웹'의 창시자인 [팀 버너스 리]가 1998년 제안하였습니다. 시맨틱 웹을 제안하기 전 HTML의 주된 기능은, 단순히 정보를 보여주기 위한 수단이였습니다. 그러다 인터넷 사용자들이 폭발적으로 늘어나고 사용자들에 의하여 그 이상의 정보가 생성되는 것이 반복되자 이러한 정보들을 연결하기 위한 도구가 필요해졌습니다. 이 과정에서 탄생한 것이 바로 검색엔진입니다.


하지만, 검색엔진이 정보를 찾는데 단순히 보여주기만을 위한 마크업이 문제가 되었습니다. 레이아웃을 이유로 <table>로 태깅한 웹 사이트가 특정한 정보를 담고 있는 표를 찾는 사용자들에게 나타나고 사물의 정의를 알고 싶어서 단어를 찾으면 <dt>를 사용하여 다른 정보를 집어넣은 정보가 검색되었던 것입니다.


그렇다면 단순히 고품질의 마크업은 검색엔진을 위한것일까요?!


우리의 삶 주위엔 어디에든 정보가 있습니다. 일할 때에도, 놀 때에도 정보가 있습니다. 정보가 발생하는 출처의 양이 많고 적고가 중요한게 아닙니다. 중요한 건 정보가 연결된다는 것이지요. (팀 버너스 리 2009년 TED).


위 이야기는 [팀 버너스 리]가 TED 강연에서 언급한 내용입니다. 그가 말한것과 같이 [팀 버너스 리]가 가장 중요하다 여기는 것은 정보의 연결입니다. 정보와 정보를 연결하기 위해서 우리는 검색엔진이라는 '다리'를 사용합니다. 즉, 우리가 검색엔진을 위하여 바른 마크업을 해야하는 것이 아니라, 최종적으로는 그 정보를 사용할 사용자에게 그 정보를 전달하기 위하여 사용하는 것입니다.(그러니 프로그램 따위를 위해 노가다를 한다는 부정적인 생각은 버리시길...)


여러분이 생각하시는 좋은 마크업과 일치할 수도 그렇지 않을 수도 있지만 제가 생각하는 가장 좋은 마크업은 사용자가 쉽게 접근할 수 있는 마크업, 올바른 정보를 갖춘 마크업이라 생각합니다. 물론 검색엔진에서 쉽게 찾는다고 다 좋은 품질의 사이트는 아니지만 적어도 원하는 정보를 제대로 전달할 수 있는, 준비 된 HTML이야말로 좋은 품질의 마크업일 것입니다.


'Front' 카테고리의 다른 글

JavaScript[ECMAScript] 2. 불리언 타입  (0) 2016.07.08
JavaScript[ECMAScript] 1. 데이터 타입  (0) 2016.07.07
Ionic 하이브리드 앱  (0) 2016.06.28
Angular Material  (1) 2016.06.17
AngularJS $watch  (0) 2016.06.16

+ Recent posts