엔지니어 생활이 2-3년을 넘어가다 보면, 장비의 상태를 파악하는, 본인만의 판단 기준이 생깁니다. 초급 시절에는 모든 로그가 생소하기 때문에, 하나 하나 꼼꼼하게 검토하고, 혹시 모를 레퍼런스를 체크하고, 레퍼런스도 명확하지 않다면, 케이스 오픈 후 분석을 의뢰하기도 하죠. 행여 잘못되면 어쩌나 하는 마음에 노심초사. 밝혀지지 않은 현상에 두려움을 느끼기 일수입니다. 아마 이런 과정이 모두 지나고 축적된 경험치가 나의 기준을 만드는 것이라고 생각합니다. 오늘은 그 기준이 옳지 않은 방향으로 수립되었을 때에 대해 말씀드리고 싶습니다.
아 이거, 별일 아냐
한참 사수에게 인수인계를 받던 시절 사수가 자주 하던 말이었습니다. “아 이거? 별일 아냐 벤더도 잘 모른대” 모든 것이 의문 투성이었던 저는 찝찝한 마음을 감출 수 없었고, 사무실에 복귀할 때면 어깨너머로 보았던 미상의 로그를 서치해보며 발생 원인을 파악하기 위해 애쓰곤 했습니다. 한참 이런 생활이 반복될 무렵, 사수가 일명 ‘별일 아님’으로 치부하는 현상들에 대해 일련의 공통점을 발견하게 되었죠.
1. 장비를 운용하는데 지장이 없음
2. 왜 이런 현상이 발생하는지 모름
3. 귀찮음
그랬죠, 사수는 딱히 지장이 없는데 무언가를 바꾸고, 고치는 것을 귀찮아 했습니다. 퇴근 시간이 미뤄지고, 본인의 업무량이 많아지는 것이 썩 달갑지 않았을겁니다. 그 부분에 대해서는 충분히 공감하는 입장입니다. 다만 스스로 ‘귀찮다’라고 치부하는 것들의 근본적인 원인 중에 ‘내가 모르는 것을 알려고 하지 않는 귀찮음‘이 포함되어 있다는 것을 알게 되었습니다. 즉, 사수는 퇴근 시간과 업무량과 관련 없이 단지 어떤 모르는 것을 배우고, 알아가는 과정이 귀찮은 것이었죠. 그래서 저는 이것을 ‘문제’라고 규정하고 싶었습니다.
저는 지금도 그때와 크게 다르지 않습니다. 여전히 그것을 ‘문제’로 간주하고 있고, 귀찮음을 무릅쓰는 행위가 고결하다고 생각합니다. 다만 그 이전에 문제를 유발하는 어떤 중요한 원인을 알게 되었고, 거기엔 그 사람의 잘못만 있는 것이 아니라는 사실을 깨닫게 되었습니다.
저항기
어찌 되었든 저는 별일 아닌 것들에 저항하여, 모든 원인을 알아가기 위해 노력했습니다. 한정적인 경험치와 지식 풀 안에서 나름의 합리적 기준점에 도달하기 위해 고군분투했었죠. 참 마음 같지 않던 시기였습니다. 당시 벤더도 내부적으로 신규 제품을 활성화하던 시기였고, 내부 엔지니어들은 다른 곳을 지원하는데 대부분의 시간을 쏟았습니다. 매우 혼란스러운 시기였죠.
제가 문의한 글은 매번 회신 없이 게시판 저 밑바닥으로 외면 당하기 일쑤였고, 매번 기아상태로 전락하고 말았습니다. 간혹 가다 달리는 댓글은 온통 ‘펌웨어 업그레이드 해보세요’, ‘메모리 교체하세요’와 같은 솔루션 위주의 답변이었고, 정작 제가 궁금했던 원인은 뒷전이었습니다. 벤더사도 업무 스케줄링의 우선순위가 있을테니 그것을 원망하진 못했지만, 중요한 건 제 내면의 변화였다고 생각합니다.
모르고 넘어가는 상황들이 계속적으로 발생하게 되고, 그 해소되지 못하는 기간이 점차 길어지게 되자, ‘문의 해봤자 일텐데’ 하는 자포자기의 마음이 자리 잡게 된 것이죠. 그러다 결국 스스로의 합의점에 도달하게 되었습니다. 도저히 풀리지 않는 호기심을 알기 위해 노력하기보다 ‘그거 알 필요 없어’ 하는 자기 방어가 생기기 시작했습니다. 그랬습니다. 별일 아닌 일 이전에, 알 필요 없는 일이 먼저였던 것이죠.
그 판단 기준의 근거
그렇게 자기 방어가 생긴 저는 스스로 합의한 나름의 판단 기준과 함께 엔지니어링을 수행하게 됩니다. 중요한 건 이 로그가 추후 ‘문제가 되는가’에 대한 관점이고, 경험치로 짐작했을 때 그렇지 않다면 ‘꽤 부정적인 로그임에도 불구하고’ 정상으로 판단해버리는 경우들이 생겨나게 됩니다. 왜냐면 그건 정말 알 필요가 없었으니까요.
‘제가 생각했을 때’, ‘제가 경험한 결과’ 와 같은 주관적 데이터로 고객을 설득하기란 쉽지 않습니다. 고객의 입장에서는 분명 비정상 로그로 보일 것이고, 본인의 의심을 해소해 줄 수 있는 엔지니어의 ‘논리적이고 객관적인 규명’을 요구하게 되겠죠. 이는 고객의 정당하고, 당연한 요구라고 생각합니다.
고객의 요구가 있었으니, 이제는 더 이상 별일 아닌, 알 필요 없는 일이 아니게 되어버립니다. 드디어 명분이 생긴 것이죠. 원인을 밝히기 위해 이전보다 더욱 집요하게 벤더를 괴롭히게 되죠. 대부분은 벤더 엔지니어를 동원하고 며칠 모니터링을 하고, 최후에 연구소에 문의를 마치고 나면 원인이 밝혀지게 됩니다.
” 일반적인 SW 버그 “ (펌웨어 패치 예정)
“버그 없는 SW는 있을 수 없는 거지 않습니까… 엔지니어 소견 상 운영에 문제는 없으니 그렇게 말씀드렸을 뿐입니다.” 그때부터 고객과의 마찰은 시작됩니다. 고객은 벤더사의 버그라는 입장에 더 이상 엔지니어를 신뢰하지 못하죠. 고객에게 버그는 장애와 같은 것이니까요. 엔지니어는 운영 상에 문제에 집중하지만, 고객은 100%의 무결함을 요구합니다. 제품과 서비스를 이용하는 고객의 입장은 대부분 이럴 것이고, 제가 고객이어도 이렇게 행동했을 것 같습니다.
마찰이 지속되고 감정 낭비가 계속되다 보면 엔지니어는 또 다시 이런 생각으로 본인의 행동을 정당화하게 됩니다. ‘거봐 내가 이럴까봐 말 안 한거야. 별일도 아닌데 유난을 떠니까’ 라고 말입니다. 이런 단계까지 오게되면 고객과 기술적, 대응적 한계를 공유하면서 서비스 제공 수준의 협의점을 찾아내기란 더욱 쉽지 않습니다. 고객에게는 협의에 대한 논의가 일종의 변명처럼 들릴 것이 뻔하기 때문입니다.
귀찮음 병의 전염
글을 쭉 읽어보면, 귀찮은 엔지니어가 문제를 방치하고, 그 결과 고객의 컴플레인으로 이어진 상황으로 보입니다. 엔지니어가 적당히 점검하고, 적당히 처리한 것들이 고객의 입장에서는 매우 성의 없는 조치로 보여 졌을 테니까요.
어쩌다 열정과 호기심이 가득하던 어린 엔지니어가 본인의 사수처럼 ‘귀찮음’병에 걸려버린 것일까? 동정 어린 시선으로 이를 바라봐주는 사람은 없습니다. 동료 엔지니어들조차 ‘그러게 좀 잘하지 그랬어 ‘라는 말로 대응하기 일쑤죠. ‘내가 어쩌다 이렇게 되었는데..’ 라고 스스로를 위로해봤자 내면 깊은 곳에서 타협하지 말아야 할 것과 타협한 것에 대한 깊은 자기 혐오가 느껴집니다.
내가 그토록 이해할 수 없었던 사수와 같은 길을 걸어가던 내 모습을 발견하면서, 아무리 옳았다고 생각해도 옳지 않았음을 느끼면서, 괴로운 시간은 지속됩니다. 그래도 언제까지 실의에 빠져있을 수는 없는 것 아니겠습니까? 우리는 실패 후에도 다시 생산적인 활동을 이어 나가야하고, 잘못한 것에 대한 반성과 함께 한층 더 성장하는 기회를 가져야합니다.
그 해결책에 대해
- 당당하게 요구하라
- 호기심을 저버리고 스스로 타협하게 되는 과정은, 나의 문의가 매번 기아상태로 전락하는 것을 보며, ‘벤더가 바쁘니까..’, ‘비즈니스가 우선이니까’ 하며 그들을 배려했기 때문입니다. 당당히 파트너의 자격으로 로그 발생 원인에 대해 문의하고, 정식적으로 품질보증을 요구하세요.
- 내부 정책을 통해 기준을 수립하라
- 별일 아니라고 정의하는 사수의 기준은 참 모호합니다. 명확한 기준 수립을 위해 내부 정책을 설계하세요. 어디까지가 별일이 아닌 건지, 어느 시점부터 처리가 필요한 건지 정의하는 과정을 통해 팀의 엔지니어들이 모두 같은 기준으로 점검을 수행하는 일관성을 확보하는 것이 중요합니다.
- 서비스 수준을 협의하라 (SLA)
- 마지막으로 고객과 서비스 수준을 협의하세요. 통칭 99.999%의 가동률을 보장하는 조건으로, 엔지니어의 판단 하에 사소한 문제를 직접 처리하게 할 것인지, 모든 상황을 고객과 공유하며 의사소통을 통해 처리하게 할 것인지를 정의하는 과정이 필요합니다. 이는 추후 문제 발생 시 책임 소재를 명확히 구분할 수 있으며, 각자의 목표가 통일된다는 점에서 입장의 간극을 줄이는데 매우 도움이 됩니다.
- 우리 회사는 SLA가 없는데요? 가동률과 장애 처리 시간, SR 적기 처리율 정도를 포함하여 최소 기준의 SLA를 간단하게 수립하고, 고객과 공유해보세요. 어려운 과정은 아닐겁니다.
Tip : 결국 문제는 스스로 만든 기준에 타협하지 않는 태도와 협력의 문화에서 해결될 수 있다고 생각합니다.
마치며
오늘은 제가 귀찮음 병이 걸려 고객으로부터 컴플레인을 받고, 성장하게 된 계기에 대해 말씀드렸습니다. 혹시라도 저와 비슷한 경험을 가지셨거나, 이런 상황에 처해 있는 분이 계신다면, 한 말씀만 드리고 싶습니다. 모두의 잘못이 조금씩 만나서 결국 문제로 발전했을 뿐이라는 것을요.
별일 아니라는 가르침을 준 사수와, 나의 외로운 고군분투를 방치한 조직, 문의를 제때 처리해주지 않은 벤더 모두에게 조금씩 잘못이 있다는 것을요.
결국 우리는 실패를 통해 성장합니다. 뒤늦게 정리하다 보니 어쩌면 실패 후에 얻는 것들이 성공보다 값질 수 있다는 생각이 듭니다. 물론 극복했을 때의 일이겠죠? 저는 우리 모두가 실패를 딛고, 당당히 극복하면서, 더 큰 성공으로 나아가리라 깊이 믿습니다. 그러니 묵묵히 여러분의 실패를 응원하겠습니다.