배운 것의
유통기한.

가장 빠르게 닳는 지식은 특정 도구에 묶인 지식이다. "어떤 IDE에서 이 단축키를 누르면 리팩터링이 된다"는 정보는, 그 IDE 버전이 바뀌거나 팀이 다른 도구로 이동하는 순간 즉시 만료된다. "이 모델에게 이런 식으로 말하면 좋은 코드가 나온다"는 패턴도 마찬가지다. 모델이 업그레이드되면 그 패턴은 더 이상 맞지 않거나 오히려 역효과를 낸다.

게임 개발 현장에서 더 실감 나는 예시로 보자. 특정 엔진의 씬 계층 구조를 관리하는 방법, 특정 버전의 셰이더 코드 작성법, 특정 빌드 파이프라인 도구에서 캐시를 날리는 명령어. 이것들은 쓸모 있는 지식이다 — 지금 당장 그 버전을 쓰는 동안에는. 그런데 다음 메이저 업데이트나 프로젝트 이전 시점에 상당 부분이 갱신된다.

이런 지식의 공통점은 세 가지다. 도구 이름이 지식 안에 들어가 있다. 버전 번호에 묶여 있다. 그리고 다른 맥락에 옮겨가면 작동하지 않는다. 배우는 데 시간이 들지만, 그 시간의 유효기간은 도구의 수명과 함께 끝난다.

이런 지식이 쓸모없다는 말이 아니다. 지금 당장 일하는 데 꼭 필요하다. 배워야 한다. 다만 이 지식에 깊은 시간을 쏟는 것이 좋은 투자인가 — 그건 다른 문제다. "어떻게 하면 이걸 더 잘 이해할 수 있을까"를 파고들기 전에, "이게 6개월 뒤에도 쓰이는가"를 한 번 물어볼 필요가 있다.

반면, 닳지 않는 지식이 있다. 아니 — 더 정확히는 닳는 속도가 훨씬 느린 지식이다. 이 지식에는 도구 이름이 들어가지 않는다.

버그를 추적하는 감각이 그렇다. 증상이 어디서 오는지를 역으로 좁혀가는 능력 — "이 로그가 여기 찍힌다면 문제는 이 계층 아래에 있다"는 식의 판단. 이것은 엔진이 바뀌어도, 언어가 바뀌어도, 심지어 AI가 코드를 대신 써도 유효하다. 무엇이 이상하다는 감각, 어디를 먼저 봐야 한다는 직관은 도구에 묶이지 않는다.

구조를 보는 눈도 마찬가지다. 기획 문서를 읽을 때 "이 시스템이 다른 시스템과 어떻게 연결되는가"를 그림으로 그릴 수 있는 능력. 코드를 읽을 때 "이 구조가 나중에 어떤 식으로 무너질 수 있는가"를 미리 보는 감각. 이것은 배우는 데 오래 걸리고, 익히고 나면 잘 닳지 않는다.

여기서 구체적인 장면 하나를 상상해보자. 팀에 새로운 빌드 도구가 도입됐다. 누군가는 "이 도구의 캐시 옵션이 어떻게 되지?"를 먼저 파악한다. 다른 누군가는 "이 도구가 기존 파이프라인의 어느 단계를 대체하는 건가?"를 먼저 본다. 전자는 도구 지식을 쌓는 중이고, 후자는 구조를 보는 감각을 쓰고 있다. 두 달 뒤 그 도구가 다시 바뀌었을 때 — 전자가 쌓은 것은 많이 사라지고, 후자가 쓴 것은 남는다.

사람과 일을 나누는 방식도 내구성 지식에 든다. 어떤 작업이 혼자 해결 가능하고 어떤 작업이 다른 사람의 맥락이 필요한지 구분하는 감각. 요청을 어떻게 쪼개면 상대방이 빠르게 움직일 수 있는지를 아는 것. 이것들은 팀이 바뀌어도, 프로젝트가 바뀌어도, 도구가 바뀌어도 작동한다.

중요한 것은 둘 중 하나를 포기하라는 말이 아니다. 도구 지식도 필요하다. 지금 당장 쓰는 도구를 빠르게 익히지 않으면 일이 안 된다. 다만 두 종류에 시간을 분배하는 방식을 의식하자는 것이다.