ZANI

1. 오류 분석

문제 현상

기존 챗봇은 현재 강의의 전체 전사를 LLM에 전달해 답변을 생성했습니다. 질문과 무관한 설명·실습 안내까지 함께 입력됐고, 다른 강의의 내용을 묻거나 여러 강의를 비교하는 질문에는 필요한 자료를 가져올 수 없었습니다.

원인

입력 자료가 현재 강의에 한정되어 있었고, 질문에 필요한 강의·구간을 먼저 고르는 과정이 부족했습니다. 여러 강의를 지원하려면 자료 접근 범위를 확장하는 동시에, 모든 전사를 답변 모델에 넣지 않도록 근거를 선별해야 했습니다.

추가 확인 사항

• •현재 강의·다른 강의·강의 간 비교 질문을 구분하고, 필요한 각 강의의 원문을 확보할 수 있는지 확인했습니다.
• •선택한 강의의 접근 권한, 서로 다른 강의의 동일 구간 번호, 캐시의 원문 버전과 인용 출처를 함께 검사했습니다.
• •합성 Java·Spring 3강의 48문항과 추가 24문항에서 원문·질문·정답 근거를 고정하고, 검색 결과·답변·검증 피드백·토큰·시간을 기록했습니다.
• •Python 평가 실행기로 실제 LangGraph와 gpt-4o-mini 생성·검증을 실행하고 gpt-4o로 후보 순서를 섞어 채점했습니다. 저장 응답으로 결과를 재현하고 pytest 75개와 Ruff·strict mypy 검사도 통과했습니다.

측정 기준

수치는 라우팅 도입 후 BM25 보완 전후의 합성 자료·LLM 채점 결과로, 최초 전체 전사 입력 방식과의 직접 비교나 실서비스 정답률은 아닙니다. 48문항의 평균 처리 시간은 8.86초에서 9.84초, 토큰은 556,552에서 620,040으로 늘었고 기존 답변 4건의 채점 변동도 있었습니다. Spring → LangGraph에는 전체 원문을 전달하며 답변 생성·검증 모델에 제공할 근거를 선별합니다.

2. 개선 과정

1. 1.전체 전사 입력의 한계 확인
2. 2.다중 강의 선택·권한 검사
3. 3.질문에 필요한 강의 결정
4. 4.목차·BM25 원문 검색
5. 5.LLM Wiki·지식 그래프 조건부 보완
6. 6.답변 검증·재시도 분기
7. 7.강의별 인용·영상 이동 연결
8. 8.합성 질문으로 검색·답변 평가

LangGraph 검색 라우팅을 도입해 질문·이력·제목·목차로 필요한 강의를 먼저 고르고 강의별 검색 질문을 만들도록 구성했습니다. 각 강의에서 목차 최대 3구간의 실제 전사 원문을 읽고, 원래 질문의 BM25 검색으로 최대 3발화를 보완해 중복·용량을 정리했습니다. 원문이 없거나 재검색할 때는 사전 구축된 LLM Wiki의 개념 페이지와 지식 그래프의 관계·연결 원문으로 근거를 보완합니다. 질문의 필수 내용·주장·인용을 검증해 근거 부족은 재검색, 답변 누락은 수정으로 분기했습니다. 사용자는 현재 강의 외 최대 4개 강의를 선택하고 답변 인용에서 해당 영상 시각으로 이동할 수 있습니다.

3. Before & After 비교

1. 오류 분석

문제 현상

내 강의실 페이지의 LCP가 3.5초, Performance 점수가 81점에 머물렀습니다. 555×312 카드에 녹화 영상에서 추출한 1280×720 PNG 썸네일을 그대로 넣고 있어 이미지 전송량이 컸습니다.

원인

555×312 카드에 1280×720 PNG를 그대로 사용했고, 요청마다 달라지는 URL 때문에 이미지 캐시 재사용이 어려웠습니다.

추가 확인 사항

• •원본 변경 시 캐시 갱신과 첫 화면 밖 이미지의 로딩 시점을 함께 점검했습니다.
• •JDK에 WebP 인코더가 없어 네이티브 라이브러리에 의존하게 되므로, 인코딩이 실패하더라도 썸네일이 사라지지 않도록 대체 경로를 설계했습니다.
• •포맷을 바꾸면서 화질이 떨어지지 않는지 동일한 축소 결과를 기준으로 비교했습니다.

2. 개선 과정

1. 1.LCP·이미지 요청 분석
2. 2.카드 크기로 리사이즈
3. 3.WebP 변환·캐시(JPEG 대체 경로)
4. 4.화면 밖 이미지 지연 로딩
5. 5.용량·화질 비교 측정
6. 6.Lighthouse 재측정

썸네일 URL이 요청마다 달라 Next.js 이미지 캐시를 쓰기 어려웠습니다. 그래서 서버에서 원본을 카드 크기에 맞게 줄이고 WebP로 변환했습니다. JDK 이미지 라이브러리에는 WebP 인코더가 없어 네이티브 라이브러리를 추가해야 했기 때문에, 인코더를 불러오지 못하는 환경에서는 JPEG로, 변환 자체가 실패하면 원본으로 단계적으로 대체하도록 설계했습니다. 변환한 이미지는 캐시해 다시 쓰고, 원본이 바뀌면 캐시도 함께 갱신했습니다. 첫 화면 밖 썸네일은 지연 로딩으로 바꿨습니다.

3. Before & After 비교

1. 오류 분석

문제 현상

실시간 코칭을 위해 강사의 최근 5분 음성을 링버퍼에 저장했습니다. 하지만 LiveKit에서는 음소거 중 오디오 프레임이 오지 않아, 실제 최근 5분이 아니라 음성이 들어온 시간만 따진 최근 5분이 조회됐습니다.

원인

음소거 중 오디오 프레임이 오지 않아 버퍼가 실제 경과 시간 대신 수신한 음성 길이만 누적했습니다.

추가 확인 사항

• •짧은 네트워크 지연을 음소거로 오인하지 않도록 0.5초 기준을 적용했습니다.
• •MP3 인코딩 중 락이 오디오 수집을 막는지도 확인했습니다.

2. 개선 과정

1. 1.음소거 재현
2. 2.수신 시간·실제 시간 비교
3. 3.긴 공백에 무음 삽입
4. 4.인코딩을 락 밖으로 분리
5. 5.시간 오차·락 점유 확인

버퍼 시간이 실제 시간과 맞도록 0.5초 이상 오디오가 비면 서버에서 무음 데이터를 채웠습니다. 짧은 네트워크 지연은 기다리고, 긴 공백만 보정해 불필요한 무음 삽입을 줄였습니다. MP3 변환은 필요한 음성만 먼저 복사한 뒤 락 밖에서 진행했습니다.

3. Before & After 비교

1. 오류 분석

문제 현상

이전 팀 프로젝트에서 Jira 티켓 누락, 서로 다른 커밋 형식, 작업 상태 갱신 지연으로 진행 상황을 파악하기 어려웠습니다. 기록만으로 확인할 수 없어 팀원들에게 진행 상황을 다시 물어야 했습니다.

원인

협업 기록과 상태 갱신이 팀원들의 수작업에 의존했습니다. 개발 중에도 기록이 남도록 규칙을 작업 흐름에 연결하고, 반복되는 관리 작업을 줄일 필요가 있었습니다.

추가 확인 사항

• •브랜치 검사 → 이슈 키 자동 삽입 → 커밋 메시지 검사가 순서대로 실행되는지 확인했습니다.
• •이미 이슈 키가 있는 메시지는 중복 삽입하지 않고, 자동 생성 커밋과 보호·릴리스 브랜치에는 단계별 예외를 적용했습니다.
• •총 1,300개 커밋 중 메시지 규칙 위반 5건을 집계해 준수율을 계산했습니다.

2. 개선 과정

1. 1.티켓·담당자·스크럼 규칙 합의
2. 2.이슈 키 자동 삽입·형식 검사
3. 3.Jira 상태·아침 공지 자동화
4. 4.커밋 규칙 준수율 집계

다음 5인 프로젝트에서는 기능별 티켓 생성·담당자 지정·매일 스크럼을 팀과 합의했습니다. 제가 구축한 Husky 훅은 브랜치명에서 티켓 번호를 읽어 커밋 메시지에 자동으로 넣고, 정해진 메시지 형식을 검사하도록 했습니다. Jira 작업 상태 변경도 자동화하고, JQL로 필요한 티켓을 조회해 매일 아침 담당자별 할 일을 공지하는 봇을 만들었습니다. 스크럼 전에 각자의 작업을 확인할 수 있도록 기록과 공지를 연결했습니다.

3. Before & After 비교