개발자의 커뮤니케이션 : 도와주세요 개발자 여러분

Jiwon Lee·2024년 3월 18일
1
post-thumbnail

이번 동아리 신입 부원 리크루팅을 하고 면접을 보면서 커뮤니케이션의 중요성을 뼈저리게 느끼는 계기가 되었다... 그래서 집에 와서 나중에 신입 부원들을 위해 세션을 하려고 이런 저런 강의를 찾아보며 좋은 개발자의 커뮤니케이션에 대해서 고민해보고 내 경험까지 담아서 정리해봤다. 이미 커뮤니케이션 고수인 분들은 최하단의 내용을 참조해주세요... 도움이 필요합니다!!

개발자에게 좋은 [[커뮤니케이션]]이란

@인프콘 2023 : 커뮤니케이션 잘하는 개발자의 4가지 습관
@https://zdnet.co.kr/view/?no=20160718075808
@https://youtu.be/A2qxIrNIzhk?si=Jwv4-CLcpE70dkZD

좋은 개발자란

커뮤니케이션을 잘 하는 개발자? 협업을 잘 하는 개발자?


다른 직군과의 요구사항 커뮤니케이션

일을 하기 위한 커뮤니케이션

가장 협업하기 어려운 개발자

"그냥 개발 구조 상 안 돼요"라고 하는 스펙 구현형 개발자

-> 왜 안 되지? 그러면 방법은 없나? 당연하다는 듯이 말하니 다시 물어보기도 어려움
-> 개발자 = 스펙을 주면 잘 구현하는 사람 이라고 생각해서 저렇게 말하는 것
-> 이유 = 구현에 집중하는 바람에 시야가 좁아짐

커뮤니케이션을 잘 하는 개발자

문제 해결형 개발자 = '안 된다'라는 말을 그냥 하지 않음

즉 문제의 의도와 맥락을 이해해서 더 좋은 스펙을 만들어내는 것
-> 서비스의 개선과 문제 해결에 집중 !

그렇다면 어떻게 변화해야 할까?

커뮤니케이션 = 습관
따라서 아는 것만이 아니라 실제로 지속적으로 행동하는 습관이 필요함

1. 요구사항을 들을 때 해결하려는 문제와 의도에 대해 묻기
  • 혹시 이건 어떤 문제를 해결하려고 하는 걸까요?
  • 이 기능이 나온 의도나 맥락은 무엇인가요?
  • 그렇게 생각하신 이유가 있나요?
2. 말을 듣고 바로 답하는 대신에 내가 이해한 바를 공유하기
  • 상대방의 요구사항을 이해한 대로 정리하고 ~ 라고 이해했는데 맞을까요?
  • 요구사항이 명확하지 않을 경우 명확해질 때까지 물어보기
3. 안 된다고 말할 때는 상대방의 관점에서 대안 제시하기
  • 상대방이 왜 안 되냐는 질문을 하는 것은 '왜 기술적으로 어려운지' 이해하는 것이 아니라
    그렇다면 어떻게 해야 문제를 해결할 수 있는지 알고 싶은 것임
  • 이유를 길게 설명하는 대신에 제약을 덜 받는 다른 방향성이나 대안 제시
4. 문제를 해결할 또다른 방법을 고민해보기
  • 된다 / 안 된다의 흑백 논리에 갇히지 않기 -> 섣불리 결론내지 않기
  • 다른 사람들의 의견을 꼭 물어보기

아래는 사실 우리 동아리의 경우 타 직무와의 교류보다는 백엔드-프론트 간의 협업이 주된 커뮤니케이션 목적이고, 첫 프로젝트인 사람들이 많다는 점을 감안하여 내 경험을 토대로 써본 이야기다.

개발자끼리 협업할 때의 커뮤니케이션

명확하고 간결하게 이야기하자

너무나 당연한 이야기이지만 이걸 어려워하는 분들이 많다
질문 받지 않은 내용에 대해서 자기방어를 위해 대답하지 말자
횡설수설하거나 웅얼거리지 말고 충분히 생각한 뒤 이야기하자
간결하게 이야기 한답시고 상황이나 주어를 생략하는 실수를 범하지 않도록 주의하자

같은 곳을 바라보는 것이 중요하다

팀으로 개발하고 협업하기 위해서는 프로덕트에 대해서 동일하게 이해해야 한다
개발을 시작하기 전에 그라운드 룰과 함께 기획과 목적에 대한 생각도 일치시켜야 한다

구글과 ChatGPT는 좋은 도구이지만 언제나 정답은 아니다

구글과 ChatGPT는 단순한 오류나 지식을 건네줄 수는 있지만
프로덕트의 fit과 팀이 구현하고자 하는 것의 의도까지 알아낼 수는 없다
'어떻게 구현해야 할지 모르겠을 때'는 팀원들과 의논을 해보자
혼자서 문제를 오래 끌고가면 오히려 협업에 독이 된다

개발자끼리는 코드로 소통하는 게 편할 때가 있다

코드 리뷰는 검토 도구로 사용되기도 하지만
개발 중 불필요한 커뮤니케이션을 줄이기 위한 소통 기술로 쓰이기도 함
-> 뭔가 문제가 있다면 구구절절 말로 설명하지 말고 에러 메시지와 코드를 놓고 이야기를 나누자

  • 먼저 코드를 보고 말하자.
  • 가능하면 읽기 쉽고 단순하게 코드를 짜자.
  • 꼭 100점에 집착하지 말자. (특히 해커톤에서 !!)

잘 듣고, 잘 물어보자

본인이 의견을 잘 내는 성격이라고 해서 의견이 없는 사람을 답답해하면 안 된다
성향 차이를 인정하고 먼저 의견을 물어보고 이끌어내는 사람이 정말 협업을 잘 하는 것이다

상대는 내가 아니라는 걸 명심하자

아무리 좋은 의도를 가진다고 해도 의도한 결과의 100%를 기대하긴 어렵다
하지만 타인의 행동에 대해 평가를 내리고 판단하려고 하지 말자

누구에게나 배울 점은 있다

본인의 프라이드, 자존심은 조금씩 내려놓자. 코딩 실력과 커뮤니케이션 실력과는 관계 없이 누구에게나 배울 수 있고 무조건 옳은 사람은 없다.


그런데 이제 문제가 생겼다! 이런 이야기를 내 주관적인 경험만으로 쓰는 건 좋지 못한 일인 것 같아서 고민이다. 정기 운영진 세션에서 이러한 내용을 발표했지만 크게 더 얻어낸 이야기가 없어서 아쉬웠다.

아래 내용에 대한 꿀팁, 노하우가 있거나 커뮤니케이션에 있어서 중요하게 알아야 할 점이 있다면 꼭! 제발! 댓글 달아주세요 여러분! 프로젝트 초짜 대학생들을 살려주십시오 ...

  • 감정적이고 이기적인 어투를 사용하는 사람을 만났을 때는 어떻게 상대해야 할까
  • 배우거나 성취할 의지가 없는 팀원의 의지를 돋궈주려면 어떻게 말하고 행동해야 할까
  • 소통을 하지 않거나 연락을 무시하는 팀원을 어떻게 상대해야 할까 (저는 그라운드 룰을 정하거나 집착광공이 되어 전화를 하긴 합니다 ...)
profile
노는 게 제일 좋은데 공부는 하고 싶어요 😗

0개의 댓글

관련 채용 정보