나는 요새 바보가 된 것 같다. 아니, 원래 바보였는데 그걸 모르고 있었던 걸까? 확실한 건 동기부여(Motivation)이 잘 안된다.

무엇에 대해서? 내 본업인 코딩에 대해서다. 개발자라는 직업으로, 월급쟁이로 사는 처지에 무슨 배부른 소리냐 할 수도 있다. 근데 사실인 걸 어쩌나. 도대체 왜 이렇게 됐나? 바로 AI 때문이다.

처음으로 GPT 3.5 가 출시된 날을 기억한다. 그때는 내가 한 중소기업에서 iOS 개발자로 일하고 있을 때였다. 신기한 게 나왔다길래 웹사이트에 들어가서 진짜로 이런저런 질문을 해봤다. 오호라, 꽤나 괜찮은 답변이 와서 신기하게 느꼈다. 그런데 코딩도 잘한다길래, 코딩 질문을 해봤다. 방금 내가 만들고 있던 SwiftUI View 에 대해서 물었다. 조금 이상하지만, 그럴싸한 코드가 나왔다. 나는 신기해하며 슬랙에 공유하고 웹사이트를 닫았다.

그렇게 1년, 2년 … 시간이 흘렀다. 2026년인 지금은 직접 코딩하는 사람이 없다. 요새 출근해서 주변 개발자들 일하는 거 보면, 죄다 CLI 를 여러 화면으로 나눠 화면에 꽉 채워두고 있다. 원하는 걸 입력하면, 원하는 게 나온다. 마치 마법 같다. 이제는 누구나 마법사가 될 수 있다.

하지만 아이러니 하게도, 누구나 마법사가 될 수 있다면, 마법사는 전혀 특별한 존재가 아니다. ‘해리포터’가 특별한 건 세상에 마법의 존재를 모르는 ‘머글’ 들이 존재하기 때문이다.

문제는 AI 는 개발자를 바보로 만든다. 이 점에 대해서는 글로벌하게 공감대가 나오고 있다. 최근에는 아래와 같은 유튜브 영상이 알고리즘에 떴는데, 20년차 개발자가 AI 코딩을 그만두겠다고 선언하는 내용이다.

위 내용은 GeekNews <AI 사용을 그만두기로 한 이유> 에 한글로 요약되어 있다. 위 링크로 글을 읽어봐도 좋을 것 같다.

문제는 AI 를 그만 사용하기도 어렵다는 거다. 개발자의 생산성이 높아졌지만, 당연히 회사도 그만큼의 일을 당연시 생각한다.

“이거 AI 쓰면 하루도 안 걸리지 않아요?” by 디자이너

사실 진짜 하루도 안 걸리는 건 사실이다. 내가 <아내가 바이브 코딩을 시작했다> 글에서 쓴 것 처럼, 진짜 맘먹고 하면 개발을 해본 적 없는 사람도 뭐든 만들어낼 수 있으니까.

아내가 바이브 코딩을 시작했다

상황이 이렇다 보니, 마음과는 다르게 AI 를 더, 더, 더 쓰게 된다. 아니 써야 한다. 스킬을 만들고 MCP 붙이고 자동화할 거 찾아보고 난리도 아니다. 스타트업, 대기업 가릴 거 없이 요새는 ‘전사적 AX’ 한다고 광팔고 난리도 아니다.

하지만 점점 코딩이 재미가 없어졌다. 예전에는 손으로 타닥타닥.. 하면서 허접한 화면이라도 만들고 주변에 보여주는 재미가 있었다. 근데 지금은 대단한 걸 만들지 않으면 무가치한 것 처럼 느껴진다. 엥? AI 로 이런 건 금방 하잖아. 전혀 자랑할 게 아닌데? 남들도 다 이런 건 하는데?

그래서 요새는 집에 오면 코딩을 더 하진 않는다. 회사에서 하루종일 클로드하고만 대화하고 집에 오면, 이상하게 평소보다 더 지쳤다. 몸이 지친 게 아니라, 심리적으로 뿌듯함을 느끼지 못해서 그런 것 같다.

그래서 나는 AI 에 절여진 뇌(brain)를 회복시키기 위해 새로운 루틴을 시작했다. 나는 요새 이런 걸 하며 지낸다.

알고리즘 공부 (LeetCode)

갑자기 코딩 테스트 준비? 그건 아니다. 내가 원했던 것은 뇌를 자극할 수 있는 브레인 티징(Brain teasing)이었다. 그리고 어떤 비즈니스 도메인하고도 관련이 없는 순수한 코딩은 바로 알고리즘이었다!

그래서 신입 개발자 취준할 때는 별로 열심히 하지 않았던 알고리즘 공부를 하고 있다. 대단한 건 아니고, 리트코드에서 Easy 난이도 문제로 시작했다.

부끄럽지만, 내 머리로 문제를 푸는 기분이 오랜만이었다. 쉬운 문제라도 정답을 맞추면 짜릿함까지 느꼈다. 취미로 고등학교 수준의 수학 공부를 하는 사람들도 있다던데, 대충 비슷한 느낌이겠구나 싶었다. 대신 나는 개발자니까, 수학 공부 보다는 알고리즘 공부를 하는 게 장기적으로도 도움이 될 것 같다.

이왕 공부하는 김에 알고리즘 풀이에 유리한 Python 언어까지 공부했다. 나는 iOS 개발자라 Swift 언어만 할 줄 알았고 다른 언어에 대한 심리적 허들이 있었다. 근데 클로드 통해 Swift 랑 Python 비교 하면서 공부하니까 금방 배울 수 있었다.

오히려 Swift 언어 같이 type strict 한 언어를 하다가, Python 처럼 type 이 상대적으로 느슨한 동적 타입 언어를 배우니까 훨씬 자유로운 느낌이라 재밌었다.

영어 원서 읽기

영어 공부는 매일 꾸준히 하고 있다. 아래 글은 2023년 전에 쓴 글인데, 글에서 언급한 영어 앱들은 아직도 매일 하고 있다.

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

나는 좀 더 많은 영어 인풋을 원했다. 그리고 나는 내러티브(Narrative)를 굉장히 좋아하니까, 이왕 인풋하는 거 영어 소설을 읽기로 했다.

내가 처음으로 선택한 책은 <Hidden Pictures> 였다. 내가 좋아하는 스릴러 장르를 선택했다. 근데 370페이지 짜리인 줄은 몰랐다. 모르는 단어는 다 체크하면서 읽었더니, 다 읽는데 3달이 넘게 걸렸다.

다음으로 고른 책은 <Piranesi> 인데, 요즘 읽고 있다. 아내가 맷 데이먼을 인터뷰하던 사람이 자기 인생 책이라고 맷에게 선물로 줬는데, 궁금하다고 해서 같이 읽으려고 샀다. 아내는 이틀 만에 다 읽었다. 나는 또 천천히 영어 공부하며 읽는 중이다.

소설을 읽을 때는 잠깐 그 세상으로 빠져드는 기분이 좋다. 그리고 AI 가 따라 할 수 없는 위대한 작가들의 문장을 더 많이 읽고 싶다.

인디 보드게임 개발

나는 보드게임을 좋아한다. 각 게임이 가진 독특한 메커니즘을 경험할 때마다, 작가들의 창의성에 감탄하곤 한다. 재밌는 점은 보드게임을 만드는 사람들도 ‘작가’ 라고 부른다. “소설 작가” 처럼 “보드게임 작가” 라고 부른다.

그 이유는 판매에 대한 인세로 수익을 얻는다는 공통점도 있지만, 사람들이 즐거운 시간을 보낼 수 있는 창작물을 만드는 사람들이기 때문이다. 물론 개발자가 만드는 웹이나 앱도 창작물이긴 하지만, “코딩 작가” 혹은 “앱 작가” 라고 부르지는 않는다.

이 작가의 영역이 바로 나의 추구미다. 저 영역으로 들어가고 싶다. AI 로 대체하기가 어려운 영역이다. 바이브 코딩과는 다르다. 속된 말로 똥게임은 만들 수 있으나, 개성있고 또 하고 싶은 게임을 만드는 건 차원이 다르게 어려운 일이다.

궁금하신 분들은 AI 를 써서 직접 보드게임 제작에 도전해보시면 좋겠다. 은근히 이 분야가 미개척지다. 이 점에 대해선 할 얘기가 많다. 나중에 다른 글로 써봐야겠다.

아무튼, 올해는 인디 보드게임을 하나 만들어보는 게 목표였다. 2025년 겨울에 한국보드게임작가협회(KTDA)에 정회원으로 가입하고 가끔 모임도 나갔다. 그러다 보니 유명한 국내 보드게임 작가 분들과도 인사를 나누고 조언도 받을 수 있었다.

보드게임 개발 업계에도 공모전이 있다. 대표적으로 <PnP 공모전> 이 있는데, “Print and Play” 의 약자로, 프린터로 간단하게 뽑아서 바로 즐길 수 있는 간단한 보드게임을 말한다. 인디 작가들이 많이 도전하는 단계이기도 하다. 나는 여기에 도전했다.

결론적으로 나는 완전 실패했다. 심지어 제출도 못했다. 혼자서 이런 저런 아이디어를 많이 생각했으나, 그걸 프로토타이핑 하는 과정에서 좌절했다. 재밌는 아이디어가 떠올라서, 구체화 하다 보면 재미가 없어지는 과정이 반복됐다. 클로드에게 물어봐도 답이 안 나오다 보니, 답답함을 많이 느꼈다.

솔직히 말하면, 내가 보드게임 제작을 만만하게 봤던 것 같다. 기성 작가들의 공통적인 조언은 “처음부터 좋은 게임을 만들 수는 없다. 많이 실패해보고, 많이 피드백 받다 보면 하나가 우연히 걸린다.” 이런 거였는데, 팩트였다. 뼈저리게 느꼈다.

아직 포기한 건 아니다. 가끔 보드게임 아이디어가 떠오르면 계속 메모장에 적어두고 메커니즘을 생각한다. 언젠가는 꼭 내 이름으로 된 게임을 출시하고 싶다.

뉴비인 나에게 값진 조언을 해주신 <문라이트게임즈>의 문지인 작가님, <플루토게임즈>의 주봉환 작가님, 그리고 <초이스 보드게임>의 최경운 작가님에게 이 글을 빌려서 감사 인사를 전합니다.

아내가 바이브 코딩을 시작했다. (2편)

<슈점터>를 배포하고 3주 뒤, 아내는 또 새로운 프로젝트를 시작했다.

퀴즈 게임 웹사이트를 만들어보고 싶다고 했다.

회사에서 주기적으로 올핸즈 미팅을 하는데, 그때 당장 사용하는 것을 목표로 일주일 안에 개발하겠다고. 그러니까 <카훗>이나 <퀴즈앤>을 대체하는 프로덕트를 만들겠다고!?

나는 나름 단체 퀴즈 게임의 전문가다. 작은 사이즈로 여러 번, 가장 크게는 현대차에서 센터원 전체를 모아서 400명 규모로 진행해 본 적이 있다.

그래서 이런 퀴즈 사이트의 가격 정책이 굉장히 별로라는 건 익히 알고 있었다.

학교 선생님이 아닌 이상, 직장인이 이런 퀴즈 게임 만들 일이 1년에 1~2번 있을까 말까 인데, 카훗은 보통 1년 구독 단위로 판매하고 생각보다 엄청 비싸다.

최대 참가자 수도 교묘하게 제한되어 있고 1달 단위 결제는 없다. (혹은 극도로 숨겨져있다.)

퀴즈 게임 한 번 하려고 1년 단위 결제를 해야 하는 게 말이 되나?

<퀴즈앤>은 ‘국산 카훗’ 이라고 불리는데, <카훗>보다는 저렴하지만, 여전히 비싸게 느껴진다.

아내도 비슷한 고충을 느끼고 있었다. 그래서 무료로 쓸 수 있고 핵심 기능에 집중한 퀴즈 게임 메이커를 만들기로 결정했다.

바이럴이 되거나 큰돈을 버는 걸 목표로 하지 않았다. 최소한 쓸만한 퀄리티로 만들어서 당장 일주일 뒤 올핸즈 미팅에서 사용할 수 있다면 <카훗> 1년 구독비를 아낄 수 있으니까.

바로 결과물부터 공유한다. <qizu> 라는 이름의 카훗 킬러…

프로덕트 이름은 내가 아이디어를 줬는데, “quiz” 의 스펠링을 재배열해서 귀여운(?) 발음으로 만든 것이다. 집에서는 “키주" 라고 부른다.

qizu - real-time team trivia

퀴즈 게임의 핵심 요소는 간단하다. 문제 타입은 객관식과 True/False 정도면 충분하다. 게임에 여러 명이 참여하고 동시에 문제를 확인할 수 있어야 한다. 마지막으로 빨리 맞출수록 큰 점수를 얻게 하면 된다.

<키주> 는 이런 핵심 기능에 집중한 가벼운 퀴즈 메이킹 도구다.

<키주>에는 카훗에는 없는 “데모” 기능이 있다. 단체 퀴즈 게임의 바이브를 웹에서 그대로 느끼면서, 키주의 기능이 카훗과 별 차이가 없음을 사용자들이 느꼈으면 했다.

이 데모를 만들기 위해 아내는 <미드저니> 와 <SUNO> 를 결제했다. 즐겁게 퀴즈에 참여하는 POV(Point of View)를 예쁜 그림체로 생성하고 파티에 어울리는 신나는 배경 음악을 만들었다.

짧은 기간 동안 집중적으로 만든 프로덕트라서 대규모로 게임을 진행할 때도 문제가 없을까 걱정이 되긴 했다. 다행히 아내는 올핸즈 미팅에서 30명 규모의 퀴즈를 아무 문제 없이 진행했다고 한다.

지금 <키주>는 완전히 무료다. 로그인만 하면 즉시 퀴즈 게임 생성/플레이가 가능하다. 이 글을 읽으신 분들이 가족 행사나 팀 워크샵에서 사용해 보시고 피드백을 주신다면 정말 감사할 것 같다.

여기까지 읽으셨다면 느끼셨겠지만, 아내의 바이브 코딩 시리즈가 처음에는 ‘개발자 남편’의 짧은 소감이었다. 프로그래밍을 해본 적 없는 사람이 뚝딱 무언가를 만들어냈니.. 남편이 병목이었느니.. 난 이제 이런 얘기를 하지 않는다.

당황스러울 정도로 바이브 코딩을 잘하고 있다. 솔직히 개발자인 나도 이 정도로 진지하게 프로덕트를 만든 적이 없다. 요새 현타도 많이 느끼고 있는데, 나는 그냥 아내를 더 잘 도와주는 것에 집중하기로 했다.

뭔가 만들고 싶다고 하면, 응원해 주고 아이디어를 보태준다. 완성되면 블로그에 써서 홍보를 도와준다. 시간이 지나면서 점점 내 역할을 찾아가고 있다.

아내 바이브 코딩 시리즈는 4편, 5편 … 계속 나올 수 있다. 이 글을 쓰는 지금은 맥앱(Mac Application)을 개발하고 있다. 이왕 프로덕트를 많이 만든 김에 자기 포트폴리오까지 웹 버전으로 만들고 있다. 다음 글에서 또 소개해보겠다.

아내가 바이브 코딩을 시작했다

위 글을 작성한 날짜가 2026년 5월인데, 아내가 그 이후로 계속해서 뭔가 만들어냈다. 그 결과물을 좀 더 정리해 보려 한다.

개발자 남편의 아내 관찰 일지(?) 느낌이 나는데, 놀라움을 넘어서 이제는 나보다 한참 잘한다. 소프트웨어 개발자라는 직업이 진짜 위험하다는 걸 집에서 같이 사는 아내가 직접 느끼게 해줬다.

아내는 iOS 앱 <베이크북> 을 배포하고 난 뒤에 마케팅 및 운영 기간을 가졌다.

어느 날 팀원들이 점심 메뉴 고르는 데 은근히 많은 시간을 고민한다고 얘기를 했다. 그래서 ‘점심 메뉴 추천’하는 서비스를 만들어 보고 싶다고 했다. 나는 또 반대했다. 왜냐면 점메추하는 웹이나 앱이 너무 많았고 흔하기 때문에 차별점 만들기 어렵다고 생각했다.

그럼에도 아내는 퇴근하고 바로 개발을 시작했다. 점메추 서비스가 흔하고 재미없으니까, 인형 뽑기 컨셉을 적용해 보겠다고 했다. 이번에는 더 많은 사람들이 쓸 수 있도록 앱이 아니라 웹으로 만들기로 했다.

로직은 간단했다.

뽑기 버튼을 누르면 → 랜덤하게 점심 메뉴가 추천된다.

여기에 최소한의 선호 메뉴를 선택할 수 있게 만들었다. 인형 뽑기 게임 컨셉에 맞게 가상의 코인을 사용해서 뽑기를 할 수 있는데, 하루 최대 3개의 코인만 주어진다.

디벨럽하는 과정에서 새로운 기능을 넣기도 했다. 사용자 위치의 날씨 정보를 이용해서 메뉴 추천에 반영한다. 구글 Gemini API 를 이용했다.

캐주얼 게임 분위기를 내기 위해 배경음악도 추가됐다. 이것도 Gemini 로 만들었다. (나는 제미나이가 음악을 만드는 기능이 있다는 건 몰랐다.)

Lyria - Gemini AI 음악 및 노래 생성기

여담이지만, Gemini 가 만들어주는 음악이 Suno 보다는 퀄리티가 조금 부족하다. 그래도 간단한 배경음악은 상당히 잘 만들어준다. 게다가 무료라는 게 큰 장점이다.

그리고 여러 명이 참여하는 팀전도 있다. URL 을 만들어서 공유하면, 친구들이 닉네임을 설정해서 방으로 들어온다. 각자 메뉴를 뽑으면 인형뽑기 기계에 추가되고 그중 하나가 선택된다.

마지막으로 아내는 도메인까지 구매한 뒤에 배포했다.

서비스 이름은 <슈퍼 점메추 터보> … 줄여서 “슈점터” 라고 부르기로 했다. 아래 링크에서 체험할 수 있다.

SUPER JEOMMECHU TURBO

<슈점터>를 만들면서 아내는 클로드 Pro 한도가 답답하다고 클로드 Max 를 결제했다. 무려 한 달에 15만 원! 개발자인 나도 Max 는 결제해 본 적이 없었는데 말이다.

아내는 이렇게 바이브 코딩으로 iOS 앱과 웹서비스를 배포했다. (와중에 나는 새로운 사이드 프로젝트를 하나도 만들지 못했다.)

아내의 AI 활용 능력이 눈에 띄게 늘어났다. 아내의 본업이 PM 이니까, 개발을 직접 하진 않더라도 기술에 대한 이해도가 높다. 그래서 언제 어떤 기능이 필요한지를 이미 알고 있으니까, 바이브 코딩의 생산성이 더 크게 높아졌다.

지난 글에서, 개발자 남편이 오히려 아내의 바이브 코딩에 ‘병목’ 을 일으켰다는 걸 기억하고 있다. 그래서 요즘에는 아내가 무엇을 만들어도 방해하지 않는다. 오히려 칭찬해주고, 어떻게 하면 더 도와줄 수 있는지를 고민한다.

아내는 <슈점터> 이후로 각성했는지 엄청난 걸 하나 만들어냈다. 그건 바로 다음 글에서 정리해 보겠다.

아내는 GPT, Gemini 같은 LLM 은 꾸준하게 사용해 왔으나 코딩까지 한 적은 없었다. 그러다 1달 쯤 전에 바이브 코딩을 해보겠다고 선언했다.

만들고 싶은 앱이 있다고 했다. 아내는 평소 집에서 베이킹(제빵)을 많이 한다. 홈메이드 베이킹. 손재주가 좋아서 베이글, 바게트, 피자, 쿠키 등 다양하게 만든다.

베이킹 앱? 특이하다고 생각했다. 요새는 엄청나게 많은 바이브 코딩 앱들이 나오고 있지만, 베이킹이 흔한 주제는 아니라고 생각했다.

아내에게 Claude Pro 1년 구독권을 선물했다. 그리고 처음에 세팅만 도와주고 어떤 기술들이 편할 것이라고 조언만 했다. 예를 들면, 서버는 SUPABASE 로 MCP 연결해서 하면 구성하기 쉽다더라. 이 정도?

아내는 회사에서 매니저 역할도 하고 있어서 일을 굉장히 많이 한다. 평일에는 12시간 정도 근무하고, 가끔 주말에도 일한다. 그래서 퇴근하고 집에 오면 밤 10–11시 정도다.

이 상태에서 쉬지도 않고 매일 2~3시간씩 바이브 코딩을 했다. 사실 나는 좀 걱정이 앞섰다. 왜냐면 요새 바이브 코딩으로 개인 앱이 하도 많이 나오니까, 앱 다운로드가 잘 나오기 진짜 어렵다. 무엇보다 출시는 한다고 쳐도, 결국 ‘운영’ 이 쉽지 않다는 걸 알고 있으니까.

내 우려와 달리, 아내는 되게 즐겁게 만들고 있었다. 이런저런 기능도 기획하고, 앱에 들어가는 아이콘이나 작은 에셋은 직접 손으로 그렸다.

그렇게 아내 혼자서 2주 만에 앱을 개발해서 배포했다. 앱스토어 배포한 뒤에는 인스타그램, 스레드에 동시에 마케팅을 전개했다.

https://www.instagram.com/bakebook.app

앱의 이름은 <Bake Book> 으로, 홈베이커들을 위한 베이킹 기록, 레시피 저장, 커뮤니티 기능을 가진 앱이다.

이제부터 웃긴 이야기를 하자면, 아내가 2주 동안 앱을 하나 만들 동안, 나는 방해만 했다. 어떤 방해를 했냐면…

아내: “캘린더 기능을 넣고 싶어.”

유저들이 그 날 올린 베이킹 기록을 커스터마이징된 캘린더 위에서 볼 수 있길 원했다.

나는 캘린더 기능은 어렵고 버그가 많이 날 것 같으니, 배포한 뒤 안정되면 만들자고 제안했다. → 아내는 30분 뒤 캘린더를 완성해서 가져왔다.

아내: “베이킹 기록 피드, 댓글 기능을 만들고 싶어.”

유저들이 서로 소통할 공간을 갖길 원했다.

나는 유저도 많지 않은데 벌써 피드를 생각하냐고, 나중에 하자고 제안했다. → 아내가 주말 하루 동안 만들어서 배포를 준비하고 있다.

아내: “홈베이커들의 커뮤니티를 만들고 싶어.”

아내는 베이킹 커뮤니티를 만들고 싶어 했다. 서로 레시피 공유하고 만든 빵 사진도 공유하면서 소통하는 그런 장소를 꿈꾸고 있었다.

나는 그런 건 유저가 일단 모여야 하는 거라고 조언했다. → 아내는 진심으로 참여할 소수의 베타테스터를 모집하겠다고, 모집 form 을 만들고 인스타그램/스레드로 홍보할 준비를 시작했다.

나는 현업 개발자인데 아내의 바이브 코딩에 병목 현상만 만들고 있었던 것이다. 나는 그렇지 않다고 생각했는데, 어느새 나도 “안 된다.” 라고 말하는 개발자가 되어 있었다.

아내의 바이브 코딩을 보며 배운 점이 있다면, 개발자라는 직업을 가진 내가 오히려 겁이 많고, 방어적이고, 느리게 개발하고, 편견이 있다는 것을 알게 됐다.

개발해 본 적이 없지만, AI 를 잘 다루고 만들고자 하는 게 뚜렷한 사람이 더 용감하고 더 빠르게 뭔가 만들어내는 걸 봤다.

나는 Maker 가 아니고 그냥 직업으로서의 개발자였나 하는 반성도 하고 있다.반성뿐만 아니라, 개발자라는 직업의 미래에 대한 고민이 생겼다. 어떤 고민을 하는지는 나중에 다른 글로 풀어보겠다.

요즘엔 어떤 취미를 갖고 있는 지도 커리어에 영향을 준다. 아내의 경우는 그녀가 베이킹을 좋아하기 때문에 베이킹 앱이 탄생한 것이다. 최근 관심 있게 보는 1인 개발 앱인 Kyro 도 러닝을 좋아하는 분이 만들었다.

내 취미가 무엇인가? 나는 애니메이션, 인디 공포 게임, 보드게임을 좋아한다. 외국어 공부, 사람들 만나는 거, 도와주는 걸 좋아한다. 앞으로는 취미에 좀 더 시간을 써야겠다. 그러면 오히려 본업이 더 잘 풀릴 수 있으니.

아내의 앱 <Bake Book> 링크는 아래에! (iOS only)

Bake Book - 베이킹 기록, 레시피, 도구 앱 - App Store

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

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

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

그러다 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)