[스위프 후기][SWYP 웹 11기] 국내 여행 AI 서비스 Airoad 개발 회고록

한 달 동안 스위프(SWYP) 웹 11기와 함께 달리며 배우고 성장한 여정을 정리해보려 한다. 스위프 웹 11기에서 경험한 협업과 개발의 모든 순간들을 기록해두고 싶었다.

스위프에 참여하게 된 계기

사실 팀프로젝트를 여기저기 참여하면서 느낀 가장 큰 단점은 끝까지 프로젝트를 마치기
쉽지 않다는 점이다.

오늘도 어김없이 인프런에 상주하다가 발견하게 된 스위프 프로그램은
팀 빌딩부터 유지보수 및 고도화까지 책임지고

또 요즘 가장 중요하게 생각하는 네트워킹까지 행사로 추가해 인사이트를 공유하는 시간까지
책임을 진다는게 마음에 들어 프로그램에 참여하게 되었다.

팀 빌딩

팀 빌딩을 위해 자기소개 카드를 노션에 올리면서 아무도 연락이 안오면 어쩌지 하는 걱정이 있었는데 생각보다 많은 분들이 연락을 주셔서 너무 감사했다..

우리 스위프 11기 4팀은 PM을 따로 뽑지 못해서 가장 경력도 많으시고 PM 경험까지 있으신 동현님이 디자이너 겸 PM을 맡으시게 되었다.

해서 디자이너 2분, 백엔드 3분, 프론트 2분 총 7명이서 팀을 꾸리게 되었다..!

협업 방식

1. 정기 회의 시간

• 매주 수요일 오전 9시에 진행
• 각자 진행한 업무 / 앞으로 할 업무를 채팅으로 공유
• 회의는 30분 이내로 마무리하는 것을 원칙으로 함

---

2. 자체 회의 시간

• 필요 시 팀원들끼리 자유롭게 디스코드에서 회의 진행 가능
• 프론트엔드/백엔드 파트별 PR·코드리뷰는 자체적으로 진행

---

3. 사용 채널

• 소통: 디스코드
  https://discord.gg/CmbwgyRy
• 일정 관리: 뤼이도

---

4. 지켜야 할 것

• 프로젝트에서 정한 약속과 일정은 최대한 준수하기
• 일정에 차질이 생길 경우 빠르게 공유하기
• 메시지 확인 시 체크 표시 또는 이모지로 반응하여 커뮤니케이션 명확하게 유지하기

---

주제 선정

동현님의 리드 하에 ICE 평가법(Impact / Confidence / Ease) 방식으로 주제 선정을 하게 되었다. Impact(영향), Confidence(확신도), Ease(난이도) 3가지 기준으로 점수를 매겨서 가장 우선순위 높은 아이디어가 무엇인지 정하기로 했는데 AI 관련 아이디어가 많이 나와서 역시 대세는 AI 구나 싶었다.

이렇게 ICE 과정을 거친 뒤 가장 점수가 높은 주제 3개를 선정해서 투표를 했다. 결과는 가장 많은 표를 얻은 개임 패치노트 챗봇 서비스가 선정되게 되었다!

하지만 이슈가 있었다.. 게임이라는 도메인이 어떻게 보면 마이너한 주제라 팀원 중 한분이 게임에 대한 이해도가 낮아 진행하기 어렵다는 의견이 있었다. 고민 끝에 우리는 AI라는 주제를 살리고 대중적인 도메인인 여행, 독서를 결합해 각자 의견을 제출하고 투표를 진행해 우리는 국내 여행 일정 추천 AI 서비스를 선정했다!

프론트엔드 기술 스택 선정

첫번째 정기회의가 끝나고 나와 산성님은 프론트엔드 기술 스택을 정하기로 했다. 나도 이것저것 기술스택을 활용하는 것을 좋아하고 산성님 또한 프론트엔드 기술에 대한 열정이 있으셔서 서로 의견 조율을 해가며 수월하게 기술 스택을 선정하게 되었다. 또 나보다 1년 더 연차가 많으신 프론트엔드 선배(?)셔서 더 든든하고 의지가 되었던 것 같다.

기술 스택

• React 19 - UI 라이브러리
• TypeScript - 타입 안정성
• Vite - 빌드 도구 (SWC 플러그인 사용)
• React Query - 서버 상태 관리
• React Router - 라우팅
• Vanilla Extract - CSS-in-JS 스타일링
• MSW - API 모킹
• Biome - 린팅 및 포매팅
• pnpm - 패키지 매니저

이번에 새로운 css 라이브러리인 vanilla extract을 사용하게 되었다. 물론 기존 스택을 활용하면 익숙하고 러닝커브 없이 개발할 수 있다는 장점이 있겠지만 새로운 개발스택을 사용하게 되었을때 생기는 경험치를 무시할 수 없었다.

FSD 아키텍쳐

산성님과 아키텍쳐 방식을 논하면서 FSD 방식을 제안해주셨다. 나는 보통 Atom 아키텍쳐 방식을 사용했기 때문에 FSD 아키텍쳐를 미리 선행하지 않으면 쉽지 않겠다는 생각이 들어 여기저기 자료를 찾아봤다.

사실 아키텍쳐라는 것은 정답은 없다고 생각한다. 어떤 프로젝트냐, 어떤 기술스택을 사용하냐, 어떤 개발 성향이냐에 따라서 선호하는 방식이 다르지만 FSD 아키텍쳐는 커뮤니티가 굉장히 활발하기도 하고 계속해서 발전해 나가는 형태여서 현재는 어느정도 틀이 잡혀있는 상태라 공용적으로 사용되는 방식으로 활용하기로 했다.

이런 부분에 있어서는 경험자의 코멘트가 중요하다고 생각하기 때문에 매주 토요일마다 과외를 진행하는 멘토님과 FSD 아키텍쳐에 대해 깊게 고민하고 의견을 나누는 시간을 가졌다.

FSD(Feature-Sliced Design) 아키텍처 트렌드 정리

이슈 기반 워크플로우

프론트엔드 팀은 Issue-Driven Workflow 기반으로 작업하기로 했다. 스위프에서 지원하는 뤼이도라는 프로젝트 관리 도구를 활용하면 이슈마다 브랜치명이 생성되어 연결된 레포에 PR을 올리면 자동으로 뤼이도가 이슈 업무 진행중으로 변경하고 머지가 되면 완료된 태스크로 넘겨주는 점이 마음에 들었다.

또한 우리는 회의툴로 디스코드를 활용하고 있기 때문에 디스코드와 연동하여 이슈 생성 및 PR 생성 시 알림이 오는 구조로 워크플로우를 진행했다! 디스코드 알림설정은 평소 업무 툴이나 플러그인으로 지식이 많으신 주엽님께서 설정해주셨다.

기획 및 디자인

AI 여행 일정 생성이라는 기획에 맞춰서 디스코드로 각자 의견을 제시하고 어느정도 틀이 잡힌 기획을 동현님이 와이어프레임 플로우로 짜주셨다. 초반 기획 때 틀에 벗어나지 않도록 가이드라인도 잡아주시고 회의가 주제에 벗어나지 않도록 도움을 많이 주셨다..!

프론트엔드 팀에서는 UI 컴포넌트 라이브러리로 Radix UI를 사용하기로 했고 이 내용을 디자인팀에 먼저 공유했다. 그런데 디자인팀에서 Radix UI의 Figma 소스를 그대로 참고해 온보딩 화면 디자인을 작업해주셨는데 이게 생각보다 훨씬 더 협업 효율이 좋았다.

Radix UI는 원래 헤드리스 UI(스타일 비포함) 형태가 장점인데 이번에는 디자인팀이 Figma 소스를 기반으로 작업을 하다 보니 헤드리스 특유의 자유도는 조금 줄어들었지만 그래도 장점이 있었다.

• 디자인이 실제 사용하는 컴포넌트 구조와 거의 1:1로 맞아떨어지고
  
• 속성 값(Spacing, Radius, State 등)이 이미 Figma에 정리되어 있으니
  
• 프론트엔드에서 구현할 때 스타일 튜닝할 필요가 거의 없었다
  

결국 ‘빠르게 동일한 UI를 코드로 옮길 수 있다’는 게 엄청난 이점이었다.
그리고 개인적으로 가장 크게 배운 점은 이거였다:

디자이너와 협업할 때, 팀에서 사용하는 UI 라이브러리가 무엇인지 먼저 언급하는 게 중요하다.
디자인팀이 그 라이브러리의 Figma 소스를 바로 활용해서
프론트–디자인 간의 간극을 크게 줄일 수 있기 때문이다.

이전에는 디자이너가 컴포넌트 디자인을 하고, 개발자가 해당 속성 값을 활용해 구현한다. 정도로만 생각했었는데
이번에 협업하면서 피그마 소스를 통해 개발 시간을 크게 단축할 수 있다는 걸 처음 알았다.
덕분에 앞으로의 디자인 미팅에서는 사용중인 UI 라이브러리를 공유하는게 좋겠다는 확신이 들었다.

업무 분담 및 개발 과정

• 인증(소셜 로그인) = @박산성
• 온보딩(기본 데이터 입력, 멀티 스텝 폼) = @윤홍비
• 챗봇 = @박산성
• 일정 보여주기(지도, 일차별 리스트) = @윤홍비

프론트엔드 팀에서는 논의 끝에 업무를 분담하고 태스크별로 해당 업무를 맡은 백엔드 분과 맨투맨으로 디스코드 스레드를 생성해서 진행하기로 했다. 업무 별로 스레드를 만들어서 관리하니 어디에 이야기를 꺼낼지 확실하고 이슈가 잘 정리되어서 관리하기 좋았다. 개인 메시지로 진행하면 팀원에게 업무 진행 상황을 공유하기가 힘든데 스레드로 이야기를 나누면 대화 히스토리가 고스란히 남아서 팀 전체가 흐름을 한눈에 파악할 수 있고 중간에 합류한 사람도 자연스럽게 맥락을 따라올 수 있다는 점이 좋았다.

스레드로 이야기를 진행하며 더 자세한 설명이 필요한 것들은 음성채팅으로 화면공유해가며 논의했다. 사실 프론트엔드에서 백엔드에게 '이렇게 데이터 구조 수정해주세요', '해당 API 추가로 만들어주세요' 하고 요청하면 귀찮을 법도 한데 주엽님과 승기님의 빠른 피드백에 감동 받았다.. 새벽까지 PR을 올리는 디스코드의 알람을 보면서 굉장히 동기부여가 되었다.

실시간으로 메시지가 정상적으로 들어오는 걸 보고 감격하는 승기님

코드 리뷰 과정

이전 이슈 기반 워크플로우를 기반으로 뤼이도에서 태스크를 추가하면 브랜치 연동이 되기 때문에 따로 레포에서 이슈생성은 하지 않고 해당 브랜치를 토대로 PR을 올렸다. 문서 형식은 주요 작업 내용, 이외 변경 사항으로 나눠 문서를 작성했다.

코드 리뷰를 좀 더 진행하고 싶었지만 한달이라는 시간이 너무 촉박해 추후에는 코드래빗을 추가해 PR을 올리고 수정할 수 있는 사항은 수정하여 바로 머지하는 방식으로 수정했다. 나중에 MVP 단계가 끝나고 본격적으로 디벨롭 단계로 들어가면 이번에 아쉽게 줄였던 코드 리뷰를 팀의 핵심 과정으로 올려보고 싶다.

프로젝트 발표 및 Q&A

행사 전날 갑작스레 감기몸살에 걸려 회사도 연차내고 하루 종일 이불 속에서만 버텼다...덕분에 준비했던 행사에는 끝내 참여하지 못했다 실제로 함께 프로젝트를 달린 팀원들과 만나서 여러 이야기도 하고 싶었는데 많이 속상했다. 이번엔 몸이 따라주지 않았지만 다음 기회가 있다면 꼭 건강한 모습으로 참석해서 팀원들과 마음껏 웃으며 좋은 시간 보내고 싶다.

그리고! 이번 MVP가 끝나고 서비스 고도화를 위해 바로 설문조사를 돌렸다. 프로덕트를 만든 사람의 입장에서 내가 느낀 부족함도 많지만, 실제 사용자들의 목소리를 듣는 건 또 완전히 다른 차원의 인사이트라 하나하나 읽으면서 우리가 집중해야 할 개선 포인트들이 명확히 잡히는 경험을 했다.

추후에는 기능 개선 사항을 반영하면서 고도화 작업 및 성능 최적화를 진행해보려한다.
팀원 모두 각자의 자리에서 최선을 다해줘서 정말 고마웠다. 짧지 않은 기간 동안 서로 의지하며 달려온 시간들이 지금 돌이켜보면 더 큰 의미로 남는 것 같다.

이번 MVP는 이렇게 마무리되지만 우리가 만들어온 흐름과 경험들은 분명 다음 단계에서도 큰 힘이 될 거라 믿는다. 앞으로도 서로의 성장과 더 나은 서비스를 향해 조금씩 나아가보고 싶다.