[데이터조직]비즈니스와 기술 부채에 대한 커뮤니케이션

최근에 자주 사용하는 단어가 있다. 바로 "독박개발"이다. 뭐랄까 개발자는 비즈니스 요구사항을 충분히 이해하고 개발해야 한다. 즉 개발에 대한 지식과 비즈니스에 대한 지식을 모두 인지하고 있어야 한다. 하지만 상대적으로 비즈니스는 개발에 대해서 자세히 알 필요가 없다. 단지 개발을 배려할 뿐이다.

이러한 괴리감은 사실 비즈니스가 지속가능할 때 프로덕트가 존재할 수 있기 때문에 수긍하고 업무를 하고 있다. 그리고 종종 이런 비즈니스의 요구사항을 먼저 해결하면서 생기는 것중의 하나가 바로 기술부채이다.

기술부채는 최적의 솔루션 대신 최선의 솔루션을 택함으로써 이후 추가적으로 재작업을 해야 하는 경우를 비용적인 관점에서 정의한 용어이다. 최적의 솔루션을 사용하지 못한 이유는 여러 이유가 있을 수 있겠으나, 오늘 이야기하는 기술부채는 주로 비즈니스 요구사항에 따른 목표를 더 우선시하는 과정에서 발생하는 경우에 국한되어 있다.

프로덕트팀의 리더로서 일을 하다보면 이런 기술을 로드맵상에서 지속해서 관리할 필요가 있다. 특히 시니어라면 의도적으로 이 기술부채를 생성하는 경우도 있다. 회계에서 자본은 자산과 부채, 즉 자기비용과 타인비용의 결합으로 타인비용을 통해 비즈니스의 성장을 꾀할 수 있음을 보여준다. 이는 기술부채에도 동일하게 적용되어, 더 큰 개발을 할 때 기술부채를 의도적으로 생성하기도 한다.

하지만 기술부채 역시 재무상의 부채와 동일하게 놔두고 관리하지 않을 경우 지속해서 발목을 잡으면서 압박으로 존재할 수 있기 때문에 관리가 필요하다. 그런데 비즈니스가 이 부채에 대해서 알까? 대부분 모른다.

따라서 리더는 기술부채를 지속해서 수면위로 띄우고 비즈니스 요구사항과 우선순위를 비교해나가면서 기술부채를 적절한 시점에 해소할 필요가 있다. 그리고 이를 위한 커뮤니케이션을 프로덕트팀 뿐만 아니라 사업팀과도 해야할 필요가 있다.

그런데 앞서 "독박개발이라는 말을 한 것이 기억나는가? 기술부채를 아무리 설명해줘도 사업팀은 이해 못할 가능성이 있다. 따라서 리더는 기술부채를 보다 사업팀이 이해할 수 있는 용어로 바꿔서 관리를 해야 한다. 즉 기술의 언어와 사업의 언어를 모두 구사하며 통번역해서 관리해야 한다는 것이다. 찰떡같은 비유를 적절히 사용해야할 시점이다.

HBR의 "정상에 오른 리더들의 커뮤니케이션 전략"에서도 적절한 비유와 짧은 문장 등을 예씨로 들며 리더의 커뮤니케이션 능력을 강조했고 그 예로써 제프베이조스의 서술형 줄글(narrative structured memos)기반 회의 진행 정책을 언급하였다. 서술형으로 글을 작성하다보면 구술형태의 커뮤니케이션 보다 더 체계적으로 글을 쓰게 되는 경향이 있다.

이러한 부분 때문에 프로덕트팀의 리더는 커뮤니케이션에 있어서 높은 난이도의 수련이 의지적으로 이루어져야 한다. 글로도 써보고 말로도 해보는 과정을 통해서 지속해서 숙달해야 한다는 것이다. 이런 것을 신경쓰지 않는다면, 구성원에게는 로드맵의 불확실성과 개인의 커리어에 대한 불안감이 증폭되어 소속감은 떨어지고 더 큰 실패로 이어질 것이다.

각설하고, 비즈니스와 기술부채의 적절한 관리는 따라서 프로덕트 팀 리더의 중요한 업무 중 하나이다.