지난 '데이터 분석 플랫폼에 대한 고민'이란 글에서 사용자들이 쉽게 빅데이터를 가지고 분석하고 결과를 해석해서 서비스화를 seamless하게 지원하는 시스템/플랫폼에 대한 고민/생각을 적었습니다. 그런데 지난 밤 (1월 8일)에 잠들기 전에 막상 이 작업을 저의 올해 중점과제로 삼아서 진행해볼까라고 생각하니 좀 막막해집니다. 평소에 제 스타일을 생각해보면 수박의 겉핥기와 차려진 수박먹기는 잘하지만, 정작 수박을 먹기 좋게 다듬어서 내놓는 그런 스타일은 아닙니다. 즉, 관념적으로 개념을 생각해서 대강의 모습을 그리는 작업이나 이미 범용으로 만들어진 서비스를 이용해서 다른 가치를 창출하는 것에는 어느 정도 능하지만, 개념을 구체화하고 그걸 서비스로 구현해내는 능력은 많이 부족합니다. 그런데, 글로 적었던 분석플랫폼이 제대로 작동하기 위해서는 상세 시스템을 설계하고 그것을 구현해는 능력이 필요합니다. 구현 능력은 주변에 잉여력들이 많은데, 시스템 설계 능력을 갖춘 인재를 주변에서 찾는 것이 어렵습니다. (어쩌면 이제껏 이런 고민이 없었기 때문에 그런 능력을 갖춘 사람을 눈여겨보지 않았습니다.)
정형화된 시스템/서비스를 만들기 위해서는 사용자들의 니즈와 트렌드를 읽어서 관념적인 시스템 설계가 우선이고, 다음으로는 관념적인 도면을 더 상세한 컴포넌트로 나누고 각각의 컴포넌트의 상세 설계를 하고, 그리고 각각을 구현하고 전체를 통합하고, 그런 후에 사용자들에게 가치를 전달하는 과정이 필요합니다. 이상의 각 단계에 특출난 재능을 가진 인재들이 있습니다. 각각을 관념형, 설계형, 구현형, 실무형으로 부르면 될 듯합니다. 그림을 그리는 과정을 생각해보면 관념형은 무엇을 어떤 구도로 그릴 것인가?를 정하는 것이고, 설계형은 구체적인 스케치를 하는 것이고, 구현형은 스케치된 바탕 위에 채색을 해서 그림을 완성하는 것이고, 실무형은 완성된 그림을 큐레이션해서 전시해주는 것으로 생각해도 될 듯합니다. 건축에서도 건축 컨셉을 잡고, 설계를 하고, 시공을 하고, 또 그 속에서 살아가는 과정이 이와 비슷합니다. 그림을 스케치하고 건물을 설계하는 사람, 즉 설계형 인재를 Architect라고 부르려 합니다.
Architect의 능력은 어디서 오는 걸까요? 타고난 재능일까요 아니면 교육을 통해서 배우는 걸까요 그것도 아니면 실무 경험을 통해서 획득하는 걸까요? 기본적으로 예술가적 재능이라거나 관념을 형상화하고 구조화하는 것은 타고나는 것같습니다. 이런 자질이나 성향이 없는 사람에게 무조건 '설계능력이 중요해' '앞으로 유망한 직종이 될거야'라고 꼬셔서 교육을 시킨다고 한들교육을 통해서 얻는 지식과 발전가능성에는 한계가 있습니다. 그러나 그런 성향/흥미가 있는 사람들은 소프트웨어 엔지니어링 분야를 좀 더 체계적으로 교육해서 양성할 필요가 있습니다. 그렇게 교육을 받은 후에 실무 경험을 쌓는다면 좋은 소프트웨어 엔지니어 또는 IT/서비스 아키텍트로 성장할 수 있습니다.
아키텍트에게 필요한 능력은 뭘까요? 시스템의 관념적 설계 능력은 굳이 필요없을 듯합니다. 있으면 좋지만 필수능력은 아닙니다. 그러나 관념적인 생각을 듣고 상세 모습을 상상할 수 있고, 그림/다이아그램 또는 슈도 코드 등의 형태로 그것들을 현실화시킬 수 있어야 합니다. 여기까지 글을 적다가 나도 잘 모르는 소프트웨어 엔지니어링에 대해서 왈가왈부하는 것이 부끄러워서 검색찬스를 사용했습니다. 아래에는 한성대의 이민성 교수님의 재미있는 '한국에서 소프트웨어 엔지니어로 성공하는 법'이라는 동영상이 있습니다. 제가 생각하는 모든 것이 녹아있지는 않지만 많은 것을 얘기해주고 있습니다. 그러나 제가 말하고 싶은 아키텍트는 코딩개발자는 아닙니다.
소프트웨어 엔지니어와 관련된 글을 하나더 소개합니다. 제가 이 글에서 적는 아키텍트의 역량과는 조금 차이가 납니다. 감안하고 읽으보세요. '미국에서 소프트웨어 엔지니어로 산다는 것'. '소프트웨어 아키텍트가 알아야할 97가지' 라는 책도 있네요. 이 책은 한 번 읽어봐야겠습니다. 좋은 아키텍트가 되기 위해서는 참 다양한 능력과 자질이 필요합니다.
관념을 상세로 설계하는 능력과 함께 상세를 관념으로 역변환시키는 능력도 필요합니다. 집의 설계도를 보고 나서 왜 이런 설계도가 나왔는지에 대한 이유를 유추해낼 수 없다면 설계도와 한치의 오차도 없는 집은 지을 수 있어도 원래 구현하고자 했던 철학은 담을 수 없습니다. 완벽하지는 못하더라도 그런 역관념화의 과정을 거쳐야지 애초에 의도했던 바를 (형태는 바뀌더라도) 구현할 수가 있습니다. 그리고 실제 제품 (시스템이나 코드)를 분석하는 리버스 엔지니어링 reverse engineering 능력도 필요합니다. 그런 의미에서 복기능력도 필요합니다. 다른 사람이 만든 서비스에 대한 이해 없이 나만의 독창성을 실현하는 것은 불가능합니다. 그렇지만 타인 (특히, 롤모델)의 설계에 너무 의존적이 되는 것도 경계해야 합니다. 그 외에도 좋은 아키텍트가 되기 위해서 필요한 자질과 능력은 많습니다. 제가 당장 아키텍트가 되지는 않더라도 그런 능력을 가진 인재를 찾기 위해서 어떤 자질과 능력이 필요한지 공부해봐야겠습니다. 위의 책을 읽어보고 인사이트가 있으면 나중에라도 다시 공유하겠습니다.
주변에서 아키텍트의 역량을 지닌 동료를 찾기 힘든 이유는 아마도 대한민국에서는 개발자들이 (소프트웨어) 엔지니어가 아니라 (프로그램) 코더로 성장하기 때문이 아닌가라는 생각을 합니다. 소위 말하는 Geek스러움이 철저한 계획과 설계에 따른 실행이 아니라, 어떤 문제를 만나도 그 자리에서 뚝딱 해결해버리는 그런 괴짜스러움으로 받아들여지는 듯합니다. 인터넷에 떠도는 이과와 문과의 비교라든가, 공대생 이야기는 모두 그런 이상한 미신에 기반을 두고 있습니다.
...
일단 제가 구상하는 것을 실행하기 위해서 함께할 동료들을 많이 모아야겠습니다. 그동안 몇몇은 눈여겨보고 있었지만, 실행에 앞서서 부족한 부분을 채워줄 그런 동료들이 필요합니다. 이제껏 별로 생각을 못했는데, 아키텍트에 적합한 이가 누구인지 언뜻 떠오르지 않습니다. 생각나는 사람은 있지만 그가 이 일에 적합한 사람인가?에 대해서는 확신이 없습니다. 더 열린 마음과 열린 눈으로 주변의 동료들의 숨은 재능을 찾아보고 규합해봐야겠습니다.
