1년차를 벗어나고 추구하고 있는 것

2025년 6월 8일 · 약 9분

Product Engineer @ flex

1년차때는 나에게 주어진 태스크를 그저 '달성'하는데에 집중했다. 단순히 기능을 '구현'하는게 가장 주요한 관심사였고, 그외의 것들까지 모두 다 챙기기는 쉽지 않았다.

첫 회사에서 딱 6개월 정도 지나니까 기능 구현 그 자체에는 큰 문제가 없기 시작했다. 특별히 어려운 기능이 아니라면, 적절히 비즈니스적으로 필요한 시기까지 기능을 딜리버리하는데에는 무리가 없었다. 이때부터, 기능 구현 이상의 것들을 생각하기 시작했다. 나에게 주어진 기능을 개발하는 것 뿐만 아니라, 팀 동료와 함께 성장할 수 있는 기회를 만들어내는 법, 리소스를 효율적으로 쓸 수 있는 환경을 구축하는 법, 조금 더 좋은 코드, 서비스 운영을 위한 시스템 등을 고민하기 시작했다.

이런 맥락에서 내가 요즘 추구하고 있는 것 중 하나는 "내가 만든 작업물의 품질"이다. 이 품질에는 여러가지 요소가 포함될 수 있다. 작업물에 대한 설계의 수준, 정확성, 안정성 등 여러가지가 있을 수 있는데, 그 모든 것들을 예전보다 훨씬 높은 수준의 잣대로, 목표 달성에 대한 기준치를 높였다.

특히 나는 정확성과 안정성에 대해서 아주 높은 수준으로 스탠다드를 유지하려고 노력 중이다. 동료들이 나와 함께 일하면서 나의 작업물에 대한 정확성과 안정성에 대해서 높은 신뢰를 갖게 만들고 싶었다. 물론 언제나 100%라는 것은 없겠지만, 스스로도 내 결과물에는 결함이 없다고 확신하며 말할 수 있는 사람이 되고 싶었다.

누군가는 자신이 작업한 작업물에 대해서 아주 최소한의 자체 QA없이, 자신의 작업을 완료했다고 말하기도 한다. 정말 '완료'만 한 것이다. 실제로 어떤 사람들과 일할때는 따로 api 를 만들고서 한번도 api 요청을 보내보지 않고 프론트에게 결과물을 넘기는 사람들도 있었다. 함께 일하는 동료 입장에서 그들의 작업물은 신뢰할 수 없다.

또 누군가는 자신의 작업물에 버그가 있는것을 분하게 생각하기도 한다. 특정 기능을 크게 수정하는 작업에서 QA 이슈를 크든 작든 5개 이하로 맞춰보겠다는 목표를 스스로 세우면서 작업하는 사람도 있었다. 그 사람은 실제로 3개의 이슈만을 만들었고, 그조차도 큰 이슈는 아니었다. 그 동료와 일할 때는, 그의 작업물과 말에 대한 신뢰를 가질 수 있었다.

그 차이는 년차의 많고 적음이 만드는 것도 아니라고 본다. 나는 이것이 태도의 문제라고 생각한다. 얼마나 더 높은 수준의 작업 결과물을 만들 것인가에 대한, 본인의 기준에 따라서 달라지는 마인드이다.

새로운 회사인 flex에 합류한지 만으로 2개월이 되었다. 상당히 밀도 높은 시간이었다. 2개월이 아니라, 체감상 5~6개월 정도로 느껴진다.

flex에 합류하면서 나는 WCP(Web Client Platform)팀에 소속하며, 플랫폼 엔지니어링을 수행했다. 플랫폼 일을 한다는 것, 특히 웹 프론트 개발에서의 플랫폼 팀에서 일한다는 것은 업계에서 상당히 귀한 직무이다.

지금까지 플랫폼 팀에서 일하면서, '품질'에 대해서 많은 생각을 하게 된다. 플랫폼 팀은 서비스를 만드는 과정에서 생긴 기술부채를 청산하기도 하고, 기술 비전과 장기 전략을 주도하는 일을 하게된다. 이 과정에서 플랫폼 팀에 생산하는 작업 결과물은 보통 서비스 전체에 영향을 미치는 수정인 경우가 많다. 그리고 플랫폼 팀의 의사결정은 모든 서비스 개발자에게 영향을 주는 의사결정이고, 돌이키기도 어렵다.

그래서 플랫폼 팀에는 '품질' 자체에 대한 높은 기대치가 요구된다. 실제로 그 기대치를 WCP 동료들은 충족하고 있는 것으로 보인다. 아직 2개월 밖에 안되었지만, 나는 WCP 팀원들이 하는 일이라고 한다면, 그들이 정확하고 안정적으로 일을 할 것이라는 믿음이 절로 생긴다. 당연하게도 우리 팀원들도 그들과 같은 수준을 나에게 요구한다.

지난 2개월 간 내가 했던 일의 대부분은 특정 서비스 전체에 영향을 줄 수 있는 일이었다. 보통 플랫폼 일들이 대부분 그렇다. 내가 꼼꼼하게 챙기지 못한 실수 하나로 특정 서비스는 아예 프로덕션에서 장애를 맞고 아무런 기능도 수행하지 못할 수 있다. 테스트 환경에서 디테일하게 챙기지 않고 낙관적인 태도로 체크해야 할 것들을 생략하고 넘어가면, 내가 책임지기 어려운 문제를 만들 수 있다.

이 과정에서 나는 단 한 줄의 코드, 오퍼레이션도 실수하지 않겠다는 마인드로 임했다. 조금 더 귀찮지만 원칙적으로 테스트 해봐야 할 것들을 반드시 테스트하고, 내가 가하는 코드에 대한 변경사항을 PR을 올리기 전에 꼼꼼하게 체크한다. 설령 돌아가는 일이 있더라도 정확하고 안정적인 오퍼레이션을 선택한다.

사실 이렇게 해도 팀원의 코드리뷰에서 나의 실수와 부족한 점이 늘 발견된다. 이런 실수를 잡아줄 수 있는 동료가 있음에 감사하지만, 내 목표는 그들이 내 코드에서 실수를 찾지 못하게 하는 것이다. 실수가 아닌 더 좋은 방법, 좋은 설계에 대한 논의만 PR 코멘트가 달릴 수 있게 만들고 싶다.

1년차를 반복하는 2년차가 되는 것이 아니라, 1년차를 거름 삼아 열매를 맺고 수확도 하고 씨도 뿌리는 2년차가 되어보자.