Cover · Issue 051
"빈 강의실, 칠판이 아니라 서로를 마주 보게 돌려놓은 의자 하나."
TSTF MAG · 2026
집에 가져가 쓰던 과제가 조용히 사라지고 있다. 그 자리에 돌아온 건 눈앞에서 직접 풀고, 말로 설명하는 방식이다. 기계가 답을 다 내놓는 지금, 무엇을 물어야 실력을 가늠할 수 있을까. 가르치는 쪽이 먼저 그 질문을 다시 쓰기 시작했다.
어느 교실에서, 집에 가져가 쓰던 과제가 하나둘 사라지기 시작했다.
대신 그 시간에 다시 등장한 건 오래된 방식이다. 학생이 눈앞에서 직접 풀고, 왜 그렇게 풀었는지 입으로 설명하는 방식. 몇 년 전만 해도 이건 "손이 많이 가서 잘 안 쓰는" 방법이었다. 그런데 지금은 오히려 그 방법만이 확실하게 남았다.
이유는 단순하다. 집에서 혼자 쓰는 글은 이제 누가 쓴 건지 가려내기가 너무 어려워졌다. 결과물만 봐서는, 그 학생이 실제로 이해하고 쓴 건지 기계에게 맡기고 받아 적은 건지 구분이 안 된다. 그래서 평가하는 쪽은 결과물 대신 과정을 보기로 했다.
결과물만으로는 더 이상 아무것도 증명할 수 없다. 증명은 이제 과정에서, 그리고 그 과정을 설명하는 말에서 나온다.
— 이번 호가 출발한 관찰이건 게임을 만드는 우리 일과도 멀지 않다. 기획서 한 장, 코드 한 줄, 아트 시안 하나 — 이제 기계가 초안을 순식간에 만들어낸다. 그러면 "잘 만들었다"는 판단은 어디서 나오는가. 결과물을 보는 것만으론 부족해졌다. 왜 그렇게 만들었는지를 설명할 수 있는가 — 그게 새 기준이 되고 있다.
"과제가 사라진다"는 말을 손실로 읽으면 이야기가 서글퍼진다. 하지만 조금 다르게 보면, 이건 평가와 과제의 형태를 능동적으로 다시 설계하는 과정이다. 무엇을, 어떻게 물을지를 다시 정하는 일. 그 방향은 대략 세 갈래로 보인다.
혼자 써 오는 글 대신, 수업 시간 안에서 직접 쓰고 그 자리에서 말로 설명하는 방식이 늘고 있다. 작업 중간 기록을 남기게 하고, 그걸 모아 쌓아가는 방식도 함께 쓰인다. 핵심은 하나다. 마지막 결과물 한 장이 아니라, 거기까지 가는 궤적을 본다는 것.
예전엔 "정답을 아는 것"이 실력이었다. 지금은 "설명하고 공유하는 법", "사실을 검증하는 법", "도구가 어떻게 움직이는지 이해하는 법"이 더 중요한 역량으로 올라온다. 비판적으로 따져 묻는 힘, 판단의 근거를 대는 힘도 함께 앞으로 나온다.
이미 과정 중심으로 방식을 옮긴 곳은 그 전환이 점점 빨라진다. 반대로 일부는 다시 종이와 제한된 방식으로 되돌아간다. "기계가 생각하는 힘을 약하게 만든다"는 걱정이 오히려 어떤 곳에는 다시 설계할 동력이 되고, 어떤 곳에는 방어적으로 문을 닫는 이유가 된다. 같은 걱정에서 출발했는데, 반응은 정반대로 갈린다.
이 흐름을 게임 개발 현장에 그대로 옮겨보면 낯설지 않다. 코드 리뷰가 딱 이 모양으로 바뀌는 중이다. 예전 코드 리뷰는 "이 코드가 돌아가는가, 버그는 없는가"를 검사하는 자리였다. 지금은 코드 자체를 기계가 순식간에 짜준다. 그러면 리뷰의 무게는 자연히 옮겨간다 — 왜 이 구조를 선택했는지, 다른 방법은 왜 버렸는지로.
| 예전 방식 | 지금 방식 | |
|---|---|---|
| 보는 대상 | 완성된 결과물 | 결과에 이르는 판단 |
| 코드 리뷰 | 버그·스타일 검사 | 선택의 이유 점검 |
| 온보딩 과제 | 산출물 제출 | 왜 그렇게 했는지 설명 |
| 실력 판단 기준 | 얼마나 잘 만들었나 | 얼마나 정확히 설명하나 |
신입 온보딩 과제도 마찬가지다. 예전엔 "이 기능을 구현해 오세요"로 충분했다. 지금은 기계가 그 기능을 몇 분 만에 만들어낼 수 있다. 그래서 과제의 형태가 바뀐다. 결과물 제출이 아니라, 왜 그 방식을 골랐는지 설명하는 자리로. 같은 질문인데, 이제 답을 다 아는 시대라 물어보는 방식이 바뀐 것뿐이다.
과정과 판단 중심으로 무게가 옮겨가면, 몇 가지가 자연히 따라온다.
이 이야기는 이미 우리 안에서도 조금씩 벌어지고 있다. 신입 과제를 낼 때 "결과물을 제출하라"고만 하면, 그 결과물이 어디서 왔는지 알 수 없다. 그래서 결과물과 함께 "이렇게 만든 이유"를 짧게 말해보라고 요청하는 자리가 늘어난다.
코드 리뷰도 비슷하게 움직인다. 같이 생각해볼 점이 몇 가지 있다.
그래서 질문은 "얼마나 잘 만들었나"에서 옮겨간다 — "그 판단을 얼마나 정확히 설명할 수 있는가." 이건 앞으로 우리 팀의 채용, 온보딩, 리뷰 자리 모두에 걸쳐 있는 질문이다.
이번 호의 결론도 당신에게 미룬다. 점심 자리에서 한 번쯤 꺼내보길 바라는 질문들이다.
결과물을 봤다면, 그 결과물이 기계가 만든 것과 어떻게 다른지 구분할 수 있었는가?
결과는 늘 낼 수 있는데, "왜 이렇게 했는지"를 물으면 선뜻 답이 나오는가?
유효하지 않다면, 우리는 이제 무엇을 새로 물어야 할까?
이번 호는 어느 교실의 작은 장면에서 출발했다. 집에 가져가던 과제가 사라지고, 그 자리에 눈앞에서 직접 풀고 설명하는 방식이 돌아왔다는 장면. 처음엔 이걸 "무언가 무너지는 이야기"로 읽고 싶은 유혹이 있었다. 하지만 들여다볼수록, 이건 무너짐이 아니라 다시 설계하는 일에 가까웠다.
기계가 결과물을 다 만들 수 있게 되면서, 평가와 검증의 무게는 결과물에서 과정과 판단으로 옮겨가고 있다. 그리고 그 전환을 먼저 능동적으로 받아들인 쪽과, 방어적으로 문을 닫은 쪽 사이에 생각보다 큰 격차가 생기고 있다.
우리가 만드는 게임도 다르지 않다. 코드 리뷰든 온보딩 과제든, 결과물 검사만으로는 이제 아무것도 가려낼 수 없는 순간이 오고 있다. 그렇다면 우리는 이제 무엇을 새로 물어야 할까. 사람의 실력을 가늠하던 그 과제는, 기계가 답을 다 아는 지금도 여전히 유효한가.
— Desk γ즉석 발화 NPC라는 새 재료와 그 경계에 관하여.