MZ아들이 저희 회사 대표입니다.
"누가 잘못했는지 따지지 말고,
어디서 오류가 생겼는지를 찾아야죠."
문제가 생기면, 우리는 습관처럼 '범인'을 찾는다.
하지만 프로그래밍 사고는 다르다.
사람을 심문하지 않고 흐름을 본다.
왜 그런 입력이 들어왔는지,
그 입력은 어느 함수(팀, 규칙, 혹은 직원)를
지나며 변형되었는지를 추적한다.
이 과정을 우리는 '디버깅'이라 부른다.
한번은 회원 단체 톡의 문구 하나가
오해를 불렀다.
담당자는 주눅이 들어 스스로를 탓했고,
우리들도 내심 원망했다.
그때 대표가 물었다.
“이 문구가 왜 다르게 해석됐을까요?
이전과 특별히 달라진 부분이 어디죠?”
몇 번의 질문과 대답 끝에 원인을 찾았다.
고객 관리팀과 운영팀이
같은 개념을 서로 다른 용어로 쓰고 있었던 것—
우리는 곧장 ‘용어 통일’을 시행했다.
간단한 조정이었지만, 그 한 번의 디버깅이
이후 수십, 수백 건의 오해를 미리 지웠을 것이다.
시스템을 자동화하자 센터는 알아서 굴러갔다.
‘이제 내가 할 일 없네.’
그 말처럼, 아들은 미뤄두었던 군대로 떠났다.
훈련소 수료 후 하루 쉬는 날—
지난 1년에 관해 함께 이야기를 나눴다.
뭐가 제일 힘들었어?
“엄마 디버깅하는 게 제일 힘들었음.”
아들은 코드보다, 생각의 습관을 바꾸는 일이
더 어렵더라며 한마디를 덧붙였다.
“○○○씨가 업데이트를 거부해서—”
알고보니 내가 리스크였네—
그동안 엄마 때문에 네가 고생이 많았다.
아들이 무슨 말이냐는 듯 동그랗게 떴다.
"내가 만든 프로그램인데 왜 엄마 탓인데.
엄마까지 내가 세팅한 건데—?"
진지해서 더 당황스러웠지만—
디버깅은 단순한 기술이 아니라,
문제를 대하는 철학에 가깝다는 걸 깨달았다.
"근데, 엄마— 리스크가 해결되면
기분이 얼마나 좋은지 아나.
그 맛에 하는 거 같기도—"
긴 시간 운전해 돌아오는 내내 많은 생각을 했다.
리스크는 예측할 수 없기에 불안을 동반한다.
그 불안은 무언가를 알려주는 신호다.
어쩌면 내가 겪은 혼란과 실패의 많은 부분도
나를 키우기 위한 신호였을지도 모른다.
리스크를 디버깅한다는 건
결국 나 자신을 업데이트하는 일이다.
지금부터라도 시스템이 나에게
‘업데이트 요청’이 오면
디버깅하는 맛이 뭔지 느껴보려 한다.