내가 지금까지 접해본 여러 이론/실천법 들을 통틀어 가장 맘에 드는 것들을 세 가지 고르라면 TDD, Refactoring, Scrum, 이렇게 세 가지를 뽑겠다. (우리 조직에선 이 중 단 하나도 하지 않고 있어서 참으로 답답하고 안타깝다.) 다른 사람들과는 좀 다른 관점일 수 있겠는데, 이들에 애착이 생기는 내 나름의 이유는 간략히 정리해본다.

• Part I – TDD (this article)
• Part II – Refactoring
• Part III – Scrum (not available yet)

TDD (Test Driven Development) – 보통 언급은 되지만 크게 부각되지 않는 장점. 종종 설명에서 아예 빠지기도 한지만, 내가 가장 높게 쳐주는 TDD의 장점은 바로 ‘개발자들의 설계 능력의 향상’이다. 테스트는 곧 사용자의 사용 패턴을 시뮬레이션 한 것으로, 쉽게 테스트하기 위한 고민은 바로 쉽게 사용하기 위한 인터페이스를 고민하는 것이다. 이 과정을 몇 개월만 반복하더라도 테스트하기 쉬운 설계(testable design)와 그 반대의 케이스의 대표적인 사례(testable design anti-patterns)들을 한 다발 발견해낼 수 있을 것이다. 디자인 공부한답시고 UML 다이어그램 책이나 디자인 패턴 책을 열심히 파는 것보다, 자신이 개발중인 코드를 보고 테스트를 어떻게 할까를 고민해보는 것이 훨씬 효과만점이라고 자신있게 주장할 수 있다.

업계에선 이 부분이 잘 수행되지 않고 있는데, ‘테스트 == 설계’ 라는 관계가 잘 부각되지 않기 때문으로 보인다. (아쉽게도 팀원의 역량 향상을 등한시하는 매니저도 제법 있다.) 설계는 중요시하면서도 테스트는 등한시 하는 것이다. 개발자에게 설계를 잘 하라면서도 테스트는 외부 인력에 의존하는 경우가 너무 많다. 테스터들도 자신이 설계를 검증해야 한다는 것을 자각하지 못하고 있고, 혹 있다손 치더라도 설계에 대해 이러쿵 저러쿵 하는 것을 개발팀에서 그리 달가워하지 않는 경우도 종종 있다. 그리고 테스트를 너무 늦게 시작해 설계 문제가 드러나도 일정상 수정하지 못하는 안타까운 상황도 흔히 발생한다.

기본적인 테스트(유닛, 인티그레이션)는 가능한 모두 개발자들 스스로 수행하도록 하고, 외부 인력은 신뢰성, 고가용성, 보안, 스레드 안정성 등 전문 분야에 대해서 검증을 수행해 주는 것이 효율적이다. 개발자 테스트 단계에서도 단순 기능 검증이 아닌 테스트 용이성에 큰 비중을 주도록 꼭! 주지시켜야 한다.

이렇게 훈련된 개발자들은 나중에 혹 테스트 케이스를 작성할 시간이 부족하더라도 처음부터 상대적으로 수준 높은 설계를 만들어낸다. 신입사원들에게 별 쓸모 없는 프로세스나 테크닉 교육은 대폭 줄이고 TDD 나 한 두 달 시켜주면 현업에 훨씬 도움이 될 것이다. 대학과 확원에서도 이론과 테크닉에만 치우지지 말고 이런 실질적인 교육과 훈련에 좀 더 투자를 해야 한다.

다시 한 번 강조하는 것은 ‘개발자‘의 역량 향상이다. 그 효과는 영구적이고 사기 증진에도 많은 도움이 된다. 제품의 설계 향상 같은 단기적인 이점은 그에 비해 훨씬 가치가 적다.

TDD 에 관심이 있는 사람이라면 BDD (Behavior Driven Development – Click Here) 도 한 번쯤 꼭 참고해보도록 하자. TDD 의 발전 형태로 볼 수 있는데, 무엇을 어떤 식으로 테스트해야할 지에 대한 좋은 가이드라인을 제시해준다. 개념을 확실히 인지하고 있다면 전용 툴 지원  없이 전통적인 Unit Test Framework 만으로도 BDD 를 활용할 수 있다.

단순 API 테스트라면 boundary value analysis (Click Here) 와 equivalence partitioning (Click Here) 정도는 확실히 알아두자. 이 둘을 조합하면 많은 경우에 있어 기계적으로 test case 들을 뽑아낼 수 있다. SE, SQA, 혹은 전문 테스터로서 역량을 원한다면 이곳 (Click Here) 도 좋은 레퍼런스가 될 것이다.

아름프로님의 블로그 (Click Here) 를 통해 알게되었는데.. 원본 링크는 여기 (Click Here).

Kanban (Click Here) 에 대한 설명이지만, 평소 agile/scrum 등에 관심이 있었던 사람이면 누구나 쉽게 이해할 수 있을 것이다. Kanban 에 의해 추가된 것은 아래 taskboard 의 각 칼럼에 있는 숫자들인데.. 이는 각 칼럼에 동시에 올 수 있는 최대 task 수를 의미한다. 예를 들어, Selected 에는 최대 2개까지 옮겨 놓을 수 있고, 동시 개발이 허용되는 최대 task 수도 역시 2, Deploy 검수는 1개씩만 허용된다. 이 숫자는 경험에 기반해 최적화가 가능하며, 마지막 그림에 보면 Develop 최대 개수를 3으로 늘렸음을 알 수 있다.

볼만한 아티클이 있어서 소개한다. 사이트 가입이 필요하지만 좋은 글들을 소개해주는 메일이 종종 날아오는 것 정도라 관심있는 사람이라면 오히려 도움이 될 거다.

Principles of Agile Architecture (Click Here)

주제는 제목이 잘 설명해주고 있다. 애자일 방법론이 엔터프라이즈 시장까지 급속히 번져감에 따라 대규모 프로젝트에 적합한 애자일 아키텍쳐링에 대한 노하우를 공유하는 글이다. 내용을 자세히 다루고 싶지만, 해당 사이트의 라이선스 정책을 정확히 몰라 간략히 소개만 하겠다. (읽어보았는데 번역에 대한 명시적 언급은 없고, 승인을 위한 컨텍 주소가 있지만 귀찮다 ㅎ)

이 글에서 제시하는 원칙은 아래의 7가지이다. 자세한 설명은 직접 글을 읽어보자. ^^ (주변인 중 사이트 가입이 내키지 않는 사람에게는 프린트해서 드리죠. ㅎ)

1. The teams that code the system design the system.
2. Build the simplest architecture that can possible work.
3. When in doubt, code it out.
4. They build it, they test it.
5. The bigger the system, the longer the runway.
6. System architecture is a role collaboration.
7. There is no monopoly on innovation.

맛을 보여 드리기 위해 일부만 발췌해 보았다.

1. The teams that code the system design the system.

Scrum 에서 이야기하는 Self Organization(자기 조직화) 와 연관해서 생각해봐도 좋을 것이다. 왜 애자일 팀이 기존 팀 대비 훨씬 능동적이고 활기 넘치고, 또 발전할 수 밖에 없는가에 대한 이유를 잘 정리해놓은 표이다.

6. System architecture is a role collaboration.

1번 원칙에서 이야기한 것 처럼 설계에 대한 기본적인 권한과 책임은 이를 구현하는 팀에게 있지만, 엔터프라이즈 레벨의 대규모 프로젝트에서 각각의 팀에게 모든 것을 맡겨 놓는 것도 그리 이상적이진 않다. 그래서 능력있는 전문 아키텍트나 멀리서 조망하며 큰 그림을 그려나가는 팀도 필요해진다. 그렇지만 여전히 어느 한 팀이나 특정인에게 모든 권한이 위임되지는 않는다. 아래 그림에서 묘사한 것처럼 조직의 여러 팀과 전문가들의 협력에 의해 전체 시스템 아키텍쳐가 발전해나가야 한다.

7. There is no monopoly on innovation.

혁신은 한 번에 일어나지 않는다는 정도로 이해하면 되는데.. 아래는 Rally Software Development 에서 수행해온 방식이라는데 마지막의 hackathon 이 아주 흥미롭다.

Hackathon 의 개념과 기원은 Wikipedia 에 잘 설명되어 있으니 참조하길 바라고 (Click Here), 위의 그림과 연관하여 간략히 설명하면 이렇다. 마지막 한 주 간은, 회사의 미션과 연관된 것이라면, 개발팀 누구나 자신이 관심있는 어떤 주제에 대해서도 자유롭게 탐구할 권한이 주어진다. 이런 기회를 통해 새로운 것을 배우고 사고의 폭을 넓혀가면서 차곡차곡 혁신을 이끌어낼 기반을 다지는 것이다. 구글의 20% 원칙도 같은 맥락에서 바라볼 수 있겠다.

Don’t Code, Write!!

개발자들의 기초 역량 중 특히 부족한 것 중 하나가 품질 높은 코드를 생산하는 능력이다. 그래서 오늘은 고품질 코드 생산에 대한 평소 생각을 한 번 정리해보고자 한다.

본론으로 들어가기 앞서, 내가 말하는 품질 높은 코드란 논리 정연하고 쉽게 읽을 수 있는 코드를 말한다. 결함이 적다는 것은 결과로써 자연히 따라오는 이점일 뿐이다.

자.. 그럼..

왜 대부분의 개발자들은 높은 품질의 코드를 생산해내지 못할까? 왜 수 년간 프로그래밍을 하면서도 코드의 품질은 크게 나아지지 않는 것일까? 환경적인 요인도 물론 있지만, 프로그래밍에 대한 잘못된 인식과 마인드가 더 근본적인 문제로 보인다.

환경적인 요인으로는 일정 압박이 가장 많다. 코드의 품질에 대해 깊게 생각할 여유를 주지 않는 것이다. 특히 한국에서는 많은 프로젝트들이 상당한 일정 압박 속에 진행되므로 낮은 코드 품질에 대한 이유로 가장 많이 거론되는 핑계이다. 충분히 공감은 가지만, 이번 글의 포커스는 이쪽이 아니므로 이쯤에서 다음으로 넘어가보자.

프로그래밍에 대한 잘못된 인식과 마인드란 무엇을 말할까?

Coding. 나는 이 용어를 싫어한다. 습관처럼, 혹은 커뮤니케이션을 위해 평소에는 많이 사용하지만, 지금과 같이 의미를 생각해야 하는 경우는 가능한 사용을 자제한다. 과거 프로그래밍이라는 개념이 처음으로 생겨나고, ‘0′ 과 ‘1′ 로 구성된 기계어 시절부터 어셈블러의 전성시대, 나아가 C 언어 개발자에게 ‘인라인 어셈블리’ 라는 단어가 아직 친숙하던 시절까지는  아무 문제가 없었다. 하지만 지금은 21세기이다. 10년이면 강산이 변한다지만, IT 업계에서의 10년은 강산이 흔적조차 없이 사라질 정도로 긴 세월이다. 이 빠른 변화 속에서 프로그래밍 언어도 진화하였고, 무엇보다 개발 ‘문화’가 크게 바뀌었다. 홀로 세상을 뒤흔들던 천재 개발자들은 살아 있는 화석으로 취급해도 좋을 시대인 것이다. 소프트웨어 규모 증가에 따른 개발 문화를 세 단계로 나눠보았다.

• 태동기 – 한 개인에 의해 모든 개발이 완료되며, 빠른 경우 몇 주 혹은 몇 일 만에 제품이 완성되기도 한다.
• 성숙기 – 소수의 전문 집단에 의해 비교적 짧은 기간 안에 제품이 완성된다. 모듈 구분과 역할 분담이 생겨나고, 모듈간에는 인터페이스를 정의해 다른 사람에 의해 독립적으로 구현된다.
• 부흥기 – 대규모 개발 집단에 의해 장기간에 걸쳐 만들어진다. 급변하는 시장 상황에 따라 요구사항과 설계가 자주 변경되며, 유지보수 기간에는 말할 것도 없고, 첫 제품이 완료되기 이전 이미 수차례에 걸쳐 담당 개발자가 바뀐다. 개발자 집단에서 개인간의 능력 편차가 심하다. 내부 구현 레벨에서 잦은 소통이 발생한다.

태동기 프로젝트에서는 개발자간 아무런 소통도 필요가 없었다. 점차 소프트웨어 규모가 커지면서 성숙기로 넘어가고, 이 단계에서는 모듈간 명확한 인터페이스 정의의 중요성이 부각된다. 하지만 내부 구현은 여전히 각 개발자 개인에 맡겨진다. 마지막 부흥기 과제에서는 구현 소스 레벨에서 소통이 가장 중요하다. 소스는 처음 작성자가 기초를 잡은 시점부터 제품의 수명이 다하기 까지 열 명 이상의 손이 거쳐 가는 것은 이제 그리 특이한 경우도 아니다. 각 파일 위에 기록된 저자(author) 정보는 아무런 의미가 없는 경우가 허다하다. 이제 추상화된 설계 다이어그램이 아니라, 프로그램 소스 그 자체가 소통의 매개체가 된 것이다.

대부분의 소프트웨어 개발이 이미 부흥기적 성격을 띄게된 현 시점에서, 프로그래밍에 대한 우리의 인식도 다시 한 번 고찰해보아야 한다. ‘동작하는 코드’는 더 이상 미덕이 아니다. 프로그래밍은 코딩(coding)이 아닌 작문(writing)으로써 인식되고 그에 걸맞게 취급되고 교육되어야 한다.

좋은 글은 타인이 쉽게 읽고 이해할 수 있어야 한다. 구조가 잘 잡혀 있어서 필요한 부분을 발췌해 쓰거나 다른 목적으로 재구성하기도 용이해야 한다. 반면 잘못 인용되는 사례가 없도록 오해의 소지는 최소화 되어야 한다.

그렇다면 좋은 글은 어떻게 작성할 수 있을까? 다른 사람이 작성한 좋은 글들을 많이 읽고, 좋은 부분을 모방해보고 때론 변화를 주어 그 차이를 느껴본다. 서로 쓴 것은 공유하고 많은 논의, 때로는 논쟁을 거치면서 조금씩 조금씩 논리력을 키우고 효과적인  표현 방식을 습득해간다. 내가 작문 교육에 남다른 지식이 있는 것은 아니지만 이상의 과정은 필수가 아닐까 한다.

프로그램 작성도 마찬가지이다. 틈나는대로 좋은 소스를 많이 보고, 서로 작성한 소스를 비교해가면서 더 나은 소스를 만들기 위해 열띤 토론을 벌여봐야 한다. 우리는 이미 그 방법을 알고 있다. 바로 코드 리뷰와 리펙토링이다. 컨벤션을 맞추는 단순한 리뷰나 리펙토링이 아닌 명료한 문장, 효율적 로직까지 토론이 이루어져야 한다. 이들의 의의를 살펴보자.

• 명료한 문장
  • 결함 발생 확률이 적다.
  • 유지보수 시 side effect 을 최소화한다.
  • 논리력을 향상시킨다. (정신없는 소스는 대부분은 논리력 부족의 산물이다. 논리력은 훈련을 통해 향상될 수 있다.)
  • 독해력을 증진시켜 리뷰의 효율성을 극대화시킨다.
• 효율적인 로직
  • 개발자들에게 배움의 즐거움을 선사하여, 자칫 재미없게 흘러갈 수 있는 리뷰에 개발자들이 적극 참여하게 만든다. (리뷰가 진행될 수록 개발자들이 상향 평준화 되어, 코드 리뷰는 점차 효율적 로직에 촛점이 맞춰질 것이다.)
  • 제품의 효율성 향상은 고객 만족도 향상으로 이어진다.

그러면 서로간의 이해력 증진이라는 이점이 따라온다. 소스의 형식적인 측면뿐 아니라 그 개념과 로직 등도 자연스럽게 섭렵하게 되므로, 개발자가 부재중이거나 담당 모듈이 바뀌어도 큰 장애 없이 소스를 개선할 수 있다.

상대방의 취향이나 자존심 존중 같은 구시대적 사고는 과감히 버려야 할 때다. 이왕이면 남들 모두가 인정하는 떳떳한 자존심을 권해보자. 남을 배려한 소스 작성의 중요성을 교육시키고, 그런 사람을 우대하는 정책을 펴자. 심도 있는 코드 리뷰와 리펙토링을 권장하는 문화(부작용이 없는 수준에서 프로세스 적으로 강제해도 좋음)를 만들고, 그 과정에서 훌륭한 리뷰어를 찾고 모든 개발자들의 소스 작성 능력을 상향 평준화 시키자. 가장 뛰어난 개발팀은 가장 못하는 개발팀보다 10배 이상의 생산성을 보여준다. 당장 눈앞의 목표만 쫓다보면, 평생 서로 말 안통하는 개발자 집단을 이끌고 (혹은 그 속에서) 과제를 진행하고 있는 자신을 발견할 수 있을 것이다.

개발자로써의 실력을 평할 때도 반드시 한 번 쯤은 그 사람이 작성한 소스를 참조할 필요가 있다. 남이 쉽게 알아볼 수 있게 작성되어 있는지 살펴보고, 그렇지 않다면 코딩 스타일에 대한 철학을 은근슬쩍 떠보는 것도 좋다. 아무런 정보 없이, 혹은 독불장군형 개발자에게 중요 모듈을 맡기는 것은 오늘날과 같은 규모의 소프트웨어 프로젝트에서는 모 아니면 도 식의 큰 도박이다. 그 개발자가 팀을 이탈했거나 다른 일로 시간을 낼 수 없는 상황에서 중요한 기능 수정 요청이 들어왔다고 가정해보자. 아예 동작하지 않으면 차라리 맘 편히 재작성이라도 할텐데, 잘 동작하는데 도데체가 그 원리를 이해할 수 없게 되어 있다면 어떻게 하겠는가? 불행히도 지금 가정한 상황은 거의 모든 프로젝트에서 크고 작은 형태로 아주 빈번하게 발생하는게 오늘날의 현실이다.

이쯤에서 글을 정리해보자.

• 오늘날의 소프트웨어 개발에서는 프로그램 소스 자체가 팀 내 개발자간 소통의 가장 비중있는 매개체이다.
• 개발자가 소통이 원활한 프로그램을 작성하기까지는 인식 변화와 교육, 훈련이 필요하다.
• 가장 효율적인 교육, 훈련법은 잦은 코드 리뷰와 리펙토링이다.
• 코드 리뷰와 리펙토링은 명료한 문장과 로직 효율성까지 커버해야 한다.
• 이러한 과정은 모든 개발자의 능력을 상향 평준화 시킨다.

나는 이러한 사실을 프로그래밍을 가리키는 모든 학교/학원과 입문서에서 반드시 가리켜야 한다고 생각한다. 적어도 이 글을 읽는 모든 개발자분들은 coding 이 아닌 writing 의 세계로 여행을 떠나길 바라며.. 이만.

주의: 코드 리뷰나 리펙토링도 아무런 사전 지식과 노하우 없이 섵불리 수행하면 시간 낭비나 역효과가 날 수도 있다. 기회가 되면 효율적인 코드 리뷰와 성공적인 리펙토링을 위한 지침에 대해서도 다뤄보도록 하겠다. 자료는 많으니 관심있는 사람은 인터넷과 관련 서적을 살펴보면 좋을 것이다.

나는 대기업에서도 상당히 큰 규모의 과제에 몸담고 있다. 연관된 내/외부 팀원만 하더라도 족히 5백은 넘을 듯 하고, 그 중 직간접적으로 내 영향력이 미치는 범위는 백여명 정도 될 듯 싶다. 이런 규모의 과제를 진행하다보니 프로젝트 투명성의 중요성이 더욱 크게 느껴진다.

여기서의 프로젝트 투명성이란 프로젝트 계획, 세부 태스크, 진척도, 히스토리,  위험 요소, 가용 자원 현황 등 프로젝트 진행과 관련된 중요 정보들에 관련자들이 실시간으로 얼마나 쉽고 정확하게 접근할 수 있는가를 말한다.

우리팀의 수직적 계층을 대략적으로 구분해보면 ‘개발자, 중간 관리자, 상위 관리자, 경영진’ 정도로 나뉘는 듯 하다. 수평적으로는 협력 팀과 경쟁 팀이 있고, 경쟁 팀들의 수직적 구조는 우리 팀과 대동소이하다. 이러한 거대 조직에서 프로젝트 투명성을 제대로 지원해주는 어떠한 인프라도 갖춰져 있지 않다면 어떤 현상이 벌어질까? 우리의 예를 일반화시켜 적어보겠다.

실시간 정보 공유가 어려우므로, 개발자는 중간 관리자에게 한 주 정도 간격으로 진행 상황을 보고한다. 하지만 이 때 기입되는 태스크들의 의미를 전체 프로젝트의 관점과 연관시켜주는 인프라가 없다. 무언가 많은 일들이 진행되고 있는 것은 같으나 그것의 의미는 잡아내기 쉽지 않다. 중요하지 않거나 계획에도 없던 일에 과도한 시간을 투자하거나, 반대로 아주 시급한 일과 직결된 이슈 사항이 주목 받지 못하고 묻혀버리는 일이 허다하다. 진도가 계획 대비 얼마나 충실히 나아가고 있는지, 그래서 예정된 마일스톤에 납기가 가능할 지와 같은 정작 중요한 정보는 거의 포함되지 못한다.

중간 관리자와 상위 관리자도 보통 주 단위의 미팅을 갖는다. 개발자들로부터 받은 보고를 정리해서 공유하고 전체 일정 대비 점검하거나 큰 이슈들에 대한 논의가 주로 이루어진다. 개발자의 보고 내용이 필터링 되는 것은 오히려 작은 문제이고.. 더 큰 우려 사항은 앞서 이야기한 ‘중요한 정보를 얼마나 잘 캐취해 냈는가’이다. 중간 관리자가 이 일을 제대로 처리하지 못한다면, 중요치 않은 일이 부각되고 그 후속 조치로써 더 중요한 일에 투입할 시간마져 갉아먹게 된다.

이 단계에서의 또 하나의 심각한 문제는, 가용 리소스와 각 태스크별 요구되는 리소스량에 대한 신뢰할 만한 데이터 없이 매니저들의 감과 욕심(혹은 바람)에 의존해 일이 계획된다는 점이다. 실무자가 보기엔 현재 할당된 일만으로도 일정 지연이 뻔한 상황에서도 새로운 태스크들이 추가된다. 요구 일정에 맞추려면 실무자는 결국 대충 진행할 수 밖에 없다. 그 때 그 때 지뢰를 하나씩 매설해놓고, 제품은 점차 건드리기조처 겁이 나는 지뢰밭이 되어 간다. 심지어 기존 기능을 변경할 시에도 감히 현 코드를 수정하지 못하고 편접적인 방법으로 살짝 덧씌운다.

상위 관리자는 협력 팀이나 경영진들과 미팅을 갖고, 그 주기나 형태는 어떤 주제로 누구와 맞나느냐에 따라 달라진다. 이전까지의 논의가 주로 기술과 일정에 대한 것이었다면, 이제부터는 기술은 쏙 빠지고 비즈니스 임팩트와 내/외부 경쟁에 대한 것들에 초점이 맞춰진다. 빠르게 변하는 시장 상황에 따라 과제 방향이 확 틀어질 수도 있고, 경쟁에서 너무 밀릴 것 같으면 생존 자체가 위협을 받는다. 이런 상황이 상급 관리자들을 방어적으로 만든다. 거짓말이 되지 않도록 신경쓰면서 문제를 최대한 숨기고, 작은 장점을 크게 부풀리고, 묘한 가정을 설정하거나 자신들에게 유리한 데이터를 추려 인용한다. 예를 들면, 여러가지 임시 방편과 제한된 시나리오로 간신히 데모 정도 돌리는 수준에서 마치 다 마무리 되어가는 듯 보고가 되고, 그 결과 추가적인 일거리가 생기고 과제 규모도 커져버리는 식이다. 추가된 업무에 허락된 리소스는 당연히 지금까지 잘 된(것처럼 보고된) 생산성에 맞춰져 있다. 일을 받는 입장에서 현실적인 리소스를 요구할 수 없는 것이, 앞으로는 자신의 팀원들의 생산성이 훨씬 떨어질 것이라는 납득하기 어려운 주장을 펴거나 현재의 상황을 인실직고해야하기 때문이다. 더욱이 현 문제에 대해 상급 관리자가 파악하고 있는 수준 역시 현실과는 꾀 거리가 있게 마련이다.

결과적으로 부정확한 데이터에 기반해 엄청난 예산을 낭비하고 기회를 놓치게 된다. 그리고 이런 체제에서는 개발자들의 실력도 늘지 않아 경쟁에서 점차 뒤쳐질 수 밖에 없다. 좋은 개발자들은 기회가 되면 조직에서 벗어나려 할 것이다. 그 외의 악순환 얘기까지는 굳이 꺼내지 않아도 될 것 같다.

투명한 프로젝트의 장점 중 가장 중요한 것은 다음 두 가지라고 생각된다.

첫 째, 여러 단계에 걸친 보고 과정에서 낭비되는 고급 인력의 시간을 실무적인 문제 해결로 돌릴 수 있다. 어떤 정보를 공개할 지, 어느 정도로 포장을 해야할 지, 유리한 데이터는 무엇이 있을 지, 경쟁자보다 우월해 보이려면 다소 무리해서라도 어떤 기능을 더 넣어야 할 지 등을 찾고 고심하는대는 생각보다 많은 시간과 노력이 필요하다. 한 구글 직원의 블로그에서는 자신들의 리더는 약 20% 의 리소스만을 관리에 쓰고 나머지는 같이 개발을 한다고 하였다. 반면 비효율적인 기업은 상위 20%의 인력은 관리만 하고 있는 것이 아닌가 싶을 정도이다. 고급 인력 한  사람의 적극적인 참여는 저급 인력 몇 명을 투입하는 것보다 훨씬 나은 효과를 낳는 경우가 많다. 이런 효과는 팀 규모가 커지고 과제가 장기화될 수록 더욱 뚜렷해진다. 과제가 진행되면서 노하우가 전파되고 개발인력들의 역량이 향상된다. 이 문제는 굉장히 심각한 것이.. 실무에서 몇 년을 일한 프로 개발자들 중 아직껏 대학생 수준의 코드를 작성하고 있는 경우가 너무 많이 목격되기 때문이다. 투명성 부여 하나만으로 해결될 일은 아니지만 문제를 부각시키는데 분명 큰 효과를 발휘한다.

둘 째, 조직이 스스로의 역량을 정확히 파악함으로써, 현실성 있는 비전과 전략을 수립하여 그에 집중할 수 있게 해준다. 어느 시점에 어떤 역량을 더 키워야 하는지도 판단할 수 있고, 이는 조직이 경쟁에서 살아남기 위해 꼭 필요한 정보 중 하나이다.

하지만 위와 같은 경직된 조직에서 과제에 투명성을 부여하기란 결코 쉽지 않다. 깨어 있는 사람에 의해 위에서부터 도입되는 시나리오가 가장 현실적이나, 정보가 차단된 문화에서 그럴 필요성을 느낄 수나 있는가가 첫 난관이다. 반대로 아래로부터의 개선은 변화를 시도하는 팀에게 상당한 모험이 될 것이다. 모든 정보를 투명하게 공개한 과제는 여러 겹 포장된 과제에 비해 생산성이 떨어지고 각종 문제들로 정신이 없는 것처럼 비춰지기 쉽다. 이런 현상의 진실을 경영진들에게 잘 납득시켜 결과가 나올 때까지 과제를 유지해 나가는 것이 가장 큰 난관이 될 것이다.

개발자들에게 오픈 마인드를 심어주는 것 역시 큰 장애가 될 수 있다. 자신들이 하는 일이 실시간으로 공개가 된다는 것은 자칫 일거수 일투족이 감시받는다는 오해를 불러 일으키기 쉽다. 실제 비공식적으로 도입해본 결과도 아랫사람들이 훨씬 적극적이며, 주로 위로부터의 말도 안되는 압박에 대한 방어효과 때문으로 보인다. 그리고 윗사람들이 하는 일도 다 같이 공개된다는 점을 잊지 말자.

마지막으로 그리고 절대 간과해서는 안되는 것이 있다. 정보 공개를 위해 귀찮은 추가 작업을 수행해야 한다면 업무 집중도가 떨어지고 정보 누락이 발생한다. 부정확한 정보를 얻기 위해 생상성을 떨어뜨리는 것은 바보짓이다. 따라서 충분한 논의와 교육으로 가능한 많은 이들과 공감대를 형성하고, 좋은 자동화 인프라를 갖춘 후에 시행에 옮겨야 한다. 의욕만 앞서 무리하게 추진하면 부정적 인식만 남겨 도입 시기를 더 늦춰버리는 역효과가 나기 쉽다. 지금까지 자칭 SE 라는 조직에서 수없이 반복해온 실수들이 아닌가!

하루라도 빨리 제대로된 개발을 해볼 수 있는 날이 오기를 바라며, 답답한 마음에 두서 없이 적어본 프로젝트 투명성에 대한 이야기를 마친다.

참고로, 인프라 관점에서는 본격적으로 제품이 나오기 시작한지는 아직 몇 년 되지 않아 제대로된 솔루션 중에는 선택의 폭이 넓지 않다. 현 시점에서는 IBM Rational 의 Jazz/RTC 와 MS 의 Visual Studio Team System 2010 정도가 눈에 들어온다. 통합 환경에 비해 사용법을 익히고 관리하는데 더욱 많은 노력이 드는 것은 어쩔 수 없지만, 별개의 여러 툴들을 조합해 사용할 수도 있다. 조직의 규모가 커질수록 투자할 만한 가치가 있을 것이다. 나라면 개발 인력 5명에 3개월 과제만 되어도 이런 류의 인프라를 도입할 것이다.