같이 일하고 싶은 개발자란 무엇일까?
저는 그다지 길지 않은 경력을 가진 3년차 프론트엔드 개발자입니다.
그러나 제 사회생활 경험은 참 다사다난 했다고 생각합니다. 별 일이 다 있었거든요.
다양한 사건들과 환경에 있으면서 늘 주변을 보며 곱씹고, 생각하고, 고민하고, 결심도 하고, 느꼈던 것들이 참 많았습니다.
일 잘하는 개발자? 같이 일하고 싶은 개발자란 무엇일까요?
아무것도 모르던 사회초년생 시절에는 그저 상사 말 잘 듣고 개발을 잘하기만 하면 될 거라고 생각했습니다.
근데 좀 더 사회생활을 해보니 아닌 것 같다는 생각이 들더군요.
어느날 이런 일이 있었습니다.
기획자분이 기획을 했는데, 상대 개발자분께서 "그 기능은 지금 개발하기엔 무리다" 라는 말을 하며 그 이유에 대해 설명을 해주는데 기획자분은 전혀 이해하지 못했던걸 옆에서 지켜봤던 일이 있었습니다.
기획자분이 결국 다시 되물어봐도, 상대 개발자분은 그저 개발자의 입장에서만 설명을 하기에 결국 되물어보길 포기한 기획자분이 결국 관련된 다른 개발자분한테 같은 질문을 또 한다거나, 결국 기획을 수정해야 하긴 하는데 갈피를 못 잡을 때의 모습을 보았을 땐 과연 이게 효울적인 소통 방식인가? 라는 생각이 들기 시작했습니다.
해당 상황에 대한 제 생각은 결국 커뮤니케이션 코스가 늘어나는 비효율적인 상태다라고 생각을 하게 되었습니다.
이런 상황이 점점 누적 되어, 결국 해당 기획자는 그 개발자과의 소통을 꺼려하는 모습들이 보이기 시작했습니다.
이게 과연 팀 문화를 넘어 좋은 프로덕트의 결과까지의 영향을 안 미칠까요?
저는 미친다고 생각합니다
그러면서 제 스스로의 행동도 돌아보면서, 같이 일하고싶은 개발자란 무엇일까? 라는 고민을 하게 되었습니다.
개발자면 개발만 잘하면 된거 아님?
네.. 제가 잘 몰랐던 시절에 했던 생각입니다.
뭐 어찌 되었든 원하는 요구사항에 맞게, 데드라인에 맞게 알잘딱깔센으로 개발을 했으면 된 거 아닐까? 라고 생각을 했습니다.
그러나 이건 매우 잘못된 생각이었단걸 깨달았죠.
회사에 속해 있는 개발자는 프리랜서, 1인 개발자가 아닙니다. 고객의 요구사항을 직접 받아 혼자서만 개발하는 개발자가 아니죠.
프로덕트를 만드는 팀에 속해 함께, 같이 만들어가는 공동체에 속해 있는 인간 1명입니다.
사람 여러명이 모이면 소통이 빠질 수 없습니다. 근데 이 소통이 어려운 사람이 있다? 그럼 말을 걸기가 편할까요? 벌써부터 불편해집니다. 친구 사이에도 그렇잖아요.
정말 오로지 고객의 요구사항에만 개발해야 하는 회사라면 팀 내부에서의 소통이 적을 순 있을 겁니다.
그러나 대게는 요구사항을 정립해 가는 과정에서 기획자, 디자이너, 개발자끼리 긴밀하게 소통을 하는 편이죠.
여기에서 소통이 계속 삐걱거리면 개발 일정이 밀릴 수도 있습니다.
또한 매우 슬프게도 기획자가 길을 잃어버리는 상황이 발생할 수도 있다고 생각합니다.
뭐가 되었든 프로덕트를 눈앞에 실물로 만드는 사람은 개발자이기에 여기서 개발자의 소통 역량이 중요하다고 생각합니다.
이 소통이 잘 이루어지면 개발 기간도 크게 단축될 수도 있고, 요구사항과 방향성이 빠르게 잡힐 수도 있다까지 저는 생각합니다.
그럼 어떻게 소통을 해야 하는 건지?
개인적으로 개발자분들이 쉽게 실수하는 부분이 뭐라고 생각하냐면 바로,
개발 뽕에 취해 개발자만 알아들을 단어들로 소통하는 것.
네, 저격 아닙니다. 제 이야기입니다. 제가 이랬습니다.
물론 사회초년생 시절에는 엄청 주눅 들고 다녔기에 말할 기회는 적었습니다만^^...ㅋㅋ
저런 식으로 말하는 사람들 보면 멋지고, 간지나 보였습니다.
근데 시간이 지나고 보니, 슬슬 주변들의 반응과 시선들이 보이기 시작하더라고요.
그렇게 설명하는 개발자 스스로는 완벽한 설명이었을지라도, 설명을 듣는 비개발 직군들은 점점 안광이 흐려지더군요.
반면, 누구나 알아듣기 쉽게 설명해 주는 개발자와 소통하는 주변 사람들을 보면 기분 좋음을 넘어서 재밌어하고 신나 하시는 분들도 계셨습니다.
저 같은 경우, 첫 회사에서 이사님이 늘 하시던 소리가 있었습니다.
"제 3자도 알아볼 수 있게 작성해라"
사실 그 당시에는 이 말을 크게 이해하지 못했습니다.
이미 충분히 설명한 것 같고, 시각적으로도 잘 표현한 것 같은데 왜왜왜왜! 계속 수정을 하시라는 걸까!!라고 생각했죠...ㅋㅋㅋ
당시 그분께서 말하시던 제 3자는 이 정도의 범위였습니다.
"해당 서비스 또는 제품을 아예 모르는 사람도 이해할 수 있는 수준"
아마 회사 서비스 특성상 아무것도 모르는 사람들에게 우리 솔루션을 설명해서 영업을 해야 했기에 더 강조하신 것 같습니다.
저는 그 당시 첫 회사에서의 배움(?) 덕분에 늘 누군가에게 기능적으로 설명을 해야 할 때 엄청 풀어서 설명하려고 노력합니다.
평소에도 늘 이런 편이 긴 했으나, 점점 사회생활이 쌓이면서 다양한 걸 경험해 보니 이게 정말 중요한 능력이구나 싶더군요.
이 부분에 있어서 그 이사님께 감사한 마음이 있습니다.
꼭 개발 직군만 해당되는 이야기는 아니다
제가 처음으로 요즘 느낌 낭낭한(?) IT 기업으로 이직하면서 경험했던 일입니다
그전 회사는 아빠뻘 분들이 많으시고 뭐랄까.. IT 기업이긴 했으나, 전통적인 기업?의 느낌이 강했습니다.
그렇다 보니 요즘 기술툴보다는 PPT, 엑셀을 많이 사용하고, 소통도 정말 전통 기업에서 쓰는 용어들로 가득했습니다.
근데 그다음 이직한 회사에서는 영어와 처음 듣는 단어들이 난무하더군요(?)
이젠 잘 기억이 안 나는데... 어떤 식인지 예시를 들어보면 아래와 같습니다
- 스크럼 -> 회의
- PoC -> 기술 검증
- QA -> 단위 테스트 / 기능 테스트
- 백로그 -> 업무
- 스프린트 -> 애초에 이런 말을 안 씀
- 오프보딩 -> 인수인계
- 온보딩 -> 신입 교육
이땐 개발이고 뭐고 간에 회의할 때마다 나오는 모르는 단어들 때문에 너무 힘들었습니다.
이젠 익숙해져서 다 알아듣지만, 사실 아직까지도 굳이... 한글 냅두고 영어로 써야 하나? 싶은 단어들이 몇 개 있긴 합니다. (이건 개인 차이, 성향이긴 합니다)
쨌든, 꼭 개발 직군이 아니더라도 디자이너, 기획자 사이에서도 그들만이 쓰는 단어가 있습니다. 또는 같은 단어이인데 각자의 영역에선 다른 의미를 가진 단어들도 있고요. 그렇다 보니 혼란을 야기할 때도 있는 것 같습니다.
그럴 땐 최대한 대체할 수 있는 단어로 쓰거나, 아님 미리 팀 내부에서 업무 용어, 지칭하는 단어 등등을 미리 정의 내리고 가는 것도 좋을 것 같습니다.
이런 문서는 나중에 새로 들어오신 분께 소중한 온보딩 자료가 되지 않을까 싶습니다.(저 진짜 처음에 못 알아들어서 식은땀 엄청 흘리고 힘들어했거든요 ^_ㅠ.....)
마무리
결론은 개발자는 개발 실력뿐만이 아니라,
타 직군과도 유연하고 원활하게 소통하는 개발자가 팀에 있어서, 누구에게 든 간에 같이 일하고 싶은 개발자가 아닐까 싶습니다.
물론 개발 실력이 무조건 갖춰진 다음에 일이죠. 개발자가 데드라인 못 지키고 개발 못하면 큰 문제니 까요.
특히나 이 소통 역량은 연차가 쌓일수록 더더더 중요해지는 것 같습니다.
내 상사가, 또는 우리 팀 팀장이 소통을 못하면 그 밑에 있는 팀원들이 많이 고생을 하더라고요.
물론 주니어인 제가 지금 이러쿵저러쿵 하는 게 좀 웃길 순 있습니다.
제가 이 고민을 벌써부터 하는 이유는 제 스스로가 찔려서입니다.
난 우리 팀원들에게 좋은 구성원일까? 같이 일하고 싶은 개발자일까? 나랑 일하기 싫어서 뒤에서 욕하려나? 라는 자책에서 시작된 고찰입니다.
제 스스로 생각하기에 제 커뮤니케이션이 매끄럽다고는 생각하지 못해서, 늘 커뮤니케이션 부분에 있어서 고민이 많은 저에게는 꼭 필요한 고찰이었던 것 같습니다.