팀 소개
- 팀명: 구운 감자
- 구성: 프론트엔드 2명 · 백엔드 1명(본인)
- 기간: 2026.07.16 ~ 2026.07.30 (약 2주)
프로젝트 소개
구움(Gooum)
팀명인 구운감자의 '구움'과 협업 공간을 뜻하는 Room을 결합한 이름.
대화를 나누고, 협업하며, 결과물을 함께 구워내는 공간
실시간 채팅 · AI 회의록 자동 생성 · 동시 문서 편집을 하나로 합친 AI 기반 협업 메신저다.
왜 만들었는가
팀 협업을 할 때 보통 대화는 카카오톡, 기록은 노션, 문서 편집은 구글독스를 쓴다. 도구가 흩어져 있다 보니 탭을 계속 오가야 하고, 회의가 끝나면 누군가가 대화 내용을 일일이 정리해서 옮겨야 한다. 그 과정에서 결정사항이 빠지는 일도 생긴다.
Slack이나 Teams 같은 도구도 있지만 "같은 조직"이 전제되기 때문에 해커톤, 사이드 프로젝트, 대학 팀플 같은 상황에서는 도입 자체가 어렵다. 결국 다시 카톡과 구글독스로 돌아가는 악순환이 반복된다.
그래서 채팅 → AI 요약 → 동시 편집의 흐름을 하나의 서비스에서 끊김 없이 연결하고, 워크스페이스 없이 가입만으로 누구와든 바로 협업할 수 있는 서비스를 만들고자 했다.
내가 맡은 역할
백엔드 전체를 담당했다. REST API 설계, 실시간 채팅(Socket.io), DB 설계, 인증, 파일 업로드, 배포까지 백엔드에 필요한 모든 영역을 직접 구현했다. 동시 편집(y-websocket)은 프론트 팀원이 구현과 테스트를 진행했고, 나는 해당 코드를 서버에 배포하는 역할을 맡았다.
핵심 기능
1. 실시간 채팅
1:1 및 그룹 채팅, 실시간 메시지 송수신을 지원한다.
2. 동시 문서 편집
여러 사용자가 하나의 문서를 동시에 편집할 수 있고, 변경 사항이 실시간으로 반영된다.
3. AI 회의록 생성
채팅 내용을 기반으로 AI가 회의록을 자동 생성하고, 생성된 회의록을 동시 편집 가능한 문서로 저장할 수 있다.
기술 선택과 이유
Node.js + TypeScript를 선택한 이유
원래 백엔드는 거의 Python + FastAPI 위주로 해왔다. 그런데 이번 프로젝트에서 실시간 채팅을 구현해야 했고, Socket.io가 가장 편하고 적합해 보였다. Socket.io를 제대로 활용하려면 Node.js 환경이 자연스러웠다.
거기에 부트캠프에서 프론트엔드를 배우면서 JavaScript를 익히게 됐는데, 매일 하던 Python보다는 새로운 언어로 백엔드에 도전해보는 게 좋겠다고 판단했다. TypeScript를 선택한 건 타입 안전성 때문이었고, 결과적으로 백엔드를 TypeScript로 처음 해본 경험이 됐다.
Azure 배포
Azure App Service 단일 인스턴스에 REST API, Socket.io, y-websocket을 함께 올렸다. 처음에는 이 세 가지가 하나의 서버에서 동시에 돌아간다는 게 신기했는데, 구조를 보니 이해가 됐다. Express가 HTTP 요청을 처리하면서, 같은 서버의 같은 포트에서 Socket.io와 y-websocket이 HTTP 연결을 WebSocket으로 업그레이드해서 붙는 방식이었다. Node.js가 이벤트 기반 논블로킹 I/O라서 하나의 프로세스에서 HTTP와 WebSocket을 동시에 처리할 수 있는 것이다.
배포가 단순하고 관리 포인트가 하나라는 장점이 있지만, 트래픽이 커지면 채팅이 몰릴 때 API도 같이 느려질 수 있다는 단점이 있다. 다만 MVP 단계에서는 이 구조가 훨씬 합리적인 선택이었다.
시크릿 관리는 Azure Key Vault를 사용했고, 시스템 할당 관리 ID를 통해 안전하게 접근하도록 구성했다.
AI 호출 구조
AI 회의록 생성은 프론트엔드에서 Gemini API를 직접 호출하는 방식으로 구현했다. 프론트 팀원이 클라이언트에서 AI 호출하는 경험을 해보고 싶다고 해서 이번에는 그렇게 진행했다. 다만 이 구조에서는 API 키가 클라이언트에 노출되기 때문에, 향후에는 백엔드를 프록시로 두고 키를 서버 환경변수에서만 관리하는 방식으로 전환하기로 했다.
트러블슈팅
1. API 응답 시간 지연 — DB 리전 이슈
가장 큰 이슈였다. API 응답이 대부분 3초 이상 걸렸고, 쿼리를 아무리 최적화해도 체감할 수 있는 변화가 없었다. 뭔가 근본적인 문제가 있다고 느껴서 원인을 파고들었더니, App Service는 Korea Central에 만들었는데 Cosmos DB는 브라질 리전에 생성되어 있었다. 물리적 거리에서 오는 네트워크 레이턴시가 원인이었다.
DB 리전을 Japan으로 옮기자 대부분의 API 응답이 3초 이상 → 0.5초 이내로 줄었다. 코드 레벨의 최적화보다 인프라 구성을 먼저 점검해야 한다는 걸 체감한 경험이었다.
2. 브라우저 캐시 이슈
코드나 데이터를 수정해도 화면에 반영되지 않는 현상이 있었다. 브라우저가 이전 응답을 캐시에서 그대로 재사용하고 있었던 것. Ctrl+Shift+R로 하드 리프레시하면 캐시를 무시하고 강제 재요청이 되면서 수정 사항이 정상 반영됐다.
3. 로컬 환경 실시간 테스트 이슈
팀원과 실시간 채팅을 테스트할 때 메시지가 서로에게 반영되지 않는 문제가 있었다. 원인은 단순했다. 각자 로컬 환경(localhost)에서 서버를 실행하고 있어서 같은 소켓 서버에 연결되지 않았던 것. 배포된 서버에 함께 접속해서 테스트를 진행하니 실시간 송수신이 정상 동작했다.
배운 점과 좋았던 점
양방향 실시간 통신을 직접 경험한 것
이전까지는 단방향 통신만 해봤기 때문에 소켓이나 양방향 통신이 어떻게 동작하는지 개념으로만 알고 있었다. 이번에 Socket.io로 직접 메신저를 구현해보니 "아, 메신저가 이런 식으로 동작하는 거구나"를 확실히 체감할 수 있었다.
익숙한 것 대신 도전을 선택한 것
매일 쓰던 Python/FastAPI 대신 TypeScript + Node.js로 백엔드 전체를 구현한 건 처음이었는데, 새로운 언어로 실제 서비스를 만들어보는 경험 자체가 재밌었다.
아쉬운 점
시간 부족으로 못 넣은 기능들
2주라는 시간 안에 MVP를 완성하는 데 집중하다 보니, 구현하고 싶었지만 넣지 못한 기능들이 있다. 이모지 리액션 기능은 메시지에 대한 간편한 피드백 수단으로 꼭 넣고 싶었고, 동시 편집도 현재 순수 텍스트만 지원하는데 마크다운 문법을 지원했다면 회의록이나 기획서 같은 실무 문서까지 플랫폼 안에서 완결할 수 있었을 것이다.
AI 활용의 확장 가능성
현재 AI는 채팅 내용을 요약해서 회의록을 생성하는 한 가지 용도로만 사용하고 있다. 하지만 대화 맥락을 기반으로 할 일(To-Do) 목록을 자동 추출하거나, 회의록을 여러 버전(간단 요약 / 상세 기록 / 액션 아이템 중심 등)으로 생성하는 기능까지 확장할 수 있었다면 서비스의 차별점이 더 뚜렷했을 것이다.
향후 개선 방향
기능 확장
리액션 기능: 이모지 리액션을 추가하면 불필요한 답장을 줄이고 빠르게 의사 표현이 가능해진다.
마크다운 기반 리치 문서 편집: 마크다운 문법을 지원하고 실시간 렌더링까지 되면 실무 문서를 플랫폼 안에서 완결할 수 있다.
AI 다중 요약 모드: 간단 요약, 상세 기록, 액션 아이템 중심 등 목적에 맞는 여러 버전의 회의록을 생성할 수 있도록 확장한다.
구조 개선
API 키 서버 사이드 전환: 현재 프론트에서 Gemini API를 직접 호출하고 있어 API 키가 클라이언트에 노출된 상태다. 백엔드 프록시를 통해 API를 호출하고 키는 서버 환경변수로만 관리하는 구조로 전환하면 키 탈취 및 요금 폭탄 위험을 제거할 수 있다.
링크
- GitHub (Backend): https://github.com/ureca-Gooum/Gooum-BE
- GitHub (Frontend): https://github.com/ureca-Gooum/Gooum-FE
- 배포 URL: https://gooum-green.vercel.app/
- 시연 영상: https://youtu.be/JqVb_mgDe8o
