14장짜리 생일 앱을 친구 한 명을 위해 만들었다

한눈에 요약 친구 한 명에게 한 번 보여주기 위한 14장짜리 생일 앱을 만들었다. 이미지 생성만으로 원하는 장면을 맞추기 어려워지자, 앱 안에 콘티 편집기를 만들고 내가 직접 의도를 배치하는 방식으로 바꿨다. 완성 기준은 빌드 성공이 아니라 실제 노트북에서 마지막 장면까지 보여주는 것이었다.

처음에는 우사기 애니메이션으로 시작해 짧은 게임을 지나 편지로 끝나는 생일 선물을 만들고 싶었다. 문제는 머릿속 장면이 이미지 생성 결과에 제대로 나오지 않았다는 것이다. 컷마다 캐릭터와 방의 분위기가 달라졌고, 날짜와 숫자는 뭉개졌고, 여러 행동이 한 장면에 들어가면 의도한 구도가 자꾸 틀어졌다.

더 잘 설명하면 다음 결과는 나아졌지만, 그 방식으로 모든 장면을 다시 뽑다가는 정작 생일까지 앱을 끝내지 못할 것 같았다. 그래서 이미지를 계속 생성하는 대신 제작 방식을 바꿨다. 내가 장면을 직접 배치하고, AI 코딩 에이전트(Codex·Claude Code처럼 코드를 만들고 확인하는 도구)가 그 상태를 읽어 구현할 수 있는 웹 기반 콘티·상호작용 편집기를 앱 안에 만들었다.

그 편집기를 거쳐 최종 상영본은 14장이 됐다. 2026년 8월 2일에는 실물 노트북에서 전체 흐름과 소리를 확인했고, 친구에게 앱을 실제로 보여줬다.

예쁜 화면보다 먼저 이야기의 이유를 맞춰야 했다

이 앱의 관객은 한 명이었다. 한 번 보여주고 나면 같은 방식으로 다시 쓸 일도 거의 없었다. 그래도 생일 축하 화면 몇 장을 이어 붙이는 것으로 끝내고 싶지는 않았다.

처음부터 생일 앱이라고 밝히면 마지막 공개가 약해진다. 반대로 정체를 너무 오래 숨기면 친구는 왜 이 화면을 보고 있는지 이해하지 못한다. 그래서 시작은 우사기 애니메이션처럼 보이게 하고, 중간에는 직접 눌러보고 찾아보는 장난을 넣고, 마지막에야 생일 축하와 편지를 공개하는 흐름을 잡았다.

막상 콘티를 짜보니 어려운 건 그림 한 장의 완성도가 아니었다. 이 장면을 왜 보고 있는지, 다음에는 무엇을 해야 하는지, 눌렀을 때 어떤 반응이 나와야 재미있는지를 이어 붙이는 일이 더 어려웠다.

처음 만든 4막 16씬 구조는 하고 싶은 것이 너무 많았다. 이후 3막 7씬으로 줄였다가 다시 13장 콘티를 거쳤고, 마지막에 별도 선물을 공개하는 장을 더해 공식 상영본을 14장으로 고정했다. 장면 수를 줄였다 늘린 이유는 더 화려하게 만들기 위해서가 아니라, 친구가 설명 없이도 끝까지 따라갈 수 있게 하기 위해서였다.

이미지 프롬프트 대신 조정할 수 있는 화면을 만들었다

이미지 생성 도구에 원하는 장면을 말로 설명하는 데에는 한계가 있었다. “여기에는 달력이 있고, 이 날짜만 정확히 보여야 하고, 캐릭터는 저쪽을 보면서 특정 행동을 해야 한다”처럼 조건이 늘어날수록 한 부분을 고치면 다른 부분이 달라졌다.

내게 필요했던 건 새로운 프롬프트가 아니라 내가 직접 의도를 고정할 수 있는 화면이었다.

그래서 앱에 편집 모드를 붙였다. 이미지를 놓고 크기와 위치를 바꾸는 것에서 끝내지 않았다. 각 장면에 처음 보이는 것, 친구가 할 행동, 성공했을 때의 반응, 실패했을 때의 반응, 웃음이 나와야 하는 지점과 배경음악까지 적을 수 있게 했다.

편집 결과는 JSON이라는 구조화된 데이터로 보였다. JSON은 화면에 놓인 요소와 행동 규칙을 컴퓨터가 읽을 수 있게 정리한 형식이다. 나는 편집기에서 콘티를 직접 조정했고, AI 코딩 에이전트는 그 구조를 읽어 실제 화면과 동작을 구현하고 확인했다.

역할도 나눴다. 나는 이야기 구조와 장면 배치를 정하고 결과를 판단했다. Codex는 구현을, Claude Code는 문서와 프롬프트 정리, 브라우저 확인을 중심으로 맡았다. AI에게 “생일 앱을 알아서 만들어줘”라고 맡긴 게 아니라, 내가 의도를 고정한 뒤 서로 다른 작업을 맡긴 방식에 가까웠다.

브라우저에 보인다고 전달본에도 있는 건 아니었다

편집기를 만들고 나서 한 번 더 크게 막혔다. 내가 브라우저에서 완성한 콘티가 다른 노트북에서는 그대로 나오지 않을 수 있었다.

첫 초안은 브라우저 내부 저장 공간에만 남아 있었다. 내 컴퓨터에서는 멀쩡히 보이지만 새로 받은 저장소나 친구 노트북에는 그 상태가 따라가지 않는다. 화면을 완성했다고 생각했는데, 정작 전달본에서는 과거 콘티가 열릴 수 있는 구조였다.

이 문제를 해결하려고 편집 중인 초안과 실제 상영할 공식 콘티를 분리했다. 최종 장면 순서와 행동은 Git에 고정하고, 이미지도 파일 위치가 조금 바뀌어도 찾을 수 있는 안정적인 ID로 연결했다. Git은 코드와 변경 기록을 함께 보관하는 도구다. 이렇게 해야 내 브라우저가 아닌 새 환경에서도 같은 14장이 다시 만들어졌다.

이때부터 “내 화면에서 된다”는 말은 완료 조건에서 빠졌다. 새로 받은 상태에서 빌드되는지, 서버나 계정 없이 전달본의 HTML 파일로 열리는지, 처음부터 마지막까지 진행되는지를 따로 확인했다.

장난 때문에 진행이 멈추면 안 됐다

중간 장면에는 버튼이 도망가거나, 화면 속 단서를 찾아 눌러야 하거나, 예상과 다른 선택에 반응하는 장난을 넣었다. 이런 장면은 보는 사람보다 만든 사람이 구조를 더 잘 알기 때문에 쉽게 착각한다. 나는 어디를 눌러야 하는지 알지만 친구는 모른다.

그래서 정답 행동만 넣지 않았다. 잠시 지나면 힌트가 보이고, 다른 방식으로 눌러도 넘어갈 수 있고, 일정 시간이 지나면 다음 장면으로 갈 수 있는 빠져나올 길을 함께 만들었다. 웃기려고 넣은 장치가 상영을 멈추는 벽이 되지 않게 하기 위해서였다.

편지 뒤의 흐름도 같은 기준으로 고쳤다. 처음에는 편지가 끝나면 다음 선물 장으로 자동 이동했는데, 감정을 느낄 시간을 코드가 정하는 모양이 됐다. 마지막에는 친구가 직접 선택해 다음 장으로 넘어가도록 바꿨다.

빌드 성공이 아니라 실물 노트북 완주를 끝으로 잡았다

코드가 빌드되고 자동 검사가 통과해도 실제 상영은 다를 수 있다. 소리가 너무 늦게 나오거나, 전체 화면에서 버튼이 가려지거나, 터치패드로는 의도한 동작이 불편할 수 있다. 그래서 완료 기준을 실물 노트북에서 처음부터 끝까지 한 번 완주하는 것으로 잡았다.

2026년 8월 2일, 공식 14장과 오디오를 실제 노트북에서 확인했다. 같은 날 친구에게 앱도 보여줬다. 친구가 내가 예상한 것보다 크게 감동한 모습에 나도 놀랐고, 친구는 나중에 울었다고 말했다.

정확히 어떤 문장을 먼저 말했는지, 어느 장면에서 가장 크게 반응했는지는 기록하지 못했다. 그 부분을 그럴듯한 대사로 채우지는 않으려고 한다. 내가 확실히 남길 수 있는 건 작은 장난과 편지로 설계한 흐름이 생각보다 크게 전달됐다는 사실이다.

원본을 지운다고 공개판이 되는 건 아니다

현재 앱에는 친구의 얼굴 사진, 실명, 사적인 문장과 우사기 이미지가 들어 있다. 이 원본과 저장소, 실행 파일은 공개하지 않는다. 이름을 가리고 사진 몇 장을 지우는 것만으로 안전한 공개판이 되는 것도 아니다. 파일과 코드 기록에 개인 정보가 남을 수 있고, 캐릭터 자산을 다른 사람이 다시 써도 된다는 권리도 없기 때문이다.

나중에 공개한다면 현재 앱을 정리해 올리는 방식이 아니라, 생일 앱 빌더를 별도 프로젝트로 다시 만들 생각이다. 사용자가 자기 사진과 문구, 장면을 브라우저 안에서 넣고 미리 본 뒤, 서버 없이 실행되는 단일 HTML이나 ZIP으로 내보내는 도구다. 샘플도 직접 만들거나 사용 권리가 분명한 자산만 써야 한다.

아직 그 빌더와 공개 저장소는 없다. 그래서 지금 글에는 다운로드나 GitHub 링크도 넣지 않는다. 이번에 먼저 남기는 것은 완성된 개인 선물 자체보다, 의도가 어긋났을 때 제작 방식을 바꾸고 실제 전달까지 책임진 과정이다.

한 번만 쓰는 물건이라고 대충 만들 필요는 없었다. 오히려 다시 기회가 없기 때문에 마지막 장면까지 직접 확인해야 했다. 이번 작업에서 완성은 코드가 돌아간 순간이 아니라, 친구가 그 14장을 실제 노트북에서 끝까지 경험한 순간이었다.

관련해서 먼저 읽어볼 만한 글:

• AI에게 이틀을 맡겼다: 무인 작업 12건, 코드 변경 34건의 기록
• 바이브코딩으로 2시간 만에 웹사이트 배포한 후기