이력서
작성해왔던 이력서를 다시 보니, “하고 싶은 말은 참 많은데, 정리는 잘 안 되어 있었구나…” 라는 생각이 들었습니다.
개발자가 코드를 리팩토링하듯, 이력서도 관심사와 경험에 맞게 리팩토링할 필요가 있겠다는 깨달음을 얻었습니다.
작가와 개발자
무라카미 하루키의 『직업으로서의 소설가』를 읽기 시작했습니다. 아직 초반이지만, 책을 읽으며 자연스럽게 “작가와 개발자는 참 닮았다”는 생각이 들었습니다.
“작가가 되기 위해선 책을 많이 읽어야 한다.” -> “개발자가 되기 위해선 코드를 많이 읽어야 한다.”
작가는 생각을 글로 표현하고, 개발자는 생각을 코드로 표현합니다.
그래서 저는 자연스럽게 다른 사람의 코드를 보며,
“어떤 고민을 거쳐 이 코드를 썼을까?” 를 더 자주 생각하게 되었습니다.
코드에는 모두 의도와 맥락이 있고, 그걸 하나씩 파악해가며 코드를 작성하는 과정이 요즘은 더 재미있게 느껴집니다.
스펙터
제가 스펙터에 합류한 이유는, 이력서만으로는 자신을 충분히 보여주기 어려운 지원자에게 평판이라는 무기를 쥐어줄 수 있는 서비스라고 느꼈기 때문입니다.
입사 후, 직접 동료들에게 평판을 받아보며 내가 어떤 방식으로 일해왔고, 동료들이 나를 어떻게 바라보는지 돌아볼 수 있었고, 그 내용을 바탕으로 다음 회사를 지원할 수 있는 경험이 좋았습니다.
스펙터는 레퍼런스 체크라는 다소 무거운 주제를 지원자의 강점을 더 잘 드러낼 수 있는 도구로 만들어가고 있습니다.
최근에는 리나라는 이름의 앱도 만들고 있습니다.
리나는 사내의 피드백 문화를 자연스럽게 만드는 서비스로, 동료에게 전하고 싶은 마음과 피드백을 손쉽게 전달할 수 있도록 돕습니다.
아직 부족한 점도 많지만, 진심을 담은 피드백을 주고받는 경험을 통해
- “피드백 문화란 그렇게 부담스러운 게 아니구나.”
- “뭐든 처음이 어렵고, 안 해봐서 두려운 거구나.”
라는 생각을 하게 되었습니다. 지금도 글을 적으면서 동료에게 마음을 하나 보내고 있습니다.
회사와 개발자
회사가 필요로 하는 개발자의 공통된 역량은 무엇일까? 저는 그 중에서도 생산성이 핵심이라고 생각합니다.
업무 중 고민이 들 때는 아래와 같은 질문을 스스로 던져보곤 합니다.
- 이 기술 도입이 회사의 생산성을 높일 수 있을까?
- 이번 리팩토링은 생산성 향상에 기여했을까?
- 이 미팅은 어떤 방식으로 생산성에 영향을 주었을까?
물론, 항상 생산성만을 고려하는 것은 바람직하지 않습니다.
하지만 업무의 방향성을 점검하는 좋은 질문들이 될 수 있습니다.
혹시 일하면서 기술적으로 답답함이나 정체감을 느낀다면, 위 질문에 대한 자신의 답을 정리해보는 것도 좋은 돌파구가 될 수 있습니다.
PM과 개발자
첫 회사에서는 PM이라는 직군 없이 일했고, 스펙터에서는 PM과 밀접하게 협업하고 있습니다.
PM은 개발자와 가장 밀접한 직군 중 하나이며, 서로 영향을 주고받는 협력 관계라고 생각합니다.
입사 초기에는 킥오프 → 기획 → 디자인 → 개발 → QA 라는 정형화된 프로세스를 그대로 따랐고, 기획 과정에서 null case나 상태 관리처럼 기술적 고려가 부족해 기획을 수정하는 일이 잦았습니다.
이 문제를 개선하고자, 기획 초기 단계부터 제품팀 전체가 모여 초기 리뷰를 진행하기 시작했습니다.
각 직군의 입장에서 리스크를 검토하고 의견을 공유하면서 기획 변경 없이 더 안정적인 프로젝트 진행이 가능해졌습니다.
개발자의 역할은 단순히 코드를 작성하는 것에 그치지 않습니다. 제품을 함께 만들어가는 주체이며, 그 과정에서 코드를 다루는 역할의 비중이 큰 것일 뿐입니다.
다양한 직군과 협업하고, 더 나은 제품을 만들기 위한 과정에 주도적으로 참여하는 것이 개발자로서의 중요한 역할이라고 믿습니다.