용어가 어긋나는 지점 — 실무어와 표준어 사이

개념

세 문장이 전부 어긋나 있다

어제 스탠드업에서 이렇게 말했다고 하자.

"어제 호환성 테스트 돌렸고요, 버그 세 개 등록했습니다. 그중 하나는 우선순위를 Critical 로 올렸어요."

세 표현 모두 팀 안에서는 완벽히 통한다. 그리고 세 표현 모두 표준의 좌표계에서는 어긋나 있다.

이게 틀렸다고 말하려는 게 아니다. 실무 용어는 실무에서 잘 작동한다. 문제는 이 말들이 팀 밖으로 나갈 때 생긴다.

간극이 비용이 되는 네 순간

용어 차이가 평소에는 무해하다가 갑자기 비싸지는 순간이 있다.

① 시험성적서를 쓸 때. 성적서의 시험항목은 표준 분류를 따라 등재한다. "호환성 시험"이라고 적어놓고 실제 수행한 것이 브라우저별 렌더링 확인이면, 심사에서 항목과 내용이 일치하지 않는다 는 지적을 받는다. 모듈 25 레슨 7에서 다룬 KOLAS 공인성적서처럼 형식이 엄격한 문서일수록 그렇다.

② 계약서·RFP의 품질 요구를 해석할 때. 발주처가 "ISO/IEC 25010 호환성 요구사항을 만족할 것"이라고 썼다. 이 문장이 요구하는 것은 공존성과 상호운용성이다. 브라우저 호환을 아무리 잘 해도 이 조항은 충족되지 않는다. 반대로 우리가 그렇게 썼다면, 우리가 원한 것을 납품받지 못한다.

③ 인증·심사를 받을 때. 심사원은 표준 용어로 묻는다. "상호운용성은 어떻게 검증하셨습니까"라는 질문에 브라우저 테스트 결과를 내밀면 대화가 겉돈다.

④ 팀 안에서 서로 다른 것을 믿을 때. 이건 매일 일어난다. QA가 "Critical"이라고 적은 것은 "시스템이 이만큼 망가진다"는 뜻인데, PM은 "지금 당장 고쳐야 한다"로 읽는다. 두 사람이 같은 필드를 보면서 다른 것을 믿는다. 레슨 7에서 이 문제만 따로 다룬다.

왜 이런 어긋남이 생기는가

원인을 알면 어느 용어를 의심해야 할지 감이 잡힌다.

원인 ① — 도구가 먼저 가르쳤다. 많은 사람이 표준보다 Jira를 먼저 배웠다. Jira의 기본 우선순위 값이 Blocker·Critical·Major·Minor·Trivial이니 "우선순위란 이런 것"이라고 학습된다. 도구의 기본값이 사실상 교과서 역할을 해버린 것 이다.

원인 ② — 일상어가 이미 있다. '호환된다'는 일상어다. "이 사이트 사파리에서 호환 안 돼요"라는 말은 자연스럽다. 표준이 그 단어를 다른 뜻으로 정의해도, 일상어의 힘이 더 세다.

원인 ③ — 번역이 겹친다. Compatibility도 호환성, Interoperability도 맥락에 따라 호환성으로 옮겨진다. Portability는 이식성인데 "옮겨 심는다"는 뉘앙스가 브라우저 이야기와 잘 안 붙는다.

원인 ④ — 표준이 개정된다. 이건 특히 성가시다. 2011년에 배운 8개 특성이 2023년 2판에서 9개가 되고 이름도 바뀌었다. 정확히 알고 있던 사람이 어느 날 갑자기 옛 용어를 쓰게 된다. 레슨 2에서 다룬다.

이 모듈의 결론을 먼저 말한다

어느 한쪽을 버리는 것은 답이 아니다. 표준 용어만 쓰면 팀이 못 알아듣고, 실무 용어만 쓰면 문서가 밖에서 안 통한다.

분류는 표준을 따르고, 항목명에는 실무 용어를 괄호로 병기한다.

이 한 줄이 모듈 전체의 결론이다. 실제 적용은 이렇게 생겼다.

[시험성적서 항목 등재 예]
 
  ✗  호환성 시험
  ✗  크로스 브라우저 테스트
  ✓  이식성 – 적응성 (크로스 브라우저·디바이스 호환성 시험)
       └ 분류는 표준      └ 항목명에 실무 용어 병기

분류 칸은 심사원과 계약서가 읽고, 괄호 안은 개발팀과 고객이 읽는다. 한 줄로 두 독자를 만족시키는 방법 이 이것이다.

미리 보는 매핑표

이 모듈이 다루는 세 가지 어긋남을 한 표로 미리 본다. 각각은 레슨 3·4·6·7에서 자세히 다룬다.

용어를 고칠 때의 현실적 원칙 셋

1. 대외 문서부터 고친다. 성적서·제안서·계약서·인증 산출물이 우선 순위다. 여기가 비용이 발생하는 곳이다. 팀 내부 슬랙 대화까지 교정하려 들면 아무도 안 따라온다.

2. 실무 용어를 금지하지 않는다. "버그라고 하지 마세요"라고 하면 반발만 산다. "문서에서는 결함으로 적자" 는 받아들여진다. 말과 글을 분리하는 것이 현실적이다.

3. 판(edition)을 명시한다. 표준 용어를 쓰기로 했다면 어느 판인지 적는다. ISO/IEC 25010:2011 과 ISO/IEC 25010:2023 은 특성 이름이 다르다. 판 없이 "25010 기준"이라고만 쓰면 몇 년 뒤 그 문서를 읽는 사람이 헷갈린다.

어긋남을 발견하는 가장 값싼 방법

용어 점검을 거창하게 시작할 필요가 없다. 같은 단어를 두 사람에게 따로 묻는 것으로 충분하다.

질문  "성능 테스트를 했다" 는 말은 구체적으로 무엇을 확인한 것인가?
 
개발자  응답 시간을 쟀다
QA      부하를 걸고 처리량을 봤다
기획자  느리지 않다는 것을 확인했다

세 답이 다르면 그 용어는 팀 안에서도 정렬돼 있지 않다. 대외 문서로 나가기 전에 이미 어긋나 있는 것이다.

이 방법의 장점은 비용이 질문 하나이고, 결과가 누구의 잘못도 아닌 형태로 드러난다는 것이다. "당신이 틀렸다" 가 아니라 "우리가 같은 말을 다르게 쓰고 있다" 가 되므로 교정 제안이 받아들여진다(모듈 6 레슨 3).

용어가 어긋나도 괜찮은 자리와 안 괜찮은 자리

고칠 곳을 좁히려면 어디가 안 괜찮은지를 먼저 알아야 한다.

아래 세 줄이 전부다. 그리고 공통점이 있다 — 읽는 사람이 우리 맥락을 모르는 자리다. 용어 정렬의 범위를 정하는 기준이 "중요한 문서" 가 아니라 "맥락을 공유하지 않는 독자가 읽는가" 인 것이다.

사례 — "호환성 시험 완료" 가 보완 요구를 받은 일

공공 사업 산출물로 시험성적서를 냈다. 시험항목에 "호환성 시험" 이 있었고, 내용은 브라우저 4종·모바일 2종에서 화면과 기능을 확인한 것 이었다. 실제로 꼼꼼히 했고 결함도 잡았다.

심사에서 보완 요구가 왔다.

세 지적 모두 "시험을 안 했다" 가 아니었다. 한 건은 이름이 틀렸고, 한 건은 계약서가 요구한 것을 오해해 아예 안 했고, 한 건은 판정 기준이 없었다.

두 번째가 비용이 컸다. 계약서의 "ISO/IEC 25010 호환성 요구사항" 이 무엇을 뜻하는지 착수 시점에 확인하지 않아서, 연동 시험을 계획에 넣지 않은 채 18개월이 지났다. 외부 시스템 협조가 필요한 시험이라 급하게 할 수도 없었다.

보완에 6주가 걸렸고, 그중 대부분이 연계 기관 협조 일정을 잡는 시간 이었다.

그 뒤 바꾼 것은 착수 시점의 한 줄 질문이다.

계약서·RFP에 품질 특성 이름이 나오면, 그 이름이 어느 판의 어느 특성인지 발주처에 확인한다.

질문 하나의 비용은 메일 한 통이고, 안 물었을 때의 비용은 6주와 연계 기관 협조였다.

교훈이 셋이다.

• 이름이 틀린 것보다 "그 이름이 요구한 것을 안 한 것" 이 비싸다 — 전자는 문서 수정이고 후자는 없는 시험을 새로 하는 일이다
• 용어 확인은 착수 시점의 질문이다. 모듈 28 레슨 1의 "규격 적용 계획 한 장" 과 같은 자리에서 한다
• 외부 협조가 필요한 시험은 급하게 할 수 없다 — 그래서 용어 오해가 일정 리스크로 직결된다

어느 용어부터 의심할지 — 세 가지 신호

용어를 전부 점검할 수는 없다. 의심할 가치가 있는 것을 고르는 신호가 셋이다.

첫 줄이 가장 위험하다. 아무도 의심하지 않기 때문이다. "성능 테스트를 했다" 는 말에 응답 시간만 본 것과 자원 효율까지 본 것이 섞여 있는데, 둘 다 자기가 맞다고 믿는다.

실용적인 확인 방법이 하나 있다 — 그 단어를 쓰는 사람에게 "구체적으로 무엇을 확인한 것인가" 를 묻는 것이다. 대답이 사람마다 다르면 그 용어는 정렬이 필요하다.

용어를 정렬하는 순서

한꺼번에 바꾸면 실패한다. 순서가 있다.

2번에서 대상이 크게 줄어든다. 어긋난 용어가 스무 개여도 계약·인증에 걸린 것은 세 개 정도다. 나머지는 팀 안에서 잘 작동하므로 그대로 둔다.

그리고 4번이 가장 효율적인 지점이다. 사람을 교육하는 대신 템플릿의 빈칸 이름을 바꾸면 다음 문서부터 자동으로 정렬된다(모듈 7 레슨 7의 "템플릿으로 빈칸을 보이게" 와 같은 원리).

실무에서 왜 필요한가

성적서 반려를 막는다

공인 성적서나 인증 산출물에서 시험항목명과 실제 시험 내용의 불일치 는 가장 흔한 보완 요구 사유 중 하나다. 항목을 표준 분류로 정확히 잡아두면 이 왕복이 사라진다. 한 번 반려되면 재작성·재제출에 수 주가 든다.

RFP를 정확히 읽는다

공공 SI 제안서의 품질 요구에 25010 특성 이름이 그대로 등장하는 경우가 많다. "호환성"이라고 적힌 항목이 실제로 무엇을 요구하는지 정확히 알면 견적과 계획이 달라진다. 상호운용성 검증은 외부 시스템 협조가 필요한 일이라 비용 구조가 브라우저 테스트와 완전히 다르다.

검색과 학습이 정확해진다

표준 용어를 알면 규격 문서와 논문에서 원하는 내용을 바로 찾는다. "크로스 브라우저"로는 25023의 측정량을 찾을 수 없지만 "adaptability measures"로는 찾는다.

팀의 반복 논쟁이 줄어든다

심각도·우선순위를 분리하지 않은 팀은 매 트리아지마다 "이게 왜 Critical이냐"는 대화를 반복한다. 축이 둘로 나뉘면 그 대화가 "심각도는 Critical, 우선순위는 P3"로 한 번에 끝난다.

채용시장에서의 위치

용어 정렬은 공고에 적히지 않는 능력이지만, 면접에서는 표준을 실제로 써 본 사람인지가 바로 드러나는 주제다.

첫 번째가 가장 변별력이 크다. 면접관의 질문 자체가 실무 용어로 오는데, 되묻는 답이 가장 강하다 — 아는 척이 아니라 비용 구조가 다르다는 실질적 이유를 대기 때문이다.

네 번째도 좋다. 전면 교정을 하지 않겠다는 답이 오히려 실무 감각으로 읽힌다. 용어 통일을 시도해 본 사람은 그것이 반발을 산다는 것을 안다.

공고 표현으로는 "품질 표준 이해", "시험성적서 작성", "RFP·제안 대응", "인증 산출물 관리" 가 이 레슨에 걸린다. 그리고 발주처·심사원과 대화하는 자리에서는 이 능력이 바로 눈에 띈다.

실습 과제

과제 1 — 우리 팀의 어긋난 용어 찾기

최근 2주치 결함 리포트·테스트 계획서·회의록에서 다음을 센다.

"대외 문서에 쓰였는가" 칸이 핵심이다. 여기에 표시된 것만 고치면 된다. 나머지는 급하지 않다.

과제 2 — 성적서 항목명 다시 짓기

우리가 최근 수행한 테스트 활동 5개를 골라 본문의 병기 형식으로 항목명을 다시 짓는다.

표준 분류 – 부특성 (실무 용어 병기)

예시를 하나 채워두고 나머지를 직접 해본다.

과제 3 — RFP 문장 해석하기

아래 문장이 실제로 요구하는 것이 무엇인지, 그리고 우리가 준비해야 할 시험이 무엇인지 적는다.

"제안 시스템은 ISO/IEC 25010의 호환성 요구사항을 충족하여야 하며, 기 구축된 대내외 시스템과의 연계에 문제가 없어야 한다."

힌트: 앞 절과 뒤 절이 같은 것을 말하는가, 다른 것을 말하는가? (정답은 레슨 3에서 확인한다.)

과제 4 — 판 명시 규칙 정하기

우리 조직이 문서에서 25010을 인용할 때 어느 판을 기준으로 할지 정하고, 그 근거를 세 줄로 적는다. 고려할 것:

• 계약·인증에서 요구하는 판이 있는가
• 참조하는 측정 표준(25023)이 어느 판 기준인가
• 기존 문서가 어느 판으로 쓰여 있는가

이 결정은 레슨 2를 읽고 나서 확정해도 된다.

자가 체크리스트

• 실무 용어와 표준 용어가 어긋나는 대표 사례 세 가지를 말할 수 있다
• 그 간극이 비용이 되는 네 가지 순간을 설명할 수 있다
• 어긋남이 생기는 네 가지 원인을 댈 수 있다
• "분류는 표준, 항목명은 실무 용어 병기" 원칙을 예시로 보일 수 있다
• 대외 문서부터 고친다는 우선순위의 근거를 설명할 수 있다
• 실무 용어를 금지하지 않고 말과 글을 분리하는 접근의 이유를 안다
• 표준을 인용할 때 판(edition)을 명시해야 하는 이유를 설명할 수 있다
• RFP의 "호환성" 요구가 무엇을 뜻하는지 판단하려면 무엇을 확인해야 하는지 안다

흔한 실수

용어 교정을 전면전으로 벌인다. 슬랙에서 누가 "버그"라고 할 때마다 정정하면 팀이 피로해지고, 정작 중요한 대외 문서는 그대로 남는다. 고칠 곳을 좁히는 것이 성공의 조건이다.

실무 용어를 문서에서 완전히 지운다. 표준 분류만 적힌 성적서는 정작 그 시험을 의뢰한 고객이 무엇을 시험했는지 못 알아본다. 병기가 답이다.

판을 안 적고 표준 이름만 쓴다. "25010 기준 8대 품질 특성"이라고 적힌 문서는 2023년 이후에는 그 자체로 옛 판을 가리키는데, 읽는 사람은 모른다.

표준 용어를 아는 것을 지식 자랑으로 쓴다. "그건 호환성이 아니라 적응성입니다"라고 회의에서 지적하는 것 자체는 아무 가치를 만들지 않는다. 그 구분이 성적서나 견적을 어떻게 바꾸는지 를 함께 말해야 설득이 된다.

번역어 하나만 보고 매핑한다. Compatibility와 Interoperability가 문헌에 따라 둘 다 "호환성"으로 옮겨지는 경우가 있다. 원어와 규격 번호를 함께 확인 하는 습관이 필요하다.

참고 자료

• ISO/IEC 25010 — 제품 품질 모델. 특성·부특성의 정의가 나오는 1차 자료. 판(2011 / 2023)을 확인하고 인용한다
• ISO/IEC/IEEE 24765 — 시스템·소프트웨어 공학 어휘. 결함·오류·실패 등 용어의 표준 정의를 찾는 사전
• ISTQB 용어집(Glossary) — 테스트 용어의 한국어 대역어까지 확인할 수 있다. 실무 문서 작성 시 참조하기 좋다
• 모듈 25 레슨 2 ISO/IEC 25010 — 8대 품질 특성을 검증 항목으로 옮기기 — 특성별 검증 항목 표. 이 모듈은 그 위에 '이름 붙이기' 층을 얹는다
• 모듈 25 레슨 7 시험성적서의 세 얼굴 — 항목명 등재가 실제로 문제가 되는 문서들
• 모듈 6 레슨 1 결함 생명주기와 심각도·우선순위 — 두 축의 실무적 구분. 레슨 7에서 표준 근거와 필드 설계로 확장한다

이 커리큘럼 안에서

• 모듈 30 레슨 2 — 25010 개정. 판이 바뀌면 무엇이 어긋나나
• 모듈 30 레슨 3~4 — 호환성 vs 적응성. 이 레슨의 핵심 어긋남을 각각 깊이
• 모듈 30 레슨 5 — 측정량과 성적서 항목명
• 모듈 30 레슨 6 — 버그·결함·이상
• 모듈 30 레슨 7 — 심각도·우선순위 필드 설계
• 모듈 30 레슨 8 — 팀 용어집과 이행. 이 레슨의 순서가 거기서 체계가 된다
• 모듈 25 레슨 2 — 25010 특성별 검증 항목
• 모듈 25 레슨 7 — 시험성적서의 세 얼굴
• 모듈 28 레슨 1 — 착수 2주 안의 규격 적용 계획. 용어 확인이 거기 들어간다
• 모듈 28 레슨 2 — 적합성·상호운용성 시험
• 모듈 6 레슨 1 — 심각도·우선순위의 실무적 구분
• 모듈 7 레슨 7 — 템플릿으로 빈칸을 보이게 만드는 원리

한 줄 정리 — 실무어와 표준어는 어긋나 있고, 그 간극은 팀 밖으로 나갈 때 비용이 된다. 어느 한쪽을 버리지 않는 답은 분류는 표준을 따르고 항목명에 실무 용어를 괄호로 병기하는 것이다. 고칠 곳은 대외 문서로 좁히고, 사람을 교육하는 대신 템플릿의 이름을 바꾼다. 그리고 가장 비싼 실수는 이름이 틀린 것이 아니라 그 이름이 요구한 시험을 아예 안 한 것이다 — 그래서 용어 확인은 착수 시점의 질문이다.