[스위프 후기] 생성형 AI를 활용한 여행 서비스 개발 회고

김주엽·2025년 12월 14일

취준을 본격적으로 시작한지 어느덧 10개월..
데브코스 수료 후 학교 졸업 준비와 이것저것 공부하다보니 벌써 10월이 훌쩍 지나있었다.
이곳저곳 떠돌아 다니다가 우연히 스위프라는 곳을 알게 되었고 고민없이 신청해서 사이드 프로젝트를 진행하게 되었다. 오늘은 스위프에서 프로젝트를 마치면서 후기를 남겨보려고 한다:)

🚀 스위프란?

스위프는 6주동안 PM, 디자이너, 개발자가 한 팀으로 모여 사이드 프로젝트를 진행하는 프로그램이다.
내가 수강했던 데브코스 과정은 백엔드 개발자만 이뤄진 상태에서 진행했기에 다른 직군과의 협업 경험이 많이 부족한 상태였다.

나에게 있어 스위프는 다양한 직군이 한 곳에 모여 사이드 프로젝트를 진행한다는 점에서 크게 장점으로 느껴졌고 이 외에도 개발에 필요한 여러 지원이 주어지는 것 같아 지원을 하게 되었다.

✨ 스위프 참여 혜택

프로젝트를 위해 스위프에서 여러 혜택을 지원해주지만 개발자 입장에서 가장 크게 느껴졌던 혜택은 다음과 같은 것들이 가장 와닿았다.

1. 네이버 클라우드 크레딧 최대 100만원 지원

스위프에서는 개발 서버/DB 구축, 생성형 AI 등을 위한 네이버 클라우드 크레딧을 최대 100만원까지 지원하는데 이 부분이 가장 맘에 들었다.

사이드 프로젝트를 진행하다보면 항상 떠오르는 고민이 배포라고 생각한다.
프로젝트를 완성했으면 누군가에게는 보여줄 수 있어야 하니까 배포가 가장 중요한데 네이버 클라우드 크레딧을 지원받을 수 있다는 점이 가장 큰 장점이라고 생각한다.

2. 스위프 데모데이 & 네트워킹 행사

개발을 하다보면 다른 직군과 소통할 일이 매우 잦은데 개발 관련 용어들을 쉽게 설명하는게 가장 어렵다. 이런 어려움을 데모데이 행사에서 디자이너나 PM 분들과 얘기를 많이 나눴었는데 이 경험이 큰 도움이 됐던 것 같다.

(네트워킹 중 한 분이 오셔서 얘기를 나눴었는데 알고 보니 스위프에서 제공해주는 협업 툴 뤼이도의 대표분이시더라..😮)

🔥 프로젝트 준비 과정

팀 빌딩

스위프 합격 후 가장 먼저 하게 되는 건 팀 빌딩이다.
스위프 측에서 노션 링크를 전달해주는데 여기에 자기소개 카드를 작성하고 개인적으로 맘에 드는 사람이 있다면 자유롭게 DM 보내서 팀을 완성하는 방식이다.

연락이 안오면 어쩌나.. 싶다가 다행히도 AI에 대한 관심사가 비슷하다고
DM을 주신 분이 계셔서 팀 빌딩을 무사히 마칠 수 있었다ㅠㅠㅠㅠ

팀장 및 협업 룰 정하기

팀 빌딩이 끝난 후에는 팀장을 뽑은 후 미팅 시간이나 협업 방식을 빠르게 정했다.

우리 팀에서는 다음과 같은 룰을 정했다.

소통은 디스코드로 직군별로 스레드를 나누어 관리
프로젝트 일정/이슈 관리는 뤼이도 사용
매주 수요일 오후 9시에 진행 상황 공유 및 회의 진행
회의 참석이 어렵다면 빠르게 디스코드로 공유하기

홈 프로텍터로 항상 집을 지키고 있는 상태였기에 다행히(?) 룰을 지키는데 큰 어려움은 없었다ㅎ..

주제 선정

처음에는 기준에 맞게 각자 작성한 아이디어에 대해 점수를 1~5점으로 측정해
가장 점수가 높은 아이디어를 선정해서 진행하기로 했다.

이 과정에서 내가 제시한 게임 패치노트 챗봇 서비스가 선정됐는데 아쉽게도 한 분이 게임에 대한 도메인 지식이 낮아 진행하지 못하고 빠르게 다른 주제를 정할 필요가 있었다.

주제를 선정하는데 시간을 너무 오래 쓸 수 없다고 판단해 각자 빠르게 하나씩 더 해보고 싶은 아이디어를 생각한 후 1시간..? 후에 곧바로 미팅을 잡아 우여곡절 끝에 생성형 AI를 활용한 여행 추천 서비스가 우리의 프로젝트로 선정됐다.

✈️ Airoad - 생성형 AI를 활용한 여행 추천 서비스

주제 선정이 끝난 후에는 백엔드에서는 사용할 기술 스택을 먼저 정했다.

기술 스택

Language: Java 17
Framework: Spring Boot 3.5.6, Spring AI 1.1.0
Build Tool: Gradle
Database: JPA, H2(Test), PostgreSQL 16.x (+ pgvector for RAG)
Cache: Redis
External APIs
- Tour API
LLM Model
- Chat: OpenAI, gpt-4.1-mini
- Embedding: Naver Clova X, bge-m3
API Documentation: Swagger/OpenAPI
ETC
- Spotless / Jacoco / SonarQube

언어와 프레임워크는 백엔드 팀원 모두가 자프링을 선호해서 쉽게 정할 수 있었다.

DB의 경우 처음에는 MySQL 8.x를 사용하려고 했는데 여행 추천 기능 개발에 필요한 RAG 파이프라인 구성을 위해서는 pgvector 플러그인을 지원하는 PostgreSQL이 더 적합하다고 판단해 팀원에게 설득한 후 PostgreSQL 16.x로 개발을 진행했다.

LLM의 경우에는 지원받은 네이버 클라우드 크레딧을 활용하기 위해 Naver Clova X를 쓰려고 했지만 OpenAI 호환 이슈와 개발하면서 여러 테스트를 해보니 Tool에 대한 개념이 다소 부족하다고 판단해 최종적으로는 gpt-4.1-mini를 선택했다.

핵심 기능

프로젝트에서는 생성형 AI를 활용한 여행 추천을 핵심 기능으로 하고 다른 서비스와 차별점을 두기 위해 일정 수정이나 장소 추천을 챗봇 대화를 통해 가능하도록 구현했다.

여행 정보 입력
- 여행 도시, 날짜, 기간, 인원 수 입력
- 여행 테마 선택 (체험/액티비티, 문화/역사, 자연/힐링, 맛집 투어, 쇼핑 등)
AI 일정 자동 생성
- RAG(Retrieval-Augmented Generation) 기반 관광지 추천
- 이동 시간을 고려한 최적 동선 계획
- 일자별 상세 일정, 숙소, 맛집 추천
일정 편집
- 장소 추천: 유저가 원하는 다른 장소를 쉽게 검색할 수 있도록 챗봇 대화를 통해 장소 검색
- 챗봇 대화: "첫번째 일정과 두번째 일정 순서를 서로 바꿔줘" 같은 자연어로 요청하면 챗봇이 일정을 수정
일정 확정 및 저장
- 최종 확정된 일정을 "내 여행 일정"에 저장
- 언제든지 조회 및 재수정 가능

🛠️ 프로젝트 셋업

나를 제외한 다른 백엔드 팀원 두분의 경우 아직 대학생이다 보니 백엔드 개발 경험이 내가 가장 많은 상태였다.. 나도 많이 부족하지만 쨋든 팀원이 빠르고 좀 더 편하게 개발할 수 있도록 프로젝트에 대한 셋업을 개발 시작 전 미리 해두었다.

패키지 구조

팀원 모두가 레이어드 아키텍처로 개발한 경험이 있다고 해서 익숙한 레이어드 아키텍처를 사용하고 프로젝트 종료 후 개선할 때 도메인간 모듈별로 쉽게 분리할 수 있도록 패키지 구조를 가져가고자 했다.

com.swygbro.airoad.backend/
├── common/                 # 공통 모듈
│   ├── config/             # 설정 클래스 (Swagger, JPA Auditing 등)
│   ├── domain/
│   │   ├── dto/            # 공통 DTO
│   │   └── entity/         # BaseEntity 등 공통 엔티티
│   ├── exception/          # 예외 처리
│   │   ├── ErrorCode.java           # 에러 코드 인터페이스
│   │   ├── BusinessException.java   # 비즈니스 예외 클래스
│   │   └── CommonErrorCode.java     # 공통 에러 코드 enum
│   └── presentation/       # GlobalExceptionHandler 등 공통 컨트롤러
│
└── <domain>/               # 도메인별 패키지 (예: example)
    ├── presentation/       # 컨트롤러 (REST API 엔드포인트)
    ├── application/        # 유스케이스 및 비즈니스 로직 서비스
    ├── domain/
    │   ├── dto/            # 데이터 전송 객체
    │   └── entity/         # 도메인 엔티티
    ├── exception/          # 도메인별 에러 코드
    │   └── <Domain>ErrorCode.java  # ErrorCode 인터페이스 구현 enum
    └── infrastructure/     # 리포지토리 및 외부 시스템 연동

Claude Code

프로젝트 기간의 경우 개발 기간 6주 + 유지보수 2주로 짧은 기간은 아니지만 중간에 추석연휴가 끼면서 개발 기간이 사실상 2~3주..밖에 없었다. 이에 빠르게 개발할 필요가 있어 팀원에게 Claude Code 사용을 추천하고 관련 서브 에이전트나 커스텀 명령어들을 미리 작성해두었다.

예를 들어 github-manager 서브 에이전트를 작성해두고 /commit, /pr-create 같은 커스텀 명령어를 입력하면 커밋 컨벤션과 PR 템플릿에 맞게 서브 에이전트가 커밋 후 PR까지 자동으로 완성하도록 추가해두었다.

그 외에도 context7, sequantial-thinking과 같은 MCP 서버를 사용해 Claude가 개발 문서 참조나 복잡한 문제를 좀 더 세분화해서 작업할 수 있도록 추가했다.

🐳 프로젝트 결과

프로젝트 셋업이 끝난 후 눈 한 번 깜빡..했더니 프로젝트가 끝나있었다.
분명 10월에 시작했던거 같은데 벌써 12월이라니.. 시간 너무 빠르다😭
프로젝트 결과를 쨋든 정리하면 다음과 같은 경험을 할 수 있었다.

✅ 잘했던 점 (Keep)

짧은 기간 안에 서비스 흐름을 끝까지 완성한 점

추석 연휴가 포함되면서 실제 개발 기간이 많이 짧았는데도 여행 일정 생성부터 챗봇을 통한 일정 수정, 최종 저장까지 하나의 흐름을 끊기지 않게 구현할 수 있었던 점이 가장 만족스러웠다.

단순히 “AI를 붙여본 프로젝트”가 아니라 실제로 사용자가 한 번쯤은 써볼만한 프로토타입에 가까운 완성도를 만들었다는 점에서 의미가 컸다.
개발 초반 셋업을 미리 해둔 점

프로젝트 시작 전에 패키지 구조, 공통 예외 처리 방식, 코드 컨벤션, 커밋 메시지와 PR 규칙을 미리 정해두면서 개발을 진행하면서 생길 수 있는 불필요한 논의를 많이 줄일 수 있었다.

특히 Claude Code와 커스텀 명령어를 활용하면서 반복적인 작업에 드는 시간을 꽤 많이 아낄 수 있었던 것 같다.
RAG 기반 추천 구조를 직접 설계해본 경험

단순히 LLM에게 추천을 맡기는 방식이 아니라 관광지 데이터를 기반으로 LLM을 사용해 장소 요약 임베딩을 생성하고 pgvector를 활용해 검색한 결과를 바탕으로 답변을 생성하도록 구성했다.
생성형 AI 서비스를 구현하면서 “왜 이 장소가 추천되는지”를 고민해볼 수 있었던 경험이었다.
다른 직군과의 협업 경험

PM, 디자이너와 함께 기능 우선순위와 화면 흐름을 논의하면서 개발자 관점이 아닌 서비스 관점에서 생각해보는 연습을 할 수 있었다. 데모데이와 네트워킹 과정에서 개발 내용을 비개발자에게 설명하는 경험을 많이 해볼 수 있었던 것도 큰 도움이 됐다.

❗ 아쉬웠던 부분 (Problem)

LLM 응답의 일관성이 부족했던 점

챗봇을 통해 일정을 수정하는 과정에서 의도한 것과 다르게 일정이 바뀌거나
Tool을 사용하지 않고 응답하는 경우가 간혹 발생했다.
프롬프트 설계나 Tool 사용 방식에 대해 아직 많이 부족하다는 걸 느끼게 된 부분이었다.
여행 도메인(지도·경로)에 대한 이해 부족

경도, 위도, 지도 데이터와 관련된 도메인 지식이 충분하지 않다 보니
여행 일정 경로 최적화 부분에서 아쉬움이 많이 남았다.

프로젝트 막바지에 경로 최적화와 관련된 논문들을 찾아보면서 지역 단위로 장소를 클러스터링한 뒤 경로를 구성하는 방식이 실제 서비스에서도 많이 사용된다는 걸 알게 되었는데,
이 부분을 초반에 알았더라면 더 나은 구조로 설계할 수 있었을 것 같다는 아쉬움이 컸다.
API 명세서를 지속적으로 관리하지 못한 점

개발 시간이 빠듯하다 보니 API 명세를 Claude Code로 빠르게 작성한 뒤
변경 사항을 그때그때 반영하지 못한 부분이 있었다.

중간에 일부 API 스펙이 실제 구현과 어긋나는 이슈가 발생했고 뒤늦게 수정하긴 했지만
협업 관점에서 API 명세 관리의 중요성을 다시 한번 느끼게 된 계기였다.

👀 개선할 것들 (Try)

LLM 성능 개선하기

지금 작성된 프롬프트는 개발 시간을 맞추는데 초점을 두고 작성하다 보니 많이 미흡하다.
따라서 프롬프트를 더욱 더 명확하게 개선하고 일정 수정, 장소 변경, 날짜 이동 같은 작업을 명확한 Tool 단위로 나눠서 응답의 일관성과 안정성을 높이고 싶다.
여행 도메인에 대한 이해를 바탕으로 추천 로직 개선

경로 최적화와 지도 관련 도메인 지식을 조금 더 깊게 학습한 뒤 클러스터링 기반 경로 구성이나 이동 거리 계산 로직을 추천 과정에 자연스럽게 녹여보고 싶다.
단순히 “좋아 보이는 장소 나열”이 아니라 실제 이동까지 고려한 추천을 목표로 개선해보고 싶다.
DDD + 헥사고날 아키텍처로 개선하기

현재는 레이어드 아키텍처 기반으로 빠르게 구현하는 데 집중하다 보니
도메인 로직과 인프라, AI 연동 코드가 점점 섞이는 구조가 되었다.

다행히도 패키지 구조를 바운디드 컨텍스트 단위로 나눠둔만큼
도메인 로직을 중심에 두는 DDD 방식으로 아키텍처를 재정리해보고 싶다.

또한 헥사고날 아키텍처를 적용해
외부 API, LLM, DB 같은 요소들을 어댑터로 분리함으로써
기술 변화에도 비교적 유연하게 대응할 수 있는 구조를 만들어보고 싶다.

✍️ 앞으로의 계획

위에서 정리한 개선 포인트들을 바탕으로
프로젝트를 바로 확장하기보다는 하나씩 정리해보는 시간을 가져보려고 한다.

그리고 개인적으로는 개인 기술 블로그를 직접 개발해보려고 한다.
벨로그도 편하고 좋긴 한데 서버가 자주 터지는 경험을 하다 보니
이참에 글 작성부터 배포까지 전부 직접 관리해보고 싶다는 생각이 들었다.

조금 여유가 생긴다면 이번에 좋은 경험을 했던 스위프에도 다시 한 번 지원해보고 싶고
최근 알게 된 사이프라는 개발 동아리에도 도전해보면서 계속해서 새로운 자극을 받아보고 싶다.

김주엽

나야 루이지

이전 포스트

Gemini CLI 사용기

2개의 댓글

ho_vi

2025년 12월 14일

주엽님의 ai 사용능력은 정말 탑..! 그동안 LLM 성능 개선시키느라 고생많으셨어요 ㅠㅠ

1개의 답글