2월 2일까지 푸켓에서의 5박 6일 여행을 마치고 돌아왔다. 푸켓 여행은 생각보다 너무 좋아서 돌아오기 싫을 정도였다. 정말 밥 먹고, 수영하고, 낮잠자다가 수영하고, 밥 먹고의 생활을 며칠간 했더니 이렇게 좋을 수가.. 나 뿐 아니라 아내와 아이들이 너무 좋아해서 더 즐거운 여행이 될 수 있었다.

지금이 건기라 휴가 기간 내에 위 사진에 보이는 것처럼 맑고 푸른 하늘과 바다를 볼 수 있었다. 어찌나 파랗던지 누워서 하늘을 보고 있으면 어린 시절 시골 마루에 누워서 하늘을 바라보던 때가 생각이 났다.

나와 아내 모두 활동적인 여행보다는 조용하고 쉬기 위한 여행을 바래서였는지 더 만족스러운 여행이 되었다. 외출은 코키리를 타기 위해서 하루 외출했을 뿐이다. 왼쪽 사진은 코끼리를 탔을 때 찍은 사진이다. 나머지는 리조트에서 수영하고, 다양한 스포츠(양궁, 스쿼시, 테니스 등등) 하는데 시간을 보냈다.

물론 다양한 볼거리가 있는 여행도 좋지만 이번 여행처럼 아무 생각없이 책 읽으면서 편히 쉬는 여행도 정말 좋은 여행이라는 것을 다시 한번 느낄 수 있었다.

처음 떠난 가족의 해외 나들이였는데 너무 만족스러운 여행이었다. 여행에서 돌아오면서 지금부터 조금씩 돈 모아서 3~5년 후에 다시 한번 해외로 나가자는 계획을 세웠다. 넘 무리하는거 아닌지 모르겠다. 적게 벌어서 적게 쓰면서 살고자 하건만..

2009년 10월 팀장 자리에 실증을 느끼고 팀장을 그만 두었다. 팀장을 그만두고 내가 하고 싶었던 기술 지원 업무를 하고 싶었지만 진행하고 있던 프로젝트가 있었던 관계로 프로젝트를 마무리하고 조직을 이동하기로 결정했다. 2009년 12월 말 진행하던 프로젝트를 마무리하고 2010년 1월 인수인계를 진행하면서 자연스럽게 이동할 계획이었다. 그런데 올해 2월 조직 개편을 하면서 4개월간 버렸던 팀장을 다시 하게 되었다. 자의반 타의반 팀장의 자리를 맡게 되면서 다시 한번 새로운 도전을 하게 되었다.

내가 맡게 된 팀은 전략적으로 의사 결정이 필요한 업무에 대하여 프로토타이핑을 진행하면서 요구사항을 수렴하고, 구체화하는 것이 주요업무이다. 기존에 진행했던 개발 업무와는 완전히 다른 새로운 성격의 업무이다. 휴가에서 어제 복귀하고 이틀째인 오늘까지도 팀을 어떤 방향으로 만들어갈지에 대한 구체적인 모습을 잡지 못한 상태이다. 조직 내에서도 완전히 새로운 시도인지라 딱히 이렇게 일을 해야 한다는 것 또한 없다.

아무 것도 없는 것에서 하나씩 만들어 가야 한다는 것이 나름 재미있는 일이기도 하지만 일정 수준으로 구체화하기 전까지는 많은 고통이 따름을 안다. 하지만 내가 지향하는데로 조금씩 구체화되어 가는 모습을 보는 것은 개발을 통하여 좋은 소프트웨어를 만드는 것만큼 짜릿한 즐거움을 준다. 물론 바람직한 모습으로 조직이 성장하고 가치있는 일을 하고 있을 때의 이야기이다. 그렇지 않은 경우에는 더 큰 고통이 따르는 법..

오랜만에 나에게 던져진 새로운 도전거리라 약간의 긴장과 흥분이 교차한다. 한편으로는 개발에서 다시금 조금 멀어지는 느낌이지만 나름 이 조직 속에서도 재미있는 시도는 다양하게 해볼 수 있을 듯하다.

내가 진정 바라는 조직의 모습을 이 조직에서 더 빨리 만들어볼 수 있지 않을까라는 기대감으로 다시 팀장을 맡았다. 이번 시도에서도 진정 내가 바라는 일을 할 수 없다면 이젠 다른 시도를 해보는 수 밖에 없을 듯하다. 너무 한 곳에서 오래 안주하고 있는 것은 아닌지 모르겠다. 너무 오랫동안 가슴 뛰는 일을 하지 못해 무력감을 느낄 때가 많다. 다시 한번 가슴 뛰는 일을 만들어가고 싶다.

나는 경제 현안이나 부동산에 대한 정보를 얻기 위하여 종종 다음에 개설되어 있는 김광수경제연구소포럼 카페에 들른다. 이 연구소를 좋아하는 이유는 자신들이 분석한 내용을 국가나 특정 기업의 눈치를 보지 않고 솔직하게 전달하고 있다고 판단되어 신뢰감이 가기 때문이다. 오히려 지금 정부나 기업들이 싫어할 말들만 골라서 한다고 해도 좋을 듯하다.

어제 이 카페에 잠시 들렀다가 카페에서 케네디언이라는 별명으로 활동하고 있는 선대인 부소장이 MBC 100분 토론에 참석했다는 소식을 접하게 되었다. 최근에 TV도 없고, 손석희 아나운서도 자리에서 물러나면서 100분 토론을 보고 싶은 마음은 없었는데 자주 들르는 카페에서 활동하는 분이 참석했다기에 다시 보기를 통해서 100분 토론을 보게 되었다.

100분 토론의 주제는 "2010 부동산, 어디로?"였다. 내가 이 방송을 보면서 느낀 것은 부동산에 대한 지식을 얻고 앞으로 어떻게 행동해야 되겠다는 것이 아니었다. 내가 이 방송을 보면서 더 크게 느낀 것은 "진정한 전문가라면 어떻게 활동하는 것이 맞을까?"라는 것이었다. 최근의 많은 지식 전문가들은 특정 기업이나 연구소에 소속되어 해당 기업이나 연구소의 이익을 위하여 일하고 있으며, 이로 인해 월급을 받으며 생계를 유지한다. 이런 실정이기 때문에 자신이 옳다고 생각하는 진실을 전달하지 않고 왜곡하는 경우가 많다. 하지만 진정한 전문가라면 자신이 분석하고 연구한 내용의 진실을 이야기할 수 있어야하지 않을까? 100분 토론의 선대인 부소장을 보면서 "진정한 전문가라면 저러해야 한다."라는 생각을 하게 되었다. 자신이 연구하고 분석한 내용이 현재 많은 사람들이 주장하는 논리와 틀리더라도 자신있게 이야기할 수 있어야 하지 않을까? 다른 사람이 이야기하기 꺼리는 부분이더라도 맞다고 판단한다면 소신을 가지고 이야기할 수 있어야 하지 않을까?

이 방송을 보면서 내 자신을 돌아볼 수 있는 계기가 되었다. 현재 사회는 많은 사람들이 점점 더 전문가가 되기 위하여 노력하고 있으며, 전문가로 성장하면서 부를 얻기 위하여 노력한다. 하지만 전문가가 되기 위하여 노력하기 전에 어떤 자세를 가지느냐가 더 우선시 되어야 하지 않을까 생각한다. 나 또한 전문적인 지식을 습득하는데만 집중할 것이 아니라 전문적인 지식을 습득해 무엇을 할 것인지를 고민해봐야겠다. 부동산에 대한 분석 내용도 좋았지만 그 보다 전문가로서 자세를 보여주는 모습이 나에게는 더 큰 감동이었다.

그 동안 me2day나 twitter를 할까 말까 고민하다가 오늘부터 me2day를 시작했다. 사실 개설한지는 1년이 다 되어간다. 오늘 들어가서 보니 개설 날짜는 2009년 2월 12일이다. 조금만 더 참았으면 딱 1년이 되는 시점에 시작할 수 있었는데.. 개설하게 된 이유는 1년 전에 같이 일하는 동료가 두명의 친구를 끌어들이면 스타벅스 커피를 공짜로 먹을 수 있다는 속임에 빠져서 개설했는데 알고 보니 추천했던 그 친구에게만 커피가 있었고 나한테 떨어지는 건 아무 것도 없었다.

어딘지 모를 배신감을 느꼈지만 그래도 javajigi 아이디를 미리 선점할 수 있는 기회는 되었다. 내가 마이크로 블로그를 시작하지 않은 이유는 지금까지 마이크로 블로그이 의미있는 컨텐츠일까에 대해서 많은 의구심을 가져왔고, 필요성을 느끼지 못했다. 그런데 최근 me2day나 twitter의 흐름을 보면 비동기이지만 실시간성 커뮤니케이션 채널로 유용하게 사용되는 모습을 보면서 나 또한 관심을 가지게 되었다. 더불어 글쓰는 사람들간의 부담 없는 의사소통은 토론을 싫어하는 국내 환경에서 다소 의미가 있지 않을까라는 생각이 들었다. 물론 팀을 옮기고 개발에 대한 관심 뿐만 아니라 기획에 대한 관심도 생기면서 자연스럽게 사용해봐야겠다는 생각도 하게 되었다.

친구들을 찾기 위해서 이리 저리 찾고 있는데 쉽지 않다. 나를 알고 있는 친구들 중 미투하고 있는 친구들 있다면 친구로 초대 좀 해줬으면 좋겠다. 아직 미투 초보라 어떻게 사용해야 되는지 막막한 상태이다. 이러다 미투에 빠져서 iphone도 지르고, 이 커뮤니티도 방치하는 것은 아닌지 모르겠다. 아무쪼록 과용은 금물..

내 미투 주소는 http://me2day.net/javajigi이다. 많은 분들과 친구로 지냈으면 좋겠다.

• 소프트웨어 개발자는 늘어나는데 생산성이 높아지지 않는 이유는?
• 업무, 조직 세분화로 인해 발생하는 문제점은?
• 웹 서비스 소프트웨어 개발 회사의 효율적인 조직 구조 및 관리

푸켓 여행 기간 중 프로페셔널의 조건(자기 실현편)이라는 책을 읽었다. 책을 읽기 시작할 때부터 나의 관심을 끄는 내용으로 시작하더니 끝까지 흥미진진하게 읽을 수 있었다. 현재의 나의 모습을 되돌아 볼 수 있는 기회도 제공해 주면서 앞으로 내가 나아갈 방향으로 제시해 주고 있다. 특히 지식 근로자의 생산성에 대하여 다루는 부분이 특히 좋았다.

내가 몸담고 있는 소프트웨어 개발자 또한 지식 근로자 중의 한 분야이기 때문에 더 많은 부분에서 공감할 수 있었다. 지식 근로자의 생산성과 앞으로 나가야할 방향에 대하여 많은 숙제를 안고 휴가에서 복귀한 시점에 CSO님이 사내 관리자를 대상으로 진행했던 강의 동영상을 볼 수 있었다. 강의를 듣다가 CSO님이 던진 질문의 원인과 해결책에 대한 내 나름대로의 생각을 정리하기 위하여 지금까지 고민했던 내용을 적어본다.

CSO님이 던진 질문은 다음과 같았다.

"개발자가 부족하다고 해서 몇 배의 개발자를 충원했다. 그런데 개발자 리소스는 항상 부족하다고 한다. 개발자가 충원되었음에도 불구하고 개발 생산성은 높아지지 않은 것 같다."

먼저 위 질문에서 개발자에 대한 정의가 필요할 것으로 생각한다. 내가 보는 관점에서 위에서 이야기한 개발자는 우리들이 흔히 이야기하는 프로그래머를 의미하는 것이 아니라 프로젝트에 참여하는 프로젝트 구성원으로 보는 것이 타당할 것으로 생각한다. 해외의 경우에는 프로젝트에 참여하는 구성원의 대부분이 개발자일 가능성이 높겠지만 국내 웹 서비스 개발 회사는 많은 업무로 나뉘어 개발이 진행되고 있기 때문에 이들을 통틀어 개발자로 보는 것이 맞을 것으로 생각한다.

이 질문에 대하여 지금 몸담고 조직에 있으면서 느꼈던 내용을 바탕으로 내가 생각하는 방향을 정리해보고자 한다. 물론 내가 지금 회사를 경영하는 경영자는 아니지만 효율적인 조직을 만드는 방법에 대해서 많은 관심을 가지고 있었기 때문에 내 나름대로의 원인과 해결책을 가지고 살아왔다. 몇 번의 포스팅을 통하여 이 내용을 다루어 보도록 하겠다. 이 글에서 다루고 있는 내용이 내가 몸담고 있는 조직에 국한된 것이 아니라 소프트웨어 개발을 하고 있는 많은 조직에서 발생하고 있는 현상이리라 생각한다. 어쩌면 소프트웨어 개발 조직 뿐만 아니라 앞으로 점점 지식 근로자가 많아지는 회사에서 경험하게 될 현상이 될 수도 있다고 생각한다.

자 그럼 이제 본격적으로 이야기를 시작해보자.

소프트웨어 개발은 다른 분야에 비하여 역사가 길지 않기 때문에 생산성 향상을 위한 방법을 다른 분야의 성공 사례를 도입하여 적용하는 것이 현실이다. 그 중 대표적인 예가 제조업의 경험으로부터 분업화와 자동화를 도입하려는 시도가 많았다. 또한 제조업, 건축 분야로부터 모듈화를 통한 재사용 가능한 컴포넌트화에 대한 시도가 그것이리라. 이 글에서는 자동화와 모듈화를 통한 생산성 향상에 대해서는 언급하지 않았다. 이 글에서는 제조업 분야로부터 도입한 분업화에 대하여 언급하고자 한다.

프로페셔널의 조건에 나오는 내용을 보면 다음과 같은 내용이 나온다.

작업은 연구될 수 있고 분석될 수 있으며, 또한 작업은 일련의 간단하고도 반복적인 동작으로 나눌 수 있다는 것 - 즉 작업에서의 각 동작은 하나의 옳은 방법으로, 주어진 시간 내에, 알맞은 도구를 사용하여 수행될 수 있다. - 테일러의 주장

테일러의 주장에 의한 훈련 방식을 도입한 국가들의 생산력은 거의 50배 가까이 증가하였는데, 이 놀라운 생산력 증대야말로 모든 선진 국가에서 생활 수준과 삶의 질을 월들히 향상시킬 수 있었던 근원이었다.

• 피터 드러커, 프로페셔널의 조건 1장 일부 발췌 및 정리

위 인용문의 테일러의 주장은 한마디로 말해서 모든 작업을 분석하여 세분함으로써, 단순화할 수 있고, 짧은 기간의 훈련만으로 '일류 기술자'를 만들어 낼 수 있다는 것이다. 이 주장은 제조업 분야에는 적중했으며, 이로 인해 생산성 혁명이 가능하게 되었다.

이와 같이 제조업에서의 비약적인 생산성 향상은 새롭게 등장한 소프트웨어 개발 분야에서도 매력적일 수 밖에 없었다. 하지만 제조업에서 성공적이었던 이 방법이 소프트웨어 개발에 있어서는 성공하지 못하고 있는 듯하다. 그 이유에 대하여 Pete McBreen은 다음과 같이 이야기하고 있다.

소프트웨어 개발에 있어서 작업을 세분화하고 분업화할 때 작업이 더 작은 단계로 세분화될수록, 한 사람에서 또 다른 사람으로 정보를 전달하는 데에 더 많은 시간이 걸린다. 생산라인 접근 방식은 수작업 노동에는 잘 맞을 수 있다. 그러나 지적인 작업에는 형편없이 실패한다.

소프트웨어 개발은 팀원들의 머리에서 일어난다. 사람들을 특정 활동에 전문화시킴으로써 간단한 프로젝트의 딜리버리도 여러 경로를 통해야 한다. 각 경로는 실수와 결함에의 잠재성을 갖고 있는 값비싼 과정이다.

• Pete McBreen, 소프트웨어 장인 정신

소프트웨어 개발에 있어서 작업을 세분화할 경우의 문제점에 대하여 설계 작업과 개발 작업을 분리할 경우 발생할 수 있는 한계점을 다루고 있는 다음 글을 읽어보면 많은 부분에서 공감할 수 있을 것이다.

• 설계의 본질, 그리고 UML - 1부
• 설계의 본질, 그리고 UML - 2부
• 설계의 본질, 그리고 UML - 3부

소프트웨어 개발에 있어 세분화, 분업화로 인하여 얻을 수 있는 한계가 있다는 것을 알고 있지만 아직도 많은 소프트웨어 개발회사는 제조업의 생산성 향상 방식을 도입하고 있다. 이와 같이 변화하게 되는 과정을 살펴보면 다음과 같다.

회사가 성장하는 초기 단계에는 각 서비스(또는 프로젝트)별로 업무를 세분화하여 프로젝트를 진행한다. 물론 이 시점에 업무가 세분화되어 있지만 문제가 될 정도로 세분화되어 있는 상태는 아니다. 조직 구조 또한 서비스(또는 프로젝트)를 기준으로 분리되어 있는 경우가 많다. 회사가 성장하는 단계에 있어서 일정 수준의 분업화와 조직 구조는 크게 문제가 되지 않는다. 하지만 회사가 성장하고 조직이 커지면서 전문화와 효율화를 해야 한다는 이유로 각 업무별로 조직 구조가 바뀌고, 업무는 점점 더 세분화되어 간다. 이 같은 논리는 다분히 과거의 제조업에서의 생산성 향상에 대한 경험에 기반을 두고 있는 것으로 판단된다.

예를 들어 초기 단계에서는 다음 그림과 같이 업무 분석가(또는 기획자), 개발자, 디자이너, DBA(선택) 정도로 시작하는 경우가 많다.

시간이 지나면서 서비스가 성장하고 회사의 규모가 커질수록 각 프로젝트에 참여하는 역할은 세분화된다. 이에 대한 요구는 각각의 업무에 대한 전문성을 강화하기 위한 일환으로 진행된다. 전문화함으로써 소프트웨어의 품질을 향상시킬 수 있으며, 생산성 또한 높아질 것이라는 판단 때문이다.

이와 같이 프로젝트 하나를 진행하기 위하여 여러 개의 업무로 나누어지고, 각각의 업무를 담당하는 구성원들은 점점 더 증가한다. 시간이 지나면서 각각의 업무 담당자들은 자신과 같은 업무를 하고 있는 동료와 같은 조직에서 일하는 것이 자신의 실력을 향상할 수 있으며, 전문성을 더 강화할 것이라 생각한다. 이 같은 생각이 확대되면서 자연스럽게 각 업무는 하나의 조직으로 만들어지게 된다. 이와 같이 각각의 업무가 조직으로 바뀌게 되면서 프로젝트를 진행하기 위하여 관여하는 구성원이 한 개인이 아니라 조직(대표적으로 팀)이 되어버리는 상황이 발생한다.

많은 개발자를 충원했지만 개발 생산성이 향상되지 않는 가장 큰 원인에 대하여 내가 내린 결론은 앞에서 본 바와 같이 업무 단위를 너무 세분화, 분업화했기 때문이다. 업무 단위를 세분화하면서 조직 구조가 각 서비스(또는 프로젝트) 단위로 구성되었다면 좀 더 효율적이었을 것이라 생각한다. 하지만 조직 구조까지 업무 단위로 재편되면서 개발 생산성은 급격하게 떨어지게 된다. 업무 단위가 조직 구조로 변경되는 초기 단계에는 기존에 진행하던 업무 방식이 남아 있기 때문에 큰 변화는 없거나 오히려 각 업무 단위가 전문화 되면서 생산성이 향상된다는 착각을 할 수 있다. 하지만 더 큰 문제는 업무 단위 기반의 조직이 점점 더 탄탄해 지면서 발생하게 된다.

이번 글에서는 소프트웨어 개발 회사에서 개발자는 지속적으로 충원되지만 개발 생산성이 높아지지 않는 이유에 대하여 나의 생각을 정리해봤다.다음 글에서는 업무 단위를 기반으로한 조직이 점점 더 탄탄해지면서 발생할 수 있는 문제점에 대하여 살펴보도록 하겠다.

PS. 개발자가 늘어남으로 인해서 생산성이 떨어지는 이유는 이 이외에도 무수히 많을 것으로 생각한다. 이 글에서 내가 선택한 원인은 여러 개의 원인 중에서 가장 큰 원인이라고 생각하는 부분에 대하여 다루었다. 이후에 기회가 된다면 더 많은 원인에 대하여 이야기해보고 싶다.

• 소프트웨어 개발자는 늘어나는데 생산성이 높아지지 않는 이유는?
• 업무, 조직 세분화로 인해 발생하는 문제점은?
• 웹 서비스 소프트웨어 개발 회사의 효율적인 조직 구조 및 관리

이 글은 내가 포털 회사에 4년 간 몸담고 있으면서 느꼈던 내 나름대로의 생각을 정리한 것이다. 이 글의 내용은 포털과 같이 하나의 소프트웨어를 지속적으로 관리하고 성장시켜 나가야하는 소프트웨어 개발 회사에 도움이 될 듯하다. 나는 지금까지 웹 에이전시, SI 회사에 몸담은 경험이 더 많은데 웹 에이전시, SI와 같이 특정 회사에 업무 의뢰를 받아 단기간에 개발을 완료해야하는 조직에는 적합하지 않을 수 있다. 이 글의 내용은 내가 몸담고 있는 조직의 의견과는 무관하다. 지금까지 소프트웨어 개발 업무를 진행하면서 느꼈던 내 나름대로의 생각을 정리한 것이다. 내가 이 글을 쓰는 가장 큰 이유는 내가 잘못 판단하고 있는 부분도 많을 것이기 때문에 그에 대한 의견을 받아보고 더 바람직한 모습에 대한 논의를 해보고자 함이다. 논리적으로 타당하지 않거나 근거가 부족하다고 생각하는 부분에 대해서는 가차없이 의견 마구마구 날려주기 바란다.

• 소프트웨어 개발자는 늘어나는데 생산성이 높아지지 않는 이유는?
• 업무, 조직 세분화로 인해 발생하는 문제점은?
• 웹 서비스 소프트웨어 개발 회사의 효율적인 조직 구조 및 관리

지난 글에서는 개발자(프로젝트에 참여하는 모든 구성원을 통칭한다.)는 증가하지만 개발 생산성이 향상되지 않는 가장 큰 원인은 "업무가 세분화되고, 세분화된 업무 단위를 기반으로 조직 구조가 만들어지는 것이다."라는 이야기를 다루었다. 이번 글에서는 업무 단위를 기반으로 조직이 만들어질 경우 생산성 저하와 발생 가능성이 있는 문제점에 대하여 살펴보도록 하겠다. 문제점의 우선 순위는 파급효과가 큰 부분을 먼저 다루도록 하겠다.

급격하게 증가한 협업 비용

소프트웨어 개발 과정에서 업무를 세분화할 경우 가장 큰 문제점은 협업 비용이 급격하게 증가한다는 것이다. 이에 대한 가장 큰 원인은 앞 글에서 인용했던 Pete McBreen의 글을 통하여 확인할 수 있다. 다시 한번 인용해본다.

소프트웨어 개발에 있어서 작업을 세분화하고 분업화할 때 작업이 더 작은 단계로 세분화될수록, 한 사람에서 또 다른 사람으로 정보를 전달하는 데에 더 많은 시간이 걸린다. 생산라인 접근 방식은 수작업 노동에는 잘 맞을 수 있다. 그러나 지적인 작업에는 형편없이 실패한다.

소프트웨어 개발은 팀원들의 머리에서 일어난다. 사람들을 특정 활동에 전문화시킴으로써 간단한 프로젝트의 딜리버리도 여러 경로를 통해야 한다. 각 경로는 실수와 결함에의 잠재성을 갖고 있는 값비싼 과정이다.

• Pete McBreen, 소프트웨어 장인 정신

Pete McBreen의 말처럼 업무를 세부화할 수록 한 사람에서 다른 사람에게 정보를 전달하는데 많은 비용이 발생한다. 특히 각 업무를 맡고 있는 담당자의 Context가 다른 경우 그 비용은 더 커진다. 비용을 좀 더 구체적으로 살펴보면 다음과 같이 구분할 수 있을 듯 하다.

• 다른 파트에 정보를 전달하기 위한 문서화 및 문서에 대한 유지보수 비용
• 각 파트간에 정보를 공유하기 위하여 발생하는 회의비용
• 다른 파트에서 정보가 넘어오기를 기다리면서 소요되는 비용
• 정보를 잘못 이해함으로써 원하는 형태의 결과물이 나오지 않음으로써 발생하는 비용

위에서 살펴본 네 가지 이외에도 많은 비용이 발생하게 된다. 위 네 가지 비용 중에서 가장 큰 문제가 되는 경우는 네 번째일 것이다. 잘못된 요구사항 파악 및 구현으로 인하여 추가적으로 발생하는 유지보수 비용은 상당히 클 것으로 생각한다.

한 서비스(또는 프로젝트)를 여러 단위로 나뉘어 프로젝트를 진행할 경우 이와 같이 비용이 발생한다. 이 상태에서만 보아도 많은 비용이 발생하고 있는데, 각각의 업무 단위로 조직이 만들어질 경우 추가적인 비용이 또 발생하게 된다.

서비스(또는 프로젝트)가 개인 단위에서 조직 단위로 진행할 경우 각 조직의 성과와 정치적인 목적까지 개입하게 된다. 그러면서 추가적으로 발생하는 비용은 다음과 같은 부분이 있을 수 있다.

• 각 조직의 프로세스에 따라서 업무를 요청하고 업무를 진행한다. 새로운 프로세스를 익히고, 요청 문서를 많드는데 비용이 발생한다.
• 원할한 리소스 관리를 위하여 각 조직에서는 전체적인 리소스를 관리하기 위한 관리자가 필요한 상태가 된다.
• 조직이 물리적으로 분리되어 있는 경우가 일반적이기 때문에 협업을 위하여 이동, 전화, 이메일 작성에 비용이 소요된다. 이 같은 비용은 결과적으로 협업 횟수를 줄임으로써 요구사항을 잘못 이해하고 개발함으로써 추가적인 비용을 발생하게 한다.
• 서비스(또는 프로젝트)의 목표와 각 조직의 목표가 충돌하면서 추가적인 비용이 발생한다. 이 부분에 대해서는 잠시 후에 추가적으로 살펴보도록 하겠다.

이와 같이 업무 단위를 세부화화면서 업무 단위로 만들어진 조직까지 개입하게 되면 하나의 서비스(또는 프로젝트)를 진행하기 위하여 발생하는 협업 및 추가적인 비용은 급격하게 증가하게 된다. 이는 결과적으로 많은 사람을 투입했지만 생산성을 떨어트리는 결과를 가져온다.

원할한 리소스 관리를 위하여 각 조직에서는 전체적인 리소스를 관리하기 위한 관리자가 필요한 상태가 되면 여러 곳에 많은 관리자가 생겨나게 된다. 이와 같은 상황이 지속되다보면 가슴 아픈 이야기이지만 나 혼자 삽질하고 있는데 수 많은 관리자가 구경하면서 간섭하는 현상까지 발생한다. 즉, 고객의 가치를 위하여 일하는 시간과 사람보다 가치를 만들어내지 못하는 시간과 사람이 많아지게 된다.

이 같은 문제점을 해결한다는 명목하에 새로운 프로세스(방법론)가 도입되고, 값 비싼 도구를 구입하지만 결과적으로 실패하게 된다. 가장 큰 원인은 원론적인 부분을 해결하지 않은 상태에서 임시 방편의 해결책이기 때문이다. 이와 같은 상태의 가장 좋은 해결책은 업무 관련자들이 최대한 가까운 공간에서 일할 수 있도록 해야 하며, 각 조직의 정치적인 목적을 최대한 배제한 상태가 되어야 한다. 하지만 각 조직의 성과와 조직 관리를 해야 하는 입장에서는 쉽지 않은 선택이다.

조직의 목표와 서비스(또는 프로젝트) 목표와의 충돌

서비스의 목표는 고객에게 가치를 부여하면서 고객과 서비스가 같이 성장해 나가는 것이리라. 무슨 기술을 사용하고 방법론을 사용했느냐가 중요한 것이 아니라 서비스가 생존하는 것이 우선적인 목적이기 때문이다. 이를 실현하기 위해서는 서비스의 목표를 세우고 그 목표에 따른 우선 순위를 정하고 작업을 해나가는 것이 효율적인 방법이리라.

그런데 업무 단위가 세분화되고, 더 나아가 조직까지 세분화되어 있는 상태에서는 가장 중심에 있는 서비스의 목표와 각 조직의 목표가 충돌하는 상황이 발생한다.

목표가 충돌할 경우 각 조직의 목표보다 서비스 목표가 우선시 되어야 하지만 많은 경우 각 조직의 목표를 우선시 하는 상황이 발생할 가능성이 있다. 이 상태에서 평가 권한까지 서비스(또는 프로젝트)에서 가지고 있는 것이 아니라 각 조직에 부여되어 있을 경우 더 이상 서비스 성공이나 목표가 중요한 것이 아니다. 각 조직의 성과를 내기 위한 조직의 목표를 맞추는 것이 더 중요한 상태가 되어 버린다.

이 같은 상태가 되면 서비스에 대한 우선 순위를 조정하기 힘들 뿐만 아니라 고객에게 가치를 줄 수 있는 부분보다는 각 조직에 성과를 내는 데 집중하게 됨으로써 서비스의 품질은 점진적으로 떨어지는 결과를 초래하게 된다. 이는 장기적으로 서비스에 큰 위험요소로 작용한다.

서비스 목표와 각 조직의 목표가 충돌하고, 조직의 세분화가 지속될 경우 대부분의 조직이 "프로젝트가 서쪽으로 간 까닭은?"에서 이야기하는 아드레날리 중독증에 빠진 상태가 될 가능성이 높다.

다음은 아드레날린 중독증에 걸린 조직이 보이는 특징이다. 아마 익숙하리라.

1. 우선순위가 계속 변한다.
2. 어제까지 모든 결과물이 나왔어야 했다.
3. 시간이 언제나 부족하다.
4. 모든 프로젝트가 긴급하다.
5. 긴급한 프로젝트가 계속 쏟아진다.
6. 모두가 언제나 미친 듯이 바쁘다.

이런 조직에서 일하는 사람들은 전략적으로 사고하지 않는다. 무조건 긴급한 업무부터 처리한다. '긴급도'가 낮은 프로젝트는(장기적인 이익이 보장되어도) 일단 무시한다. 그러다가 갑자기 급해지면 그제야 돌아본다. 아드레날린 중독증에 걸린 조직은 계획보다 전력 질주가 최선의 방법이라 믿는다.

• 톰 드마르코, 팀 리스터외 지금, 프로젝트가 서쪽으로 간 까닭은

모든 개발자들이 바쁘게 일하고, 열심히 일하고 있지만 생산성은 떨어지고, 개발자는 지속적으로 더 필요한 상태가 된다. 이 상태에서 개발자를 더 충원한다고 개발자의 삶이 나아질 수 있을까? 오히려 더 바빠지면 바빠졌지 나은 상태가 되지 않을 것이다. 왜? 이 상태에서 개발자를 충원하는 것이 원론적인 해결책이 아니기 때문이다. 하지만 아드레날린 중독증에 대해서는 조직 구조 개편이나 새로운 관리자로 대체한다고 해결할 수 있는 쉬운 문제가 아니다.

조직은 응급 상태가 아닐 때 가장 효율적이라는 사실을 인정하는 관리자가 필요하다. 하지만 이런 인력 교체는 거의 불가능하다. 흔히 조직이 미친 듯이 바쁘기를 바라는 사람은 경영진이나 CEO이기 때문이다. 그들은 회사가 미친 듯이 바빠야 잘 돌아간다고 믿는다. 회사 경영진이 아드레날린 중독증에 걸렸다면 프로젝트 팀들도 금방 따라 걸니다.

• 톰 드마르코, 팀 리스터외 지금, 프로젝트가 서쪽으로 간 까닭은

경영진이나 CEO가 자진해서 변할 수 있을까? 이 같은 문제점을 이야기할 수 있는 사람은 몇 사람이나 될 것이며, 이야기한다고 진실되게 들을 수 있는 경영진은 얼마나 될까? 이에 대한 대답은 글쎄올씨다가 맞을 듯 하다.

공정한 평가를 하기 힘들다.

평가를 공정하게 한다는 것은 사실 불가능한 일이다. 평가와 인센티브는 오히려 하지 않는 것이 지식 근로자에게 있어서는 더 나은 선택이 아닐까 생각한다. 왜냐하면 지식 근로자의 업무를 정량적으로 판단하기 힘든 부분이 대부분이기 때문이다. 특히 소프트웨어 개발 업무는 정량화하기 더 힘든 영역에 속한다. 많은 사람들이 정량화를 시도하고 있지만 그 내면을 보면 대부분이 정성적인 사실이다. 따라서 평가를 아무리 잘 하더라도 불만이 나올 수 밖에 없다.

그런데 조직 구조가 세분화되어 있고, 여러 조직이 하나의 프로젝트에 투입되는 상황에서 평가를 어떻게 해야할까? 만약 서비스 또는 프로젝트의 PM에게 평가 권한을 준다면 PM은 각 업무에 대한 이해도가 있어야 하며, 각 업무에 대한 난이도와 품질에 대한 기준도 알고 있어야 할 것이다. 다른 대안은 각 업무 조직에게 평가 권한을 위힘하는 경우이다. 이 경우에는 팀원들이 각 프로젝트에서 어느 정도의 기여를 했는지를 판단해야 할 것이다. 이 경우 잘못할 경우 프로젝트에 대한 기여보다는 각 조직에 어느 정도의 기여를 했는지에 따라서 평가가 진행될 수 있다. 이럴 경우 앞에서 이야기한 것처럼 프로젝트 목표보다 조직의 목표를 우선시 하는 부작용이 발생한다.

어떤 방식을 취하더라도 문제가 있을 수 있으며, 이 두가지 방법을 조합해서 평가를 한다고 하더라도 조직장의 기준에 따라서 평가 기준이 달라질 수 밖에 없다. 평가에 대한 정답은 없다. 하지만 위와 같이 많은 문제점을 가진 상태라면 오히려 평가와 인센티브 지급이 생산성을 높이는 것이 아니라 저하시킨다. 이 상태라면 인센티브는 동일하게 지급하고, 평가는 개인의 역량을 강화하기 위한 목적으로 진행하는 것이 훨씬 더 효율적일 것이다.

이 글에서는 업무와 조직을 세분화할 경우 발생할 수 있는 문제점에 대하여 살펴보았다. 이 같은 문제점은 사람을 꾸준히 늘리더라도 생산성이 높아지는 것이 아니라 떨어트린다. 소프트웨어 개발회사에서 이 같은 문제점은 일정 수준 규모에서 급격하게 사람을 늘릴 경우 발생할 가능성이 높은 현상으로 판단된다.

지금까지 두편의 글에서 원인과 문제점에 대하여 살펴보았다. 그렇다면 "네가 생각하는 해결책은 뭔데?"라는 질문을 던질 것이다. 다음 글에서는 내가 생각하는 해결책에 대하여 다루도록 하겠다.

• 소프트웨어 개발자는 늘어나는데 생산성이 높아지지 않는 이유는?
• 업무, 조직 세분화로 인해 발생하는 문제점은?
• 웹 서비스 소프트웨어 개발 회사의 효율적인 조직 구조 및 관리

이 글은 내가 포털 회사에 4년 간 몸담고 있으면서 느꼈던 내 나름대로의 생각을 정리한 것이다. 이 글의 내용은 포털과 같이 하나의 소프트웨어를 지속적으로 관리하고 성장시켜 나가야하는 소프트웨어 개발 회사에 도움이 될 듯하다. 나는 지금까지 웹 에이전시, SI 회사에 몸담은 경험이 더 많은데 웹 에이전시, SI와 같이 특정 회사에 업무 의뢰를 받아 단기간에 개발을 완료해야하는 조직에는 적합하지 않을 수 있다. 이 글의 내용은 내가 몸담고 있는 조직의 의견과는 무관하다. 지금까지 소프트웨어 개발 업무를 진행하면서 느꼈던 내 나름대로의 생각을 정리한 것이다. 내가 이 글을 쓰는 가장 큰 이유는 내가 잘못 판단하고 있는 부분도 많을 것이기 때문에 그에 대한 의견을 받아보고 더 바람직한 모습에 대한 논의를 해보고자 함이다. 논리적으로 타당하지 않거나 근거가 부족하다고 생각하는 부분에 대해서는 가차없이 의견 마구마구 날려주기 바란다.

최근에 아이폰, 안드로이드폰이며 모바일 환경에 급격한 변화가 일고 있다. 지금 같은 추세라면 모바일 환경이 기존의 웹 시장을 무너트릴 기세이다. 하지만 생각하는 것만큼 너무 부풀려지는 감이 없지 않다. Yes24나 강컴과 같은 온라인 서점은 보면 아이폰, 안드로이드폰과 관련한 개발 서적이 베스트 10안에 들어와 있는 것을 보면 소프트웨어 개발 업계 종사자에게 얼마나 많은 관심사가 되고 있는지 알 수 있다.

이 같은 변화의 흐름 속에 소프트웨어 개발 회사들은 모바일 어플에 집중하고 있는 것이 사실이다. 기존에 자신들의 핵심 서비스에 집중하기에도 여력이 부족한데 모바일 어플에 대한 분산 투자라.. 기존에 세워져 있던 우선 순위 또한 뒤죽박죽되고 있는 현실이다. 정말 이렇게까지 해야할까? 정말 지금과 같은 시점에 우리 개발자들은 무엇에 집중해야 할까? 이런 고민을 안고서 스터디를 진행해볼까 한다.

이런 관점에서 봤을 때 아이폰이냐 안드로이드폰이냐는 중요하지 않다고 생각한다. 필요하다면 그 시점에 준비해서 진행해도 될 터이다. 소프트웨어 개발에 있어서 진정 중요한 것은 유행을 따라가는 것이 아니라 핵심에 집중하는 것이다. 아이폰, 안드로이드폰 개발자 급구 글을 통해서 많은 것을 느낄 수 있다고 생각한다.

내가 생각하는 스터디의 방향은 단순히 스터디에서 안드로이드에 대한 기술적인 부분만을 이야기하고 싶은 생각은 없다. 현재와 같이 스마트폰이 이슈인 현재 시점에 개발자인 우리에게 정말 필요한 것이 무언인지에 대한 논의도 해보고(물론 안드로이드 어플도 만들어 보겠죠.) 더 깊이 있는 논의를 하고 싶다. 이런 방향으로 스터디를 진행한다면 참석하고자 하는 사람들이 있을까? 현재 아이폰 스터디도 진행하기 위해서 준비하고 있는데 동시에 두개의 스터디를 진행하는 것도 좋은 생각일 듯하다. 관심이 있는 분들은 덧글을 남겨주면 좋겠다. 어느 정도의 관심이 있는지 살펴보고 스터디의 진행 여부를 결정할 생각이다.

1. 자신의 직군 => 기획자, 개발자 등등
2. 경력
3. 기타 의견

위 세가지 내용으로 덧글을 남겨 주면 앞으로 스터디의 방향을 정하는데 많은 도움이 될 듯하다.

2월 1일자로 조직 개편이 되면서 프로토타이핑을 담당하는 조직을 맡게 되었다. 새롭게 진행하는 업무가 기획자의 요청에 따라 발빠르게 프로토타이핑을 할 수 있어야 하기 때문에 최대한 빨리 대응할 수 있는 기반을 만들기 위한 준비 작업을 하고 있다. 처음 개발 작업을 위한 기반 프레임워크로 Ruby on Rails, Grails, Spring Roo 세 개가 물망에 올랐다. 각각에 대하여 개발 편의성, 학습 비용, 프로토타이핑 팀 개발자 및 사내 개발자들의 지식 수준, 향후 실 프로젝트에 적용할 때의 적용 가능성 등을 고려해서 Spring Roo로 진행하기로 잠정적으로 결정하고 준비하고 있다. 이에 대한 더 자세한 내용은 같이 일하고 있는 꿈꾸는 개발자님이 더 자세하게 부연 설명 해주리라 생각한다.

직접적인 기반 준비 작업은 꿈꾸는 개발자님이 진행하고 있지만, 옆에서 지켜보면서 느끼는 Spring Roo에 대한 감정은 일단 긍정적이다. 우리는 Spring Roo의 UI 관련 기능은 제외하고 Entity 영역만 사용하기로 결정했다. 포털의 성격상 UI에 대한 변화나 요구가 많고, Spring Roo를 통하여 생성되는 JSP가 만족스러운 수준은 아니었다. Spring Controller까지 자동 생성하고 싶었지만 Ben Alex에게 문의한 결과 Controller만 단독으로 생성할 수는 없다고 한다. Spring 3.0으로 버전업 하면서 @MVC가 잘 만들어져 있어 Controller 만들기는 어렵지 않게 해결하고 있다. 이후 이 작업이 귀찮으면 Controller만 생성할 수 있는 add-on을 하나 만들어도 좋을 듯 하다.

Spring Roo를 적용하면서 가장 만족할만한 부분은 코드 생성 방식이다. Introduction To Spring Roo 1.0.0 문서에서도 설명하고 있지만 Passive Generation과 Active Generation을 모두 지원하고 있다는 것이다.

이 같은 코드 생성 방식은 roo shell을 이용하여 소스 코드를 생성하는 것도 가능하지만, 도메인 모델 클래스를 직접 변경하더라도 관련된 aj 소스가 자동으로 변경되는 것을 확인할 수 있었다. 예상하지도 못했던 부분까지 고려해서 개발되었다는 것을 보고서 놀라지 않을 수 없었다. 이 같은 기능을 지원하기 때문에 JPA Annotation과 Validation Annotation만 알고 있다면 굳이 roo shell을 사용하지 않고 도메인 모델 클래스에서 직접적인 수정이 가능하다. 이 같이 동작하는 방식에 대해서는 Spring Roo 1.0.0 Technical Deep Dive 문서에서 좀 더 구체적으로 파악할 수 있다.

아직 add-on까지 만들어 보지 못하고 Spring Roo에서 제공하는 샘플 add-on 프로젝트를 생성하고 배포해 봤는데 생각보다 쉽게 개발할 수 있을 듯 하다. 이미 add-on을 쉽게 개발할 수 있도록 roo shell에서 샘플 프로젝트까지 제공하고 있어 이 프로젝트를 참고해서 만든다면 어렵지 않게 개발하는 것이 가능하리라.

이 참에 지난 번에 만들었던 Spring Batch Monitoring System을 Spring Roo 기반으로 만들어보면 어떨까라는 생각을 했다. "Spring Batch Log야 단순 조회용도니까 지금처럼 Spring Jdbc 기반으로 개발하면 되고, 그 외의 User, Role, 통계 기능에 대해서는 Spring Roo를 적용가능하지 않을까?", "기존 Legacy Project에 Spring Roo를 적용하기 어렵지 않을까?"라는 생각으로 시도해봤는데 생각보다 쉽게 Spring Roo를 통합할 수 있었다. 물론 아직까지 기존 Legacy 테이블까지 매핑해서 개발하는 단계까지는 가지 않았지만 기존 Legacy Project에 쉽게 통합해서 일부만이라도 Spring Roo 기반으로 개발하는 것이 가능하다는 것을 확인할 수 있었다. Spring Roo에서 강조해서 이야기하고 있듯이 Spring Roo는 상당한 유연성을 가지고 있다는 생각이 들었다.

아직 프로토타이핑 업무에 직접 적용한 단계는 아니고 준비 단계이지만 만족할만한 수준이라고 생각한다. 사내 프로토타이핑 업무와 Spring Batch Monitoring System에 적용해 나가면서 Spring Roo의 허와 실에 대해서 지속적으로 공유해보도록 하겠다.

3개월간 독서 통신 신청해 진행하고 있는데, 대부분의 책이 비슷한 내용이라 좀 재미가 없고 따분하다는 생각이 들었다. 그래서인지 이번 달에는 마감을 임박해서야 책을 읽고 있다. 역시나 먼저 읽은 한 권의 책은 큰 의미를 가지지 못하고 읽었다. 그런데 "세상을 가질 수 있는 사람 없는 사람"은 나에게 많은 것을 느끼게 해주고 있다. 새해를 맞아 새롭게 세웠던 계획과 마음가짐은 조직 개편과 몇 가지 상황에 부닥치면서 물거품이 되었는데 이 책으로 인해서 다시 한번 되돌아 볼 수 있는 계기가 되었다.

이 책을 읽으면서 다시 한번 나의 목표를 검토해봐야겠다고 생각한 부분이 있어서 공유해 본다. 올 해 나의 목표 중에 하나는 책 100권 읽기이다. 지금까지 틈 날때마다 책을 읽고 있어서 100권이 가능할 듯도 하다. 그런데 이 책에 독서와 관련하여 다음과 같은 내용의 글을 읽고서 나의 책 읽는 습관을 다시 한번 되돌아 보게 되었다.

이 책에서는 독서에 대하여 다음과 같아야 한다고 이야기하고 있다.

첫째는 책을 읽기 시작하면 끝까지 읽을 것,
둘째는 책을 완전히 이해하기 전엔 다 읽었다고 생각하지 말 것,
셋째는 온 정신을 기울여 읽으라는 것이다.

위 세 가지 중에서 잘 지키고 있는 습관은 첫째이다. 둘째와 셋째는 영 꽝인 듯하다. 책을 제대로 이해하지도 못하면서 10권, 100권을 읽는 것이 중요할까? 단 한권이라도 제대로 이해하는 것이 더 중요하리라. 그러기 위해서는 책을 읽을 때 맑은 정신으로 온 정신을 집중해 읽는 것이 중요하리라.

소프트웨어 관련 서적 또한 똑같다. 배우고자하는 기술과 관련한 서적을 읽는다고 해서 그 기술을 사용할 수 있는 것은 아니리라.

PS. 이 책이 쓰여진 시대는 19세이다. 그럼에도 불구하고 지금 시점에 읽을 만한 충분한 가치가 있는 책이다. 단점이라면 번역서에 오타가 너무 많다.

나는 아키텍처를 깊이 있게 공부하지도 않았으며, 깊이 있는 고민을 한 것도 아니다. 프로젝트를 시작하거나 각각의 상황에 따라서 어떤 모습이 좋을까를 고민하는 형태라고 할까? 물론 대형 프로젝트를 주도해서 개발한 경험이 없기 때문에 아키텍처가 얼마나 중요한 것인지 피부로 느끼고 있다고 이야기할 수도 없다. 하지만 아키텍처에서 정말 중요한 것은 처음에 만들어진 아키텍처는 시간의 흐름에 따라서, 시장의 상황에 따라서 변화 발전해야 한다는 것이다. 최근의 아이폰 열풍이 불면서 모바일 환경에 대한 관심이 높아지고 있는 현 시점이 새로운 아키텍처에 대한 고민을 해야 하는 시점이 아닌가 생각한다.

최근 GWT, Spring Roo, Rest에 대하여 고민하다보니 다양한 방식의 아키텍처가 가능할 수 있겠다는 생각이 든다. 더불어 웹 뿐만 아니라 모바일까지 고려한 소프트웨어 개발에 대하여 고민할 때라고 생각한다. 물론 웹과 모바일을 동시에 고려하지 않는 단독 애플리케이션이라면 상관 없겠지만 대부분의 웹 애플리케이션이 모바일을 고려할 것으로 생각한다. 과거에는 모든 거래가 오프라인을 통하여 이루어졌지만 지금은 오프라인 + 온라인(웹 주도), 온라인(웹 주도) 형태로 발전했지만, 앞으로는 오프라인 + 온라인(웹 + 모바일), 온라인(웹 + 모바일), 온라인모바일) 형태로 발전할 가능성이 크기 때문이다. 기존에 웹 주도의 온라인 회사들이 큰 비용 없이 모바일 환경을 지원할 수 있느냐가 현재 온라인 회사들의 생사를 결정 지을 수도 있을 듯하다. 물론 초반에 상당한 비용을 들여서 모바일 환경을 지원할 수 있겠지만 뒤따르는 유지보수 비용을 고려한다면 초반 아키텍처가 중요할 것이다. 초반에 제대로 된 아키텍처를 가져가지 않을 경우 막대한 유지보수 비용을 치를 수 밖에 없을 것이다. 사실 이런 내용을 아키텍처라고 이야기하는 것이 맞는지 모르겠지만 적절한 단어가 생각나지 않아서 사용한 것도 있다.

지금까지 국내 대부분의 온라인 애플리케이션은 웹이라하는 하나의 클라이언트를 고려해서 개발해왔다. 이 같이 하나의 클라이언트를 고려하는 상황에서도 상당한 유지보수 비용을 지불하고 있는데, 웹과 다양한 모바일 환경을 고려해야 하는 상황이 되면 이 때 발생하는 중복코드와 유지보수 비용은 생각하기도 끔찍하다. 어쩌면 이 같은 환경 변화로 인해서 아키텍처, 설계, 품질에 대한 중요성이 부각될 수도 있겠지만 이를 느끼고 실행하는 회사는 얼마나 될 것인지 의문이다. 만약 다양한 클라이언트 환경을 고려한다면 해당 서비스의 핵심 도메인에 집중해야 할 것이다.

핵심 도메인 영역을 얼마나 정교하게 개발하느냐에 따라서 새로운 클라이언트가 추가되더라도 큰 변화 없이 대응할 수 있을 것이다. 그렇다면 핵심 도메인 영역을 어떻게 다양한 클라이언트에 제공하는 것이 좋을까? Spring Roo를 적용하면서 Rest 방식에 관심을 가지고 문서를 찾다보니 Restlet, a RESTful middleware for GWT, GAE and Android 문서를 보게 되었다. Restlet, a RESTful middleware for GWT, GAE and Android 문서에서 얻은 아이디어와 Spring MVC 3.0부터 지원하고 있는 ContentNegotiatingViewResolver API를 결합해 사용한다면 다음과 같은 형태로 다양한 클라이언트를 지원하는 것이 가능할 것이라는 생각이 들어 테스트를 진행해 봤다.(ContentNegotiatingViewResolver에 대한 더 자세한 사용 방법은 Spring 3.0 Web MVC and JSON) 문서에서 확인할 수 있다.)

첫 번째 방법은 외부와 통신하는 핵심 도메인 Controller는 하나이고, 요청 URL의 확장자에 따라 다른 데이터를 제공하는 형태이다.

두 번째 방법은 외부와 통신하는 핵심 도메인 Controller는 하나이고, 요청 Content Type에 따라 다른 데이터를 제공하는 형태이다.

테스트한 결과는 예상하는 데로 지원할 수 있겠다는 생각이다. 물론 실무에 적용하면서 많은 문제에 봉착하겠지만(벌써 Spring Roo를 적용하면서 문제가 생겨 해결책을 찾았다.) 그런 문제들이 하나씩 해결해 나가면 될 것이다.

위 두가지 모두 외부와 인터페이스를 위한 Controller는 하나이지만 확장자와 요청 Content Type에 따라 다른 데이터를 제공하기 때문에 중복 코드를 만들지 않고 다양한 클라이언트와의 통신이 가능하다. 물론 이 같은 구조가 가능하기 위해서는 각 Controller 뒤에 잘 만들어진 핵심 도메인이 존재해야 할 것이다.

물론 모든 API를 위 구조로 통일하는 것이 힘들 것이다. 하지만 대부분의 API(90%는 되지 않을까? 너무 긍정적인가?)는 위와 같은 구조로 개발하는 것이 가능할 것이다. 기능에 따라 예외적인 경우가 발생한다면 예외적인 상황이 발생하는 부분에 대해서만 Controller를 분리하면 될 것이다. 클라이언트 수가 증가할 때마다, 요구사항이 기존과 조금 다를 때마다 새로운 Controller를 추가한다면 중복 코드가 발생할 가능성이 높으며, 유지보수 비용 또한 증가할 것이다.

새로운 클라이언트가 추가되고, 새로운 요구사항이 발생하더라도 최대한 중복 코드를 만들지 않고, 하나의 API를 이용하여 요구사항을 만족시키도록 노력해보자. 그래도 해결 방법이 없다면 그 시점에 추가하는 것이 적절한 선택이 되리라. 이 같은 방식으로 접근하는 것이 장기적으로 개발자의 삶에 여유를 가져다 줄 수 있는 환경이 될 것이라 확신한다. 현재의 편함을 위해서 미래의 불편함을 만드는 오류는 범하지 말았으면 좋겠다.

• 소프트웨어 개발자는 늘어나는데 생산성이 높아지지 않는 이유는?
• 업무, 조직 세분화로 인해 발생하는 문제점은?
• 웹 서비스 소프트웨어 개발 회사의 효율적인 조직 구조 및 관리

지금까지 두 번의 글을 통하여 조직이 커지면서 생산성이 떨어지는 이유에 대하여 살펴보았다. 첫 번째 글에서는 생산성이 떨어지는 가장 큰 원인이 업무와 조직의 세분화라고 이야기했다. 두 번째 글에서는 이 같은 세분화가 어떠한 문제점을 가지고 있는지는 지난 글에서 다루었다.

그렇다면 소프트웨어 개발 회사는 어떤 형태의 조직 구조와 업무 형태를 가져야할까? 지금부터 내가 생각하는 웹 서비스 소프트웨어 개발 회사의 조직 구조 및 업무 형태에 대한 해결 방법을 제시해보도록 하겠다. 이 해결 방법은 지금까지 나의 경험을 바탕으로 이러한 방향으로 나아가는 것이 바람직하지 않겠느냐는 의견을 제시하는 것이다. 글을 읽으면서 내가 생각하는 방향이 가지는 문제점과 또 다른 대안에 대해서 많은 의견을 주면 좋겠다.

핵심 업무 중심으로 조직이 확대

모든 회사는 회사를 유지하는데 가장 핵심이라고 할 수 있는 업무가 있다. 웹 서비스 소프트웨어 개발 회사라면 회사의 중심에 서비스(또는 프로젝트)가 있을 것이다. 웹 서비스 개발 회사가 성장하면서 급격하게 조직이 커지는데 이 때 중심에 두어야 할 것은 서비스이며, 서비스를 중심으로 조직 구조가 확대된다.

서비스를 중심으로 조직을 확대하다 보면 각 서비스에서 공통적으로 발생하는 문제와 해결책이 빈번하게 발생한다. 이 때문에 업무의 효율화라는 명목과 효율적인 인력 관리를 통한 비용 절감이라는 명목으로 이 업무를 전담하기 위한 조직들이 서서히 등장하기 시작한다.

이 시점이 조직이 커지면서 조직을 재편할 때 가장 중요한 시점이라고 생각한다. 이 시점에 공통 업무를 위한 새로운 조직을 만드는 것에 신중해야 한다. 한번 만들어진 조직을 없애고 새로 재편하기 위해서는 조직을 만들 때보다 몇 배의 비용과 고통이 따르기 때문이다. 이 시점에 조직을 각 업무별로 세분화하고, 공통 작업 단위로 세분화할 경우 발생하는 문제점에 대해서는 앞에서 살펴봤다.

그렇다면 어떤 방법이 가능할까? 나의 관점으로 봤을 때 하나의 서비스를 담당하는 조직이 커지고 공통 업무가 발생한다고 하더라도 서비스의 핵심 업무 단위에 대해서는 세분화하지 않는 전략을 가져가야 한다. 예를 들어 하나의 웹 서비스를 개발하기 위하여 필요한 핵심 업무 단위는 PM, 개발자, 디자이너, DBA, QA라고 판단한다면 이 업무 영역에 대한 세분화는 하지 않는 것이 바람직하다. 또한 각 구성원간의 유기적인 협업이 필요한 경우에도 분리하는 것은 바람직하지 않다. 이 영역에 대한 분리는 신중하게 판단해 마지막 단계에서 분리하는 것이 바람직할 것이다.

조직이 커지면서 조직을 재편할 때 가장 중심에 두어야 한다고 판단하는 부분은 서비스에 중심을 두고 의사 결정을 하는 조직이 만들어져야 한다는 것이다. 조직을 키우더라도 서비스를 중심으로 조직이 커지고, 수직 구조가 만들어 지더라도 서비스를 기준으로 만들어 지는 것이 바람직하다..

서비스 중심으로 조직 구조를 가져갈 경우 각 조직에서 공통적으로 발생하는 문제를 해결하기 위한 방안으로 별도의 조직을 만들고자 하는 경우가 발생한다. 이 같은 요구는 항상 발생하는 것이 아니라 특정 상황에 따라 가끔 발생하는 경우가 일반적이다. 따라서 문제가 발생하는 시점에 해당 문제를 해결하기 위하여 일시적으로 조직(TF 형태)을 만들거나, 만약 공통 문제를 해결하는 상시 조직이 있다면 일정 기간 동안 해당 조직에 참여하여 개발을 진행한 후 원 조직으로 복귀하거나 공통 모듈에 대한 지속적인 지원이 필요하다면 지원 조직으로 남는 형태를 취해야 할 것이다.

예를 들어 A 서비스를 개발하면서 얻게된 지식을 전사적으로 사용하는 것이 좋겠다고 판단된다면 A 서비스에 참여했던 개발자가 사내 프레임워크 개선 조직에 참여하여 해당 기능을 사내에서 범용적으로 사용할 수 있도록 개발하고, 다시 원 조직으로 복귀하는 구조이다.

이와 같이 조직을 유지해야 하는 이유는 지원 업무를 담당하는 조직을 최대한 작은 규모로 유지하기 위해서이다. 지원 업무를 담당하는 조직이 커질 경우 지원 조직은 자체적으로 성과를 만들어야 하는 상황이 발생하는 경우를 종종 본다. 자체적인 성과를 내기 위하여 만들어진 결과물은 실질적으로 각 서비스 조직에서 필요하지 않은 경우가 많다. 그 이유는 지원 조직의 사용자라고 할 수 있는 각 서비스 조직의 요구사항을 수렴하기 보다는 자신의 조직에 성과가 클 것으로 보이는 결과물을 만들어 내기 때문이다. 이와 같이 만들어진 결과물은 서비스에 적용되어야 최종적으로 성과를 낼 수 있다. 따라서 지원 조직은 자신들이 만든 결과물을 서비스에 적용하려는 시도를 끊임없이 시도하게 된다. 이 같은 상황에서 서비스의 목표와 지원 조직의 목표가 충돌하는 상황이 발생한다. 이 같은 상황이 발생하면 어느 조직이 힘이 세냐에 따라서 적용 여부가 결정되는 구조로 치닫게 된다.

따라서 진정 사용자에게 가치를 만들어내는 핵심 업무를 기준으로 조직이 커지는 것이 바람직할 것으로 판단한다. 이 상태에서 특정 문제를 해결하기 위한 지원 조직은 임시 조직으로 유지하거나, 상시 조직으로 유지한다면 최소한의 인력으로 유지하는 것이 바람직하다.

서비스 중심으로 조직이 발전하면 조직 구조가 수직 구조에서 수평 구조로 발전하는 것이 가능하다. 지금까지 국내 거의 모든 회사의 조직 구조는 수직 구조이다. 그러나 수직 구조는 조직이 커지면서 의사 결정자의 단계가 증가하고, 의사 결정자의 수가 많아짐으로써 의사 결정 속도를 더디게 한다. 특히 웹 서비스와 같이 사용자의 요구에 발빠르게 대응하고, 빠르게 변화하는 기술에 대응하기 위해서는 조직이 커지고, 서비스 복잡도가 증가하더라도 빠른 의사 결정을 요구하고 있다. 이 같은 요구에 대응하기 위해서는 수평 구조로 유지하는 것이 더 빠른 의사 결정을 하고 사용자에게 가치를 부여하는 일에 집중할 수 있다.

리소스의 효율적인 사용을 하려면..

각 업무별로 조직 구조를 가져가는 또 하나의 이유는 리소스를 효율적으로 사용한다는 명목이 있다. 한 명의 개발자가 한 서비스를 전담하고 있을 경우 우선 순위가 높은 서비스 또는 프로젝트가 발생했을 때 유연하게 대처하기 힘들다는 것이다. 또 하나는 HTML 마크업이나 디자인 작업과 같이 한 서비스에 100%를 투입할 작업 분량이 되지 않는 경우이다. 이 같은 상황에 대응하기 위하여 업무 단위로 조직을 분리하는 것이 효율적인 리소스 관리가 가능하다고 생각한다.

첫 번째 우선 순위가 높은 서비스에서 새로운 프로젝트가 발생했을 때 어떻게 하면 유연하게 대처할 수 있을까? 업무 단위로 조직을 분리한다고 해서 이 문제를 해결할 수 있을까? 나는 없다고 생각한다. 업무 단위로 조직을 분리하더라도 새로운 업무가 발생하면 똑같은 상황이 발생한다. 따라서 내가 생각하는 해결책은 다음과 같다.

먼저 각 서비스별로 조직 구조를 만들고, 서비스를 운영, 개선하기 위하여 상시적으로 필요한 인원의 적정 규모가 어느 정도인지를 결정한다. 인원 규모는 서비스를 운영하면서 어느 정도가 적정 수준인지를 판단하는 것이 바람직하다. 이와 같이 상시 업무를 담당하기 위한 인원을 제외한 사람들은 별도의 인력풀처럼 관리한다. 이 인력풀에 속해 있는 사람들은 우선 순위에 따라서 자신이 하고 싶은 서비스 또는 프로젝트에 참여하여 업무를 진행하는 방식을 취한다.

인력풀이라고 이야기하니 SI 할 때의 인력 시장과 같은 것 아니냐고 부정적으로 생각하는 사람들도 많이 있다. 하지만 내가 생각하는 인력풀은 인력 시장과는 다르다. 인력풀에 속해 있는 사람들은 자신이 원하는 서비스 또는 프로젝트를 선택할 수 있는 권한을 주고, 서비스 또는 프로젝트가 완료되면 상시 업무를 진행할 것인지, 새로운 서비스 또는 프로젝트를 진행할지에 대한 선택권을 주어야 한다.

한 서비스에서 안정적으로 상시 운영 업무를 하는 것에 따른 장,단점이 있듯이, 인력풀에서 계속해서 새로운 업무를 맡게 되는 사람들에게도 충분한 보상이 주어져야 할 것이다. 예를 들어 하나의 프로젝트가 완료되었는데 바로 다른 프로젝트에 투입하는 형태처럼 하나의 부속품처럼 취급되는 것이 아니라 하나의 프로젝트를 완료하면 자신의 역량을 개발할 시간과 쉴 수 있는 여유 시간에 대한 보상이 뒤따라야 할 것이다.

또한 이 같은 구조를 지속적으로 유지하고 성장시키기 위해서는 서비스 조직, 인력풀 조직, 지원 조직 사이에 유기적인 업무 순환이 있어야 한다.

두 번째는 각 서비스에 한명에게 할당할 업무가 100%가 되지 않는 경우이다. 따라서 한 명이 여러 개의 서비스에 참여해야 효율적인 활용이 가능할 것으로 생각한다.

그런데 정말 이와 같이 관리하는 것이 리소스를 효율적으로 사용하는 방법일까? 한 측면으로 본다면 맞는 맞일 수 있겠지만, 별도의 조직을 만들어 조직을 관리하고 유지하는 비용을 생각한다면 이 또한 만만치 않은 비용이 발생한다. 또한 조직이 분리됨으로써 발생하는 협업 비용 또한 고려해야 할 것이다. 그렇다면 어떻게 하는 것이 합리적인 방법일까? 나 또한 이 부분에 대하여 명확한 해결책을 제시하기는 힘들지만 조직을 분리하는 것만이 좋은 해결책은 아니라고 생각한다.
이상적이기는 하지만 내가 생각하는 첫 번째 해결책은 가능한 한명이 하나의 서비스를 담당하도록 하는 것이다. 한 명이 여러 개의 서비스나 프로젝트를 담당하는 것은 서비스나 프로젝트 간의 이동 비용이 발생하기 때문에 한 명이 여러 개의 서비스를 담당하는 것은 효율적인 방법은 아니다. 하지만 동시에 여러 개의 서비스를 담당하는 상황이 아니라면 괜찮다고 생각한다. 한 명이 여러 개의 서비스를 담당하지만 시간 상으로 겹치는 부분이 많지 않다면 충분히 효율적인 작업이 가능하리라.

각 업무에 대한 역량 강화는?

업무 단위로 조직을 분리하는 이유 중의 하나는 역량을 강화하기 위한 목적이라고 이야기한다. 그런데 정말 업무 단위로 조직을 분리하면 전체적인 역량이 강화될까? 개인의 역량을 강화하는 것이 조직 구조에 따라 달라질까? 물론 일정 부분 영향을 미칠 수 있겠지만, 개개인의 역량 향상에 가장 큰 영향을 미치는 것은 자신의 역량을 강화하기 위한 개인의 노력이다. 개인의 노력이 부족한 사람은 어떤 형태의 조직이 되더라도 큰 효과는 볼 수 없으리라.

업무 단위로 조직을 분리할 경우 오히려 자신의 업무에 대한 이해도와 지식은 높아질 수 있겠지만, 다른 업무에 대한 지식과 이해도는 상당히 낮아지는 것을 느낄 수 있다. 최근 전문화라는 이유로 업무를 세분화해서 자신의 분야에만 관심을 가진다면 이것이 진정 전문가로서 성장할 수 있는 길일까? 진정 전문가로서 성장하려면 자신의 전문 분야 지식도 필요하지만 이와 더불어 서비스(또는 프로젝트)의 전반적인 모습을 같이 볼 줄 알아야 하며, 다른 분야에 대한 지식과 이해도도 필요하다고 생각한다. 그렇게 되었을 때 다양한 분야에 대한 고려가 가능할 것이기 때문이다. "사용자의 입장은 고려하지 않고, 자신의 전문 분야에 빠져 역량만 강화하고 있다면 이것이 진정 전문가의 올바른 길일까?"라는 의구심을 가져본다.

업무 단위로 조직을 분리하던 서비스 단위로 조직을 분리하던 개인의 역량을 강화한다는 것은 쉽지 않은 일이다. 진정 회사가 개인의 역량 강화를 통하여 전반적인 품질 향상을 바란다면 멘토링을 적극 활용하고, 이와 같은 멘토링에 대해서는 개인 성과와 역량에 반영하여 모든 구성원이 적극적으로 참여할 수 있도록 해야 한다. 국내 대부분의 회사를 보면 개인 역량을 강화하고, 교육을 하는 것이 정말 중요하다고 이야기하지만 실상을 보면 신입 사원을 키우고 사원의 역량을 강화하는데 인색한 것이 사실이다. 정말 개개인의 역량 강화가 서비스 품질 향상에 중요하다는 판단을 한다면 단기적인 성과 위주의 전략이 아니라 장기적으로 인내심을 가지고 정책을 펴야할 것이다. 개인의 역량 강화는 단기간에 비용을 투자한다고 해서 해결되는 것이 아니다.

평가는 어떠해야 하는가?

앞의 글에서도 잠시 언급했지만 서비스 기반으로 조직 구조를 가져갈 경우 평가는 서비스 단위로 하는 것이 바람직하다. 하나의 서비스에 여러 업무가 혼재되어 있기 때문에 각각의 개인을 평가하는 것이 힘들 뿐더러 팀워크를 위해서 좋지 않은 방법이다. 업무에 대한 성과는 개인이 아니 서비스를 기준으로, 서비스 지원 조직은 서비스에 대한 기여도를 기준으로 평가하는 것이 바람직할 것으로 판단한다. 물론 내가 생각할 때 평가는 개인이나 조직에 대한 동기 부여 효과는 크지 않을 것이라 생각하지만 그래도 해야 한다면 개인보다는 조직 단위로 하는 것이 불합리한 부분을 최소한으로 줄일 수 있다고 생각한다.

개인에 대한 평가는 개인의 역량에 대한 평가가 되어야 한다. 서비스 기반 조직이고 수직 구조에서 수평 구조로 조직 구조를 유지한다면 과거처럼 좀 더 높은 관리자로 올라가는 것이 승진의 개념이 될 수 없다. 수평 구조에서는 상위 조직장으로 올라가는 것이 의미 있는 것이 아니라 자신의 역량 레벨을 높이는 것을 승진의 개념으로 보아야 할 것이다. 각 업무별 역량에 대한 기준을 세우고 이 기준에 따라서 개인별로 역량 레벨을 평가하는 방식이 되어야 할 것이다.

피터 드러커는 프로페셔널의 조건에서 조직에 대한 공헌의 세 가지 영역에 다음과 같이 이야기하고 있다.

'공헌'은 여러 가지를 의미한다. 모든 조직은 세 가지 주요 영역에서 성과를 올리 필요가 있다. 1) 직접적인 결과를 산출하고, 2)가치를 창출하고 재확인하며, 3)인재를 육성하는 것이 그것이다. 만일 이 세 가지 영역 가운에 어느 하나라도 성과를 달성하지 못한다면, 그 조직은 썩어서 없어지고 말 것이다. 그러므로 조직에 몸담고 있는 모든 지식 근로자의 공헌 활동은 이 세 가지 영역과 연결되어 있어야만 한다. 한편 세 영역의 상대적인 중요도는 조직의 필요에 따라 그리고 지식 근로자 개개인에 따라 상당히 많이 달라진다.
– 피터 드러커, 프로페셔널의 조건 중에서..

위 글에서 피터 드러커가 이야기하고 있듯이 지식 근로자를 평가하고 판단할 때 세 가지 측면에서 회사에 대한 기여도를 판단해야 할 것이다. 하지만 많은 회사에서 "1)직접적인 결과를 산출하고"에 해당하는 직접적인 성과에만 집중하는 경향이 있다. 이와 같이 성과에만 집중하게 되면, 회사 전반적인 분위기가 단기적인 성과에만 집착하게 되는 경향이 있다. 또한 성과 위주의 평가가 우선시되는 많은 조직을 보면 서비스를 안정적으로 운영하는 것보다 새로운 기능을 추가하는 것에 더 큰 가치를 부여하는 경향이 있다. 새로운 결과물을 만들어 내는 것이 성과 측면에서는 더 큰 성과로 보이기 때문이다. 하지만 이 같은 현상은 결과적으로 고객의 목소리에 귀기울이기 보다는 각 조직의 성과에 이익이 되는 업무를 우선시하는 경향이 발생하게 된다. 따라서 조직과 개인을 평가할 때 직접적인 성과 뿐만아니라 "2)가치를 창출하고 재확인하며, 3)인재를 육성" 부분에 대한 기여도 고려해야 할 것이다.

지식 근로자인 우리는 어떻게 대응해야 하는가?

내가 위에서 제시하는 형태로 조직 구조를 가져갈 경우 지금까지 일하던 방식과 다르기 때문에 많은 부분에서 혼란스러움을 느낄 수 있다. 이 같은 변화에 대응하기 위하여 우리 지식 근로자들은 어떻게 대응해야 할까?

지금까지 수직 구조에서는 위에서 시키는 일만 열심히 하고, 조직이 움직이는 데로 따라가기만 하면 되는 수동적인 자세를 가지고 있는 것이 사실이었다. 하지만 수평 구조로 변경된다면 지금보다는 좀 더 적극적으로 자신의 의견을 개진하고, 자신의 역량을 강화하기 위하여 더 많은 노력을 해야할 것이다.

이 같은 노력은 회사를 위한 것이 아니라 결과적으로 우리 자신을 위한 것이다. 좀 더 효율적으로 일함으로써 더 좋은 품질의 서비스를 만들어 회사에 기여하는 바도 크지만 궁극적으로 우리가 시간적인 여유를 가질 수 있으며, 이런 여유 시간을 통하여 좀 더 재미있고, 의미 있는 일들을 해나갈 수 있을 것이기 때문이다.

마치며..

지금까지 세 번에 걸쳐서 글을 작성했다. 이 번 글에서 제시하고 있는 것처럼 조직 구조를 바꾸고, 평가 제도를 개선한다고 지금까지 비효율적이었던 부분이 곧바로 효율적인 구조로 바뀐다고 생각하지 않는다. 내가 세 번의 글을 통하여 이야기하고 싶었던 것은 업무 세분화, 전문화로 인해 비효율적인 부분에 대하여 다룬 것 뿐이다. 업무와 조직을 너무 세분화하는 것은 많은 문제점을 가지고 있기 때문에 신중해야 한다는 것이며, 새로운 방법으로 접근할 수도 있다는 것이다.

실질적으로 업무의 효율화와 생산성을 극대화하기 위한 더 좋은 방법은 바로 우리 개개인의 마음 가짐이다. 어떤 조직 구조를 가지던, 어떤 평가 체계를 가지던 간에 같은 목표와 비전을 가지고 업무에 임할 수 있다면 크게 중요하지 않다. 각 조직의 성과 위주가 아니라 정말 사용자에게 가치를 만들어 내는 것에 집중할 수 있는 환경이라면 어떤 조직 구조라도 상관 없다. 하지만 이런 상태를 유지하는 것은 쉽지 않다. 특히 조직이 커지면서 이와 같은 초심을 유지하는 것은 더더욱 힘들어지게 된다. 이런 상황에서 좀 더 사용자 지향적이고, 목표 중심적인 조직 구조 형태가 어떤 것인지에 대하여 언급했다.

• 소프트웨어 개발자는 늘어나는데 생산성이 높아지지 않는 이유는?
• 업무, 조직 세분화로 인해 발생하는 문제점은?
• 웹 서비스 소프트웨어 개발 회사의 효율적인 조직 구조 및 관리

이 글은 내가 포털 회사에 4년 간 몸담고 있으면서 느꼈던 내 나름대로의 생각을 정리한 것이다. 이 글의 내용은 포털과 같이 하나의 소프트웨어를 지속적으로 관리하고 성장시켜 나가야하는 소프트웨어 개발 회사에 도움이 될 듯하다. 나는 지금까지 웹 에이전시, SI 회사에 몸담은 경험이 더 많은데 웹 에이전시, SI와 같이 특정 회사에 업무 의뢰를 받아 단기간에 개발을 완료해야하는 조직에는 적합하지 않을 수 있다. 이 글의 내용은 내가 몸담고 있는 조직의 의견과는 무관하다. 지금까지 소프트웨어 개발 업무를 진행하면서 느꼈던 내 나름대로의 생각을 정리한 것이다. 내가 이 글을 쓰는 가장 큰 이유는 내가 잘못 판단하고 있는 부분도 많을 것이기 때문에 그에 대한 의견을 받아보고 더 바람직한 모습에 대한 논의를 해보고자 함이다. 논리적으로 타당하지 않거나 근거가 부족하다고 생각하는 부분에 대해서는 가차없이 의견 마구마구 날려주기 바란다.