2026 AI·SW중심대학 디지털 경진대회 : SW부문

안녕하세요! 프로젝트를 세심하게 봐주셔서 감사합니다.
말씀해주신 모바일 접근성의 중요성에 저희도 공감하고 있습니다. 다만 저희가 로컬 PC를 선택한 것은 사용자가 PC를 통해서만 서비스를 이용하도록 하기 위한 것이 아니라, 센서 데이터 처리와 AI 추론, IoT 기기 제어를 담당하는 홈 서버로 활용하기 위해서입니다.
사용자는 모바일 기기에서 웹으로 접속해 현재 상태와 리포트를 확인하고, 자동화 조건을 설정하거나 기기를 원격으로 제어할 수 있도록 구성했습니다. 즉, 로컬 PC는 시스템 내부의 연산과 제어를 담당하고, 실제 사용자 인터페이스는 모바일 웹을 중심으로 설계했습니다.
로컬 서버 구조를 선택한 이유는 레이더와 센서 데이터를 실시간으로 처리할 수 있는 연산 성능을 확보하면서, 사용자의 생활 데이터를 외부 클라우드가 아닌 집 내부에서 처리해 개인정보 노출을 줄이기 위해서였습니다.
좋은 질문 감사드립니다. PiecePool 팀도 좋은 결과 있으시길 바랍니다!

안녕하세요. 저희가 중요하게 생각했던 의도를 정확하게 짚어주셔서 감사하게 읽었습니다!

먼저 로컬 LLM과 LangGraph 사용에 따른 응답 지연은 작업에 따라 처리 방식을 분리하여 대응했습니다. 예를 들어 수면 리포트 같이 즉시 결과가 필요하지 않은 작업은 실시간 요청과 분리해 비동기 잡으로 처리합니다.
또한 센서의 원본 데이터와 라이프 로그 전체를 LLM에 그대로 전달하지 않고, 백엔드에서 수치 계산과 데이터 집계를 수행한 후 전달합니다. LLM은 이를 바탕으로 자연어 리포트와 인사이트를 생성하는 역할에 집중하며, 이 방식으로 입력의 크기와 불필요한 도구 호출을 줄였습니다.

레이더 센서의 노이즈는 CFAR → DBSCAN → Motion Tracking의 순서로 처리합니다. 먼저 CFAR이 임계값을 기준으로 배경 잡음과 약한 반사점을 제거합니다. 이후 DBSCAN을 통해 공간적으로 가까운 포인트들을 하나의 객체 후보로 군집화하고, 주변에 충분한 포인트가 없는 고립된 값은 노이즈로 제외합니다. 마지막으로 Motion Tracking 단계에서 각 클러스터의 위치와 움직임을 이전 프레임과 연결합니다.
한 프레임에서만 순간적으로 발생한 신호로 사용자 상태로 판단하지 않고, 여러 프레임에서 이동 경로가 연속적으로 유지되는 객체를 중심으로 추적합니다. 반려동물의 움직임이나 다중 인원으로 여러 신호가 발생하는 상황에서도 포인트 하나하나를 독립적으로 해석하지 않고, 군집별 움직임과 프레임 간 연속성을 기준으로 각각의 대상을 구분해 추적하여 원활한 필터링이 가능합니다.

구체적이고 좋은 질문 덕분에 WaveHome의 처리 구조를 자세히 설명드릴 수 있었습니다. 준준티비 팀도 좋은 결과 얻으시길 응원하겠습니다!

안녕하세요, WaveHome에서 LangGraph 기반의 워크플로우 설계를 맡은 팀원입니다.🌊🌊
앞서 우리 팀원분이 잘 답변해주신 것처럼 현재는 지연과 실패에 대응하기 위해 비동기 job polling(요청 시점에 job을 큐에 올리고 별도 엔드포인트로 상태를 조회해, API가 LLM 응답을 기다리며 블로킹되지 않도록 분리) 방식을 사용하고 있습니다! 그리고 LangGraph의 ReAct 에이전트 루프가 컨텍스트 수집 단계에서 무한 루프나 불필요한 반복에 빠지지 않도록 도구 호출 루프 상한을 제한해 두었습니다. 채팅 기능의 경우에는 토큰 스트리밍으로 부분 응답을 먼저 내려줌으로써 지연을 줄였습니다. 또한 일부 기능의 경우 같은 날 여러 번 요청해도 실제로는 한 번만 LLM을 호출하고 나머지는 실시간 LLM 추론을 거치지 않고 캐싱된 응답을 즉시 반환하도록 했습니다. 관심 가져주셔서 감사하고 준준티비 팀도 화이팅하세용!!💪🏻

안녕하세요! 따뜻한 말씀 남겨주셔서 감사합니다.
WaveHome은 사용자가 매번 앱이나 리모컨을 조작하지 않아도, 일상적인 행동과 생활 패턴을 기반으로 공간이 자연스럽게 반응하도록 만드는 것을 목표로 했습니다. 특히 적외선 통신을 활용해 기존 IoT 기능이 없는 가전제품까지 함께 제어할 수 있도록 한 부분을 좋게 봐주셔서 감사합니다.
저희도 디딤팀의 늘보듬 프로젝트에 방문해서 살펴보겠습니다. 좋은 결과 얻으시길 응원하겠습니다!

안녕하세요! WaveHome의 구조를 좋게 봐주셔서 감사합니다.
현재 설정 화면에서는 한국어와 영어를 선택할 수 있도록 구성했지만, 채팅 API는 사용자가 입력한 text만 서버로 전송하며 설정에서 선택한 언어값을 함께 전달하지는 않습니다. 따라서 채팅, 리포트, 알림 및 화면 문구가 선택한 언어에 따라 변경되는 완전한 다국어 기능까지는 아직 구현하지 않았습니다.
말씀해주신 것처럼 사용자마다 사용하는 언어가 다를 수 있고, 특히 생활 리포트나 안전 관련 알림은 사용자가 정확히 이해할 수 있는 언어로 제공되는 것이 중요하다고 생각합니다. 향후에는 설정한 언어로 서비스를 사용할 수 있도록 확장할 필요가 있을 것 같습니다.

외국인이 한국 서비스를 이용하면서 겪는 언어와 정보 이해의 장벽을 해결하는 Hilol팀의 방향도 흥미롭게 느껴집니다. 좋은 의견 감사드리며, 좋은 결과 얻으시길 응원하겠습니다!

그리고 랜딩페이지 구현을 어떤 방식, 어떤 툴로 하셨는지 궁금합니다. 바이브코딩으로 작업하셨다면 어떤 식으로 프롬프트를 작성하셨을지 여쭙고 싶습니다. 너무 멋지게 잘 만드셨네요. 우승하셨으면 좋겠습니다.

Deleted Comment

랜딩 페이지는 React와 Tailwind CSS를 기반으로, Lenis의 부드러운 스크롤 레이어 위에 GSAP를 결합하여 카드 애니메이션 등의 스크롤 기반 인터랙션을 구현했습니다. 
첫 화면의 물결은 WebGL2 프래그먼트 셰이더로 직접 작성하여 실시간 마우스 감쇠 파동 시뮬레이션(높이맵) 굴절 효과를 합성해 표현했습니다. 바이브코딩을 활용했는데, 참고 레퍼런스 페이지(Shopify edition 페이지가 멋있어서 레퍼런스로 활용했습니다!)를 제공하고 디테일을 완성했습니다.

좋은 질문 감사드리며, 모두봄 팀도 좋은 결과 얻으시길 응원하겠습니다~!!☺️

안녕하세요!  이어서 디지털 트윈홈 페이지 관련해서 답변드리도록 하겠습니다.

3D 모델 만드느라 고생했었는데 봐주셔서 감사합니다 ㅎㅎ

3D 상태 동기화는 별도 웹소켓 채널이 아니라, 채팅의 SSE(Server-Sent Events) 스트림과 프론트 로컬 상태 저장소를 함께 쓰는 방식입니다. 사용자가 채팅으로 기기를 제어하면 에이전트가 control_device 툴을 호출하고, 백엔드가 실제 제어를 수행한 뒤 tool_end이벤트를 SSE로 내려줍니다. 프론트는 이 이벤트를 받아서 twinSceneStore에 장치 상태를 갱신하고, 모델이 렌더링 중인 상태를 즉시 다시 그립니다.

즉, 실시간 채널 = 채팅 SSE, 3D 반영 = 도구 결과를 받은 뒤 브라우저 내 상태 업데이트 구조입니다. WebSocket처럼 트윈 전용 양방향 소켓을 두지 않아도, 제어 직후 같은 턴 안에서 시각화가 맞춰지도록 설계했습니다.

웹소켓을 쓰면 반응성도 빨라지고 대용량 데이터도 쉽게 주고 받을 수 있다는 장점이 있겠지만, 이번에 제작한 프론트에서는 세션 유지와 관련된 문제 상황을 최대한 배제하기 위해서 기존에 있는 매커니즘을 그대로 이용한거라고 이해해주시면 됩니다.

사실 트윈홈은 이용자에게 실제로 어떻게 동작하는지 이해를 돕기 위해서 만들어낸 데모용 페이지입니다. 하지만 추후에 사용자가 집안의 이미지나 영상을 업로드 하면, 에이전트가 이를 분석해서 가구/가전 등의 배치를 디지털 트윈(=3D모델) 환경으로 그대로 이어주는 기능도 확장 가능성 부분에 기술해두었습니다. 만약 데모 뿐만이 아니라 실제 프로덕션 환경에서 더욱 정밀한 동기화가 필요하다고 생각되면 웹소켓도 당연히 고려하고 있습니다.

좋은 질문 감사드리며, 모두봄 팀도 좋은 결과 얻으시길 응원하겠습니다!

안녕하세요! '제어가 아니라 케어'라는 표현과, '사용자가 요청하지 않는 순간에 시스템이 먼저 움직인다'는 지점을 짚어주셔서 정말 반가웠습니다. 저희도 집이라는 공간에서는 잘못된 개입이 체감이 훨씬 크다고 생각합니다.

WaveHome도 비슷한 원칙으로 “제안은 자유롭게, 실행은 허용된 범위 안에서만” 을 나눴습니다. AI 코딩 도구가 코드를 제안하더라도 rm -rf 같은 터미널 명령은 사용자의 승인이나 정책(allowlist, sandbox 등) 없이는 실행하지 않는 것처럼, 저희는 추천(인사이트) 과 실제 가전 제어(인사이트 실행) 를 분리해 두었습니다.

수면/전력 리포트의 AI 인사이트는 먼저 카드 형태의 초안으로만 제공됩니다. 사용자가 직접 적용하기 전까지는 자동화 룰이나 일정에 반영되지 않습니다.

실제로 가전 기기가 제어되는 경로는 1. 사용자가 채팅으로 요청한 즉시 제어, 2. 사용자가 미리 등록한 자동화 룰(제스처, 스케줄, 장치 상태 조건)로 한정했습니다. 에이전트가 백그라운드에서 임의로 가전을 바꾸는 구조는 아닙니다. 자동화 룰은 일종의 실행 allowlist이고, 활성화 버튼으로 실행을 막는 식으로 안전장치를 두었습니다.

아직까지는 저희의 최종 목표인 완전한 무자각 케어기능으로 가기 위한 교두보 단계라고 생각해주시면 좋겠습니다.

안그래도 저도 AI가 만연한 시대에 글을 분석하면서 너무 도구에만 안주하는게 아닌가 하는 생각이 들었었는데, 그런 의미에서 올데이해피데이 팀의 주제도 참 매력적인거 같습니다. 남은 일정 잘 마무리하시길 응원하겠습니다!

네 안녕하세요! 먼저 프로젝트에 깊은 관심을 가져주시고 에이전트 구조까지 꼼꼼히 살펴봐주셔서 감사합니다.

먼저 한가지 오해만 바로잡고 답변드리겠습니다. 저희가 수면에서 사용하는 센서는 레이더 센서, WaveStation의 센서입니다.

이제 질문해주신 기기의 end-to-end 및 시스템 보안과 관련해서 답변드리겠습니다.
1. 레이더
레이더 센서에서 수집되는 포인트 클라우드 및 위상 데이터는 개인을 식별할 수 있을 정도의 민감 정보를 담고 있지 않습니다. 예를 들어서 포인트 클라우드는 사람의 대략적인 실루엣이나 움직임이 수백개의 점으로 표현되고, I/Q 위상정보는 단순한 실수 숫자 하나입니다. 레이더 센서의 장점 중 하나가 프라이버시 문제를 해소한다는 점이며 실제로 지하철역 공공 화장실과 같은 민감 장소에서도 활용됩니다.

2. WaveStation
마이크가 때문에 민감정보인 음성 신호가 포착된다고 생각하실 수 있습니다. 다만 음성 데이터는 코골이 소리 대역의 포함 정도가 단일 수치로 계산되며 음성 자체를 전송하진 않습니다.

3. 개인 건강 데이터 저장 및 보관
저희 시스템에서 모든 데이터는 중앙 PC(=맥미니)의 로컬 DB에만 저장됩니다. 그리고 에이전트 시스템을 운용하기 위해 기본적으로 로컬 LLM을 활용합니다. 따라서 DB의 정보가 PC외부로 유출되지 않는 구조입니다.

4. 백엔드 서버 - 에이전트 서버 연동
저희 시스템의 중요한 두 구성요소인 백엔드 서버와 에이전트 서버 간의 통신의 경우엔 DB의 정보를 서로 주고받습니다. 하지만 이 두 서버는 MSA구조로 단일 PC내에서 동작하기 때문에 간단한 방화벽 설정만으로도 중앙 PC 외부에서 접근이 불가능합니다.

그리고 추가적인 보안관련 솔루션도 고려중입니다. 예를 들어, 사용자가 홈 네트워크 외부에서 접속을 원하는 경우, 중앙 PC - 휴대폰연결에서 기본적으로 종단 간 암호화를 적용할 수 있습니다.

좋은 질문 감사드리고, 트루노스 팀의 정부 지원사업 자동 매칭 플랫폼도 꼭 방문해보겠습니다!

안녕하세요! 저희 시스템의 구조를 눈여겨 살펴봐주셔서 감사합니다.

말씀해주신 것처럼 저희는 생활 데이터가 집 밖으로 나가지 않도록, 백엔드와 에이전트 서버를 분리한 뒤 로컬에서 레이더 처리/RAG/LLM 추론까지 돌리도록 설계했습니다. 도메인별로 도구의 범위를 나눈 것도, 한 에이전트가 수면/전력/IoT를 한꺼번에 건드리지 않는 전문가로 작동하게 하려는 의도였는데 그 부분을 잘 짚어주셔서 반가웠습니다.

개인정보 민감 데이터는 자체 호스팅 임베딩을 쓰고, 클라우드 LLM은 품질이 중요한 일부 태스크에만 열어두신다는 GAON 팀의 선택도 옵셔널하게 사용자에게 외부 API를 사용할 수 있도록하는 저희 방향과 닮아 있어 흥미로웠습니다.

다문화 가정 학교 알림장 번역 지원이라는 주제도 실생활 접근성과 활용성이 분명해서 한번 방문해 보겠습니다. 좋은 결과 있으시길 응원하겠습니다!

안녕하세요! 

안그래도 저도 RoomFit 프로젝트를 눈여겨보고 있었습니다. 데모 영상을 보고 왔는데 RoomPlan을 활용해서 실시간으로 스캔한 방의 구조가 화면에 나타나는 방식과, 웹에서 이를 불러와서 입체적으로 나타내주는 부분에서 미려하다고 느껴졌습니다.

저희 프로젝트에서는 트윈홈이라는 데모 페이지로 비슷하게 입체 모델을 보여주는데 블렌더로 직접 모델링하고 배치도 수동으로 하느라 힘들었습니다. 그래서 저희 pdf 마지막에 트윈 홈 자동 생성을 추가 애플리케이션으로 적어놨었는데 RoomFit 프로젝트가 이것의 지향점이라는 느낌을 받았습니다.

그럼 이번대회 남은 일정 잘 마무리 하시길 바랍니다. 화이팅!!

네 안녕하세요. Sleep-Net의 구조를 상세히 봐주셨다니 감사합니다...!

먼저 임베딩 캐싱에 대해서 이해를 돕기 위해 좀 더 구체적으로 설명해드리겠습니다.

포인트넷은 레이더 센서의 20fps로 전송되는 포인트 클라우드 프레임을 인코딩하여 임베딩 벡터를 만들어 냅니다. 만약 캐싱을 하지 않는다면 이런 사태가 발생합니다.
1. 시계열 모델인 LSTM은 160프레임 분량의 임베딩 벡터가 필요합니다.
2. 캐싱이 되어있지 않다면 포인트넷은 저장된 포인트 클라우드 데이터를 매 프레임 추론마다 다시 계산합니다.
3. 결과적으로 1초당 159 * 20번의 중복된 포인트넷 연산이 발생합니다.

캐싱을 사용한다면 이렇게 됩니다.
1. 매 프레임 포인트 클라우드 결과가 들어오고, 포인트넷이 한 프레임 인코딩 후 캐시에 push(LRU 방식)합니다.
2. LSTM은 이미 계산된 256차원 임베딩 벡터 160개를 가져오기만 하면 됩니다.
3. 결과적으로 1초당 20프레임의 포인트넷 연산만 하면 됩니다.

결과적으로 캐싱을 사용하면 다음 이점이 있습니다.
1. 연산량을 99%이상 절감할 수 있습니다.
2. 캐싱을 한다면 포인트 클라우드(용량이 큼)를 따로 저장하지 않고 포인트넷 추론 후 해제해도 됩니다.

즉, 매 연속된 프레임 단위에서 최근 프레임들에 대해 캐싱을 수행하는 것입니다. 따라서, 캐시가 축출되는 경우는 '그 프레임이 더이상 쓰이지 않을 정도로 예전에 녹화된 정보일 때'뿐입니다. 사용자의 상태가 급격히 변한다면 그 정보가 연속된 캐시정보에 그대로 녹아들어가 있습니다.

여담으로 실제 추론에 걸리는 시간은 맥미니 M4 기준 약 0.5ms, 라즈베리파이5 기준 약 8ms가 소요됩니다. 이거 말고도 포인트넷 연산량을 줄이기 위해서 두 LSTM의 입력을 같은 임베딩 행렬에서 사용하는 등 여러 최적화 기법이 들어갔습니다.

아, 더 설명드리고 싶지만 글자수가 모자라네요 ㅎㅎ

아무쪼록, hoBIT-AX팀도 이번 대회 잘 마무리하셨으면 좋겠습니다. 응원합니다!

안녕하세요! 자세한 의견 남겨주셔서 감사합니다.
저희 팀도 스마트홈 서비스가 단순히 기기를 원격으로 제어하는 수준에 머물면 사용자가 지속적으로 사용할 이유가 부족하다는 점을 중요하게 생각했습니다. 그래서 편의성뿐만 아니라 수면 관리, 에너지 절감, 생활 패턴 기반 자동화처럼 사용자가 실제로 체감할 수 있는 문제를 해결하는 방향을 고민했습니다.

또한 설치와 기기 연동의 복잡성, 연결 안정성, 제조사별 호환성, 서비스 유지 비용 등 여러 측면도 함께 고려했습니다. 특히 스마트홈은 일상과 밀접하게 연결되는 만큼 기능이 많다는 것보다 사용자가 별도의 조작 없이도 안정적으로 사용할 수 있는지가 더 중요하다고 생각합니다.

마지막에 작성해 주신 관련 내용이 중간에 잘린 것 같습니다. 카메라와 센서로 수집되는 데이터에 대한 의견도 이어서 작성해 주시면 감사하겠습니다!