Let'Swift 2025 짤막한 후기

올해는 못 갈 줄만 알았던 iOS 행사를 회사 팀원 분의 좋은 기회를 받아 다녀올 수 있었습니다.(오거나이저 만세!)

 

오랜만에 아카데미 분들도 봐서 좋았고, 무엇보다 다시금 iOS에 대한 열정의 기억을 되살릴 수 있었습니다. 사이드 프로젝트도, 디자인도, 완전히 다른 것도 재밌는게 많지만 제겐 역시 iOS 개발이 제일 재밌는 것 중에 하나이니까요.

 

작년에 비해 스스로 넣는 인풋량은 많이 부족하지만(그만큼 다른걸 많이 채우고 있다 생각하지만) 외적으로 주입되는 인풋량은 더 많아짐을 느끼곤 합니다. 처음 들었던 컨퍼런스에선 거의 모든 내용을 이해할 수 없었지만 지금은 고개를 끄덕거릴 정도는 되었습니다 ㅎㅎ

 

열심히 준비해 좋은 기회 주신 회사 동료 분께 다시 한번 감사 인사 드립니다 😇 (다들 너무 고생 많으심,,, 늘 응원합니닷)

 

컨퍼런스 내용 간단 정리

AI 친화적 코드베이스: 중대규모 코드베이스에서 AI 에이전트 활용도 높이기

• Claude 코드 기반 설명.
• 관련 없는 맥락이 인풋으로 들어가면 답변의 질이 떨어짐 → 컨텍스트 부패
• Why? 1 → 문자열 리터럴 충돌 → 동일 함수/클래스명으로 인한 혼란
• Why? 2 → Claude의 Read 방법 → 필요한 부분을 동적으로 로드하기 때문에 전체 파일 읽어야 함
• 해결 시도 1 → Claude의 Read 방법을 바꿔주는 Claude Context MCP 사용 → 토큰 사용량 및 호출 횟수 최적화
• 해결 시도 2 → Smart Compact 기법 사용 → 각 단계별 요약 문서(project.md 등) 생성 → 관련 없는 코드베이스 탐색 및 요약을 줄여줌
• 하지만 2가지 방식 모두 완전히 컨텍스트 부패를 막을 수는 없었음,,, → 이를 위해 코드베이스에서의 수정이 필요하다 느낌
• 코드베이스 수정 1 → Layer Based 폴더링이 아닌, Feature Based 폴더링 채택 → Claude의 파일 탐색을 더 정확하고 빠르게 해줌.(회사 프로젝트도 폴더링 개선이 필요해 보임 인간에게나 AI에게나 필요해보임)
• 코드베이스 수정 2 → 단일 책임 File 구조(SuperFile 지양) → 전체 파일을 읽으려 하기 때문에 이를 막아줌 → 프로토콜 및 구현체의 파일을 적절히 분리할 수 있음.

 

CGAffineTransform으로 화면 렌더링 이해도 올리기

• 안타깝게도 transform(x: 0, y: -1) 하면 뒤집어 진다,,, 까지 이해했음(?)
• CGAffineTransform이 어떻게 이런 단순한 값으로 좌표를 표현하는지에 대한 수학적 설명이 주된 내용이었음.(벡터, 행렬 등)

 

SwiftUI로 디자인시스템 약간 오버 엔지니어링 설계하기(feat: OOP)

• 디자인 시스템을 설계하기 위해 각 컴포넌트 내 공통되는 디자인 요소, variation 등을 분석하는 과정이 선행됨.
• 이후에는 protocol을 이용해 각 요소를 적절히 추상화하고 UIComponent(View)에 적용.
• 연사자 분이 왜 오버 엔지니어링이라고 제목을 붙이셨는지 공감이 감,,,(개인적으로는 만들어진 컴포넌트에서 수정이나 추가가 거의 적을 것이라 판단해 하나의 View에 다양한 속성을 받을 수 있게 생성자를 만들고 기본값을 부여해 적당한 리소스로 관리 가능한 컴포넌트를 구현했을 것 같음)
• 마지막에 연사자 분도 프로젝트의 맥락과 필요에 따라 선택이 필요하다고 언급해주셨음.
• 특히 디자이너 분들과의 적극적인 소통이 필요하다는 말이 가장 인상 깊었음.(진짜 제일 중요한듯!!!)

 

모놀로식에서 모듈화로, 그 중간 어딘가

• 모듈화는 왜 하는가? → 생산성 및 효율 증가 / 도메인 분리 / 의존성 및 재사용성 관리 / 빌드 시간 최적화 / 데모 앱
• 연사자 분 팀의 모듈화에서의 목표 → 한번에 큰 변화가 아닌, 점진적인 개선으로 모듈화 진행하기(모듈화 진행 중에도 안정적인 서비스를 유지하고, 영향 범위를 크게 만들지 않아 팀원의 부담을 줄이는 방향성)
• How? → 모듈 분리 부터 하려 하지 말고 메인 앱의 적절한 의존성 분리부터 선행(그래야 모듈화가 더 수월해짐)
• 점진적 방법 1 → 저수준 레이어(Core) 부터 의존성 분리하기 → 이후 다른 객체, 레이어와의 의존성 분리의 토대가 될 것.
• 점진적 방법 2 → DI Container를 이용해 간접적으로 의존성 분리(최종 목표는 DI Container도 걷어낼 수 있어야 함, 점진적인 개선을 위한 방편) → 순환 의존성을 간접적으로 느슨하게 만들어줄 수 있음
• 어느 정도 메인 앱의 의존성 분리가 됐을 때 Component(UI) 모듈을 만들었음. → 최종적으로 각 Feature 모듈을 여러 개 만들어 데모 앱을 만드는 게 목표인데, 이를 위핸 토대가 Component 이기 때문.
• Component 모듈을 만들어서 스토리북(모든 팀원들이 보고 참고할 수 있는 UI 컴포넌트의 집합 데모 앱 같은 느낌)으로 QA 영향 범위를 파악하고, 컴포넌트 재사용률을 높일 수 있음.
• 이 때 활용할 수 있는 좋은 툴이 Uber에서 만든 snapshot-test-case 라이브러리.
• 연사자 분 팀에서는 PR의 diff를 토대로 PR의 스냅샷, develop 브랜치의 스냅샷을 만들고 이를 비교해 다른 점이 발생했을 때의 차이를 스크린샷으로 정리해주는 액션을 만들어 영향 범위를 효과적으로 파악할 수 있게 만들었음.
• 회사 프로젝트에서도 모듈화를 조금씩 진행 중인데 지금처럼 새롭고 작은 기능은 모듈로 나눠가면서도, 메인 앱의 코드 의존성을 점진적으로 개선해나갈 수 있는 액션 아이템을 만들 수 있으면 좋겠다고 생각했음.
• tmi) 카카오 스타일스의 '지그재그' 팀의 이야기였음!

 

Modern Network와 WebSocket

• iOS 26에서는 WebSocket을 더 Modern하게 사용할 수 있도록 새로운 API가 이것저것 추가되었음.
• 특히 SwiftUI의 ResultBuilder 패턴 처럼 WebSocket을 쉽고 직관적으로 생성할 수 있는 방법도 추가됨!
• 개인적으로 Networking, WebSocket 등에 대한 기본 지식이 부족하다 느껴 이 부분은 추후 탄탄히 쌓아보도록 공부가 필요함.(조만간 찜해둔 Network 기본기 인프런 강의 완강하기)

 

Swift 개발자를 위한 온디바이스 AI LLM

• Apple Intelligence → 온디바이스 LLM → OS 내장이기 때문에 앱 용량 증가 X
• Apple Intelligence의 장점: 요약 / 정보 추출 / 텍스트 분류 / 간단한 QA / 작은 Context에서의 작업
• Apple Intelligence의 약점: ChatGPT, Gemini 등 대비 지식 부족, 복잡한 추론 능력 부족, 아직은 부족한 한글 능력,,
• 모델 사용 전 필수 체크! 기기가 Intelligence를 지원하는가?(iPhone 15 Pro 이상) / 사용자가 기기에서 '온디바이스 Siri 및 탐색' 기능을 활성화 했는가? / 모델이 다운로드 되었는가?
• LanguageModelSession? AFM(Apple Foundation Model)의 핵심 객체 → Swift 코드에서 요 객체로 다양한 동작 가능
• 핵심 꿀팁 1 → 모델 사용 전 사전 예열로 성능 최적화(session.prewarm) → 첫 응답 지연 감소 / 최적 호출 시점
• 핵심 꿀팁 2 → Playground 매크로로 AFM 테스트(#Playground) → SwiftUI Preview와 비슷하게 여러가지 LLM 요청 결과 확인
• 사용법 1 → AFM 기본 응답 생성하기 → session.responde(to:) → 여기서 파라미터로 들어가는 GenerationOption 값에 따라 응답 전략(창의적 결과, 일관성, 조정 등), 표현의 다양성(신뢰도, 창의성 등)을 바꿔줄 수 있음
• AFM 응답 생성 시 오류 발생 케이스 → 유해, 민감 콘텐츠 / 예측 불가능한 출력 / 의도된 역할 이탈 / 구조화된 출력 위반 / 지원되지 않는 언어 등 → 이에 대한 에러 처리 적극 권장!
• 사용법 2 → session.streamResponse()를 통해 비동기 스트리밍 작업 시작 → 각 출력 값을 바인딩 된 변수에 누적해줄 수 있음.
• 사용법 3 → Guided Generation(유도 생성) → 개발자가 정의한 Swift 타입(구조체, 열거형)에 맞춰 모델이 엄격한 형식의 출력을 생성하도록 유도 → 별도의 파싱 없이 Type-Safe한 Swift 객체를 즉시 얻을 수 있음 → @Generable, @Guide 매크로 활용
• 사용법 4 → Tools(모델의 손발) → 모델이 스스로 외부 코드(Swift 함수)를 호출해 정보를 얻거나 특정 행동을 수행하게 만드는 기능 → Tool Calling 또는 Function Calling이라고도 함. → RAG(검색 증강 생성) 구현, 앱의 액션(DB에 새 정보를 쓰거나, 외부 API를 호출하는 등)을 호출하는데도 활용 가능.
• 요걸 활용해볼 다양한 아이디어? 게임 NPC 랜덤 대사 생성 / 사용자 입력 기반 여행 일정 자동 생성 / 온디바이스 개인 맞춤형 비서 등
• 복잡한 작업이 어렵고 한국어에 약해 맛있게 써먹기는 어렵겠지만 분명 온디바이스의 장점을 살려 여러가지 시도를 해볼만 할 것 같다고 느꼈다.(회사 프로젝트든, 개인 프로젝트든 어쨌든 무료로 다양한걸 해볼 수 있다는데 해볼만 하지 않을까?)