QA의 시작과 현재

“왜 개발자는 주목받고, QA Engineer는 그렇지 않을까?”

소프트웨어가 세상을 바꾸면서 우리는 점점 더 정교하고 복잡한 시스템을 개발하고 있다. 하지만 아무리 뛰어난 소프트웨어라도, 오류 하나로 인해 사용자 경험이 망가지는 것은 순식간이다. 그렇다면, 우리는 소프트웨어를 만들면서 “문제가 발생하지 않도록 하는 과정”에 얼마나 집중하고 있을까?

이 역할을 담당하는 사람이 바로 QA Engineer다. 오늘날 QA Engineer는 단순히 버그를 찾는 것이 아니라, 소프트웨어의 신뢰성과 안정성을 책임지는 전문가로 자리 잡았다. 하지만 현실은 다르다.

소프트웨어 개발자는 새로운 기능을 만들면서 제품의 ‘가치’를 창출하는 직군으로 주목받는다. 반면, QA는 제품이 안정적으로 동작하도록 돕는 역할을 수행하지만, 종종 ‘지원 역할’로 평가된다.

개발과 QA의 차이는 단순히 업무가 다르기 때문일까,
아니면 더 깊은 이유가 있을까?

이 질문에 대한 답을 찾기 위해, 먼저 QA Engineer는 어디에서 시작되었으며, 한국에서는 어떤 흐름을 거쳐왔는지 살펴보자.

1. 소프트웨어 테스팅과 QA의 탄생

소프트웨어 개발 초기에는 ‘테스팅’이라는 개념 자체가 존재하지 않았다. 당시의 프로그래머들은 새로운 코드를 작성하면, 그것을 실행해보며 직접 오류를 찾아 수정하는 방식을 사용했다. 하지만 이 방식에는 한 가지 큰 문제가 있었다.

개발자가 직접 오류를 수정하면, 객관적인 검증이 어렵다는 점이다.

이 과정에서 개발자는 자신이 작성한 코드가 정상적으로 동작한다고 가정하는 경향이 강했다. 이로 인해, 실제 시스템이 배포된 후에야 심각한 버그가 발견되는 사례가 많아졌다.

초기 테스팅의 등장 (1940~1960년대)

이러한 문제를 해결하기 위해, 개발과 테스팅을 구분하는 개념이 서서히 등장하기 시작했다.

• 1940년대: 세계 최초의 전자식 컴퓨터 ENIAC 개발

→ ENIAC은 오류 발생이 잦았고, 프로그래머들이 코드를 다시 수정해야 하는 일이 빈번했다. 이 과정에서 오류를 찾고 수정하는 일이 하나의 독립된 과정으로 인식되기 시작했다.

에니악 (ENIAC)

• 1947년: 코볼의 어머니라 불리던 프로그래머였던 그레이스 호퍼(Grace Hopper)가 컴퓨터 회로에서 벌레(Bug)를 발견하면서, ‘버그(Bug)’라는 용어가 공식적으로 사용되기 시작했다.

→ “버그를 찾는 과정”이 자연스럽게 프로그래머의 중요한 업무가 되었다.

그레이스 호퍼 (Grace Hopper)

• 1950년대: IBM과 같은 기업이 메인프레임 컴퓨터를 개발하면서, 개발과 테스팅이 구분되기 시작했다.

→ 대규모 시스템이 개발됨에 따라, 프로그램을 실행하기 전에 오류를 미리 점검해야 한다는 개념이 등장했다.

→ 하지만 여전히 이 과정은 체계적으로 관리되지 않았고, 개발자가 직접 테스트를 수행하는 방식이었다.

세계 최초의 메인프레임 서버인 'IBM 시스템 360'

✅ 이 시기의 QA와 개발의 관계

• 테스팅이라는 개념이 등장했지만, 여전히 개발자의 업무 일부로 간주됨.

• 오류가 발생하면 개발자가 직접 수정하는 형태였고, 별도의 테스터(Tester) 직군은 존재하지 않음.

• 소프트웨어가 점점 복잡해지면서, 개발과 검증을 분리해야 한다는 필요성이 증가

소프트웨어 위기와 QA의 필요성 (1960~1980년대)

1960년대부터 대형 소프트웨어 프로젝트가 늘어나면서, 개발 방식에 근본적인 문제가 있다는 점이 부각되기 시작했다.

당시에는 개발자가 직접 코드를 작성하고, 직접 테스트를 진행하는 방식이 일반적이었다. 하지만 이러한 방식에는 심각한 문제점이 있었다.

• 소프트웨어 규모 증가: 시스템이 복잡해지면서, 개발자가 모든 오류를 직접 찾아 수정하는 것이 불가능해짐.

• 개발 일정 지연: 테스트가 개발자에게 부가적인 업무로 여겨지면서, 충분한 검증 없이 배포되는 사례가 늘어남.

• 실패한 프로젝트 증가: 테스트가 제대로 이루어지지 않으면서, 배포 이후 치명적인 버그가 발견되는 일이 많아짐.

1968년 NATO 소프트웨어 공학 컨퍼런스

이러한 문제들이 누적되면서, 1968년 NATO 소프트웨어 공학 컨퍼런스에서 ‘소프트웨어 위기(Software Crisis)’라는 개념이 공식적으로 등장했다.

• 소프트웨어 개발이 점점 복잡해지면서, 기존 방식(개발자가 직접 테스트하는 방식)으로는 대형 프로젝트를 성공적으로 수행하기 어렵다는 점이 지적되었다.

• 프로젝트 실패율이 급증하자, 소프트웨어 품질을 보장하기 위한 독립적인 프로세스가 필요하다는 목소리가 커지기 시작했다.

• 이 회의를 기점으로, 개발과 테스팅을 분리하는 것이 필수적이라는 인식이 확산되었다.

소프트웨어 위기의 대표적인 사례

→ 이때부터 품질 보증(Quality Assurance, QA) 개념이 등장하면서, 개발과 QA가 점차 분리되기 시작했다.

QA의 등장과 개발과의 역할 분리

NATO 컨퍼런스를 계기로, 많은 기업들이 품질 관리를 체계적으로 수행하기 위한 방법을 고민하기 시작했다.

• 1970년대: 미국 국방부와 NASA 같은 기관에서는 개발과 검증을 분리하는 프로세스를 도입

• QA(Quality Assurance) 개념 등장

→ 소프트웨어가 개발될 때, 개발자가 아닌 독립적인 품질 보증 팀이 검증을 담당하는 방식이 정착됨

• 1979년: 최초의 소프트웨어 테스팅 교과서인 “The Art of Software Testing”이 출판됨.

→ 소프트웨어 테스팅이 단순한 기능 검증이 아니라, 체계적인 품질 보증 과정으로 발전해야 한다는 개념이 정립됨.

The Art of Software Testing

✅ 개발과 QA의 역할 차이가 생긴 이유

이 시기부터 개발과 QA의 역할이 본격적으로 분리되었다.

• 개발(Development): 새로운 기능을 만들고, 비즈니스 로직을 구현하는 역할

• QA(Quality Assurance): 개발된 기능이 제대로 동작하는지 검증하는 역할

이 과정에서 QA는 소프트웨어의 품질을 보장하는 중요한 역할을 하게 되었지만, 동시에 “보조적인 역할” 로 인식되기 시작했다.

⚠️ QA가 개발보다 낮은 평가를 받기 시작한 이유

1. QA는 개발이 끝난 후 개입하는 역할로 자리 잡음.

• 기존의 개발 방식에서는 QA가 개발 이후에 제품을 검증하는 단계에서만 작동했기 때문에, 상대적으로 덜 중요하다고 여겨졌다.

2. QA는 ‘문제가 없음을 확인하는 역할’로 간주됨.

• 개발자는 새로운 기능을 만들고 가시적인 성과를 내지만, QA는 오류가 발생하지 않도록 하는 역할을 수행하기 때문에 성과를 측정하기 어려웠다.

3. QA의 업무가 비용으로 인식됨.

• QA를 강화하면 품질이 향상되지만, QA 인력을 늘리는 것은 기업 입장에서 추가적인 비용으로 여겨졌다.

이러한 이유로 QA는 소프트웨어 품질을 좌우하는 중요한 역할을 맡고 있음에도 불구하고, 개발에 비해 상대적으로 덜 주목받고, 낮은 연봉을 받는 경우가 많아졌다.

→ 이 문제를 해결하기 위해, 이후 QA는 테스트 자동화, DevOps, QAOps 등과 결합하며 변화해 나가게 된다.

2. 한국에서의 QA와 테스팅 역사

초기 소프트웨어 개발과 테스팅 (1980~1990년대)

한국에서 소프트웨어 개발이 본격적으로 시작된 것은 1980년대 후반부터다.

당시 국내 IT 산업은 정부 기관과 대기업을 중심으로 발전하였으며, 주로 금융권, 공공기관, 대기업의 내부 전산 시스템 구축이 핵심이었다.

1980년대 후반: IT 산업의 태동과 테스팅 개념 도입

• 1980년대 후반부터 한국에서도 전산 시스템이 본격적으로 도입되면서, 소프트웨어 품질 관리의 필요성이 증가

• 하지만 이 시기에는 ‘QA’라는 개념이 거의 없었으며, 개발자가 직접 오류를 수정하는 형태가 일반적이었다.

• 정부 및 대기업의 전산실에서 메인프레임 컴퓨터를 이용한 데이터 처리 시스템이 운영되었으며, 프로그램이 정상적으로 실행되는지 확인하는 수준의 수동 테스트가 전부였다.

1990년대: 대형 IT 프로젝트와 품질 보증의 필요성 대두

1990년대 들어 한국의 IT 산업이 급격히 성장하면서, 대형 소프트웨어 프로젝트가 증가했다.

• 전자정부 시스템 구축(1990년대 중반)

→ 정부가 공공기관 전산화 프로젝트를 추진하면서, 대규모 소프트웨어 개발이 진행됨.

→ 대표적인 예: 주민등록 전산화, 전자세금계산서 시스템 구축 등

→ 하지만 당시에는 여전히 QA 개념이 없었으며, 개발 완료 후 기능이 정상적으로 동작하는지 확인하는 수준에 불과했다.

• 금융권 IT 시스템 도입

→ 은행 및 증권사의 IT 시스템이 발전하면서, 거래의 정확성과 보안성이 중요한 이슈로 떠오름.

→ 금융 데이터의 무결성을 검증하기 위해, 테스팅의 필요성이 커지기 시작했지만, 여전히 개발자가 직접 검증하는 방식이 일반적이었다.

✅ 이 시기의 QA와 개발의 관계

• 테스팅은 여전히 개발자의 업무 일부로 간주됨.

• 소프트웨어 프로젝트가 커지면서 품질 문제도 커졌지만, 이를 체계적으로 해결할 QA 개념이 부재

• 대형 프로젝트에서 문제 발생 → 사후 대응 방식으로 해결하는 구조

이러한 문제들은 2000년대 이후 QA 개념이 도입되는 계기가 되었다.

게임 산업과 QA의 발전 (2000~2010년대)

2000년대에 들어서면서, 한국의 IT 산업은 웹 서비스와 온라인 게임 시장을 중심으로 폭발적으로 성장했다. 이 시기에 QA라는 직군이 공식적으로 등장하게 된다.

2000년대 초반: 온라인 서비스와 게임 QA의 부상

• 넥슨, 엔씨소프트, 한게임 등 온라인 게임 시장이 급격히 성장하면서, 게임 내 버그와 성능 문제가 핵심 이슈로 부상

• 게임은 실시간으로 운영되며, 사용자가 직접 오류를 경험하게 되므로 QA의 중요성이 부각됨.

• 특히, 게임 패치 및 업데이트가 주기적으로 이루어지면서 QA의 역할이 확장됨.

→ 이 과정에서 ‘게임 테스터(Game Tester)’라는 직군이 등장하였으며, 테스팅을 전문적으로 수행하는 인력이 필요하다는 인식이 확산되었다.

2000년대 후반: 대기업 IT 서비스 회사에서 QA Engineer 직군 등장

• 삼성SDS, LG CNS, SK C&C 등 대기업 IT 서비스 회사에서 QA 조직을 운영하기 시작

• 이 시기부터 ‘QA Engineer’라는 직군이 등장하며, 테스팅이 독립된 업무로 자리 잡기 시작함.

• 하지만 QA는 여전히 개발 이후의 검증 단계에서만 작동하며, 테스팅 자동화나 품질 전략 수립은 거의 이루어지지 않음.

✅ 이 시기의 QA와 개발의 차이

• QA라는 개념이 공식적으로 자리 잡았지만, 여전히 ‘개발 이후’ 단계에서만 개입하는 구조

• 개발자는 새로운 기능을 만드는 역할, QA는 문제가 없는지 확인하는 역할로 구분됨.

• QA의 중요성이 증가했지만, 여전히 ‘보조적인 역할’로 인식됨.

모바일과 자동화 테스팅의 확산 (2010년대~현재)

2010년대 이후 스마트폰이 대중화되면서, 모바일 QA가 중요한 역할로 떠올랐다.

2010년대 초반: 모바일 QA의 등장

• 아이폰, 안드로이드 스마트폰 보급 확대 → 모바일 앱 테스팅이 주요 업무로 부상

• 크로스 브라우징 테스트(다양한 디바이스 및 OS에서의 테스트) 필요성이 커짐.

• 이 시기부터 QA가 단순한 기능 검증을 넘어, 사용자 경험(UX)까지 고려하는 방향으로 발전

2010년대 후반: 자동화 테스팅의 확산

• Selenium, Appium, JUnit 등 오픈소스 테스트 자동화 도구가 널리 보급되면서 QA의 업무가 점점 자동화됨.

• DevOps와 CI/CD(Continuous Integration / Continuous Deployment)가 확산되면서, QA가 개발 과정에 좀 더 일찍 개입하는 방식이 등장함.

• 하지만 여전히 많은 기업에서는 QA를 비용으로 인식하며, 전략적인 QA 조직을 구축하지 않는 경우가 많았음.

AI와 QAOps 시대 (2020년대~현재)

2020년대: AI 기반 QA 및 QAOps 확산

최근 QA의 역할은 더욱 정교해지고 있으며, AI 기반 자동화 및 QAOps(QA + DevOps) 개념이 확산되고 있다.

• AI 기반 테스팅(Applitools, Test.ai 등)이 도입되면서, 테스트 자동화가 더욱 지능화됨.

• AI가 UI 변경을 자동으로 감지하고, 자동으로 테스트 스크립트를 생성하는 등 QA의 업무 효율성이 향상됨.

• DevOps 환경에서 QA가 개발과 운영을 통합하는 역할을 수행하는 QAOps 개념이 확산됨.

✅ 현재 QA의 역할 변화

• 단순한 기능 검증을 넘어, 자동화, 성능 테스트, 보안 테스트까지 수행하는 역할로 확대

• 개발 초기 단계부터 QA가 개입하는 Shift-Left Testing이 점점 보편화됨.

• 하지만 여전히 많은 기업에서는 QA를 비용으로 간주하며, 개발만큼 중요하게 인식하지 않는 경우가 많음.

3. QA의 현재와 미래: 왜 여전히 주목을 덜 받을까?

소프트웨어 산업이 발전하면서 QA의 역할도 크게 변화했다. 과거에는 개발 이후 오류를 발견하는 것이 주된 업무였지만, 현재 QA는 자동화, 성능 테스트, 보안 테스트, DevOps 및 AI 기반 품질 관리까지 포함하는 넓은 개념으로 확장되었다.

그럼에도 불구하고 QA는 여전히 개발과 비교했을 때 상대적으로 낮은 평가를 받는다. 이 문제는 단순히 QA의 중요성이 부족해서가 아니라, 산업 구조, 기업 문화, 기술적 오해, 역할 정의의 불명확성 등 여러 복합적인 요인이 얽혀 있기 때문이다.

QA는 왜 여전히 개발보다 낮은 평가를 받을까?

1. QA는 ‘제품을 만드는 직군’이 아니라 ‘검증하는 직군’으로 인식됨

QA의 가장 큰 역할은 소프트웨어의 품질을 보장하는 것이다.

하지만 이 역할이 종종 “개발자가 만든 것을 검증하는 과정”으로만 인식되는 경우가 많다.

• 개발자는 새로운 기능을 설계하고, 이를 코드로 구현하며 가시적인 성과를 만든다.

• 반면 QA는 기능을 검증하고 결함을 예방하는 역할을 하지만, 이러한 기여는 눈에 잘 보이지 않는다.

결과적으로 QA는 제품의 성공에 핵심적인 역할을 하지만, 새로운 기능을 추가하는 개발자보다 상대적으로 덜 주목받는다.

✅ 현재 시대의 변화

• AI QA, 테스트 자동화, 품질 전략 수립 등의 기술적 역할이 점점 중요해지고 있다.

• 하지만 여전히 QA는 단순한 ‘테스터’로 인식되는 경우가 많으며, 제품 품질을 전략적으로 설계하는 직군이라는 인식이 부족하다.

2. QA의 성과가 눈에 보이지 않음

QA의 성과는 “문제가 발생하지 않는 것”으로 평가되는 경우가 많다.

즉, QA가 잘할수록 티가 나지 않는 직군이라는 문제가 있다.

• 개발자는 코드 한 줄 추가만 해도 제품 기능이 확장되고, 이는 곧바로 사용자 경험과 매출 증가로 이어질 수 있다.

• 반면, QA는 버그를 사전에 차단하고, 제품의 안정성을 유지하는 역할을 하지만, 이것이 직접적인 성과로 측정되지 않는 경우가 많다.

✅ 현재 시대의 변화

• QA의 기여도를 수치화하는 방법이 점점 발전하고 있다.

• 테스트 커버리지, 발견된 결함율, 배포 안정성 지표 등을 활용해 QA의 가치를 증명할 수 있는 방식이 필요하다.

3. 기술적인 난이도에 대한 오해

많은 기업에서는 QA를 비개발 직군으로 분류하며, 기술적인 난이도가 낮다고 오해하는 경우가 있다.

• 수동 테스팅에 대한 편견

→ 과거에는 QA가 주로 수동 테스트를 수행했기 때문에, 상대적으로 기술적 도전이 낮은 직군으로 인식되었다.

• 자동화 테스팅과 AI QA에 대한 저평가

→ 현재 QA는 Selenium, Appium 등의 자동화 도구뿐만 아니라, 성능 테스트(JMeter, Locust), AI 기반 QA까지 다양한 기술을 활용하고 있다.

→ 하지만 일부 기업에서는 여전히 “QA는 스크립트 작성 정도의 기술 수준”으로만 인식하는 경향이 있다.

✅ 현재 시대의 변화

• SDET(Software Development Engineer in Test) 개념이 확산되면서, QA는 이제 개발 지식을 필요로 하는 엔지니어 직군으로 자리 잡아야 한다.

• QA가 단순한 테스팅 직군이 아니라, 테스트 자동화, 품질 전략, AI 활용 등 기술적 역량이 필요한 직군이라는 인식을 확산할 필요가 있다.

4. QA의 역할이 명확하게 정의되지 않음

QA의 역할이 회사마다 다르기 때문에, QA의 위상이 기업마다 차이가 크다.

일부 기업에서는 QA가 품질 전략을 설계하고, 제품의 안정성을 총괄하는 핵심 엔지니어 역할을 수행하는 반면,

다른 기업에서는 QA가 단순한 테스트 실행자로만 운영되는 경우도 있다.

• 스타트업 및 중소기업

→ QA 조직이 없는 경우가 많으며, 개발자가 직접 테스트를 수행하는 경우가 흔하다.

→ QA가 존재하더라도, 단순한 기능 검증에만 초점이 맞춰져 있는 경우가 많다.

• 대기업 및 IT 서비스 기업

→ QA 팀이 존재하지만, 기업마다 역할이 다르게 정의됨.

→ 어떤 기업에서는 QA가 품질 관리 및 자동화까지 수행하지만,

→ 다른 기업에서는 QA가 개발자가 만든 테스트 스크립트를 실행하는 역할에 머물러 있음.

✅ 현재 시대의 변화

• QA의 역할을 명확히 정리하고, 기업 내 QA 조직이 어떤 역할을 수행해야 하는지 가이드라인을 확립할 필요가 있다.

• QA를 단순한 결함 검증에서 품질 전략 수립까지 포함하는 역할로 확대해야 한다.

QA가 더 주목받고 성장하기 위한 방향

QA가 개발과 동등한 직군으로 자리 잡기 위해서는, 단순한 ‘테스트 실행자’가 아니라 소프트웨어 품질을 책임지는 전문가로서의 역할을 더욱 강조해야 한다.

1. QA의 기술적 역량을 강화

• QA는 더 이상 단순한 수동 테스팅이 아니다.

• 테스트 자동화, 성능 테스트, 보안 테스트, AI 기반 QA 등 전문적인 기술을 강화해야 한다.

• SDET(Software Development Engineer in Test)와 같은 기술 중심의 QA 개념이 확산될 필요가 있다.

2. QA의 가치를 수치화

• 개발 성과는 코드와 기능 추가로 쉽게 평가되지만, QA는 그 기여도를 측정하기 어렵다.

• 테스트 커버리지, 발견된 결함율, 배포 안정성 향상 등의 지표를 통해 QA의 가치를 데이터화해야 한다.

3. QA 커뮤니티 활성화

• 개발자 커뮤니티처럼 QA도 적극적인 정보 공유와 네트워킹이 필요하다.

• QA 컨퍼런스, 밋업, 기술 블로그 등을 통해 QA의 가치를 더 널리 알릴 필요가 있다.

4. QA Engineer의 연봉 및 커리어 패스 확립

• QA가 단순한 테스터가 아니라, 품질 전략을 담당하는 전문가로 자리 잡도록 인식 개선이 필요하다.

• QA도 기술적 역량과 기여도에 따라 개발자와 동등한 연봉을 받을 수 있도록 구조를 만들어야 한다.

4. Summary

소프트웨어 테스팅과 QA는 단순히 버그를 찾는 과정에서 시작했지만, 이제는 소프트웨어의 품질을 설계하는 역할로 발전하고 있다.

• QA는 소프트웨어 위기에서 출발하여, 테스팅이 체계화되면서 독립적인 직군으로 자리 잡았다.

• 현재는 DevOps, AI, 테스트 자동화 등의 기술이 결합되면서 QA의 역할이 더욱 확대되고 있다.

• 하지만 여전히 QA는 개발에 비해 덜 주목받으며, 그 가치를 제대로 인정받지 못하는 경우가 많다.

• 앞으로 QA는 단순한 기능 검증을 넘어, 소프트웨어 품질을 총괄하는 전략적 역할로 자리 잡아야 한다.

QA는 더 이상 개발이 끝난 후 문제를 찾아내는 역할이 아니다.

개발과 함께 움직이며, 소프트웨어의 품질을 설계하는 직군으로 자리 잡아야 한다.

QA Engineer는 더 이상 조연이 아니다.

✅ 과거의 QA: 개발자가 만든 기능을 테스트하는 보조적인 역할

✅ 현재의 QA: 테스트 자동화, 품질 전략, 보안 및 성능 테스트까지 수행하는 필수적인 역할

✅ 미래의 QA: AI와 DevOps 기반의 소프트웨어 품질 보증 전문가

QA는 단순히 오류를 찾는 사람이 아니라, 소프트웨어의 품질을 설계하는 사람이다.

이제는 QA도 개발과 동등한 엔지니어 직군으로 인정받아야 하며,

QA의 가치가 기업과 업계 전반에서 제대로 평가받을 수 있도록 변화가 필요하다.