왜 용어 지도가 따로 필요한가

소프트웨어공학은 일상어와 비슷하게 생긴 전문 용어가 많다. “요구사항”과 “요구”, “결함”과 “오류”와 “실패”, “검증”과 “확인”처럼 한국어로 옮기면 뜻이 겹쳐 보이는 단어들이 실제로는 서로 다른 대상을 가리킨다. 독학사 시험은 이 미세한 차이를 정확히 아는지를 즐겨 묻는다 — “설명이 맞게 짝지어진 것”이나 “옳지 않은 것” 유형이 대표적이다.

이번 편은 새로운 개념을 배우는 편이 아니라, 앞으로 반복해서 쓸 용어들을 미리 정확한 경계로 나눠 두는 지도(map)다. 각 용어 쌍은 나중에 본론 편(06편 이후)에서 다시 등장할 때 “3편에서 정리한 그 구분”이라고 되짚을 수 있게 간단히 표시해 둔다.

1. 요구사항 계열 — 요구·요구사항·명세

세 용어는 구체화의 단계가 다르다. “고객이 앱이 빨랐으면 좋겠다고 말했다”는 요구다. 이를 “검색 결과는 2초 이내에 표시되어야 한다”로 다듬으면 요구사항이 된다. 이런 요구사항들을 모아 우선순위·제약조건과 함께 문서로 정리한 것이 명세(SRS, Software Requirements Specification)다.

쉽게 말하면: 요구는 “느낌”, 요구사항은 “문장으로 만든 조건”, 명세는 “그 조건들을 모은 공식 문서”다.

이 구분이 왜 중요한지는 06~07편(요구공학)에서 도출·분석·명세·검증의 각 단계와 직접 연결된다. 지금은 “구체화 정도의 차이”라는 축만 잡아두면 된다.

2. 검증·확인 계열 — 다시 정확히 굳히기

02편에서 짧게 다룬 검증(Verification)과 확인(Validation)을 이번에는 예시로 완전히 굳힌다.

• 검증(Verification): “제품을 올바르게(정해진 명세대로) 만들고 있는가?” — 이전 단계의 산출물과 대조한다.
• 확인(Validation): “올바른(실제 필요한) 제품을 만들고 있는가?” — 실제 사용 맥락·사용자 요구와 대조한다.

두 상황 모두 “검증 통과 = 확인 통과”가 아님을 보여준다. 검증은 문서 간 일치를, 확인은 실제 필요와의 일치를 본다는 점을 이 표로 확실히 구분해 둔다.

3. 설계·구현·검토 — 활동의 성격 차이

세 용어 모두 “무언가를 만드는 과정”에 속하지만, 다루는 대상과 산출물의 성격이 다르다.

• 설계(Design): 요구사항을 만족하는 구조(모듈 구성, 인터페이스, 알고리즘 개요)를 결정하는 활동. 산출물은 아직 실행되지 않는 문서·다이어그램이다.
• 구현(Implementation): 설계를 실제로 실행 가능한 코드로 옮기는 활동. 산출물은 실행 가능한 소스코드다.
• 검토(Review): 산출물(설계 문서든 코드든)을 실행하지 않고 사람이 읽으며 결함을 찾는 활동. 코드 리뷰, 설계 검토 등이 해당한다.

검토가 헷갈리기 쉬운 지점은 “테스트와 뭐가 다른가”이다. 테스트는 프로그램을 실행해서 실제 동작을 관찰하는 동적(dynamic) 활동이고, 검토는 프로그램을 실행하지 않고 읽기만 하는 정적(static) 활동이다. 이 구분은 13편(테스팅의 기초)에서 정적 검증 기법과 동적 검증 기법을 나눌 때 그대로 이어진다.

비유로 이해하기: 검토는 다리 설계도를 전문가들이 모여 앉아 눈으로 검토하며 오류를 찾는 것이고, 테스트는 실제로 축소 모형에 하중을 가해 무너지는지 확인하는 것이다. 둘 다 결함을 찾는 목적은 같지만 방법(읽기 vs 실행)이 다르다.

4. 결함·오류·실패 — 시험에서 가장 자주 헷갈리는 삼총사

이 세 용어는 하나의 인과 사슬로 이해하면 절대 헷갈리지 않는다.

• 오류(Error, Mistake): 개발자가 요구사항을 잘못 이해하거나 코드를 잘못 작성하는 사람의 실수 자체를 가리킨다. 예: 개발자가 “이상이면”을 코드에서 >= 대신 >로 잘못 옮겨 적었다.
• 결함(Fault, Defect, 흔히 “버그”라고도 부름): 그 실수가 산출물(코드나 문서)에 남긴 잘못된 상태다. 예: 코드에 >로 잘못 적힌 그 줄 자체.
• 실패(Failure): 그 결함을 포함한 프로그램을 실행했을 때, 명세와 다르게 동작하는 것이 관찰되는 사건이다. 예: 경계값(정확히 그 값)을 입력했을 때 프로그램이 잘못된 결과를 출력하는 순간.

세 단어의 관계에서 중요한 것은 결함이 있다고 항상 실패가 관찰되는 것은 아니다라는 점이다. 결함이 있는 코드 경로를 아직 아무도 실행하지 않았다면 실패는 겉으로 드러나지 않는다. 그래서 “결함 없음”과 “실패 없음”은 다른 말이다 — 실패가 없다고 결함이 없다는 뜻은 아니며, 단지 그 결함을 드러낼 조건이 아직 발생하지 않았을 뿐일 수 있다.

이 구분은 13~15편(테스팅)과 16편(유지보수, 결함 생명주기)에서 결함 추적·분류의 기본 단위로 계속 쓰인다.

5. 결함 생명주기를 살짝 미리 보기

결함은 발견되고 나서도 곧바로 사라지지 않는다. 보고되고, 확인되고, 수정되고, 재검증되는 상태 전이를 거친다. 이 전체 흐름은 16편에서 자세히 다루지만, 용어 지도 차원에서 상태 이름만 먼저 익혀 둔다.

“발견됨”과 “확인됨”을 같은 상태로 착각하기 쉬운데, 발견은 누군가 문제를 보고한 시점이고 확인은 그 문제가 실제로 재현 가능한 결함임을 담당자가 검증한 시점이다. 재현되지 않는 보고는 “확인됨” 상태로 넘어가지 못하고 반려될 수 있다.

자주 틀리는 점

• 요구 vs 요구사항 vs 명세를 같은 말로 뭉뚱그리면, “SRS는 이해관계자의 구두 요구를 그대로 옮긴 문서다”처럼 틀린 진술을 골라내지 못한다. SRS는 구체화·정리를 거친 공식 문서다.
• 검증과 확인을 반대로 외우는 실수가 가장 흔하다. “Verification = 명세와 일치하는가”, “Validation = 실제 필요와 일치하는가”로 영단어 자체에 의미를 걸어 외운다.
• 검토와 테스트를 같은 활동으로 혼동하면 안 된다. 검토는 정적(실행 없음), 테스트는 동적(실행함) 활동이다.
• 결함이 없으면 실패도 없다고 단정하는 것은 틀린 추론이다. 결함이 있어도 그 경로를 실행하지 않으면 실패가 관찰되지 않을 뿐이다. 역으로 “실패가 관찰되지 않았으니 결함이 없다”도 틀린 진술이다.
• 오류·결함·실패를 발생 위치 기준(사람의 머릿속 / 산출물 / 실행 중 시스템)으로 구분하지 않고 “다 비슷한 버그 관련 용어”로 뭉치면 문제를 틀린다.

핵심 정리

• 요구는 막연한 바람, 요구사항은 구체화된 조건 문장, 명세는 요구사항들을 정리한 공식 문서(SRS)다.
• 검증(Verification)은 “제품을 올바르게 만들었는가”를, 확인(Validation)은 “올바른 제품을 만들었는가”를 묻는다.
• 설계는 구조 결정, 구현은 코드 작성, 검토는 실행 없이 읽어서 결함을 찾는 정적 활동이다.
• 오류는 사람의 실수, 결함은 산출물에 남은 잘못된 상태, 실패는 실행 중 관찰되는 잘못된 동작이며, 이 셋은 인과 사슬로 이어진다.
• 결함은 발견 → 확인 → 수정 → 재검증 → 종료의 상태를 거치며, 발견과 확인은 서로 다른 시점이다.

마무리 복습

참고 자료

• 국가평생교육진흥원 독학학위제 시험안내 
• 국가평생교육진흥원 독학학위제 제도 활용