# 테스트 제대로 하는 법 — 실무자가 절대 건너뛰지 않는 단계 --- 테스트는 소프트웨어, 제품, 또는 서비스가 의도한 대로 동작하는지 확인하는 검증 과정입니다. 개발 현장에서는 버그를 조기에 발견할수록 수정 비용이 기하급수적으로 줄어드는데, IBM 연구에 따르면 출시 후 발견된 버그는 개발 중 발견된 것보다 최대 100배 더 많은 비용이 든다고 합니다. 테스트는 단순히 오류를 찾는 작업이 아닙니다. 시스템이 사용자의 기대를 충족하는지, 성능은 적절한지, 보안은 견고한지를 점검하는 품질 관리의 핵심 단계죠. 실제로 구글, 마이크로소프트 같은 기업들은 전체 개발 인력의 약 30~40%를 테스트 관련 업무에 투입합니다. 이 글에서는 테스트의 종류와 실무에서 바로 쓸 수 있는 접근법을 다룹니다. 커버리지 숫자의 함정, 자동화 도입 시점, 피라미드 구조까지 현장에서 자주 마주치는 질문들을 기준으로 정리했습니다. --- ## 테스트가 왜 이렇게 중요한지 — 숫자로 보면 명확합니다 소프트웨어 테스트의 무게를 처음 피부로 느낀 건 작은 스타트업 이야기를 들었을 때였어요. 서비스 출시 직후 결제 모듈에서 오류가 터졌는데, 불과 2시간 만에 수천만 원의 매출이 날아갔다고 하더군요. 충분한 테스트가 있었다면 막을 수 있었던 상황이었는데 말이죠. NIST(미국 국립표준기술연구소) 보고서에 따르면, 미국 소프트웨어 산업에서 불충분한 테스트로 발생하는 연간 손실이 약 595억 달러에 달합니다. 뚝뚝 새는 파이프처럼, 테스트 없이 출시된 소프트웨어는 조용히 비용을 갉아먹는 구조거든요. [이미지: 테스트 단계별 버그 수정 비용 증가 그래프 — 개발 중 발견 vs 출시 후 발견 비교] 테스트를 건너뛰고 싶은 마음은 충분히 이해합니다. 납기 압박이 있고, 기능 개발에 시간을 더 쏟고 싶은 게 당연하니까요. 그런데 흥미롭게도, 테스트에 1달러를 투자하면 평균 5~10달러의 버그 수정 비용이 절감된다는 연구 결과가 있습니다(Capers Jones, 소프트웨어 공학 연구, 2017). 선투자 효과가 쑥쑥 올라가는 셈이에요. [quotation_line]소프트웨어 테스트는 버그를 찾는 게 아니라, 버그가 없다는 확신을 쌓아가는 과정이다.[/quotation_line] --- ## 테스트의 종류 — 뭐가 뭔지 헷갈렸다면 여기서 정리됩니다 지금 "그래서 어떤 테스트부터 시작하면 되는 거야?" 하고 생각하시는 분 분명 계실 거예요. 단위 테스트, 통합 테스트, E2E 테스트... 용어가 많아서 슬그머니 겁이 나기도 하죠. [이미지: 테스트 피라미드 구조도 — 단위/통합/E2E 계층별 비중 시각화] 쉽게 말하면 이렇습니다. 단위 테스트(Unit Test)는 함수 하나, 메서드 하나처럼 아주 작은 단위를 검증해요. 자동화가 쉽고 실행 속도가 빠릅니다. 구글 엔지니어링 팀은 전체 테스트의 약 70%를 단위 테스트로 구성하길 권장하는데, 기초가 탄탄해야 위층 테스트가 가벼워지기 때문이에요. 통합 테스트(Integration Test)는 여러 모듈이 함께 동작할 때를 검증합니다. API가 데이터베이스와 제대로 통신하는지, 외부 서비스와의 연동이 맞는지 확인하는 거예요. 전체 테스트 구성의 약 20%를 차지하는 게 이상적이라고 합니다. E2E 테스트(End-to-End Test)는 실제 사용자처럼 시스템 전체를 처음부터 끝까지 테스트하는 방식입니다. 가장 현실적이지만 느리고 비용이 많이 들어서, 전체의 10% 이내로 유지하는 게 좋아요. 이 비율을 "테스트 피라미드"라고 부르는데, 마틴 파울러(Martin Fowler)가 2012년에 정립한 개념이죠. --- ## 테스트 자동화 — 반복 작업은 기계에 맡기는 게 맞습니다 수동으로 매번 클릭하며 검증하던 시절이 있었어요. 릴리스 전날 밤 개발자 전원이 달라붙어 기능 하나하나를 손으로 확인하는 거죠. 2~3시간은 기본이고, 놓치는 경우도 허다했습니다. [이미지: CI/CD 파이프라인 자동화 테스트 흐름도 — 코드 푸시부터 배포까지] 자동화 테스트는 이 반복 노동을 기계에 넘기는 겁니다. Selenium, Cypress, Playwright 같은 도구들이 대표적이에요. 한 번 스크립트를 짜두면 수백 번을 똑같이 실행해주거든요. JetBrains 개발자 설문(2023)에 따르면, 응답자의 약 67%가 이미 자동화 테스트를 활용하고 있으며, 그 비율은 매년 8~10%포인트씩 증가하는 추세입니다. [quotation_line]자동화 테스트를 도입한 팀은 릴리스 주기가 평균 46% 단축되었으며, 버그 발생률은 36% 감소했다. (DORA State of DevOps Report, 2022)[/quotation_line] CI/CD 파이프라인과 결합하면 더 강력해집니다. 코드가 푸시될 때마다 테스트가 자동으로 돌아가고, 실패하면 머지가 차단돼요. 제 기억이 맞다면, GitHub Actions가 무료 플랜에서도 월 2,000분의 실행 시간을 제공하기 시작한 게 2019년쯤이었는데, 덕분에 소규모 팀도 자동화 환경을 손쉽게 구축할 수 있게 됐습니다. --- ## 테스트 설계의 핵심 — 커버리지 수치만 믿으면 위험합니다 테스트 커버리지 100%면 완벽한 테스트일까요. 아닙니다. 많은 분들이 빠지는 함정이에요. [이미지: 코드 커버리지 리포트 예시 — 라인별 실행 여부 색상 표시 화면] 커버리지는 코드 라인이 테스트에 의해 실행된 비율을 뜻합니다. 그런데 실행됐다는 것과 올바르게 검증됐다는 건 다른 이야기거든요. 어떤 함수를 호출하는 테스트가 있어도 반환값을 아무것도 검증하지 않으면, 커버리지는 올라가지만 의미 있는 테스트는 아닌 거죠. 실무에서는 커버리지 80%를 합리적인 목표로 설정하는 경우가 많아요. 구글 내부 가이드라인도 "60%는 수용 가능, 75%는 칭찬할 만한 수준, 90% 이상은 너무 꼼꼼할 수 있다"는 표현을 사용한다고 알려져 있습니다. 숫자를 채우는 데 집착하다 보면, 정작 중요한 엣지 케이스를 놓치는 일이 생기거든요. [이미지: 단위 테스트 코드 예시 — 정상/경계값/예외 케이스 3가지 구조 비교] 좋은 테스트 케이스는 세 축을 담아야 합니다. 정상 동작 확인, 경계값 처리, 예외 상황 대응. 이 세 가지가 탄탄하면 커버리지가 100%가 아니어도 충분히 신뢰할 수 있는 테스트 스위트가 됩니다. --- 테스트를 "언젠가 해야 할 일"이 아니라 개발의 자연스러운 흐름으로 받아들이는 팀이 결국 더 빠르게 달리더군요. 릴리스할 때마다 조마조마하지 않아도 되는 그 여유는, 결국 촘촘한 테스트가 만들어주는 겁니다.