저는 공포 게임을 직접 하는 건 무서워하지만, 유튜버 수탉님을 통해 대리만족하고 있어요.

수탉님을 정말 오랫동안 구독해 온 팬으로서, 최근 충격적인 납치 사건을 겪으셔서 크게 걱정했어요. 무사히 돌아와 다시 방송도 빠르게 복귀하신 것에 그저 감사한 마음입니다.

저는 공포 게임이라는 환경에서 주제 의식을 전달하는 건 정말 어렵다고 생각합니다. 그래서 수탉님 영상들을 보면, 소위 똥겜이라고 하는 게 많은 것이겠죠.

그러다 2023년 <러브, 샘>을 보고 완전히 시각이 바뀌었어요. 거의 영화를 보듯이 빠져들었거든요. 개발자가 한국 사람이라는 걸 듣고 도대체 어떤 분이 이런 걸 혼자서 만들었을까 검색해 보기도 했습니다.

<러브, 샘>을 개발한 곳은 Korean Linguistics Lab, 줄여서 ‘KLL’ 이라 부르겠습니다. KLL 은 1인 개발자 최세윤 님이 운영하는 게임 스튜디오입니다.

지난 2025년 상반기에는 KLL 의 두 번째 게임 <Letters of Bernard Thorne(버나드 쏜의 편지)> 가 출시되었습니다. 줄여서 <LBT> 라고 부르겠습니다.

저는 두 작품을 정말 재미있게 봤습니다. 또 두 작품이 주는 울림을 기억하고 있습니다. 공포 게임으로 예술을 하는 분이라고 생각했어요.

공포 콘텐츠, 인디 게임, 스토리텔링을 좋아하는 사람으로서 KLL 최세윤 개발자님과 대화를 나눠보고 싶었습니다. 그래서 세윤님께 X(트위터)로 조심스럽게 연락드렸고 흔쾌히 수락하셔서 직접 만나 뵐 수 있었습니다.

2026년 3월의 어느 맑은 주말. 강남에서 식사하고 커피를 마시며 나눈 대화를 인터뷰 형식으로 정리했습니다.

요즘에는 어떻게 지내고 계신가요?
혹시 다음 작품을 만들고 계신가요?

<LBT>를 출시하고 나서 거의 바로 차기작 준비를 시작하긴 했습니다. 하지만 이번에는 전작 때보다 조금 더 여유를 두고 취미 생활이나 다른 아이디어 구상도 병행하면서 개발하고 있어요.

여자친구가 카페 가는 걸 좋아해서, 저를 자꾸 밖으로 끄집어내 준 덕분에 밖에서 영감을 얻기도 해요. 집에서만 일을 하다 보니 건강이 나빠지는 것 같아 헬스장에서 PT 도 받고 있어요.

세윤님에 대한 공개된 내용이 많지 않아요.
과거 2024년 기사를 보면, 광고 회사에서 일하시다가 하고 싶은 일을 해보고 싶어 3년 간 개발한 것이 <러브, 샘> 이라는 내용을 봤어요.
그 당시 이야기를 좀 더 구체적으로 들을 수 있을까요?

처음에는 인터넷 강의 회사 마케팅팀에서 일하다가 창의적인 일을 하고 싶어 광고 대행사로 이직해 SNS팀에서 일했습니다. 카피도 쓰고 기획도 했지만, 제 창의성보다는 광고주의 입맛에 맞춰 끊임없이 설득해야 하는 ‘영업’에 가까운 환경에 현타가 왔습니다.

그러다 어느 날 자다가 “일기장을 소재로 한 공포 게임을 만들어야겠다!” 아이디어가 떠오르면서 눈이 확 떠졌어요. 그 후로 부모님의 만류에도 불구하고 바로 퇴사하고 게임 개발을 공부하기 시작했죠.

언리얼 엔진은 유튜브 강의를 보며 무작정 시작했어요. 언리얼 엔진의 블루프린트 방식이 마치 <심즈> 게임에서 방을 한 칸 한 칸 만드는 것 같아 재밌었거든요. 다만 제가 아트에 소질이 없어서 그게 제일 힘들었어요.

제가 게임에 넣을 그림을 열심히 그린 걸 보고, 당시 같이 살던 룸메이트 친구가 이걸 공포 게임에 넣으려고 그린 거냐고. 자기가 그려주겠다고 하며 <러브, 샘>에서 사용되는 그림의 90% 를 대신 그려줬습니다.

직장인으로 일하시던 시절과 1인 게임 개발자로 활동하고 계신 지금의 삶은 어떤 차이가 있을까요?
지금의 삶에 더 만족하고 계신지도 궁금합니다.

네 만족하고 있어요. 1인 개발의 장점은 출퇴근 시간을 자유롭게 조절할 수 있고 제 생각대로 개발을 빠르게 진행할 수 있다는 것입니다. 다만 게임 출시 전에 피드백을 주고받거나 창작의 고통을 공감해 줄 동료가 없다는 점은 단점이에요.

심지어 저희 부모님은 한동안 제가 정확히 어떤 일을 하는지 잘 모르셨어요. 제가 하는 일을 완전히 이해해 줄 사람이 없다는 게 어렵죠.

조심스러운 질문이지만, 수익 측면에서는 직장인 때와 비교하면 어떠신가요?

<러브, 샘> 최초 출시 때는 회사 다닐 때 받던 수입보다는 적었습니다. 하지만 rewrite 버전을 출시한 이후부터 수익이 증가하기 시작했어요.

이후 후속작인 <LBT>가 출시되면서 사람들이 전작을 함께 구매하는 시너지 효과가 발생했고, 지금은 꽤 안정적인 수익을 얻고 있습니다.

수익 패턴은 출시 직후에 판매량이 가장 높았다가 점차 줄어들긴 해요. 그러다 유명 스트리머가 방송에서 플레이하면 다시 판매량이 확 뛰곤 합니다.

많은 사람들이 세윤님의 게임을 즐기고, 무서워하는 모습을 보면 창작자로서 기분이 어떠신가요?

제가 의도한 타이밍과 연출의 강약 조절에 따라 사람들이 비명을 지르거나 무서워해 주면 창작자로서 매우 뿌듯하고 다행(?)이라고 느낍니다.

유튜브에서 어떤 여성 스트리머가 <러브, 샘>을 플레이하는 영상을 본 적이 있는데요. 어떤 장면에서 비명을 지르시더니 막 울기 시작하는 거예요. 그때는 너무 우셔서 약간 죄송한 마음이 들기도 했습니다.

<러브, 샘>의 시나리오를 구성하실 때, 일기장 말고도 영감을 받은 곳이 있으신가요?

세상에서 가장 짧은 공포 소설에 대해 아시나요? 두 문장 만으로 공포 소설을 쓰는 것인데요.

“세상에 홀로 남은 마지막 인간이 방 안에 홀로 앉아 있었다.”

“그때 밖에서 누가 문을 두드렸다.”

처음에는 이런 단편 영화적 아이디어에서 시작했어요.

여기에 집안을 돌아다니며 일기나 편지를 읽고 스토리를 파악하는 흐름은 <Gone Home> 이라는 게임에서 많은 영감을 받았습니다.

<LBT>의 주제의식은 상당히 묵직합니다.
어떻게 이런 주제의 게임을 만드셨나요?

전작인 <러브, 샘>이 ‘공간의 제약’ 을 다뤘다면, <LBT>에서는 ‘행동의 제약’을 활용해보고 싶었어요. 그래서 휠체어를 떠올렸습니다.

주제는 저의 개인적인 경험에서 왔어요. 학창시절에 우울증으로 심하게 힘들어하던 친구가 제 앞에서 “죽지 못해 산다”고 말한 적이 있어요.

주변에 그렇게 마음의 병을 앓는 사람들이 많은데, ‘저들은 어떻게 살아가는가, 왜 살아야 하는가’에 대한 깊은 고민을 계속해왔고, 그 주제를 참전 용사의 PTSD 와 결합하게 된 것입니다.

<LBT> 를 출시한 이후, 마음에 상처를 안고 살아가는 많은 분들에게 감사 메일을 정말 많이 받았습니다.

알고 보니, 해외 유튜버 jacksepticeye (구독자가 무려 3,110만 명…) 가 <LBT>를 플레이하며 눈물을 흘리면서 자신의 과거 트라우마를 진지하게 털어놓는 영상이 화제가 된 거예요.

제가 보통은 유튜브에 댓글을 남기지 않지만, 이 영상에는 댓글을 길게 남겨서 감사 인사를 전했어요. (링크)

저는 세윤님 게임의 연출을 되게 좋아합니다.
영화 연출 처럼 느껴질 때도 많았는데요, 이런 연출은 시나리오 작성 단계에서 미리 생각해두시는 건지, 아니면 게임을 개발하는 과정에서 고치고 또 고치고 하면서 만들어지는 것인지 궁금합니다.

연출 아이디어와 제가 생각한 스토리가 처음부터 끝까지 계속 치고 받으면서 만들어져요.

예를 들어, 어두운 밤에 창문 밖에 사람이 서있는 실루엣이 보인다거나, 어두운 화장실에서 카메라 플래시만 터뜨려서 길을 찾아야 한다는 등 “이런 장면을 짜면 무섭겠다.” 는 아이디어가 떠오르면, 그에 맞춰 스토리에 살을 붙이면서 개발을 하기도 해요.

최근 <8번 출구>, <백룸> 등 인디 공포 게임을 모티브로 한 영화가 많이 나오잖아요?
혹시 세윤님 게임에 대한 영화화 제안을 받으신 적은 없나요?

<러브, 샘> 초기 버전 출시 때 국내의 영화 제작자분께 연락을 받은 적이 있지만, 첫 작품이기도 하고 제가 원하는 그림이 나올지 조심스러워 정중히 거절했습니다.

제 게임을 해주신 분들이 종종 ‘영화 같다’라는 평가를 해주시거든요.

그 이유는 제가 게임을 만들기 시작할 때부터 “이 장면을 영화로 만들면 어떨까?” 생각하면서 만들어서 그런 것 같아요. 이 영화의 예고편이 나온다면 어떨지 상상해 보기도 하고요.

하지만 게임이기 때문에 전달할 수 있는 감정과 경험이 분명히 있다고 생각해요. 플레이어가 되어 직접 그 공간에 들어간 느낌을 받을 수 있고, 1인칭 시점에서 경험하는 긴장감이 재밌잖아요.

이런 게임이란 매체의 장점을 영화에서 그대로 표현할 수 있는, 그런 걸 잘하시는 영화감독을 만난다면 좋을 것 같아요.

AI 발전으로 소프트웨어 개발자의 영역이 무섭게 침범당하고 있습니다.
저는 이런 시대에는 오히려 ‘네러티브 게임’이 주는 가치는 높아지고 있다고 생각합니다.
코딩은 AI 가 순식간에 정답을 낼 수 있지만, 스토리와 감동이란 건 정답이 없기 때문이라 생각하는데요. 이 점에 대한 세윤님 의견이 궁금합니다.

동의합니다. 저 역시 창작자로서 언젠가 제 일이 AI 에게 따라잡히지 않을까 걱정하곤 해요. 하지만 창작이라는 것은 결국 ‘사람이 사람의 경험과 감정을 나누는 것’이라고 생각합니다.

아무리 화려하고 예쁜 그림을 보더라도, 이거 AI 가 만든 거라는 걸 알게 되는 순간 감동이 식어버리거든요.

물론 AI가 많은 업무에 사용되고 광고 이미지를 만들거나 코딩 수단으로 쓰이는 것은 피할 수 없는 흐름이겠지만, 순수 창작물에 있어서는 AI가 발전할수록 오히려 ‘사람의 손길’을 더욱 찾게 될 거라 생각해요.

예를 들어, 아무리 AI가 문법적으로 완벽하게 잘 쓴 글이 있더라도 저는 사람이 직접 썼다는 게 확실한 글, 심지어 열 살짜리 아이가 휘갈겨 쓴 글을 더 집중해서 읽을 것 같아요.

앞으로 온전히 사람의 손을 거친 창작물의 개수 자체는 줄어들지 몰라도, 그 희소가치는 훨씬 더 높아질 거로 생각합니다.

혹시 오프라인 강의 콘텐츠를 오픈하실 생각은 없으신가요?
게임 개발 강의 혹은 스토리 설계에 대해 강의하신다면 수요가 분명 있을 거라 생각합니다.

제가 외향적인 성격이 아니어서 그런 강의에 대한 부담감이 좀 있어요.

하지만 이렇게 재호님 처럼, 제 게임을 좋아해 주시는 분들, 공포 게임과 인디 게임을 진심으로 좋아하시는 분들이 모인다면 재밌게 진행할 수 있을 것 같아요.

마지막으로 질문입니다.
앞으로 어떤 게임을 만들고 싶으신가요? 혹시 다음 작품의 대략적인 주제와 출시 일정을 알려주실 수 있나요?

저는 항상 현실에 발을 딛고 있는 게임을 만들고 싶어요. 공포, 두려움이라는 감정은 결국 사람의 현실적인 걱정과 맞닿아 있거든요. 게임과 현실이 강하게 연결될 때 비로소 큰 공감과 감동을 이끌어낼 수 있다고 생각해요.

다음 작품은 개발을 시작한 지 거의 1년이 되었는데요. 계속 스토리를 뜯어고치고 있어서 정확한 출시 일정은 저도 모르겠습니다.

이번 주제도 저의 개인적인 경험에서 가져오려 합니다. 제가 직장인 시절에 너무 힘들어서 공황이 크게 온 적이 있거든요. 당시 겪었던 ‘당장 죽을 것 같은 공포감’을 스토리에 녹여낸 게임을 만들고 있습니다.

인터뷰는 여기까지입니다. 사실 인터뷰 외에도 여러 공포 게임에 관한 얘기도 많이 나눴어요. ㅎㅎ

일본의 게임 스튜디오 칠라스 아트, 그리고 Fears to fathom 시리즈, 인스크립션(Inscryption), Layers of Fear 같은 공포 게임 덕후들만 아는 내용으로 신나게 떠들었습니다.

이런 주제로 대화할 수 있는 친구를 만난 것 같아 신났습니다. KLL 최세윤 개발자님의 다음 작품도 응원하겠습니다!

• iOS 앱이 위젯을 여러 개 가지고 있는 경우, 사용자에게 먼저보여주고 싶은 위젯이 있을 것이다. 좀 더 앞에 내세우고 싶은 그런 위젯
• 이번 글에서는 위젯 갤러리에서 보여지는 순서에 대한 실험을 해봄
• 위젯 타겟이 딱 1개 있고 supportedFamilies 가 여러 타입이라면?
• [.systemLarge, .systemMedium] 이렇게 배치하면 systemMedium -> systemLarge 순서로 노출됨
• 즉, 동일한 위젯 kind 에서는 타입이 작은 순서대로 노출

• 위젯 구조체를 2개로 만들고 같은 kind 설정
• 두 위젯 구조체의 supportedFamilies 를 일부러 다르게 함
• WidgetBundle 의 body 에 배치할 때 A2Widget() 을 먼저 선언하면, 이 위젯만 노출됨
• 둘의 순서를 바꾸면, 반대로 AWidget() 만 노출되고 A2Widget() 은 안 보임

• kind 가 다른 BWidget() 생성
• WidgetBundle 바디에 배치할 때, A -> B 순서로 배치
• B 위젯은 systemSmall 이지만 갤러리에서 가장 우측 배치됨

• 만약 B 위젯의 supportedFamilies 가 [.systemSmall, .systemLarge] 가 되면?
• 예상한 대로, 같은 kind 안에서는 반드시 작은 위젯 타입부터 배치됨

• 만약 나는 B 위젯들이 A 위젯들보다 먼저 보이길 원한다면
• WidgetBundle 의 바디에서 먼저(위에) 선언하면 됨!

• 참고로, 앱 아이콘을 롱탭해서 위젯으로 transform 할 수 있는 기준도 이와 동일함
• 갤러리의 맨 앞에 있는 위젯의 kind 를 따라감
• 즉, 위의 경우 B 위젯을 최우선하기 때문에, systemSmall, systemLarge 로 변신 가능 (아래 왼쪽 스크린샷)
• 만약 A 위젯이 먼저 선언되면, systemMedium, systemLarge 로 변신 가능 (아래 오른쪽 스크린샷)
• 이거 즉시 반영되는 거 아님. 시뮬레이터 껐다 켜야 바뀜

• 이제 B 위젯을 지우고, 새로운 위젯 타겟을 만들자. (지금까진 같은 위젯 타겟)
• 만약에 위젯 타겟은 서로 다르지만, 두 위젯의 kind 가 똑같으면 무슨 일이 생길까?
• 즉, 타겟 마다 WidgetBundle 이 존재하지만, 결국 두 위젯 구조체의 kind 가 같으면 어떻게 되나 실험해보자
• 새로운 위젯 타겟에서 B 위젯의 supportedFamilies 는 systemSmall 만 채택

• 예상과 달리(?) A, B 위젯 둘 다 잘 작동함. 갤러리에서 title 구별도 되고, 설치도 잘 됨
• 앱 아이콘 롱탭해서 위젯 변신하는 거는 여전히 위젯 갤러리 맨 앞에 있는 B 위젯의 supportedFamilies 에만 반응함 (systemSmall)
• 홈 화면에 설치한 위젯을 롱탭했을 때는 A, B 위젯의 각자의 supportedFamilies 에서만 가능했음
• 즉, 위젯 타겟이 다르면 위젯 kind 가 ‘똑같아도’ 문제는 없음. 하지만 일반적으로 이렇게 하면 안 됨
• 그리고 롱탭 위젯 변신의 기준은, 아이콘은 ‘갤러리의 맨앞에 오는 위젯’ 을 우선하고, 화면에 설치한 위젯은 자신의 kind 끼리만 변신 가능

• 근데 서로 다른 두 개의 위젯 타겟(A, B)을 만들었을 때, 갤러리 노출 순서는 왜 B 위젯이 먼저 나왔을까?
• 어떤 기준으로 B 가 먼저 나왔는지 모르겠음
• 알파벳상으로는 AWidget > BWidget 임. 갤러리에서 A 위젯이 먼저 나오는 게 자연스러움. 하지만 실제론 BWidget 이 먼저 보임
• 여기서 예외 케이스가 하나 발생
• 앱 아이콘 롱탭해서 위젯으로 변신시키는 게, 지금까지는 위젯 갤러리 맨 앞의 위젯을 우선했는데, 위젯 타겟이 2개 이상이 되니까 그게 안 지켜짐
• 즉, 갤러리 맨 앞에 B 위젯이 있어도 앱 아이콘은 A 위젯으로만 변신 가능할 때가 있음. 그러다 앱 삭제하고 재설치하면 B 위젯으로 변신할 때도 있었음
• 어디서 순서를 정하는거지? 알파벳 순서가 아닌가?
• 3년 전 스택오버플로우 글 하나 찾았는데, 댓글 보면 애플 TSI(Technical Support Incident) 에 문의했었는데, 위젯 타겟을 나누지 말고, 하나의 타겟 안에서 순서를 조절하라고 했다고 함
• https://stackoverflow.com/questions/74301476/determine-the-order-of-the-widgets-in-the-widget-gallery-without-widgetbundle-s

TSI를 접수했고, 다음과 같은 답변을 받았습니다:
두 개의 별도 익스텐션을 사용하면 안 됩니다. 대신 하나의 익스텐션과 Widget Bundle을 사용해야 하며, Widget Bundle은 표시 순서도 지정합니다.

사용 사례는 이해하지만, 두 개의 익스텐션을 쓰면 앱의 컴파일 시간이 느려지고, 서로 다른 프로세스에 속하기 때문에 두 익스텐션 사이의 순서를 제공할 방법이 없습니다. […]

제 입장이라면 앱을 [단일 위젯 익스텐션을 쓰는 구조로] 바꾸고, 특정 위젯에 한정된 권한을 부여할 수 있도록 기능 개선 요청을 제출하겠습니다.

• 근데 위젯 개발하다 보면 이런 일도 생김. A 위젯은 평범하고, B 위젯은 ‘위치 권한’ 이 필요한 경우
• 만약 A 위젯은 위치 권한이 필요하지 않다면, 둘을 단일 위젯 타겟에 묶어두지 않는 게 개발자에겐 자연스러운 행동일 것임
• B 위젯 타겟의 Info.plist 에서 “Widget Wants Location” 를 “YES” 로 설정하면 위젯에서 사용자 위치에 접근할 수 있음
• (중요) 위젯에서 위치 권한을 쓰려면, iOS 호스팅 앱에서 먼저 위치 권한을 얻어야 함. 앱에서 허락 안 했다면 위젯에서는 물어보지도 않음

• 재밌는 사실. Widget Wants Location 을 “YES” 로 설정한 B 위젯에 위치 관련 코드를 아무것도 넣지 않았음에도, 앱을 최초 설치 후, 인앱에서 위치 권한 허용하고 백그라운드로 나가게 되면, 위젯 위치 권한 팝업이 뜸!

• 즉, A 위젯은 위치 권한 안 쓰는 위젯, B 위젯은 위치 권한 필요한 위젯으로 구분하고, 둘의 위젯 타겟을 분리하더라도, 위젯 타겟 중 하나라도 Widget Wants Location 가 “YES” 이고 사용자가 호스팅 iOS 앱에서 “앱을 사용하는 동안 허용" 을 눌렀다면, 백그라운드로 나가는 순간, 위젯 위치 팝업이 즉시 뜬다.
• 만약 “한 번 허용” 혹은 “허용 안 함” 을 선택한다면, 앱을 나가도 위젯 위치 팝업이 뜨지 않음 (원하면 나중에 설정에서 직접 바꿔야 함)
• 만약 이 상황에서, B 위젯의 Info.plist 에서 “Widget Wants Location” 을 NO 로 바꾸면, 백그라운드 나가더라도 위젯 위치 팝업이 뜨지 않는 걸 확인함
• 실기기로 테스트할 때는 일정하지 않은 모습을 보임. 앱에서 위치 권한 허용하고 BG 로 나가도 위젯 위치 권한 팝업이 안 뜨기도 함. 실제로 위젯을 설치할 때가 되어서야 뜬다.
• 그런데 실기기에서 앱 삭제 후 재설치 하니까 이번엔 BG 로 나갈 때 바로 위젯 위치 권한 팝업이 뜬다. 왔다갔다 하는 듯.

실험 결론

• 위젯 갤러리에선 작은 사이즈 타입부터 노출된다. (small → medium → large)
• kind 를 나눠서 위젯을 구분했다면, WidgetBundle 에서 선언한 순서대로 위젯이 노출된다.
• 위젯 타겟이 하나만 있어야지 위젯 갤러리에서 노출 순서 조절하는 게 쉽다. (단일 Widget Extension 타겟)
• 위치 권한이 필요한 위젯과 필요 없는 위젯을 같이 운영하는 경우, 그냥 위젯 타겟 분리하지 말고 하나에 다 때려 넣자.
• 어차피 위젯 위치 권한은 앱에서 위치 권한 허용하고 BG 나가면 바로 뜬다. (위젯을 설치하지 않았더라도)

애플 아카데미 쇼케이스24 후기

벌써 1년이 지난 게 놀랍다. 올해는 4기 러너들의 차례다. 올해는 구경한 앱이 너무 많아서, 그냥 작년에 비해 뭐가 나아졌는지, 어떤 생각을 했는지 편하게 적어보려 한다.

올해도 현대자동차 팀원들과 개인 연차를 쓰고 포항으로 향했다. ㅎㅎ

이번 쇼케이스25 에 나온 모든 앱은 아래 노션 링크에서 자세히 살펴볼 수 있다.

[2025] SHOWCASE | Notion

1. 공공기관, 병원, 기업과의 협업이 눈에 띄게 늘어났다.

올해 느낀 가장 큰 변화다. 많은 팀이 단순히 앱만 출시하는 게 아니라, 더 큰 사회적 임팩트를 만들어내기 위해, 아카데미 외부와 협업하기 시작했다.

수사24 팀은 경북 경찰청과 협업하여 ‘형사’ 들을 위한 iOS 앱을 개발했다.

히포 팀은 삼성서울병원과 협업하여 ‘의사’ 들을 위한 visionOS 앱을 개발했다.

일반 사용자들이 아닌 특수 사용자를 위한 전용 앱을 만드는 전략. 되게 매력 있다고 느꼈다.

왜냐면 팀플로 만들어진 일반 사용자를 위한 앱이 ‘진짜로’ 그럴싸한 성과를 내기가 너무 어렵기 때문이다. DAU 10명 만들기도 진짜 어렵다.

하지만 협업으로 만들어진 전용 앱은, 일단 협업을 이끌어낸 것 자체가 큰 성과다. 어필이 잘 된다.

팀원들은 소수의 타겟 유저의 불편함에 집중해서 앱을 뾰족하게 다듬어 나가는 경험을 할 수 있다.

조금 느슨한 형태의 협업 프로젝트들도 많았다.

스틸워크 팀은 포항시 및 포스텍 사회문화데이터 사이언스연구소와 함께 게이미피케이션이 강조된 포항 철길숲 산책 iOS 앱을 개발했다.

우아 팀은 전시를 준비하는 예술가들과 함께 관객과 작가의 소통을 돕는 iOS 앱을 개발했다.

사실 이런 느슨한 협업이야말로 가장 균형 잡힌 프로젝트라고 생각한다. 특히 기획이나 PM 직무를 준비하는 러너들에게 좋다. 타겟 유저들의 Pain Point 를 분석해서 기획에 녹일 수 있다는 건 정말 좋은 경험이니까.

듣기로는 애플 아카데미가 올해 협업을 많이 만들어낸 건 멘토분들의 공이 크다고 한다. 고생 많이 하셨을 듯. 내년(5기) 기수에는 협업이 더 많아질 것 같다.

글을 쓰며 떠오른 재밌는 아이디어가 있는데, 애플 아카데미 쇼케이스를 준비하는 똑똑한 친구들의 개발 리소스를 ‘외주화’ 해 보는 건 어떨까?

예를 들어, 아이디어가 있는 초기 창업팀이 아카데미 측으로 기획서를 제출하고, 러너들이 그 기획서를 검토 후 구현 가능성이나 매력도가 괜찮아 보이는 아이디어를 선택하는 식으로.

그러면 러너들이 아이디어를 떠올리기 위해 낭비하는 시간도 줄어들 것이고, 개발자가 부족한 외부의 초기 창업팀도 도와줄 수 있는 Win-Win 전략이 나올 수 있을 것 같다.

2. AI 생성 이미지/영상을 안 쓰는 팀이 없다.

2025년에 AI 생성 이미지/영상 기술이 엄청나게 발전한 건 알고 있다. 얼마 전 출시된 구글의 나노 바나나 프로만 봐도 미친 성능을 보여주니까!

근데 와~ 역시 러너들이 기술 적응이 빠르다. 앱 소개 목적으로 만든 AI 이미지나 영상이 수준급이었다.

이제 AI 생성 콘텐츠를 사용하는 게 NEW NORMAL 이 된 거다. 안 쓰면 오히려 생산성이 떨어지는 시대. 휴… 요즘 취준생들은 정말 배워야 할 게 많구나.

3. 과한 일회용품 사용이 99% 줄었다.

작년 후기에서 나는 이런 피드백을 남겼다. 러너들이 마케팅을 위해 일회용품을 조금 과하게 준비하는 것 같다고.

이게 보기엔 예뻐 보이지만, 솔직히 스티커나 팜플릿은 집에 가면 쓰레기통에 버려지는 게 현실이다. 심지어 러너들이 ‘사비’로 준비해야 하고, 다른 팀과 경쟁 심리도 자극하게 되니 지양하면 좋겠다고 생각했다.

올해 쇼케이스에선 이 피드백이 완전히 반영된 것 같았다. 나눠주는 게 없으니, 모든 팀이 앱의 소개에만 집중했다. 방문자로서는 받는 게 없으니, 손이 가벼워서 돌아다니기도 편했다.

테이블을 과하게 꾸미는 팀도 사라졌다. 이건 정~말 좋은 변화인 듯!

마지막으로 쇼케이스25 현장 스케치 영상을 첨부한다. 다들 고생 많으셨고 수료 축하합니다!

이 스터디 자료를 조금 수정해서, 블로그에 다시 포스팅합니다.

WWDC25 에서 등장한 <Icon Composer> 에 대한 두 편의 WWDC 영상을 정리했습니다.

• iOS 26 의 아주 큰 디자인 변화. visionOS 에서 영감을 받아 liquid glass material 을 만들어냄
• 빛을 받아 반사되는 듯하고, 불투명도도 있고, 깊이감도 있는 앱 아이콘 만들 수 있음

• gyro input 에 따라 빛이 반사되는 방향이 라이브하게 바뀜.
• light tint, dark tint 모드도 생김

• 앱 아이콘 업데이트는 iPhone, iPad, Mac, watchOS 전부 적용됨
• 당연히 앱스토어에서도 업데이트된 앱 아이콘으로 보임
• 지금까지는 플랫폼 마다 앱 아이콘의 디자인이 좀 달랐음

• 그런데 이제는 쉬워짐!
• macOS, iPadOS, iOS → 왼쪽의 Rounded Rectangle format
• watchOS → 오른쪽의 Circle format

• 이미 심플한 구조를 가진 앱 아이콘은 아무 처리를 하지 않아도, 자동으로 새로운 디자인이 적용됨.
• 아래 스크린샷을 보면, 앱 아이콘 테두리가 반짝반짝 거리고 “box” 텍스트엔 입체감이 생긴 걸 볼 수 있음.

• 만약 아래 스크린샷의 왼쪽 처럼, 특별한 디자인을 가진 앱 아이콘은 자동으로 조정(auto adjusted) 됨
• 하지만, 전체 앱 아이콘 공간을 잘 쓰려면 그냥 다시 만드는 걸 추천함!

• watchOS 에서는 어떻게 보일까?
• Rounded Rectangle 앱 아이콘을 둥글게 변형 → 픽셀이 1088 x 1088 로 변경됨
• visual consistency 를 유지하면서 플랫폼 간의 디자인을 맞출 수 있다.

• 이 새로운 디자인 시스템을 쉽게 만들 수 있도록, 템플릿 만듦
• 피그마, 일러스트레이터, 스케치, 포토샵 포맷으로 뿌림
• 아래와 같이 피그마 템플릿을 보면, 정확한 비율과 가이드라인이 제시되어 있음.

• 이제 앱 아이콘 구성을 알아보자!
• 기본적으로 아이콘은 background 와 foreground layer → 이렇게 2개 층인 것임
• 아래 있는 메시지 앱 아이콘 처럼!

• foreground layer 가 단 1겹이더라도, 충분한 디테일이 녹아든 것을 볼 수 있음
• 메시지 버블에는 멋진 투명도가 들어가 있고, 살짝 그림자가 있어서 조금 떠있는 듯한 느낌도 줌
• 물론 배경은 한 장이지만, foreground 에는 보통 multiple layers 가 포함됨
• 그리고 이런 layers 를 stacking 하는 게 아주 흥미롭다.
• <팟캐스트> 앱을 예시로 들자.
• 기존 팟캐스트 아이콘은 플랫한 느낌.

• 하지만 이제는 애플의 레이어링 테크닉을 이용해서, 팟캐스트 아이콘 모양을 차곡차곡 스태킹할 수 있다.

• <체스> 앱 아이콘은 기존엔 머티리얼 느낌이 강했음
• 새로 만들어진 앱 아이콘은 flat 하고 리퀴드 글래스 느낌 추가됨
• <미리보기> 앱도 기존 대비해서 더 멋있어졌다!
• 그리고 좀 더 목적이 명확해짐. magnifying glasses 더 중앙에 둬서 집중할 수 있도록

• translucency in blur 는 특히 아름다워 짐
• 만들기도 쉬움
• 가볍고, 디자인에 깊이감을 줄 수 있음
• translucency 는 낮과 밤 둘 다 예쁘다.
• 투명 모드에서도 아주 예쁘다.

• <사진> 앱 아이콘 보면 대박임. petals(꽃잎)들을 겹쳤을 때, 유리 처럼 서로 비치는 디자인이 아주 예쁘다.
• petal 아래에 그림자가 있어서 depth 도 강조된다.

• 기존의 <홈> 아이콘을 보면, 그림자를 잘 써서 되게 입체적이다.
• 이 디자인에 glass icon 디자인을 적용해서 아래와 같이 리디자인했다.

• 앱 아이콘 만들 때, 뾰족한 선은 피해라.
• 대신에 둥근 코너를 만들어서, 빛이 잘 반사되도록 구현해라.

• 작게 보이는 텍스트에는, 예외적으로 bolder line weight 을 적용해서, 글자를 두껍게 보이게 만들어라.
• 그러면 글자가 작아져도 가독성이 좋음!

• 애플이 단순 흰색이나 검정색 배경 하지 말라고, system 배경도 준비해둠

• 다크 모드가 예쁘니까, 라이트 모드를 반대로 되게 비비드한 컬러 백그라운드 넣기를 추천한다.
• 그러면 라이트 ↔ 다크 모드 전환할 때 훨씬 예쁘게 느껴지기 때문이다!

• 이제 이어서 “Make app icons with Icon Composer” 를 보면 된다.

• 다음 WWDC 영상으로 들어갑니다.
• 새로운 도구 <Icon Composer> 를 어떻게 사용하는지 알아봅시다.

• 2025년, 테마가 다양해지며 만들어야 하는 앱 아이콘 종류가 참 많아짐
• default, Dark, Clear light, clear dark, Tinted light, Tinted dark
• 이제 이 많은 아이콘 종류들은 단 1개의 파일로 처리 가능하게 됨

• 그게 바로 Icon Composer 로 제작한 .icon 파일임
• Icon Composer 로 앱 아이콘 제작하면, 매번 여러 사이즈를 대응할 필요가 없음
• 자동으로 아이콘의 스케일이 조정되며 대응됨!

• 아이폰, 아이패드, 맥에서 보이는 아이콘은 1024 x 1024 임
• 와치앱에서 아이콘은 1088 x 1088 임

• 레이어링을 다뤄보자
• 아래 번역 앱을 보면, 여러 레이어링이 있지만, 테마에 따라 컬러 지정만 해주면 됨

• Icon Composer 안에는 여러 설정들도 존재함
• Blur
• Shadow
• Specular : 반사광
• Opacity : 불투명도
• Translucency : 반투명도 (흐릿하게 보이는 정도 — 유리 느낌)
• Opacity 와 Translucency 는 반대 개념이 아님.
• Opacity 는 수치적 “불투명 정도” (1 → 완전 불투명, 0 → 완전 투명)
• Translucency 는 시각적/재질적 “빛 투과 성질”을 더 강조함

• 기존에 있던 앱 아이콘을 Icon Composer 를 통해 다시 작업하고 싶다?
• 일단 기존 아이콘의 구성 요소 레이어들을 SVG 포맷으로 canvas 사이즈로 export 해야 함.
• 그래야지 Icon Composer 에 옮겼을 때 올바른 자리에 떨어지기 때문임

• Z축 방향 순서는 파일 이름 맨 앞에 숫자를 붙여주면 됨
• 0 이 가장 아래, 높을수록 위로 가는 것임
• 물론 나중에 Icon Composer 안에서 순서는 바꿀 수 있으니 걱정 ㄴㄴ

• 간단한 배경화면은 Icon Composer 안에서 만드는 게 나으니까, 애매하면 빼버려도 됨

• 혹시 SVG 로 표현이 안 되는 투명도가 포함된 에셋이 있다면, PNG 포맷으로 export 해라
• PNG 는 손실이 없는(lossless) 포맷이라 투명도 표현하기 좋다.

• 중요한 사실, 경계선에 미리 radius 넣어서 crop 해서 export 할 필요 없다.
• 네모난 이미지를 첨부하면, 나중에 Icon Composer 가 자동으로 예쁘게 crop 해줄 것임

• 레이어를 다 준비했다면 <Icon Composer> 실행해보자!
• 일단 파란색 배경이 보일텐데, 이걸 바꾸려면, 왼쪽 side bar 에서 “home” 선택하고
• 우측 inspector 에서 컬러나 gradient 를 선택해서 변경 가능!

• 아까 export 해놨던 에셋들을 가져와서 왼쪽 side bar 에 드래그 앤 드랍해보자
• 알파벳 순서대로 정렬이 될 것임
• 만약 파일 이름 앞에 숫자를 Z 순서대로 붙였다면, 그 순서가 유지된다.

• 에셋을 넣으면 “Group” 이 생기는데, 이 그룹 단위로 glass 효과를 가짐
• Group 은 최대 4개 까지 생성 가능함

• Icon Composer 앱의 아래를 보면, 플랫폼이나 Appearances 를 바꿀 수 있음
• Default(Light), Dark, Mono
• 모노는 Clear Light, Clear Dark, Tinted Light, Tinted Dark 4개로 바꿔볼 수 있음

• 인스펙터로 가면, 레이어에 적용된 효과를 바꿀 수 있음
• 기본적으로 “Liquid Glass Effects” 토글이 ON 상태임. 원한다면 끌 수 있음.

• 불투명도나 Blend Mode, Fill color 등을 바꿀 수도 있음

• 만약 “Group” 레벨로 바꿔본다면, 인스펙터에 못 보던 게 생김 (Liquid Glass)

• Liquid Glass 효과는 바리언트가 달라져도 똑같이 가도 되지만
• 만약 특정 바리언트 마다 조금 다르게 주고 싶다면, 아이콘에 마우스 hover 하면 Vary 할 수 있는 옵션이 뜰 것임

• 실전 예시를 들어보자, <캘린더> 앱 상단에 “Wed” 란 글자에 Specular 효과가 들어가서, 조금 pillowy 해보인다면 (베개처럼 보인다면)
• “Group” 을 찾아서 Specular 토글을 꺼버리면 좀 더 가독성이 좋아진다.

• Shadow 효과의 옵션 중에서는 “Chromatic” 이란 게 있음
• 그림자인데, 컬러가 들어간 그림자임. 떠있는 요소의 컬러가 자동으로 그림자 컬러로도 반영되는 효과

• 다크 모드에서는 고민해야 하는 지점이 있음
• 배경색이 바뀌면, 라이트 모드 때 컬러가 제대로 안 보이고 묻히는 경우도 있기 때문에, 라이트와 다크 때 각각 다른 컬러로 바꿔주는 것도 중요함
• (왼쪽) 라이트 모드 때 쓰던 라벨 컬러 그대로 다크 모드로 가져오니까 가시성이 뚝 떨어짐
• (오른쪽) 하지만 라벨 컬러를 좀 더 밝은 Red 로 바꿔주니 가시성 좋아짐

• 만약 아래의 loupe 이미지 같은 PNG 포맷을 사용해야 한다면, 컬러를 채울 수 없으니까
• 다크 모드에서 쓰는 별도의 PNG 이미지로 분기처리를 하면 됨

• Mono 톤에서는 최소 하나의 요소는 ‘흰색’ 으로 해라
• 보통 가장 중요하고 눈에 띄는 부분에 흰색 바르면 됨
• 다른 색상들은 grayscale 로 작업하면 됨

• RoundedRectangle 아이콘과 watchOS 아이콘을 위한 Circle 아이콘 사이에 별다른 처리는 필요 없음
• Icon Composer 가 자동으로 처리해주기 때문임
• watchOS 를 위한 아이콘은 1024 x 1024 가 아니라 1088 x 1088 로 살짝 크기 때문에 주의할 점이 생기기도 함
• ‘건강’ 앱 처럼, 우측 상단에 ❤️ 레이어가 있는데, Circle 로 컷 할 때 조금 더 중앙에 가까워지도록 X, Y 축 방향으로 -13pt 씩 땡겨온 예시

• Siri 앱을 보면, 배경이 canvas 끝에 딱 닿아있음
• 1024 x 1024 그대로 watchOS 아이콘으로 변환되면, 1088 x 1088 이 되면서 끝에 여백이 생김
• 따라서 watchOS 에서는 106.25% 확대시켜주는 분기를 적용하면 canvas 끝에 딱 닿아서 예쁨
• 왜 106.25% 냐면, 1088 / 1024 에 해당하는 숫자임

• Icon Composer 상단에 보면 배경을 바꿀 수 있는 버튼도 있음
• 이 버튼을 이용해서 legibility 를 테스트해보자!
• 참고로 legibility 와 readability 는 뜻이 다름
• legibility: 시각적인 관점에서 식별 가능성
• readability: 글을 읽는 관점에서 얼마나 술술 읽히는 좋은 글인지

• 가상의 그리드를 만들거나, 빛이 내려오는 방향도 각도계를 통해 조절할 수 있음

• 아이콘을 다 완성했다면, `.icon` 파일을 저장하면 된다.
• 그리고 Xcode 의 프로젝트 에디터에 드래그 앤 드랍하고 선택해라.

• Icon Composer 로 더 짧은 시간으로 더 멋진 앱 아이콘 만들어보자!
• 그리고 포토샵으로 glass effects 구현하려고 고생하지마라. 편한 거 만들어뒀으니 이거 써라!

• 기존의 아이콘 디자인은 그저 단순한 이미지들이었지만
• 이제는 expressive, multi-layered artworks 로 진화한다.
• 유저 인풋과 주변 환경에 반응한다.
• 애플 디바이스에서 훨씬 멋지고 풍부하게 보일 것이다.

• Icon Composer 는 베타 버전으로 바로 사용 가능!
• https://developer.apple.com/icon-composer/

개발자는 영어 공부 어떻게 해요?

위 글에서는 <말해보카> 앱을 중심으로 얘기했어요. 실제로 제가 가장 오랫동안 streak 를 유지하고 있는 앱이 말해보카입니다.

근데 저는 말해보카 외에도 <스픽> 과 <듀오링고> 도 매일 하고 있습니다. 스픽으로는 영어 공부를 하고, 듀오링고로는 독일어/일본어 공부를 해요. (개인적으로 듀오링고의 영어 학습 콘텐츠는 별로라고 생각)

마켓에서 제일 잘 나가는 외국어 앱을 매일 하고 있으니, 자연스럽게 이런 language learning apps 의 이해도가 높고 각 앱의 장단점도 아주 잘 알고 있습니다.

<스픽> 앱은 streak 를 높게 유지하는 유저를 대상으로 베타 테스터를 운영하고 있습니다. 저는 24년 7월부터 베타 테스터로 참여하고 있어요. 가끔 신기능이 출시되거나 디자인이 변경되면, 먼저 사용해 보고 스픽에게 솔직한 의견을 전달하고 있습니다.

제 직업이 iOS 개발자이기 때문에, 독특하게도 “개발자이자 사용자의 피드백” 을 전달할 수 있었습니다.

그렇게 지내던 중, 25년 7월에 우연히 스픽 CEO 와의 온사이트(현장) 인터뷰를 제안받게 됩니다.

기존에 참여하던 베타 테스트는 그냥 인터뷰도 없이 피드백을 텍스트로 적어 제출하는 게 전부였는데, 갑자기 대표랑 인터뷰라니. 그리고 대표는 미국인이잖아… 😓

걱정이 앞섰지만, 한국인 팀원이 들어와서 통역을 도와준다고 하니 안심이었습니다. 무엇보다 거절할 이유가 없었어요. 매일 사용하는 앱의 대표랑 만나서 대놓고 피드백할 수 있는 기회니까요.

그렇게 저는 “실리콘 밸리의 유니콘 스타트업” — 스픽의 대표 Connor Zwick 하고 만났어요. 유저 인터뷰는 1시간이 조금 넘게 진행됐고 정말 재밌게 많은 얘기를 나눴습니다.

제가 인터뷰 때 전달한 내용은 아래 간단한 메모로 정리했어요. 재미로 읽어보시면 좋겠습니다!

• 제가 마켓의 여러 언어 앱을 다 하는 사용자라서, 다른 앱 대비 스픽의 장단점이나 AI 튜터 기능에 대해 피드백을 꽤 했는데요, 대표가 정말 열정적으로 되묻고, 메모하고, 직접 화면도 같이 보면서 확인하려고 하고… 왜 스픽이 유니콘이 되었는지 그 이유를 알 것 같더라구요.
• 제가 지난 3년 동안 영어 실력이 많이 좋아지긴 했으나, 그건 오로지 스픽 때문이라고 보긴 어렵고 복합적인 이유일 겁니다. (이것저것 영어 공부 열심히 함) 근데 항상 유창성 수준의 천장을 느끼고 있고, 그걸 break through 해서 더 성장하려면 아이러니하게도 오프라인 학원같이 네이티브들과 아이 컨택하며 두려움을 극복하고 쫄지 않는 연습이 필요할 거 같다고 얘기했습니다. 스픽의 비전이 오프라인 영어 학원을 대체하는 것이기 때문에, 아이러니한 것입니다. ㅎㅎ
• 지금의 스픽 AI 튜터는 너무 착하고, 뻔하다고 말했습니다. 요즘 GPT 대답 meme 도 있잖아요? “너 정말 **핵심** 을 찔렀어.” 같은 거요. 스픽 AI 도 비슷하거든요. 일단 리액션을 먼저 하고, 그다음에 착한 질문을 하고… 이런 방법으로만 영어를 학습하다가, 갑자기 미국에 가면 네이티브 스피커들의 무자비한 영어에 놀라게 되고, 오히려 더 벽을 느낄 수 있다는 경험담을 얘기했습니다.

• 결국 AI 튜터가 더 공격적이고, 다양한 성격 모드를 가져야 한다고 얘기했습니다. 머스크의 Grok 이 최근 출시한 AI waifu 기능처럼, 정말 대화를 하고 싶게 만드는 특별한 AI 튜터가 되면 좋겠습니다. 이를 위해 unexpectedness 와 randomness 가 가미된 ‘하드 모드’를 추가하면 좋겠다고 얘기했습니다.

• 그 외에도 앱의 디자인(UI, UX)에 대한 얘기도 했지만, 결국엔 외국어 학습에서 AI 튜터의 방향성에 대한 대화를 많이 했습니다.
• 인터뷰가 마무리될 때, 가장 궁금했던 질문을 던졌습니다. “왜 저를 인터뷰에 초대했나요?” 혹시 저의 직업이나 배경에 대해 알고 있냐구요. 근데 놀라운 건, 스픽은 제 직업이나 나이, 다니고 있는 회사도 몰랐습니다. 스픽을 열심히 사용하는 베타 테스터 중에서 선발했다고 합니다.
• 그래서 제가 iOS 개발자임을 얘기하고, 좀 더 기술적인 얘기도 나눴습니다. 저는 스픽 대표인 Connor 의 창업 이야기를 알고 있습니다. 그도 처음에는 iOS 개발자였거든요.
• 인터뷰 후에는 같이 기념사진도 찍었습니다. ㅎㅎ

그렇게 인터뷰를 다녀오고, 일주일 사이에 스픽 앱의 AI 튜터 버튼 위치, 스마트 리뷰 기능의 업그레이드 등 아주 빠르게 업데이트가 나왔습니다. 아마 저의 피드백만으로 업데이트가 이뤄진 게 아니라, 많은 사용자들의 피드백을 반영한 것이겠죠.

알고 계셨나요? 스픽이 이제는 영어뿐만 아니라, 해외 사용자들을 대상으로 스페인어, 불어, 한국어, 일본어, 이탈리아어 교육도 시작했습니다.

스픽도 듀오링고 처럼 글로벌 언어 시장을 노립니다. 두 앱의 학습 경험은 분명 다릅니다. 장단점도 명확하구요. 앞으로 둘의 대결이 기대됩니다. 저는 그럼 다시 스픽을 하러 가야겠네요.

In my last post I talked about the tools you can use for event logging on watchOS.

Need watchOS Event Logging?

If your watchOS does not have a logging system yet or you are just getting started I recommend Amplitude. If for some reason you end up going with Firebase Analytics then good luck.

In that case you will need to send your watchOS logs to the companion iOS app and let the iOS app handle sending them on behalf of watchOS.

Here is the catch:

here is no built-in way for the iOS app to retrieve the paired watch’s model name. You have to include the model name yourself when sending logs from watchOS to iOS.

Does getting the device model name seem easy to you? That just means you have not spent enough time on watchOS.

Let’s start by printing WKInterfaceDevice.current().name on watchOS. You will see different results in the simulator versus on a real device.

In the simulator, you get the correct device model name. But on a real device, it only shows “Apple Watch.”

If you use Amplitude on watchOS, you can track the device model name without any extra code. I tested it myself, and when logs are sent from a real device, Amplitude records the exact Apple Watch model name.

There is a catch, though. You also lose details like case size or whether it’s a GPS or Cellular version.

In many cases you don’t need that level of detail, but it never hurts to know exactly which Apple Watch you’re dealing with.

So how do you get the precise watchOS device model name?

The answer is simple:

Use the code I wrote. I’m sharing it right here.

This code is really simple to use. I’ll show in red text how it appears in the simulator versus on a real device.

I checked out DeviceKit, that popular library with over 4.6k stars, and I think it hasn’t been very well maintained.

It even lacks support for Apple Watch Series 9 models. I submitted a PR to add them, but a month has passed with no response. That’s a bummer.

https://github.com/devicekit/DeviceKit/pull/448

My code already includes the latest Apple Watch models.

I’ll keep it updated as new watches come out, but even if I don’t, adding them yourself will be really easy.

When a new Apple Watch model is released, just refer to the link below to update it. Good luck!

Device Selection (Apple Watch)

If you’re building an app, logging user events to understand how people use your app is essential.

For iOS developers, the most common choice would be Firebase Analytics. But there’s a challenge if you’re like me, someone who also build watchOS apps.

Firebase Analytics doesn’t support watchOS. I actually tried importing it into my watchOS target, but it just doesn’t work.

I develop various extensions such as Widgets, App Intents, and watchOS apps.

Firebase Analytics works fine on Widgets and App Intents, but strangely it doesn’t support watchOS.

Because of this limitation, if you want to log user actions on watchOS, you need to send the actions from the watch app → companion iOS app.

Then the iOS companion can send logs ‘on behalf of’ watchOS. Just like a proxy!

However, this solution is complicated to build and difficult to debug. And more importantly, if you have a standalone watchOS app (without an iOS companion), you can’t log anything at all.

The cleanest solution is to use Amplitude.

Amplitude officially supports not only iOS but also watchOS, macOS, and tvOS.

Amplitude-iOS support for WatchOS | Community

I tested this myself, and logging watchOS events using the Amplitude SDK was really easy.

Even if your app is a standalone watchOS app, it still works fine.

If there’s any difficulty, it won’t be technical thing.

If your company already uses Firebase Analytics, you’ll face an extra challenge — like persuading coworkers, refactoring code, or migrating existing data.

But if you’re a startup, or your watchOS app is important, I strongly recommend starting with Amplitude from the beginning.

Conclusion

Firebase Analytics, a common logging tool, does not officially support watchOS.

If you want to log events on watchOS, I recommend using Amplitude. It’s even easier and more elegant from a technical perspective.

If you check Firebase Analytics’ repository, you’ll see it says watchOS is “partially supported.”

However, this support isn’t official from Firebase. It’s only available because of open-source contributions.

firebase-ios-sdk/Example/watchOSSample at main · firebase/firebase-ios-sdk

며칠 전, 2025년 3월 13일이 현대차 입사 2주년이었다.

내 블로그에서 가장 조회수가 잘 나오는 글 중 하나가, 현대차 이직 3개월 차 회고 글이라는 재밌는 사실 ㅎㅎㅎ

이번 2주년을 작게 기념하며 2년 차 회고를 써본다.

현대자동차 iOS 개발자 이직 — 3개월 차 회고

위 글에서 현차 입사하고 2주 만에 바로 특근을 했다고 썼었는데, 특근은 요즘에도 하고 있다. ㅎㅎ 솔직히 좀 바쁘다가 여유로운 기간도 생겨서 팀원들과 같이 스터디도 하고 ~ 사이드 프로젝트 아이디어도 나누고~ 이럴 줄 알았다.

하지만 2년 동안 ‘계속’ 바빠지기만 했고 업무 난이도도 우상향만 했다.

왜 그랬을까? 푸념하듯 써본다.

일단 우리 팀이 다뤄야 하는 앱의 종류가 늘었고, 앱의 권역(Region)이 늘었고 차종이 많아졌다. 차종이 많아졌다는 게 어떤 말이냐면, 예를 들어 테슬라는 전부 ‘전기차’ 만 있고 내연기관 차량은 없다. 그리고 그 전기차도 종류가 소수다. (모델 S, 3, X, Y, 사이버트럭)

하지만 현대는 내연, 전기, 하이브리드, 수소차가 있고 같은 내연이더라도 오래 전 차량과 최근 차량들의 차량 스펙이 다르다. 여기에 버스/트럭 상용차들도 다룬다.

국내와 유럽은 차량 사양과 법규가 다르다. 그래서 한국에서는 노출해야 하는 기능이지만 외국에서는 막아야 하는 기능, 텍스트가 달라져야 하는 기능도 많다.

23년도에는 다국어 처리도 없이 그저 깔끔하게 한국어만 지원했었는데, 이제는 다국어를 20개 다루고 있다.

다국어와 함께 단위/온도 분기도 있다. 북미는 km 안 쓰고 mile 쓰고, 섭씨 안 쓰고 화씨 단위를 사용하니까. 아..

이렇게 어마어마한 소프트웨어 복잡도와 분기 처리를 고려하면서 일하다 보니, 머리가 지끈지끈하다.

그 외에도 테스트를 하다 보면, 차량 하드웨어에 문제가 있을 때도 있다. 클라이언트와 서버 모두 잘 해놨는데, 정작 버그의 범인은 차량일 때도 있다. 범인이 서버일 때도 있다.

마지막으로 앱 개발의 오너십이 우리 팀에 온전히 있지 않다. 이게 가장 믿기 힘든 부분인데, 설명하기도 어려우니 일단 넘어간다.

현대 서버에 대해서도 할 말이 많지만 비난이 될 수 있기에 쓰진 않겠다. 다들 자신의 자리에서 최선을 다 하고 있을 거라 생각한다.

난 입사 초반엔 앱과 위젯을 같이 하다가, 이제는 위젯/watchOS/인텐트(단축어) 위주로만 하고 있다.

전부 iOS 앱이 아니라, Extension 들이다. 그렇다. 나는 그렇게 DLC 전문가가 되었다. 는 농담이고, 아직 멀었다. ㅋ.. 위젯이나 와치나 인텐트나 굉장히 tricky and flaky 하기 때문에 열 받을 때가 많고 가끔은 좌절한다.

특정 OS 버전이나, 특정 아이폰 디바이스에서만 나오는 버그도 있는데, 이건 진짜 어떻게 고칠 방법을 찾기 힘들다. 재현도 어렵다. 그런 고객 VOC 가 들어오면 진짜 난감하다. 애플을 탓하고 싶지만, 고객들은 그런 걸 믿지 않아서 더 힘들다.

지난 레츠스위프트 뉴스레터(제122호) 에서 공감이 많이 되는 기사가 있었는데, 애플이 최적화보다 기능 추가에만 집중해서, 소프트웨어 품질 문제가 있다는 말이다.

Apple's Software Quality Crisis: When Premium Hardware Meets Subpar Software

이 글은 좀 제너럴한 내용이지만, 개발자 관점에서 미완성 상태로 느껴지는 프레임워크들이 있다. iOS 17 에서 나온 Interactive Widget 이 특히 그렇다. 아무튼 애플이 기존 프레임워크 버그들 좀 빨리 잡아주면 좋겠다.

그래도 현대차에서 개발하며 좋은 점이 있다면, 내가 만든 앱이 글로벌로 나간다는 거다. 흐미.. 내가 만든 기능이 전 세계로 진짜 나가도 되나? 부담될 때도 있지만, 책임감과 자부심을 가지려 노력하고 있다.

가끔씩 엄마나 와이프한테는 익살스럽게 과장해서, “나는 국가와 전 세계를 위한 일을 한다.” 고 표현할 때가 있는데, 생각해보면 진짜 그렇다.

일주일 뒤에 다시 독일에 2주 출장을 떠난다. 작년엔 2월에 다녀왔는데, 1년 만에 다시 독일에 간다. 올해도 무사히 다녀오고 싶다.

첫 번째 개인앱 <Chopinate!> 출시 이야기

당시의 기술 스택은 아래와 같습니다.

• 최소 버전: iOS 16
• 100% SwiftUI
• 그래프를 그리기 위한 Swift Charts 프레임워크
• Local DB: Realm
• Remote DB: Firebase Realtime Database
• 피아노 사운드: GarageBand 를 통해 추출한 57개의 mp3 파일

최소 기능을 담은 심플한 앱이었지만, 오가닉하게 다운로드가 꾸준하게 나오는 게 은근 기분이 좋았습니다. 개발자가 자신의 앱을 잊으면 안 되기에, 저도 가끔은 실행해서 악보 읽기 연습을 하곤 했어요.

지난 2년 동안 업데이트를 아~주 가끔씩 소소하게만 했었어요. 그러다 24년 12월, 연말 연휴 기간 동안 집중적으로 큰 업데이트를 준비했습니다.

전체적인 디자인 개선

<Chopinate!> V1(Version 1) 디자인이 플랫하고 단순했다면 V2 에서는 화려하면서도 고급스러운 분위기를 주고 싶었습니다.

그래서 화려한 그라데이션으로 배경을 장식했고, 폰트는 전부 세리프(serif)로 교체했습니다. 앱 아이콘까지 다 바꿨습니다.

위 스크린샷을 보시면, 큰 차이가 느껴지죠? ㅎㅎㅎ

라이트/다크 모드에 신경을 많이 썼습니다. 뭔가 한국에서 만든 앱이 아니라, 완전히 외국앱 처럼 디자인 하고 싶었어요. 실제로 지인들로부터 그런 평가를 많이 들어서 기분이 좋았습니다.

LocalDB 를 Realm → SwiftData 으로 전환

2024년 9월에, LocalDB 로 사용하고 있던 Realm 의 Deprecation 소식을 접했습니다. 당장 사용을 못하게 되는 건 아니었지만, 업데이트가 중단되는 건 확실했어요.

역시 애플의 퍼스트 파티를 사용하는 게 좋겠다는 생각이 들었고, 이왕에 새로 나온 SwiftData 로 모델링을 바꿔보기로 결심했습니다.

이 과정에서 ChatGPT o1 의 도움을 많이 받았습니다. 앱의 기능을 구체적으로 설명하고 그에 맞는 모델링을 부탁하니 발군의 성능을 보여줬습니다.

사운드 폰트(sf2) 적용

가장 큰 업데이트 중의 하나는 피아노 소리를 내기 위해 사용하던 57개의 mp3 파일을 모두 삭제해서 앱의 용량을 30% 가량 줄였습니다.

대신 ‘사운드 폰트’를 사용했는데요. 사운드 폰트는 저도 처음 알게된 신기한 개념이었습니다. 마치 폰트를 사용하듯 악기의 소리를 재생할 수 있는 파일입니다. 덕분에 피아노 소리를 내는 방법을 훨씬 간단하게 리팩토링 할 수 있었습니다.

예를 들어, 만약 가운데 도(C4) 소리를 재생하고 싶다면, 아래와 같은 코드를 통해 쉽게 재생할 수 있게 됐어요.

// 피아노 엔진 의존성
@EnvironmentObject private var pianoEngine: PianoEngine

// 피아노 소리를 내는 코드
pianoEngine.playSound(midi: 60) // middle C 의 midiValue

게임센터(Game Center) 도입

이전 글이 게임센터 내용이었는데요, 리더보드(leaderboard)와 업적(achievement) 기능을 추가하기 위해 게임센터(GameKit)를 도입했습니다.

[GameKit] SwiftUI 환경에서 Game Center 대시보드 present 하는 방법

유저들의 최고 점수를 비교하기 위해선 Remote DB 가 필요했습니다. 각자의 디바이스에서 최고 점수를 서버로 올리면, 비교를 통해 자신의 순위를 알 수 있으니까요.

기존에는 Firebase Realtime Database 를 사용하고 있었는데요, 게임센터의 리더보드 기능이 있으면, 이런 Remote DB 가 필요가 없었습니다. 그냥 애플 서버를 무료로 사용할 수 있는 것이지요.

게다가 게임센터는 로그인 기능까지 탑재하고 있으니, 애플 로그인이나 카카오 로그인 같은 절차를 구현하지 않아도 돼서 간편했습니다.

만약 앱을 실행한 유저가 게임센터 미로그인 상태라면, 위 스크린샷의 맨 왼쪽과 같은 sheet 가 뜨게 됩니다. 꼭 로그인을 하지 않고 sheet 를 dismiss 해도 앱을 사용할 수 있는데요.

그런 경우엔, 리더보드 탭에 진입했을 때, 로그인을 유도하기 위한 mock list 를 보여주는 식으로 구현했습니다. Medium 에서 유료 글을 보려고 하면 중간에 글이 끊기고 불투명해지는 것에 영감을 받았습니다.

Amplitude 도입

앱의 유저 데이터 분석을 위해 앰플리튜드를 처음으로 도입했습니다.

기존엔 구글 애널리틱스(GA) 조차 적용하고 있지 않았습니다. 데일리 유저가 많지 않으니 도입할 필요성을 못 느낀 것도 사실이구요.

하지만 V2 부터는 데이터 분석을 해보고 싶었어요. 유저 데이터를 보고, 앱을 개선하고 그 후에 다시 데이터를 보고 앱 개선하고… 그런 이터레이션을 해보고 싶었습니다.

많은 스타트업에서 앰플리튜드를 사용하고 있다고 하길래 저도 시도해봤는데요, 인터페이스가 깔끔하고 좋았습니다.

앰플리튜드 전문가인 와이프의 도움을 받아, 이벤트 로그를 앱 전체에 꼼꼼하게 심어놨습니다. 그래서 유저가 앱을 실행하고 어떤 행동을 하고 나가는지를 확인할 수 있어요.

유저를 몰래 염탐하는 것 같기도 하고 기분이 묘했습니다. 초라한 앱이지만 방문해준 유저들에게 감사한 마음도 들더라구요. 흑흑.

어쨌든 이런 로그가 꽤 쌓이면 유의미한 인사이트를 뽑아낼 수 있겠죠? 그걸 바탕으로 앱을 또 개선해나가려고 합니다.

하려고 했으나 못 한 것

네, 당연히 계획은 세웠지만 시간 관계상(힘들어서) 추가하지 못한 기능들도 있습니다.

먼저, OpenAI 연동인데요. 악보 연습 앱이지만, 단순히 랜덤하게 문제를 출제하는 것이 아니라 AI 를 활용해서 유저 맞춤형으로 문제 난이도를 조절하거나, 멜로디를 만들어내는 기능을 상상했습니다.

하지만 연휴 때 쉬지 않고 계속 앱을 개발하다 보니, 꽤 지치기도 했고 진도가 더뎠습니다. 아시겠지만, 회사 다니면서 사이드 프로젝트 하는 게 정말 힘들더라구요.

그래서 “아 모르겠다. 일단 V2 배포하고 나중에 생각하자!” 마인드로 배포부터 했습니다. ㅎㅎ

두 번째는 애드몹(AdMob) 광고 도입입니다.

네.. 개인/1인 개발 업계에서는 어쨌든 수익성이 중요합니다. 돈을 약간이라도 벌 수 있는 앱을 만들어보고 싶었어요. 진지하게 돈을 많이 벌고 싶다가 아니라, “돈이 벌리나?” 를 확인해보고 싶었습니다.

조만간 작은 배너 광고라도 추가해서 업데이트 해보려 합니다.

마지막은 지역화(localization) 입니다.

좀 웃기지만, V1 때는 지역화를 한국어/영어/일본어 → 3개나 해두고, 이번 V2 때는 100% 영어 앱으로 만들었습니다.

디폴트 언어를 영어로 해서 다 만들고, 나중에 지역화/다국어화를 추가하려 했는데, 막상 한국어로 번역하려고 하니 뭔가 어색하게 느껴지고 은근 고민하는 시간이 길어지더라구요.

특히 피아노/악보 주제의 단어들은 평소 접하기 어려운 생소한 단어들이라서, 번역을 하면 오히려 더 이상하게 느껴지는 것들이 있었습니다.

마찬가지로 “나중에 생각하자!” 마인드로 100% 영어 앱으로 배포하게 됐네요. 하하… 심지어 앱 소개 스크린샷도 전부 영어입니다.

궁금하신 분들은 아래 링크를 통해 앱 구경해보세요!

‎Chopinate!

감사합니다.

첫 번째 개인앱 <Chopinate!> 출시 이야기

당시에는 로그인도 없이, Firebase 를 사용한 간단한 DB 를 통해 유저들의 ‘점수’ 를 저장해서 나름의 리더보드(leaderboard) 를 구현했었다.

이번 2.0 버전을 개발하며 GameKit 을 도입했다. “GameKit” 이란 단어가 어색하더라도 “Game Center” 는 들어봤을 거다. 혹은 아래와 같은 알록달록 버블 아이콘은 본 적이 있을지도!

Game Center 는 애플이 제공하는 ‘소셜 게임 기능’ 플랫폼이다. 앱에 탑재만 하면 로그인, 친구 연동, 리더보드, 업적, 멀티 플레이어 기능을 간편하게 구현할 수 있다.

GameKit 은 개발 자료가 부족한 것도 사실이었다. 왜냐면 사이드 프로젝트나 심지어 회사에서도 자주 쓰는 프레임워크가 아니기 때문이다. 나름 희귀한 프레임워크를 사용하는 것도 재밌는 경험이니, 이번 2.0 개발하며 리더보드, 업적까지 알짜로 사용해 보고 있다. 아마 앞으로 GameKit 관련 글이 몇 개 이어질 수도 있다.

이번 글에서는 SwiftUI 환경에서 Game Center 의 대시보드를 present(띄우는) 하는 방법을 간단하게 공유하려 한다.

일단 게임센터 대시보드를 띄운다는 것이 뭘까?

아래는 개발 중인 <Chopinate!> 2.0 버전의 리더보드 화면인데, 게임센터 로그인을 했다면, 화면 우측 상단에 자신의 프로필 이미지가 보이게 된다.

이때 이 프로필을 클릭했을 때, 오른쪽과 같이 애플이 제공하는 게임센터 대시보드로 진입하는 걸 원했다.

구글에서 SwiftUI + Game Center 를 검색하면 자료가 많이 없다. 조금 오래된 코드들이 나오는데, 아마 UIViewControllerRepresentable 프로토콜을 사용해서 GKGameCenterViewController 를 래핑하는 자료가 나올 것이다.

ChatGPT 한테 질문하더라도 비슷하게 답변한다.

결론부터 얘기하면, 이렇게 래핑한 방식도 작동은 하지만, 뭔가 어색하다.

일단 NavigationLink 를 통해 GameCenterView() 를 호출하면 화면에 아무것도 나오지 않는다. (흰 화면만 나옴)

SwiftUI 환경에서 NavigationLink 가 안 되면, 당연히 다음은 모달(sheet, fullScreenCover) 이다.

코드는 간단하다. 프로필 모양 버튼을 누르면 sheet 를 띄울 건데, 그 안에 GameCenterView() 가 들어있는 것이다.

@State private var showsGameCenterModal: Bool = false

// 버튼 부분
Button {
  showsGameCenterModal = true
} label: {
  myPhoto
    .resizable()
    .scaledToFit()
    .clipShape(.circle)
    .frame(width: 36, height: 36)
}

// View 에서 sheet 띄우는 부분
.sheet(isPresented: $showsGameCenterModal) {
  GameCenterView()
}

sheet 를 통해 게임센터를 띄우면 위 gif 처럼 동작한다. (x1.5 배속이 걸린 점 참고)

작동은 하지만, 뭔가 어색하다. sheet 를 통해 트리거만 됐지, 실제로 sheet 위에 그려진 View 가 아닌 것이다.

그럼 어떻게 구현해야 할까?

먼저, UIViewControllerRepresentable 프로토콜은 전혀 사용하지 않는다.

나는 GameCenterManager 클래스를 만들어서 3가지 프로토콜을 채택시켜서 사용했다. 코드는 아래와 같다.

import SwiftUI
import GameKit

final class GameCenterManager: NSObject, GKGameCenterControllerDelegate, ObservableObject {
  
  func presentGameCenter() {
    let vc = GKGameCenterViewController(state: .default)
    vc.gameCenterDelegate = self
    self.presentGameCenterViewController(vc)
  }
  
  /// SwiftUI에서 Game Center ViewController를 present하는 메서드
  private func presentGameCenterViewController(_ viewController: UIViewController) {
    if let windowScene = UIApplication.shared.connectedScenes.first as? UIWindowScene {
      if let rootViewController = windowScene.windows.first?.rootViewController {
        rootViewController.present(viewController, animated: true)
      } else {
        print("🚨 RootViewController를 찾을 수 없습니다.")
      }
    }
  }
  
  // GKGameCenterControllerDelegate 프로토콜 준수하려면 구현 필요
  func gameCenterViewControllerDidFinish(_ gameCenterViewController: GKGameCenterViewController) {
    gameCenterViewController.dismiss(animated: true, completion: nil)
  }
}

NavigationLink, sheet 같은 것으로 띄우는 게 아니라, 뷰컨을 찾아서 거기에 직접 게임센터 뷰컨을 present 하는 방식이다.

코드를 이렇게 구현하면, SwiftUI 에서 띄우는 게 아주 편리하다. 버튼의 액션에서 호출만 하면 끝이다.

Button {
  gameCenterManager.presentGameCenter()
} label: {
  myPhoto
    .resizable()
    .scaledToFit()
    .clipShape(.circle)
    .frame(width: 36, height: 36)
}

아까 sheet 로 구현했을 때와 달리, 게임센터 대시보드가 자연스럽게 present/dismiss 되는 걸 확인할 수 있다.