![[팀스파르타 제품 조직 AX 시리즈] 1탄. 말로만 듣던 Product Engineer가 되었습니다?!](https://image.inblog.dev?url=https%3A%2F%2Fsource.inblog.dev%2Ffeatured_image%2Feed7445e-6781-4370-8c5f-984334b17e2f%2Fc3cfc689-8496-485a-b932-3207e95985db&w=3840&q=75)
Contents
요즘 팀스파르타 제품실에서 하고 있는 고민입니다.모두가 PE가 된 시점, 이런 대화가 이제는 낯설지 않습니다Product Engineer 전환의 목적은 우리 일의 타율과 ROI를 높이는 것이었어요물론 직무 경계를 허물고 의존도를 낮추는 일이 쉽진 않았습니다 (현재 진행형이고요) 그렇게 처음 시작한게 AX 워크플로(PE체제) 선발대였습니다Team First. 서로 돕는 문화 안에서 꽃피운 직무 온보딩 교육미래 조직 방향성은 해커톤을 통해 스며들었습니다이렇게 몸에 물 묻히는 시간을 가지고, 지난 7월 1일 본격적인 PE 체제를 시작했습니다이 대대적인 변화, 효과는요?위 결과가 말해주듯 아직, 임팩트로 이어지려면 개선이 많이 필요합니다다음시간에 나눌 이야기요즘 팀스파르타 제품실에서 하고 있는 고민입니다.
‘개인 기량 의존을 낮추고, 누구나 안정적 퀄리티로 제품 제작을 하려면 어떤 기술/문화 기반이 필요할까? ‘에이전트의 시니어리티를 어떻게 하면 구성원 수준으로 높일 수 있을까?’ ‘제품 제작 워크플로의 AX를 고객 임팩트로 이어지게 하려면 무엇이 필요할까?’
지난 연말 송년회에서 AX라는 거대한 파도에 올라타 이것을 기회로 쓰겠다는 이야기를 나눴었는데요.
상반기 내내 AI를 기회로 활용하기 위한 변화들을 겪어왔습니다.
작년 말 대비 가장 큰 변화는 ‘기획 - 디자인 - 개발’ 기능조직을 뒤로 하고, 제품실의 메이커들은 모두 Product Engineer로 일하고 있다는 점입니다.
출신(?)은 다르지만 각자가 속한 파트에서 문제를 직접 발굴하고 - 고객을 만나고 - 제품으로 구현하는 일련의 과정을 독립적으로 진행하고 있어요.
모두가 PE가 된 시점, 이런 대화가 이제는 낯설지 않습니다
Product Engineer 전환의 목적은 우리 일의 타율과 ROI를 높이는 것이었어요
더 잦게 타석에 서고, 더 임팩트 높은 문제를 푸는 것.
1) 더 잦게 타석에 서기 위해서는 먼저 기존 PM, 디자이너, 개발자 직무가 모여 그룹 단위로 움직이던 구조적 한계를 해소하고, 모두가 문제를 발굴하고 풀어내는 워크플로가 필요하다고 보았어요.
물론 이 과정에서 필요한 조력자는 AI이고요.
AI를 통해 직무 단위로만 쌓여있던 지식, 역량의 격차를 해소하고, 사람이 고객을 만나고 문제를 발굴하는 일에 더욱 집중할 수 있도록 구현리소스를 줄여주는 역할을 하기를 기대하고 있어요.
2) 더 임팩트 높은 문제를 풀기 위해서는 고객과 가까워져야 했습니다. 유저에 대한 깊은 이해는 우리 프로덕트가 내야하는 임팩트가 무엇인지 초점을 정확히 맞추도록 도와주었거든요.
이 과정은 DA와 CX팀과 함께 하고 있습니다.
정량적인 데이터 속에서 고객에 대한 힌트를 찾고, 고객을 직접 만나 리서치를 통해 가설에 힘을 싣습니다.
데이터 심층분석으로 파트별 인사이트를 전해주신 DA 보경님
7월 한달 간 25명의 유저리서치를 진행했던 CX팀 지영님
물론 직무 경계를 허물고 의존도를 낮추는 일이 쉽진 않았습니다 (현재 진행형이고요)
처음 접근은 각 직무의 역할을 대신할 수 있는 스킬들을 만드는 식으로 시작했는데요. 그냥 일들을 잇는다고 생산성 높은 워크플로가 만들어지긴 어렵겠다고 생각했어요.
그래서 우리는 직무별 AX가 아니라 제품 제작 워크플로라는 관점으로 다시 바라보았습니다.
즉 ‘PM이 기획서 쓰는 과정 / 개발자가 코딩하는 과정을 어떻게 모두가 할 수 있게 하지?’가 아니라, ‘제품을 AI 동료와 함께 빠르고 효과적으로 제작하려면 어떤 과정들을 밟아야할까?’를 묻는 것이었어요.
일하는 프로세스를 다시 정리했습니다. 해당 워크플로에서 사람 & AI가 기여해야하는 역할도 정의했고요.
그렇게 처음 시작한게 AX 워크플로(PE체제) 선발대였습니다
‘실제로 우리가 그린 워크플로대로 잘 동작할까?’를 확인하려면 제일 빠른 건 ‘해본다’였기 때문에 소규모 조직을 정해서 선발대를 출발했습니다.
이 과정에서 미리 준비하지 못했지만 꼭 필요한 것도 발견했어요.
- 새로운 직무로 거듭나기 위해선 온보딩 교육도 중요하다.
- 수영하기 전에 물을 묻히는 시간을 갖자!
Team First. 서로 돕는 문화 안에서 꽃피운 직무 온보딩 교육
직무가 해체되고 새롭게 구성되어도 문제를 정의하고, 제품으로 구현해서 고객에게 전달하기까지의 과정 중 일부 일들은 그대로 존재합니다.
그래서 선발대는 PM, 디자이너, 개발자 각자가 해왔던 일들을 동료들을 위해 자료화해서 온보딩 세션을 가졌어요.
💬 작은 소회를 나눠보자면: 문화의 중요성을 이런 순간들에서 깨닫는 것 같아요. 동료들의 편의와 조직의 일 문화를 위해 내가 아는 것을 기꺼이 정리하고, 공유하는 마음 씀이 모여 ‘서로 도와서 헤쳐나가야 할 때’ 빛을 발합니다.선발대 분들의 기여덕분에, 처음 PE체제를 전체 적용하는 시점에 동료들이 쉽게 이해할 수 있는 가이드도 마련하고, 동료들의 온보딩 세션으로 심리적인 안정감을 가지고 변화에 적응할 수 있었습니다.이 자리를 빌려 감사를 전해요.
미래 조직 방향성은 해커톤을 통해 스며들었습니다
본격적인 체제 변화에 앞서 PE의 하루를 체감하려면 직접 해보는 것이 제일 효과적일 것이기에 제품실 해커톤을 통해 몸에 물 묻히는 시간을 가졌습니다.
3월, 5월에 각각 하루를 통으로 비워 문제정의 - 솔루션 도출 - 구현 - 실배포까지 PE의 하루 축약버전을 겪었어요.
해커톤을 준비하면서 그동안은 PM분들의 주도로만 이루어졌던, 현 운영의 문제/개선점 파악과 고객보이스를 청취하는 일들도 경험해보았고요. AX워크플로 선발대분들만 경험했던 AI동료와의 협업 워크플로 온보딩도 받았습니다.
- 운영 매니저를 위한 어드민을 뚝딱 만들어 바로 사용을 시작할 수 있게 한 PM 유나님
- 세일즈 매니저의 일과를 관찰하며 해커톤을 준비했던 개발자 성종님
- 간단하지만 수강독려를 위한 앱으로의 연결다리를 만든 개발자 진호님
- 해커톤에서 진행했던 워크플로 온보딩 세션 - QA TC 생성 & 브라우저 테스팅 Skill을 공유해주셨던 수정님과 수영님
이렇게 몸에 물 묻히는 시간을 가지고, 지난 7월 1일 본격적인 PE 체제를 시작했습니다
소규모로 시작한 선발대를 통해 얻은 인사이트로 하반기 방향성을 잡고 - 본격적인 조직 개편과 함께 드라이브를 시작합니다.
AX워크플로를 통해 임팩트를 내기 위한 제품 조직 하반기 방향성
- PE로 거듭나기 위한 문제정의 ~ 구현 역량 강화
- 휴먼 개입을 최소화하기 위한 에이전트 시니어리티 강화
- 도처에 좋은 문제가 깔릴 수 있도록 ‘데이터 & 유저 인사이트’ 순환 문화 안착
- 제품의 퀄리티와 유저 경험의 기준을 지킬 수 있도록 피트인 문화 & QA 인프라 고도화
구성원들은 바뀐 워크플로 & 역할 변화 안에서 잘 적응하기 위해 자발적으로 인사이트를 나누고, 학습했어요.
- 기존 직무별 노하우를 나누는 스터디
- 기획 - 문제정의 마스터
- 디자인 - UXUI, 디자인을 보는 눈
- 개발 - 비개발자 엔지니어링 스터디
- 구성원들이 자발적으로 마련한 고객 인사이트 세션
- 라이프스타일 커머스 A사 - 리서쳐와 함께한 파이어사이드챗
- 시니어 타겟 커머스 B사 - 유저 인사이트 세션
- 고객을 직접 만나보고자 했던 디자이너/엔지니어들과 함께한 고객 리서치
UXUI 디자인 보는 눈
비개발자 엔지니어링 스터디
이 대대적인 변화, 효과는요?
사실 조직 체계 / 워크플로의 변화가 즉시 비즈니스 임팩트와 1:1로 치환되기는 어려운 것 같다는 생각을 자주 합니다.
그럼에도 변화의 시간들이 차곡차곡 쌓여 임팩트가 만들어진다고 생각하기에, 이번 변화에서 중요한 것을 3가지로 상정해두었어요.
- PE체제 / AX워크플로에 대한 혼란 & 불편이 점차 줄어들어 안정화 되는지
최근 진행한 워크플로 설문에서 작업 블로커 지수는 52.4로 확인되었어요. 워크플로 전 과정에서 (약간~매우 불편/지연)으로 응답한 단계가 전체의 절반가량이라고 볼 수 있습니다.
특히 (1) 코드리뷰, (2) 개발 구현 단계에서는 작업 지연이 매우 많이 발생하고 부정 VoC도 다수 나왔어요.
(3) 디자인/기획 리뷰 등 사람이 개입하는 단계에서도 기준이 모호하거나 비효율적이라는 의견도 있었고요.
- 프로젝트, PR 등 실행하는 액션 수에 있어서 살로 닿는 변화가 있는지
지난 챕터(2개월) 간, 이 체제를 적용한 2개의 파트에 대해서 1개 파트만 PR이 2배 증가, 프로젝트도 1.5배 증가했어요.
다른 1개 파트의 경우, 프로젝트와 PR 볼륨이 오히려 줄었고요.
액션 볼륨이 증가한 C 파트는 비교적 소규모 조직이고, 위 1번에서 언급한 리뷰도 간소화하여 운영하는 편이라는 점, 기존 개발자로 구성되어있다는 점에서 차이를 보였던 것으로 추정하고 있어요.
- 결과적으로 고객 임팩트로 이어지는 사례가 기존 직무 무관하게 하나 둘 나오는지
- 이력서 & 포트폴리오 생성을 더 쉽게 도와주는 ‘경험 정리 템플릿’
- 취약한 성취 항목을 반복 학습할 수 있게 도와주는 ‘복습 기능’
직무와 별개로 안타를 친 (고객 임팩트로 이어진) 액션들은 하나 둘 나오는 중이에요.
개발자 오*진님이 작업한 피쳐로, github를 읽어 프로젝트를 자연어로 정리해주는 기능이에요.
경험정리 기능 사용률 74%, 이력서 반영률 98%를 달성하며 수료생들의 긍정적 반응과 사용률을 이끌었습니다.
개발자 신*준 님이 본인의 부트캠프 경험을 떠올리며 작업한 피쳐로, 성취도 퀴즈를 풀고 난 뒤 취약 항목에 대해서 다시 학습하고 & 퀴즈를 다시 푸는 기능이에요.
복습기능 이행률 28%를 달성하며 수강생들의 긍정적 반응을 이끌었습니다.
위 결과가 말해주듯 아직, 임팩트로 이어지려면 개선이 많이 필요합니다
조직 변화 후 하나의 챕터(2개월)를 보내며 설정했던 방향성에 가까워지고 있는 것도 있지만 아직 넘어야할 큰 산들이 있습니다.
그래서 PE 체제 / AX워크플로 설문조사를 통해 도출한 핵심 문제를 중심으로 몇가지 시도를 해보려합니다.
살짝 공유해보자면, 대표적으로는 아래 3가지 액션을 빠르게 실행해볼 예정이에요.
(1) 코드 리뷰 프로세스 내 휴먼 개입 제거
- 개발자 온보딩/학습 문화였던 코드리뷰를 ‘비개발자 출신 PE’ 분들의 제품 개발 안정성을 위한 가드레일로 활용했던 기존 프로세스에서 벗어나, 자동화 코드리뷰로 크리티컬한 P0, P1 이슈들을 잡아내기로 했습니다.
- AI가 작성하는 방대한 코드를 사람이 보지 않아도, 우리의 규칙과 최소한의 품질 기준을 지킬 수 있다는 안전감을 갖는게 최우선 과제라고 보았어요.
(2) 비개발자(PM, 디자이너)의 엔지니어링 부트캠프 & 설계 지원 프로세스
- ‘PE는 누구나 스스로 설계적 의사결정을 수행할 수 있다’는 목표를 두고 좋은 설계 / 좋은 구현의 기본을 배우고 실무 의사결정에 적용해볼 수 있는 실전형 교육 과정을 준비하기로 했습니다.
- 팀스파르타 이름에 걸맞는 스파르타식 교육과, 실무 케이스 스터디를 거치며 엔지니어링 의사결정 훈련을 해보려합니다.
- 성장을 거치는 동안, 실무에서도 테크파운데이션 파트 엔지니어분들을 통해 설계적 의사결정을 돕는 지원 프로세스도 운영할 계획이에요.
(3) 기획/디자인/개발 암묵지 자산화 TF 운영
- 에이전트의 시니어리티 & 아웃풋 퀄리티를 높이기 위해서는 형식지로 정의되어있지 않은 수많은 의사결정 암묵지들이 필요하다고 보았어요.
- 방대한 암묵지를 모두 자산화하는 것은 현실적으로 어렵기에, 우선 기획 / 디자인 / 코드 리뷰와 같은 휴먼 개입 지점을 중심으로 우선순위 높은 암묵지를 발굴하고 이를 자산화하는 시도를 시작할 예정이에요.
다음시간에 나눌 이야기
앞서 언급한 것처럼 PE들의 기존 직무 의존성을 낮추고, 누구나 큰 허들 없이 안정적인 제품 제작이 가능하려면 테크파운데이션 파트의 기여가 필요한데요.
다음시간에는 AX워크플로의 발전을 위해 고민중인 테크파운데이션 이야기로 다시 찾아뵙겠습니다.
지금 겪고 있는 크고 작은 어려움들을 잘 극복한 성공담으로 찾아뵙기를 바라며 - 곧 만나요!
Share article