조사할 것
1. xml, yaml, json 이 뭔가요?
데이터 표현 형식으로 간단하게 말하자면 한 줄로 이어진 데이터들을 구조를 가진 언어로 번역하는 것이라고 할 수 있습니다.
(1) XML(eXtensible Markup Language)
- 특징:
- 1990년대 SGML을 기반으로 개발
- 태그 기반의 구조, HTML과 유사한 문법을 사용
- 사용자 정의 태그 가능하므로 태그의 중복을 방지
- 엄격한 구문 규칙
- 사용 사례:
- 웹 서비스 (SOAP)
- 설정 파일 (예: Android의 레이아웃 파일)
- 데이터 교환 (예: RSS 피드)
<book>
<title>The Great Gatsby</title>
<author>F. Scott Fitzgerald</author>
<year>1925</year>
</book>
(2) JSON (JavaScript Object Notation):
- 특징:
- 키-값 (""붙여야함)쌍으로 구성
- 경량화된 데이터 교환 형식
- 언어 독립적이지만 JavaScript와 호환성이 좋음
- 사용 사례:
- API 응답 데이터
- 설정 파일 (예: package.json in Node.js)
- 데이터베이스 (예: MongoDB)
{
"book": {
"title": "The Great Gatsby",
"author": "F. Scott Fitzgerald",
"year": 1925
}
}
(3) YAML (YAML Ain't Markup Language)
- 특징:
- 들여쓰기 기반의 구조
- 인간 친화적인 가독성
- 복잡한 구조 표현 가능
- Array/Lists :
-, [], ["문자열"] 사용, 순서중요
- Dictionary/Map : 줄 맞추기, 순서 상관없음
- 사용 사례:
- 설정 파일 (예: Docker Compose, Kubernetes)
- CI/CD 파이프라인 구성 (예: GitLab CI, GitHub Actions)
- 데이터 직렬화
book:
title: The Great Gatsby
author: F. Scott Fitzgerald
year: 1925
YAML과 JSON은 데이터 직렬화 형식으로 키-값 페어의 형태로 나타냅니다. 차이점은 JSON은 데이터 객체를 값으로 지원하지만, YAML은 그렇지 않으며 자연어에 더 가깝다고 볼 수 있습니다.
XML은 Mapping하기가 어렵고 많은 태그 때문에 응답시간이 느려져 개발자 사이에서 JSON이 빠르게 확산되었습니다.
2. MVC, MVP, MVVM이 뭔가요?
아키텍처 패턴


(1) MVC
Model, View, Controller

- 1979년 발표
- UI, 데이터, 제어 로직을 분리한 접근 방식
- 소규모 프로젝트
- 모든 input은 Controller로 전달됩니다.
- Controller는 입력에 해당하는 Model을 업데이트합니다.
- 업데이트 결과에 따라 View 선택합니다.
- Controller는 View를 선택할 뿐, 직접 업데이트 하지는 않습니다.
- View업데이트 방법:
- View가 Model을 직접 이용하기
- Model에서 View에서 Notify하기
- View가 Polling하여 Model의 변화를 감지
- 단점 : Model과 View 사이 의존성 발생 - 유지보수 어려움
(2) MVP
Model, View, Presenter

- 소규모 프로젝트
- 모든 input은 View로 전달됩니다.
- Presenter는 입력에 해당하는 Model을 업데이트 합니다.
- 업데이트 결과에 따라 View를 업데이트 합니다.
- Presenter는 해당 View를 참조하고 있습니다.
- Presenter는 View와 Model인스턴스를 가지고 Model과 View사이의 매개체 역할을 합니다.
- 단점 : View와 Presenter 사이 의존성이 커짐, 필요한 클래스 개수 많음
(3) MVVM
Model, View, View-Model

- UI 로직의 단위 테스트가 용이
- 모든 input은 View로 전달됩니다.
- View-Model은 입력에 해당하는 Presentation Logic을 처리하여 View는 데이터를 전달합니다.
- View-Model은 View를 참조하지 않기 때문에 독립적입니다.
- View는 자신이 이용할 ViewModel을 선택해 바인딩하여 업데이트를 받게 됩니다.
- Model이 변경되면 해당하는 View-Model을 이용하는 View가 자동으로 업데이트됩니다.
- View-Model은 View를 나타내 주기 위한 Model이자, View의 Presentation Logic을 처리합니다.
- 단점 : View-Model 설계가 쉽지 않음
MVI, MVVM-C, VIPER
-
MVI: Model View Intent
-
MVVM-C: Model View View-Model Coordinator

-
VIPER: View, Interactor, Presenter, Entily, Router

MVW(Model-View-Whatever)라는 말이 있듯이
프로젝트 규모와 팀의 전문성 등에 따라 선택하게 됩니다. 규모 뿐만 아니라 Data binding이 필요한 경우면 MVVM이 유리하고, 기능 추가가 빈번할 것으로 예상되면 VIPER가 좋습니다.
이미지: https://youtu.be/I5c7fBgvkNY?si=KNwqoETD74MQKGqL