지난 2019년 11월 9일, 각자 다른 가치관, 다른 경험, 다른 전문 분야를 가지고 있는 9명의 개발자들이 Chit Chat에 참여하기 위해 잠실에 모였습니다.
많은 개발자들이 이런 모임을 직접 운영하거나 참여하고 있기는 하지만 대부분 기술과 관련된 주제에 집중되어있기 때문에 기술 외적인 주제에 대해 각자의 생각이나 가치관을 나눠볼 수 있는 기회는 그리 많지 않은 것이 사실이죠.
그래서 루비콘은 기술적인 주제가 아닌, 기술 외적인 주제에 대해 다양한 개발자들의 다양한 의견과 가치관을 들어보자는 의미로 칫챗이라는 스몰 토크 모임을 열게 되었어요.
이번 칫챗의 주제는 바로 “소프트 스킬”입니다! 소프트 스킬은 전문가로써 지녀야하는 전문 스킬인 하드 스킬 외에 모든 스킬을 지칭하는 상당히 폭 넓은 용어인데요, 존 손메즈가 집필한 “소프트 스킬”이라는 책으로 인해 개발자들에게도 상당히 많이 알려진 용어입니다.
처음에는 이런 모임을 주최하는 것이 처음이라 이야기가 원활하게 진행될 수 있을 지 걱정하기도 했지만, 이런 걱정을 했던 것이 무안할만큼 이야기를 시작하자마자 소프트 스킬에 대한 다양한 경험과 의견들이 쏟아져 나오기 시작했습니다.
이번 칫챗은 총 2시간 정도 진행되었으며, 이 포스팅에서는 그 중 가장 많은 이야기를 나누었던 3가지 주제에 대해서 이야기를 해볼 예정입니다!
그럼 다양한 가치관과 경험을 가진 9명의 개발자들이 소프트 스킬에 대해서 이야기를 나누었는지 한번 살펴볼까요?
이 포스팅에 등장하는 분들의 이름은 익명성 보호를 위해 임의의 닉네임으로 처리하였습니다. 또한 포스팅의 원활한 내용 진행을 위해 약간의 각색이 첨가되어있음을 알려드립니다.
여러분이 생각하는 소프트 스킬은 어떤 것인가요?
첫 번째 주제는 “각자가 생각하는 소프트 스킬이 무엇인가”에 대한 이야기였습니다.
앞서 이야기했듯이, 소프트 스킬이란 전문가의 전문 스킬인 하드 스킬을 제외한 나머지 모든 분야를 지칭하는 용어이기 때문에 개발자들이 생각하는 소프트 스킬의 범위도 각자 다를 수 있습니다.
그래서 본격적인 토론에 들어가기에 앞서 조금 더 디테일한 주제를 정하기 위해 각자가 생각하는 소프트 스킬의 정의 또는 가장 중요하게 생각하는 가치에 대해서 한번 이야기를 나눠보기로 했습니다.
처음에는 존 손메즈의 “소프트 스킬”을 읽어본 두 분이 운을 띄워주셨는데, 두 분 모두 “소프트 스킬에서 다루고 있는 내용이 너무 많다”라는 의견을 공통적으로 이야기해주셨습니다.
저는 소프트 스킬이라는 책을 읽어본 적이 있는데, 이 책에서 다루는 주제가 무려 70가지나 되더라구요. 그래서 이 책을 읽어보면서 “과연 어디까지가 소프트 스킬인가?”라는 생각을 굉장히 많이 했던 것 같아요.
- Austin저도 그 책을 읽어본 적이 있는데, Austin 말대로 굉장히 많은 것을 소프트 스킬이라고 하더라구요. 심지어 재무 관리까지도 소프트 스킬이라고 하더군요. 저는 개인적으로 이렇게 많은 부분을 전부 챙기는 건 불가능하다고 생각해서, 자신의 가치관에 따라 특별한 포인트를 잡는 것이 중요하다고 생각해요.
- Henry
사실 Austin과 Henry의 말대로 소프트 스킬이라는 책에서는 소프트 스킬에 대해서 경력, 자기 PR, 학습, 생산성, 재무관리, 건강, 영혼이라는 7가지 큰 주제를 가지고 설명하고 있고, 이 주제들 안에서 다시 세부적인 주제들이 나누어지는 형식으로 이야기를 풀어나가기 때문에 무려 70가지 정도의 주제에 대해서 이야기하고 있습니다.
말 그대로 “전문 스킬 이외에 모든 것”을 소프트 스킬로 정의하고 있는 것이지요. 그래서 Austin과 Henry는 이 책을 읽어본 후에 오히려 머리가 더 복잡해졌다고 하네요.
이렇게 이야기를 나누다보니 이 책을 읽어보신 다른 분들도 이 의견에 대해서 공감을 표해주셨고, 이후 자연스럽게 수많은 소프트 스킬 중에서 어떤 것이 가장 중요한지에 대한 이야기로 흘러가게 되었습니다. 이렇게 10분 정도 도란도란 이야기를 나누다보니 자주 언급되는 키워드가 하나 나오게 되었는데요, 바로 “커뮤니케이션” 이었습니다.
사실 돈이나 복지, 대우 이런 것보다는 역시 사람이 가장 중요하다는 생각이 들어요. 팀원과의 케미가 맞지 않으면 돈을 아무리 많이 준다고 해도 함께 일하기 힘든 경우가 있었어요.
- John결국은 일 외적인 부분에서 얼마나 안정감을 느끼고 일에만 집중할 수 있는지가 중요한데, 이렇게 사람 때문에 일에 집중하지 못하는 경우가 있더라구요.
- Austin
음, 결국 이런 사람 간의 관계는 아무래도 커뮤니케이션이 가장 중요하지 않을까요?
- Karl
아무리 개발자가 컴퓨터와 함께 동고동락하며 일을 하는 직업이라고는 하지만, 결국 우리는 회사 안에서 다른 사람들과 팀을 이뤄 협업을 하게 돼죠.
칫챗에 참여한 다른 개발자분들도 모두 현 직장에서 협업을 하고 있는 사람들이기 때문에 소프트 스킬에 대한 이야기를 나누면서 자연스럽게 협업이나 커뮤니케이션에 대한 이야기를 하게 되었던 것 같아요.
Karl이 커뮤니케이션이라는 주제를 꺼내자마자 모든 분들이 너도 나도 공감을 표하며 커뮤니케이션의 중요성이나 어려움에 대한 이야기를 나누기 시작했습니다. 그 중에는 아무래도 개발팀 내에서 같은 개발자들과 커뮤니케이션을 하는 것보다는 개발팀 외부의 인원들과 커뮤니케이션이 어려운 것 같다는 이야기도 나왔습니다.
사실 디자이너, 기획자, PO, 마케터처럼 밀접하게 일해야하는 타 직군 팀원들과의 갈등 사례는 많은 개발자들의 공감을 얻을 수 있는 보편적인 이야기입니다.
하지만 직군은 달라도 결국 같은 지향점을 바라보고 있는 팀원인 만큼, 어떻게 하면 이들과 원활한 커뮤니케이션을 통해 시너지를 낼 수 있을지 고민해보는 시간을 가지는 것이 프로페셔널한 개발자의 모습이라고 할 수 있죠.
회사에서의 커뮤니케이션이 어려운 이유는 사람마다, 팀마다 사용하는 언어가 다르기 때문이라고 생각해요. 하지만 그 중에서도 가장 비일상적인 용어를 많이 사용하는 사람들은 아마 저희 개발자들이 아닐까요? 개발자가 아닌 다른 포지션의 팀원들과 대화할 때는 되도록 그들이 하는 일이나 사용하는 용어를 사용하여 비유하는 것이 좋다고 생각합니다.
- Karl
이렇게 커뮤니케이션과 팀에 대해서 이야기를 나누던 중 “사람마다, 팀마다 사용하는 언어가 다르다”라는 이야기가 나오기도 했는데요.
Karl은 개발자들에 대한 흔한 선입견 중 하나인 “늘 안된다고만 하는 사람”이라는 이미지를 깨기 위해서 노력을 많이 했다고 해요.
사실 개발자가 어떤 요청에 대해서 불가능하다고 이야기하는 이유는 대부분 기술적이거나 일정 때문인 경우가 많기 때문에 섣불리 가능하다고 말하는 것이 쉽지 않습니다.
그래서 Karl은 상대방이 하는 일이나 사용하는 용어를 관찰하고, 자신이 이야기할 때 최대한 그 사람이 하는 일이나 상대방의 전문 분야 용어를 사용하여 비유하는 경우가 많았다고 해요.
개발자의 언어가 아닌 상대방의 언어로 소통하려고 노력한 것이죠. 사실 이렇게 각 팀이 가지고 있는 업무에 대한 개념이나 사용하는 언어가 다르기 때문에 그 컨텍스트를 통합하자는 이야기는 DDD(Domain Driven Design)에서 다루고 있는 내용이기도 합니다.
그리고 이런 노력을 통해 실제로 원활한 커뮤니케이션을 이끌어 내며 팀의 생산성도 높아졌고, 무엇보다도 다른 팀원들이 개발자가 말하는 “No”라는 말에 대해서 더 신뢰를 가지게 되었다고 해요.
반면 DevOps 업무를 맡고 있는 Eric은 다른 개발자들과는 조금 다른 관점에서 커뮤니케이션을 바라보고 있었습니다.
저는 데브옵스 업무를 하고 있기 때문에 팀 내의 개발자들이 제 고객이기도 해요. 그래서 저는 고객과 사무실에서 직접 얼굴을 마주보며 커뮤니케이션을 통해 고객의 니즈를 파악해야 하는 상황이죠.
이때 제가 가장 초점을 맞추는 것은 상대방의 “Pain Point”를 찾아내는 것 입니다. 상대방이 이야기하는 주제의 흐름 중에서 정확히 이 사람이 원하는 부분을 캐치할 수 있는 능력이 커뮤니케이션에서는 중요한 것 같아요.
- Eric
Eric은 칫챗에 모인 다른 개발자들과는 다르게, 조직의 전반적인 인프라를 관리하는 DevOps 포지션을 맡고 있는 개발자입니다.
보통 개발자들이 DevOps 개발자를 찾아오는 경우는 “뭐가 안되거나”, “개선하고 싶거나”인 경우가 많습니다. 이때 DevOps 개발자는 커뮤니케이션을 통해 팀원의 니즈를 정확히 파악하고 합리적인 해결 방법을 제시해줄 수 있는 능력이 있어야 한다고 합니다.
그래서 개발팀 외부 인원과의 커뮤니케이션이나 배려, 존중에 초점을 맞추던 다른 분들과는 다르게, Eric의 커뮤니케이션 포인트는 바로 “상대방의 Pain Point를 잘 찾아내는 것”이었습니다.
이렇게 맡고 있는 포지션에 따라서도 커뮤니케이션에 대한 다양한 시각이 발생할 수 있다는 점을 알 수 있었습니다.
커뮤니케이션의 부족으로 인해 겪었던 문제가 있었나요?
다음으로 나누었던 이야기는 “팀 내에서 소프트 스킬의 부족으로 인해서 문제가 발생한 적이 있는지”에 대한 내용이었습니다.
앞서 커뮤니케이션에 초점을 맞춰 이야기하다보니, 자연스럽게 다음 주제 또한 “팀원들 간의 커뮤니케이션이 부족한 상황”으로 흘러가게 되었어요.
사실 대부분의 회사에서 팀원들 간의 커뮤니케이션의 중요성을 강조하기는 하지만, 실제로 팀 내에서 느끼는 온도와는 약간 다른 경우가 많아요.
커뮤니케이션 과정에서 서로 간의 오해도 있을 수 있고, 때로는 소프트 스킬이나 커뮤니케이션에 대해서 관심이 없는 팀원도 있을 수 있지요. 그래서 각자 소프트 스킬의 부재로 인해서 겪었던 아쉬운 점에 대해 이야기를 나눠보기로 했습니다.
저는 상대방에 대한 존중이 부족한 단 한 명의 팀원으로 인해 팀 전체가 망가지는 경험을 한 번 겪었어요. 처음에는 개발팀 내에 있는 많은 개발자 중 단 한명만 그러는 것 뿐이라서 가볍게 생각했는데, 그 분으로부터 시작해서 점점 팀 분위기가 서먹해지고 서로 불편해하는 상황까지 가니까 저도 같이 힘들어지더라구요.
- Henry맞아요. 비록 한 명뿐이지만 팀 분위기가 좌지우지 될 수 있기 때문에 가볍게 넘기면 안되는 것 같아요. 심지어 팀 내에 한명이 키맨 역할을 하는 경우에는 그 분이 이직을 하게 되면 다른 팀원들도 다 함께 그만 두는 경우도 있어요.
- Colin
칫챗에 모인 모든 개발자들이 이런 경험을 한 것은 아니였지만, 몇몇 분들은 한 두명의 팀원 때문에 팀 전체의 팀워크, 또는 팀 자체가 와해되어버리는 경험을 하기도 했습니다.
이런 경험을 했던 분들의 공통적인 의견은 “그런 인원이 적다고 해서 팀에 영향을 못 끼칠거라고 생각하면 안된다” 였습니다.
이렇게 구성원들의 소프트스킬 부족으로 인해 팀 내에서 원활한 커뮤니케이션이나 존중이 이루어지지 않는 경우, 팀원들이 퇴사를 하게 되는 극단적인 상황까지도 갈 수 있는 만큼 가볍게만 바라볼 수는 없습니다.
그래서 팀 차원에서 이런 점에 대해 경계를 해야한다는 의견도 있었습니다.
원활하지 않은 커뮤니케이션으로 인해서 팀 분위기가 안 좋아질 수는 있지만, 그것보다 그런 분위기에 젖어버리면 안되는게 더 중요한 것 같아요.
사실 같은 조직에 오래 있다보면 고인물이 되어버리기 때문에 문제를 객관적으로 파악하기 힘들 수도 있어요. 그래서 개인적으로는 조직에 새로 합류한 분이 보는 팀의 모습이 가장 객관적이라고 생각합니다.
- Karl
Karl은 자신이 겪어왔던 팀들이 커뮤니케이션 부족으로 인해 어떤 문제점들이 발생했는지 이야기하면서, 이런 문제의 원인을 객관적으로 찾아내고 해결하기 위해서 팀 내에 오래 있던 기존 구성원보다는 새로 팀에 합류한 사람의 의견이 중요하다고 이야기해주었어요.
사람은 적응의 동물이라고 하죠. 아무래도 기존 환경에서 오래 있던 사람들은 이미 해당 환경에 잘 적응한 사람들일테니 뭔가 개선하기위한 도전은 쉽지 않을 것입니다.
하지만 새로 팀에 합류한 사람의 경우에는 내부에 아는 사람도 없고 팀의 환경에 아직 적응을 한 상태도 아니기 때문에 조금 더 객관적인 제 3자의 눈으로 팀을 바라볼 수 있죠.
그런 이유로 팀에 새로 합류한 사람과 한 두달 정도 주기적인 티타임을 가지며 팀의 개선 방안에 대해 이야기를 나눠보는 회사들도 있습니다.
비록 칫챗에 모인 모든 개발자들이 이와 같은 경험을 한 것은 아니었지만, 팀 내의 커뮤니케이션 부재 상황을 겪었던 몇몇 개발자들은 이런 상황이 발생하는 것을 상당히 경계하고 있었고, 팀 내에서도 자체 정화를 위한 꾸준한 노력이 필요하다는 점에 대해서 공감을 표하기도 했습니다.
커뮤니케이션 스킬을 향상시키기 위해 여러분은 어떤 노력을 하고 있나요?
세 번째 주제는 “커뮤니케이션 스킬을 향상시키기 위해 어떤 노력을 하고 있는지”에 대한 이야기였습니다.
사실 처음에는 커뮤니케이션 스킬에 대한 노력이 딱히 필요없다고 하는 분도 있을 것 같아서 “과연 따로 노력을 해야할까요?”라는 질문을 하기도 했지만, 의외로 모든 분들이 소프트 스킬이나 커뮤니케이션 능력 향상에 대한 노력을 끊임없이 해야한다고 대답해주셨습니다.
이런 질문을 던졌을 때 가장 처음 나온 주제는 바로 “타인에 대한 존중”이었습니다.
사실 조직마다 소프트 스킬이나 좋은 커뮤니케이션에 대한 정의가 조금씩 다른 것 같아요. 상대방에 대한 공감도 중요하지만, 사실 직장에서의 커뮤니케이션이 가지는 의의는 일에 대한 소통이잖아요. 그래서 저같은 경우에는 감정적인 부분을 최대한 배제하고 최대한 논리적으로, 데이터를 근거로 이야기하려고 노력하는 편이에요.
- Brandon맞아요. 회사에서 하는 커뮤니케이션에는 절대 “그냥” 이라는 전제가 들어가면 안되죠. 그래서 저도 어떤 주장을 할 때 최대한 자료조사를 하고 데이터를 본 후에 이야기하는 편이에요.
- Henry
상대방의 업무에 대한 공감에 초점을 맞췄던 Karl과는 다르게 Brandon과 Henry는 직장 내에서의 커뮤니케이션에는 감정을 배제한 논리가 중요하다는 이야기를 했습니다.
사실 회사에서 일을 한다는 것은 각자 전문 기술을 가진 프로페셔널로 인정받았다는 것이기 때문에 어떤 주장에 “그냥”이라는 이유가 붙어서는 안되겠죠.
그래서 이 두 분은 어떤 기능을 배포하고나면 회사의 핵심 지표들이 어떻게 변화하는지도 자세히 관찰했다고 합니다. 그리고 어떤 주장을 할 때 데이터를 가지고 이야기를 하니까 확실히 동료들 간의 미스커뮤니케이션도 줄어들었고, 서로 오해할만한 일도 발생하지 않았다고 하네요.
물론 상대방에 대한 공감과 존중, 그리고 논리는 상반된 개념이 아니기 때문에 함께 공존해야하는 것이 맞지만, 같은 개발자라고 해도 각자의 가치관에 따라서 어느 부분에 조금 더 중점을 두는 지 갈리게 된다는 것을 알 수 있었습니다.
마치며
칫챗은 거의 두 시간 가량 진행되었으며, 포스팅에 작성한 내용 말고도 “하드 스킬이 부족한 팀원을 어떻게 도와줘야하는가”, “일정이 빠듯한 상황에서 타인을 배려할 여유를 만들 수 있는가” 등 많은 주제에 대해서 이야기를 나누었습니다.
그러나 두 시간 가량의 대화 전문을 제한된 공간에 담아내는 것이 힘들 것 같아, 그 중 대표적인 주제 3가지를 선정하여 포스팅을 작성하게 되었습니다.
아무래도 메인 주제가 소프트 스킬과 커뮤니케이션이었다보니, 모든 분들이 평소에 직장에서 동료들과 협업을 진행하면서 느꼈던 많은 생각들과 경험들을 적극적으로 공유해주셔서 더욱 재밌는 자리가 되었던 것 같습니다.
그리고 칫챗은 토론이라기보다 편안한 분위기에서 편안하게 이야기하자는 취지의 스몰 토크 모임으로 기획되었기 때문에 중간 중간에 드립도 섞어가면서 재미있게 이야기했던 것 같네요.
루비콘 멤버들도 이렇게 다른 환경에서 일하는 개발자들과 함께 기술 외적인 주제에 대한 생각을 나눠볼 수 있는 기회가 많지 않았어서 즐거운 마음으로 스몰 토크에 참여할 수 있었습니다.
마지막으로 근처 치킨집에서 치맥을 즐기는 소소한 뒷풀이 사진을 자랑하며 Lubycon 1st Chit Chat 후기를 마칩니다.
