최근 게임 업계의 시류에 대한 제 생각을 기술한 포스팅에 많은 분들이 찾아오셔서, 시류에 관심이 있으신 것인지 아니면 게임에 관심이 있으신 것인지는 헷갈리지만, 비슷한 이야기로 제가 종사하는 SQA 분야에 대한 현재 시점의 이야기를 한 번 해볼까 합니다. 이 내용은 최근에 제가 하고 있는 강의의 배경이 되었던 생각 중 일부입니다. 실제로 강의 중에 하는 이야기들도 많이 섞여 있을 듯합니다. 그냥, 오늘 느닷없이, 문득, 그 중 일부를 정리해야 겠다는 생각이 들어서 열심히 정리해 보려합니다. 자, 시작합니다.
<그림 출처 - 소프트웨어 V&V>
1. Quality Assurance
한국에서도 한 15년 전부터 시작된 소프트웨어의 품질을 향상시키기 위한 바램, 그리고 움직임이 있어왔습니다. 그리고 대략 10년전부터 우리나라에서도 Quality Assurance라는 분야가 각광 받기 시작한 것 같습니다. 이 분야는 짧게 줄여서 QA라고 부르지요. 우리는 소프트웨어에서 품질 향상 시키는 접근 방법을 일컫는 말을 의미하기 다른 업계의 그것과 헷갈리지 않기 위해 SQA(Software Quality Assurance)라고 부릅니다.
최근 대학생들 대상으로 강의를 하니, 취업 희망자들 중에 SQA 분야에 관심을 가진 친구들이 좀 있더라구요. 이 분야에 접근하고 싶어하시는 분들을 위해 한국에서 제일 유명한 SQA 분야의 사이트와 카페를 소개해 드리겠습니다.
- STEN : 한국의 SQA 1세대들이 싸이월드에서 활동하던 카페가 독립 사이트로 분리. 현재는 STA라는 컨설팅 회사의 사이트로 운영 중.
- SW Tester : 네이버 카페로 운영되는 중인, SQA 전문 커뮤니티. 필자가 부운영자로 운영하고 있는 곳.
(현재 카페는 네이버라는 서비스에 종속되어 있어, 이거 외에도 제가 하나 더 구축 중입니다. 다만 아이템의 문제가 있어서 보류-연구 중입니다. 확실한 건 커뮤니티 기능은 계속 카페에서 이루어질 예정입니다.)
SQA는 그것이 발전하는 중간 과정에서 '실천적인 방법'을 고증하는데 있어 관리자들과 실무자들 모두가 이해할 수 있는 여러가지 쉬운 예를 들려 노력한 결과, 그 방법의 한계로 현재 Testing 전문 분야로 인식되어 있습니다. 그래서 결국 2013년 현재 한국의 품질 영역을 잘 갖춘 업체나, 그렇지 못한 업체들 모두 SQA를 Testing으로 인식하고 있습니다. (물론 Blackbox 접근이냐 Whitebox 접근이냐에 대한 차이는 업체마다 조금씩 존재하지만요.)
여기에는 여러가지 문제가 되는 배경이 있긴 합니다. 비단 SQA 분야만이 아니고 모든 소프트웨어 공학의 접근 방법이 등장할 때는 두 가지의 가치를 목표로 등장합니다. 「생산성 향상」과 「고객 만족」입니다. 폭포수 접근 방법도 오래전 자료를 찾아보니 고객 만족과 생산성에 대한 이야기가 있더군요. [TQC에서 TQM으로, 한국표준협회, 1993년 발행]
<그림 출처 - 한국 생산성 본부>
어라? 「생산성 향상」, 「고객 만족」, 이런 것들 어디서 많이 듣던 이야기들이지 않나요? 그렇습니다. 애자일 세미나에서 많이 듣던 이야기이죠. 그런데 이 이야기를 전통적인 폭포수 모델, 그 중 가장 강력한 순차적 접근 방법 중 하나인 TQM(Total Quality Management)에서 하네요? 이게 어떻게 된 일일까요?
필자의 생각은 이렇습니다. 모든 소프트웨어 공학적 접근 방법들은 모두 그 당시 사용되던 접근 방법의 한계를 극복하기 위해 「생산성 향상」, 「고객 만족」이라는 두 가지를 기본 목표로 하여 발생하는데, 소프트웨어 자체가 비가시적일 뿐더러 그 소프트웨어 프로젝트라는 것 역시 비정량화되어있다보니, 새롭고 신선한 공학적 접근 방법이 나타나도 사람들은 그에 대한 실증적, 실천적 사례를 원하게 됩니다. 그것이 실제로 옳은지를 판별하기 위해 눈에 보이는 무언가를 갈구하는 것이지요. 그러면 누군가 실증적 사례를 만들어 내고, 다른 누군가는 그 사례에 대한 옳고 그름을 판별하는 활동을 하게 되죠. 이런 일련의 반복 과정을 거치면서 그 공학적 접근 방식은 그 사례들 안에 갖혀 프레임화 됩니다.
그리 멀지 않은 곳에 예가 있습니다. 2013년 소프트웨어 개발 종사자들은 SQA를 순차적 접근 방법이라고 생각하고, 애자일은 반복점진개발이라고 생각합니다. 그런데 과연 그럴까요? 필자는 아니라고 생각합니다. 전혀요. 다만 우리가 그렇게 믿게 된 건, 두 분야의 사례들이 그런 방식으로 구축되어 왔기 때문이라고 믿습니다.
<그림 출처 - 세상을 바라보는 눈>
옛날 이야기를 잠시 해야겠네요. 과거 30년전의 소프트웨어 공학에는 Software Testing이라는 분야는 존재하지 않았습니다. SW Testing 활동은 Programming을 하는 데 필요한 Debugging 단위의 활동에 통합되어 있었고, 전문적인 테스팅 활동은 소프트웨어 공학 지식 체계 내에 존재하지 않았습니다. 그런데 Debugging 활동이 점점 발전하면서 소프트웨어가 올바로 작동하는 지를 볼 필요가 있었고(Demonstration 관점), 그 후 더 발전한 컴퓨팅 기술 속에서 소프트웨어가 문제가 없는 지를 볼 필요(Destruction 관점)가 있었습니다. 이때까지도 Software에서 Testing이라는 개념은 거의 미미했습니다. 이후 소프트웨어를 상용화해서 돈을 벌 수 있다는 사실을 깨닫게 된 자본가들이 안정적인 사업 운영을 위해 소프트웨어의 사업적인 평가를 하기 위한(Evaluation 관점) 모델이 필요하다는 깨달음이 다달았을 즈음에야 비로소 Software Testing이라는 지식 체계가 발생합니다. 이게 1980년 초 즈음입니다. (그리고 Art of Software Testing이라는 책은 1979년에 초판이 발간되었습니다. 시기가 딱 맞죠.) [Software Testing, Wikipedia]
즉, 우리가 SQA라고 부르는 「품질 향상을 위한 Testing 활동의 총체적 집합」은 바로 「안정적인 사업 운영에 대한」 모델을 제시하기 위한 소프트웨어 공학적인 접근 방법이었고, 우리도 그렇게 해석해야 했습니다. 그런데 우리는 지난 10년간, (한국의 예만 봐도) 어떻게 테스트해야 테스트를 잘 할 수 있는가에 대한 연구만을 고집해왔고, 모든 관련 세미나나 교육이 그런 방향으로 흘러 왔습니다. 바로 그곳이 문제인 것입니다.
누구의 잘잘못을 따지자는 것이 아닙니다. 다만 우리에게 오해는 분명히 발생하였고, 현재도 발생하고 있습니다. 그리고 우리는 그 오해 속에서 살고 있습니다. 모두가 어지럽고 혼란해하는 현 상황에서, 누군가에게 책임 전가를 하기 보다는, 현재 시점에서 우리가 안고 있는 소프트웨어 공학에 대한 오류가 어디에서 발생했는지에 대한 root cause analysis를 수행하고 함께 이겨나가기 위한 노력이 필요해 보입니다.
어디에서 SQA에 대한 오해가 발생했는지, (필자가 생각하는 이야기를) 쉽게 한 줄씩 기술해 보겠습니다.
- 애초에 QA는 「현실의 사업」을 위해, 「가상의 제품인 소프트웨어」 개발에 대한 접근 방법
- 사업을 더 잘하기 위해서는 소프트웨어 개발 도중 어떤 것들이 도출되어야 하는가에 대한 연구가 필요하였음
- 정량적인 목표 중 가장 도출하기 쉬운 것은 결함률 (ROI 등에 대한 산정이 쉬우므로)
- 결함률에 대한 통계적, 관리적, 소프트웨어 공학적 접근이 발생
- 여러가지 더 나은 방법들에 대한 연구가 진행
- 그런데 결함이라는 것은 대상이 되는 객체가 존재해야 하므로, 선개발 후검증이라는 순차적인 방식의 사례들이 나타남
- 당시엔 다른 대안이되는 개발방법론이 존재하지 않았으므로 그 상태로 10년~20년 진행
- SQA = Testing = Waterfall approach라는 공식이 발생
Error!!! 입니다.
SQA는 Testing 활동도 아니고 순차적인 폭포수 접근 방법도 전혀~~아닙니다. 단지 그것이 등장할 때에는 소프트웨어 기반 사업을 안정적으로 끌고 나가기 위한 접근 방법이었을 것입니다. 그 중 결함률 도출이 가장 쉬운 사업 관리 방법이었을 뿐, 그것 자체가 SQA라고 말한 사람은 아무도 없습니다. 그런데 점점 우리는 그렇게 믿게 되어갔습니다. SQA는 테스트를 잘해야 하는 거라고 말이죠.
SQA라는 분야가 자리를 잡아 감에 따라, 소프트웨어 공학에서는 좋은 테스팅 접근 방법으로 Prevention, 예방하는 방법을 이야기 하게 됩니다. 결함을 일찍 찾을 수록 결함 수정에 소요되는 비용이 줄어든다는 것이죠. 이 이야기는 하도 많이 들어서 공학도라면 지겨울 수도 있겠습니다. 그래서 패스. (사실 여기에도 좀 오해의 소지가 있긴 한데, 또 한 바닥 글 쓰기도 귀찮고, 읽으시는 분들도 지루해 하실 것 같아서 일단 패스~!)
2. Agile
서기 2000년, 미합중국 유타 지방의 컨퍼런스에서 전 세계 최고의 소프트웨어 공학자, 프로그래머들 19명이 만나 애자일 선언문을 발표하게 됩니다. (번역본은 한글화되어 있는 것이 많으니 각자 찾아보세요.) 이후 소프트웨어 공학의 개발 접근 방법은 많은 부분 패러다임의 변화를 맞게됩니다. [Agile Manifesto]
잠시 다른 이야기를 하자면, 필자는 사실 애자일은 "이것이 옳다"라는 것을 증명하기는 힘든 학문이라고 생각합니다. 왜냐하면 애자일은 "이렇게 생각하면 잘 될거야" 라는 접근론적인 「철학」으로 보이지, "무조건 이렇게 하면 돼" 를 알려주는 「방법론」이 아니거든요. 다른 말로 "착하게 살면 복받을거야"라고 한다고 해서, 그 말을 들은 사람들이 다 착하게 살리는 없거든요. 애자일도 사실은 그렇다고 (필자는) 생각하기 때문에, 그리고 사람의 생각을 증명하는 일은 2013년 인류가 갖지 못한 기술 분야이기 때문에 애자일이 옳다고 증명하는 건 힘들다고 생각합니다. 그냥 "착하게 살자" 하고 사는 것처럼, "애자일하게 살자" 하고 살아야죠. 그러니, 혹시라도 애자일이 실패했다고 판단하실 때 "난 잘못없어. 몽땅 쟤네 잘 못이야" 라고 하지 마세요. 비겁합니다. 애자일이 실패했더라도 회사 내부의 소프트웨어 개발에 필요한 주요 요소들, 그 문화 속에 애자일은 잘 뿌리 내렸을 겁니다. 우리 비굴하게는 살아도 비겁하게는 살지 맙시다.
자, 앞서 필자는 SQA가 Testing 활동과 같지는 아니하다고 이야기 하였습니다. 마찬가지로 애자일이 반복점진개발이 아니라는 이야기를 하고 싶습니다. 필자보다 훨씬 똑똑하고 훌륭하신 애자일 분야 활동가들이 많이 계시지만, 그래도 필자는 그렇게 생각합니다. 기본적으로 이 포스팅에서 찾고 이야기하는 것은 실천적이지도 않은 소프트웨어 개발 방법론들이 가지는 철학 그 본래의 모습을 이야기하는 것이기 때문에, 일단 계속 이야기를 이어 나가겠습니다.
과거 하드웨어에서의 프로젝트는 제품 그 자체입니다. 프로젝트가 곧 제품입니다. 그런데 소프트웨어는 프로젝트(Project)와 제품(Product)이 다른 모습일 수 있습니다. 여기에서 많~~은 문제가 발생합니다. 소프트웨어의 기본적인 특징 중 하나는 하드웨어에 종속적으로 작동하기 때문에 수행하는 업무와 결과로 발생하는 제품이 다를 수 있다는 것입니다. 때로는 메시업(Mesh up)도 발생하고, 때로는 분리되기도 합니다. 소프트웨어의 기본 특징 중 하나가 부드러움(soft, 혹은 non-solid)이기 때문입니다.
<왼쪽 그림 출처 - 자전거 용품구매(1)>
예전에 디스커버리 채널에서 보잉사의 비행기 제작 프로세스에 대한 이야기가 방영된 것을 본 적이 있습니다. 비행기는 자동차처럼 계속 만들고 있는 것이 아니라, 고객이 사겠다고 해서 계약서가 서명된 후 작업에 착수하게 됩니다. 그렇기 때문에 비행기는 각 부품들이 모두 각기 다른 공장에서 동시에 병렬로 제작되고, 한 곳으로 모여 동체에 조립하는 구조로 만들어집니다. 그 과정에서 비행기라는 특수성 때문에 (고장나면 엄청난 인명 피해가 발생하기 때문에) 굉장히 엄격한 증명 과정을 거치게 됩니다. 실제로 보잉사의 비행기 제작 시 하드웨어 오류가 검출되면 몇 달 동안 공정을 멈추고 원인 분석에 들어간다고 합니다. 보잉사에서 일하시는 분들은 나사 박는 분도 공학 박사일텐데 말입니다. 몇 달이고 업무를 중단한다고 합니다.
그런데 이런 과정을 소프트웨어에 적용하면 여러가지 문제가 발생합니다. 일단 유동성 있는 구조인 소프트웨어 개발에 맞지 않는 다는 것이 가장 큰 문제입니다. 소프트웨어 코드는 개발 중간 동안에는 큰 위험을 발생시키지 않습니다. 물론 제품이 출고된 후에는 여러가지 문제를 발생시키지만요. 그렇다보니 제품 개발 중 영향도 높은 무언가가 잘못되었다고 개발을 중단시킨다면 효율적이지도 않고 의미도 없게 됩니다. 그래서 시스템이 어느 정도 완성되고 나서 확인을 하곤 했었지요.
또 20~30여년 전에는 전 세계적으로 2차 세계대전이 끝난 다음 세대들이기 때문에, 그리고 기술의 집적도도 지금처럼 높지 않은 세대였기 때문에, 지식 체계에 대한 분류 수준이 높지 않았기 때문에 이런 순차적 방식의 개발 접근 모델이 모두에게 가장 「안전하고」, 「이해하기 쉬우며」, 「다음 세대로의 지식 이관이 쉬운」 지식 체계였을 것입니다. 그리고 이런 방식으로 발전한 하드웨어의 지식 체계를 기반으로, 그 유명한 폭포수 모델이 소프트웨어 개발에도 도입되게 되었을 것입니다.
그 당시 사람들이 바보 같은게 아니라 사실은 굉장히 당연한 역사적 순리라 보입니다. 당시에는 컴파일러는 둘째치고, 개발 환경 자체가 지금처럼 안정적이지 않았으니까요. 문제가 발생하면 어디에서 발생했는 지 원인을 찾고, 해결하는데는 순차적 모델이 최고일 테니까요. 당시 그들에게는 그것이 최상의 선택이었을 겁니다. 그 방법이 당시 우리네 선배들에게는 「생산성 향상」을 위한 방법이고 「고객 만족」을 향한 방향이었을 것입니다.
<그림 - 매킨토시>
3. SWEBOK 이야기 아주 조금 (그리고 SQA와 Agile)
일반적으로 소프트웨어 공학의 지식 체계에 대한 이야기를 할 때에 Software Engineering Body of Knowledge에 대한 이야기를 많이 합니다. 물론 SWEBOK이 실제 소프트웨어 개발에 도움을 주지 못한다는 의견 때문에, 문서의 내용에 대한 찬반은 있습니다만 소프트웨어가 어떻게 생겼고 어떤 방식으로 구동되는 지, 어떤 방식으로 관리되는 지를 알려면 반드시 살펴보아야 하는 지식 체계라고 생각합니다. 이 SWEBOK에도 향후 애자일 방식의 반복적인 접근 방법과 사례들이 소개되겠습니다만, 여태까지는 폭포수 접근 방법으로 구성되어 있었습니다. [Software Engineering Body of Knowledge, IEEE]
다시 애자일로 돌아가서, 서기 2000년, 유타에서 그 전문가들이 느꼈던 소프트웨어 개발 접근 방법의 문제점은 아마도 「빠른 개발(Rapid Developement)」을 추구하던 당시의 유행과 (하드웨어 방식을 옮긴) 전통적 개발 접근 방법이 맞지 않는다고 느꼈던 부분, 두 가지 정도에서 온것이라 추측합니다.
만약에 누군가 애자일의 가치를 필자에게 한 마디로 표현하라고 한다면, 필자는 「User Involvement」라고 말 할 것입니다. 정확하게는 「Early Involvement」를 이야기할 것입니다. 왜냐하면 소프트웨어의 특징 중 하나인 비가시성에서 발생하는 요구사항 만족의 문제점들을 해결하기 위한 접근이라고 보는 것이 애자일을 표현하는데에 가장 맞는 것 같기 때문입니다. 사용자에게 다양한 선택이 주어지면 적어도 그들의 요구사항은 조금 더 가시적인 형태로 변할테니까요.
앞서 언급한 것처럼, 소프트웨어에서는 제품과 프로젝트가 같지 않기 때문에, 개발 중간에 하드웨어에서처럼 공정 중단의 이유가 크지 않은 상태에서 가시성을 빠르게 확보할 수 있는 방안은 무엇일까요? 앞서 SQA에서도 그랬지만, 소프트웨어 개발 시 발생하는 정량적 데이터 중 가장 가시적인 데이터는 결함입니다. SQA에서도 V&V(Validation & Verification)를 이용하여 코드 단위의 결함 해결 방안이 존재하였지만, 애자일에서는 조금 더 효율적으로, 그리고 집중적으로 결함 해결의 위치를 코드레벨로 가져가려는 것이겠지요. (이 분야는 저보다 전문가들이 많으므로 후략~!)
즉, 예전엔 어느 정도 가시성이 확보된 제품을 가지고 결함률을 체크했다면, 이제 만드는 공정 내에서 결함들을 제거하는 「예방」과 「빠름」을 접합한 접근 방법이 필요한 시기가 도래했기 때문에 애자일의 시대가 등장했다고 보입니다.
너무 먼길을 돌아왔네요. 결국 필자가 하고자 하는 말은 "반복을 위해 애자일이 존재하는 것이 아니라, 애자일의 기본 가치인 「Early Involvement」를 달성하기 위한 접근 방법 중 제일 나은 방향이 현재까지는 반복점진개발인 것 뿐"이라는 겁니다. 애자일을 반복이라는 틀 안에 묶어 두어선 안됩니다. SQA에 대한 오해를 줄여보기 위해 노력하고 있는 저처럼, 몇 년 뒤에는 애자일을 반복이라는 틀 안에서 해방시키고자 하는 노력들이 나타날 지 모르니까요. 우리가 집중해야할 중요한 사안은 사용자의 요구사항을 빠르게 볼 수 있는 가능한 모든 접근 방법이 되어야죠. 굳이 반복 모델이 아닌, 순차적 모델에서 그 방법을 찾는다고 할 지라도 말이죠.
<그림 - 영원히 반복되는, 그러나 순차적인 프랙탈 구조>
4. Software Assurance
필자는 이번에 (회사 다니다가 조금 더 배워야 겠다고 생각해서 들어온) 대학원을 졸업합니다. 어느날 지도 교수님께서 식사 중에 관심을 가져보라시면서 이런 이야기를 저에게 들려주셨습니다. 굉장히 길고 재미있는 이야기였습니다만, 교수님이 키노트 발표자로 초청 받으시면 발표하시는 강연 내용이어서 자세히는 적지 않겠습니다.
마이크로소프트사가 10년 전에 Trustworthy Computing이라는 것을 시작했고, 현재는 MS-SDL(Microsoft Security Development Lifecycle)이라는 이름으로 알려져 있습니다. 이 역시 지난 10년간 소프트웨어 개발의 많은 영역에 영향을 끼쳤습니다. 그리고 최근에는 미국 국방성 프로젝트로 Software Assurance라는 단어가 튀어 나왔습니다. Software Assurance는 현재 SwA라고 표기합니다. 위키피디아에서 SwA를 찾아보셨다면, Software Assurance는 우리가 보기에는 「보안」과 관련된 것으로 보일 수도 있습니다. [Software Assurance, Wikipedia] 그래서 Official Site도 링크해 둡니다. [Software Assurance] 그리고 OWASP라는 그룹에서는 SAMM(Software Assurance Maturity Model) 관련한 자료들이 포스팅되어 있습니다. [OWASP SAMM]
SwA는 정확히 보안에 관련된 지식 체계는 아닙니다. (현재까지 필자가 파악한 바로는) 오히려 10년전 SQA가 하던 일들처럼, 그리고 지난 10년간 애자일 분야에서 집중해 온 일들처럼 「코드 레벨의 품질을 향상시키기 위한 가능한 모든 활동」으로 보입니다. 다만, 그 가치 기반이 「프로젝트 성공」보다는 「안정성」쪽에 가치가 매겨진 듯합니다.
SwA 공식 홈페이지에 가 보면 2013년 현재로는 요구사항 해석론, 테스팅론, 아키텍쳐 설계론 등 다양한 분야로 접근하고 있습니다. 그리고 이 방법 중 하나로 우리가 잘 알고 있는 「Secure Coding」이 있습니다. 최근 필자도 Secure Coding 관련해서 일단 국내 발표 자료들부터 찾아 열공하고 있습니다. 언젠가 초보 수준의 포스팅 정도는 해 볼 예정입니다.
여기에서 우리가 주목할 점은 소프트웨어의 「보안」이라는 패러다임이 「깨고(Hacking) 지키기(Defending)」로부터 「안정성(Secure)」으로 변화했다는 점이라고 생각합니다. 기존의 깨고 지키기 관점에서는 보안은 뚫지 못하게 하는 무엇인가였다면, 안정성 관점에서는 소프트웨어 자체를 하나의 안전함이 필요한 무엇인가로 보고, 악의적인 의도를 가진 사용자로 인해 선량한 다수의 사용자가 사용하는 정보가 오용되거나 잘못 이용되지 않도록 하는 관점까지를 포함하고 있는 듯 합니다. 즉, 요구사항 단계에서부터 불필요하거나, 위험할 수 있는 요소들을 제거하는 것이지요. 과거의 관점이 일단 모든걸 만들어 놓고 어떻게든 지키는 것이었다면요.
또, 필자는 SW품질전문가인데, SwA에 집중하는 이유는 이렇습니다. SW보안과 SW품질은 이전부터도 동전의 양면같이 붙어 있었지만 또 전혀 다른 분야였습니다. 그래서 SW품질전문가는 SW보안에 대해 알아야만하는데, 쉽지 않았습니다. 그런데 이제 SwA로 패러다임이 변화하면서 지금 SW품질 전문가들인 우리에게 거의 최초로 보안과 품질을 하나의 선상에서 해석할 수 있는 기반이 펼쳐졌다고 보입니다. Secure Coding과 Software Assurance는 앞으로 PM(Project Management)이라는 지식체계처럼 SW품질에 대한 기술적 접근 방법의 영역으로 구축 될 것 같습니다. (물론 한 5년~10년 뒤에...)
<그림 - 세계 최고의 해킹 그룹 중 하나인 어노니모스의 로고>
5. 마무리
이렇게까지 길게 쓰려고 시작한 포스팅이 아니었는데, 많이 길어졌네요. 마지막으로 광고나 한 번 해볼랍니다.
2013년, 애자일의 대유행이 휩쓸고 지나간 한국의 소프트웨어 업계. 지금 이곳에서 소프트웨어의 품질은 블랙박스 테스팅을 조금 지나쳐 코딩 품질을 높이기 위한 방법인 동료검토(Peer Review), 클린코드(Clean Code) 관점까지 도달해 있습니다. 그렇다면 그 부분이 만족되면 그 다음은 어디로 가게 될까요? 그에 대한 이야기를 하는 것이 최근에 제가 하고 있는 강의의 핵심입니다. 바쁘신 분들이 굳이 저를 찾아오실 필요는 없으니, 결론만 이야기하면 "QA나 제대로 해라, 테스팅만 하고 있지 말고." 입니다. 세상 모든 소프트웨어 품질의 문제는 소프트웨어 테스팅에 대한 오해에서 시작되기 때문입니다.
한국의 소프트웨어, 더 나아질 수 있습니다. 세계 최고가 될 수 있습니다. 충분히요. 저는 믿습니다.
