저자: 켄달 그랜트 클라크(Kendall Grant Clark), 역 전순재
들어 가는 말
W3C의 TAG(Technical Architecture Group) 회원들(그리고, 간접적으로, 그 주위에 모인 개발자 공동체도 마찬가지)은 자신들이 개념적으로 고정된 위치를 지키고 있는지 반드시 자주 살펴 보아야 한다. 그들의 일부 임무는 웹의 아키텍처 원칙을 접합하는 것인데, 이는 그동안 구축된 분산 정보 시스템 중에 가장 성공을 거두었다고 볼 수 있다. 그렇지만 사건은 항상 보이는 것만큼 그렇게 단순하지 않은 법이다. 한편으로 그들의 연구조사 목적이 성공적인 것은 분명하지만, 그런 성공을 책임질 원칙들을 찾아내서 접합하는 일이 얼마나 어렵겠는가? 그것은 단순히 적시에 적소를 들여다보고 무엇을 이해하고 있는지 기록하는 문제가 아니지 않은가? 반면, 성공적이긴 하지만 웹은 인간의 실수에 면역이 되어 있지 않으며, 어두운 구석이 많이 있고, 그리고 계속해서 변해간다.
그렇기 때문에 TAG 조직의 임무는 어려운 일이 아닌 듯이 보이기도 하며 불가능해 보이기도 한다. 나는 기술적(descriptive)인 것들과 표준적(normative)인 것들이 개념적으로 서로 관련되어 있는 것이라는 이론적인 격언이 이런 상황에 반영되어 있다고 생각한다. 기술(describing)과 표준(norming) 사이에 명확한 경계선이 있다면 관례적인 수준에서 상황은 좀 더 단순해질 것이다. 그러나 처음으로 이러한 경계선을 그어야 하거나 찾아야 하는 것이 작업의 일부라면 이때 관례는 작지만 귀중한 도움이 된다. 웹 애플리케이션을 구축할 때 해도 좋은 것과 안되는 것(may)을 결정짓는 경계선 및 해야만 하는 것과 해서는 안될 것(must)을 결정짓는 경계선은 그저 웹의 아키텍처적 원칙들일 뿐이다. 한 시스템의 구성요소는 그 작동 원칙들이 시스템 그 자체의 원칙과 일치하거나 조화를 이룰 때 가장 잘 작동한다는 것을 전제로 하여 TAG의 임무가 성립한다.
지금까지 TAG의 활동에서, 공중의 관심은 기본적으로 그의 임기응변식(ad hoc) 성명서에 쏠려 있었다. 여기서 "임기응변식(ad hoc)"이라 한 이유는 때때로 성명서가 어떤 특정한
이슈에 관한 질의의 결과로 나오기 때문이다. 그동안 TAG 회원들은 "웹 아키텍처적 원칙들(
APW, Architectural Principles of the World Wide Web)"이라는 문서의 초안을 만들어 왔는데 이 문서는 웹을 작동시키는 요인에 대해 그들이 발견하고 정의한 것들을 명확하게 정의하는데 기여할 것이다. 이 문서의
첫 공개 작업 초안은 최근에 배포되었다. 비록 아직까지 시험 단계이기는 하지만 이 문서는 그동안 TAG가 고착 상황을 얼마나 잘 극복해 왔는지 보여주는 데 중요한 시각을 제공한다.
지금까지는 APW에서 섹션 1과 2가 가장 잘 개발되었다. 본 기사의 나머지 부분에서 APW의 섹션 1을 검토해 보고, 다음 기사에서 섹션 2를 살펴보겠다. 뒤이은 APW 초안이 더욱 완벽하게 채워지고 나면, 섹션 3과 섹션 4도 탐구해 볼 생각이다.
웹의 아키텍처(Architecture)
먼저 어쩔 수 없는 것들을 용서하자: 첫 공개 초안대로라면 몇몇 문장과 단어가 빠져 있으며, 부적절한 표현, 그리고 거친 곳이 여러 군데에 걸쳐있다. 그리고 상당량의 문장-수준의 작업과 구절-수준의 작업이 여전히 요구된다.
당연히 그렇게 하는 것이 공정하겠지만 그러한 문제들을 제외하면, 문서 그 자체의 모양을 가장 먼저 주목할 만하다. APW는 다음과 같은 4개의 실질적인 섹션으로 이루어져 있다.
문서 구조는 웹 아키텍처를 반영하는데 APW의 주장대로라면 웹 아키텍처는 식별자(identifiers), 형식(formats), 통신규약(protocols)으로 구성되어 있다.
그러나 어떻게 APW는 웹 그 자체를 이해할까? APW의 주장대로라면 웹은 "네트워크로 연결된 정보 시스템이자 정보를 서로 교환하는 중개자(다른 사람, 개체, 또는 프로세스를 대신하여 작동하는 프로그램)들로 구성되어 있다". 웹 아키텍처의 세가지 구성부분이 이미 다음 정의에서 암시되어 있는 것이다.
첫째, 네트워크로 연결된 시스템에서, 그 네트워크를 구성하는 객체나 노드에 이름을 짓고 접근하는 방법이 있어야 한다. "식별자(identifiers)"로 APW는 웹을 구성하는 객체들에 접근하는 유일한 방법, 즉 URI를 뜻하고 있는데, 이는
RFC 2396으로 설립되었다.
둘째, 중개자들 사이에
정보(information)가 교환되는 시스템에서, 그 정보는 구체적인 형태를 가져야 한다. 다시 말해, 그 네트워크의 노드들은 서로 교환하는 정보를 인코딩하고, 재-표현하는 방식을 공유해야 한다. "형식(formats)"으로 APW는 다양한 그룹의 정보 교환 표준을 의미하는데 여기에는 HTML, CSS, RDF가 포함되며 아마도 유니코드와 같은 저수준 표준도 포함될 것이다. 그러나 성공적인 정보 교환 시스템이라면 내부적이든 외부적이든 변화에 적응하는 유연성이 필요하다. 그렇다면 정보 표현의 수단이 예전방식이나 예측 가능한 방식으로 확장 가능해야 하는 것이 가장 이상적이다. 그러므로 APW에는 XML과 네임스페이스(namespaces)를 웹 "형식(formats)"의 일부로 포함하고 있다.
셋째, 네트워크로 연결된 정보 교환 시스템에서 교환의 수단과 방법은 적절한 중개자들이 반드시 제대로-정의하고, 널리 공유해야 하며, 객체를 명명하고 접근하는 그 시스템의 구도와 일관성이 있게 작동해야 하고, 반드시 인코딩된 정보를 배달할 능력이 있어야 한다. 그래서 "통신규약(protocols)"으로 APW가 의미하는 것은 정보 교환을 위한 한 집합의 정형적 표준이다. APW의 설명에 의하면 여기에는 "HTTP, SMTP, 등등"이 포함된다.
원칙의 시험적 선언
그래서, 요약하면: 웹은 정보 교환 중개자들이 네트워크로 연결된 시스템이다. 정보교환 중개자들은 식별자(identifiers), 형식(formats), 그리고 통신규약(protocol)이라는 세 부분으로 구성되어 있다. 웹의 구조를 이렇게 이해하면 어떤 아키텍처적 원칙들(APW의 설명대로 "중대한 디자인 선택")이 따라오는가?
TAG는 지금까지 9개의 원칙과 2개의 "좋은 관례"를 웹의 본성과 그의 구성 부분으로부터 이끌어 내었다. 본 기사에서는 지면관계 상 그 원칙들과 관례만을 언급하겠다. 좀 더 자세한 논의는 XML-데비앙 칼럼에서 다루어질 것이다.
- 절대적인 URI 참조를 사용할 것
- 절대적인 URI 참조는 애매하지 않다
- 자원을 기술할 것
- 표현 열람(Representation retrieval)은 안전하다
- 절대적인 URI 참조의 맥락-감지(context-sensitivity)를 이해할 것
- 일관되게 표현을 사용할 것
- 영속성(persistence)을 지원할 것
- 불필요하게 새로운 URI 체계(schemes)를 사용하지 말 것
- 등록되지 않은 URI 체계(schemes)를 사용하지 말 것
아마도 그렇게 과도하게 아키텍처적이지는 않을 듯 싶은데, 내가 알기로 이러한 것들은 대부분 원칙보다는 관례로 더 많이 선전된다. 다음 번호들(1, 3, 5, 6, 7, 8, 9)을 포함하여, 모든 것들은 아마도 웹 애플리케이션을 구축할 때 또는 웹 그 자체의 일정 부분을 확장하려는 시도를 할 때 당연히(should) 해야 하거나 하지 말아야 할 것을 지정한다. 또는 무조건(must) 해야 하거나 하지 말아야 할 것을 지정한다. 오직 2번과 4번 만이 명확하게 원칙의 선언처럼 보인다. 9번은 중간쯤 되는 성격을 가지고 있다. 등록되지 않은 URI 체계는 단순히 웹의 일부가 아니라는 의미로 읽을 수도 있지만 개인적으로는 관례가 아니라 원칙의 선언으로 생각되기 때문이다. 그리고 그 가치에 상관없이, 비록 등록되지 않은 URI 체계가 "공개 인터넷"에서 작동이 불가능하고 그리고 잘-맞지 않는다고 할지라도 APW에서 언급했듯이 자신들의 임무는 "공개 웹(public Web)"이 되어야 한다고 생각한다. 그러나 아마도 이것은 그냥 부적당한 표현일 것이다.
확실하게 밝혀진 좋은 관례는 다음과 같이 요약할 수 있다.
- URI의 대소문자 무시에 의존하지 말 것
- 컨텐츠 협상(content negotiation)과 조각 의미구조(fragment semantics)를 이해할 것
APW에 관련된 한도 내에서 원칙과 좋은 관례 사이의 차이가 해야 할 것 또는 하지 말아야 할 것에서 그저 당연히(should)와 무조건(must) 사이의 차이에 불과하다고 생각하고 싶겠지만 그런 식으로 쉽게 분석되지는 않는다. "컨텐츠 협상(content negotiation)과 조각 의미구조(fragment semantics)"를 이해하는 좋은 관례와 사람들이 예측할 수 있는 "절대적인 URI 참조의 맥락-감지(context-sensitivity)"를 이해하는 웹 아키텍처적 원칙 사이를 TAG가 어떻게 구별할지는 앞으로 나올 초안에서 명확하게 다루어질 것이다.
그래서 좋은 관례와 최상급 관례 사이에 만약 차이가 있다면 "그 차이를 어떻게 이해할 것인가?", "무엇 때문에 좋은 관례로부터 원칙이 구별되는가?"와 같은 질문들에 대해서는 아직 APW가 적절하게 대답할 수 있을 것 같지는 않다. 주목할 만한 것은 9개의 원칙과 2개의 좋은 관례가 완전히 섹션 2와 연관된다는 것인데, 이 섹션은 식별자(Identifiers)를 다루고 있다. 사실, 섹션 2는 이 11개의 원칙과 관례를 근본적으로 깊이-있게 논의 하고 있다. 이 섹션에서 제안하는 바를 보면 TAG가 앞으로 APW 초안을 더 배포하면, 원칙과 관례를 더 잘 이해할 수 있을 것이라고 짐작할 수 있다. 원칙과 관례는 웹의 통신규약과 형식에 관하여 진행중인 작업과 미래의 작업에서 파생되는 것이기 때문이다. 조금만 단순하게 확대해 생각해 보면, APW에서 30개에 이르는 원칙들을 미루어 생각해 볼 수 있는데, 그 정도에 이르면 그 원칙들을 제일 원칙들의 관점에서 생각하는 것이 더 이상 아무 의미가 없을 것이다. 그런 고찰은 유익함을 과도하게 넘어서는 쓸모없는 것이다.
맺는 말
다음 칼럼에서 명백히 밝혀지겠지만, 지금까지 APW(Architectural Principles of the World Wide Web)에서 개괄한 원칙과 관례의 골자는 상당정도가 적절하다는 생각이 든다. 지금 당장은 APW가 W3C의 역사와 미래의 웹 그 자체의 진화에 매우 의미심장한 문서라고 충분히 말할 만하다. 골자라는 관점에서, 특히 그 개발단계가 초기라는 점을 감안하면 잘못한 것보다는 잘한 것이 더 많다. 비록 개인적으로는 원칙과 관례 사이의 구별이 좀 명확하게 밝혀지기를 고대하고는 있지만, 이 점 때문에 웹 개발자들이 APW를 현재의 형태와 미래의 형태 모두에서 진지하게 고려하는데 방해가 되어서는 안될 것이다.