[성공이란 별거 없다] 삶의 방향 상호작용
우리가 살아가는 삶의 방향은 우리가 겪고, 느끼는 모든 접촉과 모든 감정의 연결이 만들어낸 결과가 아닐까? 본인의 삶의 방향이 잘못됬다 생각된다면, 현재 맞이하는 접촉과 감정의 변화를. 반대의 경우라면 더 강한 접촉과 감정을 느낀다면 어떻할까?
성공이란 별거 없다[성공이란 별거 없다] 삶의 방향 상호작용
우리가 살아가는 삶의 방향은 우리가 겪고, 느끼는 모든 접촉과 모든 감정의 연결이 만들어낸 결과가 아닐까? 본인의 삶의 방향이 잘못됬다 생각된다면, 현재 맞이하는 접촉과 감정의 변화를. 반대의 경우라면 더 강한 접촉과 감정을 느낀다면 어떻할까?
성공이란 별거 없다시스템 규모가 작을때는 일반적으로 하나의 데이터베이스에서 모든 데이터를 관리합니다.(로그같은 특수 목적의 데이터는 제외) 이유는 데이터 양이 많지 않은데 굳이 멀티 데이터베이스를 쓰면서, 관리 포인트를 늘일필요가 없고, 데이터베이스 늘어날때마다 모든면에서 복잡도가 매우 높아집니다.
하지만 대륙을 넘나 드는 서비스를 한다거나, 단일 데이터베이스에서 감당하기 힘든 데이터가 쌓인다면, 복잡도를 감수하더라도 멀티 데이터베이스를 고려해야할 상황이 생깁니다. 지금 저희 www.mymusictaste.com 서비스가 위에서 언급한 두 가지 상황에 쳐해있고, 해결 방향을 찾아가는 과도기 입니다. 이런 배경을 갖고 개발을 진행하고 있으며, 이번 제가 맡은 업무중 하나는 여러개의 Django app 중 (저희는 서비스 별로 app을 나누고 있습니다.) 하나를 다른 데이터 베이스로 이전하는 작업을 하게 되었습니다.
장고는 멀티데이터베이스를 지원합니다. 아주 잘 디자인된 웹프레임웍 답게 멀티데이터 베이스를 Config 설정에서 간단히 지원합니다. 하지만 각 데이터베이스의 통신을 위한 라우팅은 개발자의 몫입니다. 일반적으로 라우팅을 해주지 않는다면, default
데이터베이스가 사용됩니다.
The default routing scheme ensures that if a database isn’t specified, all queries fall back to the default database.
그렇다면 멀티데이터 베이스에 어떻게 라우팅 할것인가? 위에서도 말했지만 라우팅은 부분은 전부 개발자의 몫이다. 공식문서에 가이드가 있지만 random 을 활용한 example 정도 수준이며, Google 검색결과 매우 다양한 방식의 구현을 찾아볼수 있다. 모델 수준에서 사용할 database
를 명시하는 경우도 있고, 라우터를 세세하게 작성하는 경우도 있었다. 나는 첫번째 방법인, 모델 수준에서 사용할 데이터베이스를 명시하는것은 각 모델 수준에서 routing을 관리해야하기 때문에 좋지 않은 디자인으로 생각했고, 두번째 방법을 선택하기로 했다.
예제는 순서대로 진행하면 된다. 초기 프로젝트라면 쉽게 구성할 수 있지만, Legacy가 많은 코드라면 고생을 각오해야한다. 말씀 드리지 않아도 아시겠지만, 아래 작성된 코드와 방식은 이해를 위한 샘플이지 best example은 결코 아니다.
데이터 베이스를 생성 후, 커넥션 정보를 셋팅파일에 추가한다.
settings.py
DATABASES = {
'default': {
'NAME': 'master',
'ENGINE': 'django.db.backends.mysql',
'USER': 'mysql_user',
'PASSWORD': 'spam',
},
'auth_db': {
'NAME': 'auth_db',
'ENGINE': 'django.db.backends.mysql',
'USER': 'mysql_user',
'PASSWORD': 'swordfish',
},
}
커스텀 라우터 모듈을 작성 후 settings.py 에 작성된 라우터를 사용한다고 선언한다.
router.py
class MultiDBRouter(object):
def db_for_read(self, model, **hints):
if model._meta.app_label == 'auth':
return 'auth_db'
return 'default'
def db_for_write(self, model, **hints):
if model._meta.app_label == 'auth':
return 'auth_db'
return 'default'
def allow_migrate(self, db, model):
if db == 'auth_db':
if model._meta.app_label == 'auth':
return True
else:
return False
return True
settings.py
...
DATABASE_ROUTERS = [
'<router_path>', # e.g) snsproject.core.routers.MultiDBRouter
]
(MySQL 기준) 새로운 database를 생성하고, application 에서 connection을 맺으려 할시 Access Denied
에러가 발생할 것이다. 이를 해결 하기 위해 application user에 새로 생성한 database의 접근 권한을 부여하자. 위 작업은 root 권한 혹은 user 권한 변경이 가능한 DB user가 필요하다.
GRANT ALL ON <database_name>.* TO 'selo'@'%';
> python manage.py migrate --database=auth_db
만약 마이그레이션을 진행시 마이그레이션 이슈가 발생한다면 기존 마이그레이션 파일의 변경이 필요할수도 있다. 장고 마이그레이션은 매우 편리하지만 100퍼센트 완벽하지는 않아보인다. 이러한 부분은 개발자가 풀어야할 숙제이며, 나는 다음과 같은 방법으로 이 문제를 해결하려한다.
from django.db import migrations
def forwards(apps, schema_editor):
if not schema_editor.connection.alias == 'default':
return
# Your migration code goes here
class Migration(migrations.Migration):
dependencies = [
# Dependencies to other migrations
]
operations = [
migrations.RunPython(forwards),
]
항상 느끼는거지만 장고는 정말 정말 많은 기능을 품고 있다. 멀티 데이터베이스도 간단하게(???) 지원한다. 하지만 어디까지나 장고가 추구하는 디자인과 API 표준을 벗어나지 않는 범위에서 구현된 프로젝트에만 해당되는 이야기다. 그리고 위 포스팅에서는 다루지 않았지만 1.7 이하의 버전을 쓰고 있다면 몇 가지 제약이 존재한다.
SessionAuthentication
을 메인 인증방식으로 사용하고 있습니다. 하지만 특수한 목적으로 해당 API만 다른 인증방식이 필요하였고, DRF에서 제공하는 Token 인증을 이용하여 간단히 문제를 해결하였습니다.
from rest_framework.authtoken.models import Token
token, created = Token.objects.get_or_create(user_id=2)
token.save()
시 내부적으로 key
보유 여부를 확인.key
가 None
인 경우 generate_key()
method를 호출, key
생성 후 저장.[일잘하는법] 업무 요청시 이유를 동반해야 하는 이유
업무를 요청시 이유(왜 필요한지, 왜 변경해야 하는지 등)를 반드시 동반한다.
요청을 받는 입장에서는 당사자의 리소스를 들여서 업무를 처리해야한다. 이유가 결여된 상태에서 업무 처리는 의문이 남게된다. 의문은 비효율성과 부정적 태도를 갖게한다.
즉, 이유를 동반한 업무요청은 불필요한 부정적 요소들을 제거 함으로서 효율적일 수 밖에없다.
“뭐시기 해주세요.”
“뭐시기가 이거하는데 필요한데 뭐시기 해주세요.”
일잘하는법[평범하게 부자 되는 방법] 부자의 기회를 찾아서
기회와 위기는 더 빠르게 창출될 것이다.
나는 유년시절 부터 쓸데 없이 세상에 관심이 많았다. 특히, 사람이 사랑하는 방식에 대한 의문이 많았다. 초등학교 시절 유일한 관심사는 사랑받는 방법이었다. 이성으로 부터 뿐만 아니라 모든 사람에게 받는 사랑과 관심에 관한 고민이었다. 유치원 시절 노랑반 반장 부터 시작해 고등학교 까지 관심과 사랑을 받기 위한 끊임없는 고뇌와 증명의 시간이었다. 지나가서 생각해보면 내 자신은 크게 중요하지 않았던 것 같기도 하다. 내 자신에 대한 고민보다 타인의 관심을 얻기 위한 고민이 더 많았다. 그래서 인지 머리가 커서부터는 일반적인 사람들의 행동과 생각은 어느정도 예측범위에서 벗어나지 않았다. 우리가 촉이라고 얘기하는 추상적인 능력이 꽤 발달했다.
내가 생각하는 인간 세상의 변화의 가장 큰 영향은 사람들의 관심이다. 관심의 옮고 그름을 떠나서, 사람들이 관심을 갖는 순간 부터 그 무엇은 변화하기 시작한다. 이는 역사적 사실로부터 수없이 증명되어왔다. 우리는 정치에 관심을 갖지 않았고, 정치에 무지했고, 정부는 부패했다. 하지만 우리가 정치에 관심을 갖게된 순간 부터 변화가 시작되었다. 이는 정치 뿐만 아니라 인간 세상의 모든 변화의 시발점이 된다. 최근 예로는 인공지능, 가상화폐, 북한병사 탈북 이국종의사 선생님의 발언으로 인한 중증 치료센터 개선 관심.
(또한 관심 정도에 따라 변화의 속도에 큰 영향을 미친다. 우리의 관심이 커질수록 변화의 속도는 상상을 초월한다.)
최근 사람들의 관심사 변화 속도는 과거와는 비교가 안되게 빠르게 변화한다. 소셜 네트워크를 기반으로한 다양한 미디어 채널 증가. 그로인한 정보 총량, 정보 접근성, 정보 노출도의 폭팔적 개선 및 증가가 이를 이끌고 있다.
(바쁘다. 이만 마무리 하자. 할일이 태산이다…)
결론적으로 인간의 관심 정도는 세상을 변화시킴 => 현재는 인간의 관심이 빠르게 변화함 => 인간의 관심이 세상을 빠르게 변화시킴(세상의 변화는 위기와 기회를 동반함) => 기화와 위기가 더 빠르게 창출됨 => 기회와 위기는 투자의 기회
평범하게 부자 되는 방법블로그를 옮기며…
나는 계속 변화하려 한다. 이것이 긍정인지, 부정인지 아직 답은 내리지 못했다. 하지만 하나는 확실하다. 변화하려는 나의 강한 본능적 욕구가 큰 에너지를 발생시킨다.
일 년 정도 운영하던 https://selo77.github.io 문을 닫고 이곳으로 옮겼다. 이번이 횟수로는 3번째 블로그다. 공들여 만들었던 블로그를 굳이 왜 옮기려 하는가? 이유는 간단하다. 나는 글을 잘 쓰고 싶고, 기록하고 싶고, 공유하고 싶고, 자랑하고 싶다. 그러나 나는 전혀 그렇지 못하다. 이러한 목적을 갖고 블로깅을 시작했다. 하지만 이전 블로그는 글쓰기 전에 상당히 귀찮은 사전 작업이 많다. 또 시각적으로 화려하고 편리한 UI를 제공하지만 그만큼 이쁘게 꾸미려는 욕망을 불러일으킨다. 글도 못 쓰는데 자꾸 잿밥에 신경 쓰게 된다. 맞춤법도 틀리는 놈이 글이나 잘 쓸 것이지 블로그의 디자인에 신경 쓰고 있어서 말이다.
이제 블로그를 옮긴 이유는 충분히 합리화했다 하하. 그렇다면 내가 블로그를 만들었던 그리고 지속하려는 이유를 생각해보자. 처음 블로그를 시작한 것은 그냥 남들이 하니까, 하라고 하니까, 나도 해야할것 같았다. 물론 이것도 큰 동기이자 목표가 되었고 내가 블로그를 시작하게 된 계기를 만들어줬다. 두 번째 블로그는 있어 보이고 싶었다. 나도 꾸준히 블로깅을 하고 유명블로그 까지는 아니지만 화려한 명함이나 직함처럼 있어보이게 나를 기록해줄 무언가가 필요했다. 그게 두번째 화려하게 기록하고 싶은 블로그였다. 왜 굳이 두 번이나 중도 포기를 하고 또 블로깅을 하려 하는가?
글을 쓰고 싶다. 글을 못 쓰지만 쓰고 싶다. 맞춤법도 틀리지만 쓰고 싶다. 창피하지만 쓰고 싶다. 그렇다면 창피하고 잘하지도 못하는 글을 왜 쓰고 싶은가? 나는 변화한다. 그리고 많이 변화했다. 이게 성장인지 퇴보인지는 모른다. 하지만 이러한 과정을 기록하고 싶다.
“새로야!! 이번엔 천천히 꾸준히 잘해보자.” 블로그가 새로에게
PS. 글을 다 쓰고 나서야 생각난 나의 진짜 첫 블로그가 생각났다. 무려 일 방문자 3,000명이 넘는 네이버 파워블로그였는데, 벌써 머릿속에서 잊혀다. 이래서 기록은 중요한가보다…