이제 아키텍트는 필요없다, 아키텍처를 이해하는 전문가가 필요할 뿐

팝잇에 예전에 썼던 글의 댓글을 한참 후에 발견했다. 그러던 중, 하나의 글에 달린 댓글에 답변을 달고 있는데 데자뷰가 느껴졌다. 언젠가 이런 일을 했던 느낌...

다시 아키텍트란 개념를 만나다

올 봄, 그러니 무려 7개월 전에 댓글 중 일부에 대한 답으로 다음 글을 썼다. 어이없었다. 까맣게 잊고 다시 똑같은 댓글을 길게 쓸뻔했다. 하지만, 그러는 중에 아키텍트에 대한 신경을 곤두세웠던 과거의 여운이 다시 날 찾아왔다. 나에겐 애증으로 남은 단어이자 역할이자 하나의 개념이다.

나는 교과서에 나오는 아키텍트 역할에 충실하게 일한 경력이 꽤 된다. 그중 비교적 젊었을 때는 역할에 대한 자부심이 강해서 내 생각과 다르게 일 하면서 '아키텍트'라 칭하고 다니는 일에 대해 반감이 컸다. 어릴 때니 정의감이 더 강했다. 물론, 그것이 우물안에서 규정한 정의감이란 사실을 몰랐을 뿐이지...

여하튼 아키텍트란 일에 대한 프라이드나 애착이 강했다. 그런데 지금은...

적폐가 따로 있는 것이 아니다

요즘 적폐청산이 한창이다. 모두가 '적폐'를 말할 때 과연 얼마나 일치하는 생각인지 의문이다. 가끔 내용을 잘 모르면서 타인에게 엄청난 비난을 쏟는 사람을 보면 반작용이 일어나곤 한다. 그 중 하나가 적폐의 응용이란 글을 쓸 때, 떠오른 생각이다. 잘못을 인지하고도 고치지 않거나 오히려 걱정했던 부작용이 일어나지 않는다는 점을 악용하여 그 행위를 지속하면 누구나 적폐와 가까워지는 것이다.

내가 아키텍트에 대해 발끈하는 경우는 간헐적인 사건이다. 대개는 이제는 사라져야 할 진부한 생각이 세상을 호도할 때이다. 7개월만에 다시 아키텍트에 대해 떠올리니... 이젠 흥미없는 개념이었다. 왜 일까? 한 때 내 가슴을 뜨겁게 하고, 젊은 시절을 쏟아 붓게 한 것인데 한 순간에 소멸될 리가 있나?

일단, 열어서 찾아봤다. 습관처럼 위키피디아로~

이젠 아키텍트는 필요없다

방금 찾아보고 확신이 생겼다. 확신은 바로 '이젠 아키텍트란 직함은 필요없는 시대란 사실'.

A software architect is a software expert who makes high-level design choices and dictates technical standards, including software coding standards, tools, and platforms. The leading expert is referred to as the chief architect.

번역해보면, 소프트웨어 아키텍트란  소프트웨어 전문가로서 상위 수준의 설계 결정을 하고 기술 표준을 정한다. 기술표준은 코딩 표준, 도구 그리고 플랫폼을 포함한다.

현대의 빠른 시장 경쟁은 기민한 조직 구성을 요구한다. 회사에 개발팀을 하나로 꾸리는 형태가 아니라 업무 혹은 서비스 영역별로 팀이 꾸려지고 개발팀이 내재되는 형태에 가까워야 한다. 이에 대해 마이크로 서비스 구축 경험을 통해 설명한 바 있다.[1]

운좋게도 나에게 마이크로 서비스 아키텍처를 주문했던 두 분의 훌륭한 경영자가 있었다. 둘 다 개발자 출신은 아니지만, 빠른 시장 대응(Time to market)을 위해서는 소수가 독립적으로 판단하고 개발하는 조직이 필요하다는 데에 초점을 두고 있었다. 한 분은 이를 마이크로 셀이라고 표현했다. 린(Lean)이나 애자일 관련 자료를 찾아보면 이론적으로 마이크로 셀을 구축하는 방법론은 어렵지 않게 찾을 수 있다. 그러나, 우리가 일할 대상은 모두 감정과 생각이 있는 사람들이다. 그래서 일원화된 방식으로 성공을 기대하는 것은 어리석은 일이다. 그래서, 각자 조직에 맞는 방법을 찾아 끊임없이 시도해야 한다.

소수가 독립적으로 판단하고 개발하는 조직으로 구성되어 있다면, 각 팀마다 아키텍트가 있어야 한다. 여기서 딜레마가 발생한다. 아키텍트는 시장에 널려 있는가? 아니면, 양성(?)이 쉬운 역할인가? 전혀 그렇지 않다. 만일 회사에 아키텍트 역량을 보유한 사람이 한 두명뿐이고, 개발팀은 다수라고 해보자. 이 상황에서 어떻게 그들의 역량을 활용할 것인가? 어떻게 필요한 곳에 그들의 경험이 쓰이게 할 것인가?

전업 아키텍트가 있다고 해보자. 개발팀이 커지면 그는 점차 정신 없이 일하지만 어디에도 도움이 되지 않는 사람이 될 수 있다. 왜 그럴까? 업무 성격에 따라 설계 결정이 전혀 다른데, 그 모든 것을 소화하기는 어렵다. 개인입장에서 선택과 집중이 필요하다.

자연스럽게 (1) 중요한 업무에 개발자로 참여하거나 (2) 공용으로 사용할 수 있는 소프트웨어(통상 플랫폼이라고 부르기도 함) 인프라 개발을 하거나 아니면 (3) 지향을 달리하여 PO(Product Owner)나 PM(Program Manager) 역할을 하면서 아키텍처에 대한 이해를 사업적으로 활용하는 방식이 자연스러운 확장 방향이다. 고로 고립된 형태로 '아키텍트'가 존재할 가능성은 조만간 0으로 수렴할 것이다.

아키텍처를 이해하는 전문가는 필요하다

이러한 생각은 실제로 내가 몸으로 겪은 경험에서 베어나온 것이다. 앞서 소프트웨어 아키텍트 정의해서 언급한 두 가지 행위(makes high-level design choices and dictates technical standards)중에서 1년 정도는 후자가 중요하지 않았다.

개발조직이 크게 바뀌어야 하는 경우 예를 들면, 외주 개발 맡기고 운영만 하던 조직이 실제 개발을 해야 한다거나 한 종류의 DBMS만 쓰던 조직이 다양한 DBMS를 쓰고 모바일 개발을 해야 하는 상황이라면 기술 표준따위는 무시해도 상관없다. 적어도 초반에는 용기가 절대적으로 필요하다. 그리고, 할 수 있다는 믿음과 희망을 줘야 한다.

과거에 아키텍트였던 사람이라면 그들에게 기술적으로 믿음을 줄 수 있는 사람이 되어야 한다. 이런 것이 아키텍트에 대한 현대적인(Modern) 정의이다. 우리 팀에는 현재 두 명의 아키텍트 역량 보유자가 있다. 한 명은 필자인데 코딩을 멈춘지 6년이 넘었다는 약점을 갖고 있지만, 그 기간만큼 유통업에 종사했다는 강점을 갖고 있다. 따라서, IT측면에서 뒤떨어진 유통회사가 디지털회사가 되기 위해 어떤 방향으로 나아가야 하는지 감이 있었다. 그리고, KSUG 커뮤니티 활동이나 오픈소스 소프트웨어에 대한 경험이 개발자들의 정서나 협업(Collaboration)이 주는 시너지(Synergy)가 어떤 것인지 감각적으로 알고 있었다.

이를 쏟아 부어 우리의 변화를 만들었다. 그러면서 나는 점차 '아키텍트'라는 타이틀과는 거리가 먼 사람이 되어 가고 있었다.

우리의 도전이 한창이던 지난 1월 합류한  또 다른 아키텍트 역량을 가진 분은 직접 개발하는 과정에서 한편으로는 제품(코딩)으로 한편으로는 함께 일하는 동료들의 살아있는 교재 역할을 했다. 그 후엔 체력이 다하는 순간까지(?) 코드 리뷰를 하고 있다.

아키텍트 따위는 잊자

결국, 위키피디아의 정의가 진부하다는 것이 내 결론이다. 그런데, 왜 진부한채로 그대로 놓여지고 있을까? 간단하다. 누구도 그 정의따위는 관심없다는 것이고, 아키텍트가 행동하는 모습이 매우 다양하고, 이제는 그렇게 불리지도 않는다는 점이다.

하지만, 아키텍처를 이해하는 소프트웨어 전문가는 반드시 필요하다. 그럼, 과거에 말하던 아키텍트와 내가 주장하는 아키텍처를 이해하는 전문가는 어떤 차이가 있을까? 아래는 앞서 언급했던 내 일상에서 찾은 두 개의 표본을 관찰해서 뽑아낸 특성만 밝혀본다.

소프트웨어 전문가가 경영자향으로 활동할 경우[2]

소프트웨어 전문가가 기술 응집력 강화로 활동할 경우[3]

  • 오픈소스 개발문화와 같은 선진 소프트웨어 개발문화를 배양한다
    • Git 혹은 Github 중심의 개발자 협업 방식
    • 더 나은 코드(Better code) 작성을 위한 노력이 개발자의 일상이 되게 하기
    • Slack, Dooray 등을 이용하여 경영자/관리자와 개발자가 개발 내용물로 대화하는 분위기 만들기
  • 안정적 서비스를 위한 기반 환경 구축
    • 접근 로그, 오류 로그를 효과적으로 수집하고, 통합적으로 추적하는 기반 만들기
    • (각 서비스별로 다른 기술을 쓰더라도) 상호 호환성이 필요한 부분은 표준화하기
  • 쉽게 데이터를 다룰 수 있는 환경 구축
    • Data Federation 시스템 구축으로 보고 싶은 데이터는 수분내에 어떻게든 볼 수 있게 하기
    • 빅데이터 관리(입수/보관) 효율성을 위한 지속적 개선

주석

[1] 최근 Implications of Tech Stack Complexity for Executives란 기사를 번역하고 있는데 같은 취지의 이야기를 잘 설명하고 있다. 다음 주 중에 팝잇에 번역한 글을 발행할 계획이다.

[2] 부끄럽지만, 독자의 이해 증진과 소통의 기회를 잡기 위해 실제 대상이 나란 사실을 공개한다. ^^

[3] 위와 같은 이유로 Micro Service, Docker로 할 수 밖에 없었던 사연을 시작으로 우리 경험을 시리즈로 공유하고 있는 김형준님이 실제 대상이다.

[4] thumbnail image 출처: http://nomorenancy.blogspot.kr/2006/10/nancy-johnson-master-architect.html

Popit은 페이스북 댓글만 사용하고 있습니다. 페이스북 로그인 후 글을 보시면 댓글이 나타납니다.