아키텍트들은 프로젝트에 착수할 때, 자신의 가치를 입증 하려 하는 갈망이 있다. 소프트웨어 아키텍트 역할을 맡는 다는 것은 아키텍트의 기술적 리더십을 회사의 일부분으로 절대적으로 신뢰함을 나타내고 이는 오직 아키텍트가 가능한 빨리 기대를 성취하기를 열망할 때 이루어진다. 그런데 불행히도 자신의 가치를 입증하는 것이 현혹하거나 개인의 기술적 탁월함으로 팀을 좌절시키는 쇼맨십으로 이루어진다고 오해하는 아키텍트들이 있다.
사람들에게 어필하는 행동인 쇼맨십은 마케팅에서는 중요할지 모른다. 하지만 소프트웨어 개발 프로젝트에 있어서는 역효과를 나타낼 뿐이다. 아키텍트는 확고한 리더십으로 그들 팀의 존경을 얻어야만 하고 기술과 그들이 운영하고자 하는 비즈니스도메인의 이해가 있어야 한다.
책임을 지고 다른 이들을 돌보는 청지기의식(Stewardship)은 아키텍트의 역할에 적합하다. 아키텍트는 그들의 고객을 위해 최선을 다해야 하며 고객의 요구를 이용하려 들지 말아야 한다.
소프트웨어 아키텍처는 고객의 요구를 수행하는 것으로, 보통 탁월한 능력으로 도메인 전문지식을 가진 이들의 방침으로 이뤄진다. 성공적인 소프트웨어의 개발을 추구하는 것은 아키텍트로 하여금 절충안에 대한 솔루션을 만들고, 프로젝트에 주어진 시간과 노력에 대한 구현의 복잡성과 비용 사이의 밸런스를 조절하도록 이끈다. 이 시간과 노력이 바로 아키텍트가 개인적 사심 없이 책임을 다해야 하는 기업의 자원인 것이다. 최신의 따끈따끈한 프레임웤이나 기술전문유행어로 이루어진 과도하게 복잡한 시스템은 기업 지출의 희생을 담보로 하고 있다. (주- 즉 아키텍트 자신의 돈으로 시스템을 구현하면 좀 더 현실적인 시스템이 나왔을 것이라는 얘기다. 이기심에서 발로되는 아키텍트의 방만한 재정 운용을 꼬집고 있다). 아키텍트는 그들 활동이 투자 브로커처럼 합리적인 ROI(투자 대비 수익률)를 창출할 수 있다는 전제 하에 고객의 돈을 사용하도록 해야 한다.
쇼맨십을 넘는 가치 청지기의식은 당신이 다른 사람의 돈을 사용하고 있음을 절대 잊지 않는 것이다.
대부분의 아키텍트의 경력은 개발자로부터 시작한다. 아키텍트는 시스템을 구축하는 방법을 결정하는 새로운 의무와 더 많은 자유를 갖게 된다. 아마 당신은 아키텍트라는 새 역할로 개발자 때 했던 일을 놓아두는 것에 어려움을 발견했을 것이다. 더 안 좋은 것은 당신은 개발자가 설계를 따라 개발하도록 강한 통제를 하는 것이 중요하다고 느낄 수도 있다는 것이다. 당신의 동료들에게 충분한 자유를 주어 그들 자신의 창조성과 능력을 행사하도록 하는 것은 당신의 성공과 팀의 성공에 매우 중요할 것이다.
개발자로서 뒤에 앉아서 전체 시스템이 어떻게 맞춰지는지를 바라보는 시간이 드물지만 아키텍트로서 이는 당신의 주된 관심사이다. 개발자가 힘차게 클래스와 메소드, 테스트, 유저인터페이스, 데이터베이스를 만들어내는 동안 당신은 그 모든 조각들이 함께 어우러져 잘 작동하도록 확인해야 한다. 어려운 지점들에 주목하고 그들을 발전 시키도록 해라. 사람들이 테스트 작성하는데 어려움을 겪고 있는가? 인터페이스와 의존성 경계를 발전시켜라. 당신은 추상화가 필요한 지점과 그렇지 않은 부분을 이해하고 있는가? 도메인 명확도를 위해 일을 하라. 어떤 순서로 그것들이 세워지는지 아는가? 프로젝트 계획을 세워라. 개발자가 당신이 설계한 API를 사용하는데 지속적으로 공통된 실수를 하는가? 더욱 명백하게 설계하라. 사람들이 정말 설계를 이해하는가? 대화하고 이를 명확히 하라. 당신은 기준으로 해야 하는 곳과 그렇지 않은 곳을 정말로 이해하는가? 당신의 고객과 함께 일하고 그들의 비즈니스 모델을 배우도록 하여라.
만약 당신이 아키텍트로서 훌륭히 일을 해내고 있다면 당신은 개발자들을 간섭할 만한 시간이 없을 것이다. 당신은 설계가 의도한대로 잘 구현되고 있는지 자세히 살펴볼 필요가 있다. 하지만 당신은 사람들의 어깨 너머에 서서 목표를 완성하는 것을 볼 필요는 없다. 사람들이 고군분투하는 것을 볼 때 조언하는 것이 합리적이고 그들이 찾아와서 당신의 조언을 요청할 환경을 만든다면 더욱 좋을 것이다. 당신이 잘 한다면 성공적인 아키텍처의 보장과 창조성 제한과 당신의 개발자와 팀 동료의 지적 삶의 사이에 훌륭한 길을 능숙히 갈 것이다.
Written by Philip Nelson
Philip Nelson은 자신이 가장 흥미로운 일을 찾아 하드웨어 분야로 시작하여 네트워크, 시스템, 관리를 지나 마침내 소프트웨어 개발 및 아키텍처의 경력을 가진 기술 제너럴리스트이다. 그는 운송, 금융, 제조, 마케팅과 다양한 인프라분야 관련 소프트웨어 문제점에 대해 일해왔다.
지난 몇 년을 지내면서 나를 가장 즐겁게 한 한가지는 어떤 것이 견디어 냈고 무엇이 그러하지 못했는지를 관찰하는 것 이였다. 똑똑한 사람들에 의해 오랜 시간의 숙고와 알려진 모든 이슈의 조정과 열정으로 논의되어진 그렇게 많은 패턴, 프레임워크, 패러다임의 변화, 알고리즘들은 긴 하품의 시간 만큼도 보장되지 않았다. 그 이유는 무엇일까? 이 역사가 우리에게 말하려는 것은 무엇일까?
도전의 가치를 선택하라.
소프트웨어 아키텍처에게 도전은 까다로운 것이다. 도전이나 문제들은 우리에게 그냥 주어지기에 우리에게 선택의 사치스러움이란 있을 수 없지 않는가? 말처럼 그렇게 단순하지가 않다. 우리가 종종 저지르는 믿음에 대한 첫번째 실수는 우리가 받은 요청에 변화를 줄 수 없다는 것이다. 일반적으로 우리는 변화를 줄 수 있지만 이는 우리를 편안한 기술영역에서 쫓아낸다. 우리가 옳은 것을 결정 하지 않는 곳에 괴물 이 있다. 시간이 지나가서 우리가 맞닥뜨린 도전을 열심히 해결하며 기쁘고 열심히 일했다면 그 동안 우리가 필요로 했던 일을 못하고 놓치더라도 결국 문제 되지 않을 것이다. 옳은 도전에 대한 좋은 해결책은 모든 다른 사람에게 까지 오래 지속될 것이기 때문이다.
단순한 법칙들 우리는 단순함을 추구하라고 우리자신에게 말하지만 실제 그렇게 살지 않는 이유는 그럴 필요가 없기 때문이다. 우리는 영리하고 약간의 복잡도를 다룰 수 있다. 그래서 빠르게 설계에 추가하기 위함이라고, 우리 미적 감각이 더 우아하다고, 우리가 미래를 예상할 수 있다고 믿는다고 하면서 쉽게 자신을 변호해버린다. 하지만 시간이 흘러 일년 이상 프로젝트에서 멀리 떨어져 있다가 다시 돌아와 봤을 때 분명 당신은 당신이 한 일에 대해 왜 그렇게 했었는지 의야 해 할 것이다. 만약 모든 것을 처음부터 다시 해야 한다면 분명 당신은 다르게 할 것이다. 시간은 우리를 바보로 보이게 한다. 이를 일찍 깨달아서 자신을 극복하라 그리고 단련할 수 있을 때 단순함이 무엇을 의미하는지 진심으로 배우도록 하여라.
오래된 것들과 행복하라
아키텍트는 방법론 또는 학파가 가능하다고 여겨지는 하나의 방법이나 손에 닿지 않는다고 여겨진 것의 명확한 답을 찾는 것을 좋아한다. 문제는 당신이 일년간 사용한 등대가 무엇이었던 2년째에는 정확히 일치하지는 않을 것이고 10년 후에는 더 더욱 그러리라는 것이다. 뒤돌아 보면 당신은 항상 현재 기대와 맞지 않는 설계가 보일 것이다. 오래된 것을 포용함을 배우고 뒤로 되돌아 가려는 생각의 유혹에 저항하고 이를 고쳐라. 그 해결책이 그 문제에 적합한 것이었는가? 그 문제의 필요를 해결했는가? 이 질문을 당신의 측정 기준으로 삼아라 그럼 당신은 훨씬 행복해 질것이다.
Written by Philip Nelson
Philip Nelson은 자신이 가장 흥미로운 일을 찾아 하드웨어 분야로 시작하여 네트워크, 시스템, 관리를 지나 마침내 소프트웨어 개발 및 아키텍처의 경력을 가진 기술 제너럴리스트이다. 그는 운송, 금융, 제조, 마케팅과 다양한 인프라분야 관련 소프트웨어 문제점에 대해 일해왔다.
객체지향 프로그래밍과 Simula프로그래밍언어의 아버지인 Kristen Nygaard는 “프로그래밍은 배우는 것이다” 라고 말하곤 한다. 프로그래밍, 더 정확히 소프트웨어 개발을 받아들이는 것은 발견과 배움의 과정이지 공학의 과정이 아니다. 그리고 구축은 소프트웨어 프랙틱스를 진보시키는 필수요소이다. 소프트웨어 개발의 전통적 공학과 구축의 개념의 적용은 효과가 없다. 이러한 문제는 30년 이상 유력한 소프트웨어 사상가들에 의해 문서화 되고 이야기 되어왔다. 한 예로 1987년 Fredric Brooks JR는 “Report of the Defense Science Board Task Force on Military Software”에서 document driven, 즉 명세 후 구현하는 방식은 많은 소프트웨어 문제로 거짓임을 기술했다.
그렇다면 소프트웨어 산업이 그 프랙틱스를 향상시키기 위해 어디에 주의해야 하는가? 차나 의약품, 반도체와 같은 정교한 대중시장 제품의 생산에 관련된 산업은 어떤가?
자동차 산업을 보자. 새로운 모델을 계획할 때 최초로 하는 것이 컨셉이나 원형을 선택하는 것이다. 이것이 주된 아키텍처적인 배치 방법이다. BMW X6는 BMW가 Sports Active Coupe라고 부르는 SUV와 쿠페의 속성을 결합한 새로운 컨셉의 한 예이다. 생각해볼 점은 당신이 새로운 X6를 구매하기 전에 BMW가 이 자동차와 제조 설계에 수천시간과 수백만 달러를 투자했다는 것이다. BMW가 당신의 주문을 받을 때, 조립라인이 가동될 것이고 당신의 요구에 맞춘 버전의 X6를 생산할 것이다.
그렇다면 이 자동차 생산자의 시나리오에서 배울 점은 무엇일까? 중요한 배움은 새로운 자동차를 만드는데 2개의 프로세스가 수반된 다는 것이다. 첫번째 프로세스는 필요로 하는 조립라인을 세우는 것을 포함한 창조적인 디자인 프로세스이다. 두번째 프로세스는 공정 안에서 고객의 명세서에 맞춘 자동차 제조이다. 이는 많은 면에서 우리가 소프트웨어 산업에서 발견할 수 있는 프로세스이다. 도전은 우리가 이 조건 에 무엇을 투자하는 가이다.
"What is software design?(소프트웨어 설계란 무엇인가?)" 라는 기사에서 Jack Reeves는 고전적인 공학에서 이해되어지고 사용되었던 설계 문서의 기준을 만족시키는 소프트웨어 공학의 유일한 산출물이 소스코드임을 제시했다. 소프트웨어의 제조는 컴파일러, 빌드, 테스트 스크립트에 의해 자동화 되어지고 관리되었다.
소스코드를 조각해 가는 것은 설계의 행위이지 구현의 행위가 아니다는 것을 받아들임으로 인해 우리는 일하는 것이 입증되는 유리한 관리 프랙틱스를 채택할 수 있는 위치에 있게 됐다.
이들은 새로운 자동차, 의약품, 컴퓨터게임 개발과 같은 창조적이고 예측하기 힘든 일을 관리하는데 사용되는 프랙틱스이다. 우리는 에자일 제품 관리와 SCRUM과 같은 린 생산 에 대해서 이야기 한다. 이 프랙틱스들은 특정기간에 고객가치의 최대 투자수익률(ROI)에 집중한다.
이 프랙틱스를 이용할 소프트웨어 산업을 위해 우리는 기억해야 한다. 프로그램은 설계의 행위이지 구축의 행위가 아니다 라는 것을…
유능한 SW아키텍트들은 기술 뿐 아니라 문제영역의 비즈니스도메인(업무영역)도 이해한다. 비즈니스도메인 지식 없이는 비즈니스의 문제, 목표, 요구들을 이해하기 힘들고 그렇기에 비즈니스의 요구사항에 맞는 효과적인 아키텍처를 설계하기 힘들다.
비즈니스 문제, 골, 요구사항들을 이해하고 요구사항을 그 요건들을 충족시킬 수 있는 기술적인 아키텍처 솔루션으로 옮기는 것이 소프트웨어 아키텍트의 역할이다. 비즈니스 도메인을 이해하는 것은 아키텍트가 어떤 패턴을 적용할지, 향 후 확장성을 위해 어떤 계획을 짤 것인지, 계속 변하는 산업 추세를 어떻게 준비할지 결정하는 것을 도와준다. 예로 몇몇 비즈니스 도메인들(예: 보험)은 워크플로우 기반 아키텍처(workflow-based architecture)접근방법에 더 많이 힘 쏟는 비즈니스모델(예: 금융 시장)에 반해 서비스기반 아키텍처(SOA) 접근방법에 힘을 쏟는다. 도메인을 이해하는 것은 당신이 어떤 아키텍처 패턴을 사용해야 기관의 특정 필요들을 최대한 만족시켜주게 할지를 결정하는데 도움을 준다.
특정 도메인의 산업 트랜드를 이해하는 것 역시 소프트웨어 아키텍트가 효과적인 아키텍처를 설계하는데 도움을 줄 수 있다. 한 예로 보험 도메인에서는 당신이 실제적으로 운전할 때에만 자동차 보험료를 지불하도록 하는 “on-demand” 자동차 보험이 증가 추세 이다. 당신이 월요일 아침에 차를 공항에 주차하고 당신이 일할 곳으로 날아갔다가 금요일에 돌아와 집으로 운전하고 돌아갈 때 이러한 타입의 보험이 훌륭하다. 당신의 회사와 당신이 그러한 계획을 비즈니스 모델로 계획하지 않고 일하는 중이 더라도 이와 같은 보험추세를 이해하는 것은 당신이 소프트웨어 아키텍트로서 이러한 트렌드를 아키텍처 안에 계획하는 것을 가능하도록 한다.
비즈니스의 특정 골을 이해하는 것 역시 당신에게 효과적인 아키텍처를 설계하는데 도움이 될 것이다. 한 예로 당신이 일하고 있는 특별한 비즈니스 골이 큰 합병과 인수를 통한 조직화되지 않은 성장을 포함하고 있는가? 질문에 대한 답은 당신이 설계할 아키텍처의 타입에 영향을 미칠 것이다. 만약 답이 ‘그렇다’ 라면 아키텍처는 비즈니스 컴포넌트들의 융합을 용이하게 하는 많은 추상레이어를 포함하게 될 것이다. 만약 비즈니스의 골이 대량의 온라인 참여를 통한 시장 점유율 증가를 포함한다면 고가용성이 가장 중요한 속성이 될 것이다. 소프트웨어 아키텍트로서 항상 당신이 일하고 있는 회사의 골에 대해 이해하고 아키텍처가 그러한 골을 지원할 수 있도록 하라.
내가 아는 대부분의 성공한 아키텍트들은 광범위한 실전 기술지식과 결합된 특정 도메인의 강한 지식을 갖은 사람이다. 이러한 소프트웨어 아키텍트들은 C레벨 임원과 비즈니스 사용자에게 이들이 알고 이해할 수 있는 도메인 언어를 사용하여 의사소통 할 수 있다. 이는 소프트웨어 아키텍트가 자신이 무엇을 하고 있는지 아는 것에 강한 수준의 확신을 갖도록 해준다. 비즈니스 도메인을 이해하는 것은 소프트웨어 아키텍트가 문제와 이슈, 골, 데이터, 프로세스 등 효과적인 엔터프라이즈 아키텍처를 설계할 때의 모든 핵심 요소들에 관해 더 잘 이해하도록 해준다.
어플리케이션을 만드는 것에는 많은 결정을 필요로 한다. 몇몇은 프레임워크나 라이브러리를 선택하여 포함할 것이고 또 다른 이들은 특정 디자인 패턴 사용에 집중할 것 이다. 모든 경우에 결정의 책임은 팀의 아키텍트에게 있다. 진부한 아키텍트는 수집할 수 있는 모든 정보를 수집한 후 잠시 숙고하여 마침내 상아탑에서 개발자들로부터 적용될 솔루션을 발표할 것이다. 놀랄 것도 없이 여기에 더 좋은 방법이 있다.
Mary와 Tom Poppendieck는 개발에 편향된 그들의 업무에서 의사결정을 위한 기술을 설명했다. 이들은 아키텍트가 마지막 순간까지 책임의 의무를 다해야 한다고 주장한다. 팀이 쉽게 되돌릴 수 없는 결과가 예상되는 결정으로 인해 결정하지 못해 아무 일도 못 할 때 그들을 위해 결정해 줘야 한다는 것이다. 더 많은 정보는 결정 기반 위에 가능하고 뒤의 결정은 이 정보에 의해 만들어지기 때문에 신중할 수밖에 없다. 그러나 많은 경우 더 많은 정보가 충분한 정보를 의미하지는 않는다. 그리고 우리는 최고의 결정이 뒤늦게 만들어 진다는 것을 안다. 이것이 좋은 아키텍트에게 어떤 의미를 갖게 하는가?
아키텍트는 곧 이뤄야 할 결정을 지속적으로 감시해야 한다. 주어진 팀이 소수의 개발자보다 많고 축적된 코드 소유권을 수행한다면 그와 같은 결정지점이 다가올 때 아키텍트는 다양한 개발자에게 문제의 해결점 제시를 물어보고 잠시 이를 수행할 수 있다. 마지막 결정의 순간이 다가올 때 팀은 이점에 대해 평가하고 다른 솔루션의 약점에 대해 알게 된다.
소 잃고 외양간 고치는 격이지만 일반적으로 문제의 최고의 솔루션은 누구에게나 아주 명백하다. 아키텍트는 선택할 필요도 없다. 그냥 의사 결정 프로세스만 조정하면 될 뿐이다.
이 접근방식은 큰 선택뿐 아니라 작은 선택에도 작용한다. 이는 팀에게 스프링 프레임워크에서 제공된 하이버네이트 템플릿을 사용할지 안 할지를 팀이 알아내도록 할당할 수 있을 뿐 아니라 어떤 자바스크립트 프레임워크를 쓸지에 답해줄 것이다. 다른 접근방법들이 나타내는 지속기간은 명백히 선택의 복잡성에 매우 의존한다.
같은 문제에 둘 혹은 더 많은 접근방법을 시도하는 것은 먼저 결정 내리고 하나를 적용해 보는 것 보다는 더 많은 노력이 요구된다. 하지만 앞선 결정은 나중에 차선으로 인식된 솔루션을 이끌기에 아키텍트에게 딜레마를 남긴다. (팀이 현재 수행하는 일을 취소하거나 그대로 남겨서 결과를 감수하는 것 양쪽 결과 모두 노력을 낭비하는 결과를 낳기에) 더 나쁜 경우는 아무 대안들이 조사되지 않았기 때문에 그 접근의 선택이 최선이 아님을 팀의 누구도 인식 못할 가능성이 있다는 것이다. 이와 같은 경우에 노력은 어떠한 방향의 기회 없이 쓰레기로 버려진다. 그렇기에 다양한 접근들을 시도하는 것이 최소한의 자원낭비 일 수 있다는 것이다.
Written by Erik Doernenburg
Erik Doernenburg는 ThoughtWorks, Inc.의 기술고문으로 대규모 기업 솔루션의 설계와 구현부분의 고객지원을 하고있다.
아키텍트로서 우리가 알기 원하는 것은 ‘우리가 개발하고 있는 software가 얼마나 좋은가’이다. 소프트웨어는 사용자에게 유용해야 한다는 명백한 외부적 관점이 있지만 그보다 더 어려운 품질이라는 내부적 관점도 있다. 품질은 쉽게 소프트웨어를 이해하고, 유지보수하고 확장할 수 있는 설계의 명확도를 요구한다. 우리가 명확히 정의 내려야 할 압박이 올 시점에 보통 “나 그거 보면 알아!” 라고 말 할 수 있어야 한다. 하지만 어떻게 품질에 대해 볼 수 있겠는가?
아키텍처다이어그램에서 작은 상자들은 전체 시스템을 나타내고 그 사이의 선은 시스템간의 의존성, 데이터흐름, 버스와 같은 공유자원 등 모든 것이 될 수 있다. 이 다이어그램들은 마치 비행기에서 보는 풍경과 같은 30,000피트 뷰이다. 전형적으로 유일하게 사용 가능한 다른 뷰는 바닥레벨 뷰와 비교되는 소스코드이다. 한뷰는 매우 높은 레벨이고 다른뷰는 구조를 보지 못할 정도로 너무 많은 정보를 제공하기 때문에, 두 뷰는 소프트웨어 품질에 대한 많은 정보를 제공하지 못한다. 이 둘 사이에 빠진 뷰는 1000피트 뷰이다.
이 1000피트 뷰는 적당한 수준의 정보를 제공할 것이다. 이는 많은 양의 데이터와 메소드갯수, 클래스 팬아웃, 순환복잡도와 같은 다중 metrics 를 모은다.
현실적인 뷰는 품질의 특정한 측면에 매우 의존한다. 이는 다양한 입력 값에 상응하는 의존성그래프나 클래스레벨의 metrics를 나타내는 막대그래프나 정교한 polymetric 뷰의 시각적 표현이 될 수 있다.
손으로 이러한 뷰를 그리고 이를 소프트웨어와 지속적으로 동기화 하는 것은 절망적인 시도이다. 우리는 유일한 원천인 소스코드로부터 뷰를 만드는 툴이 필요하다. 상업적인 툴로 몇몇 뷰가 있다. (예: design structure matrix ) 하지만 놀랍게도 일반적인 시각화 패키지로 (정확한 데이터와 metrics 같은) 작은 도구들을 결합해서 전문화된 뷰를 쉽게 생성 가능하다. 간단한 예를 들자면 차트를 그리기 위해 본질적으로 클래스와 메소드레벨의 matrics세트인 checkstyle에서 스프레드시트로 출력물을 로드하는 것이 될 수 있다. 같은 metrics 로 InfoViz 툴킷을 이용하여 트리맵으로 보여 줄 수있다. 복잡한 의존성 그래프를 그리는 훌륭한 도구로는 GraphViz가 있다.
적당한 뷰가 가능해 짐으로 소프트웨어 품질은 덜 주관적이 된다. 이로서 소수의 비슷한 시스템으로 개발단에서 소프트웨어를 비교할 수 있다. 같은 시스템에서 다른 개정판 비교는 트렌드의 징후를 보이는 한편 다른 서브시스템의 비교뷰는 outliers (서로 다른값)를 강조할 수 있다. 단지 하나의 다이어그램으로도 우리는 패턴을 발견하고 아름다움을 알아차릴 수 있다. 균형이 잘 잡힌 트리는 성공적인 클래스계층화를 보여줄 것이다. 그리고 조화로운 상자(다이어그램에서)의 집합은 적당한 크기로 정리된 코드를 보여줄 것이다.
대부분의 경험에서 매우 단순한 관계로 성립된다. 좋아 보인다면 분명 잘 설계 되었을 것이다.
Written by Erik Doernenburg
Erik Doernenburg는 ThoughtWorks, Inc.의 기술고문으로 대규모 기업 솔루션의 설계와 구현부분의 고객지원을 하고있다.
나는 분명 Architecture에 ‘i’가 있다라는 것은 알고 있다. 하지만 이것은 그 자신에만 집중하는 것으로 불리는 대문자 ‘I’, 가 아니다. 소문자가 단어 안에서 깔끔하게 딱 맞는다. 오직 소문자 만이 되는 이유는 적절한 단어와 소리의 요구사항을 충족시키기 때문이다.
이 말이 소프트웨어 아키텍트인 우리에게 어떤 연관성이 있을까? 우리의 자아는 우리 자신의 최악의 적일 수도 있다는 것이다. 다음과 같은 사람은 아키텍트를 경험하지 못해왔다.
그들이 고객보다 요구사항을 더 잘 이애 한다고 생각하는 사람
개발자를 그들의 아이디어를 구현하기 위해 고용한 자원으로 보는 사람
그들의 아이디어가 도전 받거나 다른 이의 아이디어에 무시당할 때 방어적인 사람
나는 모든 경험 있는 아키텍트가 위의 함정 중 최소 한가지에는 실패한 적이 있을 것이라 추측한다. 나도 그런 함정에 실패한 적이 있고 내 실수를 통해 아픈 교훈을 얻었다.
왜 이런 일이 일어나는 것일까?
우리는 성공해 왔다. 성공과 경험은 자기만족감을 형성시키고 우리로 아키텍트가 되도록 한다. 성공은 더 큰 프로젝트로 인도한다. 자기만족과 오만함 사이에는 고속도로가 있다. 몇몇의 지점에서 프로젝트는 우리 개개인의 능력보다 크다. 오만함은 우리가 그 선을 넘지만 아직 그것을 모를 때 몰래 들어온다.
사람들은 우리를 존경한다. 어려운 설계의문들은 중요한 안전망을 제공한다. 우리 자신의 방어기재, 오만, 경험의 강조는 설계 의문들을 잃어버리는 결과가 될 수 있다.
우리는 사람이다. 아키텍트들은 각 설계로 그들 자신을 나타낸다. 그래서 당신의 만들어 낸 것에 대한 비판은 당신의 비판처럼 느껴진다. 방어기재는 쉽게 나타나지만 이를 그만두기를 배우는 것은 힘들다. 우리 성취감에 자신감을 얻기란 쉽지만 우리 한계를 의식적인 노력 없이 인식하기란 어렵다.
이를 피할 방법은 무엇인가?
요구사항은 거짓말을 하지 않는다. 옳고 완벽한 요구사항으로 되어있는 모든 아키텍처는 좋은 것이다. 각 요구사항이 제공하는 비즈니스 가치의 이해를 하기위해 고객과 가까이 일하라. 아키텍처를 당신이 이끌려 하지 말고 요구사항이 하도록 하라. 당신은 최선을 다해 그들의 필요를 섬겨야 한다.
팀에 집중하라 팀은 자원이 아니다. 그들은 당신의 설계 협력자이자 당신의 안전망이다. 진가를 인정받지 못하는 사람은 보잘것없는 안전망을 만든다. 아키텍처는 팀의 것이지 당신 혼자의 것이 아니다. 당신은 가이드라인을 제공하고 모든 사람이 힘써 함께 이끈다. 당신은 그들이 당신의 도움을 필요로 하는 것 이상으로 그들의 도움이 필요하다.
당신의 업무를 점검하라. 모형은 아키텍처가 아니다. 이것은 아키텍처가 동작하는 방법에 대한 당신의 이해일 뿐이다. 프로젝트 아키텍처가 각 요구사항을 어떻게 지원하는지 검증하는 테스트 항목을 정하기 위해 당신의 팀과 함께 일하라.
당신을 돌아봐라 우리 대부분은 우리 일을 방어하고, 이기적인 관심에 집중하고, 우리자신을 방안에서 가장 영리한 사람으로 여기는 우리의 본능과 싸운다. 압력은 표면에서 이러한 경향을 밀어낸다. 매일 몇 분 동안 당신의 반응에 심사 숙고해라. 당신은 모든 사람의 아이디어에 그들이 마땅히 받아야 할 존경과 인정을 주었나? 당신은 선의의 참여에 부정적으로 대하지는 않았는가? 당신은 누군가가 당신의 접근방법에 왜 불응했는지 정말로 이해했는가?
성공을 보장하지 않는 architecture 의 ‘I’를 제거해라. 이는 전적으로 당신의 실패인 실패의 공통요소를 제거하는 것이다.
Written By Dave Quick
Dave Quick은 Thoughtful Arts의 소유주이자 수석 아키텍트, 관리인, 그리고 유일한 직원이다.
Thoughtful Arts는 음악가들을 위한 off-the-shelf 소프트웨어를 개발하고, 음악이나 예술 관련 소프트웨어를
개발하고자 하는 기업의 소프트웨어 디자인 자문을 하기도 한다.
당신은 당신의 조직에서 잘 설계된 프레임워크나 꼼꼼히 고려하고 현명하게 구현된 아키텍처를 그대로 재사용하는 방법을 선택할 수도 있다. 진실은 가장 아름답고, 우아하며, 재사용 가능한 아키텍처, 프레임워크나 시스템일지라도 오직 아래와 같은 사람들만 재사용한다는 것이다.
재사용요소가 있는 곳을 아는 사람 당신의 조직에서, 개발자와, 디자이너들은 설계, 프레임워크, 라이브러리, 코드조각의 존재와 재사용하기 위한 모든 중대한 정보(예: 문서, 버전, 호환성)를 어디서 찾아야 할지 알아야 한다 간단히 말하자면, 사람들은 없다고 생각하는 것들을 찾으려 하지 않는다. 만약 재사용 요소들에 대한 정보를 전달(push)한다면 당신은 더욱 성공에 가까워 질 것이다.
기업에서 재사용 요소의 정보 전달을 위한 다양한 방법이 있다. 업데이트된 정보를 RSS feed로 전달해줄 수 있는 위키페이지(대규모 팀에서 유용한)부터 소스 레파지토리내의 버전 업데이트를 이메일로 알려주는 방법까지 다양합니다.작은 팀에서의 디자이너나 수석개발자는 그의 동료들에게 직접 이야기 하거나 사무실 건너편으로 외침으로 알릴 수 있다. 궁극적으로 당신의 재사용 요소들에 관해 의사소통 프로세스가 무엇이든 간에 운에 맞기지 말고 당신이 소유하도록 확실히 해야 한다.
재사용요소를 사용할 수 있는 사람 요소를 재사용 하는 법을 이해하는 것은 기술과 훈련에 달려있다. 물론 코딩과 설계에 “resonate:공명(Donald Knuth의 전문용어)”하는 사람이 있다. 우리는 천부적인 개발자와 무서울 정도로 빠르고 깊이 있는 이해로 뛰어난 아키텍트들과 함께 일해왔다. 그러나 그런 사람들은 흔치 않다. 팀의 나머지 사람은 착하고 충실하고 영리한 개발자와 설계자들로 구성될 것이다. 그들은 교육을 받아야 한다.
개발자와 디자이너들은 프레임워크설계자가 사용하도록 의도한 상속모델을 완전히 이해 못하거나 설계에서 사용된 특정 디자인패턴을 알지 못할 수도 있다. 그들에게 최신문서형태로 정보를 쉽게 접속하는 방법이나 더 나은 훈련 이 제공되어야 한다. 작은 훈련은 모든 사람이 재 사용하려 할 때 같은 위치에 있게 한다.
자신이 스스로 하는 것보다 재사용 요소가 낫다고 확신하는 사람 사람들, 특별히 개발자들은 문제를 해결함에 있어 도움을 요청하기보다 스스로 해결하는 경향이 있다. 어떻게 동작하는 것을 물어보는 것은 나약함의 표시이거나 무지의 표시로 받아들인다. 당신의 개별 팀 멤버의 성숙도와 성격 유형에 따라 많은 할일 들이 있다. “스스로 그것을 하는 것보다 더 나은”이라는 말은 다른 사람에 대한 다른 일을 의미한다. 팀 내의 초년생 들은 항상 그들 자신의 것을 쓰기 원할 것이다. 왜냐하면 이것이 그들의 자아를 나타내기 때문이다. 그에 반해 경험 많은 사람은 문제영역의 생각을 갖고 해결점을 제공한 다른 사람의 의견을 받아들일 것이다.
만약 당신의 팀이 재사용할 산출물이 어디 있는지 찾지 못하거나 어떻게 재사용할 지 모른다면 그들 자신이 스스로 만드는 인간으로서의 자연스러운 태도를 불이행 하는 것일 것이다. 그리고 당신은(아키텍트로) 그 대가를 지불하게 될것이다.
Written By Jeremy Meyer Jeremy Meyer는 20년 가까이 소프트웨어 설계와 개발의 전문지식을 가르치고 해왔다. 그는 현재 Boland Software의 모델링과 설계영역에 수석 컨설턴트 이다.
