# 반응형 프로그래밍에 대한 이해 📨 지난 | 커리어리

# 반응형 프로그래밍에 대한 이해 📨 지난 새해 계획에서 소개해드린 것처럼, 저는 요즘 틈틈이 Reactive 프로그래밍에 대한 글을 찾아보며 익히고 있습니다. 프론트엔드에 대해 유익하고 깊은 글을 많이 써주시는 Teo님께서 마침 반응형 프로그래밍에 대해 다루어주셔서 정리 내용을 공유합니다.(예시도 잘 되어있으니, 원본 글도 함께 보기실 추천합니다!) <프로그래밍에서 패러다임이란> • 프로그래밍에서 패러다임은 프로그래밍의 관점을 갖게 해주고 결정하는 것으로, 간단히 '어떠한 관점으로 설계를 하느냐'입니다. 목적이 같더라도 관점에 따라서 다른 형태가 됩니다. 객체지향은 프로그램을 상호작용하는 객체들의 집합으로 보고, 함수형 프로그래밍은 프로그램을 상태값이 없는 함수값의 연속으로 생각하게 해줍니다. • 잘 만들어진 프로그래밍 패러다임은 보다 좋은 프로그램을 만드는 방법과 시각을 제공합니다. 나아가 여러 패러다임을 안다면, 상황별로 그 상황을 '더 간결하고 단순하게 설명하는 관점'을 선택할 수 있습니다. • 현대의 프로그램은 하나의 패러다임만 취하는 게 아니라, 여러 패러다임을 함께 섞어서 사용하려는 시도가 늘고 있습니다. 반응형 프로그래밍도 프로그래밍 관점을 갖게하고 결정하는 하나의 패러다임입니다. <반응형 프로그래밍이란> • 반응형(Reactive) 프로그래밍이란, '데이터의 흐름'과 '변경사항의 전파'에 중점을 둔 '선언적 프로그래밍' 패러다임입니다. 가장 친숙한 예는 스프레드 시트(엑셀)입니다. 하나의 셀에 다른 셀을 사용하는 수식을 '선언'해두면, 다른 셀의 값이 변경되면 '변경사항이 전파'되어 수식의 값도 변경되지요. 이런 수식이 중첩되어 있다면, 변경사항이 '데이터의 흐름'도 만들어집니다. • 웹 개발에서 반응형 프로그래밍이 중요해진 계기는 웹 프레임워크 전환이 있습니다. MVVM 패턴을 따르는 웹 프레임워크의 본질은 "'값이 변경'되었을 때 '템플릿에 선언' 해둔대로 알아서 렌더링을 해준다"인데요, 반응형의 정의와 유사합니다. • 또한 웹 프레임워크의 핵심은 어떻게 동작하는 지가 아니라 무엇을 해야할지 '선언'해서 내부에서 적절하게 렌더링하는 방식입니다. 이는 선언적 프로그래밍으로 명령형 프로그래밍에 비해 가독성, 재사용성, 독립성, 유지보수 면에서 좋습니다. • '선언'으로 변화는 데이터를 대하는 방식도 변경했습니다. 기존에는 Pull의 관점에서 렌더링할 때필요한 데이터를 모두 불러왔다면, 이제 Push의 관점으로 값이 변화할 때마다 템플릿으로 데이터를 전달합니다. 초기에는 반응형이 뷰에 집중되었다면, 이제 비즈니스 로직 전반으로 개념이 확장되었습니다. <비동기 프로그램와 반응형 프로그래밍> • 프론트엔드에서 반응형 프로그래밍이 중요한 다른 이유는 비동기 프로그래밍을 잘하기 위해서 입니다. 프론드엔드를 사용하는 사람의 동작과 서버의 응답시간을 예측할 수 없기 때문에, 대부분의 프론트엔드 로직은 비동기로 되어 있습니다. • 비동기 프로그래밍은 코드 작성 순서대로 동작하지 않으며, 언제 실행이 될지 예측할 수 없고, 호출 순서대로 동작한다는 보장과 호출 당시의 값과 실제 실행 값이 그대로일 거라는 보장이 없습니다. Rx와 반응형 프로그래밍은 이런 어려운 비동기 상황을 더 잘 대응합니다. • 반응형 프로그래밍은 '데이터의 변경을 템플릿에 반영하는 일'을 [데이터의 변경/템플릿 반영]으로 나눕니다. 이때 참조의 주체는 [템플릿 반영]하는 쪽입니다. [데이터의 변경]쪽은 그저 데이터가 변경될 때 전달만 하면 됩니다. 이렇게 하면 캡슐화와 느슨한 결합이 용이해지고, 모듈간의 책임이 확실해지며 확장이 쉬워집니다. <ReactiveX; Rx> • ReactiveX는 관측가능한 스트림을 통해 비동기 프로그래밍을 하기 위한 API(An API for asynchronous programming with observable streams)입니다. Rx는 단순한 API라기 보다 새로운 패러다임인 반응형 프로그래밍에 가깝습니다. • 반응형 프로그래밍은 [데이터의 변경]을 [템블릿 반영]하는데, 이를 Event라고 할 수 있습니다. Rx는 이벤트의 종류를 Next, Error, Complete 타입으로 정의하여 보편적인 상황을 처리합니다. Next는 일반적인 이벤트, Error는 에러난 상황, Complete는 더 이상 이벤트가 없는 상황입니다. 이런 이벤트가 여러개 연결될 때, 이벤트는 값으로 다루어 집니다. • 이렇게 보편적인 상황을 모두 다루는 형태를 Stream이라고 할 수 있습니다. 반응형 프로그래밍이란 '스트림을 선언적으로 작성하는 프로그래밍 패러다임'이라고 할 수 있습니다.

프로그래밍 패러다임과 반응형 프로그래밍 그리고 Rx

Velog

2022년 2월 6일 오후 2:04

댓글 0

함께 보면 더 좋은

# 카카오페이지 사례로 알아보는 Backend For Frontend(BFF) 📑 테오님이 잘 정리해주신 것처럼, 프론트엔드의 업무는 크게 ⑴데이터 보여주기, ⑵데이터(화면) 조작하기, ⑶서버로 데이터 보내기, ⑷서버에서 받은 데이터를 다루기로 나눌 수 있습니다. '⑷서버에서 받은 데이터를 다루기'를 잘하기 위해서, 데이터를 보내주는 서버팀과 지속적인 협업이 필요합니다. 이 협업과 업무를 더 잘하기 위한 방법으로 Backend For Frontend(BFF)가 있습니다. 개념적으로만 들었던 BFF를 멋진 동료인 카카오페이지 FE팀에서 사례를 다루어주어 공유합니다. <Backend For Frontend> • 규모가 큰 앱은 여러 마이크로서비스와 여러 플랫폼이 있을 수 있습니다. 여러 플랫폼이 여러 마이크로서비스의 데이터를 사용하게 되면, 프론트엔드는 여러 데이터를 're-format' 해야 합니다. 다른 의미로 데이터를 필터링하고 포맷팅하는 데 추가적인 자원을 쓴다는 것입니다. • BFF는 프론트엔드의 이런 데이터 처리를 대신 해주는 중간 레이어 입니다. 프론트엔드는 API를 직접 호출하지 않고 BFF에게 데이터를 요청합니다. BFF는 응답에 필요한 여러 데이터를 마이크로서비스에게 대신 요청하여 받아옵니다. 그리고 적절한 포맷을 바꾸어 프론트엔드에게 다시 알려줍니다. 결과적으로 프론트엔드는 데이터 요청 로직이 간단해지고, 인터페이스에 더욱 집중할 수 있습니다. • 단일 플랫폼에 하나의 서비스만 제공하는 애플리케이션이라면 BFF는 불필요 합니다. 그러나 여러 서비스를 제공하고, 여러 프론트엔드를 지원한다면 BFF는 적절한 선택입니다. BFF는 브라우저, 모바일 앱, 서드 파티 서비스 등 플랫폼의 종류 별로 두게 됩니다. 각 BFF는 각 플랫폼에 필요한 포맷과 데이터를 제공하는 역할을 합니다. <카카오페이지의 BFF> • 카카오페이지는 여러 플랫폼(Web, Android, iOS)을 지원하고, 여러 서비스의 데이터를 사용하고 있습니다. 그런데 BFF 없이 모든 플랫폼이 API에 다이렉트로 접근하면, API 엔드포인트가 분리되거나 스팩을 맞춰야 할때 큰 비용이 듭니다. 웹 프론트엔드는 생산성을 더욱 높이기 위해 BFF를 적용하였습니다. • Web BFF는 브라우저의 CORS 처리, 인증 처리, 데이터 호출을 담당하여, 프론트엔드 개발자는 화면에 집중할 수 있습니다 . Web BFF는 프론트엔드 플랫폼에 최적화되며 프론트엔드의 요구사항을 충족하기 때문에, 서버가 아니라 프론트엔드 개발자에게 구현과 안정성의 책임이 있습니다. • 여러 API를 호출하는 경우, 일반적으로 응답 값을 받아 상태관리에 저장하게 됩니다. 이 때 프론트엔드에서 필요하지 않은 값들이 올 수도 있고, 필요할 때마다 상태관리에서 연산을 하게 됩니다. GraphQL로 BFF를 적용한 후, API를 POST로 요청하고 브라우저의 캐시 대신 라이브러리의 캐시에 저장하게 되었습니다. 그리고 불필요한 값은 제거하여 프론트엔드에게 전달합니다. <GraphQL에 Redux로 보완> • 그런데 Apollo GraphQL의 Client 캐시는 카카오페이지 웹 적용에 이슈가 있었습니다. Apollo Client는 정규화 캐싱 정책을 따르는데, 쿼리도 기본적으로 CACHE ID를 사용해 모든 데이터를 store에 저장합니다. 따라서 레이아웃만 같고 데이터가 다른 여러 뷰가 동시에 그려진다면, 쿼리 호출 순서에 의해 의도와 다른 저장값이 나오는 이슈가 있었습니다 . • 카카오페이지 프론트엔드는 id 방식으로 캐싱하는 Apollo Client 대신 document 방식으로 캐싱하는 URQL을 사용하게 되었습니다. 또한 redux도 추가하게 되었습니다. GraphQL과 URQL만으로는 사용자의 클릭 이벤트가 발생하거나 스크롤로 데이터가 추가되는 등 비동기 상황의 복잡성까지 줄이지 못했기 때문입니다. URQL은 데이터를 fetch하고, 화면에 사용되는 데이터 저장은 redux에 하게 되었습니다. • 결과적으로 Web BFF를 통해, 비즈니스 로직과 데이터 처리 부분을 분리하여 복잡도를 낮출 수 있었습니다. ⟪참고⟫ - 테오의 프론트엔드. "시니어 개발자가 말하는, 프론트엔드 업무와 잘하는 프론트엔드 개발자란", 2022.1.24, https://yozm.wishket.com/magazine/detail/1294/ - Viduni Wickramarachchi, "The BFF Pattern (Backend for Frontend): An Introduction", 2021.2.24, https://blog.bitsrc.io/bff-pattern-backend-for-frontend-an-introduction-e4fa965128bf

카카오페이지는 BFF(Backend For Frontend)를 어떻게 적용했을까?

Kakaoent

추천 프로필

현직자에게 업계 주요 소식을 받아보세요.

현직자들의 '진짜 인사이트'가 담긴 업계 주요 소식을 받아보세요.

커리어리 | 일잘러들의 커리어 SNS