QA 빅뱅: QA는 어떻게 탄생하였을까?

* 이 글은 2025년 11월에 Medium에 작성된 내용입니다. 
제 블로그에도 기제하기 위해서 동일한 내용을 가져온것 입니다. 앞으로도 이런 글들은 계속됩니다.

---

 

“QA는 Quality Assurance의 약자로… “ 이제는 거의 구전으로 전해지는 느낌의 QA소개 문장입니다.

QA를 시작하거나 QA란 용어에 관심이 있으신 분들은 익숙하신 문장이실 겁니다. 프로그래밍을 처음 배우시는 분들이 느끼는 “hello world” 처럼요.

저는 이 글에서 QA의 정체성과 성장과정에 대해 이야기해보려고 합니다.

 

QA, 탄생하다

QA라는 직무는 소프트웨어 산업때 처음 생긴 직무는 아닙니다. 근원을 올라가보면 1920년대 초반 제조업에서 시작했다는 추측이 있습니다. 그런데 그 시작은 QA가 아닌 QC (Quality Control)였습니다.

QC의 역할은 제품이 의도한대로 만들어진것이 맞는지 확인하는 직무였습니다. 생산 과정 가장 마지막에서 제품을 검수하는 역할이였죠. 초기에는 이렇게 시작해도 충분했으나 곧 문제가 생기기 시작했습니다. 불량이 많아지기 시작한 것이였죠. 불량이 발생한 후에 문제를 수정하는 것은 비용이 적지 않았을 것입니다. 지금 우리가 Shif Left를 이야기 할 때 개발 후반부로 갈 수록 수정 비용이 커진다는 것을 겪지 않아도 알 수 있었던것은 과거에서 선조들이 먼저 경험해보셨기 때문이겠죠.

그래서 QA라는 개념이 생겨났습니다. 수정 비용을 줄이고 결함률을 낮추기 위해 불량이 발생하지 않도록 전반적인 과정을 관리하는 직무였죠. 사후검증에서 사전예방으로 생산과정의 프로세스가 변경된 것이죠.

1933년 보잉사에서 최초로 자동 운항 장치를 도입한 모델 ‘보잉 247’이라는 비행기가 제작되었습니다. 자동 운항 장치라니 제법 소프트웨어같은 느낌이 듭니다. 그럼 이 때에는 소프트웨어 QA가 있었을까요?

안타깝지만 아닙니다. 이때의 자동 운항 장치는 소프트웨어가 없는 기계적, 전기적 제어장치였습니다. 그래서 소프트웨어 자체가 없었으니 소프트웨어 QA는 자연스럽게 없었을 것입니다. 아직은 QC의 활동이 주가 되었던 시절이였습니다. 그럼 더 거슬러 올라가 보겠습니다.

1946년 미국에서 품질의 중요성을 느낀 사람들이 모여 미국 품질관리학회, 즉 ASQC (American Society for Quality Control) 이라고 하는 조직이 설립됩니다.

이 때 Quality Assurance라는 말이 사용되기 시작한것으로 추측됩니다. 품질관리학회의 회장이였던 조지 에드워즈(George Edwards)가 품질 보증 책임자(director of quality assurance) 라는 직무로 통칭되었기 때문입니다. 하지만 Quality Assurance라는 직무가 통상적으로 생겨난것은 아니것으로 보입니다. 이 때 까지만 해도 아직은 Quality Assurance 라는것을 직무의 한 종류로 생각하지는 않은 것 같습니다. Quality Assurance가 하나의 직무로 인정받기 위해서는 조금 더 시간을 거슬러 올라가야 할 것 같습니다.

---

​

소프트웨어를 논할때 절대 이것을 제외하고는 할 수 없죠. 바로 게임 소프트웨어 입니다.

최초의 게임 소프트웨어에 대해서는 논란이 있습니다만 통상적으로 게임은 1970년대 스페이스 인베이더의 대성공으로 본격적인 대중적 문화로 자리잡기 시작했습니다. 이 때는 아케이드 센터에 방문해서 게임을 해야 했기 때문에 접근성이 좋지는 않았죠. 하지만 1983년 닌텐도의 패미컴이 발매되고 나서 가정용 게임의 시대가 열렸습니다. 이제는 더 높은 접근성으로 많은 사람이 게임 소프트와 만날 수 있게 된 것이죠.

사용자가 많을 수록 제품의 결함과 오류는 더 큰 리스크가 됩니다. 결함이 발생한 뒤에 조치가 아닌 결함의 사전 제거를 위한 목적으로 QA가 생겨났기 때문에 이 리스크를 줄이기 위해서는 QC가 아닌 QA가 필요했을 것입니다. 그럼 이 때의 QA는 어떤 모습이였을까요?

과거에도 그랬고 지금도 게임 소프트업계에서도 하나의 큰 축을 맡고 있는 일본의 게임 소프트웨어 분야를 살펴보겠습니다.

 

---

 

1987년 에닉스의 드래곤퀘스트2 라는 게임이 출시됩니다.

이때의 개발팀 맴버로 나카무라 코이치라는 프로그래머가 있었는데 그 때 당시의 인터뷰 내용을 보면 이런 내용이 나옵니다. “매일 호리이 씨한테서 업데이트된 지시를 받았는데, 그걸 프로그래밍하는 데 온통 시간을 쏟았죠. 최종 버전을 제작에 투입하기 직전까지 디버깅조차 직접 할 수 없었어요.” 이때의 팀 인원은 10명이 채 안되는 수준이였던 것으로 알려져있어 아마 직접 테스트하고 디버깅까지 해야 하는 상황이였을 것입니다. 디버깅 할 시간조차 부족한 인력난이였기 때문에 전담 QA인원은 당연히 없는 시절이 아닐까하는 추측이 됩니다.

실제로 드래곤퀘스트2 엔딩 크레딧에서 테스트와 관련된 그 어떤 이름도 나오지 않습니다.

이후 1988년 일본내 사회적으로 엄청난 파장을 몰고와 학생들이 결석하고 직장인들이 무단으로 이탈하여 게임소프트를 사기위해 수 km 줄을 서며 구입해야 했던 드래곤퀘스트3 에도 엔딩 크래딧에 테스트와 관련된 이름은 나오지 않았습니다.

 

---

 

이후 1992년 스퀘어에서 파이널판타지5가 발매됩니다. 이 게임의 크레딧에는 TEST ASSIST라는 직무명이 나타나기 시작합니다. QA라는 조직이 정식으로 갖춰지고 운영이 되었는지는 명확하지 않지만 이제 사전예방을 위한 테스트 활동을 목적으로하는 인원이 있었다는 뜻이였겠죠.

이 이름도 아마 기존에는 개발자과 디렉터가 테스트를 했었는데 테스트를 할 시간이 부족하니 이를 도와주는 개념으로 이름을 정한것이 아닌가 싶습니다.

그리고 이러한 테스트를 수행하는 인원에 대한 크레딧은 1994년 파이널판타지6에서는 또 다른 이름인 TEST COORDINATOR 라는 이름으로 등장합니다.

이후 1995년 드래곤퀘스트6 게임 크레딧에도 TEST PLAY라는 이름이 나타나기 시작합니다.

이름은 조금씩 다르지만 명확히 확인할 수 있는 것은 게임의 용량이 커지고, 시스템이 복잡해지면서 테스트하는 인원의 수가 증가하고 있다는 점입니다.

1990년대 중반은 이러한 사전 예방에 대한 중요성을 회사에서 자각하기 시작했다는 신호로 봐도 될 것 같습니다.

 

 

---

 

추가로 드래곤퀘스트6 발매년도와 동일한 1995년에 Microsoft에서 발매한 세기의 OS가 세상에 발매되었습니다. 바로 windows95 이죠.

이전 버전인 windows 3.1에 비해 대폭 업그레이드 된 제품이였기 때문에 당대에 엄청난 관심을 받았던 OS였습니다. 그런데 당시 Microsoft에서는 QA가 어떤 모습이였을까요?

이스터 에그로 Credits를 숨겨놨던 내용을 확인해보면 QA가 아닌 Core Testing 이라는 직무로 존재하고 있었다는 것을 알 수 있습니다.

1990년대 중반이 지났는데 아직도 QA는 하나의 직무로 인정받지 못하는 것일까요?

하지만 마침내. 1997년 파이널판타지7에서 시리즈 최초로 QUALITY ASSURANCE라는 이름이 크래딧에 등장합니다.

QA MANAGER, LEAD TESTER, ASST.LEAD TESTER라는 직무도 볼 수 있는데요, 이렇게 테스트와 관련된 직무도 세분화 된것을 볼 수 있습니다.

여담이지만 파이널 판타지 6보다 용량도 크고 시스템도 복잡했을 텐데 파이널 판타지6의 TEST COORDINATOR 인원과 QA인원에 별 차이가 없었던 이유는 ASST. LEAD TESTER의 존재가 아닐까 합니다. 외부업체의 테스터를 관리하는 직책인 것으로 보이는데 아마 외주업체 테스터 인원들은 꽤 많지 않았을까 하네요.

최근 AAA 게임들 크레딧을 보면 QA조직이 수십명인것을 감안했을 때 예상되는 바 입니다.

이렇게 QA는 1990년대 중반, 떳떳하게 직무이름을 내걸며 소프트웨어 산업 전반에 그 영향을 끼치기 시작했을 겁니다.

그리고 30년이 지난 지금까지 QA는 어떤 존재감을 나타내면서 이 길을 걸어가고 있었을까요?

 

TEST, 공식 기술임을 인증하다.

앞서 내용을 살펴보면 1990년 초, 중반에는 테스트를 별도의 기술로 인정하거나 전문가로써 인정을 하지 않는 분위기였습니다. 이것이 세계적인 추세였기 때문이였을까요? QA라는 직무는 필요하지만, 그것은 정의되지 않은 기술을 요하여 진행되는 비전문가가 진행하는 업무 라는 인식이 있었던것 같습니다.

하지만 이것을 지켜보던 영국에서 소프트웨어 테스트에 대한 중요성을 인식하고 1998년 BSB, 즉 영국 소프트웨어 테스팅 위원회를 (British Software Testing Board) 설립하게 됩니다.

이 BCS의 산하 조직으로 자격 인증 및 교육 시험을 담당하는 ISEB (Information Systems Examination Board) 조직이 있었습니다. 이 부서에서 테스터 활동에 대한 인식 강화를 목적으로 1998년에 소프트웨어 테스트용 Foundation Syllabus를 만들었습니다. 그리고 그 해 10월 최초의 Foundation Certificate 수여가 있었습니다. 이것을 시작으로 테스팅 자격화 움직임이 시작되었다고 해석할 수 있을것 같습니다.

이후 다른 국가 기구들도 자국용 테스터 자격 계획을 수립하기위해서 ISEB Syllabus를 기반으로 문서와 내용을 재구성하여 사용했습니다. 그 결과 2002년 유럽내의 8개국이 참여하여 우리모두가 잘 알고 있는 ISTQB (International Software Testing Qualifications Boar)를 공식 출범시킵니다.

국제 공인 테스터 자격증의 시대가 본격적으로 열리게 된 것 입니다.

 

게임의 폭팔적인 출시와 드러난 QA의 필요성

1998년 스타크래프트라는 게임이 출시됩니다. 우리나라에는 PC방 붐이 불며 e스포츠 대회가 진행되어서 게임 흥행에 기름과 불을 같이 부은격이 되었죠. 그리고 2000년대로 넘어가면서 역사적인 게임들이 많이 출시됩니다. 대표적으로 디아블로2와 WoW (World of Warcraft)가 있을 것 같습니다. 물론 블리자드게임만 유명한것은 아니였죠. 이 때 당시 GTA3와 심즈, 몬스터헌터, 바이오하자드4 등 명작들이 많이 나왔던 시대였습니다. 이용자가 많아지고, 게임이 복잡해졌으며 개발기간이 점점 길어지기 시작했습니다.

누군가는 제품 품질의 안정성을 관리해야했을 것입니다. 그래서 QA라는 조직이 점점 필요해졌을 것으로 추측하고 있습니다.

실제로 스타크래프트 크래딧을 보면 QA Manager, Lead Tester, Assistant Lead Tester, QA Analyst, Additional Testing, Localization QA 등 다양한 QA 직무가 있는 것을 알 수 있습니다.

​WoW를 봐도 Quality Assurance Manager, Quality Assurance Assistant Managers, QA Night Supervisor, QA Lead Testers, QA Lead Assistant, QA Technical Engineers, QA Compatibility Testing, QA Team Leads, Game Testers, Additional Game Testing 라는 직무를 확인할 수 있습니다. 게다가 이를 합한 인원 수는 총 100명이 넘습니다. 블리자드에서 사전 결함제거를 통한 리스크 관리에 얼마나 공을 들이고 있는지 알 수 있는 부분이라고 생각합니다.

이렇게 1990년대에서는 소프트웨어의 크기가 작고 복잡도가 크지 않아서 지원 형식의 테스트가 진행되었다면 2000년대에 들어서는 제품의 크기가 1990년대에 비해 수십배는 넘게 커지고 복잡도 또한 증가하여 단순한 테스트 지원으로는 제품의 안정성을 확보하기가 어려워졌을것입니다. 그래서 QA가 하나의 부서로 자리잡고 본격적인 활동을 활발히 하던 시대였을 것입니다.

 

개발 라이프사이클의 전환기, 애자일 방법론 탄생

이렇게 QA팀이 열심히 활동하고 있는 시기였던 2001년 2월 21일, 17명의 소프트웨어 개발자들이 모여 애자일 선언을 발표합니다. 기존까지의 폭포수 모델 개발방식은 그 과정이 경직되어 있어서 변화에 취약하고 어려웠죠. 게다가 출시되기 까지의 기간이 긴 편이였기 때문에 실제 고객의 피드백을 받는것도 쉽지 않았습니다. 그래서 이를 극복하기 위해 변화에 대응하고 고객에게 빠른 피드백을 받아볼 수 있기 위한 새로운 개발 방법론을 제시한 것이였습니다.

폭포수 모델은 QA입장에서 꽤 부담이 큰 개발 방식이였습니다. QA가 개발 라이프사이클의 가장 마지막을 담당하고 있기 때문에 만약 일정에 변경이 생기게 된다면 그 영향은 QA팀이 직격으로 받게 되는 방식이였기 때문이죠.

애자일 방법론은 이러한 분위기를 완전히 반전시키는 방법론이였습니다.

출시 사이클이 짧아지고 주요기능에 집중하기 때문에 QA는 좀더 면밀히 대상을 검증하는 것이 가능해졌습니다. 게다가 모든 개발자가 품질에 대한 책임을 가진다 라는 문화가 기반이 되는것이 애자일 방법론이기 때문에 품질에 대한 모든 팀원의 관심도 높아질 수 있게 되었죠.

1980년대 후반, 개발팀의 주도적인 테스트에서 1990년대에 들어서서 개발팀의 테스트를 지원해주는 방식으로 진행되었고 2000년대에 들어서 전문적으로 제품의 품질을 관리할 수 있는 부서를 두었다면 이제는 모든 인원이 제품의 품질에 관여하고 책임감을 느낄 수 있도록 한것이죠. 과거에는 품질에 대한 오너쉽이 이동하는 방식이였다면 이제는 모든 인원에게 분산되는 방식이 된 것입니다.

애자일의 의도는 좋았고 품질에 대한 오너쉽이 분산된 것도 좋았으나 QA는 한가지 고민이 생기기 시작했을 것입니다. 바로 잦은 배포로 인한 대응 부분이였을 것입니다. 제품이 유저를 위한 기능으로 개발되어 출시되는 것은 좋았으나 자주 배포를 해야 하는것은 다른 문제였죠. 품질에 대한 책임이 분산되었다고는 하지만 QA는 배포되는 제품의 안정성을 확보할 책임이 있었습니다.

수동테스트로는 이것을 계속 대응하는데 문제가 많았습니다. 지나친 반복작업으로 인한 효율성 저하였죠.

그래서 이를 해결하기 위해 브라우저 테스트 자동화의 혁명이 일어나게 됩니다.

 

테스트 자동화, 시동

2004년 제이슨 허긴스(Jason Huggins)는 “JavaScriptTestRunner”라는 이름의 코어 모드를 구축했습니다. 그리고 여러 동료들에게 테스트 도구를 시연하기 시작했고 그것은 추후에 Selenium 이라는 혁명적인 테스트 자동화 도구로 세상에 선보여지게 됩니다.

테스트 자동화 자체가 Selenium으로 시작된건 아니였습니다. 1990년대에 LoadRunner 같은 성능 테스트 자동화 도구들이 이미 존재하였고 WinRunner같은 UI기반 테스트 자동화 도구도 있었으나 Selenium의 등장은 Web UI 테스트 자동화의 표준을 정립한 오픈소스라는 개념으로 본다면 그 존재감이 매우 크다고 할 수 있겠습니다.

그 이후 테스트 자동화를 사용하여 QA는 단순작업을 자동화 할 수 있게 되었습니다. 이로인해 잦은 배포를 대응할 수 있게 되고 QA는 반복작업에서 해방될 수 있게 된 것이죠. 저는 여기서 한가지 중요한점을 짚고 싶습니다. 테스트 자동화를 하면서 QA가 바로 프로그래밍을 접하게 되었다는 것입니다. QA가 이제는 엔지니어로써의 능력도 갖추게 되었다는 것을 뜻하게 된 것이였죠. 개인적인 추측으로는 이 이후부터 QA Engineer, SDET 라는 파생 직무가 생기게 된것이라고 예상합니다.

테스트 자동화는 애자일 방법론 내에서 QA와는 뗄 수 없는 관계가 되기 시작합니다. 그래서 테스트 도구들도 계속적으로 만들어지게 됩니다. 여러분이 아시는 Katalon이나 BrowserStack 같은 것 말이죠.

지금도 계속해서 No Code, Low Code 툴이 출시되고 있고 AI 기능까지 추가된 여러가지 툴들이 계속해서 업데이트 되거나 출시되고 있습니다.

 

앞으로

QC에서 시작하였으나 필요에 의해 QA가 되었고 이제는 스스로 한발 나아가 QA Engineer가 되었습니다. QA는 계속해서 필요성과 효과를 스스로 입증해 낼 것이고 계속해서 성장해 나갈 것이라고 생각합니다.

이제 본격적인 AI시대가 되었습니다. 우리가 프로그래밍을 학습하고 스스로 성장한 것 처럼 AI의 시대에도 그것과 융합되어 더욱더 성장하는 QA의 모습이 되길 기대해봅니다.