웹 프로그래밍

From Hidden Wiki
Jump to navigation Jump to search
필독 사항 유닠스 계열 저작물, 성인물, 도박 웹 써버 보안 프로그래밍 그래핔 파싱
필독 사항 고스트BSD 표면 웹 싸이트 제작 리눅스 마스터 파이썬 트킨터 뷰티펄 숲
수학 아이투피 마약, 아청물, 해킹 웹 싸이트 보안 웹 프로그래밍 데이터 분석 게임 제작
통계학 뮤와이어 다크넽 싸이트 제작 정보 보안 기사 쟁고우 팬더즈 파이게임

개요

웹 프로그래밍(web programming)은 웹 개발(web development) 중 프로그래밍 부분만을 말한다.

웹 프로그래밍 언어WWW에서 사용되는 프로그래밍 언어들을 통틀어 말한다.


오픈 소스 코드 에디터 중 가장 인기 있는 것은 Visual Studio Code( https://code.visualstudio.com/ )와 Atom( https://atom.io/ )이며, 지난 1년간 놀랍게 발전했다. 두 에디터 모두 최신 웹 기술을 이용해 만들어졌고, 커뮤니티의 수많은 개발자들에게 관심을 받고 있으며 리눅스, 맥OS, 윈도우즈를 모두 지원한다. 게다가 플러그인을 설치하여 각 프로그래밍 언어에 대한 문법 체크, 코드 최적화, 리팩토링을 비롯한 기능을 추가할 수도 있다.


리눅스상에서 웹 써버와 WAS(PHP, JSP, Node.js 등등...)을 설치해두고 개발은 에디터를 활용해서 개발합니다. 저같은 경우 개발을 시작할때 서버 하나 파서 우선 웹서버와 WAS 를 설치합니다. 아파치나 nginx 등 입맛에 맛는 웹서버를 설치합니다. 아직 환경변수 설정은 안됬기에 그냥 말그대로 웹서버만 설치한거죠.

다음으로 WAS를 설치합니다. WAS웹 애플리케이션 서버(web application server)의 줄임말로 비즈니스 로직을 수행하고 트랜잭션을 처리하는 미들웨어, 또는 그것이 수행되는 서버 컴퓨터이다. 보통 엔진엑스아파치같은 웹 서버와 DB 서버에 사이에서 위치한다. PHP 라면 원하는 버전의 PHP를 설치하고 웹서버와 PHP-FPM을 연동하죠. 그다음 CI나 라라벨(PHP의 웹 프레임워크 Laravel)같은 프레임워크를 다운받아 압축을 풀어 개발환경을 만듭니다. Python이라면 Django나 Flask를 설치하고 uWSGI나 Gunicorn같은 게이트웨이를 설치해서 웹서버와 WAS가 연동할 수 있도록 준비합니다.

이제 둘을 연동시킵니다. 웹서버가 HTTP 리퀘스트를 받아서 WAS에 전달해 줄 수 있도록 환경변수를 설정해 줍니다. VirtualHost 설정 이라고 검색하면 상세히 나옵니다. 아파치와 nginx가 설정방법이 다르기에 해당 웹서버에 맞게 설정해 주셔야 합니다.


기업들과 개발자들이 모두 클라우드를 도입하고 있다. 클라우드는 가상 컴퓨팅 인프라이며, 필요할 때 확장 가능하고 조작 페이지를 이용하여 설정을 마음대로 바꿀 수도 있다. 대표적인 클라우드 제공 업체는 아마존 웹 서비스(AWS), 구글 클라우드 플랫폼, MS Azure이다. 세 업체 모두 강력하고, 무한한 확장이 가능하며, 가상 머신을 지원하고, 데이터베이스를 호스팅하면서, 기계 학습도 가능한 서비스를 제공하고 있다. 이 회사들은 지속적인 경쟁을 통해 가격을 인하하고 있기 때문에 작은 회사나 개인 개발자들도 예산 부담 없이 서비스를 이용할 수 있다. 클라우드와 조금 더 친해지는 것도 2017년을 위한 좋은 투자가 될 것이다. 클라우드는 소프트웨어 업계 전반을 장악했고, 데이터센터를 운영하는 회사들은 데이터센터를 축소하거나 클라우드로 옮기고 있다.


Git은 여전히 가장 인기 있는 코드 버전 관리 시스템이다. 서버도 필요 없고 컴퓨터 안의 어떠한 폴더라도 저장소로 바꿀 수 있다. 코드를 공유할 때도 수많은 방법이 있으며, 몇 개를 꼽아보자면 GitLab, Bitbucket, GitHub과 같은 것이 있다. 2017년에는 git 커맨드 라인과 친해져보기를 추천하는데, 생각보다 편하고 자주 쓰게 될 것이다.


프로그래밍을 배우기 전에 찰스 펫졸드코드라는 책을 읽어보기를 추천한다. 영어판은 구글에 charles petzold code pdf라고만 쳐도 나오며, 한국어판은 도서관에서 빌리거나 사서 봐야 한다.

  • [Book] CODE 코드

https://blog.outsider.ne.kr/1053

  • 찰스 펫졸드의 코드:CODE

http://freesearch.pe.kr/archives/2406


프런트-엔드 웹 개발

흔히 HTML, CSS, 자바스크맆트 등의 단어를 들어보셨다면, 이 주제가 front-end web development 영역을 의미한다고 보시면 됩니다. 우리가 사용하는 웹브라우저가 이해하는 직접적인 기술들을 다루는 분야입니다. 인터넷 익스플로러, 사파리, 크롬 등의 웹브라우저들은 인터넷에서 문서를 받아와서 화면에 보이는데, 이 보이는 문서의 내용들이 들어있는 모양새라고 보시면 어떨까 합니다.


다른 거 빼고, HTML5, CSS3, JavaScript를 보시면 됩니다. 서툴지만 쉽게 얘기하면, HTML5는 웹문서 본문을 적는 텍스트 포맷이고, CSS3는 그 문서의 스타일을 다루는 속성들이며, 자바스크립트는 웹브라우저가 이해하고 실행할 수 있는 프로그래밍 언어입니다. HTML5와 CSS3는 평범히 적는 텍스트지만, 자바스크립트는 좀 더 본격적인 프로그래밍을 해야 합니다.


프론트엔드 기술만 다뤄도 내 컴퓨터에 저장한 파일로 웹브라우저 화면에 무언가를 보이게는 할 수 있습니다. 결국 나중에 백엔드와 마주쳐야 손뼉 소리가 나는 거지만요.


보통 프론트엔드에서 무언가 주문(요청)을 하고, 그 주문을 멀리서 받은 백엔드의 서버가 응답을 주고, 그 응답 내용을 웹브라우저가 화면에 표시합니다. 프론트엔드가 먼저 요청을 해서 서비스를 받는 입장이고, 백엔드가 그 요청을 받아서 작업을 처리하고 응답을 주는 입장이라서 각각 클라이언트 측(Client-side)과 서버 측(Server-side)라고도 부릅니다. 식당에 가면 손님(클라이언트)이 주문을 하고 웨이터나 웨이트리스(서버)가 주문을 받아서 주방에 전달해 요리를 만들어 다시 손님에게 가져다 주는 상황과 비슷합니다.


다크 웹 싸이트만 제작할 생각이라면 어차피 노스크맆트 때문에 자바스크맆트를 쓸 수 없으니 자바스크맆트는 안 배워도 되지만, 표면 웹 싸이트도 만들 생각이라면 JavaScript도 배워놓으면 좋다. 그리고 써버쪽 스크맆트로 노드.js(Node.js)를 쓸거면 자바스크맆트를 배워야 한다.


클라이언트-싸이드 코딩

  • 하이퍼 텍스트 마크-업 언어(Hyper Text Mark-up Language, HTML): HTML5라고 불리우는 개념은 단순히 웹 문서를 작성할 때 사용되는 마크업 랭귀지(HTML)의 문법적 (syntactic) 버전 뿐만 아니라 새로운 DOM API 스펙을 포함하는 것이다. 문법면에서는 이전에 비해 상당히 간결하고 명확해 졌는데, 또한 이전에는 JavaScript를 사용해서 엄청나게 긴 코드를 써서 간접적으로 구현해야 했던 기능들이 정식 엘리먼트로 편입됨으로서 (예를 들어 <video> ) 간단하게 구현해낼 수 있게 되었고, 불필요하게 길게 적어야했던 이전 버전에서 꼭 필요한 부분만 남기도록 바뀌는 등 여러가지 개선점이 생겼다. API면에서, HTML5에서는 비디오 및 오디오와 같은 미디어 엘리먼트에 대한 API뿐를 포함해 오프라인 웹 앱 구현, 문서 편집 등과 같은 다양한 기능에 대한 API가 추가되었으며, WHATWG에 의해 Geolocation, Web SQL, File API, Audio API등이 “Living standard”로 권고되고 있다.
  • 캐스케이딩 스타일 시트(Cascading Style Sheet, CSS): 과거에는 HTML에 디자인적 요소를 포함하여 작성하는 것이 일반적이었다. 다시 말해서 온갖 레이아웃, 디자인 정보를 HTML 안에 우겨넣다 보니 HTML의 본연의 목적인 구조화된 문서가 아닌 디자인을 위한 문서로 전락하고 말았다. 표를 작성해야 하는 <table> 태그가 레이아웃을 구성하는 용도로 쓰이는 등으로 인해 HTML 소스코드만 보면 이 문서가 어떤 문서인지 전문가조차 알기 힘든 상황이었다. 이에 따라 W3C에서는 "디자인적 요소를 HTML과 완전히 분리시켜 구조화된 HTML을 만들어보자!" 라는 목적으로 CSS를 발표했다. 2016년 현재는 CSS3의 애니메이션 기능과 3d 변환 기능 정도는 (IE 구버전을 제외한)주요 브라우저에서 표준으로 지원한다. 심지어는 그래픽 툴에서나 볼 수 있는 혼합옵션까지 지원한다.
  • 부트스트랲(Bootstrap): CSS의 프레임워크인데 다음과 같은 이득을 얻을 수 있다. 디자인 역량이 부족한 엔지니어 중심의 팀이 그럭저럭 괜찮은 디자인의 웹사이트를 만들 수 있다. 웹사이트의 UI를 컴포넌트 기반으로 설계할 수 있는 기반이 되어 디자인 및 개발 비용을 절감할 수 있다. https://wrapbootstrap.com/처럼 Bootstrap 테마를 판매하는 곳도 있다. http://bootsnipp.com/에서는 Bootstrap 기반의 다른 컴포넌트들도 가져다 쓸 수 있다. 어떠한 프론트엔드라도 Bootstrap을 빼면 구성이 다 되었다고 하기 어려울 것이다. 4버전은 현재 알파 단계이고 2017년에 정식 버전이 발표될 것으로 보인다. 주목할 만 한 새 기능으로 다용도의 카드 컴포넌트와 플렉스박스 그리드가 있고(일반 그리드와 비교), Bootstrap 프로젝트는 계속해서 나아지고 있어서, 사용하는 즐거움도 더해질 것이다.
  • 자바스크맆트(JavaScript): 프로그래밍 언어로, 스크맆트 언어(Script Language)에 해당된다. 특수한 목적이 아닌 이상 모든 웹 브라우저에 인터프리터가 내장되어 있다. 오늘날 HTML, CSS와 함께 웹을 구성하는 요소의 하나다. HTML이 웹 페이지의 기본 구조를 담당하고, CSS가 디자인을 담당한다면 JavaScript는 클라이언트 단에서 웹 페이지가 동작하는 것을 담당한다. 이 때문에 동적인 홈페이지가 필요없다면 JavaScript는 안 써도 된다. 그러나 2016년 현재 웬만한 홈페이지에는 동적인 요소가 들어가므로 거의 필수적으로 쓰이는 것이 현실.
  • 제이쿼리(jQuery): HTML 속 클라이언트 사이드 스크립트 언어를 단순화 하도록 설계된 브라우저 호환성이 있는 JavaScript 라이브러리이다. 존 레식에 의해, 2006년 뉴욕 시 바캠프(Barcamp NYC)에서 공식적으로 소개되었다. 현재 가장 인기있는 JavaScript 라이브러리이며 표준에 가까운 점유율을 자랑한다. jQuery는 한 개의 JavaScript 파일로 존재한다. 공통의 DOM, 이벤트, 특수 효과, Ajax 함수를 포함한다.
  • 앵귤러(Angular): 이 프레임워크는 구글의 지원을 받으며 대형 프로젝트에서도 큰 인기를 끌고 있다. 이 프레임워크는 데스크탑 웹과 모바일 앱 양쪽을 위한 수 많은 기능들을 마련해두고 있다. Angular 2는 타입스크립트로 작성되었고, 어플리케이션을 구현할 때도 타입스크립트를 권장하고 있다.

백-엔드 웹 개발

백엔드에서는 프론트엔드에 보여줄 HTML 문서를 그때그때 생성해서 내려줍니다. 한번 작성하고 잘 바뀌지 않는 내용들은 평범한 파일의 형태로 디스크에 저장해뒀다가 전달해주고, 그때그때 변하는 새로운 자료들은 요청시 클라이언트마다 다르게 만들어서 내려주고는 합니다. 전자를 정적(static) 페이지라고 하고, 후자를 동적(dynamic) 페이지라고 합니다. 모든 고객이 같은 걸 보는 메뉴판 같은 것을 정적(static) 자원이라고 보면 되고, 고객마다 다른 응대를 해주는 웨이터/웨이트리스의 응대 기술이 동적(dynamic)한 영역이라고 보시면 될 것 같습니다. 백엔드 개발이라 함은 대부분은 동적인 처리를 다루니 굳이 구분해서 이해하실 필요는 없습니다.


백엔드는 여러 고객의 요청을 한꺼번에 받아서 각각 제대로 처리해서 내려줘야 하는 동시성(concurrency) 처리 문제가 있어서 어려운 면이 있습니다. 요리 주문을 받은 주방에서는 요리사들이 다양한 재료를 한꺼번에 조리하면서 여러 요리가 각각 하나의 요리로 완성돼야 하는 상황과 비슷합니다. 요리사가 스테이크 요리를 하고 있는데, 파스타 요리 주문이 들어왔다고 해서 스테이크 요리에 토마토소스를 얹으면 안 되잖아요? 그렇다고 스테이크 요리가 끝날 때까지 기다렸다가 파스타요리를 시작하면 고객들은 이미 화를 내며 집에 갈 테고요. 그러니 여러 가스레인지 불마다 여러 요리가 마구 동시에 조리해야 하는데 이렇게 동시에 여러 작업을 하면서도 각각의 처리 단위가 서로 꼬이지 않게 완성되게 하는 일이 동시성 처리입니다.


REST(Representational State Transfer)는 WWW(World Wide Web)와 같은 분산 시스템을 위한 소프트웨어 아키텍쳐로 특히, 웹 API 디자인을 위한 지배적인 모델로 각광받고 있다.

RESTful API는 HTTP와 URI 기반으로 자원에 접근할 수 있도록 제공하는 애플리케이션 개발 인터페이스다. 기본적으로 개발자는 HTTP 메서드와 URI 만으로 인터넷에 자료를 CRUD 할 수 있다.

https://www.joinc.co.kr/w/man/12/rest/about


보통 스타트업의 기술 선택에서 가장 중요한 것은 서버 프로그래밍 언어와 프레임워크다. 기술 스택의 다른 모든 것들을 합한 것보다 더 중요하다. 스타트업의 서버 프로그래밍 언어로 선택할 만한 것은 파이썬, 루비, Node.js 세 가지 중 하나다. 한 때 자바도 웹 개발용으로 각광을 받았으나, 현 시점에서 자바와 위의 세 가지 대안의 생산성 차이는 몹시 크다. 쉬운 일은 쉬운 도구로 하고 자바는 이제 좀더 어렵고 미션 크리티컬한 분야로 넘기도록 하자. 혹시 PHP를 생각하고 있을지 모르겠는데, PHP는 이제 미래가 없다. 간혹 간단한 웹사이트는 PHP가 가장 빠르다는 주장도 있었으나 요즘은 PHP가 간단한 웹사이트를 만드는 시간에 Rails나 Django는 제법 복잡한 웹사이트를 만들고 시간이 남아서 어드민까지 붙여놓을 수 있다. PHP는 진입 장벽이 낮은 언어지 생산성이 좋은 언어가 아니다.

물론 어떤 언어를 선택하든 별로 중요하지 않다는 주장을 하는 사람도 있다. 그런 사람들은 실제로 어떤 언어를 쓰든 별반 차이가 없다. 그런데 필자라면 아이언맨 슈트를 줘도 K2 소총이랑 똑같은 전투력을 내는 병사를 전장에 내보내진 않을 것 같다. 좋은 도구를 선택하는 안목 역시 개발자의 중요한 능력 중 하나다.


언어를 선택하고 나면 프레임워크도 거의 결정되는 거나 마찬가지다.

파이썬 - Django

루비 - Ruby on Rails

Node.js - express.js

물론 다른 선택도 있으나, 이 세 가지 프레임워크는 널리 쓰이기도 하고, 딱히 큰 단점이 있는 것도 아니라서 다른 대안을 선택한다고 해도 특별히 나은 선택이 되기는 어려울 것이다. 파이썬을 사용하는 대표적인 서비스로는 요기요, 번개장터가 있고, 루비는 텀블벅, 배달의 민족에서 일본에 진출한 라인와우가 있으며 카카오도 과거엔 Ruby on Rails를 많이 썼으나, 2~3년 전부터 성능 문제로 자바로 옮기는 추세다.


웹 서버는 NginxApache의 두 가지 선택이 있다. 웹 서버의 역할은 요청을 애플리케이션 서버로 라우팅해주는 것과 정적인 자원을 서비스하는 것이다. 원래는 Apache가 절대 강자였으나, 이제 Nginx로 대세가 넘어간 듯 하다. Nginx는 등장 초기부터 성능이 좋았고 설정도 조금 더 간단해서 인기를 끌었다. 부하가 높은 상황에서 에러가 많다는 주장도 있었으나 지금은 충분히 안정화된 상태이다. Nginx를 추천한다.

애플리케이션 서버는 프로그래밍 언어에 따라 나뉘는데, Node.js는 별도의 애플리케이션 서버가 필요 없다. 자체적으로 내장된 http 모듈의 서버가 이미 성능과 안정성 면에서 인정을 받아서 프레임워크에서도 그대로 쓰는 경우가 많다.

파이썬은 웹 서버를 Apache로 쓰는 경우는 mod-wsgi를 사용하며 엔진엑스(nginx)의 경우는 uWSGIgunicorn으로 갈린다.

보통 퍼포먼스를 보면 아무래도 C 언어 기반의 uWSGI가 Python 기반인 Gunicorn보다 빨라보입니다. 간혹 uwsgi가 느리다는 비교가있는데 이는 gunicorn은 워커를 gevent로 하면 몽키패치를 지가 app서버에 해버리는데 반해 uwsgi는 app서버 코드에 몽키패치를 해줘야함을 모르고 테스트할 결과로 보여지네요. 사용성 측면에서 uwsgi가 좀더 복잡하고 코어 갯수에 따라 configure를 잘못하면 오히려 성능저하가될 우려가 보이네요. 도큐먼트는 gunicorn이 훨 깔끔.

gunicornnginx와 파이썬 인터프리터를 연결해주는 다리 역할을 한다.

Ruby on Rails는 최근 추세를 잘 모르지만 Passenger, Unicorn, Puma가 경합하는 듯 하고, JRuby도 간혹 쓰인다고 하며, Rails 커뮤니티에서 1옵션으로 권고하는 안은 Passenger인 듯 하다.


써버-싸이드 코딩

  • 파이썬(Python): 파이썬은 개발자들, IT 전문가들, 과학자들이 선택할만한 스크립트 언어로서의 입지를 가진다. 이 언어는 자동화, 웹 개발, 기계 학습, 복잡한 연산에 적합하기 때문이다. 파이썬 2와 3는 작년에 분리되었으며 커뮤니티에서는 반발이 많았지만, 이제 3 버전을 당당하게 선택해서 전폭적인 라이브러리 지원을 받을 수 있다. 더 나은 성능을 위해서는, JIT을 대신해서 PyPy를 사용하는 것도 고려해볼 만 하다.
  • 쟁고우(Django): 파이썬의 웹 프레임워크이다. Python은 독자적인 풀스택을 사용하거나 Django와 Flask 같은 최소한의 프레임워크를 이용하여 구성할 수 있다. Django의 1.10 버전이 8월에 발표되었는데, Postgres를 위한 전문검색(Full text search)을 지원하고 시스템 점검을 위한 중간단계의 레이어를 도입했다.
  • 플래스크(Flask): Python기반의 microframework이다.
  • 루비(Ruby): 루비도 일반적인 목적의 스크립트 언어로써 훌륭하지만, 레일즈(Rails)와 함께 쓸 때 더 빛을 발한다. 루비3 릴리즈를 지금 버전에서보다 3배 빠르게 하겠다는 야심찬 루비 3x3 계획이 발표되기도 했다.
  • 피에이치피(PHP): 대표적인 서버-싸이드 스크맆트 언어로 전 세계 수많은 웹 시스템의 기반이 되는 언어이다. 비슷한 언어로는 ASP, JSP 등이 있다. PHP라는 이름은 원래 Personal Home Page Tools이나, 지금은 PHP: Hypertext Preprocessor라는 재귀 약자를 사용하고 있다.
  • 라라벨(Laravel): PHP의 웹 프레임워크이다. 문서도 훌륭하고 Laravel은 PHP를 이용해서 훌륭한 커뮤니티를 만들어냈다.
  • 자바(Java): Java 9이 2017년에 발표될 것이고 REPL과 HTTP 2.0, 새로운 API를 지원하게 될 것이다. 이 기능들은 자바를 사용하는 수많은 개발자들의 요구에 의해 도입되었고, 자바를 사용하는 프로젝트에 더 큰 활력을 불어넣게 될 것이다. 딱히 자바를 사용하지 않는다면, 수많은 JVM 기반의 언어 중에서도 Kotlin과 Scala를 살펴보는 것도 좋다. Java 생태계에서도 주목할 만 한 프레임워크가 몇 개 있다. Play와 Spark가 가장 인기있고 두 프레임워크 모두 Scala로 작성할 수 있다.
  • 자바써버 페이지즈(JavaServer Pages, JSP): HTML내에 자바 코드를 삽입하여 웹 서버에서 동적으로 웹 페이지를 생성하여 웹 브라우저에 돌려주는 언어이다. Java EE 스펙 중 일부로 웹 애플리케이션 서버에서 동작한다. 자바서버 페이지는 실행시에는 자바 서블릿으로 변환된 후 실행되므로 서블릿과 거의 유사하다고 볼 수 있다. 하지만, 서블릿과는 달리 HTML 표준에 따라 작성되므로 웹 디자인하기에 편리하다. 이와 비슷한 구조로 PHP, ASP, ASP.NET 등이 있다. 확장자는 당연히 .jsp를 사용.
  • 스프링 프레임워크(Spring Framework): 스프링 프레임워크는 자바 플랫폼을 위한 오픈소스 애플리케이션 프레임워크로서 간단히 스프링(Spring)이라고도 불린다. 동적인 웹 사이트를 개발하기 위한 여러 가지 서비스를 제공하고 있다. 대한민국 공공기관의 웹 서비스 개발 시 사용을 권장하고 있는 전자정부 표준 프레임워크의 기반 기술로서 쓰이고 있다.
  • 노드.js(Node.js): Node.js는 자바스크맆트(JavaScript)를 웹 브라우저 밖에서 실행하는 가장 대표적인 방법이다. 올해 많은 버전 발표가 있었는데, 점점 성능이 나아지고 ES6 표준에 대한 지원사항도 많아지고 있다. Node 프레임워크를 사용하면 API와 서버, 데스크탑 앱을 빠르게 만들 수 있고, 심지어 로봇이나 대규모 커뮤니티 등 상상할 수 있는 모든 것들을 만들 수 있다. 당신이 Node를 좋아한다면 Express, Koa, Next, Nodal과 같은 프레임워크도 좋아할 것 같다. node.js로 개발하다 보면 모든 것을 비동기 루틴으로 작성해야 하기 때문에, 처음 개발해 보면 소위 말하는 헬게이트가 발생할 수 있다. 이를 해결하기 위해서 Promise pattern이 나왔는데, node.js용 구현체인 node/bluebird, node/Q등을 사용하면 상당히 깔끔하게 프로그래밍 할 수 있다. Node.js가 io.js포크되었다.
  • 공용 게이트웨이 인터페이스(Common Gateway Interface, CGI): 웹 서버에서 동적인 페이지를 보여 주기 위해 임의의 프로그램을 실행할 수 있도록 하는 기술 중 하나이다. 간혹 동적인 페이지는 다 CGI라고 생각하는 사람들이 있는데 CGI 말고도 이런 역할을 하는 기술은 여럿 있다. 단지 CGI가 맨 처음 나온 기술일 뿐. 원래 웹 서버는 서버에 저장되어 있는 고정된 문서를 보여 주는 역할을 했다. 하지만 웹 서버에서 정보를 찾거나 기록을 하려면 웹 서버를 고쳐서 그런 기능을 넣어야 하는데 버틸 수 없으니, 대신 웹 서버가 특정한 URL로 들어가면 요청을 원하는 프로그램에 적절히 넘겨 주는 기술이 필요해졌는데 CGI가 그런 역할을 한다.
  • (Perl): 웹 프로그래밍에 많이 쓰이고, 소스 코드가 더러워보이는 특성 때문에, "인터넷을 땜빵 연결하고 있는 청테이프(정확히 말하면 'duct tape')"라고 불리기도 한다(...). 요즘엔 잘 안 쓴다.
  • 액티브 써버 페이지즈(Active Server Pages, ASP): 마이크로소프트가 인터넷 정보 서비스(Internet Information Services, IIS)에서 동적 웹 페이지 생성 용도로 사용할 것을 목적으로 제작한 써버-싸이드 스크맆트 엔진이다. 확장자는 .asp 를 사용한다.

Python

파이썬(Python)의 웹 프레임워크(web framework) 중 가장 많이 쓰이는 게 쟁고우(Django)와 플래스크(Flask)인데, 쟁고우는 모든 게 다 갖춰져있는 풀 스택(full stack) 웹 프레임워크이고, 플래스크는 최소한의 내용만 갖추고 필요한 내용은 덧붙일 수 있는 논 풀 스택(non full stack) 웹 프레임워크이다.


풀 스택(full stack)은 처음부터 끝까지 모든 것을 한다는 의미이다. 즉, 풀 스택 개발자면 사용자에게 보여지는 프론트엔드(HTML, CSS, JavaScript 등)부터 서버에서 돌아가는 백엔드(Python, Ruby, PHP 등)까지 혼자서 다 개발하는 사람을 말한다.

풀 스택 프레임워크(framework)는 유저 인터페이스(user interface) 개발부터 데이터 저장(data store) 개발까지 모두 다 도와주는 프레임워크를 말한다. 풀 스택이 아닌 프레임워크는 논 풀 스택 프레임워크(non full stack framework)라고 부른다.

Django

쟁고우 문서 참조.

Flask

Python 기반의 microframework이다. 경량(lightweight) 프레임워크라고 불러도 상관없겠다.

Django, ROR(Ruby on Rails) 등 소위 말하는 풀 스택 프레임워크를 다뤄본적이 없어서, 이들과 비교해서 어떤 부분이 어떻게 경량인지는 모른다. 루비쪽에서는 sinatra가 이와 비슷한 위치에 있는 프레임워크일건데, REST API 개발에는 최적화된 모습을 보인다. 해서 Flask도 비슷하겠지라는 생각으로 살펴보려한다. Flask 관련 몇개 소개글들을 살펴보니, 복잡한 view를 포함하지 않은 REST API 서버의 개발에는 최상의 툴이라고 해서 기대를 하고 있다.


링크트인(LinkedIn): 구인/구직 관련 SNS로 유명한 LinkedIn. LinkedIn의 internal stack의 대부분이 Python기반의 Flask를 사용하였다고 한다. 아래는 LinkedIn의 Tech engineer였던 Rachel Sanders가 PyCon 2014에서 발표 했던 내용. 초반 소개 부분에 LinkedIn에서 Flask가 쓰였다고 언급한다. https://www.linkedin.com/


핀터레스트(Pinterest): Django 처럼 core application 서버로 사용하진 않지만, API 기능 개발 위주로 Flask가 사용되었다고 한다. 원래는 쟁고우(Django)를 썼으나 현재는 플래스크(Flask)를 사용한다. https://www.pinterest.com/


트와일리오(Twilio): 개발자가 VoIP기반 보이스, 비디오, 텍스트 서비스를 쉽게 사용할 수 있도록 API를 제공하는 서비스이다. 즉, twilio의 경우는 API 가 서비스의 핵심인데 이것을 Flask 기반의 Flask-RESTful (http://flask-restful.readthedocs.io)로 개발하였다고 한다. https://www.twilio.com/


  • Flask에서 Hello World 띄우기

https://www.joinc.co.kr/w/Site/Python/Flask

Ruby

루비(Ruby)에서 많이 쓰이는 웹 애플리케이션 프레임워크(web application framework)는 루비 온 레일즈(Ruby on Rails)와 시나트라(Sinatra)가 있다.


Rack은 Ruby 기반의 웹 애플리케이션 개발을 위한 인터페이스를 제공하는 소프트웨어다. Rack의 가장 간단한 응용은 웹서버의 요청을 받아서 웹 프레임워크로 전달하고 응답을 웹서버로 전달하는 미들웨어 소프트웨어의 개발이다. Rack는 웹 서버로의 요청을 처리해서 웹 프레임워크로 전달하고, 웹 프레임워크의 응답을 처리해서 웹 서버로 전달하기 위한 일련의 API들을 제공한다.

Sinatra같은 웹 프레임워크는 Rack을 내장하고 있는데, 이 Rack를 이용해서 웹 애플리케이션과 웹 서버를 연결할 수 있다. Rack은 WEBrick, Mongrel 등의 웹 서버를 연결하기 위한 handler를 포함하고 있다. 또한 Sinatra와 Rails등을 연결하기 위한 adapter를 가지고 있다.

https://www.joinc.co.kr/w/Site/Ruby/Rack

Ruby on Rails

Ruby on Rails는 풀 스택(full stack) 웹 프레임워크이다. Ruby로 만들어진 대표적인 사이트로는 소셜커머스인 그루폰(Groupon)과 오픈 소스 소프트웨어 호스팅 사이트인 깃헙(Github)이 있습니다. 트위터(Twitter)도 Ruby on Rails를 이용하다가 규모가 커지자, Java 기반의 Scala라는 언어로 갈아탔다고 하네요.


카카오톡(KakaoTalk)도 Ruby on Rails를 사용한다. http://www.kakao.com/services/8


텀블벅(tumblbug)은 대한민국에서 서비스 중인 대표적인 크라우드 펀딩 사이트 중 하나로 예술, 문화 컨텐츠를 중점적으로 다루고 있다. 여기서도 Ruby on Rails를 사용한다. https://www.tumblbug.com/

Sinatra

시나트라(Sinatra)는 루비(Ruby)용 논 풀 스택(non full stack) 웹 프레임워크이다. Sinatra는 MVC 모델을따르는 프레임워크는 아니다. 최소한의 노력으로 빠르게 웹 애플리케이션을 개발하는데 촛점을 맞춘 경량 프레임워크다. 애플, 영국 정부, 링크트인, Heroku, Engine Yard, Songbird, 징가(Zynga) 등에서 사용하고 있다. 루비의 웹 서버 인터페이스인 Rack을 기반으로 Rack의 여러 기능들도 활용할 수 있다.


  • Sinatra에서 Hello World 띄우기

https://www.joinc.co.kr/w/Site/Ruby/sinatra


  • sinatra를 활용한 간단한 서버 구축

http://thswave.github.io/ruby/sinatra/2015/05/26/introduce-sinatra.html


  • Sinatra 공식 웹 싸이트

http://www.sinatrarb.com/


  • Sinatra 사용 방법 한국어 설명 페이지

http://www.sinatrarb.com/intro-ko.html

데이터베이스

데이터베이스(database) 문서 참조.