아주 이상적인 아키텍처
도메인 모델링 세미나 5
지난 주에 올린 <데이터 제품 접근방식과 그 표현>편을 공개했더니 페이스북 대화 중에서 아래 의견을 보았다.
아키텍쳐는 의사소통의 문제가 아니라 조직과 권력구도의 문제입니다
반쯤 동의할 수 있는 글이다.
권력 구도로 인해 소통이 어려운 환경
많은 경우 조직 구조에 따라 소통이 만들어진다. 이렇게 조직을 지배하는 힘(권력)은 당연히 아키텍처에도 영향을 끼친다. 예를 들면, 약 10 여년전 빅데이터 프로젝트가 유행할 때 데이터 공유가 어려운 이유는 기술이 아니라 조직 내의 권력 구도였다. 데이터 공유 자체를 원하지 않는 힘있는 사람이 많았던 것이다.
반면 그렇게 고착화 된 아키텍처를 바꿀 수 없는 현실로 보는 관점을 내 가치관과는 거리가 멀다.
아키텍처는 의사소통에 관한 문제다
내가 Vaughn Vernon의 글을 인용하고 반복해서 인용하는 이유는 아키텍처를 제도의 문제로 보고 싶은 이유다. 20년 쯤 전에는 설계를 한번 하며 고칠 수 없는 일로 보는 시각이 지배적이었다. 지금은 그렇지 않다. 아래는 설계 방법에 대해 가장 활발히 연구하는 집단인 DDD 커뮤니티에서 그린 모델링(설계) 절차에 대한 그림이다.
내가 밑줄 친 내용처럼 이들은 반복 개선과 지속을 기본으로 한다. 내가 말한 제도의 문제로 아키텍처와 설계를 인식하는 일이다. 이렇게 만든 코드는 지속 가능하다. 이러 상태의 프로그램은 종종 제품이라고 불리운다.
반면에 한번 설계하여 만들어지고 권력에서 멀어진 프로그램은 레거시가 된다. 레거시는 보통 제품이라고 불리기 보다 권력층과 거리가 먼 집단에서 맡는다. 나는 레거시 코드를 수정하는 일이 (조직내에서) 의미를 지니려면 수정한 이후에는 합당한 의사결정에 의해 보호(?)될 수 있어야 한다고 믿는다. 이렇게 제도적 관점에서 아키텍처를 볼 수 있어야 비로소 실용적/실무적 시각을 갖출 수 있다고 믿는다.
품질에 대한 기준을 누가 정하는가?
사실, 페북 댓글은 그냥 지나치고 넘어갈 문제였는데, 이 글을 쓰게 된 계기는 구독하는 Kent Beck의 글 <Better?> 때문이다. Better 즉, 무엇이 더 낫다 혹은 좋다고 말할 때도 누구의 기준이냐 따라 의미가 전혀 다르다는 글이었다.
As soon as I started talking about “better” software, I got a flood of definitions of quality, each seeming to advance some agenda of the definer. (To be sure, I have my own agendas.) I’m going to take a crack here at what I mean by “quality”.
이런 내용을 들으면 나에게 가장 먼저 떠오르는 단어는 맥락(context)이다. 위키피디아 정의를 보자.
Context (language use), the relevant constraints of the communicative situation that influence language use, language variation, and discourse summary
어떤 대화를 할 때 대화 상황의 소통을 돕는 적절한 제약사항을 정의한 것이다. 나는 모델링 할 때 <시스템 구동의 맥락(context) 파악하기>편에서 소개한대로 가장 먼저 이해관계자를 파악하고, 그들이 원하는 시스템 쓰임새를 구체화 해나간다. 이걸 드러낸 그림도 시스템 맥락도(Context diagram)이라고 부른다.
간단한 맥락도 예시우리가 어떤 상황에 대해 이야기할 때 (자연과학에 대한 이야기가 아닌 다음에야) 이해관계자와 그들의 욕망을 배제하면 알맹이 없는 내용이 된다. 다른 말로는 '맥락이 없다'고 할 수 있다. 그렇다. 맥락을 파악하기 위해서는 우리가 다루는 문제가 도대체 누구의 문제인지, 누가 이익을 보고, 누가 손해를 보는 지를 알아야 한다.
아키텍처를 조직의 지속가능한 제도로 활용하기
두 개의 글, 하나는 페북 댓글과 Kent Beck의 글에서 촉발해 쓴 글이지만 메시지가 불분명했던 지난 글 <아키텍처는 의사소통에 관한 문제라서?>를 보강하는 글로 마무리를 해보려고 한다. 갑자기? 갑작스럽지만 그게 좋겠다.
지난 글에서 Vaughn Vernon의 짧은 글과 그림을 인용하며, 지휘자 같은 코드는 좋지 않다고 주장했다. 그 주장의 근거는 주관적 경험에서 비롯한 것인데, 그런 코드는 대체로 수정 빈도를 줄이는 경향이 있어 레거시를 만들기 때문이다.
만일 Smart Client를 발견하면 나는 레거시를 유발하는 아키텍처는 좋지 않다는 근거로 수정을 제안할 것이다. 이전 글에서 Smart Client 대신 유사 코드로 예를 들었던 '10만 줄이 넘는 주문 코드'를 소환해보자. 여러분이 이 코드를 담당하는 개발자라면 어떻겠는가? 내가 만났던 담당자는 섣불리 코드를 고칠 수 없었다. 그의 일상을 관찰하면 마치 평론가처럼 '이럴 것입니다' 라고 말하는 일이 개발하는 일보다 훨씬 많았다. 스스로 택한 길이 아니라 그렇게 될 수 밖에 없는 사연과 시절이 있었기 때문이다.
권력의 작용을 이해해야 효과적인 아키텍처를 수립할 수 있다
앞서 내가 반만 동의한다고 말한 페북상의 글을 다시 떠올려보자.
아키텍쳐는 <중략> 조직과 권력구도의 문제입니다
한편, 앞서 소개한 Kent Beck의 글에 링크가 걸린 <Dimensions of Power>라는 제목의 글이 있다. 그 글은 이렇게 시작한다.
“Well I’m a senior engineer so we’ll do it my way.” I always hated conversations like that as a junior engineer but they seem to be a natural consequence of titles. Keep titles private and the best ideas will win instead of the best titles. Right?
번역까지는 자신이 없어 파파고 번역을 첨부한다.
요즘 스타트업에서는 직함을 배제하는 일이 잦다. 효과성을 떠나서 지향점이 비슷하다고 할 수 있겠다. 아마도 조직 차원에서 최고의 아이디어에 힘을 싣자는 시도가 아닐까 생각한다. 하지만, 이런 일의 실효성을 말할 때 많은 사람들은 결국 오너(혹은 리더)가 어떻게 하느냐가 관건이라고 말한다. (나도 동의한다.)
제도처럼 자동하는 아키텍처의 이상
그리고 <Dimensions of Power>을 쭉 읽다 보면 Kent Beck이 나열한 56까지 종류의 힘을 볼 수 있다. 그걸 다 읽어볼 필요는 없지만, 힘이라는 것이 인식하기에 따라 굉장히 다양한 양상으로 나타날 수 있구나 고개를 끄덕였다.
그리고 마지막에 그가 강조한 결론의 문장이 눈에 들어온다.
Power differentials will always exist. Wise, effective use of power to achieve good decisions & growth require those with power to lend it to those with less.
힘의 차이(Power differentials)는 항상 존재한다. 그래서 (그 차이 자체를 문제 삼기보다는) 현명하고 효과적인 힘의 사용으로 바람직한 성장을 이뤄낼 수 있는 의사결정을 내리는 데 써야 한다. 그렇게 하려면 힘이 부족한 곳에도 힘을 빌려 목소리를 낼 수 있게 해야 한다. 공청회와 같은 민주적 장치는 효율을 떨어뜨리는 의사소통 방식이지만, 바로 이런 일들이 벌어질 수 있게 인류가 만들어낸 유산이다.
아키텍처를 제도로 활용한다는 의미는 권력자의 의중에 맞춰 고정된 시스템 구조를 굳건히 하는데 초점을 두기 보다는 시장의 필요에 따라 수정 가능하도록 지능적으로 만들자는 시도다. 그렇게 하기 위해서는 현장과 마주치는 이해관계자가 힘이 없더라도 힘을 빌려 그(녀)가 오늘 배운 것들을 전할 수 있게 만들 수 있다면 지속 가능한 시스템에 기여할 수 있을 것이다.
