[Phase#0 — Prequel]

필자가 대학을 졸업하고 국내 최대 SI 회사인 S사에 들어갔을때,

흥미롭게도 주변 사람들의 반응은 극명하게 갈렸다. 그 회사에 현재 다니는 선배들은 “제발 이곳에 오지 말라. 너를 위해 다른 선택을 하라”라고 했고, 그 외 분들은 진심으로 입사를 축하해주었다.

입사 후 6개월 정도가 지난 때부터 난 선배들이 말한 “이곳에 오지 말라”라는 이유에 대해 이해하기 시작했다. 당시 공공 SI사업 현장은 다양한 문제들이 있었다. 필자도 자연스레 IT 엔지니어로 일하는 곳에서의 문화/환경/인식에 대한 불만이 점점 쌓여갔다.

여러가지 점에 대해 이야기 할 수 있겠지만, 필자의 가장 큰 불만은 “내가 성장한다는 느낌”이 들지 않았다.

당시 상황을 회상해보면, 개발하는 패턴이 너무 단순했다. 기술에 대한 선택은 개발자의 몫이 아니었다. 대형 SI개발을 위해 만들어진 프레임웍들은 필자가 능력이 없더라도 쉽게 기능을 개발하도록 도와주었다. 굳이 주변에 물을 필요도 없었다. 코딩의 대부분은 70%정도는 Copy & Paste 하면 되었다.

요새는 코드리뷰라는 것에 대해 당연시 하며 개발자들끼리 이야기 하고 있지만, 당시 서로의 코드는 아무도 쳐다보질 않았다. 누가 코딩을 잘 하는지, 잘 하지 못하는 지 실제 알 수 있는 방법은 특별히 없었다.

이렇게 단조로운 생활 + 야근/주말 출근이 반복되는 삶을 지내면서, 필자는 매우 답답해 지기 시작했다. 필자 옆에 앉아 있는 피곤해 보이는 필자의 10년 선배가 나와 똑같은 일을 하는 것을 보며, 두려움이 밀려들었다. 그리고 나에 대해 보다 진지하게 고민하기 시작했다.

“내가 지금 여기서 무엇을 다르게 할 수 있을까?”

그리고 여러가지 시도를 시작했다. 이제부터 이야기 할 내용들은 필자가 직접 겪었던 이야기들이다.

아래 내용은 과거 여러 회사의 애자일 전문가들가들과 공동집필한 “애자일 SW개발 101” 이라는 책에 필자가 기고했던 내용을 기반으로 부가적으로 이야기 하고 싶은 내용을 추가한 것이다.

고생스런 유지보수 경험을 하다.

2005년 겨울, 필자는 대형 공공 SI 사업에 개발자로 참여했다. 그는 이 프로젝트에서 다른 149명의 프로젝트 참여 인력과 마찬가지로 13개월 동안 고되게 야근을 해야 했다. 사실 이번 프로젝트는 개인적으로 그의 현재까지 회사 생활 중 가장 힘든 경험이었다.

우여곡절이 많았지만 다행스럽게도 납기를 지키고 시스템은 오픈을 했다. 필자는 내심, 가능한 빨리 이 프로젝트를 떠나고 싶었지만, 운영 PM으로 내정된 김피엠의 끈질긴 설득으로 유지보수에 남기로 했다.

그는 남기로 한 선택을 곧 후회하게 된다. 왜냐하면 그는 유지보수 팀에서 예상보다 굉장히 많은 일을 떠맡게 되었기 때문이다. 물론, 개발 프로젝트와 달리 유지보수 프로젝트의 인력은 일반적으로 한 사람이 여러 가지 역할을 맡는다. 하지만, 당시를 회상해보면 3년 차 엔지니어에게 맡겨진 일 치고는 많아도 너무 많았다.

그러다 보니, 필자는 엔지니어로서는 시스템 관리 업무 개발, 로그인/보안 등의 공통기능을 개발하는 일, 서버를 운영하는 일, 배포(당시 분배라고 부름)를 담당하는 일 등을 해야 했다. 게다가 관리자로서 PL을 맡아 고객과 신규 및 변경 요구사항에 대해 협상하는 최접점 역할을 수행했다. 그가 맡은 일은, 불과 6개월 전만해도 8명이 하던 일 이었다. 이를 모두 인수인계 받았을 때 필자는 현기증이 나고 머리가 폭발할 지경이었다.

유지보수 프로젝트가 시작된 후, 세 달 가까이 야근과 주말 출근이 반복되었다. 이 때 그의 작업 강도는 개발 당시보다도 훨씬 센 것이었다. 당시 근무시간외 수당이 시간당 5,000원었는데, 필자는 월급을 제외하고 이 수당으로만 한 달에 100만원 가까이 모을 수 있었다.

그는 이 시간을 견디기 힘들어 했다. 매일 오후 4시쯤에 화장실 거울을 통해, 스트레스 때문에 얼굴 전체가 붉어진 스스로를 발견할 수 있었다. 그는 항상 이 때쯤 세수를 하며 짜증과 열을 식히곤 했다. 일할 시간이 부족하여 점심을 거르는 경우도 종종 있었다.

사실 지금 돌아보면 대형 프로젝트의 유지보수는 늘 그랬다. 수정할 버그가 많았고 남은 일도 많았음에도 불구하고, 구축 프로젝트 기간이 종료됨과 동시에 먼저 1/10 수준으로 인력을 줄이고, 시간이 지나면서 더 줄여나갔다. 또한 갑을 관계에서 을(주사업자)회사의 인력은 비용이 병, 정회사보다 높게 산정되기에, 을 회사의 인력은 상대적으로 책임감 있는 인력이 적었다. 그때는 이 매커니즘을 이해하는데 너무 경험이 부족했다. 그냥 힘들기만 했다.

실험#1 — 신뢰를 얻다.

보통 사람은, 스스로가 편안할 때 보다, 힘든 시기에 현재 상태를 바꾸고자 하는 의지가 강해진다. 필자도 당시에 그랬다. 이러한 상황이 지속되자 “이렇게 살다간 안되겠다 뭔가를 해야지” 라는 원초적(?) 의지가 점점 커졌다. 이 때 필자 주변에 매우 좋은 자극을 준 선배가 있었는데 그 선배는 ‘애자일’이란 것의 신봉자였다. 그 선배를 통해 필자는 제약이론(Theory of Constraint)의 창시자 골드랫 박사의 “The Goal” 이란 책을 읽을 수 있었다. 또한 그를 통해 Cruise Control (후에 이 도구는 젠킨스(Jenkins) 라는 이름으로 바뀌게 된다) 이라는 지속적인 통합 툴을 배울 수 있었다.

필자는 이 선배를 통해 현재 상황에 대해, 객관적으로 관찰하고 문제점이 없는지 고민하는 방법을 배울 수 있었고, 스스로 하는 일들을 훌륭하게 관리하는 방법을 깨우칠 수 있었다. 그리고 그 때부터 애자일에 대한 공부를 하기 시작했다.

유지보수 시작 후 3개월 정도가 지나자 시스템은 점차 안정화되어 갔다. 자연스레 필자의 근무시간외 수당도 점점 줄어갔다. 고생할 당시는 매우 답답함을 느꼈으나 그 때의 경험은 꽤나 값진 것이었다.

이 기간을 통해 그는 매우 중요한 자산을 얻었다. 그것은 ‘관리자와 고객의 무한 신뢰’ 였다. 그가 헌신한 만큼의 충분한 신뢰가 쌓인 것이었다. 이때부터 필자가 하는 많은 것들이 수월해졌다. 관리자와 고객들은 그를 믿기에 그와 대화하는 것을 좋아했다. 하물며 엉뚱한 것을 제안하더라도 (반드시 무슨 이유가 있을 것이라 생각하고) 필자의 이야기를 긍정적으로 들어주었다.

또한 매우 경험이 부족할 때도 많은 것을 의사결정할 수 있었다. 오랜 공공 시장의 갑을병정 관계에서 을 (주사업자)회사에 있다는 것 만으로 보다 많은 권한이 주어졌다. 상대적으로 어리고 경험이 부족하더라도, 필자의 이야기에 귀기울이는 이들이 많았다.

이즈음, 필자는 주변 사람들과 많은 대화를 시도했다. 그리고 애자일이라는 것에 대해 여러가지 책을 읽기 시작했다. 당시 Xper(한국익스트림사용자모임)이라는 개발자 모임에 가서 여러 개발자들을 만났고, 그들의 경험을 들었다.

그리고, 주변을 변화시키려는 시도를 시작했다.

그것중 하나가 가장 가까이의 의사결정자 였던 김피엠에게 그가 공부한 애자일이란 것이 무엇인지에 대해 설명하기 시작했다. 당시를 회상하면 그는 정말 열린 사람이었다. 필자의 이야기가 다소 이상적인 것이라도 늘 들어주었다. 다만, 그렇다고 내가 하려는 것에 대해 모든 것을 이해해 주기에는 현실적으로 어려웠다. 늘 바빴고, 늘 많은 일이 그를 괴롭혔다. 때문에, 소극적이고 점진적인 접근 방법으로 이야기를 시작했다. 의견의 충돌보다는 다음과 같은 유연한 타협으로 대화를 시작했다.

필자: “피엠님, 이 책 한번 읽어보실래요? 미국에는 이런 애자일이란게 있데요. 근데 참 재미있어요. 짝 프로그래밍이라고, 둘이서 한 키보드를 두고 같이 개발을 한데요. 하하하. 피엠님이 들으면 기가 막힐 이야기죠.”

김피엠: “그래? 하하 그거 재밌네. 근데 그렇게 프로젝트를 하면 돈이 남을까?”

필자: “에이.. 물건너 얘긴데요 뭘. 근데, 미국은 여러 가지 상황이 좋으니까 남긴 많이 남는데요. 프로젝트 상황 괜찮아지면, 우리도 한번 해볼까요?”

김피엠: “하하, 신입 사원 들어오면 한번 해봐라. 그렇게 하면 얘가 일을 얼마나 잘하는 앤지 몇 시간 안에 알 수 있을 것 같은데?”

필자: “와! 좋은 생각이세요. 그럼, 신입이 들어오면 제게 맡겨주세요. 한번 교육을 시켜 볼께요.”

필자는 2 개월 후 들어온 신입사원 3명에게, 실험군과 대조군을 만들어 짝 프로그래밍을 시켰다. 그리고 그 실험결과를 리포트로 만들어 김피엠에게 주었다. 이 리포트를 통해 김피엠은 개발에 전혀 관심이 없던 신입사원이 어떻게 변화하는지를 관찰하며 매우 즐거워했다. 김피엠이 짝 프로그래밍을 보는 시선은 자연스레 달라졌다. 짝 프로그래밍은 그에게 더 이상 공수를 갉아먹는 말도 안 되는 방식이 아니라, 교육을 시키며 관리를 하는 매력적인 도구로 비추어 졌다.

실험#2 — 다시는 하고 싶지 않은 경험

신입사원을 대상으로 한 실험이 성공적으로 끝나자, 필자는 더 많은 욕심이 생겼다. 무엇이든 더 할 수 있을 거라는 자신감으로 가슴이 가득 찼다. 하지만 남들에게 무엇인가 함께 하자는 제안을 할 용기는 아직 없었다. 유지보수팀의 구성원 대부분이 그보다 많은 사회 경험을 가지고 있었으므로, 이러한 선배들에게 새로운 것에 대한 제안을 하는 것은 매우 어려운 일이었다. 그래서 먼저 혼자서 할 수 있는 것을 찾아보기 시작했다.

‘리팩토링’ 이란 것이 눈에 들어왔다.

“리팩토링은 [기능은 그대로이지만 코드의 디자인을 개선하는 것]이다. 이것은 내 코드에 나 혼자서도 할 수 있는 것이다. 누구에게도 이야기할 필요 없이…”

이때부터 그는 리팩토링을 수행할 사냥감을 찾기 시작했고, 가장 먼저 눈에 들어온 소스는 로그인 부분이었다. 당시 로그인 소스는 말 그대로 스파게티 코드였다. 최초의 코드는 단지 한 개의 클래스로 이루어져 있었다. 라인 수도 적고 가독성도 그리 나쁘지 않았다. 하지만, 여러 업체가 로그인에 보안 및 암호화 솔루션을 추가로 심으면서 코드는 점점 변질되어갔다. 게다가 고객들의 빗발친 요구사항으로 인해 해당 솔루션은 규칙 없이 여러 조각의 긴 클래스들로 커스터마이징되었다. 결과적으로, 코드 덩어리는 빗물에 쓸려가는 찢어진 신문지 같이 지저분해졌다.

필자는 이 코드를 리팩토링하기로 했다. 클래스를 분할하고 10 줄 이상되는 메소드는 추출하여 적절한 책임에 맞는 클래스에 매핑시켰다. 1,500 줄 정도 되는 코드는 클래스당 100 줄 정도씩으로 단순화 되었다. 그는 매우 기뻤다. 그는 그 코드가 그의 노력의 산물이고 결국 시스템에 훨씬 유익한 일이라 확신했다. 다만, 그는 아무에게도 그 코드를 리팩토링 했다는 이야기를 하지 않았다. 사실 할 필요가 없었다. “누가 이 엄청난 작업을 이해하겠는가?” 라고 오만을 떨며 즐거워했다. 그리고 1 달간 리팩토링한 코드를 배포했을 때, 그는 엔지니어로서의 짜릿함을 느꼈다.

대형사고를 치다

하지만, 그 짜릿함은 오래가지 않았다. 새벽 1시에 배포된 내용은 다음날 아침 커다란 후 폭풍으로 밀려왔다. 35만명의 사용자가 4시간 동안 로그인을 하지 못했다. 신문에 날 사고를 바로 필자 본인이 만들어 낸 것이었다. 고객 팀장이 사무실로 부랴부랴 와서 처음에는 화를 내다가 몇 시간 후 부터는 살살 필자을 달래기 시작했다. 고객 팀장의 얼굴은 새파랗게 질려 있었고 그가 식은땀을 흘리며 다음과 같이 이야기 했다.

“저기.. 복구는 가능한거지? 응? 되는거지?”

필자는 이해가 되지 않았다. 개발환경에서 분명히 완벽하게 돌던 소스였다. 무엇인가 이상했다. 그리고 억울했다. 그는 4시간에 거쳐 이를 겨우 복구해냈다. 김피엠은 모든 상황이 종료된 후 다음과 같이 이야기 했다.

“내가 그동안에 네가 주던 신뢰가 이번 한번에 완전히 무너졌다”

김피엠은 이 일의 후속 조치로, 다시는 이 같은 일이 발생하지 않을 것이고, 만약 발생한다면 책임지겠다는 각서까지 썼다.

필자는 끝까지 리팩토링을 하여 소스코드에 문제가 생긴 것이라는 걸 누구에게도 말하지 않았다. 그냥 예전에 고쳤어야 할 기존 코드의 동작이 결함으로 올라와 사고가 난 것이라고 이야기 했다. 그는 도저히 그 모든게 그가 한 일이라고 말할 수 없었다.

이러한 문제가 생긴 이유는 무엇일까? 사실 이유는 단순했다. 그는 당시 거의 자살행위나 다름없는 방식으로 소스를 분배한 것이다. 신 개발은 테스트 코드 없이 리팩토링을 했고, 결과적으로 기능 하나하나가 잘 동작하는지 전혀 검증하지 않았다.

이 실험을 통해 그는 많은 교훈을 얻었다. 이후 필자는 비슷한 방식으로 리팩토링을 혼자 시도해보려는 엔지니어들을 보면 “절대 생각조차 하지말라” 고 이야기하기 시작했다.

실험 #3 — 유지보수에 사용해 본 칸반(Kanban)

수 개월이 지나 이 전의 사고가 잊혀질 무렵 이 유지보수 팀은 착한 팀이 되어 있었다. 스스로 맡은 바 책임을 다하는 것은 물론, 다른 팀원이 힘들 때는 기꺼이 도와주기도 했다. 하지만 여전히 고질적인 유지보수 조직의 문제를 어느정도 가지고 있었다.

유지보수 조직은 보통 업무 별로 인력이 할당되기 때문에, 시기에 따라 바쁜 사람과 바쁘지 않은 사람이 갈리게 된다. 이를 효과적으로 구분하고 바쁜 사람의 부담을 서로 분담하는 체계가 필요했다. 이를 위해 필자는 “큐(Queue)제어 방식인 칸반을 도입하자” 라는 제안을 했다. 팀원 모두 이 문제에 대해 공감하고 있었기 때문에 쉽게 동의했다.

먼저, 눈으로 보이는 즐거움을 주기 위해 예쁘게 코르크 보드를 한쪽 벽면에 크게 붙였다. 색 테이프를 이용하여 구간을 표시했다. 그리고 김피엠에게는 우리가 일을 더 잘해보려고 이런 보드를 쓰려고 하는 것이니 특별히 신경 쓰지 말아달라고 부탁했다. 김피엠이 누구를 억압하거나 강요하는 스타일은 아니었지만 최대한 팀이 자발적으로 선택하여 적용한다는 느낌을 주고 싶었다. 일단 보드를 붙이는 것만으로도 김피엠과 고객은 좋아했다. 전시효과가 있었다. 이 보드는 정적인 유지보수 조직에 무엇인가 돌아가고 있다는 모습을 효과적으로 보여줄 수 있었다.

코르크 보드에 유지보수 팀원의 이름을 각각 넣고, 한 명 당 5개의 슬롯을 주었다. 그리고, 고객의 요구사항이 시스템으로 들어오면 포스트 잇에 해당 요구사항의 내용과 번호를 간단히 적고 백로그 부분에 올려 놓았다.

그리고, 개인당 가진 슬롯의 개수까지만 포스트잇으로 적힌 일을 가져가고, 이것이 넘치는 경우, 다른 사람이 자신의 업무가 아니더라도 도울 수 있도록 했다. 모든 사람의 슬롯이 다 찬 경우에는 김피엠에게 현재 프로젝트가 감당 할 수 없는 정도의 일이 들어오고 있다고 이야기 했다. 김피엠은 이 상황에 대해 매우 현실적인 의사 결정들을 했다. “8시까지 근무하자. 대신에 저녁밥은 프로젝트가 펑크가 나더라도 내가 책임진다”. 또는 고객에게 가서 “우리 정말 너무 힘들다. (칸반 보드를 보여주며) 저거 봐라 애들 죽는다. 웬만한 요구사항은 우리에게 넘기지 말고 너희가 좀 알아서 처리해줘라” 라는 식으로 프로젝트의 일을 줄이기 위해 노력했다.

한 달 정도 이 보드를 사용한 후, 일상적으로 아침마다 커피를 함께 마시는 자리에서 팀 내 누군가가 테스트를 너무 개인의 역량에 의존하는 것 같다는 이야기를 꺼냈다. 그들은 즉시 어떻게 하면, 효과적으로 테스트를 할 수 있을까를 이야기했고, 그들 스스로 ‘테스트 매니저’ 라는 역할자를 만들어 냈다. 당시 화요일과 목요일에 정기 분배 작업이 있었는데, 이 전에 분배할 모든 기능에 대해 담당 테스트 매니저가 한 번씩 제 3 자의 눈으로 확인하기로 했다. 매주 돌아가며 ‘테스트 매니저’의 역할을 담당했는데, 이때는 두 개의 슬롯을 줄여 주는 방법으로 테스트로 인한 공수를 분산시켰다.

이후

이런 실험들을 지켜 본 뒤, 당시 피엠은 나에게 관리를 맡기기로 결정한다. 내게는 “애자일을 해보라”라고 이야기 했지만, 주변의 일반적인 시선은 관리를 맡기는 것이었다. 그리고 스크럼을 기반으로 한 여러가지 실험을 할 수 있었다.

당시 프랙티스 하나하나를 실천할 때 정말 많은 고민을 했던 것 같다. 그리고 팀에 맞는 것을 찾아갔다. 사실 처음에는 모든게 엉망 진창이었다. 예를들어 Stand up을 처음 시작했을 때 나 또한 한명씩 가리키며, PL로서 진척을 물었다. 당시 애자일에 대해 보다 깊이 있는 고민을 한 분들이 조언을 해줬고, 그 덕분에 점점 나아지게 만들었다.

지금, 그때로 돌아가 다르게 시도한다고 하면, 좀 더 엔지니어링 측면에서의 공부를 더 많이 했을 것 같다. 당시 내가 운영했던 Cruise Control 자동 디플로이 시스템은 정말 형편없었다. 한번 디플로이 준비하는데 1시간 30분 정도가 걸렸으니 말이다.

Show your support

Clapping shows how much you appreciated Hubert Shin’s story.