Cover · Issue 008
"빈 종이 앞에서, 첫 번째 글자를 누가 쓰는지가 달라졌다."
TSTF MAG · 2026
AI가 초안을 쓰고 사람이 다듬는 흐름이 표준이 되어가는 지금, "작성자"라는 말의 무게는 어디로 옮겨갔는가. 시작 버튼을 누르는 손에서, 남기고 버릴 것을 고르는 손으로.
한동안 "쓴다"는 행위는 그 자체로 시작의 증거였다. 빈 화면을 채우는 사람이 작성자였고, 첫 줄을 만들어낸 손이 책임을 가져갔다.
기획서를 처음 열고 첫 문장을 타이핑하는 사람. 빈 캔버스에 첫 스케치를 그리는 사람. 새 파일을 만들고 첫 함수를 선언하는 사람. 이 행위들은 모두 같은 무게를 가졌다. "내가 시작했다"는 사실 안에, "내가 책임진다"는 의미가 함께 들어 있었다.
그런데 지금은 다르다. 프롬프트 하나를 입력하면 10초 안에 3페이지 분량의 초안이 나온다. 기획 방향 한 줄을 넣으면, 섹션별로 정리된 목차와 각 항목의 설명이 따라온다. 레퍼런스 이미지 하나를 올리면, 비슷한 스타일의 시안이 쏟아진다. 코드의 경우는 더 극단적이다. 원하는 기능을 설명하면, 구조가 잡힌 코드 블록이 즉시 완성된다.
이 흐름에서 "시작 버튼을 누른 사람"은 여전히 존재한다. 그런데 그 사람이 만들어낸 것은 초안이 아니다. 초안을 요청하는 문장이다. 처음의 행위가 달라졌다. 그리고 그 달라짐이 작성자의 의미를 조용히 흔들기 시작했다.
이 변화는 특정 직군의 이야기가 아니다. 게임 개발 현장 전체에 동시에 번지고 있는 질문이다.
게임 기획자가 시스템 설계를 시작하는 방식이 달라졌다. 예전에는 노션이나 엑셀을 열고 직접 구조를 잡았다. 지금은 "전투 루프의 핵심 변수 목록을 뽑아줘"라고 입력하고 결과를 받아서 다듬는다. AI가 제안한 변수 중 어떤 것을 남길지, 어떤 것을 버릴지, 어떤 것을 다시 쓸지를 고른다. 이 선택들이 기획서를 만든다.
프로그래머도 비슷하다. 함수를 직접 타이핑하는 대신, 원하는 동작을 설명하고 생성된 코드를 검토한다. 로직이 맞는지, 엣지 케이스를 놓쳤는지, 팀의 코드 스타일과 맞는지를 따져본다. 이 검토 과정이 지금의 "코딩"에서 가장 많은 시간을 차지하기 시작했다.
아트 쪽은 더 이전부터 이 흐름 안에 있었다. 레퍼런스 이미지를 입력하고 AI 시안을 받은 뒤, 거기서 방향을 골라 다듬는 방식이 이미 많은 팀에서 일상이 됐다. 처음부터 직접 그리는 것과, AI 출력물을 재료로 삼는 것. 두 작업의 결과물은 같은 파일로 남는다.
"내가 만들었다"는 말이 세 직군 모두에서 같은 도전을 받고 있다. 첫 번째 줄을 타이핑한 사람이 작성자라면 — 지금 그 줄을 타이핑한 건 AI다. 그런데 방향을 잡고, 범위를 정하고, 결과물을 보고 다음 요청을 만든 건 사람이다. 둘 중 어느 쪽이 "쓴 것"인가.
AI가 초안을 만들어주는 세상에서 가장 달라진 것은 공급이다. 재료가 넘쳐난다. 기획 아이디어가 30초 안에 열 가지 나온다. 코드가 몇 가지 버전으로 동시에 생성된다. 시안이 한 번에 여러 장 쏟아진다.
그런데 재료가 많아질수록, 고르는 일이 쉬워지지는 않는다. 오히려 더 무거워진다.
선택지가 하나였을 때, 그 안에서 최선을 다하면 됐다. 선택지가 열 개가 되면, 열 개를 모두 읽고 어떤 기준으로 고를지를 먼저 정해야 한다. 그 기준이 없으면 고를 수 없다. 고르지 못하면 재료는 쓰레기가 된다.
기획 문서로 치면 이렇다. AI가 쓴 초안 열 페이지 중에서 진짜로 쓸 수 있는 두 페이지를 고르는 판단. 코드라면, 생성된 세 가지 구현 중에서 우리 팀의 구조에 맞는 것을 가려내는 판단. 아트라면, 방향이 맞는 시안을 알아보는 눈.
이 판단들이 지금 "작성자"가 하는 일의 핵심이 됐다. 직접 타이핑하는 시간은 줄었지만, 읽고 판단하는 시간은 늘었다. 아니, 더 정확하게는 — 판단의 질이 결과물의 질을 결정하는 비중이 높아졌다.
생성은 도구가 한다. 선택은 사람이 한다. 그리고 선택하는 사람이 만들어낸 결과물의 책임을 진다. 이것이 지금 현장에서 실제로 벌어지고 있는 재편이다.
버리는 것을 결정하는 손이, 지금 작성자의 손이다.
AI가 초안을 쓰고 사람이 검토해서 최종본이 나왔을 때, 누가 그것을 "쓴" 것인가. 이 질문은 법적인 문제이기 이전에 문화적인 문제다. 우리가 매일 일하는 방식 안에서 이미 일어나고 있는 일이고, 팀 안에서 어떻게 이야기하느냐가 앞으로의 관계를 만든다.
"AI가 썼다"고 말하는 것은 자신의 역할을 지운다. 검토하고, 방향을 잡고, 고르고, 다듬고, 최종 판단을 내린 모든 과정이 사라진다. 이 표현은 겸손처럼 들리지만, 실제로는 책임을 흐리는 방향으로 작동한다.
반대로 "내가 썼다"고 말하는 것은 AI의 역할을 지운다. 구조의 많은 부분이 AI에서 왔다는 사실을 지우면, 나중에 문제가 생겼을 때 원인을 찾기 어렵다. 그리고 솔직하지 않다는 인상을 남긴다.
두 표현 모두 진실의 일부만을 담는다. 더 정확한 질문은 이것이다 — "누가 어떤 판단을 했는가."
AI가 초안을 만들었다. 그리고 어떤 방향으로 갈지를 정한 건 기획자였다. AI가 코드를 생성했다. 그리고 어떤 구조가 맞는지 가려낸 건 개발자였다. AI가 시안을 뽑았다. 그리고 어떤 시안이 우리 게임의 분위기에 맞는지를 고른 건 아티스트였다.
판단을 가진 쪽이 크레딧을 가져간다. 그리고 판단이 잘못됐을 때, 그 책임도 함께 가져간다. 이것이 지금 "작성자"라는 말이 옮겨가고 있는 자리다.
이 글은 결론을 내리려고 쓴 게 아니다. 우리가 이미 겪고 있는 변화를 같은 언어로 이야기해보자는 제안에 가깝다.
"AI가 썼다" vs "내가 썼다" 이분법을 버리고, 대신 이 질문을 쓰는 것을 권한다 — "누가 어떤 판단을 했는가." 기획서 회의에서, 코드 리뷰에서, 아트 피드백에서 이 질문을 쓰면 대화가 달라진다. 결과물의 어느 부분이 어떤 판단에서 나왔는지가 보이기 시작한다.
기획 문서를 리뷰할 때. "AI가 썼어요"가 아니라, "AI 초안에서 이 부분을 살리고 이 부분을 바꿨어요"가 더 유용한 정보다. 어떤 판단이 개입했는지가 리뷰의 출발점이 된다.
코드 리뷰에서. 생성된 코드를 그대로 붙여넣은 것과, 생성된 코드를 검토하고 수정한 것은 다르다. 어느 부분이 직접 판단을 거쳤는지를 PR 설명에 짧게 남기는 것이 팀 전체에 도움이 된다.
아트 시안 리뷰에서. AI 시안 중 어떤 방향을 왜 골랐는지를 한 줄이라도 남기면, 그 판단이 다음 시안 요청의 방향이 된다. "좋아 보여서"가 아니라 "우리 게임의 이 부분과 맞아서"가 훨씬 강한 근거다.
문제가 생겼을 때. "AI가 이렇게 만들었어요"는 원인 분석에 도움이 안 된다. 어떤 판단으로 그 출력을 채택했는지를 되짚는 것이 같은 실수를 안 반복하는 방법이다. 판단이 기록에 남아야 한다.
변화의 속도 앞에서 자세를 잃지 않는다는 것에 대하여.