Younghoe.Info v3

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.)을 이해하지 못할 수도 있다. 최근에 고객 업무에 깊이 관여하면서 일치감을 느껴 신규 업무 설계와 화면을 만든 짜릿한 경험을 했는데, 개발자에 대해서도 마찬가지다. 유명한 국내 아키텍트 중에도 실제 구현 과정에서 겪는 어려움을 무시해서 모두를 어렵게 만드는 이에 대해 듣곤 한다.

 
개발자에게 아키텍트 역할에 대한 강연을 준비하던 글인 듯한데.. 마무리가 인상 깊다.


사이먼 말처럼 개발자이지만 이미 아키텍트의 역할을 (일부라도) 수행하는 이도 있다. 반대로 지겨운 개발(?)을 그만두기 위해 아키텍트를 꿈꾼다는 이해하기 어려운 사람도 어렵지 않게 만날 수 있다.

관련 글:

• 소프트웨어 아키텍트의 일에 대한 메모 (상)
• Architects architect architecture!

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!

요즘 가장 마음에 드는 블로그인 @Kirkk 에 올라온 그림이다. 시조를 연상시키는 문구도 인상적이다.


우리말로 바꿔 의미 전달하긴 어려운 문장처럼 보인다. 본문은 이어서 각 단어가 나타내는 세 가지 측면에 대해 짤막하게 설명을 덧붙이고 있다.

첫 번째는 사회적 측면인데 언젠가 한번 발췌했던 그림으로 많은 부분을 표현하고 있다.



노련한 선배 아키텍트로부터 들었던 '사람과 사회를 이해하지 못하면 아키텍처를 이해하기 어렵다.'는 조언이 떠올랐다. 각자 처한 상황이나 관점의 차이에서 비롯한 이해 결여가 위 그림에 음영으로 그려진 부분이다. @Kirkk 에서는 이 부분을 가시화하는 일이 아키텍처에 대한 이해와 공유(understanding, visibility, and transparency)에 유익하다고 말하고 있다.



두 번째는 기술적 측면인데 입자가 다른 요소 사이에서 틈을 메우는 일을 강조하고 있다. components, composition, interfaces, subsystems, and structure 등을 키워드로 들고 있다. 이론으로는 오래전에 깔끔하게 정리된 듯 보이기도 하지만, 현실은 무척 더디다.



세 번째는 최근에 체험하고 고민하는 프로세스 측면이다.


최근 아주 촉박한 일정으로 중요 모듈 개발을 맡았다. 아이러니하게 촉박한 일정 덕분에 느긋하게 다이어그램을 그리는 방식 대신 테스트 코드와 인터페이스로 Workflow를 정의(pure java)하고, 실 환경(was, dbms, shell, 상용 솔루션, ...)에서 개발/검증하고 개선하는 사이클을 반복했다. UI 설계 과정에서 업무 정의가 필요하고, 빠른 의사결정을 끌어내기 위해 UI의 배경(context) 역할을 하는 가상상황을 PPT로 그렸다. 또한, 복잡한 상태 변화는 PPT로 다이어그램을 작성하고, 각 상태에 따라 달라지는 처리나 DB 필드를 함께 볼 수 있는 표를 그렸다.

* 최근의 생각을 담은 메모이기 때문에 의도가 모호함

개발자와 아키텍트 사의 불협화음의 본질


그리고 해결책



아키텍처의 중요한 특성

architecture is a kind of “shared understanding"


아키텍처 수립/구현에도 기민한 접근이 필요한 이유에 대한 Temporal Aspect


부가 설명


Structural Aspect는


두 가지 츨면은 물론 조화를 이뤄야 한다.


출처: Agile Architecture Requires Modularity, Turtles and Architecture

제2회 한국 SW 아키텍트 대회에 발표자 자격으로 참석했다. 행사에 관심 있는 분에게 공유 차원에서 후기를 남긴다. 먼저 리셉션 후기다. 마침 업무상 방문했던 분당에서 올라오는 길에 시간이 맞아 리셉션에 참석했다. 우연히 모 SI 업체에서 아키텍트 팀을 총괄하는 분이 옆에 앉았다. 인사를 청하자, 고객이 '아키텍트가 도대체 뭘 하는 사람이냐?'라고 물으면 한 마디로 뭐라 대답하느냐고 물었다. 난감한 질문이다. 대개는 프로젝트 종료 후에 인정하지, 말로는 설명이 어려웠다. 한 수 배우려고 오히려 반문했지만, 묘안은 없었다. 대화를 나누다 보니 자연스레 대회 필요성을 공감할 수 있었다. 아직, 직무로 통용하기 어려운 '아키텍트'란 역할에 대해 공감대나 저변 확대를명확한 정의, 범용성 확보 혹은 홍보 등의 활동이 필요한 듯하다.

축사 과정에서 두 가지 인상 깊은 발언이 있었다. '통신 분야에서 일하다가 SI에 왔더니 상황이 이 정도로 열악한 줄 몰랐다'라는 모 SI 업체 대표님 발언이 하나고, 다른 하나는 모 교수님의 '상식수준의 내용을 대단한 노하우인양 숨기던 관행을 벗어나자!'라는 취지의 발언이었다.

10일 세션 발표 시간은 아쉬웠다. 오후 발표는 시간이 늦어졌고, 가뜩이나 짧은 25분 발표도 5분이 줄었다. 핵심적인 메시지 위주로만 전달했는데 그래도 1분을 초과했다. 질문사항 응답 및 토론시간의 열기가 놀라웠다. 내 발표에 대해서도 질문이 있어 답변했다. 오픈소스 라이선스 관련 질문이 두 개나 있었는데, 발표자가 참석하지 않아 대신 대답했다. 이를 포함하여 몇 가지 인상적인 질문과 대답을 메모한다.

1. 아키텍처 평가 모델을 실제 프로젝트에 적용한 사례가 있는가?
없다. (좌장 추가 의견) 현실적으로 아키텍처 평가 모델에 입각한 절대적 검증은 불가능하다. 감리는 절차만 다룬다. 내용에 있어서 감리할 수 있는 조직이 국내에는 없다. 따라서, 다른 아키텍트가  경험에 따른 직관으로 조언을 제시할 수 있을 뿐이다.

2. 테스트 자동화를 위해 아키텍처 측면에서 고려해야 할 요인이 있나요?
없다. 테스트 자동화는 오히려 다양한 아키텍처를 포용할 수 있어야 한다. (다른 발표자 추가 의견) 테스트 자동화를 위해 아키텍처를 고칠 수 없다. 그러나 일관성 있는 아키텍처를 갖춘 시스템은 테스트 자동화가 쉽다. 가령, 각 레이어별로 전달인자가 분명한 경우를 떠올려보라.

3. Spring, Struts 등으로 비즈니스 로직을 구현한 경우 공개 의무는?
아파치 라이선스를 채택한 경우이므로, 사용 고지에 대한 의무는 있지만, 소스 코드 공개에 대한 의무는 없다. 자세한 사항은 오픈소스란 어떤 것인가? 내용 참조.

4. Hibernate와 iBatis 성능 비교?
단순 성능 비교는 의미 없다. 개발/운영 시 DBA가 SQL을 짜주는 경우라거나 SQL을 직접 노출하여 관리하기 위해 iBatis를 선택했다거나 장기적으로 객체 모델을 유지해가기 위해서 혹은 솔루션 코어를 만들기 위해서 Hibernate를 선택한다는 식이 바람직하다.

두 달쯤 전에 아래와 같은 가벼운 글을 썼다. 그런데 훌륭한 글을 발견해 소개하고자 한다.

코더(Coder), 프로그래머(Programmer), 소프트웨어 아키텍트(Software Architect), 그리고 구루(Guru)

이제 저는 비켜 드릴 테니 가서 보시라.

2008. 12. 18
많은 프로젝트에 아키텍트가 없어서 아키텍처 수립을 하곤 했지만, 스스로 아키텍트라고 하긴 낯이 간지럽다. 언제쯤 부끄럼없이 저는 아키텍트입니다라고... 할 수 있을까? 평소 궁금했는데 방금 InfoQ에 뜬 기사를 보니...

현장의 요구에 따라서 이런 그림 한장 그려내고, 훌륭하게 개발팀을 지휘해서 결과를 실현할 수 있다면... 말할 수 있을 것 같다. 그런데.. 가만 생각해보니, 내 꿈이 아키텍트는 아닌 것 같다. ^^

낚시성 제목이다. 하지만, 애초부터 주목을 끌기 위함은 아니고, 집에 오는 길에 막연히 떠오른 생각을 한 줄로 표현한 것 뿐이다. The Matrix (1999)탓인지도 모르지만, 아키텍트^[각주:1]라고 하면 논리적이고 냉정한 결정이 필요하다는 점에서 남성적인 역할이라고 느껴졌다.(영어도 그렇지만, 서양의 언어들은 사물에도 성을 부여한 것이 떠올랐다.) 그런데 한편으로는 아키텍트가 고유의 생산물을 만들어낸다는 점에서 여성성이 깃든 직업으로 보이기도 한다.

 
이미지 출처: http://www.answers.com/topic/matrix-reloaded-neovarchitect-600-gif-1

Role Profile for Software Architects라는 글에서 정리된 내용이다.
나름 경험 많은 이들이 고민한 흔적이기에 이런 박스 그림은 정교함을 떠나서 일단 호감이 간다.

J2EE architect's handbook 이라는 책에서 아키텍트의 딜레마로 소개한 내용이 있습니다. 표로 정리한 것을 보면 아래와 같습니다.

underdesign과 overdesign이라는 표현을 쓰고 있는데요. 이상적인 설계라고 하는 지점을 기준으로, 필요 이상으로 설계를 하면 overdesign이 되고, 설계가 부족한 상태일 때를  underdesign이라 할 수 있겠죠.

설계에 시간을 덜 투입할 경우, 단기적으로는 개발 비용이 적게 들 수 있습니다. 예를 들어, 설계를 장기간하면 개발 기간이 지연되고, 기업입장에선 곧 비용이죠. 반면, 설계를 하면 문서나 모델이 만들어지기 때문에 시스템 유지 보수에 유리하게 됩니다.

또한, 설계를 적게 하게 되면 불필요하게 설계가 복잡해지는 것을 막을 수 있습니다. 대체로 구현에서 멀어진 추상화된 작업을 하게 되면 보다 유연한 표현이 가능하고, 그러다 보면 구현하기 어려운 산출물을 요구하게 될 수도 있죠. 반면에 설계에 많은 시간을 투자하면, 유연성을 확보하기 쉬운 형태로 모델을 만드는 일이 수월해져, 새로운 요구 사항을 받아들이는데 더 수월할 수 있습니다.

마지막으로 설계를 적게 할수록 적기에 프로젝트를 마칠 수 있지만, 장기적으로 시스템의 품질은 설계에 많은 노력을 기울인 것이 유리할 수 있죠.

이 표는 둘 중에 하나를 택해야 한다는 것이 아닙니다. 말 그대로 딜레마를 이야기 한 것입니다. 하나를 완전히 포기할 수 없는 상황이죠. 결국 이들 둘 사이의 접점을 찾으라는 것입니다. 완벽한 중간이란 존재하지 않습니다. 인간의 경지를 넘어서서.. 해탈에 들어서면 가능할지 몰라두요...

결국 여러 상황을 고려해서 허용치 범위내에서 이들 사이에서 조화를 찾으라는 의미가 되겠죠.

2004/11/21  엠파스에서...

당시 답글 보기...

* Younghoe.info v1(엠파스 블로그)에 2005/09/22 (목) 12:55 에 작성했던 글입니다.