iOS 기술 블로그 최신 글

우리의 iOS 인앱 결제 불법 환불을 막기 위한 시도

안녕하세요 SpoonLabs 에서 Business Platform Team 백엔드 서버 개발을 맡고있는 Joe(원주호) 입니다. 저는 iOS 앱의 주 수익원인 인앱 결제에 관해서 이야기를 하려고 합니다. 인앱 서비스 느낌? iOS 인앱 결제에 대해 먼저 이야기 해보자 iOS 앱에서 유료 콘텐츠를 판매하려면 대부분 Apple의 인앱 결제(In-App Purchase)를 사용하게 됩니다. 이건 단순히 결제 수단 하나를 붙이는 문제라기보다, 결제와 환불, 그리고 그 이후의 모든 흐름을 Apple의 시스템 안으로 맡기는 선택 입니다. 사용자가 앱에서 상품을 선택하고 결제를 누르면, 실제로 돈이 오가는 순간은 서비스가 아니라 Apple App Store에서 일어납니다. 결제 승인, 카드 정보 처리, 영수증 발급까지 모두 Apple의 책임이며, 서비스는 그 결과를 받아서 “이 사용자가 무엇을 샀는지”를 확인하고 구매에 대한 서비스내 재화를 지급하는 역할을 맡습니다. 조금 더 보태어 말하면, 앱 서비스 제공자는 결제를 직접 처리하지 않습니다. 대신 Apple이 “결제는 완료됐다”고 알려주면, 그 말을 믿고 아이템을 지급하거나 구독 권한을 열어주는 구조입니다. 결제 흐름은 어떨까? 흐름 자체는 복잡하지 않습니다. 앱 접속 - 결제 상품 선택 - iOS가 익숙한 App Store 결제 화면 노출 - 결제 끝 (Apple 의 영수증을 발급) 그 다음 부터가 서비스의 역할입니다. 이 영수증 (또는 결제 주문번호 등)을 서버에서 검증하고, 문제가 없으면 해당 사용자에게 구매 상품에 대한 아이템 또는 권한을 제공합니다. 여기까지 보면 꽤 깔끔한 구조처럼 보입니다. 사용자는 안전하게 결제할 수 있고, 서비스는 민감한 결제 정보를 직접 다루지 않아도 됩니다. Apple이 제공하는 이 구조 덕분에 iOS 결제 경험이 일관되게 유지되는 것도 사실입니다. 하지만 결제와 관련된 모든 최종 결정권은 Apple이 가진다는 점입니다. 서비스는 결제를 승인하거나 거절할 수 없고, 환불 역시 서비스가 아니라 Apple의 정책에 따라 처리됩니다. 사용자가 환불을 요청했는지, 어떤 사유로 승인되었는지조차 서비스 입장에서는 알기 어려운 경우가 많습니다. 이건 단순한 기술적 제약이라기보다, Apple이 사용자 경험과 소비자 보호를 최우선에 두고 설계한 결과에 가깝습니다. 사용자는 앱마다 환불 정책을 찾아다닐 필요 없이 Apple 계정 하나로 결제 내역과 환불을 관리할 수 있고, 문제가 생기면 서비스가 아니라 Apple에 바로 요청할 수 있습니다. 그럼 진짜 문제는 무엇인가? 진짜 문제는 Apple 이 제공하는 IAP 시스템을 악용하는 유저가 존재한다는 것입니다. 사용자 아이템 구매 후 전부 소진 상태 이후 서비스에 어떤 요청도 하지 않은 채, Apple에 직접 인앱 결제 환불을 요청하는 상황입니다. 그리고 이 환불은 Apple 기준으로는 정상적인 절차입니다. 문제는 그 환불이 처리되는 동안, 혹은 처리된 이후에도 서비스는 그 사실을 즉시 알지 못할 수 있다는 점입니다. 환불은 끝났는데, 사용자는 여전히 아이템을 쓰고 있고, 구독 권한도 살아 있고, 서비스는 아무 일도 없었다는 듯 정상적으로 리소스를 제공합니다. 사용자 입장에서는 환불을 받았고, Apple 입장에서도 정책에 맞게 처리했다. 하지만 서비스 입장에서는 그제야 질문이 생깁니다. “이 상황을 언제, 어떻게 알아야 했을까?” 환불을 “알 수 있는” 거의 유일한 방법 이 질문에 대한 답을 찾다 보면, 결국 하나의 기능으로 수렴하게 됩니다. 바로 App Store Server Notifications입니다. Apple은 인앱 결제와 관련된 주요 상태 변경이 발생했을 때, 해당 이벤트를 서버 간 통신 방식으로 전달해주는 기능을 제공하는데 결제 완료, 구독 갱신, 해지, 그리고 우리가 관심을 가질 수밖에 없는 환불 관련 이벤트 역시 여기에 포함이 됩니다. 중요한 점은, 이 알림이 앱으로 오는 것이 아니라 서비스 서버로 직접 전달된다는 것입니다. 즉, 환불을 포함한 결제 상태 변화는 “사용자가 앱을 실행했을 때”가

ODW #3: MCP 서버를 안전하게 활용해 개발 효율 높이기

안녕하세요. LY Corporation의 aikawa입니다. Yahoo! 지도 및 Yahoo! 환승 안내 iOS 앱 개발을 담당하고 있고, iOS 영역의 Developer Rela...

제품을 깊이 이해하고, 치열하게 만들어갑니다— iOS Engineer

리멤버 iOS의 SwiftUI 도입기 — 허들을 하나씩 넘기며

리멤버 iOS의 SwiftUI 도입기 — 허들을 하나씩 넘기며 Hurdle Between Remember And SwiftUI 안녕하세요, 리멤버 iOS챕터 허성진입니다. SwiftUI, 도입하셨나요? 새 프로젝트라면 이미 자연스러운 선택이 되었지만, 오래된 UIKit 앱이라면 여전히 어디서부터 시작하지?라는 막막함이 남아있을 수 있습니다. 리멤버는 명함 관리부터 경력직 채용, 직장인 커뮤니티, 그리고 최근 출시된 커넥트 SNS까지 — 일하는 프로들을 위한 비즈니스 네트워크 앱입니다. 2014년 출시 이후 10년이 넘는 시간 동안 서비스를 이어오고 있고, 그만큼 코드베이스의 대부분은 UIKit을 기반으로 구성되어 있습니다. Remember App Store Screenshots 최근 AI 코딩 도구와 Figma MCP 같은 디자인-개발 연동 도구들이 등장하면서 SwiftUI를 써야 할 이유가 더욱 명확해졌습니다. 선언적 스타일의 SwiftUI는 이런 도구들과 훨씬 자연스럽게 맞아떨어지기 때문입니다. 지금은 리멤버 앱에서 SwiftUI를 적극적으로 사용하고 있지만, 여기까지 오는 과정은 결코 단순하지 않았습니다. 이 글에서는 리멤버 iOS챕터가 SwiftUI를 도입하며 마주친 허들들과, 그것을 하나씩 넘겨온 과정을 공유합니다. 위젯이라는 작은 영역에서 시작해 전체 화면을 SwiftUI로 구현할 수 있게 되기까지의 과정을 총 5단계로 나눠 이야기합니다. 1단계. 위젯 — 리스크 없는 첫 시작 Remember Card Camera Widget 가장 간단하게 SwiftUI를 적용해볼 수 있는 곳은 어디일까요? 앱 본체와 완전히 분리된 위젯 Extension이라고 생각합니다. UIKit 코드베이스와 충돌할 일이 없고, 잘못되더라도 앱 본체에 영향을 주지 않습니다. iOS 14에서 WidgetKit이 등장하면서 위젯은 SwiftUI만으로 작성해야 했고, 자연스럽게 SwiftUI를 접하는 첫 창구가 되었습니다. 제가 합류했을 때 이미 커뮤니티 베스트글 위젯이 있었는데요, 2020년 당시 iOS챕터에서 SwiftUI를 써보고 싶어서 만들어진 위젯이라고 전해들었습니다. 거기에 어느 날, 고객 VoC에서 출발한 아이디어이기도 했던 명함 촬영 바로가기 위젯을 개인적인 호기심으로 직접 만들어봤습니다. Remember Card Camera Widget VOC 당시 리더분의 적극적인 지지 덕분에 실제 배포까지 이어졌습니다. Remember Card Camera Widget Making Messages 이미지 하나를 탭하면 명함 촬영으로 바로 연결되는 단순한 위젯이었습니다. 말 그대로 발만 살짝 담가보는 단계였습니다. 그 작은 경험이 SwiftUI와의 첫 개인적인 만남이 되었습니다. Remember iOS Widgets @main struct RememberWidgetBundle: WidgetBundle { var body: some Widget { RememberCardCameraWidget() // 명함 촬영 위젯 RememberCommunityWidget() // 커뮤니티 베스트글 위젯 } } 2단계 . 셀 — UIKit 화면에 SwiftUI 뷰 심기 위젯으로 감을 잡았다면, 다음 질문은 “UIKit기반 위에 SwiftUI를 어떻게 넣을 수 있을까?”였습니다. UIHostingController를 사용하면 된다는 것은 알지만, 실제로 부딪혀보기 전까지는 어디서 어떻게 시작해야 할지 막막했습니다. 2-1. SwiftUI 탐색 — “제 이력서에 ‘SwiftUI 도입’을 작성하고 싶었습니다” 챕터 내에서 SwiftUI 도입에 대한 공감대는 있었습니다. 하지만 저는 SwiftUI를 써본 적이 없었기에 궁금하기도 했고, 직접 써보고 싶다는 마음에 리멤버 iOS 앱의 공지사항 목록 화면을 SwiftUI로 시행착오를 겪으며 만들어봤습니다. 셀을 SwiftUI로 감싸는 시도도 해보고, 전체 화면을 SwiftUI로 만든 다음 VIPER 아키텍처와 연결해보는 시도도 했는데, UIKit과 SwiftUI의 경계를 어디에 그어야 할지 감이 잡히지 않아 어색했

AttributedString 구조로 풀어낸 대규모 iOS 설정 시스템

환경이 바뀌면서 과거에 내렸던 합리적인 결정이 더 이상 유효하지 않게 되는 일은 흔히 생깁니다. 이 글은 LINE 앱이 성장하면서 동적 설정 배포 시스템인 ‘서비스 설정’의 iOS...

크몽 iOS 개발자의 다크모드 지원

안녕하세요. 크몽 iOS 팀 Peggy입니다.😁 드디어 크몽 iOS 앱에서도 다크모드를 사용할 수 있게 되었어요! Press enter or click to view image in full size kmong iOS App 이번 글에서는 다크모드 지원 작업을 진행하면서 겪은 문제와 해결 과정을 간단히 공유해 드리려고 합니다. 문제점 크몽 앱은 UIKit과 SwiftUI를 함께 사용하는 구조로 되어 있습니다. 다크모드 전환 시 대부분의 화면은 디자인 시스템의 컬러셋 덕분에 잘 적용되었지만 UIKit에서 border 색상을 CGColor로 설정한 부분에서 문제가 생겼어요. CGColor는 다이나믹 컬러를 지원하지 않기 때문에 앱 실행 중 라이트 ↔ 다크 모드로 전환하면 이전 모드의 border 색상이 그대로 남는 현상이 있었습니다. 즉, 색상은 바뀌었는데 border만 예전 색으로 유지되는 상황이었죠. 해결 방안 이 문제를 해결하기 위해 border 색상을 동적으로 갱신하는 프로토콜을 만들었습니다. 뷰가 현재 모드의 색상을 기억하고 다크모드 전환 이벤트가 발생할 때, 자동으로 새로운 색상으로 업데이트되도록 했습니다. 특히 iOS 17부터 추가된 registerForTraitChanges API를 활용했는데 이 덕분에 다크모드 전환 이벤트를 보다 간결하게 감지할 수 있었습니다. 이전에는 traitCollectionDidChange를 오버라이드해야 했지만 새로운 API를 사용하면 관심 있는 trait만 선택적으로 구독할 수 있고 코드도 훨씬 깔끔하게 유지할 수 있다는 장점이 있습니다. 마무리 다크모드 지원은 단순히 색을 어둡게 바꾸는 일처럼 보이지만 UIKit과 SwiftUI가 함께 있는 구조에서는 생각보다 다양한 이슈가 숨어 있었습니다. 이번 작업을 통해 뷰 시스템 동작 방식을 더 깊이 이해할 수 있었고 작은 부분 하나하나가 사용자 경험에 큰 영향을 줄 수 있다는 걸 다시 한번 느꼈습니다. 다크모드를 지원하면서 사용자가 실제로 다크모드와 라이트 모드 중 어떤 모드를 더 많이 사용하는지를 확인할 수 있도록 이벤트 트래킹도 추가했습니다. 사용자들이 어떤 환경에서 크몽을 더 자주 이용하는지 살펴보는 과정도 흥미로울 것 같습니다. 앞으로도 크몽 iOS 팀은 더 나은 사용자 경험을 위해 계속 개선해 나가겠습니다. ☺️ Ref. https://developer.apple.com/documentation/uikit/uitraitchangeobservable-67e94/registerfortraitchanges(_:handler:) 크몽 iOS 개발자의 다크모드 지원 was originally published in kmong on Medium, where people are continuing the conversation by highlighting and responding to this story.

하이브리드 앱에 구축하는 iOS 개발자모드

안녕하세요! 올리브영의 iOS Junior Engineer Ted입니다. 저는 오늘, 올리브영 iOS…

iOS 개발자가 올리브영 QA 엔지니어가 되기까지, 5개월간의 리얼 온보딩

iOS 개발자가 올리브영 QA 엔지니어가 되기까지, 5개월간의 리얼 온보딩 안녕하세요! 25년 1월에 CJ올리브영 QA팀 QA 엔지니어로 합류한 구망🐧 입니다. "QA…

iOS 성과 측정, 우리는 이렇게 보정하고 최적화합니다

HLS 기반 숏폼 스트리밍 구현기: iOS/Android 호환성 대응 사례

안녕하세요! 올리브영 리뷰와 커뮤니티 FE개발을 담당하고 있는 뽀야미입니다! 이번 포스팅에서는 커뮤니티 서비스 셔터에 숏폼 콘텐츠를 도입한 전체 과정을 공유드리려고 합니다. 셔터는 올리브영의 SNS…

iOS 개발자를 위한 DocC 실무 튜토리얼

안녕하세요! 올리브영🫒 iOS앱 개발자📱 럭셔Lee 입니다🙇‍♂️ 이번 포스팅에서는 Apple에서 제공하는 문서화 도구, DocC에 대해서 이야기해보고자 합니다. 🤔 일단 DocC가 뭔가요? DocC는 Xcode13부터 지원하는 Apple…

Let'Swift 2024 X 올리브영: 기술과 경험을 나누는 특별한 만남

안녕하세요. 올리브영에서 iOS 개발을 맡고 있는 럭셔Lee입니다. Let'Swift 2024 컨퍼런스에서 올리브영 부스를 운영하며 많은 iOS…

누가 내 쿠키를 먹었을까?

iOS 웹뷰 환경에서 세션쿠키가 소실되는 이유와 해결방법을 알아봅니다.

스위프트 매크로_2탄, 어떻게 쓰는건데요?

지난 글에 이어 이번 포스트 역시 Let'Swift 202…

안전제일! 뱅크샐러드가 모바일 앱을 안정적으로 배포하는 방법

지난 글에서는 뱅크샐러드 iOS…

모듈 구조를 개선해 더 나은 뱅크샐러드 iOS 앱 개발하기

안녕하세요. 뱅크샐러드 iOS 챕터의 김봉균입니다. 최근 iOS 챕터는 뱅크샐러드 iOS…

스위프트 매크로_1탄, 스위프트 매크로가 뭐예요?

안녕하세요. 블로그에는 처음 인사 드리는 올리브영 모바일앱개발팀 윌입니다. 이번 포스트에서는 스위프트 5.9에 등장한 신기능: 스위프트 매크로를 소개합니다. 이 내용은 Let'Swift 202…

퇴근길에 카뱅 들러서 기술 한 잔 어때요? : 첫 번째 기술 밋업 회고

지난 8월 30일, 카카오뱅크 11층 카페 테라스에서 외부 iOS 개발자들과 함께하는 첫 번째 기술 밋업 ‘퇴근길 기술 한 잔’이 열렸습니다. 이 회고록에서는 KWDC 후원사 참여 경험에서 시작된 밋업의 기획 및 준비 과정을 담았습니다. 네이밍 비화와 굿즈 제작, 세션 및 패널톡 준비 과정, 네트워킹을 위한 세심한 준비까지, 카카오뱅크 개발자들과 함께한 소중한 시간을 공유합니다.

카카오뱅크 iOS 플랫폼의 모듈화, 왜 필요했을까요?

카카오뱅크의 지속적인 성장에 따라, 개발 리소스 부족과 빌드시간 증가가 큰 이슈로 떠올랐습니다. 이를 해결하기 위해 iOS 개발자들이 모듈화를 도입한 과정을 살펴봅니다. 카카오뱅크 결제서비스개발팀 Zeon이 KWDC 2023에서 발표한 내용을 바탕으로, 모듈화의 배경, 과정, 그리고 얻은 교훈을 공유합니다. 모듈화에 대한 고민이 있다면 이 글이 큰 도움이 될 것입니다.