어떤 기능에 문제가 있어서 사업자에게 정중히 사과를 하고 패치파일들을 보냈다
하지만 해당 패치를 적용한 후 사업자쪽에서 더 큰 문제가 발생한 것이다.
분명 우리가 돌렸을때는 잘 됐는데 왜 사업자한테서 문제가 발생한 것인가!?!?
담당자와 우리의 협력업체는 밤을 새가며 디버깅을 했지만 뾰족한 이유를 찾지 못했다.
다음날 사업자에게 다시 한 번 사과의 메일을 보내고 일정 delay를 살짝 얘기해보는 순간, 사업자쪽 Merger에게 메일이 왔다
"내 실수다. 패치들 중 한 개를 누락하여 merge를 하였다. 모두한테 암 쏘 쏘리"
누구의 잘 못 인가?
기능 담당자?
사업자쪽 Merger?
내 생각에는 사업자쪽 회사의 잘못이고, 그 다음이 사업자쪽 Merger, 그 다음은 기능담당자이다.
굳이 그 잘못의 크기를 얘기하자면, 80%/10%/10% 뭐 그 정도?
뚱딴지같지만 사업자 조직을 막 욕해야 한다.
휴먼에러는 누구든지 저지를 수 있다는게 내 생각의 바탕이다.
Merger는 하루에도 얼마나 많은 소스를 이메일로 받아서 Merge를 할까?
Merge하는 툴이나 있을까?
걍 수작업으로 copy & paste?
만약 그 Merger의 role이 Merge말고 다른 기능을 또 맡고 있다면, 주기적으로 Merge를 하는게 얼마나 귀찮고 짜증날까?
Merge 실수라고 해서 기능담당자들이 Merger를 비난하는 순간 최악의 상황이 발생할 수 있다.
결론은 조직의 잘못이다. 무조건 무조건이다.
조직는 Merge 실수를 방지할 system을 마련해야한다
소스 반영은 각 개발자가 직접 수행하고 빌드도 자동으로 돌아가게 해야한다.
각 업무의 step step 마다 누가/언제/어떻게 했는지 추적이 가능해야 하고, 최대한 자동화를 해야 한다.
Merger를 비난하지 말고 이 과정을 시스템화 시키지 않은 조직를 비난해야한다.
그런 시스템을 구성 할 사람이 없다면?
영원히 고생하고 Merger의 인생을 망쳐버려라.
(실제로 최고의 대학을 나오고 4개 국어를 하고 코딩을 굉장히 좋아하는 유능한 인재가 입사 후 Merger만 2년하고 성격이 비관적으로 변하여 진급도 계속 누락되고 결국 퇴사하는 모습을 보았다. 또 다른 Merger는 건강악화로 퇴사 후 한의원을 전전하다가 작은 회사로 이직을 한 경우도 있다)
'<기타> > ___회사생활' 카테고리의 다른 글
| 되는 방향의 idea를 내자 (0) | 2016.01.18 |
|---|---|
| 보고 Line이 많다 (0) | 2016.01.18 |
| 블리자드 (0) | 2009.08.11 |
| [스트랩] 이클립스에 소스 주석 달기 (0) | 2009.07.03 |
| 버전 관리 규칙 (0) | 2009.05.22 |
