Cover · Issue 006
"범용이 모르는 것은, 우리가 직접 기른 것들이다."
TSTF MAG · 2026
범용 AI는 거의 모든 걸 안다. 그런데 우리 게임의 10년 피드백 기록은 모른다. 그 '모름'이 경쟁력이 될 수 있다는 이야기.
팀 내 한 동료가 이런 질문을 꺼냈다. "LLM으로 결과물을 만드는 시대가 오면, 양질의 데이터를 기반으로 특화된 모델을 만들어야 하지 않을까?"
짧은 질문이었는데, 편집부 안에서 꽤 오래 맴돌았다. 그 이유를 생각해보니 — 이 질문은 "어떤 기술을 써야 하는가"가 아니라 "우리가 가진 것을 어떻게 봐야 하는가"라는 질문과 닿아 있었기 때문이다.
어떤 곳들은 이미 자기 데이터 위에서만 자라는 모델을 기르고 있다. 외부에 공개된 범용 모델에 전적으로 의존하는 대신, 자기 조직이 쌓아온 기록을 먹고 자라는 무언가를 만드는 방향이다. 이 방향이 옳은지 그른지는 아직 답이 없다. 하지만 "우리도 그 방향을 생각해야 하는가?" 라는 질문은 충분히 지금 꺼낼 만하다.
이번 호는 그 질문을 붙잡고 걸어본 기록이다.
범용이 모든 걸 알게 된 바로 그 순간,
"범용이 모르는 것"의 값이 올라간다.
이 글은 기술 소개가 아니다. 파인튜닝 방법론도, MLOps 스택 나열도 아니다. "우리한테 데이터가 있는가?" 라는 질문 하나를 천천히 들여다보는 에디토리얼이다.
지금 범용 AI는 대단히 많은 것을 안다. 어떤 게임이 왜 재미있는지, 레벨 디자인의 원칙이 무엇인지, 플레이어가 어느 순간 이탈하는지 — 수천 개의 포스트모템과 논문과 인터뷰를 읽은 것처럼 답한다. 그런데 딱 하나, 모르는 게 있다.
우리 팀의 기록이다.
매주 쌓인 리뷰 코멘트, 조용히 붙여진 스티커 메모, 아트 회의에서 남긴 한 줄짜리 반응들. 이것들이 어딘가에 쌓여 있다면, 그건 세상에 딱 한 곳에만 존재하는 신호다. 범용 AI는 이 신호를 본 적이 없다. 우리 팀만이 이 신호를 갖고 있다.
"이거 왜 이래요" 한 줄짜리 티켓도 수백 개 쌓이면 패턴이 된다. "레벨 5에서 막힌다", "캐릭터 A가 너무 약하다", "업데이트 후 소리가 이상해졌다" — 이런 불만들이 모이면, 우리 게임이 어디서 깨지는지를 보여주는 지도가 된다. 범용 AI는 이 지도를 본 적이 없다. 그런데 우리 CS 팀은 이미 갖고 있다.
"이 기능을 넣었더니 리텐션이 올랐다", "저 버그를 고쳤을 때 클레임이 반으로 줄었다", "이 아이템 밸런스를 바꿨을 때 유저 반응은 이랬다" — 이런 인과관계의 기록들이 빌드 노트와 리뷰 기록 안에 잠들어 있다. 범용 AI는 이 인과관계를 추론할 수 있지만, 우리 게임에서 실제로 일어난 것을 알지는 못한다.
출시된 게임에는 나타나지 않는 것들이 있다. "이 방식으로 만들었다가 버렸다", "이 아이디어가 왜 안 됐는지", "두 번 시도해보고 포기한 것들" — 이 실패의 아카이브야말로 우리 팀이 어디까지 생각해봤는지를 보여주는 가장 솔직한 기록이다. 어느 범용 AI도 우리 팀이 무엇을 포기했는지 알 수 없다.
"데이터를 많이 쌓아야 한다"는 말을 들을 때, 보통 양을 떠올린다. 로그가 많을수록, 티켓이 쌓일수록, 기록이 길수록 좋다고. 그런데 실제로 데이터가 쓸모를 갖게 되는 순간을 보면 — 그건 양이 아니라 맥락이 담겼을 때다.
이런 두 가지 기록을 비교해보자.
기록 A는 수백만 개가 있어도 혼자서는 별 의미가 없다. 기록 B는 한 줄짜리여도 의사결정에 쓸 수 있다. 차이는 맥락이다. "왜"와 "그래서"가 붙어 있는 기록이 데이터다. "왜"와 "그래서"가 없으면 그건 그냥 로그다.
대부분의 팀이 로그는 많이 갖고 있다. 데이터는 적게 갖고 있다. 그 간극을 좁히는 일이, 특화 모델을 만들기 전에 먼저 해야 할 일이다.
"왜"와 "그래서"가 붙어 있을 때,
로그는 비로소 데이터가 된다.
그리고 여기서 한 가지 각도를 더 얹으면 — 맥락이 담긴 기록을 만드는 건 자동이 아니다. 누군가가 레트로스펙티브 때 한 줄을 더 적어야 하고, 코드 리뷰에서 "왜 이렇게 바꿨는지"를 덧붙여야 하고, CS 티켓을 분류할 때 "이 유형의 불만이 늘었다"고 표시해야 한다. 그 한 줄들이 쌓인다. 그게 나중에 우리만 가진 신호가 된다.
"우리 데이터를 제대로 모으면 우리만의 AI를 만들 수 있다" — 이 말을 그대로 받아들이면, 몇 가지가 따라온다.
이 이야기를 TSTF 안으로 가져오면, 한 가지 작은 실험을 제안해볼 수 있다.
팀 안에서 누군가가 이런 질문에 한 줄씩 대답해본다면 어떨까.
이 질문들을 가져다 놓고 팀 안에서 답을 찾아본다면 — 우리 팀의 "데이터 현황"이 대략 보일 것이다. 그 현황을 보는 것 자체가 이미 시작이다.
첫 단계는 모델을 만드는 것이 아니다. "무엇이 우리 데이터인가"를 한 줄로 정의하는 일이다. 그 한 줄이 없으면, 아무리 로그가 쌓여도 데이터는 되지 않는다.
답을 정해두지 않은 질문들이다. 점심 자리에서, 스탠드업 직후에 한 번쯤 꺼내볼 수 있으면 좋겠다.
그것이 지금 어디에 있는지 알 수 있는가. 찾을 수 있는가. 찾지 못한다면, 그건 어디에 잠들어 있는 걸까.
결정을 내릴 때 그 이유를 기록으로 남기는 습관이 팀 안에 있는가. 있다면 누가 하고 있는가. 없다면, 왜 없는가.
파이프라인을 만들기 전에 먼저 해야 할 일이 있다면 무엇인가. 그 일을 가장 빨리 시작할 수 있는 사람은 누구인가.
이번 호는 팀 내에서 나온 한 줄짜리 질문에서 시작됐다. 그 질문이 편집부 안에서 오래 맴돈 것은, 기술 이야기처럼 들리면서 사실은 "우리가 가진 것을 어떻게 보느냐"는 태도의 이야기였기 때문이다.
편집부 입장에서 이 주제를 고른 이유는 하나다. 범용 AI가 더 강해질수록, 누구나 쓸 수 있는 도구의 값은 내려간다. 그때 남는 것은 "우리만 가진 것"이다. 그 "우리만 가진 것"이 지금 어디에 잠들어 있는지를 한 번쯤 들여다볼 만하다고 생각했다.
이 매거진이 하고 싶은 일은 정답을 배달하는 것이 아니다. 한 주에 한 번, 같은 질문을 함께 바라보자는 초대에 가깝다. 이번 호가 그 초대로 기능했다면 충분하다.
— Desk γAI 시대, 도구를 고르는 사람과 도구를 만드는 사람 사이의 거리에 대하여.