2026-10-10 업데이트 — 공식 페이지가 바뀌었다. 10/10에 Cofa Probe 페이지와 Cofa 메인을 다시 읽었다. 9/28 작성 때 옮겨 적은 내용과 다른 점이 넷 있다.

  1. 모델 조건. 이 글은 처음에 “모델 성능과 범위에 제한을 두지 않는다”고 적었다. 지금 FAQ의 문구는 반대에 가깝다. “동일한 과제·작업 환경·모델을 제공해 같은 조건에서 문제를 해결하는 방식을 살펴봅니다.”(영문판: “the same task, workspace and model”). 그래서 2절과 6절을 고쳤다.
  2. 응시 감독이 생겼다. 응시 전에 카메라·권한·접속 상태를 확인한다. 응시 중에는 “과제에 설정된 감독 조건에 따라 카메라와 세션 기록 등을 확인”한다. 적용 범위는 “실제 응시 환경에 따른다”고 적혀 있다.
  3. 비개발 직무 과제가 생겼다. 개발 과제는 코드·문서·테스트가 갖춰진 IDE에서 푼다. 비개발 과제는 문서·AI 도구·업무 서비스로 푼다.
  4. 결과물이 면접 브리핑까지 간다. 이제 점수 리포트만 나오지 않는다. 후보별 확인 지점, 실제 작업에 연결된 질문, 면접용 응시자 링크까지 만든다.

3절의 충족·미충족 신호표, 4절 3번의 회색 지대 rubric 설명, 6절의 “Claude → GPT-5 비교” 예시는 현재 페이지에서 찾을 수 없다. 둘 다 9/28 당시 페이지 기준으로 남겨 둔다. 이전 페이지는 Wayback Machine에 스냅샷이 없어서 원문과 대조할 수 없었다. 이 점도 밝혀 둔다.

SK하이닉스 해커톤 응시자에게: 7월 Cofathon은 “제한 없는 AI 인프라”였고 로컬 하네스 업로드도 허용했다. 이 조건이 해커톤 예선에도 그대로 적용된다고 기대하지 말 것. 허용 도구는 주최 측 안내를 기준으로 한다.

크래프톤이 만든 Cofa-Probe는 AI 활용 역량 평가 도구다. 코딩 테스트처럼 정답을 채점하지 않는다. 지원자가 AI와 어떻게 일했는지를 기록해서 채점한다. 크래프톤 자체 채용, CJ 올리브영 경력 개발자 채용에 이어 SK하이닉스 AI 해커톤 2026의 평가에도 쓰인다(BusinessKorea).

이 글은 공개 자료만으로 이 도구가 무엇을 기록하고, 어떻게 채점하고, LLM 채점의 한계를 어떻게 막는지 정리한 것이다. 결론부터 적으면 이렇다.

  • 평가 축은 셋이다. 기술 관리(산출물을 직접 장악하는가), 의도 관리(AI를 조향하고 검증하는가), 인지 관리(자기 산출물을 설명할 수 있는가).
  • 증거는 자동 수집된다. 코드뿐 아니라 대화 기록, 프롬프트, 도구 설정, 검증 실행 흔적까지 남는다. 과제가 끝나면 사후 Q&A가 이어진다.
  • LLM 채점이 매번 다르게 나오는 문제는 “메타 하네스”로 푼다. 기준과 점수 변환처럼 일관성이 필요한 부분은 코드가 맡고, 맥락 판단만 LLM이 맡는다.

1. 무엇인가

  • 만든 곳: 크래프톤 AI Frontier 부문. OpenAI와 파트너로 만들었고, OpenAI Codex로 개발했다고 한다(Sedaily, BusinessKorea).
  • 제품 구성: 채용 플랫폼 Cofa의 평가 모듈이다. 인재를 찾는 Sourcer와 역량을 검증하는 Probe로 나뉜다(Cofa).
  • 쓰인 곳:
    • 크래프톤 정규 채용. 연구원·엔지니어뿐 아니라 비개발·백오피스 직군까지 쓴다(Cofa Probe).
    • CJ 올리브영 경력 개발자 채용. 라이브 코딩 테스트를 대신하는 “AI 과제” 전형으로 들어갔다(Edaily).
    • 크래프톤·올리브영 공동 해커톤 “Cofathon”(Gamemeca).
    • SK하이닉스 AI 해커톤 2026. 문제 정의, AI 활용, 결과 검증을 종합 평가하는 데 쓴다(BusinessKorea).

2. 평가 환경 — 같은 출발선, 실제 도구

지원자는 브라우저 웹 IDE에서 과제를 푼다. 공식 설명의 핵심은 세 가지다(Cofa Probe).

  • mock이 아닌 실제 API와 실제 컴퓨트 환경에서 작업한다.
  • 시간과 토큰 예산이 정해져 있다.
  • 모델 성능과 범위에 제한을 두지 않는다. → (10/10 정정) 현재 FAQ에 따르면 모든 응시자가 동일한 과제·작업 환경·모델을 받는다. 모델을 고르는 능력이 아니라, 같은 모델로 일하는 방식을 비교하겠다는 설계다(Cofa Probe).

서울경제 보도는 이 환경을 “AI 엔지니어의 실제 업무를 닮은 가상 환경”이라고 설명한다. 지원자는 그 안에서 여러 작업 에이전트와 상호작용하며 문제를 찾고 푼다(Sedaily).

두 번째 점이 중요하다. 토큰 예산이 있다는 건 “AI에게 끝없이 다시 시켜서 맞히기”가 통하지 않는다는 뜻이다. 제한된 자원 안에서 AI의 장점과 한계를 운용하는 능력을 본다고 명시돼 있다.

3. 무엇을 채점하나 — 세 축

공식 페이지는 AI 네이티브 역량을 세 축으로 정의한다(Cofa Probe).

축 질문 무엇으로 보나
기술 관리 (Technique) AI가 만든 산출물을 본인이 직접 장악했는가 산출물·코드: 실제로 돌아가는가, 유지 가능한 구조인가, 시크릿·민감정보가 코드나 로그로 새지 않는가
의도 관리 (Intent) AI에게 일을 맡기고 조향했는가 행동 기록: 목표와 제약을 정의했는가, 작업을 쪼개 위임했는가, 검증 루프로 결과를 통제했는가
인지 관리 (Cognition) 자기 산출물을 이해하는가 사후 답변: 왜 이 구조인지, 어떻게 동작하는지, 어디서 깨지는지 설명할 수 있는가

보도에서는 같은 내용을 네 범주로 나눠 설명하기도 한다(Sedaily). 문제 정의와 우선순위, AI 협업과 지시의 질, 근거 수집과 의사결정, 반복 개선과 오류 복구다.

공개된 충족·미충족 신호가 특히 구체적이다(Cofa Probe).

충족으로 보는 신호 미충족으로 보는 신호
완료 조건과 수용 기준이 명시된 프롬프트 “알아서 잘 만들어줘”식 통짜 위임
실패 → 수정 → 같은 검증으로 재통과한 기록 AI의 완료 보고를 검증 없이 수용
결정 이유와 기각한 대안의 기록 교과서 일반론으로 채운 답변
새 세션이 이어받을 수 있는 의도 문서(예: CLAUDE.md) 없는 파일·API를 인용하는 설명
실제 제출물과 일치하는, 본인 산출물 기준의 답변 도구·MCP 남발로 흐려진 신호

사후 답변 전체에도 공통 기준이 걸린다. 실제 제출물과 모순되지 않는가, 일반론이 아니라 본인 산출물 기준인가, 없는 것을 지어내지 않는가, 권위가 아니라 증거로 추론하는가. 눈에 띄는 건 마지막 두 줄이다. AI가 흔히 하는 실수(환각, 근거 없는 확신)를 사람에게도 똑같이 감점한다.

10/10 현재 Cofa 메인에는 신호표 대신 프롬프트 예시 한 쌍이 실려 있다(Codex CLI 화면).

  • 좋은 예: “로그인 실패 원인을 먼저 찾아줘. 기존 인증 방식은 바꾸지 말고, 수정 전에 원인과 변경 범위를 알려줘. 수정 후 같은 테스트로 다시 확인해줘.” 원인·범위 확인, 보존할 제약, 테스트 재확인이 다 들어 있다.
  • 나쁜 예: “로그인이 안 돼. 알아서 고쳐줘. 다른 부분도 괜찮게 정리해줘. 테스트는 나중에 할게.” 범위 없는 위임, 제약 없는 변경 허용, 테스트 없는 완료 수용이다.

4. 어떻게 채점하나 — LLM 채점의 한계를 코드로 막는다

AI 활용 과정을 사람이 전부 읽고 채점하기는 어렵다. 그래서 채점도 LLM이 한다. 그런데 LLM은 같은 제출물에 매번 다른 점수를 줄 수 있다. 크래프톤은 이 문제를 이렇게 다뤘다고 한다(Sedaily).

  1. 메타 하네스: AI 채점 에이전트의 실행 구조를 반복적으로 시험하고 다듬는 틀을 씌웠다. 목표는 재현성과 변별력이다.
  2. 역할 분리: 일관성이 필요한 평가 기준과 점수 변환은 코드로 통제한다. 맥락을 읽어야 하는 정성 판단만 LLM 에이전트가 한다.
  3. 세부 rubric: 기준마다 회색 지대(grey area)와 충족·미충족 예시가 정의돼 있다. 점수 근거로 해당 프롬프트와 소스코드를 함께 제시한다(Cofa Probe).
  4. 면접 리포트: 채점 결과는 합격·불합격이 아니라 면접관을 위한 참고 리포트로 나온다(Sedaily).

2번은 LLM을 운영에 붙일 때 가장 자주 쓰는 원칙과 같다. 나도 보안 에이전트 WATCHMAN과 SENTINEL을 만들 때 같은 구조를 썼다. 분류값은 열거형으로만 받는다. 근거는 실제로 수집한 증거 키만 인용하게 하고, 검증을 통과하지 못하면 규칙 분류로 떨어진다. LLM에게 판단을 맡기되, 판단의 틀은 코드가 쥔다. 채점 도구도 같은 결론에 도착했다는 점이 흥미롭다.

5. 이 도구가 바꾸는 것

① 코딩 테스트의 자리가 바뀐다. 올리브영은 경력 개발자 채용에서 라이브 코딩 테스트를 “AI 과제”로 대체했다(Edaily). AI가 코드를 쓰는 시대에 “손으로 알고리즘을 푸는가”보다 “AI가 쓴 코드를 믿을 근거를 만드는가”를 보겠다는 것이다.

② 과정이 곧 결과물이 된다. 대화 기록과 검증 흔적이 자동으로 수집되니, 지원자가 과정을 따로 서술할 필요가 없다. 거꾸로 말하면 과정을 꾸며서 보여 줄 수도 없다. 평소에 AI와 일하는 습관이 그대로 드러난다.

③ 설명할 수 없는 산출물은 감점이다. 사후 Q&A에서 “어디서 깨지는가”를 묻는다. AI가 만든 코드를 그대로 붙여 넣은 사람은 여기서 걸린다.

6. 한계와 열린 질문

  • rubric의 세부 가중치는 공개되지 않았다. 이 글은 공식 페이지와 보도에 근거한다. 실제 점수 산정 방식은 모른다.
  • “같은 출발선”의 범위. 모델 선택에 제한이 없다고 하지만 … 어떤 모델을 고르느냐 자체도 평가 대상일 수 있다. (10/10 정정) 현재 공식 FAQ는 모든 응시자에게 같은 모델을 준다고 적고 있다. 그러니 모델 선택은 변수가 아니다. 남는 변수는 정해진 시간과 토큰 한도 안에서 어떻게 지시하고 검증하느냐다. 다만 Cofathon은 “NO RULE”을 내걸고 로컬 하네스까지 허용했다. 같은 Probe라도 행사·고객사마다 조건이 다르게 설정될 수 있다는 뜻이다.
  • LLM 채점자는 여전히 LLM이다. 메타 하네스로 재현성을 높였다지만 독립 검증 결과는 찾지 못했다. 크래프톤이 리포트를 “면접 참고용”으로 둔 것도 이 한계를 인정한 설계로 보인다.
  • “도구·MCP 남발은 감점”의 경계. 도구를 많이 쓰는 게 나쁜 게 아니라 신호가 흐려지는 게 나쁘다는 뜻이다. 그 선이 어디인지는 회색 지대다.

정리

Cofa-Probe가 채점하는 건 AI를 잘 부리는 능력이 아니다. AI를 믿지 않고 검증하는 능력이다. 완료 조건을 먼저 적고, AI의 “다 됐습니다”를 테스트로 다시 확인하고, 기각한 대안을 남긴다. 그리고 마지막에 내 산출물이 어디서 깨지는지 내 말로 설명한다. 좋은 엔지니어가 원래 하던 일에, AI라는 동료가 하나 늘었을 뿐이다.

References