멍글멍글은 사람의 정면 사진과 유기견 사진을 분석해 닮은 후보를 보여 주고, 책임감 체크리스트와 AI 챗봇으로 입양 정보를 이어 주는 해커톤 프로토타입이다. 이 글은 실제 발표자료와 구현 화면을 기준으로 문제 정의, 모델, 백엔드, 챗봇을 다시 따라가며 무엇을 만들었고 무엇이 한계로 남았는지 기록한 프로젝트 회고다.
멍글멍글은 상용 서비스가 아니라 짧은 기간 안에 핵심 흐름을 검증한 프로토타입이었다. 당시 구현한 기능과 모델 결과를 돌아보고, 실제 서비스로 이어 가려면 무엇이 더 필요한지도 함께 적었다.

인사교 해커톤 25조 ‘멍글멍글’ 발표 표지
1. 출발점: 입양 의향과 실제 행동 사이의 간격
발표자료는 농림축산검역본부의 2023년 동물보호 국민의식조사를 근거로 유기동물 입양 의향이 84%인 반면 실제 입양률은 9%라고 제시했다. 입양을 망설이는 이유로는 ‘아기 때부터 키우고 싶다’ 38.9%, ‘입양 방법이나 절차를 잘 모른다’ 27.8%, ‘질병·행동 문제가 있을 것 같다’ 25.9%, ‘마음에 드는 품종이 없을 것 같다’ 7.4%가 정리되어 있었다.

발표자료에 인용된 입양 의향·입양률 및 입양을 고려하는 이유
팀은 이 간격을 두 단계로 풀었다. 먼저 얼굴 닮은꼴이라는 가벼운 진입점으로 관심을 만들고, 그 다음 체크리스트와 대화형 정보로 실제 입양 절차를 이해하게 하는 방식이다. 따라서 이 프로젝트의 핵심은 단순한 사진 유사도 앱이 아니라 Matching·Bond·Information을 하나의 흐름으로 연결한 데 있다.
2. 실제 사용자 흐름: 책임 확인 → 사진 분석 → 매칭 → 대화
책임감 체크리스트
첫 화면은 보호자의 성별, 주거 형태, 동거인, 함께할 수 있는 시간, 산책 빈도 등을 묻는다. 발표자료는 이 답변을 ‘사용자와 유기견의 성향을 맞추는 데이터’로 설명했다. 얼굴 사진보다 앞에 이 단계를 둔 것은 좋은 선택이었다. 재미로 들어온 사용자에게도 입양이 생활 조건의 문제라는 사실을 먼저 보여 주기 때문이다.

주거 환경과 돌봄 가능 시간을 확인하는 책임감 체크리스트
AI 닮은꼴 분석과 매칭 결과
사용자가 정면 얼굴 사진을 올리면 AI가 데이터베이스의 유기견과 얼굴 유사도를 비교해 후보를 보여 준다. 결과 카드에는 유사도와 함께 체크리스트 매칭 포인트가 표시되고, ‘대화해보기’를 누르면 해당 유기견의 이름·나이·성격·특징을 묻는 챗봇으로 이어진다.

유사 후보, 체크리스트 매칭 포인트, 유기견 역할 챗봇으로 이어지는 실제 시연 화면
얼굴이 닮았다는 사실은 주거 환경, 의료비 부담, 활동량, 행동 특성과 같은 입양 적합성을 대신하지 못한다. 실제 서비스로 확장할 때는 체크리스트와 보호소 상담을 필수 조건으로 두고, 닮은꼴은 후보 탐색을 돕는 보조 신호로 제한해야 한다.
3. 아키텍처: 한 컨테이너 안에서 기능 책임을 나눴다
시연용 서비스는 Docker 환경 안에서 프런트엔드, 백엔드, 비전 모델, 챗봇을 연결했다. 프런트엔드는 Bootstrap과 NGINX, 백엔드는 Spring Boot, 데이터베이스는 MySQL, 비전 모델은 PyTorch, 챗봇 흐름은 LangGraph로 구성했다.

멍글멍글 발표자료의 Docker 기반 서비스 아키텍처
| 영역 | 발표자료에서 확인한 구현 | 담당 책임 |
|---|---|---|
| 프런트엔드 | Bootstrap, NGINX | 체크리스트·사진 업로드·매칭·채팅 화면 |
| 백엔드 | Spring Boot REST API | 프런트와 모델 API 연동, 서비스 흐름 제어 |
| 데이터 | Docker Compose의 MySQL | 유기견 데이터 저장 |
| 비전 | PyTorch, YOLO, EfficientNet_B5 | 견종 분류와 사람·유기견 이미지 매칭 |
| 챗봇 | LangGraph, RAG, 메모리 | 전문 서적 기반 정보, 체크리스트 맞춤 답변, 대화 문맥 유지 |
해커톤에서는 여러 기능을 짧은 시간 안에 연결해야 하므로 이 구조가 실용적이다. 다만 운영 단계라면 얼굴 사진의 즉시 폐기 여부, 모델 API 장애 시 동작, 챗봇 답변의 출처 표시, 개인정보 접근 권한까지 백엔드 계약으로 명확히 남겨야 한다.
4. 모델: 견종 분류와 사람·유기견 매칭을 분리했다
YOLO로 20개 견종 분류
견종 분류 모델은 YOLO를 사용하고 20개 견종 이미지를 학습했다. 좌우 반전·회전·확대·이동 같은 기하학적 변환, 모자이크와 믹스업, 채도·명도 조절을 적용했다. 상하 반전은 실제 강아지 사진에서 자연스럽지 않다고 판단해 제외했다.

발표자료의 YOLO 내부 평가 결과: Top-1 0.9591, Top-5 0.9990
발표자료의 최종 그래프에는 Top-1 정확도 0.9591, Top-5 정확도 0.9990이 기록되어 있다. 다만 이 수치는 20개 견종 분류 데이터셋의 내부 평가 결과다. 실제 보호소 사진은 각도, 가림, 믹스견, 촬영 품질이 훨씬 다양하므로 서비스 성능으로 일반화하려면 외부 검증 데이터와 혼동행렬, 품종별 재현율이 추가로 필요하다.
EfficientNet_B5로 사람과 유기견 이미지 매칭
사람과 유기견의 닮은 이미지를 찾는 모델에는 EfficientNet_B5를 사용했다. 시연에서는 얼굴 특징을 비교해 비숑, 코카스파니엘, 푸들처럼 닮은 후보 견종을 제시하고 해당 유기견 카드로 연결했다. 이 기능은 프로젝트의 흥미를 만드는 데는 효과적이지만, ‘닮음’을 입양 성공 가능성으로 오해하지 않도록 UI 문구와 추천 순서를 제한해야 한다.
5. 백엔드와 챗봇에서 구현한 것
백엔드는 프런트와 모델을 잇는 REST API를 설계하고 Docker Compose에 MySQL 컨테이너를 추가해 유기견 데이터를 저장했다. 챗봇은 구조화된 에이전트 시스템으로 구성했으며, RAG를 활용해 전문 서적 기반 반려동물 정보를 제공하고 사용자별 체크리스트를 반영한 답변과 메모리 기반 대화 문맥 유지를 목표로 했다.
- 잘 연결된 부분: 매칭 결과에서 바로 해당 유기견과의 대화로 이어져 탐색 흐름이 끊기지 않는다.
- 검증이 더 필요한 부분: RAG 문서의 출처·갱신일, 답변 근거 표시, 잘못된 건강·행동 조언을 막는 거절 규칙이다.
- 개인정보 과제: 정면 사진은 분석 즉시 폐기하고 저장 여부와 보유 기간을 화면에서 명확히 알려야 한다.
6. 회고: 잘한 선택과 남은 한계
| 구분 | 회고 |
|---|---|
| 좋았던 점 | 체크리스트→사진 분석→매칭→챗봇의 사용자 흐름을 실제 시연 화면까지 완성했다. |
| 기술 연결 | Spring Boot·MySQL·PyTorch·LangGraph를 하나의 Docker 기반 서비스로 연결했다. |
| 모델 증거 | YOLO 학습·검증 손실과 Top-1·Top-5 정확도를 발표자료에 남겼다. |
| 가장 큰 한계 | 견종 분류 정확도와 입양 적합성은 다른 문제이며, 닮은꼴이 실제 입양 성과를 설명하지 못한다. |
| 제품 한계 | 보호소 실데이터, 상담가 검증, 입양 이후 관찰 결과가 없어 기대 효과를 실증하지 못했다. |
| 안전 과제 | 얼굴 사진 처리, 챗봇 답변 근거, 의료·행동 질문의 전문가 연결 규칙이 필요하다. |
이 프로젝트에서 가장 중요한 배움은 AI 모델 하나보다 사용자가 왜 들어오고, 어떤 정보를 확인하며, 어디서 사람의 판단으로 넘어가는지를 연결하는 일이었다. 닮은꼴은 첫 클릭을 만들고, 체크리스트는 책임을 생각하게 하며, 챗봇은 정보 탐색을 돕는다. 각 기능의 역할을 구분해야 서비스 메시지가 과장되지 않는다.
7. 다시 만든다면 이 순서로 개선한다
- 실제 보호소 데이터 구조부터 정한다. 품종 외에 나이, 건강, 활동량, 사회성, 관찰일, 정보 작성자를 저장한다.
- 생활 조건을 필수 필터로 올린다. 닮은꼴 후보보다 주거·돌봄·의료 조건을 먼저 통과시킨다.
- 외부 검증셋을 만든다. 믹스견과 실제 보호소 사진을 포함해 품종별 오류를 확인한다.
- 챗봇 근거를 화면에 표시한다. 답변마다 출처와 갱신일을 보여 주고 의료·행동 판단은 전문가 상담으로 연결한다.
- 입양 이후를 측정한다. 클릭률이 아니라 상담 완료, 적응 상태, 반환 사유로 제품 가설을 검증한다.
- 멍글멍글은 체크리스트, 얼굴 닮은꼴 분석, 유기견 매칭, RAG 챗봇을 연결한 해커톤 프로토타입이다.
- 서비스는 Docker 안에서 Bootstrap·NGINX, Spring Boot·MySQL, PyTorch, LangGraph로 구성했다.
- YOLO 20개 견종 분류의 발표자료 내부 성능은 Top-1 0.9591, Top-5 0.9990이었다.
- 이 수치는 견종 분류 성능이며 입양 성공을 의미하지 않는다.
- 다음 단계는 보호소 실데이터, 생활 조건 필터, 외부 검증, 챗봇 근거, 입양 후 결과 확인이다.
'실전 개발 노트 > 프로젝트·회고' 카테고리의 다른 글
| AI 산업안전 관제 프로젝트 설계 회고: YOLO·FastAPI·개인정보 보호까지 (0) | 2026.08.03 |
|---|---|
| React로 브라우저 OS를 만들었다: PocketDesk OS 창 관리자·파일 시스템 개발기 (0) | 2026.07.31 |