협상과 리더십은 습득하기 어려운 스킬이다. 유능한 소프트웨어 아키텍트가 되려면 오랜 기간에 걸쳐 학습 실습, 그리고 산 지식(lessons based)을 체득해야 한다.

23.1 협상과 조정

이 능력이 중요한 이유는 소프트웨어 아키텍트가 내리는 거의 모든 결정이 곳곳에서 거친 도전과 반대에 부딪히기 때문이다. 예를 들어, 아키텍트가 전체 시스템 가용성의 리스크를 줄이고자 (도메인 단위의 별도 물리적 데이터베이스 인스턴스를 사용하여) 데이터베이스 클러스터링과 페더레이션을 결정했다고 하자. 데이터베이스 가용성 측면에서 나쁘지 않은 선택이지만 비용이 많이 들기 때문에 아키텍트는 주요 비즈니스 이해관계자(시스템 비용을 지불하는 사람)들과 만나 가성비를 놓고 협상을 해야 한다.

협상은 소프트웨어 아키텍트가 지녀야 할 가장 중요한 스킬 중 하나이다. 유능한 소프트웨어 아키텍트는 사내 정치를 이해하고 강력한 협상 및 조정 능력을 발휘하며, 모든 이해관계자들이 동의하는 해법을 찾는 과정에서 맞닥뜨리는 숱한 의견 차이를 극복할 것이다.

23.1.1 비즈니스 이해관계자들과의 협상

다음은 핵심 비즈니스 이해관계자와 수석 아키텍트의 협상에 관한 실제 시나리오이다.

시나리오 1

프로젝트의 고객사 임원은 신규 거래 시스템의 99.999% 가용성을 요구한다. 하지만 수석 아키텍트는 비즈니스 도메인 및 기술에 대한 연구, 집계, 지식을 바탕으로 99.9% 가용성이면 충분하다고 말한다. 이 고객사 임원은 기술을 잘 아는 사람은 아니지만 평소 프로젝트의 비기능 측면에 자기 목소리를 내는 편입니다. 이제 아키텍트는 고객사 임원과의 협상을 통해 99.9% 가용성이 충분하다고 설득해야 한다.

이해관계자들과 협상하는 과정에서 아키텍트가 참고해두면 좋은 몇 가지 중요한 협상 기술을 소개한다.

상황을 더 잘 이해하기 위해 문법과 유행어를 사용해라.

제로 다운타임을 만들어야 합니다, 어제 필요했습니다 같은 말은 보통 별 의미가 없지만 협상을 시작하는 아키텍트 입장에서 소중한 정보가 된다. 예를 들어, 고객사 임원에게 언제 그 기능이 필요하게 됐냐고 물어보니 어제요라는 대답을 들었다면 이 이해관계자는 출시 시기를 무엇보다 중요하게 생각한다는 것을 알 수 있다. 마찬가지로, 이 시스템은 번개처럼 빨라야 한다라고 대답에는 성능이 주요 관심사임을, 제로 다운타임을 운운했다면 애플리케이션 가용성이 중요함을 시사한다.

고객사 임원은 파이브 나인스 가용성을 원한다.

협상에 돌입하기 전, 가능한 한 많은 정보를 수집해라.

파이브 나인스가 고가용성을 의미한다는 건 알겠는데, 그럼 파이브 나인스는 정확히 어느 정도의 가용성일까? 협상하기 전에 이런 정보를 미리 찾아보면 아래와 같이 정리할 수 있다.

파이브 나인스는 연중 다운타임이 5분 35초 이내 또는 비계획 다운타임이 하루 1초 이내인 가용성이다. 아주 의욕적인 수치지만 앞서 든 예에서 이렇게까지 할 필요는 없을 뿐더러 비용도 많이 든다. ㅇㅇ 나인스 식으로만 대화하려고 하기보다 몇 시간 몇 분(여기서는 몇 초)인지 환산해서 이야기하면 훨씬 소통이 원활할 것이다.

다른 모든 것이 실패하면 비용과 시간으로 설명해라.

비용과 시간은 최후의 협상 카드로 아껴두는 것이 좋다. 우리는 협상을 하기도 전에 비용이 많이 들 겁니다, 그럴 시간이 없습니다 같은 말을 하면서 협상을 잘못 이끌어가는 아키텍트를 많이 봤다. 물론, 비용과 시간(투입되는 작업량)은 모든 협상에서 핵심적인 요소지만 일단 정당화, 합리화를 시도한 다음 그래도 안 될 경우에 쓸 최후의 수단으로 남겨두어야 한다. 비용과 시간이 협상의 중요한 속성이면 어차피 협상이 타결된 이후에 고려해도 될 것이다.

분할 및 정복(divide and conquer) 규칙을 활용해서 요구사항 또는 필우 조건을 검증해라.

고대 중국의 전략가 손자는 손자병법이라는 책에서 적이 단합되어 있으면 분열시켜라라고 말했다. 분할 및 정복은 이와 동일한 전략으로 아키텍트가 협상을 할 때에도 구사할 수 있다. 시나리오 1의 고객사 임원은 신규 거래 시스템의 가용성은 파이브 나인스 (99.999%)가 되어야 한다고 주장하는데, 시스템 전체적으로 파이브 나인스 정도의 가용성이 필요할까? 실제로 파이브 나인스의 가용성이 필요한 특정 시스템 영역의 요구사항만 충족된다면 까다롭고 비용이 많이 드는 요구사항과 협상의 범위를 좁힐 수 있을 것이다.

23.1.2 다른 아키텍트들과의 협상

시나리오 2

프로젝트 수석 아키텍트는 성능과 확장성, 두 마리 토끼를 잡으려면 여러 서비스 간의 통신 기술로 비동기 메시징이 가장 적합하다고 확신한다. 하지만 다른 아키텍트들은 메시징보다는 REST가 항상 더 빠르고 확장성도 좋아서 더 낫다고 강력히 반대한다. 수석 아키텍트는 메시징이 올바른 솔루션이라는 사실을 납득시켜야 한다.

증명은 언제나 논쟁을 이긴다는 사실을 명심해라.

REST냐. 메시징이냐를 따지기 전에 주어진 환경에서 메시징이 더 나은 기술이라는 팩트를 수석 아키텍트가 증명하면 논쟁할 일도 없다. 환경에 따라 결과는 얼마든지 달라질 수 있으니 단순히 인터넷 검색 결과가 정답이라는 보장은 없다. 프로덕션과 유사한 환경에서 두 통신 기술을 비교한 결과를 다른 아키텍트들에게 공유하면 어떨까?

지나치게 논쟁을 벌이려고 하거나 협상 과정에서 개인적인 감정을 드러내지 마라.

간결 명료한 추론에 차분한 리더십을 더하면 반드시 협상에서 승리할 것이다.

이 기술은 시나리오 2처럼 적대적인 관계가 형성되었을 때 아주 강력하다. 분위기가 너무 개인적이거나 논쟁 위주로 흘러가면 일단 협상을 중단하고 추후 양측이 진정되었을 때 다시 이야기하는 것이 상책이다. 아키텍트 간 논쟁은 늘 있기 마련이지만 차분한 리더십으로 상황에 접근하면 격론이 벌어졌을 때 상대방을 한발짝 물러서게 할 수 있다.

23.1.3 개발자들과의 협상

유능한 소프트웨어 아키텍트는 아키텍트라는 직책을 내세워 개발자에게 할 일을 지시하기보다 외려 그들과 협력하여 존경심을 이끌어낸다. 그래야 개발팀에 어떤 요청을 하더라도 논쟁을 하면서 서로 얼굴을 붉힐 일이 없다.

개발자가 아기 결정을 수용해서 어떤 작업을 하도록 설득할 때에는 '고압적으로 지시'하지 말고 왜 그 일 을 해야 하는지 정당성을 제공해라.

왜 그 일을 해야 하는지 분명히 밝히면 개발자는 그 요청에 수긍할 것이다.

아키텍트 : "그렇게 호출하려면 반드시 비즈니스 레이어를 거쳐야 합니다."

개발자 : "아뇨, 데이터베이스를 직접 호출하는 게 훨씬 더 빠르다고요!"

이 대화는 몇 가지 문제점이 있다.

먼저 "해야 합니다" 같은 어법을 주의해라요. 명령조의 말투는 품위를 떨어뜨릴 뿐만 아니라 협상과 대화를 가장 나쁘게 시작하는 방법이다. 만약, 아키텍트가 이런 식으로 바꿔 말했다면 어땠을까요?

아키텍트 : "이 프로젝트는 변경 관리가 무엇보다 중요하므로 폐쇄 레이어드 아키텍처를 구축했습니다. 다시 말해, 데이터베이스 호출은 모두 비즈니스 레이어를 거쳐 이루어져야 합니다."

개발자 : "알겠습니다. 그럼 간단한 쿼리의 성능 문제는 어떤 식으로 접근해야 할까요?"

아키텍트가 그럴 법한 이유를 먼저 들려주고 자신의 정당한 요구를 개발자가 경청하도록 만들어야 한다. 그리고 이 아키텍트는 말을 하면서 개인적인 부분은 드러내지 않았습니다. ~해야 합니다, ~하지 않으면 안 됩니다 식으로 말하지 않고 자신의 요구를 단순한 사실 진술 형태 ("이것은...")로 바꾸었다. 이제 두 사람은 폐쇄 레이어드 아키텍처를 유지하면서 간단한 쿼리를 더 빨리 실행시킬 방법을 궁리할 것이다.

개발자와 협상을 하면서 그들이 동의하지 않는 설계나 아키텍처 결정을 받아들이게 만드는 또 다른 효과적인 협상 기술은 개발자 스스로 해결책을 찾도록 유도하는 것이다. 이것은 아키텍트가 전혀 손해볼 일이 없는 윈-윈 전략이다.

개발자가 아키텍트의 결정에 동의하지 않을 경우 그들 스스로 해결책을 찾도록 유도해라.

아키텍트가 개발팀의 존경을 받고 더 나은 솔루션을 얻어내는 것이야 말로 진정한 협업이다. 더 많은 개발자의 존경을 받을수록 아키텍트는 개발팀과 협상을 하기가 수월해진다.

23.2 소프트웨어 아키텍트는 리더다

소프트웨어 아키텍트는 개발팀을 이끌고 아키텍처를 구현하는 리더이다. 유능한 소프트웨어 아키텍트가 되는 50%정도는 효과적인 대인 관계 스킬, 조정 능력, 리더십에 있다고 생각한다.

23.2.1 아키텍처 4C

비즈니스 프로세스, 시스템, 아키텍처가 점점 더 복잡해지면서 일상 업무 또한 갈수록 복잡해지는 것 같다. 아키텍처와 소프트웨어 개발은 언제나 복잡성이 도사리고 있으며 앞으로도 마찬가지일 것이다. 가령, 식스 나인스(99.9999%) 가용성을 지원하는, 매일 86밀리초 이 내의 비계획 다운타임. 연간 31.5초 이내의 다운타임을 보장하는 아주 복잡한 아키텍처도 있 습니다. 이런 종류의 복잡성을 근원적 복잡성(essential complexity, 즉, "우리에겐 어려운 문제가 있다")이라고 한다.

그런데 많은 아키텍트가 솔루션, 다이어그램, 문서를 쓸데없이 복잡하게 만드는 우를 범한다. 원래 (개발자도 그렇지만) 아키텍트는 복잡한 걸 좋아하는 사람들인 것 같다. 이런 종류의 복잡성을 우발적 복잡성(accidental complexity, "우리가 문제를 어렵게 만들었다")이라고 한다. 아키텍트는 뭔가 너무 단순하게 느껴지면 자신의 가치를 증명하거나, 비즈니스 또는 아키텍처에 관한 토론과 결정이 어떤 경계를 벗어나지 않게 하려고 복잡하게 만든다.

원래 복잡하지 않은 것을 우발적으로 복잡하게 만드는 건 아키텍트로서 무능한 리더임을 입증하는 좋은 방법이다.

우방적 복잡성을 방지하는 가장 좋은 방법은 아키텍처 4C라고 불리는, 커뮤니케이션(communication), 협동(collaboration), 명료함(clarity), 간결함(conciseness)을 실천하는 것이다. 4C는 모두 함께 작용하여 팀에서 유능한 의사 소통자와 협력자를 창출한다.

아키텍처 4C를 실천한 아키텍트는 팀의 존경심을 얻고, 프로젝트 팀원들이 그냥 질문뿐만 아니라 조언, 멘토링, 코칭 리더십을 위해 찾아오는 그런 위치에 오르게 될 것이다.

23.2.2 실용적으로 행동하되 비전을 가져라

유능한 소프트웨어 아키텍트는 실용적이면서 동시에 비전을 가져야 한다. 물론, 이것은 말보다 실천이 쉽지 않아 매우 높은 수준의 성숙도와 꾸준한 연습을 필요로 한다.

비전을 가진다는 건 어떤 문제를 전략적 사고 방식으로 접근한다는 뜻입니다. 바로 아키텍트가 마땅히 해야 할 일입니다. 아키텍처는 미래를 계획하고 아키텍처의 활력(아키텍처가 얼마나 타당한가)을 오랫동안 유지하는 것입니다. 하지만 아키텍트가 너무 이론적으로만 계획/설계한 탓에 이해하기도 어렵고 구현하기는 더더욱 어려운 솔루션이 되는 경우가 비일비재하다.

아키텍트는 비전을 가져야 하지만 현실적인 솔루션을 적용해야 한다. 즉, 다음과 같은 요소와 제약조건을 모두 고려한다는 뜻이다.

• 예산제약 등의 비용 요소
• 시간 제약 등의 시간 요소
• 개발팀의 스킬 세트 및 수준
• 아키텍처 결정에 관한 트레이드오프와 의미
• 제안된 아키텍처 설계 또는 솔루션의 기술적인 한계

유능한 소프트웨어 아키텍트는 문제 해결 과정에서 끊임없이 상상력과 지혜를 발휘하면서도 실용적인 부분과의 적절한 균형점을 찾으려 노력한다. 예를 들어, 탄력성과 연관된 골치 아픈 문제 (알 수 없는 이유로 동시 유저 부하가 급증)에 직면한 아키텍트가 있다. 비전을 가진 아키텍트면 (분산된 도메인 기반의 데이터베이스 집합인) 복잡한 데이터 메시를 응용해 문제를 해결하는 세련된 방법을 떠올릴 것이다. 그러나 아키텍트는 그것이 이론적으로는 좋은 방법일지라도 실제로 적용 가능한 방법인지, 그럴 만한 당위성은 있는지도 살펴야 한다.

실용적인 아키텍트는 고도의 탄력성이 필요한 경우에도 제약조건이 무엇인지부터 살펴볼 것이다 병목 지점이 데이터베이스인가? 병목은 호출된 서비스 중 일부 또는 다른 외부 소스에서 발생할 때도 있다. 병목점을 찾아 격리하는 것이 문제를 해결하는 첫 번째 실용적인 접근 방법이다.

아키텍트로서 존중받으려면 실용적인 것과 비전을 가지는 것의 균형을 잘 맞추는 게 중요하다. 비즈니스 이해관계자는 갖가지 제약조건에 적합한 비전이 가미된 솔루션을 높이 평가하고, 개발자는 (이론에만 그치는 것이 아니라) 구현 관점에서 솔루션이 실용적이라는 사실에 더 후한 점수를 줄 것이다.

23.2.3 모범을 보여 팀을 리드하라

무능한 소프트웨어 아키텍트는 자신의 직책을 이용해 사람들이 자기 말을 듣도록 강요하지만, 유능한 소프트웨어 아키텍트는 직책을 들이대지 않고 솔선수범하여 사람들을 리드한다. 이 것이 바로 개발팀, 비즈니스 이해관계자, 그 밖의 다른 조직원들(예: 운영팀장, 개발 관리자, 제품 소유자)의 존경심을 얻는 길이다.

기본적으로 존경심을 자아내고 팀을 이끌어 가는 것은 인간 관게 기술이다.

소프트웨어 아키텍트는 팀을 잘 이끄는 유능한 리더가 되기 위해 팀에서 가장 중요한 사람이 되어야 한다. 개발자는 질문을 던지고 문제를 해결하려는 사람이다. 유능한 소프트웨어 아키텍트는 직급이나 보직에 상관없이 기회를 포착해서 팀을 이끌어 간다. 또 누군가 기술적인 문제로 난관에 빠진 모습을 보면 적극적으로 개입해서 도움을 주거나 지침을 제공한다.

리더로서 존경심을 얻고 팀을 이끄는 주동자가 되는 또 다른 기술은 정기적으로 특정한 기술 또는 테크닉에 대해 함께 논의하는 시간을 갖는 것이다.

23.3 개발팀과의 융합

유능한 소프트웨어 아키텍트로서 성공하는 핵심 포인트 중 하나는, 개발팀에 더 많은 시간을 할애하라는 것이다.

가능한 한 회의 때문에 시간을 낭비하지 말고 개발팀과 함께 작업하는 시간을 더 많이 가져라.

회의 전에 미리 아젠다를 요청해서 아키텍트가 그 회의에 정말 참석해야 하는지 여부를 판단해라.

회의 관리 외에도 아키텍트가 개발팀과 더 잘 융합하기 위해 할 수 있는 일은 개발팀과 나란히 앉는 것이다. 아키텍트가 팀에서 멀리 떨어진 칸막이에 앉아 있으면 자신은 특별한 존재라는 메시지를 보내는 셈이다. 또 칸막이를 둘러싼 물리적인 장벽은 아키텍트를 괴롭히거나 방해해서는 안 된다고 경고하는 것과 다를 바 없다. 개발팀과 함께 앉는 건 아키텍트가 팀에서 꼭 필요한 사람으로서 개발자의 문의 사항이나 이슈가 발생하면 언제든지 자신을 활용하라는 암시이다. 아키텍트는 자신이 개발팀의 일원임을 물리적으로 보임으로써 더 많은 개발자들의 존경심을 얻고 그들을 안내하고 멘토링하는 과정에서 더 큰 도움을 줄 수 있다.

물론, 아키텍트가 어쩔 수 없이 개발팀과 다른 공간에 있어야 하는 경우도 있다. 이럴 때는 계속 걸어 다니면서 개발자의 눈에 자주 띄도록 노력하는 게 좋다. 다른 층에 있거나 항상 사무실이나 큐비클에 갇혀 있으면 아키텍처를 구현하는 개발팀을 제대로 지원할 수 없다.

아침/점심 식사 후 또는 늦은 시간에 시간을 내어 개발팀과 대화하고, 문제를 같이 들여다보고, 질의 응답하고, 기본적인 코칭 및 멘토링을 해라. 개발팀은 이러한 의사 소통을 높이 평가하고 소중한 시간을 내준 여러분을 존경할 것이다.

23.4 마치며

이 장에서 제시한 협상 및 리더십 팁은 소프트웨어 아키텍트가 개발팀과 그 밖의 이해관계자들과 더 나은 협력 관계를 구축하는 데 큰 도움이 될 것이다. 유능한 소프트웨어 아키텍트가 되려면 반드시 갖추어야 할 필수기술이자, 효과적인 리더가 되는 첫 여정을 시작하기에 좋은 팁이다. 하지만 가장 좋은 팁이라면 다음 한마디일 것이다.

성공의 공식에서 가장 중요한 한 가지 성분은 다른 사람들과 잘 지내는 방법을 아는 것이다.

26대 미국 대통령, 시어도어 루즈벨트