본문으로 건너뛰기
강의실강의실
AI Championship 2026 · wanted · KRAFTON

생성 수정

Wanted AI Championship 2026

주제 선정 전략

수상 가능성과 파트너사 채용 어필을 동시에 겨냥하는 분석 프레임워크

핵심 기조

파트너사가 만드는 서비스를 따라 만드는 것이 아니라,
파트너사가 뽑고 싶어 할 개발자의 역량이 드러나는 서비스를 만든다.

전략 목표

  • Competition

    심사위원이 좋은 프로젝트라고 판단하는가

  • Recruitment

    파트너사 엔지니어가 “이 팀과 한번 이야기해보고 싶다”고 느끼는가

전체 분석 구조

  1. 해커톤 분석
  2. 파트너 분석
  3. 채용 JD 분석
  4. 인재상 추출
  5. KDT 스택 매칭
  6. 주제 생성
  7. 100점 평가
  8. TOP 3
01

해커톤 기본사항 분석

먼저 대회의 공식 구조를 정확히 파악한다. 목적은 단순 일정 확인이 아니라, 이 대회의 성격과 평가 메커니즘을 역산하는 것이다.

  • 주최사·메인 파트너·파트너사
  • 참가 대상·팀 구성·일정·제출물
  • 예선/본선 구조와 심사기준
  • 사용자 투표 반영 여부
  • AI Builder Badge와 참가 이후 프로필 노출 구조
  • 수상 혜택 및 채용·네트워킹 연결 가능성

핵심 질문

이 대회가 순수 기술경진대회인지, 서비스 아이디어 대회인지, AI 인재 발굴형 행사인지 구분한다. 현재까지의 분석에서는 세 성격이 혼합되어 있으나 AI 인재 발굴·채용 연결 성격이 강한 편으로 본다.

02

Wanted가 이 해커톤을 왜 개최하는가

“원티드 = 채용 플랫폼”이라는 표면적 해석보다, 원티드가 현재 어떤 AI/AX 사업을 추진하고 있고 이 대회를 어떤 인재 생태계와 연결하려는지를 본다.

  • Wanted 기존 채용사업과 AI/AX 확장 방향
  • Ennoia 등 AI Agent/AX 사업
  • AI Builder·AI Native 인재 전략
  • 기업 대상 AX 사업과 AI 인재 수요
  • 해커톤 이후 참가자의 리더보드·프로필·채용 연결 구조
  • AI Builder Badge가 주는 포트폴리오 신호

핵심 가설

원티드가 발견하고 싶은 사람은 “AI를 사용할 줄 아는 사람”보다 “AI를 이용해 실제 문제를 정의하고 제품으로 구현할 수 있는 AI Native 인재”에 가깝다.

03

메인 파트너·파트너사 분석

파트너사 분석은 회사소개가 아니라 “어떤 사람을 뽑고 싶은 회사인가”를 찾는 작업으로 설계한다.

분석 항목확인 목적
주요 사업회사가 무엇으로 돈을 버는가
핵심 제품어떤 기술·제품을 만드는가
주요 고객어떤 산업 문제를 해결하는가
AI 전략AI를 어디에 투자하는가
최근 프로젝트앞으로 어디로 이동하는가
개발조직어떤 개발역량이 필요한가
채용공고실제 요구 역량이 무엇인가
기술 Stack어떤 기술을 운영환경에서 쓰는가
인재상어떤 문제 해결자를 채용하려 하는가

특히 현재·최근 채용공고(JD)를 우선적으로 본다. 회사 PR보다 “지금 이 회사가 어떤 문제를 해결할 사람에게 돈을 지급하려 하는가”를 더 직접적으로 보여주기 때문이다.

04

파트너사의 주요 거래처·고객 산업 분석

주요 거래처·고객 산업 분석의 목적은 파트너사의 고객 서비스를 복제하기 위해서가 아니다. 파트너사가 실제로 맞닥뜨리는 문제공간과 개발자의 업무 맥락을 추정하기 위해 사용한다.

  • 금융·게임·리테일·제조·SaaS·B2B Enterprise 등 주요 고객 산업
  • 고객별 데이터 환경·규제·운영 복잡도
  • PoC → 구축 → 운영으로 이어지는 개발 방식
  • 새로운 도메인 적응, 데이터 연결, 문제 정의, 고객 커뮤니케이션의 중요도

판단 원칙

주요 고객사는 “무엇을 만들지”를 정하는 자료가 아니라 “어떤 개발 역량이 현장에서 요구되는지”를 역산하는 보조자료로 사용한다.

05

파트너사가 원하는 AI 개발자 역량 추출

파트너사의 최근 JD와 개발자 인터뷰·기술 블로그에서 공통 키워드를 추출해 “파트너 채용 컬러 지도”를 만든다.

영역관찰할 키워드
AILLM · RAG · Agent · Multimodal · Embedding · Fine-tuning · Prompt Engineering
Agent EngineeringPlanning · Tool Calling · Memory · Agent Loop · Evaluation · Benchmark · Retry · Self-correction · Agent Harness
BackendPython · FastAPI · API · Async · WebSocket
DataMySQL/PostgreSQL · Elasticsearch · Vector DB · Data Pipeline
InfraDocker · AWS · Kubernetes · CI/CD · Monitoring
ProductProblem Definition · UX · Experiment · Evaluation · Production
06

KDT에서 배우는 기술과 파트너 요구역량 비교

KDT에서 배우는 기술을 “전부 사용해야 할 체크리스트”로 보지 않고, 파트너사의 요구역량과 겹치는 기술을 프로젝트의 설계 근거로 사용한다.

  • Python / FastAPI / React / Node.js
  • MySQL / Elasticsearch
  • Hugging Face / STT / OpenCV
  • WebSocket
  • Docker / AWS / Kubernetes

중요 원칙

“배웠기 때문에 넣었다”가 아니라 “이 문제를 해결하기 위해 필요해서 선택했다”가 되어야 한다. 사용하지 않은 기술도 왜 제외했는지 설명할 수 있어야 한다.

07

기존 KDT 프로젝트 주제 재평가

현재 KDT에서 제시된 전형적 주제는 교육용 프로젝트로는 적합하지만, 해커톤에서는 기술 신호와 제품 차별성이 약할 수 있다.

기존 주제한계해커톤형 발전 방향
Finance 소비분석단순 분석·시각화로 끝날 위험의사결정·실행까지 연결하는 Data Agent
Call Center 자동화일반 챗봇과 차별이 약함실시간 QA/Compliance + 후속 액션 Agent
리뷰 감정분석너무 흔한 분류 문제VOC 원인추론 → 담당부서 → 조치 → 검증
음성인식+대화분석STT 데모로 보일 수 있음대화 맥락 기반 Tool Calling/업무완료
Image+Text 상품검색유사 서비스가 많음멀티모달 검색 + 판단 + 실행 Workflow
08

해커톤에서 보여줘야 할 AI Native 개발자 정의

이번 프로젝트가 보여줘야 할 인재상은 단순한 LLM API 사용자가 아니라, 문제정의에서 운영까지 연결할 수 있는 AI Application/Agent/Product Engineer 계열이다.

정의

새로운 문제를 빠르게 이해하고 → AI가 해결할 수 있는 Task로 분해하고 → 적절한 Model과 Tool을 선택하고 → Backend·Data·Frontend를 연결해 실제 작동하는 Product를 만들고 → 결과를 평가하고 개선할 수 있는 개발자

  • AI Application Engineer
  • AI Agent Engineer
  • AI Product Engineer
  • FDE (Forward Deployed Engineer)
09

주제 선정 기준 정의

아이디어를 감으로 고르지 않고 동일한 100점 평가표에 넣어 비교한다. 기존 심사기준에 “파트너사 채용 어필력”을 명시적으로 추가한다.

평가 항목비중
문제의 명확성10
AI 사용 필연성10
서비스 가치10
Agent 기술력15
Evaluation 가능성10
실제 구현 가능성10
Demo 임팩트10
확장성5
Wanted 컬러 적합성5
파트너사 채용 어필15
합계100
10

주제 후보 10개 도출

파트너 분석과 인재상 정의가 끝난 뒤 주제 후보를 만든다. 특정 산업에 먼저 묶이지 않고, 다양한 문제공간에서 동일한 AI Native 역량을 증명할 수 있는 아이디어를 발굴한다.

  1. 01AI Incident Commander
  2. 02Self-Improving AI Agent
  3. 03AI Ops Worker / Digital Employee
  4. 04AI Research Agent
  5. 05Customer Intelligence Agent
  6. 06Personal Workflow Agent
  7. 07AI QA Agent
  8. 08AI Decision Agent
  9. 09Multimodal Agent
  10. 10Autonomous Data Analyst

여기서 중요한 것은 아이디어 이름보다 Architecture 안에서 어떤 역량을 증명하는지다.

11

각 후보의 Architecture까지 비교

후보별로 기능목록이 아니라 Agent의 제어구조와 실패 처리까지 비교한다.

  1. User Input
  2. Planner
  3. Agent
  4. Tools
  5. Execution
  6. Evaluator
  7. Re-plan
  8. Memory
  • 어떤 Tool을 호출하는가?
  • 무엇을 RAG 하는가?
  • Memory가 왜 필요한가?
  • Evaluation은 어떻게 하는가?
  • 실패 시 Re-plan은 어떻게 동작하는가?
  • Human Approval은 어디에 들어가는가?
12

TOP 3 선정

상위 3개 후보는 동일한 템플릿으로 정리해 선택 근거와 구현 리스크를 동시에 비교한다.

  • 왜 문제인가
  • 왜 AI가 필요한가
  • 주요 사용자
  • 핵심 Workflow
  • 핵심 Stack
  • Demo Scenario
  • 파트너사와의 연결
  • 채용 어필 포인트
  • 구현 난이도
  • 주요 위험요소

결정 기준

TOP 3는 “멋있어 보이는 아이디어”가 아니라 100점 평가표, 파트너사 JD 적합도, 팀 역량, 구현 기간을 함께 반영해 선정한다.

13

최종 선정 시 두 가지 KPI

이번 프로젝트는 단일 목표가 아니라 두 개의 KPI를 동시에 가진다.

KPI판정 질문평가 축
KPI 1 — Competition심사위원이 좋은 프로젝트라고 판단하는가기획 · 실현 가능성 · 기술 · 확장성 · 발표 · Demo
KPI 2 — Recruitment파트너사 엔지니어가 “한번 만나보고 싶다”고 느끼는가GitHub를 보고 싶은가 · Architecture를 질문하고 싶은가 · 기술적 의사결정을 물어보고 싶은가 · 실제 업무를 맡길 수 있다고 느끼는가

성공 시나리오

반드시 입상해야만 성공하는 것이 아니다. “입상 실패 + 파트너사 관심/채용 연결” 역시 이번 해커톤에서 유효한 성공 시나리오로 설정한다.

14

최종 산출물 및 의사결정 구조

최종 조사 결과는 다음 5개 산출물로 정리한다.

산출물내용
A. 해커톤 분석Wanted AI Championship은 어떤 대회인가
B. 파트너 인재지도각 파트너가 어떤 AI 인재를 원하는가
C. 기술역량 MatrixKDT에서 배운 기술과 기업 요구기술의 교집합
D. 주제 후보 Matrix10개 아이디어를 100점 기준으로 평가
E. 최종 TOP 3선정 근거 + Architecture + Demo Scenario
  1. 해커톤 분석
  2. Wanted의 목적 분석
  3. 파트너사 사업·고객 분석
  4. 파트너사 채용공고 분석
  5. 원하는 AI 개발자 역량 추출
  6. KDT Stack과 교집합 도출
  7. 그 역량을 증명할 주제 생성
  8. 수상 가능성 + 채용 어필력으로 평가
  9. TOP 3 선정

Final Principle

“파트너사가 만드는 서비스를 따라 만드는 것이 아니라,
파트너사가 뽑고 싶어 할 개발자의 역량이 드러나는 서비스를 만든다.”

전략 정리본  |  2026.08.25

※ 현재까지의 대화와 공개자료 분석을 토대로 정리한 프레임워크이며, 파트너사 전체 분석 완료 후 세부 우선순위는 조정될 수 있음