| Editor’s Note PFCT의 온투금융 플랫폼 ‘크플’은 사업이 빠르게 크는 만큼 앱도 쉴 새 없이 바뀝니다. 한 달에 반영되는 코드 변경만 196건, 당연히 화면도 그만큼 자주 새로 생기거나 달라지는데요. 그동안은 바뀐 화면을 팀원 모두가 확인할 수 있게 누군가 피그마 흐름도에 한 땀 한 땀 옮겨 그려야 했습니다. 사람 손으로 하다 보니 빠뜨리는 화면이 생겼고, 흐름도는 어느새 실제 앱과 달라지곤 했죠. Client Team 예지님은 여기서 반짝이는 아이디어를 내놓았습니다. 더 부지런히 그리는 게 답이 아니라면, 아예 사람이 안 그리면 되지 않을까? 화면 정보는 이미 코드에 다 적혀 있으니까요. 그렇게 나온 게 ‘크플 프로덕트 맵’입니다. 앱 코드를 읽어 화면과 화면 사이 이동을 스스로 그리고, 코드가 바뀌면 지도도 알아서 다시 그려지죠. 화면 630여 개, 화면 사이 이동 1,300여 개, 상태별 스크린샷 6,100장. 관리하는 사람이 없어도 지도는 늘 지금 서비스의 모습 그대로입니다. 이번 글에는 프로덕트 맵이 어떤 아이디어에서 출발했는지, PM·CX·데이터 분석 등 여러 직군이 이 지도를 어떻게 쓰고 있는지 담았습니다. 흐름도와 실제 화면이 달라 헤맨 적이 있거나 팀이 같은 화면을 보는 방법을 고민하고 있다면, 이 글이 힌트가 되어줄 거예요. |
들어가며
안녕하세요, PFCT Client Team 프론트엔드 개발자 하예지입니다.
크플 프로덕트 맵은 당연하게 여기던 불편함에서 시작됐습니다. 새 기능 출시를 앞둔 어느 날, 디자이너가 새 화면 수십 장을 피그마에 옮기는 모습을 보며 ‘사람 손을 거치지 않고 화면을 한데 모아 볼 방법은 없을까?’ 하는 생각을 하게 된 건데요.
화면을 찾아 헤매는 건 출시 때만의 일이 아니었습니다. 평소에도 회사 안에서는 화면을 두고 이런 질문이 매일 오갔거든요.
“투자 완료하고 나면 다음에 어느 화면으로 가요?”
“우리 앱에 화면이 몇 개나 있어요? 어디서 한 번에 봐요?”
“이 이벤트, PRD대로 붙어 있는 거 맞아요?”
“고객이 출금 버튼이 안 보인대요. 어느 화면이죠?”
디자이너가 아무리 부지런히 흐름도를 그려도 하루에도 몇 번씩 바뀌는 앱을 전부 피그마로 옮길 수는 없었어요. 그래서 앞의 질문들에 답하려면 매번 레포를 뒤져 코드 안에서 찾아야만 했습니다.
클라이언트 개발자가 서비스 지도를?
레포를 뒤지는 일이 반복되다 보니 거꾸로 생각해 보게 됐습니다. 답이 늘 코드에 있다면 지도도 코드에서 바로 뽑을 수 있지 않을까? 화면이 어떻게 생겼고 언제 보이는지, 어떤 API를 부르고 어떤 이벤트를 기록하는지까지 전부 클라이언트 코드에 담겨 있거든요. 그렇다면 이 정보를 꺼내 지도로 그리는 일은 그 코드를 매일 만지는 클라이언트 개발자가 잘할 수 있는 일이 아닐까 싶었습니다.
생각만 하기보다 직접 만들어 보기로 했습니다. 혼자 웹뷰 화면 몇 개로 프로토타입을 만들었는데, 코드에서 뽑은 화면들이 실제 이동 순서대로 이어지는 걸 보니 ‘이거 해 볼 만하겠는데?’ 싶더라고요.
하지만 웹뷰만으로는 반쪽짜리 지도였습니다. 크플 서비스는 웹에서 끝나지 않거든요. 투자 한 번만 해도 웹·Android·iOS 화면을 넘나드는데요. Android와 iOS는 쓰는 언어부터 코드 구조까지 웹과 달라서 제가 혼자 들여다보기는 어려웠어요. 두 앱 화면까지 지도에 담으려면 각 앱 코드를 잘 아는 개발자들의 도움이 꼭 필요했죠.
말로 설명하는 것보다 직접 보여 주는 게 빠르겠다 싶었습니다. 그래서 데모와 제안 문서를 들고 팀원들을 찾아갔고, 다행히 모두 함께하기로 해, 프로덕트 맵 제작은 클라이언트 팀 프로젝트가 되었습니다.
물론 쉽지는 않았어요. 웹·웹뷰·Android·iOS 네 가지 코드에서 화면을 뽑아 한 장의 지도로 잇는 일도, 화면마다 상태별 스크린샷 수천 장을 자동으로 찍는 일도 까다로웠거든요. 이 과정은 다음 편에서 자세히 풀기로 하고, 이번 글에서는 그렇게 완성된 지도로 무엇을 할 수 있는지부터 보여 드릴게요.
프로덕트 맵으로 할 수 있는 것
1) 코드를 따라 바뀌는 지도
개발자가 화면을 새로 만들거나 화면 사이 이동을 바꾸면 다음 추출 때 지도가 알아서 갱신됩니다. 프로덕트 맵 쪽 코드는 한 줄도 고칠 필요가 없습니다. 프로덕트 맵을 만들면서 가장 중요하게 생각했던 포인트입니다.
2) 한 장으로 보는 서비스 전체
기획서의 화면 흐름도를 서비스 전체로 넓혀 한 장에 펼친 모습입니다. 화면은 투자·대출·커뮤니티 같은 도메인 단위로 묶여 있습니다. 줌 아웃하면 서비스 전체가 보이고 화면 하나하나는 줌 인해서 볼 수 있습니다.
3) 상태별 화면 보기
화면을 누르면 같은 화면이 데이터에 따라 어떻게 달라지는지, 로딩 중에는 어떻게 보이는지 상태별 스크린샷으로 볼 수 있습니다.
4) Android와 iOS를 나란히
같은 기획이라도 Android와 iOS는 OS마다 따르는 관례가 달라 화면이 조금씩 달라집니다. 프로덕트 맵은 두 앱의 같은 화면을 페어링해 나란히 보여 줘서, 의도한 차이와 의도하지 않은 차이를 한눈에 가를 수 있습니다. 지금은 100여 개 화면을 이렇게 비교할 수 있습니다.
5) 화면에서 코드로, 코드에서 화면으로
화면마다 나가는 이벤트, 호출하는 API, 소스 코드 위치가 붙어 있습니다. 반대로 API 경로나 이벤트 이름으로 검색하면 그걸 쓰는 화면이 모두 나옵니다. API를 바꾸기 전에 영향받는 화면을 미리 짚어 볼 때 씁니다.
프로덕트 맵을 펼치니 보인 것들
지도의 쓸모는 화면을 찾는 데서 끝나지 않았습니다. 수백 개 화면을 나란히 놓자 하나씩 볼 때는 지나쳤던 것들이 드러났거든요. 그중 두 가지를 소개합니다.
1) 에러를 받아도 정상처럼 보이는 화면
상태별 스크린샷에는 서버에서 400 에러를 받은 상태도 담겨 있습니다. 이 상태로 찍힌 12장을 모아 보니 정상 화면과 다르게 그려진 건 단 1장뿐이었어요. 나머지 11장은 요청이 실패했는데도 사용자에게 아무 안내 없이 정상 화면처럼 보였죠. 지도를 보고서야 알게 된 사실이었습니다.
2) 같은 흐름, 다른 단계
앞에서 Android와 iOS의 같은 화면이 조금씩 어긋나 있다고 했는데요. 화면 하나가 아니라 흐름 전체가 다른 곳도 있었습니다. 투자자 등록의 계좌 인증이 그렇습니다. iOS에서는 은행 선택, 계좌번호 입력, 인증 확인 세 화면으로 나뉘는데 Android에서는 한 화면에서 끝나요. 같은 기획이 OS마다 다르게 구현된 셈입니다. 두 앱을 나란히 놓고 보지 않았다면 알아채기 어려운 차이였죠.
지금은 두 문제 모두 지도에서 발견한 뒤 바로잡았습니다.
프로덕트 맵 버전 관리
이처럼 문제를 고치고 나면 고치기 전 화면은 어땠는지 다시 보고 싶을 때가 있는데요. 프로덕트 맵은 지난 모습도 기억합니다. 코드가 바뀔 때마다 지도를 새로 그리지만 이전 지도는 지우지 않고 쌓아 두거든요. 과거 시점을 고르면 그때의 서비스 전체가 그대로 열립니다.
화면 하나만 골라서 거슬러 올라갈 수도 있어요. 화면마다 커밋 기록이 붙어 있어서 언제, 누가, 왜 바꿨는지 보입니다. 이 기록을 따라가면 화면 하나가 어떤 변화를 거쳐 지금의 모습이 됐는지 알 수 있죠.
이제는 레포 대신 지도를 엽니다
이제 ‘들어가며’의 질문들로 돌아가 볼게요. 예전에는 질문 하나에 답하려면 웹·Android·iOS 레포를 차례로 열어 봐야 했습니다. 지금은? 프로덕트 맵에서 바로 답을 찾을 수 있죠.
“투자 완료하고 나면 다음에 어느 화면으로 가요?”
지도에서 투자 완료 화면을 찾으면 다음 화면이 화살표로 이어져 있어요. 개발자를 찾아가 묻지 않아도 흐름을 직접 따라가 볼 수 있습니다.
“우리 앱에 화면이 몇 개나 있어요? 어디서 한 번에 봐요?”
지도를 줌 아웃하면 서비스 전체 화면이 한 장에 보입니다. 어디부터 봐야 할지 모를 때 전체 그림부터 잡을 수 있죠.
“이 이벤트, PRD대로 붙어 있는 거 맞아요?”
화면을 누르면 그 화면에서 나가는 이벤트가 Android·iOS별로 보입니다. 기획서와 맞는지 보려고 앱에 직접 들어가 눌러 볼 필요가 없어졌어요.
“고객이 출금 버튼이 안 보인대요. 어느 화면이죠?”
지도에서 ‘출금’을 검색하면 최신 버전 기준 화면이 바로 나옵니다. 과거 지도가 쌓여 있어도 검색은 늘 지금 화면부터 보여 주니까, 고객이 보고 있는 화면을 바로 확인할 수 있습니다.
앞으로
지금까지는 여러 직군이 지도를 ‘보는’ 데 썼다면, 앞으로는 더 많은 일을 지도 위에서 할 수 있게 하려고 합니다.
- 지도 위에 코멘트를 남길 수 있게 해서 제품을 만들 때 PM·디자인·개발이 프로덕트 맵 하나만 보면 되도록 만들 생각입니다.
- 마케팅팀이 푸시를 눌렀을 때 열리는 화면을 지도에서 바로 확인할 수 있게 하려고 합니다.
- 아직 사람 손이 가는 곳도 줄여 나갈 겁니다. 새 화면이 생기면 사람이 테스트 데이터를 따로 만들지 않아도 지도에 바로 올라오게 하는 게 다음 목표입니다.
마치며
‘사람 손을 거치지 않고 화면을 한데 모아 볼 방법은 없을까?’ 디자이너가 피그마에 화면을 옮기는 모습을 보며 떠올린 이 질문이 클라이언트 팀 전체의 프로젝트가 됐습니다.
AI가 코드를 대신 써 주게 되면서 클라이언트 개발자가 할 수 있는 일도 넓어지고 있습니다. 저는 화면을 만드는 데서 그치지 않고 플랫폼 코드에 담긴 지식을 꺼내 회사 전체와 AI가 쓸 수 있게 하는 일까지 클라이언트 개발자의 몫이라고 생각합니다. 프로덕트 맵은 제게 그 첫 시도였습니다.
다음 편에서는 코드에서 화면을 뽑고, 세 플랫폼의 스크린샷을 찍고, Android와 iOS 화면을 페어링한 방법을 기술적으로 풀어 보겠습니다.
written by Yeji
edited by Hoonjung
반짝이는 아이디어를 펼칠 곳을 찾고 있다면
