위키를 이용한 업무지원 시스템의 개발

Contents

정보를 만들고, 이것을 다듬어서 지식이 되도록 만들어주는 위키의 강력함은 이미 널리 알려져 있다. 여기에 위키 시스템 특유의 강력하고 손쉬운 링크(:12)관리 기능이 더해짐으로써, 하나의 거대한 지식네트워크가 만들어질 수 있는 기본방향을 제시한다는 점에서, 위키의 앞날은 매우 밝다고 할 것이다.

가장 성공적인 위키 서비스라고 평가되고 있는 wikipedia(:12)는 단지 몇년의 시간으로 수백년전통의 브리테니커 백과사전의 권위에 도전하고 있는게 현실이다. 많은 기업들이 자사의 지식을 관리하기 위한 목적으로 위키를 사용하고 있으며, 위키의 도입에 미온적인 태도를 보이던 국내기업들도 대기업을 중심으로 사용 영역을 넓혀가고 있다.

기업의 경우에는 특히 협업을 위한 도구로써, 위키의 도입을 고민하고 있는 것 같은데, 여기에서는 일반적인 협업을 도구로써의 위키가 아닌, 업무지원 시스템으로써의 위키의 활용에 대해서 얘기해보려고 한다. 협업을 위한 도구로써의 위키활용에 관한 것은 위키를 활용한 협업 노하우문서를 읽어보기 바란다.

일단 업무지원 시스템의 범위를 명확히 할필요가 있을것 같다. 여기에서의 업무지원은 CS라고 불리우는 고객지원 시스템을 의미하지 않는다. 이슈 tracking 기반의 IT 업무지원 시스템으로 범위를 제한할 것이다.

예컨 데 소프트웨어 개발, 시스템/네트워크/서비스 관리영역에서의 업무의 효율성을 높이도록 도와주는 위키시스템을 구축하고자 하는게 목표다. 특히 개인적인 주요 업무인 시스템/네트워크/서비스 관리업무의 지원시스템 구축에 촛점을 맞출 것이다.

IT업무에서 지원업무라고 하면, 인프라적인 성격이 강한 영역 즉, 시스템관리, DB관리, 네트워크 관리와 관련된 영역이다. 흔히 SE, DBA, QA, QOS 업무를 담당하는 부서들로 각각의 자원 즉 시스템, DB, 네트워크, 서비스 품질을 보장해서 IT업무가 원할히 돌아가도록 support(지원)하는 일을 한다. 특성상 이들은 개발부서, 보안운영팀, 서비스운용 부서들과 커뮤니케이션을 해야 한다. 당연히 원할한 커뮤니케이션을 위한 시스템의 구축이 필요할 것이다.

이것은 고객지원시스템과 비슷한점이 있다. 어찌보면, 대상이 고객에서 회사내부 부서가 된다는 것 외에는 완전히 동일한 것으로 보여질 수 있을 것이다. 그러나 고객지원 시스템보다는 좀더 복잡한 프로세스를 거친다. 일반적으로 고객 프로세스는 고객으로 부터의 요청 <---> 이에 대한 응답의 비교적 단순환 과정을 거친다고 볼 수 있다. 반면 업무지원 프로세스는 이보다는 복잡한 과정을 거친다. 이러한 프로세스는 다음과 같은 과정으로 정의내릴 수 있을 것이다. 프로세스는 Ticket을 발행하고 이를 추적하는 방식으로 기술했다. Ticket 방식을 이용한 이유는 구현이 간단하며, 특히 이슈를 추적하는 방식의 업무지원을 훌륭히 기술할 수 있기 때문이다. trac(:12), mentis 같은 이슈추적 시스템역시 Ticket 발행방식을 사용한다. 다음은 Ticket을 이용해서 이슈가 관리되는 방식을 보여주고 있다.

Ticket 발행시스템은 프로세스가 단순명로하다는 장점을 가진다. 이것은 일이 생길경우 해야될 일을 쪽지에 적은다음, 일을 처리해야 할 사람에게 쪽지를 전달하고, 쪽지를 전달받은 사람은 쪽지에 적힌데로 일을 수행하고 그결과를 다시 쪽지에 적어서 발행자에게 전달하는 방식이다.

전령(메신저)를 매개로한 의사소통과정으로 생각해볼 수 있다. 예전같으면 전령이 왔다 갔다하는데, 상당히 많은 시간이 소비되었겠지만, 지금은 빛의 속도로 의사소통이 가능하다. 적어도 의사를 주고받는데 걸리는 시간은 무시할 수 있을 것이다.

특별히 wiki 기반으로 티켓발행 시스템을 구축할 때, 얻을 수 있는 장점은 다음과 같다.

• Ticket 자체에 의사소통과정과 그 결과를 온전히 보존할 수 있다.
• 강력한 링크 기능을 제공한다.

위의 장점을 결합하면, 업무처리를 위한 지식기반 시스템으로 만들 수도 있다. 여기에 유연한 위키의 확장성을 이용해서 링크 기능을 확대한다면, 지식기반시스템을 구축할 수 있을 것이다. 링크의 확장을 위한 몇가지 아이디어가 있는데, 하나는 meta page를 이용하는 것이고, 하나는 tag(:12)를 이용하는 것이다.

meta page에 대한 내용은 Related Link문서를 참고하기 바란다.

좀더 간단하게 링크를 확장시키는 방법으로 tag를 이용할 수도 있을 것이다. tag의 경우 똑똑하게 tagging을 하지 못할경우, 말그대로 tag cloud가 되어버려서, 그다지 유용하지 못하게 될 수 있다는 점이다. 그러나 업무지원 시스템 처럼, 일반유저가 아닌 소수의 전문사용자가 사용하게 될경우, 정책이나 교육등을 통해서 똑똑하게 tagging할 수 있도록 유도할 수 있기 때문에, 매우 좋은 시스템으로 만들 수 있다. 내가 생각하는 tag 시스템은 다음과 같다.

• tagging를 하면, tag를 이루는 Term이 Tag Table에 저장된다.
• 그렇다면 Term을 클릭했을 때, 해당 Term과 연관된 문서들을 찾아낼 수 있을 것이다.
• 이들 정보는 위의 meta page와 연동이 가능할 것이다. 즉 meta page로 링크가 될경우, 해당 meta page가 존재한다면, meta page의 내용을 우선보여주고, 만약 해당 term이 tag 테이블에도 존재한다면, 두개를 하나의 meta page에 표현해주는 것으로, 구현상의 문제는 없다.
• tag를 이루는 Term기반으로 연관된 문서를 찾아내는 방법에 대한 것은 별도의 문서로 정리해볼 생각이다.

tagging이 똑똑하게 이루어질 수 있다고 가정한다면, tag로 그라프를 만들 수 있을 것이고, 원하는 문서를 더욱 쉽게 찾을 수 있도록 시스템을 구축할 수 있을 것이다. tagging를 충분히 신뢰할 수 없을 경우에는 link를 분석해서 함께 사용하는 방법이 있을 것이다. 이름과 성격이 다를뿐 근본은 link 기반이므로 - 가중치를 다르게 한다든지 하는 장치를 두는 정도로 - 이 둘을 함께 사용하는데, 문제는 없을 것이다.

대부분의 위키는 Plugin 형식으로 필요한 기능을 제공하는데, 이는 각 기능을 컴포넌트 형태로 만들고 블럭을 쌓듯이해서 시스템을 만들 있도록 도와준다. 예를 들어 Ticket 발행시스템을 구축하려고 한다면, 다음의 컴포넌트들을 만들면 될 것이다.

• TicketMake : Ticket 생성
• TicketList : Ticket 리스트 보여주기
• TicketView : 단일 Ticket 보여주기
• TicketComment : Comment
• TicketPropertiesChange : Ticket의 상태 변경

ㅇㅇㅇ 업무지원을 위해서는 다음과 같은 요소들이 필요할 것이다.

• Ticket 요청/처리를 위한 Ticket 발행모듈
• Ticket의 범주설정을 위한 Milestone 및 Project 관리모듈
• Ticket의 상태관리를 위한 Properties 관리 모듈
• Ticket Comment의 생성및 관리를 위한 모듈
• Ticket 통계를 내기위한 모듈

Ticket 발행모듈은 다음과 같은 구성요소를 가진다.

1. 요청팀/요청자
2. 처리팀/처리자
3. Priority
4. DueDate
5. 요청일
6. 요청완료일
7. Status

trac와 같은 이슈추적 시스템은 DueDate를 가지지 않는게 일반적이지만, 업무지원시스템에서는 반드시 지켜지지 않을 지라도 DueDate가 필요할 것이다.

Status는 이슈츄적 시스템의 Ticket의 상태와 비슷하며, Ticket이 Ticket 처리 프로세스 상의 어느위치에 있는지를 알려준다.

1. Open : Ticket이 발행되었음
2. Accept : 발행된 Ticket을 해당 부서에서 받아들였음
3. Assigned : Ticket는 우선 팀으로 발행될 것이다. 이것은 PM 혹은 PL에 의해서 Accept되고, 팀원들에게 다시 Assigned 될수 있을 것이다. 이 과정을 통해서, PM/PL은 자기 부서에 어떤일이 일어나고 있는지, 어떤 팀원에게 어떤일이 할당되었는지를 인지할 수 있게 된다. Mail로는 이러한 관리가 거의 불가능 할것이다.
4. Close : 업무가 종료되었다. 업무는 여러가지 상태로 종료될 수 있으므로 Close는 다시 다음과 같은 상태를 가질 수 있다. 종료 상태는 지원되는 업무의 성격에 따라 달라질 수 있을 것이다. 아래는 일반적인 예일 뿐이다.
   • fixed : 해결되었음
   • invalid : 잘못된 요청
   • duplicated : 중복된 요청
   • wontfix : 여러가지 이유로 해결될 수 없는 요청 - 후에 해결될 수 있으며, 이경우 ReOpen 될 것이다.

MileStone & Projcet

• MileStone은 장기적으로 달성되야할 목표를 말한다. 분기 이상의 단위로 설정되는게 일반적이다.
• Project는 MileStone을 달성하기 위해서 진행되는 단위 업무들을 말한다.
예를들어 QOS 팀의 올해 장기계획으로 QOS 인프라 시스템 구축을 세웠다면, QOS 인프라 시스템 구축은 MileStone가 될 것이다. 이제 이 MileStone을 달성하기 위한 Project로는 관제시스템구축, 이력관리 시스템 구축, 통계정보 시스템 구축등이 만들어질 수 있을 것이다.
이제 만들어진 Ticket을 위의 MileStone과 Project에 연결을 한다면, 업무의 대략적인 방향과 업무를 완수하기 위해서 어떤 일이 필요하고, 어떤일이 어떻게 수행되었는지등에 대한 정보를 얻을 수 있을 것이다.
이는 업무지원 시스템에도 그대로 응용될 수 있다. 특정 부서에서 업무요청이 들어온다면, 이 업무요청은 MileStone과 Project로 분류될 수 있을 것이고, 이 자료를 취합한다면 업무형태분석, 어떤 업무에 자원이 주로 들어가는지, 어떤 문제가 주로 발생하는지 등에 대한 정보를 얻을 수 있을 것이다.

좋은 구조를 가지는 위키 매크로 시스템

지금의 방식으로 한다면, 하나의 모듈은 하나의 컴포넌트에 대응하고 이 컴포넌트들이 모여서 하나의 기능 즉 하나의 위키페이지가 완성될 것이다. 예로 Ticket View 는 다음과 같은 모듈의 조합으로 이루어질 것이다.
1. Ticket Status : Ticket의 현재 정보를 보여줌
2. Ticket Comment : Comment를 남김
3. Ticket Upload : 첨부파일을 올림
4. Ticket Properties Change : 티켓 상태를 바꿈
이러한 구조는 아래의 경우에 있어서 좋은 설계구조라고 할 수 있다.
• 응집도
하나의 모듈은 하나의 논리나 하나의 기능을 구현해야 한다. 각각의 단위 메크로로 기능을 최소화 한다는 것은 단위 메크로 즉 모듈의 응집도를 높인다는 얘기가 된다.
• 결합도
모듈은 단위 컴포넌트로 작동할 수 있어야 한다. 모듈은 독립적이며, 다른 모듈에 의존하지 않도록 해야 한다. 굳이 의존한다면 글로벌한 영역 즉 시스템에만 의존하도록 해야 한다. 위키를 이용하면, 쉽게 이러한 환경을 만들 수 있다. 업무지원 시스템을 예로 들자면, 각 모듈은 Ticket의 key만 있다면, 다른 모듈이 있건 없건간에 상관없이 독립적으로 작동할 수 있어야 할 것이다. 그렇다면 wiki의 페이지의 이름을 Key로 할 수 있을 것이다. 즉 티켓이 발행되면, ticket id를 이름으로 하는 페이지가 만들어지고, 이 페이지에 적재된 모듈은 위키 페이지의 이름만을 가지고 작동할 수 있을 것이기 때문이다. 유저정보와 같은것들역시 위키 시스템에서 얻을 수 있기 때문에, 각각의 모듈은 완전히 독립적으로 작동할 수 있으며, 낮은 수준의 결합도를 유지할 수 있을 것이다. 낮은 수준의 결합도를 유지한다는 것은 자유로운 확장과 구성이 가능해짐을 의미한다.
• 적응성
설계를 얼마나 쉽게 변경할 수 있는지와 관련된 문제다. 모듈간의 결합도가 낮을 수록 높은 적응성이 보장될 것이다. 그외에, 문서화의 정도와 응집도등도 적응성을 높이는 방법이 된다. 문서화를 잘 해두면, 어떤 모듈이 어떤 모듈에서 분기되었는지 어떤 모듈과 어떤 모듈이 서로 관계가 있는지 등을 쉽게 추적할 수 있게 된다.
위키시스템을 이용하면, 골머리 썩힐 필요없이, 위의 3가지의 구조적 장점을 가진 시스템을 구축할 수 있다.
위키기반의 trac 이 개발된것도 이러한 이유에서일 것이다.

다른 기간정보와의 결합

이는 위키시스템의 뛰어난 적응성때문에 가능하다. 이렇게 해서 만들어진 업무지원 시스템은 기존의 다른 시스템과의 결합이 손쉽게 이루어질 수 있다.
인터넷 서비스를 하고 있다면, 인터넷 서비스의 품질을 높이기 위한 시스템도 마련되어 있을 것이다. 여기에는 SMS(:12), NMS(:12) 과 같은 낮은영역에서의 자원관리 시스템이 있을 것이다. 자원관리 시스템은 자원을 수집하고 분석하며, 임계치를 초과했을 경우 이벤트를 발생시키는 일을 할 것이다. 또한 이벤트는 Ticket 형식으로 업무처리시스템에 전달되어서 처리되고 이력으로 남아야 할 것이다.
뿐만 아니라, 인터넷 서비스에 대한 성능측정 시스템도 갖추어져 있어야 한다. 이 성능측정 시스템은 다시 SMS, NMS 및 업무지원 시스템과 연동되어 있어야 할 것이다. 이렇게 각각의 시스템이 유기적으로 모여야지 인터넷 서비스 품질을 보장하기 위한 활동 - 이하 QA -도 원할히 이루어질 수 있기 때문이다.
이들 시스템의 중심에 wiki를 두어서 가교역할을 하도록 하자.

가장 밑바닥에는 시스템과 네트워크가 있을 거고, SMS와 NMS 등의 소프트웨어가 Raw Data를 수집할 것이다. 수집한 정보는 wiki 시스템에서 분석해서 레포트, 통계자료를 만들고 Dash Board를 통해서 관리자에게 서비스하면 된다.
서비스, 네트워크, 시스템 정보들은 서비스에 따라 커스터마이징이 필요한 부분이다. wiki를 이용하면, 환경에 최적화된 시스템의 구축이 가능하다.
zenoss와 wiki를 이용한 시스템 및 이력관리 시스템 문서를 참고해보기 바란다.