최근 현대자동차 그룹 소프티어 교육을 수강하며 팀원 간 소통하게 되는 시간이 많아지게 되었다. 이에 따라 개발자로서 갖춰야 할 커뮤니케이션 역량에 대해서 많은 고민을 하고 있다.

예전에는 커뮤니케이션을 단순히 팀원과 사이좋게 지내는 것이라고 생각했다. 다투지 않고, 분위기를 좋게 유지하고, 서로 기분 상하지 않게 말하는 것이 좋은 커뮤니케이션이라고 생각했다.

하지만 프로젝트와 여러 활동을 경험하면서 생각이 조금 바뀌었다.

이번 글에서는 프로젝트와 활동을 하면서 느낀 점을 바탕으로, 내가 생각하는 좋은 커뮤니케이션에 대해 정리해보려고 한다.

커뮤니케이션은 관계 유지가 아니라 문제 해결이다

프로젝트를 진행하다 보면 자연스럽게 의견 차이가 생긴다.

기능을 빠르게 배포할 것인지, 완성도를 더 높인 뒤 배포할 것인지.

이런 선택에는 대부분 정답이 없다. 각 선택마다 장점과 단점이 있고, 상황에 따라 더 적절한 선택이 달라진다. 문제는 의견 차이 자체가 아니라, 의견 차이를 어떻게 다루느냐가 중요하다.

먼저 배포할 것인가, 완성도를 높인 뒤 배포할 것인가

금품타 프로젝트를 진행하면서 실제로 의견 차이가 있었던 순간이 있다.

서비스를 어느 정도 구현한 뒤, 우리는 배포 시점에 대해 논의하게 되었다.

한쪽 의견은 이랬다.

“일단 사용자에게 빠르게 배포하고, 피드백을 받으면서 애자일하게 개선하자.”

내가 더 가깝게 생각했던 방향도 이쪽이었다.

실제 사용자가 있는 서비스를 만들고 있다면, 내부에서 오래 고민하는 것보다 빠르게 배포하고 사용자 반응을 확인하는 것이 더 중요하다고 생각했다. 사용자가 실제로 어떤 부분에서 불편함을 느끼는지는 배포 이후에 더 명확하게 알 수 있기 때문이다.

반면 다른 의견도 있었다.

“사용자에게 처음 보여주는 서비스인 만큼, 완성도를 더 높인 뒤 배포해야 한다.”

이 의견도 충분히 일리가 있었다.

초기 사용 경험이 좋지 않으면 사용자는 다시 돌아오지 않을 수 있다. 특히 앱 서비스는 첫인상이 중요하고, 불안정한 기능이 많으면 서비스에 대한 신뢰도가 떨어질 수 있다. 이것은 누가 맞고 틀린 문제가 아니라, 우리가 현재 어떤 기준을 더 중요하게 볼 것인가의 문제였다.

하지만 회의 과정에서 의견이 오가다 보니, 어느 순간 감정이 섞이는 것처럼 느껴지는 순간이 있었다. 상대방의 말이 단순한 의견 제시가 아니라 내 생각을 부정하는 것처럼 들리기도 했다.

“왜 저렇게 말하지?”
“내 의견이 그렇게 이상한가?”
“나를 공격하는 건가?”

지금 돌아보면 상대방이 나를 공격하려던 것은 아니었다. 서로 서비스에 대해 진지하게 고민하고 있었고, 각자 중요하게 보는 기준이 달랐을 뿐이었다.

하지만 회의 중에는 의견과 감정을 분리하는 것이 생각보다 쉽지 않았다. 내가 낸 의견에 반대 의견이 나오면, 그 반대가 나라는 사람에 대한 부정처럼 느껴질 때가 있었다.

이 경험을 통해 커뮤니케이션에서 중요한 것은 이성과 감정을 분리하는 것이라고 생각하게 되었다.

비판해야 하는 것은 사람이 아니라 방식, 근거, 리스크, 문제 상황이어야 한다.

회의 이후 대화로 합의점을 찾다

회의가 끝난 뒤 서로 다시 이야기를 나누면서 우리가 무엇을 우려하고 있었는지 정리할 수 있었다. 서로의 입장을 다시 들어보니 결국 둘 다 같은 목표를 가지고 있었다. 다만 그 목표에 도달하는 방법을 다르게 생각했을 뿐이었다.

결국 우리는 무조건 빠르게 배포하거나, 무조건 완벽해질 때까지 미루는 방식이 아니라, 핵심 기능을 우선 안정화한 뒤 배포하고 이후 사용자 피드백을 받아 개선해나가는 방향으로 합의점을 찾았다.

이 경험을 통해 이성과 감정을 분리하는 법을 조금 배웠다.

논쟁 중에는 의견이 다를 수 있다. 하지만 논쟁이 끝난 뒤에는 다시 같은 팀원으로 돌아와야 한다. “고생하셨습니다”, “밥 먹으러 가실래요?”라고 말할 수 있어야 한다.

이것이 좋은 커뮤니케이션에서 중요한 태도라고 느꼈다.

갈등을 피하는 것이 항상 좋은 것은 아니다

또 다른 경험도 있다.

팀원 중 한 명이 연락을 늦게 확인하고, 담당한 부분을 제때 마무리하지 못한 적이 있었다. 그 결과 다른 프론트엔드 팀원이 해당 부분을 대신 처리하게 되었다.

사실 그때 나는 문제를 인지하고 있었다. 담당자가 제때 작업하지 못하고 있었고, 다른 팀원이 부담을 대신 떠안고 있었다. 이 상황이 반복되면 팀 전체 일정에도 영향을 줄 수 있다는 것도 알고 있었다.

하지만 나는 직접적으로 말하지 못했다. 괜히 말했다가 분위기가 불편해질까 봐, 분쟁이 생길까 봐, 상대방이 기분 나빠할까 봐 피했던 것 같다. 당시에는 그것이 팀 분위기를 지키는 방법이라고 생각했다

하지만 결과적으로는 그렇지 않았다. 내가 말을 하지 않는 동안, 다른 팀원이 더 많은 부담을 떠안게 되었다. 문제는 해결되지 않았고, 오히려 특정 팀원에게 일이 몰리는 상황이 되었다.

그 경험을 통해 갈등을 피하는 것이 꼭 좋은 커뮤니케이션은 아니라는걸 느꼈다.
돌아보면 그때 이렇게 말할 수 있었을 것 같다.

“현재 담당하신 부분의 진행 상황을 팀원들이 정확히 알기 어려운 것 같습니다.
이 부분이 늦어지면 다른 작업에도 영향을 줄 수 있어서, 현재 어디까지 진행됐는지 공유해주시면 좋겠습니다.”

또는 이렇게 말할 수도 있었다.

“이번 작업이 제때 끝나지 않으면서 다른 팀원이 대신 처리하게 된 부분이 있었습니다.
다음부터는 일정이 어려울 것 같으면 미리 공유해서 같이 조정하면 좋겠습니다.”

이 표현의 핵심은 상대를 비난하는 것이 아니라 문제 상황과 영향, 그리고 다음 행동을 함께 이야기하는 것이다.

반대로 나쁜 방식은 이런 식일 것이다.

“왜 연락을 안 보세요?”
“왜 맡은 일을 안 하셨어요?”
“이러면 팀에 피해 주는 거 아닌가요?”

물론 문제를 지적하는 것은 필요하다. 하지만 사람을 공격하는 방식으로 말하면 상대는 방어적으로 반응할 가능성이 높다. 그러면 논의의 초점은 문제 해결이 아니라 감정 대응으로 바뀐다.

상대가 말하는 의도를 정확히 이해하자

개발 회의에서는 종종 이런 상황이 생긴다.

나는 특정 기능의 도메인 흐름이나 설계 방향에 대해 이야기하고 있는데, 상대방은 그 맥락을 충분히 이해하지 못한 상태에서 전혀 다른 방향의 이야기를 하는 경우가 있다.

예를 들어 결제 기능을 개발한다고 가정해보자. 한 사람이 이렇게 말한다.
(하나의 사례일 뿐, 내용은 틀리더라도 무시해주세요)

“결제 요청이 들어왔을 때 바로 주문 상태를 PAID로 바꾸면 안 될 것 같습니다.
PG사 승인 결과를 확실히 받은 뒤에 상태를 변경해야 할 것 같아요.”

결제 도메인에서 중요한 것은 주문 상태의 정합성이고, 외부 PG사와 통신하는 과정에서 실패하거나 지연될 수 있는 상황을 고려해야 한다는 의미다.

그런데 이 말을 들은 사람이

“그럼 결제 API 응답 속도를 빠르게 하려면 비동기로 처리하면 되지 않을까요?”

물론 비동기 처리는 하나의 대안이 될 수 있다.
하지만 이 대답은 앞에서 이야기한 핵심과 조금 다르다.

처음 이야기의 핵심은 “응답 속도를 어떻게 빠르게 할 것인가”가 아니라, 어떤 시점에 주문 상태를 변경해야 데이터 정합성을 지킬 수 있는가였다.즉, 상대방이 말한 기술적인 단어만 듣고 바로 해결책을 말하면 대화의 핀트가 어긋날 수 있다.

이런 상황이 반복되면 회의는 길어지지만 결론은 잘 나지 않는다. 각자 열심히 말하고 있지만, 실제로는 서로 다른 문제를 보고 있기 때문이다.

도메인과 설계를 이해해야 대화의 초점이 맞는다. 개발 커뮤니케이션에서는 단순히 말을 듣는 것만으로는 부족하다. 상대가 어떤 도메인 맥락에서 이야기하는지, 어떤 설계 의도를 가지고 말하는지 이해해야 한다.

도메인을 이해하지 못하면 상대의 말에서 중요한 부분을 놓칠 수 있다.
설계를 이해하지 못하면 지금 논의해야 할 문제가 무엇인지 파악하지 못하고, 전혀 다른 해결책을 이야기할 수 있다.

그래서 대화 중에는 내가 이해한 내용이 상대의 의도와 맞는지 확인해야 한다.
예를 들면 이렇게 물어볼 수 있다.

“제가 이해한 게 맞다면, 지금 말씀하신 핵심은 결제 API 속도보다 주문 상태 정합성을 보장하는 시점을 정하는 게 중요하다는 의미인가요?”

상대방의 말을 듣고 바로 내 의견을 말하는 것보다, 먼저 상대가 의도한 바를 확인하는 과정이 필요하다. 결국 좋은 커뮤니케이션은 내가 이해한 내용과 상대가 의도한 내용 사이의 괴리를 줄여가는 과정이라고 생각한다.

마무리

이번 글을 정리하면서 커뮤니케이션에 대해 다시 생각해보게 되었다.

예전에는 좋은 커뮤니케이션을 갈등 없이 잘 지내는 것이라고 생각했다. 하지만 프로젝트 경험을 돌아보니, 정말 중요한 것은 단순히 분위기를 좋게 유지하는 것이 아니었다.

의견이 다를 때 감정과 내용을 분리하기
필요한 문제를 피하지 않고 말하기
상대가 말하는 도메인과 설계 의도를 정확히 이해하기

이런 과정들이 결국 팀이 같은 문제를 바라보고, 더 나은 방향으로 나아가기 위해 필요한 커뮤니케이션이라고 느꼈다.

소프티어 교육을 들으면서도 이 부분을 더 의식적으로 연습해보고 싶다. 단순히 주어진 과제를 구현하는 것에서 끝나는 것이 아니라, 팀원들과 문제를 어떻게 이해하고 있는지 맞춰보고, 내가 생각한 설계 방향과 판단 근거를 명확하게 공유하는 습관을 들이고 싶다.

앞으로는 단순히 좋은 분위기를 유지하는 사람이 아니라, 문제를 더 명확하게 만들고 팀이 앞으로 나아가도록 돕는 개발자가 되고 싶다.