2009년 08월 20일
결함 관리
나로호 발사의 중단 사태는 일단 개인적으로 걱정스러웠던 소프트웨어 결함인것으로 드러났다.
결함 없는 소프트웨어를 만들기는 매우 어렵다. 아무리 날고 기는 개인이라도 홀로 이것을 피한다는 것은 사실상 불가능에 가깝다. 나 역시여지껏 작성해본 코드중에 컴파일 에러, 버그 없이 한번에 끝난 경우는 단 한 번. 100 라인짜리 알고리즘 구현 프로그램이었던 것으로 기억된다.
일찍이 이 문제를 수도 없이 고민했왔던 NASA의 경우 가장 높은 품질 관리 수준을 갖고 있는 것으로 알려져있다. 웹을 통해 검색해 보니, 그들의 소프트웨어 품질 관리 정책에 관한 문서가 있네. NASA 역시 수많은 소프트웨어 결함 관련 에피소드를 갖고 있지만 하나도 기억이 안나는 관계로 여기서는 패스.
예상컨대 나로호 프로젝트에서 소프트웨어에 하드웨어 만큼의 투자를 하기는 어려웠으리라 생각된다. 첫 시도에서 큰사고 없이 교훈을 얻었으니 이제부터 그쪽 분야에도 많은 투자를 하면 되겠지.
사실 당장 내게 절실한 문제는 게임에서의 버그 문제이고, 내 성격이 그다지 꼼꼼하지 못해서 과거 내 게임에서의 버그 문제에 대해서는 찔리는 부분이 많다. 경험이 쌓일수록 자동화와 측정을 통한 극복에 노력은 해오고 있지만 아직 마음이 편치 못 한 것도 사실이다. 단순히 QA 인원을 늘려서 수동 test coverage를 높이는 것에는 큰 의미가 없어 보인다.
특히 이 방면에서는 외계인의 기술로까지 평가되는 불리는 블리자드(Blizzard)의 품질관리 기술은 정말 존경스럽다고 밖에 할 수 없다. 사소한 게임 로직의 문제는 생길지언정 게임이 크래쉬 나는 경우는 한번도 본적이 없을 정도이니. 코딩 스타일의 차이도 있을 것 같은데 이 문제에 대해서는 외부에 그다지 알려진게 없어 여전히 신비할 따름.
이 주제는 내겐 아직 많은 부분이 미지의 영역으로 남겨져 있으니 시간을 두고 더 고민해 봐야지.
# by | 2009/08/20 14:36 | 일(Work) | 트랙백 | 덧글(4)
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
규모와 범용성이라는 측면에선 이쪽이 오히려 괴수(...;;;)
개인적으로 요새는 테스트 방법 문제보다는 결함을 방지할 수 있는 코딩 스타일/아키텍쳐에 관심이 많이 갑니다.
블리자드, NASA 같은 경우는 개인의 능력(코딩 스타일 등) 차원에서 품질을 극대화 시킨게 아닌 통합 프로세스와 집단 지성 등으로 조직의 품질로 승격화 시킨 경우라고 생각됩니다. 예를 들어 HCD를 만들고 조직적으로 프로세스화 시킨 능력이 IDEO가 업계에서 리딩할 수 있는 힘의 원천이겠죠.