팀전배후 새로 맡은 프로젝트중의 하나는 소스 refactoring을 하는 업무가 있었다.
집중도가 많이 필요한 일이었는데, 여러가지 사정과 많은 사람들과의 커뮤니케이션 문제로 내가 예상한것보다 집중도가 많이 떨어졌다.
새로 개발을 한 나의 자식같은 코드를 실서비스에 올리고 오픈한다는 것은 매우 자극적인 일중에 하나이다.
하지만, 남이 만들어둔 코드를 다시 refactoring을 해서 올린다는 것은 밑져야 본전이 장사중에 하나이다.
항상 바라는 것은 아무 문제없이 잘 돌아가길 바랄뿐이지만, 사람이 하는 일이 항상 그렇듯이 기계처럼 정확할 수는 없다. 그래서, 버그가 발생하기 마련인데 그 버그의 양이 최소한으로 하는 것이 아주 중요하다.
오픈후 일주일이 가장 중요한 시점중의 하나이다. 최소 일주일정도는 웬만한 문제점은 다 나오기때문이다.
이번 프로젝트 오픈후 하루하루 나오는 버그들을 보고, 해결을 해나가면서, 내가 너무 도메인 영역을 몰랐다는 생각을 하게 되었다.
일단, refactoring을 하는데 있어서 가장 중요한 것은 domain expert와 유기적인 커뮤니케이션이다. domain expert가 없다면, 내가 하는 시스템을 많이 써봐서 나 자신이 domain expert수준에 이른 다음에 개비를 시작해야 한다.
물론 domai expert없이 작업을 해야하는 후자가 더 risk가 클 것이다. 하지만, 남이 만든 코드를 가지고 다른 패러다임으로 새롭게 재구성을 하는 것 자체가 risk인데, 그 시스템을 정확하게 모르면 risk가 더 커질수밖에 없다.
난 domain expert도 없었고, 충분히 업무분석을 하지 못했고, 시스템을 잘 알지 못했다.
--> 정말 내가 다 잘못한 것들!! 최소한 시스템의 경우의 수만큼은 사용을 해봐야 했다.
정말 high risk를 가지고 작업을 한 것이다. 고통스러운 버그리포트들을 보면서 domain영역에 대해서 이해가 가기 시작했다. 조금 늦었지만, 이런 계기를 바탕으로 성숙할 수 있는게 아닐까 생각한다.
다시 처음 얘기했던 refactoring은 밑져야 본전이라는 얘기를 다시 한번 생각을 해보자.
지금 현재는 버그때문에 여러가지 손해(?)를 보지만, 이 손해에 대한 투자만큼 얻은 것도 많다고 생각이 든다. 물론, 버그들은 최단시간내에 해결이 되어야만 손해를 최소화할수가 있다.
난 refatoring과 QA, 오픈후 버그리포트를 통해서 좀더 빠르게 업무를 이해할수 있게되었다. 이 부분은 장기적으로 생각을 할때 큰 재산이 될것이다. 아마 다음번에 할때는 더 성숙하고 안정적으로 갈수 있는 터전을 마련한 셈이다. refactoring의 시작점인 만큼 앞으로 진행될 여러가지 부분에서 이번에 얻은 도메인 영역의 지식을 바탕으로 더 나은 어플리케이션을 만들수 있다면, 손해보다도 더 많은 이익을 얻을수 있게 될 것이다.
이 버그들을 통해서 내가 느끼는 수모(?)는 앞으로 좀더 정교한 업무를 가능하게 할 것이다.
여러모로 이번 refactoring프로젝트는 나에게 많은 깨달음과 영감, 그 밖의 여러 지식들을 일깨워주는 계기가 되었다. 이런 것이 경험이라는 소중한 배움이다.
