진짜 아키텍트가 없는 EA 시장 잠재력을 알리는 글 (2)

앞서 올린 글, 진짜 아키텍트가 없는 EA 시장 잠재력을 알리는 글이 (popit 운영자가) 상당한 조회수를 올렸다고 한다. 원래는 작년 6월 개인 블로그에 썼던 글을 다시 쓰기 한 것이다. 그러나, 목표는 조회수가 아니라 소통을 끌어내려 했는데 성공했다. (중국에선 읽기 어려운) 페이스북 댓글이 달렸음을 운영자를 통해 들었다. 반가운 마음에 어렵게 댓글을 읽을 수 있었다. 이 소중한 피드백을 불씨로 삼아 희망을 만들고자 토론문으로 바꾸는 글쓰기를 한다. 역시 목표는 소통이다.

소통은 언제나 환영하니 메일 주세요

시대정신을 읽으라

어떤 분이 이렇게 물었다. 앞서 언급한 대한민국의 그러한 현실을 고려했을 때, 어떤 조건을 갖추면 아키텍트라고 인정받을 수 있냐? 먼저 댓글로 답한 내용을 다시 쓴다. 소프트웨어 아키텍트 중에서 글의 초점인 엔터프라이즈 아키텍트로 범위를 좁히면, 대략 다음 같은 질문에 실천 가능한 답을 줄 수 있어야 한다.

• 빅뱅(혹은 차세대) 없이 레거시 시스템을 현대화(modernization) 할 방법
• 해당 기업이 놓인 현 비즈니스 상황에서 SW기반으로 새로운 기회를 찾을 방안
• 외주에 의존하는 시스템 운영을 자체 개발로 바꿔갈 현실적인 방안

그가 어떤 답을 했건 문제가 하나 더 있긴 하다. 이런 답을 듣고 적절하다 아니다 판단할 수 있는 사람 또한 드물다는 점이다. 그렇다면, 진짜 아키텍트가 없는 EA 시장 잠재력을 알리는 글이 던지는 메시지는 무엇인가? 운좋은 소수에 필자가 끼었다고 자랑하는 것인가? 아니면 냉소나 자조적인 글인가? 전혀 그렇지 않다. 결론부터 말하면 EA 시장 잠재력은 말하고자 함이다. 지금까지 프로그래밍 실력을 쌓은 분들이 아키텍처와 협업 문화에 조금만 식견을 가지면 앞으로 다가올 거대한 기업용 서비스 시장에서 긴 생명력을 유지할 수 있다고 확신하기 때문이다. 이젠 SAP, Oracle, MS, IBM 솔루션을 고쳐가며(tailoring) 기업용 시스템을 만들어 운영하던 시절은 끝나간다. 오픈소스나 클라우드 인프라 기반으로 기업의 핵심 비즈니스에 IT 기술을 버무려 서비스를 내놓는 연금술의 시대가 이미 도래했다.

스타트업에서 새로운 도전을 하는 것도 좋고, 이미 기틀이 잡힌 서비스 회사에서 자기 역할을 하는 분들이라면 굳이 이 글에 관심을 갖을 필요는 없다. 혹시 실력에 맞는 기회를 찾지 못해 새로운 시장에 도전하고 싶은 분은 메일을 주시라. 개별 소통으로 길을 찾는데 도움을 줄 수 있다.

1세대 이야기

경력이 길지 않는 후배들을 위해 옛날 얘기를 좀 하자. 내가 업계에 뛰어든 2000년초 엔터프라이즈 시장은 거의 불모지였다. 외산 솔루션이 (제국주의 침략처럼) 우리 전산실에 침투했다. 컴퓨터에 내장된 형태로 번들로 침투했다. 선진국과 꽤나 격차가 있던 전산직 선배들에겐 6/25 이후 미군 주둔처럼 자연스러운 일이었을지 모른다. (마치 신탁통치처럼 유닉스 세상과 윈도 세상으로...) 내가 직접 경험한 부분은 99년부터다. 당시 엔터프라이즈 프로그래밍이란 말이 유행이었다. Enterprise JB 때문이었는지 어쩐지 모르지만 아무튼 엔터프라이즈라는 말은 미국 기술업체(Vendor)들 구호일 뿐, 당시 대한민국 대다수 기업은 '전산실'이란 이름을 지우려고 노력할 때였다. 거의 대부분의 프로그래밍은 하나의 DBMS를 사용하고 화면과 테이블을 매핑하는 C/S(Client Server) 프로그래밍이 대세를 이루던 때였다.

C/S 는 90년대를 지배했지만, 90년대말 닷컴버블과 함께 웹 프로그래밍이 갑자기 당도했다. 준비되지 않은 우리 전산실 선배들에겐 이를 대처할 시간이 부족했다. IMF 극복과 맞물려 HTML이나 포토샵만 배운 학원 출신 개발자들이 바로 현장에 나왔다. 당시 증권사에서 유명한 ASP 책에 나오는 토이 예제 쿼리를 실무에 그대로 쓰면서 잘 안돌아간다고 자문을 구하던 동료(?)들을 흔히 볼 수 있었다. 그들은 결과가 화면에 보이는 것에만 익숙했지, 그들이 작성한 SQL이 어떠한 과정을 거쳐 수행되는지 알 수가 없어서 자기 노트북에서 잘 되던 것이 왜 서버에만 올리면 안되는지 이해할 수 없었다. 필자의 운은 여기서 시작했다. VB(Visual Basic)으로 현장 개발을 시작했는데, 선배 개발자들은 웹 프로그래밍을 모르던 터라 초보 ASP 프로그래머들이 친 사고를 해결하는 기회가 초보 개발자인 나에게 주어졌다. 혼자 두꺼운 책을 찾아가며 외로운 씨름을 하는 가운데 컴포넌트를 만드는 기술과 SQL 인덱스의 존재, 그리고 심오한 SQL 문법의 세계에 빠져들었다.

비슷한 시기에 이렇게 씨름을 하는 신진세력(?)들을 당시 유행하던 개발자 커뮤니티나 컨퍼런스를 통해 만나고 교류할 수 있었다. 그 중 어떤 분은 이들을 '1세대'라고 부른다. '1세대' 상당수는 당시 도전적인 업종이었던 SI업체에서 많은 프로젝트를 수행하며 무공을 키웠다. 그러나, SI업계가 기술 중심에서 사업관리 중심으로 변모하면서  대부분은 인터넷 서비스업체로 이직했다. 그렇지 않은 이들은 솔루션 개발 업체로 옮겨갔다. 필자는 다른 길을 갔는데, 교과서에 나오는대로 해보고 싶어 (자유도가 높은) 작은 컨설팅 회사에 들어갔다. 많은 비율은 아닐지모르지만 묵묵히 자기 길을 걸으며 내공을 쌓아온 선수들이 '꿈꾸는 사람'들을 돕기 위해 기다리고 있다.

한강의 기적을 해낸 대한민국은 엄청나게 빠른 속도로 진화한다. 멀리 갈 것도 없이 얼마전 왕국에서 민주공화정으로 대반전을 이룬 모습이 있지 않는가? 20년 넘게 외산 솔루션에 당하며 배운 노하우가 사회에 체득되어 있다. 그들은 이미 다양한 채널(개발자 커뮤니티와 컨퍼런스, 유투브 채널 운영, 블로그 등등)로 이미 후배들에게 자신들이 배운 유산을 전하고 있다. 필자 역시 그 중 1인이며, 설계나 아키텍처 관련한 노하우를 동료들(혹은 후배들)에게 넘겨주기 위해 글을 쓴다.

소프트웨어 아키텍트

한 시절 보낸 10년 경험과 비즈니스를 읽는 눈이 있다면 EA를 표방하시면 대한민국은 무주공산이다. 하지만, 관심사가 좋은 소프트웨어 혹은 오래 지속하는 서비스를 꿈꾸신다면, 그건 조금 다른 길이다. EA와는 조금은 다르게 분류할 수 있는 소프트웨어 아키텍트가 되어야 하는데, 세상에 나온 사례는 다음 몇 가지 예시로 구분할 수 있다.

• N사 등의 성숙한 개발조직에서 배워서 한 팀을 책임지는 모델
• 오픈소스 커미터
• (사업까지는 아니라도) 내 서비스를 주인의식을 갖고 꾸준히 운영하는 개발자

마지막으로, 한국에선 '아키텍터'란 말을 쓰는 분들이 있다. 한글로 된 자료 중에 아키텍터란 야매(?) 용어를 쓰는 글을 절대 읽지 마시라고 말씀드리고 싶다. 기레기 글과 유사할 가능성이 높기 때문이다.