[브루스터.챗] 2. 기술 스택과 결정 이유

이번 글에선 앞서 소개했던 순서도 흐름대로, 브루스터.챗을 만들기 위해 어떤 기술들을 골랐고, 왜 그렇게 의사결정을 했는지 말씀드리겠습니다.

브루스터.챗의 기술 스택

한 줄 요약브루스터.챗은 Supabase를 기반으로 OpenAI LLM을 활용해 색상 벡터 기반 원두 추천 로직을 구현하고, 이를 SwiftUI+TCA 구조의 iOS 앱에서 제공하는 프로젝트입니다.

1) 데이터베이스 & 서버: Supabase

이전에 Firebase를 주로 사용해 PaaS(Platform as a Service)의 편리함에 익숙해 있었습니다. 이번 프로젝트에서는 관계형 DB를 꼭 사용하고 싶었고, 마침 Supabase가 최근에 많은 관심을 받고 있길래 한 번 시도해보기로 했습니다.

• Storage(이미지 저장), Edge Functions(DB 업데이트·호출용 API) 등 다양한 기능을 제공해 빠른 MVP 개발에 적합했습니다.
• 특히 PostgreSQL 기반이라 pgvector 같은 익스텐션을 사용할 수 있는데, 바로 이것이 벡터 타입을 DB에 저장하는 핵심 포인트였습니다.

결국 “PostgreSQL + 벡터 DB”라는 요구사항을 가장 손쉽게 충족하는 선택지가 Supabase였고, 지금까지 써본 결과는 꽤 만족스럽습니다.

DB 스키마 (정의)

2) 원두 정보 수집: Python, BeautifulSoup4

요즘 크롤링하면 흔히 파이썬의 Selenium을 떠올릴 수 있지만, 이번 프로젝트에선 원두 목록의 이름, 가격, 컵노트(향미), 이미지 정도만 정적으로 가져오면 되어서, Requests + BS4 조합을 사용하는 것이 낫겠다고 판단했습니다.

실제로 차트 캡처같은 복잡한 액션이 필요했던 이전 프로젝트(비트코인 자동매매봇)처럼 “사이트 클릭”이나 “동적 렌더링”이 필요한 상황이었다면 Selenium을 메인으로 사용했을 것 같네요.

정보 수집 대상 사이트 예시 (실제로 이 사이트들을 긁진 않았습니다)

3) LLM 활용: OpenAI API(GPT-4o)

브루스터.챗의 핵심 기능 중 하나는 사용자 문장을 색상 코드로 변환하는 것입니다. 이를 위해선 LLM(대형 언어 모델)이 필수여서, 이미 결제해서 사용중인 OpenAI API를 사용했습니다.

이 프로젝트에서 만들고자 하는 결과(향미 기반 색상 코드 생성)가 어느 LLM을 써도 결과가 비슷할거라 생각하여 가장 손쉽게 접근할 수 있었던 GPT-4o를 사용했는데요. 추후엔 다른 LLM 서비스(예: Anthropic 등)와 비교해볼 기회가 생기면 또 즐거운 경험이 될 것 같습니다.

실제 개발 결과: 색상 코드와 이유 반환

4) 유사도 계산을 위한 벡터 DB: pgvector (Postgres 익스텐션)

이전에는 Firebase Storage에 저장된 데이터를 바탕으로 Pinecone 같은 벡터 검색 서비스를 활용했는데, Supabase를 쓰면서는 pgvector 익스텐션만 설치하면 DB 안에서 바로 벡터 연산을 할 수 있었습니다.

SELECT * 
FROM beans 
ORDER BY flavor_vector <-> '[255, 100, 50]' 
LIMIT 5;

위와 같이 작성하면, flavor_vector와 입력한 색상 벡터 간 거리(유사도)를 계산해 상위 5개 원두를 순식간에 찾을 수 있어 정말 편리했습니다.

5) iOS 클라이언트: SwiftUI + TCA

SwiftUI를 처음 써보던 4년 전에는 아직 생태계가 어수선했지만, 이제는 어느 정도 자리를 잡으면서 가장 주류가 된 선언형 UI 방식이라 판단했습니다.
게다가, 상태 관리 측면에서 TCA(The Composable Architecture)를 함께 써보니, 작은 앱을 빠르게 만들 때 꽤 좋은 궁합을 보여줬습니다.

물론 SwiftUI는 여전히 완벽하지 않으며, TCA의 학습 곡선도 있기 때문에 더 복잡한 서비스를 만든다면 더 고민할 것 같습니다. 하지만, MVP 수준에서는 오히려 이 조합이 속도와 개발 편의성 모두 만족시켜주기 때문에 이렇게 결정하였습니다.

SwiftUI+TCA를 통해 만든 채팅 UI

기타

현재는 어디까지나 프로젝트성 애플리케이션에 불과하지만, 서비스로 발전할 가능성을 생각해서 몇 가지 도구를 미리 생각해 보았습니다.

• Retool: PostgreSQL 기반 DB만 연결하면, 노코드 방식으로 쉽게 어드민 페이지를 만들 수 있는 도구입니다. 이전에도 Supabase와 함께 써봤는데 궁합이 좋았습니다.
• CoreData: 후에 사용자 채팅 기록이 필요해지고, 오프라인 지원이 중요해지면 고려해볼 생각입니다. 사용자 계정이 생긴다면 Supabase의 Auth도 함께 써볼 수 있겠네요. 경우에 따라 Supabase DB를 쓸 수도 있구요.
• TestFlight: iOS 앱을 베타 테스트할 때, 빠른 배포와 초대 링크를 지원해주기 때문에 최적의 선택지라고 생각합니다.

이상으로, 브루스터.챗의 주요 기술 스택과 그 선택 이유를 간략히 살펴보았습니다.

다음 글에서는 백엔드(Supabase + Python + LLM) 파트에서 구체적으로 어떤 문제들을 어떻게 해결했는지 다뤄보려고 합니다.

이번 글도 읽어주셔서 감사합니다!

브루스터.챗 시리즈 바로가기

• 브루스터.챗을 시작하게 된 계기
• [현재글] 브루스터.챗을 어떻게 만들었는지
• 브루스터.챗 백엔드 개발기 (예정)
• 브루스터.챗 iOS 개발기 (예정)
• 브루스터.챗 프로젝트 마무리 & 회고 (예정)