Extremely Agile

오늘 이 글을 보다가 든 생각입니다만, 좋은 개발자가 되려면, 아무래도 인간성이 좋아야 할 것 같아요. (사실 이 비슷한 생각을 한 지는 오래 되었습니다.) 왜 이런 말을 하냐 하면, 적어도 국내에서는 다음의 두 가지 가정이 유효하기 때문입니다.

1. 개발자에게 주어지는 환경이 아주 척박하다
2. 혼자서 모든 개발을 다 해내는 것은 어려운 일이다.

우리나라의 SW 개발 환경이 외국에 비해 그다지 좋지 못하다는 이야기는 나온지 꽤 오래된 이야기입니다. 대부분의 개발 프로젝트는 일정 중심적(date-driven)인 프로젝트이고, 개발을 진행하다보면 요구사항(requirements)도 시도 때도 없이 변화합니다. 다른 프로그래머들과 맞춰야 하는 인터페이스는 한두가지가 아니고, 그러다보면 가끔 굉장히 비생산적인 논쟁에 빠지게 되는 일도 허다합니다.

그런데 이런 비-프로그래머 중심적인 환경에서도 빛나는 프로그래머들이 있습니다. Guru는 아닐지라도, 다른 사람의 가치를 내 가치처럼 중요하게 여기고, 내 편의를 위해 다른 사람의 불편함을 강요하지 않으며, 섣불리 다른 사람의 능력을 폄하하지 않는, 그런 프로그래머들 말입니다.

통계적으로 보면 (어디까지나 제 주관적인 통계에 의한 것이긴 합니다만) 그런 프로그래머들일 수록 신기술을 습득하는 데 주저하지 않고, 맘에 들지 않는 기술이라고 해서 자기 잣대로 폄하하지 않으며, 다른 사람들과의 관계를 원만히 이끌어 갑니다. 남들이 귀찮아하는 TDD도 솔선수범하는 경향이 있고, 문제가 생기면 언제나 자기가 맡은 부분을 주저없이 의심하는 자세를 보여주죠.

하지만 개발 환경이 척박해질 수록, 이런 개발자들도 함께 드물어진다는 것은 서글픈 일입니다. 이런 개발자들이 점차로 드물어진다는 것은, 소프트웨어 기술자들을 계속하여 재생산해 낼 책무를 지는 개발집단들이 개발자들에게 바람직한 역할 모델을 보여주지 못한다는 뜻이기도 합니다.

그런 역할 모델을 보여주지 못하는 이유로는 여러가지가 있겠습니다만, 가장 큰 것으로는 "개발 집단의 상당수가 개발 방법론을 잘 모른다"는 것을 꼽을 수 있겠습니다.

startup 회사부터 좀 잘 나가는 회사까지 여러 회사를 접해보았습니다만, 폭포수적인 개발방법론이나마 꾸준히 적용해보려는 의지를 가진 회사도 드물었고, 일의 양을 정확하게 추정해 보려는 시도를 하는 회사는 더더욱 드물었습니다. 잘못된 추정으로 시작하더라도 중간 중간에 그것을 바로잡을 기회는 자주 주어집니다만, 그 기회를 제대로 이용하는 회사도 드물었어요.

보통은 "야근-대책없는 휴식-야근-대책없는 휴식-야근-대책없는 휴식..."을 소프트웨어를 릴리즈하는 그날까지 반복하죠. 회의시간은 보통 "지시사항 전달"로 변질되고, 개발자들은 요구사항을 내놓은 사람들과 대면하고 요구사항을 이해할 기회조차 갖지 못합니다. 결국 잘 만들어놓으면 "그게 아니었어..."가 되니까 다시 야근을 하게 되구요. 이런 상황에서라면 아무리 인간성이 좋은 개발자라도 종국에는 인간성이 더러워지지 않을까요?

소프트웨어 개발도 남과 더불어 하는 일이니까, 결국 사람과의 인간관계가 가장 중요하기 마련인데, 그 관계를 차단한 다음 닭장에 밀어넣어 놓고는 "니가 할 일만 잘 하면 돼!"라고 하는 꼴이죠. 결국은 나중에 가서 "왜 내 말을 제대로 이해하지 못한거야!"라고 할거면서 말이에요. :-P

이런 억지스러운 환경을 개선하려면 어떻게 해야 할까요? 저는 요즘 그 답을 찾기 위해 애쓰는 중입니다.

SW 프로젝트는 일입니다. 모든 일이 다 그렇듯, 시간이 지나면 남은 일의 양은 차츰 감소하게 마련입니다. 하지만 대부분의 SW 프로젝트의 경우, 그렇지 않을 떄도 많습니다. 가장 흔한 것은, 마감 시간에 맞추어 밤을 새우는 일입니다. 일의 총량은 정해져 있을 터인데, 왜 프로젝트가 끝나갈 무렵까지 일의 양은 전혀 줄어들지 않고, 결국에는 철야를 하게 되는 것일까요?

애자일 방법론을 만든 사람들은 이 문제를 깊이 있게 연구했습니다. 그리고 그 결과, 이런 결론을 얻습니다.

일은 빵과 같다. 빵을 먹으면, 빵은 줄어든다. 일도 마찬가지이다. 일을 하면, 남은 일의 크기는 점점 작아진다. 하지만 '내가 먹으려는 이 빵이 정말로 내가 먹고 싶었던 빵인지' 한 입 베어물어 보기 전에는 정확하게 알 수 없는 것과 마찬가지로, 고객에게 소프트웨어를 인도하기 전까지는 누구도 그것이 정말로 고객이 원했던 그것인지 확신할 수가 없다.

고객이 원하지 않는 기능을 구현하게 되면, 그 기능을 구현하는 데 투자했던 시간들이 고스란히 오버헤드가 되고, 결국 고객이 정말로 원하는 기능을 구현하기 위해 프로젝트 후반부에 날밤을 새우게 됩니다. 이런 문제에 대해서는 마이크 콘(Mike Cohn)을 비롯한 여러 사람들이 많은 연구를 했고, 좋은 책도 많이 있습니다. Agile Estimating and Planning은 그 중 하나입니다.

하지만 오늘은 그 보다는 좀 더 개인적인 이야기를 해 볼까 합니다. 개인적인 견지에서 보면, 프로젝트 막바지에 더 바쁜 가장 결정적인 이유는, 프로젝트 중간 중간에 박혀있는 마일스톤 점검 시점에 반드시 해야 할 몇 가지 일들을 하지 않고 넘어갔기 때문입니다.

마일스톤 점검시에, 제가 속한 팀은 주로 그 때 까지 개발한 소프트웨어의 큰 틀이 정상동작하는지를 점검합니다. 속칭 '연동시험'을 하는 것이죠. 이 연동시험은 개발에 참여하는 여러 업체와 개발자들로 하여금 '다른 사람의 관점에서' 시스템을 바라볼 수 있도록 해 주기 때문에 굉장히 중요합니다. 그 과정에서 '개발에는 별로 적합하지 않은' 업체나 개발자가 가려지기도 하죠. ('다른 사람의 입장을 전혀 고려하지 않는 개발자'는 그 한 예가 되겠습니다. 이런 개발자일수록 '개발자의 자질'에 대해 더 많이 이야기하곤 한다는 것은 아이러니 한 일이죠. 좋은 코더가 되는 것도 중요하지만, 사실 더 중요한 것은 존중의 자세입니다.)

그런데 이 마일스톤 점검시에는 보통 자질구레한 사항이나 버그들에 신경을 쓰기 보다는, 서로 다른 사람들이 만든 시스템이 별 탈 없이 연동되어 돌아가는지를 살펴보는데 집중하는 일이 많습니다. 자잘한 문제들은 TO-DO 리스트에 적어놓는 것으로 점검을 마무리 짓곤 하죠.

문제는 그렇게 만들어진 TO-DO 리스트를 나중에는 아무도 거들떠보지 않는다는 사실입니다. 그러다보니, 데드라인이 다가오면 최종 연동시험과 병행해서 '자질구레한' 버그들도 함께 잡아 나가야 하는 일이 벌어지게 되고, 결국은 잠을 줄이게 되는 것이죠.

'엉뚱한 기능'을 구현하는 것도 위험천만한 일이지만, 진짜 '일'을 남겨두는 것도 위험천만하기는 마찬가지라는 거에요. 그런데 이런 실수를 되풀이하게 되는 이유는 대체 뭘까요?

가장 큰 이유는, 그런 '뒷마무리 작업'이 대체로 재미가 없기 때문입니다. 뭔가 그럴듯한 새 기능을 시스템에 추가하는 건 재미있습니다만, 그 부산물들을 치우는 것은 사실 지루한 일이죠. 물론, 그런 뒷마무리 작업을 충실히 할 만큼 넉넉한 시간이 주어지지 않는 경우도 있습니다. 자고 일어나면 세상은 달라져 있고 또 뭔가 새로운 요구사항은 생겨나게 마련이니까요.


PS.

이 글은 새벽 네시쯤 쓴 것 같군요.
저도 날밤을 새고 있었다는 이야기죠. ㅋㄷ



 

사실 개발자로서 '소통'의 문제를 전혀 고민하지 않은 채 독야청청 가끔 책이나 들여다보고 지식의 외연을 넓혀가는 데 지나치게 만족하고 살다 보니, 어느새 세상 돌아가는 꼴을 모르는 우물안 개구리가 되어 있더군요.

그래서 요즘 블로그 질이다 뭐다 해서 나름대로 열심히 하던 와중에.

"에자일 이야기"라는 블로그를 하나 발견했습니다. 알고보니 에자일 이야기의 운영자님은 꽤 유명한 분이더군요. (그런 것도 모르고 살았으니 개발자로서는 지나치게 게을렀던 셈이지요 ㅋㅋ)

그 블로그에 포스팅된 기사를 뒤적거리다보니, "야근 금지"를 모토로 하는 한 회사에 관한 기사가 눈에 들어왔습니다. 알고보니 이 회사도 꽤 유명한 회사더군요 -_-




라고 물으시면 할말없3 ㅜㅜ

야근 금지라... 사실 모든 개발자의 꿈이기도 하죠. 야근 금지는 다른 말로 하면 칼퇴근 정도로 바꿀 수 있겠습니다. 사실 서울에서 직장생활하던 때, 저는 칼퇴근을 해 본 적이 거의 없었습니다. 코딩도 해야하고, 때로는 전화도 받아야 하는 팍팍한 벤처에서 칼퇴근이라는 것은 언감생심 꿈꾸기 민망한 소망이었죠.


저의 경험상, 칼퇴근은 '숙련도가 어느 수준 이상 상승한 프로그래머' 혹은 '요구사항의 변화를 엄격하게 통제할 수 있는 환경에서 근무하는 프로그래머' 또는 '을보다는 갑의 지위에 더 가까운 계약관계를 지속적으로 유지하는 회사에서 근무하는 프로그래머'라야 누릴 수 있는 특권적인 혜택입니다.

숙련도가 어느 정도 상승한 프로그래머는, 자신의 코딩 경험을 라이브러리 화 해 놓을 수 있습니다. 그 축적된 라이브러리를 바탕으로, 프로그래머는 자신의 다음 업무에 드는 코딩 시간을 배로 단축할 수 있습니다. 자, 그러면 이 프로그래머가 하게 되는 업무 영역에 큰 변화가 없다고 가정한다면, 이 프로그래머의 순수 코딩 시간은 맡는 프로젝트가 끝날 때 마다 exponential하게 감소하겠군요 :-P

물론, 그러려면 '업무 영역에 큰 변화가 없다'는 가정이 계속적으로 유지가 되어야 합니다. '업무 영역에 큰 변화가 없는' 환경에서 근무하려면, 회사가 하는 업무 형태에 일관성이 있어야 합니다. 제가 근무했던 한 회사의 업무 영역은 제가 근무하는 1년 동안 두 번 바뀌었습니다. 처음에는 웹 개발이었는데, 나중에는 네트워크 장비 개발로 업무 영역이 바뀌었죠. 게다가 근무하는 동안에 다른 업체의 용역 개발을 수행할 일도 있어서, 업무 영역에 변화가 없을래야 없을 수가 없었습니다. 거기다 개발자로서는 처음 맡아보는 업무들이 태반이었으니... 능력 부족으로 자진 퇴사한 뒤 대전으로 튀었습니다만, 지금도 그 때 좀 더 잘해볼껄 하는 후회가 남습니다. 아무튼 각설하고.

용역을 수행하더라도 그 용역의 범위에 일관성이 있으면 좀 낫습니다만, 없는 경우에는 개발자로서는 난감할 때가 많습니다. 이런 코딩도 해야하고, 저런 코딩도 해야하니까요. (심하면 서버 코딩만 전문으로 하다가 GUI 프로그래밍을 하게 되기도 합니다.) 먹고 살자면 그런 일도 생깁니다. 계약서에 명시된 역할이 '을'에 가까울 수록 이런 일은 더 자주 생깁니다. 대개의 경우 '을'은 '갑'이 요구사항을 아무리 자주 바꾸더라도 어쩔 수 없이 응해야 할 때가 많습니다. 요구사항이 바뀌면 코드를 뒤엎어야 하는 일도 늘어나고, 야근 횟수도 늘어납니다. (물론 그런 것 까지 예측하여 프로그래밍을 할 수 있는 수퍼 코더라면야 문제는 또 다르겠습니다만... ㅎㅎ)

이런 문제들을 해결하고 '칼퇴근 맨'이 되기 위해서는, 스스로 부단한 노력을 거듭해서 '자기 분야에서 숙련도가 어느 수준 이상 상승한 프로그래머'가 되거나, '요구사항의 변화를 엄격하게 통제할 능력이 있는 상사' 밑에서 일하던가, '잘 정리된 솔루션을 가지고 있고, 그런 솔루션에 대한 꾸준한 개발 계획을 가지고 있으며, 미래에 대한 비전도 있는' 회사에서 일하거나, '거의 항상 갑의 위치에서 계약을 하는 회사'에서 일하거나, 이도 저도 안되면 '출중한 개발자 및 컨설팅 그룹'에서 일하거나 해야 합니다.


저는 대전으로 튄 후 5년간 꾸준히 칼퇴근 맨이었습니다. 저의 경우에는 '거의 항상 갑의 위치에서 계약을 하는 회사'에서 일한 탓도 있었고, 스스로 '요구사항의 변화를 칼같이 짜른' 탓도 있었고(그래서 욕도 엄청나게 얻어먹었습니다 ㅎㅎㅎ), 나름대로 5년동안 한 회사에서 굴러먹다 보니 제 분야에서 '숙련도가 어느 수준 이상 상승한' 탓도 있었습니다. 대전이라는 환경이 서울보다는 좀 살기에 널널한 탓도 있었죠. (어떻게 보면 그게 가장 지배적인 요인 같기도 하군요 ㅋㅋ)

앞서도 말했듯, 칼퇴근은 개발자의 꿈입니다만, 그만큼 성취하기 어려운 목표이기도 해요. 그래서 그런지, 야근금지를 모토로 하는 저런 회사가 참으로 신기해보이기도 하고, 대전에서 보낸 지난 5년동안의 시간이 좀 아깝기도 합니다. 서울에서 좀 치열하게 생활했었으면 아마 저런 회사나 개발자 그룹에서 좀 더 큰 꿈을 펼쳐보겠다... 뭐 이런 생각을 가지고 보다 더 열심히 공부를 했었을지도 모르겠다, 그런 생각이 들거든요.

뭐, 모로가도 서울만 가면 된다고, 어찌 어찌 해서 야근 안하는 프로그래머가 되었으니 어떻게든 목표를 달성한 셈이긴 하지만 말입니다.. ㅎㅎㅎㅎㅎ

아무튼, 제 입장에서만 보자면 야근은 안하는 게 낫습니다. 야근을 상습적으로 하게 되면 낮 동안의 업무 효율이 떨어지고, '야근하면 되지...'하는 생각에 심각한 업무를 밤에 미뤄두게 됩니다. 체력도 별로 안좋아지고요. 낮 동안에 가급적 모든 업무를 재빨리 처리하고, 밤에는 차라리 시간날때 운동을 하거나, 공부를 하거나 하는 것이 더 낫습니다.

제가 한동안 애들을 다 재운 밤 열시 이후에 회사에 나와서 야근을 하고 담날 다시 정상근무를 하는 비정상적인 생활을 한 두어달 했던 적이 있는데요 (소스코드를 날려먹는바람에 어쩔수가 없었습니다 ㅎㅎㅎㅎ 거기다 애도 봐야하고 아흑 ㅜㅜ) 일은 성공적으로 마무리했습니다만 그 뒤에 정신상태가 피폐해져서 한 한달가량은 뭘 제대로 할 수가 없더군요. 공부도 손에 안 잡히고...

그렇다면 프로그래머가 추구해야 할 길은 오직 하나로군요.

공부를 열심히 해서 숙련도를 향상시키는 거... -_-;;

사실 그 이외의 문제는 '환경'의 문제이고, '환경'의 문제는 프로그래머 맘대로 콘트롤 할 수 있는 게 아니니까요.