트레이드오프와 아키텍트 그리고 개발자의 소통 문제

뉴스를 빠르고 유익하게 소비하기 No. 17

고물가로 인심잃을까 조바심?…바이든, OPEC+에 증산 촉구를 읽으며 떠오른 생각을 씁니다. 다만, 기사의 초점과 전혀 다른 생각이라 미리 주제를 밝히면 대략 두 가지입니다.

트레이드오프 즉, 상충관계에 대한 생각

개발자에게 아키텍트로 나아가는 길

미국 대통령의 자리에서 하는 고민

기사는 유가 상승에 대한 미국 정부의 대처를 다루고 있었습니다. 개인적으로 최근 제주도에서 휘발류 가격이 (리터당) 1,700원을 넘어서서 기사가 관심이 갔습니다. :)

미국자동차협회(AAA)에 따르면, 미국의 휘발유 가격은 갤런당 3.18달러까지 뛰었다. 지난해에 비해 1달러 이상, 올해 초에 비해서도 30% 이상 올랐다. 휘발유 가격만 오른 게 아니라 지난달 소비자물가지수(CPI)를 구성하는 가격들이 다 많이 올랐다. 이날 발표된 7월 CPI 상승률은 전년 동기 대비 5.4%, 지난달 2008년 이후 최고치를 기록했던 것과 같았다. 식료품 가격, 임대료, 그리고 휘발유와 중고차 가격, 호텔 이용료 등이 다 많이 오르고 있어 서민 생활을 옥죌 가능성이 엿보인다.

뒤이어 기사는 유가 상승에 대해서 바이든 행정부의 고민과 대응을 설명하고 있습니다. 미국 대통령 입장에서 유가 상승문제가 어떤 이슈인지 대강을 짐작할 수 있습니다.

바이든 행정부의 이 같은 산유국 압박은 도널드 트럼프 전 대통령이 툭하면 했던 했던 압박과 본질적으로 다르지 않다. 트럼프 전 대통령은 사우디아라비아에 대한 군사 지원을 철회하겠다는 ‘협박’까지 하며 감산을 요구하기도 했다. 이 같은 관행을 깨겠다던 약속을 바이든 행정부는 스스로 어기면서까지 증산을 요구하고 있는 것이다.

그리고, 풍자적인 만화로 국가간 갈등을 압축해서 나타냅니다. 

트레이드오픈 혹은 상충관계 연상하기

기사를 읽다가 주제를 벗어나 생각을 펼친 계기는 아래 문장입니다.

바이든 행정부의 친환경 기조도 흔들리는 셈. 석유 생산량을 늘린다는 건 화석연료 사용을 줄이고 청정 에너지원을 기반으로 한 경제로 가겠다던 방향을 스스로 ‘배신’하는 것이 되기 때문이다.

트럼프 정부의 관행을 극복하겠다고 했으나 유가상승을 막기 위해 이를 고수하기 어려운 입장이 읽힙니다. 그리고, 물가의 지표가 되는 유가를 잡아서 대중적 인기를 얻으려면, 친환경 기조라는 선도적인 역할에 대해서는 국제적인 신망을 잃을 수 있는 상황입니다. 

여기서 저는 과거 장기간 소프트웨어 아키텍트 역할을 해오면서 몸에 배인 트레이드 오프란 개념이자 단어가 툭 튀어나왔습니다. 뒤이어 머리속에 떠오른 이미지를 묘사해보면 아래와 같습니다. 트레이드 오프(trade-off), 우리말로는 상충관계입니다. 하나를 얻으면 하나를 잃을 수 있는 상황 혹은 결정을 요하는 관계를 지칭합니다.

사실 이런 발상은 제가 일하며 몸에 익힌 특수성에 기인한 듯도 하지만, 굉장히 보편적인 일이라는 생각도 동시에 듭니다. 무슨 말이야 하면, 트레이드 오프란 단어를 떠올리는 것은 많은 사람에게는 익숙한 일은 아닐지 모르지만, 중요한 두어 가지 선택 중에 하나를 택해야 하는 고민하는 일은 거의 모든 사람의 일상을 가득 메우는 문제이기도 합니다. 

결국, 워커홀릭에 가까웠던 저라는 사람은 일하는 과정에서 배운 지식을 원칙삼아 일이 아닌 부분도 익혀왔던 듯합니다. 보다 익숙한 것에서 비롯해서 생소한 것을 배우는 것은 자연스러운 학습 과정이니까요. 누군가의 지도가 아니라 스스로 탐험하듯이 배운 것이라 방법을 아주 구체적으로 묘사할 수는 없지만, 소프트웨어 개발을 하며 배운 것들을 컨설팅 영업, 컨설팅 수행 그리고 조직을 빌드업할 때에도 똑같이 써오는 듯합니다. (최근에는 가장 역할에도...)

개발자에게 아키텍트로 가는 길

뒤이어 또다른 개념이 머리속에서 튀어나옵니다. 바로 아키텍트인데요. 트레이드 오프가 제 기억속에서 불러낸 개념이죠. 아키텍트 역할을 하면서 자주 다루던 것이니까요. 아키텍트를 떠올리며 자연스럽게 이런 가정을 해봅니다.

혹시 개발자와 아키텍트 차이가 그런 것일까?

개발자는 트레이드 오프에 대해 훈련받는 경우가 드뭅니다. 개발자들도 그런 상황을 수도 없이 겪지만, 다수의 개발자는 자기 주장을 다른 사람 관점으로 표현하는 일에 익숙하지 않습니다. 언쟁을 풀지 못해 팀웍이 깨지는 일이 비일비재하게 발생합니다. 많은 개발자들이 프로그램을 잘 짜는데, 동료나 개발자가 아닌 다른 사람들과 소통하는데 어려움을 겪는 일을 수도 없이 목도합니다.  

지나치게 일반화 하는 오류를 범하지 않도록 주의한다는 전제하에서, 개발자가 아키텍트로 변해야 하는 동인 중에 하나는 다른 이들에게 상충관계를 잘 설명하는 일입니다. 경영자나 관리자에게 중요하게 생각하는 요소들과 기술문제를 연결해서 소통하는 일은 너무나도 중요합니다. 흔히 CTO 역할을 하는 사람들의 주요 책임이죠. 또한, 개발자가 다수가 되면, 개발자 사이에서 의견을 조율해서 시스템이 바람직한 특징들을 갖추도록 조율해야 합니다. 그런데, 이런 문제는 경영자들의 관심밖이거나 이해가 어려운 경우가 있습니다. 이때는 (CTO일수도 있지만) 흔히 시니어 개발자가 나서서 개발자들이 주장하는 항목 사이의 상충 관계를 드러내서 생산적인 소통과 공감, 수렴을 유도할 수 있어야 합니다. 

우리가 CTO나 시니어 개발자를 아키텍트라 부를 필요는 없습니다. 소프트웨어 아키텍트라는 말은 아직 충분한 공감대가 형성된 용어는 아닌 듯합니다. 게다가 아키텍트는 몸값을 높이기 위한 욕구탓에 오염된 히스토리도 있습니다. 여기서 제가 말하는 아키텍트는 결국 기술문제에 있어 상충관계를 포착해 의사소통을 할 수 있는 사람을 뜻합니다. 그런 맥락에서 개발자가 아키텍트가 되기 위한 필요조건은 다양한 관점을 이해하는 것입니다. 사람들을 이해하고, 그들의 욕구와 이해관계 혹은 사회적 지위(역할)에서 오는 임무와 목표에 대해 공감할 수 있어야 하는 것이죠.