개발자 취업 1년만에 Product Owner가 되었습니다

안녕하세요! 24년 10월, 웹 프론트엔드 엔지니어로 취업한 후 1년 만에 Product Owner 직무로 직군변환한 경험을 회고와 함께 공유해보려 합니다.

이 글에서는...

• 웹 프론트엔드 개발자로서 1년 동안의 경험들을 회고합니다.
• Product Owner로 전환한 계기와 함께 지금까지의 PO 업무를 회고합니다.

🎯 온보딩 과정에서의 기술 스택 딥다이브

저는 평소에 관심이 많았던 핀테크 회사에 수습생으로 입사하여 3개월을 보냈어요.

첫 주에 팀 리드님, 사수님과 함께 온보딩 목표를 '사용하는 기술 스택의 동작 원리 이해하기'로 정하고 업무를 시작했습니다. React와 React Query, Next.js의 코어에 대해 딥다이브하고 각각의 주제로 웹 팀원들을 대상으로 세 번의 세미나 발표를 진행하는 것이 최종 목표였어요.

'빠르게, 잘'하고 싶다는 마음가짐

처음으로 회사에 입사한 사회초년생은 알게모르게 '무언가를 증명해내야 한다'라는 압박과 욕심이 생기더라구요. 정규직으로 전환되지 못하더라도 온보딩 목표를 1개월만에 끝내고 2개월 동안은 실무를 다룰 수 있도록 해보자는 개인적인 목표를 가지고 공부했습니다.

기술을 사용하는 것과 이해하고 사용하는 것

처음에는 규모 있는 사이드 프로젝트를 개발하고 유지/보수하는 입장에서 제가 쓰고 있는 기술을 잘 알고 있다고 생각했어요. 그런데 막상 '동작 원리'를 알아보려고 하니 너무 새롭고 난이도 있는 내용을 학습해야 해서 숨이 턱 막혔습니다. 구글링을 해보았을 때도 기술을 사용하는 방법을 다루는 자료는 너무나도 많지만, 막상 그 기술이 내부에서 어떻게 작동하고 어떤 식으로 구현되어있는지에 대한 자료는 너무 적었어요. 세미나를 준비하면서 구글과 많은 시간을 보냈고, 끝에 어느 정도의 자료를 찾는 노하우를 터득하게 되었습니다. (1년 전까지만 해도 GPT 답변 수준이 적절한 구글링보다 성능이 좋지 못했고, 당시에 저는 AI 비관론자였답니다)

공식 문서, Source Code, Discussion

제가 원하는 정보는 거의 모두 이 세 가지 요소들에 포함되어 있었어요. 현재도 트러블 슈팅이나 내부 동작 원리, 기술적인 논의 주제를 찾아볼 때는 이 요소들을 애용하곤 합니다.

공식 문서
공식 문서는 라이브러리/프레임워크를 제공하는 개발자들이 직접 사용 방법과 동작 방식에 대해 적어둔 문서이기 때문에, 사실 공식 문서만 열심히 읽어도 단순한 궁금증은 해결됩니다.

Next.js의 공식 문서에서 처음 렌더링 방식과 관련된 문서를 접했는데, 제가 모르고 사용하고 있는 내용들이 너무 많았더라구요. 그래서 Next.js의 공식 문서를 처음부터 끝까지 다 읽어가며 세미나에 발표할 내용들을 정리했고, 당시 Next.js 공식 문서 한글 번역 프로젝트에도 기여해보았었습니다.

또 저는 개인적으로 React Query를 너무너무 좋아하는데, React Query를 딥다이브할 때는 개인적인 애정과 더불어 동작 방식도 너무 흥미로워서 혼자서 React Query v5 문서 전체를 한국어로 번역하는 프로젝트를 진행했어요. 완성된 문서를 배포한 후 처음으로 100개가 넘는 Github Star를 받았습니다. 공부를 위해서 번역한 내용들을 정리하고, 커뮤니티에 공유하여 긍정적인 반응을 얻는 경험은 정말 즐겁고 짜릿했어요.

Source Code

특정 기술의 동작 원리에 관심이 있는 경우, 리포지토리에 방문해 직접 소스 코드를 분석해보는 게 제일 정확합니다. 처음에는 오픈 소스 코드를 읽는다는 것 자체가 처음이라 코드가 잘 읽히지 않았어요. 그런데 잘 찾아보면 오픈 소스의 코드 일부들을 인용하여 라이브러리를 설명하는 수준 높은 블로그 글들이 있더라구요. 그런 글들과 함께 소스 코드를 확인하다보니 점점 글 없이도 오픈 소스 원문을 볼 수 있게 되었어요. 원문을 보며 동작 원리를 이해하는 데 확신(더블체크)을 가질 수 있고, 추후 라이브러리를 사용하다가 개선 포인트가 생각나면 직접 기여를 할 수도 있게 되었습니다.

React Query를 queryOption 기반으로 관리하는 패턴을 자주 애용했는데요, 문득 useQuery의 파라미터를 Type Safety하게 반환해주는 queryOptions라는 함수는 존재하는데 useMutation을 관리하는 mutationOptions는 왜 존재하지 않을까 싶은 의문이 들었어요. 의문을 기반으로 React Query에 feature PR을 올렸고, 리뷰 과정에서 메인테이너분께 많이 두들겨맞았지만 여러 개발자들의 많은 관심을 받고 기능이 Merge되게 되었습니다.

Next.js를 사용하면서도 next/router의 SingletonRouter를 클라이언트 사이드에서 사용하면 context와 관련된 모든 필드(router.query, router.isReady 등)들이 작동하지 않는다는 걸 발견했어요. 그래서 SingletonRouter에서는 context 관련 필드를 반환하지 않도록 하는 PR을 올렸는데, 아직까지도 Merge나 Close는 되지 않은 상태입니다 😅

Discussion

커뮤니티에서 기술적으로 논란이 되고 있는 주제를 확인하고 싶을 땐 Discussion을 확인하는 게 제일 정확합니다. Discussion은 대부분 찬/반으로 나누어지기 때문에, 현재 기술의 동작 원리와 장단점을 깔고 시작해 재미없을 수가 없는 요소에요. 저 또한 불타는 감자들이 생길 때마다 Github Discussion에서 Comment를 읽으며 동작 원리와 소스 코드를 함께 확인했습니다.

지금까지 React의 Suspense 작동 방식 변경에 대한 Discussion, Next.js의 Streaming metadata, Partial prerendering과 관련된 Discussion들을 탐방해봤어요. 공식 문서와 Source Code에 비하면 난이도는 훨씬 높지만, 그만큼 기술 이슈에 딥하게 집중할 수 있다는 점이 매력적입니다. 또한 라이브러리 개발자들이 어떤 철학을 가지고 라이브러리를 개발하는지와 같은 뒷 단의 뒷 단 관련 내용들도 알 수 있어 저는 개인적으로 정말 좋아합니다.

🦿 현업과 실무, 성급한 건 빠른 게 아니다

여담이지만 저는 글쓰기를 좋아해서 글을 쓸 때는 단 한 글자도 AI를 사용하지 않습니다. 이모티콘으로 소제목을 나누다보니 AI가 쓴 글 냄새가 나서 찔려서 적어봅니다 😗

개인적으로 세웠던 목표대로 정말 1개월만에 세 개의 세미나를 열어 온보딩을 빠르게 끝낼 수 있었습니다. 온보딩 이후에는 회사의 소스 코드에 적응한 후, 실무 작업을 할당받아 PO, Design, QA, BE 등 다른 직군의 팀원들과 직접 소통하는 경험을 접했어요.

직접 현업에서 일을 해 보니 너무 명확한 두 가지를 느낄 수 있었어요. 첫 번째는 내 업무 처리 속도가 매우 빠르다는 것이었고, 두 번째는 빠른만큼 실수가 많고 디테일이 매우 부족하다는 것이었습니다.

사이드 프로젝트를 진행할 때는 비교 대상이나 평가 대상이 없었기 때문에, 제 개발 속도가 어느정도인지를 인지하지 못하고 있었어요. 그런데 현업 개발자분들께 속도가 정말 빠르다는 평가를 듣고 처음으로 '개발 속도가 빠르구나'라고 인지하게 되었습니다.

그런데 함께 알게 된 건 잔실수가 너무 많고 빠르기보다는 성급하게 일을 처리한다는 것이었습니다. 기획서나 논의 내용에 서술된 내용임에도 빠뜨리고 개발 버전을 전달드린다거나, Happy path로 발생한 QA 티켓이 10개 넘게 생성되는 등 성급한 일처리로 인해 타팀에 리소스가 더 많이 발생하게 되는 죄송한 일이 많았어요. 리드님에게도 항상 속도보다 정확한 해결이 더욱 중요하다고 피드백 받았습니다.

이후 타팀에 결과물을 전달드리기 전에 3번 확인하자는 규칙을 세워 잔실수를 대폭 줄일 수 있었어요. IDE에서 코드를 Commit할 때 한번, Github PR을 올렸을 때 한번, Merge된 후 테스트가 가능할 때 직접 사용하여 한번 총 세 번을 확인하는 프로세스를 자체적으로 거쳤어요. 그렇게 몇십개씩 나오던 실수들이 한 자릿수로 대폭 줄게 되었고, 타팀의 업무 효율 향상이나 리소스 최적화보다는, '나 자신에게 떳떳해지는 경험'을 할 수 있었습니다.

😎 프로덕트 업무와 테크 업무, 그리고 디자인시스템

다행스럽게도 3개월 동안의 온보딩이 끝나고, 정규직으로 전환에 성공해 정식으로 웹 프론트엔드 개발자가 될 수 있었어요. 작년 10월부터 올해 10월까지, 약 1년 동안 했던 여러 업무들을 세 가지로 나누어서 설명드려볼게요.

프로덕트 업무

타 부서에서 기획을 통해서 전달받는 업무 즉, 실제로 고객이 사용할 수 있는 무언가를 새로 개발하거나 유지/보수하고, 삭제하는 등의 작업을 프로덕트 업무라고 정리했어요. 저희 회사의 소스 코드는 서비스를 도메인별로 나눈 모노레포 형식으로 구성되어 있었는데요, 나름 영역별로 분류까지 할 수 있을만큼 레포들의 난이도가 명확했어요.

처음 정규직으로 전환됐을 때는 제일 매출 영향이 낮고 이슈 영향도 또한 낮은 백오피스 업무를 위주로 진행했어요. 그러나 다시 생각해보면 우매할 수 있지만 그 때는 백오피스 업무가 직접 고객이 사용하는 화면을 다루는 것도 아니고, 반복되는 작업이 많다보니 조금 지루하다고 생각했었습니다. 그래서 마침 요청받았던 큰 규모의 백오피스 업무 하나를 완료하고 나서, 리드님께 다른 도메인을 맡아보고 싶다고 말씀드렸어요. 이후 2개월만에 백오피스를 벗어나 고객이 직접 사용하는 도메인의 레포를 도맡아 관리하게 되었습니다.

정규직으로 전환한지 반 년 정도가 지나갔을 때 즈음, 타 1금융권과 밀접히 협업하여 몇 개월에 걸쳐 개발해야 하는 대규모 프로젝트를 할당받았어요. 회사 이름이 걸린 1금융권의 PLCC 카드를 발급하는 개설 플로우를 개발하는 일이었는데, 리드님이 매니징해주시는 상태에서 같은 팀의 미들 개발자 한 분과 제가 담당자가 되었어요. 개발해야 하는 화면은 30개 내외였는데 단순한 화면 구현은 미들 개발자분과 5:5 비율로 작업을 나누어 담당했습니다. 물론 요구사항이 쉬운 화면도 있고, 어려운 화면도 있는데 어려운 화면은 대부분 도맡아주셔서 비교적 쉬운 작업 위주로 진행할 수 있었어요.

문제는 QA 및 소통이었는데요, 외부 금융사와 협력하는 프로덕트이다보니 하루에 몇십 통씩 전화로 금융사와 발을 맞추는 과정이 필요했습니다. 그런데 타이밍이 좋지 않게 출시 전 QA 단계가 미들 개발자분의 리프레시 휴가와 겹쳐 혼자 최종 QA를 대응하고 소통했어야 했어요. 1금융권 개발 부서 과장님과 하루에 20~30통씩 전화를 하며 이슈 제보를 받고 대응하는 일을 2주 정도 반복했습니다. 정신적으로 에너지 소모가 심하고 하루 종일 트러블 슈팅만을 하다보니 많이 힘들었던 시기였어요. 그런데 저는 개발을 잘한다는 건 얼마나 이슈 파악이 빠르고 트러블 슈팅을 잘하는지에 따라 결정된다고 생각하거든요. 프로젝트가 끝나고 이후 다른 업무를 할 때에도 그 경험들 덕에 실력이 향상된 기분이 들었고, 개인적으로도 "1년차인 내가 대기업 과장님과 직접 소통하고, 대규모 프로젝트에 비중 있게 기여했어!"와 같은 생각이 멤도니 매우 뿌듯했어요. 이후 직접 제가 만든 플로우를 통해서 카드 발급도 받아 지갑에 끼워넣고 다니고 있습니다 😊

테크 업무

직접적으로 화면이 변경되거나 로직이 바뀌진 않지만, 클린 코드와 성능 최적화와 관련된 업무들을 테크 업무로 정리했어요. 레거시 코드를 마이그레이션하는 것부터 시작해서 컴포넌트의 props drilling을 줄이거나 컴포넌트들간의 의존성을 역전시키고, 도메인이 붙어있는 컴포넌트에 도메인을 제거해 공통 컴포넌트로 묶어 재사용하는 등 클린 코드를 구성하는 데 힘 썼어요. 하반기에는 팀원들과 함께 FSD 아키텍처에 대해 깊게 조사하고, 맡고 있는 도메인의 레포에 직접 적용해보는 등의 마이그레이션도 진행했습니다. FSD는 파볼수록 매력적이더라구요, 처음에는 단순히 API 관련 코드, 컴포넌트 코드, 이를 묶은 화면 코드와 유틸 코드를 features, entities, widgets 등으로 이름만 바꾸어두었다고 생각했는데, 깊게 이해해보니 이를 코드 기반이 아니라 화면 기반으로 구현한다는 걸 이해할 수 있었어요. entities에도 리액트 컴포넌트가 들어갈 수 있고, features는 화면이 아니라 기능이며, 어떤 레이어가 모인 특정 레벨을 구현하는 레이어가 있다는 규칙 등 알면 알수록 직관적이고 매력적이었습니다. 프론트엔드에서 FSD 구조가 왜 하입받고 있는지 공감할 수 있는 경험이었어요.

디자인시스템 업무

회사에 들어오고나서 PO가 되기 전까지 디자인시스템 관련 업무를 계속 진행했어요. 사실 제일 어려운 업무같기도 해요. 컴포넌트를 만드는 건 쉬운 일이지만, 이 컴포넌트들을 개방성 있게 만들고 사용하기 쉽게 만드는 건 정말 어려운 일이더라구요. 엣지 케이스를 고려하지 못한 경우 컴포넌트를 사용하는 입장에서 자잘한 hack을 넣어야 한다거나 하는 등 불편함이 계속해서 발생했어요. 추후에는 shadcn이나 radix ui같은 오픈 소스들의 컴포넌트 코드를 참고했고, 이 덕에 직군변환 전 마지막으로 만든 컴포넌트는 정말 사용하기 쉽고 확장성 있게 개발하여 사용하는 모든 케이스를 커버할 수 있었어요. 또 기존 컴포넌트들을 새 컴포넌트로 마이그레이션하는 과정에서 너무 많은 리소스가 발생해서, 스크립트를 통해 한 번의 실행으로 모든 코드를 마이그레이션하는 codemod도 직접 개발했습니다. 여러모로 힘든 경험이었지만, 그만큼 실력 향상에 도움이 되는 경험이었어요.

🤗 Product Owner로의 전환 계기

상반기 웹 팀 목표 중 하나가 금융 관련 계산기를 N개 출시하는 것이었는데요, 막상 상반기가 끝났을 때 잡았던 목표에 비해 계산기를 몇 개 출시하지 못한 상태였어요. 그래서 당시 PO분과 회의할 때 아이스브레이킹 느낌으로 '이런 계산기 만드는건 어떻게 생각하시나요?'와 같이 가볍게 말을 꺼내봤어요. 그런데 그 주제가 트래픽도 나름 괜찮고, 안 할 이유가 없다며 PO분께서 기획서를 작성해서 대표님들께 전달드려보라고 해주셨습니다. 이후 짧게 기획서를 작성해서 대표님들께 전달드렸고, 다행히 좋게 봐주셔서 해당 계산기를 직접 기획하고 개발하여 운영 배포까지 나가는 재미있는 경험을 할 수 있었어요.

한 달마다 전사적으로 진행하는 세션이 있는데, 해당 세션에서 대표님께서 제 디자인닥(기획서)을 직접 언급해주셨어요. 그래서 해당 디자인닥을 필두로 PO가 아닌 팀원도 기획서를 제출하고 추진해볼 수 있는 이벤트가 진행됐는데, 그 때 개인적으로 생각하고 있던 규모 있는 서비스 디자인닥을 추가로 하나 더 제출드렸습니다.

디자인닥을 제출하고서 대표님께 따로 1on1 커피챗 요청을 받았는데, 다름이 아니라 지금 하고 있는 프론트엔드 개발자에서 Product Owner로 전향할 생각은 없는지와 관련된 직군 변환 제안이었어요. 처음 제안을 받았을 땐 조금 당황했었어요. 개발자로 5~7년 정도 미들 레벨 급의 연차를 쌓으면 PO로 직군변환해보고 싶다는 생각 정도가 있었는데, 이 기회가 취직한지 1년만에 다가올 줄은 몰랐었기 때문입니다. 그래서 처음에는 제출드렸던 디자인닥을 기반으로 진행하고 있는 개발 일과 PO 일을 병행하며 진행해봐도 되냐고 여쭤봤어요. 그런데 너무 흔쾌히 계속 도와줄테니 편한대로 마음껏 경험해보고, 천천히 원하는대로 결정하라는 답변을 받았습니다. 아직 사회초년생이기도 하고 회사에 들어온지 1년 밖에 안 된 터라 윗 분들에 대한 군기가 바짝 들어있을 때였는데, 예상보다 훨씬 따뜻하게 이야기해주시고 공감해주셔서 너무 감동받았어요.

그렇게 1개월 정도 개발 일과 PO 일을 동시에 하게 되었습니다. 옛날 같았다면 상상도 못할 일이었겠지만, 비교적 최근인 당시에는 MCP를 사용해서 웹 개발 업무 효율을 대폭 증가시켰던 시기였기에 숨 돌릴 여유는 있었어요. 그런데 진행을 하면 할 수록 복잡한 컴플라이언스 이슈를 해결하고, 여러 부서와 협업하며 스펙을 파악하는 일이 스트레스가 아니라 흥미로 느껴져 PO 업무에 더욱 정이 들게 되었습니다. 또한 MCP와 같은 개발 과정을 돕는 AI 툴이 발전하면서, 머지않아 IT 시장도 10년 내에는 테크니컬한 프로덕트 오너가, 프로덕티브한 엔지니어가 선호될 것이라는 생각도 들었어요. 그래서 이번에는 제가 먼저 대표님께 커피챗 요청을 드렸고, 정식적으로 PO 업무를 진행해보고 싶다고 말씀드리게 되었어요. 그래서 스프린트가 끝난 후 추석 이후를 기점으로 전환배치를 통해 정식적으로 Product Owner가 되었습니다.

😏 Product Owner가 되고나서의 업무

PO로 발령받은지는 글 쓰는 시점으로 3주 정도 되었는데요, 프론트엔드 개발자를 처음 시작했을 때처럼 작은 개선을 제안하는 것부터 시작해 점점 Activate나 매출에 직접적인 영향을 주는 볼륨이 큰 업무를 제안하는 것으로 차차 배워나가고 있습니다. 개발자로 일할 때보다 커뮤니케이션이 필요한 요소는 많아 물리적으로 소모되는 에너지는 많지만, 업무와 성향이 잘 맞아 정말 만족하면서 다니고 있어요. 잠을 훨씬 잘 자야겠다는 생각을 합니다 ^^.

한국에는 Product Owner라는 개념이 들어온지 얼마 되지 않아서 회사마다 PO의 개념이 조금씩 다른 것 같아요. 저는 PO는 '말하고 설득하는 사람'이라고 생각합니다. 여러 유관 부서의 팀원들이 오인 없이 이해할 수 있는 언어로 말하고, 만들거나 개선하고자 하는 프로덕트에 논리를 붙여 설득하는 것이 주 업무라고 생각해요. 여기서 모든 팀원이 이해할 수 있는 언어는 상황에 따라 이벤트 로그 같은 데이터가 될 수도 있고, 유저의 VOC나 NPS/CSAT/CES 지표가 될 수도 있으며, 서비스 외부에서의 시장 트렌드에 대한 자료가 될 수도 있다는 점이 PO의 매력인 것 같아요. 사용할 수 있는 여러가지 언어 중 어떤 요소를 채택해 설득해볼지 지표를 확인하며 고민하고, 설득 이후 개발을 시작하고나서도 팀원들간의 커뮤니케이션 리소스를 최적화시키는 게 PO이지 않을까?와 같은 생각으로 임하고 있습니다!

😃 마무리

글에서는 간단히 적었지만, PO를 할지 프론트엔드 개발자로의 커리어를 이어나갈지 고민이 되게 많았어요. 주변의 시니어분들께서는 '개발자로서의 경력이 적은 게 단점이 될 수 있다'고 피드백해주셨는데, 확실히 PO가 되고나서 기술적으로 딥한 영역을 논의해야하는 경우 벽이 느껴지긴 하더라구요.

그러나 계속 지표를 보고, 글을 쓰며, 말로 표현하고 설득하다보니 점차 업무가 손에 붙는 느낌이 들고 있어요. 앞으로도 이 느낌 그대로, 여러 지표와 방법들을 고민하며 발전하는 테크니컬한 프로덕트 오너로 발전하는 것을 목표로 하고 있습니다. 앞으로도 열심히, 하고 싶은 일을 하며 살아가는 사람이 되어보겠습니다.