개발자는 개발만 잘하면 된다?
개발 외에 잘하면 좋을 네 가지
개발자는 산출물을 만드는 사람이다. 기획자도, 디자이너도 그러하다.
각자의 역할이 나누어져 있지만, 직군에 관계없이 협업을 해야 하며, 그러기 위해서는 개발만 잘해서는 안 된다. ‘개발만 잘하면 되겠지’라는 식의 마인드를 가지고 있다면, 당장 버려야 한다.
이 글에서는 개발 외에 개발자가 잘해야 할 것들에 대해 이야기해보고자 한다.
커뮤니케이션이 잘되는 개발자
고민많은 개발자들 설문 결과 중 일부 발췌일반 개발자들을 대상으로 한 설문 결과이다. 커뮤니케이션에 어려움을 겪고 있는 사람들이 많았으며, 개발자가 커뮤니케이션 하기 가장 어려워하는 사람은 아이러니하게도 ‘개발자’였다. 커뮤니케이션 능력이 중요한 이유다.
위에 언급한 것처럼, 기획자, 개발자, 디자이너 등의 다양한 직군이 모여 하나의 산출물을 만든다. 많은 사람들이 많은 논의(라 쓰고 회의라 읽는다)를 거치면서 하나의 지향점을 가지게 되는데, 서비스를 구현하는 개발자가 커뮤니케이션이 잘 안된다면?
제발 나의 말을 들어줘데드라인이 임박해오는 시점에 잘못된 산출물을 내놓는 것은 나의 신뢰도를 떨어트리는 일이다. 개발 일정이 늘어나는 것은 물론, 최악의 경우 아키텍처를 뜯어고쳐야 하는 상황까지 오게 된다면 중요한 서비스 릴리즈 일정도 지연될 수 있다. 한 번의 실수는 있을 수 있지만, 매번 커뮤니케이션이 잘 안 되는 사람과 일하고 싶어 하는 사람들은 없을 것이다. 아래 세 가지 사항을 유의하면 좀 더 대화가 잘 통하는 개발자가 될 수 있을 것이다.
명확하지 않은 부분은 시간을 들여서라도 명확하게 만들어야 한다.
명확하지 않은 것은 오해와 곡해를 낳게 되고, 정확하지 않은 산출물을 만들 가능성이 높아진다.
스펙에 대해 커뮤니케이션을 할 때에는 개발자 입장에서만 생각하지 않아야 한다.
무조건 방어적인 태도로 나와서도 안된다. 서비스에 진정으로 좋은 방향이 무엇인지 고려해보고 주장해야 한다.
나의 논리를 알기 쉽게 설명할 수 있어야 한다.
예를 들어, 기획자가 제안하는 기능이 기술적으로 어려움을 설명해야 할 때, 안된다고만 하면 주장에 대한 설득력이 떨어진다. 청자의 배경지식에 맞춰서 설명하고, 필요에 따라 각종 도구(그림, 모식도 등)를 적극적으로 활용하면 좋다. 개발자들과 이야기할 때도 마찬가지이며, 새로운 기술 도입에 대한 근거를 제시할 때에 도입하게 된 배경, 고민했던 문제점, 내린 결론을 이야기하면 다른 사람에게 내 생각을 전하기 쉬워진다.
가치 있는 서비스를 만드는 개발자
가치 있는 서비스를 만든다는 것은 서비스에 대한 책임과 소신이며, 개발하고자 하는 기능이 정말 서비스에 필요한 기능인지 재고하고, 사용하기 편리하게 개발할 수 있도록 힘을 쏟고, 서비스에 대한 센스를 탑재하는 것이다.
모든 서비스는 목적이 있으며, 그 목적에 가장 부합하도록 설계되어야 한다. 하나의 서비스를 만들기 위해 많은 사람들과 이야기를 하게 되는데, 이때 목적에 대한 이해가 낮거나, 이해하지 못한 채로 개발을 한다면, 엉뚱한 서비스를 만들게 될 수도 있다.
팀원들의 피드백을 자주 받는다.
내가 올바른 방향으로 개발하고 있는지, 내가 하는 일이 어떻게 서비스에 도움이 되는지, 이러한 기능이 추가된 배경은 무엇인지 확인해볼 수 있다.
비슷한 방향을 가진 다른 서비스가 있다면 벤치마킹을 해보거나, 공유가 된 자료를 찾아보는 방향으로 의사결정의 과정을 따라가다 보면 많은 센스를 얻을 수 있다. 비슷한 목적을 수행하는 서비스, 물건, 사람 등을 관찰하여 목적에 대한 본질을 파악하는 것이 중요하다.
사용자의 입장에서 고려해보자.
서비스를 사용하는 말단 사용자(end-user)의 입장에서 ‘이 프로그램이 무슨 가치를 제공해주는가?’에 대한 물음을 높은 수준으로 고민해봐야 한다. 다만, ‘내가 말단 사용자라면 당연히 이렇게 하겠지’는 지양해야 한다. ‘나’를 말단 사용자로 착각 하기는 쉽지만 서비스를 개발하는 사람이라 정말 말단 사용자의 입장에서 바라보기는 힘들기 때문이다. 내가 가진 배경지식과 다른 사람의 배경지식은 다를 수 있는 것처럼 말이다.
하여 말단 사용자의 시각으로 보는 것이 어렵다면, 적어도 기획자, 디자이너, 사업가의 입장에서 서비스를 바라보면 조금 더 센서블 하고 커뮤니케이션도 원활하게 할 수 있을 것이다. 개발자의 시각으로만 바라보게 되면 자칫 프로그래밍하기 쉽게만 만들어질 수도 있다.
Documentation을 작성하는 개발자
문서화에 대한 중요도는 아무리 강조해도 모자라다. 기획자와 개발자 간, 개발자와 개발자 간 스펙을 명확하게 협의할 때에 아주 중요한 역할을 한다. 우리가 커뮤니케이션에 힘을 쏟는 이유는 ‘시간 낭비를 하지 않고, 서로가 원하는 공통의 지향점을 향해 서비스를 잘 만들어나가기 위한 수단’ 이기 때문인데, 이를 정리해놓은 것이 documentation이고, 잘 정리된 documentation은 직군 간 오해를 줄이기에도, 새로 합류한 팀원이 히스토리를 파악하고 업무에 빠르게 적응하는데도 도움이 된다.
이렇게 중요한 스펙 문서는 어떻게 작성해야 하는가? 원문 ‘On Writing Product Spec’을 잘 번역해놓은 글이 있어서 하단에 링크를 해놓았다.
이렇게 작성된 스펙 문서는 한번 작성하고 끝이 아니다. 개발하는 내내 지속적으로 확인해야 한다. 개념이 정확하지 않거나, 추가적인 논의가 필요한 부분이 생긴다면 빠르게 논의를 해야 한다. 변경에 대한 리스크는 프로젝트 초기에 발견할수록 비용이 적게 소모된다. 또한 구두로 협의한 내용을 모든 구성원이 기억하기엔 무리가 있으므로, 변경된 내용들이 문서에 잘 반영되도록 힘써야 한다. 조직 내에서 ‘이 문서는 항상 업데이트되어 있고, 신뢰할 수 있는 자료다.’라는 인식이 생긴다면 협업하기 좋은 환경을 구성하는 첫걸음이 된 것이다. 스펙 문서는 서로 간의 약속이지만, 오류를 내포할 수도 있고, 더 나은 대안이 존재할 수도 있다. 궁금하거나 이해가 가지 않는 것은 꼭 물어보자.
프로덕트 스펙 문서 작성법 ( https://brunch.co.kr/@hj-kang/2 )
나를 어필할 수 있는 개발자
내가 이룬 성과에 대해 성취감을 느끼고 인정받는 것은 중요하다. 성취감은 내가 하는 일을 보다 열정적으로 만들어 준다. 나를 뽐내는 시간은 주로 평가 시즌, 이직 시즌에 발생한다. 갑작스럽게 나를 어필하라고 하면 잘 생각나지 않는다. 미리미리 준비해놓는 것이 좋다. A 양의 경우, 쿠폰 시스템을 설계하고 개발했다. 몇 천만 건을 발행하고, 발행 속도를 18배 개선하는 등의 과정에서 과정에서 고난과 역경이 존재했다. 이런 일들이 쌓여 몇 달이 지나, 혹은 n 년이 지나 누군가가 물어봤다고 하면 잘 대답할 수 있을까? (잘 대답할 수 있는 사람들은.. 부럽다.) 우리 같은 사람들은 아니다.
일정 주기 혹은 성과 단위로 회고하고, 비교할 때는 무엇을 이룩했는지에 대한 전, 후 차이를 기술한다.
기존 대비 n % 상승 등 정량적 지표들을 같이 기술하면 성과를 측정하는 데 도움이 될 수 있다.
긴 주기의 성과보고의 경우(1년 성과 등)에는 보다 짧은 기간 동안의 성과들을 미리미리 취합해 놓는다.
1주일 동안 한 일을 정리하고, 정리된 것들을 모아 다시 1 달의 성과를 정리하고, 정리된 것들을 토대로 1년의 성과를 정리한다면 내가 그동안 무엇을 했는지 고민하는 시간을 줄일 수 있다. 이 과정에서는 잘 정리된 documentation이 도움이 될 수도 있다.
이번 글에서는 커뮤니케이션에 대한 내용이 상당 부분을 차지했지만, 구체적인 방법이나 사례는 제시되지 않았다. 부족한 부분은 “기획자/개발자와 개발자의 사이, 힘들지 않으신가요?” 편에서 더 자세히 다뤄보려고 한다.
개선의 시작은 문제를 인지하는데서부터 시작된다. 잘 하고 있다면 스스로에게 칭찬하는 시간을 가지고, 내게 필요한 부분들은 부단한 노력을 통해 개선해 나가면 된다.
나 혼자만 막막한 길을 가고 있는 것이 아니다. 분명히 나와 비슷한 고민을 하는 사람들이 있다. 우리는 지금 고민하고 있고, 고민의 깊이만큼 성장하고 있다.
