티스토리 뷰

원본 : 4 essential skills software architects need to have but often don’t
작성자 : Brian Foster

(본 글은 한빛미디어의 IT 기사 번역 세션에서 소프트웨어 아키텍트에게 필요하지만 종종 가지고 있지 않은 4가지.
라는 글로 게시되었습니다.)


소프트웨어 아키텍트에게 필요하지만 종종 가지고 있지 않은 4가지.

- 소프트웨어 구조 내면에 대한 고찰

 

마이크로서비스. 지속적 출시. 리액티브 시스템. 클라우드 지향적 구조... 많은 소프트웨어 아키텍트(혹은 이를 지향하는 사람들)은 적어도 그들 사업 영역에서 형성되어 있는 최신 경향과 개발 기술에 대해 익숙함을 느낍니다. 그런 주제에 대해서 배울 수 있는 수많은 자원들이 있습니다. 책이나 온라인 비디오부터 컨퍼런스에 나오는 프레젠테이션까지 모든 것들에서부터 말이지요. 중급자에서 전문가로 되는 방법은 그들 손끝에 달려있습니다. 하지만 오늘의 경향이 개발에 관한 미래의 표준이 될 수 있는 것과 같이, 소프트웨어 아키텍트에게는 그들이 가진 "언급되지 않은" 기술들을 실전에 반영함으로써 그들이 속한 조직을 변화시키는 것이 중요합니다. 그게 바로 대화와 인적 기술이라는 것입니다.

 

 매 새해가 올 때마다 우리는 모두 새해에 시작할 것에 대해서 언급합니다. 소프트웨어 아키텍트에게는 이런 언급들이 보통 어떤 아키텍쳐의 속도를 향상시키겠다던가, 혹은 최신 기술 스택을 완벽히 이해하겠다는 식으로 표현합니다. 물론 어떤 큰 아키텍쳐 팀을 이끌거나 그들이 포용하는 기술을 선택하는 매니저로써의 아키텍트가 가지는 약한 기술 개발도 있을 수 있는데, 이는 보통 최신 경향의 기굴을 배우는 선호에 밀려서 경시되기도 합니다.

 

 2017년이 온 것을 환영하면서, O’Reilly 작가이자 전문 아키텍트인 Mark Richards 에 의해서 정의된 조금 더 나은 리더, 협상가, 결정권자, 그리고 팀 형성자가 되기 위한 필수적인 기술의 핵심에 대해서 간단히 다뤄봅시다. 각 섹션에는 Mark Software Architecture Fundamentals People Skills Software Architecture Fundamentals Soft Skills 비디오 강좌에서 소개되고 있는 비디오와 인용구문을 포함하고 있습니다.

 

리더쉽

효율적인 리더란 정말 무엇일까요? 기술적인 영역뿐만 아니라 사업 영역에서 대인 관계에 있어서도 팀이 앞으로 전진할 수 있도록 방해물을 제거하는 것을 돕는 것이 필요합니다. 아키텍트가 리더로 된다는 것은 도움과 보조를 제공하는 것을 의미하기도 하고, 팀이 어떤 의사를 결정하고 그 결정을 검증할 수 있도록 도와주는 것을 의미하며, 팀에게 동기를 부여하고 기술적이든 비기술적이든 어떤 지원을 제공하는 것을 의미하기도 합니다. 이런 것들이 보통 우리가 아키텍트로써 리더에게 필요한 것들이라고 할 수 있습니다.

 - Mark Richards, Software Architecture Fundamentals People Skills

 Leadership Skills video segment 을 보면서 효율적인 리더가 되기 위한 방안을 모색해봅시다.

 

협상

협상은 어렵습니다. 하지만 성공적인 아키텍트가 되기위해서 필수적인 기술이기도 합니다. 불행하게도 협상은 수많은 시도와 오차를 수행하고 그걸 바르게 잡는 것을 경험하는데 수년의 시간이 걸립니다. 다음 두 영역이 아키텍트가 협상기술을 필요로 하는 분야입니다. 물론 협상 기술이 수많은 분야에서 확장될 수도 있지만 적어도 이 두가지 영역에서는 필요로 합니다.: 비품질적 요소들 사이에서 구조내의 장단점을 협상하는 것과 개발자 매입과 같은 것인데 이건 정말 힘들기도 하고 중요한 것입니다.

- Mark Richards, Software Architecture Fundamentals People Skills

 Negotiation Skills video segment 을 통해서 합의를 도출하고 장단점을 이해하는 방법에 대해 알아봅시다.

 

의사 결정

아키텍트는 구조를 정의하고 기술적 결정을 지도하는데 사용되는 원칙들을 설계할 책임이 있습니다. 오늘날에 이르러서 아키텍트가 기술적 결정을 내리는 경우들이 많아졌습니다. 하지만 기대와 책임이라는 관점에서 우리가 눈여겨봐야 할 것은 그런 기술적 결정을 하는데 "지도"한다는 것입니다. 이건 어쩌면 직접 결정을 하는 것보다도 더 어려운 일입니다. 여기서 찾을 수 있는 팁이라면 결정이 시스템상에 미칠 영향과 결정된 내용을 적용하는 데 있어서의 어려움의 정도에 대해서 집중하자는 것입니다.

- Mark Richards, Software Architecture Fundamentals Soft Skills

 Architecture Decisions video segment를 통해서 어떤 것이 구조 결정이고 아닌 것인지 알아봅시다.

 

아키텍쳐 팀과 함께 일하는 것

제가 아키텍쳐 팀과 일하면서 접근했던 방식은 우선 중재자를 선정하는 것이었고, 중재자가 어떤 기술을 쓰던 간에 이런 접근은 당신이 처한 상황에 적합할 수 있습니다. 중재자의 역할은 팀 내에서 발생하는 차이를 해결하고, 통합된 아키텍쳐 관점으로 팀을 인도해 나가는 것입니다. 두번째 방식은 아키텍처 팀 구성에 대한 모든 결정은 합리적인 정당성을 동반해야 한다는 것입니다. 세번째는 팀 구성원간에 어떤 충돌이 발생했을 때, 구성원들은 중재자가 결정한 어떤 내용이든 동의하고 받아들여야 한다는 것입니다. 마지막으로 팀 내 구성원들이 통합적 아키텍쳐 관점에서 일의 목표와 중요성에 대해서 지속적으로 이해하게 하는 것입니다.

 - Mark Richards, Software Architecture Fundamentals People Skills

 Working with Architecture Teams video segment 를 통해서 아키텍쳐 팀과 일하는데 있어 필요한 기술과 예시에 대해 숙지해봅시다.

 

이번 기사에서 다뤄졌던 대화와 인적 기술에 대해서 조금 더 관심을 가지고 있다면, 한번 4 2-5일에 뉴욕에서 열리는 Software Architecture Conference에 참여해보시기 바랍니다. 이 행사는 2017년에 당신이 조금 더 나은 리더나 협상가, 의사결정권자, 그리고 팀 형성자가 되기 위해 추구할 수 있는 또 하나의 방법이 될 수 있습니다.

댓글