말 많은 AI 면접관 입 다물게 만들기: 오픈소스 5개에서 찾은 프롬프트 전략

말 많은 AI 면접관 입 다물게 만들기: 오픈소스 5개에서 찾은 프롬프트 전략

2026년 2월 9일

면접관이 기다려줘야 지원자가 생각할 수 있습니다. 그런데 Recall AI 면접관은 침묵을 견디지 못하고 계속 질문을 하는 문제가 있었습니다..

코딩 면접 시뮬레이터 Recall을 만들면서 마주친 문제를 어떻게 해결할지 고민을 하였고 AI가 도와주려는 본능을 억제하게 만드는 법을 오픈소스에서 배운 과정을 공유해보려고 합니다.

1. 문제 상황

Recall은 음성 기반 코딩 면접 시뮬레이터다. 지원자가 문제를 보고 생각을 말하면 AI 면접관이 반응하고, 코드를 작성하는 동안 AI는 지켜보다가 적절한 타이밍에 개입하는 구조다.

처음 시도할 때 원했던 건 이런 흐름이었다.

  1. 지원자가 문제를 읽는다
  2. 접근법을 설명한다
  3. 코드를 작성한다 — 이 동안 면접관은 침묵한다
  4. 막히거나 명백히 틀렸을 때만 개입한다

하지만 실제 동작은 달랐다. AI는 코드를 조금만 작성해도 “지금 어떤 방향으로 생각하고 계신가요?”, “이 부분에서 어떤 자료구조를 선택하셨나요?”를 반복했다. 지원자가 생각을 정리할 틈이 없었다.

문제는 단순히 프롬프트가 약해서가 아니었다. LLM은 기본적으로 도움을 주도록 훈련되어 있다. “침묵하라”는 지시 하나로는 그 본능을 억제하기 어렵다는 걸 모르고 있었다.

2. 내가 처음 한 생각

처음에는 쿨다운 타이머로 해결하려 했다.

“AI가 질문한 뒤 최소 N초는 다시 질문하지 못하게 막으면 되지 않을까?”

그래서 AI_QUESTION_COOLDOWN_MS 값을 늘려가며 테스트했다. 30초, 45초, 60초… 타이머를 길게 하면 AI가 덜 개입하긴 했지만, 개입할 때의 질문 자체는 여전히 어색하게 도움을 주려 했다. 타이밍 문제가 아니라 프롬프트 설계 문제였다.

그때 방향을 바꿨다. 직접 해결하려는 대신, 비슷한 걸 이미 만든 사람들이 어떻게 했는지 먼저 찾아보기로 했다.

3. 실제로 해 본 선택

GitHub에서 코딩 면접 시뮬레이터를 검색해 스타 수 기준으로 5개를 골라 프롬프트를 직접 읽었다.

IliaLarchenko/Interviewer ★92

가장 도움이 됐다. 핵심은 부정 지시의 반복이었다.

- Never provide hints or partial solutions
- Never repeat, rephrase, or summarize candidate
  responses
- Never provide feedback during the interview
- Never give away the solution or any part of it
- Never assume anything the candidate has not
  explicitly stated

“하지 마라”를 다섯 번 반복하고 있었다. LLM은 하나의 “하지 마라”로는 충분히 억제되지 않는다. 반복 자체가 강조 역할을 한다는 걸 배웠다.

두 번째로 배운 건 히든 노트 시스템이었다.

#NOTES#

AI 응답에서 #NOTES# 이후의 내용은 지원자에게 보여주지 않고 내부에서만 관리한다. 면접 중 지원자의 실수나 흐름을 AI가 메모하게 하고, 리포트 생성 시 이 노트를 참조하게 하는 방식이다.

adrianhajdin/ai_mock_interviews ★492

Zod 스키마로 피드백 구조를 강제하는 방식을 쓰고 있었다. 그리고 평가 프롬프트에 이런 문장이 있었다.

Avoid leniency; point out mistakes and areas
needing improvement.

현재 Recall 프롬프트에는 이 지시가 없었다. LLM은 기본적으로 관대하게 평가하는 경향이 있기 때문에, 명시하지 않으면 점수가 실제보다 높게 나온다.

FoloUp/FoloUp ★1,100

10점 스케일 루브릭이 인상적이었다.

10: Fully operational command, appropriate,
accurate, fluent
09: Occasional inaccuracies, handles complex
arguments well
...
01: Did not answer the questions

점수에 기준 설명을 붙이면 채점 일관성이 올라간다. “0-100 사이로 점수를 줘”라는 지시만으로는 AI마다, 세션마다 기준이 달라진다.

또한 supportingQuotes 구조를 쓰고 있었다.

{
  "supportingQuotes": [
    { "quote": "...", "analysis": "...", "type": "strength" }
  ]
}

AI가 지어내지 못하게 실제 대화에서 인용하게 강제하는 방식이다.

friedrichgeiecke/interviews ★49

비지시적 면접 방법론을 코드로 구현하고 있었다.

Maintain forward momentum. Do not return to
previously discussed topics.
Use assertive phrasing: "Tell me more about that"
(not "Can we discuss this?")

그리고 코드 기반 흐름 제어 패턴을 쓰고 있었다. AI 응답에 특수 코드를 삽입하면 프론트엔드가 이를 파싱해서 면접 단계를 전환하는 방식이다.

jiatastic/GPTInterviewer ★257

리포트에 모범 답안을 포함하는 방식을 쓰고 있었다.

Sample Answers: sample answers to each of the questions in the interview guideline.

지원자가 면접 후에 “이렇게 말했으면 더 좋았을 텐데”를 볼 수 있게 하면 학습 가치가 높아진다.

분석 후 도입한 것들

문제: AI가 계속 질문함 오픈소스에서 배운 것: 부정 지시 5회 반복 (IliaLarchenko) Recall에 적용한 것: “절대 힌트를 주지 마라” 3회 반복 추가

문제: 리포트 근거가 모호함 오픈소스에서 배운 것: supportingQuotes 구조 (FoloUp) Recall에 적용한 것: JSON 필드에 supportingQuotes 추가

문제: 점수 기준이 불명확함 오픈소스에서 배운 것: 점수별 앵커 루브릭 (FoloUp) Recall에 적용한 것: 80-100 우수, 60-79 양호 등 기준 명시

문제: 면접 중 실수 추적 안 됨 오픈소스에서 배운 것: #NOTES# 히든 노트 (IliaLarchenko) Recall에 적용한 것: 응답 파싱에 #NOTES# 구분자 도입

문제: AI가 관대하게 평가 오픈소스에서 배운 것: “관대하지 마라” 명시 (adrianhajdin) Recall에 적용한 것: 리포트 프롬프트에 동일한 지시

문제: 학습 자료 없음 오픈소스에서 배운 것: 모범 답안 포함 (GPTInterviewer) Recall에 적용한 것: sampleAnswer 필드 추가

코드 분석 프롬프트에는 “개입하지 않을 조건”을 명확히 나열했다.

// 이 조건이면 SKIP // - 코드가 활발히 작성되고 있음 // - 올바른 방향으로 진행 중 // - 단순 수정 (변수명, 들여쓰기, 주석) // // 이 조건일 때만 ASK // - 20초 이상 코드 변화 없고 막혀 보임 // - 명백히 잘못된 방향 // - 문제를 오해한 것으로 보임

“개입하라”보다 “개입하지 마라”의 조건을 더 자세히 쓰는 것이 효과적이었다.

4. 결과

#NOTES# 히든 노트 시스템은 리포트 품질을 크게 올렸다. 이전에는 리포트가 면접 전체를 막연하게 요약했다면, 이제는 “3번 질문에서 시간 복잡도를 잘못 계산했습니다”처럼 구체적인 근거가 생겼다.

부정 지시 반복 강화도 효과가 있었다. AI가 코딩 중에 먼저 끼어드는 빈도가 눈에 띄게 줄었다.

supportingQuotes 구조는 AI가 지어내는 걸 줄이는 데 도움이 됐다. 인용 필드를 강제하니 실제 대화에서 근거를 가져오는 경향이 생겼다.

아직 남은 문제

코드 분석 프롬프트는 여전히 완벽하지 않다. AI가 “막혀 있는지” 판단하는 건 여전히 어렵다. 30초 동안 코드를 안 썼어도 생각 중일 수 있고, 정말 막혔을 수도 있다. 이 판단을 프롬프트만으로 해결하기엔 한계가 있다.

5. 지금 다시 해본다면?

문제를 발견하자마자 직접 고치려 하지 말고, 먼저 비슷한 걸 만든 사람들이 어떻게 했는지 찾아봤을 것이다.

프롬프트 엔지니어링은 생각보다 이미 많은 선례가 있다. 특히 GitHub에서 실제로 동작하는 코드를 읽으면, 블로그 글보다 훨씬 구체적인 패턴을 얻을 수 있다.

그리고 하나 더. LLM에게 “하지 마라”를 한 번만 말하면 효과가 약하다. 같은 의미를 다른 표현으로 여러 번 반복하는 것이 단일 강조보다 훨씬 효과적이다. 이건 프롬프트 설계의 기본이지만, 오픈소스를 직접 읽기 전까지는 몰랐다.