HomeAboutMeBlogGuest
© 2025 Sejin Cha. All rights reserved.
Built with Next.js, deployed on Vercel
👻
개발 기록/
📪
대규모 시스템 설계 기초 퀴즈
📪

대규모 시스템 설계 기초 퀴즈

www.naver.com에 접속하면 사용자 요청 처리 과정이 어떻게 되는가?
정답
  1. 접속을 위해 도메인 이름을 DNS에 질의하여 IP 주소로 변환
  1. 해당 IP 주소로 HTTP 요청이 전달
  1. 요청 받은 웹 서버는 HTML 페이지나 JSON 형태의 응답을 반환
 
개인 프로젝트에 noSQL을 도입했다고 가정해보자. 면접관이 noSQL 채택 이유를 묻는 데 뭐라고 할까?
정답
  1. 아주 낮은 응답 지연시간이 요구됨
  1. 다루는 데이터가 비정형이라 관계형 데이터가 아님
  1. 데이터를 직렬화하거나 역직렬화 할 수 있기만 하면 됨
  1. 아주 많은 양의 데이터를 저장할 필요가 있음
 
선착순 티켓팅 서비스를 만든다 했을 때 가장 효과적인 처리율 제한 알고리즘은 뭘까?
정답
가장 효과적인 방법은 토큰 버킷(Token Bucket) + 요청 큐(Request Queue) 조합입니다.
이유:
1. 토큰 버킷(Token Bucket)
• 트래픽이 갑자기 몰려도 서버가 감당할 수 있는 속도로 요청을 처리.
• 순간적인 폭주를 조절하여 서버 다운을 방지.
• 선착순 개념을 유지하면서도 공정하게 처리 가능.
2. 요청 큐(Request Queue)
• 토큰이 있는 사용자만 요청을 할 수 있게 하고, 요청을 선착순으로 큐에 저장.
• 처리 가능한 요청만 남기고 나머지는 거절하여 서버 부하를 최소화.
작동 방식:
1. 티켓팅 요청이 들어오면 토큰 버킷에서 토큰을 소모하며, 토큰이 없으면 요청 거부.
2. 토큰이 있는 요청만 요청 큐에 추가되어 순차적으로 처리.
3. 큐가 가득 차면 이후 요청을 거절하여 서버 안정성을 유지.
이 방식은 서버 부담을 줄이면서도 공정한 선착순 티켓팅을 보장할 수 있습니다. 🚀
 
 
모듈러 연산을 이용한 해시 키는 어떤 한계점이 있나요?
정답
서버가 추가 또는 제거되면 문제가 생김. 장애가 발생한 서버에 보관되어 있는 키 뿐만 아니라 대부분의 키가 재분배 됨. 그 결과 대규모 캐시 미스가 발생함.
 
그럼 이 한계점을 극복하는 방법으로 뭐가 있나요?
정답
안정 해시 방법. 해시 테이블 크기가 조정될 때 평균적으로 오직 n/k 개만 재배치하는 해시 기술. 이 중에서도 단순하게 안정 해시 알고리즘 구현법(해시 링을 만들고 키를 배치해서 시계방향으로 가장 가까운 서버에 저장하는 것)을 쓰면 안되고 가상 노드를 도입해야 균등 분포가 가능하다.
 
클라이언트 측에서 데이터의 버전 정보를 활용해 일관성이 깨진 데이터를 읽지 않도록 하는 기법은 뭐가 있을까?
참고 답변
클라이언트에서 데이터 버전 정보를 활용해 일관성이 깨진 데이터를 읽지 않도록 구현하는 방법은 크게 Optimistic Locking, ETag 기반 캐싱 및 검증, Consistency Token 활용 등의 기법을 사용할 수 있습니다.
1. Optimistic Locking 구현 방법
Optimistic Locking은 클라이언트가 데이터를 읽고 수정할 때 버전 정보를 포함하여 업데이트를 수행하는 방식입니다. 일반적으로 API 요청에서 버전 필드를 추가하고 이를 체크하여 데이터 충돌을 방지합니다.
1-1. 서버 응답 예제 (JSON)
클라이언트가 데이터를 조회할 때 서버에서 버전 정보를 함께 내려줍니다.
1-2. 클라이언트 코드 구현 (JavaScript, React, Axios 예제)
1. 데이터를 서버에서 가져올 때 version 정보를 함께 저장.
2. 수정 요청 시 해당 version을 함께 전송.
3. 서버에서 version이 일치하면 업데이트 수행, 다르면 오류 응답.
🚀 서버는 If-Match 헤더의 값과 현재 데이터의 version을 비교하여 다르면 409 Conflict 응답을 반환해야 합니다.
2. ETag 기반 캐싱 및 데이터 검증
HTTP의 ETag(Entity Tag)를 활용하면 데이터 변경 여부를 클라이언트가 효율적으로 감지할 수 있습니다.
2-1. 서버 응답 예제 (ETag 포함)
2-2. 클라이언트 코드 구현
1. 데이터를 요청할 때 ETag 값을 저장.
2. 다시 요청할 때 If-None-Match 헤더에 ETag 값을 포함.
3. 서버에서 데이터가 변경되지 않았다면 304 Not Modified 응답.
🚀 서버는 데이터가 변경되지 않았으면 304 Not Modified를 응답해야 합니다.
3. Consistency Token 활용
Consistency Token은 서버가 클라이언트에게 변경 불가능한 토큰을 제공하고, 클라이언트가 이를 다음 요청에서 사용하여 데이터 일관성을 검증하는 방식입니다.
3-1. 서버 응답 예제 (토큰 포함)
3-2. 클라이언트 코드 구현
1. 데이터를 읽을 때 consistency_token을 저장.
2. 수정 요청 시 해당 토큰을 함께 전송.
3. 서버는 토큰이 유효한 경우에만 업데이트 수행.
🚀 서버는 consistency_token을 검증하고, 유효하지 않으면 409 Conflict 응답을 반환해야 합니다.
어떤 방식이 가장 적합할까?
기법
특징
사용 예시
Optimistic Locking
데이터베이스의 버전 필드를 이용해 충돌 방지
REST API에서 If-Match 헤더와 함께 활용
ETag 기반 검증
HTTP 캐싱과 변경 감지를 활용
정적 데이터 캐싱, 빈번한 읽기 요청이 있는 경우
Consistency Token
변경 불가능한 토큰을 이용한 검증
분산 시스템에서 데이터 무결성 유지
🚀 클라이언트에서 구현할 때 고려해야 할 점
• 실시간 데이터 변경이 많으면 ETag나 Consistency Token 활용.
• 트랜잭션이 중요하다면 Optimistic Locking 적용.
• 분산 환경(여러 서버에서 변경 가능)이면 Vector Clock 등의 고급 기법 고려.
어떤 기법을 사용할지 결정하는 것은 서버와의 협업이 중요하므로, 백엔드 개발자와 함께 논의하여 적절한 방법을 선택하는 것이 좋습니다. 🚀
 
 
분산 시스템에서 유일성이 보장되는 ID를 만드는 방법으로 UUID와 스노플레이크가 있다. 이 둘의 차이는?
참고 답변
Snowflake ID와 UUID는 모두 고유 식별자를 생성하지만, 설계 원칙과 생성 방식에서 중요한 차이가 있습니다:

스노플레이크 ID(Snowflake ID)

  1. 구조적 설계: 타임스탬프(41비트) + 워커 ID(10비트) + 시퀀스 번호(12비트)와 같은 구조적 설계
  1. 시간 기반: 밀리초 단위의 타임스탬프가 포함되어 있어 시간순 정렬 가능
  1. 분산 시스템 친화적: 여러 서버에서 ID 충돌 없이 생성 가능
  1. 비트 효율성: 64비트로 구현 가능해 저장 공간이 적게 필요
  1. 예측 가능성: 시간 기반이라 생성 시점을 추론 가능
  1. 주요 용도: 분산 시스템에서 시간순 정렬이 필요한 데이터에 적합

UUID

  1. 비구조적/랜덤: 대부분의 비트가 랜덤(특히 버전 4)
  1. 시간 독립적: 버전 1을 제외하면 시간 정보가 없음
  1. 분산 생성: 중앙 조정 없이 독립적으로 생성 가능
  1. 크기: 128비트로 더 큰 저장 공간 필요
  1. 예측 불가능성: 버전 4는 충돌 확률이 매우 낮고 예측 불가능
  1. 주요 용도: 보안이 중요하거나 시간순 정렬이 불필요한 경우

핵심 차이

  • 스노플레이크는 시간 기반 순차적 할당을 중시하여 디자인됨
  • UUID는 충돌 확률의 최소화를 중시하여 디자인됨
  • 스노플레이크는 64비트로 더 효율적이지만, UUID는 128비트로 더 넓은 식별 공간 제공
용도에 따라 선택이 달라집니다. 순차적 정렬이 중요하면 스노플레이크, 예측 불가능성이 중요하면 UUID가 더 적합합니다.
 
스노플레이크 ID 시스템에서 시계 동기화 문제는 중요한 단점이다. 이 문제가 발생하는 이유와 극복 방법은?
참고 답변

시계 동기화 문제가 발생하는 이유

  1. 시간 의존성: 스노플레이크는 41비트를 타임스탬프에 할당하므로 시간에 크게 의존합니다.
  1. 분산 시스템: 여러 서버에서 ID를 생성할 때 각 서버의 시계가 다를 수 있습니다.
  1. 시계 드리프트(Clock Drift): 하드웨어적인 이유로 서버 간 시계가 점차 어긋날 수 있습니다.
  1. 시간 역행 문제: 서버의 시계가 과거로 돌아가면(예: NTP 동기화 후) 중복된 ID가 생성될 수 있습니다.

시계 동기화 문제 극복 방법

1. NTP(Network Time Protocol) 사용

  • 모든 서버를 동일한 NTP 서버와 동기화하여 시간 차이 최소화
  • 가장 기본적인 접근법이지만 완벽한 해결책은 아님

2. 시간 역행 감지 메커니즘

  • 마지막으로 생성된 타임스탬프를 저장하고 비교
  • 현재 시간이 마지막 타임스탬프보다 이전이면 대기하거나 마지막 타임스탬프 사용

3. 중앙 시간 서비스 도입

  • ZooKeeper나 다른 분산 코디네이션 서비스를 통해 시간 관리
  • 각 노드가 개별적으로 시간을 결정하지 않고 중앙에서 조정

4. 타임스탬프 블록 할당

  • 중앙 서버가 각 노드에 타임스탬프 범위를 미리 할당
  • 각 노드는 할당된 범위 내에서만 ID 생성

5. 하드웨어 기반 시간 동기화

  • GPS나 원자 시계 같은 정밀한 외부 시간 소스 활용
  • 대규모 금융 시스템이나 고정밀 환경에서 사용
이러한 방법들을 조합하여 사용하면 스노플레이크 ID 시스템의 시계 동기화 문제를 효과적으로 관리할 수 있습니다. 특히 대규모 분산 시스템에서는 여러 방법을 함께 사용하는 것이 권장됩니다.
 
해시 함수 구현에 쓰이는 기술인 base-62 변환에 대한 장점과 단점은?
참고답변

Base-62 변환의 장점

  1. 공간 효율성: 10진수보다 더 많은 문자(a-z, A-Z, 0-9)를 사용하므로 같은 숫자를 더 적은 문자로 표현할 수 있습니다.
  1. URL 친화적: URL에서 사용 가능한 특수문자를 포함하지 않아 인코딩 없이 URL에 직접 사용할 수 있습니다.
  1. 구현 용이성: 구현이 비교적 간단하고 직관적입니다.
  1. 가독성: 숫자와 알파벳만 사용하므로 읽고 전달하기 쉽습니다.
  1. 고유성 보장: 다른 숫자는 항상 다른 Base-62 문자열로 변환됩니다.

Base-62 변환의 단점

  1. 예측 가능성: 순차적 ID를 Base-62로 변환하면 다음에 생성될 ID를 예측할 수 있어 보안 문제가 될 수 있습니다.
      • 비트리(Bitly) 정보 유출 사례: 초기 비트리는 순차적 ID를 사용했으며, 이로 인해 사용자들이 URL을 순차적으로 증가시켜 다른 사용자의 단축 URL을 발견할 수 있었습니다. 이를 통해 비공개로 공유된 민감한 문서나 정보에 접근하는 사례가 있었습니다.
      • 유튜브 단축 URL 스캐닝: 유튜브의 초기 단축 URL 시스템에서도 비슷한 문제가 발생했습니다. 사용자들이 단축 URL을 무작위로 생성해 비공개 동영상을 발견하는 일이 있었습니다.
      • 기업 내부 문서 노출: 몇몇 기업들이 사용한 내부 URL 단축 서비스에서 순차적 ID를 사용했고, 이로 인해 민감한 내부 문서가 외부에 노출된 사례가 있었습니다.
  1. 충돌 해결 부재: Base-62 자체는 충돌 해결 메커니즘을 제공하지 않습니다. 해시 함수와 함께 사용할 경우 별도의 충돌 해결 방법이 필요합니다.
  1. 분산 환경 제한: 여러 서버에서 순차적 ID를 생성할 경우 동기화 문제가 발생할 수 있습니다.
  1. 성능 오버헤드: 대규모 숫자를 변환할 때 나눗셈 연산이 많이 필요하여 약간의 성능 오버헤드가 있습니다.
  1. 역변환 용이성: Base-62 문자열에서 원래 ID로 쉽게 역변환할 수 있어, 시스템의 내부 ID 구조가 노출될 수 있습니다.
Base-62 변환은 단독으로 사용되기보다는 다른 기술(무작위성 추가, 해시 함수 등)과 함께 사용될 때 단점을 보완할 수 있습니다.
 
 
블룸필터란?
참고 답변
블룸 필터에 의해 어떤 원소가 집합에 속한다고 판단된 경우 실제로는 원소가 집합에 속하지 않는 긍정 오류가 발생하는 것이 가능하지만, 반대로 원소가 집합에 속하지 않는 것으로 판단되었는데 실제로는 원소가 집합에 속하는 부정 오류는 절대로 발생하지 않는다는 특성이 있다. 집합에 원소를 추가하는 것은 가능하나, 집합에서 원소를 삭제하는 것은 불가능하다. 집합 내 원소의 숫자가 증가할수록 긍정 오류 발생 확률도 증가한다.
 
예의바른 크롤러가 되려면?
답변 예
  • 동일한 웹사이트에 대해선 한번에 한 페이지만 요청하기
  • 같은 웹사이트면 시간차 두고 실행하기
 
크롤러 성능 최적화 방법
답변 예
  • 분산 크롤링
  • 도메인 이름 변환 결과 캐시
  • 지역성
  • 짧은 타임아웃
  • 안정성
  • 확장성
  • 문제있는 콘텐츠 감지 및 회피
    • 중복 콘텐츠
    • 거미 덫
    • 데이터 노이즈 (근데 거미 덫이랑 데이터 노이즈는 수동으로 등록이 필요할듯..?)
 
알림 시스템에서 중복 전송을 100% 방지하는 것이 불가능한 이유와 중복 발송을 줄이는 방법
답변 예
중복 전송을 100% 방지할 수 없는 핵심 원인:
1. 분산 시스템의 특성 – 여러 서버 및 노드에서 같은 이벤트를 동시에 처리할 가능성이 있음.
2. At-Least-Once 메시지 전달 – 메시지 큐(RabbitMQ, Kafka 등)가 메시지 유실을 방지하기 위해 중복 전송할 수 있음.
3. 네트워크 장애와 재시도 – 전송 실패 시 클라이언트 또는 서버가 재시도하며 중복 알림이 발생할 수 있음.
4. 이벤트 중복 감지 한계 – 트랜잭션 처리 중 장애 발생 시 중복 검출이 어려울 수 있음. 중복 발송 줄이는 방법 중 하나로 중복 감지 및 필터링이 있음.
• 메시지의 고유한 ID(UUID, 해시값 등)를 생성하여, 이미 처리된 메시지인지 확인하는 방식.
• Redis, 데이터베이스 등을 활용하여 최근 전송된 알림을 기록하고, 동일한 ID의 알림이 일정 시간 내 재발송되지 않도록 방지.
 
그래프 데이터베이스가 친구 관계나 친구 추천을 관리하기 적합한 이유
답변 예
그래프 데이터베이스란 그래프 생성 및 조작이라는 단일 용도로 특별히 설계된 플랫폼을 말합니다. 그래프는 노드, 간선, 속성으로 구성되어 있으며, 이 모든 요소를 활용하여 관계형 데이터베이스에서는 불가능한 방식으로 데이터를 표현하고 저장할 수 있습니다.

그래프 데이터베이스 유형

그래프 데이터베이스에는 속성 그래프와 RDF 그래프의 두 가지 주요 모델이 있습니다. 속성 그래프는 분석 및 쿼리에, RDF 그래프는 데이터 통합에 중점을 둡니다. 두 가지 유형 모두 포인트(정점)와 해당 포인트 사이의 연결선(간선)의 모음으로 구성됩니다. 그러나 차이점도 있습니다.

속성 그래프

속성 그래프는 데이터 간의 관계를 모델링하는 데 사용되며 이러한 관계를 기반으로 쿼리 및 데이터 분석 작업을 지원합니다. 속성 그래프에는 주제에 대한 자세한 정보 등을 포함하는 정점과 이러한 정점 간의 관계를 나타내는 간선이 있습니다. 정점과 간선은 속성(properties)이라고 하는 요소(attributes)를 가질 수 있으며, 이를 사용하여 연결될 수 있습니다.
이 예에서는 동료 및 이들의 관계 집합이 속성 그래프로 표시됩니다.
notion image
속성 그래프는 그 다재다능한 특성으로 인해 금융, 제조, 공공 안전, 리테일 업계를 비롯한 다양한 산업 및 부문에 광범위하게 사용됩니다.
 
채팅 시스템 설계에서 cur_max_message_id 변수 활용 목적
예시 답변
cur_max_message_id 변수를 활용하는 방법은 여러 가지가 있습니다. 여기 몇 가지 예시를 들어볼게요:
  1. 메시지 동기화: 유저가 여러 단말을 사용하고 있을 때, 각 단말에서 최신 메시지를 추적하여, 새로운 메시지를 수신할 때 해당 단말에서만 새로운 메시지를 로드하거나 표시할 수 있습니다. 이를 통해 사용자 경험을 개선할 수 있습니다.
  1. 중복 수신 방지: 동일한 메시지를 여러 단말에서 중복으로 수신하는 것을 방지하기 위해, cur_max_message_id를 사용하여 이미 수신한 메시지보다 더 높은 ID의 메시지만 처리하도록 할 수 있습니다.
  1. 오프라인 메시지 처리: 유저가 한 단말에서 오프라인 상태일 때, 최신 메시지 ID를 기록해 두었다가 온라인 상태로 돌아왔을 때 그 ID 이후의 메시지를 요청하여 일관된 메시지 흐름을 유지할 수 있습니다.
  1. 메시지 배치 요청: 사용자가 특정 단말에서 메시지를 요청할 때, cur_max_message_id를 기준으로 그 ID 이후의 메시지들만 서버로부터 요청할 수 있어, 네트워크 트래픽을 줄이고 응답 속도를 개선할 수 있습니다.
  1. 상태 관리 및 로깅: 각 단말의 상태를 관리하고, 특정 이벤트가 발생했을 때 (예: 메시지 전송 실패) 해당 상태를 기록하여 문제를 추적하고 분석하는 데 사용할 수 있습니다.
이처럼 cur_max_message_id는 여러 단말에서의 메시지 관리를 효율적으로 수행하는 데 중요한 역할을 할 수 있습니다.
 
but… 여러 단말에서 메시지를 읽는 방식에 대한 처리 방법은 다음과 같은 방식으로 접근할 수 있습니다:
  1. 읽음 상태 동기화: 사용자가 한 단말에서 메시지를 읽으면, 그 정보를 서버에 전송하여 다른 단말에서도 해당 메시지가 읽음 상태로 업데이트되도록 할 수 있습니다. 이렇게 하면 모든 단말에서 일관된 읽음 상태를 유지할 수 있습니다.
  1. 설정 옵션 제공: 사용자에게 한 단말에서 메시지를 읽었을 때 다른 단말에도 읽음 상태를 동기화할지를 선택할 수 있는 옵션을 제공하는 방법입니다. 예를 들어, "모든 단말에서 읽음 상태 동기화" 기능을 켜거나 끌 수 있게 하면, 사용자가 원하는 방식으로 설정할 수 있습니다.
  1. 상태 표시: 각 단말에서 메시지의 읽음 상태를 개별적으로 표시하되, 사용자가 각각의 단말에서 메시지를 읽은 경우 그 정보를 서로 공유하는 방식으로, 예를 들어 "핸드폰에서 읽음"이라는 표시를 추가할 수 있습니다.
  1. 사용자 피드백: 사용자로부터 피드백을 받아 어떤 방식이 더 선호되는지 조사하고, 그에 따라 시스템을 조정하는 것도 좋은 방법입니다.
결국, 메시지의 읽음 상태를 어떻게 처리할지는 사용자 경험을 고려하여 적절한 방법을 선택하는 것이 중요합니다. 이를 통해 사용자가 더 자연스럽고 직관적인 경험을 할 수 있도록 할 수 있습니다.
 
 
검색어 자동완성 시스템 개발 시 빠른 데이터 제공을 위해 결과를 최적화 하는 방안 2가지
  1. AJAX 요청 : AJAX(Asynchronous JavaScript and XML)가 페이지를 새로고침하지 않고도 요청을 보내고 응답을 받을 수 있는 있음. 비동기 통신 방식을 사용하기 때문.
  1. 브라우저 캐싱 : cache-control 헤더 값에 등장하는 private는 해당 응답이 요청을 보낸 사용자의 캐시에만 보관될 수 있으며 공용 캐시에 저장하지 않는 다는 뜻이다. 추가로 max-age는 3600으로 한 시간동안 유효하다.
 
  • 유튜브 설계에서 왓챠랑 비교해볼 수 있는 것?
    • 각 비디오 프로토콜에 맞게 비디오 인코딩과 플레이어 다르게 하는 방식
    • 인프라 미디어팀에서 해주고 있는게 비디오 트랜스코딩 과정인가?
    • cdn 쓰고 있는지?, 인기작은 cdn 쓰고 그 외엔 비디오 서버 사용하는 방식인가?
  • gpt 한테 비교해달라하면 이렇게 해줌
ㅤ
YouTube
왓챠
비디오 인코딩
자체 인프라, 다양한 코덱/화질
클라우드 기반 (AWS/GCP) 또는 자체 일부 구성
플레이어
Shaka 기반, 최적화 + 기능 풍부
HLS/DASH 지원 플레이어 커스터마이징
CDN
자체 CDN (Google Global Cache 등)
상용 CDN 사용 (Akamai, CloudFront 등)
라이브 스트리밍
자체 제공, 초대형 인프라, 저지연
기본 없음 또는 외부 솔루션 의존
DRM
일부 콘텐츠에 Widevine 사용
대부분 콘텐츠에 플랫폼별 DRM 적용
다운로드 기능
Premium 사용자 대상, 강력한 보호
일부 콘텐츠, DRM 기반 다운로드
추천 알고리즘
유튜브 ML 기반 전 세계 최상위 수준
왓챠만의 큐레이션/콘텐츠 기반 추천 강점
 
구글 드라이브 설계에 적합한 DB 유형
관계형 데이터 베이스, 강한 일관성을 보장하기 쉽기 때문에.
{
  "id": 123,
  "name": "Product A",
  "price": 1000,
  "version": 5
}
import axios from "axios";

async function fetchData() {
    const response = await axios.get("https://api.example.com/product/123");
    return response.data;  // 데이터와 함께 버전 정보도 포함됨
}

async function updateData(updatedData) {
    try {
        const response = await axios.put(`https://api.example.com/product/${updatedData.id}`, updatedData, {
            headers: { "If-Match": updatedData.version } // 버전 정보 전달
        });
        console.log("Update successful", response.data);
    } catch (error) {
        if (error.response.status === 409) {
            console.error("Conflict error: Data has been modified by another user.");
        } else {
            console.error("Update failed", error);
        }
    }
}

// 사용 예시
(async () => {
    const product = await fetchData();
    product.price = 1200; // 가격 변경
    await updateData(product);
})();
HTTP/1.1 200 OK
ETag: "v5"
Content-Type: application/json

{
  "id": 123,
  "name": "Product A",
  "price": 1000
}
let etag = null;

async function fetchDataWithETag() {
    try {
        const headers = etag ? { "If-None-Match": etag } : {};
        const response = await axios.get("https://api.example.com/product/123", { headers });

        if (response.status === 200) {
            etag = response.headers["etag"]; // 새로운 ETag 저장
            console.log("Updated Data:", response.data);
        } else if (response.status === 304) {
            console.log("Data has not changed, use cached version.");
        }
    } catch (error) {
        console.error("Fetch failed", error);
    }
}

// 데이터 가져오기 실행
fetchDataWithETag();
{
  "id": 123,
  "name": "Product A",
  "price": 1000,
  "consistency_token": "abc123xyz"
}
async function updateWithToken(product) {
    try {
        const response = await axios.put(`https://api.example.com/product/${product.id}`, {
            ...product,
            consistency_token: product.consistency_token // 일관성 토큰 추가
        });

        console.log("Update successful", response.data);
    } catch (error) {
        if (error.response.status === 409) {
            console.error("Conflict error: The data has changed since last retrieval.");
        } else {
            console.error("Update failed", error);
        }
    }
}

// 사용 예시
(async () => {
    let product = await fetchData();
    product.price = 1300; // 가격 변경
    await updateWithToken(product);
})();