[220520] 문제 해결

문제 해결보다 더 어려운 건 사실 문제를 알아차리고 원인을 정확하게 짚어내는 일인 것 같다. 해결을 찾고 시도하는 하기 위해서는 문제 인식이 선행 되어야 하기 때문이다. 어쩌면 진짜 문제가 뭔지 아는 것 자체가 문제 해결의 일부라고 볼 수도 있겠다. 무언가 잘못 되었다고 '느끼는 것', 이 잘못의 원인이 어디에 있는지 더듬더듬 찾는 것, 뭔가 잡히는 것 같을 때 여러 가설들을 세워서 문제가 제거되는지 확인해보는 것; 1년 차 중반까지만 해도 이런 프로세스를 정확히 이해하지 못했던 것 같다.

 

지금 생각해보면 1인분의 몫을 하겠다는 강박과 긴장 속에 눈 앞에 놓인 일들을 수행하기 급급했다. 다른 팀에서 오는 요청에 대해 스스로 한번 검토하거나 고민하는 단계 없이 그저 받아서 해치웠다. 그게 내 역할이라고 생각했고, 다른 팀이 잘한다고 하면 정말 잘하는 줄 알았던, 지금 생각하니 많이 부끄러운 시기이다.

 

아마 개발의 의미와 역할에 대해 진지하게 고민하지 않은 채로 일을 했기 때문이 아닐까 싶다. 당시에도 개발의 목적은 문제 해결에 있다고 생각하긴 했지만, 단순히 눈 앞의 버그, 위치 및 색상 조정, 다른 사람이 문제라고 하는 것 등 ‘문제'의 의미를 협소하고 단편적으로 이해한 상태였다. 주니어라는 처지로 인해 문제를 인식하는 시야를 좁혔던 것 같아 스스로 많이 아쉽다.

 

결국 시간이 지나면서 근본적으로 ‘문제’의 뿌리는 코드 밖에 있다는 점을 느끼게 되었다. 앞서 말한 방식으로 일을 하는 동안 내 작업물이 어떤 결과와 효과를 가져오는지 확인할 수 없어서 나아가는 방향을 가늠할 수 없었고, 코드 안에서 맴도는 듯한 답답함이 자주 찾아왔다. 내가 정말 고민했어야 할 질문들은 처음부터 프로덕트와 유저에서 시작했어야 하지 않나 싶다. 우리 프로덕트와 서비스가 왜 더 많은 유저 수를 모집하지 못하는지, 유저가 이를 이용하면서 어떤 불편함을 느끼는지, 왜 일의 효율성이 나지 않는지 등 이런 것들이야말로 내가 가장 먼저 떠올렸어야 할 문제였고, 나의 역할은 그런 문제들을 다른 팀과 협업하면서 기술적으로 풀어내는 데에 있었다.

 

지금은 문제 인식에 있어서 프로덕트와 유저를 중심에 두고 일을 하려고 한다. 다른 팀에서 여러 요청 사항들이 와도 즉각 눈을 코드로 옮기기 보다 그러한 요청 사항이 결과적으로 프로덕트와 유저에 어떤 영향을 주는지, 임팩트가 얼마나 큰지, 이 요청 사항을 즉각 반영했을 때의 기회 비용은 무엇일지를 먼저 생각하는 편이다. 그리고 필수적으로 최초에 요청한 당사자 혹은 다른 팀원과 이러한 고민과 선택을 커뮤니케이션 하면서 공유하려고 한다. 진심으로 우리가 옳은 방향으로 나아갔으면 싶고, 문제 해결이라는 공통의 기반 위에 있다는 바를 서로 확인함으로써 신뢰를 갖고 지속해서 협업할 수 있다고 생각하기 때문이다.