[소프트웨어 아키텍처] 아키텍처의 효율적인 협상 원칙

소프트웨어 아키텍처에게 협상이 중요한 이유는 대부분 아키텍처가 내리는 결정들이 곳곳에서 거친 도전에 부딪히기 때문 입니다. 그래서 협상은 소프트웨어 아키텍처가 가져야 할 중요한 스킬 중 하나 입니다. 유능한 소프트웨어 아키텍처는 사내 정치를 이해하고 강력한 협상 및 조정 능력을 발휘하며, 모든 이해관계자들이 동의하는 해법을 찾는 과정에서 맞닥뜨리는 숱한 의견 차이를 극복해야 합니다. 아래는 비즈니스 이해관계자, 다른 아키텍트, 개발자간 협상을 이렇게 3가지 방점에서 어떻게 협상해야 하는지에 대한 방법을 기술 하였습니다.

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

예를 들어 프로젝트를 진행하는 임원이 99.999%의 가용성을 요구한다고 해 봅시다. 하지만 아키텍처는 비즈니스 도메인 및 기술에 대한 연구, 집계, 지식을 바탐으로 99.9%의 가용성이면 충분하다고 말합니다. 근데 임원 성향이 자신이 틀려서 수정하는것을 싫어하고 잘난척 하는 사람들을 아주 싫어 합니다.

이때 아키텍트는 자신의 분석 결과만 너무 들이대면서 분위기를 강압적으로 몰아가지 않도록 주의 해야 합니다.

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

파이브 나인스가 고가용성을 의미하는 것은 알겠는데 정확히 어느 정도에 가용성인지는 파악하지 못하였습니다. 협상하기전에 해당 정보를 미리 찾아보는것이 좋습니다.

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

비용과 시간으로 설명 하라.

비용과 시간은 최후의 협상 카드로 아껴두는 것이 좋습니다. 우리는 협상 전에 “비용이 많이들 것 입니다.’, ‘그럴 시간이 없습니다.’ 같은 말을 하면서 협상을 잘못 이끌어가는 아키텍트를 많이 보았습니다. 물론, 시간과 비용은 모든 협상에서 중요한 핵심 요소이지만 일단 요구사항에 대한 정당화, 합리화를 시도한 다음 그래도 안될 경우 비용과 시간을 최후에 협상 카드로 내밀어야 합니다.

‘분할 및 정보’ 규칙을 활용해서 요구사항 또는 필우 조건을 검증하라.

고객사 임원이 99.999%(파이브 나인스)를 원하지만 모든 시스템에 해당 원칙이 필요할까요? 파이브 나인스가 필요한 특정 시스템 영역의 요구사항만 충족된다면 협상의 범위를 좁힐수 있을 것 입니다.

다른 아키텍트들과의 협상

나와 아키텍트간의 기술적인 도입에 이견차이가 있으면 어떻게 될까? 내가 수석 아키텍트라면 나의 지위로 엄포를 놓을수도 있을 것이다. 그렇게 되면 상대방의 적대감을 조장하여 비협조적인 관계가 형성되고 이는 개발팀에게도 바람직하지 않은 영향을 미칠 수 있다. 이런 상황을 타계하는데 몇가지 기술을 소개 한다.

증명은 언제나 논쟁을 이긴다.

우리가 프로젝트를 하는 환경에서 어떤 기술이 더 나은 기술인지 두가지의 기술결과를 공유 할 수 있도록 환경을 제공해 보는 것이다.

논쟁이 심해질땐 개인적인 감정을 드러내지 마세요.

분위기가 너무 개인적이거나 논쟁 위주로 흘러가면 일단 협상을 중단하고 추후 양측이 진정되었을때 다시 이야기 하는것이 좋습니다. 아키텍트간 논쟁은 항상 있을수 있습니다. 차분한 리더십으로 상황에 접근하는것이 좋습니다.

개발자들과의 협상

유능한 아키텍처의 경우 직책을 내세워 개발자들에게 할 일을 지시하기보다 그들과 협력하여 존경심을 이끌어 냅니다. 물론 개발팀과 협력하는 일이 항상 녹록치는 않습니다. 그들은 대부분 아키텍처와 단절된 느낌을 받기 때문에 아키텍트가 내리는 결정에 자연스레 소외감을 가집니다. 이렇게 되면 상아탑 아키텍트 안티패턴이 발생 합니다. 상아탑 아키텍트는 높은 곳에서 지시만 내릴뿐 개발자의 의견이나 우려에도 아랑곳하지 않고 그들이 해야 할 일들을 통보한다는 것 입니다.

개발자가 아키텍처 결정을 수용해서 어떤 작업을 하도록 설득할 때는 ‘고압적 지시’ 하지 말고 왜 그런지 정당성을 제공하세요.

왜 그런 일을 해야 하는지 분명히 밝히면 개발자는 그 요청에 수용을 합니다. “~해야 합니다.” 같은 어법을 사용하지 말고 “개발자 분은 어떻게 생각하세요?” 이렇게 말을 한다면 개발자는 그것에 대한 개선방향을 생각하게 된다.

개발자와 협상을 하면서 그들이 동의하지 않는 설계나 아키텍처 결정을 받아들이게 만드는 또다른 효과적인 협상 기술은 개발자 스스로 해결책을 찾도록 유도하는 것 입니다.