설계의 정의

설계란 화면 설계를 통해 기획자가 상품을 납품하는 과정이라고 정의할 수 있습니다. 설계서의 완성도는 곧 기획자의 가치와 직결될 정도로 중요합니다. 설계서는 단순한 도면이 아니라, 실제 구현과 운영을 가능하게 하는 기준 문서이기 때문입니다. 그러나 이러한 설계를 제대로 수행하기 위해서는 IT 인프라에 대한 이해가 선행되어야 합니다. 설계는 독립적으로 존재하는 작업이 아니라, 기술적 기반 위에서만 안정적으로 성립할 수 있습니다.

 

설계 구조의 기반

IT 인프라는 하드웨어와 소프트웨어를 모두 포함하는 개념이며, 그 위에 서비스 정책, 요구사항, 사용성이 차례로 쌓이는 구조를 가집니다. 정책에는 회원 정책, 상품 정책, 주문 정책, 할인 정책 등이 포함되며, 요구사항은 프로젝트에서 변경하거나 추가해야 할 항목을 기록한 문서입니다. 사용성은 UX 가이드와 같은 기준을 담고 있습니다.

이러한 요소들이 기초가 되어 정보 설계와 정보 구조도가 만들어지고, 그 위에 화면 설계서가 지붕처럼 얹혀지는 구조가 형성됩니다. 기반이 단단할수록 설계는 안정적으로 완성될 수 있습니다. 반대로 기반이 불명확하면 설계 역시 흔들릴 수밖에 없습니다.

 

전통적인 IT 인프라 구조

전통적인 IT 인프라는 사용자의 웹 브라우저를 통해 서버와 통신하는 구조입니다. 기본적인 흐름은 요청(request)과 응답(response)으로 설명할 수 있습니다.

• 사용자가 브라우저에 정보를 입력하면 서버로 요청이 전달되고, 서버는 그 요청을 처리한 뒤 응답을 반환합니다. 이 과정에서 서버는 일반적으로 세 가지 역할로 나누어집니다.
• 웹서버는 일종의 인포데스크와 같은 역할을 합니다. 사용자의 요청을 가장 먼저 받아들이고, 정적 HTML과 같은 기본적인 처리를 수행합니다. 그러나 복잡한 비즈니스 로직은 처리하지 못합니다.
• 이러한 로직 처리는 애플리케이션 서버(WAS)가 담당합니다. WAS는 실제 로직을 수행하고, 필요한 경우 데이터베이스 서버와 통신합니다. 데이터베이스는 별도의 DB 서버에서 관리됩니다.

이처럼 서버를 분리한 이유는 보안과 안정성 때문입니다. 과거에는 하나의 서버에서 모든 처리를 담당하기도 했지만, 점차 웹서버, 애플리케이션 서버, 데이터베이스 서버를 분리하여 역할을 나누는 구조로 발전했습니다.

사용자가 웹서버에 요청을 보내면, 웹서버는 해당 요청이 단순 처리인지 로직 처리가 필요한지 구분합니다. 로직 처리가 필요한 경우에는 애플리케이션 서버로 요청을 전달하고, 처리 결과를 다시 웹서버를 통해 사용자에게 응답합니다. 이러한 구조가 전통적인 IT 인프라의 기본 모델입니다.

 

환경 변화와 웹과 앱의 차이

시간이 지나면서 사용 환경이 변화했습니다. 과거에는 PC 중심이었지만, 현재는 모바일, 태블릿, 다양한 스마트 디바이스가 함께 사용됩니다. 다양한 디바이스 환경에서 동일한 데이터를 동기화해야 할 필요성이 커졌습니다.

예를 들어 특정 서비스에서 ‘좋아요’ 수가 모든 디바이스에서 동일하게 보여야 한다면, 데이터는 하나의 공통 채널을 통해 관리되어야 합니다. 이러한 요구 속에서 앱이 등장했습니다.

앱은 설치형으로 동작하며, 네트워크가 끊기더라도 일부 기능을 제공할 수 있습니다. 또한 안면 인식, 지문 인식, 위치 기반 서비스 등 디바이스의 네이티브 기능을 활용할 수 있다는 장점이 있습니다. 웹은 HTML, CSS, 자바스크립트 기반으로 동작하기 때문에 네이티브 기능 활용에는 한계가 있습니다.
그러나 웹과 앱 모두 동일한 데이터를 기반으로 사용자 경험을 제공해야 하므로, 공통된 데이터 통신 방식이 필요합니다.

 

API와 REST API의 의미

이 공통 채널이 바로 API입니다. API는 웹과 앱이 서버와 데이터를 주고받을 수 있도록 하는 규약입니다. 최근에는 REST API 방식이 표준처럼 사용되고 있습니다. 과거에는 웹서버가 직접 데이터를 전달하는 구조가 많았지만, 현재는 REST API를 통해 필요한 데이터만을 전송하는 방식으로 발전했습니다. 데이터는 주로 JSON 형식으로 전달됩니다. JSON은 키-값 구조를 가지는 데이터 표현 방식으로, 다양한 디바이스와 시스템 간의 호환성을 높여줍니다.

이러한 표준화 덕분에 서로 다른 시스템 간에도 데이터 교환이 원활해졌습니다. 과거처럼 쿼리 형태나 파일 배치 방식에 의존하던 구조와는 달라진 모습입니다. API는 일반적인 인터페이스 개념을 의미하고, REST API는 그 중에서도 특정 규약을 따르는 방식입니다.

 

설계 관점에서의 API 이해

설계자는 한 페이지에 표시되는 정보가 내부 서버에서 오는 것인지, 외부 API를 통해 가져오는 것인지 구분할 수 있어야 합니다. 이를 명확히 정의하는 것이 설계의 일부입니다. 예를 들어 항공권 판매 서비스에서는 좌석 정보와 가격이 실시간으로 변경될 수 있습니다. 항공편 시간이나 가격 정보는 외부 API에서 가져오고, 일부 여행 정보는 내부 서버에서 관리될 수 있습니다. 페이지를 새로 고침했을 때 가격이 변경되는 현상 역시 외부 데이터 연동의 결과입니다. 또한 날씨 정보를 추가하려는 경우, 기상청 API를 활용하여 데이터를 가져올 수 있습니다. 이때 설계 단계에서 외부 데이터 출처와 연동 방식을 명확히 정의해야 합니다.

 

변화된 인프라 환경

현재는 물리적인 서버를 직접 운영하기보다 클라우드 컴퓨팅을 통해 가상화된 서버를 사용하는 경우가 많습니다. 과거에는 이벤트를 대비해 물리 서버를 미리 준비해야 했다면, 이제는 필요할 때 서버를 증설하고 종료 후에는 다시 줄일 수 있는 구조로 변화했습니다. 서버 운영이 훨씬 유연해진 것입니다.

설계는 IT 인프라, 서비스 정책, 요구사항, 사용성이라는 기반 위에서 이루어집니다. 특히 REST API와 JSON 기반의 데이터 통신 구조를 이해하는 것은 현대 설계에서 중요한 요소입니다. 데이터가 내부에서 오는지 외부 API를 통해 오는지 구분하고, 이를 화면 설계에 반영할 수 있어야 안정적인 설계를 완성할 수 있습니다. IT 인프라는 점점 복잡해지고 있지만, 그 기본 원리를 이해하면 설계의 안정성 역시 높아집니다.