Work

검색된 문장만 모델에 전달하면 앞뒤 문단에 있는 조건이나 예외가 빠졌습니다. 여러 내용을 한꺼번에 묻는 질문에서는 답할 수 있는 내용이 있어도 설명 대신 원문만 표시되는 문제가 있었습니다. 긴 답변을 평가할 때는 모델의 입력 한도를 넘었고, 같은 텍스트의 길이를 반복해서 계산하는 작업도 문서 분석을 지연시켰습니다.

• 검색어가 들어 있는 문장뿐 아니라 그 내용을 이해하는 데 필요한 앞뒤 문단과 참조된 표도 함께 전달하기로 했습니다. 여러 문서를 분석할 때도 각 근거가 어느 문서에서 나왔는지 추적할 수 있도록 했습니다.
• 원문을 정확히 인용했는지, 답변이 문서에 근거하고 있는지, 질문의 각 항목에 답했는지는 서로 다른 문제였습니다. 한 가지 점수로 판단하지 않고 각각 확인하도록 검증 과정을 나눴습니다.
• 평가 모델이 검증 대상 문장을 다시 쓰는 과정에서 내용을 바꾸는 문제가 있었습니다. 각 항목에 ID를 붙여 평가 대상 문장을 고정하고, 반환된 평가 결과를 원문 항목과 대조하도록 구성했습니다.
• 모델의 응답 속도와 애플리케이션 내부의 처리 시간을 구분해야 병목을 찾을 수 있었습니다. 같은 모델 응답을 사용하는 시험을 구성해 반복 계산에 걸리는 시간을 비교했습니다.
• 사용자가 이미 생성된 답변을 보기 위해 품질 평가까지 기다릴 필요는 없었습니다. 답변을 먼저 보여 주고 평가는 별도로 실행하되, 새 질문이 들어오면 다음 평가 요청을 잠시 미루도록 했습니다.

• 같은 모델 응답을 사용하고 준비 실행 후 변경 전후를 각 20회 측정했습니다. 애플리케이션 처리 시간의 중앙값은 문서 분석에서 2,969ms → 672ms, 지정 문서 검색에서 485ms → 312ms로 줄었습니다. 정상 처리 과정의 모델 호출 횟수는 유지했습니다.
• 실제 긴 답변에서 검증할 내용 25개를 추출하고 5개 묶음으로 나누어 평가를 완료했습니다. 가장 긴 입력은 8,164토큰이었고, 내용을 추출하는 요청을 포함해 총 6회 호출했습니다. 자동 테스트에서는 ID가 빠지거나 중복된 결과, 잘못된 자료형의 판정을 거부하는지도 확인했습니다.
• 실제 실행에서 평가가 끝나기 전에 답변이 표시되는 것을 확인했습니다. 새 질문을 처리하는 동안 다음 평가 요청이 보류되는지, 이미 끝난 평가 단계의 결과를 다시 사용할 수 있는지도 점검했습니다.
• 실제 질문의 답변을 원문과 대조하고, 인용문이나 단위가 달라진 경우와 문서에 근거가 없는 질문을 테스트했습니다. 브라우저에서는 출처 페이지로 이동하고 미디어를 재생한 뒤에도 입력 내용과 선택 상태가 유지되는지 확인했습니다.

담당자가 표나 Excel에서 입력한 내용을 저장할 때 일부 행만 등록되거나 같은 자료가 두 번 들어가는 일을 막아야 했습니다. 다른 사람이 먼저 수정한 내용을 오래된 화면에서 덮어쓰지 않으면서, 사용자가 입력한 내용도 보존해야 했습니다. 차량·기사 배정이나 청구 원본이 바뀐 뒤에도 과거 정산을 그대로 조회할 수 있어야 했습니다.

• Excel 미리보기에서 검사한 전체 자료를 서버에 보관하고, 최종 저장 직전에 권한과 연결 자료의 변경 여부를 다시 확인하도록 했습니다. 저장 도중 오류가 나면 전체를 취소하고, 같은 요청이 다시 도착하면 기존 결과를 반환하도록 했습니다.
• 다른 사용자가 먼저 저장한 자료는 조회 당시 버전과 현재 버전을 비교해 오래된 요청을 거절했습니다. 화면에는 입력값을 남기고, 처음 읽은 값과 최신 값, 입력값을 비교해 반영할 내용을 선택한 뒤 별도로 저장하게 했습니다.
• 현재 배정 정보와 거래 당시의 대상·금액을 나눠 저장했습니다. 대출·보험 원본을 고치면 작성 중이거나 반려된 청구에 변경을 반영하고, 이미 승인했거나 정산에 반영한 금액은 다음 내역에서 조정하도록 했습니다.

• 격리된 MariaDB에서 저장 중 실패하면 전체가 취소되고, 동시에 확정하거나 같은 요청을 반복해도 중복 등록되지 않는지 확인했습니다.
• 개발 환경에서 다른 사용자가 먼저 수정한 뒤 오래된 화면의 저장이 거절되는지 확인했습니다. 입력값이 남아 있는 상태에서 최신 내용과 비교하고 다시 저장한 결과를 브라우저·API·DB로 대조했습니다.
• 개발 DB에서 배정 관계가 바뀐 뒤에도 과거 정산 금액이 유지되는지 확인했습니다. 정산 저장 기능은 개발 환경에 반영했으며, 개편한 작업 로그 화면은 관리자가 사용하고 있습니다.

ERP에서 내용을 수정하거나 삭제한 뒤에도 모바일에 예전 알림이 남을 수 있었습니다. 동시에 들어오는 읽음 저장 요청은 DB 잠금 충돌로 실패했고, 웹에서 만든 파일 주소는 Android 다운로드 기능에서 그대로 사용할 수 없었습니다. 이미 완료한 문의를 뒤늦게 도착한 요청이 덮어쓰는 문제도 막아야 했습니다.

• 알림의 업무 내용과 사용자의 읽음 상태를 별도로 관리했습니다. 원본 버전과 삭제 여부를 확인해 최신 변경만 반영하고, 내용을 수정해도 읽음 기록은 유지하도록 했습니다.
• 읽음 기록을 먼저 갱신한 뒤 없으면 등록하던 처리를 단일 UPSERT로 바꿨습니다. 같은 요청이 반복돼도 최초 표시 시각과 읽은 시각은 바뀌지 않도록 했습니다.
• PDF 다운로드에는 짧은 시간 동안 유효한 파일 전용 서명 주소를 사용했습니다. 주소를 발급할 때뿐 아니라 파일을 내려받을 때도 현재 계정과 문서의 접근 권한을 확인하도록 했습니다.
• 문의 완료 요청은 조회 당시 버전과 현재 처리 상태를 확인하도록 했습니다. 이미 처리된 문의는 구체적인 사유로 거절하고, 화면에는 저장하지 못한 입력을 남겼습니다.

• 격리된 MariaDB에서 기존 읽음 저장 실패를 재현한 뒤, 동시에 들어오는 표시·읽음 요청이 저장되고 최초 시각이 유지되는지 확인했습니다. 알림 수정·삭제의 역순 전달과 재전송도 검사했습니다.
• Chrome에서 내려받은 PDF가 원본과 같은 파일인지 해시로 대조하고, Android 다운로드 요청으로 전달되는 주소와 값을 검사했습니다.
• 로컬 브라우저에서 문의 접수부터 관리자 완료와 모바일 상태 확인까지 검수했습니다. 뒤늦은 완료 요청은 기존 결과를 바꾸지 않았고, 같은 이력을 다시 보내도 ERP에 중복 기록되지 않았습니다.
• 관련 기능을 개발 환경에 반영했습니다. Android 에뮬레이터에서는 실제 시스템 알림을 받고, 알림을 눌러 관련 목록과 본문으로 이동하는 동작을 확인했습니다.

여러 업무 화면에 표·입력 폼·모달이 반복돼 함께 사용할 구조가 필요했습니다. 첫 화면에서 쓰지 않는 페이지와 Excel 라이브러리까지 한 번에 불러와 초기 JavaScript 파일이 커졌고, 화면 미리보기가 정상이어도 실제 라벨에서는 긴 주소가 잘리거나 겹쳤습니다.

• 조회 데이터, 입력 상태, 출력 요청을 분리하고 표·폼·모달은 공통 컴포넌트로 구성했습니다.
• 번들 분석으로 첫 화면에서 필요하지 않은 코드의 비중을 확인하고, 페이지 진입과 Excel 기능 실행 시점에 맞춰 나눠 불러오도록 했습니다.
• 웹에서 보내는 출력 데이터는 통일하고, PC의 로컬 프린터 프로그램과 Android 앱의 Bluetooth 출력은 각각의 연결 방식에 맞춰 처리했습니다.

• 2026.05 빌드 산출물에서 초기 JavaScript 파일과 gzip 압축 파일의 크기를 비교했습니다.
• 페이지 이동, 데이터 조회, Excel 처리와 PC 라벨 출력이 지연 로딩 이후에도 이어지는지 확인했습니다.

웹의 출력 요청을 Android 프린터 SDK에 전달하고, 사용자가 프린터를 선택한 뒤 권한 요청·연결·출력을 진행할 수 있어야 했습니다. 실제 기기에서는 프린터가 목록에 표시되고 선택도 되지만 연결 단계에서 실패하는 문제가 있었습니다.

• 업무 화면은 웹에 두고 장비와 직접 연결하는 출력 기능은 네이티브 모듈로 분리했습니다.
• 웹 요청, 앱 권한, SDK 연결, 실제 출력 단계를 나눠 오류가 발생한 위치를 확인했습니다.
• SDK가 명령을 받았다는 응답과 종이에 인쇄가 끝났다는 의미가 섞이지 않도록 완료 안내를 출력 요청 전송으로 정리했습니다.

• Android 16 / API 36 실기기에서 권한 요청, Bluetooth 연결과 실물 라벨 출력을 확인했습니다.