셀프케어 체크 프로젝트 소개
맥북에어에서 Codex로 만들어 둔 셀프케어 웹 프로토타입을, Claude Code로 토스 미니앱 「셀프케어 체크」로 다시 지어 콘솔 등록과 실기기 테스트까지 마쳤어요. 프로토타입 코드를 그대로 옮긴 게 아니라, 먼저 "설계 한 장"을 쓰고 그 문서대로 새 프로젝트를 만든 과정이에요.
바쁘시면 이것만 읽어도 돼요
도구: Claude Code(Fable 5.1) + 앱인토스 콘솔 MCP + Claude in Chrome + codex-image. 목표는 웹 프로토타입을 토스 미니앱으로 옮겨 실기기에서 여는 것
핵심: 프로토타입은 코드가 아니라 설계도로 썼어요. 가져올 것과 버릴 것을 표로 정리한 뒤 토스 틀(create-ait-app + TDS)로 새로 만들었어요
인상적이었던 순간: "점검 날짜를 사용자가 정하게 해 달라", "매일도 넣어 달라" 같은 요청이 설계 문서의 규칙 한 줄로 바뀌고, 그 줄이 코드와 테스트로 이어지는 흐름
배운 것: 단계마다 완료 기준을 정해 두면 AI가 "다 됐다"고 할 때 무엇을 확인할지 분명해져요
이런 분들께 도움돼요
ChatGPT·Codex로 웹 프로토타입은 만들었는데, 앱 스토어(토스 미니앱)에 올리는 단계가 막막한 분
앱 하나를 여러 날에 걸쳐 AI와 이어 만들어야 해서, 결정 사항이 흩어질까 걱정인 분
종이 양식(체크리스트)을 앱으로 옮겨 보고 싶은 분
프로토타입의 문제점
프로토타입은 맥북에어에서 Codex로 만든 한 파일짜리 React 앱이었어요. 탭이 네 개(오늘·균형·나눔·나침반), 삶을 다섯 영역으로 1~5점 매기는 주간 점검, 월간 공유까지 들어 있었죠. 화면은 그럴듯했지만 토스 미니앱이 아니었어요. shadcn·tailwind로 짜여 있고, 사용자 이름·날짜·점수가 전부 가짜로 박혀 있고, 점검이 바텀시트에서 진행돼서 토스 출시 가이드와도 맞지 않았어요.
같은 날 만들 앱이 두 개(AI 단어 퀴즈, 셀프케어)라 한 세션에서 병렬로 갈지부터 물었어요.
Open optionsauto
토스 미니앱 2개 설계했는데, 하나씩 구현해보자. … 병렬로 여기서 작업할 수 있어? 아니면, 따로 세션을 만들어서 따로따로 작업을 할까?
Claude는 세션을 나누자고 했어요. 앱마다 단계별로 제가 확인하고 결정해야 하는데, 한 세션에서 번갈아 다루면 한 앱의 결정이 다른 앱에 섞일 수 있다는 이유였어요. 대신 두 세션 모두 같은 상위 폴더에서 열어야 세션 메모리를 공유한다고 알려 줬고요. 이 세션은 셀프케어 앱으로 정했어요.
셀프케어 체크 진행 방법
사용한 도구
Claude Code (Fable 5.1) — 설계 문서, 코드, 테스트, 브라우저 검증, 콘솔 등록까지 전부
앱인토스 콘솔 MCP — 미니앱 등록, 로고 업로드, 번들 업로드, 테스트 푸시
Claude in Chrome — 개발 서버를 열어 화면을 직접 눌러 보며 검증
codex-image 스킬(gpt-image-2) — 앱 로고
color-palette 스킬 — 메인 컬러와 영역색을 명도 대비 검증까지 거쳐 결정
create-ait-app
--tds템플릿, Node 22 (Node 24 권장 경고만 뜨고 동작)
프로토타입을 설계도로 변환
먼저 Claude에게 프로토타입과 참고 자료를 정독시켰어요. 돌아온 건 코드가 아니라 설계 한 장 초안이었어요. 앞서 만든 다른 미니앱의 설계 문서 형식(무엇을 누구에게 / 운영 규칙 / 화면 / 콘텐츠 규격 / 측정 / 출시 가이드 / 단계와 완료 기준)을 그대로 따랐고요.
가장 유용했던 건 "가져오는 것 / 바꾸는 것" 표였어요.
가져오는 것: 영역별 1~5점 점검, 가장 낮은 영역을 "돌봄이 필요한 영역"으로 짚기, 작은 행동 하나를 골라 매일 "했어요 / 조금 했어요 / 오늘은 어려웠어요"로 기록하기
바꾸는 것: 탭 4개 → 첫 안내·점검·결과·홈 세 화면(가치·방향 화면과 월간 공유는 2차), 바텀시트 점검 → 전체 화면, 가짜 데이터 → 첫 사용자는 "첫 점검 안내"부터, 동점이면 앞 영역 자동 선택 → 사용자가 고름
그 다음 결정은 제가 했어요. 영역은 프로토타입의 5개 대신 6개(마음·몸·관계·감정·성장·돈) 로 — 토스 사용자라면 '돈'이 자연스럽다는 제안을 받아들였어요. 점검 주기는 제가 바꿨어요.
Open optionsauto
주 1회 체크를 하지 말고, 사용자가 원하는대로 체크할 날자를 정하게 해 주었으면 좋겠어.
이 한 줄이 설계 문서의 운영 규칙 한 줄("정해진 주기 없음. 점검을 끝내면 다음 점검 날을 사용자가 고른다")이 되고, 나중에 그대로 코드와 테스트가 됐어요.
이름은 두 번 퇴짜를 놨어요. 처음 추천받은 「내 안부」는 설명을 들어야 이해되는 이름이었거든요.
Open optionsauto
내 안부 가 이름으로 낯설어. 직관적으로 무슨 앱인지 확 와닿지를 않아. 다른 이름 더 추천해줘.
두 번째 후보 표에는 직관성과 정겨움을 따로 평가한 열이 있었고, 저는 가장 직관적인 「셀프케어 체크」를 골랐어요. 영문 식별자(appName)는 콘솔에 등록하면 바꿀 수 없다는 점도 이때 알았어요.
설계 문서 기반 프로젝트 구축
구현은 프로토타입 코드를 한 줄도 복사하지 않고 시작했어요. create-ait-app --tds로 빈 프로젝트를 만들고, 같은 폴더의 먼저 만든 미니앱에서 공통 조각(TDS 글자 겹침을 막는 Text 컴포넌트, 토스 내비바 뒤로가기와 맞물리는 history 기반 화면 전환)만 가져왔어요.
색은 감으로 고르지 않았어요. color-palette 스킬이 Color Hunt 트렌드 → Colormind → 색상환 → WCAG 명도 대비 검증 순서로 돌았고, 처음 고른 청록은 '몸' 영역의 초록과 구분이 안 돼서 버리고 자두색(흰 글자 대비 6.1:1)으로 정했어요. 영역색 여섯 개도 전부 흰 글자 4.9:1 이상인지 확인했고요.
코드는 순수 로직(점검 저장, 평균, 최저 영역, 다음 점검 날 상태, 저장값 복원)을 먼저 쓰고 Node 테스트로 묶은 뒤 화면 다섯 개를 붙였어요. 그리고 Claude in Chrome으로 개발 서버를 열어 첫 안내 → 6영역 점검 → 결과(동점 선택) → 행동·날짜 고르기 → 홈 → 기록 → 새로고침까지 직접 눌러 봤어요. 설계 문서 9번 표의 "1단계 완료 기준"이 바로 이 흐름이었고, 통과한 뒤에야 다음 단계로 갔어요.
사용자 피드백 반영
크롬 창을 저한테 열어 주길래 직접 눌러 봤어요. 그러면서 나온 요청들이에요.
Open optionsauto
날짜 고르기에 매일 탭도 넣어줘. 매일 하고 싶은 사람도 있을 것 같아.
Claude는 "매일" 버튼 하나를 더한 게 아니라, 간격(매일·3일마다·7일마다·14일마다)을 기억해 두고 점검할 때마다 다음 날짜를 자동으로 잡는 방식으로 바꿨어요. 달력에서 직접 고른 날짜는 한 번만 적용되고요. 테스트에 "매일로 바꾸면 점검할 때마다 다음 날" 같은 경우가 추가됐어요.
Open optionsauto
각영역별로 점검할 내용들 수정할 수도 있어? 추가 하고 싶은 내용이 있으면 넣을 수 있게 기능을 만들어줘.
이건 꽤 큰 기능이었어요. 영역 설정 화면(영역마다 점검할 내용과 작은 행동을 추가·고치기·삭제, 처음대로, 저장)과, 결과·약속 바꾸기 화면의 "직접 적기"가 생겼어요. 점검 화면의 힌트가 한 줄 문장에서 항목 목록으로 바뀌면서 "잠, 식사, 움직임을 떠올려 보세요"처럼 받침에 따라 을/를을 붙이는 함수까지 따라왔고요.
그 뒤로는 눈에 보이는 것만 말했어요. "+ 가 원 정 가운데 있지 않고 살짝 아래로 내려와 있어", "오늘 체크되는 원이 너무 오른쪽으로 붙었어". 둘 다 CSS 한두 줄로 끝났는데, 두 번째는 원 바깥에 두른 테두리가 원 밖으로 튀어나온 게 원인이라 테두리를 원 안쪽으로 그리는 방식으로 바꿨어요.
콘솔 등록과 테스트
Open optionsauto
콘솔에 등록하고 실기기에서 확인해보자
로고가 필수라 codex-image로 먼저 만들고, 앱인토스 콘솔 MCP로 로고 업로드 → 미니앱 등록 → 번들 빌드·업로드 → 빌드 완료 확인 → 테스트 푸시까지 이어졌어요. 콘솔 웹을 열 일이 없었어요. 휴대폰 토스 앱에서 열어 보니 잘 떴어요. 검토 제출은 제가 테스트를 마치고 말할 때까지 하지 않도록 해 두었고요.
로고 생성 프롬프트
로고 생성에 쓴 프롬프트예요. 색·구도·금지 요소를 다 적어야 원하는 게 나와요.
Open optionsauto
앱 아이콘(로고). 단색 자두색 배경(#A63D5C)이 화면 전체를 꽉 채운다. 가운데에 흰색의 단순한 하트 모양 안에 자두색(#A63D5C) 굵은 체크 표시 하나가 들어 있는 플랫 벡터 아이콘. 하트는 둥글고 부드러운 윤곽, 약간 두툼한 느낌. 그림자·그라데이션·질감·테두리 없음. 글자·숫자·텍스트 절대 없음. 다른 요소 없음. 정사각형 구도, 하트가 화면의 약 60%를 차지하며 정확히 중앙 배치. 토스 로고나 다른 회사의 아이콘을 닮지 않게.
결과와 배운 점
프로젝트 결과
Before: Codex 웹 프로토타입(토스 미니앱 아님, 가짜 데이터, 탭 4개) → After: 토스 미니앱 「셀프케어 체크」 콘솔 등록, 첫 번들 테스트 푸시, 실기기에서 열림 (근거: 콘솔 MCP 응답, 사용자 확인)
설계 문서
docs/DESIGN.md한 장: 운영 규칙·화면·단계별 완료 기준 포함 (근거: 파일)화면 7개(첫 안내·점검·결과·홈·약속 바꾸기·영역 설정·영역 편집), 순수 로직 테스트 8개 통과 (근거:
npm test)영역 6개 · 기본 행동 18개 · 격려 문구 9개, 전부 사용자가 고칠 수 있음 (근거:
src/content/areas.ts, 영역 설정 화면)메인 컬러와 영역색 7개 모두 흰 글자 WCAG AA 통과 (근거: color-palette 스킬 검증 기록)
크롬에서 1단계 완료 기준(첫 안내→점검→결과→홈, 새로고침 유지) 통과, 실기기에서 열림 확인 (근거: 스크린샷, 사용자 진술)
시행착오와 개선점
입력칸에서 Enter를 치면 '추가' 대신 '취소'가 눌렸어요. 영역 설정의 "직접 적기"를 크롬으로 테스트하다 발견했어요. 가설은 폼 안에서 Enter가 첫 번째 버튼을 누르는 HTML 기본 동작. 디자인 시스템(TDS) 버튼에
type="button"을 명시하니 해결됐어요. AI가 짠 코드도 눌러 보지 않으면 모르는 종류의 버그였어요.로고가 투명 배경에 테두리가 번진 채로 나왔어요. 프롬프트에 "단색 배경이 화면 전체를 꽉 채운다"고 썼는데도요. 다시 생성하는 대신 Pillow로 자두색 배경에 합성하고 흰색·자두색 두 색만 남기도록 정리해서 600×600을 만들었어요.
Node 테스트가 TypeScript 파일 간 import를 못 찾았어요. Node의
--test는.ts확장자를 붙여야 해서, 프로젝트 설정(allowImportingTsExtensions)을 확인한 뒤 로직 파일 import에 확장자를 붙였어요.메인 컬러 첫 후보(청록)를 버렸어요. 흰 글자 대비는 통과했지만 '몸' 영역의 초록과 색상이 너무 가까웠어요. 대비 수치만 보지 말고 함께 놓일 색끼리도 봐야 했어요.
셀프케어 체크 꿀팁
프로토타입은 설계도로 쓰세요. "가져오는 것 / 바꾸는 것" 표를 먼저 만들면, 프로토타입의 가짜 데이터와 플랫폼에 안 맞는 UI를 무심코 옮기는 일을 막아요.
단계마다 완료 기준을 문서에 적으세요. "브라우저에서 첫 안내→점검→결과→홈이 끊기지 않고 새로고침해도 유지된다"처럼요. AI가 "됐다"고 할 때 무엇을 확인할지가 정해져요.
요청은 사용자 관점 한 줄이면 충분해요. "매일 하고 싶은 사람도 있을 것 같아"가 간격 기억 기능과 테스트로 번역됐어요. 구현 방법을 지시하지 않아도 돼요.
AI가 연 브라우저를 직접 눌러 보세요. 눈에 띄는 것만 말해도 돼요. "+ 가 살짝 아래로 내려와 있어" 수준이면 충분했어요.
콘솔 작업은 MCP에게. 로고 업로드부터 테스트 푸시까지 콘솔 웹을 열지 않았어요. 단, 검토 제출처럼 되돌리기 어려운 일은 "내가 말할 때까지 하지 마"를 미리 정해 두세요.
주의할 점
영문 식별자(appName)를 대충 정하지 마세요. 콘솔 등록 뒤에는 못 바꿔요. 한글 앱 이름은 나중에 바꿀 수 있어요.
두 앱을 한 세션에서 번갈아 만들지 마세요. 저는 끝에 다른 앱 작업을 하나 끼워 넣었다가 세션이 섞여서, 사례글을 쓰고 새 세션으로 옮기기로 했어요.
다른 프로젝트에 적용하기
종이 체크리스트나 점검표가 있는 일이면 같은 순서로 갈 수 있을 것 같아요. 양식을 읽혀 "가져오는 것 / 바꾸는 것" 표부터 만들고, 사용자가 고칠 수 있어야 하는 항목(이 앱에서는 점검할 내용과 행동)을 처음부터 데이터로 분리해 두는 식이에요. 아직 해 보지 않은 건 가능성으로만 적어 둘게요.
도움이 필요한 부분
토스 미니앱에서 큰 글자 설정일 때 점수 버튼 5개를 한 줄에 두는 게 맞는지, 두 줄로 흐르게 두는 게 나은지 써 보신 분 계실까요?
점검 날짜를 사용자가 정하게 했는데, 알림(푸시)은 로그인·동의가 필요해 1차에서 뺐어요. 비슷한 앱에서 알림 없이 재방문을 어떻게 만드셨는지 궁금해요.
향후 계획
실기기에서 큰 글자·뒤로가기·재진입을 더 확인하고 문구 검수(평가하는 말투 0건)를 거쳐 2~3명에게 설명 없이 써 보게 하기
앱 정보와 번들을 함께 검토 제출
2차: 가치·방향 화면(프로토타입의 '나침반' 탭)과 월간 돌아보기·공유
도움 받은 자료
앱인토스 개발자센터 — 출시 가이드와 TDS: https://developers-apps-in-toss.toss.im/
닿님의 write-post 스킬(MIT) — 이 글의 DEVLOG·사례글 구성: https://github.com/daht-mad/write-post
