요청시 파라미터 같은 정보를 전달하여서 서버 입장에서는 전달 받은 데이터를 바탕으로
서비스를 처리하고 처리한 결과를 다시 클라이언트에게 보냅니다.
일반적인 서버-클라이언트 모델과 비슷하다고 할 수 있습니다.
하지만, Ajax는 클라이언트 측에서 보다 역동적이고, 보다 많은 처리를 할 수 있다는 가능성을 보다 많이 제공하고 있습니다. 따라서 기존의 웹 서비스에서도 이러한 일들을 충분히 처리할 수 있지만, 앞에서 이야기한 점들을 십분 활용하기 위해서 Ajax를 이용하고 있다고 할 수 있습니다.
그렇다면, 어떤 상황에서 Ajax 호출 기반 서비스를 구축할 것인가? 그 중에서도 서버를 어떻게 디자인 하여야 할 것인가?에 대해서 이야기 하고자 합니다.
가장 선행 되어야 할 것은 서비스의 어떤 부분을 서버가 처리하고 어떤 부분을 클라이언트가 처리하는가? 하는 고민을 해보아야 합니다.
회사 또는 개인이 보유한 중요한 정보까지도 모두 클라이언트에게 통채로 넘겨서 이를 처리하게 한다면, 서버의 부담이라고 하는 것은 "요청시 전달"이라는 것으로 국한 될 수 있습니다.
하지만, 이러한 점 때문에 중요한 정보를 모두 넘길 순 없죠.
그럼 모든 정보를 서버에서 처리하고 넘기면 될까요?
그럼 서버의 부하가 많이 걸리게 될 것입니다.
그럼 Ajax같은 것을 굳이 쓰지 않아도 될 것입니다. 일반적인 자바스크립트로도 충분히 해낼 수 있기 때문이죠.
이러한 동전의 양면과 같은 부분을 가장 근본적으로 고민을 해야합니다.
저는 첫번째 고려 사항으로 제안하는 것은 "데이터의 보안 여부" 입니다.
"데이터의 보안 여부"가 낮은 정보의 경우 서버측에서 다루느라 시간을 허비하지 안하도 될 듯합니다.
그리고 두번째 고려 사항으로 제안하는 것은 "데이터의 양" 입니다.
엄청나게 많은 데이터로 데이터군을 형성하는 데이터가 있다고 합니다. 이러한 데이터는 전송하는데 더 많은 시간을 허비할 수 있습니다. 만약 클라이언트가 이용하는 인터넷 라인의 속도가 느린 경우에는 데이터의 많은 부분을 처리하고 가공하여서 이를 클라이언트에게 보내주여야 합니다.
그리고 세번째 고려 사항으로 제안하는 것은 "데이터의 갱신성" 입니다.
만약 데이터의 갱신성이 높은 데이터의 경우, 예를 들어 실시간 뉴스라던가 하는 부분은 사용자에게 즉각 즉각 전달 되야 합니다. 이러한 데이터의 경우는 Ajax라는 기술을 통해서 실시간 정보를 즉각즉각 처리해 주어야 합니다. 이 부분을 페이지 리로딩과 같은 작업을 클라이언트에게 요구하게 되면, 사용자로써는 매우 귀찮은 작업이 될 수 있을 뿐만 아니라, "데이터의 갱신성"이 높음에도 불구하고 매우 낮은 갱신율을 제공하게 되는 불상사를 불러 올 수 있기 때문입니다.
위의 3가지를 미리 고려해본뒤 이 서비스는 Ajax같은 다이나믹한 기술로 제공하면 좋겠다는 판단이 서게 되면, 이제는 서버에서 처리한 결과를 어떤 식으로 건네줘야 하는가? 라는 문제를 고려 해야 합니다.
서비스 처리 결과를 건네 주는 방식은 Ajax에서 2가지를 제공하고 있습니다.
1. 텍스트 기반
2. XML 기반
이 외에도 여러 방식이 있지만, 대표적인 2가지 방식만을 고려해보도록 하겠습니다.
일단 텍스트 기반으로 할 경우 같은 양의 데이터를 보낸다고 한다면 XML 보다 가볍게 여길 수 있습니다. 왜냐하면 텍스트 데이터만을 전송해 주면 되기 때문입니다.
하지만, XML을 전송할 경우 최소한 1개 이상의 엘리먼트를 구성해야 하기 때문에 태그에 소요되는 텍스트를 구성해야 하기 때문입니다.
여러개의 데이터군을 형성하는 데이터라 할 지라도, "즉각적 사용"과 "가공"이라는 두가지 측면을 고려한다면, 어느것이 가장 적합하다고 단정지어 말할 수 없습니다.
XML 기반으로 데이터를 전송할 경우 텍스트와는 비교하기 힘들 만큼 정보의 가공성을 제공하기 때문입니다.
그리고 XML로 제공되는 데이터의 경우 파서의 성능에 따라서 그 결과가 달라질 수 있지만, 그래도 기본적으로 데이터에 성격을 부여할 수 있기 때문에, 다른 서비스에서도 이를 활용할 수 있는 가치는 높아지게 됩니다.
따라서 텍스트 기반으로 서비스 처리 결과를 돌려줄 것인가 아니면 XML 기반으로 할 것인가는 서비스 처리 결과의 "활용 방안"을 고려한 뒤 결정해야 합니다.
일반적으로 1개의 결과값, 예를 들어, True, False, 이름, 색상... 등 1개의 결과값만을 제공한다면 텍스트를 추천할 수 있지만, 이러한 값들이 복합적으로 이루어진 데이터군을 형성하는 데이터라면, XML을 추천 드리는 바입니다.
이것은 데이터의 추후 활용 방안 때문에 그런 것입니다.
기존의 많은 인터넷 서비스에서는 OpenAPI 형태로 웹 기반으로 서비스 요청-응답 서비스를 제공합니다. 네이버나 구글, 다음과 기타 인터넷 서비스에서도 OpenAPI 서비스의 결과 값으로 XML의 형태로 데이터를 제공합니다.
뿐만 아니라 우리가 지금 보고 있는 블로그의 경우도 RSS 서비스를 제공하는 블로그라면 RSS 요청 결과가 XML 형태로 되어있다는 것을 쉽게 알 수 있습니다.
이러한 복잡도가 높은, 복잡한 데이터군을 형성하는 데이터는 XML로 제공하는 것이 효율적이라 생각합니다.
데이터 가공 처리 방안을 넘어서서,
이번에는 클라이언트로 부터의 서비스 요청을 서버에서 어떤 방법으로 처리할 것인가?
라는 부분을 얕게 고민해보고자 합니다.
클라이언트로 부터 요청된 정보를 JSP나 PHP, ASP와 같은 서버 지향적인 코드로 짜여진 페이지로 보내도록해서, 바로 그곳에서 처리한 뒤 결과를 보내 줄 수도 있지만, 프레임워크라는 것을 이용하게 되면 더욱더 세밀한 부분을 쉽고 안전하게 처리할 수 있는 경우도 존재하게 됩니다.
이렇게 될 경우,
로 데이터를 전달 할 수 있게 됩니다.
이렇게 될 경우 많은 프레임 워크에서 제공하듯 MVC 패턴에 의해 비즈니스 코드와 뷰 코드를 분리 시켜 일은 프레임 워크에서 처리하고 결과는 프레임 워크에서 지정한 결과 페이지에서 뭉쳐서 사용자에게 보내주게 되는 일을 할 수 있게 됩니다.
따라서 반드시 어떻게 서비스를 처리해서 꼭 한 방법으로 줘야 한다는 것은 없습니다.
하지만, 작업을 몇명이서 하는가? 혼자서 한다면.. 어떻게 일을 쪼갤 것인가?
하는 이슈들을 처리한 뒤 이에 맞추어서 서비스 서버를 구축하게 되면 막연히 제작하게 되는 서비스 서버 보다 더욱더 서비스를 원활히 제공할 수 있게 됩니다.
다음으로 진지하게 고민해야 할 사항은 "스팟"님께서 댓글에서 제안해 주신 부분인 "검색 노출"에 대한 부분입니다. Ajax로 데이터를 표현하게 되면, 그 특성상 웹 페이지의 정보를 긁어다가 검색 DB에 넣는 "크롤러"의 정보 수집 부분을 방해하게 됩니다.
이 부분은 노출을 민감하게 다루어야 하는 부분에서는 Ajax를 통해 실시간으로 데이터를 전송 받아서 노출해야 하기 때문에 "크롤러"에게 장애의 요인으로 작용하게 됩니다. 하지만, "크롤러"에게 노출되고 싶지 않은 정보라는 것도 존재 할 수 있게 됩니다. 이러한 부분은 다른 방식으로 표현해야 합니다. 예를 들어 태그로써 아예 상주시키게 한다거나요. 아니면, 다른 방법을 써서 노출을 하도록 해야 합니다. 그래야 "크롤러"가 이를 수집하여 검색을 통한 페이지 유입을 이룰 수 있게 됩니다.
