BooMeRang

개요

부메랑은 부동산 계약 경험이 적은 사용자가 계약 현장에서 느끼는 불안과 정보 격차를 줄이기 위해 만든 AI 기반 실시간 부동산 계약 보조 서비스입니다. 부동산 계약에서는 계약서 내용뿐 아니라 현장에서 이루어지는 설명 역시 중요한 판단 근거가 됩니다. 하지만 사회초년생이나 첫 부동산 계약을 진행하는 사용자가 계약서의 조항과 권리관계를 확인하면서 동시에 중개인이나 임대인의 설명까지 검증하기는 어렵습니다. 부메랑은 계약 현장의 대화를 STT로 변환하고 계약서 및 관련 문서를 OCR로 분석한 뒤, AI Agent가 두 정보를 함께 활용하여 계약 과정에서 사용자가 놓칠 수 있는 내용과 위험 요소를 확인할 수 있도록 하는 것을 목표로 했습니다. 단순히 계약이 끝난 뒤 녹음 파일을 분석하는 것이 아니라,

계약이 진행되는 순간 사용자가 현재 대화가 정상적으로 분석되고 있음을 확인하고 필요한 정보를 바로 얻을 수 있는 경험을 핵심 가치로 정의했습니다. 약 2주 동안 서비스 기획과 기술 검토를 진행했고, 실제 개발은 약 30시간의 해커톤 현장에서 진행했습니다. 기획 단계에서는 OCR을 어느 범위까지 사용할 것인지, 어떤 STT 구조를 사용할 것인지, 제한된 개발 시간 안에서 어떤 기능까지 안정적으로 완성할 수 있을지를 중심으로 기술적 트레이드오프를 검토했습니다.

---

기여 범위

프론트엔드 전반을 담당했으며, 특히 실시간 STT 구조 선정과 브라우저부터 STT API까지 이어지는 음성 처리 파이프라인을 중심으로 구현했습니다.

Frontend / Real-time STT

• React 기반 서비스 UI 구현
• STT 구현 방식 조사 및 비교
• Live STT 아키텍처 도입 제안
• 브라우저 WebRTC Audio Track 연결
• WebSocket 기반 WebRTC Signaling 구현
• Interim / Final STT 이벤트 수신 및 실시간 자막 상태 관리
• STT 세션과 계약 Room 데이터 연결
• REST API 및 백엔드 서비스 연동

Backend / Integration

Live STT 적용을 위해 프론트엔드뿐 아니라 백엔드 실시간 통신 계층도 함께 구현했습니다.

• FastAPI · aiortc 기반 WebRTC PeerConnection 구현
• WebRTC Audio Track 수신 및 PCM Audio Pipeline 연결
• Google Cloud Streaming STT 연동
• FFmpeg 기반 스트리밍 오디오 전처리 연결
• STT 결과의 MongoDB 저장 및 Room 단위 데이터 연결

또한 팀원들이 독립적인 브랜치에서 개발하던 STT · OCR · LLM 백엔드를 최종 서비스로 통합하는 과정에도 참여했습니다.

• 분산되어 있던 Backend Config 구조 통합
• FastAPI REST Router와 실시간 STT 세션 공존 구조 복구
• Circular Import 문제 해결
• OpenAI · CrewAI · aiortc 등 Python Dependency 충돌 정리
• Frontend / Backend 환경변수 및 Docker Compose 실행 환경 구성

즉 프론트엔드 화면 개발뿐 아니라 실시간 STT의 백엔드 구현과 서로 독립적으로 개발된 서비스 모듈을 하나의 실행 가능한 애플리케이션으로 연결하는 작업까지 담당했습니다.

---

주요 기술 구현

실시간 STT 파이프라인

부메랑에서 가장 집중했던 부분은 사용자의 음성이 들어오는 순간부터 STT 결과가 화면에 나타나기까지의 실시간 데이터 흐름이었습니다. 실제 구현 구조는 다음과 같습니다.

WebRTC와 WebSocket의 역할은 분리했습니다. 실제 음성 데이터는 WebRTC Audio Track을 통해 브라우저에서 FastAPI 백엔드로 전달했습니다. WebSocket은 음성 전송이 아니라,

• SDP Offer / Answer
• ICE Candidate
• STT Interim Result
• STT Final Result

등의 WebRTC Signaling과 STT 이벤트 전달에 사용했습니다. 백엔드에서는 aiortc로 브라우저의 Audio Track을 수신하고, 오디오 프레임을 STT 처리에 사용할 수 있는 형태로 변환해 Google Cloud Streaming STT에 전달했습니다. Google Cloud STT는 발화 중 Interim Result를 지속적으로 수정하고, 문장이 확정되면 Final Result를 반환합니다.

프론트엔드에서는 두 결과를 별도로 관리했습니다. Interim Result는 즉시 화면에 갱신하고, Final Result는 대화 세그먼트로 누적하여 사용자가 계약 중 현재 어떤 내용이 오가고 있는지를 바로 확인할 수 있도록 구현했습니다. 이를 통해 STT를 단순한 녹취 기능이 아니라 현재 계약 상황을 서비스가 이해하기 위한 실시간 입력 계층으로 활용했습니다.

---

기술적 의사결정

왜 Live STT를 선택했는가

기획 단계에서 STT 구현 방식을 전체 녹음 후 처리, 10~15초 단위 Batch 처리, Live STT 세 가지로 검토했습니다.

방식	장점	문제	판단
전체 녹음	정확도·화자 분리에 유리	계약 중 피드백 불가, 긴 녹음 데이터 보관 필요	제외
Batch STT	빠른 결과, 개별 STT 처리 단순	순서·병합·복구·화자 연결을 직접 관리	제외
Live STT	즉각적인 사용자 피드백	WebRTC 및 실시간 처리 구현 필요	채택

부메랑에서 가장 중요한 것은 최고의 STT 정확도가 아니라, 사용자가 계약 현장에서 서비스가 실제로 동작하고 있음을 즉시 확인하는 경험이라고 판단했습니다. Live STT는 WebRTC와 실시간 상태 관리라는 초기 구현 난이도는 높았지만, 스트림이 연결된 이후의 지속적인 처리는 Streaming API에 맡길 수 있었습니다. 반면 Batch 방식은 음성 분할, 순서 관리, 결과 병합, 실패 복구까지 서비스 내부에서 직접 구현해야 했습니다. 따라서 사용자에게 주는 가치와 약 30시간이라는 개발 제약을 함께 고려해 Live STT를 선택했습니다.

전체 녹음·Batch·Live STT를 비교하고 Live STT를 선택한 이유

---

트러블슈팅

FFmpeg Streaming에서 발생한 Blocking

Live STT 구현 중 FFmpeg 기반 오디오 전처리에서 Blocking I/O로 인해 서버 전체가 멈춘 것처럼 보이는 문제가 발생했습니다.

초기에는 Audio Chunk를 FFmpeg stdin에 전달한 뒤 동일한 크기의 결과를 stdout.read()로 즉시 읽는 구조였습니다. 하지만 FFmpeg가 같은 크기의 출력을 즉시 반환하지 않으면서 stdout.read()가 다음 데이터를 기다린 채 Blocking 되었고, 별도의 예외나 명확한 오류 로그도 발생하지 않았습니다.

원인을 확인한 뒤 stdout과 stderr를 별도 Thread에서 지속적으로 소비하고 결과를 Buffer에 저장하는 구조로 변경했습니다. 메인 Audio Pipeline은 짧은 Timeout 안에 처리 결과가 없으면 원본 Chunk를 그대로 통과시키도록 하여 오디오 전처리 하나가 전체 실시간 파이프라인을 중단시키지 않도록 구성했습니다.

이 경험을 통해 실시간 시스템에서는 API 호출 성공 여부뿐 아니라 처리 경로 내부의 Blocking I/O와 Thread 상태까지 함께 확인해야 한다는 점을 배웠습니다.

FFmpeg Blocking 문제 자세히 보기

---

트레이드오프 기준

이 프로젝트를 진행하면서 기술을 선택하는 기준 역시 명확해졌습니다. 단순히 가장 정확하거나 가장 구현하기 쉬운 기술이 아니라,

사용자에게 주는 가치 × 제한된 시간 안에서의 구현 가능성 × 실패했을 때 핵심 플로우에 미치는 영향 × 구현 이후 검증에 필요한 비용을 함께 고려해야 했습니다. Live STT는 이 기준으로 비교했을 때 좋은 선택이었습니다. 반대로 OCR 처리 구조에서는 이 기준을 충분히 적용하지 못한 부분도 있었습니다.

---

결과 및 회고

실시간 STT, OCR 기반 문서 분석, AI Agent를 하나의 서비스 흐름으로 연결한 MVP를 완성했고 정보통신기획평가원(IITP) AI 해커톤 최우수상을 수상했습니다. 하지만 실제 시연 과정에서는 기획 단계에서 예상했던 데이터 처리 구조를 완전히 구현하지 못한 부분도 있었습니다.

병렬 처리 구조를 충분히 검증하지 못한 문제

OCR과 파일 처리 작업은 처음에 Redis 기반 Worker 구조를 검토했지만, 약 30시간의 개발 시간에 비해 과도하다고 판단해 Thread 기반 병렬 처리 구조로 단순화했습니다.

계약이 진행되는 동안 문서 업로드와 OCR 처리를 함께 수행해 대화 종료 후 약 1분 안에 결과를 제공하는 것을 목표로 했습니다. 하지만 Thread 기반 병렬 처리를 충분히 검증하지 못해 실제로는 작업이 직렬화되었고, S3 업로드 병목까지 겹치면서 경우에 따라 최종 결과 생성 시간이 약 10분까지 증가했습니다.

돌이켜보면 Redis Worker를 사용하지 않은 것 자체가 문제는 아니었습니다. 더 큰 문제는 서비스 응답시간을 결정하는 병렬 처리라는 핵심 가정을 검증하지 않은 상태에서 구현 방식을 변경했다는 것이었습니다.

이 경험을 통해 오버엔지니어링을 피하는 것만큼이나 핵심 성능 가정을 검증할 수 있는 구조를 선택하고, 구현 비용뿐 아니라 검증 비용까지 기술 선택의 일부로 고려해야 한다는 점을 배웠습니다.

백엔드 병렬 처리 구조와 아키텍처 의사결정 회고 - 자세히 보기

---

시애틀 8주 연수로 이어진 경험

최우수상 수상을 계기로 미국 시애틀에서 진행된 8주간의 연수 프로그램에 참여할 기회를 얻었습니다. 이 경험은 부메랑 프로젝트 자체만큼이나 이후 제가 제품을 바라보는 관점에 큰 영향을 주었습니다. 그전까지 창업을 준비하면서 주로 보고 있던 것은 IR Pitch, Pitch Deck, 투자사가 보는 기준, 정부지원사업과 같은 외부적인 요소였습니다. 하지만 스타트업 생태계가 활발한 시애틀에서 여러 팀과 창업가를 만나면서 실제 제품을 만드는 과정에는 그보다 더 근본적인 문제가 있다는 것을 체감했습니다.

팀이 어떻게 소통하고 의사결정하는지, 우리가 정의한 Pain Point가 실제로 존재하는지, GTM 가설을 실제 사용자에게 어떻게 검증하는지, 그리고 예상한 수요를 어떤 방식으로 측정하는지

를 구체적으로 배우고 직접 실천했습니다. 특히 네트워킹 현장에서 가설에 맞는 잠재 사용자를 직접 찾아 CEO나 출장이 잦은 사람들에게 인터뷰와 설문을 요청하고, 실제 문제와 수요를 확인하는 과정을 반복했습니다. 이를 통해 내부에서 논리적으로 잘 만든 가설과 실제 사용자가 가진 문제는 전혀 다를 수 있다는 점을 체감했습니다. 그 이후에는 기술이나 사업 모델을 먼저 정교하게 만드는 것보다,

누구의 어떤 문제를 해결하려는지, 그 문제가 실제로 존재하는지, 우리가 만든 해결책을 실제 사용자가 필요로 하는지를 먼저 검증하는 것을 더 중요하게 생각하게 되었습니다. 또한 교육 프로그램뿐 아니라 8주간 시애틀에서 생활하며 다른 문화와 사람, 도시의 환경과 인프라를 경험한 것 자체도 기존에 가지고 있던 시야를 넓히는 계기가 되었습니다. 부메랑은 실제 개발 기간만 보면 약 30시간의 짧은 해커톤 프로젝트입니다. 하지만 실시간 시스템의 기술적 트레이드오프, Blocking I/O 트러블슈팅, 검증하지 못한 병렬 처리 구조의 실패, 그리고 수상 이후 이어진 시애틀 연수까지 경험하면서 제가 기술과 제품을 판단하는 기준을 크게 바꾼 프로젝트가 되었습니다.