소프트웨어 아키텍트는 기술 아키텍처를 정립하고 아키텍처 결정을 내릴 뿐만 아니라 개발팀이 아키텍처를 올바르게 구현하도록 안내할 책임이 있다. 이 일을 잘하는 아키텍트는 개발팀과 긴밀하게 협력하여 문제를 해결하고 성공적인 해법을 찾아낸다. 팀을 생산적으로 만드는 능력은, 유능하고 성공적인 소프트웨어 아키텍트가 다른 아키텍트들과 차별화되는 강점이다.

22.1 팀 경계

우리는 경험상 소프트웨어 아키텍트가 개발팀의 성패를 좌우할 만큼 지대한 영향력을 갖고 있다고 생각한다. 스스로 정상 궤도에서 벗어났거나 소프트웨어 아키텍트(그리고 아키텍처)로부터 멀어졌다고 느끼는 개발팀은 대부분 시스템의 다양한 제약조건을 제대로 알지 못하고 경험도 없기 때문에 아키텍처를 올바르게 구현하지 못한다.

소프트웨어 아키텍트는 개발자가 아키텍처를 구현할 수 있게 제약조건이나 어떤 틀을 만들어 개발팀과 소통하는 일을 한다. 아키텍트는 너무 빡빡하거나, 너무 느슨하거나, 얼추 딱 맞는 경계를 생성할 수 있는데, 경계가 너무 빡빡하거나 느슨하면 아키텍처를 구현하는 팀의 능력에 직접적인 영향을 미친다.

아키텍트가 제약조건을 너무 많이 설정하여 개발자가 숨도 쉴 수 없게 빡빡한 틀을 전달하면 개발자는 시스템을 효과적으로 구현하는 데 필요한 많은 도구, 라이브러리, 프랙티스를 사용하지 못하게 된다.

이와 반대로, 제약을 너무 느슨하게 적용해서 (아니면 일체의 제약 없이) 중요한 아키텍처 결정을 모두 개발팀에 위임하는 아키텍트도 있다. 이것 역시 앞서 제약조건이 빡빡한 상황만큼 좋지 않다. 개발팀은 사실상 본인들이 소프트웨어 아키텍트의 역할을 떠맡아 직접 개념 증명(proof of concept, POC)을 하고, 적절한 지침없이 설계 결정을 놓고 서로 싸우며 혼란과 불만을 느낀 채 비생산적으로 일하게 된다.

유능한 소프트웨어 아키텍트는 팀이 올바른 도구와 라이브러리로 무장하여 아키텍처를 잘 구현할 수 있도록 적절한 지침과 제약조건을 제공한다.

22.2 아키텍트 성향

아키텍트의 성향은 내 맘대로 아키텍트, 유체이탈 아키텍트, 유능한 아키텍트, 대략 이렇게 세 가지 타입이 있다. 내 맘대로 아키텍트는 빡빡한 경계, 유체이탈 아키텍트는 느슨한 경계, 그리고 유능한 아키텍트는 적합한 경계에 해당한다.

22.2.1 내 맘대로 아키텍트

내 맘대로 아키텍트(control freak architect)는 소프트웨어 개발 프로세스의 세세한 부분을 일일이 통제 하려고 한다. 이런 아키텍트가 내리는 결정은 하나같이 세부적으로 저수준에 관한 내용이라서 개발팀에 과도한 제약을 초래한다.

개발팀이 알아서 쓸 법한 오픈 소스나 서드파티 라이브러리를 마음대로 내려 받아 사용하지 못하게 하면서 개발팀이 언어API를 이용해 모든 것을 처음부터 개발하라고 우긴다. 또 명명 규칙, 클래스 설계, 메서드 길이 등을 엄격하게 제한하고 개발팀에게 의사코드(pseudocode)까지 짜주는 친절한(?) 간섭도 잊지 않는다.

아키텍트의 역할은 애플리케이션(컴포넌트)의 구성 요소를 만들고 컴포넌트 간의 상호 작용을 결정하는 일이다. 개발자의 역할은 이런 컴포넌트를 가져와 클래스 다이어그램 및 설계 패턴을 사용해 최선의 구현 방안을 결정하는 것이다.

아키텍트는 프로젝트의 복잡성과 팀 기술 수준에 따라 내 맘대로 아키텍트라는 악역을 맡아야 할 때도 있다. 그러나 대개 내 맘대로 아키텍트는 개발팀을 혼란에 빠뜨리고, 적절하게 지도하지 못한 채 외려 방해가 될 때도 많고, 팀을 이끌어 아키텍처 구현을 리드하는 데 적합하지 않은 편이다.

22.2.2 유체이탈 아키텍트

유체이탈 아키텍트(armchair architect)는 꽤 오랫동안 (어쩌면 단 한 번도 제대로) 코딩을 한 적이 없는, 아키텍처를 수립할 때 세부 구현 사항은 거의 나몰라라 하는 아키텍트입니다. 이런 아키텍트는 아키텍처 초안이 완성되면 개발팀과 연락이 끊기고 다른 프로젝트로 홀연히 사라지곤 한다.

내 맘대로 아키텍트처럼 유체이탈 아키텍트가 되기도 참 쉽습니다. 유체이탈 아키텍트의 가장 분명한 징후는 아키텍처를 구현하는 개발팀과 충분한 시간을 갖지 않거나 아예 만나서 얘기조차 안 하려고 하는 자세이다. 개발팀은 아키텍트의 기술 지원 가이드가 필요하고 기술/비 즈니스에 관한 문의사항에 답변할 수 있는 아키텍트를 원한다. 다음은 유체이탈 아키텍트의 다른 징후들입니다.

• 비즈니스 영역 비즈니스 문제 기술을 온전히 이해하지 못한다.
• 소프트웨어 개발 실무 경력이 부족하다.
• 아키텍처 솔루션 구현에 함축된 의미를 전혀 신경쓰지 않는다.

처음부터 그럴 의도는 아니었지만 한꺼번에 너무 많은 프로젝트를 맡아 다수의 개발팀을 상대하거나, 기술 또는 비즈니스 도메인의 맥락을 놓치게 되어 유체이탈 아키텍트가 되는 경우도 있다. 어쨌든 이런 아키텍트가 되지 않으려면 프로젝트에서 쓰이는 기술에 더 많이 관여하고 비즈니스 문제/영역을 잘 이해하려고 노력해야 한다.

22.2.3 유능한 아키텍트

유능한 소프트웨어 아키텍트(effective software architect) 개발팀에 적절한 제약조건과 경계를 설정하고 팀원들이 서로 잘 협력할 수 있도록 독려하며 그들을 올바른 수준으로 가이드한다. 또 팀이 용도에 맞는 도구와 기술을 보유하고 있는지 확인하고 개발자들이 목표를 달성하는 데 걸림돌이 될 만한 요소를 제거한다.

너무 뻔하고 쉽게 들리지만 결코 그렇지 않다. 개발팀을 잘 이끄는 유능한 리더가 되는 것은 일종의 예술입니다. 유능한 소프트웨어 아키텍트는 개발팀과 긴밀하게 협력하면서 그들의 존경심을 이끌어 낸다.

22.3 얼마나 제어해야 하나?

유능한 소프트웨어 아키텍트가 되려면 얼마나 내 맘대로 아키텍트가 되어야 하고, 얼마나 유체 이탈 아키텍트가 되어야 할까? 이 문제는 지금부터 나열할 다섯 가지 팩터와 밀접한 관련이 있으며, 소프트웨어 아키텍트가 한 번에 관리 가능한 팀(또는 프로젝트)의 수도 이 5개 팩터가 결정한다.

팀원 간 친밀도

팀원들이 서로 얼마나 잘 알고 있나? 전에도 프로젝트를 함께 한 사람들인가? 일반적으로 팀원들이 서로 잘 아는 사이라면 이미 스스로 조직화하기 시작되므로 제어가 덜 필 하고, 그 반대일수록 팀원 간 협업을 촉진하고 팀 내 파벌을 없애기 위해 더 많은 제어가 필요하다.

팀 규모

팀 규모가 어느 정도인가(우리는 같은 팀에 개발자가 12명 이상 있으면 큰 팀으로, 4명 이 하면 작은 팀으로 본다)? 팀이 커질수록 더 많은 제어가 필요하고, 팀이 작을수록 제어가 덜 필요하다.

전체적인 경험

팀원 중 시니어 급은 몇 명이나 있나? 주니어급 팀원은 몇 명인가? 팀에 주니어/시니어 개 발자가 섞여 있나? 팀원들은 기술과 비즈니스 영역을 얼마나 잘 알고 있나? 주니어 개발자가 많은 팀은 제어와 멘토링이 더 필요하고, 시니어 개발자가 더 많은 팀은 아무래도 제어가 덜 필요하다. 후자의 경우 아키텍트는 멘토가 아닌, 사실상 조정자(Facilitator)의 역할을 합니다.

프로젝트 복잡도

프로젝트가 아주 복잡한가? 아니면 단순한 웹 사이트 정도인가? 복잡도가 높은 프로젝트를 수행하려면 아키텍트가 팀에 더 많이 관여하여 갖가지 이슈를 처리해야 할 테니 팀에 더 많은 제어를 가할 수밖에 없다. 비교적 단순한 프로젝트는 그 자체로 간단하니 별로 제어할 필요가 없다.

프로젝트 기간

짧은 프로젝트 (2개월)인가? 아니면 보통 수준 (6개월) 내지 긴 프로젝트(2년)인가? 프로젝트 기간이 길수록 더 많은 제어가 필요하고 프로젝트 기간이 짧을수록 제어는 덜 필요하다.

보통 프로젝트를 처음 시작할 때 이 팩터들을 토대로 제어 수준을 결정한다. 그러나 시스템이 진화할수록 제어 수준도 달라지기 마련이므로 프로젝트 내내 이 팩터들을 지속적으로 분석하여 개발팀을 어느 정도까지 제어할지 결정하는 게 좋다.

예를 들어, 각 팩터마다 20점 단위로 값을 매긴다고 하자. 음(-)의 값이면 유체이탈 아키텍트(제어와 관여를 덜 함)를, 양(+)의 값이면 내 맘대로 아키텍트(제어와 관여를 더 많이 함)를 의미한다.

물론, 이런 척도가 정확한건 아니지만 팀에 가할 제어의 상대량을 측정하는 용도로는 요긴하다.

위의 시나리오 같은 경우, 유능한 소프트웨어 아키텍트는 처음에는 조정자 역할을 하며 팀원들과 그들의 업무에 깊이 개입하지 않는다. 아키텍트는 대부분의 시간 동안 팀원들 질문에 답변하고 팀이 정상 궤도에 있는지 체크하면서, 숙련된 팀원 각자가 본인이 제일 잘 아는 일을 수행하도록 (그래서 소프트웨어가 빨리 개발되도록) 맡긴다.

자, 이번에는 전혀 다른 시나리오이다. 프로젝트 규모가 크고(12 명) 팀원들은 서로 잘 아는 사이지만 주니어(무경험자) 개발자가 대부분이다. 프로젝트 기간은 6개월로 약간 복잡한 편이다. 누적값을 계산하니 -20점입니다. 따라서 아키텍트가 팀원들의 업무에 관여하여 멘토, 코치 역할을 어느 정도 수행하는 편이 더 효과적이다.

이런 팩터를 객관적으로 측정하기는 어렵다. 팩터마다 상대적인 가중치가 높은 경우(예: 전체적인 팀 경험)가 있는데, 이럴 때에는 주어진 시나리오나 조건에 맞게 메트릭에 가중치를 부여하거나 수정한다. 요는, 소프트웨어 아키텍트가 팀을 제어하고 팀원들의 업무에 관여하 는 정도가 팩터마다 다르다는 점, 그리고 이런 부분을 감안하여 아키텍트가 팀에 어떤 종류의 제어를 어느 정도 가할 것인지, 개발팀이 어떤 틀 안에서(예: 경계가 딱딱하여 제약이 심하거나 반대로 여유가 많아 느슨하거나) 작업을 수행하도록 만들지 고민해야 한다는 점이다.

22.4 팀의 이상 징후

가장 효율적인 개발팀의 규모는 다음 세 가지 팩터에 의해 결정된다.

• 프로세스 손실
• 다원적 무지
• 책임 확산

프로세스 손실(process loss, 브룩스의 법칙이라고도 함)은 원래 프레드 브룩스가 자신이 쓴 「맨먼스 미신(인사이트, 2015)에서 처음 고안한 용어이댜. 기본적으로 프로젝트에 인력을 더 많이 투입할수록 프로젝트를 수행하는 시간이 더 길어진다는 것이다. 그룹 포텐셜(group potention)은 팀원 모두의 집합적인 노력에 의해 정의되지만, 어느 팀이건 실제 생산성은 이 그룹 포텐셜에 훨씬 못 미칩니다. 이 차이가 바로 팀의 프로세스 손실이다.

유능한 소프트웨어 아키텍트는 개발팀을 잘 관찰하여 프로세스 손실을 찾는다. 프로세스 손실을 어떤 프로젝트나 과업을 수행하기에 올바른 팀 규모를 결정하는 유용한 팩터이다. 코드를 리포지터리에 커밋할 때 병합 충돌이 자주 발생하면 이는 프로세스 손실의 징후이다. 프로세스 손실을 방지하려면 팀 내부적으로 병렬 작업이 가능한 부분을 찾고 팀원들이 각자 별도의 서비스나 애플리케이션 영역에서 작업할 수 있게끔 환경을 제공해야 한다.

팀 규모가 너무 커지면 다원적 무지(pluralistic ignorance) 현상도 발생한다. 모든 사람들이 자신이 뭔가 너무 뻔한 것을 놓치고 있는 게 아닐까 두려운 나머지 어떤 표준에 순순히 동의하는 현상이다. 예를 들어, 어느 규모가 큰 팀의 팀원들은 대부분 두 원격 서비스가 메시징으로 통신하는게 최적이라고 생각한다. 그런데 한 팀원이 두 서비스 간 보안 방화벽 때문에 이건 말도 안 된다고 생각하지만, 함부로 입바른 말을 내뱉아 미움을 살까 두려워 (개인적으로는 동의하지 않지만) 메시징 사용에 마지못해 동의한다. 자칫 말을 잘못 꺼 냈다가 이렇게 뻔한 것도 모르냐, 하는 소리를 듣고 싶지 않은 것이다. 결국 표준에 동의하지 않은 이 팀원 생각이 옳았음이 밝혀진다. 누군가 진작 얘기했더라면 (그리고 팀 규모가 더 작았으면) 원안은 방화벽 문제로 적용할 수 없다. 대신 다른 프로토콜(예: REST)을 사용하자. 라는 더 나은 결론이 나왔을 것이다.

유능한 소프트웨어 아키텍트는 어떤 성격의 협업 회의나 토론을 하더라도 상대방의 표정과 몸짓을 끊임없이 관찰하며 다원적 무지가 일어날 것 같으면 조정자를 자처한다. 중간중간 끼어들어 그 동안 논의된 해결책에 대해 사람들에게 의견을 물어보고 그들이 발언할 때 그들 편에서 지지해주어야 한다.

적절한 팀 규모를 나타내는 세 번째 팩터는 책임 확산(diffusion of reponsibility)이다. 팀 규모가 커질수록 의사 소통이 잘 안 되는 건 모두가 공감하는 팩트입니다. 팀원 중 누가 무슨 일을 담당하고 있는지 혼란스럽다면 팀이 너무 커졌다는 신호이다.

유능한 아키텍트는 개발팀이 아키텍처를 잘 구현하도록 친절하게 안내하는 것은 물론, 팀이 건강하고 행복하게 공동 목표를 달성하도록 서로 협력하는 분위기를 조성한다. 이 세 가지 징후를 발견하여 결과적으로 개발팀 스스로 바로잡을 수 있게 도와주면 팀을 매끄럽게 꾸려갈 수 있다.

22.5 체크리스트 활용

체크리스트는 정말로 효과가 있다. 만사 든든히 하고 온갖 문제를 해결하는, 더 없이 훌륭한 수단이다. 그런데도 왜 소프트웨어 개발 업계는 체크리스트를 활용하지 않는 걸까? 우리는 개인적인 경험을 통해 체크리스트가 개발팀의 효율성에 지대한 영향을 준다고 굳게 믿지만 다소 미묘한 차이가 있다. 첫째, 소프트웨어 개발자는 항공기를 조종하거나 심장 수술을 하는 사람들이 아니다. 다시 말해, 그들이 하는 모든 일에 체크리스트가 필요한 것은 아니다. 팀을 효율적인 운영하려면 체크리스트를 활용할 때와 하지 말아야 할 때를 잘 구분해야 한다.

이건 체크리스트가 아니다. 이련의 절차와 단계가 체크리스트에 포함돼서는 안 된다. 있따라 실행되는 종속적인 작업들은 체크리스트에서 걸러내야 한다.

체크리스트에 적합한 프로세스는 순서나 종속된 작업이 없는 프로세스, 그리고 에러가 발생하기 쉽거나 누락되어 다음으로 넘어가기 쉬운 단계가 있는 프로세스이다. 아키텍트는 프로세스 내부의 필요한 모든 단계를 포착하되, 가능한 한 체크리스트는 최소화하는 게 좋습니다. 자동화하여 체크할 수 있는 항목은 체크리스트에서 제거해라.

체크리스트에 뻔한 내용을 기재하는 것은 두려워하지 마라. 뻔한 것도 대부분 넘어가거나 놓치기 일쑤이다.

우리가 경험상 가장 효과적이라고 생각하는 체크리스트 3인방은 개발자 코드 완료 체크리스트, 단위/기능 테스트 체크리스트, 소프트웨어 릴리스 체크리스트이다.

22.5.1 개발자 코드 완성도 체크리스트

개발자 코드 완성도 체크리스트는 소프트웨어 개발자가 코드를 완료했다고 말할 때 사용하기 좋은 도구이다. 완료된 것의 정의를 정의할 때에도 유용하다. 개발자가 이 체크리스트의 모든 항목을 완료했다면 실제로 코딩을 완료했다고 당당히 외칠 수 있다.

개발자 코드 완성도 체크리스트에는 다음과 같은 내용이 포함된다.

• 자동화 도구에 포함되어 있지 않은 코딩 및 포매팅 표준
• 자주 간과되는 항목(예: 로그 속에 파묻힌 예외)
• 프로젝트에 특정한 표준
• 특별한 팀 지침이나 절차

아키텍트는 체크 작업을 자동화하거나 플러그인 형태의 코드 유효성 검증기로 대체할 방법은 없는지 수시로 확인해야 합니다. 자동화 가능한 영역을 잘 찾아보면 체크리스트 분량과 노이즈를 모두 줄여 더 효과적인 체크리스트를 만들 수 있다.

22.5.2 단위/기능 테스트 체크리스트

단위/기능 테스트 체크리스트는 아마도 가장 효과적인 체크리스트 중 하나일 것이다. 이 체크리스트에는 대다수 개발자가 테스트를 잊기 쉬운, 다소 특이한 엣지 케이스 테스트가 들어있다. QA팀 사람들은 어떤 테스트 케이스에서 이슈를 발견할 때마다 이 체크리스트에 추가한다.

이 체크리스트에는 코드를 상대로 실행 가능한 모든 종류의 테스트가 포함되어 있어서 분량은 가장 많은 편이다. 가능한 한 완전 코딩을 보장해서 개발자가 체크리스트 점검을 마치면 기본적으로 코드를 프로덕션 배포가 가능한 상태로 만드는 것이 목표이다.

단위/기능 테스트 체크리스트에는 보통 다음과 같은 항목들이 있다.

• 텍스트 필드의 특수 문자와 숫자 필드
• 최솟값/최댓값 범위
• 흔치 않고 극단적인 테스트 케이스
• 누락된 필드

여기서도 개발자 코드 완성도 체크리스트처럼 자동화 테스트로 확인 가능한 항목은 체크리스트에서 제거한다. 예를 들어, 주식 거래 애플리케이션의 체크리스트에 매입 주식수의 마이너스 여부를 테스트하는 항목이 있고 이미 테스트 스위트의 단위/기능 테스트에 이런 체크 로직이 들어 있다면 체크리스트에서 삭제한다.

단위/기능 테스트 체크리스트는 일반적인 또는 특정한 테스트 시나리오가 소프트웨어 개발 프로세스에 포함됐는지 확인할 수 있는 수단으로, 별도의 팀이 이런 활동을 수행하는 환경이라 해도 이 체크리스트는 개발자와 테스터의 간극을 좁히는 데 효과적이다. 완전한 테스트를 수행하는 개발팀이 많을수록 테스트팀도 작업이 용이해지고 체크리스트에 없는 특정 비즈니스 시나리오에 집중할 수 있다.

22.5.3 소프트웨어 릴리스 체크리스트

소프트웨어를 프로덕션에 릴리스하는 작업은 소프트웨어 개발 라이프 사이클에서 가장 에러가 발생하기 쉬운 부분이므로 체크리스트를 작성하면 큰 도움이 된다. 빌드 및 배포 실패를 예방하는 데에도 탁월한 효능이 있고 소프트웨어 출시 관련 리스크도 크게 줄어든다.

소프트웨어 릴리스 체크리스트는 배포가 실패하거나 이슈가 발생할 때마다 새로운 에러와 사건을 해결하면서 계속 바뀌므로 가장 변화가 많은 체크리스트이다. 이 체크리스트에는 일반적으로 다음과 같은 내용이 포함된다.

• 서버 또는 외부 구성 서버의 설정 변경

• 프로젝트에 추가된 서드파티 라이브러리(JAR. DLL 등)

• 데이터베이스 업데이트 및 해당 데이터베이스의 마이그레이션 스크립트

  아키텍트는 빌드/배포가 실패하면 근본 원인을 분석하고 그 내용을 그때그때 소프트웨어 릴리스 체크리스트에 추가한다.

22.6 지침 제시

소프트웨어 아키텍트는 설계 원칙을 적용하고 지침을 제공하여 팀을 효과적으로 만들 수 있다. 개발자가 아키텍처 구현 작업에 착수할 어떤 틀(제약조건)을 마련하는 데에도 도움이 된다. 설계 원칙을 효과적으로 전달하는 것은 팀을 성공으로 이끄는 핵심 요소이다.

가령, 아키텍트가 개발팀에 레이어드 스택(layered stack, 애플리케이션을 구성하는 서드파티 라이브러리 집합(예: JAR, DLL 파일)) 사용에 관한 지침을 제공하려고 한다.

유능한 소프트웨어 아키텍트는 다음 질문에 개발자가 먼저 답하도록 유도함으로써 개발팀에 지침을 제시한다.

1. 제안하신 라이브러리와 기존 시스템의 내부 기능 사이에 중첩되는 부분이 있나?
2. 제안하신 라이브러리를 반드시 사용해야 하는 당위성은 무엇인가?

1번 질문은 개발자로 하여금 새 라이브러리가 기존 라이브러리나 기능으로도 충족되는지 다시 한번 살펴보도록 안내한다.

2번 질문은 새 라이브러리 또는 기능이 왜 꼭 필요한지 개발자가 자문하도록 유도한다. 유능한 소프트웨어 아키텍트는 추가 라이브러리가 필요한 기술적 타당성과 비즈니스 타당성을 둘 다 요구한다. 이는 개발팀 내에서 비즈니스 정당화의 필요성에 대한 인식을 제고하는 강력한 기술이다.

개발팀이 결정할 수 있는 사항과 결정할 수 없는 사항을 시각적으로 설명하면 설계 원칙을 효과적으로 전달하는 데 도움이 된다. 아래 그림은 레이어드 스택을 제어하는 구조(안내까지 포함)를 시각화한 예이다.

가령, 모든 서드파티 라이브러리에는 다음 세 가지 범주가 정의되어 있다.

특수한 목적

PDF 렌더링, 바코드 스캐닝, 그 밖에 딱히 커스텀 소프트웨어를 작성할 만한 이유가 없는 상황에서 사용되는 특수한 라이브러리

일반적인 목적

자바 진영의 아파치 커먼스, 구아바처럼 언어 API를 감싼 래퍼

프레임워크

퍼시스턴스, 제어 역전(inversion of control, 예: 스프링 Spring) 등에 사용하는 라이브러리. 이런 라이브러리는 애플리케이션의 전체 레이어나 구조를 형성하며 어디에나 널리 퍼져있다.

이렇게 범주화한 다음 이 설계 원칙을 중심으로 틀을 만든다.

일반적으로 아키텍트는 넌지시 개발자가 알아서 중복 분석을 한 후 정당화할 수 있다고 얘기하지만 라이브러리는 아키텍트의 승인이 필요한 범주이다. 끝으로, 프레임워크 라이브러리는 아키텍트가 결정한다. 이런 종류의 라이브러리는 개발팀이 분석할 대상은 아니며, 아키텍트가 오롯이 책임을 져야 할 부분이다.

22.7 마치며

개발팀을 잘 굴러가게 만들기란 참으로 어렵다. 많은 경험과 연습, 그리고 강력한 대인 관계 기술이 필요하다. 이 장에서는 탄력적 리더십, 체크리스트 활용, 설계 원칙을 효과적으로 전달함으로써 지침을 제공하는 간단한 기법들이 실제로 효과가 있고 개발팀이 더 스마트하게, 효율적으로 일하도록 만드는 데 탁월하다는 사실을 밝혔다.

소프트웨어 아키텍트는 팀을 기술적으로 이끌 뿐만 아니라, 아키텍처 구현을 통해 팀을 리드하기도 한다. 소프트웨어 아키텍트는 개발팀과 긴밀한 협력 관계를 유지하면서 팀 역학을 관찰하고 변경을 촉진하여 효과적으로 팀을 움직일 수 있다. 이것이 바로 기술만 가진 아키텍트와 유능한 소프트웨어 아키텍트를 구분하는 잣대이기도 하다.