변경 기록 (Change Set)

가정하기는 싫겠지만, 이상적인 상황을 생각하고 이 글을 읽어주시기 바란다. 현실이 이상적인 상황과 얼마나 차이가 나있는지를 아는 것이 현실에 대한 만족도와 미래지향적인 행동을 하는데 도움이 되기 때문이다. 사족을 더 쓰자면, 어둔밤 풍랑 속에서 나침반과 지도, 그리고 희미한 등대 불과 사투하는 선원/선장을 연상하시라는 것이다.

거창하게 도입을 시작한 이유는, 소스 커밋과 관련되어 한 말씀 드리고자 함이다. 소스가 진화하는 세 가지 경로는 개발하면서 들어오는 코드와 릴리즈 후 버그 픽스, 기능 추가가 일어나는 코드를 통해서 그리고, 그 외에 소소하게 심심풀이로 개발자가 예쁘게 만드는 경우이다. 소스가 과연 진화하는지 퇴화하는지는 모르겠지만, 어떤 경우든 변경이 가해지는 것이며, 초당 몇 컷이 지나가는 영화 처럼 하나하나는 그 이전과 약간의 변경이 들어가는 것으로 볼 수 있다.

과감하게 말하건데, 조각가적인 프로그래머들은 마지막 결과를 중요시하고 방금 집어 넣은 스냅샷에 목숨 걸듯이 코드를 대한다. 하지만, 영화감독같은 프로그래머들은 코드의 변화에 신경을 쓰며, 각 테이크들의 연결이 훨씬 더 중요하게 생각한다.

당신은 혹시 마지막 스냅샷에 열광하여 변화해 온 모든 기록들을 별로 중요하게 생각하지 않은것은 아닌가? 제품을 만들어 내는 코드들은, 각 제품이 변경되는 기록에 대한 처절한 판단 기록을 소홀히 해서는 안된다. 아무리 현실이 급하게 돌아간다할지라도, 당신의 이상적인 코드 변경관리와 현실이 어느 정도 떨어져 있는지 감각을 잃지 마시라. 어느날 바닷가 근처에서 난파된 뱃조각에 몸을 싣고 간신히 탈출한 선원이 되지 마시길 바란다.

P.S. 이런 류의 글을 몇번째 쓰는 것 같은 기분이 든다. 이런 글을 쓸 때는 대개, 팀원 중에 누군가가 커밋을 의미 없이 하는 것 같아서 그런 경우가 많은것 같다. 그러나 이번에는 의미 없이 커밋해서 그렇다기 보다는 변경관리의 미학을 좀더 깊이 알았으면 좋겠다는 생각에서 썼다.