#Yobine

#SpringDotNET + #NHibernate: .NET in 2026

matrim — Sat, 31 Jan 2026 16:12:19 +0900

AI 툴로 편집한 Spring.Net + NHibernate 학습 가이드를 만들어봤습니다. 레거시 시스템을 분석하고 유지보수 및 추후 개발을 하기 위해 완전히 동일한 형태는 아니지만, .Net 쪽에서 당시 Spring 형태로 만들려고 했던 Spring.Net 과 Nhibernate 의 이해도를 높이기 위해 작성하였습니다. 아직 가이드 데로 코딩까지는 안해봤지만, 앞으로 내용을 검토해 가며, 업데이트 하려고 합니다.

[소개영상]

당신의 .NET 엔터프라이즈 개발 여정을 위한 완벽한 가이드

.NET 생태계에서 Spring.NET과 NHibernate는 강력한 엔터프라이즈 애플리케이션을 구축하는 데 필수적인 프레임워크입니다. 하지만 아쉽게도 이 두 기술을 효과적으로 조합하여 실무에 적용하는 방법에 대한 양질의 한글 자료는 부족한 것이 현실입니다.

여기, 바로 그 갈증을 해소해 줄 프로젝트를 소개합니다! "Spring.NET + NHibernate 완벽 학습 가이드"는 기초부터 고급까지, 실무에 필요한 모든 지식을 체계적이고 단계적으로 안내하는 종합 튜토리얼 시리즈입니다.

Spring.Net 의 기본 개념

왜 이 가이드를 선택해야 할까요?

한글 자료의 갈증 해소: Spring.NET과 NHibernate에 대한 깊이 있는 한글 학습 자료를 찾기 어려웠던 분들을 위해 제작되었습니다.
실전 프로젝트 중심: 단순히 이론만 나열하는 것이 아니라, 게시판, 사용자 관리, 쇼핑몰 시스템과 같은 실제 프로젝트를 직접 구축하며 학습합니다.
체계적인 단계별 학습: 00번부터 19번까지, 총 20개의 튜토리얼을 순서대로 따라가다 보면 어느새 전문가 수준의 지식을 갖추게 될 것입니다.
최신 모범 사례 반영: 의존성 주입(DI) 일관성, Spring.NET 기반의 Unit of Work 패턴, 선언적 트랜잭션, NHibernate 필터 기반 Soft Delete, 이벤트 리스너 기반 Audit Trail 등 현대적인 아키텍처 및 디자인 패턴을 적용했습니다.
완벽한 예제 코드: 각 튜토리얼마다 동작하는 완전한 예제 코드가 제공되어, 개념을 즉시 실습하고 확인할 수 있습니다.

이 가이드를 통해 무엇을 배울 수 있나요?

Spring.NET IoC/DI/AOP: 제어의 역전, 의존성 주입, 관점 지향 프로그래밍의 핵심 개념과 실전 적용.
NHibernate ORM: 객체-관계 매핑의 기본부터 HQL, LINQ, Criteria API, Stored Procedure 활용 고급 쿼리까지.
탄탄한 계층형 아키텍처: Domain, Data, Service, Web 계층을 명확히 분리하고 통합하는 방법.
RESTful Web API 개발: 기존 MVC 프로젝트에 Web API를 통합하여 모바일/SPA 클라이언트와 연동하는 방법.
고급 디자인 패턴: Repository, Spring.NET 컨텍스트 기반의 Unit of Work, Specification, Soft Delete, Audit Trail 등 실무에서 유용한 패턴들을 직접 구현하며 체득.
트랜잭션 관리: ACID 속성, 격리 수준, 선언적 트랜잭션을 통한 데이터 일관성 및 동시성 문제 해결.
성능 최적화 및 보안: 캐싱(2차 캐시), Eager/Lazy Loading, SQL Injection, XSS, CSRF 방지, 비밀번호 해싱 등.

‍ 어떤 분들에게 추천하나요?

.NET Framework 기반의 엔터프라이즈 애플리케이션 개발에 관심 있는 개발자.
Spring.NET 또는 NHibernate를 체계적으로 배우고 실무에 적용하고 싶은 분.
객체지향 설계 원칙과 최신 아키텍처 패턴을 .NET 환경에서 적용하고 싶은 분.
Java Spring Framework 경험이 있어 .NET 환경으로 전환하려는 분.
레거시 .NET 프로젝트의 유지보수 또는 현대화 방안을 모색하는 분.

지금 바로 학습을 시작하세요!

더 이상 흩어진 정보를 찾아 헤매지 마세요. "Spring.NET + NHibernate 완벽 학습 가이드"는 당신의 .NET 엔터프라이즈 개발 역량을 한 단계 끌어올릴 최고의 파트너가 될 것입니다.

지금 바로 프로젝트를 확인하고, 당신의 .NET 개발 여정을 시작해 보세요!

➡️ Spring.NET + NHibernate 완벽 학습 가이드 프로젝트 방문하기

Happy Learning!
Made with ❤️ for .NET Developers

더 위쳐 3 DLC는 2026년 5월에 출시 예정입니다.

matrim — Mon, 29 Dec 2025 14:49:37 +0900

최근 인터넷 상에서 보이는 더 위처3 의 새로운 dlc 관련 내용을 폴란드어에서 번역해서 공유합니다. 2025년 12월 16일자 소식입니다.

[출처: https://strefainwestorow.pl/analizy/noblesecurities-cdprojekt-wiedzmin-dlc-orion-cyberpunk DeepL 로 번역되었습니다.]

노블 증권의 애널리스트에 따르면, ‘위쳐 3’ 확장팩 출시 일정은 2026년 5월로 예정되어 있으며, CD PROJEKT 주식 매수를 권고하고 있다.
노블 증권의 애널리스트 마테우시 크르자노프스키는 최근 보고서에서 CD 프로젝트의 주요 프로젝트 일정과 예산을 업데이트했다. 그는 2026년 5월 ‘위쳐 3’ 유료 확장팩 출시와 2027년 4분기 ‘위쳐 4’ 출시를 예상하며, 삼부작 전체의 제작 및 마케팅 비용이 크게 증가할 것으로 전망했다. 이후에는 멀티플레이어 요소가 포함된 사이버펑크 게임 ‘오리온(Orion)'이 출시될 예정이며, '시리우스(Sirius)'와 '카니스 마요리스(Canis Majoris)’ 프로젝트도 재편될 전망이다. 이 모든 것은 'GTA VI'와의 시장 경쟁 속에서 진행될 것이다.
노블 증권의 이 보고서는 12월 16일 공개되었으며, 이는 투자자 포털 '스트레파 인베스토르(Strefa Inwestorów)'가 마테우시 크르자노프스키와의 인터뷰를 게재한 직후였다. 해당 인터뷰에서 그는 자신의 예측에 대한 세부 사항 일부를 공개한 바 있다. 그는 특히 CD 프로젝트의 미발표 프로젝트 중 하나가 ‘위쳐 3'의 DLC일 것이라고 제안했는데, 이는 이전 3부작의 마지막 부분과 새 시리즈의 시작을 연결하는 가교 역할을 하며, 동시에 '위쳐 4’ 캠페인의 출시와 맞물릴 것이라고 설명했다.

2026년 5월 ‘더 위쳐 3’ 유료 확장팩 출시 및 ‘W4’ 마케팅 시작.
노블 증권의 한 애널리스트는 내년 중반 ‘더 위쳐 4’ 출시가 주요 초점이 될 것으로 전망한다.
보고서는 “2026년 5월 '위쳐 3'의 유료 확장팩(DLC) 추가 출시를 예상한다. 내년 1,100만 장 판매(개당 30달러)를 전망하며, 제작 예산은 5,200만 폴란드즈워티(PLN)로 추정된다. 이번 출시가 '위쳐 4'의 본격적인 마케팅 캠페인을 시작할 것”이라고 밝혔다.
해당 애널리스트는 내년 출시 예정인 소규모 비공개 프로젝트에 대해서도 추정치를 제시했다.
보고서는 “내년에 공개될 수 있는 기타 비공개 프로젝트의 예산을 2,800만 폴란드 즐로티로 추정하며, 내년 잠재적 매출 수익은 6,100만 폴란드 즐로티로 예상한다”고 덧붙였다.

위쳐 4는 2027년 말 출시 예정이며, 3부작 가격은 인상될 전망이다.
회사 경영진이 위쳐 4가 2027년 이전에는 출시되지 않을 것이라고 발표한 이후, 노블 증권은 제작 주기 추정치를 1년 연장하여 이제 게임이 2027년 4분기에 출시될 것으로 예상하고 있습니다.
"현재 개발 비용의 연장 및 구조로 인해 게임 예산 추정치를 14억 PLN(마케팅 비용도 동일 금액)으로 상향 조정하게 되었습니다. 그러나 후속작들이 W4 기술을 기반으로 할 예정임을 고려할 때, 3부작 전체 예산은 21억 PLN에서 32억 PLN으로 증가했습니다. 또한 출시 일정 집중(경영진은 6년 내 새 3부작 전체 출시를 원함)과 브랜드 인지도 상승으로 인한 마케팅 캠페인 시너지 효과가 발생할 수 있으며, 이는 CP77 비용 기반 모델 대비 판매 비용 절감으로 이어질 수 있습니다"라고 보고서는 설명합니다.

오리온 멀티플레이어 버전 – CP77 10주년 기념 첫 공개.
사이버펑크 후속작과 관련해 노블 시큐리티스는 스튜디오의 두 번째 핵심 프랜차이즈 프로젝트를 담당하는 팀이 현재 135명으로 구성되어 있으며, 향후 2년 내 규모가 두 배로 확대될 것이라고 밝혔습니다.
“멀티플레이어 모드를 제작에 통합하려는 의지로 인해, 벤치마크 W4 작업 진척 상태를 넘어 제작 기간을 연장하게 되었습니다. 그 결과 예산은 15억 PLN으로 증가했으며, 2030년 4분기(CP77 10주년) 출시를 예상합니다”라고 보고서는 덧붙였습니다... 중략...

#Spec #Driven #Development 란? ( #명세기반개발 )

matrim — Mon, 22 Dec 2025 11:37:32 +0900

I. 들어가며: '바이브 코딩'의 시대와 그 한계

1. AI 코딩 시대의 도래

AI 코딩 도구의 등장으로 소프트웨어 개발의 문턱이 극적으로 낮아졌습니다. 이제 누구나 간단한 아이디어만으로도 빠르게 애플리케이션을 만들 수 있는 시대가 열렸습니다. 이러한 현상 속에서 '바이브 코딩(vibe-coding)'이라는 새로운 용어가 등장했습니다. 이는 단순한 아이디어 에 의존해 코드를 짜는 것처럼, 명확한 계획 없이 즉흥적으로 AI와 상호작용하며 개발하는 방식을 의미합니다.

https://youtu.be/Ilyc4Ss0tsc

2. '바이브 코딩'의 정의 및 문제점 분석

바이브 코딩이란 "트윗 길이의 짧은 문장으로 아이디어를 설명하고, AI가 코드를 작성하게 한 뒤, 문제가 생기면 또 다른 지시를 내려 고치는 방식"으로 정의할 수 있습니다. 실무에서 우리 모두는, 저를 포함해서, 명확한 계획 없이 일단 시작하고 보자는 유혹에 빠지곤 합니다. 바로 이 지점에서 프로젝트가 길을 잃기 시작합니다. 이 방식은 초기 프로토타입을 빠르게 만드는 데에는 효과적이지만, 두 가지 핵심적인 문제점을 안고 있습니다.

• 방향성 상실: 긴 슬랙(Slack) 스레드에서 대화가 길어질수록 원래 논점에서 벗어나는 경험을 해본 적이 있을 겁니다. 바이브 코딩도 이와 비슷합니다. 명확한 목표 없이 계속해서 AI에게 프롬프트를 수정하며 지시하다 보면, 처음 의도했던 것과 전혀 다른 결과물이 만들어지기 쉽습니다. 개발 과정이 중심을 잃고 표류하게 되는 것입니다.

• 품질 저하: 바이브 코딩은 코드 품질, 아키텍처, API 패턴, 보안 표준, 장기적인 유지보수성 등 프로덕션급 소프트웨어의 핵심 요소들을 간과하기 쉽습니다. AI는 주어진 프롬프트에만 의존하기 때문에, 전체적인 구조나 장기적인 유지보수를 고려한 코드를 생성하기 어렵습니다. 결국 초기에는 빠르게 결과물을 얻는 것처럼 보이지만, 숨겨진 버그와 기술 부채가 쌓여 나중에 더 많은 수정 작업을 초래하게 됩니다.

3. 스펙 주도 개발(SDD) 소개

이러한 문제들에 대한 해결책으로 **스펙 주도 개발(Spec-Driven Development, SDD)**이 주목받고 있습니다. SDD는 "나중에 시간을 절약해주는 잠시 멈춤"이라는 개념으로 설명할 수 있습니다. 무작정 코딩을 시작하는 대신, 먼저 만들고자 하는 소프트웨어의 기능, 요구사항, 제약 조건 등을 명확하게 정의한 '명세서(specification)' 즉, 설계도를 만드는 체계적인 접근법입니다.

이 설계도는 개발 과정에서 인간과 AI 모두가 따라야 할 명확한 '북극성'이 되어, 방향을 잃지 않고 품질 높은 소프트웨어를 만들 수 있도록 돕습니다.

그렇다면 바이브 코딩과 스펙 주도 개발은 구체적으로 어떤 차이가 있을까요? 다음 섹션에서 두 가지 접근법을 한눈에 비교해 보겠습니다.

II. 한눈에 비교하기: 스펙 주도 개발(SDD) vs. 바이브 코딩

스펙 주도 개발(SDD)과 바이브 코딩의 핵심적인 차이점을 아래 표를 통해 명확히 비교할 수 있습니다.

기준	바이브 코딩	스펙 주도 개발(SDD)
시작점	모호한 프롬프트	명확하고 구조화된 명세서
프로세스	반복적인 프롬프트 수정과 코드 생성의 순환	명세 → 계획 → 작업 → 구현의 체계적 단계
개발자의 역할	AI에게 지시하는 프롬프트 엔지니어	AI와 협력하는 시스템 설계자 및 검토자
결과물	빠른 프로토타입, 숨겨진 버그와 기술 부채 발생 가능성	신뢰성 높은 고품질 코드, 유지보수의 용이성
핵심 비유	끝없는 슬랙 스레드	모두가 공유하는 청사진(Source of Truth)

이처럼 명확한 차이를 보이는 스펙 주도 개발이 왜 더 신뢰할 수 있는 접근 방식인지, 그 구체적인 장점들을 자세히 살펴보겠습니다.

III. 왜 스펙 주도 개발(SDD)을 사용해야 할까?

소프트웨어 개발을 처음 배우는 학생의 입장에서 스펙 주도 개발(SDD)은 복잡한 프로젝트를 성공적으로 이끌어갈 수 있는 강력한 무기가 됩니다. SDD가 제공하는 핵심 이점은 다음과 같습니다.

1. 명확한 목표 설정 이는 앞서 언급한 '방향성 상실' 문제를 정면으로 해결합니다. 잘 정의된 명세서는 끝없는 슬랙 스레드처럼 표류하는 대신, 프로젝트의 모든 참여자가 따라야 할 명확한 등대가 되어줍니다. 이를 통해 "우리가 무엇을 만들고 있었지?"라는 개발 과정의 혼란을 방지하고, 프로젝트에 참여하는 인간과 AI 모두가 처음부터 끝까지 같은 목표를 향해 나아가게 합니다.

2. 품질 높은 결과물 이는 AI가 추측에 의존해 코드를 생성하며 발생하는 '품질 저하' 문제를 근본적으로 해결합니다. 명확한 명세서가 있으면 AI는 주어진 설계도에 따라 코드를 생성하기 때문에 버그가 적고, 구조적으로 더 안정적이며 일관성 있는 코드를 만들 수 있습니다. 이는 단순히 '작동하는' 코드를 넘어, 장기적으로 유지보수하기 좋은 '잘 만들어진' 코드를 얻게 됨을 의미합니다.

3. 진정한 AI 협업 파트너 이는 개발자의 역할을 단순한 '프롬프트 엔지니어'에서 벗어나게 합니다. SDD를 통해 AI는 단순히 명령을 수행하는 코드 생성 도구를 넘어, 개발자의 의도를 깊이 이해하고 협력하는 진정한 '파트너'가 될 수 있습니다. 명세서는 개발자의 생각을 AI에게 전달하는 가장 정확한 언어이며, 이 명확한 소통을 바탕으로 AI는 잠재력을 최대한 발휘하여 개발자를 도울 수 있습니다.

이러한 개념적 장점들이 실제 개발 과정에서는 어떻게 구체화되는지, 구인구직 앱 개발 예시를 통해 알아보겠습니다.

IV. 실전 예제: 구인구직 앱 개발로 배우는 SDD 4단계

예제 소개

여기서는 간단한 '구인구직 앱(job seekers app)' 개발 사례를 통해 SDD의 4단계 프로세스를 살펴보겠습니다. 이 앱은 사용자가 면접 질문에 음성으로 답변하면, 이를 녹음하고 분석하여 구직자에게 피드백을 제공하는 인터뷰 준비용 애플리케이션입니다. 개발자의 재치있는 '엘리베이터 피치'에 따르면, 이 앱은 구직자들이 실제 면접처럼 질문에 답하고, 그 결과를 분석하여 정량화된 점수와 피드백을 제공함으로써 면접 기술을 향상시키는 것을 목표로 합니다.

SDD 4단계 설명

1단계: 명세(Specification) - '무엇을' 만들지 정의하기

첫 단계로, 우리는 앱의 Figma 디자인을 AI에게 전달했습니다. AI는 즉시 로그인, 프로필 관리를 포함한 방대한 요구사항 목록을 생성해냈죠. 하지만 숙련된 개발자로서 우리는 MVP(최소 기능 제품)에 이 모든 것이 필요하지 않다는 것을 압니다. 그래서 우리는 직접 개입하여 핵심 기능인 '인터뷰 연습'에만 집중하도록 불필요한 기능들을 덜어내는 '범위 조율' 역할을 수행했습니다. 이것이 바로 인간 개발자의 전략적 판단이 빛을 발하는 순간입니다. 이 단계는 기술적 구현이 아닌, 앱의 기능과 목표, 즉 '무엇(WHAT)' 을 정의하는 데 집중합니다.

2단계: 계획(Plan) - '어떻게' 만들지 설계하기

명세서가 확정되자, 우리는 AI에게 '어떻게(HOW)' 이 기능을 구현할지에 대한 기술 설계 문서를 요청했습니다. AI는 전체적인 아키텍처와 StartScreen, QuestionScreen 같은 필요한 화면 컴포넌트 목록을 제안했습니다. 하지만 여기서도 인간의 통찰력이 필요했습니다. AI가 만든 초기 설계에는 '사용자 음성을 텍스트로 변환하는 기능'이나 '분석을 위해 Claude AI SDK를 사용'하는 것과 같은 핵심 기술 계획이 빠져 있었습니다. 우리는 이 구체적인 기술 계획을 직접 추가하여 설계를 보완하고 완성했습니다.

3단계: 작업(Task) - 실행 계획을 잘게 쪼개기

잘 만들어진 기술 설계도를 바탕으로, AI는 코딩에 필요한 모든 단계를 체크리스트 형태의 '작업 목록'으로 만들었습니다. 하지만 AI가 제안한 작업 순서는 최적이 아니었습니다. 그래서 우리는 사용자가 즉시 눈으로 확인할 수 있는 UI 관련 작업을 초기 단계에 배치하도록 순서를 전략적으로 재조정했습니다. 이 작은 변화를 통해 우리는 더 빠르게 테스트 가능한 MVP를 만들어 피드백을 받을 수 있게 되었고, 프로젝트의 방향성을 조기에 검증할 수 있었습니다.

4단계: 구현(Implementation) - AI가 실제로 코드를 작성하기

마지막으로, 우리는 AI에게 잘 정리된 작업 목록에 따라 코드를 작성하도록 지시했습니다. AI가 파일 생성, 라이브러리 설치, 코드 작성을 자동으로 수행하는 동안, 우리는 감독관의 역할을 수행했습니다. 단순히 지켜보는 것을 넘어, 각 단계의 결과물이 우리가 처음 정의했던 명세서와 계획에 정확히 부합하는지 전체 과정을 감독하고 검토하며 최종 결과물의 품질을 보장했습니다.

이처럼 SDD는 아이디어를 체계적인 단계를 거쳐 신뢰할 수 있는 소프트웨어로 만드는 전 과정을 안내합니다. 그렇다면 이러한 변화가 개발자에게는 궁극적으로 어떤 의미를 가질까요?

V. 결론: AI 시대의 개발자, 코더에서 설계자로

SDD의 핵심 가치 요약

SDD는 단순히 코딩 전에 문서를 하나 더 작성하는 관료적인 절차가 아닙니다. 수많은 프로젝트를 거치며 깨달은 것은, 이것이 AI라는 강력한 도구를 길들이고 그 잠재력을 극대화하기 위한 필수적인 **'생각의 틀(framework)'**이라는 사실입니다. 모호한 지시 대신 명확한 설계도를 제공함으로써, 우리는 AI의 예측 불가능성을 통제하고 그 잠재력을 극대화할 수 있습니다.

개발자의 역할 변화 강조

'바이브 코딩'의 즉각적인 속도가 매력적인 유혹일지라도, 견고하고 신뢰성 높은 소프트웨어로 가는 길은 결국 설계자의 규율과 명확한 청사진으로 포장됩니다. SDD가 보편화되면서 개발자의 역할은 근본적으로 변화하고 있습니다. 더 이상 키보드 앞에서 한 줄 한 줄 코드를 입력하는 '코더(Coder)'에 머무르지 않습니다.

이제 개발자는 시스템 전체의 청사진을 그리는 '설계자(Architect)', AI의 작업을 지휘하는 '지휘자(Orchestrator)', 명확한 의도를 정의하는 '명세서 저자(Spec Author)', 그리고 AI의 결과물을 검증하는 **'최종 수문장(Guardian)'**으로 진화하고 있습니다. AI 시대의 개발자는 코드를 '만드는' 사람에서, 훌륭한 코드가 '만들어지도록' 설계하고 이끄는 사람으로 거듭나게 될 것입니다.

#GTA5 on #SteamDeck

matrim — Mon, 1 Dec 2025 17:28:50 +0900

Direct X version: 11
Resolution: 1280x800
Refresh rate: 90Hz
FXAA: On
MSAA: Off
Vsync: Off
Population Density: 70%
Population Variety: 100%
Distance Scaling: 80% (Potential for 100% but needs further testing)
Texture Quality: Very High
Shader Quality: High
Shadow Quality: Normal
Reflection Quality: High
Reflection MSAA: Off
Water Quality: Very High
Particles Quality: Normal
Grass Quality: Very High
Soft Shadows: Soft
Post FX: High
Motion Blur Strength: Personal preference
Antistropic Filtering: 8-16x
Ambient Occlusion: Normal
Tesselation: Normal

Advanced Graphics:

Long Shadows: Off
High-Resolution Shadows: Off
High Detail Streaming While Flying: On
Extended Distance Scaling: Off
Frame Scaling Mode: 3/2 (1x500) - This smooths out jaggies a lot better

#MacMini #256GB + #외장 1TB 구성 #최적화 #가이드

matrim — Tue, 25 Nov 2025 16:42:42 +0900

Mac Mini의 내부 256GB SSD가 금방 차는 문제를 해결하고, iMovie와 Xcode를 외장 하드로 옮겨 용량을 확보하는 방법을 정리했습니다. 혹시 더 좋은 방법이 있으면 확인 후 업데이트 하겠습니다.

1️⃣ 외장하드 준비

외장하드 이름: MacData
포맷: APFS
권장: SSD (속도 문제 최소화)

폴더 구조

MacData/
└── iMovieLibrary/       # iMovie 보관함
└── Applications/        # 외장 앱

2️⃣ 내부 디스크 용량 확인

df -h /

용량 확인 후, 어떤 파일/폴더가 공간을 차지하는지 분석

du -sh ~/* | sort -h
du -sh ~/Library/* | sort -h
du -xh / | sort -h | tail -20  # 대용량 폴더 TOP 20 확인

3️⃣ iMovie 보관함 외장 이동

1. 외장 폴더 생성

Finder에서 외장하드 MacData 열기 → 새 폴더 iMovieLibrary 생성

2. 보관함 이동

Finder에서 ~/Movies/iMovie 보관함.imovielibrary → 외장 iMovieLibrary 드래그 앤 드롭

3. iMovie에서 연결

iMovie 실행
상단 메뉴 → File → Open Library → Other… → Locate…
외장하드 iMovieLibrary/iMovie 보관함.imovielibrary 선택
(선택) Preferences → Library Location에서 기본 보관함으로 설정

외장 하드 미연결 시 프로젝트 열기 불가
SSD 권장

4️⃣ Xcode / 개발자 캐시 정리 (추가 용량 확보)

# Xcode DerivedData 삭제
rm -rf ~/Library/Developer/Xcode/DerivedData

# 시뮬레이터 전체 삭제
rm -rf ~/Library/Developer/CoreSimulator

# 아카이브 파일 삭제
rm -rf ~/Library/Developer/Xcode/Archives

# iOS DeviceSupport 삭제
rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport

추가 20~30GB 확보 가능
안전, 재설치 가능

5️⃣ 사용자 캐시 정리

rm -rf ~/Library/Caches/*

일부 시스템 관련 캐시는 삭제 불가 (CloudKit, Music, Safari 등)
용량 차지 크지 않음 → 무시 가능

6️⃣ 내부 디스크 상태 확인

df -h /

iMovie 외장 이동 + Xcode/캐시 정리 후 예시:

Size: 228GB
Used: 10GB
Avail: 41GB
Capacity: 21%

안정적 운영 가능

7️⃣ 추가 팁

iMovie 외장 보관함 주기적 백업
Xcode 캐시 주기적 정리
외장하드 앱 사용 시 속도 고려 (SSD 권장)
내부 보관함/임시 파일 삭제로 용량 확보

✅ 결론

내부 디스크 256GB는 시스템과 필수 앱만 유지
대용량 작업(영상 편집, 앱 설치 등)은 외장 1TB에 저장
주기적 캐시 정리 및 외장 보관함 관리로 안정적 사용 가능