IT이야기/입코딩2017. 5. 30. 13:50

-딥웹(Deep web)의 정의


한때 인터넷에 떠돌던 떡밥이었던 딥웹의 정의에 대해서 한번 알아보겠습니다.

위키피디아에 등재된 딥웹의 정의입니다.


원문

The deep web, invisible web, or hidden web are parts of the World Wide Web whose contents are not indexed by standard search engines for any reason. 

The content is hidden behind HTML forms. 

It is estimated that the deep web makes up 96 % of the whole internet. 

The opposite term to the deep web is the surface web. 

The deep web includes many very common uses such as web mail and online banking but also paid for services with a paywall such as video on demand, and many more. 

Computer scientist Michael K. Bergman is credited with coining the term deep web in 2001 as a search indexing term.


깊은 웹 , 보이지 않는 웹, 또는 숨겨진 웹은 어떤 이유로 든 표준 검색 엔진에 의해 색인이 생성되지 않는 월드 와이드 웹의 일부입니다.

HTML 양식 뒤에 내용이 숨겨져 있습니다. 

딥 웹은 전체 인터넷의 96 %를 차지하는 것으로 추산됩니다. 

깊은 웹의 반대말은 표면 웹 입니다. 

딥 웹은 웹 메일 및 온라인 뱅킹 과 같이 매우 보편적으로 많이 사용 되지만 , 주문형 비디오 와 같은 페이 웰 (paywall) 이있는 서비스에 대해서도 많은 비용을 지불 합니다. 

컴퓨터 과학자 인 Michael K. Bergman은 검색 색인 생성 용어로 2001 년에 Deep Web 이라는 용어를 사용하여 창안 되었습니다.



먼저 Google, 야후, Bing, 네이버같은 일반 검색 엔진으로 검색이 가능한 웹을 표면 웹(surface web)이라 합니다.

그리고 그 대치 용어로 검색 엔진에 걸리지 않는 곳을 딥 웹(deep web)이라고 합니다. 


인터넷 하면 흔히 웹이라고 줄여 부르는 월드 와이드 웹만 생각하기 쉽지만 인터넷은 

"월드 와이드 웹, 전자 메일, 파일 공유(토렌트, eMule 등), 웹캠, 동영상 스트리밍, 온라인 게임, VoIP, 모바일 앱 등 "

다양한 서비스들을 포함합니다. 



딥 웹(deep web)은 이름에 웹(web)이 들어가지만 월드 와이드 웹뿐만 아니라 위와 같은 다양한 서비스들 중 검색 엔진에 걸리지 않는 컨텐츠들도 포함합니다. 

웹뿐만 아니라 다양한 서비스들을 포함하고 있기 때문에 딥 웹(deep web)보다 딥넷(deepnet)이 더 정확한 표현이라고 합니다. 영어 위키피디아에서도 deepnet으로 검색하면 deep web으로 문서를 넘겨줍니다.

접속 허가가 필요한 네트워크나 특정 소프트웨어로만 접속할 수 있는 오버레이 네트워크(overlay network)는 다크넷(darknet)이라고 부릅니다.

다크넷(darknet)은 인터넷처럼 이름에 net(network의 줄임말)이 들어가지만 Tor처럼 사실상 웹 서비스만 있는 경우에도 I2P나 Freenet과 함께 다크넷으로 분류합니다.

다크넷 중 웹만을 따로 다크 웹(dark web)이라고 부릅니다. 

딥 웹에 다크넷이 포함되고, 다크넷에 다크 웹이 포함됩니다. ex(다크넷 > 다크웹)

딥 웹이라는 용어를 다크넷이나 다크 웹을 가리키는데 잘못 사용하는 경우가 있습니다.

사람들이 흔히 오해하는것이 모든 딥웹이 범죄자들이나 사회의 어둠과 관련된 사이트들인 것은 아닙니다. 

딥웹을 찾아보던 중에 알게된 단어들인데, 다크넷, 다크웹, 딥웹 모두 같은 뜻은 아닙니다.


딥웹은 단순히 검색에 걸리지 않는 모든 사이트들을 포괄하는 단어입니다. 

(ex.기업의 내부 정보 페이지, 웹 관리 페이지, 전자 도서관의 데이터 베이스. 혹은 단순히 검색 엔진의 기술적인 문제 때문에 잡히지 않는 웹페이지 등)


구글, 네이버, 다음 등등에서 검색되는 나무위키는 표면웹이고, 검색되지 않고 직접 url 입력해서 들어가야 했던 리그베다 위키는 딥웹입니다.


검색엔진에 노출되는 사이트라면 검색을 통해 찾아 들어갈 수 있습니다. 하지만 검색을 막아버리면 이런 사이트는 검색을 통해 찾을 수 없고, 그 사이트의 주소를 아는 사람만 찾아갈 수 있습니다. 

전자가 표면웹, 후자가 딥웹이며, 어떠한 이유로든 자신이 개설하거나 운영하는 사이트가 대중에게 노출되기를 원치 않는 사람들은 검색봇을 거절해 버릴 수 있고, 딥웹의 정의 자체는 이런 사이트들의 통칭입니다.


다음 카페나 네이버 밴드에 친구들 동창회 모임 같이 그런 사이트들처럼 말이죠.

 

다만, 세상에는 나쁜 사람들도 있어서 이런 사람들은 남의 눈이 닿지 않는 곳에서는 나쁜 짓을 합니다. 

흔히 딥웹의 특징으로 거론되는 불법자료나 마약, 무기거래, 청부살인 등이 바로 이런 특성에서 기인합니다. 

표면웹에서 저런 짓을 했다가는 경찰에게 적발될 테니, 남에게 안 보이는(검색이 안 되는) 곳에 숨어서 하는 것입니다. 나아가, 어니언 네트워크처럼 이용자의 익명성이 보장되는 네트워크 역시 이런 식으로 설명할 수 있습니다. 


오프라인 가게를 예로 들면. 광고를 해서 이름을 알리는 보통의 가게가 표면웹이라면, 광고를 하지 않아 아는 사람들만 갈 수 있는 가게가 딥웹입니다. 


그리고, 딥웹가게 중에는 일반 손님은 받지 않고 회원만 들어갈 수 있는 더욱 폐쇄적인 가게도 있을 수 있습니다. 

이런 가게에는 VPN을 통한 인트라넷을 운용하는 가게, 검색이 안 되는 회원제 네이버 카페 같은 가게, 그리고 토르 브라우저로만 들어갈 수 있는 어니언 네트워크에 속한 가게 등이 이에 속합니다. 

이들을 대략 깊은 딥웹이라고 볼 수 있습니다. 

따라서, 나쁜 짓을 하는 사람들에게는 이런 회원제의 폐쇄적 가게가 더욱 유리할 하나, 익명성을 만들고 유지하는 사람들이 모두 나쁜 짓을 하는 사람들이라는 의미는 아닙니다.


또한 딥웹에서는 보다 더 질이 높은 전문적인 자료도 구할 수가 있는데, 위에서 언급했다시피 딥웹의 정의 자체를 생각해보면 질이 높은 전문적인 자료라는 것이 중2병스러운 것들뿐인 것도 아닙니다. 

딥웹의 정의는 생각보다 포괄적이라 포털에서 포착되지 않는 전공 지식만 모은 전문 사이트도 딥웹입니다. 


박사급 연구자들의 연구자료를 주로 필요로 하는 사람들은 역시 박사급 연구자들일 것입니다. 

그렇다면, 박사급 연구자료를 모아놓은 논문 페이지를 굳이 검색엔진에 노출시킬 필요가 없습니다. 쓸데없이 트래픽만 잡아먹을 테니까 말이죠. 그렇다면 내부에서만 검색 가능한 독자적인 네트워크를 형성해서 박사급 연구자들에게 그 네트워크에 가입해서 필요한 정보를 검색하라고 하면 됩니다. 

즉, 딥웹이라고 해서 불법적이고 더러운 것들만 딥웹 인 것도 아닙니다.

대표적으로 '국회도서관'의 자료가 딥웹 입니다. 

외부에서 온라인으로 열람할 수 없으나, 계약을 맺은 기관의 전산실 컴퓨터를 이용해서 열람할 수 있습니다. 

석박사 논문은 보통 국회도서관에만 있으므로 집에서 편하게 볼 수 없고 학교 도서관 등을 가야 하는 수고를 해야 합니다. 


흔히들 사람들이 딥웹에 대해서 생각하는 건 2011년도 쯤 전후로 해서 오늘의 유머를 중심으로 다른 각종 커뮤니티에서도 퍼져나간 인터넷을 떠돌던 떡밥입니다.


내용인 즉슨, 


인터넷 세계에는 각종 포털 검색에도 걸리지 않는 그들만의 리그가 있으며, 그곳에서 돌아다니는 내용이란 우리의 상상을 초월한다는 것입니다. 

간단히 말해 우리가 쉽게 구해볼 수 있는 성인 동영상이 일반 커피면 딥웹을 돌아다니는 동영상은 TOP라는 내용입니다. 때문에 이중 삼중의 프록시 우회를 시행하는 Tor라는 브라우저를 통해서만 접근이 가능하고 여러 해커들이 암약하고 있다고 이야기 합니다. 


내용만 들으면 엄청 섬뜻하네요.

나무위키에서 이 내용에 대한 의견을 발췌해 보았습니다.


정확히 말하면, 위의 글쓴이는 딥웹과 어니언 네트워크를 착각한 것입니다. 

기본적으로 딥웹은 외부에 노출되지 않도록 만들어진 네트워크이고, 그런 네트워크를 만드는 기술 중에는 이용자의 익명성을 보장하는 다중 우회 브라우저인 tor로만 접속할 수 있도록 주소를 암호화하는 기술이 있으며, 이 기술로 만들어진 사이트들을 어니언 네트워크라고 분류합니다. 

그런데 위 글쓴이의 경우 어니언 네트워크=딥웹이라고 착각하여 딥웹에는 tor 브라우저로만 접근할 수 있다고 기술한 것이며, 해당 글에 줄줄이 늘어서 있는 url들 역시 어니언 계열의 사이트만 늘어놨으니 토르 브라우저로만 접속할 수 있는 것이 당연합니다. 


비유적으로 설명하자면 

서울 버스나 지하철을 타려면 서울 교통카드가 필요한데, 글쓴이가 서울 외 다른 지역에도 대중교통이 있는 걸 잘 몰라서 

'대중교통을 이용하려면 서울 교통카드라는 것이 있어야 합니다.'

라고 말한 것과 같다는군요. 

저런 주소들은 애초부터 토르 브라우저 이외의 수단으로는 접근할 수 없도록 암호화 해 둔 것이다.


전 개인적으로 음모론을 믿지는 않습니다. 정당한 의심은 있을수 있지만 실상은 별거 아닌 사실을 무지에 대한 공포를 너무 키워주는것같거든요.일반인들이 서핑으로 잘 찾기 어려운 자료들이라 그렇지, 딥웹에 있다는 자료들이 실상은 딥웹에만 존재하는 자료들은 아닙니다.

인터넷에 떠도는 링크걸린 딥웹 사이트들은 일부 불법 웹사이트들이 기재되어있고, 그것을 클릭하는 순간부터 경찰에게 어그로를 끌 수가 있으니 애초에 웬만하면 들어가지 말라고 권합니다. 

강력한 익명성을 보유하는 게 쉽지도 않을 뿐더러 정신건강에 썩 좋은 웹사이트도 아니거니와 컴퓨터를 혹사시키고 바이러스를 먹이는 근원지가 될 수 도 있습니다.


딥웹이 위키피디아에서 언급한대로 전체 인터넷의 96 %, 인터넷 데이터의 대부분이라고 이야기 하지만

 

"개인간에 주고받는 E메일이나 카카오톡, 텔레그램, 스카이프 등 메신저를 통해 주고받는 대화, 

각 개인이 클라우드 서비스에 업로드한 각종 자료, 

인터넷 전화의 통화내용 등 "


이런 정보들은 분명히 인터넷의 일부이지만, 당연히 당사자 외 다른 사람은 검색 등을 통해서 접근할 수 없으므로 명백한 딥웹입니다. 통상적인 인터넷 사용자들이 인터넷 상의 정보나 자료라고 잘 인식하지 못하는 것들이 이런 딥웹의 인터넷 트래픽 중 상당부분을 차지하고 있다는 것입니다. 

정확히 집계하기는 극히 어려우나 딥웹의 정보량은 분명히 방대합니다. 하지만 저 위에 예시로 든 데이터들 처럼 다른 사람에게 딱히 쓸모 없는 것이 대부분입니다.


물론, 그렇다고 딥웹은 별볼일 없는 곳이냐..라고 제가 이야기 하기도 어려운게

나무위키에서 이야기하는 딥웹에 결론을 발췌하였습니다.


"딥웹은 실존하며 가벼이 넘길수 없다."



"

마약, 총기 거래, 고어, 야동들 같은 것들을 전문적으로 만든 페이지들이 있으며 마약, 총기거래 등이 정말 이루어 지는 것 사실이고, 일반인은 보지도 듣지도 못한 고어물이나 야한 동영상들이 딥웹에 있는것도 사실이다. 

범죄를 의미하는 딥웹이라면 분명 있긴 있고 더 많이 있을 것이다. 

그 실체를 정말 잘 아는 사람이라면 이미 범죄에 한 발 몸 담근 사람이니 함부러 떠들 수 없을 것이다. 

근데 애초에 범죄가 이 세상에 많은데 인터넷이라는 도구를 범죄에 쓰지 않으리란 법이 없지 않은가

휴대폰으로도 범죄 목적의 통화가 엄청나게 많이 이루어지는 것처럼 말이다. 

한국처럼 범죄가 적은 국가가 아니라 미국처럼 마약, 총기, 갱단 등이 많은 국가라면 더 그렇고, 

중동처럼 전쟁의 와중에 있는 지역, 중남미처럼 치안이 매우 열악한 곳에는 인신매매, 청부살인 정도는 흔히 일어나는 것을 다들 알고 있을 것이다. 

그렇다면 이라크 레반트 이슬람국가도 SNS로 테러범 모집하는 시대에 범죄자들이 인터넷이라는 유용한 익명 유지 도구를 사용하지 않을 리 없는 것이다. 

즉 범죄의 한 도구일 수도 있는 것이 딥웹이며 없어도 고전적인 방식으로 범죄는 이루어진다. 

흔히 하듯 토렌트로 야동을 공유하는 것도 범죄를 익명성을 유지하면서 하기 위한 수단인 점에서는 비슷하다. 

Tor보다 익명성의 정도가 약할 뿐이다.

"


이상으로 딥웹(Deep Web)이 어떤것이란 것을 알아보았습니다.

딥웹 중에 불법 사이트들이 일부 존재하는것은 사실이나, 한동안 인터넷에 떠돌던 루머처럼 모든 딥웹들이 거창하고 무섭기한 한 곳은 아닙니다.

인터넷도 사람이 만든 거고, 딥웹도 사람들이 관리를 하는 것이고, 하나의 수단이기 때문에 범죄에 쓰이는 사이트들도 있다는 것이죠. 그렇다고 함부로 접속해서 가득 심겨진 랜섬 웨어나 바이러스에 걸리는 행동은 피하는 것이 좋겠죠.


출처 : 위키피디아, 나무위키

Posted by Joseph514
IT이야기/입코딩2017. 5. 19. 10:02

-풀스택개발자(full-stack-developer)란 무엇일까요?

인터넷에서 개발자 커뮤니티에 글을 보거나, 구직란을 보면 full-stack-developer라는 표현이 있더군요.

한국에 잡코리아나 사람인에 보면 그냥 자바 개발자, php 개발자 이런식으로 몇년차 이렇게 된게 고작인데, 

유독 해외에 취업을 목적으로 링크드인이나 인디드 같은 구인구직 사이트에서 개발자 항목을 봐도 자주 보입니다.

풀 스택 개발자라니?

제 개발세발 영어로 해석해 보자면 모든것(Full)을 쌓은(Stack) 개발자(developer)라는 뜻이 아닐까합니다.

Stack overflow 등에서 쓰이는 Stack이 (깔끔하게 정돈하여) 쌓다[포개다]; 쌓이다, 포개지다. 이런 뜻이니깐요.

okjsp나 그외 유명한 커뮤니티에서도 이런거다 정도만 사람들이 이야기 하지, 위키피디아에 등제되 있지는 않군요.

개발자로 오래 종사하신 분들의 이야기를 들어보면 다양한 견해가 많은데요.

간단히 정리하면 백엔드, 프론트 엔드 다 건드릴수 있는개발자다?!

정도로 보이기도 하고, 처음부터 끝까지 홈페이지 하나를 뚝딱 만들 수 잇는 개발자이겠군요.

한국말로 번역했을 때 범용적인 개발자인지 전천후(어떠한 기상 조건에도 제 기능을 다할 수 있음)개발자 정도로 번역하더군요.

너무 없어 보이는 설명인데, 일단 구글링해서 풀스택 개발자에 대한 정의를 내린 사이트 두개 참고하여 구체적으로 풀 스택 개발자라 칭할 수 있는 자들이 가지는 소양으로 어떤 것들이 있는지 정리해보았습니다. 하나는 sitepoint이라는 사이트고 하나는 laurencegellert입니다.


sitepoint

원문보기

사이트 소개를 하자면 1999 년 Mark Harbottle과 Matt Mickiewicz에 의해 설립되었다고 합니다..

개발자, 디자이너, 프로그래머, 제품 제작자 및 기업가와 같은 웹 전문가가 웹 전문가를 대상한 사이트입니다.


추상적으로 어떤거다 라고 하지 않고, 정확히 어떤 프로그램을 어떻게 다루라고 언급하고 있군요.


전체 스택 개발자가 필요로하는 주요 기술 스택을 세분화하고 분류했습니다.

-System administration(시스템 관리):

1.Linux and basic shell scripting(Linux 및 기본 셸 스크립팅)

2.Cloud computing: Amazon, Rackspace, etc.(클라우드 컴퓨팅 : Amazon, Rackspace 등)

3.Background processing: Gearman, Redis(백그라운드 처리 : Gearman, Redis)

4.Search: Elasticsearch, Sphinx, Solr(검색 : Elasticsearch, Sphinx, Solr)

5.Caching: Varnish, Memcached, APC / OpCache(캐싱 : Varnish, Memcached, APC / OpCache)

6.Monitoring: Nagios(모니터링 : Nagios)

-Web development tools:

1.Version control: Git, Mercurial, SVN(버전 관리 : Git, Mercurial, SVN)

2.Virtualization: VirtualBox, Vagrant, Docker(가상화 : VirtualBox, Vagrant, Docker)

-Back-end tech:

1.Web servers: Apache, Nginx(웹 서버 : Apache, Nginx)

2.Programming language: PHP, NodeJS, Ruby(프로그래밍 언어 : PHP, NodeJS, Ruby)

3.Database: MySQL, MongoDB, Cassandra, Redis, SQL / JSON in general (데이터베이스 : MySQL, MongoDB, Cassandra, Redis, SQL / JSON)

-Front-end tech:

1.HTML / HTML5: Semantic web(HTML / HTML5 : 시맨틱 웹)

2.CSS / CSS3: LESS, SASS, Media Queries(CSS / CSS3 : LESS, SASS, 미디어 쿼리)

3.JavaScript: jQuery, AngularJS, Knockout, etc.(JavaScript : jQuery, AngularJS, Knockout 등)

4.Compatibility quirks across browsers(브라우저 간 호환성 문제)

5.Responsive design(반응형 디자인)

6.AJAX, JSON, XML, WebSocket

-Design:

1.Converting website design into front-end code(웹 사이트 디자인을 프런트 엔드 코드로 변환)

2.UI

3.UX

-mobile technologies.

1.iOS

2.Android

3.Hybrid: PhoneGap, Appcelerator

전체 스택 개발자가되는 것이 더 좋습니까?

풀 스택 개발자 란 신기술에 대한 열린 마음, 각각의 손을 더럽 히고 웹 응용 프로그램이 컨셉에서 완제품에 이르기까지 어떻게 완성되는지를 이해하는 것을 의미합니다.

"풀 스택 개발자 (full-stack developer)"라는 아이디어는 전문화가 이유가 있기 때문에 가능할 수 있는 모든 기술에 능통하지는 않습니다. 위의 각 영역에 대해 이해하고, 팀 구성원 간에 지능적으로 의사 소통하며, 상황에 따라 적절한 자산이 될 수 있도록 하는 것이 중요합니다.

풀 스택 개발자는 미래의 웹 개발에서 점점 더 중요한 역할을 담당하게 될 것입니다. 특히 개발 작업과 같은 개발 방법이 코드 개발을 담당하는 코드 개발자와 관리자 사이의 라인 인 소프트웨어 개발 회사의 필수 구성 요소가 될 때 더욱 그렇습니다 매일 설치 프로그램이 점점 더 가늘어지고 있습니다.

원문

Is it better to be a full-stack developer?

Being a full-stack developer means to have an open mind towards new technologies, having your hands dirty in each one and to have an understanding of how a web application gets done from a concept to design to the finished product.

The idea of a “full-stack developer” isn’t about being fluent in every possible technology there is, because specialization exists for a reason. It’s more about having an understanding in each of the areas above, to communicate intelligently between team members and to be a good asset if the situation needs it.

The full-stack developer will have an increasingly important role in the web development of the future, especially when development methods such as DevOps are becoming an essential part of software development companies, where the line between code developers and administrators who are responsible for code deployment and setup is getting thinner each day.

자 이중에서 제가 할줄아는게 뭐가 있는지 체크해봅시다.


리눅스 쉘스크립팅 언어, 클라우딩 컴퓨터(아마존 웹서버), 버전관리(cvs, svn, git), 가상화(virtualBox), 웹서버(Apache), 프로그래밍 언어(PHP, nodejs, java), 데이터베이스(Mysql, MongoDB, Oracle, Mssql)

시멘틱 웹(HTML, HTML5), CSS, javascript, Jquery, AngualrJS, AJAX, JSON, XML, Android, Hybrid Application 요정도 건드려봤네요.


나름 이것저것 건드려 봤다고 생각했지만 한 70%정도 밖에 만족을 못 시키는군요.

아쉽게도 저는 풀 스텍 개발자는 아닌가 봅니다. 


laurencegellert

원문보기

사이트를 소개하자면 미국 오리건 주 포틀랜드에 거주하는 소프트웨어 개발자인 Laurence Gellert의 웹 사이트입니다.

이 사이트의 글을 참고해 봅니다.

원문

Probably not, but Facebook can ask for it. I was told at OSCON by a Facebook employee that they only hire ‘Full Stack’ developers.  Well, what does that mean?

To me, a Full Stack Developer is someone with familiarity in each layer, if not mastery in many and a genuine interest in all software technology.

이게 뭔 말인가 하니, 페이스북(Facebook) 직원은 풀스택 개발자만 고용한다고 합니다.

풀스택 개발자는 모든 소프트웨어 기술에 대해 많은 지식과 진정한 관심을 가진 각 계층에 익숙한 사람입니다. 라고 정의하고 있군요.

layers of the full stack:

1. Server, Network, and Hosting Environment.(서버, 네트워크 및 호스팅 환경)

2. Data Modeling(데이터 모델링)

3. Business Logic(비즈니스 로직)

4. API layer / Action Layer / MVC(API 계층 / 액션 계층 / MVC)

5. User Interface(사용자 인터페이스)

6. User Experience(사용자 경험)

7. Understanding what the customer and the business need.(고객과 비즈니스에 필요한 것을 이해합니다.)

아마존에서 AWS 공짜로 1년치 사용하면서 리눅스 서버에 푸티로 접속해서 공부해 나갔습니다만 그것도 귀찮아서 안건드리고 있네요. 처음부터 끝까지 사이트 하나를 오픈할수 있어야 혼자 아르바이트를 하든 용돈벌이를 하든 하지 않을까 합니다.

나이 지긋하신 차장급 이상 개발자들은 한 우물을 파라고, java만 진득히 하다 보면, 다른 것들도 알게 될꺼라고 이야기하는 사람들도 있더군요. 

사실 한국 SI에서는 java만 해도 몇년을 먹고 살았고 앞으로도 먹고 살 수 있으니깐요.

어설프게 헛바람들 듯 트랜드 따라간다고 건드리고 제대로 못 배우는 것 보다는 한 언어를 좀더 깊이 있게 배울 시간도 모자를 수도 있구요.

목표로 저는 풀 스택 개발자를 목표로 공부해 나가 보고 싶습니다.


Posted by Joseph514
IT이야기/입코딩2017. 5. 18. 14:58

-반응형 웹 디자인이 무엇일까요?

웹 개발을 하다 보면 반응형 웹이 어쩌고 하는 이야기를 듣습니다.

저는 웹개발자이기에, 자세히는 모르지만 디자이너분들이 이야기하는 반응형 웹 디자인이 무엇인지 한번 알아보겠습니다. 앞전에 설명한 부트스트랩의 경우도 반응형 웹 디자인의 일부입니다.

부트스트랩 정의

-반응형 웹 디자인의 정의

반응형웹디자인. 영어로는 Responsive Web Design라고 하는군요.

웹 디자인 기법 중 하나로 웹(Web)에 접속하는 디바이스에 반응하는(Responsive) 디자인(Design)을 말합니다.

과거불과 몇 년전만 해도 웹사이트들은 대부분 데스크톱에서만 볼 수 있고, 또 데스크톱을 제외하면 웹(인터넷)에 접속 할 수 있는 기기가 거의 존재하지 않았습니다.

물론 피처폰 시절에도 인터넷 접속은 대다수 가능했니다만.(WAP,i-mode) 여러가지 문제로 일반적으로 사용하기에는 무리가 많았고, 설상가상으로 통신사에서 데이터 요금을 너무 비싸게 책정하는 바람에 거의 사용되지 않았습니다. 

인터넷 한두시간 사용했는데 요금 고지서에 몇십만원이 찍혀 나올 정도였으니 말이죠. 

이 데이터 요금이 현실화 된 것은 스마트폰이 대중화 되던 2010년 무렵부터였습니다. 

하지만 최근 기술의 발전으로 데스크톱 뿐만 아니라 스마트폰, 태블릿 PC, 텔레비전 등 대부분의 전자기기에서 웹에 접속 할 수 있게 되었습니다. 

하지만 이러한 전자기기들은 모두 다른 크기의 스크린을 가지고 있었고, 이를 최적화 시키기 위해 m.naver.com처럼 별도의 모바일 페이지를 제작하고 모바일 사용자일 경우 모바일 페이지로, 아닐 경우 www.naver.com처럼 기존 페이지로 이동하는 방식을 사용해왔습니다. 

그러나 이러한 방식은 문제점이 많았는데 대표적으로 당연하게도 모바일 페이지를 별도로 구현해야 한다는 점입니다.  이러한 문제점을 해결하기 위해 반응형 웹이 등장하였습니다.


넓은 의미로는 여러 장치의 다양한 특성에 대응하는 하나의 웹 문서 또는 사이트로써 브라우저의 크기(스크린의 크기)에 실시간으로 반응하여 크기에 따라 레이아웃이 변하는 웹 사이트라는 의미가 있는데, 이는 다양한 디바이스에 대응하여 최소한의 변화로 내용 탐색을 쉽게 하여, 사이트를 최적의 형태로 제공한다는 뜻입니다. 

또한 좁은 의미로는 CSS3 Media Queries, Fluid/Hybrid Grid Layout, Flexible Media Content 등을 이용/사용하여 구현한 홈페이지를 뜻합니다.


반응형 웹 디자인의 기법으로는 미디어 쿼리(Media Query), 유동형 그리드(Fluid Grids), 반응형 레이아웃,뷰포트(viewport)가 있다고 합니다.

반응형 웹디자인의 특징으로는 

1. 하나의 웹 : 하나의 콘텐츠에 오직 하나의 HTML 소스만 있습니다. 

특정 장치에 최적화된 여러가지의 HTML이 있으면 반응형이라고 부르지 않습니다. (CSS, JS 파일은 여러가지가 존재할 수 있습니다.)

2. 하나의 URL : 특정 장치에 최적화된 페이지로 연결되는 별도의 URL이 있으면 반응형이라고 부르지 않습니다.

을 들수 있겠네요.

반응형 웹 디자인은 유연한 레이아웃에 대응하여 항상 최적의 화면을 제공함으로써 다양한 스크린 사이즈를 지닌 디바이스에 적응하게 됩니다. 

그리고 반응형 웹이 일반 웹 디자인과 다른 큰 이유 중에 하나는 이 모든 기술이 하나의 소스로 구현 가능하다는 점입니다. 

보통 일반 웹 디자인의 경우에는 PC와 태블릿, 스마트폰의 브라우저 각각에 최적화시킨 소스를 개발하여 각 디바이스 별로 산출물이 생기기 때문에 초기 제작비용뿐만 아니라 추후 유지보수 인력과 비용까지 추가로 발생하게 됩니다.

요즘에는 다양한 스마트 기기가 계속해서 개발되고 있기 때문에 각각의 디바이스와 스크린 사이즈에 맞추어 사이트를 개발한다는 것은 거의 불가능에 가깝다고 볼 수 있습니다. 

하지만 반응형 웹은 하나의 소스를 수정하면 모든 스크린 사이즈에 맞추어 컨텐츠가 최적화되기 때문에 유지보수가 효율적이고, 사용자 입장에서도 기기에 구애받지 않고 항상 최적의 화면을 경험할 수 있다는 측면에서 반응형 웹의 장점이 고스란히 나타나게 됩니다.


반면 이러한 특징때문에 발생하는 단점이 있는데, 모바일 사이트에 비해서 무겁다는 점입니다. 

이는 사이트 속도와 직결되는 문제로, 사용자 입장에서는 불편하게 느낄수도 있습니다. 

반응형 웹 디자인은 모바일 사이트보다 읽어들이는 소스가 많아서 쓸데없는 데이터를 소비할 수도 있고, 더군다나 데스크톱 사이트와 모바일 사이트의 용도가 다른 사이트의 경우 이러한 반응형 웹 디자인은 걸림돌이 될 수 있습니다. 

이 때문에 서버 사이드 스크립트를 이용해 접속 기기에 따라 디자인을 선택적으로 적용하는 RESS(Responsive Design + Server Side Components)라는 기법도 있습니다. 

한국 한정이지만 아직까지도 쓰이고 있는 구버전 인터넷 익스플로러(주로 IE8 이하)에서 와장창 깨져버린다는 단점도 있다고 하네요. 미디어 쿼리로 반응형 웹을 구성하는 경우, 그걸 씹어먹고 적용돼버려서 결국에는 모바일 버전으로 보이게 됩니다. 특히 업그레이드에 제약을 받는 관공서의 컴퓨터가 심각한 편이라고 하네요. 

제가 근무하던 공공기관들은 그냥 모바일은 간단한 공지사항 정도만 볼수 있고, 대부분의 처리는 웹에서 할게 하였는데, 장점만 있는게 아니라서 쉽게 변경을 못하는거 같네요.

현재 보고 계시는 제 블로그도 원래는 반응형 스킨을 사용했는데, 데스크탑용으로 변경하니 속도가 좀 빨라진 거 같기도 하구요.

사람들이 반응형 반응형 그러던데, 무슨뜻인지 몰라서 벙쪄있던 적도 있었는데, 정의는 그렇게 어려운것이 아니네요.  반응형 웹디자인( Responsive Web Design)에 대해서 알아보았습니다.


출처 : 나무위키, 본인생각

Posted by Joseph514
IT이야기/입코딩2017. 5. 17. 09:31

이전에 웹표준에 대해서 포스팅하였습니다.


이번엔 웹접근성(web accessibility)에 대한 정의를 한번 알아보겠습니다.

제법 규모가 있는 사이트들은 일년에 몇회 이상 웹 접근성 컨설팅 업체를 통해서 검사를 받습니다.


W3C의 정의에 의하면 웹 표준성은 접근성, 사생활 보호, 보안, 국제화의 측면을 고려해야 합니다. 

이 중에 접근성을 흔히 '웹접근성'이라고 하고 웹 표준성과 함께 많이 언급되는 개념입니다. 

웹접근성은 장애 여부에 상관없이 누구나 원활하게 웹페이지를 이용할 수 있어야 한다는 것을 의미합니다. 

예를 들어 시각장애인의 경우 화면을 눈으로 볼 수 없기 때문에 그렇지 않은 사람과 같은 방식으로는 웹페이지를 이용할 수 없습니다. 

그래서 '스크린 리더'라는 별도의 소프트웨어를 컴퓨터에 설치해서 인터넷을 이용합니다. 

스크린 리더는 모니터에 비춰지는 내용을 인식해서 음성, 점자로 출력해주는 역할을 합니다. 

화면에 '메뉴'라는 텍스트가 있으면 이를 인식해서 '메뉴'라는 음성이 나오는 방식이라고 합니다. 

시각장애인은 이를 이용해 눈으로 보는 대신 소리로 들으면서 웹페이지에 담긴 정보를 이해할 수 있습니다. 

하지만 스크린 리더는 소프트웨어에 불과하므로 스스로 웹페이지의 내용을 분석해서 이건 무슨 내용이고 저건 무슨 내용이다라는 걸 이해할 수 없습니다. 

특히 이미지의 경우가 그렇습니다. '메뉴'라고 텍스트로 집어 넣지 않고 메뉴라고 그려진 이미지를 사용하면 비 시각 장애인의 눈에는 똑같이 메뉴라고 보이지만 소프트웨어 입장에서는 그저 이미지일 뿐입니다. 

그 이미지 안에 그려진 내용을 인식하는 것은 불가능합니다. 

그래서 되도록 이면 이미지를 사용하지 말고 소스 코드에 내용을 그대로 담는 것이 권장되며, 부득이하게 이미지를 사용할 경우 반드시 이 이미지가 어떤 내용인지 설명을 추가해야 합니다. 


<button>메뉴</button>

<img src="images/button.jpg" alt="메뉴 버튼" />


위와 같이 메뉴 버튼을 두 가지 방식으로 구현할 수 있습니다. 

윗줄은 <button> 태그를 이용해서 구현하는 방식이고 아래 줄은 버튼 모양의 이미지를 쓰는 방식입니다. 

둘 중 어느 방식을 쓰던 버튼의 기능은 그대로 구현할 수 있습니다. 하지만 되도록이면 윗줄의 방식을 쓰는것이 권장됩니다. 

이미 <button> 태그를 쓰고 있기 때문에 스크린 리더가 메뉴라는 텍스트가 담긴 '버튼'이라는 것을 사용자에게 올바르게 전달할 수 있기 때문입니다. 

하지만 부득이하게 이미지를 쓴다면 특히 버튼 특유의 회색 그라데이션을 견딜 수 없다면 alt라는 속성을 추가한 뒤 이 이미지가 무슨 이미지인지 설명하는 텍스트를 추가해주어야 합니다. 

이렇게 할 경우 비 시각 장애인의 눈에는 alt 속성에 쓰여진 '메뉴 버튼'이라는 텍스트는 볼 수 없습니다. 

하지만 스크린 리더는 이를 '메뉴 버튼'이라는 이미지로 인식해 사용자에게 정보를 전달하게 됩니다. 

이처럼 장애가 있는 경우에도 웹페이지를 원활하게 이용할 수 있도록 지켜야 하는 사항을 웹접근성이라고 합니다.



위키피디아에 등제된 웹접근성에서 고려해야 할 사항입니다.


시각: 실명, 색각 이상, 다양한 형태의 저시력을 포함한 시각 장애

운동성: 파킨슨병, 근육병, 뇌성마비, 뇌졸중과 같은 조건으로 인한 근육 속도 저하, 근육 제어 손실로 말미암아 손을 쓰기 어렵거나 쓸 수 없는 상태

청각: 청각 장애

발작: 깜박이는 효과나 시각적인 스트로보스코프를 통해 일어나는 뇌전증성 발작

인지: 문제 해결과 논리 능력, 집중력, 기억력에 문제가 있는 정신 지체 및 발달 장애, 학습 장애 (난독증, 난산증 등)



웹접근성 지침 한글번역본

자세한 웹접근성 지침에 관한 정보들이 있습니다.


네이버에서 '널리'라는 프로젝트의 일환으로 네이버 사옥 그린팩토리 2층에 '웹접근성 체험 부스'를 오픈했습니다. 

이 곳에 방문하면 누구나 무료로 실제 장애가 있는 경우 어떤 식으로 인터넷을 이용하는지 직접 체험해 볼 수 있다고 합니다.


널리 공식 홈페이지


웹접근성 연구소 아래에 사이트에 가입하고 들어가서, 코딩한 페이지가 접근성에 맞는지 문의할 수도 있더군요.

웹접근성 연구소


웹사이트는 모두가 사용할 수 있어야 합니다. 

별거 아닌거같아 보였는데 웹사이트를 만들려면 여러가지 고려해야 할 사항들이 많네요.



출처 : 나무위키, 위키피디아

Posted by Joseph514
IT이야기/입코딩2017. 5. 16. 17:25


-웹표준에 대해 알아보겠습니다.


웹개발을 하다보면, 웹표준이니 웹접근성이니 하는 말들을 인터넷에서 많이 사용하는데요. 

우선, 웹 표준이란 무엇인지 이 포스팅에서 한번 알아보겠습니다.

월드 와이드 웹의 측면을 서술하고 정의하는 공식 표준이나 다른 기술 규격을 가리키는 일반적인 용어입니다.

보통 인터넷을 이용할 때 같은 웹페이지라면 어느 브라우저를 사용하는지 여부에 상관없이 그 웹페이지가 똑같이 보이고 정상적으로 작동해야 함을 의미합니다. 

Acid 테스트를 통해서 웹 브라우저가 웹 표준을 준수하는지 테스트할 수 있습니다. 

W3C 웹표준 설명



이전에 엑티브x(Atcivex)항목에서 포스팅 하였던 데로 한국에서는 정부나 공공기관부터가 웹 표준을 무시하고 있습니다.


웹 사이트를 작성하는 데 중요도가 높아지고 있으며 웹 디자인, 개발과 관계가 있습니다. 

수많은 상호 의존성이 있는 표준들과 규격들 가운데 일부는 단지 월드 와이드 웹으로만 끝나는 것이 아니라, 인터넷의 관리 측면이기도 하며 이러한 표준들은 직간접적으로 웹 사이트, 웹 서비스 개발과 관리에 영향을 주고 있습니다. 

웹 표준을 완벽하게 지키려면 특정 브라우저에 의존하는 플러그인이나 코드를 완벽하게 제거해야 하는 것이 보통인데, 일반적인 브라우저에 공통적으로 제공되는 플러그인은 이 기준에서 예외가 되는 경우가 많습니다.

이러한 것들 모두 "웹 표준"이라고 부르지만 웹 표준으로 이동하는 것을 찬성하는 사람들은 사용성과 접근성에 직접 영향을 미치는 더 높은 수준의 표준에 초점을 두는 경향이 있습니다. 


더 넓은 뜻의 웹 표준은 아래를 이릅니다.


-W3C (World Wide Web Consortium) - 대표적으로 HTML과 CSS의 표준을 정한다.

-국제 인터넷 표준화 기구 (IETF)가 출판한 인터넷 표준 (STD) 문서

-국제 인터넷 표준화 기구 (IETF)가 출판한 RFC (Request for Comments) 문서

-국제표준화기구(ISO)가 출판한 표준들

-Ecma 인터내셔널 (이전 이름은 ECMA)이 출판한 표준들 - JavaScript 표준이 여기서 정해진다.

-유니코드 컨소시엄이 출판한 유니코드 표준과 다양한 유니코드 기술 보고서 (UTR)

-인터넷 할당 번호 기관 (IANA)이 운영하는 이름과 번호 레지스트리



-웹 표준이 중요한 이유는 무엇일까요?

산업표준이 왜 존재하는지, 도량형이 왜 존재하는지 생각해 보면 이유가 명확해집니다. 

산업현장에서 부품들의 표준화가 돼 있지 않으면 업체마다 서로 호환이 되지 않고, 같은 업체에서 생산하는 부품도 품질보장이 되질 않을 것입니다. 

웹 환경은 본질적으로 '통신'이기 때문에 더욱 더 표준화가 중요해집니다. 

비표준 '부품'이야 자기네 제품에만 독점적으로 사용할 거라면 크게 상관없지만 웹은 누가 어떤 장치를 어떤 방식으로 사용할지를 제공자가 통제할 수 없기 때문입니다.


2016년 기준으로 인터넷 사용 인구는 30억명을 훌쩍 넘어 갔습니다. 

사실상 전인류의 절반이 인터넷을 사용하고 있고 인터넷 트래픽의 거의 전부를 차지하는 게 웹 트래픽입니다. 

사용하는 사람이 많아지면 표준화는 반드시 해결해야 할 과제가 됩니다. 그것이 일개 개인의 프로젝트에서 시작되었든(월드 와이드 웹), 국제 연합 수준의 극대규모 프로젝트(미터법)였던 말입니다.


웹 표준이 없던 90년대 말 ~ 2000년대 초반에는 웹 사이트 개발자는 사실상 두 개의 사이트를 만들어야 했습니다. 

인터넷 익스플로러용과 넷스케이프용의 두 개로 말이죠. 

실질적으로는 각종 핵과 브라우저 판별 코드를 삽입해야 해서 3배의 노동이 들어갔다고 합니다. 

표준이 없으면 이렇게 더 많은 노동력과 시간이 듭니다. 사회 전체적인 비용이 증가하는 것입니다. 

시간과 예산이 빠듯한 상황에서 웹 개발자는 결국 하나만을 선택하고 나머지를 버릴 수밖에 없어지며 이는 정보 제공에 차별을 발생시킵니다.


인터넷에 정보는 차별없이 제공되어야 합니다. 


물론 이상과 현실은 다릅니다. 

드넓은 PC모니터 화면과 좁디좁은 스마트워치 화면에서 동일한 정보를 제공하는 건 말도 안 되는 소리이고 동영상 스트리밍 사이트가 맹인을 고려해야 한다는 말도 어불성설입니다. 

하지만 이상을 추구해야 하는 것은 맞습니다. 


즉 "이 사이트는 인터넷 익스플로러 6, 1024x768해상도에서만 이용하실 수 있습니다." 같은 말들은 횡포일 뿐입니다. 

본인이 갑이 아닌데도 불구하고 이런 횡포를 부린다면, 그건 장사하기 싫단 소리밖엔 안 됩니다. 


제가 처음 웹이랍시고 홈페이지를 만들어본게 2000년대 초반입니다.

지금와서 보면 포토샵이랑 나모웹에디터로 찍찍 그려서 제로보드 적용시켜 뚝딱 만들고 했었던게 기억나네요. 

그 당시에는 저처럼 웹표준이란 개념도 없이 자바스크립트로 도배하거나, 플래쉬로 도배된 사이트들도 많았습니다.

위에서 언급한데로, 어떤 해상도에 어떤 웹브라우저에서 최적화 되었습니다 라는 문구가 씌어진 사이트들이 많았습니다. 그리고 제 컴퓨터에서는 아주 잘 나오는데, 이게 학교 컴퓨터나 다른 사람들 피씨에서는 어긋나게 나오는 경우를 왕왕 보았습니다. 익스플로러에서만 나온다는 건, 윈도우 운영체제를 깔아야 한다는 전제로 하는데. 한국에서야 윈도우에 익스플로러 사용자들이 엄청나게 많고 예전엔 더 많았지만, 현재는 크롬 파이어폭스 사파리도 많은 점유율을 차지 하고 있습니다.


나무위키에 등재된 2000년도 초반의 웹표준을 무시한 홈페이지들의 특징을 말씀드려보겠습니다.


-대문이 단순히 '들어가기' 형태로 된 홈페이지들이 많았습니다. 

사이트에 관한 내용을 간단히 보여주는 오늘날의 대문과는 차이가 있었습니다. 

리뉴얼 전 NTX(구 엔젤하이로)나 사유화 사태 전 리그베다 위키의 대문도 개인 홈페이지로 출발하던 시절의 전통이 그대로 유지됐는지 이 방식을 쓰고 있었다고 합니다.

-프레임 구조를 채용한 홈페이지들이 많았습니다. 

지금은 CSS나 jQuery 등의 보급과 W3C의 프레임 구조 채용 지양 권고로 인해 프레임 구조를 채용하지 않는 추세이지만 그 당시에는 프레임 구조의 장점이 많았기 때문에 높은 확률로 프레임을 쓴 것입니다.

header, menu, main, footer 이런식으로 프레임을 나눠서 사용했던 기억이 나네요.

-배경음악을 깔아놓은 홈페이지들을 많이 볼 수 있었습니다. 

바로 앞의 '프레임 구조'의 특징을 활용해서 끊김없는 재생을 구현하면 금상첨화였습니다. 

당시 회선 환경상 MP3를 넣으면 용량의 압박이 심했던지라 MIDI가 대세였습니다. 

인터버드라는 사이트에서 대규모로 MIDI 음악 자료실을 제공해서 인기가 있었지만, 안타깝게도 2001년 가을을 즈음하여 저작권 문제로 문을 닫았습니다. 

나중에 WMA 같은 압축 스트리밍 파일이 보급돼 배경음악으로 쓰이기도 했습니다.

-알록달록한 글꼴 색상과 효과, 화려한 클립아트와 애니메이션 GIF 등이 많이 쓰였습니다. 

이러한 풍조는 웹표준 보급 이후 다소 사그라들었다고 합니다.

-표를 그릴 때 쓰는 <table> 태그로 디자인을 하는 홈페이지들이 있었습니다. 

아직 CSS가 보급되기 전인지라 지금은 어지간하면 CSS로 넣는 디자인적인 요소까지 당시에는 죄다 HTML 문서 안에 때려박을 수밖에 없었고 그래서 <table> 태그가 그나마 레이아웃 잡는데 안성맞춤이었던 태그였습니다. 

웹표준의 개념이 알려지고 HTML5와 CSS3가 널리 보급된 현재는 레이아웃용 태그와 <div> 태그를 쓰고 <table> 태그를 레이아웃용으로 쓰는 경우는 찾아보기 어려워졌습니다.

-초창기에는 자바 애플릿을 넣는 홈페이지들을 꽤 볼 수 있었습니다. 

하지만 자바 가상 머신이 필요하다는 문제점이 있었고 매크로미디어 플래시가 보급된 이후 점차적으로 자바 애플릿 중 일부가 플래시로 대체되었습니다. 

물론 플래시를 보기 위해서도 매크로미디어 플래시 플레이어 플러그인을 깔아야 했다는 점은 똑같습니다. 

현재는 자바 애플릿이 이미 사양길로 들어선 상태고 플래시도 사정은 비슷합니다. 다만, 둘 다 HTML5로 대체할 수 있다고 합니다.

-게시판이나 방명록은 높은 확률로 홈페이지 서비스에서 함께 제공하는 게시판이 달려 있었습니다.


지금와서 아카이브로 박제된 90~2000년대 초반 홈페이지들을 보면 이질감이 느껴집니다.

그만큼 사람들은 웹 표준에 익숙해 졌기 때문 일수도 있겠죠.


민원24같은 전자정부 사이트는 갑의 요건을 일부 충족하기 때문에 아직도 영업이 가능한 면이 있지만 이것도 시대를 역행한다고 볼수 있죠. 내년까진 다 갈아엎는다고 들었습니다.


지금까지 웹표준에 대한 정의를 알아보았습니다.



출처 : 나무위키, 본인 생각

Posted by Joseph514
IT이야기/입코딩2017. 5. 12. 15:13

-cms가 무엇일까요?


웹에서 흔히 쓰이는 표현으로 cms 솔루션이라는 말이 있습니다. 

여기서 cms가 무엇인지 알아보겠습니다.

제가 쓰고 있었지만 확실히 개념을 정리하지 못한 탓 인지, 사람들에게 이야기하기가 어렵더군요.

일단 구글에 cms라고 쳐봅니다. 위키피디아에 나오는 뜻을 봅니다.


CMS

자금관리서비스(Cash Management Service)의 약자이다.

Cash Management System의 약자이다.

Color Management System의 약자이다.

저작물 관리 시스템(Content Management System)의 약자이다.

컴퓨터 지도 제작 시스템(Computer Mapping System)의 약자이다.

Creative Music System의 약자이다.

Molecular Sieving Carbon의 약자이다. 정확히는 MSC이고, 제조 메이커의 상표명인 CMS로 널리 알려졌다.


참 사람 헷갈리게, 동일한 이름의 여러가지 다른 약자들이 많습니다.

금융쪽에서는 Cash Management System 라는 의미로 많이 쓰이는데, 웹에서는 보통 Contents Management System 콘텐츠 관리 시스템으로 쓰입니다.


-CMS(Contents Management System)

게시판 솔루션이나 레이아웃, 모듈과 같은 기능을 모아둔 솔루션입니다. CMS를 사용하면 클릭 한번으로 사이트를 만들 수 있습니다.게시판 관련 기능 같은 기본적인 작업을 자동화시키기 때문에 웹사이트 제작에 드는 시간이 많이 감소되며, 그만큼 개발속도로 빨라집니다. 기본적으로 파일/썸네일/캐시/등 프레임워크단위의 도구가 있기때문에 새로운 기능을 만들때도 간단하게 구현이 가능합니다.


뭐 말이 어려운데, 웹만들어보신 분들이라면 한번쯤은 들어본 제로보드라는 프로그램이 있습니다. 

제로보드4의 경우는 그냥 게시판만 만들기 때문에 CMS라 보기 어렵지만 제로보드XE부터는 확실히 CMS 같습니다.

그리고 그누보드의 경우도 웹빌더를 사용하면 CMS 비슷할정도의 기능을 합니다.


국산 cms의 경우는 XpressEngine,텍스트큐브,그누보드,킴스큐 정도 있습니다.

그리고 jsp용으로 만든 콘텐츠와이즈라는 솔루션업체의 유료 CMS 솔루션도 사용해본적이 있습니다.

해외 cms의 경우는 ocPortal, WordPress, WebGUI, Drupal, Rubedo, Ghost, Joomla 가 유명합니다.



근데 무슨 cms 라 함은 블로그 관리하고 만드는 설치형 블로그 같은 느낌이 드는군요. 제가 블로그 운영 노하우를 정리하는 포스팅도 몇개 끄적였었는데, 거기에 설명한 설치형 블로그들이 있네요.

실제로 워드프레스 같은것도 블로그 제작및 관리 운영에서 많이 사용되구요. 


-그러면 개인 블로그 만드는 프로그램들이 cms일까요?

물론 개인 블로그 설치용으로 사람들이 많이 사용합니다.

하지만 개인 블로그 외에도 커뮤니티 사이트나 쇼핑몰과 같은 사이트의 운영이 가능합니다.

공공 기관이나 기업, 뉴스 같은곳 에서도 워드프레스를 사용하는 곳이 제법 됩니다.


서울시 홈페이지, 워드프레스로 바꾼다

원문보기

서울시가 기존 홈페이지를 완전히 새롭게 뜯어고친다. 대공사다. 집으로 치면 가구와 살림만 남겨놓고 집을 통째로 허물고 다시 짓는 것과 마찬가지다.

이번 개편의 핵심은 홈페이지를 ‘워드프레스‘ 기반으로 바꾸는 데 있다. 워드프레스는 오픈소스 기반으로 제작된 블로그 저작도구다. ‘블로그 저작도구’라고는 하지만, 일반 웹사이트처럼 꾸미는 데는 아무런 제약이 없다. 오픈소스 기반이란 점도 큰 장점이다. 전세계 개발자들이 재능을 기여해 만든, 수많은 확장기능이나 테마를 아무런 비용 부담 없이 가져다 쓸 수 있다.

이 뿐 아니다. 철마다 공식 행사처럼 치르던 웹사이트 개편이나 판올림 작업을 하기에도 훨씬 편리하다. 홈페이지 콘셉트에 맞춰 테마만 바꾸거나 필요한 기능을 확장기능으로 붙이거나 빼면 된다. 특정 메뉴나 항목의 글꼴이나 폭, 여백 등을 조정할 때도 케스케이드 스타일시트(CSS)라 불리는 스타일 정의 파일만 고쳐주면 손쉽게 적용된다.

확장성도 뛰어나다. 워드프레스 다중이용자판인 ‘워드프레스MU‘를 이용하면 내 홈페이지(블로그)를 만들 뿐 아니라, 다른 이용자나 부처, 직원 등에게 블로그를 분양해줄 수 있다. 네이버 블로그나 티스토리 같은 블로그 서비스를 힘 안 들이고 자체 구축할 수 있는 것이다.

이렇게 블로그 기반으로 구축한 웹사이트는 검색엔진에서도 잘 노출된다. 국내 공공기관 홈페이지가 대부분 검색로봇의 접근을 막아뒀거나 ‘꼭꼭 숨기는 검색 능력’을 자랑하는 것과 비교해보자. 서울시의 결정이 얼마나 큰 변화인지 짐작할 수 있다.


 

구글에서 워드프레스로 만든 사이트라고 치면 제법 많습니다.

그리고 구직란에 php 개발자를 보면 거의가 워드프레스로 하는 프로젝트입니다.

사람들이 url 경로나 화면 같은걸 보면 어느정도 어떤 솔루션으로 만들었는지 감은 옵니다. 개발자 도구로 주석을 보든지요. 완전히 마개조 해버리면 이게 원래 어떤 솔루션을 기반으로 만들었는지 조차 알수없게 독자적인 사이트가 되겠지요.


제가 cms라고 하면 그누보드 5, 워드프레스, 제로보드 xe 정도 밖에 사용해 보지 않았지만 특징을 정리하면 아래와 같습니다.


-편리성

cms를 사용하는 이유는, 손쉽게 여러가지 페이지들을 만들수 있다는것이 첫번째 이유일거같습니다.

하드코딩으로 화면 하나 하나 찍어내는것보단 공통의 플렛폼에 제목 정도 바꾸어 주고, 몇가지 게시판 유형을 만들어 커스텀하는것이 훨씬 유지보수 및 제작에 용이할 것입니다.

-보안문제

예전엔 오픈소스였기에 경로나 db구조를 다른 사람들이 어느정도 유추가 가능했고, 관리자화면으로 가능 경로도 동일해서 '/ wp-admin' 이렇게 접근해서 공격 들어올수도 있겠죠. 보안상으로 취약한 문제도 있었지만 주기적으로 계속 업데이트가 되어가고 있으므로, 큰 문제 없이 관리가 가능합니다.

물론, 올라오는 보안 업데이트는 계속 받아주는 것이 좋겠죠. 아에 버전이 달라지면 기존에 만들어서 관리하던 사이트들이 호환되지 않는 문제도 생기는것 같습니다.(제로보드4->제로보드xe)

이럴 경우, 계속 이전 버전을 쓰면서 자체 보완 하던가, 아니면 다른 대체 솔루션으로 갈아타야 될것입니다.


특징이라면 이 오픈소스로 무료로 제공되는 국내, 해외 cms 솔루션들은 대부분 php입니다. jsp는 사실 호스팅 구하기도 어렵구 비싸죠. 


그런데 오픈소스라 하더라도, 기본 엔진 말고 그 외에 스킨이나 레이아웃들, 그리고 cms 엔진으로 만든 빌더들은 제작자들이 따로 저작권을 가지는 것 같습니다. 

그래서 그누보드나 제로보드 같은 솔루션으로 홈페이지를 제작해서 판매할 때 라이센스 문제에 유의해야 합니다.


여러 사람들의 피와 땀이 배여있는 소스코드여서 받아놓고 참고해보면 유익하고 재미있습니다. 

디비구조도 비효율적인것은 자신이 쓰기 적합하게 커스텀 하고, 자체 제작해보기도 하면 재미있을거 같네요.


제가 잘못 알고 잇는건지는 모르겠는데, 한국에서 보통 워드프레스 등의 cms를 통해서 사이트를 개발하고 관리하는 사람들은 퍼블리셔 분들이 많다고 들었거든요. 그만큼 내부의 기능이나 구조보다는 디자인에 더 투자할 수 있는 것이 아닌가 합니다.


출처 : 나무위키, 위키피디아, 본인생각



Posted by Joseph514
IT이야기/입코딩2017. 5. 8. 21:14


인터넷에서 많이 쓰이는 호스팅이라는 용어에 대해서 알아보겠습니다.


전 처음 블로그를 시작하려고 했을때, 나름 웹개발자라서 AWS 서버 구축해서 직접 제작한 블로그를 쓰던가 못해도 워드프레스 같은 cms 를 직접 제작해서 관리해보려는 생각을했습니다.

그러다 무료 호스팅을 신청해서 1년정도 개인홈페이지나 블로그도 만들어봤구요.

그런데, 느껴진게 귀차니즘의 압박으로 네이버 블로그나 티스토리 블로그로 갈아탔네요. 언젠가 가능하다면 개인 호스팅에 사이트를 운영해 보고싶기도 합니다.

일단 호스팅(hosting)이란 뜻을 정의해보면, 서버 컴퓨터의 전체 또는 일정 공간을 이용할 수 있도록 임대해 주는 서비스를 말합니다.

co.kr 이나 .net 같은 도메인과는 좀 개념이 다릅니다. 도메인(domain)이란 문자로 표시한 인터넷 주소입니다. 모를 때는 카페24같은 호스팅업체에서 도메인도 서비스하기에 같은 개념인줄알았습니다.

집에서 아무리 만들고 가지고 놀아도 외부에서 사람들이 보려면 본인의 컴퓨터를 서버로 쓰거나 간단한 작업정도는 쓸수 있겠지만 호스팅이 있어야 겠지요.

인터넷에 연결된 웹 사이트를 운영하기 위해서는 1일 24시간, 1년 365일 항상 인터넷에 연결된 서버 컴퓨터를 운영해야 합니다. 

학부생 시절에 동아리방 구석에 모니터와 키보드 없이 본체만 켜져있는 리눅스 서버를 돌려서 푸티로 접속하고 가지고 놀았던 기억이 있는데요.

만약 집에서 했다면 전기세, 인터넷 트레픽 때문에 눈치가 이만저만 아니겠지요. 개인학습이나 소수 인원이 쓰기엔 노는 데스크탑이나 노트북으로 서버환경 구성해서 사용해도 문제는 안됩니다만, 회원이 몇십명만 넘어가도 부화가 걸려서 버벅거리는게 느껴지더군요.

개인이나 기업 또는 단체가 이런 서버 컴퓨터를 독자적으로 구축하여 운영하기 위해서는 막대한 비용이 필요로 합니다.

이러한 문제를 해결하기 위해 전문 호스팅 업체가 미리 여러 대의 서버 컴퓨터를 구축한 뒤, 그 공간 중 일정 부분을 이용자들에게 임대해 주고 그 대가를 받는 서비스가 생겨났는데, 그것이 호스팅 서비스입니다.

유명한 카페24나 phpschool 같은 경우는 단돈몇백원에 한달의 호스팅을 제공해 주기도 합니다. 물론 사이트의 규모가 커지면 사용자수도 늘어나고 용량도 늘어나서 유지비가 많이 들겠죠.

호스팅 서비스에는 웹 호스팅과 서버 호스팅, 메일 호스팅 등 다양한 종류가 있습니다. 

-웹 호스팅 혹은 공유 호스팅(shared hosting)

개별 홈페이지를 운영하는 사용자를 위해 서버 컴퓨터의 일부 공간을 임대해 주는 서비스입니다. 

웹호스팅은 하나의 서버에서 여러 사용자의 사이트를 띄워주기 때문에 한 사용자가 서버자원을 과도하게 사용하게 되면 서버내 다른 사용자 페이지 처리속도에 영향을 끼쳐 업체마다 정해진 조치를 취합니다. 

물론 사용자측에서는 서버부하가 보이는 것도 아니고, 억울할 수도 있으나 아무래도 다른 서비스에 비해 저렴한 서비스라 감수해야하고, 조금 더 비싼 단독웹 호스팅은 어차피 혼자쓰기 때문에 중요한 사이트라면 돈을 더 내더라도 단독웹이나 서버호스팅을 쓰는게 낫다고 합니다. 

장점

저렴한 가격도 있지만 서버관리에 대해 신경쓸 필요가 없다는게 큰 장점입니다. 

단독웹 호스팅과 서버호스팅은 혼자쓴다는 점은 같지만, 웹호스팅은 서버에 손 댈 필요가 없습니다. 서버 호스팅에는 가상 서버(virtual private server) 호스팅과 단독 서버(dedicated server) 호스팅으로 나뉘는데, 가상 서버 호스팅은 서버의 일정한 공간을 KVM, Xen, OpenVZ 등의 가상화 기술을 이용하여 한대의 서버처럼 나눠주는 서비스이며 단독 서버 호스팅은 서버 한대를 전부 임대해 주는 서비스로서 일정 비용을 납부해야 합니다. 


-메일 호스팅

이메일 혹은 웹메일 계정과 공간을 임대해 주는 서비스입니다. 

기타 이외에도 쇼핑몰 호스팅, 리셀러 호스팅 등이 있습니다. 웹호스팅을 구매하면 해당 옵션에 메일 몇개씩 메일 호스팅은 기본으로 포함되어 있더군요.

호스팅 서비스는 스토리지에 따라서 SSD, HDD로 나뉘고, 운영체제에 따라서 리눅스(Linux) 호스팅, 윈도우즈(Windows) 호스팅로 나누기도 합니다.

하지만 해당 호스팅이 웹 호스팅일경우, 혹은 꼭 웹 호스팅이 아니라도 그냥 저렴한 리눅스 호스팅을 쓰는게 나은 경우가 있습니다.

많은 사람이 간과하는 부분이 있는데, 일부 호스팅 업체는 서버에 부담을 준다는 이유로 검색엔진 봇(구글봇, 네이버 봇 등)을 막아버리는 경우가 있습니다. 개인 자료관리용이라면 상관없겠으나 그렇지 않은 경우라면 아무리 열심히 홈페이지를 운영해도 방문자가 들어오지 않을수 있습니다. 검색에 민감한 홈페이지를 운영할 계획이라면 호스팅을 신청하기 전 검색엔진 봇을 차단해 두는지 여부 등을 미리 물어보도록 하거나 안전하게 단독형 호스팅을 사용하는 게 좋다고 합니다.


호스팅을 구매하기전 팁

워드프레스 같은 CMS 도구나 미디어위키같은 위키엔진을 설치하고자 할 경우, 서버 환경이 UTF-8기반에 PHP와 MySQL 버전이 최신으로 세팅 되어 있는지 꼭 확인하는게 좋습니다. 

PHP, Mysql 양쪽다 5 이상이면 괜찮다습니다. 단, 워드프레스나 미디어위키, XE 최신버전은 PHP 5.3 이상을 요구합니다. 

SSH 지원 여부도 중요한데. 호스팅에 따라 SSH가 지원되지 않는 경우가 생기면 홈페이지 관리가 불편해집니다.

제 실력이 짧아서 그런지 모르겠지만 php 라라벨 프레임워크 같은경우는 설정을 안해주면 아에 하지를 못하는경우가 생기더군요.

SSH가 지원되는 호스팅을 고르고 그렇지 않다면 cPanel 같은 관리자 툴이 제공되는지 꼭 알아보아야 할것입니다.

마지막으로 가장 중요한 것은 역시 비용입니다. 한국을 포함한 아시아권 서버의 비용은 전반적으로 비싼 반면 구미권 서버비는 상당히 싸다고 합니다. 저는 한국것만 써봤는데, 영어를 더 익혀서 북미에 미국호스팅이나 캐나다 호스팅도 한번 사용해봐야겠군요.


출처 : 나무위키, 본인생각

Posted by Joseph514
IT이야기/입코딩2017. 5. 8. 13:40

웹브라우저란 무엇일까요?


웹개발자라면 당연히 알아야 할 웹브라우저에 정의에 대해서 한번 알아보았습니다.

웹브라우저란 HTML 문서와 그림, 멀티미디어 파일등 월드 와이드 웹을 기반으로 한 인터넷의 컨텐츠를 검색 및 열람하기 위한 응용 프로그램의 총칭입니다.

현재는 사람들이 흔히 사용하는 익스플로러, 구글 크롬, 파이어폭스 등이 있습니다.

세계 최초의 웹 브라우저는 팀 버너스 리가 NeXTSTEP용으로 개발한 'WorldWideWeb'이라고 합니다. 

그후 크로스 플랫폼으로 된 line-mode browser가 CERN에서 개발되었으며, 1993년 '모자이크'라는 이름의 브라우저가 최초로 이미지를 바로 표시할 수 있는 기능을 넣고 월드 와이드 웹 붐을 타면서 큰 성공을 거두게 됩니다. 

이후 넷스케이프 네비게이터 등의 웹 브라우저가 만들어졌고, 넷스케이프의 점유율이 한때 86%를 넘는 시절도 있었으나 넷스케이프의 개발이 늦어진 틈을 타서 마이크로소프트의 전략(윈도우즈 98에 인터넷 익스플로러 4를 내장)과 인터넷의 폭발적 전파가 맞물려 넷스케이프는 급속도로 침몰, 인터넷 익스플로러(IE)가 전 세계 웹 브라우저 시장을 독점했습니다. 

(IE는 2003년에는 약 95%에 이르는 점유율을 기록했다고 하는군요.)

2000년 중반 인터넷 익스플로러(IE)가 기술적으로 계속 정체되어 몇 년째 IE6에 머무르고 있는 틈을 타서 모질라 파이어폭스가 점유율을 잠식하기 시작합니다. 

2008년 후반에는 구글 크롬등 새로운 웹 브라우저도 등장해 현재는 모질라 파이어폭스나 구글 크롬, 사파리, 오페라 등 다른 웹 브라우저가 서서히 점유율을 늘리고 있는 중입니다.

웹 브라우저의 점유는 곧 인터넷의 점유(혹은 지배)라고 해도 과언이 아닌데, 인터넷 자체가 다양한 문서의 집합체인 만큼 '특정한 프로그램'으로만 그것들을 온전히 열람할 수 있다고 한다는 것은 곧 인터넷 전체가 특정 프로그램에 종속된다는 것을 의미하는 것입니다. 

넷스케이프가 시장을 장악했을 때나, 이후 IE가 시장을 장악하였을 때 이러한 현상이 매우 심각하게 나타납니다. 

수많은 사람들이 이를 경고했고, 웹 표준을 지키자는 캠페인이 진행되었으며, 수많은 웹 브라우저들이 개발되었습니다.


웹브라우저가 하는일을 그린 만화

출처 Deviantart 

-인터넷 익스플로러(IE)의 독점이 장기화 되면서 발생되는 문제점

액티브X나 MS DOM 등 독자적인 기술이 마치 표준인 양 이용되면서 다른 브라우저들을 제대로 이용하지 못하는 악순환이 벌어지기도 하였고(국내는 아직도 이 문제가 심각합니다.), 

경쟁이 사라지면서 IE의 버전업이 늦어지기도 하였고(파이어폭스가 주목을 받기 전에는 IE7의 계획 자체가 없었습니다. 심지어 MS의 브라우저 팀이 해체됐을 정도였다고 하네요), 

이로 인해 사용자들이 신기술을 체험하는데 방해가 되기도 하였습니다.

그로 인해 마이크로소프트는 악의 근원이며, 인터넷 익스플로러는 그들의 무기라고 인식하는 사람들이 은근히 늘어나고 있습니다. 

물론 마이크로소프트가 인터넷 익스플로러의 높은 점유율을 이용해 일부 고압적인 정책을 편 것은 사실이나, 그보다 더 큰 책임은 무책임하게 비표준 기술을 남용한 일부 개발자나 웹 디자이너, 혹은 높으신 분들에게 있을 것입니다.

전 세계적으로 인터넷 익스플로러(IE)의 시장 점유율은 약 30%대로, 2012년 5월을 기점으로 점유율이 크롬에 의해 따라 잡혔으며 지속적으로 하락하고 있습니다. 유럽에서는 파이어폭스와 비등하며 러시아나 독일 등의 일부 국가에서는 오페라나 모질라 파이어폭스의 점유율이 높은 국가도 있습니다. 

전 세계적으로 보았을 때 점유율 탑 3는 인터넷 익스플로러, 모질라 파이어폭스, 구글 크롬이며 점유율 비는 4:3:2 정도이며 나머지 1을 오페라나 사파리 등의 브라우저가 점유하고 있습니다.

대한민국에서는 아직까지도 IE를 기준으로 만들어진 홈페이지가 아직 많이 있고, 많은 금융기관 및 정부 공공기관의 보안 체계가 액티브X로 되어 있어 현재까지도 시장 점유율이 70%대 정도 유지하고 있다. 파이어폭스나 크롬을 주 웹 브라우저로 쓰는 사람들도 금융 결제 때문이라도 IE를 완전히 버릴 수 없는 상황이다.

제 경험으로는 개발자가 웹표준에 맞추어 하면 그래도 상관이없는데, 예전부터 만들어져오던 사이트들의 경우 웹표준 따윈 개나 주는 상황이라서, 유지보수 업무로 프로젝트에 들어갔는데 싹 뜯어고치는 일이 생기더군요.

최근까지도 공공기관 사이트들 부터 엑티브엑스에 공인인증서 로그인을 해야되는 곳들이 많습니다.

고인물은 썩는다고, 다른 웹브라우저들에도 정상적으로 적용되는 스크립트와 css를 먹여야 겠지요.

사용하는 웹 브라우저가 웹 표준을 잘 지키는지, 즉 표준을 지키면서 개발되었다는 전제 하에 웹페이지를 개발자의 의도대로 표시할 수 있는지를 Acid 테스트에서 확인할 수도 있습니다.

황당하게도 하나의 애플리케이션에 불과했던 웹브라우저가 HTML5 등의 기술 발달로 거의 모든 애플리케이션을 잠식하고 있습니다.

이를테면 iPhoto 같은 데스크톱 애플리케이션이 담당했던 사진 관리를 지금은 Flickr나 구글 플러스 사진 등의 서비스가 대체해 나가고 있고 오피스 역시 구글 드라이브와 같은 웹 오피스의 도전이 거세졌습니다. 

아예 기존의 강자였던 MS와 애플이 웹 오피스 버전을 내놓는 지경이라고 합니다. 

웹브라우저의 성능과 하드웨어의 발전이 맞물려 나가면 앞으로 웹이 해 나갈 수 있는 일은 더욱 많아질 것입니다. 

게임이나 유틸리티 등등 웹만으로 구현하지 못하는게 없을 정도로 다양한 기능들이 있더군요. 그래서 웹 개발만으로도 향후 몇년은 더 먹고 살수 있을거같다는 생각이 듭니다.


출처 : 나무위키, 본인생각

Posted by Joseph514
IT이야기/입코딩2017. 5. 7. 15:22

-부트스트랩 프레임워크(Bootstrap Framework)에 대해서 알아보겠습니다.

요즘 웹에서 유행하고 있는 부트스트랩 프레임워크에 대해서 한번 알아보겠습니다. 

일단 부트스트랩 프레임워크는 트위터에서 시작된 HTML5 기반의 오픈 소스 웹 디자인 프레임워크입니다. 

시작은 디자이너 하나와 트위터의 한 개발자였지만 지금은 트위터에서 주도적으로 개발하고 있지는 않다고 합니다.

일단 부트스트랩의 장점들을 한번 알아보겠습니다.

트위터에서 사용하는 각종 레이아웃, 버튼, 입력창 등의 디자인을 CSS와 JavaScript로 만들어 놓은 것이라고합니다. 

웹 디자이너나 개발자 사이에서는 웹 디자인의 혁명이라고 불릴 정도로 폭발적인 반응을 얻는 프레임워크입니다.

그 이유는, 글자, 인용문, 목록, 표, 입력폼, 버튼, 이미지, 아이콘 등의 자잘한 것 뿐만이 아니라, 드롭다운 메뉴, 버튼, 탭, 리스트, 메뉴바, 페이지 이동 바, 알림 메시지, 썸네일, 진행 바 등의 웹 페이지에서 많이 쓰이는 요소를 거의 전부 내장하고 있기 때문입니다. 이 때문에 웬만한 웹 페이지는 부트스트랩의 CSS와 JavaScript, 관련 이미지만 설치하고 미리 지정된 CSS 클래스나 JavaScript 함수만 불러오면 트위터에서 쓰는 것과 엇비슷한 디자인이 뚝딱 만들어집니다. 거기다 PC용 디자인 뿐만 아니라 태블릿이나 스마트폰 같은 모바일용 디자인도 지원합니다. 

이 때문에 디자인을 할 시간이 크게 줄어들고, 여러 웹 브라우저를 지원하기 위한 크로스 브라우징에 골머리를 썩일 필요가 없습니다. 

크로스 브라우징을 위한 각종 핵도 들어 있기 때문이라고 합니다. 거기다 웹 브라우저 크기에 따라 자동으로 정렬되는 "그리드 시스템"을 채용하고 있기 때문에 하나의 웹 페이지를 데스크탑, 태블릿, 스마트폰 모두에서 무리없이 보게 만들 수 있습니다. 즉 반응형 웹 디자인을 지원한다는 의미입니다.

다들 아시겠지만 반응형 웹이란 웹 디자인 기법 중 하나로 웹(Web)에 접속하는 디바이스에 반응하는(Responsive) 디자인(Design)을 말합니다. 모바일 페이지를 따로 만들필요없이, 웹페이지 하나로 다 나온다는 이야기군요.

거기다 이게 오픈소스입니다. GPL은 아니고 MIT 허가서를 사용하는데, 재배포 면에서는 GPL보다 휠씬 자유로운 라이선스입니다. 

단 같이 들어 있는 아이콘은 CCL BY 3.0을 사용하므로 출처를 밝혀야 한다고 합니다. 소스까지 오픈되어있다 보니 여기서 파생된 프로젝트만 해도 수백 개를 넘어가더군요.

그렇다면 부트스트랩의 단점들은 어떤것이 있는지 알아보겠습니다.

단점은 디자인이 정형화 되어 있다 보니 비슷한 디자인의 페이지가 양산될 수 있다는 것입니다. 대게 부트스트랩으로 만든 사이트들은 모양이 고만고만합니다. 그러나 이건 오픈소스의 힘으로 극복이 가능하다고 합니다. 오픈소스이다 보니 사용자가 커스터마이징 하는 것도 자유롭고, 이 커스터마이징 한 것을 재배포해도 됩니다. 심지어는 상업적으로 판매하는 것도 허용한다고 합니다. 

하지만 우리나라에서는 심플한 디자인보다는 이미지를 많이 쓰는 화려한 디자인을 선호하는지라 부트스트랩으로 만드려면 소스를 처음부터 뜯어 고치다시피 코딩을 해야하다보니 인기가 없다고 합니다. 이것 이외에는 HTML5에 맞춰져 있다 보니 구형 브라우저 지원이 미흡하다고 합니다. 이 때문에 HTML5가 제대로 지원되지 않는 IE7,8의 경우에는 강제로 HTML5를 인식시키는 JavaScript 코드가 필요하고, 가뜩이나 JavaScript 해석이 느린 IE 구버전을 더 느려지게 하는 주범이 됩니다. 결국 이 때문인지 3.0에서는 IE8부터 정식 지원합니다.

부트스트랩이 적용된 사이트로는 나무위키, 리그베다위키, 리브레 위키, 티비플, 위키닷, XpressEngine 공식홈페이지 등이 있다고 합니다.

디자인에 크게 신경쓰지 않고 사이트를 뚝딱만들수 있어서 참 유용했는데, 웹디자인 프레임워크 치고는 좀 불편하다는 이야기도 있더군요.


출처 : 나무위키, 본인생각

Posted by Joseph514
IT이야기/입코딩2017. 5. 3. 19:59

-프로그래밍의 정의에 대해서알아보겠습니다.

"

진정으로 재능 있는 프로그래머에게 있어, 코드를 짜는 것은 사고의 부산물에 지나지 않는다.

For a truly gifted programmer, writing code is a side effect of thought.

-Paul Ford 원문보기

"



확실히 제 생각도 그렇습니다. 제가 재능있는 프로그래머는 아니지만, 코드를 짜는건 사고의 부산물에 불과하다고 생각합니다.

우선 Programming이라 함은 프로그램을 만드는 것을 뜻합니다. 그리고 여기에서의 프로그램은 대체로 컴퓨터에서 동작하는 프로그램을 말합니다. 

일반적으로 프로그래밍이라고 하면 대개 컴퓨터 프로그래밍을 뜻며 기술을 다루는 기술이라고 하기도 합니다.


프로그래밍을 하는 도구를 개발자 도구 또는 개발환경이라고 부르고 (IDE는 그 중 하나입니다) 프로그래밍 언어는 프로그래밍을 하는 방식 또는 절차를 말하며 프로그래밍을 하는 사람이 프로그래머입니다. 

단순히 개발자라고 해도 되지만 이건 범위가 너무 넓습니다.

프로그래밍의 프로그래밍인 메타프로그래밍(대표적으로 컴파일러 자체의 프로그래밍, C macro 작성, C++11 template 작성)이 코드를 자동 생성하는 경우를 제외하면, 프로그래밍은 결국 사람이 해야 합니다. 심지어 메타프로그래밍도 결국은 사람이 해야 하므로 프로그래밍이란 결국 사람의 일입니다. 


이론적으로도 그 유명하신 괴델의 "On Formally Undecidable Propositions of Principia Mathematica and Related Systems"을 적용하면 결국 프로그래밍의 완전 자동화란 불가능하다는 결론을 내릴 수 있습니다. 간략히 설명하면, 모든 명제에 대해 완전 자동화된 증명 시스템이 불가능함을 괴델이 보였고, 그러한 증명 시스템 또한 하나의 컴퓨터 프로그래밍에 속하므로, 모든 프로그램을 자동으로 만들 수 있는 컴퓨터는 존재하지 않는다고 합니다. 그렇다고 이게 영원할 일자리냐 하면 일단 인간에 의해 메타프로그램이 만들어지기만 하면 완벽히 인간의 개입이 없는 것은 아나지만 더 이상의 추가적인 개입은 필요가 없어진다고 합니다.

인공지능의 발달로 인해 프로그래머가 더이상 필요로 하지 않느니 마느니 라는 떡밥중에 자주 나오는 이야기입니다. 단순히 웹화면 짜는정도는 이제 프로그래머가 필요없을수도 있겠죠.

언제 밥줄 끈어질지도 모르니 계속 새로운 기술을 공부해야겠지요.


예전에는 사람이 수동으로 프로그래밍하던 어셈블리어를 이제는 컴파일러가 자동으로 만들어 줍니다. 그러나 사람이 할 일은 줄어들지 않았고 그저 능률만 늘었는데, 이는 구현보다 디자인에 더 집중할 수 있게 돼서 더 대규모의 소프트웨어 프로젝트가 가능해졌기 때문입니다. 물론 여전히 디자인에만 몰두하고 구현은 무시해도 될 정도로 프로그래밍 언어의 세계는 호락호락하지 않은데, 디자인 패턴이라는 것들이 결국은 디자인을 구현으로 옮기는 표준적인 기교들을 소개하고 있다는 것부터가 이를 반증합니다.


대부분, 아니 자주 사용되는 모든 프로그래밍은 라틴 문자를 그 기반에 둡니다. 쉽게 말해 유럽의 알파벳(주로 영어 알파벳)이 프로그램에 쓰인다. 한글이나 한자 등으로 프로그래밍할 수 있는 도구는 극소수에 불과합니다. 이 말은 한글 데이터를 뜻하는 게 아니고 한글 코드를 뜻합니다. 한글데이터는 지금 보는 이화면에서도 잘만 나오고 있습니다.

근데 이런 걸 지원하는 건 기술적으로 '전혀 대단한 것도 없고 정말 바람직하지 않은 시도' 라고 합니다. 

어느 나라 사람이든지 영어 잘 못 한다고 남이 짠 코드를 못 읽진 않지만, 한글이나 한자로 코드를 짠다면 재앙은 정말 끔찍하군요.


아폴로 계획 당시의 소프트웨어 제작 영상이라고 합니다.



이때도 참 프로그래밍이란게 후덜덜하네요.


프로그래밍 언어로는 절차적 언어, 객체지향적 언어 등등 여러 종류가 많습니다.

사람들이 흔히 사용하는 java, c, c++ 외에 웹언어로 php도 있고, javascript 등등 아주 많지요.

이 언어들 덕분에 제가 아직까지 먹고 살고 있습니다. 웹이 무슨 프로그래밍이냐 라는 커뮤니티의 글들을 한번씩 볼수 있는데, 페이스북도, 아마존도 다 웹언어라고 말씀드리고 싶네요.


출처 : 나무위키, 내 생각


Posted by Joseph514