'분류 전체보기'에 해당되는 글 1246건

ClearCase의 UCM

기술자료/개발도구 2009. 4. 3. 17:18

무슨 약자가 그리 많은지….

UCM = Unified Change Management. 범용 변화 관리. 기능을 말한다.
ClearCase를 설치 한뒤, VOB를 만들 때 마법사 창에 묻는 내용 중 하나가 project의 VOB에 대한 UCM도 생성할지 여부를 결정하는 부분이 있다. 즉 이 작업이 바로 ClearQuest와의 연동을 말하는 것 같다.

설치할 때 잘못 설치했는지 현재 ClearQuest에 대해 라이센스가 없다고 에러가 나는 바람에 정확한 테스트는 못했지만, Create as a UCM project VOB를 선택하고 설치를 진행하면 연동할 ClearQuest에 대한 정보를 묻는다. 여기에 현재 구성해서 만들어진 ClearQuest Storage에 대한 연결을 구축하면 된다.

그러나 아직 실행은 못해보았고, 지금도 Created as UCM project VOB 옵션은 끈 채로 진행하고 있다.

728x90

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

Snapshot View에 대한 추가적인 생각

기술자료/개발도구 2009. 4. 3. 16:07

아래 글은 ClearCase에 대한 소개를 적은 글이다.
사실 아래의 글을 만든 이유는 바로 ClearCase에서 제공하는 기능 중 View라는 것이 헷갈려서 쓰기 시작했다.
특히, 그 View를 만들때 Dynamic View와 Snapshot View 중 하나를 선택하게 끔 나오고 있다.
일단 지금까지 생각한 것을 정리하자면 아래와 같다.

Snapshot View는 서버의 데이터(VOB)와 똑같은 한 벌의 데이터를 각 개발자(혹은 사용자)들이 갖는 것이다. 즉 서버의 데이터의 내용을 복제해서 사용자의 개인 PC 내의 특정 폴더에 복사해 놓고, 그 안에서 작업하고 Check Out / Check In 할 때만 서버와 통신하는 방식인 것이다. 현재 Visual Source Safe에서 하는 방식이라고 보면 된다.

Dynamic View는 서버 내 특정 공간을 주고 사용자는 서버에 직접 데이터를 얹어 놓고 작업하는 것이다. 이 때 Dynamic View의 내용은 VOB를 그대로 보여주는 것은 아니다. 별도의 공간을 할당하기 때문에, 사용자가 아무리 변경해도 VOB에 바로 적용되는 것은 아니다. 최종적으로 Check In이 되어야 Mixing되어 적용되는 것이다.

아무래도 지금 필자는 Source Safe에 익숙하기 때문에, 이 ClearCase를 Snapshot의 개념으로 맞추어 이해하고 있어 Snapshot과 Dynamic의 차이를 바라보지 못한 것 같다.

일단 ClearCase는 특수한 상황이 아니면 Dynamic View의 형태로 구성하고 개발을 하는 것이 좋을 것 같다.

728x90

하인도1

What is ClearCase

기술자료/개발도구 2009. 4. 3. 15:59

IBM의 Version Control Solution 중 Rational 에서 만든 ClearCase라는 제품이 있다.
자세한 역사는 잘은 모르겠지만, 분산 환경과 복잡한 버전 관리에 있어 우수하다고 한다.

해야 할 일도 형상관리인지라, 이 ClearCase라는 것에 대한 파악이 필요하고,
마침 잘 설명되어 있는 PPT를 구해, 그 내용을 번역 하면서 정리해보도록 하겠다.
이 내용은 ftp.ccs.neu.edu/pub/people/laf/Talks-2000-nonames/ClearCase.ppt에서 원본을 다운로드 받을 수 있다.

소스 제어

소스 제어란, 간단하게 말하면, 변경사항이 발생하는 경우 새로운 버전을 매겨 등록 관리하는 것을 말한다. 그래서 변경 때 마다 버전이 매겨 지기 때문에, 어디서 무엇이 어느 시점에 추가/수정/삭제되었는지 판단되기 때문에, 문제가 발생할 때 어느 부분의 변경으로 발생되어 있는지 정확하게 추적할 수 있게 된다.

다음 그림에서 보듯 특정 사람이 특정 내용을 변경할 때, 먼저 버전 관리되는 항목 중 변경할 항목을 Check Out을 한다. 이는 무척 중요한 행위인데, Check Out을 하는 순간 그 시점의 코드는 그 사람의 소유가 되게 된다. 그리고 필요한 내용에 따라 변경한 다음 Check In을 하게 되면 버전 관리 도구는 자동으로 버전을 증가 시키고 서버에 등록하게 된다. 아래의 그림에 따르면 0번 버전의 내용을 Check Out 한 뒤 수정하고 다시 Check In을 통해 버전을 1 증가 시켜 1번 버전이 되는 것이다. 이처럼 변화를 준 뒤 Check Out-Check In을 함으로써 해당 버전 관리 내용의 버전은 증가되게 된다. 여기서 버전 관리를 하게 되는 주축, 최종 배포 버전이 되는 코드 내용이 바로 Main Line이라고 한다.

기존 버전 관리 소프트웨어 종류

사실 버전 관리 작업은 늘 필요로 했던 요청 사항이였고, 예전부터 이미 다양한 도구들이 만들어졌고 사용되고 있었다. 그 중 대표적인 것이 아래와 같다.

* ClearCase - Windows and UNIX
- 지금 부터 살펴볼 도구.
* Visual SourceSafe – Windows
- MS에서 주로 사용되는 버전 관리도구로 Visual Studio랑 가장 궁합이 잘 맞는 도구
* CVS – UNIX
- Unix 계열의 제품으로 Client는 여러 플랫폼을 지원하지만, 서버는 Unix만 제공. linux용인 제품도 많다.
* CMVision - Unix and Windows
- 모름
* Control CS - Unix and Windows
- 모름

각 도구들은 현재 버전 관리 뿐만 아니라 파일 관리까지 제공하며 Text Diffrencing에서 부터 Binary Diffrencing까지 다양한 형태로 제공된다. 이 중 살펴볼 버전 관리도구가 바로 ClearCase이다.

ClearCase
ClearCase에는 무척 다양한 기능이 탑재 되어 있다. 모든 기능을 세세히 살펴보는 것은 어렵고 대표적인 기능들을 설명하도록 하겠다.

Overview
ClearCase의 개괄적인 대표적인 장점들은 아래와 같다.

모든 종류의 파일과 디렉터리에 대한 버전 관리 기능을 제공한다.
각 버전 이력에 대한 정보를 항상 기록하며 필요하면 버전 이력에 대한 보고서를 제시한다.
매 Release 때 마다 정확한 코드 복제를 보장한다.
최신 버전 코드 복제 및 추적 기능을 제공한다.
강력한 코드 버전 분할(Branch) 및 통합(Merge) 기능을 제공한다.
모든 소프트웨어 구성요소의 통합을 보장한다.

각 장점들을 기준으로 하나씩 설명하도록 하겠다.

ClearCase의 중요 기능 요소.
버전 관리를 위한 기능을 기본적인 기능은 다음과 같다.

버전 분할(Branching)
버전 통합(Merging)
버전 라벨 처리(Labeling)

사실 각 상황이나 구성에 따라 복잡한 기능들이 많지만, 버전 관리 작업을 단순화 하면, 위의 3가지 매커니즘을 통해 버전을 관리하게 된다. 위의 기능들을 적용한 결과물을 트리형태로 표시하면 아래의 그림과 같다.

/Main 이 바로 버전 관리의 중요 지점이라고 보면 된다. 그 중 0, 1, 2, 3, … 이 버전을 의미한다. /Main을 계승하는 버전이 실제적으로 배포될 버전이며 그 버전들 중 최신 버전(그림에서는 5번이 된다.)을 컴파일 하여 제공하면 되는 것이다. 각 요소들의 파일, 디렉토리에 관계 없이 모든 요소들이 버전관리를 받게 된다. 또한 버전 관리를 받는 요소에 Check Out되는 순간 Read Only가 되어 다른 이들이 수정하지 못하게 끔 한다.

BRANCH라는 부분은 특정 버전에서 다른이가 Check-Out된 내용에 대한 수정작업을 하거나, 기능적인 테스트를 위해 임시적인 버전을 설정하여 구성할 때 사용된다. 위의 그림에서 보면 3번에서 /Rls2_bugfix라는 하위에 다시 0, 1, 2 식으로 새롭게 버전이 만들어지는데 이 처럼 /Rls2_bugfix 라는 형태로 구성되는 것을 Branch라고 한다. /Rls2_bugfix는 /Main의 3번 소스를 그대로 가져와 새롭게 변경하고 적용하는 것이다. 보통 이런 작업은 버그 수정 작업을 하거나, 검증되지 않은 새로운 기능 추가할 때 사용된다. /Main의 3번 소스를 기준으로 새로운 기능을 추가하여 자체적으로 컴파일 하고 실행해보고 이상이 없다면 /Main에 돌려주고, 문제가 있다면 폐기하는 일종의 임시 버전 같은 것이다. 이 Branch 작업은 무한대로 할 수 있으며 Branch된 버전에 새롭게 더 Branch 처리를 할 수 있다.

MERGE란, BRACH된 하위 버전을 상위 버전에 포함시키는 작업이 된다. 통합 결과 이상이 없다면 이런 단계를 통해 버전에 합쳐지게 된다. 이 작업은 하위의 작업이 상위로 올라가는 형태로 추가되게 된다. 물론 통합될 필요가 없는 경우에는 하위 버전을 그냥 버릴 수 있다.

LABELS는 각 버전에 이름을 붙이는 작업이다. 단순히 번호로 나열된 버전에 특정한 이름이나 버전을 붙여 해당 버전의 의미를 정확히 나타내는 것이다. 위의 예제에서는 Beta, Rls 1.0, Rls 2.0 …. 이런 식으로 붙여 해당 버전이 베타 버전 소스이다, 새로 Relase된 버전이다 이런 식으로 이정표를 새기는 작업을 하게 된다. Code Complete나 특정 개발 마일스톤 때 매겨지게 된다.

위의 기본 기능을 편리하게 할 수 있도록 ClearCase에서는 다음과 같은 기능들을 제공한다.

Check Out –> 편집 –> Check In 이라는 단순한 모델로 버전 관리를 한다.
특별히 충돌하는 내용이 없는 변경사항에 대해 지능적인 Merging 기능을 제공하여 자동적으로 버전 통합(Merge) 해준다.
그래픽 기반의 비교 및 통합(Merge) 도구를 제공한다.
Dynamic(동적) View, Snapshot(순간보존 형) View라는 모델을 제공해 상황에 맞는 형태로 작업할 수 있도록 제공한다.

View와 VOB

View
View란 ClearCase에서 제공하는 모델 중 하나로, 작업 공간 관리를 위한 기초 단위이다. 각각 개별적인 개발자 혹은 밀접한 작업자 그룹에서 독자적으로 작업하는 공간으로 VOB(Versioned Object Base)에서 필요한 사항들만 나타내는 부분이다. 프로젝트 전반적인 소스 코드가 있을 때, 각 개발자 혹은 독자 그룹 마다 주로 보는 파일 이나 디렉터리들이 다를 것이다. 그래서 전체 소스 코드 중 주로 보게 되는 항목들을 선택하여 볼 수 있도록 제공하는 부분이다. 그래서 프로젝트에 해당하는 파일이나 디렉터리를 모두 공유해서 사용하지만, 마치 개별적인 특정 폴더 및 파일을 보여주게 된다.

VOB(Versioned Object Base)
ClearCase에 각 요소들을 저장하는 저장장소로 모두 읽기 전용으로 제공된다. 네트워크 기반의 저장장소로써, 모든 이들의 소스를 저장하고 관리받는 기준 소스 정보들이다. 각 사용자들은 이 VOB를 공유하게 되며 수정할 때는 View에서 수정하게되며 최종적으로 변경 사항 적용될 때 View에서 VOB로 적용된다. Windows에서는 네트워크 드라이브로 UNIX에서는 Mount된 디렉터리로 제공된다.

View와 VOB의 관계
위에서는 단순히 텍스트로 나열하기만 해 조금 난해할 수 있는데, VOB와 View의 관계를 굳이 표현하면 아래와 같다.

즉 사용자의 환경에 따라 공통의 VOB 자료를 View의 설정만 다르게 해서 필요한 내용을 중심으로 표시하는 내용이다. 만일 개발자 1이 특정 소스를 변경했을 때 Check-In 하지 않는 이상 VOB에 반영되지 않기 때문에, 다른 이들은 간섭되지 않는다. 즉 최종 변경 후 Check In이 되어야 VOB에 반영되며 반영되어야 다른 이들에게도 전파가 되게 된다.

Configuration Specification
위에서 언급했을 때 사용자 별로, 버전 별로 보여주는 내용이 틀려지도록 할 수 있다고 했다. 이 때 이런식으로 보여질 수 있도록 View내에 값을 설정할 수 있는데, 그 설정을 Configuration Specification(구성 정의?)라고 한다. 이 안에 마치 SQL의 쿼리 처럼 규칙에 필요한 사항들에 해당하는 값을 넣으면 전체 VOB 내용 중 Filter되어 해당 View에 전달되게 된다. 이 값은 Create View 할 때 기본값이 설정되며 필요시 수정하여 변경할 수 있다.

기본 값은 아래와 같다.

element * CHECKEDOUT
element * \main\LATEST

위의 내용을 의미하는 바는 Check Out된 항목 들과, Main 의 LASTEST 항목들을 모두 가져오게 된다.

View의 종류
지금까지 View가 무엇인지를 언급했다면 이번에는 View의 종류를 언급하려 한다.
개발 환경에 따라 다르게 설정하여 진행하게 되는데, 여기에는 2가지 종류가 있다.

Snapshot View
Dynamic View

Snapshot View
Snapshot이라는 뜻 때로 특정 시점의 그대로의 내용을 표시하는 View이다. 즉 한번에 모든 설정과 값들을 사용자의 환경에 그대로 붑고, VOB와의 통신은 끊은 채 독자적으로 관리하는 View이다. 보통 네트워크로 ClearCase와 항상 연결되기 어려운 환경이거나, 공동작업이 거의 없는 부분에 대한 수정하는 경우 많이 사용된다.

Dynamic View
각 요소들을 투명하게 연결하여, 항상 최신 버전을 유지하고, 변경된 사용만 업데이트 하기 때문에 적은 양만 업데이트 하며, 빌드에 대한 감사등을 지원한다. 보통 네트워크 드라이브와 같이 상시 연결된 채널을 구성하게 된다.

Snapshot – Dynamic View 의 유사점

Configuration Specification 을 통해 버전 요소들을 선택할 수 있다.
Check Out – 편집 – Check In 의 기본 행위로 동작한다.
Check Out한 대상을 Reserved(예약)/(Unreserved)비 예약 상태로 설정할 수 있다.

Snapshot – Dynamic View의 차이점

Snapshot은 버전 자체가 만료될 수 있기 때문에 주기적인 서버 동기화 작업이 필요하다.
Dynamic의 경우 Check Out 하는 경우 서버와의 항상 동기화 작업을 수행하기 때문에, VOB에서 굳이 최신 버전을 일일이 받아 올 필요가 없다.

728x90

하인도1

UML의 스테레오 타입이라는게....

기술자료/개발도구 2009. 4. 2. 17:32

UML로 Use Case나 Class Diagram 조금 깔짝거리던 실력이라,

무지에 가까운 지식 속에서 끊임없이 도전해오듯 나오는 속성이

바로 스테레오 타입(Stereo Type)

모른체 지나가기엔 너무 먼 길을 걸은 느낌에 잠깐 검색하니

아래의 글을 찾았다.

http://bkangel.egloos.com/1565687

다 읽고 난 소감은....

이놈의 스테레오 타입이라는게 결국 Domain (경계?) 이나 Category (분류?)의 의미가

가깝다는 생각이다. 일단, 정확함을 떠나서 그렇게 생각하면서

UML로 된 그림들을 하나씩 하나씩 봐야 겠다.

728x90

하인도1

SPSite(사이트콜렉션)의 사이트 용량 변경 방법

기술자료/.NET 2009. 3. 12. 15:12

다음 코드를 참고하세요…

long nQuata = long.Parse("500");

// 용량은 1byte로 계산 1K는 1024, 1M는 1024*1024

nQuata = nQuata * 1024L * 1024L;

SPSite site = new SPSite("http://www.knoie.com/sites/1");

Microsoft.SharePoint.Administration.SPSiteAdministration admin = new Microsoft.SharePoint.Administration.SPSiteAdministration(site.ID);

Microsoft.SharePoint.Administration.SPQuota quota = new Microsoft.SharePoint.Administration.SPQuota();

// 저장 용량(0L은 제한없음)

quota.StorageMaximumLevel = nQuata;

// 경고 용량(0L은 제한없음)

quota.StorageWarningLevel = 0L;

// 최대 사용자 수(0은 제한 없음)

quota.InvitedUserMaximumLevel = 0;

admin.Quota = quota;

admin.Dispose();

이 코드의 핵은 SPSiteAdministration 인데 이 안에서 SPSite를 관리자 모드로 설정하여 SPSite 설정을 다양하게

해줄 수 있습니다. 이 때, 내부적으로 다음과 같은 코드로 현재 사용자가 권한이 있는지 체크합니다.

if (this.m_Site.WebApplication.Farm.CurrentUserIsAdministrator())

            this.m_Site.AdministratorOperationMode = true;

즉 위의 코드는 관리자 권한으로 실행되는 페이지 안에서만 실행됩니다.

728x90

하인도1

슬슬 스팸도 테러수준이군요.

잡글 2009. 3. 9. 12:42

냉큼 냉큼 보이는 즉시 삭제 중인데,
요즘 이 스패머가 거의 테러식으로 올리는 군요.

( 필명을 유사하게 쓰는 거 보면 분명 동일 인물인듯 싶습니다. asdf 를 차단하니깐,
미묘하게 바꾸더군요 )

블로그의 특징상, 로그인 따위는 하지 않아도 언제든 댓글을 써서 서로의 의견을 나누는 것이 중요하기
때문에, 익명으로 하긴 했는데, 이거야 원, 그 틈을 노려 스팸 댓글을 쏘다니..
일단, 이 스패머가 사용한 IP를 중심으로 차단하기는 하는데, 게임방을 넘나 들면서
올리는 것 같군요.

스패머의 처벌법좀 바꾸죠.... 최진실 법 따위를 만들기 보다, 이런 법이나 정비했으면 좋겠습니다.
스패머 자체의 처벌도 중요하지만, 스패머 보다, 그 광고 글을 발주한 광고 주를 처벌했으면 좋겠습니다.
거 그냥 시늉으로 하지 말고, 광고주에게 벌금 1500만원 이렇게 때리시죠.
스패머도 벌금 800 정도 하시고, 해외에 있다고 하면 할 수 없지만, 분명 광고주도 무슨 선이 있으니
그렇게 광고를 한 것이니, 광고주를 달달 볶아서 그 스패머 연줄을 후두둑 뽑아 버리죠 좀.

경고? 1회면 족합니다... 광고주는 1회는 봐줘도 2회 부터는 얄짤 없이 거두고, 3회 부터는 1500 의 제곱을 받는 거죠. 그러면 거 조용해질 것 같습니다.

그러나... 명박이는 IT 죽이기에 여념이 없으시니 이런 요청은 씨알도 안 먹힐 것 같네요.
삽질로 시작한 인생 삽질로 마무리 지을라고 하는데, 시대의 흐름은 봐가면서 좀 했으면 좋겠네요...
4년.....
탄핵 안하나? 하면 즉시 찍으러 갈텐데....

728x90

하인도1

미묘하게 빈정상하다.

잡글 2009. 3. 5. 23:50

사실, 나 스스로 대화 하는 스킬 분석 도중, 내 대화 내용도 들리는 사람에 따라서
은근히 빈정상하게 들릴만 하게 말하곤 한다.
은근히 삐딱선을 탄데다, 약간 줏대 없이 말하기도 하고, 지나치게 가볍게 이야기하는 버릇이 있는 것 같다.

그런데 그런 모습을 나 뿐만 아니라, 다른이들에게서 느껴지기도 한다.
내가 쓸데 없이 민감하게 생각하고 멋대로 의미를 부여하는 것 같기도 하다.
실제로 특별한 의도를 가지고 그런 식으로 표현 한 것이 아닌데, 그렇게 되버린 모습.

일 예로, 상인 스킬과 같은 대화술이 적용된 예다.
특히 물건을 팔려고 하는데, 은근히 대화 중에 그 물건의 가치가 없고, 문제 있으며,자신에게는
필요 없다는 사실을 은근히 어필한다. 그래서 가격을 하락 시킨다.
사실 이런 형태가 되는 경우 나는 보통 GG 하고 물건 팔기를 포기한다.
(모 아니면 도의 행각이기 때문에, 네고시에이션 이라는게 있을 수 없다. )

예전에도 한번 이런 비슷한 상황에 있어, 물건을 주거나 팔기보다 전부 버린 적이 있다.
버리는 순간 조금 후회하기는 했지만, 지금은 말끔하다. 도리어 그 따위 물건에 얽매여
내가 기는 것 같은 순간을 가진 것이 더 많으 후회를 가져올 수 있을 법도 하기 때문이다.

난 최소한 나와 시점을 같이 하는 사람에게는 No Take, All Give에 가까운 지원을 한다.
그런데, 상대가 나의 마음은 무신한재, 상인들 처럼
그 안에서 골라내고 가격 협상을 하려는 모습은 나의 마음을 무척 아프게 한다.

내가 그들에게 팔아서 이익볼 바에는 그냥 다른데서 일해서 돈벌고, 팔려는 물건 다 버린다.
그게 내 생활 방식이다.

- 물론 나와 최소한 시점을 같이하는 사람이나 그런 혜택이 있지, 그렇지 않으면 일절 없다.
Give & Take 뿐이다.

728x90

하인도1

내 나름대로의 생각해 본 세대별 사고 방식.

잡글 2009. 3. 2. 16:12

내가 가지고 있는 인맥 네트워크가 무척 넓은 편은 아니기 때문에, 사실 정확도가 있지는 않다.
(즉 논문이나 특정 갤럽의 분석 보다 신뢰도는 낮다.)
오로지 내 눈으로 보고, 피부로 느낀 그대로를 내 생각대로 말하는 것이다.

현재 내가 70년대 생(76년)이기 때문에 먼 과거의 분들 (40, 50년대 생) 나 아직 고등학생들인 어린 친구들(90년대 생 이후)까지는 명확히 알 수 없다. 가끔 후배의 동생이나 후배의 후배를 통해 보긴 하지만, 솔직히 그 친구들과 자세한 이야기를 나눌수 없는게 사실이기에 정확도는 당연히 떨어진다. 게다가 어르신들은 세상의 변화가 단 20년 동안 순식간에 바뀌어 완전히 18세기사람과 20세기 사람 차이처럼 그 골이 조금 깊다.(전후 세대 분들이다 보니, 생각 자체의 시점이 틀리다.)

그래서 내 앞세대 뒷세대인 60년대 생과 80년대 생을 기준으로 말하고 싶다.

1. 버르장머리.
예절(禮節)에 대한 문제라고 볼 수 있다.
점점 시간이 흐르면서 이 예절적인 문제는 많이 대두 되었다. 사실 60년대 생 분들이 70년대 생을 바라 보는 눈이 그렇게 곱지만은 않다. 무언가 탐탁잖은 그런 모습. 분명 무언가 챙겨주는 것 같은데, 약간 버르장 머리 없는 모습. 과거 자신은 전후 세대들에게 깍득히 선/후배의 모습을 갖추었고, 상사가 이러라 하면 이러고 저러라 하면 저랬는데, 70년대생들은 무언가 삐닥허니 잘 안한다. 그렇다고 완전히 안하는 건 아니고 미묘하게 안한다는 것이다. 이제 70년대 생을 바라보자. 70년대 생이 바라보는 80년대 생은 60년대 생이 70년대 생을 바라보는 것과 별반 차이 없다. 최소한 지킬 선은 지켜줬으면 하지만, 80년대 생이 다 그렇지는 않지만 대개 이 선을 뭉개는 경우가 많다. 물론 첫대면은 깍듯하다. 사실 이 깍듯함은 경계의 의미가 강한 것일 뿐이고, 60년대생 대부분, 70년대생 일부분이 갖춘 선/후배 챙기기의 모습이 아니다. 서서히 이 경계점이 무너지기 시작하면, 어느새 서서히 말이 짧아 지며, 인사도 대충한다. 양키 식으로 손을 드는 친구도 있다.

60년대 생이 70년대 생을 바라보며 참 버리장 머리 없네...라는 말 그대로 70년대 생이 80년대 생을 바라보며 참 버르장 머리 없네... 라고 말하는 것과 별반 차이 없다. 세상이 변해 가면서 그 허용 경계가 점점 낮아지면서 바로 윗세대는 바로 아랫 세대에게 한소리를 하는 것과 별반 차이 없는 것 같다.

2. 일에 대한 자세.
일을 어떻게 생각하는지 한번 나름대로 나누어 생각해보았다.
먼저 60년대 생들.
대부분 60년대 생들은 일 = 삶 이였다. 사실 전(戰)후 세대 분들은 일 = 생존 이였다. 그에 반해 업그레이드 된 모습이지 않을까 생각된다. 하지만, 60년대 생 분들 중에 인텔리는 그리 많지 않은 것으로 알고 있다. 당장 먹고 살기 힘들기에 학교를 다니기 보다 돈을 벌 수 있는 일자리를 찾기가 바쁘셨기에 어쩔 수 없는 선택이였으리라 상상한다.
그러기에 그 분들은 생존이면서도 인생을 살아가는 터전과 같은게 바로 일이라 할 수 있을 것이다.
이에 반해 70년대 생들은 어느정도 경제적인 안정을 갖추고 일 = 삶이라고 살아오신 분들과는 다른 생각을 갖게 된 것 같다. 즉 즐기며 일을 한다는 것이 어떻게 보면 최고의 일자리라는 생각을 대부분 갖고 있었던 것 같다. (최소한 제 주변에는 이런 분들 많죠 ) 대기업에 들어가거나 공무원이 되거나 라기 보다는 자신이 좋아하는 일을 선택하여 그 일에 최선을 다하는 모습. 이것이 미덕이라고 생각하는 것 같다. 그러기에 더욱더 자신이 하는 일에 대한 후회를 하는 경우도 많다. ( 임금, 근로환경 등등 ) 그래도 대부분은 자신이 택한 길이라는 생각, 이나 최소한 제대로 일은 해야지 욕은 안먹는다는 생각? 등등 여러가지 원인들로 책임감을 가지고 자신의 일을 수행한다. 물론 말로는 일이라 함은 적당히 하고 가정생활을 중시해야 한다고는 늘 말한다. (마치 운동해야 되는데..... 와 비슷하게, 은근히 야근들을 하고 잔업들을 하곤 한다..)
이에 반해 80년대 생은 일과 삶은 명백하게 분리되어 있다. 즉 70년대 생이 말로만 하는 일과 생활의 분리는 몸소 실천하는 모습이다. 즉 정해진 일을 똑부러지게 한 뒤, 그 일에 대한 수당으로 잘 사는 것이 최고의 미덕이라고 생각한다. 절대 일을 야근을 통해서 해결하거나, 잔업으로 하는 것을 최악의 상황으로 생각한다. 그래서 면접을 하다 보면 80년대 생은 근로 환경이나 임금에 대해서 많이 묻는다. 열악이라고 판단되면, 그 일이 어떤일이든 일단 회피하고 본다. ( 물론 떡밥이 좋으면 - 20세기 말에서 21세기 초에 유행한 스톡옵션 등등 - 잘 물리긴 한다. )

그래서 잔업이나 야근 횟수등을 보면 60년대 생 > 70년대 생 > 80년대 생 순으로 보이곤 한다.
( 만나자 할때 만나기 힘든 순서이기도 하다. )

3. 지식을 향한 모습
아마도 삶이자 생존이라고 생각을 해오던 60년대 생에게는 지식이란 훌륭한 무기이며 동경 그 자체라고 생각된다. 환경이 열악하니 공부를 하고 싶어도 하기 힘들기 때문에, 더욱더 그 생각에 불타 올라 심지어 자신의 자식만이라도 공부 열심히 할 수 있는 환경을 만들기 위해 희생 그 자체를 보여주었다. 엄청난 학구열이라 생각된다.
그에 반해 70년대 생은 지나친 경쟁 속에서 지식에 대한 열망이 한풀 꺾인 모습이다. 너무 많은 지식들을 쏟아 붇고 그를 테스트 하기 위한 시험들을 보다 보니, 지식은 지식이고 삶은 삶이지.. 라는 생각을 갖는 경우가 많다. 학부모 경쟁열이 붙은 경우에는 자식에 대한 학구열 불태우기에 여념없긴 하지만, 대개는 학습에 대한 방만 주의가 조금씩 흐른다. 너무 지나치게 키우고 싶지 않다는 생각이 팽배하다 ( 하지만 자신의 자식에 대한 애정이 학구열로 불타는 경우가 많다 ). 80년대 생은 아예 지식은 도구 및 발판에 불과하다고 생각한다. 즉 특정 조건을 갖추기 위한 자격 요건 이나 돈 벌기 위한 단순한 수단에 불과하다고 생각한다. 그래서 사실 지식 자체에 대하여 열망은 없다. 단지 일하는데 지장이 있는 경우 일시적인 열혈모드로 들어가곤 하지만 아주 일시적인 현상이다. 게다가 자신과 전혀 관계 없거나, 조금이라도 지루하다고 판단 되면 가차없다. 그냥 졸아 버린다. 상대방에 대한 예의나 배려는 없이 자기 중심적으로 생각하는 경우가 많다. 아마도 정보 홍수속에서 살아 남는 방법을 몸소 체득하여 본능적으로 나오는 현상이라 생각된다. ( 최소한 70년대 생까지는 정보란 하나라도 쥐어야 살아남는 다는 생각이 강했다 )

4. 세대별 차이를 통한 내 나름 대로의 결론.
사실 세대별 차이는 시대 트랜드에 의해 변화되는 것을 막을 수 없다. 게다가, 자신이 무리에서 왕따, 혹은 아웃 사이드가 아니라면 이 변화에 꼭 휩쓸리게 된다. 그래서 80년대 생인데, 야근을 하는 경우 주위 친구들이 그 사람을 동정하거나 바보, 병신 취급한다. 그러기에 더더욱 세대 차이를 명확하게 보여준다.
그런데 만족스러운 삶은 사는 사람들의 형태는 무리에 대해 크게 개이치 않고 My way를 밟으며 나아가는 사람들이라는 점이다. 그리고 전 세대의 모습과 현재 자신의 또래의 트랜드의 줄타기를 잘하는 것이라 할 수 있다.(최소한 2세대 이상을 뛰어넘게 되면, 완전 막나가는 사람이 되거나, 고지식한 사람으로 치부되기 싶다.)

PS.
마지막으로 지금 80년대생 분들에게 두가지 말씀을 전해 드리고 싶군요.

이 글에 대해서 전혀 동의할 수 없으며, 그에 대한 반박문을 A4 100페이지라도 쓸 수 있습니다.... 라고 말씀하실 분들도 있겠지만 이 글은 오로지 저의 지인들과 제 나름대로의 인맥 네트워크를 통해 이러저런 이야기를 한 결론입니다. 게다가, 제가 아는 60년대생, 70년대 생, 80년 대 생 분들 중 저 세대별 차이를 뛰어넘는 분들도 여럿 알고 있습니다. 하지만, 그런 다양한 예외들을 모두 품고 설명하기에는 복잡하기 때문에, 어느정도 걷어내고 말씀을 드린거죠. 하지만, 세대 트랜드는 저 모습이라고 생각됩니다. 지금의 모습을 잠시 기억에만 담으시고, 한번 딱 10년 후에, 당신이 관리직에 올라 90년대생 00년대생 분들과 함께 일을 해보시기 바랍니다.아마 저와는 다른 트랜드의 모습을 90년대생 00년생 분들을 통해 자신의 모습을 바라볼 수 있을 것입니다.
(물론 그전에 이 글에 대해서는 완전히 잊혀지겠지만요.)

그리고, 옛날 말 중에 이런 말이 있습니다.

知之者不如好之者好之者不如樂之者
아는 자는 좋아하는 자보다 못하고, 좋아하는 자는 즐기는 자보다 못하다.

당신이 학습을 하는 중이든, 일을 하는 중이든,
그저 열심히 하기 보다, 그저 좋아하기 보다, 그를 즐기는 마음을 갖고 임해주시면 좋겠습니다.
분명 즐기는 자와 함께 일을 하면 같이 즐겁게 모든 것을 할 수 있다고 생각됩니다.
(분명 그냥 하는 사람보다, 좋아하는 사람보다 즐기는 사람이 심리적으로 안정되고 여유가 있기도 합니다.)
어느새 즐겁게 모든 것을 하고 있는 자신을 볼 수 있을 것 같습니다.
( 전 아직도 "좋아하는" 레렐인 것 같군요 )

728x90

하인도1

250x250

블로그 내에 소스 코드 삽입 이사온 기념 스킨도... RSS 전문 기능 비활성화 관련. 스킨 바꾸어 보았습니다. 서버 파일 정리 좀 했습니다.

« 2025/06 »
일	월	화	수	목	금	토
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30

인터파크 MOSS 2007 수 비스킷 좀 블로그 지름신 SharePoint me2photo Visual Studio 매뉴얼 불만 me2dayzm twi2me Tutorial Azure 협업 2010 e-book 것 개발환경 친구 Buscuit Google Apps Engine me2sms WSS java windows 오류 moss

Total :
Today :
Yesterday :

'분류 전체보기'에 해당되는 글 1246건

검색

공지

보관함

달력

링크

태그 목록

최근 포스트

최근 댓글

카운터

티스토리툴바