개발자들이 느끼는 기획자와의 소통 부담

갈등이 있을땐 양쪽말을 다 들어봐야 한다

기획자 여러분들이 이 글을 읽고있다는 것은 개발자와 업무하며 갈등을 겪고 있거나 겪지 않기 위해서일 것이라고 생각한다. 기획자 여러분들이 짜증나는 이유들에 대해서는 2장에서 깊게 다룰 예정이다. 이 장에서는 개발자들의 입장을 들어보고 이해해보려는 시도를 하고 있다.

갈등이 있다면 항상 양측의 이야기를 들어볼 이유가 있다. 특히나 우리가 설득해야 할 대상인 개발자들이 기획자들과 소통하기를 부담스러워 하는 이유를 알아보려고 한다. 후술한 그들의 포인트들을 소거해 준다면 그들의 방어적인 태도를 많이 줄일 수 있다고 생각한다.

개발자들이 기획자들과 소통하며 짜증나는 나름의 이유들이 분명 존재한다. 그들의 속마음엔 ‘이거 지난번에 설명했는데 또 설명해야 되나?’ 라든지, ‘얼마나 자세하게 설명해줘야 하는거야..?’ 식의 마음이 떠오르는 일이 잦다. 우리 프로덕트를 발전시켜서 회사도 발전하고, 내 커리어도 발전시켜야 하는데 매번 안된다는 이야기만 하는 악역을 자처하는것도 결코 기분좋은 일이 아니다.

기술적으로 설명하는것은 생각보다 어려운 일이다. 필자는 개발자 출신으로 기획조직에서 일하며 비개발자 동료들을 대상으로 자주 그들이 어려워하는 기술들에 대해 설명하는 시간을 가져왔다. 여기서 맨 처음 부딛히는 어려운점은 어디까지 모르는지 예측이 불가능하다는 점이다.

기술적 설명의 난이도를 조절하는 것은 마치 물의 온도를 맞추는 것과 같다. 너무 차갑게(기초적으로) 설명하면 핵심을 전달하지 못하고, 너무 뜨겁게(전문적으로) 설명하면 상대방이 받아들이지 못한다. 게다가 청자의 이해도에 따라 적정 온도가 계속 달라진다.

예를 들어 “이 기능은 캐시를 써서 구현했어요”라고 하면 어떤 기획자는 “네?“라고 할 것이고, 다른 기획자는 “아, 성능 때문에 그렇게 하신 거죠?“라고 할 것이다. 전자에게는 캐시가 무엇인지부터 설명해야 하고, 후자에게는 왜 이 상황에서 캐시가 필요한지를 설명해야 한다. 매번 상대방의 이해도를 가늠하며 설명 수준을 조절해야 하는 것이다.

기술 용어를 쓰는 것도 큰 고민거리다. 정확한 의미 전달을 위해서는 기술 용어를 써야 하지만, 그러면 소통이 단절된다. 반대로 쉬운 말로 풀어서 설명하면 정확성이 떨어진다. “데이터베이스의 인덱스가 없어서 느립니다”라는 말을 “책의 목차가 없어서 찾기가 오래 걸리는 것처럼요”라고 비유하면, 또 다른 오해를 낳을 수 있다.

더 큰 문제는 이런 설명을 반복해야 한다는 점이다. “이전에 말씀드렸던 것처럼…“이라는 말로 시작하는 대화가 늘어날수록 개발자의 목소리에는 피로감이 묻어난다. 특히 기술적 제약사항에 대해 설명할 때가 그렇다. “이건 보안상의 이유로 안 됩니다”라고 세 번째 설명할 때면, 개발자의 인내심은 바닥을 보이기 시작한다.

예측할 수 없는 요구사항도 개발자들에게는 큰 부담이다. “비슷한 기능 있잖아요, 그거랑 똑같이 만들어주세요”로 시작하는 대화는 개발자들을 긴장시킨다. 겉보기에 비슷해 보이는 기능이라도 내부적으로는 전혀 다른 구조를 가질 수 있기 때문이다. 더구나 이런 요청 뒤에는 보통 숨은 요구사항들이 따라오기 마련이다.

특히 모호한 요구사항은 개발자들을 더욱 불안하게 만든다. “좀 더 자연스럽게 만들어주세요”, “사용자가 불편하지 않게 해주세요”와 같은 추상적인 요청은 해석의 여지가 너무 많다. 개발자 입장에서는 이런 모호한 요구사항이 나중에 “이런 뜻이 아니었는데…“라는 말과 함께 재작업으로 이어질 것을 걱정하게 된다.

기술적 문제를 설명하는 것도 큰 도전이다. 기술 부채나 성능 이슈는 당장 눈에 보이는 문제가 아니라서 설명하기가 더욱 까다롭다. “지금은 괜찮아 보이지만, 나중에 문제가 될 수 있어요”라는 말은 종종 기우로 치부되곤 한다. 보안 문제도 마찬가지다. 눈에 보이지 않는 위험을 설명하는 것은 마치 보이지 않는 괴물의 존재를 증명하는 것만큼이나 어렵다.

이러한 상황에서 가장 힘든 것은 책임과 권한의 불균형이다. 기술적 결정은 개발자가 하지만, 그 결과에 대한 책임은 종종 개발자에게 전가된다. “왜 이렇게 오래 걸리나요?“라는 질문에 기술적 제약을 설명해도, “다른 회사는 다 하던데…“라는 반응을 마주하게 된다. 개발자의 전문성이 인정받지 못하는 순간이다.

결국 이러한 상황들이 반복되면서 개발자들은 점점 더 방어적인 태도를 취하게 된다. “안됩니다”라는 말 뒤로 숨거나, 최소한의 설명으로 상황을 마무리하려 한다. 잦은 기획 변경으로 인한 불신이 쌓이고, 기술적 제약을 이해받지 못할 때의 상실감이 커지면서, 소통 자체를 꺼리게 되는 것이다.

이는 당장의 소통 부담을 줄일 수 있을지 모르지만, 장기적으로는 개발자와 기획자 모두에게 도움이 되지 않는다. 소통이 줄어들수록 서로에 대한 이해도 줄어들고, 결국 프로덕트의 품질에도 영향을 미치게 되기 때문이다. 특히 개발자의 전문성이 제대로 인정받지 못하는 환경에서는 이러한 악순환이 더욱 깊어진다.

이러한 악순환을 끊기 위해서는 양쪽 모두의 노력이 필요하다. 개발자는 방어적인 태도에서 벗어나 좀 더 열린 자세로 소통하려 노력해야 하고, 기획자는 개발자들의 이러한 부담을 이해하고 좀 더 명확하고 구체적인 방식으로 소통하려 노력해야 한다. 무엇보다 서로의 전문성을 인정하고 존중하는 문화가 필요하다. 그래야만 진정한 의미의 협업이 가능하고, 더 나은 프로덕트를 만들어낼 수 있을 것이다.