한날의 낙서 [Hannal's scribbling]

1998년에 c 로 짜여진 웹 게시판(Crazy Web Board) cgi 소스 파일을 처음으로 접한 이후 perl(조금), php(어느 정도), asp(쬐금), 그리고 python(조금) 을 겪어 왔다.

python 은 2001년에 처음 접했다. 하지만 조금만 말실수(syntax error)를 하면 버럭 화를 내는(500 Internal server error) 예민한 성격이어서 곧 떠났다.

다시 python 으로 cgi 프로그래밍 하는 데 관심을 가진 건 유들 유들하고 성격 좋아 보이는 Rails (RoR 로 유명한 그 처자)를 대산님, 만박님, 코디안님을 통해 알게 된 어느 날이었다. 하지만 Java와 마찬가지로 Ruby라는 처자에 도무지 정이 가지 않았다. 왠지 뚱뚱해 보이는 몸짓도 마음에 들지 않았고, 말하는 것도(문법) 사람 약 올리는 느낌이었다. (마치 문법이 “핵꺼등녀?”, “댁꺼등?” 이라는 말투 같달까)

그래도 Rails의 성격에 자꾸 눈길이 갔다. 그래서 Rails 와 비슷한 성격을 가진 다른 처자들을 찾아 나섰고, php에선 cakephp가, python에선 django 가 비슷한 성격을 가졌다는 정보를 접했다. 발그레 미소 지으며 수줍게 말을 거니 딱히 까탈스럽게 굴지 않고 대답을 해주었다. “hello hannal”(hello world)라고…

2007년 도쿄市에서 무더운 여름을 나던 난 그렇게 django 처자와 인연을 시작했다.

---

내 취미는 기획이다. 밥벌이 역시 기획이다. 심지어 똥도 기획해서 누곤 한다. 99년부터 2007년 상반기까지는 게임 기획을 해왔고, 그 이후로는 웹 기획을 하고 있다. 그런데 오지랖 넓은 호기심 탓에 이것 저것 많이 건드렸다. 그림을 그리던 때도 있었고 음악을 짜던(?) 때도, 그리고 당장 쌀 살 돈이 없어 급한대로 웹 프로그래밍 외주를 한 적도 있다.

그래도 내 본업은 기획이다. 본업이 아닌 일엔 깊이 파고 들지 않는다. 아니, 그 일에만 파고 들지를 못한다. 얕고 넓게 여러 가지를 접하고 대하며 그러다 보면 자연스레 조금씩 깊어지곤 하지만, 일부로 깊게 파고 들지 않는다. 난 내 분수를 알고 주제를 안다. 그래서 되도록 각 분야 담당자나 전문가에게 까불지 않는다.

강좌 하나 쓰려 한다. 까불지 않는다면서 감히 프로그래밍쪽 강좌를 쓰려 한다. 이름하여 “날로 먹는 Django 웹 프로그래밍”이다.

이 강좌 역시 시건방지게 똥꼬에 주름 접으며 방귀 뽕뽕 낄 계획은 없다. 전문성과 깊이를 담은 지식과 정보를 널리 퍼뜨리는 것이 목적이라기 보다는, 새내기나 웹 기획자들에게 길라잡이 역할만 하려 한다. Django가 Python 이라는 프로그래밍 언어를 기반으로 하는데 Python 을 모른다고 해서 걱정할 필요는 없다. Python 문법 설명도 틈틈히 간단하게 다룰 것이며, 굳이 Python을 모르더라도 흘러가는 논리만 이해하면 어려움 없이 따라 할 수 있다.

아, 물론 사이비가 잘못된 길로 이끌 수도 있는데 그건 각자 알아서 길을 바로 잡아가길 바란다. 그 정도 노력도 없이 어떤 분야를 바르고 깔끔하게 다 얻고자 하는 건 무임승차자 심보이고, 난 무임승차자를 싫어한다. ^^ (농담 반 진담 반)

잠깐, 웹 기획자라고? 어째서 웹 기획자를 대상으로 한다는 것이지?

사람 마다 생각이 다르겠지만, 난 기획자라면 기획을 빼고 다른 분야 중 하나 정도는 할 줄 알아야 한다고 생각한다. 그래픽이든 프로그래밍이든. 그걸로 먹고 살거나 그 분야 담당자/전문가와 맞장을 뜨기 위함도, 뜨내기 개발자 기죽이기 위해서도 아니다. 기획을 할 때엔 많은 경험과 정보가 “기획 삽질”을 줄여 준다. 겪어 본 이들은 알다시피 기획 삽질은 많은 사람들을 고통스럽게 한다. 이 강좌는 웹 기획자도 쉽게 웹 개발을 겪어서 관련 이해도를 높여 다른 분야 사람들을 덜 고통스럽게 하고, 결국 웹 기획자도 행복해지게 하기 위함이다. (그래도 기획자는 게으르고 꼭 핵심 내용 한 두 개쯤 빼먹는 문서나 만들어 대는, 그래서 스토리 보드나마 좀 제대로 만들어 줬으면 좋을 족속에서 벗어나긴 쉽지 않을 것 같다. ^^;)

---

이 강좌는 6월 1일에 시작해서 8월 중순 경에 끝날 예정이다. 1주일에 한 편씩 올릴 예정인데 짧지 않은 이 기간 동안 우리는 간단한 블로그를 만들 것이다. 어딘가에선 5분이나 10분 만에 블로그를 만든다는 걸 보면 이 강좌를 쓰는 한날이라는 사람 수준을 알 만 하다. 어쩔 수 없다. 내가 하수이니 손이 느리며, 이 강좌를 쓰는 나 역시 공부를 하며 강좌를 쓰기 때문에 더 느리다. 그런데도 감히 강좌를 쓸 용기를 갖는 것은 홀아비 마음 헤아릴 줄 아는 과부 같은 마음이라 하겠다.

우리나라에 우리말/글로 쓰여진 python + django 정보가 많지 않아서 아직 널리 알려지지 않았는데, 이 참에 많은 초보자들에게 도움이 되길 바라 본다. 2007년, 열심히 구글링하며 했던 아주 단순한 실수를 다른 사람들이 하지 않기도 바라 본다.

- 2008년 5월 23일, 한날.

• 저작권 : 이 강좌의 저작권은 한날에게 있으며, 무단 배포를 원하지 않습니다. 어떡해서든 도메인과 블로그를 지켜낼테니 안심하고 강좌를 주소 연결(link)만 하시기 바랍니다. 다른 이유가 있어서는 아니고 중간 중간 틀린 걸 고치거나 내용을 덧쓸 수 있는데, 무단으로 퍼가면 조금이라도 더 부족한 내용을 제가 제어 할 방법이 없습니다.
• 배포처 : 이 강좌 예고는 이곳에서 하지만, 실제 연재는 한날은 생각한다에서 합니다.
• 연락처 : iam 달팽이 hannal.net 으로 연락을 하시면 되며, 전자우편으로 질문은 받지 않습니다. 질문은 python 과 django 에 궁금한 점 물어보고 답하기에 댓글로 남기세요.

1. 들어가며

며칠 전에 구글에서 Google App Engine이라는 플랫폼을 공개했다. 소식을 접하자 마자 계정 신청을 했는데 오늘 계정이 활성화 됐다는 전자우편이 왔다. Google App Engine에 대해 보다 자세한 우리말 글을 보고 싶다면 likejazz님께서 쓰신 구글 웹 어플리케이션 플랫폼: App Engine 글을 참조 바란다.

2. 가볍게 둘러 본 느낌

난 방금 전에 Google App Engine (이하 GAE)에 예제를 따라 Hello world성 문장을 만들어 뿌려봤다. 마침 Django도 지원하길래 django를 이용해서 비슷한 일을 해봤다.

이리 저리 둘러 보고

• 이거 정말 짱이다
• GAE를 기반으로 하는 서비스가 많아지면 MS passport 서비스가 실패했던 것과는 달리 Google account(gmail)은 성공할 수 밖에 없다. Open ID보다 더 Open ID스러운 놈이 될 수도 있을 것이다
• 기획자나 작은 서비스 기업, 혹은 개발자(엔지니어 말고)들은 정말 신나겠다
• 역시 구글은 무섭다. GAE는 서비스 개발계의 Google Adsense가 될 것이다

이와 같은 느낌을 아주 강렬하게 받았다.

3. 좋은 점

요즘 개발 인트라넷으로 각광 받고 있는 도구는 Trac과 Subversion이라고 생각한다. 자료 판숫자(version)나 Wiki를 통한 문서 관리가 편하기 때문이다. 무엇보다 협업을 편리하고 안전하게 할 수 있다는 점이 아주 좋다. GAE 역시 이런 점이 잘 되어 있는 걸로 보인다. 잘 되어 있다고 확실하게 말을 하지 못하는 이유는 그런 기능이 보이기는 하지만 아직 제대로 실험을 하지 않았기 때문이고, svn 같은 것도 여전히 따로 필요해 보이기 때문이다.
하지만 소스를 갱신할 때마다 소스 판숫자를 자동으로 올릴 수 있다.

어렵고 골치 아픈 부분은 신경 쓰지 않고 서비스 개발 자체에 집중할 수 있는 환경도 좋은 점이다. 서비스가 잘 되어 확장을 해야 할 때, 개발 초기에 확장성을 고려하지 않으면 큰 고생을 한다. 그래서 개발 초기에 설계에 많은 시간을 들인다. GAE를 쓰면 이런 부분을 신경 쓸 일은 없을 듯 싶다. 서비스 확장을 할 때 Database Server와 Application Server를 주로 확장할텐데 이 두 부분을 GAE가 맡기 때문이다. 서버 뒷단에서 어떻게 분산을 하는지 신경 쓸 것 없이 나는 API로 자료를 꺼내 쓰거나 넣으면 된다.

아직 이용자가 많지 않아서 그런지는 몰라도 GAE 서비스 자체가 빠른 점도 좋다. 값싼 어지간한 웹호스팅 보다 훨씬 낫다. -_-;

SDK도 잘 만들어져 있다. Rails 나 Django가 그러하듯이 GAE SDK도 내장 웹서버가 있어서 GAE에 계정이 없더라도 개발 자체는 진행해 나갈 수 있다. 그리고 이 SDK 기반에서 잘 작동하면 GAE 위에서도 잘 돌아갈 확률이 높은 편이다. 왜 “높은 편”이라는 다소 불확실한 말을 썼냐하면, 아직 SDK 완성도가 완전치 않아서 개발 환경(내장 웹서버)에서 잘 작동하는 것이 GAE 안에서는 오류가 나는 경우가 있고, GAE에 소스 코드를 올릴 때 GAE가 소스 파일 일부 내용을 고치는지 개발 환경에서 뜨는 화면과 GAE 위에서 뜨는 화면이 달라지는 경우가 있는 듯 싶다. 대체로 python 경로(path)와 관련된 부분에서 그러한데, GAE에서 제공하는 문서를 보면 어렵지 않게 문제를 피할 수 있다.

이용자 인증 체계도 아주 쉽게 처리할 수 있다. The Users API 문서를 보면 알겠지만, Google account(Gmail)과 이용자 정보 기능을 연결해놨다. Google App Engine 을 기반으로 하는 서비스가 많아지면 많아질수록 gmail 계정 하나로 편리하게 서비스에 접근하여 쓸 수 있게 될 것이다. 이거 어디서 보던 개념 아닌가? 그렇다. 바로 Open ID이다. Open ID는 인증 체계만 덜렁 제공한다면, GAE는 인증 체계와 더불어 Application을 편하게 만드는 환경까지 제공하는 것이다. 정말 기가 막히고 무섭다.

마지막으로 나한테 좋은 점은 (현재) 쓸 수 있는 개발 언어가 python인 점이다. 난 python을 좋아하기 때문이다.

4. GAE 안쪽 살펴보기

우선 처음 가면 Application을 만들라고 나온다. 현재는 이용자당 3개를 만들 수 있으며 한 번 만든 Application은 지우거나 ID를 고칠 수 없다.

Dashboard에는 각 Application(Service) 관련 로그들이 나온다. 서비스 감시 및 현황을 파악할 때 좋을 것이다.

내가 마음에 들어했던 부분은 바로 로그 보기 기능이다. 총 7가지에 로그를 볼 수 있다.

• debug log line
• An info log line
• A warning log line
• An error log line
• A critical log line (most severe)

크흑. 정말 기가 막히지 않은가!

Google Account를 가진 이용자에 한해서 개발에 참여시킬 수 있다. Google apps를 통해 계정을 만든 이용자도 참여가 가능하긴 한데 몇 가지 문제가 있어서 깔끔하게 되지 않는다. gmail.com 계정을 초대하고 참여하는 것이 명랑한 삶을 사는 데 도움이 될 것 같다.

당연히 있을 법한 기능 중 하나는 GAE에 올린 서비스에 도메인을 따로 붙일 수 있는 것이다. 이 기능은 Google apps를 통해야 한다.

Google Apps 관리자 화면에 가면 아마 GAE 관련 서비스 추가 항목이 없을 것이다. 그럴 경우 위 그림과 같이 도메인 설정 영역 중 제어판에서 “다음 세대”라는 항목을 적용해야 한다. 그러면

이와 같은 도메인 연결란이 생긴다. 예를 들면 http://hello-hannal.appspot.com에 http://helloworld.hannal.com을 연결한 것이다.

5. 실제로 Hello world 찍어보기

여기서는 GAE에 hello world를 출력하는 과정을 보이는 것이 목적이지 python이나 django 강의를 하는 건 아니다.

5-1. 어플리케이션 생성

우선 GAE SDK 디렉토리 안에 GAE에 추가한 Application 디렉토리(폴더)를 하나 만든다. GAE에 만든 Application ID와 꼭 같을 필요는 없다. 근데 여기서는 Django를 이용할 것이므로 django-admin.py 을 이용해 만들기로 하자.

django-admin.py startproject uw

그러면 uw라는 디렉토리가 생기고 django 관련 기본 파일들이 만들어져 있다. 왜 helloworld가 아니라 uw인가하면 별 뜻 없다. hello world가 지겨워서 unlimited world라고 하고 싶었기 때문이다.

이제 app.yaml 파일을 uw 디렉토리 안에 만들고 다음 내용을 써넣는다.

application: uw
version: 1
runtime: python
api_version: 1

handlers:
- url: /.*
  script: main.py

YAML 설정에 대한 자세한 내용은 Configuring an App 문서를 참조 바란다.

보면 / 로 들어오는 모든 요청을 main.py 이 받게 했다. 이 main.py는 Running Django on Google App Engine 문서에 설명이 잘 나와있다. 다만 이 문서대로 하면 settings.py 에서 오류가 발생하는데 settings.py 맨 위에 import os 를 써넣으면 된다. 템플릿 경로 지정 문제 때문에 그런 것이다.

5-2. 화면 만들기

이번엔 / 로 들어왔을 때 보일 화면을 만들자. 간단하다. 우선 urls.py 에 접근 요청 경로와 이 경로에 연결할 함수를 정의한다.

urlpatterns = patterns('',
    (r'^$', 'views.root_page'),
    (r'^hannal/$', 'views.goto_hannal'),
)

난 아무 경로 없이 최상위 경로(/)로 왔을 때 views.root_page 를, /hannal로 왔을 때 views.goto_hannal을 실행하겠다고 했다.

이번엔 views.root_page 를 만들 차례이다. 취향에 따라 views.py 안에 각 함수를 만들어도 되고 views 디렉토리 안에 root_page.py 나 goto_hannal.py 파일을 만들어도 되지만, 난 views.py 안에 각 함수를 만들기로 했다.

urls.py 나 settings.py 파일이 있는 곳에 views.py 를 만든 뒤 다음과 같이 내용을 만든다.

# -*- coding:utf-8 -*-
from django.http import HttpResponse, HttpResponseRedirect
import django

def root_page(request):
    str = '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "DTD/xhtml1-transitional.dtd">'
    str += '<html>'
    str += '<head><title></title><meta http-equiv="content-type" content="text/html; charset=utf-8"/></head>'
    str += '<body>'
    str += '<p>안녕하세요, 여러분.  이 화면은 '
    str += '<a href="http://www.djangoproject.com">Django %s.%s</a>로 만들었고, '  % (django.VERSION[0],django.VERSION[1])
    str += '<a href="http://appengine.google.com">Google App Engine</a>에서 '
    str += '돌리고 있답니다.</p>'
    str += '</body></html>'

    return HttpResponse(str, mimetype='text/html')

def goto_hannal(request):
    return HttpResponseRedirect('http://www.hannal.net')

5-3. 소스 반영 및 확인

이제 appcfg.py 를 이용하여 소스를 GAE 서버에 올린다. 처음 실행하면 gmail 계정 인증을 요청하고, 이후엔 .appcfg_cookies 파일을 만들어 인증을 생략한다.

다 올린 뒤 http://uw.appspot.com에 접속하면 화면이 잘 나온다. http://uw.appspot.com/hannal로 접속하면 http://www.hannal.net 로 이동한다.

6. 글을 마치며

기대보다 훨씬 재밌고 끝내주는 서비스, 아니 플랫폼이 등장했다. 시장에 미칠 파급력이 엄청날 것이라고 본다. 기획자도, 소프트웨어 엔지니어가 없거나 경험이 없어 서비스 확장 구조 설계에 어려움을 겪는 작은 팀이나 회사도 모두 매력을 느낄 개발 플랫폼이다.

그나저나 이런 것 나왔으니 가벼운 말로 꺼낸 django 개발 책을 정말 써야 하는 걸까? ^^