본문 바로가기

Homo Architect/Things Every SW Architect Should Know

(24)
소프트웨어 아키텍트가 알아야 할 97가지 [책소개] '아키텍처' 라는 단어에는 많은 의미들이 포함되어 있으며, 특히 SW 분야에서 아키텍처를 만드는 아키텍트에게 너무나 많은 역할이 부여되는 것이 사실입니다. 구태여 '소프트웨어'라는 단어를 붙인 이유는 수많은 의미로 아키텍처/아키텍트라는 단어를 사용하기 때문에 더욱 강조를 한 것 같습니다. '소프트웨어 아키텍트가 알아야 할 97가지' (원제 : 97 Things Every Software Architect Should Know') 라는 책은 처음에 블로그를 통해서 여러 SW 아키텍트들의 이야기를 접하게 되었습니다. 그 후, 본격적인 출판 작업 O'Reilly에서 진행하면서 위키로 해당 내용들을 옮겼습니다. 이 책의 내용은 여러 SW 아키텍트들이 경험한 내용을 이야기하듯이 적고 있습니다. 위키에 있는 내용들..
'공통'은 모든 사람들이 접근하는 광장이다. 대형이든 소형이든 대부분의 프로젝트에서는 아키텍트팀과 업무를 중심으로 한 업무 개발팀으로 나눕니다. 업무는 비즈니스로부터 구획화가 되며, 각 업무 간에는 의존관계로 연결됩니다. 하지만, 비즈니스가 칼로 자르듯이 구획화가 힘든 부분이 발생되기도 하며, 이는 비즈니스를 구현하는 IT 입장에서도 명확하게 나누는 것이 힘든 경우도 발생됩니다. 이와 같은 일이 발생되는 경우에 가장 흔하게 사용되는 것이 업무 공통이라는 영역을 나누는 방식입니다. 즉, 어느 업무 팀에도 할당하기 애매모호한 것들을 통틀어서 공통이라는 영역으로 두게 됩니다. 일단 공통이라는 영역을 두게 되면, 수많은 애매모호한 성격의 일들이 이 영역으로 들어오게 됩니다. 심지어는 두 업무 사이에 명확하게 나누기 힘든 것 역시 이러한 공통 영역으로 들어..
고객은 '버라이어티 정신'을 원한다. 이미 TV 프로그램의 대세가 되어버린 '버라이어티' 쇼 프로그램들은 시청자의 요구가 이미 이러한 환경으로 바뀌었음을 나타내는 증거입니다. 새로 생겨나는 TV 프로그램들이 이러한 환경에 제대로 적응하지 못하면, 시청률을 기준으로 퇴출당하게 되는 일은 이미 예삿일이 되어버렸습니다. '버라이어티' 프로그램들은 시청자의 마음을 읽고, 기존의 전형적인 프로그램의 기획을 과감하게 탈피하고 있습니다. 사전에 무엇을 할지를 기획하고, 기획된 대로 작업 시간을 만들고, 대본을 미리 만들어서 연습을 하고, 실제 촬영에서는 주어진 각본대로 찍고 또 찍는 것이 기존의 전형적인 틀이었습니다. 하지만, 이제 이러한 전형적인 틀로 찍어낸 TV 프로그램들은 시청자들에게 외면받는 시대가 되었습니다. 소프트웨어 프로젝트 역시 이러한 환..
표준화(standardization)와 혁신(innovation) 표준화는 일에 대한 생산성을 높이는데 일조를 담당한다. 즉, 일을 수행하는데 있어서 표준화가 되어 있으며, 생산성이 날 수 있다. 하지만, 표준화라는 말을 잘 살펴보면, 표준화를 통해 일을 수행하는 것은 동일한 입력과 동일한 산출물을 내는 작업에 적합하다고 볼 수 있다. 만일, 해당 작업을 수행하는 동안 이전과 다른 입력물을 가지고 작업하게 되면 다른 산출물을 내는 것은 당연한 결과이다. 표준화는 이러한 다양성에 대한 부분을 감독 및 통제하는 형태로 나타나게 되며, 결국 프로세스 통제라는 형태로 나타나게 된다. 소프트웨어 개발은 그럼 위와 같은 표준화라는 의미에서 표준화가 가능한 작업을 수행할 수 있을까? 결론을 말하자면, 결코 그렇지 못하다는 것이다. 어느 한 프로젝트에서의 설계 작업은 다른 프로젝트에..
지속적으로 통합하라. - David Bartlett Dave Bartlett은 프로그래머, 개발자, 아키텍트, 관리자, 컨설턴트, 교육자로서 25년 이상의 경험을 가진 열정적인 소프트웨어 전문가이다. 그는 현재 사설 컨설팅 회사인 Commotion Technologies 사에서 일을 하고 있으며, Pennsylvania 주의 Great Valley에 위치한 Penn State 대학의 대학원 과정에서 강의 중이다. 현재 그의 주요 작업은 미 필라델피아 연방준비은행에서 연방준비 시스템과 미 재무부 내에서 사용하는 웹, 포탈, 복합 어플리케이션 설계와 구축에 대해 조언을 하는 것이다. 프로젝트 개발에서 “빅뱅” 과 같은 빌드는 이제 사망했습니다. 어플리케이션 아키텍트이건 엔터프라이즈 아키텍트이건 , 아키텍트는 지속적인 통합 방법과..
아키텍트는 직접 실무를 담당해야 한다. - John Davies John Davies는 현재 미국 Revolution Money사 최고 아키텍트이다. 그는 최근 Incept5 라고 하는 새로운 기업을 시작했다. 좋은 아키텍트는 사례를 통해 팀을 이끌어야 합니다. 아키텍트는 네트워크를 설치하고 빌드 프로세스를 설정하는 것에서부터 단위 테스트를 작성하고 벤치마킹을 수행하는 것까지 자신의 팀 내 어떠한 역할도 수행할 수 있어야 합니다. 기술에 대한 모든 영역에 충분한 이해 없이는 아키텍트는 그저 프로젝트 관리자에 지나지 않습니다. 팀 멤버들이 자신들의 특정 영역에 깊은 지식을 많이 갖고 있는 것은 당연한 일입니다. 그런데 만일 아키텍트가 해당 기술을 이해하지 못하고 있다면 팀 멤버들이 어떻게 그 아키텍트를 신뢰할 수 있을지 상상하기 어렵습니다. 어..
손쉬운 방법은 이후에 이자가 붙어서 되돌려 받게 된다. - Scot Mcphee Scot Mcphee는 어플리케이션 코딩과 설계에 15년 이상의 경험을 가진 호주의 소프트웨어 개발자/아키텍트이다. 지난 8년 동안 그는 거의 J2EE 분야에서 종사해왔다. 유지보수하려는 시스템을 아키텍팅할 때 결국 프로젝트의 초기 개발보다 더 많은 자원이 소모될 것이라는 사실을 기억하는 것은 중요합니다. 프로젝트의 개발 초기 단계 기간 적용되었던 손쉬운 방법은 이후에 심각한 유지보수 비용을 발생시킬 수 있습니다. 예를 들어, 단위 테스트가 직접적인 가치를 부여하지 않는다는 정보를 들은 적이 있어서 여러분은 개발자들에게 단위테스트에 대한 엄격한 적용을 건너뛰도록 전달합니다. 이는 인도된 시스템이 향후 미래에 변경을 더 어렵게 하는 원인이 되며, 그러한 변화를 수용할 때 신뢰를 떨..
하드웨어 역시 이해해야 한다. - Kamal Wickramanayake - 블로그 : http://www.swview.org/ Karnal Wickramanayke는 스리랑카에서 IT와 소프트웨어 아키텍트를 수행하고 있다. 그는 The Open Group에서 TOGAF 인증을 받았다. 많은 소프트웨어 아키텍트들에게 하드웨어 용량 산정은 결코 마음 편히 작업할 수 있는 영역이 아닌 곳에 위치한 주제이지만, 아키텍트 작업의 중요한 부분으로 남아 있습니다. 왜 소프트웨어 아키텍트가 하드웨어를 적절하게 고려하는데 자주 실패하는지에 대한 수많은 원인이 있지만, 아키텍트 대부분이 하드웨어 이해에 대한 부족과 불명확한 요구사항과 관련이 있습니다. 하드웨어 고려사항을 무시하는 주요한 원인은 아키텍트들이 소프트웨어만 초점을 맞추고 하드웨어 요구에 대..

반응형