+ 대한민국 IT프로젝트 교훈 보고서를 여는 글
“나는 가끔 인터넷에 올라오는 IT개발자의 열악한 현장 고백에 동감하면서도 2007년은 여유 있게 일하다 보니 열악함을 피부로 체감하지 못하고 있었다.
그러나 얼마전 피부를 뚫고 뼛속 깊숙이 건강과 열정을 해치는 전형적인 대한민국 IT프로젝트를 경험하게 되었다.
경험하면서 예전에도 느꼈지만 훌륭한 개인이나 훌륭한 생각을 가진 회사가 지금의 우리나라 IT프로젝트 환경을 바꾸는 것은 거의 불가능 하다는 것을 다시 한번 절감하게 되었다.
당시 일했던 사람과 회사들도 분리해서 보면 한분 한분 좋은 사람들이고 좋은 회사였다. 그러나 프로젝트 환경을 구성하는 우리나라 고유의 시스템과 문화를 들여다 보면,
갑을병정 하도급, 터무니 없이 짧은 일정, 저 예산 프로젝트, 막무가내 프로젝트 공정 관리 등의 고질적인 문제에 동화되어 열악한 프로젝트 환경을 똑같이 만들어 내고 반복하고 있었다.
나는 지금의 우리나라 IT프로젝트 환경이 나라에서 적극적으로 개선에 나서기 전에는 변화가 거의 불가능 하다고 다시 한번 절감하게 되었다.
그렇다고 여기서 그만 둘 것인가. 나는 배운게 도둑질이라고 먹고 살려면 계속 이 일을 해야 되고, 밥줄을 떠나 여전히 재미있는 IT기술이 나오면 열광하는 천상 프로그래머이다.
나는 열악한 프로젝트 환경에도 살아남기 위해 나름대로 얻었던 교훈을 정리하여 앞으로 다가올 더 큰 고된 프로젝트에서 조금이나마 실수를 반복 안하고 여유를 찾으며 일하고 싶다.
완벽하게 고됨을 없애지는 못해도 최대한 줄일수는 있을 것이다. 그리고 동병상련 고생하는 동료 프로그래머들이 읽고 조금이나마 도움이 된다면 더욱더 좋을 것이다.
프로젝트의 고됨을 없애지는 못해도 줄일수는 있다. 이것이 대한민국 IT프로젝트 교훈 보고서를 통해 이루려는 나의 열망이다.”
(* 저는 약 4년 동안만 프로젝트 경험해 봤기 때문에 10년 이상 경력자가 이 글을 읽기에는 다소 어설퍼 보일 수도 있을 것입니다. 어설프면 어설픈 대로 웃으면서, 동감하면서 읽어주셨으면 좋겠습니다.
– by 산골소년)
1. 갑인 것처럼 행동하라.
사례를 보시면 알겠지만 갑은 을이 알아서 프로젝트를 하게 냅두고 자기들이 해야 될 부분은 신경 쓰지 않는 부분이 있는 것 같습니다.
그러다가 정작 프로젝트 오픈이 다가오면 부랴부랴 왜~ 여기까지 밖에 안됐냐고 을을 탓하기 마련입니다. 그러나 미리 내가 할일을 끝내고 갑이 해줘야지만 처리 가능한 일들을 구두가 아닌 문서로 잘 정리하여 계속 반복 요청하면 갑은 마지못해서라도 일을 해줄 것이고,
끝내 일을 잘 처리 안해주더라도 나중에 문제 터질 때 미안해 할것이며, 을인 우리가 덤태기 쓸 일은 줄어들 것입니다.
(* ‘없을 것 입니다.’가 아닌 ‘줄어들 것입니다.’ 에 주목해 주세요. 그래도 갑은 끝내 자기 잘못을 인정하지 않을 것입니다.)
‘갑인 것처럼 행동하라.’ 는 갑이 을에게 요청하는 것처럼 을이 갑에게 요청할 것은 강하게 요청해야 된다는 교훈 입니다.
2. 갑의 요구사항만이 진실이다.
제가 경험했던 프로젝트는 갑이 프로젝트 오픈 전주까지 거의 신경을 쓰지 않다가 오픈 전주가 되니 번갯불에 콩 구워먹듯 을인 우리를 조여서 성공적으로 오픈(?)하게 했던 경우였습니다.
프로젝트 동안 갑이 너무 바쁘니깐 제가 나름대로 만든 업무를 확인 받을때도 갑이 제대로 확인을 해줄수가 없었습니다.
그래서 제 나름대로 이렇게 하면 되겠지~ 하고 밀어 붙였는데, 이 어림짐작 때문에 막판에 고생하게 되었습니다.
갑이 신경쓰지 않은 것도 문제 였지만 끝까지 확인받고 넘어가지 못한 제 잘못도 있었습니다.
그래서 깨달았습니다. 내가 나름대로 맞다고 정리한 업무는 허상일 뿐이고 오로지 갑의 최종 확인 만이 진실이라는 것 입니다.
무조건 갑의 요구사항만이 진실입니다. 업무 요구사항은 갑의 확실한 정의(Confirm, Fix)가 필요 합니다. 을의 어림짐작은 쓰레기일 뿐입니다.
한가지 덧붙이자면 갑의 말단직원 확인 보다 갑의 책임자 확인이 필수 입니다. 갑의 말단직원의 확인 또한 언제 바뀔지 모릅니다.
3. 버그는 괴물 되기 전 새끼일때 죽여야 한다.
사실 버그는 을인 나만 잡는 것이 아니라 갑도 같이 테스트 하면서 잡아야 하는 것 아닌가요. 프로젝트 오픈 전 주가 되니깐 갑자기 갑의 전 팀원이 달려들어 테스트 하더니 많은 버그 목록들(또는 바뀐 요구사항)을 저한테 보여주며 질책하더군요.
사실 버그는 버그라 아무 말 못했지만 아쉬운 점도 많았습니다.
가장 잘못된 버그는 예상 가능한 버그들도 제대로 테스트 하지 않고 놓친 버그인 것 같습니다. 이리저리 완벽하게 테스트 해서 문제 없었는데 그래도 발생된 버그는 어쩔수 없지만, 잘되겠지~ 하고 대충 넘긴 버그가 있다면 내가 잘못한게 맞다고 생각합니다.
그래서, 나중에 괴물로 성장한 버그 만나지 않으려면 새끼일 때 죽여야 합니다.
4. 오늘 할일을 미루면 결국 철야작업 한다.
철야작업을 하는 이유는 무리한 일정도 있지만, 프로젝트 초반에 여유있게 일 하고 막판에 빡씨게 일하는 분위기와 조금만 힘들면 ‘내일 하지뭐~’ 하는 분위기도 문제인 것 같습니다.
막판에 몰아서 고생하는 것은 하늘이 노래질 정도로 힘듭니다. 시간도 십시일반 나눠서 막판 고생을 줄여야겠습니다.
5. 밤새 고민해도 안되는 일은 아침에 깔끔하게 해결된다.
저는 이번 프로젝트 뿐만 아니라 예전에도 아무리 야근을 해도 해결 안됐던 문제가 다음날 아무렇지도 않게 해결되는 것을 많이 경험한 적이 있었습니다.
야근을 해도 해도 안되는 문제는 우리 프로그래머의 뇌가 더 이상 제대로 움직이기 힘들기 때문인 것 같습니다.
아쉽지만 다음날 맑은 정신으로 출근하면 우리의 뇌는 비상하게 움직여서 문제를 깔끔하게 해결해 줄 것 입니다.
6. 평정심을 잃지 말자. 될 일은 된다.
어딜 가나 배울 점도 있고 배울 사람도 있습니다. 당시 부장은 쓰러지기 직전의 몸상태에다가 프로젝트를 포기해야 되는 최악의 상황에서도 평정심을 잃지 않고 끝까지 문제를 해결하더군요.
그분께 하나 배운게 있다면 아무리 최악의 상황에서도 ‘평정심을 잃지 말라’ 입니다.
제가 특히 부족한 부분 입니다. 최악의 상황에서도 ‘평정심을 잃지 말아야’ 겠습니다.
7. 노가다 문서작업도 써먹을때가 있다.
프로그래머라면, 그리고 특히 남에게 보이기 위한 문서라면 그 문서 작업들을 거의 경멸할 정도로 싫어하기 마련입니다.
그런데 이번 같은 경우는 노가다 화면 캡춰 테스트 케이스가 중대한 버그를 잡는데 공을 세웠습니다.
그래서 아무리 쓸데없는 일도 쓸데없다고 단정을 짓지 말고 뭐든지 조금이나마 도움줄수도 있다~는 자세로 일을 해야겠습니다.
+ 마치며
라는 보안에 대한 격언은 '갑의 요구사항' 이나 '버그 잡기'에도 통했습니다. 이렇게 하면 되겠지~ 했던 안이한 생각들은 막판에 크게 고생하는 낭떠러지 길이었습니다.
그 외 여러가지 교훈을 얻을 수 있었습니다. 고된 경험이었지만 이렇게 정리하여 다음에 실수와 고생을 줄이는 소중한 교훈으로 만든다면, 고생했던 경험이 결국 이득으로 '환골탈태'되어 더 큰 고생을 미리 방지하는 ‘백신’이 되지 않겠습니까.
소중한 '백신' 맞았다고 생각하며 다음 프로젝트를 준비해야 겠습니다.
대한민국 IT 프로젝트의 열악함은 당분간 개선되기 힘들지만 고생을 줄일 수는 있습니다.
대한민국 프로그래머 파이팅 입니다.
“나는 가끔 인터넷에 올라오는 IT개발자의 열악한 현장 고백에 동감하면서도 2007년은 여유 있게 일하다 보니 열악함을 피부로 체감하지 못하고 있었다.
그러나 얼마전 피부를 뚫고 뼛속 깊숙이 건강과 열정을 해치는 전형적인 대한민국 IT프로젝트를 경험하게 되었다.
경험하면서 예전에도 느꼈지만 훌륭한 개인이나 훌륭한 생각을 가진 회사가 지금의 우리나라 IT프로젝트 환경을 바꾸는 것은 거의 불가능 하다는 것을 다시 한번 절감하게 되었다.
당시 일했던 사람과 회사들도 분리해서 보면 한분 한분 좋은 사람들이고 좋은 회사였다. 그러나 프로젝트 환경을 구성하는 우리나라 고유의 시스템과 문화를 들여다 보면,
갑을병정 하도급, 터무니 없이 짧은 일정, 저 예산 프로젝트, 막무가내 프로젝트 공정 관리 등의 고질적인 문제에 동화되어 열악한 프로젝트 환경을 똑같이 만들어 내고 반복하고 있었다.
나는 지금의 우리나라 IT프로젝트 환경이 나라에서 적극적으로 개선에 나서기 전에는 변화가 거의 불가능 하다고 다시 한번 절감하게 되었다.
그렇다고 여기서 그만 둘 것인가. 나는 배운게 도둑질이라고 먹고 살려면 계속 이 일을 해야 되고, 밥줄을 떠나 여전히 재미있는 IT기술이 나오면 열광하는 천상 프로그래머이다.
나는 열악한 프로젝트 환경에도 살아남기 위해 나름대로 얻었던 교훈을 정리하여 앞으로 다가올 더 큰 고된 프로젝트에서 조금이나마 실수를 반복 안하고 여유를 찾으며 일하고 싶다.
완벽하게 고됨을 없애지는 못해도 최대한 줄일수는 있을 것이다. 그리고 동병상련 고생하는 동료 프로그래머들이 읽고 조금이나마 도움이 된다면 더욱더 좋을 것이다.
프로젝트의 고됨을 없애지는 못해도 줄일수는 있다. 이것이 대한민국 IT프로젝트 교훈 보고서를 통해 이루려는 나의 열망이다.”
(* 저는 약 4년 동안만 프로젝트 경험해 봤기 때문에 10년 이상 경력자가 이 글을 읽기에는 다소 어설퍼 보일 수도 있을 것입니다. 어설프면 어설픈 대로 웃으면서, 동감하면서 읽어주셨으면 좋겠습니다.
– by 산골소년)
1. 갑인 것처럼 행동하라.
“프로젝트는 갑을 위한 일이기 때문에 을(나)만 일해서는 되는 일이 없다. 갑이 해줘야 하는 일들이 꽤 많이 있다.
나는 내가 해야될 일을 미리 다 끝내고 ‘갑이 해줘야 하는 일’들을 문서로 정리 하여 빨리 해달라고 자주 요청을 했었다.
그러나 갑이 바빠서 거의 신경을 못쓰다 보니 제때 지원을 못해주었고 그럴 때마다 나는 ‘갑이 해줘야 하는 일’들을 계속 정리하여 해달라고 반복 요청했었다. 그러나 여전히 갑은 지원을 잘 해주지 않았다.
결국 프로젝트 막판에 문제가 터졌는데, 잘 도와주지 않았다는 것을 갑인 자기들도 잘 알기 때문에 크게 뭐라고 하지는 않았다.
대신 고생은 심하게 했다. 그나마 자주 요청을 했기에 이정도지 구두로 굽신거리며 조심스럽게 ‘김대리님 번거로우시겠지만 이것 좀 해주시겠어요~ *^^*’ 라고 저자세로 나갔으면 을인 나만 덤태기 쓸 뻔했다.”
나는 내가 해야될 일을 미리 다 끝내고 ‘갑이 해줘야 하는 일’들을 문서로 정리 하여 빨리 해달라고 자주 요청을 했었다.
그러나 갑이 바빠서 거의 신경을 못쓰다 보니 제때 지원을 못해주었고 그럴 때마다 나는 ‘갑이 해줘야 하는 일’들을 계속 정리하여 해달라고 반복 요청했었다. 그러나 여전히 갑은 지원을 잘 해주지 않았다.
결국 프로젝트 막판에 문제가 터졌는데, 잘 도와주지 않았다는 것을 갑인 자기들도 잘 알기 때문에 크게 뭐라고 하지는 않았다.
대신 고생은 심하게 했다. 그나마 자주 요청을 했기에 이정도지 구두로 굽신거리며 조심스럽게 ‘김대리님 번거로우시겠지만 이것 좀 해주시겠어요~ *^^*’ 라고 저자세로 나갔으면 을인 나만 덤태기 쓸 뻔했다.”
사례를 보시면 알겠지만 갑은 을이 알아서 프로젝트를 하게 냅두고 자기들이 해야 될 부분은 신경 쓰지 않는 부분이 있는 것 같습니다.
그러다가 정작 프로젝트 오픈이 다가오면 부랴부랴 왜~ 여기까지 밖에 안됐냐고 을을 탓하기 마련입니다. 그러나 미리 내가 할일을 끝내고 갑이 해줘야지만 처리 가능한 일들을 구두가 아닌 문서로 잘 정리하여 계속 반복 요청하면 갑은 마지못해서라도 일을 해줄 것이고,
끝내 일을 잘 처리 안해주더라도 나중에 문제 터질 때 미안해 할것이며, 을인 우리가 덤태기 쓸 일은 줄어들 것입니다.
(* ‘없을 것 입니다.’가 아닌 ‘줄어들 것입니다.’ 에 주목해 주세요. 그래도 갑은 끝내 자기 잘못을 인정하지 않을 것입니다.)
‘갑인 것처럼 행동하라.’ 는 갑이 을에게 요청하는 것처럼 을이 갑에게 요청할 것은 강하게 요청해야 된다는 교훈 입니다.
2. 갑의 요구사항만이 진실이다.
“오픈 전주까지도 말단 실무 담당자 조차도, 아무도 신경쓰지 않았던 갑은 프로젝트 오픈이 코앞에 닥쳐오자 갑자기 높으신 차장님부터 깐깐한 과장님 등의 갑이 갑자기 신경을 곤두세우며 내가 했던 프로젝트를 검사하기 시작했다.
내가 '이렇게 하면 되겠지~' 했던 업무는 갑의 바뀐 요구사항 앞에서 무효였다. 쉽게 만든 업무나 어렵게 만든 업무나 내가 어림 짐작 했던 업무는 닥쳐올 바뀐 요구사항 앞에서 무효였다. 바뀐 요구사항은 시간과도 같았다. 무수한 요구사항들이 대열을 지어 다가오고 있었지만, 지나간 모든 어림짐작 업무들은 단절되어 있었다. 밤을 새더라도, 갑의 바뀐 요구사항은 해결해야 했다.”
내가 '이렇게 하면 되겠지~' 했던 업무는 갑의 바뀐 요구사항 앞에서 무효였다. 쉽게 만든 업무나 어렵게 만든 업무나 내가 어림 짐작 했던 업무는 닥쳐올 바뀐 요구사항 앞에서 무효였다. 바뀐 요구사항은 시간과도 같았다. 무수한 요구사항들이 대열을 지어 다가오고 있었지만, 지나간 모든 어림짐작 업무들은 단절되어 있었다. 밤을 새더라도, 갑의 바뀐 요구사항은 해결해야 했다.”
제가 경험했던 프로젝트는 갑이 프로젝트 오픈 전주까지 거의 신경을 쓰지 않다가 오픈 전주가 되니 번갯불에 콩 구워먹듯 을인 우리를 조여서 성공적으로 오픈(?)하게 했던 경우였습니다.
프로젝트 동안 갑이 너무 바쁘니깐 제가 나름대로 만든 업무를 확인 받을때도 갑이 제대로 확인을 해줄수가 없었습니다.
그래서 제 나름대로 이렇게 하면 되겠지~ 하고 밀어 붙였는데, 이 어림짐작 때문에 막판에 고생하게 되었습니다.
갑이 신경쓰지 않은 것도 문제 였지만 끝까지 확인받고 넘어가지 못한 제 잘못도 있었습니다.
그래서 깨달았습니다. 내가 나름대로 맞다고 정리한 업무는 허상일 뿐이고 오로지 갑의 최종 확인 만이 진실이라는 것 입니다.
무조건 갑의 요구사항만이 진실입니다. 업무 요구사항은 갑의 확실한 정의(Confirm, Fix)가 필요 합니다. 을의 어림짐작은 쓰레기일 뿐입니다.
한가지 덧붙이자면 갑의 말단직원 확인 보다 갑의 책임자 확인이 필수 입니다. 갑의 말단직원의 확인 또한 언제 바뀔지 모릅니다.
3. 버그는 괴물 되기 전 새끼일때 죽여야 한다.
“프로젝트를 하면서 이렇게 하면 되겠지~ 설마 문제 터지겠어~ 했던 부분들이 있었는데 막판에 여지 없이 문제가 발생하여 지적을 받았다.
사실 내가 버그만 터트리지 않았으면 오히려 내가 갑에게 할말이 많았는데 신경을 미처 못썼던 버그들 때문에 얄미운 갑에게 아무런 대꾸도 할 수 없었다.
개발 당시 신경쓰지 못했던 버그들은 마지막에 괴물이 되어 나를 압박하였고, 나는 괴물들 제거하느라 밤을 새야 했다.
그런데 더욱 더 아쉬웠던 것은 버그만 없었어도 내가 갑에게 할말이 더 많았다는 것이다.”
사실 내가 버그만 터트리지 않았으면 오히려 내가 갑에게 할말이 많았는데 신경을 미처 못썼던 버그들 때문에 얄미운 갑에게 아무런 대꾸도 할 수 없었다.
개발 당시 신경쓰지 못했던 버그들은 마지막에 괴물이 되어 나를 압박하였고, 나는 괴물들 제거하느라 밤을 새야 했다.
그런데 더욱 더 아쉬웠던 것은 버그만 없었어도 내가 갑에게 할말이 더 많았다는 것이다.”
사실 버그는 을인 나만 잡는 것이 아니라 갑도 같이 테스트 하면서 잡아야 하는 것 아닌가요. 프로젝트 오픈 전 주가 되니깐 갑자기 갑의 전 팀원이 달려들어 테스트 하더니 많은 버그 목록들(또는 바뀐 요구사항)을 저한테 보여주며 질책하더군요.
사실 버그는 버그라 아무 말 못했지만 아쉬운 점도 많았습니다.
가장 잘못된 버그는 예상 가능한 버그들도 제대로 테스트 하지 않고 놓친 버그인 것 같습니다. 이리저리 완벽하게 테스트 해서 문제 없었는데 그래도 발생된 버그는 어쩔수 없지만, 잘되겠지~ 하고 대충 넘긴 버그가 있다면 내가 잘못한게 맞다고 생각합니다.
그래서, 나중에 괴물로 성장한 버그 만나지 않으려면 새끼일 때 죽여야 합니다.
4. 오늘 할일을 미루면 결국 철야작업 한다.
“요구사항은 늘어만 가고 일은 뜻대로 진행되지 않고, 일정은 따라잡아야겠기에 일을 하긴 하는데 테스트 서버까지 먹통이 되고 복구될려면 한시간 넘게 걸린다니 속이 터질지경이다. 결국 에라~ 내일하지 뭐~ 하고 퇴근하긴 했지만 이런게 쌓였더니 결국 프로젝트 막판에 철야작업 하게 됐다.”
철야작업을 하는 이유는 무리한 일정도 있지만, 프로젝트 초반에 여유있게 일 하고 막판에 빡씨게 일하는 분위기와 조금만 힘들면 ‘내일 하지뭐~’ 하는 분위기도 문제인 것 같습니다.
막판에 몰아서 고생하는 것은 하늘이 노래질 정도로 힘듭니다. 시간도 십시일반 나눠서 막판 고생을 줄여야겠습니다.
5. 밤새 고민해도 안되는 일은 아침에 깔끔하게 해결된다.
“다음날 금요일 드디어 프로젝트가 끝나는가 싶어서 마음이 편안해졌는데, 에휴~ 발목을 잡은 문제가 터졌다.
그 문제를 해결하기 위해 담당자가 계속 매달렸는데 해결은 안되고 문제는 더욱더 꼬여만 갔다. 결국 결단을 내려서 토요일날 하루 더 나와서 해결하기로 했는데 당시 우리는 고된일 끝내고 주말내내 늘어지게 잘 생각만 해서 실망이 컸다.
아쉬움을 뒤로 하고 토요일날 출근해서 문제해결을 시도했는데 전날 아무리 해도 꼬이기만 했던 문제가 30분만에 해결이 되었다. 그날 우리는 깔끔하게 문제 해결하고 우리는 기분좋게 퇴근 하였다.”
그 문제를 해결하기 위해 담당자가 계속 매달렸는데 해결은 안되고 문제는 더욱더 꼬여만 갔다. 결국 결단을 내려서 토요일날 하루 더 나와서 해결하기로 했는데 당시 우리는 고된일 끝내고 주말내내 늘어지게 잘 생각만 해서 실망이 컸다.
아쉬움을 뒤로 하고 토요일날 출근해서 문제해결을 시도했는데 전날 아무리 해도 꼬이기만 했던 문제가 30분만에 해결이 되었다. 그날 우리는 깔끔하게 문제 해결하고 우리는 기분좋게 퇴근 하였다.”
저는 이번 프로젝트 뿐만 아니라 예전에도 아무리 야근을 해도 해결 안됐던 문제가 다음날 아무렇지도 않게 해결되는 것을 많이 경험한 적이 있었습니다.
야근을 해도 해도 안되는 문제는 우리 프로그래머의 뇌가 더 이상 제대로 움직이기 힘들기 때문인 것 같습니다.
아쉽지만 다음날 맑은 정신으로 출근하면 우리의 뇌는 비상하게 움직여서 문제를 깔끔하게 해결해 줄 것 입니다.
6. 평정심을 잃지 말자. 될 일은 된다.
“새벽에 중대한 버그가 발견 되었다. 나는 외주 직원(사실 을이 아닌 병)이라서 피부로 와 닿지는 않았지만 당시 을인 회사는 프로젝트를 포기 하는 중대한 기로에 놓였다고 한다. 나는 에라 모르겠다 하고 휴게실에서 선 잠을 청했는데 당시 을의 회사 사장과 부장은 한숨을 푹푹 쉬며 프로젝트를 포기할까 말까를 얘기 했었다고 한다.
그런데 당시 부장은 어떻하든 이 문제를 해결할 수 있다며 3일 밤을 새고 4일째 밤을 새는 그 최악의 상황을 무시하고 새벽 내내 매달리더니 동이 틀 무렵 끝내 문제를 해결하였다.
당시 내가 지켜 봤던 부장의 모습은 아무리 급하고 힘든 상황에서도 절대로 평정심을 잃지 않은 사나이였다. 평소 성격 급한 나는 그 모습을 보고 감탄했다.”
그런데 당시 부장은 어떻하든 이 문제를 해결할 수 있다며 3일 밤을 새고 4일째 밤을 새는 그 최악의 상황을 무시하고 새벽 내내 매달리더니 동이 틀 무렵 끝내 문제를 해결하였다.
당시 내가 지켜 봤던 부장의 모습은 아무리 급하고 힘든 상황에서도 절대로 평정심을 잃지 않은 사나이였다. 평소 성격 급한 나는 그 모습을 보고 감탄했다.”
어딜 가나 배울 점도 있고 배울 사람도 있습니다. 당시 부장은 쓰러지기 직전의 몸상태에다가 프로젝트를 포기해야 되는 최악의 상황에서도 평정심을 잃지 않고 끝까지 문제를 해결하더군요.
그분께 하나 배운게 있다면 아무리 최악의 상황에서도 ‘평정심을 잃지 말라’ 입니다.
제가 특히 부족한 부분 입니다. 최악의 상황에서도 ‘평정심을 잃지 말아야’ 겠습니다.
7. 노가다 문서작업도 써먹을때가 있다.
“다음날, 드디어 제때 집에 가나 싶었는데 키작고 깐깐한 갑의 높으신 분이 나타나더니 문서 검열을 했다.
지금 소스를 죽어라 고치는데 정신이 없는데 문서작업을 한게 있을리가 없었다. 높으신 분은 윈도우 비스타부터 윈도우 98까지 테스트 케이스 화면 캡춰 문서를 내일까지 내놓지 않으면 프로젝트를 연기하겠다고 깐깐하게 엄포를 놓았다.
나는 그 사람이 너무 미웠다. 형식만 지나치게 추구하는 전형적인 관료주의자로 보였다.
덕분에 나 뿐만 아니라 을 회사 전체가 매달려 다시 밤새도록 OS별 테스트 케이스 캡춰화면을 노가다 식으로 찍어냈는데, 발견하지 못했던 문제가 터졌다.
우리가 개발한것이 윈도우 98과 Me에서는 작동을 하지 않았던 것이다. 결국 해결 하긴 했는데, 내가 미워했던 깐깐한 높으신 분이 아니면 모르고 지나갔을 문제 였다.
제일 고통스러운 작업인 노가다성 화면 캡춰라도 다 쓸모가 있었던 것이다.”
지금 소스를 죽어라 고치는데 정신이 없는데 문서작업을 한게 있을리가 없었다. 높으신 분은 윈도우 비스타부터 윈도우 98까지 테스트 케이스 화면 캡춰 문서를 내일까지 내놓지 않으면 프로젝트를 연기하겠다고 깐깐하게 엄포를 놓았다.
나는 그 사람이 너무 미웠다. 형식만 지나치게 추구하는 전형적인 관료주의자로 보였다.
덕분에 나 뿐만 아니라 을 회사 전체가 매달려 다시 밤새도록 OS별 테스트 케이스 캡춰화면을 노가다 식으로 찍어냈는데, 발견하지 못했던 문제가 터졌다.
우리가 개발한것이 윈도우 98과 Me에서는 작동을 하지 않았던 것이다. 결국 해결 하긴 했는데, 내가 미워했던 깐깐한 높으신 분이 아니면 모르고 지나갔을 문제 였다.
제일 고통스러운 작업인 노가다성 화면 캡춰라도 다 쓸모가 있었던 것이다.”
프로그래머라면, 그리고 특히 남에게 보이기 위한 문서라면 그 문서 작업들을 거의 경멸할 정도로 싫어하기 마련입니다.
그런데 이번 같은 경우는 노가다 화면 캡춰 테스트 케이스가 중대한 버그를 잡는데 공을 세웠습니다.
그래서 아무리 쓸데없는 일도 쓸데없다고 단정을 짓지 말고 뭐든지 조금이나마 도움줄수도 있다~는 자세로 일을 해야겠습니다.
+ 마치며
“보안은 사슬과 같아서 가장 약한 고리만큼만 안전하다. 공격자가 가장 약한 고리를 찾아 공격하듯이 방어자는 가장 약한 고리부터 보완해야 한다.”
라는 보안에 대한 격언은 '갑의 요구사항' 이나 '버그 잡기'에도 통했습니다. 이렇게 하면 되겠지~ 했던 안이한 생각들은 막판에 크게 고생하는 낭떠러지 길이었습니다.
그 외 여러가지 교훈을 얻을 수 있었습니다. 고된 경험이었지만 이렇게 정리하여 다음에 실수와 고생을 줄이는 소중한 교훈으로 만든다면, 고생했던 경험이 결국 이득으로 '환골탈태'되어 더 큰 고생을 미리 방지하는 ‘백신’이 되지 않겠습니까.
소중한 '백신' 맞았다고 생각하며 다음 프로젝트를 준비해야 겠습니다.
대한민국 IT 프로젝트의 열악함은 당분간 개선되기 힘들지만 고생을 줄일 수는 있습니다.
대한민국 프로그래머 파이팅 입니다.
올블로그 추천은 http://link.allblog.net/7345501/http://mckdh.net/190 입니다.
