[소프트웨어 아키텍처] 아키텍트의 리더십 스킬 3가지

첫번째, 쓸때 없이 복잡하게 만들지 마라.

많은 아키텍처가 솔루션, 다이어그램, 문서를 쓸데없이 복잡하게 만드는 우를 범합니다. 원래(개발자도 동일하지만) 아키텍트는 복잡한 걸 좋아하는 사람들인 것 같습니다.

개발자는 나방이 불빛에 끌리듯 복잡한 것에 이끌립니다. 결과는 대부분 똑같습니다.

아키텍트는 뭔가 너무 단순하게 느껴지면 자신의 가치를 증명하거나, 비즈니스 또는 아키텍처에 관한 토론과 결정이 어떤 경계를 벗어나지 않게 하려고 복잡하게 만듭니다. 직업 보안상 그렇게 하는 사람들도 있습니다. 원래 복잡하지 않은것을 우발적으로 복잡하게 만드는 건 아키텍트로서 무능한 리더임을 입증하는 좋은 방법 입니다.

그런 복잡성을 예방하기 위해서는 우리는 커뮤니케이션, 협동, 명료함, 간결함을 실천하는 것 입니다. 소프트웨어 아키텍처는 의사소통을 명료하고 효율적으로 해야 합니다. 그러면서 고객사, 다른 아키텍트, 개발자와 해결방법을 찾고 완성해야 합니다.

두번째, 실용적으로 행동하되 비전을 가진다.

유능한 소프트웨어 아키텍트는 실용적이면서도 동시에 비전을 가져야 합니다. 비전을 가진다는것을 아래 뜻 힙니다.

상상력이나 지혜를 발휘하여 미래를 떠올리거나 계획한다.

비전을 가진다는 것은 어떤 문제를 전략적인 사고 방식으로 접근한다는 뜻 입니다. 아키텍처는 미래를 계획하고 아키텍처가 얼마나 타당한가를 오랫동안 유지하는 일 입니다. 그러나 이런 비전 때문에 너무 이해하기 어렵고 구현하기도 어려운 솔루션을 만들수도 있습니다. 그렇다면 ‘실용적이다’라는 정의는 무엇일까요?

이론적으로만 생각하지 말고 실제에 근거한 방식으로 분별 있게 현실적으로 접근 한다.

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

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

유능한 아키텍처는 문제 해결 과정에서 끊임없이 상상력과 지혜를 발휘하면서도 실용적인 부분과의 적절한 균형점을 찾으려고 노력 합니다. 예를들어 탄력성과 관련된 문제가 있다면 어떤 아키텍처는 복잡한 메시 아키텍처를 활용해 문제를 해결하려고 하겠지만 유능한 아키텍처의 경우 해당 문제의 병목점이 데이터 베이스에 있다는 것을 찾고 데이터의 일부를 캐시해서 사용하도록 시스템을 고칠것 입니다.

아키텍트로서 존중받으려면 실용적인것과 비전을 가지는 것의 균형을 잘 맞추는게 중요합니다.

세번째, 모범을 보여 팀을 리드하라.

무능한 아키텍트는 자신의 직책을 이용해 사람들이 자기 말을 듣도록 강요하지만 유능한 아키텍트는 직책을 들이대지 않고 솔선수범하여 사람들을 리드하여 존경심을 얻는 길 입니다.

인간 관계가 중요하다.

대부분의 사람은 문제를 해결하는데 기술적인 지식이 중요하다고 생각하지만 그것은 일부에 불과 합니다. 가장 중요한 것은 존경심을 자아내고 팀을 이끌어 가는 인간관계 기술이라는 것 입니다. 이전 글 협상원칙에서도 언급 했지만 ‘~하세요’라는 말투보단 ‘~어떻게 하면 좋을까요?’라는 식의 질문을 던짐으로써 개발자나 클라이언트에게 제어권을 주고 아키텍트와 함께 솔루션을 만들어가는것이 중요 합니다.

이름을 불러라.

그리고 사람의 이름을 부르세요. 사람들은 대화 중에 자신의 이름을 듣는 것을 좋아하고 자기 이름을 불러준 사람에게 더 친밀감을 느낍니다. 사람의 이름을 기억하는 연습을 하고 자주 그들의 이름을 불러주세요.

악수를 하라.

처음이나 가끔 사람들을 보면 악수를 하고 눈을 맞추세요. 악수는 중세시대때부터 시작된 중요한 대인 관계 기술 입니다. 악수를 할때 상대방의 손을 흔들고 시선을 맞추고 확실하게 하세요. 먼곳을 처다보면 대부분 무례한 행동이라고 생각 합니다. 2~3초간만 악수를 하고 너무 길게 하지는 마세요. 그리고 가끔해야지 너무 자주하면 불편한 분위기가 될 수 있습니다.

정기적인 백 미팅을 하라.

특정한 기술이나 테크닉에 대해 함께 논의하는 시간을 갖는 것 이다. 이키텍트는 이런 자리를 통해 각자의 기술역량을 보여주고 발표 스킬과 멘토링 연습을 할 수 있습니다. 예를 들어 설계 패턴 검토나 프로그래밍 언어의 최근 릴리스를 주제로 세션을 갖는 것 입니다. 소중한 정보를 습득한 개발자는 이제 여러분의 팀 리더 겸 멘토로서 우러러 보기 시작할 것 입니다.

관련 글 보기