마이크로서비스 아키텍처 구축(전면 개정판)

651

16

장

진화하는 아키텍트

경험에 비춰보면, 이 모든 것은 원활하고 명확한 의사소통과 책임에 대한 이해 부족으로 귀결

된다. 필자가 추진 중인 영역 교차 활동에 프로덕트 오너가 활동을 저해하는 결정을 내리는 모

습을 본다면 그들과 대화를 나눌 것이다. 그리고 아마도 단기적인 결정이 옳다는 답변을 들을

것이다 (이는 결국 의식적으로 받아들인 일종의 기술적 부채가 될 수도 있다 ). 다른 경우에는

프로덕트 오너가 전체 전략에 도움이 되도록 계획을 변경할 수 있을지도 모른다. 최악의 경우

에는 이 문제를 에스컬레이션해야 할 수도 있다.

앞서 몇 장에 걸쳐 언급한 온라인 부동산 회사인

REA

에서는 프로덕트 오너가 때때로 기술 부

채가 쌓이는 방식으로 작업의 우선순위를 결정해 후속 문제를 야기하는 경우가 있었다. 문제

는 프로덕트 오너가 주로 기능을 제공하고 고객을 만족시킬 수 있는 능력과 관련해 책임을 져

야 하는 반면, 기술 부채와 관련된 문제는 기술 리더에게 책임을 돌리는 경우가 많았다는 것이

다. 결국 프로덕트 오너가 소프트웨어의 기술적인 측면에 대해서도 책임을 지는 방식으로 바뀌

었다. 이는 프로덕트 오너가 시스템의 보다 기술적인 측면 (예: 보안 또는 성능)을 이해하는 데

더 적극적인 역할을 수행하고 수행해야 할 작업의 우선순위를 정하는 것과 관련해 기술 전문가

와 더 협력해야 한다는 사실을 의미했다. 기술 전문성이 없는 프로덕트 오너가 기술 활동에 대

한 우선순위를 정할 때 더 많은 책임을 지게 하는 것은 사소한 일은 아니지만, 필자의 ...