업데이트 된 자기소개서 보러가기 : 자기소개서

<aside> 💡 세상에 없던 무궁무진한 가치를 만드는 것을 좋아하는 엔지니어, 박성호입니다.

</aside>

저를 몇단락의 글로 100%를 보여줄 수 없지만, 저를 조금이라도 알 수 있도록 작성해보았습니다.

감사합니다.

고객과 가까이 있는 제품을 개발하는 것을 좋아해요

고객이랑 가장 가까이 있는 문제를 해결하는 것을 좋아해요. 그래서 보통 고객의 문제를 가장 먼저 접하는 프론트엔드의 관점에서 먼저 이야기하게 되는 거 같습니다. 그렇게 기획자랑 이야기하고, 다양한 문제를 제기하고, 디자이너와 최고의 유저 경험을 줄 수 있는 방법을 이야기합니다. 누비랩에서 기억에 남는 좋았던 평가는 “기획과 디자이너 관점에서 놓친 부분을 같이 이야기 해줘서 감사합니다” 입니다.

그렇지만 궁극적으로 제품이 제일 중요해요. 기획 이야기도, 디자이너와 UX 이야기를 많이 하지만 이걸 제품에 녹이는 것이 저의 가장 중요한 역할이라고 생각합니다. 때론 기획 리뷰에서 기획자가 되어 피드백을 드리기도 하고, 디자이너 입장에서 UI와 UX를 이야기 할때가 있습니다. 점차 그러한 과정에서 제품에 대한 오너십과 애착이 생기는 것 같습니다.

그래서 고객을 이해하기 위해서 다양한 시도를 했었습니다. 웹에서 유저(고객)이 어떻게 행동하는지 100% 트래킹 할 수 있어야 한다고 생각했고, 오픈소스로 공개된 우마미 등을 저에게 맞게 수정해서 배포하고 사용했습니다.(자금 상황 때문에 saas 플랫폼을 사용할 수 없는 상황이었습니다.) 때론 고객의 세션을 레코딩하여 천천히 살펴보는 날을 (배포 이후에) 만들어 팀원이 다 같이 살펴보았습니다. 그렇게 고객이 느끼는 다양한 문제점, 개선사항을 발견하고 많은 문제를 찾아 해결 할 수 있었습니다.

데이터 기반으로 이야기 하는 걸 좋아해요

때로는 대화 중에 실수로 ‘고객은 000을 더 좋아할 거야!’ 라는 의견을 이야기 할 수 있지만, 저는 실제 고객 데이터를 보면서 이야기하는 것을 지향해요. 예를 들면 A라는 디자인과 B라는 디자인을 보고 “고객은 A를 더 선호할거야” 라고 말하기보단 “A가 더 클릭률이 높은데?”와 같이 이야기하는 것을 더 좋아하고, 그렇게 논의하도록 노력합니다. 가령 "고객이 C라는 기능을 원해”라고 말하기보단, “설문조사 했을 때 원하는 사람이 많네” 그리고 “베타 테스트 해봤을 때, 유입이 많은데?”로 논의하는 것을 즐겨합니다.

누비랩에서 구성원들이 데이터를 기반으로 대화할 수 있도록 많이 노력했었습니다. 유저의 데이터 트래킹을 했고, 기획자와 같이 피쳐단위와 프러덕트 단위의 KPI를 달성하기 위해 지표를 정리했습니다. 이후 가설에 지표를 살펴보며 이야기하는 문화와 플레이그라운드를 만드려고 노력했습니다.

목표한 기간안에 기대하는 제품을 만드는 것을 중요하게 생각해요

프론트엔드 개발하면서 ‘다양한 의존성이 존재한다.’ 느꼈습니다. 가령 백엔드 API가 늦어지면 같이 프론트엔드가 배포가 미루어지고, 디자인이 변경되면 프론트엔드도 바뀌어야 했습니다. 기획 의도가 변경되면 제품을 다시 설계해야 할 때도 있었고 그럴 때마다 PM이 제품 출시 배포 일정에 무리 없도록 지속해서 문제를 공유했습니다. 능력 밖의 영역에 빠르게 만들어야 할 때도 있었는데, 그럴 때마다 적극적으로 챕터 구성원과 논의해서 간접 경험을 얻고 시간을 단축하려고 노력했습니다. 결국 가장 중요한 것은 예상된 일정에 기대를 충족하는 제품을 만드는 것이 아닐까요?

프론트 개발 코드는 선언형으로 관심사를 분리해요

프론트엔드 개발은 React와 Nextjs를 주로 상용해서 개발했습니다. Nextjs의 SSR로 넘어오면서 프론트엔드의 역할이 점점 커지는 것 같다고 느꼈습니다. 그래서 이를 최대한 활용하려고 노력했고, 혼자서 Frontend, Backend 개발을 해야 할 때 더 많이 유용했었습니다.

프론트엔드 코드는 가능하면 선언형으로 작성하는 것을 좋아해요. 그리고 그렇게 관심사를 줄여가는 것을 원해요. 가령 컴포넌트내에서 React Query 로 isLoading을 받아서 useEffect 내에서 로직을 처리할 수 있지만, <Suspense />를 사용하는 것을 선호합니다. 또한 유저 트래킹 코드를 서비스 로직과 분리하고 싶어서 Provider + hook + Component 를 사용해서 분리하기도 했었습니다. (토스의 테크 블로그로 영감을 받은 것 같아요.) 그랬을 때 개발 로직이 엉키거나 불필요한 의존성을 줄일 수 있었습니다.