개발자 비개발자 협업 시 소통 오해 줄이는 방법

프로젝트를 진행하다 보면 개발자와 비개발자 간 소통에서 오해가 생기는 일이 잦습니다. 처음에는 어떻게 풀어나가야 할지 막막하기도 했지만, 2년 가까이 직접 부딪히며 몇 가지 경험을 쌓았습니다. 지난 봄, 한 프로젝트에서 기획자와 개발팀 간의 의견 충돌이 심했던 경험을 떠올리면 지금도 아찔합니다. 이 과정에서 배우고 익힌 소통 노하우를 공유하고자 합니다.

 

목차

1. 기술 용어, 왜 자꾸만 꼬이는 걸까

2. 비개발자가 알아야 할 개발 프로세스의 기초

3. 결과물은 똑같은데, 뭐가 다른 건가요

5. 모호함은 오해를 낳는다, 명확한 요구사항 전달법

4. 기대치는 현실과 같을 수 없습니다

6. 비평이 아닌, 발전을 위한 피드백 문화 만들기

개발자와 비개발자의 다른 언어 사용 방식 이해하기

처음 프로젝트를 시작할 때, 개발자와 비개발자 사이에 묘한 거리감이 느껴질 때가 많았습니다. 서로 사용하는 용어도 다르고, 문제점을 바라보는 관점도 달랐죠. 개발자는 기능 구현에 집중하는 반면, 비개발자는 사용자 경험이나 비즈니스 목표 달성을 더 중요하게 생각하는 경향이 있었습니다. 이런 차이 때문에 같은 사안을 두고도 전혀 다른 방향으로 이야기하는 경우가 잦았습니다. 예를 들어, 비개발자가 "이 부분 좀 더 눈에 띄게 해주세요"라고 요청하면, 개발자는 '눈에 띈다'는 것이 구체적으로 어떤 디자인적 요소를 의미하는지 명확히 파악하지 못해 혼란스러워하곤 했습니다. 결국, 수많은 질문과 답변을 주고받고 나서야 비로소 같은 지점에 도달할 수 있었죠. 이런 경험을 여러 번 겪으면서, 서로의 언어와 관점을 이해하는 것이 얼마나 중요한지 깨닫게 되었습니다.

 

개발자들은 추상적인 표현보다는 구체적인 수치나 명확한 논리를 선호합니다. '버그를 최대한 줄여주세요'라는 요청보다는 '특정 기능에서 발생하는 오류 발생률을 0.1% 미만으로 낮춰주세요'와 같은 명확한 목표가 제시될 때 훨씬 효율적으로 움직입니다. 반대로 비개발자들은 사용자가 서비스를 어떻게 느끼고 경험할지에 대한 부분을 더 중요하게 생각하며, 감성적인 부분이나 전체적인 맥락을 설명하는 데 더 익숙합니다. 저 또한 처음에는 이러한 차이를 '소통의 어려움'으로만 여겼지만, 시간을 두고 지켜보니 각자의 전문 분야에서 비롯된 자연스러운 방식임을 알 수 있었습니다.

 

몇 년 전, 한 서비스 개선 작업을 할 때였습니다. 비개발팀에서는 '고객 문의가 많으니 빠르게 해결 방안을 내야 한다'는 입장이었고, 개발팀에서는 '문제가 되는 부분을 정확히 파악해야 정확한 해결책을 제시할 수 있다'는 입장이었습니다. 양측 모두 문제 해결을 원했지만, '무엇이 문제인지'에 대한 정의가 달랐던 것입니다. 결국, 30분 넘게 격렬한 논쟁 끝에, 각 팀이 생각하는 '문제'가 사실은 연결된 하나의 큰 그림 안에 있다는 것을 발견했습니다. 이러한 과정은 매우 비효율적이었지만, 각자의 시각을 존중하고 맞춰나가는 경험은 값진 자산이 되었습니다.

 

한번은 비개발 팀에서 '모바일 환경에서 버튼 클릭이 잘 안 돼요'라는 피드백을 주었습니다. 처음에는 단순한 UI 오류라고 생각했는데, 개발자가 상세하게 묻기 시작하면서 실제로는 여러 복합적인 요인이 작용하고 있다는 것을 알게 되었습니다. 특정 운영체제 버전에서의 렌더링 문제, 네트워크 속도에 따른 로딩 지연, 그리고 사용자의 손가락 움직임 패턴까지 고려해야 하는 상황이었죠. 이러한 디테일을 이해하는 데 상당한 시간이 걸렸지만, 개발자 입장에서 어떤 정보가 필요한지를 파악하는 데 큰 도움이 되었습니다.

 

 

상호 이해는 소통 오해를 줄이는 첫걸음입니다. 상대방의 전문 분야와 사고방식을 인정하는 것부터 시작해야 합니다.

요청 사항 명확하게 전달하는 방법

요청 사항을 명확하게 전달하는 것은 소통 오해를 줄이는 데 매우 중요합니다. 제가 프로젝트를 진행하면서 가장 많이 부딪혔던 부분 중 하나가 바로 '요청의 모호함'이었습니다. 비개발자 입장에서 '사용자 편의성을 높이기 위해'라는 말을 자주 사용하는데, 개발자에게는 이것이 너무 추상적으로 들릴 수 있습니다. 예를 들어, "메인 화면에 있는 검색창을 좀 더 눈에 띄게 해주세요"라고만 요청하면, 개발자는 어떤 부분을 얼마나 강조해야 할지 막막할 수밖에 없습니다. '눈에 띈다'는 것은 디자인적인 부분, 위치, 크기, 색상 등 다양한 요소로 해석될 수 있기 때문입니다.

 

처음에는 이런 부분을 명확하게 설명하는 것이 어렵게 느껴졌습니다. 하지만 시행착오를 거치면서 몇 가지 원칙을 세우게 되었습니다. 첫째, 요청하는 내용을 최대한 구체적인 용어로 표현하려고 노력했습니다. '더 좋아지게'가 아니라, '사용자가 5초 안에 원하는 메뉴를 찾을 수 있도록'과 같이 결과 지향적으로 이야기하는 것이 훨씬 효과적이었습니다. 둘째, 시각적인 자료를 적극적으로 활용했습니다. '이런 느낌으로'라며 디자인 시안이나 참고 이미지, 또는 와이어프레임을 함께 보여주는 것이 말로만 설명하는 것보다 훨씬 명확했습니다. 제가 예전에 했던 프로젝트에서는, '여기를 좀 더 직관적으로 바꿔주세요'라는 요청 대신, 구체적인 사용자 시나리오를 몇 가지 작성해서 개발팀과 공유한 적이 있습니다. 그랬더니 개발자들도 어떤 부분을 개선해야 할지 명확하게 이해하고 더 빠르게 결과물을 낼 수 있었습니다.

 

둘째, 개발자가 요청을 이해하는 데 필요한 정보를 충분히 제공하는 것입니다. 단순히 '이 기능을 추가해주세요'라고 말하기보다, '이 기능이 왜 필요한지', '이 기능이 어떤 문제를 해결해 주는지', '이 기능을 사용할 주요 사용자는 누구인지'와 같은 배경 설명을 덧붙이면 개발자는 기능의 중요성을 더 잘 파악하고 우선순위를 결정하는 데 도움을 받을 수 있습니다. 몇 달 전, 한 기능 구현 요청 시 단순히 '새로운 알림 기능을 만들어 달라'고만 전달했는데, 개발자분께서 '어떤 상황에서 어떤 알림이 가야 사용자들에게 도움이 될까요?'라고 되물었습니다. 그 질문 덕분에 우리가 놓치고 있던 부분들을 발견하고, 오히려 더 유용한 알림 기능을 만들 수 있었습니다.

 

한번은 모바일 앱의 특정 페이지 로딩 속도가 느리다는 피드백이 들어왔습니다. 비개발팀에서는 '빨리빨리'라는 막연한 요구만 반복했습니다. 하지만 개발자 입장에서는 '얼마나 빠르게'인지, '어떤 부분이 느린지'를 알아야 해결이 가능했습니다. 결국, 제가 직접 여러 환경에서 속도를 측정하고, 개발팀과 함께 느린 부분을 분석한 결과, 특정 이미지 파일의 크기 문제와 비효율적인 데이터 로딩 방식이 원인임을 파악할 수 있었습니다. 이때, '무엇이 문제인지'를 구체적으로 파악하고 이를 전달하는 것이 얼마나 중요한지 다시 한번 깨달았습니다.

 

 

모호한 요청은 혼란을 야기합니다. 구체적인 용어, 시각 자료, 배경 설명을 통해 명확한 소통을 시도하세요.

피드백 주고받는 문화 만들기

효과적인 소통은 단순히 요청만 하는 것이 아니라, 피드백을 주고받는 과정에서도 발생합니다. 특히 개발자와 비개발자 협업에서는 이 피드백 문화가 더욱 중요합니다. 제가 처음 현업에 들어왔을 때, 개발팀에서는 자신들이 만든 결과물에 대해 피드백을 요청하는 것을 다소 어색하게 생각하는 분위기였습니다. 결과물이 나오면 그대로 받아들이기를 원한다고 생각했죠. 하지만 제가 몇 번이고 적극적으로 질문하고 의견을 개진하면서, 개발팀에서도 솔직한 피드백이 오히려 더 나은 결과물을 만드는 데 도움이 된다는 것을 알게 되었습니다.

 

서로에게 건설적인 피드백을 주고받기 위해서는 몇 가지 주의할 점이 있습니다. 첫째, 피드백은 '사람'이 아닌 '결과물'에 대해 해야 합니다. 예를 들어 "이 디자인이 마음에 안 들어요"보다는 "이 버튼의 색상이 주변 요소들과 잘 어우러지지 않는 것 같아요"와 같이 구체적인 개선점을 지적하는 것이 훨씬 효과적입니다. 둘째, 피드백을 할 때는 '왜' 그렇게 생각하는지에 대한 이유를 함께 설명하는 것이 중요합니다. 제가 예전에 비개발 팀의 디자인 초안에 대해 '이 부분이 사용자들이 혼란스러워할 것 같다'는 피드백을 준 적이 있었습니다. 그 당시 개발자분은 제가 왜 그렇게 생각하는지 이유를 묻길래, 몇 가지 예상 시나리오를 들며 설명했습니다. 그랬더니 개발자분께서 제 의견을 적극적으로 수용하여 디자인을 수정했고, 실제로 출시 후에 사용자들의 긍정적인 반응을 얻을 수 있었습니다.

 

또한, 피드백을 받을 때는 방어적인 태도를 버리는 것이 중요합니다. 비개발자 입장에서는 개발 결과물에 대해 솔직하게 의견을 말하기 어렵다고 느낄 수도 있습니다. 하지만 개발자들은 자신의 결과물에 대한 객관적인 평가를 통해 배우고 성장합니다. 개발 과정 중 발생한 문제에 대해 솔직하게 공유받았을 때, 저 또한 '이런 문제가 생길 수도 있구나'를 배우고 다음 협업에서 미리 대비할 수 있었습니다. 개발 팀에서 "현재 이 기능은 예상치 못한 기술적인 이슈로 인해 조금 늦어질 것 같습니다"라는 피드백을 받았을 때, 처음에는 답답했지만 그 이유를 명확히 듣고 나니 오히려 다음 계획을 세우는 데 큰 도움이 되었습니다.

 

정기적인 회고 시간을 가지는 것도 피드백 문화를 정착시키는 데 큰 도움이 됩니다. 프로젝트의 특정 단계가 마무리될 때마다 '무엇이 좋았고, 무엇이 개선될 수 있는지'에 대해 솔직하게 이야기하는 자리를 마련하는 것입니다. 한 팀에서 몇 달간 진행한 프로젝트가 끝난 후, 개발자와 비개발자 팀이 모여 진행했던 회고 세션이 있었습니다. 거기서 오고 간 솔직한 피드백 덕분에, 다음 프로젝트에서는 이미 알고 있는 어려움을 미리 대비하고 훨씬 더 원활하게 협업할 수 있었습니다.

 

 

솔직하고 건설적인 피드백은 성장의 밑거름입니다. 결과물에 집중하고, 이유를 설명하며, 열린 마음으로 주고받는 것이 중요합니다.

요구사항 명확화와 배경 지식 공유

개발자와 비개발자, 이 둘 사이에서 프로젝트가 잘 진행되지 않을 때 가장 흔하게 발생하는 문제는 역시 '소통'이었다. 지인들이나 동료들과 이런 이야기를 나눌 때면, 다들 비슷한 경험을 이야기하며 공감대를 형성하곤 했다. 처음에는 그저 '아, 나만 그런 게 아니구나' 싶었는데, 반복해서 듣다 보니 이 또한 정리가 필요하겠다는 생각이 들었다. 무엇이 문제인지, 그리고 어떻게 하면 조금이라도 오해를 줄일 수 있을지 말이다. 각자 처한 환경과 성향이 다르니 완벽한 답은 없겠지만, 여러 경우를 비교하고 직접 겪어본 바를 바탕으로 이야기해보려 한다. 제일 먼저 짚고 넘어가야 할 것은 바로 '요구사항'에 대한 명확한 이해다.

 

비개발자 입장에서는 머릿속에 있는 아이디어나 목표를 명확하게 전달하는 것이 우선이다. 하지만 이 과정에서 '이 정도는 당연히 알겠지' 하는 생각이 발목을 잡을 때가 많다. 반면 개발자는 제시된 요구사항을 구체적인 기능으로 구현해야 하므로, 모호함은 곧 작업의 비효율로 이어진다. 예를 들어, '좀 더 편리하게 만들어줘'라는 말은 개발자에게 너무나 막막한 지시일 수밖에 없다. 어떤 부분이, 어떻게 편리해져야 하는지에 대한 구체적인 근거나 예시가 없기 때문이다. 나는 처음에 이런 추상적인 표현에 혼란을 겪었고, 결과적으로 수정 작업이 몇 번이고 반복된 경험이 있다.

 

반대로 개발자는 자신이 만든 결과물이 왜 그렇게 만들어졌는지, 기술적인 제약 사항이 무엇인지 등을 비개발자에게 이해하기 쉽게 설명해야 할 필요가 있다. 전문 용어를 그대로 사용하는 것은 금물이다. 최근에는 KISA 보호나라 같은 곳에서 보안 관련 정보를 쉽게 풀어 설명하려는 노력도 많이 보였다. 기술적인 배경 지식이 부족한 사람들도 알아들을 수 있도록 비유를 사용하거나, 상황을 단순화해서 설명하는 것이 핵심이다. 한번은 개발팀에서 "API 연동 과정에서 이슈가 있습니다"라고 했을 때, 나는 그게 대체 무엇을 의미하는지 전혀 감을 잡지 못했다. 알고 보니 외부 서비스와 정보를 주고받는 과정에서 문제가 생긴다는 것을, 꽤 많은 시간을 들여서야 겨우 이해할 수 있었다.

협업 도구 활용과 문서화 습관

정해진 규칙 없이 소통하면 감정 싸움으로 번지기 쉽다. 서로 다른 관점에서 바라보기 때문이다. 개발자는 효율성과 기능 구현에 집중하고 싶어 하고, 비개발자는 사용자 경험과 비즈니스 목표 달성을 우선시한다. 이러한 차이를 좁히기 위해서는 공통으로 사용할 수 있는 '협업 도구'가 필수적이다. 단순히 채팅만 하는 것이 아니라, 프로젝트의 진행 상황을 시각적으로 확인할 수 있는 도구들을 적극 활용하는 것이 좋다. 칸반 보드 형태의 툴이나, 태스크 관리 시스템은 누가 무엇을 언제까지 해야 하는지를 명확하게 보여준다.

 

나 역시 처음에는 각자 메신저로 정보를 주고받다가 일이 꼬이는 경험을 자주 했다. 누가 언제 어떤 이야기를 했는지, 중요한 결정 사항이 무엇이었는지 파악하기가 어려웠기 때문이다. 지난 2년간 슬랙이나 노션 같은 도구들을 체계적으로 사용해보니, 대화 기록이 명확하게 남고, 관련된 자료들도 한 곳에 모을 수 있어서 정말 유용했다. 특히 중요한 회의 내용을 정리하고, 담당자와 마감일을 명시하는 문서화 습관은 오해의 소지를 크게 줄여준다. 비록 수고스럽더라도, 논의된 내용은 반드시 문서로 남기는 것이 장기적으로는 시간과 에너지를 아끼는 길이었다.

 

개인정보보호에 대한 중요성이 커지면서, 개인정보보호위원회에서도 관련 규정과 지침을 꾸준히 업데이트하고 있다. 이런 정보들도 사내 협업 도구를 통해 팀원들과 공유하고, 각자의 업무에 어떻게 적용할지를 논의하는 것이 중요하다. 단순히 '규칙'으로만 제시하는 것이 아니라, '왜' 그 규칙이 필요한지, '어떤 문제'를 방지하기 위한 것인지 배경 설명까지 곁들이면 팀원들의 이해도를 높일 수 있다.

기대치 조율과 적극적인 피드백 문화

프로젝트를 진행하다 보면, 현실적인 제약과 이상적인 결과 사이의 괴리가 발생하기 마련이다. 비개발자들은 때로 자신이 상상하는 모습과 실제 구현 가능한 결과물의 차이를 간과하기 쉽다. 반대로 개발자 역시 구현 가능성만 보고 비개발자의 중요한 의견을 놓칠 수도 있다. 이 지점에서 '기대치 조율'은 무엇보다 중요하다. 단순히 '되는 것'과 '안 되는 것'을 넘어, '어떤 것을 하면 이 정도 수준의 결과가 나올 것인지', '비용과 시간을 고려했을 때 최선의 선택은 무엇인지'에 대한 솔직한 논의가 필요하다.

 

처음에는 이런 솔직한 대화가 불편하게 느껴질 수도 있다. 하지만 서로의 입장을 이해하고 현실적인 목표를 설정하면, 나중에 발생할 수 있는 큰 실망감이나 갈등을 예방할 수 있다. 나는 약 50여 명 규모의 팀에서 일했던 경험이 있는데, 이때는 프로젝트 착수 단계부터 개발팀 리더와 비즈니스 기획팀장이 몇 날 며칠을 붙잡고 서로의 입장을 꼼꼼하게 조율했다. 그 덕분에 이후 프로젝트 진행 중에 예상치 못한 문제가 발생했을 때도, 이미 공유된 로드맵 덕분에 큰 혼란 없이 대처할 수 있었다.

 

이와 더불어 '적극적인 피드백 문화'를 만드는 것도 오해를 줄이는 데 크게 기여한다. 좋은 점은 칭찬하고, 개선이 필요한 부분은 솔직하게 이야기하는 분위기가 형성되어야 한다. 물론 이때에도 비난이 아닌 '건설적인' 피드백이 오가야 한다. 어떤 부분이 왜 문제라고 생각하는지, 그리고 어떻게 개선하면 더 좋을지에 대한 구체적인 제안이 함께 제시되어야 한다. 이렇게 쌓이는 긍정적인 피드백과 건설적인 비판들은 결국 팀 전체의 역량을 끌어올리는 밑거름이 된다.

 

결국 개발자와 비개발자의 협업은 기술적인 능력만큼이나 서로에 대한 이해와 존중이 중요하다고 생각한다. 오늘 이야기 나눈 내용들은 여러 번의 시행착오 끝에 얻은 나름의 정리이며, 앞으로도 계속해서 더 나은 방법을 찾아나갈 것이다. 상황에 그래서는 지금 이야기한 부분들도 조금씩 달라질 수 있다는 점을 염두에 두면 좋을 것이다.