옆 부서는 신입사원이 들어오면 기존 블럭에 대한 F/U을 시키는 것이 아니라 무조건 Test 작업부터 할당한다. 그래서 옆에서 보기에 참 불쌍(?)하다는 생각을 많이 했다.
Test 업무라는 것이 내가 만든 것이 아니라 대부분 남이 만들어 놓은 것을 대상으로 하는 지라 나름 부품 꿈을 안고 “개발자”의 길을 선택했는데 그것과는 사뭇 다른 일을 하고 있으니 어찌 흥이 나겠는가?
얼추 보면 최소 6개월에서 1년동안 이런 일을 한다.(리더가 특별히 계획을 가지고 이렇게 진행하는 것인지는 모르겠다. 아무래도 그 분이 그럴 것같지는 않고)
개인적으로 이렇게 하는 것에 그리 공감하는 편이 아니었는데 이번에 출장와서 겪은 일을 계기로 다른 생각이 들었다. 바로 “역지사지”, “사용자 입장에서 바라보기”가 그것이다.
많은 실은 대부분의 개발자들은 코딩을 할때 자신의 관점에서 작업한다. 자신의 관점이라 하면 어떤 방법을 사용하던 자신에게 주어진 요구사항에 맞게 프로그램이 동작하게 만드는 것이다. That’s it.
당연히 코딩하고, 시험하면서 필요한 부분을 확인하기 위해 로그 메시지도 출력하고, 상태 확인을 위한 디버깅 기능도 추가한다. 하지만 이런 것은 거의 100%가 자신을 기준으로 한 것이다. 즉 누구보다 해당 블럭을 잘 알고 있다는 것을 바틍으로 로그나 디버깅 기능을 추가하는 것이다.
그런데 정말 로그나 디버깅은 개발자 자신만 사용하는 것일까? 만일 그 사람이 다른 업무를 맡게 되었다면? 만일 퇴사했다면? 갑자기 동작에 문제가 있는데 연락이 안된다면? 담당자가 있는 곳이랑 전혀 반대의 시간대에서 문제가 발생했다면?
결코 로그나 디버깅 기능은 개발자를 위한 기능이 아니다. 개발자(담당자) 자신을 포함한 많은 사용자를 위한 기능이다.
그렇다면 어떻게 해야 할까?
쉽고 직관적이어야 한다.
당연한 이야기다. (대부분의 경우) 쓸데없는 소스 파일 이름, 함수 이름, 라인수를 찍어 로그를 지저분하게 하지 말고, 단순하게 error 문이나 Return -1 같은 거의 무의미한 내용을 출력하지 말고, 16진수를 0x도 없이 찍지 말고, 16진수를 10진수로 출력하지 말고, 디코딩이 필요한 값을 단순하게 숫자로 찍어서는 안된다.
한가지 정보를 얻기 위해 사용자가 몇 번의 명령어를 입력하게 해서는 안된다. 개발/시험 중에는 고작해야 1-2군데에서 그 명령어를 치겠지만 현장에서는 단위가 달라진다. 몇 십번에서 몇 백번 똑같은 명령을 입력하는 경우도 있다. 이런 어처구니 없는 불편함은 누구 잘못이겠는가? 모든 것이 자신을 기준으로 자신만을 생각하고, 사용자를 생각하지 않는 개발자 잘못이다.
그럼 처음에 왜 신입사원에게 Test 업무부터 시키는 것에 대한 생각이 바뀌었는지 답이 나온다. 바로 다른 사람이 만들어 놓은 불편한 로그/디버깅 기능을 체험하라는 것이다. 내가 다른 사람이 만들어 놓은 지저분한 로그를 분석할 때도 있고, 불편한 디버깅 기능을 이용해 봐야 정말 다른 사용자의 심정을 조금이라도 이해할 것이라고 생각하기 때문이다.
정말 부서내에 게시판을 하나 만들어놓고 다른 사람의 로그나 디버깅 기능을 이용하면서 느낀 불편한 점을 공유했으면 좋겠다. 모든 불편한 점을 해결할 수는 없을 테니 주기적으로 게시판에 올라온 것중에서 꼭 필요한 부분을 골라 activity로 잡아 개선하는 작업이 있으면 좋겠다.
그리고 시험 인력은 로그가 부정확하거나 불편한 점 역시 개선요구사항을 개발팀에 feedback을 줄 수 있는 분위기/체계가 있었으면 한다. 제대로 기능 동작은 기본이 아닌가? 단지 제대로 동작하는 것 그 이상을 목표로 삼아야 한다.
많은 경우 제대로 되지 않는 management나 process를 욕하는 경우가 많다. 하지만 시간이 가면 갈수록 결국 문제점은 개발자의 태도라는 생각이 든다. 개발자의 능력이 아니라 태도.
꼬랑지) 그래서 읽고 싶은 책. “소프트웨어, 누가 이렇게 개떡같이 만든거야” 중 (via Inuit Blogged)
geek들의 지적 만족을 위한 프로그램이 아니라 제품으로서의 소프트웨어를 만들어야 합니다
지난 주에 몇 달 만의 주말 근무를 하게 만든 문제점을 드디어 해결했다.
금요일 8시간, 토요일 9시간. 그리고 오늘 1시간. 총 18시간을 투입했는데 결국은 해결한 것이다.
현상적으로는 내가 짠 코드가 의심받을 만하지만 아무리 생각해도 문제가 없어 보이고, 여러가지 시험 결과가 서로 다른 결과를 보여서 하나의 일관된 원인/이유를 찾지 못했다. House 말대로 모든 증상에는 이유가 있을 텐데 그걸 찾지 못하고 있었던 것이다.
그래서 문제 해결을 위해 brainstorming을 많이 활용했다. 하우스에서처럼 화이트보드를 두고 이런 저런 이야기를 한 것은 아니지만 이 문제에 관심을 보일만한 사람들과 대화를 많이 했다.
덕분에 내가 생각하지 못했던 그 “something missed”와 관련된 하나의 사실을 후배 녀석이 발견했고, 그걸 기반으로 문제의 원인이 될 만한 결정적인 내용을 파악했다. 그리고 그 사실이 문제의 원인일 때 발생할 수 있는 예상 결과와 그 문제를 해결하였을 때의 예상 결과를 도출하고 실제로 적용해 보았다.
결과는 한 방에 해결.
정말 주말 내내 날 우울하게 만들었던 문제를 명쾌하게(?) 해결해 버린 거다. 물론 아직 확인할 것은 한 가지 남았지만 그래도 어떤 설정이 이런 문제 결과를 만들어 냈는지를남들이 모두 납득할 수 있게 설명할 수 있게 된 것이다.
문제를 해결하는 순간 정말 어찌나 기쁘고 허탈하던지.
사뭇 심각한 문제여서 평소에 대면할 필요도 없는 다른 부서 부장님도 전화해서 상황을 묻곤 하셨는데 다행히 비교적 짧은 시간내에 해결해냈다.
그 동안 미드 하우스를 자막으로 보는 탓에 영어 공부는 안되었지만 그래도 닥터 하우스가 질병의 원인을 찾고 치료하는 과정을 비슷하게 따라하려고 노력한 결과 좋은 결과를 얻었다. 여기서 내가 배운 점은
문제에 관련있거나 관심 있어 할 만한 사람들과 많은 대화를 하자.
재미 삼아 본 드라마가 엉뚱하게나마 도움이 되서 기쁘다^^
꼬랑지) 문제 해결했더니 무척 허기 진다. 일찍 퇴근해야겠당.
회사에서 일을 하다보면 “일”에 전혀 뜻이 없어 보이는 친구들이 종종 보인다.
멋모르는 신입사원도 아닌 나름 3년 이상(혹은 10년 가까이 된 친구)들인데 아무런 생각이 없어 보인다.
해야 할 일이 있음에도 불구하고, 시간만 나면 인터네 쇼핑이나 하려고 들고, 삼삼오오 모여 농담따먹기나 하려고 한다.
일을 하다 보면 휴식이 필요하기 때문이라고 생각할 수도 있겠지만 회사에서 8시간 일하면서 그 중 60-70% 이상을 노는데 보내는 것을 어떻게 이해할 수 있을까?
몇 년 전에 한참 벤처 붐이 일 때 상무님이 하신 말씀이 생각난다. 미국에서도 실력이 뛰어난 사람들은 대기업보다는 벤처쪽으로 많이 가고, 보통 사람들이 주로 대기업에 간다고.
그렇다면 기업에서는 그런 보통 사람들을 어떻게 해야 좋은 일꾼으로 만들 수 있을까? 우리가 하고 있는 일을 함께 고민하고, 스스로 공부하고, 자신이 터득한 지식을 남에게 공유하고, 끊임없이 코드를 확인하고, 기능/구조를 개선하는 사람으로 어떻게 하면 만들 수 있을까?
“개발”업무를 재밌다고 생각하지 않는 듯한 개발자를 어떻게 하면 좋을까? 과연 그런 ‘개발자’에게 개발 업무를 주는 것이 맞는 일일까? 그런 ‘개발자’에게 블럭에 대한 책임을 맡기는 것이 맞는 일일까?
고민이다. 옆에서 보고 있기에 너무 답답하다. 스스로 무언가를 하기 보다는 반드시 시켜야 하고, 그리고 시킨 일만 하는 사람들.
그들을 어떻게 하면 능동적인 사람으로 만들 수 있을까? 아니 능동적인 사람이 되길 기대하는 게 맞는 것일까? 다른 회사/조직은 어떻게 이런 문제를 풀었을까?
특별한 것은 아니고 회사에서 일하는 인도친구들이 expect를 사용해서 개발 서버에서 여러 호스트를 거쳐 타켓 보드에 이미지를 보내는 것을 보고 부러워하다 Python의 pexpect를 알게되어 비슷한 동작을 하는 프로그램을 만들었다.
파일을 보내는 것은 아니고(요건 따로 만들어 놓고) 로그인만 하도록 만들어 놨었는데 어떤 기능을 추가하다가 기존 동작도 안하도록 수정을 해버렸다.
고쳐야지 하면서 생각만 하다가 피일차일 미루고만 있었는데 알라딘 아저씨가 비슷한 이야기를 하면서 프로그램이 있냐고 하길로 제약 사항을 알려주고 소스 코드를 넘겨줬다.
그러더니 뚝딱 뚝닥 하더니 버그를 고쳐왔다.(코드가 워낙 간단해서 특별히 이해하는데 어려움은 없었고, 다만 실행 환경에 따라 다를 수 있는 부분에 대한 처리가 필요했다)
잘 동작한다. 와서 고친 부분을 설명해 줘서 듣고 나니 아이디어가 생각났다. 같이 이야기하면서 바로 고쳤다. 다시 소스 동기화.
알라딘 아저씨 자리에 가더니 아이디어가 생각이 났는 지 뭔가를 또 고쳤단다. 쓸만한 기능이 추가되었다. 그러면서 이런 이런 기능이 있으면 좋겠다고 한다.
마침 해당 기능을 쉽게 구현하는 코드를 본적이 있어 바로 방법을 이야기 하고 뚝딱 뚝딱 해서 코드를 고쳤다.
XP(Extreme Programming)에서 말하는 Pair Programming은 아니지만 같은 블럭을(기능을) 함께 고민하고, 함께 코딩하는 경험은 색달랐다. 서로가 가지고 있는 아이디어를 내놓고, 최적의 구현 방법을 논의하다 보니 코딩도 재밌지만 빠른 시간내에 쓸만한 프로그램을 만들 수 있었다.
이것이 진정한 Pair Programming의 장점이 아닐까?
작년 말부터 회사에 wiki 를 사용하기 시작했다.
처음에는 mediawiki 를 사용하다 기능이 많아서 인지 몰라도 불필요하게 복잡한 듯 보여 다른 wiki를 찾다가 dokuwiki 를 만났다. 예전에 일롭자 님이 쓰던 위키로만 알고 있었는데 의외로 훌륭했다. 게다가 언제 자료인지 모르겠지만 위키중에 가장 평이 좋은 것이 dokuwiki라는.
mediawiki는 wikipedia 가 사용하는 덕에 사용자층이 무척 넓다. 덕분에 다양한 부가 기능이 장점이다. 하지만 편집 기능이 내겐 불편했고, DB를 사용한다는 점이 오히려 부담스럽다.
dokuwiki는 별도의 DB를 사용하지 않고 파일시스템을 사용한다. 덕분에 백업이 무척 용이하고 migration도 편리한 편이다.(물론 내가 MySql를 잘 다룰 줄 안다면 mediawiki도 괜찮겠지만)
암튼 설치도 쉽고 사용도 쉬운 dokuwiki를 내가 관리하고 있는 개발 서버(라고 해봐야 펜4에 리눅스 설치한 것이 전부)에 설치하고 혼자서 열심히 사용하고 있었다. 위키가 위키다워야 하는데 혼자서만 쓰니 아쉽기는 했지만 주변에 위키를 쓸만한(?) 사람이 보이질 않아 애써 권장하지 않았다.
그러다 productivity에 대해 고민하게 되고 특히나 release it, the practice of agile development등의 책을 보면서 개발 팀에 wiki가 아주 적합한 툴임을 다시 생각하고 주변사람들에게 조금씩 소개하기 시작했다.
10명쯤에게 소개했더니 2-3명이 관심을 갖기 시작했다. 하지만 실제로 사용하는 사람은 1명.
그러다 내가 맡은 일때문에 정보 공유를 해야 할 때 자료를 위키에 정리한 후에 메일에 URL을 알려줬다. 물론 그래도 별 반응은 없었다. 그러다 오늘 파트장이 저녁먹으로 가기전에
“위키 그거 괜찮던데~”
라고 한 마디 하셨다. ㅎㅎ
마치 신입사원이 자신의 성과를 인정받은 것처럼 속으로 좋아라 했다. 내가 하는 일을 인정받았다는 게 중요한 게 아니라 파트장이 위키라는 툴을 이용한 자료 정리의 장점을 인지하고 인정했다는 점이 중요했다.
지금도 여전히 혼자서만 자료를 올리고 있는 위키지만 조금씩 나아질 것이라고 믿는다. 그렇게 함으로써 서로가 가진 정보를조금씩 공유해야지만 현재 우리 부서에 팽배해있는 부서이기주의(내가 하는 일만 관심있어 하기)를 조금이라고 완화시키고 각자가 머리속에만 가지고 있는 노하우를 모을 수 있을 것이다.
That’s the POWER of wiki.
Collaboration is a structured, recursive process where two or more people work together toward a common goal—typically an intellectual endeavor[1] [2] that is creative in nature[3]—by sharing knowledge, learning and building consensus. Collaboration does not require leadership and can even bring better results through decentralization and egalitarianism.[4] In particular, teams that work collaboratively can obtain greater resources, recognition and reward when facing competition for finite resources.[5]
http://en.wikipedia.org/wiki/Collaboration
Though good collaboration doesn’t guarantee a project’s success, poor collaboration almost always guarantees a project’s failure.