오픈비 : 삽질은없다

작년도 미국 최고의 인기서비스로 등극하면서, 그 여세를 올해까지 몰아가고 있는 트위터가 김연아 양의 가세와 함께 국내에서도 무서운 속도로 그 영역을 확장해가고 있습니다.  그러다보니, 기존의 블로그와는 또다른 특성을 가지고 있는 트위터와 같은 마이크로블로그 특성에 맞는 비즈니스 방법에 대해서는 다양한 담론이 이어지고 있습니다.

트 위터의 마케팅 전문가인 @indymike 의 연구에 따르면, 트위터 사용자들이 트위터 링크에 응답하는 확률은 약 4% 정도로, 일반적인 블로그 광고의 1% 내외, 페이스북의 0.1% 내외와 비교할 때 훨씬 효과적이라는 것이 밝혀졌습니다.  이는 실제로 다양한 비즈니스 성공의 예로도 실증이 되고 있습니다.

오늘은 트위터의 마케팅 도구로서의 가능성과 관련한 이야기를 조금은 더 심도있게 다루어볼까 합니다.  이전의 포스팅 중에서도 이와 관련된 글들이 있으니 같이 읽으시면 더욱 도움이 되시리라 믿습니다.


연관글:
2009/07/16 - 소셜 미디어를 이용한 소셜 CRM이 뜬다.
2009/07/06 - 트위터를 이용한 브랜드 파워 높이는 전략
2009/06/15 - 블로그 이은 마이크로블로그 대히트와 비즈니스


트위터는 마케팅에 유리하게 디자인된 서비스이다.

트위터는 작은 세상과도 같아서, 다양한 의견과 이벤트에 대한 이야기, 뉴스 및 아이디어, 그리고 다양한 사적인 대화에 이르는 우리 인생의 "조각난 경험"들로 넘쳐 납니다.  누구나 쉽게 수천 명의 사용자들의 이야기를 들을 수 있고, 다수의 사용자들의 대화에 언제든지 끼어들 수 있으며, 이것이 누구에게나 용인되는 즐거운 세상입니다.

이를 바꿔서 말하면, 다른 인터넷 서비스와는 달리 마케팅을 하려고 하는 회사들이 적당한 매너와 네트워킹 기술이 있다면 수동적인 마케팅이 아니라, 매우 적극적인 마케팅이 가능하다는 것을 의미합니다.  능동적으로 트위팅 메시지를 푸쉬할 수 있기 때문에 셀프 프로모션과 마케팅에 매우 유리합니다.


트위터를 통한 마케팅의 기술과 문제점

트위터를 이용한 다양한 마케팅 기술에 대해서는 여러 글에서 언급이 되지만, 이를 한 마디로 줄여보면 "관심을 추적하고 돌리는 것"이라고 하겠습니다.  트위터 세상에서 중요한 영향을 미치는 사람들이 마케팅 대상이 되는 제품이나 서비스, 브랜드에 대해서 어떻게 생각하는지 모니터를 하고, 이들을 적극적인 네트워킹 활동을 통해 원하는 방향으로 관심을 가지게 유도하는 것이 목표가 되겠습니다.

비즈니스 차원에서 바라보면, 트위터는 현재와 앞으로의 고객들과 직접 연결할 수 있는 채널입니다.  정말 관심이 있는 참여자를 골라서 이들의 참여를 유도할수도 있고, 이들에게 브랜드의 영속성과 충성도를 높이게 할 수 있습니다.  또한, 트래픽을 일으키는 도구로 이용하는 것도 가능합니다.  프로파일이나 대화 도중에 방문을 유도할 수 있는 링크를 이용하는 것도 많이 쓰이는 방법입니다.

그렇다면, 트위터 마케팅의 문제점은 뭘까요?   트위터는 어려운 도구가 아니다보니, 진입장벽이 낮습니다.  그래서 수많은 트위팅이 존재하고, 관심을 끌기가 쉽지 않습니다.  그러므로, 나름 관심을 끌기 위한 노력이 필요합니다.  물론, 반짝 마케팅을 이용할 수도 있겠지만 근본적인 처방은 시간과 정열을 많이 쏟아야 한다는 점입니다.


언제나 통하는 경품 전략 !  #Moonfruit 의 성공 비결

최근 갑자기 트위터에서 #Moonfruit 라는 단어가 최고의 인기어로 계속 트위터 메인 페이지 및 사이드 바에 표시가 된 적이 있었습니다.  이렇게 메인 토픽으로 표시된 단어는 누구에게나 관심을 유발할 수 밖에 없습니다.  사실 Moonfruit는 웹 사이트를 구축해주는 서비스를 하는 곳입니다.  이들이 택한 전략은 2가지 였는데, 한 가지는 Moonfruit를 follow하면 일정기간 동안 follow한 사람들 중에서 추첨을 통해 맥북을 한 대 선사하는 것이었고, 그 다음으로는 #Moonfruit 라는 단어를 넣어서 트위팅을 하면 그 중에서 추첨을 통해 마이클잭슨 기념공연 티켓을 주는 것 등입니다.

그 덕분에 엄청난 수의 트위터리안들이 #Moonfruit에 대해 트위팅을 하기 시작하고, 친구의 친구를 거쳐 수백 만, 수천만에 이르는 사람들이 이를 알게 되었습니다.  경품의 대가에 비해 월등히 경제적인 마케팅/브랜딩 방법이지 않았을까요?

단기간에 엄청난 수의 사람들에게 노출되기에는 가장 적합한 전략이라고 하겠습니다.  단점은 아무래도 1회성으로 그칠 가능성이 있고, 컨테스트나 이벤트가 끝나고 나면 많은 사람들이 unfollow를 할 것이라는 점입니다.  며칠 간의 결과를 보면 이미 Moonfruit 는 최고의 트렌딩 토픽으로 올라왔고, 하루 1만명 이상의 follower가 생기는 대성공을 거두었습니다.

현재 약간 상승의 탄력이 둔화되기는 하였지만, 대단한 성과라고 할 수 있습니다.  이런 이벤트는 사실 가장 쉽게 생각할 수 있기도 하고, 전통적인 마케팅 기법이 먹힌 사례라고 하겠습니다. 


할인 쿠폰과 특별 판매 홍보전략 (Dell의 사례)

최초로 트위터 마케팅 성공사례로 꼽히는 Dell 의 전략이 할인 쿠폰 및 특별판매 전략이었습니다.  일단 충실한 followers 수를 확보한 뒤에, Dell은 리펍(refurbished) 제품에 대해 @dellOutlet 계정을 통해서 할인 쿠폰을 발행했습니다.  마치 할인 쿠폰을 받기 위해 이메일로 사이트에 가입하는 것과 비슷하다고 하겠습니다.

이미 상당 수의 follower들을 확보한 뒤였고, 동시에 할인 제품에 관심이 있는 많은 사람들에게 리트위팅이 되면서 새로운 follower들이 유입되었습니다.  사실 현재까지 가장 효과가 좋은 것이 바로 이 모델입니다.  소비자에게도 유용한 정보가 전달되었고, 계정의 신뢰도도 크게 떨어지지 않습니다. 

Dell의 리퍼제품(refurbished product, 주로 반품된 제품을 수리해서 다시 내놓는 상품)의 마케터였던 리카르도 게레로(Ricardo Guerrero)는 2007년부터 트위터를 이용했습니다.  그는 초반에 절대로 제품에 대한 직접적인 메시지를 주지 않고, 주로 점심이나 날씨, 그리고 많은 사람들이 관심을 가지는 주제에 대한 가벼운 채팅을 중심으로 그 네트워크를 키워나갔습니다.

게레로는 트위터가 언젠가 중요한 비즈니스의 원동력이 될 수 있음을 직감했지만, 서두르지 않았습니다. 그러면서, 몇명의 친구들과 함께 Odeo라는 회사의 공짜 팟캐스트 기술을 활용하기 시작했습니다.  나름 인지도도 쌓았고, 활동도 활발하게 하면서 2007년 6월 @DellOutlet 이라는 트위터 기반의 판매 계정을 만들게 됩니다.  이것이 트위터 최초의 비즈니스 계정으로 알려져 있으며, 주로 follower들에게 특별할인 기회를 주는 형태로 이용하기 시작합니다.

트위터는 게레로가 고객들에게 빠르면서도 동시에 이메일보다 훨씬 효과적인 방법으로 접근할 수 있는 기회를 주었습니다.  특히나 그가 주로 취급하는 리펍(refurbished) 제품들은 온라인 웹사이트에서조차 냉대받고 매우 적은 사람들이 찾아오는 섹션이었습니다.  그렇지만, 트위터를 통해 전달하는 최저가 정보나 특별할인에 대한 정보들은 많은 follower들에게 유익했고, 이들은 그동안 게레로가 쌓아놓은 신뢰를 믿었으며 상호의 신뢰를 바탕으로 가장 유용한 정보를 제공한다는 형태의 트위터 광고전략은 매우 큰 성공을 거두게 됩니다.

게레로가 트위터 마케팅을 시작한지 1년이 될 때까지, 트위터를 통한 판매는 $50만 달러를 돌파하게 됩니다.  물론, Dell이라는 회사의 규모를 생각할 때 이는 아무것도 아닌 것일 수도 있습니다.  그렇지만, 새로운 마케팅/세일즈 채널을 열었다는 측면에서 이는 커다란 성공을 예고한 것이나 마찬가지 였습니다.  2008년 이후 Dell은 게레로의 성공을 바탕으로 20개가 넘는 트위터 계정을 새로 만들었습니다.  그렇지만, 그 중에서 실제 세일즈를 위한 계정은 2개 입니다.  나머지 계정은 모두 Dell이 고객들과 대화를 하기 위한 창구로 이용했습니다.  그들은 무엇이 트위터 사용자들의 마음을 움직였는지 이해하고 있는 것입니다.

강력한 유대감을 가진 네트워크를 이용한 고객응대전략

트위터는 블로그에 비해 소셜 네트워크 성격이 훨씬 강합니다.  트위터 사용자들은 미디어적인 성격보다는 사용자들의 관계를 훨씬 중시합니다.  이 부분이 기존의 마케팅이나 세일즈 방식이 먹혀들지 않는 가장 큰 이유입니다. 그러므로, 트위터를 이용한 비즈니스는 고객들과의 밀접하고 친밀한 관계를 유지하는데 목표를 두어야 합니다.

 

미국의 대표적인 케이블 방송 네트워크 회사인 컴캐스트(Comcast)는 고객서비스에 대한 만족도가 역사적으로 최하위권에 속하는 곳입니다.  컴캐스트의 고객서비스 운영자 중의 하나였던 프랭크 엘리어슨(Frank Eliason)은 자신의 열정을 회사의 고객서비스 만족도를 높이는데 쏟기로 결심합니다.  그는 @ComcastCares 라는 계정을 만들고, 2008년 5월부터 현재까지 3만 건이 넘는 트위팅 메시지를 쏟아내었는데 놀랍게도 대부분의 트위팅이 어떻게 하면 고객들의 문제를 풀어낼 수 있는지에 대한 것이었습니다.

그의 접근 방법에 대해서는 상당한 논란이 있었습니다.  작년 말까지만 하더라도 그를 follow하는 사람의 수는 3,000명 정도에 불과했고, 많은 사람들이 그의 트위팅을 단순히 PR로 받아들이기도 하였습니다.  그렇지만, 현재는 2만 명이 넘는 사람들이 그의 계정을 follow하고 있으며 그의 열정이 받아들여지고 있습니다.  그가 알려주는 정보에 실제로 도움을 받은 사람들도 늘어나고, 실제로도 그의 이름을 알고 그를 마치 자신의 이웃처럼 느끼는 사람들이 생기면서 회사 자체에 대한 인식도 서서히 변하고 있습니다.


그 밖의 트위터 활용사례

이 밖에도 이제는 트위터를 이용한 다양한 기업들의 사례들이 쌓이고 있습니다.  아마도 앞으로 마케팅 및 PR 관계자들의 최대의 주목대상이 트위터가 되는 것도 어쩌면 당연한지도 모르겠습니다.  국내에서는 어느 정도의 효과를 거둘지는 아직 미지수이지만요 ...

• 델타 항공사, 사우스웨스트 항공 그리고 제트블루 항공: 특별한 할인판매나 여행자들과의 직접적인 소통을 시도함
• 아마존:  매일 새로운 제품에 대한 특별판매를 실시함
• 홈 데포(Home Depot):  소비자들이 제품을 사서 사용하거나, 조립하는 등의 활동에 불편이 없도록 도와주는 역할
• Wine Enthusiast : “Twitter only” 할인판매를 실시함.  와인과 관련한 다양한 기사들이나 안건에 대한 투표 실시
• H&R Block: 소비자들과 직접적인 관계를 맺고, 심지어는 세금에 대한 조언까지 해줌

트위터의 사회적 파급효과와 실질적인 산업 및 비즈니스와의 연계에 대해서는 아직 더 많은 경험과 연구, 그리고 보다 창의적인 확장 서비스들을 통해 변화될 여지가 많을 것 같습니다.  특히, 웹에서 모바일 기반으로 이동하면서 나타날 수 있는 다양한 부가적인 혁신에 의해 미래의 인터넷 환경은 급변할지도 모르겠습니다.  이것이 2009년 우리가 맞게될 가장 커다란 인터넷과 미래환경의 변화가 아닐지요?

참고자료:

 

Despite Debate, Brands Find Value on Twitter by Kate Kaye

17 Ways You Can Use Twitter: A Guide for Beginners, Marketers and Business Owners

Twitter Is/Is Not a Serious Marketing Tool by Sean Silverthorne

How Photographers Can Use Twitter as a Marketing Tool by scottbourne

Twitter as a Marketing Tool by  Karlyn Morissett 

 

출처 : http://health20.kr/tag/Twitter

trac을 설치하고, customization했으니 이제 trac에서 사용되는 용어의 개념과 흐름(workflow)을 살펴 보도록 하자.

Ticket System

trac 은 ticket이라는 것을 사용하여 project를 관리하고, bug를 관리한다. ticket은 간단히 말하면 업무 내용을 전달하기 위한 수단이다. 즉, "이런 저런 문제가 있으니 해결하라" 라든가 "이런 저런 기능이 필요합니다"라는 등의 내용이 들어간다. ticket은 이러한 업무를 보다 구체적이고 효율적으로 지시(혹은 전달)하기 위해 많은 정보를 가지고 발행된다.
이 ticket이 가지는 정보는 다음과 같은 것들이 있으며, 이는 trac project의 관리자가 Admin tab의 Ticket System 부분에서 관리할 수 있다.

Components

Components(구성요소, 성분)는 원래 단어의 뜻대로 project의 구성요소나 성분을 뜻한다. component는 해당 project의 규모에 따라 함수나 module 수준이 될 수 있다.

예 를 들어 사용자로부터 두 정수(integer)를 입력 받아 평균을 구하는 작은 project가 있다고 치면 component는 main 함수, sum 함수, average 함수, input 함수, output 함수 등의 수준에서 구성될 수 있다.
조금 더 복잡한 예로, 간단한 게임을 만든다고 하면(tetris나 그림 조각을 맞추는 등의) component는 input, output, user interface, sound engin, game logic, graphic engine 등의 부분으로 구성될 수 있다.

Components에는 component 이름(name)과 소유자(owner), 설명(description), 기본 값(default)을 설정할 수 있다. 기본 값이 check된 component는 ticket을 만들 때 component 항목의 기본 값으로 설정된다.

ticket을 만들때 component를 지정하면 component 소유자의 email로 전달된다.

Milestones

milestone은 사전적인 의미로 길을 따라 일정한 간격으로 세워져있는 이정표를 말한다 (참조 : http://www.letsmakegame.net/?mid=data_dic&page=2&document_srl=5721 ). 최종 목표 이전의 중간 목표 정도라고 볼 수 있겠다.

예 를 들어 게임을 만든다고 하면, 기본적인 playable한 게임 수준의 첫번째 milestone, 거기에 intro, menu, background music, effect 등이 추가되는 두번째 milestone, 이후 bug 수정, valancing 등이 적용된 세번째 milestone을 정의 할 수 있다.

예는 이렇게 들었지만, 꼭 시간이나 기능순으로 나열할 필요는 없으며, 꽤 커다란 project로 다른 여러 subproject들이 함께 맞물려 개발될 때에는 각 subproject의 이름과 version이 하나의 milestone을 구성할 수 있다.

ticket에 milestone이 지정되어 발행되면 trac의 Roadmap tab에서 해당 milestone에 발행된 ticket의 수와 해결된 ticket의 수를 graph로 보여주어 해당 milestone의 진행률을 쉽게 알아 볼 수 있다.

Milesotnes에는 milestone 이름(name)과 목표 날짜(due), 완료 날짜(completed), 기본 값(default)을 설정할 수 있다. 목표 날짜를 설정하면 현재 날짜로부터 얼마나 남았는지 혹은 얼마나 초과되었는지 알 수 있다. 완료 날짜는 milestone을 완료했을 때 check하면 된다. 기본 값을 check한 milestone은 ticket을 만들 때 milestone 항목의 기본 값으로 설정된다.

Priorities

ticket의 우선 순위를 뜻한다. 기본 값은 blocker, critical, major, minor, trivial 순이다. 이것들은 우선 순위를 바꾸거나 다른 이름을 줄 수 있다.

이 우선 순위와 나중에 나올 Severities(중요도)와 헷갈릴 수 있는데, priorities는 시간상으로 먼저 해결해야 할 문제라고 이해하면 될 듯 하다. 물론 Severities가 높다면 priorities도 높은 경우가 많으므로 따로 Severities를 정의하지 않고 priorities만 가지고 project를 관리할 수 있으며, 실제로 trac은 Severities의 기본 값들을 채워주지 않고 있다.

• blocker : 개발이나 test를 더 이상 진행할 수 없게 만드는 문제점.
• critical : program이 crash되거나 data 손상, memory leak이 발생하는 문제점.
• major : 기능상의 중요한 결점, 일반적인 문제로 반드시 고쳐야 할 버그.
• minor : 기능상 그리 중요하지 않은 결점, 쉽게 해결 가능한 문제.
• trivial : 오탈자, text 정렬 문제 등의 외형적 문제.

priorities에는 priority 이름(name)과 기본값(default), 순위(order)를 설정할 수 있다. 기본 값을 check한 priority는 ticket을 만들 때 priority 항목의 기본 값으로 설정된다.

Resolutions

ticket 이 만들어 진 후 실무자가 ticket에 쓰여진 업무를 내용을 확인하여 처리하면 실무자는 ticket을 닫게 된다. ticket을 닫을 때 이 문제를 어떻게 해결했는지 - 혹은 그냥 놔 두었는지 - 표시하는 것이 이 resolution이다. resolution은 fixed, invalid, wontfix, duplicate, worksforme의 기본 값들이 정해져 있다. 이것들은 물론 이름이나 순위를 바꿀 수 있다.

• fixed : 해결됨.
• invalid : ticket의 문제는 bug가 아님.
• wontfix : 해결될 수 없는 문제임.
• duplicate : 기존의 ticket과 중복된 문제임.
• worksforme : 파악할 수 없음. 동일한 현상을 재현하려 했으나 재현이 안 되고, code를 봐도 해당 문제의 원인을 파악 할 수 없는 상태.

resolution 에는 resolution 이름(name)과 기본값(default), 순위(order)를 설정할 수 있다. 기본 값을 check한 resolution은 ticket을 만들 때 resolution 항목의 기본 값으로 설정된다.

trac customization post에서 svn commit hook을 설정해 두었다면, svn으로 commit 할 때 남기는 log를 통하여 fixed 상태로 ticket을 닫을 수 있다.

Severities

심 각도, 중요도 등을 뜻한다. trac에서는 severity의 기본 값을 표시하고 있지 않다. priority가 시간적으로 처리해야할 순위를 뜻한다면, severity는 일의 심각성, 중요도를 나타낸다. 일상 생활의 예를 들면, 전기세를 안 내면 전기가 끊길지도 모르지만 납부 기한이 많이 남아있는 경우 priority는 다소 떨어지더라도 severity는 높다고 할 수 있다.

trac에서는 priority만 기본 값이 들어가있고 severity는 무시되어 있는데, bugzilla를 살펴보면 priority와 severity가 분리되어 있다. bugzilla의 priority는 단순히 p1~p5의 다섯 단계로 각각 즉시, 긴급, 보통, 낮음, 없음으로 구성되어 있으며 severity는 blocker, critical, major, normal, minor, trivial, enhancement로 trac의 priority와 비슷하지만 좀 더 세분되어 있다. bugzilla의 enhancement는 trac의 ticket type에 enhancement와 같다.

ticket type의 존재로 bugzilla보다 trac쪽이 더 세세한 분류가 가능하지만 기본 값은 ticket type과 priority만 있고, priority는 bugzilla의 severity에 가깝다. Priorities 부분에서 언급했듯이, priority와 severity는 비례하는 경우가 많으므로 편의를 위해 기본 값을 이렇게 둔 모양이다.

severities 역시 severity 이름(name)과 기본값(default), 순위(order)를 설정할 수 있다. 기본 값을 check한 severity는 ticket을 만들 때 severities 항목의 기본 값으로 설정된다.

Ticket types

ticket의 형태를 뜻한다. 업무의 종류라고 볼 수도 있겠다. trac이 기본 제공하는 ticket type은 defect, enhancement, task가 있다.

• defect : 문제점. 현재 있는 기능이 가지고 있는 bug나 문제점을 뜻 함.
• enhancement : 개선사항. 현재 기능이 제대로 작동하고 있으나 기능을 확장하거나 개선시켜야 할 것들.
• task : 새로 추가할 기능이나 해야 할 일.

ticket type도 ticket type 이름(name)과 기본값(default), 순위(order)를 설정할 수 있다. 기본 값을 check한 ticket type은 ticket을 만들 때 ticket type 항목의 기본 값으로 설정된다.

Versions

project 의 version을 뜻한다. milestone이 비공개된 미래지향적(앞으로 release할 code, 현재 완성을 위해 개발 중인 code)인 제품이라면, version은 release되어 공개된 과거 지향적(이미 상품화된, 배포된)인 제품이라고 할 수 있겠다.
따라서, ticket을 만들 때 현재 개발 중인 milestone이 대상이라면 version 부분은 비워 놓아야 하며, 이미 개발 되어 release된 제품이 대상이라면 versions 부분을 채워야 할 것이다.

versions 도 version 이름(name)을 가지며, 날짜(Released)와 기본값(default)을 설정할 수 있다. 기본 값을 check한 version은 ticket을 만들 때 version 항목의 기본 값으로 설정된다.

Workflow

trac에서 ticket을 만들고, 실무자에게 할당하고, 해결하고, ticket을 닫을 때까지의 흐름(workflow)을 정리해 보자.

trac에서 기본으로 제공하는 workflow는 다음과 같다. 이 workflow가 마음에 들지 않는다면 새 workflow를 작성하여 적용할 수도 있다.

new

새 로운 ticket을 생성한다. TICKET_ADMIN이나 TICKET_CREATE 권한을 가진 사용자는 새 ticket을 만들 수 있다. 새 ticket은 trac의 main menu중 "New Ticket" tab을 선택하여 생성할 수 있다.
다음 정보들을 입력하여 새 ticket을 생성한다.

• Summary : ticket에 관한 요약된 정보.
• Reporter : ticket을 발행한 사람의 id.
• Description : ticket에 대한 자세한 설명. 설명은 trac wiki 문법을 사용하여 꾸밀 수 있다.
• Type : ticket 종류. Ticket Type 부분 참조.
• Milestone : 이정표. Milestones 부분 참조.
• Version : 판 번호. Versions 부분 참조.
• Cc : 참조(carbon copy). ticket을 mail로 보낼 때 참조할 사람.
• Priority : 우선 순위. Priority 부분 참조.
• Component : 구성. Components 부분 참조. 해당 component의 owner가 지정되어 있을 경우 owner에게도 ticket mail이 날아간다.
• Keywords : ticket의 내용에 대한 주요 단어.
• Assign to : ticket을 실무자에게 할당하기 위해 적어주는 id.
• I have files to attach to this ticket : ticket에 첨부할 file이 있을 경우 check.

ticket이 생성되면, component owner, Cc, Assign to, 관리자(trac.ini에서 mail을 함께 받도록 설정된)에게 ticket mail이 발송된다.
Assign to에 실무자 id가 할당되어 있으면 ticket은 발행되면서 assigned 상태로 옮겨진다.

new ticket을 받은 사람이 TICKET_MODIFY 권한을 가지고 있다면 해당 ticket을 실무자에게 할당(reassign) 할 수 있다.
new ticket을 받은 사람이 실무자이고 자신의 업무 분야가 맞다면 수락(accept) 할 수 있다.
new ticket을 받은 사람이 실무자이고 자신의 업무 분야가 맞다면 수락(accept) 과정을 생략하고 ticket의 내용을 따른 후(resolve) ticket을 닫을(close) 수 있다.
new ticket을 받은 사람은 ticket의 상태를 바꾸지 않고 그대로 두면서 자신의 의견을 남길 수 있다(leave).

assigned

assigned는 할당된 상태를 뜻한다. 할당되어진 ticket을 받은 사람은 다음의 action을 취할 수 있다.

assigned ticket을 받은 사람이 TICKET_MODIFY 권한을 가지고 있으며 할당된 업무가 다른 사람의 업무라면 다른 실무자에게 ticket을 할당(reassign) 할 수 있다.
assigned ticket을 받은 사람이 자신의 업무 분야가 맞다면 수락(accept) 할 수 있다.
assigned ticket을 받은 사람이 자신의 업무 분야가 맞다면 수락(accept) 과정을 생략하고 ticket의 내용을 따른 후(resolve) ticket을 닫을(close) 수 있다.
assigned ticket을 받은 사람은 ticket의 상태를 바꾸지 않고 자신의 의견을 남길 수 있다(leave).

accepted

accepted는 수락된 상태를 뜻한다.

accepted ticket을 받은 사람은 다시 수락할 수 있다(accept).
accepted ticket을 받은 사람이 자신의 업무 분야가 아니거나 자신의 범위에서 해결할 수 있는 문제가 아니라면 다른 사람에게 ticket을 할당(reassign) 할 수 있다.
accepted ticket을 받은 사람은 ticket의 내용을 따른 후(resolve) ticket을 닫을(close) 수 있다.
accepted ticket을 받은 사람은 ticket의 상태를 바꾸지 않고 자신의 의견을 남길 수 있다(leave).

closed

해 결(resolve)되어 닫힌(close) 상태를 뜻한다. 실무자의  해결 방법에 따라 fixed, invalid, wontfix, duplicate, worksforme로 표시될 수 있다. 각 해결 방법은 Resolution 부분을 참조한다.

closed ticket을 받은 사람은 해당 ticket의 문제가 해결되지 않았다고 판단 될 경우 닫힌(close) ticket을 다시 열 수(reopen) 있다.
closed ticket을 받은 사람은 ticket의 상태를 바꾸지 않고 자신의 의견을 남길 수 있다(leave).

reopened

문제가 해결되어 닫힌(close) ticket에 동일한 문제가 있어 다시 열린(reopen) 상태이다.

reopen된 ticket을 받은 사람은 다른 사람에게 ticket을 다시 할당(reassign) 할 수 있다.
reopen된 ticket을 받은 사람이 자신의 업무 분야가 맞다면 수락(accept) 할 수 있다.
reopen된 ticket을 받은 사람은 ticket의 내용을 따른 후(resolve) ticket을 닫을(close) 수 있다.
reopen된 ticket을 받은 사람은 ticket의 상태를 바꾸지 않고 자신의 의견을 남길 수 있다(leave).

Time Line, Roadmap and View Tickets

위의 개념과 흐름을 참조하여 trac을 사용하다 보면 Time Line, Roadmap, View Tickets tab에 여러 가지 것들이 보이게 된다.

Time Line tab은 시간 순으로 ticket의 발행, repository의 변화(changeset), ticket의 상태 변화 등을 알 수 있다.

Roadmap tab은 milestone 기준으로 발행된 ticket, 진행된 ticket(closed), 마감 기한(혹은 초과한 기한)등을 확인 할 수 있다.

View Tickets tab은 여러 종류의 option을 통해 ticket을 정렬시켜 확인 할 수 있다. report라고도 하는데, report용 query 직접 만들어서 자신의 입맛에 맞게 ticket들을 살펴 볼 수 있다.

마치며

trac 의 기본 개념과 workflow 부분은 내가 충분히 이해할만큼 잘 정리되어 있는 한글 문서를 찾아내지 못 해서 따로 정리한 것이다. trac의 사용이 미숙하기 때문에 정확한 사용법까지는 posting하지 못 하지만, 여기에 정리된 개념을 사용하여 study하면 보다 세부적인 기능까지 다룰 수 있으리라 생각된다.

trac의 실제 사용법에 대해 깔끔하게 정리되어 있는 page가 있어 link를 걸어 둔다.

1. OCP (Open closed principle)

 버틀란트 메이어박사가 1998년 객체지향 소프트웨어 설계라는 책에서 Open/Closed Principle 언급함.
 http://en.wikipedia.org/wiki/Open/closed_principle#Meyer.27s_Open.2FClosed_Principle

 " 소프트웨어 구성 요소(컴포넌트, 클래스, 모듈, 함수등 )는 확장에 대해서는 개방되어야  하지만
 변경에 대해서는 폐쇄되어야 한다고 언급했습니다."
 먼저 이원리를 설명하기전에, 부절적한 예를 들어 보겠습니다.

예 : 휴대전화와 충전기의 관계
http://www.zdnet.co.kr/ArticleView.asp?artice_id=00000039134727
최상훈(핸디소프트) - 마소에 기재된 글

인용문 =>
휴대전화마다, 충전기가 달라서, 휴대전화변경시 충전기도 같이 변경해야 하는 불편함을
충전기 자체를 24핀 표준화하므로써,
이제 휴대전화만 사고 충전기는 재사용할 수 있게 됐다.
따라서 휴대전화의 여러 종류에는 ‘개방하지만’
충전기의 쓸데없는 생산은 ‘닫아두는’ 효과를 얻은 것이다.
바로 이번 호에서 소개할 개방-폐쇄의 원칙을 잘 반영한 결과라고 생각한다.

=>위의 예는 ocp 원칙을 설명하기에는 2% 부족하거나, 잘못된 예라고 볼수 있습니다.
왜냐하면, 이예제는 변경되는 부분은 표준화(규격통일)해라.
그러면, 재사용성이 높아진다 라는 것이지만,
그러면, 클래스등 s/w요소를 개발할때, 표준화하면서 개발해라. 라는 결론을
도출할 위험성이 있기때문입니다.

위의 예를 근거로 클래스를 설계하면서, OCP 원리를 지켜라 라고 하면 생뚱맞아 집니다.
왜나하면, 클래스를 표준화하면서, 개발해라. 아니면, 개방 폐쇄원리를 적용하면서, 개발해라 것은
너무 추상적이기 때문입니다.

그럼 메이어박사가 이야기한  OCP에서 강조하고 있는 것은 무엇일까요?
풀이하면,  요구사항의 변경이나 추가사항이 발생하더라도, 기존 구성요소는 수정이 일어나지 말아야 하며,
기존 구성요소를 쉽게 확장해서 재사용할수 있어야 한다는 뜻입니다.
그러기 위해서는 구성요소의 단위속성중 외부로 노출할것과 노출하지 말것을 구분하여야 한다는 겁니다.
즉,  변하지 않을 필수적인 단위속성과 변할 가능성이 있는 비 필수적인 단위속성을 구분해서,
필수적인 요구사항만, 구성요소(클래스)안에 구현하고, 나머지는, 구현자체를 생략하라는 겁니다.

예를 들어 전자제품을 설계해보도록 하겠습니다.
전자제품의 속성을 먼저 나열해보면
 1. 전기를 필요로한다.
 2. 끄고, 켤수있다.
 3. 작동하고, 멈춘다.
 4. 소리가 난다.
 5. 통신을 한다.
 6. 방송을 본다.
 7. 빨래를 한다.
 8. 시원하게 한다.
 9. 게임을 한다.
10. 복사를 한다.
....

전자제품의 속성은 위의 경우말고라도 무수히 많이 존재합니다.
여기에서  1번부터 3번까지는 전자제품의 고유한 기능이고,
4번이하는 개별전자제품의 기능이라고 분리할수 있습니다.

<?php
class electronic  {
  private $bolt  = '' ;
  public function setBolt($input) { $this->bolt = $input ; }
  public function getBolt()        { return $this->bolt ;    }
  public function powerOn()      {}
  public funciton powerOff()      {}
  public function play()            {}
  public funciton stop()            {}
}
?>
1번부터 3번까지의 고유한 속성만을 모아서 전자제품 클래스를 만들었습니다.

이제 tv라는 전자제품을 만들어라는 추가 요구사항이 발생하였습니다.
tv는 리모컨으로 파워를 온,오프라는 기능이 있습니다.

<?
class tv extends electronic  {
  public function setChannel() {}  //추가기능
  public function setVolumn() {}    //추가기능
  private function remote($mode) { }  //추가기능 : 리모트 기능
  public funciton powerOn() { this->remote('on'); }
  public funciton powerOff() { this->remote('off'); }
}
?>
상속의 다형성을 이용해서
추가요구사항 발생에도 불구하고, 기존 클래스인 electronic 수정이 발생하지 않고도,
쉽게 tv 클래스를 만들수 있습니다.

=>메이어박사가 언급한  ocp 개념에서는  상속에 의한 다형성이 중요하였지만,
요즘은, 추상인터페이스 방식의 ocp원칙을 중요시 하고 있는것 같습니다.(이부분은 예제생략)

정리) 보통 객체지향 입문자의 경우, 발생할지 안할지 모르는 요구사항을 미리 고민해서,
 클래스 설계에  반영해야 한다는 강박관념이 있는듯 합니다.
 이 원리에서 강조하고 있는것은, 발생할 모든 요구사항을 파악하는 것이  중요한것이 아니라,
 변경되지 않을 필수적인 요구사항만 파악해라는 뜻으로 생각할 수 있습니다.

  ocp 적용설계시 주의할점3가지
  -  확장되는 것과 변경되지 않는 모듈을 분리하는 과정에서 크기 조절에 실패하면  관계가 더 복잡해진다.
  -  인터페이스는 가능하면 변경해서는 안 된다
  -  인터페이스는 본질적인 특성만 추상화해야 한다.


2.  SRP (The Single responsibility principle) - 단일책임원리
http://en.wikipedia.org/wiki/Single_responsibility_principle
(Robert C. Martin 언급함)

Martin defines a responsibility as a reason to change, and concludes that a class or module should have one, and only one, reason to change
(첵임이란, 변경해야 할이유이다. 이것은 클래스 또는 모듈이 변경할 이유가 단 한가지만 가져야 한다는 것을 의미한다.)

모든 객체는 단일책임을 가져야 한다.라고 언급하였습니다.
즉 클래스나 모듈은 단지 하나의 이유에 의해서만 변경되어야 한다는 것을 강조하는 원리입니다.

두개이상의 책임을 하는 경우, 변하는 책임에 의해 변하는 않는 책임도 영향을 받아서,
연쇄적인 수정이 발생할 가능성 또는 위험성을 미연에 방지하자는데 있습니다.
얼핏보면,  SRP는 OCP와 비슷해보이지만, OCP는 클래스에 존재해야 할 책임의 범위를 규정하는 것이라면,
SRP는 단일 책임을 강조하는 겁니다.
여기서 단일책임은 메소드 한개만을 의미하지는 않습니다.

예) 로그인 처리는 아이디 및 패스워드로 인증여부를 체크후,
인증에 성공하면, 세션이나 쿠키로 인증사실 기록후, 페이지 처리하는 행동을 합니다.

즉 loginProcess 는 다음과 같이  3개의 책임(행동)이 존재할수 있습니다.

<?php
class LoginProcess {
  //1.로그인처리
  function loginCheck($id,$password) {}
  //2.인증처리
  function saveAuthority()  {}
  //3. 페이지처리
  function movePage() {}
}
?>

=>SRP 원칙에 의거 클래스를 분리하겠습니다.

<?php
class Login {
  function Check($id,$password) {}
}

class Authority {
  function save()  {}
  function delete() {}
}

class PageControl {
  function go()    {}
  function back() {}
}
//구현 및 사용법 생략
?>


정리) 클래스나 모듈은 단지 하나의 이유에 의해서만 변경되어야 한다는 것을 강조하는 원리입니다.
위에서는 LoginProcess클래스는 3가지 이유에 의해 변경될 가능성이 있습니다.



3. LSP (The Liskov Substitution Principle) 리스코브의 치환 원리
(http://en.wikipedia.org/wiki/Liskov_Substitution_Principle :위키)

 바바라 리스코브(Barbara Liskov) 1987년에 언급함.
 Let q(x) be a property provable about objects x of type T.
 Then q(y) should be true for objects y of type S where S is a subtype of T.

 함수q(x)에서 클래스 T의 객체 x가 잘 작동한다면,
 T클래스의 서브클래스인 S클래스의 객체 y도 q(x) 매소드에서 잘 작동되어야 한다는 원리이다.
 따라서, 리스코브의 정의에 의하면, 만일 S가 T의 서브클래스라면,
 프로그램상에서  T클래스의 객체는 S 클래스의 객체로 변환하더라도  어떠한 변경이 없어야 한다.

 LSP는 당연하다고 할수 있으나, LSP원칙에 위배되는 코딩을 자주 목격하게 됩니다.

 위배되는 경우는 주로 다음의 3가지 경우입니다.
 첫째, 하위클래스의 동일한 메소드가 유저가 요구하는 메소드로서, 행동하지 않는 경우,  즉 무늬만 같고, 행동이 아예 다른 경우
 둘째, 하위클래스의 메소드가 존재하지 않는 경우
 셋째, 상위클래스와 하위클래스의 형타입 맞지 않는 경우로 요약할 수 있습니다.

 LSP의 의미는  상속받는 하위 클래스는 상위 클래스의 책임을 넘지 말아야  하며,
 하위클래스는 유저가 요구하는 행동되는 설계되어야 한다는 겁니다.
 즉 다형성을 오용해서 사용하면 안된다는 것과, 다형성이 작동안되게끔 하면 안된다는 것임.


4. DIP(Dependency inversion principle) 의존관계역전의 원리
http://en.wikipedia.org/wiki/Dependency_inversion_principle
 Robert C. Martin가 언급함.

High level modules should not depend upon low level modules.  Both should depend upon abstractions.
Abstractions should not depend upon details. Details should depend upon abstractions
높은레벨의 모듈은 낮은레벨의 모듈을 의존하면 안된다. 서로 추상에 의존해야 한다.
추상은 구체적인것에 의존하면 안되고, 구체적인것은 추상에 의존해야 한다.

흔히, 상위개념은  하위개념을 포함하게 된다,
예를 들어, 고양이과 동물에는 호랑이, 사자,표범 등등 동물들이 포함된다.
즉 고양이라는 상위개념은 하위개념인, 호랑이, 사자,표범등을 다 포괄하는개념이다.

하지만, S/W설계에서는, 개념상 포함되어 있다고 하더라도, 상위개념이 하위개념 모두를 표현하거나,
참조하는 것은 나쁘고, 하위개념이, 상위개념을 참고하는 것이 좋다.
즉 이런것을 의존관계가 역전되어 있다고 표현합니다.

예) 고양이과에는 호랑이, 사자, 표범등이 있다. ( 안좋은 참조의 예)
호랑이는 고양이과이다. (좋은 참조의 예)

나쁜 의존관계
<?php
  class tiger    {}
  class lion      {}
  class cheeta {}

  class cat {
    var $tiger ;
    var $lion ;
    var $cheeta ;
    function cat() {
        $this->tiger = new tiger ;
        $this->lion = new lion ;
        $this->cheeta = new cheeta ;
    }
  }
?>
상위개념인 고양이 클래스에서 하위개념인 타이거, 라이온, 치타를 참고하고 있습니다.
구현을 생략했지만, 틀림없이, 불필요한 중복코드가 많아 생깁니다.

객체와 객체의 참조관계에서 is a 관계이면 상속, has a 관계면 합성(위임)의 방법으로 설계해야 합니다. 지금은 is a 관계이기 때문에 상속으로 해결해야 합니다.

<?php
  class cat { }
  class tiger  extends cat  {}
  class lion  extends cat    {}
  class cheeta  extends cat{}
?>

DIP원칙을 지키면
상위모듈개발할때, 하위모듈 개발을 미리 할 필요가 없다는 것입니다.
즉, TopDown 접근방식으로 설계 및 개발이 가능하다는 겁니다.

DIP원리를 설명하면서, 헐리우드 원리가 설명되기도 하는데, 관련은 있지만,
완벽하게 일치 하는 개념은 아닙니다.

헐리우드원리란 배우지망생이 많아서, 오디션 담당자가 전화응답이 너무 힘들어
거꾸로, 오디션 합격자에게만, 전화를 거는 현상을 이야기 합니다.
전화하지 마세요. 우리가 연락할께요..

헐리우드원리예를 보면
온라인 채팅서버와 클라이언트의 관계를 보면, 잘 알수가 있습니다.
채팅정보를 원하는 클라이언트는 채팅서버에게 채팅정보를 게속 요구합니다.
하지만, 서버가 클라이언트에게 전달한 정보가 없다면, 불필요한 서비스요청을 하게 되는 겁니다. http 같이, 비연결성 프로토콜경우 이러한 현상을 잘 나타나는데,
서버가 클라이언트와의 연결정보를 유지할수 없기때문에,
부득이하게, 클라이언트가 몇초단위로 요구하게 됩니다. 즉 불필요한 서비스요청이 게속 발생하게 됩니다.  그래서 이를 해결하기 위한 방법이 서비스제공자인 서버가, 서비스요청자인 클라이언트에게 서비스를 거꾸로 전달하는 겁니다. 이러한 원리를 헐리우드원리 또는 제어권의 역전 현상이라고 이야기 합니다.

이러한 제어권의 역전현상 모두를 상위개념과 하위개념으로 나눌수 없기때문에
DIP 원칙이다 하기에는 무리가 있지만  밀접한 관련이 있는것은 사실입니다.

참고) 대규모의 채팅서비스는 서버소켓방식 통신이 적합하고, 소규모의 채팅서비스는, http통한 서비스도 가능할것 같습니다.


5.  ISP (The Interface Segregation Principle) 인터페이스 분리원칙

ISP원리는 한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 원리입니다.
즉 어떤 클래스가 다른 클래스에 종속될 때에는 가능한 최소한의 인터페이스만을 사용해야 한다는겁니다.

예를 들어보겠습니다.
IWorker 인터페이스에는  work() 메소드와 eat() 메소드가 있습니다.
정규직은, 일하면서, 점식식사를 하지만,
파트타임 알바는 점식식사가 제공되지 않습니다.
이경우 알바는 eat()라는 메소드가 불필요함에도 불구하고,
구현을 해야합니다. 즉, 인터페이스가 분리가 안되어 나오는 문제입니다.
<?php
interface IWorker {    
  public function work();    
  public function eat();
}

//정규직
class standardWorker implements IWorker{    
  public function work() {//todo }    
  public function eat()    {//todo}    
}

//알바
class partTimeWorker implements IWorker{    
  public  function work() {//todo }    
  public  function eat()    {//사용하지 않음}    
}
?>

=>수정

<?php
interface IWorkable  {    
  public function work();    
}

interface IFeedable{    
  public  function eat();
}

//정규직
class standardWorker implements IWorkable,IFeedable{    
  public  function work() {//todo }    
  public  function eat()    {//todo}    
}

//알바
class partTimeWorker implements  IWorkable{    
  public function  work() {//todo }    
}
?>
즉 파트타임 노동자는 불필요한 메소드를 구현하지 않게 되었습니다.

ISP 인터페이스 분리원칙는 SRP 원칙과 관련이 있지만,  SRP는 클래스의 단일책임을 강조하는 거라면
ISP는 인터페이스의 단일책임을 강조하는 겁니다.


=========================================
이상으로 객체지향 5가지 원칙을 설명하였습니다.

디비졍규화가 있듯이 앞서 설명한바와 같이 객체지향설계에도 지켜야 할 5가지 원칙이 있습니다.
이러한 5가지 원칙이 앨랜케이가 스몰토크를 만들데, 개념화한것이 아니라,
수십년 지난 이후, 여러 고수 개발자들이 객체지향설계을 하면서 얻은 경험을 바탕으로
책이나 잡지에 발표한것이라서, 학문적으로 표준화되어 있지는 않는것 같습니다.

우째든 객체지향 설계 및 개발을 하면서 5가지원칙을 모두 지켜서, 프로그래밍 할수는 없지만,
원리가 지향하는바에 대한 이해와 적용노력을 하는 것이 좋다고 확신합니다.

참고사항

여기서 잠시 앨런케이가 1971년 스몰토크 개발하면서, 설명한 객체지향의 정의는 아래와 같습니다.

1. 모든것은 객체이다.(Everything Is An Object)
2. 객체들은 메세지를 주고 받음으로써, 서로 대화한다.(Objects communicate by sending and receiving messages (in terms of objects))
3. 객체는 고유의 메모리를 가진다.Objects have their own memory (in terms of objects).
4. 모든 객체는 클래스의 인스턴스이다.Every object is an instance of a class (which must be an object).
5. 클래스는 그들의 인스턴스의 공통된 형태를 가진다.The class holds the shared behavior for its instances (in the form of objects in a program list)

http://c2.com/cgi/wiki?AlanKaysDefinitionOfObjectOriented
(참고 : 모든 사유의 대상은 클래스의 인스턴스라는 명제는 고대서양철학자 플라톤의 책에 나온다고 합니다.)

즉 앨런케이가 객체지향이라는 용어를 컴퓨터 영역으로 가지고 왔지만,
설계원리에 대한 어떠한 원칙등을 언급도 하지 않아,
현재 개발자가 고생하는 것 같습니다.


by darkLittleSoldier

ps) 객체지향 설계5원칙에 관한 블로그 포스트마다, 뉴앙스나, 예제가 상이하거나, 부적합경우가 종종 있어서, 제 나름대로 정확한 설명이나 예제를 만들어 볼려고 시도했으나, 저역시도, 한계가 있는것 같군요..  우째든 제글이 다른 포스트를 보는데, 도움이 되었으면 합니다.

오랜만에 설치한 리눅스
브라우저를 띄워보니 한글이 이상할때..

윈도우의 맑은고딕 폰트를 한번 써볼까
맑은고딕 폰트를 다운로드 받아야 한다.
다운로드 받은 파일은 ~/.fonts 를 만들어 그안에 넣고
fc-cache -r 해서 폰트를 추가한 설정을 반영한다.

그리고 ~/.fonts.conf 파일을 만들어 아래의 내용을 붙여넣는다.

firefox를 실행시키면 적용완료.

수시로 나오는 패키지의 버전을 일일이 확인하면서 설치하기 번거로울 때 사용 하시면 됩니다.

# vi /etc/yum.repos.d/CentOS-Base.repo

치시면 vi 로 문서가 뜨는데 i 누르시고 맨 아랫쪽에 있는 글들을 맨 아래쪽에 입력해 주세요.



[utterramblings]
name=Jason's Utter Ramblings Repo
baseurl=http://www.jasonlitka.com/media/EL$releasever/$basearch/
enabled=1
gpgcheck=1
gpgkey=http://www.jasonlitka.com/media/RPM-GPG-KEY-jlitka

[dag]
name=Dag RPM Repository for Red Hat Enterprise Linux
baseurl=http://apt.sw.be/redhat/el$releasever/en/$basearch/dag
gpgcheck=1
enabled=1
 

치시고 ESC 누르신 다음 :wq 로 저장하고 나오세요.

그 후에

# rpm --import http://www.jasonlitka.com/media/RPM-GPG-KEY-jlitka

# rpm --import http://dag.wieers.com/rpm/packages/RPM-GPG-KEY.dag.txt

를 칩시다.


▶ 이용하는 법

원래 버전이 gcc-3.2-17 라고 한다면 뒤에 버전를 빼주고 앞부분만 치시는 겁니다

# yum install gcc 
라고 치시면 gcc의 최신버전으로 설치를 하게됩니다

gcc-c++-3.2-17 이라는게 있다면

#yum install gcc-c++
라고 치시면 됩니다. 이해 되셨죠?

트위터에 링크된 주소를 따라가서 쭈욱 읽어보니
어느분이 블로그를 운영하면서 책을한권 낸것 같다.

과연 이렇게까지 하면서 살아야 하나 하는 생각이 든다.
이렇게 까지 남의 눈을 신경쓰면서 살아야 하는건지..

블로그나 책을 출판해서 얻어지는 사회적인 영향력의 증가가 지식의 축적과 동일하다고 생각하는것은
이해하기 힘든 부분이다.

공부란 내가 필요에 의해서 하는거지 남을 의식해서 하면 안되는거라 생각한다.

위자드닷컴의 자료인데 위젯에 대한 이해와 시장을 한눈에 볼수 있도록 잘 정리되어 있다.