검증·확인·운영 피드백

명세대로 완벽히 만든 쓸모없는 기능도 실패다

개발팀이 요구문서의 모든 항목을 정확히 구현했어도 사용자의 실제 업무가 빨라지지 않을 수 있다. 반대로 사용자가 좋아하는 시제품도 보안·정확성·복구 기준을 만족하지 못하면 운영할 수 없다. 그래서 만드는 동안에는 정해진 기준을 지켰는지와 실제 필요를 풀었는지를 서로 다른 자료로 확인해야 한다. 배포한 뒤에는 실제 성능과 장애, 사용 결과를 다음 요구와 설계에 다시 돌려준다.

먼저 되짚기: 요구와 생명주기

요구는 이해관계자의 필요를 시스템이 만족해야 할 기능·품질·제약으로 표현한 기준이다. 생명주기는 그 기준을 분석, 설계, 구현, 시험, 운영, 변경의 결과물로 이어 가는 흐름이다. 검증과 확인은 이 흐름 안에서 기준을 지켰는지와 실제 필요를 채웠는지를 나누어 묻는다.

검증과 확인

검증과 확인(V&V)은 검증(Verification)과 확인(Validation)의 영어 첫 글자 V 두 개를 묶은 표기다. 검증은 단계의 결과물이 정해진 명세·설계·표준을 올바르게 만족하는지 묻는 활동이고, 확인은 최종 시스템이 실제 사용자와 운영 환경의 필요를 만족하는지 묻는 활동이다. 검증은 제품을 올바르게 만들었는가, 확인은 올바른 제품을 만들었는가라는 질문으로 기억할 수 있다. 검증 자료로는 검토와 분석, 여러 수준의 시험, 그리고 코드를 실행하지 않고 규칙 위반을 찾는 정적 검사를 쓸 수 있다. 확인 자료로는 사용자 평가와 인수시험, 시범운영, 실제 업무성과를 쓸 수 있다. 한 활동이 상황에 따라 두 질문 모두에 일부 답을 줄 수는 있지만, 무엇을 기준으로 판단하는지는 구분해야 한다.

여기서 최종 시스템의 필요를 묻는다는 말은 확인을 마지막 단계에만 한다는 뜻이 아니다. 요구와 시제품 단계부터 실제 사용 맥락을 대표하는 모델이나 증분으로 필요를 채우는지 확인하고, 완성 시스템과 운영에서도 같은 질문을 이어 간다.

운영 피드백

운영 피드백은 실제 사용환경에서 관찰한 결과를 다음 요구·설계·구현·운영 변경에 돌려주는 흐름이다. 관찰하는 대상은 성능과 가용성, 오류, 보안사건, 사용행동, 업무가치다. 지표는 수치가 시간에 따라 어떻게 변하는지, 로그는 개별 사건의 기록, 추적정보는 한 요청이 여러 구성요소를 거친 경로를 보여 준다. 사용자 문의와 장애 분석, 비용과 성과도 운영 자료다. 그런데 피드백은 수집으로 끝나지 않는다. 목표와 비교해 차이의 원인을 판단하고, 소유자가 행동한 뒤 결과를 다시 측정해야 닫힌 순환이 된다.

기준에서 운영 학습까지 증거를 잇는다

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

명세대로 응답하는 API라도 미출고 이용자 4/10이 취소 가능 시간을 오해하면 필요 확인은 실패한다. 업무규칙을 몰래 바꾸지 않고 안내를 개선하며 사용자 과제 10/10과 상태·권한 회귀를 충족한 뒤 제한 적용한다. 같은 상태·기간의 문의율을 다시 측정한다.

그림은 주문 취소 기능에서 두 판단이 갈리는 지점을 보여 준다. 실제 필요와 성공척도를 요구·설계·구현으로 옮긴 뒤, 결과물을 먼저 명세 기준으로 검증하고 다시 필요 기준으로 사용자·운영 확인을 거친다. 그런데 API가 명세대로 응답해도 미출고 이용자 10명 중 4명이 취소 가능 시간을 오해하면 필요 확인은 실패한다. 이 불일치는 원인·변경으로 넘어가 수정과 회귀시험을 거친 재검증·재확인으로 이어진다. 적용한 뒤 운영에서 다시 잰 결과가 목표와 다르면 다시 원인·변경으로 돌아가고, 그 변경은 다음 판본의 요구·설계·구현에 반영된다.

이 순환을 실제로 돌리려면 요구를 쓸 때부터 누가 어떤 환경에서 무엇으로 성공을 판단할지 정한다. 구현 전후에는 검토와 자동·수동 시험으로 명세를 지켰는지 확인하고, 대표 사용자와 실제에 가까운 환경에서 필요를 채우는지 평가한다. 배포할 때는 성공척도와 위험에 대응하는 관찰 항목, 경보 기준, 담당자, 복구 행동을 함께 준비한다. 운영 결과가 기대와 다르면 결함인지, 잘못된 가정인지, 환경 변화나 측정 문제인지 구분해 다음 변경으로 보낸다.

질문에 맞는 증거를 고른다

시험 통과 수는 품질 그 자체가 아니다. 시험이 중요한 위험과 경계조건을 얼마나 대표하는지, 실패를 볼 수 있는 기록과 지표가 있는지, 결과가 요구와 연결되는지를 함께 본다. 확인도 사용자의 선호 조사에 그치지 않고 실제 업무 목적과 안전·법적·운영 제약까지 포함한다.

시험은 결함이 없다는 증명이 아니다

시험은 선택한 조건에서 관찰한 결과일 뿐이다. 그래서 시험하지 않은 입력과 환경에 결함이 없다는 것까지 알려 주지는 않는다. 성공 경로만 시험하거나 실제와 다른 데이터·권한·부하를 쓰면 운영에서 생길 실패를 놓친다. 요구가 모호한데 시험만 자동화하면 잘못된 기대를 빠르게 되풀이할 뿐이다.

운영 지표가 많아도 사용자 가치나 위험과 연결되지 않으면 경보 소음만 늘어난다. 예를 들어 평균 응답시간만 보면 일부 사용자의 심한 지연이 가려지고, 장애 건수만 줄이려 하면 신고를 억제하는 잘못된 행동이 생길 수 있다. 그래서 기준선과 분포, 사용자 영향, 원인과 조치 결과를 함께 보고, 피드백 항목마다 의사결정자와 마감조건을 둔다.

요구에서 운영학습까지 품질 증거를 연결한다

취소 기능의 두 판단과 환류 그림을 수용기준에 대입한다. 요구에서 설계·구현·검증 결과까지 추적하고, 실제 사용자와 운영환경에서 확인한다. 배포 뒤에는 운영 결과에 나타난 차이의 원인과 변경을 판단한 다음, 영향받는 범위를 다시 검증한다.

사례: 시험은 통과했지만 실제 사용자가 목표를 달성하지 못한다

주문 취소 API가 모든 명세 시험을 통과했는데, 실제 사용자는 취소 가능 시간을 이해하지 못해 문의가 급증했다고 하자. API 응답과 권한이 명세대로라는 것은 검증에서 확인한 사실이다. 하지만 사용자가 필요한 시점에 올바르게 취소할 수 있는지를 묻는 확인은 실패한 것이다.

그래서 운영에서 취소 실패율과 문의 이유, 처리시간을 관찰하고, 원인이 잘못된 안내인지, 업무규칙인지, UI나 권한 문제인지 구분한다. 개선한 뒤에는 같은 수용기준과 실제 사용자 시나리오로 다시 시험하고 운영지표를 다시 측정해야 피드백이 닫힌다.

자체 시험은 본인 주문을 결제 전, 결제완료·미출고, 출고 후 상태로 나누어 진행한다. 이 사례의 업무규칙은 결제 전에는 직접 취소를 허용하고 그 이후에는 거부하는 것이다. API는 상태에 맞게 모두 응답했지만, 미출고 이용자 10명 중 4명이 “배송 전이면 취소 가능”으로 읽고 요청을 되풀이했다. 즉 안내가 실제 행동과 어긋난 것이다.

개선안은 주문 상세에 “직접 취소 가능: 결제 전”과 현재 상태, 문의 경로를 표시하는 것이다. 미출고 상태에서 금지된 동작을 몰래 허용하는 방식으로 해결하지 않는다. 대표 과제 재시험에서 10명 모두 가능한 동작을 찾고 상태·권한 회귀시험도 통과했다고 가정하면, 그때 제한 적용한다. 그 뒤 다음 운영기간의 같은 상태별 문의율을 다시 측정하며, 작은 과제시험을 통과했다는 것만으로 모든 사용자가 이해했다고 선언하지 않는다.

자체 10점 문제

소프트웨어 검증과 확인을 비교하고 운영 피드백을 포함한 지속적 품질확보 체계를 설명하시오.

요구어는 비교와 설명이다. 명세준수와 실제 필요충족의 판단기준을 구분한 뒤, 요구–설계–시험–운영 결과와 재변경 흐름을 연결한다.

10점 풀이 방향과 모범답안 보기

10점 답안 목차

1. 검증과 확인의 기준 차이
2. 정적검토·시험·인수·사용 증거
3. 요구–설계–시험 추적
4. 운영 지표·로그·추적정보
5. 원인분석·변경·재검증 폐루프

10점 답안 도식

판단	무엇과 무엇을 대조하는가
검증	명세 ↔ 구현 결과
확인	실제 필요 ↔ 실제 사용
운영 피드백	운영 결과 → 변경 → 재검증·재확인

대표 그림에서 두 판단의 기준이 달라지는 위치를 설명한다.

기술사 답안으로 전환하기

예상문제: “소프트웨어 검증과 확인을 비교하고 운영 피드백을 포함한 지속적 품질확보 체계를 설명하시오.”

검증은 단계 결과물이 요구·설계·표준을 올바르게 만족하는지 묻고, 확인은 최종 시스템이 실제 사용자와 운영환경의 필요를 만족하는지 묻는다. 검토, 정적분석, 수준별 시험은 주로 검증 자료이고, 사용자 평가, 인수시험, 시범운영, 업무성과는 확인 자료다. 같은 시험도 어떤 기준으로 판단하느냐에 따라 두 질문에 모두 일부 답을 줄 수 있지만, 기준 자체는 구분한다.

요구를 쓸 때 성공척도와 수용환경을 정하고, 요구–설계–구현–시험 결과를 추적한다. 배포할 때는 성능, 오류, 보안사건, 사용행동, 업무가치를 볼 지표·로그·추적정보를 준비하고, 경보와 담당자, 복구행동도 함께 정한다. 운영 결과를 목표와 비교해 결함, 잘못된 가정, 환경 변화, 측정문제를 나누고, 다음 요구·설계·운영 변경으로 보낸 뒤 다시 검증·확인한다.

시험 통과 수가 많아도 시험하지 않은 조건에 결함이 없다는 증명은 되지 않는다. 운영자료를 모아도 조치와 재측정이 없으면 피드백이 아니다. 그래서 실제 권한·부하·데이터와 경계조건을 대표하는 시험, 평균과 분포, 사용자 영향과 잔여위험을 함께 본다. 그리고 각 차이에 소유자와 판단기준, 마감조건을 붙여 폐루프로 관리한다.

자체 25점 문제

주문 취소 기능의 요구·설계·시험·운영 증거를 연결해 검증·확인·운영 피드백을 폐루프로 관리하는 품질확보 절차를 설계하시오.

요구어는 설계다. 시험 통과를 품질의 끝으로 보지 않고, 실제 사용조건과 업무가치에서 얻은 결과가 다음 변경과 재검증으로 돌아오게 한다.

25점 풀이 방향과 모범답안 보기

25점 답안 목차

1. 필요·요구·수용기준
2. 설계·구현 추적
3. 검토·정적분석·수준별 시험
4. 사용자·인수·시범운영 확인
5. 운영 지표·로그·추적정보
6. 목표 대비 차이와 원인분석
7. 결함·가정·환경·측정 문제 분류
8. 변경·재검증·재확인·재측정

25점 답안 도식

필요를 요구·설계·구현·검증에 연결한 뒤 실제 필요를 채우는지 확인한다. 운영 결과에 나타난 차이의 원인을 분석해 다시 변경하고, 그 결과는 다시 필요·요구와 검증·확인으로 돌아간다. 취소 사례 그림과 아래 상태별 재시험·문의율 재측정을 함께 사용해 순환이 닫혔는지 판단한다.

25점 모범답안

주문 취소의 사용자 필요와 업무규칙을 검증 가능한 요구·수용기준으로 만들고, 설계결정과 구현변경, 시험 결과에 연결해 추적한다. 검토와 정적분석, 단위·통합·시스템시험으로 명세대로 만들었는지 검증한다. 그리고 사용자 평가와 인수, 시범운영으로 실제 취소 목적과 사용환경의 필요를 만족하는지 확인한다.

배포 전에는 지표·로그·추적정보와 담당자를 준비한다. 관찰할 항목은 취소 성공률, 오류, 응답시간, 권한 거부, 문의 이유, 업무처리시간이다. 운영 결과는 목표와 비교해 결함인지, 잘못된 요구·설계 가정인지, 환경 변화나 측정 문제인지 구분한다.

차이마다 소유자와 판단기준, 마감조건을 붙여 개선하고, 영향받은 시험을 다시 실행한다. 실제 사용자 시나리오와 운영지표도 다시 확인한다. 시험 통과 개수나 대시보드 수집만으로 완료를 선언하지 않으며, 행동과 재측정까지 이어져야 폐루프가 된다.

이 사례에서는 취소 상태표와 안내를 함께 시험한다. 미출고 이용자 4/10의 오해를 보고 안내를 고치고, 재시험에서 10/10이 올바른 동작을 고르는 것과 기존 API의 상태·권한 회귀 통과를 제한 적용 조건으로 둔다. 운영 담당자는 같은 상태·기간 정의로 문의율을 다시 확인하고, 오해가 남으면 요구와 안내를 다시 고친다.

출처와 적용 경계

검증·확인, 추적성과 운영 피드백은 안정된 소프트웨어 품질 기초개념이다. 주문 취소 사례는 자체 교육 시나리오이며 특정 테스트 표준의 전체 적합성이나 운영 KPI 기준을 뜻하지 않는다.

자기교정과 조건 변경

조건을 바꿔 보자. 명세가 틀렸는데 구현은 그 명세를 정확히 지켰다면 검증은 통과할 수 있지만 확인은 실패한다. 그러므로 요구를 고치고 영향범위를 다시 검증한다. 운영 오류율은 낮은데 문의가 급증한다면 기술결함만 찾지 말고 사용성과 업무규칙, 안내, 측정정의를 확인한다.

긴급 수정으로 일부 시험을 생략했다면 생략한 범위와 잔여위험을 기록하고, 후속 검증을 누가 언제까지 할지 명시한다.

30초 정리

1. 검증은 명세·설계·표준대로 올바르게 만들었는지, 확인은 실제 필요한 것을 만들었는지 묻는다.
2. 두 질문은 기준과 증거가 다르므로 모두 수행하고 요구부터 시험까지 추적한다.
3. 운영 피드백은 실제 성능·장애·사용·가치 증거를 다음 변경에 돌리는 닫힌 순환이다.
4. 시험 개수와 지표 개수보다 위험 대표성, 실제 맥락, 행동 책임과 재측정이 중요하다.