“개발자분, 이거 가능할까요?”

이 질문에 “음… 기술적으로 복잡한데요"라고 답한 적이 있다면, 당신은 이미 ‘소통 못하는 개발자’ 클리셰에 한 발 걸쳐 있을지도 모릅니다.

저는 9년차 프론트엔드 개발자입니다. 그동안 수없이 들었어요. “개발자분들은 왜 설명을 어렵게 해요?” “개발팀과는 이야기가 안 통해요.” 심지어 개발자들 끼리도 “개발자들이라 말을 잘 못해"라는 농담을 자주 봅니다.

그런데 정말 그럴까요? 매일 동료와 코드 리뷰하고, 기술 블로그 글을 쓰고, 온라인에서 서로의 질문에 답하고, 여러 스터디를 참여하는 개발자들이 정말 소통을 못하는 걸까요?

이 글은 개발자와 다른 직군 사이에 있는 보이지 않는 벽에 대한 이야기입니다. 그 벽이 실은 기술의 문제가 아니라, 작은 오해들이 쌓여 만들어진 것임을 이야기하려 합니다.

개발자들은 정말 소통을 못할까?

개발자의 하루를 한번 봅시다.

오전 10시, 데일리 미팅에서 어제 한 일과 오늘 할 일을 공유합니다.
오후 2시, 동료가 올린 코드를 리뷰하며 한 줄 한 줄 코멘트를 답니다. “이 부분은 이렇게 바꾸면 더 읽기 쉬울 것 같아요."
오후 4시, 주니어 개발자와 30분간 페어 프로그래밍하며 개념을 설명합니다.

이건 소통이 아닐까요?

개발자는 사실 하루 종일 소통합니다. 다만 그 소통이 코드라는 언어로, 깃헙이라는 도구에서, 개발자끼리 이루어질 뿐입니다. 저만 해도 매주 최소 10개 이상의 코드 리뷰를 하고, 팀 내 문서를 작성하고, 다른 개발자가 작성한 기술 문서를 읽으며 학습합니다.

문제는 개발자가 소통을 못하는 게 아닙니다. 서로 다른 맥락에서 다른 언어로 소통하는 데 익숙한 게 문제입니다. 대부분 동상이몽을 하는 경우죠.

왜 ‘개발자는 소통 못한다’는 오해가 생겼을까

이 오해는 양쪽에서 만들어집니다.

개발자: 우리는 종종 이렇게 생각합니다. “이 사람은 기술을 모르니까 이해 못할 거야.”, “이 사람은 IT나 개발을 잘 모르네” 그래서 설명을 포기하거나, 지나치게 기술적으로 설명합니다. 마치 전문성이라는 방패를 들고 있는 것처럼요.

다른 직군: 기획자나 디자이너는 개발자에게 질문하면 돌아오는 “그건 어려워요”, “시간이 많이 걸려요"라는 답에 좌절합니다. 검은 화면에 빠르게 흐르는 코드는 심리적 장벽을 만듭니다. ‘개발자는 뭔가 다른 사람들’이라는 느낌이 들죠. 화가나기도 하죠.

실제 있었던 일을 예로 들어볼게요.

기획자: “이 버튼 색깔 좀 바꿔주세요."
개발자: “아 그건 좀 어려워요. 3일은 걸릴 것 같아요."
기획자: “이 버튼 색깔만 바꾸면 되는 거 아닌가요? 왜 3일이 걸려요?"
개발자: “디자인 시스템 전체를 수정해야 하고, 테마 로직도 바꿔야 해서요."

여기서 기획자는 생각합니다. ‘색깔 하나 바꾸는데 왜 저렇게 복잡하게 말하지?’
개발자는 생각합니다. ‘기술을 모르니까 이해를 못 하네.’

하지만 둘 다 틀렸습니다. 진짜 문제는 기술 이해도가 아닙니다. 서로가 같은 상황을 다른 맥락과 입장에서 보고 있다는 것을 모른다는 게 문제죠.

이랬다면 어땠을까요?

기획자: “이 버튼 색깔을 바꾸려면 어떤 작업들이 필요한가요?"
개발자: “지금 버튼 색은 사이트 전체에서 공통으로 사용하는 색상이에요. 이걸 바꾸면 100개 넘는 화면에 영향을 주기 때문에, 각각을 확인하는 테스트 작업이 필요해요. 반대로 이 페이지의 이 버튼 하나만 바꾸는 것이라면 별도로 새 색상이나 버튼 형식을 정의하는 게 나을 수 있는데, 어떻게 하시겠어요?”

같은 상황인데 전혀 다른 대화가 됩니다. 첫 번째는 서로를 오해하게 만들고, 두 번째는 함께 해결책을 찾게 만듭니다.

같은 일을 각자의 입장에서 바라보는 것은 당연합니다. 하지만 같은 상황에서 싱크를 맞추어 해결책을 만들 수 있는 소통을 하는게 핵심입니다.

자기만의 단어 없애기

“그냥 API 하나 붙이면 되는데요.”

저도 예전에 이런 말을 자주 했습니다. 그런데 이 문장에는 두 가지 문제가 있어요.

첫째, “그냥"이라는 단어. 이건 상대방의 질문을 가볍게 여긴다는 느낌을 줍니다. 개발자에게는 익숙한 일이지만, 듣는 사람은 “내가 뭔가 모자란 질문을 했나?” 생각하게 됩니다.
둘째, “API"라는 용어. 상대방이 이게 뭔지 모르면, 대화는 거기서 끝입니다.

이렇게 바꿔볼 수 있어요.

“서버에서 필요한 데이터를 가져오는 작업이 필요해요. 서버팀과 협의하면 2-3일 정도 걸릴 것 같습니다.”

훨씬 명확하죠? 기술 용어를 쓰기 전에 한 번만 더 생각해보세요. 이 단어를 모르는 사람이 들어도 이해할 수 있을까? 처음에는 어색할 수 있습니다. 정확한 용어를 쓰지 않으면 뭔가 프로답지 않은 것 같은 느낌도 들고요. 하지만 소통의 목적은 내가 얼마나 아는지 보여주는 게 아니라, 상대방이 이해하도록 만드는 겁니다.

비유로 설명해보기

“캐시가 뭐예요?”

이 질문에 “서버 요청을 줄이기 위해 임시로 데이터를 저장하는 메모리 영역이요"라고 답하면, 상대방은 고개를 끄덕이지만 사실 이해하지 못했을 가능성이 큽니다.

이렇게 바꿔보면 어떨까요?

“냉장고로 설명해 볼게요. 매번 마트 가기 귀찮으니까 자주 먹는 음식을 냉장고에 넣어두잖아요. 캐시도 똑같아요. 서버에 매번 물어보기 번거로우니까, 자주 쓰는 데이터를 브라우저에 잠깐 저장해두는 거예요.”

100% 정확한 설명이 필요한 게 아닙니다. 하지만 상대방은 이해합니다. 그리고 이해했으니 다음 질문을 할 수 있죠. “그럼 냉장고가 꽉 차면 어떻게 돼요?” “오래된 음식은 버리나요?”

좋은 비유는 대화의 문을 엽니다.

비유 예시:

데이터베이스 = 도서관
“데이터베이스는 거대한 도서관이에요. 책(데이터)이 수만 권 있는데, 사서(쿼리)가 정확한 위치를 알아야 빨리 찾을 수 있죠. 인덱스는 도서 목록 같은 거예요.”

API = 식당 주문
“API는 식당에서 주문하는 것과 비슷해요. 손님(프론트엔드)이 메뉴판 보고 주문하면, 주방(서버)에서 요리해서 가져다주는 거죠. 손님은 주방에서 어떻게 만드는지 몰라도 돼요.”

컴포넌트 = 레고 블록
“리액트 컴포넌트는 레고 블록이에요. 버튼, 카드, 헤더 같은 작은 조각들을 만들어두고, 이걸 조립해서 화면을 만드는 거예요. 같은 블록을 여러 곳에 쓸 수 있죠.”

배포 = 책 출간
“배포는 책을 출간하는 것과 같아요. 초고(개발)를 쓰고, 편집(테스트)하고, 인쇄소(서버)로 보내서, 서점(사용자)에 깔리는 거죠. 한 번 나간 책은 다시 수정하기 어려워요.”

처음에는 이런 비유를 찾는 게 어렵습니다. 저도 그랬어요. 하지만 연습하다 보면 자연스럽게 나옵니다. 팁을 하나 드리자면, 일상생활에서 익숙한 것들로 비유하세요. 식당, 도서관, 우체국, 공장… 누구나 경험해본 것들이요.

정확도를 조금 포기하는 게 두려울 수 있습니다. “이건 엄밀히 말하면 틀린 설명인데…” 하는 생각이 들 수도 있어요. 괜찮습니다. 소통의 목적은 기술 논문을 쓰는 게 아니라, 함께 일하는 동료가 맥락을 이해하도록 돕는 거니까요.

상대방이 비유를 이해했다면, 그 다음은 자연스럽게 더 깊은 대화로 이어집니다. 그게 좋은 소통의 시작입니다.

태도가 기술보다 중요하다

일을 하다 보니 깨달은 게 있습니다. 좋은 개발자가 좋은 소통을 하는 게 아니라, 좋은 소통을 하는 사람이 좋은 개발자가 된다는 것.

기술은 배우면 됩니다. 새로운 프레임워크도, 낯선 라이브러리도 시간을 들이면 익힐 수 있어요. 하지만 상대방의 말을 듣는 태도, 먼저 이해하려는 자세는 기술 책에 나오지 않습니다.

이렇게 해보면 어떨까요?

“안 돼요” 대신 “이렇게 하면 가능해요”
나쁜 예: “그건 기술적으로 불가능해요.”
좋은 예: “말씀하신 방식은 어렵지만, 비슷한 효과를 낼 수 있는 방법이 있어요.”

상대방의 질문을 존중하기
기초적인 질문이어도 성의 있게 답하기. “그것도 모르세요?“라는 표정 짓지 않기. 질문은 신뢰의 표현입니다.
질문자는 알만한 사람에게, 대답해줄 수 있을법한 사람에게 물어봅니다.

기술적 우월감 내려놓기
코드를 모른다고 가치가 낮은 게 아닙니다. 기획자는 사용자를, 디자이너는 경험을 이해합니다. 각자의 전문성을 존중하세요.

먼저 듣고, 나중에 설명하기
상대방이 진짜 원하는 게 뭔지 먼저 파악하기. 기술 설명은 꼭 필요할 때만. “제가 이해한 게 맞나요?“로 확인하기.

다른 직군 여러분께

개발자인 제가 다른 직군 분들께 부탁드리고 싶은 이야기도 있습니다.

개발자도 여러분과 똑같은 사람입니다

우리도 월요일 아침은 힘들고, 금요일 저녁은 기다려집니다. 점심 메뉴 고르기 어렵고, 칭찬받으면 기뻐하고, 무시당하면 상처받습니다. 검은 화면에 코드를 친다고 해서 다른 종족이 아니에요.

가끔 개발자를 대할 때 조심스럽게 접근하시는 분들이 있어요. “바쁘신 데 죄송한데요…”, “이거 물어봐도 될까요?” 괜찮습니다. 편하게 물어보세요. 우리는 질문받는 걸 싫어하지 않아요. 다만 질문의 맥락을 이해하는 데 시간이 좀 필요할 뿐이에요.

“기술적으로 어렵다"는 말의 진짜 의미

개발자가 “기술적으로 어렵다"고 말할 때, 대부분은 거절하려는 게 아닙니다. 진짜 어려운 거예요.

하지만 우리도 설명을 더 잘해야 합니다. “어렵다"만 말하지 말고, 왜 어려운지, 어떻게 하면 가능한지를 함께 이야기해야죠.

여러분이 도울 수 있는 방법은, 그 다음 질문을 해주시는 겁니다. “어떤 부분이 어려운가요?”, “비슷한 걸로 대체할 수 있을까요?”, “시간이 더 있으면 가능한가요?” 이런 질문이 문제 해결의 시작입니다.

개발자에게 편하게 질문하는 방법

좋은 질문은 개발자에게도 좋습니다. 명확한 질문은 명확한 답을 만들어요.

도움이 되는 질문:

  • “이 기능이 왜 필요한지” 맥락 공유하기
  • “언제까지 필요한지” 데드라인 알려주기
  • “어느 정도까지 필요한지” 범위 명확히 하기

예를 들어 “로그인 기능 만들어주세요” 보다는 “신규 유저 온보딩 개선을 위해 소셜 로그인이 필요해요. 다음 달 마케팅 캠페인 전까지 구글 로그인만이라도 우선 적용 가능할까요? 최종적으로는 구글, 애플, 카카오, 네이버 로그인이 다 들어가야해요.“가 훨씬 좋습니다.

맥락을 알면 개발자는 더 나은 제안을 할 수 있습니다. “당장의 온보딩 유입 개선이 목적이면, 카카오가 국내에서 전환율이 더 높은데 그걸로 먼저 해볼까요?”

함께 성장하는 팀 만들기

결국 우리는 같은 배를 타고 있습니다. 좋은 제품을 만들려면, 기획자의 사용자 이해도, 디자이너의 경험 설계도, 개발자의 기술 구현도 모두 필요해요.

서로의 전문성을 존중하고, 모르는 걸 부끄러워하지 않고, 함께 배우려는 태도. 이게 좋은 팀의 시작입니다.

개발자에게 “이거 왜 이렇게 만들었어요?“라고 물어봐 주세요. 우리는 우리가 만든 것에 대해 이야기하는 걸 좋아합니다. 그리고 여러분의 피드백으로 더 나은 결과물이 나옵니다.

마치며

이 글을 여기까지 읽어주셔서 감사합니다.

좋은 제품은 좋은 대화에서 나옵니다.

뛰어난 코드보다, 최신 기술보다, 빠른 개발 속도보다 중요한 게 있습니다. 서로를 이해하고, 같은 방향을 바라보고, 함께 문제를 해결하는 것. 좋은 제품이 나오는 조건이자 함께 일하는 행복을 만드는 조건이기도 합니다.

개발자는 소통을 못하는 게 아닙니다. 다른 방식으로 소통하는 데 익숙할 뿐이에요. 그리고 그 간극을 메우는 건 어렵지 않습니다. 조금만 노력하면, 조금만 연습하면 충분합니다.

오늘부터 실천할 한 가지

이 글을 읽고 나서 딱 하나만 실천해보세요.

  • 다음 회의에서 기술 용어를 하나만 줄여보기
  • 동료의 질문에 비유로 답해보기
  • “안 돼요” 대신 “이렇게 하면 가능해요"로 바꿔보기

이 중에 하나만요. 한 번에 많은 걸 바꾸려고 하지 마세요. 작은 변화가 쌓이면 큰 차이가 됩니다.

저도 여전히 배우고 있습니다. 여전히 실수하고, 여전히 어색할 때가 있어요. 하지만 포기하지 않습니다. 좋은 개발자가 되는 것만큼, 좋은 동료가 되는 것도 중요하니까요.

여러분의 팀에서 오늘도 좋은 대화가 오가기를 바랍니다.

P.S.
이 글이 도움이 되셨다면, 여러분 팀의 개발자나 기획자에게 공유해보세요. 그리고 커피 한 잔 마시며 “우리 팀의 소통은 어때?“라고 물어보세요. 그게 좋은 시작입니다.