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)
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"
위 글은 두 가지 관점에서 볼 수 있다. 하나는 아키텍트의 책임감 측면이다. '아키텍트'라는 사람이 구현기술에 대한 상세한 내용은 내 일이 아니라며 미루는 모습을 자주 볼 수 있다. 물론, 본인 스스로 모든 것을 해결할 수도 없고, 그럴 필요도 없다. 하지만, 적어도 '아키텍트'가 아키텍처 이슈(시스템 전반에 영향을 미치는 사항)를 개발팀에 떠넘기는 것은 문제가 있다. 또 다른 측면은 '아키텍트'의 높은 몸값 때문에 프로젝트 초반에만 고용하는 점이다. 만일 아키텍트가 철수한다면 어떻게 아키텍처를 지켜나갈지 방책을 마련해둬야 한다.
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.)을 이해하지 못할 수도 있다. 최근에 고객 업무에 깊이 관여하면서 일치감을 느껴 신규 업무 설계와 화면을 만든 짜릿한 경험을 했는데, 개발자에 대해서도 마찬가지다. 유명한 국내 아키텍트 중에도 실제 구현 과정에서 겪는 어려움을 무시해서 모두를 어렵게 만드는 이에 대해 듣곤 한다.
개발자에게 아키텍트 역할에 대한 강연을 준비하던 글인 듯한데.. 마무리가 인상 깊다.
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.
사이먼 말처럼 개발자이지만 이미 아키텍트의 역할을 (일부라도) 수행하는 이도 있다. 반대로 지겨운 개발(?)을 그만두기 위해 아키텍트를 꿈꾼다는 이해하기 어려운 사람도 어렵지 않게 만날 수 있다.
관련 글:
이올린에 북마크하기
이올린에 추천하기
