회사 동료들과 마지막 식사를 마치고 자리에 되돌아가려고 하니 문득 두려운 마음이 든다. 퇴직하는 마지막 날인데 팀장이 긴급 업무를 또 시키지는 않겠지? 어려운 일은 아니지만 다시 한번 긴급 업무를 도와달라는 말을 들으면 좋게 마무리하고 싶은 나의 심정이 부서질 수 있다는 생각이 들었다. 그래서 자리에 앉지 않고 회사나 구경하자는 생각에 평소에 자주 가지 않는 아래층 사무실로 내려갔다. 8년 다니니까 낯선 층을 다니더라도 부담이 없다. 유유자적 자리에서 눈치 보는 사람들과 아이컨택을 한 번씩 하면서 걸어가고 있다가 이게 무슨 행패인가라는 생각이 들어서 시선을 피하면서 걷는다. 걷다보니 저 멀리 복도에서 신입 개발자와 기술지원을 해주시는 분의 대화하는 소리가 들린다.
“개발자님, 고객사에서 지금 민감한 상황입니다. 문제 일어난 이유와 문제가 해결될 수 있는 예상 시간을 빨리 알려주셔야 해요.”
굉장히 급한 표정으로 기술지원을 해주시는 분이 고객사에 민감한 문제가 발생해서 개발자에게 빨리 대응을 해달라는 요청을 했다.
“급한 것은 알겠지만 아직 원인 파악이 안 되어서 일어난 문제에 대해서 분석을 해봐야 알 수 있어요.”
신입 개발자인데 한참 묵힌 개발자의 대답을 한다. 기술 지원은 답답해하고, 신입 개발자는 황당해한다. 이게 바로 사람들이 말하는 개발자가 커뮤니케이션을 못한다는 사례 중 하나다. '저분은 시간이 지나면 많은 사람들이 말하는 개발자 커뮤니케이션 문제를 해결할 수 있을까?'라는 생각을 하다가 다들 문제라고 생각하는 개발자 커뮤니케이션에 대해서 변명을 해주고 싶어 진다. 커뮤니케이션이라는 부분은 자신이 신경 쓰는 부분이 많지 않고 몰입하는 일을 하지 않을 때는 신경 쓰기 편하다. 상대방의 입장과 현재 상황 등 다양한 고려 요소를 고려해서 상황에 맞는 대화를 하면 된다. 하지만 어떤 신경 써야 할 복잡한 문제로 정신이 침몰되어 있는 상태인 사람에게 서로를 생각해서 대화를 하자고 하면 그런 대화가 될 수 있을까? 개발자들의 작업을 글쓰기로 비유할 수 있다. 실제로 수많은 개발자들은 글쓰기에 자신의 일을 비유한다. 그런데 비유하기 좋은 부분이 글쓰기일 뿐이지 글쓰기보다 훨씬 복잡한 작업이다. 일단 글쓰기도 복잡한 작업이니 글쓰기부터 분석을 시작해보자. 글을 쓰려면 엄청 복잡하게 생각을 하고 아이디어를 생각해내야 한다. 잡힐 듯 말듯한 고민을 한참 하면서 쓰고 지우고 반복하면서 초안을 작성하다. 고통스러운 초안을 작성하고 나면 길고 긴 반복된 수정이 시작된다. 어떻게 해야 완벽하다는 정답은 없지만 완벽에 가까울 수 있도록 노력을 해야 한다.
개발자도 똑같다. 요청한 작업을 처리하기 위해서는 많은 가정과 지식을 나열해놓고 어떻게 해결해야 최선의 해결인지 고민한다. 그리고 그런 생각이 어느 정도 잡히면 컴퓨터가 알아들을 수 있게 글쓰기를 시작한다. 처음에는 컴퓨터만을 고려하면서 문제를 제거하기 위해 시작하지만 내가 작업한 내용을 다른 개발자들도 같이 공유하고 작업해야 하기 때문에 같이 작업할 개발자들이 알아들을 수 있고 원활한 작업을 할 수 있도록 정답은 없지만 완벽에 가깝게 글쓰기를 진행한다. 한 번에 다양한 컴퓨터 환경과 다양한 개발자들을 다 맞춰주는 것은 불가능한 일이므로 작업을 하면서 핑계를 만들어야 한다. 내가 이렇게 글을 쓴 이유는 이러한 핑계 때문이다. 이러한 핑계를 안 만들고 작업하면 다른 개발자들을 납득시킬 수가 없어서 다시 글을 써야 한다. 이런 부분도 힘들지만 프로그램은 글과 달라서 해줘야 할 일이 더 많다. 글은 작성이 완료되고 나면 혹여나 불완전한 상태여도 마무리할 수 있지만 프로그램은 작성이 완료되고 나면 완전해야만 한다. 따라서 작성만으로는 완전할 수 없기 때문에 수많은 검증을 하게 되고 그 완벽해지는 과정에 개발자는 지속적으로 신경을 쓰고 책임을 져야 한다. 보통 사람들은 살아가면서 실수 없이 완벽하게 일을 해야 하는 경우가 얼마나 있을까? 그리고 완벽할 수 없는 결과물을 완벽하게 하기 위해 책임을 몇 번이나 지고 갈까? 이런 개발의 특성 때문에 개발자를 장인이라고 부르거나 스스로를 장인이라고 생각하는 사람도 있다. 이런 사람들에게 다가가서 당장의 단순한 문제만 제거하려는 사람이 커뮤니케이션을 하려고 하니 얼마나 원활한 커뮤니케이션이 되겠는가?
개발자가 아닌 사람들은 급한 상황에서는 문제의 근본적인 수정을 원하지 않는다. 단순히 현상적으로 문제가 빠르게 수정되길 더 바란다. 그래야 고객사에게 걱정을 하지 않아도 된다고 전달할 수 있고 신뢰를 얻을 수 있기 때문이다. 개발자는 보이는 문제의 근본 해결을 원한다. 지금 보이는 문제를 대충 해결하면 다시 큰 문제로 되돌아와서 책임을 져야 하고 보이는 문제를 대충 해결하는 개발자로 보일 수 있기 때문이다.
위에서 일어난 개발자 커뮤니케이션 문제의 해결책은 개발자가 문제를 우회하여 빠르게 해결할 수 있는 부분을 가이드해주고 나중에 근본적인 문제를 해결해주면 된다. 대화에서도 빠르게 해결할 수 있는 우회 방법을 기준으로 일정과 해결 시간을 알려줬으면 대화는 만족스럽게 끝났을 것이다. 그러면 보통의 개발자들은 왜 이렇게 대화를 하지 못했을까? 개발자의 입장에서 다시 표현하면 식칼 장인과 식칼을 고쳐달라고 말하는 손님으로 비유할 수 있어 보인다. 손님이 식칼 손잡이의 느낌이 이전과 같지 않다고 가지고 왔다. 손님이 말하는 손잡이의 느낌이 무엇인지는 모르겠지만 장인은 손잡이를 열심히 고치기 시작한다. 한참 몰입해서 고치려고 하는데 손님이 독촉을 한다.
“어떤 부분이 문제예요? 식칼을 언제부터 쓸 수 있어요?”
장인은 묵묵히 기다리라고 말하고 또 몰입해서 고친다. 10분쯤 지났는데 다시 손님이 물어본다.
“금방 고쳐질까요? 저녁 준비를 해야 해서 빨리 고쳐져야 해요!”
장인은 고민에 빠진다. 이 손님의 상황을 빨리 해결해주려면 창고에 있는 실패 했다고 생각했던 식칼의 날만 갈아서 빌려주고 내일 오라고 하면 된다. 그런데 이렇게 해결하면 높은 확률로 손님들이 오래된 식칼을 안 가져와서 자신이 찾으러 가야 하고 당당하지 않은 작품을 손님에게 보여줘야 한다. 또한 실패한 식칼의 날을 가는 시간 안에 현재 식칼이 고쳐지지 않을까라는 생각도 하게 된다. 장인이 결정할 수 있는 방법은 크게 두 가지다. 첫 번째 대화 방법은 “내가 쓰는 식칼을 쓰려면 조금만 참고 기다려요. 그러면 쓰던 좋은 식칼을 쓸 수 있게 됩니다.”라고 하는 방법이다. 두 번째 대화 방법은 “창고의 식칼 갈아줄 테니 이 식칼을 쓰고 내일 오세요.”라고 하는 방법이다. 손님을 위해서는 두 번째를 선택해야겠지만 그런 커뮤니케이션을 하는 나도 첫 번째를 선택하고 싶다. 개발자가 커뮤니케이션을 잘하려면 만드는 것은 장인처럼 생각하고 만들어진 제품은 장인처럼 생각하면 안 된다. 참 모순적이지만 그렇게 한다 하더라도 잘하는 개발자가 아닌 평범한 개발자로 생각될 뿐이다.
늘 회사를 위해 제품을 위해 올바르다고 생각되는 관점에서 일했었는데 마지막 날이라도 개발자의 관점에서 열심히 변명을 해보니 속이 후련하다. 흔히 우리들은 일을 하다가 잘못된 부분을 발견하면 비난하기 바쁘다. 그런데 일부러 잘못되게 하고 싶었던 사람이 있을까? 그렇게 한 작업이 그 당시에 최선은 아니었을까?