왜 코드에서 100 % CPU를 사용하지 않아야합니까? [닫은]


42

Windows XP 이상에서 실행되는 C # .NET 4 프로그램에 대해 구체적으로 말하고 있지만 일반적인 대답도 허용됩니다.

이미 최적화되고 효율적인 프로그램을 가정하십시오. 여기서 문제는 전적으로 CPU 사용률이 하드웨어에 미치는 영향과 내 구현의 효율성이 아니라 마모를 줄이기 위해 사용량이 많은 프로그램을 조절해야하는지 여부입니다.

동료는 오늘 "현대 CPU가 싸고 100 % CPU에서 빠르게 저하 될 것"이므로 데이터로드 프로세스에서 100 % CPU 사용을 목표로하지 말아야한다고 제안했습니다.

이것이 사실입니까? 그렇다면 왜 그렇습니까? 이전에 100 % CPU 사용이 집중적이거나 긴 작업에 바람직하다는 인상을 받았으며, 어느 쪽이든 주제에 대한 적절한 소스를 찾을 수 없었습니다.


6
응용 프로그램이 상자에서 실행되는 유일한 것으로 가정하면 엄밀히 말하면 100 % CPU 사용률은 실제로 나쁘지는 않지만 오히려 더 나은 일이있을 수 있음을 나타낼 수 있습니다. 나는 데스크톱 앱을 많이 사용하지는 않았지만 웹 애플리케이션의 경우 CPU 부하를 최대로 활용하는 애플리케이션을 본 적이 없으며 이러한 사이클을 사용하는 코드가 실제로 최적이었습니다. 항상 잘못된 것이 있습니다. 그러나 그것은 웹상에서 종종 I / O에 묶여 있기 때문에 CPU 문제는 부적절 해 보입니다. 귀하의 앱이 다르다고 확신합니다.
Brandon

7
또한 다른 운영 체제에서이 경우를 다르게 처리합니다. 예를 들어, 내 Windows 상자는 CPU를 100 % 사용하면 크게 실행됩니다. 반면에 Linux 서버가 며칠 동안 100 % CPU에서 실행되는 것을 보았습니다. (우리는 며칠 후 수정을 출시했다지만.)
브랜든

17
지나치게 낭비하지 않고 가능한 한 빨리 일하고 싶습니다. 유용한 계산을 위해 CPU의 100 %를 사용하면 좋습니다. 쓸모없는 루프에서 CPU의 100 %를 사용하면 낭비입니다.
nwp

10
당신은 그것을 전부 지불했다. 모두 사용하십시오.
Brian Hooper

4
이 질문은 프로그래밍에 관한 것이 아니라 전자에 관한 것이기 때문에 주제가 아닌 것 같습니다.

답변:


59

냉각이 충분하지 않으면 CPU가 과열 될 수 있습니다. 그러나 그들 모두 (적어도 모든 최신 PC CPU)는 클럭 속도를 조절하거나 최종 수단으로 종료되는 다양한 열 보호 메커니즘을 갖추고 있습니다.

따라서 먼지가 많은 랩탑에서는 100 % CPU로드로 인해 일시적인 문제가 발생할 수 있지만 아무 것도 깨지거나 "저하"되는 것은 없습니다.

CPU 바운드 문제의 경우 100 % CPU로드가 올바른 방법입니다.

애플리케이션 (UI) 응답 성은 CPU 사용률과 별개의 개념입니다. 1 % CPU를 사용하는 응답없는 응용 프로그램 또는 100 % CPU를 사용하는 응답 성이있는 응용 프로그램을 갖는 것은 전적으로 가능합니다. UI 응답 성은 UI 스레드에서 수행 된 작업량과 UI 스레드와 다른 스레드의 우선 순위로 요약됩니다.


3
그리고 OS는 심지어 코어를위한 쿨 다운 슬라이스를 시행 할 수도 있습니다.
ratchet freak

8
실제 대답은 대부분의 프로세스가 CPU 바운드가 아니라 I / O 바운드라는 것입니다. 이것이 일반적으로 우리가 적어도 "일반 / 일반"계산을 위해 100 % CPU 사용량이 비정상적인 세계에 사는 이유입니다.
윈드 파인더

4
@windfinder "computation"의 경우 100 % 달성은 매우 표준이지만 "computation"이 수학으로 무언가를 수행해야하는 한에만 :) 예를 들어 MySQL 쿼리 처리는 나에게 계산되지 않습니다.)
yo '

@ tohecz-내가 사용한 의미에서 계산은 CPU 시간을 의미합니다. 우리는 여기서 용어에 대해 논쟁 중입니다. CPU가하는 모든 것은 계산 ( "계산")입니다. 데이터 과학자로서 나는 또한 대부분의 수학도 I / O 바인딩 (가장 사소한 수학을 넘어서서)이라고 말합니다. 수학 세계에서 많은 시간을 할애하여 CPU 사용률을 최대한 유지하기 위해 (물론 캐시 비 효율성을 최소화하면서) 데이터를 프로세서로 효율적으로 압축 / 스트리밍하는 방법을 찾고 있습니다.
윈드 파인더

4
"먼지가 많은 랩탑"의 일화 : 석사 논문 실험을 위해 4 살짜리 랩탑을 러너로 사용했습니다. 약 3 개월 동안 24/7 100 % CPU 사용률 . 그 후, 랩탑은 유령을 포기하기 전에 4 년 동안 서버 역할로 위임되었습니다 (아마도 손상된 그래픽 문제로 인해).
mikołak

15

Windows 프로그램 (winforms / WPF)은 항상 반응을 유지해야합니다. 100 % CPU 리소스를 사용하는 프로세스의 순진한 구현으로 인해 프로그램이나 시스템이 느리고 중단되는 것처럼 보이게하기가 너무 쉽습니다.

구현이 우수하면 (예 : 우선 순위가 낮은 별도의 스레드 사용) 문제가되지 않습니다.

CPU가 더 빨리 깨지는 것에 대해 걱정하지 않아도됩니다.


3
물론 장기 계산을 수행하는 프로그램은 winforms / wpf 응용 프로그램이 아니라 UI가없는 배치 작업이어야합니다. 따라서 반응 형 UI 스레드를 신경 쓸 필요가 없으므로 작업 스케줄러 등을 통해 시작할 수 있습니다. UI가 필요한 경우 여전히 완전히 별도의 프로세스로 런처 응용 프로그램을 권장합니다 (응답을 쉽게 유지할 수 있습니다. 배치 작업의 상태 메시지 대기를 차단하지 않아도됩니다).
Jan Hudec

15

100 % CPU 사용하는 프로그램 에는 실제로 유용한 작업을 수행하고 더 중요한 것에서 시간을 허비하지 않는 프로그램에는 일반적으로 아무런 문제 가 없습니다 . 예를 들어 특정 하드웨어 플랫폼이 과열을 피하기 위해 50 %로 다시 조정하기 전에 1 초 동안 100 % CPU 만 계속 사용할 수있는 경우 유용한 작업을 수행 하는 응용 프로그램이 일반적으로 더 좋습니다응용 프로그램이 얼마나 빨리 실행해야하는지 추측하는 것보다 CPU 또는 OS가 필요한 제한을 처리하도록합니다. 응용 프로그램이나 스레드에 우선 순위가 낮은 작업이 유용하지만 항상 중요하지 않은 작업이 있으면 OS가 우선 순위가 낮은 작업 CPU 사용량을 50 %로 제한하여 CPU가 필요한 경우 빠르게 "스프린트"할 준비가되지만, 애플리케이션은 낮은 스레드 우선 순위를 요청하는 것 이상으로 걱정하지 않아야합니다.

100 % CPU를 사용하는 것이 좋지 않은 가장 큰 상황은 다음 중 하나입니다.

  • 응용 프로그램은 지속적으로 폴링에 의해 재촉하지 않을 [하고 작업이 완료 여부를 확인 낭비 노력 그렇지 않으면 소비 할 수있는 CPU 리소스를 차지하면 실제로는 지연 될 수있는 몇 가지 이벤트에 대한 바쁜 대기 하고 작업을].

  • 응용 프로그램이 디스플레이를 너무 자주 다시 그리는 중입니다. "과도하게 자주"의 정의는 디스플레이 장치의 특성 및 표시되는 컨텐츠에 따라 어느 정도 좌우 될 것이다. 디스플레이 하드웨어가 120fps를 표시 할 수있는 경우 모션 블러를 추가하지 않고 애니메이션을 120fps로 표시 할 수 있지만 추가하지 않고 낮은 프레임 속도에서는 깨끗하게 표시 할 수없는 경우가 있습니다. 모션 블러를 사용하여 프레임을 렌더링하는 것이 프레임없이 렌더링하는 것보다 훨씬 오래 걸리는 경우이를 지원하는 하드웨어에서 120fps로 렌더링하는 것은 모션 블러를 사용하여 느린 프레임 속도로 렌더링하는 것보다 비용이 많이 들지 않습니다. [단순한 상황 : 스포크가 29 개인 휠이 초당 1 회전으로 회전합니다. 120fps에서 휠은 적절한 속도와 방향으로 회전하는 것처럼 보입니다. 60fps에서

전자는 분명히 나쁜 것으로 인식됩니다. 두 번째는 조금 더 미묘합니다. 모바일 플랫폼을 목표로하는 경우 일부 사용자는 배터리 수명에 대해 걱정하지 않지만 최상의 품질의 애니메이션을 원하지만 다른 사용자는 낮은 품질을 받아 들일 수 있기 때문에 사용자가 원하는 애니메이션 프레임 속도를 선택할 수 있도록하는 것이 바람직 할 수 있습니다 배터리 수명 향상을위한 애니메이션. 응용 프로그램이 트레이드 오프 위치를 추측하도록하는 대신 사용자가 사용자 정의 할 수 있도록하는 것이 도움이 될 수 있습니다.


10

"현대 CPU는 저렴하고 100 % CPU에서 빠르게 저하됩니다".

나는 누군가이 질문의 "degrade"부분을 실제로 다루지 않았다고 생각합니다. 다이 온도 가 제조업체의 한계를 초과하면 IC가 저하됩니다 . IC는 일반적으로 최대 125C까지 작동하도록 설계되었지만 10C가 증가 할 때마다 수명이 50 % 단축됩니다.

프로세서에는 항상 온도 조절 기능이 없었습니다. 그런 다음 일부 AMD Durons에서 문제가 발생했습니다 (히트 싱크없이 실행하면 문제를 해결할 수 있음). 이제 모든 PC 프로세서에는 내장 온도 센서가 내장되어 CPU 클럭으로 피드백되고 손상을 방지하기 위해 클럭 속도가 느려집니다. 따라서 프로그램이 사용 가능한 CPU의 100 %를 사용하고 있지만 냉각이 부적절하기 때문에 CPU가 정격 속도의 75 %로만 실행되고 있음을 알 수 있습니다.

사용자 프로그램 내에서 CPU 소비를 관리 할 올바른 위치가 아닙니다. 일반적으로 프로그램은 가능한 빨리 작업을 수행하고 입력 또는 디스크 액세스를 위해 대기, 일시 중지하는 방법을 번갈아 사용해야합니다. 가능하면 통화 중 대기 및 스핀 록을 피해야하지만 나머지 시스템에 대한 예의입니다.

Windows와 Linux에는 모두 성능 및 열 관리를 수행하는 CPU "govenor"시스템이 있습니다. 이는 OS 수준에서 수행되므로 전체 시스템 CPU 소비를 설명 할 수 있습니다. 하드웨어를 관리하고 사용자 프로그램이이를 잘못 사용하지 못하도록하는 것은 운영 체제의 책임입니다. 팬을 깨끗하고 작동 상태로 유지하는 것은 하드웨어 소유자 의 책임이며 제조업체는 적절한 방열판과 팬을 먼저 설치해야합니다.

장치의 냉각이 부적절한 경우가 몇 가지 있지만, 대량의 반품으로 인해 제조업체는 그렇게하지 않아야합니다.


폭발하는 AMD Duron의 비디오는 가짜 일 것입니다. 온도 조절에 대한 귀하의 진술은 여전히 ​​유효합니다.
Sam

1
흠, 나는 구글에서 가짜라고 주장하는 것을 많이 볼 수 있기 때문에 그것을 꺼냈다.
pjc50

3
SSE 엔진을 푸시하고 OS에서 CPU 조절을 의도적으로 비활성화하는 코드를 작성하여 최신 Intel Core CPU를 과열시킬 수 있습니다. CPU 제조업체가 항상 클럭 사이클 당 4 개의 플롭을 계산하도록 강제하는 것은 정상적이지 않다는 가정하에 제조업체 (인텔 자체도 포함)가 열 요구 사항을 설계하는 것 같습니다. 누군가 실제로 코드를 작성하면 CPU가 과열되기 시작합니다. 참조 : stackoverflow.com/questions/8389648/...
slebetman

^ "히트 싱크없이 실행하면 하나를 파괴 할 수 있음" - "개인적으로 확인했습니다" . 히트 싱크없이 초기 K7을 파괴 할 수있었습니다 .. ; 그것은 거의 20 년 전과 같습니까? !!
user2864740

3

악마의 옹호자를 연기하는 방법 : 100 % 활용률에 도달 할 수없는 프로그램은 마모를 일으킬 수 있습니다. 키 입력을 기다리는 동안 일시 중지되지 않는 한 디스크 I / O를 기다리는 동안 대부분 일시 중지 될 가능성이 있습니다. 그리고 디스크는 (일반적으로) 큰 기계적 장치이며, 전력 소모는 말할 것도없고 기계적 마모 또는 이동시 충격 / 자이로 스코프의 영향을받습니다.


이 경우 몇 분 정도 걸리는 대용량 (메모리 내) 데이터 세트에 대한 복잡한 프로세스 일뿐입니다. 그러나 다른 독자에게는 분명히 좋은 지적입니다.
Nick Udell

3

".. 현대 CPU는 저렴하고 100 % CPU에서 빠르게 저하됩니다."

"CPU 성능 저하"에 대해 전혀 걱정할 필요가 없습니다. 최신 CPU는 이전보다 품질이 떨어집니다.

CPU를 만드는 것은 매우 비싸고 (2 년마다 더 비싸지고 있습니다), 새로운 팹을 구축하는 데 수십억의 사람들이 드문 일이 아닙니다 (링크 참조).

http://en.wikipedia.org/wiki/Semiconductor_fabrication_plant

CPU의 생산 비용은 최대에 달려 있습니다. 생산 단위. 이것은 경제에서 잘 알려진 사실입니다. 그것이 그들이 "상대적으로"싼 가격으로 팔릴 수있는 이유입니다. (여기서는 링크가 필요하지 않습니다)

현대 CPU가 "이전 시대"보다 품질이 더 좋은 경향이 있다고 생각하는 여러 가지 이유를 나열 할 수 있습니다.

그러나 가장 중요한 것 : 테스트의 장점. 최신 전자 제품은 "테스트를 위해 설계되었습니다". 소프트웨어 또는 하드웨어, 거의 모든 다른 것들에 대한 테스트 평가의 통찰력은 그리 오래되지 않습니다. CPU의 경우, 다른 가격과 주파수 유형을 형성하기위한 테스트도 수행됩니다. 예를 들어 최상의 CPU는 가장 높은 주파수로 판매됩니다. 그럼에도 불구하고, 더 저렴한 프로세서는 종종 판매되는 것보다 더 높은 주파수로 작동 할 수 있습니다. 제조업체가 더 높은 가격으로 "높은 수준의"프로세서를 판매하기를 원하는 경우에만 파산됩니다.

(다른 한편으로는, 오늘날 70 억 개 이상의 프로세서의 수천 개의 트랜지스터보다 현재 15 억 개 이상의 트랜지스터를 가진 프로세서에 대해 더 많은 오류가있을 수 있습니다. 그러나 이것은 제 답변 IMO와 모순되지 않습니다. 최소한 마이크로 코드에서는 알려진 오류 가 많지만 여기에서는 다루지 않습니다.)

프로그램의 CPU 탈지에 대해 걱정하지 않아도되는 더 많은 이유 가 있습니다 .

  • 첫 번째 이유는 최신 CPU가 너무 뜨거워지면 주파수 나 스로틀을 낮추기 때문입니다.

    연중 내내 CPU 100 % 24/7을 사용하는 경우 일반적으로 매 2 주마다 1 시간 만 사용되는 CPU보다 더 빨리 죽습니다. 그러나 그것은 자동차도 마찬가지입니다. 그런 경우에만 CPU 사용률과 잠재적 잠을 생각합니다.

  • 두 번째 이유는 OS에서 CPU를 100 % 사용하는 프로그램 (예 : Windows)을 작성하는 것이 실제로 매우 어렵다는 것입니다. 게다가, 현대 CPU는 (일반적으로) 적어도 2-4 개의 코어를 가지고 있습니다. 따라서 단일 코어 CPU의 100 %를 사용하는 기존 알고리즘은 이제 듀얼 코어 CPU (단순화되었지만 실제 시나리오에서 볼 수 있음)에는 50 % 만 있습니다.

  • 또한 운영 체제는 프로그램이 아닌 CPU를 제어하므로 우선 순위가 같거나 높은 다른 응용 프로그램 (기본값은 무엇입니까)이있는 경우 프로그램은 가능한 한 많은 CPU 만 가져 오지만 다른 응용 프로그램은 그렇지 않습니다 굶어 죽다. (물론 이것은 단순한 이론 일뿐입니다. 물론 Windows, Linux 및 기타의 멀티 태스킹은 완벽하지는 않지만 전반적으로는 사실이라고 생각합니다).

"이전에는 집중적이거나 긴 작업에 100 % CPU 사용이 선호된다는 인상을 받았습니다."

그렇습니다. 그러나 예를 들어, 다른 프로세스를 기다리는 & 반복, 즉 아무것도하지 않는 경우 해당 루프에서 Thread.Sleep () 밀리 초를 사용하면 다른 프로세스에 추가 시간을 주면 그렇게 나쁘지 않습니다. 좋은 멀티 태스킹 OS에는 필요하지 않지만 Windows 2000과 같은 일부 문제를 해결했습니다. (예를 들어 Sleep ()을 계산에 사용하는 것은 아닙니다.)


3
이 답변은 오늘날에도 사실이지만 미래에 대한 우려가 있습니다. 예전에는 "솔리드 스테이트 (solid state)"가 최고의 안정성을 의미했지만, 이제는 블록 당 1000 개의 소거주기에 대해서만 등급이 지정된 MLC 플래시가 있습니다. 다이 크기가 줄어들 때까지 100 % 지속적으로 실행해야하는 CPU에서 비슷한 현상이 발생할 때까지 얼마나 걸립니까?
Michael

2
@Michael, CPU는 변경되지 않고 휘발성 메모리에 쓰지만 여전히 당신이 말하는 것을 이해합니다.
Peter

3

이러한 분해는 이론적으로 가능하며 " 일렉트로 마이그레이션 "이라고합니다. 일렉트로 마이그레이션은 온도에 따라 달라지며 온도가 올라감에 따라 가속화됩니다. 최신 CPU의 실제 문제인지 여부는 논쟁의 여지가 있습니다. 최신 VLSI 설계 관행은 일렉트로 마이그레이션을 보완하고 칩은 다른 이유로 실패 할 가능성이 높습니다.

전자 이동 은 정상적인 부하와 온도에서도 발생 하지만, 잘 설계된 칩은 실패하기 훨씬 전에 사용되지 않거나 다른 메커니즘을 통해 먼저 실패 할 정도로 느립니다.

일렉트로 마이그레이션의 속도는 칩 온도에 따라 다르며, 수명은 대략 10 ° C마다 두 배가됩니다. 실제로 이것은 "HTOL"(고온 작동 수명)이라는 테스트의 기초이며, 이는 125 ° C에서 칩이 죽는 데 걸리는 시간을 측정합니다. 125 ° C에서 작동하는 칩은 55 ° C에서 작동하는 칩보다 약 100 배 더 빨리 고장납니다. 따라서 55 ° C에서 10 년 이상 지속되도록 설계된 경우 125 ° C에서 1 개월 이내에 칩이 고장날 수 있습니다. 85 ° C와 같이보다 합리적인 수준에서 작동하는 경우 이러한 칩은 설계보다 5-10 배 이상 빨리 실패합니다.

물론 CPU는 일반적으로 더 높은 온도를 염두에두고 설계되므로 일반적으로 85 ° C 24/7 100 % 부하 작동에서 수년간 지속될 수 있습니다. 따라서 CPU "마모"에 대해 걱정하지 말고 소프트웨어 엔지니어링 관점에서 100 %로드가 적절한 지 여부 만 걱정하십시오.


이 단어를 찾으면 SE 네트워크 전체에서 잘 읽히는 많은 결과 가 검색 되며이 중 많은 것이 Electronics.SE 및 SuperUser에 있습니다.

1

클라이언트에서 코드를 실행하는 경우 100 % CPU 사용률은 해당 시간의 클라이언트 컴퓨터를 우선 순위가 높은 작업 이외의 용도로는 사용할 수 없음을 의미합니다. 대부분의 응용 프로그램은 일반적으로 기본 우선 순위로 실행되므로 해당 컴퓨터를 사용하는 사용자는 컴퓨터가 멈추고 컴퓨터에서 다른 컴퓨터를 사용할 수 없게됩니다. 짧은 버스트에 대해 이야기하더라도 무언가를 작업하는 사용자는 여전히 눈에.니다.

다른 사람들이 말했듯이, 당신은 설정에 대해 매우 비밀 스러웠으므로 확실하게 말할 수는 없습니다. 그러나 클라이언트가 데스크톱 컴퓨터 인 경우 100 % CPU 사용률을 유지하십시오. CPU 성능 저하가 아니라 작업 중에 사용자를 방해하는 것이 좋지 않기 때문입니다.


6
Windows는 이런 식으로 작동합니다. Linux 및 기타 많은 시스템에서 무언가를 기다리는 스레드 (사용자 입력)는 할당 된 시간을 사용하여 스레드보다 우선 순위를 자동으로 얻으므로 대화식 프로그램은 우선 순위를 가지고 플레이하지 않아도 응답 성을 유지합니다.
Jan Hudec

2
@ JanHudec Windows는 실제로 그렇게합니다. superuser.com/questions/194223/…
NtscCobalt

@NtscCobalt : 예. 분명히 Windows CE는 아닙니다. 그리고 디스크에 프로세스가 많은 경우에는 Windows에 심각한 문제가 있지만 분명히 다릅니다 (일반적으로 Windows에서는 디스크 처리가 다소 열악합니다).
Jan Hudec

1

따라서 상황은 다음과 같습니다. 모든 CPU의 100 %를 사용하여 5 시간 동안 실행되는 코드가 있습니다. 가능한 한 많이 최적화되어 있으며, 컴퓨터 소유자는 5 시간 동안 컴퓨터를 사용할 수없고 동료는 괜찮습니다. 컴퓨터의 마모가 적기 때문에 모든 CPU의 83.33 %를 사용하여 6 시간 내에 코드를 실행하는 것이 좋습니다.

사용중인 컴퓨터에 따라 다릅니다. 컴퓨터 제조업체는 24 시간 연중 무휴로 운영되는 과학적 환경에서 사용 된 값싼 가정용 컴퓨터의 보증 시간 내에 보증 수리를 거부했음을 알고 있습니다. 그들은 고객이 더 비싼 서버 나 "비즈니스"컴퓨터를 구매하기를 원했습니다. 그들이 성공했는지 모르겠다.

내가 소유 한 모든 Mac은 한 번에 며칠 동안 100 % CPU 사용률로 코드를 실행합니다. 하나의 경우, 나는 노트북을위한 원래 충전기가 없었기 때문에 4 개의 코어와 하이퍼 스레딩으로 인해 제공된 충전기보다 더 많은 전력을 사용했기 때문에 디스플레이를 꺼야했습니다. 그래서 배터리가 떨어졌을 때 배터리가 최대 10 %가 될 때까지 컴퓨터 속도가 5 % 느려졌습니다. (디스플레이를 끈 상태에서 며칠 동안 최고 속도로 실행했습니다). 어떤 경우에도 부작용이 없습니다.

따라서 잘 설계된 컴퓨터를 사용하면 옳습니다. 잘못 설계되고 저렴한 컴퓨터를 사용하면 동료가 옳을 수 있습니다. 반면에 대기 시간 비용과 교체 컴퓨터 구매 비용을 고려할 수 있습니다.


0

가능하면 코드를 우선 순위가 낮은 작업으로 만들고 CPU가 많은 스레드를 GUI와 별도로 유지하십시오. 그런 다음 100 % 활용률을 가질 수 있지만 사용자는 항상 다른 작업을 실행하고 응답을 유지할 수 있습니다. CPU 자체는 한동안 100 % 사용 상태를 유지하도록 설계되어 있거나 출시되지 않았습니다. 최종 사용자가 하드웨어를 심각하고 위험한 방식으로 수정하지 않는 한 아무것도 손상되지 않습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.