본문 바로가기

IT . Web

어느 시스템 유지보수팀의 프로젝트 위기극복 이야기~.~



글을 작성하기 앞서
겸손한 개발자가 만든 거만한 소프트웨어
라는 좋은 소재와 내용(추측하건데^^a)의 책을 출간한 인사이트 출판사와 저자 분께 축하와 감사의 말씀을 드립니다.

축하는 그렇다치고 뭘 감사하냐구요?

먼저는 제가 글 읽고 쓰는 것을 참 좋아하는 편인데, 좋은 생각이나 경험이 있어도 그것을 한 권의 책으로 펴낸다는 것이 얼마나 많은 정성과 수고를 필요로 하는지 알기에, 이렇게 읽을꺼리를 제공해 주신데 대해 감사를 드립니다. 물론 드물게(주로 번역서...) 그 정성이 부족해서 2~20% 아쉬운 책들도 있지만, 인사이트의 IT서적이라면 그런 걱정은 하지 않아도 될 것 같습니다.(실용주의 프로그래머 등 좋아하는 책이 많지요.~)

그리고, 게으른 제게 작지만 매력적인 미끼(?)로 이벤트를 제공해주셔서, 키보드에 손을 얹도록, 뭔가에 대해 더 생각하고 나누도록 이끌어 준 부분에서 또한 감사를 느낍니다.

그럼 저는 제목에서 나타나듯이,
하나.  실제 경험이 있다면 그 상황을 설명하고 어떤 방법으로 그 불협화음이나 위기를 극복했는지, 또는 극복하려고 어떤 노력을 하고 있는지, 아니면 어떠한 방법을 썼는데 실패했는지, 같이 함께 공유했으면 하는 사례를 올립니다.
이 주제에 대해 나눠보고자 합니다.




저희는 모 교육서비스를 제공하는 그룹의 모 교육시스템(들)의 유지보수를 담당하는 작은 파트고 인원은 기본적으로 3명이 투입되고 있습니다. 저희에게는 이 일상의 업무가 하나의 프로젝트죠.

먼저 뭔가를 극복해나가고 있다는 말은 위기요소가 있다는 말이겠죠. 먼저 저희 파트의 위기요소를 소개해드리겠습니다.
뭐.. 그렇게 머리를 짜내지 않아도 슬금슬금 떠오릅니다^^a
  1. 기획/운영 파트 동료와의 의사소통 문제(사이가 나쁘진 않으나 서로의 의도와 프로세스를 썩 잘 이해하지 못하는...)
    • 새 얼굴이 와서 업무를 이해하고 적응하는데 평균 2~3개월 소요
    • 정형화되지 않은 업무요청
  2. 매우 다양한 고객사들의 요청(힘이 없어서 과감히 쳐내지 못하는..)
  3. 잦은 인력의 교체(Lee군을 제외한 나머지 2人)
  4. 레거시 시스템의 양과 낮은 완성도
  5. 열악한 개발환경
이 정도가 제가 수 개월 전에 처음 파트에 합류해서 느낀 점들입니다. 저야 더 열악한 곳에서도 견뎌 왔기에 살며시 미소짓긴 했지만, 업무 중에 어려움을 주는 요소들이 썩 달갑지는 않았습니다.

그런데 파트의 퍼스트인 Lee군은 상당히 열정적인 사람이더군요. 저도 업무 프로세스 개선, 다양한 서비스들을 업무에 활용/접목하려고 시도하는 일에 관심이 많은 편인데, 게으르고 이기적이다 보니 제가 좋아하고 열의를 느끼는 일을 할 경우에만 그렇습니다. 사실 저는 말할 수 없는 사정 상 파트에 합류했기에, 파트에 애정이 크지는 않았습니다.

하지만 Lee는 정말 파트를 사랑하는지, 아니면 요즘 대두되는 '생계형 개발자'까지는 아니더라도 가족을 위해 최선을 다해야 했던 건지.. 여러가지를 시도했고, 지금에 와서는 나름대로 많은 개선이 있었던 것 같습니다.(저는 적극적으로 주도하진 않았어도 참여는 적극적으로 해주려고 애썼습니다^^)

제일 큰 문제는 역시 A였는데, 이에 대한 대응으로 Lee는 팀원들만 사용가능하도록 남는 서버에 위키(http://moinmoin.wikiwikiweb.de 활용)를 설치했습니다.

B와 D 때문에 어느 정도 반복적인 요청이 지루해질만큼 날아오는데(처리하다보면 하루가 금새 갑니다), Lee는 요청과 처리에 대한 요약을 위키에 작성하기 시작했습니다.

예)
  • 요청자: 케로로 중사
  • 요청일: 어느 비오는 오후
  • 작성자: Lee
  • 개요: 3월부터 4월까지 '노다메 칸타빌레' 과정을 수강중인 학습자 중 어학과정을 함께 수강중이면서 과제물을 제출하지 않은 사람의 명단 추출을 요청받다.
  • 사용된 쿼리: select * from table...
  • 유의사항: 가랑비에 옷 젖을 수 있음

이렇게 작성되는 문서가 늘어나면서 파트의 퍼포먼스는 꽤 나아질 수 있었습니다. 틈만 나면 데이터를 요청하는 운영파트에서 뭔가 메일이 오면 몇 가지 슬픈 구석이 있을 수 있는데,
  1. 새 얼굴이 요청을 받아서 D로 표현되는 레거시를 잘 몰라서 한참을 헤메이거나
  2. 1의 연장선에서, 새 얼굴이 아니더라도 필요로 하는 컬럼이 요청자, 요청건마다 매번 달라서 운영이 말하는 '신청일'이라는 필드가 도대체 DB의 어느 테이블의 어느 컬럼인지 헤메이거나
  3. 극단적인 경우로서 헤메임의 극치로 잘못된 데이터를 전달해주거나(-_-)
이런 슬픈 상황을 보다 효율적으로 모면할 수 있는 기반이 되어 준 것입니다. 데이터 추출 외에 시스템을 개선하는 부분에 있어서도 미투데이나 미니홈피에서 친구의 근황을 엿볼 수 있듯, 시스템의 변화를 좀 더 인지할 수 있었구요.

요청이 누구에게 전달되는지는 어느 정도 패턴이 있지만 꼭 1:1 매칭되지는 않았기에, 파트 구성원 중 한 명이 처리한 적이 있는 건이라면 다른 구성원도 위키 검색을 통해 유사하거나 중복되는 요청의 처리속도와 정확성을 향상시킬 수 있었습니다.

그래서 저를 비롯한 새 얼굴들이 교육이력(데이터가 여러 테이블에 흩뿌려져 있는)을 옮겨달라는 요청을 처음 받았을 때, 어설프게 처리했다가 운영파트와 옥신각신하며 시간을 낭비하는 슬픔을 겪는 대신 위키에서 Lee에 의해 작성된 문서를 보고 깔끔하게 처리하는 모습을 보일 수 있었던 거죠.

저도 제가 보기에 '아, 이건 정말 쉬크하게 처리한 것 같아!'라고 느낀 건들에 대해서는 함께 작성해주었고 서로가 도움을 주고 받을 수 있었습니다.

그리고 서로 연관성이 있는 B, E에 더 나은 대응을 하기 위해, Lee는 SVN(Subversion)을 설치하고 적극 사용을 추진했습니다. 이 때부터 새 얼굴들이 뭔가를 저지르고 모른 척하고, Lee가 밤을 새는 슬픈 상황을 비롯한 장면들이 나아지곤 했죠. 횟집에서 생선에 칼대는 횟수만큼 시스템을 바꿔대는데, 정말 정신이 없었죠 :(

또 A, B와 관련해서 운영파트의 요청이 다이렉트로 각 구성원에게 전달되다보니 파트 내에서 서로 진행 중인 작업에 대해 인지가 어렵고 혼란이 가중되는 문제가 있었는데, 어느 날 Lee가 운영파트와 협의 하에 모든 요청은 Lee를 거치거나 최소한 참조를 달도록 했습니다.

이렇게 의사소통미로의 교통정리를 하면서, Lee는 새 얼굴들이 벙쪄서 모니터에 빠져 헤메이는 시간을 줄이고 요청마다 적절한 조언을 더하기 시작했습니다. 매우 현명한 판단이었죠. Lee가 직접 처리하지 않더라도, 모든 요청 내용을 살짝 읽고 파악하는 것만으로도 파트 전체의 효율을 높일 수 있었습니다.

지금 생각해보면 위키보다 블로그가 좀 더 좋지 않았을까 싶기도 합니다. 저희가 택한 위키는 심플하고 직관적이지만 편집기능이 다소 부족하고, 블로그처럼 레이블이나 태그를 적용하는 것이 불가능했죠. 하지만 어쨌거나 이런 방식을 시도한 건 참 훌륭했습니다.

글을 작성해놓고 보니 따지고 보면 잘 구성된 팀이라면 당연히 갖추고 있어야 할 기본적인 모습들을 갖춰 나갔을 뿐이라는 생각도 들지만, Lee는 결국 말단 사원임에도 불구하고 지속적으로 고민하고 시도했습니다. 이 점에서 저는 Lee를 인정합니다.

이 와중에 이런저런 시도와 교통정리가 가능했던 것도, 다른 사람들을 존중하면서 의견을 제시할 수 있는 능력과 동료관계의 밑바탕에 개선하고자 하는 의지가 있었기 때문이라고도 생각합니다.

여전히 우리 파트에 들어오는 요청은 적벽대전의 화살 같고 고객들의 콧대는 피노키오 같지만, 그래도 요즘 우리 파트는 야근은 잘 안합니다. 업무시간 내에 열심히 하고 제 때 퇴근하는 편이죠.

무수한 방법론이 있고 프로세스에 대한 정의가 있겠지만, 결국 열쇠는 사람에게 있는 것 같습니다.
구성원들이 서로 건강한 마음가짐과 시각을 가꾸어 나가는 것.
이게 위기를 예방하고 극복하는 기본 아닐까요?

 - 끝, 감사합니다.