해결사와 질문

문제를 빠르게 해결하는 해결사

해결사에 대한 소문은 더 있었다. 문제를 빠르게 해결하긴 했는데 하나를 고치면 9개의 버그를 만든다고 했다. 그 9개의 버그는 다른 개발자들이 감당해야 했고 빠른 일처리에 대한 영광은 그 사람과 회사가 즐겼다고 한다. 이런 말을 들으면 놀라겠지만 그때는 코드 리뷰가 없었다. 그때는 여러 가지 의미로 회사에서 인정받고 있는 사람의 의견과 코드에 대해서는 언급하면 안 되었다. 이미 나온 회사라고 혹은 다시는 안 만날 사람이라고 해서 회사나 해결사를 탓하는 것은 아니다. 다만 오래전 그 회사의 그 프로젝트가 지금도 잊히지 않는다.

혹시 내가 해결사일까?

해결사 안경을 쓰고 다른 사람들을 해결사로 보고 있는 것은 아닐까 하고 스스로를 의심했다. 어쩌면 내가 해결사 일지도 모른다는 불편한 생각도 들었다. 하나를 해결하고 99개의 문제를 덮어두는 그런 사람일까? 그 해결사도 어쩌면 자신이 만든 코드가 그렇게 많은 버그를 만드는지 몰랐을 수도 있다. 문제에 대한 생각이 서로 달라서 자기 생각대로 문제를 열심히 해결하고 있었는지도 모른다. 그건 아닌데 하는 생각을 작은 댓글로라도 남길 수 있어야 했다고 생각한다. 해결사가 떠나고 다른 해결사가 프로젝트에 들어오는 악 순환이었을까? 혹시 나도 그런 해결사처럼 열심히 당장 급한 문제만 해결하고 있는 것이 아닌지 걱정되었다. 코드 리뷰는 먼발치에 치워 놓고서 말이다.

코드 리뷰가 답일까?

그렇다면 그때 코드 리뷰를 했더라면 문제가 해결되었을까? 코드 리뷰가 문제를 해결하는 강력한 도구지만 근본 문제를 해결하기에는 부족하다. 해결사가 문제를 제대로 해결하지 못하고 이런 것이 반복되어 프로젝트가 산으로 가는 것에는 다른 원인이 있다. 질문을 할 수 있는 문화가 없었기 때문이다. 문화라는 단어가 불편할 수 있다. 그러면 뭐든 질문할 수 있는 분위기라고 말을 바꿔보자. 분위기란 지금부터 궁금한 점을 질문해 보세요?라고 딱히 말하지 않아도 모두에게 언제나 주어지는 자유로운 질문의 기회를 말한다.

질문 자체는 항상 진지하다

질문은 죄송한 일이 아니다. 질문을 허락받을 필요가 없음에도 우린 머뭇 거린다. 회의할 때나 보고서에 댓글을 적을 때 질문의 개수를 세어보면 생각보다 적은 질문 수에 놀랄 것이다. 질문이 적다면 그 회의에서 예정된 의사 결정은 이미 문제가 없고 그 보고서는 거의 완벽한 것이다. 그리고 모두가 다 잘 이해했다는 뜻이다. 아니면 그 회의나 보고서는 여러 사람의 의견이 필요 없는 것일 수 있다. 기자 회견장에서 질문을 받지 않는 정치인을 상상하면 된다. 어느 기자도 질문을 하지 않는다면 뭔가 이상하지 않은가? 아무것도 궁금하지 않다면 그 기자 회견은 필요 없는 것이다. 말하려는 내용을 메일로 알려주면 된다. 질문이 없다는 건 다 알거나 너무 모르거나 둘 중 하나다. 질문이 없는 곳에 이상한 해결사가 나타날 가능성이 있다. 자신을 해결사라고 생각하지 않을 수도 있다는 것이 더 무섭다.

--

--

JavaScript Developer, https://afrontend.github.io/

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store