2008년 3월 24 ~ 26일 미국 간증부흥집회
2008년 3월24일 첫날 저녁집회 1부 입니다.
2008년 3월24일 첫째날 저녁집회 2부 입니다.
2008년 3월 25일 둘째날 저녁집회 1부 입니다.
2008년 3월25일 둘째날 저녁집회 2부 입니다.
2008년 3월26일 셋째날 저녁 집회 1부입니다.
2008년 3월26일 셋째날 저녁집회 2부 입니다.
2008년 3월24일 첫날 저녁집회 1부 MP3.
2008년 3월24일 첫째날 저녁집회 2부 MP3.
[출처] 박보영목사님 간증부흥집회 |작성자 선한 길
아키텍트로서 성장하기 위한 길은 막막하게 느껴지곤 한다. 누구에게 아키텍트로서 가야 하는 길을 물어야 할 것인가? 산전수전 다 겪은 나이가 지긋한 아키텍트로 활동 중인 사람을 만나기란 하늘의 별따기다. 따라서 필자는 업계 최고의 아키텍트들의 조언을 모아 가상의 인터뷰를 진행해 봤다. 이 인터뷰의 내용은 필자가 PLoP라는 패턴학회에서 만난 해외 거장들과의 토론과 조만간 출간될 번역서인 『아키텍트가 알아야 할 97가지』의 내용을 모아 만들었다.
손영수 안녕하십니까? 여러 선배님들. 아직 ‘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
거울로 보이는 문제는 실제 보이는 것보다 클 수 있습니다. 많은 소프트웨어 프로젝트에 참여했던 그 동안의 경험에 비춰 보면, 각 팀의 구성원들은 팀이 예상한 것보다 더 많은 문제를 가지고 있습니다. 소규모의 팀은 이런 문제들을 초기에 확인할 수 있지만, 대부분 잊어버리거나 무시합니다. 그 이유는 프로젝트 초기에는 이 문제가 얼마나 프로젝트 후기에 큰 영향을 미치는지를 이해하지 못하기 때문입니다. 이러한 문제를 초기에 대처하기 위한 몇 가지 전략이 있는데 다음과 같습니다.
그 후 리스크들에 우선순위를 매기고 리스크의 상태가 변화하거나 새로운 정보가 있을 때마다 리뷰를 합니다. 리뷰는 토론를 통해 감정적인 면을 배제하도록 도와주고 주기적으로 리스크를 재평가함으로써 쉽게 기억하도록 도와줍니다.
손영수 개발 도중에도 아키텍처만 그려주고 사라지는 아키텍트가 아닌, 팀원 간 또는 이해당사자 간에 소통이 잘되는 문화를 만들고 잘못된 방향으로 흘러가면 가이드해서 바로 잡아야 한다는 조언이군요. 그럼 아키텍트가 가져야 할 자세에 대해서도 조언 바랍니다.
아키텍트로서 갖춰야 할 자세
Dave Quick 아키텍트는 자신이 최고라는 대문자 ‘I’보다는, 일원이라는 의미를 가지는 소문자 ‘i’의 자세가 필요합니다. 아키텍처를 수립할 때, 여러분 스스로가 최악의 적이 될 수도 있습니다. 여러분이 고객보다 요구사항을 더 잘 이해한다고 생각하거나, 개발자를 아이디어를 구현하기 위한 단순한 자원으로 보거나, 여러분의 생각에 도전하는 개발자나 팀원을 무시한 경험이 있습니까? 성공이나 사회적 지위로 인해 자만하거나 다른 사람들이 우리를 존경한다는 착각을 가지고 있고, 자신이 만든 설계에 도전하는 것을 여러분 자신의 인격에 대한 도전으로 받아들인 경험이 있을 것입니다. 이것은 과거의 성공에 빠져 여러분을 더 작은 한계에 가두는 짓입니다.
아키텍트로서 스스로 성장하고 성공하는 프로젝트를 만들기 위해서는 여러분의 마음가짐을 바꿔야 합니다. 전 후배 여러분들에게 다음과 같은 자세를 요구합니다.
손영수 저도 그렇게 생각합니다. 제가 소문으로 들었던 몇몇 아키텍트들은 많은 반대에도 불구하고 자신의 생각을 관철시키곤 했습니다. 설계 자체의 옳고 그름을 떠나 개발자들과 소통 없이 일방적으로 자신의 생각을 강요했죠. 그 결과로 설계 따로, 개발 따로 하는 프로젝트가 되었다는 이야기를 들었습니다. 개발자를 이해하는 아키텍트, 그리고 아키텍트를 이해하는 개발자들이 모여야 정말 좋은 프로젝트로 갈 수 있을 것입니다. 마음가짐에 대한 또 다른 의견도 듣고 싶습니다.
David Bartlett 아키텍트는 쇼맨십을 뛰어넘는 가치 있는 청지기 의식(Stewardship)을 가져야 합니다.
아키텍트들은 프로젝트에 착수할 때, 자신의 가치를 입증하려는 갈망이 있죠.
소프트웨어 회사에서 아키텍트 역할을 맡는다는 것은 아키텍트의 기술적 리더십을 회사의 일부분으로 절대 신뢰한다는 의미입니다.
그런데 불행히도 자신의 가치를 입증하기 위해 개인의 기술적 탁월함과 쇼맨십으로 팀원들을 이끌어야 한다고 오해하는 아키텍트들이 있습니다. 사람들에게 어필하는 행동인 쇼맨십은 마케팅에서는 중요할지도 모릅니다. 하지만 소프트웨어 개발 프로젝트에 있어서는 역효과를 나타낼 뿐입니다.
아키텍트는 확고한 리더십으로 그들 팀의 존경을 얻어야만 하고 기술과 팀이 운영하는 비즈니스 도메인의 이해가 있어야 합니다. 책임지고 다른 이들을 돌보는 청지기 의식은 아키텍트에게 꼭 필요한 자질입니다. 아키텍트는 고객을 위해 최선을 다해야 하지, 고객의 요구를 이용하려고 해서는 안 됩니다.
소프트웨어 아키텍처는 고객의 요구들을 수행하는 것으로, 보통 탁월한 능력을 소유한 도메인 전문가의 방향 제시로 이뤄집니다. 성공적인 소프트웨어 개발을 추구하는 것은 아키텍트가 프로젝트에 주어진 시간과 노력에 대비해 구현의 복잡성과 비용 사이에 균형이 잡힌 절충된 솔루션을 만들게 합니다.
최신의 따끈따끈한 프레임워크나 기술 전문 유행어로 이뤄진 과도하게 복잡한 시스템은 비용 지출의 희생을 담보로 합니다. 아키텍트의 활동은 투자 브로커처럼 합리적인 ROI(투자 대비 수익률)를 창출할 수 있다는 전제 하에 고객의 돈을 사용하도록 해야 합니다. 여러분이 다른 사람의 돈을 사용하고 있음을 절대 잊어버려서는 안 됩니다.
손영수 아키텍트 명함을 가지고 다니는 사람들 중에는 신기술로 도배된 제품을 팔기 위한 비즈니스맨인지, 아키텍트인지 구분하기 힘든 이들이 있습니다. 청지기 의식이라는 것을 통해 많은 것을 되돌아보게 되었습니다.
지금까지 여러분의 소중한 조언을 들을 수 있었습니다. 설계만 잘하기 위한 공학적인 기법만큼 외부와 소통 및 협상하고, 팀원들을 이끄는 정신도 중요하다는 것을 깨우치는 시간이 되었습니다. 이 가상 인터뷰가 아키텍트를 꿈꾸는 많은 이들에게 유용한 시작점이 되었으면 합니다.
[출처] 데브피아 | 12명의 아키텍트에게 물어본 "아키텍트의 길!"
뭐.. 보는 사람에 따라 여러 가지 차이를 말할 수 있겠지만,
내가 생각하는 차이를 한 번 적어본다.
가장 중요한 차이는 바로 남자주인공의 자세라 할 수 있다.
어떤 면에서?
이전의 신데렐라 드라마에서의 남자 주인공들은 조금은 비현실적인, 어쩌면 정말로 여자들이 환상속에서 그리고 있는 모습이라고도 볼 수 있는 모습을 보여주고 있다. 그들은 재벌가의 아들이라는 신분으로 인한 많은 제약들에 답답해 하고 자유로운 세계를 꿈꾸며 현실에서 벗어나고자 하는 마음이 가득하고, 자신에게 엄청난 재산과 기업의 총수 자리를 상속하려는 부모에게 반항하고자 하고, 정략 결혼이 싫어 운명적인 만남을 꿈꾸는 남자들이다.
그들은 이러저러한 사건들을 통하여 여자 주인공을 만나게 되고, 그들의 자유로운 생활과 치열하게 살아가는 모습에 매료되어 사랑에 빠진다. 한 번 사랑에 빠지면 그 남자는 이제 눈에 뵈는 게 없고, 오로지 여자 주인공을 감싸고 돌며 모든 외부로부터의 어려움을 극복하고 결국 그들의 스토리는 해피 엔딩으로 마무리 된다.
이러한 남자주인공의 모습으로 인하여 드라마는 2단계의 스토리로 이루어진다.
1. 남자주인공과 여자주인공이 사랑에 빠진다.
2. 이 커플은 외부로부터의 모든 압박을 이겨내고 해피 엔딩
그러나 시크릿 가든에서는 1과 2 사이에 하나의 단계가 더 들어가는데 그것은
'자기 자신의 변화' 이다.
그래서 시크릿가든은 3단계의 스토리로 이루어진다.
1. 남자주인공과 여자주인공이 사랑에 빠진다.
2. 남자주인공의 내적인 변화
3. 이 커플은 외부로부터의 모든 압박을 이겨내고 해피 엔딩
(10화까지 방영된 현재로서는 2번의 과정을 지나가고 있으며 3번 요소는 아주 약하게 표출되고 있다. 하지만 신분이 매우 다른 남녀가 만남에서 엔딩으로 가는데 있어서 3번의 과정은 필수 요소이므로 시크릿 가든 후반부의 주요 스토리를 이룰 것이라 생각된다.)
그러면 남자주인공의 내적인 변화라는 것은 무엇인가?
다시 한 번 말하지만 시크릿 가든의 남자 주인공 김주원은 이전의 신데렐라 드라마의 남자 주인공들과는 다른 삶의 자세를 보여주고 있다. 재벌집 아들로서 가질만한 아주 현실적인 모습이다.
그는 자신의 신분에 만족해 하고 있으며, 철저한 재벌집 아들의 사고방식을 가지고 살고 있고, 길라임을 만나기 전까지는 자신과 다르게 살아가는 사람들의 삶의 방식을 굳이 이해하려 하지 않았으며, 정략결혼도 삶에 그다지 나쁠게 없는, 아니 오히려 결혼을 기업 M&A에 버금가는 일생일대의 비지니스로 생각하고 있다.
자신의 모습과 상황에 대해 그다지 불만이 없기 때문에, (아니 만족하고 있기 때문에) 그는 자신의 모습을 버리고 싶어하지 않는다. 그렇기 때문에 여자 주인공을 위해 모든 것을 버릴 이유가 없으며 여자 주인공으로 인해 눈에 뵈는 게 없는 상황으로는 치닫지 않는다.
(그래서 그는 자신의 현실과 감정의 차이를 메울 타협점을 찾는다.)
이전까지의 남자 주인공들은 자기 자신을 벗어나고 싶어했기 때문에 여자 주인공의 사고방식과 삶의 모습을 그렇게 쉽게 받아들인 반면, 시크릿 가든의 김주원은 여자 주인공의 사고방식과 삶의 모습을 쉽게 받아들일 수가 없고 자기 자신도 그 안으로 쉽게 빨려들어가지 못한다.
10화만 봐도 그런 모습이 제대로 나오는데, 이전의 남자 주인공들을 상상해 보라. 이전의 남자 주인공들 같았으면 자신이 평소에 경험할 수 없는 액션 촬영 현장에서 연기에 푹 빠져도 보고 진흙탕에 굴러도 보고 형편없는 도시락도 먹어보며 색다른 그 삶의 현장을 즐겼을 것이다. (그러면서 여자 주인공에 대해 더욱 사랑이 깊어지고 여자 주인공은 그런 남자 주인공의 평소와는 다른 모습에 감동하는..) 그러나 김주원은 계속해서 그 속에 녹아들지 못한다. 그는 여전히 액션 배우로서는 발연기를 하며, 진흙탕에 쓰러질 수 없어 다른 이 위에 눕고, 원산지가 불분명한 도시락은 입에 대고 싶지조차 않다. 그가 거기에 있는 이유는 오직 길라임이 거기 있기 때문이다.
그리고 그는 끊임없이 질문한다. 그런 삶이 뭐가 좋냐고? 그리고 길라임으로부터 쓴소리가 섞인 대답만 계속 듣게 된다.
그런 질문들은 김주원이 자신과는 다른 사람들의 삶을 이해하기 위한 과정들이다. 그는 자기로서는 이해할 수 없었던, 그리고 그다지 알고 싶거나 이해하고 싶지도 않았던 삶을 길라임을 통해 이해해 가는 과정인 것이다. 그리고 재벌집 아들로서의 사고방식으로부터 벗어나 평범한 사람들의 삶을 생각할 수 있는 사고방식으로 변화해 나간다. 이것이 바로 남자주인공의 내적인 변화이다.
이렇게 현실적인 남자 주인공의 모습 때문에 드라마의 스토리도 현실적인 모습을 보여주게 된다. (물론 영혼이 바뀐다는 설정은 비현실적이지만..) 한 사람이 한 사람을 이해해 나가는 모습을 제대로 보여주고 있는 것이다.
가끔 이런 질문 듣지 않나? 그래서 그들은 오래오래 행복하게 살았답니다. 그런데 정말 그들은 끝까지 행복했을까? 라는 거. 동화나 일반적인 드라마는 왕자와 신데렐라의 뜨거운 열정은 보여줄지 몰라도 서로를 이해하고 받아들여 가는 시간은 없다. 시간이 지나 그 열정이 식고 나면? '그들은 정말 오래오래 행복하게 살았을까?' 에 대한 의문에 대한 대답은 부정적일 것이다. 현실을 살아가는 사람이라면.
거기에 반해 시크릿 가든은 그 과정을 철저하게 보여주고 있다. (그것도 러브 스토리의 긴장감을 떨어뜨리지 않으면서.. 김은숙 작가 대단하다.) 그렇기 때문에 드라마 막판에 나올 결말(아마도 해피 엔딩이라고 생각될 결말)이 '그들은 오래오래 행복하게 살았답니다.' 라는 마무리에 충분한 개연성을 더해 줄 수 있다.
이렇게 이전의 드라마와는 다른 남자 주인공의 캐릭터와 이로 인해 없던 과정이 생겨 나기 때문에, 이 과정이 성공적으로 이루어질 수 있게 해 줄 수 있는 장치가 필요한데 그게 바로 영혼의 바뀜이다.
김주원과 길라임의 러브 라인이 흘러가는데 있어서 굳이 영혼이 바뀔 필요가 있냐고 묻는 이들도 있었지만, 좀 전에 말한 과정을 성공적으로 지나기 위해 김은숙 작가가 선택한 '영혼의 바뀜'이라는 방법은 아주 훌륭한 장치이다.
어떤 이도 다른 사람의 삶과 사고방식을 완전히 이해할 수는 없다. 그것도 김주원과 길라임처럼 남자와 여자라는 성의 차이가 있고, 백화점 사장과 액션 배우라는 사회적 신분의 차이가 이렇게까지 큰 사람들 사이엔 더욱 그렇다. 이런 상황에서 그래도 이해하기 위한 최선의 방법은 뭐가 있을까? 바로 그 사람의 삶을 직접 살아보는 것이다. 영혼의 바뀜은 상대방의 삶을 직접 살아보기 위한 장치인 것이다.
물론 처음 바뀌었을때 그들은 상대방의 삶을 '살아보려' 하기 보다는 놀람과 당황스러움 속에서 빨리 이 상황을 벗어나고자 했을 뿐이다. 그리고 상대방의 삶 속에 적응하려 하기 보다는 상대방의 삶을 자기 스타일로 바꾸려고 노력했다. (김주원은 길라임의 방을 자기 스타일로 꾸미고 길라임의 주변 사람들을 자기 스타일로 대한다. 길라임도 김주원으로 생활하기 보다는 자기의 감정을 그대로 드러내며 살아간다. 특히 오스카에 대해서) 그리고 다시 원래대로 돌아왔다.
듣기론 스토리상 한 두번 더 바뀐다고 한다. 아마 다시 바뀔 때는 처음 바뀌었을 때와는 조금 다른 모습을 보여주지 않을까 한다. 상대방의 삶에 익숙해져 보려고 노력하는 모습을.
자동차를 운전하다 보면 공회전을 의외로 많이 하게 된다. 아침에 예열을 한다고 시동을 걸어놓고 몇 분간 있는 경우 또는 잠시 정차해 놓고 물건을 구입하러 마트에 가는 경우, 전화 통화를 위해서 차를 멈추고 나서 공회전 상태에서 있는 경우 등등, 하루 평균 20분 이상은 불필요한 공회전을 하고 있다고 한다. 그렇다면 과연 연료는 어느 정도 소요될까?
2분간 공회전 시 소요되는 기름은 53cc로, 20분이면 530cc가 30일을 계산하면 15,900cc 즉, 16L 라는 기름이 공회전에 의해서 소모된다. 휘발유값을 1,700원으로 계산을 하면 한 달에 약 27,200원의 주유비가 공회전으로 소모되는 것이다.
교통 신호로 인한 정차 시 고민 되는 것이 기어를 ‘D’로 놓아야 하는지 아니면 ‘N’으로 놓아야 하는지이다. 결론부터 말하자면 2분 이상의 긴 신호대기일 때는 기어를 ‘N’으로 놓는 것이 연비절감에 도움이 된다고 한다. 신호 대기시간이 짧을 때에는 ‘N’으로 놓게 되면 바로 ‘D’로 전환을 해야 하는데 연비에는 큰 도움이 안되면서 미션에 무리가 갈수도 있어 굳이 그럴 필요는 없다. 실험을 통해서 직접 확인을 해보았다.그림은 신호대기시 D로 놓았을 때와 N으로 놓았을 때의 연료 분사량을 그래프로 보여주는 화면이다. 약간의 연료 변화를 볼 수 있을 것이다. 특히 5분 이상 정차 시에는 무조건 시동을 끄는 것이 연료절약의 지름길이다.
자동차 연료가 가장 많이 소모될 때가 바로 브레이크와 엑셀러레이터를 밟을 때이다. 잘못된 엑셀러레이터 사용 습관 때문에 연비를 10%이상 더 사용하게 되는 경향이 있다. 비교사진을 한번 보도록 하자.
엑셀러레이터를 밟을 때 발을 떼었다 밟았다를 반복했을 때 연비소모에 대한 그래프이다. 그래프에서 높이 올라간 부분이 필요 없는 연료가 소모되는 경우를 나타낸다. 이렇게 연료가 소모되어도 차의 움직임에는 큰 영향이 없다.
엑셀러레이터를 지긋이 밟으면서 고정시켰을 때의 연비소모 그래프이다. 불필요한 연비소모가 발생하지 않았다. 이렇게 엑셀러레이터를 지긋이 밟는 요령을 습관화 시킨다면 연비를 무난하게 절감할 수 있다.
또 오르막길 정차시 엑셀러레이터를 사용하거나 브레이크를 밟는 것보다 핸드 브레이크를 사용하면 연료효율을 높일 수 있다.
운전을 하게 되면 급출발, 급정지를 하지 말라고 하는데 과연 그것이 어느 정도로 엑셀을 밟아야 하는지 애매한 경우가 있다. 상황에 따라서 다르겠지만 엑셀을 밟을 때 발을 살짝 올려놓는다는 기분으로 밟아야 한다. 그리고 바로 발을 떼는 것이 아니라 살짝 올려놓은 상태에서 계속 유지를 하게 되면 차량은 탄력을 받아 연료를 적게 소모하면서 오랜 주행을 할 수 있다. 또한 주행 시에는 일정한 속도를 유지하려고 노력하는 것이 좋다.
2009년도에 아시아경제 주관 연비왕 대회를 했을 때 같은 차종이지만 일반 운전자보다 무려 182%나 연비개선율을 기록한 우승자의 비결이 바로 엑셀을 밟을 때 요령이었다. 위에 소개한 방법으로 습관화가 되었으며, 급출발, 급감속을 줄인 것이 비결이라고 전했다. 최근에 열렸던 ‘2010볼보트럭 연비왕 선발대회’에서는 1리터당 7.6km를 달린 이가 우승을 거머쥐었다. 이처럼 각 자동차브랜드마다 연비왕 대회를 개최해 자동차 연비를 효율적으로 사용할 수 있는 방법을 연구하고 있다. 작은 습관 하나가 자동차 연비를 20%이상 절감할 수 있다는 사실을 꼭 기억하며 연료를 절약하는 습관을 들여보도록 하자.
요즘 잘나가는 준중형급인 아반떼MD와 라세티프리미어 그리고 쏘울의 연비를 비교해보면 16.5km/L : 13.0km/L : 15.0km/L 등으로 차이가 난다. 같은 1,600cc급인데 연비 차이가 나는 이유는 바로 자동차의 무게 때문이다. 자동차에 무거운 짐을 싣고 운행을 하게 되면 기름이 많이 든다는 이야기처럼 차체가 무거운 차량이 기름도 많이 먹는 것이다. 하지만 차체가 다른 준중형급 보다 무거운 차량은 반면에 고속주행시에 안정감을 준다는 장점을 가지기도 한다. 연비만 생각한다면 무조건 차체가 가벼운 차량으로 구입하는 것이 좋겠지만 차량 선택시에는 자신에게 맞는 여러 조건들을 가지고 검토해 보는 것이 좋다. 차체 중량이 적을수록 연료 소모가 줄어든다는 것을 인지했다면 차량의 트렁크 관리도 습관화 해야 한다. 당장 필요 없는 무거운 짐들은 집에 보관하고 트렁크에는 꼭 필요한 물건들로 트렁크 다이어트(?)를 해 보자.
이 밖에도 최적의 엔진오일량을 유지한다든지 적절한 에어컨 사용법, 순정부품 사용하기 등이 있으며 연비절감 뿐 아니라 안전운전에도 도움이 되는 것이므로 습관화 하도록 하자.
사진 : 최재봉 http://blog.naver.com/auto10004
자료제공 : 오토카페 www.autocafe.kr
UPnP(Universal Plug and Play)는 정보가전, 무선통신장치, PC 관련 장비 등 여러 장소에 분산되어 있는 장치와 서비스 간의 쉽고 편리한 통신방법을 제공하고자 탄생하였다. 그 이름에서 느낌이 오듯이 UPnP는 마이크로소프트사에서 MS Windows에 주변장치 접속을 위해 채택한 PnP (Plug and Plag – 꽂으면 동작한다)를 보다 다양한 장비에 적용할 수 있도록 확장한 기술이다.
UPnP는 가정이나 작은 사무실과 같이 관리자가 없는 네트워크 환경에서 사용자의 작업이 없이 표준화된 방법으로 쉽게 장비간의 연결이나 장비와 인터넷의 연결 방안을 제공한다. 즉, 각 장비들은 언제나 쉽게 네트워크에 접속을 하여 다른 장비들에게 자신의 기능을 알리고 통신을 하거나 제어를 할 수 있도록 해주며, 더 이상 사용하지 않을 경우에는 네트워크에서 쉽게 제거 시킬 수 있도록 해준다.
UPnP는 장비간의 1대1 통신(Peer-to-Peer)을 기반으로 하고 있으며 현존하는 Internet 표준 프로토콜(TCP/IP)을 이용하여 그 구조를 정의하고 있다. 그러나, 이로 인해 장비마다 IP를 부여하고 동적으로 IP를 할당 받아야 하기 때문에 DHCP(자동으로 IP 주소를 할당하는 기능)와 같이 가정내의 장비의 동적인 IP 할당방안을 제공하거나 IP 주소의 크기를 늘인 IPv6를 필요로 한다는 점은 UPnP 확산에 부담으로 작용하고 있다. UPnP 모임은 MS, Intel을 주축으로 하여 정보, 가전중심의 250개 이상의 회사들이 회원으로 가입이 되어 있으며 현재 활발한 활동을 진행 중이다.
UPnP의 특징으로는 소규모에서 대규모의 네트워크로 확장이 용이하고, PnP를 지원하여 장비의 접속과 분리를 자동으로 인지하며, 개발이 용이하고, 작은 리소스로도 이용이 가능하며, 가전장비와 같이 IP가 없는 장비에 대해서는 단순한 기능을 가진 SCP라는 프로토콜을 통하여 브릿지(Bridge; 네트워크 프로토콜 변환기)로 연결할 수 있도록 지원한다.
[그림1] UPnP 의 구조 |
UPnP는 장비에 관계없이 공통적인 Interface를 제공한다[그림 1]. 따라서 홈 서비스용 응용 프로그램 입장에서는 UPnP를 지원하는 장비들의 구체적인 사항에 대한 고려를 하지 않아도 통신이 가능하며, 장비의 입장에서도 UPnP만을 지원하면 이를 지원하는 모든 서비스용 응용 프로그램과 연결이 가능하게 된다. 위의 그림에서 SSDP(Simple Service Discovery Protocol)는 네트워크에 연결되어 있는 장비와 사용 가능한 서비스를 검색하기 위한 프로토콜이고, Mini Web Server는 장비간의 기능 및 상태정보를 주고 받기 위해서 사용되고, GENA는 장비간의 이벤트(상태 변화 등) 교환을 위해서 사용되며, SOAP은 XML 문법을 이용하여 장비에 제어 명령 등을 전달할 때 사용된다.
UPnP를 지원하는 장비는 제어의 주체가 될 수 있느냐에 따라 제어기(Control Point)와 피제어기(Controlled Device)로 구분된다. 제어기는 다른 장비를 검색하거나 제어하며, 피제어기는 제어기에서 전달되는 명령을 수행한다.
[그림 2] UPnP Network 의 구성 |
[그림 2]는 UPnP Network상에서 장비들간의 관계와 동작을 보여주고 있다. 제어기는 다른 피제어기들을 찾아주고 이 장비들을 제어한다. 피제어기는 장비 내부에 여러 가지 서비스를 내장하고 있으며, 제어기에서 명령이 오면 이에 대응하는 서비스를 수행한다. 또한, UPnP를 지원하지 않는 장비들에 대해서는 브릿지라는 프로토콜 변환기를 통하여 UPnP 네트워크에 접속할 수 있도록 고려하였다.
[그림 3] UPnP Networking 단계 |
[그림 3]에서는 UPnP가 실제로 동작하는 과정을 보여주고 있다. 각 단계별로 설명을 하면 다음과 같다.
• 주소지정(Addressing) : UPnP는 IP기반의 네트워크이므로 장비들마다 IP가 필요하며,이를 위해 IP의 할당이 제일 먼저 수행 된다. 장비가 처음 네트워크에 접속할 때 DHCP서버를 검색하여 IP를 할당 받으며, 이때 각 장비들은 모두 DHCP Client가 된다
• 장비 검색(Discovery) : 주소지정을 통해 각 장비들이 IP를 부여 받게 되면, 그 다음에는 제어하고자 하는 장비들을 검색하는 것이 필요하다. 이를 위해 제어기에서는 SSDP라는 프로토콜을 사용하여 장비를 검색한다. 제어기는 관심 있는 장비들을 검색하고 피제어기는 이에 응답한다. 피제어기에서는 자신이 네트워크에 접속하는 경우, 자동으로 타 장비들에게 접속된 사실을 알려주고 주기적으로 접속의 지속여부를 알려준다.
• 장비 명세(Description) : 장비를 발견하게 되면 각 장비마다 수행할 서비스가 무엇이 있는가를 알아야 한다. 이를 위해 제어기에서 피제어기를 발견하면, 피제어기에서는 장비에 대한 명세가 들어 있는 URL을 보내고, 제어기는 피제어기에서 XML 문서로 된 장비 명세를 가져온다. 이 문서에는 제조사 정보, 제품정보(모델, 시리얼 번호,…), 서비스 목록 등이 담겨있다.
• 제어(Control) : 제어기는 피제어기에서 장비 명세를 가져와 기술되어 있는 장비의 서비스를 분석한 후, 피제어기에게 적절한 명령어(action)를 보내어 제어한다. 이 때 사용되는 프로토콜은 XML/SOAP이다.
• 이벤트 처리(Eventing) : 홈 네트워크에서는 주변 환경에 따라서 장비의 상태가 변하는 경우가 빈번하다. 때로는 이러한 변화가 사용자에게는 중요한 정보가 될 수도 있기 때문에 UPnP에서는 이벤트를 정의하고 있다. 제어기는 피제어기의 상태가 변화하는 것에 주목을 하고 있고, 피제어기는 자신의 상태가 변할 때 제어기에게 이벤트 메시지를 전달한다. 이벤트는 (이름, 값)의 쌍으로 되어 있으며, 이벤트에서 사용되는 프로토콜은 XML형식의 GENA라는 프로토콜이다.
• 장비의 사용자 인터페이스(Presentation) : 제어기에서는 피제어기의 HTML Page를 읽어 들일 수 있다. 이 HTML Page는 장비 사용에 관련된 사용자 인터페이스를 보여주며, 이를 통하여 장비를 제어하거나 상태를 보여주기도 한다.
마지막으로 UPnP의 장단점을 살펴보자. 먼저 장점으로는 범용의 인터넷 기반의 프로토콜이기 때문에 개발자들에게 친숙하며 개발이 쉽고 유지보수가 용이하다. 또한 웹 기반의 프로토콜이기 때문에 운영체제와 무관하게 사용할 수 있다. 단점으로는 TCP/IP기반의 프로토콜을 사용하므로 사용 모듈의 크기와 수행에 따른 CPU의 부담이 크다. 따라서 PC와 같은 고급 장비에 어울리는 미들웨어이다. 현재 마이크로소프트에서는 이러한 단점을 보완하기 위하여 가전장비와 같은 저급의 CPU에서 사용이 가능한 SCP(Simple Control Protocol)라는 가전장비 제어용 프로토콜을 정의하고, SCP와 UPnP의 호환성을 위한 브릿지를 사용하는 방법을 제안하고 있다.
최근 덧글