지난 2년 동안 대학교 졸업부터 취업까지의 과정을 겪으며 다양한 프로젝트들을 진행을 했다. 정말 재미있는 프로젝트도 많이 진행을 했지만, 마냥 좋았던 기억만 있던 것은 아니다. 프로젝트를 진행하면서 능동적으로 참여를 하는 프로젝트가 있는 반면, 나도 모르게 수동적으로 참여를 하게 되었던 프로젝트들이 여럿있다.
내가 왜 프로젝트를 참여하면서 수동적으로 참여를 하게 되었는지, 그리고 지난 프로젝트들에서 어떤 것들을 느꼈는지 돌아보려고 한다. 사실 어떠한 문제를 해결하기 위해 사이드 프로젝트를 진행하고, 이에 즐거움을 느끼기 시작한 것은 불과 1년 정도 밖에 되지 않았다. 그 전에는 사이드 프로젝트는 불과 취업에 대한 수단으로 작용했고, 취업에 대한 불확실함이 있을 때마다 사이드 프로젝트에 대한 나의 관심도 같이 떨어지곤 했다.
사이드 프로젝트가 왜 재미없었을까?
사이드 프로젝트에 싫증이 날 때 쯔음 나 자신에게 계속해서 던지는 질문이다. 처음에는 취업 준비를 목적으로 하는 사이드 프로젝트를 진행하다보니 주제도 잘 모르고 팀에 합류를 한 적이 많다. 전체적인 구조에 대해 이해 조차 하지 못하고 기능들을 만들다보니, 이 기능들은 어디에 쓰이는지 조차 잘 모르고 로봇처럼 의미 없이 만들어내고 있었다. 그러다보니 사이드 프로젝트는 의미 없는 기술에 대한 학습이 되었고 자연스레 재미가 없어졌다.
사이드 프로젝트는 하나의 목표를 위해 공동체가 같이 움직인다. 서비스가 노리고 있는 목표가 무엇인지 제대로 알지 못했고, 방향성을 잃고 프로덕트를 만들어나가면서 "왜 이 기능이 불편할까?", "이 서비스의 타겟층은 누굴까?" 등 다양한 질문을 던지지 못했던 것 같다. 그러면서 자연스레 사이드 프로젝트에 대한 나만의 공백기를 만들어냈다. 동시에 사이드 프로젝트 팀도 자연스레 해체가 되었다.
너무 불편해서 서비스를 만들어보았다.
학교 졸업을 앞두고 내가 몸담아 왔던 멋쟁이사자처럼과의 작별을 위해 마지막으로 운영 활동을 했던 적이 있다. 운영을 하면서 매 기수마다 회원 모집을 해야했던 순간이 있었는데 구글 폼으로 지원서를 받고, 수 많은 지원서를 종이로 인쇄해 서류때마다 크로스 체킹을 하면서 확인을 했다. 구글 폼은 정말 단순히 폼 양식만을 제공하고, 합 · 불 여부와 메일 처리 등 상당히 불편한 점들이 많았다.
너무 불편했다, 왜 우리는 이런 불편한 점들을 참고 계속 모집을 했을까. 합격자들에게 서류 합격 메일을 이메일 하나 하나를 보면서 타이핑을 해야하고, 서류 검토를 위해 수 많은 종이들을 인쇄해 확인을 해야한다는 과정 자체가 너무 비효율적으로 처리가 되고 있었다. 그래서 4주라는 기간을 가지고 리쿠르팅 서비스 하나를 열심히 만들기 시작했다. 불편함을 해결하려는 생각 밖에 없었기 때문에, 기획이나 기능에 대한 부분은 자연스레 불편함을 통해 나오게 되었고 빠르게 빠르게 진행이 될 수 있었다.
합 · 불 여부를 모바일이나 PC에서 손쉽게 볼 수 있고, 버튼 하나면 자동으로 모두에게 메일이 전송이 되고, 채널톡 서비스를 통해 불편한 점들을 실시간으로 톡 형태로 주고받는다. 서비스를 만들고 실제로 운영해보며 당연하면서 너무나도 큰 부분을 깨닫게 되었다.
"문제에 대해 공감하며 문제의 근본적인 원인을 해결해보는 사람이 되어보자"
문제를 해결하는 사람이 되어보자
사실 문제를 해결하기 위해 팀의 목표에 공감을 한다는 말은 어쩌면 쉽게 느껴질 수도 있지만, 문제를 해결하고자 하는 사람의 배경까지 이해하기에는 정말 많은 시간이 걸린다. 프로젝트를 구상하고 이끄는 사람이 아니라면, 프로젝트의 100%를 공감하기 위해서는 정말 많은 시간이 소요된다는 말이다.
나는 그 동안 프로덕트를 만들고 내 이력에 도움이 되는 프로덕트만을 만들어왔다. 이 때문에 열심히 개발을 했던 기억들은 존재하지만 프로덕트에 대한 좋은 기억이 많이 존재하지 않는다. 하지만 문제를 해결할 수 있는 프로덕트를 내가 기획하고 만드는 과정을 겪어보니 프로젝트에서 "공감" 이라는 감정(동시에 행동)은 정말 중요한 것이라고 깨달았다.
실제로 현재 재직중인 기업에서 입사 초반에 워드프레스를 통해 블로그 초기 구축을 하라는 업무 지시 사항이 내려왔다. 예전의 나라면 로봇처럼 이유를 묻지도 않고 따지지도 않고 무작정 프로젝트에 뛰어들었을 것이다. 하지만 나도 똑같이 문제를 풀어나가려는 사람이 되고자 했고, 프로젝트를 진행하기 위해 궁금한 점들을 물어보았다. "왜 프로젝트 초기 구축은 워드프레스를 이용하나요?", "지금 현재 블로그가 잘 운영되고 있는데, 왜 리뉴얼 프로젝트를 진행하나요?" 등등 다양한 질문들을 쉴새없이 했다.
프로젝트에 공감을 하고, 문제를 해결하는 사람이 되고자 프로젝트도 능동적으로 참여하게 되었다. 이렇게 계속 열심히 참여를 하면서 자연스레 프로덕트에 대한 오너쉽이라는 감정이 새롭게 태어났다. "이 버튼을 조금 더 노출하면 사용자가 더 편하지 않을까?", "이 레이아웃은 조금 불편할 것 같은데.." 등등 다양한 의견들이 나로부터 능동적으로 나오게 되었고, 운이 좋게 블로그 구축 및 전반적인 설계와 운영을 내가 맡게 되었다.
프로젝트의 전반적인 구성을 알게 되면서 프로덕트를 만들어나가는 과정 하나 하나가 모두 재미있었다. 또 다시 프로젝트에서 공감이라는 것은 정말 중요하다는 것을 깨닫게 되었다. 결과도 나름 좋게 나왔다, 초기에는 DAU 2000+을 기록하고 있었다면 현재는 DAU 3000+이라는 좋은 성과가 나오면서 문제 해결에 대한 즐거움을 더욱 느낄 수 있었다.
개발자의 오너쉽은 필요가 아닌 필수이다.
프로젝트를 진행하면서 문제를 해결하기 위한 고민이 녹아든 코드가 아닌, 단순 기능 구현만을 위한 코드를 작성하는 코더들이 많이 보인다. 프로그래머라는 직업은 어떤 문제를 기술적으로 해결하는 사람이다. 그렇기 때문에 문제에 대한 정의 과정에도 함께 해야하고, 프로젝트의 전반적인 상황을 모두 잘 알고있어야 한다고 생각한다. 예전에 작성했던 글(개발자는 내가 만드는 제품에 애정을 가져야한다)의 일부를 인용하자면 가끔 구현 된 후 오랜 기간이 지난 기능임에도 불구하고, 버그들이 늦게 발견되는 경우가 종종 있다. 이에 따른 이유는 그 아무도 프로덕트를 많이 사용을 해보지 않았다는 말이 되기도 한다.
프로덕트를 많이 사용해보고, 프로덕트 자체에 애정을 가져야한다. 이를 위해서 개발자의 프로젝트에 대한 오너쉽은 선택 사항이 아닌 필수인 덕목으로 가져야한다. 파면 팔수록 개발자라는 직업은 무궁무진한 것들이 정말 많고, 배울 점들이 너무 많다. 앞으로 연차가 쌓이며 다양한 경험들을 하겠지만 이제 곧 2년차에 가까워지며 느꼈던 생각과 경험들을 글에 녹여보았다. 2년차를 보내고, 3년차를 보내면서 어떤 생각과 다양한 경험들을 할 수 있을지 정말 기대가 된다. 마지막으로 가볍지만, 되게 인상깊게 공감되었던 링크드인 게시글을 마무리로 포스팅을 마무리해보려고 한다.
댓글