프로그래밍 경영: 리스크와 디버깅
돌아서면, 소위 ‘사고를 치는 학생들’이 있었다.
누구나 불편을 느꼈다. 교실 분위기는 쉽게 흐트러졌다.
그래도 어찌어찌 수업은 이어졌고,
마음 한구석엔 언제 또 일이 터질까 하는 불안이 쌓여갔다.
결국 우려하던 문제가 터졌다.
담당 선생님은 죄인 아닌 죄인이 되었다.
“이 일은 제가 책임지고…”
하지만 MZ대표는 곧바로 물었다.
“어떻게 책임지실 건데요?”
선생님은 아무 말도 하지 못했다.
책임이라는 단어 앞에서, 방법은 막막했다.
MZ대표의 말이 이어졌다.
"이게 왜 선생님 책임입니까?
제대로 된 매뉴얼이 없는 이유죠—
이런 문제들도 시스템의 언어로 번역이 가능해야 합니다."
그래, 우리 잘못은 없다.
진짜 잘못은 이런 문제 상황에 제대로 대응하는
매뉴얼이 없었던 것이다.
정적이 흐르자 대표는 입을 열었다.
“착각할까 봐 확인합니다—
여러분은 '내가 학생들에게 뭔가 해준다.'는
생각이 깔려있는 것 같습니다.
그런데, 도대체 뭘 해 줄 수 있죠?
이 상황이 나만 이상해요?"
대표는 고개를 저으며 말을 덧붙였다.
"애초에 모두 만족시킬 수 있는 건 없습니다."
MZ대표의 말을 빌리자면,
우리의 행태는 자기 돈 주고 자동차를 산 고객에게
우리가 되려 자동차를 주었다고 말하는 꼴이었다.
"착각의 서비스죠. 한마디로 선 넘은 겁니다."
표정을 누그러뜨리고 말을 이어갔다.
"영웅주의는 지속될 수 없습니다.
괜히 힘 빼지 말고 회사에 기대세요.
매뉴얼한테 책임지라 하세요. 얼마나 편합니까."
처음엔 차갑다고 느껴졌던 말이,
조금씩 납득되었다.
다음날 [고객 대응 프로세스 v1.0]라는 이름으로 공지가 떴다.
Phase 1: 감지 > Phase 2: 대음 > Phase 3: 에스컬레이션
의 대응 프로세스에 세부 사항이 꼼꼼히 기록되어 있었다.
실무 직원들과 몇 번의 수정 끝에 새로운 버전이 업데이트되었다.
문제가 발생하면 우리는 늘 ‘사람’을 먼저 탓했다.
하지만 불확실한 수업과 학생의 돌발행동을
매뉴얼 없는 책임으로 떠안는 시대는 이미 지나갔다.
프로그래머는 버그가 발생하면
코드를 탓하지, 컴퓨터를 탓하지 않는다.
마찬가지로 조직의 문제도
사람이 아니라 시스템 설계의 오류이다.
이제는 시스템에 기대어,
각자의 역할과 한계를 인정하며 일하는 것이
불필요한 죄책감과 불안을 덜고,
조직과 개인을 더 성숙하게 만든다.
매뉴얼이란 누군가에게 책임을 지우는 게 아니라,
같은 실수를 반복하지 않기 위한 디버깅 도구이다.