1. 본격 시작에 앞서서

이글은 실제로 수십번 어플을 만들어 보면서 엄청난 시행착오를 통해 시작하는 글입니다.

UI제작 보다는 이론이나 백엔드 기획에 대해서 다룰것입니다.

 

 

일정

2025년 2월 25일 - 스타트업 대표님과 대화 현재 잘 진행되고 있는지 설명

2025년 2월 26일 - 사업계획서 및 아키텍처 다시보기 / 영업을 위해서 계획 짜기 / ui제작

2025년 2월 27일 - 구조 다시 설계

2025년 2월 28일 - 코드설계

 

느낀점

 

일단 느낀점은 영업이란 쉽지 않다고 느꼈다 나는 

매장 마커를 추가만 하면 되지 않을까? 생각했는데

사장님께서 위치정보도 동의 안 해주신다. 찾아가서 말씀도 드려봤는데

아예 이상한 사람 취급도 받아서 솔직히 마음이 좋지는 못했다.

다른 사장님께는 또 서비스를 설명해드렸는데 법인사업자라 나는 못하겠다.라고 거절하셨다.

 

많은 생각이 드는 하루였지만 그래도 하나 얻은 지식이있다.

일단 갖춰 놓은 것이 없다. 마케팅이라도 차라리 하고 있었으면 사장님께서는 

그래 너 위치 동의만 해줄 테니까 해봐 이렇게 나오지만 애초에 mvp도 다 안 만들고 가서 욕만 먹고 온 기분이다.

 

일단 오늘을 기점으로 똑바로 어플을 설계하고 만들 것이다.

그렇다면 개발지식도 올라가고 사장님들께 보여줄 수 있겠다 생각했고

여기 플러스로 마케팅을 하고 있어야 된다. 그래야 사장님과 대화가 가능하다.

 

 

 

아키텍처 부터

 

0부터 시작 아키텍처 이론을 닥치는대로 찾아봤다.

 

핵심은 두가지 중 하나였다.

msa 아키텍처 방식

모놀리식 아키텍처 방식

 

근데  여기서 모놀리식으로 나는 개발하고있는데 진짜 말도 안되게 개발하고있는 중이였다 ㅋㅋㅋ

뭐 알아야 뭘하지... 박치기를 해봐야 아는 내성격은 어쩔수 없나보다.

https://alive-wong.tistory.com/6#google_vignette

DevOps란? - MSA와 컨테이너 아키텍처까지

블로그 글을 읽던중 

 

"모놀리식으로 시작하여, 모듈식으로 서비스를 분리하여 유지하고,

만약 모놀리식의 구조가 문제가 된다면 그때 마이크로 서비스로 분리해가라

 

나는 모놀리식으로는 만들면 안된다.  왜? 이건 AI가 있어서 걍 누구나 쉽게 만들기도 하고

이건 개발 실력도 안올라간다 사실 코드 실력은 늘겠지만..

 

그래서 나는 모듈식으로 서비스를 분리해야되겠다고 생각했다.

근데 이것도 막했다가 또 다시만들어야되니까..  좀 찾아 보던 중

나는 flutter 로 프론트엔드를 쓸거니까 flutter 에 맞는 디자인 패턴중 mvvm에 대해서 찾아봤다.

MVVM은:

• Model: 데이터와 비즈니스 로직 (DB나 API에서 가져온 데이터).
• View: 사용자에게 보이는 UI.
• ViewModel: View와 Model 사이를 연결하며, UI에 맞게 데이터를 가공.

 

흐름은? 
main.dart에서 TodoViewModel을 Provider로 등록.

ui 화면 에서 Provider로 ViewModel을 가져와 데이터 표시.

데이터 가공화면 에서 Supabase 호출 후 상태 업데이트 → UI 자동 반영.

 

한마디로 모놀리식 + 서버리스 +mvvm +프로바이더 상태관리

 

그럼 왜 ? 이렇게 하나?

mvvm반영 : models,viewmodels,views로 나눠서 패턴을 명확하게 유지 (데이터 관리는 데이터 관리 ui는 ui로 )

 

서버리스 통합 : services에 supabase 호출 넣어 백엔드 통신 분리

 

확장성 : 기능이 늘어나면 views나 viewmodels 에 파일만 추가 가능

 

재사용성: 반복되는 UI는 widgets로 빼서 중복 줄임 

 

 

그럼 프로바이더는 왜쓰냐?

 

• notifyListeners로 자동 UI 갱신: ViewModel에서 데이터가 바뀌면 setState 없이도 화면이 갱신돼요.
• 중앙 집중 상태 관리: 여러 화면에서 TodoViewModel을 공유해서 쓸 수 있어요.
• MVVM 강화: ViewModel이 상태를 관리하니까 뷰는 더 얇고 깔끔해져요.

 

 MSA 확장은 어떻게?

 

config/app_config.dart & utils/constants.dart
기존 Supabase 관련 URL이나 키 대신, Spring 서버의 기본 URL, 포트, API 엔드포인트, 그리고 필요한 경우 인증 토큰이나 기타 환경변수를 저장하게 됩니다.

models/todo.dart
데이터 모델은 서버에서 반환하는 JSON 구조가 동일하다면 거의 변경 없이 유지됩니다. 다만, Spring에서 추가 정보나 다른 필드가 제공된다면 그에 맞춰 생성자나 fromJson 메서드를 수정해야 합니다

 

services/supabase_service.dart
이 파일은 핵심적으로 많이 변경됩니다.

• 파일 이름 및 내부 클래스 이름을 Supabase 관련 명칭에서 일반 REST API 호출에 맞게 변경할 것입니다.
• Supabase Flutter 클라이언트를 제거하고, 대신 http 패키지나 다른 HTTP 클라이언트를 사용하여 Spring 서버의 REST API 엔드포인트에 GET, POST 등의 요청을 보내게 됩니다.
• 요청 헤더, 파라미터, 응답 처리 로직 등이 Spring 서버의 API 스펙에 맞게 새로 작성되어야 합니다.
• 인증 방식이 달라진다면 (예: JWT 토큰) 그에 맞춰 헤더 설정이나 토큰 갱신 로직을 추가할 필요가 있습니다.

 

 

설계

 

일단 나는 마지막은 msa 아키텍처를 이용할것이고 그렇게 되면 자연스럽게 도커 , 젠킨스를 사용하게 될것이다. 

설계 다이어그램은 따로 올릴 예정

 

 

실제 만들어보기

 

flutter 에서는 폴더를 생성 그 후 거기에 맞는 dart파일 제작 

 

이렇게 만들어놓으면 나중에 

Spring 기반 MSA 아키텍처로 전환할 경우, 전체 앱 구조는 크게 바뀌지 않지만 주로 데이터 호출 및 인증 방식이 변경만 하면된다.

 

 

실제로 역활들은 

lib/
├── main.dart               # 앱 진입점
├── models/                 # 데이터 모델
│   └── todo.dart           # Todo 클래스
├── viewmodels/             # ViewModel (로직 처리)
│   └── todo_viewmodel.dart # Todo 관련 로직
├── views/                  # UI 화면
│   └── todo_screen.dart    # Todo 리스트 화면
├── services/               # 외부 서비스 호출 (API 등)
│   └── supabase_service.dart # Supabase API 호출 로직
├── widgets/                # 재사용 가능한 UI 컴포넌트
│   └── todo_item.dart      # Todo 항목 위젯
├── utils/                  # 유틸리티 함수
│   └── constants.dart      # 상수 (예: API URL)
└── config/                 # 설정 파일
    └── app_config.dart     # 앱 설정 (환경 변수 등)

 

잘됩니다.

 

법 어렵다

 

 

그리고 내가 위치를 가져와서 무언가를 하면 고소를 당하는지 매번 궁금했는데 

대한민국 법이란 법을 싹 디져서 알게된 사실 

 

가게 위치 정보를 제공하는 것이 개인정보 침해인가?

• 아니요, 가게 정보(매장 주소, 연락처 등)는 개인정보가 아닙니다.
• 대한민국의 개인정보보호법에서 말하는 "개인정보"란 **특정 개인을 식별할 수 있는 정보(이름, 주민등록번호, 전화번호, 얼굴사진 등)**입니다.
• 가게(사업장)는 법인이거나 사업자로 등록된 곳이기 때문에, 사업자 정보(위치, 연락처 등)는 개인정보로 보호되지 않습니다.
• 예외적으로, 개인사업자의 경우 대표자의 실명이나 개인 전화번호가 포함될 경우 일부 개인정보로 간주될 수 있습니다.

네이버 지도에 위치 등록하는 것이 불법인가?

• 공개된 장소(예: 매장, 식당, 카페 등)의 위치를 지도에 등록하는 것은 문제되지 않습니다.
• 대부분의 매장은 대중에게 공개된 장소이므로, 위치를 공유하는 것이 불법이 아닙니다.
• 다만, 가게 운영자가 등록을 원하지 않는 경우 네이버 지도 등에서 삭제 요청을 할 권리는 있습니다.

사업자가 "고소"할 수 있는 경우는?

가게가 다음과 같은 이유로 문제를 제기할 수는 있습니다:

• 허위 정보 등록: 가게 위치를 잘못 등록하거나, 가짜 매장을 등록하면 업무방해죄가 될 수 있습니다.
• 비방 목적: 단순히 위치 등록이 아니라, "이 가게는 불친절하다" 등의 명예훼손적인 내용을 포함하면 **명예훼손죄(정보통신망법 또는 형법)**가 적용될 수 있습니다.
• 위치 공유로 인해 피해 발생: 예를 들어, 가게 주소를 사적인 용도로 유출해 사생활 침해가 발생한다면 문제될 수 있습니다.

결론: 고소 가능 여부

👉 단순히 네이버 지도에 매장 위치를 등록하는 것은 개인정보 침해가 아니며, 고소당할 가능성도 낮습니다.
🚨 단, 허위 정보 기재, 명예훼손, 영업 방해 등의 요소가 있다면 문제가 될 수 있습니다.

즉, 가게 위치만 공유하는 것은 불법이 아니지만, 비방 목적이 포함되면 법적 문제가 될 수 있습니다.

 

 

이 말인즉 비방 목적이 아니라면 공유하는건 문제가 안된다는 말이다 . ㅎㅎ 이제 쫄지말고 올려 보면 될거같다.