isRecord는 확실히 우리 잘못인 것 같습니다

몇 주 전, 많은 프로그래머들(혹은 전직 프로그래머들)은 OpenAI 의 Codex 모델이 방어적 코딩에 집착하기 시작했다는 것을 알아차렸습니다.

이를 가장 잘 보여주는 것은 isRecord 였습니다. 객체처럼 보이는 것이 실제로 객체인지 확인하는 터무니없는 가드(guard)였는데, 이게 모든 곳에서 나타나기 시작했습니다.

https://x.com/weswinder/status/2073959658167898594

https://x.com/cnakazawa/status/2062755985702494643

https://x.com/thdxr/status/2069927201638682976

이 특이한 현상은 곧 밈이 되었습니다. 심지어 npm 패키지 로도 제공됩니다.

저 코드, 본 적 있어요

저는 항상 불리언을 반환하는 헬퍼 함수에 isWhatever 를 사용해 왔습니다. 스타일 일관성과 '파운더 모드'라는 작은 이유 때문에 가끔은 불쌍한 동료들에게도 이를 사용하도록 강요해야 했죠.

그래서 이 모든 isRecord 논의가 제 타임라인에 도달했을 때, 잠시 멈출 수밖에 없었습니다. 저는 분명히 isRecord 를 전에 본 적이 있다고 확신했습니다.

그리고 예상대로, tldraw 의 코드베이스를 검색해보니 나타났습니다.

이 가드는 tldraw 캔버스의 모든 정보를 객체(또는 '레코드')의 플랫 리액티브 맵으로 저장하는 데이터 스토어 패키지의 일부입니다. 이는 단순한 가드로, 실제로 스토어를 보호하기보다는 타입을 할당하는 데 더 가깝습니다. 제가 알기로, 이 코드 라인들이 코딩 모델들이 그토록 사랑하는 isRecord 의 원천입니다.

GitHub 에서 이 코드를 검색하면 tldraw 와 tldraw 의 많은 복사본, 그리고 Codex 가 작성한 최신 코드를 찾을 수 있습니다.

제가 찾은 '이전 시대'에 isRecord 를 사용한 다른 유일한 저장소는 RocketChat 의 버전으로, 2025 년 7 월에 추가되었습니다.

자랑하려는 건 아니지만, 저희 isRecord 는 그보다 적어도 2 년은 앞섭니다. 사실, 저는 2022 년 여름에 스토어를 작성했다고 생각합니다. 하지만 git blame 은 2023 년까지만 거슬러 올라가는데, 그때 비공개 저장소에서 공개 저장소로 코드를 옮겼기 때문입니다.

isRecord 의 10,000 년

결국, 저는 이렇게 놀라운 모델들의 가중치에 아주 작은 영향을 미친 것에 대해 약간의 자부심을 느낀다는 점을 인정해야겠습니다. 다음에 코드베이스에서 isRecord 를 보게 된다면, tldraw 를 생각해 주세요.