기술 지식 홍수 속, 개발자는 무엇을 위해 기술을 습득해야 할까?
F-Lab : 상위 1% 개발자들의 멘토링
개발자 커리어를 쌓아 가면 언젠가는 시니어 개발자가 됩니다. 시니어 개발자로서 기술적 스킬도 물론 중요하지만(오히려 기본적인 요소라고 봐야겠죠?) 소프트 스킬과 같은 태도와 마음가짐도 꼭 갖춰야 합니다. 그것이 행복하게 개발을 하면서 유저에게 사랑받는 서비스를 만드는 길이기 때문입니다.
기술 지식 홍수 속에 우리는 무엇을 위해 기술을 습득해야 하는지에 대해 생각해 보고 어떠한 태도를 가지고 개발자로 살아갈 것인지 생각해 보면 좋을 것 같아 글을 작성했습니다. 각 중요하게 생각하는 가치가 달라서 차이가 있을 수도 있지만 참고가 되고 도움이 되었으면 좋겠습니다.
유저 관점에서 생각하는 태도
개발자는 세상을 이롭게 하는 아이디어를 구체화하는 사람입니다. 출시한 서비스를 사용자들이 많이 이용해 더 나은 세상이 된다면 더할 나위 없이 보람차고 행복감을 느끼죠.
하지만 사용자들이 서비스를 이용하지 않으면 무용지물입니다. 잘 사용하지 않는 이유는 여러 가지가 있을 겁니다. 시장 조사 실패, 매력적이지 않은 기능, 사용 불편함, 경쟁 실패, 서비스 신뢰도 하락 등..
결국 서비스는 유저에게 사랑받아야 유저, 개발자, 회사 모두 윈윈하는 구조입니다. 그렇기 때문에 사용하기 유용하고 편리한지 항상 자문하면서 구현하는 태도가 필요합니다.
다시 말해, 주어진 대로 찍어내듯 개발하는 것을 경계해야 합니다. 구체화시키는 과정에서 자칫하면 의도와 다른 서비스가 개발될 수 있고 이는 서비스가 사랑받지 못하는 이유 중 하나가 될 수 있기 때문이죠. 유저에게 영향도가 큰 기능이거나 대형 프로젝트를 진행할 때는 조금 더 유저 관점에서 개발하는 태도가 필요합니다.
그럼 구체적으로 어떤 태도를 말하는 걸까요?
- 기획 검토 시점에서 참여할 수 있다면 참여하여 구현 관점에서 이슈는 없는지 유저 입장에서 고려가 되었는지 함께 고민하는 태도
- 기획 의도를 확실히 파악하고 개발하고 있는 것인지 자문하는 태도
- 기획 내용이 유저에게 정말 도움이 되는 것인지 의심하는 태도
사실 기획 검토 시점부터 참여하여 의견을 내고 고민을 하게 되면 필연적으로 회의 시간이 늘어날 수도 있고, 기존에 하고 있는 개발 업무와 겹쳐 시간이 촉박할 수도 있을 겁니다. 현실적으로 어려운 문제죠. 하지만 이러한 태도를 가지고 서비스를 구현한다면 유저에게 사랑받는 서비스가 되지 않을까요?
또한 기획이 아무리 잘 나왔다고 하더라도 개발 관점에서는 또 다른 얘기일 수도 있습니다. 기존 히스토리에 의해서 의도대로 할 수 없는 경우도 있고, 개발 설계나 성능을 고려하여 역으로 더 좋은 방법을 제시하기도 합니다. 이러한 과정들이 모여 유저에게 사랑받는 서비스가 된다고 생각합니다.
NEXT를 고민하는 태도
혼자 개발하고 서비스를 운영하는 경우는 거의 없습니다. (혼자 하더라도 결국 다른 누군가는 코드를 인수인계 받게 됩니다.) 대부분 팀으로 일하며 누군가는 나의 코드를 보고 수정을 할 수 있습니다.
그러려면 가독성이 있어야 하고 수정하기 쉬워야 합니다. 테스트 코드로 뒷받침되어 수정에 대한 사이드이펙트를 최소화해 유지보수도 쉽게 할 수 있게 해야 합니다.
이러한 이유로 개발할 때 코드 가독성은 어떠한지, 코드 변경은 쉬운지, 테스트 코드로 기능 검증이 이루어지고 있는지 확인하는 태도가 꼭 필요합니다. 무술을 연마하듯이 이러한 능력을 키우기 위해서는 클린코드, 리팩토링, 디자인패턴, 테스트 코드 관련 지식을 꾸준히 학습하여 어제보다 더 나은 코드를 작성하도록 노력해야 합니다.
서비스 오픈은 끝이 아니라 시작입니다. 잘 서빙되고 있는지 APM과 알람 로그 등을 잘 구축해 놓고 모니터링이 잘될 수 있도록 하여 문제가 발생해도 빠른 대응으로 서비스 신뢰도를 높여야 합니다.
팀에서의 나의 태도
결론부터 말씀드리면 공유와 더 좋은 문화를 실천하려는 태도를 갖춰야 합니다. 시간을 들여 문서화한 것을 공유함으로써 동료들의 검색 및 학습 리소스를 아낄 수 있게 해주는 마음이 중요하다고 생각합니다.
공유할 내용은 무수히 많습니다. 이슈 사항에 대한 정리 문서, 프로젝트 회고, 장애 처리, 코드 개선 사항, 기술 공유 등이 있겠죠. 결국 이것은 팀 효율을 높이고, 정말 필요한 부분에 집중할 수 있게 합니다.
문화를 실천하는 태도라고 거창하게 말하긴 했으나, 현재에 안주하지 않고 더 좋은 환경과 분위기를 만들자는 것입니다. 업무를 하다 보면 불필요하게 사람이 수동 작업을 하는 경우가 많은데 그러한 과정을 인지하고 자동화를 고민해 적용하는 것입니다. 예를 들면 git hook을 이용하여 원격저장소에 commit이나 push를 하기 전에 코드 포맷팅을 자동으로 수행할 수 있도록 하여 업무 효율성을 높이는 것입니다.
코드리뷰도 예시가 될 수 있습니다. 리뷰를 하다 보면 자연스레 그라운드룰이 필요한 순간이 생기게 됩니다. PR 요청 내용, PR 사이즈, 리뷰 범위 등 업무할 때 이러한 순간이 필요하다고 느낀다면 이것을 같이 협업하는 동료들에게 알리고 소통하여 결정하는 과정이 더 개발하기 좋은 환경을 만든다고 생각합니다.
성장하려는 태도
개발자는 많은 도구(툴)와 각종 기술을 잘 알고 사용할 줄 알아야 합니다. 시간이 흐를수록 더 좋은 기술이 나오기 때문에 사용에 적합하다면 습득하고 적용할 줄 알아야 합니다. 기술 컨퍼런스나 블로그에 관심을 기울이고 특정 서비스에서 어떤 문제를 해결하기 위해 어떠한 기술을 적용했는지 관심을 가지면 좋습니다. 이해하기 어려운 부분도 많겠지만 “이 기술은 이러한 문제를 해결하기 위해 적용됐구나.” 정도로만 이해해도 충분하다고 생각합니다. 추후에 비슷한 문제를 직면했을 때 생각해 내어 적용하면 되기 때문입니다.
Github Repository에서도 다양한 주제로 알짜배기 좋은 내용을 모아 놓은 곳도 많기 때문에 지속적으로 관심을 가지고 검색해 보는 것도 도움이 됩니다.
그러나 신기술을 무조건 따라야 된다는 의미는 절대 아닙니다. 지금 당장 쓰지도 않는 것을 공부해 봤자 잊어버리기 쉽고 기술들은 산더미같이 많습니다. 이보다 기술을 빠르게 습득하고 그것을 Production 환경에서 적용하는 능력 자체를 키우는 것이 훨씬 중요합니다. 즉 메타인지를 하는 것이지요.
그래서 저는 기술 습득에 관한 블로그를 읽어 어떻게 접근하면 좋은지 생각하기도 하며 영어 레퍼런스를 더 잘 이해하기 위하여 자주 나오는 영단어를 찾아보거나 영어 문장에 익숙해지기 위해 의도적으로 영어 레퍼런스를 읽기도 합니다. 기술 습득을 잘하기 위한 고민에서 나온 실천이라고 봐주시면 되겠네요.
다시 돌아와서 개발자는 환경과 목적에 따라 그에 맞는 기술셋이 필요하며 그러한 상황에서 잘 알고 사용할 줄 알아야 하기 때문에 상대적으로 다른 직업 보다 새롭게 습득해야 하는 상황이 많이 발생하게 됩니다. 이 밖에도 소프트스킬에 대한 능력을 키워 더욱 능력 있는 개발자가 되려고 노력해야 합니다. 때문에 현실에 안주하지 않고 개선하기 위해 꾸준하게 회고하고 성장하려는 태도가 필요합니다.
글을 마치며
여러 각도에서 개발자로서 가져야 할 마음가짐과 태도를 저의 경험을 바탕으로 작성해 보았는데요. 핵심적인 키워드를 뽑아 보자면 공유 그리고 성장 마인드셋이라고 생각합니다.
이러한 태도로 업무에 임하고 능력과 경험을 쌓는다면 같이 일하고 싶은 동료, 프로페셔널한 전문가로 인정받을 수 있을 거라 생각합니다.
이 컨텐츠는 F-Lab의 고유 자산으로 상업적인 목적의 복사 및 배포를 금합니다.