LLM 응용 개발자의 1차 면접에서는 검색 품질을 높였다는 결과보다 평가 문항과 채점 기준을 어떻게 만들었고 무엇을 기준으로 정답을 판정했는지를 자세히 묻는 편입니다. 이 예시의 공고는 오픈소스 LLM 파인튜닝 경험과 고객사별 문서 전처리·권한별 검색 범위 관리를 요구했는데, 이력서에서 두 경험이 확인되지 않아 각각을 메울 방법을 묻는 질문이 나왔습니다. 아래는 AI 엔지니어 6년차가 온새미로AI의 문서 기반 응답 제품 공고로 받은 1차 면접 준비 예시입니다.
면접 준비 기능은 지원한 회사의 채용공고와 내 이력서를 대조하고 회사의 공개 정보도 함께 살펴 질문을 만들어요. 이 예시의 회사와 채용공고는 예시를 위해 지어낸 것이라 이력서와 채용공고만으로 만들었어요.
라온에이아이의 문서 기반 검색 증강 응답과 평가 하니스 경험은 JD의 핵심 업무와 직접 맞닿아 있습니다. 1차에서는 24만 건 문서의 검색 적중률 개선 과정에서 본인이 결정한 범위, 측정 기준의 타당성, 품질과 지연·비용의 균형을 확인할 가능성이 큽니다. 반면 오픈소스 모델 파인튜닝 경험, 고객사별 권한 검색, 멀티모달 문서 처리와 온프레미스 배포는 자료에서 확인되지 않습니다. 확인되는 경험의 세부 설계와 함께, 빈 자리는 유사 경험과 학습·검증 계획으로 솔직하게 준비해 두세요.
JD는 '문서 색인·검색·재순위 파이프라인 설계와 개선'을 요구하고, 경력 사항에는 '24만 건 문서 기반 검색 증강 응답 구축'과 근거 문서 적중률 '61%에서 89%로 상승'이 제시되어 있습니다.
전략 · 「경력·프로젝트 검증」 1번과 「직무 역량·기술」 1번에서는 먼저 420개 평가 문항의 구성과 판정 기준을 설명하고, 이어 61%에서 89%로 개선한 진단 순서와 직접 구현한 범위를 말해 주세요. 검색 품질을 수치와 재현 가능한 절차로 관리한 인상을 남기는 것이 좋습니다.
JD는 '평가 문항 구축과 자동 평가 하니스 운영, 품질 회귀 감시'를 주요 업무로 제시하고, 이력서에는 '문항 420개와 채점 기준 12항목'으로 평가 파이프라인을 만들어 변경당 평가 시간을 '3일 → 40분'으로 줄였다고 적혀 있습니다.
전략 · 「직무 역량·기술」 2번과 「경력·프로젝트 검증」 1번에서 평가 기준을 만든 배경, 반복 실행으로 변동성을 확인한 방식, 이력 310건을 활용한 비교 순서로 설명해 주세요. 모델 변경 전에 측정 기준부터 마련하는 실무자로 기억되도록 하세요.
JD는 '요청당 토큰 사용량 관리와 모델 호출 비용 최적화'를 요구하며, 이력서에는 입력 토큰을 '9,400개에서 3,600개'로 줄이고 월 모델 호출 비용을 '940만 원에서 380만 원'으로 낮춘 경험이 있습니다.
전략 · 「직무 역량·기술」 3번에서 남긴 정보와 축약한 컨텍스트를 판단한 기준을 먼저 밝히고, 평가 결과와 토큰·비용을 함께 비교한 순서로 설명해 주세요. 품질 지표만이 아니라 제품 운영에 필요한 비용까지 같은 기준으로 관리한 점을 강조하세요.
JD는 '오픈소스 LLM을 업무 데이터로 파인튜닝해 본 경험'을 요구하지만, 이력서에는 평가 하니스와 프롬프트 최적화만 확인됩니다.
전략 · 「요구 대비 빈 자리」 1번의 답변 방향에 따라 실제 수행 범위를 분명히 하고, 프롬프트 작업을 파인튜닝으로 표현하지 마세요. 면접 전에는 관련 학습 경험이 있는지와 모델·데이터·학습 방식·평가 결과를 사실로 확인하고, 없다면 기존 평가 하니스 경험을 연결해 파인튜닝을 검증할 계획을 준비하세요.
JD는 고객사별 문서 구조와 '권한별 검색 범위 관리'를 업무로 제시하지만, 경력 사항에는 사내 문서 색인과 사용자 대상 공개만 적혀 있습니다.
전략 · 「직무 역량·기술」 4번과 「요구 대비 빈 자리」 2번에서 실제 권한 필터 구현 경험이 없음을 명확히 구분하고, 사내 문서 색인 경험을 유사 사례로 설명하세요. 면접 전에는 권한 정보의 출처, 검색 전 필터 적용, 결과 접근 검증과 테스트 지점을 설계 흐름으로 정리하세요.
경력 사항에는 적중률·응답 시간·초안 사용률 등 여러 개선 수치가 있지만, 일부 항목은 팀의 변경과 개인이 직접 결정하거나 구현한 범위가 분리되어 있지 않습니다.
전략 · 「경력·프로젝트 검증」 2번과 3번에서 실제로 맡은 설계·구현·측정 역할을 구분해 답하고, 비교 기간과 지표 정의도 준비하세요. 특히 A/B 비교 14회의 배정 방식과 조건을 확인해 인과 검증으로 과장하지 말고, 본인의 판단과 협업 지점을 구체적인 사례로 보여주세요.
가상 모범 답변의 장면과 수치는 예시로 지어낸 내용이에요. 내 실제 경험으로 바꿔 말해 보세요.
라온에이아이의 자동 평가 하니스를 축으로 문항을 어떤 질의 유형과 실패 사례에서 구성했는지, 정답 근거를 누가 어떤 기준으로 판정했는지 설명해 보세요. 이후 동일 평가 집합으로 변경 전후를 비교한 절차와 본인이 정한 기준을 상황, 행동, 결과 순으로 정리하세요.
평가 문항 구성의 직접 기여가 일부에 한정됐다면, 평가 이력 310건과 24회 반복 실행의 평균·분산 기록을 중심으로 재현성과 변동성 관리에 기여한 범위를 설명하세요. 개선 수치 외에 평가 집합의 한계와 보완 방향도 함께 제시하면 좋습니다.
420개 문항을 만들었다는 사실만 강조하고, 정답 근거의 판정 기준이나 평가 집합의 편향 가능성을 설명하지 않는 답변은 감점됩니다.
저는 라온에이아이에서 실제 사용자 질의와 검색 실패 사례를 유형별로 나눠 평가 문항 420개를 구성했습니다. 문서 제목만 겹치는 경우와 본문 내용이 답을 뒷받침하는 경우를 구분하고, 근거 문서 식별과 답변에 필요한 정보 포함 여부 등을 12개 채점 항목으로 정리했습니다. 각 문항에는 관련 문서의 문단을 기준 근거로 연결해 적중 여부를 판정했고, 같은 평가 집합을 검색 구성 변경 전후에 적용했습니다. 그 결과 근거 문서 적중률은 61%에서 89%로 올랐습니다. 평가 집합이 특정 질의 유형에 치우치지 않도록 실제 질의와 실패 사례를 함께 반영하는 것이 중요하다는 점을 배웠습니다.
짧은 질의에서 적중률이 낮았던 사례를 축으로, 기존 질의의 어떤 부족함을 발견했고 재작성 단계가 그 문제를 어떻게 보완했는지 설명하세요. 같은 평가 집합에서 짧은 질의와 전체 질의를 나눠 확인한 결과, 응답 시간 변화까지 연결해 말해 보세요.
재작성 방식의 세부 구현을 직접 결정하지 않았다면, 검색 응답 구조와 평가 과정에서 맡은 범위를 분명히 하세요. 대안으로 전체 적중률 61%에서 89% 개선 과정에서 직접 조정한 검색 구성이나 실패 유형 분석을 설명하고, 재작성의 부작용을 어떻게 검증했는지 실제 확인 범위만 말하세요.
적중률 상승만 제시하고 재작성으로 질의 의도가 달라지거나 잘못된 근거가 유입될 가능성을 다루지 않으면 감점됩니다.
저는 라온에이아이에서 짧은 질의가 문서의 핵심 표현을 충분히 담지 못해 검색 결과가 빗나가는 사례를 확인했습니다. 예를 들어 약어만 입력한 질의는 관련 규정 문서보다 같은 단어가 있는 일반 안내 문서를 앞에 가져왔습니다. 그래서 질의 의도와 문서 표현을 잇도록 재작성 단계를 넣고, 420개 평가 집합에서 짧은 질의와 전체 질의를 나눠 비교했습니다. 재작성 후에는 정답 근거뿐 아니라 상위 결과에 무관한 문서가 늘었는지도 함께 확인했습니다. 짧은 질의 적중률은 44%에서 78%로, 전체 적중률은 61%에서 89%로 올랐고 95백분위 응답 시간은 11초에서 3.4초로 줄었습니다. 검색어를 보강할 때는 적중률과 오검색을 같이 봐야 한다고 배웠습니다.
상담사 38명용 답변 초안 생성 기능을 축으로, 상담 유형을 나눈 이유와 비교한 변경 항목, 품질 검증 기준을 설명하세요. 초안 사용률과 상담 1건 처리 시간의 정의·비교 기간을 함께 밝히고, 본인이 결정하거나 구현한 범위를 구분하세요.
A/B 비교의 실험 설계를 직접 맡지 않았다면 그 사실을 분명히 하고, 규정 위반 표현 차단 규칙 26종 적용 경험으로 답변의 안전성과 검수 반려 감소를 설명하세요. 사용률 개선과는 다른 축으로, 운영상 어떤 기준을 정하고 결과를 확인했는지 말해 보세요.
A/B 비교 14회를 무작위 실험이나 통계적 인과 검증으로 단정하면서 배정 방식과 비교 조건을 설명하지 않는 답변은 감점됩니다.
저는 라온에이아이에서 상담 유형에 따라 필요한 근거와 답변 형식이 다른 점을 보고 프롬프트를 9종으로 나눴습니다. 상담 유형별로 답변 길이, 근거 인용 방식, 필수 안내 문구를 바꿔 14회 비교했고, 검수 기준 12항목으로 규정 준수와 상담사가 바로 활용할 수 있는지를 살폈습니다. 초안 사용률은 생성 후 상담사가 수정 없이 쓰거나 일부 수정해 업무에 반영한 비율로 집계했고, 적용 전후 각각 4주를 비교했습니다. 사용률은 47%에서 72%로, 상담 1건 처리 시간은 7분 20초에서 4분 50초로 줄었습니다. 사용률은 업무량과 상담 구성에도 영향을 받으므로 품질 검수와 처리 시간도 함께 확인하는 기준을 익혔습니다.
글마루소프트 상품 340만 건 검색 API를 축으로, 어떤 조회 경로를 캐시 대상으로 삼았고 최신성 요구와 조회 부하를 어떤 기준으로 조정했는지 설명하세요. 평균 응답 시간과 DB 조회 건수의 측정 범위, 부하 테스트 12종 시나리오가 검증에 어떻게 쓰였는지 연결하세요.
캐시 정책 결정이 팀 단위였다면 본인이 맡은 구현·검증 범위를 분리해서 말하세요. 별도 경험으로 색인 갱신 지연을 40분에서 6분으로 줄인 작업을 선택해, 검색 최신성을 위해 조정한 구조와 성과 측정 방식을 설명해도 좋습니다.
응답 시간과 조회 건수 감소를 모두 캐시의 단독 효과로 단정하고, 측정 조건이나 색인 최신성의 영향은 설명하지 않는 답변은 감점됩니다.
저는 글마루소프트에서 상품 340만 건 검색 API의 조회 경로를 살펴보고, 반복 조회가 많고 결과 갱신을 즉시 요구하지 않는 상품 정보부터 캐시 대상으로 정했습니다. 가격과 판매 상태처럼 최신성이 중요한 값은 갱신 주기를 짧게 두고, 변경 이벤트가 들어오면 관련 캐시를 무효화하도록 구성했습니다. 부하 패턴 12종을 배포 전에 돌리며 응답 시간과 데이터베이스 조회량을 함께 확인했고, 색인 갱신 지연도 별도로 점검했습니다. 평균 응답 시간은 420밀리초에서 130밀리초로 줄었고 일 데이터베이스 조회는 620만 건에서 210만 건으로 감소했습니다. 캐시는 빠르게 만드는 것뿐 아니라 오래된 값을 얼마나 허용할지 정하는 일이 핵심이라고 배웠습니다.
라온에이아이의 24만 건 문서, 186만 청크 검색 경험을 축으로 적중률 61% 시점에 확인한 실패 유형과 질의 재작성·검색 구성 변경의 순서를 설명하세요. 자료에 기재된 범위와 직접 담당한 구현을 구분하고, 재순위 적용 경험이 있다면 구체적인 입력·출력과 평가 기준을 덧붙이세요.
재순위 파이프라인을 직접 다루지 않았다면 경험이 있는 것처럼 말하지 마세요. 대신 글마루소프트의 Elasticsearch 기반 상품 검색 품질 개선에서 동의어·오타 규칙을 적용한 사례를 연결하고, 문서 검색의 청크 단위 검색과는 어떤 차이가 있는지 구분해 설명하세요.
벡터 검색 경험만으로 재순위까지 설계했다고 포괄해 말하거나, 검색 실패를 진단한 근거 없이 도구 이름만 나열하면 감점됩니다.
저는 라온에이아이에서 24만 건 문서와 186만 청크를 검색할 때 적중률이 61%에 머물자, 먼저 실패 질의를 짧은 표현, 약어, 문서 갱신 문제로 나눠 원인을 확인했습니다. 관련 문서가 색인에 있는지와 청크에 필요한 문맥이 남아 있는지를 살핀 뒤, 색인 누락보다 짧은 질의의 표현 부족이 두드러진 구간에 질의 재작성과 검색 구성 변경을 적용했습니다. 같은 420개 평가 문항으로 전체와 짧은 질의를 따로 비교해 개선을 확인했고, 짧은 질의 적중률은 44%에서 78%로 올랐습니다. 검색은 단계별 실패 근거를 먼저 좁혀야 불필요한 변경을 줄일 수 있다는 점을 배웠습니다.
라온에이아이의 평가 문항 420개와 채점 기준 12항목을 출발점으로 삼아, 검색 근거가 맞는지와 생성 답변이 근거에 충실한지를 분리해 설명하세요. 실제 사용한 지표와 새로 제안하는 지표를 구분하고, 각 지표가 어떤 실패 사례를 드러내는지 사례를 들어 보세요.
고객사 보고용 지표를 직접 운영한 경험이 없다면 그 한계를 인정하고, 평가 이력 310건과 반복 실행 평균·분산을 기록한 경험으로 비교 가능성과 변동성 설명 방식을 제시하세요. 면접 전에는 지표별 판정 기준과 고객에게 오해 없이 설명할 단위를 정리해 두세요.
적중률 89% 하나만 품질의 증거로 제시하고, 근거 검색 성공과 답변의 정확성을 같은 것으로 취급하면 감점됩니다.
저는 라온에이아이에서 근거 문서 적중률과 생성 답변의 품질을 분리해 봐야 한다고 생각합니다. 실제로 사용한 적중률은 정답 근거가 검색 결과에 포함됐는지를 보여주는 지표입니다. 여기에 답변의 근거 충실도, 질문에 필요한 핵심 항목의 포함률, 근거와 모순되는 주장 비율, 답할 근거가 없을 때 보류하는 비율을 추가하겠습니다. 예를 들어 근거 문서는 맞게 찾았지만 답변이 오래된 절차를 섞으면 검색 성공과 생성 실패를 따로 드러낼 수 있습니다. 420개 평가 문항과 12개 채점 항목을 바탕으로 고객사와 유형별 결과를 나누고, 전체 적중률 89%만으로 답변 품질을 대표하지 않도록 하겠습니다. 지표는 실패 원인을 행동으로 연결할 수 있어야 한다고 배웠습니다.
프롬프트와 컨텍스트 최적화 경험을 축으로, 중복 정보와 답변에 필요한 정보를 구분한 기준을 설명하세요. 입력 토큰, 월 호출 비용, 평가 결과를 변경 전후에 어떻게 비교했는지, 품질을 유지했다고 판단한 범위를 구체적으로 정리하세요.
컨텍스트 축약의 세부 판단이 본인 담당이 아니었다면, 평가 하니스에서 프롬프트 변경을 검증한 경험으로 대체하세요. 변경마다 동일한 평가 집합을 돌리고, 품질이 허용 범위를 벗어나면 비용 절감만으로 채택하지 않는 판단 기준을 설명하세요.
월 비용 감소만 강조하고 답변 품질에 어떤 영향을 확인했는지 설명하지 않거나, 입력 토큰 감소를 품질 유지의 증거로 간주하면 감점됩니다.
저는 라온에이아이에서 요청당 입력 토큰이 평균 9,400개에 이르자, 먼저 반복되는 지시와 답변에 직접 쓰이지 않는 문서 문맥을 찾아냈습니다. 필수 규정과 적용 조건은 남기고, 중복 설명은 하나로 합쳤으며, 검색 결과에서는 질의와 관련성이 낮은 내용을 줄였습니다. 변경 전후 동일한 평가 문항으로 근거 적중률과 답변 검수 결과를 비교하고 토큰 사용량과 월 비용도 함께 기록했습니다. 그 결과 평균 입력 토큰은 3,600개로 줄고 월 호출 비용은 940만 원에서 380만 원으로 낮아졌습니다. 토큰 절감 자체를 품질 유지로 간주하지 않고, 평가 결과를 통과한 변경만 반영하는 원칙을 익혔습니다.
라온에이아이의 사내 문서 검색 구조를 유사 경험으로 연결하되, 권한 필터를 실제 구현했다고 주장하지 마세요. 문서와 사용자 권한 정보를 어디서 받는지, 필터가 검색 전 단계에서 적용되는지, 결과에 대한 접근 검증과 테스트를 어떻게 둘지 설계 가정과 확인 질문을 나눠 설명하세요.
검색 API 개발 경험이 더 적절하다면 글마루소프트의 조회 경로 분리와 부하 테스트 12종을 근거로, 기존 API 검증 경험이 권한 조건을 다루는 데 어디까지 전이되는지 설명하세요. 권한 데이터 동기화와 예외 처리처럼 확인되지 않은 부분은 추가 검증 과제로 명시하세요.
검색 후 결과를 숨기는 방식만으로 권한 요구를 충족한다고 답하거나, 자료에 없는 권한 검색 구현 경험을 했다고 말하면 감점됩니다.
저는 라온에이아이에서 권한별 검색을 직접 구현한 경험은 없습니다. 다만 문서 24만 건과 청크 186만 개를 색인하며 문서와 청크의 식별 정보를 맞추고 검색 결과를 검증한 경험을 바탕으로, 권한은 검색 요청 전에 필터 조건으로 적용하겠습니다. 사용자 인증 정보를 신뢰 가능한 권한 서비스에서 받고, 문서에는 고객사와 접근 범위 메타데이터를 두어 검색 후보 생성 단계부터 필터링하겠습니다. 반환 직전에도 권한을 다시 확인하고, 권한이 없는 문서가 검색 결과와 답변 근거에 섞이지 않는지 경계 사례를 자동 시험하겠습니다. 입사 첫 달에는 고객사 권한 구조와 갱신 흐름을 파악하고, 두 번째 달에는 권한별 평가 문항과 누출 시험을 만들어 검증하겠습니다.
실제로 오픈소스 모델을 업무 데이터로 파인튜닝한 경험이 있다면 모델, 데이터 준비, 학습 방식, 평가 기준과 본인이 직접 수행한 범위를 사실대로 구분해 설명하세요. 이력서에 적지 않은 경험이라면 어느 프로젝트에서 했는지와 결과를 확인 가능한 수준으로 준비하세요.
경험이 없다면 없다고 명확히 답하고, 라온에이아이의 평가 집합·프롬프트 변경 이력·비용 측정 경험을 유사 기반으로 연결하세요. 파인튜닝을 검토할 때 필요한 데이터 적합성, 기준 모델, 평가 비교와 운영 제약을 면접 전에 살펴보고, 실제 수행 계획과 이미 한 일을 분리해 말하세요.
프롬프트 설계나 모델 API 호출을 파인튜닝 경험이라고 표현하거나, 실제 수행하지 않은 학습 결과를 제시하면 감점됩니다.
저는 오픈소스 LLM을 업무 데이터로 파인튜닝한 경험은 없습니다. 가장 가까운 경험은 라온에이아이에서 평가 문항 420개와 채점 기준 12항목으로 자동 평가 하니스를 만든 일입니다. 프롬프트 변경마다 같은 집합으로 결과를 비교했고, 평가 시간을 3일에서 40분으로 줄이며 실행 이력 310건을 쌓았습니다. 이 경험을 바탕으로 입사 후 첫 달에는 업무 데이터의 사용 권한과 민감정보 제거 기준, 학습·검증 분리 방식을 익히겠습니다. 3개월 안에는 작은 공개 모델과 허가된 업무 데이터로 기준선을 만들고, 파인튜닝 전후를 기존 평가 하니스로 비교해 품질과 비용을 함께 판단하겠습니다.
라온에이아이의 사내 문서 24만 건과 청크 186만 개를 색인한 경험을 유사 사례로 설명하세요. 실제로 다룬 문서 형식과 전처리 범위만 밝히고, 고객사별로 달라질 수 있는 문서 구조와 권한 조건을 어떻게 파악하고 검증할지 구체적인 확인 절차를 제시하세요.
문서 형식별 전처리 경험이 제한적이라면 글마루소프트 상품 검색의 동의어·오타 규칙과 색인 갱신 구조를 대체 경험으로 활용하세요. 문서 청킹과 상품 검색 색인의 차이를 인정한 뒤, 권한 필터와 고객별 테스트 데이터를 먼저 확인하겠다는 학습·검증 순서를 설명하세요.
사내 문서 색인 경험만으로 고객사별 전처리와 권한별 검색을 이미 운영했다고 단정하면 감점됩니다.
저는 고객사별 문서 전처리와 권한별 검색 범위를 운영한 경험은 없습니다. 라온에이아이에서는 사내 문서 24만 건을 정리해 186만 청크로 색인하고, 검색 실패 질의를 평가 문항에 반영했습니다. 입사 후 첫 달에는 고객사 두 곳의 문서 형식, 개정 정보, 권한 메타데이터와 갱신 경로를 확인하고 대표 문서를 유형별로 점검하겠습니다. 3개월 안에는 문서 유형별 전처리 규칙과 권한 경계가 포함된 평가 집합을 만들어 검색 전 필터와 결과 반환 단계의 누출 여부를 시험하겠습니다. 실제 문서 구조와 권한 정책을 먼저 파악한 뒤 자동화 범위를 정하는 방식으로 빈자리를 메우겠습니다.
라온에이아이의 짧은 질의 검색 개선을 축으로, 품질과 지연 중 어떤 기준을 먼저 합의했고 변경을 어떻게 검증했는지 설명하세요. 의견 차이나 조정이 실제로 있었다면 구체적인 쟁점과 본인의 행동을 말하고, 없었다면 협업 과정에서 확인한 기준과 의사결정 흐름을 사실대로 설명하세요.
검색 개선에서 협업 사례가 뚜렷하지 않다면 상담사 답변 초안 기능을 선택해, 상담 유형별 프롬프트와 검수 기준을 정리하는 과정에서 실제로 조율한 역할을 설명하세요. 초안 사용률이나 반려 건수는 결과로 제시하되 개인 성과와 팀 성과를 나누세요.
검색 적중률과 응답 시간의 개선 수치만 나열하고, 팀과 어떤 기준을 맞췄는지 또는 본인이 어떤 선택을 했는지 빠뜨리면 감점됩니다.
저는 라온에이아이에서 짧은 질의의 검색 적중률이 낮고 응답도 느린 상황에서, 품질과 지연을 따로 최적화하면 실제 사용성이 떨어진다고 판단했습니다. 같은 420개 평가 집합을 쓰고 짧은 질의와 전체 질의를 구분해 결과를 보며, 질의 재작성 뒤에도 무관한 근거가 늘지 않는지와 95백분위 응답 시간을 함께 확인했습니다. 변경을 비교할 때 적중률을 낮추지 않으면서 응답 지연을 줄이는 것을 공통 기준으로 삼았습니다. 짧은 질의 적중률은 44%에서 78%로, 95백분위 응답 시간은 11초에서 3.4초로 개선됐습니다. 팀이 같은 평가 기준과 지표를 공유해야 품질과 속도 사이의 선택을 설명할 수 있다고 배웠습니다.
글마루소프트 검색 품질 개선을 축으로, 규칙 적용 뒤 검색 결과 없음 비율과 클릭률을 어떻게 확인했는지 설명하세요. 실제로 예상 밖의 결과나 규칙 조정이 있었다면 그 사례를 사용하고, 없다면 지표를 함께 본 이유와 적용 범위 결정 과정을 말하세요.
클릭률 개선 과정에서 행동 사례를 찾기 어렵다면 색인 갱신 지연을 40분에서 6분으로 줄인 작업을 대체 소재로 삼으세요. 최신성 개선에서 확인한 제약이나 조정 사항이 실제로 있었는지 점검해 설명하고, 부작용을 겪지 않았다면 만들어내지 마세요.
클릭률 상승을 동의어·오타 규칙의 단독 인과 효과로 단정하고 비교 기간이나 적용 범위, 다른 변화 가능성을 설명하지 않으면 감점됩니다.
저는 글마루소프트에서 동의어와 오타 규칙을 적용할 때 검색 결과 없음 비율만 보면 넓어진 규칙이 무관한 결과를 끌어올 가능성을 놓칠 수 있다고 봤습니다. 그래서 적용 전후 검색 결과 없음 비율과 결과 클릭률을 함께 살피고, 검색어 유형별로 동의어 규칙을 점검했습니다. 클릭률이 낮은 유형은 결과 순서와 규칙 적용 범위를 다시 확인해 과도한 확장을 경계했습니다. 최종적으로 검색 결과 없음 비율은 12.4%에서 4.1%로 낮아졌고 클릭률은 8.2%에서 11.6%로 올랐습니다. 지표 변화가 규칙만의 효과라고 단정하기보다 여러 지표와 검색 사례를 같이 검토하는 것이 중요하다고 배웠습니다.