설계의 전제가 되는 사항들

설계의 전제가 되는 사항들

 

 

설계란?

화면 설계를 통해 기획자들이 상품을 납품하는 과정 이다.

>> 설계서의 가치는 기획자의 가치와 맞먹을 정도로 중요하다.

 

그러나 이 설계를 구현하기 위해서는 IT 인프라에 대한 이해가 필요하다.

IT 인프라는 하드웨어와 소프트웨어 모두를 포함하며, 이 위에 서비스 정책, 요구사항, 사용성이 토대로 올라간다.

 

정책에는 회원 정책, 상품 정책, 주문 정책, 할인 정책 등이 포함된다.

요구사항은 앞서 이야기한 여러 가지 요구사항을 기록한 것이고, 사용성은 UX 가이드에 대한 내용을 담고 있다.

 

이 모든 것들이 기초가 되어 정보 설계와 정보 구조도가 만들어지고,
그 위에 화면 설계서가 지붕처럼 얹혀지는 구조다.

 

=> 이 기반이 튼튼할수록 더 안정적인 설계를 할 수 있다.

 

 

IT 인프라

 

 

전통적인 IT 인프라는 웹 브라우저라는 사용자의 디바이스를 통해 서버와 통신하는 절차.

=> 기본적으로 요청(request)과 응답(response)의 두 가지 흐름으로 볼 수 있다.

 

사용자가 브라우저에 정보를 입력하면 서버로 요청을 보내고, 서버는 그에 대한 응답을 보낸다.

 

이 과정에서 서버는 크게 세 가지로 나누어진다.

• 웹서버는 인포데스크 같은 역할을 한다. (안녕하세요. 무슨 일을 하시겠어요?) HTML 처리는 가능하지만, 복잡한 로직 처리는 못 한다. 그것은 애플리케이션 서버(WAS)로 넘긴다.

 

웹서버와 WAS의 역할

WAS는 로직을 처리하는 곳이고, WAS에서 담고 있는 것은 일부 소스.

데이터베이스는 별도의 DB 서버에서 관리된다.

 

이 서버를 분리한 이유는 주로 보안 때문.

• 예전에는 한 대의 서버에서 모든 것을 처리했지만, 보안을 강화하기 위해 웹서버, 애플리케이션 서버, 데이터베이스 서버를 분리하게 되었다.
• 웹서버는 HTML 같은 일반 데이터를 처리하고, 애플리케이션 서버는 로직을, 데이터베이스 서버는 데이터 관리를 담당한다.

 

작동 흐름

사용자가 웹 서버에 요청하면, 웹 서버는 처리할 수 있는 것과 처리할 수 없는 것을 구분하여 적절히 처리한다.

>> 만약 애플리케이션 서버에 로직 처리가 필요하면, 웹서버는 그것을 애플리케이션 서버로 넘기고, 최종적으로 브라우저로 응답을 보내는 구조다.

 

이것이 전통적인 IT 인프라 구조였는데, 시간이 지나면서 클라이언트 측의 변화가 생겼다. 예전에는 PC만 있었지만, 지금은 PC, 태블릿, 모바일, 심지어 스마트 디바이스까지 다양해졌다.

 

 

변화의 이유(웹 VS 앱)

다양한 디바이스 환경에서 하나의 공통 데이터를 동기화해야 할 필요성이 생겼다.

• 예를 들어, 페이스북에서 작성한 글의 '좋아요' 수가 모든 디바이스에서 동일하게 보여야 한다.
• 이러한 문제를 해결하기 위해 앱이 등장했는데, 앱은 웹과 달리 설치형이다.
  • 즉, 네트워크가 끊기더라도 디바이스에서 사용 가능한 기능을 제공하는 것이 앱의 특징.
  • 또한, 디바이스의 네이티브 기능을 활용할 수 있다는 장점이 있다.

 

앱은 네이티브 기능을 활용해 안면 인식이나 지문 인식, 위치 기반 서비스 등을 제공한다. 앱은 디바이스에 설치되기 때문에 웹보다 빠르고, 부드러운 사용자 경험을 제공할 수 있다.

 

반면 웹은 HTML, CSS, 자바스크립트로 제한되므로 네이티브 기능을 사용하는 데 한계가 있다.

 

=> 하지만 웹과 앱 모두 사용자가 동일한 경험을 하도록 하기 위해, 동기화된 데이터를 제공하는 공통 채널이 필요합니다. 이 공통 채널이 바로 API다.

 

 

API

API는 웹서버에서 데이터를 가져오거나 앱과 웹 간의 실시간 동기화를 담당.

>> 예전에는 웹서버로부터 디바이스가 바로 데이터를 받았는데,
>> 지금은 REST API를 통해 웹서버에서 일부 데이터를 받아서 앱에 실시간 동기화를 해주는 식으로 데이터를 보낸다.

=> 하나의 규약 안에서 데이터가 왔다갔다 할 수 있도록 바뀌었다.

• 대표적인 사이트가 항공권 판매 "실시간으로 왔다갔다."

그래서 하나의 페이지에 나타나는 정보들이 우리 서버에 있는 것과 외부에서 가져오는 것을 명확하게 살필 수 있는 안목이 있어야 한다는 것이다.

 

api는 하나의 스펙 rest면 만든 사람들이 만들어놓은 것.

- 웹에서는 바로 웹서버에서 데이터를 받지만, 앱에서는 필요한 데이터만을 전송하는 방식으로 동기화를 유지한다.

=> 이 과정에서 REST API가 중요한 역할을 하며, 데이터를 JSON 형식으로 전송한다.

 

JSON은 키-밸류 형태로 데이터를 주고받는 방식 으로, 다양한 디바이스 간의 데이터 호환성을 높여준다.

예전에는 쿼리 형태로 보내므로 호환이 서로 안 되는 경우가 많았다.

 

데이터 교환 방식의 변화와 JSON

• 예전에는 데이터베이스에서 데이터를 쿼리 형태로 받아오고, 서로 다른 데이터베이스 간에 파일 배치 같은 방식으로 데이터를 교환했다.
• 하지만 지금은 JSON 형태의 표준화된 방식으로 데이터를 주고받으면서, 이기종 데이터베이스 간의 호환성이 크게 개선되었다.
  • 이러한 변화는 IT 인프라의 프론트엔드와 백엔드 모두에 큰 변화를 가져왔다.

 

변화된 모습

서버 측에서도 물리적인 서버 분리 대신, 클라우드 컴퓨팅을 통해 가상화된 서버를 사용한다.

- 예전에는 이벤트를 위해 물리적인 서버를 미리 준비해야 했지만,

- 지금은 클라우드 컴퓨팅을 통해 버튼 몇 번으로 서버를 증설하고, 이벤트가 끝나면 다시 줄일 수 있다.

- 클라우드 컴퓨팅 덕분에 서버 관리는 훨씬 유연해졌다.

 

핵심은 REST API에 대한 이해이다.

 

쉽게 얘기해서 데이터 통신 규약이 키 밸류를 갖고 있는 이 JSON 타입으로 통합되고 있다라고 하는 게 핵심이고
그렇기 때문에 이제 사물 간 인터넷이든 아니면 내가 앱을 갖고 있든 웹을 갖고 있든 모든 데이터가 하나의 규칙 안에서 전달과 소통이 될 수 있다.

 

- 이를 통해 데이터가 우리 DB에서 오는 것인지, 외부 API를 통해 오는 것인지, 화면 설계에서 구분할 수 있어야 한다.

- 그것들을 기획자가 정의해 줄 수 있어야 된다.

 

예시 : 항공권 판매 서비스

항공권 판매 사이트는 실시간으로 좌석이 변경되기 때문에, 기획자는 해당 화면에서 외부 API와 내부 데이터를 어떻게 구분할 것인지 정의할 수 있어야 한다.

• 예를 들어, 항공편의 시간, 체류 시과 가격 정보는 외부에서 가져오고,
• 그 외의 데이터는 내부 서버에서 관리된다.

- 여행 정보는 세부적인 항목들은 우리 서버에 있겠지만 이 시간 정보는 마찬가지로 이 정보를 가져오면서 같이 가져오게 되는 것.

>> 특히 가격 정보가 같은 기종이고 같은 시간대인데 어떤 시간대에 따라서, 마감 시간에 따라서 달라질 수 있다 보니까 리프레시를 하게 되면 가격이 달라져 있다.

 

=> 이처럼 한 페이지 내에서 외부와 내부 데이터를 구분하여 표시할 수 있어야 한다.

 

- 날씨 정보를 추가하고 싶다면, 기상청 API를 이용해 유료나 무료로 데이터를 가져올 수 있다.

=> 이처럼 설계 과정에서 외부 데이터 출처를 명시하고, API를 이용하여 데이터를 가져오는 방법을 정의해야야 한다.

 

 

정리

- IT 인프라는 점점 복잡해지고 있지만, 이를 잘 이해하고 설계에 반영해야만 더 튼튼한 시스템을 구축할 수 있다.

- REST API는 표준화된 스펙으로, 주로 공공 API나 일반적인 API 서비스에서 사용된다.

 

API vs REST API

우리가 흔히 얘기하는 API는 공공 API처럼 그런 API를 제공하는 어떤 일반 스펙을 의미하는 것.

REST API는 어떤 이 API라는 개념을 만든 사람들이 정해 놓은 그런 스펙.