2012. 11. 4. 22:05

1. 소프트웨어 품질은 어렵다.


소프트웨어 품질은 어렵다. 어려워도 너어어~~~무 어렵다. 소프트웨어 품질이 어려운 이유는 정말 정확하게 말하면 "달성되었다" 라고 특정 시점으로 끊어서 결론 내기가 어렵고 "달성되어 있는 상태다" 정도로 표현할 수 밖에 없기 때문이다. 왜냐하면 소프트웨어 품질은 지속적으로 관리되어야 하는 활동(on going activity)이기 때문이다. 소프트웨어 테스트 활동은 소프트웨어 개발 활동과 병행으로 수행된다. 소프트웨어 테스트 계획은 요구사항 단계에서부터 시작하여, 개발 생명주기 동안 지속적으로 수행되면서 소프트웨어의 품질을 향상시킨다. [Software testing and continuous quality improvement, WE Lewis, 2004]


우리나라에서는 이 on going activity 성격을 가진 활동이 작게는 모듈 통합, 크게는 컴포넌트 단에서의 테스팅 활동에 초점이 맞추어져 있다. 이전에 다른 포스팅에서 언급했다 시피 이런 문제는 PMBOK의 8장인 Quality Management가 너무 수험 위주로 이론이 맞추어져 있고, 이에 대한 실전적인 지식이 전달이 잘 되지 않기 때문이며, 그 상태로 너무 오랜 시간 동안 우리나라의 IT 산업이 흘러왔기 때문에 모두 익숙해져버린 것이 원인 중 하나이다. [PMBOK, http://www.pmi.org]


또 다른 이유를 들자면, 2000년에 미국의 유타에서 애자일 선언문[Agile Manifesto, http://agilemanifesto.org]이 발표된  이후, 우리나라에도 애자일의 열풍이 불어닥쳤다. 애자일에서는 앞서 언급한 이런 문제들이폭포수(waterfall) 모델의 한계라고 규정하고 새로운 방법으로 코드 품질을 높이려는 생산적인 시도들을 발생시켰다. 하지만 세상은 등가교환, 즉 완벽한 것은 없는 법. 애자일이 대중화 되다보니 (충분한 경험을 가지지 못한 사람들이 이용하면서) 프로젝트 초기 충분한 고려가 이루어지지 않아도 되고, 문서 작성도 안해도 되는 것이 애자일이라고 곡해되기에 이르렀다. 심지어 애자일을 프로세스라고 부르는 사람들이 생겨날 정도로 심하게 왜곡이 일어나고 있다.




2. 애자일에 대한 뻘소리


필자가 애자일에 대한 쓴소리를 자꾸 내뱉는 것은, 애자일의 단점이 부각되지 않고, 관련된 업급들이 이단 취급을 받으며 배척당하고 있는데, 그 이유가 종교가 널리 퍼지면서 다른 이데올로기를 억압하는 모습과 너무나도 닮았기 때문이다. '나라도 해야지' 라는 절박함?, 혹은 정의감? 같은 것이 자꾸 생긴다.


필자도 애자일 좋아한다. 애자일로 실제로 성공했던 프로젝트들도 꽤 있다. 단, 진짜 애자일로, 제대로 진행하니 옆 사람들, 그리고 필자가 관리하는 사람들이 굉장히 피곤해 하더라는 거 정도.


애자일 이야기를 하게 되었으니, 분명히 하고 싶은게 있는데...... 애자일은 early involvement를 달성하기 위한 가능한 현실적인 접근 방법에 대한 철학이다. 반복적 개발 모델이나 점진적 프로세스는 애자일이 지향하는 '조기 참여'를 이루기 위한 방법이고 도구일 뿐, 그것 자체가 애자일은 아니다. 스크럼은 프로세스다. 스프린트는 프로세스다. 개선 가능하다. 하지만 애자일은 개선이 가능한게 아니다. 그 안에 스크럼, 스프린트, 짝개발, 여러가지 평가방안, 회고까지가 애자일이다. 그러므로 애자일은 프로세스라고 부를 수 없다. 


애자일이 프로세스라고 생각한다면, 애자일 선언문을 다시 읽어보고, 그 전문가들이 서기 2000년에 모여서 어떤 고민을 했고, 어떤 생각으로 그런 선언을 발표 했을 지에 대해 곰곰히 생각해 보기를...... 사실 모든 것은 단지 early involvement를 이루어내기 위한 철학일 뿐이다. 인간이 숨쉬는게 너무 당연하니 공기에 대해 인지하지 못하는 것처럼, 조기참여라는 사상이 너무 당연하니 인지하지 않고 다른 이야기들을 하는 것 뿐이다.


필자를 부정적인 시선으로 보든, 어느 커뮤니티에 가서 이단이 있다고 신고를 하든, 뭘 하든 상관 없다. 이번 포스팅에서 하고자 하는 이야기를 하려고 꺼낸 이야기니까. 이런 소모적인 논쟁으로 태클 걸리기 딱 좋은 글을 싸지르는 이유는 이거다. "때로는 멀리 돌아가는게 제일 빠른 길일 수 있다" 는 것. 때로는 굉장히 기본적인 소프트웨어 공학이 가장 빠른 지름길이 될 수 있다는 점도 이제는 논의되어야 하는 것이 아닌가? 




3. 스타 개발자와 부작용


한국은 언제나 스티브 잡스 같은 스타 개발자가 부럽다. 질투난다. 가져본적이 없다. 아니, 게임 업계 몇 명 있었다. 근데 그나마도 차기작들을 발표하고는 이른 겨울 서리 맞고 우수수 떨어진 낙엽처럼 사라져버렸다. 그래서 자꾸만 스타 개발자를 만들려고 한다. 그리고 자신이 그 존재가 되려고 한다. 소프트웨어 개발의 과정을 증명하는 방법은 잘 모르겠으니 결과만 내 놓으려고 든다. 우연히 좋은 소프트웨어를 만들면 스타 개발자가 된다. 좋다. 그럼 질문 하나. 


"그 사람이 스티브 잡스처럼 혁신을 만들 수 있나?"


애자일이 곡해되었기 때문인지, 아니면 원래 애자일이 그런 방향으로 진화할 수 밖에 없는 것인 지는 알 수 없지만, 어쨌든 그에 대한 반작용으로 2012년 대한민국 대부분의 테스트는 설계 품질이나 코드 품질을 '프로그래머의 역량에 올인' 해서 맡겨 놓고, 이에 대한 객관성과 타당성에 대한 검증은 오로지 컴포넌트 단위에서만 진행한다. 그러다보니 소프트웨어 공학에 기반한 전문적인 소프트웨어 품질 전문가는 육성되지 못하고 오로지 '해봤어?' 라는 명제만으로 사람의 능력을 추측하게 되고, 수 많은 '가짜 공학자'들이 판치는 세상을 열었다. (어쩌면 필자도 가짜다. 땡큐 애자일 곡해자들.) 


또한 제품의 품질이 '모 아니면 도' 라는 식으로 관리되기 쉽상이고, 프로젝트가 엇 나간 경우 '커뮤니케이션의 문제' 혹은 '팀 화합과 소통의 문제'로 결론을 내는 경우가 많다. 정확하게 말하면 "내 잘 못 아니다"인거지. 죽어도 자기 잘못은 없는거다. 남이 멍청하고 안도와 준거지. 자신을 안도와준 그들이 애자일을 이해하지 못한 미개인인거다. 푸하하. 실제로 최근 경험한 몇 개의 프로젝트가 그러했다. 필자의 경험상 사람들이 애자일에 대해 잘 몰랐을 때가 오히려 애자일 방법론 적용 가능성이나 애자일을 통한 프로젝트 성공률은 더 높았던 듯 하다.


필자가 혁신이란 거에 대해 말할 주제는 안되지만, 적어도 그 동안의 경험을 토대로 이런 결론을 내렸다. 과정에 대한 고찰을 생략하고 결과론적인 산출물에 집착해서는 혁신은 커녕 현상 유지도 힘들다는 거다. 위에서 필자가 던진 질문에 대한 자답을 해 본다.


 "잘 팔리는 상품을 만든다고, 그가 스티브 잡스 같은 혁신을 만들 수 있는 것은 아니다."




4. 소프트웨어 테스팅의 기본 중에 기본 중에 기본 중에 기본


이런 큰 세상의 흐름을 한 사람의 힘으로 어떻게 바꾸랴. 바꿀 생각도 없다. 다만 소프트웨어 테스팅이 소프트웨어 공학적인 접근이 아닌, 막무가내 식 수행으로 진정성을 잃어가는 이런 흐름속에서 필자가 할 수 있는 일이 있다. "할려면 제대로 좀 해라" 라고 격려하고 독려하는 것. 여기에 모듈-컴포넌트 테스트에 가장 자주 쓰이는 개념 정리를 해 놓아 본다.


* 참고 문헌: Software testing and continuous quality improvement, WE Lewis, 2004


단위 테스트 (Unit Testing)

- 단위 테스트는 가장 기본적인 단계의 테스트다.

- 단위 테스트는 프로그램이나 시스템의 가장 작은 단위로 나누어 진행한다.

- 단위 테스트의 목적은 각 모듈이 스스로 잘 작동하는 지에 대한 검사이다.

- 단위 테스트는 자동화로 많이 수행되는데, 이는 각 단위에 테스트 해야하는 로직의 양이 적기 때문이다.

- GUI단위의 단위 테스트는 녹화 후 재생 방식으로 검사하기도 한다.


통합 테스트(Integration Testing)

- 단위 테스트가 끝난 후에 수행되며, 모든 모듈은 반드시 한 번 이상 통합 테스트를 통해 테스트 되어야 한다.

- 통합 테스트는 시스템 테스트 전에 반드시 행해져야 한다.

- 통합 테스트의 목적은 모든 모듈의 조합들이 정상적으로 인터페이스 되는 가에 대한 검증이다.

- 통합 테스트는 점진적인 방법으로 이루어진다. 모든 모듈의 조합이 테스트될 때까지 테스트를 진행한다.


시스템 테스트(System Testing)

- 통합 테스트 이후에 수행되며 시스템 테스트 계획에 기반하여 행해진다.

- 블랙박스 테스팅은 프로그램의 기능을 명세에 기반해서 테스트하는 기법을 말한다.

- 화이트박스 테스팅은 로직의 여러 경로에서 예측된 결과대로 작동하는 지를 테스트하는 기법을 말한다.

- 그레이박스 테스팅은 위의 두 가지 방법은 혼합하여 시스템 테스트를 진행하는 기법을 말한다. 위의 두 가지가 균형 있게 조화되어 사용되며, 시스템 테스트에 널라 사용된다.


인수 테스트(Acceptance Testing)

- 시스템 테스트 이후에 수행되며, 소프트웨어 시스템이 요구사항에 부합하는 지를 기반으로 행해진다.

- 인수 테스트는 소프트웨어 제품이 완성된 후 수행되는 것이 일반적이다.

- 인수 테스트는 블랙박스 테스팅 기법을 이용하여 진행된다.

- 시스템 인수 시 (제 3자인) 실제 사용자가 테스트를 진행해야 한다,

- 인수 테스트 중 에러가 발생한다해도 중단하지 않고 계속 수행한다.

- (고객의 시간이 허락한다면) 개발 중간에 지속적으로 인수 테스트를 수행하는 것이 좋다.



혹시나 해서 다시 말 하지만, 이건 기본 중의 기본이다. 윤리 시험 100점 받았다고, 도덕적인 사람일 리가 만무하다. 위의 기본적인 이론들을 실무에 어떻게 적용해야 효율적이고 안정적인 테스트 결과를 확보할 수 있는 지는 전혀 다른 문제이다. 특히 프로젝트 초기 고려를 점점 하지 않는 방향으로 유행이 흘러가는 요즈음의 세태에는 인수 테스팅을 어떻게 효율적으로 수행하느냐가 앞서 말한 early involvement를 달성하는 데에 핵심이 된다. 


Posted by 『 Lv8+の 꽃怪獸 』 천년나무