개발자와의 커뮤니케이션이 당황스러웠던 이유

IT 기업에 처음 발을 들인 문과 출신 홍보담당자에게 개발은 무척 생소하고도 흥미로운 직군이었다. 나뭇잎 캐노피 밑에서 일하는 모습도, 후드티를 입은 자유로움도 신기했지만 가장 강렬한 기억은 개발자와의 미팅이다. 기획, 영업 등 다른 부서와의 커뮤니케이션이라고 해서 쉬운 것은 아니지만, 서로 같은 페이지에 있다는 것만큼 의심하지 않았다. 하지만 개발 부서와의 커뮤니케이션은 물음표의 연속이었다. 서로가 서로를 보며 고개를 갸우뚱하는 가운데, 생각의 차이를 이해하고 효과적인 소통 방식을 찾기까지는 조금 시간이 걸렸다.

재미있는 것은 챗GPT에게 개발자와의 커뮤니케이션에 대해 묻자 내가 겪었던 고민을 그대로 답했다는 점이다. 개발자와 비개발자간 소통의 오류가 그만큼 빈번하면서도 전형적인 것이다. 개발자와의 효과적인 커뮤니케이션 방법에 대한 챗GPT와의 대화를 실제 사례와 엮어봄으로써 소통의 오류와 극복 방법에 대해 생각해보고자 한다.

챗GPT: “기술 용어와 개념에 대한 기본적 이해가 뒷받침되어야 아이디어를 정확하게 전달하고 개발자들의 반응을 잘 이해할 수 있어.”

개발자와의 커뮤니케이션 오류는 가장 먼저 이해 수준의 차이에서 시작된다. 난생처음 들어보는 용어나 개념이 개발자들에게는 기초적이고 당연한 것이기 때문이다. 단순한 예로, 웹사이트에 링크되어 있는 파일 교체에 대해 물어봤을 때 “아, 그건 그냥 AWS 들어가서 S3에서 교체하시면 돼요.” 라는 답을 들은 적이 있다. 1) AWS 계정으로 로그인해 2) S3가 무엇인지 알고 3) 파일을 교체할 수 있다는 생각에서 나온 대답이다.

그러나 나는 1) AWS 계정과 비밀번호가 있어도 IAM 사용자와 루트 사용자의 개념조차 알지 못해 로그인 자체가 어려웠으며 2) S3가 스토리지라는 건 간신히 알고 있었지만 3) 어렵고 낯선 UI 앞에서 파일을 교체하는 것에는 실패했다. 이러한 소통 오류를 해결하기 위한 방법은 두 가지다. 업무에 필요한 기본적인 용어나 개념은 알아두어야 한다는 것, 그리고 이해하지 못했을 때는 그 순간을 놓치지 말고 빠르게 얘기해 이해의 차이를 줄여야 한다는 것이다.

이와 관련해, 챗GPT는 개발자에게 “모든 사람이 기술 용어에 친숙한 것은 아니라는 것을 기억하고, 다른 부서의 동료에게 개념, 과정, 이슈 등을 설명할 때 비기술 용어를 사용해 봐”라고 조언한다. 이렇게 ‘눈높이 소통’을 하는 개발자와의 협업은 대개 수월하다. 물론 개발자의 입장에서는 부가적인 설명을 하는 과정이 다소 번거롭게 느껴질 수는 있으나, 결과적으로 같은 생각을 공유하고 효율적으로 업무를 하기 위해서는 꼭 필요할 것이다.

챗GPT: “개발자가 요구사항을 정확하게 코딩할 수 있도록 명확하고 구체적인 커뮤니케이션이 필요해.”

모든 커뮤니케이션에 있어 명확성과 구체성이 중요하지만, 개발자와의 커뮤니케이션에 있어서는 한 번 더 신경 쓰는 것이 좋다. 특히 기능이나 서비스의 구현에 있어 설명이나 요청사항이 조금이라도 모호해 생각의 차이가 있을 경우, 이를 구체화하지 않고 유야무야 넘어간다면 개발자는 일부를 추측해 작업할 수밖에 없고, 기대와는 다른 결과물을 든 채 회의실에 다시 앉게 될 것이다.

‘프로모션 페이지에 DB 수집 버튼을 만들어주세요’라는 요구사항을 떠올려보자. 단순한 요구사항처럼 보일지라도 다음과 같은 과정을 거쳐 구체화할 수 있다.

• 버튼의 색깔과 모양과 크기와 위치는 어떠한가?
• 랜딩 페이지는 팝업으로 처리할 것인가, 새 탭에서 나타나게 할 것인가?
• 네이버 폼이나 구글 폼을 연동할 것인가, 자체 페이지에서 처리할 것인가?
• 수집할 항목은 무엇인가?
• 전화번호 유효성 검사나 봇 차단 기능을 필요로 하는가?
• 개인정보 수집 동의 관련 문구가 있는가?
• 있다면 어떤 방식으로 보여줄 것인가?
• DB 입력 후 어떤 화면을 보여줄 것인가?
• 입력된 DB는 어디에 어떻게 저장할 것인가?

이렇듯 모든 단계를 검토한 후 명확하고 구체적으로 요청해야만 개발자의 불필요한 고민이나 작업에 소요되는 시간을 줄이고, 동시에 나의 요청사항을 최대한 정확하게 구현한 결과물을 빠르게 받아볼 수 있다.

챗GPT: “프로젝트나 업무의 배경과 맥락을 설명하면 개발자들은 목적을 더 잘 이해하고 그에 맞는 결정을 할 수 있을 거야.”

개발자와의 커뮤니케이션이 낯설고 어려울지라도, 협업을 하는 이상 ‘원팀’이라고 생각하며 충분한 정보를 공유하는 것이 좋다. 특히 ‘이것을 왜 요청하게 되었는지’에 대한 설명은 무엇보다 중요하다. 바로 위에서 예로 들었던 ‘프로모션 페이지 내 DB 수집 버튼 생성’라는 요구사항을 생각해보자. ‘DB 수집 버튼이 필요하니 만들어주세요’라는 설명에는 맥락이 생략되어 있다. 대신에 업무를 요청하게 된 배경과 기대 효과를 말한다면 어떨까?

“△△△ 제품 홍보와 잠재 고객 확보를 위해 프로모션을 진행하게 됐습니다. 관심사가 일치하는 사람과 웹사이트 방문자에게 00일 동안 배너 광고를 띄우고, 00명의 DB를 확보하는 게 목적이에요. 스타벅스 기프티콘 0개를 경품으로 걸어서 더 많은 참여를 유도할 예정이고, 프로모션을 통해 확보한 DB를 활용해 △△△ 제품 웨비나 초대 메일을 발송하려고 해요.”

같은 업무라 해도 DB 수집 버튼을 ‘그냥’ 만드는 사람과 ‘효과적인 프로모션 및 DB 확보를 위해 만드는 사람’ 사이에는 분명한 차이가 있다. 보다 많은 정보를 제공할수록 목적에 충실한 결과물이 나올 것이고, 때로는 개발자로부터 더 좋은 제안이 나올 수 있다. 업무의 난이도가 높을수록, 더 많은 공수를 투입해야 할수록 이러한 차이는 더욱 크고 선명해질 것이다.

반드시 직접적인 개발 업무에만 국한되는 이야기는 아니다. 개발자와 함께 고객 등 외부인을 만나야 할 수도 있고, 브로슈어 등 참고자료를 만들어야 하는 경우도 있다. 개발에 대한 전문적인 설명 대신, 고객이나 독자를 설득하기 위한 기술적 트렌드, 중요성 등을 압축해 제시해야 하는 상황이다. 이러한 맥락을 충분히 설명하지 않는다면 당연히 개발자는 개발 관점에서 자신의 지식과 기술을 풀어낼 수밖에 없다. 배경과 맥락 등을 사전에 충분히 논의하고 공유해야 개발자 역시 목적을 파악하고 적절하게 참여할 수 있다.

마치며

이 글을 쓰며 개발자의 성향이나 소통에 대한 많은 농담을 떠올렸다. 재미로 소비되는 면이 강하긴 하지만, 가끔은 커뮤니케이션의 실패 원인을 개발자에만 돌리는 것 같다는 생각도 든다. 물론 나처럼 뼛속까지 문과인 사람에게 개발자와의 첫 커뮤니케이션은 당황스럽다. 하지만 소통의 기본이 이해와 경청, 공감이라는 점을 생각했을 때, 과연 개발이라는 업무의 특성에 대해 충분히 생각하고 이해하며 소통에 임했는지 돌아보게 된다. 서로에 대한 이해가 뒷받침된다면 소통은 유연하고 원활해지기 마련이다. 이러한 기본으로부터 출발한다면 개발자와의 커뮤니케이션은 한결 매끄러워질 것이다.

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.