지난 포스트에서 이야기한 것과 같이 MP에는 WCF 서비스 코드와 그를 호출하는 코드를 생성하는 기능이 있습니다.

지난 포스트에서는 BasicHttpBinding 바인딩을 사용하는 사용했었는데, 오늘은 NetTcpBinding 을 사용하는 방법에 대해서 이야기를 해보겠습니다.

0. IIS 의 구성

BasicHttpBinding 은 IIS 에서 기본적으로 지원하지만, NetTcpBinding 은 별도의 호스팅 애플케이션이 필요합니다.

하지만 IIS 7.0 부터는 IIS 에서 HTTP 이외의 바인딩도 직접 호스팅하는 기능이 포함되어 있습니다.

IIS 에서 NetTcpBinding 을 지원하기 위해서는 먼저 이 글의 설명대로 IIS 를 구성하여야 합니다.

위 링크의 4번 단계 까지만 진행하고 나머지는 본 포스트의 설명을 계속 읽어주십시오.

1. web.config 파일 설정

지난 포스트에서 만든 Memopad 솔루션을 계속 예제로 사용하겠습니다.

MP가 생성한 Memopad.Service 프로젝트의  MemopadDataService.svc 파일을 열어 보면 마지막에 web.config 용 샘플이 생성되어 있습니다.

그 중에서 NetTcpBinding 부분을 복사하여 아래와 같이 web.config 파일에 붙여넣습니다.

바인딩의 여러 속성이 최대값으로 지정이 되어 있는데, 실 서버에 배포하기 전에는 적당히 조정을 하여야 합니다.

2. 서비스 클라이언트의 구성

Memopad.Biz 프로젝트의 Biz.cs 파일에는 역시 WCF 서비스 클라이언트용의 샘플 코드가 있습니다.

지난 번에 설명한대로 ServiceFactory 클래스를 만들고 위 샘플 코드에서 아래와 같은 두 메서드를 복사합니다.

주소가 localhost 로 되어 있는데, NetTcpBinding 은 BasicHttpBinding 과 달리 비주얼 스튜디오의 내장 웹 서버가 호스팅 할 수가 없습니다.

따라서 별도의 호스트 애플리케이션을 만들어야 하는데, 자세한 설명은 MSDN의 설명을 참고하십시오.

여기서는 실 서버의 IIS 에 호스팅하는 예를 보이겠습니다.

3. 서비스의 게시

솔루션 탐색기에서 Memopad.Service 프로젝트를 우클릭하고 게시를 선택합니다.

실서버에 서비스를 게시할 수 있는 방법을 지정하여야 하는데, 여기서는 FTP 를 사용하였습니다.

FTP 의 주소는 적절한 값으로 설정하시기 바랍니다.

여기서는 ftp://실서버의 IP/Memopad.Service 라고 설정하였습니다.

게시가 끝났으면 실서버에서 IIS 관리자를 실행한 후 방금 게시된 가상 디렉토리를 응용 프로그램으로 변환하여야 합니다.

이 때 주의할 점은 응용 프로그램 풀이 Memopad.Service 가 사용하는 닷넷프레임웍 버전을 지원하여야 한다는 것입니다.

이 예제에서는 Memopad.Service 가 닷넷프레임웍 4.0을 사용하므로 닷넷프레임웍 4.0 응용 프로그램 풀을 지정하였습니다.

마지막으로 위 응용 프로그램이 NetTcpBinding 을 지원하도록 설정하여야 합니다.

위 응용 프로그램의 고급 설정 창을 연 후, 사용할 수 있는 프로토콜을 아래와 같이 설정합니다.

이제 IIS 설정이 모두 끝났습니다.

다시 Memopad.Biz 프로젝트로 돌아가 (사용자가 생성한) ServiceFactory 클래스를 열어 WCF 서비스의 주소를 방금 게시한 주소를 변경합니다.

net.tcp://실서버의 IP/Memopad.Service/MemopadDataService.svc 와 같은 식으로 지정하면 됩니다.

4. 테스트

모든 작업을 마쳤으니 제대로 동작하는지 테스트를 해봅시다.

Memopad.TestConsole 프로젝트의 Program.cs 파일에 아래와 같은 코드를 작성합니다.

예외가 발생하지 않고 정수가 출력되면 모든 것이 정상입니다.

복습 삼아 지난 시간에 한 이야기를 다시 하자면, Memopad.Biz 프로젝트의 등록정보에서 ForService 라는 기호가 정의되어 있을 때에만 WCF 서비스를 호출합니다.

(정의되어 있지 않으면 서비스를 호출하는 대신 DB에 바로 접속합니다.)

따라서, Memopad.Biz 프로젝트에 ForService 가 정의되어 있고, Memopad.TestConsole 프로젝트의 app.config 파일에 DB 연결문자열이 없는 상태에서,

위 Program.cs 파일의 테스트 코드가 작동한다면, WCF 서비스가 제대로 구축되어 있다고 할 수 있겠습니다.

본 포스트의 샘플 파일 :

Memopad.zip

간단한 윈도우즈 자동 종료 프로그램을 만들어 보았습니다.

이런 류의 프로그램들이 워낙에 많이 있지만, 설치하기가 귀찮아서 저 같은 경우는 보통 시작 –> 실행 에서 shutdown 명령을 치곤 합니다.

shutdown 명령의 옵션을 조합함에 따라 종료 방법 (종료, 로그오프, 최대절전모드, 리부팅)과 종료 시간을 지정할 수 있는데, 아쉽게도 최대절전모드와 로그오프의 경우에는 종료 시간을 지정할 수 없습니다. (즉시 실행만 가능)

그래서 하나 만들어 보았습니다.

설치는 아래 첨부 파일로 실행을 하면 되고, 혹 나중에 새로운 업데이트가 있으면 자동으로 반영이 됩니다.

app.zip

닷넷 프레임웍 4.0의 경량 버전 (클라이언트 프로파일)이 필요한데, 설치되어 있지 않다면 위 파일 설치 시 자동으로 설치 됩니다.

물론 위 설치 파일에는 바이러스나 기타 어떠한 나쁜 코드도 들어 있지 않습니다.

워낙에 간단한 프로그램이긴 하지만 어쨌든 소스 파일도 첨부합니다.

 GenericTimer.zip

원문 : http://msdn.microsoft.com/ko-kr/magazine/hh965663(en-us).aspx

MS에서 또 개발자들에게 고마운 선물을 하나 주려나 봅니다.

웹(HTTP)은 원래 비연결지향적으로 설계되었습니다.

즉, 클라이언트가 서버에게 요청을 하면 서버가 그에 대한 응답을 주는 방식입니다.

바꿔 말하면 클라이언트가 요청하지 않았는데 서버가 먼저 어떤 정보를 줄 수는 없는 구조입니다.

따라서 채팅과 같은 대부분의 네트웍 프로그램은 순수한 HTTP 프로토콜만으로는 구현하기가 힘이 듭니다. (물론 HTML5의 웹소켓을 제외한 이야기입니다.)

서버가 클라이언트에게 요청을 할 수 없으니, 클라이언트가 주기적으로 계속 서버에게 자신에 줄 정보가 있는지를 물어보는 구조가 될 수 밖에 없는데, 이른바 폴링(polling)입니다.

(제가 아는 한에서는) AJAX를 통하여 비동기로 서버에 폴링을 하는 방법을 사용하는 것이 통상적인 경우일 것 같은데, 이 경우의 문제는 수 많은 클라이언트들로부터 폴링을 받아야 하는 서버의 부담이 너무 크다는 것을 들 수 있겠습니다.

이러한 문제에 대한 한 가지 해법으로, MS의 두 개발자가 닷넷 프레임웍4의 병렬 프로그래밍 기술을 기반으로 하여 게시/구독 패턴을 구현한 라이브러리를 발표하였는데 그 이름이 SignalR 이라고 합니다.

(아직 0.5 버전이니 발표하는 중이라고 해야겠네요.)

서버는 물론 ASP.NET으로 구현이 되어야 하지만, 클라이언트는 jQuery를 지원하기만 하면 된다니까 크롬이나 사파리, 심지어 모바일 브라우저에서도 쓸 수 있다고 합니다.

게다가 향후에는 웹이 아닌 데스크탑 애플리케이션도 클라이언트가 될 수 있다고도 합니다.

저는 오랫동안 게시/구독 패턴에 입각한 (윈폼용) 라이브러리를 꼭 가지고 싶었습니다.

그런 라이브러리가 있다면 상당히 많은 일을 할 수 있을 것 같아, 직접 만들어보기도 하고 또 다른 사람들이 만든 수 많은 라이브러리들을 검토해보기도 하였는데, 안심하고 신뢰할 만한 것은 아직 발견하지 못하였습니다.

어쩌면 이 SignalR 이라는 라이브러리가 제가 오랫동안 찾던 바로 그 라이브러리가 될 수도 있겠지요.

추신 : 말 그대로 여담인데, 게시/구독 패턴을 구현할 때 굳이 TCP를 고집할 이유는 없을 것 같습니다.

UDP를 사용하는 것도 괜찮은 방법이고, WCF의 DuplexBinding을 사용하는 것도 좋은 방법인 것 같습니다.

다만 WCF는 소켓을 직접 다루는 것에 비하면 확실히 무거우니, 현재로서는 UDP에 한 손을 들어주고 있습니다.

0. DB 스키마 준비

파트 I과 동일한 스키마를 사용하니, 파트I을 참조하십시오.

1. 솔루션의 생성

MP를 실행한 후 Tool –> Generate Solution을 실행합니다.

이번에는 LINQ2SQL Use Service를 선택합니다.

생성된 솔루션을 비주얼 스튜디오에서 엽니다.

4개의 프로젝트가 생성이 되는데 각 역할은 다음과 같습니다.

• Test Console : 간단한 테스트용(단위 테스트와 상관 없음) 코드를 작성하기 위한 콘솔 프로젝트입니다.
• Data : 데이터 엑세스 레이어입니다. DBML 파일이 위치하고 있으며, 파트1의 Biz 프로젝트와 유사한 역할을 합니다.
• Service : Data 프로젝트에서 만든 데이터 엑세스 메서드(MP가 생성한 코드 + 사용자가 만든 코드)를 래퍼하는 WCF 메서드가 있습니다.
• Biz : Service 메서드를 호출하는 래퍼 메서드가 있습니다. Data와 Service 프로젝트와는 달리 클라이언트 측에 위치합니다.

아래 그림은 각 프로젝트 간의 실행 흐름입니다.

푸른색은 클라이언트에서 실행되는 코드, 붉은색은 (WCF가 실행되는) 서버에서 실행되는 코드입니다.

아주 중요한 그림이니 좀 있다 한번 더 말씀 드리겠습니다.

2. DBML의 작성

역시 파트I과 동일합니다.

3. 데이터 레이어 코드 생성

서비스를 사용하는 솔루션에서는 MP가 두 단계의 코드를 생성합니다.

첫번째 단계는 DBML 파일을 소스로 하여 데이터 엑세스 코드를 생성하는데, 파트I에서는 이 기능 만을 사용합니다.

두번째 단계는 Data 프로젝트를 빌드한 결과인 DLL (여기서는 Memopad.Data.DLL)을 소스로 하여, 이 DLL에 있는 메서드 들에 대한 래퍼 메서드를 생성하는 단계입니다.

먼저 첫번째 단계부터 진행을 하겠습니다.

MP에서 위에서 생성된 Memopad.mp 파일을 열고, Generate –> Data를 실행하여 코드를 생성합니다.

솔루션탐색기에서 Show All Files 버튼을 클릭하여 MP가 생성한 파일을 표시합니다.

Generated 폴더에서 오른쪽 버튼을 클릭한 후 Include In Project를 선택합니다.

두번째 단계를 진행하기 위해 먼저 커스텀 메서드를 만들어 보겠습니다.

Entities 폴더에 Memo 클래스를 추가하고 아래와 같이 코드를 작성합니다.

WCF 서비스를 통과해야 하므로 DataMember 특성을 추가하여야 합니다.

다음에는 Data 폴더에 MemoData 클래스를 추가하고 아래와 같이 코드를 작성합니다.

ForService 특성이 지정되어있는데, 이 특성은 MP로 하여금 이 메서드에 대한 서비스 레이어 코드를 생성하라는 것을 지시하는 역할을 합니다.

이제 비주얼 스튜디오에서 빌드를 하여 Memopad.Data.DLL을 생성합니다.

4. 서비스 레이어의 생성

다시 MP에서 Generate –> Service 를 실행하여, 서비스와 비지니스 코드를 생성합니다.

코드를 생성하고 나면 아래와 같은 메시지 박스가 나오는데, 이는 현재 MP의 해결하지 못한 버그입니다.

아래 그림과 같이 Biz 프로젝트에서 MP가 생성된 코드들을 추가합니다.

5. 솔루션 구성 테스트

솔루션이 적절히 구성되었는지 테스트를 할 차례입니다.

먼저 Memopad.Biz 프로젝트에 ServiceFactory 클래스를 추가하고 아래와 같이 코드를 작성합니다.

WCF 서비스가 배포된 주소를 지정하여야 하는데, 위 그림은 비주얼 스튜디오에 내장된 개발 서버를 사용하는 경우의 예입니다.

예에서는 54179 포트를 사용하는데 물론 사용자마다 다를 것입니다.

Memopad.Service 프로젝트의 속성 중 Web 탭에 있는 정보를 참고하여 적절한 포트번호를 지정하면 되겠습니다.

Memopad.Service 프로젝트의 web.config 파일을 열어 DB 연결문자열을 적절히 수정합니다.

TestConsole 프로젝트의 Program.cs 파일에 아래 코드를 작성하여 솔루션이 제대로 구성되었는지 확인합니다.

TestConsole 프로젝트를 시작 프로젝트로 지정한 후 실행해서 예외가 발생하지 않고 정수 값이 출력되면 정상입니다.

6. 실행 흐름

이해를 돕기 위해 여기까지의 과정을 메서드의 실행흐름을 중심으로 정리해 보겠습니다.

클라이언트(즉 위에서는 TestConsole)에서 Bizrepository.Memo.GetCount 메서드를 호출하면 MemoBizBase 클래스의 GetCount 메서드가 호출됩니다.

이 메서드는 사용자 지정 비니지스 로직을 추가하기 위해 가상으로 지정되어 있습니다. (잠시 후에 좀 더 이야기를 해보겠습니다.)

그리고 ServiceFactory.GetService 메서드를 호출하여 IMemopadDataService ServiceContract 특성이 지정된 인터페이스를 구현한 객체를 생성합니다.

CreateBinding 메서드와 GetAddress 메서드는 각각 내부적으로 부분 메서드인 CreateBindingCore 와 GetAddressCore 를 호출하는데, 이 부분 메서드들을 사용자가 설정하면 각각 바인딩과 서비스의 주소를 재지정할 수 있습니다.

위에서 GetAddressCore 메서드를 구현한 것이 바로 주소를 지정하는 단계였습니다.

IMemopadDataService 인터페이스에는 데이터 엑세스 레이어의 메서드 중 ForService 특성이 붙은 메서드들이 모두 포함되어 있습니다.

위 그림에서 Memo_GetByCategoryName 은 사용자가 작성한 커스텀 메서드이고, Memo_GetByPK 는 MP가 자동 생성한 메서드 중 하나 입니다.

다시 Bizrepository.Memo.GetCount 메서드로 돌아가서, 서비스 객체를 만들고 나면 이를 이용해서 서비스 메서드를 호출합니다.

이 서비스 메서드 역시 MP가 생성하는데, 아래와 같습니다.

단순히 MemoData 클래스를 만든 후 GetCount() 메서드를 호출합니다.

사실 MemoData 클래스에는 GetCount 메서드가 없습니다.

GetCount 메서드는 MemoData 의 부모 클래스인 EntityData<T> 에 저장되어 있습니다.

이 GetCount 메서드는 내부적으로 몇 개의 오버로드를 거치게 되는데 최종적으로 실행되는 메서드는 아래와 같습니다.

DbContext 객체를 생성하는 일을 하는 DataContextFacotry.Create 메서드를 제외하면, 모두 닷넷 프레임웍이 기본 제공하는 코드입니다.

그래서 MP가 생성한 코드는 여기가 마지막입니다.

6. 커스텀 비지니스 로직의 추가

커스텀 비지니스 로직을 추가하기 위해서는 각 엔터티의 BizBase 클래스를 상속 받는 클래스를 만들고 해당 메서드를 오버라이드 하여야 합니다.

사실 MP에는 이 BizBase 클래스를 상속 받는 클래스들이 이미 만들어져 있습니다.

이미 클래스가 만들어져 있으니, 동일한 이름으로 부분 클래스를 Memopad.Biz 프로젝트에 추가하고 아래와 같이 비지니스 로직을 추가합니다.

위 예에서는 단순히 파라미터의 유효성을 검사하는 코드를 추가하였습니다.

여기서 유심히 볼 부분은 바로 부모인 MemoBizBase 의 GetByCategoryName  메서드를 오버라이드하고, 커스텀 비지니스 로직 호출 전/후에 부모 클래스의 해당 메서드를 다시 호출하는 패턴이 되겠습니다.

7. 맺음말

MP는 단순한 코드가 아니라 프레임웍을 생성하는 것을 목표로 하고 있습니다.

그래서 비주얼 스튜디오의 솔루션 전체를 생성하는 기능을 제공하는 것인데, 이 솔루션에는 N-티어 아키텍쳐의 각 레이어에 해당하는 프로젝트들이 포함되어 있으며, 각 프로젝트에는 해당 프로젝트가 필요로 하는 어셈블리가 이미 참조되어 있고, 필수적으로 필요한 코드가 포함되어 있습니다.

물론 MP가 생성하는 솔루션의 아키텍쳐가 실무의 요구사항을 모두 만족하지는 않을 것입니다.

다만 MP는 N-티어 아키텍쳐와 LINQ에 익숙하지 않은 개발자에게, 솔루션을 어떻게 구성하고 어떤 코드를 어떤 레이어에 작성해야 하는가와 같은 문제에 대한 가이드 역할을 하고자 합니다.

온라인에서 글쓰기를 하면서 ‘지면관계상’ 이라는 말을 쓸 수는 없지만, MP를 설명하는 이 포스트에는 정말 많은 부분이 누락되어 있습니다.

관용적인 표현이 아니라, 정말로 열의 하나도 설명을 다 하지 못했습니다.

물론 MP를 만든 제가 친절하게 설명을 하는 것도 중요하지만, 결국에는 스스로 연구하고 습득하는 수 밖에 없을 것 같습니다.

이왕 MP를 공개까지 하였으니, 책임감을 느낌과 함께 가급적이면 개발자들의 공동체에 도움이 되었으면 합니다.

MP의 소스 코드 역시 곧 공개하겠습니다.

MP 자체가 전 세계 개발자 공동체에서 제가 직간접적으로 전수 받은 지식으로 만들어진 것이니 당연한 일이겠지요.

0. DB 스키마 준비

먼저 DB 스키마가 구성되어 있어야 할 것입니다.

여기서는 Memopad 라는 데이터베이스를 만들어 사용하겠습니다.

아래 파일은 위 스키마에 대한 생성 스크립트입니다.

invalid-file

1. 솔루션의 생성

MP에는 비주얼 스튜디오 솔루션 템플릿이 내장되어 있습니다.

이 기능을 이용하면, MP가 추천하는 형태대로 프로젝트가 미리 구성된 솔루션을 쉽게 생성할 수 있습니다.

MP를 실행시킨 후 Tool –> Generate Solution 을 실행합니다.

Template은 LINQ2SQL Basic, Solution Name은 생성할 솔루션 이름, Folder는 솔루션을 생성할 폴더를 지정한 후, OK 버튼을 누릅니다.

솔루션을 생성하고 나면 비주얼 스튜디오에서 열겠냐고 물어보는데, 예를 선택하여 솔루션을 엽니다.

두 개의 프로젝트가 생성되는데, Memopad.Biz는 데이터 액세스 레이어와 비지니스 레이어가 결합된 프로젝트이고, Memopad.TestConsole 프로젝트는 Biz 프로젝트를 테스트하기 위한 용도의 콘솔 프로젝트입니다.

Memopad.mp 파일은 MP의 템플릿 파일입니다.

Biz와 Entities 폴더는 각각 사용자가 작성하는 비지니스 클래스와 엔터티 클래스가 들어갈 곳입니다. (DeleteMe.txt 파일들은 부모 폴더를 생성하기 위해 만든 더미 파일이니 삭제하시면 됩니다.)

Generated 폴더 안에는 MP가 생성할 코드가 들어갈 곳입니다. 이 폴더 안의 코드는 개발자가 직접 수정하지 않아야 합니다.

2. DBML의 작성

(비주얼 스튜디오에서) Memopad.dbml 파일을 열고 서버 탐색기에서 Memo 테이블과 Category 테이블을 끌어옵니다.

N-Tier에서 LINQ-toSQL를 사용하기 위해서는 각 엔터티 프로퍼티의 Update Check 값이 Never로 설정이 되어야 합니다.

아래는 Memo 엔터티중 MemoID 프로퍼티의 예인데, 이런 식으로 모든 프로퍼티가 설정되어야 합니다.

엔터티와 프로퍼티 수가 많으면 제법 번거로운 작업이 될 수 있는데, MP에는 이 작업을 쉽게 할 수 있는 기능도 내장되어 있습니다.

MP에서 Tool –> Add Update Check를 실행한 후, 위 DBML 파일을 선택합니다.

여기서 중요한 점이 있는데, 위와 같이 Update Check를 설정한 후에는 반드시 비주얼 스튜디오에서 DBML 파일을 다시 열고 나서 저장을 해야 한다는 것입니다.

그렇게 해야 Update Check 값이 Never가 지정된 상태에서 비주얼 스튜디오가 코드를 생성합니다.

3. MP의 코드 생성

MP에서 위에서 생성된 Memopad.mp 파일을 열고, Generate –> Data를 실행하여 코드를 생성합니다.

이제 MP에 의해 생성된 코드가 Generated 폴더 안에 생겼습니다.

이 시점에서 솔루션이 제대로 구성되었는지 테스트를 해볼 수 있습니다.

TestConsole 프로젝트를 시작 프로젝트로 설정한 후 app.config 파일을 열어 아래와 같이 DB 연결 문자열을 수정합니다.

Program.cs 파일을 연 후 아래 코드를 입력한 후 프로젝트를 실행합니다.

별다른 예외가 발생하지 않고 정수값이 출력되면 성공입니다.

4. 커스텀 비지니스 클래스의 작성

위 단계에서 각 엔터티 마다 20개 이상의 데이터 엑세스 메서드가 생성이 되었습니다.

특히 Get 메서드의 경우 필터링 / 정렬 / 페이징을 각각 포함하는 8개의 오버로드가 제공되어 바로 사용할 수도 있지만, 여기서는 Memo 엔터티에 대한 커스텀 메서드를 하나 만들어 보겠습니다.

만들려고 하는 메서드는 아래와 같습니다.

카테고리 이름을 검색 조건으로 하여 Memo 엔터티를 검색하는 메서드인데, 이때 반환되는 각 Memo 엔터티에는 카테고리 이름이 포함되어 있습니다.

즉 다음과 같은 쿼리를 실행하는 메서드입니다.

먼저 Memo 엔터티가 카테고리 이름을 가져야 하므로 Memo 엔터티에 CategoryName 이라는 속성을 추가해야 합니다.

물론 Memo 클래스는 DBML을 저장할 때 비주얼 스튜디오가 생성하는 코드이므로, 여기서는 부분 클래스로 만들어야 합니다.

Entities 폴더 안에 Memo 클래스를 추가합니다.

(이 스샷은 조금 있다 사용할 MemoBiz 클래스도 같이 추가해 둔 상태입니다.)

새로 만든 Memo 클래스를 부분 클래스로 지정하고 CategoryName 프로퍼티를 정의합니다.

네임스페이스를 기존 Memo 클래스와 동일하게 맞추고, partial 키워드를 지정합니다.

이번에는 MemoBiz 클래스를 추가하고 아래와 같이 LINQ 코드를 작성합니다.

역시 네임스페이스를 맞추고 partial 키워드를 지정합니다.

위 코드에서 쿼리 내용에 대해서는 여러 가지 이야기할 포인트가 많으니, 별도의 포스트에서 다루도록 하겠습니다.

여기까지 해서 서비스 레이어를 두지 않는 형태의 솔루션을 만들어 봤습니다.

다음 포스트에서는 서비스 레이어를 생성하는 형태에 대해서 이야기해 보겠습니다.

3년 이상 필드에서 사용하며 계속 다듬었더니 이제 공개할 만한 수준이 된 것 같습니다.
오래 기다리셨습니다.

현재 버전은 3.0.12 입니다. 그래서 처음 설치하면 3.0.12 버전이 설치가 되는데, 재실행 하면 최신 버전으로 업데이트가 됩니다.

Midnight Peach에 관한 예전 포스트들은 1.X대 혹은 2.X대 버전에 맞춰진 것들이 많아, 현재 버전과 맞지 않는 내용이 많습니다.
이제 공식적으로 배포도 시작하고 했으니, 가급적 빨리 업데이트를 하도록 하겠습니다.