프로가 되기 위한

웹기술 입문

iv

•목 차•

LESSON 0 | 프롤로그 2

웹 애플리케이션 개발 기술은 어디서 배우는가? ................................................. 3

왜 여러분은 웹 애플리케이션 개발 기술을 배우지 못하는 것일까? ................... 3

대상 독자 .................................................................................................................. 4

이 책을 읽을 때 필요한 사전 지식 .......................................................................... 4

가장 효율적으로 기술을 배우는 방법 .................................................................... 5

LESSON 1 | 웹 애플리케이션이란 무엇인가? 8

1.1 데스크톱 애플리케이션 .........................................................................................8

1.2 웹 애플리케이션 ....................................................................................................9

1.3 정리 .......................................................................................................................12

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

2.1 WWW의 탄생과 보급 .........................................................................................14

전 세계의 컴퓨터를 연결하는 인터넷 .................................................................. 14

인터넷 보급의 견인차 월드 와이드 웹과 모자이크 ............................................ 15

WWW의 탄생 ....................................................................................................... 16

현대 웹 브라우저의 시조인 NCSA 모자이크 ...................................................... 18

v

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

웹 서버와 웹 클라이언트 ....................................................................................... 20

왜 클라이언트와 서버로 나누는가? ..................................................................... 21

‘그 리소스는 어디에 있지?’ - URL ....................................................................... 22

HTTP ...................................................................................................................... 25

2.3 CGI의 탄생 ...........................................................................................................29

동적인 콘텐츠에 대한 요구 ................................................................................... 29

CGI의 탄생 ............................................................................................................. 30

웹의 폭발적인 보급 ............................................................................................... 31

2.4 서블릿의 등장 ......................................................................................................32

CGI를 둘러싼 문제점 ............................................................................................ 32

자바/서블릿의 탄생 ............................................................................................... 32

자바로 애플리케이션을 개발할 때의 이점 .......................................................... 34

2.5 JSP의 탄생 ............................................................................................................36

서블릿의 문제점 .................................................................................................... 36

발상의 전환! JSP의 탄생 ....................................................................................... 39

2.6 웹 애플리케이션 프레임워크의 시대 .................................................................40

서블릿과 JSP의 문제점 .......................................................................................... 40

웹 애플리케이션 프레임워크의 탄생 ................................................................... 40

2.7 정리 .......................................................................................................................42

vi

LESSON 3 | HTTP를 이해하자 44

3.1 왜 HTTP를 알아야 하는가? ...............................................................................44

3.2 웹 브라우저와 웹 서버의 통신을 엿보자 ...........................................................46

피들러 설치 ............................................................................................................ 47

HTTP 통신을 엿보자 ............................................................................................ 49

HTTP 요청을 엿보자 ............................................................................................ 49

HTTP 응답을 엿보자 ............................................................................................ 55

HTTP에서는 한 번에 리소스 하나를 취득한다 .................................................. 57

파일명을 생략했을 경우의 요청 ........................................................................... 59

3.3 정보는 어떻게 인터넷의 대해를 건너는가? ......................................................60

인터넷상의 주소-IP 주소 ...................................................................................... 60

IP 주소에 의지해 정보를 보내는 TCP/IP ........................................................... 61

IP 주소는 누가 결정하는가? ................................................................................. 63

글로벌 IP 주소와 사설 IP 주소 ............................................................................. 63

호스트명을 IP 주소로 변환하는 DNS ................................................................. 65

DNS는 어떻게 구현되는가? ................................................................................. 66

호스트 내의 수신처를 결정하는 포트 번호 ......................................................... 68

3.4 웹 서버에 요청을 어떻게 전달하는가? ..............................................................70

GET 메서드를 이용한 매개변수 전달 ................................................................. 70

애플리케이션 측의 매개변수 받기 ....................................................................... 74

POST 메서드를 이용한 매개변수 전달 ............................................................... 75

GET과 POST 중 어느 쪽을 사용해야 할까? ....................................................... 79

한글은 어떻게 전달해야 하는가? ......................................................................... 81

3.5 정리 .......................................................................................................................83

vii

LESSON 4 | CGI에서 웹 애플리케이션으로 86

4.1 배달 피자 주문 사이트를 만들자 ........................................................................86

4.2 화면 구성 ..............................................................................................................87

4.3 화면 모형 ..............................................................................................................89

4.4 로그인 인증 기능 .................................................................................................91

PHP로 인증 기능을 만들자 .................................................................................. 92

인증 기능의 동작을 확인하자 ............................................................................... 94

리다이렉트 동작의 HTTP 통신을 확인하자....................................................... 94

4.5 로그인 상태를 어떻게 기억할 것인가? ..............................................................98

상태 유지 프로토콜과 무상태 프로토콜 .............................................................. 98

무상태인 HTTP상에서 상태를 어떻게 표현할 것인가? .................................. 102

쿠키를 이용해 상태를 보존한다 ......................................................................... 103

실제 쿠키 이용을 확인한다 ................................................................................. 107

4.6 안전하게 상태를 보존하기 위한 기술 -세션 ...................................................110

쿠키를 둘러싼 문제점 .......................................................................................... 110

은행의 창구 업무를 통해 세션을 이해하자 ....................................................... 112

계좌 개설 업무의 진행 상황을 어떻게 관리하는가? ........................................ 114

세션으로 처리 진행 상황을 관리한다 ................................................................ 115

세션의 상태를 어디에 보존할 것인가? .............................................................. 116

HTTP에서의 세션 ID 전달 방법 ....................................................................... 117

실제 웹 애플리케이션에서의 세션 ID 활용 ...................................................... 118

세션 ID를 이용한 사용자 식별 ........................................................................... 122

4.7 피자 펜토미노의 완성........................................................................................123

4.8 정리 .....................................................................................................................127

viii

LESSON 5 | 웹 애플리케이션의 구성 요소 130

왜 웹 애플리케이션의 구성을 이해해야 하는가? ............................................. 130

5.1 웹 서버와 웹 클라이언트의 시대 ......................................................................133

WWW의 여명기.................................................................................................. 133

CGI의 시대 ........................................................................................................... 134

5.2 데이터베이스 서버의 등장 ................................................................................137

대량의 정보를 어떻게 관리할 것인가? .............................................................. 137

데이터베이스 관리 시스템의 등장 ..................................................................... 139

데이터베이스에 대한 조작 .................................................................................. 141

데이터베이스를 이용한 정보의 관리 ................................................................. 141

데이터베이스에서 정보를 추출한다 .................................................................. 144

필요한 정보를 SQL로 데이터베이스에 전달한다 ............................................ 145

데이터베이스와 클라이언트의 관계 .................................................................. 147

데이터베이스 서버의 분리 .................................................................................. 151

웹 애플리케이션과 데이터베이스의 통신 ......................................................... 153

5.3 애플리케이션 서버의 등장 ................................................................................155

서블릿이나 JSP는 어디에서 작동하는가? ......................................................... 155

서블릿/JSP를 작동시키기 위한 애플리케이션 서버 ......................................... 156

웹 서버와 애플리케이션 서버의 연동 ................................................................ 157

웹 서버와 애플리케이션 서버의 분담 ................................................................ 158

웹 서버와 애플리케이션 서버 연동의 이점 ....................................................... 161

여러 톰캣에 전송하기 .......................................................................................... 162

웹 서버의 기능을 가진 애플리케이션 서버 ....................................................... 164

5.4 웹 시스템의 삼층 구성.......................................................................................167

최소 구성의 웹 시스템 ......................................................................................... 168

일반적인 구성 ...................................................................................................... 169

웹 시스템의 삼층 구성 ......................................................................................... 170

5.5 정리 .....................................................................................................................173

ix

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

6.1 서블릿/JSP만으로는 부족한가? ........................................................................176

웹 애플리케이션 개발의 표준 – 자바................................................................. 176

서블릿과 JSP의 연동............................................................................................ 177

6.2 서블릿/JSP를 이용한 피자 펜토미노의 로그인 처리 구현 .............................178

JSP를 통한 로그인 화면 표시 .............................................................................. 178

서블릿의 호출 ...................................................................................................... 180

로그인 서블릿의 처리 .......................................................................................... 181

포워드와 리다이렉트의 차이 .............................................................................. 183

요청 스코프에서의 정보 전달 ............................................................................. 184

JSP의 요청 스코프에서 정보를 꺼내기 .............................................................. 186

왜 요청 스코프가 필요한가? ............................................................................... 187

세션 스코프와 요청 스코프의 차이 .................................................................... 189

6.3 웹 애플리케이션의 아키텍처 ............................................................................191

로직과 디자인의 분리 .......................................................................................... 191

소프트웨어의 건축 양식 ...................................................................................... 192

피자 펜토미노의 구조를 살펴보자 ..................................................................... 195

MVC 모델에 따른 웹 애플리케이션의 아키텍처 ............................................. 198

MVC 모델에서의 처리 흐름 ............................................................................... 201

6.4 프레임워크를 통한 아키텍처의 구현 ...............................................................202

프레임워크란 무엇인가? ..................................................................................... 202

스트러츠를 이용한 MVC 모델의 구현 .............................................................. 204

스트러츠를 이용한 피자 펜토미노의 로그인 처리 ........................................... 206

JSP에서의 로그인 처리 액션 호출 ...................................................................... 209

로그인 처리 액션에서의 로그인 확인 처리 ....................................................... 213

상품 목록 화면으로 이동 ..................................................................................... 215

x

6.5 레이어 패턴에 따른 데이터 액세스 계층의 분리 ............................................216

모델을 어떻게 구현할 것인가? ........................................................................... 216

JDBC를 이용해 데이터베이스에서 정보를 가져온다 ...................................... 220

레이어 패턴에 따른 데이터 액세스 계층의 분리 .............................................. 223

DAO 패턴을 이용한 데이터 액세스 레이어의 구현 ......................................... 226

6.6 O/R 매핑 프레임워크를 이용한 데이터 액세스 레이어 구현 ....................................228

O/R 매핑 프레임워크의 필요성 ......................................................................... 228

RDB와 객체의 임피던스 불일치 ........................................................................ 229

아이바티스를 이용한 O/R 매핑의 실제 ............................................................ 232

데이터 매퍼와 SQL 맵 파일을 이용한 O/R 매핑 처리 ..................................... 232

Dao 프레임워크를 이용한 DAO의 작성 ........................................................... 235

6.7 프레임워크 이용의 장점과 단점 .......................................................................238

프레임워크 이용의 장점 ...................................................................................... 239

프레임워크 이용의 단점 ...................................................................................... 240

6.8 정리 .....................................................................................................................242

LESSON 7 | 보안을 확보하기 위한 방법 244

7.1 왜 보안을 확보해야 하는가? .............................................................................244

웹 애플리케이션이 지켜야 할 보안 .................................................................... 244

7.2 웹 애플리케이션에 대한 대표적인 공격 수법과 그 대책 ...............................246

SQL 인젝션 ........................................................................................................... 246

크로스 사이트 스크립팅(XSS)............................................................................ 249

세션 하이재킹 ...................................................................................................... 251

크로스 사이트 요청 위조 ..................................................................................... 256

강제 브라우징 ...................................................................................................... 262

디렉터리 접근 공격 ............................................................................................. 263

xi

7.3 설계 · 실행의 실수에 기인한 오작동이나 보안 문제를 막기 위한 대책........266

뒤로 가기 버튼 대책............................................................................................. 266

이중 폼 제출 대책 ................................................................................................ 269

hidden 매개변수를 이용할 때의 주의점 ........................................................... 271

디버그 정보를 출력하지 않는다 ......................................................................... 272

전역 변수에 정보를 담지 않는다 ........................................................................ 273

7.4 정리 .....................................................................................................................275

LESSON 8 | 맺음말 278

감사의 말 .............................................................................................................. 279

제5쇄 증쇄에 즈음해 ........................................................................................... 280

LESSON 9 | 부록 282

9.1 참고 서적 · 사이트 .............................................................................................282

0장 ........................................................................................................................ 282

2장 ........................................................................................................................ 282

3장 ........................................................................................................................ 283

4장 ........................................................................................................................ 283

5장 ........................................................................................................................ 284

6장 ........................................................................................................................ 285

7장 ........................................................................................................................ 286

찾아보기 282

xii

•옮긴이 글•

1990년대만 해도 인터넷은 일반인들에게 아직 생소한 존재였다. 온라인이라고 하면 먼저 PC통신을 떠올렸

으며, 주로 전화선을 이용해 모뎀으로 통신을 했기에 속도는 턱없이 느렸다. 지금은 ‘겨우’ 몇 메가바이트이

지만, 그때는 ‘무려’ 몇 메가바이트였다. 게다가 전화 요금 체계에 시분제가 적용됨에 따라 유선 통신 요금의

부담은 지금과는 비교도 되지 않았다. 밤새 PC 통신을 하다가 전화 요금이 십여 만 원씩 나와 고지서를 받

고 깜짝 놀란 어머니(혹은 아버지)에게 빗자루로 맞았다는 이야기를 심심치 않게 들을 수 있었던 시절이었

다(옮긴이도 빗자루로 맞지는 않았지만 비슷한 경험을 했다). 이렇듯 온라인을 통한 정보 교환에 제약이 많

았던 시절이기에 소프트웨어는 패키지 형태로 판매되는 데스크톱 애플리케이션이 주류를 이뤘다. 그러나

ADSL과 VDSL 등 점차 초고속 통신망이 구축되고 인터넷이 일반화되면서 소프트웨어의 흐름은 데스크톱

애플리케이션에서 웹 애플리케이션으로 넘어오고 있다.

이제 웹 애플리케이션은 우리 생활에 없어서는 안 될 필수품이다. 우리는 Gmail이나 각종 포털 사이트의

이메일 서비스를 통해 이메일을 주고받으며, 사고 싶은 물건이 있으면 인터넷에서 최저가를 검색한 다음 인

터넷 쇼핑몰에서 구입한다. 내가 타려는 버스가 어디쯤 와 있는지도 인터넷에서 확인할 수 있게 됐다. 모두

웹 애플리케이션의 발달로 가능해진 일들이다.

이 책은 그런 웹 애플리케이션의 개발에 뜻을 두고 있는 분들을 위한 입문서다. 입문서이기에 구체적인 기

술을 자세히 다루지는 않지만, 그 대신 웹 애플리케이션을 개발하기 위한 기본적인 지식과 역사, 배경을 친

절하게 설명해 준다. 글쓴이가 이 책에서 많은 중점을 둔 부분은 바로 웹 애플리케이션 개발 기술이 오늘에

이르기까지의 역사와 배경에 관한 설명이다. 어떤 기술이 개발된 이유는 그 기술이 필요했기 때문이다. 또한

처음부터 완벽한 기술은 있을 수 없으므로 문제점이 발생하기 마련이고, 그 문제점을 해결하기 위해 또 다

른 기술이 탄생한다. 이러한 역사 속에서 현재의 웹 애플리케이션 개발 기술로 발전된 것이며, 앞으로도 새

로운 필요성에 따라 신기술이 속속 탄생할 것이다. 그런 역사를 이해한다면 어떤 기술을 어떻게 이용해야

할지 아는 데 많은 도움이 될 것이며, 새로운 기술이 탄생해도 그 기술을 좀 더 빨리 이해할 수 있으리라는

것이 글쓴이의 생각이다. 그리고 옮긴이 역시 글쓴이의 생각에 동의한다.

xiii

뭔가를 배울 때 단순히 내용만을 암기하는 것은 큰 도움이 되지 못한다. 그 바탕에 깔려있는 배경을 알아

야 응용력이 생기기 마련이다. 독자 여러분도 학교에서 수학 공식을 암기한 경험이 있을 것이다. 참고서에 나

와 있는 공식을 무작정 외우기만 하면 똑같은 패턴의 문제가 나왔을 때는 간단하게 숫자만 바꿔서 빠르게

풀 수 있지만, 조금만 문제를 비틀어도 벽에 부딪치고 만다. 그러나 그 공식이 어떤 과정을 거쳐 나왔는지를

이해한다면 패턴에서 벗어난 문제를 만나더라도 당황하지 않고 이 문제를 어떻게 풀어야 할지 곰곰이 생각

하며 풀 수 있게 된다. 어학에서 관용 표현이나 속담 등을 외울 때도 마찬가지다. 그 표현 또는 속담이 어떤

배경에서 나왔으며, 때로는 그 안에 어떤 역사가 담겨 있는지 알면 단순 암기할 때보다 훨씬 이해도 잘 되고

잘 잊어버리지도 않는다. 이와 같이 역사와 배경을 알면 이해도가 훨씬 높아지며, 무엇보다도 배우는 것이

즐거워진다.

다만 이 책은 아무런 지식도 없는 상태에서 웹 애플리케이션 개발 기술을 처음부터 배우려 하는 사람을

위한 책은 아니다. 전문적인 내용을 최대한 배제했다고는 하지만, HTML에 관한 기초 지식과 간단한 프로

그래밍 지식 정도는 알고 있다는 가정에서 이야기가 진행된다. 그러나 지금부터 공부를 시작하는 사람도 가

벼운 마음으로 읽어 본다면 앞으로 웹 애플리케이션 개발 기술을 공부하기 위해 필요한 개념을 잡는 데 많

은 도움이 되리라고 생각한다.

아무쪼록 이 책이 웹 애플리케이션 개발에 뜻을 두고 있는 많은 독자 여러분에게 도움이 되기를 기원한다.

2012년 4월

옮긴이

1

0L e s s o n

프롤로그

2

프롤로그0LESSON

zz 사회의z필수z요소가z된z웹z애플리케이션

인터넷이 일반적으로 널리 이용된 지도 벌써 10년 이상이 지났다. 이제 인터넷은 우리 생활 곳곳에서 이용되

고 있다. 우리는 밖으로 나가지 않아도 집안에서 뉴스나 일기 예보 같은 생활에 필요한 정보를 얻고 인터넷을

이용해 쇼핑이나 은행 거래를 할 수 있게 됐다. 또 블로그와 SNS 1 , 트위터 2 처럼 인터넷이 있기에 가능한 서비

스도 등장했다. 그리고 행정 서비스나 각종 신청 등도 인터넷으로 손쉽게 해결할 수 있는 세상이 됐다.

이러한 서비스는 컴퓨터와 인터넷의 조합을 통해 실현됐는데, 이처럼 컴퓨터상에서 작동하는 프로그램을

‘웹 애플리케이션’이라고 한다. 이 책을 집필하고 있는 2010년 현재 IT 업계의 시스템 개발 업무는 대부분 이

러한 웹 애플리케이션이 차지하고 있으며, 웹 애플리케이션을 설계, 개발할 수 있는 기술자의 수요는 점점 증

가하고 있다.

zz 웹z애플리케이션z개발의z어려움

이와 같은 상황 속에서, 웹 애플리케이션의 개발에 관여하는 사람 중에는 다음과 같은 고민을 하는 사람도

많지 않을까 한다.

y 웹 애플리케이션을 만들어 작동시킬 수는 있지만, 장애가 발생하면 어떻게 해야 할지 모르겠다.

y 웹 애플리케이션 개발 프로젝트를 관리하고 있지만 현장에서 발생하는 문제가 이해되지 않는다.

y 새로운 언어나 기술이 잘 익혀지지 않아 고생하고 있으며, 프로그래밍이 즐겁지 않다.

1 　 소셜 네트워킹 서비스(Social Networking Service) - 네트워크를 통해 개인과 개인의 커뮤니케이션을 돕는 서비스. 대표적인 SNS로 트위터

(http://www.twitter.com/)를 들 수 있다.

2 　 트위터(Twitter) – 2010년 현재 유행하는 서비스. 그때그때의 행동이나 기분 등을 트윗(Tweet; 재잘대기)이라고 하는 짧은 문장으로 입력해

인터넷을 통해 공유한다. 블로그보다 입력하기가 간편하며, 팔로워(Follower)라고 하는 다른 사용자의 트윗을 항상 확인하는 기능을

이용해 SNS보다 느슨한 커뮤니티를 형성할 수도 있다.

3

0이러한 고민의 원인 중 하나로 웹 애플리케이션이 작동하는 구조를 이해하고 있지 못하다는 점을 들 수

있다. 근본적인 구조를 제대로 이해하지 못하면 장애의 원인을 규명해 문제를 본질적으로 해결할 수 없다.

또 표면적인 사용법을 따라하기만 해서는 구조를 제대로 이해할 수 없어 기술 습득에 시간이 걸리며 프로

그래밍도 즐겁지 않다.

zz 웹z애플리케이션z개발z기술은z어디서z배우는가?

그렇다면 웹 애플리케이션 개발에 관한 지식과 기술은 어디서 익혀야 할까?

안타깝지만 책이나 잡지를 읽고 독학으로 익히거나 현장에서 선배 엔지니어에게 배우는 등 조금씩 익혀

나가는 수밖에 없다는 것이 내가 느끼는 현실이다. 한때 업무의 연장선상으로 웹 애플리케이션 개발 기술에

관한 세미나를 연 적이 있었는데, 다뤄야 할 사항이 너무 많아서 시간이 몹시 부족하다는 것이 솔직한 느낌

이었다.

한편 대학의 교육 현장은 어떤 상황일까? 나는 정보공학과 출신이지만 내가 수업에서 배운 지식 중 IT 업

계의 개발 현장에서 즉시 써먹을 수 있는 것은 없었다. 그리고 지금도 그런 상황은 그다지 달라지지 않은 듯

하다. 이 문제에 관해 모교의 교수님께 여쭤 본 적이 있는데, 역시 가르치는 입장에 있는 교수님들로서도 기

술 변화의 흐름을 따라잡기가 쉽지 않아서 수업에 그런 내용을 포함하기가 어렵다고 한다.

zz z왜z여러분은z웹z애플리케이션z개발z기술을z배우지z못하는z것일까?

이와 같은 상황이 개선되지 않는 원인은 뭘까? 나는 두 가지 이유가 있다고 생각한다.

첫째는 웹 애플리케이션이라는 시스템의 역사가 일천하다는 점이며, 둘째는 웹 애플리케이션의 개발에

필요한 지식이 너무 방대하다는 점이다.

웹 애플리케이션 자체가 최근 10년 정도 사이에 새롭게 확산된 것이며, 개발 기법 자체도 계속 발전하고

있다. 현장의 일선에서 일하는 엔지니어조차 조금만 방심하면 순식간에 뒤처지고 말 정도이니 대학이나 기

업에서 체계적으로 교육하기가 어려울 수밖에 없다.

예를 들어 수학이나 물리는 역사가 수백 년에 이르며, 비교적 새로운 공학 계열의 분야조차도 역사가 100

년은 된다. 우리가 학교에서 배우는 과목은 그런 오랜 역사 속에서 조금씩 체계를 잡은 것들이다. 그에 비해

웹 애플리케이션은 안 그래도 역사가 짧은 컴퓨터 분야에서도 최신 기술이다 보니 체계적으로 가르치기가

어려운 것은 당연한 일이 아닐까?

Lesson 0 프롤로그

4

또한 웹 애플리케이션은 개발에 필요한 지식이 너무 방대하다. 웹 애플리케이션 자체가 기존의 여러 가지

기술을 이용해 만들어졌기 때문에 이것을 제대로 이해하려면 프로그래밍 언어는 물론 네트워크와 HTML,

애플리케이션 서버, 운영체제와 관련된 지식까지 익혀야 한다. 물론 모든 지식을 완전히 이해하지 못해도 웹

애플리케이션의 개발에 관여할 수는 있다. 그러나 그래서는 시스템 전체를 설계하거나 문제가 발생했을 때

원인을 찾아내 해결할 수 있는 수준 높은 엔지니어가 될 수 없다.

이처럼 폭넓은 지식을 독학으로 익히려면 긴 시간이 걸리며, 이 지식을 가르칠 수 있는 인재는 개발 현장

에서도 서로 모셔 가려고 하므로 교육에 시간을 할애할 여유가 없는 것이 현실이다.

zz 대상z독자

그래서 나는 다음과 같은 사람들을 주된 대상으로 웹 애플리케이션 개발에 필요한 핵심 지식을 이해를 돕

고 싶은 마음에 이 책을 썼다.

1. 앞으로 웹 애플리케이션을 개발하려는 사람

2. 웹 애플리케이션 개발 경험은 있지만 어떤 구조로 작동하는지 설명하지 못하는 사람

3. 웹 애플리케이션 개발 프로젝트를 관리하고 있지만 현장에서 사용되는 기술을 제대로 파악하고 있

지 못하다고 느끼는 사람

1장에서 5장까지는 지금부터 웹 애플리케이션 개발을 공부하려고 하는 사람들이 꼭 알고 있었으면 하는

내용이다. 또 6장과 7장은 어느 정도 웹 애플리케이션 개발 경험이 있는 사람들이 기초 지식을 강화하기 위

한 내용이다.

zz 이z책을z읽을z때z필요한z사전z지식

되도록 사전 지식이 적어도 읽을 수 있게 신경을 썼지만, 다음 사항에 관해서는 어느 정도 지식이 있다는 전

제하에 이야기를 진행한다. 물론 완전히 이해하고 있을 필요는 없다. 이 책을 계기로 각 지식의 깊이를 더하

면 될 것이다.

(1) HTML에 관한 지식

간단한 웹 사이트를 만들 수 있을 정도의 HTML 태그에 관한 기초 지식이 있다고 전제했다.

5

0(2) 프로그래밍에 관한 기초 지식

이 책에서는 주로 전반에는 PHP를, 후반에는 자바(Java)를 예로 들어 설명을 진행한다. 이러한 언어에 관해

깊은 지식이 없어도 읽을 수 있게 신경을 썼지만, 변수나 제어 구조 등 프로그래밍 언어와 관련된 기초적인

내용은 이미 알고 있다고 전제했다.

(3) 객체지향 프로그래밍에 관한 지식(가능하다면)

후반의 자바를 사용한 예제에서는 아무래도 객체지향에 관한 용어가 등장하는 부분이 있다. 깊은 지식이 없

어도 읽어 나갈 수 있게 신경 썼지만 좀 더 깊이 이해하고 싶은 사람에게는 참고문헌 [1]이나 [2]를 추천한다. 3

zz 가장z효율적으로z기술을z배우는z방법

이 책을 쓰면서 나는 최신 기술이 아니라 몇 년이 지나도 유용한 기본적인 개념을 알리는 데 주안점을 뒀다.

앞에서도 설명했듯이 웹 애플리케이션의 세계에서는 시시각각 새로운 기술이 등장하고 있어 이 책을 집필

하는 시점의 최신 기술을 소개해도 금방 구식이 되어 버리기 때문이다.

핵심을 파악해 기술을 이해하려면 그 역사와 배경을 아는 것이 효율적이지 않을까? 기술은 우리 인간이

만들어낸 것이므로 그것이 필요해진 배경이 있기 마련이다. 어떤 배경에서 문제의식이 싹트고, 그것을 해결

하고자 새로운 기술이 만들어진다. 그리고 그 기술을 이용하는 과정에서 또 다른 문제점이 발생하며, 그 문

제를 해결하기 위해 또 새로운 기술이 탄생한다……. 이러한 과정의 반복 속에서 지금 우리가 이용하고 있

는 기술이 탄생했다고 할 수 있다.

배경

문제점

해결 새롭게 발생

기술

▲ 그림0-1 문제점과 기술의 사이클

3 　 참고문헌 목록은 권말에 정리해 실었다.

Lesson 0 프롤로그

6

요컨대 어떤 기술이 탄생한 배경을 이해하면 그 기술을 어떻게 이용해야 할지 알 수 있다. 그리고 지금까

지의 배경을 파악해 두면 또 새로운 기술이 등장했을 때 좀 더 빠르게 이해할 수 있지 않을까?

중국의 사상가인 공자는 이런 말을 남겼다.

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

(學而不思則罔, 思而不學則殆)

책을 읽거나 다른 사람에게 가르침을 받아도 그 지식을 자신의 머리로 곰곰이 생각해 소화하지 못하면

자신의 것이 되지 않는다. 또 생각만 할 뿐 책이나 다른 사람에게 배우지 않으면 생각이 편협해진다. 즉 배움

과 생각의 균형이 중요하다는 말이다.

인터넷의 보급으로 대량의 지식을 손쉽게 얻을 수 있게 됐다. 그러나 공자의 말씀처럼 무작정 지식을 얻는

다고 자신의 것이 되지는 않는다. ‘왜 만들어졌는가?’, ‘왜 필요한가?’를 곰곰이 생각하고 이해해야 한다.

그래서 이 책에서는 되도록 딱딱하지 않은 정도로 알기 쉽게 배경을 해설하면서 웹 애플리케이션에 관한

기술을 소개하고자 한다. 이 책을 다 읽었을 때 지금까지 먹구름이 짙게 깔렸던 독자 여러분의 웹 애플리케

이션 세계가 맑게 갠 세계로 변하기를 기도한다. 또 독자 여러분이 이 책을 통해 웹 애플리케이션에 관한 기

술뿐 아니라 기술을 배운다는 점에 관해서도 생각하게 된다면 행복할 것이다.

7

1L e s s o n

웹 애플리케이션이란 무엇인가?

8

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

웹 애플리케이션이란 무엇일까? 그리고 다른 애플리케이션과 무엇이 다를까?

이 장에서는 워밍업을 겸해 이것부터 설명하겠다.

1.1 데스크톱 애플리케이션

가령 여러분이 평소에 사용하는 워드프로세서 소프트웨어나 스프레드시트 소프트웨어, 이메일을 읽고 쓰

는 데 이용하는 이메일 프로그램 같은 소프트웨어는 데스크톱 애플리케이션이라고 한다(그림 1-1).

▲그림 1-1 데스크톱 애플리케이션

대표적인 데스크톱 애플리케이션으로는 마이크로소프트의 워드와 엑셀, 아웃룩 같은 오피스 애플리케

이션을 들 수 있다. 이러한 애플리케이션의 특징을 간단히 살펴보면 다음과 같다.

9

1

y 주된 처리는 본인의 컴퓨터(PC)상에서 진행된다

y 화면은 운영체제의 기능을 이용해 표시된다

y 애플리케이션을 PC에 설치할 필요가 있다

데스크톱 애플리케이션의 커다란 특징은 기본적으로 여러분이 가지고 있는 컴퓨터상에서 모든 처리가

진행된다는 것이다. 이러한 애플리케이션을 이용하려면 패키지를 구입해 CD-ROM이나 DVD-ROM에서

소프트웨어를 컴퓨터에 설치해야 한다. 또 무료로 공개된 애플리케이션은 대부분 인터넷에서 내려받을 수

있는데, 이 경우도 설치라는 과정이 필요하다. 이렇게 해서 설치한 애플리케이션은 설치된 컴퓨터에서만 작

동한다.

애플리케이션 작동한다!

설치

1.2 웹 애플리케이션

한편 웹 애플리케이션의 경우, 여러분은 평소에 그 존재를 거의 의식하지 못한 채 사용하고 있을 것이다. 웹

애플리케이션을 이용하기 위해 돈을 내고 구입하거나 직접 설치하는 일이 거의 없기 때문이다. 그러나 인터

넷이 일반화된 현재, 웹 애플리케이션은 세상 곳곳에서 활약하고 있다. 예를 들어, 나는 기다리는 것을 너무

나 싫어하는 성격이라 외출할 때는 반드시 전철시간표를 확인해 정확한 시각에 목적지에 도착하려고 한다.

15년도 더 전에 내가 학생이었을 때는 역에서 나눠 주는 시간표를 지갑에 넣고 다니면서 그걸로 시간을 확

인했다. 그러다 컴퓨터에서 이용할 수 있는 시간표 애플리케이션이 나왔고, 그것으로 전철 도착 시각을 확인

하게 되었다. 이 애플리케이션을 이용하면 수작업으로는 알 수 없는 최단 경로나 가장 요금이 싼 노선 등을

검색할 수 있다.

Lesson 1 웹 애플리케이션이란 무엇인가 ?

10

이후 인터넷이 등장하자 굳이 소프트웨어를 구입하지 않아도 인터넷상에서 무료로 검색할 수 있게 됐다.

http://ekitan.com의 환승 안내 서비스(그림 1-2) 등이 좋은 예다. 그리고 현재는 휴대전화에서도 이런 서비

스를 이용할 수 있게 되어 언제 어디서나 전철시간표를 확인할 수 있다. 덕분에 이제는 전철이 오지 않아 짜

증을 내는 일도 없어졌다.

▲그림 1-2 ekitan의 환승 안내 서비스

예를 한 가지 더 들어 보겠다.

컴키드였던 내가 프로그래밍을 처음 시작한 때는 20년도 더 전이었다. 당시는 아직 프로그래밍이라는 것

이 일반적이지 않아서 프로그래밍 공부를 하려고 해도 근처 서점에서는 관련 서적을 구할 수가 없었다. 지

금이라면 인터넷에서 검색할 수 있지만 당시는 인터넷은커녕 컴퓨터 통신조차 꿈같은 이야기였다. 그래서

나는 자전거를 타고 시내의 규모가 큰 서점을 돌아다니며 원하는 책을 힘들게 구했다.

그런데 지금은 인터넷으로 뭐든 살 수 있는 시대가 됐다. 아마존(Amazon)에서 검색하면 원하는 책을 십중

팔구 찾을 수 있다. 마음에 드는 책이 있으면 신용카드로 구입하고 택배가 오기를 기다리면 된다. 이제 옛날

처럼 자전거로 서점을 순회하지 않아도 된다(그만큼 내 몸무게도 늘어났지만……).

게다가 과거의 구입 이력을 바탕으로 책을 추천하는 이메일도 보내 준다. 더할 나위 없이 편리한 세상이

된 것이다.

11

1

▲그림 1-3 아마존의 판매 서비스

이처럼 우리가 현재 당연하다는 듯이 인터넷에서 이용하는 서비스가 웹 애플리케이션의 앞모습이다. 통

상적인 웹 사이트(이른바 홈페이지)에서는 공개된 콘텐츠를 우리가 수동적으로 열람할 뿐이었다. 한편 웹

애플리케이션은 우리가 능동적으로 이용할 것을 목적으로 한다. ‘출발지와 목적지를 입력해 최적의 환승 경

로를 검색한다’, ‘어렴풋이 기억하는 제목을 실마리로 원하는 책을 검색해 구입한다’ 등의 목적을 실현하려

면 지금까지는 데스크톱 애플리케이션을 사용해야 했지만 이제는 인터넷을 통해 이용할 수 있게 된 것이다.

그렇다면 웹 애플리케이션은 데스크톱 애플리케이션과 무엇이 다를까? 데스크톱 애플리케이션과 같은

형식으로 웹 애플리케이션의 특징을 나열하면 다음과 같다.

y 주된 처리는 본인의 컴퓨터(PC)가 아니라 서버상에서 진행된다

y 화면은 HTML로 표현되며, 웹 브라우저에 표시된다

y 애플리케이션을 PC에 설치할 필요가 없다

처음 두 가지는 구조와 관련된 특징이다. 여기서 말하는 주된 처리는 경로 검색이나 서적의 검색과 구입이

라는 처리다. 데스크톱 애플리케이션에서는 이런 처리를 여러분이 가지고 있는 컴퓨터가 담당했다. 그러나

Lesson 1 웹 애플리케이션이란 무엇인가 ?

12

웹 애플리케이션에서는 서버 1 라고 하는 컴퓨터가 담당한다. 또 웹 애플리케이션의 화면은 HTML로 표현되

며, 인터넷 익스플로러(Internet Explorer)나 파이어폭스(Firefox) 같은 웹 브라우저에 표시된다. 2

그리고 우리와 같은 사용자에게 가장 큰 특징은 세 번째인 ‘설치가 필요 없다’라는 점일 것이다. 우리는 돈

을 내느냐 안 내느냐는 둘째 치고 설치라는 번거로운 작업에서 해방된다. 그리고 인터넷과 연결된 컴퓨터만

있으면 언제 어디서나 웹 애플리케이션을 이용할 수 있다.

이것이 웹 애플리케이션이 보급된 커다란 이유 중 하나다.

지금까지 사용자가 본 웹 애플리케이션, 즉 앞모습에 대해 소개했다. 그리고 이 책에서 지금부터 여러분에

게 알려 주고자 하는 것이 웹 애플리케이션의 뒷모습, 즉 구조에 대해서다.

1.3 정리

이 장에서는 다음과 같은 내용을 배웠다.

yy 웹y애플리케이션의y구체적인y예

yy 데스크톱y애플리케이션과y웹y애플리케이션의y차이

이 장에서

배운 내용

데스크톱 애플리케이션 웹 애플리케이션

처리 주체 자신의 PC 서버

화면 표시 운영체제상에서 표시 웹 브라우저에서 표시

설치 필요 불필요

▲표 1-1 데스크톱 애플리케이션과 웹 애플리케이션의 차이

다음 장에서는 조금 과거로 거슬러 올라가 웹 애플리케이션이라는 기술이 필요해진 배경을 소개하겠다.

1 　 서버에 관해서는 4장에서 자세히 설명하겠다.

2 　 조금 복잡하지만, 인터넷 익스플로러나 파이어폭스 등의 웹 브라우저 자체는 데스크톱 애플리케이션이다. 그리고 웹 브라우저에 표시되는

ekitan이나 아마존 등이 웹 애플리케이션이다.

13

2L e s s o n

웹은 어떻게 발전했는가?

14

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

이 장에서는 어떤 이유로 웹이 탄생해 웹 애플리케이션으로 발전했는지 그 흐름을 간단히 소개하겠다.

이러한 지식은 웹 애플리케이션을 개발할 때 반드시 필요한 것은 아니므로 급한 사람이나 “이런 건 이미

알고 있다고!”라는 독자는 건너뛰어도 무방하다. 다만 프롤로그에서 이야기했듯이 어떤 기술이 탄생한 배경

이나 흐름을 이해하면 그 후에 새로운 기술이 나와도 비교적 쉽게 이해할 수 있다. 기술은 우연이 아니라 필

연적으로 탄생하기 때문이다. 그 필연성을 이해하는 것이 새로운 기술을 빠르게 이해하기 위한 지름길이다.

또 역사의 흐름은 기초에서 응용으로 진행되므로 기술의 역사를 이해하면 그 기술을 체계적으로 이해할

수 있다.

2.1 WWW의 탄생과 보급

1장에서도 사례를 소개했듯이, 인터넷이 보급됨에 따라 우리의 생활은 크게 편리해졌다. 그런데 이 편리함을

낳은 인터넷이라는 것은 과연 무엇일까? 여기서는 먼저 인터넷의 탄생과 발전의 역사를 되돌아보고자 한다.

zz 전z세계의z컴퓨터를z연결하는z인터넷

인터넷(Internet)은 간단히 말해 전 세계의 컴퓨터를 상호간에 접속하고 통신할 수 있게 한 네트워크망이

다. 간단히라고는 했지만 뭔가 잘 이해가 되지 않는 사람도 있을 것이다. 그럴 때는 좀 더 친근한 예로 전화

를 생각해 보면 이해하기 쉬울지도 모르겠다. 현재 전 세계에는 전화망이 구석구석까지 깔려 있어서 전화번

호만 알면 누구에게나 전화를 걸어 이야기를 나눌 수 있다. 이것은 물론 전 세계의 전화가 전화선으로 연결

돼 있기에 가능한 일이다.

이제 이 전화를 컴퓨터로 치환해 보자. 그것이 바로 인터넷의 이미지다(그림 2-1).

15

2

▲그림 2-1 인터넷의 이미지

이처럼 인터넷은 전 세계의 컴퓨터를 연결하는 네트워크망을 가리킨다. 다만 인터넷이 처음부터 세계 규

모로 구축됐던 것은 아니다. 인터넷은 탄생한 이래 지금까지 수십 년 동안 여러 가지 컴퓨터 네트워크를 상

호 연결함으로써 발전해 왔다. 인터넷의 인터(Inter)는 ‘~사이’라든가 상호(相互)라는 의미다. 즉 인터넷은 ‘네

트(Net)를 상호간에 연결하는 것’이라는 뜻에서 붙은 이름이다.

기본적으로 전화로는 우리가 말하는 음성 신호밖에 주고받지 못한다. 그러나 인터넷으로는 디지털화된

온갖 정보를 주고받을 수 있다. 인터넷을 사용하면 우리가 평소에 이용하고 있는 이메일, 웹 사이트의 열람,

화상이나 영상의 송수신 등 컴퓨터상에서 다루는 모든 정보를 지구 뒤편까지 1 보낼 수 있다.

zz z인터넷z보급의z견인차z월드z와이드z웹과z모자이크

원래 인터넷은 지금으로부터 약 40년 전인 1969년에 초기 원형 2 이 탄생했다. 그러나 탄생하고 약 20년 동안

은 대학이나 연구 기관의 관계자 등 극히 일부의 제한된 사람들만이 이용했는데, 여기에는 두 가지 이유가

있다. 첫째는 인터넷을 이용하기 위한 컴퓨터와 네트워크 자원이 지금에 비해 매우 고가였다는 점이고, 둘

째는 이용 용도가 주로 이메일 교환이나 파일 공유 같은 비교적 평범한 것이어서 컴퓨터와 인연이 없는 사

람들은 그다지 흥미를 느끼지 못했다 3 는 점이다.

1 　 최근에는 행성 간 인터넷의 연구도 진행되고 있다. 미래에 우리의 자손이 달이나 화성, 혹은 우주 식민지(?)에서 사는 시대가 온다면

행성 간 인터넷이 당연하다는 듯이 이용될지도 모른다.

2 　 미국 국방성이 연구·조사를 목적으로 구축한 ARPANET(아파넷)이라는 네트워크가 현재의 인터넷의 원형이 되었다.

3 　 지금은 많은 사람이 이메일을 이용하고 있지만 당시는 컴퓨터 자체가 대중적이지 않았고 휴대전화 역시 일반화되지 않았기 때문에 극히

제한적인 사람들만의 문화였다.

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

16

zz WWW의z탄생

이런 상황을 바꿔 버리는 계기가 된 것은 월드와이드웹(World-Wide Web)과 현재 우리가 이용하고 있는 웹

브라우저의 원형인 NCSA 모자이크(Mosaic)라는 소프트웨어의 등장이었다.

월드 와이드 웹은 현재 WWW나 간단하게 웹(Web)이라고 생략해서 부른다. 좀 더 일반적으로는 홈페이

지나 웹 사이트라고도 한다.

먼저 이 WWW라는 개념이 어떻게 탄생했는지 살펴보자.

세계 최초로 WWW가 고안된 시기는 1989년으로, 의외라고 생각되겠지만 소립자 물리학 연구소에서 탄

생했다. 당시 유럽 원자핵 연구 기관(CERN 4 )이라는 조직에서 핵 소립자 실험의 성과를 전 세계 연구자들

과 공유하자는 이야기가 나왔다. 그러나 당시 이용이 가능했던 이메일이나 파일 전송 같은 기술은 사용 편

의성이 너무 떨어졌기에 좀 더 좋은 방법을 찾고자 시행착오를 거듭했다. 그러던 가운데 CERN 소속의 팀

버너스 리(Tim Berners-Lee) 박사가 정보 공유를 위해 제안·개발한 것이 WWW였다.

연구 자료 B

연구 자료 A

어떻게공유하지?

▲그림 2-2 정보 공유에 어려움을 겪는 사람들

버너스 리 박사는 먼저 연구 성과를 HTML(Hyper Text Markup Language)이라고 하는 통일된 형식으로 표

현할 것을 생각했다. 연구 성과를 표현하려면 문장뿐 아니라 도표와 참고 문헌 등이 필요한데, 이러한 것들

을 텍스트 파일(문자만으로 구성된 파일)만으로 표현할 수 있게 만든 것이 HTML이다. HTML은 서서히 규

격이 확립돼 갔고, 지금도 웹 사이트에 사용되고 있음은 누구나 알고 있는 사실이다. HTML의 자세한 작성

방법 등은 이미 수많은 관련 서적이 출판돼 있으므로 여기서는 생략한다.

여기서 획기적이었던 것은 하이퍼텍스트(Hyper Text)라고 하는 구조다. 하이퍼텍스트에서는 문서 간의 참

조가 하이퍼링크(Hyper Link)라는 컴퓨터가 이해할 수 있는 형식으로 작성돼 있기 때문에 참조하는 곳의 문

4 　 ‘세른’ 또는 ‘선’이라고 읽는다.

17

2

서를 순식간에 열람할 수 있다(그림 2-3). 이에 따라 지금까지 수작업으로 참조해야 했던 참고 문헌이나 관

련 논문 등의 자료를 네트워크를 경유해 손쉽게 열람할 수 있게 됐다.

하이퍼링크 C

하이퍼링크 C

하이퍼링크 B

하이퍼텍스트 A

하이퍼텍스트 B

하이퍼텍스트 C

▲그림 2-3 하이퍼텍스트와 하이퍼링크의 관계

이처럼 네트워크상에서 링크된 하이퍼링크의 연결이 마치 거미집처럼 보인다고 해서(그림 2-4) 월드 와이

드 웹(World-Wide Web, 전 세계에 퍼져 있는 거미집)이라는 이름이 붙은 것이다.

자료 A

관련 논문연구 자료

참고 문헌

자료 B

관련 논문

연구 자료참고 문헌

자료 C

관련 논문연구 자료

연구 자료

참고 문헌

참고 문헌

자료 D

관련 논문

▲그림 2-4 월드 와이드 웹의 이미지

이 WWW라는 구조가 등장하자 정보의 상호 전달 효율은 크게 향상됐고 연구자들은 서로의 연구 성과

를 네트워크상에 공개하고 자유롭게 열람할 수 있게 됐다.

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

18

오오!

훌륭해!!

연구 자료 B

연구 자료 A

▲그림 2-5 WWW의 탄생!

zz 현대z웹z브라우저의z시조인zNCSAz모자이크

이렇게 해서 WWW이 등장했지만, 한동안은 연구자들 사이에서만 조용히 이용되었다. 현재 우리가 웹 브

라우저를 통해 열람하는 인터넷상의 웹 페이지는 여기저기에 그림과 동영상 등이 있어서 시각적으로 매우

즐겁다. 그러나 WWW 등장 초기의 웹 브라우저는 오직 문자만 표현할 수 있었다. 그림 2-6을 보자. 현재의

브라우저에 표시된 시각적인 웹 페이지다. 지금은 이런 웹 페이지를 당연하게 생각한다.

▲그림 2-6 현대의 시각적인 웹 페이지

19

2

그러나 텍스트만 표현할 수 있는 브라우저 5 에서 이 웹 페이지를 보면 그림 2-7처럼 된다. WWW가 갓 등

장했을 무렵의 웹 브라우저는 이처럼 텍스트만 표시할 수 있었으며, 그림이나 사진 등은 다른 창에 표시되

는 것이 일반적이었다. 이처럼 텍스트 중심으로 표현되던 웹 페이지를 현재와 같이 문자와 그림을 함께 표현

할 수 있게 만든 것이 일리노이 공과대학의 미국 국립 슈퍼컴퓨터 응용 연구소 6 에 근무하던 마크 앤드리슨

(Marc Andreessen)이 1993년에 개발한 NCSA 모자이크(이하 모자이크)라는 웹 브라우저다. 모자이크가 개

발되어 누구나 무료로 이용할 수 있게 공개된 덕분에 WWW의 이용은 크게 확산됐다. 종전에 비해 풍부한

표현이 가능해지면서 연구자뿐 아니라 좀 더 일반인에 가까운 사람들의 흥미를 끌게 된 것이다.

HTML은 프로그래밍 지식이 없어도 비교적 쉽게 작성할 수 있기 때문에 연구 성과 외에도 다양한 사람

들이 여러 가지 정보를 인터넷에 공개하기 시작했다.

▲그림 2-7 텍스트만으로 표현된 웹 페이지

5 　링크스(Lynx, http://lynx.isc.org/)라고 하는 텍스트 기반의 웹 브라우저다.

6 　 National Center for Supercomputing Applications. 약칭 NCSA.

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

20

게다가 1990년대 후반부터 2000년대에 걸쳐 개인용 컴퓨터의 성능이 높아지고 가격이 저하되는 양상이

지속되고 일본 내에서는 ADSL과 광통신이 보급됨에 따라 고속 네트워크를 저렴한 가격에 24시간 이용할

수 있게 되어 현재와 같은 인터넷 이용 방식이 단숨에 보급됐다.

그리고 모자이크를 기반으로 발전시킨 것이 인터넷 익스플로러나 파이어폭스 등 현재 우리가 이용하고

있는 웹 브라우저다.

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

지금까지 WWW의 탄생과 보급의 역사를 간단히 소개했다. 그리고 지금부터는 WWW의 여명기에 발명되

어 지금도 웹 시스템의 기초를 이루고 있는 기술을 소개하겠다.

zz 웹z서버와z웹z클라이언트

WWW를 통한 하이퍼텍스트의 공개와 열람은 구체적으로는 웹 서버 7 와 웹 클라이언트라는 소프트웨어로

구현된다.

우선 클라이언트와 서버라는 말을 정리하고 넘어가자. 웹 애플리케이션 시스템뿐 아니라 현재의 컴퓨터

시스템에는 클라이언트-서버 모델이라는 형태가 폭넓게 이용되고 있다. 클라이언트와 서버라는 말은 각각

컴퓨터와 해당 컴퓨터상에서 작동하는 소프트웨어를 가리키며, client(고객)와 server(시중드는 사람)라는

의미의 영어가 어원이다.

WWW에서는 웹 서버가 네트워크상에 공개하는 하이퍼텍스트(구체적으로는 HTML 형식의 파일)를 축

적하고 웹 클라이언트의 요청에 따라 필요한 HTML 파일을 건네주는 구조로 돼 있다(그림 2-8).

7 　 WWW 서버나 HTTP 서버라고 부르는 경우도 있는데, 전부 같은 의미라고 생각해도 무방하다. 최근에는 웹 서버라고 부르는 경우가

많으므로 이 책에서도 이렇게 부르겠다.

21

2요청

클라이언트

HTML을 주세요!

서버

네, 주문하신

HTML입니다!

응 답

▲그림 2-8 클라이언트와 서버

그림을 보면 알 수 있듯이 손님과 시중드는 사람의 관계인 것이다. 여기서 일반적으로 서버에 대한 클라이

언트의 요구를 요청(request), 클라이언트에 대한 서버의 반응을 응답(response)이라고 한다. 두 용어는 웹 애

플리케이션 시스템 개발의 세계에서는 자주 나오는 말이므로 꼭 기억해 두자.

현재 웹 서버용 소프트웨어로는 오픈소스 8 로 공개된 아파치 HTTP 서버(Apache HTTP Server) 9 와 마이크

로소프트사의 IIS(Internet Information Services)가 널리 이용되고 있다.

또 웹 클라이언트는 여러분이 평소에 이용하고 있는 인터넷 익스플로러, 파이어폭스, 사파리 등의 웹 브

라우저를 가리킨다.

zz 왜z클라이언트와z서버로z나누는가?

그렇다면 왜 이렇게 클라이언트와 서버로 역할을 나누는 것일까?

WWW와 같이 다양한 콘텐츠 10 를 불특정 다수의 사람에게 공개하려면 콘텐츠를 되도록 한 곳에 정리하

는 편이 관리하기 편하다. 반대로 같은 콘텐츠가 여러 곳에 분산돼 있으면 이를 갱신하기가 힘들어진다. 콘

텐츠가 어디에 보존돼 있는지 파악하고 있다가 그것들을 동시에 갱신해야 하기 때문이다. 따라서 WWW를

구현하려면 웹 서버와 같이 컴퓨터 하나에 정보를 모아 두는 편이 관리가 수월하다.

한편 WWW에서는 많은 사람이 자유롭게 콘텐츠를 열람할 수 있어야 한다. 사용자가 콘텐츠를 열람하기

위해 그 콘텐츠를 보관하는 웹 서버를 직접 조작하는 것은 비현실적이다. 그래서 사용자 앞에 있는 PC를 웹

8 　 오픈소스란 소프트웨어의 소스코드(컴퓨터의 동작을 기술한 명령서)가 공개되어 상용 제품과 달리 기본적으로 누구나 무상으로 이용할 수

있는 소프트웨어를 뜻한다. 오픈소스에 관해서는 제5장 171페이지의 칼럼에서 해설할 것이다.

9 　 정식 명칭은 아파치 HTTP 서버이지만 간단히 아파치라고 부르는 경우가 많으므로 이 책에서도 이후에는 아파치라고 부르겠다.

10 　웹 서버를 통해 공개되는 정보를 일반적으로 콘텐츠라고 한다. HTML도 콘텐츠 중 하나인데, 사진 · 그림이나 동영상, 음악, 우리가

이용하는 프로그램 등도 웹 서버를 통해 배포되므로 전부 콘텐츠라고 부른다.

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

22

클라이언트로 이용할 수 있게 만들고 멀리 떨어져 있는 웹 서버와 웹 클라이언트 사이를 인터넷으로 연결함

으로써 WWW를 구현했다.

이와 같이 불특정 다수의 사용자에게 다양한 웹 콘텐츠를 공개하는 WWW를 구현하고자 서버와 클라

이언트로 역할을 분담한 것이다.

C o l u m n칼럼 클라이언트와 서버 중 어느 쪽이 더 대단한가?

원래의 의미대로라면 고객인 클라이언트의 위치가 더 위인 것처럼 보인다. 그러나 컴퓨터 시스템에서는

고객의 시중을 드는 쪽인 서버가 더 위인 것처럼 생각될 때가 많다.

여기에는 몇 가지 이유가 있다.

ㆍ서버에 더 고성능 컴퓨터가 사용된다는 점

ㆍ서버를 운용하는 데 많은 사람(서버 관리자)이 필요하다는 점

ㆍ서버가 정지하면 수많은 사람이 영향을 받는다는 점

시중드는 쪽이 더 위라고 하면 이상하게 들리겠지만, 뒤에서 묵묵히 쉬지 않고 일하는 서버가 존재하지 않

는다면 현재의 편리한 인터넷 사회는 절대 성립하지 못한다. 그래서 서버가 더 위대한 것이다.

zz ‘그z리소스는z어디에z있지?’z-zURL

WWW가 발명됨에 따라 인터넷상에 대량의 정보가 공개됐으며 그 근간을 이루는 것이 웹서버라는 점까지

는 이해했을 것이다. 그러면 지금부터는 어떻게 해서 웹 브라우저가 웹 서버에서 원하는 콘텐츠를 얻는지에

관해 조금 구체적으로 살펴보자.

그림 2-8(21페이지)를 다시 한 번 보기 바란다. 여기서는 클라이언트가 서버에 “HTML을 주세요.”라고 요

청했는데, 실제로는 좀 더 구체적으로 요구하지 않으면 서버도 난처할 수밖에 없다. 따라서 클라이언트(사

용자)가 “어디 어디에 있는 이 콘텐츠를 읽고 싶다.”라고 지정할 방법이 필요하다. 컴퓨터가 네트워크에 접속

되기 전에는 각 컴퓨터에 보존된 파일에 고유한 11 이름을 붙여 놓으면 문제가 없었다. 그러나 WWW의 경

우는 불특정 다수의 사람이 다양한 콘텐츠를 공개하기 때문에 단순히 컴퓨터상의 파일명만으로는 인터넷

11 　 ‘고유하다’라는 것은 ‘오직 하나로 결정되는’이라는 의미로, 낯선 단어일지도 모르지만 컴퓨터 세계에서는 자주 사용된다. 예를 들어 어떤

회사에 ‘홍’이라는 성을 가진 사람이 세 명이나 있다면 성만으로는 각 사람이 유일하게 구분되지 않는다. 그러나 ‘홍길동’과 같이 성과 이름

을 함께 부르면 누구인지 구분할 수 있으므로 이를 ‘고유하다’라고 할 수 있다. 또 ‘고유하다’는 영어로 ‘Unique’이므로 ‘고유한 이름’을 ‘유니

크한 이름’이라고도 한다.

23

2

전체에서 유일하게 구분되지 않는 문제가 있다.

이 문제를 좀 더 쉽게 이해할 수 있게 현실 세계로 치환해 생각해 보자. 예를 들어 여러분의 친구 중에 이

름이 ‘홍길동’인 사람이 있다고 가정하자. 아주 흔한 성과 이름이다. 약 5,000만 명이 넘는 한국인 중에서 여

러분의 친구인 홍길동을 파악하려면 어떻게 해야 할까?

먼저, 당연하지만 ‘길동’이라는 이름만 가지고는 특정할 수 없다. 다음으로 ‘홍길동’은 어떨까? 이것도 “홍

길동 씨~!”라고 부르면 전국에서 최소한 몇 백 명은 손을 들 것이다. 그렇다면 친구가 다니는 회사명을 붙여

‘○○사의 홍길동 씨’는 어떨까? 상당히 압축이 되겠지만, 대기업이라면 그래도 몇 명은 손을 들지 모른다. 그

러나 여기에 ‘○○사 영업부 1과의 홍길동 씨’라고 부서명까지 붙이면 어지간해서는 대상을 특정할 수 있다.

즉 고유한 이름이 되는 것이다(그림 2-9).

‘길동 씨’ ‘홍길동 씨’

□□사

‘□□사의 홍길동 씨’◯◯사 영업부 1과의 홍길동 씨‘

◯◯사

▲그림 2-9 유니크한 홍길동 씨

이와 같은 생각으로 인터넷상의 콘텐츠를 고유하게 지정하기 위한 구조가 ‘URL(Uniform Resource

Locator)’인 것이다. 여러분이 웹 브라우저로 사이트를 열람할 때 주소창에 입력하는 문자열이 바로 URL이

다. URL은 번역하면 통일 자원 위치자가 된다. 조금 쉽게 말하면 리소스(자원) 12 의 위치를 지정하는 통일된

기술 방법이라고나 할까?

12 　 여기서 말하는 리소스는 인터넷상에서 송수신되는 HTML 등의 정보를 가리킨다. 21페이지의 각주 10에서 설명한 콘텐츠와 거의 같은

의미다.

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

24

URL이 어떻게 인터넷상의 리소스를 특정하는지 확인해 보자. 그림 2-10을 보기 바란다.

http : / /www.wik ibook.co.kr /webtext / index.html스킴 호스트명 경로명

▲그림 2-10 URL의 구성

이와 같은 형식 자체는 여러분에게도 친숙할 것이다. URL은 크게 세 부분으로 나눌 수 있다.

a) 스킴(Scheme)

스킴은 리소스를 취득하기 위한 방법을 나타낸다. 웹 애플리케이션에서는 대부분의 경우 http(HTTP 프로

토콜 13 을 사용해 가져오는 것)가 된다. 스킴은 RFC1738이라는 문서에 규정돼 있는데, http 외에도 다음과

같은 것이 자주 이용된다.

스킴명 설명

https 암호화된 http 통신을 나타내는 스킴

mailto 이메일의 수취인을 나타내는 스킴

ftp FTP 프로토콜*을 통한 파일 획득을 나타내는 스킴

file 파일 시스템 속의 파일이나 디렉터리를 참조하기 위한 스킴

* ‘에프티피’라고 읽는다. 파일 전송을 하기 위한 프로토콜이다.

◆표 2-1 자주 이용되는 스킴

b) 호스트명

리소스가 존재하는 호스트(컴퓨터)의 이름을 나타낸다.

인터넷을 비롯한 컴퓨터 네트워크의 세계에서 네트워크에 접속되어 다른 컴퓨터로부터 요구를 받고 처리

한 결과를 되돌려주는 컴퓨터를 일반적으로 호스트 컴퓨터라고 한다. 14 여기서 말하는 호스트명은 호스트

컴퓨터의 이름을 가리킨다.

호스트명은 다시 그림 2-11처럼 로컬명과 부모 도메인명으로 나뉜다. 부모 도메인은 해당 호스트가 존재

하는 조직을 나타내며, 로컬명은 그 조직 안의 컴퓨터에 붙은 이름을 나타낸다.

13 　 HTTP 프로토콜에 관해서는 3장에서 자세히 설명한다.

14 　 호스트 컴퓨터의 정의는 여기서 적은 대로지만, 최근에는 단순히 네트워크에 접속된 컴퓨터 정도의 의미로 호스트라고 부를 때가 많다.

25

2

로컬명 부모 도메인명

www.wikibook.co.kr

▲그림 2-11 호스트명의 구성

즉, www.wikibook.co.kr이라는 호스트명은 다음과 같은 의미다.

co.kr(Korea) → 한국의

wikibook → wikibook이라는 조직의 www → www 서버라는 컴퓨터

로컬명은 해당 조직에서 자유롭게 결정할 수 있지만 부모 도메인 부분은 멋대로 결정하면 인터넷상의 고

유함이 상실되므로 지정된 단체가 관리한다.

2010년 현재 한국에서는 ‘한국 인터넷 진흥원의 KRNIC(Korea Network Information Center)라는 곳

에서 관리하고 있다.

c) 경로명

호스트명에서 지정된 컴퓨터상의 리소스의 위치를 나타낸다. 그림 2-10(24페이지)의 예에서는 webtext라

는 디렉터리 15 에 있는 index.html이라는 파일을 나타낸다.

이처럼 URL을 이용하면 도메인 → 컴퓨터 → 디렉터리 → 파일명과 같이 계층적으로 리소스의 위치를 지

정할 수 있어 인터넷상에서 일의적으로 리소스의 위치를 나타낼 수 있다.

zz HTTP

URL을 이용함으로써 인터넷상에 공개된 다양한 콘텐츠를 나타낼 수 있게 됐다. 그러나 WWW의 구현에

는 또 다른 장애물이 있었다. 바로 하이퍼텍스트를 비롯한 콘텐츠를 컴퓨터와 컴퓨터가 어떻게 송수신하면

되느냐는 문제다.

인터넷에는 다양한 종류의 컴퓨터가 연결돼 있다. 웹 서버와 웹 클라이언트가 통신하려면 어떻게 정보를

주고받느냐는 약속이 필요하다. 이 약속을 통신 프로토콜(communication protocol)이라고 한다.

그러면 간단한 비유를 들어 통신 프로토콜의 역할을 설명하겠다. 먼 옛날, 지금의 무선이나 휴대전화 같

은 편리한 통신 수단이 없던 우리 인류는 멀리 떨어져 있는 사람에게 정보를 보내기가 정말 어려웠다. 그래

15 　 ‘폴더’라고도 한다. 컴퓨터에서 다루는 파일(정보)을 한꺼번에 보관해 놓는 상자 같은 것이라고 생각하면 된다.

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

26

서 처음에 생각한 것이 봉화라는 수단이다. 모닥불에서 나오는 연기의 유무로 적의 침략을 알리는 것이다.

봉화라면 연기가 보이는 범위에는 재빨리 신호를 보낼 수 있으며, 봉화를 이어받음으로써 더 먼 곳까지 소식

을 전할 수도 있다(그림 2-12).

▲그림 2-12 가장 원시적인 통신 프로토콜인 봉화

그러면 봉화를 사용해 멀리 떨어진 사람에게 정보를 보내려면 어떤 약속이 필요할지 생각해 보자. 이를

위해서는 다음과 같은 세 가지 약속이 필요하다.

y 봉화(연기)를 사용해 신호를 전할 것

y ‘연기’는 적의 습격을 나타낼 것

y 봉화의 연기를 보면 자신도 봉화를 올려 주위에 전달할 것

이와 같은 약속을 하지 않았다면 어떻게 될까? 첫 번째 약속을 하지 않았다면 연기가 올라오는 것이 보여

도 그것이 어떤 신호라는 것을 알 수 없다. 또 두 번째 약속이 없으면 봉화의 연기가 무엇을 의미하는지 알

수 없다.

27

2

이처럼 상대와 어떤 정보를 주고받으려면 사전에 약속을 하는 것이 중요하다. 이와 같은 약속을 컴퓨터

사이의 통신에 이용한 것이 바로 통신 프로토콜이다. 사람과 사람 사이의 통신을 위해 봉화뿐 아니라 전서

구나 모스 부호 등 다양한 방법이 고안됐듯이 통신 프로토콜에도 여러 가지가 있다. 이 때문에 통신 프로토

콜이 다른 컴퓨터끼리는 통신할 수 없다. 모스 부호를 모르는 사람은 모스 부호를 나타내는 빛의 점멸을 봐

도 단순히 빛이 깜빡거린다고만 생각할 뿐 그 의미를 이해하지 못하는 것과 마찬가지다.

그런 이유로 웹 서버와 웹 클라이언트가 통신하기 위한 공통된 프로토콜이 필요해졌다. 당시 파일 전송

을 위한 프로토콜(FTP 16 )이나 이메일 송신을 위한 프로토콜(SMTP 17 )은 이미 있었는데, 버너스 리 박사

는 이것을 참조해 HTML 전송에 적합한 프로토콜을 새로 고안했다. 이것이 현재도 폭넓게 이용되고 있는

HTTP(Hyper Text Markup Language)다. HTTP는 다른 프로토콜에 비해 매우 단순해 간단히 구현 18 할 수 있

기 때문에 널리 이용됐다.

처음에 고안된 HTTP는 매우 단순했지만, 그 후 서서히 확장되면서 규격이 정리되어 1996년에 HTTP/1.0

이 책정됐다. 19 그리고 지금은 더욱 확장된 HTTP/1.1이 보급됐다.

16 　 File Transfer Protocol

17 　 Simple Mail Transfer Protocol

18 　 프로토콜은 어디까지나 약속이며, 그 프로토콜에 따라 실제로 통신을 하는 컴퓨터 프로그램이 필요하다. 이 프로그램을 작성하는 것,

또 작성된 프로그램을 구현이라고 한다. ‘HTTP를 구현한다’라든가 ‘HTTP의 구현’이라는 식으로 말한다.

19 　 그전에 사용됐던 HTTP는 HTTP/0.9라고 한다.

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

28

C o l u m n칼럼 인터넷에 공개된 기술 규격 RFC

지금까지 소개한 URL이나 HTTP 등 인터넷상에서 이용되는 규격이나 규약은 어디에 공개되고 있을까?

역시 인터넷상에서 공개되고 있으며, 이것을 RFC(Request for Comments)라고 한다. RFC는 원래 기

술자가 통신 프로토콜이나 규약 등의 초안을 인터넷상에 공개하던 것이다. 이에 대해 널리 의견을 구했기

때문에 ‘코멘트 모집’이라는 의미에서 RFC라고 부른 것이다.

현재 RFC는 IETF(The Internet Engineering Task Force) 1 에서 공개하는 기술 문서의 형식으로 규정돼

있다. 예를 들어 URL은 RFC1738, HTTP/1.1은 RFC2616이라는 문서에 규정, 공개돼 있는 식이다. 처

음에 말했듯이 RFC는 인터넷상에 공개돼 있으므로 누구나 열람할 수 있다. 가령 HTTP는 http://tools.

ietf.org/html/rfc2626이라는 URL[3]에 공개돼 있다(그림 2-13).

또 RFC에는 진지한 내용뿐 아니라 만우절 장난 같은 것도 있다. 예를 들어 2007년 4월 1일에 공개

된 RFC4824인 “The Transmission of IP Datagrams over the Semaphore Flag Signaling

System(SFSS)”은 우리말로 옮기면 수기 신호를 보내기 위한 규약으로, “대역폭 2 은 인터페이스 3 의 집중

력 감퇴와 결여로 시간과 함께 감소한다.”, “환경 잡음 또는 먼 거리의 방해가 없는 한 대기 상태의 링크 파

트너에게 소리침으로써 회선의 질서를 지킬 것을 요청할 수 있다.” 같은 농담인지 진담인지 알 수 없는 내

용 4 이 웃음을 부른다. 이와 같은 장난이 자유로운 인터넷 문화를 상징하는 것 같아 재미있다.

이야기가 잠깐 옆길로 샜는데, RFC는 인터넷 기술을 뒷받침하는 매우 중요한 문서군(群)이다. 이러한 규

격은 더욱 알기 쉽게 해설한 서적이나 인터넷상에 공개된 문서가 있으므로 꼭 봐야 할 필요는 없다. 그러

나 다양한 규약의 기초가 RFC로 공개된다는 점만큼은 기억해 두면 좋을 것이다.

▲그림 2-13 RFC2616(HTTP/1.1)의 일부

1 　 인터넷 기술 태스크포스. 인터넷상에서 이용되는 기술을 작성하기 위한 단체.

2 　 통신 속도를 뜻한다.

3 　 수기 신호를 보내는 사람을 뜻한다.

4 　 http://tools.ietf.org/html/rfc4824에 공개된 내용에서 인용

29

2

2.3 CGI의 탄생

지금까지 WWW의 탄생과 발전에 관해 설명했다. 지금까지 설명한 웹과 웹을 위한 기술은 ‘작성한 문서(콘

텐츠)를 전 세계에 공개해 공유한다’라는 것이 목적이었다. 1장에서 소개한 웹 애플리케이션의 세계와는 큰

격차가 있다.

지금부터는 지금의 웹 애플리케이션이 등장하는 계기가 된 CGI라는 기술을 비롯해 현재의 웹 애플리케

이션으로 이어지는 흐름을 소개하고자 한다.

zz 동적인z콘텐츠에z대한z요구

앞에서 소개한 바와 같이 웹 서버는 원래 준비돼 있던 콘텐츠를 클라이언트의 요청에 응해 보내 주는 일을

했다. 그러나 인터넷이 보급되면서 연구자뿐 아니라 기업이나 일반인들도 웹을 이용하게 되자 새로운 문제

가 발생했다. 아무리 유익한 정보를 공개해도 그 내용이 매번 같으면 결국은 흥미를 잃어 열람자가 줄어든다

는 점이다. 예를 들어 기업이 웹을 통해 자사의 기업 정보를 공개하거나 광고를 실을 경우 효과를 최대화하

려면 조금이라도 더 많은 사람이 웹 콘텐츠를 열람하도록 유도해야 한다. 또 개인 역시 웹 사이트를 공개할

때는 한 명이라도 많은 사람이 자신의 사이트를 봐 줬으면 하는 욕구가 생긴다.

좀 더 많은 사람이 사이트를 보도록 유도하려면 항상 새로운 콘텐츠를 제공해야 한다. 그러나 콘텐츠의

갱신은 사람이 직접 해야 하기 때문에 매우 힘든 작업이다. 컴퓨터가 자동으로 콘텐츠를 갱신해 준다면 편

리하겠지만 ‘미리 준비된 정보를 공개한다’라는 기능밖에 없는 웹 서버에게 이것은 조금 무리한 요구다. 또한

컴퓨터에게 ‘콘텐츠를 만든다’라는 식의 창조적인 작업을 시키기란 더더욱 어려운 일이다.

콘텐츠

갱신 내용

한도 끝도 없네!

갱신

갱신

갱신

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

30

zz CGI의z탄생

그래서 생각한 것이 컴퓨터를 이용해 콘텐츠에 작은 변화를 주는 방법이다. 가령 웹 페이지에 접속자 수가

표시되면 그 페이지가 얼마나 인기 있는지 알 수 있으며, 접속한 시간에 맞춰 “좋은 아침이네요”, “점심은 드

셨나요?” 같은 식으로 인사의 내용이 변화한다면 재미있을 것이다. 또한 기업의 웹 페이지 같은 경우 취급하

는 상품의 재고 상황 등이 표시되면 고객으로서는 매우 편리하기 때문에 자주 페이지를 방문할 가능성이

높아진다. 그리고 여기에 신제품의 정보나 구인 광고를 실으면 더 많은 사람에게 많은 정보를 알릴 수 있다.

이 정도 기능이라면 기계적으로 구현할 수 있을 듯하다. 이를 구현하려면 웹 서버에 어떤 기능이 있어야

할까? 웹 서버에서 작동하는 프로그램을 만들어 그 프로그램이 사람 대신 콘텐츠를 생성하면 될 것이다. 다

행히 HTML은 매우 단순한 텍스트 형식이라 HTML을 자동으로 출력하거나 이미 존재하는 HTML를 살

짝 변경하는 식의 작업이 비교적 간단하다.

이와 같이 프로그램이 생성한 HTML 등의 콘텐츠를 동적 콘텐츠라고 한다. 또 기존과 같이 미리 준비된

콘텐츠는 정적 콘텐츠라고 한다(그림 2-14).

미리 준비된 HTML을 돌려준다

동적 콘텐츠

정적 콘텐츠

응답

웹 서버

웹 클라이언트

웹 클라이언트

요청

요청

응답

응답

웹 서버

웹 서버

웹 서버상에서 작동하는 프로그램이 HTML을 생성해 돌려준다

▲그림 2-14 동적 콘텐츠와 정적 콘텐츠

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

하다. 그래서 고안된 것이 CGI(Common Gateway Interface) 20 라는 구조다. CGI에서는 웹 서버가 클라이언트

20 　 CGI도 RFC로 공개돼 있으며, RFC3875에 규정돼 있다.

31

2

로부터 받은 요청을 웹 서버상에서 작동하는 프로그램에 보낸다. 프로그램은 요청을 참조해 HTML을 생성

한 다음 웹 서버에 돌려보낸다. 그러면 웹 서버는 프로그램으로부터 받은 HTML을 마치 미리 준비돼 있었

다는 듯이 웹 애플리케이션에 보내는 것이다(그림 2-15).

CGI

웹 클라이언트

웹 서버프로그램

요청

응답

▲그림 2-15 CGI의 구조

실제로 웹 서버상에서 작동해 콘텐츠를 생성할 목적으로 주로 이용되던 것은 펄(Perl) 21 이라는 프로그래

밍 언어였다. 또 규모가 거대하거나 빠른 속도가 요구될 때는 C 언어 22 로 작성한 프로그램이 활약했다. 이와

같이 CGI는 어디까지나 ‘웹 서버와 프로그램 사이에서 요청과 응답을 주고받기 위한 규약 23 이었으므로 응

용 범위를 넓히기 쉬웠다.

zz 웹의z폭발적인z보급

CGI를 이용하자 동적 콘텐츠를 생성할 뿐만 아니라 웹 브라우저에서 입력을 받아 그에 상응하는 처리를 하

는 애플리케이션을 제작할 수 있게 됐다. 그리고 이에 따라 사용자가 입력한 키워드로 인터넷상의 사이트를

검색하는 검색 사이트나 사람들이 자유롭게 의견을 교환할 수 있는 게시판 시스템, 그리고 웹 페이지에 게

재된 상품을 구입할 수 있는 인터넷 쇼핑 같은 편리한 기능을 제공하는 사이트를 구현할 수 있게 됐다. 이것

이 웹 애플리케이션의 시작이다.

1장에서도 소개했듯이, 지금까지 이용되던 애플리케이션과 달리 CGI로 구현된 웹 애플리케이션은 웹 브

라우저에서 URL을 입력하기만 하면 누구나 이용할 수 있다. 그래서 많은 사람이 이용하게 됐고, 각 기업이

21 　 펄은 원래 텍스트의 치환과 변형 등의 처리에 강점이 있는 언어다. C 언어보다 쉽게 이용할 수 있으며 HTML 같은 텍스트의 처리가 비교적

간단해 CGI의 백엔드 프로그램으로 폭넓게 이용됐다.

22 　 1972년에 개발되어 현재도 다양한 분야에서 이용되고 있는 범용 프로그래밍 언어다.

23 　 펄이 너무나도 많이 이용됐기 때문에 ‘CGI=펄’이라는 오해를 낳기도 했다. CGI는 프로그래밍 언어가 아니라 어디까지나 인터페이스다.

오해하지 말자.

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

32

웹을 통해 각종 서비스를 제공하거나 광고를 싣게 됐다. 웹은 이제 일부 연구자의 전유물이 아니라 전 세계

사람들이 이용하는 거대한 미디어로 자리매김했다. 이와 같은 발전을 음지에서 뒷받침한 기술이 바로 CGI

였던 것이다.

2.4 서블릿의 등장

zz CGI를z둘러싼z문제점

CGI를 이용한 웹 애플리케이션이 보급됨에 따라 다시 새로운 문제가 발생했다.

첫째는 개발 언어의 문제이며, 둘째는 성능 문제다.

먼저 개발 언어와 관련된 문제부터 살펴보자. 웹 애플리케이션에 요구되는 기능의 규모가 커지고 복잡해

지면서 당시 주로 이용되던 펄로 프로그램을 제작하기가 어려워졌다. 펄은 텍스트 처리에 강점이 있는 언어

였기에 대규모 애플리케이션을 개발하는 데는 그다지 적합하지 않았다. 또 규모가 크고 복잡한 애플리케이

션을 개발하는 데 필수라고도 할 수 있는 객체지향 프로그래밍도 지원하지 않았다 24 .

다음에는 성능 문제를 살펴보자. 기존에는 웹 브라우저에서 요청이 도착할 때마다 CGI를 통해 프로세스 25

를 기동했다. 여기에는 조금 시간(수십 밀리초에서 수백 밀리초 단위이지만)이 걸리는데, 접속 수가 적을 때

는 전혀 문제가 없지만 하루 접속 수가 수만, 수십만에 이르는 사이트에서는 프로그램의 기동 처리가 많아

져 요청을 따라잡지 못한다. 그 결과 사용자가 볼 때는 웹 페이지에 접속했는데도 화면이 표시되지 않아 불

만이 쏟아지는 사태가 초래됐다.

zz 자바/서블릿의z탄생

웹 애플리케이션 개발이 이런 문제로 고민하고 있을 때 등장한 것이 썬 마이크로시스템즈의 제임스 고슬링

(James Gosling)이 개발한 자바(Java)였다. 자바는 객체지향 기능을 완벽히 지원해 대규모 시스템을 개발하기

용이하며, 당시 널리 사용되던 C 언어와 문법이 매우 비슷했기 때문에 당시의 개발자들이 쉽게 받아들일 수

24 　 현재 공개된 최신 버전인 Perl5는 객체지향도 지원한다.

25 　 컴퓨터상에서 작동하는 프로그램의 단위를 프로세스(Process)라고 한다. CGI의 경우, 웹 서버와 콘텐츠를 생성하는 프로그램은 다른

프로세스가 된다.

33

2

있었다는 장점도 있었다. 또 멀티 스레드 26 와 보안, 네트워크 통신 등 당시 중요성이 높아지던 기술을 표준화

된 방식으로 지원했다는 점도 매력적이었다.

자바 자체는 웹 애플리케이션을 위해 개발된 언어가 아니다. 그러나 웹 애플리케이션은 당시 기업의 시스

템 개발에서도 주류가 되고 있었다. 그래서 JaveEE 27 (Java Enterprise Edition, 기업 시스템용 자바)의 일부

로서 서블릿(Servlet)이라는 웹 애플리케이션 개발을 지원하기 위한 기능을 제공했다.

서블릿은 자바로 만들어진, HTML 등의 웹 콘텐츠를 생성하기 위한 프로그램으로, CGI를 경유해 기동

하는 펄이나 C 언어의 자바 버전에 해당한다. 서블릿은 기본적으로 CGI와 같은 개념이지만 콘텐츠를 생성

하는 언어가 자바이며 객체지향을 지원함으로써 대규모 애플리케이션 개발에 적합하다는 점, 웹 서버와 같

은 프로세스 속에서 콘텐츠를 생성하는 프로그램이 작동하기 때문에 CGI처럼 새로운 프로세스를 매번 기

동할 필요가 없어 28 비교적 고속으로 작동한다는 이점이 있다(그림 2-16).

웹 컨테이너의 내부에서서블릿을 실행

CGI를 사용한 웹 애플리케이션 서블릿을 사용한 웹 애플리케이션

웹 서버 펄

프로그램

C 언어프로그램

요청을 받을 때마다프로그램을 실행

웹컨테이너

서블릿

서블릿

서블릿

▲그림 2-16 서블릿을 사용한 웹 애플리케이션

이러한 이점은 앞에서 열거한 CGI의 문제점을 그대로 보완하기 때문에 서블릿은 자바와 함께 점점 보급

되었다.

26 　 여러 개의 처리를 동시에 실행하기 위한 구조. 실제로는 동시에 실행하는 것이 아니라 짧은 시간에 여러 개의 처리를 조금씩 전환하며

실행함으로써 동시에 실행되는 것처럼 가장한다.

27 　 당시는 JavaEE가 아니라 J2EE(Java 2 Enterprise Edition)라고 불렀다.

28 　 CGI의 이러한 결점은 나중에 웹 서버가 직접 펄 프로그램을 실행할 수 있게 개선됐다. 아파치의 모듈로 공개된 mod-perl이 유명하다.

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

34

zz 자바로z애플리케이션을z개발할z때의z이점

또 자바에는 특정 운영체제나 하드웨어에 의존하지 않고 작동한다는 특징이 있다. 자바는 C 언어처럼 소스

코드를 직접 컴퓨터의 기계어로 컴파일 29 하지 않고 JavaVM 30 이라고 하는 가상 컴퓨터에서 동작하는 언어

로 컴파일해 실행한다. 그래서 JavaVM이 작동하는 컴퓨터라면 어디에서나 프로그램을 실행할 수 있다.

예를 들어 데스크톱 애플리케이션은 윈도우용, 맥 OS용, 리눅스용 등으로 나뉘어 있어 다른 플랫폼 31 에

서는 실행되지 않는다(그림 2-17).

윈도우 맥 OS 리눅스

윈도우용 애플리케이션 맥 OS용 애플리케이션 리눅스용 애플리케이션

플랫폼별로 애플리케이션을 개발해야 한다

▲그림 2-17 운영체제별로 애플리케이션을 개발해야 한다

그러나 자바는 윈도우나 맥 OS, 리눅스 같은 서로 다른 플랫폼에서 같은 프로그램을 실행할 수 있다. 또

최근 유행하고 있는 모바일 게임 등도 휴대전화용 JavaVM상에서 실행되는 것이 많다. 자바로 기술된 서블

릿도 마찬가지로 다양한 플랫폼상에서 작동하기 때문에 개발하기가 쉽다.

개발이 편해지는 이유는 웹 서버에 이용되는 운영체제가 경우에 따라 다르기 때문이다. 윈도우 머신이 이

용될 때도 있고, 최근에는 저렴하게 구축할 수 있는 리눅스 머신이 이용되는 일도 늘어났다. 기존에는 애플

리케이션을 개발하려면 그 애플리케이션이 가동되는 플랫폼과 동일한 플랫폼에서 개발하는 것이 원칙이었

다. 그러나 자바는 다른 플랫폼에서도 작동하기 때문에 개발할 때는 사용하기 편한 윈도우 머신을 사용하

고 리눅스 머신에서는 작동 확인을 위한 테스트만 하는 식의 방법이 가능하다(그림 2-18).

29 　 프로그램을 번역하는 것. 통상적인 프로그램은 사람이 읽을 수 있게 작성되기 때문에 컴퓨터가 직접 이해할 수 없다. 그래서 프로그램을

실행하려면 컴퓨터가 이해할 수 있는 명령(기계어)으로 변환하는 작업이 필요하다. 이를 컴파일이라고 한다. C 언어의 경우는 소스코드를

사전에 전부 번역하기 때문에 빠르게 작동한다. 한편 펄은 소스코드를 그때그때 기계어로 변환하면서 실행한다. 이 때문에 컴파일을 하는

수고가 필요 없어 부담 없이 이용할 수 있다는 이점이 있지만 C 언어에 비해 작동이 느려진다. 펄과 같은 언어를 인터프리터형 언어라고 부

르며, C 언어와 같이 사전에 컴파일이 필요한 언어를 컴파일러형 언어라고 한다. 자바는 그 중간에 위치한다.

30 　 자바 가상 머신(Java Virtual Machine)의 약자.

31 　 플랫폼(Platform)은 ‘토대’나 ‘기반’이라는 의미인데, 컴퓨터 세계에서는 소프트웨어를 실행시키는 컴퓨터의 하드웨어와 운영체제(윈도우나

맥 OS, 리눅스 등)의 조합을 가리켜 플랫폼이라고 한다.

35

2

이렇게 해서 자바/서블릿 32 은 대규모 웹 애플리케이션의 개발에 크게 공헌했다.

같은 애플리케이션을 여러 플랫폼에서 실행할 수 있다!

윈도우 맥 OS 리눅스

자바 애플리케이션

윈도우용 JavaVM 맥 OS용 JavaVM 리눅스용 JavaVM

▲그림 2-18 다양한 플랫폼에서 작동하는 자바 애플리케이션

다만 서블릿은 그것을 동작시키는 웹 컨테이너 33 를 설치하기가 웹 서버만 설치하는 경우에 비해 조금 어

렵고, 자바로 프로그램을 만들려면 객체지향에 관한 지식이 필요하다는 점에서 개인은 이용하길 꺼리는 경

향이 있다. 이 때문에 기업 등 대규모이며 안정적인 가동이 필요한 시스템에서는 자바/서블릿이 이용되고,

개인 웹 사이트에서 게시판 등의 간단한 시스템을 설치하고 싶을 때는 CGI/펄을 사용한 프로그램을 작동시

키는 34 식으로 용도가 갈리게 되었다.

32 　 같은 기술로 마이크로소프트의 ASP(Active Server Pages)가 있었다. 현재는 마이크로소프트의 애플리케이션 개발 · 실행 환경인 마이크로

소프트 닷넷 프레임워크(Microsoft .NET Framework)상에서 이용할 수 있게 된 ASP. NET으로 교체되고 있다.

33 　 웹 컨테이너에 관해서는 5장에서 자세히 설명하겠다.

34 　 현재는 펄과 함께 객체지향을 이용할 수 있으며 라이브러리(애플리케이션 소프트웨어를 개발할 때 이용하는 각종 기능을 제공하는

프로그램 부품)가 충실한 PHP(PHP: Hypertext Preprocessor)를 주로 사용한다.

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

36

C o l u m n칼럼 시대를 너무 앞서갔던 기술, 자바 애플릿

사실 자바가 등장했을 때 서블릿보다 주목받았던 기술이 있다. 바로 자

바 애플릿(Java Applet)이라고 하는 기술로, 웹 브라우저의 화면 속에

서 자바 프로그램을 실행할 수 있게 한 것이다. 서블릿과는 달리 자바 애

플릿에서는 자바 프로그램이 웹 서버에서 자동으로 다운로드되어 클라

이언트에서 작동한다. 그림 2-19는 썬 마이크로시스템즈의 사이트 1 에

공개돼 있는 자바 애플릿의 데모 화면이다.

자바 애플릿을 이용하면 HTML로는 표현할 수 없는 그래픽적인 애플리

케이션을 구현할 수 있다. 게다가 사용자는 지금까지와 마찬가지로 웹

브라우저에 URL을 입력해 웹 페이지를 열기만 하면 되기 때문에 자바

등장 초기에는 커다란 주목을 받았다.

그러나 당시의 자바 애플릿은 다음과 같은 문제점도 안고 있었다.

ㆍ당시의 네트워크 환경에서는 자바 애플릿을 다운로드하는 데 시간이 오래 걸렸다

ㆍ자바가 등장하는 초기였기 때문에 웹 브라우저상에서 그다지 빠른 속도로 작동하지 못했다

이러한 문제 탓에 많은 웹 사이트 제작자로부터 외면을 당하고 말았던 것이다. 자바 애플릿은 시대를 앞선

콘셉트였음에도 실용적이지 못하다는 이유로 널리 보급되지 못했다.

현재는 이러한 문제점이 거의 해결됐지만 나중에 등장한 어도비 플래시(Adobe Flash)에 그 자리를 빼앗

기고 말았다. 자바 애플릿과 어도비 플래시 모두 기본적인 콘셉트는 같았지만 먼저 등장한 자바 애플릿이

보급되지 못했다니 아이러니한 일이다.

이 절에서 이야기한 서블릿은 자바 애플릿의 실패 이후 서버 측에서 자바를 이용하기 위해 개발된 기술이

었다.

1 　 http://java.sun.com/applets/jdk/1.4/demo/applets/GraphicsTest/example1.html

▲그림 2-19 자바 애플릿의 화면

2.5 JSP의 탄생

zz 서블릿의z문제점

대규모 개발에 적합한 자바에서 동적 콘텐츠 제공을 가능하게 만든 서블릿도 이용이 확산되자 개발자들

사이에서 어떤 점이 문제로 떠올랐다. 어떤 문제인지 구체적인 서블릿 프로그램을 예를 들어 설명하겠다. 예

제 2-1은 브라우저에 1,000원의 부가가치세 포함 가격을 표시하는 간단한 서블릿 프로그램이다.

37

2

import java.io.*;

import javax.servlet.*;

import javax.servlet.http.*;

public class Calc extends HttpServlet {

public void doGet(HttpServletRequest request, HttpServletResponse response)

throws ServletException, IOException {

// 콘텐츠 유형 설정

response.setContentType("text/html;charset=UTF-8");

// HTML 출력 준비

PrintWriter out = response.getWriter();

// HTML 출력

out.println("<html><head>");

out.println("<title>Calcurator</title>");

out.println("</head><body>");

out.println("<p>1000원의 부가가치세 포함 가격 = " + (1000 * 1.1) + "원</p>");

out.println("</body></html>");

// HTML 출력 완료 처리

out.flush();

out.close();

}

}

예제 2-1 부가가치세 포함 가격을 HTML에 출력하는 서블릿

언뜻 어려워 보일지도 모르지만 여기서는 자세한 내용보다는 대략 어떤 느낌이 드는지를 느끼는 정도만으

로 무방하다.

이 프로그램이 출력하는 HTML은 예제 2-2와 같다.

<html><head>

<title>Calculator</title>

</head><body>

<p>1000원의 부가가치세 포함 가격 = 1100원</p>

</body></html>

■예제 2-2 서블릿이 출력한 HTML

자바를 모르는 사람도 어렴풋이 이해될 것으로 생각하는데, 예제 2-1에서 진하게 칠한 부분이 이 서블릿

의 핵심이다.

❶

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

38

out.println이라는 명령에 이어 괄호 안에 HTML로 출력할 문자열을 지정했다. 그리고 ❶에서는

1000*1.1이라는 계산 결과를 HTML에 채운다. 이런 HTML의 출력 방법은 펄을 이용한 CGI도 마찬가지다.

이 HTML을 웹 브라우저에서 출력하면 그림 2-20처럼 된다.

▲그림 2-20 출력된 HTML의 표시 결과

자, 여기서 1100원이라는 부분을 강조 표시하고 싶다고 해보자. HTML에서는 강조하고 싶은 부분을

‘<b></b>’라는 태그로 감싸면 되므로 예제 2-2의 일부를 고쳐 쓰면 될 것 같다. 예제 2-3의 밑줄을 그은 부

분이 추가한 태그다. 보다시피 아주 간단하다.

out.println("<p>1000원의 부가가치세 포함 가격 = <b>" + (1000 * 1.1) +"원</b></p>");

■예제 2-3 계산 결과를 강조 표시하려 한 서블릿

이처럼 간단한 예에서는 별문제가 없다. 그러나 좀 더 복잡하게 디자인된 HTML 페이지를 출력해야 한다

면 어떻게 될까? 상용 사이트처럼 화려한 웹 페이지를 만들려면 고도의 HTML 지식과 디자인 감각이 필요

하다. 이런 작업은 웹 디자인이라고 부를 정도이며, 프로그래밍 지식과는 전혀 다른 기술이 필요해진다.

대규모 사이트에서는 프로그래밍하는 사람과 화면의 디자인을 담당하는(HTML을 작성하는) 사람이 분

담해 작업하는 일이 많다. 그렇게 할 경우 이와 같이 화면의 디자인을 변경할 때마다 프로그램을 변경해야

한다면 작업 효율이 나빠진다(그림 2-21). 또 프로그래밍 지식이 없는 웹 디자이너는 실수로 프로그램을 망

가트릴 우려가 있다는 위험성도 있다.

프로그램을 고치고 싶은데…… 프로그래머

작업하기어렵다!

서블릿

웹 디자이너

디자인을 고치고 싶은데……

▲그림 2-21 서블릿은 수정하기가 어렵다

39

2

또 다른 문제도 있다. 서블릿을 통해 출력되는 HTML을 상상하기 어렵다는 점이다. 서블릿은 예제 2-1(37

페이지)처럼 자바의 출력 명령을 사용해 HTML의 문자열을 출력하는 방식이었다. 그래서 프로그램이 길어

지거나 출력할 HTML이 복잡해지면 HTML을 변경하려고 해도 수정해야 할 부분을 찾기조차 쉽지 않다.

zz 발상의z전환!zJSP의z탄생

이런 상황을 조금이라도 개선하기 위해 고안된 것이 JSP(Java Server Pages)라는 기술이다. JSP와 서블릿의 차

이를 이해하고자 먼저 JSP를 사용해 앞의 서블릿(예제 2-1)을 바꿔 보자.

<html>

<head>

<title>Calcurator</title>

</head>

<body>

<p>1000원의 부가가치세 포함 가격 = <% out.println(1000 * 1.1); %>원</p>

</body>

</html>

■예제 2-4 부가가치세 포함 가격을 HTML에 출력하는 JSP

어떤가? 서블릿을 사용할 때와는 달리 출력되는 HTML에 거의 근접한 형태이므로 알기 쉽고, 어떤

HTML이 출력될지 쉽게 이해할 수 있다.

JSP에서는 동적으로 출력하고 싶은 부분을 <%, %>로 묶고 그 안에 자바 프로그램을 기술할 수 있다. 이

와 같이 JSP 내부에 적힌 자바 프로그램을 스크립틀릿(Scriptlet) 35 이라고 한다. 예제 2-4에서는 진하게 칠한

부분이 스크립틀릿이다. 여기서 1000×1.1의 계산 결과를 표시한다는 사실을 한눈에 알 수 있다.

동적 콘텐츠라고 해도 페이지 전체를 매번 변경하는 일은 매우 드물며, 페이지의 일부분만 변경될 때가

많다. 그러므로 페이지를 구성하는 HTML을 기본으로 삼고 변경되는 부분만 자바로 작성하는 편이 효율적

이다. 이렇게 한 덕분에 개발자들은 자바 코드가 나오는 부분에 집중하고 웹 디자이너는 HTML 부분에 집

중하는 식으로 애플리케이션 개발을 분업할 수 있게 됐다.

35 　 이미 눈치챘을지도 모르지만 자바에서는 다양한 프로그램을 ‘~릿’이라는 식으로 부른다. 원래 ‘~let’은 영어로 ‘작은~’이라는 의미를 나타

내는 말이므로 ‘애플릿’은 ‘작은 애플리케이션’, 서블릿은 ‘서버상에서 작동하는 작은 프로그램’, ‘스크립틀릿’은 ‘작은 스크립트’라는 의미다.

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

40

서블릿은 자바 코드 속에 HTML을 넣고, JSP는 HTML 속에 자바 코드를 넣는다. 36 37 말 그대로 발상의

전환인 것이다.

2.6 웹 애플리케이션 프레임워크의 시대

zz 서블릿과zJSP의z문제점

지금까지 소개한 웹 애플리케이션 개발 기술 덕분에 간단한 웹 애플리케이션을 만들기가 매우 편해졌다. 그

러나 실제 개발 현장에서는 아직 웹 애플리케이션을 개발하는 데 어려움이 있었다. 웹 애플리케이션의 규모

가 엄청나게 커졌기 때문이다.

예를 들어 아마존으로 대표되는 쇼핑 사이트나 경매 사이트 등 실시간으로 물건을 살 수 있는 서비스, 은

행 계좌의 이체나 예금 확인을 할 수 있는 서비스, 증권 거래 시스템 같은 시스템은 많은 사람이 이용하고 있

으며, 만에 하나 시스템이 다운돼 버리면 기업의 신용이 떨어지고 경제적 손실을 보는 등 막대한 피해를 입

는다. 이처럼 우리의 생활 기반을 뒷받침하는 매우 중요한 역할을 담당하는 시스템이 속속 웹 애플리케이션

으로 개발되고 있다. 이런 대규모 애플리케이션을 처음부터 서블릿이나 JSP로 만들면 코딩 분량이 엄청나

며, 완성되기까지 막대한 시간과 돈이 든다.

또 시스템의 규모가 커지면서 개발에 관여하는 사람의 수도 점점 늘어났다. 그런 상황에서는 개발자가 독

자적인 라이브러리나 클래스를 만들고 나중에 결합하려고 했을 때 결합이 잘 되지 않거나 디자인팀과 개발

팀의 성과물을 연결하는 과정에서 불협화음이 일어나는 식의 문제가 나타난다.

소프트웨어 개발을 흔히 건축에 비유한다. 개집 정도라면 혼자서 못과 망치만 가지고도 문제없이 지을 수

있다. 그러나 고층 빌딩을 지을 때는 많은 사람의 팀워크와 튼튼한 지반, 우수한 중장비가 있어야 한다. 고층

빌딩을 지으려면 서블릿이나 JSP만으로는 아직 부족한 것이다.

36 　 이와 같은 발상은 마이크로소프트의 ASP나 나중에 등장한 PHP에서도 구현됐다. 이 책에서는 자바를 중심으로 소개했지만 공통적인

문제점을 배경으로 다양한 기술이 등장한 것이다.

37 　 사실 JSP는 그것을 실행하는 웹 컨테이너의 내부에서 서블릿으로 자동 변환된 다음 실행된다.

41

2

zz 웹z애플리케이션z프레임워크의z탄생

그렇다면 고층 빌딩 같은 대규모 애플리케이션을 효율적으로 개발하려면 어떻게 해야 할까?

이때는 재사용이라는 발상이 효과적이다. 소프트웨어는 자동차나 가전제품 등의 공업 제품과 달리 일단

만든 프로그램을 얼마든지 복사해 이용할 수 있다. 이 발상은 오래전부터 이용돼 왔다. 자주 이용되는 코드

는 라이브러리라고 하는 프로그램 부품으로 정비해 38 몇 번이고 똑같은 프로그램을 만들지 않아도 되게 한

것도 그중 하나다.

이와 같은 개념을 더욱 발전시켜, 재사용할 수 있는 부분을 늘려 애플리케이션 개발을 용이하게 하는 토

대로 만들어진 것이 프레임워크다. 프레임워크는 애플리케이션의 기반이 되는 것으로, 프레임워크를 토대로

필요한 부분을 만들어 나가면 원하는 애플리케이션을 단기간에 개발할 수 있다. 39

추가

완성!

프레임워크 프레임워크

그리고 현재 웹 애플리케이션 개발의 세계에서 필수적이라고 해도 좋을 만큼 널리 사용되고 있는 것이 웹

애플리케이션의 손쉬운 개발을 위한 ‘웹 애플리케이션 프레임워크’라고 하는 프레임워크다. 웹 애플리케이

션 프레임워크는 이 책의 커다란 주제 중 하나이므로 6장에서 자세히 설명하겠다. 여기서는 그러한 이름과

대략적인 이미지를 머릿속에 기억해 두기 바란다.

38 　 이 책의 예제 프로그램에서 이용한 PHP나 자바는 프로그래밍 언어의 표준 라이브러리가 충실하다. 예를 들어 문자열의 조작이나

데이터의 조작 등은 이러한 라이브러리를 이용해 손쉽게 할 수 있다.

39 　 이 책에서는 웹 애플리케이션을 위한 프레임워크로서 6장에서 스트러츠(Struts)를 소개하겠다.

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

42

2.7 정리

이 장에서는 WWW가 등장한 이래 현재에 이르기까지 약 30년의 역사를 간단히 소개했다. 그 역사는 0장

에서 이야기했듯이 문제의 발생과 해결의 반복이다. 연구자 사이에 정보를 고유하고 싶다는 수요에서 웹이

탄생했고, 우리가 오늘날 웹을 중심으로 한 애플리케이션을 편리하게 사용할 수 있게 되는 과정에서 CGI와

서블릿, JSP 등의 기술이 발전해 왔다. 불과 십수 년 사이에 기술이 놀라울 만큼 발전했음을 알 수 있을 것이

다. 이 기술의 발전은 아직도 계속되고 있는 현재 진행형이다.

그리고 현재 요구되고 있는 웹 애플리케이션은 탄생 당시에는 누구도 상상하지 못했을 만큼 규모가 커지

고 복잡해졌다. 지금 현장의 기술자들이 안고 있는 과제는 대규모 웹 애플리케이션이라는 초고층 건물을 어

떻게 하면 빠르고 품질 좋게 개발할 수 있느냐다.

yy WWWy등장의y배경

yy 웹에서y클라이언트와y서버의y역할y분담

yy URL의y역할과y구조

yy HTTP의y역할

yy CGIy등장의y배경과y역할

yy 서블릿y등장의y배경

yy JSPy등장의y배경

yy 웹y애플리케이션y프레임워크의y필요성

이 장에서

배운 내용

43

3L e s s o n

HTTP를 이해하자

44

HTTP를 이해하자3LESSON

1장에서 설명했듯이 웹 애플리케이션은 사용자 인터페이스에 HTML을 사용한 것이 커다란 특징이며,

HTML을 송수신할 때는 웹 사이트를 열람할 때와 마찬가지로 HTTP가 사용된다. 이 장에서는 웹 애플리

케이션의 근간을 이루는 HTTP에 관해 자세히 설명하겠다.

3.1 왜 HTTP를 알아야 하는가?

앞장의 끝에서 소개했듯이, 현재는 웹 애플리케이션 개발할 때 프레임워크를 이용하는 경우가 대부분이다.

그래서 웹 애플리케이션 프레임워크를 이용하면 HTTP 통신에 관해 그다지 자세히 몰라도 어느 정도 웹 애

플리케이션을 만들 수 있다. 1 그러나 이래서는 개발한 애플리케이션이 의도대로 작동하지 않을 때 무엇이

원인인지 전혀 알 수 없을 것이다.

예를 들어 여러분이 자동차를 운전하고 있다가 운 나쁘게 자동차가 고장을 일으켜 정지해 버렸다고 생각

해 보자. 이럴 때 자동차의 구조를 잘 모르는 사람은 어디가 문제인지 알 수 없어 난감할 것이다. 그래서 수

리 공장으로 가져가 자동차 정비사에게 보일 것이다. 정비사는 자동차가 어떤 구조로 움직이는지 알고 있기

때문이다. 그 구조를 추적해 나가면 어디가 망가졌는지 밝혀내 고칠 수 있다. 이와 같이 전문가라면 문제나

고장을 해결할 수 있게 구조를 확실히 이해하고 있어야 한다.

점검!

원인을

밝혀낸다

1 　 이것은 어떤 의미에서 프레임워크의 동전의 앞뒷면과도 같은데, 이 부분에 관해서는 6장에서 자세히 이야기하겠다.

45

3

그리고 이것은 컴퓨터상의 소프트웨어도 마찬가지다. 소프트웨어는 기계와 마찬가지로 사람이 만든 논리

위에서 작동한다. 그러므로 올바르게 작동하지 않는다면 반드시 어딘가에 원인이 있다. 다만 소프트웨어의

경우 그림 3-1과 같이 축적된 수많은 기술 위에서 형성되므로 그 기술을 전부 이해하기란 매우 어렵다. 극단

적으로 말하면 컴퓨터를 구성하는 IC와 트랜지스터, 나아가 그 근본이 되는 반도체 내 전자의 움직임까지

알아야 한다. 그러나 너무 걱정할 필요는 없다. 현재 사용되는 컴퓨터나 운영체제, JavaVM 같은 하드웨어와

미들웨어는 거의 안정적으로 작동한다고 믿어도 무방한 수준의 품질을 갖추고 있다. 2 그러므로 대체로 그

구조까지 이해할 필요는 없다. 또 소프트웨어는 기계와 달라서 올바르게 작동하던 것이 오래 사용했다고 해

서 망가지는 일도 없다.

웹 브라우저

운영체제

컴퓨터

CPU/메모리 등…

IC/LSI

트랜지스터

웹 서버 HTTP 통신 웹 클라이언트

애플리케이션

웹 애플리케이션프레임워크

애플리케이션 서버

JavaVM

OS

컴퓨터

CPU/메모리 등……

IC/LSI

트랜지스터

HTTP

TCP

IP

이더넷

▲그림 3-1 웹 애플리케이션을 구성하는 기술

다만 우리가 만드는 애플리케이션에 가까운 부분에 관여하는 기술에 관해서는 알아 둬야 문제에 대처할

수 있다. 그리고 HTTP는 웹 서버와 웹 클라이언트 사이에 일어나는 통신의 근간이자 웹 애플리케이션 개

발이 어려운 커다란 요인 중 하나다.

그렇다면 왜 HTTP가 웹 애플리케이션의 개발을 어렵게 만드는 것일까? 이 장에서는 HTML을 이해함으

로써 웹 애플리케이션의 본질을 알아보자.

2 　 그렇다고는 해도 실제로는 JavaVM이나 운영체제의 버그가 원인이 되어 문제가 발생하는 경우도 종종 있다.

Lesson 3 HTTP 를 이해하자

46

C o l u m n칼럼 하드웨어조차도 믿을 수 없는 사태!?

우리 같은 소프트웨어 개발자들은 ‘하드웨어는 올바르게 작동하는 것이 당연하다.’라고 믿는 경향이 있다.

그러나 하드웨어도 결국은 사람이 만든 물건이므로 신뢰성이 100퍼센트라고는 할 수 없다.

내가 학생이었을 때 겪은 일인데, 동아리 활동의 일환으로 마이크로프로세서를 탑재한 컴퓨터를 자작한

적이 있었다. 그런데 ‘메모리에 입력한 값을 올바르게 읽어들이지 못하는’ 일이나 ‘제대로 통신이 되지 않

는’ 등의 문제가 일상다반사로 일어났다. 그래서 조사해 보니, 메모리의 배선이 잘못됐다든가 통신에 사용

한 신호의 파형이 왜곡되거나 하는 등 하드웨어에 기인한 문제가 많았다. 특히 후자는 며칠 동안 밤을 새

우며 조사했음에도 알 수가 없어서 오실로스코프 1 까지 동원한 끝에 가까스로 알아낸 기억이 난다.

현재 우리가 사용하고 있는 컴퓨터는 수많은 우수한 기술의 뒷받침을 통해 안정된 하드웨어로 구성된 것

이다.

「1」 「0」…？

▲그림 3-2 정보가 올바르게 전달되지 않는다……?

1 　 전자 회로 위를 흐르는 신호의 파형을 가시화하는 기계. 최근에는 컴퓨터에서 이용할 수 있는 저렴한 제품도 판매되고 있지만

당시는 값이 비쌌기 때문에 가난한 학생들에게는 그림의 떡이었다. 당시 대학의 연구실에서 폐기 처분된 것을 주워 와서 소중하게

사용했다.

3.2 웹 브라우저와 웹 서버의 통신을 엿보자

앞장에서 WWW의 역사를 이야기하면서 HTTP에 관해서도 간단히 소개한 바 있다(25페이지). 다시 한 번

간단하게 정리하면, 통신 프로토콜은 정보를 주고받기 위한 약속으로서 주로 정보의 전달 방법과 정보의

의미를 규정하는 것이었다. 봉화를 예로 들면 연기를 통해 정보를 전달하며, 그 연기에 적의 습격이라는 의

미를 부여했다. 그리고 모스 부호에서는 이것을 좀 더 고도화해, 빛과 소리로 정보를 전달하며 빛이나 소리

의 유무에 따른 패턴에 정보의 의미를 부여했다. 이렇게 해서 우리가 평소에 이용하는 문자를 멀리 떨어진

상대에게 빠르게 전달할 수 있게 됐다. 유명한 모스 부호로는 ‘···, ― ― ―, ···’로 표현되는 SOS 신호가

있다.

47

3

그리고 WWW의 세계에서 HTML을 주고받기 위해 규정된 프로토콜이 HTTP(Hyper Text Markup

Language)다. 여기서는 먼저 웹 브라우저와 웹 서버가 실제로 어떤 통신을 하는지 엿보자.

백문이 불여일견이라는 말을 흔히 하는데, 이야기를 듣거나 책을 읽기보다는 자신이 실제로 체험해 보는

것이 기억에도 잘 남고 빠르게 이해되기도 한다. 이번에는 여러분도 직접 HTTP 통신을 실제로 체험해 보자.

zz 피들러z설치

이번에는 무료 웹 디버깅 툴인 피들러(�ddler)를 이용해 HTTP를 관찰해보겠다. 먼저 아래 페이지에서 피들

러를 내려받을 수 있다.

http://fiddler2.com/fiddler2/

페이지 중간에 ‘Download Fiddler...’라고 적힌 링크가 있으므로 이 링크를 눌러 다운로드 페이지로 이동

해 Fiddler2Setup.exe 파일을 내려받는다. 내려받은 Fiddler2Setup.exe 파일을 더블클릭하면 그림 3-3과 같

은 화면이 나타난다. 약관에 동의한다는 의미로 ‘I Agree’ 버튼을 클릭한다. 그러면 그림 3-4와 같은 화면이

나오는데 여기서 ‘Install’ 버튼만 누르면 피들러 설치가 진행된다.

▲그림 3-3 피들러 설치(1)

Lesson 3 HTTP 를 이해하자

48

▲그림 3-4 피들러 설치(2)

피들러 설치가 끝나면 ‘Close’ 버튼을 눌러 설치를 마친다. 설치가 끝나면 시작 메뉴에 ‘Fiddle2’라는 바로

가기가 생기고, 이 바로가기를 클릭하면 그림 3-5와 같은 화면이 나타난다.

▲그림 3-5 피들러 실행 화면

49

3

zz HTTPz통신을z엿보자

그러면 즉시 HTTP 통신을 엿보는 작업을 해보자. 피들러는 컴퓨터와 인터넷 간의 모든 HTTP(HTTPS 포

함) 트래픽을 기록하는 웹 디버깅 프록시로서 동작한다.

기본적으로 피들러를 실행하면 모든 프로세스의 HTTP(S) 트래픽을 가로챈다. 그래서 피들러를 실행하

고 난 이후에 발생하는 HTTP(S) 트래픽은 피들러에 기록되어 웹 세션 패널에 나타난다. 참고로 피들러를

실행하기 전에 웹 브라우저가 여러 개 실행 중이라면 굉장히 많은 HTTP(S) 트래픽이 오갈 것이다. 그러면

피들러 화면이 복잡해지기 때문에 트래픽을 가로채는 범위를 줄이려면 피들러 화면 하단에 All Processes

라고 적힌 부분을 마우스로 클릭해 웹 브라우저만 선택한다. 그리고 가급적 피들러를 사용할 때는 트래픽

을 가로채고자 하는 페이지만 띄우는 게 좋다. 여기서는 필자가 준비한 테스트용 웹 페이지를 열어 보자. 인

터넷 익스플로러를 실행해 주소창에 다음 URL을 입력하기 바란다.

http://www.wikibook.co.kr/webtext/http/index.html

▲그림 3-6 HTTP 통신 체크

zz HTTPz요청을z엿보자

제대로 표시됐다면 피들러에 HTTP 통신이 기록돼 있을 것이다. 즉시 확인해 보자.

Lesson 3 HTTP 를 이해하자

50

▲그림 3-7 피들러가 HTTP 통신을 가로챈 결과

그림 3-7처럼 로그 한 줄이 표시돼 있다면 성공이다. 표시된 줄을 더블클릭해 보자. 그림 3-8와 같은 창이

표시될 것이다.

여기서 Inspector 탭의 상단에 표시된 내용이 바로 웹 브라우저에서 웹 서버로 송신된 HTTP 요청, 즉 21

페이지의 그림 2-8에서 설명한 ‘HTML을 주세요’라는 요청의 실체다.

▲그림 3-8 취득한 HTTP 요청과 응답의 상세 내용

그러면 HTTP 요청의 내용을 좀 더 자세히 살펴보자.

51

3

먼저 요청 헤더(Request Header)라고 적힌 패널의 첫 번째 부분에는 요청 라인이 나와 있으며, HTTP 요

청에서 가장 중요한 부분이다(그림 3-9).

메서드 URI HTTP 버전

▲그림 3-9 HTTP 요청 라인

요청 라인은 빈칸으로 구분된 세 문자열로 구성돼 있다.

a) 메서드

요청의 종류를 나타낸다. 여기서는 GET, 즉 ‘URI에서 지정한 정보를 보내 주세요’라는 의미가 된다. 메서드

에는 그 밖에도 몇 가지가 정의돼 있는데, 웹 브라우저에서 웹 서버로 송신되는 요청의 대부분은 GET 메서

드에 따른 요청이다.

b) URI

GET 메서드는 단순히 ‘정보를 주세요.’라는 의미에 불과하며, URI(Uniform Resource Identi�er)는 ‘무엇을 원

하는가?’를 나타낸다.

이 시점에서 의아해하는 사람도 많을 것이다. 기술한 내용은 똑같은데, 지금 등장한 URI와 22페이지에서

소개한 URL은 무엇이 다를까? 결론부터 말하면 일단은 ‘URL과 URI는 거의 같은 것’이라고 생각해도 무

방하다. 그 이유는 54페이지의 칼럼에서 이야기하겠다.

c) HTTP 버전

HTTP의 버전을 나타낸다. 버전에 따라 이용할 수 있는 메서드의 종류와 요청 헤더의 종류가 달라지므로

어떤 버전에 따른 요청인지 지정한 것이다.

여기서는 HTTP/1.1로 돼 있으므로 HTTP1.1이 사용됐음을 알 수 있다. 또 통상적인 웹 열람에서 이용하

는 범위라면 HTTP1.0이나 HTTP1.1이나 차이가 없다.

두 번째 줄 이후의 나머지 부분은 메시지 헤더라고 하며, 요청의 부가적인 정보를 나타낸다. 메시지 헤더

는 각 줄이 그림 3-10과 같은 형태로 표시돼 있다.

<필드 이름> ： <필드 값>

▲그림 3-10 메시지 헤더의 형식

Lesson 3 HTTP 를 이해하자

52

Accept: text/html, application/xhtml+xml, */*

Accept-Language: ko-KR

User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)

Accept-Encoding: gzip, deflate

Connection: Keep-Alive

Host: www.wikibook.co.kr

Pragma: no-cache

■예제 3-1 피들러가 취득한 메시지 헤더

예제 3-1에 나타난 것이 앞에서 피들러가 취득한 HTTP 요청 가운데 메시지 헤더에 해당하는 부분이다. 3

이해하기 쉽게 헤더명 부분을 굵게 표시했다. 여기서는 메시지 헤더가 7개 추가됐음을 알 수 있다. 이 가운

데 대표적인 헤더 4 의 의미를 간단히 소개하겠다.

d) Accept

웹 클라이언트가 받을 수 있는 데이터의 종류를 표시한 것이다. 데이터의 종류는 Content-Type 5 이라는 형

식으로 표시되며, 클라이언트에서 받을 수 있는 Content-Type을 콤마로 구분해서 지정한다. 예를 들어 텍

스트 파일을 나타내는 text/plain이나 JPEG 이미지를 나타내는 image/jpeg 같은 식이다. 이 책에서 이용한

인터넷 익스플로러 9에서는 text/html, application/xhtml+xml을 비롯해 임의의 정보를 받을 수 있음을 나

타내는 ‘*/*’이 있지만, 인터넷 익스플로러 7에서는 image/gif, image/x-xbitmap, image/jpeg, ……와 같이

Content-Type이 지정돼 있다.

왜 이런 정보가 필요할까? WWW의 세계에서는 HTTP에 따른 통신만 가능하면 어떤 소프트웨어든 웹

클라이언트가 될 수 있다. 예를 들어 19페이지의 각주에서 소개한 링크스라는 소프트웨어는 UNIX 콘솔에

서 작동하며 텍스트만으로 HTTP를 표현한다. 이와 같은 클라이언트는 JPEG나 GIF 등의 이미지를 표시할

수 없다. 그렇게 할 경우 Accept 필드를 참조하면 웹 서버는 불필요한 정보를 송신하지 않아도 될 가능성이

있는 것이다.

3 　 메시지 헤더는 이용하는 웹 브라우저에 따라 출력되는 내용이 다르다. 여기서 든 예는 인터넷 익스플로러 9의 메시지 헤더다.

4 　 HTTP의 헤더 필드는 HTTP/1.1을 규정하는 RFC2616에 규격이 정해져 있다. 그러나 실제로는 그림 3-11의 형식만 지키면 독자적인 헤더

(비표준 헤더)를 추가할 수도 있다. 본문에서는 RFC2616에서 규정된 헤더에 관해서만 설명했다. 대표적인 비표준 헤더로는 넷스케이프에서

독자적으로 책정한 쿠키(Cookie)가 있다. 이에 관해서는 ‘4.4 로그인 인증 기능을 작성한다’에서 자세히 설명하겠다.

5 　 전체 Content-Type은 인터넷과 관련된 각종 번호를 관리하는 단체인 IANA의 사이트(http://www.iana.org/assignments/media-types/index

.html[8])에 공개돼 있으므로 이곳을 참조하기 바란다. http://www.iana.org/assignments/media-types/index.htm

53

3

e) Accept-Language

웹 클라이언트가 받을 수 있는 자연 언어의 종류를 나타낸다. 자연 언어는 사람이 사용하는 언어를 가리킨

다. 여기서는 ‘ko-KR’로 되어 있으므로 한국어를 나타낸다.

예를 들어 같은 콘텐츠의 영어판과 한국어판이 있는 경우는 Accept-Language 헤더에 따라 웹 서버가 클

라이언트가 사용하는 언어에 맞는 콘텐츠를 보낼 수 있다. 6

f) User-Agent

이용 중인 웹 브라우저의 종류와 버전을 나타낸다.

웹 서버가 접속해 온 클라이언트의 종류에 낮춰 최적의 콘텐츠를 돌려주는 데 사용된다. 구체적인 예로

는 컴퓨터와 휴대전화 양쪽에서 열람할 수 있는 사이트가 있다. 이와 같은 사이트에서는 웹 서버가 User-

Agent 필드를 참조해 휴대전화에서 접속한 경우는 휴대전화용 HTTP를 돌려준다.

또 User-Agent 필드는 대부분의 경우 사이트 사용자가 어떤 브라우저를 이용하고 있는지 통계를 내는 데

도 이용된다.

g) Host

요청을 보낸 곳의 호스트명과 포트 번호를 지정한다.

6 　 이와 같은 구조를 콘텐트 네고시에이션(Content Negotiation)이라고 한다.

Lesson 3 HTTP 를 이해하자

54

C o l u m n칼럼 URL과 URI는 무엇이 다른가?

본문에서 URL과 URI라는 매우 혼동하기 쉬운 용어가 등장했다. 원래는 22페이지에서 소개했듯이 인터

넷상에 존재하는 리소스의 위치를 지정하기 위해 URL이 고안된 것이 최초였다. 그 후 URL을 좀 더 확장

한 개념으로 URI(Uniform Resource Identifier)가 고안된 것이다.

그렇다면 URI는 과연 어떤 것일까? 그림 3-11와 같이 URL과 함께 URN(Uniform Resource Name)을

포함시킨 것을 가리킨다.

URI(Uniform Resource Identifier)

URL(Uniform Resource Locator)

URN(Uniform Resource Name)

▲그림 3-11 URI의 범위

또 새로운 말이 나왔는데, URN은 인터넷상에 존재하는 이름을 고유하게 식별하기 위해 준비된 것이다. 예

를 들어 앞에서 여러분이 시험 삼아 입력한 http://www.wikibook.co.kr/webtext/http/index.html

라는 URL은 wikibook.co.kr이라는 도메인(조직)의 www라는 서버의 webtext/http라는 디렉터리에

존재하는 index.html이라는 파일명을 가리킨다. 문자 그대로 위치를 나타낸다. 그러나 이 파일이 www.

developerfarm.com이라는 호스트로 이동했다면 어떻게 될까? 이동된 URL을 모르고서는 접속할 수 없

을 것이다.

어라? 사라졌네?

55

3

이처럼 URL은 말하자면 인터넷상의 주소와 같은 것이므로 리소스가 이사해 버리면 어디에 있는지 알 수

없게 돼 버린다. 이런 문제를 해결하기 위해 인터넷상에 존재하는 리소스에 통일된 이름을 정하자는 생각

에서 고안된 것이 URN이다. 예를 들어 urn:itif:rfc:2626은 HTTP1.1의 RFC에 대한 URN이다. 이 문서

가 물리적으로 어떤 위치에 존재하든 같은 URN으로 표시할 수 있다.

이와 같이 URI는 위치를 나타내는 URL과 이름을 나타내는 URN을 통일적으로 나타낸 것이다. 그러나

안타깝게도 이 책을 집필하는 시점에서는 URN이 거의 이용되고 있지 않기 때문에 실질적으로는 URI도

URL도 거의 같은 의미로 취급되고 있다. 좀 더 정확히는 URI라고 불러야 할지도 모르지만 URL이라고 부

르는 경우가 더 많으므로 앞으로도 특별한 이유가 없는 한 URL이라고 부르겠다.

zz HTTPz응답을z엿보자

HTTP 요청이 어떤 것인지 이해가 됐는가? 뚜껑을 열어 보니 그렇게 어려운 것이 아님을 알았을 것이다.

그러면 웹 서버에서 돌려받은 HTTP 응답은 어떻게 됐는지 살펴보자. 동일한 피들러 화면에서(그림 3-8,

50페이지)에서 아래에 나와 있는 부분이 HTTP 응답을 의미한다. 여기서 Raw라고 적힌 버튼을 클릭하면

예제 3-2와 같은 내용이 표시된다.

HTTP/1.1 200 OK ❶

Server: apache

Date: Wed, 22 Feb 2012 06:19:08 GMT

Content-Type: text/html

Connection: keep-alive ❷

X-Powered-By: PHP/5.2.9p1

Content-Length: 283

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

<title>HTTP 통신 체크 테스트 페이지</title>

</head> ❸

<body>

<h1>HTTP 통신 체크 테스트 페이지</h1>

</body>

</html>

■예제 3-2 피들러가 가로챈 HTTP 응답

Lesson 3 HTTP 를 이해하자

56

a) 상태 라인

HTTP 요청과 마찬가지로 HTTP 응답에서도 첫 번째 줄이 가장 중요하며, 이것을 상태 라인이라고 한다(예

제 3-2의 ❶).

HTTP 상태 라인도 구성은 매우 간단하다. HTTP 버전과 상태 코드, 응답 구문으로 세 부분으로 나뉜다

(그림 3-12).

HTTP/1.1 200 OK

HTTP 버전 상태 코드 응답 구문

▲그림 3-12 HTTP 상태 라인

HTTP 버전은 요청에서 설명한 것과 마찬가지로 사용하는 프로토콜의 버전을 나타낸다. 중요한 것은 상

태 코드로, 이 부분을 보면 요청이 성공했는지 실패했는지 쉽게 알 수 있다. 200은 요청이 성공해 정상적인

응답이 돌아왔음을 나타내는 상태 코드다.

상태 코드는 세 자릿수 숫자와 여기에 이어지는 메시지로 표시된다. 첫 자릿수의 숫자가 카테고리를 나타

내며, 이것을 보면 대체적인 틀을 알 수 있게 돼 있다(표 3-1).

응답 구문은 상태 코드와 같은 의미이지만 이것은 사람이 보고 금방 알 수 있는 내용으로 돼 있다.

상태 코드 의미 설명

1×× Informational(정보) 요청 처리가 계속되고 있음을 나타낸다

2×× Success(성공) 요청이 성공했음을 나타낸다

3×× Redirection(리다이렉션) 요청을 종료하려면 작업이 더 필요함을 나타낸다

4×× Client Error(클라이언트 에러) 클라이언트 측에 기인한 오류로 요청이 실패했음을 나타낸다

5×× Server Error(서버 에러) 서버 측에 기인한 오류로 요청이 실패했음을 나타낸다

◆표 3-1 HTTP 응답 상태 코드의 범주

통상적인 HTTP 통신에서 자주 등장하는 상태 코드는 표 3-2와 같다. 실제로는 더 많은 상태 코드가 있

지만 7 여기에 소개한 코드만 기억해도 충분할 것이다.

7 　 HTTP 상태 코드에 관해서는 http://www.studyinghttp.net/status_code[9]에 알기 쉽게 정리돼 있으니 이쪽을 참조하기 바란다.

57

3

상태 코드 의미 설명

200 OK 요청이 정상적으로 완료됐음을 나타낸다

302 Found 요청된 리소스가 일시적으로 다른 URI에 속해 있음을 나타낸다. 4장에서 소개할 리

다이렉트에서 이용된다

401 Unauthorized 사용자 인증에 실패했음을 나타낸다

403 Forbidden 접속 권한이 없기 때문에 서버가 요청 실행을 거부했음을 나타낸다

404 Not Found 요청 URI와 일치하는 리소스를 찾지 못했음을 나타낸다. 브라우저에 입력한 URL이

잘못됐을 경우에 나타나는 오류

500 Internal Server Error CGI 프로그램 등 서버 내부의 프로그램 실행 과정에서 에러가 발생했음을 나타낸다

◆표 3-2 대표적인 상태 코드

b) 메시지 헤더

상태 라인에 이어서 나오는 것이 메시지 헤더(예제 3-2의 ❷)로, 두 번째 줄부터 빈 줄 8 까지 계속된다. 메시

지 헤더는 HTTP 요청의 메시지 헤더와 같은 형식으로, 응답에 관한 부가적인 정보가 들어 있다. 여기서는

HTTP 통신의 흐름을 이해하는 것이 목적이므로 자세한 내용은 생략한다. 9

c) 메시지 본문

마지막으로 등장하는 것이 메시지 본문(예제 3-2의 ❸)이다. 이번 예제에서는 HTML 파일을 요청했기 때문

에 HTML 파일의 내용이 그대로 들어 있다. 웹 브라우저는 이 HTML을 해석해 화면에 표시한다.

HTML은 텍스트 형식이므로 우리가 읽을 수 있는 형식으로 메시지 본문에 저장돼 있다. 그러나 GIF나

JPEG 형식의 이미지 파일을 요청했을 경우에도 마찬가지로 그 데이터가 메시지 본문에 그대로 들어간다.

이러한 데이터는 바이너리 형식이므로 피들러로 확인해도 의미를 알 수 없는 문자열로 보인다.

zz HTTP에서는z한z번에z리소스z하나를z취득한다

대략적인 흐름을 이해했으면 조금 더 실험을 해 보자.

이번에는 다음 URL에 접속하기 바란다.

http://www.wikibook.co.kr/webtext/http/image.html

8 　 줄바꾸기만 돼 있을 뿐 아무것도 적혀 있지 않은 줄

9 　 HTTP 헤더 필드에 관해서는 http://www.studyinghttp.net/header[10]에 알기 쉽게 정리돼 있으니 이쪽을 참조하기 바란다.

Lesson 3 HTTP 를 이해하자

58

그림 3-13과 같이 이미지를 포함한 페이지가 표시됐을 것이다. 이때는 어떤 요청을 발행했을까?

▲그림 3-13 이미지를 포함한 웹 페이지의 표시

피들러에서 취득한 로그를 살펴보면 요청이 두 번 있었음을 알 수 있다(그림 3-14).

▲그림 3-14 이미지를 포함한 웹 페이지의 HTTP 로그

첫 번째 요청에서는 전과 마찬가지로 브라우저의 주소창에 입력한 URL의 HTML 파일을 요청했다. 여기

서 취득한 HTML은 예제 3-3이며, 그 안에 img 태그가 담겨 있다.

59

3

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

<title>HTTP 통신 체크 테스트 페이지</title>

</head>

<body>

<h1>HTTP 통신 체크 테스트 페이지</h1>

<img src="logo.png" />

</body>

</html>

■예제 3-3 image.html

웹 브라우저는 HTTP를 해석하는 과정에서 이 img 태그를 확인하고 src 속성에 지정된 URL의 이미지를

다시 취득한다. 이것이 두 번째 요청의 정체다.

HTTP에서는 한 번의 요청에 한 리소스밖에 취득하지 못하기 때문에 이미지가 많이 들어 있는 페이지에

서는 이미지의 수만큼 HTTP 요청이 발생한다

zz 파일명을z생략했을z경우의z요청

마지막으로 한 가지 실험을 더 해 보자. 다음 URL에 접속해 보기 바란다.

http://www.wikibook.co.kr/webtext/http/

이번에는 처음에 실험한 것과 동일한 페이지(그림 3-6, 49페이지)가 표시됐다. 이것은 웹 서버의 기능으

로, 파일명을 생략한 URL로 접속할 경우 기본 문서 파일을 돌려준다. 기본 문서 파일은 웹 서버의 설정에

따라 달라지지만 기본적으로는 index.html이나 default.htm 등으로 돼 있다. 이와 같은 파일이 디렉터리에

있을 경우, 파일명이 생략됐으면 그 파일이 표시된다.

기업 등이 공개하는 웹 사이트의 URL이 http://wikibook.co.kr/과 같이 파일명이 생략된 이유는 이런 기

능이 있기 때문이다. 이렇게 함으로써 URL이 짧아져 기억하기가 편해지는 것이다.

Lesson 3 HTTP 를 이해하자

60

3.3 정보는 어떻게 인터넷의 대해를 건너는가?

지금까지 가장 단순한 HTTP의 통신을 살펴봤다. 어떤가? 막연하게나마 이미지가 잡혔는가? 피들러 같은

도구를 이용해 통신의 내용을 살펴보면 우리가 눈으로 보고 알 수 있는 형식 10 으로 통신을 주고받기 때문에

의외로 내용을 쉽게 이해할 수 있음을 깨달았을 것이다.

이 절에서는 좀 더 깊이 파고들어 HTTP에 따른 통신이 어떻게 상대방의 컴퓨터에 도착하는지에 관해서

도 간단히 이야기하고 넘어가겠다. 다만 정보가 네트워크를 경유해 어떻게 전달되는지를 빠짐없이 설명하려

면 그것만으로도 책 한 권 분량 11 은 나온다. 아쉽지만 이 책에서 전부 설명할 수는 없으므로 핵심적인 부분

만 설명하겠다.

zz 인터넷상의z주소-IPz주소

HTTP에 따른 요청에서는 요청의 목적지가 되는 웹 서버가 URL의 호스트명 부분에 표시돼 있었다. 앞에

서 시험한 http://www.wikibook.co.kr/webtext/http/index.html이라는 URL의 경우는 www.wikibook.

co.kr이 요청을 보내려는 웹 서버다. 그러나 이 호스트명도 사람이 이해하기 쉽게 표현된 것에 불과하다. 사

실 인터넷에 접속된 모든 컴퓨터는 IP 주소라는 숫자로 식별된다.

▲그림 3-15 IP 주소의 예

IP 주소는 그림 3-15과 같이 마침표로 구분된 네 가지 숫자의 조합으로 표시된다. 각 숫자의 종류는 0부

터 255까지 256가지다. 그 결과 256×256×256×256=4,294,967,296(약 43억)가지 12 의 숫자를 나타낼 수

있다. 13

10 　 효율을 추구하는 프로토콜은 컴퓨터가 해석하기 쉬운 바이너리 형식(텍스트가 아니라 수치에 의미를 부여하는 형식)으로 통신한다.

이 경우 정보의 양을 줄임으로써 대역폭을 절약할 수 있는 반면, 통신 로그를 사람이 읽어도 이해하기 어렵다는 문제점이 있다.

11 　 이에 관해 책 한 권에 정리한 것이 성안당의 《성공과 실패를 결정하는 1%의 네트워크 원리》[12]다. 정보가 전달되는 구조를 네트워크

전체에 걸쳐 매우 알기 쉽고 자세히 설명한 추천서다.

12 　 정보 공학의 기초를 배운 사람은 알고 있겠지만 각 숫자가 8비트로 표시돼 있어 전체적으로는 32비트의 숫자가 되었다.

13 　 이것은 현재 널리 사용되고 있는 IPv4(Internet Protocol Version 4)에 따른 IP 주소의 수로, 주소의 고갈이 우려되고 있다. 차세대 통신

프로토콜인 IPv6(Internet Protocol Version 6)에서는 IP 주소로 2128(2의 128제곱, 대략 340조의 1조 배의 1조 배)개를 이용할 수 있다.

61

3

이와 같은 숫자의 조합은 컴퓨터로서는 편리하지만 인간은 기억하기가 불편하다. 예를 들어 국내의 주소

가 전부 숫자로 표시돼 있다면 어떨 것 같은가? 자기 집 주소조차 잘 못 외울지 모른다. 역시 사람은 의미를

알기 쉬운 문자열을 훨씬 쉽게 기억하기 마련이다.

zz IPz주소에z의지해z정보를z보내는zTCP/IP

IP 주소를 알면 특정 호스트를 지정할 수 있으므로 해당 호스트로 임의의 정보를 보낼 수 있다. 인터넷의 세

계에서 그 역할을 맡은 것이 TCP/IP 14 라고 하는 프로토콜이다.

인터넷의 TCP/IP는 현실세계의 우편배달부와 매우 비슷하다. 가령 우리가 현실 세계에서 어떤 사람에게

편지를 보내고 싶다고 해보자. 편지를 써서 주소와 상대방의 이름을 적은 봉투에 담아 우편함에 넣는다. 그

러면 우체국이 주소와 이름을 가지고 그 사람에게 편지를 전달해 준다.

우편배달

A씨에게

웹 서버

A씨의 집

TCP/IP

이때 우리는 우편함에 넣은 편지가 어떻게 해서 상대방의 집에 도착하는지 생각할 필요가 없다. 모든 것

을 우체국이 알아서 해 주기 때문이다. 이와 마찬가지로 인터넷의 세계에서도 받을 곳만 IP 주소로 지정해

놓으면 어떻게 정보가 전달되는지까지 생각할 필요가 없다.

사실 TCP/IP는 브라우저 등으로부터 받은 HTTP 요청 등의 정보를 패킷(Packet) 15 이라고 하는 작은 단위

로 분할해 송신하며, 정보를 받은 쪽에서 그것을 원래대로 조립한 다음 송신처인 웹 서버 등의 애플리케이

션으로 넘긴다 16 (그림 3-16).

14 　 Transmission Control Protocol/Internet Protocol의 약자로, 네트워크상에서 정보를 주고받기 위한 기본 프로토콜이다. 1970년대에 미국

국방 고등 연구소(DARPA)의 연구가 발단이 되었다.

15 　 원래는 소포라는 의미다.

16 　 이와 같은 TCP/IP상의 처리는 TCP/IP 프로토콜 스택이라고 하는 프로그램에서 담당하며, 윈도우나 맥 OS, 리눅스 등 오늘날의 운영체제

에서는 표준으로 TCP/IP 프로토콜 스택이 내장돼 있다.

Lesson 3 HTTP 를 이해하자

62

웹 브라우저 웹 서버

분할 복원

웹 브라우저

분할

웹 서버

복원

인터넷

TCP/IP

1/5

4/5 5/5

2/5 3/5

TCP/IP

1/5

4/5 5/5

2/5 3/5

HTTP 요청 HTTP 요청

▲그림 3-16 TCT/IP를 통한 패킷의 송수신

‘왜 이렇게 번거로운 과정을 거치는 걸까?’라고 의문을 느끼는 사람도 많을지 모르지만 14페이지의 ‘2.1

WWW의 탄생과 보급’에서도 설명했듯이 인터넷은 다양한 네트워크의 협조로 성립된다. 정보가 상대방 컴

퓨터에 도달하기까지의 과정에는 고속도로처럼 대량의 정보를 처리할 수 있는 네트워크도 있지만 구불구

불한 산길처럼 정보를 조금씩밖에 보낼 수 없는 네트워크도 있을지 모른다. 이런 상황에서 정보를 한 번에

보내려고 하면 어떤 이유로 송신에 실패했을 때 모든 정보를 다시 보내야 한다. 그러나 패킷 같은 작은 단위

로 조금씩 보내면 설령 송신에 실패하더라도 그 패킷만 다시 보내면 되므로 전체적인 효율이 높다.

이처럼 멀리 떨어진 컴퓨터에 정보를 확실히 보내려면 갖가지 궁리를 해야 한다. 그러나 이것을 전부

TCP/IP가 해결해 주므로 우리는 깊게 생각할 필요가 없다. 17

웹 애플리케이션을 개발할 때 TCP/IP까지 깊게 이해할 필요는 없지만 그 존재는 알아 둬야 한다. 중요한

점은 다음 두 가지이므로 이것만큼은 기억하기 바란다.

y 정보는 패킷이라고 부르는 단위로 분할되어 송수신된다

y 패킷의 송수신은 TCP/IP가 책임지고 수행한다

17 　 여기서 설명한 것은 어디까지나 개략적인 내용이며, 실제로는 좀 더 다양한 방법이 마련돼 있다. 그러나 일반적으로 우리가 웹 애플리케이

션을 개발할 때 그것까지 알 필요는 거의 없으므로 이 책에서는 설명할 범위를 벗어난다고 간주했다. 관심이 있는 사람은 60페이지의 각주

에서 소개한 《성공과 실패를 결정하는 1%의 네트워크 원리》[12]를 참조하기 바란다.

63

3

zz IPz주소는z누가z결정하는가?

그러면 다시 IP 주소의 이야기로 되돌아가자. IP 주소는 전 세계에 하나밖에 없어야 하므로 아무렇게나 정

해도 되는 것은 아니다. IP 주소도 도메인명과 마찬가지로 특정 단체 18 가 관리하고 있으며, 여기에 신청해야

IP 주소를 할당받을 수 있다.

그러나 우리가 집에 있는 컴퓨터에서 인터넷에 접속할 때 일일이 IP 주소를 신청하지는 않는다. 이 경우는

우리가 이용하는 인터넷 서비스 프로바이더(ISP)가 대량의 IP 주소를 확보해 놓고 있다. 우리가 인터넷에 접

속할 때마다 ISP가 확보한 IP 주소 중 하나를 일시적으로 할당받는 방식이다(그림 3-17). 따라서 일반적으

로 우리가 이용하는 컴퓨터의 IP 주소가 반드시 똑같지는 않다.

이 범위의 IP 주소를사용하십시오

이 범위의 IP 주소를사용하십시오

ICANN

KRNIC

XXX.XXX.XXX.1

XXX.XXX.XXX.123

XXX.XXX.XXX.123XXX.XXX.XXX.254

…

…

이 IP 주소를 사용하십시오

할당

할당

할당

인터넷 서비스프로바이더(ISP)

사용자

▲그림 3-17 IP 주소 할당의 흐름

zz 글로벌zIPz주소와z사설zIPz주소

이렇게 해서 할당된 IP 주소는 인터넷상에서 유일한 주소가 되며, 글로벌 IP 주소라고 한다. IP 주소는 인터

넷의 이용뿐 아니라 컴퓨터를 비롯한 현재의 네트워크 기기가 서로 정보를 주고받는 데 필요하다. 설령 인터

넷을 이용하지 않더라도 사무실이나 가정에서 네트워크를 구축하려면 각 기기에 IP 주소가 있어야 한다. 이

처럼 인터넷 등 다른 네트워크에 접속돼 있지 않은 네트워크를 사설 네트워크(Private Network)라고 한다. 그

런데 사설 네트워크상의 호스트까지 ISP에서 글로벌 IP 주소를 할당받을 필요가 있을까? IP 주소는 네트워

18 　 ICANN(Internet Corporation for Assigned Names and Numbers)이라는 민간 비영리 법인이 전 세계의 IP 주소를 관리하고 있다.

일본에서는 JPNIC(일본 네트워크 정보 센터)가 ICANN으로부터 위탁을 받아 일본 국내의 IP 주소를 관리하고 있으며, 한국에서는 KISA

(한국인터넷진흥원)가 관리하고 있다.

Lesson 3 HTTP 를 이해하자

64

크에 접속된 호스트를 식별하기 위한 것이었다. 그러므로 사설 네트워크상에서 글로벌 IP 주소를 사용할 필

요는 없다. 어떤 사설 네트워크에서 사용되고 있는 IP 주소가 다른 사설 네트워크에서도 사용되고 있더라도

서로 네트워크가 연결돼 있지 않으므로 아무런 문제도 일어나지 않는다. 그래서 등장한 것이 사설 IP 주소

다. 사설 IP 주소는 어떤 일정 범위의 IP 주소를 사설 네트워크에서 자유롭게 이용할 수 있게 예약한 것이다.

가까운 예로 전화번호와 내선 번호의 차이를 생각하면 글로벌 IP 주소와 사설 IP 주소의 차이를 이해하

기가 쉬울 것이다. 글로벌 IP 주소는 전국에서 통용되는 유선 전화의 전화번호에 해당한다. 한편 사설 IP 주

소는 사무실이나 학교 등에서 사용되는 구내전화의 내선 번호에 해당한다.

글로벌 유선

IP 주소 전화번호중복되지 않는다

사설 내선IP 주소 번호

⑪홍길동

⑫이우진다른 곳에서

사용되어도 OK!

사설 IP 주소는 표 3-3과 같이 세 종류의 범위가 준비돼 있다. 이 범위의 주소는 특별히 신청하지 않아도

조직 내에서 자유롭게 이용할 수 있다.

사설 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개

◆표 3-3 사설 IP 주소

각 범위에는 클래스 A~C라는 이름이 붙어 있으며, 이용 가능한 주소의 수가 다르다. 일반적으로 사설 네

트워크에 연결되는 컴퓨터의 수는 그다지 많지 않기 때문에 주소의 수가 가장 적은 클래스 C의 주소가 자

주 이용된다. 여러분이 다니는 학교나 회사에 있는 컴퓨터에도 192.168.×.×라는 주소가 할당돼 있는 경우

가 많을 텐데, 이것은 클래스 C의 사설 IP 주소를 이용했기 때문이다.

65

3

C o l u m n칼럼 IP 주소와 개인 정보

최근 들어 개인 정보 유출 문제가 자주 화제가 되고 있다. 여러분 중에도 IP 주소가 유출되면 개인 정보가

노출되지 않을까 걱정하는 사람이 많을 것이다. 답은 ‘그렇다’이기도 하고 ’아니다’이기도 하다.

그 이유를 설명하겠다. 보통 기업이나 대학 등의 조직에서는 게이트웨이라고 하는 해당 조직의 출입구가

되는 서버를 통해 웹 사이트에 접속하기 때문에 접속한 곳의 웹 서버에는 게이트웨이의 IP 주소가 전달된

다. 이 시점에서 어떤 기업이나 대학에서 접속했는지는 손쉽게 파악할 수 있다. 또 게이트웨이에서는 내부

의 어떤 컴퓨터에서 어디로 접속했는지 기록할 수도 있으므로 기록이 남아 있으면 부정 접속 등의 범죄 행

위가 있을 때 당사자를 찾아낼 수 있다.

한편, 개인이 인터넷을 이용할 때는 대부분 ISP를 경유해 접속한다. 이때 ISP가 게이트웨이의 역할을 하

기 때문에 이 IP 주소가 어떤 ISP에서 접속했는지(경우에 따라서는 지역까지) 알 수 있다. ISP를 이용할

경우는 63페이지에서 이야기했듯이 접속할 때마다 다른 IP 주소가 할당되므로 일반적으로는 IP 주소를

통해 특정 개인을 식별하기란 불가능하다. 그러나 범죄 행위가 일어났을 때 범인을 찾을 수 있게 ISP 측에

서는 대부분 언제 누구에게 어떤 IP 주소를 할당했는지 기록을 남겨 놓고 있다. 이러한 정보는 필요할 때

경찰에게 제시된다.

따라서 IP 주소가 알려진다고 해서 금방 개인 주소가 노출되지는 않는다. 그러나 범죄 방지 차원에서 언제

라도 조사할 수 있는 체제는 갖춰져 있는 것이다.

zz 호스트명을zIPz주소로z변환하는zDNS

인터넷상에서는 IP 주소로 통신 상대의 컴퓨터를 식별한다는 사실을 알 수 있었다. 그러나 우리가 브라우저

의 주소창에 입력하는 URL에는 IP 주소가 등장하지 않는다. 어딘가에서 도메인명을 IP 주소로 변환하는

시스템이 있는 것이다. 그렇다면 어떻게 해서 IP 주소를 산출하는 것일까?

그것을 가능케 하는 것이 DNS(Domain Name System)라는 시스템이다. DNS는 도메인명과 IP 주소의 대응

표를 가진 컴퓨터(DNS 서버)를 인터넷상에 배치해 놓고 있으면서 DNS 서버에 문의하면 도메인명에 대응하

는 IP 주소를 가르쳐 준다(그림 3-18).

클라이언트 DNS 서버

www.daum.net의 IP 주소를 가르쳐 주십시오

114.108.157.19입니다

▲그림 3-18 DNS 서버에 문의

Lesson 3 HTTP 를 이해하자

66

이 문의는 우리가 직접 할 수도 있다. 잠시 실험해 보자. 윈도우의 명령 프롬프트를 열고 19 다음 명령어를

입력해 보기 바란다.

C:\>nslookup daum.net

그러면 다음과 같은 결과가 표시될 것이다.

C:\>nslookup daum.net

서버: kns.kornet.net

Address: 168.126.63.1

권한 없는 응답:

이름: daum.net

Addresses: 114.108.157.19

114.108.157.50

61.111.62.173

110.45.215.23

중간 부분은 네트워크 환경에 따라 다르지만 마지막 줄에 나온 IP 주소가 DNS 서버에 질의해 알아낸

www.daum.net에 대응하는 IP 주소다. 우리가 웹 페이지를 보고 있는 뒤편에서는 이와 같이 도메인명과 IP

주소가 자동으로 변환되고 있다. 20

참고로 웹 브라우저에 입력하는 URL에서는 도메인명 대신 직접 IP 주소를 지정할 수도 있다. http://

www.daum.net이라고 입력했을 때와 http://114.108.157.19라고 입력했을 때 같은 웹 페이지가 표시되는 것

을 확인해 보기 바란다.

zz DNS는z어떻게z구현되는가?

DNS는 알고 보면 매우 간단한 아이디어다. 그러나 문제는 구현 방법이다. IP 주소는 최대 약 43억 개 21 나 되

므로 도메인명과 IP 주소의 대응표만으로도 정보의 양이 방대해진다. 그러면 간단히 계산해 보자.

19 　 윈도우 XP의 경우는 시작 메뉴에서 [프로그램]-[보조 프로그램]-[명령 프롬프트]를 선택하면 열 수 있다. 또 윈도우 비스타나 윈도우 7에

서도 마찬가지로 시작 메뉴에서 [모든 프로그램]-[보조 프로그램]-[명령 프롬프트]를 선택하면 열 수 있다.

20 　 이 변환은 운영체제가 담당한다.

21 　 실제로는 앞에서 등장한 사설 IP 주소 등이 있어서 모든 주소가 사용되지는 않는다. 여기서는 이야기를 간단히 하기 위해 모든 주소가

사용되고 있다고 가정했다.

67

3

IP 주소 도메인명IP 주소 도메인명

IP 주소 도메인명

4 바이트 255 바이트

4,294,967,296(=4G)개

(4+255)바이트×4G개=1,036G바이트≒1T바이트!!

▲그림 3-19 IP 주소-호스트명 대응표의 정보량

IP 주소는 8비트(=1바이트) 4조(組)의 숫자로 표시되므로 4바이트다. 또 도메인명은 최대 255바이트이므

로 합쳐서 259바이트다. 약 43억 개(4G개)나 되는 IP 주소가 각각 이 조합을 가지는 것이므로 그 정보량은

259×4G=1,036G바이트, 즉 1T(테라 22 )바이트 이상이 된다(그림 3-19). 최근 하드디스크의 용량이 커지고

있다고는 해도 엄청난 양이다. 게다가 이 문의가 웹 서버에 접속할 때마다 발생한다면 도저히 컴퓨터 한 대

로는 모든 질의를 처리할 수 없다. 또 설령 서버 한 대에서 처리한다고 해도 그 서버가 고장으로 정지해 버리

면 전 세계가 인터넷을 이용할 수 없게 돼 버린다.

그렇다면 어떻게 해야 이를 처리할 수 있을까? DNS에서는 그림 3-20과 같이 도메인명에 대응하는 DNS

서버를 다수 준비해 정보를 분산 관리하고 있다. 예를 들어 앞의 예에서 든 daum.net라는 도메인명은 마침

표로 구분된 daum과 net이라는 두 계층으로 나뉜다. 인터넷상에는 각 계층에 대응하는 DNS 서버가 준비

돼 있으며, 이들 DNS 서버에 질의함으로써 하위 DNS 서버의 주소를 알 수 있게 돼 있다.

루트 DNS 서버

net 도메인의 DNS 서버

▲그림 3-20 DNS 서버의 계층 구조

22 　 1T(테라)바이트는 240=1,099,511,627,776(약 1조)바이트다. 일반적으로 하드디스크의 용량은 1012=1,000,000,000,000(1조)바이트를 1테라바

이트로 표시하기 때문에 약간 차이가 있다.

Lesson 3 HTTP 를 이해하자

68

이번 예의 경우, daum.net의 DNS 서버 주소는 상위인 net 도메인의 DNS 서버에 등록돼 있는 식이다.

그러나 이것으로 끝나지 않는다. kr이나 com, net, org 같은 최상위 도메인을 TLD(Top Level Domain)이라

고 하는데, 이러한 TLD의 DNS 서버를 관리하는 우두머리라고도 할 수 있는 DNS 서버가 존재한다. 이것이

루트 서버다. 루트 서버는 2010년 현재 전 세계에 13개 23 가 있다. 루트 서버의 IP 주소는 거의 변경되지 않기

때문에 각 운영체제나 모든 DNS 서버에 등록되어 언제라도 참조할 수 있게 돼 있다. 루트 서버부터 순서대

로 하위 DNS 서버에 질의해 나감으로써 최종적으로 원하는 호스트명에 대응하는 IP 주소를 알 수 있다.

한편 DNS는 인터넷의 근간을 뒷받침하는 시스템이므로 DNS 자체가 다운되면 인터넷을 이용할 수가 없

다. DNS는 전 세계의 수만 대나 되는 서버를 통해 운용되고 있으므로 모든 서버가 망가지지 않는 한 DNS

가 다운되는 일은 없다. 그러나 어떤 이유로 가까운 DNS 서버에 접속할 수 없는 경우 등에는 호스트명을 해

석하지 못해 웹 서버를 표시할 수 없게 된다. 이 같은 경우는 앞에서 소개한 nslookup 명령으로 호스트명을

정상적으로 해석할 수 있는지 알아보는 것이 한 가지 방법이다.

zz 호스트z내의z수신처를z결정하는z포트z번호

이제 URL에 포함된 호스트명에서 정보를 수신할 컴퓨터를 찾아내기까지의 흐름을 이해했을 것이다. 그러

나 이것으로 끝이 아니다. 인터넷의 세계에서는 HTTP 이외에도 다양한 프로토콜로 정보를 주고받는다. 예

를 들자면 이미 우리 생활의 일부가 된 이메일의 송수신에 사용되는 SMTP와 POP3, 웹 사이트의 갱신 등

파일을 전송하기 위한 FTP, 멀리 떨어진 곳에서 컴퓨터를 조작하기 위한 Telnet이나 SSH 등이 여기에 해당

한다. 이러한 프로토콜은 전부 61페이지에서 설명한 TCP/IP상에서 동작하며, 정보를 수신할 컴퓨터를 지

정하는 데 IP 주소를 사용한다.

인터넷을 통해 정보를 수신할 컴퓨터에 도착한 패킷이 수신 측의 TCP/IP를 통해 원래의 정보로 재구축

된다는 것은 61페이지에서 설명했다. 그러나 수신한 정보가 어떤 프로토콜의 것이고, 어떤 애플리케이션에

서 처리해야 하는지 TCP/IP는 알지 못한다. 그래서 등장하는 것이 포트(Port)라는 개념이다. TCP/IP를 통

해 정보를 수신하는 애플리케이션은 반드시 수신 대기 포트를 결정하고 정보를 기다린다. 포트는 0~65,535

까지의 숫자로 표시되며, 여러 개의 애플리케이션이 같은 포트를 이용할 수는 없다. 포트에는 원래 항구라

는 의미가 있는데, 컴퓨터 안에서 애플리케이션이 정보의 수신을 기다리기 위한 항구의 부두를 떠올리면 이

해하기가 쉬울 것이다. 컴퓨터를 항구에 비유하면 부두가 65,536개 있어서 각 부두에서 애플리케이션이 정

보를 기다리는 것이다.

23 　 실제로 루트 서버가 13대밖에 없는 것은 아니며, IP 주소가 13개라고 말하는 편이 좀 더 정확하다. 재해나 고장에 대비해 IP 주소 하나에

여러 대의 DNS 서버가 등록돼 있다. http://www.root-servers.org/에는 IP 주소 13개의 관리 조직과 서버 소재지가 공개돼 있다.

69

3

컴퓨터A는

1번 포트B는

2번 포트

C는 3번 포트

지금까지는 인터넷으로 정보를 보낼 때 IP 주소로 수신처를 지정한다고 설명했다. 그러나 실제로는 IP 주

소와 함께 포트 번호까지 지정해야 한다. 그렇게 하지 않으면 도착한 정보를 어느 애플리케이션에서 처리해

야 할지 알 수 없기 때문이다.

그런데 지금까지 살펴본 URL에는 어디에도 포트 번호가 표시돼 있지 않았다. 사실 이것은 지정할 필요가

있지만 생략됐을 뿐이다. 가령 www.wikibook.co.kr이라는 이름으로 표시되는 호스트에 HTTP 요청을 보

낼 경우 www.wikibook.co.kr:80이라고 기술된다. 일반적으로 다음과 같은 방식으로 기술한다.

호스트명(또는 IP 주소): 포트명

[예]

▲그림 3-21 호스트명과 포트 번호를 통한 수신처 지정

그렇다면 왜 지금까지 포트 번호의 지정을 생략해도 HTTP 요청이 웹 서버에 정확히 전달됐던 것일까? 일

반적으로 애플리케이션이 어느 포트에서 정보를 기다릴지는 자유롭게 결정할 수 있다. 그러나 그래서는 같

은 HTTP라도 호스트에 따라 포트 번호가 제각각이 되어 버려 불편하다. 그래서 자주 사용되는 프로토콜

에 대해서는 표준으로 사용하는 포트를 정해 놓았다. 가령 HTTP 프로토콜의 경우는 80번이다. 보통 브라

우저는 URL에 포함된 스킴(24페이지의 표2-1 참조)을 통해 HTTP 프로토콜을 사용한다는 사실을 안 시점

에서 URL 내에 포트 번호가 지정되지 않았다면 80번 포트를 수신 포트로 설정한다. 이와 같은 약속 덕분에

평소에 웹 사이트를 볼 때 포트 번호까지 신경 쓰지 않아도 되는 것이다.

또 이처럼 대표적인 프로토콜이 사용하는 포트를 잘 알려진 포트(well-known ports)라고 한다. 표 3-4는 잘

알려진 포트의 대표적인 예다.

Lesson 3 HTTP 를 이해하자

70

포트 번호 프로토콜

20, 21 FTP(파일 전송)

22 SSH(암호화된 원격 컴퓨터와의 범용 통신)

23 Telnet(원격 컴퓨터와의 범용 통신)

25 SMTP(이메일 송신)

53 DNS(호스트명 해석)

80 HTTP(웹 브라우징)

110 POP3(이메일 수신)

443 HTTPS(암호화된 HTTP)

◆표 3-4 대표적인 잘 알려진 포트

3.4 웹 서버에 요청을 어떻게 전달하는가?

지금까지 HTTP 통신의 실제 모습을 이해하면서 웹 페이지가 표시되기까지의 흐름을 소개했다. 그러나 지

금까지의 흐름만으로는 아직 웹 애플리케이션을 구현할 수 없다. 웹 애플리케이션이 어떤 것인가는 ‘1.2 웹

애플리케이션’에서 설명했지만 다시 한 번 간단히 복습해 보자. 웹 애플리케이션에서는 사용자가 브라우저

상의 폼에 요청 정보를 입력하면 그것을 바탕으로 서버 측에서 어떤 처리를 수행했다. 그 결과가 HTML로

되돌아와 웹 브라우저에 표시되는 것이다.

지금부터는 간단한 웹 애플리케이션의 예를 들어 HTTP로 어떤 정보가 오가는지 살펴보자.

zz GETz메서드를z이용한z매개변수z전달

사용자가 웹 애플리케이션에 정보를 전달하는 방법은 두 가지가 있다.

먼저 비교적 간단한 방법을 시험해 보자. 다시 한 번 피들러의 로그 기록 기능을 활성화하고 다음 URL에

접속해 보기 바란다.

http://www.wikibook.co.kr/webtext/calc_get.html

그러면 이번에는 다음과 같은 웹 페이지가 표시될 것이다.

71

3▲그림 3-22 GET 메서드를 이용한 매개변수 전달

이것은 내가 만든 아주 간단한 웹 애플리케이션으로, HTML 폼을 이용해 입력된 숫자의 합을 표시하

는 역할을 한다. 시험 삼아 123+456을 계산해 보자. 각 입력 필드에 숫자를 넣고 계산 버튼을 누른다(그림

3-23).

▲그림 3-23 GET 메서드를 이용한 매개변수 전달 - 매개변수 입력

그러면 다음과 같이 계산 결과가 표시될 것이다(그림 3-24). 입력한 두 수를 더한 결과가 표시됐다.

▲그림 3-24 GET 메서드를 이용한 매개변수 전달 - 계산 결과

‘다시 한 번 계산한다’라는 하이퍼링크를 클릭하면 앞 페이지로 돌아가므로 숫자를 바꿔서 계산해도 올바

른 결과가 표시되는지 확인하기 바란다.

이 웹 페이지가 어떻게 만들어졌는지 확인해 보자. 예제 3-4는 그림 3-24의 웹 페이지의 HTML이다.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

<title>GET 메서드를 이용한 매개변수 전달</title>

</head>

<body>

<h1>GET 메서드를 이용한 매개변수 전달</h1>

<form action="do_calc_get.php" method="get">

❶

Lesson 3 HTTP 를 이해하자

72

<input type="text" name="arg1" size="8">

+ ❷

<input type="text" name="arg2" size="8">

❸

<input type="submit" value="계산">

</form>

</body>

</html>

■예제 3-4 calc_get.html의 내용

HTML의 기초를 설명한 서적은 이미 많이 나와 있으므로 자세한 설명은 생략한다. 여기서는 예제 3-4

의 밑줄 친 ❷와 ❸에 나와 있듯이 두 텍스트 필드에 각각 arg1과 arg2라는 name 속성을 부여했다는 데 주

목한다. 이것은 텍스트 필드에 입력된 문자열이 arg1, arg2라는 이름으로 웹 서버에 송신된다는 것을 나타

낸다.

그렇다면 실제로는 어떻게 해서 웹 서버로 정보가 송신되는 것일까? 피들러에서 취득한 HTTP 통신 로그

를 확인해 보자(그림 3-25).

▲그림 3-25 피들러를 이용해 GET 요청을 취득한 결과

요청이 두 개 발행됐음을 알 수 있다. 첫 번째 요청은 http://www.wikibook.co.kr/webtext/calc_get.

html(그림 2-23)에 접속했을 때의 요청이다. 그리고 두 번째는 이 페이지에서 ‘계산’ 버튼을 눌렀을 때 발행

된 요청이다.

73

3

HTML의 폼에서는 제출 버튼 24 을 눌렀을 때 웹 브라우저가 form 요소의 action 속성에서 지정된 URL

에 접속한다. 이때 데이터를 주고받는 방법을 지정하는 것이 method 속성의 내용이다. 예제 3-4에서는 get

을 지정했으므로 GET 메서드를 사용해 폼에 입력한 내용을 송신하도록 의도했다.

그렇다면 구체적으로는 어떻게 정보를 송신하고 있을까? 피들러에서 취득한 두 번째 요청을 더블 클릭해

자세한 내용을 살펴보자(예제 3-5).

GET http://www.wikibook.co.kr/webtext/do_calc_get.php?arg1=123&arg2=456 HTTP/1.1

Accept: text/html, application/xhtml+xml, */*

Referer: http://www.wikibook.co.kr/webtext/calc_get.html

Accept-Language: ko-KR

User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)

Accept-Encoding: gzip, deflate

Host: www.wikibook.co.kr

Connection: Keep-Alive

■예제 3-5 GET 요청으로 송신된 폼의 정보

빠르게 훑어보니 3.2절에서 처음에 본 GET 요청과 같아 보인다. 주목해야 할 것은 첫 번째 줄, 즉 요청

라인 부분이다(예제 3-5에서 밑줄 친 부분). URL 뒤에 낯선 문자열이 추가돼 있는데, 사실은 이것이 바로

GET 요청으로 송신되는 정보의 정체다. 좀 더 자세히 살펴보자. 그림 3-26이 요청 라인에 포함된 정보 부분

이다.

/do_calc_get.php?arg1=123&arg2=456 매개변수명 값

쿼리 문자열

▲그림 3-26 GET 요청의 쿼리 문자열

통상적인 URL에 ‘?(물음표)’가 이어져 있다. 이 부분을 쿼리 문자열(Query String)이라고 하며, 폼에 입력된

문자열 등을 웹 서버에 전달하는 데 사용된다. 쿼리 문자열 속은 다시 &(앰퍼샌드)로 나뉘어 있으며, 각 부

분은 ‘매개변수명=값’의 형식으로 표현된다.

24 　 type 속성이 submit으로 돼 있는 input 요소로 표시되는 버튼. 여기서는 ‘계산’ 버튼이 제출 버튼에 해당한다.

Lesson 3 HTTP 를 이해하자

74

이것으로,

arg1이라는 텍스트 필드에 123이라는 문자열이 입력되었다

arg2라는 텍스트 필드에 456이라는 문자열이 입력되었다

라는 정보를 웹 서버에 송신하는 것이다.

한편 웹 서버 측에서는 수취한 요청 라인 속에 물음표가 존재하면 25 그 이후를 쿼리 문자열로 인식하고

그 안에 들어 있는 매개변수를 CGI 등을 통해 실행되는 애플리케이션에 넘긴다.

zz 애플리케이션z측의z매개변수z받기

다음에는 GET 메서드로 전송된 매개변수를 애플리케이션 측에서 어떻게 취급하는지도 살펴보자. 애플리

케이션에 매개변수를 보내는 방법은 언어에 따라 다르므로 일괄적으로 설명할 수는 없다. 여기서는 최근 중

소 규모의 웹 애플리케이션에서 널리 이용되고 있는 PHP의 예를 소개하겠다.

예제 3-6을 보기 바란다. 이것이 앞의 두 GET 요청에서 지정됐던 do_calc_get.php다. PHP는 프로그래

밍 언어이지만 너무 어렵게 생각할 필요는 없다. 보다시피 대부분이 통상적인 HTML과 같다.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

<title>GET 메서드를 이용한 매개변수 전달</title>

</head>

<body>

<h1>GET 메서드를 이용한 매개변수 전달</h1>

<?php

$arg1 = $_GET['arg1'];

$arg2 = $_GET['arg2'];

$result = $arg1 + $arg2;

echo htmlspecialchars($arg1)." + ".htmlspecialchars($arg2)." = ".htmlspecialchars($result);

?>

<br />

25 　 물음표는 URI의 예약 문자열이라서 URL에는 포함되지 않는다. 그래서 요청 라인 안에 물음표가 있으면 그 이후는 쿼리 문자열로

인식할 수 있다. URI에서 사용할 수 있는 문자는 표 3-6(81페이지)에 정리했으니 그쪽을 참조하기 바란다.

❷

❸

❶

75

3

<a href="calc_get.html">다시 한 번 계산한다</a>

</body>

</html>

■예제 3-6 PHP로 작성한 계산 애플리케이션(do_calc_get.php)

진하게 칠한 ‘<?php ~ ?>’로 묶인 부분이 PHP 프로그램 부분이다. PHP는 ‘2.5 JSP의 탄생’에서 소개한

JSP와 마찬가지로 HTML 속에 프로그램을 심는 방식으로 애플리케이션을 만들 수 있다. 이 책에서는 PHP

에 관해 자세히 설명하지 않지만 26 여기서는 일단 분위기만 느껴 보기 바란다.

예제 3-6의 ❶에 나온 부분이 쿼리 문자열에 저장된 값을 꺼내 변수에 저장하는 부분이다. PHP에서는

‘$_GET’이라는 연관 배열 27 에 매개변수명과 값의 집합이 저장돼 있어서 매개변수명을 지정해 꺼내기만 하

면 된다. 여기서는 꺼낸 값을 각각 $arg1, $arg2라는 변수에 저장했다. 웹 애플리케이션에서는 언어에 따라

이 매개변수를 꺼내는 방법이 다르지만 기본적인 개념에는 차이가 없다.

예제 3-6의 ❷에서는 $arg1과 $arg2의 내용을 더해 $result라는 변수에 저장했다. 여기서 실제 덧셈을 수

행할 것이다.

그리고 마지막으로 예제 3 - 6의 ❸에 나온 echo문으로 HTML을 출력했다. 이번 예제에서는

‘123+456=579’라는 문자열이 HTML의 일부로 출력됐다. 28

어떤가? 생각보다 간단하지 않은가? 이와 같이 구조를 알면 웹 애플리케이션의 기본은 그렇게 어렵지 않

다. 다만 여기에 네트워크를 통해 데이터를 주고받는 HTTP가 얽히기 때문에 조금 어려워 보일 뿐이다.

zz POSTz메서드를z이용한z매개변수z전달

그런데 이처럼 간단한 GET 메서드를 이용한 매개변수 전달에는 한 가지 커다란 문제점이 있다. URL 속에

매개변수가 포함되기 때문에 어떤 정보를 웹 서버에 전송했는지 제삼자에게 누설될 가능성이 크다는 점이

다. 일반적으로 웹 서버에서는 수취한 요청의 요청 라인이 로그로 기록된다. 예를 들어 아이디와 패스워드

같은 중요한 정보를 GET 메서드로 보낼 경우, 이러한 정보를 담은 요청 라인이 서버의 로그에 남기 때문에

26 　 PHP를 배우고 싶다면 《PHP5 철저 공략(PHP5徹底攻略)》[15]과 《PHP5 철저 공략 전문가편(PHP5徹底攻略 エキスパ-ト編)》[16]을 추천한다.

27 　 ‘이름=값’이라는 한 쌍의 정보를 저장할 수 있는 배열이다. 펄이나 PHP에서는 연관 배열이라 하고 자바에서는 맵이라고 한다.

28 　 $arg1과 $arg2가 htmlspecialchars()로 묶여 있는데, 이것은 7장에서 설명할 보안 대책 때문이다. 또 PHP에서 ‘.’(마침표)는 문자열 연결을

나타내는 연산자다.

Lesson 3 HTTP 를 이해하자

76

그 로그를 본 제삼자에게 아이디와 패스워드가 알려질 위험성이 있다. 29 또 과거에 만든 웹 서버나 웹 클라

이언트 중에는 이용할 수 있는 URL의 길이가 255문자로 제한돼 있다는 문제도 있는데, 이럴 경우에는 많

은 정보를 취급할 수 없다는 문제도 있다.

그래서 등장한 것이 또 한 가지 방법인 POST 메서드를 이용한 매개변수 전달이다. POST 메서드는 어떻게

매개변수를 전달할까? GET 메서드를 살펴볼 때와 마찬가지로 HTTP 통신의 내용을 실제로 들여다보자.

피들러의 로그 기록 기능을 활성화한 상태에서 다음 URL에 접속해 보기 바란다.

http://www.wikibook.co.kr/webtext/calc_post.html

그러면 그림 3-27과 같은 웹 페이지가 표시된다.

▲그림 3-27 POST 메서드를 이용한 매개변수 전달

앞에서와 마찬가지로 각 텍스트 필드에 123, 456을 입력하고 ‘계산’ 버튼을 눌러 보자. 계산 결과가 표시

될 것이다(그림 3-28).

▲그림 3-28 POST 메서드를 이용한 매개변수 전달 - 계산 결과

여기까지는 GET 메서드와 완전히 똑같다. 매개변수를 전달하는 방법이 다를 뿐이므로 사용자가 볼 때는

차이가 없다. 그렇다면 HTTP 통신은 어떨까? GET 요청을 사용했을 때와 마찬가지로 요청이 두 개 발행됐

다(3-29).

29 　 이러한 보안과 관련된 문제는 7장에서 자세히 다루겠다.

77

3

▲그림 3-29 피들러를 사용해 POST 요청을 취득한 결과

여기에서 주목할 것은 두 번째 요청이다. 목록을 더블 클릭해 자세한 내용을 살펴보자(예제 3-7).

POST http://www.wikibook.co.kr/webtext/do_calc_post.php HTTP/1.1 ❶

Accept: text/html, application/xhtml+xml, */*

Referer: http://www.wikibook.co.kr/webtext/calc_post.html

Accept-Language: ko-KR

User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)

Content-Type: application/x-www-form-urlencoded

Accept-Encoding: gzip, deflate

Host: www.wikibook.co.kr

Content-Length: 17

Connection: Keep-Alive

Pragma: no-cache

arg1=123&arg2=456

■예제 3-7 POST 요청으로 송신된 폼의 정보

GET 요청으로 정보를 송신했을 때와 무엇이 다른지 알겠는가? 다른 점은 두 가지다. 먼저, 요청 라인을 보

면 메서드가 GET이 아니라 POST다. 그리고 GET 요청을 사용했을 때는 있었던 쿼리 문자열이 없어졌다(예

제 3-7의 ❶).

그렇다면 매개변수는 어디에 들어 있을까? 그 답은 메시지 본문 부분이다(예제 3-7의 ❷). GET 요청을 사

용했을 때는 메시지 본문이 없었지만 POST 요청의 경우는 메시지 본문에 매개변수가 들어 있다. 형식은

❷

Lesson 3 HTTP 를 이해하자

78

GET 요청을 사용할 때와 마찬가지로 ‘매개변수명=값’의 조합을 &(앰퍼샌드)로 구분한 것이다.

이처럼 POST 요청에서는 쿼리 문자열을 사용하는 대신 메시지 본문을 이용해 매개변수를 전달한다. 이

에 따라 GET 요청을 사용해 매개변수를 전달할 때의 문제점을 해결할 수 있다.

첫째는 매개변수가 URL에 들어가지 않기 때문에 브라우저의 주소창에 표시되지 않아 제삼자에게 노출

될 가능성이 적다는 점이다. 또 같은 이유로 보통 POST 요청에 포함되는 매개변수가 웹 서버의 로그에 기록

될 가능성도 줄어든다. 30 둘째는 메시지 본문에는 길이 제한이 없어서 매개변수의 양이 많아도 길이를 걱정

할 필요가 없다는 점이다.

그렇다면 애플리케이션은 POST 요청으로 전달된 매개변수를 어떤 방법으로 취득할 수 있는 것일까?

GET 메서드 때와 마찬가지로 PHP의 소스코드를 살펴보자(예제 3-8).

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html lang="ko">

<head>

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

<title>POST 메서드를 이용한 매개변수 전달</title>

</head>

<body>

<h1>POST 메서드를 이용한 매개변수 전달</h1>

<?php

$arg1 = $_POST['arg1'];

$arg2 = $_POST['arg2'];

$result = $arg1 + $arg2;

echo htmlspecialchars($arg1)." + ".htmlspecialchars($arg2)." = ".htmlspecialchars($result);

?>

<br />

<a href="calc_get.html">다시 한 번 계산한다</a>

</body>

</html>

■예제 3-8 PHP로 작성한 계산 애플리케이션(do_calc_post.php)

30 　 메시지 본문까지 로그에 남기면 로그가 방대해져서 일반적으로는 메시지 본문을 로그에 남기지 않는다. 그러나 기술적으로는 메시지

본문을 로그에 남길 수 있으므로 보안상의 주의가 필요하다.

❶

79

3

보다시피 GET 메서드로 매개변수를 전달했을 때(예제 3-6)와 차이는 거의 없다. 다른 점은 매개변수를

꺼내는 부분의 연관 배열이 $_GET에서 $_POST로 바뀌었을 뿐이다(예제 3-8의 ❶). 이것은 PHP가 아니더

라도 마찬가지로, 어느 메서드를 이용해 매개변수를 전달하든 이를 전달받는 애플리케이션 입장에서는 큰

차이가 없다.

zz GET과zPOSTz중z어느z쪽을z사용해야z할까?

그렇다면 매개변수의 전달 방법이 한 가지가 아니라 두 가지인 이유는 뭘까? 여기까지 읽은 독자라면

‘POST 요청을 사용하는 편이 더 낫지 않아?’라고 생각할 것이다. 그러나 GET 요청과 POST 요청에는 커다

란 차이가 있다.

구체적인 예를 들어 보자. 이번에는 유명 검색 사이트인 구글을 이용해 보겠다. 구글 웹 사이트(http://

www.google.co.kr/)를 열어 검색 키워드에 ‘car’라고 입력해 검색해 보자. 검색 결과가 표시될 것이다. 이때

브라우저의 주소창에 주목하기 바란다. 내 컴퓨터 환경에서는 다음과 같이 표시된다.

http://www.google.co.kr/search?hl=ko&site=&q=car&oq=

■예제 3-9 구글 검색 결과의 URL

보다시피 GET 메서드를 사용해 매개변수를 전달했다. 이 매개변수 속에 q=car라고 적힌 부분이 포함돼

있다(예제 3-9의 밑줄 친 부분). 여러분이 검색 키워드로 입력한 문자열이 q라는 매개변수명으로 전달됐음

을 알 수 있다. 31

그런데 이 검색 결과를 보존해 놓았다가 나중에 다시 보고 싶을 때도 많다. 그럴 때 여러분이라면 어떻게

하겠는가? 그렇다. 브라우저의 즐겨찾기나 북마크에 보존할 것이다. 또 검색 결과를 친구에게 보내고 싶을

때는 어떻게 하겠는가? 주소창에 표시된 URL을 복사에 이메일로 보낼 것이다.

31 　 여기서는 다른 매개변수도 전달되는데, 전달되는 매개변수는 구글의 표시 설정에 따라 달라진다.

Lesson 3 HTTP 를 이해하자

80

즐겨찾기에 추가 이메일웹

A씨

제목 편리한 사이트

A씨에게편리한 사이트를 발견했습니다!

이처럼 GET 메서드는 URL에 매개변수가 포함되기 때문에 매개변수째로 기억하거나 다른 사람에게 전

달할 때 편리하다. 또 이를 위해서는 GET 요청의 결과가 시스템의 상태에 영향을 주지 않게 돼 있어야 한

다. 가령 구글에서 검색할 경우, 같은 시점이라면 똑같은 검색 키워드를 아무리 입력해도 검색 결과에 차이

가 없을 것이다. 이처럼 같은 요구를 수없이 반복해도 같은 결과를 얻는 것을 ‘부작용이 없다’라고 표현한다.

HTTP에 관해 규정한 RFC2616(28페이지 칼럼 참조)에서도 GET 요청에는 부작용이 없을 것이 기대된다

는 취지의 내용이 있다. 한편 POST 메서드는 메시지 본문에 매개변수가 들어 있기 때문에 즐겨찾기를 이용

해 매개변수를 보존할 수 없다.

그러면 지금까지 살펴본 GET 메서드와 POST 메서드의 차이점을 간단히 정리해 보자(표 3-5).

GET 요청 POST 요청

이용하는 메서드 GET 메서드 POST 메서드

매개변수의 저장 장소 URL 메시지 본문

보안 낮음(URL이 타인에게 노출된다/웹 서버의 로그

에 남는다)

비교적 높음(웹 서버의 로그에 남지 않는 경

우가 많다)

매개변수의 길이 오래된 소프트웨어는 URL이 255문자 이내로 제

한돼 있을 가능성이 있다

제한 없음

매개변수의 보존ㆍ재현 용이하다 어렵다

부작용이 없을 것 기대된다 기대되지 않는다

◆표 3-5 GET 요청과 POST 요청의 차이

GET 요청과 POST 요청의 용도를 정리해 보자. 로그인 처리처럼 아이디와 패스워드 같은 기밀 정보를 송

신할 경우나 결제 처리처럼 부작용을 동반하는 처리, 쿼리 문자열에 다 담을 수 없을 만큼 대량의 정보를 송

신해야 할 경우는 POST 메서드를 사용해야 한다. 한편 이러한 조건에 해당하지 않으며 부작용이 없는 처리

는 GET 요청을 이용하는 편이 매개변수째 보존할 수 있다는 이점을 활용할 수 있다.

81

3

zz 한글은z어떻게z전달해야z하는가?

마지막으로 한국인에게 중대한 문제에 대해 이야기하고 이 장을 마치겠다. 지금까지 다룬 매개변수는 숫자

나 알파벳이었는데, 우리가 평소에 사용하는 한글은 어떻게 전달해야 할까?

간단히 생각하면 지금까지와 똑같이 하면 될 것 같다. 예를 들면 이런 식이다.

다음 URL을 실제로 브라우저의 주소창에 직접 입력해 보기 바란다.

http://www.wikibook.co.kr/webtext/do_greeting.php?name=홍길동

그러나 안타깝게도 알 수 없는 문자가 표시된다(그림 3-30).

▲그림 3-30 한글로 매개변수 전달-실패

이른바 ‘문자 깨짐’이라고 부르는 상태다. 사실 URL에서 이용할 수 있는 문자에는 제한이 있어서 그 범위

에서만 이용할 수 있다. 그 제한은 표 3-6과 같다 32 .

대문자 알파벳 A ~ Z

소문자 알파벳 a ~ z

숫자 0 ~ 9

하이픈 -

마침표 .

언더스코어 _

틸트 ˜

◆표 3-6 URL에서 이용할 수 있는 문자

GET 요청에서 이용되는 쿼리 문자열도 URL의 일부이므로 당연히 이 제한을 받는다. 요컨대 우리가 사

용하는 한글은 매개변수에 직접 사용할 수 없다. 한글뿐 아니라 공백 등도 이용 가능한 문자가 아니어서 매

개변수에 사용할 수 없다.

32 　 이것은 URI에 관해 규정한 RFC3986의 Section 2.3에 기재돼 있다.

Lesson 3 HTTP 를 이해하자

82

앞에서 소개한 구글에서도 검색 키워드를 전달하는 데 GET 요청을 사용했다. 그러나 우리가 평소에 이

용할 때는 문제 없이 검색 키워드로 한글을 지정할 수 있다. 어떻게 이 문제를 해결한 것일까? 다시 간단한

예를 통해 시험해 보자. 다음 URL을 브라우저의 주소창에 입력해 웹 페이지를 열기 바란다.

http://www.wikibook.co.kr/webtext/greeting.html

이번에는 텍스트 필드에 한글로 아무 이름이나 입력하고 ‘인사’ 버튼을 눌러 보자(그림 3-31).

▲그림 3-31 한글로 매개변수 전달

이번에는 제대로 인사를 받았을 것이다(그림 3-32)!

▲그림 3-32 한글로 매개변수 전달 - 성공

앞의 것과는 무엇이 다를까? 브라우저의 주소창에 표시된 URL을 살펴보자(예제 3-10).

http://www.wikibook.co.kr/webtext/do_greeting.php?name=%ED%99%8D%EA%B8%B8%EB%8F%99

■예제 3-10 퍼센트 인코딩된 URL

na me 매개변수의 값 부분이 뭔가 이상한 문자열로 바뀌었다. 33 이것은 텍스트 필드에 입력

된 문자열이 퍼센트 인코딩이라고 부르는 방법으로 변환된 것이다. 퍼센트 인코딩은 문자열을 문

33 　 파이어폭스 등 브라우저에 따라서는 퍼센트 인코딩된 문자열이 아니라 한글이 그대로 주소창에 표시되는 경우도 있다. 이것은 브라우저

의 기능에 따라 보기 편하게 변환됐기 때문이다.

83

3

자 코드 34 로 나타낸 것으로, 16진수로 표시한 각 값의 앞머리에 %(퍼센트)가 붙어 있기 때문에 이

렇게 부른다. 이번 예의 경우는 텍스트 필드에 입력된 ‘홍길동’이라는 문자열이 그림 3-33와 같이

“%ED%99%8D%EA%B8%B8%EB%8F%99”라는 문자열로 변환된 것이다. 35

%ED%99%8D %EA%B8%B8 %EB%8F%99

ED998D EAB8B8 EB8F99

홍 길 동

▲그림 3-33 퍼센트 인코딩된 문자열

표 3-5와 비교하면 퍼센트 인코딩된 결과가 전부 URL에서 이용할 수 있는 문자열이 됐음을 확인할 수 있

을 것이다. 이와 마찬가지로 반각 공백 등도 퍼센트 인코딩으로 변환할 수 있다.

이 같은 과정은 전부 브라우저에서 자동으로 처리되므로 우리가 신경 쓸 필요는 거의 없다.

3.5 정리

이 장에서는 웹 애플리케이션의 근간이 되는 기술인 HTTP에 관해 이야기했다. 하고 싶은 이야기는 아직 많

지만 일단 HTTP가 어떤 것이며 HTTP를 사용해 어떻게 정보를 주고받는지는 어느 정도 이해했으리라 생

각한다.

이 장에서는 다음 내용을 배웠다.

34 　 아는 사람도 많겠지만 컴퓨터 안에서는 문자가 전부 수치로 표현된다. 그 숫자로 표현된 문자를 ‘문자 코드’라고 한다. 현재는 문자 코드에

여러 종류가 있으며, 여기서는 UTF-8이라는 변환 방법으로 수치화했다. 또 문자 코드를 구성하는 숫자는 16진수로 표현된다.

35 　 윈도우에서 ‘에디터’를 이용하는 사람은 에디터에서 문자를 입력한 다음 그 위에 커서를 놓고 [Other]-[Command list...]-[Others]-

[Show character code]를 선택해 보기 바란다. 커서를 놓은 문자의 문자 코드가 표시될 것이다(이 책에서는 히데마루 에디터 영문판으

로 확인했다. 영문판은 http://www.hidemaru.interlink.or.jp/software/bin/maruo812_signed.exe(32비트), http://www.hidemaru.interli

nk.or.jp/software/bin/maruo812_x64_signed.exe(64비트)에서 내려받을 수 있다).

Lesson 3 HTTP 를 이해하자

84

yy HTTP의y기본적인y정보y송수신

yy HTTPy요청의y구조

yy HTTPy응답의y구조

yy IPy주소

yy 호스트명을yIPy주소로y변환하는y시스템(DNS)

yy DNS의y구현y방법

yy HTTP의y매개변수y전달y방법

yy GETy요청

yy POSTy요청

yy GETy요청과yPOSTy요청의y차이

yy 퍼센트y인코딩을y이용한y표현

이 장에서

배운 내용