이 전글에 댓글을 달려다가 좀더 정리를 해야 할 것 같아서 본글로 올린다.
2013/02/27 - [프로젝트/품질관리] - 거의 다 만들었어요.
알파, 베타의 정의를 가지고 이렇게 강하게 주장하는 경우는 처음봐서 약간 당황스러웠다. 독자들은 알아서 판단하겠지만 혼란이 있을 수도 있어서 다시 한번 내 의견을 밝힌다.
나는 20년간 한국, 미국, 대기업, 벤처기업을 다 경험하고 이론과 실전을 다 경험하고 온 국민이 쓰는 소프트웨어 개발에도 다수 참여하고 수많은 소프트웨어 프로젝트를 성공시켰고 여러 소프트웨어의 회사의 역량 개선을 시키고 있고 이런 경험을 책(소프트웨어 개발의 모든 것)으로 쓰고 블로그를 통해서 공유하고 있다.
소프트웨어 공학은 실전이다. 이론적으로 먼저 정립된 것이 아니라 실전적인 발전을 거듭해오다가 이론적인 정리가 된 것이다. 따라서 보편적인 이론과 원리가 있고 주장이 있으며 회사마다 그 응용이 있다. 물론 모든 회사의 응용이 효율적인 것은 아니다. 대부분의 우리나라 소프트웨어 회사들의 응용이 비 효율적인 이유는 그 원리를 모르고 응용만 해왔거나 스스로 방법을 생각해 냈기 때문에 한계가 있는 경우가 많다.
세상에는 수만가지 종류의 소프트웨어가 있고 그에 알맞는 라이프사이클도 약간씩 다르다. 다른 것이 잘못된 것은 아니다. 따라서 하나의 프로세스나 이론만 들이대고 이대로 따라하면 모든 소프트웨어에 알맞다고 주장하는 것은 틀릴 가능성이 매우 높다.
이론서를 보거나 Wikipedia를 보더라도 "generally"라는 용어를 주로 사용하는 이유가 그것이다.
알파, 베타라는 용어도 최초에 한사람이 이를 정의하고 모든 사람들이 이것을 따르라고 한 것이 아니다. IBM에서 최초로 A, B버전을 사용하였고 수많은 회사가 이런 용어를 따라했으며 Microsoft가 이후에 많은 영향을 미쳤으며 수많은 회사들이 이와 유사한 용어를 따라서 써오다보니 어느 정도 정립이 되었을 뿐이다. 각 회사의 프로세스 정의서에 알파, 베타에 대한 정의가 서로 다르며 이것이 틀린 것은 아니다.
제가 컨설팅했던 수많은 회사에서도 알파, 베타 버전의 용어가 비슷은 하지만 미묘하게 약간씩은 다르다. 회사마다 천차만별로 다른 것이 아니고 핵심적인 것은 비슷하지만 약간씩 다른 것이다. 이것이 틀린 것은 아니다. 회사마다 소프트웨어의 성격에 따라서 강조해야 하는 것이 다르고 프로세스가 다르다. 그렇다고 회사에서 개인마다 다르게 사용해서는 안된다. 회사내에서는 동일한 절차와 정의를 사용해야 한다. 회사마다 코딩컨벤션이 다른 것도 그 하나이다.
회사를 옮기면 그 회사의 조직, 프로세스, 규칙을 익혀야 한다. 대부분의 회사가 비슷한 프로세스와 정의를 사용하기 때문에 이를 익히는데 며칠도 걸리지 않는다. 대부분은 그냥 적응한다.
회사마다 다른 극단적인 예를 들면 5년이 걸리는 화상탐사선을 개발할 때와 간단한 Web application은 알파, 베타, RC를 다루는 방법이 다르다. 화성탐사선은 스펙이 완벽하게 정해지고 수정되는 법이 없고 스펙이 바뀐다면 엄청난 크로스체크와 절차가 필요하다. 하지만 간단한 Web application은 많이 다를 것이다.
모든 것은 어떻게 하면 소프트웨어를 가장 효율적으로 개발하느냐에 집중되어 있다. 소프트웨어의 성격에 따라서 회사의 조직, 프로세스, 시스템, 문화등이 비슷은 하지만 조금씩 달라진다. 어떻게 하면 효율적으로 개발할지 고민을 하다보니 여러 라이프사이클이 나오고 방법론도 매우 많다. 그 중에서 개발하는 소프트웨어에 가장 알맞는 방법을 선택해야 한다. 여기서 한가지만 옳다고 주장하는 것도 잘못된 것이지만 비효율적인 방법을 선택하는 것도 안좋다.
우리가 주의할 것은 하나의 경험이나 학습으로 세상의 모든 진리로 착각하면 안되겠다는 것이다. 그래서 나도 글을 쓸때 항상 조심하는 편이다. 또한 다른 사람의견에 빈정대거나 공격하지 않고 건설적인 토론을 하려고 노력한다. 하지만 대중을 상대로 하는 일이라 힘들때가 많다. 교양있는 여러분의 많은 경험을 같이 나누고 싶다.
image by Israel Defense Forces
