ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 24일차 수업 - 스케쥴링 서비스(DoTomorrow) MVP 구현하기
    AI_Leader Camp 2026. 6. 15. 17:00
    Demo 구현과 수정

     

    저번수업시간에 스케쥴링 서비스를 만들면서 Stitch를 사용해 UI/UX까지 만드는데 성공했다

    일단 데모까지 만들어놨지만 지금다시보니 UI가 썩 맘에 들지 않는다

    우선 주간의 할 내용이 보여야된다

    내일이나 모레까지만 보이는건 심각한 문제다

    그리고 캘린더 형태로 월단위로 보여야되는건 아주 당연한 것 같다

     

    하여 달력형 화면을 볼수 있게 만들어 달라고 했다

    아주훌륭하게 금방 만들어낸게 굉장히 만족스럽다 ㅎㅎ

     

     

    Setting 의 Theme기능이 원활하게 되지않았다

    안에 글씨체라던지 박스의 색깔이 바뀌어야 될텐데

    Theme이 의미하는 바를 정확히 파악하고 있지 못한 것 같았다

    Demo를 넘어서 MVP까지 가더라도 사실 중요한 기능은 아니기 때문에 삭제하도록 했다

     

    정확히 콕집어 어떤 컴포넌트를 수정해야 되는건지 알려주는게 불편해서 Stitch를 쓸수 있다고 보는데

    정말 아주 조금의 Html CSS지식만 있으면 컴포넌트 특정하는게 정말 쉽고, AI가 그 말을 정말 찰떡같이 잘알아 들어서 너무 좋다

     

    근데 방금 바꾼거는 CSS속성 하나만 추가하면 되는건데 테스트까지 돌린다?

    난 이게 토큰낭비라는 생각이 든다

     

    하여 AI한테 물어본다

     

    줄인다고? 하지만 난 호락호락하지않다

    어떻게 줄일건데?

     

    난 항상 절약해서 코딩을 하고 싶기 때문에 이 내용을 전에 배운 룰이나 스킬로 등록해놓은 다면

    나중에도 계속해서 토큰의 소모량을 아낄 수 있지 않을까?

     

    하지만 난 여전히 룰과 스킬중에 하나를 정하지 못하겠다

    약간 애매하다고 생각한다

    그럼 나보다 똑똑한 기계한테 물어보면 된다

     

    이렇게 업무를 보는 중에 일이 생각나면 AI에게 바로바로 말해서 룰이나 스킬로 반영하고

    어느정도 룰과 스킬이 쌓였을때는 한번씩 최적화 해줘서 과도하게 커지지 않았는지 확인한다면

    안정적으로 하네스를 구축할 수 있다고 생각한다

     

    하네스를 한번에 구축하는게 아니라 계속해서 사용해 나가며 보완해 나가는 것이 더 좋을 것 같다는 생각이 든다

     

     

    모바일에서 잘 작동하는지 확인해봤다

    사실상 데스크탑보다는 모바일로 사용될 일이 많은 서비스이기 때문에 반드시 확인해봐야한다

     

    역시나 확인해보니까 석연찮게 작동하는 부분들이 있었다

     

    PC에서는 task를 드래그 앤 드랍으로 다음날로 옮기는 게 굉장히 간편했는데

    모바일에서는 해당 동작이 작동하지 않았다

     

    이렇게 하나하나 물어보고나서 해결하는게 좀 귀찮을 수도 있지만

    지금단계에서는 많이 해보는게 좋을 것 같다

     

    그러면서 관련지식도 좀 쌓다보면 나중에는 좀 대충넘어가더라도... 지금은 이러는게 다 도움이 될 것이다

     

    드래그앤 드랍할때 컴포넌트가 굉장히 느리게(마치좀비처럼) 쫓아와서

    해결방안을 물어봤더니 방법2는 좀 터무니 없는.. 리소스낭비일 것 같은 방안도 제시해준다

    번번히 물어보는것에 보람을 느낀다

     

    나는 지시할때 최대한 자세히 지시하는게 맞다고 생각하는 사람이다

    아 이상해 고쳐줘~ 가 아니라 구체적인 지시를 해보고 그거에대한 피드백을 통해서 더 발전 시킬 수 있는 부분을 찾아보는 편이 단기적인 개발속도는 늦을지언정 전체로 봤을때는 효율적이지 않을까 생각한다

     

     

     

    아주 굉장히 훌륭하게 내가 원하는 바를 해결해줬다

     

    여기까지는 Solution Interview를 할 수 있을 정도의 데모버전이라고 생각한다

     

     

    그 다음단계의 데모버전은 마치 우리가 게임을 사면 먼저 체험판을 해보듯이

    체험을하다가 "아 뭐야 출시된거 아니었어? 출시되면 써야겠는데?"

    싶은 느낌의 데모버전(체험판)을 만드는 것이다

     

    실제로는 이 두가지의 데모버전 중 한가지만 만들어도 될 것 같기는 하다

    이번에는 실습이니까 제대로 체험판 제품을 만들어 본다

     

     

    나의 과정을 잘 복기하기 위하여 Github에 잘 올려놓을 것이라 세가지의 형태로 리포지토리를 다르게 올리려고 한다

     

    1. 기능이 동작하는 척 만하는 데모버전 - DB연동 X
    2. 기능이 실제로 동작하지만 모든기능을 사용할 수 없고 주요기능만 제한적으로 사용가능한 데모버전, 사용자의 이메일 주소를 수집해서 이 서비스를 원하는 사용자가 얼마나 될 것인지 측정하는 용 - DB 연동O(이메일 주소, 클릭 수 등 사용자 정보를 확인하는 정보만 수집)
    3. MVP버전 - 핵심기능이 원활하게 작동하는 서비스 - DB연동 O

     

     

    리포지토리가 아까워서 그냥 2단계로 하기로 한다

     

     

    현재의 서비스를 조금 사용하다가 이메일 등록으로 전환되고 종료되는

    열불터지는(?)서비스를 먼저 만들고

    더 사용하려면 이메일 등록을 하고 출시를 기다리라는 식의 마케팅을 해보는 것이 목표다

     

    화면을 엉망진창으로 만들면 내가 이 버튼은 어떻게 해야되고 여기 Textarea는 무슨색이어야되고...

    이런 수정명령을 계속해서 내려야되는데

     

    개발자 도구를 열어도 Component들에 ID가 없어서 지칭하기가 쉽지않다

    그래서 아예 ID를 명명하도록 규칙에 넣어버렸다

     

    근데 여전히 ID를 못넣는 컴포넌트들이 발생했고

    왜그러냐니깐 실수가 있을수있기때문에 한번씩 콤포넌트를 싹 체크하겠단다

    그래서는 토큰낭비아니냐니까 맞다고해서

     

    특정태그에만 ID를 달도록 하는 것으로 합의를 봤다

     

    룰 수정

     

     

    물어본건데 코드를 수정해버림

     

     

    하여 룰추가

     

     

     

     

     

     

    후... 정말 많은 수정사항들이 있었다...

     

    1시간정도만 사용해서 대충 앱을 만들려고 했는데..

     

    내가 Builder's Trap에 빠진건 확실히 아니다...

    그저 개발자로서....

    테스트를 해보고 원활하게 작동하지 않은 점들을 계속해서 수정했을뿐.....

     

    분명 오후부터 했는데 새벽이 되었다..

     

     

    계속해서 오류를 잡다 보니 사실 DB 만 붙이면 이건 Demo가 아니라 MVP의 형태가 되어있었다

    하여 안티그래비티한데 울었다물었다

     

     

    그리하여...생각을 달리한점

     

    원래는 Demo / 체험판 / MVP

    버전의 코드를 깃허브에 각각 다른 리포지토리에 저장해서 확인하고 회고하려고 했다

     

    하지만 지금도 조금해봤을때 수정할 거리가 정말 부지기수로 나오는 상황에서

    리포지토리를 분산하면 세개를 동시에 유지보수하는 것이 사실상 불가능 하기 때문에

    이런 두가지 방안을 주었다

     

    위의 방식은 내가 개발할때도 많이 써먹던 방식이었다

    상수값하나를 코드에 심어놓고 그것에 따라 다른 작동이 되게 하는 것이다

     

     

     

     

    하여 Git 생성!

    MCP 만세!
    MCP 만세!

     

     

     

    와... 진짜 MCP만만세다..

    DEMO -> MVP

     

    강사님이 제공한 프롬프트 보고 따라하는 것 보다는

    큰틀을 대강 파악해서 내가 알아서 해보는 쪽이 도움이 되지 싶다

     

    일단 나의 데모 버전과 다른점은 명확히 어디서 끊고 이메일을 등록하게 한다



    그로부터 며칠이 더 지났고 나는 여전히 여러가지 석연찮은 오류를 잡아내고 있다

     

    한가지 오류는 너무 열받아서.. ㅋㅋㅋ 분노를 금치 못했는데

    수업과 특강 실습을 수행하다가 생기게된 오륜데
    antigravity랑 codex를 둘다 사용해서 localhost에 배포를 하고있었는데

    A프로젝트는 Anti에서 B는 Codex에서 배포했었다
    근데 특정포트에서 A프로젝트를 하다가 B프로젝트를 한번씩 배포했었고

    다시 A프로젝트를 Antigravity에서 배포하는데 계속해서 B프로젝트가 올라가게 되었다

     

    Antigravity한테 왜그러냐 확인해봐라 뭐가 문제냐하는데

    자꾸 캐시 같은 헛소리만 하고있었다... (당연히 시크릿에서도 해봄)

    너무 열불터지는게 같은소리만 계속 반복하는 거였다 ㅋㅋㅋ

    아우 진짜.. 너무 빡쳐서... 둘다 켜놓고 둘다 ㅋㅋㅋㅋ...혼내면서 누가 잘못한건지 (물론 내가잘못한거겠지만 ㅋㅋㅋ)

    가려내고있었다 마치 솔로몬 마냥

     

     

     

    그리고 하다하다 내가 추측해낸 것은 터미널 기본경로를 B프로젝트 폴더로 지정해버려서(Codex(내)가)

    A프로젝트를 배포시켜도 계속해서 B프로젝트가 올라갔던거였다

     

    "맞습니다 네 추정이 정확했습니다"

     

    마치 외국에서 막 졸업하고 신입사원으로 온 MZ사원이 지가 잘못해놓고(사실 내가 잘못함) 저렇게 반존대 섞어가며 나한테...ㅂㄷㅂㄷ 망할 AI놈이.......

     

     

    ㅋㅋㅋㅋ 분명 내가시킨건데 너무 빡쳐하니까 그냥 사과하고 보는 AI ㅠㅠㅋㅋㅋㅋㅋ

    코덱스는 욕을하면 말을 잘듣는 것 같다

    다음엔 존댓말부터 제대로 가르쳐야겠다

     

     

    터미네이터가 나오면 제거대상에 근접해졌다

     

     

     

     


    그로부터 며칠뒤 드디어 MVP서비스를 완성해서 며칠 사용해봤다

     

     

    특강에서 Favicon이랑 OpenGraph라는 것을 배웠기 때문에 그것까지 적용해 봤다

     

     

    Favicon은 브라우저에서 보이는 아이콘이고
    OpenGraph는 우리가 어떤 링크를 넣었을때 나오는 사진과 설명이다

     

    이 작은 차이가 완성도 면에서 큰 차이를 준다

     

    Favicon

    현재는 프론트엔드 빌드 툴인 Vite로 지정되어있어서 개발을 해본사람은 바로 알것이다

    아 이거 완성도가 떨어지네...

     

    이렇게 보인다면 나름 뭔가 만든티가 날 것이다

     

    OpenGraph

     

    우리가 링크를 카카오톡에 붙여넣어보면 그럴싸한 사이트들은 다 어떤 그림이 나온다

    근데 만약 이런 느낌이면 뭔가 허접함이 느껴지는 것이다

    하지만 이렇다면 뭔가 오.. 만들었구나 하는 신뢰감이 들것이다

     

    도메인주소도 중요하지만..ㅎㅎ 일단 MVP니까 패스!

     

     

     

     

    DoTomorrow - 내일해

    지독한 P들을 위한 간편한 To Do List. 오늘 못한 일은 내일 바로 이어서, 가볍게 적고 넘기는 데일리 할 일 앱.

    schedule-checker.vercel.app

     

    티스토리에서도 훌륭하게 OpenGraph가 나오긴하는데

    흠 ㅋ 겁나 짤려서 나왔넹

     


    링크를 이런 퍼블릭한 장소에 오픈할때는 뭔가 공격당하지않을까 걱정이된다

    supabase를 무료버전으로 쓰고있는데 사용량이 많으면 유료전환해야되는거 아닐까?

    누군가 악성사용자가 내 일정앱을 들어와 해코지를 한다면?

     

     

     

     

    1. RLS라는건 Row Level Security를 뜻하고, DB의 Row단위로 보안을 강제한다는 것이다. 그 다음의 2가 실제내용이 된다.

    2. Supabase의 API를 직접호출하지 않게 user_id = auth.uid()와 같을때만 허용한다고 한다. 어렵지만 쉽게얘기하면 본인인지 확인해서 본인계정의 행동만할 수 있도록 DB에서 강제한다는 뜻이다

    3. Row에 갯수제한을 DB에서 설정한다

     

    1,2는 이미 작성하는 과정에서 했다고 한다.

    3 까지 해서 좀더 보안에 완성도를 높여서 안전한 MVP를 만들어본다

     


    이제 테스트 데이터는 다 지워서 마지막 준비를 한다

    테이블에 카카오로그인 안한 계정의 데이터는 전부 삭제하기로 한다

     

    이렇게 지워도 되냐고 물어보니까

     

    이렇게 적으라고 한다

     

    몰랐던 사실인데 public.users랑 auth.users 두 테이블이 있다

     

     

    흠.. 봤는데 사실 무슨소리인지 정확히 모르곘다

     

    현업에서는 그냥 테이블을 생성할 때 저렇게 두개씩 생성하지 않았는데

    뭔가 새로 배워야 할 부분인 것 같다

     

    그전에 했던 건 뭐랄까 구조적이지만 그다지 구조적이지 않았던것 같다

    사실 정확히 이해는 못하겠으니 어느정도 듣고 넘어가는 정도로 그치는게 좋을 것 같다

     

     

    와 내가 저런 쿼리를 작성하니까 제목이 Remove Users Without Email이라는 이름으로 바뀌었다

    내가 정확히 어떤 쿼리를 작성해서 실행한건지 다 파악하고 있다는 느낌이었다

     

    정말 ㅋㅋ 지금껏 너무 구시대적인 툴만 쓰고 살았다는 생각이 든다 ㅠ

     

     

    이제 내 바탕화면에 당당히 자리해서 사용해보면서 테스트해야지!

     

     

    ㅋㅋㅋ..... 데이터를 잘못지웠다..

    나는 Email등록은 안하고 카카오톡 로그인만 했던건데... 그게 email인것이라 착각했다..

    실제서비스였으면..뭐 망한거... ㅋㅋ 라는 생각을하면서..!

     

     

     

     

    이게 지금 거의 2주정도에 걸쳐 한 작업들인데.. 정말 많은 작업들을 했던것 같다..

    많은 기능이 있는 앱이 아니어도 만드는데 굉장히 많은것들을 고려해야되고 개발하는데도 오래걸린다

    끝까지 해보면서 얻게된 많은 지식들이 분명 도움이 될 것이다

     

     

     

    우선 이 MVP는 이정도에서 마무리하고 사용하면서 테스트 해봐야겠다

     

     

    이 글을 읽는 당신도 테스트하고 싶다면!!

     

    DoTomorrow - 내일해

    지독한 P들을 위한 간편한 To Do List. 오늘 못한 일은 내일 바로 이어서, 가볍게 적고 넘기는 데일리 할 일 앱.

    schedule-checker.vercel.app

    내일하지말고 오늘 들어가봐주세요! ㅎㅎ

    'AI_Leader Camp' 카테고리의 다른 글

    23일차 수업 - Antigravity_Rule&Skills  (0) 2026.06.01
    22일차 수업 - DB  (1) 2026.05.27
    21일차 수업 - MVP형태, 데모  (0) 2026.05.26
    20일차 수업 - Lean Start Up  (0) 2026.05.23
    19일차 수업 - GitHub, AntiGravity, AIStudio  (0) 2026.05.21
Designed by Tistory.