프론트 개발자가 바라보는 멱등성🔥

 

안녕하세요 메이토입니다 🍅 저저번달 아인슈타임 팀 백엔드 개발자가 테코톡 발표를 하다가 처음 "멱등성" 이라는 단어를 접하게 되었습니다 . 처음 들었을 때 굉장히 새로운 단어였는데 그때는 백엔드만 알아도 되는걸까 라고 생각했지만, 멱등성에 대해 알아보게 된 계기가 생겨 까먹지 않고자,, 프론트엔드 개발자가 바라본 멱등성에 대해 간략히 소개해보도록 하겠습니다.

 

우선 멱등성이란 무엇일까요?

 

동일한 요청을 한 번 보내는 것과 여러 번 연속을 보내는 것이 같은 효과를 지닐 때,

그리고 서버의 상태도 동일하게 남을 때 가지는 속성을 의미합니다.

아래 이미지를 보시면 Http method 마다 멱등성(Idempotent) 이 보장되는가 에 대해서 나타내고 있습니다.

(참고:ㅣ RFC editor- https://www.rfc-editor.org/rfc/rfc7231#section-8.1.3)

 

대표적으로 CRUD와 관련된 메서드인 GET, POST, PUT, PATCH, DELETE를 살펴보면, GET과 PUT, DELETE만 멱등성이 있다고 하는데, 각각 왜 멱등한지 살펴보면 다음과 같습니다.

 

1️⃣ GET

- 서버에 요청을 여러번 보내도 데이터가 바뀌지 않기 때문

 

2️⃣ PUT

- PATCH 와 다르게 여러 번 PUT 해도 동일하게 덮어쓰기 때문 (완전히 교체하는 방식)

 

3️⃣ DELETE

- 처음 요청하면 삭제가 되고, 삭제 요청을 여러번 더 해도 서버에서 삭제된 상태가 그대로 이기 때문

 

* 하지만, 어떤 리소스를 삭제하는지에 따라 멱등하지 않을 수도 있습니다

ex) DELETE 요청을 보낼 때마다 장바구니의 마지막 아이템을 삭제하는 경우 (요청 마다 서버 상태가 달라지기 때문)

 

POST와 PATCH 는 멱등하지 않다는 것인데 ,, 그렇다면 프론트엔드 관점에서는 멱등성을 어떻게 지킬 수 있을까요?

 

* PATCH는 경우에 따라 멱등할 수도 있다고 합니다 ! 왜일까요 ?

 

PATCH의 경우 우리가 알다시피 리소스의 "일부 필드" 만 수정할 때 사용되는데, 뭔가 고정값을 정해두고 요청을 여러번 보내도 결과가 변하지 않을 경우 멱등하다고도 할 수 있습니다.

 

* 요청 횟수에 따라 서버에 담기는 리소스의 결과가 달라질 경우 멱등하지 않겠죠?

 

프론트엔드와 멱등성

 

중복 요청 방지

POST가 멱등하지 않은 이유는 여러번 요청할 경우 그 때마다 새로운 리소스가 생성되기 때문입니다.

프론트엔드에서는 "등록" 버튼을 여러 번 연타하게 될 경우, 중복 요청 방지 처리를 안했을 때 누른 횟수만큼 요청이 가게 됩니다. 즉, 중복 리소스가 생기는 문제가 발생할 수 있기 때문입니다.

이를 방지하기 위해 가장 기본적으로 사용할 수 있는 방법은 로딩 상태에서 버튼을 비활성화하는 것입니다. 

저희 서비스인 "아인슈타임" 을 예시로 들어볼까요 ?

 

 

방을 만들기 위해 열심히 약속 정보를 입력하고 "방 만들기" 버튼을 연속으로 누를 경우,, 만약 아무 처리도 해주지 않는다면 방을 만드는 POST 요청이 중복으로 보내지게 되고, 결국 서버에는 중복된 방에 대한 리소스가 만들어지게 됩니다 !

그래서 isRoomCreateLoading 이라는 상태를 통해 방 만들기 요청을 보내면 바로 로딩 상태를 true 로 만들어 중복 요청이 되지 않도록 방지 해두었습니다.

<Button
    ref={submitButtonRef}
    color="primary"
    selected={true}
    size="small"
    onClick={handler.createRoom}
    data-ga-id="create-event-button"
    disabled={isRoomCreateLoading}
>
        <Text variant="button" color="background">
              {isRoomCreateLoading ? '생성 중...' : '방 만들기'}
        </Text>
</Button>

 

 

아인슈타임과 멱등성

 

SSE를 연결하고 GET 으로 지속적으로 stream 을 받고 있는데 이건 GET 이어도 멱등하지 않은 것이 아닌가?

* 서버의 상태 관점으로만 바라보면 지속적으로 변한 데이터 요청을 받아도 GET 요청 자체호 서버의 상태가 바뀌지 않으니 HTTP 자체는 멱등하다고 생각합니다.

(처음에는 서버 데이터가 바뀌니까 멱등하지 않은 것이 아닌가라고 생각했지만, "서버의 상태가 유지되어야 한다" 라는 관점에서는 확실히 바뀐 데이터만 조회를 해가는 상태이기 때문에 멱등하다는 결론으로 내려졌습니다 )

 

결국 멱등성은 단순히 서버나 HTTP 규약의 문제가 아니라,

사용자가 같은 행동을 반복해도 예측 가능한 결과를 얻는 경험을 만드는 데에 있습니다.

프론트엔드에서 멱등성을 고려한다는 건, 버튼을 한 번 더 눌러도 중복 데이터가 생기지 않게 하고,

네트워크가 잠시 끊겨도 UI가 안정적으로 유지되도록 설계하는 것을 의미합니다.

 

저 역시 “아인슈타임” 프로젝트를 진행하면서,

단순히 기능이 동작하는 것뿐 아니라 사용자 경험이 일관되게 유지되는 구조가 얼마나 중요한지를 다시 한 번 느꼈습니다.

 

앞으로도 이런 ‘예측 가능한 경험’을 만드는 것이 프론트엔드 개발자로서 지켜야 할 멱등성의 형태가 아닐까 생각합니다. 🍅