문제가 있을 때 누군가를 탓하지 말자. 원인이 본인 때문이라고 느껴져도 스스로 자책하지 말자.
조직에선 코드로 인한 오류든, 실수로 인한 장애든, 빗나간 일정 추측이든 문제는 언제나 발생한다. 이런 문제를 개인이 자책하며 후회하고 괴로워하지 않아야 한다. 문제에서 학습하고 성장하기 위해 조직은 누군가를 탓하기보다 먼저 문제가 왜 발생했고 어떻게 하면 재발 방지가 이루어지는지 고민하고 실행할 수 있는 문화를 조성해야 한다.
x 서비스에 의존하는 y 서비스를 배포할 때, x 서비스의 최신 버전 배포를 잊고 y 서비스를 배포해서 장애가 났을 때, 문제를 개인의 실수로 여기고 그 개인은 "제가 배포 전에 x 서비스를 확인했어야 하는데 잊었습니다. 다음부턴 주의하겠습니다." 다짐할 수 있다. 문제를 눈앞에서 치워버리기는 쉽지만 개인의 탓으로 여길수록 재발 방지가 되는지 확신할 수 없고 개인과 조직 모두 유의미한 학습을 하기 어렵다. 조직은 현재 서비스 간 배포 상태에서 충분한 가시성을 확보할 수 있었는지, 어떻게 하면 x 서비스 배포가 누락되어 있는지 인지시켜줄 수 있었는지, 자동화된 방법으로 사람의 개입 없이 최신 상태를 유지할 순 없었는지, 왜 개인이 실수할 수 있는 환경이었는지 등 문제의 근본 원인을 해결해 재발 방지에 확신을 가질 수 있어야 한다.
자료형을 잘못 다뤄 큰 값에서 에러가 발생하고 이를 유저에게 배포된 후에야 다른 사람의 제보로 알았을 때 마치 본인이 코드를 잘못 짰고 왜 진작 인지하지 못했는지 자책하기 쉽다. 개인을 탓하기보다 먼저 어떻게 하면 코드 리뷰에서 인지할 수 있었을지, 테스트 코드가 있었는지, 테스트 케이스가 너무 큰 값, 너무 작은 값도 고려하고 있었는지, 유저에게 배포되기 전 확인해볼 수 있는 환경은 있었는지, 큰 값을 다루는 공통 영역에 가이드가 있었는지, 자동화된 도구로 이를 해결할 순 없었는지를 보자.
프로젝트 일정이 반 정도 지나고 처음 산정한 일정에 맞추기 어렵겠다는 생각이 들 때면 개인으로선 한번 약속한 일정을 밤새워서라도 맞추고 싶은 마음이 든다. 한두 번은 늦게까지 일하며 일정을 맞추려 하지만 이내 몸과 마음이 지치고, 왜 일정을 못 지켰지 죄책감을 느끼고 번아웃이 온다. 스스로 자책하기보단 어떻게 하면 더 빠르게 일정 문제를 인지할 수 있었을지, 어떻게 하면 더 잘 추정할 수 있었을지 고민하자. 처음 일정을 산정할 때 개인이 심리적 안정감을 느끼는 상태였는지, 일정과 스펙은 고정된 채 한정된 리소스를 그에 맞추려고 한 건 아니었는지, 스펙이 학습을 위한 최소한의 스펙이 맞는지, 개발 완료가 무엇을 뜻하는지 더 잘게 쪼개고 명확히 하자. 코드 작성뿐만 아니라 리서치, 코드 리뷰, 테스트, 피드백 반영 등 다른 요소도 고려했는지, 하루 업무 시간을 100% 활용할 수 있다고 가정하진 않았는지, 일정에 blocking point가 있진 않은지 짚어보자. 80%의 자신감으로 x일 내에 끝낼 수 있을 때 95%의 자신감으론 얼마나 일정이 더 필요한지, 그 요소가 무엇이며 나머지 5%는 무엇 때문인지 공유하자. 어떤 업무를 하고 있고 어떤 고민이 있고 어떤 blocking point가 있는지 매니저와 팀원이 투명하게 확인할 수 있는 환경을 만들자. 감에 의존하지 말고 장치를 두고 자동화된 도구를 믿자.
내 코드가 아니라 우리의 코드고, 개인의 실수가 아니라 시스템의 부재라고 생각하자. 왜 문제가 발생했는지 꼬치꼬치 캐묻고 근본 원인을 찾고 재발 방지까지 다다르자. 누군가를 탓하고 스스로 자책하지 말자.