크로스 브라우저는 적응성이다 — 이식성에서 유연성으로

개념

밀려난 항목들은 어디로 가는가

레슨 3에서 호환성 칸의 경계를 그었다. 브라우저·OS·디바이스 관련 항목이 전부 그 칸 밖으로 밀려났다. 그럼 어디로 가는가.

적응성(Adaptability) 이다.

2011판 정의로는 이렇게 읽힌다 — 제품이 서로 다른 또는 진화하는 하드웨어, 소프트웨어, 그 밖의 운용·사용 환경에 효과적이고 효율적으로 적응할 수 있는 정도. 크롬과 사파리, Android 14와 15, 태블릿과 폰은 전부 서로 다른 운용 환경 이다. 우리 제품이 그 환경들 위에서 제대로 도는가 — 정확히 적응성이 묻는 질문이다.

왜 호환성이 아닌가 — 한 번 더

레슨 3의 구분 기준을 다시 붙인다.

상대가 "다른 제품"인가?        → 호환성
   정보를 주고받는 대상이거나, 같은 자원을 다투는 이웃
 
상대가 "다른 환경"인가?        → 적응성
   우리가 그 위에 올라타 실행되는 그릇

브라우저는 우리 웹 앱이 올라타는 실행 환경 이다. 우리가 크롬에게 데이터를 보내고 크롬이 응답을 주는 관계가 아니다. 크롬이 우리를 실행한다. OS도, 기기도 마찬가지다.

이 구분이 직관에 반하는 이유는 일상어 때문이다. "이 사이트 사파리에서 호환 안 돼요"는 완벽히 자연스러운 한국어다. 표준 용어가 일상어를 이기지 못하는 전형적인 경우 이고, 그래서 이 오분류가 이렇게까지 널리 퍼졌다.

적응성의 세 갈래 — 측정 표준이 알려준다

적응성이 구체적으로 무엇을 보는지는 ISO/IEC 25023의 측정량이 잘 보여준다. 적응성 측정량은 세 갈래로 나뉜다.

각 측정량의 기본 형태는 "새 조건에서 정상 동작한 기능의 비율" 이다.

적응성 측정 = 새 환경에서 정상 동작한 기능 수 / 대상 기능 총 수

이 식이 크로스 브라우저 매트릭스와 정확히 같은 모양이라는 점 을 보면 분류가 맞다는 것이 분명해진다. 우리가 이미 만들고 있는 기능 × 브라우저 표가 곧 적응성 측정량이다.

             크롬   사파리   엣지   파이어폭스
 로그인        ✓      ✓      ✓       ✓
 결제          ✓      ✗      ✓       ✓
 파일 업로드    ✓      ✓      ✓       ✗
             ────────────────────────────
 적응성 = 10 / 12 = 83.3 %

2011 이식성 → 2023 유연성

레슨 2에서 본 변화를 이 맥락에서 다시 정리한다.

ISO/IEC 25010:2011                ISO/IEC 25010:2023
──────────────────────            ──────────────────────
이식성 (Portability)               유연성 (Flexibility)
  ├ 적응성 (adaptability)   ────→    ├ 적응성 (adaptability)
  ├ 설치성 (installability) ────→    ├ 설치성 (installability)
  └ 대체성 (replaceability) ────→    ├ 대체성 (replaceability)
                                     └ 확장성 (scalability)  ← 신설

적응성이라는 이름은 그대로이고 상위 상자 이름만 바뀌었다. 그래서 이 레슨의 결론 — "크로스 브라우저는 적응성이다" — 은 두 판 모두에서 성립한다. 다만 상위 특성을 함께 적을 때는 판에 맞춰야 한다.

2011 기준 표기:  이식성 – 적응성
2023 기준 표기:  유연성 – 적응성

확장성이 적응성에서 떨어져 나온 것도 짚고 갈 가치가 있다. 2011판에서는 "동시 사용자가 늘어나도 동작하는가"를 적응성 안에서 다뤘는데, 2023판에서는 별도 부특성이다. 크로스 브라우저(적응성)와 부하 확장(확장성)이 이제 분명히 다른 칸 이라는 뜻이다.

요청하신 매핑표

이 모듈의 핵심을 한 표로 정리하면 이렇다.

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

이식성 – 적응성 (크로스 브라우저·디바이스 호환성 시험)

왼쪽은 심사원과 계약서가 읽고, 괄호 안은 개발팀과 고객이 읽는다. 한 줄로 두 독자를 만족시킨다.

오분류가 만드는 실제 문제

"어차피 같은 테스트인데 이름이 뭐가 중요한가"라는 반문이 나온다. 구체적인 대가를 세 가지만 짚는다.

① 성적서 항목과 내용의 불일치. 호환성 시험이라고 등재하고 브라우저 스크린샷을 증거로 제출하면, 심사에서 "공존성·상호운용성 시험 결과를 제시하라"는 요구가 온다. 없다. 보완 요구로 되돌아온다.

② 요구사항 커버리지 착시. 품질 특성별로 검증 항목을 채우는 표에서 호환성 칸이 브라우저 항목으로 가득 차 있으면, 정작 진짜 호환성 (연동·공존)은 비어 있는데 채워진 것처럼 보인다. 모듈 25 레슨 2에서 "25010이 값을 만드는 순간은 빈 칸을 알아채는 순간 하나뿐"이라고 했는데, 오분류는 그 빈 칸을 가려버린다.

[오분류된 표]                      [바로잡은 표]
호환성  ████████ 항목 8개          호환성  ██ 항목 2개  ← 여기가 비었다는 게 보인다
이식성  ▒ 항목 1개                 이식성  ███████ 항목 7개

③ 견적과 일정의 오판. 브라우저 테스트는 우리 팀만으로 끝난다. 상호운용성 시험은 상대 시스템의 협조 일정 이 필요하다. 두 가지를 같은 칸에 넣으면 "호환성 시험 3일"이라는 견적이 나오고, 실제로는 연동 상대를 기다리느라 3주가 간다.

그럼 실무에서 "호환성 테스트"라고 부르지 말라는 건가

아니다. 레슨 1의 원칙이 여기서도 그대로다.

말할 때      "호환성 테스트 돌렸습니다"        → 그대로 둔다
팀 문서      "크로스 브라우저 테스트 결과"      → 그대로 둬도 된다
대외 문서    "이식성 – 적응성 (크로스 브라우저   → 병기한다
              ·디바이스 호환성 시험)"
품질 특성 표  적응성 칸에 넣는다                → 분류는 표준을 따른다

고칠 곳은 대외 문서와 품질 특성 표 둘뿐이다. 나머지는 건드리지 않는 것이 현실적이고, 그래야 실제로 정착한다.

적응성 시험이 실제로 잡는 결함의 유형

"브라우저별로 봤다" 가 무엇을 잡는 일인지 유형으로 정리해 두면 범위를 줄일 때 무엇을 포기하는지 알 수 있다.

두 번째와 네 번째가 가장 많이 빠진다. IME(한글 입력기) 관련 결함은 영문 환경에서 재현되지 않고, 화면 폭 경계는 대표 3종만 보면 그 사이의 경계를 놓친다(모듈 3의 경계값 분석이 해상도 축에 적용되는 자리다).

그래서 범위를 줄일 때 "기기 수" 를 줄이는 것과 "축" 을 버리는 것은 다르다. 기기를 5종에서 3종으로 줄이는 것은 밀도가 낮아지는 것이고, 입력 방식 축을 아예 안 보는 것은 그 유형의 결함을 구조적으로 못 잡게 되는 것이다.

적응성 범위를 정하는 것이 곧 견적이다

적응성은 "어디까지" 가 정해지지 않으면 끝이 없는 축이다. 브라우저· OS·기기·해상도·언어·네트워크를 곱하면 조합이 수천 개가 되고, 전부 보는 것은 불가능하다.

그래서 범위를 정하는 근거가 필요하고, 근거는 우리 사용자 데이터에서 온다.

"상위 N%" 를 몇 %로 잡을지가 견적이 된다. 95%와 99%의 차이가 기기 수에서 몇 배로 벌어지고, 그 결정은 QA가 혼자 할 수 없다 — 데이터를 가져가 선택지로 제시하는 것이 QA의 몫이다(모듈 26 레슨 2의 선택지 보고와 같은 구조).

그리고 정한 범위를 성적서와 계획서에 적는다. "주요 브라우저" 는 판정 불가능한 말이고, "Chrome·Safari·Edge 최근 2개 버전, 실사용 점유율 96% 기준" 은 판정 가능한 범위다.

사례 — "호환성 100% 통과" 가 운영에서 깨진 일

성적서에 "호환성 시험 100% 통과" 가 적혀 있었다. 브라우저 5종을 전부 확인했고 결함도 없었다. 출시 2주 뒤 특정 사용자군에서 결제가 안 된다는 문의가 몰렸다.

원인은 분류의 문제였다.

세 가지 모두 "호환성 시험" 이라는 한 항목에 묶여 있다고 믿었기 때문에 빠진 것이다. 첫 줄은 공존성(레슨 3)이고 뒤의 둘은 적응성 범위인데, 항목명이 하나라서 무엇을 안 봤는지 성적서에서 보이지 않았다.

바꾼 것은 항목을 셋으로 쪼갠 것이다.

기존  호환성 시험 — 통과
 
변경  호환성 – 공존성 (보안 프로그램·백신 공존 시험)        미실시 ← 드러났다
      유연성 – 적응성 (크로스 브라우저, 최근 2개 버전)        통과
      유연성 – 적응성 (기업 표준 단말·해상도)                미실시 ← 드러났다

쪼개는 순간 "미실시" 두 줄이 생겼다. 시험을 더 한 것이 아니라 원래 안 하고 있었던 것이 보이게 된 것이다. 그 두 줄이 다음 분기 계획에 들어갔고, 보안 프로그램 공존 시험에서 결제 모듈 결함 1건이 나왔다 — 운영에서 터진 것과 같은 유형이었다.

교훈이 셋이다.

• 한 항목으로 묶으면 안 본 것이 안 보인다 — 분류의 실용적 가치가 분류 자체가 아니라 공백을 드러내는 것에 있다
• "100% 통과" 는 분모가 정의되지 않은 숫자다(모듈 27 레슨 5·모듈 28 레슨 5와 같은 함정)
• 적응성은 범위를 적지 않으면 통과가 무의미하다 — 무엇을 보고 통과 했는지가 숫자보다 중요하다

실무에서 왜 필요한가

성적서가 한 번에 통과한다

시험항목명과 시험 내용의 불일치는 보완 요구의 단골 사유다. 분류를 바로잡고 병기 표기를 쓰면 이 왕복이 사라진다. 재작성·재제출에 드는 수 주를 아낀다.

진짜 비어 있는 칸이 드러난다

품질 특성별 검증 항목 표를 정직하게 채우면, 공존성 항목이 0건인 조직이 대부분 이다. 온프레미스·SDK·에이전트 제품이면 이건 실제 리스크다. 오분류를 걷어내는 순간 이 공백이 보인다.

견적의 근거가 생긴다

"호환성 시험"을 둘로 나눠 견적하면 이렇게 된다.

적응성 시험 (크로스 브라우저·디바이스)    3일   우리 팀 단독 수행
상호운용성 시험 (외부 연동 3건)          3주   상대 협조 일정에 종속
공존성 시험 (백신·모니터링 에이전트)      2일   대상 환경 확보 필요

한 줄이었을 때는 안 보이던 리스크가 분리하는 순간 보인다.

채용시장에서의 위치

이 레슨의 내용은 면접에서 실무 용어로 질문이 들어오는 대표적인 주제다. 그래서 되묻는 답이 가장 강하게 작동한다.

세 번째와 다섯 번째가 가장 변별력이 크다. 둘 다 성적서가 반려되거나 운영에서 뒤집히는 것을 겪어 본 사람의 답이다. 특히 세 번째의 "쪼개면 안 본 것도 드러난다" 는 분류를 공백 발견 도구로 쓰는 시각이라, 용어를 지식으로만 아는 사람과 분명히 구분된다.

두 번째도 좋다. 범위 결정이 견적이라는 연결은 실제로 견적을 내 본 사람의 감각이고, 모듈 26 레슨 3의 숫자 대화와 같은 자리다.

공고 표현으로는 "크로스 브라우저·디바이스 테스트", "호환성 검증", "품질 특성 기반 시험 설계", "시험성적서 작성" 이 이 레슨에 걸린다.

실습 과제

과제 1 — 우리 검증 항목 재분류

우리가 "호환성"이라 부르며 수행해온 항목을 전부 나열하고 재분류한다.

재분류 후 호환성 칸에 남는 항목이 몇 개인지 세어본다.

과제 2 — 빈 칸 드러내기

재분류 결과를 품질 특성별 항목 수 표로 만든다.

비어 있는 칸마다 "우리 제품에 해당 없음"인지 "해야 하는데 안 하고 있음"인지 판정한다. 후자가 리스크 목록이다.

과제 3 — 적응성 측정량 계산

우리의 크로스 브라우저·디바이스 매트릭스를 가져와 적응성 비율을 계산한다.

적응성 = 정상 동작 기능 수 / (대상 기능 수 × 대상 환경 수)

세 갈래(하드웨어·시스템 소프트웨어·운용 환경) 각각에 대해 따로 계산해본다. 어느 갈래의 대상 정의가 가장 부실한지 드러난다.

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

최근 작성했거나 앞으로 작성할 시험성적서의 항목명을 병기 형식으로 다시 짓는다. 최소 5건.

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

판(edition)을 어디에 적을지도 함께 정한다 — 항목마다인가, 문서 머리에 한 번인가.

과제 5 — 견적 분리하기

"호환성 시험"으로 뭉쳐 있던 견적 항목을 적응성·상호운용성·공존성으로 나누고, 각각의 소요와 종속 리스크 를 적는다.

이 표를 다음 견적 회의에 들고 간다.

과제 6 — 확장성 항목 분리 (2023 기준)

2011 기준으로 적응성 안에 섞여 있던 확장성 요구를 찾아 별도 항목으로 떼어낸다. 없다면 정의한다.

• 우리가 감당해야 할 최대 규모는 얼마인가
• 그것을 어떻게 검증하는가 (모듈 16의 부하 테스트와 연결)

자가 체크리스트

• 크로스 브라우저·디바이스 검증이 왜 적응성인지 설명할 수 있다
• "다른 제품인가 다른 환경인가" 기준으로 항목을 판정할 수 있다
• 적응성의 세 갈래(하드웨어·시스템 소프트웨어·운용 환경)를 안다
• 적응성 측정량의 기본 형태가 무엇인지 알고 계산할 수 있다
• 크로스 브라우저 매트릭스가 곧 적응성 측정량임을 설명할 수 있다
• 2011 이식성과 2023 유연성에서 적응성의 위치를 각각 말할 수 있다
• 확장성이 어디에서 어디로 옮겨졌는지 알고, 적응성과 구분할 수 있다
• 오분류가 만드는 세 가지 문제를 구체적으로 설명할 수 있다
• 커버리지 착시가 무엇이고 왜 위험한지 설명할 수 있다
• 병기 표기 형식을 쓸 수 있고, 어느 문서에서 써야 하는지 안다
• 고쳐야 할 곳과 그대로 둬도 되는 곳을 구분할 수 있다
• 적응성 시험이 잡는 결함 유형 여섯 가지를 들 수 있다
• 기기 수를 줄이는 것과 축을 버리는 것의 차이를 설명할 수 있다
• 적응성 범위를 실사용 데이터로 정하는 방법을 말할 수 있다
• "주요 브라우저" 가 판정 불가능한 말인 이유를 설명할 수 있다
• 항목을 쪼개면 안 본 것이 드러난다는 것을 예로 들 수 있다
• 범위를 적지 않은 "100% 통과" 가 왜 의미가 없는지 설명할 수 있다

흔한 실수

분류만 바꾸고 항목명을 표준어로만 남긴다. "이식성 – 적응성"이라고만 적힌 성적서는 의뢰한 고객이 무엇을 시험했는지 못 알아본다. 괄호 병기가 답이다.

상위 특성명을 판과 어긋나게 적는다. 2023판을 기준으로 쓴다고 해놓고 "이식성 – 적응성"으로 적으면 어긋난다. 판을 정했으면 상위 이름을 맞춘다.

적응성 대상 환경을 정의하지 않고 측정한다. 분모가 없으면 비율이 안 나온다. "지원 대상 브라우저·OS·기종 목록"이 먼저다. 이 목록이 계약이나 제품 명세에 있는지도 확인한다.

확장성을 계속 적응성 안에 둔다. 2023판을 쓰기로 했으면 별도 부특성이다. 섞어두면 부하 관련 요구가 브라우저 항목 사이에 묻힌다.

일상 대화까지 교정하려 한다. "호환성 테스트"라는 말 자체를 금지하면 반발만 산다. 레슨 1의 원칙 — 말과 글을 분리한다.

재분류를 하고 빈 칸을 그대로 둔다. 오분류를 걷어내는 목적은 빈 칸을 드러내는 것이다. 드러난 뒤에 아무것도 안 하면 표만 예뻐진 것이다.

참고 자료

• Flexibility — ISO 25000 포털 — 2023판 유연성 특성과 네 부특성의 정의
• ISO/IEC 25023:2016 — 적응성 측정량(하드웨어 환경·시스템 소프트웨어 환경·운용 환경 적응성)의 산식
• ISO/IEC 25010 Explained: 9 Software Quality Characteristics — 확장성이 적응성에서 분리된 배경
• 이 모듈 레슨 3 표준의 호환성 — 이 레슨과 짝. 경계의 양쪽을 각각 다룬다
• 이 모듈 레슨 5 측정량과 성적서 항목명 — 병기 표기를 실제 성적서 양식에 적용하는 법
• 모듈 16 레슨 8 시각적 회귀와 호환성 테스트 — 크로스 브라우저 검증의 실제 수행 기법. 이 레슨은 그 활동에 표준 좌표를 붙인다
• 모듈 17 레슨 2 Android와 iOS 검증 포인트 — 플랫폼별 적응성 검증의 구체적 항목

이 커리큘럼 안에서

• 모듈 30 레슨 1 — 병기 원칙. 분류는 표준, 항목명에 실무 용어
• 모듈 30 레슨 2 — 25010 개정. 판을 적어야 하는 이유
• 모듈 30 레슨 3 — 호환성(공존성·상호운용성). 이 레슨과 경계의 양쪽
• 모듈 30 레슨 5 — 측정량과 성적서 항목명. 병기의 실전 적용
• 모듈 30 레슨 8 — 팀 용어집과 이행
• 모듈 25 레슨 2·7 — 특성별 검증 항목, 시험성적서의 세 얼굴
• 모듈 16 레슨 8 — 크로스 브라우저 검증의 실제 수행 기법
• 모듈 17 레슨 2 — 플랫폼별 적응성 항목
• 모듈 26 레슨 2~3 — 선택지 보고와 견적. 범위 결정을 전달하는 방법
• 모듈 27 레슨 5 · 모듈 28 레슨 5 — 분모 없는 숫자의 같은 함정

한 줄 정리 — 실무가 "호환성" 이라 부르는 크로스 브라우저·디바이스 검증은 표준 분류에서 적응성이고, 2011 이식성에서 2023 유연성 아래로 옮겨졌다. 그래서 성적서에는 판을 적고 실무 용어를 병기한다. 그리고 적응성은 범위를 정하지 않으면 끝이 없는 축이므로 실사용 데이터로 범위를 정해 문서에 적어야 하고, 범위 없는 "100% 통과" 는 무엇을 봤는지 알려 주지 않는다. 분류의 실용적 가치는 분류 자체가 아니라 쪼갰을 때 안 본 것이 드러나는 것에 있다.