디버깅을 잘 한다.
나는 과거 종종 그런 얘기를 들은 적도 있고, 또 스스로도 제법 잘 한다고 생각한다. (최근 몇 년간은 직접적인 개발과는 거리가 좀 있는 업무들을 주로 수행해 왔다.)
그런데 ‘디버깅을 잘한다’는 말에는 어떤 의미가 포함되어 있을까.
아무 개념 없이 엉터리로 짠 남의 코드에서 산발적으로 발생하는 미지의 문제를 소스 코드만 추적해서 잘아낼 수 있으면 디버깅을 잘 하는 것일까? 분명 이런 능력은 대단한 것겠지만.. 현실적으로는 ‘운이 좋았다’ 이상을 기대하긴 어렵다. 주변에서도 능력 있는 개발자가 다른 프로젝트 합류 후 ‘내가 할 수 있는 일이 없다’고 푸념하고 경우를 몇 번 보았다. 이유는 몇 년 동안 들여다보던 사람이 아니면 도저히 손 댈 엄두가 안나는 코드를 사용하고 있기 때문이었다. 종속된 모듈과 프로젝트가 많고 덩치도 만만치 않아 새로 깔끔히 만들 수도 없다는 것이다. 동작하는 코드를 새로 만들 시간을 달라는 요청은 관리자들에게 쉽게 묵살당한다.
결국 아무리 능력 좋은 개발자도 대상 소프트웨어의 상태/환경에 따라 발휘되는 능력은 극심한 편차를 보이기 마련이다. 좀 더 정리하여 이야기하면, 커버할 수 있는 임계점 이하까지는 쉽게쉽게 문제를 찾아내지만, 그 한계를 넘어서면 거의 컨트롤이 불가하여 평범한 개발자와 별 차이를 보이지 못하게 된다. 이는 인간이 머릿속에 한 번에 담고 분석/추적할 수 있는 정보량이 그리 많지 않기 때문이다.
중요한 것은 디버깅 대상을 단순 명료하게 유지하는 능력이다. 또는 복잡한 대상을 단순하게 변형하는 능력이다. 구체적인 방법들을 떠올려보자.
이상은 순수한 소스 코드 & 설계의 관점에서의 디버깅 능력 향상 방법들이었다. 유지보수를 위한 지침과 동일하다고 볼 수 있다. 그럼 다른 관점에서는 또 어떤 방법들이 있을까?
이상은 소스 코드 외적인 방법이었지만, 개인이 충분히 할 수 있는 것들이다. 그럼 마지막으로 소셜 개발자라면 또 어떠한 방법들을 생각해볼 수 있을지 나열해보겠다.
디버깅 하나 얘기하면서 참 많은 것을 훑었다. 오버라고 생각할 수도 있겠지만, 개발이라는 것이 그리 딱딱 떨어지는 것이 아니고.. 이것이 현실이다. 오히려 위에 나열할 것 외에도 수많은 요소들이 훌륭한 디버거를 만드는 관여될 것이 분명하다.
자!! 그럼 지금까지 나온 좋은 디버거로서의 자질은 정리해보자.
내가 지금까지 접해본 여러 이론/실천법 들을 통틀어 가장 맘에 드는 것들을 세 가지 고르라면 TDD, Refactoring, Scrum, 이렇게 세 가지를 뽑겠다. (우리 조직에선 이 중 단 하나도 하지 않고 있어서 참으로 답답하고 안타깝다.) 다른 사람들과는 좀 다른 관점일 수 있겠는데, 이들에 애착이 생기는 내 나름의 이유는 간략히 정리해본다.
Refactoring – Refactoring은 현재의 잘못된 점이나 부족한 부분을 식별하여 더 나은 형태로 개선하는 작업이다. 따라서 Refactoring 은 일종의 회고이며, 그 주된 관점은 설계/코드의 효율성, 가독성, 명확성 등이다. 사람이나 조직이 회고를 통해 교훈을 얻고 성장하듯, 개발자도 Refactoring 을 통해 역량을 키워나간다. 여건이 되지 않으면 혼자서라도 틈틈히 수행해야 하며, 다행히 지도해줄 경험 많은 동료가 함께한다면 그 효과는 배가된다. 팀의 리더라면 팀원간의 이런 교류가 자연스레 일어날 수 있도록 이끌어 주어야 한다.
Refactoring은 개발 기간 내내 리듬을 가지고 정기적으로 수행되어야 한다. 리펙토링 문화가 충분히 자리잡지 못했다면 프로세스에 명시해두는 것이 좋다. 시점은 매 반복 주기(iteration/milestone)가 끝나고 다음 주기가 시작되는 시점이다. 새로운 기능을 넣기 전에 기반을 단단히 다진다거나, 구조적 문제를 조기에 다잡아 추후 대규모 수정을 예방한다는 점도 물론 중요하지만, 사람(개발자)의 역량 성장 측면에서도 반드시 요구되는 프로세스이다.
배우고 경험하고 배우고 경험하고.. 두 과정이 주기적으로 반복되어야 머리로 익힌 것이 체화되고, 그것이 실생활에서 어떤 가치가 있는지 진정한 의미를 깨닫게 된다. 처음에 좋아보였던 것도 생각지 못했던 숨은 이슈나 과소 평가했던 측면 때문에 실제로는 역효과가 더 큰 경우도 많다. 또한 체험 없이 계속해서 머리로만 익히다 보면 모든 것이 쉽고 단순해 보이는 경향이 있다. 이렇게 해서 다음 리펙토링을 수행할 때에는 이전 수행 시보다 향상된 시각으로 구조를 바라볼 수 있게 된다. 설계와 코드를 보는 눈이 향상되고, 시행착오가 줄어들고, 다양한 경험을 통해 확신을 가질 수 있다. 주기적인 Refactoring은 프로젝트가 진행될 수록 Refactoring의 품질과 그것을 수행하는 개발자 역량을 함께 성장시킬 수 있는 멋진 제도적 장치가 될 것이다.
Refactoring 시 주의점
리펙토링 시 가장 신경써야할 부분은 역시 side effect 다. 때문에 전문 툴 활용과 풍부한 테스트 케이스가 준비가 큰 도움을 준다. 툴의 Refactoring 지원 정도는 언어별로 편차가 심하다. Small Talk, Java 언어는 Refactoring 이 지원되지 않는 툴은 오래전에 자취를 감췄을 정도로 대중화되어 있고, C#, Visual Basic 등은 중간 정도.. C/C++ 계열은 아직 많이 부족하며 발전 속도도 더디다.
툴이 해주는 일은 다양한 리펙토링 기법들을 마우스 클릭 몇 번으로 관련된 모든 코드를 자동 변경해주는 편리함과, 이 때 발생할 수 있는 구조적 충돌을 사전 검증하여 side effect 을 최소화시켜주는 효과가 있다. 소프트웨어 규모가 커지면 수십명이 일주일 동안 해야할 변경량을 한 사람이 반나절 만에 처리할 정도로 극적인 효과를 볼 수도 있다.
툴이 구조적인 side effect를 예방해준다면, 테스트 케이스는 기능적인 side effect 를 예방해준다. 테스트 케이스가 충분치 않다면 변경의 잘못된 영향을 먼 훗날에야 발견하게 되고, 무엇이 그 원인이었는지 파악하기 어렵게 된다.
Refactoring 과 TDD 테스트의 대표 주자는 역시 TDD 이다. 현실적으로 거의 불가능하지만, TDD 를 100% 잘 따랐다면 작성된 코드 중 테스트 케이스가 커버하지 못하는 영역은 존재하지 않는다. 따라서 Refactoring 을 가장 안전하게 하기 위한 좋은 지침은 TDD 를 잘 따르는 것이다. 역으로 TDD 의 과정에서 새로운 테스트 케이스(요구사항)가 추가되면, 그 케이스를 만족시키기 위해 기존 코드를 Refactoring 해야한다. 이렇든 이 둘은 거의 바늘과 실 관계이다. 다만 Refactoring 없는 TDD 는 그 효과가 급감하지만, TDD 없이도 테스트 케이스는 작성할 수 있으므로 Refactoring 은 독자적으로도 충분한 가치가 있다.
평소 기술 동향에 관심이 많아 Parallel Programming 을 빨리 익혀둬야겠다 생각한 지는 벌써 1년도 훨씬 지난 것 같은데, 마땅한 기회를 잡지 못해서 자료만 모으고 있었다. 그러다 마침 Snow Leopard 에서 Grand Central Dispatch (이하 GCD)라는 멋진 기술을 제공한 것을 계기로 몇 일 동안 이러저런 자료들을 살펴보았다. 처음엔 기본적인 개념 정리까지 해볼까 하였으나, 현재로썬 단순 번역 정도에서 그칠 듯 싶어 마음을 바꿔먹었다. 오늘은 운을 띄우는 정도에서 몇 자 적어보고.. 더 깊이 있는 지식과 경험을 쌓으면 보다 전문적인 글을 적어보겠다.
CPU 가 클럭 경쟁에서 멀티코어 형태로 그 진화 방향이 변화하였고, GPU 의 성능이 CPU 를 능가하기 시작하면서, 그 막강한 프로세싱 파워를 그래픽 외적인 목적으로도 활용코자 하는 노력도 몇 년 전부터 꾸준히 진행되어 왔다. 멀티 코어 CPU 와 GPU 의 공통적인 특징은 바로 복수의 프로세싱 엔진(코어)를 갖음으로써 여러 개의 서로 다른 연산을 병렬로 처리할 수 있다는 점이다. Parallel Programming 은 이런 다중 코어 환경에서 코어들을 최대한으로 활용하여 프로그램의 성능을 향상시키고자 하는 프로그래밍 기법을 일컷는다.
서버 분야에서는 멀티 코어 이전부터 멀티 프로세서 환경이 일반화 되어 있기 때문에 Parallel Programming 의 역사는 상당히 깊다. 자연히 GCD 는 갑자기 혜성처럼 나타난 별천지 기술은 아니다. 그리고 기존 상식을 뛰어넘는 혁신적인 아이디어도 보이진 않는다. 다만 서버 분야에서부터 적어도 십수년간 쌓아온 노하우를 애플 식으로 OS X 플랫폼에 멋지게 녹여낸 것이다. 그럼 애플 외의 다른 경쟁 데스크탑 플랫폼에서의 상황은 어떠할까?
.NET 은 곧 등장할 Windows 7 부터 4.0 으로 버전업되며, .NET 4.0 의 큰 특징 중 하나로 Task Parallel Library (TPL) 탑재가 있다. MS 도 바보가 아닌 이상 병렬화라는 시대 흐름을 놓칠 리 없고, 애플과 비슷한 시기에 비슷한 문제를 해결하려는 나름의 솔루션을 내놓는 것이다. Java 역시 곧 등장할 JDK 7 에 Fork/Join Framework 을 포함한 JSR166y 를 추가하여 병렬 환경 지원을 강화하고 있다.
이렇듯 Parallel Programming은 이제 거스를 수 없는 시대의 흐름이고, 어플리케이션이 이를 얼마나 잘 활용하느냐에 따라 수십배의 성능 차이를 보이는 날이 곧 도래할 것이다.
다시 애플의 GCD 로 돌아가보자. 내가 아직 전문 지식이 부족한 관계로 정확한 평가는 불가능하지만, 현재의 얕은 지식만을 바탕으로 봤을 때 GCD 의 큰 장점은 아래 정도이다.
이 글은 관련 자료 중 쓸만한 링크들을 남겨놓는 것으로 마무리 하겠다. 나중에 직접 작성해볼 기회가 생기면 코드 수준에서의 간단한 설명과 성능 테스트 결과 정도를 포스팅할 생각이다.
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.
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)으로써 인식되고 그에 걸맞게 취급되고 교육되어야 한다.
좋은 글은 타인이 쉽게 읽고 이해할 수 있어야 한다. 구조가 잘 잡혀 있어서 필요한 부분을 발췌해 쓰거나 다른 목적으로 재구성하기도 용이해야 한다. 반면 잘못 인용되는 사례가 없도록 오해의 소지는 최소화 되어야 한다.
그렇다면 좋은 글은 어떻게 작성할 수 있을까? 다른 사람이 작성한 좋은 글들을 많이 읽고, 좋은 부분을 모방해보고 때론 변화를 주어 그 차이를 느껴본다. 서로 쓴 것은 공유하고 많은 논의, 때로는 논쟁을 거치면서 조금씩 조금씩 논리력을 키우고 효과적인 표현 방식을 습득해간다. 내가 작문 교육에 남다른 지식이 있는 것은 아니지만 이상의 과정은 필수가 아닐까 한다.
프로그램 작성도 마찬가지이다. 틈나는대로 좋은 소스를 많이 보고, 서로 작성한 소스를 비교해가면서 더 나은 소스를 만들기 위해 열띤 토론을 벌여봐야 한다. 우리는 이미 그 방법을 알고 있다. 바로 코드 리뷰와 리펙토링이다. 컨벤션을 맞추는 단순한 리뷰나 리펙토링이 아닌 명료한 문장, 효율적 로직까지 토론이 이루어져야 한다. 이들의 의의를 살펴보자.
그러면 서로간의 이해력 증진이라는 이점이 따라온다. 소스의 형식적인 측면뿐 아니라 그 개념과 로직 등도 자연스럽게 섭렵하게 되므로, 개발자가 부재중이거나 담당 모듈이 바뀌어도 큰 장애 없이 소스를 개선할 수 있다.
상대방의 취향이나 자존심 존중 같은 구시대적 사고는 과감히 버려야 할 때다. 이왕이면 남들 모두가 인정하는 떳떳한 자존심을 권해보자. 남을 배려한 소스 작성의 중요성을 교육시키고, 그런 사람을 우대하는 정책을 펴자. 심도 있는 코드 리뷰와 리펙토링을 권장하는 문화(부작용이 없는 수준에서 프로세스 적으로 강제해도 좋음)를 만들고, 그 과정에서 훌륭한 리뷰어를 찾고 모든 개발자들의 소스 작성 능력을 상향 평준화 시키자. 가장 뛰어난 개발팀은 가장 못하는 개발팀보다 10배 이상의 생산성을 보여준다. 당장 눈앞의 목표만 쫓다보면, 평생 서로 말 안통하는 개발자 집단을 이끌고 (혹은 그 속에서) 과제를 진행하고 있는 자신을 발견할 수 있을 것이다.
개발자로써의 실력을 평할 때도 반드시 한 번 쯤은 그 사람이 작성한 소스를 참조할 필요가 있다. 남이 쉽게 알아볼 수 있게 작성되어 있는지 살펴보고, 그렇지 않다면 코딩 스타일에 대한 철학을 은근슬쩍 떠보는 것도 좋다. 아무런 정보 없이, 혹은 독불장군형 개발자에게 중요 모듈을 맡기는 것은 오늘날과 같은 규모의 소프트웨어 프로젝트에서는 모 아니면 도 식의 큰 도박이다. 그 개발자가 팀을 이탈했거나 다른 일로 시간을 낼 수 없는 상황에서 중요한 기능 수정 요청이 들어왔다고 가정해보자. 아예 동작하지 않으면 차라리 맘 편히 재작성이라도 할텐데, 잘 동작하는데 도데체가 그 원리를 이해할 수 없게 되어 있다면 어떻게 하겠는가? 불행히도 지금 가정한 상황은 거의 모든 프로젝트에서 크고 작은 형태로 아주 빈번하게 발생하는게 오늘날의 현실이다.
이쯤에서 글을 정리해보자.
나는 이러한 사실을 프로그래밍을 가리키는 모든 학교/학원과 입문서에서 반드시 가리켜야 한다고 생각한다. 적어도 이 글을 읽는 모든 개발자분들은 coding 이 아닌 writing 의 세계로 여행을 떠나길 바라며.. 이만.
주의: 코드 리뷰나 리펙토링도 아무런 사전 지식과 노하우 없이 섵불리 수행하면 시간 낭비나 역효과가 날 수도 있다. 기회가 되면 효율적인 코드 리뷰와 성공적인 리펙토링을 위한 지침에 대해서도 다뤄보도록 하겠다. 자료는 많으니 관심있는 사람은 인터넷과 관련 서적을 살펴보면 좋을 것이다.
나는 대기업에서도 상당히 큰 규모의 과제에 몸담고 있다. 연관된 내/외부 팀원만 하더라도 족히 5백은 넘을 듯 하고, 그 중 직간접적으로 내 영향력이 미치는 범위는 백여명 정도 될 듯 싶다. 이런 규모의 과제를 진행하다보니 프로젝트 투명성의 중요성이 더욱 크게 느껴진다.
여기서의 프로젝트 투명성이란 프로젝트 계획, 세부 태스크, 진척도, 히스토리, 위험 요소, 가용 자원 현황 등 프로젝트 진행과 관련된 중요 정보들에 관련자들이 실시간으로 얼마나 쉽고 정확하게 접근할 수 있는가를 말한다.
우리팀의 수직적 계층을 대략적으로 구분해보면 ‘개발자, 중간 관리자, 상위 관리자, 경영진’ 정도로 나뉘는 듯 하다. 수평적으로는 협력 팀과 경쟁 팀이 있고, 경쟁 팀들의 수직적 구조는 우리 팀과 대동소이하다. 이러한 거대 조직에서 프로젝트 투명성을 제대로 지원해주는 어떠한 인프라도 갖춰져 있지 않다면 어떤 현상이 벌어질까? 우리의 예를 일반화시켜 적어보겠다.
실시간 정보 공유가 어려우므로, 개발자는 중간 관리자에게 한 주 정도 간격으로 진행 상황을 보고한다. 하지만 이 때 기입되는 태스크들의 의미를 전체 프로젝트의 관점과 연관시켜주는 인프라가 없다. 무언가 많은 일들이 진행되고 있는 것은 같으나 그것의 의미는 잡아내기 쉽지 않다. 중요하지 않거나 계획에도 없던 일에 과도한 시간을 투자하거나, 반대로 아주 시급한 일과 직결된 이슈 사항이 주목 받지 못하고 묻혀버리는 일이 허다하다. 진도가 계획 대비 얼마나 충실히 나아가고 있는지, 그래서 예정된 마일스톤에 납기가 가능할 지와 같은 정작 중요한 정보는 거의 포함되지 못한다.
중간 관리자와 상위 관리자도 보통 주 단위의 미팅을 갖는다. 개발자들로부터 받은 보고를 정리해서 공유하고 전체 일정 대비 점검하거나 큰 이슈들에 대한 논의가 주로 이루어진다. 개발자의 보고 내용이 필터링 되는 것은 오히려 작은 문제이고.. 더 큰 우려 사항은 앞서 이야기한 ‘중요한 정보를 얼마나 잘 캐취해 냈는가’이다. 중간 관리자가 이 일을 제대로 처리하지 못한다면, 중요치 않은 일이 부각되고 그 후속 조치로써 더 중요한 일에 투입할 시간마져 갉아먹게 된다.
이 단계에서의 또 하나의 심각한 문제는, 가용 리소스와 각 태스크별 요구되는 리소스량에 대한 신뢰할 만한 데이터 없이 매니저들의 감과 욕심(혹은 바람)에 의존해 일이 계획된다는 점이다. 실무자가 보기엔 현재 할당된 일만으로도 일정 지연이 뻔한 상황에서도 새로운 태스크들이 추가된다. 요구 일정에 맞추려면 실무자는 결국 대충 진행할 수 밖에 없다. 그 때 그 때 지뢰를 하나씩 매설해놓고, 제품은 점차 건드리기조처 겁이 나는 지뢰밭이 되어 간다. 심지어 기존 기능을 변경할 시에도 감히 현 코드를 수정하지 못하고 편접적인 방법으로 살짝 덧씌운다.
상위 관리자는 협력 팀이나 경영진들과 미팅을 갖고, 그 주기나 형태는 어떤 주제로 누구와 맞나느냐에 따라 달라진다. 이전까지의 논의가 주로 기술과 일정에 대한 것이었다면, 이제부터는 기술은 쏙 빠지고 비즈니스 임팩트와 내/외부 경쟁에 대한 것들에 초점이 맞춰진다. 빠르게 변하는 시장 상황에 따라 과제 방향이 확 틀어질 수도 있고, 경쟁에서 너무 밀릴 것 같으면 생존 자체가 위협을 받는다. 이런 상황이 상급 관리자들을 방어적으로 만든다. 거짓말이 되지 않도록 신경쓰면서 문제를 최대한 숨기고, 작은 장점을 크게 부풀리고, 묘한 가정을 설정하거나 자신들에게 유리한 데이터를 추려 인용한다. 예를 들면, 여러가지 임시 방편과 제한된 시나리오로 간신히 데모 정도 돌리는 수준에서 마치 다 마무리 되어가는 듯 보고가 되고, 그 결과 추가적인 일거리가 생기고 과제 규모도 커져버리는 식이다. 추가된 업무에 허락된 리소스는 당연히 지금까지 잘 된(것처럼 보고된) 생산성에 맞춰져 있다. 일을 받는 입장에서 현실적인 리소스를 요구할 수 없는 것이, 앞으로는 자신의 팀원들의 생산성이 훨씬 떨어질 것이라는 납득하기 어려운 주장을 펴거나 현재의 상황을 인실직고해야하기 때문이다. 더욱이 현 문제에 대해 상급 관리자가 파악하고 있는 수준 역시 현실과는 꾀 거리가 있게 마련이다.
결과적으로 부정확한 데이터에 기반해 엄청난 예산을 낭비하고 기회를 놓치게 된다. 그리고 이런 체제에서는 개발자들의 실력도 늘지 않아 경쟁에서 점차 뒤쳐질 수 밖에 없다. 좋은 개발자들은 기회가 되면 조직에서 벗어나려 할 것이다. 그 외의 악순환 얘기까지는 굳이 꺼내지 않아도 될 것 같다.
투명한 프로젝트의 장점 중 가장 중요한 것은 다음 두 가지라고 생각된다.
첫 째, 여러 단계에 걸친 보고 과정에서 낭비되는 고급 인력의 시간을 실무적인 문제 해결로 돌릴 수 있다. 어떤 정보를 공개할 지, 어느 정도로 포장을 해야할 지, 유리한 데이터는 무엇이 있을 지, 경쟁자보다 우월해 보이려면 다소 무리해서라도 어떤 기능을 더 넣어야 할 지 등을 찾고 고심하는대는 생각보다 많은 시간과 노력이 필요하다. 한 구글 직원의 블로그에서는 자신들의 리더는 약 20% 의 리소스만을 관리에 쓰고 나머지는 같이 개발을 한다고 하였다. 반면 비효율적인 기업은 상위 20%의 인력은 관리만 하고 있는 것이 아닌가 싶을 정도이다. 고급 인력 한 사람의 적극적인 참여는 저급 인력 몇 명을 투입하는 것보다 훨씬 나은 효과를 낳는 경우가 많다. 이런 효과는 팀 규모가 커지고 과제가 장기화될 수록 더욱 뚜렷해진다. 과제가 진행되면서 노하우가 전파되고 개발인력들의 역량이 향상된다. 이 문제는 굉장히 심각한 것이.. 실무에서 몇 년을 일한 프로 개발자들 중 아직껏 대학생 수준의 코드를 작성하고 있는 경우가 너무 많이 목격되기 때문이다. 투명성 부여 하나만으로 해결될 일은 아니지만 문제를 부각시키는데 분명 큰 효과를 발휘한다.
둘 째, 조직이 스스로의 역량을 정확히 파악함으로써, 현실성 있는 비전과 전략을 수립하여 그에 집중할 수 있게 해준다. 어느 시점에 어떤 역량을 더 키워야 하는지도 판단할 수 있고, 이는 조직이 경쟁에서 살아남기 위해 꼭 필요한 정보 중 하나이다.
하지만 위와 같은 경직된 조직에서 과제에 투명성을 부여하기란 결코 쉽지 않다. 깨어 있는 사람에 의해 위에서부터 도입되는 시나리오가 가장 현실적이나, 정보가 차단된 문화에서 그럴 필요성을 느낄 수나 있는가가 첫 난관이다. 반대로 아래로부터의 개선은 변화를 시도하는 팀에게 상당한 모험이 될 것이다. 모든 정보를 투명하게 공개한 과제는 여러 겹 포장된 과제에 비해 생산성이 떨어지고 각종 문제들로 정신이 없는 것처럼 비춰지기 쉽다. 이런 현상의 진실을 경영진들에게 잘 납득시켜 결과가 나올 때까지 과제를 유지해 나가는 것이 가장 큰 난관이 될 것이다.
개발자들에게 오픈 마인드를 심어주는 것 역시 큰 장애가 될 수 있다. 자신들이 하는 일이 실시간으로 공개가 된다는 것은 자칫 일거수 일투족이 감시받는다는 오해를 불러 일으키기 쉽다. 실제 비공식적으로 도입해본 결과도 아랫사람들이 훨씬 적극적이며, 주로 위로부터의 말도 안되는 압박에 대한 방어효과 때문으로 보인다. 그리고 윗사람들이 하는 일도 다 같이 공개된다는 점을 잊지 말자.
마지막으로 그리고 절대 간과해서는 안되는 것이 있다. 정보 공개를 위해 귀찮은 추가 작업을 수행해야 한다면 업무 집중도가 떨어지고 정보 누락이 발생한다. 부정확한 정보를 얻기 위해 생상성을 떨어뜨리는 것은 바보짓이다. 따라서 충분한 논의와 교육으로 가능한 많은 이들과 공감대를 형성하고, 좋은 자동화 인프라를 갖춘 후에 시행에 옮겨야 한다. 의욕만 앞서 무리하게 추진하면 부정적 인식만 남겨 도입 시기를 더 늦춰버리는 역효과가 나기 쉽다. 지금까지 자칭 SE 라는 조직에서 수없이 반복해온 실수들이 아닌가!
하루라도 빨리 제대로된 개발을 해볼 수 있는 날이 오기를 바라며, 답답한 마음에 두서 없이 적어본 프로젝트 투명성에 대한 이야기를 마친다.
참고로, 인프라 관점에서는 본격적으로 제품이 나오기 시작한지는 아직 몇 년 되지 않아 제대로된 솔루션 중에는 선택의 폭이 넓지 않다. 현 시점에서는 IBM Rational 의 Jazz/RTC 와 MS 의 Visual Studio Team System 2010 정도가 눈에 들어온다. 통합 환경에 비해 사용법을 익히고 관리하는데 더욱 많은 노력이 드는 것은 어쩔 수 없지만, 별개의 여러 툴들을 조합해 사용할 수도 있다. 조직의 규모가 커질수록 투자할 만한 가치가 있을 것이다. 나라면 개발 인력 5명에 3개월 과제만 되어도 이런 류의 인프라를 도입할 것이다.
