느닷없이 거센 돌풍이 불어 낯선 땅에 착륙했다든지, 망망대해에서 방향을 잃고 외딴 섬에 표류하게 되었다든지, 시공간이 뒤틀려 새로운 행성에 도착했다든지.

낯선 곳에서 홀로 남겨져 살아남아야 하는 이야기들이 참 많습니다.

그중에서도 소설을 원작으로 한 영화 마션을 참 재미있게 봤습니다. 화성에 홀로 남겨진 우주비행사가 제한된 자원과 지식으로 살아남아 지구로 귀환하기 위해 고군분투하는 이야기입니다.

그리고 불과 몇 달 전, 저한테도 비슷한 일이 벌어지고 말았습니다.

이 글에서는 서비스 개발자였던 제가 플랫폼 조직으로 이동하면서, 낯선 환경을 이해하고 저만의 일하는 방식을 만들어간 과정을 이야기해보려 합니다.

1. 플랫폼 행성에 떨어졌습니다

여느 조직이 그렇듯 제가 속한 조직에도 올해 몇 차례 조직개편 폭풍이 지나갔습니다.

지금껏 3년 가까이 프론트엔드 개발자로 배달의민족의 B마트, 배민스토어 서비스를 개발해 왔던지라 이번에도 크게 다르지 않을 거라 생각했습니다. 그런데 정신을 차려보니, 제 팀 이름에는 서비스가 아닌 플랫폼이라는 글자가 있었습니다.

분명 옆자리에 있어야 할 디자이너, PM, 데이터 분석가들은 보이지 않고, 주위엔 온통 서버 개발자들이 저를 쳐다보고 있었습니다. 다행히 이 낯선 행성에 떨어진 프론트엔드 개발자는 저 혼자는 아니었습니다. 한 명이 더 있었고, 그렇게 둘이서 프론트엔드 영역을 담당하게 되었습니다.

그럼에도 팀에서 다루고 있는 제품과 도메인은 낯설었고, 당장 내일 무엇부터 해야 할지 막막했습니다.

일단 플랫폼 행성은 어떤 곳인지부터 살펴보기로 했습니다.

AI로 생성한 이미지

2. 감자도 심고 로그도 심어봅시다

플랫폼이란 여러 서비스와 조직에 공통 기능과 규칙을 제공하는 기반입니다.

B마트와 배민스토어처럼 상품을 판매하는 배달의민족 커머스가 안정적으로 운영되기 위해서는 다양한 플랫폼이 필요합니다. 그중에서도 제가 속한 팀이 담당하는 것은 커머스 서비스의 전시(Display) 운영을 지원하는 전시플랫폼입니다.

상품을 어떤 고객에게, 어느 시점에, 어떤 영역에서, 어떤 혜택을 적용하여 제공할지 설정할 수 있는 사내 MD, 마케터, 사업 운영과 같은 운영자들이 사용하는 전시어드민을 제공하고 있습니다.

그리고 이 어드민에는 50개 정도의 메뉴가 존재합니다. 매우 많습니다.

각각의 메뉴가 어떤 기능을 제공하는지는 코드를 살펴보면 알 수 있었습니다. 문제는 어떤 조직에서 얼마나 자주 사용하는지, 실제 업무에서는 어떤 패턴으로 쓰이는지 파악할 방법이 거의 없었다는 것입니다. 새롭게 구현할 기능이나 개선할 부분들은 보였지만, 개발자인 제가 보기에 불편해 보이는 지점과 실제 업무에서 불편을 겪는 지점이 같은지는 알 수 없었습니다.

무엇부터 해야 할지 결정하려면, 우선 어떻게 쓰이고 있는지부터 알아야 했습니다.

마션의 주인공이 식물학 지식을 살려 감자를 심었듯, 그간 서비스 개발을 하며 쌓아온 경험을 살려 로그부터 심는 것이 최우선이라 생각했습니다.

이미 로그를 적재하고 있는 환경이었다면 기존 컨벤션에 따라 추가하면 되겠지만, 플랫폼 행성에는 사용자 행동을 공통된 기준으로 수집하고 분석할 기반이 없었습니다. 고로 처음부터 설계를 시작했습니다.

페이지 조회, 검색, 항목 생성 및 수정 등 어드민에서 공통으로 일어나는 행동을 정의하고, 이를 적재하는 Tracker 모듈을 만들었습니다. 메뉴마다 이벤트 이름과 속성이 달라지지 않도록 공통된 수집 기준을 만드는 데 신경을 썼습니다.

자주 확인하는 지표는 대시보드로 구성했습니다. 아래는 메뉴별 조회 수와 조직별 사용 비중을 한눈에 보려고 만들었던 대시보드의 일부입니다.

어드민 사용 현황 분석 대시보드 발췌

다른 플랫폼 조직에서도 같은 기준을 사용할 수 있도록 로그 시스템을 모듈화했습니다.

이제 사용자 행동 데이터가 쌓이고, 이를 지표로 플랫폼을 이해할 기반이 마련된 겁니다.

3. 레버리지가 큰 곳을 찾아봅시다

기반을 마련했으니 이제는 새로운 기능들을 구현하고 비효율을 개선할 차례입니다.

하지만 50개나 되는 메뉴를 두 명이 하나씩 맡아서 개선하는 데에는 한계가 있었습니다.

한정된 시간이라는 자원을 어디에 사용해야 가장 큰 효과를 낼 수 있을지 고민해야 했습니다. 한 번의 개선이 여러 업무에 반복해서 도움이 되는 지점, 이른바 레버리지가 큰 곳을 찾기 시작했습니다.

이때 앞서 쌓아둔 데이터를 활용했습니다.

[공통 컴포넌트를 살펴봅시다]

여러 조직에서 자주 사용하는 메뉴를 살펴보고, 그 안에서 반복적으로 쓰이는 공통 컴포넌트를 중심으로 개선점을 찾았습니다. 단순히 공통 컴포넌트가 몇 개의 메뉴에 들어 있는지뿐 아니라, 어떤 조직에서 얼마나 자주 사용하는지도 함께 살펴보았습니다.

그중 인상적인 사례가 필터 컴포넌트입니다.

로그를 살펴보니 조회 페이지 방문 세션의 80% 이상에서 필터 조작과 직접 검색이 발생하고 있었습니다. 문득 이런 생각이 들었습니다.

필터는 많이 사용할수록 나쁜 컴포넌트가 아닐까?

정확히는, 같은 정보를 보기 위해 같은 조건을 매번 다시 입력해야 한다면 말입니다. 사용자는 필터를 조작하러 온 것이 아니라 업무에 필요한 정보를 확인하러 왔으니까요.

처음에는 최근 사용한 조건을 브라우저 저장소(예: localStorage)에 저장하고 복원하도록 했습니다. 이 간단한 변경만으로 필터를 조작하는 세션의 비율이 현저히 줄어들었습니다.

보다 자세히 사용 패턴을 데이터로 살펴보니 제목이나 ID와 같은 특정 항목을 번갈아 조회하는 경우가 많았습니다. 그래서 자주 쓰는 조건을 탭으로 저장하고 재사용할 수 있도록 한 단계 더 개선했습니다. 신규 컴포넌트를 적용한 메뉴를 기준으로, 필터 조작이나 검색 없이 상세 페이지로 바로 이동한 비율은 5.8%에서 22.6%로 약 3.9배 증가했고, 상세 페이지에 접근하기까지 걸리는 시간(중앙값)도 10.4초에서 8.3초로 20% 이상 줄었습니다.

필터 탭 UI 컴포넌트

필터를 열심히 만들었더니 사용자가 필터를 덜 조작하게 됐습니다. 참으로 좋은 소식이 아닐 수 없습니다.

아래 그래프는 기존 필터(v1), 조건 복원(v2), 필터 탭(v3) 단계별로 필터 미사용 비율과 상세 항목 진입 시간을 비교한 결과입니다.

[우선순위를 정해봅시다]

하지만 단순히 공통 컴포넌트만 개선한다고 모든 문제가 해결되는 것은 아닙니다. 특정 메뉴의 기능 추가나 사용성 개선처럼 개별적인 요구사항도 쉼 없이 밀려들어옵니다. 제한된 시간 안에서 이 모든 요구사항을 다룰 수는 없기에, 무엇을 먼저 할지 판단하는 기준이 필요했습니다.

물론 우선순위를 단순히 사용량만으로 결정할 수는 없습니다. 비즈니스적으로 반드시 필요한 일과 시급하게 해결해야 하는 문제는 그 자체로 중요합니다. 다만 개선이 필요한 지점을 찾거나, 비슷한 중요도의 과제 중 하나를 선택해야 할 때는 개선 결과가 얼마나 넓은 범위에 반복해서 도움이 될 수 있는지를 함께 살펴보았습니다.

이때도 데이터는 좋은 판단 근거가 되었습니다. 전시어드민의 페이지 방문 빈도와 이를 사용하는 조직을 살펴보며 실제 업무에서 많이 쓰이는 영역을 파악했습니다. 그리고 하나의 문제를 해결하더라도 여러 조직과 메뉴에 적용할 수 있는지, 앞으로 다른 과제를 진행할 때도 그 개선 효과를 이어갈 수 있는지를 고려했습니다.

누군가의 10초를 줄이는 일은 작아 보일 수 있습니다. 하지만 같은 10초가 여러 메뉴에서 많은 사용자에게 하루에도 몇 번씩 반복된다면 이야기가 달라집니다. 결국 중요했던 것은 가장 많이 쓰이는 화면을 찾는 것이 아니라, 한정된 자원으로 더 많은 사용자의 업무를 더 나아지게 만들 수 있는 지점을 찾는 것이었습니다.

아래 이미지는 어드민의 메뉴별 사용 세션 수를 면적으로 나타낸 차트로, 파란색은 이미 개선이 완료된 메뉴를 의미합니다. 글 작성 시점을 기준으로 어드민 전체 기능의 82%의 커버리지를 달성했습니다.

조직별 메뉴 사용량에 따른 개선 범위 커버리지 분석 자료 발췌

4. 생존 기지를 구축합니다

화면을 만드는 것 말고도 해야 할 일은 참 많았습니다.

제가 서비스 개발을 하던 조직에서는 정책 검토, UI/UX 설계, 데이터 분석, QA를 각 직군의 동료들과 함께 수행했습니다. 플랫폼으로 옮겨온 뒤에도 필요한 일은 크게 다르지 않았습니다. 다만 이 모든 과정에서 전담 인력의 도움을 받기는 어려웠습니다.

담당하는 사람이 곁에 없다고 해서 그 일을 하지 않아도 되는 것은 아닙니다. 그럼에도 매번 제가 시간을 더 쓰는 방식으로는 오래 지속하기 어려웠습니다. 그래서 어느 순간부터 질문을 바꾸기 시작했습니다.

“이 일을 누가 해야 하지?”보다 “이 문제를 해결하려면 지금 어떤 능력이 부족하지?”로요.

그렇게 매번 스스로 찾아보고, 설명하고, 확인하던 일들을 도구로 만들거나 자동화하기 시작했습니다.

[고민을 시작하는 비용을 줄여봅시다]

먼저 데이터와 지표를 확인하는 수고를 줄였습니다.

2장에서 로그를 모을 기반은 만들었지만, 새로운 가설을 확인하려면 여전히 데이터의 위치와 스키마부터 찾아야 했습니다. BigQuery를 비롯한 데이터 분석 도구를 MCP로 연결하고, 분석에 필요한 절차를 Skill로 정리했습니다. 클로드와 같은 AI Agent가 스키마를 탐색하고 실제 데이터를 조회할 수 있도록 했습니다. 아직 기준과 결과는 스스로 확인하고 판단해야 하지만, ‘필터 탭을 적용한 뒤 상세 페이지 진입 시간이 줄었나?’ 같은 질문들도 부담 없이 궁금할 때마다 확인해볼 수 있었습니다.

복잡한 정책과 개발 지식도 AI가 참조할 수 있는 LLM Wiki와 Skill로 정리했습니다. 덕분에 작업을 요청할 때마다 용어와 정책, 구조를 다시 설명하지 않고도 필요한 컨텍스트를 쉽게 제공할 수 있었습니다.

화면을 고민할 때는 AI로 간단한 목업을 만들었습니다. 가끔 머릿속에서 그려보았을 때는 굉장히 편하고 세련될 것 같았던 UI도 막상 화면으로 나오면 어딘가 모자랄 때가 있습니다. 미리 확인해 볼 수 있는 목업이 있으면 이런 차이를 빨리 발견할 수 있었습니다. 사용자 인터랙션을 검토하고, 필요한 기능과 API를 협의하거나 아이디어를 공유하기에도 편했습니다.

[배포 전 검증하는 비용도 줄여봅시다]

여러 곳에서 사용되는 컴포넌트나 기능을 수정하면 이를 사용하는 여러 메뉴를 함께 확인해야 했습니다. 3장에서 설명한 레버리지가 큰 지점일수록 배포 전 검증해야 할 범위 역시 넓어졌습니다.

테스트 코드는 매번 CI에서 확인하지만, 안정성을 높이려면 새롭게 추가된 스펙이 실제 화면에서도 의도대로 동작하는지 여러 시나리오를 통해 검증하는 과정이 필요했습니다. 안정성 확보를 위해 AI를 적극적으로 활용했습니다.

첫 번째로 배포 전 최종 QA 단계의 TC(Test Case) 작성에 활용했습니다. MR의 코드 변경분(diff), 요구사항이 정리된 Jira 티켓, 과제 기획서, 정책과 코드 지식이 정리된 LLM Wiki를 참조하여 TC를 구성하는 절차를 Skill로 작성했습니다.

다음으로 이렇게 구성한 TC를 AI가 Playwright로 실제 브라우저에서 수행하도록 했습니다. 값을 입력하고, 버튼을 누르고, 화면을 이동하면서 결과를 확인하고, 수행 내역과 스크린샷을 남기도록 했습니다. 단순히 통과나 실패라는 결과만 보는 것이 아니라, 실제로 무엇을 어떻게 확인했는지까지 살펴볼 수 있었습니다.

아래는 앞서 설명한 QA 자동화 도구의 실제 구동 화면입니다. AI가 직접 TC 96건을 수행했고, 우측에 TC별 수행 절차와 기록이 남아 있습니다.

이 구조를 기존에 작성해 둔 테스트와 결합해, 배포마다 확인할 시나리오를 새로 구성하는 회귀 테스트(Regression Test)에도 활용했습니다. 한정된 QA 리소스를 절약하면서도, 간단한 수정 배포 시에는 충분히 활용할 수 있는 검증 도구가 되었습니다. 물론 AI가 만든 테스트 케이스와 결과를 그대로 신뢰하지는 않았습니다. 중요한 시나리오는 사람이 검토하고, 반복적으로 확인해야 하는 영역을 자동화하는 방식으로 활용했습니다. 그 덕분인지 해당 과정을 거쳐 배포한 변경에서는 글을 작성하는 현재까지 별도의 운영 이슈가 발생하지 않았습니다.

매번 스스로 하기 오래 걸리고 귀찮았던 일들을 조금 더 효율적이고 안정적으로 처리할 수 있는 시스템으로 만들었습니다.

이제 제법 생존 기지 비스무리한 모습이 된 것 같습니다.

5. 이제 플랫폼 행성도 익숙해졌습니다

플랫폼 팀에서 보낸 지난 몇 달간, 단순히 코드를 작성하기보다는 실제 운영자들의 업무와 프로덕트를 만들기 위한 워크플로를 치열하게 고민했습니다.

돌아보면 플랫폼에서 제가 가장 공들여 만든 것은 화면보다도, 무엇을 해야 할지 판단하고 반복해서 개선해 나갈 수 있게 해주는 제 업무 자체의 플랫폼이었습니다.

시작은 미약했습니다. 무엇부터 해야 할지 막막해서 익숙한 방식대로 로그부터 심어보았고, 요구사항은 많은데 하나씩 해결할 시간이 부족하여 공통 분모와 영향 범위를 기준으로 우선순위를 판단했습니다. 스스로 부족한 능력은 AI로 보완하고, 반복되는 일은 도구와 자동화로 해결했습니다.

당장 답답한 것들을 하나씩 해소하다 보니 오래 지속할 수 있는 업무 환경도 만들어졌습니다.

물론 아직 고칠 곳은 한참 남아 있습니다. 그래도 조금씩 나아지고 있다는 것은 참 뿌듯한 일입니다.

역시 인간은 적응의 동물입니다.

어디선가 각자의 낯선 행성에서 고군분투하고 계신 분들 모두 파이팅입니다.