소개
바이브코딩툴 성능이 워낙 좋아서 처음 돌아가는(것처럼보이는) 웹앱이 금방 만들어지지만,
이걸 서비스로 발전시키려면 인간의 고뇌와 이해가 필요합니다 ㅎㅎ
지난주말 실사례가 있어서 해당 내용을 공유해봅니다.
진행 방법
거창한 도구는 필요없습니다. (사실 있으면 좋습니다.)
하지만 기획자의 의도와 논리가 전제되어야 하죠.
처음에 서비스 만들어갈때 그냥 종이와 펜만 있어도 좋아요.
눈오지 님이 준비하는 서비스를 개발하기 위해 db구조 잡는거 도와달라고 요청이 왔고,
제가 만들어본 종류의 서비스는 아닌데 뭐 만들어보지 하면서 해봤어요.
ㅋㅋㅋㅋㅋ 진짜 스케치를 했습니다. ㅋㅋㅋㅋㅋ
여기서 db관련된 내용은
이정도?
내가 만들려고 하는 서비스의 데이터 흐름과 연관관계가 어떻게 되는지 창조자가 알고 있어야
향후 개선이나 데이터의 논리적 구조를 파악하는게 가능할거애요.
AI가 뭔지 모르는 내용으로 멋져보이게 만들어준다고 그걸 다 컨펌하면..
서비스가 망하면 별 상관없지만 ㅎㅎ 멋진 서비스가 되는 아이라면 언젠가 대혼돈을 겪을 수도 있겠죠?
(그래도 서비스가 잘되서 대혼돈을 겪는 경험이 훨씬 값지다고 생각합니다 ㅎㅎ 그건 돈이 되는거일 가능성이 높거든요 ㅎㅎㅎ)
아무튼 생각 정리용으로 스케치하면서 구조가 대략 파악은 됐는데
저걸 다시 정리하려니까 귀찮자나요?
우리는 이럴때 AI를 사용하면 될거애요 ㅎㅎㅎ
성능이 대폭 향상된 gemini한테 알아서좀 해달라고 해봤습니다. (눈오지님이..)
오.. 생각보다 잘 정리합니다.
2. [System & DB] 데이터베이스 구조 및 로직 분석
스케치 하단의 복잡한 선들과 메모는 관계형 데이터베이스(RDBMS)의 스키마(Schema)와 비즈니스 로직을 시각화한 것으로 분석됩니다.
메타데이터 태깅 시스템 (Metadata Tagging System):
분석: "태그, 문제 내용" 언급 부분.
구조: 단순히 문제를 저장하는 것이 아니라,
법률 조항,난이도,핵심 키워드등을 해시태그(Tagging) 형태로 DB에 매핑해야 합니다. 이는 오답노트 생성 시 "민법 제OO조 관련 틀린 문제만 보기"와 같은 쿼리(Query)를 가능하게 합니다.학습 이력 데이터 (User Activity Log):
분석: "몇 문제 맞혔는지, 오답노트까지 되는 구조".
구조:
User_ID와Question_ID를 매핑하는 중간 테이블(Mapping Table)이 핵심입니다.
is_solved: 풀이 여부
is_correct: 정답 여부 (오답노트 트리거)
solve_date: 풀이 날짜 (망각 곡선 알고리즘 적용 가능성)커뮤니티 기반 품질 관리 로직 (Crowdsourced QA Logic):
분석: "싫어요 비율이 높으면 문제 퇴출".
로직: 이 부분은 시스템의 자동화된 트리거(Trigger)로 설계되어야 합니다.
각 문제(Question) 테이블에
dislike_count컬럼이 존재.
Threshold Algorithm: (싫어요 수 / 전체 풀이 수) > 특정 비율(%) 일 경우is_active = False로 변경하여 문제 풀에서 제외(Soft Delete).
구조 정리하면서 스케치와 함께 녹음까지 해서 제공하면 더 잘 정리했을 것 같아요!
그러면 완벽하진 않지만 손그림도 정리시켜보죠..
역시 더욱 향상된 나노바나나로 정리를 시켜봤습니다.
오.. 한글 표현이 정말 좋아졌습니다!
물론 의도한바가 명확히 반영되진 않았어요 ㅋㅋㅋ
그래도 이정도면 상당히 훌륭한 수준이라고 생각됩니다.
정보 제공의 누락도 많았는데 이정도면 훌륭한 추론이죠!
이제 저런 내용을 바탕으로 db구조를 설계하고 개발을 하면 지속가능한 서비스가 되는거죠 ㅎㅎ
저런 흐름이 머릿속에 있어야 AI가 설계한 내용을 가지고 뭐라고도 하고 다시 하라고도 해보시길 추천드려요 🙂
결과와 배운 점
눈오지 님 서비스가 잘 만들어졌으면 좋겠네요 ㅎㅎ
