jjeong

지난 컬럼에서 살펴본 개발자 관리의 문제점 및 좋은 관리 지침에 대해 독자들의 많은 피드백이 있었다. 그만큼 관리가 제대로 되고 있지 않다는 실증일 것이다. 올바른 관리의 밸런스를 갖추는 것은 쉽지 않다. 통제에 집착한 나머지 '관리를 위한 관리'를 하게 되거나, 리소스 부족 또는 자율에 집착한 나머지 방임을 하게 되는 경우가 많기 때문이다.

또한 이러한 잘못된 관리의 근원적인 문제는 곧 시스템의 문제라고 볼 수 있다. 단지 관리자 개인의 철학과 도덕성만으로는 어쩔 수 없는 조직문화, 그리고 조직의 프로세스로부터 엄청난 영향을 받기 때문이다. 사실, 조직문화와 시스템의 문제는 일개 개인이 어떻게 할 수가 없다. 시스템에 반발하면 퇴출당하거나 스스로 나가야 할 뿐이다.

이에 대해서는 필자 스스로 여러 기업들을 전전하면서 가슴 절절하게 느낀 부분이다. 그러므로 관리자들은 조직문화에 맞추어서 그리고 시스템을 위배하지 않는 가운데에서 자신의 관리 철학을 구현하려고 노력해야 할 것이다. 이것이 관리자를 위한 애정 어린 조언이다.

시스템을 바꿀 수 없다면 자신을 바꿔라
그렇다면 개발자 개개인은 어떻게 해야 할까? 많은 개발자들이 사회 환경과 조직 시스템에 대해 불만이 많다. 하지만 자신이 권한이 없다면, 사회와 조직은 바꿀 수 없다. 그것에 반발심을 가진 채로 자신에게 맞는 노력을 하지 않는다면, 마치 사춘기 소년이 트라우마를 안겨준 부모에게 반항한 나머지 자신의 인생을 망가뜨리는 것처럼 개발자 자신의 삶도 망가질 뿐이다.

조직은 개발자의 경력관리를 해주지 않는다. 이점은 불변의 진리이다. 정말 잘못된 일이지만, 현실을 보면 많은 회사들이 직원을 "달면 삼키고 쓰면 뱉는 일"이 빈번하다. 그러니 사람들이 생존의 욕구에 집착한 나머지 자아실현은 엄두도 내지 못하고 있는 것이 아닐까? 생존조차 쉽지 않은 것이 이 사회의 현실이다. 더군다나 개발자 직종에 몸담고 있다면 삭막한 현실은 몇 배 더 증가한다.

사회에서 성공한 선배 개발자(그 성공의 기준이 돈이든 명예든 자아실현이든)를 찾아보기가 참으로 힘들다. 물론 그것의 가장 큰 이유는 바로 업계 풍토 때문인데, 그것에 대해서는 이미 두 차례에 걸쳐서 컬럼을 쓴 바 있다. 업계 풍토는 서서히 변하거나 변하지 않는다. 개발자 개인이 바꿀 수 있는 것은 단기적으로는 단지 자기 자신뿐이다. 그렇다면 개발자 개인이 갖추어야 할 주요 역량에는 어떤 것들이 있는지 살펴보자.

개발자 개인이 갖추어야 할 주요 역량
첫째, 주변 상황과 인간의 역학관계를 이해하고 교류하는 커뮤니케이션 스킬이다. 많은 개발자들에게 있어 가장 부족한 역량이 바로 이것이다. 혹자는 이렇게 말한다. 개발자들은 그 특성상 커뮤니케이션 스킬이 부족할 수밖에 없고, 외국에서는 그것을 인정해주는데 한국에서는 왜 그렇지 않냐고. 실제로 소프트웨어 강국들을 보면, 개발자들에게 개발에만 집중할 수 있는 환경을 제공해주며 멀티플레이어 역할을 원하지 않는다. 하지만 한국은 소프트웨어 강국이 아니다! 또한 아무리 개발자를 대우하는 외국에서도 성공하는 개발자들은 커뮤니케이션 스킬이 뛰어난 사람들인 경우가 많다.

이 점을 간과해서는 안될 것이다. 커뮤니케이션 스킬은 개발자가 노력해서 갖추어야 하는 것이며 그것을 폄하해서는 안 된다. 개발자들과 함께 일해본 기획자들은 개발자들의 커뮤니케이션 문제점에 대해 지적하는 경우가 많다. 그들은 개발자들의 커뮤니케이션 태도가 닫혀있고, 어려운 용어를 남발하며, 대세에 영향을 미치는 않는 사소한 문제에 집착하고, 타인의 요구에 대해 관심을 가지지 않는다고 필자에게 하소연하곤 한다. 개발자 출신인 필자가 보기에도 그런 개발자들이 많다는 것을 인정하지 않을 수 없다.

물론 그러한 캐릭터가 바로 개발자이다. 그렇기 때문에 하루 종일 모니터를 바라보며 코딩의 세계에 빠져있을 수 있는 것이다. 하지만 만일 고도의 집중력를 발휘할 수 있는 캐릭터의 특성을 유지하면서 또한 타인과의 커뮤니케이션 스킬에 있어 조금의 향상이라도 가져온다면, 더욱 더 개발을 잘 할 수 있는 환경을 얻게 될 것이다. 즉 코딩을 더 잘하기 위해 커뮤니케이션 스킬이 필요한 것이다. 좋은 커뮤니케이션 스킬은 좋은 환경을 만들어 준다. 만일 데일 카네기의 책 한 권 읽어본 적이 없다면 지금 당장 인터넷 서점에서 구매하기 바란다.

둘째, 기술향상과 인간수양을 위한 자기계발이다. 자기계발이란 조직이 책임져주는 것이 아니다. 다시 한번 말하지만 조직은 경력관리를 해주지 않으며 자기계발을 시켜주지도 않는다. 회사가 시켜주는 교육은 단지 회사 업무를 위한 것일 뿐이다. 그것마저도 직원들이 함께 받는 경우가 대부분이라서 경쟁력 향상에 별로 도움이 되지 않는다.

자기계발은 여유 있을 때 행하는 것이 아니다. 실제로 인간이라는 존재는 한없이 여유로운 동물이라서, 시간이 많으면 더 게을러질 뿐이다. 그러므로 자기계발은 시간이 없을 때 짬을 내서 하는 것이라고 생각하는 것이 좋다. 그리고 자기계발에는 두 가지 측면이 있다. 하나는 개발자로서 기술적인 측면의 자기계발이고, 또 다른 하나는 인간으로서 인간수양 측면의 자기계발이다.

신기술 습득에 대해서는 다 아는 부분이니 따로 얘기하지 않겠다. 인간수양은 흔히 간과되지만 몹시 중요한 부분이다. 태어난 그 자체의 결함 가득한 성격 그대로 산다면 동일한 실수와 실패를 반복하게 될 뿐이다. 인간으로서의 멋진 점은 자신을 계속 가다듬으면서 조금이라도 완성된 인간을 지향하는데 있다. 다양한 책을 읽고, 가보지 않은 곳을 가고, 많은 사람들을 만나야 한다. 만일 이것을 해낸다면 인생의 도를 깨우친 멋진 개발자가 될 수 있을 것이다.

셋째, 작은 성공을 통해 큰 성공을 얻을 수 있도록 끊임없는 변화하고 실행해야 한다. 주변 상황과 인간을 입체적으로 이해하고 교류하면서, 기술과 인간적 소양의 자기계발을 하다 보면, 어느 순간 기회가 온다! 이것은 정말 준비된 사람에게만 주어지는 선물과도 같다. 하지만 준비되지 않은 사람에게는 기회 자체가 주어지지 않거나 또는 기회가 왔다고 하더라도 그 자신이 눈치챌 수 없다.

우리 스스로 저주를 받을 것인지 축복을 받을 것인지 선택할 수 있는 것이다. 그렇다. 어떤 측면에서 인생은 충분히 콘트롤 할 수 있다. 자신을 진화시키다 보면, 우리 자신이 이 사회에 변화를 줄 수 있는 주체라는 것을 깨닫게 되고 실제로 변화를 행할 수 있는 기회를 얻게 되는 것이다. 그러한 기회를 얻기 위해서는 끊임없이 변화하고 실행해야 한다. 자기 자신에게 다가오는 모든 기회를 수용하며 그 결과를 확인해야 한다. 불안감과 두려움 따위로 인해 좋은 기회를 포기해서는 안 된다.

자신에게 좀 벅차다고 생각하는 바로 그것을 떠맡아야 한다. 그 일을 하게 되면 그 일을 하기 전에 자신이 생각했던 그 모든 게 바보 같았다는 것을 깨닫게 된다. 그리고 이미 사람이 달라지고 있는 것을 발견하게 된다. 결국 그 일을 끝마쳤을 때는 모든 것이 변해있다. 작은 성공사례를 반복하고 반복하면서 더 큰 성공사례를 향해 다가가는 것이다. 그러니 신기술 구현이든, 새로운 프로젝트를 떠맡는 것이든, 자격증 도전이든, 커뮤니티 창설이든, 이직이든, 대학원 진학이든, 외국 취업이든 두려워하지 말고 실행하기를 바란다. 실행하면 모든 것이 달라진다.

환경, 조직, 사람간의 역학관계를 이해하고 미래를 준비하는 개발자
유능한 개발자는 기술력이 뛰어날 뿐만 아니라, 자신이 해야 할 일을 둘러싼 기술적/정치적 환경을 입체적으로 이해하고 교류하며, 자신에게 요구될 역량을 미리 갖추고 있으며, 적절한 시점에 곧바로 행동에 옮길 수 있는 실행력을 갖춘 사람이다.

왜 개발자가 이렇듯 기술 외적인 부분에 대해 신경을 써야 할까? 이런 필자의 논리에 대해 불편한 감점을 느끼는 개발자도 있을 것이다. 충분히 이해하고 있다. 그러므로 좀 더 부연설명을 해보겠다.

만일 현재 자신이 처한 환경이 돈, 명예, 자아실현의 관점에서 자신의 원하는 만큼 만족스럽다면 필자가 제시한 이러한 역량들에 대해 신경 쓰지 않아도 좋다. 그런 분들한테는 여기까지 글을 읽게 해서 죄송할 따름이다. 하지만 자신이 처한 환경이 만족스럽지 않다면 그것이 커뮤니케이션 스킬과 자기계발, 실행력이 부족하기 때문은 아닌지 생각해 보기 바란다.

필자가 언급한 역량들은 사실 개발자뿐만 아니라 이 사회의 모든 개인이 갖추어야 할 역량이라고 볼 수 있다. 하지만 잘못된 업계 풍토로 인해 어려움에 처해있는 개발자들에게 있어 특히 부족하면서도 더욱 요구되고 있는 역량이라고 볼 수 있다. 이러한 역량들이 가져다 주는 놀라운 결과들을 간과하지 않았으면 좋겠다.

환경을 바꿀 수 없으면, 자기 자신을 진화시키고 결국 환경을 만들어 내야 한다. 그러지 못한다면 잘못된 업계 풍토로 인한 희생양이 될 뿐이다. 이 사회에 대한 올바른 이해와 방향 감각을 갖추고 있으면서, 부단히 노력하며 진화를 꿈꾸는 개발자의 앞날에 커다란 행운을 기원한다

일반적 개념의 SOA란 무엇인가?
먼저 SOA(서비스지향아키텍처)에서 이야기 하는 '서비스'를 이해할 필요가 있습니다.. SOA에서 이야기하는 서비스는 IT적인 개념이 아니고 비즈니스적인 용어로서 '특정한 기능을 하는 단위'를 서비스라고 합니다. 예를 들어, '항공권 예약' '호텔 예약' '고객 정보 조회' '예금' 같은 것을 서비스라고 할 수 있습니다.

즉 기업의 업무를 기능단위로 나눈 것을 '서비스'라고 합니다. 이러한 기능 단위는 크게 나누거나 보다 자세하게 나눌 수 있는데, '항공권 예약' 이라는 것도 사실 '항공 좌석 조회', '회원정보 조회', '좌석 배정' 같은 더 작은 서비스로 구성되어 있습니다. 그래서 기업 업무의 어떤 기능을 서비스화 할 것인지, 이러한 서비스 단위를 얼마나 작은 단위로 쪼갤 것인지 같은 것이 SOA의 핵심적인 사항이라 할 수 있겠습니다.

이야기가 길었습니다만, SOA라는 것은 이렇게 정의된 서비스를 배열하여 기업의 업무를 구현하는 방식을 말합니다. 그래서 SOA라는 것은 기업의 어떤 업무에서도 적용할 수 있는 일종의 IT 아키텍처의 사상이면서 아키텍처를 만드는 스타일을 말하는 것입니다. 그래서 SOA 기반 BPM, SOA 기반 CRM등이 모두 가능한 것입니다.

기업에서 왜 SOA가 필요한가?
기업에서 SOA를 이야기하는 것은 '비즈니스 유연성' 혹은 '비즈니스 민첩성' 때문입니다. 한가지 예를 들어 A라는 은행이 새로운 상품 Y를 새로 출시하여 선풍적인 인기를 끌렀다고 한다면, 경쟁 은행인 B, C, D가 유사한 상품을 내놓으려고 합니다.

이때 SOA를 적용하지 않은 기존 시스템에서 새로운 상품을 개발한다면 시간이 많이 걸리게 됩니다. 먼저 현업에서 상품을 디자인하여 IT 기획에 넘기면 IT 기획에서는 이를 가능하게 하려고 기존 애플리케이션을 바꾸려고 합니다. 그 과정은 설계를 하고 설계에 맞추어 코딩을 하고 테스트 한 후 운영계로 옮겨 실제로 상품을 시장에 팔 수 있게 합니다.

이러한 과정이 3개월에서 4개월 걸리게 되는데, 그 3~4개월 동안 먼저 상품을 출시한 A은행이 시장을 석권하게 되는 것이지요. 시장에서는 항상 1등만을 기억하게 됩니다. 이러한 경우를 보게 되면 IT 시스템이 오히려 발목을 잡게 되는 것이지요. 만약 B은행이 A은행이 상품을 출시한 지 1~2주 만에 비슷한 상품을 내놓을 수 있으면 어떻게 될까요?

시장은 A와 B은행이 양분 하게 될 것입니다. 이렇듯 SOA는 기업들이 변화하는 시장 환경에 빠르게 대응할 수 있게 해 주기 때문에 기업의 '비즈니스 유연성' 또는 '비즈니스 민첩성'을 높여줍니다. 이것은 곧 기업의 경쟁력을 높여주어서 생존하고 성장할 수 있는 기반이 됩니다.

어떻게 이러한 것이 가능하느냐 하면, SOA는 미리 '서비스'들을 만들어서 저장소에 넣어놓았다가 현업 사용자가 저장된 서비스 들을 검색하여 필요한 서비스들을 골라 그 서비스들을 순서대로 작동하도록 배치하기 때문입니다.

그러한 과정은 현업 사용자가 툴을 사용하여 그림 그리듯이 쉽게 할 수 있습니다. 그렇게만 하면 바로 사용 가능한 애플리케이션을 만들어 내는 것입니다. 그렇기 위해서 개발자들은 필요한 모든 애플리케이션 컴포넌트를 미리 만들어 놓아야 합니다. 그래서 기존의 IT 시스템을 재활용하여 개발 속도를 빠르게 하기도 합니다.

국내의 SOA 도입 실정은?
국내 기업의 SOA 도입은 이제 초기 단계입니다. 대부분이 기업 업무의 일부만을 SOA로 적용하는 단계이거나 비즈니스 프로세스를 SOA로 구현하는 단계가 대부분입니다. IBM의 SOA를 예로 들자면, '기본 단계와 '통합 단계' 에 해당하는 것 같습니다.

주로 많이 사용하는 분야는 BPM과 ESB를 활용한 이기종 시스템과의 연결 업무에 많이 사용합니다. SOA는 사실 거의 모든 기업들이 관심을 가지고 있습니다만 실제로 구현하는 기업은 주로 새로운 IT 기술 도입에 거부감이 없는 기업들이 많이 합니다. 특별히 어떤 수준의 기업이 한다고 이야기 하기는 어렵습니다.

현재 국내 시장에서는 그룹사와 금융권, 정부 기관 등이 SOA를 도입하는 경향이 있습니다. 통상 그룹사의 경우는 주로 이기종 시스템간 통합 업무가 많고, 나머지는 주로 BPM쪽이라고 할 수 있습니다.

SOA 도입에 따른 우려, 기업의 IT 자회사 밥그릇 뺏기나?
대기업이 IT 자회사를 가지는 것은 한국만의 특수한 상황이 아니고 글로벌 기업들도 자체 IT 자회사를 많이 가지고 있습니다. IT 자회사들이 담당하는 것은 기업 IT 아웃소싱과 업무 개발로 나뉠 수 있는데, IT 아웃소싱은 SOA와 관련되어 영향을 받을 것 같지는 않습니다. 업무 개발 분야에서는 IT 자회사들이 오히려 할 일이 많을 것 같습니다.

초기 단계에서는 SOA에 대한 경험이 없기 때문이 SOA를 하는 글로벌 업체와 협력을 하는데, 주로 글로벌 업체가 선진 기법과 사례를 가지고 접근할 때 IT 자회사는 특정 기업에 특화된 정보를 제공함으로써 서로 협력을 합니다. 그러다가 SOA가 보편적으로 적용되는 단계가 되고 IT 자회사들의 기술이 축적이 되면 독자적으로 SOA를 적용할 수 있게 될 것입니다.

SOA가 점점 보편화 되고 '기업 혁신 단계'와 '동적 적용 단계'에 이르게 되면 IT가 겉으로 들어나지 않게 되는데, 이는 현업 사용자가 IT의 도움 없이 원하는 업무를 직접 조립하여 사용하는 단계를 말합니다.

그러나 이러한 단계에 이르려면 그 밑단에서는 너무나 복잡하고 많은 일들이 IT에 의해서 준비되어야만 하기 문에 오히려 SOA가 진행되면 될 수록 IT 자회사의 할 일이 많아질 것입니다.

향후 바람직한 SOA의 발전 방향은?
SOA는 기업 전체 IT의 아키텍처를 대상으로 합니다. 비록 처음에는 부서 단위 업무를 대상으로 작게 시작할 지라도 처음부터 전체 IT 아키텍처를 고려해야 성공적으로 SOA를 전사적으로 활용 할 수 있습니다.

SOA를 활용하려는 궁극적인 목적은 기업이 경쟁에서 살아남고 성장하기 위한 것입니다. 그렇게 되기 위해서는 필수 적으로 IT가 유연하게 되어야 한다는 것입니다. 기업은 IT 시스템을 단순히 돈을 사용하기만 하는 것으로 보는 것에서 기업 혁신의 핵심 동력으로의 인식전환이 필요합니다.

SOA는 궁극적으로 개발자의 도움 없이 필요한 업무를 스스로 조림하여 사용하는 '즉석 개발(Instance Development)'이 이루어 지는 수준까지 발전해 나갈 것입니다. @

기획/진행 : 김효정 기자(ZDNet Korea)