left-pad을 Jev AI 호출로 다시 구현한 농담 npm 패키지, HN에서 '제2의 npm 대참사' 시나리오로 소비됨
- jev-leftpad는 문자열 왼쪽에 공백을 채우는 작업을 TypeSafe AI의 Jev 모델 호출로 처리하는 npm 패키지임. padStart() 한 줄이면 되는 일에 호출당 TypeSafe API 요청 1회를 쓰고 재시도는 비활성임.
- Jev는 space_0부터 space_10까지 11개 선택지 중 하나를 고르고, JavaScript가 그 숫자만큼 공백을 만든 뒤 값을 뒤에 붙임. 10칸을 넘는 패딩이 필요하면 Jev에게 정답 선택지가 없음.
- 테스트는 Jev를 모킹해서 API 키와 TypeSafe 크레딧 없이 돌아가고, README는 프로덕션은 물론 중요한 코드에도 쓰지 말라고 명시함.
- 저장소는 사용자 f의 커밋 1개에 별 3개, MIT 라이선스임. HN에서는 left-pad가 남의 npm 설치를 광범위하게 깨뜨린 사건을 떠올리며, 이 패키지가 의존성 체인에 들어간 뒤 벤더링되면 실행마다 패딩이 조용히 달라질 수 있다는 쪽을 더 무서운 시나리오로 꼽음.
- 댓글에서는 confidence score를 U+2009 THIN SPACE 같은 유니코드로 매핑해 부분 신뢰도를 소수 공백으로 만들라는 제안이 나옴. 지금 구현은 Jev의 confidence를 쓰지 않는다는 지적임.
Hacker News opinions
진짜 사람이 만든 이해 불가능한 공포다. '입은 없지만 패딩은 해야 한다'는 댓글에서 터졌음.
깃허브 유저네임이 한 글자라는 게 제일 놀랍다. 근데 또 하나의 AI에 사람들 의존시키는 프로젝트가 하나 늘었네.
ELI5 해줄 사람 있냐.
한 줄이면 되는 코드를 Jev로 돌리는 거임. leftpad는 예전에 다들 직접 안 짜고 갖다 썼던 패키지인데 그게 터져서 남의 npm 설치를 광범위하게 깨뜨린 적이 있고, Jev는 주어진 선택지 중에 하나 고르는 것만 하는 작고 빠른 모델임. 바보를 바보에 넣은 이중 농담인 셈.
README에 프로덕션에 쓰지 말고 중요한 데도 쓰지 말라고 써 있는데, 5~10년 뒤에 이게 npm 의존성 체인 깊숙이 들어가서 중요한 서비스 장애 터뜨리면 다들 울상일 듯.
그것보다 무서운 건 누가 이걸 벤더링해놓으면 실행할 때마다 패딩이 조용히 달라진다는 거임.
그래서 벤더링하라고. 테스트 코드 보면 Jev가 틀린 개수를 고를 때도 그냥 믿는다고 되어 있음. space_2를 답하게 해놓고 ' jev'가 나오길 기대함.
10칸 넘으면 어떻게 되냐는 질문에, 타깃 길이가 범위 밖인지 Jev로 검사하는 PR을 올리겠다는 답이 나옴. 11번째 space를 추가하는 PR인 줄 알았다는 반응도 있었고.
솔직히 이건 Jev의 핵심 기능인 confidence score를 안 쓰고 있음. 부분 신뢰도를 U+2009 THIN SPACE 같은 유니코드로 매핑해서 소수 공백으로 만들면 되는데, 지금은 Jev 성능을 다 못 씀.
이거 Web Scale이냐.
결국 vim 종료할지 말지도 Jev한테 물어보는 날이 오겠네. 슬슬 선 넘는 거 아님?
Jev로 assertion 하는 테스트 러너도 만들면 재밌겠다. 설계부터 flaky한 테스트라니 악마적임.
프로덕션급 코드라고 하려면 SBOM에 SonarQube 품질 게이트까지 통과해야 함.
테스트가 Jev를 모킹한다는 부분, 10점 만점에 지적할 게 없음.
한 글자 유저네임은 어떻게 딴 거임? 2011년부터 굴러다닌 계정이라는데, 옛날 시스템에 id가 null이거나 빈 문자열인 유저들 있던 거 생각나네.
오늘 HN이 Jev 글로 도배됐음. Jev mania 정점인 듯. 나는 벌써 Jev 피로 옴.
AI 회의론자들 난리 났는데, GOFAI 쪽으로는 Prolog로 만든 Proven Leftpad도 있음.