최근 Git이나 Mercurial 과 같은 분산제어 방식의 소스 제어 제품을 무조건 맹신하고 찬양하거나 분산제어 방식보다 중앙집중형 소스제어 방식을 무조건 배척하는 현상이 일부 나타나고 있다.

리누스 토발즈(Linus Tovalds)와 같은 공산주의(Communism) 사상의 이상을 강조하는 철학이 담긴 Git은 GitHub.com을 통해 소스 코드를 공유함으로서 오픈 소스 진영에 매우 발전적인 기여를 하고 있음은 확실하다. 리누스 토발즈(Linus Tovalds)가 만든 것이라 그런지 훨씬 더 주목받고 있는 것 같다.

중앙집중 소스제어와 분산제어 소스제어 방식은 그 원칙과 근본적인 가치에 차이가 있는, 방법론으로 접근해야 할 것이다. 따라서 각 소스 제어의 방식마다 특징과 장단점이 있으며 ‘좋은 게 좋은 것 아닌가~’ 라는 간단한 답을 얻길 바란다.

필자는 중앙집중 소스제어와 분산제어 소스제어 방식의 장단점을 5가지의 관점에서 살펴보자. 중앙집중 소스제어(이하 중앙제어 방식)은 분산제어 소스제어 방식을 사용하는 몇 가지 소프트웨어를 제외한 대부분으로 보면 된다.

  • 중앙통제력
  • 정책주입력
  • 분기용이성
  • 사용편의성
  • 성능

그 외에 도움이 될만한 위키피디아(Wikipedia) 링크를 참고하기 바란다.

내용상 비교하는 대상은 중앙제어 방식은 ‘팀 파운데이션 서버(Team Foundation Server)’와 SVN을 많이 참조하였고, 분산제어 방식은 ‘Git’을 많이 참조하였다.

중립적인 관점에서 글을 작성하였으나 어느 한 쪽으로 편향이 되었다면 미리 그 점에 대해 양해를 구하는 바이다.

중앙통제력

이름에서도 알 수 있는 것 처럼 중앙집중적인 통제력은 기존의 중앙집중 방식이 분산제어 방식보다 유리한 점이 많다. 분산제어 방식은 자신이 서버로의 통제를 받는 동시에 제 3자에게 있어 자기 자신이 서버가 된다. 반면, 중앙집중 방식에서는 서버가 오직 물리적인 한 곳에 위치해 있다.

때문에 중앙집중 방식은 조직에 있어 정책적인 부분을 클라이언트에게 강제로 주입할 수 있는 여지가 많다. (물론 분산제어 방식도 가능하다) 중앙 서버 한 곳의 설정만으로 많은 클라이언트를 통제할 수 있다.


이미지 참조

그리고 모든 히스토리는 중앙 서버의 데이터베이스에 저장이 되기 때문에 클라이언트에게는 단지 소스 밖에 없지만, 분산제어 방식은 그렇지가 않다. Git의 스테이징 스토리지가 바로 클라이언트가 가지고 있는 데이터를 저장하는 (임시?)스토리지다.

조직에서 소스코드가 변경되는 주요 변경 이력은 매우 민감한 부분이고, 영업비밀과 직결되는 요소들이 많다. 응용프로그램이 연결되는 데이터베이스의 컬럼이나 테이블의 사소한 변경에도 응용프로그램은 수정되어야 할 수 있고, 이것이 응용프로그램의 소스코드에 반영이 되면서 소스제어에 이력을 남기게 된다.

정책주입력

정책적인 주입력은 중앙통제력과 유사한 부분이 많다. 중앙통제력이 크면 클수록 정책주임력은 향상된다. 중앙 서버의 정책적인 설정만으로 여러 클라이언트는 중앙 서버에 의해 통제받을 수 있다.

특히 ALM(Application Lifecycle Mamangement) 제품과 개발 IDE 제품간에 얼마나 긴밀하게 잘 통합이 되었느냐에 따라 정책주입력에 영향을 미친다. 통합이란 것이 양날의 검과 같아서 좋게 말하면 ‘All in One’이라 표현할 수 있겠고, 나쁘게 말하면 구성요소간에 강한 응집력으로 인해 제한된 확장이라 말할 수 있겠다.

ALM 통합의 장점

  1. 한 번의 구성으로 모든 것을 사용할 수 있다.
  2. 새로운 업그레이드도 한 번의 구성으로 모든 것을 구성할 수 있다.
  3. 개발툴과 통합되어 사용하기 쉽다.

ALM 통합의 단점

  1. 설치/구성 환경은 벤더에 의해 결정된다.
  2. 기능이 하나 하나가 완성도가 높지 않아 기업 및 도메인 환경에서는 추가 개발이 필요한 경우가 많다. (범용성을 위해…)
  3. 오픈 소스 ALM 도구보다 쓸 수 있는 도구들이 적다. (애드인/플러그인)
  4. 다양한 외부 도구와 연동이 제한된다.

분기용이성

분기(Branch)는 나무에서 여러 가지(Branch)로 뻗어 나가는 것을 일컬어, 하나의 소스 코드에서 여러 가지(Branch)로 소스 코드를 키울 수 있다. 특히 분산 제어 방식에서 분기가 얼마나 유용하고 효율적으로 사용할 수 있는지 잘 알 수 있다.

중앙 제어 방식에서의 분기는 곧 변경 이력으로 반영되어 영구적으로 분기 이력이 남게 된다. 때문에, 분기를 개인적인 용도로 사용하는 것이 힘들다. 소스 제어의 파일 시스템 구조를 복잡하게 만들 수 있고 구성원 개개인이 이를 핸들링 하기에는 전체 제품의 소스 코드에 좋지 않은 영향을 미칠 수 있다.


이미지 참조

반면, 분산 제어 방식의 경우 분기는 반드시 알아야 할 매우 효과적인 기능 중 하나로 볼 수 있다. 위에서 언급 했듯이 서버에게는 클라이언트가 되지만, 제 3자에게는 곧 서버가 된다. 즉, 로컬 서버(클라이언트)에서 자체적으로 분기가 가능해진다. 클라이언트에서 분기와 서버로 Push되는 정보는 다르므로 서버의 정책이나 구조에 영향을 최소한으로 적게 미치게 된다.

하지만, 중앙 제어 방식에서도 이런 단점은 충분히 극복할 수 있다. 분기는 병합(Merge)이라는 조건을 전제로 수행되는데, 만약 병합이라는 전제 조건이 없다는 가정하에 이와 유사하게 문제를 해결할 수 있는 방법이 있다.

중앙 집중 방식의 소스 제어 제품마다 기능적으로 다른 점이 있겠지만, 다중 작업 영역(Workspace) 또는 보류(Shelve) 기능을 이용하여 로컬 분기(Local Branch) 기능을 유사하게 흉내낼 수 있다. (물론 진정한 의미에서의 분기 목적과는 다소 차이가 있다)

사용편의성

사용편의성은 소스 제어를 사용하는 사용자가 얼마나 소스 제어를 편하게 사용함을 의미한다. 이를 언급하기 전에 사용편의성은 개개인의 경험적인 부분에서 다를 수 있다.

먼저, 분산제어 방식의 대표적인 Git을 험오하는 이유 10가지에 대해 쓴 블로그 내용을 참고하자.

Git is the source code version control system that is rapidly becoming the standard for open source projects. It has a powerful distributed model which allows advanced users to do tricky things with branches, and rewriting history. What a pity that it’s so hard to learn, has such an unpleasant command line interface, and treats its users with such utter contempt.
이하 생략…
http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/

대부분의 소스 제어 명령은 GUI(그래픽 인터페이스)와 CMD(명령줄 인터페이스) 방식을 제공한다. 주로 GUI 방식은 개발툴과 연동이 되는 확장 또는 플러그인 방식으로 제공되고, CMD 방식은 소스 제어 제품 자체에서 제공하는 고유의 기능으로 제공이 되는 것이 대부분이다. 그래서 소스 제어를 사용하는 개발자가 어떤 환경에서 개발하느냐에 따라 GUI 또는 CMD 방식으로 갈리는 경우가 많다.

먼저, 이클립스(Eclipse) 또는 비주얼 스튜디오(Visual Studio)와 같이 비주얼을 강조하는 개발툴에서는 GUI 방식의 소스 제어 플러그인을 사용하는 경우가 대부분이다. 이런 환경에서는 키보드와 마우스를 함께 사용하는 경우이고 아이콘(icon)으로 수정된 파일을 바로 확인할 수 있다.

반면, SVN 또는 Git 의 CMD 도구의 사용이 익숙해질 경우 상당히 빠르게 명령을 사용하거나 결과를 확인할 수 있다. 그리고 개인용 컴퓨터의 성능에 거의 영향을 받지 않고 소스 코드를 개발할 수 있고, 손이 마우스와 키보드로 번갈아가며 사용할 필요가 없어 익숙한 사람에게는 더할 나위 없이 편리하다. 더불어, SSH와 같은 단순 Plain Text 환경에서도 제어가 가능하기 때문에 사용에 있어 거의 제한도 없다.

하지만 대체적으로 두 방식 모두 GUI 도구를 제공하거나 GUI 공개 소프트웨어가 많기 때문에 취향에 맞에 사용할 수 있다.

성능

중앙제어 방식은 모든 동작이 서버 측의 허가 없이는 불가능하거나 반드시 서버와 연결이 되어야 한다. 인트라넷이라면 크게 성능의 손실은 없겠지만, 지역이 다른 사람과 오픈 소스 개발을 하거나 클라우드 소스 컨트롤을 사용하는 경우 매우 느리다.

분산제어 방식은 모든 동작이 대부분 로컬에서 이루어 진다. Push, Fetch 같은 동작만이 서버와 연결이 필요하다. 때문에 성능이 매우 좋은 것이 특징이다. 하지만, 중앙제어 방식과 다르게 많은 데이터를 로컬에 저장해야 하므로 중앙제어 방식보다 로컬에 충분한 용량이 확보되어야 한다.

결론

몇 가진 기본적인 관점에서 깊지 않은 내용으로 중앙제어 방식의 소스제어 컨트롤과 분산제어 방식의 소스 컨트롤을 살펴보았다.

필자에게 어떤 것을 사용할지 묻는다면, 작은 개발 조직과 기업 환경에서는 중앙제어 방식을 권장하고 싶다. 많은 소프트웨어 개발 조직에서 여전히 통제하에 소프트웨어 개발을 하기를 원한다. 그리고 암묵적인 소프트웨어 개발 프로세스를 명시적인 프로세스로 개선하고자 하는 곳도 과거보다 많이 생겼다. 이런 환경은 중앙제어 방식이 더 효과적이라 믿는다.

반대로 분산제어 방식은 패키지를 개발하는 기업이나 IT 컨설팅, 국지적 개발 환경이 필요한 경우 효과적일 것이라 생각한다. 물론 기업 환경과 맞지 않는다는 것이 아니며, 통상적인 경우를 말한다.

필자는 우연히 Stack Overflow에서 매우 흥미로운 주제를 발견하였다. 바로 [Git vs Team Foundation Server [closed]]11 인데, 어느 개발팀의 분산제어 방식과 중앙제어 방식의 대결 구도에서 어떤 것을 선택해야 할 것인가에 대한 논의였다. (참고로 필자는 최근 git을 더 좋아한다.)

내용인 즉, 자신의 개발팀에 Git를 도입시켰으나, 개발 팀원들은 팀 파운데이션 서버(Team Foundation Server)로 바꾸길 원했다. 이 질문에 추천 답변의 내용은 ’Git을 버려라. Git을 계속 쓰다가는 계속 비난을 받고 싸우게 될거다’고 한다.

결론은 소스제어 컨트롤(Source Control)은 개인이 아무리 좋고 훌륭한 소스제어라고 생각하더라도 다른 사람들은 그렇게 생각하지 않을 수 있고, 선택에 있어서 다수의 의견에 귀 귀울이는 것이 좋을 것 같다.

I think, the statement

everyone hates it except me

makes any further discussion waste: when you keep using Git, they will blame you if anything goes wrong.
Apart from this, for me Git has two advantages over a centralized VCS that I appreciate most (as partly described by Rob Sobers):
automatic backup of the whole repo: everytime someone pulls from the central repo, he/she gets a full history of the changes. When one repo gets lost: don’t worry, take one of those present on every workstation.
offline repo access: when I’m working at home (or in an airplane or train), I can see the full history of the project, every single checkin, without starting up my VPN connection to work and can work like I were at work: checkin, checkout, branch, anything.
But as I said: I think that you’re fighting a lost battle: when everyone hates Git, don’t use Git. It could help you more to know why they hate Git instead of trying them to convince them.
If they simply don’t want it ’cause it’s new to them and are not willing to learn something new: are you sure that you will do successful development with that staff?

Does really every single person hate Git or are they influenced by some opinion leaders? Find the leaders and ask them what’s the problem. Convince them and you’ll convince the rest of the team.

If you cannot convince the leaders: forget about using Git, take the TFS. Will make your life easier.


Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 이성훈 2018.05.10 14:53 Address Modify/Delete Reply

    분산제어 서버를 이용하면 프라이빗 블록체인과 차이가 없는건가요..?!

소프트웨어 인문학(Software Humanities)

최근 '소프트웨어 인문학(Software Humanities)'에 대한 이야기가 종종 들린다. '인문학'은 인문학인데 소프트웨어 인문학은 또 뭘까? 정확하게 말하면 필자도 모른다. 영문 Wikipedia에서 '디지털 인문학(Digital Humanities)'에 대한 내용은 있는데 소프트웨어 인문학에 대한 정의는 찾아볼 없었다. 아직까지 '소프트웨어 인문학'에 대해 다수가 공감하는 정의가 없다고 보는 게 옳은 것 같다.

필자가 인문과 전공도 아니므로 인문학이 뭔지도 제대로 모른다. 국문 Wikipedia에서 '인문학(人文學)' 인문학에 대한 정의를 볼 수 있다. 국문 Wikipedia에서 인문학에 대해서 다음과 같이 정의를 한다.

인문학의 분야로써 '고전', '역사', '언어', '법', '문학', '철학', '종교', '역사' 등이 있다고 정의되어 있다. 그리고 이 인문학을 과학적으로 규명하기 위한 연구가 '사회 과학'과 매우 밀접하게 연관되어 있어 보인다. [1]

결국 탐구하는 학문...

소프트웨어는 사람이 만든다. 콩 심은 데 콩 나고, 팥 심은 데 팥 나듯, 그 소프트웨어를 보면 그 기업이 추구하는 가치관을 어느 부분 읽을 수 있다. 하물며 소프트웨어의 속의 하나 하나 벗겨 코드 까보면 그 코드를 만든 사람이 추구하는 생각을 읽을 수 있다. 결국 소프트웨어는 사람에 의해 만들어진 하나의 인격적인 집합, 또는 인격체라고 정의하고 싶다. '소프트웨어 인문학'은 소프트웨어의 가치를 탐구하는 활동이 그 시작이라고 생각한다.

최근의 소프트웨어 개발은 애자일과 린 소프트웨어의 영향을 많이 받았다. 소프트웨어를 잘 만드는 방법은 이론적인 방법보다 실용성에 초점을 맞추고 있다. 과거부터 지금까지 소프트웨어 개발 방법론에 대해서 많은 발전을 이루어왔다. 전반적인 모든 것을 포괄하는 '소프트웨어 공학'은 소프트웨어를 정의하고 소프트웨어를 개발하는 모든 것을 정의하고 있다. 단지, 개발 영역 뿐만 아니라 '소프트웨어 테스트'와 '소프트웨어 운영'에 대한 효과적인 방법을 제시한다. 우리가 알고 있는 개발 프로세스나 방법론 등은 '소프트웨어 공학'의 일부이다.

그리고 아무리 이론이나 실용적인 부분을 적용하더라도 개발 툴이나 개발 플랫폼이 받쳐주지 않으면 실용적이라고 할 수 없다. 최근의 객체지향 프로그래밍 언어를 지원하는 개발 툴은 도구가 없이 개발하는 것이 상상하기 힘들다. (일부 리눅스 계열의 개발자들은 개발 통합 툴(IDE)보다 vi 또는 vim 을 사용하는 것이 더 편하다고 한다. 분명 툴이 만능은 아니다.)

실용성을 추구하는 애자일 소프트웨어

최근 애자일(Agile)과 린(Lean) 소프트웨어 개발 방법 및 프로세스가 소프트웨어 개발 문화를 많이 바꾸어 놓았다. 최근의 이런 애자일리티(Agility)한 방법들은 실질적으로 실용성을 높이기 위해 사람을 탐구한다. 반대로 사람을 탐구하여 실용성과 낭비를 제거하고자 한다는 것이다.

낭비에 대표적인 두 가지가 있다. 문맥 전환(Context Switching)과 성능(Performance), 커뮤니케이션(Communication)이다.

  1. 문맥 전환(Context Switching)이 얼마나 리소스를 잡아먹는지에 대한 실험이 있었다. 사무업무는 가장 집중할 때 가장 높은 퍼포먼스를 낸다. 소프트웨어를 만드는 개발자들도 마찬가지며, 공부하는 학생도 마찬가지다. 이 집중력을 수치로 100이라고 가정하자. 집중하는 그 시간에 업무에 의해, 또는 친구들의 전화가 와서 전화를 받는다고 가정하자. 전화를 끊고 나서 그 사람이 이전 상태의 100의 집중력 상태로 다시 진입하기 위해 약 15분이라는 시간이 필요하다고 한다. 더군다나 신체적인 움직임이 필요한 문맥 전환인 경우, 다시 원상태로 돌아와 다시 안정된 심박수로 돌아가는 것 마저 5분 정도의 시간이 소요된다.

  2. 성능(Performance)을 보자. 비싼 연봉을 주고 그 사람을 100% 활용하지 못하면 무능한 팀장, 무능한 조직으로 오해 받기 쉽다. 더 나아가 120%의 퍼포먼스를 내길 원한다. 그리고 평가는 이런 식으로 등급을 매기지는 않는가?

    120%=S, 100%=A, 80%=B, 60%~=C

'린 소프트웨어 개발(Lean Software Development)'을 출간한 Mary Poppendieck와 Tom Poppendieck는 이를 컴퓨터의 CPU에 비유하기도 했다. 컴퓨터의 CPU를 잘 활용하는 것은 CPU를 항상 100% 성능을 끌어내는 것이 아니다. 그러다간 CPU의 수명이 짧아지고, CPU가 열 받는다. 120%의 성능을 내기 위해 오버클럭(Overclocking-CPU의 권장 클럭을 의도적으로 높이는 조작 행위)을 하게 되면 컴퓨터는 이유 없이 꺼지기를 반복하다가, 언젠가 CPU가 쪼개진다.

즉, 높은 성능을 요구하고, 문맥 전환도 자주 발생한다면, 컴퓨터는 이도 저도 모두 다 제시간이 마치지 못한다. 이 비유가 사람에게도 마찬가지로 적용된다는 것이다.

커뮤니케이션(Communication) 또한 잘 알려진 실화가 많다. IBM 출신의 운영체제를 만들던 프레더릭 브룩스(Frederick Brooks)는 전설이라고 일컫는 유명한 'The Mythical Man-Month' 저서가 있다. 우리가 개발할 때 익히 듣던 맨먼스(Man Month)라는 용어가 여기에서 나오게 되었다. 'Man Month(M/M)'는 번역하면 인월(人月), 풀어서 얘기하면 '한 사람이 한 달 동안 할 수 있는 일' 이다. 초기 소프트웨어 공학에서는 사람을 하나의 '객체의 하나(a Unit of Object)' 인 물질적인 존재로 다루어 졌다. 사람 한명 한명 '리소스'이자 '비용'이다. 현재까지도 우리나라에서는 프로젝트에 투입되는 인력의 수를 산정하는 기준은 바로 이 'Man Month(M/M)'이다.

포토샵(Photoshop) 같은 이미지 편집 소프트웨어를 12개월에 만들어야 한다면, 12 M/M(Man Month)가 되고, 한 사람을 12개월 동안 개발시키면 된다. 그런데 한 달 만에 끝내고 싶다면, 12개월치 일정과 업무량을 12조각으로 나누어 12명의 개발자를 투입시켜 배당한다면, 과연 한 달 만에 끝날까? 모든 소프트웨어 공학자가 '그렇다' 또는 '그렇지 않을까' 란 대답에 브룩스는 전혀 다른 답을 했다.

이것이 바로 '브룩스의 법칙'이다.

즉, '1 * 12 = 12 * 1 은 성립되지 않는다. ' 개발자(1명) * 개발기간(12개월) = 개발자(12명) * 개발기간(1개월) '

12명이 프로젝트에 투입되게 되면 이메일 소통, 상호간의 인터페이스 합의, 미팅 등 커뮤니케이션 비용이 곱하기(*)가 아닌 제곱(^) 만큼 복잡해진다고 정의하였다. 이 '브룩스의 법칙'이 오늘날 사실임을 말해주는 다양한 공학적인 실험이 있으니 찾아보는 것도 재미있을 것이다.


[이미지 출처는 여기]

'브룩스'의 원서는 '이 링크에서' 번역서를 찾을 수 있다. 필자도 아직 읽어보지는 않았지만, 지금 읽는 책을 다 읽으면 조만간 볼 계획이다.

널린 게 한 번에 한 가지 일을 할 수 있는 사람이다.

자신의 능력 100% 중에 60~70%를 발휘할 수 있는 사람은 널려있다. 5천만원 연봉의 과장급 개발자 한 명 데리고 있는 것보다 3천만원 연봉의 신입이나 대리 한 명이 같은 결과를 내지만, 양적인 면에서 생산성이 좋다는 이치이다.

문맥 전환(Context Switching) 논리를 가져다 대는 것은 쉽다. 그럼에도 불구하고 한 번에 두 가지 일을 할 수 있는 사람이 더 가치 있는 사람으로 대우 받는다. PM(Project Manager) 한 명이 2~3개 프로젝트를 잘 수행하는 것도 능력이다. 이것이 특별한 슈퍼맨의 기운이 필요한 것은 아니다. 그렇다고 2~3개의 프로젝트가 전부 어중간 하다고 결론 지을 수도 없다.

개발자에게 명세서를 던져주고 일을 제시간에 완료하는 것은 기본 중의 기본이다. 당연히 할 수 있어야 하는 것을 못하는 사람이 문제다. 명세서가 부실하다고 탓해도 잘 하는 사람은 한다. 못하는 사람이 부실하다고 불평한다. 어쩌면 개발자가 두 개의 프로젝트에 투입하여 일을 잘 해내는 것은 아무나 할 수 없다. 그렇다고 매일 철야에 야근을 하지도 않는다.

이렇게 일을 잘 하는 사람들이 많다. 주변을 살펴봐라. 온갖 애자일 법칙을 추구하며 존중 받기를 원한다면, 기본적인 자기 관리 능력이 있어야 한다. 자기 관리를 잘 하려면 옆의 동료보다는 내가 더 나은 실력을 갖추어야 한다. 하향 평준화에 맞추지 말고 냉정하게 스스로를 평가할 수 있어야 한다.

자신의 성능을 100%, 그리고 120%를 끌어내보지 못한 사람은 자신의 능력과 성능을 모른다. 그 와중에 일을 멀티쓰레딩(Multi-Threading)과 멀테테스킹(Multi-Tasking)으로 한다고 상상해 보자. 이렇게 하는 사람들이 없을 것 같지만, 필자는 .NET 컨설팅 회사를 다니면서 많이 봐왔다. 정말 실용적으로 낭비를 제거하고 일을 잘 한다.

소프트웨어 공학을 들여다 보면, 기본적으로 개발에 필요한 기술적인 테크닉과 소프트웨어와 개발에 대한 이해, 그리고 개발에 필요한 충분한 능력을 기본 전제로 하고 있다. 그 전제를 바탕으로 소프트웨어를 개발하는 방법론을 지향한다. 애자일도 마찬가지다. 소프트웨어를 사랑하고 개발을 즐기는 애정이 없다면 그 사람에겐 무효인 방법론에 불과하다. 그러므로 기본 전제에 해당되지 않는 사람들이라면 애자일은 매우 비효율적일 것이다.

애자일이 그저 허울 좋은 면죄부가 아니란 점을 확실하게 인식해야 할 때이다.

이 부분에 동의할 수 없는 사람도 있겠지만, 일어날 수 있을 법한 예이고, 실제로 겪어 본 일이다. 그래서 필자가 다양한 시각으로 역설하지 못한 부족한 부분도 있으니 이점 양해 바란다.

애자일은 맞춤복처럼 딱 맞지 않더라..

최근 필자와 같은 생각을 하는 사람들이 많이 늘었다. 애자일 개발 방법과 프로세스를 우리나라에 그대로 적용시키기 무리이다. 서양 사람이 서양 사람을 탐구하여 만든 방법론이 우리나라 사람에게 적용하기에 문화적인 차이와 생각이나 관념이 다르기 때문에 애자일을 적용하는 사람이나 적용 받는 사람이나 서로 불편하다.

  • 개발 업무 자체를 거의 개인(혼자)할 수 있도록 쪼개서 주는데, 짝 프로그래밍(Pair Programming)이 무슨 필요가 있겠냐. 언제부터 우리가 몸 비비며 일했다고...
  • 프로젝트 기간이 짧고, 비용이 낮아야 프로젝트를 수주할 수 있는데, TDD(Test Driven Development), 즉, 테스트 코드부터 만들라고 하니 이게 왠 봉창 두드리는 소리냐.
  • 미국은 테러리스트와 협상하지 않으며, 고객은 왕이요, 고객은 '을병정'을 위해 화합, 협력하지 않아...
  • 가치 있는 소프트웨어? 5년 후 차세대 프로젝트, 그 5년 후 차세대 프로젝트, 또 5년 후 차세대 프로젝트… 가치가 있으면 가치를 덧붙이겠지, 갈아 엎을 필요는 없겠지...

모든 소프트웨어 기업이 그렇단 말은 아니다. 주로 SI 프로젝트에서 발생한다. 그리고 우리나라 SI 소프트웨어 산업의 규모는 80% 이다. (수치적인 출처). 80%에 육박하니 거의 대부분이라고 말해도 되겠다.

  • 동료나 상사에게 속마음을 터놓는 것은 자신의 약점을 오픈하는 것이므로 꺼려하며,
  • 자신의 치부를 놓고 토론하듯 내 코드를 보며 코드 리뷰를 하는 것을 꺼리며,
  • 품앗이처럼 서로 돕는 공동체 사회에서 서구화된 팽배한 개인주의를 선호하며,
  • 전문직 직종이란 말이 무색할 정도로 산업 전반적으로 하향 평준화된 개발자나 기술자

이런 우리나라의 문화와 특성에 맞는 소프트웨어 방법론이 필요하다. '애자일 성공 사례' 들을 들어보면 하나 같이 책에서나 나올 법한 뻔한 얘기들 뿐이다. 성공이란 기준이 기한 내에 합의된 비용으로 프로젝트를 마친 경우를 성공이라고 하나, 모든 팀원이 '애자일'을 성공적으로 적용하여 성공했다는 것에 동의할 지는 의문이다.

’진정성'이 없는 롤러코스터와 같은 프로세스와 기법들...

이렇게 쓰고 보니, 뭐라고 결론을 내야 할 지 본인도 모르겠다. 넓은 범위로 애자일에 대한 사상과 그것이 추구하는 가치는 필자도 매우 공감한다. 물론 지금도 마찬가지다. 그리고 애자일을 잘 알고, 잘 하고 싶다.


[이미지 출처는 여기]

애자일(Agile)과 린(Lean) 방법론(?)은 결국 일본의 도요타 자동차 공장의 프로세스와 사상을 소프트웨어라는 분야에 적용시킨 것이다. 과거에 미국 등 많은 자동차 생산 기업들이 일본의 도요타 자동차의 생산 기법을 적용하였는데, 왜 실패하는지 모르겠다고 했다. 모든 기법과 프로세스를 그대로 적용했는데도 말이다.

'짝퉁'과 '명품'의 차이는 '장인 정신'이 아닌가. 모두가 S+급 짝퉁을 가리켜 명품이라고 하지만 1~2년 써보면 짝퉁은 역시나 짝퉁이다.

왜 많은 자동차 기업들이 도요타 자동차의 생산 방식에 실패했을까? 독자들이 생각하는.. 목구멍까지 올라오는 무언가가 있을 것이다. 정답은 바로 그것이 없기 때문에 모조리 실패했다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 박중석 2013.01.25 08:15 Address Modify/Delete Reply

    좋은글 잘보고 갑니다. 장인정신하니 학생 때 교과서에 배운 방망이 깍던 노인 소설이 떠오르네요.

  2. 짜두 2013.01.25 08:41 Address Modify/Delete Reply

    일정부분은 동의하고 어떤부분은 공감할 수 없기도 하지만 이 글에서 가장 공감하는건 EX-회사의 경험은 정말 좋은 경험이었음~ 구정오기전에 함 봅시다~ 레알~ㅎ

  3. kevin 2013.01.25 09:45 Address Modify/Delete Reply

    글의 주제와는 벗어나지만. ^^ Turbo C에 대한 평가는 지금 세대에서 하면 안될 것 같습니다. 그 당시에 실제로 제가 써 본 기억에 의하면, IDE 환경 내에서 편집/컴파일하고 디버깅까지 할 수 있었다는 것 자체가 편리했었습니다. 인텔리센스 같은 것은 그 당시에는 어떤 IDE에서도 구현하지 않았으므로 비교해서 우울해질만한 것도 없었다는. ^^

애자일 개발과 전통적인 소프트웨어 개발 방식의 함점

얼마 전 필자는 지인을 통한 이 바닥에서 잘 알려진 분을 통해 소프트웨어 개발에 필요한 사람을 찾는다는 소식을 듣고 연락을 취하여 좋은 프로젝트를 소개 받았다. 쉽게 말하면 알바 하나 건졌다. 난이도와 기간에 비해 높은 비용을 제시하였고, 재택 근무 조건으로 업체와 구두상으로 서로 계약에 합의하였다. 구두상의 협상의 합의가 타결되기 위해 이 틀 동안 분석/설계된 자료를 검토하여 질의응답도 있었다.

필자는 애자일 개발 기법을 공부하고 적용해 보면서 여러 가지 함정에 빠져보았다. 이전에 비슷한 글을 몇 번 쓴 적이 있는데, 참고하면 좋을 것 같다. 그리고 과거의 필자의 작은 지식이기 때문에 독자들은 동의하지 않는 부분도 있을 것이라고 생각한다. 잘못되거나 동의할 수 없는 부분이 있더라도 양해를 부탁하며 필자의 아티클을 읽어주길 부탁한다.

프로젝트의 요구 사항은 무엇이었나?

어쨌든 필자는 애자일은 양날의 검이라고 이야기한 바 있다. 누구의 손에 쥐어지는지에 따라 애자일의 가치와 방법은 변할 수 있다. 맞춤 정장처럼 누구에게나 꼭 맞는 폼이 나지 않는다. 더불어 애자일 팀의 팀 성숙도와 이해도에 따라 성공과 실패가 극단적으로 갈리기 때문에 필자는 항상 애자일에 대한 접근에 매우 조심스럽다.

프로젝트는 유명한 게임 업체의 기업 홈페이지인데, 최신 .NET 플랫폼을 이용하여 개발하지만, 발주처에서 제시한 개발 지침은 강도가 높았다. 문서화나 산출물과 같은 노가다 짙은 결과물 보다는 객체지향적인 개발과 추상화된 개발이 조건이 있었다. 필자 또한 기반 프레임워크 개발과 개발 프레임워크를 개발하고 컨설팅을 수행하던 경력이 있던 부분에 계약 업체에서 필자의 이력에 만족해 하는 눈치였다. (뭐 상상은 자유지요? ^^).

더불어 성능 테스트도 개발 완료 조건이 포함이 되어있었다. 이 부분 또한 4년 이상 성능 테스트 경험의 컨설팅을 수행하고, 이후 N모사에서 서버/웹/클라이언트 소프트웨어의 성능 테스트와 부하 테스트 시스템을 프로세스화하고, 테스트 시스템을 구축하여 전담하고 있었기 때문에, 이 부분에서 신뢰를 얻을 수 있었던 것 같다.

우선 기업 홈페이지의 특징을 간단하게 분류해 본다면, 정적인 페이지(HTML), 게시판, 그리고 채용 기능이다.

  • 첫 번째, 특히 채용 기능은 내부 시스템과 연동되는 가능성이 크고, 채용 프로세스가 기업의 문화마다 차이가 있다는 점에서 가장 투입되는 리소스가 많은 부분이라고 판단했다. 더불어 화면 기획서의 절반 이상을 차지 것이 채용 시스템 부분이었다.

  • 두 번째, 전반적으로 국지화나 다국어 지원인데, 동적인 데이터나 게시판과 같은 것도 다국어 지원이 필요한 부분이었다. 단순히 다국어라고 하면 동일하게 보여지는 콘텐트에 대한 다국어인지, 국지화에 따라 별도의 게시판인지에 대한 부분도 명확해야 한다.

  • 세 번째, 발주처의 지침에 따라 성능 테스트가 필요하다. 그런데 완전히 새로 개발되는 웹 페이지가 더 나은 성능을 제공하는지 판단하기 위해서는 기존 웹 페이지의 성능 지표가 필요하다. 그래야 더 나은 성능 개선에 대한 데이터와 지표를 제공할 수 있다. 다만, 문제는 이전의 성능 지표가 없다는 것과 그렇다면 이전 웹 페이지에 대한 성능 테스트를 재수행해야 하는지에 대한 여부이다. 그리고 최근의 인터프리터 언어는 객체지향 컴파일 언어보다 런타임에서 더 빠른 성능을 발휘할 수도 있기 때문에, 이 부분에서 반드시 더 좋은 성능을 낼 수 있다는 보장을 할 수 없다고 구두상으로 못박았다.

일전에 테스트한 node.js의 성능과 C++ 성능을 테스트한 바 있는데 필자의 눈을 의심할 만한 결과가 나왔다. 당연히 C++ 네이티브 코드가 더 빠를 것으로 예상했던 부분이 node.js의 자바스크립트 인터프리터 컴파일 결과가 훨씬 빨랐다는 점이다. 전체적으로 자바스크립트도 가비지(Garbage) 작업을 배제한 것이기도 하고, 이 부분은 이 아티클의 논점을 벗어나기 때문에 논외로 하겠다.

계획 없는 애자일은 항상 불안한 문제들을 내포하고 있다.

이제 프로젝트 이야기를 잠시 떠나 전통적인 개발 방식과 애자일 개발 방식에 대해 이야기를 하고 싶다.

전통적인 개발 방식은 워터 폴(Waterfall)이나 Top-Down 방식의 개발 방식이라고 부르기도 한다. 폭포의 물이 위에서 아래로 떨어지는 것처럼 최초의 정의(Definition)나 개요에 의해 요구사항이나 작업이 나열되는 방식이다. 큰 덩어리는 더 작은 덩어리로 쪼개어 정의되는데, 여기에 파생된 기능/비기능 작업이 정의가 된다. 그리고 기획자(기획 또는 분석가 등의 포괄한다는 의미)는 각 화면을 정의하고 기능/비기능의 정의와 링크가 된다. 때로는 화면 정의와 기능/비기능 정의가 하나의 문서로 통합시키기도 한다. 뭐 이건 프로젝트의 규모나 개발 방식에 따라 다를 수 있고 발주처나 누군가에 의해 템플릿화 된 부분이므로 큰 문제가 되지 않는다.

전통적인 개발 방식은 매우 체계적(?)이여서 체계 자체의 정의에 오류가 있다면 이후의 설계나 개발에 영향을 미치고, 전체 개발 일정에도 영향을 미치게 된다. 필자도 공감하는 부분이며, 이런 문제와 요구 사항, 그리고 도출되지 않는 일부 작업을 잘게 쪼개진 다음 이터레이션(Iteration) 포함시켜 납품 기간에 최대한 근접할 수 있는 유동적인 계획이 만들어진다. 유동적일 수 있는 계획들이지만, 그 유동성에 의해 개발팀에서 만족할 수 있는 일정과 개발 형태를 가져갈 수 있는 이점이 있다.

하지만 대부분 문제가 되는 부분들은 표면적으로 드러나지 않는다. 사실 눈에 보이는 문제는 문제도 아니다. 눈에 보이는 문제는 문제로 인식할 수 있기 때문에 당장이라도 해결하길 원하면 해결할 수 있고 일정에 포함시킬 수 있다. 그런데, 눈에 보이지 않는 아주 작은 문제는 나중에 핵폭탄이 될 수 있는 위력을 가지고 있다.

애자일 개발을 선호하는 초급의 사람들은 이런 핵폭탄급 문제를 먼저 제거하려고 하지 않는 경향이 있다. 위에서 언급한 것처럼 국문/영문 게시판이라는 정의는 자세하게 기능을 정의하기 전에는 매우 많은 위험성을 내포하고 있다.

국문/영문을 지원하는 게시판이 있다면 도출되지 않은 기능/비기능적인 문제들의 예이다.

  • 다수의 게시판 중에 모두 지원해야 하는지, 일부만 지원해야 하는지
  • 일부만 지원하면 어떤 게시판이 국문/영문을 지원해야 하는지
  • 국문/영문 게시판은 하나의 게시물이 국문/영문으로 지원하는 것인지,
  • 또는 국문/영문 게시판은 별도의 게시물을 게시할 수 있는 것인지,
  • 또는 둘 다 가능해야 하는지
  • 이와 같은 다양한 국문/영문 지원에 따라 댓글 기능은 분리되어야 하는지, 또는 어떻게 지원해야 하는지
  • 현재까지는 국문/영문이지만 더 지원해야 하는 언어가 생길 가능성은 얼마나 있는지
  • 국문/영문 그리고 댓글에 대해 관리자의 권한 정의는 어떻게 하는지
  • 그 외의 부분은 영업 비밀이므로 비공개 함.

채용 시스템이 내포하고 있는 문제점의 예이다.

  1. 영문 지원 여부가 확실하지 않다
  2. 영문을 지원한다면 영문 문화권의 채용 프로세스로 진행해야 하는지
  3. 현재의 주소 체계인 도/시/읍/번지가 데이터베이스 스키마에 종속적인데, 새로운 주소 체계를 지원할 것인지
  4. 그렇다면 두 가지 주소 체계 도입으로 주소 입력 프로세스와 기능/비기능적인 개발 소요 리소스 비용이 추가되는 것을 인지하고 있는지
  5. 그 외의 부분은 영업 비밀이므로 비공개 함.

위와 같이 기능/비기능이 명확하게 정의되지 않는 일부의 예이다. 만약 기능/비기능이 이해하기 쉽게 정의되지 않거나 애매모호하다면 무엇이 가장 힘들어지는가? 바로 '커뮤니케이션'이다. 이 비용이 얼마나 비싼지 소프트웨어 개발에 관심이 있는 분들이라면 익히 알고 있을 것이다. 그리고 비싼 커뮤니케이션 비용을 감수하더라도 추후에 발생 가능한 책임의 소지이다. 이메일이나 메신저로 기록이 남으면 다행이지만, 전화 연락을 통해 급하게 정의되는 기능/비기능이라면 빼도 박도 못하고 약자가 패자가 된다. 일반적으로 개발자가 패자가 되는 것이다.

애자일 선호하는 사람들이 범하는 오류

애자일 소프트웨어 개발 방식을 선호하는 사람들은 전통적인 개발 방식이 잘못되거나 비효율적이라고 생각하는 사람들이 있다. 물론, 모든 사람들이 그렇다는 것은 아니다. 개인적인 필자의 경험은 외부의 애자일 팀과 일할 때가 가장 힘들었다. 바로 전통적인 개발 방식의 설계 방식의 고민의 흔적이나 문서들이 전혀 없다. 대신, 내 팀이 애자일 팀이라면 정말 일하기는 편할 수 있다.

애자일 개발 방법에서는 불필요한 산출물은 최대한 만들지 않는 것을 선호한다. 그래서 애자일 기법 중 기능/비기능이나 설계적인 문서는 클래스의 주석으로 만들어서 Doc Generator와 같은 유틸리티로 주석에 기재한 명세를 문서화한다고 한다. 이런 이야기는 비단 애자일 책에서도 매번 나오는 이야기다.

그런데 여기에도 문제가 있다. 발주처에서 사용하는 문서 양식이 있다면 문서 양식을 맞추어야 한다. Doc Generator의 템플릿을 고쳐 써야 한다. 그리고 Doc Generator로 전달된 문서가 발주처의 담당자에 의해 수정이 되는 경우 다시 코드의 주석에 반영이 되어야 한다. 결국 양방향 동기화가 가능해야 한다. 물론, 기술적으로 MS WORD와 같은 문서는 Hidden Field Definition(숨김 필드)의 메타데이터 정보를 이용하여 양방향 동기화가 가능하다. 다만, 발주처의 문서 자체를 양방향 동기화에 맞게 바꾸어야 한다. 양방향 동기화가 가능성 있는 이야기처럼 들리겠지만, 실제로는 전혀 불가능할 수 있는 환경일 가능성이 더 크다. 발주처의 표준 문서 형태를 바꾼다는 것은 사실 권한 밖의 범위이다.

애자일의 성숙도와 개발 방식은 전통적인 개발 방법의 경험이 기반

필자는 프로젝트 구두 계약을 취소하였다. 생각했던 것 이상으로 정의되지 않은 채 진행되는 요소들이 너무 많아, 일정을 추정할 수 없을 지경이었다. 개발은 커녕 분석/설계된 데이터도 없었다. 하지만 데드라인은 정해져 있었고, 작은 기능/비기능 요소 중 핵폭탄이 될 수 있는 플루토늄이 너무 많았다.

계약서의 도장을 찍지 않은 채, 약 이 틀 정도 전달 받은 허술한 문서에 대해 커뮤니케이션 리소스를 상당히 빼앗겼다. 계약할 업체 또한 필자의 계약 취소 요청에 개발 일정 중 이 틀을 손해를 보게 된 것이다. 결국 필자를 포함한 양측 모두 이에 대해 상호 손해를 본 점에 대해 인정하고 그냥 그렇게 필자의 알바 건수는 끝이 났다.

이 알바 건으로 느낀 결론은 애자일의 성숙도와 개발 방식은 전통적인 개발 방법의 경험이 기반이 되어야 한다는 점이다. 계산하지 않고 생각하더라도 명확하게 정의되지 않는 기능/비기능에 대해 수시로 커뮤니케이션 하는 것과 빡 세게 정의한 후에 일부 도출되지 않는 부분에 대해서만 커뮤니케이션 하는 것과의 소요되는 비용이나 리소스의 차이는 엄청나게 크다. 그리고 기록으로 남기기 힘든 전화와 같은 수단으로 정의된 기능은 추후 책임의 소지를 가려내기 힘들다. 약자가 패자다.

애자일과 같은 기법들이나 책이 있다면 다시 한번 보도록 하자. 초기 설계와 분석이 얼마나 중요한지 말이다. 필자 또한 여러 애자일에 대한 책을 보았다만, 분석/설계가 강조가 되지 않았을 뿐 중요성에 대한 이야기는 분명 나와있다.

아래의 문구는 애자일 선언문이다.

다시 한번 곱씹어 볼 글귀이다. '문서화보다는 잘 동작하는 소프트웨어'는 '문서화'가 중요하지 않다는 이야기가 아니다. '문서화'도 중요하지만 '잘 동작하는 소프트웨어'에 가치를 두자는 것이다. '잘 동작하는 소프트웨어'를 위해 '문서화'가 필요하다면 문서화를 잘 하는 것이 '잘 동작하는 소프트웨어'를 위한 방법이다.

바라보는 관점에 따라 '잘 동작하는 소프트웨어'를 기한 내에 납품하는 것 자체가 '가치'이기도 하다. 이 '가치'에 대한 설명은 자신의 역할이나 위치에 따라 얼마든지 달라질 수 있다. 위의 애자일 선언문 또한 우리나라의 발주처인 '갑'부터 '을', '병', '정'이 보는 관점에 따라 추구하는 가치는 다를 수 있다. 물론 기업의 팀이나 조직에서도 관점에 따라 그 가치에 차이가 있을 수 있다.

누구를 위한 가치인가? 애자일은 소프트웨어 개발 방법을 정의하고 가치를 추구하는 것이지만, 그저 '빠른 개발', '가벼운 개발', '우리 팀만을 위한' 개발 방법이라면 다른 팀이나 타인에게 무척 괴로움을 줄 수도 있다는 것이다. 전통적인 개발 방법의 경험이 축적되고 그 이후에 애자일 경험이 축적되어야 올바른 방향과 가치 있는 '가치'가 창조되는 것이라 생각한다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

소프트웨어 개발 프로세스와 프로세스 자동화의 함정

개발 방식에 고민이 없다는 것은 현재의 방식이 완벽하다거나 아니면, 전혀 그렇지 않거나 개발 방식에 대해 관심없다는 의미일것이다. 만약 개발 방식에 대한 관심이 없다면 각 구성원은 자신의 개발 경험과 눈빛만 보아도 통하는 암묵적인 프로세스에 의존하여 개발을 진행을 할 것이다.


[무단복제금지-엄준일[(POWERUMC)]]5

개발 프로세스와 프로세스 자동화

애자일과 같은 가벼운 개발 방법 또는 프로세스는 소규모의 팀이나 구성원들에게 매우 긍정적인 영향을 끼쳤다. 암묵적인 프로세스는 명시적으로 도출이 되어야 한다는 것과 물 흐르듯 자연스러운 조직 내의 개발 프로세스는 소프트웨어 개발 전반적인 품질을 향상시키거나 현 위치를 올바르게 인지할 수 있다는 것도 알게 되었다.

그리고 여러 가지의 툴을 도입하면 개발 프로세스를 더욱 강력하고 정책화시킬 수 있다. '째깍 째깍' 돌아가는 아날로그 시계처럼, 매일 매일 체크인 된 코드를 검증하고, 빌드 그리고 테스트를 수행하게 된다. 조직에서 개발 프로세스에 툴이 결합하면 개발현황을 파악하고 개발 프로세스의 전반적인 부분을 시각화 할 수 있다.


[무단복제금지-엄준일[(POWERUMC)]]10

실제로 필자는 부하테스트에 대한 분야에서 기술적인 경험들 축약하여 부하테스트에 대한 부분을 자동화를 한 적이 있다. 부하테스트에 대한 부분에서 자세한 이야기는 기회가 되면 다음에 다시 다룰 예정이다. 어쨌든 이런 부하테스트를 일일 테스트(Daily Test), 주간 테스트(Weekly Test)로 적용하고 리포팅을 자동화하였을 때, 시간의 흐름에 따라 서버나 클라이언트 역할을 하는 지점의 변화와 데이터베이스에 데이터가 적재됨에 따라 성능적인 부분과 안정성 부분에서 시스템 전체적으로 그 어떤 방법보다 명확하게 인지하고 이해할 수 있다. 즉, 어떠한 프로세스는 시각화될 때 의미있고 이해할 수 있는 데이터가 될 수 있다.

하지만, 물 흐르듯한 개발 프로세스에서 하루 하루 유영을 하는 개발자 한명 한명을 관찰해보자. 소프트웨어 전반적인 품질이 좋아진다는 것은 개발자 한명 한명이 누릴 수 있는 어떤 혜택도 되지 않는다. 물론 시스템의 장애와 버그가 줄어든다고 해도 말이다. 오히려 개발자 한명 한명에게 개발 프로세스의 강제화나 정책화는 기존에 개발하는 방식의 일보다 더 많은 시간적인 리소스가 필요하다. 이메일과 메신저와 같은 단/양 방향의 커뮤니케이션 채널은 개발 프로세스를 움직이는 동력과 같은 시스템으로 접근하여 각 작업의 명확한 트래킹(Tracking)을 위해 철저하게 데이터베이스화 되어 관리된다.

개발 프로세스를 도입하고 이것을 자동화하였을 때, 팀이나 조직의 관리자에게 가장 편안함을 준다. 조작되지 않은 신뢰할 수 있는데이터를 앉아서 받아볼 수 있으니 말이다. (물론 조작은 얼마든지 가능하다.) 관리자는 현황을 파악하기 위해 더 이상 발품 팔듯이다닐 필요가 없어진 것이다. 하지만 개발 조직의 개발자는 작업 관리를 위한 시스템은 편리하기보다 불편하다고 느낄 때가 더 많다.

개발 프로세스에 의한 양극화 발생..

왜 그럴까? 개발 프로세스를 도입하고 개발 프로세스를 자동화함으로써 모두에게 효율성이 좋아져야 하는데 왜 양극화가 발생하는 것일까?

개발 프로세스의 자동화는 닦아 놓은 길을 똑바로 따라가지 않을 때, 즉시 이를 트래킹 할 수 있다. 관리자의 입장에서는 팀원 개개인의 퍼포먼스를 끌어 올리거나 업무 향상을 기대할 수 있겠지만, 모든 경우가(대부분의 경우가) 이렇게 아름다운 업무 환경으로이어지지 않는다. 이 부분은 독자들의 상상에 맡기겠다.

또 하나는 전체적인 프로세스가 개선이 되었지만, 개개인이 이 프로세스에 올라 타 개발 프로세스의 이점을 누리기가 힘들다.대한민국의 1인당 국민 소득이 증가한다고 반드시 나의 소득이 올라가지 않는다. 대한민국의 경제가 5% 성장한다고 반드시 나의 경제 여건이 5% 좋아지지 않는다. 개발자의 개개인의 개발 프로세스에 대한 성숙도는 전반적으로 개발 프로세스를 최적화시키고 툴과 시스템과 통합하여 개선되는 속도보다 더디다. 즉, 많은 팀이나 조직에서 "일단 도입부터..." 시작하는 곳이 많다.팀이나 조직의 개발 프로세스 성숙도는 높은데, 개개인의 성숙도는 낮다면 이건 무슨 시추레이션인가.

그렇다고 개개인의 개발과 개발 외적인 성숙도를 높이는 것도 매우 어려운 일이다. 개발자는 개발을 잘 하는 것이 기본 자격 요건이다. 개발을 잘 하지 못하는 아마추어는 많다. 당장 서점에 가서 책 한권을 사서 뚝딱 아이폰 앱을 만드는 사람은 널리고 널려있다. 하지만, 실제로 개발 현장에 나가보면 프로그래밍 언어의 딱 10가지 키워드와 10가지 클래스, 그리고 대부분 그 외의것들을 모르고 있는 개발자들이 너무 많다. 이들을 버릴 것인가? 끌고 갈 것인가? 라는 물음에서 결국 하향 평준화를 선택할 수밖에 없다.

필자는 여기에 굳이 답을 제시하지 않겠다. 관점의 차이도 있겠고, 정답이 있는 것도 아니기 때문이다. 어쨌든 개발 프로세스와프로세스 자동화에 집중을 하고 있었다면, 그 이면의 잘 보이지 않거나 어두운 부분을 재조명해 보는 것이 개발 프로세스를 최적화할 수 있는 방법이라는 것이다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

최근의 대부분의 IT 트랜드는 통합에 매우 집중이 되어있다. 90대부터 분산 시스템에 대한 관심이 매우 급증하고, 실제로 많은 시스템이 분산 시스템으로 개발이 되어왔다. 과거에 콘솔이나 터미널 형태의 단순한 방식의 접근에서 이제는그야말로 어머어마하게 분산되고, 그 리소스와 자원을 효과적으로 다루기 위해 다시 또 하여금 통합이라는 대 주제의기술들이 쏟아지고 있다. 고도로 발전한 개개의 기술들을 통합시키고 다듬어져 클라우드라는 기술로 재조명 되고 있다.

대부분 이런 새로운 트랜드와 기술들은 소프트웨어 거대 기업에 의해 마케팅이 되거나 주도되어져 온 것이 사실이다.또 한가지 새로운 것들은 전혀 새로운 것이 아니라, 하부 기술의 탄탄한 기반에 의해 쌓아 올려진 것들임을 알 수 있다.

소프트웨어 공학의 함점

대부분의 소프트웨어 업계에서 일하는 독자들은 소프트웨어 공학이라고 들어는 보았을 것이다. 매우 추상화된 학문이기도하고, 그 범위나 학문 자체가 성숙되지 않은 학문이라고 한다. 필자는 이 소프트웨어 공학이 별도의 학문이라기 보다는 다른 학문과 이어져 함께 발전하는 학문이라고 생각한다.

우리나라에서 대학교를 입학하고 컴퓨터 학과에 진학하게 되면 가장 먼저 접하는 학문이 컴퓨터 공학이다. 0,1을사용하는 비트 연산부터 시작하여 이산 수학, 컴퓨터 과학이나 구조, 운영체제, 데이터베이스, 알고리즘, 그리고 프로그래밍 언어 등으로 컴퓨터 공학을 전공하게 된다. 당장 프로그래밍 언어만 잘 이해하고 습득하여도 학교를 졸업하고 먹고 사는데 큰 지장은 없다. 이론과 실무가 다르듯이 이론 없이 실무가 가능하다는 말이다. 이론적인 성숙도가 낮더라도 자격증을 딴다는 것이 어렵지 않은 것이 현실이다.

그렇다면 우리가 왜 학교에서 컴퓨터 학문을 배우는가…? 자고로 이미지 처리를 하기 위한 프로그래밍을 하려고한다면, 컴퓨터가 사용하는 2진수의 비트 연산을 이해하지 않고서는 만들 수 없다. 더 나아가 컴퓨터가 표현할 수있는 색상의 수는 한계가 있다. 자연의 색상인 True Color에 가깝게 표현은 할 수 있지만, 컴퓨터는 절대 TrueColor를 모니터로 표현할 수 없다. 그렇기 때문에 팔레트(Pallete) 원리를 이해하면 좀 더 가까운 True Color에 접근할 수 있다.

우주 과학이나 물리학과 같은 학문도 소프트웨어 공학과 떨어질 수 없는 관계이다. 왜 블랙홀에서는 모든 물리학의 법칙이 깨지고, 블랙홀의 중력은 무한대(∞?)인가에 대한 수수께기를 풀기 위해 많은 가설이 존재하고, 이 가설을 시뮬레이션 하기 위해 프로그래밍 언어와 알고리즘 사용하여 계산하고, 더 빠른 계산 성능을 위해 분산 컴퓨팅분야까지 발전하게 된다.

여기까지의 이야기만 듣다보면 컴퓨터 공학이나 소프트웨어 공학이라는 것은 성능적인 향상을 위한 목적의 학문이라는 착각이 들기도 한다.

본질을 잃어버린 소프트웨어 공학

우선 밝혀둘 것은 필자는 소프트웨어 공학을 논할 만큼 높은 학위가 있는 것도 아니고, 소프트웨어 공학에 푹 빠진사람도 아니다. "소프트웨어 공학의 본질이 무엇이다"라고 정리해야 하는 입장도 아니지만, 본질 자체가 흐트려지고 오해되는 것에 대해 매우 애석하게 생각한다. 'Agile이 우리 회사 문제를 해결해 줄 수 있을까?' 라는 주제의 소프트웨어 공학적인 입장에서 소프트웨어 공학이란 '소프트웨어를 빠르게 개발하기 위한 방법이다' 라는 최종결론에 도달하는 것에 대한 입장에 차이에 대해 이야기 하고 싶다.

우리나라는 몇 년 동안 애자일(Agile) 개발 방법론(개발 프로세스) 에 한 동안 푹 빠져, 애자일 개발 방식이 전지전능하고 실천하면 좋은 개발 방법으로 오해하며 살아왔다. 필자는 개발자의 관점에서 쓴 '애자일에 대한 고찰' 을쓰면서 한 동안 애자일에 대해 많은 고민을 해왔다. 어떻게 실천하는 것이 좋은 것이고, 어떤 애로사항이 있는지에대해서 말이다.

애자일(Agile)과 스크럼(Scrum), 린 소프트웨어(Lean), 그리고 칸반(Kanban)과 같은 툴 등의 방법론적인 관점에서가장 대표적인 두 가지 목적에 도달하기 위한 목표를 가지고 있다.

  1. 빠른 개발과 효율성 증대, 품질 좋은 소프트웨어 납품
  2. 낭비의 제거

그리고 개발 방법을 잘 적용하기 위해서는 '사람', 즉 소프트웨어는 사람과 사람에 의한 것이라는 대 주제로 귀결된다.

바로 필자가 이야기 하려던 것이다. 소프트웨어 공학=개발 프로세스(방법론) 이라는 성립될 수 없는 공식이 성립이 된다는 것이다. 소프트웨어 공학이 소프트웨어를 빠르게 개발하기 위한다는 것이 포커싱이 되는 것은 개발 단계일 때 뿐이다. 애자일 등의 방법론은 개발을 빨리 하기 위한 방법이 맞다. 그래서 도구를 잘 이용해야 한다고 한다. 형상 관리와주기적인 통합과 빌드, 배포, 테스팅. 즉, 절차지향적인 기존의 방법을 미리 조금씩 적용함으로써 큰 사건(?)을 작은 사건으로 쪼갤 수 있으므로, 이를 빠르게 대응하기 위한 비용과 리소스도 줄어들게 된다.

그런데 말이다. 개발 단계를 벗어나면 소프트웨어 공학과 빠른 개발과는 전혀 이치에 맞지 않는 상황이 된다.

분석 단계를 보자. UML(Unified Modeling Language) 을 대신해 DSL(Domain Specific Language) 로만 이야기 해보자. (고객이나 실무자가 UML 을 알 필요는 없기 때문에 UML 은 제외한다.) 분석을 경험해본 독자라면 분석가(또는 아키텍처)의 용어와 고객이 사용하는 용어가 다르다는 것을 익히 알고 있을 것이다. 설령, 용어를 특정 단어라고 이해해도 좋다. 도메인 업무의 깊은 지식을 갖고 있는 고객의 한 문장을 도메인 지식이 앝은 분석가가 모든 의미를이해할 수 없다. 예를 들어, 관공서와의 민간 시스템간의 통신에 사용되는 "전문" 이라는 단어는 도메인 지식이 깊은 고객에게는 전문 송수신 이후에 내부 시스템적으로 변화가 일어나는 모든 속성에 대해 알고 있지만, 분석가에게는 통신 프로토콜과 전문의 스키마, 콜백 방법 에 대한 이해만 있다면, 아키텍처는 설계 단계에서 기간과 비용,인력 등을 잘못 설계할 수 있다. 필자 또한 이러한 고객의 용어를 깊이 이해하지 못하여 실제로 프로젝트 제안서를작성하고 프로젝트 투입 후 돌이킬 수 없는 실수를 한 적이 있다.

또 다른 예로, 소프트웨어 유지 보수 단계를 보자. 소프트웨어가 모두 납품이 되고 품질도 검증이 되어도, 잠깐 사용하려고 개발된 것이 아니다. 적어도 5년 이상 시스템을 운용/운영하기 위해 유지 보수를 하게 된다. 최종 소프트웨어 사용자의 요구 사항이 변할 수 있고, 관련 업종의 법이 변경되어 시스템의 일부분을 고쳐야 하는 경우도 생긴다. 예를 들어, 병원의 예약 시스템이 있다고 가정해보자. 예전에는 외래 환자는 병원을 방문하여 접수만 하면 되었지만, 선택진료제도라는 법이 생겼다. 이제는 외래 환자는 자신이 원하는 의사 선생님에게 진료를 받을 수 있게된 것이다. 물론, 시스템을 당장 바꾸는 것은 아니다. 변경될 법에 대한 내용을 미리 고시하기 때문에 정해진 기간안에만 제도에 맞게 시스템을 변경하여 릴리즈를 하면 된다.

일부만 요약해 보자.

  • 소프트웨어 요구 사항 수집
    고객과 분석가 간의 정확한 목적과 목표를 이해. 고객의 용어를 공통적인 언어(표현)로 표현하기 위해DSL을 사용한다. 요구 사항을 빨리 수집하기 위해 DSL 을 사용하지 않는다.
  • 소프트웨어 설계
    UML 등을 이용하여 설계를 한다. DSL(고객과 분석가 간의 모델)이 소프트웨어적인 언어로 변경되어야 한다. 그래서 UML을 사용한다. 필자의 블로그의 "개발자도 알아야 할 응용 프로그램 모델링1~7회" 까지 살펴보는 것도 좋다.
  • 소프트웨어 개발
    애자일과 같은 개발 방법은 소프트웨어 공학에서 다루는 대부분을 요약하여 빠르고, 높은 품질의 소프트웨어 개발을 지향한다.
  • 소프트웨어 유지 보수이 때부터는 소프트웨어는 항상 심장이 뛰고 숨을 쉬고 있다. 그렇기 때문에 안정성을 확보하는 것이가장 우선이다. 버그가 있는 릴리즈를 엄청난 손해를 끼치게 된다. (실제로 국내 쇼핑몰에서 간간히 발생하는데, 분 단위마다 억대의 손실이 발생한다고 업계 관계자에게 들은 바 있다.) 이제는 운영 프로세스가 도입되는 시점이다. 개발된 소프트웨어, 그리고 소프트웨어를 호스팅하는 하드웨어, 네트워크,스토리지 등 애자일과 같은 개발 프로세스는 여기에 비하면 빙산의 일각이다. 운영 프로세스 중 마이크로소프트의 MOF(Microsoft Operations Framework) 를 참고바란다.

소프트웨어 공학과 소프트웨어 팩토리, 소프트웨어 개발 프로세스는 별개…

이미 언급한 바, 우주/물리학에서 블랙홀의 질량이 무한대(∞) 에 대한 수수께기가 벗겨진다면 우리의 우주적인생각/시점/관념은 전혀 새롭게 바뀔 수 있다. 그리고 우주적인 학문적인 깊이는 더욱 깊어지고, 이로인하여 새로운 우주 시대를 맞이할 수 있다. 우리가 살고 있는 우주의 최초는 빅뱅이 아닐 수도 있고, 우리가 살고 있는 우주가 유일한 우주가 아닌, 다중 우주론일 수 있다. 단지 이것들이 가설로만 존재하는 이유는 아직 수학적으로 증명을 하지 못했기 때문이다.

다른 학문들이 발전하면서 소프트웨어 공학은 발전해 왔다. 특히 소프트웨어 공학이 이야기하는 10가지는 각 단계마다 의사 소통 또는 언어가 틀리기 때문에 어렵다. 고객과 분석가 간의 언어, 아키텍처와 아키텍처간의 언어, 아키텍처를 소프트웨어 개발을 위한 코드로 알게 하는 언어, 소프트웨어 개발 언어가 하드웨어가 알도록 하는 언어,소프트웨어 테스트를 위한 테스팅과 테스터간의 언어 등… 소프트웨어는 공학은 언어를 언어로 바꾸는 학문이기도 하다. 마치 구글 번역기 처럼 빨리 번역된다고 개발 성능이 나아지는 그런 것들과는 거리는 멀다.

소프트웨어를 빨리 개발하기 위해 소프트웨어 팩토리나 소프트웨어 개발 프로세스 등은 이미 많이 널려있다. 소프트웨어 팩토리나 소프트웨어 개발 프로세스는 이미 많은 사람들에 의해 빠른 개발에 필요한 요소임이 증명이되었다. 물론 칼자루를 쥔 사람이 누구냐에 따라서 다르겠지만, 이런 방법들은 현재도 꾸준히 논쟁의 대상이기도하지만, 소프트웨어를 빨리 개발하기 위한 방법들은 지금도 계속 현장에서 검증하여 나온다.

소프트웨어 공학은 그 깊이를 아직 대다수의 사람들은 모른다. 자신의 학문적인 깊이를 잴 수 없으니 공학적 깊이를 잴 수 없는 것이 당연하다. 분명한 것은 소프트웨어 개발 프로세스나 소프트웨어 팩토리, 그리고 다양한 개발 방법들은 소프트웨어 공학에서 하나의 작은 일부이다. 소프트웨어 공학은 계속 발전하고, 이론에 머물러 있는 것들이 많을 것이다. 실제로 개발 프로세스에 대한 것들만 보아도 들어보지도 못한 개발 프로세스나 방법들이 무수히존재한다. 그것을 검증하고 경험하는 것은 우리의 몫이지 공학 자체가 답을 제시해 주지는 않는다.

빛 보다 빠른 어떤 물질을 발견한다면 아인슈타인의 상대성 이론은 엉터리 이론이 될 것이다. 왜냐하면 어쨌든 틀린 이론이 될 것이기 때문이다. 하지만, 상대성 이론이 깨진다고 하여도 학문적으로는 엄청난 업적이자 이를 이해하지 못하면 더 깊은 지식을 이해하기 힘들 수 있다. 마찬가지로, 개발 프로세스가 엉터리이고 빨리 개발 할 수 없는 방법일지라도 그것이 우리가 사용하는 개발 프로세스를 있게 한 일부이고, 학문적인 부분의 하나의 작은 일부분일 것이다. 바꾸어말해, 빨리 개발하기 위해 학문이 존재한다는 것이 아니라는 말을 하고 싶다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

협업이 필요한 이유

최근의 소프트웨어 개발은 점차적으로 엔터프라이즈화 되어 가고 있습니다. 대용량/대규모화 되어가고 있는 현대의 소프트웨어 생태계에서 마치 새로운 트랜드로 자리잡고 있는 엔터프라이즈 2.0 이 자리를 잡고 그 규모를 넓혀가고 있습니다. 엔터프라이즈 2.0 은 Web 2.0 과 결합된 의미로써 즉, Enterprise social software(http://en.wikipedia.org/wiki/Enterprise_2.0) 라고 보아도 크게 의미는 다르지 않습니다.    

엔터프라이즈 소프트웨어는 대용량/대규모/보안 등의 핵심 키워드로 그 아키텍처가 매우 민감한 부분이기도 합니다. 하지만 엔터프라이즈 2.0은 기존 엔터프라이즈에 개방/공유 등을 강조하면서 바로 협업과 맞물리는 부분이기도 합니다. 그리고 이러한 움직임은 국가적인 차원의 거버먼트 2.0(http://blog.powerumc.kr/252)과 매우 유사하기도 합니다.    

즉, 중요한 것 중 현대의 소프트웨어 개발은 더 이상 폐쇄적인 환경을 거부하며, 최소한의 자원과 리소스를 아끼고, 남은 자원을 극대화하여 새로운 가치를 생산하고자 한다는 것입니다. 단지, 소프트웨어 개발은 개발자 역량만 훌륭하다고 되는 것이 아니며, 개발자간의 원활한 커뮤니케이션, 각 팀과의 원활한 커뮤니케이션, 더 나아가 조직과의 커뮤니케이션과도 연관 고리가 존재하게 됩니다.    

콩 심은 곳엔 콩이 나고, 팥 심은 곳엔 팥이 나야 하지만, 실제 프로젝트에서는 콩 심은 곳에 팥이 나기도 합니다. 협업을 하다 보면 협업 자체가 어려운 것이 아니라, 사람을 대하는 것이 가장 어렵다는 것을 느낄 수 있을 것입니다. 그래서 애자일(Agile) 한 방법론이 최근 팀과 조직에서 관심의 대상이 되는 것과 같은 이치입니다. 애자일 방법론을 잘 하기 위해서는 사람과 인간성을 이해하고 신뢰를 쌓는 것이지만, 그렇게 애자일하게 너그러운 사람과 팀, 조직은 그리 흔하지 않습니다.    

그렇다면 뭐가 문제일까요? 사람을 대하는 것이 어렵고, 고로 협업을 하는 것이 어렵고, 고로 전체 프로젝트를 수행하는게 어렵습니다. 개개인의 인격과 인간성을 존중하기엔 시간이 넉넉치 않을 뿐더러, 그들 간의 업무를 조율하는 것은 더 어려워지고, 점점 위태로운 프로젝트가 되기도 합니다. 물론 필자 또한 이런 문제의 발원지가 되기도 해보았고, 이것을 조율하는 입장도 되어 본 경험입니다.    

그럼 이미 답은 나왔습니다. 바로 "강제성" 을 부여하는 것입니다. 강제성이라고 하면 오히려 비 애자일하다고 할 수 있겠지만, 바꾸어 말하면 "당신 하나 때문에~" 애자일을 하는 것이 아니라는 것입니다. 가장 표준적이면서도 쉬운 방법을 통해 목표의 방향성을 가지고 간다는 것이 더 중요할 수 있기 때문입니다.

      

어떻게 커뮤니케이션을 할 것인가?

사람과 사람, 팀과 팀, 조직과 조직, 기업과 기업, 이들 간의 커뮤니케이션은 매우 다양합니다. 메신저, 이메일, 그 밖에 다양한 방법이 존재합니다.    

   

사람마다 선호하는 방법은 틀리겠지만, 개인적으로는 메신저야말로 가장 업무적으로 방해가 되는 커뮤니케이션 방법이라고 생각합니다. 언제나 급한 분들에게는 가장 좋은 커뮤니케이션 방법이 메신저가 될 수 도 있을 것입니다.    

제가 가장 좋아하는 커뮤니케이션 방법은 이메일입니다. 제가 이메일을 열람하고 싶을 때 보고 업무를 처리하면 되니까요. 하지만 이메일은 기록되고 보관되기 때문에 가장 책임감을 발휘해야 하는 커뮤니케이션 방법이기도 합니다. 하지만 요즘 스마트폰의 열풍으로 직장이든 가정이든 이메일을 볼 수 밖에 없는 현실이 되었죠^^;    

최근에는 SNS 와 같은 방법으로 커뮤니케이션을 하기도 합니다. 우리가 흔히 알고 있는 트위터(Twitter) 와 같은 Public SNS 도 존재하지만, 기업 내에서 사용할 수 있는 Private SNS 도 있습니다. 간단 명료한 메시지라는 강점으로 최근 유행하는 방식이기도 합니다.    

 

Team Foundation Server 의 구성 요소를 통한 커뮤니케이션

Team Foundation Server(이하 TFS) 는 단독적으로 사용할 때 보다 여러 가지 구성 요소를 갖출 때 비로소 가장 효과적인 커뮤니케이션 방법을 제공해 줍니다.    

최소한으로 TFS 는 SQL Server 를 필요로 하며, SQL Server 는 TFS 를 통해 소스 제어(Source Control), 리포팅(Reporting) 서비스를 제공해 줍니다. Team Foundation Server 를 사용하는 목적으로 SQL Server 라이선스를 일부 무료로 제공하기 때문에 가장 저렴한 비용으로 커뮤니케이션을 할 수 있는 방법입니다.

이를 이용하여 최소한으로 이행할 수 있는 여러 가지 기능이 있습니다.

  • 소스 제어(Source Control)
  • 소스 코드 브랜치(Branch)
  • 리포팅 서비스 및 데이터 웨어하우스(Reporting Services and Data Warehouse)
  • 일부 오피스(Office) 제품 연동

       

   

하지만 위의 방법으로는 조금 부족한 감이 있습니다. 마찬가지로 Team Foundation Server 를 사용하게 되면, SQL Server, Sharepoint Server 의 일부 라이선스를 무료로 제공하기 때문에 더욱 효과적인 커뮤니케이션 인프라를 구축할 수 있습니다. 특히 SharePoint 는 팀 포털과 문서 관리의 이점 뿐만 아니라, 팀 워크플로우를 개선할 수 있는 다양한 방법을 제공합니다. 특히 큰 규모에서는 의사 결정권이라는 막강한 권한이나 프로세스가 존재하게 되는데, SharePoint 는 이러한 워크플로우를 상당히 효과적으로 개선할 수 있는 솔루션이기도 합니다.

  • 소스 제어(Source Control)
  • 소스 코드 브랜치(Branch)
  • 리포팅 서비스 및 데이터 웨어하우스(Reporting Services and Data Warehouse)
  • 다양한 오피스(Office) 제품 연동
  • 팀 포털, 문서 관리, 팀 프로세스 개선

   

최근 가상화(Virtualization) 를 기반으로 클라우드 서비스가 매우 큰 개발 및 비즈니스 영역으로 자리잡고 있습니다. 소프트웨어 가상화는 물론이고 우리가 흔히 알고 있는 하드웨어 가상화 등 이러한 서비스 가상화를 통해 이전에는 상상하기 힘들거나 환경을 구성하기 힘든 영역까지 모두 커버하고 있습니다. Microsoft 에서는 이것을 가리켜 Dynamic IT 라고 칭하고 있습니다.

   

그 중, System Center 솔루션은 매우 다양한 역할을 수행합니다. 가상화 인프라와 서버 모니터링을 위해 다양한 솔루션은 아래와 같습니다.

솔루션

설명

SCVMM

(System Center Virtual Machine Manager)

물리적인 서버 또는 가상화의 서버를 관리, 배포, 최적화하는 솔루션이다. Hyper-V 또는 VMWare 등 여러 가상화 플랫폼을 지원한다.

SCOM

(System Center Operation Manager)

데이터센터의 운영을 중앙 관리를 위한 솔루션이다. 분산되어 있는 서버의 상태, 성능 정보, 구성 또는 보안 상태를 감지한다. 윈도우 운영체제와 리눅스(Linux), 유닉스(Unix) 운영체제 의 리소스나 그 하위 구성요소를 모니터링 할 수 있다.

SCCM

(System Center Configuration Manager)

운영체제 배포, 보안 패치, 서버/데스크탑 정책, 모바일 정책 등 총체적인 서버 및 클라이언트의 구성을 관리하는 솔루션이다. 기업의 네트워크 내의 모든 컴퓨터를 대상으로 강제 업데이트, 필수 구성 요소 등을 정책적으로 강제화 할 수 있다.

   

SCVMM(System Center Virtual Machine Manager) 은 가상화를 통한 동적 서버 관리, 가상화를 통한 유지 관리 계획, 가상화를 통한 테스트 및 개발 환경 의 작업을 관리하고 단순화 위한 가상화 관리 솔루션입니다. 가상화 서버를 관리를 용이하게 하고, 물리적인 서버를 가상화로 쉽게 전환하거나 가상 호스트에 여러 개의 물리적 서버를 통합할 수 있습니다.

특히 이 솔루션은 ALM(Application Lifecycle Management) 솔루션 중 Team Foundation Server 2010 에서 테스트 가상화를 사용하기 위해 필요한 구성 요소이기도 합니다.

   

SCOM(System Center Operation Manager) 는 분산되어 있는 데이터 센터를 통합 관리를 하며 윈도우 운영체제 뿐만 아니라 다양한 리눅스, 유닉스 기반의 운영체제를 지원합니다. 이 솔루션을 이용하면 특정 장애나 서비스 성능, 가용성을 보장하기 위해 자동으로 조치를 취하도록 할 수 있습니다.

   

SCCM(System Center Configuration Manager) 는 네트워크 인프라에 존재하는 클라이언트 컴퓨터, 서버 컴퓨터 등의 구성을 중앙에서 관리합니다. 예를 들어, 일부 클라이언트 사용자의 컴퓨터는 윈도우의 업데이트를 꾸준히 사용하지 않는 경우가 있습니다. 이러한 경우 강제적으로 업데이트를 수행하도록 정책적으로 관리를 할 수 있습니다. 그 밖에 윈도우 방화벽 설정, 자동 업데이트 및 백신 프로그램 등을 정책적으로 설치되거나 구성하도록 강제화 할 수 있습니다.

   

   

현재 협업을 위한 기본적인 기반 환경은?

단지, 필자가 오늘 하고 싶은 이야기는 여러분들에게 여러 가지 솔루션이 이를 대체할 것이라는 암시를 주는 것이 아닙니다. 단지 협업은 혼자만의 노력으로는 불가능 한 것이며, 이것을 뒷받침해 줄 수 있는 도구가 있다는 것에 감사할 뿐입니다.    

대부분의 우리나라 조직은 상하 수직적인 관계입니다. 일을 던져주고, 그것을 받고 일을 하는 수직적인 줄타기 방식은 작업의 결과를 매우 가시적이고 평가하기 쉬운 방법입니다. 그리고 이런 방식에 저 또한 매우 길들여져 있으며, 일을 수행하는 입장에서도 매우 수월합니다. 수행 결과를 보여주기도 쉽고, 처리하기도 쉽습니다.    

다만 수평적인 조직(절대적인 수평은 없을 것이지만)에서는 오히려 상하 수직적인 방식과는 다릅니다. 항상 중간 과정에 서로의 동의와 협력이 필요하며, 그 성과 또한 개인의 성과가 아닌 우리의 성과가 될 테니까요.    

하지만, 여러 조직과 기업이나 프로젝트에서 일을 해 본 경험으로, 절대적인 상하 수직적, 수평적인 조직은 없다는 것입니다. 그리고 필자 또한 어떤 것이 바람직한지 아직은 확신을 하기 어렵습니다. 다만, "그때 그때 잘~" 이라는 것밖에는 ^^    

팀워크(Team Work) 란 팀이 무너지지 않고 존재할 수 있는 가장 큰 힘을 발휘합니다. 반대로 팀 워크가 수년간 같은 방식이고 개선되지 않고 제자리에 머물러 있다면 썩은 우물과도 같습니다. 왜냐하면 시대가 변함에 따라 개개인의 커뮤니케이션 방식은 바뀔 것이며, 점차적으로 개선되어 지지 않는다면 팀 워크가 아닌 커뮤니케이션 자체의 문제의 한계에 부딪히게 될 것입니다.    

일단 오늘은 협업에 대해 썰을 풀어 보았습니다. 그리고 협업을 위한 많은 노하우를 여러분들에게 알려드리고 개선해 나가고자 합니다. 언제든지 불편한 내용이나 피드백을 주시면 참고하여 개선하고자 하도록 하겠습니다.

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 2010.07.18 12:23 Address Modify/Delete Reply

    비밀댓글입니다

  2. 2010.07.18 20:05 Address Modify/Delete Reply

    비밀댓글입니다

애자일에 대한 고찰에 앞서 먼저 '정말 TDD 필요한가?' 대해 이야기 부터 시작해봅니다.


애자일에 대한 고찰

애자일 프로그래밍이 도마에 오르면서 단연 단위 테스트(Unit Test)와 TDD(Test Driven Development) 를 빼놓을 수 없습니다. 단위 테스트와 TDD는 상호 공생 관계에 놓이면서, 둘 중 어느하나 포기하기 쉽지 않습니다. 왜냐하면 TDD에 대한 이상론자들은 TDD의 중요성을 매우 높이 강조하고 있기 때문입니다.

필자는 이에 대해 정말 개발에 TDD가 얼마나 좋고 효과가 좋은지 사실 산술적으로 검증할 수는 없다고 생각합니다. 좋은 것이 있는 많큼 잃는 것도 있을테니까요.


TDD 를 해야한다는 관점

일반적으로 코드를 작성한 후에 그 기능을 테스트하는 코드를 작성하는 것을 단위 테스트라고 합니다. 단위 테스트를 작성함으로써 결함없는 소프트웨어를 만들기 위한 지속적인 통합(CI-Continuous Integration) 라는 관점에서 상당히 효과적인 방법입니다.

여기에서 TDD 는 단위 테스트를 작성하는 단계의 순서를 기존의 Last 에서 First 로 바꾸면서, 단위 테스트 코드를 먼저 작성하도록 하는 방법입니다. 처음 오류가 날 수 밖에 없는 코드를 테스트하면서 Red, Green, Refactor 단계로 옮겨가도록 하는 기법입니다.

사실 이런 저런 TDD 의 효과중에 단연, 코드가 매우 견고해진다는 큰 장점이 있습니다.    

 

처음부터 기능을 구현하는 코드를 작성하게 된다면, 클래스와 메서드를 잘 분리한다고 하더라도 한 클래스나 메서드는 생각지도 않게 기능의 크기가 커질 수 밖에 없습니다. 왜냐하면 코드 작성자는 코드를 만드는 목적이 기능이 정상적으로 작동해야 한다는 전제하에 코드를 만들기 때문에 오류 없는 코드가 목적이기 때문입니다.

또 한가지 TDD를 하지 않는다면 코드의 리팩토링을 코드가 완료된 이후에만 가능하다는 것입니다. 지속적으로 이런 문제는 소프트웨어의 디자인이 바뀌거나 오류가 발생하지 않을 경우 굳이 리팩토링을 하지 않게 되죠.

결국 어떤 이유에서든지 좋은 코드를 만들기 위해서는 TDD가 매우 좋은 기법이 될 수 있습니다. 쉽게 Database 를 예로 들자면, 초기에 테이블을 정규화할 것인지, 나중에 문제가 생길 경우 정규화를 할 것인지의 고민과 유사하기도 합니다. 하지만 절대 변하지 않는 진리는, 처음부터 갈귀갈귀 정규화를 한 것을 합치는 것은 쉬워도, 통짜를 분리하는 것은 사실 엄청난 리스크가 됩니다.


TDD 를 하지 말아야한다는 관점

개인적으로 필자는 이 부류에 속하기도 합니다. 누구든 TDD를 알게 되면 그것이 가지는 이상적인 효과를 이해할 수 있습니다. 하지만 살짝 TDD에 발가락을 담구어보면 금방 TDD에 대해 의심을 하게 됩니다. 바로 TDD를 해보면 너무 어렵다는 것입니다.

첫번째로 Red, Green, 그리고 최종적으로 Refactor 단계로 가는 과정이 오래 걸리고 어렵습니다. TDD코드를 만들기 시작하는 순간부터 리팩토링의 시작이며, 길지 않은 코드조차 굉장히 버겁다는 것을 알 수 있죠. 정말 지루하고도 기계적인 과정입니다.

두번째는 이미 언급했다시피 지루하고도 기계적인 과정입니다. 즉 TDD기법으로 생상되는 코드는 기존에 코드를 만들고 테스트하는 예상 시간이 +a 가 됩니다. 코드의 양에 비례하여, 'stub(코드의 양) * alpha(가중치) = TDD 수행시간' 이라는 대략적인 예측 소요 시간이 걸릴 것입니다.

 

TDD의 시작은 곧 리팩토링의 연속입니다. 아무리 개발 도구가 좋아진다고 하더라도 사람이 하던 리팩토링을 대신해줄 수는 없을 것입니다. 즉, TDD기법을 도입하기 위해서 기존 방식의 산술적인 계산법으로 더 이상 기간과 공수를 예측할 수 없습니다. 분명 시간과 비용이 터무니없이 증가할 것입니다.

아마도 우리나라에서는 TDD를 조직내에서 개발 방법으로 채택하는 곳은 없다고 봅니다. 우리나라에서는 소프트웨어의 생산 기간을 어떻게 줄일까에 집중하고 있기 때문에, TDD는 팀과 조직의 goal 에 방해 요소만 뿐입니다. 효용성 측면에서 TDD 본다면 그저 좋은 개살구로 보이기 쉽기 때문입니다.


애자일을 명목으로 스스로 족쇄를 차고있는 우리 조직

애자일이라는 이름과 이상적인 가이드를 이행하려는 조직에서 특히 불화음이 많을 것입니다. 그리고 그들은 애자일을 해 본 결과 애자일은 왜 실패하냐는 물음을 던집니다. 사실 애자일이 가지는 그 사상은 굉장히 높이 살만 합니다. 기존의 폐쇄적인 조직을 개방하려는 의지를 보인다는 것으로 시작하여 팀간의 커뮤니케이션을 향상시키도록 합니다.

그런데 애자일을 도입하려는 사람들은 큰 함정에 빠집니다. 팀을 위한다는 명목으로 너무 많은 것을 팀에게 강요합니다. 자신이 바라보기엔 좋은 기법들이 많고 팀에게 전파하려고 노력하겠지만, 팀은 이미 기존에도 잘 되고 있는 부분을 왜 뜯어고치려는지 이해할 수 없기 때문이죠. 팀에게 변화라는 명목으로 팀원들의 공감을 얻지 못한채로 강요를 시작하게 됩니다.

사실 애자일한 팀과 애자일한 프로그래밍을 위해 애자일은 아무것고 강요하지 않습니다. 그런데 누군가의 손에 애자일이 쥐어지면 은근히 강요로 변질되는 경우가 대부분입니다.

 

애자일 중에, 특히 XP(eXtreme Programming) 는 우리나라 실정이 전혀 반영되지 않았습니다. XP 의 여러가지 기법 중에 특히 코드 리뷰 와 짝 프로그래밍이 대표적이죠. 짝 프로그래밍은 짝이 되어 서로의 생각과 노하우를 전수해 주는 기법이지만, 필자로써는 '글쎄…'

필자는 오히려 짝 프로그래밍을 함으로써 개인 업무 시간을 너무 할애당한다는 생각이 듭니다. 필자가 메신저의 채팅보다 이메일을 좋아하는 이유도 여기에 있습니다. 업무 진행에 탄력을 받다가도 채팅으로 내 생각의 컨텍스트가 강제로 전환됩니다. 생각이 정리되지 않은 상대편이 타자를 치고있는 것을 멍하니 바라만 봅니다. 기술적인 것을 물어볼땐 답을 알려줘도 채팅이라는 특성상 한번에 한줄의 글로 모든 것을 표현하기가 힘듭니다. 만약 이메일이었다면 보낸 사람도 생각을 정리해서 보냈을테고, 또한 내가 보고싶을 때 보고, 명쾌한 MSDN 링크와 곁들여 오히려 짧은 시간에 높은 성과를 낼 수 있을텐데요...

결국 짝 프로그래밍은 그것을 성취한 후의 성과가 소비된 리소스에 비해 턱없이 낮으며, 짝 프로그래밍의 특성상 지속성을 유지하기에 한계가 있습니다.

 

또, 코드 리뷰를 진행하기 위해 다양한 기법들과 절차를 선보입니다. Self Review, Pair Review, Team Review 등 전혀 현실을 고려하지 않고 단지 그 기법들에 대해서만 매달리는 사람들이 많습니다. 특히 코드 리뷰는 도구를 이용한 자동화를 하지 않을 경우 있으나 마나한 기법입니다. 장기적으로 코드 리뷰는 형식적일 수 밖에 없습니다.

더 중요한 것은 코드 리뷰 기법이 아니라, 프로세스적으로 이것을 통제하여 코드 리뷰 책임자를 두는 것이 효과적일 수 있습니다. 보안이나 성능 등에 관련하여 코드 리뷰의 책임을 위임하고, 보안이나 성능 문제 발생시에 책임을 물을 수 있도록 체계화된 프로세스 말입니다.

사실 이런 면에서 기존의 애자일인 XP(eXtreme Programming) 이나 스크럼(Scrum) 보다 MSF(Microsoft Solution Framework) 기존 애자일 방법론을 현실적이고 수행가능하도록 체계화시킨 프로세스이기도 합니다.

   

입장이 서로 다른 애자일

대부분 현장에서 개발하시는 분들은 내 옆의 동료나 우리 팀보다 자기 개인이 더 중요할 것입니다. 개인 업무 성과가 팀과 조직이 나를 판단하는 기준이 대부분의 경우이기 때문입니다. 또 어떤 경우는 개발자의 특성상 발언권이 없는 경우도 있을 것입니다.

이에 반해 팀의 관리자의 평가는 자신이 관리하는 팀 전체의 성과가 조직이 관리자를 판단할 것입니다. 팀 프로젝트나 팀의 업무 성과가 낮다는 것은 관리자의 능력과 비례하기도 합니다.

 

결과적으로 애자일이라는 공통 분모로 애자일의 목표를 이루고자하는 시각이 전혀 다르다는 것이죠. 서투른 애자일은 팀원의 불만만 증가할 뿐, 팀원과 공감대를 이루기 힘듭니다. 관리자의 입장에서는 팀원간의 커뮤니케이션을 높이고 팀원 스스로 변화하길 기대하고 이것이 소리없는 강요가 될 수 있습니다.

   

애자일을 성공시키기 위해

앞서 이야기한 바와 같이 애자일이라는 목표와 사상은 굉장히 좋습니다. 그것이 팀과 조직뿐만 아니라, 개인, 가족, 단체, 사회, 국가적으로 비유해도 좋은 모델이 될 것입니다. 하지만 애자일, 특히 XP 가 이루는 그 구성 요소들은 조금은 허무맹랑한 것들이 많습니다. TDD나 짝 프로그래밍, 코드 리뷰 등 현실성이 부족한 것들을 이행하기를 권장합니다. 적어도 우리나라에서는 그것을 이행하기 위한 주변 여건이 좋지만은 않지요.

 

예전 트로이 목마라는 전쟁 이야기에서 나오듯이, 적진에게 해를 가하기 위해 트로이 목마를 적진에게 가져다 놓았습니다. 적진은 트로이 목마를 보며 마치 신이 주신 선물로 생각하겠지만 정작 트로이 목마는 적군에게 해가 되는 무시무시함을 가졌습니다.

과학에서 모든 물체는 현재 상태를 유지하려는 힘, 관성을 가지고 있듯이 우리의 팀과 조직도 마찬가지 입니다. 애자일도 마찬가지로, 그것이 좋아보인다고 자신의 팀과 조직에 구역구역 쑤셔넣다보면 상태를 유지하려는 관성을 가진 구성원과 바로 맞닿을 수 있습니다. (물론 애자일이 해를 가한다는 의미는 아닙니다)

   

 

애자일이 추구하는 여러 구성 요소는 짧은 반복으로 결과물의 품질을 높이고 결함을 줄이고자 합니다. 애자일의 대부분의 구성 요소는 짧은 반복으로 인한 높은 위험성을 줄이기 위한 보조적인 수단이라는 것입니다. 예를 들면, 스크럼(Scrum) 을 도입한다고 해서 대시보드와 붙이는 메모지를 준비하고, 매일 매일 스크림 미팅을 할 필요는 없습니다. 스크럼 미팅이라는 형식에 갇히는 순간부터 자멸의 길이라는것을 뒤늦게 깨닳게 될 것입니다. 즉 스크럼 미팅은 매일할 필요도 없으며 어떤 다른 모습으로 바뀔 수 있고, 동료와 담배를 피거나 커피를 먹으면서 알게 모르게 나타날 수도 있습니다. 어떤 경우는 상대편 알게 모르게 하는것이 자연스러운 참여에 도움이 되는 경우도 있지요.

결론적으로 팀과 조직, 구성원 개인의 차이를 인정하고, 팀과 조직의 문화를 최대한 유지하는 것이 성공하는 애자일이 되는 것입니다. 필자 또한 이것을 깨닿기까지 많은 시행 착오를 겪으며 애자일로 인한 물음표에 종지부를 찍을 수 있었습니다. 즉, 애자일로 스스로에게 족쇄를 차지 마십시오. 족쇄를 끊은 후에야 진정한 애자일이 당신의 곁에 있음을 느낄 수 있을 것입니다.

 

Posted by 땡초 POWERUMC

댓글을 달아 주세요

  1. 박형근 2010.03.14 20:05 Address Modify/Delete Reply

    좋은 글 잘 읽었습니다.^^
    저는 애자일 도입을 진행하는 쪽인데, 확실히 조심해야 하는 점들이 많은것 같습니다.
    또 다른 관점에서 애자일도입을 생각하게 하네요~

    • 땡초 POWERUMC 2010.03.14 22:04 신고 Address Modify/Delete

      애자일이 우리에겐 개선이지만,
      누군가에겐 혁명일 수 있지 않을까 하는 생각이 드네요.

      박형근님의 블로그에 좋은 글
      잘 보고 있습니다. ^^

  2. 레브민호 2010.03.17 18:23 Address Modify/Delete Reply

    좋은글이네요 ^^
    저의 경우 인도기업에 있을때 경험을 조금 적어보자면..
    JUnit으로 TDD를 유지하면서 저희팀6명은 3개모듈로 나누어 2명씩 짝을 이루어서 같이 모듈개발을 했었죠. 중요한부분은 함께 의논하면서 프로그래밍을 했었고, 코딩이 분명한 부분은 한명이 개발을 하고 한명은 테스트코드로 테스트를 돌렸습니다. 중요부분을 개발하다 막히면 서로 시간을 갖고 관련 자료를 각자 찾고나서 다음날 병합하여 의견을 교환했죠.
    그리고 코드리뷰는 모듈별 일정에 맞추어 Team 리뷰를 했었는데 미리 달아둔 주석을 다큐먼트로 추출해서 나눠주고 핵심만 설명하는게 아닌 전체 흐름에 중심을 두고 부분부분 사용된 알고리즘을 설명하는 식으로 진행했었죠.

    그때는 이게 페어 프로그래밍이다, TDD이다.. 이런 의식없이 진행되었던 것 같습니다.
    제가 생각할때 이러한 것들을 성공적으로 하기 위해서는 이것들을 자연스럽게 수행할 수 있도록 하는 환경 그 자체가 우선되어야 하지 않나 싶습니다. ^^

    • 땡초 POWERUMC 2010.03.18 10:03 신고 Address Modify/Delete

      민호님은 정말 좋은 경험을 하셨네요..^^
      팀이 발전적인 마인드를 갖고 있다면 더할 나위 없는
      환경이라고 생각합니다.

      우리나라는 의견 교환의 시간이
      자기 영역 방어체계 구축하고, 잡아 먹어야 이길 수 있는 것 같아요.
      ^_^;