이걸 처음 봤을 때부터 정말 마음에 들었음. 예시 커밋(여기)을 살펴본 뒤 더더욱 마음에 들게 됨. 문제를 해결하기 위한 코드와 함께 ‘저주받은 지식’이 기록되는 점이 특히 좋음. 이런 기능은 모든 프로젝트에 필요하다는 생각이 가장 먼저 듦. 로그가 그저 카타르시스가 아니라, 각종 골치 아픈 문제를 긍정적인 학습 경험으로 전환해줌. 외부에 공개하면, 같은 문제를 겪은 사람들과 공감도 할 수 있고, 앞으로 발생을 예방하는 툴이 될 수도 있음
보통 이런 정보들을 커밋 메시지에 직접 적는 편임. 누군가 코드 한 줄을 보고 "왜 이렇게 대충 짰지? 그냥 ___ 하면 되는 거 아냐?"라고 생각할 때 바로 설명이 있어서 유용함
‘PostgreSQL 플레이스홀더 6만5천 개를 한 쿼리에서 바인딩할 수 없다’는 부분을 보고 놀랐음. 애초에 이건 별로 좋은 생각이 아니어서 오히려 PostgreSQL 쪽을 탓하긴 어려움. 깃허브 이슈 코멘트들을 보니, ORM을 리팩터링해서 큰 쿼리를 여러 개의 작은 쿼리로 나누는 식의 합리적인 접근을 했더라고 함. 개인적으로는 한 쿼리에서 3,000~5,000 행 정도씩 쓰는 게 적당한 느낌임. 누군가는 TEMP 테이블에 데이터를 먼저 올리고, 나중에 조인하는 방식[특히 COPY … FROM]이 성능상 더 좋다고 조언했는데, 그건 코드 변화가 너무 크고, 결국 그 전략은 포기함. 전반적으로 좋은 경험담이 모인 유익한 모음집이라 생각함. 경고성 사례로 유용함
‘이런 시도 자체가 저주받은 아이디어’라는데 공감함. 목록을 다 읽어보면, ‘저주 목록’이라는 게 일종의 막힌 점이나 설계 함정이라기보다 실제 개발자가 부딪혀서 체득한 교훈 같은 느낌을 받았음. 물론 정보마다 완성도가 다르고 아직 진행 중인 것들도 있으나, 엔지니어링 로그 내 개인적인 경험담으로 이해하면 더 가치가 있음
파일 시스템의 모든 파일 이름을 NUL 문자 없이 xargs 같은 툴로 한 번에 처리하려는 경우랑 비슷한 느낌임. 특이하거나 깨진 파일명이 있거나, 메모리가 넉넉하지 않다면 곤란함. find -print0와 parallel -0/xargs -0 등의 도구를 사용하는 게 좋음. 그리고 sed, grep 등도 LC_ALL=C 없이 쓰면 다중바이트 문자 시퀀스 오류가 발생하니 조심해야 함
실제로 ORM으로 레코드를 대량 upsert 하다가 6만5천 개 바인딩 오류를 직접 겪어 봤음. 특히 테이블에 SQL 배열 타입 컬럼이 있을 때, 삽입하는 항목마다 바인딩해야 하니까 바인딩 변수 수가 기복을 띄게 됨. 그래서 두 번 실행해도 행/열 수는 같아 보여도 바인딩 필요 변수 수는 달라지는 불안정한 상황이 됨
또 다른 전략으로, 값들을 배열 인자(text[]나 int[] 등)로 전달하는 방법도 있음. PostgreSQL도 이건 잘 처리함. ANY() 연산이 IN()보다 약간 느리긴 하지만, 한 파라미터 안에 여러 ID를 담을 수 있음. 아마 ORM이 그걸 지원하지 않았을 수도 있음
나도 그 부분이 눈에 띄었음. 그렇게 많은 파라미터를 바인딩하는 건 확실히 저주받은 방식임. 대량 처리라면 대부분 COPY를 써야 함. 진짜 저주받은 Postgres 사례 하나 더 추가하자면, prepared statement 이름이 NAMEDATALEN-1 만큼만 조용히 잘림(NAMEDATALEN은 64). 이건 2001년부터 그랬고, 사실 그 전에도 있었음. ORM들이 이런 부분을 반드시 인지해야 함. 사람이 60자 넘는 prepare name을 쓰는 경우는 드물지만, ORM은 예외임
‘패키지 50개 추가 설치’ 항목은 정말 충격적임. 그 패키지 저자는 다운로드 수만 엄청 올렸을 것임. 전 세계적으로 낭비되는 대역폭과 디스크 공간을 생각하면 정말 아까움. 혹시라도 명성을 쌓으려고 그런 게 아닐까 궁금함
이 ‘저주받은 지식’에서 지목된 패키지 메인테이너는 TC39 멤버임. 여러 유명 JavaScript 프로젝트에서 종종 논란이 됐던 인물임. 특정 polyfill 이슈와 관련해서 금전적 동기가 있다는 주장도 있었지만, GitHub Sponsor나 Tidelift의 수익이 크지 않기 때문에, 본인이 정말 호환성을 신념으로 삼고 있지 않나 생각함. 2025년 기준으론 그에 대해 생각이 조금 달라졌음. 중요한 유지보수를 꾸준히 하고 있고, 커뮤니티 내에서 계속해서 틀리는 견해를 내는 역할도 어쩌면 필요하다고 봄
명성 또는 특이한 성향 때문일 수도 있지만, 엄청난 규모의 소프트웨어 공급망 공격을 위한 사전포석이라는 극단적 해석도 있음
그 저자 거의 확실히 ljharb임
Windows의 NTFS Alternate Data Streams(ADS)는 기존 파일에 무제한의 파일을 숨길 수 있는 기능임
macOS는 data fork, xattr, Spotlight(md) 인덱싱까지 기본으로 모든 이동식 볼륨에 수많은 숨김 및 임시 파일을 생성함. 해결법: mdutil -X /Volumes/path/to/vol
그리고, opt-out 텔레메트리가 너무 많음(go, yarn, meilisearch, homebrew, vcpkg, dotnet, Windows, VS Code, Claude Code, macOS, Docker, Splunk, OpenShift, Firefox, Chrome, flutter 등 온갖 곳에서 사생활 침해 우려가 있음)
opt-out 텔레메트리: go의 경우 기본적으로 텔레메트리 데이터가 로컬에만 저장됨. 사용자가 원할 때만 일부 승인된 데이터를 telemetry.go.dev로 업로드할 수 있음. 업로드 활성화는 “go telemetry on”, 전체 비활성화는 “go telemetry off”로 조절 가능함(문서 참고)
opt-out 텔레메트리만이 진짜 유용한 텔레메트리임
‘npm 스크립트가 실행될 때마다 npm 레지스트리에 HTTP 요청을 보낸다’는 제보에 대해, 사실인지 궁금함. 만약 그렇다면 패키지 매니저로서는 말도 안 되는 동작임
아마 npm 업데이트가 있는지 확인하는 과정일 수 있음. 구버전 사용 시 업데이트 안내가 뜨기도 함
아마도 업데이트 확인 때문일 것임. 때때로 업데이트 배너가 표시되곤 함
하나 빼먹은 게 있어 보임. EXIF 메타데이터의 날짜/시간 처리와 관련된 라운드는 꽤 오래된 논쟁임 참고 이슈1, 참고 이슈2, 참고 이슈3
날짜/시간 자체도 저주받기 쉬움. 잘 돌아가더라도 관련 기능에서 언제든 문제가 터질 가능성이 있음. 특히 값이 시간대나 서머타임을 포함하고 있다면 더욱 취약함
Hadoop과 Kerberos 관련 ‘Madness beyond the gates’(링크) 문서가 연상됨. 이 글이 덕분에 미쳐버릴 위기에서 여러 번 구원받은 적 있음. 저자인 Steve에게 감사함을 표하고 싶음. 저주받은 지식을 얻어내기까지 얼마나 고생했을지 상상도 안 됨
이런 저주받은 지식을 한곳에 정리한 개념이 너무 좋음. 실제로 프로젝트에 깊이 들어가야만 겪을 수 있는 시행착오라는 것도 공감됨. 앞으로 프로젝트마다 이런 목록을 만들어둘 생각임
Hacker News 의견
이걸 처음 봤을 때부터 정말 마음에 들었음. 예시 커밋(여기)을 살펴본 뒤 더더욱 마음에 들게 됨. 문제를 해결하기 위한 코드와 함께 ‘저주받은 지식’이 기록되는 점이 특히 좋음. 이런 기능은 모든 프로젝트에 필요하다는 생각이 가장 먼저 듦. 로그가 그저 카타르시스가 아니라, 각종 골치 아픈 문제를 긍정적인 학습 경험으로 전환해줌. 외부에 공개하면, 같은 문제를 겪은 사람들과 공감도 할 수 있고, 앞으로 발생을 예방하는 툴이 될 수도 있음
‘PostgreSQL 플레이스홀더 6만5천 개를 한 쿼리에서 바인딩할 수 없다’는 부분을 보고 놀랐음. 애초에 이건 별로 좋은 생각이 아니어서 오히려 PostgreSQL 쪽을 탓하긴 어려움. 깃허브 이슈 코멘트들을 보니, ORM을 리팩터링해서 큰 쿼리를 여러 개의 작은 쿼리로 나누는 식의 합리적인 접근을 했더라고 함. 개인적으로는 한 쿼리에서 3,000~5,000 행 정도씩 쓰는 게 적당한 느낌임. 누군가는 TEMP 테이블에 데이터를 먼저 올리고, 나중에 조인하는 방식[특히 COPY … FROM]이 성능상 더 좋다고 조언했는데, 그건 코드 변화가 너무 크고, 결국 그 전략은 포기함. 전반적으로 좋은 경험담이 모인 유익한 모음집이라 생각함. 경고성 사례로 유용함
‘이런 시도 자체가 저주받은 아이디어’라는데 공감함. 목록을 다 읽어보면, ‘저주 목록’이라는 게 일종의 막힌 점이나 설계 함정이라기보다 실제 개발자가 부딪혀서 체득한 교훈 같은 느낌을 받았음. 물론 정보마다 완성도가 다르고 아직 진행 중인 것들도 있으나, 엔지니어링 로그 내 개인적인 경험담으로 이해하면 더 가치가 있음
파일 시스템의 모든 파일 이름을 NUL 문자 없이 xargs 같은 툴로 한 번에 처리하려는 경우랑 비슷한 느낌임. 특이하거나 깨진 파일명이 있거나, 메모리가 넉넉하지 않다면 곤란함. find -print0와 parallel -0/xargs -0 등의 도구를 사용하는 게 좋음. 그리고 sed, grep 등도 LC_ALL=C 없이 쓰면 다중바이트 문자 시퀀스 오류가 발생하니 조심해야 함
실제로 ORM으로 레코드를 대량 upsert 하다가 6만5천 개 바인딩 오류를 직접 겪어 봤음. 특히 테이블에 SQL 배열 타입 컬럼이 있을 때, 삽입하는 항목마다 바인딩해야 하니까 바인딩 변수 수가 기복을 띄게 됨. 그래서 두 번 실행해도 행/열 수는 같아 보여도 바인딩 필요 변수 수는 달라지는 불안정한 상황이 됨
또 다른 전략으로, 값들을 배열 인자(text[]나 int[] 등)로 전달하는 방법도 있음. PostgreSQL도 이건 잘 처리함. ANY() 연산이 IN()보다 약간 느리긴 하지만, 한 파라미터 안에 여러 ID를 담을 수 있음. 아마 ORM이 그걸 지원하지 않았을 수도 있음
나도 그 부분이 눈에 띄었음. 그렇게 많은 파라미터를 바인딩하는 건 확실히 저주받은 방식임. 대량 처리라면 대부분 COPY를 써야 함. 진짜 저주받은 Postgres 사례 하나 더 추가하자면, prepared statement 이름이 NAMEDATALEN-1 만큼만 조용히 잘림(NAMEDATALEN은 64). 이건 2001년부터 그랬고, 사실 그 전에도 있었음. ORM들이 이런 부분을 반드시 인지해야 함. 사람이 60자 넘는 prepare name을 쓰는 경우는 드물지만, ORM은 예외임
‘패키지 50개 추가 설치’ 항목은 정말 충격적임. 그 패키지 저자는 다운로드 수만 엄청 올렸을 것임. 전 세계적으로 낭비되는 대역폭과 디스크 공간을 생각하면 정말 아까움. 혹시라도 명성을 쌓으려고 그런 게 아닐까 궁금함
이 ‘저주받은 지식’에서 지목된 패키지 메인테이너는 TC39 멤버임. 여러 유명 JavaScript 프로젝트에서 종종 논란이 됐던 인물임. 특정 polyfill 이슈와 관련해서 금전적 동기가 있다는 주장도 있었지만, GitHub Sponsor나 Tidelift의 수익이 크지 않기 때문에, 본인이 정말 호환성을 신념으로 삼고 있지 않나 생각함. 2025년 기준으론 그에 대해 생각이 조금 달라졌음. 중요한 유지보수를 꾸준히 하고 있고, 커뮤니티 내에서 계속해서 틀리는 견해를 내는 역할도 어쩌면 필요하다고 봄
명성 또는 특이한 성향 때문일 수도 있지만, 엄청난 규모의 소프트웨어 공급망 공격을 위한 사전포석이라는 극단적 해석도 있음
그 저자 거의 확실히 ljharb임
Windows의 NTFS Alternate Data Streams(ADS)는 기존 파일에 무제한의 파일을 숨길 수 있는 기능임
macOS는 data fork, xattr, Spotlight(md) 인덱싱까지 기본으로 모든 이동식 볼륨에 수많은 숨김 및 임시 파일을 생성함. 해결법: mdutil -X /Volumes/path/to/vol
그리고, opt-out 텔레메트리가 너무 많음(go, yarn, meilisearch, homebrew, vcpkg, dotnet, Windows, VS Code, Claude Code, macOS, Docker, Splunk, OpenShift, Firefox, Chrome, flutter 등 온갖 곳에서 사생활 침해 우려가 있음)
opt-out 텔레메트리: go의 경우 기본적으로 텔레메트리 데이터가 로컬에만 저장됨. 사용자가 원할 때만 일부 승인된 데이터를 telemetry.go.dev로 업로드할 수 있음. 업로드 활성화는 “go telemetry on”, 전체 비활성화는 “go telemetry off”로 조절 가능함(문서 참고)
opt-out 텔레메트리만이 진짜 유용한 텔레메트리임
‘npm 스크립트가 실행될 때마다 npm 레지스트리에 HTTP 요청을 보낸다’는 제보에 대해, 사실인지 궁금함. 만약 그렇다면 패키지 매니저로서는 말도 안 되는 동작임
아마 npm 업데이트가 있는지 확인하는 과정일 수 있음. 구버전 사용 시 업데이트 안내가 뜨기도 함
아마도 업데이트 확인 때문일 것임. 때때로 업데이트 배너가 표시되곤 함
하나 빼먹은 게 있어 보임. EXIF 메타데이터의 날짜/시간 처리와 관련된 라운드는 꽤 오래된 논쟁임
참고 이슈1, 참고 이슈2, 참고 이슈3
Hadoop과 Kerberos 관련 ‘Madness beyond the gates’(링크) 문서가 연상됨. 이 글이 덕분에 미쳐버릴 위기에서 여러 번 구원받은 적 있음. 저자인 Steve에게 감사함을 표하고 싶음. 저주받은 지식을 얻어내기까지 얼마나 고생했을지 상상도 안 됨
이런 저주받은 지식을 한곳에 정리한 개념이 너무 좋음. 실제로 프로젝트에 깊이 들어가야만 겪을 수 있는 시행착오라는 것도 공감됨. 앞으로 프로젝트마다 이런 목록을 만들어둘 생각임
이 항목은 저주가 아니라, 모바일 OS에서의 권한 관리와 관련한 보안/프라이버시 이슈임
멋진 아이디어임! 다른 분들도 각자의 저주받은 지식을 공유하고픈 생각이 있나 궁금함
내 경험상 MacOS 파일명도 저주임:
1995년 Windows 95 베타 때 CDDB를 처음 만들었음. CD 음반의 트랙 이름들을 모아 .ini 파일로 배포했는데, 64KB라는 .ini 파일 크기 제한 때문에 프로젝트가 중단된 적 있음
맞음. 시스템이나 데이터 볼륨에 case-sensitive APFS나 HFS+ 볼륨을 만들면 무조건 문제가 생김
‘1번’ 항목은 기본 설정일 뿐임. HFS, APFS 둘 다 대소문자 구분 옵션이 있음. NTFS도 비슷하게 동작함. 이들 파일 시스템은 case-retentive이기 때문에 아래와 같이 쓸 수 있음
진짜 문제는 Steam이 case-sensitive 파일 시스템에서는 인스톨 자체를 거부한다는 점임(Linux 버전도 있음에도 불구하고)