가장 중요한 문제에, 가장 잘 맞는 사람을 붙인다

Share
가장 중요한 문제에, 가장 잘 맞는 사람을 붙인다

마이리얼트립의 프로덕트 엔지니어(PE)는 CTO 직속 PS팀(Product Strategy)에 모여 있습니다. 전사에서 가장 중요한 문제에 가장 잘 맞는 PE를 배치하고 한 명의 PE가 문제 정의부터 구현과 배포까지 끝까지 책임지는 조직입니다.

이렇게 한 데는 이유가 있습니다. 회사에서 가장 중요한 문제는 계속 바뀌는데, 사람이 특정 버티컬에 묶여 있으면 그 경계 안에서만 움직이기 쉽습니다. 그래서 사람은 한 팀에 두되, 일은 문제 단위로 배치합니다. 지금 가장 비즈니스 임팩트가 큰 문제에 가장 잘 맞는 PE를 곧바로 붙이기 위해서죠. 대신 각 버티컬에는 도메인을 깊이 아는 PE를 두어, 맥락과 우선순위가 끊기지 않게 합니다.

이 팀에서 PE는 어떤 문제를 어떻게 풀지 스스로 판단해 끝까지 끌고 갑니다. 한 사람이 문제 정의부터 배포까지 책임지니, 중간에 손이 바뀌며 맥락이 새는 일도 줄어듭니다.

그런데 이런 구조는 더 근본적인 질문을 부릅니다. AI가 구현의 상당 부분을 대신하는 지금, 제품을 만드는 사람은 대체 무엇을 하는 사람인가. 구현 자체는 눈에 띄게 쉬워졌지만 무엇을 만들지 고르고 그 가치를 증명하는 일은 여전히, 어쩌면 더 어려워졌습니다. 허원진 CTO가 이 물음에 가장 힘주어 짚은 문장이 이것입니다. 만드는 건 쉬워졌지만, 그중 정말 가치 있는 것을 선택하고 증명하는 일은 여전히 어렵다.

이 답은 특정 직군만의 이야기가 아닙니다. 엔지니어든 디자이너든 기획을 맡은 사람이든, 제품에 기여하려는 모두의 일하는 방식에 대한 관점입니다. AI 네이티브 조직으로 일해 온 마이리얼트립이 정리해 온 생각이기도 합니다.

직무가 아니라 역할로 일한다

가장 먼저 바뀐 것은 일을 나누는 단위입니다. 예전에는 기획, 디자인, 백엔드, 클라이언트, QA처럼 직무로 R&R을 나눠 각자의 영역을 지켰습니다. 이제는 이 경계가 흐려집니다. 지금 맡은 프로젝트에서 어떤 역할을 얼마나 강하게 가져갈지, 스스로 판단해 조합하는 쪽으로 일이 바뀝니다.

원진님이 제시한 조합의 재료는 앤트로픽의 Boris Cherny가 공유한 다섯 가지 역할입니다. 프로토타이퍼, 빌더, 스위퍼, 그로워, 메인테이너.

데이터가 전혀 없는 곳에서 가능성부터 확인해야 할 때는 프로토타이퍼가 되어 최대한 빨리 만들어 봅니다. 가치가 보이면 빌더로 넘어가 제대로 된 제품으로 만듭니다. 이후 스위퍼가 되어 쌓인 복잡도와 중복을 걷어내고, 그로워로서 지표를 끌어올리며, 메인테이너로서 안정성과 비용, 운영을 챙깁니다. 가능성 확인에서 제품화로, 정리에서 성장으로, 다시 운영으로 이어지는 흐름입니다.

핵심은 한 사람이 이 다섯을 모두 완벽히 해내야 한다는 뜻이 아닙니다. 내 강점이 어디에 있는지, 지금 프로젝트가 어느 위치에 있고 목표가 무엇인지에 따라 어떤 역할을 강하게 가져갈지 스스로 정합니다. 한 곳에 매몰되지 않고 유연하게 프로젝트의 오너가 되는 사람, 마이리얼트립이 지향하는 일하는 방식은 여기에 가깝습니다.

역할을 조합해 유연하게 프로젝트의 오너가 된다는 이 원칙을, 글머리에서 말한 PS팀이 조직의 형태로 구현하고 있습니다. 가장 중요한 문제에 가장 잘 맞는 PE를 붙이는 구조가, 결국 한 사람이 여러 역할을 오가며 문제를 끝까지 책임지도록 돕기 위한 것입니다.

이 방식이 실제 제품에서 어떻게 작동하는지는 앞서 마이리얼트립 블로그에 소개한 스토리에서 볼 수 있습니다.

한 팀에 모이면 달라지는 것

사람을 한 팀에 모으면, 흩어져 있을 때는 잘 보이지 않던 것들이 드러납니다.

먼저 맞닿는 지점이 보입니다. 여러 버티컬이 비슷한 문제의식을 마주하는 순간이 있는데, 한 팀에서 전체 맥락을 보면 이를 일찍 알아채 하나로 엮을 수 있습니다. 누가 맡을지 정하고, 나머지는 더 중요한 문제에 집중합니다.

문제를 풀어본 경험도 자연스럽게 흐릅니다. 한쪽이 이미 해결한 문제를 다른 쪽이 다시 만나면 그 경험이 그대로 넘어가고, 디자인 시스템이나 검색처럼 여러 버티컬에 걸친 공통 영역도 특정 팀의 몫이 아니라 전체 관점에서 다뤄집니다.

물론 아직 다듬는 중입니다. 프로젝트마다 목표 지표를 분명히 정의하는 습관, 한 사람이 문제의 오너로 온전히 자리 잡기까지의 시간 같은 건 여전히 풀어가는 과제입니다.

학습도 방향이 바뀌었다: Bottom-up에서 Top-down으로

PS팀에서 역할을 넘나들려면 새로운 것을 계속 배워야 합니다. 그래서 배우는 방식부터 달라졌습니다.

예전에는 무언가를 익히려면 강의를 사서 기초부터 개념, 실습, 프로젝트 순으로 차곡차곡 쌓아 올렸습니다. Bottom-up 방식입니다. 지금은 언제든 질문할 수 있는 도구가 곁에 있습니다. 그래서 순서를 뒤집는 편이 낫습니다. 구체적인 문제를 먼저 고르고, 일단 만들어 보다가, 막히는 지점에서 필요한 개념을 그때그때 습득하고, 다시 적용해 데이터로 검증합니다. Top-down 방식입니다.

한 가지 짚어둘 게 있습니다. AI를 잘 못 쓰는 것 같거나 지식이 부족하다고 느껴질수록, 관련된 프로젝트에 직접 도전해 부딪히며 배우는 편이 빠릅니다. 다만 "AI가 다 해줬으니까"로 끝내면 남는 것이 없습니다. 결과물을 스스로 이해하고 다음 프로젝트에서도 다시 꺼내 쓸 수 있게 체화해야 진짜 학습입니다.

이 학습은 일하는 방식에도 그대로 드러납니다. PS팀 PE들은 구현을 AI에 통째로 맡기기 전에 정책과 계획, 구현 스펙을 먼저 세우고 가볍게라도 리뷰를 받고 들어갑니다. 다 만든 뒤에 문제를 발견해 되돌리는 것보다 빠르기 때문입니다. 받은 리뷰는 AI에도 계속 학습시켜, 다음 작업에서는 리뷰에 드는 시간이 짧아집니다. 큰 변경은 한 번에 바꾸지 않고 일부에서 방법이 맞는지 확인한 뒤 넓힙니다. 이렇게 남긴 결과물이 다음 프로젝트에서 다시 쓰는 자산이 됩니다.

비즈니스 임팩트를 중심에 둔다

무엇을 만들지 고르는 기준은 결국 비즈니스 임팩트입니다. 기능을 몇 개 더했는지보다, 내 프로젝트가 회사가 실제로 만들어내는 성과에 얼마나 기여하는지를 먼저 봅니다.

이 관점은 오래된 이분법을 흔듭니다. 예전에는 사용자에게 보이는 '피처 과제'와 보이지 않는 '개발 과제'를 나눠서 생각했습니다. 비즈니스 임팩트를 중심에 두면 이 둘이 정말 나뉘는지 다시 묻게 됩니다. 가령 매출이 크게 잡히는 기능이라도 송출이나 인프라, 성능을 받치는 비용이 함께 불어나면, 정작 회사에 실질적으로 남는 성과는 줄어들 수 있습니다. 로딩 속도, 동시접속 안정성, 장애가 났을 때 되돌릴 수 있는지, 결제가 마지막까지 문제없이 되는지 확인하는 일도 마찬가지입니다. 겉으로 드러나지 않는 작업도 저마다 성과에 기여합니다.

우선순위를 정하는 방식도 달라집니다. 실제 가치를 움직이는 일을 먼저 고릅니다. 프로젝트가 주어지면 일단 시작하기보다, 이 일이 어떤 지점을 움직이고 임팩트가 어디서 나는지부터 파악하고 주도하는 쪽입니다.

그래서 목표를 세울 때부터 비즈니스 임팩트를 함께 봅니다. 이 프로젝트가 어떤 지점을 움직여 어떤 가치를 만들어내는지, 얼마의 기간에 어느 정도의 변화를 낼 것인지를 처음부터 계산해 두는 태도입니다. 자신이 맡은 영역 안에만 머무르려는 습관도 다시 봐야 합니다. 한 곳에서 만든 것을 "다른 화면에도 적용하면 좋겠다"에서 멈추지 않고, 이미 해본 사람이 맥락을 얹어 다른 영역까지 넓혀 가는 방식이 더 큰 가치를 만듭니다.

트레이드오프를 당연하게 받아들이지 않는다

마지막은 태도 이야기입니다. 제품을 만들 때 우리는 흔히 Good, Fast, Cheap 세 가지를 놓고 둘을 고른 뒤 하나를 포기합니다. 기한이 정해져 있으면 셋 중 하나를 내려놓는 게 당연해 보입니다. "Pick Two"라 불리는 오래된 상식입니다.

원진님은 이 익숙한 선택에 물음표를 붙입니다. 우선순위를 따지기 전에, 하고 싶은 것을 다 하면 안 되느냐는 것입니다. AI와 에이전트 덕분에 트레이드오프가 반드시 존재하지는 않는 상황이 온다면, 둘을 고르는 대신 셋 다 가져갈 수도 있습니다. 도구가 기준을 높여 주는 만큼, 우리가 잡는 목표도 그만큼 더 높이자는 이야기입니다.

그래서, 무엇을 만들 것인가

다시 처음의 문장으로 돌아옵니다. 만드는 건 쉬워졌지만, 그중 정말 가치 있는 것을 선택하고 증명하는 일은 여전히 어렵습니다.

이 이야기들은 하나의 질문으로 모입니다. 우리가 만드는 모든 것을 어떻게 정말 가치 있게 만들 것인가. 마이리얼트립이 내놓는 답은 정해진 정답이라기보다, 이 질문을 계속 품고 회사가 오래 지켜온 기준 위에서 함께 풀어가자는 제안에 가깝습니다. 도구가 아무리 좋아져도, 무엇을 만들지 고르는 일만은 끝까지 사람의 몫으로 남기 때문입니다.

Read more

돌려쓰던 테스트 환경을, 각자의 환경으로: 배포 병목을 없앤 이야기

돌려쓰던 테스트 환경을, 각자의 환경으로: 배포 병목을 없앤 이야기

PEPE 세션 — 회원주문개발팀 정현수 님 과거 마이리얼트립의 공용 테스트 환경은 쓰려는 사람에 비해 모자랐습니다. 누가 쓰는지 알기 어려워 "지금 써도 되냐"고 서로 물어 가며 차례를 기다리는 경우가 많았고, 내가 작업 중인 사이 다른 사람이 배포하지 않도록 조율해야 했습니다. 이 병목을 환경 개수를 늘리는 방식에서 각자 자기 환경을

By 마이리얼트립
예약에서 끝나지 않는 여행: 한 명이 10여 개 레포를 가로질러 만든 항공 여정 케어

예약에서 끝나지 않는 여행: 한 명이 10여 개 레포를 가로질러 만든 항공 여정 케어

마이리얼트립이 예약한 항공편의 운항 상태를 고객이 앱을 열지 않아도 실시간으로 받아보는 서비스를 선보였습니다. 출발 3시간 전 알림부터 게이트 변경과 지연, 결항, 회항, 출발, 도착, 수하물 상태까지, 비행의 흐름 전체를 고객이 찾기 전에 먼저 안내합니다. 여행은 항공권을 예약하는 순간 끝나지 않습니다. 짐을 싸고 공항으로 향하고 비행기에 올라 목적지에 내려 짐을 찾을

By 마이리얼트립
취소를 끝이 아니라 시작점으로: 취소 화면에서 다음 여행을 제안한 이야기

취소를 끝이 아니라 시작점으로: 취소 화면에서 다음 여행을 제안한 이야기

PEPE 세션 — 회원주문개발팀 배재경 님 마이리얼트립에서 여행 예약이 취소되는 순간을, 이탈이 아니라 다음 여행이 시작되는 지점으로 바꾼 작업이 있습니다. 회원주문개발팀이 취소 후 추천 경험을 다시 설계한 프로젝트로, 취소 화면의 추천 하나로 시작한 일이 "어떤 사용자에게, 어떤 순간에, 어떤 콘텐츠를 보여줄 것인가"를 다루는 구조로까지 자랐습니다. 그 과정을 배재경

By 마이리얼트립
출처가 분명한 여행, '마이 오리진'의 탄생 이야기

출처가 분명한 여행, '마이 오리진'의 탄생 이야기

마이리얼트립이 직접 기획한 여행 브랜드 '마이 오리진(MyOrigin)'을 선보였습니다. 마이리얼트립이 직접 여행을 설계하고 검증해 내놓은 셀렉션입니다. 마이 오리진에는 이미 일본 나오시마 예술 섬 워킹 투어, 파리의 플라워 클래스와 미식 투어, 시드니 하이킹, 프라하 맥주 공장 투어까지 여러 결의 여행이 자리 잡고 있습니다. 마이리얼트립은 이런 라인업을 직접 기획하고

By 마이리얼트립