관련 글들 묶어둡니다.
이슈 관리 도구 비교 (2) : 이슈관리란? 이슈관리 도구란? - http://xelion.tistory.com/1303
이슈 관리 도구 비교 (1) : 이슈와 버그란 무엇인가? - http://xelion.tistory.com/1302Mantis Mobile, 사마귀 모바일로 들어오다. - http://xelion.tistory.com/1251알려드립니다. 오래된 글들은1) 현재 제 생각과 다를 수도 있고,2) 그 당시 제가 잘 못 알고 있었을 수 있으나 수정할 생각은 없으며,3) 예전 글들은 당시의 언어로 쓰여져지금 읽기에는 편하지 않으실 수 있습니다.
일전에 국산 이슈관리 도구인 야옹이의 PM과 인터뷰를 한 내용을 포스팅 한 적이 있는데, 관련 검색어로 꾸준히 방문객 유입이 되어 관련 포스팅을 하나 더 올립니다. 제 공지에도 있다시피, 이 블로그는 제 개인 공간이다보니 「누군가의 장사를 도와주거나 방해할 목적으로 쓰는 글이 존재할 수 있음」을 공지 하였습니다. 블로그 주인의 성향에 따라 어떤 제품은 좋아도 비판할 수 있고, 나빠도 칭찬할 수 있기 때문입니다. 우리는 그런 것을 「비평」이라 부르는 듯 합니다.
이번 글은 어쩌면 지난 번 올린 야옹이 개발사에는 나쁜 글이 될 수 있겠네요. 국산도구인 데다가 벤처기업이다보니 여러가지 기능상 제약과 한계가 존재하거든요. 뭐, 이 블로그에는 장사 도와주는 글과 반대 글이 공존하고 있으니, 정보가 필요하신 분들의 개인의 판단으로 결정하시기를 바랍니다. 최근 관련 키워드의 유입량이 점점 많아져서, 정확한 정보를 전달해야 할 필요성을 느꼈습니다. 관련 글도 묶어 둘 겸, 겸사겸사 이슈관리 도구 비교 글을 포스팅합니다.
1편. 이슈란? 이슈관리 도구란?
이슈 관리에 대해 알아보기 위해서는 이슈란 무엇인가에 대해 알아보아야 합니다. 그리고 이슈가 무엇인가에 대해 알아보기 위해서는 이슈와 혼동되어 사용되고 있는 버그에 대해 알아보아야 합니다. 먼저 버그에 대해 알아보겠습니다.
1. 버그란?
우리가 소프트웨어 개발 중 발생하는 문제점들은을 흔히 「버그」라고 부릅니다. 영어로 「Bug」이지요. 이 용어는 어디에서 왔을까요?
세계 최초의 버그는 (컴퓨터를 배우신 분들이 한 번쯤 들어보셨을) 여러분들이 알고 계신 진공관 컴퓨터를 이용한 연구를 진행하던 하버드 대학교에서 1947년에 발견됩니다. 사람이 하던 연산을 대신해 주던 거대한 컴퓨터가 어느날 갑자기 연산 오류를 뽑아내기 시작하였고, 이에 대한 원인 분석을 하게 됩니다.
< 출처 - This day in history, September,9, 1947 >
그리고 발견한 것이 바로, 기계들 사이에 끼어 죽어 있는 나방, 즉 벌레(Bug) 한마리였다고 합니다. (아래 그림에는 1945년에 발견되었다고 나와있네요. 1945와 1947중에 어떤 것이 옳은 지 모르겠습니다. 어쨌든 많이 많이 옛날입니다.)
< 그림 - 세계 최초의 버그, 이를 통해 벌레(Bug)라는 말이 컴퓨터의 오류를 지칭하게 됨. >
소프트웨어에서 발생하는 버그는 Bug라고도 하지만, Defect, Problem, Issue, Failure, Fault, Incident, Accident, Error 등 소프트웨어 상의 문제를 지칭하는 여러가지 단어가 존재합니다. 이 단어들은 비슷해보이지만 사실 모두 각각 상황에 따라 다른 의미를 가집니다. 하지만 관련된 논문을 영어로 개재하실 것이 아니시라면, 외국인들도 실무에서는 딱히 구분하지 않으니 신경쓰지 않으셔도 됩니다. 다만 최근에는 이 모두를 포함하는 가장 큰 의미로 이슈(Issue)라는 단어가 부각되었음만 인지하시면 됩니다.
[ 필자의 주저리 ]
기술이 많이 발전해서, 많은 프로세서들과 반도체들이 생산되었습니다. 그래서 놀랍게도 저런 집채만한 컴퓨터보다 여러분들의 스마트폰이 훨씬 많은 일을 해 주고 있습니다. 그런데 지금까지도 우리 컴퓨터는 먼지, 벌레 등에 취약합니다. 놈들이 들어가서 살면 고장이 날 수 밖에 없습니다. 그러므로, 컴퓨터를 사용하실 때 꼭 기억해 두세요.
- PC는 1년에 한 번, 먼지 털어주기
- 노트북은 반년에 한 번, 먼지 털어주기
- 컴퓨터 주위에는 벌레들이 먹고 살만한 환경 조성하지 않기
2. 이슈란?
이슈란 무엇일까요? 사전적 의미를 찾아보면 이렇습니다.
제 블로그의 특성상~ 우리가 살펴보아야 할 부분은 소프트웨어의 이슈일 겁니다. 아시죠? 하하...
소프트웨어에서의 이슈란 무엇일까요? 여러분들이 실제 업무에서 사용하시는 이슈라는 말에는 어떤 의미들이 담겨있나요? 버그(Bug)인가요? 고객의 변경요청(Change Request)인가요? 사장님 지시? 디버그? 네, 모두 다 옳습니다. 사실 이슈라는 말에는 여러가지 접근 관점이 존재합니다. 그래서 정의 내리기가 쉽지 않습니다. 확실한 것은, 예전에는 버그라고 부르던 소프트웨어의 문제점들이 요새는 이슈라는 말로 변경되어 있다는 점이겠지요.
소프트웨어에서 이슈에 대해 위키피디아에서는 이렇게 정의합니다
* 출처 : http://en.wikipedia.org/wiki/Issue_%28computers%29#Issue
In computing, the term issue is a unit of work to accomplish an improvement in a system. An issue could be a bug, a requested feature, task, missing documentation, and so forth. The word "issue" should not be misunderstood as just a synonym for "problem," as in other English usage.
컴퓨터 분야에서 이슈라는 의미는 시스템 내에서 달성되어야할 개선점에 대한 단위 업무이다. 이슈는 버그가 될 수도 있고, 기능 변경이 될 수도 있으며 작업이나 부족한 문서 등이 될 수도 있다. "이슈"라는 단어는 문맥 그대로 "문제점"이라고만 인식되어서는 안된다.
즉, 예전에 컴퓨터의 문제점들을 단순히 버그라고 불렀다면, 소프트웨어가 발전함에 따라 기능 개선이나 문서화 등 「사용자의 요구」를 전체적으로 만족시킬 수 있는 모든 작업을 통틀어 한 마디로 정의할 필요가 발생하였고, 바로 이를 「이슈」라고 정의해야 합니다.
이야기를 더 진행하기 전에 확실히 정리해두시지요.
소프트웨어에서의 이슈는 이렇게 세 가지를 해결하기 위해 정의 가능합니다.
- 문제점 해결 : 버그 + 디버그 등
- 사용자 요구사항 만족 : 변경 + 작업 + 문서 등
- 미래 전략 대비 : 기능 및 확장성 고려 등
3. 소프트웨어에서 버그가 발생하는 이유
소프트웨어에서 버그가 발생하는 이유는 여러가지가 있겠지만, 필자는 그 근본적인 이유들을 아래와 같이 세 가지로 정의하였습니다.
일단 소프트웨어는 독립 개체로 작동하지 않습니다. 소프트웨어는 반드시 (ㄱ) 자신을 구동시켜줄 하드웨어 웨에서, (ㄴ) 전기적 신호에 의해서만 작동됩니다. 이 세상 어떤 소프트웨어도 공기 중에서 독립적으로 활동할 수 없습니다. 그러다보니 소프트웨어가 완벽하다고 쳐도 하드웨어가 마모되면서 발생하는 오류가 있을 수 있습니다. 게다가 전 지구가 하나의 시장이 되는 글로벌화(Globalization)가 진행되면서 시장의 요구가 커지고 있고, 변하고 있고, 다양해지고 있습니다. 이에 맞춘 하드웨어를 생산하다보니 소프트웨어 역시 변화할 필요가 있고, 이곳에서 무한루프(Infinite Loop)가 발생합니다.
두 번 째는, 복잡한 소프트웨어가 작동할 때는 반드시 작동하는데에 필요한 기반 기술이 갖추어진 환경 위에서 작동하게 됩니다. 그리고 우리는 그런 기반 기술을 이야기 할 때 Operating System, 혹은 Platform, 혹은 Framework라고 부릅니다. 문제는 지구상에 아직 완벽한 기반환경이 마련되어 있지 않습니다. 이 부분은 컴퓨터가 발생한 이후 계속 발전해 왔고, 앞으로고 계속 발전해 갈 것입니다. 그럼 OS나 Platform, Framework가 완벽하면 다 해결 되냐느구요? 하하하. 완벽한 플랫폼은 발생할 일도 없거니와, 만에 하나 그런 일이 벌어진다면 그때 지구엔 소프트웨어 개발자라는 직업이 없어질 겁니다. 할 일이 없을테니까요. 전부 UFO 타고 어딘가 여행다니다가 그 행성 사람들의 사진에 찍히겠죠. 하하하.
마지막으로, 소프트웨어라고 구별되어지는 특성 때문입니다. 하드(Hard)웨어는 하나의 제품으로 작동하기 때문에 설계의 유지보수가 어려워도 과정과 결과가 가시적으로 나타납니다. 그런데 소프트웨어는 부드러운(Soft), 유동성 있는 특성 때문에 하드웨어와 같이 가시적이고 시각적인 데이터 도출이 쉽지 않습니다. 조금 더 전문적으로 표현하면 모듈간, 그리고 데이터간의 의존성으로 인해 소프트웨어 내부 구조가 매우 복잡합니다. 이런 복잡한 구조를 해결하기 위해 여러가지 방법(구조적설계, 형상관리, 이슈관리 등)을 차용하고 있지만, 2013년, 아직까지는 이렇다할 대책은 없습니다. (필자의 의견으로는, 코딩 한 줄 못하더라도 소프트웨어 공학에 대해 심각하게 생각하고, 적용하려는 의지가 있는 사람을 찾아 채용하시는 수 밖에 없는 것 같습니다.)
위에서 잠깐 살펴 본, 소프트웨어 버그가 발생하는 근원적 이유를 요약하면 이렇네요.
(1) 소프트웨어는 하드웨어 위에서만 작동하는데, 아직 지구의 인류는 영원히 지속되는 완벽한 하드웨어를 가지고 있지 않다.
(2) 소프트웨어가 작동하는 기반 시스템 환경이 완벽하지 않다. (완벽할 리 없다.)
(3) 소프트웨어는 각 모듈간, 데이터간 의존성으로 인해 내부 구조가 복잡하다.
그리고 바로 이런 문제점들을 어느 정도 해결해 주는 도구 중 하나가 바로 이슈관리 도구입니다.
< 대표적인 프로젝트 관리 도구 & 이슈 관리 도구 >
4. 소프트웨어의 변경에 관한 이야기
위에서 필자는 소프트웨어에서의 이슈를 「변경」까지를 포함한다고 하였습니다. 이 부분에 대해서는 할 말이 참 많으나, 단순히 버그나 이슈만으로 한정 짓기에는 부족하고, 요구사항 분석, 구조적인 설계, 형상관리, 요구사항 관리까지를 포함해야 하며, 굉장히 민감한 한국 문화까지 언급해야 하므로, 언급하지 않고 넘어가려 합니다. 대신 제 블로그보다 몇 만 배는 좋은 내용이 들어 있는 블로그를 소개해드립니다. 그리고 그곳의 필자분이 쓰신 책을 소개해 드립니다.
* 전규현님의 블로그 : All of Software
이 분의 블로그와 책을 읽으시면, 사실 제 블로그에는 오실 필요가 없겠네요. ^^ 가끔 놀러와 주실거죠?
5. 미래 전략
소프트웨어 공학 관련 실무를 하시는 분들 중 한국의 소프트웨어 공학에서 뭔가 나사 하나가 빠진 듯한 느낌을 받으셨다면, 그 분은 저와 같은 느낌을 공유하신 분이십니다. 같이 따끈한 커피나 차 한 잔 하면서 수다를 떨고 싶네요. 필자가 생각하는 그 빠져버린 나사는 바로 「미래 전략」입니다. 한국은 소프트웨어 분야에 있어 한 번도 선도한적이 없습니다. 항상 service layer단의 기술들을 이용해 장사를 해 왔고, 그 분야에서는 돋보적인 기술력을 가지고 있습니다. 특히 쇼핑몰 같은 개인화(Personalize)된 엔터프라이즈(Enterprise) 분야에서요.
실패가 용납되지 않는 사회의 특성일 수도 있겠지만, 어쨌거나 그런 과거를 가지고 있다보니 「미래」나 「전략」 분야에 있어서는 강하지 못합니다. 한국이 과연 IT 강대국이 맞는가 싶을 정도로 IT 전략을 제대로 구사하지 못합니다. 한국의 IT 전략은 행정안전부의 「진흥」 방안에 따라 좌지우지 되어왔을 뿐, 실제로 「전략」을 가진 SW회사, IT회사는 거의 존재하지 않는 것이 현실입니다.
이는 소프트웨어 공학의 정량적 측정이 한 번도 제대로 성공하지 못했기 때문입니다. 최근에는 CI(Continuous Integration)를 이용해서 소프트웨어 개발 단의 정량화를 시도하고 있습니다만, 안될겁니다. 중요한 건 품질이거든요. CI를 넘어서 CM을 이루지 못한다면, 결국 소프트웨어는 또 다시 쳇바퀴를 돌리게 될 것입니다. CI 서버에서 예쁘게 수치가 떨어지니 품질을 위한 첫걸음을 뗀거 같은 착각이 들겠지만, 그건 불치의 병이 호전되고 있다고 환자를 속이는 거짓말일 뿐, 실제로 병을 고칠 수는 없습니다.
확신하건데, 품질 개선은 전략이 없으면 절대 이룰 수 없습니다. 이론과 실무가 다르듯이, 실행과 전략 역시 다릅니다. CI는 실행입니다. 그리고 여기에 「전략」을 덧 붙여야 CM(Configuration Management)이 됩니다. 여지껏 「형상관리」는 소스관리(Source control)이나 문서 관리(Documentation)라고 생각하셨다면 오해이십니다. 앞선 포스팅에서 언급했다시피, 모든 소프트웨어 방법론은 그 실체의 부정확성으로 인해 「사례」를 강요 받게 되고, 사례를 검증하는 과정을 거치면서 그 「사례라는 프레임」 안에 갖히게 됩니다. 우리가 알고 있는 형상관리의 모습이 소스관리나 문서관리인 것도 그래서 그렇습니다. 사실 형상관리는 「Configuration Management」이고, 이는 「프로젝트의 형상」을 의미합니다. 요구사항부터 단위테스트까지를 연결하는 모든 작업을 형상이라고 보아야지, 단지 CI 서버에서 떨어지는 버그들을 보고 미소짓고 있어선 안됩니다.
이슈관리라는 것은 바로 이런 미래 전략을 기반으로 해야만 이룰 수 있습니다.
오늘은 전략이 필요하다는 언급만 하고 넘어가려 합니다. 소프트웨어와 관련된 전략은 북미와 유럽 등 선진 SW국가들에서 이미 10년 전부터 꾸준히 제기되어 왔고, IT Management 등과 관련된 지식들은 넘쳐나지만, 제가 감히 짧은 지식으로 논할 주제는 아닙니다. 언제 기회가 될 때 창피하지 않은 수준으로 포스팅하겠습니다.
< 지구에 홀로 남아 쳇바퀴 돌듯 지구를 청소하다가 나타난 신형 로봇과 친구가 된 Wall-E,
쳇바퀴돌고 있는 소프트웨어 공학에 필요한 것은 기술이 아니라 신뢰입니다.>
