말 한마디로 천냥 빚을 갚는다..

목적

최근 들어 아무리 개발을 잘하더라도 소통이 부족하면 그 실력이 제대로 드러나지 않는다는 생각이 자주 든다. 오히려 개발 실력보다 의사소통 능력이 몇 배는 더 중요하다는 생각이 들어서, 그 중요성을 다시 한번 되새기고자 짧게나마 글을 써보려 한다.

서사

최근에 진행했던 프로젝트에서 겪은 일을 바탕으로 이야기해보려 한다. 프로젝트는 나를 포함해 프론트엔드 3명, 백엔드 2명, 클라우드 1명으로 구성되어 있었다. 백엔드 개발은 이미 완료된 상태였고, 프론트엔드는 클라우드 팀원이 AWS를 통해 서버를 배포해주기만 하면 API를 연결하여 마무리할 수 있는 상황이었다.

하지만 서버 배포 과정에서 문제가 발생했다. 당초 계획에 따르면 3월이 끝나기 전까지 배포가 완료되어야 했으나, 클라우드 팀원이 별다른 상황 공유 없이 배포 일정을 계속 미뤘다. 어떤 이유로 일정이 지연되는지에 대한 설명이나 상황 공유가 있었다면 좋았겠지만, 제대로 된 소통이 이루어지지 않으면서 프로젝트 마무리도 계속해서 늦어졌다. 결국 계획보다 약 2주가 지난 후, 백엔드 팀원이 Cloudtype을 통해 직접 배포를 진행하게 되었다.

문제점..

글을 이어가기 전에, 이 글이 절대로 팀원을 비하하기 위한 의도가 아니라는 점을 먼저 밝혀두고 싶다. 단지 프로젝트를 진행하면서 느낀 점들을 솔직하게 공유하려는 목적임을 이해해주면 좋겠다.

그럼 지금부터 내가 느낀 문제점들에 대해 이야기해보겠다.

1. 상황 공유의 부재

프로젝트를 원활히 진행하기 위해서는 소통이 중요한데, 그중에서도 핵심은 상황 공유이라고 생각한다. 작업이 지연될 경우, 어떤 이유로 늦어졌는지, 현재 어느 정도까지 진행되었는지, 만약 작업이 어려운 상황이라면 다른 팀원에게 업무를 넘기는 등의 조치가 필요하다.

물론 스프린트가 계획대로 진행되는 것이 가장 좋지만, 하루 이틀 정도의 지연은 충분히 이해할 수 있다. 다만, 상황 공유 없이 일정을 계속 미루는 것은 바람직하지 않다.

팀원들은 누군가 상황을 공유하지 않으면, 그 사람이 어떤 상황에 놓여 있는지, 얼마나 작업이 진행되었는지 전혀 알 수 없다. 이러한 상태에서 일정만 계속 미뤄진다면 팀원 간의 신뢰는 당연히 떨어질 수밖에 없다.

상황을 잘 공유하기 위해서는 자기 상황을 확실하게 인식하는 능력도 중요하다. 지금 내가 작업을 계속할 수 있는지, 언제까지 마무리할 수 있을지 등을 스스로 판단하고 그것을 팀원에게 정확히 전달할 수 있어야 한다.

또한, 상황 공유를 특정 한 사람에게만 하는 것도 바람직하지 않다. 상황을 전달받은 한 사람이 다른 팀원들에게 다시 내용을 전하는 과정에서 오해가 생길 수 있기 때문이다. 따라서 상황을 공유할 때는 팀원 모두가 동시에 내용을 들을 수 있도록 한 번에 공유하는 것이 가장 좋다. 이렇게 하면 정보의 왜곡 없이 팀 전체가 동일한 이해를 바탕으로 움직일 수 있다.

2. 적극적이지 않은 소통

프로젝트를 원활하게 진행하려면, 누군가는 먼저 말을 꺼내야 한다. 모든 팀원이 소극적이고 서로 대화를 주고받지 않는다면, 프로젝트는 결코 제대로 진행될 수 없다.

단지 친하지 않다는 이유로 소통에 소극적인 태도를 보이는 것은 바람직하지 않다. 아무리 어색하고 친하지 않은 사이라도, 프로젝트를 함께 하는 동안만큼은 적극적으로 참여하려는 자세가 필요하다.

또한, 특정 역할의 팀원들과 직접적인 관련이 없는 이야기라 하더라도, 팀 내에서 오간 대화의 내용은 가능한 한 모두에게 공유되어야 한다. 예를 들어, 프론트엔드에서 어떤 기술 스택을 사용하기로 했다거나, 백엔드에서 내부 논의를 통해 특정 방식을 채택하기로 했다면, 이런 비교적 단순한 내용이라도 팀원 모두가 알아야 한다. 이런 정보들이 쌓이면서 전체적인 이해도와 협업의 효율이 높아지기 때문이다.

자신의 의견을 말할 때도 중요한 점이 있다. 의견을 말하는 것 자체는 매우 좋은 일이지만, 애매한 표현이나 두루뭉실한 설명은 오히려 혼란을 줄 수 있다. 의견이 있다면, 반드시 스스로 정리한 뒤, 명확하고 구체적인 표현을 사용해 전달하는 것이 좋다.

그리고 질문은 많이 할수록 좋다. 누군가 의견을 냈을 때 왜 그런 방식으로 하려는 건지 이해가 되지 않거나, 말의 의미 자체가 헷갈릴 때는 반드시 질문해야 한다. 모르는 것은 절대 부끄러운 일이 아니며, 오히려 그때 묻지 않으면 나중에 더 큰 문제가 발생할 수 있다. 이해되지 않는 부분이 있다면 즉시 질문하고, 필요한 만큼 확인하는 것이 프로젝트에 도움이 된다.

3. 역할과 책임의 불분명함

프로젝트를 진행하다 보면 '누가 이걸 해야 하지?' 하는 애매한 상황이 종종 생긴다. 역할과 책임이 명확히 정리되어 있지 않으면, 팀원들 사이에 업무 누락이나 중복이 발생하기 쉽다. 서로가 ‘누군가 하겠지’라는 생각만 하게 되면 결국 아무도 하지 않게 되고, 결과적으로 프로젝트의 흐름이 끊기게 된다.

그래서 프로젝트 초반에는 각자의 역할과 담당 업무를 명확하게 나누는 것이 매우 중요하다. 단순히 프론트, 백엔드, 클라우드라고만 나누는 것이 아니라, 프론트 내에서도 어떤 기능을 누가 맡을지, 백엔드에서도 어떤 API를 누가 책임질지 등 세부적인 분업이 필요하다. 그리고 상황에 따라 역할을 조정할 수 있는 유연함도 함께 가져가는 것이 좋다.

4. 회의의 비효율성

회의는 협업에서 중요한 소통 수단이지만, 준비 없이 진행되거나 목적 없이 길어질 경우 오히려 비효율적일 수 있다. 누가 무엇을 말해야 하는지, 어떤 결정을 내려야 하는지 정리되지 않은 채 진행되는 회의는 시간만 낭비하고, 실질적인 결과를 얻기 어렵다.

회의가 반드시 길 필요는 없다. 오히려 짧더라도 핵심만 빠르게 공유하고, 즉각적인 피드백을 주고받는 문화가 정착되면 팀 전체의 소통 효율이 훨씬 높아진다.

효율적인 회의를 위해서는 회의 전 안건을 사전에 정리하고, 회의가 끝난 후에는 결정된 사항과 각자의 할 일을 명확히 기록해두는 것이 중요하다. 회의 내용을 기록해두면 시간이 지나 기억이 희미해졌을 때 다시 확인할 수 있어, 혼란을 줄일 수 있다.

또한, '목소리로 하는 회의'의 중요성도 간과해서는 안 된다. 디스코드나 메신저처럼 텍스트로만 소통하다 보면, 말하고자 하는 의도나 감정의 뉘앙스가 제대로 전달되지 않아 의미의 손실이 발생할 수 있다. 특히 중요한 결정이나 복잡한 주제를 다룰 때는 텍스트보다 음성 소통이 훨씬 효과적이다.

가장 이상적인 방법은 실제로 만나서 대면 회의를 하는 것이지만, 여건이 되지 않는 경우에는 최소한 음성 통화나 화상 회의를 통해 서로의 목소리를 들으며 소통하는 것이 좋다. 말로 대화하면 감정과 의도를 더 정확히 파악할 수 있고, 텍스트로는 설명하기 어려운 부분도 훨씬 빠르게 조율할 수 있다.

5. 피드백 부족

피드백은 팀원 간의 성장과 개선을 위한 매우 중요한 요소다. 하지만 '괜히 기분 상할까 봐', '내가 잘 몰라서 말 꺼내기 어려워서' 같은 이유로 피드백을 주저하는 경우가 많다.

그러나 사소한 문제라도 솔직하게 피드백과 질문을 주고받는 문화가 없다면, 같은 실수가 반복되거나 팀 전체의 퍼포먼스가 떨어질 수밖에 없다. 물론 피드백을 줄 때는 말하는 방식이 중요하다. 상대를 비난하기보다는, 개선 방향 중심의 피드백을 주는 연습이 필요하다.

이 부분은 솔직히 나 자신도 많이 반성하게 되는 부분이다. 예전에 선배가 PR을 올렸을 때 내가 코드 리뷰를 해야 했지만, '선배니까 더 잘하겠지'라는 생각에다 코드가 잘 이해되지 않아서 리뷰에 제대로 참여하지 못했다. 어떤 식으로 개선하면 좋을지 감이 잡히지 않았고, 괜히 틀릴까 봐 겁이 나기도 했다. 하지만 돌아보면, 그럴수록 더 용기 내서 질문하고 피드백을 주려고 노력했어야 했다고 느낀다.

또 하나 느낀 건, 나보다 경험이 많은 사람이 피드백을 줬다고 해서 무조건 수용할 필요는 없다는 점이다. 물론 더 잘할 가능성이 높긴 하지만, 그렇다고 항상 더 나은 해답을 가진 것은 아니다. 피드백을 받은 뒤에는, 그 내용을 바탕으로 스스로도 한 번 더 고민하고, 내 생각을 정리해보는 과정이 꼭 필요하다. 스스로의 판단을 믿는 자세도 중요하다.

최근에 학교 친구들, 선배들과 스터디를 하면서 확실히 깨달은 게 있다. 모르는 것은 절대 부끄러운 일이 아니다. 오히려 모르는 걸 숨기거나, 괜히 아는 척을 하는 것이 더 부끄러운 일이다. 민망하더라도 이해가 안 되는 부분이 있다면, 앞으로는 더 자신 있게 질문하고, 내가 생각한 바를 솔직하게 말하려고 한다.

서로의 성장을 위해, 그리고 더 나은 협업을 위해, 피드백과 질문은 언제나 환영받아야 한다.

마무리

글을 다 쓰고 보니, 소통이라는 건 분명 정답이 없는 주제인데 뭔가 내 말이 정답인 것처럼 글을 작성한 것 같다. 하지만 그런 의도는 전혀 없었고, 단지 내가 겪은 경험과 그 안에서 느낀 점들을 솔직하게 나누고 싶었다는 것만 알아주면 좋겠다.

오늘은 내가 생각하는 소통의 중요성과 그 이유, 실제 프로젝트를 하면서 느꼈던 문제점들에 대해 이야기해보았다. 개발자에게 소통 능력은 개발 실력 못지않게 중요한 역량이고, 사실 개발자가 아니더라도 모든 사람에게 꼭 필요한 능력이라고 생각한다.

이 글을 읽는 누군가에게 조금이라도 도움이 되었으면 좋겠고, 나 역시 아직 부족한 부분이 많기 때문에 앞으로도 더 많은 사람들과 소통하면서, 더 나은 팀원, 더 나은 개발자가 되기 위해 계속해서 노력해야겠다..