모던 아키텍트에 대해 개념 잡아보기

책을 읽다가 전에 써둔 글이 떠올라 찜찜했다. 이글을 쓰는 현재 시각 무려 328개의 페이스북 좋아요를 기록하고 있는 아키텍트는 필요없다, 아키텍처를 이해하는 전문가가 필요할 뿐[1]에 대한 것이다.

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

현재 시각 페이스북 좋아요 갯수가 328개

서울대 공대 교수들이 지적하는 아키텍트 부재

연말부터 축적의 시간이란 책을 다시 펼쳤다. 현재까지 반 정도[2]밖에 읽지 않았지만, 아키텍트 부재를 대한민국의 약점으로 지적하는 표현이 나온다.

저는 스티브 잡스가 아키텍트였고 좋은 아키텍트들을 곁에 많이 두고 있었다고 봅니다. 바로 이 아키텍처를 가진 혁신가의 생각이 노키아와 애플의 성쇠를 가른 것이죠. - 박영준 교수(서울공대 전기정보공학부/나노,바이오 응용)

물론, 여기서 말하는 아키텍트가 소프트웨어 개발자사이에서 말하는 소프트웨어 아키텍트와는 상당한 차이가 있다. 하지만, 이 책의 다른 교수님들이 다른 공학 분야에서 공통으로 발생하는 대한민국의 약점으로 개념 설계 역량 부족을 지적하는데, 나는 이 부분이 소프트웨어 아키텍트의 역량과 맞닿아 있다고 생각했다.

산업 분야와 상관없이 우리 산업이 처한 공통적인 문제를 가려 뽑고자 할 때 가장 많이 제기된 키워드는 '개념설계conceptual design' 역량의 부재였다. 개념설계 역량은 제품개발이 되었건, 비즈니스 모델이 되었건 산업계가 풀어야 할 과제가 있을 때, 이 문제의 속성 자체를 새롭게 정의하고, 창의적으로 해법의 방향을 제시하는 역량으로서 ... - 이정동 교수(서울공대 산업공학과/기술경영,정책)

그렇다. 글을 쓰며 다시 추적해보니 여기서 찜찜함이 발생했다. 아키텍트는 필요없다고 주장할 때, 지칭한 아키텍트는 SI(System Integration) 회사위주의 외주 개발문화로 한 시대를 풍미한 과거식의 소프트웨어 아키텍트의 역할을 말한다. 반면에 개념 설계를 통해 비즈니스와 도메인(혹은 조직)과 기술을 엮는 역할을 해야 하는 일은 너무나도 중요하다. 공대 교수님들이 대한민국 미래를 위해 지적한 개념 설계와 기술축적의 첨병은 소프트웨어 개발에서도 당연히 필요하고, 그런 이들을 과거의 아키텍트와 구분하기 위해 아키텍처를 이해하는 전문가로 임시 작명을 했던 것이다.

아키텍트는 죽었다.

그러던 차에 나와 비슷한 주장을 하는 다른 지구인의 글을 만났다. 이름하여 아키텍트의 죽음(The Death of the Architect)이다. 신은 죽었다는 니체의 말을 패러디했다는데 우리 개발자들에게 이 정도 교양은 무리다.[3] 그의 주장은 내가 썼던 글과 대체로 비슷한데 고유한 내용만 여기에 일부 소개한다. 크게 두 가지이다.

첫째로 아키텍트란 역할은 애자일 개발에서 더욱 모호해져서 아래와 같은 역할이 이를 대체하고, 개발자에 대한 통제 대신 자유도가 늘었다는 주장이다.

  • Product Manager
  • Scrum Master
  • Business Analyst
  • Software Development Manager

그리고, 둘째로는 EA 프레임워크 혹은 ITA에서 정의하는 아키텍트 역할 분류 즉, software architect, enterprise architect, solution architect, domain architect 등으로 나누는 일에 대해 모호하다고 지적한다.

저자와 이해를 같이 하지만, 일해온 환경이 다른 내 입장에서 다시 한번 아키텍트는 필요없다, 아키텍처를 이해하는 전문가가 필요할 뿐에서 주장한 바를 요약하면 아래와 같다.

주로 개발표준이라고 프레임워크나 기반 솔루션을 정하던 시대는 끝났다는 주장이다. 작명 원칙이라고 의미를 모호하게 만드는 약어같은 규칙을 강제하거나 XML 등의 형식으로 획일화를 강조하던 시행착오를 당장 그만두자는 의미에서 강한 어조로 제목을 붙였다. (설마 하니 아직도 약어 조합의 클래스나 변수명을 강제하는 사람이 있다면, 빨리 멈추자.)

Yogeshwar Srikrishnan[4]의 문학적 표현을 빌리면, 바야흐로 한 명의 전지전능한 아키텍트가 개발자를 통제하던 시대는 갔다. 이제 개발자에게 자유를 허하라.

개발자 역할의 변화

과거 서울에 있을 때 구독하던 블로그 글을 간만에 지인 추천으로 봤다. 외국 자료를 인용하며 대한민국 IT 흐름을 짚어주었다. 그리고, 다음과 같이 비교한다.

서비스 플랫폼의 발전 과정

서비스 플랫폼의 발전 과정

과거와 현재 개발자 역할 비교

전통산업군에서의 IT 인터넷 서비스에서의 IT 

  • 과거의 SW 공학은 어떻게 하면 10년 이상 안정되게 돌아가게 할 것인가(Tolerant), 어떻게 하면 한 번 만들어서 여기도 쓰고 저기도 쓰게 할 것인가(Flexibility)에 집중
  • 이 분야의 중점사항이 ‘안정된 Process Function’ 들을 만들어 내는 데 있다는 것이다. ‘Data’는 거래 Transaction의 근거로서 존재할 뿐이다. 즉 Data를 보존할 뿐 이용하지는 않는다.

    • IT 시스템의 핵심이 원가절감이 아니다. 고객들에게 돈을 받을 수 있는가 하는 상품성이 핵심이다. 그래서 IT의 역할이 ‘돈으로 치환될 수 있는 부가 가치를 제공하고 있는가?’ 하는 효과성을 충족
    • 훈련된 사람이 만들어 내는 협업 과정이 문화가 인터넷 서비스의 생산 공정인 것이다.
    • 개발자의 문제는 개발자들이 해결의 주체이어야 한다. 그리고 개발자의 문제란 상품을 잘 만드는 데 필요한 외연의 것들도 함께 포함

결론

서양에서는 익숙하나 우리 개발자들에게 생소한 표현이 바로 Product이다. 소프트웨어 프로그램 혹은 웹/모바일 서비스를 제품Product라고 부른다. 그리고, 직무를 부르는 말 중에 제품 주인Product Owner이나 제품 관리자Product Manager와 같은 말이 있다.

우리는 현재의 시장/산업에 적응해서 앞으로도 10년 이상 직업생활을 누리려면 이제라도 빨리 눈치채야 한다. 이미 개발자들은 과거 제조업의 생산자 역할을 하고 있다. 흥미로운 사실은 정해진대로 일하는 생산직 노동자가 아니라 주체로 판단하여 전통적인 제품과 서비스를 바꾸는 역할을 해야 한다. 그런 말도 이미 있다. Digital Transformation 이란 말을 구글링해보라. 그리고, 오늘부터 조금씩 변화하는 세상의 1인으로 살아보자.

http://www.mobiinside.com/kr/2017/08/24/engineer-role-subokim/

주석

[1] 글을 막 올리던 시점에도 혹시 '아키텍트'라는 직함을 가진 분들에게 의도치 않은 불쾌감을 줄까 우려가 있었다. 하지만, 아직도 '아키텍트'라는 역할로 개발자들을 통제만 하고 도움을 주지 않는 분들이 있으면 안된다는 생각에 제목을 저렇게 붙였다.

[2] 278쪽까지 읽은 상황에서 글을 쓴다.

[3] 필자가 읽지 않았다는 말이기도 하다.

[4] 앞서 소개한 글 아키텍트의 죽음(The Death of the Architect) 저자

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