2주 전에 새로운 팀으로 발령이 아닌 파견을 받았습니다. 일하고 있던 팀은 데이터 통합 관련 업무를 하던 팀입니다. 거의 프로젝트가 마무리 되어가는 단계였는데, 갑자기 팀 리더가 부르더니 너 오늘부터 유지보수팀으로 가야해라고 합니다. 미리 언질도 없이 하루만에 팀을 옮겼습니다. 하여간 서양 회사들은 낌새 없이 레이오프하고, 팀 옮기고 하는 것이 아주 일상화 되어 있나 봅니다. 왜 옮겨야 하는데라고 물었더니, 유지 보수팀에 인원이 부족해서 SLA 맞추기 위해 가야 한다고 합니다. 그 전 유지보수 팀에서 새로운 팀으로 옮긴지 3개월 만에 다시 원래 자리로 돌아왔습니다. 팀 소속은 그대로인데 파견 형태인지, 조직도에서 파견이라고 당당하게 써져 있네요.
개발팀과 유지보수팀에는 장단점이 있는데, 어느쪽이 딱히 좋다고 말할 수가 없네요. 개발팀에 있으면 Deadline을 맞추어야 하는데 압박감과 계속 튀어나는 버그 수정이 단점이나, 업무가 순조롭게 진행된다면 여유있는 시간을 확보하여 개인적으로 인터넷 보면서 공부도 할 수 있고, 새로운 개발 트랜드 등도 적용할 수 있다는 장점이 있지요. 하지만 유지보수 팀은 시간적 압박은 거의 없으나 정말 알 수 없는 요상한 상황들의 발생으로 인한 원인 추적이 너무나 까다롭다는 점입니다. 고객사의 관리자는 원인을 알고 싶어하는 사용자 하나 하나의 행동을 추적할 수도 없는 노릇이고, audit log나 데이터 변경 사항을 추적해야 하는데 그게 어디 쉬운 일인가요.
정말 골치 아픈 것은 Third party에서 발생하는 버그일 경우 그 원인을 찾기가 거의 불가능에 가깝다는 점도 하나 입니다. 지금도 버그 하나 가지고 3일째 씨름을 하고 있는 중인데, 아마도 ORM의 캐쉬 때문에 발생하는 것이 아닐까 생각되는 버그입니다. 분명히 데이터베이스에서 데이터를 읽어들이는 것을 DB 프로파일러에서 확인했는데, 내부 Memory에는 변경사항이 적용되지 않는다는 것입니다. 내일 PR을 진행하고 신규 Release 버전이 배포되기 전까지 변경 사항이 제대로 작동하는지 당췌 알 수 없는 버그입니다. Jira에서 키워드 검색을 하니 관련된 버그 또는 스토리가 잔뜩 튀어 나오는데, 아무도 고친거나 개발한 사람이 없습니다. 다들 이유가 무엇인지 모른다는 뜻이지요. 그냥 커맨트에 concurrency 때문에 발생하는 것 같다고만 적어 놨네요.
제가 지금까지 유지보수팀에 있으면서 가장 시간을 많이 잡아 먹은 버그가 아니었나 합니다. 만약 수정한 내용이 맞다면, 다른 모듈들도 전부 바꾸게 될테니 성공적으로 수정되었으면 하는 바램입니다.
'개발 이야기' 카테고리의 다른 글
도메인 주도 설계 - Designing a DDD-oriented microservice (0) | 2018.11.02 |
---|---|
도메인 주도 설계 (0) | 2018.10.21 |
캐나다 개발자의 하루 (0) | 2018.07.24 |
[TypeScript 기초] 5. gulp를 이용한 빌드 자동화 (0) | 2018.07.15 |
[TypeScript 기초] 4. Ajax를 이용한 리스트 바인딩 (0) | 2018.07.14 |
최근댓글