AI가 내 경험을 대신 지어내지 않도록

01 / DEVELOPMENT NOTES

더 구체적인 문장이 더 나쁜 답변일 수 있었습니다

면접 답변 진단에서 AI가 해야 할 일은 지원자의 경험을 더 잘 설명하도록 돕는 것입니다. 그런데 짧은 답변을 긴 성공담으로 바꾸다 보면, 지원자가 말하지 않은 성과까지 채워 넣기 쉽습니다. 개발 기록에서는 짧은 원문의 과도한 확장과, QA 초안에 원문 밖 측정 시간·구현 세부사항이 추가된 사례를 확인했습니다.

수치와 기술 이름이 들어가면 글은 전문적으로 보입니다. 하지만 면접관이 “어떻게 측정했나요?”라고 물었을 때 본인의 경험으로 설명할 수 없다면 개선이 아닙니다. 이 제품에서는 문장의 화려함보다 사용자가 책임지고 말할 수 있는 범위를 먼저 두기로 했습니다.

02 / DEVELOPMENT NOTES

필드가 존재하는 것과 사실인 것은 다릅니다

점수, 요약, 약점, 개선 초안, 꼬리질문은 앱이 일정한 형태로 읽을 수 있어야 합니다. JSON Schema 기반 구조화 출력과 앱의 범위 검사는 그 계약을 위한 것이었습니다. 그러나 형태를 통과한 문자열에도 원문 밖 주장이 들어갈 수 있습니다.

그래서 “처리할 수 있는 형식인가”와 “원문보다 더 큰 주장을 만드는가”를 별도의 질문으로 나눴습니다. 프롬프트에는 확인한 사실과 보완 제안을 구분하도록 넣고, 출력 뒤에는 숫자·단위와 선정한 주요 기술 표현을 비교하는 보호 로직을 두었습니다.

1. 원문과 초안을 비교합니다숫자·단위·일부 기술 표현을 정규화해 원문 밖 추가 신호를 살핍니다.
2. 의심되면 더 보수적으로 돌려줍니다검증되지 않은 구체성을 그대로 주는 대신, 원문과 실제 경험으로 보완하라는 안내를 제공합니다.
3. 한계를 남깁니다의미 전체를 이해하는 사실 확인기가 아닙니다. 목록 밖 주장과 같은 숫자의 다른 의미는 놓칠 수 있고, 안전한 설명을 막을 수도 있습니다.

03 / DEVELOPMENT NOTES

화면은 안전한데, 복사는 원본이면 안 됩니다

새 생성 경로만 바꾸면 예전에 저장한 결과는 예전 방식으로 읽힙니다. 화면에 보이는 초안을 보수적으로 바꿨어도 복사 버튼이 가공 전 값을 가져가면, 사용자가 실제로 가져가는 문장은 달라집니다.

같은 보호 함수를 새 평가의 후처리, 저장된 결과의 표시, 결과 복사에 적용했습니다. 과거 데이터를 모두 다시 생성하거나 삭제한 것은 아닙니다. 사용자에게 전달하는 세 경로의 기준을 맞춘 것입니다.

회귀 검사에는 빈 초안, 원문 밖 숫자, 단위 표기, 기술 동의어, 이미 보호된 문구를 넣었습니다. 평가 함수가 실제로 이 경로를 거치는지도 확인했습니다. 보호를 위해 AI를 한 번 더 호출하는 방식은 쓰지 않았습니다.

04 / DEVELOPMENT NOTES

통과한 테스트 수로 답변 품질을 말하지 않기

이 검사는 정해진 사례에서 보호 정책이 유지되는지 확인합니다. 모든 문장에서 환각이 사라졌다는 뜻은 아닙니다. 스키마 검사와 휴리스틱만으로 사용자 경험의 진위를 판정할 수도 없습니다.

결과 출처도 구분했습니다. 규칙 기반 대체 결과가 표시됐다는 사실을 기대한 AI 평가의 성공으로 세지 않았습니다. 유효한 본 평가 뒤의 추가 다듬기만 실패한 경우와, 평가 자체가 실패한 경우 역시 같은 상태로 묶지 않았습니다.

다음으로 필요한 것은 사실 추가·누락·과장·구체성을 나눠 보는 사람의 평가와 오탐·미탐 측정입니다. 이 글에서 그러한 대규모 검증을 완료했다고 말하지 않습니다. 점수 상승 역시 실제 면접 실력이나 합격률 상승과는 별개입니다.