회사에서 여러분은 어떻게 프로젝트를 진행하십니까?

http://www.joelonsoftware.com/articles/fog0000000332.html

도움이 되는 내용일 것이라 생각됩니다.

전역변수를 무자비하게 썼다...

제가 그 코드 보고 있습니다. 열라 짜증납니다 -_-;
하나 고치면 다른데서 문제터지고 또 고치면 또 다른데 문제 터지고 -_-;
팀원 중에 거래처 드나드는 사람이 그거 때문에 욕 무지 먹었죠 -_-;

얘기했더니 다행히 팀장님이 소스 다시 고치라고 하시더군요.

그회사 데미지 왕창 먹을겁니다. 얘기해보고 안되면 걍 나와버리십시오.

의외로 그런 프로그램들이 엄청 많습니다.

모든 프로그래머들이 자료구조나 개발 방법론에 정통해있지도
않을 뿐더러 엄청난 시간의 압박속에서 작업을 하는 경우도
허다하죠. 그런 시간의 압박속에서도 하루 하루 결과를 그게
뭘 뜻하는지도 모르는 사람에게 보여줘야 되구요. 어제하고
비교해서 이만큼 달라졌다고...

이렇게 골치아픈 상황에서는 소스코드가 그런 식으로 흐르기
매우 쉽습니다. 누군가 엄청나게 굳은 의지를 가지고 조율하지
않는다면 말이죠.

하지만 그런 소스를 보고 벌컥 화내면서 고치려고 하지 마세요.
그건 (매우 지저분한 코드가 아니라) 그저 좀 이상한 (좀 좋아질
여지가 다분한) 코딩 스타일이라고 보면 될 것 같네요.
코드를 고칠때마다 이런 생각해보세요.

'회사 전체의 코딩 스타일을 나 혼자 안지키려고 한다.'

그걸 수정하게 되면 그 코드는 오직 님만의 코드가 되는거죠.
회사의 누구도 손을 댈 수 없는...

이렇게 씨스템 자체가 무능력한 곳이라면 저같으면
"이런 구닥다리 같은 환경에서 도저히 일 못하겠습니다" 하고
바로 박차고 나오겠습니다. 회사한번 더럽군요 . . . ㅋ;;

저도 비슷한 상황을 접했었고 나름대로 노력을 기울여 절반의 성공이라 평가할 만한 결과를 얻어낸 경험이 있습니다. 부족하나마 도움이 될 것 같아 잠깐 끄적거려봅니다. 보안상 기술적인 세부사항은 생략하니 이해바랍니다.

작년 이맘 때쯤 지금의 회사로 이직을 했습니다. 잘나가는 회사라서 상당히 기술적인 면에서 기대를 많이 했었는데 정작 입사해서 보니 기술력이 형편 없었죠. 소스 관리, 코드, 프로젝트 관리 등등 보안을 제외하면 정말 엉망이었습니다. 보안도 엉망까진 아니지만 좋게 봐줄 수는 없는 상황이었구요. 그래서 그런 상황을 바꿔보고 싶었습니다. 그러나 당시 전 팀내에서 거의 막내였던 상황, 발언력이 강할 수 없는 상황이었죠. 하지만, 바꿔보기로 결심했고 차근차근 실행에 옮겼습니다.

우선, 입사 후 처음으로 주어진 업무가 꽤 head-bounded job이라서 한 동안은 깊이 생각하지 못했고 그 업무가 해결된 이후부터 며칠 동안 문제점을 파악하는데 힘을 쏟았습니다. 일단 업무 시간엔 주어진 일을 하면서 업무랑 겹치는 부분에 대해서만 생각하고 업무시간이 끝난 후 야근을 하면서 기존 체제 파악도 할 겸 차근차근 생각을 정리해나갔습니다.

스스로 문제점이 어느 정도 파악이 되고 나서 해야할 일은 자신과 비슷한 눈높이로 문제를 바라볼 수 있는 사람을 만드는 것입니다. 내가 문제라고 인식하는 것을 다른 사람도 문제라고 인식하기 시작해야 바꿔나갈 수 있는 것이죠. 팀 분위기 자체는 변화에 대한 거부감이 상당히 컸지만 다행스럽게도 제 사수는 비록 기술적인 뛰어난 편은 아니었지만 상당히 개방적이면서 일에 대한 열정이 있는 사람이었습니다. 그래서 그 때부터 매일 매일 업무를 하면서 제가 파악한 문제점으로 인한 현상이 드러날 때마다 사수에게 그 문제점을 인식시키려 애썼죠. 사실 사수 역시 팀의 문제를 어느 정도는 인식하고 있었고 그 역시 뭔가 개선하려는 의지가 있었기 때문에 제 이야기에 대해 부분부분 다시 반박하는 경우도 상당히 많았긴 해도 저와 상당한 공감대를 형성할 수 있었습니다.

그런 후 대안을 준비하기 시작했습니다. 제가 세운 대안은 세 가지, 소스 관리 체계화, 프레임워크 도입을 통한 안정적이고 효율적인 개발, 빌드 및 배치 과정 자동화였습니다. 소스 관리는 기존의 방식에 문제가 많았지만 기존 방식조차도 처음 도입할 때 팀원의 저항이 많았기 때문에 다시 바꾸자고 할 경우에 더 큰 저항이 예상되었고 프레임워크 도입은 팀장의 경우는 필요하다고 느끼지만 실제로 기술적으로 소화할 사람이 없는 상태였고 역시 기존의 개발 방식과의 차이로 인한 팀원들의 저항이 예상되었습니다. 빌드 및 배치 과정 역시 방식 변화 자체에 대한 거부감이 워낙 큰 상태라 앞의 두 가지에 비하면 덜하지만 꽤나 저항이 예상되는 부분이었구요. 그러나, 사실 세 가지 모두 적용만 한다면 오히려 기존 방식에 비해 개발자들이 훨씬 편리해질 수 있는 방법이었습니다.

자, 이제 내 편이 생겼고, 대안도 어느 정도 마련되었고, 대안 추진시의 저항에 대한 예상도 해보았습니다. 그렇다면 그 저항에 대한 대책을 세울 차례겠죠? 이 대책은 그 사람이 처한 상황에 따라 달라질 수 있을 것입니다. 기술적으로 인정을 받고 있고 결정관까지 있다면 이런 대책은 필요없겠죠. 하지만 전 막내였기 때문에 제 의견이 무언가의 권위나 신뢰를 얻을 수 있는 상황은 아니었습니다. 그래서, 이것저것 자료들을 많이 끌어모았습니다. 당시 XP의 일부 practice를 도입하자고 했었기 때문에 xp의 적용 사례나 연구자료 등을 얻고 XP를 오랫동안 해왔던 룸메이트의 조언도 구했습니다. 그리고, 적용하려는 신기술들에 대한 자료도 좀 모았죠. 사실 적용하려던 기술들이 나온지 2년도 넘은 것들이라 신기술이라 할 만한 것이 아닌 이미 상당히 널리 퍼진 것들임에도 불구하고 워낙 뒤쳐져 있었기 때문에 이런 과정이 필요하다고 생각했죠. 그리고, 대안들을 추진했을 때의 이득에 관해서도 리스트업을 했습니다.

이제 다음 차례는 결정권을 가진 사람과의 미팅입니다. 마침 이건 팀장님의 주최로 기회가 생겼습니다. 예상 외로 팀장님은 문제에 대한 인식이 어느 정도 있었고 변화 의지도 있어 개선 요구 자체는 쉽게 받아들여졌습니다. 그러나, 그 방법들에 대해 세부적으로는 이것저것 이의를 많이 제기했는데 그 때마다 앞서 준비했던 자료들로 디펜스를 할 수 있었고 경우에 따라서는 약간의 거짓말-_-도 섞었죠. 이를테면, XP라든가, 적용하려던 기술 중 일부는 제가 해보지도 않았던 것들이었음에도 마치 이미 많이 해봤고 익숙한 것처럼 설명을 하고 각 기술들에 대해서도 새로운 것인데 불안하지 않냐는 식의 반론을 할 땐 구체적인 자료를 준비하지 않은 것들에 대해서도 마치 여기 말고는 다 이미 쓰고 있는 것들이라는 식으로 얘기를 했었죠. 효과는 상당했습니다-_-

이제 남은 것은 진행입니다. 우선, 기존에 있는 것은 바꾸지 않기로 했습니다. 일단 돌아가고는 있었고, 검증되지 않은 새로운 체제로 갑자기 바꾸는 것은 바람직하지 않죠. 그래서 새로 진행되는 프로젝트부터 차근차근 해나갔습니다. 제가 내세운 대안 중엔 저도 처음 해보는 부분도 좀 있었지만 다행스럽게도 큰 어려움 없이 진행되었고 첫번째 프로젝트에서도 우여곡절 끝에 무사히 적용이 되었죠. 그리고, 그 이후부터는 팀 내의 모든 프로젝트는 새로운 시스템으로 돌아가기 시작했습니다. 그리고 두번째 프로젝트에는 팀원 중 제 선배가 참여했고 세번째에는 새로 입사한 제 동갑내기가 한 명 참여했는데 이 둘 모두 어느 정도 수준에 올라 있어서 새로운 시스템에 쉽게 적응하고 부족한 점을 다듬는데 많은 도움을 주었습니다. 그래서 연말쯤에 어느 정도 자리를 잡았고 팀원 중 40% 정도가 새로운 시스템을 경험하게 되었고 이 중 한 명을 제외한 나머지는 긍정적인 평가를 내려주었고 몇몇은 아주 좋다는 평가를 해주기도 했죠.

이쯤되면 성공이라 할 법도 한데 굳이 절반의 성공이라 평가하는 이유는 그 이후에 일어난 일들 때문입니다. 그 이후 조직 개편이 이어지면서 다른 개발 조직과 통합이 되었고 이 과정에서 새로운 시스템 역시 개편 및 통합 작업에 들어갔고 저 역시 그 중심에 들어가게 되었는데 이 과정에서 기존에 쌓아왔던 것들을 대부분 상실해버리는 불행한 결과가 있었습니다. 당시 전 새로운 시스템이 기존 체제와 공존하는데에도 많은 노력을 기울였고 나름대로 아주 자연스럽게 마이그레이션이 진행되어갔습니다. 그래서 팀원들의 저항도 줄일 수 있었고 큰 문제를 만들지도 않았었죠. 하지만, 개발 조직 통합과 함께 시스템 개편 작업이 지나치게 강하게 드라이브되면서 기존 것들을 강제적으로 검증해보지도 않은 새로운 체제로 다 갈아엎었고 한 번에 다 적용해나갔습니다. 그러다보니 불완전힌 시스템임에도 너무 많은 곳에 연관되기 시작해서 개선 작업을 해나가기가 어려웠고 그런 과정 중에 새로운 시스템에 대한 신뢰가 많이 무너져버렸습니다. 막았어야했지만 중간에 개인적인 사정과 맞물려 막지 못했고 지금 뒤늦게나마 시스템의 구조적 불합리들을 개선하려 노력하고 있지만 첫 단추를 잘못 꿴 대가를 비싸게 치르고 있죠. 그리고 조직 개편 이전엔 팀원들이 조금씩 변화해가고 있었는데 지금은 그런 움직임들이 오히려 팀 차원에서 차단이 되고 있는 상태기도 하구요. 그래서 원래는 이 회사에 오래 다닐 생각이었지만 이제는 마음을 많이 접었습니다.

이런 일련의 과정들을 거치면서 나름대로 준비한 방법이 때로는 성공하고 때로는 실패하는 것을 보아왔고 그러면서 얻은 것은 많은 것 같습니다. 다시 이런 시도를 하게 된다면 좀더 잘할 수 있을 것도 같고요.

변화의 과정을 요약하면 다음과 같습니다.

문제 인식 -> 문제 분석 및 정리 -> 문제 인식의 공유 -> 대안 마련 -> 대안 추진 시 예상되는 반론에 대한 대책 마련 -> 결정권자와의 미팅 -> 진행 시작 -> 기존 체제는 유지하며 두 체제가 조화되도록 새로운 방법 도입 -> 새로운 방법 도입의 성공 사례가 생기면 점차적으로 확대 적용 -> 안정화되면 기존 체제를 새로운 체제로 대체 -> 성공

여기서 제가 볼 때 가장 중요한 과정은 문제 인식의 공유입니다. 이게 얼마나 잘 되느냐 아니냐가 성공 여부를 가름합니다. 또 주의해야할 점은 기존 체제를 무리하게 바꾸지 말고 조화되는 방법을 찾아가야한다는 것입니다. 그게 아니면 업무량도 기하급수적으로 늘 뿐더러 저항이 거세지죠.

또 하나, 간과하지 말아야할 것은 자신의 조직이 바뀔 수 있는 조직인가를 판단하는 일입니다. 얼마전 들은 XP 강연에서는 change your organization or change your organization이라고 하더군요. 바뀌지 않을 것 같은 조직이라는 확신이 들면 주저 없이 회사를 옮기는 것이 좋으리라 생각됩니다.

p.s. 참고로, 사내 문서 관리는 위키가 짱입니다. 위키가 없었다면..으..끔찍하죠-_- 혼자만의 문서 관리에도 위키가 좋습니다. 그리고 사람이 많으면 많을수록 더욱 좋은 게 위키죠.

뭐하러 고칠라고 하시는지.. 그냥 편하게 있으시는게..
전 프로그래머는 아니지만 그냥 있어도 잘 돌아가면 굳이 손 안댑니다. 손 대라고 사정해도 잘 돌아가니까. 개기는게 비일비제인데...

정신 건강을 위해서 적당히 농땡이 부리면서. 일하시는게.. 어떠할지..ㅋㅋ