조직의 변화에 대해 이야기할 때, 상향식(bottom-up), 하향식(top-down) 운운하면서 서로 책임을 회피하는 경향이 심하다는 느낌이다.

상향식은 조직의 아랫사람들부터 변화의 물결이 일어 결국 윗사람들까지 동참시키는 경우이고, 하향식은 반대로 윗사람의 의지에 의해 아래까지 변화를 일으키는 방식이다.  어느 방식이 더 나은 선택이 될 것인가? 만약 어느 한쪽을 운운하는 사람은 변화도입에 대한 전문성이 부족하거나(하향식 변화 도입에 대한 환상[1] – 김창준), 혹은 자신의 책임을 회피해보려는 시도를 하고 있다고 볼 수 있을 것이다.

하향식 변화 도입에 대해선 위 김창준씨의 글을, 상향식 변화 도입에 대해서는 일전에 내가 작성해둔 글 – Show Me The Magic[2]을 참고하면 좋을 것이다. 그리고 그 둘의 결론 역시 Show Me The Magic 에 잘 나타나 있다.

그럼에도 이 글을 적는 목적은, 조직에서 자신의 위치, 자신의 역할에 대한 자각의 필요성을 느껴서이다.

내가 변화시켜보려 했던 팀에서 가장 큰 문제들은 바로 하급 관리자가 조직의 머리에 해당하는 사람들의 논리를 대변한다는 것이었다. 대략 8 단계로 이루어진 조직 피라미드의 밑에서 3번째에 위치한 사람들에 해당하는 이야기이다.

아래에서 3번째이면 말단 관리자, 즉 아래에서부터 올라가 최초로 ‘관리자’라는 타이들을 달아볼 수 있는 직급이다. 이 계층의 구성원들이 ‘먼저 다른 사람들을 다 설득시키고 나한테 오라’, ‘정말 좋으면 내가 참여 안해도 다들 하겠지’ 라는 말을 하고, 뒷짐진채 ‘자! 재주껏 나를 설득해봐!’ 라는 자세를 취한다. 그러면서 ‘역시 상향식 변화는 안되’라고 말하는 모습을 보며 ‘당신이 현 조직에서 윗사람에 해당한다고 생각합니까?’라는 말이 목구멍까지 올라왔지만 참은 적도 몇 번 있다. ^^

그 계층에서부터 공감대를 형성하고 의지를 다져 변화를 이야기해야 비로서 ‘상향식 변화의 첫 발을 내딛었다’ 라고 할 수 있다. 아랫 사람들의 목소리를 전파해줄 수 가장 낮은 위치의 사람들이 그 위치에 올라서자마자 이런 마음자세로 돌변한다면, 그 조직은 절대 변화할 수 없다. 그렇다면 하향식 변화를 기대해야 할까? 그것 역시 환상이다[1].

이 글을 읽는 분들은 자신이 조직에서 어느 위치에 있는지, 그 위치에서 어떤 역할을 해주어야 더 나은 조직으로 변화할 수 있을지 찬찬히 생각해보았으면 한다.

---

References

1. 하향식 변화 도입에 대한 환상 (애자일 이야기, 김창준)
2. Bad Team Culture – Show Me The Magic (wegra.org)

Don’t Code, Write!!

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

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

자.. 그럼..

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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