태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.
BLOG main image
Not so Simple World (251)
이생각 저생각 (92)
이클립스 RCP (10)
Books (15)
잊기전에 회고 (7)
Better SW Development (83)
node.js (OctoberSkyJs) (32)
[뭘, 이런걸 다?] (12)
bảng giá máy tính xách tay
bảng giá máy tính xách tay
Beer Brewing Tutorials
Beer Brewing Tutorials
harga alat kesehatan spirometri
harga alat kesehatan spirometri
air max pas cher
air max pas cher
veste parajumpers
veste parajumpers
«   2017/11   »
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
848,169 Visitors up to today!
Today 192 hit, Yesterday 261 hit
rss
tistory 티스토리 가입하기!
Recent Entries
2009.09.19 01:36
예전에 모 사이트에서 일할 때의 이야기.

개발후 테스트 완료된 모듈을 운영 서버에 반영하는데에 종종 문제가 발생했다. (나를 포함해서) 반영작업을 하는 작업자가 때때로 실수를 하는 것이다. 물론 서버 대수가 많고, 시스템이 복잡한 이유이긴 하지만, 그렇다고 그냥 놔둘순 없었다. 관련 팀들이 모여 장시간의 회의를 했다. 상대에 대한 비난은 최대한 접고 우선은 해결책을 모색하기로 했다.

그 결과로 반영 후 작업 상태를 점검 할 수 있도록

1. 작업 체크리스트를 만들었다.


하지만, 그래도 여전히 문제가 발생하곤 했다.
체크 리스테 자체에도 빈틈이 있었고, 밤에 혼자 일하다 보니 체크 리스트 작업을 종종 까먹기도 했다. 그런식으로 장애가 몇 번쯤 반복될 때 즈음. 이대로는 안되겠다는 생각에 다시 대책 회의가 다시 열렸다. '그래! 자신의 일을 자기가 판단 하려니 잘 안보는 거였어! 왜 버그도 남이 보면 쉽게 찾는 경우가 많곤 하잖아?' 라는 의견이 모였다. 그래서 소스 반영작업 전에 당일 수행할 작업에 대한

2. 동료검토(peer-review) 단계를 추가했다.


<예~에! 그래! 니가 이야기 한데로 하면 문제없이 잘 될거야! 이젠 누락따윈 없다구!>

하지만, 그래도 작업 실수로 인한 다양한 문제는 근절되지 않았다. '왜지? 둘이 검토를 하는데도 실수로 누락되는 부분이 왜서 생기는 거지?' 

결국 또 다시 회의를 하였고, 그 결과, 이번엔

3. 체크리스트를 두 번 작성하도록 정했다.


작업 하면서 한 번, 작업 마치고 다시 한 번! 이렇게 두번 체크리스트를 작성하라고 했다. 설마 동료검토에다가 체크리스트를 두 번이나 검토하는데도 서버 작업하는데에 누락이나 실수가 있을 수 있겠냐는 발상이었다.
(뭐, 사실 이쯤 되면 운영 환경에 모듈 반영 작업 하는 일 자체가 본의아니게 운영팀의 초고도 부담백배 핵심업무가 될 수밖에 없다. )

어쨌든, 이렇게라도 해서 우리를 괴롭히던 모듈 반영 오류에 따른 장애 문제가 해결되면 다행이니까 견뎌보기로 한다. 자, 그럼 문제는 해결나? 

No way!! 반영자의 실수로 인한 에러율이 줄긴 했지만 여전히 에러는 발생했다. 이쯤 되면, 고객도 분노하고, 팀장도 분노하고, 동료도 분노한다. 그래서 결단의 수를 쓸 수 밖에 없어졌다.

4. 또 실수하면 패널티를 개인에게 물리겠다
라는 공지가 전달 되었다.
 

<명심하게! 실수하면 이렇게 되는 것도 요원한 일만은 아닐세! >

..
..

그래서, 그 뒤로 반영 실수로 인한 장애가 줄어들고 모두가 더 행복해 졌습니다..???

Masaka! (설마!)

확실히 작업자 실수로 인한 장애가 더 줄긴 했다.

하지만, 이젠 반영작업은 작업자에게 굉.장.한 정신적 프레셔를 주는 일이 되었다. 안그래도 지쳐있는 작업자들에게 피로도와 스트레스가 몇 배가 되버린건 당연! 문제상황은 더 줄어 들었지만, 하루 빨리 여길 뜨던가 딴일을 해야 겠다는 생각이 작업자들 모두의 머리 속에 들수 밖에 없었다.

단 방향식 해결책이란 언제나 이런식이기 쉽다.


예전 CPU 들의 Hz 전쟁같은 식으로 한 방향을 향해서 극도로 쥐어짜내는 형태.
창의성도 결여되고, 품질도 떨어지기 쉽다. 실제로 인텔의 cpu clock 전쟁 마지막 세대인 '프레스캇'은 과도한 클럭 쥐어짜기로 인해 열이 굉장히 심했고, 그 결과 '프레스 핫!' 이라고 까지 불렸었다. (과열로 인한 문제도 적지 않았다)

타개점은 Architecture 변경이었다. 소위 말하는 패러다임쉬프트. 문제상황을 달리보는 관점. 그래서 나온게 Core 아키텍처이고, 그게 발전해서 현재 우리가 쓰는 Core 2 Duo 계열이 되었다. Core2Duo 는 기존 4G에 육박한 CPU 성능을 1G대에서도 가뿐히 넘어서고 있다.

뭐든, 한 방향으로만 가면 상황을 만족시키는 답이 점점 어려워지기 마련이다.

다시 모듈 반영 문제로 돌아가 보자.

차분히 그리고 냉정히 생각해보면 모듈 반영 에러의 근본적인 문제는 '반영 작업 하나 제대로 처리 못하는 바보같은 운영팀 녀석들!' 이 아니라 '사람이 작업한다'는 점이었다.



다시말해서, 좀 더 우와한 해결책은 '정신 똑바로 차린다'가 아니라 일찌감치 '모듈 반영 작업을 최대한 자동화해서 누락과 실수를 제거한다' 였던 것이다.

하지만, 그걸 깨달았을 때에는 이미 우린 일방도로를 너무 많이 지나온 상태였다. 그렇기 때문에, 과거의 우리 자신을 부정하며 새롭게 시작하기 위해 돌아가는건 (여러가지로 이유로) 어렵게 되었다는 것을 알게 되었다. (고객신뢰라던가 팀간 정치, 감정의 골이라던가.. 등등등..)

.
.
.

여러 프로젝트에서 발생하는 문제들이 분석/설계가 제대로 안되어서 그렇다는 말이 많다.

고객의 요구사항을 제대로 파악해 내지 못한다는 거다.

자, A라는 회사의 해결책을 살펴보자.


해결책을 찾기 위해 TFT(Task Force Team)를 구성한다. (전통적인 해결책 모색 시퀀스의 시작점이기도 하다)

요구 사항 파악이 문제란다.

1. 그래서 최대한 고객의 요구사항을 잘 뽑아내기 위해 분석작업에 노력(effort)을 쏟았다. (기간이며 인원이며..)

(분석단계에서) 요구사항 명세서 같은 산출물을 최대한 자세하고 정확하게 만들어 내기 위해 많은 에너지를 써야 했다. 하지만, 그래도 개발이 진척되어 가다보면 이전에 없던 고객의 새로운 요구사항이 자꾸자꾸 나왔다. 안되겠다는 생각이 들었다. 그래서

2. 초반 요구사항을 뽑을때 회의록이나 계약서에 명시해서 고객이 못 바꾸도록 만들었다.
단순하면서도 간단한 해결책인것 같았는데, 고객은 답답해졌다고 느낀다. 나중에 요구사항을 말해도 합의사항에 없어서 못 들어준다고 하니 때때로 짜증도 난다. (그리고, 보통은 고객이 답답하고 짜증나는데 일해주는 사람이 편해지는 경우는 없다)

그래서 고객은 교훈삼아 새롭게 마음을 먹었다. 다음엔 최대한 요구사항을 쉽게 확정 짓지 않겠노라고...

고객은 점점 더 오묘모호하게 요구사항을 이야기 하게 된다. 왜? 너무 자세하고 명확히 말하면 나중에 생각나는 요구사항을 안 들어줄거라고 생각하니까. 또 그로인해 발생하는 문제를 고객 담당자인 본인이 책임을 져야 하니까.

일해주는 우리 입장에서는 고객의 요구사항 파악과 확정이 점점 더 힘들어 지는것 같았다.
뭘까? 어떻게 해야 할까? 우리가 너무 요구사항을 띄엄띄엄 봤어서 그런건가? 라는 자기 반성과 함께 새로운 해법을 찾아낸다.

3. 단순하게 접근해선 요구사항 파악이 안되니 '요구공학'이란걸 만들어서 도입하기로 했다.
공학! 이름만으로도 뭔가 빈틈없고 체계적으로 해결해 줄것만 같은 느낌인거다!

쉽진 않았지만, 관련 전문가들을 부르고 연구하고 정리해서 요구사항을 잘 뽑아내 고객을 꼼짝 못하게 만들 수 있도록 하는 요구공학(Engineering) 이란걸 만든다.

하지만, 그 결과, 교육을 받고 도입된 공학을 적용해도, 요구사항 파악 문제는 좀처럼 잘 해결이 되지가 않았다.

'왜지? 많은 자원과 노력을 기울여 공학까지 만들었는데도 잘 안되는거지?
그래! 요구공학을 적용할 전문 인력이 부족해서 그런건거 같아! 분석 전문가를 다수 양성해야 겠어! 그게 해결책인거야!

.
.
아.. 근데 잠깐? 어째 지금과 비슷한 시퀀스의 경험을 어디선가 했던 것도 같은데... 데.. 데자뷰???'


..
..
.
물론 예로 든 상황이란게 다소 극단적이긴 하지만, 때때로 이런 생각이 들곤 한다. 이런 경우에 있어 혹시

보다 근본적인 문제는 고객의 요구사항이 바뀌는 것이 아니라, 바뀌는 고객의 요구사항을 따라가기 어렵게 만들고 있는 우리의 시스템 구조에 있는 건 아닐까?

좀더 쉽고 유연한 시스템으로 만들었으면, 그래서 고객이 새로운 요구사항을 내었을때에 난감한 표정으로 '바꾸기 어렵다'고 말할 수 밖에 없는 상황이 조금은 더 줄어 들 수 있었던 건 아닐까?

사실, 고객과 요구사항에 대한 문제는 수십년을 걸쳐서도 깔끔히 해결못한 SW공학의 블랙홀 중 하나이다.
이렇듯 한가지 방식으로 간단하게 해결 되는 문제는 아니다.

하지만 가끔은 중심에서 벗어나서 머리를 식히며 우리가 가는 방향이 맞는지, 더 개선이 가능한 방향인지는 한 번쯤 생각해 볼 필요는 있는 것 같다.

" 한 방향으로 가속화 하는 식의 개선은 한계가 쉽게 온다. 근본적인 원인은 현상의 이면에 있을 수도 있다. " 는사실을 마음속에서 되뇌이면서 말이다.





[이미지 참고]
1. http://www.flickr.com/photos/40491122@N03/3738306829/
2. http://www.flickr.com/photos/clagnut/531802055/
3. http://www.flickr.com/photos/andrewgrant/461624012/
4. http://www.flickr.com/photos/linux-works/289746552/
5. http://www.flickr.com/photos/noamg/226698892/
6. http://www.flickr.com/photos/jeffrinehart/2375255538/
등등..
저작자 표시 비영리 동일 조건 변경 허락
신고