온아웃

들어가며: 팀원으로서의 일

회사에서는 누구나 자기의 일이 있다. 개발자는 개발을 해야 하고 디자이너는 디자인을 해야 하고, 기획자는 기획을 해야 한다. 하지만 모든 사람은 각자의 일 말고도 “팀원으로서의 일”이 따로 있다.그것은 바로 좋은 프로덕트를 만드는 일이다. 좋은 코드를 짜는 것, 멋진 디자인을 하는 것, 좋은 기획을 하는 것 등 모든 것은 수단일 뿐이다. 결국 모두의 최종적인 목표는 좋은 프로덕트를 만드는 것이다. 따라서 당장 눈 앞에 놓인 코드를 짜는 것보다 더 중요한 것은 방향성에 미치는 일에 영향을 주는 것이다. (그러기 위해서는 좋은 프로덕트에 대해 먼저 정의해야겠지만, 여기서는 매출로 귀결되는 제품이라고 정의하고 넘어가자)

하지만 ‘팀원으로서의 일’을 하는 것은 생각보다 쉽지 않다. 그 이유는 단순히 한 개인의 문제보다는 구조적인 문제에 있다. 항상 각 직무 별로 항상 골치아픈 “문제”들이 있고 그 데드라인도 타이트하다. 매번 눈앞에 일에 허덕이다보면, 가장 중요한 ‘팀원으로서의 일’, 즉 좋은 프로덕트를 만드는 일은 뒷전이 되기 쉽다. 그럼에도 불구하고 세상에 수많은 프로덕트 사이에서 남다른 프로덕트를 내놓으려면 단순히 각자들의 ‘숙제’들만 하는 것을 넘어 ‘팀원으로서의 일’을 잘해야 한다.

내가 온아웃에서 일하면서도 여러 개발적인 문제가 있었다. 하지만 나에게 개발자로서 명시적으로 주어진 일들보다는 팀원으로서 묵시적으로 주어진 일이 있었다. 비지니스적으로 더 나아가게 하는 것. 그 일들은 사실 인정받기 어렵다. 개발자의 일은 같이 일하는 개발자들이 알 것이오, 디자인적인 일은 디자이너가 알 것이지만, 대게 비지니스적으로 중요한 일들은 수면 아래 있기 마련이다.

그래서 이번 회고에서는 ’개발자로서’ 해온 99%의 업무에 대신 ‘팀원으로서’ 내가 관심을 가져왔던 수면 아래의 그 1%의 일에 대해 적어보고자 한다.

1. 객관적인 데이터로 기획하기

문제: 주관에 의존한 기획

내가 팀에 합류했을 때는 투자유치를 위한 MVP가 이미 개발되어 있었다. 투자 이후 PO와 개발자들이 합류하며 프로세스도 점차 정립되었다. 하지만 새로 나아가려는 방향은 기존과 달랐기 때문에, 사실상 제품을 다시 만들어가는 상황이었는데 기획의 성과는 기대만큼 좋지 않았다.

두 가지여러 원인이 있었겠지만, 내가 본 주요 문제는 유저보다 만드는 사람의 주관에 의존하는 기획 방식이었다. 기획팀 안에서는 합의된 내용이라도 개발팀에는 왜 이것을 만들어야 하는지 충분히 전달되지 않는 경우가 있었다. 기획팀 구성원이 바뀔 때마다 방향이 크게 달라지기도 했다. 그 상태에서 성과까지 좋지 않다 보니, 내부 회의에서는 불만과 피로감이 드러났다.

이런 상황을 바꾸려면 특정 개인의 판단을 넘어 팀이 함께 납득할 수 있는 근거가 필요하다고 생각했다. 모든 기획은 시장에서 검증하기 전까지 하나의 가설이지만, 적어도 어떤 유저의 문제를 풀려는 것인지, 무엇이 달라지면 성공이라고 볼 것인지는 공유할 수 있어야 했다. 내가 생각한 공통의 근거는 실제 유저의 데이터였다.

이전 창업 경험에서도 기획의 답은 내 머릿속보다 유저에게 있는 경우가 많았다. 실제 유저의 필요에서 출발한 기획은 성과를 만드는 데 도움이 되었고, 팀원들을 설득하기에도 효과적이었다. 이번에도 유저를 함께 바라볼 수 있다면 기획의 방향을 잡고 팀의 의견을 모으는 데 도움이 될 것이라고 기대했다. 그래서 개발 업무를 병행하면서 유저 데이터를 지속적으로 확보할 방법을 찾기 시작했다.

시도 1: 유저 인터뷰하기

⌨️ 유저 인터뷰 요청과 직접 인터뷰

우선 대표님에게 미팅을 요청해 기존 유저 인터뷰를 확인했다. 사업 초기에 진행한 몇 건은 있었지만 최근 자료는 없었다. 유저 인터뷰가 기획의 성과를 높이는 데 도움이 될 것이라고 설명하고 진행 약속을 받았다. 다만 다른 업무에 밀려 바로 실행되지는 않았고, 이후에도 몇 차례 요청을 이어갔다. 그렇게 회사 차원에서 약 10건 내외의 심층 인터뷰가 진행되었다.

회사에서 인터뷰를 진행하는 동안, 나도 주변 지인을 통해 직접 인터뷰를 했다. 정리된 내용을 전달받는 것과 직접 이야기를 듣는 것에는 차이가 있다고 느꼈기 때문이다. 원하는 답을 유도하기보다 상대의 실제 생각과 생활패턴을 이해하는 데 집중했다. 표본은 제한적이었지만 새롭게 얻는 인사이트가 있었다.

이렇게 인터뷰를 통해 유저를 이해할 단서를 얻으면서, 일회성으로 끝내지 않고 계속 이야기를 들을 수 있으면 좋겠다고 생각했다. 하지만 회사 차원에서 인터뷰를 이어가기에는 비용과 인력, 시간 등 현실적인 제약이 있다는 피드백을 받았다. 인터뷰만으로 유저 데이터를 지속적으로 확보하기는 어려웠고, 이를 보완할 다른 방법을 찾기 시작했다.

시도 2: 유저 모니터링 툴 도입

⌨️ 유저 행동을 관찰할 수 있는 도구 도입

기획에 단기적으로 도움이 되지만, 도움이 되려면 지속적으로 유저로부터 데이터를 받을 대안이 필요하다. 그 대안으로 찾은 것이 유저 모니터링 툴이었다. (Clarity, PostHog) 유저 모니터링 툴을 이용하면 인터뷰를 매번 진행하지 않더라도 유저가 제품 안에서 어떻게 움직이고 어떤 행동을 하는지 화면으로 관찰할 수 있었다. 직접 이유를 물을 수는 없지만, 수치만으로는 보이지 않던 사용 맥락을 살펴볼 수 있다는 점에서 인터뷰를 보완할 수 있다고 생각해 도입했다.

이후 기획팀은 신규 기능이 추가되었을 때 실제 유저 행동을 관찰하고 인사이트를 얻는 데 이 도구들을 활용했다. 이벤트를 설정해 더 구체적인 데이터를 수집하는 방향으로도 이어졌고, 이후 어떤 이벤트를 추적할지는 기획팀에서 담당하게 되었다.

이렇게 행동을 관찰하고 지표를 수집할 수 있게 되면서, 다음으로는 그중 무엇을 중요하게 볼 것인지가 과제로 남았다. 숫자가 좋아 보여도 실제 비즈니스에는 도움이 되지 않는 허영지표를 경계해야 했기 때문이다. 주요 지표를 다시 살펴보는 과정에서 리텐션이 낮다는 문제를 확인했고, 이를 개선하려면 행동을 관찰하는 데서 더 나아가 유저가 제품에서 무엇을 필요로 하는지 이해할 단서가 필요하다고 생각했다.

시도 3: 검색 데이터 활용

⌨️ 이미 쌓이고 있던 검색 데이터 활용

추가 인터뷰가 어려운 상황에서 그 단서를 찾기 위해 이미 쌓인 데이터를 살펴보기로 했다. 백엔드 DB를 확인하던 중 최근 배포된 검색 기능의 검색어 데이터가 눈에 들어왔다. 행동 기록이 유저가 제품을 어떻게 쓰는지 보여주었다면, 검색어에는 유저가 그 순간 제품에서 무엇을 찾으려 했는지가 남아 있었다.

다만 원본 데이터는 그대로 활용하기 어려웠다. 의미를 파악하려면 다른 데이터와 연결하고 가공해야 했다. 그래서 검색키워드를 분류하고 분석할 수 있는 자동화 도구를 만들었다. 이를 통해 기존에는 파악하지 못했던 유저의 의도와 패턴을 살펴볼 수 있었고, 이후 실제 기능 기획에도 활용했다.

결과: 기획의 공통 근거 확보

💡 유저 데이터와 기획의 공통 근거 확보

인터뷰를 계속하기 어려워 행동 기록으로 보완했고, 유저의 필요를 더 들여다보기 위해 검색 데이터까지 활용하게 되었다. 처음부터 모든 방법을 계획했던 것은 아니지만, 제약에 부딪힐 때마다 다른 방법을 찾으면서 기획에 활용할 자료를 넓힐 수 있었다. 만드는 사람의 생각만이 아니라 실제 유저를 근거로 논의할 토대가 생긴 것이다.

다만 자료를 확보했다는 사실만으로 기획의 성과까지 좋아졌다고 말할 수는 없다. 팀의 의견 일치에 미친 영향도 정량적으로 확인한 것은 아니다. 다음 과제는 이렇게 확보한 데이터를 실제 문제 정의와 기능 기획에 연결해보는 일이었다.

2. 숨어있는 데이터를 분석해서 활용하기

문제: 낮은 장기 리텐션

유저 인터뷰, 유저 모니터링 툴, 검색 데이터 활용을 통해 객관적인 데이터를 바탕으로 하는 문화. 신규 유저 유치. 여전히 잘 풀리지 않았다.

(

유저 데이터를 확보하는 한편 제품에 대해서도 꾸준히 의견을 냈고, 그 공로(?)를 인정받아 개발자 중에서는 유일하게 기획 회의에 참여하게 되었다. 다만 회의에 참여하는 것과 기획을 온전히 맡는 것은 다른 일이었다. 매 스프린트마다 개발 업무가 있었기 때문에, 기여는 주로 부분적인 제안에 머물렀다.

그러던 중 퇴사를 앞두고 마지막 스프린트의 개발과 QA를 진행하며 잠깐 여유가 생겼다. 당시 기획팀은 새로운 기획을 내는 데 어려움을 겪고 있었고, 나에게 기획을 전담해달라는 요청이 왔다. 문제 정의부터 해결책 제시까지 맡아볼 기회였다.

)

처음 받은 요청은 사실 ‘아….좋은 아이디어가 없을까요?’에 가까웠다. 하지만 바로 아이디어를 떠올리기보다 지금 풀어야 할 문제가 무엇인지부터 확인하고 싶었다.

당시 팀에서는 MAU, 리텐션, 참여율 등 여러 지표를 보고 있었다. 이 제품은 단독으로 매출을 만드는 것이 아니라 외부 프로젝트와 연계해 매출을 만드는 구조였으므로, 제품 내부의 숫자만으로 우선순위를 판단하기는 어려웠다. 그래서 대표님과 미팅을 통해 외부 연계 프로젝트의 현황과 목표를 파악했다. 그 결과 장기적으로 매출에 영향을 줄 핵심 지표는 리텐션이라는 결론을 내렸다.

이후 PostHog의 코호트 분석으로 리텐션을 살펴보았다. 단기 리텐션에 비해 장기 리텐션이 낮았고, 특히 8주 안에 다시 방문하는 비율이 낮다는 점을 확인했다. 막연한 ‘새 기능 기획’이라는 요청은 ‘낮은 장기 리텐션을 개선할 가설을 세우는 일’로 구체화되었다.

시도 1: 검색 데이터 분석

💡 검색 데이터를 기획에 쓸 수 있는 자료로 만들기

리텐션을 개선한다는 목표는 정했지만, 그 사실만으로 어떤 기능을 만들어야 할지 알 수는 없었다. 유저가 제품에서 무엇을 필요로 하는지 살펴보고, 그중 다시 방문할 이유가 될 만한 필요를 찾아야 했다. 추가 인터뷰에는 제약이 있었으므로 과거 인터뷰를 다시 읽고 검색 데이터를 분석했다. 앞에서는 이 데이터를 활용하게 된 배경을 이야기했다면, 여기서는 실제 기획에 쓸 수 있도록 가공한 과정을 조금 더 구체적으로 설명하려 한다.

원본 검색어의 맥락을 확인하려면 MySQL JOIN으로 다른 데이터와 연결해야 했고, 이를 매번 수작업으로 반복하기에는 시간이 많이 들었다. 먼저 직접 데이터를 조회하며 반복되는 패턴을 찾았고, 이를 기준으로 검색어를 7개 카테고리로 나눴다. 개별 검색어 대신 비슷한 의도를 가진 검색들을 묶어 살펴볼 수 있게 한 것이다.

분류 기준을 만든 다음에는 이 작업을 어떻게 반복 처리할지 정해야 했다. 전부 AI로 처리하는 방법도 고려할 수 있었지만, 당시에는 예산 집행 절차뿐 아니라 프롬프트를 조정하는 시간, 반복적인 API 비용, 검색량 증가에 따른 처리 비용과 유지보수도 고려해야 했다. 그래서 모든 데이터를 AI에 맡기기보다 꼭 필요한 부분에만 활용하는 방식을 택했다. 정교한 시스템 자체보다 주어진 시간과 비용 안에서 기획에 쓸 수 있는 자료를 만드는 것이 목적이었다.

이 기준으로 검색키워드 가공 자동화 도구를 만들고 데이터를 분석했다. 그 결과 개별 검색어만 볼 때는 드러나지 않던 유저의 의도와 패턴을 살펴볼 수 있었다.

시도 2: 데이터 분석 자동화 툴 기획

💡 인사이트를 기능과 화면으로 구체화

분석을 통해 유저가 무엇을 찾는지 살펴본 뒤에는, 그 필요를 제품 안에서 어떻게 해결할지 고민하며 리텐션을 높이기 위한 기능을 기획했다. 출발점은 ‘이런 기능이 있으면 좋겠다’는 생각이 아니라 실제 유저에 대한 관찰이었다.

이 관찰이 왜 해당 기능의 제안으로 이어졌는지 팀원들에게 설명하기 위해 글뿐 아니라 Figma로 만든 Lo-fi 프로토타입도 준비했다. 같은 설명을 듣더라도 각자 상상하는 화면과 사용 흐름은 다를 수 있기 때문이다. 이 단계에서 중요한 것은 완성도 높은 디자인이 아니라, 제안하는 기능과 사용 흐름을 팀원들이 함께 보고 논의할 수 있게 만드는 것이었다.

문제 정의 과정과 분석 결과, 제안하는 기능을 기획안으로 정리해 발표했다. 퇴사를 앞두고 있었기 때문에 이후 작업을 이어갈 수 있도록 개발 관련 README도 함께 작성했다.

시도 3: 데이터 분석 자동화 툴 구현

• Python, 등 이용
• Heuristic 적으로 빠르게 구현

결과: 도입 결정

💡 기능 도입 결정과 인수인계까지 진행

몇 차례 회의를 거쳐 해당 기능을 도입하기로 결정했다. 데이터 분석에서 출발한 제안이 시도해볼 만한 기획으로 받아들여졌다는 점은 의미가 있었다. 다만 실제 개발 전에 퇴사했기 때문에 출시 여부와 이후 리텐션 개선 효과까지 확인하지는 못했다.

3. 안해도 되는 일 없애기

문제: 느린 실행속도

앞의 두 이야기가 무엇을 만들 것인지에 대한 고민이었다면, 이번에는 어떻게 더 빠르게 만들고 검증할 것인지에 대한 이야기다. 좋은 방향을 정하더라도 실행에 시간이 오래 걸리면 가설이 맞는지 확인하는 시점도 늦어진다. 그래서 개발 업무를 하면서는 속도를 늦추는 일이 무엇인지, 그중 하지 않아도 되는 일은 없는지 살펴보았다.

당시 눈에 띈 것은 핵심 가설과 무관한 디자인 차이 때문에 비슷한 기능을 반복해서 개발하는 일이었다. 기존에 만든 것을 재활용하면 될 일도 모양과 동작의 작은 차이 때문에 새로 구현해야 했다. 개발팀에서는 업무가 내려오면 ‘이걸 해야 하는가’보다 ‘어떻게 구현할 것인가’에 집중하기 쉬웠다.

이런 차이는 구현할 때뿐 아니라 이후 디자인 QA에서도 비용으로 돌아왔다. 색상과 컴포넌트의 종류가 늘어나고 세부 수정 요청이 반복되면서, 개발자들은 신규 기능 개발 외에도 매 스프린트마다 수정에 시간을 써야 했다. 일부 디테일은 사용자 경험에 중요하지만, 모든 차이가 핵심 가설을 검증하는 데 필요한 것은 아니었다. 개별 작업을 더 빨리 처리하기 전에, 차이 자체를 줄일 수 없는지 생각해볼 필요가 있었다.

시도 1: 불필요한 업무 파악 및 해결책 도출

💡 간소화된 디자인 시스템을 점진적으로 도입

시도 2: 디자인 시스템 설계하기

해결 방향은 재사용성을 높이고 가설 검증과 무관한 차이를 줄이는 것이었다. 이를 위해 간소화된 디자인 시스템을 제안했다. 하지만 좋은 대안을 찾는 것만으로는 부족했다. 디자이너와 개발자, PO가 각자 걱정하는 부분을 풀어야 실제로 도입할 수 있었다.

디자이너에게는 추상적으로 표준화를 요구하기보다 대안을 제시했다. Google Material Design과 IBM Carbon Design System에서 우리 상황에 참고할 부분을 찾고, 구체적인 화면 사례가 필요할 때는 Mobbin(디자인 레퍼런스 사이트)에서 사례를 찾아 제안했다. 모든 디자인을 한 번에 통일하기보다는 일부부터 적용하고, 기존의 표준화된 패턴을 활용할 수 있는 방향을 함께 찾았다.

개발자에게는 새로운 시스템을 익히는 비용보다 반복 업무를 줄이는 효과를 설명했다. 이미 바쁜 상황에서 또 일을 추가하는 것이 아니라, 앞으로 바쁠 일 자체를 줄이려는 시도라는 점을 이야기했다. 적용 방식이 막연하다는 이야기에 내가 먼저 초안을 만들어 보여주기로 했다.

PO가 걱정한 것은 일정이었다. 그래서 별도 스프린트를 할당해 전체를 교체하는 대신, 기존 화면은 두고 신규 디자인과 개발부터 점진적으로 적용하는 방식을 제안했다.

시도 3: 점진적으로 도입하기

💡 디자인 기준과 개발 구조를 함께 정리

점진적으로 도입한다는 원칙에 맞춰, 디자인에서는 색상 체계를 정리하고 타이포그래피 종류를 줄이는 방향을 잡았다. 기존 컴포넌트는 유지하되, 새로 만드는 컴포넌트는 최소 단위로 관리하고 유사한 것은 재활용하도록 했다.

디자인에서 정한 기준이 실제 구현에서도 유지되어야 반복 작업을 줄일 수 있었다. 그래서 개발에서는 공통 컴포넌트 패키지와 디자인 토큰을 정리하고, Atomic Design 방식과 Tailwind CSS, Storybook 등을 활용했다. 여러 채널에서 공통으로 사용할 수 있는 컴포넌트를 분리하고, 자동완성 등을 통해 정해진 기준을 적용하기 쉽게 만드는 방향이었다.

결과: 중복 구현과 QA 부담 감소

💡 반복 구현과 디자인 QA 부담 감소

디자인 기준과 공통 컴포넌트를 함께 정리하면서 유사한 컴포넌트를 중복 구현해야 하는 일이 줄었고, 디자인 QA 부담도 감소했다. 원고에 정리한 디자인 QA 감소 수치는 약 40%다. 다만 측정 기간과 산정 기준은 별도로 정리되어 있지 않으므로, 팀 전체 실행 속도가 같은 비율로 향상되었다는 의미로 확대해서 해석할 수는 없다.

수치와 별개로 이 작업에서 중요했던 것은 반복적으로 발생하던 일 자체를 줄였다는 점이다. 불필요한 수정과 중복 구현이 줄면서 새로운 가설을 실행하는 데 집중할 여지가 생겼고, 반복적인 디자인 QA로 인한 개발팀의 스트레스도 줄었다. 한 번의 작업을 빨리 끝내는 것을 넘어, 다음 작업에서도 같은 비용이 들지 않게 만드는 개선이었다.

마치며

이 글에서는 ‘팀원으로서의 일’만 이야기했지만, 사실 회사에서 일하는 동안에는 개발자로서의 일로도 머리를 싸맨 날이 많았다. 당장 해결해야 할 기술적인 문제와 타이트한 일정은 늘 있었고, 개발 문제를 해결하는 것 역시 내게 중요한 일이었다. 다만 그럴수록 잊지 않으려 했던 것은, 왜 이 코드를 쓰고 있는지 생각하는 일이었다. 아무리 잘 만들어도 정작 필요한 것을 만들고 있지 않다면 좋은 프로덕트로 이어지기는 어렵기 때문이다.

그 질문을 붙잡고 있다 보면 내 직무 밖의 일에도 의견을 내게 되었다. 하지만 필요하다고 생각하는 일을 이야기하는 것과, 실제로 팀의 일하는 방식을 바꾸는 것은 달랐다. 설명과 설득을 반복해야 했고, 그 과정이 외롭게 느껴질 때도 있었다. 같은 직무의 어려움은 함께 일하는 동료들이 알아주지만, 여러 역할 사이에 걸친 일은 누가 알아주는 일이 드물기 때문이다. 이런 일들은 대개 권한은 없고 책임과 의무만 있는 일이기 마련이다.

하지만 중요한 일이라는 건 종종 그런 특성을 가지고 있는 듯 하다. 중요한 일 중에 쉬운 일이란 없다. 그리고 중요한 중에 사람을 설득하는 일이 빠진 일들은 거의 없다. 그래서 더 어렵고, 그래서 더 중요하다.

‘팀원으로서의 일’은 그런 일 같다. 어려운 일. 하지만 중요한 일. 그래서 해야 하는 일.

항상 본질을 잘 파악하는 그런 사람이 되고싶다는 생각을 하면서 온아웃 회고를 마친다.