AI가 답한 뒤에 생기는 문제들

01 / WORK NOTES

결과와 사용량이 따로 움직일 수 있었습니다

Interviewer Lens는 개발자의 면접 답변을 AI로 진단하는 서비스입니다. 진단을 실행하면 답변을 만들고, 결과를 저장하고, 사용한 횟수도 기록해야 합니다. 눈에 보이는 답변 화면 뒤에 여러 단계가 이어집니다.

코드를 점검했을 때 사용량을 차감한 다음 결과를 따로 저장하는 흐름이 있었습니다. 중간에 실패하면 결과는 없는데 횟수만 줄어드는 상황이 생길 수 있는 구조였습니다. 이것은 점검에서 발견한 실패 가능성이지, 실제 사용자에게 같은 사고가 발생했다고 확인한 기록은 아닙니다.

수정의 기준은 결과 저장과 사용량 반영을 함께 확정하거나 함께 되돌리는 것이었습니다. 둘 중 하나만 성공한 상태를 남기지 않도록 만들고, 중간 저장 지점에 의도적으로 오류를 넣어 확인했습니다.

02 / WORK NOTES

응답이 없다는 것이 실패했다는 뜻은 아니었습니다

데이터베이스에서는 저장이 끝났지만, 브라우저로 돌아오는 응답만 끊길 수 있습니다. 이때 사용자가 다시 누른 요청을 전부 새 작업으로 처리하면 AI 실행과 사용량 기록이 중복될 수 있습니다.

그래서 같은 요청의 재시도인지 확인하고, 이미 확정된 결과가 있으면 그 기록을 다시 확인하는 경로를 연결했습니다. 완료된 결과를 뒤늦은 오류 때문에 실패로 덮어쓰지 않는지도 함께 점검했습니다. 접수 단계에서도 중복 요청이 새 AI 작업을 반복해서 시작하지 않도록 처리했습니다.

1. 접수같은 작업을 다시 요청한 것인지 확인합니다.
2. 확정결과 저장과 사용량 반영을 하나의 처리 단위로 묶습니다.
3. 재확인응답이 끊겨도 이미 완료된 상태를 확인할 수 있게 합니다.

하나의 테스트만으로 충분하지는 않았습니다. 같은 요청이 동시에 들어오는 경우와 마지막 남은 사용 횟수를 여러 요청이 함께 쓰려는 경우도 별도로 검증했습니다.

03 / WORK NOTES

서버에서는 만료됐는데, 화면은 계속 기다렸습니다

마지막 화면 흐름 점검에서는 다른 빈틈을 발견했습니다. 서버가 작업 도중 종료되면 작업 예약은 만료돼도, 사용자의 화면은 계속 ‘처리 중’으로 남을 수 있었습니다. 내부 상태가 정리되는 것과 사용자에게 다음 행동이 보이는 것은 별개의 문제였습니다.

상태를 조회할 때 만료된 작업을 정리하고 다시 제출할 수 있도록 보완했습니다. 이후 재배포하고, 운영 화면에서 제출 버튼과 무료 한도, 최근 기록이 표시되는 흐름을 확인했습니다.

04 / WORK NOTES

코드 준비와 운영 적용을 다른 칸에 적었습니다

작업은 DB 처리 기반을 먼저 만들고, 이를 서비스 흐름에 연결한 뒤 운영에 적용하는 순서로 진행했습니다. 앞 단계가 끝났을 때는 준비된 코드를 운영 적용 완료라고 기록하지 않았습니다.

검증도 층을 나눴습니다. 중간 실패 시 되돌아오는지 확인하는 테스트, 실제 데이터베이스 연결 간 동시성 테스트, 서버 요청 흐름과 운영 화면 확인을 구분했습니다. 검증용 입력은 합성 데이터로 준비하고 기존 사용자 기록을 보존하는 조건을 확인했습니다.

조회한 완료 기록에는 안정화 적용과 검증이 남아 있습니다. 다만 이 작업으로 모든 장애를 없앴다고 말할 수는 없습니다. 이 글은 운영 환경의 구성값이나 사용자 답변을 공개하지 않으며, 현재 보안 상태 전체를 인증하는 문서도 아닙니다.

05 / WORK NOTES

다음 기능보다 먼저 적을 실패 시나리오

다음 AI 기능을 만들 때도 정상 응답만 확인하고 끝내지 않으려 합니다. 두 번 눌렀을 때, 저장 뒤 연결이 끊겼을 때, 기다리던 작업이 만료됐을 때 사용자가 무엇을 보게 될지 먼저 적을 수 있습니다.

확인할 대상은 모델의 문장만이 아닙니다. 요청의 정체성, 결과의 보존, 사용량의 일관성, 다시 시작하는 경로까지입니다. 아래 템플릿은 이 기록을 다른 서비스에서도 사용할 수 있도록 새로 정리한 점검 양식입니다. 그대로 붙여 넣는 운영 코드나 SQL은 포함하지 않았습니다.