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

안녕하세요, 모찌 팀입니다! 고혈압 노인 돌봄이라니 대상이 구체적이라 방향성이 명확해서 좋네요. 

질문 주신 부분에 대해서는 두 방식이 함께 사용됩니다.
우선 사용자가 백탭이나 공유시트로 내용을 저장하면, AI가 내용을 분석해 할 일·일정·지식·기록을 필요한 만큼 추출하고, 필요한 정보까지 정리합니다.
이후에는 사용자가 검색하거나 채팅으로 요청했을 때 관련 기록을 찾아주기도 하고, 적절한 시점에 모찌가 먼저 알림으로 기록을 꺼내주기도 합니다. 특히 사용자가 직접 찾아야만 하는 구조보다는, 필요한 순간에 먼저 떠올려주는 경험에 더 중점을 두고 있습니다.
개인화 추천은 별도의 학습보다는 사용자의 저장 이력과 액션 이력등의 Context 를 주입하는 방식으로 제공하고 있습니다.

시니어 대상이면 능동 회수 쪽이 특히 중요할 것 같은데, 저희도 들러서 보고 의견 남기겠습니다. 좋은 결과 있으시길 저희도 응원하겠습니다!

안녕하세요! 모찌를 꼼꼼히 봐주셔서 감사합니다. 특히 Reminder Agent의 의도를 정확히 알아봐 주셔서 반가웠어요!

우선 Chat Agent는 정확한 키워드가 없어도 최근 기록과 저장된 내용을 함께 비교해 관련 기록을 찾도록 설계했습니다. 내부 테스트에서는 전체 검색 성공률이 약 95.8%였고, 여러 기록을 한꺼번에 찾아야 하는 질문도 약 89.6%까지 확인했습니다! 아직 베타 테스트 기반 결과라, 실제 사용 환경에서도 계속 검증해 나갈 예정입니다.
또한 second brain은 모찌에 쌓인 기록을 ChatGPT나 Claude에서도 필요할 때 꺼내 쓸 수 있도록 연결하는 방향인데요! 단순히 모든 데이터를 넘기기보다는 사용자 권한과 민감 정보 보호를 중요하게 고려해서 필요한 정보만 넘기는 것을 우선으로 다뤄보려고 해요. 

PiecePool도 방문해서 살펴보겠습니다. 좋은 질문과 응원 감사합니다! 🔥

그리고 디자인적인 점에서 궁금한 점이 3~6페이지 느낌을 내려면 어떤 툴로 작업을 하면 되는 건지 여쭙고 싶습니다..! 피그마로 하시는 건가요??

안녕하세요! 반갑습니다 ㅎㅎ 역할 경계 잡는 게 골치라는 말씀 공감합니다.

Q1.  키워드랑 의미 검색을 하이브리드로 섞으시는 건가요?
네, 하이브리드 맞습니다. 키워드랑 벡터를 각각 돌린 뒤 RRF(k=60)로 섞고, 그 위에 Voyage rerank-2.5를 한 번 더 재정렬 했습니다. 가중치는 따로 안 두지 않고, 두 방식의 순위 정보만 활용했습니다. 임베딩은 voyage-4-large(1024차원) 모델을 사용했고, pgvector의 HNSW 인덱스로 저장해 검색했습니다.
검색 관련하여 더 궁금하시다면, 슬라이드 36, 37페이지에 실험 관련한 더 디테일한 내용이 담겨있으니 확인 해보셔도 좋을것  같아요 ㅎㅎ 

Q2. Gemini는 Vertex AI로 붙이신 이유가 따로 있나요?
Vertex는 특별한 선택이라기보다 인프라가 이미 GCP에 있어서 자연스럽게 Google Cloude 에 있는 서비스로 이용 했습니다.
굳이 이점을 뽑으라면, VM에 서비스계정(IAM)을 붙이면 키파일 없이 ADC로 인증되는게 컸습니다

Q3.
피그마로 작업해서 이미지로 추출해 넣었습니다. 초반 페이지에 임팩트를 주고 싶어 조금 과감한 시도를 해보았는데 좋게 봐주셔서 감사합니다!!


모두봄도 들러서 의견 남기겠습니다. 좋은 결과 있으시길!

감사합니다! 
사용해보고 싶다고 말씀해주셔서 정말 기분 좋습니다😊

저희는 ‘나중에 필요할 것 같아 저장해둔 스크린샷이나 메모를 다시 찾지 못하는 경험’에서 얻은 아이디어를 기반으로 만들어본 서비스입니다.
그래서 파편적인 기록도 AI가 알아서 정리하고, 필요할때 알려주는 서비스를 만들고 싶었거든요 ㅎㅎ

Piecepool 도 LLM Wiki, Second brain 처럼 파편적인 기록을 AI가 활용 가능한 정보로 정리해준다는 점에서 ,
저희와 비슷한 부분도 있는것 같아서 반갑네요.

Piecepool 팀도 응원하겠습니다! 극찬 감사드립니다🙌

안녕하세요, 디딤팀! 모찌가 짚고자 했던 문제에 직접 공감해 주셔서 감사합니다. 

말씀해 주신 필기 사진이나 장소, 여행 팁처럼 분명 저장해 뒀는데 정작 필요한 순간에는 떠오르지 않는 경험에서 저희도 모찌를 기획하게 됐어요 ㅎㅎ 그래서 기록을 잘 정리하는 것보다, 필요한 순간에 자연스럽게 다시 꺼내주는 데 더 집중하고 있습니다.

라이프로그를 바탕으로 청소년의 위기 신호를 조기에 발견하고 여러 AI 에이전트가 함께 돕는 늘보듬의 접근도 의미 있게 느껴지네요. 특히 놓치기 쉬운 신호를 먼저 발견한다는 점에서 모찌와 맞닿은 부분도 있는 것 같아요. 늘보듬 프로젝트에도 방문해서 살펴보겠습니다. 디딤팀도 좋은 결과 있으시길 바랍니다!

안녕하세요! 모찌의 저장 방식과 검증 과정까지 자세히 봐주셔서 감사합니다.

우선 현재 검색과 채팅은 LLM과 의미 기반 검색을 함께 사용하고 있어, 한국어로 저장된 기록을 영어 등 다른 언어로 질문해도 의미를 연결해 찾을 수 있는 구조입니다. 다만 아직 다국어 질의를 별도로 최적화하거나 언어별 정확도를 측정한 단계는 아니라서, 완전한 다국어 지원이라고 말씀드리기보다는 기본적인 교차 언어 검색이 가능한 상태에 가깝다고 할 수 있을 것 같아요. 

말씀해 주신 계약서나 안내문처럼 외국인 사용자에게 중요한 문서는 향후 다국어 검색뿐 아니라 번역·핵심 내용 설명까지 함께 제공하면 너무 좋을 것 같다는 생각이 드네요! 좋은 아이디어가 됐습니다 ㅎㅎ

외국인이 한국 서비스를 이용하며 겪는 언어와 정보 이해의 장벽을 해결하는 Hilol의 방향도 흥미롭네요. 저희도 방문해서 살펴보겠습니다. 응원 감사드리고 Hilol 팀도 화이팅입니다!

안녕하세요! 반갑습니다 ㅎ ㅎ
요약과 원본의 관계는 저희도 계속 고민하던 부분이에요. 저희는 요약을 원본 대신 보는 게 아니라, 원본으로 다시 데려가는 입구로
보는 방식으로 접근했습니다. 상세 화면에 요약이랑 원본 캡처가 늘 같이 떠 있고 요약만 남는 화면이 아예 없어요. 요약을 누르든 검색으로 들어오든 결국 원본에 도착합니다. 
검색이 데려가는 곳도 요약이 아니라 근거가 된 원본이에요. 답변에 뱃지가 붙어서 바로 원본으로 넘어가고요. 그래서 요약은 "원본 안 봐도 되게"
만드는 것보다는 필요할 때 원본을 다시 찾아주는 인덱스에 가까워요. 
저흰 올데이해피데이팀처럼 원문을 계속 붙들게 하는 장치는 없는데, 관심이 '읽는 힘'보단 '놓친 걸 다시 꺼내는' 쪽이라 그래요. 방향이 반대라 오히려 재밌네요 ㅎㅎ
저희도 한 번 들러서 코멘트 남겨보도록 할게요 ㅎㅎ 남은 일정 화이팅 하시길 바랍니다!

안녕하세요! 저희가 제일 오래 고민한 부분이네요 ㅎㅎ 라이브 환경에서 그간 실측한 숫자로 답변드립니다.
영상까지 봐주시고 질문 해주시니 너무 감사하네요..

결론부터 말씀드리면 Redis 캐시는 일부러 안 넣었습니다. 레이턴시를 단계별로 측정해보니 캐시로 풀리는 위치가 아니었어요. 무거운 작업(분석, 요약, 임베딩)은 저장 시점에 전부 끝내둬서, 검색할 때 DB에서 걸리는 시간은 키워드 1.2ms, 벡터(pgvector HNSW) 1.7ms로 사실상 0입니다. 남는 건 쿼리 임베딩 p50 356ms, 리랭커(rerank-2.5) p50 363ms 외부 API 두 번뿐인데, 여긴 Redis로 줄일 수 없는 구간이고요. 개인 기록 검색은 같은 질문이 드물고 방금 저장한 캡처가 바로 검색돼야 해서, 결과를 캐싱하면 오래된 걸 보여줄 위험만 커지더라구요..

1000자가 맥스라 이어서 답변드리겠습니다!

말씀하신 애매한 질문은 에이전트가 최대 4개 검색어로 쪼개 한 번에 검색하고, RRF(k=60)로 합쳐 리랭킹 한 번으로 끝냅니다. TOP_K=25도 1,045건 코퍼스로 실측해 정했고(recall@8 0.800→@25 0.958), 리랭커가 R@1을 0.15→0.43으로 올려 재검색을 없애주니 363ms가 감수할 만한 trade-off라고 판단했어요. 외부 API가 죽으면 키워드로 폴백합니다.

latency 전략의 절반은 iOS에 있습니다. 모든 기록이 폰 내부의 로컬 DB(Realm)에 먼저 저장되고, 목록과 열람은 서버를 기다리지 않고 비행기 모드에서도 저장과 조회가 다 됩니다. 검색도 두 단이라 타이핑 중엔 로컬 매칭이 즉시 뜨고,  Debounce 로 서버에서 Vector Search가 보충합니다. 좋게 봐주신 백탭, 공유 시트 캡처도 앱을 안 켜도 공유 저장 공간(App Group)에 먼저 담기고 서버 전송은 큐에 담겨 앱을 켰을때 다시 요청 합니다. 전송이 실패해도 캡처  id 로 찾아 재시도가 같은 기록으로 합쳐져 중복이 없고, 앱을 지웠다 깔아도 서버에 올라간 기록은 로그인하면 복구되는 구조에요. 인터넷 연결이 안되는 상황에서도 기록을 확인 할 수 있어야한다고 판단했고, 기록 자체가 사라지는것은 치명적인 결함이라고 생각하여, 로컬 DB를 설계하여 두었습니다.


좋은 질문 감사드리며 추가적인 질문은 언제든 환영입니다! 
응원합니다. 좋은 결과 있으시길!

산출물을 이렇게 깊이 봐주시고, 저희가 가장 오래 고민한 지점을 정확히 짚은 질문까지 남겨주셔서 감사합니다.
RoomFit AI에서 LLM과 규칙 엔진의 책임을 나누신 설계를 보며 저희도 같은 종류의 고민을 했던 터라, 질문이 더 반가웠습니다.

 1. 후보 기록과 알림 시점을 정하는 방식

 말씀하신 두 구조가 트랙별로 다르게 섞여 있습니다. 능동 회수는 세 트랙으로 나뉘는데, 시간 앵커가 있는 트랙(일정·마감 역산, 지식의 간격 반복 )은 "규칙이 거르고 LLM이 설계"합니다. 분석이 끝난 기록에서 미래 날짜를 가진 일정/할일과 지식(저장 단계에서 분류된)만 결정적 eligibility 게이트로 통과시키고, 통과한 건만 LLM 플래너가 발송 스케줄을 설계합니다. 이때 플래너는 단발 호출이 아니라 tool-loop로 돌아서, 같은 날 예정된 다른 알림을 직접 조회해 묶거나 시각을 조정합니다. 설계 결과는 stages DSL로 받아 스키마 검증을 통과해야만 저장되고, 발송 시각 계산은 DB를 모르는 순수함수로 분리해 단위테스트합니다.

 질문 주신 맥락 회수 트랙은 반대입니다. 개입 시점을 규칙으로 따로 정하지 않고, 사용자의 새 저장 이벤트 자체가 트리거입니다. 새 기록이 저장되면 임베딩 ANN으로 과거 기록 40건을 overfetch하고, archived와 근중복(cos 0.92 이상)만 얇게 거른 top-10을 LLM 선별 게이트에 넘겨 "지금 다시 떠오를 가치가 있는 최대 1건"만 채택시킵니다.

이렇게 설계한 이유는 실데이터 백테스트에서 나온 발견 때문입니다. 코사인 유사도가 회수 품질의 판별자가 되지 못했습니다. 좋은 회수와 나쁜 회수의 코사인 분포가 완전히 겹쳤고(최고 유사도가 오히려 나쁜 케이스), 임계값을 조여도 정밀도 64%가 천장이었습니다. 

"조거팬츠를 고르다가 다른 조거팬츠를 저장"은 회수 가치가 있고 "조거팬츠를 보다가 러닝화를 저장"은 없는데, 이 구분은 임베딩 거리로는 불가능했고 LLM만 해냈습니다. 그래서 코사인은 후보를 추리는 임계치로만 쓰고, 채택/거절 판단과 메시지 작문(알림 멘트 생성)은 LLM이 합니다.

사용자 액션 이력은 reranking 신호가 아니라 결정적 게이트로 씁니다. 알림 탭의 "그만 볼래요" 버튼은 그 기록의 활성 알림 계획 전체 취소,  열어봤으면 양성 신호로 기록하면서 잊혀가던 지식의 간격 반복 계획을 다시 살립니다. 반대로 "안 누른 것"은 부정 신호로 취급하지 않기로 명시했는데, 알림을 보고 클릭하지 않더라도 "아 맞다"만 해도 회수의 목적은 달성이기 때문입니다.

 2. 근거 충실성과 알림 피로도 평가

정답 라벨이 없는 문제라 이진 정확도 대신 인과적 백테스트로 평가했습니다. 실사용 168건의 기록에서, 각 기록의 저장 시점마다 "그 시점까지의 과거만으로" 어떤 회수가 떴을지 재구성하고 LLM-as-a-judge 정성평가를 돌렸습니다. 근거 충실성의 기준은 좁게 잡았습니다. 모찌가 아는 유일한 사실은 "사용자가 이 기록을 저장했다"뿐이므로 저장 동기나 감정을 추측하는 문장을 금지하고, 과거 기록의 구체 명사를 반드시 앵커로 쓰게 했으며, 알림을 탭하면 단건 상세만 열리는 앱이라 "비교해볼까요/묶어볼까요"처럼 앱에 없는 기능을 제안하거나, “이거 찾고 계시죠!” 라는 단언적인 멘트를 최악의 실패로 정의했습니다. 프롬프트를 여섯 번 개정하며 이 실패율을 추적해 초기 51%에서 0으로 잡았고, 튜닝에 쓰지 않은 다른 계정에 무튜닝 적용해도 누수 0인 것까지 확인했습니다. 문장이 한 패턴으로 수렴하는 것도 실패로 봐서, 최빈 패턴 비율 54%→22%, 어미 종류 13→34종으로 다양성을 함께 측정했습니다.

알림 피로도는 LLM에게 맡기지 않았습니다. 경량 모델의 비결정성과 워커 동시성 때문에 쿨다운·dedup류는 결정적 백스톱으로 남겼습니다. 계정당 회수 최소 간격 6시간, 같은 기록 재회수 7일 금지, dismiss한 intent 7일 쿨다운, 그리고 같은 날 마감 알림이 있으면 맥락 회수는 다음 날로 양보합니다(마감이 회수보다 우선). 게이트의 기본값도 "애매하면 보내지 않는다"입니다. 설계된 예정 알림은 채팅에서 조회,연기,취소할 수 있게 해서 마지막 결정은 사용자에게 뒀습니다.

사견으로는 Agent 를 만들때 가장 중요한것이 실험이라고 생각합니다. 일반적인 ML 평가나, 이진분류와 같은 지도 학습이 가능한 모델들과 달리, 정성적인 평가가 기준이 될수 밖에 없는 지점들이 상당히 많고 해당 부분을 실험과 유저 만족도(가령 CTR-클릭률 또는 리텐션 등으로 가늠 할 수 있는)를 활용하여 지속적으로 성능이 장기 우상향 할 수 있어야 한다고 생각합니다. 출시되지 못한 서비스는 사실 유저 만족도라고 할만한것들이 부재하다 보니, 저희는 주변 지인들을 20명정도 베타 테스트하여 데이터들을 수집하고 모아 이를 LLM as a judge 를 통해 개선루프를 돌렸습니다.

말씀주신 RAG 검색의 평가가 확실히 까다롭다고 생각하는데 LLM 이 어떤 Tool 로 어떤 데이터(Context)를 찾아야 한다는것을 사람손으로 미리 정한다는것이  어렵기 때문인데요,
따라서 성능이 좋은 AI Agent(가령  Claude code 의 Opus, Fable) 을 잘 활용하여  라벨링된 데이터를 증강하거나 결과를 평가시키는것이 중요하다고 생각됩니다.


다만, ‘평가하는 AI Agent’ 가 ‘우리가 튜닝한 AI Agent’들보다 ‘성능이 좋기 때문에 평가 할 수 있다’ 라는 전제를 깔기 보단,  "생성보다 검증이 쉽다"는 비대칭이 있으니, 이 부분을 고려하여 설계 했던것 같습니다. judge에게 "좋은 결과인가"를 통째로 묻지 않고 사람이 정의한 좁은 기준(없는 기능을 약속했는가, 내면을 추측했는가, 구체 명사로 앵커했는가)을 하나씩 판정시키고, 셀 수 있는 것은 judge 대신 코드로 세고(문장 패턴 수렴율, 어미 다양성), judge의 판정 자체도 실출력 샘플을 사람이 재검수해서 믿을 만한지부터 확인했습니다. 정답이 없는 문제에 이진 정답 라벨을 강요하면 라벨 자체가 편향이 된다는 것도 실험에서 배운 부분입니다.


아이러니하게 LLM 장점중 하나인 비결정성을 줄이는게 하나의 큰 과제가 되고 있는것 같네요 ㅎㅎ

긴 답변 읽어주셔서 감사합니다. RAG 검색·평가를 공부하고 계시다니 저희 실험 과정에서 더 궁금한 부분이 있으면 언제든 편하게 물어봐 주세요. RoomFit AI도 좋은 결과 있으시길 진심으로 응원합니다!

안녕하세요 hoBIT-AX 팀, 모찌를 만든 세얼간이팀입니다.
이전에 감명깊게 보고 답변까지단 팀인데, 늦은시간에 산출물에 있는 파이프라인 구조까지 정확하게 읽어주시고 이렇게 댓글 달아주셔서 감사합니다

이해하신것이 맞습니다 ㅎㅎ. P4에서 분석 결과(의도·요약·카테고리)를 기록에 write-back하고, P5에서 요약과 의도 라벨을 입력으로 임베딩을 색인합니다.

답변에 앞서 배경을 조금 설명드리면, 모찌는 저장된 모든 기록을 분석해서 일정·할일·지식·메모 네 가지 "의도"로 구조화합니다. 스크린샷 한 장에 "다음 주 회의 일정"과 "참고할 자료"가 같이 담겨 있을 수 있어서, 한 기록에 여러 의도가 동시에 붙을 수 있고, 각 의도는 별도 데이터로 저장돼 서로 영향 없이 따로 관리됩니다.

질문 주신 최신성은 저희도 설계 초기에 오래 고민한 지점인데요. 결론부터 말씀드리면, 이미 만들어진 요약을 주기적으로 다시 쓰는 대신 "시간이 지나며 실제로 변하는 것이 무엇인가"를 세 갈래로 나눠 각각 다르게 처리합니다.

1. 변하는 것 대부분은 내용이 아니라 기록의 "의미"였습니다. 스크린샷 원문과 요약은 시간이 지나도 그대로인데, 그 기록이 지금 사용자에게 갖는 의미(일정이 지났다, 할 일이 끝났다, 지식이 잊혀간다, 보려고 했는데 까먹었다)가 변하더라고요. 그래서 요약을 고치는 대신 의도마다 상태를 두고, 정해진 규칙에 따라서만 바뀌게 했습니다. 규칙은 의도 종류마다 다릅니다. 일정은 끝나면, 할 일은 완료하면 보관 처리되고, 지식은 마지막으로 본 지 30일이 지나면 "잊혀가는 중"으로, 거기서 180일이 더 지나면 "다시 볼지 물어볼" 상태로 하루에 한 번 자동으로 바뀝니다. 이 상태가 능동 회수(리마인)와 맞물리는데, 잊혀갈 때쯤 간격 반복 알림으로 다시 보여주고, 사용자가 열어보면 다시 활성 상태로 돌아와 30일을 새로 보장받습니다. 의도가 보관 처리되면 걸려 있던 알림 계획도 함께 취소됩니다.

2. 내용이나 의도 자체가 바뀌는 경우에는 사용자 신호를 트리거로 재분석합니다. 분류가 틀렸을 때 후보 칩을 고르거나 "이건 이런 의도였어요"라고 자연어로 알려주면, 그 힌트를 실어 같은 분석 파이프라인(P3~P5)을 처음부터 다시 태웁니다. 같은 파이프라인이라 요약·의도·임베딩이 한 번에 함께 갱신됩니다. 

3. 태그(카테고리 말씀하신것이겠죠?)는 갱신보다 파편화가 진짜 문제였습니다. (ppt 39 페이지에 관련 실험 및 구현 내용이 있으니 참고 바래요!) 저장할 때마다 LLM이 새로 뽑으면 "여행/여행 준비/여행 계획"처럼 갈라지는데, 두 단계로 막고 있습니다. 저장할 때는 그 사용자가 지금까지 써온 카테고리 목록을 분석 Agent 의 Context에 넣어줘서 같은 주제면 기존 이름을 재사용하게 하고(예방), 월간 정리 시점에는 그 달의 잘게 갈라진 카테고리들을 LLM 1회 호출로 더 큰 묶음으로 합쳐서 DB 값을 실제로 고쳐 씁니다(교정). 다음 달에는 정리된 카테고리만 컨텍스트로 넘겨 달마다 이름이 흔들리지 않게 구현했습니다. 

반대로 "시간이 지났으니 전체 기록을 미리 다시 요약해 두는" 배치 작업은 안 하기로 했습니다. 원문이 바뀌지 않는 서비스라 요약 자체가 옛날 것이 되는 경우는 드물고, 대부분은 위에서 말씀드린 의미의 변화여서, 전량 재요약은 비용 대비 사용자가 체감할 변화가 없다고 판단했습니다.

학생마다 다른 맥락을 프로필로 이해해서 필요한 학사 정보를 먼저 정리해 준다는 방향, 저희의 "필요한 기억은 알아서 떠오른다"와 닿아 있어 반가웠습니다. 
이번 대회 좋은 결과 있으시길 응원합니다!