직장 생활을 하며 제가 저지른 가장 부끄러운 일은 동료에게 거짓말을 한 것이었습니다. 약 10년 전, 갓 입사한 인턴이었던 저는 업무를 서둘러 마무리하려다 스테이징(staging) 환경에서 작업물을 테스트하는 단계를 건너뛰었습니다. 결과는 실패였습니다. 프로덕션(production) 환경에 배포했을 때도 역시 작동하지 않았습니다. 사실 큰 문제는 아니었습니다. 당시 작업 중이던 페이지는 아직 고객에게 노출되지 않은 상태였으니까요. 하지만 동료가 책상을 너머로 “테스트했을 때는 잘 됐나요?”라고 물었을 때, 저는 “그럼요, 잘 됐는데 왜 이러는지 모르겠네요”라고 답해버렸습니다.
그 동료는 아마 그 일을 바로 잊었을 겁니다. 제가 테스트 과정에서 단순히 실수했거나(예를 들어, 배포한 코드와 다른 코드를 실행해 봤다거나), 혹은 제가 거짓말을 하고 있다는 걸 눈치챘더라도 별로 신경 쓰지 않았을 수도 있습니다. 하지만 저는 잊지 못했습니다. 10년이 지난 지금도 이 글을 쓰면서 부끄러움을 느낍니다.
물론 제가 저지른 실수 자체가 부끄러운 것은 아닙니다. 테스트를 하지 않은 것은 부주의한 일이었지만, 그 이후로도 필요하다고 판단될 때는 절차를 생략한 적이 있고 지금도 그 결정을 지지합니다. 제가 부끄러운 것은 그 상황을 대처한 방식입니다. 하지만 당시의 저도 이해는 갑니다. 저는 빨리 배우고 싶어 했고, 제가 IT 업계에 어울리는 사람이라는 것을 증명하고 싶어 했던 어린애였으니까요. 제가 저지른 실수를 곱씹고 싶지 않았던 것이죠. 만약 지금 제가 그 동료의 입장이라면 저 역시 대수롭지 않게 넘겼을 겁니다. 그렇다면 지금의 저는 실수를 어떻게 다루려고 노력할까요?
감정적 반응 다스리기
가장 중요한 것은 자신의 감정을 조절하는 것입니다. 저와 비슷하다면, 직장에서 겪는 가장 강렬한 감정적 반응은 대개 실수를 저질렀을 때 나타날 것입니다. 이때 보통 두 가지 상충하는 감정이 작용합니다. 자신을 방어하고 변명을 찾으며 결과를 최소화하려는 욕구와, 죄책감을 고백하고 자신을 낮추며 용서를 구하려는 욕구입니다. 이 두 가지 모두 함정입니다.
자신을 변호하거나(혹은 제가 했던 것처럼 실수를 아예 부정하는 것) 나쁜 일임은 분명합니다. 하지만 반대로 공개적으로 자신을 자책하며 괴롭히는 것 역시 그만큼 나쁩니다. 여기에는 몇 가지 이유가 있습니다.
첫째, 동료들이 문제 해결에 집중해야 할 시간에 당신을 안심시키기 위해 시간과 노력을 들게 만듭니다. 둘째, 문제 해결에 집중해야 할 집단에서 스스로를 이탈시킵니다. 대개 실수를 저지른 본인이 상황을 가장 잘 알고 있으므로 해결책을 찾기에 가장 적합한 위치에 있음에도 말이죠. 셋째, 이는 전혀 프로페셔널(professional)하지 못한 행동입니다.
그렇다면 어떻게 해야 할까요? 처음 얼마 동안은 아무것도 하지 마세요. 감정적 반응은 시간이 지나면 잦아듭니다. 실수를 깨달았을 때의 그 충격과, 당장 해결하기 위해 뛰어들고 싶은 충동이 지나가기를 기다리세요. 실수에 대한 최악의 반응은 대개 직후에 발생하므로, 그 짧은 시간 동안 아무것도 하지 않는 것만으로도 좋은 시작이 됩니다. 저의 경우 이 시간은 약 30초 정도 걸립니다. 사람마다 필요한 시간은 다르겠지만, 10분 이내이기를 바랍니다. 그보다 더 오래 걸린다면 이를 악물고 업무에 임해야 할 수도 있습니다.
소통하기
감정을 통제할 수 있다는 확신이 들면, 다음 단계는 무슨 일이 일어났는지 알리는 것입니다. 보통은 매니저에게 알려야 하지만, 문제의 성격에 따라 동료나 다른 사람일 수도 있습니다. 이때 중요한 것은 사실 위주로 담담하게 말하는 것입니다. 그렇지 않으면 앞서 언급한 “내가 너무 부족하니 나를 안심시켜 달라”는 함정에 빠질 위험이 있습니다. 문맥상 명확하다면 굳이 “제가 실수를 했습니다”라고 명시적으로 말할 필요도 없습니다. 그저 “변경 사항을 배포했는데 X 기능이 고장 났습니다”(혹은 무엇이든 발생한 문제)라고 말하면 됩니다.
이 작업은 해결책을 찾기 전에 이루어져야 합니다. 실수를 숨기고 조용히 해결하고 싶은 유혹이 들겠지만, 사용자에게 노출되는 실수는 숨기는 것이 불가능합니다. 결국 누군가는 티켓을 생성할 것이고, 당신이 소통하지 않는다면 다른 누군가가 문제를 발견하고 별도로 보고하게 될 위험이 있습니다.
최악의 경우, 당신이 조용히 수정을 진행하는 동안 다른 누군가가 인시던트(incident)를 선포할 수도 있습니다. 당신은 원인을 완벽히 알고 있고(본인이 원인이니까요), 잘못된 배포 때문이며 쉽게 고칠 수 있다는 것도 알고 있습니다. 하지만 인시던트 회의에 참석한 다른 사람들은 그 사실을 모릅니다. 그들은 최악의 시나리오를 가정하며 데이터베이스나 네트워크 문제인지 고민하고, 온갖 팀을 호출(paging)하며 큰 혼란을 겪게 됩니다. 당신이 즉시 보고만 했더라도 이 모든 고생을 피할 수 있었을 것입니다.
제 경험상, IT 기업의 매니저들은 실수를 용서하지만, 자신을 바보처럼 보이게 만드는 것은 용서하지 않습니다. 특히 중요한 정보를 전달받지 못하는 상황을 용서하지 않습니다. 만약 상사로부터 인시던트에 대한 설명을 요구받았는데, 당신이 이미 알고 있던 맥락이 없어서 매니저가 허둥대야 한다면, 그와의 관계는 영구적으로 손상될 수 있습니다. 반면, 즉시 문제에 대한 명확한 요약을 제공하여 매니저가 상황을 장악하고 있는 것처럼 보이게 한다면, (비록 당신이 원인을 제공했더라도) 오히려 신뢰를 얻을 수도 있습니다.
고통을 받아들이기
하지만 신뢰를 얻지 못할 가능성이 더 큽니다. 여기서 저는 ‘인시던트는 항상 시스템의 잘못이지 개인의 잘못이 아니다’라는 소프트웨어 공학계의 대중적인 통념과 의견을 달리합니다. 물론 인시던트는 복잡한 시스템 간의 상호작용으로 인해 발생합니다. 우주의 모든 일이 그렇죠! 하지만 그 연쇄 작용의 원인 중 하나는 종종 누군가의 실수입니다.
엔지니어링 조직의 매니저라면 프로젝트를 성공시키기 위해 믿고 맡길 수 있는 엔지니어들의 명단을 머릿속에 가지고 있을 것입니다. 만약 어떤 엔지니어가 반복적으로 실수를 저지른다면, 그 명단에서 제외되거나 이름 옆에 주의 표시가 붙게 될 가능성이 높습니다.
실수에 합당한 기술적 이유가 있었는지, 혹은 참작할 만한 사유가 있는지는 중요하지 않습니다. 매니저들은 그런 세부 사항에 관심이 없습니다. 그것이 진실인지 아니면 단지 변명인지 판단할 기술적 맥락이 부족하기 때문입니다. 매니저가 평가할 수 있는 맥락은 오직 결과뿐이며, 그것이 당신을 판단하는 기준이 됩니다. 즉, 충분한 성공으로 균형을 맞출 수만 있다면 어느 정도의 실패는 용납될 수 있다는 뜻입니다.
뛰어난 엔지니어가 된다는 것은 항상 옳은 판단을 내리는 것과 리스크를 감수하는 것 사이에서 균형을 찾는 일입니다. 항상 옳은 판단만을 내리려 한다면 실수는 피할 수 있겠지만, 프로젝트를 주도할 수는 없을 것입니다(주도에는 항상 리스크가 따르기 때문입니다). 따라서 직장에서의 최적의 실수 횟수는 0이 아닙니다. 특수한 몇몇 산업 분야를 제외하면, 때때로 실수를 저지르는 것은 당연한 일입니다. 그렇지 않다면 당신은 아마 너무 느리게 일하고 있을 가능성이 큽니다.
원문: On screwing up
blog by ash에서 더 알아보기
구독을 신청하면 최신 게시물을 이메일로 받아볼 수 있습니다.
