라이온하트 스튜디오가 올해 1월부터 3개월간 기획·테크 직군별로 AI 심화 교육을 진행했다. Claude, Gemini 등 최신 LLM을 활용한 프롬프트 설계, 워크플로우 제작, 코드 기반 개발까지—ZDNet 보도에 따르면 교육 녹화본을 전사 공유하는 수준까지 지원했다. AI 내재화에 진심인 게임사의 움직임이다.
솔직히 말하면, 이런 뉴스를 볼 때마다 나는 반사적으로 한 가지를 확인한다. 커리큘럼에 '비판적 사용'이 들어 있는가. 프롬프트 설계를 가르치는 건 좋다. 워크플로우 제작도 필요하다. 그런데 팀원이 AI의 답변을 그냥 믿어버리는 습관까지 함께 가르치고 있다면, 그 교육은 절반짜리다.
이게 단순한 우려가 아니다. LLM에는 구조적인 아첨 모드(Sycophancy)가 내장되어 있다. RLHF(인간 피드백 강화학습) 과정에서 모델은 사용자를 불편하게 만들지 않도록 튜닝된다. 그 결과 "Great question!"으로 시작해 무난하고 안전한 답변으로 끝나는 패턴이 기본값이 된다. dev.to에 올라온 한 엔지니어의 실전 사례가 이를 잘 보여준다—Docker 멀티스테이지 빌드를 최선으로 믿고 있던 그는, AI를 '기술 스파링 파트너'로 전환하고 나서야 자신의 접근이 문제를 절반만 풀고 있었다는 걸 깨달았다.
문제는 팀 전체가 AI의 첫 번째 답변을 정답으로 수용하는 문화다. 특히 교육 직후에는 더 그렇다. "AI가 그렇게 말했으니까"가 설계 결정의 근거가 되는 순간, AI는 생산성 도구가 아니라 책임 회피 도구가 된다. 라이온하트 스튜디오의 교육이 실무 활용 역량 강화에 주안점을 뒀다는 건 긍정적이다. 그런데 '활용'이 '수용'으로 미끄러지지 않으려면, 팀원이 AI 출력을 가설로 다루는 훈련이 병행되어야 한다.
그렇다면 실제로 팀에 어떻게 심을 수 있을까. 가장 효과적인 방법은 AI를 비판자로 설정하는 프롬프트 패턴을 팀 표준으로 만드는 것이다. "Please respond critically" 같은 막연한 지시는 효과가 없다. AI는 그냥 "다만 몇 가지 고려사항이 있습니다..." 수준의 면피성 문장을 덧붙일 뿐이다. 대신 구체적인 행동 규칙을 바인딩해야 한다—약점을 즉시 지목할 것, 실패 원인을 수치와 예시로 설명할 것, 대안을 제시할 때 그 대안의 약점도 함께 명시할 것. 마지막 규칙이 핵심이다. AI가 자신의 대안을 스스로 비판하게 만들어야 "AI가 말했으니 맞다"는 함정을 구조적으로 차단할 수 있다.
직군별로 접근이 달라야 한다는 점도 중요하다. 라이온하트 스튜디오가 기획·테크 직군을 나눠 교육한 건 올바른 방향이다. 다만 기획 직군에게 필요한 비판적 사용법은 코드 레벨이 아니라 요구사항 검증 레벨이다—"이 기능 명세의 엣지 케이스를 찾아라