이렇게 쓰면 개발 못해요.
퇴사일지, 그 첫 번째 이야기
회사를 다니면서 겪은 여러 에피소드들이 있는데,
그중 굉장히 뇌리에 남았던 것을 하나 꺼내볼까 한다.
입사하고, 아직 인턴이었을 시절. 그렇지만 인력난으로 앱 하나를 통째로 책임지고 기획해야 했던 날.
그때까지만 해도 서비스 기획은 책과 인강으로만 배운 게 전부였다.
서비스 기획을 하면 나오는 산출물이 뭔지, 기획서는 어떻게 생겼는지는 알아도 그 산출물을 어떻게 만들고 기획서는 어떻게 써야 하는지를 몰랐었다.
서비스 기획 업무에서는 산출물보다 더 중요한 게 있는데, 바로 커뮤니케이션이다. 그리고 그때의 나는 다른 사람들과 커뮤니케이션하는 방법을 1도 몰랐었다.
나는 이걸 배우러 온 건데, 냅다 정글에서 생존하기로 장르가 바뀌어버리고 만 것이다.
지금 돌이켜 생각해 보면, 나와 같이 합을 맞춰가야 했딘 개발, 디자인, 품질팀이 얼마나 힘들었을지 감히 상상이 되지도 않는다.
왜냐하면 아무것도 모르던 시절이었는데도 그때 개발자분이 많이 화내고, 열받아한 게 눈으로 너무 보였거든. (근데 그만큼 나도 많이 힘들었다. 매일매일 베갯잇을 눈물로 적시며 하루를 잠들 정도로.)
아무튼 천방지축 얼렁뚱땅 엉망진창 하루하루를 보내던 그 시절에 있었던, 어느 날의 에피소드다.
그날은 앱 사용 시간 모니터링 기능을 개선하던 때였다.
기존에는 단순히 앱 사용 시간의 총합을 보여주는 기능이었다면, 이번 개선을 통해서 더 추가적인 정보를 제공하기로 했다.
그래서 결정난 것이 지난주에 사용한 총 시간 평균과 이번 주에 사용한 총 시간 평균을 비교해서, 지난 주 대비 얼마나 더 썼는지, 덜 썼는지에 대한 정보를 제공하는 것이었다.
이때 소소한 우려점이 있었는데, 지난 주에 사용한 시간이 없으면 어떻게 하지?였다.
정보 제공 가능 여부의 문제가 아니라 사용자에게 정말 올바른 정보인가의 초점에서 시작된 이야기였다.
(지난주 데이터가 없게 되면, “이번 주는 지난주에 비해 140시간을 더 썼어요!” 이렇게 표기된다는 건데 이게 얼마나 사용자에게 효용가치가 있을지….)
그래서 협의 끝에 내린 결론은 지난주에 사용한 시간이 없을 경우에는 비교 데이터를 보여주지 않기로 했다. 그렇게 협의된 내용을 바탕으로 기획서에 다음과 같이 작성했다.
지난주에 사용한 시간이 없을 경우, 비교 데이터를 보여주지 않는다.
이렇게 쓴 기획서를 배포하자마자 담당 개발자분께 연락이 왔다.
지난주에 사용한 시간이 없다는 게 무슨 말인가요? 이렇게 쓰면 개발 못해요.
그 말을 듣고 아차, 한 나는 다음과 같이 수정했다.
[AS-IS]
지난주에 사용한 시간이 없을 경우, 비교 데이터를 보여주지 않는다.
[TO-BE]
지난주에 사용한 시간이 0일 경우, 비교 데이터를 보여주지 않는다.
(지난주에 사용한 시간이 0을 초과한 경우에 한해서 비교 데이터를 제공한다)
2년 전에 있던 일임에도 지금도 이날이 생생하게 기억난다.
커뮤니케이션이란 이런 게 아닐까 깨닫게 된 계기였기 때문이다.
“없다”는 것이 갖는 의미가 무엇인가.
“없다”는 것은 어떻게 보면 추상적인 말인데 이러한 추상적인 것을 현실로 구현해야 하는 사람 입장에서 보면 난해하기 그지 짝이 없다.
그리고 ‘없다’는 말에서 0이라는 숫자를 추측할 수는 있지만, 커뮤니케이션에 있어서 추측은 금기와도 같다. 내 생각을 덧입히는 거니까. 그러다가 원래의 의도와 달랐다면?
모르는 것을 처음에 바로잡는 것은 실수를 고치는 일이지만, 더 나중에 발견하게 되면 그건 사고다.
커뮤니케이션이란, 단순히 나의 생각을 전한다고 끝나는 것이 아니라, 정말 잘 이해했는지를 확인하고 그 사이에 오류가 없는지를 몇 번이고 체크하는 것.
그렇게 정보의 갭을 줄여나가 같은 것을 볼 수 있게 하는 것.
이날 이후에 커뮤니케이션을 잘 하게 되었는지는 모르겠다. 그래도 노력했다고 자부한다.
상대의 이야기를 들었을 때, 내 이해와 내 인식이 맞는지를 더블 체크하거나, 무조건 자료로 정리해 정보를 시각화하려고 했다.
그리고 보기에 불편하진 않은지, 어떻게 하면 더 이해하기 쉬울지를 조금 더 열심히 물어보려고 했다.
저 시절에는 사실 질문하는 게 많이 무서웠다. 저 사람이 열심히 설명해줬는데 내가 못알아들으면 어떻게 하지, 내가 못 알아들었다고 저 사람이 뭐라고 하면 어떻게 하지.
그런 불안이 아주 아주 컸다.
지금도 그게 없는 건 아니지만, 그래도 ‘어쩌라고’ 라는 마인드 셋으로 있을 수는 있다. 내가 모르겠다는데 어떻게 할 거야, 뭐 그런 거?
그리고 나중에 알게 된 사실인데, 위의 일화에 등장한 개발자가 화를 냈던 이유가, 내가 경력직으로 입사한 줄 알고 있었는데 경력직이 너무 일을 못해서였다고 하더라.
이후 어찌어찌 신입 + 인턴이라는 것을 알게 된 건지, 내가 잘 모르는 게 생기면 a4용지 한바닥에 달하는 자료를 정리해서 보내주곤 했다. (덕분에 정말 정말 많이 배웠다)
이것처럼 내가 어느 수준까지 이해하고 있는지 상대도 알 필요가 있다는 걸 깨닫기도 했다. 너무 잘한다고 생각하면 나중에 그게 화를 입더라고.
내가 창피한 것보다, 그냥 나중에 일이 커지면 더 처리하기 힘드니까 약간의 면책 느낌으로, 그리고 내 수준 이 정도니까 잘 좀 해달라는 느낌으로 있는 것이 딱 좋다. 정말로.
서로의 정보와 이해 수준을 알고 그걸 바로잡는 것.
앞으로도 잘 새기며 살아가야지. 배운 걸 허투루 쓸 수는 없으니까!
