IT 인프라에 대한 이해

(1) 전통 IT 인프라 구조

전통 IT 인프라

 

구성

- 웹 서버 (Web Server): 사용자 요청을 받아 전달. 일종의 '인포데스크' 역할

- 애플리케이션 서버 (WAS: Web Application Server): 비즈니스 로직을 처리

- 데이터베이스 서버 (DB Server): 실제 데이터 저장소

 

흐름

1) 사용자가 웹브라우저를 통해 로그인 요청

2) 웹서버가 요청을 받아 WAS에 전달

3) WAS가 DB에 쿼리를 날려 로그인 정보 확인

4) 결과를 다시 웹서버를 통해 사용자에게 전달 (ex: “로디님 안녕하세요.”)

 

특징

- 서버 역할 분리로 보안 강화, 전문성 향상

- 물리적 서버 사용 → 장비 도난/정전 사고 우려

 

 

(2) 모던 IT 인프라 

모던 IT 인프라

 

특징

- 서버 클라우드화: 서버를 클릭 몇 번으로 복제/축소 가능 → 유연성↑

- 디바이스 다양화: 모바일 앱, 모바일 웹, PC 웹 등 다양한 채널 등장

- REST API 방식 채택: 클라이언트 간 데이터 동기화에 효과적

 

표현 영역과 데이터 처리 영역 분리

- Front-End (모바일 앱/웹, PC 웹 등) ↔ Back-End (서버)

- 다양한 디바이스에서 동일한 데이터(예: '좋아요' 숫자)를 일관되게 제공 가능

 

데이터 형식

- API 통해 데이터를 JSON 또는 XML 형식으로 주고받음

 

 

(3) REST API

 

 

REST API

 

REST API와 화면설계의 이해

- REST API(Representational State Transfer API)는 2000년, HTTP의 창시자 중 한 명인 Roy Fielding이 제안한 방식으로, URI(Uniform Resource Identifier)를 통해 리소스에 접근하고, HTTP 메소드(GET, POST, PUT, DELETE 등)를 이용해 데이터를 주고받는 구조이다.

- REST API는 클라이언트가 특정 URI에 요청을 보내면, 서버는 JSON과 같은 형식으로 응답을 반환한다.
이를 통해 웹, 앱, 클라우드, 파트너 시스템 등 다양한 플랫폼 간 연결이 가능해집니다.

 

- 특히 REST API에서 주로 사용하는 JSON 방식은 속도가 빠르고, 키-값 구조로 되어 있어 가독성이 뛰어나며, 외부 데이터를 연동할 때 널리 활용되는 포맷이다.

 

 

기획 단계에서 REST API를 이해해야 하는 이유

- 실제 화면 설계를 할 때, 기획자는 화면에 표시되는 각 정보가 어디서 오는 데이터인지 반드시 명확히 파악해야 한다.

예를 들어, 날씨 정보를 화면에 표시해야 한다면, 그것이 내부 DB에 저장된 값인지, 혹은 기상청 API를 통해 실시간으로 불러오는 값인지 확인해야 한다. 이러한 데이터의 출처를 설계서에 명시함으로써 개발자와의 원활한 커뮤니케이션이 가능해진다.

특히 외부 API를 사용하는 경우에는 ‘전문 명세서(스펙 문서)’를 공유함으로써, 개발자가 API의 구조를 이해하고 정확히 연동할 수 있도록 해야 한다.

 

 

API 명세서와 화면설계의 관계

- API 명세서는 일반적으로 개발자가 작성하는 산출물로, 이 문서에는 해당 API의 데이터 구조, 요청 방식, 응답 포맷, 데이터 출처 등이 자세히 정의되어 있다.

- 기획자의 역할은 이 API 명세서를 바탕으로 어떤 데이터가 화면의 어느 위치에, 어떤 형태로 들어가야 하는지를 정의하는 것. 즉, 데이터를 어떻게 시각적으로 표현할 것인지, 어떤 레이아웃과 흐름으로 배치할 것인지에 대한 설계가 바로 기획자의 몫이다.

 

정리하자면

기획자가 REST API의 구조와 역할을 이해하는 이유는, 단순히 기술적인 이해를 넘어서 데이터의 출처와 성격에 따라 화면 구성과 설계를 구체화해야 하기 때문이다.

API 명세서를 이해하지 못하면, 실제 구현되는 화면에서 데이터가 누락되거나 오작동할 수 있으므로, 기획자는 API와 화면 설계 간의 연결고리를 명확히 이해하고 소통할 수 있어야 한다.