[스위프 후기] 스위프 웹 15기 완주 후기
2026년 8월부터 10월까지 진행된 스위프 웹 15기 8주 과정 후기입니다. 일곱 명 팀의 팀장과 프론트엔드를 맡아 팝업 코스 서비스 팝픽을 배포하고 수료하기까지, 회의 시간을 맞추고 결정을 모은 일과 마지막 2주, 구글 로그인 QA, 데모데이를 돌아봤습니다.
"팝업을 찾지 마세요. 오늘 갈 곳을 팝픽이 골라 드립니다."
8월 22일 킥오프로 시작한 스위프 웹 15기가 어느새 10월 22일 수료 발표를 끝으로 마무리됐습니다. 일곱 명이 한 팀이 되어 팝업 코스 서비스 팝픽을 배포하고 수료까지 했는데요. 팀장과 프론트엔드를 함께 맡았던 8주를 돌아보려고 합니다.
프롤로그
스위프를 시작하게 된 계기
저는 현업 프론트엔드 개발자입니다. 회사 일과는 별개로 기획부터 배포까지 한 팀으로 끝까지 가 보고 싶어서 스위프 웹 15기에 지원했습니다. 그래서 목표도 포트폴리오에 넣을 결과물보다는 실제로 운영하는 서비스로 잡았어요.
간단한 소감
회사를 다니면서 보낸 8주였습니다. 개발 마감 날 밤에는 끝났다는 실감이 잘 나지 않았어요. 돌아보면 팀장을 맡으면서 많이 성장한 것 같습니다. 프론트엔드 개발에만 집중할 수 있는 자리가 아니었어요. 팀 일을 전반적으로 주도해야 했고 회의 일정과 안건, 운영진에 낼 자료까지 신경 쓸 게 많았습니다.
스위프는 이런 곳입니다
스위프(SWYP) (새 창에서 열림)는 IT 직군이 팀을 꾸려 사이드 프로젝트를 끝까지 만드는 프로그램입니다. 웹과 앱 트랙이 있고, 저는 웹 15기에 참여했어요.
8주의 일정
운영진이 직군 비율에 맞춰 팀을 짜 주면, 그다음부터는 이 일정대로 진행됩니다.
- 8월 22일 킥오프
- 목요일 21시 온라인 리뷰데이. 팀별로 진행 상황을 발표합니다. 15기는 리뷰데이가 다섯 번 있었습니다
- 10월 4일 개발 마감. 배포 주소를 내면 운영진이 팀이 미리 제출한 기능 구현 계획을 기준으로 QA를 합니다
- 10월 17일 오프라인 데모데이. 발표와 서비스 체험
수료 조건이 전부 이 날짜들에 걸려 있어서, 마감을 놓치면 그대로 수료를 못 합니다.
직접 써 본 혜택
- 뤼이도 유료 구독 이용권. 프로젝트 관리 도구 뤼이도(Riido)를 유료 요금제로 받아 일정 보드로 썼습니다. 주차마다 할 일과 진행 상태를 여기서 맞췄어요.
- 운영진의 관리 감독. 마감 뒤에 운영매니저님이 서비스를 직접 눌러 보고 팀 전용 채널로 QA 결과를 줍니다. 저희 팀은 이 QA에서 구글 로그인 하나 때문에 2차 QA까지 받았습니다.
- 수료증과 상장, 수료 리워드. 10월 28일에 수료증을 받았고, 수료 리워드도 따로 나옵니다.
우리가 만든 것, 팝픽
팝픽(POP PICK)은 취향과 시간, 지역에 맞는 서울 팝업스토어를 추천하고, AI가 방문 코스까지 짜 주는 서비스입니다.
출발점은 주말에 팝업 하나 가려고 해도 할 일이 많다는 것이었습니다. 정보는 인스타그램과 지도 앱, 커뮤니티에 흩어져 있고, 찾고 나면 관심 없는 팝업까지 섞여 있어서 고르기가 피곤해요. 겨우 골라도 몇 곳을 어떤 순서로 돌지 다시 짜야 합니다.
그래서 팝픽은 처음 들어올 때 취향을 받아 홈 추천을 바꾸고, 지도와 목록으로 팝업을 둘러보다 마음에 드는 곳을 찜할 수 있게 했습니다. 마지막으로 AI 플래너에서 지역과 동행, 날짜와 시간을 고르면 AI가 방문 순서와 머무는 시간, 고른 이유까지 담아 코스를 만들어 줍니다.
배포 주소는 pop-pick-web.vercel.app (새 창에서 열림)입니다. 한 번씩 들어가 봐 주세요!
8주 돌아보기
일요일 밤 9시의 정기회의
저희는 1팀, 일곱 명이었습니다. PM 한 명, 디자이너 한 명, 프론트엔드 두 명, 백엔드 세 명이고 저는 팀장과 프론트엔드를 같이 맡았어요.
가장 먼저 어려웠던 건 회의 시간을 맞추는 일이었습니다. 일곱 명의 일정을 모아 보니 평일 저녁에 다 같이 모일 수 있는 날이 하루도 없었던 것 같습니다. 그래서 정기회의를 일요일 밤 9시로 잡고, 일요일에 다음 주를 정하고 주중에 만드는 식으로 8주를 보냈습니다.
흩어진 결정을 모으는 일
결정이 흩어지는 것도 문제였습니다. 공지는 슬랙, 대화는 디스코드, 일정은 뤼이도, 시안은 피그마, 코드는 깃허브에 있었거든요. 그래서 회의록을 작성해서 정리하고 정해진 것과 안 정해진 것을 제 위키에 따로 모았어요. 뭐가 정해졌는지 궁금한 팀원은 저한테 물어봤고, 다음 회의 안건도 여기서 안 정해진 것을 골라 만들었습니다.
기록이 쌓이니까 회의 때마다 계속 밀리는 안건도 보였어요. 팝업 데이터를 어디서 가져올지가 그랬습니다. 그래서 개발자들만 따로 모이는 회의를 제안했고, 그 회의에서 소셜 로그인 범위와 API 응답 규칙 같은 개발 쪽 안건을 정리했어요.
화면 동작처럼 말로만 해서는 정해지지 않는 안건도 있었습니다. 이건 PM님이 와이어프레임을 띄워 놓고 화면 순서대로 짚어 가는 기획 리뷰를 열어 주셔서 한 번의 리뷰로 정리됐어요. 그 뒤로는 큰 방향은 정기회의에서, 화면 동작은 화면을 띄워 놓고 정했습니다.
개발이 몰린 마지막 2주
공식 개발 기간 2주가 시작될 때 디자인 시안은 아직 나오기 전이어서 시안을 기다리지 않기로 했습니다. 와이어프레임대로 화면을 먼저 만들어 기능부터 붙이고, 시안이 나온 뒤 이틀 동안 화면을 시안대로 다시 올렸어요. 팝업 목록과 검색 같은 핵심 기능은 마감 이틀 전에야 서버에 붙었고, 마감 날 오후에 배포를 마쳤습니다.
QA에서 받은 X 하나
마감 이틀 뒤 운영진이 1차 QA 결과를 줬습니다. 계획한 기능 중에 구글 로그인 하나에만 X가 붙어 있었어요.
사실 마감 배포 때부터 알고 있던 문제였습니다. 로컬에서는 되는데 배포 주소에서만 구글 로그인이 막혔고, 마감 전까지 원인을 못 찾았거든요.
원인은 구글 로그인 설정이었어요. 웹에서 백엔드용으로 만든 데스크톱 앱 유형 키를 같이 쓰고 있었는데, 이 유형은 배포 주소를 받아 주지 않습니다. 백엔드 팀원분이 짚어 준 덕분에 웹용 키를 따로 만들어 그날 바로 고쳤어요.
그래도 운영진은 1차 QA를 기준으로 수료를 보는데, 계획한 기능이 1차에서 다 확인되지 않았으니 2차 QA로 넘긴다고 했어요. 다행히도 수료에는 문제가 없었습니다.
스위프에서 얻은 것들
결정은 적어 둬야 남습니다
도구가 다섯 곳으로 흩어진 팀에서는 누가 무엇을 정했는지 물어볼 곳이 하나 있어야 했습니다. 저희 팀에서는 기록을 들고 있던 제가 그 역할을 했어요. 계속 밀리는 안건이 눈에 들어온 것도 기록이 쌓인 뒤였습니다.
로컬에서 되는 것과 배포 주소에서 되는 것은 다릅니다
구글 로그인 문제는 코드가 아니라 구글 쪽 설정에 있었습니다. 외부 서비스 설정은 코드 리뷰로 잡히지 않아요. 배포 주소에서 직접 눌러 봐야 보이는 문제였습니다.
AI를 쓰는 범위는 처음부터 좁게
팝픽의 홈 추천은 PM님이 정한 기준대로 내고, AI는 플래너에서 코스와 고른 이유만 만들었습니다. 마감 직전에 팝업 설명이 비어 있는 데이터가 많아 AI로 채울지 고민했지만, 사실이 아닌 내용이 섞일 수 있어서 확인된 정보만 보여 주기로 했어요.
좋은 팀원들
같이 한 팀원 모두에게 고마운 장면이 하나씩 있습니다.
PM님은 정기회의 도중에 직접 검색해서 저희가 만들려던 기능을 거의 다 갖춘 경쟁 서비스를 찾아내 주시고, 그 서비스를 분석해서 방향성을 계속 고민해 주셨어요. 기능 수로 겨루지 않고 AI 추천을 앞에 두는 쪽으로 방향을 바꿨고, 기능 명세와 테스트 시트도 PM님이 썼습니다.
디자인은 디자이너님 혼자 맡아 화면 시안부터 로고와 썸네일, 파비콘까지 만들었어요. 정해진 기간 안에 결과를 내는 게 먼저라며 기능을 더 늘리지 말자고 한 것도 디자이너님이었습니다.
백엔드 팀원 중 스위프를 이미 수료해 본 분은 누가 말하기 전에 팀 디스코드 서버를 꾸려 줬어요. 다른 한 분은 알림 기능을 빼기로 했을 때 캘린더에 일정을 넣어 알림을 대신하자는 안을 냈습니다. 마감 날 밤에는 코스 생성이 몇몇 지역에서만 되던 문제를 맡아 고쳤어요. 나머지 한 분은 마감 직전 밤늦게까지 지역 필터와 정렬, 지도 좌표를 운영 서버에 올려 줬습니다.
같이 프론트엔드를 개발한 팀원분은 온보딩과 마이페이지, 구글 로그인 화면을 맡았어요. QA에서 구글 로그인이 막혔을 때 코드에는 문제가 없고 구글 쪽 설정을 봐야 한다고 가장 먼저 짚은 것도 이분이었습니다.
아쉬웠던 점
팀장으로서의 역할
팀장을 맡으면서 프론트엔드 개발도 같이 해야 했어요. 기능 구현 계획과 배포 주소, 팀 정보, QA 원인 공유, 발표 자료까지 운영진에 내는 것도 거의 다 제가 맡았어요. 그러다 보니 발표 자료 초안은 마감보다 하루 늦게 냈습니다.
회의도 준비한 만큼 결론을 내지 못한 날이 있었어요. 안건을 여러 개 들고 갔다가 하나도 다루지 못하고 끝난 스크럼도 있었습니다.
다시 팀장을 맡는다면 운영진 제출물은 처음부터 담당을 나누고 결정 기록도 저 혼자 보는 위키 대신 팀이 같이 보는 곳에 두고 싶어요.
피드백 받을 기회
리뷰데이에서는 질문이 오가는 날이 적어서 외부 피드백을 받을 기회가 많지 않았습니다. 그래서 데모데이 전에 지인들에게 배포 주소를 보내 직접 써 보게 했어요.
써 본 사람 여럿이 새 계정으로 처음 들어와 취향을 저장하는 단계에서 오류를 만났습니다. 첫 화면부터 오류를 보면 홈 추천도 비어 버리는 문제였어요. 인기 팝업 랭킹이나 가까운 순 같은 기능을 바라는 의견도 있었고, 현업 기획자 한 분은 AI 코스 생성이 가장 좋았다며 지도에 방문 순서를 그려 달라고 했습니다. 이 의견들은 데모데이 발표의 향후 계획에 넣었어요.
데모데이
10월 17일 데모데이는 디캠프 선릉에서 열렸습니다.
발표
저희 팀 발표는 제가 맡았습니다. 7분 안에 문제와 해결, 시연, 시행착오까지 넣어야 해서 장마다 시간을 재 가며 연습했어요.
체험 시간
체험 시간에는 테이블에 팝픽 이름표를 세우고 노트북을 두어, 참가자분들이 직접 써 보게 했습니다.
스위프를 고민하는 분들에게
추천하는 이유
회사 밖에서 기획부터 배포까지 다른 직군과 끝까지 가 보고 싶은 분께 추천합니다. 매주 리뷰데이가 있고 수료 조건이 날짜에 걸려 있어서 중간에 흐지부지되기 어려워요. 저처럼 회사를 다녀도 리뷰데이는 평일 밤 온라인이고 회의 시간은 팀이 정하니 병행할 수 있었습니다.
다만 기술 멘토링은 없었어요. 운영진이 챙기는 건 팀 구성과 일정, QA와 데모데이 같은 진행 쪽이라, 개발하다 막히는 건 팀 안에서 풀어야 합니다.
미리 준비하면 좋을 것들
데이터가 필요한 서비스라면 데이터를 어디서 가져올지부터 정하세요.
저희 팀에서 계속 밀렸던 안건이 바로 이것이었습니다. 화면은 2주 안에도 만들 수 있지만, 채울 데이터가 없으면 시연이 안 됩니다.
원인을 찾을 시간이 남아 있을 때 배포 주소에서 로그인 버튼을 눌러 보세요.
저희는 마감 배포 때 실패를 알았지만 원인은 마감 뒤에야 찾았습니다. 로컬에서 된다고 배포 주소에서도 되는 건 아니더라고요.
에필로그
팀원 대부분이 소감에 팝픽을 더 키우고 싶다고 적었습니다. 데모데이 발표에서는 다음에 만들 기능으로 추천 이유 보여 주기와 AI가 짠 코스 직접 고치기, 인기순, 다녀온 팝업 기록을 소개했어요.
저는 이 중에서 플래너 화면을 맡았던 만큼 AI가 짠 코스를 직접 고치는 기능부터 만들어 볼 생각이에요.
8주 동안 함께해 준 팀원들께 먼저 고맙다는 말을 전합니다. 공지와 QA로 일정을 챙겨 주신 운영진분들, 배포 주소를 직접 써 보고 의견을 남겨 주신 지인분들께 감사드려요.
부록
재참가 할인
모든 기수 참여자는 다음 기수에 다시 지원하면 수료 여부와 상관없이 30% 재참가 할인을 받을 수 있습니다. 두 번 이상 다시 참가하면 할인이 50%로 늘어나요. 자세한 조건은 스위프 웹 FAQ (새 창에서 열림)에서 볼 수 있어요.
이런 글도 읽어보세요
재생 엔진을 갈아 끼울 수 있는 HLS Player 모듈 설계하기
마이크를 끈 상담 녹화만 재생되지 않던 장애에서 시작해 Shaka Player와 hls.js를 어댑터로 갈아 끼울 수 있는 HLS 재생 모듈을 만든 과정입니다. 브라우저에 HLS 라이브러리가 필요한 이유부터 엔진을 고를 수 있게 만드는 설계까지 다룹니다.
[RADIO로 시스템 디자인하기 #3] 실시간 채팅 앱 설계 부숴보기
RADIO로 시스템 디자인하기 시리즈의 세 번째 글입니다. 서버가 먼저 말을 거는 실시간 채팅을 소재로, WebSocket 선택부터 낙관적 병합, 순서 보장, 가변 높이 가상화까지 RADIO 다섯 단계로 처음부터 끝까지 설계해봅니다.
[RADIO로 시스템 디자인하기 #2] 자동완성 검색창 설계 부숴보기
RADIO로 시스템 디자인하기 시리즈의 두 번째 글입니다. Input과 Dropdown뿐인 작은 UI 안에 디바운스, 캐시, race condition, 접근성까지 자동완성 검색창을 RADIO 다섯 단계로 처음부터 끝까지 설계해봅니다.