Gloridea On The Stage

"우리 아이들에게
결코 불의와 타협하지 않아도 성공할 수 있다는
하나의 증거를 꼭 남기고 싶었습니다."

그러나 그는

불의와 타협하지 않으면
끝내 목숨을 잃게 된다는 증거를 남겼다.

목숨을 잃는 것이
결코 패배는 아니지만
나같이 비루한 범인들에게는 참 높은 벽이다.

아아, 오늘같은 날에는

황금빛 기름부음을 받으라.

벅찬 뺨을 흐르고 황홀한 목덜미를 훑어

외로이 맥박치는 혈관을 따라

땅 속 깊이 깊이 뿌리내리라.

남들 다 한마디씩 할 때 말 보태는 걸 그리 좋아하는 성격은 아니다. 남들 다 한다고 하면 할까 하다가도 안하는, 오히려 적잖이 삐딱한 성격에 가까운데, 그래도 뭔가 말을 하긴 해야겠다. 이것은 남들이 얘기하고 안하고의 문제가 아니라, 20대 내내 고민했던 것들 중 가장 많은 화두를 던져준 존재를 내가 어떻게 정리해서 받아들이냐 하는 문제이기 때문이다.

처음에는 현실감이 없었고, 그 다음에는 말이 떨어지지 않았다. 그리고 느꼈다. 아, 이 사람이 어떤식으로든 내 의식 속에 차지하는 공간은 작지 않구나... 이것을 언어로 정리하지 않으면 안되겠구나... 라고. 그러나 며칠이 지나도록 말은 정리되지 않았다. 지금도 술김이 아니라면 절대 쓸 수 없을 것 같아서 일단 쓰고 본다.

정리라던가, 일관성, 이런 건 일단 포기할 수밖에 없다.

.

그의 언어는 시원하다. 분노를 결집시키고, 동지들의 의지를 불태우며, 지지자를 결집시킨다. 그의 말에는 시시비비가 분명하며, 당위에 모자람이나 부끄러움이 없다. 말과 삶이 일치한다. 이십대에 그런 정치인에 열광하지 않는다면 누구에게 열광할 수 있을까. 깨뜨려야 할 벽 앞에 온 몸을 내던져 깨져가며 그 틀을 바꾸려는 바보 노무현을 어찌 사랑하지 않을 수 있었을까.

세상에 온통 뜯어 고쳐져야 할 구조와 부조리하여 어떻게든 바로잡혀야 할 사람들만 보이던 시절엔 그러했다.

.

나는 기본적으로 권모술수를 가치중립적으로 여긴다. 그것은 분명 사용하면 사용할수록 사용하는 이의 육체와 정신을 갉아먹는 위험한 것이지만, 그것이 필요없다고 생각해본 적은 단 한 번도 없다. 목적에 이르기 위한 길이 눈밭에 뿌려진 핏방울마냥 순일하고 선명한 것일 수도 없고, 그래서도 안된다고 생각했다. 중요한 것은 인민의 입에 무엇을 떠 먹이느냐, 그리고 인민이 욕하고 싶은 이를 욕한 뒤 후환을 두려워하지 않으면서 살 수 있도록 해주느냐라고 생각했다.

그러나 노무현의 방법은 칼끝에 투명하게 배인 핏방울마냥 너무나도 선명했다. 그러한 의지를 초인적이라 하지 않으면 다른 무엇을 초인적이라 부를 수 없을 것 같았다. 내가 마키아벨리스트이기 때문에 그는 나에게 특별했다.

.

그가 대통령이 되기를 염원하며 희망돼지 모금에 보냈던 당시의 보잘것 없던 돈 10만원은, 당시의 내겐 (잉여라는 관점에서 따지면) 지금의 수십 배가 넘는 금액이었다. 당시의 내게 그가 이루고자 하는 가치는 정말 간절한 염원 중 하나였다. 그러면서도 그가 대통령이 된다고 해서 그렇게 많은 것이 바뀔 거라고 기대하지는 않았다.

그리고 그는 대통령이 되었다.

기쁘다고 신나게 돌아다니거나 하지는 않았다. 그저 개표 발표 직전 엄기영 앵커의 입꼬리에 살그머니 붙은 숨길 수 없는 미소를 보고 얼핏 당선을 예감했고, 지인과 닭에 맥주를 마시며 조촐히 기쁨을 삭였다. 그리고 얼마 지나지 않아 개혁당은 산산조각났다.

.

그리고 이어지는 실망, 실망. 그것은 노무현에 대한 실망이기도 했지만, 실은 팔 할이 소위 민주세력이라는 작자들의 앎의 일천함과 실력 없음에 대한 것이었다. 그리고 그런 앎과 현실감각, 그리고 인재는 절대 공짜로 얻는 게 아니라는 것을 통감했다. 아아, 수권 능력이란 시간을 들이고, 돈을 들여서 사람을 길러야만 얻어지는 것이구나... 라는 것을 절감하고 또 절감했다.

한편으로는 노무현의 입이, 참 원망스러웠다. 지지자를 끌어모으는 언어와 적을 회유하는 언어는 다르다. 대통령이라면 후자를 자신의 언어로 삼아야 한다. 게다가 거기에 이해관계가 얽히면, 진정성 같은 것으로는 어찌 해볼 수 없는 큰 공백이 존재한다. 그는 그것을 알면서도, 결국 자신을 이기지 못하고 매번 그 앞에 걸려 넘어졌다. 그러나 어찌하랴. 사람은 자기 존재 양식을 버리고는 살 수 없는 존재인것을. 그리고 기득권은 그러한 노무현에게 참 지독하게도 가혹했다. 노무현은 그들과 전쟁조차 치를 수 없었다. 애당초 기득권은 노무현을 자신들과 전쟁할만한 동격의 존재로 인정한 사실이 없었다.

.

술 먹지 않은 날 이어서 쓴다.

.

파병에는 반대했지만, 노무현을 미워하진 않았다. 오히려 너무 빤히 진심이 보여서, 그냥 애처로웠다. 하지만 새만금을 끝내는 메워버리고, FTA를 진행하는 시점에 나는 그와 정서적으로 이별했다. 대통령이 어찌 할 수 없는 것들이 많다는 걸 감안해도 - 가령 비정규직 보호법이라던지 - 위의 두 사건만큼은 대통령의 의중이 반영되지 않았다고 할 수가 없어 보였기 때문이다. 민주노동당과 진보신당은 노무현만큼이나 내게 서글펐다. 결국 나는 아직까지도 정치적 지지 세력을 정하지 못한 채 표류하고 있다.

.

그가 죽었다. 죽어야 할 인간들은 살아서 천세 만세를 누릴 듯 기세 등등한데, 정치 역정 뒤에서는 얼마든지 존경받아도 좋을 그가 스스로의 목숨을 끊었다.

.

영결식 이전에 어떻게든 글을 끝맺고 싶었다.  내 안에서 그가 어떤 형태로든 납득할 수 있도록 정리되었으면 했지만, 지금까지도 불가능하다. 앞으로도 상당히 오랜 시간동안 불가능할 것 같다. 그의 삶과 죽음이 던지는 질문에 대해, 나는 아직 대답할 준비가 되어있지 않은 듯하다. 그것은 거창한 각오나 담론이 필요해서가 아니다. 그냥 삶을 이해하는 방식, 그것 하나를 소화시키는데도 너무 많은 생각이 필요하기 때문이다.

내가 가장 좋아했던 그의 죽음을 진심으로 깊이 애도한다.

어느 날 갑자기 회사 사람과 이야기를 하다가 문득 깨달음이 왔다. 그래서 미투데이에 <깨닫고 보니 애자일은 할부 기법이었더라>라고 적었다. (그리고 덧글로 "생각해보니 인생의 거의 모든 일은 일시불과 할부 사이에 있다." 라고 적었다.)

세상에 공짜는 없다. 너무나 당연하면서도 그 무게를 가벼이 볼 수 없는 황금률중의 황금률인데, 사실 이 법칙은 애자일의 전반에 배어 있다.

소스코드 통합

각 부분을 나눠서 개발하고 합치는 작업은 반드시 예상치 못한 문제와 맞닥뜨리게 되어 있다. 만약 그렇지 않았다면, 천재 리더를 만났거나, 설계에 엄청나게 많은 - 개발에 거의 맞먹을 정도로 - 시간을 쏟았거나 (그럼에도 불구하고 이 문제는 대부분 피해갈 수 없다), 아주 작은 프로젝트인데다가 운이 좋았거나일 가능성이 대부분이다. 이 때 많은 문제점이 드러나고, 이것은 프로젝트를 중단시키고 '처음부터 뒤집어 엎는' 결과로 이어진다. 혹은 어떻게든 프로젝트를 미봉한 채 완료짓기도 한다.

이번 프로젝트에서 각 스프린트는 10일로 잡았다. 첫번째 스프린트는 전체 개발 환경 구성이 되지 않아 각 요소만을 개발하고 샘플 페이지를 릴리즈했다. 두번째 스프린트의 후반에서 통합을 수행했는데, 나름 준비할만큼 했다고 생각했지만, 역시 통합은 또 다른 문제였다. 통합을 수행하면서 몇 가지 굉장히 황당한 문제를 겪었고, 막판에 버그를 잡느라 상당한 고통을 감수해야 했다. 다행인 것은 어쨌거나 두번째 스프린트에서 통합을 완료했다는 것이다.

애자일 방법론이 통합의 고통을 제거해주는 것은 절대 아니다. 다만 이것을 반복적인 개발의 주기 내에 계속 나누어서 하도록 한다. 갚을 돈을 한 번에 갚느냐, 다달이 나눠 갚느냐의 느낌에 가깝다. 중요한 것은, 비용은 '어디에선가는 반드시' 치러야 한다는 것이다. 그리고 널리 알려졌다시피, 그 비용은 후반으로 갈수록 '지수적으로 증가하는 이자'를 물게 되어 있다. (그럼에도 불구하고 오늘도 많은 조직들이 정치적 이유로 앞에서 벌어서 뒤에다가 폭탄 쌓는 일을 한다.)

QA와 인수 테스트, 그리고 버그 수정

프로젝트 막바지에 이르면 개발자들은 BTS와의 전쟁을 벌이느라 심신이 초췌해지고, QA는 QA대로 품질 낮은 코드와 사투를 벌이며 기본적인 동작에 대한 QA로 시간을 다 소모하느라 정작 깊이있는 부분에 대한 체크는 묻어두고 지나가곤 한다. 스크럼에서 QA는 각 스프린트 내에서, 혹은 스프린트마다 전달하여 진행하는 것을 권장한다. 가급적이면 스프린트 내에 진행하는 쪽으로 진행하고 싶었지만, 몇 가지 이유로 스프린트마다 전달하는 것으로 가닥을 잡았다.

한 스프린트가 시작이 되면 스프린트 시작 + n 일 내에 QA에서 해당 기능에 대한 인수테스트 항목을 넘겨받는다. 사용자 스토리를 상세화 할 때 인수 테스트 항목도 정리하는 것이 좋지만, (혹은 인수 테스트 항목이 산정되어 있으면 스토리 포인트 산정에도 도움이 될 수 있다) 상황의 짜임에 따라 그 때 그 때 필요한 만큼을 넘겨받는 방법도 수용 가능하다. 그리고 개발자는 각자 개발한 기능을 전체 소스에 통합하고 반드시 이 인수테스트 항목을 수행한다. 개발할 때도 매우 유용하게 참고할 수 있다. 그리고 QA는 이전 스프린트에서 릴리즈된 항목을 테스트하고 그 결과를 BTS에 등록한다.

상당히 빡빡한 일정 속에서 QA 결과가 올라오면, 개발자는 신규 기능을 개발하는 일과 버그 수정에 대응하는 일 모두를 수행해야 한다. 이는 심리적 압박감 뿐만 아니라 주의의 분산까지 가져오기 때문에, 반드시 이를 수행할 수 있는 시간을 확보해 주어야 한다. 잘 돌아갈 경우 20% 내외의 시간을 할당하면 될 것으로 예측하고 있다. 다만, 문제가 있다면,실질적으로 필요한 시간임에도 불구하고 BTS 처리 시간을 전체 스크럼 계획 회의에서 필요 시간으로 포함시키는 것이 정치적으로 민감한 부분이라는 것이다.

버그는 일찍 발견될수록 수정 비용이 감소한다는 것 또한 널리 알려진 상식 중 하나이다. 그러므로 한 두 스프린트에 끝날 프로젝트가 아니라면 QA를 마지막에 한꺼번에 몰아서 하는 것은 절대 답이 될 수 없다. QA를 개발 주기에 맞춰 반복적으로 수행하는 것 또한 후반에 치러야 하는 비용을 프로젝트 전반으로 분산시키는 방법인 셈이다.

최근 출간된 스크럼과 XP에서도 이러한 상황에 대해 상당히 유용한 가이드를 제시하고 있다 (개인적으로는 매우 많은 도움을 받았다).

코드 공동 소유와 트럭 넘버, 병렬 개발

각 기능간의 상호작용이 많고 긴밀할수록, 동시에 개발되는 기능이 많을 수록, 각 개발자는 다른 개발자가 짠 코드를 잘 알아야 한다. 그러나 기능별로 나눠서 담당을 맡기고, 그 담당이 혼자 해당 구현을 맡도록 할 경우, 각 개발자는 다른 인의 코드 보는 일을 할 수 있는데까지 미루게 되어 있다. (이 문제는 개발자의 부도덕함이나 안일함 때문에 발생하는 것이 아니라, 타인의 코드라는 것 자체가 원래 어려운 반면, 개발자에겐 항상 일이 많기 때문에 발생한다.) 그리고 그것을 구현하지 않은 사람은 손을 댈 수 없는 문제가 발생한다.

전통적인 방식에서는 이러한 문제를 해결하기 위해 핵심 모듈을 신중하고 엄격하게 설계하여, 이것을 사용하는 사람들은 모두가 정의된 명세에 따라 개발할 것을 요구한다. 그리고 핵심 모듈은 가장 경력이 많은 개발자가 책임을 지도록 한다. 그러나 요구사항은 변하고, 명세도 변하고, 이를 사용한 코드도 모두 변한다. 해당 부분을 개발한 책임자는 다른 어떠한 일을 하고 있다가도 다시 자신의 코드를 수정해야 한다 (다른 사람의 작업이 걸려 있으므로). 그동안 다른 개발자는 손 놓고 놀아야 하며, (아예 긴 시간이 비면 다른 일을 하면 되지만, 딱 애매한만큼 시간이 빌 경우가 가장 많다.) 해당 부분을 책임진 개발자는 지쳐서 녹초가 되어버리기 십상이다.

그리고 중요한 부분을 맡은 사람에게 일이 생기면 프로젝트 전체가 상당한 타격을 입는다. 이를 트럭넘버라는 말로 표현하는데, '프로젝트 구성원 중 몇 명 까지 트럭에 치이면 프로젝트가 더이상 진행될 수 없느냐'를 의미한다(예제가 좀 무시무시하긴 하다). 낮을수록 나쁘다. 1은 할 수만 있다면 피해야 한다.

애자일에서는 이러한 문제를 해결하는 방법으로 코드 공동 소유를 주장한다. 그리고 이를 위한 방법으로 짝 프로그래밍을 강력히 권장한다. (짝 프로그래밍에는 이런 문제를 해결해주는 것 외에도 엄청나게 많은 이점을 가진다. 하지만 다른 방법과 마찬가지로 항상 유용하지는 않으며, 외부와의 정치적 문제가 가장 큰 걸림돌이 된다.)

짝 프로그래밍은 코드 생산성에 있어서 1명이 개발할때에 비해 140~160%정도의 코드 생산성을 낸다고 한다. (직접 측정해보지는 않았으나, 경험적으로 동의한다.) 그러나 결함이 줄어들어 디버깅에 들어가는 시간이 단축되는 것과, 자신이 알고 있는 것 - 코드 및 개발 실천법, 설계의 관점 등 모든 것 - 이 타인과 동기화시켜서 그 사람이 언제든 이 일을 대신할 수 있도록 하는 이점 등을 감안하면, 결국 생산성은 유사하거나 더 낫다.

개발자가 많고, 병렬로 진행되어야 할 작업이 많을수록 코드를 이해하는 사람이 많다는 것은 굉장한 장점으로 작용한다. 아니, 어떤 식으로든 코드를 다른 사람에게 이해시키지 않고서는 병렬로 작업 진행 자체가 불가능하다. 코드를 배타적으로 지배하는 일이 전체 품질과 작업에 일으키는 병목은 프로젝트의 큰 위협 요소 중 하나이다.

위와 같은 관점에서, '교육 및 전파'를 별도의 프로세스로 나누어서 프로젝트 종료 후에 하는 (사실은 거의 흐지부지 하는) 일시불 방식에서, 프로젝트 전반에서 이를 수행하는 할부방식으로 전환하는 것으로 볼 수 있다.

개인적으로는 개발팀의 개발 속도를 낮추지 않고 트럭 넘버를 올릴 방법이 무엇이 있을지 굉장히 많은 고민을 했다. 하지만 어떤 방법을 취하더라도 결국 한 사람의 머릿 속에 있는 것이 다른 사람의 머릿 속으로 건너가야 한다면, (문서를 통해서든, 다른 방법을 통해서든) 그것은 결국 비용(개발 속도의 일시적 저하)을 치르고 살 수밖에 없는 절차라는 결론에 이르렀다. 역시 세상에는 공짜가 없다.

릴리즈

릴리즈란 동작하는 프로그램을 고객에게 전달하는 것을 말한다. 고객 - 스크럼에서는 제품 책임자 - 에게 전달되는 것이 가장 이상적이지만, 현재 진행중인 프로젝트의 경우, 릴리즈는 QA 단계로 전달하는 것을 말한다. 단, 이 경우 QA가 이해하는 제품 책임자의 의도와 실제 제품 책임자의 의도 간에 괴리가 생기지 않도록 장치를 마련해야 한다.

변경은 반드시 비용을 수반한다. 소소한 변경이라도 변경은 절대 공짜가 아니다. 그러나 아무리 주의깊게 기획하고 설계한다 하더라도, 실제로 구현해놓고 보면 생각과 다를 수 있다 (정확히 말하자면, 항상 다르다). 그러면 '아 이게 아닌데' 라는 게 드러나는 시점에, 그 프로젝트를 그대로 몰고 가야 할까?

많은 프로젝트들이 무언가 이게 아니라는 것이 드러난 이후에도 정치적인 이유로 그대로 끝까지 진행한다. 혹은 파워게임을 통해 문제를 전가시키곤 한다. 그러나 닭의 목을 비튼다고 새벽이 오지 않는 것이 아니듯, 기획 다 뒤집으면 아무리 오픈 일정은 고정되었다고 고래고래 선언한다 하더라도 일정은 지연되게 되어 있다. 서로 거짓말 게임을 한다고 해서 문제가 해결되지는 않는다. 그러나 이 비극은 사실 사람과 사람이 풀어야 할 문제이니 논외로 칠 수밖에 없다.

다만, 제대로 된 가치를 얻기 위해 변경을 하기로 마음을 먹었다면, 이것을 위한 비용은 반드시 치러야 한다. 그것은 다른 우선순위가 낮은 작업을 버리는 것일 수도 있고, 일정을 연기하는 것일 수도 있다. 혹은 사람을 추가 투입하는 방법일 수도 있다. (추가 투입이라는 방법은 신중하게 결정해야 하는 부분이다. 추가 투입은 커뮤니케이션 비용을 증가시키고 추가 투입 인력이 궤도에 오를때까지 기존 인력의 생산성마저 저하시킨다.)

그래도 반복적인 개발을 통해 매 반복(스크럼에서는 스프린트라고불리우는)마다 가장 중요한 기능을 고객에게 전달하는 과정은, 고객이 최종 시점에 자신이 원하지 않던 결과물을 받아보게 되는 문제를 상당 부분 방지해준다. 결국, 매 스프린트마다 개발팀은 결과물을 '조금씩 나눠서 파는' 것이고, 고객은 '조금씩 나눠서 사는 것'이 되는 셈이다. 역시 할부다.

맺음말

세상에 은탄환 따위는 없다. 아무리 좋은 프로세스를 도입해도 해결해야 할 문제는 산적하여 있으며, 매 순간마다 닥치는 문제를 푸는 것이 프로젝트 수행의 핵심이다. 이것을 도외시하고 프로세스에 매달린다고 해서 문제가 해결되지는 않는다. 문제가 자동으로 풀리는 프로세스... 그런 건 꿈속에조차 존재하지 않는다.

그러나 문제를 풀 때 도움이 되는 많은 실천법은 분명 존재한다. 이번 프로젝트를 진행하면서 애자일 방법들 중 우선적으로 적용 가능한 몇 가지를 적용해 보았고, 많은 효과를 보았다. 그러다보니 그 맥락을 꿰뚫는 어떤 하나의 흐름이 느껴졌고, 그것을 '할부'라는 표현을 사용해서 정리해 보았다.

할부라는 은유는 '어쨌거나 치르기는 치러야 하는 비용'이라는 의미도 있다. 분명 투자수익률이 높은 실천법과 그렇지 않은 실천법은 존재하지만, 공짜는 없다. 결국 그 비용을 언제 치를 것인가 하는 문제가 중요하다. 애자일은 이 비용을 프로젝트의 특정 순간에 몰아서 지불하는 것이 아니라, 프로젝트 전반에 넓게 분산시켜서 지불하는 것을 강력히 권장한다. (위에서 언급한 부분 외에도, 애자일 다른 실천법도 비용의 분산이라는 관점에서 다뤄 보고 싶지만, 너무 졸리다. @_@)

그러나 현실은 항상 쉽지 않다. 드러낼 수 있는 모든 비용을 다 드러내고 프로젝트를 진행할 수 있다면 행복하다. 무엇을 목표로 삼고, 무엇을 얻기 위해 노력하고, 무엇을 버릴것인가가 명확하면 마음의 평화를 얻을 수 있다. 그러나 기획자는 개발자를 신뢰하지 못하고 무조건 푸시하면 된다고 생각하고, 개발자는 기획자가 푸시할 게 뻔하니까 일정을 뻥튀겨 잡는, 서로가 서로에게 거짓말 게임을 하는 세상에서는 둘 다 행복해질 수 없다. 더 중요한 것? 고객(사용자)도 행복해질 수 없다는 것이다. 결국에 모든 누락된 비용은 품질에 전가되기 때문이다.

다음번에는 '공짜는 없다'의 관점에서 품질과 개발 프로세스를 다뤄볼까 한다. (시간 나면)

이노베이션 신화의 진실과 오해 스콧 버쿤 저/임준수,서상원 공역

소개글만 읽어도 충분한 책.

<이노베이션은 그분이 오시는 극적 순간에 탄생하는 게 아니고, 이노베이션을 창출할 수 있는 규정된 프로세스는 없다> 라고 얘기해놓고도 이노베이션을 탄생시키는 구성요소를 규명하려고 참 애를 많이 쓰지만, 그다지 쓸만한 얘기는 나오지 않는다. 저자가 본문에서 인용한 인용구들이 가장 쓸만하다.

게다가 표지에는 이렇게 써 있다. "전화기에서 구글에 이르기까지 신화를 만드는 이노베이션의 공식을 배운다." 요즘은 본문이랑 반대되는 말을 표지에 적는 게 대세인가보다.

개인적으로 모든 성공은 맥락 속에서만 성립한다고 믿기 때문에, 그 자세한 맥락을 충분히 이야기하지 않는 종류의 글을 그다지 높이 평가하지 않는다 (모든 맥락을 다룰 수는 없을지라도, 읽다보면 주요한 맥락을 잘 잡아내었는지 혹은 빠뜨렸는지는 대충 감을 잡을 수 있다). 가끔 예외적으로 높은 추상화와 일반화의 역량을 보여주는 사람들이 있는데, 유감스럽게도 이 책에서 그러한 역량을 발견할 수는 없다.