ETag 헤더, 낙관적 동시성 제어에 안전하게 사용할 수 있을까?

게시글은 낙관적 동시성 제어를 위해 ETag 헤더(ETag Header)를 활용하는 방법을 제시한다. 특히, If-Match 헤더를 사용하여 클라이언트 측에서 서버로 데이터 변경 요청 시, 예상되는 데이터 버전을 함께 전송하도록 한다. 서버는 ETag 값을 비교하여 일치하지 않으면 412 Precondition Failed 에러를 반환하여 데이터 무결성(Data Integrity)을 보장한다. Express.js 프레임워크에서의 구현 예시를 통해 실제 적용 방법을 설명한다.

댓글에서는 ETag를 If-Match와 함께 사용하는 방식이 HTTP 스펙(HTTP Spec)을 위반할 수 있다는 점을 지적한다. 특히, If-Match 요청에 약한 ETag를 사용하는 것은 스펙상 허용되지 않으며, 이는 캐싱, 프록시, 미들웨어 등에서 문제를 발생시킬 수 있다. HTTP 명세(HTTP Specification)에 따르면, If-Match는 강한 ETag 비교를 사용해야 한다. 따라서, 약한 ETag를 사용하는 것은 잠재적인 호환성 문제를 야기할 수 있다.

강한 ETag는 바이트 단위의 완전한 일치를 보장해야 하므로, 데이터베이스에서 동적으로 생성되는 응답에는 적용하기 어렵다는 의견이 제시된다. 강한 ETag(Strong ETag)는 전역적으로 유일한 값을 가져야 하며, 데이터베이스 레코드의 식별자와 버전을 연결하는 방식으로 생성될 수 있다. 하지만, 데이터베이스에서 데이터를 조립하는 과정에서 강한 ETag를 생성하는 것은 성능 저하를 유발할 수 있다. 따라서, 강한 ETag의 실용성은 제한적이다.

댓글 작성자는 HTTP 스펙 위반 문제를 해결하기 위해 쿼리 파라미터(Query Parameter)를 활용하는 방식을 제안한다. 즉, POST 요청 시 예상되는 버전을 쿼리 파라미터로 전달하고, 서버 측에서 버전 불일치 시 409 Conflict 에러를 반환하는 방식이다. 이 방법은 HTTP 스펙을 준수하며, 캐싱 및 프록시 환경에서도 안전하게 동작할 수 있다. 데이터 격리 아키텍처(Data Isolation Architecture)를 구현하는 데 있어, ETag 외에도 다양한 선택지가 존재함을 시사한다.