블로그 이전.

Tistory에서 github pages로 블로그 이전 했습니다. 티스토리 백업 중지는 폐쇄 전 움직임 같아 보여 안심할 수가 없네요.

문제는 글들을 옮겨와야 하는데 양이 꽤 되는지라… 티스토리 블로그를 2008년 1월부터 사용해왔고, 쓴 글 갯수를 보니 362개 였습니다.

오래된 글 들 중 많이 다듬어야 될 글이나, 의미가 무색해진 글들을 배제한다해도 200개쯤은 옮겨야 할 거 같아 긴 노가다가 될 거 같네요.

XML로 export된 문서들이 있긴한데 이걸 Markdown으로 잘 컨버팅 해주는 도구가 있는지 찾아봐야겠습니다.

여튼 앞으로는 이쪽에서 블로깅을 하게 됐으니~~ 새로 RSS 구독 신청 부탁드립니다!

python 입문기

여러 글에서 밝혀왔듯 나는 rubyist다. ruby를 사랑하는 이유는 내가 접했던 언어 중 가장 즐겁게 코딩이 가능했기 때문이다. rails는… 음 이제와 밝히자면, 사실 좀 어려웠다. ruby가 어려웠다기보다는, 웹에 대한 이해도가 전무한 개발자가 쉽게 기능 개발을 해볼 순 있지만, production 과정까지 가는게 쉽지만은 않았다랄까?

ruby는 해외와는 달리 국내에서는 비주류라는 점이 고민의 포인트가 되긴했지만, 해외에서의 높은 인지도로 인한 풍부한 자료는 그 거부감을 상쇄 시켜줬다.

성능상의 이슈가 있다지만 어지간한 규모의 트래픽으론 성능 이슈를 제기할 정도로 열악한 것도 아니다.

오히려 가장 아쉬웠던 점은 rails가 갖는 장점인 학습 속도에 비해, 단점인 프로덕션 과정에서의 학습 비용이 큰 편이었던 점이라고 할 수 있다.

특히 DB관련한 연동은 추상화 레이어로 인한 개발 과정 이득은 있지만, 인덱스 개념이나 데이터 모델링 개념이 부족한 경우에 프로덕션 트러블의 요인이 되기 쉽상이다. 물론 이는 다른 언어들의 프레임워크들도 가진 문제지만, ruby on rails는 쉬운 학습 비용이 장점인 프레임워크이기 때문에, 이 부분이 조금 더 감점 요인이라고 생각한다.

물론 나는 위 모든 점을 감안해도 rails가 좋다. 여전히. ruby도 물론이고.

몇번이나 이런 질문을 받은 적이 있다. 왜 rails를 썼냐고. 국내 기준으로 C++이 여전히 주류이고, 웹 기반 서버로 많이 넘어가던 시기에도 php, asp.net, node.js, jsp 등이 주류이던 시기에, 심지어 python도 아닌 ruby였냐고.

그 질문에 나는 항상 같은 대답을 했다.

“내가 그 당시 학습하려 시도한 모든 언어들 중에 ruby가 가장 즐거웠노라고.”

업무는 내 삶에서 큰 부분을 차지한다. 그 과정이 즐겁지 않다면, 내 삶이 즐겁지 않을 수 도 있다. 그래서 나는 내가 업무를 즐겁게 하기 위한 선택을, 가능하다면 많이 하려고 하는데, 그 과정에서 ruby는 꽤나 높은 점수를 줄 수 있었다.

그렇다면 python도 즐거워서 골랐나? 그렇진 않았다.

내가 느낀 국내 인지도는

Java > C++ > C# > Python > Ruby > Golang = scala 였다. 사실 나는 ruby 다음 언어로 Golang이나 scala를 해보고 싶었음을 지난 글에서 밝힌 바 있다.

하지만 현재 시점에서 “웹 서버”를 구현해야 할 언어를 골라야 한다는 관점에서, Golang은 시기상조인 면이 많고, 특히 웹서버로 구동하기엔 여타 프레임워크보다 아쉬움을 갖고 있다. scala로 Play! 프레임워크를 사용해보려 고민도 했으나, 그러기에는 내가 너무 java에 대한 이해도가 부족했다.

게다가 나는 C++ > C# > Java의 선호도를 갖고 있고.

그리하여, ruby와 비슷한 급(?)의 언어이면서, 국내에서의 인지도가 ruby보다 높은 python을 해보기로 했다.

rails를 다시 선택하는 방법도 있었지만, 웹 프레임워크로써 프로덕션 레벨에 올려본 것이 rails 하나이기 때문에 다른 웹 프레임워크의 장단점과 다른 언어 학습의 기회를 같이 맛보기 위한 선택을 하게 됐다.

그렇게 python을 입문하고 나니, 몇 가지 감상이 들어 3달여간 사용해본 경험을 정리해보고자 한다.

indent 강제. 사실상 내가 python보다 ruby를 애호하게 된 이유다.

indent 에도 취향이 있는 것이고, 나는 프로그래밍이 재밌어야, 일이 재밌어야 한다고 주장하는 입장에서 자유도를 억제하는 느낌드는 파이썬의 indent강제는 거부감이 들었다랄까?

막상 사용해보니 코드 읽기에 큰 강점이 있더라.

실제 동작을 유추하기 쉽다보니, 여러모로 메리트가 있었다.

다만 다른 언어들과 조금 다른 것들이 많은데, 예를들어

조건문이나 함수 정의에 :이 마지막에 붙는 점이다.

ruby

def test()
    statement

python

def test(abc):
    statement

다음과 같아 진다.

조건문의 경우에도 마찬가지로,

ruby

if aaa
    statement
end

python

if aaa:
    statement

같은 형태가 된다.

다들 아시다시피, 들여쓰기가 depth에 따라 코드가 어떤 단락에 포함되는지를 결정짓는다.

ruby

# 들여쓰기 1
if condition
    statement
    statement2
end

# 들여쓰기 2
if condition
    statement
statement2
end

python

# 들여쓰기 1
if condition:
    statement
    statement2

# 들여쓰기 2
if condition:
    statement
statement2

루비는 두 결과가 같다. 하지만, 파이썬은 다르다. 들여쓰기 2에서, aaa 조건이 성립하지 않아도 statement2는 실행된다.

이런 제약이 거추장 스럽게 느껴진게 사실이다. C++에 비해 상대적 자유도가 낮은 java를 선호하지 않았던 이유도 같은 이유였기 때문인데, 굳이 스크립트 언어에 제약이 있는 언어를 고르지 않겠단 생각이었다.

헌데 막상 파이썬을 사용해보니, 협업에 큰 장점이 있었다. RSA 알고리즘을 한 줄에 짤 수 있네 마네 말도 많은 perl을 겪은 나로썬, 또 지나친 자유도로 소통 비용을 크게 요구하는 C++을 오래 사용해온 입장에서 크게 와닿으며, 인정하게 된 것은, indent강제가 코드 읽기 비용을 크게 낮춰준다는 것을 확실히 느낄 수 있었다.

이는 디버깅이나 오류 비용이 크게 낮아진다는 얘기기도 하다.

내가 크게 걱정했던 표현력이 막상 크게 제한되지도 않았다. 팀작업에서 큰 이득이 있었고, 오픈소스 코드 분석에서도 큰 장점이 됐다.

아니, 다른 언어들도 이래야 하는거 아닌가 싶을 정도로 마음에 들었다는게 맞겠다.

대다수의 팀에서 일하는 프로그래머들은 팀 코드만 보지 않는다.

오픈소스 진영에서의 개발은 특히나, 다른 사람의 코드를 봐야 할 일이 아주 많다.

그런 측면에서 아주 큰 강점이 있다는 생각이 들었다.

거기에 부가적으로, python도 말하면서 코딩하는 기분이 들었다.

if user is None:
    blah blah

이 얼마나 직관적인가?

django로 개발하면서 머릿속의 내용을 코드로 옮기는데에 멈칫하는 과정없이 술술 진행될 수 있었던 것은, python의 문법이 유연하진 못하지만, 대화하는 느낌이 드는 언어였기 때문이다.

이 점이 나에게 python에 대한 인상을 좋게 만들어주는 요인이 되었다.

나에게있어 python은 어려운 언어는 아니었다. 사실 쉽게 익숙해진 언어라 볼 수 있다고 본다.

ruby를 먼저 접했어서 인지, 아니면 python 자체가 쉬워서인지는 잘 모르겠지만, 여러모로 ruby와는 또 다른 즐거움을 가져다준 언어였다고 생각한다.

이어지는 django 사용기에 조금 더 디테일한 python 사용기를 담아볼 예정이다.

TCP 서버와 웹서버 장단점 비교

TCP 서버

장점

  • 성능이 좋다. (=빠르다)
  • 커넥션 기반
    • 가용성을 확보하는 공수가 큼.
  • 손쉽게 notify가 가능. (클라이언트의 요청없이 서버가 패킷 전달)

단점

  • 커넥션 기반이라, 커넥션 유실/복구 이슈
    • 로직간 결합도가 높아지는 경우가 자주 발생한다.
  • 서버 크래시에 대한 높은 리스크.
    • 예외처리로 커버되지 않을 때.

웹 서버

장점

  • stateless 기반
    • 가용성 확보가 쉬움.
    • state는 모두 db에 존재.
  • 오픈소스 프레임워크가 많고, 검증되어있음.
    • 프레임워크 내에서도, 다양한 기능들이 오픈소스로 배포되고 쉽게 사용 가능.
  • state가 없음으로 로직간 결합도가 낮다.
    • 서버 크래시에도 큰 장애는 없다.
    • 어지간해서는 서버 크래시도 없다. [일부 기능만 오류 발생.]
    • 부하로 인한 timeout이나, 스크립트 오류가 발생할 뿐.

단점

  • 모든 데이터는 요청마다 db를 조회해야해서 성능이 떨어진다.
  • notify가 어려움. (1-request, 1-response 구조)
  • 다른 피어와 통신용으로 사용하기 위해선 polling이 필요하다. [like ajax]

Django 사용법

Django

Django package

python

python package

Django Celery 사용법 [with RabbitMQ]

Django + Celery 사용법

설치

pip install -U Celery
pip install django-celery
# 데이터베이스 migration 필요. [djcelery를 위해]

Django 설정

  • settings.py에 아래 내용을 추가한다. ~~~ python import djcelery

djcelery.setup_loader()

BROKER_URL = “amqp://guest:guest@localhost:5672//”


* settings.py 파일에 추가

~~~ python
INSTALLED_APPS = (
'djcelery',
'myapp',
)
  • 두 가지를 추가해야 한다. myapp은 개발하고 있는 app의 이름이 되겠다.

Task 생성

from djcelery import celery
@celery.task(name='tasks.add')
def add(x,y):
 return x + y

@celery.task(name='tasks.sleeptask')
def sleeptask(i):
 from time import sleep
 sleep(i)
 return i

테스트 목적으로 두 개의 task를 만들었다. 하나는 즉시 값을 리턴하는 add함수와 10초 뒤에 task를 반환하는 sleeptask 함수이다.

View 만들기

# django app의 views.py에 아래의 내용을 추가
from django.http import HttpResponse
from myapp import tasks

def test_celery(request):
   result = tasks.sleeptask.delay(2)
   result2 = tasks.add.delay(2,5)
   return HttpResponse("this is task test (id : %s)" % result.id)

# 이렇게 view를 만들어놓고 url에 이 view를 호출할 수 있도록 해야한다. 
# urlpattern에 아래 내용을 추가해준다.

import views as taskview
urlpatterns = patterns(
                      ...
                      url(r'^test$',taskview.test_celery),
                      )

가동

python manage.py celeryd -l info

직렬화

Consumer

  • 주의 사항
    • 15672는 웹 포트다. 5672 포트로 연결해야 한다.
    • 연결이 RabbitMQ에서 끊어질 시에는 RabbitMQ 관리 웹 페이지에서 Can access virtual hosts가 설정되어있는 계정인지 확인해볼 것.
    • tasks로 만들어 던지는 함수에 req를 바로 던질 수 없다. pickle 가능한 object만 던져야 한다. 즉 파라미터들을 꺼내서 던져야 한다는 의미.

      user_no = int(req.session[‘user_no’])
      return tasks.celery.delay(user_no)

Pycharm Celery 디버깅 설정

Pycharm Celery 디버깅 설정

참고