맨위로가기

MSI 프로토콜

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

MSI 프로토콜은 캐시 일관성을 유지하기 위한 프로토콜로, 캐시 라인의 상태를 무효(Invalid), 공유(Shared), 수정됨(Modified)의 세 가지 상태로 관리한다. 프로세서의 읽기/쓰기 요청과 버스 측면 요청에 따라 캐시 라인의 상태가 변경되며, 각 상태는 특정 상황에서 다른 상태로 전이된다. MSI 프로토콜은 SGI 4D 머신에서 사용된 프로토콜과 유사하며, MESI, MOSI, MOESI 프로토콜과 같은 변형을 통해 캐시 일관성 상호 연결에서 트래픽을 줄인다.

더 읽어볼만한 페이지

  • 캐시 일관성 - MESI 프로토콜
    MESI 프로토콜은 다중 프로세서 시스템에서 캐시 일관성을 위해 Modified, Exclusive, Shared, Invalid의 네 가지 상태를 사용하여 캐시 라인 상태를 관리한다.
MSI 프로토콜
일반 정보
종류캐시 일관성 프로토콜
개요
설명MSI (Modified, Shared, Invalid) 프로토콜은 캐시 일관성을 유지하기 위한 프로토콜이다.
상태수정됨 (Modified)
공유됨 (Shared)
무효화됨 (Invalid)
동작 방식
수정됨 상태 (Modified State)캐시 라인이 수정되었고, 다른 캐시에는 해당 라인의 유효한 복사본이 없음을 나타낸다.
공유됨 상태 (Shared State)캐시 라인이 여러 캐시에서 공유되고 있음을 나타낸다. 메모리의 데이터와 일치한다.
무효화됨 상태 (Invalid State)캐시 라인이 유효하지 않음을 나타낸다. 해당 데이터를 사용하기 전에 메모리에서 다시 가져와야 한다.
활용
사용 분야다중 코어 프로세서 시스템
목적각 코어의 캐시가 일관된 데이터 복사본을 유지하도록 보장
참고 사항
관련 기술캐시 일관성

2. MSI 프로토콜의 상태

캐시 내에 포함된 각 블록은 다음 세 가지 상태 중 하나를 가질 수 있다.


  • '''M'''odified(수정됨): 블록이 캐시에서 수정된 상태이다. 캐시에 있는 데이터는 메모리와 같은 백업 저장소의 내용과 일치하지 않는다. 'M' 상태의 블록을 가진 캐시는 해당 블록이 제거될 때 변경된 내용을 백업 저장소에 기록해야 한다.[1]
  • '''S'''hared(공유됨): 블록이 수정되지 않았으며, 하나 이상의 캐시에 읽기 전용 상태로 존재할 수 있는 상태이다. 캐시는 이 상태의 데이터를 백업 저장소에 기록하지 않고 제거할 수 있다.[1]
  • '''I'''nvalid(무효): 블록이 현재 캐시에 유효하게 존재하지 않거나, 다른 캐시의 요청으로 인해 무효화된 상태이다. 이 상태의 블록을 사용하려면 메모리나 다른 캐시에서 데이터를 새로 가져와야 한다.[1]

2. 1. Modified (수정됨)

Modified(수정됨): 블록이 캐시에서 수정되어, 캐시의 데이터가 백업 저장소(예: 메모리)와 일치하지 않는 상태이다. 'M' 상태의 블록을 가진 캐시는 해당 블록이 제거될 때 백업 저장소에 내용을 기록해야 한다.[1]

2. 2. Shared (공유됨)

이 블록은 수정되지 않았으며, 하나 이상의 캐시에 읽기 전용 상태로 존재한다. 이 상태의 캐시 라인은 메모리와 같은 백업 저장소에 다시 기록하지 않고 캐시에서 제거될 수 있다.[1]

캐시에 읽기 요청이 도착했을 때 해당 블록이 'S' 상태라면, 캐시는 가지고 있는 데이터를 바로 제공한다. 만약 다른 캐시가 특정 블록에 대한 읽기 요청을 보냈고, 해당 블록을 가진 캐시 중 'M'(수정됨) 상태인 캐시가 없다면, 요청한 캐시는 메모리나 다른 'S' 상태의 캐시로부터 데이터를 가져온다. 데이터를 받은 후 해당 캐시 블록은 'S' 상태가 된다.[1]

만약 'S' 상태의 블록에 쓰기 요청이 발생하면, 해당 캐시는 이 블록을 가지고 있을 수 있는 다른 모든 캐시에게 해당 블록을 무효화(Invalidate)하라고 알려야 한다. 이 알림은 스누핑이나 캐시 디렉토리를 통해 이루어질 수 있다. 다른 캐시들이 블록을 무효화한 후, 해당 캐시는 로컬 데이터를 수정하며, 이 블록의 상태는 'M'(수정됨)으로 변경된다.[1]

2. 3. Invalid (무효)

`'''I'''nvalid(무효):` 이 상태는 해당 데이터 블록이 현재 캐시에 유효하게 존재하지 않음을 의미한다. 블록이 캐시에 처음부터 없었거나, 다른 캐시로부터의 요청(예: 버스 요청)에 의해 기존 데이터가 무효화된 경우를 말한다.[1] 'I' 상태의 캐시 블록을 사용하려면 해당 데이터를 메모리 또는 다른 캐시에서 먼저 가져와야 한다.[1]

  • 읽기 요청: 캐시 블록이 'I' 상태일 때 읽기 요청이 들어오면, 시스템은 다른 캐시 중에 해당 블록을 'M'(Modified) 상태로 가지고 있는 캐시가 있는지 확인한다. 'M' 상태 캐시가 존재하면, 해당 캐시는 데이터를 메모리에 기록(write-back)하고 자신의 상태를 'S'(Shared) 또는 'I'로 변경해야 한다. 그 후, 요청한 캐시는 메모리나 'S' 상태의 다른 캐시로부터 데이터를 가져와 자신의 캐시에 저장하고 상태를 'S'로 설정한다.
  • 쓰기 요청: 캐시 블록이 'I' 상태일 때 쓰기 요청이 들어오면, 요청한 캐시는 먼저 다른 모든 캐시('S' 또는 'M' 상태)에 해당 블록을 무효화('I' 상태로 변경)하라는 신호를 보낸다. 만약 'M' 상태의 블록을 가진 다른 캐시가 있다면, 그 캐시는 데이터를 메모리에 기록하거나 요청한 캐시에 직접 전달해야 한다. 요청한 캐시는 필요에 따라 메모리에서 최신 데이터를 읽어온 후, 데이터를 수정하고 해당 블록의 상태를 'M'으로 변경한다.

3. MSI 프로토콜의 동작 방식

MSI 프로토콜에서 캐시 내 각 블록은 다음 세 가지 상태 중 하나를 가질 수 있다.[1]


  • '''M'''odified (수정됨): 블록이 캐시에서 수정되어 메모리의 내용과 일치하지 않는 상태이다. 'M' 상태 블록을 가진 캐시는 해당 블록을 캐시에서 내보낼 때 반드시 메모리에 변경된 내용을 기록해야 한다.
  • '''S'''hared (공유됨): 블록이 수정되지 않았으며, 여러 캐시에 읽기 전용 상태로 존재할 수 있다. 캐시는 메모리에 내용을 기록하지 않고도 이 블록을 제거할 수 있다.
  • '''I'''nvalid (무효): 블록이 현재 캐시에 없거나, 다른 캐시의 요청으로 인해 무효화된 상태이다. 이 상태의 블록을 사용하려면 메모리나 다른 캐시로부터 데이터를 다시 가져와야 한다.[1]


이러한 캐시 상태들은 캐시와 메모리 간의 통신을 통해 관리되며, 이를 통해 캐시 일관성이 유지된다. 특정 블록에 대한 읽기 또는 쓰기 요청이 발생하거나, 다른 캐시에서 발생한 요청을 감지(버스 스누핑 등)했을 때 각 캐시는 정해진 규칙에 따라 동작하여 데이터의 일관성을 보장한다. 구체적인 읽기 및 쓰기 요청 처리 방식은 캐싱 아키텍처(스누핑 또는 캐시 디렉토리 등)에 따라 달라질 수 있다.

3. 1. 읽기 요청

읽기 요청이 "M"(수정됨) 또는 "S"(공유됨) 상태의 블록에 대해 캐시에 도착하면, 해당 캐시는 데이터를 바로 제공한다.

만약 요청된 블록이 캐시에 없는 "I"(무효) 상태라면, 다른 캐시가 해당 블록을 "M" 상태로 가지고 있는지 확인해야 한다. 이 확인 과정은 캐싱 아키텍처에 따라 다르다. 예를 들어, 스누핑 방식은 읽기 요청을 모든 캐시에 알리고, 캐시 디렉토리 방식은 특정 블록의 최신 복사본 위치를 아는 에이전트를 사용한다.

다른 캐시 중 하나가 해당 블록을 "M" 상태로 가지고 있다면, 그 캐시는 먼저 데이터를 메모리에 기록해야 한다. 데이터를 기록한 후, 해당 캐시 블록의 상태는 "S" 또는 "I"로 변경된다. "M" 상태의 블록이 메모리에 기록된 후, 읽기 요청을 보낸 원래 캐시는 이제 메모리나 혹은 해당 블록을 "S" 상태로 가진 다른 캐시로부터 데이터를 가져올 수 있다.

다른 캐시 중에 "M" 상태의 블록이 없다면, 읽기 요청을 보낸 캐시는 메모리나 "S" 상태의 데이터를 가진 다른 캐시에서 직접 블록을 가져온다.

어떤 경우든 데이터를 성공적으로 가져온 후, 읽기 요청을 처리한 캐시 블록은 "S" 상태가 된다.

3. 2. 쓰기 요청

캐시에 쓰기 요청이 도착했을 때의 동작은 해당 블록의 상태에 따라 달라진다.

  • '''M'''(Modified) 상태: 쓰기 요청을 받은 블록이 이미 "M" 상태라면, 해당 캐시는 다른 캐시나 메모리에 알릴 필요 없이 로컬 데이터를 즉시 수정한다. 데이터는 이미 해당 캐시에서 최신 상태이며 독점적으로 소유하고 있기 때문이다.
  • '''S'''(Shared) 상태: 블록이 "S" 상태일 경우, 해당 데이터는 다른 캐시에도 존재할 수 있는 읽기 전용 복사본이다. 따라서 쓰기 작업을 수행하기 전에, 이 캐시는 해당 블록을 "S" 상태로 가지고 있을 수 있는 다른 모든 캐시에게 이 블록을 무효화(Invalidate)하라는 메시지를 보내야 한다. 이 과정은 버스 스누핑이나 디렉토리를 통해 이루어질 수 있다. 다른 캐시들이 블록을 무효화한 후, 캐시는 로컬 데이터를 수정할 수 있다. 수정 후 해당 블록의 상태는 "M"으로 변경된다.
  • '''I'''(Invalid) 상태: 블록이 "I" 상태라는 것은 해당 캐시에 유효한 데이터가 없다는 의미이다. 이 경우, 캐시는 먼저 쓰기 작업을 하려는 데이터 블록에 대한 소유권을 얻어야 한다. 이를 위해 다른 모든 캐시에게 해당 블록을 무효화하라는 메시지를 보낸다. 만약 다른 캐시 중 하나가 해당 블록을 "M" 상태로 가지고 있다면, 그 캐시는 데이터를 백업 저장소에 쓰거나, 요청한 캐시에게 직접 데이터를 전송해야 한다. 요청한 캐시에 해당 블록이 아직 없다면(쓰기 미스), 데이터를 수정하기 전에 백업 저장소나 다른 캐시로부터 최신 데이터를 읽어와야 한다(Read-For-Ownership). 데이터를 가져와 수정한 후, 해당 캐시 블록의 상태는 "M"이 된다.


결론적으로, 쓰기 작업이 완료된 후에는 해당 캐시 블록은 최신 데이터를 가지는 독점적인 '''M''' 상태가 된다.

4. 상태 전이 (State Machine)

MSI 프로토콜에서 캐시 블록의 상태는 프로세서의 요청이나 버스를 통한 다른 프로세서의 요청에 따라 동적으로 변화한다. 이러한 변화 과정을 상태 전이라고 부른다.

MSI 프로토콜에 대한 프로세서 요청의 상태 다이어그램


MSI 프로토콜에 대한 버스 트랜잭션의 상태 다이어그램


각 캐시 블록은 '''무효(Invalid)''', '''공유(Shared)''', 또는 '''수정됨(Modified)''' 상태 중 하나를 가지며, 프로세서의 읽기(PrRd)/쓰기(PrWr) 요청이나 다른 캐시로부터의 버스 요청(BusRd, BusRdX, BusUpgr)에 따라 다른 상태로 변하거나 현재 상태를 유지한다.[2] 구체적인 상태 전이 규칙은 각 상태별로 정의된다.

4. 1. 프로세서 요청



프로세서가 캐시에 요청하는 내용은 다음과 같다.

  • '''PrRd''': 캐시 블록을 읽기 위한 프로세서 요청이다.
  • '''PrWr''': 캐시 블록에 쓰기 위한 프로세서 요청이다.

4. 2. 버스 측면 요청



버스 측면에는 다음과 같은 요청들이 있다.

  • BusRd: 프로세서의 캐시에서 읽기 실패(miss)가 발생했을 때, 버스에 이 요청을 보내 캐시 블록을 받기를 기대한다.
  • BusRdX: 프로세서의 캐시에서 쓰기 실패(miss)가 발생했을 때, 버스에 이 요청을 보내 캐시 블록을 받는 동시에 다른 프로세서 캐시에 있는 해당 블록을 무효화시킨다.
  • BusUpgr: 프로세서의 캐시에서 쓰기 적중(hit)이 발생했을 때, 버스에 이 요청을 보내 다른 프로세서 캐시에 있는 해당 블록을 무효화시킨다.
  • Flush: 전체 캐시 블록이 메인 메모리에 다시 쓰여졌음을 알리는 요청이다.[2]

4. 3. 상태 전이 규칙



프로세서가 캐시에 보내는 요청은 다음과 같다.

  • '''PrRd''': 캐시 블록 읽기 요청.
  • '''PrWr''': 캐시 블록 쓰기 요청.


버스를 통해 전달되는 요청은 다음과 같다.

  • '''BusRd''': 프로세서가 읽기 요청(PrRd) 시 캐시에 해당 데이터가 없을 때(캐시 미스), 필요한 캐시 블록을 가져오기 위해 버스에 보내는 요청.
  • '''BusRdX''': 프로세서가 쓰기 요청(PrWr) 시 캐시에 해당 데이터가 없을 때, 필요한 캐시 블록을 가져오면서 다른 프로세서 캐시에 있는 동일 블록을 무효화하기 위해 버스에 보내는 요청.
  • '''BusUpgr''': 프로세서가 쓰기 요청(PrWr) 시 캐시에 해당 데이터가 있을 때(캐시 히트), 다른 프로세서 캐시에 있는 동일 블록을 무효화하기 위해 버스에 보내는 요청.
  • '''Flush''': 캐시 블록 전체를 메인 메모리에 다시 쓰는 요청.[2]


각 캐시 블록의 상태는 프로세서 요청이나 버스 요청에 따라 다음과 같이 변한다.

  • '''무효(Invalid)''' 상태:
  • PrRd 요청 시: BusRd 신호를 발생시키고 '''공유(Shared)''' 상태로 변경된다.
  • PrWr 요청 시: BusRdX 신호를 발생시키고 '''수정됨(Modified)''' 상태로 변경된다.
  • 다른 캐시로부터 BusRd, BusRdX, BusUpgr 요청 수신 시: '''무효(Invalid)''' 상태를 유지한다.
  • '''공유(Shared)''' 상태:
  • PrRd 요청 시: '''공유(Shared)''' 상태를 유지한다.
  • PrWr 요청 시: BusUpgr 신호를 발생시키고 '''수정됨(Modified)''' 상태로 변경된다.
  • 다른 캐시로부터 BusRd 요청 수신 시: '''공유(Shared)''' 상태를 유지한다.
  • 다른 캐시로부터 BusRdX 또는 BusUpgr 요청 수신 시: '''무효(Invalid)''' 상태로 변경된다.
  • '''수정됨(Modified)''' 상태:
  • PrRd 또는 PrWr 요청 시: '''수정됨(Modified)''' 상태를 유지한다.
  • 다른 캐시로부터 BusRd 요청 수신 시: 캐시 블록을 버스로 플러시(Flush)하고 '''공유(Shared)''' 상태로 변경된다.
  • 다른 캐시로부터 BusRdX 요청 수신 시: 캐시 블록을 버스로 플러시(Flush)하고 '''무효(Invalid)''' 상태로 변경된다.[2]
  • BusUpgr 요청은 이 상태에서 발생할 수 없다. 특정 캐시 블록이 한 프로세서에서 '''수정됨(Modified)''' 상태라면, 다른 모든 프로세서에서는 반드시 '''무효(Invalid)''' 상태여야 하기 때문이다.

4. 3. 1. Invalid (무효)

프로세서가 특정 캐시 블록에 대해 요청을 보낼 때, 해당 블록이 '''무효(Invalid)''' 상태에 있다면 다음과 같이 상태가 변화한다.

  • 프로세서가 읽기 요청(PrRd)을 보내는 경우:
  • 버스에 BusRd 신호를 발행한다.
  • 해당 캐시 블록의 상태는 '''공유(Shared)'''로 변경된다.
  • 프로세서가 쓰기 요청(PrWr)을 보내는 경우:
  • 버스에 BusRdX 신호를 발행한다.
  • 해당 캐시 블록의 상태는 '''수정됨(Modified)'''으로 변경된다.
  • 다른 프로세서로부터 버스를 통해 BusRd, BusRdX, 또는 BusUpgr 신호가 수신되는 경우:
  • 해당 캐시 블록은 계속 '''무효(Invalid)''' 상태를 유지한다.[2]

4. 3. 2. Shared (공유)

캐시 블록이 '''공유(Shared)''' 상태일 때, 다음과 같은 상태 전환이 일어난다.

  • 프로세서가 해당 블록을 읽으려고 하면(PrRd), 블록은 계속 '''공유(Shared)''' 상태를 유지한다.
  • 프로세서가 해당 블록에 쓰려고 하면(PrWr), 버스에 BusUpgr 요청을 보내 다른 캐시들의 복사본을 무효화하고, 해당 블록의 상태는 '''수정됨(Modified)'''으로 변경된다.
  • 다른 프로세서가 해당 블록을 읽기 위해 버스에 BusRd 요청을 보내면, 블록은 계속 '''공유(Shared)''' 상태를 유지한다.
  • 다른 프로세서가 해당 블록을 쓰기 위해 BusRdX 요청을 보내거나, 쓰기 위해 BusUpgr 요청을 보내면, 해당 블록은 '''무효(Invalid)''' 상태로 변경된다.[2]

4. 3. 3. Modified (수정됨)


  • PrRd 또는 PrWr: 프로세서가 캐시 블록을 읽거나 쓸 때, 해당 블록은 '''수정됨(Modified)''' 상태를 유지한다. 이는 이미 해당 프로세서가 최신 데이터를 가지고 있으며, 다른 캐시에는 유효한 복사본이 없음을 의미한다.
  • BusRd: 다른 프로세서가 해당 캐시 블록을 읽으려고 BusRd 요청을 보내면, 현재 '''수정됨(Modified)''' 상태의 블록은 버스로 플러시(flush)되어 메인 메모리를 업데이트하고 요청한 프로세서에게 데이터를 제공한다. 이후 해당 블록의 상태는 '''공유(Shared)'''로 변경된다. 이제 여러 캐시가 해당 블록의 복사본을 가질 수 있게 된다.
  • BusRdX: 다른 프로세서가 해당 캐시 블록에 쓰기 작업을 하려고 BusRdX 요청을 보내면, 현재 '''수정됨(Modified)''' 상태의 블록은 버스로 플러시된다. 이후 해당 블록의 상태는 '''무효(Invalid)'''로 변경된다. 이는 다른 프로세서가 해당 블록을 수정했으므로, 현재 캐시의 데이터는 더 이상 유효하지 않음을 의미한다.[2]
  • BusUpgr: 이 상태에서는 BusUpgr 요청이 발생할 수 없다. 어떤 캐시 블록이 특정 프로세서에서 '''수정됨(Modified)''' 상태라면, 정의상 다른 모든 프로세서의 해당 블록은 '''무효(Invalid)''' 상태여야 한다. BusUpgr 요청은 '''공유(Shared)''' 상태의 블록을 가진 프로세서가 쓰기 작업을 할 때 발생하는 것이므로, '''수정됨(Modified)''' 상태에서는 이 요청이 들어올 수 없다.

5. 유사 프로토콜 및 변형

MSI 프로토콜은 SGI 4D 머신에서 사용된 프로토콜과 유사하다.[3] 현대의 컴퓨터 시스템에서는 캐시 일관성 유지를 위한 통신 과정에서 발생하는 트래픽 양을 줄이기 위해 MSI 프로토콜을 변형하여 사용한다. 대표적인 변형 프로토콜로는 "Exclusive"(단독) 상태를 추가한 MESI 프로토콜, "Owned"(소유) 상태를 추가한 MOSI 프로토콜, 그리고 이 두 상태를 모두 추가한 MOESI 프로토콜 등이 있다. 이러한 변형 프로토콜들은 각각의 방식으로 캐시 간 데이터 전송량을 최적화하여 시스템 성능을 향상시키는 데 기여한다.

5. 1. MESI 프로토콜

MSI 프로토콜을 확장한 여러 프로토콜 중 하나이다. 현대 시스템에서는 캐시 일관성 유지 과정에서 발생하는 트래픽을 줄이기 위해 MSI 프로토콜의 변형을 사용하는데, MESI 프로토콜은 "Exclusive"(단독) 상태를 추가하여 이러한 목적을 달성한다. 이 상태는 특정 데이터 블록이 여러 캐시 중 단 하나의 캐시에만 존재할 경우를 나타내며, 해당 블록에 쓰기 작업을 수행할 때 발생하는 불필요한 버스 트래픽을 효과적으로 줄여준다.

5. 2. MOSI 프로토콜

MOSI 프로토콜은 MSI 프로토콜을 확장한 캐시 일관성 프로토콜 중 하나이다. 현대 시스템은 캐시 일관성 유지를 위한 상호 연결 과정에서 발생하는 트래픽 양을 줄이기 위해 MSI 프로토콜의 여러 변형을 사용한다. MOSI 프로토콜은 "Owned"(소유)라는 상태를 추가하여, 다른 캐시에서 이미 읽어간 데이터 블록에 대해 특정 캐시가 쓰기 작업을 수행한 후, 변경된 데이터를 다시 메인 메모리로 기록(쓰기 반환, write-back)할 때 발생하는 트래픽을 줄이는 데 목적을 둔다.

5. 3. MOESI 프로토콜

MOESI 프로토콜은 MSI 프로토콜을 확장한 캐시 일관성 프로토콜 중 하나이다. 현대 시스템은 캐시 일관성 유지를 위한 상호 연결 과정에서 발생하는 트래픽 양을 줄이기 위해 MSI 프로토콜의 다양한 변형을 사용하는데, MOESI 프로토콜도 이러한 목적으로 설계되었다.

MOESI 프로토콜은 MSI 프로토콜에 "Exclusive"(배타적) 상태와 "Owned"(소유) 상태를 모두 추가한 것이 특징이다. "Exclusive" 상태는 MESI 프로토콜에서 도입된 것으로, 특정 데이터 블록이 단 하나의 캐시에만 존재할 때 쓰기 작업으로 인해 발생하는 트래픽을 줄이는 데 목적이 있다. "Owned" 상태는 MOSI 프로토콜에서 추가되었으며, 다른 캐시에서 이미 읽어간 데이터 블록에 대한 쓰기 후 결과 반환 과정에서 발생하는 트래픽을 감소시키는 역할을 한다.

결론적으로 MOESI 프로토콜은 "Exclusive" 상태와 "Owned" 상태의 이점을 모두 통합하여, 캐시 간 통신 트래픽을 효과적으로 줄인다.

참조

[1] 서적 29th Digital Avionics Systems Conference 2010-10-01
[2] 서적 Fundamentals of Parallel Multicore Architecture Chapman & Hall/CRC Computational Science Series
[3] 웹사이트 INTEGRATION AND EVALUATION OF CACHE COHERENCE PROTOCOLS FOR MULTIPROCESSOR SOCS https://smartech.gat[...] 2006-12
[4] 저널 How to address certification for multi-core based IMA platforms: Current status and potential solutions 2010-10-01


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com