FAST(Functional Augmented State Transfer) : 고성능 네트워크 서비스용 REST + 함수형 프로그래밍 하이브리드 아키텍처

📝 Abstract

We describe a novel architecture that combines the simplicity of RESTful architecture with the power of functional programming for delivering web-services. Although, RESTful architecture has been quite useful in simplifying the development of scalable systems, it is not suited for all types of network applications. Our architecture improves upon the RESTful architecture to provide scalable framework for computationally intensive network applications. The proposed architecture is ideal for applications that involve data management and data analysis/calculations on data. Data analytics and financial calculations are two areas where the architecture can be applied efficiently.

💡 Analysis

**

1. 연구 배경 및 문제 정의

• REST의 장점(단순성, HATEOAS, 무상태)과 한계(자원을 URI에 매핑해야 하는 구조적 제약) 를 명확히 제시.
• 실제 사례(Facebook·Yahoo)에서 REST를 변형하거나 다른 모델(Graph, YQL)로 전환한 점을 근거로, ‘리소스‑중심’ 설계가 모든 도메인에 적합하지 않음을 설득력 있게 설명한다.

2. 제안된 FAST 아키텍처

• 함수 호출 방식: GET /lambda/get_weather?lat=...&lon=... 와 같이 기존 HTTP 메서드를 그대로 사용하면서도 함수형 파라미터 전달이 가능하도록 설계.
• 고차 함수·맵·리듀스: 한 번의 요청에 여러 함수를 적용하거나, 함수 결과를 다른 함수의 입력으로 재사용하는 파이프라인 형태를 지원한다(예: 옵션 가격·델타·감마·베가 동시 계산).

3. 주요 기여 및 혁신성

4. 강점

1. 이론적 설계가 명료 – REST와 함수형을 각각 독립된 서버로 분리함으로써 책임을 명확히 함.
2. 실제 적용 사례 제시(기상·금융 포트폴리오)로 도메인 적합성을 강조.
3. URI 폭발 문제 해결 – 연속 파라미터를 함수 호출로 대체해 무한 URI 생성 문제를 회피.
4. 확장성 – 고차 함수, 파이프라인, 중첩 호출 등 복잡한 연산 흐름을 선언형으로 표현 가능.

5. 약점 및 개선점

6. 잠재적 영향 및 활용 분야

• 데이터 분석 파이프라인: 대규모 로그·시계열 데이터에 대한 실시간 집계·통계 함수를 REST와 결합해 마이크로서비스 형태로 제공.
• 금융·옵션 가격 계산: 복잡한 수식(Black‑Scholes 등)을 함수형 모듈로 캡슐화하고, REST를 통해 포트폴리오 데이터를 전달 → 고성능 실시간 리스크 관리.
• IoT·스마트 시티: 센서 데이터(위치·시간 연속값)를 함수 호출로 처리해 실시간 이벤트를 생성, 기존 REST 기반 대시보드와 연동.
• 머신러닝 서빙: 모델 추론을 순수 함수로 구현하고, REST를 통해 입력 데이터를 관리·버전 관리함으로써 A/B 테스트와 모델 파이프라인을 깔끔히 분리.

7. 향후 연구 방향

1. 표준화 작업 – IETF/WS‑API와 협업해 FAST를 공식 API 스타일(예: application/fast+json)로 정의.
2. 서버리스 구현 – AWS Lambda·Azure Functions와 같은 서버리스 플랫폼에 Lambda 머신을 매핑해 비용 효율성 검증.
3. 자동 최적화 – 함수 호출 그래프를 분석해 동적 병렬 스케줄링 및 캐시 프리페치 전략을 적용하는 런타임 개발.
4. 멀티‑클라우드 배포 – REST와 Lambda를 서로 다른 클라우드 영역에 배치해 지연 최소화와 가용성 향상.

**

📄 Content

FAST(Functional Augmented State Transfer) 아키텍처
컴퓨팅 집약적인 네트워크 애플리케이션을 위한 설계
GOPI KRISHNA SUVANAM¹

초록

본 논문에서는 RESTful 아키텍처의 단순함과 함수형 프로그래밍의 강력함을 결합한 새로운 아키텍처를 제시한다. RESTful 아키텍처는 확장 가능한 시스템을 손쉽게 구축하도록 도와주지만, 모든 종류의 네트워크 애플리케이션에 적합하지는 않다. 제안하는 아키텍처는 RESTful 구조를 개선하여 컴퓨팅 집약적인 네트워크 애플리케이션을 위한 확장 가능한 프레임워크를 제공한다. 데이터 관리와 데이터 분석·계산을 수행하는 애플리케이션에 특히 적합하며, 데이터 분석 및 금융 계산 분야에 효율적으로 적용될 수 있다.

키워드: 웹 서비스, RESTful 아키텍처, 함수형 프로그래밍, 네트워크 애플리케이션

1 RESTful 아키텍처

RESTful 아키텍처는 하이퍼미디어를 이용해 분산 애플리케이션을 구축하기 위한 설계 양식이다. 그 단순성과 완전성 덕분에 많은 웹 애플리케이션에서 널리 사용되고 있으며, SOAP 아키텍처보다 우위에 서 있다[2]. 특히 모바일·클라우드 컴퓨팅이 급성장하면서 RESTful 웹 서비스의 인기는 더욱 높아졌다[3].

RESTful 아키텍처의 핵심은 클라이언트와 서버의 결합도를 낮추는 것이다. 클라이언트는 사전에 API를 학습할 필요 없이 서비스를 이용할 수 있으며, 이는 확장 가능한 개발을 가능하게 한다. 클라이언트는 서버의 API를 “탐색(browse)”하면서 런타임에 기능을 발견할 수 있는데, 이를 HATEOAS(Hypermedia As The Engine Of Application State) 라고 부른다[4].

2 RESTful 아키텍처의 한계

RESTful 아키텍처가 제공하는 장점에도 불구하고, 언제나 엄격히 따르는 것이 현실적으로 어려운 경우가 있다. 여러 온라인 서비스가 RESTful 구조에 유연성을 부여하거나 완전히 새로운 아키텍처로 전환하고 있다. 대표적인 사례가 Facebook이 RESTful 에서 그래프 기반 아키텍처로 전환한 경우이다[5]. Yahoo는 YQL이라는 질의 언어를 도입했으며, 소셜 데이터에 대한 REST API를 제공하지만 완전한 RESTful 원칙을 따르지는 않는다.

이러한 변형은 RESTful 아키텍처 자체에 내재된 간극에서 비롯된다. REST는 월드와이드웹(WWW)과 HTTP 프로토콜의 등장과 동시에 설계되었으며, “문서(document)” 중심의 사고방식에 크게 의존한다[6]. 웹이 정적 문서 제공에서 시작했지만, 시간이 흐르면서 풍부한 동적 플랫폼으로 진화했음에도 불구하고 문서 중심 편향은 여전히 남아 있다. Roy Fielding이 말했듯이

“REST에서 정보의 핵심 추상화는 **리소스(resource)**이다. 이름을 붙일 수 있는 모든 정보—문서, 이미지, 일시적인 서비스(예: ‘오늘 로스앤젤레스의 날씨’), 다른 리소스들의 집합, 비가상 객체(예: 사람) 등—가 리소스가 될 수 있다.”[7]

리소스‑표현 방식은 특정 애플리케이션에 구조적 제약을 만든다. 예를 들어, 위치 기반 날씨 정보를 조회하려면

/weather/LA
/weather/35.05/118.25

와 같은 URI를 사용한다. 하지만 세부 지역까지 정확히 지정하려면

/weather/35.050456/118.25090

처럼 무한히 많은 URI가 필요하게 된다. 연속적인 위·경도 값은 이론적으로 무한한 조합을 만들며, 이를 RESTful 방식으로 모두 표현하려면 URI 폭발 문제가 발생한다.

우회 방법으로는

1. POST /mylocation { "lat":35.050456, "long":118.25090 }
2. GET /mylocation/weather

와 같이 두 단계에 걸쳐 정보를 전달할 수 있다. 그러나 이는 REST의 탈결합(de‑coupled) 철학에 위배되는 핵심적인 해킹이라 볼 수 있다.

대안은 함수형 프로그래밍에서 영감을 얻어, “날씨를 함수로 표현하고 get_weather(35.050456,118.25090) 와 같이 호출하는 방식**을 도입하는 것이다. 이러한 함수가 웹 서비스 형태로 노출된다면, GET/POST 외에도 다양한 호출 방법을 제공하면서도 REST의 무상태성(statelessness)·자원 중심 원칙을 유지할 수 있다.

3 함수형 프로그래밍의 장점

함수형 프로그래밍은 명령형이 아닌 함수 평가를 중심으로 계산을 수행한다. 선언형(paradigm) 프로그래밍의 일종으로, “무엇을 할 것인가”를 기술하고 “어떻게 할 것인가”는 컴파일러·런타임에 맡긴다. 핵심 원칙은 **불변성(immutability)**과 **부작용 없는 실행(side‑effect‑free)**이다.

함수형 프로그래밍이 제공하는 주요 이점은 다음과 같다.

과거에는 함수형 프로그래밍이 성능이 낮다는 인식이 있었지만, 현대의 저렴한 컴퓨팅 파워와 최적화된 런타임 덕분에 그 격차는 크게 줄어들었다[8].

4 제안하는 FAST 아키텍처

RESTful 아키텍처에서 가장 큰 장점은 무상태성이다[9]. 이는 클라이언트와 서버를 깔끔하게 분리하고, 다음과 같은 부가 효과를 만든다.

• 캐시 최적화
• 연결 지속성에 대한 의존성 감소
• 다중 접근 및 큐잉 지원

FAST 아키텍처는 이 무상태성을 유지하면서 함수형 기능을 추가한다. 구체적으로 서버를 두 부분으로 나눈다.

1. REST 서버 – 전통적인 CRUD 작업을 담당 (REST Machine)
2. 함수형 서버 – 함수 호출을 담당 (Lambda Machine)

순수 함수형 서버가 만족해야 할 조건

1. 동일 입력에 대해 언제나 동일한 응답을 반환한다.
2. 두 요청은 순서와 무관하게 실행해도 결과가 같다.
3. 모든 입력·출력은 불변이다.

실제 서비스에서는 전역 상태가 지속적으로 변하기 때문에 순수 함수형 서버만으로는 충분하지 않다. 예를 들어, 로스앤젤레스의 날씨는 매분 변하므로 get_weather(34.05,118.25)는 호출 시점에 따라 다른 값을 반환한다. 따라서 REST Machine과 Lambda Machine을 결합한 하이브리드 구조가 필요하다.

FAST 프레임워크 동작 흐름

• REST Machine은 POST, GET, PUT, DELETE 등 전통적인 리소스 조작을 제공한다.
• 동적으로 생성되는 리소스가 필요하면, REST API는 내부적으로 Lambda Machine에 질의하여 결과를 얻는다.
• Lambda Machine은 부작용이 없으며, 모든 데이터는 불변이다. 가변 데이터는 REST Server에 저장된다.
• 클라이언트는 함수 호출과 리소스 접근을 동일한 엔드포인트(FAST API)를 통해 수행한다.

Lambda Machine의 핵심 원칙

• 호출 시 부작용이 없어야 한다.
• 내부 데이터는 불변이며, 가변 데이터는 REST Server에 보관한다.
• 클라이언트는 함수명과 파라미터만 전달하면 된다.

비록 RPC와 유사해 보이지만, Lambda Machine은 FAST Server와의 결합도가 낮다는 점에서 차별화된다.

FAST API가 지원하는 호출 유형

1. 리소스 CRUD (GET, POST, PUT, DELETE)
2. 함수 호출 – 파라미터 집합에 대한 함수 실행 및 결과 반환
3. 리소스에 함수 적용 – 예: POST /fast/pricer/get_value 로 계산 결과를 특정 리소스에 저장
4. 함수 체이닝 – 한 함수의 결과를 다른 함수의 입력으로 사용

선언형 템플릿 예시 (Table 1)

이 글은 AI가 자동 번역 및 요약한 내용입니다.