일 잘하는 개발자란?

최근 내가 맡은 회사 프로젝트에 React-Query를 도입하고 그 사용범위를 점차 넓혀가는 작업을 하고 있다. 마이그레이션 작업 자체는 까다롭고 귀찮기도 한데 상당히 재밌게 하고 있다. 아마도 그 이유는 내가 이 기술의 도입을 주도적으로 이끌었기 때문일 것이다. React-Query는 도입해 보고 싶은 기술이긴 했는데 단순히 ‘요즘 다들 많이 쓰니까-‘가 아니라 지금 프로젝트에 구조적인 개선을 가져올 것이라는 합리적인 근거를 기반으로 도입을 결정했다. 나 스스로와 팀원들을 설득하기 위해 ‘왜 도입해야 하는가’에 대해 고민했고 납득할 만한 근거를 찾았다.

그런데 어쨌거나 저쨌거나 React-Query 마이그레이션 작업은 눈에 보이지 않는 개선이기도 하고, 작업량이 며칠 만에 뚝딱 될만한 양은 아니라 항상 최우선 순위로 작업하는 테스크는 아니다. 기획 & 마케팅에서 요구하는 변경 사항이나 다른 피쳐 개발이 있으면 그 업무들이 일 순위가 되고 마이그레이션 작업은 잠시 뒤로 밀렸다가 다른 우선순위 작업이 완료되면 다시 마이그레이션 작업을 하는 식으로 틈틈이 하고 있다. 사실 마음 같아서는 진득하니 마이그레이션 업무만 하고 싶다는 생각이 스멀스멀 피어올랐다. 자꾸 업무 컨텍스트가 스위칭 되는 게 피곤하기도 하고…

이런 업무 루틴 속에서 최근 마케팅팀의 요청으로 했던 우선순위 작업 중 하나가 Facebook pixel 세팅 작업이었다. Facebook pixel은 Facebook을 통해서 우리 서비스에 유입된 사람들의 행동을 트래킹 할 수 있는 유저 트래킹 툴이다. 근데 이거 영, 문서도 불친절한 것 같고, 적용 사례도 잘 안 찾아지고 해서 세팅 작업을 진행하는 내내 귀찮다는 마음이 커졌다. (근데 결과적으로 요거 찾아서 잘 세팅했음 😇)

그리고 생각해 보자구, 내가 이력서를 쓴다고 할 때 “React-Query 도입을 통한 어쩌구 저쩌구…” 한 줄은 쓸지 몰라도, “Facebook pixel 세팅”이라는 한 줄을 쓰게 될까? 이 업무가 나한테 어떤 기술적인 성장이나 깨달음을 주는 것도 아니고 말이야… 흐음’ 뭐 이런 생각들을 하고 있었는데, 순간 이건 지극히 개발만을 위한 개발자의 관점이라는 생각이 들었다.

내가 만약 마케팅팀이였다면 사실 React-Query가 무엇인지 알 바인가? “트래킹 툴 적용 좀 해주세요” 하면 삼십분 뒤에 “적용 됐습니다”라고 말해주는 개발자랑 일하고 싶지 않을까? 그리고 마케팅팀 입장에서는 그런 개발자가 일 잘하는 개발자로 여겨지지 않을까(다소 비약적이긴 하다만…🤔)? 더 나아가서 만약 마케팅팀이 트래킹 툴에서 얻어진 데이터를 기반으로 더 효율적인 전략을 마련하고 그게 수익 창출로 이어진다면, 회사 입장에서도 그게 일 잘하는 개발자 아닌가?

… 음 여튼 서론이 길었는데 일 잘하는 개발자는 하드 스킬이 뛰어난 개발자와 동의어가 아니라는 것을 말하고 싶다. 개인마다 생각의 차이는 있겠지만 적어도 나는 그렇게 생각한다. 그런 점에서 나는 그토록 잘하고 싶어 몸부림치면서도 하드 스킬을 키우는 것에만 너무 집중하지 않았는지 스스로를 되돌아볼 필요가 있겠다.

그런데 일단 나 역시도 그랬고 ‘개발자’라는 역할에 몰입해 일을 하다보면 ‘기술을 위한 개발’에 몰두하게 되는 경우가 많은 것 같다. 하지만 잊지 말아야 할 점은 기술은 목적이 아니라 가치를 실현하기 위한 수단이며, 가치는 사람들이 서비스를 이용함으로써 생길 수 있다는 점이다. 프로 스포츠 선수들에게 관중(팬)이 없다면 그건 그저 공놀이에 그친다. 나는 기술(개발)도 마찬가지라고 생각한다. 제아무리 기술적으로 뛰어난 서비스라고 해도 아무도 사용하지 않는다면 무슨 소용이 있을까? 서비스 위에 기술이 있는 것이 아니라 기술 위에 서비스가 있다는 점을 잊지 말자. 서비스가 생명력을 가지고 있을 때 기술도 그 가치를 더 할 수 있다. 기술을 위한 개발은 사이드 프로젝트나 토이 프로젝트서 충분히 할 수 있다.

​-
근데 참 아이러니하게도 기술을 위한 개발을 할 때 재밌는 경우가 많은 것 같다(…) 그래서 회사의 상황이나 프로젝트의 성숙도가 ‘기술을 위한 개발을 해야 하는 경우일 때’ 개발자가 몰입해서 일할 수 있는 환경이 쉽게 조성되는 듯 하다. 아니면 서비스를 위한 개발 테스크를 쳐내고 기술을 위한 개발을 고민할 시간이 주어지는 환경이라면 그것도 좋겠다.

​-
물론 당연히! 서비스를 위한 개발과 기술을 위한 개발이 항상 따로 있는 것은 아니다. 오히려 두 가지가 공존하는 경우가 많고, 최근에 서비스의 유의미한 개선 + 기술적인 깨달음 포인트가 동시에 왔던 테스트는 모바일 웹 뷰 테스크였는데 이것도 조만간 글로 정리해 블로그에 포스팅할 수 있도록 해보아야겠다.

​-
내가 지금의 업무에 어느 정도 만족을 느끼는 포인트는 조직이 개편되고 내가 메인으로 맡는 프로젝트가 바뀌면서 기술을 위한 개발을 고민할 여유가 조금 생겼고, 시도해 볼 수 있는 환경이 조성됐다는 점이다. 아마 이렇게 조직이 바뀌지 않았다면 이직에 대한 욕구가 훨씬 강렬했을 것이고, 주도적인 성장 포인트를 찾는데에 보다 큰 어려움을 느끼고 있었을 것이다. 내가 지금 할 수 있는 최대한의 것을 하고 최대한의 것을 얻어야 한다.