개발자와 어떻게 협업하면 좋을까?
개발자도 '같은 편'입니다.
상대를 진심으로 존중하는 마음이 중요하다는 사실은 대부분 공감하지만, 실제로 업무 현장에서 막상 실천으로 옮기기는 것은 생각보다 쉽지 않을 때가 있는 것 같습니다. 특히 서로의 역할과 업무가 다른 사람들이 함께 일하다 보면, 각자의 목표와 사정에만 집중하다 보니 존중하는 태도를 놓치고 소통하는 경우가 적지 않은 것 같습니다.
이러한 현상은 여러 직무 간 협업에서 두루 나타나지만, 특히 개발자와 비개발자 간에 업무 특성과 전문 분야가 크게 달라 더 빈번한 갈등이 생기는 것 같습니다. 개발자는 기술적인 복잡성을 해결하는 데 집중하고, 비개발자는 사용자 편의와 비즈니스 요구에 초점을 맞추는 일이 많기 때문입니다. 이처럼 서로 다른 관점과 우선순위가 부딪히면, 의사소통 문제로 협업이 원활하지 않을 때가 종종 있습니다.
하지만, 회사에서 진행되는 프로젝트나 업무는 결코 혼자만의 힘으로 완성되지 않습니다. 여러 분야의 구성원들이 서로의 역량을 인정하고 협력할 때 더 높은 수준의 결과물을 만들어 낼 수 있다고 생각합니다.
존중하는 태도는 단지 예의가 아니라, 공동의 목표를 향해 함께 나아가는 이들에게 실질적인 동기부여를 제공한다고 믿습니다. 서로의 전문성과 능력을 인정하고, 협업할 수 있는 동료들이 있음에 감사하는 마음을 가지면 사소한 갈등이 생겨도 해결책을 함께 찾아가는 분위기가 형성됩니다. 상대방 또한 더 큰 열정을 가지고 프로젝트의 이익을 위해 몰입할 가능성이 커집니다.
특히 개발자와 함께 일하는 직군에서는, 종종 개발자를 '내가 요청한 기능을 만들어 주는 사람'으로만 바라보는 경우가 생깁니다. 하지만 이보다는 '함께 가치를 구현하는 파트너'라는 인식을 가질 때 더 좋은 결과물이 나온다고 생각합니다. 개발자도 프로덕트를 개선하기 위해 노력하는 팀원이며, 기획자의 요청을 거부하려고만 하는 것이 아니라 더 나은 결과물을 위해 임하고 있습니다. 이러한 사실을 기억하면 조금 더 상호 존중에 기반한 의사소통이 수월해 질 것 같습니다.
모두가 즐겁게 일하는 환경을 만들 수 있다고 믿습니다.업무 현장에서 종종 들었던 몇 가지 말 표현을 떠올려 보았습니다. 무심코 했던 말 한 마디가 개발자의 동기부여를 떨어뜨리거나 대화를 단절시키는 상황이 생기곤 합니다. 이럴 때는 어떻게 표현하면 좋을지 고민해 보았습니다. 혹시 다른 관점이나 경험담, 생각이 있다면 공유해 주시면 좋겠습니다.
서로 다른 입장으로 논의할 때,
❌ “네. 다 알겠는데, 일단 해주세요."
이 표현은 상대방의 이야기를 듣는 듯하면서도 결국 자신의 요구만 밀어붙인다는 느낌을 줄 수 있습니다. 개발자는 “내 의견은 존중받지 못하고 있구나”라고 생각해, 점차 마음을 닫게 됩니다. 그 결과 업무를 형식적으로 처리하거나 협력 의지를 잃을 수도 있습니다.
>> 대안: 먼저 경청한 뒤, 이해하려고 노력, “네, 이해했습니다." + "그런데 이 부분은 이렇게 해결해 보는 건 어떨까요?” 함께 문제를 파악하려고 노력하고 다양한 방안을 열어 두는 쪽이 훨씬 긍정적입니다.
❌ “이거 간단하게 할 수 있는 거니까 해주세요.”
겉보기에 사소해 보여도 내부 로직이 복잡하거나 다른 시스템과 연결된 경우, 예상 이외의 시간이 들 수 있습니다. 또, 개발의 난이도를 개발자가 아닌 다른 사람이 임의로 판단해버리면 개발자의 노력과 역량이 저평가되고 있다는 인상을 줄 수 있습니다.
>> 대안: “이러이러한 이유로 수정이 필요합니다. 처리해 주실 수 있나요?” 이때 요청하는 업무의 복잡성이나 난이도에 대해 평가하고 언급하지 않고 요청사항만 명확하게 전달하는 것이 좋다고 생각합니다.
❌ “왜 이렇게 오래 걸리는 거예요? 전에 다른 개발자는 빨리해 줬어요.”
개발 요건마다 환경과 조건이 다르며, 예상치 못한 문제들도 언제든 발생할 수 있습니다. “전에 다른 사람은 빨리했는데”라는 비교는 비난처럼 들려, 감정만 상하게 만들 뿐 실제 업무 속도 개선에는 큰 도움이 되지 않는 것 같습니다.
만약 작업이 지연되어 답답하다면, 어려운 부분이 무엇인지 함께 파악해 보거나, PM이라면 문제 해결에 도움을 줄 수 있는 방법을 찾아보는 편이 좋은 것 같습니다. 필요하다면 애초에 업무 기한(due date)을 설정해 두는 것도 도움이 됩니다.
>> 대안 : “이번 작업에 어려운 부분이 있나요? 혹시 어떤 어려움을 겪고 있는지 알려주실 수 있을까요?”
❌ “다른 회사들은 이런 기술은 다 사용하던데 우리는 대체 왜 못하는 거죠?”
회사의 환경, 인프라, 자원은 제각각이고, 기술을 구현하는 데 필요한 작업 범위도 다를 수 있습니다. 단순 비교로 들리면, 상대방은 “우리 사정을 전혀 고려하지 않는구나”라는 생각에 부담만 커질 수 있습니다.
>> 대안: “이 기술이 괜찮아 보이는데, 우리 프로젝트에도 적용할 수 있나요? 도입하려면 어떤 준비가 필요한지 알려주실 수 있을까요?"라고 묻는 편이 훨씬 존중하는 태도로 느껴집니다.
❌ "왜 이렇게 만들어 놓으신 거죠?”
현재 보기에는 비효율적인 구조일지라도, 과거에는 그것이 최선의 선택이었을 수 있습니다. 무작정 “잘못됐다”고 지적하기보다는, 당시의 배경을 이해하고 현재 상황에 맞는 개선책을 함께 모색하는 태도가 필요합니다.
>> 대안: “당시에 어떤 상황이나 이유가 있었는지 궁금합니다. 지금 기준에서 더 좋은 방법을 찾아보고자 합니다."
결국 존중이란, 상대방을 단순히 “내 일을 대신해 주는 사람”으로 보지 않고, 전문성을 갖춘 동료이자 함께 결과물을 만들어 갈 파트너로 대하는 데서 시작되는 것 같습니다. 이를 위해서는 작은 표현 한 마디라도 신경 쓰고, 개발자의 입장을 물어보거나, 업무 목적과 배경을 명확히 알려 주는 것이 큰 도움이 될 수 있습니다. 개발자도 나와 같은 목표를 위해 노력하는 동료라는 사실을 염두하고 배려하는 태도가 자리잡으면, 자연스럽게 갈등은 줄어들고 업무 효율과 동기는 오히려 높아질 것이라고 생각합니다.
이상주의자처럼 들릴 수도 있지만, 모두가 소중한 시간을 할애해서 일하는 일터에서 일하는 만큼, 이왕이면 서로 조금 더 존중하고 협력하여 즐겁고 효율적으로 일할 수 있는 환경을 만들어 나가면 좋겠습니다. :) 많은 개발자와 비개발자가 서로 협력하여 즐겁고 효율적으로 높은 품질의 서비스를 만들어 내길 희망합니다.
