개발자가 기획자를 불신하게 되는 과정
처음부터 그랬던건 아니다
주변에 개발자때문에 힘들어하는 동료나 친구들을 보면 그들의 방어적인 태도를 지적하곤 한다. 그들이 처음부터 그런 태도를 보이진 않았을 것이다. 차츰 신뢰가 깨지고 불신하게 되면서 행동으로 나타나는 것이라고 생각한다. 개발자를 포함해 많은 사람들이 새로운 사람들을 만나게 되면 어느정도 기대를 하기 마련이다. 이전 조직에서 느꼈던 부분들을 개선하고 새로운 조직에서 함께 발전하고 멋진 프로덕트를 만들어내는 희망적인 미래를 그린다. 이 생각이 어떻게 불신에 이르게 되는지 짚어보고 현상을 예방하는 방법을 알아보려고 한다.
기획이 자주 변경되는 경험
신뢰가 깨지는 가장 큰 이유는 약속을 지키지 않기 때문이다. 용인되는 선을 넘어 약속을 어기는 일을 반복하는것은 불신으로 가는 지름길이다. 그런 면에서 기획이 자주 변경되는 것은 개발자-기획자간의 신뢰구축에 안 좋은 영향을 미친다.
보통 여러 문서들로 서로 소통하게 되는데 여기에는 어느정도 내용이 '확정'되었다는 의미를 담고 있다. 꼭 문서가 아니더라도 보통 구두라도 확정되었다는 이야기를 듣고 개발자들은 업무에 돌입하게 되는데, 이 내용이 얼마 지나지 않아 변경되는 일을 자주 겪으면 개발자는 기획자를 신뢰하기 어렵다. 기획서의 요구사항이 개발하는 도중에 변경되면 개발자 입장에선 요청을 수용해 적용을 해도 문제, 안해도 문제인 면이 있다. 수용한다면 기존 설계를 버려야 하는 문제가 있고, 받아들이지 않고 기존 설계대로 완성한다고 해도 결국엔 재작업을 할수 도 있다는 예상이 되기 때문이다.
이런 상황이 반복되다 보면 개발자들은 기획이 확정되었다는 말을 신뢰하지 않게 된다. "이번에도 어차피 바뀔 텐데..."라는 생각에 설계에 공을 들이지 않게 되거나, 아예 기획이 완벽하게 확정될 때까지 개발을 미루는 경우도 생긴다. 이는 결국 제품의 품질 저하나 개발 일정 지연으로 이어진다.
특히 문제가 되는 것은 "사소한 수정"이라는 표현이다. 기획자 입장에서는 정말 작은 변경일 수 있지만, 개발적인 측면에서는 전혀 다른 이야기일 수 있다. 버튼 하나의 위치를 바꾸는 것이 전체 화면 구조의 변경으로 이어질 수 있고, 간단한 텍스트 수정이 데이터 구조 전체의 수정을 필요로 할 수도 있다.
이번만이 쌓이는 과정
기획자로 일하며 개발자에게 요청할때 다양한 이유로 인해 "이번 한번만 해주시면 안될까요?"라는 말을 하게 된다. 예상하겠지만 이런식의 소통은 당연히 '이번만'이 아니기때문에 신뢰를 쌓는데 도움이 되지 않는다. 개인적으로 '이번만' 찬스를 사용했다면 충분한 감사와 성의표시를 하고 그 사람과의 '이번만' 상태를 0으로 리셋하는것이 필요하다고 생각한다. 하지만 이 장에서는 지켜지지 않는 이번만 해주세요가 어떤 영향을 주는지 알아본다.
반복되는 예외상황은 예외상황이 아닌 평소상황이라고 봐야한다. 사전에 약속한 절차를 무시하고 이번만 급하게 먼저 처리해야 할 일이 있을 수 있다. 하지만 그런 일이 반복된다면 기존의 프로세스는 의미가 없어진다. 처음에 한두번이야 상황을 봐가면서 요청을 수용할 수 있지만, 반복된다는 것을 깨닫고 나면 방어적인 태도를 취할수 있다고 생각한다.
'이번만'이 쌓이면 프로덕트에도 결코 좋은 영향을 주지 않는다. 임시방편으로 처리된 코드들은 오래 심사숙고한 코드들과 품질면에서 차이가 날 수 밖에 없다. 오랜기간 이런 코드들이 쌓이면 코드 가독성이 떨어지고 이는 오래 정리하지 않고 쌓이기만 한 창고처럼 물건을 찾기 어렵고 제 역할을 하기도 어려워진다. 이는 주기적인 리팩토링으로 관리되어야 한다. 하지만 매번 너무 급하니 이번만 해주세요 라고 요청하는 조직에서 리팩토링을 할 여유가 있을리 만무하다. 따라서 개발자는 조직에 회의감을 갖게되고 불신으로 이어지게 된다. 따라서 급한 요청이라도 매번 이번만 해주세요 라고 요청하기 보다 어느정도 기획자의 요청 바구니를 만들어 모아둘 필요가 있다.
전문성을 인정받지 못하는 순간
개발자의 전문성을 존중해 줘야 하는 순간들이 있는데 그 중 우리가 자주 마주하는 순간이 '일정산정'을 할 때이다. 어떤 개발자들은 일정을 과도하게 산정하고 노는것 처럼 보여서 지켜보는 이로 하여금 분노의 씨앗을 만들어 주기도 한다. 하지만 조직에 악영향을 미치는 '가짜 개발자'와 일하는게 아니라면 그들이 본인의 업무에 대해 난이도를 결정하고 일정을 산정하는 것은 존중해줘야 한다고 생각한다.
"다른 개발자들은 며칠 안걸리고 금방 하시던데..." 혹은 "이거는 전에 있던거랑 똑같으니까 그대로 복사 붙여넣기 해서 해주시면 안되요?" 라는 식의 대화는 개발자와의 신뢰를 무너뜨리는 선전포고 같은 말이다. 기획자 여러분들의 경험에 비추어 봤을 때 그런 판단을 하신 것이 이해됩니다. 하지만 개발자마다 가진 역량과 배경지식이 다르고 따라서 처리하는데 소요되는 시간도 다르다. 설령 이번에 일정을 좀 길게 잡았더라도 과하게 산정했다는것을 인지한다면 다음부터는 적절하게 산정할테니 믿어야 한다. 여기서 그들의 전문성을 무시하고 다른사람과 비교를 하는 등 공격을 한다면, 우리의 전문성도 공격받을수 있다는 것을 인지해야 한다.
이 외에 개발자가 성능에 악영향을 줄 수 있다고 경고를 하는 경우가 있다. 또 보안측면에서 우려되는 부분에 대해 이야기를 할 수도 있다. 이때는 기존 기획방향과 상충되는 부분이 있더라도 충분히 듣고 적용해야 할 필요가 있다. 많은 디지털 프로덕트들이 보안이슈나 성능을 고려하지 않아 다음 단계로 넘어가지 못하고 좌절하는 경우가 많기 때문이다.
개발자의 전문성을 무시하는것이 불신으로 가는 지름길인 만큼 반대로 존중을 통해 신뢰를 쌓아가는것이 필요하다.
불신이 쌓이면 협업이 어려워진다. 훌륭한 역량을 가진 사람이라도 신뢰 관계가 무너지면 함께 일하기 힘들어진다. 특히 IT 업계에서 평판은 매우 중요한 자산이다. "저 기획자와는 일하기 힘들다"는 평가는 순식간에 퍼질 수 있고, 이는 향후 협업에도 큰 영향을 미친다.
더 큰 문제는 이렇게 형성된 불신이 조직 전체로 확산될 수 있다는 점이다. 한 명의 기획자로 인해 개발팀 전체가 기획팀에 대해 방어적인 태도를 취하게 될 수 있다. 이는 단순한 업무 비효율을 넘어 조직 문화 자체를 해칠 수 있는 심각한 문제다.
따라서 신뢰 관계 구축은 선택이 아닌 필수다. 약속을 지키고, 상대의 전문성을 인정하며, 투명한 소통을 하는 것은 단순히 개인 간의 관계를 위해서가 아니라, 더 나은 제품을 만들기 위한 기본 조건이다.
결국 우리의 목표는 좋은 제품을 만드는 것이다. 이를 위해서는 기획자와 개발자가 서로를 동등한 파트너로 인정하고, 각자의 전문성을 존중하며 협력해야 한다. 신뢰는 하루아침에 쌓이지 않는다. 하지만 작은 약속부터 하나씩 지켜나가다 보면, 견고한 신뢰 관계를 만들어갈 수 있을 것이다.
