자주 통합하고 커밋 알림을 사용하세요

로그 달기

예전에 소스세이프와 서브버전의 차이에 대해서 글을 쓴 적이 있습니다. 로그를 읽어야 쓰기도 한다는 얘기였지요. 이것은 도구의 차이라기보다는 문화의 차이입니다. 그리고 도구가 문화의 필요조건이 되기도 합니다.

로그를 쓰는 이유는 두 가지가 있습니다. 하나는 내가 읽기 위해 쓰는 것이고, 나머지 하나는 다른 사람을 위해 쓰는 것입니다. 내가 쓴 로그를 읽는 것은 어떤 경우가 있을까요? 어떤 코드가 왜 들어갔는지 기억이 안 날 때, 특정한 시점의 작업 내역을 되돌릴 필요가 있을 때, 특정한 시점으로 돌아갈 필요가 있을 때 등이 있겠지요.

그럼 다른 사람을 위해 쓰는 경우는 어떨까요?  다른 사람을 위해 쓴다는 것은 반대로 말하면 다른 사람이 쓴 로그를 내가 읽는다는 것입니다. 일반적으로 협업의 경우겠습니다. 개발자들이 멀리 떨어져 있는 일이 많은 오픈소스 개발에서는 로그 없이는 기본적으로 일이 안 됩니다. 누군가 로그를 달지 않으면 내가 힘드니까 나부터 달게 되는 거지요. 하지만 현업에서는 오히려 로그를 달지 않는 일이 비일비재합니다. 그냥 말로 하면 되기 때문이죠. 정책적으로 다중 체크아웃을 꺼놓고 소스세이프를 사용하면 개발자간의 지속적인 대화 없이는 업무가 불가능합니다. 누군가 파일을 잠궈버리면 아무도 일을 못하니까요. 내가 작업하려는 파일이 잠겨 있으면 잠근 사람에게 요청합니다. 얼른 풀어달라고요. 그 사람이 그저 올리는 것만 잊은 상태라면 즉시 올려줄 겁니다. 그러나 그 파일을 고치는 중이었으면 다급해집니다. 잠시만요, 금방 올릴게요! 급하게 작업을 마무리하고 잠금을 풀어줍니다. 뭐가 빠졌죠? 로그를 달지 않았네요!  그치만 적으면 뭐해요? 아무도 읽질 않는데. 그냥 물어보면 돼죠. 로그를 보는 것이 불편하기 때문에 적을 생각도 들지 않습니다.

버전 컨트롤 시스템을 서브버전으로 바꾼다면 사정이 좀 나아질까요? 별로 그런 것 같지도 않습니다. 어쨌든 로그를 읽을 일이 없잖아요.

자주 통합하기

저는 자주 통합하는 것을 지향하는 파(^^)지만, 현업에서도 통합의 시점에 대한 스펙트럼은 굉장히 넓습니다. 제가 생각하는 자주는 일일 평균 3~5회입니다. 일정 시간마다 하는 것은 아니고 작은 단위로 나눈 일이 끝날 때마다 통합하는 것을 기준으로 하고 있습니다. 적어도 작동하는 상태에서 통합해야하는 것은 당연하지요. 개발자가 여럿이다보면 업무 진도에는 편차가 있기 마련이고, 따라서 평균 1~6회 정도면 적당하다고 봅니다.

반면에 기능이 완성되지 않으면 열흘이고 보름이고 통합을 하지 않는 개발자도 있습니다. 여기에는 어떤 문제가 있을까요? 통합이 늦으면 늦을 수록 통합 비용과 리스크가 상승합니다. 서로 연결되어야 할 모듈을 각기 다른 철학으로 만들거나, 기획을 제대로 이해하지 못해 기능을 잘못 구현하는 등의 문제는 언제든지 발생할 수 있습니다. 문제를 늦게 발견하니 위험이 커지는 것은 당연합니다. 그럼 왜 자주 통합하지 않나요?  저는 이 역시 문화적인 문제라고 봅니다. 아직도 버전 컨트롤 시스템을 쓰지 않고 WinMerge나 WinDiff를 사용하는 팀도 있을 겁니다. (물론 좋은 툴이지요.) 게다가 코드는 FTP나 공유 폴더로 공유하고요. (물론 편하죠.) 이런 환경에서는 잦은 통합 작업이 힘듭니다. 저는 2002년까지도 그런 팀에서 일했습니다. 통합을 늦게 하는 개발자는 아마 최근까지 그런 환경에서 일했을 겁니다. 도구는 쉽게 바꿀 수 있어도 문화의 영향은 쉽게 벗어나기 힘든 법이죠.

자, 만일 여러분이 혼자 일하고 있다고 생각해 보세요. 소스 코드의 주인은 누구인가요? 그리고 그 코드를 빌드하는 주체는 누구인가요? 누구의 코드가 올바른 코드일까요? 사용자의 경험을 제공하는 코드는 결국 누구의 코드일까요? 답을 말씀 드리겠습니다. 답은 물론 여러분과 여러분의 코드죠. 여러분의 하드 디스크 안에 들어 있는 바로 그 코드가 빌드 되어 완성된 모습으로 사용자에게 제공됩니다.

그러면 이번엔 여러분이 혼자 일하긴 하지만 이력 관리를 위해 소스 컨트롤을 사용한다고 생각해보세요. 뭔가 달라지나요? 여럿이 함께 작업한다면 어떤가요? 앞의 질문을 여러분의 팀에 던져보세요. 누구의 코드가 올바른 코드인가요? 여전히 여러분의 코드일까요?

아닙니다. 사용자에게 제공되는 코드는 여러분의 코드가 아니라, 바로 저장소에 있는 코드입니다. 여러분은 그걸 잠시 빌려와서 쓰는 것뿐입니다. 작업하고 있는 동안의 코드는 불안정한 상태입니다. 가능하면 빨리 안정적인 상태로 되돌려 놓아야 합니다. 절대 여러분의 코드가 사용자에게 제공된다고 생각해서는 안 됩니다. 여러분의 컴퓨터에서 프로그램이 잘 빌드 되고 똑바로 실행된다고 해서 최종적인 버전도 반드시 그렇다고 볼 수는 없습니다. 그래서 커밋을 자주 하고 저장소의 코드를 깨뜨리지 않으려고 노력해야 합니다. 저장소 앞에 앉아서 사람들이 소스 코드를 가져가고 돌려놓는 것을 지켜본다고 생각해 보세요. 어떤 부류의 개발자와 일할 때 안심이 되겠어요?

이제 위에서 던져 놓은 질문에 대답하겠습니다. 저장소에 있는 소스 코드가 올바른 코드입니다. 여러분은 저장소의 코드로 결과물을 빌드해야 합니다. 물론 빌드 하는건 더 이상 여러분이 아닐 수도 있죠.

커밋을 자주 하면 문화의 변화가 생깁니다. 커밋을 하기 위해서는 먼저 업데이트를 할 수 밖에 없습니다. (소스세이프에서는 Get Lastest Version이라고 부르는 그것.) 그렇기 때문에 항상 작은 통합을 하게 됩니다. 통합을 하다가 종종 충돌이 나고 빌드가 깨지는 문제가 발생해서 업데이트 하기를 꺼리는 사람도 있습니다. 하지만 반대로 생각을 해 보세요. 그 충돌은 언젠가 나도 날겁니다. 문제가 작을 때 해결하는 게 낫지요. 큰 문제를 잘게 쪼개서 작은 문제가 여러 번 난다면 무슨 이득이 있냐구요? 글쎄요, 이미 작은 문제가  일어났는데 큰 문제가 일어날 때까지 기다릴 수 있을까요?

XP에서는 오히려 커밋을 더 자주하기를 권고합니다. 어떤 문서에서는 15분마다 소스를 동기화(업데이트하고 커밋하는 일련의 작업을 동기화라고 부를 수도 있습니다)하라고 합니다. 이렇게 하는 것에는 부수적인 효과가 있습니다. 개발자마다 각자 작업을 해서 그 결과물을 때때로 저장소에 올려놓는 것이 아니라, 우리가 하나의 소스를 다루고 있다는 생각이 들게 합니다. 일을 하면서 빌드 에러 메시지를 한 번도 보지 않을 수는 없습니다. 마찬가지로 작은 충돌 또한 겨우 그 정도로 여기게 됩니다. 어떤 놈이 잘못된 코드를 확인도 안 하고 저장소에 넣어서 나를 열받게 만드는 게 아니고요.

팀이 소스 저장소에 대해 어떤 어휘를 사용하나요? 주의를 기울여 잘 살펴보세요. 공유폴더 메타포를 사용한다면 이미 위험한 상황입니다. 공유폴더 메타포는 내 하드 디스크에 있는 코드가 진짜고 다른 사람에게 주기 위해 저장소에 올린다는 문화가 만연해 있다는 것을 의미하기 때문입니다.

언제 올려줄거예요?

공유 폴더를 사용하든 버전 컨트롤 시스템을 사용하든 개발자 간에 코드를 공유하는 이상 내가 원하는 코드가 언제 올라오는가를 아는 것이 중요합니다. 예를 들어보죠. 저는 필요한 코드가 올라올 때까지 다른 일을 시작해보려고 합니다. 항상 그럴 수 있는 것은 아니지만 못할 것도 없지요. 마냥 놀면서 기다릴 수는 없잖아요. 그런데 언제까지 그 일을 하고 있으면 될까요? 코드가 올라왔을 때 내가 그 코드를 받을 준비가 되어 있지 않으면 어떻게 할까요? 또, 코드를 올려놓고 알려주지 않거나, 알려주려고 할 때 마침 내가 자리에 없어서 전달되지 않는다면 어떻게 될까요? 어떤 사람이 깨지는 코드를 올렸는데, 그가 퇴근하고 난 뒤에나 그 사실을 알게 된다면요? 하지만 그걸 어쩌겠어요? 이러한 단절은 두 명 이상의 개발자가 작업을 하기 때문에 필연적으로 생기는 걸요. 단지 프로그래머이기 때문이 아니라 혼자서 할 수 없는 모든 분야의 모든 일에서 단절의 문제는 언제나 생깁니다. 역사적으로 한 사람이 모든 일을 다 할 수 없게 된 다음부터 이 모든 문제가 존재하고 있었습니다.

제가 있는 팀은 15분마다 소스 코드를 동기화 하고 있지는 못하지만, 서로의 코드를 그럭저럭 잘 반영하는 편입니다. 서브버전에 소스가 커밋되면 그 내용이 MSN으로 전달됩니다. 그러면 작업자는 내용을 확인하고 필요한 것이면 업데이트를 합니다. 눈에 띄거나 의심스러운 내용이 들어오면 로그를 열어서 변경 내역을 바로 확인하기도 하지요.

서로의 코드가 반영이 잘 안 되는 경우도 있습니다. 릴리즈 막판까지 커밋을 미루었다가 한꺼번에 하는 경우가 그렇습니다. 일을 하면서 그럴 일이 전혀 없을 수는 없습니다. 이 경우에도 업데이트를 자주 한다면 문제를 줄일 수 있습니다. 자주 업데이트 해서 내가 작업하고 있는 내용의 전제가 바뀌지 않았다는 것을 확인해야 합니다. 아무리 일이 다 끝나고 올리고 싶다지만 내가 가정하고 있는 내용이 모두 다 바뀐다면 어떻게 하겠어요? 그걸 커밋할 때 비로소 알았다면 어떻겠어요? 어떻긴요, 저는 일주일간의 작업분을 날린 거지요.

SvnMsnNotifier.png

이 스샷은 파이썬으로 만들어진 msnlib의 msnbot을 조금 수정해서 만든 알리미인데, 만드는 데 들인 공에 비하면 팀에 긍정적인 관점의 변화를 가져오고 있습니다. (치명적인 버그가 있긴 합니다.)

이 글은 스프링노트에서 작성되었습니다.

신고
Trackback 0 Comment 13

prev 1 ··· 8 9 10 11 12 13 14 15 16 ··· 28 next


티스토리 툴바