때로는 까칠하게..

Xcode 시뮬레이터 먹통으로 마우스 및 키보드 입력 불가

까칠코더 — Mon, 10 Aug 2026 11:41:32 +0900

Xcode 시뮬레이터 먹통으로 마우스 및 키보드 입력 불가

Xcode로 개발중에 시뮬레이터가 멈추거나 시뮬레이터 실행은 되는데 Mac에서 마우스나 키보드로 입력이 안되는 경우가 발생할때가 있습니다. 보통은 시뮬레이터나 Xcode 재시작하거나 아예 Mac을 재시작하면 해결되곤 하는데요.

간혹 이런 방법으로도 해결이 안될때가 있습니다.

1. Xcode 시뮬레이터 강제종료 명령어

시뮬레이터 먹통시 실행하는 명령어의 동작은 다음과 같습니다.

Apple 공식 CLI인 simctl을 통해서 실행중인 모든 가상 기기를 정상으로 shutdown 상태로 전환합니다.

xcrun simctl shutdown all

Mac OS에서 시뮬레이터 앱을 정상종료(SIGTERM) 합니다.

killall Simulator

Xcode와 시뮬레이터 간 통신(IPC) 및 시뮬레이터 생명주기를 관장하는 핵심 데몬을 강제 종료합니다. 종료시 launchd에 의해 자동 재시작되면 데드락이 해제됩니다.

killall -9 com.apple.CoreSimulator.CoreSimulatorService

Xcode에서 빌드된 앱을 시뮬레이터 런타임에 실행하고 디버거를 연결하는 도우미 프로세스를 초기화 합니다.

killall -9 SimulatorTrampoline

macOS 호스트 환경과 가장 iOS 내부 OS간 입출력 이벤트를 전달하는 브릿지 데몬을 강제 종료하여 동기화를 리셋합니다.

killall -9 CoreSimulatorBridge

2. 단계별 시뮬레이터 먹통 초기화 방법

셧다운 및 데몬 강제 리셋하기

xcrun simctl shutdown all
killall Simulator
killall -9 com.apple.CoreSimulator.CoreSimulatorService
killall -9 SimulatorTrampoline
killall -9 CoreSimulatorBridge

시뮬레이터 기기 데이터 전체 초기화

xcrun simctl erase all

CoreSimulator 캐시 및 DerivedData 삭제

rm -rf ~/Library/Developer/CoreSimulator/Caches
rm -rf ~/Library/Developer/Xcode/DerivedData

Xcode 및 CoreSimulatorService 데몬 완전 재시작

killall -9 com.apple.CoreSimulator.CoreSimulatorService
open -a Xcode

3. 키보드만 입력이 안될때

시뮬레이터 내부 텍스트 필드에 Mac 키보드 입력이 전달되지 않는 경우에는 다음과 같은 확인 필요합니다.

Mac의 키보드 입력을 시뮬레이터 가상 기기로 전달하는 설정이 꺼진 경우 발생합니다. (I/O -> Keyboard -> Connect Hardware Keyboard 체크)

해결방법 : 하드웨어 키보드 연결 옵션 해제 : Cmd + Shift + K

시뮬레이터 가상 온스크린 키보드와 호스트 입력 상태가 꼬였을때 발생합니다.

해결방법 : 소프트웨어 온스크린 키보드 토글 : Cmd + K

Mac의 현재 입력기가 한글(2벌식 등) 모드일 때 시뮬레이터 텍스트 필드 뷰가 이벤트를 수신하지 못하는 현상

해결방법 : macOS 한영/입력기 동기화 오류: 입력기를 영문(U.S)로 전환

호스트 Mac과 시뮬레이터 기기간 키보드 이벤트 전달 브릿지 데몬이 응답 없는 상태

해결방법 : coreSimulatorBridge 데몬 리셋

killall -9 CoreSimulatorBridge

핵심 요약

Xcode 시뮬레이터 먹통은 주로 CoreSimulatorBridge 데몬의 오류가 주요 원인이고, 강제 재시작으로 해결할 수 있습니다.

Electron과 Tauri 비교 : 성능, 메모리, 사용법 및 도입 가이드

까칠코더 — Fri, 7 Aug 2026 13:24:40 +0900

Electron과 Tauri 비교 : 성능, 메모리, 사용법 및 도입 가이드

웹 기술(HTML, CSS, JavaScript)을 활용해 데스크톱 애플리케이션을 개발할 때 가장 대표적으로 검토되는 프레임워크는 Eletron과 Tauri입니다. 기존 시장을 독접하던 Eletron의 무거운 리소스 점유율 문제를 해결하기 위해 경량화된 Rust 기반의 Tauri가 부상하면서 두 기술 간의 선택 고민이 커지고 있습니다.

1. Electron과 Tauri의 핵심 아키텍쳐

Electron (Chromium + Node.js 번들링)

구조 : 애플리케이션 번들 내에 전체 Chromium 브라우저 엔진과 Node.js 런타임을 통째로 내장하여 패키징 합니다.
프로세스 : UI를 담당하는 Renderer 프로세스(Chromium)와 시스템 제어를 담당하는 Main 프로세스(Node.js)가 IPC 통신으로 작동합니다.

Tauri (OS 네이티브 WebView + Rust 백앤드)

구조 : 자체 브라우저 엔진을 내장하지 않고, 운영체제에 이미 설치된 네이티브 WebView (Windwos: WebView2, macOS : WKWebView, Linux: WebKitGTX)를 활용합니다.
백앤드 : 백앤드 런타임으로 Node.js 대신 메모리 안전성과 성능이 뛰어난 Rust 런타임을 사용합니다.

2. 바이너리 크기, 메모리 사용량 비교

실제 동일한 HelloWorld 수준의 기본앱을 빌드했을때의 리소스 수치 비교입니다.

구분	Electron	Tauri
설치 파일 번들 용량	80 ~ 120 MB	8 ~ 10 MB
메모리(RAM) 점유율	150 ~ 300 MB	30 ~ 50 MB

3. 프레임워크별 환경 설정 및 기본 사용 방법

Electron 기본 사용법 (Node.js 기반)

JavaScript

// main.js (Main 프로세스)
const { app, BrowserWindow, ipcMain } = require('electron');

function createWindow() {
  const win = new BrowserWindow({
    width: 800,
    height: 600,
    webPreferences: {
      nodeIntegration: false,
      contextIsolation: true
    }
  });

  win.loadFile('index.html');
}

app.whenReady().then(createWindow);

// JS <-> Node.js IPC 바인딩
ipcMain.handle('get-system-info', async () => {
  return process.platform;
});

Tauri 기본 사용법 (Rust + Web 프론트앤드)

# Tauri 프로젝트 초기화 CLI
npx create-tauri-app

Rust

// src-tauri/src/main.rs (Rust 백엔드 커맨드 정의)
#![cfg_attr(not(debug_assertions), windows_subsystem = "windows")]

// Frontend에서 호출 가능한 Rust 커맨드 작성
#[tauri::command]
fn greet(name: &str) -> String {
    format!("Hello, {}! Rust에서 반환된 응답입니다.", name)
}

fn main() {
    tauri::Builder::default()
        .invoke_handler(tauri::generate_handler![greet])
        .run(tauri::generate_context!())
        .expect("Tauri 앱 실행 실패");
}
```

JavaScript

// src/App.js (Frontend JS에서 Rust 명령어 호출)
import { invoke } from '@tauri-apps/api/core';

async function callRust() {
  const response = await invoke('greet', { name: 'Developer' });
  console.log(response);
}

4. 서비스 도입 사례

구분	Electron	Tauri
도입 서비스	VS Code, 1Password 8 (Electron UI + Rust Core), Slack, Discord, Notion, Figma Desktop, Obsidian, 채널톡 (Channel.io), 리디 (RIDI PC 뷰어), 밀리의 서재 (PC 뷰어), ...	GitButler, Spacedrive, Bloop, CrabNebula

5. 프로젝트별 프레임워크 선택 의사 결정 체크리스트

Electron 도입이 유리한 경우

NPM 생태계 의존성 : Node.js 전용 C++ 애드온 라이브러리나 대규모 NPM 패키지를 다수 활용해야 하는 경우
빠른 MVP 개발 속도 : 개발팀에 Rust 경험자가 없고, JavaScript/TypeScript 기반으로 즉시 데스크톱 앱을 출시해야 하는 경우
구형 레거시 호환성 : 특정 OS 버전이나 구형 렌더링 호환성을 Chromium 통째로 번들링으로 통일해야 하는 경우

Tauri 도입이 유리한 경우

리소스 최적화 : 10MB 미만의 작은 설치 파일과 30MB 수준의 최저 메모리(RAM) 점유율이 핵심 스펙인 경우
강력한 보안 및 백앤드 성능 : 시스템 파일 파싱, 암호화 처리 등 고성능 백앤드 연동(Rust)과 샌드박스 보관이 필요한 경우
크로스 플랫폼 확장성 : 하나의 코드베이스로 데스크톱(Windows/macOS/Linux)뿐만 아니라 iOS 및 Android 모바일 타겟까지 확장하려는 경우

6. 배포 및 자동 업데이트(Auto-Update) 생태계 비교

Electron 의 배포 생태계

외부 툴링 의존 : 빌드 및 수동 패키징을 위해 electron-builder 또는 electron-forge를 사용합니다.
업데이트 관리 : electron-updater 패키지를 조합하여 자체 S3나 GitHub Releases 서버 구축이 필요합니다.

Tauri의 배포 생태계

자체 인브라 내장 : tauri.conf.json 설정에 자동 업데이트(Auto-Updater)기능이 기본 포함되어 있습니다.
클라우드 연동 : 전용 멀티 플랫폼 자동 빌드, 업데이트 관리 서비스읜 CrabNebula 인프라와 즉시 결합이 가능합니다.

7. 상세 스팩 비교

구분	Electron	Tauri (V2 기준)
백엔드 런타임	Node.js	Rust
렌더링 엔진	Chromium 엔진 내장 (통째 번들링)	OS 네이티브 WebView 공유
지원 플랫폼	데스크톱 (Windows, macOS, Linux)	데스크톱 + 모바일 (iOS, Android)
빌드 파일 크기	약 80MB ~ 150MB	약 3MB ~ 10MB
RAM 메모리 소모	높음 (150MB ~ 300MB+)	매우 낮음 (30MB ~ 50MB)
자동 업데이트	electron-updater 서드파티 사용	내장 Updater 및 CrabNebula
보안 체계	개발자 설정 의존	Default-Deny 샌드박스
진입 장벽	낮음 (JavaScript/Node.js)	보통~높음 (Rust 학습 필요)
생태계 및 플러그인	압도적으로 거대함	빠르게 성숙 중

8. 핵심 요약

거대한 NPM 생태계와 빠른 개발 속도가 최우선이라면 Electron이 유리하며, 설치 파일 용량과 RAM 소모 최소화, 고성능 메모리 보안 및 모바일 확장성까지 중요하다면 Tauri를 도입하는 것이 적합니다.

iOS AppIntents 아키텍쳐: 온디바이스 AI 및 Siri에 앱 로직 연동하기

까칠코더 — Thu, 6 Aug 2026 11:31:05 +0900

iOS AppIntents 아키텍쳐: 온디바이스 AI 및 Siri에 앱 로직 연동하기

Apple Intelligence 및 Siri와 같은 온디바이스 AI 시스템이 사용자의 의도를 파악하여 특정 애브이 기능을 직접 실행하려면, 앱 내부 로직을 시스템이 이해할 수 있는 형식으로 노출해야 합니다. 기존의 복잡한 SiriKit 자원 파일(Intent Definition) 대신 Swift 언어의 선언적 문법을 활용하는 AppIntents 프레임워크가 iOS 앱 연동의 표준 아키텍처로 자리 잡았습니다.

1. 기존 SiriKit의 한계와 AppIntents 프레임워크의 도입

기존 SiriKit은 별도의 .intentdefinition 파일 설정과 자동생성 코드에 의존하여 코드 유지 보수가 까다로웠습니다.

선언적 Swift 코드 : AppIntents는 Swift 프로토콜 기반으로 동작하여 뷰 코드 및 도메인 로직과 동일한 코드 베이스 내에서 선언적으로 정의 됩니다.
Apple Intelligence 결합 : 단순 음성 명령을 넘어 온디바이스 AI 시스템이 앱 내부 엔티티(Entity)와 인텐트(Intent)를 인식하도록 지원합니다.

2. AppIntents 아키텍처 핵심 구성 요소

AppIntents 시스템은 3가지 기본 프로토콜로 구성됩니다.

AppIntent : 앱이 수행할 수 있는 작업 단위(동작)를 정의합니다. (예: "주문하기", "메모 작성하기")
AppEntity : 작업의 대상이 되는 앱 내부 데이터 모델을 다룹니다. (예: "상품", "노트 객체")
AppShortcutsProvider : Siri 및 단축어 앱에 자동으로 등록될 기본 음성 명령 패턴을 선언합니다.

3. AppIntent 구현 및 비즈니스 로직 연동 실무 예제

특정 동작을 수행하는 AppIntent를 Swift 코드로 구현하는 방식입니다.

import AppIntents

// 1. 시스템에 노출할 동작(Intent) 정의
struct CreateNoteIntent: AppIntent {
    // 시스템 Siri 및 단축어 앱에 표시될 제목
    static var title: LocalizedStringResource = "새 노트 작성"
    static var description = IntentDescription("지정된 제목으로 새 노트를 생성합니다.")

    // 사용자 또는 온디바이스 AI가 전달할 파라미터 정의
    @Parameter(title: "노트 제목")
    var noteTitle: String

    // Intent 실행 시 호출되는 핵심 로직
    @MainActor
    func perform() async throws -> some IntentResult & ReturnsValue<String> {
        // 앱 내부 도메인 서비스 호출
        let newNoteId = try await NoteService.shared.create(title: noteTitle)
        
        // 실행 결과 및 성공 메시지 반환
        return .result(value: "노트 '\(noteTitle)'이(가) 성공적으로 생성되었습니다.")
    }
}

// 2. Siri 자동 음성 명령 등록 프로토콜 정의
struct NoteAppShortcuts: AppShortcutsProvider {
    static var appShortcuts: [AppShortcut] {
        AppShortcut(
            intent: CreateNoteIntent(),
            phrases: [
                "\(.applicationName)에서 \(\.$noteTitle) 작성해 줘",
                "\(.applicationName)에 새 노트 추가"
            ],
            shortTitle: "노트 작성",
            systemImageName: "square.and.pencil"
        )
    }
}

4. SiriKit vs AppIntents 비교

구분	기존 SiriKit 방식	AppIntents 프레임워크 방식
설정 방식	.intentdefinition GUI 파일 매핑	Pure Swift 선언적 프로토콜 코드
AI 연동성	고정된 도메인 카테고리만 지원	Apple Intelligence 온디바이스 인지 연동
단축어 자동 등록	사용자가 수동 등록 필요	AppShortcutsProvider 로 자동 생성
유지보수성	생성된 코드와 실제 로직 분리로 복잡	도메인 서비스와 직접 바인딩 가능

5. 핵심 요약

AppIntents 아키택쳐를 도입하면 코드베이스의 이원화 없이 Swift 코드만으로 앱의 핵심 로직을 온디바이스 AI, Siri, 단축어 시스템에 안전하게 노출할수 있습니다.

Swift 6 Strict Concurrency 대응: SwiftData ModelActor 비동기 파싱 및 저장 가이드

까칠코더 — Wed, 5 Aug 2026 10:09:07 +0900

Swift 6 Strict Concurrency 대응: SwiftData ModelActor 비동기 파싱 및 저장 가이드

SwiftData 환경에서 네트워크 API로 받아온 대용량 JSON 데이터를 DB에 파싱하고 저장할 때 메인 스레드(@MainActor)를 사용하면 뷰 레이아웃 멈춤(UI Freeze) 현상이 일어납니다. 반면, 일반 백그라운드 Task에서 메인 뷰의 ModelContext를 그대로 넘겨 사용하면 Swift 6의 엄격한 동시성 검사(Strict Concurrency) 환경에서 데이터 레이스 및 스레드 충돌 에러가 발생합니다. SwiftData에서 제공하는 ModelActor 프로토콜을 사용하면 독립된 액터 스레드 격리 안에서 백그라운드 데이터 파싱 및 저장을 동시성에 안전하게 처리할 수 있습니다. ModelActor 작성 패턴 및 적용 방식은 다음과 같습니다.

1. SwiftData @MainActor 한계와 백그라운드 작업의 필요성

SwiftUI 뷰 계층에서 기본 주입되는 ModelContext는 메인 스레드에 격리(@MainActor)되어 있습니다.

// 메인 스레드에서 대용량 데이터를 처리할 경우 UI가 멈춤
func fetchAndSaveHeavyData() async {
    let items = await api.fetchLargeData()
    for item in items {
        context.insert(Item(from: item)) // UI 프레임 드롭 발생
    }
}

네트워크로부터 대량의 레코드를 수신하여 데이터베이스에 저장해야 할 경우, 메인 뷰 스레드가 블로킹되는 문제를 방지하기 위해 반드시 별도의 백그라운드 액터 스레드에서 DB 커밋을 수행해야 합니다.

2. ModelActor 프로토콜의 역할과 작동 원리

ModelActor는 Swift 6 액터(Actor) 모델을 기반으로 동작하는 SwiftData 전용 인프라 프로토콜입니다.

독립된 ModelContext 보유: ModelActor 내부에는 뷰 스레드와 격리된 별도의 ModelContext와 ModelExecutor가 자동으로 생성됩니다.
액터 스레드 격리: 모든 데이터 삽입, 조회, 삭제 및 save() 작업이 액터 내부 큐에서 순차적(Serial)으로 실행되므로 데이터 레이스가 방지됩니다.

3. ModelActor 구현 및 비동기 백그라운드 DB 처리 실무 예제

ModelActor 프로토콜을 채택한 전용 백그라운드 데이터 핸들러 래퍼를 생성합니다.

import Foundation
import SwiftData

// 1. ModelActor 프로토콜을 채택하는 백그라운드 액터 정의
@ModelActor
actor DataBackgroundHandler {
    // 2. 백그라운드 데이터 파싱 및 저장 메서드 구현
    func insertBatchItems(from rawDataList: [RawItemDTO]) throws {
        for dto in rawDataList {
            let newItem = Item(id: dto.id, name: dto.name)
            modelContext.insert(newItem)
        }
        
        // 3. 백그라운드 전용 context에서 변경사항 즉시 저장
        try modelContext.save()
    }
}

// 4. SwiftUI 또는 ViewModel에서 비동기로 호출
@MainActor
final class ViewModel: ObservableObject {
    private let modelContainer: ModelContainer

    init(modelContainer: ModelContainer) {
        self.modelContainer = modelContainer
    }

    func syncServerData() async {
        let rawData = await networkClient.downloadJSON()
        
        // 백그라운드 액터 생성 시 공유 ModelContainer 전달
        let backgroundHandler = DataBackgroundHandler(modelContainer: modelContainer)
        
        do {
            // 메인 뷰 멈춤 없이 백그라운드 스레드에서 안전하게 DB 저장
            try await backgroundHandler.insertBatchItems(from: rawData)
        } catch {
            print("DB 저장 실패: \(error)")
        }
    }
}

4. 일반 ModelContext 사용 vs ModelActor 패턴 비교 요약

구분	일반 View ModelContext	ModelActor 패턴 방식
실행 스레드	메인 스레드 (@MainActor) 격리	독립된 백그라운드 액터 스레드
대용량 DB 작업 시	UI 프레임 드롭 및 랙 발생	메인 뷰 멈춤 없이 비동기 처리
Swift 6 동시성 검사	백그라운드 Task 전달 시 에러 발생	Strict Concurrency 안전하게 통과
주요 사용 목적	UI 뷰 데이터 바인딩 및 즉시 읽기	네트워크 대량 동기화 및 DB 파싱 백엔드

(출처: Apple Developer Documentation - SwiftData ModelActor)

5. 핵심 요약

SwiftData의 ModelActor 패턴을 도입하면 대용량 DB 저장 및 파싱 작업을 메인 스레드 멈춤 없이 처리할 수 있으며, Swift 6 Strict Concurrency 환경에 부합하는 안전한 백그라운드 데이터 파이프라인을 구축할 수 있습니다.

#SwiftData #ModelActor #Swift6 #StrictConcurrency #iOS개발자 #Swift동시성 #iOS데이터베이스 #AppArchitecture #SwiftUI

SwiftUI iOS 18 신기능: @Entry 매크로로 커스텀 EnvironmentValues 한 줄로 정의하기

까칠코더 — Wed, 5 Aug 2026 10:05:54 +0900

SwiftUI iOS 18 신기능: @Entry 매크로로 커스텀 EnvironmentValues 한 줄로 정의하기

iOS 18부터 SwiftUI의 EnvironmentValues 확장 방식이 크게 단순화되었습니다. 기존에는 뷰 계층 구조 전체에 전달할 커스텀 환경 변수를 정의하기 위해 EnvironmentKey 프로토콜을 선언하고 getter와 setter 연산 프로퍼티를 일일이 작성해야 했습니다. iOS 18에 새롭게 도입된 @Entry 매크로를 사용하면 이러한 보일러플레이트 코드 없이 선언적으로 환경 변수를 작성할 수 있습니다. 기존 방식과의 코드 구조 비교 및 실무 적용 패턴은 다음과 같습니다.

1. 기존 EnvironmentKey 정의 방식의 불편함

iOS 18 이전에는 커스텀 키를 선언하기 위해 커스텀 타입을 정의한 후, EnvironmentValues에 연산 프로퍼티를 연결하는 장황한 코드가 필요했습니다.

// 1. EnvironmentKey 프로토콜을 구현하는 타입 생성
private struct CustomThemeKey: EnvironmentKey {
    static let defaultValue: String = "Light"
}

// 2. EnvironmentValues 확장 및 getter/setter 구현
extension EnvironmentValues {
    var customTheme: String {
        get { self[CustomThemeKey.self] }
        set { self[CustomThemeKey.self] = newValue }
    }
}

이 방식은 단 하나의 커스텀 환경 변수를 추가하기 위해서도 불필요한 전용 struct와 키 매핑 구문을 매번 새로 작성해야 하는 보일러플레이트(Boilerplate) 문제가 있었습니다.

2. iOS 18+ @Entry 매크로를 활용한 한 줄 선언

iOS 18에서는 @Entry 매크로가 도입되어 EnvironmentValues 확장 내부에 기본값(Default Value)과 함께 변수를 선언하는 것만으로 키 생성과 Accessor 매핑이 자동 완료됩니다.

// iOS 18+ @Entry 매크로 적용 방식
extension EnvironmentValues {
    @Entry var customTheme: String = "Light"
}

보일러플레이트 제거: 별도의 EnvironmentKey 타입을 만들지 않아도 컴파일러가 매크로를 통해 전용 키 타입 및 연산 프로퍼티를 자동 생성합니다.
기본값 지정: 변수 선언 시 할당한 초깃값이 환경 변수의 기본값(defaultValue)으로 자동 지정됩니다.

3. 커스텀 EnvironmentValues 정의 및 뷰 적용 실무 예제

@Entry 매크로로 정의한 커스텀 환경 변수는 기존과 동일하게 .environment() 수정자 및 @Environment 프로퍼티 래퍼를 사용해 뷰 계층에 적용할 수 있습니다.

import SwiftUI

// 1. 커스텀 환경 변수 선언
extension EnvironmentValues {
    @Entry var userRole: String = "Guest"
}

// 2. 하위 뷰에서 환경 변수 읽기
struct ProfileView: View {
    @Environment(\.userRole) private var userRole

    var body: some View {
        Text("현재 사용자 권한: \(userRole)")
    }
}

// 3. 상위 뷰에서 커스텀 환경 변수 주입
struct ContentView: View {
    var body: some View {
        ProfileView()
            .environment(\.userRole, "Admin")
    }
}

4. 기존 방식 vs @Entry 매크로 비교 요약

구분	기존 방식 (iOS 17 이하)	@Entry 매크로 방식 (iOS 18+)
코드 구조	EnvironmentKey 타입 선언 + EnvironmentValues 확장	EnvironmentValues 확장 내 @Entry 선언
작성 코드량	최소 8~10줄 이상	단 1줄
기본값 설정	EnvironmentKey.defaultValue에 명시	변수 초깃값 할당으로 자동 지정
가독성 및 유지보수	불필요한 전용 struct 타입 양산	선언 직관성 대폭 향상

(출처: Apple Developer Documentation - EnvironmentValues & @Entry)

5. 핵심 요약

iOS 18의 @Entry 매크로는 SwiftUI 환경 변수 작성 시 반복되던 보일러플레이트 코드를 단 한 줄로 축소하여 뷰 계층 간 상태 전달 코드의 가독성과 개발 생산성을 획기적으로 향상시킵니다.

#SwiftUI #iOS18 #Entry매크로 #EnvironmentValues #EnvironmentKey #SwiftUI신기능 #WWDC #Swift매크로 #iOS개발자

우리나라 AI 정책의 두 축: 소버린 AI(자주적 AI) 및 모두의 AI 핵심 개념 정리

까칠코더 — Wed, 5 Aug 2026 09:51:07 +0900

우리나라 AI 정책의 두 축: 소버린 AI(자주적 AI) 및 모두의 AI 핵심 개념 정리

글로벌 인공지능 패권 경쟁이 심화됨에 따라 대한민국 정부와 기술 생태계는 '소버린 AI(Sovereign AI)'와 '모두의 AI'를 핵심 국가 전략으로 추진하고 있습니다. 소버린 AI는 해외 빅테크에 대한 디지털 종속을 막기 위한 기술적 자주권 확보를 의미하며, 모두의 AI는 인공지능의 혜택을 전 국민이 누릴 수 있도록 접근성을 보장하는 정책적 방향성을 뜻합니다. 두 정책의 세부 개념과 차이점은 다음과 같습니다.

1. 소버린 AI(Sovereign AI)의 정의와 필요성

빅테크 기술 종속 방지와 데이터 주권 확보

정의: 소버린 AI는 외국의 빅테크 기업(OpenAI, Google, Microsoft 등)의 클라우드나 API에 완전히 의존하지 않고, 자국의 데이터, 인프라, 인재, 기술 모델을 통해 독자적인 인공지능 생태계를 통제하는 역량을 의미합니다.
필요성: 국가 안보 관련 민감 정보 및 산업 데이터의 해외 유출을 방지하고, 특정 국가나 기업의 수출 규제 및 서비스 가격 정책 변화에 따른 종속 리스크를 차단하기 위함입니다.

소버린 AI의 핵심 3요소

데이터 주권: 국내 행정, 의료, 금융 등 보안 데이터가 해외 서버를 거치지 않고 국내 데이터센터 내에서 안전하게 보호 및 처리됩니다.
운영 주권: AI 모델의 학습, 자체 파인튜닝, 에이전트 배포 등 전체 운영 프로세스를 국내 법률 및 기술적 경계 안에서 자율 통제합니다.
문화·언어 주권: 한국어 고유의 어휘와 역사, 사회적 맥락 및 법적 규범을 정확히 이해하는 독립된 초거대 언어모델(LLM)을 보유합니다.

2. 모두의 AI 정책의 주요 개념과 목표

AI 디지털 격차 해소 및 보편적 접근권 제공

정의: 모두의 AI는 인공지능 기술이 특정 대기업이나 일부 전문가만의 소유가 되지 않고, 소상공인, 중소기업, 일반 국민 누구나 자유롭게 활용할 수 있도록 지원하는 공공적 정책 체계입니다.
추진목적: 디지털 격차가 AI 활용 격차로 이어지는 사회적 불평등을 방지하고 국가 차원의 AI 활용 역량을 동반 상향하는 것을 목표로 합니다.

국민 1인 1 공공 AI 에이전트 서비스 활용

보편적 접근 지원: 국산 AI 서비스 이용 바우처 및 저비용 AI 인프라를 제공하여 일반 이용자의 진입 장벽을 낮춥니다.
공공 서비스 연계: 복지 지원금 안내, 청년 주택 지원, 취업 및 행정 절차 신청을 대신 처리해 주는 공공 지능 기반의 '공공 AI 에이전트' 서비스를 구축합니다.

3. 소버린 AI vs 모두의 AI 비교 요약

구분	소버린 AI (Sovereign AI)	모두의 AI (AI for All)
정책 목표	해외 종속 방지 및 기술·데이터 주권 확보	AI 접근성 보장 및 국민 보편적 혜택 제공
주요 대상	AI 반도체, 데이터센터, 자국산 LLM 개발사	일반 국민, 소상공인, 중소기업, 공공기관
핵심 요소	데이터 레지던시, 자국 데이터, 독립 인프라	공공 AI 에이전트, AI 바우처, 보편적 복지
역할 및 관계	독자적 AI 기술 생태계 구축 (인프라)	기술의 사회적 보급 및 대중화 (활용)

(출처: 과학기술정보통신부 정책 브리핑, 정보통신산업진흥원 기술 보고서)

4. 핵심 요약

대한민국의 AI 전략은 인프라와 데이터의 기술적 자주권을 확보하는 '소버린 AI'와 이를 전 국민의 일상 속에 보급하여 활용 가치를 극대화하는 '모두의 AI'가 상호보완적 두 축을 이루고 있습니다.

#소버린AI #모두의AI #AI주권 #SovereignAI #인공지능정책 #과학기술정보통신부 #국산LLM #AI에이전트 #AI인프라 #디지털격차

2026년 근로장려금 소득 기준 완화 및 최대 지급액(180~360만 원) 인상 총정리

까칠코더 — Wed, 5 Aug 2026 09:46:14 +0900

2026년 근로장려금 소득 기준 완화 및 최대 지급액(180~360만 원) 인상 총정리

기획재정부가 2026년 8월 3일 발표한 '2026년 세제개편안'에 따르면, 저소득 가구의 근로 의욕을 고취하고 소득 지원을 강화하기 위해 근로장려금(EITC)의 소득 요건이 완화되고 최대 지급액이 상향 조정됩니다. 개편안에 따른 단독, 홑벌이, 맞벌이 가구별 소득 기준 및 지급액 변경 사항은 다음과 같습니다.

1. 2026년 근로장려금 가구 유형별 소득 요건 완화 기준

근로장려금 수급 대상 확대를 위해 가구 유형별 연간 총소득 기준 금액이 상향 조정되었습니다.

단독가구: 기존 연 2,200만 원 이하에서 연 2,600만 원 이하로 기준이 완화됩니다.
홑벌이가구: 기존 연 3,200만 원 이하에서 연 3,700만 원 이하로 기준이 완화됩니다.
맞벌이가구: 기존 연 3,800만 원 이하에서 연 5,200만 원 이하로 소득 한도가 대폭 상향 조정됩니다.

2. 가구 유형별 최대 지급액 인상 내역

소득 기준 완화와 함께 가구 유형별 최대 지급 금액도 확대됩니다.

단독가구: 최대 지급액이 현행 165만 원에서 180만 원으로 15만 원 인상됩니다.
홑벌이가구: 최대 지급액이 현행 285만 원에서 310만 원으로 25만 원 인상됩니다.
맞벌이가구: 최대 지급액이 현행 330만 원에서 360만 원으로 30만 원 인상됩니다.

3. 2026년 근로장려금 개편 전후 비교

구분	가구 유형	개편 전 기준	개편 후 기준 (2026년 세제개편안)
총소득 기준 요건	단독가구	2,200만 원 이하	2,600만 원 이하
	홑벌이가구	3,200만 원 이하	3,700만 원 이하
	맞벌이가구	3,800만 원 이하	5,200만 원 이하
최대 지급액	단독가구	165만 원	180만 원
	홑벌이가구	285만 원	310만 원
	맞벌이가구	330만 원	360만 원

(출처: 기획재정부 2026년 세제개편안 보도자료, 대한민국 정책브리핑)

4. 핵심 요약

2026년 근로장려금 개편안은 소득 한도를 넓혀 수급 대상을 확대하고, 가구별 최대 지급액을 최대 360만 원까지 상향하여 서민 및 저소득 가구의 가계 소득 보전을 목표로 합니다.

#근로장려금 #2026근로장려금 #근로장려금소득기준 #근로장려금지급액 #근로장려금신청 #세제개편안 #기획재정부 #서민지원정책

자취 직장인 필수 확인: 2026년 월세 세액공제 한도 및 맞벌이 부부 공제 개편

까칠코더 — Wed, 5 Aug 2026 09:44:42 +0900

자취 직장인 필수 확인: 2026년 월세 세액공제 한도 및 맞벌이 부부 공제 개편

기획재정부가 2026년 8월 3일 발표한 '2026년 세제개편안'에는 무주택 서민 및 청년층의 주거비 부담을 완화하기 위한 월세 세액공제 한도 확대와 맞벌이 부부의 주택 임차자금 공제 개선안이 포함되었습니다. 주거비 세제 혜택의 주요 변경 내용을 정리합니다.

1. 월세 세액공제 연간 한도 상향 (1,000만 원 → 1,200만 원)

월세 세액공제의 적용 대상이 되는 연간 월세 지불액 한도가 상향 조정됩니다.

공제 한도 확대: 현행 연간 1,000만 원 한도에서 연간 1,200만 원으로 공제 한도가 200만 원 확대됩니다.
절세 효과: 월세 지출이 많은 세입자의 경우, 확대된 한도에 따라 소득공제 감면 혜택을 추가로 받을 수 있습니다.

2. 청년 세액공제율 17% 우대 적용 조건

청년층의 주택 임차 부담을 줄이기 위해 소득에 따른 공제율 차등 구분을 단순화하고 공제율을 우대 적용합니다.

청년층 우대 적용: 총급여 및 종합소득 수준과 관계없이 청년 수급자에 대해 17%의 세액공제율을 적용합니다.
혜택 적용 대상: 만 19세 이상 만 34세 이하의 무주택 청년 세입자가 대상입니다.

3. 맞벌이 부부 임차대출 중복 소득공제 허용

직장이나 근무지 사유로 따로 거주하는 무주택 맞벌이 부부에 대한 세제 불이익이 개선됩니다.

각자 공제 허용: 주거지가 분리된 무주택 맞벌이 부부의 경우, 각자 명의로 받은 전세자금 대출(주택임차차입금) 원리금 상환액에 대해 부부 각각 소득공제를 신청할 수 있습니다.
결혼 페널티 해소: 기존 1세대 1공제 제한으로 인해 발생하던 페널티를 완화하여 실질적인 주거비 부담을 줄입니다.

4. 월세 세액공제 및 주거 세제 개편 전후 비교

구분	개편 전	개편 후 (2026년 세제개편안)
월세 세액공제 연 한도	1,000만 원	1,200만 원
청년층 공제율	소득 구간에 따라 15% / 17% 차등	청년 소득 무관 17% 우대 적용
맞벌이 부부 임차대출 공제	1세대 내 1인만 신청 가능	별거 맞벌이 부부 각자 명의 공제 인정

(출처: 기획재정부 2026년 세제개편안 보도자료, 대한민국 정책브리핑)

5. 핵심 요약

2026년 주거 세제 개편안은 월세 세액공제 한도를 1,200만 원으로 확대하고 청년 공제율을 17%로 고정 우대하며, 별거 맞벌이 부부의 전세대출 중복 공제를 허용하여 주거비 절세 혜택을 대폭 강화했습니다.

#월세세액공제 #2026세제개편안 #월세공제한도 #청년월세공제 #맞벌이부부전세대출 #주택임차차입금 #연말정산월세 #기획재정부

Xcode 27 / Swift 6.3 SPM 동적 라이브러리(Dynamic Framework) 링킹 충돌 원인과 해결 방법

까칠코더 — Tue, 4 Aug 2026 10:25:22 +0900

Xcode 27 / Swift 6.3 SPM 동적 라이브러리(Dynamic Framework) 링킹 충돌 원인과 해결 방법

Xcode 27 및 Swift 6.3 환경에서 Swift Package Manager(SPM)를 통해 외부 라이브러리를 추가하거나 멀티 모듈 프로젝트를 구성할 때 duplicate symbol, objc-class-ref, 또는 앱 실행 시 dyld: Library not loaded 링킹 에러가 발생하는 사례가 증가하고 있습니다. 이는 메인 앱 타깃과 확장 타깃(Widget, Notification Service Extension 등)이 동적 라이브러리를 중복 링킹하면서 발생하는 구조적 문제입니다.

Static vs Dynamic 링킹 방식 및 Xcode 27 변경점

SPM 패키지의 Package.swift에서 라이브러리 타입을 명시하지 않으면 기본적으로 Static 형태로 빌드됩니다. 그러나 해당 라이브러리를 메인 앱과 앱 익스텐션 타깃 모두에서 참조할 경우 Xcode 27 빌드 시스템에서 링킹 충돌이 발생합니다.

구분 Static Library (.static) Dynamic Framework (.dynamic)

바인딩 시점	컴파일/빌드 타임에 바이너리에 포함	앱 실행 시(Runtime) 동적 로딩
다중 타깃 참조 시	각 타깃 바이너리마다 코드 중복 복사 발생	메인 앱 바이너리에 1회 임베드 후 공유
대표 발생 에러	Duplicate symbol _OBJC_CLASS_$_...	dyld: Library not loaded / Image Not Found
Xcode 27 권장	단일 타깃 전용 라이브러리	메인 앱 + Extension 공통 참조 라이브러리

1. 문제 상황: 다중 타깃 링킹 충돌 에러 패턴

메인 앱 타깃과 위젯 익스텐션 타깃이 동일한 SPM 라이브러리를 각각 링킹하도록 설정되어 있으면 아래와 같은 빌드 및 런타임 오류가 나타납니다.

// 컴파일 타임 에러 예시 (Static 중복 링킹)
error: duplicate symbol '_OBJC_CLASS_$_SharedUtility' in:
    /Users/.../Build/Products/Debug-iphonesimulator/MainApp.o
    /Users/.../Build/Products/Debug-iphonesimulator/WidgetExtension.o

// 런타임 에러 예시 (Dynamic Embed 설정 오류)
dyld[1234]: Library not loaded: @rpath/SharedFramework.framework/SharedFramework
  Referenced from: <UUID> /var/containers/Bundle/Application/.../WidgetExtension
  Reason: tried: '/usr/lib/swift/SharedFramework.framework' (no such file)

2. 해결 방안: SPM 및 Xcode 타깃 링킹 재구성

방안 1: Package.swift 라이브러리 타입 명시적 선언

자체 제작한 모듈이거나 사내 SPM 패키지인 경우 Package.swift 내의 products 정의에서 라이브러리 타입을 .dynamic으로 명시합니다.

// Package.swift
import PackageDescription

let package = Package(
    name: "SharedCore",
    platforms: [.iOS(.v17)],
    products: [
        // type: .dynamic 옵션을 통해 런타임 동적 라이브러리로 빌드 지정
        .library(
            name: "SharedCore",
            type: .dynamic,
            targets: ["SharedCore"]
        ),
    ],
    targets: [
        .target(
            name: "SharedCore",
            dependencies: []
        ),
    ]
)

방안 2: Xcode Build Target의 Embed 설정 최적화

서드파티 오픈소스 SPM 라이브러리(Package.swift 수정이 불가능한 경우)는 Xcode 프로젝트의 Frameworks, Libraries, and Embedded Content 설정을 분리해야 합니다.

메인 앱 타깃 (Main App Target):
- SPM 라이브러리를 추가하고 Embed & Sign으로 설정합니다.
익스텐션 타깃 (Widget / Extension Target):
- 동일한 SPM 라이브러리를 추가하되 Do Not Embed로 지정합니다.
- 이렇게 설정하면 메인 앱 번들에 동적 프레임워크가 1회 포함되고, 익스텐션은 런타임 시 메인 앱의 @executable_path/Frameworks 또는 @loader_path/Frameworks 경로를 통해 해당 라이브러리를 참조합니다.

3. Build Settings 추가 체크리스트

Runpath Search Paths (LD_RUNPATH_SEARCH_PATHS) 확인:
- 익스텐션 타깃의 Build Settings에서 Runpath Search Paths에 다음 경로가 포함되어 있는지 확인합니다.
- @executable_path/Frameworks
- @executable_path/../../Frameworks (App Extension의 메인 프레임워크 탐색 경로)
Other Linker Flags (OTHER_LDFLAGS) 정리:
- 타깃 빌드 옵션에서 불필요하게 명시된 -all_load 또는 -force_load 플래그가 SPM 라이브러리와 중복 링킹을 유발하지 않는지 점검합니다.

핵심 요약

Xcode 27 / Swift 6.3 환경에서 메인 앱과 App Extension이 동일한 SPM 라이브러리를 참조할 때 Static/Dynamic 링킹 설정 미숙으로 충돌이 발생합니다.
메인 앱과 익스텐션에서 동시 참조하는 라이브러리는 Dynamic 형태로 구성해야 합니다.
메인 앱 타깃에는 Embed & Sign을 지정하고, 익스텐션 타깃에는 Do Not Embed로 설정하여 런타임 참조 공유 방식을 적용합니다.

#Xcode27 #Swift6_3 #SPM #SwiftPackageManager #DynamicFramework #LinkerError #iOS개발 #Xcode트러블슈팅

2026년 부동산 세제 개편안 핵심 정리: 종부세·양도세 기준 및 주요 변경 사항

까칠코더 — Tue, 4 Aug 2026 10:21:59 +0900

2026년 부동산 세제 개편안 핵심 정리: 종부세·양도세 기준 및 주요 변경 사항

기획재정부가 2026년 8월 3일 발표한 '2026년 세제개편안'에 따르면, 부동산 세제 산정 기준이 기존의 '주택 수' 중심에서 '주택 가액' 및 '실제 거주 여부' 중심으로 전면 개편됩니다. 주요 개편 내용은 종합부동산세(종부세) 공제 확대 및 세율 단순화, 양도소득세(양도세) 장기보유특별공제의 거주 요건 강화입니다.

1. 종합부동산세(종부세) 주요 개편 내용

1세대 1주택자 기본공제 상향

기본공제액 조정: 1세대 1주택 실거주자의 종부세 기본공제 금액이 현행 공시가격 12억 원에서 14억 원(시가 기준 약 20억 원 상당)으로 상향 조정됩니다.
과세 대상 축소: 시가 20억 원 이하의 1세대 1주택 보유자는 종부세 과세 대상에서 제외됩니다.

다주택자·비거주 주택 및 세율 체계 개편

비거주·다주택자 기본공제: 비거주 주택 및 다주택자의 기본공제는 현행 9억 원(시가 기준 약 13억 원)으로 유지됩니다.
주택 수 차등 세율 폐지: 기존에 보유 주택 수에 따라 구분되던 중과세율 체계가 폐지되며, 주택 수와 상관없이 주택 가액 합산액을 기준으로 세율이 일원화됩니다.
초고가 주택 과세 강화: 시가 40억~50억 원을 초과하는 초고가 주택에 대해서는 구간별 과세 표준 세율이 강화됩니다.

거주 기간 중심 세액공제 전환

공제 체계 개편: 기존 보유 기간 중심의 세액공제 체계가 거주 기간 중심으로 단계적 전환됩니다.
시행 시기: 2028년부터는 보유 기간 공제가 축소되고, 실제 거주 기간에 따른 세액공제(최대 50%) 위주로 적용됩니다.

2. 양도소득세 주요 개편 내용

비거주 기간 장기보유특별공제 배제

거주 요건 미충족 시 공제 제한: 주택 보유 기간이 길더라도 실제 거주하지 않은 기간에 대해서는 장기보유특별공제 적용이 배제됩니다.
투자 목적 보유 과세 강화: 실거주하지 않는 1주택 또는 다주택 보유자의 양도소득세 부담이 증가합니다.

1세대 1주택자 실거주 공제 유지

실거주자 혜택 보존: 1세대 1주택자가 10년 이상 보유 및 실거주를 충족할 경우 현행과 동일하게 최대 80%의 장기보유특별공제율이 그대로 유지됩니다.

3. 부동산 세제 개편 전후 주요 내용 비교

구분	개편 전	개편 후 (2026년 세제개편안)
과세 핵심 기준	주택 수 중심	주택 가액 및 실거주 여부 중심
종부세 1주택 기본공제	공시가격 12억 원 (시가 약 17억 원)	공시가격 14억 원 (시가 약 20억 원)
종부세 다주택 기본공제	공시가격 9억 원	공시가격 9억 원 (유지)
종부세 세율 구조	주택 수에 따른 차등 중과세	주택 가액 기준 일원화 (단, 초고가주택 강화)
종부세 세액공제	보유 기간 + 거주 기간 (최대 80%)	거주 기간 중심으로 단계적 전환 (2028년~)
양도세 장기보유특별공제	보유 기간별 공제 인정	비거주 기간 공제 배제 (실거주 10년 시 80% 유지)

(출처: 기획재정부 2026년 세제개편안 보도자료, 대한민국 정책브리핑)

4. 핵심 요약

2026년 부동산 세제 개편안은 실거주 목적의 1세대 1주택자에 대한 세제 부담을 완화하는 동시에, 비거주 주택 및 초고가 주택에 대한 과세를 강화하여 실거주 중심의 시장 구조 유도를 목표로 합니다.

#부동산세제개편 #종합부동산세 #종부세기본공제 #양도소득세 #장기보유특별공제 #1세대1주택 #기획재정부 #부동산세금 #2026세제개편안 #실거주요건