정반합(正反合, 독일어: These, Antithese, Synthese)은 철학용어로 논리의 전개 방식의 하나이다. 헤겔의 변증법을 도식화한 것으로, 헤겔 본인에 의해서는 사용된 적이 없으나 이후에 그의 논리학을 해설하며 붙여진 용어이다.
기본적인 구도는 정(테제)가 그것과 반대되는 반(안티테제)와의 갈등을 통해 정과 반이 모두 배재되고 합(진테제)로 초월한다는 것이다. 카를 마르크스는 여기에서 정과 반의 갈등에 초점을 두어 변증법적유물론과 사적유물론의 이론적 배경으로 하였다.
-----------------------------------------------------------------------------------------------------
- ▲ 독일 철학자 '헤겔'.
변증법으로 대표되는 헤겔의 역사관은 후자에 가깝다. 합(合)이 언제나 이전의 합(合)과는 다른, 보다 발전적이고 성숙한 모습을 갖는다고 해석했다는 점에서 그러하다. 하지만 그의 역사관을 올바르게 이해하기 위해서는 그러한 합(合)이 어떠한 시간적 흐름 속에서 자리매김하고 있는가를 살펴야 한다.
변증법의 3요소는 흔히 '정(正), 반(反), 합(合)'이라 일컬어진다. 헤겔은 역사를 정(正)에서 반(反)의 등장으로, 다시 정(正)과 반(反)에서 나타난 합(合)의 이행으로 설명한다. 물론 이 '합'은 다시 '정'이 되고, 이에 대한 '반'의 등장하며 또 다른 '합'으로의 이행이 진행된다. 그리곤 이 과정이 무한 반복된다. 이처럼 변증법은 정반합이라는 단순 요소들의 병렬적 나열이 아니라, 시간 속에서 변화하는 세계의 모습을 법칙적으로 해석한 것이다.
단순한 반복처럼 보이지만, 사실 변증법적 순환은 나아가 진보, 혹은 발전의 의미를 함축하고 있다. 헤겔은 단순한 시간의 연쇄를 발전적인 것으로 파악하는데, 이는 정과 반, 그리고 합의 관계를 통해 이해할 수 있다. 흔히 '정'은 어떤 사태의 현 상태를 지칭한다. 그리고 '반'은 그러한 현 상태에 대한 자기부정쯤으로 이해할 수 있다. 그리고 어느덧 현 상태와 자기부정의 끝없는 갈등을 극복하고, 또 다른 안정적 상태 즉 '합'이 도래한다.
풀어서 이야기하면 합은 앞선 정과 반의 치열한 갈등 속에서 등장하는 일종의 '해결책'인 셈이다. 따라서 합은 당연히 앞선 정보다 더 나은 결과적 상태이다. 물론 이렇게 나타난 현 상태(합)가 완전무결하다면 여기서 역사는 종결되겠으나, 그렇지 않다면 더 나은 합을 향해 또 다른 '반'과의 갈등이 불가피하다는 것이 헤겔의 생각이다.
헤겔의 역사관에서 갈등은 발전을 위해 매우 중요한 가치를 지닌다. 갈등이야말로 발전을 가능하게 하는 핵심요소다. 갈등이 없다면, 그러한 갈등을 극복하기 위한 노력 또한 필요 없기 때문이다.
갈등을 이처럼 긍정적인 것으로 파악하는 한, 현 상태를 긍정하는 '정'도, 그리고 이를 부정하는 '반'도 필연적으로 존재해야 한다. 싸움도 어느 정도 상대방의 존재를 인정할 때라야 비로소 가능하기 때문이다. 그것이 한 개인의 내적인 싸움이건, 혹은 사회적 정당이나 이익단체들끼리의 다툼이건 상대의 존재를 인정하는 것이 발전적 '합'을 위한 첫 걸음이다.
과거의 모습에 대해서도 유사한 해석이 가능하다. 어제를 잊고 싶다거나 잃어버렸다고 평가하는 것은 보다 나은 내일을 위해 아무런 도움도 되지 않는다. 그저 내일을 향해 달리라고만 한다면 그야말로 욕심을 채우기 위해 달리는 폭주기관차와 다를 바가 없다. 어제보다 나은 내일을 위하는 꿈꾸는 사람이라면 비록 입에 쓴 모습이라도 과거의 모습 또한 나, 혹은 사회를 구성하는 한 축이라는 점을 먼저 인정해야 한다.
그러한 인정이 있을 때라야 비로소 자신이 긍정하는 어제의 모습 속에서 문제점이 무엇인지 찾아낼 수 있다.
다시 3월이다. 많은 학생들이 새로운 학급, 학교에서 2010년 이맘때쯤 만나고 싶은 자신의 모습을 위해 휘황찬란한 계획을 세우곤 한다. 매년 똑같은 계획을 세우지만 매번 실패로 끝나는 사람들에게 당부하건데 어제까지의 일들은 모두 잊겠다는 말은 이제 그만 했으면 한다.
보다 나은 자신을 만들기 위해서라도 끊임없는 내적 투쟁은 필수적이다. 그런 사람들이 제일 먼저 해야 하는 것은 당연히 자신이 다퉈야 하는 상대가 무엇인지 깨우치는 것이다. 어제까지 누렸던 자신의 모습을 송두리째 부인하기만 해서는 자신이 도달해야 하는 발전적 합(合), 즉 내일의 모습은 그저 꿈일 수밖에 없을 터이다.
http://www.lux99.co.kr/
홍콩명품 싸고 종류 많은곳
홍콩명품 싸고 종류 많은곳
스테레오타입(Stereotype) 개념
UML을 처음 접하면서 가장 명쾌하게 이해되지 않는 개념 중 하나가 바로 스테레오타입(stereotype)일 것이다. 사전을 찾아보면 "연판, 관례, 고정 관념, 상투적인 문구, ..." 등의 의미로 나오지만 이미 의미를 알고 있다면 그런 용어가 알쏭 달쏭할 수는 있지만 그것으로부터 의미를 이해하기에는 불가능해 보인다. UML 명세에 나와있는 설명은 더 어렵다. 모델링 타임에 정의된 새로운 메타클래스(metaclass)라는 등, 사용상의 구별(usage distinction)이라는 등 역시 이미 UML 하부구조를 알고 있어야 하는 설명들이다.
스테레오타입은 그 정의로써 이해하기에는 다소 마음에 와 닿지 않을 것이므로 먼저 예를 들어보자. 윈도우 기반의 UI를 가지고 있으면서 DB를 다루는 간단한 프로그램을 모델링 한다고 가정하자. 이 때 주로 UML의 클래스(Class)를 사용해서 모델링을 하게 될 것이다. 속성(Attribute)과 연산(Operation)도 넣고 서로 간의 연관(Association) 및 일반화(Generalization)도 사용해서 말이다. 이렇게 모델링을 하고 나면 새로운 욕구가 발생하게 될 것이다. GUI를 구성하는 부분과 DB를 구성하는 테이블, 그리고 기타 프로그램 내부의 순수 로직 부분 모두 다 그냥 단지 클래스(Class)로만 표현되고 있을 뿐이다. 이것들을 그저 GUI, Business Logic, Database로 구분해두고 싶어질 것이다. 이런데 이러 경우는 비단 이러한 예 뿐만 아니라 너무도 많이 발생한다. 즉, 각각의 요소들을 모델러(modeler)의 기준에서 별도의 분류를 두고 싶을 때 스테레오타입(stereotype)을 사용하게 된다.
스테레오타입이 왜 필요한가?
UML은 매우 범용적이고 일반적인 모델링 언어이다. 따라서, 어떠한 개념이라도 무리 없이 모델링이 가능하지만 반면에 어떠한 개념도 정확하고 명확하게 나타내기는 힘들다. 우리 인간이 사용하는 자연어(한국어, 영어, 일본어)등도 결국 일상 용어 외에 특정 학문 분야에서 사용될 때에는 부족함이 많기 때문에 새로운 용어가 탄생하고 기존의 단어에 새로운 의미가 부여되게 되는 것이다. 일상 용어의 "Thread"와 컴퓨팅 분야의 "Thread"는 단어는 같으나 이해되는 의미는 다르다. UML도 마찬가지로 그러한 태생적인 한계가 있으며 이를 극복하기 위한 방안이 모색되었는데 그것이 바로 UML의 확장 메커니즘(extension mechanism)인 것이다.
스테레오타입의 사용
스테레오타입(stereotype)은 바로 UML 확장 메커니즘의 한 부분으로써 매우 중요한 역할을 수행하게 된다. 다시 한번 정리하면 "스테레오타입은 UML 모델링 요소들을 모델러의 기준에 따라 새로운 분류를 적용할 수 있도록 허용하는 메커니즘"이다. 따라서, 스테레오타입은 모델러 마음대로 정의해서 적용하면 되는 것이고 특별한 제약이나 규칙은 없다. 그리고 스테레오타입은 각 요소에 "<<" ">>" 사이에 이름을 부여하면 된다. 정확하게는 "<<", ">>"는 꺽쇠 괄호(angle-braket) 두개가 아니라 guillemets라 불리는 하나의 문자('«', '»')이다. 그러나, 통상적으로 이러한 문자를 사용하기가 불편하기 때문에 꺽쇠 괄호 두 개를 써도 무방하다.
스테레오타입은 위의 예에서 처럼 <<GUI>>, <<table>>과 같이 사용해도 되고, 특정한 플랫폼이나 프로그래밍 언어를 나타내기 위해 <<JavaClass>>, <<CORBAInterface>> 처럼 사용해도 된다. 아니면 특정 분야에서 사용되는 용어나 개념으로 표현하는 것도 좋은 예가 될 수 있다. 그러나 가급적 특정 기준을 두고 분류의 용도로 사용하는 것이 바람직하며 무조건적으로 부가적인 데이터들만 기입하는 방식은 좋은 사용의 예가 아닐 것이다. 예를 들어 클래스를 작성한 사람의 이름 <<minho>>, <<younghee>> 혹은 구현될 파일의 이름 <<DBAccess.java>>과 같이 사용하는 것은 그다지 좋은 방법은 아닐 것이다.
스테레오타입과 아이콘(Icon)
스테레오타입은 하나의 아이콘으로 표현될 수도 있다. 예를 들어 <<JavaBean>> 클래스를 콩 모양의 아이콘으로 나타내준다면 훨씬 보기에도 좋고 구별하기도 쉬울 것이다. UML은 이러한 확장이 가능하도록 허용하고 있다. 그리고 현대의 여러 툴들에서는 이를 지원하고 있기도 하다. <<table>>은 표 모양의 아이콘을, <<Database>>는 원통 모양의 아이콘을 사용할 수도 있는 것이다.
이렇게 아이콘을 사용할 수 있게 되다 보니 스테레오타입을 표현하는 방식에 몇 가지 선택사항이 생기게 되었다. 간단하게 생각해보더라도 <<JavaBean>>과 같이 텍스트 형식으로 나타내느냐 아니면 아이콘 형식으로 나타내느냐 혹은 둘 다를 나타내느냐 하는 선택을 할 수 있다. UML에서는 총 4가지의 옵션이 존재한다.
UML을 처음 접하면서 가장 명쾌하게 이해되지 않는 개념 중 하나가 바로 스테레오타입(stereotype)일 것이다. 사전을 찾아보면 "연판, 관례, 고정 관념, 상투적인 문구, ..." 등의 의미로 나오지만 이미 의미를 알고 있다면 그런 용어가 알쏭 달쏭할 수는 있지만 그것으로부터 의미를 이해하기에는 불가능해 보인다. UML 명세에 나와있는 설명은 더 어렵다. 모델링 타임에 정의된 새로운 메타클래스(metaclass)라는 등, 사용상의 구별(usage distinction)이라는 등 역시 이미 UML 하부구조를 알고 있어야 하는 설명들이다.
스테레오타입은 그 정의로써 이해하기에는 다소 마음에 와 닿지 않을 것이므로 먼저 예를 들어보자. 윈도우 기반의 UI를 가지고 있으면서 DB를 다루는 간단한 프로그램을 모델링 한다고 가정하자. 이 때 주로 UML의 클래스(Class)를 사용해서 모델링을 하게 될 것이다. 속성(Attribute)과 연산(Operation)도 넣고 서로 간의 연관(Association) 및 일반화(Generalization)도 사용해서 말이다. 이렇게 모델링을 하고 나면 새로운 욕구가 발생하게 될 것이다. GUI를 구성하는 부분과 DB를 구성하는 테이블, 그리고 기타 프로그램 내부의 순수 로직 부분 모두 다 그냥 단지 클래스(Class)로만 표현되고 있을 뿐이다. 이것들을 그저 GUI, Business Logic, Database로 구분해두고 싶어질 것이다. 이런데 이러 경우는 비단 이러한 예 뿐만 아니라 너무도 많이 발생한다. 즉, 각각의 요소들을 모델러(modeler)의 기준에서 별도의 분류를 두고 싶을 때 스테레오타입(stereotype)을 사용하게 된다.
스테레오타입이 왜 필요한가?
UML은 매우 범용적이고 일반적인 모델링 언어이다. 따라서, 어떠한 개념이라도 무리 없이 모델링이 가능하지만 반면에 어떠한 개념도 정확하고 명확하게 나타내기는 힘들다. 우리 인간이 사용하는 자연어(한국어, 영어, 일본어)등도 결국 일상 용어 외에 특정 학문 분야에서 사용될 때에는 부족함이 많기 때문에 새로운 용어가 탄생하고 기존의 단어에 새로운 의미가 부여되게 되는 것이다. 일상 용어의 "Thread"와 컴퓨팅 분야의 "Thread"는 단어는 같으나 이해되는 의미는 다르다. UML도 마찬가지로 그러한 태생적인 한계가 있으며 이를 극복하기 위한 방안이 모색되었는데 그것이 바로 UML의 확장 메커니즘(extension mechanism)인 것이다.
스테레오타입의 사용
스테레오타입(stereotype)은 바로 UML 확장 메커니즘의 한 부분으로써 매우 중요한 역할을 수행하게 된다. 다시 한번 정리하면 "스테레오타입은 UML 모델링 요소들을 모델러의 기준에 따라 새로운 분류를 적용할 수 있도록 허용하는 메커니즘"이다. 따라서, 스테레오타입은 모델러 마음대로 정의해서 적용하면 되는 것이고 특별한 제약이나 규칙은 없다. 그리고 스테레오타입은 각 요소에 "<<" ">>" 사이에 이름을 부여하면 된다. 정확하게는 "<<", ">>"는 꺽쇠 괄호(angle-braket) 두개가 아니라 guillemets라 불리는 하나의 문자('«', '»')이다. 그러나, 통상적으로 이러한 문자를 사용하기가 불편하기 때문에 꺽쇠 괄호 두 개를 써도 무방하다.
스테레오타입은 위의 예에서 처럼 <<GUI>>, <<table>>과 같이 사용해도 되고, 특정한 플랫폼이나 프로그래밍 언어를 나타내기 위해 <<JavaClass>>, <<CORBAInterface>> 처럼 사용해도 된다. 아니면 특정 분야에서 사용되는 용어나 개념으로 표현하는 것도 좋은 예가 될 수 있다. 그러나 가급적 특정 기준을 두고 분류의 용도로 사용하는 것이 바람직하며 무조건적으로 부가적인 데이터들만 기입하는 방식은 좋은 사용의 예가 아닐 것이다. 예를 들어 클래스를 작성한 사람의 이름 <<minho>>, <<younghee>> 혹은 구현될 파일의 이름 <<DBAccess.java>>과 같이 사용하는 것은 그다지 좋은 방법은 아닐 것이다.
스테레오타입과 아이콘(Icon)
스테레오타입은 하나의 아이콘으로 표현될 수도 있다. 예를 들어 <<JavaBean>> 클래스를 콩 모양의 아이콘으로 나타내준다면 훨씬 보기에도 좋고 구별하기도 쉬울 것이다. UML은 이러한 확장이 가능하도록 허용하고 있다. 그리고 현대의 여러 툴들에서는 이를 지원하고 있기도 하다. <<table>>은 표 모양의 아이콘을, <<Database>>는 원통 모양의 아이콘을 사용할 수도 있는 것이다.
이렇게 아이콘을 사용할 수 있게 되다 보니 스테레오타입을 표현하는 방식에 몇 가지 선택사항이 생기게 되었다. 간단하게 생각해보더라도 <<JavaBean>>과 같이 텍스트 형식으로 나타내느냐 아니면 아이콘 형식으로 나타내느냐 혹은 둘 다를 나타내느냐 하는 선택을 할 수 있다. UML에서는 총 4가지의 옵션이 존재한다.
- None : 스테레오타입을 나타내기 않음
- Textual : 스테레오타입을 <<JavaBean>>과 같이 텍스트로 나타냄
- Iconic : 콩 그림의 아이콘과 같이 아이콘으로 나타냄
- Decoration : <<JavaBean>>과 콩 그림의 아이콘을 동시에 나타냄.
Prev
Rss Feed