회고록, 디버깅 노트, 코드 옆 짧은 메모, 읽고 난 뒤의 한 줄. 누가 시키지 않은 자기 기록들이 있었다. AI가 정리도 요약도 대신 해주면서, 그 자리가 조금씩 작아졌다. 자기 안에서 자기에게 말 거는 시간은 무엇을 길러 왔는가.
스프린트가 끝난 금요일 오후, 어떤 사람은 짧은 회고를 적는다. 누구에게 보내는 것도 아니고, 어딘가에 제출하는 것도 아닌 — 그냥 자기한테 쓰는 글.
"이번 주는 AI 도구 쓰면서 리팩터링이 빠르긴 했는데, 왜 그렇게 됐는지 설명을 못 하겠다." "기획서 요약은 AI가 해줬는데, 요약된 걸 읽고 나서도 이 기획이 왜 좋은지 모르겠다." 이런 문장들. 도구에 대한 평가인지, 자기 상태에 대한 관찰인지 애매한 — 그런 문장들.
그런데 요즘 그런 메모가 줄었다는 이야기를 종종 듣는다. AI가 요약해 주니까 따로 정리할 필요가 없고, 회의 직후 메모장을 열던 손이 덜 움직인다. 효율적인 게 맞는데, 뭔가 조금 이상하다는 감각도 함께 남는다. 이번 호는 그 이상함이 어디서 오는지를 들여다본다.
"정리를 AI가 대신 해주고 나서, 나는 그 내용을 내 것으로 느끼지 못했다."
— 편집부에 도착한 짧은 메모 · 2026.05이 문장 하나가 이번 호의 출발점이다. 정리가 잘 됐다. 빠르게 됐다. 보기 좋게 됐다. 그런데 그것이 내 것인가 — 하는 질문이 남은 것이다.
디버깅 노트를 예로 들어보자. 버그를 잡고 나서, 어떤 사람들은 그 과정을 짧게 적는다. 무엇이 문제였고, 어디서 틀렸고, 왜 처음에 그 방향으로 생각했는지. 결과 자체는 이미 커밋 히스토리에 있다. 그런데 왜 또 적는가.
그 메모는 누군가에게 설명하기 위한 것이 아니다. 자기가 자기 생각의 경로를 한 번 더 걸어보는 행위다. 적으면서 "아, 내가 이 부분을 그냥 가정하고 넘어갔구나"를 발견하는 일이 자주 일어난다. 결과물은 이미 있는데 — 그 과정을 다시 한 번 언어로 통과시키는 일. 그게 혼잣말의 작동 방식이었다.
회의가 끝나고 메모장에 몇 줄을 적는 것, 코드 옆에 # 왜 이렇게 했더라 한 줄을 남기는 것 — 이건 기록이라기보다 소화에 가깝다. 뭔가를 처리했을 때 속이 좀 편해지는 느낌, 그 느낌의 실체가 여기 있었다. 언어로 한 번 빚어야 비로소 내 것이 되는 구조.
AI가 요약을 대신 해주면, 그 소화 단계가 건너뛰어진다. 결과물은 생겼지만, 내가 그걸 처리한 게 아니다. 배달음식이 도착한 것과, 내가 요리한 것의 차이랄까 — 결과는 비슷하고 효율은 전자가 낫지만, 내 안에 남는 것이 다르다.
PR을 올리기 전에 자기 코드를 한 번 리뷰하면서 짧게 코멘트를 다는 사람들이 있다. "이 부분은 리뷰어가 헷갈릴 수 있어서 미리 설명해 두면 좋겠다", "이 함수 이름이 마음에 안 드는데 일단 올린다" — 이런 류의 메모들.
이 행위는 타인을 위한 것처럼 보이지만, 실제로는 자기를 위한 것이기도 하다. 코드를 작성자의 눈이 아닌 독자의 눈으로 한 번 더 보게 만드는 구조. AI가 코드 설명을 자동으로 달아주기 시작하면, 이 셀프 리뷰의 층이 얇아진다. 설명은 생겼는데, 자기 점검은 사라진 상태가 된다.
회의가 끝나고 잠깐, 5분이라도 혼자 정리하는 시간이 있는 사람과 없는 사람은 조금 다른 상태로 다음 일을 시작한다. 그 5분 동안 적히는 것들은 사실 정보가 아니다. "이 방향이 맞는 것 같기도 하고 아닌 것 같기도 하다", "누군가의 말이 계속 마음에 걸린다" — 이런 건 요약본에는 나오지 않는다.
AI가 회의를 요약해 준 문서는 결정 사항과 액션 아이템을 잘 담는다. 하지만 내가 그 회의에서 어떤 상태였는지는 담지 않는다. 그리고 그 부분이 사실 다음 스프린트의 에너지와 연결되어 있을 때가 있다.
무언가를 읽고 나서 한 줄을 남기는 사람이 있다. 나중에 다시 보려고 적는 게 아니다. 그 한 줄을 적는 순간, "나는 이것을 이렇게 받아들였다"가 확정된다. AI가 요약을 해주면 내가 받아들인 방식 대신, AI가 처리한 방식이 먼저 들어온다. 그러면 그 뒤에 내 한 줄을 적어도, 그 한 줄은 조금 다른 출발점에서 나온다.
여기서 한 가지를 분명히 해두고 싶다. 이 글은 AI 도구가 나쁘다고 말하는 게 아니다. 요약이 편리하고, 정리가 빠른 건 실제로 좋은 일이다. 다만 그 편리함이 특정한 종류의 활동을 조용히 대체할 때 — 우리가 그걸 인식하고 있는지를 묻는 것이다.
| AI 요약 · 자동 정리 | 자기 혼잣말 · 손 메모 | |
|---|---|---|
| 주된 기능 | 정보를 빠르게 저장·전달 | 경험을 언어로 소화 |
| 결과물 | 잘 정리된 문서 | 내 관점이 생긴 상태 |
| 속도 | 빠르다 | 느리다 — 그게 역할이다 |
| 무엇이 남는가 | 기록 | 각인 + 자기 인식 |
| 대체 가능성 | 혼잣말을 부분적으로 대체한다 | AI 요약을 대체하지는 않는다 |
이 표에서 보이는 것은 — 둘이 같은 일을 하는 게 아니라는 점이다. AI 요약은 혼잣말이 하던 일의 일부만 가져간다. 가장 빠르게 가져가는 부분은 "기록"이고, 가장 조용히 건너뛰어지는 부분은 "소화"다. 소화가 건너뛰어졌다는 사실은, 결과물이 잘 정리되어 있을수록 눈에 잘 안 띈다.
Note 소화라는 단어를 쓴 건, 단순히 이해했다는 것과 구별하기 위해서다. 이해는 정보가 내 안에 들어온 상태고, 소화는 그 정보가 내 기존 생각과 부딪히고 섞이고 조정된 상태다. 혼잣말은 그 부딪힘이 일어나는 시간이었다.
이 관찰이 맞다고 가정하면, 몇 가지 작은 신호들이 설명된다.
게임 개발 현장은 자기 기록을 꽤 많이 쓰는 곳이다. 밸런싱 조정을 반복하는 사람은 왜 이 수치를 바꿨는지를 어딘가에 남겨두고, 아트 작업자는 레퍼런스를 고를 때 "왜 이게 아니고 저게인지"를 자기한테 설명한다. 그 설명이 외부에 보이지 않는 혼잣말일 때도 많다.
그리고 그 혼잣말들이 모여서, 팀 안에서 누군가가 "그거 왜 그렇게 됐어?"라고 물었을 때 대답이 나오는 구조가 만들어진다. 기록 문서에 없어도, 그 사람이 그 결정을 통과하면서 적은 혼잣말이 있기 때문에 대답이 가능한 것이다.
AI 도구가 빠르게 들어오면서, 그 층이 변하고 있다. 나쁜 변화라고 단정하기는 어렵다. 다만 인식하고 있어야 하는 변화다. 몇 가지를 생각해볼 수 있다.
혼잣말을 늘리자는 말이 아니다. 줄어든 자리가 어디인지를 알고 있자는 것이다. 알고서 줄인 것과, 모르게 줄어든 것은 나중에 꽤 다른 결과를 만든다.
이번 호의 결론은 열어둔다. 답보다 질문이 더 유용한 주제라고 생각했다. 점심 자리나 회고 끝자락에서 한 번쯤 꺼내볼 수 있는 것들이다.
누군가에게 보내지 않는, 제출하지 않는, 시스템에 올리지 않는 — 그냥 자기한테 쓰는 메모. 그게 있다면 최근에 그 빈도가 어떻게 됐는가?
있다면 그 감각이 어디서 온 것인지 — 결과물의 품질 문제인지, 아니면 소화 단계가 건너뛰어진 느낌인지. 둘을 구별할 수 있는가?
문서에 있는가, 아니면 그 결정을 한 사람의 기억 안에 있는가. 그 사람이 떠나면 이유도 함께 사라지는 것들이 얼마나 되는가. 그리고 그게 문제인가, 아닌가.
이 글을 쓰면서 편집부도 같은 질문에 걸렸다. 초안을 AI에게 구조 정리를 시키고 나서, 그 구조 위에 다시 쓰는 과정에서 — 어느 순간 "내가 처음에 하고 싶었던 말이 뭐였지"를 되물어야 하는 일이 생겼다.
결국 초안을 한 번 지우고 처음부터 다시 썼다. 비효율적이었다. 그런데 그 과정에서 글이 무엇을 말하고 싶은지가 선명해졌다. 이게 이 호에서 말하려는 것의 작은 예가 됐다.
혼잣말을 늘리라고 말하는 게 아니다. 그 자리가 줄어들었다는 걸 인식하고, 줄어든 자리가 어떤 기능을 하던 곳인지를 알고 있자는 것이다. 그것을 알면, 어디서 속도를 낼지와 어디서 천천히 걸을지를 스스로 고를 수 있다. 모르면 그 선택이 자기도 모르게 AI에게 위임된다.
자기 안에서 자기에게 말 거는 시간 — 그게 무엇을 길러왔는지는, 줄어들고 나서야 조금씩 보이기 시작한다.
— Desk γ공예적 감각과 디지털 제작 사이, 손이 기억하는 것에 대하여.