GeekNews Weekly

메인에서도 다룬 글인데, 본문은 단순히 "쉬엄쉬엄 일하라"가 아니라 평소 80% 가동률을 유지하라는 구체적 전략을 담고 있습니다. 코드를 덜 짜라는 게 아니라 늘 바쁜 상태로 자신을 채워두지 말라는 뜻인데요. 큰 계약 지원이나 사고 완화처럼 회사 성과를 좌우하는 일은 갑자기 시간 의존적으로 찾아오는데, 이미 자잘한 작업으로 꽉 차 있으면 그 기회를 잡을 여유조차 없다는 거죠. 글루 작업이나 과도한 도움, 무보상 노동을 의도적으로 거절하라는 도발적인 조언도 인상적인데, 이를 RPG의 마나 관리에 빗댄 댓글이 특히 가슴에 와닿네요.

메인에서 "장인 정신"을 언급했지만, 이 글의 진짜 묘미는 장인 대 빌더라는 이분법을 해체하는 데 있습니다. 2026년 4월 기준 구글 신규 코드의 75%가 AI 생성일 만큼 누구나 빌더가 된 시대에, 저자는 "둘 중 하나"가 아니라 빠르게 만드는 빌더이자 깊이 있는 장인인 하이브리드가 답이라고 말합니다. 특히 프로토타입과 실제 운영되는 소프트웨어 사이에는 큰 차이가 있기 때문에, AI가 만든 코드를 이해하고 견고하게 만드는 축적된 경험의 가치는 더 커질 수밖에 없어 보입니다.

"취향"을 막연한 감각이 아니라 인식·나침반·비전이라는 세 층위로 분해하고, 결국 하나의 내부 평가 함수의 품질로 수렴한다고 정리한 글입니다. OpenAI Codex·Claude Code 제작자들의 실제 사례가 풍부한데, Boris Cherny가 todo 기능 하나를 위해 이틀간 20개 프로토타입을 만든 일화나, 핵심 코드 30%만 손으로 짜는 "30/70 규칙" 같은 구체적인 디테일이 읽는 재미를 줍니다. 무엇보다 "경험을 더 쌓아라" 같은 공허한 조언 대신 90일 훈련 계획까지 제시해서, 취향이 타고나는 게 아니라 기를 수 있는 근육이라는 점을 실천 가능하게 풀어냅니다.

같은 "취향" 주제지만, 이 글은 더 날카로운 한 문장으로 압축됩니다. 취향 없는 속도는 그저 대규모로 증폭된 소음이라는 거죠. AI가 실행의 하한선을 끌어올리면서 진짜 병목이 판단력으로 옮겨갔고, 그래서 기능을 더하기보다 빼는 "편집자형 엔지니어" 가 부상한다는 진단입니다. 검색 기능을 통째로 들어내고 더 나은 기본값만 남겼더니 제품이 좋아졌다는 사례처럼, "예"보다 "아니오"를 더 많이 말하는 능력이 새로운 10x라고 이야기 합니다.

앞서 소개한 "취향" 글들이 개발자 개인의 역량에 초점을 맞췄다면, 이 글은 한 발 더 나아가 취향을 기업의 해자(moat)로 봅니다. 코드도 가격도 하룻밤에 복제되는 시대에 끝내 복제 안 되는 건 제품의 "느낌(feel)" 이라는 거죠. 특히 디자인을 단순한 미감이 아니라 사용자가 “이 제품을 믿어도 되는가”를 판단하는 신뢰 인프라로, 절제를 경쟁력으로 보는 관점이 좋았습니다.

아무리 잘 만들어도 발표에서 잘 안되면 끝인데, 대부분의 개발자는 만들기만 좋아하고 데모 연습엔 투자하지 않죠. PostHog 팀이 수많은 데모를 관찰해 24가지 팁으로 정리한 실전 가이드입니다. "기억시킬 핵심 메시지 하나에 모든 걸 집중하라", "사과로 시작하지 말라", "슬라이드만 넘기지 말고 직접 만들어 보여주는 능동적 데모로 가라" 같은 조언이 구체적인데, 무엇보다 데모 셋업 체크리스트(알림 끄기, URL 북마크, WiFi 백업 스크린샷 등)는 발표를 앞둔 사람이라면 바로 써먹을 만합니다. 해커톤이나 투자 피치를 준비 중이라면 한 번 훑어보세요.

프롬프트 → 컨텍스트 → 하네스에 이어 이번엔 "루프" 엔지니어링이 등장했습니다. 매 턴 직접 프롬프트하는 대신, 에이전트를 대신 찔러주는 시스템을 설계하라는 개념인데요. Automations, Worktrees, Skills, Connectors, Sub-agents 다섯 구성요소가 이제 Claude Code와 Codex 양쪽에 거의 그대로 탑재되어, 1년 전이라면 bash로 직접 짜야 했던 걸 제품 기능으로 쓸 수 있게 됐다는 점을 짚습니다. 중요한건 마지막 문단인거 같아요. "루프를 만들되, 엔지니어로 남아라"

"AI로 다들 10배 생산적이라는데, 왜 가치가 10배 오른 기업은 없을까?" 란느 도발적 질문으로 시작합니다. 이거 저도 궁금했거든요. 답으로 끌어온 역사적 사례가 흥미로운데, 1890년대 방직 공장이 증기기관을 전기 모터로 바꾸고도 30년간 산출이 안 늘다가, 공장 구조 자체를 조립 라인으로 재설계한 뒤에야 수익이 터졌다는 거죠. 지금 AI도 "모터만 갈고 공장은 그대로"인 상태라는 진단입니다. 개인의 생산성을 높이는 Individual AI를 넘어, 조율·신호·객관성을 만드는 Institutional AI가 필요하다는 7가지 기둥 분석이 B2B AI를 고민하는 분들에게 좋은 프레임을 줍니다.

10년 차 엔지니어가 자신의 결제·금융 백엔드, 도메인 지식, 분산 시스템 디버깅 같은 전문성 들이 도메인 지식 → 디버깅 → 코드 품질 순으로 차례차례 무너지는 과정을 담담히 기록한 글입니다. 분산 시스템 버그의 90%를 AI가 원샷으로 잡고, 마지막 보루였던 아키텍처마저 "취향(taste)"이라는 한 단어로 축소되는 현실을 토로하는데, 마지막엔 목공으로 전직을 고민할 만큼 막막함이 짙게 묻어납니다. 다만 이 글의 진짜 가치는 1000개가 넘게 달린 HN 댓글 토론에 있는데요. "도메인이 진짜 해자다 vs 그 전통이 끝난 게 핵심이다", "결정론적 도구로 감싸라", "코딩은 죽었어도 소프트웨어 엔지니어링은 살아있다" 같은 격론이 오간 걸 볼 수 있습니다. 댓글 요약본도 일부니까 원문의 댓글도 한번 더 둘러보세요.

Lean Startup의 Eric Ries가 이제는 스타트업 방법론이 아니라, 좋은 회사가 왜 시간이 지나며 망가지는가를 이야기합니다. 핵심 개념인 financial gravity는 회사가 어느 날 갑자기 악해지는 게 아니라, 투자자·이사회·거버넌스·인센티브 구조에 의해 서서히 창립 미션에서 멀어진다는 설명인데요. Costco, Patagonia, Novo Nordisk 같은 기업을 단순한 리더십 사례가 아니라 거버넌스 구조 덕분이라고 해석하는 부분이 흥미롭습니다. “미션 중심”이라는 말이 선언문이 아니라, 실제 구조와 비즈니스 모델에 설치되어야 하는 엔진이라는 관점은 창업자들이 한 번쯤 곱씹어볼 만합니다.

빠른 생산성 도구의 대명사로 꼽히는 Linear의 속도 비결을 코드 레벨까지 파고든 기술 분석입니다. 핵심은 서버를 진실의 원천이 아니라 동기화 대상으로 두는 발상으로, 데이터베이스를 브라우저의 IndexedDB에 두고 변경을 로컬에 먼저 적용한 뒤 백그라운드로 흘려보내 사용자는 네트워크 지연을 거의 느끼지 못합니다. 여기에 MobX 기반 상태 관리, WebSocket 델타 전파, 공격적인 코드 분할, 레거시 브라우저 포기 같은 결정들이 겹쳐서 지금의 체감 속도가 만들어졌다는 분석입니다. 결국 빠른 제품은 “성능 최적화 팁” 하나가 아니라, 속도를 제품 경험의 핵심으로 보는 아키텍처 선택에서 나온다는 걸 잘 보여줍니다.

AI 에이전트가 정말 유용해지려면, 단순한 RAG를 넘어 사용자와 작업 맥락을 오래 기억하는 메모리 계층이 필요하다는 문제의식에서 나온 도구입니다. 대화에서 사실을 추출하고, “SF로 이사했다”가 “NYC에 산다”를 대체한다는 식의 모순 처리와 자동 망각까지 지원한다는 점이 흥미롭습니다. 다만 댓글처럼 이런 AI 메모리 도구들이 너무 빠르게 쏟아져 나와서 차별점을 파악하기 어렵다는 점도 같이 봐야 할 것 같습니다.

Ed Zitron이 특유의 격앙된 톤으로 AI 인프라의 재무 지속가능성을 정면으로 의심하는 글입니다. 계획된 데이터센터를 다 지으려면 2030년까지 연 2조 달러가 넘는 컴퓨트 매출이 필요한데, OpenAI·Anthropic의 매출 전망을 합쳐도 한참 못 미친다는 계산이 핵심입니다. 물론, HN 댓글도 같이 보셔야 합니다. "Zitron은 2년째 붕괴를 예언하며 틀려온 선동가다 vs 타이밍은 틀려도 경제성 지적은 옳다", "생산성은 가치가 아니다" 같은 격론이 오가며, AI 거품론을 둘러싼 양쪽 논리를 한자리에서 볼 수 있습니다.

위에서 소개한 "LLM이 내 커리어를 잠식한다"는 비관론과 정반대 편에 선, 데이터 기반의 차분한 반론입니다. Block,Snap,Intuit의 'AI 해고'가 사실은 재무 압박을 가린 "AI washing" 에 가깝다고 얘기하는데요. 핵심 논지는 소프트웨어 개발이 결정-실행-전달의 샌드위치이고 AI는 가운데 '실행'만 압축할 뿐, 무엇을 만들지 정하고 결과를 책임지는 양 끝은 자동화에 강하게 저항한다는 것입니다. “코딩”은 크게 바뀌고 있지만, 그래서 오히려 소프트웨어 엔지니어링이 무엇인지를 더 정확히 구분해야 하는 시점이라는 생각이 듭니다.

앞서 소개한 '루프 엔지니어링' 개념을 신형 Fable 5로 실제 돌려본 검증 글입니다. 핵심 기법은 두 가지로, 평가 기준(rubric)을 환경에 주입해 모델이 실행→피드백→자가 수정을 목표 달성까지 반복하게 하는 self-correction loop, 그리고 세션을 가로지르는 memory입니다. 흥미로운 건 구체적인 수치 비교인데, ML 엔지니어링 과제에서 Fable 5가 Opus 4.7보다 학습 파이프라인을 약 6배 더 개선했고, 메모리 활용에서도 Opus가 검증 커버리지 17%에서 멈춘 반면 Fable은 73%까지 도달해 배운 내용을 일반 규칙으로 distill하는 단계까지 갔다는 점입니다. 에이전트 사용법이 점점 “대화”보다 “실험 환경 설계”에 가까워지고 있다는 느낌이 듭니다.

JSON을 다룰 때 jq가 하던 일을 Markdown에 그대로 옮겨온 CLI 도구입니다. LLM 워크플로우에서 Markdown은 거의 기본 입출력 포맷처럼 쓰이는데, 정작 이를 구조적으로 쿼리하고 변환하는 도구는 부족했죠. 헤딩, 코드 블록, 링크, 테이블 셀을 셀렉터로 뽑고, Excel·Word·PDF를 Markdown으로 변환한 뒤 Unix 파이프처럼 이어붙일 수 있다는 점이 좋습니다.

마우스에 손을 떼지 않고 macOS를 키보드만으로 조작하게 해주는 도구입니다. 화면의 UI 요소를 인덱싱해 명령 팔레트로 띄우고, "ok"를 입력하면 OK 버튼으로 바로 가는 식으로 동작합니다. 단축키를 못 외워도 메뉴 항목을 퍼지 검색으로 찾아주고, "Delete"를 "remove·clear·destroy"로도 매칭하는 동의어 지원이 실용적입니다. Safari·Chrome은 물론 VS Code·Signal 같은 Electron 앱도 폭넓게 지원하고요. 다만 댓글에는 한글 입력기와 충돌해 다운그레이드해 쓴다는 후기, 더 완성도 높다는 평의 대안 Homerow를 추천하는 목소리도 있으니 함께 참고하세요.

Anthropic이 Opus 위에 Mythos급이라는 새 모델 티어를 올렸습니다. 같은 모델을 안전장치 유무로 나눠 일반용은 Fable 5, 안전장치를 일부 푼 건 Mythos 5로 부르는 구성인데요. Stripe의 5천만 줄 Ruby 코드베이스 마이그레이션을 하루 만에 해냈다거나, 단백질 설계를 10배 가속했다는 성과가 눈길을 끕니다. 이제는 모델 경쟁의 축이 “잘 대답하기”에서 오래 일하기로 옮겨가는 느낌이에요. 다만 댓글에서도 2배의 토큰 소모 나 과도한 가드레일 이야기가 많이 나오는데, 앞으로 프런티어 모델은 성능만큼이나 비용·제한·폴백 경험이 실제 평가를 좌우할 것 같습니다.

와튼 스쿨 교수인 Ethan Mollick의 사용기로 Mythos급 모델이 주는 묘한 감각을 잘 보여줍니다. 핵심은 성능 수치보다 인간 역할의 변화인데요. Fable에게 등시선 지도나 복잡한 연구 도구를 맡기면 모델이 스스로 더 저렴한 Sonnet 여러 개를 띄워 조사·코딩·검증을 분담시키고, 9시간 30분간 자율 작업해 결과만 돌려준다는 거죠. Mollick은 이를 두고 사용자가 직접 주문을 외우는 '마법사'에서, 의뢰하고 결과만 판정하는 '후원자(patron)'로 바뀌었다고 표현합니다. AI가 강력해질수록 생산성뿐 아니라 통제감의 상실도 같이 커진다는 점에서 읽어볼 만합니다. 메인에서 말씀드린 관리자 느낌이 더욱 강해지는 것 같아요.

출시 며칠 만에 반전이 터졌습니다. 미국 정부가 수출통제를 이유로 모든 외국인을 대상으로, 해외 고객은 물론 미국 내 외국인, 심지어 Anthropic의 외국인 직원까지(얼마전 입사한 Karpathy도 미국인이 아니라 차단 대상입니다) 접근을 막으라 지시했고, Anthropic은 규정 위반을 피하려 두 모델을 전 고객 대상으로 즉시 비활성화했습니다. 최첨단 AI 모델이 반도체처럼 전략기술 수출통제 대상으로 취급되기 시작했다는 신호인데요. 흥미롭게도 커뮤니티 반응은 냉소적입니다. "Anthropic의 공포 마케팅이 부른 업보다", "IPO를 앞두고 모델을 안 팔아버리면 가드레일 검증도 안 되니 오히려 유리하다", 그리고 무엇보다 "소버린 AI의 중요성을 새삼 체감한다" 는 목소리가 두드러집니다.

위 화려한 프런티어 모델 경쟁과 정반대편의 현실을 적나라하게 보여주는 글입니다. 만성 자금난으로 직원 보너스와 핵심 라이선스는 잘려나가는데, AI 컨설턴트·워크숍·구독 비용만은 즉시 승인되는 모순을 겪은 직장인의 기록인데요. 수백 명이 매달린 전사 LLM 프로젝트가 단 하나도 성공하지 못했고, 시연이라고 나온 게 "봇에게 기분 묻기", "한눈에 보이는 점심 메뉴를 굳이 업로드해 요약시키기", IT 책임자가 "의심스러운 첨부파일을 노트북에 저장해 ChatGPT에 올려 확인하라"고 권하는 수준이었다는 대목이 압권입니다.

Postman/Insomnia 같은 GUI 도구에 지친 개발자를 위한 터미널 기반 HTTP/REST 클라이언트입니다. 요청을 YAML 파일에 Recipe 형태로 정의해두니 Git으로 버전 관리하고 팀과 공유하기 좋고, TUI·CLI·Python 패키지 세 형태로 쓸 수 있는 점이 실용적입니다. Insomnia 등에서 import도 되고, 다른 요청·파일·셸 명령으로 요청을 동적으로 조립하거나 JSONPath로 응답을 파고드는 기능도 갖췄습니다. 무엇보다 README에 "영원히 무료, 절대 enshittification(서비스 악화)하지 않는다" 를 원칙으로 못 박은 점도 마음에 듭니다.

창과 탭이라는 익숙한 틀 대신, 무한 캔버스 위에 에디터·터미널·브라우저·문서·AI 에이전트를 자유롭게 펼쳐 배치하는 데스크톱 IDE입니다. 패널을 띄우거나 도킹하고, 무한 줌·팬으로 작업 공간을 넘나들며, 폴더를 다시 열면 레이아웃이 통째로 복원됩니다. Monaco 에디터와 xterm.js 터미널, Git 패널, 문서 뷰어, 인앱 코딩 에이전트까지 넣어 “코딩용 FigJam”이나 “마이너리티 리포트 IDE” 같은 느낌을 줍니다. 특히 요즘 에이전트 작업은 코드 하나만 보는 게 아니라 로그, 문서, 브라우저, 여러 작업 세션을 동시에 펼쳐야 해서 이런 공간형 작업 환경이 다시 주목받는 것 같습니다

TypeScript를 JavaScript로 트랜스파일한 뒤 V8이나 Bun, Deno 위에서 돌리는 기존 방식을 벗어나, 런타임을 통째로 걷어내는 방향으로 뒤집는 Rust 기반 컴파일러입니다. SWC로 파싱하고 LLVM으로 곧장 머신 코드를 뽑아, 하나의 코드베이스로 macOS·iOS·Android·Linux·Windows 바이너리를 만들고 콜드 스타트도 0ms에 가깝습니다. AssemblyScript처럼 'TS 비슷한 별도 언어'가 아니라 온전한 TypeScript 생태계를 지향한다는 점이 차별점이고요. 다만 동적 JS 특성을 제한해야 하고, Node.js 생태계 호환성도 아직 알파 단계인데다, 메모리 안전성과 유지보수가 가능한가에 대한 우려도 있긴한데요. 웹 생태계 언어가 네이티브 앱과 시스템 영역으로 확장되는 흐름을 보는 재미가 있습니다.

AI가 코드·문서·리뷰를 쏟아내면서 생긴 새로운 협업 예절 문제를 짚는 글입니다. 핵심 원칙은 제목 그대로 "인간의 주의를 요청하려면 인간의 노력을 보여라"인데요. 동료가 "읽어보진 않았지만 정확하진 않을 수 있다"며 AI 비평 문서를 던지는 순간, 자신에게도 가치 없던 읽기 부담을 그대로 떠넘기는 셈이 된다고 지적합니다. 특히 AI 생성 PR을 쏟아내고 리뷰는 팀에 떠넘기는 사례에 대한 HN 댓글들이 생생한데, 앞으로 팀 생산성의 병목은 코드 생성보다 AI 출력물을 어떻게 검토 가능한 형태로 전달하느냐가 될 것 같습니다.

Apple이 macOS에서 Linux 컨테이너를 더 네이티브하게 다루기 위한 Container Machine 기능을 추가했습니다. 기존 컨테이너처럼 앱 하나를 띄우는 게 아니라, 홈 디렉터리와 저장소가 자동 마운트된 영속적인 Linux 개발 환경을 만들 수 있다는 점에서 사실상 “맥용 WSL2”에 가깝게 보입니다. systemd가 들어간 이미지에서 PostgreSQL 같은 서비스를 직접 띄우고, macOS의 에디터·브라우저·프로파일러는 같은 파일을 그대로 보는 흐름이 매력적입니다. OrbStack, Lima, Colima와 어떻게 비교될지가 관건이겠지만, Apple Silicon Mac에서 리눅스 개발 환경을 쓰는 방식이 점점 더 공식화되는 느낌입니다.

창업자가 좌절했을 때 흔히 “아이디어가 나쁘다”거나 “내가 부족하다”로 바로 해석하지만, 이 글은 먼저 신호와 노이즈를 구분하라고 말합니다. 좌절의 원인을 시장·팀·아이디어로 나눠 진단해야 하는데, 차가운 시장은 창업자에 대한 판결이 아니라 나머지 모든 요소의 기준선을 높이는 조건이라는 설명이 좋았습니다. 특히 좋은 팀을 단순 스킬 조합이 아니라 고유 경험·실제 관계·내부자 우위를 가진 팀으로 보는 부분은 투자 유치를 고민하는 창업자에게 현실적인 기준을 줍니다. 결국 “계속할까, 그만둘까”의 답은 감정이 아니라, 이 아이디어가 내 시간과 돈과 사회적 자본을 쓸 만큼 무엇을 증명했는가에서 나와야 한다는 이야기입니다.

AI로 웹 앱을 뚝딱 만드는 것이 더 이상 해커톤에서 큰 차별점이 아니게 되자, 저자는 이제 하드웨어 해커톤의 시대가 다시 올 것이라고 말합니다. 48시간 동안 오래된 회전식 전화기에 Raspberry Pi를 붙이고, AI 에이전트가 Spotify 재생목록을 만들어 통화처럼 응답하는 데모를 만들었는데, 흥미로운 건 참가자 둘 다 주말 내내 코드 한 줄도 직접 보지 않았다는 점입니다. 코드 작성이 쉬워질수록 해커톤의 재미는 다시 물리 세계와 이상한 인터페이스를 엮는 쪽으로 이동할 수 있다는 진단이 설득력 있습니다.

AI를 도입하자는 이야기와 AI로 직원을 대체하자는 이야기는 완전히 다르다는 점을 강하게 짚는 글입니다. 특히 CEO들이 Claude Code 같은 도구로 데모 하나를 만들어보고 “이제 인력이 덜 필요하다”고 판단하는 순간, 작동하는 것과 대규모로 안전하게 운영되는 것의 차이를 놓치게 된다는 비판이 좋았습니다. 보안, 법규 준수, 접근성, 운영 환경 배포처럼 눈에 잘 안 보이는 마지막 10~20개의 작업이야말로 숙련된 사람들이 필요한 이유라는 거죠. 토큰을 많이 쓰게 부추기는 '토큰 리더보드' 를 가장 어리석은 도입 방식으로 꼽는 대목, 그리고 강제로 떠밀린 사용자는 결코 도구를 잘 다루지 못한다는 통찰이 핵심입니다.

AI 이후 개인 개발자들이 무엇을 만들고 있는지 묻는 Ask HN인데, 여기서 보이는 흐름은 거창한 SaaS보다 자기 문제에 딱 맞는 작은 도구입니다. 음악·오디오 실험, 홈 자동화, 미디어 변환, 건강 추적, 개발 워크플로우 자동화처럼 예전에는 “사기엔 애매하고 만들기엔 귀찮았던” 것들이 이제 개인용 소프트웨어로 바뀌고 있습니다. 특히 셰어웨어나 작은 유틸리티가 채우던 영역을 각자가 AI와 함께 직접 대체하기 시작했다는 점이 흥미롭습니다. 앱 개발자라면 어떤 걸 대상으로 삼아야 할지 고민할 부분이기도 하고요.

구글이 AI Plus 가격을 월 7.99달러에서 4.99달러로 내리고 저장 용량을 400GB로 늘렸는데요. AI 구독 경쟁이 점점 개발자보다 일상 업무 사용자를 겨냥하면서, 생활형 번들 경쟁으로 내려오고 있는것 같아요.

OpenAI가 Codex에 월 1회 직접 쓸 수 있는 레이트 리밋 리셋을 정식 기능으로 넣고, 친구 추천으로 가입을 유도하면 양쪽에 리셋을 1회씩 더 주는 referral까지 붙였습니다. 그간 비공식 공지로 이뤄지던 리셋(커뮤니티에서 담당자 이름을 따 'Tibo Button' 이라 부르던)을 아예 제품화한 셈인데요. 이건 가격 인하와는 다른 방향의 락인 전략이네요. 토큰 사용량 때문에 욕먹는 클로드와는 또 다른 방향이라서 재미있습니다.

Apple의 폴더블 루머를 단순 하드웨어 소문이 아니라, WWDC 세션과 iOS 27 베타 문자열, 리사이징 도구의 변화를 엮어 읽은 분석입니다. foldState, angleDegrees, 내장 디스플레이 개수 같은 흔적보다 더 중요한 건, Apple이 개발자들에게 고정된 화면 크기 대신 동적인 화면비에 적응하는 앱을 요구하기 시작했다는 점입니다. Android 폴더블이 7년이나 겪어온 앱 호환성 문제를 반복하지 않으려는 준비로 보이는데요. 결국 폴더블 iPhone이 나오는건 기정 사실인 것 같아요.