검색결과 리스트
소프트웨어 아키텍트에 해당되는 글 2건
- 2010/02/12 소프트웨어 아키텍트의 일에 대한 메모 (하)
- 2010/02/11 소프트웨어 아키텍트의 일에 대한 메모 (상) (1)
글
소프트웨어 아키텍트의 일에 대한 메모 (하)
분류없음
2010/02/12 08:30
InfoQ 글(Are You a Software Architect?)에 메모를 추가함
이젠 앞서 정의한 아키텍처를 제대로 구현해내는 일(Delivery of the software architecture)이다.
Ownership of the bigger picture
아키텍트의 책임감을 요구하는 부분이다. 임무 완수(through to a successful conclusion)를 위해선 영업사원 마냥 개발팀 여러 구성원에게 아키텍처를 이해시키고 동조를 얻어야 한다.(sells the vision throughout the entirety of the software development lifecycle) 단기 프로젝트가 아니라면 개발 과정에서 얻어진 새로운 정보(혹은 요구사항)에 의해 변경도 필요하다.(evolving it throughout the project if necessary)
위 글은 두 가지 관점에서 볼 수 있다. 하나는 아키텍트의 책임감 측면이다. '아키텍트'라는 사람이 구현기술에 대한 상세한 내용은 내 일이 아니라며 미루는 모습을 자주 볼 수 있다. 물론, 본인 스스로 모든 것을 해결할 수도 없고, 그럴 필요도 없다. 하지만, 적어도 '아키텍트'가 아키텍처 이슈(시스템 전반에 영향을 미치는 사항)를 개발팀에 떠넘기는 것은 문제가 있다. 또 다른 측면은 '아키텍트'의 높은 몸값 때문에 프로젝트 초반에만 고용하는 점이다. 만일 아키텍트가 철수한다면 어떻게 아키텍처를 지켜나갈지 방책을 마련해둬야 한다.
Leadership
아키텍처는 역할에 의해 권위를 갖지만 기술적 결정과 가이드(providing technical guidance, making technical decisions) 책임 역시 갖는다. 아키텍트의 권위는 당연한 이야기처럼 들리지만 실제로 충부한 권위를 갖지 못하는 경우가 많다.(The software architect position is inherently about leadership and while this sounds obvious, many project teams don't get the technical leadership that they need ...)
Coaching and mentoring
국내 현실에서는 아키텍처 구현을 위한 가이드를 하다 보면 자바 문법이나 디버깅 방법까지 묻는 경우가 발생하고, 새로운 기술에 대한 거부감/저항/두려움을 갖은 인력을 만나는 일이 잦다. 게다가 설계 결정까지 개발자에게 넘겨서 난감한 구현을 만들어내는 일이 흔하다. 개발인력을 일시적인 노동력으로만 보는 현상과 지나치게 개발 절차 자체를 강조하는 경우, 코드가 아닌 문서 형태의 중간 산출물로 진척을 확인하는 현상과 관계가 있는 듯하다.
Quality assurance
품질보증(QA)을 위해서 보통 '표준화'라는 추상적인 이름으로 코딩 표준이나 설계 원칙(coding standards, design principles)에 대한 리뷰가 필요히다. 리뷰는 시간과 노력이 많이 필요한 작업으로 CI 도구나 테스트 지원 도구(continuous integration, automated unit testing and code coverage tools)의 지원이 필요하다. 개발자 테스트 없는 CI 도구를 이용한 자동화 빌드만으로도 아주 기본적인 통합은 보장할 수 있다. 최근에도 형상 불일치 문제로 오픈을 못한 사이트 소문을 듣곤 하는데 일부 개발자의 변화에 대한 초기 저항감만 누르면 쉽게 적용할 수 있다. 하지만, 자동화 테스트는 조금 다르다. 현실적인 기준선(baseline)으로 DAO에 대한 테스트에 초점을 맞추는데, 테스트 품질을 높이려면 다양한 현실적 사례(가령, 조회 요청에 대한 테스트라면 복잡한 조회 조건의 현실적인 경우의 수를 뽑아내 모두 테스트케이스로 수렴해야 함)를 테스트에 담아야 하는데 능동적으로 이를 이행하기란 아웃소싱이 기본인 SI 현실에서 불가능이라고 할 수 있다. 현실적 제약을 인정하면, '모 아니면 도'식 접근 대신 중요한 코드(architecturally significant, business critical, complex or highly visible) 테스트로 범위를 좁히는 것도 실용적인 접근이다.
국내 SI 프로젝트에서 자동화 테스트는 높은 ROI(투자 대비 수익)를 뽑을 수 있다고 생각한다. 일각에서는 이를 인지하고 실천하는 움직임이 보인다. 하지만, 여전히 대다수의 프로젝트에서 QA하면 절차(프로세스)에 대해서만 고민하고, 지나치게 문서에 매달리며 시간을 낭비한다. 소프트웨어도 제조물과 마찬가지로 제품에 대한 품질이 최우선이다.
Design, development and testing
Simon Brown와 내 생각은 거의 비슷하다. 그가 아키텍트의 몸값 탓("too valuable to undertake that commodity work")에 조직에서 코딩을 못하게 하는 점을 지적했는데, 외국이나 우리나 현실이 비슷한 모양이다. But generally speaking, an architect that codes is more effective and happier than an architect that watches from the sidelines. 라는 말에 동의하지만, 게다가(In addition)로 부연한 내용이 더 중요하게 생각된다.
아키텍트가 꼭 코딩을 할 필요는 없다고 생각하지만, 만일 코딩을 하지 않으면 실제로 개발자 입장(the architect can experience the same pain as everybody else on the team, which in turn helps them better understand how their architecture is viewed from a development perspective.)을 이해하지 못할 수도 있다. 최근에 고객 업무에 깊이 관여하면서 일치감을 느껴 신규 업무 설계와 화면을 만든 짜릿한 경험을 했는데, 개발자에 대해서도 마찬가지다. 유명한 국내 아키텍트 중에도 실제 구현 과정에서 겪는 어려움을 무시해서 모두를 어렵게 만드는 이에 대해 듣곤 한다.
개발자에게 아키텍트 역할에 대한 강연을 준비하던 글인 듯한데.. 마무리가 인상 깊다.
사이먼 말처럼 개발자이지만 이미 아키텍트의 역할을 (일부라도) 수행하는 이도 있다. 반대로 지겨운 개발(?)을 그만두기 위해 아키텍트를 꿈꾼다는 이해하기 어려운 사람도 어렵지 않게 만날 수 있다.
관련 글:
이젠 앞서 정의한 아키텍처를 제대로 구현해내는 일(Delivery of the software architecture)이다.
Ownership of the bigger picture
아키텍트의 책임감을 요구하는 부분이다. 임무 완수(through to a successful conclusion)를 위해선 영업사원 마냥 개발팀 여러 구성원에게 아키텍처를 이해시키고 동조를 얻어야 한다.(sells the vision throughout the entirety of the software development lifecycle) 단기 프로젝트가 아니라면 개발 과정에서 얻어진 새로운 정보(혹은 요구사항)에 의해 변경도 필요하다.(evolving it throughout the project if necessary)
If you've defined an architecture, it makes sense to remain continuallyengaged and evolve your architecture rather than choosing to hand itoff to an "implementation team"
위 글은 두 가지 관점에서 볼 수 있다. 하나는 아키텍트의 책임감 측면이다. '아키텍트'라는 사람이 구현기술에 대한 상세한 내용은 내 일이 아니라며 미루는 모습을 자주 볼 수 있다. 물론, 본인 스스로 모든 것을 해결할 수도 없고, 그럴 필요도 없다. 하지만, 적어도 '아키텍트'가 아키텍처 이슈(시스템 전반에 영향을 미치는 사항)를 개발팀에 떠넘기는 것은 문제가 있다. 또 다른 측면은 '아키텍트'의 높은 몸값 때문에 프로젝트 초반에만 고용하는 점이다. 만일 아키텍트가 철수한다면 어떻게 아키텍처를 지켜나갈지 방책을 마련해둬야 한다.
아키텍처는 역할에 의해 권위를 갖지만 기술적 결정과 가이드(providing technical guidance, making technical decisions) 책임 역시 갖는다. 아키텍트의 권위는 당연한 이야기처럼 들리지만 실제로 충부한 권위를 갖지 못하는 경우가 많다.(The software architect position is inherently about leadership and while this sounds obvious, many project teams don't get the technical leadership that they need ...)
Coaching and mentoring
국내 현실에서는 아키텍처 구현을 위한 가이드를 하다 보면 자바 문법이나 디버깅 방법까지 묻는 경우가 발생하고, 새로운 기술에 대한 거부감/저항/두려움을 갖은 인력을 만나는 일이 잦다. 게다가 설계 결정까지 개발자에게 넘겨서 난감한 구현을 만들어내는 일이 흔하다. 개발인력을 일시적인 노동력으로만 보는 현상과 지나치게 개발 절차 자체를 강조하는 경우, 코드가 아닌 문서 형태의 중간 산출물로 진척을 확인하는 현상과 관계가 있는 듯하다.
Quality assurance
품질보증(QA)을 위해서 보통 '표준화'라는 추상적인 이름으로 코딩 표준이나 설계 원칙(coding standards, design principles)에 대한 리뷰가 필요히다. 리뷰는 시간과 노력이 많이 필요한 작업으로 CI 도구나 테스트 지원 도구(continuous integration, automated unit testing and code coverage tools)의 지원이 필요하다. 개발자 테스트 없는 CI 도구를 이용한 자동화 빌드만으로도 아주 기본적인 통합은 보장할 수 있다. 최근에도 형상 불일치 문제로 오픈을 못한 사이트 소문을 듣곤 하는데 일부 개발자의 변화에 대한 초기 저항감만 누르면 쉽게 적용할 수 있다. 하지만, 자동화 테스트는 조금 다르다. 현실적인 기준선(baseline)으로 DAO에 대한 테스트에 초점을 맞추는데, 테스트 품질을 높이려면 다양한 현실적 사례(가령, 조회 요청에 대한 테스트라면 복잡한 조회 조건의 현실적인 경우의 수를 뽑아내 모두 테스트케이스로 수렴해야 함)를 테스트에 담아야 하는데 능동적으로 이를 이행하기란 아웃소싱이 기본인 SI 현실에서 불가능이라고 할 수 있다. 현실적 제약을 인정하면, '모 아니면 도'식 접근 대신 중요한 코드(architecturally significant, business critical, complex or highly visible) 테스트로 범위를 좁히는 것도 실용적인 접근이다.
국내 SI 프로젝트에서 자동화 테스트는 높은 ROI(투자 대비 수익)를 뽑을 수 있다고 생각한다. 일각에서는 이를 인지하고 실천하는 움직임이 보인다. 하지만, 여전히 대다수의 프로젝트에서 QA하면 절차(프로세스)에 대해서만 고민하고, 지나치게 문서에 매달리며 시간을 낭비한다. 소프트웨어도 제조물과 마찬가지로 제품에 대한 품질이 최우선이다.
Design, development and testing
Simon Brown와 내 생각은 거의 비슷하다. 그가 아키텍트의 몸값 탓("too valuable to undertake that commodity work")에 조직에서 코딩을 못하게 하는 점을 지적했는데, 외국이나 우리나 현실이 비슷한 모양이다. But generally speaking, an architect that codes is more effective and happier than an architect that watches from the sidelines. 라는 말에 동의하지만, 게다가(In addition)로 부연한 내용이 더 중요하게 생각된다.
아키텍트가 꼭 코딩을 할 필요는 없다고 생각하지만, 만일 코딩을 하지 않으면 실제로 개발자 입장(the architect can experience the same pain as everybody else on the team, which in turn helps them better understand how their architecture is viewed from a development perspective.)을 이해하지 못할 수도 있다. 최근에 고객 업무에 깊이 관여하면서 일치감을 느껴 신규 업무 설계와 화면을 만든 짜릿한 경험을 했는데, 개발자에 대해서도 마찬가지다. 유명한 국내 아키텍트 중에도 실제 구현 과정에서 겪는 어려움을 무시해서 모두를 어렵게 만드는 이에 대해 듣곤 한다.
개발자에게 아키텍트 역할에 대한 강연을 준비하던 글인 듯한데.. 마무리가 인상 깊다.
Most developers don't wake up on a Monday morning and declare
themselves to be a software architect. I certainly didn't and my route
into software architecture was very much an evolutionary process.
Having said that though, there's a high probability that those same
developers are already undertaking parts of the software architecture role, irrespective of their job title.
사이먼 말처럼 개발자이지만 이미 아키텍트의 역할을 (일부라도) 수행하는 이도 있다. 반대로 지겨운 개발(?)을 그만두기 위해 아키텍트를 꿈꾼다는 이해하기 어려운 사람도 어렵지 않게 만날 수 있다.
관련 글:
글
소프트웨어 아키텍트의 일에 대한 메모 (상)
2010
2010/02/11 08:30
InfoQ 에서 흥미로운 글을 올렸다.
Are You a Software Architect?
아키텍처는 시스템이 전체적으로 어찌 구동하는가를 이해하는 큰 그림에 대한 것이라는 일반적인 이야기를 해놓고, 이것만으로는 부족하다며 말을 잇는다.
그리고 바로 중요한 두 가지 사실을 꺼내 놓는다.
하나는 아키텍트는 경험이 필요하며 하루아침에 만들어지는 것이 아니라 서서히 키워지는 것이란 점(It's an evolutionary process where you'll gradually gain the experience and confidence that you need to undertake the role.)
두 번째는 아키텍트는 역할이지 등급이 아니란 점. 사실 이 말이 피부에 와 닿으려면 아키텍트보다 높은 대가를 받는 고급 개발자가 있어야 하지 않을까?
점차 심도 있는 이야기를 꺼내는데 아키텍트가 행해야 하는 다양한 행위(involvement, influence, leadership and responsibility)를 설명하기 위해 아키텍처를 정의하는 측면과 구현하는 측면으로 나눠(Broadly speaking, the software architecture on most projects can be broken down into two phases; the architecture is defined and then it's delivered.) 부연을 시도한다.
Definition of the software architecture
떡 하니 다섯 개 영역으로 나눈 그림을 제시한다. 그림을 보고 문득 이런 생각이 든다. 만일 암기에 의해서가 아니라 경험에 의해서 아키텍트로 프로젝트에 참여했을 때 해야 할 일이 아래 그림처럼 자명하게 떠오르고, 프로젝트 규모와 기간, 해당 시스템의 업무적 특성, 그리고 사용 조직의 특성 등을 고려해 각각 방법을 만들어낼 수 있다면 스스로 전문적인 아키텍트라 칭해도 좋겠다는 생각을 한다. (반대로 그렇지 못하다면?)
Management of non-functional requirements
기능 요구사항과 달리 고객이 요구사항을 매우 모호하게('빠르게', '불편하지 않게') 주거나 아니면 아예 주지 않는다. 온라인 애플리케이션은 예상 사용자 규모에 따라 성능을 산정해야 하는 기술적 어려움이 따르고, 업무 프로세스와 관계된 배치(batch) 업무는 실제 업무 방식을 모르면 성능 기준을 수립조차 하기 어렵다. '잘하는 법'을 교육하기는 어렵지만, 잘 다듬어진 템플릿과 예제가 도움을 주긴 한다. 종종 몇몇 조직에서 EA나 프로세스 관련 프로젝트를 수행하고 나서 (다른 산출물은 유명무실하게 버려두지만) 비 기능 요구사항에 대한 체크리스트를 널리 재사용하는 경우를 본다.
Architecture definition
적절한 수준으로 비 기능 요구사항의 설정하면(captured) 아키텍처를 정의한다. 아키텍처 정의를 이루는 활동을 간략히 언급(Architecture definition is about introducing structure, guidelines, principles and leadership to the technical aspects of a software project.)하고 설명하는 글에서 두 가지 사항이 눈에 띈다.
모든 시스템이 (정의을 하든 아니든) 아키텍처를 갖기는 하겠지만 항상 아키텍처를 정의하는 것은 아니란 점
It's fair to say that every software system has an architecture, but not every software system has a defined architecture.
그리고 신규 시스템이냐 기존 시스템 수정이냐에 따라 크게 다르다는 점
there's a big difference between designing a software system from scratch and extending an existing one.
Technology selection
기술 선택을 할 때 고려할 다양한 사항을 열거한다. cost, licensing, vendor relationships, technology strategy, compatibility, interoperability, support, deployment, upgrade policies, end-user environments. 또, 기술 선택에는 위험이 따르기 때문에 검토와 평가가 필요하다. (need to be reviewed and evaluated)
위에 열거한 항목 외에도 흔한 일은 아니지만, 법적 문제나 기술 제공 업체(vendor)의 경제력이 문제가 되는 일도 있다. 국내 솔루션이 외산 솔루션 복제 소송에 휘말린 경우가 있고, 직원 월급을 지급하지 못해 솔루션 커스터마이징 인력이 안정적으로 일하지 못하는 경우가 발생한 바 있다.
역시 신규 시스템이냐 기존 시스템 수정이냐에 따라 기술 선택도 달라진다.
Again there's a big difference between evaluating technology for a new system versus adding technology into an existing system.
Architecture evaluation
소프트웨어가 갖는 복잡함과 추상적 성격 탓에 이해관계자에게 '구현할 소프트웨어가 어떤 것'인지 보여주기 어렵다. 시스템뿐 아니라 아키텍처도 테스트해야 한다. 요즘은 많은 프로젝트에서 파일럿을 통해 아키텍처를 검증한다. 주어진 제약(기간, 자원, 예산)하에서 무엇을 검증하느냐가 결국 관건이다. 막연히 잘 되기를 바라지 말고, 위험요소에 대해 적극적으로 대처해야 한다.(And if you can do this as early as possible, you can reduce the overall risk of project failure rather than simply hoping for the best)
Architecture collaboration
아키텍처는 개발자 관점뿐 아니라 다양한 측면(a security, database, operations, maintenance, support)에서 긴밀한 협업을 이끌어야 한다. 규모가 커질수록 서로 다른 많은 회사나 팀이 참여하게 되니 실천이 쉽지 않다.
관련 글: Architects architect architecture!
Are You a Software Architect?
Software architecture is all about having a holistic view and seeing
the bigger picture to understand how the software system works as a
whole.
아키텍처는 시스템이 전체적으로 어찌 구동하는가를 이해하는 큰 그림에 대한 것이라는 일반적인 이야기를 해놓고, 이것만으로는 부족하다며 말을 잇는다.
그리고 바로 중요한 두 가지 사실을 꺼내 놓는다.
Becoming a software architect isn't something that simply happens overnight or with a promotion. It's a role, not a rank.
하나는 아키텍트는 경험이 필요하며 하루아침에 만들어지는 것이 아니라 서서히 키워지는 것이란 점(It's an evolutionary process where you'll gradually gain the experience and confidence that you need to undertake the role.)
두 번째는 아키텍트는 역할이지 등급이 아니란 점. 사실 이 말이 피부에 와 닿으려면 아키텍트보다 높은 대가를 받는 고급 개발자가 있어야 하지 않을까?
점차 심도 있는 이야기를 꺼내는데 아키텍트가 행해야 하는 다양한 행위(involvement, influence, leadership and responsibility)를 설명하기 위해 아키텍처를 정의하는 측면과 구현하는 측면으로 나눠(Broadly speaking, the software architecture on most projects can be broken down into two phases; the architecture is defined and then it's delivered.) 부연을 시도한다.
Definition of the software architecture
떡 하니 다섯 개 영역으로 나눈 그림을 제시한다. 그림을 보고 문득 이런 생각이 든다. 만일 암기에 의해서가 아니라 경험에 의해서 아키텍트로 프로젝트에 참여했을 때 해야 할 일이 아래 그림처럼 자명하게 떠오르고, 프로젝트 규모와 기간, 해당 시스템의 업무적 특성, 그리고 사용 조직의 특성 등을 고려해 각각 방법을 만들어낼 수 있다면 스스로 전문적인 아키텍트라 칭해도 좋겠다는 생각을 한다. (반대로 그렇지 못하다면?)
Management of non-functional requirements
기능 요구사항과 달리 고객이 요구사항을 매우 모호하게('빠르게', '불편하지 않게') 주거나 아니면 아예 주지 않는다. 온라인 애플리케이션은 예상 사용자 규모에 따라 성능을 산정해야 하는 기술적 어려움이 따르고, 업무 프로세스와 관계된 배치(batch) 업무는 실제 업무 방식을 모르면 성능 기준을 수립조차 하기 어렵다. '잘하는 법'을 교육하기는 어렵지만, 잘 다듬어진 템플릿과 예제가 도움을 주긴 한다. 종종 몇몇 조직에서 EA나 프로세스 관련 프로젝트를 수행하고 나서 (다른 산출물은 유명무실하게 버려두지만) 비 기능 요구사항에 대한 체크리스트를 널리 재사용하는 경우를 본다.
적절한 수준으로 비 기능 요구사항의 설정하면(captured) 아키텍처를 정의한다. 아키텍처 정의를 이루는 활동을 간략히 언급(Architecture definition is about introducing structure, guidelines, principles and leadership to the technical aspects of a software project.)하고 설명하는 글에서 두 가지 사항이 눈에 띈다.
모든 시스템이 (정의을 하든 아니든) 아키텍처를 갖기는 하겠지만 항상 아키텍처를 정의하는 것은 아니란 점
It's fair to say that every software system has an architecture, but not every software system has a defined architecture.
그리고 신규 시스템이냐 기존 시스템 수정이냐에 따라 크게 다르다는 점
there's a big difference between designing a software system from scratch and extending an existing one.
Technology selection
기술 선택을 할 때 고려할 다양한 사항을 열거한다. cost, licensing, vendor relationships, technology strategy, compatibility, interoperability, support, deployment, upgrade policies, end-user environments. 또, 기술 선택에는 위험이 따르기 때문에 검토와 평가가 필요하다. (need to be reviewed and evaluated)
위에 열거한 항목 외에도 흔한 일은 아니지만, 법적 문제나 기술 제공 업체(vendor)의 경제력이 문제가 되는 일도 있다. 국내 솔루션이 외산 솔루션 복제 소송에 휘말린 경우가 있고, 직원 월급을 지급하지 못해 솔루션 커스터마이징 인력이 안정적으로 일하지 못하는 경우가 발생한 바 있다.
역시 신규 시스템이냐 기존 시스템 수정이냐에 따라 기술 선택도 달라진다.
Again there's a big difference between evaluating technology for a new system versus adding technology into an existing system.
Architecture evaluation
소프트웨어가 갖는 복잡함과 추상적 성격 탓에 이해관계자에게 '구현할 소프트웨어가 어떤 것'인지 보여주기 어렵다. 시스템뿐 아니라 아키텍처도 테스트해야 한다. 요즘은 많은 프로젝트에서 파일럿을 통해 아키텍처를 검증한다. 주어진 제약(기간, 자원, 예산)하에서 무엇을 검증하느냐가 결국 관건이다. 막연히 잘 되기를 바라지 말고, 위험요소에 대해 적극적으로 대처해야 한다.(And if you can do this as early as possible, you can reduce the overall risk of project failure rather than simply hoping for the best)
Architecture collaboration
아키텍처는 개발자 관점뿐 아니라 다양한 측면(a security, database, operations, maintenance, support)에서 긴밀한 협업을 이끌어야 한다. 규모가 커질수록 서로 다른 많은 회사나 팀이 참여하게 되니 실천이 쉽지 않다.
관련 글: Architects architect architecture!
