[2부 6번 수필 추가] 소프트웨어 유지보수는 해결책이지 골칫거리가 아니다
네, 이미 박재호님께서 짚고 넘어간 글, 또 뒷북입니다. :-)
저자는 유지보수에 인력을 투입하는 방식이 변해야 한다며, 구체적인 해결 방안 네 가지를 제안합니다. 그런데 개인적으로는 그 네 가지도 여전히 조금 추상적이라 여겨집니다. 그래서 오늘은 원론적인 이야기보다 제 경험을 이야기하겠습니다.
제가 처음 일했던 소프트웨어 회사는 거의 천만줄이 되는 소스 코드를 매일 밤마다 빌드할 정도로 소프트웨어 규모가 컸습니다. 몇 백명이나 되는 개발자들이 소프트웨어 하나에 매달려 일했었죠.
첫 서너 달 동안 제가 한 일은 고객이 요청한 버그 수정, 즉 유지보수 작업이었습니다.
먼저 기술 수석이 각자 짠밥에 맞게 버그를 할당합니다. 그럼 할당받은 버그를 들고 가장 먼저 기술 수석을 찾아가죠. 처음에는 문제가 도데체 무슨 말인지부터, 어떻게 재현하는지, 어떻게 디버깅하는지, 어디를 어떻게 고쳐야하는지, 일일이 기술 수석을 찾아가 꼬치꼬치 물어야만 합니다. 하나도 모르니까요. ^^;;
여차저차 코드를 고친 다음에는 기술 수석에게 코드 검토를 받고, 기술 수석이 승인하면, 고친 코드와 관련되는 테스트 케이스를 돌립니다. 여기까지 다 통과하면 소스 코드 관리 시스템에다 넣습니다.
점차 익숙해질수록 할당 받는 버그도 복잡해집니다. 이제는 기술 수석만이 아니라 여기저기 '핵심' 개발자들을 찾아서 회사 안을 헤맵니다. '이 부분은 누구한테 가봐라' 혹은 '지금은 회의있으니까 30분 후에 보자' 이런 소리도 많이 듣죠. 부끄럽다고 대충 넘어가면 문제를 해결 못하니까, 납득할 때까지 캐물어야 합니다. 질문하는 만큼 배우니까요.
그러다보면 점차 다른 개발자를 찾아가는 횟수도, 엉뚱한 개발자를 찾아다니며 헛걸음하는 횟수도, 전혀 상관 없는 질문을 던지는 횟수도, 함께 문제를 의논하는 시간도 줄어듭니다.
반면 혼자서 해결하는 문제 수가 늘어납니다. 전체 아키텍처도 조금씩 머리 속에 들어옵니다. 코드를 열심히 뒤지다 보니 회사에서 사용하는 구현 관례에 익숙해집니다. 생판 처음보는 남의 코드를 빨리 이해하는 눈도 생깁니다. 우리 팀과 관련 있는 '핵심' 개발자들과도 친해집니다. 그렇게 저는 신참 때깔을 조금씩 벗었습니다. 지겨웠다기 보다는 재미나고 신선한 시간이었습니다. :-)
아, 그렇다고 유지보수 업무에서 완전히 손을 떼지는 않습니다. 프로젝트 일정에 따라 수위를 조절할 뿐 유지보수 업무는 개발 업무와 마찬가지로 모든 팀원이 기본적으로 '해야할 일'이었습니다. 신참이었을 때 가장 많은 시간을 투자했죠.
참고로, 회사 내 모든 고참 개발자는 자기 시간에서 10-30%를 멘토링/컨설팅 시간으로 할당했습니다. 전체 아키텍처를 잘 아는 사람일수록 (어쩔 수 없이) 많은 시간을 컨설팅에 쏟았습니다.
신참이 유지보수 업무를 수행할 경우 장점이 많습니다. "신참에게 유지보수 업무를 맡긴다"에서 문제점은 "신참"이 아니라 "맡긴다"에 있다고 생각합니다. 유지보수 업무는 아키텍처를 잘 아는 고참이 "책임"져야 합니다. 신참이 코드를 구현하더라도, 책임자가 전체 아키텍처에 어긋나지 않도록 방향을 잡아주고 코드를 검토해야 합니다. 그러다 보면 고참은 자연히 신참을 이끄는 멘토 역할도 하게 됩니다. 경력 있고 실력 있는 개발자에게 멘토 역할은 참 보람된 일이죠. 경력 있고 실력 있는 개발자로부터 지식과 기술을 전수받는 경험도 참으로 즐겁죠.
유지보수 업무, 어차피 해야할 일이라면 잘 활용해서 여러 마리 토끼를 한꺼번에 잡으면 어떨까요?
"소프트웨어 컨플릭트 2.0: 시대를 뛰어넘는 즐거운 논쟁" 역자 이해영 올림
라벨: 유지보수
