상호운용성

상호운용성은 따로 만든 프로그램끼리 맞춰 본 적 없이도 함께 일하게 해 줍니다. 브라우저를 만든 회사와 웹 서버를 만든 회사는 서로 연락한 적이 없어도 둘이 대화합니다. 같은 약속을 읽고 각자 만들었기 때문입니다.

쉽고 빠른 이해

상호운용성은 따로 만들어진 프로그램들이 서로 붙어 일하게 해 주는 성질입니다. 어느 회사의 브라우저든 어느 회사의 웹 서버와 페이지를 주고받는 것이 그렇습니다.

이 성질이 없으면 붙일 상대마다 맞춤 작업을 따로 해야 합니다. 상대가 열이면 열 번입니다. 상대가 하나 바뀌면 그 쪽을 또 손봐야 합니다.

여럿이 함께 읽을 약속을 문서로 먼저 정합니다
만드는 쪽은 서로 연락하지 않고 그 문서만 보고 각자 만듭니다
다 만든 뒤에 서로 붙여 보며 어긋난 데를 찾습니다

대가는 한번 정한 약속을 마음대로 못 바꾼다는 것입니다. 내 쪽에만 맞는 방식을 두고도 문서에 적힌 대로만 해야 합니다.

상세

배달 주문의 요청 사항에 「문 앞에 두고 벨은 누르지 말아 주세요」라고 적으면 손님과 기사는 끝까지 얼굴 한 번 마주치지 않습니다. 기사는 그 한 줄대로 현관 앞에 음식을 내려놓은 뒤 벨 없이 돌아갑니다. 손님이 문을 열면 바라던 바로 그곳에 음식이 따뜻하게 놓여 있습니다.

통한다는 말의 두 조건

구현은 약속 문서를 읽고 만들어 낸 프로그램입니다. 같은 문서에서 나온 구현은 보통 여럿입니다. 브라우저도 여럿이고 웹 서버도 여럿입니다.

상호운용성은 이 구현들이 서로 짝을 맞춰 본 적 없이도 함께 도는 성질입니다. 조건이 둘입니다. 정보가 건너가느냐, 건너간 정보의 뜻이 양쪽에서 같으냐입니다.

정보가 건너간다는 것은 보낸 바이트가 상대에게 닿아 읽히는 모양으로 들어온다는 뜻입니다. 뜻이 같다는 것은 읽어 낸 값을 보낸 쪽의 의도대로 해석한다는 뜻입니다. 앞은 되는데 뒤가 안 되는 일이 흔합니다. 상호운용성 문제는 대개 그 모양으로 나타납니다.

통합과 가르는 선

프로그램 둘을 붙이는 일이 통합입니다. 통합은 이 한 쌍을 위해 변환하는 코드를 새로 짭니다. 붙일 상대가 바뀌면 그 코드도 다시 짭니다.

상호운용성은 붙이기 전에 약속을 맞춰 둔 것입니다. 쌍마다 새로 짤 코드가 없습니다. 통합은 만난 뒤에 하는 일이고 상호운용성은 만나기 전에 해 두는 일입니다.

붙을 상대가 늘수록 두 방식의 차이가 벌어집니다. 쌍마다 따로 맞추면 참여자가 넷일 때 맞출 쌍이 여섯이고, 다섯이 되면 열입니다. 같은 약속을 읽으면 각자 문서 하나만 지키면 됩니다.

flowchart TD
    subgraph "쌍마다 따로 맞춘다"
        A1[가] --- B1[나]
        A1 --- C1[다]
        A1 --- D1[라]
        B1 --- C1
        B1 --- D1
        C1 --- D1
    end
    subgraph "같은 약속을 읽는다"
        S["약속 문서"]
        S --- A2[가]
        S --- B2[나]
        S --- C2[다]
        S --- D2[라]
    end

위 그림에 참여자가 하나 더 들어오면 이어야 할 선이 넷 더 생깁니다. 아래 그림에서는 문서로 가는 선 하나만 생깁니다. 대신 아래에서는 그 문서가 바뀌면 넷이 한꺼번에 흔들립니다.

통하는 데 필요한 세 겹

통한다는 말은 한 덩어리가 아닙니다. 앞 절에서 든 두 조건 중 첫째는 다시 둘로 나뉩니다. 거기에 둘째 조건을 더하면 아래 세 겹이 됩니다. 이 셋을 차례로 지나야 두 구현이 함께 돕니다.

첫째 겹은 이어짐입니다. 보낸 바이트가 상대에게 닿아야 합니다.

둘째 겹은 형식입니다. 받은 바이트를 정해진 모양으로 쪼개 읽을 수 있어야 합니다. 그 모양을 미리 정해 둔 것이 포맷입니다.

셋째 겹은 뜻입니다. 쪼개 읽은 값을 보낸 쪽과 같은 뜻으로 받아들여야 합니다.

flowchart TD
    A["보낸 바이트가 상대에게 닿나"] -->|안 닿는다| X1["이어짐에서 끊겼다"]
    A -->|닿는다| B["정해진 모양으로 쪼개 읽히나"]
    B -->|못 읽는다| X2["형식이 어긋났다"]
    B -->|읽힌다| C["보낸 쪽과 같은 뜻으로 읽히나"]
    C -->|아니다| X3["뜻이 어긋났다"]
    C -->|그렇다| Y["두 구현이 함께 돈다"]

셋째 겹이 제일 늦게 드러납니다. 날짜를 03/04 라고 적어 보냈다고 해 봅시다. 받는 쪽은 바이트를 다 받았습니다. 두 숫자로 쪼개 읽는 데까지 성공했습니다.

그런데 한쪽은 이것을 3월 4일로 읽습니다. 다른 쪽은 4월 3일로 읽습니다. 어느 쪽도 오류를 내지 않습니다.

그래서 어긋남은 엉뚱한 날짜의 기록으로 나중에 잡힙니다. 약속 문서가 값의 모양뿐 아니라 그 값을 어떻게 읽어야 하는지까지 적는 까닭입니다.

상호운용성을 만드는 방법

같은 약속을 읽고 만든 것들이 실제로 붙게 하려고 하는 일이 넷입니다. 앞 셋은 약속을 세우는 쪽의 일입니다. 넷째는 그 약속으로 만드는 쪽의 태도입니다.

첫째, 약속을 문서로 적어 공개합니다. 문서가 한 벌이어야 읽는 쪽마다 다른 것을 만들지 않습니다.

이런 문서에는 이름이 있습니다. 둘 이상이 주고받는 순서를 정한 것은 프로토콜입니다. 여럿이 따르기로 합의해 널리 통하는 것은 표준입니다.

둘은 가르는 축이 다릅니다. 프로토콜은 그 문서가 무엇을 정했는지를 말합니다. 표준은 그 문서가 얼마나 널리 받아들여졌는지를 말합니다. 한 문서가 둘 다일 수 있습니다.

둘째, 문서대로 만들었는지 재는 시험을 문서와 함께 냅니다. 이런 시험을 적합성 시험이라 부릅니다. 만든 사람이 스스로 돌려 보고 어긋난 데를 고칩니다.

셋째, 만든 것들을 실제로 서로 붙여 봅니다. 같은 문서를 읽고도 갈리는 대목은 붙여 봐야 드러납니다.

표준을 만들고 관리하는 조직이 표준화 기구입니다. 이런 기구 중에는 서로 다른 구현을 한자리에 모아 붙여 보는 행사를 여는 곳도 있습니다.

넷째, 보낼 때는 문서대로 엄격하게 씁니다. 받을 때는 어긋난 것도 되도록 받아 줍니다. 이 태도가 견고성 원칙입니다.

다만 너무 너그럽게 받으면 맞지 않는 채로 굴러가는 구현이 늡니다. 나중에는 그 어긋남이 새 약속처럼 굳습니다.

약속에 매이며 치르는 대가

약속을 지키기로 하면 바꿀 수 있는 폭이 줄어듭니다. 내 쪽만 고쳐서 될 일이 상대 전부와 관계된 일이 됩니다.

한 번 퍼진 약속은 되돌리기 어렵습니다. 새 규칙을 얹기는 쉬워도 옛 규칙을 빼기는 어렵습니다. 그래서 아무도 안 쓰는 규칙이 문서에 남습니다.

모두가 지원하는 것만 쓰게 되는 일도 생깁니다. 구현 하나가 새 기능을 아직 안 넣었으면 그 기능은 아무도 못 씁니다. 붙는 것을 앞세우면 다들 겹치는 만큼만 쓰게 됩니다.

문서와 구현이 어긋날 때 널리 깔린 구현 쪽이 기준이 되기도 합니다. 그렇게 굳은 동작이 사실상 표준입니다. 뒤늦게 들어오는 구현은 문서가 아니라 그 동작을 따라가야 합니다.

시험과 맞춰 보기에도 사람과 시간이 듭니다. 붙을 상대가 늘수록 확인할 조합도 늘어납니다.

이 성질이 필요한 경계

경계를 넘는 정보만 이 성질을 요구합니다. 내가 양쪽을 다 만들고 늘 같이 배포한다면 둘 사이가 어긋날 일이 없습니다. 한쪽을 고칠 때 다른 쪽도 같이 고쳐 내보내면 되기 때문입니다.

경계는 조직만이 아닙니다. 시점도 경계입니다. 오늘 올린 서버가 어제 나간 앱과 대화해야 한다면 그 사이에도 같은 문제가 생깁니다. 시간을 건너 통하는 쪽은 하위 호환성이라고 따로 부릅니다.

정리하면 상대를 내가 못 고칠 때 상호운용성이 필요합니다. 상대를 언제든 같이 고칠 수 있으면 약속을 세우기보다 그때그때 같이 고치는 쪽이 간단합니다.

상호운용성

상세

통한다는 말의 두 조건

통합과 가르는 선

통하는 데 필요한 세 겹

상호운용성을 만드는 방법

약속에 매이며 치르는 대가

이 성질이 필요한 경계

관련 항목

상호운용성이 기대는 약속 문서

상호운용성을 재고 확인하는 수단

시간을 건너 통하게 하는 성질

상호운용성이 깨졌을 때 나타나는 증상

상호운용성을 지키려고 따르는 원칙

상호운용성이 자주 어긋나는 데이터 표현

상호운용성을 세우는 조직과 절차

상호운용성과 헷갈리는 이웃 성질