'IT News' 카테고리의 다른 글

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

  1. 2010.11.05 조용한 혁신, Enterprise 2.0과 기업 소셜 네트워크 사례
  2. 2010.11.05 12인이 말하는 ‘아키텍트의 길’
  3. 2010.10.11 정보 습득에 여과 Filter를 달자
  4. 2010.10.07 커피 파는 젊은 의사가 있는 제너럴닥터병원 1
  5. 2010.10.05 성공이란 무엇인가?
  6. 2010.10.01 신념이란
  7. 2010.09.29 [ORA-28002] 사용자 계정의 암호가 만기될 것입니다.
  8. 2010.09.22 TEXT INDEX의 META DATA를 CTXSYS USER에서 삭제하는 방법
  9. 2010.09.20 UGA MEMORY LEAK 에러인 ORA-600[729] ERROR에 대한 이해
  10. 2010.09.16 인증되지 않은 TOOLS 의 ACCESS 제한하기 1

조용한 혁신, Enterprise 2.0과 기업 소셜 네트워크 사례

IT News 2010. 11. 5. 12:48
조용한 혁신, Enterprise 2.0과 기업 소셜 네트워크 사례



4.jpg
*이미지 출처 : 플리커 (
http://www.flickr.com/photos/webtreatsetc/4091128553)


■ Enterprise 2.0과 기업 소셜 네트워크


웹 2.0의 참여, 공유, 개방의 정신을 가장 잘 반영하는 SNS의 거대한 물결이 개인에서 기업으로 이동하고 있다. 이런 거대한 물결의 파도를 Enterprise 2.0이라는 상징적인 단어로 설명할 수 있다. Enterprise 2.0은 앤드류 맥아피 교수가 지난 2006년 봄 MIT의 슬론 매니지먼트 리뷰를 통해 '웹2.0의 기술과 참여, 공유, 개방의 사상을 기업적인 측면에서 활용하자'며 제한한 개념이다. 또 위키피디아는 Enterprise 2.0은 '웹기술 기반의 서비스로 확장된 기업 내부에서 애자일적 협업과 정보공유, 그리고 능력의 통합을 하는 기술'이라고 정의한다.

5.jpg

기업(Enterprise)과 웹 2.0의 결합은 바라보는 관점에 따라서 물과 기름처럼 섞일 수 없는 부조리처럼 느껴지기도 한다. 기업은 최대한 폐쇠적인 구조(Close)를 지녀야 하고 SNS의 가장 기본적 가치는 개방성(open)이다. 그래서 Enterprise 2.0 가장 기본 개념은 기업 내부 방화벽 속 사내 SNS를 일컫는 경우가 많다. 하지만 실제 사내 SNS의 도입에 부정적인 목소리가 분명 존재하는 것이 사실이다. 기업 내에서는 이미 자신들만의 커뮤니케이션 툴이 잘 갖춰져 있다. 유/무선 전화, E-메일, 메신저, 파일공유 프로그램 뿐만아니라 대기업을 중심으로 ERP, BPM 등의 관리 시스템까지 갖춰져 있는데 굳이 사내 SNS를 도입해야 하는가에 대한 질문이 있는 것이 사실이다. 사내 SNS 솔루션 사례를 통해 기업 소셜 네트워크 현황에 대해 알아보기로 하자.

■ 기업용 소셜 네트워크 솔루션

기업용 소셜 네트워크 솔루션은 2006년 이후 본격적으로 등장하기 시작했다. 기존의 Wiki나 Croud Sourcing 솔루션들이 SNS와 결합하여 2009년 본격적으로 기업용 소셜 네트워크 솔루션이 개발되기 시작하였다. 대표적인 솔루션 Yammer, Chatter, Social Quik에 대해 살펴보자.

1) Yammer
사내 SNS 솔루션의 대표주자로 전 세계 약 90,000개 업체가 사용하는 대표적인 SNS 솔루션이다. 마이크로블로그라는 신조어를 만들어 열풍을 일으키고 있는 트위터와 Myspace를 뛰어넘은 페이스북의 인터페이스가 절묘하게 결합되어 있는 형태로 기업 소셜 네트워크 솔루션의 가장 표준화된 모델로 인정받고 있다. 국내에도 LG전자, KT, KB투자증권 등의 기업이 Yammer를 도입하여 사용 중이다. 야머는 기업 이메일 계정을 베이스로 가입을 받기 때문에 가입이 비교적 간편하고 내부자끼리의 소통이 편리한 장점이 있다. 또 실시간 지식 공유나 정보 확산이 가능해지면서 사내에 전문가 그룹이 자연스럽게 형성되면서 문제를 해결하는 묻고/답하기 공간이 형성된다. 개인 브랜딩, 학습 조직이 구축된다. 프로젝트 등 내부 협업, 문서 공유, 아카이브 기능도 수행할 수 있다.

2) Chatter
Salesforce라는 CRM툴로 유명한 Force.com이 개발한 채터의 큰 특징은 사람이 아닌 '개체'와 친구를 맺을 수 있다는 점이다. 단순히 기업 내부자간의 커뮤니케이션(B2B) 뿐만아니라 거래처와의 커뮤니케이션(B2B) 나아가 Salesforce와 결합하여 고객 커뮤니케이션(B2C)까지 가능하다는 점이다. 거래처가 10개라면 거래처를 팔로우 할 수 있다. 영업 시스템에서 이 거래처들에 대한 정보가 바뀌거나 업데이트 되면, Chatter의 화면에서 보여지고, 스마프폰으로도 이 사실이 전달된다. Chatter는 Sales Force에서 제공하는 다양한 솔루션의 정보를 기업 내부로 통합할 수 있다는 장점을 지니고 있다.

3)Social Text
Social Text는 마이크로블로그 트위터(Twitter), 위키피디아(Wiki), 연락처(Contacs)의 3가지 기능을 적절하게 Mash-Up한 솔루션이다. 트위터처럼 400자의 단문 메시지 위주의 커뮤니케이션이 가능하지만 경쟁 서비스와 Social Text의 가장 큰 차이점은 모든 문서에 별도의 독립된 웹페이지를 생성한다는 점이다. 그룹을 만들면 모든 그룹에 지정된 웹페이지 공간이 생겨 그곳에서 공동 작업을 진행할 수 있고 개별 문서마다 별도의 URL을 제공한다.

특히 Social Text는 기업 내부의 문서와 외부의 자료를 연결하는데 탁월한 기능을 포함하고 있다. 일반 웹에서 제공하는 콘텐츠들도 쉽게 퍼올 수 있을 뿐 아니라 웹상의 위키 페이지나 블로그 등과 같은 소셜 소프트웨어들에 게재된 콘텐츠들도 가져올 수 있고, 구글 검색 결과나 RSS 피드까지도 쉽게 퍼올 수 있다. 더불어 데스트탑, 모바일 어플리케이션을 통해 오프라인 상에서도 이용할 수 있다.

4)Quik
Quik은 앞의 3가지 솔루션과 달리 한국형 기업용 마이크로 블로그 서비스다. 따라서 국내 기업의 정서에 맞게 조직 부분이나 커뮤니케이션 툴이 최적화 되어 있다. 업무에 관한 메시지 뿐만아니라 동아리, 각 부서별로 소통할 수 있도록 시스템이 설계되어 있다. 현재 숭실대학교, 동국대학교, 한국도로공사 등이 Quik 솔루션을 사내 커뮤니케이션에 적용하고 있다.

■ Enterprise 0.0에서 2.0으로의 변화

6.jpg

Enterprise 2.0은 Enterprise 0.0, Enterprise 1.0과 비교해 문화, 프로세스, 기술적인 측면에서 각각 다르다. 기업의 기존 업무와 조직을 중심으로 한 문화에서 기업의 구성원, 고객 등 사람을 중심으로 한 문화로. 업무 효율성을 중시한 프로세스가 아니고 사람의 실제 행동과 생각을 반영한 새로운 프로세스로. 위의 문화와 프로세스를 효과적으로 실행 가능하게 구현해 주는 핵심으로의 변화를 말한다.

사내 SNS의 도입 문화, 프로세스, 기술 중 가장 포괄적인 개념인 기업 문화를 바꾸고 나아가 회사 내부의 조용한 혁신을 가져다 준다. 특히 대부분의 직원들이 아이디어나 의견을 공개적으로 표현하는 것에 있어서 불편해하는 소극적 의사소통 문화가 저변에 깔려있는 국내의 기업문화를 고려할 때 평등한 소통을 기반으로 한 기업용 SNS 도입에 거는 기대가 더욱 크다고 할 수 있다.

■ Enterprise 2.0의 성공적 도입을 위한 5가지 단계

끝으로 2009년 Enterprise 2.0 Summit의 기조연설에서 Dion Hinchclif가 말한 Enterprise 2.0의 성공적 동비을 위한 5가지 단계를 통해 기업용 소셜 네트워크의 도입과정에 대해 살펴보자.

1) 사내 커뮤니티에 집중하고 모든 의사결정에 커뮤니티의 지원과 동의를 구할 것
2) 커뮤니케이션의 임계점(Critical Mass)을 넘을 수 있도록 씨앗이 될 수 있는 콘텐츠를 만들 것
3) 관리자 그룹의 적극적 참여를 유도할 것
4) 명백하고 간단한 기업용 소셜 네트워크 활용 정책(Policy)을 세울 것
5) 커뮤니티를 적극적으로 지원하고 관리할 것

결국 기업 소셜 네트워크의 도입은 기업 구성원들의 자발적인 참여와 기업 의사결정 과정에 커뮤니케이션 내용이 적극 반영되었을 때 기업 문화로 자리잡을 수 있을 것이다. 그리고 더 많은 기업용 소프트웨어가 소셜 미디어와 결합하여 새로운 형태의 가치를 창출하고 업무 효율성을 극대화 시킬 것이다. 2011년 Enterprise 2.0이 가져올 기업 커뮤니케이션 혁신을 기대해 본다.


 ※ 참고자료

- Enterprise 2.0 : Chance or Fool's Paradise for Business Transformation:http://www.e20summit.com/archive/e20-summit-2009/keynotes.html (Enterprise 2.0 Summit 홈페이지, '09.11.12)

- 위키서비스가 대세다: http://www.idg.co.kr/newscenter/common/newCommonView.do?newsId=50774(IDG Korea, '08.08.08)

- 체험 엔터프라이즈 웹 스퀘어드란? : http://kslee7.tistory.com/1183 (이상경 박사의 enterprise 2.0, '09.10.12)
- Enterprise 2.0 정의 : 
http://en.wikopedia.org/wiki/Enterprise_social_software (Wikipedia, '09.03)
- 야머 홈페이지 : https://www.yammer.com/about/product 
- Quik Youtube 공식 페이지 : 
http://www.youtube.com/watch?v=lbLxcLEBe6Y&feature=player_embedded 
- Chatter 홈페이지 : 
http://www.salesforce.com/chatter/ 
- Socialtext 홈페이지 :
http://www.socialtext.com/products/ 

기고 : VETA Research &Consulting 최규청 컨설턴트


 출처 :http://www.skyventure.co.kr/insight/web/view.asp?Num=17154&NSLT=Y 



Enterprise 2.0과 SNS을 빼고는 IT를 논할 수 없는 시대가 도래되었다고 해도 과언이 아닐듯..
Apple Gearing Up for the Coming NFC- iPhone Revolution  (0) 2012.07.19
2011년 9월말에 시행되는 개인정보 보호법에 대한 자료  (1) 2011.08.24
Gartner의 Mobile OS 관련 조사 자료 (August 2010)  (0) 2010.09.15
아이폰4 기능을 흡수한 아이팟터치  (0) 2010.09.10
미리보는 2019년 미래생활  (1) 2010.08.13
:     

TISTORY에 Login하려면 여기를 누르세요.


12인이 말하는 ‘아키텍트의 길’

Data Architecture 2010. 11. 5. 11:39

최고 아키텍트와의 가상 인터뷰

12인이 말하는 ‘아키텍트의 길’

 

아키텍트로서 성장하기 위한 길은 막막하게 느껴지곤 한다. 누구에게 아키텍트로서 가야 하는 길을 물어야 할 것인가? 산전수전 다 겪은 나이가 지긋한 아키텍트로 활동 중인 사람을 만나기란 하늘의 별따기다. 따라서 필자는 업계 최고의 아키텍트들의 조언을 모아 가상의 인터뷰를 진행해 봤다. 이 인터뷰의 내용은 필자가 PLoP라는 패턴학회에서 만난 해외 거장들과의 토론과 조만간 출간될 번역서인 『아키텍트가 알아야 할 97가지』의 내용을 모아 만들었다.

EVA(정리 - 손영수) arload@live.com

 



손영수 안녕하십니까? 여러 선배님들. 아직 ‘Architecture’의 ‘A’자도 깨우치지 못했지만, 여러 선배님들에게 아키텍트로 성장하기 위한 방법과 또 아키텍트로서 올바른 아키텍처를 바라보는 방법들을 여쭤 보고자 합니다. 많은 이들이 궁금해 하는 질문일텐데, 여러 선배님들처럼 훌륭한 아키텍트가 되기 위해선 어떠한 것들을 준비해야 할까요? 실제 현업에서 아키텍팅할 때 어떠한 부분을 고려해야 할지 여러분들의 얘기를 듣고 싶습니다.

요구사항

Rick Kazman 실제 프로젝트는 요구사항 분석에서부터 시작한다고 할 수 있죠. 이때 아키텍트가 가져야 할 중요한 덕목은 소통과 협상 능력입니다. 설계 능력 못지않게 중요한 능력이 Social Skill입니다. 다양한 이해당사자들이 모두 만족할 수 있는 시스템을 만든다는 것은 어쩌면 불가능에 가까운 일입니다. 이해당사자들의 요구사항들이 서로 충돌하는 경우도 많이 경험했습니다. 빠른 메시지 전송뿐만 아니라 높은 보안 수준을 요구한다거나, 자원의 제약이 심한 임베디드 시스템에서 고성능 PC에서나 가능한 퍼포먼스를 요구하는 것들을 예로 들 수 있죠. 아주 적은 금액으로 모든 문제를 해결해 엄청난 효과를 누리려는 이해당사자에게 정말 기간 내 구현 가능하고 필요한 기능을 뽑아 현실에서 실현 가능한 상황에 대해 이해시키는 것이 중요합니다. 만약 여기서 이해당사자들과의 합의를 이끌어내지 못하거나, 정확한 요구사항을 파악하지 못한다면 프로젝트는 초창기부터 산으로 가게 됩니다. 그 만큼 소통과 협상 능력은 아키텍트에게 설계 능력만큼 중요한 요소라는 점을 기억해 주시길 바랍니다.

Mark Richards
저도 비슷한 사례를 말하고 싶네요. 전 프로젝트를 시작할 때 항상 꺼내는 이야기가 있습니다. 소프트웨어 아키텍트들이 알아야만 하고, 이해해야 하는, 그리고 고객, 동료와 함께 꼭 프로젝트 시작 전 나눠야 하는 이야기가 있습니다. 1620년대에 스웨덴과 폴란드의 전쟁에서 나온 ‘Vasa호’라는 배 이야기입니다. 스웨덴 국왕은 전쟁을 빨리 끝내고 싶어서 Vasa호라는 특별한 배를 만들라고 주문했습니다. 이 배가 갖춰야 했던 조건(요구사항)들은 그 당시의 어떤 배와도 비교할 수 없었습니다. 선체가 200피트 정도 더 길고, 2개의 갑판에 64개의 총을 적재할 수 있고, 300명의 군사를 안전하게 태워 폴란드로 가는 바다를 가로지를 수 있는 수송 능력을 가져야 했습니다. 배를 건조하는 데드라인(시간)을 엄수해야 했으며, 재정(자금)적으로도 여유롭지 않았습니다. 또한 배 설계자(아키텍트)는 이렇게 생긴 배를 이전까지는 설계한 적이 없었습니다. 크기가 작고 총을 실을 수 있는 갑판이 한 개만 있는 배를 만드는 것이 그가 주로 한 일이었습니다. 그럼에도 불구하고, 설계자는 그의 예전 경험을 기반으로 추정하고 Vasa를 설계하고 건조하기 시작했습니다. 그 배는 결국 설계대로 건조되었고 마침내 배를 띄우는 날이 왔습니다. 어떻게 되었을까요? Vasa호는 위풍당당하게 항구를 출항했지만 예포를 쏘고 난 뒤 바로 바다 저 밑으로 가라앉고 말았습니다. Vasa호의 문제는 명확합니다. 그 어느 누구도 1600~1700년에 큰 전투함에서 갑판을 본적이 없었고 이러한 배의 갑판은 특히 전쟁 중에 붐비고 안전하지 않다는 것을 알았습니다. 전투함과 운송선 2개의 역할을 다하는 하나의 배를 건조하는 것은 큰 실수였죠. 국왕의 모든 소원을 충족하려고 한 배 설계자는 균형이 맞지 않고, 불완전한 배를 만들 수밖에 없었던 것입니다. 저희 소프트웨어 설계자들은 Vasa호로부터 많은 것을 배울 수 있습니다. 이와 같은 불행한 사건을 소프트웨어 아키텍처의 설계에 적용할 수도 있겠죠. 하지만 Vasa호와 같이 모든 요구사항을 충족시키려는 시도는 궁극적으로 아무것도 수행할 수 없는 불완전한 아키텍처를 만들게 됩니다
.

손영수 정말 깊이 새겨야 할 교훈이네요. 그렇지만 많은 관리자나 고객이 수많은 요구사항들을 결국 쏟아내는데요. 이 사람들을 설득하고 요구사항 간에 균형을 맞추는 방법은 무엇일까요
?

Rick Kazman
이해당사자들 간에 서로 상충되는 요구사항들을 우선순위화해서 아키텍처를 도출하는 ATAM(Architecture Tradeoff Analysis Method)이라는 방법이 있습니다. 이해당사자들 간에 제한된 투표권을 준 다음 정말 중요한 것 몇 개만 선택하게 하는 거죠. 그래서 정말 중요한 것들을 우선순위화할 수 있게 됩니다. 좀더 자세한 내용은 제가 쓴 『소프트웨어 아키텍처 이론과 실제(Software Architecture in Practice)』에 자세히 설명되니 읽어 보시길 바랍니다
.

손영수 그 외에 요구사항을 파악할 때 더 주의해야 할 것은 없을까요
?

Eben Hewitt
여러분에게 시스템 구축을 의뢰한 고객은 여러분의 진정한 고객이 아닙니다. 여러분의 고객의 고객이 진정한 고객이지요
.

손영수 무슨 의미인지 정확히 이해되지 않는데요. 좀 더 자세히 설명해 주십시오
.

Eben Hewitt
여러분이 전자상거래를 구축해야 한다면 여러분의 고객보다는 최종 웹사이트를 이용하는, 즉 웹사이트에서 물건을 구매하는 사람들에게 더 주의를 기울여야 합니다. 실제 웹사이트 사용자들은 전송 보안(transport security)을 필요로 할 것입니다. 그들은 저장된 데이터 암호화가 필요한 것입니다. 여러분의 고객은 이러한 요구사항을 언급하지 않을 수도 있습니다. 고객의 고객이 필요로 하는 것을 여러분의 고객이 빼먹은 것을 안다면, 왜 이러한 것들이 필요한지 언급하고 그 이유에 대해 자세히 설명해야 합니다. 만약 여러분의 고객이 실제 웹사이트 사용자에게 꼭 필요한 기능에 관심이 없다면, 프로젝트에서 잠시 물러서 제 3자의 입장에서 고려하십시오. 공격적인 고객(Sally Customer)은 매년마다 SSL에 대해 라이선스 비용을 치르기를 원하지 않고, 구축비용이 적게 든다는 이유만으로 그들의 신용카드 정보가 간단한 텍스트로 저장되기를 원할 수도 있습니다. 이미 알고 있는 나쁜 생각들을 실행하는 것에 여러분이 동의하게 되면, 여러분은 요구사항 수집에 실패한 것입니다
.

손영수 그런 깊은 뜻이 있었군요. 앞으로 명심하겠습니다. ‘고객의 고객을 고려하라.’ 정말 의미 깊은 조언이었습니다. 그럼 계속해서 다른 이야기를 나눠 보도록 하죠. 아키텍트로서 고려해야 할 다른 것들이 있으면 조언 바랍니다.

프로세스와 팀 구축

James O. Coplien 전 프로세스와 조직에 대한 이야기를 꺼내고 싶습니다. 혹시 Conway의 법칙을 아시나요? 이는 여러분이 하나의 컴파일러를 만들기 위해 4개의 팀을 만든다면, 여러분은 4단계(four-pass) 컴파일러를 얻게 된다는 것입니다. 즉 조직구조에 의해 소프트웨어 구조가 정해진다는 얘기입니다. 이미 팀이 구성된 후 요구사항을 분석한다면, 팀 구조에 맞춰 분석이 이뤄지기 때문에, 팀 구조 그대로 소??어의 특성을 파악하기도 전에 소프트웨어의 큰 구조를 정하는 우를 범한 것입니다. 만약 팀 구성 후, 어느 팀도 맡기 애매한 요구사항을 발견했다면, 이 사각지대를 서로 맡지 않기 위해 여러 가지 복합적인 일들(정치, 책임회피 등)이 발생하게 됩니다. 이 경우 종종 프로젝트가 산으로 올라가게 됩니다. 그야말로 길을 잃는 것이지요. 그래서 팀을 구축하기 이전에 비즈니스 프로세스를 정제할 필요가 있습니다. 비즈니스 프로세스를 정제한 후에 조직을 구성해야 책임의 사각지대가 생기는 것을 막을 수 있죠.

손영수 그렇군요. 효율적으로 팀을 구축하기 이전에 어떻게 해야 할까요
?

Krysztof Cwalina
프로젝트 관리자는 팀을 구성하기 이전에, 애플리케이션의 특성을 고려해 ‘땅콩버터나 마천루(적합한 프로세스)’를 선택해야 합니다. 땅콩버터(Peanut Butter)는 ‘Feature들이 중심이 되어 소프트웨어를 만드는 Bottom-Up 방식의 프로세스’를 말합니다. Bottom-Up 프로세스는 기존의 비교 대상도 없고, 전혀 새로운 소프트웨어를 만들 때 주로 사용하는 방법입니다. 이 방식은 견고하고 더디지만 모든 Feature들이 골고루 기능 향상을 가져올 수 있는 장점이 있습니다. 실제 땅콩버터처럼 모든 기능들이 골고루 퍼지고 진화할 수 있어서 땅콩버터 방식이라고 말합니다. 흔히 하위 레벨의 프레임워크나 저 수준의 라이브러리를 개발할 때는 이러한 방식이 선호됩니다. 만약 여러분의 소프트웨어가 고객의 요구사항들을 다수 받아들여야 하고 다양한 시나리오를 요구하는 경우인데도 Feature에 초점을 맞춘 땅콩버터 식의 프로세스와 조직을 구성하게 되면 어떻게 될까요? 위에서 언급한 것과 같이 새로운 시나리오가 탄생하면 많은 조직들이 협업해야 될 뿐만 아니라, 기능을 명쾌하게 나누기가 애매한 경우 많은 정치와 책임의 분배 문제 등이 발생됩니다. 이와 상반된 방식으로 마천루(Skyscraper) 방식이 있습니다. 시나리오가 마천루처럼 높이 솟아 전체 소프트웨어의 기능을 구현하기 위한 좋은 기준이 된다는 것입니다. 명백한 기준이 있다는 것은 많은 시행착오를 줄일 수 있을 뿐만 아니라, 고객의 관점에서 소프트웨어를 생각할 수 있는 장점을 가질 수 있습니다. 흔히 우리가 알고 있는 시나리오를 만들고 프로토타입(Prototype) 방식으로 개발해 나가는 것이라고 생각하면 됩니다. 바로 Top-Down 방식의 프로세스가 여기에 해당되죠. 여러분의 소프트웨어가 상위 레벨의 응용 소프트웨어로서, 많은 사람들에 의해 사용된다면 당연히 시나리오 기반(Sky scraper)의 방식으로 팀을 구성해야 합니다
.

손영수 제가 알기론 마이크로소프트에서는 Feature Crew라는 이름으로 이미 시나리오 기반으로 팀원들이 구성되어 있다고 들었습니다. 또한 애자일(Agile)에서는 Cross-Functional Team이라고 부르기도 합니다. 정말 시나리오 기반의 애플리케이션을 개발하는 곳에서는 좋은 방법일 것 같습니다
.

Rick Kazman
좋은 얘기를 해주셨네요. 우리가 설계하고자 하는 최종 소프트웨어를 고려한 형태로 조직과 프로세스가 선택되어야 합니다. 단순히 애자일의 바람이 불어서, 또는 RUP가 좋으니 이걸 사용하자는 식보다는 소프트웨어의 특성, 조직의 문화 등을 고려해 적용하는 것이 중요합니다. UML의 창시자 Ivar Jacobson 역시 RUP를 넘어 EssUP(Essential Unified Process)라는 새로운 것을 내놓았는데, 핵심은 조직과 소프트웨어 특성에 맞게 적합한 프로세스를 고려하라는 것입니다.

 

설계

손영수 그럼 설계 시 고려해야 할 것은 무엇입니까?

Kevlin Henney
여러분이 설계 시 둘 중 하나를 선택해야 한다면 대부분은 중요한 것을 선택합니다. 하지만 설계(소프트웨어 또는 다른 것들) 시에는 그렇게 해선 안 됩니다. 두 가지 선택사항이 존재한다는 것은 설계 시 불확실성을 고려할 필요가 있다는 것을 알려주는 지표(indicator)입니다. A B 두 가지 중 하나를 결정하려고 시도하는 것보다는 A B 사이의 결정을 덜 중요하게 만들기 위해 어떻게 설계해야 할지를 고민해야 합니다. 흥미로운 것은 A B 사이의 (적절한) 선택이 존재한다는 것입니다. 설계 시 변경되는 결정을 쉽게 수용할 수 있는 분할(separation) 또는 캡슐화 기법을 고민할 필요가 있습니다
.

손영수 그럼 좀 더 SoC(Separation of Concerns)와 캡슐화를 잘 하기 위해선 어떻게 해야 할까요
?

Einar Landre
넬슨 제독이 1805년 트라팔가에서 프랑스와 스페인 함대를 격파한 이후, ‘분할 후 정복(Divide and Conquer)’ 또는 ‘걱정거리의 분리(Separation of Concern)’는 복잡하고 어려운 문제를 다루는 슬로건(상징)이 되었죠. 걱정거리의 분리로부터 우리는 캡슐화를 얻게 되고, 캡슐화로부터 우리는 경계와 인터페이스를 얻게 됩니다. Kevlin Henney가 말하는 것처럼 아키텍트가 가장 크게 겪는 난제는 동작하는 시스템을 구축하기 위해 필요한 인터페이스를 정의하고 경계를 정하는 자연스러운 위치를 찾는 것이죠. ‘결합도는 낮추고 응집도는 높여라’와 ‘정보 교환이 자주 발생하는 영역들은 나누지 말라’와 같은 오래된 명언들이 몇 가지 지침을 제공하지만, 어떻게 이해당사자들에게 가능성 있는 해결방안과 문제들에 대해 쉽게 소통할 수 있는지는 알려주지 않습니다
.

손영수 그렇군요. 결국 이해당사자들과 소통 속에서 적합한 균형을 찾아야 된다는 말씀이군요. 그럼 어떻게 하면 이러한 균형을 잘 찾을 수 있을까요
?

Einar Landre Eric Evans
의 책인 『Domain-Driven Design』에 나온 Bounded Context(문맥 정합) Context mapping(문맥 맵핑)의 개념이 앞에서 언급한 이해당사자들과 소통의 문제를 잘 해결해 줍니다. Bounded Context는 모델이나 개념을 고유하게 정의하는 영역입니다. 그리고 우리는 Bounded Context를 설명부를 가진 구름 또는 거품으로 표현합니다. 이 설명부는 도메인에 가까운 모델 또는 개념의 역할과 책임을 정의합니다. 한 가지 예를 들면, 운송 시스템은 화물 운송, 화물 일정, 항구 이송과 같은 Context(문맥)를 포함합니다. 다른 도메인에서는 다른 이름들을 사용하는 게 적합할 것입니다. Bounded Context들을 화이트보드 위에 식별하고 같이 그림으로써, Context 간에 연관관계를 그리는 것을 시작할 수 있습니다. 이러한 연관 관계들은 조직적, 기능적, 기술적 의존성을 설명하면 좋습니다. 이러한 행위의 결과로, Context 간에 인터페이스와 동일한 의미로 인식한 Context의 집합을 나타내는 Context Map이 생기게 됩니다. Context Map은 아키텍트에게 무엇을 같은 걸로 볼지, 별개의 것으로 볼지 초점을 맞출 수 있고, 좀 더 현명하게 대화를 나눔으로써 분할 후 정복할 수 있는 강력한 도구를 제공합니다. 이런 지침을 통해 약한 결합, 높은 응집, 잘 설계된 인터페이스로 구성된 시스템으로 재설계할 수 있습니다


손영수 결국 고객의 대화를 잘 이해함으로써 이러한 균형점을 찾을 수 있다는 정말 와 닿는 얘기입니다. 그럼 아키텍트가 설계 시 추가적으로 고려해야 할 사항은 무엇일까요
?

Doug Crawford
변화의 충격을 이해할 필요가 있습니다. 뛰어난 아키텍트는 복잡도를 최소한으로 줄일 수 있어야 하며, 단단한 기본 구조를 취하면서도 급변하는 상황에 적절히 대처할 수 있는 실용적인 해결책들을 설계할 수 있어야 합니다. 뛰어난 아키텍트는 고립된 소프트웨어 모듈에서뿐만 아니라 사람과 사람 사이, 시스템과 시스템 사이에서 일어나는 변화의 충격을 이해해야 합니다. 변화는 기능 위주의 요구사항 변경, 요구사항의 진화, 수정된 시스템 인터페이스들, 팀원의 변동과 같은 다양한 형태화의 광범위함과 복잡함을 미리 추측한다거나, 모든 잠재적 문제를 미리 예측해 해결한다는 것은 불가능합니다. 하지만 아키텍트는 이러한 변화가 발생했을 때, 다른 객체나 모듈에 변화를 전파시키지 않고 변화의 충격을 완화시켜 수용할 수 있는 시스템을 구축해야 합니다. 이러한 변화를 완화하기 위한 도구나 기법으로는 다음과 같은 것들이 있습니다.

 

- 반복 가능한 테스트 케이스를 만들고 자주 실행하기
-
쉬운 테스트 케이스를 만들기
-
의존성 추적하기
-
조직적으로 행동하고 반응하기
-
반복적인 태스크는 자동화하기



또한 위험을 미리 측정하는 Premortem은 어떠한 부분에 집중적으로 시간을 투자해야 할지 알려주는 유용한 도구입니다. 아키텍트는 프로젝트 범위의 관점에서 시간, 예산과 같은 변화의 영향을 미리 추정해야 하고 변화로 인해 엄청난 영향을 받는 부분에 더 많은 시간을 투자해야 합니다.

손영수 변화를 수용할 수 있는 구조, 소프트웨어 개발 생명주기의 관점에서 볼 때, 유지보수에 70%의 비용이 드는 관점으로 볼 때는 정말 중요한 말씀이군요. 저 같은 경우는 설계 시 실제 아키텍처를 검증하기 위해 몇 가지 프로토타입을 만들어 종종 검증합니다. 이것은 어떨까요
?

Clint Shank
좋은 방법입니다. 애플리케이션 아키텍처를 구현하고 검증하고 진화시키는 유용한 전략 중 하나로 Alistair Cockburn이 이야기한 ‘걸어 다니는 해골(walking skeleton)’이 있습니다. 걸어 다니는 해골은 종단(예를 들어 UI부터 DB까지) 간을 오가며 수행되는 시스템의 가벼운 구현체입니다. 모든 주요 아키텍처상의 컴포넌트는 전부 연결합니다. 모든 호출(Com munication) 경로를 실험할 수 있게 작동하는 작은 시스템부터 시작한다면, 옳은 방향으로 설계 및 개발해 나갈수 있습니다
.

손영수 그럼 이제 개발 과정에서 아키텍트는 어떠한 일을 하는지 궁금합니다.

 

개발

Erik Doernenburg 아키텍트는 현재 개발하고 있는 소프트웨어가 얼마나 잘 개발되고 있는지를 파악할 수 있어야 합니다. 사용자에게 가치 있는 소프트웨어도 중요하지만, 내부적으로 좋은 품질을 유지하는 것도 중요하죠. 좋은 품질을 얻기 위해서는 쉽게 소프트웨어를 이해, 유지보수, 확장할 수 있어야겠죠. 그럼 소프트웨어가 잘 개발되고 있는지 매 순간 상황을 파악하기 위한 방법에는 어떤 것이 있을까요? 많은 이들이 UML로 그려진 아키텍처 다이어그램을 사용합니다. 하지만 아키텍처 다이어그램에서 작은 상자들은 전체 시스템을 나타내며 상자 간의 선은 시스템 간의 의존성, 데이터 흐름, 버스와 같은 공유자원 등 모든 것이 될 수 있습니다. 마치 비행기에서 보는 풍경과 같은 30,000피트 뷰입니다. 너무나 추상화되어 있는 관점이죠. 반면에 0피트, 즉 바닥 레벨의 뷰를 보기도 합니다. 즉 소스 코드를 보는 것이지요. 바닥 레벨의 뷰는 연관 있는 몇 개의 객체 구조도 보지 못할 정도로 너무나 많은 정보를 제공합니다. 즉 이 두 뷰는 소프트웨어 품질에 대한 많은 정보를 제공하지 못한다는 것이지요. 그래서 0피트와 30,000피트 사이에 적절한 뷰가 필요합니다. 바로 1,000피트의 뷰입니다. Dependency Structure Metrics로 모듈 간의 의존성을 파악할 수 있으며 Code Metrics를 이용해 클래스의 크기를 파악할 수 있습니다. 특정 클래스가 거대하다는 것은 너무나 많은 책임(역할)을 가지고 있다는 의미죠. 이러한 다양한 지표들(클래스 팬아웃, 메소드 개수, Circular Dependency )을 지원하는 사용 툴들(NDepend, XDepend, JDepend)을 이용하면 됩니다.

손영수 1,000피트의 뷰라니 정말 멋있는 표현입니다. 저 역시 리팩토링할 때 DSM Code Metrics를 즐겨 이용하는 편인데, 다행히 방향은 제대로 잡은 것 같습니다. 그럼 다른 조언도 부탁합니다
.

Dave Quick
거울로 보이는 문제는 실제 보이는 것보다 클 수 있습니다. 많은 소프트웨어 프로젝트에 참여했던 그 동안의 경험에 비춰 보면, 각 팀의 구성원들은 팀이 예상한 것보다 더 많은 문제를 가지고 있습니다. 소규모의 팀은 이런 문제들을 초기에 확인할 수 있지만, 대부분 잊어버리거나 무시합니다. 그 이유는 프로젝트 초기에는 이 문제가 얼마나 프로젝트 후기에 큰 영향을 미치는지를 이해하지 못하기 때문입니다. 이러한 문제를 초기에 대처하기 위한 몇 가지 전략이 있는데 다음과 같습니다.

 

- 리스크를 관리하는 조직화된 접근 방법을 만들어야 합니다. 리스크를 관리하는 간단한 방법은 여러분이 버그를 추적할 때와 같은 방식으로 리스크를 관리하는 것입니다. 누구나 리스크를 발견할 수 있고, 각각의 리스크가 더 이상 리스크가 아닐 때까지 추적할 수 있습니다. 그 후 리스크들에 우선순위를 매기고 리스크의 상태가 변화하거나 새로운 정보가 있을 때마다 리뷰를 합니다. 리뷰는 토론를 통해 감정적인 면을 배제하도록 도와주고 주기적으로 리스크를 재평가함으로써 쉽게 기억하도록 도와줍니다.

-
주류의 의견에 반대할 때는 나머지 팀원들이 자신의 의견을 더 쉽게 이해하도록 만드는 방법을 찾아야 합니다. 반대 의견의 가치를 인식하고 모든 팀원에게 용기를 주십시오. 그리고 토론 시 팀원들이 중립적인 자세를 가지도록 하십시오
.

-
‘구린 냄새(Bad smells)’를 주의해야 합니다. 아직 명확한 근거가 없다면 사실을 확인할 수 있는 가장 간단한 테스트 방법을 찾으세요
.

-
지속적으로 팀과 고객에 대해 이해하는 내용을 테스트해 보세요. 사용자 이야기(user story)로 우선순위 목록을 정하는 툴의 도움을 받을 수 있지만, 정기적으로 고객과 대화를 나누는 열려 있는 자세를 대체할 순 없겠죠
.

-
맹점이란 그 말 의미 자체가 말해주듯이 스스로 인지하기 어렵습니다. 여러분이 필요로 할 때 말하기 힘든 사실을 말해주는 믿음직한 사람이 여러분의 귀중한 자산입니다.

 

손영수 개발 도중에도 아키텍처만 그려주고 사라지는 아키텍트가 아닌, 팀원 간 또는 이해당사자 간에 소통이 잘되는 문화를 만들고 잘못된 방향으로 흘러가면 가이드해서 바로 잡아야 한다는 조언이군요. 그럼 아키텍트가 가져야 할 자세에 대해서도 조언 바랍니다.

 

아키텍트로서 갖춰야 할 자세

Dave Quick 아키텍트는 자신이 최고라는 대문자 ‘I’보다는, 일원이라는 의미를 가지는 소문자 ‘i’의 자세가 필요합니다. 아키텍처를 수립할 때, 여러분 스스로가 최악의 적이 될 수도 있습니다. 여러분이 고객보다 요구사항을 더 잘 이해한다고 생각하거나, 개발자를 아이디어를 구현하기 위한 단순한 자원으로 보거나, 여러분의 생각에 도전하는 개발자나 팀원을 무시한 경험이 있습니까? 성공이나 사회적 지위로 인해 자만하거나 다른 사람들이 우리를 존경한다는 착각을 가지고 있고, 자신이 만든 설계에 도전하는 것을 여러분 자신의 인격에 대한 도전으로 받아들인 경험이 있을 것입니다. 이것은 과거의 성공에 빠져 여러분을 더 작은 한계에 가두는 짓입니다. 아키텍트로서 스스로 성장하고 성공하는 프로젝트를 만들기 위해서는 여러분의 마음가짐을 바꿔야 합니다. 전 후배 여러분들에게 다음과 같은 자세를 요구합니다.

 

- 요구사항은 거짓말을 하지 않습니다. 요구사항이 제공하는 비즈니스 가치를 이해하기 위해 고객과 가까이 일하십시오. 아키텍처를 여러분이 이끌려 하지 말고 요구사항이 이끌도록 하십시오. 여러분은 최선을 다해 그들의 필요를 섬겨야 합니다.

-
팀에 집중하십시오. 팀은 자원이 아닙니다. 그들은 여러분의 설계 협력자이자 여러분의 안전망입니다. 진가를 인정받지 못하는 사람은 보잘 것 없는 안전망을 만듭니다. 아키텍처는 팀의 것이지 혼자만의 것이 아닙니다. 여러분은 가이드라인을 제공하고 모든 사람이 협력해 함께 이끄는 것이라는 마음가짐을 가져야 합니다
.

-
여러분의 업무를 점검하십시오. 모형은 아키텍처가 아닙니다. 이것은 아키텍처가 동작하는 방법에 대한 여러분의 이해일 뿐입니다. 프로젝트 아키텍처가 각 요구사항을 어떻게 지원하는지 검증하는 테스트 항목을 정하기 위해 여러분의 팀과 함께 일하십시오
.

-
여러분을 돌아보십시오. 자기의 일을 방어하고, 이기적인 관심에 집중하고, 우리 자신을 방 안에서 가장 영리한 사람으로 여기는 우리의 본능과 싸워야 합니다. 매일 몇 분 동안 여러분의 행동에 심사숙고해 보십시오. 여러분은 모든 사람의 아이디어에 그들이 마땅히 받아야 할 존경과 인정을 주었습니까? 여러분은 선의의 참여에 부정적으로 대하지는 않았습니까? 누군가가 여러분의 접근 방법에 왜 불응했는지 이해하기 위해 노력해 보신 적이 있습니까? 자기 자신을 되돌아 볼 필요가 있습니다.

 

손영수 저도 그렇게 생각합니다. 제가 소문으로 들었던 몇몇 아키텍트들은 많은 반대에도 불구하고 자신의 생각을 관철시키곤 했습니다. 설계 자체의 옳고 그름을 떠나 개발자들과 소통 없이 일방적으로 자신의 생각을 강요했죠. 그 결과로 설계 따로, 개발 따로 하는 프로젝트가 되었다는 이야기를 들었습니다. 개발자를 이해하는 아키텍트, 그리고 아키텍트를 이해하는 개발자들이 모여야 정말 좋은 프로젝트로 갈 수 있을 것입니다. 마음가짐에 대한 또 다른 의견도 듣고 싶습니다.

David Bartlett
아키텍트는 쇼맨십을 뛰어넘는 가치 있는 청지기 의식(Stewardship)을 가져야 합니다. 아키텍트들은 프로젝트에 착수할 때, 자신의 가치를 입증하려는 갈망이 있죠. 소프트웨어 회사에서 아키텍트 역할을 맡는다는 것은 아키텍트의 기술적 리더십을 회사의 일부분으로 절대 신뢰한다는 의미입니다. 그런데 불행히도 자신의 가치를 입증하기 위해 개인의 기술적 탁월함과 쇼맨십으로 팀원들을 이끌어야 한다고 오해하는 아키텍트들이 있습니다. 사람들에게 어필하는 행동인 쇼맨십은 마케팅에서는 중요할지도 모릅니다. 하지만 소프트웨어 개발 프로젝트에 있어서는 역효과를 나타낼 뿐입니다. 아키텍트는 확고한 리더십으로 그들 팀의 존경을 얻어야만 하고 기술과 팀이 운영하는 비즈니스 도메인의 이해가 있어야 합니다. 책임지고 다른 이들을 돌보는 청지기 의식은 아키텍트에게 꼭 필요한 자질입니다. 아키텍트는 고객을 위해 최선을 다해야 하지, 고객의 요구를 이용하려고 해서는 안 됩니다. 소프트웨어 아키텍처는 고객의 요구들을 수행하는 것으로, 보통 탁월한 능력을 소유한 도메인 전문가의 방향 제시로 이뤄집니다. 성공적인 소프트웨어 개발을 추구하는 것은 아키텍트가 프로젝트에 주어진 시간과 노력에 대비해 구현의 복잡성과 비용 사이에 균형이 잡힌 절충된 솔루션을 만들게 합니다. 최신의 따끈따끈한 프레임워크나 기술 전문 유행어로 이뤄진 과도하게 복잡한 시스템은 비용 지출의 희생을 담보로 합니다. 아키텍트의 활동은 투자 브로커처럼 합리적인 ROI(투자 대비 수익률)를 창출할 수 있다는 전제 하에 고객의 돈을 사용하도록 해야 합니다. 여러분이 다른 사람의 돈을 사용하고 있음을 절대 잊어버려서는 안 됩니다
.

손영수 아키텍트 명함을 가지고 다니는 사람들 중에는 신기술로 도배된 제품을 팔기 위한 비즈니스맨인지, 아키텍트인지 구분하기 힘든 이들이 있습니다. 청지기 의식이라는 것을 통해 많은 것을 되돌아보게 되었습니다. 지금까지 여러분의 소중한 조언을 들을 수 있었습니다. 설계만 잘하기 위한 공학적인 기법만큼 외부와 소통 및 협상하고, 팀원들을 이끄는 정신도 중요하다는 것을 깨우치는 시간이 되었습니다. 이 가상 인터뷰가 아키텍트를 꿈꾸는 많은 이들에게 유용한 시작점이 되었으면 합니다.

 

출처 : 한국 마이크로소프트웨어
제공 : DB포탈사이트 DBguide.net

 
Architect가 걸어가야 할 방향에 대해 잘 정리된 내용이네요. Architect에 관심이 있다면 꼭 생각해야

할 사항들만 소개된듯.... 이 책이 출간되면 한번 구매해서 읽어봐야겠다는.....

'Data Architecture' 카테고리의 다른 글

Power Designer와 ERWin의 비교  (0) 2012.02.16
OLAP의 정의와 활용  (0) 2010.09.15
The Nine Circles of Data Quality Hell  (0) 2010.08.13
:     

TISTORY에 Login하려면 여기를 누르세요.


정보 습득에 여과 Filter를 달자

Happening 2010. 10. 11. 09:30

많은 분들이 아시는바와 같이, "타진요" (타블로에게 진실을 요구합니다)라는 카페에서 타블로를 대상으로

학력위조에 대한 논쟁을 벌이고 있던 사실 아시죠??

지난주에 제가 마지막으로 접한 기사는... "검찰에서 타블로에 대한 학력이 사실임은 입증했다.

타진요 카페를 운영하고 있는 왓비컴즈라는 아이디를 사용하고 있는 사람에 대해 수사중이다." 인데요.

제가 얘기하고자 하는 것은 이 사건에 대한 진실이나, 누가 잘못했고, 누가 잘했고의 시시비비를 가리고자하는

것은 아닙니다.

요즘과 같이 Twitter나 Facebook 등 다양한 SNS를 통해 하루에 접하는 정보의 양만해도 정말 어마어마합니다.

이런 정보들 속에서 정말 내가 원하는 것은 무엇이고, 정말 진실되고 가치가 있는 정보가 얼마나 되는지에 대한

생각을 해봅니다.

단순히 정보를 습득하는 시대는 지났습니다.

어떤 정보를 어떻게 받아들이냐에 대한 선택이 정보 습득자의 문제로 남는 때가 아닌가 싶습니다.

과거와 같이 단순하게 기사나 블로그 같은 곳의 글을 여과없이 그대로 믿고 전파했다가는 곤란한(?) 상황에도

빠질수 있기 때문입니다.

현재 여러분은 이런 정보의 홍수(?) 속에서 어떻게 선취(選取)를 하고 있나요??

좋은 방법 또는 노하우가 있으면 공유하심이 어떠실런지??

이런 노력과 습관들이 모여서 좋은 인터넷 문화가 자리잡게 되는게 아닐까 생각해봅니다 ^^

'Happening' 카테고리의 다른 글

Atlanta의 지하철 MARTA와 Breeze Card  (1) 2012.05.07
수동식 문서 분쇄기  (0) 2010.11.05
커피 파는 젊은 의사가 있는 제너럴닥터병원  (1) 2010.10.07
성공이란 무엇인가?  (0) 2010.10.05
신념이란  (0) 2010.10.01
:     

TISTORY에 Login하려면 여기를 누르세요.


커피 파는 젊은 의사가 있는 제너럴닥터병원

Happening 2010. 10. 7. 10:08
우리나라 의료 시스템의 문제를 지적할  의료소비자 입장에서 가장  꼽는 불만  하나가  대기시간에 비해 짧은진료시간이 아닐까 싶습니다. 의료 공급자인 , 의원에서는 나름대로의 사정이 있습니다만, 그런 복잡한 이야기는 잠시 접어두고 환자와의 소통을 중요시하는, 달리 이야기하면 시간에 쫓기지 않는 진료를 하기 위해 약간은 황당한 시도를 하고 있는  젊은 의사 이야기를 할까 합니다.


사용자 삽입 이미지

<커피를 파는 병원? 제너럴닥터>


화제의 주인공은 홍대 앞 놀이터 근처에 있는 제너럴닥터란 카페와 진료실의 혼합 공간에서 찾을 수 있었습니다. 김승범 원장님이 운영하는 이 제너럴닥터는 카페와 진료실이 혼합된 공간이란 이유로 이미 여러 차례 언론의 관심을 받은 바 있었습니다.


<제널럴닥터 언론 기사들 - 링크>



대부분의 언론들이 진료실과 카페의 결합이 신기하고, 뜻 깊어 보인다 라는 정도를 강조하고 있습니다. 하지만, 같은 의사의 입장에서는 일전에 <뉴욕에서 의사하기> 고수민 선생님께서 "저수가라는 천원짜리 자장면의 비밀 레시피"에서 말씀하셨던 것처럼, 저수가인 의료 현실을 극복하기 위해 비급여 항목 진료를 하는 것 대신에 커피를 파는 것 이라고 생각했습니다. 단지 업계(?)에서 금기시하는 중국집(병,의원)에서 중국 음식(의료)이 아닌 커피를 파는 것이 특이하게 생각되었습니다.


저는 단순한 호기심 차원이 아닌 의사로써 조금은 현실적인 이야기를 들어 보기 위해 방문을 했습니다. 조금 긴 인터뷰입니다만, 찬찬히 읽어주시면 우리가 잊고 있던 병,의원의 모습과 꿈과 열정을 가진 한 젊은 의사를 만날 수 있을 것이라고 생각됩니다.


사용자 삽입 이미지

<입구에 걸려있는 제너럴닥터 간판>


위치는 홍대 건너편에 있는 작은 놀이터의 화장실 건너편에 위치하고 있습니다. 간판이 작고 약간은 외진 곳에 있기 때문에 그렇게 눈에 확 띄지는 않습니다. 그 골목을 두 차례 돌고 나서야 미처 보지 못했던 저 간판을 찾을 수 있었습니다.


눈썰미 있으신 분들은 저 간판을 보며 약간 특이한 점을 발견하셨을 지도 모릅니다. 네, 저 하얀 형광등이 들어 있는 간판은 사실 엑스레이 판독을 하기 위한 판독대입니다. 간판 소재뿐 아니라 General Doctor란 이름부터 진료실이란 느낌을 주고 있네요. 하지만 아래 Hand drip/Espresso란 것에 병원 컨셉의 카페로 생각할 수도 있을 것 같습니다.


사용자 삽입 이미지

<카페 내부 모습, 조용한 음악이 흐르는 편안한 분위기>


제가 방문했을 때에는 여성분 두 분이 즐거운 이야기를 하고 있었고, 반대쪽 창문에는 외국인 두 분이 카페에 있는 게임을 하고 있었습니다. 두리번거리며 병원이라고 느낄 수 있는 무언가가 있지 않을까 찾아봤지만 없었습니다. 아마 사전 지식이 없었다면 카페로 알고 들어와 차만 마시고 나갈 수도 있었을 것 같습니다.


사용자 삽입 이미지

<직접 커피를 내리고 있는 제너럴닥터의 김승범 원장>


카페의 사장이자, 제닥의 원장인 김승범 선생님은 진료실에 환자가 없을 때에는 직접 커피를 내리고 카페의 궂은 일도 직접 하고 있었습니다. 다양한 병원의 형태를 직접 보고 또 이용도 해봤지만, 카페와 진료실의 결합도 특이하고 왜 탕수육(비급여 항목)이 아닌 커피를 파는지도 궁금해 졌습니다.


김승범 선생님과 마주 앉아 커피를 마시며 우선, 제닥을 만든 이유와 추구하는 바에 대해 물어 봤습니다. 


"제닥은, 어떻게 해야 우리 나라의 의료 체계 안에서 환자와 극단적으로 가까워질 수 있는 병원을 만들 수 있을까 하는, 처절할 정도로 현실적인 고민의 끝에 나온 결과물입니다. 

환자와 가까워지기 위해 충분한 시간을 가지고 진료하다 보면, 환자들의 대기 시간이 너무 길어질 것이고, 병원은 돈을 벌 수 없어 유지를 할 수 없다는 것이죠. 게다가, 기존의 병원의 환경은 의사와 환자가 충분히 이야기를 나눌 수 없는 형태라는 점도 문제였습니다. 

많은 사람들이 보통 병원에 가는 데에는, '빨리 약을 먹거나 주사를 맞아서 나아야지, 또는 어떤 검사를 받아봐야지' 라는 생각이 지배적이죠. 의사와 친해질 만한 마음의 여유가 없습니다. 이런 자세는 의사도 마찬가지라서, 환자의 당면한 문제를 해결하는 것에만 집중을 하게 되죠. 아프기 전에 병원에 자주 가면서 건강을 확인하라고 아무리 계몽을 한다 해도, 병원에 대해 의사와 환자의 의식이 이렇게 고정되어 있는 이상, 뭔가 큰 변화는 기대하기 어려웠던 것입니다.

따라서, 어떻게든 병원 환경을 완전히 바꾸어야 하겠다고 고민하고 있었는데, 이런 관점에서 카페를 바라봤더니 원래 카페란 곳이 아무 일 없어도 시간을 보내러 가는 곳이고, '기다림' 자체를 즐길 수 있는 재미있는 공간이더군요. 게다가 좋은 음료와 휴식은 좋은 진료와 충분한 의사소통에 더할 나위 없는 친구가 될 수 있다는 것을 깨닫게 되었고, 이런 생각 끝에 제너럴닥터의 개념을 구상했죠."


사용자 삽입 이미지

<김승범 선생님이 직접 내려 준 커피>


의사로서 환자와 깊이 소통을 하기 위해 커피를 판다는 김승범 선생님. 의사로서 커피를 팔아 버는 수익으로 부족한 진료 수익을 보충하는 방식에 혼란을 겪고 있지 않은지 물어봤습니다.


"카페 수익은 제너럴닥터의 중요한 수입원입니다. 제너럴닥터가 카페와 진료실이 공존하는 공간이니 양쪽 수입이 모두 중요합니다. '의사가 커피를 팔아야 원하는 진료를 할 수 있다니, 그게 뭐야? 게다가 진료비 수익보다 카페 수익이 더 많다면 그게 병원이라고 할 수 있어?' 라고 누군가 말하신다면 '왜요? 그게 재미있는걸요.' 라고밖에는 말씀을 드리기 어려울 것 같네요. 

사실, 현실적으로는 보험 진료 수익에만 기대는 병원 모델은 이미 무너지기 시작하고 있기 때문이기도 합니다. 비보험 수익을 주로 이끌어 내면서 보험진료는 오히려 등한히 하는 방식보다는, 차라리 맛있는 커피나 음료를 만들어 주면서 병원 수익을 보전하는 것이 더 맘 편하겠다 라고 생각한 것도 이유지요."


사용자 삽입 이미지

<제닥의 김승범 원장>


소통이 부족한 진료실 내부의 문제에 대해 저역시 공감합니다만, 자신의 소신을 지키면서는 경제적인 수익을 정상적으로는 보상받을 수 없는 현실을 극복하기 위해 커피를 파는 것도 쉽지 않은 결정입니다. 그렇다면, 카페라도 손님이 가득 차야 수익이 보장될 텐데 간판도 찾기 어렵게 되어 있고, 적은 환자수 못지 않게 손님도 비교적 많지 않아서 조용한 분위기로 입 소문을 타고 있는 카페라고 하던데, 직원들 월급은 잘 주시는지, 살짝 걱정이 되기도 했습니다. 


"얼마 전까지는, 찾기 어려워서인지 조용한 단골들만 찾는 분위기였습니다. 저도 그런 분위기가 좋고, 지금 간판이 마음에 들어서 고쳐야겠다는 생각은 별로 하지 않고 있었습니다. 다만, 저희를 좋아해서 멀리서부터 오시는 분들 중에서 어디인지 찾지 못하고 그냥 돌아가시는 분들도 있다고 하는 말을 들은 뒤로 '조금 고치긴 해야겠구나' 하는 생각은 했습니다. 너무 눈에 띄게 하기는 싫어서...고민을 하고 있는 중이지요. 

그리고, 현재의 수익은....솔직히 아직 돈을 벌고는 있지 못합니다. 임대료도 비싸고, 보시다시피 손님이 많지 않기 때문이죠. 하지만 시작한지 8개월밖에 지나지 않은 것을 생각해 보면, 나쁘지 않은 상황이라고 생각합니다. 개원자금 대출로 받은 은행 이자만 아니었다면 흑자인 상황이니까요. 매달 수익이 늘어가는 게 보이니, 조만간 경제적인 면은 문제가 되지 않을 것이라고 생각해요. "


제너럴닥터에는 김승범 원장을 포함해 간호사 1명과 직원 3명이 근무를 하고 있습니다. 직원도 적지 않고, 보통 병,의원이 개업하면 초기 인테리어와 마케팅에 억 소리 나는 비용이 들어가는 것을 감안하면 지난 8개월의 제닥의 움직임은 나쁘지 않다고 평가할 수 있습니다. 몇 차례 언론에 노출되au서 상당히 화제가 되었고, 여러 검색 포털에서 제너럴닥터를 검색하면 다 나오고 있으니 지금까지의 적자는 투자였다고 생각할 수도 있다는 것입니다.


사용자 삽입 이미지

<세심한 소품들이 인상적인 카페 내부>


이야기를 나누던 중, 환자의 진료가 있었습니다. 그리고, 소문대로 무려 1시간이 넘는 진료를 하는 것을 목격할 수 있었습니다. 게다가 선생님이 나오고 나서도 간호사와 30여분을 상담하는 모습을 보니, 무척 놀라웠습니다. 어떤 환자이길래 이렇게 오래 진료를 한 것일까, 많은 언론에서는 긴 진료시간에 대해 강조한 것을 봤는데, 늘 이렇게 1시간씩 진료하는 걸까요?


"지금 진료받으신 환자분께서는 카페 단골 손님이세요. 처음 왔을 때는 카페인 줄로만 알았지만 병원인 것을 알고도 커피 마시며 공부하러 자주 오고 계시죠. 오늘 진료를 받으신 이유에 대해서는.. 자세한 것은 환자의 비밀이라서 말할 수 없지만, 워낙 오랫동안 굳어진 생활 습관 때문에 문제가 있는 것 같아서 습관을 고치실 수 있도록 상담하다 보니까 길어졌네요. 

하지만, 늘 이렇게 한 시간씩 진료하지는 않아요. 단순한 감기나 별다른 문제가 없는 분들의 경우에는 오래 붙잡아도 서로 불편하기 때문에 10분만에 진료를 끝내기도 하죠. 제가 중요하게 생각하는 것은 의사와 환자 사이의 소통의 질입니다. 충분하게 서로 하고 싶은 이야기를 할 수만 있다면, 몇 분이 걸리든 상관이 없지요."


빨리 봐서 10분이라니, 보통 3분 진료라고 말하는 것에 비하면 꽤 긴 시간임에 틀림이 없습니다. 그렇다면, 제닥의 환자는 주로 어떤 분들일까요? 제닥을 자주 이용하시는 분들의 이용 방식은 주로 3가지라고 합니다.


"어느 날 감기가 들어 진료를 받으러 왔던 학생들이 다음에는 카페에 차만 마시러 친구들과 오거나, 학교 숙제를 하러 오기도 합니다. 혹은 카페 이용만 하던 손님이 어느 날은 오늘처럼, 진료를 받으시기도 합니다. 이렇게 진료를 받고는 가방을 카페에 두고 나가서 약을 지어온 뒤 다시 자리에 앉아 책을 읽으며 차를 마십니다. 또 다른 경우로는 진료 받으러 온 분의 친구가, 자기도 생각해 보니 신경 쓰이는 건강 문제가 있다며 진료를 받고 카페의 자리로 돌아가 친구와 건강에 대한 수다를 떱니다.

이 모든 경우가 기존의 병원 이용 방법과는 거리가 멀고, 일반 카페와도 차이가 있습니다. 제닥은 기본적으로 병원의 기능을 하고 있으면서 제대로 된 카페의 기능도 하고 있지요. 이를 통해 진료실에서만 만나던 의사 환자 관계가 변화되어 진료실 밖에서 맛있는 음료나 간식을 만들어 주고 먹으며 이야기를 하는 인간 대 인간으로 교류할 가능성을 더 제공하는 의료 환경을 조성하고 있는 셈입니다."


카페만으로도 이용할 수 있지만, '내 단골 카페가 병원이야'라는 식으로 부담 없이 이용할 수 있는, 꼭 아프지 않아도 언제든 쉽게 의사를 만나 상담을 받을 수 있는 것이 제닥의 가장 큰 장점으로 보입니다. 


사용자 삽입 이미지

<무선 인터넷이 지원되는 카페 내부>


여러 언론을 통해 비춰진 모습으로 생각하기에는 단순히 이상을 이야기하며 특이한 마케팅을 하고 있는 것은 아닌가 살짝 의심했는데, 실제 만나보니 이상적인 진료를 위해 뛰고 있는 열정적인 의사이자 사업가였습니다. 하지만 다른 병,의원들과는 다른 길을 택하겠다고 결심하고 은행 대출까지 받아가며 개원하기까지는 쉽지 않았을 것 같습니다. 어떻게 이런 결정을 하게 된 것일까요?


"제너럴닥터를 시작하게 된 데에는 제 '의료 디자인' 사업을 위한 시작점이 필요하겠다는 현실적인 고려가 있었습니다. 제가 하려는 의료 디자인(Medical Design)은, 극단적으로 인간적인 의료를 위해 뭔가 엉뚱한 것들을 만들어 내는 식입니다. 

그동안 이런 엉뚱한 것들의 이야기를 들려드리거나 시제품을 만들어 보여드리면, 의사든 일반인이든, '재미있다-'는 반응과 '뭔가 잘 해보면 좋겠다-'는 정도가 전부고, 제 일을 적극적으로 이해해 주고 도와주려는 사람을 찾기란 거의 불가능에 가까웠습니다. 처음에는 사업만 하려고 마음먹었었지만, 차라리 내가 생각하는 엉뚱한 병원을 만들어서 내가 생각하는 가치가 헛된 것이 아님을 보여주자! 하고 마음을 바꾸었죠."


사용자 삽입 이미지

<카페 내부에 있는 크리스마스 장식들>


개원을 목적이 아닌 사업의 과정으로 생각하고 했다는 점은 매우 특이하게 다가왔습니다. 그런데 이제 제너럴닥터는 김승범 선생에게 또 다른 의미가 있다고 했습니다.


"하루 하루 진료를 하면서 환자와의 소통을 통해, 환자-의사간의 소통이 그 동안 정말 처참할 정도로 이루어지지 않고 있었구나 하는 것을 알게 되었습니다. 그리고 이렇게 소통을 극단적으로 강조하는 진료 방식이 조만간 상업적으로도 성공하는 길이 될 것이라고 믿는 마음이 더욱 강해집니다. 저는 지금도 제너럴닥터를 통해 제가 생각한 것을 증명하고 있는 것이죠. 

그저 환자에게 성실히, 의사로서의 책임을 다 하며 진료를 하고 싶은 요령 없는 의사들은 우리 나라에서 의사로 살아가기에 대단히 힘이듭니다. 요령 좋고 '고객이 원하신다면' 불필요한 주사나 약도 드리겠다는 자세의 과잉 진료를 하는 병,의원이 오히려 친절하고 실력 있는 곳으로 승승장구하기 좋은 환경이기 때문입니다.

어느 직업 군에서나 요령 없이 기본에만 충실한 사람은 성공하기 어렵다고 합니다만, 의사란 직업에서는 자신의 일에 성공하지 못하는 것 뿐 아니라 자신이 인정받고 싶어 하는 환자에게서도 인정받지 못하기 때문에 어느 것도 만족할 수 없어 상당한 자괴감에 빠지기 쉽습니다. 제너럴닥터의 모델을 성공시켜서, 요령 없는 의사들이 마음 편히 개원할 수 있는 좋은 모델을 만들고 싶습니다."


오늘도 제가 제닥을 방문한 세 번째 의사였고, 이미 많은 의사들이 제닥의 모델을 눈 여겨 보고 있고 문의를 한다고 합니다. 아직은 과연 성공할 수 있는 모델인가 의심스러운 눈초리 절반, 한편으로는 너무나 이상적인 모델이라고 생각하시는 분이 절반이라고 하네요. 


사용자 삽입 이미지

<카페의 한쪽, 격리된 공간이 진료실이다>


병원을 방문해 본 사람이라면 누구나, 의료 상담을 원하는 환자와 검사를 이야기하는 의사 사이에서, 기대와는 다르다는 괴리감을 느낀 경험이 있을 겁니다. 객관적인 건강상태를 확인하기 위해 검사가 필요할 수 있겠지만, 자신의 건강 상태가 궁금해서 찾아온 환자에게 왜 검사가 필요한지 이해하고 동의 하에 검사가 원만하게 진행되는데 까지는 시간이 필요합니다. 하지만 현실에서는 이런 시간을 확보할 수 없어, 의사의 입장에서도 어려움이 많습니다.


이런 괴리감을 줄이고 언제든 가까이에서 의학 자문을 얻을 수 있는 제너럴닥터의 존재는, 어찌 보면 우리가 추구해야 할 1차 진료의 당연한 모습이라고 할 수 있습니다. 특히 1차 진료를 담당하는 병,의원 조차도 전문과목들로 나눠져 있는 경우가 대부분인 현실이기에 제닥의 존재는 의미하는 바가 큽니다.


"그 동안 제닥을 운영하며 생각한, 제닥이 제시하는 새로운 의료 환경의 의의를 몇 가지로 정리할 수 있습니다.  

환자 입장에서는, 체감 의료의 질적 향상입니다. 경제적으로는, 개인과 사회의 의료비 절감 효과도 있을 것입니다. 물론 제닥 하나로 의료비 절감을 만들어 준다는 것은 아니고, 제닥과 같은 의료 환경을 추구하는 의원들이 많아졌을 때 가능해지겠지요. 그 동안 소통이 잘 이루어지지 않아서 반복적이거나 불필요한 의료 소비, 검증되지 않은 의료기기나 건강식품에 들어가던 비용을 상당히 절감할 수 있을 겁니다. 

의사의 입장에서는 환자가 진정 마음을 담아 '선생님'이라고 부르는 의사로써의 삶의 질과 자존심 회복도 중요합니다. 그리고 놓칠 수 없는 것으로, 국가 의료 정책의 변화에 덜 민감한 안정적인 수익 구조의 창출이 가능하다는 것입니다. 보험 삭감 등의 경제적인 이유로 의사의 소신을 저버리지 않아도 된다는 것이 가장 큰 현실적인 이유가 되겠지요."


김 선생님의 말대로 더 많은 의사들이 참여해서 제너럴닥터 2호점, 3호점을 계속 만들어 나간다면, 새로운 흐름이 시작될 것 같습니다. 김승범 선생님은 앞서 언급한 의료 디자인을 하기 위해 올해부터는 본격적인 사업을 시작할 계획이라고 합니다.


사용자 삽입 이미지

<제너럴닥터의 내부 인테리어>


앞서 김승범 선생님을 열정을 가진 의사이자 사업가라고 말씀 드렸고, 직접 의료 디자인을 하고 있다고 언급하기도 했습니다. 구체적으로 어떤 일을 하고 있는지 물어보니, 매닉디자인이라는 의료디자인 회사를 운영하고 있다고 합니다. 과거에 사탕이 붙어있는 소아용 압설자 같은 독특한 아이디어로 특허를 받은 경험을 살려 의료디자인에 적극적으로 뛰어들게 되었다고 합니다.


"이 압설자는 학생시절인 본과 3학년 때 소아과 실습을 돌면서 생각한 아이디어입니다. 소아과 진료에 있어 아무리 의사가 상냥하고 친절하게 대해도 아이들은 엉엉 울기만 하더라고요. 하지만 재미있었던 것은 준비된 사탕은 절대 놓치지 않고 다 먹더란 말이죠.

어차피 다 입으로 들어가는 건데, 하나는 좋아하고, 하나는 별로 아픈 것도 아닌데 너무 싫어한다니. 두 가지를 합해서 의사에게  입을 벌려야 하는 이유를 만들어 주자고 생각했고, 제가 직접 시제품을 만들어 사용해 보니 기대 이상으로 효과가 좋았습니다."


이 사탕 압설자를 기반으로 한 의료 디자인 회사의 개념으로 2005년 원주시에 있는 원주 의료기기 테크노밸리에서 주최한 창업경진대회에서 수상한 경력도 있다고 합니다. 현재도 원주에 매닉디자인의 사무실을 운영하고 있습니다.


이 것만으로는 큰 수익이 나지는 않을 거라고 하지만, 소아과에서는 이와 같은 압설자를 필요로 하는 경우가 많을 거라며 2008년에는 적당한 공장을 찾아 대량 생산을 할 계획을 가지고 있다고 합니다. 그리고 이 압설자 못지 않게 당황스럽고 재미있는 소아과용 전자 청진기의 특허도 출원한 상태라고 하네요.


"매닉디자인은 단순히 의료기기를 만드는 회사가 아닙니다. 제닥처럼 새로운 의료환경과 새로운 수익모델을 디자인하는, 일종의 '종합적 의료 연구, 개발' 회사입니다. 진료의 효율성을 극대화시키면서도 인간성을 살릴 수 있는 것들이 될 것이고, 몇 가지 의료 도구들과 환경, 전자 차트와 같은 요소들이 주 개발 품목이 될 것입니다. 

그리고 제닥은 매닉디자인의 연구소이자 시험기관이 되어, 이런 구성 요소들을 적용한 네트워크 병원에 포함될 것입니다. 지금까지의 네트워크 병원들처럼, 환자에게 그럴듯한 이미지로 포장하고 막강한 비보험 서비스를 도입해 최대한의 수익을 내 보려고 하는 느슨한 네트워크 병원이 아니라, 환자와 의사가, 의사와 의사가 보다 폭넓게 소통할 수 있도록 규모 있는 환경을 만들기 위한 네트워크를 구상하고 있습니다."


환자와의 소통을 강조한 의료 네트워크 구성은 김 선생님의 여러 아이디어 중 하나라고 합니다. 진료실에서의 대화를 보충하고 진료실 밖에서 일어나는 일들도 케어할 수 있는 방법이 생긴다고 하면 상당히 좋을 것 같습니다. 개인적으로 상당히 기대가 되네요. 또한 같은 지역의 다른 과 전문의와 의학적 자문을 구할 수 있는 컨설팅 네트워크도 가능하도록 해 1차 진료의 강화를 도모하겠다는 포부도 현실화 되기만 한다면 환자들도 효율적으로 의원들을 이용하게 될 수 있을 것이라고 생각됩니다.


사용자 삽입 이미지

<직쩝 찍은 사진과 인테리어를 통해 남다른 디자인 감각을 엿볼 수 있다>


이미 김승범 선생님은 진료에 있어 가장 중요한 환자와의 커뮤니케이션에 있어서는 전문가로 생각됩니다. 오히려 많은 사람들에게 그러한 기술을 알려야 할 위치에 있다고 생각됩니다. 하지만 혼자서 모든 것을 할 수 없기에, 뜻이 맞는 선생님들이 제닥에 동참해주기를 원하고 있었습니다. 


"네트워크를 현실화하기 위해서, 그리고 매닉디자인을 발전시키기 위해서, 이제는 제닥에 동참하는 선생님을 찾아야 되겠다고 생각하고 있습니다. 월급을 받으며 편하게, 안정적으로 일하시면서도 환자들과 소통하는 자리라면 마다할 선생님이 없겠지만, 지금 제가 찾는 선생님은 말 그대로 '동참'하고 협력해 주실 선생님입니다. 

같은 꿈을 꾸며, 배고파도 이 길을 끝까지 같이 갈 용기를 가진 선생님이 한 분이라도 함께 하신다면 더욱 빠른 시간 내에 성과를 얻을 수 있을 것이라고 생각합니다. 양깡님도 주변에 좋은 선생님 있으시면 소개 좀 해주세요~"

관련글 : 제너럴닥터와 함께 할 선생님을 찾습니다.


사용자 삽입 이미지

<제너럴닥터의 현관>


제닥에는 환자와 카페 손님의 구별이 없다는 김승범 선생님. 그저 '사람'만 존재하고 그들은 환자 명단에 올라 있는 환자이자 단골이기도 하고, 근본적으로는 나의 친구라고 말하는 김 선생님이 무척 부러웠습니다. 


"저는 꿈을 가진다는 측면에서는 이상주의자이지만, 꿈을 이루려고 한다는 측면에서는 추진력 있는 현실적인 인간이라고 생각하고 싶습니다. 그래야 혼자서만 꾸는 꿈을 벗어나 세상을 조금이라도 좋게 만들 수 있을 테니까요. 

최근에 우연히 존레논의 부인이였던 오노 요코가 했다는 'A dream you dream alone is only a dream, but a dream you dream together is reality.'란 말을 알게 되었는데, 그 뒤로 이 말을 자꾸 되뇌게 되네요. 아마도 저의 상황과 어울리는 말인 것 같습니다. 저는 제 꿈을 절대로 그저 저만의 꿈으로만 남겨둔 채 살 수는 없기에 이렇게 살고 있으니까요."


사용자 삽입 이미지
<제너럴닥터 영업 시간 안내>


모든 병원이 제닥처럼 카페와 공유하는 진료실을 꾸밀 필요는 없습니다. 하지만 색다른 진료 환경을 선택할 수 있다는 것, 특히 질병이 없더라도 쉽게 의사와 건강에 대한 상담을 할 수 있는 진료 환경이라는 점에서 매우 긍정적이라고 생각됩니다. 해결해야할 부분도 있습니다. 응급질환이나 검사가 많이 필요한 전문 영역 진료와는 어울리기 어려운 의료 환경이란 점인데요, 그에 맞는 새로운 디자인도 연구중이라고 하니 기대를 해봐야겠지요.


이번 인터뷰를 통해 짚어볼 문제 중 하나는 소신 것 환자를 보면서 그 수익으로는 직원들 월급 주기도 어려운 우리 의료 현실입니다. 커피를 팔아 경제적인 부족함을 채워야하는 현실. 이와 같은 의료 현실이 진료의 질을 떨어뜨리고 잘못된 또는 하지 않아도 되는 의료 소비를 늘리는 것은 아닐지 잘 생각해볼 문제입니다.


의료는 본질적으로 인간적일 수 밖에 없는 행위임에도 현실에서는 인간성을 잃어버렸다고 이야기들 합니다. 제너럴닥터는 이런 현실 속에서 새로운 진료 패러다임을 제시하고 있는 것 같습니다. 그리고 저와 같은 의사들뿐 아니라, 환자와 그 가족들에게도 생각을 전환하면 새로운 세계가 보인다고 속삭이는 것 같습니다.


많은 의사들이 건강 보험등 의료 시스템의 왜곡을 이야기하면서도 진료실에서의 인간적 진료에 대해서 이야기하기에는 소극적인 것 같다는 반성도 해봅니다. 저도 예외가 아닙니다. 그런 면에 있어 일상과 함께하는 의료, 진정한 1차 진료를 실천하는 김승범 선생님께 박수를 보냅니다. 지금처럼 항상 도전하는 마음 간직하시고 언제나 지금처럼 행복하게 일하시기를 응원합니다.


추신. 홍대쪽 사시거나 홍대 앞을 지나가실 일 있으시다면 의원이자 카페인 제너럴닥터에 들러보세요. 김승범 선생님이 직접 내려준 커피가 꽤 맛있더군요. 커피값도 저렴합니다.
출처 : http://blog.daum.net/jong_kj/13809315




제너럴닥터... 참 재미있는 발상으로 시작한 병원인듯 하다.

요즘 처럼 환자 한명 진료하는데 1분도 안걸리는 대다수의 병원들 틈 속에서, 환자와 진정으로 소통함으로써

참된 의술을 전파하겠다는 김승범 원장님의 철학 또한 본받을만하다.

부족한 병원 수입을 보충하기 위해서 커피를 판다고 생각할 수도 있겠지만, 병원을 꼭 아플때만 가야 하는 것이

아니라, 커피 한잔 마시러 갔다가 의료 서비스를 체험하므로써, 치료보다는 예방에 좀 더 Focus를 맞춘 병원이

아닐까 생각된다.

그리고 아이들을 위해서 사용하는 "사탕 압설자"...  남녀노소를 불문하고 간혹 압설자가 입에 들어오는 순간

헛구역질이 나는 경험이 있을 것이다. 하지만, 사탕 압설자를 이용한다면 헛구역질을 많이 줄일수 있지 않을까??

아직 이 병원에서 진료를 받아보거나, 방문해보지는 못했지만, 환자들을 위해서 이런 세세한 것까지도 신경써

주는 병원이라면 한번쯤 가보고 싶다는 생각을 불러 일으키기에는 충분하다.

조만간 커피향이라도 만끽하러 가봐야 겠다...

'Happening' 카테고리의 다른 글

수동식 문서 분쇄기  (0) 2010.11.05
정보 습득에 여과 Filter를 달자  (0) 2010.10.11
성공이란 무엇인가?  (0) 2010.10.05
신념이란  (0) 2010.10.01
한국 교과서 왜곡도 일본 못지 않은듯...  (0) 2010.09.16
:     

TISTORY에 Login하려면 여기를 누르세요.


성공이란 무엇인가?

Happening 2010. 10. 5. 14:56
자주 그리고 많이 웃는 것

현명한 이에게 존경을 받고,

아이들에게서 사랑을 받는 것

정직한 비평가의 찬사를 듣고,

친구의 배반을 참아내는 것



아름다움을 식별할 줄 알며,

다른 사람에게서 최선의 것을 발견하는 것

건전한 아이를 낳든

한 뙈기의 정원을 가꾸든

사회의 환경을 개선하든

자기가 태어나기 전보다

세상을 조금이라도 살기 좋은 곳으로 만들어 놓고 떠나는 것

자신이 한때 이곳에서 살았음으로 해서

단 한 사람의 인생이라도 행복해지는 것


이것이 진정한 성공이다.

                                                                                                    - 랄프왈도 애머슨(R.Emerson) -


많은 사람들이 성공에 대해 갈망하고, 이를 위해 불철주야 질주하고 있다.

성공이라는 단어의 유혹을 감히 쉽게 뿌리치기 어려움 때문이 아닐런지...

막연히 성공한 사람들을 모방하기 보다는, 내가 진짜로 원하는 성공이 무엇인지를 고민해보는건 어떨까??

사람마다 개성이 제각기이듯, 성공의 모습 또한 제각각의 모습이지 않을까 싶다.

지금 이 순간 당신은 어떤 성공을 꿈꾸고 있나요??
:     

TISTORY에 Login하려면 여기를 누르세요.


신념이란

Happening 2010. 10. 1. 11:40
사용자 삽입 이미지

- "오리진이 되라"의 글 중 일부 발췌 -


지금 나에게 필요한 건 무엇보다도 "모든 불가능은 상상력으로 해결할 수 있다는 신념!", "그까이꺼 정신"이

가장 필요한게 아닐까 싶다.

새로운 것을 창조하려한다면 가장 필요한 요소일듯~
:     

TISTORY에 Login하려면 여기를 누르세요.


[ORA-28002] 사용자 계정의 암호가 만기될 것입니다.

Oracle 2010. 9. 29. 10:58
Oracle 11g R1 Window 32bit의 환경에서 확인한 내용입니다.

Oracle 10g 이하에서 DB Schema를 자동으로 생성해주는 Script를 만들어서 사용하고 있었던 터라,

Oracle 11g R1에서도 그대로 사용하여 DB Schema를 생성하고, Test를 하고 있었던 어느 날 갑자기

아래와 같은 Message가 나타납니다.

====================================================================
@> conn scott/tiger@david11g

ERROR:
ORA-28002: 7 일안에 암호가 만기될 것입니다
====================================================================

그래서 Oracle 9iR2와 Oracle 11g R1의 Profiles의 내용을 비교해 보았습니다.

[Oracle 9iR2]

SYS@david9i> select resource_name, limit
  2  from dba_profiles
  3  where profile = 'DEFAULT'
  4  and resource_type = 'PASSWORD';
RESOURCE_NAME                       LIMIT
-------------------------------- ----------------------------------------
FAILED_LOGIN_ATTEMPTS            UNLIMITED
PASSWORD_LIFE_TIME                 UNLIMITED
PASSWORD_REUSE_TIME             UNLIMITED
PASSWORD_REUSE_MAX              UNLIMITED
PASSWORD_VERIFY_FUNCTION      NULL
PASSWORD_LOCK_TIME                UNLIMITED
PASSWORD_GRACE_TIME             UNLIMITED
7 개의 행이 선택되었습니다.

[Oracle 11gR1]

SYS@david11g> select resource_name, limit
  2  from dba_profiles
  3  where profile = 'DEFAULT'
  4  and resource_type = 'PASSWORD';
RESOURCE_NAME                       LIMIT
-------------------------------- ----------------------------------------
FAILED_LOGIN_ATTEMPTS            10
PASSWORD_LIFE_TIME                 180
PASSWORD_REUSE_TIME              UNLIMITED
PASSWORD_REUSE_MAX              UNLIMITED
PASSWORD_VERIFY_FUNCTION      NULL
PASSWORD_LOCK_TIME               1
PASSWORD_GRACE_TIME              7

7 개의 행이 선택되었습니다.


Profile의 유형이 추가된 것을 제외하고, Profile가 Default인것만 비교해보았을 때,

위와 같이 빨간색으로 표시한 부분의 값들에 대한 Default Value가 변경되었습니다.

그럼 변경된 내용들이 어떤 의미가 있는지 확인해보겠습니다.

1. FAILED_LOGIN_ATTEMPTS : 로그인을 실패했을 경우에 대한 제한 횟수

2. PASSWORD_LIFE_TIME : 암호 변경 일수를 의미합니다. 180일 이후에는 암호가 Expired 상태가 됩니다.

3. PASSWORD_LOCK_TIME: 암호 잠김 시간을 의미합니다. (1/1440 으로 설정하면 1분동안 잠김)

4. PASSWORD_GRACE_TIME : 암호 변경 메세지를 출력 날짜를 의미합니다. 이 설정으로 인해 서두에서
                                             나타났던 "ORA-28002"이라는 Alert Message가 나타나는 것입니다.

추가적으로 변경되지 않은 3개의 Resource에 대해서 설명을 하자면,

PASSWORD_REUSE_TIME : 사용했던 암호를 다시 사용 가능한 기간을 의미합니다.

PASSWORD_REUSE_MAX : 사용했던 암호 기억 횟수를 의미합니다. 사용했던 암호를 재사용하지 못하도록
                                        하기 위함입니다.

PASSWORD_VERIFY_FUNCTION : 암호 복잡성 검사 함수를 사용을 하기 위함입니다.

만약, Profle의 값을 변경하고자 한다면 아래와 같이 간단하게 수정할 수 있습니다.

============================================================================
sys@david11g> alter profile default limit
  2  password_life_time unlimited;

프로파일이 변경되었습니다.

SYS@david11g> select resource_name, limit
  2  from dba_profiles
  3  where profile = 'DEFAULT'
  4  and resource_name = 'PASSWORD_LIFE_TIME'

RESOURCE_NAME                    LIMIT
-------------------------------- ----------------------------------------
PASSWORD_LIFE_TIME               UNLIMITED

============================================================================

:     

TISTORY에 Login하려면 여기를 누르세요.


TEXT INDEX의 META DATA를 CTXSYS USER에서 삭제하는 방법

Oracle 2010. 9. 22. 16:21

PURPOSE
--------------------------------------------------------------------------------------------------
Intermedia text 나 Oracle Text 를 사용할 때, Text index는 삭제되었는 데,  meta data가 삭제되지 않은
경우가 생긴다. 이런 경우, 수동으로 meta data 까지 모두 삭제하는 방법을 알아보자.

Explanation
--------------------------------------------------------------------------------------------------
이 방법은 잘못되는 경우 CTXSYS user를 다시 초기화 해야하는 문제가 발생할 수 있으므로 이를 감안하여
작업해야 한다.

수동으로 삭제하는 방법은 다음과 같은 절차를 이용하여 작업할 수 있다.

1. 먼저 해당 user에서 다음과 같은 command로 index를 drop 해 본다.
SQL> drop index INDEX_NAME force;

2. drop command로 drop이 정상적으로 되지 않으면 다음과 같이 실행한다.
sqlplus ctxsys/ctxsys

select idx_id from dr$index where idx_name='<TEXT_INDEX_NAME>';
=> 조회된 index id가 1092 인 경우 아래와 같이 실행한다.

delete from dr$index_value where IXV_IDX_ID = 1092;
delete from dr$index_object where IXO_IDX_ID = 1092;
delete from dr$index where idx_id = 1092;
commit;

3. Text index를 생성한 user에서 DR$<index_name>$i 이름의 TABLE을 모두 다음과 같이 drop한다.
SQL> drop table dr$<index_name>$i;
SQL> drop table dr$<index_name>$k;
SQL> drop table dr$<index_name>$n;
SQL> drop table dr$<index_name>$r;

4. 이제 해당 Text index를 다시 생성하면 된다.

Reference Documents
--------------------------------------------------------------------------------------------------
<Note:133482.1>

:     

TISTORY에 Login하려면 여기를 누르세요.


UGA MEMORY LEAK 에러인 ORA-600[729] ERROR에 대한 이해

Oracle 2010. 9. 20. 12:45
PURPOSE

이 문서는 오라클 shadow 프로세스에게 할당되었던 메모리를 free 하는 과정에서 만날 수 있는
memory leak problem 에 대해서 소개하고자 한다. 메모리 leak dump 는 주로 session 이 logoff하는
과정에서 만날 수 있는 것으로서 user process에게 할당되었다가 사용된 heap을
ORACLE 서버가 free할 때 발생하는 것이다.

Problem Description

alert log 및 트레이스 화일에는 이와 같은 에러가 남게 된다.

ORA-00600: internal error code, arguments: [729], [560], [space leak], [], [], [], [], []


Explanation

Heap dump의 내용과 어떤 경우에 이런 에러가 발생하는지에 대해 좀 더 자세히 알아보기로 한다.

Oracle이 process를 종료하면, 점유하였던 메모리와 release되는 memory를 비교하여
size가 정확히 일치하지 않으면 ora-600[729] 에러를 발생시키고, shutdown 시에 SGA 등을
모두 release하고 일부 메모리 영역이 여전히 남아있으면 ora-600[730]을 report하게 된다.

User가 oracle에 접속하면 user process가 생성이 되고, 각 user process마다 heap이 할당된다.
모든 프로세스들은 자신의 memory heap을 갖게 된다.
Heap을 구성하는 각 extent는 연속적인 chunk로 이루어져 있는데, 이러한 chunk들은 각각
다음과 같은 type들을 가질 수 있다.

1. FREE : free chunk는 heap manager가 다시 할당할 수 있는 비어있는 부분.
Free 영역은 할당된 chunk가 해제가 된 상태로 이것은 인접한 free chunk들과
merge한 다음에 Free list에 등록된다.

2. FREEABLE : freeable은 flush를 시켜서 다시 merge를 할 수 있는 후보.
SYS.X$KSMSP를 조회하면 freeable space에 대한 조각을 확인할 수 있다.

3. RECREATABLE : memory chunk가 heap에 할당될 때, chunk의 내용이 재생성가능한 것으로
명시할 수 있다. 이러한 option으로 생성되면, 이 chunk는 사용 중이지 않을 때 명시적으로
'unpinned'될 수 있다. 사용자가 heap으로부터 space를 요청할 때 공간이 없으면,
이러한 unpinned 혹은 recreatable chunk를 해제하고 사용할 수 있다.
Unpinned chunk는 LRU list에 존재하게 되어 무엇을 가장 먼저 비게 할 것인지 결정할 수
있으며, 이러한 방법은 row cache나 library cache에 이용된다.

4. PERMANENT : 이 영역은 일단 할당되면 해제되지 않는 메모리 부분인데, 각 heap descriptor는
이러한 permanent chunk 부분을 가리키는 pointer를 갖고 있다.
이 permanent chunk는 두 부분으로 나누어지는데, 앞 부분은 이미 permanent로 할당된
메모리 부분이고, 뒷 부분은 아직 할당되지 않은 reserved area 이다.
Chunk의 header에는 어느 부분부터가 reserved area의 시작인지 나타내는 pointer가 있다.
실제 permanent 메모리는 프로세스가 종료하여 heap 자체가 해제되면 그 영역도 해제가 된다.

5. FREEABLE WITH MARK

Permanent 메모리 영역을 해제할 때 완전히 free 시키지 않고, Freeable with MARK 상태로
두었다가 다시 restore 하기도 하는데, 이 chunk type은 oracle 10g 에서는 널리 알려져
있지는 않다.

[ Extent의 할당과 해제 ]

연속된 chunk들의 집합을 extent라고 한다.
즉, heap에 포함되어 있는 extent들의 집합 안에서 요청한 크기의 조각을 할당받게 된다.
만약 이 때 발견하지 못하면, heap manager는 새로운 extent를 요청하여 이것을 heap에 추가한다.

각 extent는 오직 한 종류의 chunk type만 갖는 것이 아니고, 다양한 type의 chunk를 가질 수 있다.
프로세스가 memory chunk를 요청할 때 heap manager는 필요한 size 만큼의 공간을 할당해 준다.
프로세스가 종료하면 프로세스에게 할당되었던 모든 메모리는 자동으로 release가 된다.
프로세스 종료(logoff) 시 RECREATABLE chunk와 FREEABLE chunk는 FREELIST 로 등록되었다고
판단을 하고, 메모리가 release될 때 아직 남아 있는 할당된 heap들은 free가 되는데,
ORACLE server 입장에서는 일반적으로 heap이 free가 될 때 PERMANENT chunk로 할당된 chunk와
freelist 상에 있는 FREE chunk들을 free시킬 대상으로 삼는다.

프로세스가 FREEABLE 혹은 RECREATABLE type 으로 남아 있는 chunk를 발견한 경우는
해당 프로세스가 memory deallcation 을 제대로 수행하지 않았다는 것을 의미하게 된다.
이러한 상황을 space leak 이라 부른다.
오라클은 일반적으로 SGA heap, UGA heap, Large pool heap, 그리고, PGA heap에 대해
space leak을 check한다. Space leak error는 BACKGROUND_DUMP_DEST 또는
USER_DUMP_DEST 내에 trace file 안에 남게 된다.

Symptoms

Space leak problem은 일반적으로 trace information과 heap dump를 capture하여 떨어뜨리게 된다.
OS와 ORACLE process header 정보 다음에 trace file 내에 이와 같은 정보를 볼 수 있다.

*** 2006-10-03 18:43:11.598
*** SESSION ID:(34.50354) 2006-10-03 18:43:11.597
******** ERROR: UGA memory leak detected 560 ********

바로 위 라인을 보면 이 memory leak 은 UGA 영역에서 발생한 것이고, leak이 일어난 size는
560 bytes임을 알 수 있다.

Heap은 연속된 chunk의 집합으로 이루어지고, heap이란 heap descriptor와 extent라고 불리는
메모리 조각의 집합으로 구성되며, 각 extent는 연속된 메모리 조각으로 정의가 된다.

******************************************************
HEAP DUMP heap name="session heap" desc=0xaef81d0
extent sz=0xffb8 alt=32767 het=32767 rec=0 flg=3 opc=3
parent=0xaeb63e0 owner=0x7a4b7078 nex=(nil) xsz=0xffb8

위 dump에서 heap name은 SESSION HEAP 이고, Heap descriptor는 0xaef81d0 임을 알 수 있다.

아래의 extent 상세 정보를 보면 release되지 않은 chunk는 4085a350임을 나타낸다.
이것은 recreatable chunk이고, 그 size는 560 bytes이다. 이 수치는 [729], [560], [space leak]
에러에 나타난 bytes와 수치가 정확히 일치한다.

EXTENT 0 addr=0x407cf048
Chunk 407cf050 sz= 65456 free " "
EXTENT 1 addr=0x408a0048
Chunk 408a0050 sz= 65456 free " "
EXTENT 2 addr=0x40890048
Chunk 40890050 sz= 65456 free " "
EXTENT 3 addr=0x40850048
Chunk 40850050 sz= 41728 free " "
Chunk 4085a350 sz= 560 recreate "bind var heap " latch=(nil)
EXTENT 4 addr=0x407df048
Chunk 407df050 sz= 65456 free " "
EXTENT 5 addr=0x40f91048
Chunk 40f91050 sz= 65456 free " "
EXTENT 6 addr=0x40880048
Chunk 40880050 sz= 65456 free " "
EXTENT 7 addr=0x40870048
Chunk 40870050 sz= 65456 free " "

메모리 leak issue를 분석할 때 FREEABLE과 RECREATABLE type의 chunk를 식별해야 한다.
그 수치는 에러의 arguments에 나타난 leak 현상을 보이는 memory bytes의 sum 과 일치해야 한다.

원인

ora-600[729] error는 memory leak 현상으로 발생하는 오라클 에러라 할 수 있다.
그러나, 이러한 현상은 정상적인 경우도 발생할 수 있으며, 지속적으로 반복적으로 발생하여
memory free 영역이 계속 줄어드는 현상으로 나타나지 않는 한, 특별히 문제 시 되지 않으며,
일정 사이즈 이하의 leak은 message로 나타나게 하지 않도록 조치할 수 있다.


Workaround

아래의 예는 2M 이하의 leak 발생 시 에러가 나지 않게 하는 것으로, 만약 100k정도나 1~2M 이하의
leak 문제가 보인다면 발생하지 않게 이와 같이 셋팅할 수 있다.

event="10262 trace name context forever, level 2000000"


Solution Description

Space leak 문제를 어떻게 다룰지에 대해 자세한 사항은 다음의 문서에서 안내하고 있다.

Step 1. alert log를 review하고, trace file 정보를 분석해야 한다.
alert log 에는 이와 같은 에러가 남았을 것이다.

Sat Dec 02 21:52:17 2006
Errors in file d:\oracle\admin\testdb\udump\testdb_ora_5928.trc:
ORA-00600: internal error code, arguments: [729], [152], [space leak], [], [], [], [], []

a. argument [729]는 space leak 문제 발생 시 대표적인 에러 code이다.
b. argument [152]는 에러에 보고된 leak된 bytes의 수치이다.
c. argument [space leak] 는 항상 space leak 으로 나타난다.

Step 2. 연관된 트레이스 화일 분석

일반적인 trace information은 다음과 같다.

*** 2006-12-13 02:01:13.859
*** SESSION ID:(54.11635) 2006-12-13 02:01:13.859
******** ERROR: UGA memory leak detected 152 ********
******************************************************

위 트레이스는 UGA로부터 leak된 메모리라는 것과 memory leak의 size가 152 bytes 라는 것을
의미한다.


Step 3. leak이 session logoff로부터 발생했다는 것을 확인한다.

Call Stack Trace 부분을 보면 opilof 가 stack 상에 보인다면 이것은 session logoff 시
발생했음을 알 수 있다.
실제 발생한 call stack trace의 예는 다음과 같다.

Call Stack Trace
==========
calling call entry argument values in hex
location type point (? means dubious value)
========= ======== ============ ==============
ksedmp()+184 ? ksedst() 800000010000B938 ?
ksfdmp()+32 ? ksedmp() 800003FFBFFF6418 ?
kgeriv()+152 ? ksfdmp() 20000000B168 ?
kgesiv()+132 ? kgeriv() 40000000000002D9 ?
ksesic2()+124 ? kgesiv() 000000000 ?
ksmuhe()+1040 ? ksesic2() 000000000 ?
ksmugf()+400 ? ksmuhe() 000000000 ?
ksuxds()+2692 ? ksmugf() 800003FFBFFF4020 ?
ksudel()+104 ? ksuxds() 8000000100131B38 ?
opilof()+876 ? ksudel() 800003FFBFFF5808 ?
opiodr()+2416 ? opilof() 0650AB9D8 ?
ttcpip()+1320 ? opiodr() 8000000100004790 ?
opitsk()+1260 ? ttcpip() 000000100 ?
opiino()+1484 ? opitsk() 8000000100138268 ?
opiodr()+2416 ? opiino() 000001560 ?
opidrv()+752 ? opiodr() 800003FFBFFF0870 ?
sou2o()+40 ? opidrv() 000000000 ?
main()+228 ? sou2o() 000000000 ?

Step 4. Dedicated Server인지, MTS 환경인지 확인한다.

1) 만약 Dedicated server 환경이라면 이 error의 impact은 process가 종료할 때 끝날 것이다.
사실 에러의 영향도는 거의 없고, 데이타베이스에 실질적인 문제는 없을 것이다.
2) MTS(Multi Threaded Server) 환경이거나 XA transaction process manager/monitor를 사용하는 환경이라면
leaked memory가 SGA 영역에 있을 것이다. 이 때에는 ora-4030, ora-4031 과 같은 다른 에러가 발생했는지
alert log를 보아야 한다.

Step 5. Leak problem을 무시할 수 있는가 ?

1) 이 물음에 대해서는 다른 에러는 없는지 우선 살펴보아야 한다. 만약 동시에 발생한 다른 에러가 전혀 없다면
이 에러는 무시해도 되고, 다시 재현하기가 쉽지 않은 case일 것이다. 무엇보다도 90,000 bytes 보다 작은
size의 leak은 중요하지 않다. 이에 대한 solution은 event 10262 를 셋팅하는 것이다.

2) 만약 leak이 SGA 내에 발생했는가?
ALERT log를 살펴보고, shared pool 이나 OS memory 와 관련한 추가적인 문제는 없는지 ORA-4030 또는
ORA-4031 발생 여부를 확인해야 한다.

3) 메모리 leak 현상이 특정 작업을 수행 시에 재현이 되는가?
만약 특정 작업 시에 재현이 된다면, leak 현상이 known bug인지 확인을 위해
추가적인 investigation이 필요한 경우이다.
다음 문서를 보면 known bug 와 fix된 version들을 확인할 수 있다.

Note 31056.1 ORA-600 [729] UGA Space Leak for a list of known bugs and fixes

Step 6. Event 10262 셋팅하기

만일 leak된 bytes 수치가 무시해도 될 만한 수치라는 것이 확인이 되면, 이 에러를
무시하기 위해 event를 걸 수 있다.

이 event를 셋팅을 하게 되면 90,000 bytes보다 작은 크기의 leak에 대해서는 alert log에 나타나지 않게 할 수 있다.

a. 다음과 같이 initSID.ora file에 event를 셋팅한다.

event="10262 trace name context forever, level 90000"

b. 데이타베이스를 restart해야 event가 효력을 미친다.

[ 참고 ]

만일 level 을 1로 하게 되면, space leak checking이 disable된다. 1로 하게 되면 매우
큰 사이즈의 memory leak을 놓칠 수 있으므로, 권장하지 않는다.
Level 을 1보다 큰 수로 하게 되면 event 안에 명시된 숫자보다 작은 memory leak에
대해서는 무시하도록 하는 역할을 한다.

Reference documents

<Note:403584.1> Understanding and Diagnosing ORA-600 [729] Space Leak Errors

출처 : http://j.mp/cRNlnc


Oracle 11gR1 11.1.0.6의 Memory Leak Bug와 연관하여, Memory Leak Error에 대한 이해를 돕기 위한

문서입니다.

:     

TISTORY에 Login하려면 여기를 누르세요.


인증되지 않은 TOOLS 의 ACCESS 제한하기

Oracle 2010. 9. 16. 16:53

PURPOSE
이 자료는 Database 에 인증되지 않은 tools 의 접근을 막는 방법에 대한 설명이다.


Explanation

SQL*Plus 나 기타 다른 tools 의 접속을 제한할 필요가 발생할 수 있다.

단지 지정한 tools 만 사용하는 user 만 access 허용을 원한다면
예를 들어, forms 나 Reports 또는 다른 tools 만 사용하는 환경에서 SQL*Plus 나
다른 software 의 tools 을 사용하는 end user 의 접속을
제한하고, 단지 인증된 tools 만
접속이 되도록 하려고 한다.


그럴 경우에 PRODUCT_USER_PROFILE 테이블을 사용하여 SQL*PLUS 을 실행하는 session에
제한을 넣을 수 있다. 어떻게 수행되는지는 <Note:2181.1>를
참조해 보면 된다.


그러나 이 제한은 단지 SQL*PLUS 에서만 작동하고 다른 tools 에서는 동작을 하지 않을 수도 있다. Oracle8i 에서는 logon trigger를 이용하면 이 기능을 사용할 수 있다.

Example
인증되지 않은 access 를 검사하는 테이블을 생성한다.


SQL> conn sys/manager

Connected.


SQL> DROP TABLE LOGONAUDITTABLE CASCADE CONSTRAINTS;


SQL> CREATE TABLE LOGONAUDITTABLE (

EVENT VARCHAR2 (10),

TIMESTAMP DATE,

SCHEMA VARCHAR2 (30),

OSUSERID VARCHAR2 (30),

MACHINENAME VARCHAR2 (64),

SID NUMBER,

SERIAL# NUMBER,

PROGRAM VARCHAR2 (100));


Table created.


scott schema 에 아래의 trigger를 생성한다.


SQL> CREATE OR REPLACE TRIGGER logonauditing

AFTER LOGON ON scott.SCHEMA

DECLARE

machinename VARCHAR2(64);

osuserid VARCHAR2(30);

sid NUMBER;

serial# NUMBER;

program VARCHAR2(100);

CURSOR c1 IS

SELECT osuser, machine , sid , serial# , program

FROM v$session

WHERE audsid = USERENV( 'sessionid' );

BEGIN

DELETE LOGONAUDITTABLE;

COMMIT;

OPEN c1;

FETCH c1 INTO osuserid, machinename, sid , serial# , program ;


INSERT INTO LOGONAUDITTABLE VALUES ( 'LOGON', SYSDATE,

USER, osuserid, machinename , sid , serial#, program);


CLOSE c1;

COMMIT;

dbms_job.isubmit(12345,'sys.killsession;',SYSDATE);

END;


Trigger created.


log on trigger로부터는 같은 session 을 kill 시킬 수는 없다. 이 SESSION은 DBMS_JOB PACKAGE를
사용하여 매 10 초마다 해당하는 SESSION 을 찾아서
KILL 시키는 SCHEDULING 을 걸어서
사용할 수 있다.


sys 나 system schema로 아래의 procedure를 생성한다.


SQL> conn sys/manager

Connected.

SQL> CREATE OR REPLACE PROCEDURE KILLSESSION AS

sid NUMBER;

serial# NUMBER;

timestamp DATE;

CURSOR c1 IS SELECT sid , serial# , timestamp FROM scott.LOGONAUDITTABLE WHERE

INSTR(UPPER(program),UPPER('C:\Documents and Settings\All Users\시작 메뉴\프')) > 0;

/* 위의 부분에서 session 의 program column 값에서 원하는 application 의 value를 지정한다. */

BEGIN

FOR i1 IN c1 LOOP

dbms_output.put_line('alter system kill session ' ||''''||i1.sid||','||i1.serial#||'''');

execute IMMEDIATE 'alter system kill session ' ||''''||i1.sid||','||i1.serial#||'''';

DELETE scott.LOGONAUDITTABLE WHERE sid = i1.sid AND serial#=i1.serial# AND timestamp = i1.timestamp;

END LOOP;

COMMIT;

END;

Procedure created.


위의 procedure를 수행하기 위해서는 init.ora 파일에 아래의 parameters를 적용해 주어야 한다.


job_queue_process = 1

job_queue_interval = 10


위와 같이 setting 을 하면 아래의 PL/SQL block 을 사용하여 인증되지 않은 sessions 들을
매 10 초 마다 KILLSESSION procedure 를 fire시킬 수 있다.


SQL> connect sys/manager

begin

    dbms_job.isubmit(2345,'KILLSESSION;',sysdate,'sysdate+1/(24*60*6)');

end;


위의 명령을 실행하면 Client sqlplus 에서 아래의 메시지가 떨어진다.


SQL> select * from logonaudittable;


EVENT TIMESTAMP SCHEMA OSUSERID
------------------ ------------------------------

MACHINENAME SID SERIAL#
---------
PROGRAM


LOGON 03-FEB-03 SCOTT Administrator

BKCHEON 11 43911

C:\Documents and Settings\Administrator\시작 메

LOGON 03-FEB-03 SCOTT Administrator

BKCHEON 11 43923

C:\Documents and Settings\All Users\시작 메뉴\프


LOGON 03-FEB-03 SCOTT Administrator

BKCHEON 15 55572

C:\Documents and Settings\All Users\시작 메뉴\프

SQL> select * from tab;

select * from tab

*

ERROR at line 1:

ORA-00028: your session has been killed


Reference Documents


NOTE:105438.1

Note:70679.1 PL/SQL Example: How to Audit Logon Events with Triggers


원본 위치 <http://kr.forums.oracle.com/forums/thread.jspa?threadID=473589&tstart=150>

:     

TISTORY에 Login하려면 여기를 누르세요.

◀ PREV : [1] : [···] : [3] : [4] : [5] : [6] : [7] : [8] : [9] : NEXT ▶