생각하는 법을 배우는 데 어떤 제안이 있습니까? [닫은]


22

우선,이 질문을 한 결과가 비슷한 것처럼 보일지라도 이것은 일반적인 '나를 더 나은 프로그래머로 만들자'라는 질문이 아니다. 프로그래머 .SE에서 나는 이것들이 여기 , 여기 , 여기 , 여기여기 에서 닫히는 것을 읽고 보았습니다 .

우리는 프로그래밍 기술을 연마하기위한 수많은 일반적인 제안이 있음을 알고 있습니다 (예 : SO 읽기, 권장 도서 읽기, 블로그 팔로우, 오픈 소스 프로젝트에 참여하기 등). 이것은 내가 추구하는 것이 아닙니다 .

나는 또한이 웹 사이트의 독자적인 독자성을 인정하며 훌륭한 답변을 제공함으로써 그것이 호의적으로 작용하기를 희망합니다. 여기 서신을 읽음으로써 프로그래밍 관련 분야에서 일하거나 일한 경험 많은 사람들이 있습니다. 그리고 대부분의 사람들은 웅변적이고 간결한 방식으로 생각을 전달할 수 있습니다.

나는 최근에 프로그래밍을 할 수있는 사람과 실제로 생각할 수있는 프로그래머 사이의 차이점을 발견했습니다 . 프로그래머가 잘되기 위해서는 평생 동안 스폰지와 같은 행동에 복종한다고 생각하기를 거부합니다 (예 : 독서, 청취, 시청 등을 통해 해당 분야와 관련된 모든 것을 흡수 함). 심지어 모든 단일 프로그래밍 개념을 아는 것만으로도 주변 사람들보다 문제 X를 더 빨리 해결할 수 있습니다. 생각할 수 없다면 자신을 엄청나게 제한하고 있습니다. 단순히 로봇 일뿐입니다.

나는 당신이 프로그래밍에 대해 얼마나 많이 알고 있는지와 무관 한 훌륭한 프로그래머라는 다른 얼굴이 있다고 생각하지만, 새로운 개념을 서로 연관시켜 프로그래밍 직업이나 취미에 적용 할 수있는 방법입니다. 나는 사람의 마음과 프로그래밍의이 측면을 탐구하거나 다루는 사람을 본 적이 없다. (예, 너무 열심히 보지 않았을 수도 있습니다. 그럴 경우 미안합니다.)

그래서 내가 위에서 언급 한 것에 대해 생각한 시간을 보냈거나 개인적 / 직업 개발에 조금 뒤쳐져 있기 때문에 여기에있는 모든 사람들에게- 생각하는 법을 배우는 것에 대한 제안은 무엇입니까? 평소에 읽은 내용 외에 다른 분야의 사람들보다 더 나은 일을하기 위해 무엇을 했습니까?


내가 위대하기 때문에 나처럼 생각해야합니다.
ChaosPandion

Steve Job처럼 단단한 약을 복용하십시오.
직업

함수형 프로그래밍은 생각하는 것을 가르칩니다. 다른 모든 것은 프로그램을 가르치고;)
Dario

답변:


13

생각하는 법을 배우는 것에 대한 나의 제안 :

  • 새로운 언어를 배우십시오 . 자연 언어와 프로그래밍 언어 항상 새로운 언어를 배우십시오. 생각은 언어에서 더 적게 이루어집니다. 모든 언어는 사고에 대해 다른 "관점"을 가지고 있습니다. 더 많은 언어를 알고 더 많은 "정신 도구", 개념, 관점 및 추상화를 사용할 수 있습니다.

"언어는 우리가 생각하는 방식을 형성하고 우리가 생각할 수있는 것을 결정합니다." -벤자민 리 후프

그리고 더 중요한 것은 언어가 우리가 생각할 수 없는 것을 결정합니다 .

  • 탐욕스럽게 읽습니다 . 넓게 읽으십시오. 프로그래밍뿐만 아니라 역사, 사회학, 생물학, 예술 등에 대한 관점을 넓 힙니다. 신선한 통찰력을 얻으십시오. 당신은 당신이 먹는 것만이 아니라 당신이 읽는 것이기도합니다. 새로운 아이디어는 어디에서나 창의력이 번쩍이는 것보다 두 가지 (상상적으로) 다른 아이디어를 결합하는 것에 관한 것입니다.

"기회는 준비된 마음을 좋아한다." -루이 파스퇴르

  • 겸손 . 당신이 아는 것이 거의 없다는 것을 이해하기 위해서는 많은 것을 알아야합니다. 겸손은 새로운 사고 방식을 위해 마음을 열어 놓는 데 도움이됩니다.
  • 왜 물어? 방법에 만족하지 마십시오.
  • 수학을 배우십시오 . 논리와 추상화로 작업 할 수있는 강력한 도구 인 일종의 언어입니다. 수학을 공부하면 뇌가 강화됩니다. "체육관에가는 것"과 같은 정신.

자연어에 대해서는 잘 모르겠습니다. 그것들을 배우는 것은 가치가 있지만 생각할 가치가 있습니까? 프로그래밍 컨텍스트에서? 생각하는 단어의 가치는 때때로 과장되어 표현됩니다. 우리는 단어로 쉽게 표현할 수없는 아이디어를 가질 수 있으므로 아이디어를 형성하는 단어에 전적으로 의존하지 않습니다. 또한 가장 관련성 높은 어휘 (수학 및 기타 기술 분야의 전문 용어)는 언어간에 크게 공유됩니다.
Steve314

6

내 경험으로는 두 가지로 나옵니다.

  1. 열정, 당신이 공예에 관심이 있다면 당신은 현장에서 일하는 직업을 가진 많은 프로그래머들보다 상자 밖에서 배우고 적응하고 더 빨리 생각할 것입니다. (일부는 집에 컴퓨터가 없습니다.)
  2. 어떤 사람들은 기술적 인 문제를 해결할 수있는 능력을 가지고 태어났습니다. 어떤 사람들은 자연스럽게 유연한 솔루션을 추출 할 수 있습니다.

이 외에도 모든 사람은 프로그래밍에 대해 생각하거나 새로운 프로그래밍 기술을 배우는 방식이 상당히 다릅니다. 나는 당신이 새로운 것을 계속 시도하고 당신을 위해 좋은 것을 유지하는 것이 좋습니다.


좋은 점, 특히 두 번째 점.
Orbling

5

생각하는 법을 배우는 데 어떤 제안이 있습니까?

연습. 연습. 연습.

진심으로, 정신 활동 (즉 사고)은 신체 활동과 같습니다. 많이할수록 더 잘 할 수 있습니다. (사실, 신체 활동도 정신 활동의 종류를 포함한다. 최고 스포츠맨이없는 단지 적절한 장소에 근육이 ...)

그렇다면 어떻게 당신이 (효과적으로) 사고를 연습하겠습니까?

(여기서는 다른 것으로 일반화하고 있습니다 ...)

나는 당신이 어렵다고 생각하지만 (불가능하지 않은) 사고 문제를 찾아 내고, 그것을 해결하고 (생각해보고) 더 좋아한다고 생각합니다.


나는 이것을 지원합니다. 생각할 필요가없는 반복적 인 일을 할 때마다 다른 것을 생각하고 있습니다. 또한 운전과 같이 생각해야 할 반복적 인 일을 할 때도 이런 일을하는 경향이 있지만, 생각하지 않을 때는 더 잘 운전하는 것 같습니다.
Earlz

1
@Earlz-요점을 이해하지 못합니다. 반복적 인 일을하고 있다면 그것에 대해 생각할 필요가 없습니다. 나는 생각 이 필요한 문제 해결 연습에 대해 이야기 하고 있습니다.
Stephen C

경험은 모든 것을 능가합니다 (일반적인 진술, 나는 알고 있습니다). 시간이 지남에 따라 배웁니다. 문제를 얼마나 자주 겪었습니까? 또한 당신이 문제에 접근하는 방식, 붙어있는 것에 집중하지 말고, 내가 시도하지 않은 것에 항상 집중하십시오. 가장 단순한
것에서

고의적 인 연습. 각 반복에서 무언가를 배워야합니다.

4

다음 두 가지에 관심이있을 수 있습니다.

흐름

헝가리 심리학 교수 인 Mihály Csíkszentmihályi이 흐름 의 개념을 소개했다 .

흐름은 활동에있는 사람이 활력을주는 집중 감, 활동에 관여하고 성공하는 과정에 완전히 몰입하는 정신적 운영 상태입니다.

난 내 응용 프로그램에서 배울 오래된 기술을 사용하여 흐름 일상에 입력 할 수있을만큼 운이있어 GTD 는 IS 다음 동작을 .

나는 그것이 실제로 차이를 만든다고 말할 수 있습니다. 내가 흐름에있을 때, 나는 그 상태에 있지 않을 때보 다 더 높은 품질과 더 빨리 생산합니다. 나는 내가하는 일에 전적으로 집중하고 있으므로 더 효과적으로 생각 합니다.

마음 챙김

명상이 내 프로그래밍 (및 창의적) 능력을 떨어 뜨릴 수 있다는 사실에 대해 염려했기 때문에 명상에 대해 얼마 전에 질문했습니다 .

방금 Jon Kabat-Zinn 방법 교육을 시작 했기 때문에 광범위한 경험을 공유하기에는 너무 이르지만 지금까지 배우지 못한 소수의 사람들은 이것이 아마도 당신이하고 싶은 일이라고 말할 수 있습니다.


+1 문제에 대한 상식적인 접근 방식에 관한 책과 전체 "이론"이 싫어서 GTD는 확실히 다리가 있습니다.
Orbling

1
@Orbling : 오, 나는 그것에 당신과 완전히 동의합니다. 그러나 대부분의 책 에서처럼 쓰레기와 가치가 있습니다. 쓰레기와 가치는 책을 읽는 사람에 따라 다릅니다. GTD의 문제점은 너무 강력하여 크기에 관계없이 입력을 관리하는 데 집중하는 대신 입력을 줄이는 데 시간이 걸리지 않으면 분쇄 될 수 있다는 것입니다. 그건 내 실수였다)

내가 인생에서 가지고있는 문제는 너무 많은 입력과 할 일이 너무 많아서 그러한 절차를 이행 할 시간이 없다는 것입니다. 확실히 그 가치를 볼 수 있지만.
Orbling

1
@Orbling : 그것이 핵심이라고 생각합니다. 입력 필터링은 Covey 또는 GTD를 기반으로 한 최고의 생산성 기술입니다. 정신적으로 매우 강해야합니다.

필터링하는 작업을 수행하려면 추가 인력이 필요합니다. lol.
Orbling

2

나는 항상 좋은 엔지니어가 태어나지 않고 태어 났다고 믿었 습니다.

논리적, 분석적, 연역적 사고 방식과 문제에 대한 개요 및 구조적 관점을 효율적으로 확보하고 A에서 B까지 빠르게 걸어가는 데 필요한 끈기와 호기심과 결합 된 사고 방식이 필요합니다. 해결책.

이러한 기술에 대한 초기 노출이 음악에 큰 도움이 됨으로써이 기술이 크게 향상되었다는 많은 연구가 있습니다. 특정 시점이 지나면 멘탈 맵이 매우 단단합니다. 당신이 생각 하는 것이 아니라 어떻게 생각 하는지 에 관한 것이 아닙니다 .

성인으로 생각하는 법을 배울 수 있습니까? 글쎄, 당신은 확실히 문제를 해결하는 기술을 배울 수 있지만 따라야 할 알고리즘이 있습니다. 직관적 인 이해는 아마도 타고난 것입니다.

이것은 우리의 직업에만 국한되는 것이 아니며, 많은 스킬 셋이 획득 한 응답보다는 타고난 기술에 의해 지배됩니다. 사람들은 그 사실을 원치 않을 수도 있지만 그럴 가능성이 높습니다.


2

열정적 인 것에 대한 온라인 포럼을 찾으십시오. 일종의 공동체가있는 것. 프로그래밍이 아닌 프로그래밍 포럼이 토론 중심보다 솔루션 지향적입니다. 서라. 그것을 지켜라. 인수를 사용하십시오. 당신은 또한 블로그 수 있지만, 상대를 갖는 것이 좋습니다. 요점은 누군가와 무언가에 대해 의미 있고 서면으로 의사 소통하는 것입니다. 더 큰 텍스트 조각을 교환하는 경우.

당신은 당신의 아이디어를 전달하고 그것들을 주장하는 법을 배웁니다. 당신의 견해를 변호해야하므로 사실을지지해야합니다. 당신은 무언가에 대해 생각하고, 당신의 입장을 분명히 표현하고, 지원해야합니다. 어쩌면 그것을 바꿀 수도 있습니다.

그런 다음 문제를 분석하고 의견을 종합하여 어떤 것에 적용 할 수있는 능력을 갖습니다. 심지어 프로그래밍.


그것은 생각을 연습하는 한 가지 방법입니다. 유일한 것이 아닙니다.
Domchi 2019

2

내가 생각하는 것 중 하나는 사물을 시스템으로 볼 필요가 있고 모든 시스템이 관련되어 있다는 것입니다. 우주의 모든 하나. 인류, 행성, 은하, 식물, 햇빛, 광합성, 곤충, 바위, 대양, 모든 상호 작용 시스템. 마찬가지로, 시간,주기 : 출생, 성장, 부패, 죽음, 벌레, 사람, 문명, 산맥, 별 시스템의 순환. 에너지에 대한 끝없는 투쟁. 모든 시스템.

이것은 웅장한 연구의 의미에서 생명과 자연에 관한 연구입니다. 관련된 모든 것을보고, 상호 작용하는 모든 것을보십시오. 일몰을보고 태양을 중심으로 우리를 회전시키는 중력의 힘의 깊이를 감지하고, 지구 표면으로 끌어 당기고, 초당 300,000,000 미터로 망막에 들어가기 전에 붉어지는 피하는 햇빛 영장류 뇌에서.

당신이 그것을 생각하기 시작할 때, 모든 것이 어떻게 관련되어 있는지, 일본의 태평양 및 산업 단지에서 금과 노예 노동과 폭풍의 가격이 어떻게 관련되어 있는지, 그리고 당신은 시간이 걸리고 실제로 앉아서 시간을 내야합니다. 이 모든 것에 대해 생각하면 당신의 생각 "근육"은 실제로 유연하고 성장할 것입니다.

이제, 그 중 많은 부분이 표현력의 임계 값보다 낮을 것이지만, 그렇게하지 마십시오. 당신의 두뇌는 가장 강력한 컴퓨터보다 강력합니다. 밀어. 오버 클로킹이 가능하지 않다고 생각합니다.

앨버트 아인슈타인이 바다를 바라보고있는 해변의 잔디밭 의자에 걸려있는 모습을 보여주는 흑백 사진이 생각납니다. 캡션은 "알버트 아인슈타인이 앉아 있습니다.

다음 과제는 모든 것의 복잡성과 상호 의존성을 간단한 방식으로 전달할 수 있도록하는 것입니다. 이렇게하면 아주 늙을 때까지해야 할 일이 생깁니다.


2

한 가지 접근 방식은 고의적 연습 입니다.

반복만으로 기술을 습득 할 수는 없습니다. 내성적이고, 성과를 평가하고, 일을 더 잘 수행 할 수있는 방법을 찾아야합니다.

예 : 가까운 친척이 권총 사격에서 경쟁합니다. 훈련하는 동안 모든 단계를 검토하는 데 많은 집중이 필요하며, 올바른 단계에 중점을 둡니다. 실수에 대한 재연 (리허설)이 실수를 강화하기 때문에 직관적으로 반격하여 초점이 좋지 않은 샷에 집중되지는 않습니다.

단순히 사격장에서 100 발을 발사하면 아무것도 달성되지 않습니다. 의도적으로 20 발의 사격 연습 은 좋은 습관을 강화하고 더 나은 성능으로 이어질 것입니다.

동일 프로그램에 적용 - 생각 당신이 무엇을하는지. 매월, 매주 또는 매일하지 마십시오-매 순간마다, 행동별로 행동하십시오.

  • 내 코드에서 그 결함이 발생한 이유는 무엇입니까?
  • 그 결함을 어떻게 피할 수 있었습니까?
  • 솔루션을 더 빨리 찾은 방법은 무엇입니까?
  • 내 가정 중 어느 것이 잘못 되었습니까?
  • 충분히 빨리 도움을 요청 했습니까? 너무 빨라?
  • 내가 그 실수를 한 적이 있습니까?
  • 이 결함이 고립되었거나 패턴의 일부입니까?
  • 근본적인 디자인 결함이 있습니까?
  • 그렇다면 무엇이든 할 수 있습니까?

등등 ...


요점은 다시 말하지만이 모든 것에는 시간 / 경험이 있습니다
farinspace

1
@farinspace, 각 반복 후에 평가하고 학습하는 데 시간이 걸리는 경우에만.

1

가장자리를 찾을 때까지 좋아하는 것을 찌르십시오.

깊은 숨,

물러서 ...

...

... 찾은 것을 다른 사람들에게 알려주십시오.


1

그래서 당신은 생각하고 싶어

흐름, 마음 챙김, 수학, 열정, 연습과 같은 생각하는 방법이나 생각하는 법에 대한 다른 포스터의 많은 좋은 제안 : 그래서 나는 거기에 가지 않을 것입니다.

그러나 왜 그런지에 대해서는 없습니다. 목적은 무엇입니까?

개인적으로 나는 당신이 당신이 이유를 알아야한다고 생각하기 전에 이해하게되었습니다.
가장 좋은 것은 듣고보고 보는 것입니다. (나는 둘 다 하나의 단위로 사용하므로 분리 할 수 ​​없습니다)

요구 사항 수집, 요구 사항을 세부 시스템 사양으로 변환, 설계 문서와 일치시키기, 코드 구현, 소중한 삶을위한 디버깅, 단계를 건너 뛰든, 또는 모든 단계를 건너 뛰든, 프로그래밍을 향상시키는 유일한 방법은, 해결책을 찾는 데 5 분이 걸리든 20 년이 되든 귀를 기울여야합니다.

사용자가 원하는 것을 듣고, 사용자가 무슨 말을했는지, 듣고있는 지원 담당자의 말을 듣습니다. 들리다. 이해가되지 않더라도 들어보세요. 그들이 틀렸다고 확신하더라도 들어라. 듣고 판단하지 마십시오.

수색이 아니라 눈을 뜨면서 단서를 찾으십시오. 현실을보십시오. 범죄 현장을보기 전에는 답변 검색을 시작할 수 없습니다. 결함이 입증 될 때까지 솔루션을 찾을 수 없습니다.

내 경험에서 하나의 예(버그 해결에 관한 것이지만 실제로 어떤 것에도 적용될 수 있습니다). 명백한 이유 (법적 및 기타) 나는 이것에 대해 수분이 많은 세부 사항을 유지합니다. 안전이 중요한 시스템에서 작업자는 심각한 결함을보고했습니다. 일부 지리적 추적 장치는 실제로는 생명에 영향을 미칠 수있는 추적이 없어야합니다 (이 '실제'는 실제 실수였으며 너무 오래 조사를 중단했습니다). 운 좋게도, 몇 주 후에 우연히 발견되었지만, 다른 운영자가 해당 시스템에서 추적이 손실되지 않았 음을 증명하기 위해 원격 위치에서 다른 시스템이 작동하고 있었기 때문입니다. 이것은 우리가 다시 생각하게했다. 우리의 주요 소프트웨어 공급 업체는 우리에게 1 초를 믿지 않았기 때문에 우리는 나가서 그 문제를 증명해야했습니다. 유일한 방법은 이식을 통해서였다 : 정확한 운영 상황을 재현하기위한 시뮬레이션 구축. 실제로 공급 업체가 우리를 믿기위한 증거를 비디오로 만들어야했습니다. 결국 시뮬레이션은 우리의 희망을 넘어 정보를 산출하고 전체 문제를 이해하도록 이끌었습니다. 그 후에 고치는 데 오래 걸리지 않았습니다.

우리가 끝까지 겪은 유일한 방법은 하나의 원격 시스템을 다른 작업과 논리적으로 비슷한 작업을 수행하지만 다른 작업을 수행하는 것은 논리적으로 연결하는 것입니다. 그것이 실마리를 찾고있는 것입니다. 이것은 일회성 보고서를 신뢰하고 시스템에서 임의의 결함으로 인식하지 않고 (듣기), 첫 번째 (듣기)와 모순되는 두 번째 보고서를 다시 들음으로써 가능했습니다.

따라서 올바른 단서가 있고 (듣고 보았을 때) 문제 영역을 정의하고 근본 원인 또는 주요 원칙을 이해 한 다음에는 먼저 추가 이해 (시험 및 오류, 시뮬레이션, 데모, 개념 증명, mock-up, alpha, beta version)을 제공하고 궁극적으로 견고한 솔루션을 제공합니다 (실제로 작동 한 후에도 개선 될 수 있음).

그러한 듣기와보기를하기 위해서는 열린 마음, 신뢰, 목표에 전념 해야합니다. 이것은 당신이 생각해야 할 연료, 또는 당신의 생각이 올바른 목표에 초점을 맞추기 위해 더 많이 필요합니다 (종종 문제는 생각할 수없는 것이 아니라 잘 정의 된 목표가 부족하여 마음을 움직일 수 없습니다).


답을 위해서는 +1, 문제 영역을 연구하고 사용자의 말을 듣는 것이 필수적입니다. "그렇습니다"의견에 대해서는 -1이지만 변경 사항은 없습니다.
Orbling

@Orbling : 네, 맞습니다. 약간 선외였습니다. 댓글이 삭제되었습니다. 저는 타고난 재능이 옳다고 생각하지 않지만 언급 할 필요는 없습니다.
asoundmove

글쎄-당신이 대신 -1 내 대답을했다면, 나는 당신의 것을 모두 똑같이 표시했을 것이지만, 이것을 막아서 지금 고쳤습니다. 내가 말한 것에 동의하지 않으면 잘못 언급해도 좋습니다.
Orbling

@Orbling, nah 나는 누구에게도 투표 -1을 좋아하지 않는다. 나는 단지 계속 나아가겠다. 극단적 인 시나리오 만이 -1을 보증한다. 단지 동의하지 않는 것은 아니다.
asoundmove

다른 사이트에서는 메인 사이트가 옳거나 잘못되었으므로 동의합니다. Programmers.SE는 주관적이므로 나머지는 다르므로 투표는 기본적으로 동의, 불일치입니다. 도움이된다고 생각하는지 여부 다른 사람과 강력하게 동의하지 않는 경우에만 부정적인 투표를합니다 . 글을 쓰는 시점에서, 내 투표의 2.6 %가 공감대입니다. 결국 의견에 도전해야합니다.
Orbling

1

다른 종류의 사고를 구별해야한다고 생각합니다.

창의적 사고-새로운 아이디어, 혁신적인 솔루션 및 예상치 못한 결과를 도출하는 방법. 이것 뒤에는 모든 과학이 있습니다. Edward de Bono, 창의성 기법 등을 찾으십시오. 많은 프로그래머가이 영역을 조사하지 않습니다.

분석적 사고-이것은 과학적 과정을 의미합니다. 입력, 출력을보고 중요한 것을 측정하고 논리적 결론을 내립니다. 대부분의 개발자는 과학 기술에 익숙하지만 실제로는 사용하지 않습니다. 그렇게하세요!

비판적 사고-이것이 더 철학이라고 생각합니다. 물러서서 더 큰 그림을보고, 가정을 검토하고, 당신의 가치관을 실제로 실천하고 있습니까? 철학을 연구하면 훌륭한 저술가와 아이디어가 많이 있습니다.


0

수학은 생각하는 방법을 가르칩니다. 응용 프로그램에는 창의성과 경험이 필요합니다.

나는 프로그래머를 잘하기 위해 평생 스펀지와 같은 행동에 복종한다고 생각하지 않습니다.

좋은 통찰력. 대략적으로 말하면 "위대함"에 대한 요구 사항은 "위대함"에 대한 개인적인 정의에 따라 달라지며 시간이지나면서 변했습니다. 오늘날, 프로젝트 성공은 모든 중요한 세부 사항을 파헤 치지 않고 개념을 신속하게 구성 할 수있게하는 것입니다. 개인적인 성공은 Jon Skeet과 같은 C # 마스터 링으로 정의 될 수 있습니다.

직장에서 코더를 읽으십시오 . 내가 이것에 대해 자세히 논의하는 것보다 훨씬 더 숙련 된 코더.


0

관련이없는 것처럼 보이는 영역에서 아이디어와 개념을 적용하십시오. 나에게있어 아이포드의 광채는 훌륭한 MP3 플레이어를 만드는 기술이 아니라 음악 엔터테인먼트 산업이 해적판 음악 및 음악 판매 CD / 앨범 모델과 관련된 큰 문제를 해결하는 데 도움이되었다. Jobs는 영화 산업을 다루기 위해 Pixar에서 배운 내용을 더 많이 적용했을 것입니다. 그는 실제 문제가 무엇인지 알았습니다.

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