[NHN SW 품질관리] 1. 소프트웨어 개발의 특징과 오해 (필사)

1. 소프트웨어 개발은 경험적 프로세스

정의된 프로세스 : 공장의 생산라인과 같이 반복할 수 있는 과정을 의미한다. 미리 정의된 절차가 있으며, 참여자는 절차를 잘 지키고 지시서를 충실하게 이행하여 반복적으로 같은 제품을 생산하는 것이다.

경험적 프로세스 : 비유하자면, 어머니가 음식을 만드는 과정과 유사하다.

음식이 완성될 때까지 양념을 넣고 간을 보고 다시 양념을 넣는 과정을 반복한다. 이렇게 피드백을 자주 받는 방식으로 제품을 생산하는 방식을 경험적 프로세스라고 한다.

※ 요즘 유행하는 Agile방법론은 "SW개발은 일반 제조업에서 사용하는 정의된 프로세스가 아니라, 경험적 프로세스에 더 적합하다고 생각하는 SW개발 방법론이다."

※ 피드백이란? 현재까지 구현된 SW가 사용자의 요구 사항과 일치하는지를 확인하는 과정이다.

개발한 기능이 '사용자 요구 사항과 일치하는 것'은 'specification에 일치하는 것'보다 포괄적인 개념이다. 구현된 기능이 명세서와 일치하더라도 원래 의도와 다르게 구현된 경우가 많기 때문이다. 전통적인 개발 방법론에서는 이런 사실을 SW개발 프로젝트 막바지에 이르러서야 

확인할 수 있다. 

이런 문제를 프로젝트 후반부가 아닌 초기부터 자주 드러내어 문제를 일찍 해결하려는 방법이 반복점진적 개발 방법, 즉 Agile방법론이며 NHN에서 사용하는 방식이다.

2. SW 품질에 대한 정의

일반적으로 SW개발 프로젝트는 "비용", :"시간", "품질"을 3대 관리 요소로 보며 이를 "악마의 삼각형"이라고 한다.

이 삼각형은 3가지 관리요소가 제한된 자원을 나눠 가지며, 서로 제약하는 관계임을 보여준다.

따라서 한 요소를 강조하면 나머지 두 요소를 희생해야한다.

이 삼각형에서, "품질"은 기능이 오류 없이 동작해야함을 의미한다.

=> 시간과 비용을 중시하는 프로젝트라면 구현할 기능 수를 줄여야 한다. 

그러나 구현할 기능 수를 그대로 유지하되 오류 없이 동작해야 한다는 입장이면 품질을 희생할 수 있다고 생각할 수 있다.

3. 오류 없는 SW는 비용이 많이 든다?

품질 비용이란 물품이나 서비스의 품질과 관련하여 발생하는 비용을 의미한다.

비용은 "예방 비용", "평가 비용", "내부 실패 비용", "외부 실패 비용"으로 구성된다.

흔히 오류없이 동작하는 소프트웨어를 만드는 데는 과도한 품질 비용이 소모된다고 생각한다.

하지만 이 예방과 평가에 들어가는 비용은 실패비용에 비하면 아주 적은 비용에 불과하다.

※ ICST 2010에서 발표한 "구글의 개발 단계별 결함 수정에 들어간 비용"을 비교한 자료에서

개발자가 테스트 주도개발 (TDD) 과정에서 결함을 발견함녀 5달러의 비용으로 결함을 수정할 수 있지만 

QA 단계인 시스템 테스트 과정에서 결함을 발견하면, 5000달러의 품질 비용이 소모된다고 발표했다.

이런 관점에서 본다면 SW품질을 높이기 위한 비용은 그 적용 시기가 문제이지 과도한 비용이 문제는 아님을 알 수 있다.

4. 기획서는 불변의 진리?

SW출시가 임박한 상황에서 가장 수용하기 어려운 것은 "초기 요구 사항의 변경"이다.

이것은 사용자에게 사소한 변경에 해당하더라도, 개발자에게는 근본을 흔드는 문제일 수 있기 때문이다.

이때 선택할 수 있는 길은 사용자의 변경 요구를 수용하여 일정을 미루거나. 변경 요구를 거부하는 것이다 ㅋㅋ.

변경 요구를 승인하고 매일 야근하는 방법도 있겠지만... 이는 언급하지 않겠다.

이러한 초기 요구사항의 변경은 왜 일어나는 것일까?

1) SW개발에서 조금의 코드를 수정함으로써 무엇이든 이룰 수 있다는 생각은 옳지 않다.

쉽게 수정이 가능하다는 생각으로 개발 후반부에 많은 요구 사항을 변경하면 프로젝트가 실패할 확률이 높아진다.

2) SW가 눈으로 확인할 수 있는 대상이 아니라는 것에 있다. 

SW개발의 모든 단계에서 가시성이 확보되지는 않으므로, 고객의 요구 사항은 대부분 구현이 어느 정도 완료된 프로젝트 마지막 단계에 이르러서야 확인할 수 있다.

건물 건축에 있어서 준공이 시작되는 단계부터 지속적으로 진행 상황을 눈으로 보고 요구사항과 일치하는지를 확인 할 수 있으나,

SW개발에 있어서는 고객이 진행 상황을 파악하기 위해 프로젝트룸을 방문하더라도 볼 수 있는 것이라곤, 커피잔과 피곤에 찌든 개발자, 그리고 코딩창 뿐이다. SW개발이 최종 UI까지 완료된 후에야 고객은 비로소, 자신이 원하는 프로그램인지 아닌지를 판단할 수 있기 때문이다.

3) 언어의차이

고객이 요구사항을 설명할때, 고객이 설명한 내용을 기획서에 담을 때, 기획서의 내용을 설계문서에 옮길때, 설계한 내용을 코드로 구현할 때, 테스터가 테스트 케이스를 만들 때 쓰는 용어가 모두 다르다.

사용하는 용어가 다르면, 고객의 요구사항이 잘못 전달될 가능성이 크고, 잘못된 요구 사항은 고객에게 프로젝트 산출물을 시연하는 프로젝트 후반부에서야 발견되고, 이는 요구 사항 변경으로 이어지기 때문이다.

이런 문제는 이 장 이후에 나오는 다양한 기술의 방법을 통해 일부 제거할 수는 있지만, 완벽하게 제거할 수는 없다.

4) 비즈니스 환경의 변화

일반적으로 요구사항이 도출되고나서 SW가 완성되기 까지는 일정 시간이 소요된다. 

그 사이 비즈니스환경은 달라질 수 있으며, 예전의 요구사항을 쓸모 없게 되고 새로운 요구 사항이 도출될 수도 있다.

따라서 기획서는 변경이 발생하지 않는 불변의 진리가 될 수 없으며, 그렇게 만들기 위해 노력하는 것도 효과적이지 못하다.

더 효과적인 방법은 프로젝트 참여자들이 기획서는 언제나 변경될 수 있다는 사실을 인정하고 변경 사항에 빠르게 대응할 수 있는 체계를 만드는 것이며, NHN의 QP활동은 요구 사항 변경에 효과적으로 대응하는 방법과 기술을 포함한다.

5. 회의의 중요성

회의시간은 필요하나 모든 참석자에게 훌륭한 도구라고 할 수 없다. 호의 시간 내내 메일만 보고 있는 사람, 자신과 관련된 이슈가 모두 정리 되었음에도 어쩔 수 없이 남아있는 사람, 왜 들어와 있는지 이유도 모르는 사람에게 회의는 낭비이다.

많은 사람이 모이는 회의가 효과적이지 못한 의사소통 방법이란 것을 알면서도 없애지 못하는 이유는 무엇일까?

SW개발은 수집한 고객의 요구사항을 토대로 제품을 개발하여 인도하는 과정이다.

고객의 요구사항은 통상 '요구 사항 정의서'라는 형식으로 기획 단계에서 정리되고, 개발 단계에서 '설계서, 상세 요구 사항' 등으로 변환되며, QA단계에서 '테스트 케이스'로 변환된다. 하지만 기획, 개발 QA단계에서 사용하는 용어는 모두 다르다.

기획, 개발, QA가 모인 회의에서 개발자는 서버, 사용자DB등의 용어를 사용하며 기획자는 서비스, 고객들의 용어를 사용하고 QA는 프론트 서버, 백본 서버등의 용어를 사용하는 등 동일한 내용에 대해 다른 관점으로 용어를 사용한다.

또한 각 단계를 거쳐 정보가 전달되는 과정에서 정보의 전달되는 과정에서 정보의 변경 및 누락이 발생한다.

2009년 NHN의 신입 사원 교육 과정에서 '말 전달하기 게임'을 통해 정보 변경과 누락에 대한 모의 실험을 해본 적이 있다고 한다.

게임은 3명의 지원자 중 1명이 이해하기 쉬운 문장 3줄을 읽고 다른 사람에게 읽은 문장을 전달하여 마지막 사람이 말한 내용과 원문을 비교하는 것이었다.

예상하는 바와 같이 전달된 내용은 핵심뿐만 아니라 기본적인 골격도 바뀌어 있었다고 한다.

문제를 해결하기 위해 전통적인 개발 방법론에서는 '정확한 요구 사항', '공통 용어집', '문서 검토' 를 사용하였으며, 문서를 쉽고 명료하게 작성하라고 강조한다. 또한 회의를 통해 내용을 공유하고 공동의 이해를 추구하라고 권장한다. 

이런 과정을 통해 의사소통이 정확해질 것이라 기대하는 것이다. 그런데, SW개발의 '정확'이라는 개념에는 함정이 있다. 정확함이란 무엇인가?

=> 효과적인 명세 작성 파트에서 설명.

6. 기획자는 기획만, 개발자는 개발만, 테스터는 테스트만?

소프트웨어 개발 프로젝트에는 다양한 역할이 존재. 요구 사항은 제시하고 개발 비용을 제공하는 고객과, 고객 요구사항을 정리하고 고도화 하는 기획자, 이를 제품으로 만들어 내는 개발자 그리고 개발된 제품이 고객의 요구 사항을 만족하는지를 검증하는 QA/테스터가 있다.

'이전 단계 작업 완료 -> 다음 단계 작업 시작' 이라는 workflow 논리라는 SW개발 방법이 지배해왔으므로 역할을 기반으로 한 업무 분배는 논리적으로 이해하기 쉽고 매우 친숙하다. 기획과 설계가 완벽하게 마무리 되어야 개발이 진행될 수 있으며 개발이 완료된 후에야 테스트가 진행될 수 있다고 당연하게 생각한다.

이런 기능적 역할 분담과 순차적 일 흐름은 업무에 몰입할 수 있는 장점이 있지만 각 단계를 넘어가기 위해서는 의사소통 비용이 너무 많이 들고 역할별 이기주의를 만들어낸다. 기획자는 자신의 기획을 개발자들이 잘못 이해했다고 하고, 개발자는 구현할 수도 없는 엉성한 기획서를 주더니 내용도 수시로 변경하여 자원을 낭비한다고 하고, QA/테스터는 개발자들이 너무 많은 오류가 너무 많은 산출물을 주어서 매번 테스트를 새로 수행하게 된다고 개발자는 비난하며, 개발자들은 중요한 오류는 찾아내지 못하면서 사소한 오류에 집착한다며 QA/테스터를 비난한다. 관리자는 일정도 지키지 못하고 문제점을 가시화하지 않았다면서 모든 관련자를 비난하고, 그런 문제점을 효과적으로 관리하지 못했다는 비난을 고객에게 듣게 된다.

많은 SW 프로젝트에서 좋은 기획자, 개발자, QA/테스터를 찾아보기 힘든것은 바로 이런 이유 때문이다. 결국 모두가 상처받는 구조인 것이다. 

이런문제를 해결하기 위해서는 전통적 역할에 대한 인식이 바뀌어야 하며 상호견제가 아닌 협업을 위한 구조가 만들어져야 한다.

SW개발은 고객의 요구 사항을 만족하는 SW를 만드는 것이 목적이므로 기획, 개발, QA/테스터 는 이를 달성할 수 있도록 함께 노력해야한다.

즉, 기획자의 기획 내용이 고객요구 사항과 일치하는지를 고객, 개발자, QA/테스터가 협업하여 검증하고 피드백을 줘야한다.

개발자가 생산한 제품이 기획 요구와 일치하는 지도 고객, 기획, QA/테스터가 함께 검증해야 한다. 또한 QA/테스터가 발견한 오류가 고객에게 어떤 영향을 주는지 고객, 개발자, 기획자가 함께 검증해야 한다. 이런 과정은 일회성 행사로 진행되는 것이 아니라 짧은 주기로 항시 수행되어야 한다.

NHN은 개발 프로세스 전 과정에서 이런 경계를 허물려고 노력하고 있다. 그 방법은 뒤에서 설명..

7. 생산성, 측정하지 못하면 개선하지 못한다?

기술의 발전 속도가 빠르고 진입 장벽이 낮은 SW분야에서 생산성을 향상시키는 일은 매우 중요하다. 많은 SW 개발 조직은 다양한 방식으로 생산성을 측정하고 개선하기 위해 노력하고 있으며, 대표적인 생산성 측정항목은 코드 라인 수와 버그밀도이다.

코드 라인 수 (LOC)로 생산성을 측정하는 방식은 단위 시간에 더 많은 코드를 생산하면 생산성이 높은 것처럼 보이므로 중복 코드를 발생시키고 리팩토링을 기피하게 만드는 부작용을 유발한다. LOC를 생산성과 품질을 측정하는 지표로 신뢰할 수 없는 이유는 케퍼스 존스가 1978년에 자신의 저서인 Assessment and Control of Software Risks에서 밝히고 있다.

높은 LOC가 높은 생산성을 의미한다면 근무 환경을 제공하는 것이 생산성 향상의 지름길이 될 것이다.

폭포수 모델은 각 단계( 요구/분석 -> 설계 -> 구현 -> 테스트 -> 유지 보수 )에서 모든 버그를 최대한 생산하여 제거하는 모델이다.

개발 후반부일 수록 의사소통 비용이 증가하므로 버그 제거비용도 상승한다. 하지만 단순히 버그의 밀도만 관리한다면 설계와 구현 단계에서 100개의 버그를 제거한 프로젝트와 테스트와 유지보수 단계에서 100개의 버그를 제거한 프로젝트의 생산성이 같이보인다는 문제가 생긴다.

생산성 측정의 어려움을 해결하기 위해서 개인이 아닌 팀 단위로 측정 단위를 높이거나 기능점수(Function Point)  등을 이용하는 방법도 시도했다.

하지만 사람의 변동성 요소, 즉 실연의 아픔을 겪은 후, 과음을 한 후 등과 같이 객관적으로 측정할 수 없는 상태들이 추가될 수 있는 요소를 완전히 제거하지 못했다.

도요타의 LEAN방법은 투입한 비용대비 수익으로 생산성을 계산하기도 한다. 아주 이상적인 방법이며 모든 문제를 개발의 문제로만 국한시키지 않고 조직의 각 구성원들이 생산성에 대한 책임을 나누어 가지므로 회사 전체를 하나의 방향으로 단결시켜 나갈 수 있다. 그러나 각 조직의 기여도를 찾아야 할 경우나 부분 최적화에 대한 욕구가 강할 경우, 수익이 장기간에 거쳐 발생하여 현재의 생산성 측정이 어려운 경우, 조직 간 협입이 아닌 경쟁에서 발생하는 경우에는 이 방식도 문제가 된다.

단일 지표의 문제점을 해결하기 위해서 

버그 수,

코드 라인 수,

복잡도,

예상 대비 실 투입 시간

등등 여러 지표를 함께 분석하는 경우에도 지표간의 상관 관계를 설명할 수 있는 공식이 없어서 이를 신뢰할 수 없다.

이 같은 문제는 2003년 마틴 파울러가 "소프트웨어 생산성은 측정 불가능하다" 라고 주장한 기사에 잘 설명되어 있다.

즉, 특정 지표 몇가지를 이용해서 개발 생산성을 측정하고 조율하는 것은 효과적인 방법이 아니며, 목표 수치의 달성이 곧 품질과 생산성의 향상으로 연결되지 않는다는 사실을 유념해야한다.

NHN의 QP도 "테스트 커버리지", "잔존 결함 밀도", "코딩 표준 준수율", "코드 리뷰 수행률", "중복 코드", "코드 복잡도"와 같은 항목을 측정한다.

하지만 NHN에서는 목표 수치의 달성을 절대적 가치로 생각하지 않으며 효과적인 개선 방법을 조직 스스로가 결정하고 발전시켜 나갈 수 있는 부가 정보로 활용하고 있다. 특정 항목의 측정 결과가 나쁠 경우, 해당 부분에 잠재적 문제가 있을 수 있음을 관련자에게 알리는 용도로 사용하며 측정 대상도 조직과 비즈니스 상황에 맞게 지속적으로 조정하고 있다.