바이트에 8 비트 또는 9가 포함되어 있습니까?


56

I는 판독 이 어셈블리 프로그래밍 가이드 1 비트는 다음 (하드웨어 고장 또는 전원 장애로 인한) 패리티 에러를 검출하기 위해 사용되는 패리티 위해 동안 8 비트 데이터를 사용하는 것이다.

이것이 사실입니까?


5
바이트 수 에 대한 설명은 cs.stackexchange.com/a/19851/584 를 참조하십시오 .
AProgrammer

63
그 기사는 넌센스로 가득 차 있으므로 무시해야합니다.
David Schwartz

12
당신이 pedantic되고 싶다면 그냥 "옥텟"이라고 부릅니다. 이 기사는 매우 구체적인 프로세서를 염두에두고 (어떤 이유로 인해 ROM에 패리티 비트를 유지 해야하는 것입니다 ...) 예를 들어, 마이크로 칩 PIC는 14 비트 워드 길이를 사용합니다. 전체 프로그램 메모리는 N x 14 비트 배열로 구성됩니다.
Nick T

13
@ NickT : 그들은 같은 것이 아닙니다. 옥텟은 항상 8 비트이며, 바이트는 무엇이든 될 수 있습니다.
Jörg W Mittag

4
이 기사에서는 일부 초기 IBM PC에서 사용 된 메모리 수정 메커니즘을 언급하고 있었지만 "바이트는 8 비트 데이터 + 1 비트 패리티"라는 말은 전혀 말이 안된다는 내용입니다. 예를 들어, CD-ROM은 일반적으로 훨씬 더 욕심 많은 오류 수정 메커니즘을 사용합니다. 일반적인 오디오 CD는 24 바이트의 오디오 데이터 당 8 바이트를 사용합니다. 그러나 가장 중요한 부분은 신경 쓰지 않는 것 입니다. 조금도. 실제 메모리 저장 메커니즘에만 적용됩니다. CPU는 신경 쓰지 않으며 코드는 신경 쓰지 않습니다.
Luaan

답변:


79

한 바이트의 데이터는 8 비트이며 OS에서 사용되는 데이터 또는 바이트 당 더 많은 비트가 있거나 오류 검사 (패리티 비트 또는보다 고급 오류 감지 체계)를위한 하드웨어 수준에 사용될 수 있지만 데이터는 8입니다. 비트 및 모든 패리티 비트는 일반적으로 소프트웨어에 보이지 않습니다. 바이트는 '8 비트 데이터'를 의미하도록 표준화되었습니다. 텍스트는 8 비트의 데이터보다 1 바이트의 데이터를 저장하기 위해 전용으로 더 많은 비트가있을 수 있다고 말하는데 잘못은 아니지만 일반적으로 바이트 자체의 일부로 간주되지 않으므로 텍스트 자체 가이 사실을 가리 킵니다.

튜토리얼의 다음 섹션에서이를 확인할 수 있습니다.

Doubleword: a 4-byte (32 bit) data item

4 * 8 = 32, 실제로 시스템에서 36 비트를 차지할 수 있지만 의도와 목적을 위해 32 비트입니다.


5
하드웨어가 오류 감지를 구현한다면 아마도 512 바이트 섹터와 같이 바이트보다 큰 메모리 청크에서 그렇게 할 것입니다. 이런 식으로 필요한 추가 메모리의 오버 헤드를 줄일 수 있습니다. 간단히 설명하자면, 오류를 수정하더라도 하드웨어는 여전히 바이트 당 8 비트와 각 데이터의 "청크"에 대해 약간의 비트를 사용하는데, 이는 아마도 단일 바이트보다 훨씬 클 것입니다.
Bakuriu

11
소프트웨어로 볼 수있는 8 비트가 아닌 바이트가있는 시스템이 있습니다. 8 비트 문자 이외의 플랫폼이있는 플랫폼을 참조하십시오 . StackOverflow에서 질문하십시오.
Ruslan

3
예, 그들은 실제로 존재합니다. 그 특정 링크는 8 비트가 아닌 문자에 대해 이야기하고 있지만. 그대로 : 주어진 시스템이 'char'를 저장하는 데 걸린 비트 수를 간단히 나타내는 데 사용되는 바이트는 6 비트만큼 낮습니다. 그러나 IIRC는 바이트가 8 비트임을 IEC-80000 사양에서 표준화합니다. 주류 시스템에서 멀어짐에 따라 당연히 이상한 점이 발견되고 표준은 법이 아닙니다.
JustAnotherSoul

3
@JustAnotherSoul : 그리고 "최소 8 비트"또는 다른 방식으로 바이트를 정의하는 경쟁 표준이 있습니다. 수십 년 후 바이트의 정의가 사람들의 마음에 어떻게 바뀌는지를 보는 것은 흥미 롭습니다. 훨씬 더 많은 아키텍처 이질성 바이트 시대에는 단순히 아키텍처에서 주소 지정이 가능한 가장 작은 단위였습니다 (예를 들어 다양한 PDP 참조). 이것은 또한 인터넷이 출현함에 따라 바이트 가 8 비트 데이터 청크에 대한 보편적 인 단어가 아니기 때문에 옥텟 이라는 용어 가 와이어상의 데이터를 설명하는 데 사용 된 이유이기도합니다 .
PlasmaHH

2
@JustAnotherSoul char은 C에서 (링크가 무엇인지) 정확히 주소 지정 가능한 가장 작은 메모리 단위 라는 점에 유의하십시오 . 방금 char 이라고 하지만 C 표준은 byte와 동의어를 만듭니다 .
Ruslan

48

일반적으로 바이트는 모든 크기가 될 수 있으며 주소 지정이 가능한 가장 작은 메모리 단위입니다. 요즘 소프트웨어에 대해 8 비트 바이트가 거의 표준화되었습니다. JustAnotherSoul이 말했듯이 하드웨어는 8 비트의 데이터보다 많은 비트를 저장할 수 있습니다.

FPGA와 같은 프로그래머블 로직 디바이스에서 작업하는 경우 내부 메모리를 종종 9 비트 청크로 처리 할 수 ​​있으며 HDL 작성자는 9 비트를 사용하여 오류를 확인하거나 더 많은 양을 저장할 수 있습니다. "바이트"당 데이터 수 맞춤형 하드웨어 용 메모리 칩을 구입할 때 일반적으로 8 또는 9 비트 주소 지정 가능 장치 (또는 16/18, 32/36 등)를 선택할 수 있으며, 9 비트 "바이트"를 가지고 있는지 여부는 사용자에게 달려 있습니다. 당신이 그것을 선택한다면 당신은 그 9 번째 비트와 함께합니다.


10
일반적으로 논리적으로 단일 단위이지만 8 비트보다 많거나 적은 데이터 그룹이있는 경우이를 "워드"라고합니다. 예를 들어, 일부 프로세서는 40 비트 명령어를 사용합니다.
Devsman

3
+1. 또한 "비트 포인터"와 "바이트 포인터"를 모두 갖춘 아키텍처가 있습니다. 그러한 아키텍쳐에서, 바이트는 기술적으로 "어드레싱 가능한 가장 작은 메모리 단위"가 아닙니다 (각 비트를 독립적으로 처리 할 수 ​​있기 때문에 ) . 나는 그것이 "내가 그것을 볼 때 그것을 알고있다"고 생각합니다. - P
ruakh

18
"옥텟 (Octet)"은 전통적으로 사용 된 단어로 "바이트라고 부르지 만 실제로는 정확히 8 비트를 의미합니다"는 바이트 크기가 다른 시스템 간의 다양한 통신 프로토콜에 사용됩니다. 그러나 요즘에는 8 비트 이외의 것을 의미하기 위해 바이트를 사용하는 것이 시대를 초월합니다.
wnoise dec

@Devsman 반드시 그런 것은 아닙니다. 예를 들어 x86 칩은 32 비트 워드와 8 비트 바이트를 갖습니다. 바이트는 주소 지정이 가능한 가장 작은 크기입니다. 단어는 좀 더 모호하게 정의되어 있지만 작업하기에 가장 편리한 크기 인 경향이 있습니다. 즉, 대부분의 명령어의 예상 피연산자 길이입니다.
Ray

정답으로 표시해야합니다. 더 정확합니다.
awiebe

32

그 텍스트는별로 좋지 않습니다. 그는 거의 확실하게 ECC (오류 수정 코드) RAM에 대해 이야기하고 있습니다.

ECC 램은 일반적으로 9 비트를 사용하여 8 비트의 정보를 저장합니다. 바이트 당 추가 비트는 오류 수정 코드를 저장하는 데 사용됩니다.

ECC와 비 ECC (두 경우 모두, 모든 바이트가 모든 칩에 분산됩니다. 이미지 제공 : Puget Systems )

이것은 하드웨어 사용자에게는 완전히 보이지 않습니다. 두 경우 모두이 RAM을 사용하는 소프트웨어는 바이트 당 8 비트를 봅니다.


제쳐두고 : RAM의 오류 수정 코드는 일반적으로 실제로 바이트 당 1 비트가 아닙니다; 대신 8 바이트 당 8 비트입니다. 이것은 동일한 공간 오버 헤드를 갖지만 몇 가지 추가 장점이 있습니다. 자세한 내용은 SECDED 를 참조하십시오 .


12
패리티 RAM과 ECC RAM은 다릅니다. 패리티 RAM은 오류 도메인 당 하나의 추가 비트를 저장하고 모든 단일 비트 오류와 이중 비트 오류를 ​​감지 할 수 있으며 아무것도 고칠 수 없습니다. ECC는 오류 도메인 당 다수의 추가 비트를 저장하고 모든 단일 비트 오류를 ​​감지 및 수정할 수 있으며 모든 이중 비트 오류를 ​​감지 할 수는 있지만 수정할 수 없으며 더 큰 오류를 포착 할 수 있습니다. 오늘날 패리티 RAM은 거의 전적으로 ECC RAM으로 대체 된 경우는 드 rare니다.
Mark

1
@ Mark : 마지막 단락에서 힌트를 얻었습니다. 링크에 자세한 내용이 있습니다. (72,64) 오류 수정 코드는 (9,8) 패리티 코드와 동일한 오버 헤드를 가지기 때문에 요즘 패리티 RAM은 기본적으로 존재하지 않습니다.
BlueRaja-대니 Pflughoeft

7
힌트를 주면서도 부정확하고 혼동을 일으키는 것들도 언급합니다. ECC RAM은 "9 비트를 사용하여 8 비트의 정보를 저장하지 않습니다". 9 비트를 사용하여 8 비트에 대해 ECC를 수행 할 수 있음을 의미하지만 불가능합니다. 8 비트의 이산 정보의 경우, 1 개의 추가 비트로 단일 비트 오류를 ​​정정 할 있습니다. ECC는 일반적으로 단일 바이트보다 큰 데이터 그룹의 오류를 정정하기에 충분한 데이터를 포함하기 위해 더 많은 수의 비트 또는 바이트를 사용합니다. 이는 8 비트 당 추가 비트를 평균화 할 수 있지만 각 8 비트와 1 비트 만 연관시키는 것으로 나눌 수는 없습니다.
Makyen

단일 비트 오류 수정 및 2 비트 오류 감지를 허용하는 36 비트 체계 (32 비트 워드 + 4 비트 ECC)가 있습니다. 산술적으로 8 데이터 비트 + 1 ECC 비트로 나눌 수는 있지만 그렇게 작동하지는 않습니다. 32 개의 데이터 비트를 포괄하는 ECC의 전체 4 비트가 필요합니다.
Zenilogix

@Zenilogix와 같은 일을 반복 한 사람들 : ECC의 작동 방식을 잘 이해하고 있으며 내가 잘못한 말은 없습니다. 나는 8 비트 ECC가 9 비트로 수행 될 수 있다고 주장하지 않았다 .ECC RAM은 바이트 당 9 비트 스토리지를 사용한다고 말했다. ECC의 작동 방식은이 질문에서 완전히 벗어난 것이므로 세부 정보를 링크와 함께 따로 남겨 두었습니다. 모든 pedantic 의견을 중지하십시오.
BlueRaja-대니 Pflughoeft

16

일반적으로 짧은 대답은 바이트가 8 비트라는 것입니다. 이것은 문제를 지나치게 단순화하지만 (때로는 부정확 한 점까지), 대부분의 사람들 (많은 프로그래머를 포함하여)이 잘 알고있는 정의이며, 거의 다른 크기의 바이트에 관계없이 거의 모든 사람들이 기본적으로 정의합니다. ve와 협력해야 함).

보다 구체적으로, 바이트는 주어진 아키텍처에서 주소 지정이 가능한 가장 작은 메모리 단위이며 일반적으로 단일 텍스트 문자를 포함 할 수있을만큼 큽니다. 대부분의 최신 아키텍처에서 바이트는 8 비트로 정의됩니다. ISO / IEC 80000-13은 인기있는 컨센서스와 마찬가지로 바이트가 8 비트임을 지정합니다 (예를 들어 9 비트 바이트에 대해 이야기하는 경우 명시 적으로 언급하지 않는 한 많은 문제가 발생 함을 의미 함) 정상 바이트를 의미하지 않는다고 진술하십시오).

그러나이 규칙에는 예외가 있습니다. 예를 들면 다음과 같습니다.

따라서 대부분의 경우 바이트는 일반적으로 8 비트입니다. 그렇지 않은 경우 아마도 9 비트 일 수 있으며 36 비트 워드의 일부일 수도 있고 아닐 수도 있습니다.


8

바이트 라는 용어 는 문맥이 없으면 잘 정의되어 있지 않습니다. 컴퓨터 아키텍처와 관련하여 최소한 현대 아키텍처의 경우 바이트가 8 비트라고 가정 할 수 있습니다. 이것은 C와 같은 프로그래밍 언어에 의해 크게 표준화되었으며, 바이트 는 최소 8 비트 를 가져야 하지만 더 큰 바이트를 보장하지 않으므로 바이트 당 8 비트가 유일한 안전한 가정입니다.

주소 지정 가능한 단위가 8 비트 (일반적으로 16 또는 32)보다 큰 컴퓨터가 있지만 이러한 단위를 일반적으로 바이트가 아닌 기계어라고합니다. 예를 들어, 32K 32 비트 RAM 워드를 가진 DSP는 32KB가 아닌 128KB 또는 RAM을 갖는 것으로 광고됩니다.

통신 표준에 관해서는 잘 정의되어 있지 않습니다. ASCII 는 여전히 널리 사용되며 7 비트 바이트 (컴퓨터의 8 비트 바이트에 잘 맞음)를 갖습니다. UART 트랜시버는 여전히 구성 가능한 바이트 크기를 갖도록 제작됩니다 (일반적으로 바이트 당 6, 7 및 8 비트 중에서 선택하지만 5와 9는 들어 본 적이 없습니다).


6

바이트는 일반적으로 주소를 지정할 수있는 가장 작은 메모리 공간 단위로 정의됩니다. 모든 크기가 될 수 있습니다. 6에서 9 비트 사이의 바이트 크기를 가진 아키텍처가 있었으며 아마도 더 클 수도 있습니다. 주소를 지정할 수있는 유일한 단위가 버스의 크기 인 아키텍처도 있습니다. 이러한 아키텍처에서 우리는 단순히 바이트가 없거나 바이트 와 단어의 크기가 같다고 말할 수 있습니다. 32 비트 여야 함); 어느 쪽이든, 그것은 확실히 8 비트가 아닙니다. 마찬가지로 비트 주소 지정 가능 아키텍처가 있습니다. 이러한 아키텍처에는 바이트가 단순히 존재하지 않는다고 주장하거나 바이트가 1 비트라고 주장 할 수 있습니다. 어느 쪽이든 현명한 정의이지만 8 비트는 확실히 잘못되었습니다.

많은 주류 범용 아키텍처에서 1 바이트는 8 비트를 포함합니다. 그러나 이것이 보장되지는 않습니다. 주류 및 / 또는 범용 CPU에서 멀어 질수록 8 비트가 아닌 바이트가 발생할 가능성이 높습니다. 지금까지 휴대 성이 뛰어난 일부 소프트웨어는 크기를 구성 할 수있게되었습니다. 예를 들어 이전 버전의 GCC BITS_PER_BYTE에는 특정 아키텍처의 바이트 크기를 구성 하는 매크로 (또는 이와 유사한 것)가 포함되어 있습니다. 일부 이전 버전의 NetBSD는 바이트 당 8 비트가 아닌 아키텍처에서 실행될 수 있다고 생각합니다.

실제로 주소 지정이 가능한 가장 작은 메모리가 아닌 8 비트의 정확한 양에 대해 이야기하고 있다고 강조하고 싶다면, 많은 새로운 RfC에서 사용되는 octet 이라는 용어를 사용할 수 있습니다 .


2
표준 C 및 C ++에는 미리 정의 된 매크로 CHAR_BIT(에서 발견됨 limits.h)가 있습니다.BITS_PER_BYTE
njuffa

3

1960 년에 프로그래밍을 시작했을 때, 우리는 6 비트 바이트를 가진 48 비트 워드를 가지고있었습니다. 그런 다음 75 비트 단어와 15 비트 바이트로 Golem 컴퓨터에서 작업했습니다. 나중에 IBM이 360을 출시 할 때까지 6 비트 바이트가 표준이되었으며 현재는 1 바이트는 일반적으로 8 비트, 즉 8 비트의 데이터와 같습니다. 일부 하드웨어에는 오류 감지 및 오류 수정을위한 추가 비트가 있었지만 소프트웨어에서 액세스 할 수 없었습니다.


3

바이트는 8 비트입니다.

먼 과거에는 메모리 단어와 바이트에 대한 다른 정의가있었습니다. 이 모호함이 오늘날 널리 퍼져 있거나 널리 퍼져 있다는 제안은 거짓입니다.

적어도 1970 년대 후반부터 바이트는 8 비트였습니다. 가정용 컴퓨터 및 PC의 대중은 플로피 디스크 드라이브, 하드 디스크 드라이브 및 PROM / EPROM / EEPROM / Flash EPROM에 대한 모든 데이터 시트 및 문서와 같이 문서에서 8 비트 값으로 바이트를 분명하게 사용했습니다. 해당 기간 동안 읽은 / SRAM / SDRAM 메모리 칩. (그리고 그 기간 동안 개인적으로 많은 것을 읽었습니다.) 이더넷과 몇 가지 다른 통신 프로토콜은 옥텟에 대해 특이한 것으로 나에게 두드러집니다.

바이트라는 용어의 모호성은 그 자체로 희귀하고 모호한 것입니다. 지난 30 년 이상 동안 프로그래머, 설계 엔지니어, 테스트 엔지니어, 영업 사원, 서비스 엔지니어 또는 평균 펀터 인구 중 극소수의 사람들이 단어를 전혀 인식하지 못하면 8 비트 이외의 다른 의미로 생각할 것입니다. .

바이트가 메모리 칩에 저장되거나 와이어를 따라 통신 될 때와 같이 하드웨어에 의해 처리 될 때, 하드웨어는 바이트에 여분의 데이터를 추가 할 수있다. 이것은 나중에 신뢰할 수없는 데이터를 인식하고 버릴 수 있도록 하드웨어 오류를 감지하는 데 도움이 될 수 있습니다 (예 : 패리티, 체크섬, CRC). 또는 데이터의 오류를 수정하고 데이터를 복구 할 수 있습니다 (예 : ECC). 어느 쪽이든, 여분의 데이터는 바이트가 추가 처리를 위해 검색되거나 수신 될 때 폐기됩니다. 바이트는 중앙 8 비트 값으로 유지되고 중복 데이터는 중복 데이터로 유지됩니다.


2

먼저, 참조하는 튜토리얼은 상당히 오래된 것으로 보이며 언급하지 않고 오래된 버전의 x86 프로세서에 대한 것으로 보이므로 거기에서 읽은 많은 것들이 다른 사람들에 의해 이해되지 않을 것입니다 (예 : 주장하는 경우) WORD가 2 바이트 인 경우 사람들은 당신이 무슨 말을하는지 알지 못하거나 매우 오래된 x86 프로세서를 기반으로 가르쳤다는 것을 알게 될 것입니다.

바이트는 누군가가 결정해야하는 비트 수입니다. 8 비트 또는 9 비트 또는 16 비트 일 수 있습니다. 2016 년에 대부분의 경우 바이트는 8 비트입니다. 안전을 위해 옥텟이라는 용어를 사용할 수 있습니다. 옥텟은 항상 8 비트입니다.

여기서 실제 혼란은 두 가지 질문을 혼란스럽게합니다. 1. 바이트의 비트 수는 얼마입니까? 2. 한 바이트를 한 장소에서 다른 장소로 옮기고 싶거나 실제 물리적 수단을 사용하여 바이트를 저장하려면 어떻게해야합니까? 두 번째 질문은 모뎀, 하드 드라이브 또는 SSD 드라이브를 만드는 회사에서 일하지 않는 한 일반적으로 거의 관심이 없습니다. 실제로 첫 번째 질문에 관심이 있고 두 번째 질문에 대해서는 "누군가가 그것을 돌보는 것"이라고 말합니다.

언급 된 패리티 비트는 바이트가 메모리에 저장 될 때 바이트를 읽을 때 메모리가 우연히 변경되었음을 감지하는 데 도움이되는 기본 메커니즘입니다. 두 비트가 변경되지 않았으므로 변경이 감지되지 않을 가능성이 높고 8 비트 중 변경된 비트를 찾을 방법이 없기 때문에 문제를 해결할 수 없기 때문에 그다지 좋지 않습니다. 또는 패리티 비트가 변경된 경우에도 마찬가지입니다.

패리티 비트는 실제로 해당 기본 형식으로 사용되지 않습니다. 영구적으로 저장되는 데이터는 일반적으로 1024 바이트 블록에 32 비트 이상의 체크섬을 추가하여보다 복잡한 방식으로 보호됩니다. 이는 훨씬 적은 공간 (이 예제에서는 12.5 % 대신 0.4 %)이 훨씬 많이 소요됩니다. 언제 문제가 있는지 알 수 없을 것입니다.


실제 구식 : 16 바이트 "단락"은 실제 모드와 세그먼트 주소 지정에서 전환 한 이후 의미있는 메모리 단위가 아닙니다.
Mark

개인적으로, 나는 누군가 2 바이트에 대해 말할 때 "WinAPI"라고 가정 WORD합니다. xP
Justin Time

1

여기에 주어진 훌륭한 답변에도 불구하고, 아무도 패리티 비트 또는 오류 수정 비트 가 '메타 데이터'로 정의되어 바이트 자체의 일부가 아니라고 지적한 사람이 아무도 없습니다 .

바이트는 8 비트입니다 !


0

현대의 사용법에서 바이트는 8 비트, 기간입니다 (역사적으로 다른 정의가 있었음에도 불구하고). 반면에 데이터 워드는 문제의 하드웨어가 원자 단위로 처리하는 모든 것입니다. 8 비트, 9 비트, 10 비트, 12 비트, 16 비트, 20 비트, 24 비트, 32 비트 등이 될 수 있습니다. 수년에 걸친 시스템은 모든 종류의 단어 크기를 가졌습니다.

메모리 시스템 또는 전송 프로토콜을 구현하려면 추가 비트를 포함하는 오류 감지 / 수정을 추가하는 것이 좋습니다. 위에서 언급했듯이 바이트는 8 비트이기 때문에 9 비트 바이트를 만들지 않습니다.

다양한 방식은 다양한 방식으로 에러 검출 및 / 또는 정정을 추가한다.

패리티의 일반적인 사용은 수신기가 단일 비트 오류를 ​​감지 할 수 있도록 전송 워드에 추가 비트를 추가하는 것입니다.

단일 비트 오류 정정을 제공 할 수있는 방식은 32 비트 데이터 워드 당 4 개의 ECC 비트를 추가하는 것입니다. 이것은 바이트 당 1 비트와 산술적으로 동일하지만 그렇게 작동하지는 않습니다. 하나의 36 비트 데이터 워드는 32 비트 데이터 공간에 대한 단일 비트 오류를 ​​복구하기에 충분한 정보를 전달할 수 있습니다.


0

8 비트 CPU 및 키보드 내부는 9 및 11 비트입니다. 사용자 데이터는 8 비트로 표시됩니다. 키보드의 키는 노래를 보내며 11 비트로 나뉩니다. 누른 키를 나타내는 1 개의 시작 비트, 1 개의 종료 비트, 1 개의 패리티 비트 및 8 비트


2
이 질문에 대답합니까? CPU의 바이트 길이와 키보드의 바이트 길이가 다른 것을 의미합니까? "노래"가 "문자열"또는 "스트림"이어야합니까?
Apass.Jack

실제 데이터 자체가 아닌 프레이밍 데이터를 포함한 와이어 프로토콜에 대해 이야기하는 것처럼 들립니다.
Peter Cordes

나는 "노래"가 "신호"라고 생각한다. @ Apass.Jack.
Justin Time
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.