[발췌] 상아탑 아키텍트 대처하기

<소프트웨어 장인> 227쪽에 있는 내용입니다.

항상 생산적인 대화를 추구해야 하지만, 어떤 상아탑 아키텍트들은 그렇지 않다. 그들은 개발자들을 그냥 시키는 것만 하는 단순한 코더로 본다. 우리가 취할 수 있는 행동 중 하나는 상아탑 아키텍트가 자신의 결정에 책임을 질 수밖에 없도록 만드는 것이다. 우리가 기술적 솔루션에 대해서 아무런 의사 표현도 하지 않았다면 우리 역시 아무런 책임을 지지 않는 것이 공정하다. 어떤 사람은 이러한 전략을 수동적인 공격이라고 부른다. 나는 최후의 수단이라고 말하고 싶다.

큰 개발 조직에서 일 할 때, 나와 그 조직에 있던 상아탑 아키텍트의 긴장관계가 극으로 치달은 적이 있다. 잘못된 아키텍처, 관료주의, 불필요한 복잡도, 당황스럽기만 한 비생산적인 논쟁으로 몇 개월을 보낸 후 나와 상아탑 아키텍트는 아래와 같은 대화를 나누었다.

아키텍트: 누가 이런 웹 프레임워크를 사용하라고 허가했습니까? 당신은 왜 나의 가이드를 무시하나요?

나: 이 프레임워크 말고는 우리 프로젝트에 잘 들어 맞는게 없었어요. 프레임워크를 정할 때 당신의 허락이 필요한지는 몰랐어요. 제 생각에는 프레임워크 선택은 개발팀이 권한과 책임을 가진 사안입니다.

아키텍트: 내가 왜 조직에 있다고 생각해요? 어떤 프레임워크와 라이브러리를 사용할지 사내 모든 프로젝트들에 대해서 내가 결정해요.

나: 아~ 네 몰랐습니다. 저는 당신의 역할이 엔터프라이즈 아키텍트라고 알고 있어요. 시스템의 정보 흐름과 애플리케이션들 간의 연동 방식을 관리해서 비즈니스 요구조건을 만족시키는 역할로 이해하고 있었어요.

아키텍트: 모든 기술적 솔루션에 대해서도 내가 감독해요. 기술적인 비전에서부터 구현까지, 프레임워크에서 라이브러리까지 모두 포함됩니다.

나: 제품 오너가 말하기를 비즈니스 부서에서 아직 요구사항을 파악하는 중이라고 하더군요. 너무 앞서 나가서 짐이 되지 않으려면 우리의 코드 베이스를 최소한으로 유지해야 합니다. 그래야 요구사항이 바뀌더라도 최대한 빨리 대응할 수 있지요. 그러면 전체적으로 피드백 루프가 짧아지고 비즈니스에서 하고 싶은 대로 할 수 있습니다.

아키텍트: 일을 어떻게 진행하고 있는지, 계획이 무엇인지 말해보세요.

나: 가장 먼저 지속적인 통합 환경을 구축했어요. 로컬 작업 내용들이 라파지토리에 반영되면 연속 통합 서버에서 모든 테스트들을 수행합니다. 모든 테스트에 통과하면 애플리케이션이 UAT(사용자 인수 시험)환경에 전개됩니다. 이 사이클 전체가 하루에 몇 번씩 반복해서 이루어질 수 있지요. 비즈니스 담당은 웹 브라우저만 새로고침해서 우리가 변경한 사항들을 확인할 수 있어요. 이렇게 하면 비즈니스 담당이 시스템이 어떻게 돌아가는지 직접 보면서 어떤 부분을 바꾸거나 추가할지 결정할 수 있죠. 이것이 비즈니스 담당을 돕기 위해 우리가 찾은 방법 중 하나입니다.

아키텍트: 그건 좋습니다. 하지만 그것이 프레임워크를 마음대로 정할 수 있는 권한을 주는 것은 아니에요. 당신은 내 가이드를 따라야해요.

나: 그래요? 그렇다면 당신이 우리 애플리케이션의 모든 기능적, 비기능적 요구사항을 이해하고 있다고 가정해도 되는 건가요? 우리가 어떤 기술을 사용해야 할지 정해 주려면 그래야만 할 겁니다. 그런데 비즈니스 담당조차도 아직 파악 중인 것을 당신이 어떻게 알고 있을 수 있죠?

아키텍트: 나는 그럴 필요가 없어요. 우리가 구매한 인메모리 데이터 그리드 솔루션과 웹 프레임워크는 모든 애플리케이션들에 적합해요. 모두가 그것을 활용해야 한다구요.

나: 네, 그 솔루션들이 좋을 것이라고 믿어요. 그럼 우리와 함께 코드를 작성할 거예요? 그 도구들과 프레임워크에 대해서 당신의 경험들이 큰 도움이 될 것이라 확신해요. 하지만 제가 보기에는 개발팀에서 선택한 것들이 더 적합하다고 생각합니다. 비즈니스에 빠른 피드백 루프를 제공해주고 생산성을 높여줍니다. 그 선택사항들은 담당 애플리케이션의 내부에만 영향을 미치고 외부에서는 보이지도 않습니다. 다른 애플리케이션과 연동하는 부분과 전체 에코시스템의 역할에는 아무런 변화도 일으키지 않습니다.

아키텍트: 글쎄요, 내 역할은 기술 스택을 표준화하는 거예요. 기술 스택이 표준화되면 개발자 의존성을 줄일 수 있습니다. 모두가 당신처럼 슈퍼 코더일 수는 없습니다(그가 ‘코더’를 말할 때 미묘하게 하대하는 뉘앙스가 있었다).

나: 개발자 의존성을 줄여서 쉽게 대체할 수 있게 한다구요? 맞는 말입니다. (그리고 조용히 비꼬는 톤으로) 지금 당신은 우리 일에 적합한 도구를 선택하면 안 되고, 역량이 떨어지는 저급 개발자들이 쉽게 쓰기 위한 도구를 선택해야 한다고 말하는 건가요? 재능있는 개발자를 채용하거나 기존 개발자를 훈련시키는 대신 개발자 수준을 낮추고 품질을 희생하자는 겁니까? 좋아요. 비즈니스 담당에게 가서 그렇게 설명하지요.

아키텍트: 지금 말장난합니까? 나는 그렇게 말하지 않았어요.

나: 죄송합니다. 그런 의도는 아니었습니다. 아마도 제가 잘못 이해한 것 같네요. 당신의 의도한 것이 정확히 무엇인지 설명해 주시겠습니까? 어떻게 프로젝트의 개발에 직접적으로 참여하지 않는 사람이 팀에서 사용할 도구와 프레임워크를 선정할 수 있죠? 당신 입장에서는 애플리케이션 하나가 파워포인트 장표의 수많은 박스들 중 하나 정도로 보일 겁니다. 왜 그 박스 하나의 내부적인 세부사항이 어떻게 구현되어야 하는지에 간섭하는 거죠? 그 박스들끼리 어떻게 대화하고 각각 박스가 어떤 역할을 해야 하는지에만 집중하는 것은 왜 안 될까요?

아키텍트: 좋든 싫든 그게 내 역할입니다. (그는 화가 난 목소리로 말했다) 나는 모든 프로젝트의 기술 스택을 선정합니다. 만약 다르게 하고 싶다면 내 허락을 맡아야 합니다. 그게 내 책임과 권한입니다.

나: 알겠습니다. 전혀 문제될 것 없습니다. 내 자리로 돌아가서 프로젝트 관리자, 비즈니스 분석 담당을 포함해서 프로젝트에 관계된 사람들 모두에게 메일을 쓰겠습니다. 물론 당신도 포함해서요. 한동안 프로젝트를 중단할 것이고, 모든 메이븐 리파지토리를 뒤져서 우리가 허가받은 라이브러리를 사용하고 있는지 확인하고, 사용이 허가된 기술 목록을 기다릴 것이라고 쓰겠습니다. 그 목록이 오면 당신의 요청에 합치되도록 모든 소프트웨어를 고칠 것이고 몇 개월, 못해도 최소한 몇 주는 일이 진행되지 않을 것이라고 쓰겠습니다. 그리고 모든 프로젝트 이해관계자들, 투자자, 제품 오너에게 이 기간 동안 비즈니스 변경사항이 있으면 당신에게 직접 이야기 하라고 하겠지요. 이 프로젝트에 투자를 한 사람들에게 개발 중단으로 인한 모든 문제를 포함해서 당신이 선정한 기술 때문에 발생하는 모든 문제들은 당신에게 직접 이야기하라고 할게요.

(아키텍트는 우려 섞인 표정으로 내 말을 가로막으려 했지만 나는 말을 이어 나갔다)

나: 제품 서비스 담당(상용 서비스 중인 애플리케이션의 유지보수를 수행하는 사람들)과 비즈니스 담당에게도 말하겠습니다. 우리 애플리케이션이 당신의 가이드를 백퍼센터 충족한 상황이 되면, 모든 긴급한 문제들은 당신에게 바로 전달하라고 하겠습니다. 왜냐하면 당신이 그 기술을 선택했고 개발자들이 볼 때 당신만이 조직 내에서 가장 잘 그 기술을 이해하고 있다고 봐야 하기 때문이지요.

아키텍트: 잠깐, 나는 그런 역할을 하는 사람이 아니에요. 프로젝트 수행은 당신이 할 일입니다. 내가 아닙니다. 솔루션을 딜리버리하는 책임은 개발팀에 있어요!(그는 신경질적으로 말했다)

나: 제가 제대로 이해했나 봅시다. 결정 권한은 당신한테 있지만 그에 대한 책임은 개발팀이 집니다. 프로젝트가 잘 되면 당신이 방향을 제시했으니 당신의 공입니다. 만약에 프로젝트에 문제가 생기면 개발팀이 책임을 지고 모든 부담을 떠 안아야 합니다. 맞습니까? (나는 속으로 참 말도 안 되는 불공정함이라고 생각했다) 그런 식으로 일 할 수는 없습니다. 프로페셔널이라면 자신의 결정에 책임을 질 수 있어야 해요. 뭔가 잘못되었을 때 누군가가 책임을 묻는다면 기꺼이 받아들일 것입니다. 하지만 결정을 하는 것은 저를 포함한 개발팀입니다. 당신에게 두 가지 선택권을 주겠습니다. 개발팀이 직접 모든 결정을 하고 그에 대한 모든 책임도 함께 지거나 아니면, 제자리로 돌아가서 당신이 모든 기술적 의사결정의 책임자이니 어던 문제가 발생하든 가장 먼저 당신에게 연락하라고 하겠습니가. 어떻게 하길 원해요?

아키텍트: 당신은 너무 극단적이예요. 물론 당신이 생각하기에 더 나은 기술들을 실험해보는데는 아무 문제가 없습니다. 그런 것들까지는 상관하지 않습니다. 내가 원하는 것은 나의 허락 하에 하라는 겁니다.

나: 그런 식이라면 내 입장은 동일합니다. 개발팀이 선택한 기술에 대해서 설명하는 것은 당신이든 누구든 관심이 있는 사람에게 기꺼이 할 수 있습니다. 내부 위키 사이트에 각각의 선택이 어떤 배경에서 이루어졌는지, 어떤 도구들과 라이브러리들을 비교해봤는지 자료를 올리겠습니다. 우리 애플리케이션이 많은 애플리케이션들로 구성된 큰 에코시스템 안에서 동작한다는 것을 이해하고 있습니다. 외부 모듈과의 연동에 대한 가이드라인이라면 따르지 않을 이유가 없지요. 애플리케이션 내부를 개발할 때 사사건건 당신의 허락을 받아야 한다면 수용할 수 없다는 것을 분명히 밝힙니다. 다시 말씀 드립니다만 제가 어떻게 하길 원하세요?

아키텍트: 모든 결정들에 대해서 문서화를 하세요. (그는 나를 죽이고 싶은 감정을 숨기려 애쓰며 말했다) 그리고 내가 알 수 있도록 항상 공유해 주십시오.

이 논쟁 이후에 외부의 영향 없이 자유롭게 의사를 결정했다. 상당히 빠른 속도로 비즈니스 부서가 원하는 기능을 버그 없이 구현할 수 있었기 때문에 비즈니스 담당자들이 대단히 기뻐했다. 우리 또한 행복했다. 실질적인 비즈니스 가치를 만들어내고 있다는 보람을 느낄 수 있었고 비즈니스부서로부터 우리의 노력도 인정받을 수 있었다. 몇 달 후, 회사의 고위 관리자들은 그 상아탑 아키텍트를 다른 부서의 프로젝트로 보냈다고 우리 개발팀에는 아키텍트가 필요 없다고 이야기했다.

진정한 소프트웨어 프로페셔널은 권한에는 항상 책임이 따른다는 것을 이해하고 있다. 권한을 갖고 싶다면, 책임질 수 있는 준비를 해야 한다. 이미 책임이 주어져 있다면, 관련된 의사결정에 권한도 가질 수 있도록 해야 한다. 상아탑 아키텍트들은 그들의 커리어에 해를 입을까봐 자신의 의견에 책임지기를 두려워한다. 관료주의와 정치 뒤에 숨는다. 그들이 당신 앞을 가로막는 것을 피하고 싶다면, 그들의 결정에 책임지도록 만들어야 한다.

• 산드로 만쿠소, 권오민 옮김, <소프트웨어 장인>, 길벗, 2015