느린 걸음으로 살아가기

어제 모 은행 프로젝트에 참여인력 인적사항을 제출해야 한다는 요청을 받고 오랜만에 경력사항을 다시 적어봤다. 어느새 10년도 넘고 12년 가까이 IT 바닥에서 밥을 먹고 있다는 것을 깨달았다. 뭐 그만큼 은퇴가 가까운 것인지도...

모 은행 관계자 분이 거대한 꿈 - 모비딕이라고 잡으려는 건지 - 을 꾸었는지 금번 컨설팅 단계에서 은행 인터넷 뱅킹 전반에 사용할 프레임워크를 구축하고자 한단다. 그냥 프레임워크 하나 만드는 거면 별일도 아니지만 스트럿츠, 스프링, iBatis 에다가 은행 전산실에서 기존에 사용하던 다양한 컴포넌트들 까지 아우르는 방대한 아키텍쳐를 설계해 달라는 것이다. 그런데 이게 전체 컨설팅 업무에서 한 줄기에 해당한다고 해서 투입 인력은 고작 한명내지 두명. 프레임워크를 설계해 주기만 한다면 그나마 낫지 온갖 시스템 개발 프로세스에 대한 표준을 정의하고 문서화 하는데다 교육하고 프로토타입 구현해야 한단다. 원래 이 정도 규모라면 컨설턴트 4~5명은 투입되어야 하거늘...

물론 아키텍쳐 설계 경험이 아예 없는 건 아니지만 솔직히 스트럿츠나 스프링은 건드려 보지도 않았다. 왜냐하면 10년 동안 자바를 해왔지만 내내 직접 프레임워크를 설계해서 써왔기 때문이다. 고객은 하늘이고 스펙은 이미 정해진 것, 그리고 내가 맡기로 한 일이니 부랴부랴 책을 사서 스트럿츠랑 스프링을 공부하는 중이다. 불행 중 다행인지 아니면 쌓은 내공 덕인지 프레임워크 책을 읽는데 별 어려움도 없고, 이해하는데 큰 무리도 없었다.

그러나 과연 이번 프로젝트가 성공할 것인가? 회사로서도 크나큰 도전이다. 다양한 비즈니스를 해왔지만 은행권 프로젝트라는 것은 성공과 실패의 파급효과가 어마어마한 것이다. 왜 꼭 IT 현장을 떠나려고 하면 기회가 찾아오는 걸까? 떠나야 겠다는 생각을 늘 하고 산다. 오래도록 개발을 해오고 온갖 프로젝트를 해왔지만 즐거운 나날보다는 힘든 날들이 많았다.

10년 내내 온갖 미디어와 에반젤리스트들을 통해 들어온 생산성 향상의 꿈은 그들의 공허한 약속이거나 부도난 수표라고 여겨왔다. 처음 객체지향 기술이 나올 무렵 당시 신기술을 알리기 위해 책을 써내고 전세계를 향해 홍보하던 고수들과 학자들은 객체지향 기술로 인해 소프트웨어 분야가 드디어 가내수공업 단계에서 공장자동화 단계로 넘어가리라고 확언했다. 또 하드웨어 산업처럼 엄청난 부가가치와 빠른 발전으로 인류의 생활을 한단계 업그레이드 해줄 것이라 믿었다. 하지만 2000년이 지나도 그런 일은 벌어지지 않고 있고, 여전히 소프트웨어는 고달프고 배고픈 산업일 뿐이다. 물론 극소수의 소프트웨어 엔지니어들이 세계적인 갑부가 되고, 선망의 대상이 되고 있지만 극단적인 양극화 현상은 나아지지 않고 있다.

지겹다, 한계를 느낀다라고 해야할까? 도저히 생산성이 늘어나지 않는 이유가 무얼까? 반복적인 코드를 생산하는 과정을 벗어날 방법은 없나? 프로그램을 자동으로 생성해주는 그런 프로그램을 만들 수는 없을까? 프로그램의 실행과정을 자동으로 모니터링하는 방법은 없을까? 이런 상상을 하지만 실제로 그런 기술을 만들 능력이 없는지 시도도 해봤지만 쉽지 않은 일이었다.

하지만, 은행 프로젝트를 준비하면서 AOP 기술을 접하게 되었다. 그리고, 최근에 제니퍼와 같은 실시간 모니터링 툴들을 써보고 내부 아키텍쳐들을 분석하면서 세상에 나와 같은 고민을 하는 사람들이 많다는 것을 다시 한번 확인하게 되고 또한 꿈꾸던 기술들이 현실로 나타나는 것을 보게 된다. 아직은 완벽하지 않지만 적어도 내가 10년을 더 버틴다면 지난 10년 간 기다려오던 기술들이 일상화되고, 소프트웨어 분야가 하드웨어 분야처럼 높은 생산성을 지니게 되는 것을 보게 될 거라는 기대감을 느낀다.

언제나 신기술에 대한 예측들은 빗나가고 사람들이 기대한 시점에서는 여전히 불만족스럽기 마련이다. 아직 로봇은 겨우 걸음마를 하고 있고 자동차는 하늘을 날지 못한다. 하지만, 사람들이 영화에서 보던 기술들 중에 일부는 하나씩 현실화 되고 있다. 느리지만 기술은 결코 퇴보하지 않는다 사람들의 기대보다 아주 천천히 자라갈 뿐이고 사람들의 열망에 상관없이 제 갈길을 가고 있는 것이다.

인내는 쓰다. 하지만 그 열매는 달다. 승자가 살아남는 것일 수도 있지만 달리보면 살아남은 자가 승자가 될 수도 있는 법이다.

최근 몇 년 사이에 소프트웨어 개발 분야에서 유행하게된 널리 단어로 '아키텍쳐'가 있다. 새롭게 만들어진 단어도 아니고 아주 오래전부터 영어사전에 등재되어 있던 것이고, 하드웨어 분야에서는 아주 오래 전부터 상식으로 쓰여진 단어인데 유달리 소프트웨어 분야에서는 최근 들어 더욱 더 관심이 높아진 듯 하다. 그건 아마도 소프트웨어의 규모가 급격히 늘어가고 있기 때문에 단순히 소프트웨어를 '개발한다'라거나 '코딩한다', '구현한다'는 단어만으로는 거대한 비지니스 프로젝트를 설명하거나 혹은 표현하기 어려워졌기 때문일 것이다. 아니면, 고급 개발자들이나 컨설턴트들이 자신의 몸값을 높이기 위해, 자신의 일을 과장하기 위해 쓰는 것일지도 모른다. 비슷하게 각광받는 단어로는 '프레임워크'라는게 있다. 문제는 아키텍쳐라거나 프레임워크라는 단어의 의미를 설명해보라고 하면 거의 모든 실무자들이 얼버무리기 시작한다. 그냥 다들 알고 있는게 아닌가, 굳이 설명해야 하는가 묻는 표정으로 멀뚱멀뚱 바라보기 일쑤다. 자신이 쓰는 용어를 제대로 이해하고 설명할 수 없다면, 대체 그 일을 어떻게 제대로 수행할 수 있을까? 의심스럽지 않은가? 목표도 모르고 전진하기만 한다면 대체 그 목표에 어떻게 닿을 수 있을까?

그나마 어렴풋이 아키텍쳐라는 단어에 대해 설명을 시도하라고 하면 거대한 프로젝트를 수행하기 위한 소프트웨어 혹은 프로젝트의 구조라거나, 각종 컴포넌트(구성 요소)들을 쌓아올리는 과정과 각 요소간의 관계를 설명한 것이라고 할 수 있다. 스스로 이런 설명을 하면서도 의문점을 가지지 않을 수 없다. 왜 거대한 프로젝트라는 제약이 필요한가? 작은 함수나 프로그램을 만들 때는 아키텍쳐가 필요 없는가? 혹은 거대한 구조를 설명하기 위해 아주 큰 부품간의 관계만을 설명하면 되는가? 다수의 프로젝트를 수행하면서 느낀 점은 대규모 프로젝트를 수행하는데 있어서 거시적인 설계를 아무리 잘 하더라도 미세한 설계를 등한히 한다면 기필코 프로젝트가 실패하게 되더라는 점이다. 이것은 굉장힌 중요한 문제이다. 예를 들어 거대한 유조선을 설계한다고 하면 분명히 청사진을 그리고 뼈대를 튼튼히 만들고, 강력한 엔진과 좋은 철강을 쓰는 것이 중요한 일일 것이다. 하지만, 건조 중에 사소한 실수로 배밑을 용접하다가 작은 구멍이라도 생긴다면 어찌될 것인가? 거대한 배가 겨우 작은 구멍 때문에 대해에서 침몰할 수도 있게 되는 것이다.

최근의 프로젝트 경향이라거나, 소프트웨어 분야의 기술 동향을 살펴보면 지나치게 거시적인 면을 중시하고 미세한 부분 혹은 아주 기초적인 부분들이 외면되고 있다는 것을 발견하게 된다. 물론 이러한 문제들을 해결하기 위한 답으로 완성된 시스템을 면밀하게 검사해주는 다양한 도구(제니퍼와 같은 모니터링 툴, 이클립스나 IntelliJ에 포함된 소스 점검 기능, JUnit 등의 테스트 툴)들이 나오고 있지만, 옛 경구대로 이런 것들은 사후약방문일 뿐이다. 이미 개발이 완료된 시스템에 수많은 결점들이 내포되어 있을 경우 그것을 해결하기 위해 드는 시간과 노력은 개발 당시보다 몇 배로 증가할 뿐더러, 만일 운영 중인 시스템이 중단된다면 그 기회 비용 상실과 피해 복구 비용을 따지는 것은 무의미할 정도가 되어 버린다.

어디서나 하는 말이지만, 결국 기초가 부족하면 안된다는 말을 되풀이 하게 된다. 아무리 좋은 프레임워크를 도입하고 아무리 생산성 좋은 개발환경을 구축한들 개발자 개개인의 자질이 부족하면 좋은 소프트웨어를 만들 수 없게 된다. 도요타 자동차가 세계적인 자동차 메이커가 된것은 그들의 훌륭한 경영진 뿐 아니라 컨베이어벨트 옆에서 매순간 자동차를 조립하는 조립자들의 장인 정신이 결합되었기에 가능한 일이다. 물론 열악한 환경에서 일하기에, 개발 기간이 촉박하기에 어쩔수 없다는 변명을 늘어놓을 수도 있다. 그렇게 남의 탓이라는 나름의 이유을 늘어 놓는다고 해서 자신의 처지가 나아지는 것이 아니다. 더구나 남이 나서서 내 운명을 바꾸어주지 않는다. 환경이 바뀌기 기다리는 것은 로또가 당첨되기를 바라는 것과 다르지 않다.

점점 거대화 되어 가는 소프트웨어들을 제대로 만들기 위해서 다양한 해법들이 제시되고 있고, 다양한 프레임워크들이 나오며 개발자들은 프레임워크를 받아들이지 못해 헤메고 있는 것이 현실이다. 프레임워크들이 생산성을 높여줄 것이라는 환상도 많이 작용하고 있어 프레임워크가 silver bullet이나 만병통치약 쯤으로 이해된 적도 있지만 세상에 어떤 솔루션이나 개발 언어도 개발 생산성을 갑자기 높여주지는 않는다. 아무리 좋은 프레임워크도 그것을 습득하고 제대로 다루지 못하면 프랑켄슈타인과 다를 바 없고, 제대로 다룰 줄 아는 엔지니어들이 있다고 한들 문제는 모든 엔지니어가 동등하게 고급 기술을 습득할수도 없다는 것이다.

그렇다면 당장 눈앞의 프로젝트들과 앞으로 개발해야 하는 무수한 난제들을 어떻게 해결해야할 것인가? 프레임워크를 버릴 필요는 없다. 다양한 도구를 가지는 것은 다양한 해법을 가지는 것과 같다. 프레임워크도 개발 툴도, 각종 라이브러리들도 모두 다 필요한 도구들이다. 전쟁을 이기기 위해서는 다양한 병법을 필요로 한다. 군대 구성도 공군, 육군, 해군에다가 특수부대도 필요하다. 개발에서도 마찬가지다. 그런데, 전쟁을 마치기 위해서는 결국 육군이 점령지를 밟아야 한다는 말처럼 개발에서도 절대적으로 필요한 것이 있다. 결국 개발자가 프로그램을 짜야 한다는 것이다. 아무리 좋은 툴, 서버, 프레임워크와 훌륭항 아이디어를 가지고 있어도 개발자가 코드를 잘 작성해야만 프로젝트가 성공하는 것이다.

거시적(macro) 아키텍쳐가 중요하지만, 더욱 더 중요한 것은 미시적(micro) 아키텍쳐다. 달리 말하자면 좋은 코드를 작성하는 개발자가 가장 중요한 자산이라는 것이다. 좋은 코드를 짜는 개발자는 결국 개발 속도가 빠르고 디버깅하기 좋으며, 유지보수가 어렵지 않은 프로그램을 만들어 낸다. 아키텍트 혹은 프로젝트 매니저가 해야하는 중요한 일들 중에서 결국 가장 중요한 것은 사람을 잘 선택하거나 혹은 사람을 가르치는 것이다.

세상 사람 누구나 '설계'라는 단어의 의미를 안다. 돈을 주고 사고 파는 가전제품, 건축물, 자동차, 옷 등 다양한 상품들이 설계라는 과정을 통해서 만들어진다는 것도 안다. 그리고 설계 없이 무언가가 만들어진다는 것은 상상하기 어렵다. 아이들의 장난감조차도 말이다. 그런데 정작 수천만원에서 수억의 돈을 들여서 만들어지는 웹 사이트, 프로그램들을 구현할 때 제대로 설계가 이루어지지 않는다고 한다면 소프트웨어를 모르는 일반인들이 이해할 수 있을까? 수백억을 들여 영화를 제작하는데 있어서 시나리오도 없이 촬영하고 편집한다는 얘기와 다를 바 없는 것이다. 그런데, 막상 소프트웨어를 제작하는 사람들 중 대다수가 소프트웨어를 어떻게 설계하는가에 대해서 거의 모른다고 할 수 있다.

물론 IT에서 10년 이상 개발을 해온 나 자신도 정확히 어떻게 설계하는 것이 법칙(규칙)이라고 말할 수 없다. 왜냐하면 소프트웨어 설계에서 대해서는 단 한번도 규칙이나 원칙이 만들어진 적이 없기 때문이다. 서점이나 인터넷을 뒤져보면 분명히 소프트웨어 설계에 관한 문서들을 찾을 수 있다. 하지만 그것들은 거의 ~론이라고 불리운다. 어떻게 하는 것이 좋다는 주장이자 의견이지 법칙이 아니라는 것이다. 춘추전국 시대의 온갓 사상처럼 무엇이 옳다, 무엇이 대세다 라고 말할 수 없이 그저 혼란스러울 뿐이라는 것이다. 소프트웨어 관련 기술 혹은 분야는 사실상 '성숙된 산업이나, 학문이라고 할 수 없다'라고 단언할 수 있다.

그럼에도 불구하고, 아니 그렇기 때문에 더욱 더 소프트웨어 설계, 아키텍쳐 설계가 중요한 것이다. 왜냐하면 소프트웨어는 더 이상 한두 사람의 노력으로 만들 수 있는 것이 아니며 - 80년대 그리고 90년대 초까지만 해도 한명이나 서너명의 노력으로 소프트웨어를 제작할 수 있었다 -, 비용 면에서는 수억에서 수백억의 투자가 발생하는 거대 비지니스이기 때문이다. 몇달에 걸쳐 수십명의 개발자, 그리고 수억의 돈이 투자되는 이유는 그만큼 중요하고 필수적인 인프라이기 때문이다. 대기업에서 소프트웨어 구축 프로젝트가 한두달 지연되면 수천억 이상의 손해가 발생할 수 있다. 만일 은행 시스템이 하루라도 중단되면 어떤 일이 벌어질까? 네이버 검색 시스템 개편이 한달 지연된다면 NHN이 감당해야할 손해는 얼마일까?

어쩌면 아키텍쳐 설계가 다 부질없는 짓일지도 모른다. 소프트웨어 개발은 고통스러운 일이며, 아무도 인정해주지 않는 일이기 때문에 열심히 일해봐야 소용없고 더 나이들기 전에 그만두는 것이 낫다는 의견도 일리는 있다. 우리나라에서는 아키텍트라는 직종이 존재하지도 않고, PM은 그저 아랫사람들을 열심히 닥달하기만 하면 되는 것일지도 모른다. 그러나, 그런 식의 태도와 접근이 해답일까? 아무것도 아니다. 아무런 노력도 하지 않는다면 미래는 나아지지 않는다. 사회가 바뀌지 않는다고 노력하지 않으면 떠내려 가고 과거의 유물이 될 뿐이다. 당장 수억을 들여 개발하는 프로젝트가 제대로 된 아키텍쳐 없이 진행되고 있다면 성공할 확률보다 실패할 확률이 높다는 것이 자명하다. 그걸 알면서도 내버려 두고, 아무런 시도도 하지 않겠다는 것은 변명도 무엇도 아니다. 그저 포기 선언일 뿐이다.

아키텍쳐 설계 자체는 목표가 될 수 없다. 아키텍쳐 설계는 '프로젝트 성공'과 '우수한 소프트웨어' 개발을 위한 방편이며, 도구이다. 아주 필수적이고 당연한 것이란 말이다. 아무런 원칙도 규칙도 없을지라도 어떠한 방식으로라도 설계해야만 한다. 자동차가 처음 나올 때부터 지금의 모습이었는가? 수십년 이상에 걸쳐서 수정된 모습일 것이다. 설계는 아무나 할 수 없는 것이라는 편견도 버려야 한다. 당신이 만들고자 하는 소프트웨어의 모습을 어떤 방식으로든 그려내면 된다. 연필과 펜만 있이면 된다. 게다가 무수히 많은 방법론과 이론을 다 공부할 수는 없다. 다만 써먹을 수 있는 것 한가지라도 갖추어야 할 것이다. 설계에서 중요한 것은 어떤 이론이나 규칙을 적용했느냐가 아니라, 남들이 당신의 설계를 이해할 수 있느냐, 설계서를 보고 무언가를 만들 수 있는가 하는 것이다. 비록 채택한 방법론이 결국 틀린 것 혹은 비주류의 것이라는 판단을 하게 될지라도 말이다. (사실 아주 틀린 것은 없다. 구조적 프로그래밍 기법도 여전히 객체지향 내부에 살아있기 때문이다.)

결론은 단순하다. 일을 잘해서 프로젝트를 성공시키고 인정받자. 그러기 위해서 소프트웨어 아키텍쳐를 설계할 줄 알아야 한다. 그러면 혹시 성공할지도 모른다. 반면에 설계할 줄 모른다면 거의 대부분 실패할 것이다.

인사이트 출판사에서 출간된 "아키텍트 이야기"라는 책을 읽으면서 느낀 좋은 점은 아키텍트가 어떤 직업인가? 그리고, 어떤 일을 하는가에 대해서 서술적으로 알기쉽게 잘 풀어냈다는 점이다. 반면에 아쉬운 점은 구체적으로 어떻게 아키텍쳐를 설계해야 하는가(how to) 면에서는 많이 부족하다는 점이다. 개론적인 면에서는 훌륭하지만 단지 책을 읽어보기만 해서는 실제 아키텍트의 역할을 수행할 수 없다는 것이다. 물론 "아키텍트 이야기" 책 뒤에 나오는 다양한 참고서적들을 모두 읽어보면 자연스레 실무를 수행할 수 있겠지만 개발자 혹은 PM, PL 들에게 그 모든 책들을 읽을 시간적인 여유를 주는 회사는 어디에 있겠는가? 그렇다고 회사를 때려치고, 한두달 집에서 책만 읽을 수도 없는 노릇이고, 언급된 책과 기타 참고서적들을 다 사 모으려면 책값만 해도 수십만원은 들 것이다. 시간과 비용 면에서 절대 불가능한 일이다.

배고픈 이에게 물고기를 주는 것보다, 물고기를 낚는 법을 가르치는 것이 중요하다고 하지만 당장 우리에게 필요한 것은 체계적인 학습이 아니라 당장 써먹을 수 있는 템플릿(template) 들이다. 정작 나 자신도 프로젝트를 수행할 때마다 어떤 단계를 거쳐 설계를 진행해야할지 난감할 때가 많다. 무려 10년이 넘도록 SI 프로젝트를 해오고 있지만 말이다. 인터넷에서 다양한 방법론에 대한 이야기가 널려 있다. 또한, 문제가 발생했을 때 혹은 문제를 해결해야 할 때 써먹을 수 있는 샘플 코드들도 많이 있다. 그런데 정작 아키텍트들에게 필요한 그리고, 프로젝트 설계에 필요한 예제는 전무하다.

내가 경험한 것들, 그리고 정리하려고 하는 것들이 정답일 수는 없다. 어차피 기술과 환경은 끊임없이 진화하기 때문에 무엇이 법칙이다라고 단정지어 말할 수는 없을 것이다. 하지만, 길을 묻는 이에게 적어도 한가지 뚜렷한 길을 알려줄 수 있다면, 하나의 목표에 다가갈 수 있고 그로 인해 자신감을 얻으며 차후에 다른 길을 찾아내거나 다른 목표를 정복하는데 참고가 될 수 있다면 내 글들이 작게 나마 가치있는 것이 될 수도 있을 것이다. 물론 타인만을 위해서 정리하고자 하는 것이 아니다. 자신이 걸어온 길을 잠시나마 돌아볼만 하다면 그 또한 가치있는 일일 것이다.

늘 시작은 어렵지 않다. 다만, 끝내는 것이 어려울 뿐이다. 그것을 알면서도 어쩌면 끝내지 못할지도 모른다는 것을 알면서도 감히 시작하려는 것은 고민만 해서는 아무것도 얻을 수 없기 때문이다.

IT 분야는 늘 희망과 절망이 함께 공존하는 곳이지만 - 야후가 떠오르기는 했지만, 곧 구글에 따라잡힌 것처럼 - 그래도 희망이 있는 곳이라고 믿었다. 아니, 희망을 가지지 않고서는 도저히 살아갈 수가 없기 때문일지도 모른다.

그런데 시장도 커가고, 경력도 쌓여 가지만 오히려 희망의 크기는 줄어가고 있다. 요즘 신입 인력을 구하는데 이력서에 나와 있는 놀라운 자기 소개를 보고 절망이 한움큼 자라나는 것을 느끼기 때문이다. 아무리 신입이라지만 개발해본 경력 내용에 "구구단"과 "소수 구하기" 프로그램을 적었다는 것은 무얼 의미하는가? 이 정도 프로그램은 원래 초등학생이나 중학생 교육용 프로그램인데 말이다. 모두가 이렇지는 않을 것이다. 물론 유능한 인재도 많다. 하지만 현장에서 그런 인재들을 채용할 수 조차 없다. 여러가지 이유가 있겠지만 가장 큰 이유는 IT 분야의 임금 수준이 너무 낮기 때문이 아닐까?

오늘 선배의 메일이 하나 왔다. 같은 대학, 같은 대학원을 나오고 석사논문을 거의 대신 써줘야 했을 정도로 전공에 대한 실력은 없었던 선배. 그런데 올해 주식 수익율이 50%였다나? 게다가 한달간 홀홀단신 해외여행도 다녀오시고 요즘 PMP에다가 주택관리사 자격증 까지 따려고 하신다는군. IT 컨설팅 분야에 잠시 몸담았다가 요즘은 공기업에 취업하신 것으로 안다. 선배에게 IT라는 전공은 취업 수단이었고 늘 실력보다는 정치력으로 살아 남았다. 물론 무능한 분은 아니다. 거의 모든 자격시험을 단 한번에 통과하는 시험의 강자인데다, 마당발이며 착실하고 말 잘 듣는 헬스 매니아 몸짱 남편까지 둔 여걸이니까 말이다. 빈손으로 시작해서 30대에 수억의 자산을 모았다는 것이 선배 능력에 대한 가장 뚜렷한 증거일 것이다.

사실 이런게 우리나라의 현실이다. 착실하게 한 우물을 파기보다는 다재다능하고 인맥을 잘 쌓으며 화술에 능해야 한다. (다른 나라도 별다르지 않겠지만...) 여전히 희망을 버리지도 않고, 남의 떡을 부러워하지도 않지만.... 그래도, 현실은 변하지 않는다. 아마 수십년 후라도 마찬가지일 것이다.

노력하는 사람들에게 하늘은 분명히 보상을 해준다. 다만, 어떤 분야는 다른 분야보다 그 보상이 적다. 아주 적은 분야도 있다. 그렇기 때문에 IT 분야 인력의 하향평준화는 거스를 수 없는 대세라고 말하고 싶다. 열심히 노력해도 그 댓가가 적기 때문에 노력을 안하게 되거나, 좋은 능력을 가진 인재나 사회 물정에 밝은 사람이라면 절대 뛰어들지 않을 분야로 인식되는 것이다.

그렇다고 무조건 인문계를 가야 한다거나, 무조건 공돌이라는 직업을 선택해서는 안된다는 말은 아니다. 누구나 타고난 재능이 있기에 커뮤니케이션 능력이 부족한 사람이 아나운서를 지망해서는 안되는게 아닌가? 반대로 IT에서도 꾸준히 영웅과 스타들이 배출될 것이다. 진짜 문제는 실력있는 선수들이 모이지 않는 리그는 결코 관중을 모을 수 없다는 것이다. 흥행이 되지 않는 리그에는 좋은 선수가 모이지 않게 되고 악순환은 반복되는 것이다. 과거의 영광을 그리워하는 노장들만 남은 그런 리그에서 감독 생활이나 해야할까? 아니면, 일찌감치 다른 종목을 찾아 떠날 것인가? 아, 물론 하락하는 시장에서도 독보적인 팀은 살아남는 법이다. 쓸쓸하게 말이다. 점점 선택의 기로에 다가서는 것을 느낀다.