최근 TypeScript로 짜여있던 Svelte 코드를 JS+JSDoc 다시 작성한다는 소식이 JS커뮤니티를 떠들썩하게 했는데요, 이에 대한 @Rich_Harris의 답변이 인상적입니다:

→ Svelte팀은 TS의 지원을 중단하는 것이 아닙니다. Type safety를 포기하는 것도 아닙니다.

→ JSDoc 사용은 TypeScript에서 공식 지원합니다. TS를 사용하는 Svelte 유저분들에겐 전과 똑같은 기능을 지원할 것입니다.

→ JSDoc을 사용하기 원하는 이유가 몇가지 있습니다. 첫번째, JSDoc으로 작성된 Svelte 패키지는 작아집니다. 더이상 TS→JS sourcemap을 배포할 필요가 없기때문이죠.

→ 두번째, Svelte 개발 중 디버깅이 더 쉬워집니다. Go To Definition이 구현 코드가 아닌 타입 정보가 담긴 index.d.ts로 끌려간적이 있으신가요? JSDoc으로 작성된   Svelte코드는 그런 불편함도 없을 것이고, 또 그 자리에서 즉시 소스를 수정을 해볼 수도 있죠.

→ 세번쩨, Svelte에 기여하기가 더 쉬워질 것 입니다. TypeScript은 빌드 시스템의  사용을 의무화 합니다. 또 TS 개발을 수월하게 만들어 주는 코드 링크나 소스 수정을 즉각 빌드하는 watch 시스템의 사용도 필요합니다.

→ 더 나아가 복잡한 빌드 시스템의 제거는 Svelte팀의 다양한 테스트 파이프라인의 관리 및 디버깅 과정도 수월하게 만들어 줄거라 기대하고 있습니다.

→ TS to JSDoc Migration은 어떤 이념이나 철할은 토대로 내린 결정이 아닙니다. 단순히 Svelte팀에 더 편하게 일하려고 하는 것 입니다.


→ TS의 광적 신도님들, 또 안티님들 모두 실망시켜드려 죄송합니다. 하지만 저희 결정을 특정 진영에 힘을 실어 줄 순 없을 것 입니다.

https://news.ycombinator.com/item?id=35892250

TIL: TypeScript가 JSDoc을 정식 지원하는건 이번에 처음 알았네요

https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html

You can read the unrolled version of this thread here: https://typefully.com/dylayed/XalfMuZ

왜 Svelte 프로젝트는 TypeScript에서 JSDoc으로 이전하는가?

"개발자의 생산성"을 이야기 할때 "개인"의 생산성으로 혼동해 IDE/원격근무/ChatGPT(!?) 등 개인 환경의 대화로 시작하지만, 결국은 중요한건 개발"팀"의 생산성.

특히 개발 조직이, 서비스가 커지면서 자연스레 더뎌지는 속도를 잡기위해 "Bezos API Mandate"같은 개발 조직 전체의 변화가 필요하다

TIL: Core Web Vitals Technology Report

웹을 크롤링하며 사이트가 어떤 기술을 사용해 만들어 졌고, 사이트의 Core Web Vital 점수의 분포를 정리한 리포트.

웹 기술의 유행이 속도가 너무 빨라 항상 늦은 느낌이지만, 아직 웹의 대부분은 "old tech" (jQuery, PHP, Wordpress)로 돌아가는구나.

여러 기술들이 얼마나 채택되고 있는지 볼수있어 재미있는 리포트다:

cwvtech.report

Core Web Vitals Technology Report

로젠버그 박사님의 "비폭력대화" (NVC)를 읽으며 연습해보는 "비폭력 코드 리뷰":

"실력이 형편없습니다"
→ 사람을 공격하지 말자.

"코드가 형편없습니다"
→ 판단/평가가 아닌 관찰을 하자.

"코드가 꼬여있습니다."
→ 여전히 판단/평가 중.

"제어 가능한 코드와 불가능한 코드가 서로 얽혀 이해하기 어렵습니다."
→ 관찰! 관찰!

"제어 가능한 코드와 불가능한 코드가 서로 얽혀 이해하는데 시간이 걸렸습니다."
→ 이제 느낀점을 표현해보자

"... 두 부분이 잘 분리되어 있다면 코드 관리 및 추후 수정이 더 편할거 같다 생각했습니다."
→ 마지막으로 바라는 점

"... ABC.java나 EFG.java 파일에 있는 좋은 예시를 참고하여 수정 부탁드립니다."
→ 👍

대화하는 법은 평생 배워야 하는구나!

비폭력 코드리뷰

"우수한 개발팀"의 지표를 딱 하나 꼽으라면:

👉 서비스 배포 주기

견고한 개발 문화의 기반 없이 배포 주기를 줄일 순 없다. 반면, 고품질 서비스의 개발 과정에선 빠른 피드백을 받을 수 있는 짧은 주기의 배포가 유리하다.

당근: 1+ 배포/day
GitHub: 20+ 배포/day
Stripe: 16+ 배포/day

뛰어난 성과를 보이는 "10x 개발자"가 있는지는 알 수 없지만, 팀의 생산성에 부정적인 영향을 미치는 "-10x 개발자"는 누구나 한번쯤 경험해 봤을듯하다.

40시간 일을하며 400시간을 낭비하는 "-10x 개발자"의 행동:

1. 일 뒤엎기 - 요구 사항을 애매하게 작성. 뒤 늦게 변경을 요구.

2. 일이 아닌 일 - 불필요한 사내 발표를 추진. 의미없는 문서 작성 및 절차를 요구. 영양가 없는 데일리 미팅 일정을 잡음.

3. 번아웃을 촉진 - 비판적이고 공격적인 태도로 대화. 조직의 방향을 꾸준히 의심. 팀원의 피드백을 철저하게 무시해 갈등을 유발.

4. 끊임없는 기술적 토론 - 실용적인 해결책을 비판하고 완벽함을 추구. 결정자의 권한을 빼앗아 프로젝트 진행을 지연. 책임 회피.

5. 쓸대없이 일 키움 - 여러 팀이 포함된 미팅을 주도. 다른 팀을 프로젝트에 끌어와 요구 사항을 창조함 . 개발 문서를 널리 공유하고 모든 의견을 수용.

6. 개발 자원 낭비 - 느린 프로그램 작성. DB 인덱스 사용을 거부. 크고 비싼 RAM/CPU에 의존해 성능 향상.

7. 개발 시간 낭비 - 내가 안쓴 코드 == 쓰레기. 무조건 처음부터 다시 작성. 다른 프로젝트에 재사용이 어려운 코드를 작성. 문서화 작업은 철저히 배제.

8. 느린 빌드/테스트 - 빌드 시간이 길면 개발자의 집중이 깨짐을 최대한 악용. 느린 테스트를 작성해 개발팀 시간을 낭비. 쓸대없고 이유없이 고장나는 테스트를 작성.

9. 엉성한 설계 - 설계에 주의를 기울이지 않고, 확장성과 유지보수가 어려운 코드를 작성. 테스트 코드를 당연히 없음.

10. 테스트 환경 - 여러 테스트 환경을 생산해 (sandbox, dev, daily, qa, test, integration, staging, pre-prod, beta, canary) 프로젝트가 릴리즈 되는 시간을 최대한 지연.

11. 정치 - 다른 "-10x 개발자"를 적극적 채용. 정치질로 입지를 다지고 갈등이 있는 훌륭한 개발자들을 쫒아냄.

쓰기만해도 현기증이 나네요. "-10x 개발자"의 더 많은 특징은:

https://taylor.town/-10x

-10x 개발자

Prompt engineering이 과학적으로 느껴지지 않는 이유는 "이게 왜 돼?" 라는 질문엔 답이 없기때문이라 생각하는데, 통계적 학습이론은 언제나 이런 갈등이 있던 것 같다:

"The Norvig - Chomsky debate"

춉: "통계적 접근의 성공은 인정. 하지만 과학이 추구하는 상호작용의 이해와는 거리가 멀다"

https://twitter.com/d_ijk_stra/status/1639857581496897537

지금 펼쳐지고 있는 통계적 학습이론의 눈부신 활약은 의심의 여지가 없다.  하지만 많은 과학자들이 오랜 시간동안 과학적으로 이해하고 설명하려 했던 사람의 의식/언어학습/Symbolic AI 같은 학술분야에서 부터 우리 사회가 돌아올 수 없는 강을 건넌 것 같아 아리송한 마음이 든다.

The Norvig - Chomsky Debate and Statistical Learning Theory

디버깅 관한 일화 중 제일 좋아하는 "바닐라 아이스크림 알러지가 있는 자동차":

자동차 회사 폰티악 개발팀에 흔치 않은 고객 클레임이 들어왔다. "제 자동차는 바닐라 아이스크림 알러지가 있는 것 같습니다."

자초지종을 들어보니 차주는 매 일요일 아이스크림을 사러 가는데...

바닐라 아이스크림을 사는 날에는 필히 차 시동이 걸리지 않는다는 것이다. 말도 안 되는 사유에 당황했지만 개발 리드는 일단 엔지니어 한 명을 보냈다.

"저도 믿기지 않지만 확인되었습니다. 처음 바닐라 아이스크림을 사 왔을 땐 걸리지 않던 시동이 초콜릿 사 왔을 땐 잘 걸렸습니다."

"희한하게 초콜릿과 바닐라 아이스크림 함께 사올때는 또 문제가 없습니다. 초콜릿이 바닐라 알러지를 상쇄시키는 무언가가 있을까요?"

개발 리드는 엔지니어 머리를 한 대 쥐어박고 다시 보내었다.

"바닐라와 초콜릿 아이스크림를 샀을때 다른 점를 모두 찾아 보고해."

엔지니어의 새로운 보고를 받은 개발 리드는 한참을 고민 후 고객에게 전화를 걸었다.

"바닐라 아이스크림을 사고 오는 시간이 짧은데, 바닐라 아이스크림을 빨리 오더할 수 있는 시스템이 있나 보죠? (네) 과열된 엔진의 열이 식을 시간이 부족했던 것 같습니다. 시간을 두시고 시동을 걸어주세요."

코딩 버그를 해결할때도 거의 대부분 예상하지 코드가 이슈인 경우가 많다.

디버깅하며 얼마나 많은 시간을 "바닐라 알러지 이유"나 "초콜릿 바닐라 상호관계"같은 질문의 답을 찾으며 보냈는지 모르겠다 🤣.

바닐라 알러지가 있는 자동차

OpenAI 연구팀이 공개한

"LLM-기반 인공지능 기술에 영향이 없는 34 직종"

1. 농업 장비 운영자
2. 운동선수 및 스포츠 선수
3. 자동차 유리 설치 및 수리공
4. 버스 및 트럭 정비사 및 디젤 엔진 전문가
5. 시멘트 조적공 및 콘크리트 마감자
6. 요리사 (조리사)
7. 커터 및 트리머, 수작업

8. 석유 및 가스 노동자
9. 식당 서빙, 바텐더
10. 주방 보조
11. 준설 작업자
12. 전력선 설치자 및 수리공
13. 굴착 및 적재 기계 및 드래그 라인 운영자, 지표 광업
14. 벽돌공, 석공, 타일공
15. 주조 금형 및 코어 제작자
16. (보조) 벽돌공, 석공, 타일공
17. (보조) 목수

18. (보조) 페인터, 도배공, 미장공 및 치장 벽토공
19. (보조) 배관공
20. (보조) 지붕수리공
21. 정육 및 수산물 가공
22. 오토바이 정비사
23. 도로 포장 장비 기사
24. 파일 드라이버 운영자
25. 타설기 및 캐스터, 금속
26. 기차 궤도 부설 및 유지보수 장비 운영자

27. 내화 재료 수리공
28. 채광 굴삭기 운전사
29. 인부, 석유 및 가스
30. 도축업자 및 육류 포장업자
31. 석공
32. 벽체 마감
33. 타이어 수리공
34. 유정 펌퍼 근로자

"손이 필요한 노동은 인간이 하도록!" 명령하는 것 같네

LLM-기반 인공지능 기술에 영향이 없는 34 직종

I see a lot of people compare OpenAI to AWS - as a provider of infrastructure where you build apps on TOP of it.

But what if OpenAI is more like Apple - as an owner of an ecosystem where they build a direct relationship with the end user and you build apps AROUND it.

OpenAI-as-API forces the developers to launch with a business model that covers their OpenAI API usage or ask users to hand over their API key to use the product.

Both are a barrier to entry. OpenAI can (has) reduce the barrier by lowering the cost, but the barrier stands.

In OpenAI-as-Ecosystem, app developers access the OpenAI API that the user brings with them - a ChatGPT Plus subscription, or the rumored Foundry clusters, or - in the future - a personalized LLM tuned specifically for the user.

"But that assumes that most people will pay to use OpenAI. That'll never happen!"

Maybe. But I don't think the future where we surrender few hundred dollars a year to access the best AI model isn't as crazy as it sounds. We already do something like that with phones.

The bet is that the impact the AI-powered apps - either in productivity or entertainment - will be as big, if not bigger, than what smartphones has done in the past two decade.

I really don't think this is a moonshot kinda bet. To a lot of people, this is already happening.