Qwen 실전 프로젝트 설계하기

목표는 "모델 사용"이 아니라 "업무 완성"이다

Qwen 기반 프로젝트를 설계할 때 가장 먼저 정할 것은 모델이 아니라 업무 흐름이다. 누가 사용하고, 어떤 입력을 넣고, 어떤 결과를 받아야 하며, 사람이 어느 지점에서 확인해야 하는지부터 정해야 한다.

좋은 설계는 단순하다. 입력을 모으고, 필요한 지식을 찾고, Qwen이 초안을 만들고, 사람이 검수하거나 시스템이 후처리한다. 이 흐름을 안정적으로 반복할 수 있으면 프로토타입은 서비스가 된다.

사내 문서 Q&A 봇 설계

가장 실용적인 첫 프로젝트는 문서 기반 사내 Q&A 봇이다. 요구사항은 명확해야 한다.

• 사용자는 자연어로 질문한다.

• 답변은 사내 문서에 근거해야 한다.

• 출처 문서와 위치를 함께 보여준다.

• 모르는 내용은 추측하지 않고 모른다고 답한다.

• 권한이 없는 문서는 검색되지 않아야 한다.

데이터 흐름은 다음과 같이 잡는다. 먼저 사내 문서를 수집한다. PDF, 위키, 회의록, 규정 문서처럼 형식이 달라도 텍스트로 변환한다. 그다음 문서를 너무 길지 않은 조각으로 나눈다. 각 조각에는 문서명, 부서, 작성일, 권한, URL 같은 메타데이터를 붙인다.

사용자가 질문하면 검색 시스템이 관련 문서 조각을 찾고, 그 조각을 Qwen의 컨텍스트에 넣는다. Qwen은 검색된 근거 안에서만 답변한다. 이 구조가 RAG다. 핵심은 모델에게 모든 것을 기억시키는 것이 아니라, 필요한 지식을 그때그때 찾아서 제공하는 것이다.

고객 상담 보조 도구 설계

고객 상담에서는 Qwen이 직접 고객에게 답하는 구조보다 상담원을 돕는 구조가 안전하다. 역할을 나누면 품질과 책임이 명확해진다.

첫째, 고객 문의와 기존 상담 이력을 입력으로 받는다. 둘째, 주문 정보, 정책 문서, FAQ를 검색한다. 셋째, Qwen이 답변 초안을 만든다. 넷째, 상담원이 초안을 검수하고 수정한 뒤 발송한다.

이때 화면에는 답변 초안만 보여주지 말고 근거도 함께 보여줘야 한다. "환불 가능"이라는 문장이 있다면 어떤 정책 조항을 근거로 했는지 확인할 수 있어야 한다. 상담원이 수정한 내용은 로그로 남겨야 한다. 나중에 어떤 유형의 답변이 자주 수정되는지 분석하면 프롬프트, 문서, 정책을 개선할 수 있다.

코드 리뷰 어시스턴트 설계

개발자용 코드 리뷰 어시스턴트는 입력 데이터가 중요하다. 단순히 변경된 코드만 넣으면 맥락이 부족하다. 변경 파일, diff, 관련 테스트, 커밋 메시지, 프로젝트 규칙, 보안 가이드를 함께 제공해야 한다.

평가 기준도 미리 정한다. 예를 들어 다음 항목을 기준으로 리뷰하도록 한다.

• 버그 가능성

• 보안 취약점

• 성능 저하 가능성

• 테스트 누락

• 코드 스타일 위반

• 읽기 어려운 구조

보안 주의점은 더 엄격해야 한다. 비공개 소스코드와 키, 토큰, 고객 데이터가 외부로 나가지 않도록 마스킹해야 한다. 로컬 실행이 필요한 조직이라면 로컬 Qwen 모델을 검토한다. API를 쓴다면 전송 범위, 보관 정책, 접근 권한을 확인해야 한다. 코드 리뷰 결과는 "수정 명령"이 아니라 "검토 의견"으로 제공하는 편이 안전하다.

멀티모달 문서 분석 도구 설계

계약서, 세금계산서, 검사 리포트처럼 이미지와 표가 섞인 문서는 텍스트 처리만으로 부족하다. 이때는 OCR, 이미지 이해, 표 추출을 결합한다.

흐름은 다음과 같다. 먼저 문서 이미지를 페이지 단위로 나눈다. OCR로 본문 텍스트를 추출한다. 표 영역은 별도로 감지해 행과 열 구조를 복원한다. 도장, 서명, 체크박스, 그래프처럼 텍스트만으로 설명하기 어려운 요소는 멀티모달 Qwen에 맡긴다.

그다음 추출 결과를 하나의 구조화된 JSON으로 합친다. 예를 들어 계약 문서라면 계약 당사자, 금액, 기간, 해지 조건, 특이 조항을 필드로 정리한다. 마지막으로 Qwen이 요약과 위험 항목을 작성한다. 중요한 것은 원본 페이지 번호와 좌표를 남기는 것이다. 사용자는 요약이 아니라 원문 근거를 확인할 수 있어야 한다.

프로토타입에서 운영 서비스로 가는 체크리스트

프로토타입은 "된다"를 확인하는 단계다. 운영 서비스는 "계속 안정적으로 된다"를 증명해야 한다. 전환 전에 다음 항목을 확인한다.

• 대표 질문과 실패 사례로 평가셋을 만들었는가

• 답변 품질, 응답 속도, 비용 기준이 수치로 정의되었는가

• 프롬프트와 모델 버전을 기록하는가

• 사용자 입력과 모델 출력을 로그로 남기되 민감정보를 마스킹하는가

• 장애 시 대체 모델, 재시도, 큐 처리가 준비되어 있는가

• 권한별 문서 검색이 적용되어 있는가

• 사람이 검수해야 할 위험 작업이 분리되어 있는가

• 모니터링 대시보드에서 오류율, 지연 시간, 사용량을 볼 수 있는가

확장 로드맵은 작게 시작하는 것이 좋다. 1단계는 내부 사용자용 파일럿이다. 2단계는 자주 쓰는 업무에 연결한다. 3단계는 권한, 로그, 평가, 비용 제어를 붙인다. 4단계는 모델 라우팅과 자동화 에이전트로 넓힌다.

Qwen 프로젝트의 완성도는 모델 크기보다 설계의 선명함에서 나온다. 문제를 좁히고, 근거를 연결하고, 사람의 검수 지점을 남기면 실전에서 쓸 수 있는 애플리케이션에 가까워진다.