GeekNews Weekly

현대 AI의 발전사를 한 번에 훑을 수 있는 좋은 학습 지도입니다. CNN에서 RNN/LSTM, 어텐션과 트랜스포머, 스케일링 법칙과 정보이론까지 이어지는 흐름을 논문/강의 노트/코드 해설로 묶어, 원문 논문에 바로 뛰어들기 부담스러운 분에게 특히 유용합니다. 다만 제목의 “일리야 서츠케버가 존 카맥에게 추천한 30편”이라는 출처는 확정된 사실이라기보다 온라인에서 전해진 목록에 가깝고, 현재 정리된 항목도 27개입니다. 이름값에 기대기보다 관심 분야의 몇 편을 골라 직접 읽고 구현해보는 커리큘럼의 출발점으로 활용하는 편이 좋겠습니다.

코딩 에이전트 활용이 매번 다음 지시를 입력하는 방식에서, 정지 조건이 충족될 때까지 스스로 반복하는 루프로 넘어가고 있습니다. Antrophic에서 직접 작성한 이 글은 턴 기반/목표 기반/시간 기반/사전 대응형을 구분해, 어떤 작업에 어떤 반복 구조가 맞는지 구체적으로 보여줍니다. 특히 중요한 것은 에이전트를 오래 돌리는 기술보다, 테스트 통과/점수 임계치/최대 시도 횟수처럼 완료와 실패를 기계가 판정할 기준을 먼저 만드는 일입니다. 자율성을 높일수록 검증기와 중단 조건이 더 중요해진다는 점에서, 요즘 에이전트 워크플로를 설계하는 분들이 참고하기 좋은 글입니다.

요즘 절치부심 하고 있는 Meta 내부에서 8년간 13,000개 이상의 앱을 지탱해온 시스템이 공개됐다는 점만으로도 살펴볼 가치가 있습니다. 160개 이상의 React 컴포넌트와 디자인 토큰을 제공하지만, 더 흥미로운 부분은 CLI와 MCP를 통해 에이전트가 문서/템플릿/테마 규칙을 직접 읽을 수 있게 했다는 점입니다. 디자인 시스템이 사람이 찾아보는 컴포넌트 카탈로그에서, AI가 일관된 화면을 만들도록 제약과 맥락을 공급하는 실행 기반으로 확장되고 있습니다. 소스를 프로젝트로 가져와 직접 수정할 수 있는 swizzle과 스타일링 락인을 줄인 구조도 실제 도입을 검토할 때 눈여겨볼 부분입니다.

AI가 기능과 코드를 추가하는 비용을 거의 없애면서, 제품의 품질은 오히려 무엇을 넣지 않을지 결정하는 능력에서 갈리기 시작했습니다. 이 글은 단순함을 추상적인 미학으로 말하지 않고, 하루 수백 번 여는 컨텍스트 메뉴의 애니메이션처럼 작은 장식이 누적해서 만드는 비용을 구체적으로 보여줍니다. 에이전트는 요청한 요소를 빠르게 더할 수 있지만, 사용 맥락을 이해해 불필요한 것을 제거하는 일은 여전히 사람의 판단에 크게 의존합니다. 새 기능을 만들기 전에 “이것이 정말 필요한가, 반복 사용에서도 덜 방해되는가”를 묻는 제품 리뷰 체크리스트로 읽어볼 만합니다.

Slack이나 Discord를 그대로 복제하기보다, 실행 파일 하나로 가볍게 띄울 수 있는 단일 커뮤니티용 셀프 호스팅 채팅에 초점을 맞춘 프로젝트입니다. 서버 간 페더레이션과 서드파티 추적을 넣지 않고, 사용자별 키로 저장 데이터를 암호화하며 음성/영상 통화와 화면 공유까지 지원한다는 구성이 깔끔합니다. 모든 조직을 위한 거대한 협업 플랫폼보다는, 데이터 통제권과 단순한 운영을 중시하는 작은 팀/개인 커뮤니티에 더 잘 맞아 보입니다. 아직 0.4 버전으로 1.0 전까지 파괴적 변경 가능성이 있으니, 당장 핵심 업무에 넣기보다는 셀프 호스팅 대안의 방향성을 살펴보는 용도로 추천합니다.

LLM이 범용 지식노동을 평준화할수록, 오래 체득한 암묵지와 실제 활동의 맥락이 더 강한 차별점이 될 수 있다는 주장입니다. 취미는 결과만 얻는 것이 아니라 사람이 직접 배우고 반복하는 과정 자체가 가치이므로, 커뮤니티/습관/센서 데이터/전문 코칭을 결합한 제품에는 여전히 기회가 있다는 설명이 흥미롭습니다. 다만 모든 취미가 곧 사업이 되는 것은 아니며, 취미 인구의 열정이 실제 결제와 반복 사용으로 이어지는지는 별도로 검증해야 합니다. 커뮤니티가 해자가 되는가, 습관이 반복 매출을 만드는가, 도메인 지식을 AI 워크플로로 바꿀 수 있는가라는 세 질문은 니치 제품을 구상할 때 유용한 프레임입니다.

브라우저에서 서버 호출 없이 시맨틱 검색을 수행할 수 있도록, 모델/토크나이저/추론 엔진을 5~7MB짜리 WASM 파일 하나에 담은 프로젝트입니다. GPU 없이 CPU만으로 밀리초 단위 임베딩을 생성하므로, 브라우저 확장/개인 노트/정적 사이트/프라이버시가 중요한 내부 도구에서 검색 기능을 붙이는 방식이 크게 단순해집니다. 거대한 챗봇보다 요약/분류/검색 같은 작은 기능부터 로컬 AI가 라이브러리처럼 들어가는 최근 흐름을 잘 보여주는 사례입니다. 최대 입력이 128토큰이고 한국어 및 실제 도메인 데이터의 검색 품질은 따로 확인해야 하므로, 작고 제한된 코퍼스의 온디바이스 검색부터 시험해보는 것이 적절해 보입니다.

개발자의 역할이 바뀐다는 익숙한 선언보다, 사람이 하던 절차를 Playwright/커맨드/스킬/워크플로로 옮겨본 구체적인 경험이 이 글의 읽을거리입니다. AI가 실패할 때마다 오류를 복사해 전달하는 대신 브라우저를 직접 열고 검증하게 만들고, 언제 질문하고 멈추고 확인할지를 규칙으로 남기면서 개인의 암묵지를 재사용 가능한 시스템으로 바꿉니다. 동시에 커밋과 테스트의 수가 늘어도 제품 경험이 저절로 좋아지지는 않으며, 그럴듯한 프로토타입을 지속 가능한 구조로 정리하는 일이 별도로 필요하다는 점도 짚습니다. AI 코딩을 많이 쓰고 있지만 아직 자신의 작업 방식을 구조화하지 못한 분이라면, 코드 생성 이후의 제품화와 맥락 관리를 고민하는 데 도움이 될 글입니다.

OpenType의 셰이핑 규칙을 작은 프로그래밍 환경처럼 활용해, 대괄호 안의 텍스트를 폰트 자체가 QR 코드로 변환합니다. 이미지 생성/JavaScript/별도 전처리 없이 QR 코드가 일반 텍스트처럼 복사되고 저장된다는 점이 특히 기발합니다. 지원 길이와 문자 범위가 제한되고 브라우저 줄바꿈에 따라 코드가 깨질 수 있어 중요한 용도의 QR 생성기를 대체하기는 어렵지만, 폰트가 단순히 글리프를 표시하는 파일 이상이라는 점을 재미있게 보여주는 프로젝트입니다. 온라인으로 QR코드 생성기 검색해서 사용했다가 몇 달 후에 계속 연결되려면 결제하라는 메시지가 나왔다는 후기를 본터라, 이 프로젝트가 더 소중해 보이네요.

위클리 메인 주제로 다룬 인터뷰이지만, 재작성 이야기 외에도 도구를 만드는 사람의 제품 철학이 풍부하게 담겨 있습니다. Ghostty는 GPU 프로그래밍/데스크톱 시스템/Zig를 배우기 위한 개인 프로젝트로 시작했지만, 직접 매일 사용하는 과정에서 빠르고 기능이 풍부한 터미널로 발전했습니다. 사용하지 않는 기능은 실행 비용이 없어야 한다는 기능 풍부함과 부풀림의 구분, 개별 요청을 하나씩 더하기보다 여러 문제를 하나의 일관된 기능으로 해결하려는 접근도 인상적입니다. 개발 도구를 만드는 분이라면 API 설계/네이티브 UI/품질 기준에 관한 부분을 중심으로 읽어보시기 바랍니다. 저는 Ghostty 기반의 cmux 를 사용하는데 넘 만족하고 있어서, 미첼 하시모토에게 항상 감사합니다.

AI 도구의 생산성은 자주 이야기되지만, 그 결과물을 계속 읽고 검토하면서 생기는 리뷰 피로는 상대적으로 덜 논의됩니다. 저자가 지친 이유는 단순히 텍스트의 양이 많아서가 아니라, 허위 가정/환각/단정적인 문체처럼 비슷한 오류와 표현을 계속 마주치기 때문입니다. 조직에서 AI가 생성하는 코드와 문서가 늘어나면 생산량은 증가해도, 이를 판별하는 사람의 집중력이 새로운 병목이 될 수 있습니다. AI 사용량뿐 아니라 사람이 얼마나 많은 생성물을 읽고 판단해야 하는가도 함께 살펴봐야 한다는 점에서 공감할 만한 글입니다.

“코딩을 배우면 좋은 일자리를 얻는다”는 과거의 단순한 공식은 약해지고 있지만, 그렇다고 프로그래밍을 배울 이유까지 사라진 것은 아닙니다. LOGO와 Mathland 사례처럼 코딩은 수학을 지시받아 외우는 대신, 직접 움직이고 실패하면서 탐구하게 만드는 사고와 학습의 매체가 될 수 있습니다. AI가 문법과 구현을 대신해주더라도 문제를 분해하고/결과를 디버깅하고/기계가 실행할 수 있을 만큼 의도를 정확히 표현하는 능력은 여전히 필요합니다. 코딩 교육의 목적을 취업 기술이 아니라 논리/창작/컴퓨터 리터러시로 다시 바라보게 하는 글입니다.

Fable 로 떠들썩할 때, 전 GPT-5.6을 많이 기다렸는데요. 이번 발표에서 눈여겨볼 부분은 최고 벤치마크 점수보다 성능 대비 비용과 작업별 모델 구성입니다. 플래그십/균형형/저비용형으로 나뉜 Sol/Terra/Luna와 멀티에이전트 기반 ultra 모드는, 하나의 최고 모델을 모든 작업에 쓰기보다 업무 난도와 비용에 따라 모델을 배치하는 흐름을 보여줍니다. 실제 서비스에서는 절대 성능뿐 아니라 토큰 사용량/응답 속도/캐시 효율/반복 실행의 안정성이 더 중요한 경우가 많습니다. 발표 수치만 보기보다 자신이 반복해서 수행하는 작업으로 비용과 성공률을 함께 평가해보는 것이 좋겠습니다. 개인적으로 전 5.6 Sol에 매우 만족중입니다. 훨씬 똘똘해진거 같아요.

Apple의 컨테이너 플랫폼을 터미널 명령 대신 네이티브 macOS 인터페이스로 관리할 수 있게 해주는 앱입니다. Electron/웹뷰/별도 백그라운드 에이전트 없이 Apple의 데몬과 XPC로 직접 통신하면서 컨테이너 상태/로그/터미널/파일/이미지 빌드까지 한곳에서 처리합니다. Docker Compose도 가져올 수 있지만 아직 지원 범위가 제한적이고 Apple 컨테이너 플랫폼 자체의 제약도 남아 있어, Docker Desktop을 완전히 대체하는 단계로 보기는 이릅니다. 그래도 Apple Silicon에서 컨테이너 개발 환경이 Docker 중심 구조와 다른 네이티브 생태계로 발전할 가능성을 엿볼 수 있는 프로젝트입니다.

21년 가까이 기술 분야에서 일한 개발자가 전일제 근무와 병행해 온라인 컴퓨터과학 학위를 마친 현실적인 기록입니다. 약 3년 9개월 동안 상당수의 자유 시간을 학업에 쓰고, 총비용도 약 3,500만원이 들었다는 점에서 “온라인이니 가볍게 취득할 수 있다”는 기대와는 거리가 멉니다. 학위가 없어도 커리어를 쌓을 수 있었지만 비자/해외 취업/체계적인 지식 보완에서는 정규 학위가 여전히 의미가 있었다는 설명도 참고할 만합니다. 온라인 학위를 고민하고 있다면 홍보 페이지보다 먼저 읽고, 시간/비용/학위가 열어줄 선택지를 냉정하게 비교해보는 것이 좋겠습니다.

위클리 메인에서는 재작성의 경제성에 초점을 맞췄지만, 실무적으로 가장 크게 체감될 변화는 개발 피드백 루프의 단축입니다. 대형 코드베이스에서 빌드 시간이 8~12배 줄어드는 것뿐 아니라, 편집기에서 첫 오류가 나타나는 시간과 CI 대기 시간이 크게 줄어들면 개발자가 더 자주 타입 검사를 실행하고 더 작은 단위로 수정할 수 있게 됩니다. 다만 TypeScript를 내부 API로 사용하는 ESLint/Vue/Svelte/Angular 같은 도구들은 아직 TypeScript 6과의 병행이 필요합니다. 도입할 때는 컴파일러와 언어 서버의 성능 이득부터 활용하고, 플러그인/프레임워크 호환성은 별도의 이전 과정으로 보는 편이 안전합니다.

AI 에이전트가 별도 앱에 머무르지 않고 Slack/Discord/Telegram 같은 기존 대화 공간 안으로 들어오는 흐름을 보여주는 프로젝트입니다. 단순히 질문에 답하는 챗봇이 아니라, 스레드의 맥락을 읽고 도구를 호출한 뒤 표/차트 같은 결과를 대화 안에 표시하며, 실제 작업은 승인 이후에만 실행하도록 구성했습니다. 특히 같은 에이전트 코드를 여러 메신저에 연결할 수 있다는 점은 조직용 AI 인터페이스가 특정 플랫폼에서 점차 분리될 가능성을 보여줍니다. 셀프 호스팅으로 모델/데이터/도구를 통제할 수 있는 대신 런타임과 상태 저장까지 직접 운영해야 하므로, 락인을 줄이는 만큼 운영 책임이 늘어난다는 점도 함께 봐야 합니다.

AI 시대에 Lisp를 배운다는 것이 다소 시대착오적으로 들릴 수 있지만, 이 글의 가치는 특정 언어의 취업 수요보다 프로그래밍 언어가 어디까지 확장될 수 있는지 보여주는 데 있습니다. 코드와 데이터를 같은 구조로 다루는 매크로/실행 중인 프로그램을 계속 바꾸는 REPL 중심 개발/문제에 맞춰 언어 자체를 키워가는 사고방식은 요즘의 에이전트 개발과도 묘하게 연결됩니다. 반면 팀마다 독자적인 DSL을 만들어버리면 뒤에 온 사람이 해독해야 할 또 다른 레거시가 될 수도 있습니다. Lisp로 제품을 만들 계획이 없더라도, 언어가 제공하는 추상화의 경계를 다시 생각해보는 학습용 언어로 읽어볼 만합니다.

모든 요청에 가장 비싼 모델을 쓰는 대신, 프롬프트마다 적절한 모델을 골라주는 추론 라우팅 레이어가 점점 중요한 인프라로 떠오르고 있습니다. 이 도구는 OpenAI / Anthropic / Gemini와 여러 오픈 모델을 하나의 엔드포인트로 묶고, 요청 내용을 로컬 분류기로 판단해 매 턴 모델을 선택합니다. 다만 프로젝트가 주장하는 40~70%의 비용 절감은 실제 코드베이스/프롬프트 분포/실패 재시도까지 포함해 직접 검증해야 하며, 모델이 자주 바뀌면 프롬프트 캐시와 응답 일관성에서 손해를 볼 수도 있습니다. 결국 좋은 라우터의 기준은 가장 싼 모델을 고르는 것이 아니라, 작업 성공률/지연 시간/캐시/비용을 함께 최적화하는가에 있습니다.

개발자 플랫폼의 경쟁력은 모델 성능만이 아니라 가격의 예측 가능성/도구 선택권/이동 가능성에서도 만들어집니다. 이 글은 Claude 구독을 Anthropic의 자체 도구에는 넉넉하게 제공하면서 제3자 하네스에는 별도 API 과금을 적용하는 정책이, 개발자가 기대한 구독 가치와 어긋난다고 비판합니다. 모든 주장에 동의할 필요는 없지만, OpenRouter 같은 게이트웨이와 여러 대체 모델이 존재하는 지금은 사용자를 묶는 정책이 오히려 다른 생태계로 옮길 이유를 만들어줄 수 있습니다. 개발자의 호감과 신뢰도 플랫폼의 중요한 해자라는 관점에서 읽어볼 만한 글입니다. 얼마전 위클리에서 "AI 시대의 개발 생태계는 이렇게 만들어 가는 겁니다" 라고 제가 Anthropic을 칭찬했었는데, 몇달사이에 또 신뢰를 잃어가고 있다는 얘기가 보이니 참 여러 생각이 듭니다.

일반적인 백업이 데이터베이스 전체를 과거 시점으로 돌리는 도구라면, 이 프로젝트는 MySQL의 binlog를 이용해 특정 행이 언제/어떻게 바뀌었는지 추적하고 잘못된 변경만 되돌리는 도구에 가깝습니다. UPDATE 조건을 잘못 넣었거나 cascade delete로 연관 데이터까지 사라졌을 때, 전체 복구 없이 필요한 역방향 SQL을 만들 수 있다는 점이 실무적으로 매력적입니다. MCP 서버도 제공해 에이전트가 변경 이력을 조사하고 복구안을 작성할 수 있지만, 데이터 복원은 영향 범위가 큰 작업인 만큼 최종 실행은 반드시 사람이 검토해야 합니다. 애플리케이션 로그만으로 원인을 찾는 것에서 한 단계 나아가, 데이터 변경 자체를 관측 가능한 이력으로 만드는 흐름을 보여줍니다.

사진을 90도 돌리는 버튼 하나만으로도 제품의 완성도가 얼마나 세밀한 곳에서 갈리는지 보여주는 글입니다. 사용자가 버튼을 빠르게 여러 번 눌렀는데 애니메이션 중이라는 이유로 입력을 무시한다면, 소리와 햅틱으로는 성공했다고 알려주면서 실제 동작은 하지 않는 모순이 생깁니다. AI로 화면과 컴포넌트를 빠르게 만드는 시대에도 이런 연속 입력/중단/대기 상태/피드백의 일치는 자동으로 해결되지 않습니다. 버튼의 평상시 모습보다, 사용자가 예상보다 빠르고 반복적으로 조작했을 때 어떻게 반응하는지를 살펴보게 하는 좋은 UX 사례입니다.

Figma의 성공은 그림을 더 잘 그리게 만든 것보다, 디자인 파일을 모두가 함께 보고 논의하는 협업과 조정의 공간으로 바꾼 데 있었습니다. 그런데 AI가 디자인 시스템/컴포넌트/API를 읽고 곧바로 동작하는 인터페이스를 만들기 시작하면, 캔버스는 더 이상 구현 전에 반드시 거쳐야 하는 단계가 아닐 수 있습니다. 그래서 Figma의 다음 과제는 코드 생성 기능을 계속 붙이는 것이 아니라, 디자이너/개발자/PM이 제품의 의도와 제약을 합의하는 공유된 진실의 공간을 계속 차지할 수 있느냐에 있습니다. 기존의 가장 강력한 자산인 캔버스를 지키려는 전략이 오히려 다음 변화를 놓치게 할 수 있다는, 전형적인 혁신가의 딜레마를 잘 짚은 글입니다.

AI 에이전트에게 Vega-Lite/ECharts/Chart.js의 세부 옵션을 모두 생성하게 하면 명세가 길어지고, 작은 실수 하나로 차트가 깨지기 쉽습니다. Flint는 데이터의 의미 타입과 원하는 차트 구조만 짧게 표현하면 축/스케일/간격/레이아웃을 컴파일러가 채우는 시각화용 중간 언어를 제안합니다. 자연어에서 곧바로 최종 코드를 생성하기보다, 사람이 읽고 수정할 수 있는 제한된 명세를 중간에 두는 방식은 앞으로 에이전트 도구 전반에서 더 자주 보게 될 패턴입니다. 다만 보기 좋은 차트를 자동 생성하는 것과 데이터를 올바르게 해석하는 것은 별개의 문제이므로, 차트 선택/축 범위/집계 방식이 결론을 왜곡하지 않는지는 여전히 사람이 확인해야 합니다.

위클리 메인에서는 53만 줄의 코드를 11일 만에 옮겼다는 결과를 다뤘지만, 실제로 더 참고할 만한 부분은 AI 작업을 통제한 방법입니다. 포팅 규칙과 수명 정보를 문서로 고정하고, 구현 에이전트와 별도의 적대적 리뷰어를 둔 뒤, 기존 테스트를 6개 플랫폼에서 모두 통과시켰습니다. AI가 알아서 재작성한 것이 아니라, 사람이 먼저 명세/검증기/작업 분할/중단 조건을 촘촘하게 만든 대규모 자동화에 가깝습니다. 에이전트를 여러 개 병렬로 돌리려는 팀이라면 결과보다 이 작업 구조를 자세히 살펴볼 만합니다.

앞에선 Rust 전환을 언어의 승패로만 보면 안 된다는 반론을 소개했는데, 이 글은 그 주장을 상당히 공격적으로 밀어붙입니다. 버그 감소/바이너리 축소/퍼징 강화 같은 성과 중 상당수는 Rust로 옮겨서 자동으로 얻은 것이 아니라, 이전 코드베이스에 충분한 엔지니어링 시간을 투자하지 않다가 재작성 과정에서 한꺼번에 수행한 작업이라는 지적입니다. 특히 기존 테스트가 Zig 버전의 수많은 버그를 잡지 못했는데, 같은 테스트가 100만 줄 규모의 새 코드를 보증한다는 주장에는 모순이 있다는 질문이 날카롭습니다. 표현에는 감정이 많이 섞여 있지만, 기술 교체의 효과와 뒤늦게 투입한 품질 개선 비용을 분리해서 봐야 한다는 관점은 조직의 재작성 프로젝트에도 그대로 적용됩니다.

위클리 메인의 결론에 사용한 글이지만, 실무적으로는 코드베이스 자체가 에이전트에게 주는 프롬프트라는 관점이 핵심입니다. 모델은 팀의 이상적인 코딩 규칙보다 현재 저장소에 반복되어 있는 패턴을 더 강한 신호로 받아들이기 때문에, 임시 조건문 하나가 다음 복사본을 계속 불러올 수 있습니다. 앞으로 코드 리뷰는 이번 변경이 동작하는지만 보는 것이 아니라, 이 패턴을 AI가 앞으로 계속 복제해도 괜찮은가까지 확인해야 할 것 같습니다. 결국 AI가 읽기 좋은 코드베이스를 만드는 일과 사람이 유지보수하기 좋은 코드베이스를 만드는 일은 크게 다르지 않습니다.

역시나 새 Grok 모델의 발표에서도 눈여겨볼 부분은 출력 토큰 효율과 실제 작업 비용입니다. 복잡한 코딩 문제를 풀면서 경쟁 모델보다 훨씬 적은 토큰을 사용한다면, 에이전트를 반복 실행할 때 비용/대기 시간/컨텍스트 사용량에서 의미 있는 차이가 생깁니다. 요즘 프런티어 모델들의 성능 격차가 줄면서, “가장 똑똑한가”보다 같은 작업을 얼마나 짧고 안정적으로 끝내는가가 더 중요한 평가 기준이 되고 있습니다. Cursor에서 제한적으로 무료 사용도 가능하니, 평소 사용하는 실제 리포지토리에서 성공률과 토큰 사용량을 함께 비교해보면 좋겠습니다. 써본 사람들 평으로는 거의 무제한처럼 쓸 수 있다는 평가도 보이더군요. 일단 뒤쳐진 상태니 제공하는 토큰량으로 푸시하는 것 같아요.

기존 음성 AI는 사용자가 말을 멈추면 답하는 구조였지만, 이번 모델은 듣기와 말하기를 동시에 처리하는 풀듀플렉스 대화로 넘어갑니다. 짧게 맞장구치고/사용자가 생각할 때 기다리고/자연스럽게 끼어드는 능력은 벤치마크 점수보다 실제 대화 경험을 훨씬 크게 바꿀 수 있습니다. 더 흥미로운 것은 깊은 검색과 추론은 다른 모델에 맡기고, 그동안 음성 모델이 대화를 계속 이어가는 역할 분리입니다. 음성 인터페이스가 단순한 STT/TTS 기능에서 벗어나, 뒤에서 여러 에이전트를 움직이는 실시간 프런트엔드로 발전하는 모습을 보여줍니다.

도구를 능숙하게 다루는 즐거움과 그 도구가 실제로 생산적인지는 별개의 문제라는 이야기입니다. 불편한 작업을 매크로나 복잡한 설정으로 해결하고 나면 자신이 영리하고 생산적으로 일했다는 느낌이 들지만, 다른 도구였다면 애초에 몇 번의 조작으로 끝났을 수도 있습니다. 특정 편집기/TUI/개발 환경이 자신의 정체성이 되면 단점을 인정하는 일까지 어려워진다는 지적도 꽤 뜨끔합니다. 도구를 평가할 때 멋있음이나 몰입감보다 실제로 걸린 시간/실수 횟수/맥락 전환 비용을 기준으로 삼아보게 하는 글입니다.

오랫동안 기다렸던 국내 HW3 차량 소유자에게는 반가운 업데이트네요. 이번 배포는 미국 생산 Model 3/Y 가운데 FSD가 활성화된 HW3 차량이 대상이며, 모든 차량에 동시에 적용되는 것은 아닙니다. 이름에 Lite가 붙은 만큼 최신 하드웨어와 동일한 기능을 기대하기보다, 기존 차량에서 어디까지 구현되는지를 실제 주행 후기로 확인할 필요가 있습니다. 국내 몇 분들이 주행후기를 올리시던데, 제 차에도 빨리 풀리기를 기다리고 있습니다.

배포가 시작되자 마자 테슬라 코리아는 기존 구매형 FSD를 종료하고, 구독형으로 8월초에 다 바꾼다고 안내하네요. 잘 선택하시기 바랍니다. 전 이미 사버렸고, BMS오류로 신형 배터리로 교환까지 해버려서 폐차할 때까지 안고 가렵니다.

제목 때문에 살짝 오해가 많이 생기는데요. 실제로는 이제 Codex 앱이 ChatGPT 앱이 되어버렸습니다. 거기에 다양한 기능이 들어오면서 ChatGPT가 답변을 만들어주는 도구에서, 앱/파일/브라우저를 오가며 완성물을 만드는 업무 실행 환경으로 확장됩니다. Slack/Teams/Drive/이메일/캘린더의 맥락을 연결하고, 조사 결과를 문서나 슬라이드로 만든 뒤 반복 작업까지 예약됩니다. 페이지를 만들어서 공유하는 사이트 기능에 깃헙 풀 리퀘스트 확인 등이 모두 유기적으로 결합되었습니다.

하나 아쉬운건 기존 ChatGPT의 프로젝트 기능이 Codex 프로젝트하고 이름이 겹쳐서인지 지원이 안되는 상황인데요. 웹에는 아직 남아있으니 곧 지원하게 되지 않을까 싶네요