• 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

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에서 연결

1. iMovie 실행
2. 상단 메뉴 → File → Open Library → Other… → Locate…
3. 외장하드 iMovieLibrary/iMovie 보관함.imovielibrary 선택
4. (선택) 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에 저장
• 주기적 캐시 정리 및 외장 보관함 관리로 안정적 사용 가능

안녕하세요 다음 글은 claude-code 가 작성한 블로그 글입니다. 오전에 만든 앱을 테스트 하기 위해 준비하는 과정을 정리해서 공유해 드립니다. 

너무 오래 전에 어플을 테스트 및 등록 해 보고, 너무 오랜만에 작업하는 것이여서, 개발자 콘솔 환경도 많이 바뀌었고, 없던 기능들도 많아져서, 진행하는데에 막힘이 많았습니다. 하지만 ai 가 잘 가이드를 해줘서 내부테스트 패키지가 무사히 잘 등록이 되었습니다. 

Flutter 앱 Google Play 내부 테스트 배포 완벽 가이드

작성일: 2025-11-10
프로젝트: RentHouse (가재 Flutter 임대관리 앱)
목표: RevenueCat 구독 기능 테스트를 위한 Google Play Console 내부 테스트 배포

📌 시작하기 전에

이 글은 Flutter 앱을 Google Play Console의 내부 테스트(Internal Testing) 트랙에 처음 배포하면서 겪은 실제 문제들과 해결 과정을 기록한 것입니다. 특히 RevenueCat 구독 기능을 테스트하기 위해서는 반드시 Play Console을 통해야 하므로, 이 과정이 필수입니다.

내부 테스트 vs 프로덕션

🔐 1단계: Android 앱 서명 설정

Google Play에 앱을 업로드하려면 Release 서명이 필수입니다.

1.1. Keystore 생성

cd renthouse

keytool -genkey -v -keystore upload-keystore.jks \
  -keyalg RSA -keysize 2048 -validity 10000 -alias upload \
  -storepass YOUR_PASSWORD -keypass YOUR_PASSWORD \
  -dname "CN=Your Name, OU=Development, O=Company, L=City, ST=State, C=KR"

중요 포인트:

• ✅ validity 10000: 27년 유효 (Google Play 요구: 최소 25년)
• ⚠️ 처음에 3개월로 설정했다가 오류 발생!

  오류: 너무 일찍 만료되는 인증서로 서명한 APK

1.2. key.properties 생성

android/key.properties 파일 생성:

storePassword=YOUR_PASSWORD
keyPassword=YOUR_PASSWORD
keyAlias=upload
storeFile=../upload-keystore.jks

1.3. build.gradle.kts 수정

android/app/build.gradle.kts:

import java.util.Properties
import java.io.FileInputStream

// Keystore 속성 로드
val keystorePropertiesFile = rootProject.file("key.properties")
val keystoreProperties = Properties()
if (keystorePropertiesFile.exists()) {
    keystorePropertiesFile.inputStream().use { keystoreProperties.load(it) }
}

android {
    // ... 기존 설정

    signingConfigs {
        create("release") {
            keyAlias = keystoreProperties["keyAlias"] as String
            keyPassword = keystoreProperties["keyPassword"] as String
            storeFile = file(keystoreProperties["storeFile"] as String)
            storePassword = keystoreProperties["storePassword"] as String
        }
    }

    buildTypes {
        release {
            signingConfig = signingConfigs.getByName("release")
            isMinifyEnabled = true
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }
}

1.4. .gitignore 업데이트

절대 커밋하면 안 되는 파일들:

# Android signing keys (NEVER commit these!)
*.jks
*.keystore
/android/key.properties
upload-keystore.jks

📱 2단계: Target SDK 업데이트

Google Play는 Target SDK 35 이상을 요구합니다 (2025년 11월 기준).

2.1. build.gradle.kts 수정

android/app/build.gradle.kts:

android {
    defaultConfig {
        applicationId = "com.a88888.renthouse"
        minSdk = flutter.minSdkVersion
        targetSdk = 35  // 34 → 35로 변경 ✅
        versionCode = flutter.versionCode
        versionName = flutter.versionName
    }
}

발생했던 오류:

현재 앱이 34의 API 수준을 타겟팅하고 있지만,
API 수준 35 이상을 타겟팅해야 합니다.

📦 3단계: App Bundle (AAB) 빌드

3.1. 버전 코드 증가

pubspec.yaml:

version: 0.7.0+3
         ^^^^^  ^
         |      └─ versionCode (Play Console에서 고유해야 함)
         └──────── versionName (사용자가 보는 버전)

문제 발생:

버전 코드 2는 이미 사용되었습니다.
다른 버전 코드를 사용해 보세요.

해결:

• 이전: 0.7.0+2 ❌
• 수정: 0.7.0+3 ✅

3.2. App Bundle 빌드

cd renthouse

# Clean build (선택사항)
flutter clean

# AAB 빌드
flutter build appbundle

결과:

✓ Built build/app/outputs/bundle/release/app-release.aab (62MB)

Warning 무시 가능:

Release app bundle failed to strip debug symbols from native libraries.

→ 앱 기능에는 영향 없음, 프로덕션 배포 전에 해결 권장

🚀 4단계: Google Play Console 설정

4.1. 내부 테스트 트랙 생성

1. Google Play Console 접속
   • https://play.google.com/console
2. 앱 선택: RentHouse
3. 테스트 > 내부 테스트(Internal testing)
4. 새 버전 만들기 클릭

4.2. AAB 업로드

1. Android App Bundle 업로드
   • 파일: build/app/outputs/bundle/release/app-release.aab
   • 드래그 앤 드롭
2. 출시명 입력: "구독테스트버전" (개발자만 보임)
3. 출시 노트 작성:

   - RevenueCat 구독 기능 연동
   - Firestore 구독 동기화
   - Target SDK 35 업데이트

4. 검토 → 저장 및 출시

4.3. 테스터 추가

중요! 테스터를 추가하지 않으면 아무도 다운로드할 수 없습니다.

1. 테스터 탭 클릭
2. 이메일 목록 만들기
3. 목록 이름: "Internal Testers"
4. 이메일 추가: 본인 Gmail 주소
5. 저장
6. 트랙에 추가 (내부 테스트 트랙 선택)

4.4. 라이선스 테스터 추가 (구독 테스트용)

구독 기능을 무료로 테스트하려면 라이선스 테스터 등록 필수!

1. 설정 > 라이선스 테스트
2. 라이선스 테스터 섹션
3. 이메일 추가: 본인 Gmail
4. 라이선스 응답: LICENSED 선택
5. 저장

효과:

• ✅ 구독 구매 시 실제 결제 없음
• ✅ RevenueCat 구독 플로우 전체 테스트 가능

📲 5단계: 테스트 앱 설치

5.1. 테스트 링크 받기

1. 내부 테스트 페이지
2. 테스트 방법 섹션
3. 공유 가능한 링크 복사
   • 예: https://play.google.com/apps/internaltest/xxxxxxxx

5.2. Android 기기에서 설치

1. 테스트 링크를 모바일 브라우저에서 열기
2. 테스터가 되기 버튼 클릭
3. Google Play에서 다운로드 클릭
4. 앱 설치

⚠️ 주의: 테스터로 등록한 Gmail 계정으로 로그인된 기기여야 함!

🐛 트러블슈팅: 발생한 문제들

문제 1: 디버그 모드로 서명

오류:

디버그 모드로 서명한 APK 또는 Android App Bundle을 업로드했습니다.

원인:

• build.gradle.kts에서 signingConfig = debug 사용

해결:

• Release 서명 설정 (위 1단계 참고)

문제 2: 인증서 유효기간 부족

오류:

너무 일찍 만료되는 인증서로 서명한 APK

원인:

• Keystore 생성 시 validity 값이 너무 작음 (3개월)

해결:

# 27년 유효 인증서 생성
keytool -genkey -v -keystore upload-keystore.jks \
  -validity 10000 ...  # 10,000일 = 27.4년

확인:

keytool -list -v -keystore upload-keystore.jks -storepass YOUR_PASSWORD
# Valid from: 2025-11-10
# Valid until: 2053-03-28 ✅

문제 3: Target SDK 34

오류:

현재 앱이 34의 API 수준을 타겟팅하고 있지만,
API 수준 35 이상을 타겟팅해야 합니다.

해결:

// android/app/build.gradle.kts
targetSdk = 35  // 34 → 35

문제 4: 버전 코드 중복

오류:

버전 코드 2는 이미 사용되었습니다.

원인:

• 이전에 업로드한 AAB와 동일한 versionCode

해결:

# pubspec.yaml
version: 0.7.0+3  # +2 → +3으로 증가

참고:

• 한 번 사용한 버전 코드는 재사용 불가
• 삭제한 릴리즈의 버전 코드도 재사용 불가

문제 5: 테스터 미지정

경고:

아직 테스터가 지정되지 않았기 때문에
어떤 사용자도 이 버전을 이용할 수 없습니다.

해결:

• 위 4.3단계: 테스터 이메일 목록 생성 및 추가

📊 RevenueCat 구독 테스트 준비

내부 테스트 배포가 완료되면 RevenueCat 구독 기능을 테스트할 수 있습니다.

RevenueCat API Key 확인

lib/core/services/revenuecat_service.dart:

const apiKey = 'goog_KWVteD89709876789858765WFgLQCM';

확인 사항:

• ✅ API Key 형식: goog_xxxxx (Android)
• ✅ RevenueCat Dashboard에서 발급받은 Public Key
• ❌ Secret Key (sk_xxxxx)는 절대 앱에 포함 금지

다음 단계

1. Google Play Console > 제품 > 구독
2. 구독 상품 등록:
   • premium_monthly: 월간 ₩5,000
   • premium_yearly: 연간 ₩50,000
3. RevenueCat Dashboard > Products
   • Google Play 구독 상품 가져오기
4. Entitlement 생성: premium
5. 모바일 기기에서 구독 구매 테스트
6. Firestore에서 구독 정보 동기화 확인

✅ 체크리스트

빌드 준비

• Keystore 생성 (27년 유효)
• key.properties 설정
• build.gradle.kts 서명 설정
• .gitignore에 keystore 추가
• Target SDK 35 설정
• pubspec.yaml 버전 코드 증가

Play Console 설정

• 내부 테스트 트랙 생성
• AAB 업로드 (62MB)
• 출시 노트 작성
• 테스터 이메일 목록 생성
• 라이선스 테스터 추가
• 저장 및 출시

RevenueCat 준비

• API Key 설정 확인
• Firestore 구독 동기화 코드 구현
• Google Play 구독 상품 등록 (다음 단계)
• RevenueCat Products 가져오기 (다음 단계)
• 구독 테스트 (다음 단계)

🎯 결과

최종 빌드 정보:

파일: app-release.aab
크기: 62MB
버전: 0.7.0+3
Target SDK: 35
인증서 유효기간: 2025-11-10 ~ 2053-03-28
상태: ✅ 내부 테스트 배포 완료

배포 상태:

• ✅ Google Play Console 내부 테스트 트랙
• ✅ 테스터 지정 완료
• ✅ 라이선스 테스터 등록 완료
• ✅ 테스트 링크 발급 완료

💡 배운 점

1. 인증서 유효기간은 충분히 길게
   • 최소 25년 이상 (Google Play 요구사항)
   • 권장: 27년 (10,000일)
2. 버전 코드는 항상 증가
   • 한 번 사용한 코드는 재사용 불가
   • 삭제한 릴리즈도 마찬가지
3. Target SDK는 최신으로
   • 2025년 11월 기준: SDK 35 이상 필요
   • Google Play 요구사항은 계속 업데이트됨
4. 테스터 설정 필수
   • 내부 테스트도 테스터 지정 필요
   • 라이선스 테스터는 구독 테스트용 별도 설정
5. AAB vs APK
   • Play Console 업로드: AAB 권장
   • 직접 설치 테스트: APK
   • RevenueCat 테스트: Play Console 필수 (AAB)

📚 참고 자료

• Google Play Console 공식 문서
• Flutter 앱 서명 가이드
• RevenueCat Flutter 통합 가이드
• Android Target SDK 요구사항

🔗 관련 문서

• Firestore Database 설정 가이드
• RevenueCat 연동 체크리스트
• 구독 기능 구현 상세

2025.10.30-01. #바이브코딩 으로 앱 만들기 - 과연 가능할까?

위의 글 이어서 실제 Renthouse 프로젝트의 바이브코딩 진행 과정 과 내용을 공유합니다.

바이브코딩이 어느정도 프로토타입 개발 경험을 바탕으로 가능한 것을 알았으니, 정말 시제품을 만들고 싶었습니다. 사실 이 RentHouse 아이디어는 개인적으로도 필요하기도 해서 구상하고 있던 프로그램이기 때문에, 출시 이후에도 지속적으로 업그레이드도 할 것 같기도 하고, 어느정도 금액이 나오면 좀더 나은 서비스를 제공할 계획도 있습니다. 나만 쓰더라도 좀 편하게 사용이 안될까.. 하며 아이디어가 계속 나오더라고요.

여하튼, 프로토타입 때, Gemini-flash 가 만든 코드를 경험 했기 때문에, (물론 생각보다 만족스러웠지만, 의외로 만족스럽지 않은 부분도 많았습니다.) 이번에는, 유료이지만 Claude Code를 선택했습니다. 결론부터 말씀 드리자면, 3개월 정도 진행 하였고, 현재 출시까지 원하는 기능 중 1개 제외하고 모두 구현되어 있습니다. 

우선, 많은 개발자분들이 클로드코드가 코딩에 최적화되어 있다고 평가했기 때문입니다. 또한 이번에는 제가 중간에 개입하지 않는 것을 목표로 했습니다. 100% 바이브 코딩으로 진행 하였습니다. 음.. 그러기 위해서.. 제가 이미 잘 아는 언어 대신, 아예 모르는 언어를 선택하였습니다.

멀티플랫폼도 지원해야 한다는 점 때문에, 많은 개발자분들께서 추천하는 Flutter 를 선택하게 되었습니다. Flutter 는 이미 여러번의 버전업을 거치면서 상당히 안정화되었고, 고품질의 결과물을 낼 수 있으며, 또한 개발하기도 편리하다는 평가를 많이 접하게 되었습니다. 또한 실제로 YouTube에서도 최신 Flutter 버전이 충분히 실무에 활용 가능하다며 여러 적용 사례들도 확인할 수 있었고요.
그래서 최종적으로, 이번 프로젝트는 Flutter로 진행하기로 결정했습니다.

프로토타입을 통한 요구사항 만들기 

우선 프로토타입을 전달하여 PRD (제품 요구사항 정의서) 를 만들기로 했습니다. LLM 과 UI 가 뛰어난 ChatGPT 를 활용하였습니다.

다음은 ChatGPT 에게 전달받은 개발 검토 및 개선 제안입니다. 4-5번의 수정을 거쳐서 만들어진 내용입니다. 물론 다음과 같이 만들어진 이후, 꽤 많은 수정 작업을 거쳐서 내용에 없는 기능이 추가되었거나, 만들었지만 빠진 내용도 있습니다. 초기에 ai (ChatGPT) 가 검토한 개발 검토 보고서를 공유합니다. 

위의 내용처럼, 개발 프로세스 중, 단순한 코드 생성을 넘어, 기획 단계부터 AI가 깊숙이 관여 시켰습니다. 화면설계도 요청했었고요. 답변은 wireframe 으로 전달 받았으며, 이 wireframe 을 통해 화면 요구사항은 초기에 끝났습니다. 물론 이후 필요한 기능들이 추가되면서 조금씩 변경은 되었지만, ChatGPT 가 전달 해준 wireframe 의 화면 설계와 구현 가능한 디자인 설계도는 이후 Claude-code 와 협업 씨 많은 토큰?을 아낄 수 있었습니다.

 AI 툴들과 와 함께 구상한 설계가 구체화된 후, 본격적인 '바이브 코딩'이 시작되었습니다. 저는 해결해야 할 문제나 구현할 기능들.. 즉 '목표' / '요구사항' 을 제시했고, AI는 그 목표를 달성하기 위한 계획과 최적의 코드를 제안했습니다. 다음은 앱내 알림 서비스를 구현하면서 전달한 요구사항을 가지고 to-do 리스트를 만든 후, 제 피드백을 받고, 하나씩 진행하는 화면입니다.

위의 화면에서는, 당연히 todo 리스트는 제가 정리해서 공유한 요구사항 내용을 가지고 만든 리스트이지만, 간혹 과제를 던져주면 알아서 과제내에서 wbs 를 만들어 진행전에 저와 계획을 공유하며 리뷰/피드백을 받고 진행하였습니다. 최근 admobs 를 활용한 광고 배너를 모바일에 추가하는 작업을 진행하였는데 꽤 수월하게 진행되었습니다. 개발 완료 후, 진행 사항 내용을 보여주는 화면입니다. 토큰 때문에 오류외 피드백은 잘 안하는 편이지만, 이번만큼은 별다른 오류나 실수 없이 한번에 진행되어서 피드백을 주었습니다. -- ai 도 좋아하는 표현을 좀 적극적으로 하면 더 할텐데 말이죠. ㅋㅋ

물론 버그는 있습니다. 코딩 작업 이후엔 바로바로 빌드 테스트를 진행하였지만, 실제 화면 테스트는 어느정도 시나리오의 흐름 때문에 활용 가능한 데이터를 기다려야 하는 경우도 있었고, 가상으로 만들어 진행 하기도 했습니다.

최근 해결한 '월별 수익 보고서의 자산 필터' 문제가 좋은 예시입니다.

문제 제기 (나): "보고서의 월별 수익 화면에 자산 필터가 있는데, 특정 자산을 선택해도 금액이 바뀌지 않아. 원인을 분석하고 해결책을 제안해 줘."

이 문제를 듣고 AI는 reports_screen.dart, reports_controller.dart, reports_repository.dart 등 관련된 여러 파일을 스스로 분석했하였고, UI의 선택 값이 데이터 조회 로직까지 전달되지 않는다는 근본 원인을 정확히 찾아냈습니다. 그리고 단순히 UI 코드만 수정하는 것이 아니라, 데이터 흐름 전체를 개선하는 구조적인 해결책을 제시했습니다. 데이터베이스 쿼리부터 컨트롤러, UI까지 각 계층에서 수정해야 할 부분을 진행전에 명확히 알려주었습니다. 제안한 코드를 제가 최종 검토하고 프로젝트의 일관성을 해치지 않는지 확인한 후 적용되었습니다.

제가 방향을 제시하고, AI가 제 의도를 이해할 때까지 설명하여, 실제 개발자처럼 움직일 수 있도록 하여 원하는 결과물을 만들어 내었던 재미난 경험이었습니다.

이번 바이브크딩 프로젝트 통해 AI 툴 (ChatGPT, Gemini-CLI, Claude-Code) 들은 단순 코더가 아니었습니다. 비록 역할별로 다른 AI 툴들을 넘나들며 활용하였지만, 바이브코딩은 다음과 같은 이유로 가능했습니다.

1. 복잡하게 얽힌 코드들 속에서 문제의 근본 원인을 찾아냈습니다. (Claude-Code, Gemini-CLI)
2. 비효율적인 로직 대신, 성능과 구조를 고려한 더 나은 아키텍처를 제안했습니다. (Claude-Code, Gemini-CLI)
3. 제가 요청하면, 방금 수정한 내용에 대한 기술 문서를 Markdown 형식으로 깔끔하게 정리하여 docs 폴더에 저장해 주었습니다. (ChatGPT, Gemini-CLI, Claude-Code)

단순히 3개의 Tool 로만 진행하였지만, 결과물은 무척 만족스럽습니다. 

물론 '바이브 코딩'이 항상 순탄했던 것은 아닙니다. '요구사항'의 상세함이 결과물의 품질을 결정한다.. 입니다. 즉 "대충 만들어줘"라는 식의 모호한 요구사항은 결과물의 품질을 보장할 수 없었습니다. 초기 기획 단계에서 PRD와 와이어프레임을 상세하게 정의했던 것처럼, 풍부하고 구조화된 '요구사항'을 제공할수록 AI 파트너는 더 정확하고 뛰어난 결과물을 만들어냈습니다.

최종 결정과 책임은 인간의 몫.. 저의 몫이였습니다.: AI는 놀랍도록 정확했지만, 프로젝트의 전체적인 방향성이나 최종 사용자 경험의 미묘한 차이까지 책임져 주지는 않습니다. 제안된 코드를 비판적으로 검토하고 최종 결정을 내리는 것은 여전히 저의 가장 중요한 역할이었습니다.

이 프로젝트를 통해 얻은 가장 큰 교훈은, AI는 개발자를 대체하는 것이 아니라, 개발자의 능력을 증폭시키는 강력한 도구(Force Multiplier)라는 것입니다. AI 덕분에 저는 혼자서 기획, 분석, 개발, 문서화까지, 마치 작은 팀처럼 일할 수 있었습니다.

결론: 새로운 개발 패러다임, 바이브 코딩
'Renthouse(가제)' 프로젝트는 AI와의 협업이 더 이상 먼 미래의 이야기가 아님을 증명하고 있습니다. 개발자의 역할은 모든 코드를 한 줄 한 줄 작성하는 것에서, AI라는 강력한 파트너에게 명확한 '요구사항'을 제시하고 전체적인 품질을 책임지는 '아키텍트' 또는 '오케스트라의 지휘자'로 변화하고 있습니다.

아직 AI와의 협업을 시도해보지 않으셨다면, 여러분만의 '바이브'를 가지고 작은 프로젝트부터 시작해보시길 강력히 추천합니다. 아마 코딩하는 방식에 대한 생각이 완전히 바뀌게 될지도 모릅니다.

마지막으로, 가트너에서 발표한 10가지 2025년의 주요 기술 트랜드라는 글을 ChatGPT 를 통해 번역하여 블로그에 올린 기억이 있습니다. 이때만 해도 ChatGPT 는 기존 검색엔진보다 "말 많은 검색 툴" 로만 여겼었지요. 하지만 2025년 한해간 급격히 많은 업그레이드가 되었고, 많은 AI 툴들이 만들어져서 서비스화 되었습니다. 2025 년은 ai 의 해라고 해도 과언이 아닐것 같네요.

AI를 의사결정 에이전트로 전환 가트너는 에이전틱 AI가 향후 2~3년 내에 등장할 것으로 예상하며, 정보 요약과 같은 작업을 넘어 개인을 대신해 실제로 행동을 취하는 능력을 갖출 것으로 보고 있습니다. 사용자에게 옵션을 제시하는 대신, 허가를 받으면 사용자에게 최적의 옵션을 선택할 수 있게 될 것입니다
출처:
https://yobine.tistory.com/605
[#Yobine:티스토리]

2025 년 #가트너 (#Gartner) 에서 발표한 10가지 주요 전략 기술 트렌드 :: #Yobine

안녕하세요! 오늘은 제가 진행하고 있는 'Renthouse(가제)' 프로젝트에 대한 조금 특별한 이야기를 공유하고자 합니다. 이 프로젝트는 Flutter로 제작된 크로스플랫폼 임대 관리 애플리케이션으로, 기획부터 설계, 개발, 문서화까지 전 과정이 AI 코딩 파트너들 (Claude-code, Gemini-CLI, 그리고 ChatGPT) 과 함께 진행되고 있습니다.

아시는분들도 많겠지만, 기본적인 소프트웨어 개발 프로세스는 다음과 같습니다. 출처: DBpia

소프트웨어 개발 방법론은 요구사항 분석, 설계, 구현, 테스트, 유지보수 단계를 포함하며, 폭포수 모델, 애자일 방법론 등 다양한 접근 방식이 존재합니다.........

저는 요구사항 분석 부터, 설계, 구현 (실제 코딩), 테스트 (중 테스트 코드 작성) 부분.. 그리고 이후에 유지보수 단계까지 모두  "바이브 코딩(Vibe Coding)" 개발 방식으로 진행하기로 선택했습니다.

음..  바이브 코딩이 뭘까요? 혹시 모르시는 분들을 위해 다음 내용을 공유 합니다. (출처 : DBpia ) 

1. Vibe Coding의 특징
Vibe Coding은 자연어 처리를 통해 코드 생성을 지원하여 프로그래밍의 대중화를 목표로 합니다.
자연어 기반 코드 생성: Vibe Coding은 자연어를 통해 코드 생성을 지원함으로써 프로그래밍 입문 장벽을 낮추고 코딩의 대중화에 기여할 수 있습니다.코딩 효율성 증대: 인공지능 기술을 활용하여 코딩 작업의 효율성을 높이는 데 기여할 수 있습니다.

2. Vibe Coding의 장점
Vibe Coding은 자연어 기반 코드 생성을 통해 프로그래밍 진입 장벽을 낮추고 코딩 대중화에 기여할 수 있습니다.
프로그래밍 접근성 향상: 자연어 기반 코드 생성은 프로그래밍 입문자에게 더 쉬운 접근성을 제공합니다.

Vibe Coding은 자연어 기반 코드 생성을 통해 프로그래밍의 대중화와 효율성 증대에 기여할 수 있습니다.

위의 내용은 자연어 처리를 통한 코드 생상 내용만 나오지만, 제가 프로젝트의 전체적인 방향성을 LLM 툴을 통해 제시하면, AI가 구체적인 산출물로 만들어내는 방식으로 진행 하였고, 그 결과 또한 생각 했던 것 보다 훨씬 뛰어났기 때문에, 이 글을 통해 AI와 함께 '바이브 코딩'으로 실제 앱을 개발하는 것이 과연 가능한지.. 그리고 어떤 경험이었는지 공유해 보겠습니다.

시작: 추상적인 '아이디어' 를 구체적인 '설계'로 (요구사항 분석 및 설계)

프로젝트의 시작은 간단한 한 줄 명령이 아니었습니다. 물론 "임대 관리 업무를 디지털로 간소화한다"는 추상적인 '이이디어'에서 출발했지만, 이 아이디어를 구체화하기 위해 AI 파트너와 수많은 대화를 나누었고, 꽤 놀라운 산출물들이 전달 되었습니다.

LLM 툴은 가장 사용하기 편했고, 접근하기 좋았던 ChatGPT 를 이용했습니다. 수많은 대화가 오고갔지만, 가장 처음 받았던 답변을 공유합니다.

개발자 질문: property 를 한글로 하면 뭘까? 그리고 하나의 property 의 종류가 꽤 있는데, 이걸 등록할 때.. 음.. 만약 아파트면.. 주소만 있으면 되지만, 빌딩이면, 내부 건물의 유닛이 몇개인지 알아야 하고 개당 유닛의 특징도 적어야 할 것 같은데.. 일단 지침에도 적었지만, 이걸 관리 하는 프로그램을 만들고 싶어

ChatGPT: property를 한글로 옮길 때 일반적으로 “부동산” 또는 **“자산”**이라고 번역합니다.
프로그램 관점에서는 “관리 대상이 되는 부동산 매물”이란 뜻에서 간단히 “부동산” 이라 부르는 게 자연스럽습니다.... 

정말 괜찮은 답변이여서, 이대로 화면에 구현이 가능할까.. 실제 spring-boot JPA 를 사용하여 웹(web) 기반 프로트타입 개발을 시작했습니다. 사실, 이 프로젝트를 생각한건 꽤 오래전이여서, github 에 레퍼지터리를 만들어 놓고, 진행을 어떻게 할까 생각만 하다가 진행을 안하고 있었는데, ai 덕에 진행이 되었네요 ^^a .... 음 여하튼.. 혹시 궁금해 하시는 분들을 위해서.. 프로토 타입이란.. (출처: DBpia) 

프로토타입 방법론은 소프트웨어 공학에서 요구사항을 명확히 하기 어려운 경우, 개발 초기 단계에서 시제품을 만들어 사용자의 피드백을 반영하며 점진적으로 시스템을 완성해 나가는 접근 방식이다. 이는 반복적인 개발 과정을 통해 시스템의 완성도를 높이는 데 기여하며, 사용자 중심 설계의 중요한 방법론으로 간주된다. 특히, 불확실성이 높은 프로젝트에서 위험을 줄이고, 최종 제품의 사용자 만족도를 향상시키는 데 효과적이다.

제가 좋아하는 Agile 개발 방법 시작 전, 기반이 되는 시제품을 미리 만들어 보는 방법입니다. 코드 구현에 테스트한 ai 툴은 gemini-cli 였습니다. gemini-cli를 선택한 이유는 단순했습니다. 무료였고, 꽤 강력한 코딩 능력을 보여준다고 했기 때문입니다. 그래서 한 달 정도 시간을 내서 테스트 삼아 작업을 해 봤는데, 예상보다 결과가 괜찮았어요. 그때는 어떤 화면을 만들고 어떤 기능을 넣어야 할지 구체적으로 정리가 안 되어 있었습니다.

직접 웹 애플리케이션을 만들어 보면서 자연스럽게 요구사항이 정리되었고, 나름의 요구사항 명세서까지 프로토타입을 통해 뽑아낼 수 있었습니다. 프로토 타입 작업하면서, 중간중간에 즉흥적으로 떠오르는 기능이나 반드시 들어가야 한다고 생각되는 부분들은 바로바로 추가하면서 진행 했고요. 제가 웹 애플리케이션 개발을 해봤어서, 만약 AI가 제대로 결과물을 내지 못하면 제가 직접 손을 대서 보완할 수 있었습니다. 이런 점에서 자바를 선택한 것도 자연스러운 선택이었습니다.

Gemini-CLI 는 하루에 고급 기능(gemini-pro) 을 제한적으로만 쓸 수 있었지만, 단순 CRUD 작업은 잘 수행했기 때문에 큰 문제는 없었습니다. 만약 gemini-flash 를 사용하면서 오류가 생기면 제가 바로 IDE를 열어 직접 수정했고, 이후 AI에게 피드백을 주면서 다시 확인받는 방식으로 진행했기 때문에 작업이 크게 지연되지는 않았습니다. 약 3-4주 정도.. 이 과정을 거치면서, AI를 활용해 바이브 코딩을 할 때 어떤 방식으로 요구사항을 제시해야 하는지 감을 잡을 수 있었습니다.

https://youtu.be/jcXF12t93vw

프로토타입 결과물: [ github : Renthouse : youp-han/RentHouse: 프로토타입 ]

프로토타입은 말 그대로 시제품이였고, 초기 개발 테스트 버전이여서 LLM 을 통해 분석한 내용이 실제 코드를 통한 CRUD 기능이 되는지, 화면 디자인이 원하는 대로 나오는지 확인하는 단계여서, 결과물에 매우 만족하였습니다. 

이어지는 글: #바이브코딩 으로 앱 만들기 - 실제 코딩 진행

부동산 임대 관리를 위한 종합 솔루션

📋 프로젝트 소개

UniRent는 부동산 관리자를 위한 Flutter 기반의 크로스 플랫폼 임대 관리 애플리케이션입니다. 물건 관리, 임차인 관리, 계약 관리, 청구서 발행 등 부동산 임대 업무의 전 과정을 효율적으로 처리할 수 있도록 설계되었습니다.

✨ 주요 기능

📊 대시보드

• 주요 지표 실시간 모니터링
• 물건/임차인/계약 현황 한눈에 파악
• 청구/수납 현황 통계

🏢 자산 관리

• 건물 및 호실 등록/수정/삭제
• 호실별 상세 정보 관리
• 자산 상태 추적 (임대가능/임대중/점검중)

👥 임차인 관리

• 임차인 정보 등록 및 관리
• 연락처 및 계약 이력 관리
• 임차인별 청구 내역 조회

📝 계약 관리

• 임대차 계약 생성 및 관리
• 계약 상태 추적 (활성/만료/해지)
• 계약 기간 및 조건 관리
• 보증금/월세 정보 관리

💰 청구 및 결제

• 월세 자동 청구서 생성
• 청구 템플릿 관리
• 결제 내역 추적
• 미수금 관리

📈 비용 관리

• 건물/호실별 비용 기록
• 비용 카테고리별 분류
• 비용 통계 및 분석

📱 활동 로그

• 시스템 활동 이력 추적
• 사용자 작업 기록

📄 보고서

• 각종 관리 보고서 생성

⚙️ 설정

• 사용자 프로필 관리
• 시스템 설정

🏗️ 아키텍처

Clean Architecture + MVVM 패턴

이 프로젝트는 Clean Architecture와 MVVM(Model-View-ViewModel) 패턴을 결합하여 확장 가능하고 유지보수가 용이한 구조로 설계되었습니다.

lib/
├── app/                      # 앱 설정, 테마, 라우팅
│   ├── router.dart          # go_router 기반 네비게이션
│   └── theme.dart           # Material 3 테마 설정
│
├── core/                     # 공유 유틸리티 및 인프라
│   ├── auth/                # 인증 로직
│   ├── database/            # Drift 데이터베이스 설정
│   ├── network/             # HTTP 클라이언트 구성
│   └── rbac/                # 역할 기반 접근 제어
│
└── features/                 # 기능 기반 모듈
    ├── auth/                # 로그인 및 인증 UI
    ├── dashboard/           # 메인 대시보드
    ├── property/            # 물건 및 호실 관리
    ├── tenant/              # 임차인 관리
    ├── lease/               # 계약 관리
    ├── billing/             # 청구 및 청구 템플릿
    ├── payment/             # 결제 관리
    ├── expense/             # 비용 관리
    ├── activity/            # 활동 로그
    ├── reports/             # 보고서
    └── settings/            # 설정

데이터 흐름

┌─────────────────────────────────────────────┐
│  Presentation Layer (View)                  │
│  - Screens & Widgets                        │
└────────────────┬────────────────────────────┘
                 │
                 ▼
┌─────────────────────────────────────────────┐
│  Application Layer (ViewModel)              │
│  - Riverpod Controllers                     │
│  - Business Logic                           │
└────────────────┬────────────────────────────┘
                 │
                 ▼
┌─────────────────────────────────────────────┐
│  Data Layer (Model)                         │
│  - Repositories                             │
│  - Data Sources (Local/Remote)              │
└────────────────┬────────────────────────────┘
                 │
                 ▼
┌─────────────────────────────────────────────┐
│  Domain Layer                               │
│  - Entities (Freezed Models)                │
│  - Business Models                          │
└─────────────────────────────────────────────┘

🚀 핵심 기술 스택

프레임워크 & 언어

• Flutter ^3.9.2 - 크로스 플랫폼 UI 프레임워크
• Dart - 프로그래밍 언어

상태 관리

• Riverpod ^2.5.1 - 타입 안전한 상태 관리
• riverpod_annotation ^2.3.5 - 코드 생성 기반 Provider

데이터 모델링

• Freezed ^2.5.2 - 불변 데이터 클래스 생성
• json_serializable ^6.9.0 - JSON 직렬화

데이터베이스

• Drift ^2.17.0 - SQLite ORM (타입 안전)
• sqflite ^2.3.3 - Android용 SQLite
• sqflite_common_ffi ^2.3.3 - Windows/Linux용 SQLite

네트워크

• Dio ^5.5.0 - HTTP 클라이언트

라우팅

• go_router ^14.2.0 - 선언적 라우팅

UI/UX

• Material 3 - 최신 디자인 시스템
• 반응형 디자인 - 모바일/데스크톱 적응형 레이아웃

문서 처리

• pdf ^3.11.1 - PDF 생성
• printing ^5.13.2 - PDF 인쇄
• excel ^4.0.3 - Excel 파일 처리
• csv ^6.0.0 - CSV 처리

기타

• uuid ^4.4.0 - 고유 ID 생성
• intl ^0.19.0 - 국제화 및 날짜 포맷
• logger ^2.4.0 - 로깅
• flutter_secure_storage ^9.2.2 - 보안 저장소

💎 프로젝트의 장점

1. 확장 가능한 아키텍처

• Clean Architecture로 계층 분리
• MVVM 패턴으로 비즈니스 로직과 UI 분리
• 기능별 모듈화로 독립적인 개발 가능

2. 타입 안전성

• Freezed를 통한 불변 데이터 모델
• Riverpod의 컴파일 타임 타입 체크
• Drift의 타입 안전한 쿼리

3. 코드 생성 자동화

• build_runner를 통한 보일러플레이트 최소화
• Freezed, Riverpod, JSON 직렬화 자동 생성
• 생산성 향상 및 휴먼 에러 감소

4. 크로스 플랫폼 지원

• 단일 코드베이스로 모바일(Android/iOS), 데스크톱(Windows), 웹 지원
•  

  

• 플랫폼별 최적화된 데이터베이스 지원 - sqlite 기본

• 

• 반응형 UI로 다양한 화면 크기 대응

 5. 오프라인 우선 설계

• 로컬 SQLite 데이터베이스로 오프라인 작동
• 빠른 응답 속도
• 향후 서버 동기화 기능 추가 예정
• 로그인 : firebase 연동

6. 유지보수성

• 명확한 폴더 구조
• 관심사의 분리
• 테스트 가능한 설계 : 모든 주요 기능 의 테스트 코드 작성 완료

7. 현대적인 기술 스택

• 최신 Flutter & Dart 버전
• Material 3 디자인
• 업계 표준 라이브러리 사용

📝 라이선스

📧 개발 및 비지니스 협업 문의 : youp.han@gmail.com 

UniRent - 스마트한 임대 관리의 시작

원본: https://yobine.tistory.com/616 번역 입니다. 

2017년, 대학원 시절 뛰어난 동료들과 훌륭한 교수님의 지도 아래 “DevOps Capabilities, Challenges, and Solutions” 라는 논문을 함께 집필했을 때, 우리는 기업이 DevOps를 성공적으로 도입하기 위해 필요한 네 가지 핵심 역량을 정리했습니다:

• 사람(People)
• 프로세스(Process)
• 기술(Technology)
• 산출물(Artifacts)

이 프레임워크는 DevOps가 단순히 도구를 넘어선다는 점을 설명하는 데 도움이 되었습니다. DevOps는 문화, 워크플로우, 그리고 우리가 만들어내고 관리하는 결과물에 관한 것이었습니다.

2025년인 지금, 여전히 이 네 가지 역량은 필수적이라고 생각합니다. 달라진 것은 현대 기업 환경에서 이들이 표현되고 실천되는 방식입니다.

👥 사람 (People)

• 2017년: 협업과 문화가 핵심이었고, HR의 역할은 DevOps 마인드셋을 갖춘 인재를 채용하고 사일로를 허무는 것이었습니다.
• 2025년: 문화는 여전히 중심이지만, HR 실무는 AI 기반 채용, 지속적 학습, 스킬 매핑으로 진화했습니다. 빠르게 변하는 기술 환경에서 팀이 적응력을 유지하도록 돕는 방향으로 바뀌고 있습니다.

🔄 프로세스 (Process)

• 2017년: 애자일 워크플로우, CI/CD 파이프라인, 자동화가 중심이었습니다.
• 2025년: AI가 프로세스를 재편하고 있습니다.
  • 사건 예측 분석(Predictive Analytics)
  • 생성형 AI 기반 런북
  • 자가 치유(Self-healing) 파이프라인
    이제 프로세스 차원은 자율성과 지능까지 포함하게 되었습니다.

💻 기술 (Technology)

• 2017년: 클라우드 도입, 컨테이너, Chef, Puppet, Ansible, Docker 같은 도구들이 선도적이었습니다.
• 2025년:
  • 쿠버네티스(Kubernetes)는 기본 전제가 되었고,
  • GitOps, 정책-코드화(Policy-as-Code), 플랫폼 엔지니어링,
  • AI 보강 관측성(Observability)이 주류를 차지하고 있습니다.

기술은 끊임없이 진화하지만, DevOps 역량은 여전히 변화를 가능하게 하고 확장하는 것에 초점이 맞춰져 있습니다.

📦 산출물 (Artifacts)

• 2017년: 빌드, 배포 패키지, 스크립트, 모니터링 로그가 DevOps의 산출물이었습니다.
• 2025년:
  • 모니터링 및 관측 시스템이 메트릭, 트레이스, 로그, AI 생성 인사이트 같은 풍부한 산출물을 만들어냅니다.
  • 이제 이 산출물은 단순한 부산물이 아니라, 의사결정과 자동화를 이끄는 적극적 자산이 되었습니다.

✨ 성찰 (Reflection)

AI가 워크플로우를 바꾸고 기술이 계속 진화하더라도, 사람·프로세스·기술·산출물이라는 네 가지 역량은 DevOps 성숙도의 토대입니다.

이 관점은 제 개인적인 읽음과 생각에서 비롯된 것이며, 도구는 오고 가지만 DevOps의 핵심 원칙은 여전히 이어진다는 사실을 일깨워 줍니다.

Docker를 쓰다 보면 어느 순간 맥의 저장 공간을 몽땅 잡아먹는 Docker.raw 파일을 보게 됩니다. 이미지/컨테이너/볼륨을 지워도 용량이 줄지 않는 이유, 그리고 실제로 용량을 줄이는 방법을 정리했습니다. Postgres를 쓰는 분들을 위한 체크리스트도 포함했어요.

TL;DR

• macOS의 Docker Desktop은 모든 데이터를 하나의 디스크 이미지(Docker.raw)에 저장합니다.
• 이미지/컨테이너/볼륨을 지워도 파일 자체 크기는 자동으로 줄지 않습니다.
• 공간을 줄이는 확실한 방법은 Reclaim(공간 회수) 를 실행하거나 디스크 이미지를 재생성하는 것입니다.
• DB(특히 Postgres) 데이터는 호스트 디렉토리로 분리 마운트하면 Docker.raw가 비대해지는 것을 막을 수 있습니다.

1) 왜 Docker.raw가 이렇게 커질까?

• 단일 디스크 이미지 구조: Docker Desktop은 내부 리눅스 VM의 /var/lib/docker 전체를 Docker.raw 한 파일에 담습니다. (이미지, 컨테이너, 볼륨 포함)
• 희소 파일(Sparse): 처음에는 크게 보이지만 실제 사용량은 적을 수 있습니다. 다만 사용이 늘면 실제 디스크도 커집니다.
• 자동 축소 없음: 리소스를 삭제해도 파일 자체가 줄어들지 않습니다. 내부적으로 빈 블록으로만 표시됩니다.
• DB/로그의 누적: Postgres 같은 DB 컨테이너의 데이터, WAL 로그, 애플리케이션 로그가 용량 폭증의 주범입니다.

2) 현재 상태 진단

# (A) 파일의 ‘겉보기’ 크기
ls -lh ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw

# (B) 실제 디스크 사용량
du -sh ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw

# (C) Docker 리소스별 사용량
docker system df
docker system df -v     # 상세

docker volume ls        # 로컬 볼륨 목록

# (D) (Postgres 예) 컨테이너 내부 실제 DB 데이터 크기
docker exec -it <postgres-container-id> du -sh /var/lib/postgresql/data

심볼릭 링크 주의: Docker.raw를 외장 디스크로 옮긴 뒤 링크만 남겼다면, 링크가 아니라 실제 대상 파일 경로에서 du -sh로 확인하세요. (예: /Volumes/External/DockerData/Docker.raw)

3) 공간 줄이는 방법 (권장 순서)

A. Reclaim: Docker Desktop 제공 공간 회수

데이터는 보존하면서, Docker.raw 내의 유휴 블록을 정리합니다.

docker run --privileged --pid=host docker/desktop-reclaim-space
# Apple Silicon에서 경고가 거슬리면 플랫폼 지정
# docker run --privileged --pid=host --platform=linux/amd64 docker/desktop-reclaim-space

실행 후 다시 확인:

du -sh /경로/…/Docker.raw

실제 사례: Reclaim 한 번으로 수백 GB → 수 GB까지 줄어드는 경우가 흔합니다.

B. 디스크 이미지 재생성 (가장 확실, 단 데이터 초기화)

모든 Docker 데이터(이미지/컨테이너/볼륨)를 날리고 새로 시작합니다.

1) Docker 종료 (메뉴바 아이콘 → Quit Docker)
2) Docker.raw 삭제

rm ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw
# 외장 디스크로 옮겨 링크 중이라면, 실제 대상 파일을 삭제
# rm /Volumes/External/DockerData/Docker.raw

3) Docker 재실행 (open -a Docker) → 새 Docker.raw 자동 생성
4) 필요 이미지/컨테이너 재배포

주의: 완전 초기화입니다. 필요한 데이터는 백업(pg_dump, docker save, 파일 복사 등) 후 진행하세요.

C. DB 데이터는 호스트 디렉토리로 분리 (재발 방지)

DB 데이터를 Docker.raw 바깥(외장 SSD 등)에 저장하면 비대화 방지에 효과적입니다.

# docker-compose.yml (예: Postgres)
services:
  db:
    image: postgres:15
    environment:
      - POSTGRES_PASSWORD=yourpw
    volumes:
      - /Volumes/External/PostgresData:/var/lib/postgresql/data  # ← 호스트 경로 바인드
    ports:
      - "5432:5432"

• 장점: DB 용량이 늘어도 Docker.raw는 그대로.
• 팁: 외장 디스크를 쓴다면 항상 마운트 경로가 동일해야 합니다.

4) (중요) Postgres 용량 다이어트 체크리스트

Postgres를 쓰면 Docker.raw가 급격히 커지는 일이 많습니다.

• VACUUM / VACUUM FULL

VACUUM FULL은 테이블 잠금을 수반합니다. 다운타임이 부담스럽다면 pg_repack 등 대안 검토.

•  
• VACUUM (VERBOSE); -- 테이블/DB 폭증 시 잠깐 서비스 중단 허용 가능하면 VACUUM FULL;
• WAL 관리
  • CHECKPOINT; 실행으로 불필요 WAL 처리 가속
  • 아카이빙/보관 정책 점검 (archive_mode, archive_command)
• Autovacuum 튜닝
  • 대량 UPDATE/DELETE가 많은 테이블은 autovacuum 파라미터 조정 검토
• 로그/임시파일
  • 장기 보관 로그/임시파일이 볼륨을 잠식하는지 확인

정리 후에도 Docker.raw는 자동 축소되지 않으므로, A(Reclaim) 또는 B(재생성) 으로 실제 파일 크기를 줄여야 합니다.

5) 외장 디스크로 Docker.raw 옮기기 (선택)

내장 SSD 부담을 줄이고 싶다면:

# 0) Docker 종료 (Quit Docker)
# 1) 새 위치 준비
mkdir -p /Volumes/External/DockerData
# 2) 파일 이동
mv ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw \
   /Volumes/External/DockerData/
# 3) 심볼릭 링크 생성
ln -s /Volumes/External/DockerData/Docker.raw \
      ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw
# 4) Docker 재실행

이후부터는 외장 디스크 용량만 소모됩니다. du -sh는 실제 파일 경로에서 확인하세요.

6) 자주 묻는 질문(FAQ)

• Q. WARNING: platform amd64 != host arm64 경고가 떠요.
  A. Apple Silicon 맥에서 reclaim 이미지를 쓸 때 나는 일반적인 경고입니다. 기능엔 문제 없습니다. 조용히 돌리고 싶으면 --platform=linux/amd64를 지정하세요.
• Q. Docker.raw 기본 위치는 어디인가요?
  A. ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw (구버전은 Docker.qcow2)
• Q. 이미지/컨테이너를 지웠는데 왜 파일이 안 줄죠?
  A. Docker.raw는 자동 축소되지 않습니다. Reclaim하거나 재생성해야 실제 파일 크기가 줄어듭니다.
• Q. VM 내부의 실제 경로는요?
  A. /var/lib/docker 아래에 저장됩니다. macOS에서는 디스크 이미지(Docker.raw)로 캡슐화되어 접근합니다.

7) 운영 체크리스트 (복붙용)

# 상태 점검
ls -lh /…/Docker.raw
du -sh /…/Docker.raw

# Docker 리소스 점검
docker system df
docker system df -v

# 공간 회수 (월 1회 추천)
docker run --privileged --pid=host --platform=linux/amd64 docker/desktop-reclaim-space

# 정말 안 쓰는 리소스 전부 정리 (⚠️ 신중하게)
docker system prune -a --volumes

8) 실전 예시 (전/후)

• Before: Docker.raw 228 GB (실제 디스크 점유)
• Reclaim 실행: docker/desktop-reclaim-space
• After: Docker.raw 6.3 GB

컨테이너/이미지 자체의 사용량은 작았지만, 과거 이력 때문에 Docker.raw가 비대해진 전형적인 사례입니다.

결론

• 용량이 갑자기 부족해졌다면 Docker.raw부터 확인하세요.
• 데이터 보존이 필요하면 Reclaim, 완전 초기화가 가능하면 재생성으로 가장 빠르게 해결됩니다.
• DB는 호스트 디렉토리로 분리 마운트하여 재발을 막는 것이 최선입니다.

이 글이 도움이 되셨다면, 팀 위키/개인 블로그에 그대로 가져다 쓰세요. 상황에 맞게 경로만 바꾸면 됩니다. 👍

Back in 2017, when I co-authored a graduate paper on “DevOps Capabilities, Challenges, and Solutions” with brilliant peers under the guidance of an excellent professor during my graduate studies, we outlined four key capabilities that enterprises need to successfully adopt DevOps:

1. People
2. Process
3. Technology
4. Artifacts

At the time, this framework helped explain how DevOps goes beyond tools—it’s about culture, workflows, and the outputs we create and manage.

Today in 2025, I still see these four capabilities as essential. What has shifted is the way they are expressed and practiced across modern enterprise environments.

People

• 2017: Collaboration and culture were the primary focus. HR’s role was to recruit for DevOps-ready mindsets and break down silos.
• 2025: Culture is still central, but HR practices are evolving with AI-driven recruiting, continuous learning, and skills mapping to keep teams adaptable in fast-changing tech landscapes.

Process

• 2017: Agile workflows, CI/CD pipelines, and automation were the core.
• 2025: AI is reshaping processes—from predictive analytics for incidents to generative AI for runbooks and self-healing pipelines. The process dimension now includes autonomy and intelligence.

Technology

• 2017: Cloud adoption, containers, and tools like Chef, Puppet, Ansible, and Docker were leading the way.
• 2025: Kubernetes is the baseline. GitOps, policy-as-code, platform engineering, and AI-augmented observability dominate. Technology keeps evolving, but the capability remains about enabling and scaling change.

Artifacts

• 2017: Builds, deployment packages, scripts, and monitoring logs formed the outputs of DevOps.
• 2025: Monitoring and observability systems now generate rich artifacts—metrics, traces, logs, and AI-generated insights. These artifacts are no longer passive byproducts but active drivers for decision-making and automation.

Reflection

Even as AI transforms workflows and technologies continue to evolve, the four capabilities—People, Process, Technology, and Artifacts—remain the foundation of DevOps maturity.

This perspective is based on my own readings and thoughts, and it reminds me that while tools come and go, the core principles of DevOps endure.

별생각 없이.. 테스트 용, spring boot 웹 어플리케이션 하나 만들었는데, pc 에 설치 된 tomcat 에서 실행이 안되어, 반나절을 이것 저것 해봤는데.. 절대, tomcat 문제도 아니고 spring 어플리케이션 내, 오류도 아니였다.

버전 문제였음.

1. spring boot 3.3.10
2. apache-tomcat-9.0.104-windows-x64 

별별 설정을 다 찾아 봤는데.. 마지막으로 혹시나 하는 마음에 ChatGPT 에게 물어보니.. ㅠㅠ...

💥 문제 원인: Spring Boot 3.x 는 Jakarta EE 10 기반, 하지만 Tomcat 9.x 는 Jakarta EE 8까지만 지원

✳️ Spring Boot 3.x → Jakarta EE 10 기반

Spring Boot 3.0부터는 기존 javax.* 패키지를 버리고 → jakarta.* 네임스페이스로 완전히 전환되었습니다.

❌ Tomcat 9.x → Jakarta EE 8까지만 지원

Tomcat 9.x는 javax.servlet.*, javax.el.*, javax.websocket.* 등 이전 네임스페이스 기반이고,
Spring Boot 3.x에서 생성된 WAR 파일을 실행하면 서블릿 API 호환 오류가 발생하거나
애플리케이션이 아예 실행되지 않는 경우가 발생합니다.

✅ 해결 방법 2가지

▶️ 방법 1: Tomcat 10.1+ 설치 (권장)

Tomcat 10.1부터 Jakarta EE 10을 공식 지원하므로 Spring Boot 3.x WAR 파일을 정상적으로 실행할 수 있습니다.

• Tomcat 10.1 다운로드
• 설치 후, 기존 ROOT.war 넣고 실행하면 바로 접속 가능해야 합니다.

Tomcat 10.0은 변환 브릿지 버전이라 10.1 이상을 추천드립니다.

▶️ 방법 2: Spring Boot 버전을 2.7.x로 다운그레이드 (비추천)

• Spring Boot 2.7.x는 javax.* 기반이므로 Tomcat 9.x에서 호환됩니다.
• 하지만 최신 기능과 보안 패치를 놓치게 되므로 권장하지 않아요.

📌 결론

Spring Boot 3.3.10 + Tomcat 9.x = ❌ 호환 불가
Spring Boot 3.3.10 + Tomcat 10.1.x = ✅ 정상 작동

나의 선택은 Tomcat upgrade..10.1 ... 업그레이드 하자마자.. hello 아흑..