OASIS

OASIS 는 여러 회사가 함께 따를 표준을 만드는 비영리 단체입니다. 표준이 필요한 회사들이 위원회를 꾸려 문서를 합의로 씁니다. 시스템끼리 로그인 결과를 넘기는 표준과 사물인터넷 기기가 메시지를 주고받는 규약이 여기서 나왔습니다.

쉽고 빠른 이해

OASIS 는 회사들이 모여 공통 규칙을 정하는 회의장입니다. 한 회사의 로그인 서버가 내준 결과를 다른 회사의 서비스가 믿고 받아 주는 규칙이 이런 회의에서 정해졌습니다.

이게 없으면 회사끼리 시스템을 붙일 때마다 둘이 따로 형식을 맞춰야 합니다. 상대가 열 곳이면 맞추는 작업도 열 번입니다. 한 회사가 혼자 정한 형식은 경쟁사가 따르기를 꺼립니다.

굴러가는 차례는 이렇습니다.

1. 표준이 필요한 회원들이 주제 하나를 맡는 위원회를 엽니다
2. 위원회가 초안을 써서 공개해 바깥의 의견을 받습니다
3. 적힌 대로 구현해 써 봤다는 회원들의 확인을 모은 뒤 회원 투표로 표준이 됩니다

대가는 시간입니다. 여러 회사의 합의를 거치느라 표준 하나가 나오기까지 오래 걸립니다. 한때 많이 만든 웹 서비스 표준 묶음은 메시지마다 서명·암호화 정보를 겹겹이 얹어 메시지가 커졌습니다. 새 시스템은 데이터를 가볍게 주고받는 방식으로 옮겨 가서 이 묶음을 덜 씁니다.

상세

같은 동네 가게들이 배달 주문서 양식을 하나로 맞추기로 했다고 해 봅시다. 한 가게가 혼자 정한 양식은 다른 가게들이 따르기를 꺼립니다. 그래서 가게 주인들이 함께 회의를 열어 양식을 정합니다.

OASIS(Organization for the Advancement of Structured Information Standards, 구조화 정보 표준 발전 기구)는 소프트웨어 업계에서 그 회의를 열어 주는 단체입니다. 정부 기관이 아니라 회원이 꾸려 가는 비영리 단체입니다. 회원은 기업이 많습니다. 정부 기관·대학·개인도 들어옵니다.

개방형 표준

표준은 여럿이 같은 방식을 따르기로 합의하고 그 방식을 적어 둔 문서입니다. 두 회사의 시스템이 같은 표준을 따르면 처음 만나도 데이터를 주고받습니다. 이렇게 서로 맞물려 돌아가는 성질을 상호운용성이라고 부릅니다.

개방형 표준은 그 문서를 누구나 읽고 구현할 수 있는 표준입니다. OASIS 의 표준 문서는 회원이 아니어도 내려받아 읽을 수 있습니다. 표준을 읽는 데부터 돈이 들면 작은 회사나 오픈소스 프로젝트는 구현을 미루기 쉽습니다.

이름에 든 「구조화 정보」

구조화 문서는 내용 사이사이에 「여기부터 제목」「여기부터 주소」 같은 표시를 넣은 문서입니다. 표시가 있으니 사람이 아니라 프로그램도 문서를 갈라 읽습니다. OASIS 이름의 「구조화 정보」가 이런 문서를 가리킵니다.

SGML(Standard Generalized Markup Language, 표준 일반화 마크업 언어)은 문서에 이런 표시를 붙이는 규칙을 정한 언어입니다. OASIS 는 처음에 SGML 을 쓰는 회사들의 모임으로 시작했습니다.

XML(eXtensible Markup Language, 확장 마크업 언어)은 SGML 을 줄여 다듬은 언어입니다. XML 이 나오자 OASIS 는 XML 로 적는 표준을 여럿 만들었습니다. 지금은 XML 과 상관없는 통신 규약도 다룹니다.

기술 위원회

OASIS 에서 표준을 쓰는 단위는 기술 위원회입니다. 주제 하나를 놓고 회원들이 모인 작업 모임입니다. 로그인 결과를 넘기는 표준에 하나, 사물인터넷 메시지 규약에 하나 하는 식으로 주제마다 따로 섭니다.

표준의 내용은 위원회에 모인 회원들이 정합니다. 단체 본부는 위원회가 정해진 절차를 밟도록 돌립니다. 그래서 어떤 표준이 나오는지는 어떤 회원들이 위원회를 여느냐에 달려 있습니다.

초안이 표준이 되기까지는 아래처럼 흐릅니다. 위원회 안의 합의로 끝나지 않습니다. 바깥의 의견을 받습니다. 적힌 대로 구현해 써 봤다는 회원들의 확인도 거칩니다.

flowchart TD
    A["회원들이 기술 위원회를 연다"] --> B["위원회가 초안을 쓴다"]
    B --> C["초안을 공개해 의견을 받는다"]
    C --> D["위원회 투표로 위원회 명세가 된다"]
    D --> E["구현해 본 회원들의 확인을 모은다"]
    E --> F["전체 회원 투표로 OASIS 표준이 된다"]

그림의 「위원회 명세」(Committee Specification)는 위원회가 다 썼다고 인정한 중간 단계입니다. 마지막 투표에는 그 위원회에 없던 회원도 표를 던집니다. 한 주제에 모인 몇몇 회사만의 결정으로 끝나지 않게 하려는 단계입니다.

특허 조건

표준에 담긴 기술에 누군가의 특허가 걸려 있을 수 있습니다. 그러면 표준대로 구현한 회사가 나중에 사용료를 요구받습니다. 문서를 누구나 읽을 수 있어도 이 걱정이 남으면 마음 놓고 구현하기 어렵습니다.

그래서 위원회는 시작할 때 참여 회원이 특허를 어떤 조건으로 내놓을지 정합니다. 위원회에 들어온 회원은 그 조건을 따르기로 약속합니다. 사용료 없이 쓰게 하는 조건을 고르는 위원회가 많습니다.

인증과 인가를 다루는 표준

인증은 상대가 누구인지 확인하는 일입니다. 인가는 확인된 상대가 무엇을 해도 되는지 정하는 일입니다. 여러 시스템이 이 일을 나눠 맡으면 결과를 주고받을 형식이 필요합니다. OASIS 의 위원회들이 이 형식을 여럿 만들었습니다.

SAML(Security Assertion Markup Language, 보안 단언 마크업 언어)은 로그인 결과를 다른 서비스에 건네는 규칙입니다. 로그인을 맡은 서버가 「이 사람을 확인했다」고 적은 문서를 만들어 보냅니다. 이 문서를 단언이라고 부릅니다. SAML 이름에 든 「단언」이 이것입니다.

서버는 단언에 서명을 붙여 보냅니다. 서명은 그 서버만 만들 수 있는 표시입니다. 받는 쪽은 서명을 검사해 누가 보냈는지와 내용이 중간에 바뀌지 않았는지를 확인합니다. 덕분에 서비스는 사용자의 비밀번호를 받지 않아도 됩니다.

싱글 사인온은 한 번 로그인해 여러 서비스에 들어가는 방식입니다. 회사 계정 하나로 메일·일정·급여 같은 사내 서비스를 오가는 것이 그 예입니다. 각 서비스가 로그인 서버의 단언을 믿고 사용자를 들이므로 SAML 로 이 방식을 만들 수 있습니다.

XACML(eXtensible Access Control Markup Language, 확장 접근 제어 마크업 언어)은 인가 쪽 표준입니다. 「인사팀 직원은 근무 시간에만 급여 파일을 읽는다」 같은 규칙을 XML 문서로 적는 언어입니다. 요청이 오면 판정 프로그램이 이 규칙에 견주어 허용이나 거부를 돌려줍니다.

위 규칙은 누가(인사팀 직원) 무엇을(급여 파일) 언제(근무 시간) 하려는지를 봅니다. 요청에 붙은 이런 성질을 속성이라고 부릅니다. 속성으로 허용과 거부를 가르는 방식이 속성 기반 접근 제어입니다. 사람마다 권한을 일일이 달지 않아도 규칙 하나로 여러 사람을 가를 수 있습니다.

오케스트레이션을 다루는 표준

오케스트레이션은 지휘를 맡은 프로그램 하나가 여러 서비스를 정해진 순서로 부르는 방식입니다. 주문이 들어오면 재고 확인 → 결제 → 배송 순서로 서비스를 부르는 흐름이 그렇습니다. 이 순서를 코드 대신 문서로 적어 두면 여러 실행 도구가 같은 문서를 읽고 돌릴 수 있습니다.

WS-BPEL(Web Services Business Process Execution Language, 웹 서비스 비즈니스 프로세스 실행 언어)이 그런 문서의 형식입니다. 어느 서비스를 어떤 순서로 부르고 실패하면 무엇을 할지를 XML 로 적습니다.

이름 앞의 「웹 서비스」는 서비스끼리 정해진 형식의 메시지로 서로의 기능을 부르는 방식을 가리킵니다. 그 메시지 형식으로 흔히 SOAP(Simple Object Access Protocol, 단순 객체 접근 프로토콜)을 씁니다. SOAP 은 요청과 응답을 XML 봉투에 담아 보내는 규약입니다.

애플리케이션 하나는 서버·데이터베이스·네트워크 같은 부품이 서로 이어져 돌아갑니다. 웹 서버는 데이터베이스에 붙습니다. 둘은 같은 네트워크 안에 놓입니다. 이런 부품의 연결 모양을 토폴로지라고 부릅니다.

TOSCA(Topology and Orchestration Specification for Cloud Applications, 클라우드 애플리케이션 토폴로지·오케스트레이션 표준)는 이 연결 모양을 문서로 적는 형식입니다. 대상은 클라우드, 곧 사업자의 서버를 빌려 쓰는 환경에 올릴 애플리케이션입니다. 실행 도구는 이 문서를 읽고 무엇을 어떤 순서로 띄울지 정합니다.

그 밖에 자주 만나는 표준

로그인과 오케스트레이션 말고도 백엔드 개발자가 만나는 OASIS 표준이 있습니다. 아래 표는 그중 셋을 무엇을 정하는지로 가릅니다.

표에서 보듯 OASIS 표준이 꼭 XML 로 적히지는 않습니다. MQTT 는 메시지를 사람이 읽는 글자가 아니라 바이트를 정해진 차례로 늘어놓은 이진 형식으로 적습니다. MQTT 처럼 한 회사가 먼저 만들어 쓰던 규약을 넘겨받아 표준으로 다듬는 일도 있습니다.

ISO 국제 표준으로 이어지는 길

ISO(International Organization for Standardization, 국제표준화기구)는 나라와 나라 사이의 표준을 정하는 기구입니다. 회원은 나라마다 하나씩 있는 표준 기관입니다. 정부가 물건을 사들이거나 규정을 만들 때 ISO 표준을 기준으로 삼는 일이 많습니다.

OASIS 표준 가운데 일부는 ISO 로 넘겨져 국제 표준으로도 승인됐습니다. ODF 와 MQTT 가 그런 예입니다. 같은 내용에 ISO 의 문서 번호가 하나 더 붙습니다. 그래서 한 표준을 두 단체의 이름으로 부르는 일이 생깁니다.

W3C · IETF 와 가르는 법

표준 단체 이름이 셋쯤 나오면 무엇을 어디서 만드는지 헷갈립니다. 로그인 결과를 담은 SAML 메시지 하나를 놓고 보면 셋이 겹겹이 나옵니다.

메시지를 적는 XML 문법은 W3C(World Wide Web Consortium, 월드 와이드 웹 컨소시엄)가 정합니다. 그 문법으로 로그인 결과를 어떻게 적을지는 OASIS 의 SAML 이 정합니다. 메시지를 실어 나르는 웹 요청 규약은 IETF(Internet Engineering Task Force, 인터넷 엔지니어링 태스크 포스)가 정합니다.

경계가 칼같이 갈리지는 않습니다. MQTT 처럼 IETF 쪽 일처럼 보이는 통신 규약도 OASIS 에서 나옵니다. 그래도 「바탕 언어는 W3C, 인터넷 규약은 IETF, 그 위의 업무 형식은 OASIS」로 먼저 짐작하면 대개 맞습니다.

합의에 드는 시간과 무거워진 웹 서비스 표준

여러 회사의 합의에는 시간이 듭니다. 바깥 의견에 답하고 구현 확인까지 모아야 합니다. 그래서 표준 하나가 나오기까지 여러 해가 걸리기도 합니다.

OASIS 는 SOAP 웹 서비스에 얹는 표준을 여럿 만들었습니다. 메시지 서명과 암호화를 정한 WS-Security 와 앞의 WS-BPEL 이 그 묶음입니다. 이름이 모두 WS 로 시작해 흔히 「WS-*」로 묶어 부릅니다. 한 메시지에 서명·암호화·주소 정보가 겹겹이 얹혔습니다. 그만큼 메시지와 설정이 함께 커졌습니다.

그 뒤 서비스끼리 주고받는 방식의 중심이 REST(Representational State Transfer, 표현 상태 전이) 방식으로 옮겨 갔습니다. 이 방식은 HTTP 위에서 JSON(JavaScript Object Notation, 자바스크립트 객체 표기법)을 주고받습니다. 새로 만드는 시스템에서 WS-* 표준을 고르는 일은 줄었습니다.

로그인 쪽도 비슷합니다. 새 서비스는 SAML 대신 JSON 으로 로그인 결과를 넘기는 OpenID Connect 를 고르는 일이 많습니다. 기업 사내 시스템에는 SAML 이 지금도 널리 남아 있습니다.

관련 항목

OASIS 와 나란히 표준을 내는 기구

W3C · IETF · ISO · IEC · ANSI · Ecma International · OpenID Foundation · OMG · ITU-T

OASIS 가 낸 보안 표준

SAML · XACML · WS-Security · WS-Trust · WS-Federation · SPML · KMIP · PKCS

OASIS 가 낸 오케스트레이션·배포 표준

WS-BPEL · BPEL4People · WS-HumanTask · TOSCA · CAMP

OASIS 가 낸 메시징·데이터 접근 규약

MQTT · AMQP · OData · ebXML

OASIS 가 낸 문서·데이터 형식

ODF · DocBook · DITA · UBL · SARIF · CSAF · STIX · TAXII

OASIS 표준이 바탕으로 삼는 기술

SGML · XML · XML 스키마 · XML 서명 · 전자 서명 · SOAP · 웹 서비스 · HTTP

OASIS 표준이 다루는 문제 영역

인증과 인가 · 인증 · 인가 · 싱글 사인온 · 단언 · 속성 기반 접근 제어 · 오케스트레이션 · 사물인터넷

WS-* 와 SAML 을 대신하는 기술

OpenID Connect · OAuth 2.0 · REST · JSON · JWT

표준을 만들고 맞추는 일에 쓰이는 용어

표준 · 표준화 · 개방형 표준 · 기술 위원회 · 상호운용성 · 사실상 표준 · 특허 · 로열티 프리