같은 공연을 함께 즐길 동행 찾기 서비스, 루프(Loop)의 여정

좋아하는 아티스트의 공연, 혼자 가기는 아쉽고 동행을 구하자니 상대가 어떤 사람일지 몰라 망설여집니다.

루프 팀은 이 익숙한 망설임에서 하나의 질문을 던졌습니다.

"동행을 구하기 전에, 상대가 어떤 사람인지 먼저 알 수 있다면 어떨까?"

PM, 디자이너, 개발자 5명이 모인 루프 팀은 6주 동안 단 한 번의 오프라인 만남을 제외하고 100% 비대면으로 협업하며 문제 정의부터 기획, 디자인, 개발, 배포까지 서비스 제작의 전 과정을 함께했습니다.

좋아하는 아티스트와 관람 스타일, 해시태그까지 담은 프로필로 나와 잘 맞는 동행을 찾을 수 있도록 했고, KOPIS API를 연동한 J-POP 공연 자동 업데이트와 채팅 리마인드 메일까지 더해 MVP를 넘어 꾸준히 운영할 수 있는 서비스를 만들었습니다.

'프로필로 찾는 공연 동행'을 서비스로 만들기까지, 루프 팀은 어떤 고민과 과정들을 거쳐왔을까요?

루프(Loop) 팀의 이야기를 들어보았습니다.

1️⃣ 팀 소개

Q. 반갑습니다. 팀 소개 부탁드려요!

A. 안녕하세요! 저희는 스위프 웹 14기에 참여한 2팀입니다.

PM 문정연, 디자이너 김소정, 프론트 엔지니어 김수진, 백엔드 엔지니어 배수환, 추동원 총 5명이서 함께 프로필 기반 동행 찾기 서비스를 만들었습니다.

👉 루프 바로가기

🫶 루프에게 피드백이 있다면 부탁드려요! 피드백 주러 가기

Q. 어떤 문제를 해결하기 위해 시작된 서비스인가요?

A. 프로필 기반 공연 동행 찾기 서비스 '루프(Loop)'는 공연 동행을 찾을 때 상대에 대해 충분히 파악할 수 없는 문제를 해결하기 위해 탄생했습니다. 보통 공연 동행은 해당 아티스트의 오픈채팅방이나 '페스티벌 라이프'라는 플랫폼의 동행 게시판에서 찾을 수 있는데요, PM인 저도 J-POP 공연을 많이 가지만 혼자 다니기 심심해서 직접 동행을 찾아보려 했지만 상대가 어떤 사람일지 모르니 결국 포기하게 되더라고요.

다른 사람들도 똑같이 느꼈을지 검증하기 위해 실제로 동행을 구해본 적 있는 사람들을 인터뷰했을 때, 실제로 동행을 구하기 꺼려지는 이유 1위는 '상대가 어떤 사람인지 알기 어렵다'는 것이었습니다. 또한 성별/연령 같은 인적 사항보다는 오히려 음악 취향, 관람 스타일 등 '나와 같은 방식으로 공연을 즐기는 사람인가'가 훨씬 중요했습니다.

여기서 저희는 기회를 포착했습니다. 동행을 구하는 사람들이 각자 성별, 연령, 좋아하는 아티스트, 해시태그 등이 모두 포함된 프로필을 작성하도록 한다면 공연 동행을 구하는 것에 대한 장벽을 허물고, 결과적으로 나와 잘 맞는 사람을 찾을 수 있을 것이라는 가설을 세웠고, 이것이 루프의 출발점이 되었습니다.

Q. 아이디어를 떠올리게 된 계기나 배경이 있었나요?

A. 루프(Loop)는 PM 문정연님의 아이디어로 시작되었습니다.

우선 PM인 제가 2~3년에 걸쳐 직접 느꼈던 불편함을 해결하기 위해 '공연 동행 찾기' 서비스를 고안하게 되었습니다. 하지만 '프로필'을 기반으로 동행을 찾는다는 아이디어가 나오기까지는 다소 시행착오가 있었습니다.

처음에는 유저가 원하는 조건(음악 취향, MBTI, 성별, 연령 등)에 따라 가장 적합한 동행을 자동 매칭해 주는 방식을 생각했었습니다. 하지만 기술적으로 구현이 복잡하기도 하고, 무엇보다 그 동행이 마음에 들지 않았을 때 서비스에 대한 신뢰도가 크게 하락하는 문제가 있었습니다.

그래서 처음에는 게시글을 업로드하는 형태로 기획해서 팀원들에게 공유했습니다. 하지만 기존에 동행을 구하는 방식과 차별점이 부족한 것 같다라는 피드백을 듣고 정곡을 찔렸습니다. 제가 봐도 별 차별성이 없어 보였기 때문입니다. 그때부터 이틀간 머리를 싸매면서 사람들이 동행에게 원하는 정보가 무엇인지를 생각하기 시작했고, 동행 조건보다 '동행하는 사람 그 자체'가 중요하다는 깨달음을 얻어 지금의 서비스를 만들게 되었습니다.

2️⃣ 프로젝트 과정

Q. 팀 협업은 어떤 방식으로 진행되었나요?

👤기획 :

저희 팀은 최초 1회를 제외하고는 100% 비대면으로 협업을 진행했습니다. 경기도 성남시부터 전라도 광주시까지 서로 거주지가 너무 멀어 어쩔 수 없는 상황이었는데요, 그만큼 긴밀한 협업 체계를 구축했다고 생각합니다. 무엇보다 저희 팀원분들께서 연락을 정말 빠르게 확인해 주시고, 궁금한 점을 여쭤보면 바로 답변을 주셔서 온라인 소통의 답답함이 거의 없었던 것 같습니다.

주로 사용했던 툴은 피그마와 노션입니다. 저는 PM으로서 기획 내용을 기능 명세서, IA, 유저 플로우 등의 형식으로 정리해서 전달드렸고, 개발자분께서 개발을 진행하시면서 의문이 생기는 부분을 바로 질문해 주셨습니다. 저는 거기에 답을 하며 엉켰던 실을 풀기도 하고, 놓쳤던 부분을 새롭게 생각하기도 했습니다. 이렇게 발전되거나 수정된 사항은 즉시 각종 기획 문서에 적용해서 팀원들끼리 정보를 맞출 수 있도록 했습니다.

디자이너분과는 피그마를 통해 와이어프레임을 기획하며 가장 집중해서 협업을 진행했습니다. 먼저 제가 서비스를 기획하면서 머릿속에 그렸던 화면을 Claude Design으로 먼저 구현해서 피그마에 옮기고, 이를 바탕으로 디자이너분과 피그마상에서 실시간으로 소통하며 발전시켰습니다.

👤프론트엔드 :

저희 팀은 프로젝트 초반에 그라운드 룰을 명확히 세우고 시작했어요. 기본 소통은 디스코드로, 회의록은 노션에, 디자인은 피그마, API 문서는 Swagger로 각 영역별 툴을 정해두고 협업했습니다.

특히 디스코드 채널을 주제별로 세분화해서 사용한 게 도움이 많이 됐어요. 채팅 채널은 일반·진행상황·잡담으로 나누고, 개발 채널은 개발-기획·백-프론트·백엔드-채팅·백엔드-자료실·백엔드-웹훅·신고-알림·문의-알림까지 목적별로 쪼개서 운영했고, 디자이너 파트도 자료실과 채팅 채널을 분리하고, 기획 파트 역시 변경사항과 자료실 채널을 따로 두었습니다. 이렇게 채널을 세분화해 두니 필요한 정보를 빠르게 찾을 수 있었고, 서로 다른 직군의 논의에 불필요하게 휩쓸리지 않으면서도 필요할 땐 바로 참고할 수 있어서 효율적이었어요.

정기 팀 미팅은 매주 월요일 오후 8시에 진행했고, 아무리 사소한 것이라도 진행 상황이나 질문사항을 채널에 남기는 걸 팀 문화로 삼았습니다. 메시지를 확인하면 체크 표시를 남기고, 디스코드는 상시로 확인하며, 꼭 알려야 할 내용은 멘션을 활용하는 규칙도 있었어요. 이런 장치들 덕분에 온라인 협업임에도 서로의 상황을 놓치지 않고 진행할 수 있었습니다.

Q. 팀원들과 협업하는 과정에서 기억에 남는 순간이 있었나요?

👤기획 :

1차 기획 후에 개발이 진행되면서 수정되었던 부분이 꽤 많았는데요, 그때마다 개발자분들께 죄송하다는 마음이 많이 들었습니다. 하지만 새로운 아이디어가 생기면 일단 던져보았고, 모두 너그럽게 받아주시는 동시에 가능 여부를 합리적으로 판단해 주셔서 기획자로서 매우 든든했습니다. 이렇게 저에게 생각할 기회와 시간을 주셔서 결과적으로 완성도 높은 프로덕트를 만들 수 있었다고 생각합니다.

저에게는 디자이너 소정님과 함께 와이어프레임을 작업했을 때가 이번 프로젝트에서 가장 재미있었던 순간 중 하나입니다. 머릿속으로만 그렸던 서비스가 실제로 탄생하는 것을 지켜보는 것이 흥미롭기도 했고, 소정님과 텍스트로 소통했음에도 불구하고 서로 배려하되 솔직하게 의견을 주고받았다는 점에서 꽤 훌륭한 협업 경험이었다고 생각합니다.

👤프론트엔드 :

가장 기억에 남는 건 빠듯한 일정에도 불구하고 팀원들이 각자 맡은 일을 묵묵히, 성실하게 해내 줬다는 점이에요. 화려하게 드러나는 순간은 아니었지만, 그런 태도가 하나하나 쌓여서 결국 좋은 서비스로 완성될 수 있었다고 생각해요.

소통 방식에서도 인상 깊었던 순간이 있는데요, 주로 디스코드로 소통했지만 피그마로 작업하다가 우연히 같은 시간대에 다른 팀원이 접속해 있으면 피그마 채팅 기능으로 바로바로 의견을 주고받았던 게 기억에 남아요. 정해진 채널이 아니어도 필요한 순간에 자연스럽게 소통이 이루어졌다는 게 팀워크가 잘 맞았다는 걸 보여주는 것 같아요.

그리고 팀원들 모두 서로를 향한 배려가 컸어요. 상대방이 꼭 확인해야 할 내용은 멘션으로 알려주면서도, 너무 늦은 시간에 메시지를 보낼 때는 일부러 멘션을 달지 않고 조용히 남겨두는 식으로 서로의 시간을 존중해 줬어요. 의견을 나눌 때도 주장만 하기보다 근거를 함께 제시하면서 이야기하는 분위기였고요. 이런 작은 배려와 존중들이 쌓여서 갈등 없이 편안한 팀 분위기가 유지될 수 있었던 것 같습니다.

Q. 프로젝트를 진행하면서 가장 어려웠던 순간은 무엇이었고, 어떻게 극복하셨나요?

👤디자인 :

유저 리서치에서 얻은 인사이트를 실제 디자인에 어떻게 녹여낼지가 가장 어려웠습니다. 동행을 찾는 플랫폼이다 보니 사용자가 동행을 선택할 때 중요하게 생각하는 정보가 많았고, 이를 프로필 카드 안에서 어떤 우선순위로 보여줄지 고민을 많이 했습니다.

특히 많은 정보를 담으려고 하다 보니 카드의 가독성이 떨어지는 문제가 생겼습니다. 이를 해결하기 위해 정보의 우선순위를 다시 정리하고 여러 레이아웃을 시도했으며, AI를 활용해 다양한 디자인 시안을 빠르게 만들어 비교하는 방식도 활용했습니다. 이를 통해 제한된 카드 영역 안에서 필요한 정보는 충분히 전달하면서도, 한눈에 내용을 파악할 수 있는 방향으로 디자인을 구체화할 수 있었습니다.

👤백엔드 :

기능을 구현하는 것보다 프로젝트가 진행된 이후 기존 구조를 수정하고 개선하는 과정이 어려웠습니다.

특히 채팅 기능에서 탈퇴 사용자를 처리하는 과정이 가장 기억에 남습니다.

처음에는 단순 삭제 방식으로 접근했지만, 개발이 진행되면서 대화 기록 보존과 상대방의 사용자 경험까지 고려해야 했고, 기존에 만들어진 참여자 구조와 로직을 함께 수정해야 했습니다.

최종적으로는 데이터를 삭제하지 않고 상태 기반으로 관리하여 탈퇴한 사용자에게는 채팅방이 보이지 않도록 하고, 상대방에게는 기존 대화 기록이 유지되도록 변경했습니다.

이 경험을 통해 프로젝트 후반에 기존 구조를 변경하는 것은 생각보다 많은 부분에 영향을 줄 수 있다는 것을 알게 되었고, 초기 설계와 함께 향후 변경 가능성까지 고려하는 것이 중요하다는 것을 배울 수 있었습니다.

Q. 각 직군별로 가장 도전적이었던 부분이나 성장 포인트는 무엇이었나요?

✔ 기획 & 디자인

👤기획 :

서비스 기획이 처음이었던 저에게는 모든 것이 도전이었지만, 동행 프로필에 어떤 내용을 넣을 것인지, 각 내용의 입력 시점을 어떻게 할지 고민하는 것이 가장 어려웠던 것 같습니다.

루프의 프로필에는 성별, 연령, 프로필 이미지, 닉네임, 좋아하는 아티스트, 해시태그, 동행과 함께하고 싶은 것, 관람 스타일, 자기소개 등 매우 많은 요소가 포함됩니다. 처음에는 이를 모두 한 페이지에서 입력하도록 했지만 페이지가 매우 길어지면서 유저의 이탈이 우려되더라고요. 그래서 일부 내용을 온보딩으로 빼보았지만, 이 경우에는 상대의 프로필을 확인하기도 전에 내 정보를 입력해야 한다는 번거로움을 유발한다는 점을 깨달았습니다.

그래서 절충안으로 찾은 것이, 프로필 내용을 온보딩에서 입력하는 '기본 프로필'과 프로필 작성 시 입력하는 '동행 프로필'로 구분하되, 온보딩 입력은 선택 사항으로 두는 것이었습니다. 이 경우 온보딩에서 유저가 느끼는 부담은 줄면서, 프로필 작성 시 2가지 프로필의 구역이 나뉘며 페이지 전체 내용이 이전보다 적게 느껴지는 효과가 있습니다.

👤디자인 :

가장 도전적이었던 부분은 사용자가 동행을 편하게 둘러볼 수 있는 플로우를 만들면서, 기획 의도와 사용성 사이의 균형을 맞추는 것이었습니다.

초반에는 온보딩 → 공연 선택 → 동행 프로필 작성 순서로 플로우를 기획했는데, 프로토타입을 직접 사용해 보니 사용자가 동행 프로필을 둘러보기까지 거쳐야 하는 단계가 길다고 느껴졌습니다.

기획자님과 플로우를 함께 검토하면서 처음 기획했던 방향을 유지할지, 사용자의 진입 장벽을 낮추는 방향으로 수정할지 고민하는 과정이 있었습니다. 저는 실제 프로토타입을 사용하면서 느낀 점과 '사용자가 처음부터 동행을 둘러볼 수 있어야 한다'는 관점에서 개선 의견을 제안했고, 논의를 통해 기존 플로우를 수정하게 되었습니다.

이 과정을 통해 각 포지션의 의견을 단순히 맞추는 것보다, 사용자의 입장에서 왜 이 방향이 필요한지를 근거로 이야기하는 것이 중요하다는 것을 배웠습니다.

✔ 개발

👤프론트엔드 :

프론트엔드로서 가장 도전적이었던 건 모바일 웹뷰에서 키보드가 열릴 때 레이아웃이 깨지는 문제였습니다. 채팅방과 온보딩 화면 모두 하단 입력창/버튼을 fixed로 고정해 뒀는데, iOS/Android에서 키보드가 뜨면 이 요소들이 밀리거나 화면 밖으로 사라지는 증상이 반복됐습니다. 표준 스펙은 하나인데 브라우저·웹뷰마다 구현이 달라서, 시도할 때마다 다른 화면·다른 조건에서 재발했습니다.

100vh를 dvh로 바꾸고 메타 태그를 추가하는 방법, visualViewport로 높이를 구독하는 방법, fixed를 아예 걷어내는 방법까지 순서대로 시도했지만 매번 다른 조건에서 증상이 재발했습니다. 원인을 좁혀가다 관련 기술 블로그를 참고해, position: fixed로 고정한 것 자체는 문제가 없고, 키보드가 뜰 때 iOS/Android가 만드는 "가상 스크롤 영역" 때문에 fixed 요소가 실제로는 밀려 보이는 것이라는 걸 확인했습니다. fixed가 적용되지 않은 것이 아니라, 적용되지 않은 것처럼 보이는 것이었습니다.

이 원리를 바탕으로 window.scroll / visualViewport.scroll 이벤트를 듣고 offsetTop·pageTop 차이만큼 translateY로 되돌리는 useKeyboardScrollOffset 훅을 만들어 ChatRoom과 OnboardingFlow에 공통 적용했고, 화면마다 흩어져 있던 임시방편들을 이 하나의 훅으로 정리했습니다. 실제 구현은 Claude Code를 활용해 빠르게 진행했지만, 원인을 정확히 진단하고 검증하는 과정은 직접 수행했습니다.

이 경험으로, 증상 대응이 아니라 근본 원인을 정확히 진단하는 게 먼저라는 것과, AI 도구를 쓰더라도 문제의 원리를 스스로 이해하고 있어야 정확한 지시와 검증이 가능하다는 걸 다시 느꼈습니다.

👤백엔드 :

가장 도전적이었던 부분은 기존에 익숙하지 않았던 기술과 기능을 실제 서비스에 적용하는 과정이었습니다.

특히 인증 및 인가, 실시간 채팅과 같이 여러 기술이 함께 동작해야 하는 기능을 구현하면서 단순히 기능을 완성하는 것뿐만 아니라 보안과 데이터 흐름까지 함께 고려해야 했습니다.

예상하지 못한 문제들이 발생할 때마다 원인을 찾아보고 설계를 수정하는 과정을 반복하면서 문제 해결 능력을 키울 수 있었습니다.

Q. 스위프를 경험하면서 가장 도움이 되었다고 느낀 부분은 무엇인가요?

👤백엔드 :

다른 직군과 협업을 직접적으로 경험해 볼 수 있다는 점이라고 생각합니다. 학교에서도 물론 팀 프로젝트같이 각자 역할을 나누어 진행하는 경험을 해본 적은 있지만, 직군을 완전히 나누어 협업해 보는 것이 이번이 처음이었고, 이 과정에서 다른 직군의 요구사항을 이해하고 제가 개발적으로 보완해야 할 점을 명확히 파악해 가는 좋은 경험을 해볼 수 있었습니다.

또한, 짧은 기간 내에 MVP를 완성하는 목표 덕분에 처음 사용해 본 k6, Redis와 같은 것들에 대해 빠르게 적용하고 실무에 바로 적용해 보면서 역량 향상에 많은 도움이 되었다고 생각합니다.

👤기획 :

첫 번째로는 팀원을 빠르게 모집할 수 있다는 점이었습니다. PM의 입장으로서는 제 프로덕트에 함께할 사람을 찾기 위해 각종 커뮤니티에 게시글을 올리는 것이 매우 부담스럽게 느껴지는데, 스위프에서 단 15분 만에 함께할 분들을 찾을 수 있어 좋았습니다.

또한 데드라인이 명확한 점도 큰 도움이 되었습니다. 개인적으로 프로젝트를 진행했다면 이만큼 압축적으로 집중하여 프로덕트를 완성할 수 없었을 것이라고 생각합니다. 스위프 프로젝트에 참여 중이라는 사실, 다른 팀들과 경쟁하고 있다는 사실이 저와 저희 팀에게 꽤 큰 책임감을 부여해 주었습니다.

3️⃣ 수상 & 성과

Q. 수상 소식을 들었을 때 어떤 기분이었나요?

A. 수상 발표 전 자유롭게 서비스를 둘러보는 시간을 가질 때 타 서비스에 사람들이 몰리는 것을 보고, 저와 저희 팀원들은 해당 팀이 상을 받을 것이라고 생각했습니다. 그래서 우승팀이 발표되는 순간 저희 서비스명이 불렸을 때 다 함께 깜짝 놀랐던 기억이 있습니다.

특히 PM인 저는 프로덕트를 기획하면서도, 발표를 하면서도 팀을 대표해서 잘하고 싶다는 마음가짐이 항상 있었는데 목표를 이룰 수 있어서 매우 기뻤습니다. 그동안 팀원들과 함께 고생했던 것이 사르르 녹는 느낌이었습니다.

Q. 서비스에서 가장 자신 있는 ‘핵심 경험’은 무엇인가요?

A. 역시 동행 상대의 프로필을 확인할 수 있는 것이 핵심 차별점이라고 생각합니다.

이외에도 KOPIS라는 사이트와 API를 연동하여 J-POP 관련 공연이 자동 업데이트된다는 점, 채팅 미확인 시 리마인드 메일을 받을 수 있다는 점도 꼽을 수 있을 것 같습니다. 단순 MVP가 아닌 이후에도 지속적으로 운영할 수 있는 서비스를 만들기 위해 신경 쓴 부분이기 때문입니다.

Q. 실제 유저나 주변 사람들의 반응 중 기억에 남는 이야기가 있었나요?

A. 처음 수요 조사를 진행할 때 '동행 찾기'를 포함해 제가 구상한 다양한 기능에 대한 의견을 여쭈어보았는데, 이때 누군가 달아주셨던 '이런 거 해주셔서 감사합니다'라는 코멘트가 기억에 남습니다. 아주 담백한 코멘트이지만 저희가 기획 중인 서비스가 누군가에게 진심으로 도움이 될 수 있다는 점이 잘 느껴졌던 것 같습니다.

4️⃣ 배움과 성장

Q. 가장 성장했다고 느낀 부분은 무엇인가요?

👤디자인 :

팀원들과 함께 하나의 문제를 끝까지 붙잡고 해결해 나가는 끈기를 배웠습니다.

배포 직전까지도 작은 수정사항을 계속 발견하고 개선하는 과정이 있었는데, 다른 팀원분들도 마지막까지 적극적으로 아이디어를 제안하고 더 나은 방향을 고민해 주셨습니다. 팀원들의 적극적인 태도를 보면서 저 역시 '이 정도면 됐다'고 생각하기보다 끝까지 완성도를 높이려고 노력하게 되었습니다.

특히 혼자 완성도를 높이는 것보다 팀원들과 계속 의견을 주고받으며 함께 결과물을 발전시켜 나가는 과정을 경험하면서, 좋은 프로덕트는 한 번의 좋은 아이디어보다 끝까지 고민하고 개선하는 과정에서 만들어진다는 것을 배웠습니다.

👤백엔드 :

개발한 기능을 실제 서비스의 관점에서 바라보는 시야를 갖게 되었습니다.

프로젝트에서 AWS EC2, Docker, Nginx를 활용해 백엔드 서버를 배포했는데, 배포 후에는 인증 문제, 서버 로그 관리, 데이터베이스 설정, 컨테이너 환경 차이 등 개발 단계에서는 경험하지 못했던 이슈들을 마주하게 되었습니다.

또한 GitHub Actions를 활용해 CI/CD 환경을 구축하면서 단순히 기능을 개발하는 것을 넘어, 코드 변경 사항이 실제 서버에 반영되기까지의 전체 과정을 직접 경험할 수 있었습니다.

배포 과정에서 발생한 문제를 로그를 통해 분석하고, 설정을 수정한 뒤 다시 배포하며 검증하는 과정을 반복했고, 배포 자동화와 운영 효율성을 높이기 위한 배포 프로세스 개선과 최적화도 함께 진행할 수 있었습니다.

이를 통해 백엔드 개발은 기능 구현에서 끝나는 것이 아니라, 사용자가 안정적으로 서비스를 이용할 수 있도록 운영 환경까지 함께 고려해야 한다는 점을 배울 수 있었습니다.

Q. 프로젝트를 통해 새롭게 자신감을 얻은 부분이 있을까요?

👤프론트엔드 :

이전에는 AI 도구를 쓸 때 모든 작업에 동일한 강도의 프로세스(요구사항 분석 → 설계 → 계획)를 적용했다면, 이제는 작업의 규모와 성격에 따라 워크플로우 자체를 다르게 설계할 수 있게 되었습니다.

프로젝트 초반에는 사소한 버그 수정이나 스타일 조정에도 매번 브레인스토밍·설계 단계를 거치다 보니, 오히려 간단한 작업의 속도가 느려지는 비효율을 겪었습니다. 그래서 "새 기능/화면 단위 작업"과 "버그 수정·스타일 조정·소규모 리팩토링"을 구분해서, 후자는 무거운 설계 단계 없이 바로 처리하도록 프로젝트 규칙(CLAUDE.md)에 명시했습니다. 대신 새 기능처럼 영향 범위가 크고 되돌리기 어려운 작업에는 설계·계획 단계를 반드시 거치도록 남겨두었습니다.

이 경험으로, AI 도구를 얼마나 잘 쓰느냐는 결국 "이 작업이 신중한 설계가 필요한 일인지, 아니면 바로 처리해도 되는 일인지"를 스스로 판단하는 능력에 달려 있다는 걸 배웠습니다. 도구를 무조건 무겁게 쓰거나 가볍게 쓰는 게 아니라, 작업의 리스크와 규모에 맞게 프로세스 자체를 설계하는 게 실무에서 필요한 역량이라는 걸 느꼈습니다.

👤기획 :

팀원들과의 협업을 위한 문서를 작성하고, 전체적인 작업 로드맵을 그릴 수 있게 되었습니다. 프로젝트 시작 시에는 기능 명세서가 어떤 것인지도 모르는 상태였지만, 6주라는 시간 동안 팀원들과 함께 MVP 완성을 위해 달려 나가면서 서비스 기획에 대해 자연스럽게 습득하게 되었습니다.

프로젝트 시작 전에는 목적지를 발견하지 못하고 그냥 달리는 느낌이었다면, 지금은 목적지를 바라보면서 최적의 루트를 설계하는 힘이 생겼습니다.

5️⃣ 앞으로의 목표

Q. 앞으로 ‘루프’를 어떻게 이어가고 싶나요?

A. 처음부터 제가 만들고 싶었던 것은 J-POP 커뮤니티였습니다.

이를 만들기 위해 구체적으로 어떤 기능이 있으면 좋을지에 대한 설문조사를 스위프 프로젝트 이전에 진행했었고, 결과적으로 공연 정보 제공/온라인 커뮤니티/동행 찾기가 거론되었습니다.

이번 스위프 프로젝트 기간 동안은 이 중 가장 기술적으로 구현하기 어려운 '동행 찾기'를 구현하는 것을 목표로 했고 충분히 달성했다고 생각합니다. 프로젝트가 끝난 현시점, 공연 정보부터 추가하는 것으로 팀원들과 이야기를 마쳤습니다. 이를 기반으로 유저를 어느 정도 확보한 후 최종적으로 커뮤니티 기능을 덧붙이는 것으로 구상하고 있습니다.

Q. 스위프 이후, 새롭게 도전하고 싶은 목표가 있을까요?

👤백엔드 :

현재 가장 우선적인 목표는 빠른 시일 내에 취업하는 것입니다.

이후에는 백엔드 개발자로서 개발 역량을 갖추기 위해 꾸준히 학습하고 도전해 보고자 합니다. 특히 도전을 두려워하지 않는 개발자로 성장하고 싶습니다. 새로운 프로젝트를 할 때, 이전에 사용해 보지 않았던 기술 스택을 사용하게 되거나 더 크고 복잡한 서비스를 개발하게 되더라도 믿고 맡길 수 있는 개발자가 되고 싶습니다.

👤프론트엔드 :

사용자와 데이터를 바탕으로 제품을 함께 만들어갈 수 있는 개발자로 성장하고 싶습니다. 이번에 모바일 웹뷰의 크로스 브라우징 이슈를 깊이 파고든 경험을 계기로, 웹앱은 물론 다양한 브라우저 환경, 나아가 네이티브 앱까지 개발 범위를 넓혀보고 싶습니다. 또한 이번에 익힌 AI 도구 활용 판단력을 더 크고 복잡한 서비스에서도 검증해 보고 싶습니다.

앞으로도 실제 사용자가 있는 서비스를 팀원들과 하나씩 만들어가는 경험을 이어가며, 서비스 전체를 이해하는 개발자로 성장하고 싶습니다.

Q. 다음 기수 참가자들에게 해주고 싶은 조언이 있을까요?

A. 무엇이든 최대한 많이 배우고 가져가겠다는 마음가짐으로 참여하셨으면 좋겠습니다. 그리고 프로젝트를 진행하면서 어떤 의사결정을 하든, 누군가의 의견이나 근거를 들었을 때도 '왜?'라고 질문하는 습관을 가지셨으면 합니다.

팀 프로젝트를 하다 보면 기획자나 개발자 등 각 포지션에서 원하는 요구사항이 생기는데, 이를 모두 수용하다 보면 어느 순간 서비스가 무엇을 위해 만들어지고 있는지 놓치기 쉬운 것 같습니다.

저 역시 프로젝트를 진행하면서 그런 순간들이 있었고, 그럴 때마다 '이 결정이 정말 사용자에게 필요한가?', '우리가 이 서비스를 통해 전달하고자 하는 가치는 무엇인가?'를 다시 생각하려고 했습니다.

각자의 의견을 존중하면서도 결국에는 사용자가 얻는 가치와 서비스의 목적을 기준으로 고민하는 것이 중요하다고 생각합니다. 그런 습관을 가지고 프로젝트에 몰입한다면, 단순히 맡은 역할을 수행하는 것을 넘어 훨씬 많은 것을 배우고 성장할 수 있을 것 같습니다.

Q. 스위프 참가를 고민 중인 사람들에게 전하고 싶은 메시지가 있나요?

👤기획 :

PM이라는 직무를 경험해 보고 싶으신 분, 혹은 구상 중인 서비스를 빠르게 완성해 보고 싶으신 분께 강력 추천합니다!

저는 AI로 프로토타입을 만드는 것이 흥미로워 서비스도 구상하고 본 프로젝트에 참여를 결정하게 되었습니다. 하지만 PM으로서 디자이너, 개발자와 협업하며 실제 인터랙션이 가능한 서비스를 설계하는 것은 전혀 다른 영역이었습니다. 스위프 프로젝트에 참여하지 않았다면 참고할 레퍼런스도, 정해진 기한도 없어 지금까지도 아이디어만 가진 채 구현 계획에 흐지부지되었을 가능성이 높습니다.

하지만 스위프를 통해 다른 팀들이 어떻게 작업하는지 일주일에 1번씩 확인하며 인사이트를 얻고, 데모데이 1위를 목표로 하며 서비스의 완성도를 높이고자 하는 동기도 가질 수 있었습니다. 개인적으로는 20대 이후에 가장 몰입도 높은 성취 경험이었습니다.

👤백엔드 :

프로젝트 경험을 쌓고 싶거나 협업 경험이 부족하다고 느끼는 분들에게 적극 추천하고 싶습니다.

혼자 공부할 때는 기술 자체에 집중하게 되지만, 프로젝트를 진행하면 기획, 디자인, 개발이 함께 움직이며 실제 서비스를 만들어가는 경험을 할 수 있습니다.

특히 다양한 사람들과 협업하며 의견을 조율하고 문제를 해결하는 과정은 개인 공부만으로는 얻기 어려운 경험이라고 생각합니다.

저 역시 이번 프로젝트를 통해 기술적인 성장뿐 아니라 협업과 커뮤니케이션 능력도 크게 향상될 수 있었습니다.

결과적으로 좋은 성과까지 얻을 수 있었기 때문에 새로운 도전을 고민하고 있다면 참여해 보시는 것을 추천드립니다.

Q. 마지막으로, 스위프에게 전하고 싶은 한마디가 있을까요? 😊

A. 스위프를 통해 책임감 있고 유능한 팀원들을 만날 수 있었다는 점에서 매우 감사하게 생각합니다. 이 인연이 있었기에 만족할 만한 프로덕트를 완성했고, 더 나아가 프로덕트를 발전시킬 계획도 세울 수 있었습니다.

스펙 측면에서나 추억 측면에서나, 귀중한 경험을 선물해 주신 스위프에 감사드립니다.

함께 성장을 경험하고 싶다면, 지금 스위프에서 시작하세요.

지금 바로 함께하기