IT이야기/입코딩2017. 6. 30. 16:17

-웹 풀스택 입문을 위한 약 500페이지 분량의 교재



인터넷 커뮤니티를 하던 중 웹 풀스택 입문을 위한 약 500페이지 분량의 교재를 무료로 배포라는 글이 있더군요.

예전에 풀스택 개발자에 정의에 대해서 한번 포스팅해 본적있는데, 좀 비약하자면 혼자서 웹사이트 제작이 가능한 사람을 이야기 한다는 이야기를 했었었죠.


okjsp에 올라온 글입니다.

웹 풀스택 입문을 위한 약 500페이지 분량의 교재를 무료로 배포하고 있습니다.


풀스택 개발자에 대해서 많이 배우고 싶은 저로서는 참고해 보고 싶은 자료가 아닐 수 없더군요.

많은 분들도 아시겠지만 혹시나 보시면 좋을까 해서 한번 포스팅해봅니다.

목차입니다.


<목차> 

1 기초 이론 

1.1 커리큘럼 소개 / 추상화 

1.2 컴퓨터 구조와 파일 

1.3 프로그램과 프로세스 

1.4 GUI/CLI, Shell, 파일 권한 

1.5 네트워크 


2 프로그래밍 연습 

2.1 프로그래밍 언어 

2.2 Node.js 설치 

2.3 기본 부품과 조합 

2.4 제어와 반복, 함수와 재귀, 에러 

2.5 명령형 프로그래밍, 스코프와 콜 스택 

2.6 객체지향 프로그래밍, 복사와 참조 

2.7 타입과 유추, 명명 규칙 

2.8 함수형 프로그래밍, 콜백과 클로저 


3 웹 프론트엔드 

3.1 웹 브라우저 

3.2 HTML 

3.3 CSS 

3.4 JavaScript 

3.5 모델링 

3.6 이벤트 시스템 

3.7 jQuery 

3.8 확장성있는 코드짜기 


4 웹 백엔드 

4.1 모듈, NPM 

4.2 스트림, 표준입출력, 소켓 

4.3 HTTP 프로토콜 

4.4 웹 브라우저의 Request 

4.5 정적 웹 서버의 Response 

4.6 동적 웹 서버 

4.7 Express.js 

4.8 쿠키와 세션, 인증 

4.9 동기와 비동기, Promise 

4.10 Ajax, WebSocket 

4.11 보안, Same Origin Policy 

4.12 REST API, OAuth, SPA 


5 데이터베이스 

5.1 메모리와 파일 

5.2 DB와 DBMS 

5.3 MySQL과 SQL 

5.4 Connector, SQL Injection, ORM 


6 개발과 배포 

6.1 패키지 매니저, 자동화 도구 

6.2 버전 관리, Git, GitHub 

6.3 호스팅, SSH, FTP 

6.4 DNS, 도메인, 메일 서버 (작성중) 

6.5 암호화, 전자서명, 인증서와 SSL 

6.6 비밀번호 해싱 


7 다른 플랫폼으로 

7.1 다른 플랫폼들 (작성중) 

7.2 GUI 프로그램 아키텍쳐, MVC 패턴 


게시글 하단에는

본 자료는 벤젠(Benzen)이 서비스하는 웹서비스 풀스택 워크샵 (workshop.benzen.io)에서 제공하는 컨텐츠입니다. 무단 전재 및 복제를 금합니다.

라고 적혀있더군요. 그래서 pdf를 퍼오지는 못하고 링크만 걸었습니다.


PDF 보러가기


아직 작성이 완료되지 않은 글들도 있긴 한데, 알기쉽게 하드웨어나 운영체제부터 개발, html까지 설명을 해주고 있습니다. 물론 풀스택 개발자라고 해서 모든 분야에 전문가가 된다는것은 아닙니다.

하지만 이 PDF를 통해서 제가 몰랐던 부분들을 좀 더 알 수 있게 되어서 좋았습니다.

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. 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