CAMT 개발일지 — "AI를 얼마나 잘 쓰는가"를 면접 전에 확인하는 시스템 만들기
📌 한 줄 요약: 채용 과정에서 “이 사람이 실무에서 AI를 얼마나 잘 쓰는가”를 확인할 방법이 없어서, AI와 실제로 대화하며 주어진 과제를 해결하는 모습을 그대로 채점하는 사전진단 시스템(CAMT)을 만들었습니다. 이 글은 기획부터 배포·보안 조치까지, 그리고 개발 중 실제로 터진 문제 4가지를 정리한 개발일지입니다.
왜 이 시스템을 만들었나
채용 과정에서 “이 사람이 실무에서 AI를 얼마나 잘 활용할 수 있는가”를 확인할 방법이 마땅치 않았습니다.
이력서와 포트폴리오로는 알 수 없고, 면접에서 몇 마디 물어보는 것만으로는 실제 업무 상황에서의 AI 활용 수준을 가늠하기 어렵습니다. 대기업들이 AI 활용 능력을 채용 평가 항목에 넣기 시작했다는 사례를 접하고, 우리도 면접 전 단계에서 지원자가 AI와 실제로 대화하며 업무 과제를 해결하는 모습을 보고자 했습니다.
핵심 아이디어는 단순했습니다.
- 지원자가 AI와 나눈 대화 전체를 기준에 따라 채점한다
- 그 결과를 면접관에게 넘겨준다 (점수 + 근거 + 추천 질문)
그렇게 시작된 것이 CAMT(Cmath AI Management Test) 입니다.
| 항목 | 내용 |
|---|---|
| 프로젝트명 | CAMT (Cmath AI Management Test) |
| 기간 | 2026년 9월 |
| 형태 | Next.js + Prisma/SQLite + Claude API 기반 웹앱 |
| 구성 | 지원자용 채팅 평가 화면 · 면접관용 결과 대시보드 · 관리자모드 |
1단계. 기획안 수립
가장 먼저 기획안을 정리하고 PPT 제안서를 만들었습니다. 핵심 골자는 이렇습니다.
- 지원자는 자신의 채용부문(영업팀 · 마케팅팀 · 콘텐츠개발팀 · 경영관리부서) × 신입/경력에 맞는 실무형 과제를 배정받는다
- 과제를 지필로 풀게 하는 게 아니라, AI와 실제로 채팅하며 해결하게 한다
- 대화가 끝나면 AI가 대화 전체를 읽고 5개 영역으로 채점한다
- 점수뿐 아니라 대화 근거를 인용한 피드백, 강점/보완점, 면접관 추천 질문까지 자동 생성해 리포트로 제공한다
채점은 5개 영역 — 프롬프트 설계력 · 결과 검증/수정력 · AI 협업 시나리오 대응 · 데이터/업무 활용력 · AI 윤리/한계 인지
5개 영역은 각각 따로 점수를 매기는 게 아니라, 하나의 대화를 여러 각도에서 읽는 렌즈에 가깝습니다. 같은 대화에서 “프롬프트를 어떻게 구성했는지”와 “결과를 어떻게 검증했는지”를 동시에 봅니다.
채점이 끝나면 면접관에게는 이런 리포트가 넘어갑니다. 종합점수와 함께 5개 영역별 분포(레이더 차트), 대화를 근거로 쓴 종합 총평, 강점·보완점이 한 화면에 정리됩니다.
개별 결과 리포트 — 종합점수(예: 90.0/100) · 영역별 점수 분포 · 종합 총평 · 강점·보완점
점수만 던져주는 리포트는 면접에 도움이 되지 않습니다. 점수가 어디에서 나왔는지가 보이지 않으면 신뢰할 수 없기 때문입니다. 그래서 종합 총평은 지원자가 실제로 한 대화를 인용해 서술하고, 강점·보완점은 영역별 점수와 함께 문장으로 풀어 씁니다.
리포트 하단에는 면접관 추천 질문 5개와 지원자에게 부여된 과제 원문이 함께 붙습니다. 면접관이 “무엇을 물어봐야 하는지”까지 시스템이 제안하는 구조입니다.
리포트 하단 — 면접관 추천 질문 5개 + 지원자에게 부여된 과제 원문(상황·데이터·최종 제출물)
특히 신경 쓴 부분이 면접관 추천 질문입니다. 지원자가 실제로 나눈 대화에서 출발해 “이걸 물어보면 실체가 드러난다” 싶은 질문 5개를 자동으로 만듭니다. 아래에는 지원자가 받았던 과제 원문(상황·데이터·해야 할 일·최종 제출물) 이 그대로 붙어 있어서, 면접관이 별도 자료 없이 맥락을 바로 잡을 수 있습니다.
여기서 한 가지 중요한 결정이 있었습니다. 처음엔 AI 활용능력 + 인적성검사를 함께 보는 구조였는데, 실사용 테스트를 해보니 목적이 흐려진다고 판단해 인적성검사를 완전히 빼고 AI 활용능력 100점 만점 단일 평가로 재구성했습니다.
2단계. 개발 — 여러 번의 방향 전환
처음부터 지금 형태로 만들어진 건 아니었습니다. 실사용을 테스트하면서 구조를 꽤 여러 번 갈아엎었습니다.
CAMT 전체 흐름 — 입장 → 부서별 과제 → AI 실시간 대화 → 대화 전체 채점 → 면접관 리포트
평가 시간은 30분입니다. 그 안에서 지원자는 과제를 읽고, AI와 대화해 결과물을 완성합니다.
실제 지원자는 이렇게 시작합니다. 채용부문(영업팀 · 마케팅팀 · 콘텐츠개발팀 · 경영관리부서)과 신입/경력을 선택하면, 그에 맞는 실무형 과제가 배정됩니다.
응시 전 기본 정보 입력 화면 — 부문과 신입/경력을 고르면 AI 활용능력 평가 30분이 시작됩니다
입력 항목은 이름 · 채용부문 · 신입/경력 세 가지뿐입니다. 부문은 영업팀 · 마케팅팀 · 콘텐츠개발팀 · 경영관리부서 4개 중에서 고르고, 여기서 선택한 조합에 따라 배정되는 과제가 달라집니다. 지원자가 따로 준비할 것은 없습니다.
과제가 시작되면 지원자는 과제 본문과 AI 대화창이 함께 있는 화면을 보게 됩니다.
실제 응시 화면 — 과제 본문을 읽고, 하단 입력창에서 AI와 실시간으로 대화하며 문제를 해결합니다 (30분 타이머)
화면은 일부러 단순하게 유지했습니다. 상단에 부문·경력과 남은 시간(30분), 위쪽에 과제 본문([핵심 과제] → [상황·데이터]), 아래쪽에 AI와 대화하는 입력창입니다. 과제 본문은 스크롤되게 만들어서, 데이터가 길어져도 채팅 영역을 가리지 않습니다.
① “5개 서면 문항” → “1개 실시간 대화 과제”로 전환
원래는 5개 영역별로 각각 서면 프롬프트를 작성하게 하는 방식이었습니다. 그런데 이건 “AI에게 뭘 쓸지 설명하는” 것이지 실제 AI 활용이 아니었습니다.
그래서 부서별로 현실적인 데이터가 포함된 과제 하나를 주고, 그 안에서 AI와 실시간으로 대화하며 해결하도록 바꿨습니다. 채점도 문항별이 아니라 대화 전체를 홀리스틱하게 읽고 채점하는 방식으로 바뀌었습니다 — 실무에서 AI 활용은 한 번의 질문이 아니라 대화의 흐름이기 때문입니다.
② AI 제공사 교체
처음엔 DeepSeek로 시작했다가 Claude(Anthropic)로 전환했습니다. 전환 과정에서 추론형 모델 특유의 API 차이를 하나씩 겪으며 고쳤고, 이 과정은 아래 “실사용 테스트에서 발견된 문제들”에 자세히 정리했습니다.
③ 배포 방식 시행착오
처음엔 같은 사무실 Wi-Fi로 공유하려 했으나 AP 격리 때문에 접속이 막혔습니다. 최종적으로 Tailscale Funnel을 이용해 별도 소프트웨어 설치 없이 접속 가능한 공개 HTTPS 링크로 전환했습니다.
⚠️ 다만 이 방식은 사내망 전용이 아니라 인터넷 전체에 공개되는 방식이라는 점을 인지하고 사용 중입니다. 그래서 뒤에 나오는 보안 조치(비밀번호 잠금)가 필요했습니다.
④ 관리자모드 추가
지원자 이름 오타 수정, 직군별 문항 편집, 신규 직군 추가가 필요해지면서 관리자모드를 추가했습니다. 이 과정에서 기존에 코드에 하드코딩돼 있던 부서/문항 데이터를 전부 DB로 옮기는 작업도 함께 했습니다.
관리자 모드 — 지원자 이름 수정(오타 보정) · 직군별 문항 편집(과제 내용·채점기준) · 채용 부문 추가
관리자 모드에서 할 수 있는 일은 세 가지입니다. ① 지원자 관리 — 응시자 이름 오타를 바로잡습니다. ② 문항 관리 — 직군별로 배정되는 과제 내용과 채점 기준을 수정합니다. ③ 부문 관리 — 새로운 채용 부문(직군)을 추가합니다.
처음엔 부서·문항 데이터가 코드에 하드코딩돼 있었는데, 관리자모드를 만들면서 전부 DB로 옮겼습니다. 이제 문항 하나를 고치기 위해 코드를 건드릴 필요가 없습니다.
3단계. 실사용 테스트에서 발견된 문제들
가장 값진 부분은 실제로 테스트를 돌려보면서 나온 문제들이었습니다.
문제 1. 채점이 조용히 “가짜 결과”로 대체되고 있었다
한 지원자의 결과를 보니 API가 적용 안 된 것처럼 보였습니다. 원인을 파고들어 보니 Claude API 호출에서 여러 문제가 겹쳐 있었습니다.
| 문제 | 내용 |
|---|---|
temperature 거부 |
추론형 모델은 temperature 파라미터를 받지 않음 |
| 프리필 거부 | 어시스턴트 턴을 미리 채워 넣는 기법 불가 (대화가 반드시 사용자 턴으로 끝나야 함) |
| 응답 잘림 | max_tokens가 낮아 모델이 내부 추론에 토큰을 쓰다가 실제 응답이 중간에 잘림 |
세 가지를 실제 API에 직접 호출해보며 재현하고 고쳤습니다. 이 사건에서 배운 가장 중요한 교훈은 — “고쳤다”는 확신은 별도 테스트 스크립트가 아니라, 실제 서비스 코드 경로를 다시 실행해서 확인해야 한다는 것이었습니다.
처음엔 독립적인 디버그 스크립트로만 검증했다가, 실제 지원자 결과는 여전히 고쳐지지 않은 채 남아있던 적이 있었습니다.
문제 2. 문항이 너무 불친절했다
초기 테스트에서 “아무 데이터도 안 주고 문제를 풀라니 의미가 없다”는 피드백을 받았습니다. 전면 재작업을 통해 모든 과제에 구체적인 수치 데이터(정답률·예산·이탈률 등)를 넣고, 각 과제 맨 앞에 “[핵심 과제] 한 줄 요약”을 붙여 무엇을 해야 하는지 한 번에 이해되도록 고쳤습니다. 콘텐츠개발팀 과제도 실제 회사 주력 상품인 초등 사고력 수학을 반영하도록 다시 썼습니다.
문제 3. 대화가 길어지면 AI가 아예 응답을 못 하는 버그
한 지원자가 대화 중반부터 5번 연속으로 “(응답을 생성하지 못했습니다)”를 받고 과제를 포기하는 사고가 있었습니다.
재현해보니 원인은 이랬습니다. 추론형 모델이 답변 전 내부적으로 하는 “생각(thinking)”의 길이가 대화가 길어질수록 예측 불가능하게 늘어나면서, 정해둔 토큰 한도를 추론만으로 전부 써버리고 정작 답변 텍스트는 한 글자도 못 만드는 상황이었습니다.
단순히 토큰 한도를 올리는 것만으론 완전히 해결되지 않는다는 것도 재현 테스트로 확인했고, 최종적으로는 모델의 추론량을 직접 제어하는 옵션을 적용하고, 품질 우선 → 안전 우선으로 단계적으로 재시도하는 방식으로 해결했습니다.
수정 후에는 문제가 됐던 지원자의 실제 대화를 진짜 운영 API로 그대로 재생해서 전부 정상 응답이 나오는 것까지 확인한 뒤 배포했습니다.
이 일로 인해 해당 지원자가 AI 응답 오류 때문에 실제 역량과 무관하게 낮은 점수를 받은 것도 함께 확인했습니다. 시스템 버그가 평가 결과를 왜곡시킬 수 있다는 걸 보여준 사례였습니다.
문제 4. AI가 그림을 그려줄 수 없다는 것을 지원자가 몰랐다
도형 추론 문제를 풀던 지원자가 “그림도 그려줄 수 있어?”라고 물었습니다. 하지만 Claude는 실제 이미지 파일을 생성하는 기능이 없는 모델입니다(유료/무료 여부와 무관).
지원자가 혼란을 겪을 수 있어, 관련 과제 브리핑에 “AI에게 그림을 요청하지 말고, 도형의 모양·배치를 말로 설명해달라고 요청하라”는 안내를 추가했습니다.
4단계. 배포 후 보완 — 보안
내부 테스트가 끝난 뒤에는 공개 링크로 누구나 접속 가능한 상태가 부담스러웠습니다. 그래서 홈 화면의 3가지 메뉴(응시 시작 · 결과 대시보드 · 관리자모드) 전체를 비밀번호로 잠갔습니다.
CAMT 시작 화면 — 응시 시작 / 결과 대시보드 / 관리자모드 3개 메뉴 전체가 비밀번호로 잠겨 있습니다
비밀번호 없이 링크만 받은 사람(또는 AI)이 볼 수 있는 건 로고가 있는 첫 화면뿐이고, 실제 채팅 UI · 과제 내용 · 채점 로직은 전부 비밀번호 뒤에 있습니다.
5단계. 만든 결과물
- CAMT 기획안 (PPT)
- CAMT 시스템 — Next.js + Prisma/SQLite + Claude API 기반 웹앱
- 지원자용 채팅 평가 화면
- 면접관용 결과 대시보드
- 관리자모드
- 응시자 매뉴얼 (PPT)
- 대표이사 시연용 “채점 방식 & 결과분석 안내” 자료 (PPT)
- 부서별 시연용 테스트 프롬프트 (영업팀 신입 등)
면접관·관리자가 보는 결과 대시보드는 지원자 목록과 상태(응시 중 · 채점 완료), 총점을 한눈에 보여줍니다.
결과 대시보드 — 지원자 이름 · 채용부문 · 신입/경력 · 응시일시 · 상태 · 총점 (관리자 설정에서 문항 편집·신규 응시 시작도 가능)
목록에서는 “응시 중”과 “채점 완료”가 구분됩니다. 아직 검사가 끝나지 않은 지원자는 응시 중으로 표시되고 총점이 비어 있으며, 채점이 끝나면 점수가 채워집니다. 면접관은 이 목록에서 지원자를 골라 개별 리포트로 들어갑니다.
돌아보며 — AI 시스템의 버그는 “안 보이게” 실패한다
이 프로젝트를 하면서 가장 크게 배운 건, AI 기반 시스템의 버그는 “안 보이게” 실패한다는 점이었습니다.
화면은 멀쩡히 뜨는데 채점만 가짜 데이터로 대체되어 있거나, 지원자가 몇 번이나 오류를 겪었는데도 시스템 로그를 직접 들여다보기 전까진 몰랐습니다.
그래서 이번 개발에서는 “고쳤다”고 말하기 전에 실제 운영 코드 경로로 재현·검증하는 것을 원칙으로 삼았습니다. 그 결과 지금은 실제 지원자가 겪었던 모든 실패 케이스를 재현해 정상 동작을 확인한 상태로 운영 중입니다.
앞으로는 실제 채용 현장에서 CAMT를 활용하며 나오는 피드백을 계속 반영해나갈 예정입니다.
이번 프로젝트에서 남은 3가지 원칙
- AI를 쓴다는 것을 “설명”하게 하지 말고, 실제로 쓰게 하라 — 서면 프롬프트 작성은 AI 활용이 아니다
- 고쳤다는 확신은 테스트 스크립트가 아니라 운영 코드 경로로 검증하라 — 디버그 스크립트만 통과한 수정은 수정이 아니다
- 자동화된 평가일수록 실패가 조용하다 — 사람이 눈으로 확인하지 않으면 점수 왜곡을 못 잡는다