비즈니스

개발자들과 소통이 힘들어요

[별별SOS] 59. 비협조에 방어적, 일방적인 소통으로 고민돼요

2023. 05. 03 (수) 12:13 | 최종 업데이트 2023. 09. 15 (금) 13:02
직장인으로서의 삶을 살다보면 별별 일들이 다 있죠. 퇴근하고 혼술 한 잔, 운동이나 명상 10분에 훌훌 털어낼 수 있는 일이 있나 하면, 편히 쉬어야 할 주말까지 주먹을 불끈 쥐게 하는 일들도 있습니다.

직장생활을 하면서 해결하기 어려운 고민이 있나요? 혼자 판단하기 어려워서, 다른 직장인들의 생각은 어떤지 조언을 들어보고 싶나요? <컴퍼니 타임스>에게 별별 SOS를 보내주세요. <컴퍼니 타임스>의 에디터들이 직장인들에게 대신 물어보고, 더 나은 직장생활을 위한 방향을 함께 고민합니다.
전산 직렬 직원 분들과 같이 일하는 게 힘들어서 고민이에요. 비협조적이고 방어적이거든요. 프로그램을 수정하거나 개발이 꼭 필요한 상황이어서 말을 하면, 다 듣지도 않고 바빠서 못한다는 말부터 나와요.

최대한 자세히 설명을 해도 데이터로 이야기하라고 하고, 설명을 해도 전산 용어로만 해서 소통이 힘들어요. 데이터 검토 요청을 하면 자료에 코드만 한 바닥 써서 줘요. 설명도 없이요. 그래도 일을 같이 해야 하다 보니 어떻게든 소통해서 일하고 싶은데 어떻게 해야 좋을까요?
⭐10+년차 백엔드개발자
#프로이직러 
#JPHS '디테일리스트' 유형 (JPHS 테스트가 궁금하면 ▶여기◀) 
#Z세대와 조금 멀리 있는 M세대


개발자들은 어둠(?) 속에서 각개전투로 일하는 분들이 많은데요. 그렇다 보니 소통으로 본의 아닌 어려움을 별별이님께 드린 것 같아서 개발자로서 대신 먼저 사과드릴게요.

방어적인 개발자는 ‘비협조적인 개발자’라는 오해를 자주 받아요. 잘 숙지돼있지 않은 코드 영역인데 수정했다가 잘못해서 버그나 오류가 나는 걸 극도로 두려워하는 경향이 있거든요. 특히 외주업체가 만들어둔 코드가 많은 경우, 이에 대한 수정 요청이 생기면 방어적으로 답변할 확률이 더 높고요.

"단순한 화면 변경이지만, 코드 상황에 따라선 아파트 전체를 뽑아서 옆으로 1cm 이동시키는 것과 같은 작업이 될 수도 있다"는 말이 있을 정도죠. 그냥 보기엔 간단해 보여도, 그걸 위해 눈에 보이지 않는 곳에서 손대야 할 것들이 어마어마하게 많을 수 있거든요. 그래서 답답하다고 느끼실 수도 있어요. 

반면 "꼼꼼한 덕분에 운영능력이 안정적"인 장점도 있다고 말씀드리고 싶어요. 그렇다고 모든 걸 이해해주셨으면 좋겠다는 말씀은 드리고 싶지 않아요. 방어적으로 대응하는 분들은 결국 자신만의 프레임에 갇혀있어서 응용력이 부족한 걸 수도 있거든요. 때문에 이런 분들을 다룰 수 있는 선임 개발자가 있다면, 커뮤니케이션할 때 더 도움되실 것 같아요.

전산용어로만 소통해서 이해가 어려우신 부분에 대해 말씀드리면, 별별이님께서 이해될 때까지 붙잡고 개발자에게 물어봐 주시면 좋겠어요. IT에 대해 모르는 분들 입장에서 전산용어가 매우 어렵다는 것에 저도 동의하거든요.

모르셔서 물어봤는데 알려주길 거부한다면, 개발자 입장에서 볼 때 근무태만이라고 생각해요. 그땐 상사 분이 계시다면 어떤 어려움을 겪고 계신지 고충상담하시길 추천드려요. 협업해야 하는데 상대방이 벽을 단단하게 치고 있으면 그건 상사들이 해결해줘야 하는 거니까요. 아무쪼록 문제가 잘 해결되셨으면 좋겠습니다.
⭐10+년 차 에디터
#평점 2점대 회사 여럿 경험한 직장인
#JPHS 애널리스트 유형  (JPHS 테스트가 궁금하면 ▶여기◀) 
#Z세대와 조금 멀리 있는 M세대


저도 비슷한 경험을 해 봤는데요. 처음엔 '왜 저러시지? 왜 저렇게 무조건 안 된다고 되실까? 일하기 싫은건가?' 싶어서 화도 났는데, 가만히 생각해보니 이유가 있을 것 같더라고요. 소통을 하면서 지켜보니 제가 겪은 경우는 정말 바빠서였어요.

리소스가 부족하니 회사에서 개발자를 더 채용해야 했던 건데, IT 회사가 아니었던 터라 자리 하나 늘리는 일은 요원해 보였어요. 모든 팀들이 다 수정·개발과 관련된 요청을 하는데, 인력은 부족하니 개발자 분들도 방어적일 수밖에 없었고요. 상대적으로 더 급해보이는 업무를 쳐내기 바빴죠. 각 팀 입장에선 꼭 필요한 일이어도 당장 돈이 되지 않거나, 급하지 않은 건 후순위로 밀렸고요.

결국 내부에서 잘 소통하고, 입장을 이해시키고, 한발씩 물러나서 조금씩 배려하는 것말곤 답이 없었어요. 우선 소통 절차를 바꿨어요. 보다 많은 권한을 갖고 있는 상사에게 요청을 해서 더 윗선에서 해당 건에 대한 협의를 먼저 보도록 했어요. 체급을 맞췄죠. 그렇게 정리가 되니 실무에서 한결 서로 부드럽게 대화할 수 있었어요.

개인적으로는 개발자 분들의 고충을 충분히 알고 있다는 걸 공감하고 표현했어요. 실제로 이해가 가는 부분도 있었고요. 또 아는 만큼 더 잘 이해할 수 있다는 취지로, 제가 이해할 수 있는 선에서 왜 그런 문제가 발생했고, 왜 그렇게 작업이 되는지 간략히라도 설명을 부탁드렸어요.

그랬더니 '처리했다'만으로 끝나던 대화에 '왜'가 추가되면서 오해가 줄고, 이해도가 높아졌고 소통은 한층 더 원활해졌어요. 약간의 기본 IT 지식을 알고 있던 게 조금 도움이 되기도 했고요. 구글 문서나 스프레드시트 등에 오류가 났을 때 원인을 빠르게 파악할 수 있도록 소통한 히스토리도 쌓았죠.

요청사항은 주관적으로 해석될 수 있기 때문에 누가 봐도 오해의 소지가 없도록 시각화해서 전달드렸어요. '이것 저것'처럼 부정확한 대명사 사용을 지양했고요. 특히 '적당히'와 같은 말은 위험했어요.

알아서 잘 딱 깔끔하고 센스있게 적당히 '알잘딱깔센'으로 해결되면 좋겠지만, 버튼 위치 하나 잡는 것, 글자 폰트 수정, 줄바꿈은 몇줄을 할지 하나하나 다 정확히 짚어서 전달하지 않으면 서로 좋다고 여기는 것들이 다르니 어긋날 수밖에 없거든요. 그러면 결국 양쪽 다 일을 두번, 세번하게 되고요.

마지막으로 사적으로 조금 더 가까워질 수 있는 시간을 마련해보시면 좋겠어요. 팀에서 점심 때 밥을 산다든지 하면서 마음을 열 기회를 갖고 고마움도 표현해 보시고요. 말 한 마디로 천냥 빚도 갚는다는 말처럼요. 무엇보다 개인을 위한 게 아니라 모두 회사를 위해 함께하는 일이라는 공감대도 만들어보세요.

뭘 이렇게까지 해야 하나 싶기도 하지만 일이란 게 다 그렇잖아요. 혼자 힘으로 할 수 있는 게 없고, 모두 조금씩 양보하고 협력하면서 해 나가야 하고요. 그렇게 마음을 열려는 노력을 하다 보면 한 단계라도 더 나아간 협업을 해나가실 수 있지 않을까 합니다. 파이팅입니다!
⭐ 7년 차 직장인
#T와 F의 4:6 황금비율을 자랑하는 ENFP
#JPHS '컨트롤타워' 유형   (JPHS 테스트가 궁금하면 ▶여기◀)
#Z세대와 멀지 않은 M세대


개발자와 비개발자는 서로 업무 영역과 스타일, 커뮤니케이션 방식이 판이하게 달라요. '화성에서 온 개발자, 금성에서 온 기획자'라는 말을 절로 실감하게 될 때가 많죠. 저도 개발자와 일하며 협업에 어려움을 느낀 경험이 있는데요.

우선, 개발자 입장에서 생각해보면 좋을 것 같아요. '최대한 자세히 설명을 해도 데이터로 이야기하라고 한다'고요. 정확히 어떤 상황인지는 파악하기 어렵지만, 개발자가 일의 필요성이나 타당성에 대해 납득하기 어려운 부분이 있었던 건 아닐까 싶어요.

기획자는 빠르게 일을 처리해야 하니 '이건 이렇게, 저건 저렇게 해주세요'하는 방식으로 업무를 요청하는 경우가 많은데요. 개발자가 보기에 작업 공수가 지나치게 큰 반면, 일의 필요성과 방향성을 공감하기 어렵다면 난색을 보일 수밖에 없을 것 같아요.

내가 기획한 설계를 상세하게 설명하는 것도 중요하지만, 그에 앞서 작업을 요청하게 된 배경을 납득할 수 있게 전달하는 과정이 꼭 필요하더라고요. 프로그램 개발·수정을 통해 어떤 효과를 기대할 수 있는지 데이터와 가설을 바탕으로 충분히 설명해 주세요. 여기서 포인트는 '내가 원하는 바'를 구구절절 늘어놓는 게 아니라, '개발이 필요한 이유'를 설득해야 한다는 거예요.

이렇게 시간을 들여 기획 배경을 설명하고 설득함으로써 얻을 수 있는 가장 큰 이득은, 개발자가 좀 더 주체적인 마인드로 일을 바라보게 된다는 것인데요. 어떤 맥락에서 개발이 필요한지를 충분히 이해하고 있으니, 개발자가 스스로 작업 방식을 고민해보고 역제안을 주기도 하더라고요. 일의 필요성에 대한 공감대가 형성됐으니, 자연스레 일의 우선순위도 높게 쳐주고요.

개발자가 이해하기 어려운 용어로 설명할 땐, 가장 빠르고 확실하게 해결하는 방법이 있는데요. "무슨 뜻인지 이해하기 어려운데, 좀 더 쉽게 설명해주실 수 있을까요?"라고 솔직하게 얘기하는 거예요. 개발자는 상대방이 어느 정도의 개발 지식을 가졌는지 알 수 없으니, 본인의 말이 얼마나 어렵게 느껴지는지 인지하지 못할 수 있거든요.

비슷한 패턴의 협업을 지속적으로 해야 하는 상황이라면 문서 양식을 만들거나 협업 툴을 활용해 소통하는 방법도 있어요. 어떤 방식으로 피드백을 받을 때 이해가 잘 되는지 샘플을 만들어서 구체적인 예시를 보여줘도 좋고요. 커뮤니케이션만큼 상호 노력이 필요한 일도 없더라고요. 어떻게 소통하는 게 쉽고 정확하며 효율적일지 서로 꾸준히 논의하면서 커뮤니케이션 방식을 개선해 보세요.

더불어, 협업 상대와 업무 외적인 이야기도 가끔 나누시면서 인간관계를 단단하게 다져보세요. 호의가 바탕에 깔린 관계일수록 협업이 한결 수월해지더라고요. 커뮤니케이션 시 답답했던 부분도 조금 더 허심탄회하게 얘기할 수 있게 될 거예요. 소통의 물꼬를 트고 즐거운 마음으로 협업하실 수 있게 되길, 응원합니다!