Yellta

[260810] 수박게임 웹으로 배포하다!! + OPEN AI GameBuilder출전해보기

yellta — Tue, 11 Aug 2026 02:16:40 +0900

드디어 수박 게임 출시!!!

게임 링크 : https://watermelon.micka-lab.com

오늘 수박게임 작업은 꽤나 많은 작업이 이루어졌다.

총 정리해보자

영수증 출력 사운드 추가 및 영수증 형태의 엔딩 화면 구현
- 실제 프린터 효과음을 추가했습니다.
- 영수증이 끊기듯 출력되는 애니메이션을 적용했습니다.
- 클레임 게임 오버 시 고객 불만 폭주! 연출 후 영수증이 출력되도록 변경했습니다.

영수증 결과 화면 UX 개선
- 게임 화면과 같은 고정 높이의 결과 패널로 변경했습니다. (기존의 엔딩페이지는 엔딩 영수증 길이에따라서 height가 늘어났었다.)
- 영수증 본문만 스크롤되도록 했습니다. -> 하단의 다시하기, 공유, 홈, 피드백은 빠르게 빠르게 유저가 눌러야하기 때문에 스크롤해서 버튼을 찾고싶게하지 않았음
- 다시하기·공유·홈·피드백 버튼을 하단에 고정했습니다. -> 위와 마찬가지의 이유. 유저가 빠르게 다시시작할 수 있도록 함
- 스크롤 안내와 아래 방향키 안내를 추가했습니다.-> 스크롤하는 방법을 몰라서 엔딩 영수증의 컨텐츠를 다 확인하지 못하는 경우를 생각했다.

키보드 조작 지원 확대
- 스테이지 완료 화면에서 Space 키로 다음 스테이지로 이동할 수 있게 했습니다.
- 결과 영수증에서 ↓ 키로 내용을 스크롤할 수 있게 했습니다.
영수증 정보 확장
- 선택한 특성의 모든 효과를 영수증에서 확인할 수 있게 했습니다.
- 정상 수박, 썩은 수박, 황금 수박, 쓰레기봉투 등 처리 품목을 표시했습니다. -> 내가. 어떤 에셋을 분류 했는지 영수증에서 확인할 수 있게 했음
- 선택하지 않은 황금 수박·쓰레기봉투는 영수증에서 숨기도록 유지했습니다. -> 스포일러 방지(황금 수박이 0개로 표시되면 뭔가 황금수박과 관련된 특성이 있다고 미리 알게될 것을 방지하기 위함)

스테이지별 차등 정산 시스템 구현
- 스테이지별 획득 점수를 별도로 기록하도록 변경했습니다.
- Stage 1은 점당 ₩100, Stage 2는 ₩200, Stage 3는 ₩300으로 정산합니다.
- 영수증에서 스테이지별 점수 × 단가 = 수당을 확인할 수 있습니다.
클레임 리스크 강화
- 클레임 1회당 공제를 -₩10,000에서 -₩100,000으로 상향했습니다.
- 실수의 긴장감과 후반 고득점의 가치를 강화했습니다.
신의 손 클레임 집계 버그 수정
- 신의 손 선택 전 발생한 클레임이 영수증에서 0회로 보이던 문제를 해결했습니다.
- 누적 클레임 이력과 신의 손의 즉시 게임 오버 하트를 분리했습니다.
- 안전 교육·사장님네 아들처럼 실제 클레임을 소모하지 않는 보호 효과는 공제 이력에 포함하지 않도록 했습니다.
실수령액 기반 정산 소견 콘텐츠 추가
- 실수령액에 따라 6단계 결과 멘트를 추가했습니다.
- 적자 인생, 오늘의 교통비, 견습 분류원, 믿음직한 직원, 이달의 수박 전문가, 정산의 신으로 구분했습니다.
- 각 구간에 여러 문구 조합을 넣어 매 결과마다 다른 느낌이 나도록 했습니다.
- 특성 조합에 따른 추가 코멘트도 표시합니다.
사용자 피드백 수집 기능 추가
- 메인 화면과 결과 화면에 이메일 피드백 버튼을 추가했습니다.
- 결과 화면에서 보내는 피드백에는 점수, 도달 스테이지, 클레임, 선택 특성이 함께 포함됩니다.
- feedback_opened 이벤트를 추가해 피드백 진입 위치를 분석할 수 있게 했습니다.

이번 업데이트에서 가장 신경쓴 것은

1. 아이템

여러가지의 아이템이 있어야 특성을 조합하고 특정 조합에 맞추서 덱을 구성하거나 가장 좋은 방법을 찾을 수 있기 때문

2. 유저의 사용성

기존의 게임은 특성을 선택할 때 마우스로 했었다. 하지만 막상 테스트해보니 실제로 어떻게 선택하는건지 모르겠다는 피드백이 들어왔다. 그래서 화살표키를 이용해서 선택하고 스페이스바로 결정할 수 있도록 변경했고, 해당 안내문구를 추가했다.

3. 게임 종료화면

단순히 점수만 보여주면 점수 경쟁심?만 자극하고 큰 재미를 못느낄 것 같았다. 게임의 컨셉이 수박을 분류하는 "일"을 하는 상황이니까 일당으로 환산이 되었으면 좋겠다고 생각했고, 그래서 점수를 돈으로 환산했고 클레임은 100,000원으로 깎이는 설정을 추가했다. 일을 했는데 오히려 돈을 못버는 상황도 번번하다.(초반부를 버티지못하면 대부분 적자임) 거기에 추가로 엔딩멘트까지 있다면 나름 엔딩을 보는 재미도 있을것이라고 생각했다.

다시하기, 공유하기, 메인으로, 피드백 버튼을 화면에 무조건 고정해놓은 이유는 간단하다. 게임을 하게되면 막상 엔딩페이지를 잘 보지않는 경우도 생긴다. 다시시작할 때, 빠르게 다시시작하고 싶은 경우가 있고 이미 망한판이라 생각해서 다시하고싶은데 일일히 마우스로 스크롤해서 다시하기버튼을 찾는 것은 유저에게 귀찮음을 주는 상황이다. 그런 귀찮음을 느끼지 않게하려고 바로 다시시작할 수 있게 버튼을 하단에 고정했다.

앞으로 해야할 일

이제 게임 디테일을 잡으면 될 것 같다.

1. 피드백 받아보기

유저의 피드백을 받아보는게 제일 좋다. 일단 트위터에 글을 올려서 사람들의 피드백을 받고 업데이트를 진행할 예정이다.

2. 에셋추가

지금은 노래 1개, 스테이지는 3개이지만 모두 똑같은 이미지에 필터만 씌운것 같은 느낌이다.

스테이지별로 노래, 이미지 에셋을 새로 생성해서 넣을 생각이다.

3. UI수정

지금 게임 메인화면, 게임 플레이화면, 게임 엔딩화면 비율이 묘하게 다를 것이다.

또한 웹 페이지도 덩그러니 가운데에 띄워져 있는게 전부이다.
조금 더. 유저가 보기 좋은 형태로 맞출예정이다.(배경과의 조합, 메인 화면-플레이화면-엔딩화면의 비율 맞춤 등등)

4. 유저의 플레이 지표를 기반으로 퍼널 만들고 분석하기

지금까지의 유저의 피드백, 단순히 좋은 의도로 나에게 게임 플레이가 혹은 어플의 사용성을 리뷰해주시는 분들을 전적으로 믿었다. 하지만 이제는 지표와 수치를 통해서 내가 스스로 부족한 점이 무엇인지 파악해야하는 시기인것 같다. 대부분의 유저는 조금 맘에 들지 않으면 그냥 꺼버리기 때문이다. 나조차도 그러니 말이다.

그래서 posthog라는 것을 사용해보았다. 컴포넌트에 tag를 달고 유저가 특정 행동을하면 tag로 기록되는 느낌이다. 그 tag를 활용해서 스테이지를 얼마나 클리어 했는지, 특성을 어떤걸 선택했는지 체크할 수 있다.

내 나름대로 열심히 만들었는데 좋은 결과가 있을지는 모르겠다.
그래도 이번에 출전하면서 다른 사람의 게임도 구경하고 codex를 좀 더 적극적으로 이용하게 될 수 있던것 같다. 추가로 AI를 더 잘 활용하는 방법에 대해서는 연구해보고 알아봐야겠지만(일상의 불편함을 먼저 느끼는게 좋은데 사실 지금 내 상황에서는 사무적으로 매일 수행하는일이 거의 없다;;)

[260806] 수박 개발일지 #3 피드백 받은 사항 정리 + 앞으로 해야할 일 정리

yellta — Fri, 7 Aug 2026 12:36:06 +0900

오늘은 아침에 집중을 못해서 작업을 못했고... 집에서 1시간 정도 얼른 작업했다.

기존에 받았던 피드백을 기반으로 소폭 수정했다.

남자친구가 플레이해보고 준 피드백이다.
여기서 1~4번까지의 데이터를 수정했다.

1. 키보드 Arrow를 통해서 item을 선택할 수 있도록 설정

우선 플레이하면서 놀랐던 점은 나는 당연히 특성을 선택하는 부분을 마우스로 선택했는데 테스트해준 플레이어는 "이 특성 어떻게 선택해?"라는 답변이 들어왔다. 그래서 직관적으로 선택하는 화면을 선택했다.

기존 마우스로 선택하던 창을 변경했다.

유저가 더 잘 볼 수 있도록 화살표로 이동하고 스페이스바로 선택하는 방향을 선택했다. 추가로 스페이스바가 action키인 경우는 기존의 다른 게임에서도 잘 보이는 특성이기 때문에 선택을 스페이스바로 결정했다.

2. 플레이타임이 너무 짧아서 흐름이 끊김 한 판당 수박을 더 추가해도 될 듯

기존 수박은 총 3스테이지로 구성이 되어있다.

1스테이지 : 60개

2스테이지 : 80개

3스테이지 : 100개

총 240개의 수박을 분류하도록 했는데 생각보다 플레이타임이 너무 짧다는 피드백이 들어왔다. 막 집중할때쯤 갑자기 끊기고 다음으로 넘어간다는 의미이다.

그래서 스테이지당 수박의 수를 변경했다.

1 스테이지 : 100개

2스테이지 : 150개

3스테이지: 200개

3. 특성선택후 분류하는 수박은 시간초과가 없음

특성을 선택하고 나타나는 수박을 바로 분류해야하니 억울하다(?) 즉 소위 말하는 억까느낌이 든다고 했다. 해당 부분 또한 특성을 선택하면 그 다음 수박은 시간 제한이 없도록 설정했다. 대신 안내 문구 정도는 띄워줘야할 듯 하다.(수박을 분류하세요!)이런식으로 특성을 선택하면 시간 제한이 없다는 것을 알려주면 좋을 것 같다. 이건 지금 당장 추가하는 것은 아니고 쓰면서 떠오른 것들!

4. 신의손 아이템 추가(클레임 기회 단 한 번, 대신 모든 수박의 점수를 3점으로 동결) - 8월 6일 업데이트에는 포함이 되지 않음

해당 아이템은 갑자기 생각나서 급하게 적은 것이다. 이번에 업데이트를 진행하면서 다양한 아이템의 필요성을 느꼇기 때문에 아이디어가 떠오르면 바로바로 작성했었다.

앞으로 수정할 내용

- 신의 손 아이템 추가

- 어떤 아이템 넣을지 고민하기

- 스테이지별 배경 & 사운드 추가

- 데이터로 유저 지표를 확인할 수 있는 방안 고려

- 웹 배포

[260805] 수박게임 개발 일지

yellta — Wed, 5 Aug 2026 18:11:15 +0900

기존에 기획이 바뀌어 버렸으니 오늘은 바뀐 내용으로 게임 업데이트를 수행해보았다.

우선 변경된 사안을 확인해보자

️ 작업 내용 (Changes)

3스테이지 진행 및 난이도

입고 검수(60개) → 폐점 세일(80개) → 월말 정산 전야(100개) 순서의 스테이지를 추가했다.
제한 시간은 1.5초 → 1.25초 → 1초로 점진적으로 짧아진다.
스테이지 완료 시 게임을 멈추고 납품 수량과 점수를 보여준다.
자동 전환 없이 다음 스테이지로 버튼을 눌러 다음 스테이지의 특성 선택으로 진행한다.
임시 배경 톤으로 Stage 1은 푸른색, Stage 2는 황금색, Stage 3은 붉은색 분위기를 적용했다.

특성 선택과 클레임

각 스테이지 시작 및 중간 지점에 특성 선택 기회를 제공한다.
특성 선택은 별도 팝업이 갑자기 등장하는 방식이 아니라, 수박 레일을 따라 보너스 성과급 상자가 들어오는 연출로 시작한다.
상자가 레일의 선택 위치에 도착하면 게임을 잠시 멈추고, 유저는 제시된 특성 3개 중 하나를 선택한다.
현재 특성은 흐름 검증용 임시 항목(특성 1~3)이며 효과는 아직 적용하지 않았다.
오분류 또는 제한 시간 초과 시 클레임이 누적되고 콤보가 초기화된다.
클레임이 3개 누적되면 게임이 종료된다.

️ 작업 내용 (Changes)

무작위 특성 풀 및 실제 효과

총 10개의 특성을 등록하고, 아직 선택하지 않은 특성 중 최대 3개를 무작위로 제시한다.
한 번 선택한 특성은 같은 런에서 다시 후보로 나오지 않는다.
특성 카드에 출현율, 점수 보상, 시간 변화, 주의사항을 줄 단위로 표시한다.
구현된 특성 효과:
- 프리미엄 납품 계약: 신선 수박 75%, 신선 점수 2배, 썩은 수박 0점
- 안전 교육 수료증: 스테이지별 첫 클레임 무효
- 연속 근무 수당: 10콤보마다 +5점
- 작업 매뉴얼 / 마감 러시: 제한 시간 조절
- 즉시 지급 수당 / 완벽 납품 보너스 / 재정비 지원금: 점수 보상
- 쓰레기 수집가: 쓰레기 봉투와 가운데 분류 해금
- 황금 수박 계약: 황금 수박 연타 아이템 해금

쓰레기 수집가 및 가운데 분류

쓰레기 수집가 선택 시 쓰레기 봉투가 레일에 약 25% 확률로 등장한다.
가운데 분류 버튼과 키보드 ↓ 입력을 활성화한다.
쓰레기 봉투를 가운데로 분류하면 기본 점수의 4배를 획득한다.
쓰레기 수집가 선택 중에는 썩은 수박을 올바르게 분류해도 0점이며, 오분류 시 클레임은 그대로 발생한다.
쓰레기 봉투는 수박과 비슷하게 보이도록 92px 크기로 표시한다.

황금 수박 연타 아이템

황금 수박 계약 선택 시 이후 레일에서 약 1% 확률로 황금 수박이 등장한다.
황금 수박이 분류 위치에 도착하면 가운데 버튼이 TAP!으로 변경되고, 키보드 ↓ 연타도 가능하다.
탭 1회당 현재 기본 점수의 5배를 획득한다.
황금 수박 도착 시 황금 오라와 황금 수박! ↓ 연타! 안내를 표시한다.
탭 성공 시 +점수 피드백을 표시한다.
제한 시간 내 탭하지 못하면 현재 클레임 규칙에 따라 클레임 1회가 누적된다.

성과급 상자 상호작용

중간 성과급 상자가 작업 위치에 도착해도 특성 선택 화면을 자동으로 열지 않는다.
레일 위에 아무 버튼이나 눌러 수령! 안내를 표시한다.
좌·중·우 버튼 또는 키보드 방향키 입력으로 상자를 수령하고 특성 선택 화면을 연다.
가운데 고정 ACTION 버튼은 성과급 상자 도착 시 OPEN! / 성과급 수령으로 활성화된다.
평소의 가운데 버튼은 ACTION / 보너스 · 특수 아이템 대기 상태로 표시해 특수 상호작용의 존재를 안내한다.

내가 작성한 PR의 일부이다.

두 개의 PR을 발행했다.

일단 요약하자만

1. 기획안대로 스테이지제로 변경했다. 총 3개의 스테이지로 구성이 되어있고 60, 80, 100개의 수박 정렬 콤보로 구성되어 있다.

2. 첫 스테이지에 입장할때, 에셋을 선택한다. 이건 The binding of isaac처럼 로그라이크 시스템을 결합한것인데 아직 추가해야하는 에셋이 많다.

일단 크게 이 두가지로 갈리는 것 같다. 밍기적?거리면서 작업한것 같아서 약간 그렇긴 한대 또 생각해보면 꾸준히 매일 뭔가를 하고있으니까 다행인가? 싶기도하다. 인생이란 매일 데드라인을 줘야하는 것일까

아무튼간 오늘은 개발을 여기까지 수행했다. OpenAI에 제출하기 위해서는 플레이 데모 영상도 준비해야하고 신경쓸것이 많으니까 2주간 빡세게 만들고 나머지는 제출하기 위한 부가적인 서비스에 집중할 예정이다.

참고로 모든 구성은 codex와 함께했고, 기획서도 codex가 만들고 내가 검수했다. 개발 자체는 코덱스에게 던져주기보다는 코덱스와 계속 대화해가면서 필요한 부분을 계속해서 채워나갔다. 나는 이렇게 쓰는 방식이 토큰도 아끼고 내가 원하는 결과물도 얻는 활용방안인것 같다.

오늘의 개발 일지는 여기서 끝이고 내일 에셋도 더 추가하고 사용성 개선을 위한 작업을 수행할 예정이다!

아 추가로 실제로 나도 플레이하면서 어떤 덱을 골라야할까 엄청 고민했는데 나름 이 와중에서 재미를 챙긴 듯 하다. ㅋㅋㅋㅋ

소중한 피드백

1. 키보드 Arrow를 통해서 item을 선택할 수 있도록 설정
2. 플레이타임이 너무 짧아서 흐름이 끊김 한 판당 수박을 더 추가해도 괜찮을 듯

3. 특성선택후에 분류하는 수박은 시간초과가 없음(갑작스럽게 플레이해야하는 상황 방지)
4. 신의손아이템 -> 선택하면 클레임을 한 번 받으면 게임오버 대신 모든 수박 점수가 3점으로 동결
5. 아이템이 더 많으면 좋을듯

OpenAI gameBuilder 나가보기 26년도 8월 26일까지

yellta — Wed, 5 Aug 2026 15:22:44 +0900

오늘은 X에서 좋은 글을 발견했다. 바로 OPENAI에서 Game builder를 개최한다는 것

어찌 됐던 심사위원의 마음을 사로잡아야하는 웹 게임을 만들어서 제출해야 실제로 오프라인대회까지 출전할 수 있는 기회를 얻게 된다. 총 40개의 팀이 선정되어 올라갈 예정!

아래는 공모전 링크!
https://openaigame2026.com/#main

아래는 새롭게 게임을 기획한 내용이다. 물론 Codex와 함께!...

수박수박수박박수박: 마트 노동 로그라이크 기획서

1. 프로젝트 개요

한 줄 소개

사장님의 기묘한 운영 지시를 골라, 3일간의 수박 마트 근무를 버텨내는 짧은 분류 로그라이크.

게임 정체성

수박수박수박박수박은 싱싱한 수박과 썩은 수박을 빠르게 분류하는 즉시성 있는 아케이드 게임이다. 플레이어는 스테이지 시작과 중간마다 특수 배송 상자에서 특성을 선택하고, 수박의 가치·생존 방식·위험도를 바꿔 자신만의 마트 운영 빌드를 완성한다.

단순히 높은 점수를 내는 것보다, 매판 서로 다른 운영 지시 와 특성 조합으로 다른 판단 우선순위를 경험하게 하는 것이 핵심이다.

2. 목표

브라우저에서 설치와 로그인 없이 즉시 플레이할 수 있는 웹 게임을 만든다.
첫 30초 안에 기본 분류 규칙과 특성 선택의 재미를 보여준다.
1회 플레이는 카드 선택을 포함해 약 2~4분 안에 끝난다.
짧은 런 안에서도 서로 다른 빌드와 재도전 동기를 만든다.
향후 Android와 Hive 연동을 통해 글로벌 랭킹·시즌 이벤트·운영 분석으로 확장할 수 있는 구조를 제시한다.

3. 핵심 경험

즉시 이해: 싱싱한 수박은 왼쪽, 썩은 수박은 오른쪽으로 보낸다.
생존과 숙련: 실수는 클레임을 소모하고, 콤보는 고득점 보상으로 작동한다.
선택과 빌드: 스테이지마다 특성을 여섯 번 선택하며 수박의 가치와 전략을 바꾼다.
정산의 만족감: 마지막에 이번 런의 특성, 성과, 직업명이 담긴 정산날 대시보드를 확인한다.

4. 기본 조작과 규칙

대상	조작	결과
싱싱한 수박	왼쪽 버튼 또는 `←`	올바른 분류
썩은 수박	오른쪽 버튼 또는 `→`	올바른 분류
오분류 또는 시간 초과	없음	클레임 1개 소모, 콤보 초기화

시작 클레임은 3개다.
클레임이 모두 소진되면 해고되고 런이 종료된다.
쓰레기봉투와 쓰레기 수박은 기본 게임 오브젝트에서 제거한다.
기본 분류 방향은 특성으로 바꾸지 않는다. 특성은 점수 가치, 출현 확률, 시간, 생존 규칙을 바꾼다.

5. 진행 구조

스테이지 흐름

Stage 1 시작 → 주요 특성 선택 → 진행도 50% → 보조 특성 선택
→ Stage 2 시작 → 주요 특성 선택 → 진행도 50% → 보조 특성 선택
→ Stage 3 시작 → 주요 특성 선택 → 진행도 50% → 보조 특성 선택
→ 정산날 대시보드

특성 선택은 매번 세 장의 카드 중 한 장을 고른다. 총 여섯 개의 특성을 보유한 상태로 런을 종료한다.

스테이지 정의

스테이지	테마	정확 분류 목표	난이도
1. 입고 검수	첫 출근	60개	기본 속도와 규칙 학습
2. 폐점 세일	급한 재고 처리	80개	제한 시간 감소, 등장 속도 상승
3. 월말 정산 전야	실적 마감	100개	최고 속도, 빌드 효과 극대화

내부적으로는 정확 분류 횟수로 진행한다. 사용자에게는 오늘의 납품 목표 0~100%로 표시한다. 목표의 50%에 도달하면 보조 특성 선택이 등장한다.

콤보의 역할

콤보는 스테이지 진행 조건이 아니다.
올바른 분류 시 증가하며 점수 배수와 숙련 보상에 사용한다.
실수·시간 초과 시 0으로 초기화한다.
전체 런 100콤보는 고수 플레이를 위한 업적 또는 추가 정산 보너스로만 사용한다.

스테이지당 100콤보를 요구하지 않는다. 콤보가 끊기면 보상에 도달할 수 없는 구조는 초보 플레이어가 빌드의 재미를 경험하지 못하게 하기 때문이다.

6. 배송 상자와 특성 선택

연출

스테이지 시작 또는 진행도 50%에 도달한다.
레일과 타이머를 완전히 멈춘다.
배송 트럭 또는 하늘에서 떨어지는 상자 애니메이션을 보여준다.
특성 카드 3장을 표시한다.
한 장을 탭하면 효과를 명확한 문구와 화면 효과로 알린다.
선택한 특성 효과를 적용하고 게임을 재개한다.

상자는 플레이 도중 놓칠 수 있는 상호작용 오브젝트가 아니다. 이는 모바일의 좌우 분류 조작과 충돌하고, 우연한 놓침이 불공정한 실패가 되는 문제를 막기 위함이다.

특성 분류

구분	선택 시점	역할	예시
주요 특성	각 스테이지 시작	점수의 가치와 운영 방향을 크게 바꿈	폐기물 수집가, 프리미엄 과일상, 과속 컨베이어
보조 특성	각 스테이지 진행도 50%	생존·콤보·시너지를 보완	사장님 아들 낙하산, 야근 수당, 긴급 휴식

초기 특성 풀: 20개

첫 제출본은 주요 특성 10개와 보조 특성 10개를 정의한다. 주요 특성은 스테이지 시작 배송 상자에서만, 보조 특성은 스테이지 진행도 50% 배송 상자에서만 제시한다. 동일 특성의 중복 선택은 허용하지 않는다.

특성은 모두 처음부터 선택 풀에 포함한다. 영구 해금이나 플레이어 간 진행도 차이를 만들지 않으며, 각 특성의 수치와 등장 가중치는 플레이 테스트 후 조정한다.

주요 특성 초안

특성	구분	효과	대가/전략
폐기물 수집가	주요	썩은 수박 정확 분류 시 +2점	싱싱한 수박 기본 점수 0
프리미엄 과일상	주요	싱싱한 수박 정확 분류 시 +2점	썩은 수박 분류 시 콤보 감소
과속 컨베이어	주요	모든 획득 점수 ×2	제한 시간 20% 감소
산지 직송 계약	주요	싱싱한 수박 등장률과 보상 증가	썩은 수박 분류 보상 감소
야간 할인 계약	주요	썩은 수박 등장률과 보상 증가	싱싱한 수박 분류 보상 감소
대량 납품 계약	주요	스테이지 클리어 보너스 증가	해당 스테이지 목표 20% 증가
정밀 검수대	주요	높은 콤보에서 점수 배수 증가	실수 시 콤보 손실이 커짐
회전율 우선	주요	수박 전환 애니메이션과 등장 속도 증가	제한 시간 감소
품질 보증제	주요	클레임 공제 감소	기본 분류 보상 감소
월말 특근	주요	Stage 3의 모든 보상 증가	Stage 1·2의 점수 보상 감소

보조 특성 초안

특성	구분	효과	대가/전략
사장님 아들 낙하산	보조	다음 클레임 1회 무효	직접 점수 보너스 없음
야근 수당	보조	콤보 10 이상에서 추가 점수	낮은 콤보에서는 효과 없음
긴급 휴식	보조	다음 스테이지 시작 시 클레임 1개 회복	즉시 점수 보상 없음
반품 처리 수당	보조	클레임이 발생할 때마다 반품 스택 +1, 다음 5회 정확 분류에 스택당 추가 수당	실수 뒤 빠른 회복에 유리
빠른 손 수당	보조	제한 시간 절반 안에 분류하면 추가 점수	늦은 분류에는 효과 없음
안전모	보조	첫 시간 초과는 클레임을 소모하지 않음	오분류는 막지 못함
단골 고객	보조	같은 종류의 수박을 연속 분류하면 보너스	종류가 바뀌면 누적 초기화
재고 정리표	보조	다음 스테이지 납품 목표 15% 감소	현재 스테이지에는 효과 없음
성과급 봉투	보조	다음 스테이지 클리어 보너스 증가	현재 스테이지에는 효과 없음
초과 근무 도장	보조	스테이지 후반에 추가 점수 배수	초반에는 효과 없음

특성 선택 화면은 주요/보조 풀을 섞지 않는다. 따라서 플레이어는 매번 세 가지의 비교 가능한 운영 방향 또는 보조 전략 중 하나를 고른다.

7. 점수와 정산

점수 구성

올바른 분류 기본 점수
현재 콤보에 따른 배수 또는 추가 점수
특성 효과로 인한 가감점
스테이지 클리어 보너스
전체 런 100콤보 달성 보너스

점수는 내부적인 게임 계산 기준으로 유지한다. 사용자에게는 점수가 단순 숫자가 아니라 마트 근무의 성과인 매출과 급여로 해석되어 보여야 한다.

정산날 대시보드

세 스테이지를 완료하면 정산날! 화면을 표시한다. 런이 중도 종료된 경우에도 현재까지의 성과를 중도 정산으로 동일한 형식으로 보여준다.

최종 매출/점수
클리어 스테이지
최고 콤보
남은 클레임
선택한 특성 여섯 개
이번 런의 직업명 또는 빌드명
재도전 및 공유 버튼

근무 일지

정산날 화면은 현재 런의 이야기를 설명하는 근무 일지를 포함한다. 이전 런을 저장하는 영구 기록 시스템은 첫 제출본의 범위에서 제외한다.

[근무 일지]
Stage 1  입고 검수        20 / 20 완료
Stage 2  폐점 세일        25 / 25 완료
Stage 3  월말 정산 전야    30 / 30 완료

[오늘의 운영 지시]
폐기물 수집가 · 과속 컨베이어 · 사장님 아들 낙하산

급여 명세서

점수의 출처를 급여 명세서로 보여준다. 특성이 만든 플레이 차이를 결과에서도 읽을 수 있게 하는 것이 목적이다.

[급여 명세]
분류 수당          ₩12,400
콤보 수당           ₩3,200
특수 계약 수당      ₩1,500
클레임 공제          -₩600
──────────────────────
이번 근무 실수령    ₩16,500

항목	계산 기준
분류 수당	올바른 분류로 얻은 기본 점수
콤보 수당	최고 콤보와 콤보 관련 특성 보너스
특수 계약 수당	선택한 특성으로 발생한 추가 점수
클레임 공제	오분류·시간 초과로 소모한 클레임
실수령	위 항목을 합산한 이번 런의 최종 성과

돈은 상점에서 쓰거나 누적하는 영구 재화가 아니다. 점수를 마트 근무 성과로 표현하는 장치이며, 영구 해금이나 별도 경제 시스템을 만들지 않는다.

직업명은 특성 조합을 바탕으로 생성한다. 예: 폐기물 전문 분류원, 과속 마트의 에이스, 프리미엄 과일 담당자.

8. 독창성 원칙

이 게임의 독창성은 새로운 조작법이 아니라, 마트의 운영 지시가 분류 대상의 가치와 생존 방식을 바꾸는 점에 있다.

모든 특성은 마트 노동·사장·물류·재고라는 세계관에 연결한다.
숫자만 증가시키는 특성보다, 플레이어가 반기는 수박과 위험으로 느끼는 수박을 바꾸는 특성을 우선한다.
강력한 효과에는 명확한 대가를 둬 정답 빌드를 없앤다.
기본 방향 규칙은 고정해, 독창성이 불친절함으로 변하지 않도록 한다.

9. 해커톤 제출 대응

심사 항목	제출본 대응
Playability	로그인 없는 웹 링크, 모바일·키보드 조작, 3스테이지 완결 흐름
Originality	마트 운영 특성이 수박의 가치와 생존 전략을 바꾸는 로그라이크 구조
Codex Collaboration	룰 설계, 특성 밸런스, Phaser 상태 전환, 모바일 입력 개선의 Codex 활용 기록
Release Potential	Android 출시 후 Hive 로그인, 빌드별 글로벌 리더보드, 시즌 이벤트, 운영 분석
Presentation	3분 안에 기본 분류 → 특성 선택 → 달라진 빌드 → 정산날을 시연

제출물 체크리스트

공개 웹 플레이 링크
로그인·설치 없이 접속 가능한지 확인
조작법이 게임 안에 표시되는지 확인
16:9 JPG/PNG 썸네일
200자 이내 게임 소개
3분 이내 실제 플레이 영상
기존 프로젝트에서 챌린지 기간에 추가한 변경점
Codex 활용 과정과 사람의 기획 결정을 구분한 설명

10. 구현 우선순위

주요 특성 10개와 보조 특성 10개의 효과·대가·시너지 가설을 데이터로 정의한다.
기존 실시간 분류 게임을 60·80·100 목표의 스테이지·클레임 구조로 전환한다.
Stage 1/2/3의 시작 및 진행도 50% 보상 전환을 구현한다.
특성 데이터 모델과 주요/보조 카드 선택 UI를 구현한다.
특성 효과가 점수·시간·클레임·스폰 정보에 반영되게 한다.
정산날 대시보드에 근무 일지와 급여 명세서를 구현한다.
실제 플레이에서 특성별 선택률, 런 길이, 스테이지 도달률을 확인하고 수치를 조정한다.
모바일 브라우저에서 전체 런을 테스트하고, 썸네일·영상·제출 설명을 준비한다.

11. 성공 기준

첫 30초 안에 플레이어가 분류와 특성 선택을 모두 경험한다.
모든 런에서 총 여섯 번의 선택 기회가 제공된다.
각 런은 주요 특성 3개와 보조 특성 3개를 보유한 상태로 종료된다.
실수 후에도 남은 클레임이 있으면 런이 계속된다.
선택한 특성은 다음 플레이에서 명확히 체감된다.
3스테이지를 마치면 빌드, 근무 일지, 급여 명세서가 담긴 정산날 화면이 나타난다.
결과에 표시되는 돈은 영구 재화로 저장되거나 상점 기능에 사용되지 않는다.
게임은 브라우저에서 안정적으로 실행되며, 모바일 터치와 데스크톱 키보드를 모두 지원한다.

일단 이런 기획서를 가지고 바로 바이브코딩으로 만들어볼 생각이다! 시간이 없으니 빨리빨리 개발해야하는데 결과가 잘 나왔으면 좋겠다!

[lost in me] Application Review

yellta — Thu, 30 Jul 2026 22:41:33 +0900

The application Reivew

this app is for meditation and focusing

This is the main of application and before I arrived main page the Application asked some questions with purple character.
I think the landing page system is quite cool. Easy to fill the contents

Functions

If I enter the world(?). I can hear the cozy... focusing music
Also I can choose night mode and day mode
But I think... I can here the music from youtube Not the [Lost in me]Application
cuz Youtube is 100% free.

This is the 발견(discovery?) function.
I used to korean but I entered the page the Language was eng.
If user didn't use the Eng then they will just skip this function cuz They have to understand eng that makes the user experience exhausting.

This function is like... email you can send the mail to lost in me team or another lost in me users.

This is a journal function and I pretty liked it!
I can use emoji to my journal and the journal function is easy to use like default application calander
and 생각내려놓기(the candle icon function- empty your brain?) the Idea was good but I didn't recognize how can i use it.

etc

I noticed When I enter the premium subscription page the cost was different.

1st 100,000 ₩ per year, and 8100₩? per week
2nd 65699won per year, 4,199won per week

if I purchase 1st price? it's unfair.

Also, considering the price, I didn't feel the subscription offered enough benefits.

the world system-> can be placed youtube focus music channel
sleep guide -> I couldn't experience cuz I didn't have token
Cloud backup -> It wasn't clear what information was actually being backed up.(the journal?)
friend -> okay It has friend chatting system (AI bot) but Also I didn't talk with the bot cuz I didn't have any token.
A letter to future me -> I didn't have any interesting for this function

music -> youtube can replace it.

Some features were locked for free users, and since I wasn't sure if it would be worth paying for, I didn't bother using them. I hesitated because I was worried I might pay and then not be satisfied.

Summary

1. The price is changing sometime was 100,000won per year but another time was 60,000won per year

2. Meditate music can here in the youtube and youtube offer unlimited if user open the youtube application

3. The price is quite... expensive I think...

4. Free user couln't experience Ai bot or other function (I used world explorer function so I coulnd't use 표류하기 function) -> user can't experience the function so they didn't feel to purchase
It will be good to give user to free token to use each functions.

5. the 발견(discovery? in eng maybe) was not support korean -> the non eng-native user can feel exhausted

6. The journal icon was different from other asset (the bed, window, lighting) I thought that was just image but It actually the journal function
7. When I used 세계탐방(world explorer function) then I could select the day mode and night mode, but I clicked it, It takes time to change theme but I thought It's not working (the loading spinner can help it!)

I hope this article is great for your application and also it was good time for me too because I can think the users experience to review this application.

[마린키우기 - 사령부는 응답하지 않는다]게임 후기

yellta — Thu, 30 Jul 2026 21:23:42 +0900

겜창 소비자의 입장에서 철저하게 리뷰해보겠다. 만드신 분이 좀 더 잘되길 바라는 마음에서!!!!

우선 첫 페이지에 버그가 하나 존재한다.
바로 이어하기 VS 새로하기 버튼인데
그러니까 어플을 완전히 처음 다운받고 이어하기를 누르면 아무일도 일어나지 않는다.

통상 "데이터가 없습니다. 새로 시작하시겠습니까?"이런 안내 없이 그냥 버튼만 눌리고 아무일도 일어나지 않았다.

게임 플레이 화면

위에 보이는 화면이 게임 플레이 화면이다.
게임의 조작법은 생각보다 간단했는데 그냥 앞뒤좌우 스크롤을 조정해서 움직이면 자동으로 사냥이 되는 방식이다.(방치형은 아님)

처음에는 생각보다 쉬운데? 라는 느낌을 받았지만, 게임 후반부에 갑자기 폭탄 던지는 애가 나와서 뒤로 호로록 도망갔따가 다시 쏘러갔다가했다. 생각보다 박진감 넘쳤다. 왜냐면 자주 죽을뻔 했거든

폭탄을 들고 다니는 적군들 여기서 생각보다 위기를 많이 마주햇기 때문에 체력 업그레이드를 난타함 ㅋ

사실 게임 화면을 많이 캡쳐하고 싶었는데 위기가 찾아온 순간이 좀 많았기 때문에 캡쳐는 별로 없다 ㅋ...
그리고 화면 아래에 아이템이 4개 있는데 아이템을 적재적소에 잘 써줘야한다. 특히 14라고 적힌 것은 궁극기이기 때문에 위기에서 벗어나게 해주었다.

게임 결과다!
플레이시간이 21분이나 되지만 중간에 내가 다른일을 갑자기 해야해서 그렇고 막상 플레이 타임은 5분에서 10분 이내인것 같다.
가볍게 전투 기록을 볼 수 있는 화면이었고 정적인 화면이었다.

그래도 승리해서 기분은 좋았음 ㅋ

난이도나 그런것들은 생각보다 밸런스가 괜찮았다. 후반부는 쫓기는 느낌도 있어서 박진감도 넘쳤다 ㅋ

아쉬운 점

1. 게임 허드

게임화면에서 보이는 뭐 총알 갯수, 자원들 이런걸 게임 허드라고 하는데 그 허드가 잘 보이지 않았다.

미니맵사이즈는 적당해서 좋았고

오른쪽 상단의 돈이랑 나가기 버튼은 잘 보이지 않았다. 특히 나가기 버튼은 배경과 그래픽, 색상이 비슷해서 눈에 잘 띄지 않았는데 대비가 확실한 색으로 변경하는 것이 좋을것 같았다.
중간에 게임을 일시정지해야하는 상황이 있었는데 저 버튼을 찾지 못해서 나갔다가 다시했었다.

왼쪽 하단의 레벨 ,체력 허드는 스마트폰의 조이스틱을 조작하게 되면 엄지손가락에 가려져서 보이지 않는다. 사실상 내가 업그레이드를 해도, 레벨이 얼마나 늘어났는지, 아머는 어느정도인지, 그런것들을 게임화면에서 직관적으로 확인하기 힘들었다.

마찬가지로 글자가 너무 작기도 했다.
미니맵 아래에 조금 더 큰 글씨를 사용해서 표현했으면 좋았을 것 같다.

2. 업그레이드 이펙트 부재

게임을 플레이 할 당시 나는 소리를 작게 설정하고 플레이하고 있었는데 강화버튼을 누르면 이게 강화가 어떻게 되는건지 도대체 감을 잡을 수가 없었다.
체력을 선택하면 채력이 오르는 것으로 대충 확인했지만 내가 한 번 사용할 때 내가 가지고 있는 돈에서 얼마가 줄어들었는지, 내가 이 재화를 사용해서 어떤 점이 강해진 것인지 확인 할 수 없어서 마구마구 난타했던 기억이 난다. 참고로 체력은 정말 피가 얼마 안남았을 때 갈겨서 썻다.

이 문제는 가지고 있는 재화를 좀 더 크게 표현해서 직관적으로 볼 수 있게 하거나, 아니면 사용할 때마다 메이플 스토리 공격 이펙트 뜰 때처럼 표현하면 내가 아이템을 사용해서 업그레이드를 했구나! 라고 느낄 수 있을 것 같았다.

3. 설명 부재

젤다의 전설이 매우 호평받는 이유는 바로 유저에게 특별하게 지시를 하지 않아도 제작자가 원하는 방향으로 플레이하게 만들었기 때문이다.
내가 여러 애플리케이션들을 테스트하면서 느꼇던것은 대부분의 애플리케이션들은 유저에게 설명이 없다. 즉 충분한 설명이 없다는 것이다.

나는 처음 게임을 플레이했을때, 내가 총을 쏴야하는건지, 내 목표는 무엇인지, 내가 쓸 수 있는 아이템은 무엇인지에 관한 정보를 하나도 얻을 수 없었다. 도대체 어떻게 하는거지?라는 생각이 들었다.

다행히 알아서 맞으러 온 적들이 있었고 나는 그 적들에게 총을 쏘려고 게임 화면을 찾아봤지만 총을 쏘는 버튼은 없었다. 게임은 자동공격으로 적들을 처리했고 적들의 기지보다는 적을 우선으로 처리했다. 또한 화면 가운데 하단에 아이템들이 있었고 해당 아이템들도 직접 사용해봐야 어떤 아이템인지 알 수 있었다.

일단 급하니까 막 갈겨쓰긴 했는데 아이템을 알고 있었으면 좀 더 적재적소에 잘 쓰지 않았을까 하는 생각이 든다.

유저가 게임을 좀 더 쉽게 플레이할 수 있도록 하는 방안이 필요해보였다. 아주 좋아했던 The escapist(감옥 탈옥 겜)라는 게임도 첫 번째 게임은 매우 불친절 했다. 유저에게 조금 불친절한 게임이었다. 간수를 때려서 키를 빼앗고 녹인 플라스틱에 열쇠를 찍어서 몰드를 만들고 그 몰드에 또 녹인 플라스틱을 이용해서 가짜 키를 만들어야 방을 탈출할 수 있었고, 몰래 삽으로 땅을 파야만했었고, 땅파는 시간에는 자신이 탈옥중이라는 것을 들키지 않기 위해 더미를 만들어야했다.

이 모든 것은 게임에서 알려주지 않았다. 유저가 플레이 해야만 알 수 있는 것이었다.

하지만 The escapist가 흥행했던 이유는 컨텐츠의 양, 그리고 탈출할 수 있는 방법이 유저마다 다 다르고 굉장히 많았다는 것이다.

하지만 이 게임처럼 전투와 액션의 방향성이 확실한 게임에서는 유저가 어떤 행동을 해야 하는지 확실하게 잡아주는 '행동 지침'이 꼭 필요해보였다. 초반에 간단한 튜토리얼을 넣어주거나, 수행해야 하는 미션을 상단에 알림처럼 띄우는 방법도 좋은 것 같다.

[수박박수 수박박수박]#1 - 안드로이드 테스트 등록 및 피드백

yellta — Wed, 29 Jul 2026 21:10:23 +0900

원래는 7월 앱인 토스에 들어갈 게임이지만 안타깝게도 게임은 심사를 받아야한다는 기준이 있어서 앱인 토스에 포기한 작품

내가 만들 어플의 Thumb nail

그리고 그 작품의 개발 일지를 작성해보려고 한다.

7월 중순쯤

첫 개발에 시작했다. 앱인토스에 출시할 작품이었으니 React + phaser + app-in-toss SDK를 사용했었고, 지금은 Capacitor를 이용해서 안드로이드 어플로 변경했다.

Capacitor를 사용한 이유

- 기존 웹 UI와 로직을 재사용할 수 있다.

- Android Stuido프로젝트를 사용해서 APK/AAB빌드 하기가 용이했음
- 카메라, 파일 저장, 공유, 알림, 진동같은 Android기능을 붙힐 수 있었다.

- React/Vue 등 특정 프레임워크에 묶이지 않아 가벼운 웹 앱에도 쓰기가 좋았음

-Capacitor는 Android 네이티브 프로젝트 구조를 유지해, 빌드 오류나 권한 문제를 Android Studio/Gradle방식으로 대응하기 편했음

즉 웹 앱의 개발 속도와 정식 Android 빌드.확장사이의 균형이 좋았기 때문이다.

7월 29일

대략적인 프로젝트가 완성되었다. 완전히 데모이다. 폰화면에서 보니까 화면도 안맞고 완전 난리임

게임 플레이 화면이다.

나름 나쁘지 않은 결과를 가져온 것 같다! 왜냐면 엄청 빨리 만들었기 때문이다.

안드로이드 AAB파일을 빌드하고, 12명의 테스터를 구해서 테스트를 진행하고 있다. 물론 테스트 중에도 추가해야할 항목들이 있다.

Redit에 안드로이드 테스터들을 구하면서 몇 가지의 피드백을 받았다.

이 친구가 설명해 준것
Tester들은 몇 판 하지 않을 것 - 매일 보상시스템이나 매일매일 들어올 동기나 이유가 약하기 때문이다. 매일 플레이 해야하는 동기가 있어야하는 것

위 지점은 내가 미처 생각하지 못한 것이었다.
Thank you redditer

생각보다 괜찮은 피드백을 얻어서 놀랐다.

App-in-toss 7월 공모전 나가보기(Summer-check)

yellta — Tue, 21 Jul 2026 21:52:55 +0900

아니 개화나게 내가 쓴 글 다날아감 하아...

아무튼 App-in-toss 7월 Summer공모전 후기를 남기려고 한다.

우선 첫 번째로 나는 수박 게임을 만들려고 했는데 게임 심사 기간 때문에 실패함(게임을 만들거면 프로토를 빨리 만들어서 빨리빨리 출시하는 방향으로 진행하자)

내 나름대로 이번 프로젝트를 통해서 얻고싶은 것이 있었다.

바로 "유저의 트래픽은 어떻게 모으는가"에 관한 것이었다.

앱인 토스 어플 분석

토스 어플을 켜서 앱인토스에서 어떤 어플이 핫한지 조사해보았다.

여러가지 어플이 있지만 아무래도 가장 핫한 것들은 게임과 관련한 것들이었다. (초기 게임을 기획한 이유이기도 했음)

특히 게임도 간단한 게임류가 주를 이뤘다. 무한의 계단같은 것들 그래서 간단한 게임을 기획했는데

게임은 심사받아야해서 포기함 ㅋ 왜냐면 기간이 절대로 안나왔기 때문이다.

그래서 남은 어플들중에서 어떤 어플이 유행하나 찾아봤다. 하지만 게임을 제외하고는 모두 고만고만했던 것 같다.

주제 정하기

생각보다 주제를 정하기 위해서 고민을 굉장히 많이 했는데

우선

1. 유저의 리텐션을 고려할 것인가
2. 비지니스 확장성이 있는가
3. 사용하기가 쉽고 공유하기 좋은 컨텐츠인가

를 염두했는데 막상 만든 결과는 1,2는 버렸다. ㅋ

Summer라는 주제와 Health, food같은 키워드들을 조합해서 여러가지 앱 아이디어를 떠올렸지만 우선 내 생각은

1. 사업자를 낼 시간이 없다. 즉 수익화 광고는 버린다.
였다.

그러면 이번 주제에서 나는
"사람들이 가볍게 즐기고, 공유하기 쉬우며, 바이럴을 탔으면 좋겠다"에 집중해서 어플을 기획했다.

그 결과가

"나의 여름맛 테스트"

우선 첫 번째로 앱의 리텐션은 포기했다. 하지만 가볍게 만들고 여러 사람에게 공유가 되었으면 하는 마음은 있었다. 이 테스트가 시장에 먹히는지 테스트해보고 싶었다는 이야기다.

또한 트위터에서 내가 만약 00가 된다면 혹은 나의 MBTI의 테스트가 한창 유행했던 것이 생각나서 테스트류로 골랐다.

단순한 테스트로는 크게 매력이 없을 것 같아 사용자의 운세기능도 추가했다.
그리고 그게 전부다.

원래는 투두리스트 기능과 투두를 실행하면 애니메이션을 보여주려고 했지만 크게 매력이 있는 어플처럼 다가오지 않았다. 물론 시장의 반응은 달랐을 수도 있었겠지만 적어도 나는 그게 별로라고 생각했다.

앱의 테스트 결과는 대략 보면 이렇다.

사실 맘에 안들지만 뭐 이 프로젝트가 바이럴을 탈지 안탈지도 모르겠고, 이용하는 사람이 얼마나 될지도 모르겠다. 그래도 콘텐츠를 기획하는 감각을 조금 익혔다고 생각하는 편이 정신 건강에 좋다.

아무튼 앞으로도 어플을 계속 만들어낼텐데 이번 기회를 토대로 어떤식으로 접근해야하고 어떤걸 조합해야하는지 조금 배운것 같기도 하다.

후우... 다음 프로젝트도 화이팅...해보자...

26년도 7월 25일 추가

소중한 X 팔로워분이 리뷰를 남겨주셨다!! 내용을 정리해보자면

- 기능은 단순하나 쓰는 흐름이 편했다.

- 결과 페이지에서 "사용자를 기분좋게 설명해주면서도 너무 가볍거나 의미 없지는 않고, 그렇다고 사람을 과하게 규정하지 않는 밀도", 활동추천도 실행난도가 낮아서 정서적으로 편했다. 여러 추천 중 하나를 "오늘의 작은 여름 미션"으로 정리한 것도 선택 부담을 줄이는 감각과 이어졌다.

- 사용자가 이걸 받고 어떤 기분이 되어야하는가? 기능을 어떤 방식으로 건네야하는가? 를 잘 본 느낌

이런 너무너무 감사한 피드백을 남겨주셨다 흑흑

그리고 버그도 찾아주심 ㅋ

[BUG] 같은 선택지를 선택해도 다른 결과가 나오는 상황 발생

문항 선택 버튼을 빠르게 여러 번 탭하면 답변 수, 문항 번호가 어긋나서 건너뛰는 문항이 생기거나, 같은 선택을 해도 음식 결과가 달라질 수 있었다.

화면에 표시된 문항의 첫 선택만 답변으로 반영하고, 다음 문항으로 진행중인 추가 입력은 무시해서 일정한 값이 들어오도록 값을 수정했다.

개인적으로 유저가 사용하면서 가장 빠르고, 간편하게 귀찮게 입력해야하는 것을 최소한으로 지정하고 어플을 즐겼으면 좋겠다고 생각했는데 생각보다 그게 잘 나온것 같아서 다행이다!

App in toss 공모전 나가보기...근데?...

yellta — Fri, 17 Jul 2026 23:30:47 +0900

App in toss가 출시가 되고 여러사람들이 공모전을 도전하고 있다. 나도 그 중 하나

7월의 주제는 Summer와 관련된 주제였다.

내 기준 App-in-toss어플을 살펴보니

아무래도 게임이 사람들의 반응을 끌기 좋은것 같았다. (무한의 계단같은 것들)

그래서 나는 게임을 만들어 본 적은 없으나 혹싀?... 하는 마음에서 바이브 코딩으로 게임을 만드는 도전을 시작하게 된다.

D-16

7월 15일 1일차 아이디어 구상하기

나에게 주어진 시간은 별로 없었고 하루죙일 공모전을 위해서 개발을 할 수도 없었다. 물론 다른 출전자분들도 마찬가지겠지만

그래서 가벼운 스낵게임 형식으로 준비하는게 좋을것 같다고 생각했고, 그때 갑자기 미니게임 천국이 기억났다.

고등학교때 미친듯이 했던 모바일 게임을 생각하며 수박 sorting게임을 구상했다.

바로 데모 프로젝트를 만들기 시작했다.

2일째에 쓰는거라서 원본 데모는 지금 수정되고 없다ㅋㅋㅋ 이게 처음에 올린 버전
일단 급하게 에셋을 뽑아서 에셋 위치만 배치시켰다.

처음에 수박 정렬 페이지로 넘어오면 버그 장난아니였음
그리고 dev 0버전은 정말 모든 에셋을 html + css로 만들어서 에셋 퀄리티며 그런게 매우 끔찍했다... 정신차리고 아이패드 들고 그림 그려서 GPT한테 설명하니까 위와 같은 이미지를 뽑아줬다

일단 끔찍한 레이아웃이지만 작동은 잘한다... 이제 점점 고도화 시켜야지....

7월 16일 : 2일차 UI테마 변경

우선 게임을 할 때 심심했었는데 Gemini로 노래를 만들고, 효과음은 무료인거 어디서 주워왔다. 가라지밴드로 잘라서 효과음으로 만들었다.

GPT에게 음원 에셋을 써달라고 했는데 생각보다 매우 맘에들었음ㅋㅋㅋ

추가로 이제 답이 없는 레이아웃을 수정해야했는데 어쩌다 보니 노래를 8bti형식으로 뽑아버려서 게임 테마도 8bit로 아기자기한 픽셀 그래픽으로 변경하기로 했다.

근데 배경이 너무나도 귀엽다 어엉어엉엉어엉엉어엉엉엉

이렇게 좋은 퀄리티로 뽑으면 남은 에셋도 좋은 퀄리티로 뽑아야해서 조금 곤란했다. 생각보다 정성이 꽤나 많이 들어가야해서... 이미지를 뽑는 것 자체는 괜찮았는데 컴포넌트들을 어떻게 배치할 것인지가 관건이었다. 나 같은 경우 게임을 완전 처음 만들어보기 어쩌면 프롬프트에게 지시를 잘 내리지 못한 느낌도 어느정도 있는 것 같다. 하지만 GPT에게 예시를 확실하게 보여주려고 나름 노력했다.

사용한 예시 :

code pen text animation
pinterest에서 줍줍한 픽셀아트 이미지들

그리고 코덱스가 코딩해줄때까지 기다리면서 한 수박sorting점수 진짜 잘했음
참고로 메인이랑 테마가 다른건 테마를 바꾸고 있는 중이기 때문

이날은 토큰을 70%나 태워버린 날이기 때문에 ㅋㅋㅋ

아무튼

게임 화면도 이렇게 만들어버려서 나름 보람찼던 날이다.

7월 17일 3일차 UI셋업 마무리 + 고도화 전략 기획하기

실제로 마무리 페이지도 만들었다.

근데 한 가지 중요한 문제가 있었다

게임은 심사가 필요하다

진짜 큰일이다. 지금 속도라면 구글에 내지도 못하고 반대로 돈주고 심사를 받기도 너무 부족한 시간이다... 그래서 잽싸게... 주제를 틀게 되는데...

3만원으로 바이브 코딩을 시도해보기

yellta — Fri, 10 Jul 2026 21:52:16 +0900

요즘 핫한 바이브코딩

하지만 딸-각 한 방으로 모든게 만들어지는 것이 아닌듯이 바이브코딩도 딸-각 한 방으로 모두 다 만들어지는 것은 아니다.

최근에 코딩을 위한 AI도구가 너무나도 많이 나왔다. claud code, codex, cursor와 같은 툴들 말이다. 이 친구들 모두 다 조건이 따랐는데 바로 토큰을 사용한다는 것이다. 그렇다면 바이브 코딩을 하게 된다면 무조건 클로드코드, 코덱스를 사용해야하는 걸까?

클로드 코드 MAX플랜 220달러짜리를 질러서 과연 바이브 코딩을 잘 할 수 있을까?

필자는 무조건 아니라고 본다.

바이브코딩의 매력은 "AI가 짜주는 코드 내가 검수해서 만든다."라고 생각한다. 즉 나는 결정권자가 되는 것이지 어떠한 제품을 만들어줘 라고 빽빽 떼를 써서는 안된다.

이 글에서는 단 돈 3만원짜리 챗봇 그것도 코딩할 때 그리 좋지 않다고 평가를 받는 Gemini와 함께 바이브코딩을 해볼 것이다. 3만원짜리 챗봇으로도 충분히 괜찮은 퀄리티의 서비스를 뽑아낼 수 있다. 대신 딸-각은 없다. 대화하며 배우고 결정하고, 발전시키는 방법을 알아볼 것 이다.

바이브 코딩을 위한 "최소한의 개발 지식"

바이브 코딩을 할 때 당연히 개발지식이 필요하다. 물론 엄청 어려운 개발지식은 꺼내지 않을 것이다. 서비스가 커진다면 당연히 고려해야하는 것들이 있지만 내가 만드는 서비스, 어플이 많은 사용자가 쓸 거라는 생각은 지금은 버리는게 좋다. 가장 최소의 자원으로 잘 돌아가는 서비스를 만드는 것이 목적이다.

Frontend + Backend + DB란?

Frontend는 눈에 보이는 것이다.

이처럼 서버에서 받은값을 가공해서 사용자에게 맞게 뿌려주거나, 사용자의 편의성을 위해 버튼이나 여러 요소들(뉴스, 회원 가입 등등)을 배치하는 것을 의미한다.

Backend는 무엇일까?

Backend는 쉬운말로 서버이다. 즉 서버에서 데이터를 Front로 보내주고 Front가 가공해서 쓰는 것이다.

DB는? 데이터를 저장하는 공간이다.Database의 줄임말이다. excel처럼 데이터를 보관한다고 생각하면 된다.

그래서 FRONT + BACKEND + DB가 어떻게 상호작용 하냐면 아래의 그림과 같다.

여기서 복잡하게 간다면 뭐 로드밸런서니, 분산 DB니 그런것들이 있지만 그런건 엄청 큰 기업에서나 필요한거고 우리는 소규모의 작업이 필요하니 위 그림처럼 간단하게 가면 된다.

흐름을 보면 알 수 잇는데
1. FRONT에서 유저에게 보여줄 데이터가 필요하다고 Backend에 요청한다.
2. Backend는 요청한 자료들을 보여주기 위해 DB에서 정보를 뒤적거리면서 찾는다.(유저 A의 프로필정보, 카테고리 정보 등등)

3. DB에서 찾은 정보를 Backend가 가공한다. (ex) 날짜가 DB에는 20260623 으로 저장되어 있는데 26/6/23으로 표기를 한다던가, DB에는 Book이라고 저장되어 있는데 한국말로 번역해서 책 으로 보내준다던가 하는 것들)
4. Front는 요청한 정보를 받아서 유저가 잘 볼 수 있도록 화면에 뿌려준다.

여기까지 데이터가 "어떤 흐름으로 이동"하는지 확인해보았다.

위 로직은 웹/앱 모두 적용할 수 있다.

연습해보기

그렇다면 당신이 번뜩이는 아이디어가 생각나서 이제 만들고 싶다고 가정하자

그렇다면 해야하는 순서는 아래와 같다.

0. 아이디어 정리하기 (제일 중요)

1. 레이아웃 구성하기

2. 각 레이어별로(Frontend - Backend - Database)어떤 데이터가 오고가야하는지 생각하기

3. 주요 기능의 알고리즘(로직이라고 생각하면 된다.)은 무엇인지 생각하기

0단계

아이디어를 정리하는 구간이다.

아이디어는 글로 적어도 상관없고 내용이 많지 않다면 머릿속에다 저장하고 바로 1. 레이아웃 구상하기로 넘어가도 좋다.

하지만 중요한 것은 만들려는 것이 무엇인지 확실하게 알고있어야 한다는 것이다.

예를 들어 투두리스트를 만든다고 가정하자. 투두리스트의 기능에는 이런것들이 있다.

1. 로그인 기능

2. 투두리스트기능

3. 투두항목을 완료할 때 마다 2포인트씩 쌓이는 포인트제도

이렇게 크게 기능을 정해놨다고 하자 그렇다면 생각을 좀 더 세분화하는 것이다. 이때 AI를 적극적으로 활용해도 좋다.

좋아 너는 시스템 기획자야, 나는 투두리스트 웹을 만들려고해 기능의 리스트는 아래와 같아
1. 로그인기능
2. 투두리스트기능
3. 투두 항목을 완료할 때마다 2포인트씩 쌓이는 포인트제도

여기서 세부적으로 어떻게 기능을 추가할 수 있는지 알려줄래? 대신 내가 말한 기능의 범위에서 벗어나면 안돼 나는 최소한의 기능으로 만들거야

필자는 위와 같은 형식으로 Gemini에게 질문을 던졌다.

여기서 중요한 것은 "내가 말한 기능의 범위에서 벗어나면 안돼 나는 최소한의 기능으로 만들거야"이다. 이를 MVP, 즉 최소한의 기능만 출시한다는 것인데 이를 명시해주지 않으면 지 맘대로 이런 저런 아이디어를 붙여 개발해야하는 사이즈가 커져버린다.

gemini의 답변은 아래와 같다.

좋습니다! 최소 기능 제품(MVP)의 핵심 매력은 '최소한의 공수로 최대의 직관성을 주는 것'입니다. 말씀하신 3가지 기능의 범위를 절대 벗어나지 않으면서, 사용자가 "어, 이거 제대로 작동하네?"라고 느낄 수 있는 디테일한 세부 기획을 잡아드릴게요.
1. 로그인 기능 (최소한의 인증)
가장 심플하게 구현하되, 보안과 사용자 편의를 챙기는 선까지만 기획합니다.
이메일/비밀번호 기반 가입 및 로그인
소셜 로그인(구글, 카카오 등)은 API 연동 공수가 들므로 제외하고, 가장 기본형태로 구성합니다.
세션 유지 (자동 로그인)
웹앱 특성상 새로고침할 때마다 로그아웃되면 사용자 경험이 최악이 됩니다. 브라우저(Local Storage 또는 Cookie)에 토큰을 저장해 로그인 상태가 유지되도록 합니다.
유효성 검사 (Validation)
이메일 형식 오류(@ 포함 여부), 비밀번호 최소 글자수(예: 6자 이상) 제한 정도로 가입 단계의 에러를 방지합니다.
2. 투두리스트 기능 (핵심 도메인)
CRUD(생성, 조회, 수정, 삭제)를 가장 직관적으로 배치합니다.
할 일 등록 및 목록 조회
텍스트 입력 후 엔터(Enter)를 누르거나 '추가' 버튼을 누르면 즉시 리스트에 반영됩니다.
오늘 해야 할 일들을 한눈에 볼 수 있는 단일 리스트 구조로 갑니다. (복잡한 폴더/카테고리 분할 제외)
할 일 완료 체크박스
체크박스를 누르면 텍스트에 취소선(예: ~~할 일~~)이 그어지며 완료 상태로 변경됩니다. (이 순간 3번의 포인트 획득 로직과 연결)
할 일 수정 및 삭제
오타 수정을 위해 더블 클릭이나 '수정' 아이콘으로 텍스트를 바꿀 수 있게 합니다.
잘못 적었거나 필요 없는 항목은 '삭제(X)' 버튼으로 지울 수 있습니다. (단, 삭제 시에는 포인트가 변동되지 않음)
3. 포인트 제도 (동기부여 및 보상)
범위를 넓혀 '포인트 상점' 같은 것을 만들면 일이 커집니다. 주어진 범위 내에서 포인트가 쌓이는 규칙과 시각적 피드백에만 집중합니다.
상단 헤더에 누적 포인트 표시
화면 우측 상단이나 프로필 옆에 현재 포인트: 12 p와 같이 실시간으로 내 포인트를 확인할 수 있는 UI를 배치합니다.
완료 시 실시간 적립 및 알림 (Toast Alert)
투두 체크박스를 체크하는 순간, 화면에 잠시 "투두 완료! +2포인트가 적립되었습니다."라는 팝업(토스트 메시지)이 떴다가 1~2초 뒤 사라집니다.
완료 취소(체크 해제) 시 포인트 회수 (어뷰징 방지)
핵심 규칙: 완료했던 항목을 다시 미완료(체크 해제) 상태로 돌리면 2포인트가 차감됩니다. 이 예외 처리가 없으면 사용자가 같은 투두를 무한으로 체크/해제하며 포인트를 복사하는 버그가 발생합니다.
  시스템 기획자로서의 한 줄 요약
화면은 [상단바: 로그인 정보 & 현재 포인트] + [중앙: 투두 입력창 & 투두 리스트] 라는 아주 심플한 단일 페이지(Single Page) 형태로 구성하는 것을 추천합니다.
이 안에서 데이터가 꼬이지 않도록 '완료 취소 시 포인트 차감' 로직만 신경 써서 개발하시면, 아주 탄탄하고 깔끔한 MVP 웹이 완성될 것입니다. 진행하시면서 데이터베이스 구조나 특정 화면 UI 흐름에 대해 더 구체화하고 싶은 부분이 있으신가요?

그럼 AI가 준 정보를 가지고 처음에 제시한 세 가지의 기능을 세분화 한다.

Gemini가 준 내용에서 크게 변하지 않았다. 거기에 내 아이디어를 붙힐게 있다면 붙히면 된다. 로그인의 경우 방법이 여러개 있었는데
1. 소셜 로그인(구글, 카카오로그인)
2. 자체 이메일, 비밀번호
3. 자동로그인

여기서 나는 1번 방법만 선택했다. 물론 세 가지를 다 선택할 수도 있다. 하지만 내가 개발을 모르는 사람이라면 뭐가뭔지 알 수가 없다. 이럴때 다시 AI를 활용하면 된다.

로그인 방법으로
1. 소셜 로그인
2. 자체 이메일, 비밀번호
3. 자동로그인

이렇게가 추천 해 줬는데 각각 장 단점이 무엇인지, 기술적으로 내가 고려해야하는 것이 있는지 알려줄래?

기획하신 최소 기능(MVP) 범위 내에서 이 3가지 인증 방식을 도입할 때, 시스템 기획자와 개발자의 관점에서 각각 어떤 이득과 대가가 따르는지 명확하게 짚어드리겠습니다.

1. 소셜 로그인 (OAuth 2.0)
구글이나 카카오 등 기존 플랫폼의 계정을 빌려 로그인하는 방식입니다.
장점
최고의 사용자 편의성: 사용자가 별도의 회원가입 절차(비밀번호 입력, 이메일 인증 등)를 거치지 않고 버튼 클릭 한두 번으로 가입할 수 있어 이탈률이 매우 낮습니다.
보안 부담 감소: 비밀번호 암호화 저장, 데이터베이스 해킹으로 인한 비밀번호 유출 등의 치명적인 보안 책임에서 자유로워집니다.
단점
초기 연동 공수: 각 플랫폼(구글, 카카오 등)의 개발자 센터에 앱을 등록하고, API 키를 발급받아 연동하는 초기 설정 작업이 필요합니다.
기술적 고려사항
토큰 교환 흐름 이해: 소셜 플랫폼이 주는 인가 코드(Authorization Code)를 받아 백엔드에서 Access Token으로 교환하고, 이를 통해 유저 정보를 가져오는 OAuth 2.0 흐름을 정확히 구현해야 합니다.
플랫폼별 데이터 규격 다름: 구글이 주는 유저 식별자 키값과 카카오가 주는 키값의 명칭이나 구조가 다릅니다. 이 정보를 우리 DB의 '유저 테이블'에 어떻게 통일성 있게 저장할지 구조를 짜야 합니다.

2. 자체 이메일 / 비밀번호 로그인
가장 전통적이고 독립적인 로그인 방식입니다.
장점
외부 의존성 없음: 구글이나 카카오의 서버가 터지거나 API 정책이 바뀌어도 우리 서비스는 아무런 영향을 받지 않고 정상 작동합니다.
완전한 데이터 제어: 가입 양식을 우리 입맛대로 제어할 수 있습니다.
단점
가입 허들: 사용자가 이메일을 타이핑하고 비밀번호를 최소 2번 입력해야 하므로 귀찮음을 느낍니다.
보안 책임 전적으로 부담: 해킹이나 유출 사고에 대비한 보안 처리를 온전히 직접 해야 합니다.
기술적 고려사항
비밀번호 단방향 암호화 (필수): DB에 비밀번호를 절대 평문(Plain Text)으로 저장하면 안 됩니다. BCrypt나 Argon2 같은 강력한 해시 함수를 사용해 암호화하여 저장해야 합니다. 개발자 본인도 유저의 비밀번호를 알 수 없어야 정상입니다.
예외 처리 기획: 사용자가 비밀번호를 잊어버렸을 때를 위한 '비밀번호 찾기/재설정' 기능이 추가로 필요해질 수 있어, 최소 기능 범위가 살짝 늘어날 리스크가 있습니다.

3. 자동 로그인 (Session / JWT 유지)
브라우저를 껐다 켜도 로그인 상태를 유지해 주는 기능입니다. (독립된 로그인 방법이라기보다는 1번이나 2번 로그인 후 적용되는 '유지 기술'에 가깝습니다.)
장점
이탈 방지: 웹사이트에 들어올 때마다 매번 로그인 버튼을 누르지 않아도 되므로, 투두리스트처럼 자주 들락날락하는 서비스에서 만족도가 극대화됩니다.
단점
공용 PC에서의 보안 취약성: PC방이나 강의실 등 공용 컴퓨터에서 로그아웃을 안 하고 창을 닫으면 다음 사람이 내 투두리스트와 포인트를 그대로 볼 수 있습니다.
기술적 고려사항
토큰 저장소 선택 (보안 vs 편의): 자동 로그인을 구현할 때 브라우저의 어디에 인증 키(토큰)를 저장할지 결정해야 합니다.
Local Storage: 자바스크립트로 접근하기 쉬워 구현이 매우 간단하지만, XSS(크로스 사이트 스크립팅) 공격에 취약합니다.
HttpOnly Cookie: 자바스크립트로 접근이 불가능해 보안성이 훨씬 높지만, 백엔드와 프론트엔드 간의 쿠키 설정(CORS, SameSite 등) 플래그를 맞추는 까다로운 작업이 동반됩니다.
만료 기간 설정: 자동 로그인의 유효 기간(예: 14일 또는 30일)을 두고, 기간이 지나면 안전하게 다시 로그인하도록 처리하는 로직이 필요합니다.

 ️ 개발 공수를 줄이기 위한 기획자의 팁
"정말 최소한의 기능"으로 빠르게 프로토타입을 뽑고 싶다면, [구글 소셜 로그인 + Local Storage를 활용한 간단한 토큰 저장] 조합이 개발 가성비가 가장 좋습니다. 비밀번호 암호화나 비밀번호 찾기 로직을 통째로 생략할 수 있기 때문입니다.
혹시 이 중에서 어떤 방식을 메인으로 가져가고 싶으신가요? 선택하신 방향에 맞춰 백엔드 DB 테이블 구조(User Table) 디자인을 도와드릴 수 있습니다.

이런식으로 답변을 준다. 물론 처음에는 모르는 것 투성이일 것이다. 하지만 여러분이 바이브코딩을 정말로 괜찮게 하고싶다면 모르는 부분은 AI에게 계속 끊임없이 질문해야한다. 지식을 채우고 연결지어서 어떤 기술을 선택해야하는지 AI가 아닌 사람이 선택해야 정말로 유지보수가 가능하고, 계속 발전시킬 수 있는 코드가 나오기 때문이다.

이번 글의 예시에서는 google 로그인을 선택하도록 하겠다.

google로그인은 생각보다 간편하고 구현도 쉬울뿐더러 유저가 이메일, 비밀번호를 생성하지 않아도 된다. (요즘 유저들은 귀찮은걸 매우매우 싫어해서 소셜 로그인은 필수이다.) 또한 자동로그인기능은 패스하도록 하겠다. Session과 JWT를 알아야하는데 이 둘은 개념도 꽤나 깊게 들어가야하고, 관리해야하는게 많아진다. 물론 사이트에 접속할 때마다 로그인을 해야하는 불편함은 감수해야하는 걸 잊지 말자.

1. 레이아웃 구상하기

다음은 손그림이 필요한 시점이다.

0번에서 정리한 아이디어를 가지고 이제는 화면을 그려보는 것이다.

이처럼 허접해도 괜찮다. 우선 필자는 레이아웃을 그릴 때 "모든 경우의 수"에 따라서 그림을 그리려한다.(물론 간단한 몇 개는 생략이 되는 경우도 있다.)

1. 로그인이 된 상태인가 안된상태인가
2. 투두가 선택된 상태, 선택되지 않은 상태, 수정중이라면 커서가 깜빡거리는 기능 등등

이건 구글에서 주워온 이쁘게 wireframe을 구성한 사진이다. 어떤 버튼을 클릭하면 어디로 넘어가는지. 그 넘어간 화면은 무엇인지 알 수 있게 작성한다.

사실 wireframe, ui flowchart라고 검색하면 레퍼런스가 많이 뜬다. 하지만 같은점은 웹 사이트 혹은 어플을 보고 어떤 화면으로 구성이 되는지, 무슨 버튼을 누르면 무슨 창이 나오는지, 어떤 기능이 구성되어 있는지 정확하게 알아볼 수 있으면 괜찮다.

2. 각 레이어별로(Frontend - Backend - Database)어떤 데이터가 오고가야하는지 생각하기

이제 각 프레임도 그렸으니까 본격적으로 설계를 하는 차례다.

각 화면에 들어가는 요소들, 기능들을 정리했으니 이제 그걸 연결할 데이터를 설계하는 것이다.

우선 허접한 와이어 프레임을 다시 봐보자

우선 메인페이지에서 로그인된 유저의 경우 보여지는 화면을 봐보자.

데이터로는

유저이름, 포인트(12라고 위에 적혀있음), 완료된 투두리스트, 완료 안된 투두리스트

이렇게 있다.

여기서 생각을 정말 잘해야한다. 데이터가 어떤 흐름으로 흘러가는지 제대로 파악해야 제대로 된 제품을 만들 수 있다.

우리는 주고 받는 데이터를 모델이라고 칭하자(샤넬쇼 모델 아님)

모델은 각각 도메인을 가지고 있는 서랍장이라고 생각하면 된다.

즉

유저 서랍장에 들어있는 유저 정보, 투두리스트 서랍장에 들어있는 유저별 투두리스트 정보

그럼 유저 서랍장엔 어떤 데이터를 넣을지 생각해봐야한다. 데이터 저장소를 만든다는 것이다.

유저 저장소에는 각 유저의 식별번호, 닉네임, 포인트가 들어있다.

식별번호는 닉네임은 같지만 서로 다른 인물임을 확인하기 위해 만든다. 닉네임은 말 그대로 유저의 닉네임 여기서는 구글 로그인을 사용하기로 했으니까 구글 닉네임으로 정하겠다. 그리고 각 유저가 가지고있는 포인트이다.

투두리스트 저장소도 식별번호가 들어간다. 서로 다른 유저가 같은 투두항목을 넣을 수 있기 때문이다. 예를 들면 강아지산책 같은 항목을 완전히 똑같이 넣을 수 있다는 의미이다. 하지만 둘은 엄연히 다른 사용자가 넣은 다른 항목이기 때문에 관리가 되어야한다. 즉 고유한값이어야 한다.

유저 식별번호도 들어간다. 투두리스트를 봤을때, 이 항목의 주인이 누구인지 표현할 수 있어야 유저 별로 데이터를 표시할 수 있다. 나머지는 투두리스트 항목과 완료의 여부이다. 보통의 투두리스트는 보통 완료가 되었다고 바로 삭제하거나 하지 않고, 흐리게 표시를 하거나 가운데에 줄을 쳐놓곤 한다. 해당 분기를 확인하기 위해 넣는다.

위 처럼 데이터 모델을 짜고, 내가 잘 모르겠으면 gemini한테 또 물어보면 된다.

프롬프트는

내가 만드는 웹앱 화면에
유저이름, 포인트(12라고 위에 적혀있음), 완료된 투두리스트, 완료 안된 투두리스트
이렇게 적혀있어
완료 된 투두리스트는 바로 삭제 안하고 흐리게 표현할거야
데이터 모델을 어떻게 구성하면 좋을까?

1. 유저 데이터 모델 (User)
로그인 정보와 화면 상단에 보여줄 이름, 현재 누적 포인트를 관리합니다.
id (식별자): 각 유저를 구분하는 고유 키 (예: 고유 문자열 또는 숫자)
username (유저이름): 화면 상단에 표시될 유저의 이름이나 닉네임
points (포인트): 현재 유저가 보유한 포인트 (화면에 12라고 표시될 데이터, 기본값 0)

2. 투두리스트 데이터 모델 (Todo)
화면에 그려질 할 일 항목들을 관리합니다. 완료 여부와 화면 표시 여부(삭제 대체)를 구분하는 것이 핵심입니다.
id (식별자): 각 투두 항목을 구분하는 고유 키
user_id (외래 키): 이 투두가 어떤 유저의 것인지 연결하는 유저 식별자
content (내용): 할 일 텍스트 (예: "방 청소하기")
is_completed (완료 여부): 체크박스가 눌렸는지 여부 (true / false)
화면 구현 가이드: 이 값이 true이면 프론트엔드에서 CSS 클래스(예: opacity: 0.5; text-decoration: line-through;)를 주어 흐리게 표현하고 취소선을 긋습니다.
is_deleted (삭제 여부): 실제로 DB에서 지우지 않고 화면에서만 안 보이게 숨기기 위한 플래그 (true / false, 기본값 false)
유저가 '삭제' 버튼을 눌렀을 때 데이터를 바로 Delete 하지 않고, 이 값을 true로 업데이트(Soft Delete)합니다.
created_at (생성일시): 투두가 생성된 시간 (최신순 정렬 등을 위해 필요)

이런식으로 답을 준다. 우리가 앞전에 미처 고려하지 못했던 is_deleted도 만들어줬다. 이제 만들어진 데이터를 가지고 Front와 Backend를 활용해서 조립할 시간이다.

3. 주요 기능의 알고리즘(로직이라고 생각하면 된다.)은 무엇인지 생각하기

이제 알고리즘을 생각해보자

우선 알고리즘이랑 문제를 해결하는 방법이다.

우리는 크게 네 가지의 기능이 있다.

1. 구글로 로그인하기

2. 투두리스트 생성하기

3. 투두리스트 삭제하기

4. 투두리스트 완료할 때마다 2포인트 얻기

기능은 최대한 자세하게 쪼개야한다. 즉 하나의 기능으로만 표현되어야 한다.
1. 투두리스트 생성,삭제하기 -> 1. 투두리스트 생성하기 2. 투두리스트 삭제하기
이렇게 쪼개야 정확하게 기능 구성을 할 수 있다.

그러면 각 기능별로 어떻게 구현하면 좋을지 생각하는 것이다.

구글 로그인하는 과정을 그린것이다.

1. 유저가 로그인 버튼을 클릭한다.

2.Front는 로그인 화면을 보여준다.
3. 유저는 구글 로그인 버튼을 클릭한다.
4. Backend는 구글 로그인 기능을 연동한다.

이런식으로 이루어진다. 이 경우는 조금 특별한데 구글 로그인이라는 외부 기능을 넣은것이다. 클로드 코드의 mcp처럼 말이다.

바로 다음 기능으로 넘어가보자

두 번째 기능인 투두리스트 생성하기다.

이것도 굉장히 간단해서 Backend나 Front에서 크게 처리할 과정이 없다. 하지만 여기서 자세하게 봐야하는 것은

입력 받은 데이터 전달이다.

위에서 우리는 데이터 모델을 짯다.

즉 User가 Front로 보낼 때 주는 데이터는

1. 자신의 식별번호

2. 닉네임

3. 새로운 투두리스트 항목

이렇게 세 가지가 된다.

그럼 Backend는?

Front에서 전달받은 Data를 DB에 저장한다. 그렇다면 백엔드는 투두리스트 서랍장에

user_id : Front에서 전달받은 유저의 식별번호
content : 투두리스트 항목

is_completed : false (true or false)
is_deleted : false(true or false)

이렇게 넣어야한다. 하지만 한가지 넣지 않는 값이 있는데 바로 id이다.

이 사진은 투두리스트 서랍장에서 가져온 것이다. id값은 user가 정하지도 않고 Front가 정하지도 않는다. 바로 Backend에서 정하거나 DB에서 정하게된다.

우선 id값은 각 투두리스트는 모두 다른 항목이라는 것을 알려주기 위해 존재하는 유일한 값이다. 이 유일한 값은 Backend에서 랜덤으로 생성할 수도, DB에서 랜덤으로 생성할수도 아니면 순차적으로 생성할 수도 있다.

보통 id는 1,2,3,4,5,6,7 이런 숫자 순서로도 할 수 있지만 완전히 랜덤인 숫자 값으로도 매길 수 있다. 하지만 둘 다 유일한 값이라는건 변하지 않는다.

(1,2,3,4,6,7 처럼 순차적인 숫자로 정하느냐, 랜덤 숫자 값으로 정하느냐에 따라서 성능이 달라질 수 있다. 하지만 일단 여기서는 가볍게 넘어가도록 하자)

3. 투두리스트 삭제하기는 2번 기능과 비슷하기 때문에 삭제하도록 하겠다.

4. 투두리스트 완료할 때마다 2포인트 얻기

위 기능은 Backend에서 전처리가 들어간 후 DB에 적용해야하는 값이다!!!

그러면 이제 작업을 시작해보자

투두리스트를 완료할 때 마다 2포인트를 얻는다.

그러면 투두리스트 서랍장에서 아직 완료가 되지 않은 값을 완료가 되었다고 표시해야하고, 유저 서랍장에서 해당 투두리스트를 완료한 유저를 찾아서 포인트를 +2 해야한다.

이걸 그림으로 그리면 아래와 같다.

여기선 조금 복잡해지는데 흐름을 잘 이해하면 된다.
1. User가 로그인한 상태면 당연히 유저 식별번호를 가지고 있을것이다. 그게 있어야 front에서 보여줄 수 있으니까

2. front는 유저가 투두 완료를 의미하는 체크박스를 선택하면 유저의 식별 정보, 투두의 정보를 Backend에 전달한다.

3. Front에서 받은 유저 정보를 통해서 Backend는 유저 정보를 조회한다.

4. 조회한 유저 정보에 point부분을 +2를 수행한다. (그림에서 5번 )-> DB업데이트

위 과정을 마치면 유저의 포인트를 처리하는 부분은 끝난다. 그 다음은 투두항목을 완료가 되었다고 표시하는 일이다.

1. Front에서 받은 유저 정보로 투두 서랍장을 조회한다. (user_id를 통해서 투두 서랍장에 있는 것을 확인할 수 있다.)
2. 투두 서랍장에서 찾은 is_completed항목을 false-> true로 변경한다. 이는 유저가 선택했다는 것을 의미한다. ->DB 업데이트

3. backend의 할 일이 끝났으니 Front에서는 유저가 완료한 항목을 UI로 표시해준다.

이런 흐름이다.

이 흐름을 기억하면 된다.

3만원으로 바이브 코딩을 시도해보기를 작성하며

호기롭게 작성해보았지만 결과는 개같이 실패인것 같다.

이 글을 보고. 누군가 제미나이 챗봇으로 바이브 코딩을 할 수 있을것이란 생각이 전혀 들지 않는다. 어떻게보면 실패한 글이라고 할 수 있겠다.

내가 작성한 글은 서비스를 기획, 설계하는 방법에 대해서 쓴것에 가깝다. 하지만 기획, 설계가 미리 짜여져있는 프롬프트를 줬을때 AI는 더 정확하게 행동한다.

하지만 이 글을 통해서 단순히 "AI야 이거말고 저 기능 추가해줘" 하고 유저가 전체 코드를 복사 붙여넣기 하고, 그 과정에서 에러가 나는 부분을 잡을 수 있을까? 라고 질문한다면 "안돼"라고 답할 것이다.

실제로 함께 바이브 코딩을 해보는 부분을 넣어봤는데 생각보다 개발지식을 정확하게 알아야 내가 원하는 부분을 정확하게 고칠 수 있었다. 그래서 그 컨텐츠를 이 글에 넣을 수 없었다. 나는 모든 코드마다 주석을 넣고 설명을 적었지만 이걸 적으면서 "과연 어느 누가 이걸보고 제대로 이해할 수 있을까?"라는 생각이 들어 멈췄다.

next.js로 개발하면 react의 상태관리를 알아야하고, Spring boot를 사용하게 된다면 @Bean을 알아야한다. 그런 프레임워크 없이 개발한다고 쳐도 HTML + CSS 문법은 알았어야 했고, 거기에 기능을 붙히고 싶다면 어떤한 자료구조에 데이터를 저장하고 어떻게 가공할 것인지 알아야했다.

데이터가 어떤 흐름으로 움직이는지 판별하기 위해선 자료구조를 알아야 하고, 알고리즘을 깨달아야한다. 그리고 무작정 클로드 코드, 코덱스로 바이브 코딩을 하시는 분들은 이 구조를 정확하게 파악하고 있진 않겠구나 하는 생각이 들었다.

그도 그럴것이 바이브코딩을 하시는 분이 끊임없이 클로드에게 레이아웃을 핑크색으로 바꿔!! 라고 몇 번이나 갈궈야 원하는 값을 얻을 수 있었으니까

그것이 CSS에서 background-color나 컴포넌트의 class, id를 찾아서 색상 값을 pink로 바꿔줘라고 명령어하는 것이 아니고서야 말이다.

글씨쓰는 부분을 핑크색으로 바꿔줘!

라고 말하는 것과

화면 메인 컨텐츠 main-container class를 가진 div박스에서 textfield의 테두리 값을 변경하고 싶어 해당 CSS를 업데이트해줘

라고 하는 것은 분명히 다르다. 당연히 후자가 바이브 코딩을 하는데 훨씬 유리할 것이다.

내가 만들고 싶은 서비스를 구현하려면 시중의 서비스로는 분명히 한계가 있다. 시중의 서비스는 쇼핑몰을 만드는 데에 집중이 되어 있기 때문이다. 드래그앤 드롭으로 웹페이지에 이미지를 배치할 수 있지만 이미지를 눌렀을때 AI가 이미지를 글자로 설명해주는 로직을 만들려면 시중의 서비스로는 힘들 것이다. 그래서 바이브 코딩이 존재하는 것인데 그런 서비스를 자세하게 만들려면 단순히

일해!!! 라고 클로드와 챗지피티에게 강요할 수는 없다.

글을 쓰면서 바이브코딩이란 것에 조금 더 가까워진 것 같다. 내가 아닌 다른 사람의 시각에서 바이브코딩은 굉장히 어렵다고 생각한다. 할 수 있는게 명령하기 붙여넣기기 때문이다.

다음 컨텐츠는 내 개인 컨텐츠도 작성할 것이지만 틈틈히 바이브 코딩을 위해 알아야하는 개발 지식을 넣을 것 같다. 시중에 클로드 코드, 챗지피티로 바이브 코딩을 하는 사람은 많은데 정작 사전 지식이 뭐가 필요한지 알려주는 컨텐츠는 못봤기 때문이다.

참고 - 넣으려다가 만 자료 간단히 그냥 보기만 하세요 그리고 쓰다 말음

아래의 자료는 넣으려고 했다가 반려한 자료이다. 왜냐면 생각보다 내용이 너무너무 방대해지기 때문이다. 가볍게 참고하는 식으로 보시면 좋을 듯 하다.

Who is Json? 제이슨이 누구에요?

우리는 위에서 프로그램이 데이터를 어떻게 주고받는지 확인했다. 그렇다면 이제 궁금증이 생긴다.

Front - Backend - DB는 도대체 어떤 언어로 말을 주고받는걸까?

그 친구가 바로 Json이다.

간단한 TodoList페이지가 필요하다고 가정해보자

좀 구리지만 위와같은 웹 페이지가 있다.

여기서 확인할 수 있는건

1. 유저의 정보(로그아웃이 있다는걸 보면 회원이 관리되고 있다는 것을 의미한다.)
2. 투두리스트 목록들 - 투두리스트 목록에 분기가 있다는 것을 눈치 채야한다. 하나는 완료가 되지 않은 목록이고 완료가 된 목록이 존재한다는 것을 말이다.

그렇다면 이런 데이터를 주고받을때 json을 사용하는 것이다.

하지만 주의할 점이 있는데 FRONT - BACKEND 간에서 주고받을때는 JSON을 사용한다.

JSON
{
  "user": {
    "nickname": "YelITa"
  },
  "todos": [
    {
      "id": 1,
      "content": "아이스크림 사기",
      "isCompleted": false
    },
    {
      "id": 2,
      "content": "감자 사기",
      "isCompleted": false
    },
    {
      "id": 3,
      "content": "강아지 약 주기",
      "isCompleted": true
    }
  ]
}

json은 위와 같은 형태로 생겼다.

key: value형태로 이루어져 있다.

우선 key는 json에서 값을 꺼낼때 쓰는 것이다. 만약에 저 json에서 유저 정보를 뽑아내고 싶다면 key는 user 그리고 nickname : yellTa가 value가 된다. 저 value에서도 또 키가 들어있는데 바로 nickname이다.

즉 나는 yellTa라는 값을 최종적으로 뽑아내고 싶으면 user키를 뒤적거리고 거기서 nickname키를 사용하면 원하는 value를 얻을 수 있다.

todos도 마찬가지이다. 대신 다른점이 있다면 [] 로 되어있는건데 이건 배열을 의미한다. 배열은 여러개의 값을 저장할 수 있는 곳이다. 생각해보자 유저는 여러개의 투두리스트를 만들 수 있다. 유저가 단 한개의 투두리스트만 만들 수 있다면 그건 좋은 서비스가 아닐 것이다. 그러면 여러개의 투두리스트를 담아야한다. 그럴때 사용하는것이 배열이다.

배열은 데이터를 담는 박스라고 할 수 있다. 대신 박스의 번호는 0번부터 시작한다.

즉 todos키에서 값을 꺼내면 위 그림과 같은 박스(배열)을 얻을 수 있는 것이다. 첫 번쨰 박스부터 까보자, 참고로 배열은 1번이 아니라 0번부터 시작한다.

1번박스를 까면

 	  "id": 1,
      "content": "아이스크림 사기",
      "isCompleted": false

위와 같은 값을 얻을 수 있다. 여기도 마찬가지로 0번박스에서 꺼낸 값에서 key가 id인 것의 값은? 1이라고 할 수 있다. 0번 박스에서 key가 content인것은 "아이스크림 사기"이다.

이런식으로 json은 key:value값으로 이루어져 있고 내가 원하는 값을 찾기 위해 키를 사용해서 찾을 수 있다.

그렇다면 Backend - DB간은 어떻게 대화를 주고받는걸까?

그건 바로. SQL이다. 특히 SQL에서 Q는 Query의 줄임말이다. 즉 백엔드가 질문하고 DB가 질문에 대한 답을 주는 것이다.

DB는 데이터를 저장하는 서랍장같은 것이다. 백엔드 서버는 서랍장에 ~~정보가 있어? 라고 질문하게 된다. 이것이 쿼리이다. 질문을 보곤 DB는 값을 내보내주게된다.