아니! 여러분은 개발자라니깐요.
요즘 "애자일 프랙티스"란 책을 팀내에서 스터디 하고 있다. 어찌나 절절히 내 마음을 찔러대는지, 역시 행복은 내가 손을 내밀지 않아서 잡지 못하는것이 었구나 뭐 그런느낌을 받습니다. ( 프로그래밍 책을 읽으면서 ㅎㅎ)
좋은글이 올라왔군요.
마음에 와 닿는 구절을 살짝 요약하면
7. 문제가 생기면 남 탓부터 한다.
모 사이트에서 작업하면서 O사의 컴포넌트를 가져다 사용한 적이 있었습니다. 저희 쪽에서는 그 컴포넌트를 좀 더 쓰기 쉽게 래핑해서 개발 프레임워크 내에 집어넣었습니다. 그런데 사용하다 보면서 갑자기 문제가 발생했습니다. 발생한 시점은 O사의 컴포넌트를 최신 버전으로 교체하고 난 이후였고, 열심히 디버깅해본 결과 최종적인 오류는 O사의 컴포넌트 내부에서 발생하는 것으로 판명되었습니다. 당장 이전 버전으로 롤백을 하면 문제는 없겠지만, 최신 버전에 포함되어 있는 기능이 필요하기에 당장 결정할 수는 없는 상황이었습니다. 그래서 문제를 O사에 문의했습니다. 유사한 문제가 발생한 적 있는지, 아니면 이를 수정할 수 있는 방안이 있는지. 워낙 급한 문제라서 바로 긴급 기술지원을 요청했고, O사 엔지니어가 왔더군요. 이 엔지니어는 오자마자 시스템이나 코드는 열어보지도 않고 무조건 절대 자기 회사 컴포넌트에서 문제가 발생할리가 없다고 주장하더군요. 일단 보기라도 하고 말하라고 했더니 잠시 살펴본 후에 이번에는 래핑하는 프레임워크 코드가 잘못 되었다고 주장하더군요. 프레임워크 안의 코드는 그들이 제공하는 예제 코드를 그대로 가져다 쓴 것이었습니다. O사 엔지니어는 자신들이 제공하는 예제를 돌리면 문제가 없으며 너희가 분명히 어딘가 코딩을 잘못 했을거다라고 하더군요. 그래서 아예 그럼 당신이 직접 그 예제를 가지고 돌려보라고 했습니다. 도대체 뭘 하는지 모르겠지만 몇 시간을 예제 가지고 끙끙대고 있더군요.
그러다 엔지니어가 온지 무려 6시간 만에 자기들 컴포넌트의 문제인 것 같다고 시인하더군요. 우리가 원하는 건 문제의 해결이지 누구 잘못인지를 따지는 것이 아닌데, 자기들 문제라고 시인하는데 무려 6시간이 소요되었습니다. 그래서 디버깅을 통해 빨리 문제를 분석하고 해결해줄 수 있냐고 했더니 한번 알아보겠답니다. 언제까지 해결하겠다는 것도 아니고 알아보겠다니, 정말 미치는 노릇이죠!
- 파란매직 : 이거 생각 보다 여렵습니다. 생각해 보면 다들 누구의 잘못인지를 가장 궁금해 하기 때문이 아닌가.? 라는 생각이 듭니다.
8. 별거 아닌 습관 속에서 문제가 발생할 수도 있다.
9. 문제는 예방하는 것이 최선이지만, 소를 잃더라도 외양간을 고치자.
10. 그래도 가장 중요한 것은 사람으로서의 예의이다.
다들 알고 있는 내용일껏 같지만 다시한번 돌아본다는 의미에서.. 적어봤습니다.
그럼 이만 총총총.