캘린더 표준으로 알아보는 일정관리 S/W의 구현방법

1. 일정관리 시스템 - 크레디 메일

지난번 일정관리 S/W에 대한 소개글에 이어서 이번에는 두번째 시간으로 캘린더 표준에 기반한 일정관리 시스템의 구현에 대해서 좀 더 자세히 알아보는 시간을 갖도록 하겠습니다. 일정 관리 S/W는 개방형 캘린더 표준 포맷을 지원함으로써 다른 일정 관리 S/W 들과 호환성을 확보할 수 있습니다. 저희 회사의 메일 솔루션인 크레디메일에서는 최근 일정관리 부분을 리모델링 하였으며, 곧 선보일 예정입니다.
 
일정관리 기능을 구현하기 위해서 다양한 일정관리 시스템을 벤치마킹 하였으며, 새로 개편되는 일정관리 시스템의 UI 부분은 RIA(Rich Internet Application)로 각광받고 있는 Adobe사의 FLEX 기술을 이용하여 구현하였습니다. 그리고 다양한 일정관리 시스템과 일정 데이터를 공유하기 위해한 표준적인 데이터 연동방식을 지원해야 합니다. 아래에는 이번에 리모델링된 일정관리 기능의 화면을 월간일정/주간일정/일일일정을 간단히 보여드리면 아래와 같습니다.

월간일정

주간일정

일일일정

2. 캘린더 표준에 근거한 일정 관리 시스템의 설계

최근 웹 2.0 기반 일정관리 시스템 중에서 UI상의 기술로 분류하자면 현재 여러분이 가장 많이 사용하시고 있는 구글 캘린더나 다음 캘린더와 같은 Ajax로 구현된 것들과, 싸이월드 플래너와 같이 Flex를 기반으로 나눌 수 있습니다. UI상의 차이점에 대해서는 다음 기회에 논의하기로 하며, 본 기사에서는 캘런더 표준을 기반으로 어떻게 데이터를 저장하여 관리하는가에 대해서 간단히 설명할 것입니다..

 iCalendar 포맷이라고 알려진 캘린더 표준에 관한 자세한 내용은 http://www.imc.org/pdi 나 http://www.ietf.org/rfc/rfc2445.txt에서 볼 수 있습니다. 대부분의 일정관리 시스템은 입력된 일정을 그룹별로 관리하며 하나의 그룹에 대해서 일정 정보를 ics 포맷 파일로 저장할 수 있습니다. plain text 형태의 ics 파일을 열어보면 다음과 같은 항목들이 존재합니다.

 - 일반적인 ics 파일의 형태

ics 파일 포맷은 일반적으로 그룹에 대한 정보와 일정에 대한 정보로 나뉘어 집니다. 그룹은 아래의 박스안에서 처럼 BEGIN:VCALENDAR 로 시작하여 END:VCALENDAR로 끝나며, 그 다음의 상자 내용처럼 BEGIN:VEVENT로 시작하여 END:VEVENT로 끝나는 일정들이 반복하게 됩니다.

BEGIN:VCALENDAR
 캘린더 헤더 <- 그룹에 대한 정보 등을 저장하고 있음
 BEGEN:VEVENT<- 일정은 VEVENT의 연속으로 표현한다.
 .....
 END:VEVENT
 BEGEN:VEVENT
 .....
 END:VEVENT
 .....
 .....
END:VCALENDAR

일반적인 일정관리 시스템들은 하나의 그룹에 대해서 여러개의 일정을 관리하는 형태로 구현되며, 이것은 하나의 ics파일로 추출될 수 있습니다. 즉, 그룹에 대한 정보가 캘린더 헤더 정보로 표현되며, 그룹에 속한 일정들은 VEVENT로써 표현될 수 있는 것입니다. 이때 논리적 모델링에서 그룹과 일정은 1:M relation을 가지며, M측은 1쪽의 식별자(PK)가 들어오게 되어 참조할 수 있는 연결고리 컬럼으로 정의 됩니다.
 
- 헤더 항목
헤더 항목에는 일정을 포함한 그룹의 정보를 나타냅니다. 그룹이름(X-WR-CALNAME)을 중심으로 여러가지 부가 정보를 포함하며, 크레디 메일의 일정관리 시스템의 그룹에 대한 정보와 매핑 됩니다.

BEGIN:VCALENDAR
PRODID:-//MOBIGEN Co.,Ltd.//CrediMail4.x//KO
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:PRIVATE
X-WR-CALNAME: 캘린더 제목
X-WR-TIMEZONE:Asia/Seoul
X-WR-CALDESC: 캘린더 설명
BEGIN:VTIMEZONE
TZID:Asia/Seoul
X-LIC-LOCATION:Asia/Seoul
BEGIN:STANDARD
TZOFFSETFROM:+0900
TZOFFSETTO:+0900
TZNAME:KST
DTSTART:20080712T000000
END:STANDARD
END:VTIMEZONE

- VEVENT 항목

BEGIN:VEVENT와 END:VEVENT 사이에 하나의 일정이 존재하며, 현재의 일정 관리시스템의 데이터를 다른 시스템으로 이전할때도 마찬가지로 아래와 같은 형태로 작성되어야 합니다. DTSTART와 DTEND의 VALUE가 DATE이면 일정의 시작과 종료일이며 참고로 DTEND는 종료일 + 1일을 한 값을 저장합니다. VALUE에 시간정보까지 포함되어 있으면, 시간정보가 포함된 일정이며, 전자의 경우는 all day(종일) 이라고 부르는 일정으로 표현된 것입니다.

RRULE은 반복을 나타내는데, 반복에는 일(FREQ=DAILY)/주(FREQ=WEEKLY)/월(FREQ=MONTHLY)/년(FREQ=MONTHLY)/특정 요일 등이 있으며 종료일(UNTIL=YYMMDD)도 지정할 수 있습니다.

SUMMRY는 일정의 제목을 의미하며, DESCRIPTION은 일정에 관한 설명을, LOCATION은 관련된 장소를 의미합니다. CREATED는 일정이 생성된 시각을 LAST-MODIFIED는 마지막으로 일정이 수정된 시간, DTSTAMP는 관리상의 목적으로 ics파일이 추출된 시각을 의미합니다.

CLASS는 공개여부를 PUBLIC과 PRIVATE 으로 구분하여 표시하며, TRANSP 항목은 일정이 긴급함을 나타냅니다. TRANSPARENT는 한가함을 OPAQUE는 바쁨을 의미합니다.

BEGIN:VEVENT
// 일일 설정
DTSTART;VALUE=DATE:20080709  => 시작일
DTEND;VALUE=DATE:20080719    => 종료일 + 1일

// 시간반복
DTSTART;TZID=Asia/Seoul:20080605(시간반복 시작 일)T100000(시작시간)  => 시간반복항목
DTEND;TZID=Asia/Seoul:20080605(시간반복 시작 일)T110000(종료시간)    => 시간반복항목
RRULE:FREQ=DAILY;UNTIL=20080613(시간반복 13일까지)T010000Z;WKST=MO

// 일간반복
DTSTART;VALUE=DATE:20080527
DTEND;VALUE=DATE:20080528
RRULE:FREQ=DAILY;UNTIL=20080620;WKST=MO  => 일간반복

DTSTAMP:20080712T015102Z   => 파일 추출 시간
UID:585k9gpf9duceh77kb0s186nh4@google.com   => 도메인 or 메일주소
CLASS:PUBLIC => 공유관련 (private)
CREATED:20080629T053500Z  => 생성 날짜
LAST-MODIFIED:20080705T013109Z  => 수정 날짜
SEQUENCE:1  => 항목별 한 개씩 올려줌(스케줄 구분)
STATUS:CONFIRMED
SUMMARY:달력 주/일/월 일정 관련 resize\, move 구현 => 제목
TRANSP:TRANSPARENT (기본 값 : OPAQUE)
LOCATION: 개발실
DESCRIPTION: 일정관리 개발 관련 내용중
END:VEVENT

그 외에도 STATUS는 Tentative(미정상태), 확정(Confirmed), 취소(Canceled)로 구분할 수 있으며, SEQUENCE는 일정 정보의 변경된 횟수를 나타냅니다. 처음 등록하면 0이며 하나씩 증가합니다. 이때 변경 정보는 일정의 시간정보만을 반영한다. 다른 변경 정보들은 영향을 미치지 아니합니다.

위의 정보들은 실제로 일정 관리 데이타를 추출할때 만들어지는 결과이며, 일정관리 시스템을 만들고자 하는 분들은 이러한 점들을 잘 고려하여 시스템을 설계하고 구현해야 합니다. 크게 의미가 없는 정보들은 특별히 중요하지는 않지만, A라는 시스템의 규칙 관한 정의를 B라는 시스템에서 수용하지 못할 경우 어떻게 처리하여야하는 대단히 중요한 문제로 인식 될 수 있습니다. 위에 예로든 추출 파일은 구글 캘린더에서 ics포맷으로 저장한것이며 위의 항목중 구글 캘린더에서 사용하지 기능인 STATUS 같은 경우는 일괄적으로 CONFIRMED 처리하고 있습니다. 즉 구글 캘린더 같은 경우도 다른 시스템에서의 STATUS 값들을 수용할 수는 없을 것입니다.

3. 검토

일정과 관련된 데이터들 이외에도 부가적으로 일정관리 시스템이 지원하는 공통적인 기능들이 있습니다. 예를 들어 기념일 관리, 일정 알림 서비스(메일, SMS), D-day 관리 등은 스케쥴의 본질적인 기능과는 별개로 더 편리한 일정관리를 위해서 만들어진 기능들입니다. 이러한 기능들에 관련된 정보는 시스템들과 상호 호환되지 않는 특징을 가지고 있습니다. - 매핑할 항목이 존재하지 않으므로 -  그리고 일정 관리 시스템을 구현할때 개방형 캘린더 표준에 포함된 항목을 구현하지 않을 경우에는 다른 시스템에서 전송된 일정에 대한 정보를 매핑하지 못함으로써 값을 누락되어 정보의 일부가 손실됩니다. 일정관리 기능 리모델링중 초기에 이러한 표준을 검토하지 않아서, 몇몇 기능들은 개발중에 포함되었으며, 결국 어떠한 기능들은 포함되지 못하는 문제도 발생하였습니다. 그러나 시스템 설계상 일정 관리 항목은 추가 확장 가능하며 기능을 추가하는데 크게 어려운점은 없습니다. 하지만 초기에 이러한 점을 누락했다는 점은 전체적인 개발 과정에서 혼란과 어려움을 가져다준것은 사실입니다. 다양한 일정 관리 시스템에서 일정 관리 데이타를 공유하는 문제는 기술적으로 크게 어렵거나 복잡한 문제는 아닙니다. 캘린더 표준이라는것의 존재유무를 모르면 당연히 참고하지 않고 시스템을 구성할 것입니다. 데이터 공유 측면에서도 표준이 있다는것은 실제로는 더 편리하고 유용하게 사용되는 경우가 많을 것입니다.