표준의 호환성 — 공존성과 상호운용성, 그 둘뿐이다

개념

정의부터 읽는다

용어 논쟁은 원문 정의를 읽으면 대개 5분 안에 끝난다. ISO/IEC 25010:2023의 정의는 이렇다.

호환성(compatibility) 다른 제품과 정보를 교환하는, 그리고/또는 동일한 공통 환경과 자원을 공유하면서 요구된 기능을 수행하는 제품의 능력

문장이 and/or 로 묶인 두 갈래인 것이 눈에 띈다. 그 두 갈래가 그대로 두 부특성이 된다.

공존성(co-existence) 다른 제품과 공통 환경과 자원을 공유하면서 , 다른 어떤 제품에도 해로운 영향을 주지 않고 요구된 기능을 효율적으로 수행하는 능력

상호운용성(interoperability) 다른 제품과 정보를 교환하고 , 교환된 정보를 상호 사용 하는 능력

비고: 정보는 의미 있는 데이터이며, 정보 교환은 교환을 위한 데이터 변환을 포함한다.

호환성 주특성은 이 둘로 끝난다. 1판(2011)에서도 그랬고 2판(2023)에서도 그대로다. 레슨 2의 대조표에서 확인했듯 호환성은 이번 개정에서 이름도 구성도 바뀌지 않은 특성이다.

두 부특성의 차이 — 방향이 다르다

공존성            "같은 자리에 있어도 서로 방해하지 않는가"
                  → 정보를 주고받지 않는다. 그냥 옆에 있을 뿐이다
                  → 관심사: 자원 점유, 간섭, 충돌
 
상호운용성         "주고받은 정보를 서로 쓸 수 있는가"
                  → 적극적으로 데이터를 교환한다
                  → 관심사: 형식, 의미, 변환

한 문장으로 줄이면 공존성은 "안 건드리는가", 상호운용성은 "제대로 건네주는가" 다.

공존성 — 무엇을 검증하는가

공존성은 눈에 잘 안 띄어서 검증에서 자주 빠진다. 그런데 정의를 뜯어보면 확인할 것이 분명하다. 핵심은 "해로운 영향을 주지 않고" 다.

마지막 두 개가 실무에서 가장 자주 사고를 낸다. 배치 작업이 테이블 락을 길게 잡아 같은 DB를 쓰는 다른 서비스가 타임아웃되는 상황, 설치 스크립트가 시스템 전역 설정을 바꿔 기존 소프트웨어가 죽는 상황이다.

공존성 검증 시나리오 설계

공존성은 우리 제품만 띄워놓고는 절대 검증되지 않는다. 반드시 다른 무언가가 함께 있어야 한다.

[공존성 시험 골격]
1. 공존 대상 목록을 정한다
   — 같은 서버·단말에 실제로 함께 설치되는 소프트웨어
   — 계약·환경 명세에 명시된 것이 있으면 그것이 1순위
2. 기준선: 대상 소프트웨어만 단독 실행 → 정상 동작과 자원 사용량 기록
3. 우리 제품을 함께 올린다
4. 대상 소프트웨어의 동작과 자원 사용량을 다시 측정
5. 판정: 열화가 허용 범위 이내인가. 기능 실패는 0건인가
6. 반대 방향도 확인: 대상이 우리 제품을 방해하는가

6번을 빼먹기 쉽다. 공존성은 양방향 성질이고, 우리가 피해자가 되는 경우도 결함이다.

상호운용성 — 무엇을 검증하는가

정의의 핵심은 "교환하고(exchange), 상호 사용한다(mutually use)" 두 동사다. 데이터가 오갔다는 것만으로는 부족하고, 받은 쪽이 그것을 의미 있게 쓸 수 있어야 한다.

[상호운용성이 깨지는 층]
 
① 전송        연결·프로토콜·인증
              → 아예 못 붙는다. 가장 알아채기 쉽다
 
② 구문(syntax) 형식·인코딩·스키마
              → JSON/XML 구조, 필드명, 문자 인코딩, 날짜 포맷
 
③ 의미(semantics) 같은 필드가 같은 뜻인가
              → "금액"이 부가세 포함인가, 통화 단위는, 반올림 규칙은
              → 가장 늦게 발견되고 가장 비싸다
 
④ 처리(pragmatics) 순서·상태·재전송
              → 중복 전송 시 어떻게 되는가, 순서가 뒤바뀌면

③ 의미 층이 상호운용성 검증의 본론이다. 형식이 맞아서 연동은 "성공"했는데 값의 뜻이 달라서 몇 달 뒤 정산이 틀어지는 사고가 여기서 나온다.

이 목록은 모듈 12에서 배운 계약 테스트(contract testing) 가 다루는 영역과 거의 그대로 겹친다. 계약 테스트는 상호운용성 부특성을 검증하는 구체적 기법 이라고 보면 위치가 정확하다.

이 칸에 들어오지 않는 것

여기가 이 레슨의 핵심이다. 정의 어디에도 "다른 환경에서 동작한다"는 말이 없다.

호환성 칸에 들어오는 것
  ✓ 같은 서버에 설치된 다른 제품과 자원을 다투지 않는다      → 공존성
  ✓ 외부 시스템과 데이터를 주고받고 의미대로 해석한다        → 상호운용성
  ✓ 표준 파일 포맷을 읽고 쓴다 (다른 제품과의 정보 교환)     → 상호운용성
 
호환성 칸에 들어오지 않는 것
  ✗ 크롬·사파리·엣지에서 화면이 동일하게 보인다
  ✗ Android 13·14·15에서 모두 동작한다
  ✗ 태블릿 해상도에서 레이아웃이 깨지지 않는다
  ✗ Windows·macOS·Linux에서 설치된다
         └─ 이들은 전부 '다른 환경에 적응하는 능력' → 적응성 (레슨 4)

구분 기준은 하나다 — 상대가 "다른 제품"인가 "다른 환경"인가.

다른 제품과의 관계   → 호환성 (공존성·상호운용성)
다른 환경으로의 이동 → 적응성 (2011 이식성 / 2023 유연성)

브라우저는 "다른 제품"처럼 보이지만, 우리 웹 앱 입장에서 브라우저는 우리가 올라타는 실행 환경 이다. 정보를 교환하는 대상이 아니라 우리를 담는 그릇이다. 그래서 적응성이다.

경계가 애매한 사례 판정 연습

실무에서 헷갈리는 것들을 판정해보자.

마지막 행이 흥미롭다. "하위 호환성(backward compatibility)"은 일상어로는 호환성이지만, 표준 좌표에서는 상호운용성 이다. 다만 이건 같은 제품의 버전 간 문제라 대체성(replaceability)으로 보는 관점도 있다. 애매한 경우에는 "무엇을 시험했는지"를 항목명에 병기 하면 된다 — 레슨 1의 원칙 그대로다.

측정으로 옮기면 — ISO/IEC 25023

분류를 정했으면 숫자로 잴 차례다. ISO/IEC 25023은 25010의 각 부특성에 대한 측정량을 제공한다. 공존성 측정량 하나를 보자.

공존성 측정량 (CCo-1-G)
 
  X = A / B
 
  A = 해당 제품과 공존할 수 있는 것으로 확인된 다른 소프트웨어 제품의 수
  B = 운영 환경에서 공존하도록 명시된 다른 소프트웨어 제품의 총 수

단순한 비율이지만, 이 식을 쓰려면 B를 먼저 정의해야 한다 는 점이 중요하다. "공존 대상 목록"이 없으면 측정 자체가 성립하지 않는다. 공존성 시험 골격의 1단계가 바로 이것이었다.

상호운용성 측정량도 같은 구조다 — 명시된 교환 대상·인터페이스 중 실제로 정상 교환된 비율을 본다. 측정량의 상세는 레슨 5에서 다룬다.

사례 — 코드가 한 줄도 안 바뀌었는데 배치가 네 배 느려졌다

온프레미스로 납품하는 리포팅 서버였다. 사내 검증에서 야간 배치는 40분 에 끝났다. 그런데 세 번째 고객사에서 납품 2주 뒤 2시간 50분 으로 늘었다는 연락이 왔다. 그 사이 우리 코드는 한 줄도 바뀌지 않았다.

고객사 서버에는 백신 실시간 검사 와 자산 모니터링 에이전트 가 돌고 있었다. 사내 검증 환경에는 둘 다 없던 것들이다.

어느 소프트웨어도 규격을 어기지 않았다. 각자 자기 일을 했고, 같은 디스크를 공유한다는 사실만 아무도 시험하지 않았다.

바꾼 것은 셋이다.

• 캐시를 제품 전용 경로 로 옮기고 보존 기간을 7일로 제한했다 — 공용 임시 경로를 떠난 것이 핵심이다
• 납품 가이드에 백신 예외 경로 와 예상 파일 증가량을 수치로 적었다
• 공존성 시험 기준선 환경에 백신이 켜진 서버 를 추가했다

배치는 42분 으로 돌아왔고 디스크 사용률은 11% 에서 정체했다. 이후 납품 3건에서 같은 유형의 장애는 0건 이었고, 그중 1건은 납품 전에 공존성 시험으로 포트 충돌을 먼저 잡았다.

• 공존성 결함은 우리 코드가 안 바뀌어도 생긴다. 회귀 테스트로는 영원히 안 잡힌다
• 깨끗한 검증 환경은 공존성 결함을 숨기는 장치다 — 모듈 7 레슨 3의 환경 패리티와 같은 뿌리다
• 대책의 절반은 코드가 아니라 납품 문서다. 예외 경로와 자원 사용량 명시가 곧 시정 조치가 된다

공존성은 네 시점에서 깨진다

앞의 공유 자원 표가 무엇을 다투는지였다면, 시험 항목을 뽑을 때 더 쓸모 있는 축은 언제 다투는지다.

마지막 두 행이 거의 시험되지 않는다. 고객에게는 "지워도 멀쩡한가"가 도입 결정 조건이고, 평가판·PoC로 먼저 들어가는 제품일수록 그렇다.

표를 관통하는 요령은 하나다. 각 행의 판정 대상이 우리 제품이 아니다 — 설치 후 볼 것은 옆에 있던 것이 그대로인지다.

섞어 쓰면 무엇이 빠지는가 — 준비물이 다르다

두 부특성을 한 칸에 묶으면 계획서에 한 줄이 남는다. 그 한 줄로는 준비물을 산정할 수 없다.

세 번째 행이 역설이다. 공존성은 남의 협조가 필요 없는데도 더 자주 빠진다. 상호운용성은 상대가 있어 일정에 강제로 올라오고, 공존성은 아무도 독촉하지 않는다. 그래서 QA가 스스로 제안하지 않으면 생기지 않는다. 계획서의 호환성 항목 아래가 전부 외부 연동 이면 공존성이 통째로 빠진 것이다. 반대 경우는 거의 못 본다.

선은 하나 그어두자. 적합성 시험과의 층 관계, PICS로 시험 항목을 고르는 절차, 두 제품 사이 기준점에 모니터를 거는 방식 — 즉 시험 유형으로서의 상호운용성 시험 은 모듈 28 레슨 2가 다룬다. 분류가 이 레슨, 수행 절차는 그 레슨이다.

환경마다 공존성이 드러나는 자리가 다르다

모바일. 같은 단말의 다른 앱과 다투는 것은 배터리, 백그라운드 실행 기회, 저장 공간, 알림이다. 쿼터와 제한 규칙은 플랫폼이 판마다 바꾸므로 해당 OS의 최신 개발자 문서로 확인한다. 더 자주 사고를 내는 쪽은 한 단계 안 — 우리 SDK가 고객사 앱에서 다른 SDK와 프로세스를 공유하는 자리 다.

SDK 제품의 공존성 시험은 다른 SDK를 여러 조합으로 넣은 샘플 앱 이 있어야 성립한다. 그 샘플 앱이 공존 대상 목록의 실체다.

브라우저 확장. 여러 확장이 같은 페이지의 같은 DOM에 코드를 주입한다. 둘이 같은 요소를 바꾸면 결과가 설치 순서와 타이밍에 따라 달라진다 — 재현이 가장 어려운 종류다. 자원 쪽은 더 분명하다. 요청 차단 규칙처럼 브라우저가 전역 예산을 두고 설치된 확장 전체가 나눠 쓰는 자원이 있어, 다른 확장이 많이 깔린 사용자에게서만 규칙 일부가 적용되지 않는다. 상한값은 브라우저 판마다 다르니 확장 API 문서 원문으로 확인한다.

엔터프라이즈. 고객사 서버와 PC에는 백신, EDR, DLP, 사내 프록시, 그룹 정책이 이미 있다. 이들은 우리를 방해하는 쪽 으로 작동하는 경우가 많아, 양방향 중 "우리가 피해자"인 사례는 대부분 여기서 나온다.

이 세 줄이 곧 온프레미스 제품의 공존 대상 목록 초안이다. 고객 환경 조사표에 이것만 넣어도 납품 후 장애가 줄어든다.

실무에서 왜 필요한가

RFP 문장을 정확히 읽는다

레슨 1 과제 3의 문장을 다시 보자.

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

앞 절과 뒤 절은 같은 것을 말하고 있다. 뒤 절의 "대내외 시스템 연계"가 곧 상호운용성이다. 즉 이 조항은 브라우저 호환을 요구하는 것이 아니라 연계 시험을 요구 한다.

이 해석이 견적을 바꾼다. 연계 시험은 상대 시스템의 협조 일정 이 최대 변수라, 브라우저 테스트와는 비용 구조가 완전히 다르다. 레슨 1에서 "RFP를 정확히 읽으면 견적이 달라진다"고 한 것이 이 뜻이다.

공존성이 빠진 검증 계획을 잡아낸다

온프레미스로 납품하는 제품, SDK로 배포하는 제품, 에이전트 형태로 서버에 설치되는 제품 — 전부 공존성이 실제 리스크인데 검증 계획에는 거의 안 들어간다. "우리 제품만 깔린 깨끗한 서버"에서만 테스트하고 납품하는 것 이 흔한 패턴이다.

공존 대상 목록을 만들어 제시하는 것만으로 QA의 기여가 명확해진다.

의미 층 검증이 정산 사고를 막는다

상호운용성에서 형식만 맞추고 의미를 안 맞추면, 연동은 성공하고 숫자는 틀린다. 그리고 그 사실은 보통 월말 정산이나 감사 때 발견된다. 단위·시간대·포함 범위 확인은 연동 초기에 30분이면 끝나는 일이다.

채용시장에서의 위치

표준 용어를 "아는지"는 면접에서 잘 묻지 않는다. 묻는 것은 그 구분이 시험 설계를 어떻게 바꿨는지 다. 호환성은 그 차이가 가장 선명한 주제다.

가장 변별력이 큰 질문은 네 번째다. "놓친 사례"에 "없다"로 답하면 공존성을 시험해 본 적이 없다는 뜻으로 읽힌다. 공존성 결함은 깨끗한 환경에서는 아예 나오지 않으므로, 놓친 경험이 있다는 것 자체가 그 환경을 벗어나 본 증거 다. 상대 소프트웨어 이름과 측정값까지 붙으면 반박되지 않는 답이 된다.

두 번째 질문도 변별력이 높은데 이유가 다르다. "함께 깔아 돌려 봤다"는 답은 기준선과 판정 기준이 없다 는 사실을 그대로 노출한다. 기준선, 열화 측정, 양방향 — 이 세 단어가 들어가면 절차로 수행해 본 사람이다. 이 구분이 돈이 되는 자리는 온프레미스 납품 제품, SDK·라이브러리 제품, 고객 환경이 통제되지 않는 분야 의 공고다.

실습 과제

과제 1 — 공존 대상 목록 만들기

우리 제품이 실제로 함께 놓이는 소프트웨어를 나열한다. 서버 제품이면 같은 호스트의 다른 서비스, 앱이면 같은 단말의 다른 앱과 SDK, 라이브러리면 같은 프로세스의 다른 라이브러리다.

이 표가 ISO/IEC 25023 공존성 측정량의 분모(B)가 된다.

과제 2 — 공존성 시험 1회 수행

과제 1의 목록에서 하나를 골라 본문의 6단계 시험을 실제로 수행한다. 6단계(반대 방향)를 반드시 포함한다.

기준선과 공존 시의 자원 사용량 차이를 숫자로 기록한다.

과제 3 — 상호운용성 의미 층 점검

우리가 연동하는 외부 인터페이스 하나를 골라 본문의 의미 층 6개 항목을 확인한다.

"문서에 명시돼 있는가" 칸이 비어 있으면 그것이 곧 리스크다. 지금은 맞아도 어느 쪽이든 바꾸면 조용히 어긋난다.

과제 4 — 판정 연습

우리 제품의 검증 항목 15개를 뽑아 각각 공존성 / 상호운용성 / 적응성 / 그 외 로 분류한다. 애매한 것은 따로 표시하고 왜 애매한지 적는다.

호환성 칸에 들어간 항목이 몇 개인지 세어본다. 예상보다 적을 것이다.

과제 5 — RFP 문장 다시 해석하기

레슨 1 과제 3의 문장에 대해 다음을 작성한다.

• 이 조항이 실제로 요구하는 시험
• 필요한 협조 대상과 일정 리스크
• 브라우저 테스트로는 충족되지 않는다는 설명 (한 문단)

이 문서가 그대로 견적 근거가 된다.

자가 체크리스트

• 호환성 주특성의 정의를 두 갈래로 나눠 설명할 수 있다
• 공존성과 상호운용성의 정의를 각각 말할 수 있다
• 두 부특성의 차이를 "안 건드리는가 / 제대로 건네주는가"로 설명할 수 있다
• 공존성이 공유 자원 7가지에서 어떻게 깨지는지 댈 수 있다
• 공존성 시험이 양방향이어야 하는 이유를 안다
• 상호운용성이 깨지는 네 층(전송·구문·의미·처리)을 구분할 수 있다
• 의미 층에서 확인할 항목 6가지를 나열할 수 있다
• 계약 테스트가 어느 부특성의 검증 기법인지 안다
• 호환성 칸에 들어오지 않는 것들과 그 이유를 설명할 수 있다
• "다른 제품인가 다른 환경인가"라는 구분 기준을 사례에 적용할 수 있다
• ISO/IEC 25023 공존성 측정량의 분모를 정의하려면 무엇이 필요한지 안다
• 공존성이 설치·실행·업그레이드·제거 네 시점에서 각각 어떻게 깨지는지 예를 들 수 있다
• 공존성 시험 결과란에 "우리 제품 정상"만 적혀 있으면 안 되는 이유를 안다
• 두 부특성의 시험 준비물이 어떻게 다른지, 공존성이 더 자주 빠지는 이유를 설명할 수 있다
• SDK 제품의 공존성 시험에 조합 샘플 앱이 필요한 이유를 설명할 수 있다
• 온프레미스 제품의 공존 대상 목록에 보안 소프트웨어가 들어가야 하는 이유를 안다
• 이 레슨(분류)과 모듈 28 레슨 2(시험 수행 절차)의 역할 차이를 구분할 수 있다

흔한 실수

호환성 칸에 브라우저·OS 항목을 채운다. 이 모듈 전체가 다루는 그 오분류다. 표준 분류를 쓰는 문서에서 이러면 항목과 내용이 어긋난다.

공존성을 아예 검증하지 않는다. 우리 제품만 있는 깨끗한 환경에서 테스트하고 끝낸다. 고객 서버에는 백신, 모니터링 에이전트, 다른 업무 시스템이 이미 돌고 있다.

공존성을 한 방향으로만 본다. 우리가 남을 방해하는지만 보고, 남이 우리를 방해하는지는 안 본다. 실제 장애는 후자에서도 똑같이 난다.

상호운용성을 "연결되면 성공"으로 판정한다. 전송 층만 확인한 것이다. 의미 층이 어긋난 연동은 연결도 되고 응답도 200이다.

널 값의 의미를 확인하지 않는다. 한쪽은 "값 없음", 다른 쪽은 "아직 모름"으로 쓰고 있으면 집계와 판단이 조용히 틀어진다.

공존 대상 목록 없이 공존성을 측정하려 한다. 분모가 없으면 비율이 안 나온다. 목록을 만드는 것이 측정의 첫 단계다.

제거와 업그레이드를 공존성에서 빼놓는다. 설치와 실행만 보고 끝낸다. 공용 구성요소를 같이 지우는 제거 스크립트는 고객 서버에서 다른 제품을 죽이고, 그 장애는 우리 제품이 이미 사라진 뒤에 발견된다.

공존성 시험 결과에 우리 제품 상태만 적는다. 판정 대상은 옆에 있던 소프트웨어다. "우리 제품 정상"으로 끝난 보고서는 시험하지 않았다는 기록이다.

SDK 제품을 단독 샘플 앱으로만 검증한다. 조합을 만들지 않으면 전역 핸들러 선점이나 초기화 순서 결함을 출시 후 고객 크래시 리포트로 처음 보게 된다.

애매한 사례에서 분류를 오래 논쟁한다. 하위 호환처럼 관점에 따라 갈리는 것이 있다. 분류를 정하고 항목명에 시험 내용을 병기하면 논쟁의 실익이 사라진다.

참고 자료

• ISO/IEC 25010:2023 공개 샘플(PDF) — 호환성·공존성·상호운용성의 원문 정의(3.3, 3.3.1, 3.3.2)를 직접 읽을 수 있다
• ISO/IEC 25023:2016 — 부특성별 측정량. 공존성 측정량 CCo-1-G와 상호운용성 측정량의 산식
• The Applicability of ISO/IEC 25023 Measures to the Integration of Agents and Automation Systems — 25023 측정량을 실제 통합 시스템에 적용한 사례 연구
• declarativeNetRequest — 정적 규칙의 전역 상한(MDN) — 설치된 확장 전체가 전역 예산을 나눠 쓰는 구조. 공존성이 플랫폼 차원에서 설계된 드문 예다(수치는 원문 확인)

이 커리큘럼 안에서

• 이 모듈 레슨 2·4·5 2판 개정 적응성 측정량과 성적서 항목명 — 호환성이 개정에서 바뀌지 않았다는 확인, 밀려난 항목들의 행선지, 측정량을 성적서 한 줄로 옮기는 절차
• 모듈 28 레슨 2 적합성·상호운용성·성능 시험 — 분류는 이 레슨, 수행 절차는 그 레슨이다
• 모듈 12 레슨 4·5 계약 테스트와 Pact — 의미 층을 자동 검증으로 고정하는 기법
• 모듈 7 레슨 3 테스트 환경 관리 — "깨끗한 서버"가 공존성 결함을 숨기는 구조
• 모듈 4 레슨 2 리스크 식별부터 우선순위화까지 — 공존 대상 목록에 우선순위를 매기는 근거
• 모듈 6 레슨 2 좋은 결함 리포트 쓰기 — 공존성 결함은 상대 소프트웨어의 이름·버전이 재현 조건이다
• 모듈 8 레슨 5 동적 테스트 프로세스 — 공존성 시험을 설계·구현 산출물에 올리는 자리
• 모듈 16 레슨 8 시각적 회귀와 호환성 테스트 — 실무가 "호환성 테스트"라 부르는 활동의 실제 내용

한 줄 정리

호환성은 공존성과 상호운용성 둘뿐이고, 둘을 한 칸에 묶으면 아무도 독촉하지 않는 공존성 쪽이 통째로 빠진다 — 그래서 이 레슨의 실질적 결론은 "공존 대상 목록을 만들어라" 한 문장이다.