2026. 8. 12. 13:38ㆍ개발 도구/[커널아카데미] 대학생 AI 크루 UNIKER 1기
커널아카데미 대학생 AI 크루 UNIKER 1기 활동도 어느덧 마지막을 향해 가고 있다.
8월 11일에는 한서우 강사님과 함께하는 마지막 라이브 강의가 진행됐다. 이번 강의의 주제는 「AI 서비스 운영 가이드」였다. 앞선 회차에서 문제를 정의하고, 화면을 만들고, Codex와 API를 활용해 실제 기능을 연결했다면 이번에는 그다음 단계인 “만든 AI 서비스를 실제 사용자에게 보여주려면 무엇을 준비해야 하는가?”를 다뤘다.
우리 팀 ‘핏줄’도 현재 대학생의 경험을 기록하고 필요할 때 다시 활용할 수 있도록 돕는 AI 경험 관리 서비스 CampusLog를 개발하고 있다. 경험 CRUD부터 AI 경험 분석, 경험 추천, 자기소개서·면접·JD 분석 기능까지 구현하고 Vercel을 통해 공개한 상태다.
그래서 이번 강의는 단순히 새로운 기술을 배우는 시간이라기보다, 지금까지 우리가 만든 CampusLog를 ‘작동하는 프로토타입’에서 ‘실제 사람이 사용하는 서비스’로 바라보게 만든 시간이었다.
로컬에서 한 번 성공하는 것과 공개 서비스는 전혀 달랐다
이번 강의에서 가장 먼저 와닿았던 내용은 로컬 프로토타입과 공개 서비스의 차이였다.
혼자 개발할 때는 입력값도 알고 있고, 문제가 발생하면 바로 콘솔을 확인하거나 다시 실행하면 된다. 하지만 여러 사용자가 이용하는 공개 서비스에서는 예상하지 못한 입력이 동시에 들어오고, 문제가 발생했을 때 운영자가 나중에 원인을 찾아야 한다.
강의 자료에서도 이를 명확하게 구분했다.
Codex exec는 로컬 파일을 읽고 코드나 문서를 생성하며 개발·자동화 작업을 수행하는 데 적합하고, 실제 웹이나 모바일 서비스에서는 백엔드에서 인증·검증·요청 제한 등을 거친 뒤 Responses API를 서비스 런타임으로 활용하는 구조가 필요하다.
이 부분을 듣고 CampusLog 역시 단순히 “OpenAI API를 사용했다”에서 끝나는 것이 아니라,
사용자 입력 → 백엔드 검증 → AI 호출 → 구조화된 결과 → 화면 출력
이라는 전체 데이터 흐름을 팀이 정확히 이해해야 한다는 생각이 들었다.
최종 발표에서도 “어떤 API를 썼나요?”라는 질문보다 “왜 이 API와 모델을 선택했고, 데이터가 어떤 흐름으로 처리되나요?”라는 질문에 답할 수 있어야 한다.
“응답을 기다리는 동안도 서비스입니다”
CampusLog를 개발하면서 실제로 고민했던 부분 중 하나가 AI 응답 시간이었다.
경험을 분석하거나 추천을 요청하면 결과가 나오기까지 시간이 걸리는데, 그동안 사용자가 아무것도 하지 못하고 기다리는 경험이 생각보다 길게 느껴졌다.
이번 강의에서는 이를 Streaming과 Background라는 두 방식으로 설명했다.
짧은 생성 작업은 Streaming을 통해 결과가 만들어지는 과정을 조금씩 보여줄 수 있고, 오래 걸리는 작업은 Background로 넘겨 완료된 결과를 나중에 확인하게 만들 수 있다.
하지만 기술적인 방법보다 더 기억에 남은 문장은 따로 있었다.
“응답을 기다리는 동안도 서비스입니다.”
AI 응답 시간이 존재한다면 그 시간을 없애는 것만 고민할 것이 아니라, empty → loading → error → success 상태를 하나의 사용자 경험으로 설계해야 한다는 것이다.
우리 팀도 중간 피드백 이후 AI가 작업 중인 화면은 유지하면서 사용자가 다른 기록이나 활동을 확인할 수 있도록 UX를 개선하고 있었기 때문에 지금 진행하고 있는 고민과 정확하게 맞닿아 있었다.
여러 사람이 동시에 AI 추천을 누르면 어떻게 될까?
강의를 듣다가 CampusLog에서 아직 제대로 확인하지 않았던 문제가 하나 떠올랐다.
현재 사용자 한 명이 경험 분석이나 추천 기능을 사용하는 것은 정상적으로 동작한다. 그런데 유저테스트를 진행하면서 여러 사람이 동시에 AI 추천 버튼을 누르면 어떻게 될까?
지금의 서버와 API 구조가 그 요청을 모두 감당할 수 있을까?
강의에서는 이러한 상황을 위해 Concurrency, Queue, Timeout, Cancel을 다뤘다.
사용자별 호출 횟수와 중복 클릭을 제한하고, 동시에 처리할 수 있는 요청 수만 실행하고, 나머지는 대기열로 보내는 방식이다.
너무 오래 걸리는 요청은 계속 기다리게 할지, 취소할지, 완료되면 나중에 보여줄지도 결정해야 한다.
CampusLog도 앞으로 단순히 “기능이 된다”를 확인하는 테스트에서 한 단계 더 나아가,
1명 → 5명 → 10명 → 여러 명이 동시에 AI 요청 처럼 실제 사용 상황을 가정한 테스트를 해보고 싶다.
그 과정에서 평균 응답 시간, 실패율, 중복 요청, API 비용 등을 함께 기록하면 서비스 운영 측면에서도 의미 있는 데이터가 될 것 같다.
“별로예요”라는 피드백을 받았을 때 원인을 찾을 수 있는가
AI 서비스에서는 결과의 품질 문제도 발생한다.
사용자가 “추천 결과가 별로예요”라고 했다고 가정했을 때, 어떤 요청에서 어떤 모델과 프롬프트를 사용했고 얼마나 오래 걸렸는지 알 수 없다면 원인을 찾기가 어렵다.
그래서 로그에는 request_id, 모델, 프롬프트 버전, latency, 오류, feedback과 같은 정보를 남기는 것이 중요하다.
대신 무엇이든 저장하는 것도 정답은 아니다.
특히 CampusLog는 프로젝트와 대외활동, 지원 경험 등 사용자의 개인적인 정보를 저장하기 때문에 개인정보와 로그의 경계도 신경 써야 한다.
어떤 데이터를 저장하고, 언제 삭제하며, 사용자가 자신의 데이터를 지우면 어디까지 삭제되는지까지 생각해야 비로소 실제 서비스에 가까워진다.
여기에 비용까지 연결된다.
강의 자료의 “한 번의 무료 체험도 운영비입니다”라는 문장이 이 부분을 정확하게 설명했다.
사용자에게 무료로 제공하더라도 서비스 운영자에게는 API 비용이 발생한다. 그래서 일일 사용 횟수, 최대 출력 길이, timeout, API 호출 수, 프로젝트 spend limit 등을 설정하고 반복 클릭이나 동일 요청 폭주 같은 남용도 감지해야 한다.
우리 역시 어떤 AI 모델을 사용할지 결정할 때 단순히 가장 성능이 좋은 모델을 선택할 것이 아니라 CampusLog에서 필요한 품질과 실제 비용을 함께 비교해 선택해야 한다.
그리고 최종 발표에서 “왜 이 모델을 사용했나요?”라는 질문이 나왔을 때도 가격이 싸다거나 유명한 모델이라는 답이 아니라 우리 서비스의 입력 크기, 출력 형태, 추천 품질과 비용을 고려한 선택이었다고 설명할 수 있어야 한다.
Local 성공 후 Preview와 실제 서비스에서 다시 확인하기
이번 강의에서는 Local 성공 후 반드시 공개 환경에서 다시 확인해야 한다고 강조했다.
Vercel을 예로 들면 Local → Preview → Production 환경이 분리돼 있고 환경변수나 API Key도 각각 다르게 설정될 수 있다. 로컬에서는 정상인데 Production에 환경변수가 빠져 기능이 동작하지 않는 문제도 충분히 발생할 수 있다.
따라서 로그인·로그아웃, AI 요청·로딩·오류, 저장·새로고침·복원 등을 Preview와 실제 Domain, 다른 기기에서 반복해서 확인해야 한다.
여기서 한 가지 더 적용해보고 싶은 것이 생겼다.
기능 명세와 테스트 시나리오를 문서로 작성하고 Codex에게 반복적인 테스트를 맡기는 것이다.
단순히 “전체 테스트해줘”가 아니라,
기능 명세 → 정상 케이스 → 오류 케이스 → 경계 조건 → 완료 기준을 먼저 문서화한 뒤 Codex가 테스트 코드를 작성하고 실행하게 한다. 실패한 테스트가 있다면 코드를 수정하고 같은 조건에서 다시 검증한다.
지금까지 Codex를 주로 구현 속도를 높이는 도구로 사용했다면, 남은 기간에는 구현한 기능을 검증하는 도구로도 적극적으로 활용해보고 싶다.
최종 발표에서는 “얼마나 만들었는가”보다 “얼마나 이해했는가”
이번 강의를 통해 최종 데모데이 준비 방향도 훨씬 명확해졌다. 최종 발표에서는 크게 문제, 제품, 검증, 설명을 본다고 했다.
누구의 어떤 문제를 해결하는지 실제로 확인했는가. 핵심 사용자 흐름이 처음부터 끝까지 동작하는가. 실사용자의 피드백이 있었고 그것을 통해 실제로 무엇을 수정했는가. 마지막으로 왜 이 구조와 규칙, 모델을 선택했는지 설명할 수 있는가.
특히 CampusLog는 AI 추천이 핵심 기능 중 하나이기 때문에 마지막 항목이 중요하다.
“AI가 알아서 좋은 경험을 추천합니다.” 라고 말하는 것으로는 부족하다.
왜 경험 세 가지를 추천하는지, 각 경험을 추천한 근거는 무엇인지, 사용자의 어떤 데이터가 입력되는지, 경험 요약은 어떤 방식으로 생성되는지, 자소서와 JD 분석 시 어떤 기준으로 경험을 비교하는지 등을 설명할 수 있어야 한다.
별도의 학습된 추천 모델을 사용한 것이 아니라 LLM과 프롬프트 기반 추천이라면 그것 역시 정확하게 설명해야 한다.
AI가 만든 코드를 많이 보유하는 것과 우리가 그 코드를 이해하고 있는 것은 다른 문제다.
최종 발표 전에는 CampusLog의 코드, 프롬프트, 데이터 흐름, 모델 선택 근거를 다시 확인하면서 팀원 모두가 자신이 만든 기능을 직접 설명할 수 있도록 준비하려고 한다.
강의에서 발표 자료에 넣어야 할 증거로 제시한 것도 인상적이었다.
한 사용자 → 실제 피드백 → 개선 전후 → 백업
새로운 기능 하나를 더 넣는 것보다 실제 사용자가 어디에서 막혔고, 그 문제를 어떻게 개선했는지 보여주는 것이 더 강한 증거가 될 수 있다.
마지막 Q&A, 내가 가장 궁금했던 Physical AI 이야기를 물었다
마지막 30분은 사전 질문과 현장 질문을 중심으로 Q&A가 진행됐다.
나는 곧 컴퓨터비전 분야에서 학부연구생 활동을 시작할 예정이고, 최근 Physical AI와 VLM·VLA, Embodied AI에 관심이 생기면서 어떤 방식으로 공부해야 할지 고민하고 있었다.
아직 논문을 체계적으로 읽은 경험도 많지 않았기 때문에 컴퓨터비전 기초 → VLM → Embodied/Physical AI 로 공부하려면 어떤 순서로 접근해야 하는지, 논문은 어떻게 공부해야 하는지 질문했다.
여기에 개발자·AI 엔지니어 취업, 그리고 장기적으로 창업까지 생각하는 대학생이라면 3학년 시점에서 무엇에 집중할지도 함께 질문했다.
강사님의 첫 번째 조언은 내가 예상했던 논문 리스트가 아니었다.
“논문보다 먼저, 움직여 보기.”
Physical AI에 관심이 있다면 우선 관련 회사의 채용공고를 많이 살펴보라고 하셨다.
여러 회사의 직무 요구사항과 우대사항을 모아보면 반복해서 등장하는 역량이 보인다. 그 교집합을 찾고, 이후 각각의 회사가 실제로 무엇을 만들고 어떤 문제를 해결하는지도 공부해보는 것이다.
그리고 우대사항은 말 그대로 ‘우대’이기 때문에 모든 조건을 만족할 때까지 기다릴 필요도 없다.
“아직 부족하니까 공부를 조금 더 하고…” 를 반복하기보다 인턴이나 실제 조직에 들어가 실무 경험을 해보는 것도 중요하다는 이야기가 기억에 남았다.
Physical AI라면 논문을 읽는 것도 중요하지만 실제 로봇을 다뤄보고, 작은 로봇이라도 직접 움직이고 데이터를 다뤄보는 경험이 훨씬 많은 것을 알려줄 수 있다.
논문 여러 편을 요약하기보다 한 편을 직접 재현해보기
논문 공부에 대한 답변도 내 생각을 많이 바꿨다.
AI를 이용해 논문을 빠르게 요약하고 여러 편을 블로그나 GitHub에 정리하는 것보다, 논문 한 편을 선택해서 실제로 재현해보는 것이 훨씬 가치 있는 경험이 될 수 있다는 이야기였다.
논문을 하나 선택한다.
코드와 데이터가 존재하는지 확인한다.
논문의 수치와 결과를 직접 재현한다.
그다음 데이터, 조명, 모델 등 조건 하나를 변경한다.
그리고 마지막에 “왜 결과가 달라졌지?” 라는 새로운 질문을 만들어본다.
논문을 읽는 사람이 아니라 연구를 조금씩 시작하는 사람의 방식에 더 가까운 접근이라고 느꼈다.
앞으로 학부연구생 활동을 시작하면 처음부터 많은 논문을 읽어야 한다는 압박을 가지기보다, 하나의 논문을 제대로 이해하고 직접 실행해보는 것부터 시작해보고 싶다.
이것저것 해보며 ‘내 감각’을 기르라는 답변
마지막으로 “대학교 3학년 2학기로 다시 돌아간다면 무엇을 하시겠냐”는 질문에 대한 답변도 기억에 많이 남았다.
정답은 하나의 분야에 모든 시간을 투자하는 것이 아니었다.
인턴, 연구, 행사, 프로젝트 등 다양한 경험을 해보고 학교 밖의 다양한 사람을 만나보라는 것이었다.
그리고 경험을 할 때마다 결과만 기록하는 것이 아니라,
나는 이 경험이 좋았는가.
싫었다면 무엇이 싫었는가.
어떤 일을 할 때 시간이 빠르게 지나갔는가.
를 스스로 확인하는 것이다.
결국 여러 경험을 거쳐야 자신의 감각이 생기고 그다음에야 무엇을 선택하고 무엇을 버릴지 결정할 수 있다는 이야기였다.
요즘은 AI를 통해 과제를 빠르게 끝내고 새로운 기술을 계속 따라갈 수 있다. 하지만 그럴수록 AI에게 생각까지 맡기지 않고 자신의 생각을 직접 해보는 것이 중요하다는 조언도 해주셨다.
이 부분이 특히 마음에 들었다.
내가 평소 중요하게 생각하는 가치 중 하나가 Fail Fast이기 때문이다.
처음부터 완벽한 선택을 하려고 오래 고민하기보다 직접 경험해보고, 실패하면 거기에서 배운 뒤 다음 선택을 더 잘하는 방식.
이번 답변을 들으면서 서비스 개발뿐 아니라 연구와 커리어에서도 결국 같은 태도가 필요하다는 생각이 들었다.
마지막 강의를 듣고, CampusLog의 목표도 조금 달라졌다
이번 UNIKER 마지막 라이브 강의 전까지 가장 큰 목표는 최종 데모데이에서 CampusLog를 잘 보여주는 것이었다.
물론 지금도 당장의 목표는 최종 발표다.
하지만 이번 강의를 들으며 이 프로젝트를 UNIKER의 10주짜리 결과물로 끝내고 싶지 않다는 생각이 더 강해졌다.
올해 안에 부족한 구조를 정리하고 CampusLog를 실제 앱으로 발전시켜보는 것이 다음 목표다.
그리고 이후에는 학교라는 실제 사용자 환경에서 직접 서비스를 배포해보고 싶다.
사람들이 실제로 사용하기 시작하면 지금까지 경험하지 못했던 문제가 생길 것이다.
동시에 AI 요청이 들어올 수도 있고, 예상하지 못한 오류가 발생할 수도 있다. 사용자 문의가 들어오고, API와 서버 비용을 직접 확인해야 하며, 장애가 발생하면 원인을 찾아 다시 배포해야 한다.
그 과정까지 직접 경험해보고 싶다.
최종적으로는 Google Play와 App Store에 CampusLog라는 이름을 실제로 올려보는 것이 하나의 목표가 됐다.
그렇게 된다면 CampusLog는 단순히 포트폴리오에 적는 “AI 프로젝트를 개발했다.” 라는 한 줄을 넘어,
문제 발견 → 기획 → 구현 → AI 연결 → 배포 → 사용자 테스트 → 피드백 → 운영 → 비용 관리 → 장애 대응 → 개선
까지 직접 경험한 하나의 제품이 될 수 있을 것 같다.
마지막 강의를 마치며
UNIKER 활동을 처음 시작했을 때는 AI 서비스를 만드는 과정에서 “무엇을 구현할 것인가?”가 가장 큰 고민이었다.
하지만 실제로 CampusLog를 만들고 배포하고 사용자에게 보여주기 시작하면서 질문이 바뀌었다.
“사람들이 실제로 사용할 수 있게 하려면 무엇이 더 필요한가?”
이번 강의 자료의 전체 흐름도 결국 이 질문에 답하고 있었다. 프로토타입에서 공개 서비스로 넘어가는 순간 인증, 입력 검증, 동시 요청, Queue, 오류 처리, 로그, 개인정보, 비용, QA, 운영 책임이라는 새로운 문제가 등장한다.
그리고 마지막 Q&A를 통해 기술이나 커리어에서도 비슷한 결론을 얻었다.
모든 것을 완벽하게 준비한 뒤 시작하려고 하지 말 것.
논문만 읽지 말고 직접 코드를 돌려볼 것.
채용공고만 고민하지 말고 실제 회사와 프로젝트를 경험해볼 것.
여러 경험 속에서 내가 좋아하는 것과 싫어하는 것을 확인하고, 그 뒤에 선택과 집중을 할 것.
이번 마지막 강의에서 가져가는 가장 큰 문장은 두 가지다.
만든 것을 직접 설명할 수 있을 만큼 이해하자.
그리고, 일단 움직이고, 경험한 뒤 더 나은 선택을 하자.
남은 UNIKER 기간에는 새로운 기능의 개수보다 CampusLog의 핵심 흐름을 더 안정적으로 만들고, 실제 사용자 피드백을 반영하며, 우리가 선택한 AI 추천 구조와 모델을 스스로 설명할 수 있을 정도로 프로젝트를 다시 들여다볼 예정이다.
처음에는 하나의 아이디어였던 CampusLog가 어느새 실제 사용자가 접속할 수 있는 서비스가 됐다.
이제 마지막 데모데이에서는 ‘무엇을 만들었는가’뿐 아니라 ‘왜 이렇게 만들었고, 실제 사용자를 통해 무엇을 배웠는가’까지 보여주고 싶다.
