AI 입문 · 프로젝트 설계 · 면접 준비
AI 프로젝트의 전체 과정
문제 정의에서 서비스 운영까지
모델의 점수가 높아도 프로젝트는 실패할 수 있다. 누구의 어떤 문제를 줄일 것인지부터 출발하자.
학교 도서관에 하루 수백 건의 문의가 들어온다고 하자. “AI 챗봇을 만들자”는 제안은 그럴듯하지만, 아직 풀어야 할 문제가 분명하지 않다. 담당자의 반복 작업을 줄이려는 것인지, 야간에도 답변하려는 것인지, 문의를 알맞은 부서에 배정하려는 것인지에 따라 필요한 데이터와 평가 방법이 달라진다.
이번 글에서는 도서관 문의를 담당 부서로 분류하는 서비스를 가상의 사례로 삼아 프로젝트를 처음부터 따라가 본다. 제시하는 수치와 운영 조건은 설명을 위한 가정이다.
1. 기술 이름을 문제 문장으로 바꾸기
“LLM을 활용한다”는 구현 방향이지 성공 조건은 아니다. 다음처럼 관찰 가능한 문제로 바꾸면 해야 할 일이 선명해진다.
문의 내용을 읽고 담당 부서를 선택하는 데 걸리는 시간을 줄이되, 잘못 배정되어 재처리되는 문의는 늘리지 않는다.
입력은 문의 텍스트, 출력은 담당 부서 후보다. 사용자는 담당 직원이고, 초기에는 자동 확정 대신 추천 결과를 직원이 확인하도록 한다. 이렇게 적용 범위를 좁히면 시스템이 실패했을 때 대응 방법도 설계할 수 있다.
Google의 ML 프로젝트 교육도 기획, 실험, 운영을 연결해 설명한다. 단계는 한 번씩 통과하는 절차라기보다, 실험 결과에 따라 앞 단계로 돌아오는 과정이다. Google — Managing ML projects
2. 성공 지표와 실패 비용을 함께 정하기
모델 지표와 서비스 지표를 구분해 보자. 모델이 담당 부서를 얼마나 정확히 맞히는지는 모델 지표다. 직원의 처리 시간이 줄었는지, 재배정 건수가 늘었는지는 서비스 지표다. 두 지표가 항상 같은 방향으로 움직이지는 않는다.
| 관점 | 예시 지표 | 살펴볼 이유 |
|---|---|---|
| 예측 품질 | 부서별 재현율, 전체 정확도 | 작은 부서의 실패가 평균에 가려지는지 확인 |
| 사용자 효과 | 건당 처리 시간, 재배정 비율 | 실제 업무가 개선됐는지 확인 |
| 운영 제약 | 응답 지연, 요청당 비용 | 현실적으로 지속 운영할 수 있는지 확인 |
문의를 잘못 보내는 비용이 크다면 확신이 낮은 사례는 직원에게 넘길 수 있다. 단, 모델이 출력한 숫자를 실제 정답 확률로 곧바로 믿으면 안 된다. 검증 데이터에서 그 점수가 얼마나 믿을 만한지 확인하고 처리 기준을 정해야 한다.
3. 데이터를 모으기 전에 예측 시점을 정하기
학습용 자료에 문의 내용, 최초 접수 시간, 최종 담당 부서가 있다고 하자. 최종 담당 부서는 학습 목표로 쓸 수 있다. 하지만 답변 완료 후 직원이 작성한 “처리 부서 설명”을 입력으로 넣으면 문제가 생긴다. 실제 접수 순간에는 존재하지 않는 정보이기 때문이다.
“이 정보는 모델이 실제로 예측하는 순간에도 얻을 수 있는가?” 답이 아니면 높은 검증 점수가 나와도 운영 성능을 대표하기 어렵다.
중복 문의나 같은 대화의 후속 메시지가 학습과 평가에 나뉘어 들어가지 않게 해야 한다. 미래 문의를 처리할 서비스라면 시간에 따른 분할도 고려한다. 또한 이름이나 연락처가 분류에 필요 없다면 입력에서 제외하는 편이 좋다.
라벨에도 문제가 있을 수 있다. 직원마다 배정 기준이 다르거나 부서 개편 전후의 기준이 섞여 있다면, 먼저 기준을 통일해야 한다. 모델을 복잡하게 만드는 것으로 라벨의 모순을 해결하기는 어렵다.
4. 가장 단순한 기준선부터 만들기
기준선(baseline)은 새 방법이 실제로 도움이 되는지 비교하는 출발점이다. 가장 많은 부서로 보내기, 몇 개의 키워드 규칙 사용하기, 간단한 텍스트 분류 모델 만들기 등이 가능하다.
문의의 90%가 대출 관련이라면 모든 문의를 대출 부서로 보내도 정확도는 90%다. 이 수치만으로 “훌륭한 모델”이라고 판단하면 나머지 10%의 문제를 놓친다. 부서별 성능과 오류 사례를 함께 봐야 한다.
다음 코드는 가상의 5건에서 정확도를 구하는 작은 예다. 외부 라이브러리 없이 실행할 수 있다.
actual = ["대출", "좌석", "대출", "자료", "좌석"]
predicted = ["대출", "대출", "대출", "자료", "좌석"]
correct = sum(a == p for a, p in zip(actual, predicted))
accuracy = correct / len(actual)
print(f"정확도: {accuracy:.0%}") # 정확도: 80%5건만으로 실제 성능을 추정할 수 있다는 뜻은 아니다. 이 예제에서 중요한 다음 행동은 틀린 한 건을 읽어 보는 것이다. 표현이 모호했는지, 라벨이 잘못됐는지, 특정 부서의 자료가 부족했는지를 구분하면 다음 실험의 방향을 정할 수 있다.
5. 실험은 하나의 가설에 답해야 한다
“성능을 높이자”보다 “좌석 문의에 자주 쓰이는 표현이 학습 데이터에 부족하다”는 가설이 검증하기 쉽다. 관련 데이터를 보완하고 동일한 검증셋에서 비교해 볼 수 있다. 모델 구조, 데이터, 전처리를 한 번에 모두 바꾸면 무엇이 효과가 있었는지 알기 어렵다.
데이터 버전, 코드 버전, 모델 설정, 지표와 실패 사례를 함께 기록한다. 검증 결과를 보고 선택한 모델을 마지막 테스트셋으로 평가하되, 테스트 결과를 반복해서 보며 조정하면 그 테스트셋도 사실상 개발 과정에 사용한 셈이 된다.
6. 배포에서는 예측 외의 동작도 설계한다
노트북에서 잘 실행되는 것과 직원이 쓰는 서비스가 되는 것은 다르다. 입력이 비어 있거나 너무 길 때, 외부 모델 응답이 늦을 때, 서버가 실패할 때의 동작을 정해야 한다. 문의가 사라지지 않도록 기존 접수 흐름으로 돌아가는 경로도 필요하다.
처음에는 일부 요청에만 추천을 표시하고 실제 재배정 비율과 처리 시간을 확인할 수 있다. 문제가 발생하면 이전 버전으로 되돌릴 수 있도록 모델뿐 아니라 전처리와 설정도 함께 관리한다. 학습과 서빙에서 서로 다른 전처리가 적용되면 같은 문의도 다른 입력으로 바뀔 수 있다. Google — ML pipelines
7. 운영은 다음 학습의 시작이다
학기 초에는 좌석 문의가, 시험 기간에는 운영 시간 문의가 늘 수 있다. 서비스에 들어오는 데이터의 분포가 바뀌면 예전 평가 결과만으로 품질을 보장하기 어렵다. 응답 시간, 실패율, 직원의 수정 기록과 부서별 성능을 관찰해야 한다.
사용자가 결과를 수정하지 않았다고 해서 반드시 정답인 것은 아니다. 바빠서 그냥 넘겼을 수도 있다. 운영 로그를 새 라벨로 쓰기 전에는 그것이 무엇을 의미하는지 확인해야 한다.
문제 정의, 데이터와 예측 시점, 기준선, 검증 방법, 운영 제약, 실패 대응. 모델 이름은 이 선택들을 설명하는 과정에 들어간다.
면접 답변 연습
“AI 프로젝트를 시작할 때 무엇부터 하나요?”
사용자의 문제와 성공 지표를 먼저 정합니다. 예측 시점에 확보 가능한 데이터와 오류 비용을 확인하고, 단순한 기준선을 만듭니다. 누수 없는 평가로 개선을 검증한 뒤 운영 지연과 비용, 실패 시 대체 경로까지 포함해 배포를 판단합니다.
“오프라인 정확도는 높은데 서비스 효과가 없다면요?”
평가셋이 실제 요청을 대표하는지, 누수는 없는지, 모델 지표가 업무 목표와 연결되는지 확인한다. 지연 때문에 직원이 추천을 기다리지 않는다면 정확도를 더 높이는 것보다 응답 흐름 개선이 우선일 수 있다.
“언제 다시 학습하나요?”
정해진 주기만 따르기보다 데이터 변화, 검증된 품질 저하, 새 라벨 확보 여부와 재학습 비용을 함께 고려한다. 재학습한 모델이 더 좋다는 가정도 검증해야 한다.
복습: 모든 문의를 가장 많은 부서로 보냈더니 정확도가 95%였다. 바로 배포해도 될까?
부서 비율이 편중되어 있을 수 있다. 소수 부서의 성능, 오배정 비용, 실제 처리 시간과 비교 기준을 확인해야 한다. 정확도 하나만으로 배포를 결정하기는 어렵다.
참고 자료
도서관 사례와 수치는 이해를 돕기 위해 구성한 가상 예시다.
'AI기본지식' 카테고리의 다른 글
| 001 AI의 큰 그림: AI·머신러닝·딥러닝과 네 가지 학습 방식출처 (0) | 2026.09.27 |
|---|