완전 무결한 소프트웨어를 위한, 클린룸(Clean Room) 모델

단계적 프로세스 모형을 구체적으로 구현한 클린룸 모델은 IBM사에서 만든 모델이다. 시스템의 핵심이 되는 부분을 최초의 프로토타입 모형으로 개발을 하고, 계속 증대해 나가는 나선형 모델 혹은 진화형 모델과 유사한 모델로 볼 수 있다. 클린룸은 오염 제어가 행해지고 있는 한정된 공간으로 공기 속에 포함되어 있는 먼지 뿐 아니라 온도, 습도, 실내 공기압, 가스성분, 정전기, 미진동, 전자파 등 환경조건이 제어되는 실을 의미 하는데 이와같이 철저한 혹은 완전 무결한 공정을 통해서 SW를 개발한다는 의미라고 받아 들이면 될 것이다.

cleanroom의 모습

---

1. 완전 무결한 소프트웨어 개발지향, 클린룸 모델

가. 클린룸 모델(Clean Room) 모델의 개념

- 수학적(정형명세/검증), 통계적(테스트) 이론에 기반한 Box 구조기법을 사용하여 무결한 SW 개발을 지향하는 반복/증분 방법론

- 코드 분석 및 설계가 엄격하고, 수학적/과학적 기법에 근거한 정형적 검증을 이용하는 점증적 개발 모델

※ The philosophy is defect avoidance rather than defect removal. (철학은 결함제거보다 결함회피이다.)

나. 클린룸 모델의 특징

- 정형명세, 점증적인 개발, 구조적 프로그램

- 수학기반 정확성 증명, 통계적 시험 수행

- 중요도, 이용빈도, 사용자 피드백으로 incremental 개발 순서 결정

다. 클린룸 모델의 장/단점

장점 :  제품 결함의 엄격한 관리, 완전무결한 시스템 추구

단점 : 숙련된 엔지니어 필요. 기술력이 낮은 조직에서는 사용하면 효과적이지 못함

- 클린룸은 3가지 Box, 블랙/상태/클리어 박스로 검증

2. 클린룸 모델의 개발 프로세스

가. 클린룸 모델의 점진적 개발 개념

나. 클린룸 모델의 개발 프로세스

• 계획 : 요구분석 → 기능명세 → 이용시나리오 기술 → 증분 계획서 작성
• 반복 : 증가분계획 수립 → 요구사항 분석 → 박스구조명세 → 정형적 설계 → 정확성 검증 → 코드생성/검증 → 통계적 테스트 → 인증/통합

3. 클린룸 모델의 박스구조

블랙박스 (Black Box)

- 명세를 입력으로부터 출력을 얻기 위한 기능을 구체적으로 다루지 않고, 추상적인 블랙박스로 표현

- 사용자 관점, 시스템 행위 명시, 이벤트 반응 매핑

- 데이터 흐름 중심으로 데이터 변환 가능 표현

상태박스 (State Box)

- 블랙 박스 상태, 상태 데이터와 서비스 연산을 캡슐화, 처리과정 은닉

- 내부에서 사용되는 데이터 변환 수행 기능을 다시 블랙박스로 기술

- 블랙박스에서 기술한 입출력과 상태박스는 매칭되어야 함

클리어박스 (Clear Box)

- 상태박스 상세, 전이기능 정의, 절차 설계 포함

- 내부 블랙박스간 제어 흐름 및 시간적 의존 관계를 자세히 기술

4. 클린룸 모델의 통계적 검증

• 박스 구조 분석 : 입출력 중심, 형식적 기능명세 검증
• 함수등가성에 기초한 검증 : 명세와 순차/분기/선택/반복 제어구조가 등가인지 리뷰
• 통계적 테스트 : 이용시나리오 활용, I/O 변환과정에 중점

참고, 함수등가성

- 명세를 입력과 출력과의 대응관계를 정의하는 함수로서 다루어, 명세를 자세하게 한 것이 입출력 관계와 기능에 있어서 원래의 명세와 등가임을 판정하는 기준

키워드

Incremental, 블랙/상태/클리어박스, 함수등가성, 통계적 기법, 무결

이것만 봐서는 이해가 잘 안되실 것이다. 도대체 이런게 SW 세계에서 쓰이고나 있는건가? 라고 묻는 사람들이 있을텐데 솔직히 이런 공정으로 개발을 하는 곳을 단 한군데도 본적이 없다. 내가 모르는 어떤 팀에서는 이런 방식을 사용하고 있는지는 모르겠지만, 아마도 하게 된다면 정말 0.0001%라도 에러가 발생되면 안되는 그런곳에서는 쓰일지 모르겠다(ex: 우주 관련 개발, 항공 ..)

이해가 안되는 사람들에게 요점을 정리한다면, "통계적 기법과 과학적 기법을 총동원하고, 개발을 철저하게 하기 위해, 블랙/상세/클리어 박스같은 것으로 설계 및 검증하는 식으로 완벽한 SW를 만드는 것을 의미"한다.

그러나 SW의 장애는 에러가 발생하지 않아도 날 수 있다. 그렇기 때문에 이렇게 공수가 많이 들어가는 방법보다는 에러가 발생하였을 때, 내결함성(fault tolerance)으로 SW를 만드는 것이 훨씬 이익이라 개인적으로 생각한다. 물론 삼성이나 애플 같은 글로벌한 기업에서는 이미지에 엄청난 영향을 주는 기기(아이폰, 갤럭시 노트 등) 및 SW에서는 철저히 QA를 하겠지만 말이다.