표준 용어와 실무 용어 정렬

학습 목표

이 모듈 한 줄 요약 — "같은 일을 서로 다른 이름으로 부르고 있다". 새 기법을 배우지 않는다. 이미 하고 있는 일의 이름을 바로잡는다. 우리가 "호환성 테스트" 라고 부르는 것이 표준에서는 다른 이름이고, 그 차이가 성적서와 계약서에서 문제가 된다. 말이 맞아야 문서가 맞는다.

이 모듈은 새로운 기법을 가르치지 않는다. 이미 하고 있는 일의 이름을 바로잡는다.

우리는 매일 "호환성 테스트를 했다", "버그를 등록했다", "우선순위를 Critical로 올렸다"고 말한다. 세 문장 모두 표준의 좌표계에서는 어긋나 있다. 크로스 브라우저 검증은 표준이 말하는 호환성이 아니고, 등록한 것은 버그가 아니라 결함이며, Critical은 우선순위가 아니라 심각도의 값이다.

이 어긋남은 평소에는 아무 문제가 없다. 문제가 되는 순간은 정해져 있다 — 시험성적서를 쓸 때, 계약서의 품질 요구를 해석할 때, 인증 심사를 받을 때, 그리고 결함 리포트를 두고 팀이 서로 다른 것을 믿을 때 다.

이 모듈을 마치면 실무 표현을 표준 좌표로 옮길 수 있고, 반대로 표준 용어를 팀이 쓰는 말로 통역할 수 있다. 그리고 어느 쪽도 포기하지 않는 표기 방식 — 분류는 표준을 따르고 항목명에는 실무 용어를 병기하는 법 을 익힌다.

완료 후 할 수 있는 것

• ISO/IEC 25010의 호환성 주특성이 공존성·상호운용성 둘뿐이라는 것과, 각각의 정의·검증 항목을 설명할 수 있다
• 크로스 브라우저·디바이스 검증이 왜 호환성이 아니라 적응성(Adaptability)인지 설명하고, 오분류가 만드는 구체적 문제를 댈 수 있다
• 2023년 2판 개정으로 8특성이 9특성이 되고 이식성이 유연성으로, 사용성이 상호작용성으로 바뀐 것을 알고 기존 지식을 갱신할 수 있다
• 우리 조직이 어느 판(2011 / 2023)을 기준으로 삼는지 정하고, 문서에 명시할 수 있다
• ISO/IEC 25023의 측정량으로 품질 특성을 숫자로 옮기고, 성적서에 등재할 시험항목명을 지을 수 있다
• 오류(error)·결함(defect)·실패(failure)·이상(anomaly)·버그를 구분해 쓰고, 리포트에서 정확한 대상을 가리킬 수 있다
• IEEE 1044가 심각도와 우선순위를 왜 별도 속성으로 두는지 설명할 수 있다
• Jira의 기본 우선순위 스킴이 만든 혼동을 진단하고, 심각도 필드를 분리하는 재설계안을 제시할 수 있다
• 심각도→우선순위 제안 매트릭스를 만들어 트리아지를 빈 칸에서 시작하지 않게 만들 수 있다
• 팀 용어집과 실무어↔표준어 매핑표를 만들고, 기존 문서·템플릿·대시보드를 점진적으로 정렬할 수 있다

채용시장에서의 위치

용어를 정확히 쓰는 것은 경력 구간에서 가장 빨리 눈에 띄는 신호 다. 면접에서 "호환성 테스트 경험이 있나요"라는 질문에 "크로스 브라우저를 했습니다"라고만 답하는 사람과, "실무에서 그렇게 부르는 건 표준 분류로는 적응성이고, 표준이 말하는 호환성은 공존성과 상호운용성입니다"라고 답하는 사람은 같은 경험을 말해도 다르게 들린다.

실질적인 수요처는 셋이다. 시험인증 기관과 공인시험 대응 조직 은 성적서 항목명을 표준 분류로 등재해야 하므로 이 능력이 직무 그 자체다. 공공 SI와 제안서 대응 에서는 RFP의 품질 요구를 해석하고 검증 계획으로 옮기는 데 쓰인다. 규모가 커진 조직의 QA 리드 는 결함 관리 필드와 용어를 정리하는 일을 맡게 되는데, 그때 근거로 삼을 표준을 알고 있어야 "내 취향"이 아니라 "표준이 이렇다"로 설득할 수 있다.

일반 제품 팀에 있다면 당장의 효용은 결함 리포트와 트리아지의 마찰 감소 다. 심각도와 우선순위를 한 필드에 섞어 쓰는 팀은 매 스프린트마다 같은 논쟁을 반복한다. 필드를 나누는 것만으로 그 논쟁이 사라진다. 이건 도구 설정 한 번으로 팀 전체의 시간을 되찾는, 드물게 효율이 좋은 개선이다.