2026. 8. 12. 09:16ㆍ개발 도구/[커널아카데미] 대학생 AI 크루 UNIKER 1기
커널아카데미 대학생 AI 크루 UNIKER 1기 활동도 어느덧 후반부로 들어가고 있다.
지난 8월 2일 중간 데모데이에서는 팀 핏줄의 AI 경험 관리 서비스 CampusLog를 실제 크루들과 멘토님들 앞에서 시연했다. 경험 기록부터 AI 분석, 부족 정보 보완, 자기소개서·면접·JD 기반 경험 추천까지 지금까지 구현한 전체 흐름을 직접 보여드릴 수 있었다.
중간 발표를 마친 뒤에는 멘토님께 받은 피드백을 반영하고 실제 사용자 테스트를 빠르게 진행하려고 했다.
하지만 이번 주에는 팀원들의 개인 일정과 다른 대회 일정이 겹치면서 큰 기능 개발을 진행하지는 못했다.
대신 지금까지 팀 내부에서만 반복하던 테스트를 벗어나, 실제 대학생 지인을 대상으로 CampusLog 사용자 테스트를 시작했다.
이번 주는 새로운 기능을 많이 추가한 주라기보다, 지금까지 만든 서비스를 실제 사람이 사용했을 때 어떤 문제가 생기는지 확인하고, 앞으로 CampusLog를 단순한 프로젝트가 아니라 실제 운영 가능한 서비스로 발전시키기 위해 무엇을 준비해야 하는지 고민한 한 주였다.
STEP 1. 이번 주 목표 — 개발보다 실제 사용자를 만나보기
중간 데모데이 이전까지는 서비스의 핵심 흐름을 만드는 것이 가장 중요했다.
기록하고, 분석하고, 추천받는 전체 과정이 실제로 연결되어야 했기 때문에 개발팀 내부에서 더미 데이터를 넣고 기능을 반복해서 실행하는 방식으로 테스트했다.
하지만 중간 발표 이후에는 상황이 달라졌다.
팀원들에게는 이미 익숙한 서비스이기 때문에 버튼의 위치나 용어가 조금 이상해도 자연스럽게 다음 화면으로 넘어갈 수 있다.
반대로 처음 CampusLog를 접한 사람은
- 어디에서 경험을 추가해야 하는지
- ‘오늘의 기록’과 ‘나의 활동’의 차이가 무엇인지
- AI 분석을 왜 해야 하는지
- 부족 정보에는 무엇을 입력해야 하는지
- AI 추천 기능에서 어떤 질문을 입력해야 하는지
자체를 이해하지 못할 수 있다.
그래서 이번 주에는 가까운 지인 중 몇 명을 먼저 선정해 작은 규모로 테스트를 진행하기로 했다.
불특정 다수에게 바로 공개하는 대신, 피드백을 편하게 받을 수 있는 사람들을 대상으로 오픈채팅방을 만들고 테스트 링크를 전달했다.
테스트를 시작한 지 오래되지 않았지만 벌써 팀 내부에서는 발견하지 못했던 여러 오류와 사용성 문제가 나오고 있다.
이 부분들은 단순히 버그 목록으로 끝내지 않고, 이번 주부터 우선순위를 정해 하나씩 수정할 예정이다.
STEP 2. 지인 테스트를 통해 발견하기 시작한 실제 문제
이번 테스트의 가장 큰 목적은 “서비스가 실행되는가?”를 확인하는 것이 아니다.
이미 개발팀 환경에서는 로그인, 경험 기록, AI 분석, 경험 추천 등의 주요 흐름이 작동하는 것을 반복해서 확인했다.
이제 확인해야 하는 것은
처음 사용하는 대학생도 설명 없이 CampusLog의 가치를 이해하고 사용할 수 있는가?
이다.
그래서 지인들에게 단순히 링크만 전달하고 끝내기보다 실제 서비스를 사용해보면서 불편했던 부분, 이해하기 어려웠던 기능, 오류가 발생한 상황을 자유롭게 전달해달라고 요청하고 있다.
현재 테스트를 통해 발견된 문제들은 이번 주부터 팀 회의를 통해 정리할 예정이다.
특히 지난 중간 데모데이에서 받은 피드백 중 아직 반영하지 못한 부분도 남아 있어,
사용자 테스트 피드백 + 중간 데모 멘토 피드백 + 기존 QA 이슈
를 하나의 개선 목록으로 합쳐 우선순위를 다시 정하려고 한다.
이번 과정에서 느낀 것은 개발자가 직접 테스트하는 것과 실제 사용자가 테스트하는 것은 정말 다르다는 점이다.
개발자는 기능이 어떻게 만들어졌는지 알고 있기 때문에 자연스럽게 서비스가 의도한 흐름을 따라간다.
하지만 사용자는 개발자의 의도를 알 필요가 없다.
화면만 보고 다음 행동을 이해할 수 있어야 한다.
결국 사용자 테스트는 단순히 버그를 잡기 위한 과정이 아니라 우리가 만든 사용자 흐름 자체가 실제로 통하는지 검증하는 과정이라는 생각이 들었다.
8월 9일 멘토링 — “이제 실제 서비스로 공개하면 무엇을 준비해야 할까?”
8월 9일 UNIKER 멘토링에서는 중간 데모 이후의 진행 상황을 공유했다.
이번 주에는 일정 문제로 큰 개발은 진행하지 못했고, 중간 데모에서 발생했던 오류를 우선 수정한 뒤 지인 테스트를 시작했다고 말씀드렸다.
그리고 이번에는 기능 구현 자체보다 조금 더 먼 질문을 드렸다.
“지인 테스트 인원이 많아지고, 나중에는 학교 학생들에게까지 서비스를 공개하고 싶다면 OpenAI API 비용이나 서버 비용은 어떻게 예상해야 할까요?”
현재 CampusLog는 AI 분석과 추천 과정에서 LLM API를 호출한다.
소수의 팀원과 지인이 사용하는 단계에서는 비용이 크지 않지만, 사용자가 늘어났을 때 한 명이 평균적으로 얼마나 많은 토큰을 사용하는지, 동시에 많은 요청이 들어오면 어느 정도까지 감당할 수 있는지에 대한 기준은 아직 없었다.
멘토님께서는 먼저 대표적인 사용자 흐름을 하나 정하고 실제로 한 명이 해당 흐름을 끝까지 사용했을 때 소비되는 토큰과 요청 횟수를 측정해보는 것이 좋다고 조언해주셨다.
예를 들어 CampusLog 사용자가 다음 행동을 한다고 가정할 수 있다.
경험 3개 등록
→ 경험별 AI 분석
→ 부족 정보 보완
→ 자기소개서 문항 입력
→ 경험 추천
→ 답변 초안 생성
이 한 사이클에서 사용하는 입력·출력 토큰과 API 호출 횟수를 측정하면,
사용자 10명, 100명, 1,000명으로 확대했을 때 대략 어느 정도의 비용이 발생할지 추정할 수 있다는 것이다.
LLM 서비스도 결국 ‘모니터링’이 필요하다
멘토링에서는 자연스럽게 LLMOps와 서비스 모니터링에 대한 이야기로 이어졌다.
단순히 OpenAI API를 호출하고 결과를 화면에 보여주는 것을 넘어,
- 요청마다 얼마나 많은 토큰을 사용하는지
- AI 응답까지 얼마나 걸리는지
- 첫 응답이 나오기까지 시간이 얼마나 걸리는지
- 어느 API에서 오류가 많이 발생하는지
- 특정 사용자가 비정상적으로 많은 요청을 보내지는 않는지
등을 확인할 수 있어야 실제 서비스를 운영할 수 있다는 이야기였다.
멘토님께서는 LLM 호출 흐름을 관리하고 관찰하는 도구들과 함께, 웹 서비스 운영에서 사용되는 여러 모니터링 도구를 소개해주셨다.
특히 기억에 남았던 것은 다음과 같다.
Sentry
웹 애플리케이션 내부의 오류와 성능 문제를 추적할 수 있는 APM(Application Performance Monitoring) 도구로 소개해주셨다.
사용자가 어떤 흐름에서 오류를 만났는지, 특정 API 요청에서 어떤 문제가 발생했는지를 개발자가 추적하는 데 활용할 수 있다.
Prometheus + Grafana
CPU, 메모리, 네트워크, 서버 상태와 같은 시스템 지표를 수집하고 이를 Grafana 대시보드로 시각화할 수 있다고 설명해주셨다.
Grafana에는 이미 다른 사람들이 만든 다양한 대시보드 템플릿도 존재하기 때문에 필요한 환경에 맞게 가져와 수정해 사용할 수도 있다고 했다.
nGrinder
모니터링과는 조금 다른 영역으로, 많은 사용자가 동시에 서비스에 접속하는 상황을 가정한 부하 테스트에 활용할 수 있다고 설명해주셨다.
예를 들어 동시에 수백~수천 개의 요청을 발생시키고,
로그인 → 메뉴 이동 → 특정 API 호출
같은 실제 행동 흐름을 반복하게 만들어 어느 정도의 트래픽까지 서비스가 버틸 수 있는지 확인할 수 있다.
지금 당장 CampusLog에 이 모든 운영 시스템을 붙여야 하는 것은 아니다.
하지만 지금까지는
“기능이 잘 동작하는가?”
만 생각했다면,
이번 멘토링을 통해 처음으로
“실제 사용자가 늘어나도 안전하고 안정적으로 동작하는가?”
라는 다음 단계의 질문을 생각하게 되었다.
불특정 다수에게 공개하는 순간 생기는 새로운 문제
특히 멘토님께서는 소수 지인을 대상으로 테스트하는 것과 서비스를 불특정 다수에게 공개하는 것은 전혀 다른 문제라고 강조하셨다.
현재처럼 지인을 한 명씩 선정해서 테스트한다면 어느 정도 사용량을 통제할 수 있다.
하지만 학교 커뮤니티나 학과 단체방 등에 링크를 공개한다면 서비스는 외부 공격과 비정상적인 사용에도 노출된다.
예를 들어 누군가 AI API를 반복해서 호출한다면 짧은 시간 안에 API 비용이 급격하게 증가할 수 있다.
따라서 실제 공개 서비스에서는
- 사용자별 호출 제한
- API 요청 횟수 제한
- 입력 길이 제한
- 지나치게 큰 출력 요청 제한
- 인증된 사용자만 AI 기능 사용
- 비정상적인 반복 요청 탐지
- Prompt Injection 대응
- 예상 비용 초과 시 차단 또는 알림
등도 함께 고민해야 한다.
CampusLog를 만들면서 이미 로그인과 사용자별 DB, 기본적인 AI API 요청 제한을 구현했지만, 실제 운영 관점에서는 더 많은 검증이 필요하다.
이야기를 들으며 프로토타입을 개발하는 것과 서비스를 운영하는 것은 완전히 다른 단계라는 것을 다시 느꼈다.
서비스 개발과 운영은 다르다
멘토님께서는 인프라나 DevOps, MLOps, LLMOps 분야를 진로로 생각한다면 모니터링은 기본적인 역량 중 하나라고 설명해주셨다.
개발자에게도 APM이나 로그 분석 능력은 도움이 되지만, 운영 분야에서는
- 서버
- 네트워크
- OS
- 가상화
- VM과 Container
- Docker
- Kubernetes
- 모니터링
- Alert
- 장애 대응
같은 기반 지식이 더욱 중요하다고 했다.
CampusLog는 현재 Vercel과 Supabase 같은 관리형 서비스를 활용하고 있어 직접 서버를 운영하는 부분은 많지 않다.
하지만 사용자가 늘어나는 상황을 고민하다 보니 자연스럽게 백엔드 개발을 넘어 서비스 운영, 트래픽, 비용, 보안까지 관심 범위가 넓어지고 있다.
UNIKER 프로젝트 하나를 진행하면서 프론트엔드와 AI API뿐 아니라 인증, DB, 운영과 모니터링까지 연결해서 생각해볼 수 있다는 점도 이번 프로젝트의 재미있는 부분이다.
엔지니어도 결국 많은 사람과 협업한다
멘토링 후반에는 멘토님의 실제 업무에 대해서도 질문했다.
현재는 금융권에서 AI 관련 업무를 하고 계시지만, 단순히 모델이나 시스템을 개발하는 일만 하는 것은 아니라고 했다.
특히 금융권에서는 서비스를 하나 도입하기 위해서도 보안, 준법, 컴플라이언스, 클라우드 사용 정책 등 여러 조건을 확인해야 한다.
그래서 실제 업무에서는 개발만큼이나 다른 부서와 회의하고, 요구사항을 정리하고, 문서를 작성하고, 내부 심사를 준비하는 일이 많다고 했다.
기술적으로 좋은 서비스를 만드는 것만으로 실제 서비스가 바로 운영되는 것은 아니다.
회사 규모가 커질수록 보안과 정책, 규정, 조직 간 협업까지 함께 고려해야 한다.
CampusLog에서도 이미 팀원 사이의 문서화와 GitHub 협업이 중요했는데, 실제 회사에서는 이런 협업 능력이 훨씬 더 중요해질 수 있다는 것을 느꼈다.
STEP 3. 이번 주 Key Takeaways
이번 주에는 새로운 기능을 많이 만들지는 못했다.
하지만 프로젝트 단계가 바뀌고 있다는 것은 느낄 수 있었다.
초반에는
“CampusLog를 실제로 만들 수 있을까?”
가 가장 큰 고민이었다.
중간에는
“AI 분석과 경험 추천이 제대로 작동할까?”
를 고민했다.
그리고 이제는
“실제 사람들이 이 서비스를 사용할 수 있을까?”
를 고민하고 있다.
이번 주 가장 크게 배운 점은 세 가지다.
1. 팀 내부 테스트만으로는 사용성을 검증하기 어렵다
개발자는 이미 서비스 구조를 알고 있기 때문에 사용자가 느끼는 진입 장벽을 발견하기 어렵다.
실제 사용자를 최대한 빨리 만나야 한다.
2. AI 서비스의 비용은 감이 아니라 측정해야 한다
대표 사용자 흐름을 정의하고 한 명이 사용하는 토큰과 호출 횟수를 실제로 측정한 뒤 규모에 따라 비용을 예측해야 한다.
3. 개발 완료와 서비스 운영 가능은 다르다
사용자가 증가하면 보안, API 제한, 장애 추적, 모니터링, 부하 테스트와 비용 관리까지 새로운 문제가 발생한다.
이번 멘토링을 통해 CampusLog를 단순한 UNIKER 프로젝트가 아니라 작은 서비스라는 관점에서 한 번 더 바라보게 되었다.
Next Step — 이번 주부터 다시 개발 집중
이번 주부터는 지인 테스트에서 들어오는 피드백을 본격적으로 개발에 반영할 예정이다.
우선순위는 다음과 같다.
1. 지인 테스트 오류 수정
오픈채팅방에서 전달받은 오류를 하나씩 재현하고, 사용자 흐름을 막는 문제부터 수정한다.
2. 중간 데모 피드백 반영
중간 발표 이후 아직 반영하지 못한 항목들을 다시 정리한다.
특히
- AI 응답 대기 경험 개선
- 백그라운드 처리와 진행 상태
- 완료 알림
- 경험 입력 부담 감소
- 멀티모달 경험 입력
- 면접 단계까지의 활용
을 다시 검토할 예정이다.
3. 사용자 테스트 체계화
단순히 “써보고 알려주세요”에서 끝내지 않고 주요 사용 과업을 정리해볼 계획이다.
예를 들어
로그인 → 경험 등록 → AI 분석 → 부족 정보 답변 → 자기소개서 문항 입력 → 경험 추천
의 흐름을 실제 사용자가 끝까지 수행할 수 있는지 확인한다.
4. API 사용량과 오류 모니터링
현재 사용자 한 명이 대표 흐름을 수행했을 때 몇 번의 AI 요청을 하고 얼마나 많은 토큰을 사용하는지 측정해볼 예정이다.
Sentry를 비롯해 이번 멘토링에서 알게 된 모니터링 도구들도 CampusLog 규모에서 어떤 방식으로 적용할 수 있을지 공부해보려고 한다.
5. 최종 데모를 위한 서비스 안정화
이제 새로운 기능의 개수를 늘리는 것보다 실제 사용자가 안정적으로 서비스를 이용할 수 있도록 만드는 것이 더 중요하다.
최종 발표 전에는 사용자 테스트와 반복적인 시연 리허설을 통해 이전 중간 데모에서 발생했던 것과 같은 돌발 오류를 최대한 줄일 계획이다.
마무리
이번 주는 개발량만 보면 지난주보다 조용한 한 주였다.
팀원들의 일정이 겹치면서 계획했던 기능을 모두 진행하지는 못했다.
하지만 가까운 지인들에게 CampusLog를 처음 공개하고, 개발팀 밖에서 서비스를 바라보기 시작했다는 점에서는 중요한 전환점이었다.
실제로 사용해보는 사람이 생기자 지금까지 발견하지 못했던 오류가 나오기 시작했고, 사용자가 서비스를 이해하는 방식 역시 우리가 생각했던 것과 다를 수 있다는 것을 확인하고 있다.
8월 9일 멘토링에서는 그보다 더 먼 단계인 서비스 운영에 대해서도 생각해볼 수 있었다.
사용자가 몇 명까지 늘어날 수 있는지, AI API 비용은 어떻게 계산할지, 오류는 어떻게 추적할지, 악의적인 요청을 어떻게 막을지.
아이디어를 구현하는 것에서 출발했던 CampusLog가 이제는 이런 질문까지 고민하게 되었다.
남은 UNIKER 기간에는 새로운 기능을 계속 추가하기보다,
실제 대학생이 CampusLog를 편하게 사용할 수 있는가
를 검증하는 데 집중하려고 한다.
지인 테스트에서 발견한 문제와 지난 중간 데모 피드백을 하나씩 정리하면서, 최종 데모에서는 지금보다 훨씬 안정적이고 자연스러운 CampusLog를 보여줄 수 있도록 준비해보겠다.