Two Approaches To Decoupling

Carson Gross

May 01, 2022

REST 아키텍처 스타일이 다른 네트워크 기반 스타일과 구별되는 중심 기능은 구성 요소 간의 일관된 인터페이스에 중점을 둔다는 점입니다. 소프트웨어 엔지니어링의 일반성 원칙을 구성 요소 인터페이스에 적용함으로써 전체 시스템 아키텍처가 단순화되고 상호작용의 가시성이 향상됩니다. 구현은 제공하는 서비스와 분리되며, 이는 독립적인 발전 가능성을 촉진합니다.

-Roy Fielding, https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_5

이 에세이에서는 웹 애플리케이션의 맥락에서 두 가지 유형의 결합 해제(Decoupling)를 살펴보겠습니다:

애플리케이션 수준에서의 JSON 데이터 API를 통한 결합 해제
네트워크 아키텍처 수준에서의 하이퍼미디어 API를 통한 결합 해제

우리는 애플리케이션 수준에서는 하이퍼미디어 API가 프론트엔드와 백엔드를 긴밀하게 결합시키지만, 이 사실에도 불구하고 하이퍼미디어 API가 변화에 더 잘 견디는 경향이 있음을 알게 될 것입니다.

#결합(Coupling)

결합(Coupling)은 소프트웨어 시스템에서 두 개의 모듈이나 시스템의 측면이 높은 상호 의존성을 가지는 특성을 말합니다. **결합 해제(Decoupling)**는 이와 관련이 없는 모듈 간의 상호 의존성을 줄여 독립적으로 발전할 수 있도록 하는 행위입니다.

결합 및 결합 해제 개념은 응집력(Cohesion)과 밀접하게 (그리고 반대로) 연관되어 있습니다. 응집력이 높은 소프트웨어는 관련된 논리가 모듈이나 개념적 경계 내에 존재하며, 코드베이스 전체에 퍼지지 않습니다. (관련 개념으로는 우리의 행동의 지역성 아이디어가 있습니다.)

일반적으로 경험이 많은 개발자들은 결합 해제되고 응집력 있는 시스템을 지향합니다.

#JSON 데이터 API - 애플리케이션 수준의 결합 해제

오늘날 웹 애플리케이션을 구축하는 일반적인 접근 방식은 JSON 데이터 API를 생성하고 이를 React와 같은 JavaScript 프레임워크를 사용하여 소비하는 것입니다. 이 애플리케이션 수준의 아키텍처 결정은 프론트엔드 코드와 백엔드 코드를 분리하고, 이 JSON API를 모바일 애플리케이션, 타사 클라이언트 통합 등과 같은 다른 컨텍스트에서 재사용할 수 있게 합니다.

이는 애플리케이션 수준의 결합 해제입니다. 왜냐하면 결합 해제의 결정과 구현이 애플리케이션 개발자에 의해 이루어지기 때문입니다. JSON API는 소프트웨어의 두 부분 사이에 “단단한” 인터페이스를 제공합니다.

제가 좋아하는 예시를 사용하여, https://example.com/account/12345에 GET 엔드포인트를 가지고 있는 은행을 위한 간단한 JSON을 고려해보겠습니다. 이 API는 다음과 같은 내용을 반환할 수 있습니다:

HTTP/1.1 200 OK

{
    "account": {
        "account_number": 12345,
        "balance": {
            "currency": "usd",
            "value": -50.00
        },
        "status": "overdrawn"
    }
}

이 데이터 API는 웹 애플리케이션, 모바일 클라이언트, 타사 등 어떤 클라이언트에서도 소비할 수 있습니다. 따라서 특정 클라이언트에 종속되지 않습니다.

#JSON API를 통한 결합 해제의 실제 사례

지금까지는 잘 되었습니다. 하지만 이 결합 해제가 실제로는 어떻게 작동할까요?

우리의 에세이 Splitting Your Data & Application APIs: Going Further에서 다음과 같은 인용문을 찾을 수 있습니다:

요즘 내 일에서 가장 어려운 부분은 프론트엔드 개발자를 위해 API를 설계하는 것입니다. 대화는 불가피하게 다음과 같이 진행됩니다:

Dev – 이 화면에는 데이터 요소 x, y, z가 있습니다… 이 형식의 응답을 제공하는 API를 만들어 주실 수 있나요? {x: , y:, z: }

Me – 알겠습니다.

Jean-Jacques Dubray - https://www.infoq.com/articles/no-more-mvc-frameworks

이 인용문은 우리가 결합을 피치포크로 (또는 우리의 경우 JSON API로) 몰아냈지만, 웹 애플리케이션 전용 JSON API 엔드포인트에 대한 요청을 통해 다시 돌아왔음을 보여줍니다. 이러한 요청은 프론트엔드와 백엔드 코드를 다시 결합시킵니다: JSON API는 더 이상 일반적인 JSON 데이터 API를 제공하지 않고, 대신 프론트엔드의 특정 요구에 맞는 API를 제공하게 됩니다.

더 나쁜 것은, 애플리케이션이 발전함에 따라 프론트엔드의 요구 사항이 자주 변경될 수 있으며, 이는 JSON API의 수정을 필요로 한다는 것입니다. 만약 다른 비웹 애플리케이션 클라이언트가 원래의 API에 의존하게 된다면 어떻게 될까요?

이 문제는 웹 애플리케이션과 다른 비웹 애플리케이션 클라이언트를 지원할 때 많은 JSON 데이터 API 개발자들이 직면하는 “버전 관리 지옥“으로 이어집니다.

#해결책: GraphQL

이 문제에 대한 한 가지 잠재적인 해결책은 GraphQL을 도입하는 것입니다. GraphQL을 사용하면 API 클라이언트의 요구가 변경될 때마다 API를 자주 변경하지 않아도 되는 훨씬 더 표현력 있는 JSON API를 가질 수 있습니다.

이것은 위에서 설명한 문제를 해결하기 위한 합리적인 접근 방식이지만, 몇 가지 문제가 있습니다. 우리가 API 변동성/보안 절충안 에세이에서 설명한 바와 같이, 가장 큰 문제는 보안입니다.

Facebook은 허용 목록을 사용하여 GraphQL이 도입하는 보안 문제를 처리하는 것 같습니다. 그러나 GraphQL을 사용하는 많은 개발자들이 관련된 보안 위협을 이해하지 못하는 것 같습니다.

#또 다른 해결책: 애플리케이션 및 일반 데이터 API 분리

또 다른 접근 방식으로는, Max Chernyak이 그의 기사 Don’t Build A General Purpose API To Power Your Own Front End에서 제안한 방법입니다. 이 접근 방식은 두 가지 JSON API를 구축하는 것입니다:

필요에 따라 수정할 수 있는 애플리케이션 전용 JSON API
모바일 등 다른 클라이언트에서 소비할 수 있는 일반적인 JSON API

이것은 여러분의 웹 애플리케이션의 프론트엔드와 이를 지원하는 백엔드 코드 간의 본질적인 결합을 해결하기 위한 실용적인 해결책이며, 일반적인 GraphQL API에서 발생하는 보안 절충점을 포함하지 않습니다.

#하이퍼미디어 - 네트워크 아키텍처 결합 해제

이제 하이퍼미디어 API가 소프트웨어를 어떻게 결합 해제하는지 살펴보겠습니다.

위에서 본 https://example.com/account/12345에 대한 동일한 GET 요청에 대한 잠재적인 응답을 고려해보세요:

HTTP/1.1 200 OK

<html>
  <body>
    <div>계좌 번호: 12345</div>
    <div>잔액: $100.00 USD</div>
    <div>링크:
        <a href="/accounts/12345/deposits">예금</a>
        <a href="/accounts/12345/withdrawals">출금</a>
        <a href="/accounts/12345/transfers">송금</a>
        <a href="/accounts/12345/close-requests">계좌 해지</a>
    </div>
  <body>
</html>

(네, 이것은 API 응답입니다. 이번 경우에는 하이퍼미디어 형식의 응답이며, HTML로 제공됩니다.)

여기서 볼 수 있듯이, 애플리케이션 수준에서 이 응답은 “프론트엔드“와 더 긴밀하게 결합될 수 없습니다. 사실, 이 응답은 리소스에 대한 데이터뿐만 아니라 이 데이터를 사용자에게 어떻게 정확히 표시할지에 대한 레이아웃 정보도 제공하기 때문에 프론트엔드 자체입니다.

응답에는 하이퍼미디어 제어 요소, 이 경우에는 링크가 포함되어 있어 사용자가 이 하이퍼미디어 기반 애플리케이션이 제공하는 하이퍼미디어 API를 계속 탐색할 수 있습니다.

그렇다면, 이 경우 결합 해제는 어디에서 일어나고 있을까요?

#REST & 일관된 인터페이스

이 경우 결합 해제는 더 낮은 수준에서 발생하고 있습니다. 즉, 네트워크 아키텍처 수준에서 시스템 수준으로 발생합니다. 하이퍼미디어 시스템은 하이퍼미디어 클라이언트(웹의 경우, 브라우저)를 하이퍼미디어 서버에서 결합 해제하도록 설계되었습니다.

이는 REST의 일관된 인터페이스 제약 조건을 통해, 특히 애플리케이션 상태의 엔진으로서의 하이퍼미디어(HATOEAS)를 사용하여 주로 달성됩니다.

이러한 스타일의 결합 해제는 더 높은 애플리케이션 수준에서 더 긴밀한 결합을 허용하면서(이는 본질적인 결합일 수 있음) 전체 시스템의 결합 해제의 이점을 여전히 유지합니다.

#하이퍼미디어를 통한 결합 해제의 실제 사례

이러한 결합 해제가 실제로 어떻게 작동하는지 살펴보겠습니다. 은행 계좌에서 다른 은행으로 송금하는 기능과 계좌를 해지하는 기능을 제거하고 싶다고 가정해보겠습니다.

이 GET 요청에 대한 하이퍼미디어 응답은 어떻게 보일까요?

HTTP/1.1 200 OK

<html>
  <body>
    <div>계좌 번호: 12345</div>
    <div>잔액: $100.00 USD</div>
    <div>링크:
        <a href="/accounts/12345/deposits">예금</a>
        <a href="/accounts/12345/withdrawals">출금</a>
    </div>
  <body>
</html>

이 응답에서는 HTML에서 해당 두 작업에 대한 링크가 제거된 것을 볼 수 있습니다. 브라우저는 단순히 새 HTML을 사용자에게 렌더링합니다. 거의 모든 클라이언트가 이전 API를 사용하지 않게 됩니다. API는 하이퍼미디어 내에 인코딩되고 하이퍼미디어를 통해 발견됩니다.

이것은 클라이언트를 손상시키지 않고 API를 크게 변경할 수 있음을 의미합니다.

이 유연성은 REST-ful 네트워크 아키텍처, 특히 HATEOAS의 핵심입니다.

보시다시피, 우리의 프론트엔드와 백엔드 간의 애플리케이션 수준 결합이 훨씬 더 긴밀해졌음에도 불구하고, REST-ful 하이퍼미디어 시스템이 제공하는 일관된 인터페이스 측면에서 네트워크 아키텍처 결합 해제 덕분에 우리는 더 큰 유연성을 갖게 됩니다.

#하지만 이것은 끔찍한 (데이터) API입니다!

많은 사람들이 이 하이퍼미디어 API가 웹 애플리케이션에는 유연할 수 있지만, 일반적인 API로서는 끔찍하다고 반박할 수 있습니다.

이것은 사실입니다. 이 하이퍼미디어 API는 특정 웹 애플리케이션에 맞게 조정되었습니다. 이 HTML을 다운로드하고 구문 분석하여 정보를 추출하려고 하면 번거롭고 오류가 발생하기 쉽습니다. 이 하이퍼미디어 API는 적절한 하이퍼미디어 클라이언트가 소비하는 더 큰 하이퍼미디어 시스템의 일부로서만 의미가 있습니다.

바로 이 이유 때문에 우리는 Splitting Your Data & Application APIs: Going Further에서 하이퍼미디어 API와 함께 일반적인 JSON API를 생성할 것을 권장합니다. 이렇게 하면 하이퍼미디어의 유연성을 웹 애플리케이션에서 활용하는 동시에 모바일 애플리케이션, 타사 애플리케이션 등을 위한 일반적인 JSON API를 제공할 수 있습니다.

(참고로, 하이퍼미디어 기반 모바일 애플리케이션도 좋은 선택일 수 있습니다!)

#결론

이 에세이에서는 두 가지 유형의 결합 해제에 대해 살펴보았습니다:

JSON 데이터 API를 통한 애플리케이션 수준의 결합 해제
하이퍼미디어 시스템에서 REST/HATEOAS를 통한 네트워크 아키텍처 결합 해제

그리고 하이퍼미디어 기반 애플리케이션에서 더 긴밀한 애플리케이션 수준 결합이 있음에도 불구하고, 하이퍼미디어 시스템이 변화에 더 잘 대응할 수 있다는 것을 확인했습니다.

</>