스케일러블

웹사이트 구축

iv

•목 차•

이 책의 목적 ........................................................................................... xviii

당신이 알고 있어야 할 것 ........................................................................xix

이 책에서 사용되는 표기법......................................................................xxi

코드 예제 사용법 ......................................................................................xxi

사파리(Safari) 사용 가능 ....................................................................... xxii

연락처 ...................................................................................................... xxii

감사의 말 ................................................................................................ xxiii

독자 서비스 ............................................................................................ xxiii

01장 시작하며 1웹 애플리케이션의 정의 ....................................................................................1

웹 애플리케이션의 개발 ....................................................................................3

아키텍처의 정의 .................................................................................................4

어떻게 시작해야 할까? ......................................................................................5

02장 웹 애플리케이션 아키텍처 9계층적 소프트웨어 아키텍처 ............................................................................9

계층 기반 기술들 ............................................................................................. 13

소프트웨어 인터페이스 디자인 ..................................................................... 15

규모의 변화 ...................................................................................................... 18

소프트웨어/하드웨어 분리 ............................................................................. 20

v

하드웨어 플랫폼 .............................................................................................. 20

공유 서버 호스팅 .......................................................................................23

전용 서버 호스팅 .......................................................................................23

콜로케이션 ................................................................................................23

자체 호스팅 ................................................................................................24

하드웨어 플랫폼의 성장 ................................................................................. 25

입수용이성 및 선행 시간 ..........................................................................25

수입, 운송, 그리고 설치 ............................................................................26

공간 ...........................................................................................................26

전력 ...........................................................................................................27

네트워크 운영 센터 ...................................................................................27

연결성 .........................................................................................................28

잉여 하드웨어 .................................................................................................. 28

네트워킹 ........................................................................................................... 29

언어, 기술, 그리고 데이터베이스 .................................................................. 32

03장 개발 환경 35세 가지 규칙 ..................................................................................................... 35

소스 컨트롤 사용 ............................................................................................. 36

소스 컨트롤이란? .......................................................................................36

유틸리티 ─ ‘가지고 있으면 좋은 것’ .......................................................42

소스 컨트롤 제품들 ...................................................................................46

vi

소스 컨트롤에 넣어야 할 것들 ..................................................................55

소스 컨트롤에 넣지 말아야 할 것들 .........................................................57

한 방 빌드 ......................................................................................................... 57

직접 수정하기 ............................................................................................58

개발 환경 만들기 .......................................................................................59

릴리스 절차 ................................................................................................61

릴리스 관리 ................................................................................................64

자동화하지 말아야 할 것들.......................................................................66

이슈 관리 ......................................................................................................... 68

최소한의 기능들 ........................................................................................69

이슈 관리 소프트웨어 ...............................................................................69

관리할 것들 ................................................................................................73

이슈 관리 전략 ...........................................................................................74

CADT .........................................................................................................76

개발 모델의 확장 ............................................................................................. 77

코딩 규범 ......................................................................................................... 78

테스트 ............................................................................................................... 81

회귀 테스트 ................................................................................................81

수동 테스트 ................................................................................................82

04장 i18n, L10n 그리고 유니코드 85국제화와 지역화 .............................................................................................. 86

웹 애플리케이션의 국제화........................................................................86

웹 애플리케이션의 지역화........................................................................88

유니코드란? ..................................................................................................... 90

유니코드 인코딩 ........................................................................................92

바이트 순서 표기 .......................................................................................96

UTF-8 인코딩 .................................................................................................. 97

vii

UTF-8 웹 애플리케이션 ................................................................................. 98

출력 관리 ....................................................................................................98

입력 관리 ..................................................................................................100

PHP에서의 UTF-8 사용 ............................................................................... 100

다른 언어에서의 UTF-8 사용 ...................................................................... 102

MySQL에서의 UTF-8 사용 ......................................................................... 102

이메일에서의 UTF-8 사용 ........................................................................... 104

자바스크립트에서의 UTF-8 사용 ............................................................... 107

API에서의 UTF-8 사용 ................................................................................ 108

05장 데이터 무결성과 보안 111데이터 무결성 정책 ....................................................................................... 112

적합, 유효, 그리고 무효 ................................................................................ 113

UTF-8 필터링 ................................................................................................ 114

제어 문자 필터링 ........................................................................................... 120

HTML 필터링 ............................................................................................... 122

HTML을 사용하는 이유 .........................................................................122

HTML 입력 필터링 .................................................................................123

블랙리스트와 화이트리스트 ...................................................................124

대조 .........................................................................................................124

HTML 다루기 ..........................................................................................125

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

기본적인 결함 ..........................................................................................126

사용자 입력 결함 .....................................................................................128

태그와 괄호 대조 .....................................................................................129

프로토콜 필터링 ......................................................................................132

SQL 주입 공격 ............................................................................................... 135

SQL 주입 공격 완화 .................................................................................136

SQL 주입 공격 회피 .................................................................................138

viii

06장 이메일 145이메일 받기 .................................................................................................... 145

애플리케이션에서 이메일 수신하기 ........................................................... 148

대안적인 접근법 ......................................................................................149

MIME 형식 .................................................................................................... 150

간단한 MIME 이메일 분석 .......................................................................... 152

UU 인코딩된 첨부 파일의 분석 ................................................................... 154

TNEF 첨부 파일 ............................................................................................ 155

무선통신사업자들은 당신을 싫어한다 ....................................................... 158

문자 집합과 인코딩 ....................................................................................... 161

사용자 인식 .................................................................................................... 163

단위 테스트 .................................................................................................... 165

07장 원격 서비스 169원격 서비스 클럽 ........................................................................................... 170

소켓 ................................................................................................................. 170

HTTP 사용 .................................................................................................... 174

HTTP 요청/응답 주기 ............................................................................174

HTTP 인증 ...............................................................................................177

HTTP 요청 만들기 ..................................................................................178

원격 서비스 잉여성 ....................................................................................... 180

비동기 시스템 ................................................................................................ 184

XML 교환 ...................................................................................................... 188

XML 파싱 .................................................................................................189

REST .........................................................................................................191

XML-RPC ................................................................................................192

SOAP ........................................................................................................193

ix

경량 프로토콜 ................................................................................................ 194

메모리 사용 ..............................................................................................194

네트워크 속도 ..........................................................................................195

분석 속도 ..................................................................................................195

쓰기 속도 ..................................................................................................196

문제점 .......................................................................................................196

만들기 .......................................................................................................197

08장 병목 현상 201병목 지점 찾기 ............................................................................................... 202

소프트웨어 컴포넌트별 애플리케이션 영역 .........................................204

하드웨어 컴포넌트별 애플리케이션 영역 .............................................206

CPU 사용량 ................................................................................................... 208

코드 프로파일링 ......................................................................................210

Opcode 캐싱 ............................................................................................212

템플릿 속도 향상 .....................................................................................214

일반적인 해결책 ......................................................................................215

입출력(I/O) ................................................................................................... 216

디스크 입출력 ..........................................................................................216

네트워크 입출력 ......................................................................................221

메모리 입출력 ..........................................................................................226

메모리와 스왑 ................................................................................................ 227

외부 서비스와 블랙 박스 .............................................................................. 231

데이터베이스 ...........................................................................................231

쿼리 현장 검사 .........................................................................................232

쿼리 프로파일 ..........................................................................................235

쿼리 및 인덱스 최적화 ............................................................................236

캐시 .........................................................................................................241

비정규화 ...................................................................................................244

x

09장 웹 애플리케이션의 범위 가변성 249범위 가변성에 대한 미신 .............................................................................. 250

범위 가변성이란? .....................................................................................250

하드웨어 범위 가변성 .............................................................................251

수직적 범위 가변성 .................................................................................252

수평적 범위 가변성 .................................................................................253

지속적인 작업 ..........................................................................................256

잉여성 .......................................................................................................256

네트워크 범위 가변성 ................................................................................... 261

PHP 범위 가변성 .......................................................................................... 262

부하 분산 ........................................................................................................ 264

하드웨어를 통한 부하 분산.....................................................................266

소프트웨어를 통한 부하 분산 .................................................................267

4계층 (L4) ................................................................................................269

7계층 (L7) ................................................................................................270

대규모 분산 ..............................................................................................273

비 HTTP 트래픽의 분산 .........................................................................277

MySQL 범위 가변성 ..................................................................................... 280

저장소 뒷단 ..............................................................................................280

MyISAM ...................................................................................................282

InnoDB .....................................................................................................283

BDB .........................................................................................................284

Heap .........................................................................................................285

MySQL 복제 .................................................................................................. 285

마스터-슬레이브 복제 .............................................................................286

트리 복제 ..................................................................................................288

마스터-마스터 복제 .................................................................................290

복제 장애 ..................................................................................................292

복제 지연 ..................................................................................................293

xi

데이터베이스 파티셔닝 ................................................................................ 295

클러스터링 ...............................................................................................295

연합 ........................................................................................................297

대규모 데이터베이스 범위 가변성 .............................................................. 299

저장소 범위 가변성 ....................................................................................... 301

파일시스템 ...............................................................................................302

프로토콜 ...................................................................................................302

RAID ........................................................................................................304

연합 .........................................................................................................307

캐시 ................................................................................................................. 309

데이터 캐시 ..............................................................................................310

HTTP 요청 캐시 ......................................................................................311

10장 통계, 감시, 경보 315웹 통계 추적 ................................................................................................... 316

서버 로그 파일 .........................................................................................317

분석 .........................................................................................................318

비컨의 사용 ..............................................................................................319

분산 .........................................................................................................322

부하 분산기 ..............................................................................................324

사용자 계측 추적 .....................................................................................325

애플리케이션 감시 ........................................................................................ 327

대역폭 감시 ..............................................................................................328

장기적 시스템 통계 .................................................................................329

사용자 정의 시각화 .................................................................................345

경보 ................................................................................................................. 347

업타임 검사 ..............................................................................................348

자원 수위 감시 .........................................................................................348

xii

한계값 검사 ..............................................................................................348

저수위 검사 ..............................................................................................349

11장 API 351데이터 피드 .................................................................................................... 351

RSS .........................................................................................................352

RDF .........................................................................................................355

Atom .........................................................................................................357

기타 피드 형식 .........................................................................................358

피드 자동 탐지 .........................................................................................359

피드 템플릿 ..............................................................................................359

OPML .......................................................................................................361

피드 인증 ..................................................................................................362

모바일 .......................................................................................................365

WAP .........................................................................................................366

XHTML 모바일 프로필 ..........................................................................367

웹 서비스 ........................................................................................................ 370

API 전송 ......................................................................................................... 373

REST .........................................................................................................373

XML-RPC ................................................................................................374

SOAP ........................................................................................................377

전송 방식 추상화 .....................................................................................381

API 오용 ......................................................................................................... 383

API 키를 통한 감시 .................................................................................383

조절 .........................................................................................................384

캐시 .........................................................................................................385

xiii

인증 ................................................................................................................. 386

무인증 .......................................................................................................387

일반 텍스트 ..............................................................................................387

MAC .........................................................................................................388

토큰 기반 시스템 .....................................................................................388

전망 ................................................................................................................. 390

찾아보기...............................................................................391

xiv

•옮긴이 글•

번역 작업을 하면서 프로그래머라는 (또는 엔지니어라는) 직업은 계속해서 지식을 갈구하고 문제

의 해결에 희열을 느껴야 적성에 맞는다는 말을 곱씹어 보게 되었다. 물론 취미가 직업이 되는 순

간 더 이상 즐겁지 않다는 말처럼 직업이란 꼭 좋아서 하는 일이 아니라는 것은 이미 사회에서 만

난 많은 사람들이 나에게 무던히 각인시켜주었다. 그렇지만 몇년이 지나도 이 바닥(?)을 벗어나지

못하는 것을 보면 나도 모르게 가끔은 즐거움을 느끼고 있지 않나 싶다.

저자가 서문에서 밝힌 바와 같이 이 책은 프로그래밍에 관한 책이 아니다. 대개 기술 서적으로

는 프로그래밍 입문서 등이 많이 팔릴텐데 저자가 많은 사람들이 찾지 않을수도 있는 위험을 무

릅쓰고 저자의 경험을 통해 축적된 지식과 통찰력을 아낌없이 풀어놓은 것을 나 또한 독자의 한

사람으로서 감사의 말을 전하고 싶다. 이 책을 번역하면서 얻은 지식을 현재 직장의 실무에서 활용

했다고 한다면 믿지 못할 수도 있겠지만 정말로 사실이다. 저자와 조금은 성격이 다른 분야에서 일

하고 있지만 그만큼 저자는 이 작은 책 안에서 핵심적인 정보들을 성공적으로 담아내었다.

오래 지연된 번역 작업 동안 인내해준 위키북스와 그간 모든 투정과 짜증을 받아준 아내와 세

준에게 감사의 말을 전한다

김슬기

xv

•서 문•

내가 처음으로 만든 웹 애플리케이션은 테라니아(Terrania)였으며 사용자가 웹사이트를 방문하

면 개인 취향에 따라 가상의 세계에서 생명체를 만들고 그것의 성장을 지켜보는 애플리케이션이

었다. 이 생명체는 이리저리 돌아다니고 식물을 (또는 다른 생명체를) 뜯어 먹고 싸움도 하며 다른

사용자의 생명체와 짝짓기도 할 수 있었다. 그리고 이러한 활동들은 사용자에게 매일 두 차례씩

정리되어 메일을 통해 보고되었다.

테라니아를 웹 애플리케이션이라고 부르는 것은 조금은 과장됐다고 할 수 있으며 적어도 그 당

시에 나는 이것을 웹 애플리케이션이라고 분류하지는 않았다. 이 게임의 핵심에는 단일 장비에서

구동되는 C++로 작성된 프로그램이 있었으며 이 프로그램은 하나의 플랫(�at) 파일에서 게임 데

이터를 가져와서 게임의 모든 ‘순간’을 처리하고 다시 플랫 파일로 저장하였다. 게임을 만들면서

운영 런타임(runtime)은 서버-클라이언트 방식의 게임 아키텍처의 서버로서 동작하도록 구상하

였으며 그 당시에는 (.NET이 없었기 때문에) 네트워크를 통한 데이터 교환은 서버와 클라이언트

간의 단순한 문자열 교환에도 많은 양의 기계적인 코드를 작성해야 하는 힘겨운 작업을 해야만

했다.

웹은 많은 애플리케이션 개발자들에게 네트워크를 통해 콘텐츠를 제공할 수 있고 즉시 사용 가

능한 플랫폼을 마련해 주었고 서버-클라이언트 애플리케이션의 많은 까다로운 부분들을 제거해

주었다. 우리는 흥미로운 일을 수행하는 서버를 손쉽게 만들 수 있게 되었으며 그러한 작업보다도

더 간단한 HTML을 통해 클라이언트를 만들 수 있게 되었다. 기존의 테라니아에서 클라이언트

컴포넌트에 속했던 것들이 이제는 서버에서 동작하게 되었고 서버가 사용하는 동일한 플랫 파일

에 손쉽게 접근할 수 있게 되었다. “클라이언트” 애플리케이션이 가진 대부분의 페이지는 그저 파

일을 메모리에 올리고 사용자가 원하는 생명체를 구분하여 HTML의 정적인 정보로 출력하면 되

었다. 새로운 생명체를 만들기 위해서는 두 번째 파일에 일련의 데이터를 붙여 넣고 서버가 동작할

때마다 이 정보를 가져와서 기존의 게임에 통합하게 하였다. 이메일로 진행 상황을 보고하는 것을

포함한 모든 게임의 처리 작업은 서버 컴포넌트에 의해 수행되었으며 웹 서버의 클라이언트 인터

페이스는 이백여 줄로 작성된 게임 데이터 파일의 분석과 처리를 수행하는 간단한 C++ CGI 애플

리케이션이었다.

xvi

이렇게 만든 시스템은 꽤 만족스러웠다. 아마도 그 당시에는 아무 문제도 겪지 못했기 때문에 내

애플리케이션의 한계를 알 수 없었을 것이다. 웹 인터페이스를 통한 상호작용의 부족은 사실 게임

디자인의 일부였기 때문에 별 문제가 아니었고 사용자가 수행하는 유일한 쓰기 작업은 생명체를

창조할 때만 발생하며 게임의 남은 부분들은 모두 읽기 전용으로 진행되었다. 나타나지 않은 다른

문제점 중의 하나는 동시 사용성(concurrency)이었다. 테라니아는 전반적으로 읽기 전용으로 동작

하였고 사용자의 수와 상관없이 동시에 페이지를 만들어 낼 수 있었고 모든 쓰기 작업은 파일에

단순히 값을 덧붙이는 것뿐이므로 스핀락(spinlock) 문제 없이 충분히 빠르게 동작하였다. 게다가

두 사람이 동시에 읽기 또는 쓰기 작업을 할만큼 사용자가 많지도 않았다.

좀 더 웹 애플리케이션에 가까운 것을 작업할 때까지는 몇 년의 시간이 더 지나야 했다. 신생 미

디어 업체에서 일하면서 나는 UBB(Ultimate Bulletin Board)를 기반으로 하는 게시판의 HTML 출

력을 수정하는 일을 맡게 되었다. UBB는 펄(perl)로 작성되었고 CGI로 동작하였으며 사용자 계

정과 토론을 구성하는 게시물과 같은 애플리케이션 데이터들은 자체적인 형식의 플랫 파일로 저

장되었다. 애플리케이션의 일부 페이지들은 동적으로 생성되었으며 플랫 파일로부터 데이터를 읽

어들여서 그때그때 만들어졌다. 토론들 자체와 같은 다른 페이지들은 필요할 때마다 애플리케이

션에 의해서 정적인 HTML 파일로 디스크에 쓰여졌다. 이렇게 ‘디스크에 쓰는’ 기법은 쓰기 작업

이 적고 읽기 작업이 많이 발생하는 블로그와 같은 곳에서 여전히 사용되고 있으며 (상대적으로

매우 느린 작업일 수 있는) 디스크의 파일로 작성하는 비용보다 동적으로 페이지를 생성하는 비용

이 더 큰 경우 사용된다.

UBB의 장점은 스크립트 언어인 펄로 작성되었다는 점이었다. 소스코드를 컴파일할 필요가 없

기 때문에 개발 주기는 엄청나게 줄어들었으며 많은 시간을 낭비하지 않고 손쉽게 수정할 수 있었

다. 소스코드는 주로 사용자가 실제로 요청을 하는 종점 스크립트와 유틸리티 함수를 포함하는

두 개의 라이브러리 파일로(ubb_library.pl과 ubb_library2.pl─정말로 이름이 이랬다) 세 가지

파일로 구성되었다.

기업 고객들을 위해 UBB로 작업하는 경험이 다소 쌓인 후에는 기존 게시판 소프트웨어에 기능

을 추가하는 데 많은 시간을 보내는 조금은 이상한 사람들의 모임인 게시판 ‘해킹’ 커뮤니티에 상

당히 깊숙히 관여하게 되었다. 나는 친구와 함께 UBB 해커라는 사이트를 시작하게 되었고 그는

나중에 Infopop의 프로그래머로 일하면서 차기 버전의 UBB를 만들었다.

초반부터 UBB는 동시 사용성이 매우 좋지 못했는데 이식(portable)할 수 없는 파일 잠금

(locking) 코드를 사용함으로써 (대상 플랫폼 중 하나인) 윈도우에서 동작할 수 없었기 때문이었

다. 두 명의 사용자가 동시에 같은 글에 대한 답변을 작성하는 경우 게시글의 데이터 파일은 손상

xvii

되고 일부 데이터는 유실될 수 있었으며 시스템당 사용자의 수가 늘어가면서 데이터 손상과 경쟁

상태(race condition)가 발생할 확률이 높아졌다. 따라서 정말로 활발하게 사용되는 시스템에서는

HTML 파일을 파일로 쓰는 작업이 파일 입출력의 병목 지점이 되었고 지금은 다음으로 할 작업

이 분명히 알고 있지만 당시에는 어쩔 줄 몰랐다.

MySQL 3은 웹 애플리케이션 세상의 많은 것을 변화시켰다. MySQL 이전에는 웹 애플리케이

션 데이터를 저장하기 위해 데이터베이스를 사용하는 것이 쉽지 않았다. 기존의 데이터베이스 기

술은 (오라클처럼) 감당하기 어려울만큼 비쌌거나 (PostgreSQL처럼) 설정과 관리가 미쳐 버릴 정

도로 복잡했다. MySQL 3의 등장과 함께 많은 것들이 변화하기 시작했다. PHP 4가 널리 사용되

기 시작했고 phpMyAdmin 프로젝트가 막 시작되고 있었다. phpMyAdmin의 등장은 웹 애플리

케이션 개발자들이 FileMaker의 이상한 디자인이나 커맨드 라인에서 작업하는 데 필요한 난해한

SQL 문법에 대한 지식이 없어도 데이터베이스를 사용할 수 있게 되었다는 것을 의미했다. 나는 아

직도 테이블을 생성하고 새로운 사용자에게 접근을 허용하기 위한 올바른 문법을 기억하지 못하

지만 이제는 더 이상 알고 있어야 할 필요가 없다.

MySQL은 애플리케이션 개발자에게 동시성을 가져다 주었다. 우리는 동시에 읽고 쓸 수 있으며

데이터는 절대로 우연히 훼손되지 않는다. MySQL이 발전하면서 우리는 더 높은 동시성과 엄청난

성능을 가지게 되었으며 플랫 파일과 디스크로 작성하는 기술로 얻을 수 있는 것과는 비교도 할

수가 없었다. 인덱스를 사용하면서 임의의 데이터 집합을 선택하고 모든 데이터를 메모리에 올리

지 않아도 정렬이 가능하며 데이터 구조를 차례대로 읽어볼 수 있었다. 가능성은 무한했다.

그리고 그 가능성은 여전히 무한하다.

요즘 세대의 웹 애플리케이션은 계속해서 범위성과 기능성 그리고 상호 운영성의 한계를 계속해

서 넓혀가고 있다. 공개 API의 급증과 함께 다양한 애플리케이션을 결합하여 새로운 서비스를 창

출해내는 능력은 서비스 지향적인(service-oriented) 문화를 만들어냈다. API 서비스 모델은 우리

의 애플리케이션을 저비용으로 범위를 확장하고 유연하게 설계하는 분명한 방법을 보여주었다.

Flickr, Friendster, MySpace, 위키피디아 같이 크고 인기가 많은 웹 애플리케이션들은 매일 수

십억 개의 데이터베이스 쿼리를 처리하고 방대한 데이터를 가지고 있으며 일반적인 하드웨어로 구

성된 엄청난 규모의 하드웨어 플랫폼에서 운영된다. 구글은 대규모 애플리케이션의 대표 주자라고

할 수 있지만 다른 상대적으로 작은 (하지만 그래도 엄청나게 큰) 애플리케이션들은 웹 2.0이라고

불리는 다음 세대의 애플리케이션의 롤 모델이 되고 있다. 증가한 읽기/쓰기의 상호작용성과 네트

워크 효과 그리고 오픈 API와 함께 차세대 웹 애플리케이션의 개발은 매우 흥미로울 것이다.

xviii

이 책의 목적

이 책은 웹 애플리케이션의 디자인, 즉 웹 애플리케이션의 소프트웨어와 하드웨어의 디자인에 초

점을 맞추고 있다. 우리는 애플리케이션 아키텍처와 개발 기법 그리고 기술 동향과 유니코드 및 전

반적인 기반 시설에 대해 살펴볼 것이다. 또한 중요한 점은 이 책은 웹 애플리케이션의 개발, 즉 하

드웨어의 구축과 디자인한 소프트웨어 시스템의 구현에 관한 책이라는 것이다. 애플리케이션 디

자인 이론도 중요하지만 (그리고 전체적인 작업에 있어서 필수적인 요소이지만) 대규모 애플리케

이션 개발에 있어서 구현이 중요한 부분을 차지한다는 점을 인지하고 디자인 작업 시 항상 명심해

야 한다. 구현할 수 없는 것을 디자인한다면 우리가 올바른 것을 디자인하고 있는지 알 수 없을 것

이다.

이 책은 프로그래밍에 대한 책이 아니다. 적어도 그렇게 표방하지는 않는다. 코드 조각이나 함수

이름들을 설명하기보다 우리는 웹 애플리케이션 개발의 일반화된 기법과 방법을 살펴볼 것이다.

책 안에서 예제 코드 조각들을 보게 되겠지만 이것들은 말 그대로 예제일 뿐이다. 이 책의 대부분

의 코드 예제는 대규모 애플리케이션이나 기반 환경의 상황에서만 사용이 가능할 것이다.

우리가 살펴볼 대부분의 내용은 애플리케이션 아키텍처를 디자인하고 애플리케이션 기반 시설

을 구축하는 것과 관련이 있다. 웹 애플리케이션 분야에서는 기반 시설은 대개 하드웨어 플랫폼과

소프트웨어 플랫폼 그리고 관리 및 개발 기법의 조합을 의미한다. 우리는 이러한 요소를 조합하여

대규모 애플리케이션을 위한 매끈한 기반 시설을 구축하는 방법을 알아볼 것이다.

이 책에서 가장 많은 페이지를 차지하는 9장은 애플리케이션의 범위 가변성만을 다루고 있으

며 범위 가변적인 디자인 방법과 기존 시스템의 확장을 도울 수 있는 기술과 기법을 설명할 것이

다. 단 한 장만으로 이 분야의 모든 것을 담을 수는 없지만 (그리고 기본적인 것만을 다루기에도

이 책 전체로도 모자라지만) 일반적으로 애플리케이션들에 가장 유용할만한 방법 두 가지를 소개

할 것이다. 하지만 이것이 범위 가변성의 모든 것을 망라하는 가이드가 아니라는 점과 그 외에도

배워야 할 것이 많이 있음을 알아두기 바란다. 범위 가변적인 기반 시설에 대한 개괄적인 내용은

“Performance by Design: Computer Capacity Planning by Example”을 읽어보기 바란다.

이 책의 마지막에 가면 (10장 및 11장) 이벤트 감시과 수용성 계획을 위한 장기적인 통계 추적을

통해 웹 애플리케이션을 지속적으로 운영하는 기법들을 살펴볼 것이다. 감시와 경보는 애플리케

이션을 개발하고 이후 장시간 관리하고자 한다면 꼭 필요한 핵심 기술이다. 자체적인 컴포넌트를

가졌거나 아니면 그저 컴포넌트의 개수가 많은 애플리케이션을 감시하고 추적하는 도구를 디자인

하고 만드는 작업은 대개 애플리케이션 디자이너에게 맡겨진다. 왜냐하면 애플리케이션의 디자이

xix

너야말로 감시해야 할 대상과 경보를 발송할만한 상태가 어떤 것인지를 가장 잘 아는 사람이기 때

문이다. 우리는 시스템의 모든 컴포넌트가 동작하고 있고 올바로 동작하고 있음을 확인하는 방법

을 고안해야 할 것이다.

가장 마지막 장에서는 데이터를 공유하고 데이터 피드 및 읽고 쓰는 API를 통해 다른 애플리케

이션이 우리의 애플리케이션과 통합할 수 있는 방법을 제공하는 것을 살펴볼 것이다. 이 책 전반

에 걸쳐 컴포넌트 API를 디자인하는 방법을 살펴볼 것이지만 마지막 장은 이러한 인터페이스를

외부로 안전하게 그리고 접근 가능한 방식으로 제공하는 방법을 다룰 것이다. 또한 우리는 데이터

의 내보내기와 상호작용과 관련하여 다양하게 발전해온 표준을 살펴보고 우리의 애플리케이션에

서 이것들을 제공하는 방법을 알아볼 것이다.

당신이 알고 있어야 할 것

이 책은 처음으로 동적인 웹사이트를 만드는 사람들을 위한 책이 아니다. 이 책에서는 기본적인

내용을 다루지 않을 것이며 초보자를 위한 좋은 책들이 시중에 많이 나와 있다. 따라서 당신은 동

적인 웹사이트나 애플리케이션을 개발해본 경험이 조금은 필요할 것이다. 최소한 웹페이지를 통

해 데이터를 변경할 수 있도록 제공하고 사용자 데이터를 다뤄본 경험이 있어야 한다.

이 책은 단순히 개발자만을 위한 것은 아니지만 다양한 실용적인 예제들을 담고 있다. 이러한

예제들을 제대로 이해하려면 기본적인 프로그래밍 지식이 필요하다. 계속(continuation) 또는 변

수 커링(currying)과 같은 것을 알고 있어야 하는 것은 아니지만 간단한 제어 구조나 기본적인 폰

노이만 (입력-처리-저장-출력) 모델의 실무적인 지식은 가지고 있어야 한다.

코드 예제와 더불어 다양한 유닉스 커맨드 라인 예제를 만나게 될 것이며 따라서 리눅스 (또는

다른 유닉스 계열) 장비를 사용할 수 있다면 많은 도움이 될 것이다. 명령문을 따라해 보고 코드를

실행할 수 있는 서버를 가지고 있다면 이해하기가 쉽고 즉각적으로 실무에 사용해 볼 수도 있을

것이다. 커맨드 라인을 사용하는 것에 대한 지식이 약간은 있다고 가정할 것이므로 셸(shell)을 구

동한 명령을 수행하거나 프로세스를 죽이는 방법 등을 설명하지는 않을 것이다. 커맨드 라인을 처

음으로 접해본다면 시작하기 앞서 먼저 기초 입문서를 읽어보기 바란다. 커맨드 라인에 대한 경험

은 유닉스 기반의 애플리케이션에서는 물론 윈도우 기반의 애플리케이션에서도 점차 중요해지고

있다.

이 책에서 소개하는 기법들은 현대의 다양한 기술들에도 모두 똑같이 적용할 수 있지만 책에서

등장하는 예제와 설명은 많은 대규모 애플리케이션이 사용하는 네 가지 기반 기술로 이뤄질 것이

xx

다. PHP는 대부분의 코드 예제에서 사용할 언어이며 PHP를 사용해보지 않았더라도 C와 비슷한

언어를 사용해 보았다면 별로 걱정할 필요가 없을 것이다. C, C++, 자바, 자바스크립트, 또는 펄을

사용해봤다면 PHP에 익숙해지는 데 얼마 걸리지 않을 것이며 예제 구문들은 바로 이해할 수 있

을 것이다.

부가적인 코드와 유틸리티 작업을 위해 일부 예제에는 펄을 사용하였다. 펄은 애플리케이션의

주 언어로 사용해도 좋지만 대개 커맨드 라인 스크립트나 데이터 변조에 가장 적합하므로 관리 툴

을 개발하는 데 주로 많이 사용한다. 펄 구문도 마찬가지로 C와 비슷한 언어를 사용해봤다면 쉽

게 이해할 수 있을 것이며 다른 책을 구매할 필요는 없을 것이다.

애플리케이션의 데이터베이스 컴포넌트로는 (오라클, MySQL 서버, PostgreSQL도 소개는 하겠

지만) 주로 MySQL을 사용할 것이다. MySQL이 항상 가장 적합한 툴이 아닐 수도 있지만 다른 제

품들에 비해 많은 장점들을 가지고 있다. MySQL은 설치가 쉽고, 대개 나쁘지 않은 성능을 보여주

며, 아마도 가장 중요할 수 있는 무료라는 장점이 있다. 프로토타입을 만들거나 규모가 작은 애플

리케이션이라면 MySQL이 지닌 손쉬운 설치 방법과 관리상의 장점과 함께 phpMyAdmin(http://

www.phpmyadmin.net)과 같은 툴의 결합이 매우 매력적인 선택이 될 수 있을 것이다. 그렇다

고 해서 웹 애플리케이션을 개발할 때 다른 데이터베이스 기술들을 사용할 수 없다는 말은 아니

며 네 가지 데이터베이스 제품들은 모두 널리 사용되고 있다. 하지만 MySQL을 대규모 애플리케

이션에서도 사용할 수 있다는 것을 꼭 기억하기 바라며 인터넷상의 많은 대규모 애플리케이션이

MySQL을 사용하고 있다는 것도 알아두길 바란다. 이 책을 읽을 때 기본적인 SQL과 데이터베이

스 이론에 대한 지식과 더불어 예제 PHP 스크립트를 실행해 볼 수 있는 MySQL 서버가 있다면 유

용할 것이다.

유닉스 환경에 맞춰 모든 예제에서는 당신이 아파치 서버를 HTTP 서버로 사용하고 있다고 가

정할 것이다. 대개 아파치는 관련된 일련의 툴 중에서 가장 덜 중요한 요소이며 이 책에서는 아파

치 서버의 설정과 확장에 대해서는 (그 자체로도 하나의 큰 분야이므로) 별로 다루지 않을 것이다.

이 책을 읽을 때 아파치에 대한 지식을 가지고 있는 것은 도움이 되겠지만 꼭 필요한 것은 아니며

어떠한 웹 서버 소프트웨어에 대한 경험이라도 있다면 충분할 것이다.

소프트웨어 사용과 관련한 실무적인 경험만이 이 책을 읽기 전에 필요한 전부는 아니다. 이 책

을 잘 활용하려면 이러한 기술들의 기반이 되는 이론에 대한 실용적인 지식도 필요하다. 우리가

살펴보게 될 각 핵심 프로토콜과 표준에 대해서 (조금은 딱딱하고 이해하기 어려울 수 있는) RFC

나 표준 명세서를 인용할 것이며 대개의 경우 중요한 관련 서적들도 제시할 것이다. HTTP, TCP/

IP, MIME 그리고 유니코드에 대해서는 약간은 심도있게 다룰 것이며 그 외 다른 프로토콜은

xxi

(200개 이상의 약자로서) 지나가면서 언급만 할 것이다. 관련된 문제들을 완전히 이해하고 싶다면

프로토콜과 표준에 대해서 직접 찾아보기를 권장한다.

이 책에서 사용되는 표기법

이 책에서는 부분적으로 특별한 형태로 표기하여 눈에 띄게 하였으며 이러한 표기법은 다음과 같

은 용도로 사용되었다.

모노스페이스 (Constant width)

리터럴, 상수 값, 코드, XML 마크업에 사용되었다.

이탤릭 모노스페이스 (Constant width)

치환할 수 있는 매개 변수나 변수명에 사용되었다.

볼드 모노스페이스 (Constant width)

코드에서 설명하는 부분을 강조하기 위해 사용되었다.

알아두세요! 팁, 제안, 또는 전반적인 주석을 나타내며 예를 들어 특정 설정이 버전에 종속

적이다는 것을 알려주려고 할 때 사용한다.?

코드 예제 사용법

이 책에서 소개하는 모든 예제는 이 책의 웹사이트인 http://www.oreilly.com/catalog/web2apps

에서 무료로 내려받을 수 있다.

이 책은 목적은 당신을 돕는 데 있다. 일반적으로 이 책에서 소개하는 코드를 당신의 프로그램

과 문서에 사용해도 괜찮으며 상업적인 목적으로 코드의 상당한 부분을 사용하는 경우가 아니

라면 허가를 받기 위해 우리에게 연락할 필요는 없다. 예를 들어, 이 책에 등장하는 여러 코드를

사용하여 프로그램을 작성한다면 허락을 받을 필요가 없지만 오라일리 책에서 소개하는 예제를

CD로 판매하거나 배포하는 것은 허락을 받아야 한다. 이 책을 인용하여 질문을 답변하고 예제 코

드를 인용하는 것은 허락을 받을 필요가 없지만 이 책에서 소개한 예제 코드의 상당 부분을 당신

제품의 문서에서 사용하는 것은 허락을 받아야 한다.

xxii

출처를 밝힐 때는 보통 “범위 가변적인 웹사이트의 개발, 칼 헨더슨(Cal Henderson), 2006, 오

라일리 미디어, 0-596-10235-6”과 같이 제목, 저자, 출판사, 그리고 ISBN 번호를 기재하도록 한다.

만약 예제 코드를 사용할 때 정당한 또는 허용하는 사용 범위를 넘었다고 생각된다면

permissions@oreilly.com로 연락을 주기 바란다.

사파리(Safari) 사용 가능

마음에 드는 기술 서적의 표지에서 사파리® 사용 가능 아이콘을 봤다면 해당 서적이 오라일리의

네트워크 사파리 서재를 통해 온라인으로 제공된다는 것을 의미한다.

사파리는 e북(e-book)보다 나은 솔루션을 제공하며 수천 권에 달하는 최고의 기술 서적을 손

쉽게 검색할 수 있고 코드 예제를 잘라내고 붙일 수 있으며 각 장별로 다운로드하여 가장 정확한

최신 정보를 빠르게 찾을 수 있게 해주는 가상의 도서관이다. 사파리는 무료로 이용할 수 있으며

http://safari.oreilly.com에서 만나볼 수 있다.

연락처

이 책에 소개한 내용을 우리의 능력이 허락하는 최대한의 범위 내에서 검사하고 확인했지만 그동

안 변경된 부분을 (또는 우리가 실수를 범한 것을) 발견할 수도 있을 것이다. 오류를 발견했거나 차

후 개정판에 대해 제안할 사항이 있다면 아래 연락처로 알려주기 바란다.

O’Reilly Media, Inc.

1005 Gravenstein Highway North

Sebastopol, CA 95472

800-998-9938 (미국 또는 캐나다)

707-829-0515 (국제 전화)

707-829-0104 (팩스)

이 책에 대한 웹페이지가 제공되고 있으며 정오표와 예제 또는 그 외 추가적인 정보를 수록하고

있다.

http://www.oreilly.com/catalog/web2apps

의견을 남기거나 이 책에 대한 기술적인 문의를 하려면 다음의 이메일 주소로 연락하기 바란다.

bookquestions@oreilly.com

xxiii

다음의 웹페이지에서 메일링 리스트에 가입할 수 있다.

http://elists.oreilly.com

출판물, 컨퍼런스, 소프트웨어, 리소스 센터, 그리고 오라일리 네트워크에 관한 더 자세한 정보

는 다음의 웹사이트에서 찾아볼 수 있다.

http://www.oreilly.com

감사의 말

나는 최초의 Flickr/Ludicorp 팀원인 스튜어트 버터필드(Stuart Butter�eld), 조지 오츠(Geroge

Oates), 그리고 에릭 코스텔로(Eric Costello)에게 감사의 말을 전하고 싶다. 그들은 내가 정말 멋

진 제품을 만드는 작업에 기여할 수 있게 해주었고 사람들이 정말로 소중하게 여기는 것을 만

들 수 있는 기회를 주었다. 대규모 시스템의 디자인과 관련한 내용은 또 다른 Ludicorp 동료들인

존 올스포(John Allspaw), 세르게이 모우라초프(Serguei Mourachov), 데이썬 패티셸(Dathan

Pattishall), 그리고 애론 스트럽 코프(Aaron Straup Cope)와의 토론을 통해 얻을 수 있었다.

마지막으로, 오랫동안 고생한 나의 배우자 엘리나(Elina)에게 이 책을 집필하는 수개월 동안 그

녀에게 신경 쓰지 못했던 것을 잘 참아준 데 대해 감사의 말을 전하고 싶다.

독자 서비스

번역서와 관련한 정보나 오탈자에 관해 궁금한 점이 있다면 아래 사이트나 메일로 연락 바란다.

위키북스 홈페이지

www.wikibook.co.kr

위키북스 메일

wikibook@wikibook.co.kr

Build

ing

Scal

able

W

eb S

ites

01시작하며

디자인이나 코딩을 시작하기에 앞서 먼저 한 걸음 물러나 우리가 사용할 용어를 정의해 볼 필요가

있다. 또한 우리가 지금 하려는 일이 무엇이고 예전의 방식과 얼마나 다를지도 생각해 봐야 한다.

이미 웹 애플리케이션을 만들어 본 경험이 있다면 이 장을 건너뛰고 기술적인 내용을 다루기 시작

하는 다음 장으로 넘어가도 된다. 하지만 이 분야의 전반적인 배경에 관심이 있다면 계속해서 읽어

나가기 바란다.

웹 애플리케이션의 정의

이 책을 읽고 있는 독자라면 아마도 웹 애플리케이션이 무엇인지 잘 알겠지만 종종 용어가 잘못

사용되는 경우가 있기 때문에 여기서 분명하게 짚고 넘어 갈 필요가 있다. 웹 애플리케이션은 웹사

이트나 일반적인 데스크톱 애플리케이션이 아니다. 웹 애플리케이션은 양쪽 모두의 특징을 가지고

있고 이 둘 사이에 위치해 있다.

웹사이트가 데이터를 담은 페이지로 구성되는 데 반해 웹 애플리케이션은 데이터와 해당 데이

터와는 별도의 제공 장치로 구성된다. 웹 접근성(Web Accessibility)의 열혈 팬들이 CSS(Cascading

Style Sheet)를 통한 마크업과 스타일의 분리에 흥분할 때, 웹 애플리케이션 디자이너들은 실제 데

이터와 마크업 간의 분리에 환호한다. 웹 애플리케이션의 데이터는 (데이터로서 마크업을 포함할

수는 있지만) 마크업과 아무런 연관성이 없기 때문이다. 웹 애플리케이션의 게시판 컴포넌트는 게

시글의 내용을 마크업과 별도로 저장한다. 게시된 글의 내용을 사용자에게 보여줘야 할 때 (대개

데이터베이스인) 데이터 저장소에서 글을 꺼내와 형식에 맞춰 매개체를 통해 (대부분 HTTP를 통

2 l 스케일러블 웹사이트 구축

해 HTML 형식으로) 전달한다. 여기서 중요한 점은 꼭 HTML을 사용하지는 않아도 된다는 것이

다. 이메일을 통해 PDF 형식으로 사용자에게 전달할 수도 있다. 1

웹 애플리케이션의 페이지는 웹사이트의 페이지와 다른 의미를 가지고 있다. 웹 애플리케이션

이 현재 10개의 페이지를 가진 것처럼 보인다고 하자. 여기서 더 이상 마크업이나 소스코드의 추

가 없이 데이터 저장소에 데이터를 추가하는 것만으로도 페이지의 개수가 늘어나게 된다. 사용

자 입력에 따른 검색과 같은 기능을 통해 거의 무한대에 가까운 ‘페이지’들이 만들어지지만 새로

HTML을 작성하여 페이지를 만드는 것은 아니다. 입력받은 URL(Uniform Resource Locator)이

나 POST 데이터에 따라 몇 개의 템플릿과 로직을 통해 다수의 페이지를 동적으로 만들어 낼 수

있다. 2

일반 사용자에게 웹 애플리케이션은 웹사이트와 차이점이 없어 보일 수 있다. 블로그에서 출력

된 마크업을 보고 해당 페이지가 데이터 저장소에서 동적으로 생성되었는지 아니면 단지 정적인

HTML 문서인지 가려낼 수가 없다. 파일 확장자가 힌트가 되기도 하지만 절대적인 것은 아니며 파

일 확장자를 일부러 속이는 경우도 있다. 따라서 웹 애플리케이션은 애플리케이션의 데이터를 편

집하는 사용자에게만 애플리케이션으로 보여지는 경향이 있다. 데이터 편집 작업은 대개 HTML

인터페이스를 통해 이루어지지만 데스크톱 애플리케이션을 통해 데이터 저장소를 직접 또는 원격

으로 수정할 수도 있다.

예전에는 원격 스크립트 또는 ‘리모팅’으로 불린 Ajax(Asynchronous JavaScript and XML)의 출현

은 웹 애플리케이션의 상호작용 모델의 확장을 가져왔다. 기존에는 사용자가 페이지 기반 모델을

이용하여 웹 애플리케이션과 상호작용했으며 따라서 사용자가 서버에 페이지를 요청하고, HTTP

POST로 변경 요청을 전송한 후, 변경을 확인하거나 변경된 데이터를 보여주는 페이지를 새로 받

아야 했다. 이제는 Ajax를 통해서 사용자가 새로운 페이지를 받지 않아도 변경 사항을 전송하고

현재 페이지에서 결과를 받게 되어 데스크톱 애플리케이션의 상호작용 모델과 비슷하게 동작하게

되었다.

웹 애플리케이션의 성격은 서서히 바뀌고 있다. 초기의 상호작용이 가능한 애플리케이션으로

부터 많은 진보가 있었지만 웹 애플리케이션에는 아직도 많은 발전의 여지가 남아 있다. 구글의

Gmail과 마이크로소프트의 O�ce Live에서 보듯, 시장은 웹 애플리케이션의 장점에 더하여 웹으

로 데스크톱 애플리케이션의 장점과 기능을 함께 제공하는 방향으로 변하고 있다. 데스크톱 애플

1 　 웹 접근성이란 사용자의 신체적 또는 환경적인 상황에 상관없이 동등하게 웹에 접근하여 사용이 가능한 것을 의미하며 마크

업은 문서의 내용이 프린터나 화면에 출력되는 방식을 제어하는 일련의 문자와 기호를 지칭한다.

2 　 템플릿은 웹 애플리케이션에서 데이터와 처리 논리를 표현과 분리시켜주며 2장에서 더 자세하게 다룰 것이다.

01 시작하며 l 3

리케이션은 상호작용이 풍부하고 응답 속도가 빠르다. 웹 애플리케이션은 업그레이드가 간편하고

데이터의 이동이 쉽다는 장점 외에도 상대적으로 고객 요구사항이 적은 편이다. 상호작용 모델과

상관없이 변함없는 사실이 하나 있다. 바로 웹 애플리케이션은 웹페이지나 다른 인터페이스를 통

해 핵심 데이터들을 사용하고 변경하는 시스템이란 점이다.

웹 애플리케이션의 개발

웹 애플리케이션을 개발하려면 최소한 하드웨어 플랫폼과 소프트웨어 플랫폼이란 두 가지 주요

구성요소가 필요하다. 작고 간단한 애플리케이션은 웹서버와 데이터베이스를 한 대의 서버에서

함께 구동하는 하드웨어 플랫폼을 사용할 수 있다. 규모가 작다면 하드웨어를 애플리케이션의 구

성요소로 보지 않아도 되지만 점차 규모가 커지면 전반적인 애플리케이션 디자인에서 하드웨어가

차지하는 비중도 커진다. 이 책에서는 두 플랫폼을 이용한 애플리케이션 디자인과 개발을 광범위

하게 살펴볼 것이다. 두 플랫폼이 어떻게 서로에게 영향을 주고 또한 이 둘을 조합하여 어떻게 효

율적인 아키텍처를 만들 수 있는지 살펴볼 것이다.

소규모 환경에서 개발한 경험이 있다면 박스에서 꺼내 바로 쓸 수 있는 OOTB(out-of-the-box)

솔루션을 놔두고 왜 ‘플랫폼 디자인’으로 고민하는지 궁금할 것이다. 애플리케이션 규모가 작다면

패키지(package) 제품이 좋은 해결책이 될 것이다. 초기에 시간과 비용을 줄이고 바로 동작하며 서

비스가 가능한 애플리케이션을 얻게 될 것이다. 하지만 대규모 웹 애플리케이션이라면 바로 문제

에 부딪히게 된다. 아마존(Amazon)이나 프렌드스터(Friendster)와 같은 웹 애플리케이션을 만들

수 있는 패키지 제품은 없기 때문이다. 이러한 웹 애플리케이션과 비슷한 기능을 구현하는 일은

별일이 아닐지도 모르지만 하드웨어에 너무 많은 비용을 들이지 않으면서 수백만 개의 상품을 보

유하고 수백만 명의 사용자가 사용할 수 있게 하려면 우리가 필요로 하는 모든 조건에 정확히 부

합하는, 완전히 맞춤제작(customizing)되고 최적화된 애플리케이션을 개발해야 한다. 따라서 인터

넷에 존재하는 규모가 큰 애플리케이션은 모두 맞춤제작된 작품들일 수밖에 없다. 왜냐하면 다른

방법으로는 합리적인 예산 내에서 막대한 범위 가변성(scalability) 3 을 지닌 애플리케이션을 만들

수 없기 때문이다.

앞서 웹 애플리케이션의 핵심에는 접근과 수정이 가능한 데이터가 있다고 말했다. 우리는 애플

리케이션의 소프트웨어적 요소로서 어떻게 데이터를 저장하고(스키마), 어떻게 데이터에 접근하

3 　 범위성 또는 범위 가변성(scalability)은 애플리케이션의 규모에 상관없이 일관된 서비스와 성능을 제공할 수 있는 것을 의미한

다. 범위 대신에 규모로 바꿔 사용할 수 있다.

4 l 스케일러블 웹사이트 구축

고 변경하며(비즈니스 로직), 어떻게 데이터를 사용자에게 보여줄 것인지(상호작용 로직) 결정해야

한다. 다음 장에서는 이러한 요소들을 살펴볼 것이며 어떻게 서로에게 영향을 끼치는지 알아보고

각 요소를 좀 더 자세히 알아볼 것이다. 좋은 애플리케이션 디자인은 하향식(top-down)으로 진행

되어 소프트웨어 및 하드웨어 아키텍처를 정의하고 플랫폼의 구성요소를 정의한 뒤 각 계층에서

구현하는 기능을 정의한다.

이 책은 대규모 애플리케이션의 디자인과 개발에 실용적인 지침이 되는 것을 목표로 삼고 있다.

이 책을 다 읽었을 즈음에는 애플리케이션과 아키텍처를 디자인하고, 시스템의 범위 가변성에 대

처하며, 디자인을 구현하고 실현하는 법에 대해 잘 알게 될 것이다.

아키텍처의 정의

많은 사람들이 애플리케이션 아키텍처에 대해 이야기한다. 하지만 실제로 아키텍처란 무엇일까?

건축 설계사가 집을 설계할 때는 요구사항을 수집하고, 구현 가능한 방법을 찾아보고, 설계도를

만드는 것처럼 해야 할 일이 매우 분명하다. 그리고 건축업자가 그 설계도를 바탕으로 집을 지으면

우리는 집이 바르게 서 있고 비와 바람을 막아주고 충분한 빛이 들어올 것이라고 기대한다. 착각

을 깨트리게 되어 안타깝지만 애플리케이션을 설계하는 일은 집을 설계하는 일과 별로 비슷하지

않다.

먼저, 건물을 짓는 것이 소프트웨어의 개발처럼 이뤄진다면 건축 설계사는 기초 공사에서 내

부 시설물 설치까지 실제 건설 과정에 참여하게 될 것이다. 그가 집을 디자인하고 지을 때 먼저 두

어 개의 방을 만들고 기본적인 설비만을 갖추고 나면 집을 다 짓기도 전에 사람들이 들어와서 살

것이다. 집이 거의 다 지어질 즈음 한 무리의 사람들이 더 들어와 살 것이며 잠을 잘 수 있는 더 많

은 방은 물론 수영장과 지하실 등 더 많은 시설을 요구할 것이다. 건축 설계사가 필요한 새로운 방

들과 시설을 기존 디자인에 더하고 공사를 시작해도 거주자들은 집을 떠나지 않을 것이다. 그들은

공사 도중에 소음과 먼지에 대해 불평하면서도 계속해서 집에 거주할 것이다. 오히려 공사 중인 집

으로 더 많은 사람들이 이사를 오고 공사가 끝날 즈음에는 새 입주자들을 위해 또 변경해야 할 사

항이 생길 것이다.

좋은 애플리케이션 설계의 핵심은 처음부터 이러한 문제에 대비하는 것이다. 앞의 예에서 건축

설계사가 처음부터 크고 복잡한 집을 짓기 시작한다면 너무 지나치게 대처하는 것이다. 이럴 경우

집을 다 지을 때가 돼도 사람들은 이미 작지만 더 빨리 지어진 다른 집으로 가서 살 것이다. 집을

확장하는 일이 너무 오래 걸려도 사람들은 다른 곳으로 이사를 가버릴 것이다. 우리는 적당한 규

01 시작하며 l 5

모에서 시작하면서 가능한 적은 노력만으로 확장이 가능한 방법을 찾아야 한다.

그렇다고 해도 처음부터 모든 것이 다 맞아떨어지게 할 수 있는 것은 아니다. 대개 애플리케이션

규모를 확장할 때는 애플리케이션의 모든 부분과 기능을 다시 살펴보고 리팩터링(refactoring) 4 해

야 할 것이다. 하지만 이러한 수고는 감내할 만한 가치가 있다. 왜냐하면 애플리케이션 아키텍트가

할 일은 최초의 디자인과 이후에 변경되는 디자인을 신중하게 만들어서 각 요소를 리팩터링하는

시간을 최소화하는 것이기 때문이다.

어떻게 시작해야 할까?

처음으로 대규모 웹 애플리케이션을 디자인하고 개발을 시작할 때에는 네 가지가 필요하다. 첫째

로는 아이디어가 필요하다. 무엇을 만들지에 대한 아이디어를 떠올리는 것이 보통 가장 힘든 작

업이지만 대개 엔지니어의 역할은 아니다. 이 책에서 소개하는 기법과 기술은 소규모의 프로젝트

에도 쓸모가 있지만 더 많은 수의 개발자들이 참여하고 사용량이 큰 대규모 프로젝트에 더 적합

하다. 아직 애플리케이션을 출시하기 전이거나 확장이 필요한 상황이라면 이미 가장 어려운 부

분은 마친 것이며 이제 대규모에 적합하게 디자인을 시작하면 된다. 이미 대규모 애플리케이션을

운영 중이라도 이 책을 처음부터 끝까지 읽고 빠지거나 잘못된 부분이 없는지 확인하는 것도 좋

을 것이다.

일단 무엇을 만들지에 대한 구상이 끝났다면 그것을 만들 사람들을 찾아야 할 것이다. 작거나

중간 규모의 애플리케이션은 한 명의 개발자가 만들 수도 있겠지만 대규모 애플리케이션을 개발

하려면 대개 더 큰 팀이 필요하다. 2005년 12월 현재 Flickr 5 는 100,000줄의 소스코드, 50,000줄

의 템플릿 코드 그리고 10,000줄의 자바스크립트 코드로 이루어져 있다. 이런 규모의 애플리케

이션은 한 사람의 개발자가 관리하기 어려우며 애플리케이션의 여러 부분들에 대한 책임을 여러

명이 나누어 맡게 된다. 다수의 개발자들이 참여하는 개발 작업을 관리하는 방법에 대해서는 3

장에서 알아본다. 애플리케이션을 개발하고 배포하려면 팀의 규모와 상관없이 개발 환경과 시연

(staging) 환경이 필요하다. 개발 환경, 시연 환경 및 관련 개발 툴들에 대해서는 3장에서 자세히 알

아볼 것이며, 간단하게 말해서 웹 서버와 데이터베이스 서버를 돌릴 장비가 필요할 것이다.

4 　 리팩터링은 코드가 목표하는 결과를 바꾸지 않으면서 코드를 향상시키는 소프트웨어 기법이다. 마틴 파울러의 <리팩토링 : 나

쁜 디자인의 코드를 좋은 디자인으로 바구는 방법>(대청, 2002)를 참조하기 바란다.

5 　 Flickr는 사진 등의 멀티미디어 호스팅 사이트로서 Yahoo!가 소유하고 있다. 저자는 집필 당시 Flickr의 사진 공유 서비스의 엔

지니어링 매니저로 일하고 있다.

6 l 스케일러블 웹사이트 구축

그리고 가장 중요한 것은 개발 프로세스를 기록하고 토론할 수단이다. 너무 자세한 명세 문서는

지루하며 불필요하지만 아무것도 기록하지 않아도 심각한 문제를 야기한다. 작은 팀에서는 공책

이나 사진을 찍어서 영구적인 기록을 남길 수 있는 화이트보드로 충분할 것이다. 뭔가를 적기 위

해 컴퓨터에서 눈을 떼는 시간마저 아깝다면 위키(wiki) 6 를 이용하는 것도 좋은 생각이다. 위키는

모든 개발자가 내용을 추가하거나 수정할 수 있고 다른 개발자들의 작업 내용을 볼 수 있으므로

규모가 큰 팀에서 개발 명세와 정보를 관리하는 데 유용하게 활용할 수 있다.

전통적인 폭포수형 개발 방법론은 거대하고 단일화된 웹 애플리케이션에는 적당할 수도 있겠

지만 대부분의 웹 애플리케이션은 빠르고 점진적(iterative)인 개발 방법론이 도움이 된다. 애플리

케이션 디자인을 막다른 곳으로 몰아가는 실수는 하고 싶지 않을 것이다. 모든 결정은 잘못된 것

을 확인했을 때 빨리 회복이 가능해야 한다. 새로운 기능은 가장 기본적인 형태로 디자인하고 개

발하며, 반복을 통해 배포 전까지 또는 배포 후에도 계속해서 발전시켜 간다. 계속되는 문서 작업

에 위키처럼 가벼운 도구를 쓰면 이후에 문서를 편집하기가 쉬워진다. 6개월 동안 명세서를 만들

고 난 후 1년 동안 개발하고 싶지는 않을 것이다. 하루 동안 하나의 기능 명세를 만들고 뒤이어 이

틀 동안 구현하며 이런 과정을 이후 몇 달 동안에 걸쳐 반복하면서 기능을 향상시킨다. 작동되는

코드를 빨리 확보할수록 디자인의 문제점을 빨리 파악할 수 있으며 완전히 새로 다시 작업을 하게

되더라도 낭비하는 시간이 적어진다. 마지막으로 말할 요점은 상당히 중요하다. 그것은 한 단위의

기능에 시간을 적게 투자할수록 (대개 이러한 기능은 작고 간단한 경향이 있다) 투입된 자원이 작

기 때문에 필요하다면 쉽게 버릴 수 있다는 것이다. 개발 방법론 및 기법에 대한 더 많은 정보를 알

고 싶다면 스티브 맥코넬(Steve McConnell)의 <Rapid Development : 프로젝트 쾌속 개발 전략>

(한빛미디어. 2003)을 꼭 읽어보기 바란다.

자, 이제 펜과 위키를 손에 들고 세상을 바꿀 애플리케이션을 디자인하고 구현해보자.

6 　 위키(wiki)는 하와이 말로 “빠른”이란 의미를 가진 단어로 서로 연결된 웹페이지들을 손쉽게 만들고 편집할 수 있는 소프트웨

어로 만들어진 웹사이트를 지칭한다. 주로 협업을 위한 도구로 많이 사용된다.

01 시작하며 l 7

Build

ing

Scal

able

W

eb S

ites

02웹 애플리케이션 아키텍처

이제 코딩할 준비가 되었으면 텍스트 에디터를 열고 바로 개발을 시작하자…

아니, 잠깐만. 컴퓨터 근처에도 가기 전에 우리는 먼저 애플리케이션의 전반적인 아키텍처를 생

각하고 충분한 계획을 세워야 한다. 그러므로 일단 컴퓨터는 저 멀리 치워 버리자. 그리고 큰 화이

트보드와 마커를 가져다 놓고 먹을 거리를 준비한 다음 개발자들을 불러 모으자.

이번 장에서는 소프트웨어 개발 원칙에 대해 알아보고 어떻게 현업에서 적용할지 살펴볼 것이

다. 또한 웹 애플리케이션에서 하드웨어 플랫폼의 디자인, 계획, 그리고 관리에 대해 알아보고 이

러한 과정들이 소프트웨어 디자인과 개발에 어떠한 역할을 하는지 알아볼 것이다. 이 장이 끝날

즈음에는 작업 환경을 구축하고 코딩할 준비가 되겠지만 너무 성급하게 서두르지는 말자. 먼저 다

음의 이야기에 귀기울여 주길 바란다.

계층적 소프트웨어 아키텍처

훌륭한 웹 애플리케이션은 그림 2-1에서 보듯이 트라이플(tri�e)과 같아야 한다. 1

이 비유가 처음에는 썩 마음에 들지 않겠지만 차차 나아질 것이다. 그러니 잠시만 참고 들어주기

바란다. 여기서 말하는 트라이플은 캐나다식이 아닌 층마다 한 종류의 재료만 들어가는 영국식이

란 점이 중요하며 그 이유는 잠시 후 분명해질 것이다. 또한 트라이플을 잘 모른다고 해도 이해하

1 　 트라이플(trifle)은 디저트의 일종으로 바닥에 과일 주스에 적신 스펀지 케이크, 커스터드, 생크림, 고명(과일 등)으로 층층이 이

루어져 있다. 자세한 설명은 본문을 참조한다.

10 l 스케일러블 웹사이트 구축

기 어렵지 않을 것이라 믿는다. 일단은 트라이플이 층층이 포개어진 디저트라는 것만을 기억하면

된다.

그림 2-1 | 층층이 잘 쌓여진 트라이플 (minky sue: http://flickr.com/photos/kukeit/8295137)

트라이플의 가장 밑바닥에는 스펀지 케이크가 있다. 다른 모든 재료는 스펀지 케이크 위로 올리

며 따라서 스펀지 케이크 없이는 트라이플이라 할 수 없다. 스펀지 케이크는 다른 모든 것을 떠받

치고 있으며 트라이플의 중심이 된다. 스펀지 케이크는 크고 견고하며 다른 재료들을 지탱한다. 대

조적으로 다른 재료들은 다양하게 바뀔 수 있다.

웹 애플리케이션에서 스펀지 케이크는 지속성 저장소(persistent storage)이다. 저장소는 디스크

상의 파일이나 또는 데이터베이스의 레코드이며 우리에게 가장 중요한 자산인 데이터를 의미한다.

데이터를 검색 ·변경 · 출력하려면 먼저 데이터를 저장될 수 있는 공간이 있어야 한다. 이렇게 저장

된 데이터는 애플리케이션의 토대가 된다.

스펀지 케이크 위에는 너무나도 중요한 젤리 층이 있다. 스펀지 케이크는 트라이플의 기반이 되

며 중요하지만 본질적으로 모든 트라이플에 있어 동일하며 젤리가 트라이플의 특징을 결정한다.

손님[사용자]은 항상 젤리와 함께 스펀지 케이크를 먹는다[상호작용한다]. 젤리는 트라이플이 지

닌 독특한 특징을 가늠할 수 있게 해주는 주된 역할을 하며 아래 층에 있는 스펀지 케이크에 접근

02 웹 애플리케이션 아키텍처 l 11

할 수 있는 유일한 통로다. 스펀지 케이크와 함께 젤리는 트라이플의 종류를 결정한다. 이 두 재료

위의 다른 재료들은 모두 상호작용과 치장을 위한 것이다. 2

웹 애플리케이션에서 비즈니스 로직은 트라이플의 젤리에 해당하며 애플리케이션의 특성을 결

정하는 요소다. 데이터에 접근하고 변경하는 방식은 시스템의 동작 방식과 이를 관리하는 규칙

을 정의한다. 우리가 데이터에 접근할 수 있는 유일한 통로는 비즈니스 로직밖에 없다. 지속성 저

장소와 비즈니스 로직만으로도 애플리케이션이라고 할 수 있다. 다만 다른 사람들이 먹지[사용하

지] 않을 뿐이다. 옛날 옛적에는 비즈니스 로직을 C 언어나 코볼로 작성했다(사실이다!). 하지만 요

즘에는 이러한 언어는 덩치가 너무 커서 성능이 정말로 중요하거나 이러한 언어로 작성된 기존 코

드가 겹겹이 둘려 쌓여 있어 바꾸는 것이 너무 힘든 곳에서만 사용된다. 요즘은 비즈니스 로직을

PHP, 펄, 파이썬, 루비 등의 스크립트 언어나 기업에서 선호하는 자바로 작성해도 괜찮다.

자, 이제 다른 층들을 지탱하는 스펀지 케이크와 트라이플의 개성이 되는 젤리가 준비되었다(젤

리 안에 과일 조각을 넣어도 맛있지만 웹 애플리케이션에서는 비교할 대상이 없다). 이 상태로 디

저트라 할 수 있고 트라이플의 모양도 갖춰 가고 있지만 그래도 아직은 완전한 트라이플이라고 할

수 없다. 다음으로 필요한 것은 커스터드다. 커스터드는 젤리를 덮으면서 트라이플을 시식할 사람

이 아래 층들을 맛볼 수 있는 접촉면이 된다. 커스터드는 트라이플을 지탱하는 요소가 아니며 필

요에 따라 바꿀 수 있다. 내 경험을 소개하자면 예전에 트라이플을 만드는 도중에 커스터드를 심하

게 태웠는데 (타버린 우유는 진짜 역겹다) 젤리 위에 붓고 나서야 얼마나 지독한지 알게 되었다. 정

말 큰 실수였지만 젤리 위에 커스터드만 긁어 내고 커스터드를 다시 만들어 올렸다. 트라이플 만들

기는 결국 성공적이었다. 트라이플에서 커스터드는 본질적으로 교체가 가능한 요소다.

트라이플에서 커스터드는 웹 애플리케이션의 페이지와 상호작용 로직에 해당한다. 비즈니스 로

직은 데이터의 검색과 변경 및 저장 방식을 결정하지만 데이터의 표현과 변경 절차를 결정하지는

않는다. 데이터의 표현과 변경 절차는 페이지 로직이 맡고 있으며 사용자들이 어디에 입력하고 무

엇을 눌러야 하는지를 정한다. 페이지 로직과 상호작용 로직은 애플리케이션이 실질적으로 수행

하는 작업에 영향을 주지 않고 교체가 가능하다. 비즈니스 로직 API를 만들고(12장 참조) 이를 이

용해 여러 개의 상호작용 로직을 만들 수 있다. 트라이플을 이용한 비유는 (어느 시점이 되면 피할

수 없는 일이기는 하지만) 여기서부터 웹 애플리케이션과 조금씩 맞지 않기 시작한다. 하지만 일단

아주 큰 스펀지 케이크와 젤리가 있는 트라이플을 상상해 보자. 그리고 조각마다 서로 다른 커스

터드와 고명이 얹혀 있다고 생각해 보자. 이렇게 같은 두 개의 층을 기반으로 다양한 상호작용을

지원할 수 있다는 것이다.

2 　 [괄호]는 트라이플의 비유가 나타내는 웹 애플리케이션 용어 또는 행위다.

12 l 스케일러블 웹사이트 구축

예리한 독자라면 아직 우리가 완벽한 트라이플을 만들지 못했다는 것을 알아차렸을 것이다. 최

소한 한 층은 더 올려야 하는데 우리는 두 층을 더 올리려고 한다. 크림 없는 커스터드는 상상조차

할 수 없는 일이므로 반드시 크림을 커스터드 위에 올려야 한다. 일반적으로 식당 손님에게 커스터

드만 있는 트라이플을 내놓는 일은 없을 것이다. 경험 많은 주방장[개발자]이라면 아직 크림을 올

리지 않은 트라이플도 알아볼 수 있겠지만 손님[사용자]에게는 그저 엉망이 돼버린 음식으로만 보

일 것이다. 우리는 여태껏 쌓아온 재료들이 나타내고자 하는 의미를 손님[사용자]에게 잘 전달할

수 있는 방법이 필요하다.

웹 애플리케이션에 있어서 트라이플의 크림이 가지는 역할을 웹에서는 마크업이 담당하고 있으

며 데스크톱에서는 GUI 툴킷(Toolkit)이, 그리고 우리가 제공하는 API에서는 XML이 그러한 역

할을 맡고 있다. 마크업을 통해 사용자들은 하위 계층에 접근하며 무엇을 할 수 있는지 대략 알 수

있다. 크림 자체로 트라이플이 될 수 없고 전체적으로 봤을 때 매우 중요한 구조적 요소도 아닌 것

은 확실하지만 트라이플이 나타내려 하는 면을 전달하는 매우 중요한 목적을 가진다. 마크업 또한

크림과 같이 데이터 및 상호작용이 보여주고자 하는 의미를 사용자에게 전달한다는 점에서 같다.

반대 입장에서 보자면 브라우저 및 다른 사용자 에이전트(user agent)는 입과 미각 신경으로 비유

될 수 있으며 웹 애플리케이션을 소비하는 쪽에서 손님[사용자]에게 애플리케이션의 계층들을 의

미 있게 만들어 주는 도구라 할 수 있다.

이제 그릇[마케팅]과 손님[사용자] 외에 트라이플을 완성할 마지막 요소가 하나 남았다. 이미

시식에 필요한 모든 것들이 준비되었으므로 주방장은 여기서 만족할 수도 있겠지만 대개 소비자

는 포장과 장식에도 많은 관심을 가진다. 그렇기 때문에 층층이 쌓인 이 걸작품 위에 추가로 과일

과 초콜릿 또는 그 밖에 원하는 장식을 하게 된다. 장식 자체만으로도 의미가 있겠지만 장식의 역

할은 아래 층들을 더 돋보이게 만드는 것이다. 멋있게 장식함으로써 사람들이 작품을 잘 이해할

수 있도록 도모하고 한 입 떠먹어 보고 싶게 만든다. 장식이 엉망이라면 아마 사람들은 거들떠보

지도 않을 것이다.

코드와 공학으로 완성된 걸작 위로 장식들, 즉 표현(presentation) 계층이 오게 된다. 웹페이지에

서 표현 계층은 일부 마크업과 CSS 그리고 멀티미디어를 포함한 영역이다(여기에는 마크업 범주

에 들어가지 않는 스크립트 위젯도 때로는 포함된다). API 기반의 애플리케이션에서도 표현 계층

은 대개 같은 구성요소를 가지나 이메일의 경우에는 표현 계층이 없을 수도 있다. 물론 HTML로

작성된 이메일이라면 웹페이지와 비슷할 것이다.

자, 요점을 정리해보자. 좋은 웹 애플리케이션은 많은 층들로 구성되며 각 층은 뚜렷한 개별적인

역할을 가진다. 모든 계층들이 순서대로 잘 포개지면 좋은 애플리케이션이 완성되지만 마구 섞어

02 웹 애플리케이션 아키텍처 l 13

버리면 불량 애플리케이션 또는 트라이플의 비유를 빌자면 한 그릇 가득한 설탕 덩어리가 되어 버

리고 만다. 요리사[개발자] 입장에서는 위의 계층을 지탱하고 기반이 되는 하위 계층들이 가장 중

요하지만 손님[사용자]들은 기반이 되는 아래 층들은 당연한 존재로 여기며 위 계층으로 올라갈

수록 제품의 차별성을 결정하는 중요한 요소가 된다. 웹 애플리케이션도 이러한 차이점은 마찬가

지다. 앞으로 이러한 계층들이 어떻게 상호작용하는지 살펴볼 것이다(안타깝게도 웹 애플리케이

션은 트라이플과 같이 그저 중력에만 의존할 수는 없으며 더군다나 트라이플의 경우에도 옆으로

무너지지 않도록 신경 써야 할 것이다). 하지만 먼저 몇 가지 예를 통해 무엇을 어디에 놓아야 하는

지 살펴보자.

계층 기반 기술들

먼저 가장 단순한 최상위 계층부터 시작해보자. 웹페이지에서 표현 계층은 CSS로 구성될 것이다.

마크업을 이용해 <font> 태그에서 color 속성을 쓰는 것과 같은 방법을 이용할 수도 있겠지만 요

즘은 그런 방법은 잘 쓰지 않는 편이다. 더군다나 계층들을 잘 분리하기 위해서는 표현 계층을 마

크업과 분리할 필요성이 있고 여기엔 CSS가 제격이다.

표현 계층 아래에는 마크업이 있다. 웹에서는 주로 다양한 버전의 HTML과 XHTML 두 가

지 마크업 중에 선택을 하게 되며 각 마크업별로 몇 가지 옵션을 활용할 수 있다. 업계 내부에서

XHTML과 표준 준수에 대해 호들갑을 떨기도 하지만 잘 생각해보면 HTML4를 사용하면서도

표준을 준수할 수 있다. 다시 말해 그저 두 개의 서로 다른 표준일 뿐이란 것이다. 마크업과 그 아

래의 로직 계층을 (페이지 로직과 상호작용 로직) 분리하기 위해 템플릿(template) 3 만들기와 예

전부터 사용해온 단순한 코드 분리 기법이라는 두 가지 방법을 이용할 수 있다. 여태껏 코드와 마

크업을 마구 섞어 사용해 왔다면 코드를 분리하는 것은 올바른 길로 가는 첫걸음이 될 것이다. 모

든 출력 로직을 별도의 파일에 넣고 이들을 include() 함으로써 강력한 마크업 언어의 사용을 가

능케 하고 또한 마크업에서 분리되게 해준다. 이렇게 하더라도 두 계층이 서로 쉽게 섞이기 때문에

항상 위험성을 인식하고 코딩에 엄격한 잣대를 유지해야 한다. 출력 로직을 별도의 파일에 담아야

하는 것을 잘 알고 있더라도 애플리케이션 로직으로 스며드는 경우가 빈번하게 발생한다. 효과적

인 분리를 위해서는 표현 계층과 마크업 양쪽에서 모두 조심해서 관리해야 한다.

3 　 템플릿(template)은 웹 애플리케이션 개발에서 디자인을 로직에서 분리해내는 개념으로 (웹) 템플릿 시스템은 템플릿을 정의

하고 별개의 템플릿과 비즈니스 로직을 하나의 문서로 컴파일해주는 템플릿 엔진과 도구를 가진 프레임워크다. PHP에서는

본문에 나오는 Smarty 등이 있고 국내에는 템플릿언더바(http://xtac.net/) 등이 있으며 적용 사례로 제로보드5가 Smarty를

사용하였다.

14 l 스케일러블 웹사이트 구축

코드를 분리하는 데는 몇 가지 어려운 점이 있다. 먼저, 앞서 설명한 바와 같이 서로의 계층을 침

범하기 쉽다는 점이 있다. 하지만 엄격한 잣대를 적용함으로써 이를 방지할 수 있다. 그보다 더 문

제가 되는 것은 다른 개발자들이 각자 로직 부분과 마크업 부분을 개발하는 경우다. 템플릿 시스

템(template system)을 사용하면 로직과 마크업의 분리를 강화하고 필요한 데이터를 명시적으로 템

플릿의 범주로 내보내기(export)를 하며 마크업에서 복잡한 구문(syntax)들을 제거할 수 있다. 데

이터를 템플릿으로 명시적으로 들여오게(import) 하면 애플리케이션 디자이너들은 마크업 계층

에서 어떠한 데이터들을 보여줄 것인지 다시 한 번 생각하게 될 것이며 또한 로직 계층이 실수로

마크업 계층을 침범하는 것을 방지할 것이다. 로직 계층에서 템플릿으로 내보내는 데이터를 명확

하게 알려줘야 한다면 템플릿 개발자들은 로직 개발자들이 내보내지 않는 데이터는 사용할 수 없

다. 다시 말해 로직 개발자가 외부로 공개된 인터페이스만 그대로 유지한다면 다른 계층에 영향을

주지 않고 원하는 대로 자신의 계층 내부에서는 마음대로 수정할 수 있다는 의미다. 이것이 바로

소프트웨어 계층 분리의 핵심적인 원리이며 앞으로 이에 대해 더 살펴볼 것이다.

언어별로 좋은 템플릿 시스템들이 존재한다. PHP 개발자들에게는 Smarty 4 가 추상 템플릿 엔

진을 제공하며 템플릿들은 PHP로 컴파일되어 빠르게 실행된다. Smarty의 구문은 작고 깔끔하며

템플릿 안팎의 데이터를 명확히 분리한다. 좀 더 빠른 속도와 강력한 기능을 원한다면 Savant 5 가

있다. Savant는 PHP로 템플릿을 작성하지만 강화된 데이터 범위의 분리를 지원하며 유용한 데이

터 서식 기능을 제공하는 템플릿 시스템이다(사실 코드 쪽으로 제공되는 인터페이스는 Smarty와

동일한 형태다). 펄에서는 Template Toolkit 6 과 Mason 7 이 잘 알려져 있으며 둘 모두 확장 가능한

구문(syntax)과 명확한 데이터 범위의 분리를 제공한다. 선택은 개인 취향에 달렸지만 둘 모두 살

펴볼 만한 가치가 있다.

마크업 계층 아래에는 표현 및 페이지 로직 계층과 비즈니스 및 애플리케이션 로직 계층으로 두

개의 로직 계층이 있다. 이 계층들 사이의 분리는 매우 중요하다. 데이터의 저장과 조작을 관장하

는 규칙은 사용자가 데이터와 상호작용하는 것을 관리하는 규칙과는 논리적으로 서로 다르다. 이

들의 분리 방법은 애플리케이션의 전반적인 아키텍처 및 해당 계층을 작성할 언어에 달려 있다.

두 계층을 모두 PHP로 작성했다면 대개 서로 별도의 파일로 저장된다. 페이지 로직은 웹 루트

(root)에 .php 파일로 저장하고 비즈니스 로직은 관례적으로 웹 루트 외부에 .inc 파일로 저장한다.

4 　 http://smarty.php.net/

5 　 http://phpsavant.com/

6 　 http://www.template-toolkit.org

7 　 http://www.masonhq.com/

02 웹 애플리케이션 아키텍처 l 15

하지만 나는 이러한 명명 규칙을 좋아하지 않으며 권장하지 않는 편이다. 왜냐하면 파일명을 다르

게 저장해서 추후에 파일들이 한 곳으로 모이게 만들 수도 있기 때문이다.

두 계층을 모두 펄로 작성할 경우 전통적으로 모듈의 네임스페이스(namespace)를 이용해서 계

층을 분리하며 이것은 또한 파일들을 물리적으로 분리하는 효과도 있다. 예를 들어 페이지 로직을

MyApp::WWW::* 모듈에서 구현하고 비즈니스 로직은 MyApp::Core::* 모듈에서 구현할 수 있다. 또한

이러한 구조는 MyApp::Mobile::* 또는 MyApp::WebServices::*과 같이 다른 네임스페이스를 이용

해 별도의 상호작용 로직 계층을 쉽게 추가하게 해준다.

C++와 자바로 작성된 엔터프라이즈 비즈니스 로직과 PHP나 펄로 작성된 상호작용 로직과 같

이 서로 다른 언어로 작성된 계층 사이에서는 분리를 피할 수가 없다. 이럴 때는 계층 간의 효율적

인 소통 방법이 문제가 된다. 따라서 인터페이스 및 함수의 데이터 교환 방법은 아주 중요해지며

세밀하게 계획해야 한다. 데이터를 교환하지 않고는 애플리케이션은 아무 일도 할 수 없기 때문이

다. 7장에서는 이종(heterogeneous) 계층 간의 통신 방법에 대해 살펴본다.

애플리케이션의 가장 밑에는 지속성 저장소가 있다. 비즈니스 로직과 저장소를 분리하는 것은

특별한 어려움이 없지만 데이터베이스의 스토어드 프로시저는 문제의 소지가 조금 있다. 하지만

이 책에서 주로 사용할 기술들이 스토어드 프로시저를 지원하지 않기 때문에 여기서 다루지는 않

을 것이다. 하지만 사실 스토어드 프로시저가 웹 애플리케이션의 아키텍처에서 중요한 역할을 하

는 것은 분명하다. PostgreSQL이나 오라클을 사용한다면 스토어드 프로시저는 웹 애플리케이션

의 로직상의 핵심적인 요소가 되므로 이와 관련된 책을 읽어볼 것을 권장한다.

데이터 저장소로 어떤 제품이나 기술을 사용할지는 여기서 별로 중요하지 않다. 애플리케이션

의 형태에 따라 데이터 저장소는 아마도 데이터베이스나 파일시스템 중 하나이거나 또는 둘 모두

사용할 수도 있을 것이다. 매번 언급하지 않더라도 이 책에서는 기본적으로 MySQL을 데이터베이

스로 사용하며 POSIX형 파일시스템을 파일 저장소로 사용한다. 9장에서는 데이터 저장소의 디

자인 및 범위 가변성에 관해 설명할 것이다.

소프트웨어 인터페이스 디자인

소프트웨어를 계층으로 분리하기 위해서는 각 계층 간 인터페이스를 디자인하는 수고를 해야 한

다. 기존에 한 덩어리의 큼지막한 코드를 가지고 있었다면 이제는 비즈니스 로직과 상호작용 로직,

마크업으로 서로 다른 세 개의 덩어리로 나눠야 하며 각 계층이 서로 통신할 수 있어야 한다. 하지

만 이러한 분리로 인해 작업량이 늘어나지는 않을까, 하는 의문이 들 것이다. 아마도 그렇지는 않

16 l 스케일러블 웹사이트 구축

을 것이다. 하나로 된 코드 덩어리라도 내부적으로는 서로 통신해야 한다. 다만 로직과 마크업 사

이처럼 명확하게 별도로 구분되어 있지 않고 내부의 다른 코드들과 뒤엉켜 있을 뿐이다.

왜 굳이 계층을 분리하는 수고를 해야 할까? 예전처럼 모든 것을 한 곳에 몰아 넣는 방식으로

애플리케이션을 만들더라도 특별한 문제는 없었다. 그러나 사실 계층의 분리가 필요한 타당한 이

유들이 있고 애플리케이션의 규모가 커질수록 이것들의 중요성은 더욱 커진다. 계층의 분리는 개

발자나 팀이 서로에게 지장을 주지 않으며 서로 다른 계층을 동시에 작업할 수 있게 해준다. 게다

가 물리적으로 다른 파일들을 가지고 작업함으로써 각자 자신들이 작업하는 계층 외에는 상세히

알지 않아도 된다. 마크업 개발자는 어떻게 데이터 저장소에서 데이터를 가져와서 템플릿 시스템

에 전달하는지 알 필요가 없으며 단지 그 데이터가 마크업으로 전달되었을 때 사용하는 방법만 알

고 있으면 된다. 마찬가지로 상호작용 로직을 작업하는 개발자는 애플리케이션 로직에서 데이터의

getter/setter가 어떤 것인지 외에는 다른 정보를 알고 있어야 할 이유가 없다. 이와 같이 개발자들

이 알고 있어야 할 지식들은 자신이 작업하는 계층과 그 위/아래 계층들의 인터페이스뿐이다.

그렇다면 여기서 말하는 인터페이스란 무엇일까? 소프트웨어 계층 간의 인터페이스를 말할 때

는 자바에서의 객체지향적 인터페이스를 말하는 것이 아니다. 여기에서 인터페이스는 하나의 계

층이 다른 계층과 요청 및 응답을 교환하게 해주는 일련의 기능들을 의미한다. 데이터와 애플리케

이션 로직 계층 사이에 있어 인터페이스란 원시(raw) 데이터의 저장과 검색을 포함하며 상호작용

로직과 애플리케이션 로직 사이에서는 특정 자원(resource)의 수정을 포함한다. 인터페이스는 한

계층이 다른 계층에 어떤 작업을 요청하는지 정의하며 그 작업의 수행 방식을 정의하지는 않는다.

애플리케이션의 상위 계층들은 조금 다른 면이 있는데 마크업과 표현 계층 사이의 인터페이스

는 이미 우리가 사용할 기술에 잘 정의되어 있기 때문이다. 마크업은 link 태그나 @import 구문을

이용해서 스타일시트(stylesheet)를 가져온 후에 class와 id 속성으로 스타일을 적용하거나 스타일

시트에 정의된 태그를 통해 스타일을 사용한다. 마크업에서 style 속성을 직접 사용하는 것은 계층

간의 분리를 해치므로 피해야 한다. 이 책에서는 웹 애플리케이션 앞단(frontend)에 대해 자세히

다루지 않지만 하위 계층과 마찬가지로 상위 계층에서도 분리가 필수다. 마크업과 스타일을 분리

하면 서로 다른 팀들이 독립적으로 작업할 수 있으며 서로 다른 계층에 영향을 주지 않고 작업할

수 있다.

상호작용 로직 계층은 일반적으로 템플릿 시스템을 통해 마크업 계층과 소통한다. PHP와

Smarty의 경우 Smarty는 PHP 상호작용 로직 계층에 각종 기능들을 제공한다. Smarty의 함수를

호출하면 데이터를 템플릿에 내보내고 출력할 수 있으며 표현(presentation) 함수들을 내보내어 템

플릿에서 실행할 수 있고 템플릿 자체를 렌더링(rendering)할 수도 있다. 때로는 템플릿 출력 결과

02 웹 애플리케이션 아키텍처 l 17

를 사용자에게 전송하고 싶지 않을 때도 있다. 메일을 보내는 경우 템플릿 시스템에서 관련 템플릿

을 만들어서 데이터 및 함수를 내보내고 템플릿을 상호작용 로직 계층의 변수로 만들어 이메일을

보낼 수 있다. 데이터와 컨트롤이 단방향으로만 흐르지 않고 계층 간 양방향으로 움직일 수 있다

는 점을 상기하기 바란다.

두 계층 사이의 인터페이스는 구현 방법에 따라 아마 이해하기 쉬울 수도 있지만 디자인하기가

까다로울 수도 있다. 두 계층을 같은 언어로 구현할 때는 인터페이스는 단순히 함수들의 집합이

될 수 있다. 이 경우 인터페이스 디자인은 함수의 명명 계획과 올바른 라이브러리를 로딩하기 위한

호출 계획, 데이터를 주고받기 위한 데이터 계획으로 이뤄진다. 이 모든 계획은 애플리케이션 로직

계층의 논리적 모델에 대한 전반적인 디자인에 속한다. 이러한 디자인 결정은 “웹 애플리케이션의

우둔성(Web Application Scale of Stupidity)”이라는 잣대를 통해 생각해보는 것이 좋다.

하나의 거대한 함수 <------ 정신 건강 ------> 객체지향 프로그래밍(OOP)

이 지표는 왼쪽의 하나의 거대한 함수에서 시작하여 오른쪽의 객체지향 프로그래밍까지 하나

의 선으로 이어져 있다. 한 덩어리로 만들어진 기존의 오래된 펄 애플리케이션들이 맨 왼쪽에 위치

하고 Zope 또는 Plone 등은 오른쪽에 자리잡고 있다. 좀 더 흥미로운 모델들이 이 지표상의 이곳

저곳에 위치하고 있다. 다양한 MVC 모델들은 중앙을 기준으로 1/3 안에 분포하고 있으며 스트럿

츠(Struts)나 레일즈(Rails) 등은 이 지역 내에서도 좀 더 오른편에 위치하여 (Zope에서 벌어진 일

을 경계하듯) Zope 근처에 자리 잡고 있다. Flickr는 프레임워크가 없지만 MVC와 유사한 디자인

을 가지며 중심의 약간 왼쪽에 위치하고 있지만 애플리케이션이 복잡해지면서 점차 오른쪽으로

이동하고 있다.

이 지표 안에서 어느 위치에 디자인을 놓을지는 여러분의 취향에 달려 있다. 오른쪽으로 갈수록

관리가 쉬워지는 반면 유연성은 떨어지며 왼쪽으로 갈수록 유연성은 좋아지는 반면 관리는 어려

워진다. 어느 방향이든지 너무 치우치게 되면 애플리케이션의 최적화는 힘들어지는 반면 아키텍

처를 디자인하는 것은 쉬워진다. 최근 경향은 지표의 왼쪽에서 멀어져 가고 있으며 오른편의 중간

쯤에 위치하는 프레임워크를 이용하는 추세다. 하지만 어느 한 방향을 선택하는 것은 얻는 것과

동시에 잃게 되는 것도 있다는 점을 명심해야 한다.

아래쪽의 계층들은 물리적으로 분리되었기 때문에 잘 정의된 인터페이스를 가지고 있는 편이다

(PHP로 자체적인 데이터베이스를 구현하는 일은 거의 없듯이 말이다). 이 계층들의 인터페이스와

분리는 추상화(abstraction) 계층을 통해 이뤄진다. 비즈니스 로직은 어떻게 데이터베이스 클러스

터(cluster)에 물리적으로 연결되는지 알 필요가 없지만 실제로 연결을 수행하는 코드는 알고 있어

야 한다. 분리된 데이터베이스와 저장소 계층은 애플리케이션 로직 계층에서 명령을 받아 데이터

18 l 스케일러블 웹사이트 구축

저장소에 연결하고 명령을 수행한 후 결과를 돌려주는 작업을 수행한다. 예를 들어, 비즈니스 로

직 계층이 특정 클러스터에서 SQL을 실행하고 싶어한다면 다음과 같이 호출할 수 있다.

$result = db_query('my_cluster', 'SELECT * FROM Frobs;')

호출 후 올바른 서버에 연결하고 명령을 수행하며 결과를 돌려주는 일은 저장소 계층과 관련 코

드에 달려 있다. 쿼리가 수행되는 서버는 하드웨어 교체 등의 이유로 바뀔 수 있고 장애 극복 등을

위해 중복될 수도 있다. 또한 서버의 로그 및 벤치마크 점수가 기록될 수 있으며 (8장의 MySQL 절

참조) 그 밖에 우리가 원하는 여러 가지 일들을 수행할 수 있다. 이 예제에서는 db_query() 등의 함

수가 인터페이스가 되며 파일 저장소 계층에서는 파일명을 인수로 받아 작업을 수행하는 store_

file() 함수가 인터페이스에 포함된다. 애플리케이션 로직 계층은 수행 방법은 개의치 않으며 다

만 필요한 함수들을 호출할 수 있고 원하는 결과를 얻을 수 있는지에만 관심이 있다.

인터페이스 디자인은 웹 애플리케이션 아키텍처에서 중추적인 역할을 한다. 인터페이스는 시간

이 지남에 따라 변화할 것이고 각 계층을 작업하는 팀은 인터페이스의 변화에 따라 계속해서 서

로 대화를 유지해야 하지만 이러한 인터페이스의 변경은 개발 진행 과정에서 상대적으로 빈도가

적어야 한다. 작업을 계층 내부에서 처리할 수 있을수록 외부에 영향을 끼치지 않으며 생산성과

유연성은 높아질 것이다.

규모의 변화

대규모 애플리케이션을 개발할 때 단단한 기반을 다지고 그 위에서 개발하는 것이 중요하지만 소

규모 애플리케이션을 개발할 때는 너무 크게 기반을 닦는 것을 피하는 것 또한 마찬가지로 중요하

다. 어떠한 규모로 시작하더라도 규모에 변화를 줄 수 있는 방법은 필요하다. 이미 ‘한 덩어리’로 되

어 있는 애플리케이션을 가지고 시작해야 할 수도 있고 프로토타입에서 시작하여 대규모 애플리

케이션으로 차츰 진화해 갈 수도 있다. 프로토타입을 만들 때는 철저한 아키텍처 디자인 없이 동

작하는 제품을 단기간에 만들어 낼 수 있다. 따라서 이렇게 작은 규모나 프로토타입 형식의 애플

리케이션에서 대규모 애플리케이션으로 진화해 갈 때는 기반의 규모 변경과 구조화를 진행해야

할 필요가 있다.

이러한 작업의 첫걸음은 대개 표현 계층을 분리해 내는 것으로 시작되며 따라서 인라인(inline)

마크업을 별도의 템플릿 파일로 옮기게 된다. 이러한 표현 계층의 분리는 개별적이고 독립적인 세

개의 작업으로 나눌 수 있으며 이를 통해 한 번에 크게 변경하고 적용하는 것을 피할 수 있다. 따

02 웹 애플리케이션 아키텍처 l 19

라서 핵심적인 개발 작업을 중단 없이 진행하면서 동시에 템플릿을 별도의 계층으로 나눌 수 있게

한다. 이 세 가지 작업은 다음과 같이 매우 단순하다.

마크업 코드에서 로직 코드 분리. 첫 단계는 HTML 마크업을 생성하는 코드를 새로운 파일로 분

리해내고 운용 시 페이지가 요청되는 파일에 포함하는 작업이다. 이를 통해 로직 부분과 마크

업 생성 부분은 서로 다른 파일에 존재하게 된다. 물론 한 파일에서 여러 페이지의 마크업이

생성될 수도 있다.

마크업 코드를 페이지당 하나의 파일로 분리. 템플릿 시스템으로 전환을 고려하면 각 페이지를 비

롯해 재사용 가능한 페이지 요소들을 별도의 파일로 분리하는 것이 좋다. 이 시점에서는 이

제까지 사용한 일반적인 소스코드를 계속해서 사용하여 마크업을 생성하겠지만 각 논리적

인 마크업 요소들은 (페이지 또는 그 일부) 별도의 파일에 위치하게 된다.

템플릿 시스템으로 변환. 페이지당 하나의 파일로 준비되면 페이지들을 템플릿 시스템으로 변환

할 수 있다. 이렇게 하려면 시간이 오래 걸릴 수도 있는데 특히 로직과 마크업 생성 부분이 많

이 섞여 있을수록 많은 시간을 요하게 된다. 이미 페이지를 분리했으므로 각 페이지를 작업

하는 데 걸리는 시간이 다른 작업에 영향을 주지는 않는다.

템플릿으로 잘 분리를 마쳤다면 이제 (이미 해두지 않았다면) 스타일도 CSS 파일로 분리하는

것이 좋다. CSS는 이 책의 범위에 포함되지 않으므로 더 이상 다루지는 않겠지만 관련된 책이 시

중에 많이 있으며 인터넷에서도 많은 자료를 찾을 수 있다.

마크업과 표현 계층이 코드베이스(codebase)에서 분리되면 마지막으로 할 일이 한 가지 남아 있

다. 바로 페이지 로직을 비즈니스 로직에서 분리하는 일이다. 여기에는 몇 가지 방법이 있는데 부분

적으로나마 이 작업을 수행하기 가장 쉬운 방법은 기능별 분류다.

이 방법을 통해 애플리케이션에서 데이터를 조작하는 부분들을 살펴보고 기능별로 분류함으

로써 비즈니스 로직을 모듈화된 구조로 빠르게 디자인할 수 있다. 가장 간단한 접근법으로는 특

정 데이터베이스 테이블이나 관련성 있는 여러 테이블을 사용하는 코드를 한군데로 모으는 것이

다. 그 후 이런 테이블에 접근하여 읽거나 쓰거나 하는 모든 코드를 살펴보고 비즈니스 로직 계층

의 함수로 구성한다. Flickr에서는 포토 노트(사진에 덧글을 다는 기능)가 저장된 테이블을 읽거

나 쓰는 코드들을 하나의 모듈에 모아 놓았다. 이렇게 해두면 추후 비즈니스 로직을 매우 간단하

게 편집할 수 있다. 데이터베이스 테이블과 관련된 사항이나 여기에 저장하는 것을 바꾸고 싶다면

어디서 관련된 코드를 찾을 수 있는지 즉시 알 수 있다.

템플릿 계층을 분리하는 것과 관련하여 비즈니스 로직을 페이지 로직과 분리하는 일은 장기간

20 l 스케일러블 웹사이트 구축

에 걸친 여러 단계의 작업을 통해 진행될 수 있다. 각 기능적인 부분들을 분리함으로써 계층들은

점차 특화되며, 모든 데이터에 대한 접근은 비즈니스 로직 라이브러리에서, 상호작용 관련 작업은

페이지 운용 로직 파일에서 이뤄질 수 있도록 분리될 때까지 진행한다.

소프트웨어/하드웨어 분리

소프트웨어 엔지니어의 역할은 이름 그대로 소프트웨어를 엔지니어링하는 것이다. 데스크톱 애플

리케이션에서 메인프레임 시스템까지 무엇을 만들든지 대부분 하드웨어와 밀접한 관계가 있다. 근

래의 웹 애플리케이션 디자인은 단순한 소프트웨어의 디자인과 코딩 이상의 것을 요구하고 있으

며 하드웨어에 대한 이해도 필요하다.

소프트웨어 디자인과 하드웨어를 구분하여 다루고 따라서 핵심적인 요소들을 시스템 관리자나

사이트 운영 인력에게 맡겨버리는 것은 큰 실수다. 애플리케이션의 디자인 단계에서부터 하드웨어

관리자와 긴밀히 협력하여 업무를 진행하거나 아니면 아예 직접 하드웨어를 관리해야 한다.

그렇지만 하드웨어에 대한 관여 정도는 경우마다 많이 다르다. 소프트웨어 아키텍트로서 파일

서버 장비에서 (8장에서 다룰 백업 배터리의 존재 유무를 파악하는 정도가 아닌) 사용할 RAID

카드 종류를 결정하거나 또는 네트워크 카드의 (대역폭을 확인하는 것 정도가 아닌) 종류를 결정

할 일은 없을 것이다. 여기서부터는 웹 애플리케이션과 관련한 일반적인 하드웨어 플랫폼의 문제

점들을 살펴봄으로써 이러한 업무를 피할 수 있더라도 적어도 관련 문제를 이해하는 데 필요한 실

무적인 지식들을 알아보겠다.

하드웨어 플랫폼

대규모 웹 애플리케이션에서 소프트웨어는 중요한 요소이지만 애플리케이션의 전부라고 할 수는

없다. 디자인과 구현 단계에서 하드웨어는 소프트웨어만큼이나 중요하다. 대규모 애플리케이션의

전반적인 아키텍처는 소프트웨어 요소와 이를 실행하는 하드웨어 플랫폼을 모두 고려하여 디자

인되어야 한다. 적어도 초기에는 하드웨어 플랫폼이 웹 애플리케이션을 배치하는 전체 비용에서

큰 부분을 차지한다. 지속적인 개발 인력 비용으로 대개 소프트웨어 개발 비용이 이후로 갈수록

더 큰 부분을 차지하게 되지만 하드웨어 비용은 초반에 일시에 지출된다. 따라서 초기 비용을 낮

추고 이후 범위 확장에 대한 진로를 분명히 정의하기 위해서는 신중하게 하드웨어 플랫폼을 디자

인하는 것이 중요하다.

02 웹 애플리케이션 아키텍처 l 21

도대체… 하드웨어 플랫폼이 뭐야?

하드웨어 플랫폼이란 특정 프로세서(processor)나 버스(bus) 아키텍처를 의미하는 것이 아니

라 하나의 애플리케이션을 구성하는 다양한 장비들의 집합과 하드웨어 부속, 그리고 시스템 소

프트웨어를 통칭하여 부르는 용어다. 하드웨어 플랫폼은 작게는 하나의 OS를 구동하는 한 종류

의 장비를 의미할 수도 있지만 대부분의 경우 여러 종류의 장비와 여러 종류의 OS로 구성된다.

도널드 커누스(Donald Knuth) 8 는 다음과 같은 명언을 했다. 앞으로도 계속해서 언급할 것이니

기억해두기 바란다.

“우리는 효율성의 작은 개선에 대해 97%의 경우 아무 눈길도 주면 안 된다. 왜냐하면 때

이른 최적화는 모든 악의 근원이기 때문이다.”

이는 소프트웨어 개발에 대해 언급한 것이지만 하드웨어 플랫폼 디자인 및 전반적인 소프트웨

어 프로젝트에도 적용된다. 시작을 작고 보편적으로 한다면 결국에는 버릴 일에 시간을 낭비하지

않을 것이다.

이 원리로부터 초기 하드웨어 플랫폼 디자인에 활용할 만한 몇 가지 훌륭한 경험적 법칙(rule of

thumb)이 도출된다.

보편적인 하드웨어 구매

예전에 비슷한 규모의 비슷한 애플리케이션을 개발해본 적이 없다면 적어도 초기에는 보편

적인 하드웨어를 구매하는 것이 대개 올바른 선택이다. 바로 주문 및 구매가 가능한 보편적인

서버와 네트워크 장비를 구매함으로써 비용을 줄이고 언제든지 다른 용도로 전환할 수 있다.

프로젝트가 실패한다면 돈을 적게 낭비한 셈이고 잘 진행된다면 초기 비용의 절약으로 이후

확장에 들일 비용을 준비할 수 있다. 초기에 과다하게 견적을 잡는 경우 돈을 빨리 써버리게

되어 인력 비용이나 하드웨어 플랫폼의 확장과 같이 꼭 지출이 필요할 때 예산이 부족할 수

도 있다.

비슷한 애플리케이션을 개발한 경험이 없다면 초기에 어느 정도 규모의 데이터베이스와 디

스크, 웹 서버 등이 필요한지 가늠하기 어려울 것이다. 이런 경우 데이터베이스 서버에 8GB

8 　 도널드 커누스(Donald Knuth)는 스탠퍼드 대학의 명예교수로 알고리즘의 고전이자 아직도 완결되지 않은 “The Art of

Computer Programming” 시리즈의 저자다. 마이크로소프트의 빌게이츠가 이 책을 읽었다면 자신에게 이력서를 보내라고 했다

는 일화가 유명하다.

22 l 스케일러블 웹사이트 구축

메모리를 넣는 것이 2GB를 넣는 것과 얼마나 차이가 있는지 잘 모를 것이다. 하드웨어의 때

이른 최적화는 돈과 시간의 활용 측면에서 몹시 위험하게 작용할 수 있다. 보편적인 하드웨어

로 보수적인 플랫폼을 꾸려 시작하기 바란다.

기성 OS의 사용

이것은 말할 필요도 없겠지만 대개 애플리케이션 개발을 시작하면서 자체적인 OS를 사용할

필요는 없다. 과거에는 종종 개발 초기부터 커널 설정 값을 수정하거나 커널 모듈의 제거 등

을 통해 하나의 작업(operation)에서 CPU 사이클(cycle) 수를 최소화하는 작업에 부단한 노

력을 기울이곤 했다. 이를 통해 10%의 성능 향상을 얻을 수 있고 이 작업에 한 명의 개발자와

한 달의 시간이 필요하다고 가정해보자. 만약 서버 한 대를 더 장만하는 가격이 개발자 열 달

치의 월급보다 작다면 이러한 최적화 작업은 오히려 시간과 돈을 낭비하는 것이다. 소비한 시

간이 실제로 비용을 절감하게 되는 규모가 돼서야 (예를 들어 서버가 충분히 많고 10%의 성

능 향상을 통한 비용 절감 효과가 개발자의 투입 시간보다 큰 경우) 이런 작업이 의미가 있게

된다.

거의 모든 애플리케이션의 경우 기본 커널을 사용해도 충분할 것이다. 제공되는 커널 외에 특

별한 커널 지원이 필요할 때는 물리 주소 확장(PAE, Physical Address Extension)의 사용 또는

커널 HTTP 서버 운영과 같은 두 가지 경우뿐이며 그 외는 경험적 법칙으로 초반에는 고유

커널을 만들지 않는 편이 낫다.

기성 소프트웨어의 사용

앞서와 같은 이유로 개발에 사용할 자체적인 소프트웨어를 만드는 것 또한 시간을 낭비하

는 것이다. 대개 OS에 포함되어 있는 아파치 서버, PHP, 펄은 그대로 사용해도 충분하다

(MySQL은 예외로 별도로 MySQL.com에서 내려받는 편이 낫다). 꼭 다른 버전을 사용해야

한다면 해당 회사나 단체에서 제공하는 바이너리(binary)를 사용하는 것이 좋다. MySQL을

직접 컴파일하여 사용한다고 얻을 수 있는 이익은 거의 없으며 오히려 성능이 떨어지는 경우

가 많다. 미리 컴파일된 바이너리들은 이미 많은 개발자들이 테스트를 했으므로 직접 이러한

작업을 거치지 않고 활용할 수 있다. 또한 애플리케이션에서 버그가 발생했을 때 실제 애플리

케이션의 문제인지 아니면 서버 애플리케이션을 잘못 컴파일하여 발생한 문제인지 고민하고

싶지는 않을 것이다.

02 웹 애플리케이션 아키텍처 l 23

공유 서버 호스팅

애플리케이션이 너무 커져서 더 이상 개인 장비에서 운영하기가 어려워지면 다음 단계는 공유 서

버 호스팅 서비스를 이용하는 것이다. 공유 서버 호스팅 서비스란 대개 인터넷 서비스 제공자나 호

스팅 서비스 제공자와 같은 대규모 사업자로부터 다른 사람들과 공유하는 서버를 임대하는 것이

다. 이런 플랫폼은 프로토타입 제작과 개발 또는 작은 규모의 애플리케이션을 배포하는 데 유용하

다. 공유 서버 호스팅은 대개 매우 저렴하며 필요한 만큼의 성능을 제공한다. 데이터베이스를 사

용한다면 이를 공유하는 사람들에 따라 성능에 영향을 받을 수 있다. 웹 서버 설정을 변경하거나

제공되지 않은 모듈을 추가하는 것은 보통 불가능하다. 이런 서비스를 제공하는 대규모 업체에서

는 대개 전용 서버로 업그레이드하는 방법을 제공하므로 필요하다면 쉽게 전용 서버로 전환할 수

있다.

전용 서버 호스팅

공유 서버 호스팅 서비스의 다음 단계로는 전용 서버 호스팅 서비스가 있다. ‘전용 서버(dedicated

server)’라는 용어가 조금 혼동될 수 있어 다시 설명하자면, 특정 애플리케이션을 위한 전용 서버라

는 의미이며 이를 위한 장비와 환경은 서비스 업체에서 임대한다. 전용 서버라고 해도 서버에 접근

하기 위해서는 여전히 SSH(Secure Shell)를 통해야 하며 우리가 직접 디스크나 랙(Rack) 장비를 교

체하지는 않는다. 전용 서버 호스팅 서비스 상품은 매우 다양한데 사용자 계정을 제공하고 모든

것을 관리해주는 것부터 원격 터미널만 제공되고 OS부터 직접 설치해야 하는 상품까지 여러 종류

가 있다.

확장하고자 하는 규모에 따라 때로는 전용 서버 호스팅 서비스를 이용하는 것이 비용 대비 가장

효과적일 수 있다. 팀 내부에 시스템 관리자가 있어야 할 필요가 없고 개발자의 시간을 서버를 구

성하는 업무에 투자할 필요도 없다. 하지만 이 경우 효율성은 호스팅 서비스 업체의 네트워크 운

영 센터와 (그리고 그 직원들과) 당신과의 관계에 따라 달라진다. 업체에 따라 제공되는 서비스가

매우 다르므로 관련 경험이 있는 지인들이 있다면 추천을 받아 보는 것이 좋다.

콜로케이션

정말로 엄청나게 규모가 큰 애플리케이션을 만들 생각이라면 콜로케이션(Collocation)은 지속적으

로 유지할 수 있는 방법은 아니다. 여러분이 개발하는 애플리케이션이 얼마나 성장할지는 모르겠

24 l 스케일러블 웹사이트 구축

지만 세계적인 규모의 애플리케이션들은 수십만 대의 서버를 운용한다. 여러분이 선택할 수 있는

방법은 실질적으로 전용 서버 호스팅이나 콜로케이션으로 두 가지이며 규모가 작거나 신생 기업의

경우 대개 콜로케이션으로 시작한다. 콜로케이션 서비스는 물리적인 장소와 전력, 네트워크 대역

폭을 제공하며 본인이 서버를 제공해야 하고 관리도 해야 한다.

업체에 따라 제공되는 콜로케이션 서비스는 매우 다양하다. 제공하는 것이 거의 없는 곳도 있으

며 서버와 모니터링 서비스를 제공하고 장애 진단을 전화로 서비스하는 업체도 있다. 네트워크 모

니터링과 리부팅 같은 기본적인 서비스는 모든 업체들이 제공하지만 계약 조건에 따라 이러한 서

비스도 건당으로 비용이 부가되기도 한다.

콜로케이션을 선택한다면 매우 큰 위험성을 떠안을 수 있으므로 쉽게 결정해서는 안 된다. 업체

를 바꾸는 것은 가능하긴 하지만 매우 험난한 작업이 될 것이 분명하므로 가능한 피하는 것이 좋

다. 콜로케이션을 몇 번 교체해본 경험이 있다면 아주 불량한 업체와 계약 중이라도 이전에 필요한

비용과 수고 때문에 업체를 바꾸는 것을 꺼릴 수 있다. 사실 일부 콜로케이션 서비스 업체들은 이

런 두려움을 악용하기도 한다. 호스팅 업체를 선택할 때와 마찬가지로 선정 대상에 오른 콜로케이

션 업체들을 이용해 본 사람들의 의견을 들어보길 권장한다. 특히 비슷한 규모의 애플리케이션을

개발해본 분들과 이야기를 나누어 보길 바란다. 일부 콜로케이션 업체들은 작은 플랫폼을 전문으

로 하여 대규모 플랫폼에 대한 지원이 미비하며 또 다른 콜로케이션 업체들은 오직 대규모 플랫폼

에 대한 서비스만을 전문으로 하는 곳도 있다.

자체 호스팅

몇천 대의 서버를 운용하게 되면 자체적인 데이터 센터를 보유하는 편이 나을 것이다. 데이터 센

터를 운영하는 일은 결코 간단하지 않으며 전용 시설, 24시간 네트워크 운영 센터, 운영 인력, 다

수의 예비 전력 연결 시설, 대규모의 UPS, 전력 필터 및 발전 설비, 화재 진압 설비, 그리고 백본

(backbone) 제공자와 다중 피어링(peering) 계약 등이 필요하다.

소규모라도 자체 호스팅을 하는 것이 솔깃할 수도 있을 것이다. 얼핏 생각하면 사무실로 전용 회

선을 임대하고 서버를 운영하는 것은 간단해 보일지도 모른다. 하지만 대개 이것은 좋지 않은 생각

이자 피해야 할 생각이며 대개 많은 돈을 낭비하게 만들고 다른 방법에 비해 더 많은 난관에 봉착

할 것이다. 근처에 콜로케이션 시설이 없을 경우 관리를 해주는 호스팅 서비스를 이용하거나 또는

콜로케이션 시설 근처에 거주하는 시스템 관리자를 채용하는 방법을 고려해보길 바란다. 자체 호

스팅은 일정 수준을 넘어가게 되면 대역폭 임대 비용이 너무 과다해지거나 (전용 회선의 상향 대

역폭은 하향 대역폭보다 대개 훨씬 비싸다) 정전 등으로 운영에 어려움이 생길 수 있다. 집에서 전

02 웹 애플리케이션 아키텍처 l 25

화선을 실수로 잘라서 며칠간 인터넷을 못쓰는 것은 조금 귀찮은 일일 뿐이지만 이런 일이 회사에

서 발생한다면 사업에 위기를 맞게 될 것이다.

자체 데이터 센터의 설립과 운영은 이 책의 범위를 벗어난다. 하지만 애플리케이션이 그렇게 큰

규모로 성장해서 데이터 센터를 고려해야 할 상황이 되기를 기원한다.

하드웨어 플랫폼의 성장

대규모 애플리케이션을 위해 하드웨어 플랫폼을 디자인하고 구현하는 것도 어려운 문제지만 이미

개발된 플랫폼을 확장하는 것은 또 다른 종류의 문제들을 제기한다. 대규모 애플리케이션의 하드

웨어 플랫폼은 소규모 플랫폼과는 확연히 다르다. 100,000명의 사용자를 지원하는 전용 서버 한

대로 소규모 애플리케이션이나 프로토타입을 운영한다면 (현실적이지 못하지만) 선형 비례로 가

정했을 때 동일한 애플리케이션이 천만 명을 지원하려면 100대의 서버가 필요하다. 100대의 장비

로 구성된 서버 플랫폼을 관리하는 일은 단 한 대를 운영하는 것보다 훨씬 더 많은 계획과 준비가

필요하며 추가적인 요구사항들을 만족시켜야 한다.

하드웨어 규격을 정하고 구매하는 책임은 (특히 작은 규모의 팀일 경우) 대개 수석 아키텍트나

개발 팀장에게 주어지며 규모가 더 크다면 운영 관리자가 이런 책임을 맡게 된다. 규모가 작은 플

랫폼에 전담 관리자를 고용하는 것은 지나친 감이 없지 않다.

순수하게 개발만 하다가 하드웨어 플랫폼까지 책임지게 되면 바로 잘 드러나지 않고 문제가 될

소지가 있는 요소들을 조심해야 한다. 앞으로 이러한 요소들을 살펴보고 초기 구축 시 주로 나타

나는 문제점들을 살펴보자.

입수용이성 및 선행 시간

하드웨어 구매처를 선택할 때는 규격과 가격에 대해 고려하는 것 외에도 동일 제품을 추후에 더

확보해야 할 때 어려움이 없을지 확인해야 한다. 특정 RAID 컨트롤러와 같이 한 종류의 하드웨어

만 사용할 계획이라면 제품을 더 주문하는 것이 용이한지 확인해야 한다. 따라서 판매처가 해당

제품을 재고로 확보하고 있는지 아니면 제조 업체로부터 물건을 받는 데 선행 시간(Lead Time)이

어느 정도 걸리는지 확인해야 한다. 제품을 제조하고 배송 받기까지 3개월이나 걸리고 이로 인해

프로젝트가 지연되기를 바라지는 않을 것이다.

또한 구매처에 따라 신뢰성이나 제품의 단종과 같은 문제가 있을 수 있다. 아주 특정한 하드웨어

26 l 스케일러블 웹사이트 구축

가 필요한 핵심 부품이라면 제조사와 연락하여 해당 제품의 생산 계획이 어떻게 되는지까지 확인

할 필요가 있다. 만약 제품의 단종 계획을 미리 알고 있다면 갑자기 몇십대의 장비를 구매하기 위

해 서두르는 일은 없을 것이다. 이런 점에서 같은 구매처를 이용하는 사람들을 찾아보고 그들의

경험을 들어보는 것도 좋다. 왜냐하면 실제 경험을 대신할 수 있는 것은 없기 때문이다.

수입, 운송, 그리고 설치

해외에서 호스팅을 할 경우 대부분의 하드웨어를 수입해야 할 것이다. 하드웨어를 수입하는 데는

많은 시간과 비용이 든다. 하드웨어에 대한 관세로 상당한 금액의 추가 경비가 발생하므로 주문 전

에 예산을 세워야만 한다. 세관을 통해 하드웨어를 들여오는 것은 작은 일이 아니며 대개 운송하

는 데도 며칠을 더 보내야 한다. 국경을 넘어 하드웨어를 들여올 때 얼마나 시간이 걸릴지를 다루

는 경험 법칙은 없지만 세관 절차를 숙지해 두면 장기적으로 많은 시간을 절약할 수 있다.

국내에서 하드웨어를 구매하더라도 구매처가 하드웨어를 수입하여 판매할 수도 있다는 점을 인

지하고 이에 맞춰 선행 시간을 적절히 조절해야 한다. 구매처와 좋은 관계를 유지하여 그들의 재고

량과 공급처 및 구매 계획을 파악해 놓으면 유용할 것이다. 대개 구매처로부터 하드웨어를 익일 배

송받을 수도 있지만 재고가 없다면 한 달 이상을 기다려야 할 수도 있다.

좋은 콜로케이션 시설은 하드웨어를 구매처에서 바로 데이터 센터로 배송할 수 있게 해주며 설

치 이전에 예비 시설에 보관해 주기도 한다. 하드웨어를 집이나 사무실로 배송받고 다시 최종 목적

지로 옮기려면 많은 시간과 노력이 든다. 이런 방법은 하드웨어 플랫폼이 성장하면서 점차 불편해

지며 어느 시점에 가서는 아예 관리가 불가능해진다. 커다란 하드웨어 플랫폼을 놓을 장소를 마련

하고 필요한 전력을 공급하는 일은 작은 사무실에서는 감당하기 어렵다. 따라서 콜로케이션 시설

을 선택할 때 예비 공간이 있는지 확인하는 것이 좋다.

공간

작은 호스팅 시설에서 애플리케이션을 런칭(launching)했다면 추후에는 물리적 공간이 큰 문제가

될 것이다. 처음에 8단 랙(rack)의 한 단만을 사용했다면 나중에 필요 시 랙의 반 이상 또는 전체

를 사용할 수 있는지 확인해야 할 것이며 또한 이후에 2개 또는 30개의 랙으로 확장할 수 있는지

도 파악해야 한다. 거래처와 계약을 하기 전에 이러한 질문의 답을 받아 놓아야 한다. 여기에 더해

확장이 가능하다면 나란히 인접한 랙들을 사용할 수 있는지 또는 그렇지 못하다면 나란히 있지

않은 랙들을 서로 케이블로 연결해 줄 수 있는지 물어봐야 한다. 텔코(telco)나 이축(two-post) 또는

사축(four-post)과 같이 제공되는 랙 마운트(mounting)의 종류는 무엇인지 그리고 사용 중인 하드

02 웹 애플리케이션 아키텍처 l 27

웨어에 적합한지 파악해야 하며 랙 마운트와 (어떤 랙들은 길게 생긴 서버들을 넣을 수 없기 때문

에) 랙의 깊이를 확인하는 것 또한 중요하다.

데이터 센터 이전보다 힘들고 많은 시간이 필요하며 스트레스를 주는 작업은 별로 없다. 특히 애

플리케이션이 성장하고 있고 수용량(capacity)이 모자라기 시작한다면 말이다. 데이터 센터를 이전

할 때에는 애플리케이션이 이 기간 동안 양쪽의 데이터 센터에서 운영되기 때문에 추가적인 하드

웨어가 필요하다. 따라서 많은 비용이 필요하므로 이전을 피할 수 있는 방법이 있는지 알아보는 것

이 좋다.

전력

공간과 더불어 플랫폼의 예상 성장 속도에 맞춰 UPS가 지원되는 충분한 전력 공급 여부를 확인

하는 것 또한 중요하다. 서버의 전력 사용량은 암페어(ampere)로 측정되며 한 랙은 대개 15암페어

정도를 사용한다. 40개의 1U 서버로 구성된 랙이라면 100암페어 이상을 간단히 사용해 버린다.

고속 디스크를 많이 사용한다면 더 많은 전력을 소비할 것이며 따라서 랙에 추가적인 전력 공급을

위해 설치 비용과 추가적인 전력 사용료 및 데이터 센터의 수용량 정도를 확인해야 할 것이다.

필요한 만큼 서버를 구매해도 만약 데이터 센터에 전력 공급이 부족하다면 사용할 수 없을 것이

다. 지속적인 성장에 대비하여 전체 예산과 수용량 계획을 세울 때 전력에 대한 준비도 포함해야

한다.

네트워크 운영 센터

네트워크 운영 센터는 업체마다 제공하는 서비스가 매우 다양하며 대개 가격에 따라 차별화된 서

비스를 제공한다. 하지만 적어도 네트워크 운영 센터는 자체 인프라를 모니터링하고 애플리케이션

과 관련된 문제가 생기면 경고해 줄 것이다. 이러한 경고는 DOS 공격과 같이 사용 중인 설비에 관

련된 특정한 문제와 더불어 일반적인 네트워크 끊김과 라우팅 문제를 포함한다.

서버를 리부팅해주는 것처럼 네트워크와 관련 없는 일반적인 서비스는 대개 기본 서비스로 제

공된다. 하지만 문제 있는 하드웨어를 진단하고 디스크를 교체하는 것과 같이 좀 더 작업이 필요한

서비스는 기본 서비스로 제공되지 않는다. 이러한 서비스는 별도로 제공되며 해당 비용을 전체 비

용에 포함하거나 또는 건당 비용을 청구하기도 한다. 일부 업체들은 일정 건수까지는 무료로 해주

고 이 횟수를 넘을 때는 비용을 청구하기도 한다. 하지만 시설의 근접성에 따라 다른 문제들에 비

해 별로 큰 문제가 아닐 수도 있다. 그렇지만 시설을 선택할 때 이러한 요소들을 참고해서 결정해

야 한다.

28 l 스케일러블 웹사이트 구축

연결성

업계의 최상위 시설이라면 고속 인터넷 백본(backbone)망에 다중 피어링(peering)이 되어 있다. 업

체들이 제공하는 네트워크 연결은 종류가 다양하다. 대개는 랙에 100Mbps(100 baseT) 이더넷

케이블을 연결하며, 필요하다면 기가비트 이더넷(1000 baseT) 또는 광(�ber-optic) 케이블의 경우

1000-baseSX로 쉽게 전환할 수 있는지 확인해야 한다.

외부 네트워크 장비가 지원한다면 백업 라인을 랙에 연결하는 것이 좋으며 이는 데이터 센터에

서 라우팅 문제가 발생했을 때 유용하다. 서비스 제공과 별도로 여분의 라인을 관리용으로 가지고

있는 것도 좋다. 다시 말하지만 제공되는 서비스는 업체에 따라 다르며 따라서 사전에 조사를 해

두는 것이 좋다.

잉여 하드웨어

비즈니스 연속성 계획(BCP, Business Continuity Planning)은 잉여성 계획(redundancy plan)의 중심

을 차지한다. BCP는 핵심 서비스의 일부 또는 전체적인 장애로 인한 위험을 관리하는 방법론이다.

웹 애플리케이션에서는 소프트웨어 및 하드웨어의 장애와 공격 또는 재해 시 비즈니스의 연속성

을 보장하는 것을 의미한다. 소규모에서는 기술적인 용어들을 대개 무시해도 괜찮겠지만 기본적

으로 BCP는 재해 복구에 대한 확고한 계획을 갖는 것을 의미한다.

다양하게 발생할 수 있는 재해의 정도에 따라 다양한 수준의 BCP가 적용된다. 매우 기본적인

수준으로는 하나의 하드 디스크 고장에 대처하는 것이며 중간 정도의 수준에는 여분의 네트워크

장비를 준비하는 것이 있다. 핵심 애플리케이션을 여러 대륙에 위치한 다수의 데이터 센터에서 운

영하는 내용을 담은 BCP라면 가장 높은 수준이 될 것이다. 이를 통해 전 세계의 사용자에 대해

응답 시간을 줄이는 효과도 있지만 더 중요한 것은 하나의 데이터 센터가 운영을 중단했을 때에도

서비스가 지속적으로 제공될 수 있다는 점이다. 이러한 장애는 실제로 종종 발생하곤 한다.

이중으로 데이터 센터를 운영해도 장애 극복(failover)을 할 수 없다면 모든 하드웨어에 대해 최

소한 하나 이상의 여분을 준비하거나 또는 필요하다면 (예를 들어 100개 이상의 디스크를 사용하

는 플랫폼에서 하나의 디스크만을 준비해 놓는 것은 매우 부족하기 때문에) 하나 이상의 여분을

준비하는 것은 좋은 방안일 것이다. 또한 모든 곳에서 장애가 발생할 수 있고 결국에는 모든 곳에

서 장애가 발생할 수 있음을 인식하는 것이 중요하다. 일반적으로 장애가 많이 발생하는 하드디스

크부터 대개 교체를 고려하지 않는 부품인 전력 케이블, 네트워크 케이블, 네트워크 스위치, 전원

02 웹 애플리케이션 아키텍처 l 29

공급 장치, 프로세서, 메모리, 라우터, 랙 포스트(post)까지 모든 것을 준비해야 한다.

9장에서 범위 가변성을 살펴보면서 하드웨어뿐 아니라 디자인 관점에서 잉여성 계획을 더 자세

히 알아보겠다.

네트워킹

최근에는 전통적인 OSI 7 계층 모델보다 좀 더 쉽게 이해할 수 있는 TCP/IP 4 계층 모델을 이용하

는 추세이다. 애플리케이션 아키텍처에서 네트워크의 역할을 이해하려면 이 네 개의 계층에 대해

이해해야 하며 각 계층이 어떻게 서로 상호작용하는지 알아야 한다. 그림 2-2에서 보듯 이 모델은

4개의 계층이 단순하게 쌓인 형태로 이루어져 있다.

5:세션, 6:표현, 7:응용

4:전송, 5:세션

3:네트워크

1:물리, 2:데이터링크

응용(Application)

전송(Transport)

인터넷(Internetwork)

링크(Link)

HTTP

TCP

NIP

이더넷

OSI 계층 TCP/IP 계층 예시

그림 2-2 | TCP/IP 스택

맨 아래 계층은 무선 신호 및 연선(UTP) 내의 파동과 같은 신호가 이동하는 경로인 물리적인 매

개체와 더불어 이더넷 프레임(Ethernet frame)과 ATM 셀(cell) 등의 데이터 인코딩 방식 모두를 포

함한다. 인터넷 계층에서는 프레임과 셀 등이 잘 알려진 IP 패킷(packet)으로 묶여서 서로 다른 네

트워크 간에 전송된다. 인터넷 계층 위로는 전송 계층이 있으며 TCP는 데이터가 지점(node) 간의

전송을 보장하며 UDP는 이를 보장하지 않는다. 마지막 계층은 하위의 다른 계층들을 활용하여

의미를 부여하며 애플리케이션에 화려한 일을 가능케 한다. 계층들이 차례로 쌓여 있기 때문에

데이터는 개념적으로 연결된 계층 사이로만 이동할 수 있다. 간단히 예를 들어 두 대의 컴퓨터가

같은 네트워크에 있을 때 메시지를 보내면 그림 2-3처럼 데이터가 이동할 것이다.

30 l 스케일러블 웹사이트 구축

HTTP

TCP

IP

이더넷

HTTP

TCP

IP

이더넷

그림 2-3 | TCP/IP 스택을 통한 HTTP 메시징

메시지는 계층의 제일 위에서 시작되며 이 예에서는 HTTP 요청이 계층을 따라 내려가면서 점

차 커다란 용기(encapsulation)에 싸인 상태로 가게 될 것이다. 따라서 IP 패킷은 HTTP 요청을 감

싸고 이더넷 프레임은 IP 패킷을 감싸게 된다. 메시지가 맨 밑의 계층을 지나가면서 네트워크를 통

해 빛과 전기 및 전자파 또는 다른 형태의 신호로 전송되어 목적지의 제일 하위 계층에 전달된다.

메시지는 목적지의 계층을 따라 올라가면서 메시지를 감싸고 있던 용기들이 하나씩 제거되고 가

장 상위 계층에 도착하면서 HTTP 요청만이 남아 전달된다. 이 아키텍처의 핵심은 각 계층이 자

신의 아래 계층에 무엇이 있는지 몰라도 된다는 점이다. HTTP 요청을 할 때 IP가 어떻게 작동하

는지 몰라도 되고 IP 패킷을 만들면서 어떻게 패킷이 전기적 신호로 변환되어 구리선을 통해 전송

될지 걱정할 필요가 없다.

웹 서버와 클라이언트들은 모델의 네 개의 계층 모두를 활용하지만 네트워크 장비는 한 계층 또

는 네 계층 모두에서 동작할 수도 있다. 요즘에는 잘 볼 수 없게 된 중계기(repeater)나 허브, 스위치

는 가장 아래의 계층에서만 동작한다. 라우터는 하위 두 개의 계층만 사용하거나 또는 위의 계층

들까지 사용할 수 있다. 9장에서 살펴볼 부하 분산기(load balancer)는 아래의 세 계층에서 (OSI 모

델이라면 계층 4 또는 L4에서) 작동하거나 또는 네 계층에서 모두 (OSI 모델에서는 계층 7에서)

동작한다. 그림 2-4에서 보듯 이러한 네트워크 장치들도 마찬가지로 메시지는 사용 가능한 계층

끝까지 전달된다.

일반적인 IP 라우터에서 메시지는 네트워크 매개체를 통해 들어 오고 전기적 신호에서 이더넷

프레임으로 변환되며 이어서 이더넷 프레임에서 IP 패킷을 뽑아내고 위의 계층으로 올려 보낸다.

라우터는 이렇게 올라온 IP 패킷의 헤더를 보고 (IP 주소가 동일 네트워크가 아니라면) 라우팅이

필요한지 판단한다. 패킷을 라우팅해야 하면 먼저 올바른 헤더를 넣고 아래 계층으로 내려 보낸다.

링크 계층에서는 새로 받은 패킷을 프레임에 다시 싸고 네트워크를 통해 목적지로 전송할 수 있도

록 매개체로 내려 보낸다.

02 웹 애플리케이션 아키텍처 l 31

IP

이더넷

HTTP

TCP

IP

이더넷

HTTP

TCP

IP

이더넷

라우터 서버클라이언트

그림 2-4 | 라우팅을 거친 TCP/IP 스택을 통한 메시지 전송

네트워크 장비 자체와 이들이 동작하는 계층을 구분하는 것은 중요하며 특히 이를 통해 스위치

와 라우터, 부하 분산 장치의 서로 다른 역할을 이해하는 것이 중요하다. 시간을 들여 기본적인 네

트워크 지식을 갖추고 어떻게 이러한 계층들과 장비들이 구성되고 작동되는지 이해할 필요가 있

다. 여기서 TCP/IP 모델은 중요한 역할을 하는데, 모든 것이 이 모델을 기반으로 하기 때문이다. 이

더넷과 IP 기반의 네트워크에서 충돌 도메인(collision domain), ARP 브로드캐스트 도메인(ARP

broadcast domain), 멀티캐스트 브로드캐스트 도메인(multicast broadcast domain) 및 멀티캐스트에

대한 전반적인 내용 그리고 다양한 라우팅 프로토콜에 (특히 RIP와 BGP) 대해 잘 알아둘 필요가

있다. 또한 대부분 OSI 7 계층을 참고하므로 TCP/IP 모델에서는 어떤 계층에 해당되는지 파악해

두어야 한다.

흥미를 끌 만한 주요한 통계 값은 아마도 네트워크로 전송할 수 있는 데이터의 한계치일 것이다.

이것은 몇 가지 요소에 달려 있으며 링크 계층의 속도, 전송하는 트래픽의 종류, 네트워크 하드웨

어의 유무, 브로드캐스트 도메인, 브로드캐스트 트래픽, 장비의 속도 등이 있다. 장비의 지원 속도

는 특히 중요하며 데이터 링크 속도가 기가비트인 OSI 7 계층 네트워크 장비라도 응용 계층인 7번

째 계층이 소프트웨어적으로 처리된다면 1기가비트의 속도를 낼 수 없다. 하지만 ASIC 9 으로 된

OSI 7 계층 장비라면 기가비트의 속도가 가능할 것이다. 데이터 전송의 최고 속도에는 많은 요소

들이 관련되며 링크 계층의 원시적인 속도만으로 결정되지 않는다.

하지만 이러한 것들은 대개 이론적인 토론으로 끝나는 경우가 대부분이다. 왜냐하면 브로드캐

스트 스톰(broadcast storm) 10 을 일으키지 않도록 네트워크 구성을 잘 해놓았다면 대부분의 애플

9 　 ASIC(Application Specific Integrated Circuit)은 특정 애플리케이션을 지원할 수 있는 하드웨어 칩을 의미한다.

10 　 브로드캐스트 스톰(broadcast storm)은 많은 양의 브로드캐스트와 멀티캐스트 메시지가 네트워크에 과부하를 줘서 사용 불

능 상태로 만드는 것을 말한다.

32 l 스케일러블 웹사이트 구축

리케이션은 기가비트 네트워크를 포화시키지 않기 때문이다. 물론 네트워크를 집중적으로 사용

하는 특별한 애플리케이션의 경우는 예외다. 9장에서는 간단한 평면적인 모델 이상으로 네트워크

를 확장하는 법을 살펴볼 것이다.

언어, 기술, 그리고 데이터베이스

이제는 애플리케이션을 어떤 기술로 개발할지 충분히 생각했을 것이다. 작업에 맞는 도구를 사용

하는 것은 중요하지만 이 책에서는 어떤 특정한 기술을 권장하지는 않을 것이다. 앞으로 몇 가지

특정 기술들을 살펴보게 되겠지만 전반적인 학습 내용과 조언은 오픈소스인 LAMP 11 아키텍처에

서부터 마이크로소프트 애플리케이션 스택에까지 모든 개발 모델에서 적용이 가능하다.

서로 궁합이 잘 맞는 것으로 알려진 기반 기술을 이용하는 것은 언제나 좋은 생각이다. 한창 유

행하는 최신 언어나 프레임워크를 사용하고 싶을 수도 있겠지만 대규모 애플리케이션에서 이미

능력이 검증된 제품들을 사용하는 편이 시간과 수고를 많이 덜어줄 것이다. 모든 방면에서 최신

기술을 적용하는 것은 지치는 일이 될 것이며 버그를 발견할 때마다 애플리케이션의 문제인지 웹

서버의 문제인지 걱정해야 한다면 너무나도 힘들 것이다. LAMP는 많은 대규모 애플리케이션에서

지난 몇 년간 사용되어 왔고 안정적이며 개발하기도 쉬운 플랫폼이다.

이 책에 나오는 예제들은 주로 PHP를 사용하며, 필요할 때마다 펄로 만들어진 대안도 제시하고

있다. 웹서버를 말할 때는 대개 아파치(Apache)를 의미하며 시스템의 OS는 상관하지 않는다. 데이

터베이스는 대개 (특히 InnoDB 저장 엔진의) MySQL4를 사용하며 MySQL과 관련된 다수의 조

언과 아이디어를 제공하고 있다. PostgreSQL, 오라클(Oracle) Grid, 또는 마이크로소프트 SQL 서

버를 사용하더라도 이 책의 데이터베이스에 관한 부분을 읽어보기를 권장하며 거기서 조언한 내

용들은 다른 제품의 데이터베이스에도 동일하게 적용된다.

11 　 LAMP는 Linux, Apache, MySQL, PHP로 (또는 다른 “P”언어, 펄, Python 등으로) 작성된 웹 애플리케이션을 말한다.