2분반-Brain Overflow - 편집 역사

Com239: /* 향후계획 */

2025-06-19T07:57:55Z

‎향후계획

Com239: /* 향후계획 */

2025-06-19T07:57:43Z

‎향후계획

Com239: /* 완료작품의 평가 */

2025-06-19T07:56:37Z

‎완료작품의 평가

Com239: /* Message Queue 시스템 구성 및 구현 기술 */

2025-06-19T07:52:55Z

‎Message Queue 시스템 구성 및 구현 기술

Com239: /* Message Queue 시스템 구성 및 구현 기술 */

2025-06-19T07:43:42Z

‎Message Queue 시스템 구성 및 구현 기술

Com239: /* Message Queue 시스템 구성 및 구현 기술 */

2025-06-19T07:42:52Z

‎Message Queue 시스템 구성 및 구현 기술

Com239: /* 시스템 설계 */

2025-06-19T07:42:13Z

‎시스템 설계

Com239: /* 세부기술 선택사항 */

2025-06-19T07:41:13Z

‎세부기술 선택사항

Com239: /* 구성원 및 추진체계 */

2025-06-19T07:38:44Z

‎구성원 및 추진체계

Com239: /* 개발 일정 */

2025-06-19T05:06:14Z

‎개발 일정

@@ 485번째 줄: / 485번째 줄: @@
 #프로젝트 통합 시 기능 간 의존성 및 충돌 문제: AI 모델, Inference 서버, WebGPU 뷰어, 채팅 시스템 등 개별 모듈은 독립적으로 완성도가 높았으나, 단일 레포지토리 통합(monorepo) 및 서브디렉토리 기반 모듈 구성 과정에서 연동 오류가 발생하였다. 특히 AI 모델의 inference 결과가 뷰어에 정상적으로 반영되지 않는 문제가 대표적이었다. 이러한 문제를 해결하기 위해서는 프로젝트 초기부터 모듈 간 통신 구조와 데이터 포맷 정의를 표준화하고, 통합 전 테스트용 샌드박스 환경을 구축하는 방식이 필요하다.
 #Message Queue의 분산 환경에서의 기능 구현:본 프로젝트는 메시지 큐의 핵심 기능과 실시간 처리 측면에서 높은 완성도를 보였으나, 분산 환경을 고려한 클러스터링과 레플리케이션 기능은 아직 미흡하였다. 단일 브로커 구조로 인해 장애 시 서비스 전체가 중단될 위험이 있으며, 메시지 복제와 동기화 메커니즘이 없어 데이터 유실 가능성도 존재한다. 향후에는 브로커 이중화, 로그 복제, 노드 간 상태 동기화 등을 통해 고가용성과 메시지 내구성을 확보할 수 있는 구조로 개선이 필요하다.
-이러한 점들을 기반으로, 추후에는 모델 성능 고도화 외에도 시스템 통합 테스트, MLOps 기반 자동화 구조, 실사용자 피드백 반영 등을 통해 기술적 완성도뿐만 아니라 서비스 품질 전반의 향상이 가능할 것으로 기대된다.#
+이러한 점들을 기반으로, 추후에는 모델 성능 고도화 외에도 시스템 통합 테스트, MLOps 기반 자동화 구조, 실사용자 피드백 반영 등을 통해 기술적 완성도뿐만 아니라 서비스 품질 전반의 향상이 가능할 것으로 기대된다.

@@ 484번째 줄: / 484번째 줄: @@
 #React 직접 구현 시도 실패 및 라이브러리 전환: 프로젝트 초기에는 React의 렌더링 구조(useState, useEffect 등)를 직접 구현하여 커스터마이징된 UI 라이브러리를 적용하고자 했으나, TypeScript 기반의 실제 프로젝트에 통합하는 과정에서 타입 호환성과 빌드 오류가 반복되었고, 공식 React의 방대한 타입 시스템과 맞지 않아 최종적으로는 공식 React 라이브러리로 전환하였다. 향후에는 자체 구현 방식의 한계를 고려하여, 성숙한 프레임워크를 기반으로 하는 UI 최적화 전략을 우선시할 필요가 있다.
 #프로젝트 통합 시 기능 간 의존성 및 충돌 문제: AI 모델, Inference 서버, WebGPU 뷰어, 채팅 시스템 등 개별 모듈은 독립적으로 완성도가 높았으나, 단일 레포지토리 통합(monorepo) 및 서브디렉토리 기반 모듈 구성 과정에서 연동 오류가 발생하였다. 특히 AI 모델의 inference 결과가 뷰어에 정상적으로 반영되지 않는 문제가 대표적이었다. 이러한 문제를 해결하기 위해서는 프로젝트 초기부터 모듈 간 통신 구조와 데이터 포맷 정의를 표준화하고, 통합 전 테스트용 샌드박스 환경을 구축하는 방식이 필요하다.
-이러한 점들을 기반으로, 추후에는 모델 성능 고도화 외에도 시스템 통합 테스트, MLOps 기반 자동화 구조, 실사용자 피드백 반영 등을 통해 기술적 완성도뿐만 아니라 서비스 품질 전반의 향상이 가능할 것으로 기대된다.
+#Message Queue의 분산 환경에서의 기능 구현:본 프로젝트는 메시지 큐의 핵심 기능과 실시간 처리 측면에서 높은 완성도를 보였으나, 분산 환경을 고려한 클러스터링과 레플리케이션 기능은 아직 미흡하였다. 단일 브로커 구조로 인해 장애 시 서비스 전체가 중단될 위험이 있으며, 메시지 복제와 동기화 메커니즘이 없어 데이터 유실 가능성도 존재한다. 향후에는 브로커 이중화, 로그 복제, 노드 간 상태 동기화 등을 통해 고가용성과 메시지 내구성을 확보할 수 있는 구조로 개선이 필요하다.

@@ 468번째 줄: / 468번째 줄: @@
 | RAFT 로그 일치율 || 다중 노드 로그 비교 || 3회 이상 동기화 후 로그 일치율 || ≥ 95% || 5.0 || 96.2%
 |-
-| 메시지큐 처리 지연 || 부하 시뮬레이션 || 평균 처리 지연 || ≤ 50ms || 5.0 || 32.5ms
+| 메시지큐 처리 지연 || 부하 시뮬레이션 || End-to-end 평균 처리 지연 || 기존 메세지큐 기준 (100 TPS) 유사한 성능 || ≥ 80 || 157
 |-
 | Virtual Thread 처리량 증가 || 비교 실험 || 기존 ThreadPool 대비 동시 처리량 증가율 || ≥ 20% || 5.0 || +31%
@@ 474번째 줄: / 478번째 줄: @@
 | 웹 UI 로딩 속도 || 웹 성능 지표 (LCP) || 최초 로딩 시간 || ≤ 1.0초 || 5.0 || 0.82초
 |}
 ===향후계획===

@@ 344번째 줄: / 344번째 줄: @@
 ====Message Queue 시스템 구성 및 구현 기술====
- 이 메시지 브로커는 Java를 기반으로 core, server (broker), client, spring-zoomq 서브모듈을 가진 Gradle 멀티 모듈 프로젝트로 구현되었다. 기존의 메세지큐 라이브러리는 브로커 측 구현을 위한 라이브러리가 없고, 전체 스펙을 직접 구현해야 하기 때문에, 소켓 연결과 프로토콜을 저수준에서 구현했다. 브로커는 독립 실행이 가능한 애플리케이션으로 구성되며, Docker 이미지로 패키징되어 Docker Hub에 배포된다. 실행 시 환경변수를 통해 사용자 인증 정보를 필수로 입력받고, 이후 인증이 완료된 연결에 대해서만 세션을 유지한다.
+이 메시지 브로커는 Java를 기반으로 core, server (broker), client, spring-zoomq 서브모듈을 가진 Gradle 멀티 모듈 프로젝트로 구현되었다. 기존의 메세지큐 프로토콜을 지원하는 라이브러리는 브로커 측 구현을 위한 라이브러리가 없을 뿐더라 전체 스펙을 직접 구현해야 하기 때문에, 소켓 연결과 프로토콜을 저수준에서 직접 구현했다.
- 위에서 언급했든 STOMP나 AMQP 같은 기존 메시지 프로토콜을 사용하지 않는다. 이에 따라 JSON 기반 메세지 프레임 및 타입을 설계하고, TCP 기반 Socket을 사용한 프로토콜을 core 모듈에 구현하였다. 이 메시지는 메시지 ID, 타입, TTL, 우선순위 등 메타데이터와 실제 payload를 포함하며, 추적과 오류 대응, 만료 처리에 유연하게 대응할 수 있도록 구성되어 메세지 전달 보장 at-least-once를 보장한다.
- client는 메세지를 발행하는 Producer와 소비하는 Consumer를 구현하였다. 해당 client는 연결, 재연결, 중지/재시작, ACK/RETRY, publish/subscribe 등 메시지큐 통신에 필요한 기능을 추상화하여 유지보수에 용이하게 만들었으며, 개발자가 직접 네트워크 로직을 작성하지 않고도 쉽게 통합할 수 있도록 돕는다. 기본적으로 메세지는 push 방식으로 consumer에게 전달되지만, back-pressure를 예방하기 위해 consumer 측에서 메세지 수신을 중지 및 재개할 수 있도록 설계하였다.  또한 사용의 편의성을 위해  Spring용 전용 라이브러리를 제공한다. 해당 라이브러리는 기존 메세지큐 (kafka, rabbitmq)를 벤치마킹하여 @ZooListener 어노테이션을 통해 쉽게 메세지를 수신하고, ZooTemplate.converAndSend를 통해 쉽게 메세지를 송신할 수 있도록 하였다.
+위에서 언급했든 STOMP나 AMQP 같은 기존 메시지 프로토콜을 사용하지 않는다. 이에 따라 JSON 기반 메세지 프레임 및 타입을 설계하고, TCP 기반 Socket을 사용한 프로토콜을 core 모듈에 구현하였다. 이 메시지는 메시지 ID, 타입, TTL, 우선순위 등 메타데이터와 실제 payload를 포함하며, 추적과 오류 대응, 만료 처리에 유연하게 대응할 수 있도록 구성되었다. 프로토콜은 메세지 전달 보장 at-least-once를 보장하며, 연결, 재연결, 중지/재시작, ACK/RETRY, publish/subscribe 등 메시지큐 통신에 필요한 기능을 추상화하여 유지보수에 용이하게 만들고, 개발자가 직접 네트워크 로직을 작성하지 않고도 쉽게 통합할 수 있도록 하였다. Producer-Broker, Consumer-Broker간의 연결마다 상세 프로토콜이 다르므로, 공통 추상 클래스를 정의하고 인터페이스에 따라 기능을 제한하는 방식으로 구현하였다.
- 메시지는 topic 기반 큐에 저장되고, prefix 매칭을 통해 단일 혹은 복수 큐에 fan-out 방식으로 전달된다. 구독 중인 consumer가 여러 명인 경우 round-robin 방식으로 메시지가 분산되며, 한번 전달된 메시지는 삭제된다.
- 이처럼 소프트웨어 설계는 기술적 기반의 선택부터 배포 전략, 프로토콜 구성, 개발 편의성 확보까지 전체적인 관점에서 일관된 방향성을 갖고 진행되었으며, 메시지큐 시스템을 실용적이고 범용적으로 활용하기 위한 기반을 마련하고 있다.
+브로커는 독립 실행이 가능한 애플리케이션으로 구성되며, Docker 이미지로 패키징되어 Docker Hub에 배포된다. 실행 시 환경변수를 통해 사용자 인증 정보를 필수로 입력받고, 이후 인증이 완료된 연결에 대해서만 세션을 유지한다. Producer (client)로부터 전송받은 메세지를 topic 기반으로 알맞은 큐에 라우팅하고, 큐에 메세지를 보관 및 해당 큐를 구독중인 Consumer (client)에 메세지를 전송한다. 이때 하나의 큐에는 여러 Consumer가 존재하여 Round-Robin 방식으로 선택되어 전달되며, 메세지는 전송 완료가 확인되면 큐에서 삭제된다.
 ===성능 분석 및 검증===

@@ 344번째 줄: / 344번째 줄: @@
 ====Message Queue 시스템 구성 및 구현 기술====
-  이 메시지 브로커는 Java를 기반으로 core, server (broker), client, spring-zoomq 서브모듈을 가진 Gradle 멀티 모듈 프로젝트로 구현되었다. 기존의 메세지큐 라이브러리는 브로커 측 구현을 위한 라이브러리가 없고, 전체 스펙을 직접 구현해야 하기 때문에, 소켓 연결과 프로토콜을 저수준에서 구현했다. 브로커는 독립 실행이 가능한 애플리케이션으로 구성되며, Docker 이미지로 패키징되어 Docker Hub에 배포된다. 실행 시 환경변수를 통해 사용자 인증 정보를 필수로 입력받고, 이후 인증이 완료된 연결에 대해서만 세션을 유지한다.
+ 이 메시지 브로커는 Java를 기반으로 core, server (broker), client, spring-zoomq 서브모듈을 가진 Gradle 멀티 모듈 프로젝트로 구현되었다. 기존의 메세지큐 라이브러리는 브로커 측 구현을 위한 라이브러리가 없고, 전체 스펙을 직접 구현해야 하기 때문에, 소켓 연결과 프로토콜을 저수준에서 구현했다. 브로커는 독립 실행이 가능한 애플리케이션으로 구성되며, Docker 이미지로 패키징되어 Docker Hub에 배포된다. 실행 시 환경변수를 통해 사용자 인증 정보를 필수로 입력받고, 이후 인증이 완료된 연결에 대해서만 세션을 유지한다.
-  위에서 언급했든 STOMP나 AMQP 같은 기존 메시지 프로토콜을 사용하지 않는다. 이에 따라 JSON 기반 메세지 프레임 및 타입을 설계하고, TCP 기반 Socket을 사용한 프로토콜을 core 모듈에 구현하였다. 이 메시지는 메시지 ID, 타입, TTL, 우선순위 등 메타데이터와 실제 payload를 포함하며, 추적과 오류 대응, 만료 처리에 유연하게 대응할 수 있도록 구성되어 메세지 전달 보장 at-least-once를 보장한다.
+ 위에서 언급했든 STOMP나 AMQP 같은 기존 메시지 프로토콜을 사용하지 않는다. 이에 따라 JSON 기반 메세지 프레임 및 타입을 설계하고, TCP 기반 Socket을 사용한 프로토콜을 core 모듈에 구현하였다. 이 메시지는 메시지 ID, 타입, TTL, 우선순위 등 메타데이터와 실제 payload를 포함하며, 추적과 오류 대응, 만료 처리에 유연하게 대응할 수 있도록 구성되어 메세지 전달 보장 at-least-once를 보장한다.
-  client는 메세지를 발행하는 Producer와 소비하는 Consumer를 구현하였다. 해당 client는 연결, 재연결, 중지/재시작, ACK/RETRY, publish/subscribe 등 메시지큐 통신에 필요한 기능을 추상화하여 유지보수에 용이하게 만들었으며, 개발자가 직접 네트워크 로직을 작성하지 않고도 쉽게 통합할 수 있도록 돕는다. 기본적으로 메세지는 push 방식으로 consumer에게 전달되지만, back-pressure를 예방하기 위해 consumer 측에서 메세지 수신을 중지 및 재개할 수 있도록 설계하였다.  또한 사용의 편의성을 위해  Spring용 전용 라이브러리를 제공한다. 해당 라이브러리는 기존 메세지큐 (kafka, rabbitmq)를 벤치마킹하여 @ZooListener 어노테이션을 통해 쉽게 메세지를 수신하고, ZooTemplate.converAndSend를 통해 쉽게 메세지를 송신할 수 있도록 하였다.
+ client는 메세지를 발행하는 Producer와 소비하는 Consumer를 구현하였다. 해당 client는 연결, 재연결, 중지/재시작, ACK/RETRY, publish/subscribe 등 메시지큐 통신에 필요한 기능을 추상화하여 유지보수에 용이하게 만들었으며, 개발자가 직접 네트워크 로직을 작성하지 않고도 쉽게 통합할 수 있도록 돕는다. 기본적으로 메세지는 push 방식으로 consumer에게 전달되지만, back-pressure를 예방하기 위해 consumer 측에서 메세지 수신을 중지 및 재개할 수 있도록 설계하였다.  또한 사용의 편의성을 위해  Spring용 전용 라이브러리를 제공한다. 해당 라이브러리는 기존 메세지큐 (kafka, rabbitmq)를 벤치마킹하여 @ZooListener 어노테이션을 통해 쉽게 메세지를 수신하고, ZooTemplate.converAndSend를 통해 쉽게 메세지를 송신할 수 있도록 하였다.
-  메시지는 topic 기반 큐에 저장되고, prefix 매칭을 통해 단일 혹은 복수 큐에 fan-out 방식으로 전달된다. 구독 중인 consumer가 여러 명인 경우 round-robin 방식으로 메시지가 분산되며, 한번 전달된 메시지는 삭제된다.
+ 메시지는 topic 기반 큐에 저장되고, prefix 매칭을 통해 단일 혹은 복수 큐에 fan-out 방식으로 전달된다. 구독 중인 consumer가 여러 명인 경우 round-robin 방식으로 메시지가 분산되며, 한번 전달된 메시지는 삭제된다.
-  이처럼 소프트웨어 설계는 기술적 기반의 선택부터 배포 전략, 프로토콜 구성, 개발 편의성 확보까지 전체적인 관점에서 일관된 방향성을 갖고 진행되었으며, 메시지큐 시스템을 실용적이고 범용적으로 활용하기 위한 기반을 마련하고 있다.
+ 이처럼 소프트웨어 설계는 기술적 기반의 선택부터 배포 전략, 프로토콜 구성, 개발 편의성 확보까지 전체적인 관점에서 일관된 방향성을 갖고 진행되었으며, 메시지큐 시스템을 실용적이고 범용적으로 활용하기 위한 기반을 마련하고 있다.
 ===성능 분석 및 검증===

@@ 259번째 줄: / 259번째 줄: @@
 ***결과를 MQ에 publish 또는 Redis에 캐싱 후 notification trigger
 *메시지 큐 시스템 (Message Queue)
-**기술 스택: RabbitMQ
+**기술 스택: RabbitMQ, ZooMQ (본 프로젝트에서 구현한 커스텀 메세지 큐)
 **역할:
 ***AI Inference 요청 및 처리 흐름을 비동기적으로 분리

@@ 219번째 줄: / 219번째 줄: @@
 *시스템 설계 및 연산 구조
-**RabbitMQ 기반 메시지 큐
+**메세지 큐: RabbitMQ 및 ZooMQ(현 프로젝트에서 구현한 메세지큐)
-***모델 추론 요청은 MQ를 통해 분산 처리되며, 요청 처리량 증가에도 안정적으로 대응할 수 있다. → 비동기 처리, 오류 격리, 재시도 정책이 설계에 포함됨
+***비동기 처리 및 고가용성을 위해 자체 구현한 Zoo Message Queue 및 기존의 RabbitMQ를 적용하였다. 모델 추론 요청은 MQ를 통해 분산 처리되며, 요청 처리량 증가에도 안정적으로 대응할 수 있다. → 비동기 처리, 오류 격리, 재시도 정책이 설계에 포함됨
 **Java Virtual Thread (JDK 21)
 ***서버는 가상 스레드를 사용하여 수천 개의 경량 스레드를 실행하며, 고동시성 처리에 최적화되었다.

@@ 178번째 줄: / 178번째 줄: @@
 | 권준호 || 서비스 개발 / MLOps·RAFT || RAFT 알고리즘 구현, Inference 파이프라인 구성
 |-
-| 김혜주 || 서비스 개발 / 백엔드 || MQ(Message Queue)
+| 김혜주 || 서비스 개발 / 백엔드 || MQ(Message Queue) 구현 (Broker server, client class)<br/> Spring 라이브러리 배포
 |-
 | 석우진 || 서비스 개발 / 인프라·서버 성능 최적화 || 서버 구조 설계<br/>Java Virtual Thread 기반 서버 동시성 구조 설계

@@ 117번째 줄: / 117번째 줄: @@
 ===기술개발 일정 및 추진체계===
 ====개발 일정====
-내용
+. MRI팀
 ====구성원 및 추진체계====
 본 프로젝트는 총 6인의 팀원으로 구성되었으며, 기술 영역에 따라 MRI 팀과 서비스 개발 팀으로 역할을