들어가며

SSU MATE는 교내 동아리 활동 자료와 창업지원단의 사업 자료를 연결해, 자료 탐색부터 기획안 작성까지 돕는 웹 서비스입니다.

이 글은 SSU MATE 서비스 개발일지의 첫 번째 글입니다. 아직 코드를 본격적으로 작성하기 전, 왜 이 서비스를 만들게 됐고 어떤 요구사항을 먼저 잡았는지를 정리한 기록입니다.

아직은 개발보다 기획과 초기 설계에 더 많은 시간을 쓰고 있습니다. 처음에는 “학교 안에 흩어진 자료를 잘 연결하면 좋겠다”는 막연한 문제의식에서 시작했지만, 실제 담당자와 이야기하고 기능을 정리하다 보니 무엇을 먼저 만들어야 하는지 조금씩 좁혀졌습니다.

이번 글에서는 아이디어를 넓게 펼쳐본 문제 발산 단계부터, 현장 검증, 요구사항 구체화, 기능 명세서 작성, 그리고 설계 초반까지의 과정을 개발 일지처럼 정리해보려고 합니다.

1. 문제 발산: 같은 학교 안에서도 서로의 활동을 알기 어려웠습니다

처음 문제를 느낀 계기는 창업지원단과 동아리 사이의 미팅이었습니다. 창업지원단에서는 동아리와 연계해 새로운 프로그램을 만들거나 실적을 쌓을 수 있는 방법을 찾고 있었고, 그래서 관련 동아리와 미팅까지 진행했습니다.

그런데 실제 협업으로 이어지지는 못했습니다. 이미 해당 연도의 사업 계획과 예산이 정해진 뒤였기 때문입니다. 협업 자체가 불가능했던 것은 아니지만, 정보를 너무 늦게 알게 된 것이 문제였습니다.

이 부분이 가장 아쉬웠습니다. 동아리는 오래전부터 활동하고 있었고, 동아리 관련 자료도 동아리연합회 쪽에는 존재했습니다. 하지만 창업지원단에서는 어떤 동아리가 어떤 활동을 하는지 바로 알기 어려웠고, 동아리연합회와 창업지원단 사이에도 자료가 자연스럽게 공유되는 구조가 없었습니다.

결국 문제는 “자료가 아예 없다”가 아니라, 학교 안에 있는 자료가 서로 연결되어 있지 않다는 점에 가까웠습니다.

처음에는 이 문제를 굉장히 넓게 바라봤습니다. 동아리 정보 검색, 부서 간 자료 공유, 사업 기획 지원, 학생 활동 데이터 분석, 비교과 프로그램 추천처럼 떠오르는 아이디어가 많았습니다. 하지만 전부 한 번에 만들 수는 없었고, 실제로 어떤 문제가 가장 먼저 해결되어야 하는지 확인할 필요가 있었습니다.

그래서 막연한 아이디어를 바로 기능으로 만들기보다, 먼저 현장에서 실제로 어떤 업무가 막히는지 확인하기로 했습니다.

2. 현장 검증: 담당자 인터뷰로 문제를 확인했습니다

이후 창업지원단 담당자분께 프로그램을 기획할 때 어떤 어려움이 있는지 여쭤보았습니다. 단순히 동아리 목록을 찾는 문제가 아니라, 사업을 기획하고 승인받기 위해 필요한 근거 자료를 찾는 과정 자체가 꽤 큰 업무라는 것을 알 수 있었습니다.

인터뷰를 통해 정리한 내용은 다음과 같습니다.

  1. 새로운 프로그램을 기획할 때는 “왜 이 프로그램이 필요한가?”, “실제로 학생 수요가 있는가?”, “기존 프로그램과 어떤 차별점이 있는가?”, “예산을 투입할 만큼 기대효과가 있는가?”를 설명해야 합니다.
  2. 사업계획을 승인받으려면 필요성과 기대효과를 구체적인 근거로 설득해야 합니다. 특히 학생 수요, 대상 규모, 목표 인원 등을 뒷받침할 자료를 찾고 정리하는 일이 중요하며, 새로운 프로그램의 경우 전체 작성·검토 과정의 40~50% 정도를 차지할 수 있다고 하셨습니다.
  3. 필요한 데이터가 여러 부서에 흩어져 있고, 어떤 자료가 어느 부서에 있는지 명확하지 않은 경우가 많습니다. 자료가 있다는 사실을 알아도 공식적으로 활용하려면 공문으로 요청해야 하는 경우가 있어 절차가 번거롭습니다.
  4. 학생 활동이나 프로그램 결과가 정량 데이터보다 서술형 보고서, 회의록, 활동일지 형태로 쌓여 있는 경우가 많아 바로 집계하거나 비교하기 어렵습니다.
  5. 기존 프로그램의 참여자·참여팀 현황, 만족도 조사 결과, 활동 결과보고서, 사업 운영 실적, 전년도 사업계획서 등이 자주 활용되지만, 각각 다른 형태로 관리되어 다시 찾고 정리하는 과정이 필요합니다.
  6. 다른 부서나 학과, 학생 조직이 가진 자료를 적극적으로 활용한 사례는 많지 않지만, 활용할 수 있다면 사업 필요성을 설명하는 데 도움이 될 수 있습니다. 예를 들어 창업을 희망하는 학생 규모, 창업 관련 비교과 참여 현황, 학과별 창업 활동 현황 등이 근거가 될 수 있습니다.
  7. 이런 정보를 미리 파악할 수 있다면, 학생이 직접 신청하기를 기다리는 방식에서 벗어나 창업 가능성이 있는 학생이나 팀을 먼저 발견하고 상담이나 프로그램 참여를 제안할 수도 있습니다.

이 내용을 듣고 나니 만들고 싶은 서비스의 방향이 조금 더 분명해졌습니다. 처음에는 단순히 “동아리 정보를 검색하는 서비스”에 가깝게 생각했지만, 실제로 필요한 것은 창업지원단이 사업을 기획할 때 필요한 근거를 빠르게 찾고, 그 근거를 바탕으로 기획안 초안까지 이어주는 도구였습니다.

그래서 SSU MATE의 초기 목표를 창업지원단과 동아리연합회 사이의 데이터를 연결해, 근거 탐색과 기획안 작성을 돕는 대학 행정 AI 에이전트로 정했습니다. 더 크게 보면 동아리연합회도 하나의 부서처럼 볼 수 있기 때문에, 이후에는 학교 안의 여러 부서 데이터를 연결하고 각 부서 업무에 맞는 AI 기능을 붙이는 방향으로 확장할 수 있을 것 같습니다.

3. 요구사항 구체화: 첫 사용자는 창업지원단 담당자로 정했습니다

처음부터 모든 부서의 업무를 지원하려고 하면 범위가 너무 커질 것 같았습니다. 그래서 인터뷰를 통해 문제를 확인한 창업지원단 담당자를 첫 사용자로 정했습니다.

대표적인 사용 흐름은 다음과 같이 잡았습니다.

관련 동아리 탐색 → 활동과 원문 확인 → 유사 사업 검색 → 기획안 초안 작성 → 협업 메일 초안 작성

예를 들어 담당자가 “최근 1년 동안 AI 프로젝트를 진행한 동아리를 찾아줘”라고 질문하면, 서비스는 관련 동아리와 활동 기록을 찾아 보여줍니다. 이후 사용자는 그 결과를 바탕으로 프로그램 기획안 초안을 만들고, 필요하다면 동아리에 보낼 협업 메일 초안까지 이어서 작성할 수 있습니다.

초기에는 검색, 기획안 작성, 메일 작성을 각각 다른 화면으로 나누려고 했습니다. 하지만 이렇게 만들면 사용자가 검색 결과를 다시 복사하고, 다른 화면으로 이동하고, 같은 맥락을 반복해서 설명해야 할 것 같았습니다.

그래서 주요 업무는 하나의 챗봇 흐름 안에서 이어가도록 설계했습니다. 다만 모든 것을 채팅창 안에 넣을 생각은 아닙니다. 원문은 별도 패널에서 확인하고, 기획안은 편집 가능한 영역에서 수정하는 방식이 더 적절해 보였습니다. 수집 상태 확인이나 추출 오류 수정처럼 운영자가 처리해야 하는 기능은 관리자 화면으로 분리할 계획입니다.

이 단계에서 요구사항도 조금 더 구체화했습니다. 사용자는 단순히 “검색 결과”만 필요한 것이 아니라, 검색 결과가 어떤 원문에서 나온 것인지 확인하고, 그 내용을 바탕으로 기획안이나 메일 같은 업무 산출물까지 만들 수 있어야 했습니다. 반대로 관리자에게는 문서 수집 상태를 확인하고 잘못 추출된 내용을 수정할 수 있는 기능이 필요했습니다.

즉 초기 요구사항은 크게 세 가지로 정리됐습니다.

  1. 담당자가 자연어로 동아리 활동과 과거 사업 자료를 검색할 수 있어야 합니다.
  2. 검색 결과에는 원문 근거와 조회 범위가 함께 제시되어야 합니다.
  3. 확인된 자료를 바탕으로 기획안과 협업 메일 초안을 작성할 수 있어야 합니다.

4. 기능 명세서 작성: 기능을 화면과 역할 단위로 나눴습니다

요구사항을 정리한 뒤에는 기능 명세서를 작성했습니다. 머릿속으로는 챗봇 하나면 될 것 같았지만, 실제 명세서로 옮기다 보니 사용자 역할과 화면을 나누어 생각해야 했습니다.

먼저 담당자 화면에서는 자료 검색, 원문 확인, 기획안 초안 작성, 메일 초안 작성이 핵심 기능이었습니다. 관리자는 문서 수집 실행, 수집 상태 확인, 추출 결과 검토, 오류 수정 같은 기능이 필요했습니다. 또 외부 자료를 검색할 수 있는 리서치 모드는 기본값을 OFF로 두고, 사용자가 허용했을 때만 켜는 방식으로 정리했습니다.

기능 명세서를 쓰면서 가장 많이 고민한 부분은 AI가 어디까지 자동으로 처리해야 하는지였습니다. 예를 들어 AI가 바로 기획안을 완성해주는 것보다, 어떤 자료를 근거로 어떤 문장을 만들었는지 확인할 수 있게 하는 것이 더 중요하다고 판단했습니다. 그래서 기능 명세서에는 결과 생성뿐 아니라 원문 근거 표시, 확인된 사실과 제안 내용 구분, 권한 확인 같은 조건도 함께 넣었습니다.

이 과정을 거치고 나니 개발해야 할 기능이 다음처럼 정리됐습니다.

  1. 문서 수집·업로드 기능
  2. 텍스트 추출과 AI 구조화 기능
  3. 동아리 활동 검색 기능
  4. 기간별·조건별 집계 기능
  5. 원문 근거 확인 기능
  6. 기획안 초안 작성 기능
  7. 협업 메일 초안 작성 기능
  8. 관리자 검토와 수정 기능
  9. 외부 리서치 모드와 접근 권한 관리

처음에는 기능을 많이 넣는 것이 좋다고 생각했는데, 명세서를 작성하면서 오히려 초기 범위를 줄이는 쪽으로 정리됐습니다. 실제 개발에서는 “질문 → 자료 조회 → 원문 확인 → 근거가 포함된 기획안 초안 작성” 흐름을 먼저 완성하는 것이 가장 중요해 보였습니다.

5. 설계 초반: 문서 처리와 사용자 요청을 분리했습니다

기술 구성은 프론트엔드에 Next.js, 서버에 FastAPI, 데이터베이스에 PostgreSQL을 사용하는 방향으로 잡았습니다. AI 모델은 Claude, 에이전트 구성에는 Strands를 활용할 계획입니다.

전체 구조는 크게 두 흐름으로 나누었습니다.

문서 준비
수집·업로드 → 원본 저장 → 텍스트 추출 → AI 구조화 → DB 저장

사용자 요청
질문 입력 → 권한·검색 범위 확인 → 데이터 조회 → 답변·초안 생성

문서 수집과 구조화를 사용자가 질문할 때마다 실행하면 응답 시간이 길어질 수밖에 없습니다. 그래서 문서는 미리 처리해 두고, 사용자가 질문할 때는 정리된 데이터를 조회하는 방식으로 설계했습니다.

원본 파일은 따로 보관하고, DB에는 문서 정보와 구조화된 값, 원문 위치를 연결해 저장할 계획입니다. 처음부터 구조를 너무 복잡하게 나누기보다는 API 서버와 문서 처리 작업을 분리하는 정도로 시작하려고 합니다.

6. 데이터 설계: 문서를 모으는 것보다, 어떻게 저장할지가 중요했습니다

수집량과 실제 확보량 구분하기

수집 대상은 기획 시점 기준 중앙동아리 77개입니다. 각 동아리가 활동보고서와 회의록을 매월 한 건씩 제출한다고 가정하면 월 최대 154건의 문서가 생길 수 있습니다.

하지만 이 숫자는 어디까지나 예상 가능한 최대치입니다. 실제로는 제출 누락이 있을 수 있고, 파일이 깨져 있거나 양식이 다른 경우도 있을 수 있습니다. 그래서 예상 수집량과 실제 확보한 문서 수, 확인 가능한 기간을 따로 관리해야 한다고 판단했습니다.

수집은 익월 5일 이후 월 1회를 기본으로 하고, 관리자가 필요할 때 수동으로 실행할 수 있도록 할 계획입니다. 답변에도 마지막 갱신일과 조회 범위를 함께 표시해 사용자가 데이터의 기준 시점을 확인할 수 있게 하려고 합니다.

같은 게시물의 첨부파일이 나중에 수정되는 경우도 고려했습니다. URL만 보면 같은 파일처럼 보일 수 있기 때문에 URL과 파일 해시를 함께 확인해 중복을 구분하고, 내용이 바뀌었다면 이전 원본을 남긴 채 새 버전으로 저장하는 방식이 필요해 보였습니다.

원문에 있는 값과 AI의 해석 구분하기

문서를 구조화할 때 가장 조심해야 할 부분은 원문 사실과 AI의 해석을 섞지 않는 것입니다.

예를 들어 원문에 “앱 출시를 위한 역할 분담을 논의했다”라고 적혀 있다면, 앱 관련 활동으로 분류할 수는 있습니다. 하지만 실제로 앱을 출시했다고 보거나 기획자, 디자이너, 개발자가 모두 참여했다고 단정할 수는 없습니다.

그래서 문서에 직접 적힌 날짜, 인원, 장소 같은 값과 AI가 분류한 활동 분야, 프로젝트 유형은 구분해서 저장하려고 합니다. 근거가 없는 항목은 억지로 채우지 않고 null로 남깁니다. 추출한 값에는 가능하면 해당 원문 구간도 함께 연결할 계획입니다.

문서 수를 활동 수로 세지 않기

같은 프로젝트가 여러 달의 보고서에 반복해서 등장할 수 있습니다. 문서 세 건에서 확인됐다고 해서 프로젝트가 세 개라고 집계하면 안 됩니다. 참여 인원도 중복 여부를 알 수 없다면 고유 학생 수처럼 보여줘서는 안 됩니다.

또한 활동 기록이 많다는 사실만으로 특정 프로그램에 대한 참여 수요가 확인되는 것도 아닙니다. 활동 데이터는 사업을 검토할 근거로 제공하되, 실제 참여 의향은 별도로 확인해야 한다는 안내가 필요하다고 봤습니다.

7. 검색 설계: 검색과 집계는 정해진 도구로 처리하려고 합니다

AI가 SQL을 직접 작성하게 하기보다는, 서버에 정의한 조회 도구를 사용하도록 설계했습니다.

동아리 활동 검색, 기간별 집계, 과거 사업 검색, 원문 조회 같은 기능을 도구로 제공하고, AI는 질문에 맞는 도구와 조건을 선택합니다. 권한과 조회 조건은 서버에서 검증합니다.

특히 관련 자료를 찾는 검색과 전체 개수를 계산하는 집계는 구분하려고 합니다.

“AI 활동을 한 동아리를 찾아줘”는 관련 기록을 찾는 질문입니다. 반면 “AI 활동을 한 동아리는 총 몇 개야?”는 조회 범위 전체에서 중복을 제거하고 계산해야 하는 질문입니다. 검색된 일부 문서만 보고 전체 수치를 답하면 안 되기 때문에, 이 둘은 처음부터 다른 방식으로 처리해야 한다고 생각했습니다.

답변에는 문서 링크뿐 아니라 근거가 된 원문 구간도 함께 보여주려고 합니다. 사용자가 파일을 열고 다시 내용을 찾아야 하는 일을 줄이기 위해서입니다.

기획안에서도 확인된 사실과 새로 제안하는 내용을 구분해야 합니다. 기존 사업의 예산에는 출처를 달고, 새 사업의 예산안은 ‘제안’ 또는 ‘검토 필요’로 표시하는 식입니다.

8. 운영 조건: 리서치 모드와 접근 권한을 함께 고려했습니다

AI 리서치 모드는 기본값을 OFF로 정했습니다.

OFF 상태에서는 동아리 자료와 창업지원단 내부 문서만 사용합니다. ON 상태에서는 다른 대학 사례나 관련 동향을 외부에서 검색할 수 있고, 교내 자료와 외부 출처를 구분해서 표시합니다.

외부 검색 제한은 프롬프트에만 맡기지 않고 서버에서 적용하려고 합니다. 다만 외부 검색을 막는다고 답변이 항상 정확해지는 것은 아니기 때문에, 근거가 부족한 내용은 확인되지 않았다고 답하도록 해야 합니다.

자연어 요청과 화면 설정이 충돌하는 경우도 고민했습니다. 예를 들어 OFF 상태에서 사용자가 “다른 대학 사례도 찾아줘”라고 요청하면, 외부 검색 허용 여부를 확인한 뒤 해당 질문에만 적용하는 방식을 검토하고 있습니다.

접근 권한도 초기 설계에 포함했습니다. 담당자와 관리자의 기능을 구분하고, 원문 조회 요청에도 서버에서 권한을 확인합니다. 회의록 작성자처럼 업무에 직접 필요하지 않은 개인정보는 검색 결과와 모델 입력에서 제외하는 방향으로 생각하고 있습니다.

여기서 외부 검색 OFF와 외부 AI API 이용은 별개라는 점도 확인해야 합니다. 내부 자료를 모델에 전달할 수 있는지는 담당 부서와 먼저 협의하고, 초기에는 비식별 샘플로 검증하려고 합니다.

9. 초기 개발 범위: 먼저 한 가지 업무를 끝까지 연결해 보려고 합니다

첫 개발에서는 일부 문서를 대상으로 다음 흐름이 제대로 동작하는지 확인하려고 합니다.

질문 → 자료 조회 → 원문 확인 → 근거가 포함된 기획안 초안 작성

이 과정이 확인되면 수집 대상을 늘리고 자동 갱신을 붙일 계획입니다. 타 부서 연동, 학교 공지사항 수집, 학생용 화면, 실제 메일 발송은 초기 범위에서 제외했습니다.

자료 탐색·정리 시간 30~50% 절감과 주요 답변의 원문 출처 제시율 100%는 아직 달성한 성과가 아니라 검증 목표입니다. 시간은 답변 생성 시간만 보지 않고, 담당자가 근거를 확인하고 내용을 수정하는 시간까지 포함해 비교하려고 합니다. 출처도 단순히 링크가 달렸는지뿐 아니라, 실제로 답변을 뒷받침하는 근거인지 나누어 확인할 생각입니다.

문서 처리 비용과 질문당 모델 비용도 함께 기록해, 학교 예산 안에서 운영 가능한지 확인할 계획입니다.

마무리

이번 기획 과정은 막연한 문제의식에서 시작해 실제 업무 흐름을 확인하고, 다시 요구사항과 기능 명세서로 좁혀가는 과정이었습니다. 처음에는 교내 자료를 연결하면 편하겠다는 정도로 생각했는데, 요구사항을 정리하다 보니 생각보다 결정해야 할 기준이 많았습니다.

특히 문서 중복을 어떻게 처리할지, AI가 추론한 값을 어디까지 저장할지, 검색 결과와 집계 결과를 어떻게 구분할지 같은 문제들이 모두 서비스의 신뢰도와 연결되어 있었습니다. 그래서 바로 구현에 들어가기보다 문제를 발산하고, 현장에서 검증하고, 기능 명세서로 좁힌 뒤, 그에 맞춰 설계를 시작한 것이 필요했던 것 같습니다.

우선은 실제 자료 몇 건으로 검색부터 기획안 작성까지 이어지는 흐름을 먼저 구현해 보려고 합니다. 담당자가 결과를 확인하는 데 얼마나 손이 가는지 보고, 그 과정에서 불편한 부분부터 하나씩 수정해 나가겠습니다.

다음 단계에서는 이 설계에서 가장 먼저 필요한 입력 데이터, 즉 동아리 활동보고서와 회의록 PDF를 어떻게 구조화된 데이터로 바꿀지 확인해보려고 합니다.