셰프(Chef)로 서버팜 깔끔하게 요리하기, Part 1: 아키텍처와 구성 요소

허진영 classpath@gmail.com 루비/레일스 개발이 하고 싶어 5년간 잘 다니던 안정된 직장을 박차고 나온 자칭 시크한 도시 남자. 현재 APEC Climate Center에서 유일한 소프트웨어 엔지니어로 활동하고 있으며, 2008 Fukuoka Ruby Award 대상을 받은 CLIK(CLImate toolKit, http://clik.apcc21.net)의 주 개발자다. 한 가지 소박한 꿈이있다면 세살 된 아들의 미래 희망이 세계 정복이었으면 하는 것이다. 역서로는 The Java™ Language Specification, Third Edition(에이콘)이 있다. 난이도 : 중급 2009년 10월 20일

연재순서
1회(2009년 10월): 아키텍처와 구성 요소

[오픈 developerWorks]는 여러분이 직접 필자로 참가하는 코너입니다.

주방의 악몽

시스템 관리자에게 신규 서버 추가, 설정은 관리하는 서버 수가 몇 대 되지 않더라도 잘해야 본전, 못하면 손해인 일이다. 기존 서비스 용량 확장을 위해 서버를 추가하거나, 신규 서비스이지만 초기에 서버를 여러 대 설정해야 한다면 더욱 신경 써야 한다. 서비스에 필요한 라이브러리 설치나 개발된 소프트웨어 배포, 환경 변수나 튜닝을 위한 설정 파일 변경 등이 모두 똑같이 완료되어야 서비스가 정상으로 동작할 수 있기 때문이다. 이는 장비 교체 시에도 적용될 수 있다. 물리적인 디스크 이동만으로 신규 장비에서 모든 것이 이전처럼 동작한다면 문제가 없겠지만 그렇지 않다면 역시나 앞서 언급한 요소들에 대해 신경 써야 한다.

솔직히 이런 작업은 어느 정도 시간이 흐른 후에는 그다지 보람도 없거니와 귀찮기도 하고 작업 한두 가지를 빼먹을 공산이 크다. 물론 절차를 문서로 써서 작업 중 실수를 최소화하는 노력을 할 수 있지만 '문서가 시스템의 최신 정보를 반영한다'라는 명제는 대개 그렇지 않은 경우가 더 많다는 문제가 있다. 필자 역시 시스템 설정•관리 메뉴얼을 위키 등을 이용해 최대한 유연하고 신속, 정확하게 유지하려고 노력했으나 시간이 지나면서 새로 추가되는 절차 중 작지만 꼭 필요한 절차를 한두 개씩 빼먹었던 경험이 있다.

이러한 여러 절차를 일련의 스크립트 조합으로 해결하려고 시도할 수 있다. 초기에는 이 방법이 쉽고 빠르며 적절해 보이지만 시간이 지나면 시스템간 버전 동기화 문제라든지 실행 시 필요한 인자 전달이나 실행 순서, 서브 스크립트 재사용성 등에서 한계를 보일 수밖에 없다. 또 운영체제 종류가 한 가지라면 그나마 다행이지만 여러 종류가 존재하는 환경에서는 스크립트를 그에 맞춰 일일이 조정하기도 쉽지 않다.

해외 리얼리티 프로그램을 좋아하는 독자라면 고든 램지(Gorden James Ramsay)의 "미션 최고의 레스토랑"(원제: Ramsay’s Kitchen Nightmares)에 대해 한번쯤 들어보았을 것이다. 폐업 직전의 레스토랑에 고든 램지가 찾아가 인기 만점의 레스토랑으로 만드는 과정을 보여주는데 흥미로운 점은 문제 있는 레스토랑에는 항상 문제 있는 주방장(chef)이 있다는 것이다. 주문이 밀리면 어떻게 해야 할지 당황해 실수하는 주방장이나 음식을 제대로 만들지 못하는 주방장, 주변 동료들과 조화롭게 일하지 못하는 주방장, 비효율적인 기존 방식과 인기 없는 메뉴를 고수하는 주방장 등이 꼭 빠지지 않는다. 주방 역시 제대로 되어 있지 못하다. 음식 재료, 각종 요리 기구가 여기저기 번잡하게 널려 있다. 주방 보조들도 우왕좌왕하기는 마찬가지다. 이런 주방과 주방장은 고든 램지에게 거의 모욕에 가까운 질타를 받는다. 하지만 결국엔 최고의 주방장과 주방이 되는데 주방 풍경은 이전과 천지 차이다. 잘 정돈된 식재료와 기자재, 일사분란하게 움직이는 주방 구성원, 그리고 이 모두를 이끌고 손님이 주문한 다양한 음식을 착착 제시간에 맞춰 훌륭하게 만들어내는 주방장이 탄생하는 것이다.

뜬금없이 왠 TV쇼 타령일까? 손님을 우리가 설정하고 관리해야 할 시스템이나 서비스, 만들어야 할 음식을 시스템에 설치하고 설정해야 할 소프트웨어, 각종 스크립트 파일과 관련 메뉴얼을 식자재와 요리 기구에 대비해 보자. 이 글의 시작에서 이야기했던 스트레스 가득한 시스템 설정•관리의 세계가 망해가는 레스토랑의 주방과 비슷해 보이지 않는가?

번창하는 레스토랑이란 목표를 위해 무엇이 가장 필요할까? 이미 재료와 각종 요리 기구, 만들어야 할 음식 종류는 준비됐으니 이 모든 것을 훌륭히 이끌 존재가 필요하다. 지금 당장 최고의 주방장이 되어 보자!

셰프에 대해

셰프(Chef, http://www.opscode.com/chef)는 OPSCODE(http://www.opscode.com)에서 만든 오픈 소스 시스템 관리 프레임워크다. 2009년 1월에 정식 발표된 아주 어린(?) 소프트웨어라고 해서 지금 보고 있는 창을 닫거나 다른 페이지로 이동하지 말자. 셰프는 충분히 안정적이며 다양한 기능을 갖추고 있다. 각종 애플리케이션뿐만 아니라 데이터베이스, LDAP 디렉터리와도 훌륭히 동작한다. 이미 실제 비즈니스 환경에도 쓰이는데 프로젝트 300만 개가 운영되는 베이스캠프(Basecamp, http://basecamphq.com)를 개발한 37시그널스(37Signals^[1])나 클라우드 스타일 루비 온 레일스( Ruby on Rails) 애플리케이션 호스팅 환경을 제공하는 엔진 야드(Engine Yard^[2]) 등에서도 셰프를 이용해 많은 서버를 관리한다. 공식 페이지(http://www.opscode.com/adoption)에서 셰프를 도입한 회사 목록을 볼 수 있다. 이 회사들은 하나같이 서버 한두 대가 아닌 엄청난 수의 서버군(Farm)을 보유하고 있다. 물론 그렇다고 셰프를 꼭 그런 회사에서만 써야 한다는 것은 아니다. 단 한 대가 되더라도 셰프를 사용하면 여러 장점을 누릴 수 있다.

셰프는 루비(Ruby)로 작성된 프레임워크인 만큼 루비의 여러 장점을 고스란히 제공한다. 사용자가 작성할 코드는 전부 루비 기반 DSL(Domain Specific Language)을 이용하기 때문에 배우기 쉬우면서도 루비로 할 수 있는 것을 모두 할 수 있다. 또한 셰프 환경을 구축할 때 모든 것을 바닥부터 일일이 손수 만들 필요가 없다. OPSCODE만 해도 이미 설정 파일을 70개 이상 제공(http://github.com/opscode/cookbooks)하며, 다른 여러 공헌자 역시 Github 등에 자신들의 설정 파일을 제공한다. 이 중에서 자신의 환경에 맞는 설정 파일을 다운로드해 이용하면 환경 구축에 소요되는 시간을 많이 줄일 수 있다.

물론 그렇다고 셰프가 완벽하기만 한 것은 아니다. 가장 큰 단점으로는 일부 유닉스/리눅스, Mac OS X 계열만 지원한다는 것이다(엄밀히 이야기하면 셰프를 윈도우 환경에 설치하고 사용할 수는 있지만 윈도우 환경 대응 리소스 프로바이더(resource provider)가 없기 때문에 할 수 있는 작업의 종류가 그렇게 많지 않다). 그리고 루비 기반이기 때문에 처음 시작할 때 루비를 아느냐 모르느냐에 따라 약간 어려움이 생길지도 모른다. 또한 앞서 언급했듯이 셰프는 신생 소프트웨어이기 때문에 분명히 알려지지 않은 다양한 버그나 불편한 점이 실제 운영 환경에서 상상할 수 없을 정도로 나타날 수 있다. 하지만 OPSCODE가 셰프 프로젝트 위키(http://wiki.opscode.com/display/chef/Home)에서 밝혀 놓았듯이 셰프는 계속해서 많은 부분이 개선 중이며 OPSCODE만이 개선하는 것이 아니라 OPSCODE의 기여 정책에 따라 많은 개인과 기업이 셰프의 발전을 위해 노력하고 있다. 따라서 셰프의 현재 단점(그것이 여러분의 환경에서 단점에 해당한다면)은 빠른 시일 내에 개선될 것이다.

위로

셰프 아키텍처

셰프를 소프트웨어가 아닌 프레임워크라 부르는 이유는 서로 유기적으로 연결되어 운영되는 여러 부분으로 구성되어 있으며 필수적이거나 공통적인 부분은 이미 완성되어 있고, 사용자는 각자의 환경에 필요한 부분만 코드를 작성하면 되기 때문이다. 이는 스프링이나 루비 온 레일스 등을 프레임워크라 부르는 이유와 같다.

프레임워크를 이용할 때 단순히 채워야 할 부분만 채워 애플리케이션을 구성할 수도 있지만 이해 없이 시키는 것만 해서는 멀고 높게 가기 힘들다. 셰프에도 이 원리는 그대로 적용된다. 따라서 셰프를 구축하고 이용하기에 앞서 셰프의 아키텍처적인 면과 각 부분을 이루는 요소에 대해 알아보자. 먼저 셰프의 아키텍처를 개략적으로 살펴보면 다음과 같다.

셰프 환경은 셰프 서버와 셰프 인덱서(indexer), 셰프 클라이언트 로 구성된다^[3].

• 셰프 서버
  노드 인증이나 설정 등 노드 관리와 쿡북을 각 노드에 배치하는 작업 그리고 인덱스 기능 사용 등은 모두 셰프 서버를 통해 이루어진다. 또한 셰프 서버는 머브 기반 애플리케이션으로 웹을 통한 사용자 인터페이스뿐만 아니라 REST API도 제공한다. 이를 통해 관리 시스템인 셰프 서버를 관리하는 애플리케이션을 만들어 사용할 수도 있다. 즉 이론적으로는 셰프 서버 운영, 관리 또한 자동화할 수 있다. 노드 정보를 저장하기 위해 CouchDB(http://couchdb.apache.org)를 사용한다.
• 셰프 인덱서
  인덱스 서버와 셰프 서버는 메시지 큐를 통해 서로 통신을 수행하며 이를 위해 STOMP(http://stomp.codehaus.org)를 이용한다. 셰프가 제공하는 부트스트랩 코드를 이용해 셰프 서버를 설치한다면 이때 설치되는 stompserver를 메시지 큐 서버로 사용할 수 있다. stompserver 외에 ActiveMQ(http://activemq.apache.org)나 래빗MQ(http://www.rabbitmq.com)를 사용할 수도 있다. 인덱스 서버는 Ferret(http://ferret.davebalmain.com)을 기반으로 작성되었다. 사용자는 전첵 텍스트 검색(full-text search) 엔진을 통해 현재 셰프 환경 내에 존재하는 것이라면 무엇이든 검색할 수 있다.
• 노드
  셰프에서 노드는 레시피(recipe)가 적용될 시스템을 가리킨다. 일반적으로 노드는 시스템을 뜻하지만 꼭 그래야만 하는 것은 아니다. 노드 여러 개가 단일 시스템을 가리킬 수도 있다. 각 노드는 해당 노드 고유의 OpenID(http://ko.wikipedia.org/wiki/OpenID)를 가진다. 노드에서 셰프 클라이언트 최초 실행 시 셰프 클라이언트는 해당 노드의 OpenID를 셰프 서버에 등록하고, 관리자가 셰프 서버에서 해당 OpenID의 등록을 완료(validate)하면 노드 설정이 마무리된다. 셰프 서버에서 설정된 노드에 레시피나 역할을 할당하거나 제거할 수 있다. 물론 노드 자체의 등록 취소(invalidate)나 삭제도 가능하다.

오하이(Ohai)란? 오하이 역시 OPSCODE에서 제작한 오픈 소스 소프트웨어다. 이 소프트웨어는 시스템의 각종 정보(나중에 각 노드의 속성 값이 된다)를 제공하기 위해 만들어졌다. 오하이를 통해 제공되는 시스템 정보는 레시피나 속성 등에서 매우 유용하게 사용된다. 오하이는 기본적으로 제공되는(직접 오하이를 실행해 보면 상당히 많은 정보가 추출된다는 것을 알 수 있다) 정보뿐만 아니라 사용자가 직접 플러그인을 만들어 해당 플러그인이 추출해 낸 정보를 같이 반환하도록 할 수 있다. 오하이 설치는 매우 간단하다. sudo gem source -a http://gems.opscode.com 젬 서버 주소를 추가한 후 설치 명령만 내리면 된다. sudo gem install ohai 설치가 완료되면 명령행에서 ohai라고 실행해 보자. JSON 포맷으로 각종 정보가 반환된다면 잘 설치된 것이다.

• 셰프 클라이언트
  셰프 클라이언트는 셰프 서버와 STOMP를 이용해 통신을 수행하고 OpenID를 통한 노드 인증을 담당한다. 또한 서버와 노드의 쿡북을 동기화하고 새로 다운로드한 쿡북을 컴파일하며 그것을 노드에서 실행하는 역할도 수행한다. 따라서 셰프 클라이언트는 셰프의 핵심 부분이라고 할 수도 있다. 셰프 클라이언트는 노드와 달리 시스템당 하나만 있으면 해당 시스템의 모든 노드를 관리할 수 있다. 셰프 클라이언트는 필요할 때마다 chef-client 명령을 통해 실행할 수도 있고, 백그라운드에서 주기적으로 변경 사항을 자동 검사하도록 할 수도 있다.

사실 셰프 자체의 아키텍처는 그리 이해하기 어려운 것이 아니다. 셰프 서버나 클라이언트를 설치하는 경우 역시 자체 부트스트랩 코드를 제공하기 때문에 복잡하지 않으며 직접 설정해야 할 것도 적다. 실질적으로 사용자가 잘 알아야 할 부분은 바로 쿡북과 여러 하위 요소다.

쿡북은 한 개 이상의 레시피, 정의, 자원, 속성, 파일, 라이브러리, 템플릿, 메타데이터를 묶어놓은 것이다. 셰프에서 쿡북은 배포의 기본 단위다. 예를 들어 MySQL을 위한 쿡북은 default, client, server 3개의 레시피와 설정 파일을 위한 3개의 템플릿, 2개의 속성, 1개의 메타데이터로 구성된다. 실제 ‘생선 요리’라는 주제의 요리책을 펼치면 모든 생선 요리에 기본적으로 필요한 레시피와 어떤 생선을 어떤 식으로 요리할 것인지에 따라 다른 레시피가 책 한 권 안에 존재하는 것과 같다. 쿡북은 셰프 저장소의 cookbooks 디렉터리 내부에 서브 디렉터리로 존재하며 각 쿡북 디렉터리는 아래와 같이 구성된다. 모든 디렉터리와 파일이 존재해야 할 필요는 없고 필요한 것만 있으면 된다.

attributes/
definitions/
files/
libraries/
metadata.rb
README.rdoc
recipes/
templates/

• 자원(resource)
  셰프 내에서 작업의 기본 단위다. 패키지나 파일, 디렉터리, 서비스, 심지어 크론이나 마운트도 자원으로 다룰 수 있다. 자원에 지정된 동작(action)은 적용 시점에 각 노드에서 실행된다. 이를 통해 사용자나 그룹을 생성, 삭제하거나 노드 내 서비스(웹, 데이터베이스)를 재시작할 수도 있으며, 로컬 파티션이나 원격 디렉터리를 마운트한 후 사용할 수도 있다. 현재 기본으로 제공되는 자원은 Cron, Directory, File, HTTP Request, Package, Script, Service 등 총 18가지다.
• 정의(definition)
  기존 자원을 이용해 사용자 고유의 자원을 만들어 사용할 수 있다.
• 레시피(recipe)
  레시피에는 한 개 이상의 자원이 어떤 순서로 관리되는지를 정의한다. 레시피는 다른 레시피를 포함할 수 있고, 쿡북에 정의된 속성뿐만 아니라 레시피를 적용하는 대상 노드에 정의된 모든 속성 역시 이용할 수 있다.
• 프로바이더(provider)
  자원에 지정된 동작을 실제로 수행하는 주체다. 예를 들어 다음과 같이 디렉터리 자원을 정의했다고 하자.
  

  directory "/tmp/monkey" do owner "root" group "root" mode 0755 action :create end

  
  해당 자원이 노드에 적용되면 셰프는 directory 자원을 담당할 프로바이더를 찾는다. 디렉터리는 Chef::Provider::Directory가 담당하며, 이 프로바이더는 /tmp/monkey의 상태를 확인하고 존재하지 않는다면 새로운 디렉터리를 만든다.
• 라이브러리(library)
  라이브러리는 반복적이거나 레시피에 기술하기에는 너무 길고 한눈에 알아보기 힘든 내용을 레시피 외부에 정의하고 레시피에서 사용할 수 있도록 해준다. 라이브러리는 루비 코드나 셰프의 DSL을 확장하는 형태로 작성 가능하다. 각 쿡북의 libraries 디렉터리에 위치하며, 존재하는 라이브러리 파일은 실행 시 자동으로 로딩되고 레시피나 속성, 정의에서 사용 가능하다.
• 속성(attribute)
  레시피 적용 시 노드에서 사용될 값을 지정할 수 있다. 속성이 중요한 이유는 대상 OS마다 다르게 지정해야 할 값을 레시피에 일일이 기술하거나 각각을 별도 파일로 만들 필요가 없게 해주기 때문이다. 아파치 서버를 예로 들면 데비안, 우분투 계열과 레드햇 계열 리눅스는 기본적으로 설치 시에 정해지는 아파치 설정 파일 경로나 이름 등이 좀 다르다. 이를 레시피에 일일이 기술하거나 여러 종류의 레시피를 만든다면 내용도 쓸데 없이 길어지고 복잡도만 늘어난다. 속성을 이용해 이 문제를 쉽게 해결할 수 있다. 아래 예제를 보면 어느 정도 감이 올 것이다.

  Case platform when "redhat","centos","fedora","suse" set[:apache][:dir] = "/etc/httpd" set[:apache][:log_dir] = "/var/log/httpd" set[:apache][:user] = "apache" set[:apache][:binary] = "/usr/sbin/httpd" when "debian","ubuntu" set[:apache][:dir] = "/etc/apache2" set[:apache][:log_dir] = "/var/log/apache2" set[:apache][:user] = "www-data" set[:apache][:binary] = "/usr/sbin/apache2" else set[:apache][:dir] = "/etc/apache2" set[:apache][:log_dir] = "/var/log/apache2" set[:apache][:user] = "www-data" set[:apache][:binary] = "/usr/sbin/apache2" end

• 파일(file)
  모든 것이 작성하는 코드만을 이용해 해결된다면 세상은 정말 행복할 것이다. 하지만 실제로는 종종 필요한 파일을 직접 업로드해야 할 경우가 발생한다. 예를 들어 각 리눅스/유닉스 시스템의 패키지 관리자가 지원하지 않는 파일을 설치해야 한다거나, 직접 제작한 파일을 각 시스템에 배포해야 하는 경우가 그러하다.
• 템플릿(template)
  파일과 매우 비슷하지만 한 가지 결정적인 다른 점은 노드에 템플릿이 전송될 때 렌더링 작업을 거친 후 전송된다는 것이다. 각 노드의 시스템 속성 및 정의된 속성이 템플릿 렌더링 시 사용된다. 이것이 의미하는 바는 앞서 속성에서 언급한 바와 같이 각 노드 별로 달라야 하는 값 때문에 설정 파일을 여러 개 만들 필요가 없다는 것이다. 템플릿 렌더링에는 Erubis(http://www.kuwata-lab.com/erubis), 즉 ERB 파일이 이용된다. ERB 파일은 머브나 레일스, 또 다른 루비 기반 시스템 관리 소프트웨어인 puppet(http://reductivelabs.com/trac/puppet)에서도 사용된다.
• 역할(role)
  노드에 적용될 여러 레시피와 속성의 집합이다. 노드 하나에 하나 이상의 역할을 할당할 수 있다. 역할은 레시피나 속성을 역할의 특성에 맞게 쉽게 조합 가능하며, 역할 이름이 무엇을 하는지 명확히 나타내주기 때문에 차후 유지보수에도 도움이 된다. 예를 들어 필자의 회사에서 구축한 시스템은 여러 파트로 나뉘는데 이미지 프로세싱 서버는 내부적으로 아파치 ActiveMQ 서버와 직접 개발한 루비 데몬, 스카이넷(Skynet)이라는 분산 프로그래밍용 프레임워크가 실행된다. 이때 ActiveMQ, Worker, 스카이넷을 담당하는 레시피를 만든 후 필요한 노드에 각각 할당할 수도 있지만, 세 레시피를 ImageProcessingServer라는 역할로 묶은 뒤 그 역할을 필요한 노드에 할당할 수도 있다. 후자 쪽이 나중에 새 시스템이 추가되었을 때 무엇을 할당해야 할지 더욱 명확하게 해주고, 필요한 레시피를 실수로 누락하지 않도록 해준다.
• 메타데이터(metadata)
  셰프 서버가 각 노드에 제공하는 몇 가지 기본적인 정보를 담고 있다. 각 쿡북의 최상위 디렉터리에 metadata.rb 파일을 만들고 필요한 내용을 기술하면 해당 파일은 JSON파일로 컴파일된 후 셰프 환경에서 사용된다.

위로

셰프로 클라우드 시대를 준비하자

지금까지 셰프 서버의 아키텍처와 각 구성요소에 대해 알아보았다. 셰프는 cfengine부터 puppet까지 이어져온 오픈 소스 시스템 관리 도구 중 가장 최근에 소개된 도구다. 그럼에도 쿡북의 리비전(revision) 관리나 REST API 제공, 쉽고 간결한 루비 기반 등 기존 도구나 프레임워크보다 장점이 많다. 또한 젊은 오픈 소스의 장점인 필요한 요소는 적절히 갖췄으면서도 무겁지 않은 코드, 셰프 개발자 및 여러 기여자의 활발한 참여로 지속적으로 발전하는 점 역시 이전 도구나 프레임워크와는 비교되는 점이다. 게다가 앞서 언급했듯이 이미 실제 비즈니스 환경에서도 안정적으로 잘 사용되고 있다.

요즘처럼 시스템 종류가 다양하고 클라우드 컴퓨팅 환경이 보편화된 시대에는 이전처럼 직접 개발한 스크립트 묶음이나 일일이 손수 입력하는 명령만으로는 유지가 어려운 것이 사실이다. 이제 셰프를 여러분의 주방에 직접 도입해 볼 시간이다. 다음 연재에서는 실제 셰프환경 구축과 쿡북 생성, 적용, 관리 등에 대해 실제 사용되는 예제와 함께 알아보자.

주

^[1] http://37signals.com 루비 온 레일스의 산실이다. 개발 방법론이자 운영 철학인 “Getting Real”은 꼭 한 번쯤은 읽어볼 만하다.

^[2] 루비 웹 프레임워크의 또 다른 양대 산맥이었던 머브(Merb)의 개발자가 설립했으며 루비 온 레일스뿐만 아니라 JRuby나 Rubinius 등에도 많은 공헌과 지원을 하고 있다.

^[3] 실제로는 셰프 솔로(solo)를 이용해 셰프의 이점을 누릴 수 도 있다. 셰프 솔로는 셰프 서버 없이 쿡북을 실행할 수 있게 해주는데 서버에 대한 권한이 제한되어 있거나, 클라이언트 대상 노드가 셰프 저장소 서버와 다른 보안 레벨 영역에 있거나, 관리보다는 한 번의 설치만을 위해서라면 셰프 솔로를 이용할 수 있다. 하지만 사용자 및 노드 인증이나 인덱스 기능, 영속(persistent) 속성 등 셰프 서버를 이용할 때의 장점을 누릴 수 없다. 이 글에서 셰프 솔로는 자세히 다루지 않겠다.

mar.gar.in

naver

eolin

del.icio.us

이제 전문가의 글을 단순히 ‘보는 것’에서, 직접 여러분이 developerWorks의 필자가 될 수 있습니다. IBM developerWorks를 통해 공유하고 싶은 지식이 있으신 분들은 원고 기획안을 접수해주세요. 채택되신 분께는 소정의 원고료를 드립니다.

필자 지원하기

[지난 Open dW 보기]