검증과 검정의 차이: Verification·Validation을 실무에서 구분하는 법
검증은 정해 둔 기준과 요구사항에 맞게 만들었는지 살피는 일이고, 검정은 만든 결과가 실제 사용자의 목적을 이루는지 확인하는 일입니다. 두 단어를 섞어 쓰기 쉬운 이유와 판단 순서를 사례 중심으로 정리합니다.
1. 먼저 두 단어가 헷갈리는 이유
검증과 검정은 모두 결과를 확인한다는 뜻으로 들립니다. 영어로는 verification과 validation이 대응되지만, 한국어 현장에서는 둘 다 ‘검증’이라고 부르는 경우도 많습니다. 품질 관리, 소프트웨어, 연구, 행정 문서마다 번역 관습이 달라서 같은 회의에서도 한 사람이 말한 검증이 다른 사람에게는 검정으로 들릴 수 있습니다. 그래서 단어 자체를 외우기보다 무엇을 기준으로 무엇을 판단하는지 먼저 꺼내 놓는 편이 안전합니다. 용어가 다르더라도 질문이 분명하면 업무의 방향은 흔들리지 않습니다.
가장 흔한 오해는 둘 중 하나가 더 엄격하고 다른 하나는 가벼운 확인이라는 생각입니다. 실제 차이는 강도가 아니라 관점에 있습니다. 검증은 이미 합의한 명세, 규칙, 도면, 계산식, 법정 기준을 출발점으로 삼습니다. 검정은 그 결과물이 사용자, 고객, 현장, 시장에서 기대한 쓸모를 내는지 살핍니다. 전자는 약속한 설계에 충실했는지를 보고, 후자는 그 설계가 문제를 제대로 풀었는지를 봅니다. 둘은 경쟁 관계가 아니라 서로 다른 빈틈을 막는 짝입니다.
번역어에만 기대면 혼란이 커질 수 있으므로 문서 첫머리에 영어 원어와 운영 정의를 함께 적는 방법이 좋습니다. 예를 들어 ‘이 문서에서 검증은 요구사항 충족 여부 확인, 검정은 사용 목적 충족 여부 확인을 뜻한다’고 한 줄 써 두면 참여자가 같은 기준으로 대화할 수 있습니다. 외부 규격이나 계약서가 특정 용어를 정의한다면 그 정의를 우선해야 합니다. 내부에서 편한 표현을 쓰더라도 납품 기준이나 인증 기준을 임의로 바꾸면 안 됩니다.
2. 검증과 검정의 가장 짧은 정의
검증은 ‘우리가 만들겠다고 한 것을 올바르게 만들었는가’에 답하는 절차입니다. 요구사항에 적힌 기능이 구현됐는지, 입력값 제한이 문서와 같은지, 화면 문구가 승인된 문안과 일치하는지처럼 비교할 기준이 먼저 존재합니다. 검사표, 코드 리뷰, 도면 대조, 자동 테스트, 계산 재확인이 대표적인 방법입니다. 이때 결과는 대체로 통과와 미통과, 일치와 불일치처럼 비교적 선명하게 기록할 수 있습니다.
검정은 ‘우리가 만든 것이 올바른 문제를 해결하는가’에 답하는 절차입니다. 사용자가 실제로 예약을 끝낼 수 있는지, 직원이 바쁜 시간에도 절차를 이해하는지, 새 포장재가 배송 중 제품을 지키는지처럼 현실의 목표가 판단 기준이 됩니다. 관찰, 사용자 인터뷰, 현장 시험, 시범 운영, 고객 문의 분석이 자주 쓰입니다. 요구사항을 모두 만족한 제품도 사용자가 어려워하면 검정 단계에서 개선 신호가 나올 수 있습니다.
따라서 검증을 통과했다고 해서 검정까지 끝난 것은 아닙니다. 반대로 검정에서 만족스러운 반응을 얻었다고 해도 안전 규격이나 계약 조건을 건너뛸 수는 없습니다. 기능이 명세에 맞지만 고객이 찾지 못하는 버튼일 수 있고, 고객은 좋아하지만 개인정보 처리 기준을 지키지 못한 서비스일 수도 있습니다. 좋은 팀은 두 질문을 순서대로 두고, 어느 질문에 대한 증거인지 결과물에 표시합니다.
3. 기준·질문·증거로 비교하기
두 과정을 구분하는 가장 쉬운 틀은 기준, 질문, 증거 세 가지입니다. 검증의 기준은 요구사항, 설계서, 체크리스트, 법규, 계산 규칙처럼 사전에 정한 문서입니다. 질문은 ‘이 항목이 문서대로 구현됐나’가 됩니다. 증거는 테스트 로그, 측정값, 검토 기록, 버전 이력처럼 재현 가능한 자료가 적합합니다. 누가 보아도 같은 기준을 따라 판단할 수 있도록 조건과 결과를 남기는 것이 중요합니다.
검정의 기준은 사용 맥락과 성공 기준입니다. 질문은 ‘이 결과가 실제 상황에서 목표를 달성하게 하나’가 됩니다. 증거는 과업 완료율, 소요 시간, 오류 경험, 재구매 의도, 현장 관찰, 인터뷰 발화처럼 사람과 환경의 반응을 담습니다. 숫자만으로 부족할 때가 많으므로, 사용자가 어디에서 멈췄는지와 왜 그렇게 행동했는지도 함께 기록해야 합니다. 검정은 정답 한 줄을 찾기보다 위험한 가정을 찾아내는 과정에 가깝습니다.
회의에서 논쟁이 생기면 ‘어느 기준에 비춰 본 결론인가’라고 되물어 보세요. 승인된 화면 설계와 다르다는 말은 검증 이슈이고, 설계대로 만들었지만 처음 쓰는 사람이 이해하지 못한다는 말은 검정 이슈입니다. 이 구분이 되면 담당자도 선명해집니다. 문서 불일치는 설계·개발·품질 담당자가 바로 고칠 수 있고, 사용성 문제는 기획·디자인·운영 담당자와 함께 원인을 다시 살펴야 합니다.
4. 문서와 설계에서 하는 검증
검증은 완성 직전에만 하는 일이 아닙니다. 요구사항 문서가 모호하지 않은지, 화면 흐름이 빠진 곳은 없는지, 데이터 항목 이름이 서로 다르지 않은지 확인하는 것도 검증의 일부입니다. 초기에 발견한 불일치는 수정 비용이 작습니다. 예를 들어 회원 가입 화면에 필요한 동의 항목이 정책 문서에는 있지만 개발 티켓에는 없다면, 코드를 쓰기 전에도 대조표로 문제를 찾을 수 있습니다.
소프트웨어에서는 단위 테스트, 통합 테스트, 코드 리뷰, 접근성 점검, 보안 점검이 검증의 도구가 될 수 있습니다. 다만 도구를 실행했다는 사실만으로 충분하지는 않습니다. 각 테스트가 어떤 요구사항을 확인하는지 연결해야 합니다. ‘버튼 클릭 테스트 성공’보다 ‘비밀번호 재설정 요청 후 안내 메일을 5분 안에 발송한다는 요구사항을 확인’이라고 적으면 결과의 의미가 분명해집니다. 실패했을 때도 기능 이름이 아니라 위반한 기준을 기록하면 재작업 우선순위를 정하기 쉽습니다.
제조와 운영에서도 원리는 같습니다. 도면의 치수, 자재 사양, 포장 수량, 점검 주기, 안전 표지를 기준 문서와 대조합니다. 측정 장비의 교정 상태와 측정 조건을 함께 남겨야 나중에 결과를 믿을 수 있습니다. 검증 기록은 누군가를 감시하기 위한 종이가 아니라, 같은 제품을 다시 만들고 문제가 생겼을 때 원인을 좁히기 위한 지도입니다. 기준이 바뀌면 이전 기록을 억지로 맞추지 말고 버전과 적용 시점을 구분해야 합니다.
5. 실제 사용 장면에서 하는 검정
검정은 회의실에서 상상한 사용자가 아니라 실제 사용 조건을 만나게 합니다. 예약 서비스라면 처음 방문한 사람이 휴대폰으로 원하는 날짜를 고르고 결제까지 마칠 수 있는지 봅니다. 교육 자료라면 학습자가 설명을 읽은 뒤 스스로 문제를 풀 수 있는지 확인합니다. 안내 표지라면 급한 상황의 사람이 멈추지 않고 올바른 방향을 찾는지 관찰합니다. 설계자는 익숙해서 놓치기 쉬운 장애물을 검정이 드러냅니다.
검정의 참여자는 목표 사용자를 대표해야 합니다. 사무용 시스템을 개발자가 시험하면 기능은 잘 찾지만 실제 현장 직원의 손이 멈추는 지점은 놓칠 수 있습니다. 표본이 작더라도 사용 맥락이 맞고 관찰 질문이 명확하면 유용한 신호를 얻습니다. ‘좋았나요’처럼 넓은 질문보다는 ‘어느 단계에서 다음 행동을 결정하기 어려웠나요’처럼 구체적으로 묻는 편이 개선에 도움이 됩니다. 참여자에게 정답을 알려 주거나 도와주기 전에 스스로 어떻게 해석하는지 지켜보는 것도 중요합니다.
검정 결과가 부정적이라고 해서 참여자가 틀린 것은 아닙니다. 사용자가 여러 명 같은 곳에서 멈췄다면, 그 지점은 제품이 설명을 더 해야 한다는 신호입니다. 물론 한 번의 반응을 곧바로 전체 사용자 의견으로 일반화해서도 안 됩니다. 관찰, 문의 기록, 사용 데이터, 운영자의 경험을 함께 보며 가설을 세우고 다시 시험합니다. 검정은 출시 전 한 번 통과하는 관문이 아니라 변화하는 현실과 계속 대화하는 방식입니다.
6. 앱 기능 사례로 구분하기
병원 예약 앱에 ‘진료과 선택, 의사 선택, 시간 선택, 예약 완료’라는 요구사항이 있다고 가정해 보겠습니다. 개발팀이 각 화면과 버튼을 요구사항 목록에 맞게 구현했고, 잘못된 전화번호 형식은 저장되지 않으며, 예약 완료 화면이 정상적으로 표시되는지 테스트했다면 이는 검증입니다. 기능이 정한 규칙대로 동작하는지 확인했기 때문입니다. 화면 간 이동과 서버 응답을 기록하면 다시 확인할 수도 있습니다.
그런데 실제 이용자가 ‘진료과를 모르겠어서 예약을 못 했다’거나 ‘예약 완료인지 대기 신청인지 구분이 안 됐다’고 말한다면 다른 문제가 보입니다. 기능 자체는 요구사항에 맞아도 사용자의 목적, 즉 적절한 진료를 빠르게 예약하는 일을 돕지 못했을 수 있습니다. 이때 처음 사용자에게 예약 과제를 맡기고 화면을 보며 생각을 말하게 하거나, 고객센터 문의 유형을 살피는 일은 검정에 해당합니다. 해결책은 버튼 오류 수정이 아니라 진료과 설명, 추천 질문, 상태 문구 개선일 수 있습니다.
이 사례에서 중요한 점은 검증과 검정이 서로의 대체물이 아니라는 것입니다. 사용성이 좋다는 반응을 얻어도 예약 시간이 중복 저장되면 안 되고, 자동 테스트가 모두 통과해도 사용자가 중요한 정보를 놓치면 서비스의 목표가 흔들립니다. 배포 전에는 요구사항별 검증 표를 먼저 마무리하고, 제한된 사용자로 검정한 뒤 발견한 문제를 다음 요구사항 개정으로 연결하면 흐름이 매끄럽습니다.
7. 제품·서비스 사례로 구분하기
보온 텀블러를 예로 들면 검증 항목은 비교적 명확합니다. 용량이 표시값과 같은지, 뚜껑을 닫았을 때 정해진 각도에서 새지 않는지, 식기세척기 사용 가능 표시가 실제 재질 조건과 맞는지, 포장 수량이 주문서와 일치하는지를 측정합니다. 여기서는 사양서와 시험 조건이 기준입니다. 시험 온도, 시간, 샘플 수를 바꾸면 결과의 의미도 달라지므로 조건을 분명히 적어야 합니다.
검정에서는 출근길 사용자가 한 손으로 뚜껑을 열 수 있는지, 가방에 넣었을 때 물이 새지 않는지, 세척이 번거롭지 않은지, 뜨거운 음료가 너무 오래 식지 않는지가 관심사가 됩니다. 사양서의 밀폐 시험을 통과한 제품도 실제 가방 안에서 눕혀졌을 때 불편을 만들 수 있습니다. 사용자는 숫자로 적힌 보온 시간보다 손이 뜨겁지 않은지, 세척 후 냄새가 남지 않는지처럼 생활 속 경험으로 제품을 평가합니다.
서비스 운영도 같습니다. 배달 주문 시스템에서 주소 형식과 결제 금액을 대조하는 일은 검증이고, 비가 오는 저녁에도 고객이 원하는 시간에 음식 상태를 이해하며 주문을 마칠 수 있는지 확인하는 일은 검정입니다. 현장은 항상 예외를 만듭니다. 주소는 맞지만 기사에게 건물 진입 정보가 부족할 수 있고, 알림은 발송됐지만 고객이 핵심 시간을 읽지 못할 수 있습니다. 검정은 이런 예외를 실패로 숨기지 않고 다음 설계의 재료로 바꿉니다.
8. 데이터와 시험에서 용어를 읽는 법
데이터 작업에서는 validation이 ‘입력값 유효성 검사’로 번역되는 경우가 많습니다. 예를 들어 생년월일 칸에 날짜가 아닌 문자가 들어오지 않게 막거나, 금액이 음수가 될 수 없는 조건을 확인하는 작업입니다. 이 표현은 제품 전체가 사용자 목적에 맞는지 보는 검정과 범위가 다를 수 있습니다. 따라서 데이터베이스 문서에서 validation이라는 단어를 만나면 먼저 입력 규칙을 뜻하는지, 전체 서비스의 적합성 확인을 뜻하는지 문맥을 확인해야 합니다.
통계와 연구에서는 ‘검정’이 가설검정처럼 더 좁은 전문 용어로 쓰이기도 합니다. 이때는 표본에서 얻은 결과가 우연으로 설명될 수 있는지를 정해진 절차로 판단합니다. 소프트웨어 품질의 validation과 글자가 같다고 해서 같은 절차라고 단정하면 안 됩니다. 연구 계획서, 시험성적서, 인증 문서에는 해당 분야의 정의와 표준이 우선합니다. 모르는 약어가 나오면 번역만 찾기보다 문서의 용어 정의 조항을 먼저 읽는 습관이 좋습니다.
인공지능 모델에서도 검증용 데이터와 테스트용 데이터를 구분해 부르는 관습이 있습니다. 여기서 검증 데이터는 학습 중 설정을 조정하는 데 쓰이고, 테스트 데이터는 최종 성능을 평가하는 데 쓰일 수 있습니다. 이 역시 일반적인 검증·검정 구분과 완전히 일치한다고 보기 어렵습니다. 분야가 바뀌면 단어의 고정된 번역보다 작업의 목적, 데이터가 쓰이는 시점, 결과로 내릴 결정이 무엇인지 세 가지를 확인해야 오해가 줄어듭니다.
9. 실무 체크리스트와 자주 묻는 질문
업무를 시작할 때는 먼저 성공 기준을 두 묶음으로 나눠 적어 보세요. 첫 묶음에는 반드시 지켜야 할 요구사항, 법규, 성능 수치, 승인 문안을 넣습니다. 두 번째 묶음에는 사용자가 이루려는 과업, 현장의 제약, 이해하기 쉬운 흐름, 만족스러운 결과를 넣습니다. 첫 묶음은 검증 계획으로, 두 번째 묶음은 검정 계획으로 연결됩니다. 각 항목에 담당자, 확인 방법, 통과 기준, 증거가 남는 위치를 붙이면 실행력이 높아집니다.
일정이 빠듯할수록 둘 중 하나를 생략하고 싶어지지만, 위험이 큰 부분만이라도 각각 확인하는 편이 낫습니다. 결제·개인정보·안전처럼 실패 비용이 큰 기능은 요구사항 기반 검증을 촘촘히 하고, 처음 쓰는 사람의 행동이 성패를 가르는 화면은 작은 규모라도 사용 검정을 합니다. 발견한 문제는 ‘버그’, ‘의견’처럼 뭉뚱그리지 말고 기준 불일치인지 목적 부적합인지 구분해 기록하세요. 그러면 수정 후 다시 무엇을 확인해야 하는지도 자연스럽게 정리됩니다.
마지막으로 팀의 용어를 한 번 합의하세요. 우리 조직에서 verification과 validation을 어떤 한국어로 표시할지, 외부 문서와 충돌할 때 무엇을 우선할지, 결과 보고서의 제목을 어떻게 쓸지 정해 두면 의사소통 비용이 줄어듭니다. 단어의 번역은 달라질 수 있어도, 기준을 충족했는지와 실제 목적을 달성했는지라는 두 질문은 계속 필요합니다. 그 두 질문에 각각 답할 증거를 남기는 것이 가장 실용적인 구분법입니다.
자주 묻는 질문
검증과 검정 중 어느 것을 먼저 해야 하나요?
보통 요구사항과 설계를 기준으로 한 검증을 먼저 진행하고, 그 결과물을 실제 사용 맥락에서 검정합니다. 다만 초기에 사용자 문제를 탐색하는 활동은 설계 전에 시작할 수 있습니다.
검정 결과가 나쁘면 요구사항도 바꿔야 하나요?
사용자가 목표를 이루지 못한 원인이 요구사항 자체의 가정에 있다면 바꿔야 합니다. 구현 오류라면 기존 요구사항에 맞게 수정한 뒤 다시 확인합니다.
작은 팀도 두 절차를 모두 해야 하나요?
규모와 무관하게 핵심 위험에는 두 질문이 필요합니다. 간단한 체크리스트와 짧은 사용자 관찰만으로도 중요한 문제를 조기에 찾을 수 있습니다.