'이 개발자가 내 개발자다' 왜 말을 못 해!
이전에 '같이 일하고 싶지 않은 개발자 특'에 대해 다뤘는데 생각보다 많은 개발자분들이 좋아해 주셔서(?) 이번 편은 같이 일하며 내게 감동을 주셨던 같이 일하고 싶은 개발자분들 특징에 대해 말해보려고 한다.
시대의 문제였는지, 회사의 문제였는지, 업무방식(애자일/워터폴)의 문제였는지 모르겠지만 10년 전만 해도 개발자는 그저 기획서 그대로 뚝딱 개발해 주시는 말수 적고 친해지기 어려운 사람들이라는 생각이 강했다. 하지만 시간이 점차 흐르고 개발자들과 일하는 시간도 많아지고 정말 많은 개발자들을 만나며 서서히 개발자에 대한 인식이 변해왔다.
'아이디어가 너무 좋은데?' '글을 왜 이렇게 잘 쓰지?', '비즈니스적인 고민이나 고객 관점에서의 고민도 같이 해주셔서 너무 감사하다' 등의 생각들을 하게 만드는 분들을 만나며 많은 것을 느끼고 배웠다.
이번 편에선 그동안 만났던 개발자 중 나의 성장에 도움을 주고, 감동을 줬던 개발자들에 대해 다뤄보려고 한다. 지극히 주관적인 입장에서 정리되었으니 '개발자는 이래야 한다'라는 생각을 하진 않았으면 좋겠다. 그냥 재미있고 편하게 읽어나가길 바란다.
중간에 기획자 두고 개발 간 핑퐁하지 않고 직접 커뮤니케이션 '내가 알아서 해결할게형'
다녔던 회사 중 가장 인원수도 많고 큰 기업에 재직중일 때였다. 큰 기업답게 개발자가 정말 많았고 파트별로 모두 쪼개져 있었다. 작은 규모의 회사에서 업무 할 때와는 달리 처음에는 '와! 개발자 진짜 많다. 너무 좋다!'라는 생각과 함께 기대가 엄청 높았다. 입사 후 여러 프로젝트를 다양한 부서의 개발자들과 하면서 정말 많은 개발자들과 업무를 진행했다. 개발부서가 크게는 백엔드, 프론트, 앱 개발팀으로 쪼개져 있었고 작게는 서비스 내 도메인과 기능 단위(주문, 쿠폰 등)의 개발자로 나뉘어있었다. 그러자 생각지 못 한 스트레스가 찾아왔다. 개발자 간 협업이 필요한 상황이나 커뮤니케이션이 필요한 경우 개발자 간 직접 커뮤니케이션을 하지 않는다는 것이었다.
1차 대화
프론트 개발자: 이거 API 개발 필요한데, 백엔드 개발자랑 이야기되었어요?
나: 저번 기획서 리뷰 드릴 때 백엔드 개발자분들도 참석하셔서 이해하고 계세요. 혹시 구체적으로 어떤 API 개발을 요청드려야 해요?
프론트 개발자: 이거 프론트에 노출해 주려면, ~~ 한 API 개발이 필요해요. 이 부분 요청해 주세요.
.
.
2차 대화
나: 안녕하세요~ 프론트 개발에서 ~한 API 개발해서 달라고 하시는데 이 부분 개발 후 전달 가능할까요?
백엔드 개발자: 어떤 API 개발이요? 그거 이미 있는 API 호출하면 돼요. ~~ API 호출하라고 해요.
.
.
3차 대화
나: 백엔드 개발자한테 여쭤보니 ~~ API 호출해서 사용하면 된대요.
프론트개발자: 그 API 봤는데, 안되던데요. 기존 API로 사용 못 하고 새로 개발해야 돼요. ~한 부분이 빠져있어요.
나: (그냥 둘이 말하면 안 되나..?)
거의 매번 무슨 개발을 하든 간에 프론트, 백엔드뿐만 아니라 웹, iOS, AOS 개발자 간의 커뮤니케이션도 직접 하려고 하지 않았다. 마치 내가 한 마리의 앵무새가 된 양 누군가의 말을 전하고, 또다시 전하고 하는 등 비효율적인 커뮤니케이션이 잦았다. 미팅과 단톡방을 통해 이야기하는 것도 한계가 있었다. 개발을 하다 추가로 필요한 API가 있으면 그걸 또 나에게 디엠으로 요청했다. 그렇게 커뮤니케이션으로 녹초가 되어가던 중 신규 프로젝트를 하게 되었는데, 그때 그저 빛과 같은 프론트 개발자를 만나게 되었다.
프론트 개발자: 이거 찾아보니까 API 없어서 개발해야 될 것 같아요.
나: 네, 그럼 ~~ 부서에 API 개발 요청드리면 되죠?
프론트 개발자: 아니요, 제가 벌써 요청드렸고 언제까지 전달 주시기로 말씀해 주셨어요. 이게 기존에는 어떤 API를 쓰고 있었는데 여기에 빠져 있는 부분 있어서 이러한 부분 추가해 달라고 요청드렸어요.
나: 네 ㅇ_ㅇ??????? 벌써 커뮤니케이션하셨다고요?♥ (무한 하트 발사)
그 간 개발자가 직접 커뮤니케이션하지 않았기 때문에 '회사 내 금기인가?'라고 생각할 정도였는데, 직접 커뮤니케이션을 하고 어떤 부분에 대한 커뮤니케이션을 했는지 공유까지 해주는 개발자라니! 감동에 도가니였다. 이후 기획자들과 커피를 마시면서 이 이야기를 하니, 역시 사람 생각이 다 똑같은지 '맞아 맞아, 그 개발자분 내 최애야!' 등의 긍정적인 반응이 많았다. 그리고 다들 이 개발자와 프로젝트를 함께 하기를 원했다.
고려하지 못한 케이스를 짚어주는 꼼꼼함과 히스토리 설명까지 해주는 완벽함! '넌내게감동이었어형'
이직을 하고 첫 프로젝트를 하면서 운 좋게 너무 좋은 개발자를 만났던 기억이 난다. PO로의 업무가 참 쉽지 않다고 생각했는데 이 분 덕분에 많은 프로젝트를 수월하게 해내어 지금도 감사하게 생각하며 인연을 이어가고 있다. 기존에 있던 위젯을 개선하는 업무를 맡게 됐을 때였다. 사내 컨플루언스에서 아무리 자료를 찾아도 원하는 자료가 나오지 않아 히스토리 파악에 애를 먹고 있다 스크럼 시간에 이러한 고충을 이야기했다.
나: 현재 PRD 작성 중이고, 히스토리를 파악하고 있는데 문서를 찾아도 원하는 자료가 나오지 않네요ㅠㅠ 최대한 찾아보겠지만 완벽한 히스토리 파악은 어려울 수 있을 것 같아요..
개발자: OO 위젯에 대한 히스토리 말씀하시는 거죠? 제가 어디서 문서를 봤던 것 같은데..
나: 네네, 맞아요. 제가 다시 한번 찾아볼게요.
개발자: 네네
스크럼 미팅이 끝나고 다시 문서를 찾기 시작했다. 그러던 중 온 개발자의 디엠
개발자: OO님이 찾으시던 문서가 아닐 수 있지만 히스토리 파악에 도움이 될 수 있을 것 같은 문서 전달드립니다. 1. ~~ 문서와 2.~~ 문서입니다. 개발 쪽에서도 확인할 수 있는 부분 확인해 봤는데, ~~ 이렇게 개발되어 있는 거 봐서는 ~~ 한 배경을 가지고 만들었던 것 같아요.
나: 헉, 이렇게까지 안 해주셔도 되는데, 너무 감사합니다! (세상에...♥)
텍스트로 말해서 느껴지지 않았겠지만 나는 이 디엠을 받는 순간 눈에서 하트가 발사됐었다. 정말 너무너무 감사하다는 생각과 감동이 밀려왔다. 찾기 어려운 문서도 직접 찾아주시고, 어떻게 개발되어 있는지 요청드리기도 전에 먼저 파악해 주시다니.. 그저 빛인가..?
이후 프로젝트를 이어가던 중 최대한 고려한다고 했지만 누락된 케이스가 발생했다.
개발자: 개발하다 보니 OO 케이스가 추가로 정의되면 좋을 것 같은데, 정리해 주실 수 있으실까요?
제가 생각했을 때 A안과 B안 중 하나로 정의되면 좋을 것 같은데 A안은 ~ 방식이고, B안은 ~방식이에요. 들어가는 개발 리소스는 거의 비슷해서 고객 경험 고민하셔서 의사결정 해주시면 됩니다.
나: 넵넵, 너무 감사합니다! 의사결정 후 공유드릴게요.
커뮤니케이션부터 에티튜드까지 완벽하다고 생각했다. 사실 어떤 케이스가 누락된 경우 많은 개발자들이 'OO케이스 고려되지 않은 것 같은데 추가 필요할 것 같아요.'에서 끝나는데 이 개발자분은 누락된 케이스와 더불어 본인이 고민한 여러 가지 안에 대해서도 의견을 주셨다. 그리고 의사결정은 PO에게 요청하는 센스. 누락된 케이스가 발생하면 PO는 그 케이스에 대해 고민하는 시간과 케이스 정의 후 개발 리소스가 얼마나 들어갈지에 대해 다시 개발자와 커뮤니케이션해야 하는데 이 분은 본인의 시간을 들여 케이스를 고민해 주시고, 개발 리소스까지 고려한 후 피드백을 주셨다. 이러한 피드백을 받고 나는 확실히 그동안 같이 업무 했던 개발자들과 다르다는 느낌을 많이 받았다. 만약 사업을 하게 된다면 높은 연봉으로 이런 유형에 속한 개발자 분을 모셔가고 싶다고 생각했다.
고객 관점에서 고민을 같이 해주는 '내가 고객이라면형'
이러한 유형은 애자일 조직에서 많이 만날 수 있다. 방법론 특성상 프로젝트 시작 단계부터 함께 협업하다 보니 최근에 많이 만나게 되었다. 기존에는 워터폴 방식에서 업무를 해서 기획/개발/디자인 고민 따로 하는 경향이 강했는데 애자일 조직에서 업무를 하다 보니 아이디어 뱅크인 개발자분들을 많이 만나게 됐다. 타깃 고객 연령층이 50대인 프로덕트를 담당할 때 '상품 상세페이지를 확대해서 볼 수 있는 기능'을 추가하는 프로젝트를 진행했었다. 확대 기능 제공 시점에 대해 상세 페이지에 특정 시간 이상 머물렀을 때 노출한다고 기획했는데 개발자가 아래와 같이 말했다.
개발자: 기획대로 구현하려고 했는데, 고객 입장에서 생각해 보니 관심 있는 상품이라면 상세페이지에서 대부분 특정 시간 이상 머무를 것 같습니다. 이 경우 대부분의 고객에게 확대하기 기능이 안내될 텐데 상품 탐색에 방해가 될 수 있을 것 같아요. <더보기> 등의 추가적인 액션이 확인될 때 노출해 주는 건 어떨까요?
나: 확대하기 기능을 고객에게 안내해 주는 것에 초점을 맞춰 생각했는데, 탐색에 방해될 수 있겠네요. 제안 주신대로 하시죠.
슬랙과 허들로 이런저런 이야기가 이어졌는데, 각색하면 위와 같은 대화로 요약할 수 있다.
위와 같이 대화가 끝나고 실제로 개발자가 제안해 주신 대로 고객이 상품 탐색 시 방해받지 않게 정책을 변경하여 배포했다. 위 케이스 아니더라도 이 개발자분은 고객 입장에서 고민해 보고 여러 제안을 주시기도 하셨고, 성과 분석을 공유해 드리면 분석 결과에 대해 미처 생각지도 못 한 의견도 많이 주셨다. 처음에는 개발자가 더 좋은 의견을 제시하거나, 내가 분석한 결과와 다른 의견을 주셨을 때 '왜 나는 이런 생각을 못 했지?'라는 자책을 했었는데 어느 순간부터는 '오! 이렇게도 생각할 수 있겠네. 좋은 의견 주셔서 너무 감사하다!'로 바뀌었다. 기획자라고 항상 정답만 말할 수 없다는 것을 스스로 깨달았기 때문이다. 그리고 다시 한번 생각해 보니 오히려 생각지 못한 아이디어를 말씀해 주시고 제안 주신 부분이 너무 감사하게 느껴졌다. 특히 프로젝트를 같이 만드는 느낌이 강하게 들었다. 또, 같이 일하며 점점 개발에 대한 신뢰가 쌓여 이 분이 개발 담당자로 배정되면 너무 든든하고 좋았다.
위에 정의한 대표 케이스 외에도 정말 좋은 개발자분들을 많이 만났다. 특히 연차가 좀 있거나 C레벨의 개발자분들은 알아서 뚝딱뚝딱 만들어주시는 경우가 굉장히 많았다. PO의 일을 조금이라도 덜어주시거나 같이 고민하고 해결해 나간다는 느낌을 주시는 경우도 있었다. 이러한 케이스도 추가하여 쓸까 고민했지만 직책에 따라 고민의 깊이와 넓이가 다를 수 있을 것이라고 생각하여 프로젝트를 하며 만났던 '실무 개발자' 위주의 케이스로 글을 전개했다.
사실 업무를 하며 많이 느낀 부분은 개발의 능력치보다 중요한 건 업무를 대하는 에티듀드와 커뮤니케이션이라는 것이다. 동료 PO들과 우스갯소리로 '일을 진짜 못하는데 커뮤니케이션은 좋은 개발자 vs 일은 진짜 잘하는데 커뮤니케이션 안 되는 개발자' 중에 골라야 하는 밸런스게임을 하면 대체로 '커뮤니케이션 좋은 개발자'를 고른다. 둘 다 일하기 쉽지 않지만 그럼에도 불구하고 '대화가 안 통하는 사람'과는 일이 진행조차 되지 않기 때문이다. 또, 프로젝트는 혼자 하는 게 아니라 다 같이 진행해야 하는데 본인이 잘하고 능력 있다고 독단적으로 진행해 버리면 트러블이 일어나기 십상이다. 이 경우 프리랜서나 1인 창업을 하면 잘 맞을 수 있겠다.
그동안 만난 많은 개발자들 중 지금까지도 친분을 이어오는 개발자들이 꽤 있는데, 이러한 분들과 가까이 지내며 알게 된 또 다른 사실은 대체로 '덕업일치'한 개발자들이라는 것이다. 하루 업무를 마치고, 같이 맥주를 마시며 업무 이야기를 하다 보면 그들 눈빛은 반짝반짝 빛이 난다. 개발 이야기를 하는 내내 즐겁고 행복해하는 게 보인다. 오랫동안 개발을 해왔음에도 여전히 좋아하고 배우려고 한다. 나는 이런 개발자들이 '야근이 너무 많아 힘들다. 워라밸이 없어 힘들다'라고 하는 말을 들어본 적이 없다. 이들은 일 자체를 즐기므로 굳이 일과 삶을 분리할 필요가 없기 때문이다.
내 지인들도 일 얘기할 때 나를 보면 눈빛에서 일을 너무 좋아하는 게 보인다는 이야기를 종종 했었는데, 그때는 스스로 잘 인지하지 못했는데 일 좋아하는 개발자들과 이야기하다 보니 지인들이 말한 그 눈빛이 무슨 눈빛인지 알게 되었다. 자연스레 가까이서 보는 이들의 열정에 나 또한 동기부여를 받고, 더 열심히 공부하고 최선을 다해야겠다는 다짐도 하게 되었다. 앞으로도 현재에 안주하지 말고 더 나아가 뛰어난 역량을 가지신 멋진 분들과 만나 함께 배우고 성장해 나가고 싶다.