한빛출판네트워크

올 가을 O‘Reilly의 소프트웨어 아키텍트 컨퍼런스를 앞두고 컨퍼런스의 회장인 레이첼 로멜리오티스(Rachel Roumeliotis)씨와 저는 발표자들에게 몇 가지 질문을 던졌습니다. 소프트웨어 아키텍트라는 직업은 굉장히 다양한 분야에 걸쳐 있기 때문에, 질문의 답변들은 특히 그 중 기술적이지 않은 부분에 대해 주로 이야기 하고 있습니다.

 

소프트웨어 아키텍트로써 가장 자랑스러운 순간은 언제인가요?

 

낸시 누네스(Nancy Nunes)씨는 자신의 가장 자랑스러운 순간이 자신이 처음부터 설계한 감염을 최소화 한 수술용 로봇이 FDA 승인을 받았을 때라고 이야기 했습니다.

 

“각자의 분야에서 권위 있는 동료들로부터 저와 함께 일하면서 많은 것을 배웠다는 찬사와 존경을 받을 때의 기분은 무엇에도 비할 수 없습니다.”

 

다른 답변들은 “기능적이거나, 기능적이지 않은 요구 조건들을 만족시키는 것”부터 “요구 조건이 크게 변했을 때 이를 잘 조절하는 것” 까지 좀 더 일반적인 내용이었습니다. 데이터 아키텍트인 프라모드 사달라(Pramod Sadalage)씨는 매일 디자인을 다듬어서 “개발자들이 많은 설명 없이 데이터 모델을 이해할 때” 스스로 가장 자랑스러움을 느낀다고 이야기 했습니다. 카산드라 숨(Cassandra Shum)씨는 아키텍트가 프로젝트에 가져올 수 있는 경험의 단계에 대해 다음과 같이 훌륭히 이야기 해주었습니다 : “서로 다른 조직에서 비슷한 문제가 발생하는 것을 보면 프로젝트를 더 유연하고 확장성 있는 내부 구조와 플랫폼으로 설계할 수 있게 됩니다. 이러한 부분을 빠르게 감지하는 것은 매우 만족스러운 작업입니다.”

 

마크 리차드(Mark Richard)씨는 “한 명의 영웅 보다는 팀 전체가 노력해야 좋은 결과를 낼 수 있다”는 것을 발견했을 때를 가장 자랑스러운 순간으로 손꼽았습니다.

 

“소프트웨어 아키텍트로써 가장 자랑스러웠던 순간은 12명으로 이루어진 한 팀을 제가 일했던 가장 효율적인 팀으로 만들었던 일입니다. 기술적인 문제도 있었지만, 주어진 시간과 예산 내에서 일을 끝내기 위해 힘을 합쳤습니다. 테크니컬 아키텍쳐 기술도 중요하지만 진정한 차이를 만드는 것은 소프트웨어 아키텍트의 소프트한, 사람을 대하는 능력이라는 것을 직접적으로 보여준 프로젝트였습니다.”

 

여러분이 일했던 가장 복잡한 프로젝트는 무엇인가요? 그 복잡함은 좋은 이유의 복잡함이었나요?

 

아키텍트들은 복잡한 프로젝트에 관해 토론하는 것을 항상 원합니다. 누가 더 뛰어난지 겨루고 싶은 본능도 있지만, 그 보다 아키텍트가 프로젝트에 참여함으로써 배울 수 있는 것들에 매료되어 있기 때문입니다. 복잡한 프로젝트는, 성공적이던 아니던 간에, 항상 풍부한 경험을 안겨주고 성공의 공식이나 같은 실패를 반복하지 않을 수 있게 해줍니다.

 

몇 몇 아키텍트는 영역과 기술의 복잡성의 혼재에 대하여 이야기 했습니다. 딘 왐퍼(Dean Wampler)씨는 자신의 가장 복잡한 프로젝트는 “빠른 데이터” 스트리밍 시스템에 관한 프로젝트였다고 이야기 합니다. “복잡성과 신뢰성에 대한 도전은 문제 자체에 이미 내재해 있었습니다.” 프라모드씨 또한 기술과 문제 영역의 조합에 대해 이야기 했습니다. “제가 참여했던 가장 복잡한 프로젝트는 장비 대여 시스템의 백엔드에 관한 것이었습니다. 경제, 장비, 고객 관리 기능에 대해 이해해야 하는 매우 복잡하고 재미있는 작업이었습니다.”

 

마크씨의 가장 복잡한 프로젝트는 서비스 지향 아키텍쳐(SOA)의 초창기 한 대형 보험 회사에서 거대한 규모의 기업서비스 지향 아키텍쳐의 총괄 아키텍트로 있을 때 찾아왔습니다.

 

“규모 자체만으로도 매우 복잡한 프로젝트였지만 진정 어려웠던 것은 많은 수의 팀과 그룹을 총괄하는 것이었습니다.”

 

이 프로젝트에서 마크씨가 얻은 또 다른 중요한 교훈은 아키텍쳐에서 데이터가 얼마나 중요한지에 대한 것이었습니다.

 

“이 프로젝트 전반에 걸쳐서 데이터베이스 변환에 얽힌 복잡성은 저를 즐겁게 했습니다. 모두가 우리가 디자인하는 기업의 서비스에 관해서 흥미를 느꼈지만, 데이터가 연관되기 시작하자 상황이 급변했습니다. ”내 데이터에 손대지 마“라는 말이 당시 프로젝트에서 흔하게 들렸었고, 이러한 상황은 프로젝트의 진행을 매우 어렵게 만들었습니다.”

 

많은 개발자들이 자신의 일을 “로켓을 쏘는 일은 아니잖아” 하며 폄하하는데, 그런 말을 꺼낼 수조차 없는 사람도 있습니다. 낸시씨의 가장 복잡했던 프로젝트는 하드웨어, 소프트웨어와 군수품에 관련된 것이었습니다!

 

“저는 레이시온(Raytheon)사에서 현재도 사용되고 있는 미사일 추적 시스템에 참여했었습니다. 프로젝트가 어려웠던 이유는 고성능의 시스템을 제작해야 했기 때문입니다. 많은 양의 데이터를 수시로 받아서 처리해야 했고 성공률 또한 높아야 했습니다. 정확하고 빠르게 대량의 데이터를 처리하는 고성능 병렬 계산이 필요했습니다. 좋거나 안 좋은 이유로 복잡한 게 아니었습니다. 문자 그대로 로켓을 쏘는 일이었습니다!

 

이 모든 대답들을 관통하는 주제는 복잡성은 기술과 비즈니스의 교차점에서 오는 것 같다는 것입니다. (적어도 이 대답에서는) 아무도 복잡성의 부정적인 이야기는 하지 않았습니다. 하지만 이것은 실제 세상에서 복잡한 프로젝트에는 항상 두 가지 모습 모두가 있다는 것을 의미하는 것이겠지요.

 

아키텍트가 가져야 하는 가장 중요한 소프트 스킬 무엇인가요?

 

이 질문을 하게 된 이유는 많은 아키텍트들이 종종 소프트 스킬이 이 일에서 가장 중요한 부분이라고 이야기하기 때문입니다. 당연하게도 많은 아키텍트들이 리더십을 가장 중요한 소프트 스킬으로 손꼽았습니다. 딘씨의 충고는 다음과 같습니다. “예를 들며 리드하세요. 다른 팀원들의 결정을 강요하지 말고, 왜 그들이 옳은지 설명하세요.” 프라모드씨 또한 커뮤니케이션 능력이 아키텍트의 가장 중요한 능력 중 하나라고 강조합니다. “좋은 아키텍트가 되기 위해 많은 소프트 스킬이 필요하지만, 사람을 연결하고 소통하는 능력이 가장 중요하다고 생각합니다.”

 

카산드라씨는 다음과 같이 말하며 오픈 마인드를 갖는 것이 중요하다고 합니다.

 

“저는 때때로 아키텍트가 ”자신의 방법“으로 생각하고 문제를 해결하는데 너무 고지식하다는 것을 발견합니다. 만약 아키텍트가 오픈 마인드를 가지고 자신에게 익숙한 방법이 아니라 분제 자체를 바라볼 수 있는 능력을 가진다면 더 좋은 해답을 발견할 수 있을 것이라고 생각합니다.”

 

낸시씨는 아키텍트가 얼마나 사업에 많은 영향을 주는지 보여주는 도표를 만들었습니다. 아키텍트가 영향을 끼칠 때 리더십이 다시 등장합니다.

 

“만약 아키텍트가 자원의 이용에 영향을 줄 수 있는 결정을 자유롭게 내릴 수 있는 권한이 있다면, 가장 중요한 대인관계 능력은 리더십입니다. 팀의 역량에 따라 많은 양의 조언이 필요할 수도 있습니다.”

 

반면, 만약 아키텍트가 자원의 사용을 조절할 수 없는 상황이라면 다른 소프트 스킬이 부각됩니다.

 

“만약 아키텍트가 자원의 재할당을 자유롭게 조절할 수 있는 권한이 없다면, 가장 중요한 소프트 스킬은 판매가 됩니다. 아키텍트가 아무리 훌륭한 계획이 있다고 하더라도 정치, 경제적인 부분이 뒷받침 되지 않는다면 영향을 끼치기 힘듭니다.”

 

낸시는 다음과 같은 중요한 부분을 지적합니다. 만약 아키텍트가 프로젝트의 중요한 부분(예산과 같은)을 조절할 수 없다면 진짜 영향을 줄 수 있는 부분은 감소합니다. 운영과 개발을 통합하는 일이 만연해지면서 아키텍트는 반드시 리더십을 발휘하여 그 영향만 잃는 것이 아니라 권한까지 잃을 수 있는 상황을 피해야합니다.

 

소프트웨어 아키텍트로써 성공하는데 가장 중요한 세 가지 비 기술적인 능력과 그 이유를 설명해 주세요.

 

위의 주제에 이어서, 프라모드씨는 영향령력을 자신의 가장 중요한 비 기술적인 능력 중 하나라고 이야기 합니다. “아키텍트는 비즈니스와 IT의 차이를 잇는 다리 역할을 해야 하기 때문에 많은 독립된 구성원들과 일 해야합니다. 영향력이 충분하지 않다면 여러분의 비전을 다른 사람들에게 이해시키기 힘듭니다.” 프라모드씨는 또 다른 능력으로 결정 능력을 손꼽았습니다. “좋은 결정 능력이 없다면 아키텍쳐는 매우 혼란스러워 질 것입니다.” 마크씨는 협상 능력의 중요성을 이야기 하며 다음과 같이 말합니다.

 

“소프트웨어 아키텍트로써 여러분이 내리는 결정은 많은 장애물을 만날 것입니다. 여러분의 결정은 돈이 들고, 다양한 영향을 가져올 것이며 심지어 논쟁을 일으킬 수도 있습니다. 따라서 협상을 하는 방법을 아는 것은 여러분의 결정이 받아들여지기 위해 필수적인 요소입니다.”

 

대부분의 아키텍트는 다양한 종류의 커뮤니케티션 능력을 핵심적인 소프트 스킬으로 손꼽습니다. 이러한 능력은 쓰기, 말하기 및 비전을 화이트보드 같은 미디어로 시각적으로 보여주는 부분을 포함하며 “아키텍쳐가 충분히 받아들여지고 계획했던 대로 적용되고 디자인되는데” 도움을 줍니다.

 

낸시씨는 관찰을 중요한 대인관계 능력인 이유를 다음과 같이 잘 설명합니다.

 

“보고, 듣고, 읽는 작업을 통한 관찰은 아키텍트가 실제 정보를 학습하고 제대로 통찰력을 발휘하기 위해 매우 중요한 기술입니다. 진실은 소통의 실패나 오해로 인해 왜곡될 수 있습니다. 문서나 코드에 존재하는 필수 요구사항이 제품에서 누락될 수도 있습니다. 서로 다른 이해관계가 얽히면 요구사항의 중요도가 사람마다 다를 수 있는 법이지요. 아키텍트는 반드시 객관적으로 관찰하며 사실과 사실이 아닌 것을 구별하며 정확하고 유효한 해답을 도출해야 합니다.”

 

마크 리차드(Mark Richards)씨는 발표에서 위와 같은 비 기술적인 부분의 중요성을 언급했습니다. 비즈니스에서 실제로 중요한 속성들, 예를 들면 보안, 확장성, 발전 가능성 같은 소프트웨어적인 부분들은 잘 정리되어 오지 않습니다. 그보다 비즈니스 사람들과의 미팅이나 사업의 목표를 이야기 하는 중간에서 튀어나오고, 이는 소프트웨어 아키텍쳐에 영향을 줍니다. 좋은 관찰 능력을 가진 아키텍트는 이러한 부분들이 문제가 되기 전에 사전에 해결할 수 있습니다.

 

카산드라씨의 세 가지 기술은 모두 사람을 포함합니다.

 

“공감능력, 임명, 조직. 이 세 가지 요소들은 모두 사람과 밀접한 관련이 있습니다. 왜냐하면 결국 프로젝트의 성패를 가르는 것은 사람이기 때문입니다. 보다 많은 경우 기술보다는 사람이 문제가 됩니다.”

 

여러분이 좋아하지 않을 수도 있지만, 프라모드씨의 마지막 요소는 바로 계속 학습하는 것입니다. 프라모드씨는 다음과 같이 말합니다. “아키텍트는 새로운 것들을 계속 학습하고, 과거나 다른 사람으로부터도 배워야 합니다. 그리고 다른 사람들에게 잘 알려줄 수 있어야 합니다.” 좋은 선생은 좋은 리더이기도 하다는 말은 학습하는 리더십의 중요성을 알려줍니다. 딘씨가 말하는 것처럼 명령이 아니라 올바른 것을 설명하며 영향을 주어야 합니다.

 

“만약 다시 시작할 수 있다면..” 싶은 프로젝트는 무엇입니까?

 

당연하게도 지금 할 슬픈 이야기들은 기회를 놓쳤거나 어려운 사업 환경 때문에 일어난 일들입니다. 낸시씨의 이야기는 많은 독자들을 공감하게 만들 것입니다.

  

“제가 일을 시작한지 얼마 되지 않았을 때, 저는 가스 및 화학 응용 프로그램을 위한 차세대 중복 제어 시스템을 만드는 팀에서 일하고 있었습니다. 당시 존재하던 제어 시스템 제품은 회사 수익의 중요한 일부를 차지하고 있었고 제품의 하드웨어는 수명이 다해가고 있었습니다. 당시 회사는 합병을 통한 변화의 시기를 겪고 있었고 새로운 경영진도 변화의 일부였습니다. 경영진은 새로운 팀에서 새로운 객체 지향 방법과 새로운 툴들로 진행하기를 결정했습니다. 이러한 결정으로 인해 현장에서 동작하던 기존 시스템의 유지보수로 오랫동안 일 해오던 일부 팀원들이 팀을 떠나게 되었고, 이는 썩 만족스러운 결정은 아니었습니다. 하드웨어 팀이 새로운 제품들을 디자인했기 때문에, 새로운 소프트웨어 팀도 생산 라인의 확장을 위해 기존의 소프트웨어 아키텍쳐와 디자인을 개선해야 했습니다. 또 한 가지 관문은 당시에 굉장히 큰 이익을 안겨줄 잠재적인 고객이 있었는데, 고객의 요구사항은 중복 율을 세 배로 높이고 자체적인 스크립트 언어도 지원하는 것이었습니다.”

 

“프로젝트가 진행되어 소프트웨어 / 하드웨어를 통합할 때가 됐을 때 항상 생기는 문제가 발생했습니다. 기존 팀의 몇 몇 사람들이 새로운 소프트웨어는 망했고, 기존 소프트웨어를 그대로 사용해야만 한다는 소문을 퍼뜨린 것입니다. 이로 인해 새로운 고객과의 계약도 날아가 버렸습니다. 경영진은 중복 율을 세 배로 올리는 기능을 없애 버렸고, 새로운 소프트웨어 아키텍쳐는 폐기되고 기존의 디자인으로 돌아가 버렸습니다. 리스크를 피하기 위해 기존의 소프트웨어 코드를 기반으로 새로운 하드웨어에 그대로 사용한 것입니다.”

 

“팀원들 모두 매우 열심히 일 했고 목표에 거의 근접해 있던 상태에서 모든 노력이 수포가 돼버림으로 인해 팀원들은 모두 실의에 빠졌습니다. 많은 가능성을 지니고 있엇던 새롭게 디자인 된 시스템이 리스크에 대한 공포로 인해 폐기된 것입니다.”

 

“이 프로젝트로 인해 제가 소프트웨어 아키텍쳐에 입문하게 되었고 소프트웨어 시스템 아키텍쳐로써의 경력에 큰 밑거름이 되어 주었습니다. 이 경험에서 저는 소프트 스킬이 프로젝트의 성공을 위해서 테크니컬 스킬 보다 중요하다는 점을 배울 수 있었습니다.”

 

 숙련된 아키텍쳐는 그렇게 되기까지 항상 교훈을 남기는 성공과 실패를 모두 견뎌야 했을 것입니다. 때때로 기술적으로는 실패 하더라도 소프트 스킬에서는 훌륭한 교훈을 얻으며 실제 프로젝트가 얼마나 지저분하고, 사람들은 또 얼마나 제멋대로인지 배울 수 있었을 것입니다.

 

마크(Mark)씨는 “다시 하고 싶은” 프로젝트를 통해 성공과 재앙을 동시에 맛보았습니다.

 

“기술적으로 이 프로젝트는 매우 성공적이었습니다 ... 하지만 소프트웨어 아키텍트로써 저는 엄청난 실패를 저질렀습니다. 당시에 저는 이 프로젝트를 이끌고 새로운 시스템을 위한 기술적인 노하우는 가지고 있었지만, 문자 그대로 사람을 다루는 능력이 전혀 없었습니다. 결과적으로 저는 팀의 거의 모든 사람들과 소원한 관계가 되었습니다. 팀원 중 몇 명은 회사를 떠났고 다른 사람들은 다시는 저와 일 하지 않겠다고 회사에 요구했습니다. 이 프로젝트를 통해 저는 많은 교훈을 얻었고 만약 기회가 된다면 다시 하고 싶은 프로젝트로 손꼽습니다. 팀원들은 모두 좋은 사람들이었지만 제가 팀을 망쳐놓았습니다. 이 프로젝트로 인해 소프트 아키텍쳐에게 소프트 스킬이 테크니컬 스킬보다 더 중요하다는 사실을 배웠습니다.

 

마크씨의 인생 교훈에 이어 프라모드씨는 자신의 모든 프로젝트를 다시 하고 싶다고 말합니다!

 

“[제가 다시 하고 싶은 프로젝트]는 매우 많습니다. 특히 지금처럼 스트림 프로세싱, NoSQL 데이터베이스, CQRS, 이벤트 소싱 아키텍쳐 스타일 같은 새로운 기술이 발전했으니 말입니다. 저는 이러한 새로운 기술들을 사용해서 저의 프로젝트를 진행했으면 어땠을까 생각해보곤 합니다. 새로운 기술을 적용해서 이전의 프로젝트를 진행하는 상상은 항상 즐거운 일입니다.”

 

학습은 저희 O’Reilly 소프트웨어 아키텍쳐 컨퍼런스의 모든 것입니다. 저희는 아키텍쳐의 기술적인 부분들을 다루지만, 숙련된 아키텍트들이 중요한 소프트 스킬에 대해 이야기하기도 합니다. 저희는 소프트웨어 아키텍쳐의 모든 부분을 건드릴 수 있는 프로그램을 제작하였습니다. 어서 합류하세요!

 

 

***** 

닐 포드(Neal Ford)는 글로벌 IT 컨설턴트인 ThoughtWorkds의 디렉터이, 소프트웨어 아키텍트이자 Meme Wrangler로 end-to-end 소프트웨어 개발과 전달에 많은 관심이 있다. ThoughWorks에 입사하기 전, 닐은 세계적으로 유명한 교육과 개발 회사인 DSW Group, Ltd.의 CTO로 일했다. 닐은 Georgia 주립 대학에서 Computer Science의 언어와 컴파일러를 전공하였으며, 부전공으로 통계 분석을 전공하였다. 닐은 또한 디자이너이자 어플리케이션 개발자이다.

 

*****

원문 : 5 questions that will make you a better software architect

번역 : 송원석(NEXT Institute 학생 / atgchan AT gmail.com)