유저를 생각하는 개발
회사에서 만드는 제품은 개발자들의 자기 만족만을 위해 개발되지 않기 때문에 당연하지만 모든 개발자들은 제품 뒤의 유저를 생각하는 개발을 해야한다고 생각합니다. 흔히 유저 경험은 디자이너가 만들어간다고 생각하지만 저는 개발자도 큰 영향을 미친다고 생각합니다. 또한 스타트업이라면 적은 인원으로 높은 만족을 주어야하기 때문에 개발자의 역할 역시도 더 커질 수 밖에 없다고 생각합니다.
버즈니 모아리포트팀에서 새롭게 서비스를 만들어가는 과정은 유저에 대해 더 생각해보는 기회가 되었습니다. 모아리포트팀에서는 부족한 인력 때문에 풀스택 개발을 하게 되었는데요, 이 팀에서 제품과 백오피스 모두 개발해보는 경험을 가졌습니다. 제품을 개발하면서 팀의 디자이너 동료와 함께 더 나은 유저 경험을 제공하기 위한 디자인을 고민했으며, 백오피스 프로젝트를 하면서 단순히 기능 개발에서 멈추지 않고 나름대로 좋은 유저 경험을 제공하기 위해 노력했습니다. 특히 백오피스는 유저의 빠른 피드백을 받고 바로 수정하는 사이클을 가질 수 있어서 유저를 생각하는 개발 능력을 키우는데 큰 도움이 되었던 것 같습니다.
커뮤니케이션
회사는 서로 다른 능력을 가진 여러 사람들이 모여서 더 큰 가치를 만들어 내야하기 때문에 개발만 잘하는 개발자보다 커뮤니케이션을 잘하는 개발자가 더 중요하다고 생각합니다.
저는 버즈니에서 매출 데이터 수집을 담당하면서 제휴팀 동료와 함께 커뮤니케이션을 해야할 일이 많았습니다. 대부분의 커뮤니케이션은 매출 미수집 기간의 재수집 요청 등 프로젝트의 운영에 관한 이야기였습니다. 하지만 종종 기존 시스템을 변경해야하는 이슈가 있었고, 어떤 문제인지, 언제까지 해결이 가능한지에 대해 공지를 해야할 때가 있었습니다. 저는 커뮤니케이션을 활발히 하기 위해 slack 채널을 이용해서 비개발자의 입장에서 알기 쉽도록 신경쓰며 주기적으로 해당 이슈에 대해 공유했습니다. 결과적으로 제가 버즈니를 나오면서 제휴팀 담당 동료로부터 커뮤니케이션이 편했다고 DM을 받으며 큰 보람을 느꼈습니다.
Why?
일을 "왜"하는지는 가장 기초적이고도 중요하지만 어쩌면 가장 잘 놓치는 부분이 아닐까요? 제품을 만드는 동안에 오버엔지니어링을 피하기 위해서, 유저에게 가장 좋은 경험을 제공하기 위해서, 유지보수하기 쉬운 코드를 작성하기 위해서 "왜" 이 도구를 사용했는지, "왜" 이런 구조로 만들었는지, …, "왜"는 제품 개발 주기 전체에서 고민해야할 부분인 것 같습니다.
버즈니에서 데이터 엔지니어로 일하는 동안 담당했던 일 중 하나는 매출 수집 시스템의 개선 프로젝트입니다. 당시 신입 개발자였던 저는 왜 이런 구조로 개선이 돼야하는지, 다른 대안은 없는지를 고민하지 않았고, 개선 방향성을 가지고 PT를 하면서 팀장님으로부터 많은 교훈을 얻었습니다. 이 교훈은 이후의 저에게 많은 것을 가져다 주었습니다. 어떤 일을 하면서 왜 선택했고, 더 나은 대안은 없는지 열심히 확인하게 되었고, 이 과정에서 많은 낭비를 막았다고 생각합니다.