Cover · Issue 018
"작은 것들이 다 채워지면, 큰 것은 정말 비어 있을까."
TSTF MAG · 2026
변수명을 AI가 고르고, PR 제목을 AI가 뽑고, 슬랙 답장 첫 줄을 AI가 채운다. 큰 결정에 쓸 정신력이 늘었을까. 아니면 큰 결정도 조금씩 같은 방향으로 흘러가고 있을까.
하루를 되돌아보면, 생각보다 많은 선택이 있었다. 그런데 요즘은 그 선택 중 상당수를 내가 고른 기억이 없다.
변수 이름을 직접 고민한 게 언제가 마지막인지 떠올리기 어렵다. AI가 제안하면 훑어보고 탭 키를 누른다. PR 제목은 커밋 메시지를 넣으면 자동으로 나온다. JIRA 이슈 우선순위는 보드가 정렬해서 보여준다. 슬랙 알림이 쌓이면 요약이 먼저 뜬다.
이것들은 각각 아주 작은 결정이다. 하나하나는 별것 아닌 것처럼 보인다. 그런데 이것들이 하루에 수십 번 쌓이면, 어떤 일이 일어나는 걸까.
큰 결정에 쓸 에너지가 남았을까, 아니면 결정하는 습관 자체가 조금씩 흐릿해지고 있을까.
— 편집부 관찰 메모 · 2026.05이번 호는 그 질문을 들고 게임 개발 현장 안으로 들어간다. 자동화가 나쁘다는 이야기가 아니다. 자동화가 가져가는 것이 정확히 무엇인지를 한 번쯤 따져보자는 이야기다.
Note 여기서 말하는 작은 결정은 결과보다 과정이 중요한 선택들이다. 변수명 하나가 프로젝트를 바꾸지는 않는다. 하지만 변수명을 고르는 행위 — 이 개념을 어떻게 부를 것인가를 잠시 생각하는 행위 — 는 코드 전체를 이해하고 있다는 뜻이다. 그 행위가 사라질 때 함께 사라지는 것이 있을 수 있다.
결정에는 두 종류가 있다. 결과가 중요한 결정과, 과정이 중요한 결정. 회의에서 방향을 정하거나, 기능을 넣을지 뺄지 판단하는 일은 전자다. 변수명을 고르고, 함수를 어떻게 나눌지 정하고, 이 코멘트를 남길지 말지 생각하는 일은 후자에 가깝다.
지금 AI가 빠르게 채우고 있는 것은 후자다. 작고 반복적이고 결과에 크게 영향을 주지 않는 것들. 그래서 "효율적"이라는 말이 붙는다. 하지만 여기서 짚고 싶은 지점이 있다.
변수명을 고민하면서 우리는 개념을 정리한다. 이것을 player라고 부를까, character라고 부를까를 잠깐 생각하는 사이, 이 둘이 코드 안에서 어떻게 다르게 쓰이는지를 다시 한 번 훑게 된다. 그 짧은 훑음이 쌓이면 코드베이스 전체에 대한 감각이 된다.
PR 제목을 직접 쓰면서 이번 작업을 한 줄로 요약하게 된다. 한 줄 요약이 안 되면, 이번 PR이 너무 크다는 신호를 자기 안에서 먼저 받는다. AI가 대신 써주면 그 신호를 받는 기회가 줄어든다.
자동화를 제대로 쓰려면 결과를 검토할 수 있어야 한다. AI가 제안한 변수명이 맞는지 판단하려면, 그 개념이 무엇인지 알고 있어야 한다. AI가 요약한 슬랙 스레드가 정확한지 확인하려면, 원래 맥락을 파악하고 있어야 한다.
그런데 처음부터 자동화에 익숙해진 사람은, 그 판단 기준을 어디서 키우는 걸까. 자동화는 이미 능숙한 사람에게는 강력한 가속 도구다. 아직 배우는 중인 사람에게는 배움의 기회를 건너뛰게 만들 수도 있다.
"작은 것들을 AI에 맡기면 큰 것에 집중할 수 있다"는 말은 직관적으로 맞게 들린다. 그런데 실제 하루를 보면 조금 다른 일이 벌어지기도 한다. 작은 결정을 안 해도 되니 여유가 생기고, 그 여유를 또 다른 작은 일로 채우게 된다. 큰 결정을 위한 조용한 생각의 시간이 늘어나는 게 아니라, 처리하는 일의 총량이 늘어나는 방향으로 흐른다.
더 깊이 들어가면, 큰 결정도 조금씩 외주화되기 시작한다. "이 기능을 넣을까 말까"를 AI에게 물어보고, 답이 나오면 그걸 기준으로 삼는다. 최종 판단은 여전히 내가 한다. 하지만 판단의 출발점은 점점 AI가 만들어주는 것이 된다.
다른 각도로 보면 이 이야기가 새로운 것은 아니다. 원래부터 우리는 많은 결정을 위임해 왔다. 린터가 코드 스타일을 잡아주고, 빌드 시스템이 배포 순서를 정하고, 팀 컨벤션이 함수 구조를 가이드한다. 그게 없으면 오히려 비효율적이다.
그렇다면 AI에게 작은 결정을 위임하는 것도 같은 선상에 있는 걸까. 편집부가 보기엔, 비슷하지만 결정적으로 다른 지점이 하나 있다.
린터는 규칙을 보여준다. AI는 답을 대신 만들어준다. 이 차이가 생각보다 크다.
— 편집부 관찰 메모 · 2026.05린터가 "이 줄은 너무 길다"고 알려주면, 어떻게 줄일지는 내가 판단한다. AI가 "이렇게 바꿔줄게"라고 하면, 나는 받아들이거나 거부하는 역할만 한다. 전자는 판단을 요구하고, 후자는 검토를 요구한다.
판단과 검토는 다른 근육을 쓴다. 검토만 계속 하다 보면, 판단 근육이 조금씩 덜 쓰이게 된다. 그리고 이게 눈에 잘 안 띈다는 게 문제다. 매일 결정을 내리고 있다는 느낌은 그대로인데, 실제로 판단한 일의 비중이 바뀌어 있다.
이 흐름을 그대로 두면 몇 가지가 따라온다.
게임 개발은 판단이 특히 많이 개입하는 일이다. 수치 밸런싱 하나에도 "이게 재미있는가"라는 감각이 필요하고, UI 배치 하나에도 "유저가 어디서 막히는가"라는 상상이 필요하다. 이 감각과 상상은 직접 만지고 고민하면서 길러진다.
그래서 이 질문이 TSTF에 좀 더 구체적으로 닿는다. 지금 우리 팀 안에서 자동화가 채우고 있는 작은 결정들 중, 어떤 것이 "아껴도 되는 에너지"이고, 어떤 것이 "직접 써야 하는 에너지"인가.
경계가 항상 선명하지는 않다. 그래서 각자가 의식적으로 생각해볼 필요가 있다. 오늘 내가 AI에 넘긴 결정 중에, 내가 직접 고민해야 했던 것이 섞여 있지는 않은지. 그 점검을 주기적으로 하는 것이, 결정 근육을 유지하는 가장 현실적인 방법일 것 같다.
결론을 내리는 대신, 질문 세 개를 남긴다. 점심 자리에서든, 코드 리뷰 직후든, 잠깐 꺼내보기 좋은 것들이다.
그 비율이 한 달 전과 비교해 바뀌었다면, 어느 쪽으로 바뀌었는가? 그 변화가 나에게 좋은 방향인가?
1년 전보다 많아졌는가, 줄었는가? 줄었다면 이유가 자동화와 관련이 있는가, 아니면 다른 이유가 있는가?
그 어려움이 "경험 부족"인가, 아니면 "처음부터 직접 결정하는 법을 배울 기회가 없었던 것"인가?
이번 호를 쓰면서 편집부도 같은 질문을 피할 수 없었다. 매거진 본문의 문장 구조를 고르고, 어떤 단어로 개념을 부를지 정하는 일 — 그것을 AI에 맡기는 것과 직접 하는 것 사이에서, 어느 쪽이 더 좋은 결과를 내는지는 모르겠다. 다만 직접 고민할 때 글의 방향이 더 선명해진다는 것은 느낀다.
자동화를 쓰지 말자는 이야기가 아니다. 다만 자동화를 쓰는 동안에도, "내가 지금 어느 결정을 넘기고 있는가"를 의식하는 것이 생각보다 중요할 수 있다는 이야기다. 의식 없이 넘기다 보면, 어느 순간 넘기고 싶지 않은 것까지 함께 나가있을 수 있으니까.
결정 근육은 헬스장에서처럼 키워지지 않는다. 매일의 작은 고민 속에서, 조용히, 자기도 모르게 길러진다. 그리고 그것이 필요한 순간은 언제나 예고 없이 찾아온다.
— Desk γ조직 안에서 큰 결정이 왜 점점 더 오래 걸리는가에 관하여.