[Interview] 문제의 본질을 찾아서: 야구장 시야 서비스, SPOT!

Depromeet(디프만)

18 min readDec 20, 2024

안녕하세요. 디자이너와 프로그래머가 만났을 때, 디프만 16기 운영진입니다.

이번 인터뷰에서는 지난 15기에서 대상을 수상하며 뛰어난 성과를 보여준 ‘내가 만들어가는 야구장 시야 서비스, SPOT!⚾’을 소개하고자 합니다.

UT 단계부터 배포까지 SPOT!이 발전해가는 모든 과정을 지켜본 사용자로서, 이들의 서비스를 향한 애정과 열정을 두 눈으로 확인할 수 있었는데요.

문제의 핵심을 찾아서 끊임 없이 개선방안을 고민해온 SOPT!팀의 이야기를 함께 만나보시죠!

ㅤ

안녕하세요, 만나서 반갑습니다!
먼저 간단한 자기소개와 팀에서 어떤 역할을 맡으셨는지 소개해주세요.

조관희(안드로이드)

4학년 2학기 대학교를 재학 중인 조관희라고 합니다. SPOT! 팀 내에서는 안드로이드 개발을 맡았습니다.

이윤선(디자인)

SPOT! 팀에서 디자이너로 활동한 이윤선입니다.
저는 게시물을 등록하는 플로우와 3D 캐릭터를 포함한 전반적인 그래픽 디자인을 맡았습니다.

정준원(서버)

저는 SPOT! 팀에서 서버 파트장으로 활동했던 정준원이라고 합니다.

ㅤ

Interview 01. 내가 만들어가는 야구장 시야 서비스, SPOT!

SPOT!에 대해서 간단하게 소개해주세요.

조관희(안드로이드)

SPOT!은 야구장 좌석 시야 정보를 제공하는 서비스예요.
특정 좌석을 검색하면 좌석 시야 사진과 후기를 한눈에 확인할 수 있어요.

또한, 사용자들이 이용했던 좌석 시야 정보를 사진이나 글로 직접 등록할 수 있어요.

성과에 대해서도 얘기를 안할 수 없을 것 같은데요.
자랑할만한 성과 소개주세요!

조관희(안드로이드)

우선 디프만 런칭 데이에서 대상🏆을 받았고, 디스콰이엇 트렌딩 프로덕트 5일 연속 1위🥇를 기록했어요.

또, 여러 곳에서 서비스 홍보 문의가 들어왔고, 초기에 약 300명의 유저를 확보했어요.
대학생으로서 이렇게 유저를 직접 확보하고 서비스를 운영해 본 경험은 정말 특별하다고 생각해요.

무엇보다도, 저희 팀원들의 열정이 이런 결과를 만들어냈다는 점이 가장 자랑스러워요.
팀원들이 보여준 노력과 열정이야말로 이 프로젝트의 진정한 성과라고 생각해요.

이윤선(디자인)

저도 자랑하고 싶은 성과가 있어요.
저희 디자인 팀에서 프로젝트 작업물을 비핸스(Behance)에 올렸는데, 거기서 🎊공식 UI 뱃지🎊를 받았어요.

저희 팀의 노력을 인정받은 것 같아 개인적으로도 정말 뿌듯했어요.

SPOT!은 어떤 기획을 바탕으로 시작하게 되었나요?

조관희(안드로이드)

SPOT!은 ‘흩어져 있는 시야 정보를 한곳에 모아,
사용자들이 좌석 시야 정보를 쉽고 빠르게 확인할 수 있도록 돕자’는 취지에서 시작되었어요.

처음에는 야구장과 뮤지컬 극장 중 어느 곳의 시야 정보를 제공할지 고민이 많았어요.

뮤지컬 극장은 사진 촬영이 제한된다는 현실적인 문제가 있었고 팀 내에서도 뮤지컬보다는 야구에 대한 이해도가 높아,
야구장 좌석 시야 정보를 제공하기로 결정했어요.

사용자들이 실제로 어떤 문제를 겪고 있었는지 더 자세하게 들어볼 수 있을까요?

이윤선(디자인)

먼저 인터뷰를 통해 사용자가 실제로 겪고 있는 문제를 파악하고자 했어요. 인터뷰 결과, 많은 분들이 야구장을 방문하기 전에 방해 요소를 피하기 위해 좌석 정보를 검색한다는 점을 알게 되었어요.

조사 과정에서 이미 좌석 시야를 제공하는 다른 서비스 A를 알게 되었지만, 해당 서비스에서 제공하는 정보는 한정적이고 불충분했어요.

첫째, 특정 구역에 대해 한 장의 이미지만 제공하다 보니 그 시야가 실제로 어떤지 제대로 파악하기 어려웠어요.
둘째, 야구장에서는 좌석 간의 다리 공간이나 기타 편의 요소도 중요한데, 이런 부수적인 정보는 제공하지 않았어요.

사용자들은 해당 플랫폼을 통해 얻은 정보 외에도, 추가 정보를 얻기 위해 블로그를 4~5개씩 찾아보는 경우가 많았어요.
저희는 반복적으로 추가 검색을 해야한다는 점이 사용자들을 크게 불편하게만든다고 판단했어요.

그래서 신속하고 자세한 후기를 제공할 수 있는 서비스를 만들어야겠다고 결심했죠.

이미 타 서비스가 있었음에도 불구하고 그 안에서 한계점을 발견하고 개선하려고 한 점이 멋지네요!
A 서비스와 비교되는 SPOT!만의 차별점은 무엇이 있을까요?

정준원(서버)

운영진들이 정해둔 자리의 후기만 보여주는 A서비스와 달리, SPOT!에서는 사용자가 직접 후기를 작성할 수 있어요.
직접 작성된 후기를 통해 훨씬 다양한 좌석 정보를 제공하고 있어요.

또한 젊은 사용자들을 타겟으로 하여 세련되고 직관적인 인터페이스를 제작했어요.

ㅤ

Interview 02. 사용자 기반 개선과 초기 데이터 수집 과정

UT를 진행했던 와이어프레임 화면과 런칭 이후의 화면 스타일 많이 바뀌었다고 들었는데요.
그 사이 어떤 개선 과정들이 있었는지 궁금합니다!

이윤선(디자인)

UT(사용성 테스트, Usability Test)를 통해 유저들이 궁극적으로 저희 서비스를 찾는 이유는 ‘시야 확인’이라는 점이 명확해졌고, 이에 맞춰 화면을 전면적으로 개편했어요.

메인 페이지의 수많은 정보를 덜어내고 야구장 정보에 초점을 맞추어 UI의 위계를 정리했어요.
또한 게시물 등록과 관련해 레벨업 시스템을 도입하면서 캐릭터 디자인을 추가하게 되었고, 더 재미있고 직관적인 사용자 경험을 제공할 수 있었어요.

개발 초기의 등록 플로우는 정보를 입력한 후 바로 공유를 유도하는 방식으로 설계했어요.
뎁스가 길면 사용자가 이탈할 것이라 생각했거든요.

하지만 UT 결과, 이 방식이 오히려 사용자들에게 혼란을 준다는 피드백을 받았어요.

작은 넛지(Nudge) 창에 많은 정보를 담다 보니 사용자는 ‘왜 공유해야 하는지’에 대한 맥락을 이해하지 못했어요.
“이미 올린 사진을 왜 다시 선택해야 하지?”라는 혼란을 느꼈어요.
더불어, 사용자는 등록 완료를 기대했으나 추가 작업으로 이어지면서 VOC(Voice of Customer)에서 혼란스럽다는 의견이 많았어요.

이를 통해 ‘뎁스 축소보다 명확한 인지가 중요하다’는 인사이트를 얻었고, 플로우를 수정했어요.

등록을 완료한 후, 바텀시트 형태의 넛지로 ‘간단한 액션만으로 공유할 수 있다’는 메시지를 전달하며, 공유를 유도하는 방식으로 변경했어요.

핵심 목표가 명확히 정해진 덕분에 개선 과정이 한층 더 명확해졌네요. 정말 인상적입니다!
SPOT!팀은 출시를 일찍 하기도 했었고, 사용자들을 어떻게 모을지에 대해 많은 고민이 있었을 것 같아요.
어떤 노력들이 있었나요?

이윤선(디자인)

저희 서비스는 유저 참여가 핵심이었기 때문에 사용자들을 어떻게 모을지 고민이 많았어요.

다행히 팀원 중에 과거 사이드 프로젝트로 iOS와 안드로이드를 합산해 약 3만 명의 유저를 확보했던 경험이 있는 분이 있었는데요.
그분의 조언으로 ‘스레드(Threads)’라는 인스타그램의 자매 플랫폼이 블루오션이라는 이야기를 들었고, 거기서 홍보를 시작했습니다.

스레드는 일반 SNS보다 더 친근하고 캐주얼한 분위기가 특징인데요.
예를 들어, 스레드 내에서는 ‘인친’(인스타 친구)처럼 ‘스친’(스레드 친구)이라는 용어를 쓰며 반말로 편하게 소통하더라고요.
저희는 그 분위기를 활용해 SPOT!을 자연스럽게 홍보했어요.

홍보 이후, 스친 분들이 남겨주신 VOC(Voice of Customer)가 정말 인상 깊었어요.
어떤 분은 “뻥 안 치고 시야 사진 100장 있는데 사직구장 빨리 열어라, 내 시야 정보 올려 줄게!” 같은 적극적인 표현을 써서 참여 의사를 보여주셨죠. 😆

이런 유저들의 반응이 정말 즐거웠고, 저희가 서비스를 알리는 데에 큰 도움이 되었어요.

SPOT!은 데이터와 콘텐츠를 기반으로 운영되는 서비스인데, 어떻게 초기 데이터를 어떻게 확보하셨나요?

조관희(안드로이드)

저희는 야구장 시야 제공 서비스인 만큼, 초기 데이터 수집이 정말 중요한 과제였어요.
이를 위해 체계적으로 역할을 분담했어요.

서버 개발자는 데이터베이스 작업을 맡고, 나머지 팀원들은 직접 야구장 시야 데이터를 수집하는 역할을 했어요.
구역이 겹치지 않도록 담당 구역을 배정하고, 하루에 5개씩 데이터를 모으기로 약속했어요.

슬랙에 리마인더를 설정해서 수집 여부를 확인하고, 네이버 블로그에서 시야 정보를 찾은 뒤, 작성자 분께 댓글로 사용 허락을 요청했어요.
이후, 수집한 데이터를 엑셀 시트로 관리하면서, 진행 상황을 체크리스트로 정리했습니다.

특히 놀라웠던 점은 네이버 블로거분들이 정말 친절해서 큰 힘이 되었어요.
응원 메시지를 남겨주시거나 사용 허락을 긍정적으로 해주신 덕분에, 서비스를 개발하며 감동도 많이 받았던 것 같아요.

직접 발로 뛰면서 데이터를 모으셨군요.
디프만이라는 3개월이라는 시간이 길다면 길지만, 짧다면 정말 짧은 시간인데,
그 안에 이렇게 데이터를 한 땀 한 땀 모아서 성과를 냈다는 점이 정말 대단하다고 생각합니다.👍

ㅤ

Interview 03. 서로의 강점을 살린 SPOT! 팀의 프로젝트 운영 방식

완성도 높은 프로덕트를 만들어낸 팀인 만큼,
각 파트 별로 작업을 어떻게 분배 했는지 궁금합니다.

조관희(안드로이드)

저희는 사이드 프로젝트인 만큼, 각자가 얻어가야되는 것이 있어야하잖아요.
그래서 하고 싶은 작업을 중심으로 화면을 분배했어요.

초기 디벨롭 단계에서 와이어프레임이 나오면 자연스럽게 자신이 개발하고 싶은 화면과 사용해보고 싶은 기능이 떠오르잖아요.
그래서 각자 원하는 화면을 먼저 물어봤는데 다행히도 겹치지 않았어요.

결과적으로 회원가입, 시야 확인, 시야 아카이빙, 시야 후기 등록이라는 네 가지 주요 화면을 각자 담당해 작업했어요.

정준원(서버)

저희 팀의 특이한 점은 제가 팀장이었지만, 사실 기술적으로는 더 뛰어난 팀원이 있었다는 점이에요.

작업 분배 시에는 저희도 안드로이드 파트처럼 원하는 작업을 중심으로 분배해서 작업을 진행했어요.

파트원들끼리도 지속적으로 의사소통을 하면서 자신의 작업이 완료되면 다른 팀원의 작업을 도와주는 등 팀워크가 좋았어요.

실제로 마감 기한이 임박했을 때, 아픈 팀원이 생겼을 때 서로 도와주려고 했었어요.

이윤선(디자인)

저희 디자인 파트는 모두 직장인이다 보니 시간이 없어서 최대한 효율적으로 진행하려고 했어요.
회의는 간결하게 끝내고, 마감일을 정확히 설정해 각자 맡은 부분을 완료하려 노력했어요.

메인 플로우를 세 가지로 나누어 각자 파트에 집중할 수 있도록 구성하고, 캐릭터 디자인이나 비헨스 관련 작업은 각자의 강점을 살려 분배했어요.

플로우와 초안을 설계한 이후에도 서로에게 공감을 얻지 못한 디자인은 보다 나은 사용성을 위해 더 자주 논의했어요.

예를 들어, 등록 과정에서는 유저에게 더 직관적이고 쉬운 방법을 전달하려고 30분씩 각자 시간을 가진 후 아이데이션을 하고 공유하며 최적의 방안을 찾으려고 노력했어요.

세 분 다 직장인이셨군요. 엄청 힘드셨을 것같은데..
그럼에도 불구하고 모두가 최선을 다한 모습이 정말 멋있습니다.
저희 팀 디자이너분들도 새벽까지 작업하는 모습이 일상이었는데 디자이너분들은 모두 열정적이신 것 같아요. 정말 리스펙합니다! 🔥
관희님께서는 클라이언트 개발자로서 서버와 디자인 팀 간의 소통을 어떻게 조율하셨나요?

조관희(안드로이드)

소통을 원활히 하기 위해 저희는 슬랙(Slack)의 스레드를 적극적으로 활용했어요.
슬랙은 모든 파트간 대화가 공유되기 때문에 모든 의사소통을 투명하게 확인할 수 있었죠.

서버 개발자와 안드로이드 개발자는 지라(JIRA)를 활용해 진행 중인 티켓을 확인하고 작업 상태를 점검했으며, API 명세서는 노션에서 관리하고 확인했어요.

QA를 진행할 때는 개발자와 디자이너 간의 소통을 위해 피그마에서 멘션을 통해 작업 완료 여부를 확인하는 방식이 효과적이었어요.
간단한 뷰 작업은 디자이너에게 개인 톡으로 피드백을 받아 빠른 소통으로 문제를 해결하려고 노력했어요.

협업을 진행하면서 겪은 문제 중 가장 기억에 남는 경험이 있나요?

조관희(안드로이드)

제가 진행하면서 겪었던 문제 중 하나는 잘못된 정보를 전달했던 경험이 있었어요. 프로젝트 특성상 많은 정보를 공유하다 보니, 개인 일정으로 빠진 팀원들에게 잘못된 정보를 전달하게 되었고, 이로 인해 서로의 이해가 엇갈려 의견 충돌이 발생했어요.

이를 해결하기 위해 논의했던 내용을 정확히 문서화하는 데 집중했어요. 잘못된 정보가 다시 전달되지 않도록 노력했고, 회의 중 이해되지 않는 부분은 질의응답을 통해 해결했어요.

이러한 과정을 통해 팀원들 간의 생각이 다를 수 있다는 점을 배웠고, 이를 하나로 통합하는 것이 프로젝트 성공에 얼마나 중요한지 깨달았어요.
또한, 문서화가 논의 내용을 복기할 때 얼마나 중요한지도 다시 한 번 느끼게 되었어요.

정말 중요한 교훈을 얻으셨네요.
디프만에서의 협업이 주는 가치가 참 큰 것 같아요.
혹시 이번 프로젝트에서 좋았던 협업 경험도 하나 들어볼 수 있을까요?

이윤선(디자인)

저는 개인적으로 QA 과정에서 안드로이드와 서버 개발자분들께 많은 도움을 받은 경험이 떠오르네요.

특히 안드로이드 개발자분들께 정말 감사했어요.
저희 디자인 팀은 꼼꼼한 성격이라 피그마에 세세하게 장표를 늘려가며 "이 부분은 이렇게 동작해야 한다"거나, "바텀 시트는 이 정도까지 올라와야 한다"며 하나하나 꼼꼼히 요구 사항을 정리했거든요.

그 과정에서 안드로이드 개발자분들이 새벽까지 해커톤을 같이 진행하면서 잠도 못 자며 디자이너들의 요구사항을 최대한 수용하려고 열심히 작업하시는 모습을 보고 정말 감동받았어요.

해커톤이 끝난 뒤 집에 가면서 “이 프로젝트에 나만 진심이 아니었구나”라는 생각에 혼자 뿌듯했던 기억이 납니다.😇

팀 프로젝트에서 서로의 노력이 보일 때 정말 뿌듯한 것 같아요.
추가로 팀 활동을 하며 기억에 남는 에피소드가 있다면 소개해주세요.

조관희(안드로이드)

저희가 런칭 데이 이후에 마지막 뒤풀이를 했었는데, 그때 정말 재밌는 일이 있었어요.
술도 좀 마시고 분위기가 한창 무르익었을 때, 팀장님이 창문을 바라보시더니 “너는 어디 회사가 어울린다”며 각 팀원에게 어울리는 회사를 하나씩 이야기해 주셨어요. 🌃🍻

예를 들어, “너는 00기업이 딱이다” 또는 “너는 은행권이 잘 맞을 것 같아” 이런 식으로 말씀해 주셨는데, 듣다 보니 정말 내가 그 회사에 갈 것 같고 상상이 되더라고요.
그 순간이 정말 유쾌하고 기억에 많이 남아요.

이런 소소한 에피소드들이 팀 활동의 즐거움을 더해준 것 같아요.

ㅤ

Interview 04. 개발 과정에서 맞닥뜨린 어려움과 도전

서비스를 실제로 배포하고 운영하면서 예상치 못한 문제들도 많았을 것 같은데,
개발 혹은 운영 과정에서 어떤 어려움을 겪었나요?

조관희(안드로이드)

안드로이드 팀에서는 야구장 화면 구현이 큰 도전이었어요.
네이티브로 구현하려니 한계가 있다고 판단해서, 다른 방식으로 접근해야 하나 고민도 했었죠.

하지만 개인적으로 이 화면만큼은 꼭 구현하고 싶어서 레퍼런스를 조사하고, 교내 동아리에서 웹 프론트엔드 개발자분들께 도움을 요청했어요.

그 과정에서 SVG clickable map이라는 개념을 알게 되었고, 디자이너분들이 만든 잠실 야구장 화면을 서버에서 URL로 받아와 웹뷰로 보여주는 방식으로 구현하게 되었어요.

디자이너분들이 한 땀 한 땀 각 컴포넌트들을 만들어준 덕분에 가능했던 일이기에, 이 영광은 디자이너분들에게 돌리고 싶습니다.

정준원(서버)

서버 팀은 저를 포함 대학생 팀원 2명이 실제로 운영되는 서비스를 처음 개발해 본 터라 어려움이 많았어요.
특히 의존성 역전과 계층 분리 같은 개념은 이론적으로는 알았지만, 실제 경험이 부족했죠.

NCP에서 AWS로의 마이그레이션을 진행하며, 계층 분리와 의존성 관리의 중요성을 크게 느꼈어요.
이런 구조가 없었다면 NCP 코드를 모두 새로 작성해야 했겠지만, 인프라 계층만 수정해 해결할 수 있었거든요.

또한, 데이터 트래킹에 대해 처음 배우고 적용하면서 사용자 행동 데이터를 분석할 수 있었습니다.
예를 들어, 특정 API 호출이 많거나 연관된 흐름을 확인하며 사용자의 경험을 간접적으로 이해할 수 있었어요.

SPOT!팀 경우에는 사용자에 대한 반응을 가장 많이 받은 팀이라고 생각을 하는데요.
사용자의 반응에 따라 기능이 바뀌거나 예상하지 못했던 문제를 해결했던 경험이 궁금합니다.

정준원(서버)

서버 개발에서는 초기 설계와 크게 다른 요구사항이 들어와 변경했던 경험이 있어요.

처음에는 다른 도메인 정보를 가져와 비즈니스 로직을 적용해 새로운 Response를 생성하려 했어요.
하지만 이런 방식은 의존성이 생겨, 변경 사항이 생기면 다른 도메인의 기능까지 수정해야 하는 문제가 있었어요.

논의 끝에 “이 작업이 꼭 동기화되어야 할 필요가 있는가?”라는 질문이 나왔고, 이를 비동기 처리로 변경했어요.
화면 하나에서 API 하나를 사용해야 된다라는 틀을 깨고 여러 API로 분리해 각 도메인 단위로 데이터를 가져오게 하고, 프론트엔드에서 필요한 데이터를 비동기적으로 처리할 수 있게 했어요.

이렇게 구조를 변경하면서 유연성과 유지보수성이 크게 개선된 경험이 기억에 남아요.

미리 설계를 고려해 변경 가능성에 대응한 점이 정말 인상적이네요.
각 파트가 사용자 피드백을 잘 반영하며 유연하게 대응했던 경험이 돋보이는 것 같습니다.
이 밖에도 기술적으로 도전한 새로운 시도가 있었다면 소개해 주세요!

정준원(서버)

보통 데이터 트래킹은 프론트엔드에서 이벤트 관리를 통해 진행하는 경우가 많지만, 프론트에서 API 조회 없이 알기 어려워요.
직접 데이터베이스에 저장하고 분석할 수도 있었지만, 그러려면 어드민 페이지가 필요했고, 이 경우 웹으로 개발해야 하니 공수가 과도하다고 판단했어요.

그래서 저희는 이미 존재하는 데이터 분석 툴인 Mixpanel과 GA(Google Analytics)의 이벤트 트래킹 기능을 활용했어요.
특정 API가 호출되거나 비즈니스 로직이 실행될 때, 비동기로 이벤트를 발생시켜 데이터가 어떻게 흘러가는지 추적할 수 있었어요.

서버 개발자와 프론트엔드 팀 모두의 부담을 줄이면서도 효율적으로 데이터를 활용할 수 있었던 좋은 시도였다고 생각해요.

ㅤ

Interview 05. 이런 분들에게 디프만을 추천합니다!

디프만 활동을 하며 ‘이거 하나는 얻어간다’라고 생각되는 것이 있다면 무엇인가요?

조관희(안드로이드)

‘성장하고 싶다면 디프만을 시작해라!’ 라고 자신있게 말하고 싶어요.

디프만에 대학생으로 참여하면서 처음으로 현직자와 협업할 기회를 가졌고, 그 과정에서 소프트 스킬과 하드 스킬 모두 배울 수 있었어요.

프로젝트 외에도 기업 대표님의 강연과 대기업에 재직 중이신 선배님들과의 커피챗을 통해 앞으로 더 성장하고자 하는 동기부여를 얻었어요.

이윤선(디자인)

IT 동아리에서 새로운 도전을 하고 싶은 디자이너라면, 디프만을 최종 관문으로 삼는 것이 좋다고 생각해요.

저는 이전 인터뷰에도 얘기하긴 했었지만 디프만이 저의 4번째 IT동아리 활동이었는데요.

디프만 활동은 서비스 운영 경험을 쌓기에도 적합하고 루즈해지지 않을 정도의 적당한 활동 기간을 가지고 있다고 생각해요.
디자이너 입장에서 비핸스로 아웃풋을 정리해볼 수 있는 세션이 있는 등 체계적인 시스템이 마련되어 크게 성장할 수 있는 원동력이 되었어요.

정준원(서버)

모든 것을 얻었다고 해도 과언이 아닐 것 같아요.

저와 같은 취준생들끼리 모여 요즘 이력서를 어떻게 작성하고 포트폴리오는 어떻게 준비하는지, 목표 기업을 위해 어떤 준비를 해야 하는지에 대해 나눌 수 있어 매우 유익했어요.

또 원래 단순하게만 알고 있던 지식을 확장시킬 수 있는 계기가 되었어요.
이번 기회를 통해 열정 있는 개발자, 디자이너들과 교류하며 기술적으로 크게 성장할 수 있었어요.
실제 운영 환경에서 모니터링이나 데이터 트래킹을 구축하는 것은 디프만에 참여하지 않았다면 알지 못했을 거예요.

덕분에 정말 좋은 경험을 했고 이러한 경험들은 면접에서도 이야기할 수 있는 좋은 사례가 되었어요.