프로가 되기 위한 웹기술 입문 ( ~ 242p)

프롤로그

  • 왜 여러분은 웹 애플리케이션 개발 기술을 배우지 못하는 것일까?
    1. 역사가 짧기 때문.
      • 웹 애플리케이션 자체가 최근 10년 정도 사이에 새롭게 확산된 것이며, 개발 기법 자체도 계속 발전하고 있다.
      • 현장에서도 조금만 방심하면 뒤처지고 말 정도이니 대학이나 기업에서 체계적으로 교육하기가 어려울 수 밖에 없다.
      • 수학이나 물리는 역사가 수백 년에 이르며, 비교적 새로운 공학 계열의 분야도 역사가 100년은 된다.
      • 안 그래도 역사가 짧은 컴퓨터 분야에서도 최신 기술이니 체계적으로 가르치기가 어려운 것은 당연하다.
    2. 필요한 지식이 너무 방대하다.
      • 프로그래밍 언어
      • 네트워크, HTML
      • 애플리케이션 서버
      • 운영체제 등
      • 이처럼 폭넓은 지식을 독학으로 익히려면 긴 시간이 걸리며,
      • 이 지식을 가르칠 수 있는 인재는 개발 현장에서도 서로 모셔 가려고 하므로 교육에 시간을 할애할 여유가 없다.

배우고 생각하지 않으면 얻는 것이 없고, 생각하고 배우지 않으면 위태롭다. - 공자

  • 배움과 생각의 균형이 중요하다.

LESSON 1. 웹 애플레케이션이란 무엇인가?

  • 주된 처리는 본인의 컴퓨터(PC)가 아니라 서버상에서 진행된다.
  • 화면은 HTML로 표현되며, 웹 브라우저에 표시된다.
  • 애플리케이션을 PC에 설치할 필요가 없다.

LESSON 2. 웹은 어떻게 발전했는가?

WWW

  • 인터넷(Internet)은 전 세계의 컴퓨터를 상호간에 접속하고 통신할 수 있게 한 네트워크 망.
  • 1969, 약 40년 전 미국 국방성이 연구 조사를 목적으로 구축한 ARPANET이라는 네트워크가 초기 원형.
  • 1989, 소립자 물리학 연구소에서 WWW 탄생.
    • 전 세계 연구자들과 핵 소립자 실험의 성과 및 정보를 공유하기 위해 개발.
      • 이메일이나 파일전송 같은 기술은 편의성이 너무 떨어졌었기에, 좀 더 좋은 방법을 찾고자.
    • 이 분이 바로 팀버너스 리 박사.
    • 정보를 표현하기 위해서는 도표와 참고 문헌등이 필요하므로
    • 이들을 텍스트로 표현하고자 HTML 이라고 하는 통일된 형식으로 표현.
  • 텍스트만 표현할 수 있는 브라우저에서 문자와 그림을 함께 표현할 수 있게 만든 것이 일리노이 공과대학의 미국 국립 슈퍼컴퓨터 응용 연구소에 근무하던 마크 앤드리슨이다.
    • 1993, NCSA 모자이크(이하 모자이크) 라는 웹 브라우저를 개발하여 누구나 무료로 이용할 수 있게 공개한다. mosaic

    • 이미지 출처

    • 풍부한 표현이 가능해지고, 무료로 이용할 수 있으므로 일반인에 가까운 사람들의 흥미를 끌었고
    • 때문에 연구 성과 외에도 다양한 사람들이 여러 정보를 인터넷에 공개하기 시작했다.
    • 게다가 1990년대 후반부터 2000년대에 걸쳐 개인용 컴퓨터의 성능이 높아지고 가격이 저하되었다.
    • 또한 ADSL과 광통신이 보급됨에 따라 고속 네트워크를 저렴한 가격에 24시간 이용 가능했다.

웹을 뒷받침하는 기술의 발명

  • 클라이언트와 서버는 손님과 시중드는 사람의 관계이다.
    • 실제 해당 의미가 어원이다.

  • WWW에서는 웹 서버가 네트워크 상에 공개하는 HTML 형식의 파일을 축적하고, 웹 클라이언트의 요청에 따라 필요한 HTML 파일을 건네주는 구조.

  • 클라이언트의 요구를 Requset
    • web browser (chrome, safari .. )
  • 서버의 응답을 Response
    • web server (Apache HTTP Server, MS IIS … )

clientServer

  • 이미지 출처

  • why 클라이언트 - 서버 구조.

    • 다양한 콘텐츠를 불특정 다수의 사람에게 공개하려면 콘텐츠를 되도록 한 곳에 정리하는 것이 갱신 및 관리하기 편하다.
    • 많은 사람들이 자유롭게 열람할 수 있어야 하는데, 사용자가 콘텐츠를 열람하기 위해 그 콘텐츠를 보관하는 웹 서버를 직접 조작하는 것은 비현실적이다.

URL

  • Uniform Resource Locator.
  • 인터넷상의 콘텐츠를 고유하게 지정하기 위한 구조. URL
  1. 스킴(Scheme)
    • 리소스를 취득하기 위한 방법.
    • 웹 애플리케이션에서는 대부분의 경우 http.
    스킴명 설명
    https 암호화된 http 통신
    ftp ftp 프로토콜을 통한 파일 통신
    mailto 이메일의 수취인
    file 파일 시스템 속의 파일이나 디렉터리 참조
  2. 호스트명 hostName
    • 리소스가 존재하는 호스트(컴퓨터)의 이름.
    • 호스트 컴퓨터 : 네트워크에 접속되어 다른 컴퓨터로부터 요구를 받고 처리한 결과를 되돌려 주는 컴퓨터.
    • 부모 도메인 명 : 해당 호스트가 존재하는 조직.
    • 로컬명 : 그 조직 안의 컴퓨터에 붙은 이름.
    • 부모 도메인 부분은 인터넷 상의 고유함을 보장한다.
      • 한국 인터넷 진흥원의 KRNIC(Korea Network Information Center) 라는 곳에서 관리.
  3. 경로명
    • 호스트명에서 지정된 컴퓨터상의 리소스의 위치.
    • 위 예제에서는 webtext라는 디렉터리에 있는 index.html 파일.

HTTP

  • Hyper Text MArkup Language.
  • 컴퓨터와 컴퓨터가 하이퍼텍스트를 비롯한 콘텐츠 정보를 주고받는 규약.
  • 당시 FTP, SMTP는 이미 있었는데
  • 버너스 리 박사는 이것을 참조해 HTML 전송에 적합한 프로토콜 HTTP를 새로 고안했다.

RFC

  • URL이나 HTTP등 인터넷상에서 이용되는 규격이나 규약이 공개되어 있는 곳.
  • Request for Comments.
  • 초기에는 기술자가 통신 프로토콜이나 규약 등의 초안을 인터넷 상에 공개
    • 이에 대해 널리 의견을 구했기 때문에 코멘트 모집 이라는 의미에서 RFC라고 부르던 것이 시초.
  • 현재 RFC는 IETF에서 공개하는 기술 문서의 형식으로 규정되어 있다.
    • ex) URL은 RFC1738, HTTP/1.1은 RFC2616 이라는 문서에 규정, 공개.

CGI의 탄생

  • 이렇듯, 웹 서버는 원래 준비돼 있던 콘텐츠를 클라이언트의 요청에 응해 보내주는 일을 했다.
  • 웹 사이트를 공개할 때는 한 명이라도 많은 사람이 자신의 사이트를 봐 줬으면 하는 욕구가 생긴다.
    • 아무리 유익한 정보라도, 그 내용이 매번 같으면 결국은 흥미를 잃어 열람자가 줄어든다.
    • 때문에 항상 새로운 콘텐츠를 제공하고자 하는 욕구로 이어진다.
    • 하지만 ‘미리 준비된 정보를 공개한다’라는 기능밖에 없는 웹 서버는 이를 수행할 수 없다.
    • 당연히 ‘콘텐츠를 만든다’라는 식의 창조적인 거대한 작업을 시키기란 더더욱 어렵다.
  • 그래서 컴퓨터를 이용해 콘텐츠에 작은 변화를 주는 방법을 고안했다.
    • 접속자 수가 표시된다거나, 재고가 표시된다거나.
  • 웹 서버에서 작동하는 프로그램을 만들어 콘텐츠의 작은 변화를 일으키기로.
    • HTML을 생성 및 변경하도록.
  • 이와 같이 프로그램이 생성한 HTML 등의 콘텐츠를 동적 콘텐츠

  • 기존과 같이 미리 준비된 콘텐츠 정적 콘텐츠라 한다.

  • 동적 콘텐츠를 생성해 웹 클라이언트에 보내려면 웹 서버와 콘텐츠를 생성하는 프로그램의 연동이 필요하다.

  • 그래서 고안된 것이 CGI(Common Gateway Interface) 구조다.

  • CGI 구조
    • 웹 서버가 웹클라이언트로부터 받은 요청을 웹서버상에서 작동하는 프로그램에 보낸다.
    • 프로그램은 요청을 참조해 HTML을 생성한 다음 웹 서버에 돌려보낸다.
    • 그러면 웹 서버는 프로그램으로부터 받은 HTML을 마치 미리 준비돼 있었다는 듯이 웹 애플리케이션에 보낸다.
      cgi
  • CGI는 어디까지나 웹 서버와 프로그램 사이에서 요청과 응답을 주고받기 위한 규약
    • CGI는 프로그래밍 언어가 아니라 어디까지나 인터페이스다.
    • 실제로 웹 서버상에서 작동해 콘텐츠를 생성할 목적으로 주로 이용되던 것은 펄(Perl) 이라는 프로그래밍 언어이다.
    • 규모가 거대하거나 빠른 속도가 요구될 때는 C언어.
    • 펄이 너무나도 많이 이용됐기 때문에 ‘CGI = 펄’ 이라는 오해를 낳기도 했다.
  • CGI를 이용하자 동적 콘텐츠를 생성할 뿐 아니라, 웹 브라우저에서 입력을 받아 그에 상응하는 처리를 하는 애플리케이션을 제작할 수 있게 됐다.
  • 검색 사이트나, 게시판, 인터넷 쇼핑 등 편리한 기능을 제공하는 사이트를 구현할 수 있는 발판.
  • 웹 애플리케이션의 시작이다.

CGI를 둘러싼 문제점
  1. 개발 언어
    • CGI 프로그래밍에 주로 이용되던 펄은 텍스트 처리에 강점이 있는 언어였다.
      • 규모가 크고 복잡한 애플리케이션을 개발하는 데 적합하지 않았다.
      • 객체지향 프로그래밍도 지원하지 않았다.
  2. 성능
    • 웹 브라우저에서 요청이 도착할 때마다 CGI를 통해 프로세스를 기동했다.
      • 여기에는 시간이 걸리는데, 접속 수가 많아지면(수만, 수십만) 프로그램의 기동처리가 많아져 요청을 따라잡지 못한다.
      • 그 결과 사용자가 웹페이지에 접속했는데도 화면이 표시되지 않아 불만이 쏟아지는 사태가 초래됐다.

JAVA / Servlet의 탄생
  • 웹 애플리케이션 개발이 이런 문제로 고민하고 있을 때, 썬 마이크로시스템즈의 제임스 고슬링이 개발한 자바가 등장.
  • 자바는 객체지향을 완벽히 지원해 대규모 시스템을 개발하기 용이.
  • 당시 널리 사용되던 C 언어와 문법이 비슷하여 개발자들의 수용이 쉽다는 장점.

  • 멀티 스레드와 보안, 네트워크 통신 등 당시 중요성이 높아지던 기술을 표준화된 방식으로 지원했다는 점도 매력적.

  • 자바 자체는 웹 애플리케이션을 위해 개발된 언어가 아니나,
    • 당시 기업의 시스템 개발에서도 웹 애플리케이션이 주류이므로,
    • JavaEE (Java Enterprise Edition)의 일부로서 서블릿(Servlet)이라는 웹 애플리케이션 개발을 지원하기 위한 기능을 제공했다.
  • 서블릿은 자바로 만들어진 웹 콘텐츠(HTML 등)을 생성하기 위한 프로그램.
    • 기본적으로 CGI와 같은 개념이지만, 웹 서버와 같은 프로세스 속에서 콘텐츠를 생성하는 프로그램이 작동.
    • 비교적 고속.

LESSON 2. 웹은 어떻게 발전했는가?

JSP의 탄생

  • Java Server Pages
  • Servlet의 문제점을 개선하기 위해 고안됨.

    • Servlet 문제점 ServletJSP

      • 개발 중심적이기에 디자인의 수정이 있을 때 개발자와 디자이너가 함께 작업하기가 어렵다.
      • 서블릿을 통해 출력되는 HTML을 상상하기 어렵다.
      • 프로그램이 길어지거나 HTML이 복잡해지면 HTML 수정부를 찾기 어렵다.
    • Servlet 보다 HTML에 근접한 형태
    • 동적으로 출력하고 싶은 부분을 <%, %> 로 묶는다.
      • 스크립틀릿(Scriptlet).

서블릿은 자바 코드 속에 HTML을 넣고 JSP는 HTML 속에 자바 코드를 넣는다.

프레임워크

  • 서블릿과 JSP를 통해 간단한 웹 애플리케이션을 만들기가 매우 편리.
  • 하지만, 웹 애플리케이션의 규모가 커질수록 공수가 커졌다.
    • 재사용 이라는 발상.
  • 하드웨어와 달리 소프트웨어는 얼마든지 프로그램이 재사용 가능하다는 점.
  • 위 개념을 더욱 발전시켜, 재사용할 수 있는 부분을 늘려 애플리케이션 개발을 용이하게 돕는 토대를 생성.
    • 이것이 프레임워크.

Lesson 3. HTTP를 이해하자

  • 통신 프로토콜 : 정보를 주고받기 위한 약속으로서 주로 정보의 전달 방법과 정보의 의미를 규정
    • ex) 봉화, 모스부호
  • 피들러 설치
    • 피들러는 인터넷 간의 모든 HTTP(HTTPS) 트래픽을 기록하는 웹 디버깅 프록시로서 동작
      • 다시, 기본적으로 모든 프로세스의 HTTP(S) 트래픽을 가로챈다

  • Request Header

    request-header

    • 첫 줄을 요청 라인 이라고 한다.
      • GET http://... HTTP/1.1
      • a) 메서드
        • 요청의 종류
      • b) URI
      • c) HTTP 버전
    • 두 번째 줄 이후의 나머지 부분은 메시지 헤더 라고 하며, 요청의 부가적인 정보를 나타낸다
      • <필드 이름=""> : <필드 값="">
      • d) Accept
        • Web client가 받을 수 있는 데이터 종류
        • 데이터 종류는 Content-Type 이라는 형식으로 표시된다
      • e) Accept-Langauage
      • f) User-Agent
        • 이용 중인 웹 브라우저의 종류와 버전
      • g) Host
  • 참고 : URI vs URL
    • URI = URL + URN
    • URL 은 우리가 아는거
      • http://www.wikibook.co.kr/webtext/http/index.html
      • http 통신, wikibook.co.kr 이라는 도메인, www라는 서버, webtext/http 라는 디렉터리, index.html 파일을 가르키는 URL
      • 그러나 이 파일의 호스트가 변경됐다면 URL을 모르고선 접속이 불가하다
      • 이런 문제를 해결하기 위해 인터넷상에 존재하는 리소스에 통일된 이름을 정하자는 생각에서 고안된 것이 URN
        • ex) urn:itif:rfc:2626 은 HTTP1.1 의 RFC에 대한 URN
          • 물리적으로 어떤 위치에 존재하든 같은 URN
    • 결론 : URI는 위치를 나타내는 URL과 이름을 나타내는 URN을 통일적으로 나타낸 것
      • 현재 URN은 거의 사용되고 있지 않으므로 URL과 URI가 거의 같은 개념
  • Response
    • a) 상태 라인
      • HTTP/1.1 200 OK
      • http 버전, 상태코드, 응답구문
    • b) 메시지 헤더
      • 두 번째 줄 부터 빈 라인 까지
    • c) 메시지 본문
  • HTTP는 한 번에 리소스 하나를 취득한다
    • 이미지 1개가 포함된 HTML 페이지라면, 요청이 2개 날라갈 것
  • IP 주소에 의지해 정보를 보내는 TCP/IP
    • IP 주소로 지정해 정보를 전달하면 TCP/IP는 브라우저 등으로 받은 HTTP 요청을 패킷으로 분할해 송신하고, 정보를 받은 쪽에서 그것을 원래대로 조립한 다음 송신처인 웹 서버 등의 애플리케이션으로 넘긴다.
  • 글로벌 IP : 유선 번호
  • 사설 IP : 내선 번호
    • 다른 곳에선 중복되어도 노상관
    사설 IP 주소 클래스 이용 가능한 수
    10.0.0.0 ~ 10.255.255.255 A 클래스 16,777,217 개
    172.16.0.0 ~ 172.31.255.255 B 클래스 1,048,576 개
    192.168.0.0 ~ 192.168.255.255 C 클래스 65,536 개
    • 대부분 그다지 많이 안필요 하니까 클래스 C가 주로 이용됨
  • DNS
    • 도메인명과 IP주소의 대응표를 가진 컴퓨터 (DNS 서버) 를 통해 도메인 명에 대응하는 IP 주소를 가르쳐 준다

      • nslookup 도메인주소 로 실습가능

          nslookup naver.com
  서버:    kns.kornet.net
  Address:  168.126.63.1

  권한 없는 응답:
  이름:    naver.com
  Addresses:  125.209.222.141
  210.89.160.88
  125.209.222.142
  210.89.164.90
    • DNS는 도메인명에 대응하는 DNS 서버를 다수 준비해 정보를 분산 관리 한다
    • 도메인 명은 마침표로 계층을 구분하여 각 계층에 대응하는 DNS 서버에 질의함으로써 하위 DNS 서버의 주소를 알 수 있게 돼 있다
    • kr, com, net, org 같은 최상위 도메인을 TLD(Top Level Domain) 라고 한다
      • 이러한 TLD의 DNS서버를 관리하는 DNS 서버가 존재하는데 이를 루트 서버 라 한다
        • 루트 서버는 2010년 기준 전 세계 13개 있고, IP 주소가 거의 변경되지 않기 때문에 모든 DNS 서버에 등록되어 언제라도 참조할 수 있다
        • 루트 서버로부터 순서대로 하위 DNS 서버에 질의해 나가며 원하는 호스트명에 대응하는 IP 주소를 찾는다
  • 포트 넘버
    • IP 로 컴퓨터를 찾았으면, 어떤 어플리케이션에 줘야 하는지는 포트번호로!
    • 대표적인 well-known ports 는 쪼꼼 알면 좋겠지
  • 웹 어플리케이션에 정보를 전달하는 방법(argument 전달)
    • GET 방식, 요청라인(URL)에 Query String 으로 전달
      • url 을 복붙해서 상대한테 보내면 같은 페이지를 공유 가능,
      • 수없이 요구를 반복해도 같은 결과가 나온다 책에서는 부작용이 없다고 표현
    • POST 방식, 메시지 본문
      • 매개변수의 길이 제하니 없다
      • 보안이 비교적 높다
  • 퍼센트 인코딩
    • 문자열을 문자 코드로 나타낸 것
    • 한글을 매개변수로 전달할 때 %ED%99% … 요로케 변하는걸 많이 봤다
      • 16진수로 표시한 각 값의 앞머리에 %(퍼센트)를 붙이는 방법

Lesson 4. CGI 에서 웹 어플리케이션으로

  • 응답 HTTP 코드가 302 코드 Redirect
    • Location Header 에 표시된 URL에 다시 Request
  • HTTP는 Stateless 프로토콜
    • 때문에 상태를 보존하는 척 해야하므로 고안된게 쿠키
      • 로그인 성공 시, 웹 서버가 클라이언트로 HTTP Response header로 작은 정보(쿠키)를 보낸다
        • ex)
          • Set-Cookie: user=userId
          • Set-Cookie: pass=password
      • 웹서버로부터 받은 클라이언트는 웹 서버로 요청할 때 전에 받았던 쿠키를 그대로 Request header에 넣어 보낸다
      • 그런데 위처럼 Id/Pw가 쿠키에 플레인하게 박혀있으면, 피들러를 통하거나 웹 브라우저에서도 쉽게 쿠키의 값을 취득할 수 있다
    • 이러한 문제점을 해결하기 위해 나온 개념이 세션
      • 서버가 세션ID 와 맵핑되는 클라이언트 정보에 대한 맵같은 걸 들고 있고
      • 쿠키 에 세션ID 를 담아 주고 받는다
      • 이렇게 하면 장점이, 쿠키에 저장할 수 있는 정보의 양도 제한이 없어지고 보안도 향상된다.
        • 물론 세션 ID 털린다고 아무런 문제가 없는 건 아닌데, 이건 나중에 설명한다고 한다 책이
  • 로그인 흐름 정리
      1. 클라 로그인 정보 입력 -> 서버 전송
      1. 서버는 아이디, 패스워드로 회원 확인 후 세션 ID 발행, 세션에 회원정보 기록
      1. 서버가 클라에게 Response 쿠키에 Session ID를 담아 보내줌
      1. 클라가 다음 요청시, Request header 쿠키에 Session ID를 담아서 서버로 보냄
      1. 서버가 뭔가 할 때 Cookie의 세션ID를 까본다음 회원정보를 확인하고 일을 진행
  • 프웹기 엄청 쉽고 잘읽히는데 너무 쉬운것도 문제긴 한 듯, 그래도 기초 웹 개념 한판 다지기에 좋은 것 같당!

Lesson 5. 웹 애플리케이션의 구성 요소

  • 초기에는 서버 측 1대의 컴퓨터에서 웹 서버와 CGI를 통해 호출되는 애플리케이션 즉 두 가지 소프트웨어가 작동했다
    • 이후, 성능향상 목적으로 웹 서버 안에서 웹어플리케이션을 실행하게 변경
  • DBMS는 여러 어플리케이션에서 동시에 이용되기 때문에 단독 프로세스로 동작한다
    • 즉 웹 서버와 데이터베이스 서버는 다른 프로세스로 동작한다
  • 웹서버와 DB서버의 통신은 웹클라이언트와 웹서버의 통신처럼 통신을 하긴 함
    • HTTP 처럼 완벽한 표준으로 존재하지 않는다
    • DB 벤더 마다 고유의 통신 프로토콜이 있기 때문
      • 프로그래밍 언어로 이 프로토콜을 준수한 인터페이스가 존재함 (라이브러리)
        • 이를테면 JDBC
  • 뭔가 인상깊은 문장. 이 책에서 첨봤음 이런 문장은 되게 뭔가 새롭
    • 컴퓨터 입장에서는 JVM도 웹서버나 데이터베이스와 마찬가지로 하나의 프로세스다
  • 웹 어플리케이션 구성

web-application

  • CGI 와 애플리케이션 서버(WAS) 의 차이
    • CGI는 웹서버로 요청이 올 때 마다 새로운 프로세스가 기동됐다가 종료되는 1회용 모델
      • 계속 기동과 종료를 반복하니 비용이 큼
    • WAS는 프로세스가 항상 기동상태로, 웹서버의 요청을 받아 실행하는 재사용 모델
  • 웹서버와 애플리케이션 서버는 다른 프로세스이므로 연동하려면 어떤식으로든 통신을 해야한다
    • 이것도 표준은 없음
    • 일반적으로는 WAS 측이 웹서버별로 연동용 모듈을 마련해, 그 모듈을 웹서버에 탑재함으로써 상호 연동을 가능하게 하는 방식
      • ex) Tomcat 은 아파치용 mod_jk 라고 하는 연동모듈을 제공
        • mod_jk와 톰캣 사이의 통신은 ajp13 이라고 하는 톰캣 고유의 프로토콜로 한다 (독자규격)

        apache-tomcat

  • 웹서버가 일단 창구가 되어 HTTP Request를 접수하고, 경우에 따라서(설정 파일에 의거) WAS 에 처리를 의뢰
    • Web Server 와 WAS는 같은 서버에 있을수도, 분리할수도 있다
  • WAS 가 제공하는 기능
    • 세션관리, 트랜잭션 관리, DB접속 관리 등

Lesson 6. 웹 애플리케이션을 효율적으로 개발하는 방법

  • 이 장에서는 서블릿/JSP 얘기를 주로 하네
    • 너무 한 물 간 기술셋이라 슥슥 읽기만 했음
  • 프레임워크
    • 자동차를 예로
    • 일부 차종은 섀시(차대)라고 하는 기본적인 부분이 공통화 되어 있다.
      • 타이어 네 개가 지면과 맞닿아 차중을 지탱
      • 어떤 엔진을 사용해 타이어를 회전시켜 앞으로 나아간다
      • 엑셀, 브레이크 라는 페달로 속도를 제어한다
      • 핸들을 좌우로 돌려 앞바퀴의 방향을 바꿔 진행방향을 제어한다

    • 자동차로 치면 섀시 같은 플랫폼이 소프트웨어의 프레임워크

    • 장점
      • 설계/개발 공수의 절감
      • 품질 향상
      • 테스트 공수의 절감
    • 단점
      • 학습 비용의 증대
      • 설계 자유도 저하
      • 장기적인 기술력 저하
  • 이번 파트에서는 소스코드들이 많았는데
    • 이게 분명히 2010 년쯤에는 엄청 신기술일테고, 그 때는 이러한 소스가 정말 많은 도움이 되었겠지만
    • 그건 아주 일시적이고, 지금처럼 기술이 변화해버리면 정말 의미없는 페이지가 되는군