DEVOCEAN

안녕하세요 데보션 영 3기 Commit조의 김경환 입니다.

저희 팀의 개발 과제 여정에 대해 이야기 해보고, 최종 결과물을 공유해보려고 합니다.

초기 개발 주제

저희 팀은 초기에는 개발 주제로 "AI 기반 유튜브 요약 서비스 (SPOT)"을 기획하게 되었습니다.

개발 배경 및 주요 기능

1. 개발 배경

SPOT의 개발 배경은 다음과 같습니다.

1. 정보 과부하의 시대 속 영상 플랫폼에서 얻는 정보를 효율적으로 관리 할 수 없을까?

2. 유튜브를 통해 해외 학습 영상을 쉽게 보고 공부할 수는 없을까?

라는 생각으로 기획하게 되었습니다.

2. 주요 기능

SPOT의 기능은 단순 합니다. 유튜브 URL을 입력하면 그 영상에 대해 GPT를 이용하여 요약을 해주는 것이죠.

요약된 내용을 따로 모아두고 볼 수 있게 구성을 하였습니다.

3. 전체 아키텍쳐

기존 서비스의 경우 안드 앱에서 웹뷰를 이용하여 클라이언트에게 제공되고 백엔드의 경우 Spring AI를 도입하여 GPT를 효과적으로 붙일 수 있도록 개발하였습니다.

또한 유튜브 영상을 프레임 별로 분석하게 해야 하기 때문에 FastAPI 기반의 서버를 따로 두고 설계를 진행했었습니다.

하지만.. 중간 발표 이후..

저희 조는 중간 발표 이후 많은 데보션 전문가 분들의 심도 있는 피드백을 받았습니다.

1. 서비스의 타겟 유저는 누구인지? 비즈니스 모델이 무엇인지

2. 왜 Spring AI를 썼는지? 안정화 되지 않은 걸로 알고 있는데 굳이 쓴 이유가 무엇인지?

3. 오브젝트 스토리지를 MinIO를 쓴 이유? S3를 사용하지 않는 이유?

4. 너무 단순한 기능에 비해 오버 테크 아닌가? 기술 선택 이유가 무엇인지?

등등의 피드백을 받고.

저희 조는 피보팅을 진행했습니다.

New Spot - 'CareSpot'

개발 배경

누구나 저희 나라에서 고령화가 진행되고 있다는 사실은 다 알고 계실 것 같습니다.

하지만, 이 노인분들을 케어 해주고 계시는 노인 돌봄 인력이 부족한 사실도 알고 계셨나요?

실제로 서울시 사회 서비스원에 근무하시는 분의 인터뷰에 따르면

"1명이 야간에는 20명" 가까이 돌봐야 한다고 합니다.

저희는 이러한 사회 현상을 해결하기 위해

생성형 AI와 IoT 기술을 접목 시켜 'CareSpot' 서비스를 기획, 개발 하였습니다.

서비스 구성 요소 및 기능

저희 서비스는 IoT 기술을 접목 시켰기 때문에 실제로 유저에게 제공될 수 있는 디바이스 제작도 하였습니다.

1. 어르신과 소통할 수 있는 디바이스인 "케어독(CareDock)"

2. 어르신 집 내의 IoT 장비인 "케어홈(CareHome)"

3. 보호자가 안심할 수 있는 "케어앱(CareApp)"

으로 구성하였습니다.

1. 케어독 (CareDock)

케어독은 어르신 댁 내 설치되는 디바이스로 라즈베리파이 보드기반으로 구성되어 있습니다.

라즈베리파이 보드에 스피커, 마이크, 카메라, 터치스크린을 부착하여 어르신과 음성 기반으로 소통할 수 있게 구성하였습니다.

케어독 내에는 웹 기반의 챗봇 화면으로 어르신과 음성 기반으로 소통할 수 있게 하였습니다.

2. 케어홈 (CareHome)

케어홈은 어르신 댁 내 설치되는 IoT 장비로 라즈베리파이 보드 기반으로 구성하였으며 라즈베리파이 보드에 온습도 센서, 소음 센서, 움직임 감지 센서들을 구성하여 연결하였습니다.

센서 데이터들을 라즈베리파이가 카프카로 데이터를 전송합니다. 연결된 센서들은 아래의 데모 영상 링크를 통해 확인하실 수 있습니다.

3. 케어앱 (CareApp)

케어앱은 보호자 용 앱으로 실시간으로 케어홈으로부터 전송되는 센서 데이터들을 모니터링을 할 수 있으며 센서 데이터를 기반으로 응급 상황이라고 판단하면 알림이 오는 기능도 제공합니다.

또한 케어독을 통해 어르신이 대화한 이력을 확인하실 수 있습니다, 또한 대화한 이력을 기반으로 요약 보고서도 제공합니다.

4. 서비스 구성도

저희 서비스 구성도는 아래의 그림과 같습니다. 기본적으로 React 기반의 웹과 안드로이드 네이티브로 앱을 개발 하였으며,

서비스 구성을 간소화하기 위해 Python 기반의 FastAPI 프레임워크를 이용하여 백엔드를 구성하였습니다.

LLM Provider로는 OpenAI 사의 GPT-4o를 사용하였고,

서버 관리용 데이터베이스로 RDBMS인 PostgreSQL과 센서데이터 적재용 데이터베이스로

Docs Storage인 MongoDB를 사용하였습니다.

센서 데이터의 경우는 클러스터로 구축되어 있는 카프라 브로커에 Producing 하면 Kafka Connect를 이용하여 MongoDB로 Sink연결하여 실시간으로 적재될 수 있도록 구성하였습니다.

기술 설명

1. Why Kafka?

저희 서비스에서 Kafka를 도입한 이유에 대해 말씀드리겠습니다.

Kafka는 실시간 데이터 스트리밍이 가능하기 때문에 실시간 스마트홈 모니터링 기능에 적합하며 분산형으로 설계되었기 때문에 손쉬운 Scale-Out이 가능합니다.

또한 토픽 기반으로 원하는 데이터만 가져올 수 있기 때문에 IoT 데이터를 다룰 때에 여러 이점이 있어 선택하게 되었습니다.

또한 저희 서비스는 Kafka와 Kafka Connect를 같이 사용하였습니다,

Kafka Connect는 Kafka로 들어오는 특정 Topic의 Message를 다른 Sink로 실시간 적재할 수 있는 기술입니다.

저희 서비스에서는 Sink를 MongoDB로 설정하였으며 이러한 기술 사용으로 실시간으로 계속 수집 되는 데이터를 중앙 서버로 집중하지 않아도 데이터를 저장할 수 있어 중앙 서버의 부하를 줄여줄 수 있습니다,

또한 복잡한 코딩 없이 설정 파일 만으로 쉽게 데이터를 통합할 수 있기 때문에 개발 리소스를 줄여줄 수 있습니다.

2. Multi Agent LLM

저희 서비스에서는 양질의 보고서를 제공하기 위해 Multi Agent LLM을 적용하였습니다.

유저 채팅 이력을 오케스트레이터 에이전트가 받아 각 에이전트의 작업을 수행하도록 하고 각 에이전트의 응답 값을 모아 자연스러운 최종 보고서를 생성하도록 구성하였습니다.

또한 오케스트레이터 에이전트의 수행 명령을 받는 에이전트로 '원인파악 에이전트', '증상분석 에이전트', '해결분석 에이전트'를 구성하여

순차적으로 에이전트들의 응답 값을 체인되게 만들어 풍부한 보고서를 생성하도록 하였습니다.

이러한 멀티 에이전트를 일반 채팅에도 적용하려고 했으나,

속도와 품질의 Trade Off 관계에 있어,, 일반 채팅에는 Single Agent로 동작하게 구성하였습니다.

데모 영상

1분 안에 만들고 싶어서.. 중간 중간 배속을 넣었습니다.

데모 영상

Commit조 개발 과제 후기

경환 (Backend, Hardware)

데보션 영 마지막 과제인 개발 과제 블로그를 쓰며 많은 생각이 드네요.

거의 1년이라는 시간 동안 데보션 영 활동을 하며 값진 경험을 얻었습니다.

값진 경험을 토대로 더 멋진 사람이 되겠습니다.

규헌 (AI)

Multi-Agent LLM을 처음 접하면서 각 에이전트가 어떻게 데이터를 주고받으며 상호작용해야 더 나은 결과를 도출할 수 있을지에 대해 고민한 시간이었고,

이 과정에서 '좋은 챗봇 설계란 무엇인가'라는 질문을 던졌습니다. 팀원들과의 협업을 통해 다양한 시각을 접하며 프로젝트를 성공적으로 마무리할 수 있어 뜻깊은 경험이었습니다.

지민 (Web)

프론트엔드로서 고객과 소통하는 챗봇의 화면을 만들었습니다. 어떻게하면 더 접근성 높고 편리한 화면을 만들지 고민하면서 역량을 키울 수 있었습니다

특히 중간 발표를 통해 프로님들께 피드백을 받아 더 좋은 프로젝트를 만들 수 있었습니다.

마지막으로 시니어와 약자를 실질적으로 도울 수 있다는 점에서 의미 있는 프로젝트였습니다

유빈 (App)

이번 프로젝트는 데보션의 지원 속에서 다양한 분야의 사람들과 협업할 수 있다는 것이 가장 큰 장점이었던 것 같아요.

평소라면 생각해보지 못했을 것 같은 기능들을 적용하면서 개발자로서의 역량도 늘릴 수 있었던 기회였어요