2013년 2월 27일 수요일

거의 다 만들었어요.


"거의 다 만들어서 2주후에 개발이 끝나요"

이 말을 이해할 수 있는가? 우리 주변에서 소프트웨어를 개발할 때 흔히 들을 수 있는 말이다.
개발자들도 이렇게 얘기하고 관리자나 경영자도 대충 알아듣는다.

하지만 이런 대화는 여러 오해를 양산한다.

영업 담당자는 2주후면 고객에게 소프트웨어를 제공할 수 있는 것으로 착각하기도 하고, 경험이 좀 있는 관리자는 아직 충분히 안정적이지 않거나 테스트가 남아 있다는 것도 알기도 한다. 하지만 정확하게 언제 고객이 쓸 수 있는 제품이 나오는지는 알 수가 없다.

그래서 우리는 좀더 전문적으로 제대로된 용어를 사용해서 커뮤니케이션을 할 필요가 있다.

우선 개발 단계별로 정확한 용어를 사용하는 것이 필요하다.

"개발"이라는 말은 너무나 모호하다. 사실 스펙을 쓰는 일부터 유지보수 까지 모두 개발이다.
그래서 분석/설계/구현/테스트 등 단계별로 세분화된 단어를 쓰는 것이 좋다.

따라서 "개발이 끝나요"보다는 "구현이 끝나요"가 좋다.

그 다음에는 개발팀에서 만들어내는 버전이 어느 정도 수준인지 표현할 필요가 있다. 내부 테스트를 진행할 수 있는 수준인지 필드테스트를 할 수 있는 수준인지 알려줘야 한다.

일반적으로 이런 수준을 표시하는 용어는 많이들 들어봤겠지만, 알파/베타/RC 등이 있다.

알파버전이란 모든 기능의 구현이 완료되었고 버그는 많지만 Show stopper가 없는 수준을 말한다. 주변에서 "개발이 다 됐어요"라고 말할 때도 자세히 살펴보면 알파 수준도 안되는 경우 많다. 기능이 99% 완료 되었으면 알파가 아닌 것이다. 예를 들어 설치 프로그램은 아직 개발을 안했다던지 간단한 기능의 일부가 미 구현상태면 알파가 아닌 것이다. 

따라서, 미국이나 인도나 어디에서도 알파버전이라고 하면 이 수준으로 이해를 하면 된다. 

그리고 알파버전 테스트에서 발견된 버그를 대폭 수정해서 버그를 많이 줄인 버전을 베타버전이라고 한다. 베타버전은 내부테스트를 하기도 하고 고객을 대상으로 외부 테스트를 하기도 한다. 베타버전은 버그는 있지만 꽤 쓸만한 버전이다.

RC버전은 Release Candidate의 약자로 테스트를 해보고 출시를 결정할 후보 버전이다. 따라서 대부분의 경우 아주 안정적이다. 출시가 결정되면 바로 고객이 사용하는 버전이다. 물론 버그가 없는 것은 아니지만 충분히 안정적이다.

따라서 알파/베타/RC등의 용어를 적절하게 사용해서 개발팀에서 만들어낸 버전이 정확하게 어느 정도 수준인지 전달을 해야 한다.

"2주후에 개발이 끝나요"보다는 "2주후에 알파버전 구현이 끝나요"가 좋다.

좀더 자세히 말하면 "2주후 금요일 오후3시 정각에 알파버전 소스코드 프리즈가 있습니다."라고 하면 좀더 정확한 의미가 전달된다.
개발자들은 3시까지 모든 소스코드를 Commit해야 하고,
빌드팀은 3시가되면 소스코드를 내려받아서 빌드를 하고
테스트팀은 3시쯤 되면 알파테스트를 시작할 준비를 하고 기다리고 있을 것이다.

관리자나 경영자는 당연히 테스트 일정을 알고 있고 언제 출시 예정인지 알고 있다.
이슈관리시스템을 보고 있으면 거의 실시간으로 발견되는 버그와 고쳐지는 버그의 현황을 볼 수 있다. 

하지만 아직도 대부분의 개발 현장에서는 이런식으로 커뮤니케이션이 이루어지지 않고 있는 것이 현실이다. 

알파/베타 등의 용어를 들어봤거나 사용하고 있어도 그 의미를 정확하게 사용하지 않고 있는 경우가 많고 개발자와 영어/관리자/경영자가 그 의미를 똑같이 공유하고 있는 않다. 서로 다르게 생각하고 있으면 커뮤니케이션에 문제가 자주 생긴다.

세계적으로 표준으로 사용하는 용어들이니 표준에 맞게 사용하고 모든 직원이 똑같이 공유를 해야 한다.

그래야 좀더 합리적인 일정으로 개발이 진행된다. 

댓글 8개:

  1. 저부터라도 오늘부터 이런 세부적이고 명확한 커뮤니케이션을 해야겠군요. 좋은 글 감사합니다.

    답글삭제
  2. 글의 취지는 공감하나, 글에서 쓰신 알파, 베타, RC의 정의도 올바르지 않아 보입니다.

    알파버전은 모든 기능의 구현이 완료된 것이 아니라, feature freeze를 하기 위한 테스트 버전입니다. 즉, 알파 버전 가지고 테스트를 한 후에야 feature freeze가 된다는 겁니다. 상황에 따라 crash가 있을 수도 있고, data loss도 있습니다.
    베타버전은 알파버전을 통한 테스트 후 feature freeze가 되고, feature complete을 한 후 수행하는 테스트입니다. 베타 테스트의 목적은 주로 feature들에 대한 usability 테스트입니다. 그래서 사용자의 피드백에 따라 반영하는 과정을 베타1, 베타2, .. 등 여러 번 거치기도 합니다.
    RC 버전은 Unknown Major Bug가 없는 상태(그에 따라 Known Bug는 있을 수 있음)이며, RC 버전을 통한 테스트를 거쳐 Code Complete을 하는 것을 목표로 합니다. RC1, RC2 등 여러개가 나오는 경우가 있는데, 베타와는 다르게 말 그대로 별도의 후보 Set을 말합니다. 숫자가 높다고 더 좋은 것도 아닌거죠. 이 경우 Known Major Bug를 workaround하기 위한 경우들이 대부분입니다. 회피할 버그의 종류나 workaround 방법이 달라지니 후보 set이 여러개 나오는 거죠.

    위키피디아에 있는 정의라도 잘 읽어보셨으면 합니다.
    http://en.wikipedia.org/wiki/Software_release_life_cycle

    답글삭제
  3. 안녕하세요. 안재우님

    의견 감사합니다. 이런 정의를 모르고 썼겠습니까? ^^ 쉽게 풀어서 설명한 것이지요.
    제 책에서는 자세히 설명이 되어 있으니 참고를 하세요.
    릴리즈사이클에 대한 정의도 일반적으로 이렇게 정의를 하지만 회사마다 약간씩 다르기도 하고 실제 프로젝트에서는 이보다 훨씬 복잡한 상황들이 벌어지죠. 알파버전 이후에 기능을 추가하는 경우고 심심치 않게 발생합니다. 원칙에는 어긋나보이지만 그런 경우 회사마다 대처하는 방법이 다르죠. 백과사전에는 모든 답이 있지만 실제 경험을 해보지 않은 사람들은 백과사전을 보고 따라 할 수 있는 것은 아니죠. 그런 맥락으로 대부분의 독자의 눈높이에 맞추고 있다고 생각하시면 되겠습니다.

    대부분의 회사가 이런 단계별 테스트를 하지도 않고 있기 때문에 왜 복잡하게 설명하지 않고 일관된 커뮤니케이션 한 주제에 대해서만 간단하게 설명하고 있는지 이해를 하실 수 있을 겁니다.

    답글삭제
  4. 알파버전에는 crash가 있을 수는 있지만 Show stopper가 있어서는 안되는데 그 정의는 빠져있군요. :)

    답글삭제
  5. 글쎄요, 쉽게 풀어서 설명하는 것과 각 단계를 구분하는 핵심이 설명되지 않은 것은 좀 다르다고 봅니다. 대부분의 사람들이 알파, 베타, RC 간의 차이가 그냥 버그가 더 적고 안정화되는 것이라고만 알고 있습니다. 그러다 보니, 개발팀에서 제멋대로 갖다 붙이는 경우가 많습니다. 하지만 알파/베타/RC라는 명칭은 원래 개발팀에서 임의로 붙일 수 있는 것이 아니지요.

    항상 베타가 알파보다 버그가 적지도 않습니다. 물론 알파 테스트를 거쳤기에 적을 수도 있지요. 하지만 Feature 변동이 있기에 베타가 오히려 버그가 더 많을 수도 있습니다. 그리고 Known Bug가 아닌 항목들이 베타에서 등장하기도 하지요.

    그리고, 답글을 주신 내용을 보면 이상한 항목이 있는데요,
    '알파 버전 이후에 기능을 추가하는 경우는 심심치 않게 발생합니다. 원칙에는 어긋나 보이지만'이라고 하셨는데, 원칙에 어긋나지 않습니다. 알파 버전의 '개발'이 아닌 '테스트' 이후에야 Feature Freeze가 일어날 수 있으니까요. 테스트도 안해보고 사용자의 피드백도 들은 적이 없는데, 알파 버전이 모든 기능 구현이 완료된 버전이 될 수 없지 않을까요?

    백과사전, 이론, 원칙대로 현실에 모두 반영할 수 없는 것은 맞는데, 이론과 원칙을 잘못 알고 있으면서 현실만을 얘기하는 것도 위험하지요.
    예를 들어, 어떤 프로젝트의 개발팀장이 이 글을 읽고 알파 버전에선 기능 구현이 이미 끝나서 버그 고치는거 빼고 일체 기능 추가나 변경은 못한다라고 주장하면 어떻게 될까요? 사실 알파 단계에서 이렇게 한다는 건 고객의 피드백을 별 그다지 들을 생각이 없는 경우입니다. 프로젝트는 일정 내에 끝낼 수 있을지 몰라도, 고객에게 좋은 평가를 듣거나 시장에서 크게 성공할 가능성이 거의 없다고 봐야죠.

    답글삭제
  6. 안녕하세요. 안재우님

    제가 원래 이런 토론을 아주 좋아하지만 이상하게 말꼬리를 잡고 늘어지는 형태로 얘기를 하시는 것 같아서 조심하게 되는군요. "원칙에 어긋나 보이지만"이란 말도 과도하게 해석해서 부풀리는 것 같습니다. 또, 첫번째 댓글에 약간 빈정대는 투가 있기는 하지만 그대로 이해하겠습니다.

    기본적으로 안재우님의 주장은 다 공감합니다. 친절하게 쓰셨으면 더욱 공감했을 겁니다. ^^ 제 독자들도 이런 말꼬리에 회사에서 억지 주장을 하지 않을 거라고 믿고 있습니다. 많은 독자들은 제가 쓴 "소프트웨어 개발의 모든 것"을 읽었거나 오랫동안 블로그를 구독하고 있어서 말꼬리 하나하나 보다는 전체적인 맥락에 공감을 합니다.

    소프트웨어 개발의 큰 원리는 같으나 회사마다 다른 것들도 많아서 하나의 주장만 맞다고 하면 문제가 되는 경우가 있습니다.

    알파버전에 관한 것도 큰 맥락은 같으나 용어와 정책들도 서로 다릅니다. 헌법은 아니죠. Feature freeze라고 하는 곳도 있고, 알파버전에 Spec을 close하는 회사도 있습니다. 고객의 피드백을 알파 이후에 하는 회사도 있고 개발단계에서 Mock up을 가지고 미리 하는 회사도 있습니다. 사실 현실에서는 이보다 100배 더 복잡합니다. 이런 것에 대한 원리를 설명한 글은 안재우님의 참고로 들으신 Wikipedia글이 더 잘 대표를 한 것 같습니다. 그렇다고 제가 항상 Wikipedia를 배낄 필요는 없다고 생각합니다. 20년부터 알파, 베타를 비롯해서 소프트웨어 공학을 사용했고, 미국 실리콘밸래의 회사와도 같은 방식으로 일을 했고 이론과 경험은 충분하다고 생각합니다.

    건설적인 주장과 토론은 환영합니다. 가끔 이런 반응에 대한 우려로 글을 쓸 때도 좀더 신중하게 정리를 해서 쓰고 싶기는 하지만 저도 시간이 그렇게 많은 편이 아니라서 후다닥 글을 쓰는 형태를 바꾸기는 어렵겠네요. ^^

    아무튼 적극적인 반응 감사합니다.

    답글삭제
  7. 베타단계에서 사용자의 피드백을 받아서 베타1, 베타2 등을 만들어 내는 것은 안재우님의 경험을 말씀하신 것이 아닌가 생각합니다.
    그럼 베타단계에서 사용자의 의견에 따라서 스펙이 바뀐다는 얘기인데 어쩔 수 없이 그렇게 해야 하는 소프트웨어도 있기는 하지만 스펙을 베타단계에서 바꾸는 것은 많은 비용을 지불해야 하기 때문에 애초에 스펙단계부터 변경을 최소화하기 위해서 잘 작성하는 것이 일반적이라고 볼 수 있습니다.

    소프트웨어 개발 방법론(or 라이프사이클)에는 여러가지가 있기 때문에 베타테스트에서 사용자의 피드백을 반영해서 계속 바꾼다는 것이 틀렸다고 말하고 싶지는 않습니다.

    우리나라의 많은 회사들이 그런 식으로 소프트웨어를 개발하고 있고 그럼으로 인해서 많은 비용을 지불하고 있습니다. 우리나라에서는 흔히 고객은 실제 동작하는 소프트웨어를 보여주기 전에는 피드백을 줄 수 없다고 합니다. 많은 비효율이 여기서 출발합니다.

    제가 많은 대기업, 중견기업를 포함해서 중소소프트웨어 회사에서 요구공학을 가르치고 스펙 작성을 도와줬는데 제대로 스펙을 작성할 수 있는 엔지니어는 2~3%도 안되는 것이 현실이죠. 그래서 이같은 현상이 어쩔 수 없이 벌어집니다. 스펙을 제대로 작성하면 이후 발생하는 변경이 최소화되죠. 방법론에 따라서 스펙 작성방법이 다르기 때문에 꼭 어떻게 작성해야 한다고 주장하지는 않습니다. 하지만 스펙 작성 역량도 없이 이런 저런 방법론만 주장하는 사람들도 많기는 합니다.

    아무는 저는 소프트웨어를 보여주기 전에 스펙단계에서 고객의 요구사항을 충분히 반영할 수 있도록 교육을 하고 있습니다.

    RC 버전은 Unknown Major Bug가 없는 상태라는 것은 발견하지 못한 Major bug가 없다는 얘기인데 이것은 불가능한 것 같습니다. Unknown한 것은 있는지 없는지는 알 방법이 없습니다. 또한 RC는 후보군이기 때문에 Major Bug가 있을 수 있는데 회사에 따라서는 Major bug가 있으면 Release가 허용이 안되는 회사도 있습니다. 또한 한국에서는 많은 회사들이 Critical,Major,Minor,Trivial,Showstopper 등 버그의 숫자만 보고 결정하는 프로세스를 만들려고 하는데 버그의 숫자만 가지고는 판단하기 어렵기 때문에 Go-live회의를 통해서 Release여부를 결정합니다. 실패시 RC2를 만들어 내기도 합니다.

    저는 소프트웨어 공학은 실전이라고 생각합니다. 이론을 잘아는 소프트웨어 공학 교수님들이 소프트웨어는 제대로 개발을 못하는 이유입니다. 따라서 저는 다른사람들의 실전적인 방법에 대해서 비난을 하지는 않습니다. 단지 컨설턴트로서 좀더 좋은 방향으로 개선을 해줍니다. 그렇다고 제가 소프트웨어 공학 이론을 모르는 것은 아니죠. 처음부터 이론을 먼저 공부한 것은 아니고 20년 실전을 해오다 보니 이론을 접할 기회가 많아서 익히게 된 것이죠. 그렇게 쌓이면 원리를 깨우쳐서 이론에서 주장하는 문구 하나하나에 집착하지 않은 상태가 됩니다. 저는 몇몇 분야에서는 원리를 깨우친 상태라고 할 수 있습니다. 그래도 여러 회사의 상황들은 제게 많은 도움이 됩니다.

    앞으로 건설적인 토론이 계속 되면 좋겠습니다.

    답글삭제
  8. 안녕하세요. 처음 댓글에서 밝혔듯이 저는 기본적인 글의 취지 자체에는 공감하고 있습니다. 다만 Consensus를 형성하기 위한 전제가 되는 '용어의 정확한 의미를 이해하고 사용'이라는 측면에서의 문제를 지적한 것입니다. 예로 드신 용어가 보편적인 정의와 일치하는 것이라면 제가 애초에 댓글을 달 이유도 없었겠지요.
    계속 말씀하시는 것은 용어에 대한 정의가 '상황에 따라 다르다', '회사에 따라 다르다'라는 건 결국 '개인에 따라서도 달라질 수도 있다'라는 건데, 원 글의 취지와 모순되어 보인다는 생각이 듭니다. 하지만 엄밀히 말하면 정의가 다른게 아니라, 해석과 적용이 다른 것일뿐이 겠지요.

    토론의 정의는 '각각 다른 의견을 말하면서 논하는 것'인데, 의견이 같아 공감하는 부분은 이미 얘기했고, 다른 의견에 대해 논하는 것을 원치 않으신듯 하니 저 역시 더 이상 토론을 진행할 것이 없을 것 같습니다. 그에 따라 '원래 정의가 뭐라고 되어 있든, 최소한 조직 내에서는 동일한 것으로만 맞추면 된다' 정도가 원래 글의 취지였다고 이해하도록 하겠습니다. 그럼 이만..

    답글삭제