백엔드 개발자 지망생이 PO를 겸하며 이해한 것
부트캠프에서 나는 백엔드 개발을 하면서 PO 역할도 함께 맡았다. 처음에는 이 경험을 어떻게 설명해야 할지 애매했다. “PO를 했다”고만 말하면 회의 정리, 일정 관리, 발표 준비를 했다는 뜻처럼 들릴 수 있기 때문이다.
그런데 현업 PO/PM/TPO 직무기술서를 찾아보면서 생각이 바뀌었다.
Scrum Guide에서 Product Owner는 제품의 목표와 백로그, 우선순위, 투명성을 책임진다. GitLab의 Product Manager JD는 PM을 한정된 엔지니어링과 디자인 리소스를 어디에 투자할지 결정하고, 그 결과를 책임지는 사람으로 설명한다. Atlassian은 PM이 사용자, 비즈니스, 기술 사이에서 전략과 로드맵을 조율하는 역할이라고 말한다. 국내 JD에서도 비슷한 키워드가 반복됐다. 문제 정의, 데이터 기반 의사결정, 제품 정책, 다양한 직군과의 협업, 안정적인 운영.
특히 기술 조직의 PO 역할을 보면 더 선명했다. 토스증권의 원장 Platform PO JD에서는 정합성, 멱등성, 재처리, 이력 추적처럼 겉으로 잘 보이지 않지만 서비스 신뢰를 좌우하는 기준을 개발자와 함께 설계하는 일을 강조했다.
이 자료들을 보고 나서야 내가 했던 PO 경험을 다시 해석할 수 있었다.
내가 한 일은 기획자로 전향하는 경험이 아니었다. 애매한 요구사항을 팀이 구현할 수 있는 기준으로 바꾸는 경험이었다. 백엔드 개발자 관점에서 말하면, 문장으로 된 요구사항이 API 계약, DB 제약조건, 상태값, 에러 케이스, SLO, 리스크 목록으로 내려오는 과정을 앞단에서 경험한 것이다.
이 글에서 말하는 모듈 3-6은 네 개의 서로 다른 과제라기보다, 같은 팀이 제품을 점점 다른 관점으로 다뤄본 과정에 가깝다.
- 모듈 3: FLOWN LMS - 수능 대비 온라인 강의 서비스의 기본 기능 구현
- 모듈 4: FLOWN LMS 운영화 - 배포, Redis, SLO, 모니터링, 부하테스트
- 모듈 5: FLOWN LMS 고도화 - AI 학습 스케줄러, 최적화, 정책/확장성 고민
- 모듈 6: 잇다 그룹웨어 - 회의, 액션, 인수인계가 이어지는 조직 협업 서비스
PO를 처음 오해한 방식
처음에는 PO를 기능을 정하고 우선순위를 세우는 사람 정도로 생각했다. 틀린 말은 아니지만, 실제 프로젝트에서는 그보다 훨씬 앞단의 일이 많았다.
기능을 정하기 전에 먼저 정해야 하는 것이 있었다.
누구의 문제인가. 왜 지금 이 문제를 풀어야 하는가. 어떤 상태가 되면 문제가 해결됐다고 볼 수 있는가. 이 기능은 이번 범위에 들어오는가. 개발자가 구현할 수 있을 만큼 요구사항이 구체적인가. 프론트와 백엔드는 같은 응답값과 상태값을 보고 있는가. 지금 만들지 않는 기능은 왜 나중으로 미루는가.
이 질문에 답하지 않으면 회의는 많이 해도 개발은 계속 흔들린다.
그래서 내가 이해한 PO는 기능 목록을 많이 만드는 사람이 아니었다. 팀이 같은 기준으로 판단할 수 있게 문제, 우선순위, 계약, 검증 기준을 정리하는 사람이었다.
모듈 3, FLOWN LMS: 요구사항은 문서가 아니라 계약에서 깨졌다
모듈 3에서는 수능 대비 LMS를 만들었다. 나는 강의(course)와 수강(enrollment_management) 도메인을 맡았다. 이 시기에는 공식적으로 PO 역할이 뚜렷했다기보다, 개발을 하면서 협업 기준이 없을 때 어떤 문제가 생기는지 먼저 겪은 단계에 가까웠다.
가장 많이 흔들린 것은 거창한 기능이 아니었다. 작은 계약이었다.
프론트는 첫 페이지를 page=1로 보고, 백엔드는 Spring PageRequest 기준으로 page=0을 첫 페이지로 처리했다. 사용자는 첫 페이지를 눌렀지만 서버는 두 번째 페이지를 돌려줄 수 있었다. course 테이블의 PK는 course_id인데 네이티브 쿼리에서 id로 조회하는 문제도 있었다. Swagger, Notion, Postman, 실제 구현이 서로 조금씩 달라지는 문제도 반복됐다.
이때 깨달은 것은 단순히 “문서를 잘 쓰자”가 아니었다.
문서는 많아도 기준이 하나로 합의되지 않으면 의미가 없다. 요구사항은 최종적으로 API 요청값, 응답값, enum, 페이징 규칙, 오류 코드, DB 제약조건으로 내려와야 한다. 그래야 프론트와 백엔드가 같은 기능을 같은 의미로 구현할 수 있다.
모듈 3은 PO 경험이라기보다 PO가 왜 필요한지 알게 된 시작점이었다. 팀이 같은 계약을 보고 있지 않으면, 각자 열심히 개발해도 마지막에 연결되지 않는다.
모듈 4, FLOWN 운영화: 우선순위는 기능 개수가 아니라 리소스 투자 판단이었다
모듈 4부터는 PO 역할이 더 명확해졌다. 팀은 기존 LMS를 기능 구현 수준에서 운영 가능한 서비스로 끌어올려야 했다. 배포, S3, Redis, 모니터링, 부하테스트, SLO 같은 주제가 들어왔다.
GitLab의 PM JD에서 말하듯, PM의 본질 중 하나는 한정된 엔지니어링 리소스를 어디에 투자할지 결정하는 것이다. 당시 우리에게 주어진 시간과 리소스는 넉넉하지 않았다. 결제도 더 다듬고 싶고, 인증도 보강하고 싶고, 랭킹과 커뮤니티도 개선하고 싶었지만, 모든 기능을 넓게 잡으면 결과가 흐려진다.
그래서 모듈 4에서는 “기능을 더 많이 만들자”보다 “실패 비용이 큰 지점을 먼저 증명하자”로 기준을 바꿨다. 중복 결제가 발생하거나, 정지된 계정이 기존 JWT로 계속 접근하는 등 서비스 신뢰를 무너뜨리는 치명적인 예외를 먼저 막아야 했다.
결과적으로 단순 CRUD를 하나 더 붙이는 것보다, 결제 멱등성, 토큰 차단, 캐싱, 부하테스트, SLO 대시보드가 더 중요한 일이 되었다. “무엇을 만들었는가”보다 “어떤 사용자 기대가 깨지지 않게 했는가”가 더 중요해진 것이다. 이 과정을 통해 개발 리소스의 방향을 정하는 일이 곧 PO의 역할임을 체감했다.
모듈 5, FLOWN 고도화: 기능 추가보다 정책과 확장성이 보이기 시작했다
모듈 5는 새 제품을 처음부터 정의하는 단계라기보다, 앞선 모듈에서 만든 LMS를 팀 기준 위에서 고도화하는 단계에 가까웠다. 회원, 강의, 결제, 학습 흐름이 어느 정도 만들어진 뒤였기 때문에 질문도 달라졌다.
그전까지는 고도화를 기능을 더 붙이거나 성능을 높이는 일로만 생각하기 쉬웠다. 그런데 실제로는 이미 만든 기능이 더 많은 조건을 견디게 하고, 나중에 정책이 바뀌어도 갈아엎지 않게 만드는 것이 진짜 고도화였다.
이때 와서 보니 앞단에서 정했어야 할 기준들이 뒤늦게 보이기 시작했다. 어떤 값은 사용자 경험에 바로 반영해도 되는지, 어떤 값은 로그만 쌓아야 하는지, 어떤 정책은 하드코딩하면 안 되는지, 나중에 변경될 가능성이 큰 부분은 어디인지 같은 질문이었다.
AI 학습 스케줄러의 stretch_factor가 대표적이었다. 처음에는 알고리즘 안의 값처럼 보였지만, 실제로는 사용자의 학습 일정에 영향을 주는 제품 정책이었다. 실사용자 데이터가 없는 상태에서 특정 값을 확정하면 나중에 바꾸기 어렵고 설명하기도 어렵다. 그래서 사용자 경험에 바로 반영하기보다 shadow mode로 계산과 로그를 남기고, 실제 데이터가 쌓인 뒤 판단할 수 있는 구조를 택했다.
모듈 5에서야 고도화의 범주가 기능 추가뿐 아니라 정책과 확장 가능한 구조까지 포함한다는 걸 이해했다. PO는 당장의 기능뿐만 아니라, 제품이 커지는 순간 튀어나올 정책값, 로그, 예외, 확장성의 문제를 처음부터 고려해야 했다.
모듈 6, 잇다 그룹웨어: 넓은 자율성에서는 목적 기준이 먼저였다
모듈 6에서 가장 크게 느낀 PO 역할은 프로젝트 설명을 잘하는 일이 아니었다. 방대한 자율성 속에서 팀이 서로 다른 제품을 상상하지 않도록 목적 기준을 먼저 세우는 일이었다.
주제는 그룹웨어였고, 회의록, 문서관리, 채팅, 일정, 결재, 조직도, 권한, 검색, 알림, 스토리지까지 모든 것을 담을 수 있는 거대한 도메인이었다. 정답 서비스가 없는 상태에서 3주라는 제한된 시간 안에 결과를 만들어야 했다. 이 과정에서 우리는 거대한 기능들을 과감히 쳐내고, 핵심 협업 흐름인 회의-액션-업무 맥락 연결에 집중했다.
일반적인 제품 개발 절차를 3주 안에 다 밟을 수 없었기에, 각 단계의 목적만 남겨 압축적으로 실행했다.
| 원래 필요한 단계 | 3주 안에서 남긴 핵심 목적 |
|---|---|
| 문제 정의 | 그룹웨어 중 어떤 문제를 풀지 좁히기 |
| 타깃 정의 | 누구에게 가장 먼저 필요한지 정하기 |
| 요구사항 정리 | 핵심 흐름에 들어오는 기능과 아닌 기능 나누기 |
| 유스케이스 | 사용자가 처음부터 끝까지 지나갈 대표 시나리오 만들기 |
| ERD/API 설계 | FE/BE가 동시에 움직일 수 있는 최소 계약 잡기 |
| 개발 계획 | 주차별 게이트와 코드 프리즈 시점 정하기 |
| QA/리스크 관리 | 지금 해결할 것과 이후 갭으로 남길 것 구분하기 |
각 산출물의 목적을 먼저 합의하니, 짧은 기간에도 팀원들이 서로 다른 방향으로 달리는 일이 줄었다. 문서를 전부 길게 만들지는 못했어도 무엇을 기준으로 개발해야 하는지는 빠르게 공유됐다. 특히 FE/BE가 동시에 움직이기 위해 필요한 최소 계약을 먼저 잡으면서, 이전 모듈보다 연동 과정에서 생기는 수정 공수도 줄일 수 있었다.
모듈 6에서 PO의 역할은 특정 기능 하나를 설명하는 데 있지 않았다. 자율성이 큰 상황에서 우선순위를 세우고, 개발 절차를 목적 기준으로 압축하고, 팀이 같은 기준으로 3주를 쓰게 만드는 데 있었다.
내가 이해한 PO
4개월 동안 개발과 PO 역할을 같이 하면서, 내가 겪은 상황은 단순했다. 팀은 늘 열심히 개발하고 있었지만, 기준이 늦게 정해지면 같은 기능도 서로 다르게 이해했다. API 하나, 상태값 하나, 우선순위 하나가 흔들리면 개발 속도보다 조율 비용이 더 커졌다.
그 상황에서 내가 맡아야 했던 일은 정답을 대신 내는 것이 아니었다. 문제를 좁히고, 왜 이걸 먼저 해야 하는지 설명하고, 팀원이 구현할 수 있는 기준으로 바꾸는 일이었다.
그래서 모듈이 뒤로 갈수록 행동도 바뀌었다. 모듈 3에서는 API와 DB 계약의 중요성을 배웠고, 모듈 4에서는 기능 개수보다 실패 기준을 먼저 봤다. 모듈 5에서는 기능이 완성된 뒤에도 정책과 확장성이 남는다는 걸 알았고, 모듈 6에서는 개발 단계의 목적만 남겨 3주 안에 팀이 같은 방향으로 움직이게 하는 경험을 했다.
결과적으로 PO는 “무엇을 만들지 정하는 사람”보다 “팀이 덜 흔들리게 판단 기준을 세우는 사람”에 가깝다고 느꼈다.
이제 요구사항을 보면 바로 코드부터 떠올리기보다 먼저 묻게 된다. 이건 누구의 문제인가. 어떤 상태가 되면 해결된 것인가. 어떤 계약이 필요하고, 어떤 실패를 막아야 하는가. 내게 PO 경험은 그 질문을 앞단에서 해본 시간이었다.