소프트웨어 테스트란? AI가 만든 코드의 PASS·FAIL 쉽게 이해하기
“코덱스가 ‘테스트 12개 통과(PASS)’라고 보고했는데, 이제 홈페이지에 문제가 없다는 뜻일까요?” ChatGPT나 Codex에게 홈페이지를 만들어 달라고 하면 “코드 수정 완료”, “테스트 통과”, “검증 성공” 같은 결과가 나타날 수 있습니다.
이런 문구가 나오면 모든 문제가 해결됐다고 생각하기 쉽습니다. 하지만 테스트가 통과했다고 해서 프로그램의 모든 기능이 완벽하게 작동한다는 의미는 아닙니다. 여기에서 알아두면 좋은 용어가 소프트웨어 테스트(Software Testing)입니다. 소프트웨어 테스트란 프로그램이나 웹사이트가 필요한 요구사항을 충족하고 예상대로 작동하는지 확인하며, 문제가 될 수 있는 부분을 찾아보는 활동입니다. 쉽게 말해 '만들었다'에서 끝내지 않고 '정말 제대로 되는가?'를 확인하는 과정입니다. 이번 글에서는 테스트가 무엇인지, PASS와 FAIL의 차이, 자동 테스트와 실제 화면 확인법, AI의 테스트 보고에서 무엇을 믿고 무엇을 다시 확인해야 하는지 설명하겠습니다.
1. 테스트는 요리한 음식을 '맛보고 확인하는 과정'과 비슷합니다
요리사가 레시피대로 케이크를 만들었다고 생각해 보겠습니다. 재료를 정해진 양만큼 넣고 오븐에서 꺼냈다고 해서 무조건 성공한 케이크일까요? 가운데까지 잘 익었는지, 맛과 모양이 원하는 상태인지, 알레르기 유발 재료를 실수로 넣지 않았는지 확인할 필요가 있을 수 있습니다. 프로그램도 비슷합니다. 홈페이지에 검색 버튼을 만들었다고 해도 버튼이 실제로 눌리는지, 검색 결과가 제대로 나오는지, 존재하지 않는 단어를 입력해도 화면이 깨지지 않는지 확인해야 합니다.
이런 확인 활동이 테스트입니다. 특히 중요한 것은 눈에 보이는 버튼 하나만 확인하는 것으로 전체 기능을 검증했다고 생각하지 않는 것입니다. 테스트에는 실제 프로그램을 실행하는 활동뿐 아니라, 실행하기 전에 요구사항과 설계를 검토해 오류 가능성을 찾는 활동도 포함될 수 있습니다.
2. PASS·FAIL·미실행은 어떻게 다를까요?
테스트 결과에는 다음과 같은 표시가 자주 사용됩니다.
| 결과 | 쉽게 말하면 | 의미 |
|---|---|---|
| PASS(통과) | 정한 조건을 만족함 | 실행한 검사에서 기대 결과가 확인됨 |
| FAIL(실패) | 정한 조건과 다름 | 실행한 검사에서 기대 결과가 확인되지 않음 |
| NOT RUN(미실행) | 검사를 하지 않음 | 해당 항목의 성공·실패를 판단할 근거가 아직 없음 |
| BLOCKED(차단) | 환경 문제 등으로 진행 불가 | 테스트를 시작하거나 완료하지 못함 |
여기서 가장 주의할 점은 미실행과 통과를 혼동하지 않는 것입니다. 실행하지 않은 검사는 성공했다는 증거가 될 수 없습니다. 또한 FAIL이 떴다고 항상 코드 결함이라고 단정할 수도 없습니다. 테스트를 위한 데이터가 잘못됐거나 검사 환경이 고장 나도 실패가 발생할 수 있습니다. 원인을 확인해야 합니다. 반대로 PASS는 실제로 수행한 해당 검사의 조건을 만족했다는 뜻이지, 테스트하지 않은 화면과 기능까지 모두 안전하다는 증명이 아닙니다. 예를 들어 로그인 버튼 검사만 PASS였는데 결제 화면에는 전혀 들어가 보지 않았다면, 결제 기능이 정상이라고 말할 근거는 없습니다.
3. '테스트 케이스'를 알면 검사 보고서를 읽을 수 있습니다
테스트 케이스(Test Case)는 어떤 조건에서 무엇을 입력하고, 어떤 행동을 했을 때, 무엇이 나와야 하는지를 정리한 검사 항목입니다. 아주 간단한 블로그 검색 기능을 예로 들어 보겠습니다. 사용자가 글 제목을 검색할 수 있는 웹페이지를 만들었다고 가정합니다.
| 테스트 항목 | 입력·행동 | 기대하는 결과 |
|---|---|---|
| 정상 검색 | '토큰' 입력 후 검색 | '토큰'과 관련된 글이 표시됨 |
| 결과 없는 검색 | 존재하지 않는 긴 단어 입력 | '검색 결과 없음' 안내가 표시됨 |
| 빈 검색 | 아무것도 입력하지 않고 검색 | 안내문 표시 또는 미리 정한 기본 동작 |
| 모바일 검색 | 좁은 휴대폰 화면에서 검색 | 버튼과 결과가 화면 밖으로 잘리지 않음 |
이 표는 앞으로 실행할 검사를 설계한 가상 예시입니다. 특정 블로그에서 실제로 테스트를 실행했다는 뜻이 아닙니다. 테스트를 실제로 수행할 때는 여기에 실제 관찰한 결과, 통과 여부, 사용한 기기와 브라우저, 실행 날짜 등을 기록하면 좋습니다. 특히 세 번째 '빈 검색'처럼 정답이 하나로 정해지지 않은 기능은 어떤 동작을 정답으로 볼지 먼저 합의해야 합니다. 기대 결과가 불분명하면 테스트가 PASS인지 FAIL인지도 판단하기 어렵습니다.
4. 수동 테스트와 자동 테스트는 무엇이 다른가요?
테스트를 실제로 수행하는 방법에는 크게 두 가지가 있습니다. 수동 테스트(Manual Testing)는 사람이 직접 앱이나 웹페이지를 사용해 보면서 결과를 확인하는 방법입니다. 예를 들어 휴대폰에서 블로그를 열고, 글 제목이 읽기 편한지 살펴보고, 검색 버튼을 직접 눌러보는 것입니다. 자동 테스트(Automated Testing)는 도구나 프로그램이 정해 놓은 검사를 실행하고 결과를 비교하도록 만드는 방법입니다. 예를 들어 검색어를 입력한 다음 원하는 제목이 화면에 표시됐는지 검사하는 절차를 자동으로 실행할 수 있습니다.
| 구분 | 장점 | 주의할 점 |
|---|---|---|
| 수동 테스트 | 낯선 문제나 사용하기 불편한 부분을 직접 살펴보기 좋음 | 반복 검사에 시간과 노력이 듦 |
| 자동 테스트 | 같은 검사를 자주 반복하고 변경 뒤 빠르게 확인하기 좋음 | 테스트에 없는 상황은 확인하지 못할 수 있음 |
어느 한쪽이 무조건 더 좋은 것은 아닙니다. 예를 들어 검색 기능이 정상으로 동작하는지 자동 검사로 확인하면서도, 실제로 화면을 봤을 때 글씨가 너무 작거나 설명이 이해하기 어려운지는 사람이 따로 확인할 수 있습니다. 자동 테스트와 수동 테스트는 서로 경쟁하는 방식이라기보다 함께 활용할 수 있는 방법입니다.
5. 단위 테스트·통합 테스트·전체 흐름 테스트는 무엇인가요?
자동 테스트에 관한 설명을 읽다 보면 단위 테스트(Unit Test), 통합 테스트(Integration Test), 전체 흐름 테스트(E2E Test)라는 말을 자주 봅니다. 이것은 누가 검사하느냐가 아니라 어느 범위까지 확인하느냐를 구분하는 개념입니다. 단위 테스트는 프로그램의 비교적 작은 부분이 정해진 입력에 올바르게 반응하는지 확인합니다. 예를 들어 상품 가격에 할인율을 적용하는 작은 계산 기능이 예상 금액을 반환하는지 살펴보는 것입니다.
통합 테스트는 서로 연결된 여러 부분이 함께 작동하는지 확인합니다. 예를 들어 사용자가 검색 버튼을 누르면 검색 기능이 서버와 정보를 주고받고, 서버가 받아 온 결과를 다시 화면에 전달하는 과정의 연결을 검사할 수 있습니다. 전체 흐름 테스트(E2E, End-to-End)는 실제 사용자의 시작부터 끝까지 이어지는 중요한 행동을 확인합니다. 예를 들어 방문자가 블로그를 열고 → 검색어를 입력하고 → 글을 선택하고 → 본문을 읽는 과정이 정상적으로 이어지는지 검사합니다.
| 검사 범위 | 블로그에서의 예시 | 주요 질문 |
|---|---|---|
| 단위 | 검색어를 정리하는 작은 기능 | 이 작은 기능이 원하는 결과를 내나? |
| 통합 | 검색 기능과 글 목록 데이터 연결 | 서로 연결된 부분이 잘 협력하나? |
| 전체 흐름(E2E) | 검색부터 글 읽기까지 | 이용자의 전체 행동이 끝까지 되나? |
세 가지를 모두 반드시 같은 수만큼 만들어야 한다는 뜻은 아닙니다. 사이트의 구조와 위험에 따라 필요한 검사를 정합니다. 또 단위·통합·E2E라는 범위 구분과 수동·자동이라는 실행 방식 구분은 서로 다른 기준입니다.
6. 한번 통과한 테스트를 왜 다시 실행하나요?
홈페이지에서 검색 버튼의 색상만 변경했다고 가정해 보겠습니다. 처음에는 단순한 디자인 수정처럼 보이지만, 잘못 수정하면 버튼이 눌리지 않거나 다른 화면의 스타일이 깨질 수도 있습니다. 그래서 프로그램을 변경한 후에는 기존에 잘 되던 부분에도 문제가 생기지 않았는지 확인하는 것이 좋습니다. 이를 회귀 테스트(Regression Testing)라고 합니다. 여기서 '회귀'는 통계 계산을 뜻하는 말이 아닙니다.
새 변경으로 이전에 정상 작동하던 기능에 문제가 생겼는지 살펴본다는 뜻입니다. 그런데 회귀 테스트와 구별해야 하는 검사도 있습니다. 수정 확인 테스트(Confirmation Testing, 재테스트)는 원래 실패했던 항목을 다시 실행해 그 오류가 해결됐는지 확인하는 것입니다. 예를 들어 검색 버튼을 눌러도 반응이 없던 오류를 수정했다면, 수정 확인 테스트로 버튼이 이제 작동하는지 확인합니다. 그다음 다른 메뉴의 버튼이나 모바일 화면이 영향을 받지 않았는지 회귀 테스트를 실행할 수 있습니다.
정리하면 다음과 같습니다. 수정 확인 테스트: “고치려던 문제가 정말 해결됐나?” 회귀 테스트: “그 문제를 고치면서 멀쩡했던 다른 곳이 망가지지는 않았나?” 둘은 비슷해 보여도 검사 목적이 다릅니다.
7. 홈페이지 테스트에서는 화면 크기도 중요합니다
코드가 맞고 검색 기능도 작동하는데 휴대폰에서 글 제목이 잘려 보인다면 어떨까요? 사용자에게는 분명 불편한 홈페이지입니다. 이처럼 테스트는 기능뿐 아니라 사용성, 화면 배치, 접근성, 성능 등도 살펴볼 수 있습니다. 예를 들어 블로그를 만들었다면 다음과 같은 항목을 확인할 수 있습니다. 작은 휴대폰 화면: 제목이나 표가 화면 바깥으로 밀려나지 않는가? 큰 화면: 글과 이미지가 지나치게 늘어나거나 겹치지 않는가? 키보드 사용: 마우스 없이 검색창과 버튼을 사용할 수 있는가?
화면 읽기 프로그램: 이미지에 의미를 전달하는 설명이 있고, 제목 구조가 올바른가? 느린 연결: 글과 이미지가 늦게 나타날 때도 핵심 내용을 읽을 수 있는가? 예를 들어 화면 너비 320픽셀과 390픽셀에서 확인해 보는 것은 일부 작은 모바일 화면을 점검하기 위한 실용적인 검사 조건의 예시입니다. 이 두 크기에서 통과했다고 모든 휴대폰과 브라우저에 문제가 없다는 보장은 아닙니다. 모든 기기와 브라우저 조합을 완벽하게 검사하기 어렵기 때문에, 실제 방문자가 많이 사용하는 환경과 중요한 기능부터 우선순위를 정하는 것이 좋습니다.
8. '테스트 100개 통과'면 완벽한 프로그램일까요?
아닙니다. 테스트 개수가 많다는 사실은 여러 검사를 수행했다는 의미일 수 있지만, 그 검사가 중요한 위험을 다뤘는지는 별도 문제입니다. 예를 들어 글 제목 색상만 100번 검사한 사이트와, 검색·로그인·결제처럼 중요한 기능을 다양하게 검사한 사이트가 있다고 생각해 보세요. 첫 번째 사이트의 검사 개수가 더 많다고 실제 운영에서 반드시 더 안전하다고 볼 수는 없습니다. 테스트의 가치를 판단할 때는 숫자뿐 아니라 다음과 같은 내용을 살펴야 합니다.
무엇을 검사했는가? 중요한 사용자 행동이 포함됐는가? 어떤 환경에서 검사했는가? 실제 사용하는 기기와 비슷한가? 어떤 경우를 빠뜨렸는가? 빈 입력이나 오류 상황도 확인했는가? 실패와 미실행은 어떻게 보고했는가? 실행하지 않은 검사까지 통과에 포함하지 않았는가? 누가 결과를 확인했는가? 실제 이용자의 요구와 일치하는가? 테스트가 모두 PASS라도 검사하지 않은 경로에서 결함이 발견될 수 있습니다. 따라서 “전체 테스트 PASS”라는 보고를 받았다면, 전체라는 말이 어떤 검사 목록을 가리키는지 함께 확인하는 것이 좋습니다.
9. 코덱스가 '테스트 성공'이라고 말하면 무엇을 확인해야 할까요?
코덱스(Codex)는 지원되는 환경에서 코드를 수정한 뒤 테스트 명령을 실행하거나 변경 내용을 검토할 수 있습니다. 하지만 결과를 보고할 때는 어떤 테스트를 실제로 실행했는지와 무엇이 아직 확인되지 않았는지를 구분해야 합니다. 예를 들어 “테스트 PASS”라는 문장만 있다면 다음과 같이 물어볼 수 있습니다.
방금 수정한 검색 기능에 대해 실제로 실행한 테스트 이름과 실행 결과를 알려 줘. 실행하지 않은 검사는 '미실행'으로 표시해 줘. PC와 휴대폰 화면을 직접 확인했는지, 다른 기능이 영향을 받지 않았는지도 구분해 줘. 확인할 내용은 크게 네 가지입니다. 첫째, 테스트 이름: 어떤 기능이나 상황을 검사했는지. 둘째, 실제 실행 여부: 실행한 검사인지, 앞으로 실행할 계획만 세운 것인지. 셋째, 결과와 증거: PASS·FAIL·미실행 등 상태와 실행 로그, 화면 확인 결과. 넷째, 남은 위험: 확인하지 못한 브라우저, 기능 또는 외부 서비스. 가령 다음은 설명용 가상 테스트 보고서 형식입니다. 실제 프로젝트에서 나온 결과가 아닙니다.
| 검사 항목 | 결과 예시 | 남은 확인 사항 |
|---|---|---|
| 검색 결과 표시 | PASS | 정확한 검색어 범위 확인 |
| 결과 없는 검색 | PASS | 긴 입력 처리 확인 |
| 모바일 화면 | 미실행 | 실제 화면 열어 확인 필요 |
| 다른 메뉴 이동 | 미실행 | 회귀 테스트 필요 |
이렇게 보고하면 '테스트 성공'이라는 한 문장보다 확인한 사실과 남아 있는 일을 정확히 구분할 수 있습니다. 중요한 사이트라면 AI가 작성한 요약만으로 결정하지 말고, 실제 테스트 로그·수정 파일·브라우저 결과도 검토하세요.
10. 자동으로 테스트가 실행되는 CI는 무엇인가요?
AI 개발 작업이나 GitHub 저장소에서 CI, 빌드, 체크(Check) 같은 말을 접할 수 있습니다. CI(Continuous Integration, 지속적 통합)는 여러 개발자의 변경 사항을 자주 합치면서 자동으로 검사하고 문제를 발견하도록 돕는 개발 방식입니다. 예를 들어 저장소에 새로운 변경 사항이 올라오면 자동화 시스템이 프로그램을 준비하고, 미리 지정된 테스트를 실행하고, 성공과 실패 결과를 보여줄 수 있습니다.
GitHub Actions 같은 도구가 이런 작업에 활용될 수 있습니다. 다만 CI가 성공했다고 해서 실제 공개 블로그의 모든 화면과 기능이 완벽하다는 뜻은 아닙니다. 자동 검사에 포함되지 않은 모바일 화면 문제, 실제 서비스에만 있는 설정 문제, 잘못된 콘텐츠 등이 남아 있을 수 있기 때문입니다. 또한 테스트 통과와 배포 완료는 별개입니다. 간단히 말하면 다음과 같습니다. 코드 수정 → 지정된 테스트 실행 → 검토 → 필요하면 실제 사이트 배포 → 공개 화면 확인 어느 단계까지 완료됐는지 알아야 결과를 정확하게 이해할 수 있습니다.
11. 코딩을 몰라도 할 수 있는 테스트 체크리스트
AI에게 처음으로 블로그 기능을 만들어 달라고 요청했다면 다음 순서로 확인해 보세요. ① 원래 요청을 다시 읽습니다. “검색 기능 추가”처럼 목표가 분명해야 무엇을 검사할지 정할 수 있습니다. ② 정상적인 사용을 해봅니다. 검색어를 넣고 결과가 표시되는지 확인합니다. ③ 예상 밖의 상황을 시도합니다. 빈 입력이나 결과가 없는 검색도 확인합니다. ④ PC와 휴대폰 화면을 살펴봅니다. 글자가 겹치거나 잘리는 부분은 없는지 봅니다. ⑤ 원래 있던 기능을 확인합니다. 메뉴 이동, 이전 글 보기 등 기존 기능이 유지되는지 확인합니다. ⑥ 결과를 기록합니다. 무엇을 실제로 확인했고, 무엇을 확인하지 못했는지 구분합니다. AI에게는 다음처럼 부탁할 수 있습니다.
블로그에 검색 기능을 추가한 뒤 테스트 계획을 먼저 작성해 줘. 정상 검색, 결과 없는 검색, 빈 검색, 모바일 화면, 기존 메뉴 이동을 각각 확인해 줘. 실제로 실행한 항목의 결과와 근거를 기록하고, 실행할 수 없는 검사는 미실행으로 남겨 줘. 테스트 통과만으로 배포하지 말고 수정 내용과 남은 위험을 보고해 줘. 이런 지시는 코드를 직접 이해하지 못해도 어떤 결과가 필요하고 무엇이 아직 확인되지 않았는지를 파악하는 데 도움이 됩니다. 테스트는 완벽함을 증명하는 마법 같은 절차가 아닙니다. 하지만 문제가 생길 가능성을 더 일찍 발견하고, 확인한 사실을 근거로 다음 결정을 내리게 해 줍니다.
자주 묻는 질문
Q. 소프트웨어 테스트는 프로그램을 실제로 실행해야만 할 수 있나요?
아닙니다. 실행하지 않고 요구사항·설계·코드를 검토하는 정적 테스트(Static Testing)도 있습니다. 실제 프로그램을 실행해 동작을 확인하는 것은 동적 테스트(Dynamic Testing)에 해당합니다.
Q. 테스트에서 PASS가 나오면 오류가 완전히 없다는 뜻인가요?
아닙니다. 수행한 해당 검사가 기대 결과를 만족했다는 뜻입니다. 검사하지 않은 상황에서 문제가 발견될 수 있습니다.
Q. FAIL이 나오면 무조건 AI가 코드를 잘못 만든 건가요?
그렇지 않습니다. 코드 결함 외에도 잘못된 테스트 데이터, 검사 스크립트 문제, 실행 환경의 장애 등이 원인일 수 있습니다. 실패 이유를 조사해야 합니다.
Q. 수동 테스트와 자동 테스트 중 무엇이 더 정확한가요?
한쪽이 항상 더 정확하다고 단정할 수 없습니다. 반복하기 좋은 검사는 자동화하고, 실제 이용자의 불편이나 예기치 않은 문제는 사람이 확인하는 방식으로 함께 활용할 수 있습니다.
Q. 회귀 테스트는 매번 모든 기능을 확인하는 건가요?
반드시 그렇지는 않습니다. 변경된 부분과 연결된 중요한 기능, 위험이 큰 부분 등을 우선 선택할 수 있습니다. 팀의 시스템과 위험에 따라 검사 범위가 달라집니다.
Q. 화면이 예쁘게 보이면 테스트가 끝난 건가요?
아닙니다. 화면 디자인 외에도 버튼 동작, 오류 처리, 키보드 조작, 다양한 화면 크기, 중요한 데이터 처리 등을 확인해야 할 수 있습니다.
Q. AI가 테스트 코드를 만들면 검증도 자동으로 끝나나요?
아닙니다. 테스트 코드를 작성한 것과 실제로 실행한 것은 다릅니다. 테스트가 잘못 만들어졌다면 잘못된 결과를 기준으로 PASS가 나올 수도 있습니다.
Q. 코덱스가 테스트를 하지 못했는데도 작업을 끝냈다면 어떻게 하나요?
실행 환경과 권한, 실패한 이유, 실제 수행한 검사와 미실행 항목을 보고받으세요. 중요도가 높은 작업은 필요한 테스트가 끝나기 전까지 배포를 보류하는 편이 안전합니다.
마무리: 테스트는 'PASS'라는 글자보다 근거가 중요합니다
소프트웨어 테스트는 프로그램이 요구사항과 사용자의 필요에 맞게 작동하는지 확인하고 문제를 찾아보는 과정입니다. 수동·자동 테스트는 실행 방법이 다르고, 단위·통합·E2E 테스트는 확인하는 범위가 다릅니다. 이미 수정한 기능을 다시 확인하는 검사와, 다른 기능이 영향을 받지 않았는지 살펴보는 회귀 테스트도 구별해야 합니다. 무엇보다 PASS가 의미하는 범위를 이해하는 것이 중요합니다. AI가 만든 홈페이지를 사용할 때는 세 가지만 기억하세요. 무엇을 검사했나? 실제로 실행했나? 아직 확인하지 못한 것은 무엇인가? 이 세 가지를 확인하는 습관이 있다면 코드를 모두 읽지 못하더라도 AI의 개발 결과를 훨씬 더 안전하게 검토할 수 있습니다.